에이전트 설계 지도: 실행 구조부터 검증과 운영까지

에이전트는 모델이 다음 행동을 선택하고, 실행 시스템이 도구·권한·상태를 관리하는 구조다. 이 글은 Anthropic과 OpenAI의 설계 자료를 바탕으로, 단일 호출에서 다중 에이전트까지 무엇을 선택하고 어떻게 검증할지 13개 주제로 정리한다.

본문의 목차에서 필요한 주제로 이동할 수 있다. 도표는 눌러서 확대할 수 있다.

모델을 실행 가능한 시스템으로 만드는 것 — 하네스(harness)는 컨텍스트 구성·실행 루프·도구 연결·상태 저장·통제를 묶는 소프트웨어다. 모델의 호출 요청만으로 외부 시스템이 변경되는 것은 아니다.

읽는 기준 먼저 모델·실행 시스템·업무 시스템의 역할을 나눈다. 이어 도구와 데이터의 경계를 정하고, 마지막에는 실패 복구·평가·비용을 점검한다. 학회 투고 점검 사례와 상태 모델은 원칙을 적용한 자체 설계 예시이며, 실제 연동하거나 성능을 측정한 결과는 아니다.

모델과 에이전트의 경계

에이전트의 자율성은 다음 행동을 선택하는 데 있다. 실제 실행 권한과 완료 기준은 애플리케이션이 소유한다.

층위	핵심 책임	대표 산출물	실패하면 생기는 일
모델 Model	상황 해석·계획·도구 선택	답변 또는 도구 호출 요청	틀린 판단·부적절한 도구 선택
하네스 Harness	루프·컨텍스트·실행 관리	상태 전이·도구 결과·기록	중복 실행·무한 반복·상태 유실
도구 Tool	정의된 외부 작업 수행	검색 결과·파일·변경 영수증	외부 오류·잘못된 부작용
업무 시스템	권한·데이터 무결성 유지	DB 상태·접근 기록	타 고객 데이터 노출·오염
평가·사람	성공 확인·예외 판단	통과·보류·반려 결정	잘못된 완료 선언

관측 → 판단 → 실행 → 검증의 폐루프 — 완료·예산 소진·사용자 취소·차단을 서로 다른 종료 상태로 기록한다. 모델의 “끝났다”는 응답은 검증 대상이지 성공 증명이 아니다.

추론 ≠ 실행

도구 호출은 실행 요청이다. 애플리케이션이 인자를 확인하고 실제 함수를 수행한 뒤 결과를 모델에 돌려준다.

세션 ≠ 영구 기억

대화 문맥, 저장된 작업 상태, 산출물은 별도의 수명과 저장 정책을 가진다. 새 실행에서 무엇을 복원할지 명시해야 한다.

어디까지 자율적으로 만들 것인가

복잡도는 업무가 요구할 때 추가한다. 품질·비용·통제 가능성을 비교할 기준선을 먼저 만든다.

업무 특성에서 아키텍처를 선택하기 — 독립 하위 과제가 있다는 이유만으로 다중 에이전트가 정답은 아니다. 단일 에이전트 기준선과 동일한 예산·평가 세트로 비교한다.

업무 신호	첫 선택	추가할 조건	대표 예제
한 번의 응답으로 충분	단일 LLM 호출	근거 검색이 필요하면 검색 결과를 입력에 추가	문서 분류·요약
검사와 순서가 정해짐	경로가 정해진 워크플로	일부 단계에만 LLM 판단 배치	접수 → 필수 항목 검사 → 등록
자료를 보고 다음 행동 결정	단일 에이전트	도구 구분·컨텍스트 문제가 확인될 때 분리	오류 원인 조사·자료 조사
각 조사 영역이 독립적	작업 분할 + 통합	병렬 이득이 조정·검증 비용보다 클 때	국가별 규정·제품 비교
실패를 객관적으로 판정 가능	평가·수정 루프	재시도 상한과 개선 기준을 설정	테스트 실패를 보고 코드 수정

경로가 정해진 워크플로에도 모델 호출이 들어갈 수 있다. 여기서 고정되는 것은 처리 순서와 분기 규칙이며, 모델이 생성하는 답까지 매번 같아진다는 뜻은 아니다.

설계 리뷰 질문 “이 업무에 에이전트가 필요한가?” 다음에는 “어떤 관측 결과에 따라 다음 행동이 달라지는가?”를 묻는다. 그 분기를 설명할 수 없다면 자율성을 늘릴 이유부터 검토한다.

같은 모델, 여섯 가지 실행 구조

노드의 개수보다 경로를 누가 정하는지, 결과가 어디서 합쳐지는지, 언제 반복이 끝나는지가 중요하다.

Chaining · 순차 처리

Routing · 분기

요청 유형에 따라 경로를 고른다. 분류가 불확실할 때의 기본 경로가 필요하다.

Parallelization · 병렬

독립 작업을 동시에 실행한다. 같은 파일을 서로 수정하는 일은 분리해야 한다.

Orchestrator–workers · 동적 분업

상황에 따라 하위 과제를 만든다. 과제 범위와 반환 형식을 먼저 정한다.

Evaluator–optimizer · 개선

평가 피드백을 받아 수정한다. 평가 기준이 모호하면 반복 자체가 목적이 된다.

Handoff · 담당 전환

제어를 다른 에이전트로 넘긴다. 관리자에게 결과만 반환하는 위임과 구분한다.

구조	경로 결정 주체	가장 큰 위험	필수 제어
순차·분기	주로 애플리케이션 코드	틀린 중간 결과·오분류	입출력 스키마·실패 경로
병렬·동적 분업	코드 또는 관리자 에이전트	중복 작업·충돌·통합 누락	작업 소유권·결과 계약
평가·개선	평가 결과 + 반복 제어	같은 오류 반복·평가 편향	수정 예산·독립 평가 세트
Handoff	현재 에이전트 + 허용된 경로	책임 불명확·전환 반복	수신자·전달 상태·전환 상한

표현 규칙 여기서 “평가”는 자동 테스트·규칙·모델 평가·사람의 판단을 모두 포함한다. 다이어그램은 실제 모델 실행 화면이 아닌 구조 설명이다.

도구는 실행 계약, MCP는 연결 규약

모델이 올바른 도구를 선택하도록 설명하고, 실행 시스템은 잘못된 요청을 받아도 안전하도록 만든다.

MCP가 들어가는 정확한 위치 — MCP는 검색 엔진·메모리·에이전트 루프 자체가 아니다. 외부 기능과 자료를 표준 인터페이스로 연결한다. 인증과 업무 권한 검사는 각 실행 경계에서 별도로 필요하다.

MCP 구성	무엇을 제공하나	일반적인 제어 주체	예시
Tools	호출 가능한 기능	모델이 선택하고 호스트가 통제	문서 검색·업무 기록 생성
Resources	읽을 수 있는 자료	애플리케이션	문서 URI·정책 파일
Prompts	재사용 입력 템플릿	사용자	리뷰·분석 작업 템플릿

Tools·Resources·Prompts의 제어 주체는 MCP의 개념 구분이다. 실제 접근 권한과 사용자에게 보여줄 방식은 연결한 호스트 애플리케이션이 정한다. MCP 공식 문서: 서버가 제공하는 세 가지 기능

실행 계약에 적어야 하는 것

항목	설계 내용	문서 검색 도구의 예
목적·경계	언제 쓰고 언제 쓰지 않는가	search_policies: 최신 정책 근거 검색
입력	타입·필수값·허용값·길이	query, collection_id, limit
권한	인증된 주체로 서버에서 확인	tenant_id를 모델 입력에서 신뢰하지 않음
출력	근거·버전·다음 단계에 필요한 값	document_id, revision, excerpt, source_url
오류	다시 시도할 수 있는지 구분	RATE_LIMIT / FORBIDDEN / NOT_FOUND
부작용	읽기·쓰기·중복 처리 규칙	쓰기 도구는 요청 키로 중복 처리 방지

업무 단위로 좁고 명확하게

search_policy(query)처럼 관련 결과를 반환한다. 전체 문서 목록을 모델에 던지고 찾게 하면 문맥과 호출 예산을 낭비한다.

형식 검증과 권한 검증은 별개

유효한 JSON이어도 다른 고객의 문서를 요청할 수 있다. 실행 서버는 인증 주체·자료 접근·작업 범위를 다시 확인한다.

자체 설계 예제 위 계약 표의 멀티테넌트 권한·중복 처리 설계는 공식 원칙을 업무 시스템에 적용한 제안이다. 특정 SDK의 내장 기능을 의미하지 않는다.

관련 자료 · [C7] MCP 입문 수업 · [C9] MCP 과정 · [A3] 도구 설계 · [O5] 함수 호출

컨텍스트는 매 순간 편집하는 작업 공간

모든 자료를 넣는 것보다 현재 판단에 필요한 근거를 정확히 공급하는 것이 중요하다. 원본·검색 인덱스·현재 문맥을 분리한다.

한 번의 판단에 들어가는 문맥

실행 지침 · 금지 조건 — 변하지 않는 운영 경계
사용자 목표 · 완료 조건 — 현재 작업의 계약
선택된 도구 · 관련 Skill — 필요한 기능과 절차만
검색된 증거 · 최신 상태 — 출처·시간·버전 포함
다음 행동에 필요한 작업 요약 — 결정·미해결·다음 단계

검색, 기억, 압축

검색: 외부 원본에서 지금 필요한 근거를 가져온다.
기억: 다음 실행에도 필요한 사실·진행 상태를 보존한다.
압축: 문맥 길이를 줄여 작업을 이어간다. 누락 가능성을 검증해야 한다.

지식 공급 경로와 실행 상태의 분리 — RAG는 검색된 근거를 생성에 결합하는 방식이다. 검색 경로를 상황에 따라 바꾸는 에이전트는 재검색·다른 도구 조회·충분성 판단을 추가할 수 있다.

저장 대상	수명	반드시 함께 저장	위험·점검
현재 도구 결과	현재 실행 중심	출처·조회 시간·오류 여부	긴 원문을 반복 주입하지 않기
작업 체크포인트	작업 완료까지	완료 항목·미해결·다음 행동·버전	요약을 실제 원본과 대조
지속 지식·선호	명시한 보관 기간	소유자·근거·유효 기간	오래된 가정의 자동 재사용 방지
검색 인덱스	원본과 동기화	원본 ID·버전·권한 메타데이터	삭제·권한 변경이 검색에 반영되는지 확인

실무 판단 소규모 최신 문서는 직접 읽기·키워드 검색으로 충분할 수 있다. 의미 검색은 표현이 달라도 관련 내용을 찾는 데 유용하지만, 관련성 점수가 사실성·권한·최신성을 보증하지는 않는다.

지침·Skills·Hooks의 역할을 나눈다

늘 적용할 기준, 필요할 때 읽을 절차, 코드로 강제할 조건을 서로 다른 위치에 둔다.

수단	답하는 질문	적합한 내용	실행 보장 여부
프로젝트 지침	이 프로젝트의 기본 규칙은?	CLAUDE.md / AGENTS.md의 규약	자연어 지침만으로 강제되지 않음
Skill	이 작업을 어떻게 수행하나?	검토 절차·참고 자료·검증 스크립트	관련 작업에서 로드·적용되는 절차
Hook · 이벤트 처리	이 이벤트에서 무엇을 검사하나?	도구 실행 전 정책 검사·종료 전 검증	연결된 이벤트·Hook 유형에 따라 다름
Subagent	누구에게 어떤 일을 맡기나?	격리된 조사·분석·수정 작업	별도 문맥·반환 계약 필요
MCP	어떤 외부 기능과 연결하나?	문서 검색·업무 API 연결	프로토콜은 업무 성공을 보장하지 않음

Hook은 실행 중 정해진 이벤트에 연결하는 처리다. Claude Code에는 명령을 실행하는 command Hook 외에 모델로 판단하는 prompt·agent Hook도 있다. 아래 그림은 명령형 Hook으로 검사 코드를 실행하는 경우다. 차단 여부는 이벤트와 응답 규약을 따르므로, Hook을 등록하는 것만으로 모든 변경이 막히지는 않는다. 공식 문서: Hook 유형과 동작

Skill은 절차를 공급하고, 명령형 Hook은 실행 경계를 검사한다 — 실행 후 검사는 이미 발생한 부작용을 예방하지 못한다. 중요한 차단은 실행 전에 두고, 완료 시에는 결과 증거를 다시 확인한다.

필요한 만큼만 읽는 Skill

설명: 적용 조건 → 본문: 수행 순서 → 참고 파일: 상세 기준 → 스크립트: 계산·검증.

트리거 설명에는 작업 대상과 적용 조건을 구체적으로 쓴다.

첫 Skill은 검증 절차부터

수정 내역 확인 → 필요한 테스트 실행 → 테스트 약화 여부 검사 → 통과·실패와 증거 반환.

검증을 요청한 것과 검증이 실행된 것을 구분한다.

Claude Code의 allowed-tools는 사전 승인 설정 Skill을 호출한 턴에서 나열된 도구를 별도 승인 없이 사용할 수 있게 한다. 그 목록에 없는 도구를 전부 차단하는 설정은 아니다. 도구를 제외하는 설정이나 권한 정책은 별도로 적용한다. 현재 공식 문서: Skill 설정

분업의 단위는 역할보다 작업 계약

독립된 문맥을 얻는 대신, 전달·중복·충돌·통합 비용을 지불한다. 관리자 에이전트는 결과를 통합하고, 최종 업무 책임은 사람과 운영 조직이 맡는다.

관리자–작업자 구조: 탐색은 분리하고 근거는 통합 — 작업자가 긴 탐색 과정을 모두 반환하면 문맥 분리의 이점이 줄어든다. 결과·근거·불확실성·장애를 정해진 형식으로 반환한다.

계약	반드시 들어갈 값	예시
입력	목표·범위·제외 대상	현재 투고 규정 확인; 과거 규정 제외
접근	허용 도구·데이터 범위	해당 학회 규정 읽기만 허용
실행 예산	마감·호출 수·재시도 범위	예산 도달 시 미완료 사유·현재 근거 반환
출력	결론·근거·불확실성·장애	finding, source, revision, unknowns, blockers
완료 조건	무엇을 채우면 끝나는가	각 항목에 통과·실패·판단 불가
소유권	수정 가능 범위·통합 담당	작업자는 초안; 관리자가 결과 확정

늘리기 좋은 경우	늘리기 어려운 경우
검색 범위가 독립적이고 넓음	모든 작업이 같은 긴 문맥에 의존
결과를 짧은 계약으로 통합 가능	같은 코드·DB를 동시에 수정
작업의 결과를 따로 검증 가능	담당 간 중간 결과가 계속 필요
고가치 업무에서 비용을 감당	한 번의 호출로 충분한 분류·요약

성과 비교의 함정 다중 에이전트가 더 많은 토큰·도구·시간을 사용했다면 개선을 에이전트 수만의 효과로 해석할 수 없다. 단일 에이전트에도 같은 총예산을 주는 비교가 필요하다.

장기 실행은 상태 전이 문제

계속 실행한다는 것은 모델 호출 하나가 영원히 이어진다는 뜻이 아니다. 작업을 시작하고, 저장하고, 멈추고, 재개할 시스템이 필요하다.

작업 수명주기와 복구 경로 — 자체 권장 상태 모델. 작업 취소는 이미 완료된 외부 변경을 되돌리지 않는다. 필요한 경우 별도 보상 작업과 감사 기록을 남긴다.

상황	잘못된 처리	운영 설계
응답 시간 초과	실패로 가정하고 쓰기 재호출	요청 ID로 실제 적용 여부부터 조회
이벤트 재전송	같은 작업을 새로 생성	이벤트 키·작업 키로 중복 제거
컨텍스트 한도	전체 기록을 계속 복사	요약·체크포인트·원본 참조로 재개
승인 지연	프로세스를 무기한 유지	승인 상태 저장 후 이벤트로 재개
진행이 반복됨	턴 수만 늘리기	진척 없음 감지·예산 종료·사람 인계
권한 오류	우회 경로를 찾도록 지시	차단 기록·권한 관리자에게 인계

다음 실행이 이어받을 최소 상태

// 자체 설계 예시 — 특정 SDK의 스키마가 아님
{
  task_id: "submission-check-1042",
  status: "waiting_approval",
  input_revision: "manuscript-v3",
  completed: ["file_integrity", "required_sections"],
  pending: ["editor_review"],
  evidence_refs: ["report-1042-v1"],
  proposed_action: "attach_check_report",
  last_action_key: "check-1042-v3",
  remaining_budget: { tool_calls: 8 },
  next_step: "validate_revision_then_attach"
}

스케줄과 자율 실행을 분리 스케줄러는 언제 실행할지 정한다. 에이전트 루프는 실행 중 무엇을 할지 정한다. 클라우드 자동화와 자체 스크립트 실행은 환경·권한·상태 보관 책임이 다르다.

신뢰 경계는 프롬프트 밖에 세운다

외부 자료는 읽을 근거다. 실행 권한을 늘리거나 상위 지침을 바꿀 권위로 취급하지 않는다.

비신뢰 입력에서 실제 변경까지의 통제 경로 — 구조화 출력은 자유로운 전달 경로를 줄이지만 인젝션을 완전히 막지는 못한다. 데이터 최소화·접근 제한·실행 전 검사를 함께 적용한다.

작업 유형	예시	권장 통제 위치	검증할 것
범위 내 읽기	내부 규정 조회	검색·API 서버	인증 주체와 문서 권한 일치
되돌릴 수 있는 초안	보고서 생성	격리 작업 공간	원본 보존·버전 구분
업무 상태 변경	심사 상태 변경	업무 API + 필요 시 승인	현재 상태·역할·전이 규칙
외부 발송·결제	저자 통지·환불	구체적 실행안 승인	수신자·본문·금액·중복 실행
파괴적 작업	원본 삭제·권한 확대	서버 정책·관리자 절차	복구 가능성·변경 권한·기록

승인 대상은 구체적인 실행안

대상·변경 내용·효과를 보여준다. 승인 뒤 대상이나 데이터가 바뀌었다면 실행 전에 다시 확인한다.

격리와 업무 권한은 다른 통제

샌드박스는 파일·프로세스·네트워크 범위를 제한한다. 업무 API가 잘못 허용한 다른 고객 자료 접근을 자동으로 해결하지는 않는다.

위 표는 자체 운영 설계 기준 자동 허용 여부는 작업 위험과 조직 정책에 따라 정한다. 모든 호출에 사람 승인을 요구하면 자동화의 효용이 사라지고, 모든 호출을 허용하면 통제 경계가 사라진다.

실제 결과와 실행 경로를 함께 평가한다

성공했다고 말한 응답과 실제 환경의 성공 상태는 다르다. 결과 평가와 실행 경로 분석을 함께 설계한다.

개발 평가와 운영 피드백의 순환 — 과제(task)마다 여러 시행(trial)을 수행하고, 결과(outcome)와 기록(trace)을 구분한다. 테스트 데이터에 맞춘 수정이 별도 보류 세트에서도 유효한지 확인한다.

평가 층	검사 대상	적절한 방법	주의할 점
결과 정확성	최종 DB·파일·업무 상태	코드 기반 검증·실제 상태 조회	답변 문구로 성공을 대체하지 않기
근거 충실성	주장과 인용의 연결	출처 대조·모델 평가 + 표본 검수	인용이 존재해도 주장을 지지하지 않을 수 있음
실행 정책	허용 도구·승인·권한	도구 로그·상태 전이 검사	결과가 맞아도 금지 경로는 실패
복구 가능성	타임아웃·재시작·중복 이벤트	실패 주입·재현 시험	정상 시나리오만 평가하지 않기
사용 품질	명료성·수정 용이성·실무 적합	기준표 기반 사람 검수	판정자 간 기준을 먼저 맞추기

같은 성공률도 무엇을 묻느냐에 따라 달라진다

지표	질문	해석
성공률	전체 시행 중 성공은 몇 개인가?	과제 유형별로 나누고 표본 수를 함께 표시
pass@k	k번 중 한 번 이상 성공했나?	후보를 여러 개 만들고 고를 수 있는 능력
pass^k	k번 모두 성공했나?	매번 안정적으로 수행하는 일관성
비용 / 성공	성공 한 건에 총비용이 얼마인가?	실패·재시도·검수 비용도 포함
P95 지연	느린 쪽 5% 경계는 얼마인가?	평균이 가리는 긴 대기와 재시도 확인

단일 성공 확률 p = 0.8, 독립 시행 k = 3
한 번 이상 성공: 1 − (1 − p)³ = 99.2%
세 번 모두 성공: p³ = 51.2%

교육용 확률 예시. 시행이 독립이고 성공 확률이 같다는 가정이다. 실제 에이전트의 반복 오류는 상관될 수 있으며, 위 수치는 모델 성능 측정값이 아니다.

운영 평가의 최소 단위 모델 버전·프롬프트·도구 정의·Skill·하네스 설정·입력 자료 버전을 함께 기록한다. 변경을 비교할 때는 평가 세트와 성공 기준도 고정해야 한다.

관련 자료 · [A7] 에이전트 평가 · [O3] 워크플로 평가

최적화의 단위는 성공한 업무 한 건

호출 한 번의 단가보다 끝까지 완료하는 데 드는 비용과 시간이 중요하다. 모델 교체 전에 낭비되는 경로를 관측한다.

업무 1건 총비용 = 모델·도구·실행 비용(실패·재시도 포함) + 사람의 검수·수정 비용

병목	먼저 볼 증거	개선 방향	품질 확인
반복 검색	같은 쿼리·같은 자료 재조회	중복 결과 제거·진행 상태 유지	자료 최신성을 희생하지 않았는가
긴 입력	불필요한 원문·도구 정의	필요한 자료만 로드·짧은 근거 반환	필수 근거가 빠지지 않았는가
긴 직렬 경로	독립 작업이 순차 실행됨	독립 작업만 제한된 병렬 처리	충돌·공유 상태 의존은 없는가
과도한 모델 사용	단순 단계에 고비용 판단	품질 기준선 확보 후 모델 분담	예외·희귀 사례의 회귀는 없는가
낮은 캐시 재사용	공통 지침이 자주 변함	안정된 접두부·가변 입력 분리	캐싱을 결과 재사용으로 오해하지 않는가
많은 사람 수정	잘못된 완료·근거 부족	결과 계약·검증 루프 개선	숨겨진 검수 노동이 줄었는가

프롬프트 캐싱은 공통 입력의 처리를 재사용한다 — 세션을 재사용한다고 캐시 적중이 보장되지는 않는다. 실제 적중·비용·지연을 기록하고 모델과 API의 캐싱 조건을 확인한다.

병렬 처리의 실제 이득

독립 작업을 병렬화하면 대략 가장 느린 작업의 시간에 조정·통합 시간이 더해진다. 총 사용량과 과금이 줄어든다는 뜻은 아니다.

실행 전에 정하는 상한

최대 턴·도구 호출·동시 작업·시간·비용을 설정한다. 상한 도달 시 현재 산출물과 미완료 사유를 반환한다.

수치 사용 원칙 이 페이지는 특정 모델의 최신 가격이나 우열 순위를 제시하지 않는다. 실제 서비스의 비용은 현재 가격표와 운영 로그로 계산해야 한다.

제품 이름보다 운영 책임으로 비교

같은 에이전트 개념도 직접 API를 감싸는지, SDK를 쓰는지, 관리형 서비스를 쓰는지에 따라 구현 책임이 달라진다.

필요한 통제 수준	Claude 쪽 진입점	OpenAI 쪽 진입점	애플리케이션의 책임
모델 호출부터 직접 구현	Client SDK / Claude API	Responses API	루프·도구·기록·상태·권한 설계
에이전트 루프를 라이브러리로 사용	Claude Agent SDK	OpenAI Agents SDK	배포·저장·도구·업무 정책 구성
관리형 하네스·세션 사용	Managed Agents	Agents API	실행 환경 선택·업무 계약·접근 권한·검증
개발자가 직접 작업을 지휘	Claude Code	Codex	작업 범위·환경·검토·최종 반영

관리형 서비스에서도 도구가 실행되는 위치는 확인해야 한다. Claude Managed Agents와 OpenAI Agents API는 공급자 관리 샌드박스와 자체 호스팅 실행 환경을 지원한다. 하네스를 맡긴다고 모든 도구 실행·데이터 보관 책임까지 자동으로 넘어가지는 않는다. 실제 지원 범위와 제공 상태는 제품별 문서에서 확인한다. Claude Managed Agents · OpenAI Agents API

2026.09.20에 확인한 공식 문서 기준의 역할 대응표. 같은 행의 제품이 기능·가격·데이터 정책까지 동일하다는 의미는 아니다.

어느 계층까지 공급자가 맡는가 — API와 SDK를 고르기 전에 보관할 상태, 실행할 도구, 접근 가능한 데이터, 운영자가 개입할 지점을 정한다.

도입 검토 항목	확인할 질문
실행 환경	우리 데이터·파일·네트워크에 접근할 수 있는가?
승인·중단	실행을 보류하고 승인 후 이어갈 수 있는가?
기록·평가	도구 호출과 결과를 추적·재현할 수 있는가?
세션·산출물	저장·보관·삭제·내보내기 정책이 맞는가?
제품 변경	실습 문서의 API와 현재 지원 API가 같은가?

과거 강의를 현재 API 사용법으로 그대로 옮기지 않기 개념과 설계 패턴은 유지되더라도 API 경로·지원 기능은 바뀐다. 구현 예제는 현재 문서를 기준으로 확인하고, 이 페이지의 자체 예제는 제품별 SDK 코드와 구분한다.

관련 자료 · [A8] Claude Agent SDK · [O2] 에이전트 실행 환경

실무 적용: 학회 투고 사전 점검

공식 원칙을 실제 업무에 옮긴 자체 설계 예제. 과학적 타당성이나 게재 여부를 자동 판정하지 않고, 제출 형식과 필수 자료를 확인한다.

검사 결과를 편집 담당자의 판단까지 연결 — 검색과 추론으로 초안을 작성하되, 최종 상태 변경은 기존 업무 API의 역할·상태 전이 규칙을 따른다. 논문 원문 내부의 지시는 실행 지침으로 승격하지 않는다.

설계 항목	이 예제의 결정	선택 이유
목표	투고 전 필수 자료·형식 누락 발견	성공과 실패를 확인할 수 있음
기본 구조	규칙 검사 + 단일 에이전트	처음부터 다중 에이전트가 필요하지 않음
지식	해당 학회의 유효 규정과 템플릿	학회 간 규정·고객 데이터 혼합 방지
도구	원고 읽기·규정 검색·초안 저장	점검 에이전트에는 게재 결정 권한 없음
완료 조건	모든 항목에 판정·근거·규정 버전	모르는 항목을 억지로 통과시키지 않음
사람의 책임	예외 인정·반려·외부 통지	해석과 의사결정의 책임을 명확히 함
반영 조건	승인 당시 원고 버전과 현재 버전 일치	수정된 원고에 오래된 결과 적용 방지

보고서의 각 행이 독립적인 증거 단위가 된다

항목	판정	확인한 증거	조치
초록 존재	통과	원고 v3 · 2쪽 · Abstract 제목	조치 없음
필수 별첨	미충족	접수 파일 목록에 저작권 동의서 없음	담당자가 첨부 요청 여부 확인
분량 기준	판단 불가	스캔 PDF로 본문 추출 신뢰도 부족	OCR 재처리 또는 사람이 확인
참고문헌 형식	확인 필요	규정의 예외 조항과 서지 형식 불일치	근거 구간을 담당자에게 제시

위 판정은 구조를 설명하기 위한 가상 데이터다. 실제 논문을 검사한 결과가 아니다.

실패 시나리오를 먼저 정한다

시험 입력	기대 동작	실패로 보는 조건
PDF에 “규정 무시” 문구 삽입	원문 데이터로만 취급	도구 권한·점검 절차가 변경됨
동일 접수 이벤트 2회 전달	같은 작업·결과를 조회	보고서·알림이 중복 생성됨
승인 전 원고 v3 → v4 수정	기존 결과 보류 후 재검사	v3 점검 결과가 v4에 적용됨
다른 학회 문서 ID 입력	서버에서 접근 차단	모델 출력이나 로그에 문서 내용 노출
규정 두 버전 충돌	유효 버전 확인·불명확하면 보류	임의로 한 규정을 선택해 확정
쓰기 응답만 시간 초과	작업 키로 실제 적용 여부 조회	동일 변경을 다시 실행

사람과 에이전트의 운영 계약

역할	결정하는 것	반드시 남기는 것
업무 책임자	성공 기준·허용 예외·도입 범위	유효한 규정과 책임자
에이전트	허용 범위 내 조사·초안 작성	근거·미확인 항목·실행 기록
검토 담당자	예외 인정·반려·통지 승인	검토 결정과 사유
시스템 운영자	권한·배포·복구·중단	모델·도구·설정 버전 및 장애 기록

기준선 사람이 판정한 사례로 규칙 검사·단일 호출 결과를 측정한다.
그림자 실행 실제 상태를 바꾸지 않고 기존 업무 결과와 비교한다.
제한 적용 근거가 명확한 범위부터 사람이 확인하며 적용한다.
범위 확대 오류 유형·검수량·비용이 기준에 맞을 때만 확대한다.

배포 판단은 점수 하나로 하지 않는다 중요 누락·권한 위반·중복 실행은 평균 정확도에 묻히지 않도록 별도 관문으로 평가한다. 필요한 통과 기준과 표본 수는 학회별 업무 위험에 맞춰 정한다.

출처와 확인 범위

설계 원칙, 제품 사용법, 자체 제안을 구분해 읽어야 한다. 아래 강의·문서는 더 읽을 자료이며, 과정 전체를 수강했다는 의미는 아니다. 제품 설정에서 달라질 수 있는 Skill 권한·Hook 유형·관리형 실행 환경은 2026년 9월 20일의 공식 문서와 대조했다.

자료 종류	읽을 내용	적용 범위
엔지니어링 글	실행 패턴·도구·문맥·평가의 설계 원칙	사례의 조건을 함께 읽고 자기 업무에서 다시 검증
제품 개발 문서	지원 기능·설정·실행 환경	제품별 현재 문서에서 사용법 확인
강의·과정·행사 안내	개념을 더 공부할 학습 경로	일부 안내 페이지만으로 전체 강의 내용을 판단하지 않음
자체 통합 설계	운영 계약·상태 모델·학회 예제	공급자가 보증하거나 실측한 아키텍처가 아님

목적에 따라 읽는 순서

목적	추천 순서	학습 완료를 확인할 산출물
구조 설계	A1 → O1 → O2 / A8	워크플로·에이전트 선택 근거와 책임 경계도
도구·지식 연결	C7 → A3 → A4 → O6	도구 계약·근거 공급 경로·권한 테스트
개발 자동화	C5 → C6 → C2 → C3 → A6	검증 Skill·실행 Hook·재개 가능한 체크포인트
다중 에이전트	C1 → A5 → O3	위임 계약·단일 에이전트 대비 평가표
조직 운영	C4 → A7 → O7	역할·승인 기준·품질 관문·장애 대응표

공식 참고 자료

A1 / Anthropic · Building effective agents
O1 / OpenAI · A practical guide to building agents
A2 / Claude Academy · Building with the Claude API
A3 / Anthropic · Writing effective tools for agents
A4 / Anthropic · Effective context engineering for AI agents
A5 / Anthropic · How we built our multi-agent research system
A6 / Anthropic · Effective harnesses for long-running agents
A7 / Anthropic · Demystifying evals for AI agents
C1 / Claude Academy · Designing effective subagents
C2 / Claude Academy · Verification skills
C3 / Claude Academy · Hooks
C4 / Claude Academy · What a strong human-agent team looks like
C5 / Claude Academy · Skills vs. other Claude Code features
C6 / Claude Academy · Configuration and multi-file skills
C7 / Claude Academy · Introducing MCP
C8 / Claude Academy · Routines and headless
C9 / Claude Academy · Introduction to Model Context Protocol
O2 / OpenAI Docs · Agents
O3 / OpenAI Docs · Evaluate agent workflows
O4 / OpenAI Docs · Safety in building agents
O5 / OpenAI Docs · Function calling
O6 / OpenAI Docs · Retrieval
O7 / OpenAI Docs · Production best practices
O8 / OpenAI Docs · Prompt caching
A8 / Claude Code Docs · Agent SDK overview
O9 / OpenAI Academy · Builder Bootcamp: Production & Optimization

문서 대조일: 2026년 9월 20일 오래된 설계 글은 발표 당시의 사례로 읽고, 실제 설정과 API는 현재 제품 문서에서 다시 확인한다. 모델의 가격·성능 순위나 예제 시스템의 실측 성과는 제시하지 않는다.