당근페이 백엔드 아키텍처의 진화 여정

당근페이팀 백엔드는 작은 Money 프로젝트에서 시작해, 서비스 확장에 맞춰 세 차례 큰 구조 변화를 겪었다.

초기에는 Layered Architecture(Controller-Service-Repository)로 빠르게 송금 기능을 출시했지만, 기능과 팀이 커지면서 Service 간 의존이 얽히고 테스트와 리팩터링이 어려워졌다. 검증, 권한, 횡단 관심사까지 Service가 떠안으며 기술 부채가 누적됐다.

이를 해결하기 위해 Hexagonal Architecture를 도입해 domain, usecase, adapter로 분리했다.

• domain: 프레임워크에 의존하지 않는 핵심 규칙
• usecase: 송금, 충전, 환불 같은 사용자 시나리오
• adapter: DB, 메시지 브로커, 외부 API, Web/Batch/Admin 입출력

전환은 Strangler Fig Pattern과 Feature Toggle로 점진적으로 진행했다. 그 결과 비즈니스 로직이 기술 세부사항과 분리되고, 모듈 간 결합도가 낮아지면서 유지보수성과 테스트 용이성이 크게 개선됐다.

하지만 여러 도메인을 한 프로젝트에 담자 새로운 문제가 드러났다. Adapter 모듈에 배너, 포인트 등 수많은 구현체가 쌓였고, money-api를 배포해도 관계없는 서비스까지 함께 배포되는 구조가 됐다. 헥사고날만으로는 도메인 간 경계와 배포 독립성을 충분히 보장하지 못했다.

그래서 Clean Architecture를 바탕으로 한 Monorepo 구조로 다시 확장했다. 핵심 목표는 다음과 같았다.

• 도메인 모듈화와 도메인 간 의존성 명시
• 의존성 역전으로 구현 교체와 테스트를 쉽게 만들기
• 배포 독립성 확보
• 테스트 용이성 강화

새 구조는 bootstrap, core, infrastructure, library, platform, usecase 여섯 모듈로 정리됐다. 특히 core:{domain}:domain과 core:{domain}:data로 도메인을 분리하고, bootstrap에서 필요한 모듈만 조합해 서비스별 독립 배포가 가능해졌다.

이 변화는 단순한 구조 개편이 아니라 개발 속도와 운영 안정성을 동시에 끌어올리는 기반이 됐다. 코드 라인은 전년 대비 192% 증가했지만 빌드 체감 시간은 늘지 않았고, 릴리즈 리포팅과 런북 자동화까지 더해져 문제 해결과 엔지니어링 성숙도를 조직 전체로 확산시켰다.

결국 이 여정의 핵심은 하나였다. 서비스 성장에 맞춰 아키텍처도 함께 진화해야 하며, 팀의 현재 문제를 가장 잘 해결하는 구조를 선택해야 한다는 점이다.