LLM Wiki

Prompt Engineering에서 Loop Engineering으로: 프롬프트는 죽지 않고 시스템에 내장된다

Properties2
descriptionSujin Kang의 LinkedIn 게시물을 바탕으로 Prompt·Context·Harness·Loop Engineering의 계층 변화와 검증·이해 부채를 정리한 노트.
tagsai-agents, ai-coding, prompting, context-engineering, harness, loop-engineering

13 min read

출처

핵심 요약

이 게시물은 “이제 Claude를 직접 프롬프팅하는 것이 아니라, Claude를 프롬프팅하는 루프를 설계한다”는 최근 코딩 에이전트 담론을 설명한다. 핵심은 프롬프트 엔지니어링이 사라졌다는 뜻이 아니라, 사람이 매번 입력하는 1회성 지시문에서 자동화 시스템 내부에 내장되어 반복 실행되는 프롬프트로 레버리지의 위치가 이동했다는 것이다.

게시물은 에이전트 설계의 최적화 단위를 다음 네 계층으로 정리한다.

Prompt → Context → Harness → Loop
  • Prompt Engineering: 무엇을 말할 것인가
  • Context Engineering: 모델에게 어떤 토큰과 상태를 보여줄 것인가
  • Harness Engineering: 도구·제약·검증 게이트를 포함한 실행 환경을 어떻게 만들 것인가
  • Loop Engineering: 에이전트가 일을 찾고, 위임하고, 검증하고, 다음 일을 공급하도록 시스템을 어떻게 계속 돌릴 것인가

네 계층의 의미

Prompt Engineering

한 번의 모델 호출에서 지시문·역할·예시·출력 형식을 조정해 원하는 응답을 얻는 방식이다. 여전히 중요하지만, 사람이 매 턴 직접 개입하는 방식만으로는 장기 실행·반복 작업·병렬 작업을 충분히 다루기 어렵다.

Context Engineering

Anthropic은 context를 모델 샘플링 시점에 포함되는 전체 토큰 집합으로 정의한다. 시스템 지시문뿐 아니라 도구 정의, MCP, 외부 데이터, 메시지 이력, 검색 결과, 메모리까지 포함해 매 순간 어떤 정보를 넣을지 관리하는 문제다.

컨텍스트는 무한한 저장공간이 아니라 주의력 예산이 있는 유한한 자원이다. 따라서 좋은 context engineering은 많은 정보를 밀어 넣는 것이 아니라 원하는 결과의 가능성을 높이는 최소한의 고신호 정보를 구성하는 것이다.

Harness Engineering

하네스는 모델 바깥의 실행 환경이다. 도구 인터페이스, 파일·샌드박스 접근, 권한, 상태 관리, 출력 검증, handoff, sub-agent 구조 등을 포함한다. 2026-07-04-harness-engineering-for-self-improvement에서 정리한 것처럼, 하네스는 단순한 prompt wrapper가 아니라 agent를 실제로 작동시키는 deployment system에 가깝다.

게시물은 이를 다음 공식으로 압축한다.

Agent = Model + Harness

Loop Engineering

Loop Engineering은 하네스 위에 자동화·병렬성·기억·검증·다음 작업 공급을 올리는 오케스트레이션 계층이다. Addy Osmani의 공식 글은 이를 “에이전트에게 직접 프롬프트하는 사람이 아니라, 프롬프트하는 시스템을 설계하는 것”으로 설명한다.

루프의 구성 요소

게시물은 Addy Osmani의 설명을 다음 요소로 요약한다.

요소역할Claude Code / Codex 예시
Automations일정·이벤트 기반 discovery와 triage/loop, cron, hooks, GitHub Actions, Codex Automations
Worktrees병렬 에이전트 작업 격리git worktree, --worktree, sub-agent isolation
Skills프로젝트 지식·절차의 재사용SKILL.md
Sub-agents목표 분해·전문 역할·검증탐색자, 구현자, 검증자 분리
Connectors / Plugins외부 시스템과의 연결MCP, 이슈 트래커, DB, Slack, staging API
External State실행 간 상태 보존Markdown, AGENTS.md, Linear, progress files

이 구성의 핵심은 한 번의 대화 안에서 모든 상태를 유지하려 하지 않는 것이다. 모델은 실행이 끝나면 잊지만, 저장소·상태 파일·이슈 보드는 다음 실행을 위한 외부 기억으로 남는다.

루프의 실행 예시

하루에 한 번 자동화가 저장소의 CI 실패·오픈 이슈·최근 커밋을 읽고 triage skill을 실행한다. 가치 있는 항목은 격리된 worktree에서 구현 sub-agent가 처리하고, 별도의 verifier sub-agent가 테스트와 프로젝트 규칙을 기준으로 검토한다. 연결된 MCP나 plugin이 PR 생성, 이슈 업데이트, Slack 알림을 수행하고, 처리되지 않은 항목은 사람의 triage inbox로 넘긴다.

이렇게 되면 사용자는 매 단계마다 프롬프트를 입력하지 않고, 시스템의 목적·규칙·검증 조건·상태 저장 방식을 한 번 설계한다.

프롬프트는 왜 여전히 중요한가

게시물의 중요한 반론은 Loop Engineering이 Prompt Engineering을 대체하지 않는다는 것이다.

루프는 내부 프롬프트를 통해 만들어진다. 루프 안의 지시문이 부정확하면 에이전트의 오류가 한 번 발생하고 끝나는 것이 아니라 자동화에 의해 반복·증폭된다. 따라서 프롬프트의 형태와 수명은 바뀌지만 역할은 더 중요해진다.

일회성 프롬프트: 이번 턴에 무엇을 말할 것인가
시스템 프롬프트: 내가 없는 동안 에이전트가 무엇을 말하게 할 것인가

프롬프트는 건별 대화의 문장이 아니라 skill, sub-agent instruction, verifier 기준, automation prompt, state transition rule 안에 내장되는 운영 정책이 된다.

세 가지 부채와 위험

1. 검증 부채

에이전트는 충분한 증거 없이 “완료했다”고 말할 수 있다. 자동 루프에서는 이 주장이 사람이 확인하기 전에 다음 단계로 전파된다. 따라서 maker와 checker를 분리하고, 테스트·빌드·정적 분석·실제 동작 확인 같은 외부 검증 조건을 종료 조건으로 둬야 한다.

2. 이해 부채

사람이 직접 작성하지 않은 코드가 자신의 이해 속도보다 빠르게 누적되는 문제다. 루프가 생산성을 높일수록 변경량도 커지므로, 결과를 읽고 핵심 설계와 실패 원인을 설명할 수 있는 검토 과정이 필요하다.

3. 인지적 저항의 약화

자동화된 루프가 내놓은 결과를 판단 없이 수용하는 상태다. 같은 루프를 두 사람이 사용해도, 한 사람은 자신이 깊이 이해하는 영역을 빠르게 확장하고 다른 사람은 이해를 회피하는 도구로 사용할 수 있다. 루프는 이 차이를 스스로 판단하지 못한다.

정석님 관점의 해석

이 글은 loop-engineering 개념을 대중적인 계층 모델로 정리한 자료다. 핵심은 “프롬프트를 버리자”가 아니라 최적화 대상과 개입 단위가 위로 이동한다는 것이다.

  1. Prompt는 개별 응답의 행동을 조정한다.
  2. Context는 모델이 볼 수 있는 정보와 주의력 예산을 조정한다.
  3. Harness는 도구·권한·검증·메모리·실행 경계를 조정한다.
  4. Loop는 여러 실행과 에이전트가 이어지는 생산 시스템을 조정한다.

따라서 Planner–Builder–Verifier 설계에서는 각 계층을 분리해 평가하는 것이 유용하다.

  • Prompt eval: 지시 준수·출력 형식
  • Context eval: 필요한 정보 회수·오염·토큰 효율
  • Harness eval: 도구 사용·권한·검증·복구
  • Loop eval: 반복 안정성·중복 작업·상태 복원·종료 조건

이 구조는 moc-ai-agents-harness의 하네스·자가개선 노트와 연결되며, 2026-04-05-survey-context-engineering-llm의 context engineering 관점과도 이어진다.

실전 적용 원칙

  • 루프를 만들기 전에 사람이 검증할 수 있는 종료 조건부터 정의한다.
  • maker와 verifier를 서로 다른 역할·프롬프트·가능하면 다른 모델로 분리한다.
  • 병렬 실행은 worktree로 격리하고, 공유 상태는 파일·이슈·DB 등 외부 상태에 명시한다.
  • 반복 프롬프트는 SKILL.md·sub-agent 정의·automation 설정으로 승격한다.
  • 루프가 만든 결과를 무조건 merge하지 말고, 테스트·diff·보안·제품 의도 확인을 gated step으로 둔다.
  • 토큰 비용·캐시·실행 시간·중복 작업을 관측한다.
  • 루프가 생산하는 코드를 읽고 설명할 수 있는 이해 수준을 유지한다.

한계와 주의점

  • 게시물은 Prompt → Context → Harness → Loop의 흐름을 설명하는 개념적 정리이며, 각 계층의 성능 향상을 독립적으로 검증한 실험 논문은 아니다.
  • “Loop Engineering”이라는 명칭과 계층화는 Addy Osmani 등의 실무 담론에서 나온 용어로, 산업 전반에 합의된 표준 taxonomy로 보기는 이르다.
  • 자동화·sub-agent·connector를 추가할수록 비용, 운영 복잡성, 권한 범위, 실패 전파면이 커진다.
  • 루프의 자동 종료는 검증을 대체하지 않는다. 종료 조건이 부실하면 검증 부채가 자동으로 누적된다.
  • 모델이 더 강해져도 사람이 설계한 목적·제약·검증·상태 경계가 부실하면 더 빠르게 잘못된 결과를 생산할 수 있다.

관련 노트

검증 정보

  • LinkedIn 원문 캡처 SHA-256: 6f714b70bd50e173a88ce4696f64fd3ec1cba7d8498c954c29cb60506bef418d
  • 해시 대상: raw/articles/2026-07-18-linkedin-sujin-loop-context-engineering.md의 frontmatter 아래 저장된 원문 본문
  • 게시물의 참고 링크(Addy Osmani, Anthropic)는 공식 페이지에서 교차 확인했다.
  • LinkedIn 공개 페이지는 로그인 유도 영역을 포함하므로, 게시물 본문과 공개 댓글까지 Jina Reader로 캡처했다.

백링크