이 기사의 대상 독자

• 개발 업무에서 일상적으로 AI를 활용하고 있는 사람
• AI에게 작업을 위임하고 싶지만, 어떤 방식이 좋은지 모르는 사람

1. 왜 「프롬프트만으로는」 부족한가

2022~2024년은 Prompt Engineering (지시 작성법)이 중심이었습니다. 하지만 실제 운영에서는 다음과 같은 한계가 드러나고 있습니다.

• 1회의 지시로는 다단계 작업을 완수할 수 없음
• 모델이 「완료했습니다」라고 말해도 실제로는 미검증 상태
• 컨텍스트 (Context)가 늘어나면 정밀도가 떨어짐
• 도구 호출 (Tool Calling) 실패, 루프, 권한 일탈이 발생함

그 결과, 업계의 초점은 Prompt → Context → Harness → Loop라는 4층 구조로 이동하고 있습니다. 이것들은 서로 경쟁하는 개념이 아니라, **동일한 스택의 서로 다른 레이어 (Layer)**입니다.

2. 4가지 엔지니어링: 무엇이 다른가

Agent = Model + Harness — 에이전트의 가치는 모델 단독이 아니라, 주변의 Harness에 의해 결정됩니다. (LangChain, martinfowler.com의 Harness Engineering에서 체계화)

참고: Loop Engineering은 Harness 안의 「반복 제어층」으로서 구현되는 경우가 많습니다. 4층 구조는 가르치기 쉽게 정리한 것이며, 엄격한 포함 관계는 도구나 설계에 따라 다릅니다.

각 레이어의 상세 내용

Prompt Engineering (지시층)

• 역할 정의, 제약, 출력 스키마, Few-shot 예시
• 여전히 중요하지만, 가장 얇은 레이어가 됨 - 실패 모드: 모호한 지시, 포맷 불일치

Context Engineering (정보층)

• Andrej Karpathy의 정의: "다음 단계를 위해 컨텍스트 윈도우 (Context Window)에 딱 적절한 정보를 넣는 기술" - RAG 결과, 대화 이력, 도구 출력, 메모리, 스키마 정의의 선별
• 실패 모드: 오래된 정보, 과도한 노이즈, 근거 없는 자신감

Harness Engineering (실행층)

• 도구 루프, 재시도 (Retry), 타임아웃, 샌드박스 (Sandbox)
• 권한 관리, 구조화된 로그, 감사 추적, 인간 승인 게이트
• 실패 모드: 무한 루프, 위험한 조작, 숨겨진 실패

Loop Engineering (반복층)

• 2026년의 주목 트렌드: "매번 사람이 프롬프트를 입력한다" → "루프가 스스로 돌아간다" (Addy Osmani, LangChain)
• 계획 → 실행 → 평가 → 수정 → 정지 조건까지 반복
• 실패 모드: 너무 이른 완료 선언, 검증 없는 자기만족

3. 전체 아키텍처

4. 핵심 원칙: 「에이전트를 믿지 마라, 증거를 믿어라」

많은 사람이 목표로 하는 "AI가 스스로 검증한다"는 올바른 방향입니다. 다만, LLM의 자기 리뷰(Self-review)만으로는 불충분합니다.

이를 Evidence-Gated Lifecycle Control (증거 게이트 기반 라이프사이클 제어)라고 부릅니다. 연구 제안인 Proof-or-Stop (2026년 7월, 프리프린트 단계)에서는 다음과 같은 원칙을 제창하고 있습니다.

Don't trust the agent, trust the evidence.

에이전트의 「완료했습니다」는 주장 (Claim)에 불과하며, 라이프사이클 상태를 진행시키는 것은 기계적으로 검증 가능한 증거입니다.

증거 게이트의 요구사항

• Freshness (신선도): 코드 변경 후의 오래된 테스트 결과는 무효
• Completeness (완전성): 필요한 체크가 모두 실행되었는지 확인
• Integrity (무결성): 결과의 변조 방지
• Gate-accepted outcome (게이트 승인 결과): 테스트 0개 실패, lint 0개 에러 등 명확한 합격 조건

실무에서의 증거 게이트 단계

많은 팀은 L1→L2 단계부터 시작해도 충분합니다. L3는 고도의 자동화가 필요한 경우 단계적으로 도입합니다.

5. 루프를 사용하지 않는 것이 좋은 경우

주의: 루프는 만능이 아닙니다. 다음과 같은 경우에는 채팅 1회 또는 사람 주도가 더 적절합니다.

• 1개 파일·수 줄의 수정 — 채팅 1회로 충분함
• 요구사항이 모호함 — Plan(계획) 단계에서 사람의 판단이 필수적임
• 운영 장애의 초동 조사 — 우선 사람이 상황을 파악해야 함
• 보안·권한·개인정보를 다루는 변경 — 사람의 승인이 필수적임
• 아키텍처의 최초 설계 — 여러 안을 비교하는 것은 사람이 수행함

루프의 가치가 발휘되는 것은 "절차는 명확하지만 반복이 많은" 태스크입니다 (테스트 수정, lint 대응, 정형적인 리팩터링, 문서 생성 등).

6. 흔한 실패 패턴과 대책

7. 구체적인 예시: PR 수정 워크플로우 설계

Before (프롬프트만 사용)

이 PR의 버그를 고쳐줘

After (Harness + Loop + Evidence Gate)

1. [Plan] PR diff와 관련 issue를 읽고, 수정 방침을 3줄로 제시
2. [Execute] 수정을 구현 (변경은 src/ 이하로 제한)
3. [Verify] 다음을 실행하고 결과를 보고:
...

복사 붙여넣기용 프롬프트 (Cursor Agent / Claude Code 공통)

당신은 PR 수정 에이전트입니다. 다음 루프에 따라 작업해 주세요.
【스코프】
- 변경 가능 범위: src/ 이하만
...

실패 시나리오와 대책

다른 유스케이스 예시

8. 도구별 실전 팁 (2026년 기준)

공통적으로 중요한 것은, 어떤 도구를 사용하더라도 **Skills (재사용 가능한 워크플로우 정의)**와 **Rules (상시 주입되는 제약·지식)**를 정비하는 것입니다.

참고: 도구의 기능은 업데이트 속도가 빠르므로, 위 내용은 2026년 7월 시점의 개요입니다. 최신 정보는 각 도구의 공식 문서를 참조하십시오.

9. 보안과 비용 관리

보안

• 기밀 정보 취급: API 키, 고객 데이터, 운영 환경 인증 정보를 프롬프트나 컨텍스트에 포함하지 않는다. .env 파일은 AI의 읽기 대상에서 제외한다.
• MCP 권한 최소화: 필요한 도구만 연결하고, 쓰기 권한은 필요 최소한으로 설정한다.
• 프롬프트 인젝션 (Prompt Injection) 대책: 외부 데이터(Issue 본문, PR 코멘트 등)를 그대로 신뢰하지 않는다. Harness를 통해 새니타이즈 (Sanitize) 한다.
• 감사 추적 (Audit Trail): 누가, 언제, 무엇을 AI에게 맡겼는지, 무엇이 실행되었는지를 로그로 남긴다.

비용 관리

• 제한된 재시도 (Bounded Retry): 재시도 상한(3~5회)을 반드시 설정한다. 무한 루프는 비용 폭발의 원인이 된다.
• 태스크당 예산: 1개 태스크의 토큰 상한 및 API 비용 상한을 사전에 결정한다.
• 모델 선정: Plan (가벼운 모델) / Execute (중간 단계) / Verify (강력한 모델)로 구분하여 사용한다.
• ROI 관점: '생성된 코드 라인 수'가 아니라 '인간의 재작업 시간 감소' 및 '최초 게이트 통과율'로 평가한다

10. 요약: 3가지 질문으로 설계 체크하기

지금까지의 내용을 바탕으로, AI에게 작업을 위임할 때는 다음 세 가지를 자문해 보십시오.

• 가드레일 (Guardrail)이 있는가 — 무엇이 허용되며, 실패했을 때 어떻게 되는가 (Harness)
• 개선 루프 (Improvement Loop)가 돌아가는가 — 실패를 감지하고 자동으로 다시 시도할 수 있는가 (Loop)
• 완료 판정이 증거 기반인가 — "다 된 것 같다"가 아니라, 테스트나 Lint 등의 기계적 게이트가 있는가 (Evidence Gate)

2026년의 실천적인 타협점은 모든 것을 AI에게 맡기는 것이 아니라,

AI가 돌리는 루프 안에 인간이 신뢰할 수 있는 검증 게이트를 심어두는 것입니다. 인간의 개입은 매 단계가 아니라, 게이트 통과 실패 시의 에스컬레이션(Escalation)과 최종 판단에 집중합니다.

11. 실천 체크리스트: 오늘부터 무엇을 해야 하는가

여기서부터는 실천 편입니다. 위의 개념을 이해한 후, 자신의 레벨에 맞는 액션을 선택하십시오.

30초 셀프 체크: 나는 지금 어느 레벨인가

• AI에게 "이 PR 수정해줘"라고 한 번에 부탁한다 → Level 1
• Rules / Skills를 작성하고 있지만, 완료 판정은 직접 확인한다 → Level 2
• 에이전트가 테스트 실패까지 자율적으로 수정하게 한다 → Level 3
• 팀 단위로 Skills 라이브러리와 Eval을 운영한다 → Level 4

오늘의 첫 번째 액션 (레벨별)

• L1: CLAUDE.md 또는 .cursor/rules에 "완료 전 반드시 실행할 명령어"를 3줄 추가한다.
• L2: 자주 사용하는 워크플로우를 SKILL.md에 하나 작성한다.
• L3: §7의 복사/붙여넣기용 프롬프트 템플릿으로 교체한다.
• L4: 대표 태스크 3건에 대한 Eval 세트를 만든다.

Level 1: 아직 AI를 "채팅"으로 사용하고 있는 사람

• 태스크를 1단계씩 분해하기 — "이 PR을 리뷰하고 수정하고 테스트해줘"가 아니라, 단계별로 위임한다.
• 출력 형식 지정하기 — JSON schema, 파일 경로, 차이점(diff)만 출력 등 형식을 지정한다.
• 프로젝트 규칙 문서화하기 — .cursor/rules, CLAUDE.md, AGENTS.md 등에 코딩 컨벤션 및 금지 사항을 작성한다.
• 검증 명령어 명시하기 — "완료 전에 pnpm test와 pnpm lint를 실행하고 결과를 보고해줘"라고 지시한다.

Level 2: AI에게 여러 단계를 맡기기 시작한 사람 (Context Engineering)

• 컨텍스트를 의도적으로 선택하기 — 모든 파일을 전달하는 것이 아니라, 관련 파일과 문서만 선별한다.
• Skills / Rules로 지식 재사용하기 — 매번 같은 배경 설명을 쓰지 않고, 스킬 파일에 워크플로우를 정의한다.
• MCP로 외부 도구 연결하기 — Jira, GitHub, 테스트 관리, Notion 등 AI가 직접 참조할 수 있는 정보원을 늘린다.
• 대화 이력의 압축 및 요약 설계하기 — 긴 세션에서는 오래된 정보를 요약하여 노이즈를 줄인다.

Level 3: AI에게 자율적인 작업을 시키고 싶은 사람 (Harness + Loop Engineering)

Harness (실행 환경)를 정비하기

• 도구의 허가 목록 (읽기 전용, 쓰기 가능 디렉토리)

• 타임아웃, 재시도(Retry) 상한, 비용 상한

• 구조화된 로그 (무엇을 했는지, 왜 그렇게 판단했는지)

• 파괴적인 작업에 대한 인간 승인 게이트 (운영 환경 배포, DB 변경 등)

Loop (개선 루프)를 설계하기

• 전형적인 흐름:
  Plan (계획) → Execute (실행) → Verify (검증) → Fix (수정) → (반복) → Report (보고)

• 정지 조건은 소프트 판단이 아닌 하드 조건 (테스트 0건 실패, lint 0건 등)으로 설정

• 재시도는 bounded (상한 3~5회 등)로 설정하며, 초과 시 인간에게 에스컬레이션(Escalation)

• 전형적인 흐름:

역할을 분리하기

• Planner (계획) / Executor (실행) / Verifier (검증)를 별도의 에이전트 또는 별도의 단계로 분리

• 하나의 에이전트에게 모든 것을 다 시키지 말 것

증거 게이트(Evidence Gate)를 통합하기

• done 선언 전에 테스트, lint, 타입 체크를 필수화

• E2E 테스트가 있는 영역에서는 E2E도 포함

• CI와 동일한 명령어를 로컬에서도 AI가 실행하도록 함

Level 4: 팀·조직 단위로 표준화하고 싶은 사람

• Skills를 팀 공유 라이브러리로 만들기 — PR 리뷰, 테스트 케이스 생성, 버그 조사 등의 워크플로우를 스킬(Skill)화
• Rules로 프로젝트 지식을 상시 주입하기 — 도메인 용어, API 명세, 화면 전환 등
• Eval (평가)를 체계화하기 — 대표적인 태스크에 대한 AI 출력 품질을 정기적으로 측정
• HITL (Human-in-the-Loop) 개입 지점 설계하기 — 매 단계가 아니라, 게이트 통과 실패 시 또는 운영 환경에 영향을 줄 때만 개입
• 감사 추적(Audit Trail) 남기기 — 누가, 언제, 무엇을 AI에게 맡겼으며, 무엇이 실행되었는지 기록

참고 링크

1차 소스

• Andrej Karpathy — Context Engineering 정의 (2025-06)
• Addy Osmani — Loop Engineering (2026-06)
• LangChain — The Art of Loop Engineering
• LangChain — The Anatomy of an Agent Harness
• Birgitta Böckeler — Harness Engineering (martinfowler.com, 2026-04)
• Anthropic — Effective Harnesses for Long-Running Agents (2025-11)
• Proof-or-Stop: Evidence-Gated Lifecycle Control (arXiv, 2026-07)

해설·패턴 모음

Discussion