안녕하세요, Maneshwar입니다. 저는 모든 커밋에서 실행되는 마이크로 AI 코드 리뷰어인 git-lrc를 구축하고 있습니다. 이는 Github에서 무료로 사용할 수 있으며 소스 코드가 공개되어 있습니다. 개발자들이 이 프로젝트를 발견할 수 있도록 git-lrc에 Star를 눌러주세요. 꼭 한 번 사용해 보시고 피드백을 공유해 주세요.

컨텍스트 엔지니어링 (context engineering) 시리즈의 3부이자 필라 투어 (pillar tour)의 대미를 장식하는 글입니다. 1부가 지도(map)였다면, 2부는 압축(compaction)이었습니다. 이번 편은 근본적인 전제에 의문을 제기하는 움직임에 관한 것입니다. 애초에 왜 모든 것을 하나의 책상 위에 몰아넣고 있는 걸까요?

여러분은 이 에이전트 (agent)를 만나본 적이 있을 것입니다. 직접 만들어 보았을지도 모릅니다.

그것은 모든 것을 수행합니다.

지원 티켓에 답변하고, 코드를 작성하며, 데이터베이스를 쿼리(query)하고, 고객 사과 이메일 초안을 작성합니다. 도구 (tool)를 하나 더 추가하면, 여러분의 화분에 물까지 줄 수도 있습니다. xD

하나의 장엄한 시스템 프롬프트 (system prompt), 하나의 거대한 컨텍스트 윈도우 (context window), 그리고 상상할 수 있는 모든 기능이 결합되어 있습니다.

하지만 그 모든 면에서 평범한 성능을 보입니다.

1부에서 저는 이것을 파티에서 세금 신고를 하는 것과 인지적으로 유사한 상태라고 불렀습니다.

SQL 지침이 이메일 작성 지침과 뒤섞여 버립니다.

모델에 필요한 도구는 필요하지 않은 9개의 도구 아래에 파묻혀 있습니다.

한 작업의 정보가 다른 작업에 오염을 일으킵니다.

윈도우 (window)가 압축 (compaction)에서 우려하는 방식처럼 '가득 찬' 것이 아니라, 잘못된 '종류'의 것들이 동시에 가득 차서 모델의 주의 (attention)를 끌기 위해 서로 팔꿈치로 밀치고 있는 상태입니다.

지금까지의 시리즈 전체는 하나의 책상을 잘 관리하는 법, 즉 책상을 비우고, 큐레이션(curating)하고, 압축하는 법에 관한 것이었습니다.

격리 (Isolation)는 "왜 책상이 하나여야 하는가?"라는 이단적인 질문을 던지는 기둥입니다.

작업당 하나의 책상

격리는 설명하기 간단합니다. 각 작업에 해당 작업에 필요한 지침, 도구, 정보만을 포함하는 깨끗하고 전용된 컨텍스트 (context)를 부여하는 것입니다.

모든 것을 아는 하나의 전지전능한 에이전트 대신, 몇 개의 집중된 에이전트를 실행합니다.

리서치 에이전트 (research agent)는 여러분의 코드 스타일 가이드를 받지 않습니다.

코더 (coder)는 환불 사과를 어떻게 표현해야 하는지 알 필요가 없습니다.

각 컨텍스트는 작고 날카로우며 오염되지 않은 상태를 유지하며, 한 곳의 혼란이 다른 곳으로 새어 나가지 않습니다.

이를 실제로 구현하는 데에는 두 가지 방법이 있으며, 두 방법은 무게감이 매우 다릅니다.

무거운 방법: 서브 에이전트 (sub-agents)

격리의 가장 대표적인 형태는 서브 에이전트 (sub-agents)를 생성하는 것입니다.

오케스트레이터 (orchestrator)는 서브 에이전트에게 전체 대화 기록이 아닌, "사용자 데이터를 수정하는 모든 API 엔드포인트를 찾으세요"와 같이 압축된 (compressed) 작업을 전달합니다.

서브 에이전트는 새로운 윈도우 (window)를 할당받아 자유롭게 탐색하고, 30개의 파일을 읽고, 10번의 검색을 수행하며, 난잡한 과정을 거칩니다.

그 후 서브 에이전트는 단 한 가지, 즉 500토큰 분량의 답변만을 반환합니다.

오케스트레이터는 30개의 파일을 결코 보지 못합니다. 오직 답변만을 봅니다.

이러한 비대칭성 (asymmetry)이 핵심입니다.

비용이 많이 들고 소음이 많은 탐색 과정은 버려질 컨텍스트 (context) 내부에서 발생하며, 정제된 결과물만이 메인 대화로 살아남습니다. Claude Code는 정확히 이 방식을 사용합니다. 탐색, 계획, 문서 조회 등을 위해 각각 별도의 윈도우에서 실행되는 전용 서브 에이전트들을 활용하며, 작업이 독립적인 경우 이들은 병렬로 실행됩니다.

Anthropic의 자체 멀티 에이전트 연구원 (multi-agent researcher)에 따르면, 격리된 컨텍스트를 가진 여러 에이전트가 단일 에이전트보다 성능이 뛰어난 것으로 나타났습니다. 이는 각 서브 에이전트의 윈도우가 모든 질문에 분산되지 않고, 하나의 좁은 질문에 온전히 집중될 수 있었기 때문입니다.

한 줄로 요약하자면 다음과 같습니다:

서브 에이전트는 읽기를 수행하고, 오케스트레이터는 요약본을 받습니다. 난잡한 과정은 격리된 상태로 유지됩니다.

가벼운 방법: 에이전트가 아닌 _대상_을 격리하기

항상 두 번째 두뇌가 필요한 것은 아닙니다.

종종 여러분에게 필요한 것은 그저 무거운 객체를 모델의 눈앞에서 치우는 것뿐입니다.

비결은 이렇습니다. 작업은 특정 환경 (environment)에서 수행하게 하고, 모델에는 페이로드 (payload) 대신 _참조 (reference)_를 전달하는 것입니다.

HuggingFace의 CodeAgent는 도구 호출 (tool calls)을 샌드박스 (sandbox) 내에서 코드로 실행합니다. 따라서 5MB 크기의 이미지나 거대한 로그 덩어리가 환경 내의 변수로 존재할 수 있으며, 모델은 바이트 (bytes) 데이터가 아닌 해당 변수에 대한 핸들 (handle)을 받게 됩니다.

런타임 상태 객체 (runtime state object)를 사용하는 것도 같은 아이디어입니다. 토큰 소모가 많은 도구 출력값은 LLM이 보지 못하는 필드에 기록하고, 이번 턴에 필요한 필드만 노출하는 방식입니다.

이 방식이 익숙하게 들린다면 당연한 결과입니다. 이는 격리 (isolation)라는 모자를 쓰고 있는 '쓰기/외부 메모리 (write/external-memory)' 기둥이기 때문입니다.

집중을 방해하지 않도록 무언가를 책상 밖으로 치워두는 행위는, 그것을 "메모리 (memory)"라고 부르든 "격리 (isolation)"라고 부르든 동일한 몸짓입니다.

이 기둥들은 항상 서로 다른 의상을 입고 있는 동일한 아이디어였습니다.

청구서가 도착합니다

격리 (isolation)는 가장 강력한 기둥인 동시에 가장 비용이 많이 드는 기둥이므로, 이를 사용하기 전에 트레이드오프 (tradeoffs)에 대해 솔직해져야 합니다.

이는 토큰 (tokens) 비용을 발생시킵니다. Anthropic의 보고에 따르면 멀티 에이전트 (multi-agent) 설정은 단일 채팅보다 최대 15배 더 많은 토큰을 소모합니다.

또한 조정 (coordination) 비용이 발생합니다. 누군가는 서브 에이전트 (sub-agents)를 계획하고, 작업을 라우팅 (route)하며, 결과를 다시 하나로 엮어야 합니다. 그리고 이러한 오케스트레이션 (orchestration) 자체가 별도의 프롬프트 엔지니어링 (prompt-engineering) 문제입니다.

그리고 토큰 비용 이면에는 더 날카로운 실패 요인이 존재합니다.

격리는 독립적인 작업에는 아름답게 작동하지만, 상호 의존적인 작업에는 나쁘게 작동합니다.

두 개의 서브 에이전트가 병렬로 서로 다른 질문을 탐색하나요? 좋습니다, 그것이 바로 격리가 존재하는 이유입니다.

두 개의 서브 에이전트가 서로 맞물려야 하는 코드를 작성하는데, 각자가 상대방이 무엇을 결정했는지 모른다면 어떨까요? 이제 당신은 모순된 가정 위에 구축된 기능의 두 조각을 갖게 될 것이며, 오케스트레이터 (orchestrator)는 통합 (integration) 시점에 그 충돌을 발견하게 될 것입니다.

서브태스크 (subtasks) 간의 합의가 필요한 상황에서 멀티 에이전트는 과장되었다고 생각하는 개발자 진영이 실제로 존재합니다. 컨텍스트 (context)를 분리하는 것은 곧 불일치를 제조하는 방식이라는 이유에서입니다.

따라서 경험 법칙은 "바쁜 작업을 격리하라"가 아닙니다. 다음과 같습니다:

바쁨이 아니라 독립성에 따라 격리하라.

만약 두 작업이 서로 일관성을 유지해야 한다면, 그들은 아마도 같은 책상을 원할 것입니다. 만약 그들이 진정으로 서로 접촉하지 않는다면 — 병렬 연구, 읽기 전용 탐색, 일회성 조사 등 — 각각에게 전용 책상을 주고 실행하게 하십시오.

재조립된 책상

이것이 마지막 기둥이며, 이는 우리가 마침내 한 걸음 물러나 전체를 볼 수 있음을 의미합니다.

기둥	답변하는 질문
외부 메모리 (External memory)	지식이 책상 위에 없을 때 어디에 존재하는가?
...

그 테이블을 응시하면 이 시리즈 전체의 핵심 결론이 드러납니다: 그것들은 모두 동일한 움직임입니다.

그것들 각각은 희소하고 유한한 책상, 즉 컨텍스트 윈도우 (context window)에 대한 결정입니다. 모델이 정확히 필요한 것만 보고, 필요 없는 것은 보지 않도록 말이죠.

방해가 되지 않도록 기록해 두세요.

관련이 있을 때만 다시 불러오세요.

내용이 비대해지면 압축하세요.

작업들이 서로 간섭하면 분리하세요.

이 중 그 어떤 것도 대문자로 모델에게 애걸하는 것이 아닙니다.

이것은 어떤 정보를 어디에, 언제 배치할지 결정하는 지루하고도 신중한 작업입니다.

파트 1을 마칠 때 사용했던 문장은 여전히 유효하며, 이 시리즈를 마무리하기에도 적절한 문구입니다:

프롬프트 (prompt)는 질문입니다. 컨텍스트 (context)는 답변을 훌륭하게 만드는 모든 것입니다.

면책 조항: 이 글은 제가 작성하였으며, 문법 교정 및 가독성 향상을 위해 AI가 사용되었습니다.

AI 에이전트 (AI agents)는 코드를 빠르게 작성합니다. 하지만 사용자에게 알리지 않고 조용히 로직을 제거하거나, 동작을 변경하고, 버그를 유발하기도 합니다. 여러분은 종종 운영 환경 (production)에 도달해서야 이를 발견하게 됩니다.

git-lrc가 이를 해결합니다. git 커밋 (commit)에 연결되어 모든 차이점 (diff)이 반영되기 전에 검토합니다. 60초면 설정이 완료됩니다. 완전히 무료입니다.

모든 피드백과 기여자를 환영합니다! 온라인에서 소스 코드를 확인할 수 있으며, 누구나 사용할 준비가 되어 있습니다.

⭐ GitHub에서 Star를 눌러주세요:

HexmosTech / git-lrc

커밋 시 실행되는 무료 마이크로 AI 코드 리뷰

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |

git-lrc

커밋 시 실행되는 무료 마이크로 AI 코드 리뷰

오늘날의 생성형 AI (GenAI)는 브레이크 없는 레이싱 카와 같습니다. 무언가를 설명하기만 하면 방대한 양의 코드가 즉시 나타나며 빠르게 가속합니다. 하지만 AI 에이전트는 사용자에게 알리지도 않은 채 조용히 문제를 일으킵니다. 로직을 제거하거나, 제약 조건을 완화하고, 비용이 많이 드는 클라우드 호출을 도입하며, 자격 증명 (credentials)을 유출하고, 동작을 변경해 버립니다. 그리고 당신은 종종 이를 운영 환경 (production)에서야 발견하게 됩니다.

git-lrc는 당신의 제동 시스템입니다. 이 도구는 git commit에 연결되어, 변경 사항 (diff)이 반영되기 전에 모든 차이점에 대해 AI 리뷰를 실행합니다. 설정에는 60초면 충분하며, 완전히 무료입니다.

요약하자면, git-lrc는 장애, 보안 침해, 그리고 기술 부채 (Technical Debt)가 발생하기 전에 이를 방지하도록 돕습니다.

한눈에 보기: 10가지 위험 카테고리 · 100개 이상의 실패 패턴 추적 · 모든 커밋...