AI 정확도를 높이는 가장 확실한 방법은 '더 나은 프롬프트'가 아니었다
Cursor로 40개 파일에 걸쳐 함수 시그니처를 리팩토링했을 때, 38개는 완벽했고 2개에서 버그가 발생했다. 문제는 사흘 뒤에야 터졌다. 범인은 AI가 아니었다. 버그가 난 2개 파일은 코드베이스에서 가장 결합도가 높은 파일들이었고, 4개 디렉터리에 걸친 타입 계층을 머릿속에 전부 담아야만 올바르게 수정할 수 있는 구조였다. dev.to의 한 개발자는 이렇게 정리했다: "AI는 방향 증폭기다 — 깨끗한 코드는 더 깨끗해지고, 쓰레기 코드는 더 나빠진다."
AI 정확도는 모델보다 코드 구조와 더 상관관계가 높다
같은 글에서 공유된 데이터는 꽤 충격적이다. 모듈이 명확하고 인터페이스가 명시적일 때 AI 정확도는 약 95%였지만, 결합도가 높고 묵시적 의존성이 있을 때는 60%까지 떨어졌다. 더 무서운 건 그 60% 케이스에서 버그가 '그럴듯하게' 보인다는 점이다 — 로컬 테스트를 통과하면서. Sonnet에서 Opus로 업그레이드하면 어려운 작업에서 10~20% 향상을 기대할 수 있지만, 엉킨 모듈을 명시적 인터페이스를 가진 깔끔한 컴포넌트로 리팩토링하면 그 모듈에서만큼은 60%를 95%로 끌어올릴 수 있다 — 어떤 모델을 쓰든.
AI를 위한 설계 = 좋은 설계
실용적으로 무엇이 바뀌어야 할까. '바보 AI를 위한 설계'의 핵심은 세 가지다. 첫째, 파일을 작게 유지하라. 500줄짜리 파일보다 100줄짜리 파일에서 AI가 훨씬 적은 오류를 낸다. 미학적 이유가 아니라 AI의 컨텍스트 윈도우가 로컬이기 때문이다. 둘째, 인터페이스를 명시하라. 모듈 간 의존성이 관례로 암묵적으로 존재하면 AI는 그것을 보지 못한다. 타입으로 선언된 것만 보인다. 셋째, 구현이 아닌 동작을 테스트하라. AI가 내부를 자유롭게 리팩토링하면서도 동작 테스트를 통과하면 그 리팩토링은 옳다. 흥미로운 점은, AI를 위해 취한 이 모든 조치들이 이미 좋은 소프트웨어 엔지니어링의 원칙들이라는 것이다 — 명시적 API 설계, 관심사 분리, TDD, 단일 진실 원천. AI는 새로운 것을 가르쳐 준 게 아니라, 그동안 타협해왔던 지점들을 잔인할 만큼 투명하게 드러냈을 뿐이다.
AI 리팩토링이 아키텍처 경계를 침범하는 패턴
코드 구조의 문제만이 아니다. AI가 아키텍처 자체를 조용히 해체하는 더 위험한 패턴이 있다. dev.to의 또 다른 글에서 Spring Boot 기반 DDD 프로젝트를 예로 든다: AI에게 "SLF4J로 구조화된 로깅을 추가해줘"라고 요청하면, AI는 도메인 엔티티 클래스 안에 Logger 를 박아버린다. 기능적으로는 완벽히 작동한다. 아키텍처적으로는 도메인 모델이 인프라 관심사에 의존하게 되는 레이어 위반이다. 로깅 하나가 문제가 아니다. 메트릭 추가, 트레이싱 도입, 재시도 로직 구현 — 이런 크로스커팅 관심사들이 AI 속도로 누적되면 계층 경계가 점진적으로 녹아버린다. AI는 작업 완료에 최적화되어 있고, 아키텍처 의도는 타입 시스템에 인코딩되어 있지 않기 때문이다. Eric Evans의 말처럼, "묵시적인 것을 명시적으로" 만들지 않는 한 경계는 언젠가 반드시 침범된다.
거버넌스를 코드와 함께 배포하라
그렇다면 테크 리드는 무엇을 해야 하는가. 아키텍처 경계를 관례가 아닌 강제 수단으로 만드는 것이다. 세 가지 레이어로 생각할 수 있다: 사람이 읽을 수 있는 계약(아키텍처 문서), 빌드 타임 강제(레이어 위반을 감지하는 테스트), 그리고 AI-Aware 제약 조건 — 바로 여기가 핵심이다. CLAUDE.md 또는 AGENTS.md 파일에 아키텍처 규칙을 명시하라. "도메인 레이어는 인프라를 import하지 않는다", "서비스는 레포지토리를 직접 호출하지 않는다" 같은 규칙들. AI 코딩 어시스턴트는 이 파일을 읽고 컨텍스트로 활용한다. 개발자, 컴파일러, AI 어시스턴트가 동일한 아키텍처 의도 아래 작동하도록 만드는 것 — 이것이 AI 시대의 거버넌스다. 제약이 아니라 정렬이다.
세션 간 아키텍처 컨텍스트를 유지하는 문제
또 다른 실용적 문제가 있다. AI 코딩 어시스턴트는 세션이 끊기면 프로젝트 맥락을 잊어버린다. CogmemAi v3 같은 도구가 이 문제를 정면으로 다루는 이유다. Claude Code, Cursor, Windsurf 등 MCP 호환 도구에 영구 메모리를 부여하고, 세션 재시작 시 이전 작업 컨텍스트를 자동 복원하며, 자주 참조되는 메모리의 중요도를 자동으로 높이는 방식이다. 프로젝트의 아키텍처 결정, 금지된 패턴, 레이어 규칙을 메모리에 저장해두면 AI가 세션을 넘나들어도 동일한 구조적 맥락 위에서 작업할 수 있다. CLAUDE.md 가 정적 규칙이라면, 세션 메모리는 살아있는 컨텍스트다.
팀 리드가 지금 당장 해야 할 것
AI 코딩 어시스턴트 도입 성과가 팀마다 극적으로 차이나는 이유가 이제 명확해진다. 모델 선택이나 프롬프트 품질이 아니라 코드 구조와 아키텍처 거버넌스의 문제다. AI-First 팀 리드로서 지금 당장 챙겨야 할 세 가지를 정리하면: ① 코드 구조 감사 — 결합도 높고 묵시적 의존성이 많은 모듈을 식별하라. 거기가 AI가 60%짜리 결과물을 내는 지점이다. ② CLAUDE.md / AGENTS.md 작성 — 아키텍처 경계를 AI가 읽을 수 있는 언어로 명시하라. 이것이 AI 시대의 아키텍처 문서다. ③ 레이어 위반 테스트 도입 — ArchUnit 같은 도구로 AI가 생성한 코드가 경계를 넘었는지 빌드 시점에 잡아라. AI는 빠르게 코드를 생성한다. 우리가 설계한 구조의 테두리 안에서 빠른 것과 그 테두리를 무너뜨리면서 빠른 것은 전혀 다른 이야기다. 아키텍처를 수호하는 것 — 그게 AI 시대 테크 리드의 핵심 역할이다.