에이전트에 사람을 어디에 끼워 넣을지 묻는 질문은 대개 “중요한 일에는 확인을 받게 하자”로 끝난다. 그런데 ‘중요한 일’은 판별 기준이 아니다. 실제로 작동하는 기준은 하나뿐이다 — 되돌릴 수 있는가. 그리고 이 기준을 쓰려면 그 전에 해야 할 일이 있다. 우리 도메인에서 무엇이 비가역인지를 미리 목록으로 적어 두는 것.
근거
카페 서비스라면 결제와 예약 취소가 비가역 목록에 들어간다. 도메인이 바뀌면 목록도 바뀐다. 이 목록을 만들어 두면 시스템 프롬프트에 “이 작업이 목록에 해당하는지 판별하라”는 규칙을 심을 수 있고, 해당하면 무조건 사람의 승인을 받게 할 수 있다.
그래서 이 목록을 미리 정리해 두는 작업이 생각보다 중요합니다. 목록이 없으면 판별 기준도 없는 거니까요.
이 한 문장이 이 인터뷰에서 가장 실무적인 대목이었다. 가드레일을 못 만드는 이유는 대개 기술이 없어서가 아니라, 무엇을 막아야 하는지 적어 본 적이 없어서다. 같은 이유로 읽기와 쓰기의 분리도 쉽게 정해진다. 읽는 것만으로는 되돌릴 수 없는 일이 생기지 않으니 읽기는 다 열어도 되고, 쓰기는 승인을 건다.
여기서 따라오는 결론이 하나 더 있다. 비개발자도 이걸 구현할 수 있다. AI에게 “이거 고려해서 만들어 줘”라고 요구하면 상당 부분 알아서 짜 준다. 어려운 건 만드는 기술이 아니라 무엇을 요구해야 하는지 아는 쪽이고, 그 요구의 실체가 바로 이 목록이다. 나 자신의 파이프라인에도 적용된다 — 자동 커밋, 퍼블리시, 파일 삭제 중 무엇이 비가역인지 나는 아직 적어 두지 않았다.
연결된 생각
- 20260814-write-permission-should-converge-on-one-manager-agent — 권한이 모인 지점에서 이 목록이 게이트로 작동한다
- 20260609-dual-safety-net-natural-language-rules-and-code-hooks — 목록을 자연어 규칙과 코드 훅 어느 층에 심을지의 문제
- 20260623-automation-needs-human-relationship-brakes — 자동화에 사람이 개입할 지점을 정하는 다른 관점
- 20260814-agent-security-as-renamed-legacy-security — 코드 게이트라는 전통 보안 기법의 AI 판 적용