Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

5492cd0d69eaf60f876834c8c8d1e217?s=47 Jin
December 04, 2019

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

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

5492cd0d69eaf60f876834c8c8d1e217?s=128

Jin

December 04, 2019
Tweet

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 감사합니다