워크숍은 모든 장난감을 알고 있습니다 — Context Engine 🧠

함께 제공되는 소스 코드 저장소: Santa Augmentcode Intent

사람들은 자주 묻습니다: 엘프들은 어떻게 무엇이든 만드는 법을 알까요? 우리는 정식 대학교를 운영하지 않습니다. 엘프 아카데미 같은 것도 없습니다. 답은 바로 워크숍 라이브러리(Workshop Library)입니다. 이는 서기 843년부터 모든 크리스마스에서 얻은 모든 장난감 설계도, 모든 재료 데이터 시트, 모든 기술 매뉴얼, 그리고 모든 교훈이 담긴 살아있는 컬렉션입니다. 엘프가 작업대에 앉을 때, 그들은 아무것도 없는 상태에서 시작하는 것이 아닙니다. 그들은 12세기에 걸쳐 축적된 지식 위에 서 있는 것입니다. Augment는 이것의 버전을 Context Engine (컨텍스트 엔진)이라고 부릅니다. 나는 이것을 필수적이라고 부릅니다.

모든 AI 도구가 가진 문제점

대부분의 AI 코딩 도구는 한 가지 근본적인 한계를 공유합니다. 그들은 일반적인 프로그래밍에 대해서는 아주 많이 알고 있지만, 특히 당신의 코드베이스(codebase)에 대해서는 거의 아무것도 모른다는 점입니다.

범용 AI 어시스턴트에게 당신의 애플리케이션에 기능을 추가해 달라고 요청하면, 컴파일은 되지만 다음과 같은 결과물을 내놓을 수 있습니다. 당신의 명명 규칙(naming conventions)을 무시하거나, 이미 가지고 있는 유틸리티를 중복 생성하거나, 6개월 전에 내린 아키텍처 결정과 충돌하거나, 팀이 몇 주 동안 구축해 온 보안 패턴(security pattern)을 위반할 수 있습니다.

AI는 자신이 무엇을 모르는지 모릅니다. 그리고 그가 모르는 것이 바로 당신에게 특화된 모든 것입니다.

Context Engine이 하는 일

Augment의 Context Engine은 단순히 당신이 열어놓은 파일뿐만 아니라 다음의 모든 것에 대해 **전체 스택에 대한 실시간 시맨틱 이해 (live, semantic understanding)**를 유지함으로써 이 문제를 해결합니다:

• 코드 (Code): 전체 저장소에 걸친 모든 파일, 클래스(class), 함수(function), 인터페이스(interface).
• 의존성 (Dependencies): 당신이 사용하는 라이브러리와 그것을 사용하는 방식.
• 문서 (Documentation): 인라인 주석(inline comments), README, 아키텍처 문서.
• 스타일 (Style): 당신의 명명 규칙(naming conventions), 코드 패턴, 포맷팅 선호도.
• 최근 변경 사항 (Recent changes): 무엇이, 언제, 왜 변경되었는지 (커밋 메시지와 PR로부터).
• 이슈 (Issues): 트래커에 있는 오픈 티켓(open tickets) 및 알려진 문제들.

Context Engine은 이를 단순히 평면적인 텍스트(flat text)로 저장하지 않습니다. 이는 **의미론적 이해 (semantic understanding)**를 구축합니다. 즉, UserAuthService가 TokenRepository에 의존한다는 사실, 코드베이스 전반에서 의존성 주입 (dependency injection)을 사용한다는 사실, 그리고 팀이 6주 전에 모든 서명 작업에 RS256을 사용하기로 합의했다는 사실을 알고 있습니다.

Intent에서 Specialist Agent가 생성될 때, 전체 코드베이스의 가공되지 않은 덤프(raw dump)를 전달받는 것이 아닙니다 (이는 어떤 모델의 컨텍스트 윈도우 (context window)도 초과할 것입니다). Context Engine은 관련 컨텍스트를 **큐레이션 (curates)**합니다. 4,456개의 잠재적 소스 중에서 이 작업에 실제로 관련 있는 682개를 선택합니다. 엘프(Elf)는 도서관 전체가 아니라, 자신이 만들고 있는 장난감에 딱 맞는 설계도를 전달받습니다.

북극 도서관 비유 (The North Pole Library Analogy)

당신의 워크숍(Workshop)에 12세기 분량의 장난감 설계도가 들어있다고 상상해 보세요. Context Engine이 없던 시절에는, 엘프가 도서관으로 걸어가 한 시간 동안 검색을 하고, 관련 있는 설계도 3개를 찾아낸 뒤, 나머지는 추측에 의존해야 했습니다. 느리고, 불완전하며, 오류가 발생하기 쉬웠습니다.

Context Engine이 있다면, 도서관은 살아있고 지능적입니다. 엘프가 장난감 기관차를 만들도록 배정되는 순간, 도서관은 자동으로 다음 사항들을 표면 위로 끌어올립니다:

• 지난 10년 동안 제작된 모든 기관차 (사용된 코드 패턴 포함).
• 워크숍이 2019년에 채택한 바퀴 표준.
• 모든 바퀴 달린 장난감에 적용되는 페인트 사양.
• 모든 차량이 통과해야 하는 안전 테스트.
• 이 기관차의 선로와 일치해야 하는 Gauge Elf의 진행 중인 작업.

엘프는 완전한 상황 인식 (situational awareness)을 갖춘 상태로 시작합니다. 실수로 오래된 바퀴 표준을 사용하지 않을 것입니다. 3년 전에 누군가 작성한 페인트 사양 유틸리티를 중복해서 만들지도 않을 것입니다. 옆에서 진행 중인 작업과 충돌하는 선로 게이지를 만들지도 않을 것입니다.

이것이 멀티 에이전트 작업 (Multi-Agent Work)에 중요한 이유

단일 에이전트 워크플로우 (single-agent workflows)에서 제한된 컨텍스트는 단순히 불편함의 문제입니다. 에이전트가 정리가 필요한 약간 일반적인 코드를 생성할 뿐입니다.

멀티 에이전트 워크플로우 (multi-agent workflows)에서 제한된 컨텍스트는 단순한 불편함이 아니라 **조정 실패 (coordination failure)**입니다. 만약 에이전트 A가 에이전트 B가 RS256 서명을 사용하고 있다는 사실을 모른다면, 에이전트 A는 다른 알고리즘으로 자체 서명을 구현할 수도 있습니다. 검증기 (Verifier)가 이를 잡아내겠지만, 이는 두 에이전트가 이미 상당한 작업을 마친 후이며, 이제 그 작업들을 다시 조정해야 하는 상황에서나 가능합니다.

Context Engine은 모든 에이전트가 시작부터 코드베이스에 대해 동일한 이해를 공유하도록 보장함으로써 이를 방지합니다. 코디네이터 (Coordinator)가 명세 (spec)를 작성할 때, 해당 지식을 가용할 수 있기 때문에 _"서명에는 RS256을 사용하세요 — *auth/signing.ts*의 기존 패턴을 참조하십시오"_라고 선언할 수 있습니다. 명세를 읽는 모든 전문가 (Specialist)는 해당 컨텍스트를 상속받습니다.

Context Engine vs Vanilla Models: 수치 비교

Augment는 Elasticsearch 리포지토리(360만 줄의 Java 코드, 2,187명의 기여자)에서 에이전트 성능을 비교한 벤치마크를 발표했습니다. Context Engine을 기반으로 하는 Augment의 에이전트는 500개의 에이전트 생성 풀 리퀘스트 (pull requests)에 대한 블라인드 평가에서 다른 도구들보다 뛰어난 성능을 보였습니다:

기준	Augment	기타
종합	우수함	미흡함
...

가장 큰 격차는 **코드 재사용 (code reuse)**과 **베스트 프랙티스 준수 (best practice adherence)**에서 나타났으며, 이는 바로 코드베이스를 아는 것이 가장 중요한 차원을 의미합니다. 어떤 모델이든 컴파일 가능한 코드는 작성할 수 있습니다. 하지만 새로운 것을 작성하는 대신 기존 유틸리티를 언제 재사용해야 하는지를 아는 데에는 컨텍스트가 필요합니다.

Context Engine이 의도 (Intent)에 구체적으로 기여하는 방식

Intent 내부에서 Context Engine은 세 가지 별도의 소비자에게 서비스를 제공합니다:

**코디네이터 (The Coordinator)**는 더 나은 명세를 작성하기 위해 이를 사용합니다. 기존 아키텍처를 알고 있을 때, 상상 속의 의존성이 아닌 실제 의존성을 존중하는 작업 분해 (task decompositions)를 제안할 수 있습니다.

**전문가 (The Specialists)**는 더 나은 코드를 작성하기 위해 이를 사용합니다. 이들은 자신이 준수해야 하는 패턴, 유틸리티, 인터페이스를 알고 있습니다.

Verifier는 코드베이스에 대한 지식이 있어야만 식별할 수 있는 명세 위반(spec violations)을 잡아내기 위해 이를 사용합니다. “이 코드는 기존의 속도 제한 (rate-limiting) 미들웨어를 우회합니다”라는 코멘트는 Verifier가 해당 미들웨어가 존재한다는 사실을 알고 있을 때에만 유용한 정보가 됩니다.

SIPOC: Context Engine의 실제 작동 방식

	S — 공급자 (Suppliers)	I — 입력 (Inputs)	P — 프로세스 (Process)	O — 출력 (Outputs)	C — 고객 (Customers)
Who/What	저장소 (Repository), CI/CD 이력, 문서, 이슈, 최근 변경 사항	원시 코드베이스 파일, 의존성 매니페스트 (dependency manifests), 커밋 이력, 티켓	인덱싱 (Index) → 의미론적 분석 (Semantic analysis) → 관련성 순위 지정 (Relevance ranking) → 작업별 컨텍스트 큐레이션 (Context curation)	각 에이전트를 위한 큐레이션된 작업 관련 컨텍스트	코디네이터 에이전트 (Coordinator Agent), 모든 전문가 에이전트 (Specialist Agents), Verifier 에이전트
Workshop	Workshop 라이브러리 (12세기의 설계도)	모든 장난감 설계, 재료 사양, 역사적 결정 사항	라이브러리 카탈로그 → 의미론적 검색 (Semantic search) → 엘프별 관련 설계도 선택	각 작업대(workbench)에 정확히 맞는 재료와 참조 자료	모든 엘프, 산타클로스, 품질 관리 (Quality Control)

개인정보 보호에 관한 참고 사항

산타클로스는 개인정보 보호를 매우 중요하게 생각합니다. Augment 역시 마찬가지입니다. Context Engine은 인덱스를 구축하기 위해 귀하의 코드베이스를 처리하며, Augment의 Trust Center는 데이터가 어떻게 처리되는지 문서화하고 있습니다. 민감한 코드베이스를 보유한 엔터프라이즈 팀의 경우, 라이브러리를 엔진에 넘겨주기 전에 이를 검토할 가치가 있습니다.

다음 단계

에피소드 7에서는 이 모든 것을 하나로 통합합니다. 여러 명의 엘프가 혼란 없이 동시에 작업하는 모습, 즉 멀티 에이전트 오케스트레이션 (Multi-Agent Orchestration) — 충돌, 혼란, 또는 크리스마스의 재앙 없이 병렬 워크숍을 운영하는 기술을 다룹니다.

컨텍스트가 없는 엘프는 값비싼 추측을 하는 엘프일 뿐입니다. 그들에게 라이브러리를 주십시오. 그들에게 Context Engine을 주십시오. 그들이 기적을 만들어내는 것을 지켜보십시오. 허허허! 🎅

이 글은 Santa Augmentcode Intent 시리즈의 일부입니다. dev.to의 the-software-s-journey 조직 아래 게시되었습니다.