안녕하세요 2
박서진
• 토스 Frontend Chapter Lead
• Client Platform
• 비대면 계좌개설, 환전, 카드 맞춤추천,
내 부동산 시세 조회, 카드값 돌려받기…
• GitHub @raon0211
Slide 3
Slide 3 text
토스 3
• 누적 가입자 1,500만, 월 활성 사용자(MAU) 1,000만
• 대표적인 대한민국 금융 애플리케이션
• 어려운 금융을 쉽고 간편하게 (Make Finance Casual)
Slide 4
Slide 4 text
토스에서도웹프론트엔드개발이필요한가요? 4
Slide 5
Slide 5 text
토스에서도웹프론트엔드개발이필요한가요? 5
네.
많이 필요합니다.
Slide 6
Slide 6 text
애자일 개발 방법론 6
애자일
가설 수립
개발
릴리스 계속 반복
Slide 7
Slide 7 text
애자일 개발 방법론 7
애자일
가설 수립
개발
릴리스 계속 반복
: 월 금
수
화 목
Slide 8
Slide 8 text
애자일 개발 방법론 8
: 월 금
수
화 목
1주
Slide 9
Slide 9 text
애자일 개발을 가로막는 어려움 9
심사가 필요합니다.
또 업데이트해요?
Slide 10
Slide 10 text
웹 애플리케이션의 장점
• 365일 24시간 자유로운 배포와 롤백
• 모든 사용자가 최신 버전을 사용
• 빠른 버그 픽스
• 빠른 사용자 반응
10
Slide 11
Slide 11 text
11
“앱 안에서 웹뷰로
빠르게 서비스를 개발해보자!”
Slide 12
Slide 12 text
Frontend Chapter 12
Slide 13
Slide 13 text
토스의 웹 프론트엔드 제품들 13
Slide 14
Slide 14 text
토스의 웹 프론트엔드 제품들 14
30+
웹 프론트엔드 서비스 수
Slide 15
Slide 15 text
대표적인 웹 제품 화면들 15
Slide 16
Slide 16 text
16
많은 수의 서비스를 관리하기 위한
첫 번째 아키텍처 — 모놀리식 (Monolithic)
Slide 17
Slide 17 text
모놀리식? 17
Slide 18
Slide 18 text
모놀리식 = 거대한 탑 18
Slide 19
Slide 19 text
한 패키지 안에 여러 개의 서비스 19
Slide 20
Slide 20 text
모놀리식 아키텍처가 좋은 점 20
• 공통되는 코드를 자유롭게 공유
• 사용하는 라이브러리의 버전을 손쉽게 통일
• 비용 없이 새로운 서비스 구축
• 서비스 관리 비용 절감
Slide 21
Slide 21 text
모놀리식 아키텍처가 별로인 점 21
• 천년만년 걸리는 빌드 시간
• 하나의 서비스 변경사항이 다른 서비스까지 영향을 미칠 수 있음
• 서비스별 배포를 할 수 없음
• 서비스별 캐싱 정책을 가져가기 어려움
Slide 22
Slide 22 text
토스의 목적 조직 — ‘사일로’ 22
S lo
Frontend
Backend
Des gner
Product Owner
S lo
Frontend
Backend
Des gner
Product Owner
S lo
Frontend
Backend
Des gner
Product Owner
o
end
end
ner
Owner
Chapter
Slide 23
Slide 23 text
S lo
Frontend
Backend
Des gner
Product Owner
S lo
Frontend
Backend
Des gner
Product Owner
S lo
Frontend
Backend
Des gner
Product Owner
o
end
end
ner
Owner
Chapter
토스의 목적 조직 — ‘사일로’ 23
Slide 24
Slide 24 text
사일로마다 다른 제품 경험 24
PC 대응 복잡한 상태 관리
모바일 웹앱
대출 맞춤추천 행운퀴즈 카드값 돌려받기
Slide 25
Slide 25 text
25
많은 수의 서비스를 관리하기 위한
두번째 아키텍처 —
마이크로서비스 (Microservice)
Slide 26
Slide 26 text
모놀리식 아키텍처 되돌아보기 26
Slide 27
Slide 27 text
한 패키지에 하나의 서비스 27
Slide 28
Slide 28 text
쪼개진 패키지, 자유로운 의존성 선택 28
Redux, Redux-Observable, RxJS
MobX, Storybook
PC 최적화, 다양한 브라우저에 대응
Slide 29
Slide 29 text
빌드 시간의 획기적인 감소 29
20+࠙
모놀리식 아키텍처에서 빌드 시간
Slide 30
Slide 30 text
빌드 시간의 획기적인 감소 30
2~3࠙
작은 서비스의 빌드 시간
Slide 31
Slide 31 text
그 외 좋은 점 31
• 하나의 서비스 변경사항은 다른 서비스에 영향을 미칠 수 없음
• 서비스별 배포를 할 수 있음
• 서비스별 캐싱 정책이 자연스럽게 적용됨
Slide 32
Slide 32 text
레포지토리가 쪼개진다면
예상되었던 어려움
32
• 공통 코드를 공유하기 어려움
• 사용하는 라이브러리의 버전 파편화
• 새로운 서비스 구축에 큰 비용
• 서비스 관리가 복잡해짐
Slide 33
Slide 33 text
이렇게 된 이상
모노레포로 간다!
Slide 34
Slide 34 text
모노레포 (Monorepo) 34
• 하나의 Git 레포지토리, 여러 패키지
• 하나의 레포지토리 안에서
모든 서비스와 라이브러리가 관리됨