| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- 그리디
- Spring
- 자바
- 그리디알고리즘
- 읽기쉬운코드
- framework
- API
- ES
- 애자일기법
- 코딩테스트
- 스프링
- 백준
- 클린코드
- kotlin
- Baekjoon
- 개발
- database
- 엘라스틱서치
- JPA
- 코딩
- 코드
- 개발자
- 데이터베이스
- spring boot
- Java
- 프레임워크
- Elasticsearch
- 애자일프로그래밍
- 알고리즘
- cleancode
- Today
- Total
튼튼발자 개발 성장기🏋️
당근페이 백엔드 아키텍처가 걸어온 여정을 읽고 나서 본문
오늘은 당근페이팀의 백엔드 아키텍처 변화 과정을 다룬 긴 블로그 글을 읽어봤다. 사실 나 같은 백엔드 개발자라면 한 번쯤 "지금 우리가 쓰는 구조가 진짜 최선인가?"라는 고민할 때가 있다. 심지어 나는 첫 회사가 PG사였기 때문에 더더욱 호기심이 생겼다. 이 글은 실제 도메인의 빠른 성장과 아키텍처 변천사가 확실하게 묘사되어 있어서 공감도 되고 배울 점도 많았다.
계층형 -> 헥사고날 -> 클린 아키텍처기반의 모노레포로
나는 솔직히 아키텍처가 비즈니스 성장과 팀의 규모 변화에 따라 명확하게 진화했다는 점이 흥미로웠다. 단순한 계층형 구조로 시작해서 업무와 팀의 확장에 따라 헥사고날 아키텍처 도입, 이후 클린 아키텍처와 모노레포 전략까지 도달한 과정이 디테일하게 적혀 있어서 너무 좋았다. 흔히들 '우리 서비스는 아직 작으니까 무조건 단순하게!'라고 시작했다가 기술 부채가 기대 이상으로 커지는 경험, 나도 현업에서 두어 번 겪어봤다. 과연 지금 이 구조가 최선인지..
헥사고날 아키텍처 도입의 어려움 그리고 값어치
이전 직장에서도 헥사고날 아키텍처에 대한 논의가 많지만, 도입이 쉽지는 않았다. 코드 간 의존성 정리가 되어서 테스트가 쉬워지고, 비즈니스 로직을 기술로부터 분리할 수 있다는 장점은 진짜 큰 것 같다. 하지만 당근페이에서도 언급된 것처럼, 도입 자체보다는 팀 단위로 명확한 컨벤션을 세우는 게 훨씬 어렵다는 걸 다시 느꼈다. 구조는 멋지게 만들었지만, 도메인/어댑터 모듈에 기준 없이 코드를 넣다 보면 결국 또 다른 형태의 스파게티가 되는 경험을... 나도 했다. 명확한 사유 없이 헥사고날 아키텍처를 도입한다? 그럼 절반 이상은 겉멋이라고 해야할까...? 그런 색안경을 끼고 바라보게 된다.
모노레포 생산성 vs. 복잡성
모노레포라는 키워드에서 확 반가움을 느꼈다. 왜냐하면 놀유니버스에서 최근 관심을 가지고 있는 아키텍처가 이 모노레포라는 사실을 알고 있어서였다. 이처럼 요즘 대규모 서비스에서 이걸 도입할지 말지 고민이 많은데, 당근페이처럼 여러 도메인 서비스를 하나의 저장소에서 일관성 있게 관리하면서 코드 리뷰, 의존성, 자동화, 일괄 개선 같은 이점을 극대화하는 건 큰 메리트라고 생각한다. 특히 피드백 루프가 빨라질수록 작은 실험 > 빠른 릴리즈 → 실사용 피드백의 선순환을 만들 수 있다는 점에 대해서 명확한 장점을 느낄 수 있었다.
하지만, 빌드 속도나 인지 부하, 모듈 경계의 해석 차이 등 실제로 겪는 문제점들도 솔직하게 적어놓은 게 좋았다. 나도 이전 직장에서 실 서비스는 아니지만, 모노레포로 프로젝트를 묶다가 젠킨스 빌드 대기열만 길어지고, '누가 우리 코드를 건드렸지?'라는 당혹스러운 상황을 겪은 경험이 있다. 결국 모노레포든, 멀티레포든 팀 상황에 따라 트레이드오프가 다른 것 같다.
팀 문화와 아키텍처의 관계
블로그에서 본 메인 메시지는 단순히 "최고의 아키텍처는 무엇인가?"가 아니라 팀의 성장, 협업 방식, 개선 문화와 맞닿은 아키텍처의 적합성에 대한 탐구(?)였던 것 같다. 코드 리뷰가 모두의 성장 루프가 되고, 구조적 문제를 함께 인식하고 고치려고 시도하는 모습이 인상적이었다. (이게 팀이지...) 기술은 결국 도구일 뿐이고, 그걸 활용하는 팀의 문화와 개선 지향성이 가장 큰 힘이란 걸 다시 한 번 느꼈다.
나는 직장인으로서 팀 문화라는 것이 굉장히 중요한 요소라고 생각한다. 나도 딱 한 번 경험 해보았지만, 사소한 일 하나라도 잘못되면 남탓하기 바쁘고 동료 중 누군가가 실수를 했을 때, 상대방이 모르는 부분을 지적하고 비난하고 질책하기만 하는 문화를 가진 팀은 정말이지... 출근하기 겁난다.
궁금했던 점
- 빌드/테스트 속도 최적화: 코드 라인 수가 두 배로 늘었다고했다. 빌드 속도가 큰 변화가 없었다고 도 했다! 실제로 어떤 CI/CD 최적화나 캐시 전략을 썼는지 궁금하다. 나도 사이드 프로젝트 개발 생산성 측면에서 가장 큰 고민이 빌드 소요 시간이다..ㅜ
- 마이크로서비스/모노리포 분기점에 대한 장기적 고민: 팀이 더 커지고, 서비스/사업부별로 완전히 독립해야 한다면 다시 MSA, 멀티레포로 돌아갈 수 있을까? 아니면 모노레포 내에서도 근본적으로 서비스 분리를 더 강화할 방법이 있을지?
참고
'기타 > 타사 기술 블로그 읽기' 카테고리의 다른 글
| T4 GPU 1장으로 일궈낸 올리브영의 Gemma 3 기반 sLLM 구축기를 읽고나서 (0) | 2026.01.26 |
|---|---|
| 배달대행사 API 연동과 장애 대응 - 오늘드림 서비스 개발기를 읽고나서 (0) | 2026.01.20 |
| 수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기를 읽고 나서 (1) | 2026.01.12 |
| 요기요 채널링 서비스 런칭 회고를 읽고 나서 (1) | 2026.01.08 |
| 어디서 사도 NOL(야놀자)로 연결되는 이유 — 레저 채널링 구조 이야기를 읽고 나서 (0) | 2026.01.07 |