AI 코딩 도구가 우리 프로젝트에서는 왜 이렇게 힘을 못 쓰지?
사내 채팅에서 심심치 않게 나오는 질문이다. 데모 영상에서는 10분 만에 앱 하나가 뚝딱 나오는데, 정작 30만 줄짜리 회사 코드베이스에 붙이면 헛발질만 반복한다. 문제는 AI 성능이 아니다. 대규모 코드베이스 AI 개발 도구 활용법을 아직 못 찾은 것에 가깝다.
METR이 2025년에 발표한 연구는 이 현실을 정확히 짚는다. 숙련된 오픈소스 개발자들이 AI 도구 사용 시 “체감상 20% 빨라졌다”고 답했지만, 실제 측정 결과는 19% 더 느려졌다. 대규모 저장소에서 AI가 만든 코드를 다시 손보는 재작업이 반복되며 시간을 잡아먹은 것이다.
그럼 해결책은? 결론부터 말하자면 컨텍스트 엔지니어링이다. 이 글에서는 실제 30만 라인 Rust 프로젝트에서 검증된 워크플로우를 단계별로 풀어본다.
브라운필드의 함정: 왜 큰 코드베이스에서 AI가 헤매는가
신규 프로젝트(그린필드)에서는 멀쩡한 AI가 기존 대규모 코드베이스(브라운필드)에서는 왜 이렇게 맥을 못 출까? 핵심은 컨텍스트 관리다.
AI는 본질적으로 무상태 함수다. 이전 대화를 기억하지 못한다. 오직 현재 입력된 컨텍스트만 보고 결과를 만들어낸다. 복잡한 코드베이스에서는 파일 검색, 코드 흐름 추적, 수정 내역, 테스트 로그가 순식간에 컨텍스트 윈도우를 가득 채운다. 그 결과 AI는 정보 과부하 상태에서 부정확하거나 불완전한 답을 내놓는다.
더 무서운 건 오류의 전파 순서다. 잘못된 정보 > 누락된 정보 > 과도한 노이즈 순으로 문제가 확산된다. 잘못된 정보 하나가 수천 줄의 엉뚱한 코드로 번지는 데 그리 오랜 시간이 걸리지 않는다.
숫자가 말해주는 브라운필드의 대가
2026년 현재 Augment Code의 브라운필드 리서치에 따르면, 개발자들은 코드를 수정하기 전에 이해하는 데만 업무 시간의 35~50%를 쓴다. AI가 이 이해를 건너뛰고 바로 코드를 뽑아내면, 그 뒤에 기다리는 건 리뷰 지옥뿐이다.
업계 벤치마크도 비슷한 방향을 가리킨다. AI 생성 코드 비율이 40%를 넘어가는 팀은 재작업률이 20~25% 증가하며, 구성원 한 명당 주당 약 7시간을 AI 관련 비효율에 쓴다. 이건 AI 의존이 엔지니어링 문화를 갉아먹는 현실에서 지적한 구조적 번아웃 문제와 정확히 맞물려 있다.
컨텍스트 엔지니어링의 핵심: 빈번한 의도적 압축
해결책으로 주목받는 접근이 빈번한 의도적 압축(Frequent Intentional Compaction, FIC) 이다. HumanLayer의 공개 문서가 이 방법론을 체계적으로 정리해뒀다.
핵심 원칙은 하나다. 컨텍스트 윈도우를 항상 40~60% 수준으로 유지한다. 꽉 채우지 않는다. 다음 단계에 꼭 필요한 정보만 구조화된 형태로 넘긴다. 즉 “컨텍스트는 유한 자원”이라는 전제에서 출발한다.
압축 대상은 이렇다.
- 파일 검색 로그
- 코드 흐름 추적 결과
- 수정 내역과 diff
- 테스트/빌드 로그
- 대용량 JSON/응답 데이터
각 단계 산출물은 구조화된 아티팩트로 남긴다. 목표, 접근 방식, 완료된 단계, 현재 실패 지점을 기록한 progress 문서가 대표적이다. 이 문서가 다음 턴의 입력 품질을 만든다.
3단계 워크플로우: 연구 → 계획 → 구현
1. Research(연구) 단계
문제의 원인 가설을 체계적으로 조사한다. 필요하면 서브에이전트를 별도로 띄워 신선한 컨텍스트에서 범위 탐색과 요약을 돌린다.
이 단계의 산출물은 한 가지다. 요약 리서치 문서. 관련 파일 목록, 코드 흐름, 외부 의존성, 가설과 반증 등이 200~400줄 규모의 마크다운으로 정리된다. 코드는 아직 한 줄도 건드리지 않는다.
2. Plan(계획) 단계
리서치 문서를 입력으로 받아 구현 계획을 짠다. 수정 대상 파일, 변경 방식, 검증 방법, 테스트 절차까지 구체적으로 쓴다.
이 계획서가 나중에 코드 리뷰보다 훨씬 높은 레버리지를 가진 검토 지점이 된다. 엔지니어는 2천 줄 PR보다 200줄짜리 계획 문서를 훨씬 정확하게 읽을 수 있다. 이 단계에서 방향이 틀어지면 이후 수천 줄이 함께 잘못되므로, 팀 리뷰를 집중적으로 투입해야 할 지점이기도 하다.
3. Implement(구현) 단계
계획을 단계별로 집행한다. 각 단계 완료 후 진행 상황을 다시 계획 문서에 압축해 기록한다. 복잡한 작업이라면 단계마다 컨텍스트를 재정렬한다. 변경이 누적될수록 원래 계획과의 정합성을 체크해야 한다.
이 연구-계획-구현 구조는 더 나은 프롬프트 하나로는 해결되지 않는 규모의 문제에 대응하기 위한 최소 단위다. 단순한 프롬프트 엔지니어링을 넘어선 영역으로, 관련 원칙은 AI 협업 최적화 전략에서도 이어지는 흐름이다.
실제 사례: 30만 LOC Rust 프로젝트에서 벌어진 일
이론만으로는 설득력이 부족하다. HumanLayer 블로그가 공개한 BAML 사례를 보자. 30만 라인에 달하는 Rust 코드베이스다.
- 프로젝트에 갓 합류한 개발자가 몇 시간 만에 버그 수정 PR을 올려 승인받았다
- 두 개발자가 7시간 만에 취소(cancellation) 기능과 WASM 컴파일 지원을 완성했다
- 팀 추정으로는 각각 3~5일이 걸릴 작업이었다
3~5일짜리 작업이 한나절에 끝났다는 건 충격적인 수치다. 그러나 방법론의 핵심은 “빠르다”가 아니라 “일관되게 빠르다”다. 리서치/계획/구현 파이프라인이 매번 같은 품질을 만들어주기 때문이다.
성공만 있던 건 아니다
반대 사례도 있다. Parquet Java에서 Hadoop 의존성을 제거하려던 시도는 의존성 트리를 깊이 파악하지 못해 실패했다. 교훈은 분명하다. 모든 문제가 프롬프트만으로 풀리지 않는다. 도메인 전문가의 개입이 필요한 지점이 있고, 그 지점을 조기에 인식하는 것도 실력이다. AI 도구의 인간 중심 설계에서 짚었듯, AI는 인간의 판단을 건너뛰려 할수록 더 크게 실수한다.
사람의 역할: 레버리지가 가장 큰 지점에 집중하라
AI 코딩에서 사람의 개입은 연구 > 계획 > 코드 순으로 레버리지가 커진다. 거꾸로 말해, 잘못된 연구 한 줄이 수천 줄의 오류 코드로 퍼질 수 있다.
코드 리뷰의 새로운 패러다임
전통적 코드 리뷰의 본질은 “정신적 정렬(mental alignment) 유지”다. 하지만 AI가 하루에 수천 줄씩 생성하는 상황에서는 비현실적이다. 대신 스펙, 계획, 리서치 단계에서의 검토가 훨씬 효율적이다.
이 변화는 조직 차원의 과제다. 엔지니어가 PR 본문 전부를 정독하는 대신 200줄 계획 문서를 매일 정확하게 읽는 문화를 만들어야 한다. 이 전환을 못 해내는 조직이 AI 혁명의 승자와 패자에서 말한 후자 쪽으로 밀려난다.
운영 비용과 현실성
현실 감각도 챙겨야 한다. 공개 사례 중에는 3명 규모 팀이 Opus 토큰 비용으로 월 약 12,000달러를 쓰는 경우도 있다(2025년 기준 추정치). 비싸 보이지만, 본래 3~5일 걸릴 작업이 7시간에 끝난다면 충분히 경쟁력 있는 수준이다.
그러나 이 비용보다 더 무거운 건 문화 전환 비용이다. 스펙 기반 개발에 익숙해지고, AI와의 협업 워크플로우를 몸에 새기는 데는 분기 단위의 시간이 든다. Anthropic의 컨텍스트 엔지니어링 가이드에서도 강조하듯, 이제 컨텍스트는 배포 인프라나 보안 인프라처럼 조직 차원의 자산으로 관리해야 한다.
오늘 당장 해볼 수 있는 한 가지
큰 흐름을 한꺼번에 바꾸려 하지 말자. 다음 한 가지만 실험해보자.
- 다음 중규모 기능을 착수하기 전에, 먼저 200~400줄짜리 리서치 문서를 만들어본다
- 파일 목록, 가설, 예상 변경 범위, 테스트 계획까지 담는다
- 이 문서를 팀원 1명과 15분만 리뷰하고 시작한다
이 한 번의 투자가 구현 단계에서 몇 시간을 되돌려준다. 확신이 없다면 다음 스프린트에 한 번만 해보자.
대규모 코드베이스 AI 개발 도구 활용법의 핵심
결국 대규모 코드베이스 AI 개발 도구 활용법은 정교한 엔지니어링 수공업에 가깝다. 단순한 기술적 스킬이 아니다. 팀 전체가 새로운 협업 방식을 몸에 익히는 과정이다.
- AI는 무상태다. 매 턴 컨텍스트를 설계하자
- 컨텍스트 윈도우는 40~60%만 쓰자. 욕심내면 망한다
- 연구-계획-구현 3단계로 나누고, 각 단계의 산출물을 구조화된 아티팩트로 남기자
- 리뷰는 코드가 아니라 계획 단계에 집중하자
여러분의 팀은 이런 변화에 얼마나 준비되어 있는지 한 번 점검해보길 권한다. 개인의 생산성 향상을 넘어, 조직 전체의 협업 방식 변화가 진짜 경쟁력의 분기점이다.