Augment 코드 리뷰: 전체 코드베이스를 인덱싱하는 AI 페어 프로그래머

저는 Augment의 Context Engine(컨텍스트 엔진)에 관한 글을 읽고, 2026년 5월 초에 Augment Code를 설치했습니다. 이 엔진은 전체 코드베이스를 의미론적으로 인덱싱하여, AI가 마치 시니어 엔지니어가 한 달간 온보딩을 마친 것처럼 프로젝트를 "이해"할 수 있게 한다는 주장을 담고 있습니다. 저는 이전에도 컨텍스트 윈도우(Context Window) 마케팅에 속은 적이 있었기에, 구조화된 비교 테스트를 진행했습니다. 제가 업무용으로 관리하는 52,000라인 규모의 TypeScript 모노레포(Monorepo)에서 3주 동안 매일 사용하며, GitHub Copilot 및 Cursor와 격일로 나란히 비교했습니다. 결과는 놀라웠지만, Augment의 홈페이지가 암시하는 방향과 완전히 일치하지는 않았습니다.

Context Engine은 단순한 기능 이름이 아닌 실제 아키텍처입니다

Augment의 핵심 차별점은 인덱싱 파이프라인(Indexing Pipeline)에 있습니다. OAuth 기반의 GitHub App을 통해 저장소를 연결하면, 시스템은 5단계의 인제스션(Ingestion, 데이터 수집) 프로세스를 실행합니다. 즉, .gitignore를 준수하며 모든 파일을 발견하고, 바이너리 및 생성된 코드를 필터링하며, 파일을 의미론적으로 유의미한 세그먼트(Segment)로 청킹(Chunking)하고, Augment 자체의 미세 조정(Fine-tuned)된 모델을 사용하여 커스텀 임베딩(Embedding)을 생성하며, 증분 업데이트를 위해 임베딩과 파일 해시(File-hash) 상태를 모두 유지합니다. 이후 실행 시에는 변경된 파일만 다시 인덱싱합니다. 52,000라인 규모의 모노레포를 대상으로 한 제 테스트에서는, 3개의 파일이 포함된 새로운 커밋이 2초 미만 만에 재인덱싱되었습니다.

임베딩 검색 (embedding search) 자체는 Augment의 엔지니어링 팀이 작년에 발표한 양자화된 근사 최근접 이웃 (quantized approximate-nearest-neighbor) 알고리즘을 사용합니다. 모든 쿼리 벡터 (query vector)를 모든 청크 벡터 (chunk vector)와 선형적으로 비교하는 대신 — 이는 1억 라인 규모의 코드베이스에서는 불가능할 것입니다 — 시스템은 먼저 압축된 비트 벡터 (bit-vector) 표현을 통해 후보군을 좁힌 다음, 상위 후보군에 대해서만 전체 유사도 점수 산정 (similarity scoring)을 실행합니다. Augment는 이전의 선형 방식보다 지연 시간 (latency)은 40% 낮추면서도, 전수 조사 (exhaustive search)와 비교했을 때 99.9% 이상의 재현율 (recall) 동등성을 확보했다고 주장합니다. 저는 이 99.9%라는 수치를 독립적으로 검증할 수는 없지만, 제 52,000라인 규모의 리포지토리에서 쿼리 지연 시간을 벤치마킹해 보았습니다. "JWT 만료를 검증하는 인증 미들웨어를 찾아줘"와 같은 의미론적 검색 (semantic searches)은 400에서 700밀리초(ms) 내에 관련 결과를 반환했으며, 이는 실시간 인라인 완성 (inline-completion) 속도는 아닐지라도 대화형 채팅 세션에는 충분히 빠른 속도입니다.

이 아키텍처는 대부분의 AI 도구 리뷰가 간과하는 이유, 즉 권한 경계 (permission boundaries) 때문에 중요합니다. Augment의 백엔드는 소유 증명 (Proof-of-Possession) 확인을 적용합니다. 즉, 컨텍스트 엔진 (Context Engine)이 해당 파일의 콘텐츠를 반환하기 전에, 사용자의 IDE가 해당 파일에 대한 읽기 권한이 있음을 증명하는 암호화 해시 (cryptographic hash)를 반드시 전송해야 합니다. 이는 모든 것을 무차별적으로 인덱싱하거나, 혹은 아무것도 인덱싱하지 않고 모델의 컨텍스트 윈도우 (context window)에만 의존함으로써 문제를 회피하는 도구들에 비해 진정한 보안상의 이점을 제공합니다. Augment의 고객으로 명시된 Adobe, MongoDB, Snyk와 같은 팀들에게 이는 단순한 학술적 관심사가 아닙니다.

한 가지 실질적인 참고 사항은, 인덱싱 시스템이 개발자별로 별도의 인덱스 (indices)를 유지한다는 점입니다. 이는 귀하의 브랜치별 변경 사항이 팀원의 컨텍스트 (context)로 유출되지 않으며, 팀원의 실험적인 리팩터링 (refactors)이 귀하의 컨텍스트를 오염시키지 않음을 의미합니다. 트레이드오프 (tradeoff)는 인덱스 저장소가 팀 규모에 비례하여 RAM을 소비한다는 것입니다. Augment는 동일한 테넌트 (tenant) 내의 사용자 간에 중복되는 인덱스 세그먼트 (index segments)를 공유함으로써 이 문제를 해결하며, 공유 브랜치에서 작업하는 팀의 메모리 비용을 줄여줍니다. 하지만 로컬 환경 (local environments)이 크게 다른 팀들에게는 오버헤드 (overhead)가 실제로 존재합니다.

전체 코드베이스 컨텍스트 vs. 파일 수준 컨텍스트: 예상보다 좁은 격차

여기서 중요한 질문은 이것입니다: 52,000줄을 인덱싱하는 것이 현재 열려 있는 500줄을 보는 것보다 더 나은 제안을 생성할까요? 저는 이를 측정하기 위해 집중적인 테스트를 수행했습니다.

저는 세 가지 카테고리에 걸쳐 25개의 작업을 정의했습니다. 카테고리 A는 "어차피 열어보았을 파일들을 건드리는 리팩터링 (refactoring)"이었습니다. 예를 들어, TypeScript 인터페이스 (interface)의 이름을 변경하고 8개의 파일에 걸쳐 이를 사용하는 컨슈머 (consumers)를 업데이트하는 작업입니다. 카테고리 B는 "기존 코드베이스에서의 그린필드 (greenfield) 작업"이었습니다. 즉, 해당 패턴이 무엇인지 명시적으로 알려주지 않아도 프로젝트의 기존 라우팅 (routing), 유효성 검사 (validation), 에러 핸들링 (error-handling) 패턴을 따라야 하는 새로운 API 엔드포인트 (endpoint)를 추가하는 작업입니다. 카테고리 C는 "숨겨진 의존성을 가진 횡단 관심사 변경 (cross-cutting changes)"이었습니다. 14개의 서비스 파일이 미묘하게 다른 방식으로 호출하는 공유 유틸리티 함수 (utility function)를 수정하는 작업이며, 이 중 3개는 해당 함수를 잘못 사용하고 있었습니다.

카테고리 A — 이름 변경 리팩토링 (rename-refactor) 작업 — 의 경우, Augment, Cursor, Copilot 모두 첫 시도 정확도 (first-attempt correctness) 면에서 서로 8% 포인트 이내의 차이를 보이며 성능을 발휘했습니다. Cursor의 @files 참조와 Composer 모드는 작업당 약 2030초 내에 관련 파일 전체에 변경 사항을 적용했습니다. Augment는 4050초에 가까운 시간이 걸렸지만 동일한 디프 (diffs)를 생성했습니다. 전체 코드베이스 인덱싱 (whole-codebase index)은 이 작업에서 별 도움이 되지 않았는데, 영향을 받는 파일 세트가 세 도구 모두가 구현하고 있는 LSP 기반 참조 조회 (LSP-based reference lookups)를 통해 아주 쉽게 발견될 수 있었기 때문입니다. 이름 변경 작업에 Context Engine을 과하게 사용하는 것은 자동차 키를 찾기 위해 인공위성을 사용하는 것과 같습니다.

카테고리 B는 Augment의 Context Engine이 제 가치를 증명하기 시작한 지점입니다. API 패턴, 에러 형식, 미들웨어 체인 (middleware chain), 또는 데이터베이스 액세스 계층 (database access layer)을 명시하지 않고 새로운 사용자 즐겨찾기 엔드포인트 (user-favorites endpoint)를 추가하라고 프롬프트를 입력했을 때, Augment는 프로젝트의 커스텀 createHandler 래퍼 (wrapper)를 사용하고, 올바른 형태의 프로젝트 AppError 클래스를 통해 에러를 반환하며, 파일을 src/routes/user/ 하위의 올바른 디렉토리에 배치하는 라우트 핸들러 (route handler)를 생성했습니다. Cursor의 첫 시도는 Express 스타일의 에러 핸들링을 사용했고 (프로젝트는 Fastify를 사용함), Copilot의 제안은 라우트 파일과 상단의 유틸리티 임포트 (utility imports) 3개만 확인했기 때문에 인증 미들웨어 (auth middleware)를 완전히 건너뛰었습니다. Augment는 이 카테고리의 그린필드 (greenfield) 작업 5개 중 4개에서 첫 시도에 엔드포인트를 정확히 구현했습니다. Cursor는 5개 중 2개를, Copilot은 1개를 성공했습니다.

Augment의 Context Engine은 코드베이스의 익숙하지 않은 부분을 작업할 때 가장 유용합니다. 어떤 파일을 수정해야 하는지, 그리고 파일들이 어떻게 연결되어 있는지 정확히 알고 있다면, Cursor의 더 빠른 탭 완성 (tab completion)과 낮은 지연 시간 (latency)이 더 나은 편집 경험을 제공합니다. 만약 3개의 서비스와 2개의 리포지토리 (repositories)에 걸쳐 있는 결제 흐름을 디버깅하고 있다면, Augment의 교차 리포지토리 인식 (cross-repo awareness) 기능은 각 파일을 일일이 열어 호출 체인 (call chain)을 수동으로 추적하는 데 걸릴 15분의 시간을 아껴줍니다.

Category C — 숨겨진 의존성을 가진 횡단 관심사 (cross-cutting) 변경 사항 — 는 Augment 방식의 한계를 드러냈습니다. 저는 세 가지 도구 모두에게 "parseQueryString 유틸리티가 예외를 던지는 대신 Result 타입을 반환하도록 업데이트하고, 모든 호출 지점 (call sites)을 수정하라"고 요청했습니다. Augment는 14개의 호출 지점을 모두 정확히 식별했지만, 그중 3곳에 대해 의미론적으로 잘못된 수정안을 생성했습니다. 구체적으로는 소비자가 배열 구문으로 반환 값을 구조 분해 할당 (destructuring) 하고 있던 호출 지점들이었습니다. Context Engine (컨텍스트 엔진)은 올바른 파일들을 찾아냈지만, 기반 모델 (당시 Sonnet)이 이러한 에지 케이스 (edge cases)에서의 TypeScript 타입 변환을 오해한 것입니다. 동일한 Sonnet 모델을 사용하는 Cursor는 동일한 3곳의 호출 지점에서 똑같은 실수를 저질렀으나, 전체 호출 지점을 14개가 아닌 11개만 식별했습니다. 인덱싱되지 않은 레거시 테스트 헬퍼 파일에 있는 3곳을 놓친 것입니다. 여기서 얻을 수 있는 교훈은 컨텍스트 검색 (context retrieval)이 필요하긴 하지만 그것만으로는 충분하지 않다는 점입니다. 모델은 여전히 전달받은 컨텍스트를 바탕으로 올바르게 추론할 수 있어야 합니다.

가격은 크레딧 기반이며, 크레딧은 생각보다 빨리 소진됩니다

Augment는 2025년 10월에 크레딧 기반 가격 모델로 전환했으며, "무제한 메시지"에서 "토큰 예산 관리"로의 사고방식 전환을 내재화하는 데 두 번의 결제 주기가 걸렸습니다. 가격 페이지에는 네 가지 플랜이 나열되어 있습니다: 월 20달러에 40,000 크레딧을 제공하는 Indie, 월 60달러에 130,000 크레딧을 제공하는 Standard, 월 200달러에 450,000 크레딧을 제공하는 Max, 그리고 맞춤형 가격을 제공하는 Enterprise입니다. 신용카드가 필요한 30,000 크레딧 규모의 체험판도 제공됩니다.

크레딧 소모율은 어떤 기반 모델 (underlying model)을 사용하는지에 따라 달라집니다. Sonnet에서 실행되는 일반적인 에이전트 작업 (agent task)은 약 290 크레딧을 소모합니다. Haiku에서 실행되는 가벼운 채팅 메시지는 대략 88 크레딧을 소모합니다. Indie 플랜의 40,000 크레딧을 기준으로 하면, 이는 약 137개의 Sonnet 기반 에이전트 작업 또는 454개의 Haiku 기반 채팅 턴에 해당합니다. 하지만 더 현실적으로는, 한 달에 약 2530개의 에이전트 작업과 150200개의 채팅 교환이 섞인 형태가 될 것입니다. 저는 적당한 일일 사용량으로 30,000 크레딧의 체험판을 9일 만에 다 썼는데, 이는 예상보다 빠른 속도였습니다. Context Engine MCP 쿼리는 쿼리당 40~70 크레딧의 별도 크레딧을 소모하며, 이는 MCP가 연결된 에이전트 세션을 실행할 때 누적됩니다.

비교를 위해 살펴보면, 월 20달러인 Cursor Pro는 더 느린 모델로 전환되거나 프리미엄 할당량을 가속화된 속도로 소모하기 전까지 약 500회의 빠른 프리미엄 요청을 제공합니다. 월 10달러인 Copilot Pro는 메시지 양 측면에서는 더 관대하지만, 코드베이스 인덱싱 (codebase indexing) 및 에이전트 기능이 부족합니다. Augment의 20달러 Indie 플랜은 Cursor Pro와 가격 면에서 경쟁력이 있지만, 사용량 측면에서는 유의미하게 적은 양을 제공합니다. 즉, 사용량을 포기하는 대신 컨텍스트의 깊이 (context depth)를 얻는 셈입니다. 월 60달러인 Standard 플랜은 Context Engine이 아껴 써야 하는 도구가 아닌, 일상적인 주력 도구 (daily driver)처럼 느껴지기 시작하는 지점입니다.

만약 파일 50,000개 미만의 단일 리포지토리 (repository)에서 작업한다면, 월 20달러의 Cursor Pro가 더 나은 가치를 제공합니다. 만약 서비스 간의 컨텍스트가 실제 버그를 방지해야 하는 여러 리포지토리를 가로질러 작업한다면, 월 60달러의 Augment Standard 플랜은 충분히 고려할 만한 가치가 있지만, 이를 유일한 AI 코딩 도구로 삼아서는 안 됩니다. 전체 코드베이스 인덱싱이 이점을 주지 않는 70%의 작업들을 위해 더 가벼운 어시스턴트와 병행하여 사용하십시오.

Augment Code의 대상과 대상이 아닌 사용자

Augment Code는 실질적인 문제를 해결합니다. 현재 파일만 보는 AI 코딩 어시스턴트(AI coding assistants)는 시간을 낭비하게 만드는 실수를 저지릅니다. 이러한 실수 중 일부는 프로젝트 컨벤션(conventions)과 충돌하는 변수명을 제안하는 것과 같은 짜증스러운 일입니다. 다른 것들은 버그입니다. 예를 들어, 어시스턴트가 미들웨어(middleware) 등록 파일을 본 적이 없기 때문에 프로젝트의 다른 모든 핸들러를 감싸고 있는 미들웨어를 무시하는 함수 호출을 하는 식입니다. Context Engine은 이러한 범주의 오류를 완전히 제거합니다.

문제는 대부분의 코딩 작업에는 전체 코드베이스(whole-codebase)의 컨텍스트(context)가 필요하지 않음에도 불구하고, 필요 여부와 상관없이 모든 작업에 대해 인덱싱 아키텍처(indexing architecture) 비용을 지불해야 한다는 점입니다. 일반적인 업무 주간 동안 저의 마지막 100가지 코딩 상호작용을 기록해 보면, 약 70개는 인라인 완성(inline completions)이고, 20개는 단일 파일 편집 또는 설명이며, 10개는 다중 파일 리팩터링(refactors) 또는 아키텍처 관련 질문입니다. Context Engine은 이 10가지 상호작용에서 결과물의 품질을 유의미하게 향상시킵니다. 하지만 나머지 90가지 작업에서는 제안 품질을 변화시키지 않는 컨텍스트 검색(context retrieval)에 대해 지연 시간(latency)과 크레딧(credit) 페널티를 지불하고 있는 셈입니다.

저는 Context Engine이 중요한 10가지 상호작용, 즉 리포지토리 간 디버깅(cross-repo debugging) 세션이나 어시스턴트가 명시되지 않은 프로젝트 컨벤션을 따르기를 원하는 신규 기능 추가(greenfield feature additions) 작업에는 계속해서 Augment를 사용할 것입니다. 하지만 일상적인 인라인 완성 제공자로 사용하지는 않을 것입니다. 만약 Augment가 세션 단위가 아닌 프롬프트(prompt) 단위로 Context Engine을 토글할 수 있는 모드를 출시한다면, 가치 제안(value proposition)은 상당히 달라질 것입니다.