한눈에 요약
- 각 에이전트가 무엇을 하고 무엇을 반환할지 미리 못박아 두는 명세다. 담당 범위, 쓸 수 있는 도구, 권한의 한계, 절대 하면 안 되는 일이 여기 들어간다.
- 에이전트를 여러 개 굴리기 시작하면 서로 같은 파일을 건드리고 충돌한다. 그걸 사전에 막는 장치다.
- 새로 생긴 개념이 아니다. 원래 하던 일에 계약(contract)이라는 이름이 붙었을 뿐이다.
- 사람을 언제 불러야 하는지까지 계약에 넣는 것이 포인트다. 그게 빠지면 에이전트가 혼자 튀어 나간다.
왜 필요한가
에이전트 하나를 쓸 때는 문제가 없다. 여러 에이전트가 한 프로젝트를 같이 만지기 시작하면 이야기가 달라진다. 서로 싸우지 않고 충돌하지 않게 하는 일이 갑자기 중요해진다 30.
그래서 2026년 들어 "계약"이라는 말이 부쩍 늘었다. 한국어로 계약이라고 하면 어색한데 **컨트랙트(contract)**라고 하면 익숙하다. 함수의 시그니처처럼, 각자가 무엇을 받고 무엇을 돌려줄지 적어 둔 약속이라고 보면 된다 30.
계약에 들어가는 것
| 항목 | 내용 | 예 |
|---|---|---|
| 담당 범위 | 어디까지 읽고 어디를 건드리면 안 되는지 | "너는 DB 전문이니 다른 데는 건드리지 마" |
| 입출력 | 무엇을 받고 무엇을 꺼내야 하는지 | 입력 스키마, 산출물의 반환 형식 |
| 도구·권한 | 어떤 도구를 쓸 수 있고 권한은 어디까지인지 | 읽기만 허용, 삭제 명령 금지 |
| 금지 사항 | 절대 하면 안 되는 것 | "중간 실험 로그는 지우지 말아라" |
| 호출 조건 | 어떤 상황에서 사람을 불러야 하는지 | 되돌릴 수 없는 작업 직전 |
앞의 세 줄이 일을 굴러가게 하는 계약이라면, 뒤의 두 줄은 안전장치의 계약이다 30.
하네스와의 관계
계약은 하네스 엔지니어링 안에 들어가는 한 갈래다. 하네스가 "에이전트가 실수하지 않게 하는 장치 전부"라면, 계약은 그중 일을 시키기 전에 미리 적어 두는 쪽을 맡는다 30.
그래프 엔지니어링과도 붙어 있다. 그래프의 각 노드가 지켜야 할 규약이 곧 계약이기 때문이다. 반대로 루프 엔지니어링에서는 계약이 더 중요해진다. 사람이 중간에 안 보는 만큼, 안 보는 동안 지켜질 규칙을 미리 다 적어 둬야 하기 때문이다.
여기서 헷갈리기 쉬운데, 계약은 프롬프트에 "잘 해 줘"라고 적는 것과 다르다. 무엇을 반환해야 하는지, 무엇을 만지면 안 되는지가 사전에 확정된 명세라는 점이 다르다. 이 위키의 표현으로는 부탁이 아니라 강제 쪽에 가깝다 11.
함께 읽기
- 하네스 엔지니어링 — 계약이 속한 상위 개념
- 서브에이전트 & 에이전트 팀 — 계약이 실제로 필요해지는 자리
- 그래프 엔지니어링 — 계약을 노드 사이의 흐름으로 확장한 접근
- 훅 — 계약의 금지 사항을 기계적으로 강제하는 수단