복잡한 코드베이스에서 AI 작동시키기

• AI 코딩 도구는 대형 실서비스 코드베이스에서 생산성을 오히려 저하시킬 수 있음
• 현재의 대형 언어모델도 맥락 엔지니어링 원칙을 잘 적용하면 상당한 성과를 도출할 수 있음
• 의도적인 맥락 축소(compaction) 전략으로 코드 품질과 개발 속도 모두에서 탁월한 결과 달성 경험을 공유함
• 단순히 대화형 챗봇 방식이 아니라, 코딩 과정 전체를 맥락 최적화 중심으로 설계하는 접근이 필요함
• 맥락 품질이 AI 코드 생성 결과를 결정하므로, 개발팀 전원이 정확성, 완전성, 크기, 진행 방향을 최적화하는 것이 중요함

복잡한 코드베이스에서 AI 작동시키기

대부분의 개발자들은 AI 코딩 도구가 실제 프로덕션 코드베이스에서는 기대만큼 잘 작동하지 않는다는 점을 잘 알고 있음

• Stanford 연구 결과, AI 도구가 추가하는 코드의 상당 부분이 이전에 AI가 생성한 미흡한 코드를 다시 손보는 식으로 반복 작업을 초래함
• AI 코딩 에이전트는 신규 프로젝트나 소규모 변경에는 효과적이지만, 대규모 코드베이스에서는 오히려 개발자 생산성을 낮출 수 있음
• 그래서 '좀 더 똑똑한 모델이 나오면…'이라는 신중한 태도를 보이는 경우가 많음

하지만 실제 300,000 LOC의 대형 Rust 코드베이스에서 맥락 엔지니어링을 적용해보니, 기존 모델만으로도 생산성과 품질 모두 시장 수준을 넘어설 수 있었음

• 핵심은 빈번한 의도적 축소(frequent intentional compaction) 로, 개발 과정 내내 AI에 주어지는 맥락을 구조화되고 관리된 형태로 만드는 것임

결국 ‘AI 코딩’이란 기술적 장인정신이 필요한 영역임을 확신하게 됨

AI 엔지니어 관점에서의 맥락

AI Engineer 2025에서의 두 가지 발표가 사고방식 변화를 이끌었음

• Sean Grove의 "Specs are the new code" 발표에서, AI와의 대화 기록까지도 스펙에 포함시켜 검증 가능한 개발 근거로 삼아야 한다는 주장을 접함
• Stanford의 생산성 연구에서는, AI 도구가 대형, 레거시 코드베이스에는 맞지 않으며 신규(그린필드) 프로젝트에만 효과적임을 데이터로 확인함
• 실무자들도 "코드가 지저분해진다", "기술 부채 공장 된다", "대형 레포지토리에서는 안 통함", "복잡한 시스템엔 취약하다"는 피드백을 반복적으로 제시함

‘좀 더 똑똑해지면’이라는 예상보다, 맥락 엔지니어링을 적극적으로 활용해 현재 모델의 잠재력을 최대한 뽑아내는 방법이 더 현실적임

현재 가능한 일

예시로, Rust 기반 30만 라인 규모의 BAML 프로젝트에서 맥락 엔지니어링을 실험함

• Rust 초보임에도 불구하고, 1시간 만에 버그 픽스 PR 제출 및 다음날 승인됨
• 며칠 후, @hellovai와 함께 팀의 예상보다 훨씬 빠르게, 대규모 기능(WASM, 취소 처리 등)을 7시간 내 draft PR로 구현함
• 모두 빈번한 의도적 compaction과 맥락 관리 중심의 워크플로우 덕분에 가능했음
• 연구, 기획, 구현의 프로세스가 있지만, 본질은 맥락 최적화 원칙이 워크플로우나 프롬프트의 구체적 형태를 넘어선다는 점임

이 방식에 이르게 된 여정

동료와 협업 중, 매번 2,000라인이 넘는 대형 PR이 올라옴

• 고난도 race-prone Go 시스템 코드가 주였고, 일일이 코드리뷰하는 방식으론 한계 도달
• 결국 spec-driven development로 전환
• 초기에 불편함과 통제력 상실감이 있었지만, ‘스펙 중심 검증’으로 패러다임 전환 성공
• 8주 뒤에는 생산성이 크게 향상되고, 직접 소스파일을 수정하는 일이 크게 줄어듦

진보된 맥락 엔지니어링이 필요한 이유

실질적으로 필요한 AI의 역할 조건은 다음과 같음

• 레거시(브라운필드) 코드베이스 적합
• 복잡한 문제 해결 능력
• 불필요한 코드나 슬롭(sloppiness) 최소화
• 팀 전체가 정신적 일치에 도달할 수 있는 방법
• (토큰 소비는 많을수록 좋음)

이후, 맥락 엔지니어링 적용 경험과 이를 통해 깨달은 '기술 장인정신', 그리고 이 접근방식의 일반화 한계 및 그 한계가 계속 깨지는 사례들을 탐구함

맥락 관리의 '순진한 방식'

대부분 초기에는 챗봇처럼 대화형 방식으로 AI 에이전트를 사용함

• 문제를 함께 풀다보면, 맥락 한계를 넘거나 답변 품질 저하, 혹은 중간에 포기하게 됨

조금 나은 방법은 작업 맥락이 꼬이면 세션을 재시작하고, 프롬프트를 조정해 조금 더 구체성을 부여하는 것임

'의도적 compaction'의 시작

조금 더 찬찬히 작업하면, 맥락이 가득차기 전에 진행상황을 요약·정리해서 새로운 세션을 시작하는 의도적 compaction을 쓰게 됨

• 예: "지금까지의 과정을 progress.md 파일로 정리하라. 목표, 현재 방법론, 지금까지 진행 단계 및 현재 마주한 실패 상황을 요약하라"는 프롬프트 활용
• 커밋 메시지로도 맥락 compaction을 실현 가능

우리는 무엇을 compaction 하는가?

맥락을 소모하는 대표 요인은 다음과 같음

• 파일 검색
• 코드 흐름 파악
• 코드 수정 및 적용 내역
• 테스트/빌드 로그
• 도구에서 발생하는 대형 JSON 데이터

Compaction의 목적은 불필요한 정보를 줄이고, 구조화된 산출물로 요약해 맥락 창을 절약하는 데 있음

• 구체적 compaction 산출물 예시: 목표, 과정, 실패지점, 쟁점 리스트 등

LLM, 에이전트, 그리고 맥락의 본질

• LLM(거대 언어 모델)은 본질적으로 상태 없는 함수와 유사함
• 입력(맥락 창)의 품질만이, 출력(코드, 제안 등)의 품질을 결정함
• 코딩 에이전트 사용법도, 에이전트 자체 구축과 마찬가지로 맥락 설계 품질이 전부임

따라서 맥락 창은 다음 네 가지 기준에서 최적화되어야 함

1. 정확성
2. 완전성
3. 크기(한계 내 효율성)
4. 진행 방향

이 네 가지 기준을 벗어나는, 즉

1. 잘못된 정보
2. 누락된 정보
3. 노이즈/불필요 정보는 반드시 피해야 함

맥락 창의 품질이 곧 AI 결과물의 품질을 좌우하므로, 이 부분을 집요하게 최적화하는 것이 핵심 경쟁력임