Velog
AI 코딩 도구가 효과가 없나요? 당신의 코드 아키텍처가 문제일 수 있습니다
Jellyfish + OpenAI 가 130k 저장소 / 380만 PR 을 분석했더니 — *AI 도입이 PR 처리량을 가장 많이 늘리는 곳* 은 중앙 집중식 코드베이스, *오히려 늦추는 곳* 은 고도 분산 아키텍처 였다.
핵심 요약
Jellyfish 가 정의한 지표는 엔지니어당 주간 활성 저장소(repos per engineer).
| 4분위 | 평균 repos/eng | 아키텍처 특성 | AI ROI |
|---|---|---|---|
| Q1 | <1 | 중앙 집중 (모노리포, 모놀리스) | 0→100% 도입 시 PR 약 4배 |
| Q2 | 1–2 | 균형형 | 약 4배 |
| Q3 | 2–3.7 | 분산형 (폴리리포) | 약 2배 |
| Q4 | 3.7+ | 고도 분산 (광범위 마이크로서비스) | 약간 감소 |
상관관계 이지 인과 가 아니지만, 본 글이 제시하는 가설은 명료하다 — AI 의 효과는 컨텍스트의 질에 좌우 되고, 코드가 통합될수록 LLM 이 작업에 필요한 모든 변경을 한 트리에서 찾을 수 있다. 분산 아키텍처는 멀티 리포 코딩 에이전트 가 더 성숙해야 같은 이득을 본다.
AI 코딩 도구의 ROI 를 '얼마나 좋은 모델인가' 로만 보지 말고 '코드가 얼마나 통합되어 있는가 — 즉 LLM 이 한 작업을 끝내는 데 필요한 컨텍스트를 얼마나 쉽게 모을 수 있는가' 로 본다. 모노리포·모놀리스·중앙 집중식일수록 컨텍스트가 한 곳에 있어 AI 가 잘 작동하고, 폴리리포·마이크로서비스·연합형일수록 저장소 간 조정 이 필요해 AI 가 약해진다.
'우리 팀이 AI 를 잘 못 쓴다' 의 원인은 종종 모델/프롬프트 가 아니라 코드베이스 구조 에 있다.
- 본 연구에서 완전 도입 시 PR 병합 2.1배 증가 — 단, 평균치다
- 코드 아키텍처 4분위 중 중앙 집중식·균형형 은 0% → 100% 도입 시 약 4배 PR 증가
- 분산형 은 약 2배
- 고도 분산형 은 오히려 약간 감소 — AI 가 여러 저장소 간 변경을 일관되게 만들기 어렵기 때문
프런트엔드 조직이 마이크로 프런트엔드 / 폴리리포 / 모듈 페더레이션 을 도입할 때 AI 생산성 비용 까지 함께 평가해야 한다는 신호.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
*컨텍스트의 질* 이 AI ROI 의 1차 변수
현대 LLM 은 코드 검색·인덱싱·도구 사용 능력이 빠르게 올라왔다. 그래서 진짜 병목은 컨텍스트의 양/품질.
작업: "User 모델에 isVerified 필드 추가하고 모든 사용처 갱신"
중앙 집중 (모노리포):
└ 한 번의 grep 으로 모든 호출처 발견 → 일관된 PR
고도 분산 (마이크로서비스):
├ 각 서비스 저장소 별도 클론
├ 서비스 간 API 계약 변경 조율 필요
└ 한 PR 가 아니라 *수십 개의 PR + 배포 순서* 가 필요
에이전트가 여러 저장소 + 배포 순서 를 자동으로 다룰 수 있게 되기 전엔 분산 아키텍처의 ROI 가 낮다.
'AI 가 안 통하는 건 모델 탓'. 실제로는 프롬프트가 모을 수 있는 컨텍스트 가 부족한 경우가 많다.
분산 아키텍처는 *PR 양* 이 많지만 *기능 양* 이 같지 않다
고도 분산 팀은 평균적으로 엔지니어당 PR 이 2배 많다. 하지만 그것이 2배 더 많이 출시한다 는 의미는 아니다.
- 한 기능이 N 개 저장소 변경 을 동반
- 같은 마이그레이션이 N 개 저장소에 복제
- 그래서 PR 카운트는 늘지만 고객에게 도착한 가치 는 비례하지 않음
PR 처리량은 생산성 의 한 신호일 뿐, 전체 출하 가치 와 동일시하면 안 된다.
PR 카운트만 보고 '분산이 더 빠르다' 고 단정하는 것. 한 기능 출시에 필요한 PR 수도 함께 봐야 한다.
고도 분산 팀이 가야 할 길은 *멀티 리포 에이전트*
현재 단일 에이전트는 한 저장소 컨텍스트 에 강점이 있다. 분산 팀에 진짜 도움이 되려면:
- 저장소 간 인덱스 — 회사의 모든 저장소를 한 검색 공간으로
- API 계약 변경 자동 전파 — A 서비스 API 를 바꾸면 B/C/D 의 클라이언트 코드 자동 PR
- 배포 순서 추론 — 의존성 그래프 위에서 안전한 배포 순서 제안
- 검증 자동화 — 각 저장소의 CI 결과를 종합 판단
리뷰 에이전트 (코드/테스트/감사) 가 이 영역에서 가장 빠르게 성숙 중. 분산 팀의 ROI 회복 가능성은 충분히 높다.
분산 아키텍처를 무조건 모노리포로 합쳐야 한다 고 결론짓는 것. 도구가 빠르게 성숙 중이며 조직 비용도 함께 고려해야 한다.
읽는 순서
- 1이론
Jellyfish 의 원문과 이전 완전 도입 시 PR 2.1배 보고서를 함께 읽고, 본 글이 제기한 컨텍스트 질 가설의 근거를 정리.
- 2구현
사내에서 대표 PR 한 건 을 골라, AI 에이전트가 한 번에 처리 가능한지 저장소 수 / 컨텍스트 수 를 측정.
- 3실무
분산 영역에 멀티 리포 인덱스 (예: Sourcegraph/Cody, GitHub Code Search) 를 도입하고 AI ROI 변화를 4주간 추적.
- 4설명
조직 리더에게 'AI 효과가 안 보이는 진짜 이유는 코드 아키텍처' 라는 주제로 10분 발표 — 4분위 표 + 자체 측정값.
면접 연결 질문
[감점 답변] '무조건 모노리포'. [좋은 답변] (1) 현재 사용하는 AI 도구의 멀티 리포 지원 수준 측정. (2) 한 기능이 평균 몇 개 저장소 변경을 동반하는지 분석. (3) 팀 규모/조직 경계 와 컨텍스트 통합 의 트레이드오프 — 100명 이상이면 모노리포가 빌드/CI 비용에서 다른 병목을 만든다. (4) 과도기 전략 — 핵심 도메인은 모노리포로 통합, 변동성 큰 영역만 별도.
[감점 답변] 'PR 카운트는 늘 동일한 의미'. [좋은 답변] 분산 아키텍처는 한 기능당 여러 저장소 PR 이 필요해 PR/기능 비율 이 본질적으로 높다. DORA Lead Time / Deployment Frequency / Change Failure Rate 같은 결과 메트릭 과 함께 봐야 의미 있다.
자기 점검
'우리는 한 저장소만 쓴다'. 백엔드/인프라/디자인 시스템/모바일까지 합치면 분산도가 높을 수 있다.