INTRO
최근 몇 달 동안 개발 방식이 많이 달라졌다.
예전에는 기능 하나를 구현하려면 IDE를 열고, 설계를 하고, 직접 코드를 작성하고, 테스트를 돌리고, 리뷰 대응까지 대부분 사람이 수행했다. 이 방식은 더이상 언급할 필요가 없을 정도로 과거의 유물이 되었고, Claude Code, Codex, Cursor Agent 같은 AI 코딩 에이전트를 적극적으로 사용하기 시작하면서 생산성이 크게 올라갔다.
단순 CRUD나 보일러플레이트 생성 수준을 넘어서, 리팩토링, 테스트 작성, 아키텍처 정리, CI 개선 같은 작업까지 AI가 상당 부분 수행하기 시작했다. 그런데 일정 수준 이상 사용해보면 의외의 결론에 도달한다. 수많은 코드라인이 생겨났지만, 코드의 품질적인 일관성이 같은 모델이라 할지라도 매번 달라지는 것을 경험하였고, 개발자 마다도 차이를 보였다.
이를 현 시점에 AI 모델 성능의 문제라고 단정 짓고 향후 모델이 발전함을 기다리기 보다 시스템을 구축하는것으로 방향을 잡았다.
Prompt Engineering보다 중요한 것
AI 코딩 에이전트를 처음 도입할 때 흔히 하는 접근이 있다. "좋은 프롬프트를 만들면 된다.", "룰 파일을 잘 작성하면 된다." "AI에게 우리 컨벤션을 학습시키면 된다."
물론 어느 정도는 효과가 있다. 하지만 실제 대규모 백엔드 프로젝트에서는 금방 한계를 만나는데 대표적으로 이런 상황들이다.
- Layer rule을 반복적으로 위반한다.
- Repository dependency 방향이 뒤집힌다.
- 같은 레포 안에서도 스타일이 흔들린다.
- PR마다 구조가 달라진다.
- 특정 서비스 수정이 다른 서비스 영향도를 놓친다.
프롬프트를 더 길게 써도 근본 해결은 잘 되지 않는다. 왜냐하면 자연어 기반 instruction은 본질적으로 확률적이기 때문이다. 반면 production backend system은 결정론적이다.Backend Engineering은 "잘 부탁합니다"로 운영되지 않는다.검증 가능해야 하고, 강제 가능해야 한다.
AI 코딩 에이전트가 잘 작동하는 Backend Repo의 조건
AI 코딩 에이전트를 실제 프로젝트에 붙여보면서 느낀 것은 하나였다. AI 친화적인 레포지토리는 사실 좋은 엔지니어링 레포지토리와 거의 동일하다.
1. 컨벤션이 일관적이다.
같은 Kotlin 프로젝트인데 파일마다 패턴이 다르면 문제가 생긴다. 어떤 곳은 Service가 orchestration을 담당하고,
어떤 곳은 Domain object가 책임을 갖고, 어떤 곳은 util helper에 비즈니스 로직이 숨어 있다.
AI 코딩 에이전트는 기존 코드베이스를 적극적으로 reference하는데도 불구하고 기존 패턴이 흔들리면 결과도 흔들리게 된다.
결국 중요한 것은 "AI instruction"보다 repo consistency다.
2. 규칙이 문서가 아니라 코드로 존재한다.
많은 팀이 Claude Code, README나 wiki에 아키텍처 룰을 적는다. 하지만 백엔드 시스템에서 문서는 참고자료일 뿐이다.
실제 enforcement는 다른 곳에서 일어나야 한다.
예를 들어:
- ktlint → formatting enforcement
- detekt → static analysis enforcement
- ArchUnit → architecture boundary enforcement
- test suite → regression prevention
- CI → merge gate
3. 자동 검증 시스템이 존재한다.
AI 코딩 에이전트는 매우 빠르게 코드를 생성함에 따라 AI 시대에 CI 중요성은 오히려 더 커지게 되었다. 그러면서 병목지점은 코드 생성 속도가 아니라 validation loop로 이동한다.
수정 → 테스트 → 실패 → 수정 → 재검증.
이 피드백 루프가 느리면 생산성이 급격히 떨어지고, 특히 MSA 환경에서는 영향 범위가 커서 더욱 그렇다. 그래서 최근에는 단순 build pipeline보다 다음을 더 중요하게 본다.
- CI execution latency
- deterministic validation
- fast feedback loop
- architecture regression detection
Architecture Test가 다시 중요해진 이유
AI 시대에 오히려 가치가 올라간 영역이 있다. Architecture Governance다. 조금 역설적이다. 사람이 직접 코드를 덜 쓰게 되는데, 왜 구조 설계가 더 중요해질까?
그이유는 AI 코딩 에이전트는 명확하게 정의된 구조를 훨씬 잘 따르기 때문이다.
God Service가 존재하는 프로젝트보다, 명확한 bounded context가 존재하는 프로젝트에서 훨씬 안정적으로 동작한다.
예를 들어:
order
├─ domain
├─ application
├─ infrastructure
└─ interfaces이런 경계가 분명한 구조에서는 AI 코딩 에이전트가 책임 분리를 비교적 잘 수행한다. 반대로 dependency graph가 얽혀있는 레포에서는 hallucination과 architecture drift가 증가한다. 그래서 최근에는 Architecture Test를 꽤 중요하게 본다.
Kotlin/Spring 기준으로는 ArchUnit 같은 도구가 꽤 유용하다.
예시:
- Controller → Repository direct access 금지
- Domain → Infrastructure dependency 금지
- Cross bounded-context import 제한
- Saga orchestration boundary 검증
이런 룰을 코드화하면 AI 코딩 생산성이 꽤 안정적으로 올라간다.
MSA 환경에서 AI 코딩 에이전트를 사용할 때 생기는 진짜 문제
단일 서비스에서는 꽤 잘 동작하지만 MSA 환경으로 가면 난이도가 급격히 올라간다. 이유는 AI 코딩 에이전트가 코드만 보고는 시스템 전체 관계를 완전히 이해하지 못하기 때문이다.
실제로 어려운 부분은 이런 것이다.
- Kafka topic ownership
- Saga transaction boundary
- service dependency graph
- shared contract evolution
- backward compatibility
이건 단일 repo analysis만으로 해결은 어려워 보이고 앞으로 중요해질 영역은 단순 code generation이 아니라 knowledge layer라고 생각한다.
- Architecture graph
- Service dependency map
- Domain knowledge retrieval
- Internal engineering RAG
- MCP tooling
결국 AI가 단순히 "코드를 생성하는 존재"를 넘어, 시스템을 이해할 수 있는 실행 환경이 필요해진다.
끝으로
AI 코딩 에이전트의 성능은 계속 좋아질 것이다. 하지만 실제 개발 생산성을 결정하는 것은 모델 버전이나 프롬프트 길이가 아니었다. 더 큰 차이를 만드는 것은 다른 곳에 있었다.
- 얼마나 빠른 validation loop가 존재하는가
- 얼마나 deterministic한 rule enforcement가 가능한가
- 얼마나 architecture constraint가 자동화되어 있는가
- 얼마나 병렬 작업을 안정적으로 운영할 수 있는가
결국 중요한 것은 AI를 잘 사용하는 방법보다, AI가 안정적으로 동작할 수 있는 Harness를 어떻게 구축하느냐에 가깝다. 좋은 AI Coding Harness는 모델의 성능을 증폭시키고, 동시에 불안정성을 제어한다. 그리고 예상하건데 앞으로의 개발 생산성 경쟁력은, 개별 에이전트의 능력보다 이런 Engineering System의 품질에서 더 크게 벌어질 가능성이 높아보인다.