토스의 마이크로프론트엔드 아키텍처, 그리고 자동화

2019년 12월 4일 수요일, wanted 프론트엔드 개발자 밋업에서.

Transcript

1. 토스의 마이크로프론트엔드 아키텍처, 그리고 자동화 박서진 <raon0211@toss.im>
2. 안녕하세요 2 박서진 • 토스 Frontend Chapter Lead • Client Platform • 비대면 계좌개설, 환전, 카드 맞춤추천,
 내 부동산 시세 조회, 카드값 돌려받기… • GitHub @raon0211
3. 토스 3 • 누적 가입자 1,500만, 월 활성 사용자(MAU) 1,000만 • 대표적인 대한민국 금융 애플리케이션 • 어려운 금융을 쉽고 간편하게 (Make Finance Casual)
4. 토스에서도웹프론트엔드개발이필요한가요? 4
5. 토스에서도웹프론트엔드개발이필요한가요? 5 네. 많이 필요합니다.
6. 애자일 개발 방법론 6 애자일 가설 수립 개발 릴리스 계속 반복
7. 애자일 개발 방법론 7 애자일 가설 수립 개발 릴리스 계속 반복 : 월 금 수 화 목
8. 애자일 개발 방법론 8 : 월 금 수 화 목 1주
9. 애자일 개발을 가로막는 어려움 9 심사가 필요합니다. 또 업데이트해요?
10. 웹 애플리케이션의 장점 • 365일 24시간 자유로운 배포와 롤백 • 모든 사용자가 최신 버전을 사용 • 빠른 버그 픽스 • 빠른 사용자 반응 10
11. 11 “앱 안에서 웹뷰로 빠르게 서비스를 개발해보자!”
12. Frontend Chapter 12
13. 토스의 웹 프론트엔드 제품들 13
14. 토스의 웹 프론트엔드 제품들 14 30+ 웹 프론트엔드 서비스 수
15. 대표적인 웹 제품 화면들 15
16. 16 많은 수의 서비스를 관리하기 위한 첫 번째 아키텍처 — 모놀리식 (Monolithic)
17. 모놀리식? 17
18. 모놀리식 = 거대한 탑 18
19. 한 패키지 안에 여러 개의 서비스 19
20. 모놀리식 아키텍처가 좋은 점 20 • 공통되는 코드를 자유롭게 공유 • 사용하는 라이브러리의 버전을 손쉽게 통일 • 비용 없이 새로운 서비스 구축 • 서비스 관리 비용 절감
21. 모놀리식 아키텍처가 별로인 점 21 • 천년만년 걸리는 빌드 시간 • 하나의 서비스 변경사항이 다른 서비스까지 영향을 미칠 수 있음 • 서비스별 배포를 할 수 없음 • 서비스별 캐싱 정책을 가져가기 어려움
22. 토스의 목적 조직 — ‘사일로’ 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
23. 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
24. 사일로마다 다른 제품 경험 24 PC 대응 복잡한 상태 관리 모바일 웹앱 대출 맞춤추천 행운퀴즈 카드값 돌려받기
25. 25 많은 수의 서비스를 관리하기 위한 두번째 아키텍처 —
 마이크로서비스 (Microservice)
26. 모놀리식 아키텍처 되돌아보기 26
27. 한 패키지에 하나의 서비스 27
28. 쪼개진 패키지, 자유로운 의존성 선택 28 Redux, Redux-Observable, RxJS MobX, Storybook PC 최적화, 다양한 브라우저에 대응
29. 빌드 시간의 획기적인 감소 29 20+࠙ 모놀리식 아키텍처에서 빌드 시간
30. 빌드 시간의 획기적인 감소 30 2~3࠙ 작은 서비스의 빌드 시간
31. 그 외 좋은 점 31 • 하나의 서비스 변경사항은 다른 서비스에 영향을 미칠 수 없음 • 서비스별 배포를 할 수 있음 • 서비스별 캐싱 정책이 자연스럽게 적용됨
32. 레포지토리가 쪼개진다면 예상되었던 어려움 32 • 공통 코드를 공유하기 어려움 • 사용하는 라이브러리의 버전 파편화 • 새로운 서비스 구축에 큰 비용 • 서비스 관리가 복잡해짐
33. 이렇게 된 이상 모노레포로 간다!
34. 모노레포 (Monorepo) 34 • 하나의 Git 레포지토리, 여러 패키지 • 하나의 레포지토리 안에서
 모든 서비스와 라이브러리가 관리됨
35. 모노레포 — 예시 35 toss-frontend (모노레포) libraries services
36. 모노레포 — 예시 36 libraries 컴포넌트 라이브러리 타입 정의 라이브러리 ESLint 등 설정 라이브러리 services
37. 실제 toss-frontend 모노레포 37
38. 만보기 웹앱 카드추천 웹앱 비대면 계좌개설 웹앱 부동산 웹앱
39. 설정의 간편한 공유 39 module.exports = { extends: [' ../ ../.eslintrc.service.js'], }; .eslintrc.js tsconfig.json { "extends": " ../ ../tsconfig.service.json", }
40. 코드와 이슈 관리 지점 일원화 • 모든 코드와 이슈가 한 레포지토리에 집결 • 라이브러리와 서비스 배포는 이미 있는 인프라를 기반으로 • 코드나 이슈의 위치를 손쉽게 찾음 40
41. 명령어 한 줄로 끝나는 인프라 셋업 41 yarn new-service my-service yarn new-library my-library
42. 토스에서 라이브러리 만들기 42
43. 43 토스에서 
 신규 웹 서비스 만들기
44. 이슈봇 44
45. 사용자의 실수를 줄여주는 ESLint Rule 45
46. PR 종달새 46
47. CI۽ ੗زചػ ױ҅੸ ߓನ 47 자동 테스트 및
 타입 체크 스테이징
 배포 라이브
 단계적 배포 *사내 테스트
48. ஠աܻ ߓನ ੹ۚ 48 사용자 트래픽 로드 밸런서 다수 사용자 일부 사용자 기존 버전 신규 버전
49. ী۞ ݽפఠ݂җ ࡅܲ ܀ߔ 49
50. 토스에서 프론트엔드 개발자로
 일한다면? 1. 개발에 필요한 대부분의 환경이 갖춰져 있는 상태에서 2. 스타트업보다 애자일하게 일하면서 3. 제품 개발에만 집중할 수 있습니다. 50
51. 51 남은 숙제
52. ҕా ۄ੉࠳۞ܻ੄ ߡ੹ ౵ಞച 52 7, 8, 9 3.4, …, 3.7
53. 보다 효율적인 개발환경 53 Netlify “Deploy Preview” Pull Request 제출과 함께 개발 서버 셋업
54. 보다 효율적인 이슈hPR 관리 54
55. 55 감사합니다