원문 발행 2026. 10. 28. 11:13원문 언어 영어AI 한국어 번역Zenn AI 원문 보기
요약
본 글은 서브 에이전트의 필요성과 메인 에이전트에 통합(folding)하는 방법을 다룹니다. Anthropic의 가이드라인과 공식 키트를 검토한 결과, 서브 에이전트는 성능 저하가 측정되거나 복잡한 추론/도구 선택이 필요한 경우에만 유지해야 합니다. 이를 통해 품질을 높이고 비용 및 지연 시간을 줄일 수 있습니다.
핵심 포인트
서브 에이전트는 별도의 컨텍스트, 툴, 지침을 가진 독립적인 에이전트입니다.
'접기(fold)'는 담당 업무를 메인 본체로 통합하는 것을 의미합니다.
서브 에이전트를 유지하려면 성능 저하가 측정되는 등 명확한 근거가 필요합니다.
단일 루프 구조가 실행 시간을 단축시키고 품질을 개선할 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
서브 에이전트는, 많아질수록 에이전트를 더 현명하게 만드는 것일까요? 이 글은 그 개념을 정리하기 위한 글입니다.
서브 에이전트는 자신만의 컨텍스트(context), 툴(tool), 지침을 가진 별도의 에이전트입니다. Claude Code의 경우, 이는 .claude/agents/ 폴더에 위치하는 것입니다.
'접는다(fold)'는 것은 담당 업무를 없애지 않으면서 그 절차나 도구를 메인 본체 하나로 통합하는 것을 의미합니다.
진행 방식은 2단계입니다. 먼저, Anthropic의 기사(2026-10-22)에서 제시한 '남겨야 할 3가지 조건'과 전문가들의 시각을 질문별로 나열합니다.
다음으로, Anthropic 공식 키트인 single-agent-loop-kit에 포함된 문의 창구(분배 담당 + 6개 담당)를 통해 검증했습니다. 감사 능력을 적용하여 동일한 19가지 질문을 두 가지 버전으로 풀게 했습니다.
결과를 먼저 말씀드리자면, 감사가 '남겨야 한다'고 판정한 담당은 6개 중 단 하나였습니다. 19가지 질문에서는 담당 분리 버전만이 2문제를 놓쳤으며, 이 두 문제 모두 주문과 배송을 아우르는 질문이었습니다. 다만 Anthropic의 기사에서 사용한 샘플에서는, 담당을 하나 접은 후 동일한 주문과 배송 사이가 끊어지는 문제가 발생했습니다.
서브 에이전트를 만들기 전에 해야 할 일은 한 가지, 3가지 조건에 해당하는지 여부를 질문하는 것입니다. 아래에는 감사의 실제 출력 결과, 19가지 질문의 세부 내용, 요청 방식, 전문가들의 원문 자료가 있습니다.
질문: 서브 에이전트는 언제 분리해야 하는가
'분리하지 않는다'는 판단을 정면으로 다룬 것이 Anthropic의 기사입니다(Diane Sarkis・2026-10-22).
제목은 'Building agents: When to fold subagents into your main agent loop'이며, 번역하면 '서브 에이전트를 메인 에이전트 루프에 언제 접을 것인가'입니다.
기사의 결론 부분에는 다음 문장이 있습니다.
Build a small end-to-end eval, fold in one subagent, and keep it as a subagent only if the folded version scores worse, then rinse and repeat.
(작은 종단 간 평가를 만들고, 서브 에이전트 하나를 접어보고, 접은 버전의 점수가 더 낮을 때만 서브 에이전트로 남긴다. 그리고 반복한다.)
서브 에이전트를 만드는 방법을 확산시킨 측에서, 점수가 떨어진 경우에만 남기라고 적고 있습니다.
출발점 기사: 줄이면 품질과 비용도 좋아질 수 있다
기사의 주장은 서브 에이전트를 줄이고 필요한 순간에만 활성화되는 컨텍스트와 도구로 집중하는 것입니다. 이렇게 하면 품질을 높이는 동시에 비용과 대기 시간을 줄일 수 있다고 적고 있습니다. 원문은 "can improve quality while reducing cost and latency"입니다.
기사의 대상은 API로 구성된 에이전트입니다. 이 기사에서는 질문의 방식이 Claude Code에도 적용 가능하다고 읽고 있습니다.
배경으로, 팀별/문제 유형별로 서브 에이전트를 만드는 기업이 많다고 적습니다. 고객 사례에서는 단일 루프가 실행 시간이 약 2배 빨랐던 예도 보고했습니다.
기사의 3가지 조건. ①은 '무거워 보인다'만으로는 부족하며, 성능 저하가 측정되었는지 여부입니다
어느 조건에도 해당하지 않는 담당은 제거하지 않습니다. 절차는 스킬(필요할 때만 읽어들이는 매뉴얼)로, API를 호출하는 부분은 도구로 만들어 메인 본체에 통합합니다. 이것이 '접기'입니다.
도구가 너무 많아지는 것에 대한 걱정에는 기사가 답하고 있습니다. 정의가 30~50을 초과하면 선택 오류가 늘어나므로, 사용하는 사람의 의도별로 그룹화해야 한다는 것입니다.
분리했을 때 발생하는 일: 기사에서 제시하는 실패 유형
기사에서 언급된 것들 중 3가지로 추렸습니다.
전언 게임: 담당자 간에는 요약본이 전달되므로, 전달할 때마다 세부 사항이 손실된다("each handoff degrading fidelity") -
조직도 복사: 팀의 구분이 그대로 담당의 구분으로 이어진다(콘웨이의 법칙) -
이어 붙이기 프롬프트: 각 팀이 규칙을 한 문장씩 추가하여, 그 규칙들끼리 충돌한다
통합 방식: 4가지 목적지
기사의 진행 방식은 먼저 작은 평가를 만들고, 담당 하나씩 접어보면서 앞뒤를 비교하는 것입니다. 평가는 정해진 질문을 풀게 하고 합격 조건으로 채점하는 일련의 과정입니다(10문제부터 시작해도 좋습니다).
담당이 갈 수 있는 목적지는 4가지입니다.
4つの箱が横に並ぶ。「まとめる：続けて動く・同じデータを触る」「畳む：3条件のどれにも当たらない」「ツールとして呼ぶ：3条件で残す・会話はメインが持つ」「残す：客と直接話す時だけ会話ごと渡す」。下に原文 "We'd only recommend a full handoff … when it needs to talk to the user directly." と和訳「会話ごと渡すのは、客と直接話す必要がある時だけ」
'남겨야 한다'는 것은 3가지 조건뿐만 아니라, 고객과 직접 대화할 것인가에 대한 기준입니다
전문가의 시각: 질문별로 나열하기
파벌로 나누는 것이 다툼처럼 보일 수 있어, 질문별로 정리합니다.
질문 1: 언제 분할하는 것이 효과적인가?
분리하여 성공한 사례가 있습니다. Anthropic의 조사 메커니즘(2025년 보고)이 그렇습니다. 리드가 병렬로 서브 에이전트를 구동하는 구성은 사내 평가에서 단일 Claude Opus 4를 90.2% 능가했습니다. 대신, 채팅의 약 15배 토큰을 사용합니다. 이는 조건 2의 '병렬로 버리는 작업' 그 자체입니다.
Claude 블로그(Cara Phillips・2026-01-23)는 멀티 에이전트가 승리하는 경우를 세 가지로 좁힙니다. 컨텍스트 오염, 병렬화, 전문화입니다. 이 외의 경우에는 협조 비용이 우세한 것이 일반적이며, 동일한 작업을 수행하는 데 3~10배 많은 토큰을 사용한다고 언급합니다. 이는 기사의 세 조건과 거의 일치합니다.
검증(Verification)이나 리뷰 역시 분할하여 효과를 볼 수 있는 부분 중 하나입니다.
上に3枚の札（Anthropic の調べ物の仕組み・2025-06-13 の報告／Claude ブログ・Cara Phillips・2026-01-23／起点の記事・Anthropic・2026-10-22）。3枚目が強調されている。下の枠に原文 "They are effective at verification, parallel work, and modular permissioning." と和訳「サブエージェントは、検証・並列の作業・権限の分離に効く」、原文 "(good candidates are … or black-box verification)" と和訳「分ける境界の好例は … 中身を見ずに外から確かめる検証」
원문 기사는 검증을 '효과적인 부분'과 '분리 경계의 좋은 예시' 두 곳에서 언급하고 있습니다
Claude 블로그도 검증 역할은 생성 과정의 배경 지식 없이 외부에서 시도할 수 있다고 적고 있습니다.
여기서는 이 글을 읽는 것이 중요합니다. 작성자 본인의 편견을 가져오지 않고, 깨끗한 컨텍스트로 바라보는 것 자체에 가치가 있습니다. 그런 의미에서 검증이나 리뷰는 조건 2의 동료처럼 보입니다. 다만 같은 블로그에서는 똑똑한 요약 역할이라면 별도의 검증 역할 없이도 볼 수 있게 되었다고도 적습니다.
질문 2: 분할하면 무엇이 망가지는가?
앞서 언급된 조사 보고서 자체에서도, 에이전트 간 의존도가 높은 작업은 현재 멀티 에이전트에 적합하지 않다고 언급합니다. 주문을 조사한 후 배송을 조사하는 것처럼 순차적으로 쌓아 올리는 작업입니다.
Cognition의 Walden Yan은 2025-06-12자 기사에서 다음과 같이 작성했습니다. 제목은 'Don't Build Multi-Agents'(멀티 에이전트를 만들지 마라)입니다.
The decision-making ends up being too dispersed and context isn't able to be shared thoroughly enough between the agents.
(판단이 여기저기 흩어지고, 에이전트들 사이에 컨텍스트를 충분히 공유할 수 없게 된다)
이는 기사의 '전언 게임'과 같은 지점을 가리킵니다.
질문 3: 무엇부터 시작해야 하는가?
나중에 사용할 공식 키트의 README는 아직 서브 에이전트가 없다면 하나의 루프(loop)부터 시작하라고 합니다. 원문은 "You have no subagents yet. Start with one loop."입니다. 시도해보고 필요하다고 알게 되었을 때, 툴과 스킬을 추가할 수 있다고 이어집니다.
반면에, 광범위하게 병렬로 조사하는 작업에는 분리하여 효과를 본 사례가 있습니다(질문 1).
차이점과 공통점
나열해 보면, 논쟁이라기보다는 작업의 형태에 대한 이야기로 보입니다. 광범위하게 병렬로 조사하는 작업은 분할해서 성공한 사례가 있고, 순차적으로 쌓아 올리는 작업은 분할하면 깨지기 쉽습니다.
일치하는 부분은 측정하여 결정한다는 점입니다(이 글의 정리입니다). 키트의 README도 "하나의 루프가 반드시 승리한다고 가정하지 않는다. 측량한다."라고 적고 있습니다("The kit does not assume a single loop always wins. It measures.").
원문 발췌 (전문가 의견)
Claude 블로그: "Outside these situations, the coordination costs typically exceed the benefits." (이러한 상황 외에서는, 협조 비용이 일반적으로 이점을 초과한다)
Claude 블로그: "Verification requires minimal context transfer by nature, so a verifier can blackbox-test a system without needing the full history of how it was built." (검증은 본질적으로 최소한의 컨텍스트 전송만 요구하므로, 검증자는 시스템이 어떻게 구축되었는지 전체 이력을 알 필요 없이 블랙박스 테스트를 할 수 있다)
공식 키트로 확인하기: 분리하고 비교하기
재료: 키트에 포함된 문의 창구
사용된 것은 Anthropic의 공식 single-agent-loop-kit입니다(Apache-2.0・SHA c437962). 기사의 부속품으로, 담당별로 목적지를 판정하는 감사 스킬이 포함되어 있습니다.
README는 자신을 '참조용 구현체이며 유지보수하지 않는다'고 적고 있습니다. 실제 모델로 예시를 구동한 것은 1명이 하나의 모델로 2회라는 내용도 있습니다.
키트에는 가상의 가전제품 매장 문의 창구 예시가 포함되어 있습니다. 분류 담당(router)이 1개와, 개별 담당자(agent)가 6개입니다. 평가 질문 19가지와 어떤 담당자가 어떤 순서로 움직였는지에 대한 기록(트레이스)도 함께 제공됩니다.
주문 + 배송 = 통합: 배송이 움직인 96건의 모든 기록에서, 배송은 주문 직후에 움직였습니다. 이는 배송 담당자가 주문에서 찾은 추적 번호가 필요하기 때문입니다.
반품/계정 = 축소: 정해진 절차와 몇 개의 API 호출만으로 세 가지 조건 중 어느 것에도 해당하지 않습니다.
불량 조사 = 도구로 호출: 한 번에 약 31,000 토큰(중앙값)을 읽고도 반환하는 것은 5문장 정도입니다. 900행의 로그 중에서 에러 행은 단지 5행뿐입니다. 메인 시스템이 읽으면 내용이 부풀려지기 때문에, 담당자에게 읽게 하고 결과만 받는 판정입니다. 다만 성능 저하 폭은 측정하지 않았습니다. 감사 자체도 '가장 확신하기 어려운 판정'이라고 적었으며, 로그를 좁힐 수 있는 도구가 있다면 축소하는 편이 좋다고 덧붙였습니다.
보험 청구 = 유지: 외부 보험 회사가 가진 담당자로, 고객과 여러 번 왕복하며 대화합니다. 세 가지 조건이 아니라, 고객과 직접 이야기하는지 여부가 기준입니다.
감사는 분류 담당(router)의 프롬프트에 있는 규칙 충돌도 발견했습니다.
router.md의 18행과 19행 발췌. 18행 ' - [shipping team] If the customer asks about delivery timing, route to shipping first.' 아래 번역 '도착 시기를 물으면, 배송을 먼저'. 19행 ' - [returns team] If the customer mentions a return, route to returns even if they also ask about something else.' 아래 번역 '반품이라고 하면, 다른 질문이 있어도 반품으로'. 아래에 태그 '조건3: 지시의 모순', '감사: 평가 문제 t11이 여기에 해당'
도착 시기와 반품을 동시에 물으면, 어느 것이 먼저인지 정해지지 않습니다. 조건 3의 '지시 모순' 실례입니다.
감사 후에는 반드시 멈추고, 'Are these verdicts right?' (이 판정이 맞나요?)라고 질문합니다. 근거 숫자가 나오기 때문에 사람이 수정할 수 있습니다.
동일한 19가지 질문으로 비교: 담당자 분리 버전에서 놓친 2가지
판정대로 재구성하면 정말 좋아질까요? 답을 읽기 전에 영상으로 보시려면, 실패한 답변부터 이음매에 빨간색이 생길 때까지의 7:05~입니다 →
두 버전을 Claude Code 위에 재구성하여 동일한 19가지 질문을 각각 두 번씩 풀게 했습니다(Sonnet).
분류 담당(router) + 6개 담당자를 .claude/agents/에 배치 (직접 사용하는 서브 에이전트와 동일한 메커니즘)
18/19
17/19
판정 기반 버전에서는 '도구로 호출'의 불량 조사를, 메인이 Claude Code의 서브 에이전트로 호출하여 결과만 받는 형태로 구성했습니다. '유지할' 보험 청구는 고객과 직접 대화하는 대신 메인이 답변을 중계하는 형태입니다.
19가지 질문에는 각각 합격 조건이 있습니다. 도착 날짜가 답변에 포함되었는지, 반품을 실제로 생성했는지 등입니다. 담당자 분리 버전에서 놓친 것은 다음 2가지였습니다.
1번째 질문(t01): '주문 5002의 상황은요?' 첫 번째는 통과했지만, 두 번째에서 실패했습니다. 두 번째 답변입니다.
안녕하세요 Ana! 주문 5002는 Vortex Blender이며, 이미 출하되었습니다. 추적 ID는 TRK-77002입니다. 배송 시기가 궁금하시면 제가 확인해 드릴 수 있습니다.
(출고되었으며, 추적 번호는 TRK-77002입니다. 도착 예정일이 알고 싶다면 조사하겠습니다.)
정답에 필요한 도착 예정일(10월 3일)이 포함되어 있지 않습니다. 기록으로 남아있는 것은 전화를 건 담당자의 수(이번에는 1개)뿐이며, 어떤 담당자였는지는 남아있지 않습니다. 주문과 배송의 경계 지점에서 실패한 것처럼 보이지만, 이는 읽기입니다.
2번째 질문(t11): '5002가 10월 2일까지 도착하지 않으면, 5001 케틀을 반품하고 싶어요' 두 번 모두 실패했습니다. 첫 번째 답변의 발췌 내용입니다.
주문 5002의 블렌더는 10월 2일까지 도착하지 않을 것이며, 케틀의 반품 기간은 이미 마감되었을 수 있습니다... 저는 아직 반품 절차를 시작하지 않았고, 기간 연장이나 예외 처리는 할 수 없습니다.
(블렌더는 10월 2일까지 도착하지 않습니다. 케틀의 반품 기한이 지났을 수도 있습니다. 반품은 아직 시작하지 않았습니다.)
정답은 반품 절차를 만드는 것입니다. 담당자 분할 버전에서는 두 번 모두 반품 절차를 만들지 못했습니다. 감사(Audit)가 't11이 충돌에 해당한다'고 지적했던 질문입니다. 다만, 단순히 충돌 때문이라고까지는 말할 수 없습니다. 확실하게 말할 수 있는 것은, 감사가 지적한 질문이었으며, 두 번 모두 반품 절차를 만들지 못했다는 사실뿐입니다.
접는 과정에서도 깨진다: Anthropic의 기사 샘플에서
그렇다면 하나로 합치면 문제가 없을까요? Anthropic의 기사 자체도 그와 반대되는 예를 제시하고 있습니다. 기사의 작성자들이 샘플 창구에서 시도했을 때, 담당자를 하나 다른 담당자로 접으면 대기 시간은 줄었습니다. 하지만 이전까지 통했던 처리가 깨졌습니다.
見出し「記事のサンプルの窓口・担当を畳んだ側で 同じ注文と配送の継ぎ目が壊れた」。原文 "The main agent was holding the order lookup tool and answering on its own, without asking the shipping specialist for the delivery date." と和訳「メインが注文の検索を持って自分で答え、配送の担当に到着日を聞かなかった」。原文 "run each task more than once, since a break like this one only showed up in one run out of two." と和訳「各問を2回以上走らせる。この壊れ方は2回に1回しか出なかった」
주문 검색은 메인으로 이동했지만, 배송은 여전히 다른 담당자였습니다. 경계 지점의 위치가 바뀌어도 주문과 배송 사이는 깨질 수 있습니다.
위와 같은 판단 버전은 주문과 배송을 모두 메인에 넣고 이 경계 지점 자체를 없앤 형태입니다. 기사는 재구성이 이루어지기 전에, 실제 운영되는 담당자 연결 고리마다 질문을 평가에 넣어두라고도 적고 있습니다.
그리고 이러한 깨짐 현상은 두 번 중 한 번만 나타났습니다. 위의 t01 역시 첫 번째는 통과했습니다. 기사가 '각 질문을 2회 이상 실행하라'고 쓰는 이유가 그대로 드러납니다.
전문가의 질문으로 돌아가서
실패했던 두 질문 모두 주문과 배송을 가로지르는 질문이었습니다. 이는 질문 2에서 언급된 '의존성이 높은 작업은 분리하는 데 적합하지 않다'는 형태를 지적합니다.
반면, Anthropic 기사의 샘플에서는 하나를 접은 후에도 같은 부분이 깨졌습니다. 나누느냐 합치느냐보다 먼저 경계 지점의 위치를 파악하고, 그곳을 평가에서 2회 이상 확인하는 것이 중요합니다. 이 예시를 통해 알 수 있는 것은 여기까지입니다.
자신의 에이전트에 적용하기: 만들기 전에 던져야 할 세 가지 질문
새로운 서브 에이전트를 만들기 전에 다음 세 가지를 자문해 보세요.
하나로 합쳤을 때 컨텍스트가 과부하되어 성능 저하가 측정되었는가 ('무거워 보인다'는 것은 제외)
병렬로 실행하여 끝난 후 폐기하는 작업인가 (광범위하게 조사하기, 깨끗한 시각으로 검증하기 등)
단일 에이전트로는 툴 선택이나 지시 사항의 모순을 해결할 수 없는가
위에 해당하지 않는다면 스킬(Skill)과 툴로 만들어 메인에 포함합니다. 고객과 직접 대화하는 담당만은 대화 단위 그대로 남겨둡니다.
이미 분리된 경우라면, 항상 연속적으로 작동하는 두 담당자를 찾아봅니다. 그곳이 경계 지점입니다. 이 경계 지점을 가로지르는 질문을 평가에 넣어 2회 이상 실행합니다.
직접 시도해 보기
키트 감사(Audit)를 자신의 리포지토리에 적용하기
README의 절차는 키트를 가져와 스킬을 배치하고 한 문장으로 요청하는 것만으로 충분합니다. .claude/skills/ 폴더가 아직 없는 리포지토리에서는 cp 명령어가 멈추므로, 먼저 만들어 두어야 합니다(이때 mkdir -p 명령어는 README에 없습니다).
README에 따르면, 이 스킬은 감사(audit) 이후, 비용이 발생하는 실행 전, 기준을 설정한 후에 변경될 때마다 멈춥니다.
키트는 무료입니다. 감사는 코드를 읽는 것만으로 가능하며 Claude Code의 세션 1회분 분량입니다. 평가를 진행하면 모델 요금이 발생하므로, 실행하기 전에 매번 토큰 견적을 제공합니다(README의 Cost 섹션 참고).
평가 없이도 약 10개의 질문에 대해 함께 초안 작성을 도와줍니다. 사용자가 직접 준비해야 할 것은 실제 환경 외에서 테스트로 구동하는 방법과 완료 조건을 설명할 수 있는 사람입니다.
키트 예시를 통해 API 키 없이 무료 체크도 가능합니다. 필요한 것은 Python 3.10 이상뿐이며, 다른 추가 설치물은 없습니다(키트의 RUNBOOK 참고).
cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smoke
1
2
3
질문마다 한 줄씩 총 19줄이 진행되며, 마지막 줄이 다음과 같으면 통과한 것입니다. 대리 모델(stand-in model)이기 때문에 점수는 부여되지 않습니다.
smoke: 19 tasks ran on the offline stand-in model, 0 harness errors. The plumbing works.
The stand-in follows keyword rules, so nothing here is scored. Set KIT_MODEL to a real model id for scores. Results in …
감사만으로 멈추도록, 한 문장 대신 다음의 문구로 요청했습니다. 단일 문장으로 요청했을 때 동일한 내용의 보고서가 나오는지 여부는 확인하지 못했습니다.
Use the single-agent-loop skill in .claude/skills/single-agent-loop on this repo.
The system to migrate is in app/. Traces are in traces/traces.jsonl.
Stop at every check-in the skill describes. Run step 0, the audit, and check in with the verdicts. Do not run any eval (no paid or offline eval runs, no run_eval.py) and do not proceed past the audit check-in. Print the full check-in as your final answer.
1
2
3
4
19개 질문 비교 구성 방법
키트 본래의 비교 방식은 SDK로 구성된 버전을 evals/run_eval.py에서 채점하는 형태입니다(examples/support-desk/RUNBOOK.md). 위 숫자는 이 방식으로 진행하지 않았습니다. 대신, 창구 역할을 Claude Code 위에 재구성했습니다.
| 항목 | 담당 분배 버전 (Role division version) | 판정 따르기 버전 (Judgment-following version) |
|---|---|
| 메인 | 역할 분담자 (스스로는 답변하지 않음) | 창구 역할 (주문과 배송은 스스로 답변함) |
| 담당 | .claude/agents/에 6개 담당자 배치 | .claude/agents/에 결함 조사 및 보험 청구, .claude/skills/에 반품・계정 관리 |
두 버전 공통: 키트의 API는 Bash에서 호출하는 명령어로 대체했습니다. 보험 청구는 두 버전 모두 중개(중계) 형태입니다.
환경: Claude Code 2.1.310 비대화 모드 · Sonnet 5.5 · 2026-10-26~27
채점: 키트의 19개 질문 합격 조건과 채점 처리를 그대로 사용했습니다. 질문마다 새로운 세션을 진행했습니다.
![router.md의 18행과 19행 발췌. 18행 ' - [shipping team] If the customer asks about delivery timing, route to shipping first.' 아래 번역 '도착 시기를 물으면, 배송을 먼저'. 19행 ' - [returns team] If the customer mentions a return, route to returns even if they also ask about something else.' 아래 번역 '반품이라고 하면, 다른 질문이 있어도 반품으로'. 아래에 태그 '조건3: 지시의 모순', '감사: 평가 문제 t11이 여기에 해당'](https://static.zenn.studio/user-upload/deployed-images/800057386bedb26da0a214d7.png?sha=de3d70453fdb56aa33e0ac71eee80d59f4ef892d)
