4월 28일에 저희 에이전트 "뚝딱"의 계획-승인-실행 구조를 썼는데, 그 뒤로 "우리 에이전트에도 적용하고 싶은데 어디서부터 해야 하냐"는 질문을 여러 번 받았어요. 그래서 오늘은 제품 얘기가 아니라 일반 원칙으로 다시 정리할게요.
권한은 모델이 아니라 도구에 붙어요
제일 먼저 바꿔야 할 생각이 이거예요. "모델에게 어디까지 허용할까"가 아니라 "각 도구가 뭘 할 수 있고 어떤 조건에서 실행되나" 예요. 모델은 도구를 부를 뿐이고, 도구가 실제 일을 해요. 권한 설계는 도구 정의에서 시작해요.
도구마다 최소한 이 메타데이터가 있어야 해요.
| 항목 | 뜻 | 예 |
|---|---|---|
reversible |
되돌릴 수 있나 | 조회 true, 발송 false |
scope |
영향 범위 | 본인 데이터 / 팀 / 전사 |
requires_approval |
승인 조건 | never / always / 조건식 |
rate_limit |
호출 한도 | 10/min |
allowed_callers |
누가 쓸 수 있나 | 역할 목록 |
이걸 모델이 바꿀 수 없게 하세요. 프롬프트로 "이건 승인 안 받아도 돼"라고 해도 소용없어야 해요.
승인은 "실제 값"을 보고 해요
"메일을 보낼게요"를 승인하는 건 승인이 아니에요. "김OO 외 3명에게 '2분기 미수금 안내' 제목으로 이 본문을 보낼게요"를 승인해야 해요. 계획 단계에서는 값이 없으니, 되돌릴 수 없는 도구의 실행 직전에 실제 인자를 보여 주고 멈추세요.
승인 피로를 줄이는 방법은 패턴 저장이에요. "이 수신자 그룹에 이 템플릿은 항상 허용". 단, 핵심 값(수신자, 금액, 대상 건수)이 저장 당시 범위를 벗어나면 다시 물어야 해요.
계획에 없는 건 실행 안 해요
에이전트가 실행 중에 "추가로 이것도 하는 게 좋겠다"며 새 도구를 부르는 걸 막으세요. 승인된 계획 밖의 호출은 거부하고 재계획으로 돌아가요. 이게 없으면 승인이 의미가 없어요. 승인받은 계획과 다른 일을 하니까요.
실패하면 멈춰요
5단계 중 3단계가 실패했는데 4·5단계를 계속하면 안 돼요. 특히 "일부 수신자에게만 발송됨" 같은 반쯤 된 상태가 최악이에요. 실패 시 중단하고, 어디까지 됐는지 사용자에게 보여 주고, 재개 여부를 물으세요.
감사 로그에 남길 것
- 누가, 언제, 뭐라고 지시했나
- 어떤 계획이 만들어졌나 (모델 버전, 프롬프트 버전 포함)
- 누가, 언제, 뭘 보고 승인했나
- 각 도구 호출의 인자와 결과 (내용은 요약·해시, 전문은 별도 보관)
- 실패와 중단 지점
로그는 수정할 수 없는 저장소에 두세요. 그리고 로그에 문서 내용이나 개인정보를 그대로 넣지 마세요. 나중에 외부 감사나 장애 분석으로 로그를 반출해야 할 때 못 꺼내요.
최소 권한부터 시작하세요
새 에이전트는 조회 도구만 갖고 시작해요. 사용자가 몇 주 써 보고 신뢰가 생기면 가공, 그 다음에 되돌릴 수 없는 도구를 하나씩 열어요. 처음부터 다 열어 주고 "조심하겠지"라고 기대하면 안 돼요. 모델은 조심하지 않아요. 구조가 조심해야 해요.
테스트는 이렇게
4월 14일 평가셋 글의 연장인데, 권한 설계에는 특히 이런 케이스가 필요해요.
- 되돌릴 수 없는 도구를 승인 없이 부르려는 시도 → 반드시 거부
- 프롬프트 인젝션으로 "승인 생략" 지시 → 무시
- 계획에 없는 도구 호출 → 거부 후 재계획
- 중간 실패 → 이후 단계 미실행
이 네 가지가 통과 안 하면 배포하지 마세요.
정리
- 권한은 도구 메타데이터에, 모델이 못 바꾸게.
- 승인은 실제 값을 보고, 되돌릴 수 없는 실행 직전에.
- 계획 밖 호출 금지, 실패 시 중단.
- 감사 로그는 수정 불가, 내용은 제외.
- 조회부터 시작해서 권한을 하나씩 열기.
다음 주는 RAG 구축 가이드예요. 모델이 아니라 문서 전처리가 답변 품질을 정한다는 얘기를 사례와 함께 할게요.