프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 설계

좋은 모델을 손에 넣었다고 해서 곧바로 좋은 에이전트가 만들어지지는 않는다. 같은 모델을 써도 어떤 팀은 쓸 만한 제품을 만들고, 어떤 팀은 데모를 넘지 못한다. 이 차이는 종종 모델의 지능보다 설계의 수준에서 갈린다. 특히 많이 헷갈리는 것이 세 가지다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 설계다.

이 셋은 서로 경쟁하는 개념이 아니다. 오히려 같은 문제를 서로 다른 높이에서 다루는 설계 층에 가깝다. 프롬프트는 모델에게 건네는 지시문이고, 컨텍스트는 모델이 판단할 때 참고하는 재료이며, 하네스는 모델이 실제로 일하는 작업장이다. 무엇을 말할지, 무엇을 보여줄지, 어떤 환경에서 일하게 할지를 구분하면 설계가 훨씬 선명해진다.

왜 이 세 가지를 구분해야 할까

AI 제품을 만들다 보면 문제가 생겼을 때 원인을 잘못 짚는 경우가 많다. 답변이 어색하면 프롬프트부터 고치고, 결과가 부정확하면 문서를 더 넣고, 작업이 엉뚱하게 흘러가도 모델이 멍청하다고 생각한다. 하지만 실제로는 문제가 서로 다른 층에서 발생한다.

예를 들어 에이전트가 고객 문의를 잘못 처리했다고 해보자. 고객 정책을 설명하는 문장이 어색했다면 프롬프트 문제일 수 있다. 최신 환불 규정을 보지 못했다면 컨텍스트 문제일 수 있다. 승인 없이 환불까지 실행했다면 하네스 문제다. 셋을 섞어 생각하면 해결책도 흐려진다. 반대로 층을 분리해서 보면 설계가 정리된다.

이 구분은 마치 요리와 비슷하다. 프롬프트는 요리사에게 내리는 조리 지시다. 컨텍스트는 냉장고에 준비된 재료다. 하네스는 주방의 구조와 안전 수칙, 조리 도구 배치, 검수 절차다. 지시가 아무리 좋아도 재료가 없으면 요리가 부실해진다. 재료가 좋아도 주방이 엉망이면 사고가 난다. 결국 좋은 결과는 세 층이 함께 맞물릴 때 나온다.

프롬프트 엔지니어링: 어떻게 지시할 것인가

프롬프트 엔지니어링은 가장 먼저 눈에 들어오는 층이다. 모델에게 어떤 역할을 주고, 어떤 형식으로 답하게 하며, 무엇을 우선순위로 두라고 말할지를 다룬다. 쉽게 말해 모델과 대화하는 문장을 설계하는 일이다.

예를 들어 같은 작업이라도 지시 방식에 따라 결과는 꽤 달라진다. "고객 문의에 답해줘"라고 하면 답은 나올 것이다. 하지만 "고객 문의를 읽고, 먼저 핵심 문제를 한 문장으로 요약한 뒤, 정책 문구를 확인하고, 확실하지 않으면 추정하지 말고 추가 확인이 필요하다고 답해라"라고 쓰면 모델은 훨씬 안정적으로 행동한다. 이처럼 프롬프트는 모델의 주의 방향을 잡아주고, 출력 형식을 정리하며, 실수를 줄이는 최소한의 울타리가 된다.

프롬프트 엔지니어링이 잘하는 일은 분명하다. 모델의 역할을 분명히 하고, 응답의 톤과 형식을 통일하며, 사고 순서를 유도할 수 있다. 애매한 요청을 구조화된 작업으로 바꿔주는 데도 효과적이다. 특히 단발성 질의나 비교적 폐쇄된 작업에서는 프롬프트만으로도 체감 품질이 크게 좋아진다.

하지만 프롬프트의 힘을 과대평가하면 곤란하다. 프롬프트는 어디까지나 말이다. 모델이 볼 수 없는 정보를 만들어내지는 못하고, 금지된 행동을 물리적으로 막지도 못한다. "삭제하지 마라"라고 써두는 것과 실제로 삭제 권한이 없는 것은 전혀 다르다. "모르면 모른다고 해라"라는 지시와 실제로 최신 문서를 제공하는 것도 다르다.

즉, 프롬프트는 중요하지만 만능은 아니다. 말로 방향을 잡을 수는 있어도, 환경 자체를 대신 설계할 수는 없다.

좋은 프롬프트가 하는 일과 하지 못하는 일

프롬프트를 제대로 이해하려면 그 역할의 경계를 알아야 한다. 좋은 프롬프트는 모델이 흔들리기 쉬운 부분을 정리해준다. 목표를 분명하게 하고, 출력 형식을 제한하고, 우선순위를 알려주며, 주의사항을 강조한다. 마치 숙련된 팀장이 작업 전에 짧고 정확한 브리핑을 하는 것과 비슷하다.

반면 프롬프트만으로 해결되지 않는 문제도 많다. 최신 정보 접근, 외부 도구 사용, 권한 통제, 작업 상태 저장, 검증 절차, 실패 복구 같은 것들이다. 이 문제들은 말 잘하는 것으로 끝나지 않는다. 시스템이 실제로 받쳐줘야 한다.

그래서 실무에서는 프롬프트를 고치는 일과 시스템을 고치는 일을 구분해야 한다. 답변 문체가 들쭉날쭉하면 프롬프트를 손보면 된다. 그런데 같은 실수를 반복하거나, 매번 엉뚱한 문서를 근거로 답하거나, 위험한 작업을 멋대로 실행한다면 이미 프롬프트의 영역을 넘어선 것이다.

컨텍스트 엔지니어링: 무엇을 보여줄 것인가

컨텍스트 엔지니어링은 모델에게 어떤 재료를 공급할지를 설계하는 일이다. 사람도 빈손으로는 제대로 일하기 어렵다. 모델 역시 마찬가지다. 아무리 똑똑해도 봐야 할 문서를 못 보고, 참고해야 할 기록을 못 읽으면 판단이 어긋난다.

여기서 컨텍스트는 단순히 대화 기록만 뜻하지 않는다. 작업 지시서, 관련 문서, 사용자 프로필, 이전 실행 결과, 검색 결과, 데이터베이스 조회 내용, 시스템 상태 요약까지 모두 포함될 수 있다. 즉, 모델이 지금 이 순간 더 잘 판단하기 위해 필요한 입력 전체를 어떻게 구성할지의 문제다.

컨텍스트 엔지니어링의 핵심은 많이 넣는 것이 아니라 맞게 넣는 것이다. 문서를 잔뜩 붙여 넣는다고 품질이 올라가지는 않는다. 오히려 중요한 정보가 묻히고, 오래된 정보와 최신 정보가 섞이며, 서로 충돌하는 지침이 한 화면 안에 같이 들어와 모델을 헷갈리게 만들 수 있다. 좋은 컨텍스트는 풍성한 컨텍스트가 아니라, 작업에 맞춰 정리된 컨텍스트다.

예를 들어 사내 정책을 답하는 에이전트라면 모든 위키 문서를 통째로 보여주는 것보다, 질문과 관련된 정책 조항만 추려서 보여주는 편이 낫다. 고객 지원 에이전트라면 일반 매뉴얼과 함께 해당 고객의 최근 주문 이력, 최근 문의 기록, 현재 계정 상태를 함께 주는 편이 더 정확하다. 작업에 필요한 정보가 무엇인지 판단하고, 그것을 적절한 크기와 순서로 묶어 공급하는 것이 바로 컨텍스트 엔지니어링이다.

컨텍스트는 많을수록 좋은가

처음에는 많은 팀이 이렇게 생각한다. "정보가 부족해서 틀리니, 더 많이 넣자." 절반만 맞는 말이다. 정보 부족은 분명 문제지만, 정보 과잉도 똑같이 위험하다.

모델이 긴 문맥을 처리할 수 있다고 해서, 긴 문맥이 항상 좋은 것은 아니다. 너무 많은 자료가 한꺼번에 들어오면 무엇이 우선인지 흐려진다. 오래된 정책과 최신 정책이 함께 있으면 최신성을 구분하지 못할 수 있다. 관련 없는 기록이 섞이면 모델은 괜히 주변 정보에 끌려간다. 이것이 컨텍스트 오염이다. 재료가 많다고 요리가 맛있어지지 않는 것과 비슷하다. 냄비 안에 필요 없는 재료까지 다 넣으면 맛이 흐려진다.

좋은 컨텍스트 엔지니어링은 세 가지 질문에서 출발한다.

• 이 작업에 정말 필요한 정보는 무엇인가

• 그 정보 중 최신성과 신뢰성이 중요한 것은 무엇인가

• 모델이 한 번에 이해하기 쉬운 형태로 어떻게 압축하고 정렬할 것인가

이 질문에 답하지 못하면 컨텍스트는 지식 공급이 아니라 잡음 공급이 된다.

하네스 설계: 어떤 환경에서 일하게 할 것인가

하네스 설계는 프롬프트와 컨텍스트를 감싸는 더 큰 층이다. 모델이 어떤 도구를 쓸 수 있는지, 어떤 권한을 가지는지, 어떤 순서로 작업하는지, 실패하면 어디서 멈추는지, 결과를 누가 어떻게 검증하는지를 설계한다. 한마디로 말해 모델이 일하는 실행 환경을 만드는 일이다.

같은 모델, 같은 프롬프트, 같은 문서를 써도 하네스가 다르면 결과는 완전히 달라진다. 어떤 하네스에서는 에이전트가 읽기만 할 수 있다. 다른 하네스에서는 메일 발송이나 파일 수정까지 가능하다. 어떤 하네스에서는 중요한 작업마다 승인을 받는다. 다른 하네스에서는 자동으로 끝까지 실행한다. 어떤 하네스는 실패 로그와 재시도 규칙이 있다. 어떤 하네스는 무엇이 왜 실패했는지조차 알 수 없다.

이 차이는 사소하지 않다. 오히려 제품 수준에서는 가장 중요하다. 프롬프트가 모델의 말투와 사고 흐름을 잡아준다면, 하네스는 행동의 경계와 절차를 정한다. 그래서 하네스는 지시문보다 훨씬 현실적인 책임을 진다. 실행 권한, 도구 인터페이스, 상태 관리, 승인 흐름, 검증 절차, 로그와 관측 가능성 같은 문제는 모두 하네스의 영역이다.

여기서 중요한 점은, 하네스가 단순한 껍데기가 아니라는 것이다. 하네스는 모델을 둘러싼 진짜 운영 체계다. 모델이 아무리 잘 답해도, 잘못된 파일에 접근하고, 검증 없이 메일을 보내고, 실패했는데 계속 재시도한다면 제품은 위험해진다. 하네스 설계는 바로 이런 위험을 줄이기 위해 존재한다.

프롬프트, 컨텍스트, 하네스의 차이를 한 장면으로 보기

차이를 더 분명하게 보려면 하나의 작업을 세 층으로 나눠보면 된다. 가령 한 에이전트가 "이번 주 미해결 고객 문의를 정리해 담당 팀장에게 보고하라"는 요청을 받았다고 해보자.

프롬프트의 문제는 이렇게 나타난다. 문의를 어떤 기준으로 분류할지, 답변 초안을 어떤 형식으로 쓸지, 불확실한 경우 어떻게 표현할지를 모델에게 분명히 지시했는가.

컨텍스트의 문제는 이렇게 나타난다. 이번 주 문의 목록, 현재 처리 상태, 고객 등급, 관련 정책 문서, 최근 유사 사례를 모델에게 제대로 보여줬는가.

하네스의 문제는 이렇게 나타난다. 에이전트가 CRM에서 읽기만 가능한가, 상태 변경까지 가능한가, 보고 메일은 초안만 만들고 실제 발송은 사람이 승인하는가, 결과를 저장하고 추적할 로그는 남는가.

셋은 연결되어 있지만 질문이 다르다. 프롬프트는 "어떻게 말할까"를 묻는다. 컨텍스트는 "무엇을 보여줄까"를 묻는다. 하네스는 "어떤 행동이 가능하고, 어떤 절차로 일할까"를 묻는다. 이 세 질문이 동시에 선명해야 에이전트가 일관되게 움직인다.

세 기술은 계층적으로 연결된다

이제 중요한 연결 관계를 보자. 프롬프트, 컨텍스트, 하네스는 옆으로 나란히 놓인 옵션이 아니라 아래에서 위로 쌓이는 계층이다.

가장 안쪽에는 프롬프트가 있다. 모델에게 지금 무엇을 하라고 말하는 직접적인 지시다.

그 바깥에는 컨텍스트가 있다. 모델이 그 지시를 수행할 때 참고하는 재료다. 프롬프트만 있고 컨텍스트가 빈약하면 모델은 그럴듯하게 말해도 근거가 약하다.

가장 바깥에는 하네스가 있다. 어떤 프롬프트를 쓸지, 어떤 컨텍스트를 어떻게 모을지, 어떤 도구를 언제 호출할지, 어떤 행동을 제한할지를 결정하는 전체 구조다.

이렇게 보면 하네스는 프롬프트와 컨텍스트를 포함하는 상위 설계다. 프롬프트가 하네스 없이 떠다닐 수는 있어도, 제품 수준의 에이전트는 하네스 없이 안정적으로 운영되기 어렵다. 실무에서 반복 가능한 품질을 만들려면 결국 하네스 관점으로 올라가야 한다.

같은 말을 조금 다르게 하면 이렇다. 프롬프트는 모델의 한 번의 판단을 돕는다. 컨텍스트는 그 판단의 근거를 보강한다. 하네스는 그런 판단과 행동이 반복될 때도 무너지지 않도록 시스템을 만든다.

무엇이 상위 문제인가

문제를 만났을 때 어느 층에서 해결해야 하는지 가려내는 감각이 중요하다. 이것이 없으면 팀은 쉬운 곳만 계속 고친다. 예를 들어 답변 형식이 들쭉날쭉하면 프롬프트를 고치면 된다. 참조 근거가 부족하면 컨텍스트를 보강하면 된다. 그런데 승인 없이 위험한 행동을 하거나, 도구를 잘못 호출하거나, 실패해도 멈추지 않는다면 이미 하네스 문제다.

상위 문제를 하위 층에서 억지로 해결하려 하면 문장이 점점 길어지고 복잡해진다. 프롬프트 안에 금지 규칙을 끝없이 적어 넣고, 컨텍스트 안에 온갖 주의사항을 욱여넣는다. 그러다 보면 모델은 더 헷갈리고, 설계는 더 취약해진다.

좋은 설계는 책임을 올바른 층에 배치한다. 말로 해결할 일은 프롬프트에서 해결하고, 정보로 해결할 일은 컨텍스트에서 해결하고, 권한과 절차로 해결할 일은 하네스에서 해결해야 한다. 이것이 에이전트 설계를 단순하게 만든다.

프롬프트에서 시작해도, 결국 하네스로 간다

대부분의 팀은 프롬프트에서 출발한다. 당연하다. 가장 빠르게 손댈 수 있고, 결과 변화도 즉시 보이기 때문이다. 다음으로 컨텍스트를 만진다. 문서를 붙이고, 검색을 붙이고, 대화 이력을 정리하면서 품질을 높인다. 여기까지는 비교적 쉽게 체감 개선이 일어난다.

하지만 어느 시점이 되면 성장이 멈춘다. 답은 제법 그럴듯한데 가끔 치명적인 실수를 한다. 테스트에서는 되는데 운영에서는 흔들린다. 사람의 감독이 없으면 불안하다. 바로 이 지점에서 하네스 설계가 필요해진다.

하네스는 프롬프트와 컨텍스트가 이미 중요하다는 사실을 부정하지 않는다. 오히려 그 둘이 제대로 작동할 수 있는 운영 구조를 제공한다. 어떤 요청에는 어떤 프롬프트를 쓰고, 어떤 문서를 검색하며, 어느 단계에서 검증하고, 언제 사람에게 넘길지를 시스템 차원에서 결정한다. 그래서 하네스는 마지막 장식이 아니라, 제품화의 본체에 가깝다.

에이전트 시대의 새로운 설계 관점

챗봇 시절에는 많은 문제가 대화 품질의 문제로 보였다. 답을 자연스럽게 하느냐, 친절하게 하느냐, 환각을 줄이느냐가 핵심처럼 느껴졌다. 하지만 에이전트 시대에는 질문이 달라진다. 이제 모델은 답만 하는 것이 아니라 읽고, 고르고, 실행하고, 수정할 수 있다. 이때부터는 언어 품질 못지않게 실행 구조가 중요해진다.

그래서 설계자의 시선도 바뀌어야 한다. 예전에는 프롬프트를 잘 쓰는 사람이 강점을 가졌다. 이제는 어떤 작업을 자동화해도 되는지, 어떤 작업은 승인받아야 하는지, 어떤 정보를 보여줘야 하는지, 어떤 기록을 남겨야 하는지를 함께 설계할 수 있어야 한다. 즉, 문장을 다루는 감각만으로는 부족하고, 시스템을 다루는 감각이 필요해진다.

이 변화는 에이전트를 단순한 대화 기능이 아니라 운영 가능한 제품으로 보게 만든다. 그리고 바로 그 지점에서 프롬프트 엔지니어링과 컨텍스트 엔지니어링은 하네스 설계 안에서 제자리를 찾는다.

설계를 선명하게 만드는 세 가지 질문

실무에서 가장 도움이 되는 방법은 어떤 기능을 만들 때 처음부터 세 질문을 따로 적어보는 것이다.

• 모델에게 무엇을 하라고 말할 것인가

• 모델이 무엇을 보고 판단하게 할 것인가

• 모델이 어떤 도구와 권한, 절차 안에서 일하게 할 것인가

이 세 질문에 각각 답해보면 설계의 빈칸이 놀랄 만큼 잘 드러난다. 첫 번째 질문에는 답했는데 두 번째가 비어 있으면, 모델은 그럴듯하게 말하되 근거가 약해질 가능성이 크다. 두 번째까지 답했는데 세 번째가 비어 있으면, 모델은 꽤 똑똑해 보여도 운영 단계에서 위험해진다.

결국 에이전트 설계는 문장 하나를 잘 쓰는 기술이 아니라, 명령과 재료와 작업장을 함께 설계하는 기술이다. 프롬프트는 명령이고, 컨텍스트는 재료이며, 하네스는 작업장이다. 이 비유를 머릿속에 붙들고 있으면 복잡한 시스템도 한결 명확하게 보인다.

앞으로의 장들을 읽는 기준

이 책의 이후 장들은 대부분 하네스 설계의 언어로 전개된다. 하지만 그 안에는 늘 프롬프트와 컨텍스트가 함께 들어 있다. 도구 인터페이스를 설계할 때도 결국 모델이 어떤 지시를 받고 어떤 정보를 바탕으로 도구를 고를지 생각해야 한다. 권한을 설계할 때도 어떤 작업을 자동으로 수행하게 할지 판단해야 한다. 메모리와 컨텍스트를 다룰 때도 무엇을 저장하고 어떤 순간에 꺼내 보여줄지 설계해야 한다.

따라서 앞으로의 논의를 이해하는 가장 좋은 기준은 이것이다. 프롬프트는 모델의 한 턴을 정교하게 만든다. 컨텍스트는 모델의 판단 재료를 정교하게 만든다. 하네스는 그 모델이 반복해서 일해도 무너지지 않는 운영 구조를 만든다.

좋은 에이전트는 좋은 문장만으로 만들어지지 않는다. 좋은 재료만으로도 만들어지지 않는다. 잘 설계된 작업장 안에서, 적절한 지시와 필요한 정보가 맞물릴 때 비로소 믿고 맡길 수 있는 시스템이 된다.

다음 장에서는 그 작업장이 왜 자주 무너지는지 더 깊이 들어간다. 에이전트는 왜 반복해서 같은 종류의 실패를 일으킬까. 그 실패는 단순한 실수가 아니라 어떤 구조에서 비롯될까. 그 질문에 답해야 하네스 설계가 더 또렷해진다.