당근페이 백엔드 아키텍처의 진화: Layered -> Hexagonal -> Clean Architecture & Monorepo

아키텍처 변화의 배경

• 초기 당근페이 백엔드는 Money라는 단일 프로젝트에서 출발하여 수십 개의 서비스로 확장되었습니다.
• 서비스 성장과 함께 코드베이스의 복잡도가 증가하며, 새로운 기능 추가 시 의존성 관리 및 영향 범위 예측이 어려워졌습니다.
• 지속 가능한 개발과 빠른 비즈니스 요구사항 대응을 위해 아키텍처 진화의 필요성이 대두되었습니다.

1. Layered Architecture (2021년)

• 특징: Controller-Service-Repository 구조의 단순하고 직관적인 계층형 아키텍처.
• 장점: 빠른 기능 개발 및 실험 용이.
• 문제점: Service 계층 간 불분명한 의존성, 복잡한 호출 스파게티화, 높은 변경 취약성, 테스트 및 리팩터링의 어려움.

2. Hexagonal Architecture (Money 2.0)

• 목표: 계층 간 응집도 향상, 결합도 감소, 구현 기술과 독립적인 비즈니스 로직 작성 기반 마련.
• 구조: Domain (핵심 규칙), Usecase (사용자 시나리오), Adapter (외부 구현) 모듈로 분리.
• 의존성 규칙: Domain → Usecase → Adapter 방향으로 단방향 의존성 강제.
• 전환 전략: Strangler Fig Pattern 및 Feature Toggle을 활용한 점진적 전환.
• 효과: 비즈니스 로직과 기술적 세부사항 분리, 모듈 간 결합도 감소, 유지보수성 및 테스트 용이성 확보.

3. Clean Architecture & Monorepo

• 배경: Hexagonal Architecture의 도메인 간 관심사 분리 부족 문제 해결.
• 목표: 도메인 모듈화, 의존성 역전, 확장성 및 유지보수성 향상, 배포 독립성 확보, 테스트 용이성 증대.
• 기본 아키텍처: The Dependency Rule 기반으로 고수준 모듈이 저수준 모듈에 의존하지 않도록 설계.
• 프로젝트 모듈 구조: Bootstrap, Core, Infrastructure, Library, Platform, Usecase 여섯 개 모듈로 구성.

Clean Architecture & Monorepo 적용 이후 성과

• Hexagonal Architecture 문제 해결: 도메인별 모듈 분리 및 관심사 명확화, 서비스별 독립적인 배포 가능.
• 비즈니스 임팩트 가속화: 빠른 피드백 루프 유지, 작은 실험과 잦은 릴리즈 지원.
• 기술적 성숙도 향상: 일관된 시스템 구축, 모노레포 내에서의 표준화된 개선 작업, 자동화된 릴리즈 및 장애 대응.
• 엔지니어링 역량 성장: 코드 리뷰 활성화, 설계 의도 공유, 공통의 엔지니어링 기준 수립 및 확산.

회고 및 결론

• 모노레포는 팀의 '함께 보고, 함께 고치고, 함께 책임지는' 문화를 강화했으나, 빌드 속도 및 인지 부하 등의 과제 존재.
• 모노레포가 항상 정답은 아니며, 현재 팀의 문제 해결에 가장 적합한 도구를 선택하는 것이 중요.
• 지속적인 변화와 개선을 통해 금융 서비스의 안정성과 비즈니스 성장을 추구.