프롬프트가 아니라 계약으로 에이전트를 묶어야 한다

제일 먼저 든 생각

LLM 에이전트를 업무에 붙일 때 자주 생기는 착각이 있다. 프롬프트를 더 정교하게 쓰면 제품 수준의 안정성이 나올 것 같다는 착각이다. 데모 단계에서는 어느 정도 맞다. 하지만 조직 안에서 쓰기 시작하면 질문이 바뀐다. 이 답은 어떤 출처에 근거했는가. 다른 회사의 정보를 섞지 않았는가. 내부 추론 흔적이 사용자에게 새지 않았는가. 같은 조건에서 다시 실행하면 검증 가능한가.

이 논문은 그 전환을 “프롬프트에서 계약으로”라고 부른다. 마음에 남은 핵심은 간단하다. 에이전트의 중요한 행동은 자연어 지시문 안에 숨겨두지 말고, 코드·매니페스트·스키마·검증 산출물로 밖으로 꺼내야 한다.

데모는 프롬프트로 움직이지만, 운영은 계약으로 버틴다

저자들은 기업용 LLM 애플리케이션이 처음에는 시스템 프롬프트와 검색 문서, 간단한 UI로 시작한다고 본다. 이 단계에서는 빠르게 가능성을 보여줄 수 있다. 그러나 제품화가 시작되면 출처 경계, 엔티티 라우팅, 답변 계약, 재현 가능한 추적 기록이 필요해진다.

논문은 이 차이를 이렇게 말한다.

“프롬프트는 시연할 만큼의 행동은 담을 수 있지만, 보장할 수는 없다.”

“Such prompts carry behavior well enough to demonstrate it, but not to guarantee it.”

이 문장은 지금 업무 자동화 프로젝트에서 꽤 아프게 들린다. 많은 내부 도구가 “프롬프트+검색+화면”으로 출발한다. 처음에는 잘 된다. 그런데 사용자 수가 늘고, 예외가 생기고, 감사나 재현 요구가 붙으면 갑자기 허술해진다. 그때 필요한 것은 더 긴 프롬프트가 아니라, 답변이 지켜야 할 계약을 코드가 검사하는 구조다.

논문은 프롬프트 중심 프로토타입을 출처·클레임·라우팅·출력 계약·검증 흔적으로 감싸는 하네스 엔지니어링으로 재구성한다.

하네스가 소유해야 하는 것들

논문에서 말하는 하네스(harness)는 모델 바깥의 제어 계층이다. 원천 문서와 사용할 수 있는 주장(source-backed claims)을 분리하고, 어떤 질문이 어떤 엔티티로 라우팅되어야 하는지 정하며, 답변 형식과 금지 표현을 검사하고, 최종 답이 어떤 근거와 경로로 만들어졌는지 추적한다.

여기서 모델은 교체 가능한 조합 경계(composition boundary)에 놓인다. 중요한 규칙은 모델의 선의나 프롬프트 기억력에 맡기지 않는다. 코드가 소유한다.

논문의 실험도 이 점을 확인하려고 설계되어 있다. 한국 기업집단 5개, 상장사 25개, 런타임에 사용할 수 있는 출처 기반 주장 113개를 놓고 검증한다. 세 개 호스팅 모델을 바꿔가며 270개의 조합 경계 실행을 확인했고, 하네스가 강제하는 체크는 통과했다고 보고한다. 반대로 프롬프트 지시만 남겼을 때는 추천 언어와 내부 추적 누출 위반이 사용자에게 도달했다. 외부 가드레일은 위반을 막을 수 있었지만 과도하게 거절해 유용성이 88/120으로 떨어졌고, 하네스는 120/120 유용성을 유지했다고 쓴다.

이 숫자를 과장해서 읽을 필요는 없다. 특정 데이터와 시나리오에서의 결과다. 그래도 메시지는 선명하다. 업무용 에이전트의 안정성은 “모델이 말을 잘 듣는가”보다 “모델이 어겨도 막아낼 구조가 있는가”에 가깝다.

RAG를 더하는 것만으로는 부족하다

이 논문이 특히 좋은 이유는 검색증강생성(Retrieval-Augmented Generation, RAG)을 만능 해법으로 다루지 않는다는 점이다. 검색은 사실성을 돕지만, 검색된 문장이 특정 답변을 실제로 지지하는지, 어느 회사에 해당하는지, 낡은 정보는 아닌지, 사용자에게 보여도 되는 주장은 무엇인지는 별도 문제다.

“검색은 사실 맥락을 제공하지만, 추적 가능성은 출처의 계보, 엔티티 범위, 주장 단위의 근거를 추가로 요구한다.”

“Retrieval provides factual context, while traceability additionally requires source provenance, entity scope, and claim-level support.”

Deciflow 작업에도 그대로 들어온다. 개인 지식관리나 평가 자동화에서 RAG를 붙이는 것은 시작일 뿐이다. 실제 업무에서는 ‘이 문장을 답변에 넣어도 되는가’를 정한 클레임 층, 답변 형식 계약, 실패 시 대체 경로가 필요하다.

원문 첫 페이지. 논문은 기업용 LLM 에이전트의 행동을 프롬프트가 아니라 버전 관리 가능한 계약과 검증 산출물로 옮기는 패턴을 제안한다.

내 업무에 붙여본다면

새 에이전트 기능을 만들 때 바로 모델 선택부터 하지 말고, 다음 체크리스트를 먼저 만들 수 있다.

• 이 에이전트가 사용할 수 있는 출처 목록은 어디에 버전 관리되는가
• 답변에 들어갈 수 있는 주장과 들어가면 안 되는 주장은 어떻게 나뉘는가
• 사용자 질문을 어느 조직, 문서, 평가 단위로 라우팅할지 누가 결정하는가
• 답변 형식, 금지 표현, 내부 추적 누출은 코드가 검사하는가
• 모델을 바꿔도 같은 검증 세트를 통과하는가
• 실패했을 때 “그럴듯한 답” 대신 거절·보류·사람 검토로 넘어가는가

이 질문은 Power BI 해설 봇, 평가 코멘트 생성기, 회의록 기반 액션 추천, 내부 지식검색 에이전트 모두에 붙는다. 좋은 프롬프트는 여전히 필요하지만, 운영 안정성을 맡기기에는 너무 부드러운 재료다.

이번 주에 해볼 작은 실험

현재 쓰는 프롬프트 하나를 골라 그 안에 숨어 있는 규칙을 밖으로 꺼내본다. “반드시 출처를 붙여라”, “추천처럼 말하지 마라”, “A 부서와 B 부서 정보를 섞지 마라”, “내부 로그를 보여주지 마라” 같은 문장을 코드 체크리스트나 스키마로 옮겨 적는다. 그중 하나라도 자동 검증으로 바꾸면, 에이전트는 데모에서 운영 도구 쪽으로 한 발 이동한다.

원문 정보

• 제목: From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents
• 저자: Joongho Ahn, Moonsoo Kim
• 연도/게시일: 2026
• 게재/출처: arXiv
• arXiv: 2607.08028v1
• PDF: https://arxiv.org/pdf/2607.08028

원문 논문: From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents