프롬프트 카탈로그를 계속 다루다 보니, 프롬프트를 한 문장씩 개선하는 것만으로는 부족하다는 느낌이 점점 강해진다. 좋은 결과는 문장에서만 나오지 않는다. 어떤 정보가 모델 앞에 놓이는지, 어떤 도구와 출력 계약이 붙는지, 실패하면 어떻게 다시 돌리는지가 함께 작동한다.
그래서 이 시리즈에서는 PCH에 Loop를 더해 PCHL로 생각해보려 한다.
| 층 | 질문 | 산출물 |
|---|---|---|
| Prompt | 무엇을 시킬 것인가 | 역할, 목표, 작업 지시 |
| Context | 무엇을 보여줄 것인가 | 자료, 상태, 기억, 제약 |
| Harness | 어떻게 실행하고 붙잡을 것인가 | 도구, 스키마, 검증, 로그 |
| Loop | 어떻게 다시 돌릴 것인가 | 평가, 수정, 재시도, 학습 |
이 이름은 내가 이 카탈로그를 정리하기 위해 쓰는 작업 프레임이다. 다만 방향 자체는 최근 AI 엔지니어링 문서들과 잘 맞는다. OpenAI와 Anthropic의 프롬프트 가이드는 명확한 성공 기준과 평가를 먼저 세우라고 말하고, Anthropic과 LangChain은 컨텍스트 엔지니어링을 프롬프트 이후의 핵심 문제로 다룬다. LangChain 문서는 에이전트를 모델이 도구를 호출하는 루프로 설명하고, 그 주변 구조를 하네스로 본다.
Prompt Engineering: 문장의 역할을 정한다
프롬프트 엔지니어링은 아직 중요하다. 역할을 정하고, 목표를 구체화하고, 출력 형식을 알려주고, 예시를 제공하는 일은 여전히 기본이다. 다만 지금의 프롬프트 엔지니어링은 “멋진 문구 찾기”보다 “요구사항을 일관되게 충족시키는 지시 설계”에 가깝다.
나는 프롬프트 층에서 네 가지를 본다.
| 요소 | 질문 |
|---|---|
| 역할 | 모델은 어떤 관점에서 답하는가 |
| 목표 | 이번 호출의 성공은 무엇인가 |
| 작업 단위 | 생성, 분석, 변환, 평가 중 무엇인가 |
| 출력 계약 | 어떤 형식으로 끝나야 하는가 |
여기까지만 잘해도 단발 작업의 품질은 좋아진다. 하지만 장기 작업, 리서치, 코딩, 에이전트형 작업에서는 곧 한계가 온다.
Context Engineering: 모델 앞의 세계를 설계한다
컨텍스트 엔지니어링은 “프롬프트를 어떻게 쓰는가”에서 “모델이 무엇을 보고 있는가”로 시선을 옮긴다. Anthropic은 컨텍스트를 모델이 샘플링할 때 포함되는 토큰의 집합으로 보고, 그 토큰의 효용을 최적화하는 문제로 설명한다. LangChain 문서는 런타임 컨텍스트, 상태, 장기 저장소, 도구, 응답 형식까지 모두 컨텍스트 설계의 재료로 본다.
이 관점에서는 좋은 질문이 바뀐다.
| 예전 질문 | 새 질문 |
|---|---|
| 어떤 프롬프트가 좋을까 | 이번 호출에 어떤 정보가 들어가야 할까 |
| 더 자세히 말할까 | 어떤 정보는 빼야 집중이 좋아질까 |
| 기억을 많이 넣을까 | 어떤 기억만 현재 작업에 관련이 있을까 |
| 자료를 다 붙일까 | 요약, 검색, 압축, 분리가 필요한가 |
컨텍스트 엔지니어링은 더 많은 정보를 넣는 기술이 아니다. 지금 필요한 정보를 고르고, 불필요한 것을 덜어내고, 모델이 쓰기 좋은 모양으로 놓는 기술이다.
Harness Engineering: 실행대를 만든다
하네스는 아직 모든 문서에서 독립 분야처럼 불리는 말은 아니다. 하지만 LangChain의 에이전트 문서는 모델, 프롬프트, 도구, 미들웨어를 포함해 루프 주변을 감싸는 구조를 harness로 설명한다. 나는 이 단어가 매우 유용하다고 느낀다.
프롬프트가 요청이라면 하네스는 실행대다.
| 하네스 요소 | 하는 일 |
|---|---|
| 입력 계약 | 무엇을 받아야 시작할 수 있는가 |
| 도구 | 검색, 계산, 파일 읽기, 코드 실행 같은 행동 |
| 출력 스키마 | 결과가 어떤 구조로 나와야 하는가 |
| 검증기 | 형식, 근거, 누락, 안전 기준을 확인 |
| 로그 | 나중에 재현하고 고칠 수 있게 기록 |
하네스가 없으면 프롬프트는 매번 사람 손에 의존한다. 하네스가 있으면 같은 프롬프트가 작은 시스템처럼 반복 실행된다.
Loop Engineering: 결과가 다음 입력이 된다
루프 엔지니어링은 내가 이번 시리즈에서 특히 붙이고 싶은 이름이다. 에이전트가 도구를 한 번 쓰고 끝나는 것이 아니라, 관찰하고, 판단하고, 다시 행동하는 구조라면 우리는 루프를 설계해야 한다.
좋은 루프에는 보통 다섯 단계가 있다.
- 목표를 정한다.
- 현재 컨텍스트를 고른다.
- 모델이 산출물을 만든다.
- 하네스가 검증한다.
- 결과를 바탕으로 다시 컨텍스트를 수정한다.
이 구조가 없으면 AI 작업은 “좋은 답이 나올 때까지 다시 물어보기”가 된다. 루프가 있으면 왜 다시 물어보는지, 무엇을 고쳐야 하는지, 언제 멈춰야 하는지가 보인다.
창의성도 루프에서 나온다
창의적 프롬프트를 만들 때도 PCHL은 쓸모 있다. 창의성은 무작정 자유를 주는 데서만 나오지 않는다. 오히려 좋은 제약, 낯선 맥락, 반복 가능한 변주 규칙에서 더 자주 나온다.
예를 들어 이런 식이다.
1 | Prompt: |
이 프롬프트는 단순히 “창의적으로 써줘”가 아니다. 관점, 맥락, 제약, 재생성 규칙을 함께 갖고 있다.
읽은 자료
- OpenAI Prompt Engineering Guide
- Anthropic Prompt Engineering Overview
- Anthropic: Effective Context Engineering for AI Agents
- LangChain: Context Engineering in Agents
- LangChain: Agents
- Anthropic: Writing Effective Tools for Agents
- DSPy
이 자료들을 읽고 나면 흐름은 꽤 분명하다. 프롬프트는 여전히 시작점이다. 하지만 실제 작업에서는 컨텍스트가 결과를 만들고, 하네스가 결과를 붙잡고, 루프가 결과를 개선한다. 앞으로의 프롬프트 카탈로그는 문장 모음이 아니라 PCHL 운영판에 가까워져야 한다.
댓글
GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.