토스 2025 makers 컨퍼런스 후기

유명한 컨퍼런스는 응모를 해도 매번 떨어졌습니다.
컨퍼런스와는 인연이 없구나 생각하고 있을 무렵 2025 토스 makers 컨퍼런스에 당첨되었습니다!
한편 같이 응모한 PM인 아내도 당첨된 걸 보면 이번엔 경쟁률이 낮았던 걸까요..?

여튼 토스 컨퍼런스에 잘 다녀왔습니다!

메이커라는 단어가 좋은 것 같아요.
저도 무언가 새로운 것을 만들고 싶어 개발자가 됐으니까요.

가자마자 한 일은 럭키드로우 스티커부터 다 모으기..
퍼시스 모션 데스크가 너무 갖고 싶었지만 역시나 비타 500을 받았다네요.

 
저는 25일 Engineering Day에 참석했어요.
강연이 정말 많았는데요, Frontend 위주로 듣고 소프트 스킬과 백엔드 강연도 들었어요.

 
발표하시는 분들이 쓴 개발 관련 글들도 적혀있더라고요.
저기에 제가 쓴 글도 적혀있다면 꽤 멋지겠는걸? 싶었어요.

 
제 캐릭터 하나 그림 남겨주고..
제 표정이 너무 뚱하네요 ㅎㅎ
최근에 파마했는데 예쁘죠?
제가 들었던 강연 중에 인상 깊었던 이야기들을 정리해 볼게요.
 

실제 사례로 알아보는 생존형 엔지니어링 이야기: 이정행 토스 페이먼츠 Head of Product

 
저도 쓰고 있는 커플 메신저 앱 비트윈을 창업하신 이정행 님께서 겪었던 사례를 바탕으로 개발팀에서 어떤 결정을 하셨는지 이야기해 주셨어요. 저도 비트윈과 비슷한 스타트업에서 일하고 있다보니 공감되는 이야기들이 많았어요.
 
1. 잘 아는 것을 선택해라
비트윈 때 spring을 사용하지 않고 netty로 직접 개발, 이모티콘 구매 서비스에 python과 flask를 선택, DB를 HBase로 결정했던 경험을 이야기 해주셨어요. 세 경험 모두 선택할 당시에는 나름의 이유가 있었지만, 시간이 지나고 나니 다른 회사들에서 쓰지 않는 기술이거나, 회사 내에 해당 기술 스택을 잘 아는 사람이 없었고, 서비스가 커지면서 발생하는 이슈들이 있었다고 해요. 그래서 안정화 기간 동안은 새로운 feature 개발을 못했다고 합니다.
 
새로운 기능을 빠르게 개발해야 하는 회사라면은 많은 사람들이 사용하는 기술 스택을 선택하는 게 중요하구나 싶었어요.
 
2. 문제가 되기 전에는 해결하지 않는다.
개발 철학 중에 YAGNI (You Aren't Gonna Need It)이라는 게 있죠. 당장 필요하지 않은 기능은 개발하지 않는다는 용어입니다. 하지만 상황에 따라서 이 철학을 지키지 못할 때도 있을 거예요.
 
정행님은 cell based 아키텍처가 로컬에 있는 DB로 처리하기 때문에 latency를 줄여 서비스에 도움이 될 거라 생각하셨대요. 그래서 실제 코드에서 설계에 미리 반영을 했다고 합니다.
하지만 코드가 너무 복잡해져서 협업이 힘들어지고, CPU 비효율도 발생했대요. 그래서 선반영한 설계를 한 달 동안 리팩토링해서 없앴고 그동안 신규 기능 개발을 못했다고 합니다.
 
저 같은 경우는 컴포넌트를 공용으로 만들지 고민할 때 이런 비슷한 경험이 있었어요. toggle switch를 만들어야 하는데, 아직 디자인에서는 한 군데에서만 쓰이고 있다면은 이 toggle switch는 공용 컴포넌트로 만들어야 할까요, 아니면 feature 폴더 하위에 컴포넌트로 만들어두고 나중에 다른 페이지에서 쓸 경우 공용 컴포넌트로 옮겨야 할까요?
 
저는 디자이너에게 이 toggle switch를 다른 곳에서도 활용할 거냐고 물어본 뒤에 그렇다고 하면 공용으로 만들곤 했어요. 다른 관점에서라면 이렇게 물어보는 것이 비용이니 일단 일반 컴포넌트로 만드는 방법도 있겠죠.
 
3. 완벽보다 빠른 실행이 답이다.
처음에 토스가 송금 기능을 만들 때 php로 개발했다고 해요. 많은 유저를 대비한 코드는 아니었지만, 빠르게 기능을 개발해서 시장에 냈기 때문에 토스가 성장할 수 있었다고 합니다.
 
제가 지금 개발하고 있는 프로젝트도 디자인 시스템을 만들자고 얘기했는데, 아직은 만들 때가 아닌가? 싶기도 했어요.
 
 

언제나, 누구에게나, 평등하게 빠른 웹: 강현구 토스뱅크 Frontend Developer

 
접속하는 디바이스, 네트워크 환경에 따라 각기 다른 웹 경험을 하게 됩니다. 현구 님은 유저들에게 더 좋은 UX를 개선하기 위해 캐싱을 사용했다고 합니다.
 
디자인 시스템을 구현한 파일과 css에 버전을 부여하여 캐싱 무효화 전략을 가져갔다고 해요. 토스는 앱이다 보니 네이티브 앱을 사용해서 preload 가능해서 캐싱도 했다고 해요.
저도 지금 개발하고 있는 프로젝트가 프로그램 안에 웹뷰로 동작하고 있는데요, native 쪽도 생각해서 개발해 봐야겠다는 생각이 들었네요.
 
WIFI와 무제한 요금제인지를 확인해서 preload를 결정하는 세심한 방법도 좋았어요.
 
한편 이렇게 시스템을 구축하고, 수치로도 향상되었다는 것을 확인했지만 실제로 적용하지는 못했다고 해요. 토스에서는 하루에도 많은 배포가 발생하여 preload를 할 시간이 없었고요. 늘어난 CDN 요청으로 한 달에 5~6천 달러의 비용이 발생했다고 해요. 처음에 기술을 도입하기 전에, 실제 사용했을 때 비용은 얼마나 들 지, 사용이 가능한 기능인지 미리 검토하는 것도 필요하구나 느꼈어요.
 
아직 저는 캐싱을 제대로 해본 적이 없었는데 이번에 한 번 회사 실무에도 적용해 보면 좋겠다 생각이 들었습니다.
 
발표하신 내용처럼 Critical Rendering Path의 여러 단계별로 어떤 최적화를 할지 계획을 세워보는 것도 좋을 것 같습니다.
 

더 나은 UX를 위한 프론트엔드 전략: 강근우 한정원 토스뱅크

강근우 님과 한정원 님께서 개발하셨던 실제 사례로 어떻게 UX를 개선하셨는지 발표하셨어요.
 
SSR 잘 사용하기
최상단 영역의 계좌 잔액만 SSR로 데이터를 fetch 하셨는데 이유는 이러했습니다.
1. 잔액이 사람들이 가장 필요로 하는 데이터다.
2. 하단의 거래 내역은 조금 늦게 보여줘도 괜찮다.
3. 거래 내역 데이터가 크면 응답이 느려지므로 SSR을 사용할 경우 첫 페이지 렌더링이 느려질 수 있다.
 
CSR 개선
거래 내역을 로컬 스토리지에 저장하여 캐싱했어요.
첫 진입하면 거래 내역을 렌더링 하며 로컬 스트리지에 저장합니다.
두 번째 진입하면 로컬 스토리지에 캐싱한 거래 내역으로 렌더링 합니다. 이후 API 호출하여 최신 데이터를 UI와 로컬 스토리지에 저장해요.
=> 로컬 스토리지에 저장하는 것은 새로고침 하더라도 유지되도록 하는 방법으로 생각했는데, 이런 식으로 캐싱하는 데도 활용해 봐야겠습니다.
 
미사용 의존성 제거, 용량이 큰 라이브러리는 더 가벼운 라이브러리로 대체, 같은 라이브러리이지만 버전이 다른 것을 정리하여 javascript 번들 사이즈를 줄였다고 합니다.
 
화면 안정성 개선
렌더링 되는 화면을 영상으로 찍고, 0.25배속으로 재생하면서 어디가 원인인지 알려주셨어요.
(0.25배 배속으로 보는 방법이 굉장히 좋은 것 같아요.)
 
잔액이 사라졌다가 보이는 이슈가 있었습니다.
나는 SSR에서 skeleton이나 height를 차지하면서 아무것도 보이지 않도록 하다가 최종 금액을 보여주면 되지 않을까 생각했는데
토스에서는 0원에서 실제 잔액으로 늘어나는 애니메이션으로 해결하셨어요.
 
현업에서는 애니메이션은 항상 후순위로 작업하곤 했었는데
이렇게 애니메이션으로 문제를 해결하는 방법이 유저들에게 더 좋은 UX를 제공하니 좋을 것 같습니다.
나도 애니메이션으로 적용하는 것 고려해 봐야겠어요.
 
API waterfall 문제 해결
네트워크 타임라인으로 API waterfall 문제를 확인하여
Suspense와 Aggregation API(여러 API 호출을 하나의 API 호출로 묶는 것)를 도입하여 해결하셨다고 합니다.
 
발표 자료를 보니까 토스는 Frontend Web Vital을 모니터링하는 툴이 있던데
저도 이거 꼭 만들어보고 싶어요! (올해 목표 중 하나)
 

 

기술 중심 엔지니어에서, 조직 중심 엔지니어로: 진유림 토스 frontend developer

진유림 씨 영상은 이전에 여러 곳에서 봤는데, 너무 유익해서 꼭 듣고 싶었던 세미나였어요.
발표가 논리 정연하고, 마무리로 정리해 주는 것까지 좋아서 그런지 질문이 한 명도 없었어요. 발표 너무 잘하시더라고요.
 
유림 씨는 토스 비즈니스 통합팀에서 다른 팀들이 사용할 수 있는 툴을 만드는 일을 하셔요.
라이브러리를 잘 만들고, 문서까지 다 쓰고, 테스트 커버리지도 100%를 달성해서 사용해 달라 했지만 아무도 사용하지 않았다고 해요.
 
디자인 / 데이터 / 호스팅 으로 나누어 공통화하는 여러 가지 방법을 설명하셨어요.
 
기술 설명보다는 상대방이 원하는 것을 잘 알아야 해요.
상대방이 원하는 것은 미팅 자리보다는 커피를 마시거나, 지나가면서 말을 걸며 알게 되는 경우가 많다고 합니다.
정보를 캐는 것보다 그 사람을 이해하는 것이 중요합니다.
 
기술을 배제하고 가치 중심으로 얘기하는 방법도 설명하셨어요.
예를 들어, 이 기술을 도입하시면 트리 쉐이킹이 돼서 어쩌고 저쩌고 하는 것보다
"이걸 도입하시면 회원 가입율이 늘어나서 KPI 달성을 더 쉽게 하실 수 있어요" 식으로 말이에요.
 
이모지 기반 위키피디아를 만드셨어요.
슬랙에 특정 이모지를 달면 노션에 문서로 만들어줘요.
노션 AI 검색을 활용하면 쉽게 검색할 수 있어요.
이건 바로 도입해봐야겠다 싶었어요!
 
나도 공용 컴포넌트를 만들어 본 적이 있었어요.
다른 사람들이 사용하기 쉽도록 스토리북까지 만들었어요.
하지만 좀 더 적극적으로 사람들에게 알려줬나?
어떤 점에서 사용하기 좋은지 어필해 봤나? 싶었어요.
앞으로 공용 기능을 만들면 적극적으로 사용하는 사람들의 필요를 만족해 줄 수 있도록 만들어 봐야겠습니다.
 
 

송범근 씨의 "뛰어난 개발자가 되려면 기술을, 뛰어난 개발팀이 되려면 사람을"라는 강연이었는데 중간에 들어가서 다 못 들었어요. 엔지니어이더라도 결국 그 사람의 감정을 잘 이해해야 협업을 잘할 수 있다는 내용이었어요.  꽤 흥미로웠는데 나중에 영상으로 올려주면 다시 들어봐야겠어요.
 

토스증권 김광훈 씨의 "‘주식 모으기’ 서비스로 살펴보는, 대용량 트래픽 처리 노하우" 세미나였는데 말이 너무 빠르셔서 랩 하시는 줄 알았어요ㅎㅎ
장 시작할 때 거래량이 가장 많아서 주식 모으기는 장 시작하고 15분 뒤에 매수하는 방식으로 간단하지만 굉장히 크게 개선했다고 해요.
소수점 단위로 매수하는 것을 다 모아서, 개인별로 매수를 요청하는 것이 아니라 종목별로 매수하도록 하여 크게 개선한 점이 인상적이었어요.
앞으로 토스증권은 해외 시장에도 진출한다고 하는데 기대됩니다.
미국 증권보다는 환전이 필요한 미국 이외 나라에서 활약하기에 좋지 않을까? 싶어요.
 

개발자 권태기, 10년 동안 이렇게 이겨냈습니다: 자기 동기부여 실전팁: 김신 토스 Server Developer

이 강의가 가장 와닿았는데 사진을 못 찍었네요.
 
Flow
심리학자 Mihaly Csikszentmihalyi는 Flow라는 개념을 만들었다고 해요.
Flow란 "어떤 활동에 몰입해서 시간 가는 줄 모르는 상태"라고 합니다.
일상에서 Flow 경험을 자주 할수록 더 깊은 만족감과 행복을 느낍니다.
여러분들도 일상, 취미, 업무 중에 Flow를 경험해 보신 적이 있었을 거예요.
 
업무 중에 Flow를 경험하려면 어떻게 해야 할까요?
 
1. 명확한 목표
매일 작은 목표를 세워보면 좋아요.
매일 아침, 오늘 안에 완료할 작은 일을 정해서 해보는 거죠.
예를 들어, 오늘은 이 버그는 꼭 마무리하겠다. 그러면 이 일을 해내면 하루를 잘 보냈다는 생각을 할 수 있어요.
 
2. 적당한 난이도의 과업
매일 비슷하거나 쉬운 업무를 하는 게 힘들다면, 나만의 미션을 추가해 봐요.
예를 들어, 코드 개발하기 전에 리팩토링을 먼저 해본다든지요.
 
3. 행동에 대한 즉각적인 피드백
김신 님은 코드를 배포하여 PRD에서 잘 동작하는 것만큼의 피드백이 없다고 생각하신대요.
그래서 당일 작성한 코드는 당일 배포한다고 합니다.
(하루 만에 설계, 코드리뷰, QA까지 다 받나 봐요.. ㄷㄷ)
 
일할 동기를 상실했을 때, 내재적 동기를 키우자
그림을 재미로 그리는 아이가 있어요.
부모님이 그림을 그리면 용돈을 주기 시작해요.
용돈을 끊으면 아이는 그림을 계속 그릴까요?
재미있어서 시작한 일에 돈과 명예가 주어지면 재미가 사라지는 마법
이걸 과잉 정당화 효과라고 해요.
 
내가 왜 일을 하는가 생각해 보면
결국 "돈" 때문이라고 생각하게 돼요.
이 업무로 연봉을 올릴 수 있을까, 이직에 도움이 될까 고민하게 되죠.
코딩 자체에 대한 즐거움이 사라져요.
하지만 이런 외재적인 동기(돈, 명예)만으로 지속할 수 있을까요?
돈과 명예는 유한하고, 욕심은 끝이 없기 때문에 지속하기 힘들어요. 언젠가 일이 싫어질 수밖에 없어요.
 
일을 즐겁게 하기 위해서는 "내재적 동기"를 잘 유지해야 해요.
내재적 동기란, 업무를 할 때의 재미, 내가 하는 일의 의미, 성장의 욕구 등이 있어요.
처음 개발자가 되기로 결심했을 때, 코딩을 할 때, 나만의 무언가를 만들었을 때, 다른 사람들에게 가치를 제공했을 때의 즐거움을 떠올려보는 거예요.
 
자기결정성 이론에 따르면 내재적 동기를 높이기 위한 3가지 방법이 있다고 해요.
1. 자율성: 내가 선택하고 결정할 수 있어야 해요.
내가 만약에 관리자라면, 팀원들에게 결정할 수 있는 permission을 드리면 좋겠죠.
 
2. 유능감: 나는 일을 잘한다는 느낌이에요.
김신 님은 얕게 알던 기술을 공부하고 실제로 적용해 보면 이런 기분을 느낄 수 있었다고 해요.
 
3. 관계성: 주변 사람들과 연결되어 있다는 기분이 들어야 해요.
사람들과 함께하는 환경이 중요해요.
기술적인 고민을 공유하거나, 스터디, 세미나를 하는 식으로요.
 
번아웃을 해결하는 방법, 좋은 수면 위생
장시간 스트레스가 쌓여서 에너지가 고갈된 상태예요.
핵심은 스트레스 관리를 잘해야 해요.
그 방법은 여러분도 아시는, 숙면이에요.
 
1. 주말 기상 시간과 주중 기상 시간을 똑같이 하기
2. 잠자리에서는 잠만 자기
김신 님께서는 침대에서 핸드폰 하고 싶으면 방바닥에서 하신다고 해요.
3. 침실 서늘하게 유지하기
 
대한수면학회에도 좋은 자료가 많다는데 참고하면 좋을 것 같아요.

 

토스 2025 Maekrs 컨퍼런스 후기

1. 실패를 통해서 배우는 문화
오프닝 세션 때 토스 CTO 이형석 님께서 하셨던 말 중에 토스는 "실패를 통해서 배우는 문화"가 있다고 하셨어요.
이정행 님이나 강현구 님도 실패를 통해서 어떤 점들을 배웠는지 발표하셨고요.
완벽보다 빠른 실행을 하고, 실패하더라도 부족했던 점을 배우고, 성장한 경험을 주변 사람들에게 공유하여
실수를 재발하는 것을 막고, 더 효율적으로 나은 방향으로 나아가려는 모습이 좋아 보였어요.
 
나는 개발을 하면서 어떤 실패를 했었나
더 나아가 지금까지의 내 삶에서 어떤 실패를 했었나를
생각해 보게 되는 좋은 계기였어요.
(이건 다음에 따로 배웠던 점들을 정리해 보면 좋을 것 같네요)
 
제가 다니는 회사에서는 최근 서비스가 커지는 과정에서
장애가 발생했을 때 빠르게 대처하지 못했던 경험이 있었는데요,
개발자 세션에서 이 주제로 다 같이 토론해서
이제 빠르게 발견하고, 누구나 장애를 선언할 수 있다는 것을 인지하고, 빠르게 대응할 수 있게 개선이 되었어요.
 
저도 제가 실패했던 것을 부끄러워하지 않으며
더 좋은 개발자, 더 좋은 사람이 되기 위해 노력해봐야겠습니다.
 
2. 소프트 세션 강의들이 와닿는 게 많았어요.
어떻게 즐겁게 일할 수 있는지
회사와 팀에 더 기여할 수 있는 방법이 무엇인지에 대한 세션들이
흥미롭게 느껴졌어요.
 
인생의 1/3 이상의 시간 동안 일을 하잖아요.
앞으로도 즐겁고 행복하게 일할 수 있도록 노력해봐야 겠습니다.
 
3. 나도 발표해보고 싶다.
어떤 분께서 이번 토스 발표로 받는 돈도 없는데 (무급이었어요..!)
자원해서 발표를 하셨대요.
발표를 준비하면서 얻는 motivation이 있으시대요.
저도 회사에서 거창한 주제가 아니더라도
한 번 발표해보고 싶은 욕심이 생겼습니다.
 
4. 아쉬웠던 점
어떤 세션은 사례 없이 개념적으로만 설명해 주시는 발표가 있었는데요,
저뿐만 아니라 다른 참여자분들도 이해가 힘들었어요.
누군가에게 설명을 할 때 예시를 드는 게 훨씬 좋구나 알 수 있었어요.
 
갑자기 뜬금없지만 제가 다니는 회사에서 프론트엔드 개발자를 뽑고 있어요 ㅎㅎ
AI로 사운드와 관련한 TTS, voice conversion 등의 서비스를 크리에이터에게 제공하는 플랫폼을 만들고 있어요.
혹시 함께 일하고 싶으신 분은 아래 링크에서 지원 부탁드려요!
https://careers.hybecorp.com/ko/o/121209

[SUPERTONE] Frontend 개발