[토스 컨퍼런스] TOSS MAKERS CONFERENCE 25 후기

세미나 정보

2025.07.25. 토스 메이커스 컨퍼런스 - 엔지니어링 데이 참가

 

참여 인증샷~

개요

CTO님이 토스 메이커스 컨퍼런스 25에 참석하지 못하는 팀원들을 위해 참석한 팀원들이 후기를 공유해 줄 것을 요청하셨고,

저도 정리해두면 나중에 보면서 오래 기억할 수 있어서 정리해봤어요!

 

토스 컨퍼런스 세션 목록 중 제가 다니는 회사의 현재 문제 상황에 실마리가 될 수 있는 세션을 골라서 들었어요

 

이 정리한 내용 바탕으로 엔지니어링 토크 때 앞에서 발표했어용

CTO님이 본인이 본 컨퍼런스 다녀온 사람 중 가장 열심히 듣고 자세히 정리한 사람이라고 칭찬해주심 (이거 극찬아닌교 유후)

지식 공유는 즐겁당

---

요약

[FE] 60개의 RN 패키지 - 하나의 프레임워크로

• 패키지들을 하나로 묶는 프레임워크를 만들어서 관리 (버전 이슈 최소화)
• https://github.com/toss/granite

[소프트] 생존형 엔지니어링

• 잘 아는 것을 선택하라
• 문제가 되기 전에는 해결하지 않는다
• 완벽보다 빠른 실행이 답

[ML] 비싼 GPU 낭비 없이 제대로 운영하는 방법

• gpu 사용 현황을 분석하고, 쉬운 반납을 유도하자

[FE] 더 나은 ux를 위한 프론트엔드 전략

• 랜더링 시 시프트 현상을 디자인적 요소로 해결
• api 과다 호출→ aggregation api 사용

[소프트] 뛰어난 개발자가 되려면 기술을, 뛰어난 개발팀이 되려면 사람을

• 심리적 안전감
• 우리가 더 좋은 소프트웨어, 더 좋은 제품을 만들기 위해서, 인간에 대한 이해, 사람의 감정에 대한 이해와 관심이 필요하다

[서버] 레거시 정산 개편기: 신규 시스템 투입 여정부터 대규모 배치 운영 노하우까지

• 레거시 - 정산 -> 신규 시스템 실패 시 레거시 결과로 지급 신규 - 정산
  -> // 두 값을 비교해서 정합성 검증 // 오랜 시간 문제 없으면 신규 시스템으로 교체

[Client] 로그 자동화로 생산성 혁신하기

• 반복되는 코드를 막고, 로그 신뢰도를 높이고, 개발 시간을 단축한다
  • android +31줄→+4줄 / ios +111줄→+3줄
• 어떤 팀에서든 로깅 분석 방식이 통일화된다

[FE] 누구나 작정하는 E2E 테스트를 향하여

• 사이드 프로젝트로 자체 e2e 테스트 플랫폼을 만듦
• 개발자 뿐 아니라 다른 포지션도 e2e 테스트를 만들어서 다함께 오너십을 가질 수 있음

---

필기

[FE] 60개의 RN 패키지 - 하나의 프레임워크로

참석 사유: RN 레포에 수많은 패키지가 엉켜있는 구조를 개선하는 데 도움이 될 것 같아서

토스 플랫폼: 김희철 개발자

• 기존 상황
  • n개의 패키지 → n개의 서비스 → 배포 (n*n의 관리복잡도)
  • 라이브러리가 거의 60~100개
  • 변경, 테스트에 대한 두려움이 있었음
• 어떻게 개선할 것인가
  • 프레임워크 단위로 묶어서 버전 관리
  • 각 패키지에 대한 버전 대응을 할 필요 없이 하나의 프레임워크 버전만 신경쓰면 됨
  • 공통인 것(로그 등)은 모두 프레임워크에 넣음
• e2e 테스트
  • 자동화 테스트를 통해 동작을 보장할 수 있어야 함
  • 테스트 원칙
    • 어떤 동작 제공? 꼭 필요한가?
  • 동작 관점으로 작성(기능, 회귀, 지속가능)
  • 기능 테스트
    • 어떤 기능을 제공하는지 문서처럼
    • 코드가 변경될 때 트리거
    • 리팩토링 시 지속 가능한 테스트 환경 제공
    • 명확한 역할 정의를 바탕으로 문서화가 쉬워짐
      • 테크니컬 라이터의 리뷰를 거쳐 문서 작성
• 버전 릴리즈
  • 프레임워크 업뎃 주기가 정해지니 우선순위가 명확해짐
• toss/granite
  • 튼튼한 기반, 패키지, 프레임워크 키워드를 바탕으로 화강암을 이름으로 지었음
  • https://github.com/toss/granite

GitHub - toss/granite: Enterprise-grade React Native framework for microservice apps. Brownfield friendly, 200KB bundles, AWS-re

 

https://www.youtube.com/watch?v=rtLaQbj_weM

 

---

[소프트] 생존형 엔지니어링

참석 사유: 주니어가 살아남기 위해 앞으로 엔지니어링에 어떤 태도를 지녀야 하는지 배우고 싶어서

토스 페이먼츠 - 이정행 개발자

 

비트윈(커플대상 모바일 서비스) 개발 후 엑싯(현재도 운영 중)

타다 개발 후 쏘카에 엑싯

 

잘 아는 것을 선택하라

• 어떤 툴을 선택할 것인가?
  • 현 상황에서 가장 잘 아는 툴을 선택하라
  • 팀 구성원이 익숙한 것을 선택하라
  • 대세를 따라 선택하는 것이 정답은 아니다
• 예시
  • 비트윈 서비스 초기 서버
    • java+netty 조합으로 api 서버 개발
    • 새로운 인원 채용을 고려했다면 좋은 선택 아님
    • 하지만 당시로서는 최선의 선택이었음
  • 비트윈 스티커 서비스 서버
    • python과 flask 선택(당시 파이썬 서버 붐이었음)
    • 팀 내에 잘 쓰는 사람이 없어서 실패
  • HBase를 선택
    • 쓰기가 많은 작업이니 괜찮을 것이다
    • 커뮤니티가 작아서 구글링해도 자료가 없음
    • 문제 파악에 시간이 걸려서 결국 서버 여러 개 띄워서 해결 (비용 이슈 생김)

 

문제가 되기 전에는 해결하지 않는다

• 미래에는 이런이런 기능이 필요할테니 거대한 구조를 처음부터 짜자
• 미래에는 더 좋은 구조가 나와서 필요 없어질지도 모름
• 나중에 추가 개발 시 오히려 확장성에서 문제가 생기고 병목이 될 수 있음
• 실행을 위해 모든 걸 미리 만들지는 말자

but! 처음부터 구조를 아예 고려하지 말자는 것 아님. 너무 먼 미래를 보지 말자는 뜻. 체계적인 기초 구조 설계는 매우 중요한 영역임.
"문제가 무엇인지 정의”하는 게 중요하다.

• 모든 걸 문제라고 치부해서는 안됨. 문제 해결보다 중요한 건 문제 정의이다.

 

완벽보다 빠른 실행이 답

• 숨은 관리 비용을 고려하자

 

https://www.youtube.com/watch?v=BEcktw3XYxY

 

---

[ML] 비싼 GPU 낭비 없이 제대로 운영하는 방법

참석 사유: 토스증권에 잠깐 같이 일했던 사수님들의 업무 내용을 더 이해하고 싶어서

토스증권 김진웅, 엄태규 ml 엔지니어

• 낭비(할당받고 다 쓰지 않는) gpu를 줄이자
• 현재 할당된 gpu들의 사용 현황을 먼저 파악
  • 배치형태의 ml - 실시간 증권 뉴스 긁어오기
    • 데이터 양이 항상 달라서 예측하기 어려움
    • 양이 적으면 배치 잡 시간이 적어서 점유시간이 짧지만, 반대일 경우엔 늘어남
    • 그래서 gpu 점유를 예측해서 빌리기 어려움
  • 그냥 빌리고 안쓰는 경우도 있음: 제일 문제
• 왜 이런 낭비가 발생하나?
  • 금융서비스 특성상 망분리 환경을 씀
    • 반납하기 매우 번거로움
    • 슬랙봇을 만들어서 반납/계속 사용 버튼 만들었더니
    • 이것만으로도 반납률이 증가함
• 도입 전후 비교 미사용시간 70% 개선
  • 도입전 6818분→1주 6375분→2주 2313분

 

https://www.youtube.com/watch?v=_g8hmmIL0EA

 

---

[FE] 더 나은 ux를 위한 프론트엔드 전략

참석 사유: 올팜의 유저 경험을 개선하기 위해 토스 뱅크의 사례를 적용해보면 어떨까 싶어서

토스뱅크 강근우, 한정원 개발자

 

강근우 개발자 - 토스뱅크 홈 화면 개선

• Next.js를 사용 중 → SSR을 잘 사용하자
  • 기존에는 생산성 우선해서 잘 해결되지 않았음
  • 그러나 ux를 위해 시간을 들여 개선이 필요하다고 어필
• 메인 홈 화면 로딩이 매끄럽지 못함
  • 상단→하단으로 순차적으로 뜨는 게 아니라 상→하→중간 이런식으로 뜸
• 무엇을 개선해야 하는가?
  • 유저는 상단 금액 표시 영역을 머저 인지함
  • 거래 내역 데이터가 많으면 서빙이 느려짐 (뚜둑 하고 표시되는 느낌)
  • 아이콘 랜더링이 뒤늦게 되면서 깜빡이는 것처럼 보임
• 어떻게 개선하는가?
  • api 응답→거래내역 로컬스토리지에 캐싱. 두번째 진입부터 빨라짐
    • 보안팀에 문제 없다는 답변 받았다고 함
  • 번들사이즈 다이어트: Webpack bundle analzer
    • 미사용 의존성 제거
    • 가벼운 라이브러리로 대체
    • 버전 1개만 남김
    • 관련 세션: slash21: javascript bundle diet
  • api waterfall - tanstack react query
    • suspense 비동기처리: fetching 중/ 완료 를 분리해서 처리
    • api를 병렬로 호출
  • 금액 영역 깜빡임
    • 하이드레이션 후 - 애니메이션 플레이 전의 갭 차이
    • 하이드레이션 전-후 자연스러운 움직임이 나오도록 디자인으로 해결
  • 송금 보내기 버튼 깜빡임
    • 송금가능 유저>불가능 유저: 더 많은 유저군 챙기는 쪽으로
    • 송금 버튼을 able - default 값으로
  • 광고배너 레이아웃 시프트
    • 광고배너 랜더링에 맞춰서 다른 영역도 애니메이션으로 넣음

 

한정원 개발자 - ‘내 토스뱅크’ 페이지 개선

• LCP 위주로 개선
• FCP(첫 화면) → LCP(로딩 끝났다고 느끼는 시점)

공룡 모양을 닮지 않았냐고 물어보심. 네?

• api 호출 이슈
  • 최적화되지 않은 api - 한 번에 3~40개의 api를 부름
  • 회색 delay 영역이 생기는 이유
    • 동시 요청이 6~8개 밖에 안됨
    • http queing이 발생함

 

• 어떻게 해결? aggregation api
  • 백엔드에서 통합해서 한 번에 내려주는 쪽으로 변경
  • server side fetching 실패 시 client에서 fetching
  • 로딩 속도 50% 개선
• 많은 실험이 나감 → LCP 영향
  • LCP 모니터링 자동화
  • 매주 LCP 성능체크 알림 시스템

 

https://www.youtube.com/watch?v=Q-_crvz4tv8

 

---

 

[소프트] 뛰어난 개발자가 되려면 기술을, 뛰어난 개발팀이 되려면 사람을

참석 사유: 현 회사의 엔지니어 개발자 경험을 향상시키고, 서로 힘이 될 수 있는 문화를 만들고 싶어서

틴뱅킹 송범근 ios 개발자

 

‘구글 엔지니어는 이렇게 일한다’ - 심리적 안전감

• 학습이 일어나고, 새로운 시도를 하게 되면서 생산성이 높아진다
• 무엇이 심리적 안전감을 만드는가?
  • 실수를 개인의 잘못으로 탓하지 않는다
    • 재발방지를 대응하는데 집중 “문제 해결에만 집중”
    • 빠르게 해결하고→재발 방지 논의
  • 나쁜 질문은 없다
    • 그것도 몰라요?(x) 나도 그땐 어려웠어요 (o)
  • 맥락 추가 질문
    • 왜 그렇게 생각했어요? 질문과 의견 제시를 촉진
    • 커뮤니케이션을 잘하는 개발자의 습관
• 결론
  • 우리가 일을 잘하기 위해서는 감정적인 이해도 중요하다
  • 오래된 뇌에서부터 나오는 본능이 이성적인 뇌의 행동을 결정한다
    • 인간은 원시시대부터 화합으로 살아남아왔음
    • 사회적 위협신호를 받는다면 무의식적으로 방어모드에 들어가고 시야가 좁아짐
• 기술적 안전망에 집중하는 경향이 있지만, 이는 심리적 안전감과 관계가 없을 수 없다
  • 같이 일하는 사람의 감정을 이해하자
  • 상대를 설득해보자

인상 깊어서 찍어놨던 문장

책 추천!

 

https://www.youtube.com/watch?v=Wh2bhWe56EM

 

---

[서버] 레거시 정산 개편기: 신규 시스템 투입 여정부터 대규모 배치 운영 노하우까지

참석 사유: 현 회사도 레거시 정산 시스템을 개선하고 있는데, 담당 스쿼드에 도움이 되는 지식을 전할 수 있을까 싶어서

토스페이먼츠 박진현, 강민주 개발자

 

레거시 시스템 왜 개선해야 했나?

• 비즈니스 로직이 쿼리에 종속
  • 수수료 계산>환전>계약조회>결제유형구분
  • 개발 유지 보수 비용이 많이 듦
  • 분할정복에 집중함
    • 수수료계산(정액, 정률)
    • 환전(고시환율,우대환율)
    • 결제유형(신용카드,체크카드)
• 데이터 모델링 한계
  • 정산 데이터 최소화
    • 실패건에 대해서만 재처리 요청해 복구비용 최소화
  • 조회 전용 데이터 설계
    • 실시간 데이터 집계시 조회 속도 낮아짐
    • 자주 조회하는 조건 바탕으로 테이블 구성
• 배치 시스템 성능 문제
  • 거래건수 늘어나면 처리시간 기하급수적으로 늘어남
  • i/o 처리 횟수 개선
  • single thread 한계 극복 → 병렬성 개선
    • 병렬로 처리하고 조합하는 방식 사용
    • %4 모듈러 연산 값에 따라 모아서 처리

그럼 이렇게 개선된 시스템을 확신하고 바로 적용할 수 있나?

• 기존과 동일하게 처리하고 있다는 확인이 필요
• 경우의 수를 모두 테스트해야 함
  • 결제수단, 할부여부,, 등등에 따라 n^n의 테스트 필요
  • test automation system
• 신규 시스템 투입 시: 빠른 시간 안에 이슈 복구가 가능한가?
  • 시스템 변화를 원자적으로 수행
  • 배치 레이어에서 카나리 투입

  레거시 - 정산 -> 신규 시스템 실패 시 레거시 결과로 지급
  신규  - 정산 -> 
  // 두 값을 비교해서 정합성 검증
  

  • 오랜 시간에도 문제가 발생하지 않는다면?
    • 신규 시스템으로 완전 교체

https://www.youtube.com/watch?v=Hb8QI5WyBJ4

 

---

[Client] 로그 자동화로 생산성 혁신하기

참석 사유: 현 회사의 로깅 시스템 효율화에 대한 아이디어를 얻고자

토스 유금상, 이윤지 개발자 (ios, aos 개발자)

"로그도 제품이다"

• 로그도 제품이다
• 아이템 선정-디자인-로그정의/개발-qa-로그qa-배포-지표 확인
• Data Operation Manager
  • 로그를 정의하고 데이터가 잘 입수되는지 모니터링 및 검증

기존 문제점

• 수동로그는 사람의 실수가 개입될 여지가 높음
• 로깅 정책이 서비스마다 파편화됨. 유사한 로직이 반복적으로 코드에 삽입됨
• 클라이언트 개발자 관점에서 비효율적이었음
• 로그 자동화/업무효율 - 로그 신뢰도

 

로그 자동화 시스템

• 로그 모듈이 내재화되어 있음/로그수집, 버퍼링,전송
  • 로그 자동화는 이 위에 자동화 규칙 추가
• 로그는 TDS(토스 디자인 시스템) 단위로 함

 

로그 자동화 시스템 구현

결과

• 로그 개발, 로그 qa 비용이 압도적으로 줄어듦
• 로그데이터 형식의 표준화
• 로그 신뢰도, 재사용성 증가
• 새로 생성되는 로그 70% 이상 자동로그, 74% 시간 절약
• 어떤 팀에서든 로깅 방식이 통일화 되어 분석 방식도 통일됨 → DA 업무 환경도 개선됨

• 반복되는 코드 줄 수 매우 줄어듦
  • android +31줄→+4줄
  • ios +111줄→+3줄

방향성

• 토스 글로벌 사용자들 - 로그 데이터에 여러 언어가 섞여들어옴
  • 이를 대응하는 로깅 시스템 개선
  • (현재는 개선된 상태)

---

[FE] 누구나 작정하는 E2E 테스트를 향하여

참석 사유: E2E 테스트 도입의 필요성을 설득하고자!
(현재는 신규 BE 개발자 분이 E2E 테스트 환경 구축 완료해서 도입 됨!!!!!!!끼얏호우)

토스 플랫폼 강민우 개발자

 

일단 보세요

사이드 프로젝트로 혼자 개발한 e2e 테스트 시스템인데 너무 경이로워서 사진으로 대체합니다.
이건 도입하고 싶다보단 어떻게 만들었지 개쩐다에 가까움

 

 

 

https://youtu.be/QUhjuz3NogA?si=JGdgWG5o2HMNw6R6&t=625

(시연 영상: 10분 25초부터... ㄹㅈㄷ goat)

 

 

 

---

 

회사 팀원들에게 공유하려고 노션에 작성했다가,

블로그에도 옮깁니다!

(팀원들에게 공유했던 시점은 2025.07.31 오후 4시 8분.이라 실제로는 작성한지 좀 된 글이네요)

 

토스 컨퍼런스는 갈 때마다 새로운 자극을 얻을 수 있어서 좋아용ㅎㅎ

 

작년에는 잘 모르기도 하고 그냥 끌리는 세션 들었는데,

올해는 목적 의식을 가지고 들으니 좀 더 몰입해서 듣고 필기도 많이 하고 질문도 많이 할 수 있었음

그리고 작년에 아무것도 모르는 학생 때랑 실무를 조금이라도 맛본 정규직 개발자일 때랑 들리는 귀 자체가 달랐음

이래서 실무 경험있는 사람을 뽑는구나 깨달음...

(작년: 우와 신기하다~, 올해: 맞아맞아 저거 문젠데 우리도 도입하고 고쳐야 되는데.........)

 

내년에도 토스 컨퍼런스 꼭 참가할 수 있기를 바라며...

 

작성: 2025.10.09. 00:25