코딩된 지능형 에이전트에 고급 컨텍스트 엔지니어링 적용 Human Layer의 창립자 @dexhorthy는 개인적인 경험과 실제 사례를 바탕으로 프로토타입에서 프로덕션 수준 코드로의 변환을 강조하며, 그 핵심은 LLM의 "컨텍스트 창"을 최적화하는 것입니다. 즉, 모델 입력 정보의 품질과 구조를 최적화하는 것입니다. 배경: 컨텍스트 엔지니어링의 기원과 AI 코딩의 진화 덱스는 "컨텍스트 엔지니어링"이라는 용어의 기원을 추적했습니다. 2022년 4월, 그는 신뢰할 수 있는 LLM 애플리케이션을 위한 12가지 원칙을 제시하는 "12 Factor Agents" 선언문을 발표했습니다. 2024년 6월, 이 용어는 더욱 널리 알려지게 되었습니다. 그는 올해 AI 엔지니어 컨퍼런스에서 열린 두 기조연설을 인용했습니다. 션 그로브의 "The New Code"는 코드 자체가 아니라 사양이 소프트웨어의 미래에 핵심적이라고 강조했습니다. 스탠퍼드 대학교에서 10만 명의 개발자 데이터를 분석한 연구 결과, AI 코딩은 프로토타입 제작 속도를 높일 수 있지만, 대규모 엔터프라이즈 또는 레거시 코드 환경에서는 재작업이나 심지어 역효과를 초래하는 경우가 많다는 것을 발견했습니다. 반면 AI가 생성한 코드는 복잡한 작업의 재작업률을 최대 50%까지 높일 수 있습니다. Dex는 현재 모델이 복잡한 시스템(경쟁 조건 및 종료 순서가 포함된 Go 애플리케이션 등)에서 사람이 작성한 코드를 완전히 대체할 수 없다고 생각합니다. 따라서 컨텍스트 엔지니어링의 목표는 기존 모델의 최대 가치를 "압축"하는 것입니다. 즉, 출력의 정확도와 효율성을 향상시키기 위해 입력을 신중하게 설계하는 것입니다. 핵심 과제: 기존 AI 코딩 방법이 실패하는 이유는 무엇인가? • 순진한 촉구: 에이전트와 반복적으로 대화(예: "아니요, 다시 시도하세요")를 하는 것만으로도 맥락 창이 쉽게 소진되어 모델이 방향 감각을 잃거나 "노이즈"(무의미한 정보)가 생성될 수 있습니다. • 컨텍스트 병목 현상: LLM은 본질적으로 "순수 함수"입니다. 출력 품질은 입력에 따라 달라집니다. 코딩 에이전트의 반복적인 프로세스(파일 검색, 프로세스 이해, 코드 편집)는 창을 빠르게 채워 정보 과부하, 누락 또는 오류를 유발합니다. • 팀의 고충: AI가 생성한 2만 줄짜리 PR은 검토하기 어려워 팀 간 단절을 초래합니다. Dex는 개인적인 경험을 공유했습니다. 최고의 AI 코더들과 함께 일할 때, 그는 코드 줄 단위 검토를 포기하고 사양서에 의존하여 "놓아야" 했습니다. 목표: 대규모 복잡한 코드베이스에 적합하며, 실제 문제를 해결하고, "쓰레기" 코드가 없으며, 프로덕션 등급의 출력을 제공하고 토큰 활용을 극대화합니다. 핵심 전략: 압축에서 워크플로 리팩토링까지 덱스는 "모든 것을 위한 컨텍스트 엔지니어링"이라는 개념을 제안하며, 정확성(잘못된 정보 없음), 완전성(누락된 정보 없음), 크기(노이즈 제어), 궤적(방향 유지)의 네 가지 차원을 최적화했습니다. 그는 비효율적인 도구(예: 간단한 /slashcompact 명령)를 피하고 대신 다음과 같은 고급 방법을 채택했습니다. 1. 의도적인 압축: 간단한 재시작 대신, 주요 요약 정보(파일 경로, 변경 의도, 테스트 계획 등)를 기록하는 "진행 파일"이 생성됩니다. 이 파일은 원본 코드보다 훨씬 짧아 후속 프록시가 컨텍스트를 상속하기 쉽습니다. • 정형화된 사고: 효과적인 토큰 ≈ 총 토큰(약 17만 개) - 불필요한 토큰. Dex는 Jeff Huntley의 "Ralph Wigum as a Software Engineer" 글을 인용하여 무작위로 반복하는 대신 동일한 프롬프트를 반복하는 것이 결과를 크게 향상시킬 수 있음을 증명합니다. 2. 하위 에이전트의 컨텍스트 제어: • 주요 맥락을 왜곡하지 않고 "정보 흐름 찾기"와 같은 작업을 분리하는 데 사용됩니다. 하위 에이전트는 구조화된 응답(예: 파일 이름 + 줄 번호)을 반환하여 "전화 게임"과 같은 정보 왜곡을 방지합니다. 과제: 비결정적 시스템은 혼란을 일으키기 쉽기 때문에 부모 에이전트가 자식 에이전트에게 지시하는 방법에 대한 정확한 지침이 필요합니다. 3. 빈번한 의도적 압축 및 3단계 워크플로: • 조사 단계: 오픈 소스 프롬프트 템플릿을 사용하여 시스템 개요(파일, 데이터 흐름, 문제 위치)를 생성합니다. 출력 내용은 간결하여 담당자의 신속한 위치 파악이 용이합니다. • 계획 단계: 담당자는 모든 변경 사항(문서, 코드 조각, 검증 단계)을 나열하여 "구현 계획"을 수립해야 합니다. 계획은 일반적으로 코드보다 짧고 사람이 검토하기 쉽습니다. • 구현 단계: 계획 코딩을 기반으로 컨텍스트 사용률을 40% 미만으로 유지합니다. 각 단계가 완료되면 계획을 업데이트하고 새 창을 다시 시작합니다. • 전체 사이클: 연구 → 계획 → 구현 → 직접 검토 → 반복. Dex는 200줄의 계획을 검토하는 것이 2000줄의 코드를 검토하는 것보다 훨씬 낫다고 강조합니다. 오류를 조기에 발견하고 팀의 "정신적 일치"를 유지할 수 있기 때문입니다. 이는 코드 검토의 핵심 가치입니다. 이 프롬프트 템플릿은 오픈 소스이며 GitHub에서 찾을 수 있습니다. Dex는 "마법처럼 되는 게 아니라, 주의 깊게 읽고 수정해야 합니다."라고 인정합니다. 실제 사례 연구: Rust 수정부터 WASM 통합까지 · Rust 코드베이스 수정: Dex는 또 다른 YC 창립자인 Vibhav(BAML 제작자)와 협력하여 30만 줄에 달하는 Rust 코드베이스의 버그를 한꺼번에 수정했습니다. 이 과정은 75분 분량의 팟캐스트에 기록되었고, 최종 PR은 CTO에 의해 조용히 통합되었습니다. 이를 통해 기존 시스템에도 적용 가능하고 재작업이 필요 없음이 입증되었습니다. • 복잡한 문제 해결: Boundary CEO와 협력하여 WASM 지원을 추가하여 7시간 만에 35,000줄의 코드를 생성/작성했습니다. 이는 1~2주간의 엔지니어링 작업에 해당하는 작업입니다. 이를 통해 운영 환경에서 전략의 실현 가능성을 검증했습니다. 시사점 및 미래 전망 Dex의 핵심 통찰: 코드 오류는 업스트림에서 발생합니다. 잘못된 연구는 수천 줄의 잘못된 코드로 이어질 수 있으며, 잘못된 계획은 이를 수백 배로 증폭시킵니다. 따라서 코드 세부 사항에 얽매이기보다는 사양과 시스템 이해에 투자하는 것을 우선시해야 합니다. 그의 팀(3명)은 한 달 만에 많은 API 크레딧을 사용했지만, 엔지니어링 시간을 상당히 절약했습니다. 인턴들은 첫날에 2개의 PR을 제출했고, 8일째에는 10개의 PR을 제출했습니다. Dex 자신도 두 달 동안 마크다운이 아닌 파일을 열지 않았습니다. 전망: 코딩 에이전트는 점차 상품화되는 경향이 있지만, 가장 큰 과제는 팀 혁신(사양 우선 및 잦은 검토)입니다. 휴먼 레이어는 6명의 Y Combinator 스타트업에서 수천 명의 직원을 보유한 대기업으로의 이러한 변화를 지원하고 있습니다. 비디오 주소:
