영상: 토스ㅣSLASH 24 - 토스뱅크가 차세대를 하지 않는 이유: 지속 가능한 마이그레이션 전략

차세대 프로젝트

• 대규모 프로젝트를 개편하는 프로젝트
  • 변화하는 도메인 대응
  • 기술 부채 해결
• Waterfall 방법론
  • 단계별 진행 -> 유연성 부족
  • 변경 발생하면 전체에 영향
  • 모든 기능을 한번에 배포하여 리스크가 큼
  • 추가 요구사항 발생 -> 품질 및 완성도 저하

토스가 안전하게 전환하는 방법

Strangler Fig Pattern

• 기존 시스템을 점진적으로 새로운 시스템으로 대체하는 전략
• 리스크 최소화, 점진적 개선

사용 예시

• monolithis system을 여러개의 microservice로 전환 -> MSA 로 변환하는 것이 목적
• 기존 구현체 낮은 응집도, 높은 결합도 -> Use Case 단위로 독립적 구현

마이그레이션 사이클

1. 대상 선정
   • 리스크 관리 중심: 사이드 이펙트가 작은 기능부터 전환
   • 성장 중심: 복잡한 핵심 기능부터 전환
   • 고객 경험 중심: 고객에게 직접 영향을 미치는 기능부터 전환
2. 분석
   • 연역적 분석: 도메인 분석, 대전제 설정
   • 귀납적 분석: 기존 시스템 분석하여 대전제 검증 및 새로운 대전제 설정
     • 정적 분석: 관계를 분석하여 전체 시스템 파악
     • 동적 분석: 데이터 수집을 통해 기존 시스템 분석 및 추후 테스트 데이터로 활용
3. 설계
   • 분석 결과를 사용하여 설계 문서 작성 -> 설계 검증시 사용
   • 테스트 케이스 작성
   • 마이그레이션이 일회성 작업이 아니라 지속적인 관리 작업이기 때문에 문석 작성이 필요함
4. 구현
   • 버그가 아니라 기능입니다.
     • 한 모듈에서 버그가 발생하면 이 버그를 사용하는 모듈에서 버그를 고려한 로직을 작성
     • 이 때문에 첫 모듈의 버그를 수정하면 새로운 버그 발생
     • 연관된 모듈들을 분할 정복해야함: 컴포지트 패턴
5. 검증
   • alert
   • 성공하면 1단계로 돌아가 반복
   • 실패하면 2단계로 돌아가 반복
   • 모두 마이그레이션이 될때 까지 반복

콘웨이 법칙

시스템을 설계하는 조직은 어떤 조직이든 그 조직의 소통 구조를 닮은 구조를 가진 시스템으로 설계할 것이다 - 멜빈 콘웨이, 1967

느낀점

• 도메인이 변환하는 것은 시간의 흐름에 따라 필연적으로 발생함
• 마이그레이션도 기술 변환, 도메인 변화에 맞춰 당연히 필요해짐
• 시작점과 끝점을 정하고 과정은 생각하지 않고 도약을 하는 것이 아니라, 점진적으로 그 과정을 설계 해야함
• 건강한 조직이 건강한 시스템을 설계한다

#the-fullswing