Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 서브 에이전트의 출력에 대한 세밀한 지시의 중요성을 강조하며, AI 개발 과정에서의 실질적인 경험을 공유합니다. 특히 Opus 모델과 Sonnet 모델을 비교하는 실험을 통해, 하위 모델(Sonnet)에게는 검증 지시가 없어도 높은 성능을 보일 수 있음을 입증했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이 글은 연재 '말하지 않는 기술'의 제6회입니다. 잘 안 되는 증상과 그 대처를 하나씩 나열하고 있습니다. 각 회차는 파일이나 스크립트를 하나 두기만 하면 완성됩니다. 그 구조가 왜 필요한지는 배치한 후에 설명을 읽으면 알 수 있습니다. 연재 전체 개요와 각 회차 목록은 서론에 있습니다.
이번에는 서브 에이전트에 대한 이야기입니다. 서브 에이전트란 메인 세션(AI와의, 시작부터 끝까지 이어지는 일련의 대화)을 인계받지 않고 따로 띄워서 작동하는 AI를 말합니다. 이 연재에서 제가 세밀하게 적고 있는 지시는 오직 서브 에이전트에 대한 지시뿐입니다. 그 지시 중에서도 제가 세밀하게 적는 것은 출력 형태에 한정됩니다.
이 연재를 통해 저는 AI에게 말하는 것을 줄여왔습니다.
하지만 이번 회차만은, AI에게 말하는 것을 늘립니다.
서브 에이전트의 출력만큼은 세밀하게 지시해야 합니다.
AI의 출력을 읽지 않아도 되는 첫 번째 작품 '읽지 않는 기술'에서는 제5회에서 '서브 에이전트의 출력만은 읽어라'라는 예외를 만들었습니다. AI의 의견을 검토하지 않는 전작 'AI의 의견을 듣지 않는 기술'에서는 제4회에서 '서브 에이전트의 입력만큼은 확인하라'라는 예외를 만들고 있습니다. 세 작품 모두 예외 대상은 같습니다.
먼저 한 가지만 떠올려 보세요.
최근에 서브 에이전트를 구동했을 때의 상황입니다.
그 서브 에이전트에 전달한 지시 작성 방식이, 서브 에이전트가 작동한 모델로 시험해 본 것이었습니까?
제2회에서 저는 지시 파일과 스킬 및 용도 카탈로그(서브 에이전트에게 맡겨도 되는 업무와, 구동 전에 준비해 둘 파일 목록) 세 가지에 작업 진행 방식을 0건이라고 적었습니다. 손에 남은 절차도 0건이라고 그때의 저는 생각했습니다. 제가 다시 세어보니, 절차가 1개 있었습니다.
제2회에서 제가 센 것은 그 세 가지 본문까지였습니다. 용도 카탈로그가 '구동 전에 준비해 두라'고 지시하는 파일 안의 내용은 셀 범위 밖에 있었습니다. 남아있던 1개는 그러한 파일 중 하나로, 서브 에이전트에게 전달하는 안내서였습니다.
제1회에서 저는 검증을 지시한 AI와, 지시하지 않은 AI를 비교했습니다. 그 비교에서는 둘 다 opus를 사용하고 있습니다. 그런데 서브 에이전트는 opus가 아닌 다른 모델로 작동할 수 있습니다.
저의 용도 카탈로그에는 화면 문구를 번역하는 용도에 model: [sonnet, haiku]라고 적고 주석으로 'opus를 기본값으로 하지 않음'이라고 달았습니다. 연재 기사를 번역하는 용도는 model: [sonnet, opus]로, 어느 모델로든 작동합니다. 제1회의 결과가 opus 외의 모델에서도 동일한지는 확인하지 못했습니다.
그래서 저는 제1회와 같은 과제를 sonnet에게도, 검증을 지시할 경우와 지시하지 않을 경우 두 가지 방식으로 풀게 했습니다. 과제는 특정 연재 기사 10개에서 정해진 형식의 문장을 하나씩 뽑아 표로 만드는 것이었습니다.
| 모델 | 검증 지시 | 도구 호출 | |
|---|---|---|
| A | opus | 있음 | 8 |
| B | opus | 없음 | 4 |
| C | sonnet | 있음 | 13 |
| D | sonnet | 없음 | 3 |
네 개의 답은 모두 제가 사전에 스크립트로 만든 정답표와 완벽하게 일치했습니다. 과제에는 함정이 하나 숨겨져 있어, 10번째 기사에만 뽑아낼 형식의 문장이 없습니다. 네 개 모두 이 함정을 피하고 있습니다.
저의 가설은 '하위 모델에는 세밀한 지시가 필요하다'였습니다. 이 가설은 틀렸습니다. sonnet은 검증 지시가 없어도 10/10을 내고, 수고(도구 호출 횟수)도 opus보다 적게 들었습니다 (4회 대 8회).
검증을 지시해도 네 개의 답은 변하지 않았습니다. 바뀐 것은 수고입니다. 제1회의 opus에서 발생했던, 검증을 지시하면 수고가 늘어나는 현상은 sonnet에서도 일어났습니다. 증가 방식은 모델에 따라 달랐습니다. 검증을 지시하지 않았을 때와 비교하여, opus의 수고는 2배(4 → 8)가 되었고, sonnet의 수고는 4.3배(3 → 13)가 되었습니다.
또 다른 두 모델은 검증을 지시하지 않았는데, 보고서의 내용이 갈렸습니다. opus는 보고서 처음에 '지정된 단어를 디렉토리 전체에서 grep 했다. 9개 파일에 정확히 한 번씩, 10번째에는 0번'과 같이 검증한 숫자를 적었습니다(제1회의 B입니다. 원문은 영어). sonnet이 검증에 대해 보고서에 적은 것은 '나머지 9개 모두에서 해당 구절과 굵게 표시된 한 문장을 확인했습니다'라는 한 문장뿐이었습니다.
보고서의 차이는 확인한 범위의 차이가 아니었습니다. 두 모델의 기록을 열어보면, sonnet도 opus와 마찬가지로 두 개의 지정 단어를 10개 모두에서 grep 했고, 10번째는 전체 내용을 열어서 '문장'이라는 단어를 찾고 있습니다. 달랐던 것은 확인한 것을 보고서에 적었는지 여부였습니다.
이 차이는 기록을 열어봐야 알았습니다. '읽지 않는 기술'의 제5회에서 썼듯이, 메인 에이전트에게 돌아오는 것은 서브 에이전트의 마지막 메시지, 즉 보고서입니다. 답이 정답표와 일치한다는 것만으로는, AI가 답을 검증했는지 여부는 알 수 없습니다. '읽지 않는 기술'의 제9회에서 썼듯이, 보고서는 AI의 자기 신고입니다. sonnet의 '확인했습니다'도, opus가 적은 숫자도, 각각의 모델이 보고서에 작성한 신고일 뿐입니다.
Anthropic의 프롬프트 지침에도 모델에 대한 단서 조항이 있습니다. 특정 모델명이 붙은 기술은 그 모델로 측정한 것으로 간주하며, 다른 모델에 적용하기 전에 스스로 확인하라는 내용입니다.
만약 당신이 같은 형태의 작업을 서브 에이전트에게 맡겼다고 가정해 봅시다. opus로 실행했을 때의 보고서에는 확인한 건수가 나열되어 있었습니다. 다른 모델로 실행했을 때의 보고서는 '모두 확인했습니다'라는 한 문장뿐이었습니다. 출력을 보니, 둘 다 맞았습니다. 다음에 같은 작업을 맡길 때, 당신은 다음 중 어느 것을 선택하겠습니까?
정답은 출력의 형태를 작성하고 프로그램으로 판별하는 쪽입니다. 보고서가 한 문장이라도, 그 모델이 확인하지 않았다고 단정할 수 없습니다. 제 기록에서 sonnet은 한 문장만 보고했지만, opus와 같은 범위로 grep하여 확인했습니다. 달랐던 것은 확인한 것을 보고서에 적는지 여부였고, 보고서는 어떤 모델이 작성하든 그 모델의 자기 신고입니다. 절차를 상세히 작성해도 돌아오는 것은 역시 보고서이며, 확인했는지 여부는 보고서 내용만으로는 알 수 없습니다. 게다가 sonnet은 절차나 검증 지시가 없음에도 opus보다 적은 노력으로 정답했습니다. 출력의 형태를 작성하고 그 형태인지를 프로그램으로 판별하면, 어떤 모델로 실행하든 통과하는지 여부는 보고서가 아닌 출력에서 결정됩니다.
이해한 바는 한 문장으로 정리할 수 있습니다.
말하지 않아도 되는 기술 중에서, 모델이 스스로 하도록 맡기는 것은 내가 측정한 모델을 기반으로 확인한 것이다. 서브 에이전트는 다른 모델로 실행될 수 있고, 나의 측정에서는 확인한 것을 보고서에 적는지 여부마저 모델마다 달랐다. 그러므로 출력의 형태—무엇을 완료로 간주할지—를 작성하고, 출력이 그 형태인지는 보고서를 읽지 않고 프로그램으로 판별한다.
매뉴얼에 적힌 형태로 출력을 판정하는 것은 매뉴얼과는 별도의 파일에 있는 인수 테스트(서브 에이전트의 출력을 메인 에이전트 측에서 판정하는 스크립트)입니다. 인수 테스트는 원본과 번역문을 비교하여 링크, 제목, 목록, 단락, 코드, 숫자, 장식 등이 일치하는지 대조합니다.
인수 테스트가 구체적으로 무엇을 어떻게 세는지(예: 한 자릿수는 글로 풀어 써도 되는지 등)는 매뉴얼에 적혀있지 않습니다. 인수 테스트는 실패했을 때, 어긋난 항목의 이름과 개수, 그리고 다음에 해야 할 일을 출력합니다. 매뉴얼에 작성된 내용은 출력의 형태와, 번역하기 전에 알아두어야 하는 것(용어의 정확성, 묶음 처리 방식 구분, 건드리지 말아야 할 부분)입니다.
매뉴얼을 작성한 후, 매번 의뢰받을 때 제가 작성하는 것은 "이 기사를 이 언어로"라는 것뿐이 되었습니다. 제가 세밀하게 작성했던 것은 매뉴얼을 작성했을 단 한 번입니다.
첫째는, 이 결과만으로는 "하위 모델은 틀릴 수 있다"라고 쓸 수 없다는 점입니다. 4개 모두 10/10이었습니다. 제가 측정한 것은 하나의 과제를 각 조건에서 한 번씩 풀게 한 결과일 뿐, 통계가 아닙니다. 이 측정으로 관찰할 수 있었던 것은 "쉬운 과제에서는 차이가 나지 않았다"는 것까지였습니다.
둘째는, 제가 매뉴얼을 작성하고 있는 용도가 같은 형태의 출력이 여러 개 나오는 경우에만 해당된다는 것입니다. 단순히 읽기만 하는 조사 목적의 경우에는 매뉴얼 없이 구동합니다.
셋째는, 매뉴얼에 적힌 조건이 지켜지는 것도 다른 지시와 마찬가지로 서브 에이전트가 매뉴얼을 읽었을 때뿐이라는 것입니다. 조건을 빠뜨린 출력이, 매뉴얼이 읽히지 않아도 실패하는 것은 인수 테스트가 존재하기 때문입니다.
전제 조건
소요 시간: 10분
절차
합격 조건(모두 충족해야 함)
합격하지 못한 경우
마무리 작업
인수 테스트가 보고 있는 것은 구조의 동일성, 즉 원본과 번역문의 구조가 같은지 여부입니다. 번역문 의미가 올바른지는 사람이 봅니다. 프로그램으로 정할 수 있는 부분까지는, 저는 프로그램에 결정하도록 시켰습니다.
다음 회차는 "AI를 추궁하지 않는 기술". 저는 AI가 틀려도 추궁하지 않습니다. 그래도 오류는 수정됩니다.
연재 「말하지 않는 기술」
