프롬프트를 제어 평면으로 설계하기

프롬프트는 말투가 아니라 운영 규약이다

프롬프트는 여전히 중요하다. 다만 AI 에이전트 시대의 프롬프트는 "친절하게 답하라", "전문가처럼 말하라" 같은 말투 지시에서 끝나지 않는다. 파일을 읽고, 코드를 수정하고, 테스트를 실행하고, 외부 API를 호출하는 에이전트에게 프롬프트는 실행 규칙을 전달하는 제어 평면이다.

프롬프트 엔지니어링이 개별 지시와 출력 구조를 다룬다면, 하네스 엔지니어링은 도구, 메모리, 권한, 검증 루프, 관측 가능성까지 포함한 전체 실행 환경을 다룬다. 이 둘은 경쟁 관계가 아니라 포함 관계다. 프롬프트는 하네스 안에서 에이전트가 어떤 판단을 해야 하는지 알려주는 중요한 안내 계층이다¹.

좋은 프롬프트는 에이전트의 성격을 꾸미지 않는다. 좋은 프롬프트는 다음을 분명히 한다.

• 무엇을 할 수 있는가

• 무엇을 해서는 안 되는가

• 어떤 순서로 판단해야 하는가

• 어떤 도구를 언제 써야 하는가

• 실패했을 때 무엇을 숨기지 말아야 하는가

• 충돌이 생기면 중단할지, 보고할지, 확인을 요청할지

즉, 프롬프트는 자연어로 작성된 운영 규약이다.

계층형 지시 구조로 조립하기

실패하는 프롬프트의 흔한 특징은 모든 규칙을 하나의 긴 문단에 섞어 넣는 것이다. 정체성, 보안 정책, 프로젝트 규칙, 작업 목표, 출력 형식이 한 덩어리로 붙어 있으면 모델은 어느 규칙이 더 중요한지 추론해야 한다. 그 순간 예측 가능성은 낮아진다.

성숙한 하네스에서는 프롬프트를 계층형 설정으로 다룬다. 하네스의 가이드가 에이전트의 행동을 사전에 조향하고, 센서가 실행 결과를 관찰하는 것처럼 프롬프트도 "행동 전 제약"의 일부로 설계된다².

이 구조의 핵심은 각 계층이 서로 다른 책임을 가진다는 점이다. 정체성 선언은 행동의 방향을 잡는다. 보안 정책은 허용 범위를 제한한다. 프로젝트 정책은 코드베이스의 관습을 알려준다. 작업 목표는 이번 실행의 완료 조건을 정한다. 출력 계약은 사람이 결과를 검토할 수 있게 만든다.

이렇게 나누면 프롬프트를 수정할 때도 안전하다. 출력 형식을 바꾸기 위해 보안 정책을 건드릴 필요가 없고, 프로젝트 규칙을 추가하면서 전체 시스템 규칙을 흐리지 않아도 된다.

충돌을 모델의 해석에 맡기지 않기

에이전트는 여러 종류의 지시를 동시에 받는다. 사용자는 "빨리 고쳐줘"라고 말할 수 있고, 프로젝트 규칙은 "테스트 없이 완료하지 말라"고 말할 수 있다. 조직 정책은 "외부 네트워크 호출 금지"라고 되어 있는데, 작업 문서에는 "패키지를 설치하라"고 적혀 있을 수도 있다.

이때 "상식적으로 판단하라"는 지시는 부족하다. 충돌 상황에서 모델이 임의로 우선순위를 정하면 실행 결과가 매번 달라진다. 프롬프트에는 명시적인 우선순위와 거부 기준이 있어야 한다. 프롬프트를 페르소나가 아니라 제어 평면으로 본다는 것은 바로 이런 의미다. 실행 범위, 실패 처리, 권한, 우선순위를 운영 규약으로 분리해야 한다³.

다음과 같은 규칙을 기본값으로 둘 수 있다.

우선순위:
1. 보안 정책과 법적 요구사항
2. 조직 정책
3. 프로젝트·저장소 정책
4. 현재 작업 목표
5. 사용자 선호와 말투 요청

충돌 처리:
- 상위 규칙과 하위 요청이 충돌하면 상위 규칙을 따른다.
- 보안 또는 권한 충돌은 임의로 우회하지 않는다.
- 작업 완료 조건이 불명확하면 실행 전에 확인 질문을 한다.
- 이미 실행한 작업이 정책 위반 가능성을 만들었다면 즉시 중단하고 보고한다.

중요한 것은 "거부"도 정상 동작으로 설계하는 것이다. 좋은 에이전트는 무조건 수행하는 에이전트가 아니다. 할 수 없는 일을 식별하고, 이유를 설명하고, 필요한 승인을 요청하는 에이전트가 더 안전하다.

실행 제약은 구체적인 위험으로 쓴다

"조심해서 작업하라"는 좋은 제약이 아니다. 모델은 조심한다는 말을 각자 다르게 해석한다. 실행 제약은 실제 엔지니어링 위험을 줄이는 문장이어야 한다.

예를 들어 코딩 에이전트라면 다음 규칙이 필요하다.

• 범위 제한: 요청과 직접 관련 없는 파일을 수정하지 않는다.

• 검증 정직성: 테스트를 실행하지 못했거나 실패했다면 반드시 그대로 보고한다.

• 최소 변경: 필요 없는 추상화, 대규모 리팩터링, 파일 이동을 만들지 않는다.

• 권한 제한: 허용되지 않은 도구나 외부 서비스를 호출하지 않는다.

• 상태 보존: 사용자의 미커밋 변경을 덮어쓰지 않는다.

• 위험 작업 중단: 삭제, 강제 푸시, 운영 배포, 스키마 변경은 승인 없이 실행하지 않는다.

이를 프롬프트에 넣을 때는 짧고 검증 가능한 형태가 좋다.

작업 범위:
- 이슈 해결에 필요한 최소 파일만 수정한다.
- 관련 없는 리팩터링, 포맷팅, 의존성 업그레이드를 하지 않는다.

검증:
- 가능한 경우 관련 테스트를 실행한다.
- 테스트를 실행하지 못했다면 "미실행"이라고 보고한다.
- 실패한 테스트를 성공으로 표현하지 않는다.

도구 사용:
- 파일 삭제, git reset --hard, git push --force, 운영 배포는 승인 없이 실행하지 않는다.
- 권한이 없는 도구가 필요하면 호출하지 말고 요청 사유를 보고한다.

이런 문장은 모델의 창의성을 줄이는 것이 아니라 사고의 폭발 반경을 줄인다. 에이전트가 강력한 도구를 가질수록 더 촘촘한 제약이 필요하다.

프롬프트는 하네스의 다른 층과 연결되어야 한다

프롬프트는 혼자 작동하지 않는다. 좋은 프롬프트는 컨텍스트 전달, 계획 산출물, 도구 인터페이스, 메모리, 평가 루프와 맞물린다.

첫째, 프롬프트는 컨텍스트 정책을 알려준다. 어떤 문서를 먼저 읽을지, 오래된 메모리를 어떻게 의심할지, 현재 작업과 관련 없는 로그를 언제 무시할지 정한다.

둘째, 프롬프트는 계획 산출물을 요구한다. 장시간 작업에서는 "바로 수정"보다 "짧은 계획 → 실행 → 검증 → 보고"가 안정적이다. 계획은 모델의 생각을 보기 위한 장식이 아니라, 작업 범위를 고정하고 중간 검토를 가능하게 하는 산출물이다.

셋째, 프롬프트는 도구 인터페이스와 연결된다. "테스트를 실행하라"는 말만으로는 부족하다. 어떤 테스트 명령을 쓰는지, 실패 로그를 어떻게 요약하는지, 도구 오류와 코드 오류를 어떻게 구분하는지까지 지정해야 한다. Claude Code류 하네스가 읽기, 편집, Bash, 훅, 권한 모드 같은 계층을 나누는 이유도 여기에 있다⁴.

넷째, 프롬프트는 메모리 규칙을 포함해야 한다. 모든 것을 기억하면 메모리는 오염된다. 반대로 아무것도 저장하지 않으면 매번 같은 실수를 반복한다. 따라서 "장기 메모리에 저장할 것"과 "현재 세션에서만 사용할 것"을 분리해야 한다.

다섯째, 프롬프트는 검증 루프와 연결되어야 한다. 에이전트가 "완료했다"고 말하는 것보다 중요한 것은 테스트, 린터, 타입 검사, 스키마 검증, 리뷰 게이트가 통과했는지다.

프롬프트만으로 잠그지 않는다

프롬프트는 강력하지만 잠금장치는 아니다. "삭제하지 말라"고 적어도 파일 삭제 권한이 열려 있으면 사고 가능성은 남는다. "테스트를 실행하라"고 적어도 런타임이 테스트 실행을 확인하지 않으면 거짓 완료 보고를 막을 수 없다.

따라서 규칙을 두 종류로 나누어야 한다.

• 판단이 필요한 규칙: 자연어 프롬프트로 유도한다.

• 위반되면 시스템 실패가 되는 규칙: 하네스가 코드로 강제한다.

예를 들어 "불필요한 추상화를 만들지 말라"는 판단이 필요한 규칙이다. 모델이 코드 맥락을 보고 결정해야 한다. 반면 "운영 DB에 쓰기 요청을 보내지 말라", "허용 범위 밖 파일을 수정하지 말라", "권한 없는 도구를 실행하지 말라"는 코드로 막아야 한다.

이때 필요한 것이 권한 제어, 샌드박스, 훅, 감사 로그다. 권한 제어는 allow, ask, deny 같은 정책으로 도구 호출을 제한한다. 샌드박스는 에이전트의 실행 환경을 호스트 시스템과 분리한다. 훅은 도구 실행 전후에 테스트나 보안 검사를 자동으로 수행한다. 감사 로그는 나중에 어떤 작업이 왜 실행되었는지 추적하게 해준다⁵.

즉, 프롬프트는 규율을 설명하고, 하네스는 규율을 집행한다.

프롬프트 변경을 코드 변경처럼 다루기

프롬프트가 제어 평면이라면 프롬프트 변경은 코드 변경과 같다. 한 문장을 바꾸면 에이전트의 행동 범위, 거부 기준, 출력 형식, 검증 습관이 달라질 수 있다. 그러므로 프롬프트는 버전 관리되어야 한다.

실무에서는 다음 항목을 관리한다.

• 프롬프트 ID와 버전

• 변경 이유와 기대 효과

• 영향을 받는 작업 유형

• 제거되거나 완화된 제약

• 새로 추가된 거부 조건

• 회귀 테스트 결과

• 롤백 방법

프롬프트 리뷰에서는 문장 품질보다 행동 변화를 봐야 한다. "더 친절하게 답하라"는 변경도 위험할 수 있다. 친절함을 위해 불확실한 내용을 단정하거나, 실패를 부드럽게 포장할 수 있기 때문이다. 따라서 리뷰 질문은 다음과 같아야 한다.

• 이 변경이 에이전트의 권한 해석을 넓히는가?

• 테스트 실패를 보고하는 방식이 약해지는가?

• 출력 계약이 파서와 호환되는가?

• 보안 정책보다 사용자 요청을 우선하게 만들 가능성이 있는가?

• 기존 실패 사례를 다시 통과하는가?

대표 작업 세트도 필요하다. 정상 작업, 애매한 요청, 실패한 테스트, 권한 없는 도구 호출, 보안 위반 시나리오를 회귀 테스트로 만든다. 프롬프트 변경 후에는 이 세트를 반복 실행해 행동 변화를 확인한다.

측정 지표는 단순한 만족도보다 운영에 가까워야 한다.

• 작업 완료율

• 검증 미실행 보고율

• 테스트 실패 은폐 건수

• 허용 범위 밖 파일 수정 시도

• 권한 거부 후 재시도 패턴

• 출력 형식 위반률

• 인간 승인 요청 비율

이렇게 관리하면 프롬프트는 감각적인 글쓰기 자산이 아니라 운영 가능한 시스템 자산이 된다.

좋은 프롬프트의 기준

좋은 프롬프트는 길다고 좋은 것이 아니다. 좋은 프롬프트는 에이전트가 임의로 해석할 여지를 줄이고, 필요한 판단은 하게 하며, 위험한 행동은 하네스의 강제 장치로 넘긴다.

정리하면 기준은 네 가지다.

1. 계층이 분리되어 있는가?

2. 충돌 시 우선순위가 명확한가?

3. 실제 엔지니어링 위험을 구체적으로 줄이는가?

4. 검증, 권한, 관측 가능성과 연결되어 있는가?

프롬프트는 에이전트에게 "어떤 사람이 되어라"라고 말하는 문서가 아니다. 프롬프트는 에이전트에게 "이 환경에서 이렇게 일하라"고 알려주는 운영 규약이다. 하네스 엔지니어링에서 프롬프트를 제어 평면으로 다룬다는 것은, 자연어를 시스템 설계의 일부로 책임 있게 관리한다는 뜻이다.

참고

¹Harness Engineering vs Prompt Engineering vs Context Engineering

²What Is Harness Engineering AI? The Definitive 2026 Guide

³Harness Engineering Essentials: Nine Practices for Taming AI Coding Agents

⁴The Complete Guide to Harness Engineering: Building AI Agents the Claude Code Way

⁵Harness Engineering이란 — AI 에이전트를 제어하는 인프라