<div id="readability-page-1" class="page"><div id="SE-aa5a987d-6400-402a-915b-30128ffc9a88">
 컨텍스트 엔지니어링Anthropic은 2025년 9월, "컨텍스트 윈도우에 들어가는 다섯 가지 요소 — 시스템 프롬프트, 사용자 입력, 대화 히스토리, 도구 결과, 검색된 지식 — 의 배합을 최적화하는 기술이라는 것입니다. 고객 지원 에이전트를 만든다고 해봅시다. 이 네 전략이 어떻게 작동하는지 따라가 봅시다.<ul><li>Write (작성): 시스템 프롬프트를 "고객 지원 에이전트입니다. 환불 정책은 30일입니다. 기"처럼 명확하고 구조화된 형태로 작성합니다. "무엇을 말할 것인가"가 아니라 "어떻게 구조화할 것인가"가 핵심입니다.</li><li>Select (선택): 고객이 "주문 취소"라고 하면, 전체 FAQ가 아니라 취소/환불 관련 문서만 골라 컨텍스트에 넣습니다. </li><li>Compress (압축): 고객과 20턴 대화를 나눴다면, 초반 15턴을 "고객이 제품 X의 환불을 요청, 영수증 확인 완료, 배송비 문의 중"으로 요약합니다.</li><li>Isolate (격리): 고객이 기술 문제를 보고하면, 진단 서브에이전트에게 별도로 위임합니다. </li></ul>​Google ADK는 컨텍스트 윈도우를 구체적으로 두 영역으로 나눕니다.<ul><li>안정 접두어 (Stable Prefix): 시스템 프롬프트, 에이전트 정체성, 도구 정의, 장기 요약 — 자주 변하지 않는 것을 앞쪽에 배치</li><li>동적 접미어 (Variable Suffix): 최신 사용자 입력, 새로운 도구 출력 — 자주 변하는 것을 뒤쪽에 배치</li></ul>​<ul><li>컨텍스트 윈도우에 한계가 있다는 걸 인정하라. </li><li>자연어보다 구조화된 출력을 써라. JSON 같은 구조화된 형식</li><li>Human-in-the-loop를 설계 시점에 넣어라. "나중에 사람 승인 기능을 추가하겠다"가 아니라.</li></ul>​<ul><li>2024년 11월 : MCP: 도구 연결의 표준이 되다, 도구 결과가 컨텍스트 윈도우의 핵심 구성 요소</li><li>스킬 : 도구가 함수라면, 스킬은 함수 여러 개를 조합한 모듈(작업 흐름 캡슐화), 지연 로딩</li><li>서브에이전트 : 메인 에이전트가 특정 작업을 위임하는 하위 에이전트입니다. "Isolate(격리)" 전략</li><li>스웜 : 오케스트레이션 패턴. 루틴(routine)과 핸드오프(handoff).</li><li>Context Hub : 검증된 최신 문서를 체계적으로 관리하고 주입, 최신 API 문서를 실시간 검색</li><li>메모리: 세션을 넘어서 : 컨텍스트 컴팩션(compaction)</li></ul>​<ul><li>첫째, 단일 턴의 한계</li><li>둘째, 에러 복구의 부재</li><li>셋째, 보안</li></ul>
 </div><div id="SE-e699b251-aa92-4396-b76c-a21f1146916f">
 하네스 엔지니어링2026년 2월 : 에이전트를 둘러싼 시스템 — 규칙, 도구, 제약, 피드백 루프 — 을 바꾸는 것에이전트 = 모델 + 하네스모델은 CPU(연산 능력), 하네스는 운영체제(컨텍스트 큐레이션, 도구 관리, 권한 제어, 에러 복구)"핵심은 "루프". 그리고 루프를 제어하는 것이 하네스에이전트의 실수를 잡아내고 바로잡는 장치들의 집합​<ul><li>가이드 (결정론적 피드포워드), 애초에 잘못된 방향으로 가지 않게, AGENTS.md, 프로젝트별로 "이 프로젝트에서는 Tailwind CSS를 사용한다", "타입은 항상 명시적으로 선언한다" 같은 규칙을 정의합니다</li><li>연산적 (결정론적 피드백). 가이드를 무시해도 기계적으로 잡아냅니다. 컴파일러 에러, 린터 경고, 타입 체커, 정적 분석. 커스텀 린터가 아키텍처 규칙을 강제</li><li>시스템 프롬프트 (비결정론적 피드포워드). 결정론적 규칙으로 포착할 수 없는 뉘앙스를 처리합니다. 역할 정의, 행동 제약, few-shot 예시.</li><li>추론적 (비결정론적 피드백) : Evaluator 에이전트</li></ul>​<ul><li>Anthropic의 3-에이전트 아키텍처 : 만드는 놈과 평가하는 놈을 나눈 것. Planner, Generator, Evaluator</li><li>OpenAI Codex 실험 : 코드가 안정적으로 생성될 수 있는 환경을 설계. <ul><li>저장소 지식의 시스템화 - 모든 원칙과 설계 결정을 저장소 안의 마크다운과 코드로 문서화</li><li>기계적 강제성 - 커스텀 린터와 구조적 테스트로 아키텍처 규칙을 강제</li><li>점진적 공개 - 에이전트에게 지도(map)를 주고 필요한 정보를 직접 찾아가게 하는 방식</li></ul></li><li>Ralph 패턴: 밤새 돌아가는 에이전트. PRD(Product Requirements Document — 제품 요구사항 문서)를 정의하고, AI 코딩 도구(Claude Code, Amp 등)를 루프 안에서 반복 실행하여 PRD의 모든 항목이 완료될 때까지 돌리는 것, 클린 컨텍스트로 새로 시작</li></ul>​보안 사고는 필연 : human-in-the-loop(사람의 승인)<ul><li>신뢰할 수 없는 입력 처리 (외부 웹, 이메일, 사용자 입력)</li><li>민감한 시스템/데이터 접근 (개인정보, 내부 API, 데이터베이스)</li><li>상태 변경 능력 (이메일 발송, 파일 삭제, API 호출)</li></ul>​하네스 설계의 기술은 "무엇을 만들 것인가"만큼이나, "무엇을 쉽게 제거할 수 있게 만들 것인가"에 달려 있습니다. <ul><li>Guardian Agent.</li><li>평가 엔지니어링. </li><li>지식 엔진 : <ul><li>"왜 이 아키텍처를 선택했는가", "6개월 전에 이 방식을 시도했다가 왜 철회했는가", "이 모듈의 원래 설계 의도는 무엇이었는가" , </li><li>코드 그래프(함수 간 호출 관계, 의존성 구조), 커밋 히스토리(코드가 왜, 어떻게 변해왔는가), 메모리 시스템(과거 세션에서 학습한 교훈)</li></ul></li></ul>
 </div></div>

I ❤ Hands-On

[원문] https://bits-bytes-nn.github.io/insights/agentic-ai/2026/04/05/evolution-of-ai-agentic-patterns.html 하네스 엔지니어링은 '무엇을 할 것인가'에 대한 개념이고, Microsoft Agent Framework는 '어떻게 구현할 것인가'에 대한 도구입니다. 프롬프트 엔지니어링이 '무엇을 물어볼까'라면, 하네스 엔지니어링은 '어떤 환경에서 일하게 할까'에 집중. Prompt Engineering(2023) → Context Engineering(2025,6) → Harness Engineering(2026) GitHub Copilot 2022년 6월 : GitHub Copilot, AI 코딩 어시스턴트, 현재 파일의 코드 기반으로 다음 줄 제안, 프롬프트 엔지니어링 2022년 11월 : Ch.......

프롬프트에서 하네스까지 — AI 에이전틱 패턴 4년의 기록 : MS 에이전트 프레임워크 활용법(초안)

댓글