hexagonal-architecture

당근페이 백엔드 아키텍처가 걸어온 여정. Money라는 하나의 작은 프로젝트부터 수십 개의 서비스를 하나의… | by Jeremy | 당근 테크 블로그 | Jan, 2026 | Medium (새 탭에서 열림)

당근페이 백엔드 아키텍처는 서비스의 급격한 성장과 조직의 확장에 발맞춰 계층형, 헥사고날, 그리고 클린 아키텍처 기반의 모노레포 형태로 끊임없이 진화해 왔습니다. 초기에는 빠른 기능 출시를 위해 단순한 구조를 채택했으나, 비즈니스 복잡도가 증가함에 따라 의존성 관리와 코드 응집도를 높이기 위해 구조적 제약을 강화하는 방향으로 발전했습니다. 결과적으로 아키텍처는 기술적 부채를 해결하는 수단을 넘어, 대규모 팀이 협업하며 지속 가능한 성장을 이뤄낼 수 있는 기반이 되었습니다. ### 초기 성장을 견인한 계층형 아키텍처 (Layered Architecture) * **빠른 실행력 중심:** 2021년 당근페이 출시 초기, 송금 서비스의 신속한 시장 진입을 위해 `Controller-Service-Repository`로 이어지는 직관적인 3계층 구조를 사용했습니다. * **성장통의 발생:** 서비스가 커지면서 송금, 프로모션, FDS 등 다양한 기능이 하나의 계층에 뒤섞였고, 서비스 간 순환 참조와 강한 결합이 발생해 코드 변경의 영향 범위를 예측하기 어려워졌습니다. * **기술 부채의 축적:** 모든 비즈니스 로직에 프레임워크 기술(Spring)이 깊숙이 침투하면서 테스트 작성이 까다로워지고, 순수 도메인 로직만 분리해 관리하기 어려운 구조적 한계에 직면했습니다. ### 구조적 제약을 통한 응집도 향상 (Hexagonal Architecture) * **외부 구현과의 분리:** 도메인 규칙을 중심에 두고 UI, DB, 외부 API 등 인프라 영역을 포트와 어댑터를 통해 분리하여 프레임워크에 의존하지 않는 POJO 중심의 설계를 지향했습니다. * **모듈 역할의 세분화:** 프로젝트를 핵심 규칙을 담은 `domain`, 사용자 시나리오 단위의 `usecase`, 실제 입출력을 담당하는 `adapter` 모듈로 재구성하여 의존성 방향을 한곳으로 모았습니다. * **재사용성과 테스트 용이성:** 유스케이스 단위로 로직이 응집되면서 REST API뿐만 아니라 이벤트 컨슈머, 배치 잡 등 다양한 진입점에서 동일한 비즈니스 로직을 안전하게 재사용할 수 있게 되었습니다. ### 규모 확장에 대응하는 클린 아키텍처와 모노레포 * **모노레포 도입의 배경:** 머니, 포인트, 빌링 등 도메인이 늘어남에 따라 여러 저장소를 관리하는 비용이 증가했고, 이를 효율적으로 통합 관리하기 위해 하나의 저장소에서 여러 서비스를 운영하는 모노레포 구조를 채택했습니다. * **계약 기반의 모듈 분리:** 각 도메인을 `contract(인터페이스)`와 `impl(구현체)` 모듈로 쪼개어 의존성 규칙을 강제했습니다. 다른 모듈은 `contract`만 참조하게 하여 불필요한 내부 구현 노출을 차단했습니다. * **빌드 성능 및 생산성 최적화:** Gradle의 `api`와 `implementation` 구성을 활용해 컴파일 시점의 의존성을 제어함으로써, 대규모 프로젝트임에도 불구하고 빌드 시간을 단축하고 변경 영향도를 최소화했습니다. 아키텍처에는 정답이 없으며, 조직의 규모와 비즈니스의 현재 단계에 가장 적합한 형태를 선택하는 것이 중요합니다. 당근페이의 사례처럼 초기에 과도한 설계를 지양하되, 서비스 성장 속도에 맞춰 구조적 제약을 단계적으로 도입함으로써 기술 부채를 통제하고 개발 생산성을 유지하는 전략을 권장합니다.

AI TOP 100이 우리에게 남긴 것들 - tech.kakao.com (새 탭에서 열림)

카카오의 'AI Native 전략 팀'은 단 2주라는 물리적으로 불가능해 보이는 일정 속에서 AI를 극한으로 활용해 'AI TOP 100' 경진대회 시스템을 성공적으로 구축했습니다. 이번 프로젝트는 단순한 도구 도입을 넘어 기획서를 AI 프로토타입으로 대체하고 개발의 99%를 AI에게 위임하는 등 소프트웨어 개발 패러다임의 근본적인 전환을 증명했습니다. 결국 AI는 개발자를 대체하는 것이 아니라, 개발자가 더 높은 차원의 의사결정과 설계에 집중할 수 있도록 능력을 확장하는 강력한 파트너임을 확인시켜 주었습니다. **전통적 방법론을 탈피한 AI 네이티브 전략** * **물리적 한계 돌파:** 기획부터 배포까지 통상 수개월이 걸리는 공정을 예선과 본선 각각 2주라는 초단기 일정으로 단축하기 위해 AI 정면 돌파를 선택했습니다. * **기획서 없는 개발:** 상세 기획서나 화면 설계서 대신, 멤버 전원이 AI로 실제 작동하는 프로토타입을 제작하여 이를 바탕으로 요구사항을 확정하는 '초고속 프로토타이핑' 방식을 도입했습니다. * **PoC 중심의 애자일:** 추상적인 컨셉을 AI에게 던져 즉시 작동 가능한 PoC(Proof of Concept) 코드를 생성하고, 이를 검증하며 기능을 확정하는 '구현-피드백-전환' 사이클을 극단적으로 짧게 가져갔습니다. **AI와 개발자의 협업 모델 변화** * **99%의 코드 위임:** Cursor와 Claude Code 등을 활용하여 전체 코드의 대부분을 AI가 작성하게 했으며, 개발자는 직접 타이핑하는 대신 AI에게 의도를 설명하고 결과물을 검토하는 역할에 집중했습니다. * **압도적인 생산성:** 한 명의 개발자가 예선과 본선의 모든 프론트엔드 화면을 전담하거나, 하루에 2억 개의 토큰을 소모하며 시스템을 구축하는 등 기존 개발 방식으로는 불가능한 퍼포먼스를 기록했습니다. * **직무 경계의 확장:** 데이터 엔지니어가 백엔드 개발을 수행하고, 비개발자가 AI로 복잡한 알고리즘 문제를 해결하는 등 AI를 통해 개인의 기술적 한계를 넘어선 역할 수행이 가능해졌습니다. **기술적 난제와 인간의 역할(The Last Mile)** * **모델 간 논리 충돌:** AI가 제시하는 논리가 매우 탄탄하여 구성원 간 의견이 대립할 때, 최종적인 유지보수성과 시스템의 방향성을 고려해 최적의 답을 선택하는 것은 결국 시니어 개발자의 '경험'이었습니다. * **최종 의사결정의 주체:** AI는 수많은 해결책과 초안을 제시할 수 있지만, 해당 서비스의 특수성과 미래 가치를 판단하여 방향키를 쥐는 것은 여전히 사람의 몫임을 재확인했습니다. * **새로운 개발 표준의 정립:** AI 페어 프로그래밍이 일상화되면서, 개발자의 사고 흐름이 '선형적 구현'에서 'AI와 실시간 아이디에이션 및 즉각적 검증'으로 재편되었습니다. **실용적인 결론 및 제언** 미래의 개발 경쟁력은 AI를 단순한 보조 도구로 쓰는 것을 넘어, 업무 프로세스 전체를 AI 중심으로 재설계하는 'AI 네이티브' 역량에 달려 있습니다. 이제 개발자는 바닥부터 코드를 짜는 시간보다 AI가 생성한 결과물의 적합성을 판단하고 아키텍처 관점에서 통합하는 능력을 키워야 합니다. 'PoC 중심 개발'을 통해 불확실성을 속도로 돌파하는 경험을 쌓는 것이 새로운 개발 표준에 적응하는 핵심이 될 것입니다.