지시문을 몇 번씩 고쳐 써도 AI 답변이 어제와 달라지거나, 조금만 긴 작업을 맡기면 앞선 조건을 빼먹는 일이 반복될 때가 있습니다. 이럴 때는 질문 문구를 더 다듬기보다 프롬프트 컨텍스트 하네스 루프 차이를 기준으로 지금 막힌 지점이 어느 층위인지부터 확인하는 편이 빠릅니다.
AI에게 일을 맡기는 방식은 한 번의 질문을 다듬는 단계에서 시작해 배경 맥락을 채우고, 실행 환경을 통제하고, 반복 시스템을 돌리는 단계로 확장됩니다. 네 개념이 각각 무엇을 바꾸는지 구분하면 지금 내 업무에 필요한 최소한의 설계만 골라 적용할 수 있습니다.
프롬프트 컨텍스트 하네스 루프 차이, 질문이 바뀌는 4단계
네 가지 개념은 서로 경쟁하는 유행어가 아니라, AI에게 맡기는 작업의 범위가 넓어질수록 바깥쪽으로 한 겹씩 추가되는 설계 층위입니다. 안쪽 층위가 한 번의 요청 품질을 다룬다면, 바깥쪽 층위는 여러 턴에 걸친 일관성과 자율 실행을 다룹니다.
| 설계 층위 | 핵심 질문 | 주요 설계 대상 | 해결하는 대표 문제 |
|---|---|---|---|
| 프롬프트 엔지니어링 | 무엇을 어떻게 요청할까 | 역할 부여, 출력 형식, 예시와 제약 문구 | 질문이 모호해 답변 방향이 빗나가는 문제 |
| 컨텍스트 엔지니어링 | 무엇을 알고 시작하게 할까 | 참고 문서, 지시 파일(CLAUDE.md), 스킬(SKILL.md), 메모리 | 배경 지식이 없거나 대화가 길어져 핵심을 놓치는 문제 |
| 하네스 엔지니어링 | 어떤 규칙과 도구 안에서 일하게 할까 | 허용 도구(MCP), 훅(Hooks), 아키텍처 린터, CI 검증 게이트 | 규칙을 확률적으로만 지켜 결과 품질이 들쑥날쑥한 문제 |
| 루프 엔지니어링 | 완료될 때까지 어떻게 스스로 돌게 할까 | 자동 실행 스케줄, 완료 조건, 서브에이전트 분리, 외부 상태 기록 | 사람이 매번 결과를 보고 다음 명령을 직접 입력해야 하는 병목 |
핵심 기준: 답변 내용이 얕다면 컨텍스트를, 규칙 위반이 반복된다면 하네스를, 사람이 계속 다음 지시를 넣고 있다면 루프를 점검해야 합니다.
프롬프트 엔지니어링은 단일 요청에서 원하는 형식과 톤을 끌어내는 데 효과적입니다. 하지만 배경 자료가 매번 달라지거나 여러 단계를 거쳐야 하는 업무에서는 문구 수정만으로 일관성을 유지하기 어렵습니다.
답변이 얕거나 앞선 조건을 잊는다면 컨텍스트와 스킬 문제입니다
AI 모델은 매 세션을 백지 상태에서 시작하며, 추론 시점에 컨텍스트 윈도우 안에 들어온 토큰만 보고 판단합니다. 회사만의 용어 정의나 프로젝트 구조, 이전 결정 사항을 넣어 주지 않으면 아무리 정교한 질문을 던져도 일반론적인 답변만 돌아옵니다.
그렇다고 참고 자료를 무조건 많이 붙여 넣는 방식도 위험합니다. Anthropic의 컨텍스트 엔지니어링 가이드가 짚듯, 컨텍스트 윈도우에 토큰이 과도하게 쌓이면 모델의 주의력이 분산되어 정보를 정확히 인출하지 못하는 컨텍스트 로트(Context Rot) 현상이 나타납니다.
따라서 좋은 컨텍스트 설계는 양을 늘리는 일이 아니라, 원하는 결과를 내는 데 꼭 필요한 고신호(High-signal) 정보만 남기는 작업입니다. 긴 작업이나 반복 업무에서는 아래 네 가지 방식으로 컨텍스트를 관리합니다.
- 핵심 지시 파일의 목차화:
CLAUDE.md나AGENTS.md에는 모든 세부 규칙을 다 적는 대신 프로젝트 구조와 핵심 규칙만 짧게 담아 지도(목차) 역할을 맡기고, 세부 문서는 필요할 때만 찾아 읽게(Just-in-time) 분리합니다. - 절차적 지식을 담은 스킬(
SKILL.md): 매 세션마다 어떤 자료를 먼저 확인하고 어떤 순서로 검증할지 설명하는 대신, 일하는 방법과 자주 쓰는 패턴을SKILL.md로 묶어 필요할 때 불러오게 합니다. - 대화 압축(Compaction)과 도구 출력 정리: 대화가 한도에 가까워지면 핵심 결정과 미해결 과제만 요약해 새 작업 공간으로 넘기고, 이미 확인이 끝난 과거 도구 호출 결과는 비워 주의력 예산을 아낍니다.
- 외부 노트 기록(Structured Note-taking): 할 일 목록이나 진행 상태 파일(
NOTES.md)을 대화창 바깥에 저장해 두면, 컨텍스트가 초기화된 뒤에도 에이전트가 기록을 읽고 작업을 이어 갈 수 있습니다.
결과가 들쑥날쑥하고 규칙을 어긴다면 하네스를 세워야 합니다
컨텍스트와 스킬 문서를 잘 갖췄는데도 에이전트가 규칙을 건너뛰거나 너무 일찍 작업을 끝냈다고 선언한다면, 그때는 하네스 엔지니어링이 필요한 시점입니다. 프롬프트와 문서에 적힌 지시는 모델이 확률적으로 따르는 권고에 가깝지만, 하네스는 시스템 코드로 규칙을 강제합니다.
OpenAI의 하네스 엔지니어링 보고서는 하네스를 에이전트가 궤도를 이탈하지 않고 안정적으로 일할 수 있도록 감싸는 전체 실행 환경과 피드백 루프로 정의합니다. 실무에서 하네스는 에이전트가 행동하기 전에 방향을 잡는 사전 제어(Guides)와, 행동한 뒤 결과를 검사하는 사후 검증(Sensors) 두 축으로 나뉩니다.
- 사전 제어(Guides): 프로젝트 진입점 문서(
AGENTS.md), 꼭 필요한 것만 남긴 도구 권한(MCP), 도구 실행 전후에 보안 검사와 상태 정리를 자동으로 수행하는 훅(Pre/Post Hooks), 계층 간 의존성 방향을 강제하는 아키텍처 린터가 여기에 해당합니다. - 사후 검증(Sensors): 코드나 문서를 수정한 뒤 자동으로 도는 테스트와 CI 게이트, 에러 메시지에 수정 지침을 담아 에이전트에게 즉시 돌려주는 피드백 장치, 실행 로그와 화면 상태를 확인하는 관측 도구가 사후 검증을 맡습니다.
특히 사용 가능한 도구를 무작정 많이 연결하면 도구 정의 자체가 토큰을 소모하고 모델의 선택 혼란만 키웁니다. 작업에 꼭 필요한 도구만 연결하고, 문구로 부탁하던 금기 사항을 린터나 체크리스트 검증 단계로 바꾸는 것이 하네스 설계의 출발점입니다.
사람이 매번 다음 지시를 내리고 있다면 루프로 묶을 차례입니다
하네스까지 갖추면 한 번 맡긴 작업의 품질은 안정되지만, 여전히 사람이 옆에 붙어 결과를 확인하고 다음 작업을 지시해야 할 수 있습니다. 루프 엔지니어링은 사람이 매번 프롬프트를 입력하는 리모컨 역할에서 벗어나, 목표를 통과할 때까지 에이전트가 스스로 탐색하고 검증하며 반복하는 작업 시스템을 설계하는 단계입니다.
루프가 사람의 개입 없이도 안전하게 여러 바퀴를 돌려면 다섯 가지 구성 요소와 외부 상태 기록이 맞물려야 합니다.
- 자동 실행과 완료 조건: 스케줄러(cron), GitHub Actions, 혹은
/loop와/goal같은 기능으로 작업을 시작하고, 빌드 통과나 테스트 성공처럼 기계적으로 판별할 수 있는 종료 조건을 걸어 둡니다. - 격리된 작업 공간(Git Worktree): 여러 에이전트가 동시에 같은 파일을 고치며 충돌하지 않도록 독립된 작업 디렉터리를 나누어 줍니다.
- 작성자와 검증자의 분리(Sub-agents): 결과물을 직접 만든 모델은 자기 산출물을 후하게 평가하는 편향이 있으므로, 별도 지침을 가진 검증 에이전트가 테스트와 요구사항 충족 여부를 따지게 합니다.
- 외부 상태 기록(State): 대화창이 닫혀도 무엇을 시도했고 무엇이 통과했는지 남도록 마크다운 파일이나 이슈 보드에 진행 상태를 기록합니다.
- 외부 도구 연결(Connectors): 파일 수정에 그치지 않고 이슈 트래커 확인, PR 생성, 채널 알림까지 이어지도록 커넥터를 연결합니다.
다만 루프를 설계할 때는 에이전트가 혼자 고쳐도 되는 영역과 반드시 사람을 불러야 하는 경계를 명확히 나눠야 합니다. 단순 린트·타입 오류 수정이나 누락된 테스트 보강은 자동 처리에 맡기되, 데이터베이스 스키마 변경, 인증·권한 정책, 결제·보안 로직, 요구사항 범위를 바꾸는 수정은 즉시 멈추고 사람에게 확인을 요청하도록 설계해야 합니다.
또한 루프가 고도화될수록 세 가지 현실적인 비용이 함께 커진다는 점도 기억해야 합니다. 무인 루프는 실수도 무인으로 반복할 수 있어 최종 검증 책임은 여전히 사람에게 남고, 서브에이전트가 늘어날수록 토큰 소비량이 커지며, 사람이 직접 읽지 않은 결과물이 빠르게 쌓이면 시스템을 이해하지 못하는 이해 부채(Comprehension Debt)가 발생할 수 있습니다.
지금 내 작업은 어디서 막혔는지 찾는 진단 순서
처음부터 거대한 루프나 복잡한 하네스를 한꺼번에 구축할 필요는 없습니다. 현재 AI 작업에서 가장 자주 겪는 불편함을 아래 네 단계에 대조해 보면 오늘 손봐야 할 층위를 바로 찾을 수 있습니다.
- 단발성 질문인데 원하는 형식이나 톤이 안 나올 때: 프롬프트에 역할, 독자, 출력 형식, 좋은 예시 1~2개를 구체적으로 명시합니다.
- 답변이 뻔하거나 매번 같은 배경 설명을 다시 붙여 넣고 있을 때: 프로젝트 핵심 구조와 용어 정의를 짧은 지시 파일(
CLAUDE.md등)과 절차 문서(SKILL.md)로 분리해 컨텍스트로 제공합니다. - 같은 실수를 반복하거나 지켜야 할 규칙을 자꾸 빼먹을 때: 지시문 문구를 고치는 대신, 완료 전 필수 체크리스트나 린터·테스트처럼 통과하지 못하면 다음 단계로 넘어가지 못하는 하네스 검증 장치를 추가합니다.
- 작업 절차가 정해져 있는데도 사람이 매번 확인하고 다음 명령을 치고 있을 때: 통과 기준과 사람 호출 경계선을 정한 뒤, 작성 에이전트와 검증 에이전트가 외부 상태 문서를 보며 반복 실행하는 루프로 묶습니다.
자주 묻는 질문
Q. 루프 엔지니어링이 등장하면 프롬프트 엔지니어링은 더 이상 필요 없나요? A. 그렇지 않습니다. 프롬프트가 사라진 것이 아니라 지시 파일, 스킬 문서, 검증 에이전트의 평가 기준 안으로 들어간 것에 가깝습니다. 단발성 요청에서는 여전히 명확한 프롬프트가 가장 빠른 해결책이며, 상위 층위로 갈수록 그 문구가 시스템 규칙으로 자리 잡게 됩니다.
Q. 지시 파일(CLAUDE.md, AGENTS.md)에 모든 규칙을 자세히 적어 두면 더 잘 작동하나요? A. 오히려 역효과가 나기 쉽습니다. 지시 파일이 백과사전처럼 비대해지면 컨텍스트 윈도우를 잠식하고, 모든 규칙이 중요해 보여 정작 핵심 제약을 놓치거나 문서가 빠르게 낡게 됩니다. 진입점 파일은 짧은 목차로 유지하고 세부 문서는 작업에 맞춰 필요한 순간에만 불러오게 설계하는 편이 안전합니다.
Q. 비개발자도 컨텍스트나 하네스, 루프 설계를 업무에 적용할 수 있나요? A. 코드를 직접 짜지 않아도 같은 원리를 그대로 쓸 수 있습니다. 자주 쓰는 용어집과 좋은 결과물 예시를 문서로 묶어 두는 것이 컨텍스트 설계이고, 초안 작성 뒤 필수 점검표로 누락 항목을 대조하게 만드는 것이 하네스이며, 일정 시간마다 자료를 모아 요약하고 이상 항목만 알림으로 받게 연결하는 것이 루프입니다.