에이전트에게 방법을 지시하지 말라 — 결과를 선언하는 OpenProse

메타데이터

• URL: https://www.youtube.com/watch?v=7T-gldvgfpo
• 작성일: 2026-10-19
• 채널: AI Engineer
• 원본 업로드일: 2026-10-18
• 재생 시간: 49분 35초
• 출연: Dan Barrett, Raymond Weitekamp, Jose Montes de Oca
• 프로젝트: OpenProse
• 원제: Stop Telling Agents How — Dan Barrett, Raymond Weitekamp & Jose Montes de Oca, OpenProse
• 자막: 영어 자동 생성 캡션

📌 핵심 질문 — 에이전트에게 무엇을 맡기고, 무엇을 계약으로 고정해야 하는가?

에이전트의 방법을 세세히 지정하기보다 원하는 결과와 완료 조건을 선언적 계약(declarative contract)으로 작성하면, 에이전트 하네스(agent harness)가 작업에 맞는 절차를 구성할 여지가 커진다. 성공한 절차는 검증 후 고정해 반복성과 비용 효율을 높이고, 각 실행은 계약을 기준으로 별도 검증한다.

• 프롬프트(prompt)에서 컨텍스트 엔지니어링(context engineering), 하네스(harness)로 자동화가 올라왔고, 다음 병목은 의도를 재사용 가능한 형태로 표현하는 일이다.
• OpenProse 프로그램은 Markdown 계약이며, 입력·의존성·필수 결과와 완료 조건을 텍스트로 남긴다.
• 이 방식은 탐색형 일회성 대화보다 반복적이고 신뢰성·감사 가능성이 필요한 이벤트 기반 업무에 맞는다.

강력한 모델이 구현 방법까지 추론할 수 있다면 사용자는 목표를 먼저 정하고 세부 절차는 열어둘 수 있다. 반대로 이미 효과가 입증된 실행 흔적은 단계적으로 고정해 더 결정적이고 저렴한 절차로 바꾼다. OpenProse는 이 두 선택을 하나의 계약 체계 안에서 결합하고, Markdown 텍스트와 기존 코딩 에이전트·모델·가드레일을 유지해 복잡한 다중 에이전트 작업을 조립하는 접근이다.

20줄 핵심 요약

OpenProse는 에이전트에게 방법 대신 목표와 완료 조건을 계약으로 선언한다.

프롬프트 중심 업무는 컨텍스트 구성과 하네스를 거쳐 다중 에이전트 흐름으로 진화했다.

계약은 입력, 의존성, 필요한 결과와 증거를 Markdown으로 정리한다.

성공한 실행 흔적을 절차로 고정하면 반복성을 높이고 비용을 낮출 수 있다.

OpenProse는 코딩 에이전트가 읽고 실행하는 텍스트이며 별도 오케스트레이터가 필요 없다.

실행 프롬프트는 약 7만~8만 토큰이며 Claude Code와 Codex의 서브에이전트 체계를 유지한다.

사람은 논리적인 영어로 프로그램을 요청하고 생성된 계약을 검토·수정한다.

크론이나 웹훅을 계약과 결합해 일정 또는 이벤트 기반 작업을 실행할 수 있다.

GitHub 이슈는 수정 커밋까지, 새 PR은 별도의 리뷰 계약으로 처리한다.

까다로운 시니어 리뷰어 계약은 배포 전 유료 실행에 사람의 승인을 요구했다.

수십 개 PR이 며칠간 검토됐고 일부 변경은 최대 14회의 리뷰를 거쳤다.

새 에이전트 세션이 계약 기준으로 검토하면 작성 모델의 자기승인 편향을 줄인다.

Jev는 계약 충족, 이벤트 라우팅, 하위 작업 재실행을 판별할 분류기로 개발 중이다.

텍스트 계약은 Git으로 관리하고 강화학습에 활용할 수 있지만 실제 학습은 아직 시작되지 않았다.

사내 하네스와 승인된 모델로 실행하면 운영 지식과 SOP를 외부로 보내지 않아도 된다.

정량 모델 문서는 사용처, 시험 조건, 상위 모델과 규제 요구를 반영해 정기적으로 갱신한다.

대형 은행은 약 4,000개 모델을 보유할 수 있고 문서화 비용은 연 1,000만~5,000만 달러다.

공개 SOFR 곡선 문서를 저렴한 모델로 만들고 정량 전문가 평가와 기존 소요 시간으로 품질을 비교한다.

조사·작성·교정은 약 100줄 Markdown으로, 팬아웃·팬인·적대 리뷰·반복을 구성할 수 있다.

일회성 탐색은 채팅으로, 반복성과 감사가 필요한 업무는 OpenProse로 다룬다.

1. 프롬프트 작성에서 결과 계약으로

1.1. 자동화가 올라간 만큼 의도 표현이 다음 과제가 됐다

1. 프롬프트 기술의 유효기간

   1. 2021년 4월, Dan Barrett은 Aluther AI 백룸 Discord에서 ‘최고의 프롬프터’로 선정됐다. 프롬프트 작성 기술은 오래 갈 것 같았지만 약 2~3년이 지나며 중심성이 약해졌다.
   2. 모델과 하네스가 바뀌어도 사람이 원하는 바를 모델에 전달해야 한다는 문제는 남는다. 더 똑똑한 모델을 얻는 일과 사람 머릿속 의도를 꺼내 정확히 전달하는 일은 별개의 문제다.

2. 프롬프트에서 컨텍스트·하네스로 이동

   1. 초기에는 다음 토큰(next-token)을 잘 유도하는 프롬프트 패턴이 중요했다. 이후 검색 증강 생성(RAG), 도구 호출, 검색 결과를 직접 컨텍스트 창(context window)에 채우는 컨텍스트 엔지니어링이 부상했다.
   2. 그다음 하네스가 컨텍스트 구성과 도구 사용을 맡기 시작했다. 최근 8~10개월 사이에는 서브에이전트를 관리하며 실행 구조 자체를 바꾸는 자기 수정형 하네스 흐름이 등장해, 불과 1년 전에는 상상하기 어려웠던 추상화 단계로 올라왔다.

1.2. 절차가 아니라 원하는 상태를 선언한다

1. 선언형(declarative)과 명령형(imperative)의 구분

   1. 클래식 소프트웨어 공학의 구성(composition over inheritance)과 선언형 설계를 에이전트 작업에 가져온다. 에이전트에게 ‘어떻게(how)’ 할지 모두 적는 대신 ‘무엇(what)’을 완료해야 하는지를 먼저 적는다.
   2. 원하는 결과를 더 강한 모델이 스스로 찾을 수 있는데 세부 절차까지 지정하면 모델의 추론 능력과 비용 절감 가능성을 동시에 제한할 수 있다. 저렴한 모델은 실행 흔적을 이미 고정한 뒤에 선택할 수 있다.

2. 계약(contract)으로 목표와 완료 조건을 명시

   1. 문장으로 원하는 상태를 선언하고, 에이전트가 그 상태를 실제로 만들도록 한다. 계약은 목표·결과·종료 조건을 표현한다.
   2. 여러 팀과 서비스에 걸친 시스템에서도 계약을 합성하면 전체 복잡성을 각 부분에서 관리할 수 있다. 결과를 모듈화하고 경계를 분명히 하면 규모가 커져도 재사용하기 쉽다.

3. 열린 방법에서 고정된 방법으로 이동

   1. 처음에는 강력한 모델이 열린 계약을 수행하며 해결 방법을 찾게 둔다. 성공한 실행 흔적(trace)을 추출해 구체적인 절차로 감싸면 이후 더 결정적인 재실행이 가능하다.
   2. 이때 ‘무엇’만 적힌 계약에서 일부 ‘어떻게’를 고정하는 계약으로 점진적으로 이동한다. 비용은 내려가고 반복성은 올라가지만, 모든 업무의 방법을 처음부터 경직되게 지정해야 한다는 뜻은 아니다.

4. 황금 세션(golden session)을 재사용 가능한 업무로 바꾸기

   1. 기대 이상의 결과가 나온 Claude Code 세션을 OpenProse 프로그램으로 변환해 그 작업 흐름을 반복할 수 있다. 모델 제공업체의 비결정성과 변경되는 기대치 탓에 같은 대화 품질이 다시 나오지 않는 문제를 다룬다.
   2. 성공 세션을 계약으로 만들면 한 번의 운 좋은 결과를 재사용 자산으로 남길 수 있다. 고정된 API도 컴퓨팅 제약 등으로 변할 수 있으므로, 계약과 검증 가능한 결과가 안정성의 기준이 된다.

2. OpenProse의 구성과 작동 방식

2.1. Markdown 프로그램이자 하네스 안에서 실행되는 가상 머신

1. 두 가지 핵심 특성

   1. OpenProse는 에이전트용 프로그래밍 언어이자 프레임워크이며, 실행 구성은 Markdown 텍스트와 하나의 거대한 프롬프트로 이뤄진다.
   2. 대화형 채팅이 아니라 이벤트 기반(event-driven) 다중 에이전트 흐름이다. 사람과 대화하는 전용 에이전트가 프로그램 작성을 도울 수는 있지만, 실제 반복 작업은 이벤트가 발생하면 계약을 수행하는 방식으로 굴러간다.

2. 계약 파일과 실행 환경

   1. OpenProse는 오픈 소스이며 로컬에서 npx skills add openprose/prose로 설치할 수 있다. 호스팅 실행 환경은 run.pro.md이며, 코딩 하네스가 Markdown을 읽고 실행한다.
   2. Claude Code나 Codex 등 기존 코딩 에이전트 안에서 실행되며 외부에서 도구 호출을 가로채는 OpenProse 서버가 필수 구성요소는 아니다. “에이전트가 컴파일러”라는 지침을 받아 계약을 해석하고 실행하는 가상 머신 역할을 한다.

3. 사람이 읽고 편집하는 진입점

   1. Markdown에 타입을 입힌 헤더와 문법이 있지만, 사용자가 그 스키마를 처음부터 암기해 계약을 직접 작성하는 것이 목표는 아니다. 사람은 논리적인 영어로 일을 설명하고 프로그램을 검토·편집한다.
   2. prose write는 자연어 요청으로 새 .prose.md 프로그램을 만들며, 생성된 프로그램도 종합적인 계약을 작성하고 유효성을 확인하는 OpenProse 프로그램이다. 실행 전 계획과 계약을 읽고 고치듯 생성 결과를 검토한다.

4. 계약의 구성 요소

   1. Requires는 실행에 필요한 입력·조건이고, Ensures는 끝났을 때 반드시 참이어야 하는 결과다. 함수 시그니처와 문서 주석을 작성한 뒤 에이전트가 그 조건을 지키게 하는 감각에 가깝다.
   2. 필요하면 의존 서비스(Services), 판단 기준(Strategies), 실행 순서(Execution)를 추가한다. 에이전트는 계약 충족을 주장하는 데 그치지 않고 충족했다는 증거를 남겨야 한다.

5. 타입 체계와 하네스 독립성

   1. Markdown 헤더의 의미를 강한 타입 체계처럼 해석하도록 런타임 프롬프트가 계약 실행 방식을 규정한다. 전체 시스템 프롬프트·스킬은 약 7만~8만 토큰이며 더 짧게 다듬고 있다.
   2. Claude Code의 서브에이전트 실행 규칙을 덮어쓰지 않고 Codex에도 특정하지 않는다. 자체 하네스가 되기보다 기존 하네스가 컴파일하는 한 계층으로 남으며, 조직은 기존 모델·가드레일·도구를 가져온다.

2.2. 계약에 필요한 의존성과 이벤트를 배선한다

1. 서브에이전트·스킬·도구 지정

   1. 하위 작업을 맡을 서브에이전트, 각각이 가져야 할 스킬, 사용할 도구를 계약에서 특정할 수 있다. 회사나 조직에만 필요한 스킬도 의존성으로 넣는다.
   2. 예를 들어 검색 에이전트가 일반 웹 검색 대신 Exa CLI와 그 사용 스킬을 반드시 사용하게 할 수 있다. 필요한 CLI나 스킬을 찾지 못하면 프로그램을 실행하지 않도록 사전 조건으로 걸어 임의 대체를 막는다.

2. 입력에서 출력까지의 서비스 계약

   1. 계약은 프로그램 입력과 산출물을 정의한다. 예를 들어 GitHub 이슈가 입력이고 수정 커밋이 출력이라면, 이슈가 실제 완료 상태에 이를 때까지 작업하는 흐름을 구성한다.
   2. 작업을 단순하게 만들 수도, 특정 모델·도구·스킬을 갖춘 다중 에이전트 파이프라인으로 만들 수도 있다. 한 프로그램에 모든 절차를 직접 쌓기보다 서비스 계약을 조립한다.

3. 이벤트와 작업(job)의 결합

   1. 작업은 계약과 트리거(trigger)의 결합이다. 스케줄에 맞춘 크론(cron)이나 GitHub의 새 이슈·PR 이벤트, 웹훅(webhook)처럼 외부 이벤트가 계약을 실행한다.
   2. 호스팅 앱에는 웹훅과 크론 트리거가 구현돼 있다. Slack·GitHub 이벤트도 웹훅으로 연결할 수 있고, 새 트리거가 필요하면 사용 피드백으로 확장할 수 있다.

4. 반복 업무를 코드 공장으로 구성

   1. 이슈 접수부터 문제 해결까지, 또는 PR이 들어올 때마다 리뷰하는 것처럼 상시 실행되는 작업(job)을 세울 수 있다. 업무 종류별 계약과 이벤트를 결합하면 코드 공장(code factory) 같은 파이프라인이 된다.
   2. 산출물과 입력이 분명한 반복 업무에 계약을 붙이면, 대화 기록에 묻히지 않고 팀이 버전 관리·검토·반복 실행할 수 있다.

3. 데모 — 계약 작성, PR 리뷰, 실행 피드백

3.1. 자연어 요청으로 반복 가능한 GitHub PR 리뷰 만들기

1. 사람이 요청하고 에이전트가 프로그램을 생성

   1. 요청은 “새 PR이 올 때마다 AI 생성 코드를 싫어하는 까다로운 시니어 개발자처럼 리뷰하는 OpenProse 프로그램을 작성하라”는 취지였다. 생성된 프로그램이 GitHub PR 검토 계약을 만들고, 기존 저장소에 필요한 배선(wiring)을 추가한다.
   2. GUI의 편집 모드에는 계약 원문이 Markdown으로 보이지만, 사용자는 그 문법을 외워 손으로 시작할 필요가 없다. 코딩 에이전트에게 만든 프로그램을 읽고 필요한 부분을 고친 뒤 반복 가능한 업무로 배포한다.

2. 비용이 드는 행위는 사람 확인을 요구

   1. 데모의 에이전트는 작성 중인 작업을 알리고 앱에 초안을 표시했다. 프로그램 생성이나 작업 배포처럼 돈을 청구하거나 소비하는 행위는 확인 버튼을 누른 뒤 진행하도록 설정했다.
   2. 승인은 결과물을 확인하는 것뿐 아니라 유료 실행을 명시적으로 제어하는 경계다. 생성된 프로그램을 실제 배포하면 새 PR이 들어올 때마다 비용이 들기 때문에 배포 단계도 확인을 받는다.

3. 작업 배포 설정

   1. Job 화면에서 크론 또는 웹훅을 선택하고, PR용으로 사전 배선된 계약과 모델을 지정한 뒤 배포한다. 데모에서 선택 가능하다고 한 모델은 OpenAI 상위 세 가지였다.
   2. 생성된 프로그램은 “Grumpy AI Skeptic PR Review”라는 검토 업무로 표시됐다. 호스팅 앱은 계약을 만들고 실행을 관리하는 편의 계층이며, 이 패턴 자체를 쓰기 위해 호스팅 제품을 꼭 이용할 필요는 없다.

3.2. 적대적 리뷰를 개발 에이전트의 역압(back pressure)으로 사용

1. 새 작업을 독립된 세션과 계약으로 평가

   1. GitHub 웹훅 기능을 개발하는 며칠 동안 수십 개의 PR이 생성·검토됐다. 어떤 PR은 첫 차례에 통과했지만, 일부는 리뷰 에이전트 간 합의에 도달하기까지 최대 14회 리뷰를 거쳤다.
   2. 새 PR마다 작성자와 별도의 리뷰 에이전트가 실행되고, 리뷰어는 선언적 계약으로 결과를 판단한다. 같은 모델이 자기 작업을 다시 확인하며 “잘했다”고 판단하는 자기확신 루프를 피하는 패턴이다.

2. 리뷰를 제품 개발의 역압으로 연결

   1. 개발 에이전트가 PR을 제출하면 리뷰 에이전트가 요구사항을 근거로 피드백을 돌려준다. 작업은 그 피드백을 반영하기 전까지 완료로 간주하지 않는 구조를 보여줬다.
   2. 개발·스테이징 서버와 프로덕션 환경은 서로 다른 리뷰 설정을 사용할 수 있다. 행사 직전에는 스테이징에서 트리거 방식을 바꾸고 프로덕션은 건드리지 않도록 계약을 고쳤다.

3. 계약 기반 검증과 비용

   1. 매번 새 세션이 같은 계약에 대해 평가되면 단발성 채팅 결과와 달리 업무의 기준점이 유지된다. 모델의 자기평가를 줄이고, 리뷰 결과가 수용될 때까지 개선 과정을 반복하게 한다.
   2. 비용은 반복 실행에서 쌓일 수 있으므로 유료 동작 승인과 더불어 검증된 실행 흔적의 고정이 중요하다. 처음에는 강한 모델이 해결법을 찾고, 결과를 통과시킨 절차를 고정한 뒤 더 저렴한 모델로 돌릴 수 있다.

3.3. Jev 의사결정 모델의 후보 역할

1. 검증기와 이벤트 라우터

   1. 저렴한 분류기(classifier)는 계약이 정의한 이상 상태와 실제 결과를 비교해 통과 여부를 판단하는 후보이다. 계약을 채우는 생성 모델과 달리 Jev는 “통과했는가, 상태가 바뀌었는가”를 결정한다.
   2. 모든 GitHub 이벤트를 사용자가 이슈 처리 Job 또는 PR 리뷰 Job으로 직접 보내는 대신, 들어온 이벤트의 의미에 따라 적합한 계약으로 라우팅하는 역할도 구상됐다.

2. 의미 캐시와 의존성 재실행

   1. 상위 의존성의 입력이 바뀌었을 때 어떤 하위 작업을 다시 실행할지를 판단하는 일은 기존 에이전트로 돌리면 비싸다. React의 구성 요소와 캐시를 연상시키는 의존성 흐름에서 의미 분류기는 무엇이 오래됐는지 판단하고 하위 노드를 다시 실행할 수 있다.
   2. 이 역할은 의미 메모이저(semantic memoizer)나 캐시에 가깝다. Jev 연동은 아직 개발 중이므로 현재 기능과 계획 중인 기능을 구분해야 한다.

4. 금융기관 사례 — 내부 운영 지식과 정량 모델 문서

4.1. 내부 하네스와 승인된 모델을 그대로 사용한다

1. 민감한 지식의 외부 반출을 줄인다

   1. OpenProse는 사내 서버(on-premises)와 사내 하네스 위에서 운영할 수 있고, 자체 호스팅 모델과 기업이 승인한 모델도 사용할 수 있다. 조직은 데이터뿐 아니라 표준운영절차(SOP)와 기관의 운영 지식을 외부 대형 모델 업체에 보내지 않을 수 있다.
   2. OpenProse는 조직의 운영 지식을 문서화한 계층으로 볼 수 있다. 사내 시스템 안의 Markdown 계약을 기존 가드레일·추론 환경과 결합해, 조달이나 IT 부서가 새 인프라를 도입하지 않아도 실험할 수 있다는 점이 규제 산업의 이점으로 제시됐다.

2. Markdown과 개방형 라이선스

   1. 업무 지식과 프로그램이 텍스트이므로 Git에 저장하고 버전을 관리하거나 기존 문서 도구에서 팀이 검토하기 쉽다. 실행 환경을 바꾸더라도 계약을 Markdown 파일로 내보내 다른 사람의 환경에서 가져올 수 있다.
   2. 오픈 코어(open core)와 허용적 라이선스(permissive license)가 제공되며, 여러 대기업이 이미 내부에서 사용 중이다. 호스팅 버전은 선택 사항이고 도입과 실행을 사내에서 구성할 수 있다.

4.2. 규제 문서화 업무를 계약으로 표현한다

1. 정량 모델 문서의 반복 요건

   1. 금융기관은 정량 모델이 무엇에 쓰이는지, 어떤 조건에서 테스트됐는지, 어떤 상위·연관 모델에 연결되는지 등을 규제기관·내부 감사·컴플라이언스 요구에 맞춰 기록해야 한다.
   2. 문서는 매년 또는 3년 주기, 또는 특정 사건·모델 변경에 따라 갱신된다. 전문성을 가진 직원의 시간이 문서 작성에 많이 들며, 정기적으로 많은 모델을 관리하는 대형 은행에서 비용이 크게 누적된다.

2. SOFR 곡선 문서화 데모

   1. Codex에서 커널(kernel)과 개별 계약 프로그램을 함께 실행했다. Claude Code나 다른 자체 하네스에서도 같은 Markdown 프로그램을 사용할 수 있다.
   2. 데모에는 내부 은행 데이터를 노출하지 않도록 공개 SOFR 곡선 모델을 사용했다. 결과물에는 규제·감사·컴플라이언스 요구와 이상적인 최종 상태를 계약 조건으로 반영했고, 상대적으로 저렴한 모델로 실행해 더 빠른 결과를 얻었다.

3. 비용 규모와 품질 검증

   1. 큰 은행에는 약 4,000개의 정량 모델이 있고, 문서를 해마다 다시 작성하는 문제의 규모는 연간 1,000만~5,000만 달러로 제시됐다. 자동화 결과는 수작업보다 훨씬 저렴하면서도 “놀라울 만큼 좋다”고 평가했다.
   2. 역사적 문서, 담당 팀이 쓰는 시간, 현장 정량 분석가의 평가를 기준으로 결과를 비교할 수 있다. 다만 규제기관·감사·컴플라이언스의 승인 절차까지 사라지는 것은 아니며, 전문가가 모델 결과를 평가해야 한다.

4. 사람이 잘하는 일에 전문성을 돌린다

   1. 반복 서류 작업을 자동화하면 정량 분석가는 모델을 만들고 검증하는 전문 업무에 더 시간을 쓸 수 있다. 데이터 생성과 판단의 책임을 없애기보다 문서화 과정의 반복 부담을 줄인다.
   2. 규제 문서 자체가 요구사항과 완료 조건을 이미 담고 있어 OpenProse 계약과 잘 맞는다. 규제 요구를 Markdown 계약으로 표현하고, 에이전트가 조건을 충족한 문서와 근거를 작성하도록 한다.

5. 적합한 사용처, 계약 합성, 질의응답

5.1. 탐색 대화와 반복 업무를 구분한다

1. 대화형 AI가 더 적합한 순간

   1. 무엇을 원하는지 아직 모르거나 문제의 형태도 잡히지 않은 탐색 단계라면 ChatGPT 같은 채팅이 시작점으로 적합하다. 채팅은 찾고 싶은 것도 명확하지 않은 사람도 대화를 시작해 예상 밖의 결과를 얻도록 해준다.
   2. DSP처럼 결과 객체의 시그니처를 먼저 정의해야 하는 방식은 원하는 상태를 미리 알아야 한다. OpenProse는 상대적으로 덜 엄격하지만 계약을 작성하려면 결과가 무엇인지 어느 정도 알아야 한다.

2. OpenProse가 맞는 업무

   1. 일회성 요청·실험·탐색보다 자주 반복되고, 신뢰성(reliability)·재현성(repeatability)·감사 가능성(auditability)이 필요한 업무에 맞는다.
   2. 채팅 파트너처럼 설계된 모델은 대화가 필요 없는 워크플로의 최적 인터페이스가 아닐 수 있다. 조직이 반복 실행할 업무와 계약을 알고 있을 때 목적·입력·완료 기준을 고정한다.

3. 계약 작성 지원과 안전장치

   1. 커널에는 결과 조건을 선언하는 모범 사례와 안티패턴이 포함될 수 있다. 사용자가 계약 전체를 직접 쓰기보다 별도 에이전트와 대화하며 요구를 구체화하고, 가이드를 따라 계약을 반복 개선한다.
   2. 호스팅 앱의 대화형 에이전트는 프로그램 작성을 돕고 기능 대부분을 조작할 수 있지만, 비용이 발생하는 행위는 확인 버튼을 요구한다. 의도를 사람 머릿속에서 꺼내는 일은 여전히 어려우며, 계약은 그 문제를 다루는 일부이지 완전한 해결책은 아니다.

5.2. 계약을 합성해 전체 다중 에이전트 흐름을 템플릿화한다

1. 상속보다 구성(composition)

   1. 여러 계약을 한 번의 실행에 주입해 에이전트가 복수 조건을 모두 만족하게 만드는 것이 핵심이다. 각 계약은 다른 서비스가 요구하는 조건을 선언하고, 전체 프로그램은 그 계약들을 결합한다.
   2. 상위 의존성의 변화가 하위 작업에 전달되는 이벤트 흐름도 계약 합성으로 볼 수 있다. 단순한 정적 템플릿처럼 빈칸만 채우는 것이 아니라, 다중 에이전트 워크플로 전체의 실행 모양을 재사용한다.

2. 중간 계약을 체크포인트로 둔다

   1. 최종 결과만 계약으로 선언할 수도 있지만, 중간 단계마다 “이 조건을 만족해야 다음으로 진행한다”는 계약을 둘 수도 있다. 각 체크포인트가 충족되면 다음 단계가 시작된다.
   2. 중간 결과의 방법은 계속 유연하게 두면서 전체 경로를 여러 계약으로 표현할 수 있다. 선언형 계약만으로도 구성 단계에 어떤 결과가 필요한지 정해 간접적으로 작업 순서를 설계한다.

3. 조사·작성·교정과 다중 에이전트 패턴

   1. 기사 작성 프로그램은 연구 에이전트에게 Exa CLI와 전용 검색 스킬을 주고, 작성 에이전트에게는 과거의 좋은 글 열 편과 문체 기준을 제공하며, 교정 에이전트를 별도로 둔다. 이런 흐름은 약 100줄의 Markdown으로 구성할 수 있다.
   2. 팬아웃 후 결과를 모으는 팬인(fan-out/fan-in), 적대적 리뷰(adversarial review), 조건이 충족될 때까지 반복하는 루프 등 Claude의 동적 워크플로 유형을 호환 하네스의 계약으로 정의할 수 있다.

4. 필요한 실행 기반

   1. 복잡한 다중 에이전트 작업에는 하네스의 서브에이전트 지원이 중요하다. 당시 기본 pi에는 서브에이전트가 없었으므로 복잡한 패턴을 실행하기 어려웠다.
   2. bash가 필수인 것은 아니며 코드 모드(code mode)의 VM 격리 환경에서도 실행할 수 있다. 핵심은 특정 도구 묶음이 아니라 필요한 계약과 에이전트를 실행할 수 있는 하네스다.

5.3. 텍스트의 버전 관리, 강화학습, 경험적 검증

1. 강화학습(RL)의 잠재력

   1. 계약이 텍스트라 Git에 커밋해 버전 관리하고 Notion·Jira 등에서 팀이 공유하기 쉽다. 같은 구조 덕분에 성공한 프로그램과 실행 결과는 강화학습 데이터로 쓰기에도 적합할 수 있다.
   2. 강화학습은 진행 중이 아니며 여러 잠재 고객과 활용 가능성을 논의하고 있다. 호스팅 모델에 약 10만 토큰 접두 프롬프트가 필요하다면 대규모 호출을 위해 토큰 효율 표현으로 압축(gisting)할 수 있다.

2. 경험과 벤치마크로 커널을 다듬는다

   1. 커널은 요구사항을 잘 쓰는 사람과 어려워하는 사람을 상대로 쌓은 엔지니어링 경험을 바탕으로 구성된다. 실제 계약을 시스템에 넣고 실행해 준수 여부를 내부에서 벤치마크한다.
   2. 요구 조건을 계속 만족하는지 보면서 커널을 줄이는 진화 알고리즘(evolutionary algorithm)도 사용한다. 이 접근은 추상적 선언에만 기대지 않고 경험적 결과를 기준으로 개선한다.

3. 명세 주도 개발과 스킬 연결

   1. Matt Pocock의 엔지니어링 스킬 흐름을 활용한 ‘auto-Pocock’ 예시는 질문으로 요구를 구체화하고, TDD 등 각 단계의 스킬을 해당 서브에이전트가 순서대로 불러오도록 만든다. 이 예시는 스킬을 필요한 시점과 작업자에게 배정하는 방식을 보여준다.
   2. 계약은 명세 주도 개발(spec-driven development)과 결합할 수 있지만, 기존 명세와 OpenProse 커널의 관계 및 여러 스킬이 결과에 미치는 영향은 아직 검증되지 않았다. 두 방식을 실제로 조합해 볼 여지가 있다.

4. 사용자 분포와 마지막 권고

   1. 소프트웨어 엔지니어가 OpenProse로 제품을 개발하기도 하지만, 더 많은 사용자는 운영(ops), 제품 관리(product management), 정량 모델 문서화 등 소프트웨어 개발 외의 업무에 활용한다.
   2. Markdown 문서의 익숙함과 논리적인 영어 계약이 비개발자에게도 접근성을 줄 수 있다. 필요한 업무가 명확하고 자주 발생하며 감사가 필요하다면 계약과 트리거를 구성하고, 탐색 중인 일이라면 대화부터 시작한다.

주요 발언 모음

“You can write a sentence and the thing just makes that sentence true.”
원하는 문장을 쓰면 기계가 그 문장을 참이 되게 만든다.

“Tell it what to do, not how to do it.”
어떻게 할지가 아니라 무엇을 해야 하는지 말하라.

“It’s all text, and we’re doing event-driven multi-agent workflows, not chatting.”
모든 것은 텍스트이고, 대화가 아니라 이벤트 기반 다중 에이전트 워크플로를 만든다.

“You are the compiler. This is not an analogy.”
당신이 컴파일러다. 비유가 아니다.

“The contract is the program.”
계약이 곧 프로그램이다.

“The intent behind OpenProse is similar to DSP … the implementation is the exact opposite.”
OpenProse가 추구하는 추상화는 DSP와 비슷하지만, 구현은 정반대다.

“You don’t want to use this if you’re doing a one-off.”
일회성 작업이라면 이 도구를 쓸 필요가 없다.

핵심 데이터와 수치

• 2021년 4월: Dan Barrett이 Aluther AI 백룸 Discord에서 ‘최고의 프롬프터’로 선정됐다.
• 약 2~3년: Barrett이 당시 프롬프팅 기술의 중심성이 유지된 기간으로 추정했다.
• 최근 8~10개월: 하네스와 서브에이전트 구조의 추상화가 빠르게 올라갔다.
• 약 7만~8만 토큰: OpenProse의 전체 런타임 프롬프트·스킬 규모. 더 짧게 다듬고 있다.
• 수십 개 PR, 며칠: GitHub 웹훅 데모가 짧은 기간 처리한 PR의 규모다.
• 최대 14회 리뷰: 리뷰 에이전트가 합의해 통과시키기 전까지 일부 PR이 거친 리뷰 라운드 수다.
• 약 10만 토큰: 호스팅 모델이 처리할 수 있는 프롬프트 접두부 규모로 가정해 토큰 압축 가능성을 논의했다.
• 약 100줄 Markdown: 조사·작성·교정 등 역할이 다른 다중 에이전트 업무를 표현하는 예시 규모다.
• 약 4,000개 모델: 대형 은행이 보유할 수 있는 정량 모델 수로 제시됐다.
• 연간 1~3년 주기 및 사건 발생 시: 정량 모델 문서를 갱신하는 예시 주기다. 특히 대형 은행의 약 4,000개 모델은 해마다 문서화해야 한다고 덧붙였다.
• 연간 1,000만~5,000만 달러: 일부 대형 은행의 정량 모델 재문서화에 드는 잠재 비용 범위다.
• 초기 모델 구성: 호스팅 앱에서 데모 당시 OpenAI 상위 세 모델을 선택할 수 있었다.
• 공개 SOFR 곡선: 은행 내부 데이터를 노출하지 않고 문서 생성 품질을 시연하기 위해 사용한 모델 사례다.

결론 및 시사점

1. 에이전트가 강해질수록 사람이 손으로 절차를 구체화하는 대신, 목표·입력·완료 조건을 명확히 정의하는 역량이 중요해진다.
2. 처음에는 방법을 열어 두고 강한 모델이 답을 찾게 한 뒤, 검증된 실행을 계약과 추적으로 고정해 비용을 낮추는 단계적 접근이 유효하다.
3. 계약은 단순한 프롬프트 템플릿이 아니라 입력·의존성·결과·증거·트리거가 결합된 재사용 가능한 다중 에이전트 프로그램이다.
4. 반복되는 PR 검토나 규제 문서화처럼 오류 비용과 감사 요구가 큰 업무에는 독립 세션, 명시적 계약 검증, 사람 승인 단계가 필요하다.
5. 금융 분야에서는 조직의 운영 지식과 SOP를 외부 서비스에 넘기지 않고 내부 모델·하네스에서 계약으로 실행할 수 있다.
6. 결과가 불명확한 탐색은 채팅으로 시작하고, 반복성·신뢰성·감사 가능성이 필요한 업무가 형태를 갖춘 뒤 OpenProse로 굳히는 편이 맞다.