Phase 1515-4

에이전트 엔지니어링 — 누구에게 맡길 것인가

AI 활용의 4단계, 에이전트 엔지니어링을 배웁니다. 도구 표면 설계, 작성자와 검증자를 분리하는 서브에이전트, 그리고 서버가 알아서 돌리는 Managed Agents까지 — AI에게 일을 '맡기는' 기술을 노무 업무에 적용합니다.

Execution Kit

실습 중 막히지 않기 위한 진행표

Phase 15

준비

강의 전 현재 폴더, 계정, 설치 상태를 확인합니다.

실행

에이전트 엔지니어링은 일하는 주체(스스로 계획·도구사용·검증·반복하는 AI) 자체를 설계하는 기술로, '대화'에서 '위임'으로의 도약입니다.

검증

명령 결과, 파일 변화, 브라우저 화면 중 하나로 성공 여부를 확인합니다.

기록

잘 된 명령과 막힌 지점을 다음 실습을 위한 로그로 남깁니다.

막혔을 때 Claude Code에 붙여넣을 양식

나는 코딩 경험이 많지 않은 실무자입니다. "에이전트 엔지니어링 — 누구에게 맡길 것인가" 강의를 따라 하고 있습니다.

현재 상태:
- 사용하는 컴퓨터:
- 방금 실행한 명령:
- 화면에 나온 결과 또는 오류:
- 내가 만들고 싶은 업무 결과물:

요청:
1. 지금 상황을 초보자 기준으로 진단해줘.
2. 다음에 실행할 명령을 한 줄씩 제시해줘.
3. 각 명령이 무엇을 하는지 쉬운 말로 설명해줘.
4. 성공 여부를 확인할 체크 포인트를 정리해줘.
5. 실패하면 다시 붙여넣을 오류 보고 양식을 만들어줘.

에이전트 엔지니어링이란? — 대화에서 위임으로

프롬프트·컨텍스트·하네스가 'AI에게 어떻게 일을 시킬 환경을 만드느냐'였다면, 에이전트 엔지니어링은 한 걸음 더 나아가 '일하는 주체 자체를 어떻게 설계하느냐'입니다. 에이전트(Agent)는 스스로 계획을 세우고, 도구를 쓰고, 결과를 검증하며, 필요하면 반복하는 AI입니다. 한 번 묻고 한 번 답하는 '대화'를 넘어, 일을 통째로 '위임'받아 처리하는 존재입니다. 노무사 비유로는 신입 직원을 키우는 것과 같습니다. 어떤 권한을 줄지, 어떤 일을 맡길지, 누가 그 일을 검수할지를 설계하는 것 — 그것이 에이전트 엔지니어링입니다. 잘 설계된 에이전트는 유능한 직원처럼 일하고, 잘못 설계된 에이전트는 사고를 칩니다.
TIP: Phase 12의 Dispatch, Phase 13의 서브에이전트가 에이전트 엔지니어링의 도구였다면, 이 강의는 '왜·어떻게 에이전트를 설계해야 하는가'라는 원리를 묶어 줍니다.

도구 표면 설계 — 무엇을 손에 쥐어줄까

에이전트에게 어떤 도구를 어떤 형태로 주느냐가 첫 번째 설계 과제입니다. 이를 '도구 표면(tool surface) 설계'라 합니다. [넓은 도구 vs 좁은 도구] '터미널 명령 전부'처럼 넓은 도구는 만능이지만 위험합니다. 반면 'send_email', 'verify_citations'처럼 좁고 전용화된 도구는 통제하기 쉽습니다. [전용 도구로 승격해야 할 때] - 되돌리기 어려운 행동: 메일 발송, 파일 삭제, 외부 제출 → 사람 승인을 걸 수 있는 전용 도구로 - 검증이 필요한 행동: 인용 검증, 계산 검산 → 자동 점검을 붙일 수 있는 전용 도구로 노무사 관점에서 핵심 원칙은 이것입니다. "되돌릴 수 없는 일일수록 좁은 도구로, 승인 게이트를 걸어라." AI가 의뢰인에게 메일을 '바로 발송'하게 두지 말고, '초안 작성'까지만 시키고 발송은 사람이 — 이것이 도구 표면 설계입니다.

서브에이전트 — 작성자와 검증자를 나눠라

에이전트 엔지니어링에서 가장 강력한 패턴은 '역할 분리'입니다. 글을 쓰는 에이전트와 그것을 검증하는 에이전트를 따로 두는 것입니다. 왜 나눌까요? 사람도 자기가 쓴 글의 오류는 잘 못 잡습니다. AI도 같습니다. 자기가 작성한 의견서를 자기가 검수하면 실수를 놓칩니다. 그래서 별도의 '검증 전용' 에이전트가 새 눈으로 점검하게 합니다. 한동노무법인 파이프라인이 정확히 이 구조입니다. - 작성 에이전트: 블로그·의견서·구제신청서 초안 작성 - 검증 에이전트(legal-document-verifier): 사건번호·법조문을 korean-law로 교차 검증, 실패 건은 반려 이 분리 덕분에 작성자가 무심코 만든 가짜 판례나 잘못된 조문이 검증 단계에서 걸러집니다. '울트라코드'가 수십 개 서브에이전트를 병렬로 돌리는 것도 같은 원리 — 여러 전문 에이전트가 각자 역할을 나눠 협업합니다.
TIP: 노무 문서는 반드시 '작성 → 별도 검증' 2단계를 거치게 설계하세요. 같은 에이전트, 같은 맥락에서 자가 검수하면 할루시네이션을 못 잡습니다. 작성과 검증은 다른 lane(차선)에서.

Managed Agents — 서버가 알아서 돌리는 에이전트

2026년에는 에이전트를 더 본격적으로 운영하는 방법도 생겼습니다. Managed Agents(관리형 에이전트)는 Anthropic 서버가 에이전트의 실행 환경(작업 컨테이너)을 직접 제공하고 굴려 주는 방식입니다. 쉽게 말해, 내 컴퓨터를 켜 두지 않아도 클라우드에서 에이전트가 일합니다. 에이전트의 설정(모델·역할·도구·검증 기준)을 한 번 정의해 두면, 필요할 때마다 세션을 띄워 일을 시킬 수 있습니다. 여기에 '예약 실행(scheduled deployment)'을 붙이면 정해진 시각에 자동으로 돕니다. "매주 금요일 저녁, 이번 주 신착 판례를 정리해 둬"처럼. 노무법인 활용 시나리오: - 매일 아침 고용노동부 보도자료·신착 판례 수집·정리 - 자문 사업장 취업규칙 변경 사항 정기 점검 - 블로그 소재 후보 자동 발굴 단, 일반 노무사가 당장 직접 구축할 필요는 없습니다. 이것이 '에이전트를 본격 운영하면 이런 단계까지 간다'는 지도라는 점만 알아두면, 다음 단계인 루프 엔지니어링이 자연스럽게 이해됩니다.
# 에이전트 엔지니어링 = 역할·권한·검증의 설계

  # [원칙 1] 되돌릴 수 없는 행동은 승인 게이트
  # 발송/제출/삭제 → 사람이 최종 결정

  # [원칙 2] 작성과 검증을 분리
  claude "다음 두 단계로 처리해줘.
  1) 작성 에이전트: 부당해고 구제신청서 초안
  2) 검증 에이전트: 인용한 판례 사건번호를
     korean-law로 전부 검증, 미확인 건은 반려.
  검증 통과분만 나에게 보고해."

  # [원칙 3] 반복 운영은 예약·자동화로 (Managed Agents)
  # "매주 금요일 18시, 신착 판례 요약" 같은 정기 작업

핵심 정리

  • ✓에이전트 엔지니어링은 일하는 주체(스스로 계획·도구사용·검증·반복하는 AI) 자체를 설계하는 기술로, '대화'에서 '위임'으로의 도약입니다.
  • ✓도구 표면 설계의 원칙은 '되돌릴 수 없는 행동일수록 좁은 전용 도구로, 승인 게이트를 걸어라'이며, AI에게 메일 자동 발송 같은 위험한 권한을 함부로 주지 않습니다.
  • ✓가장 강력한 패턴은 작성자와 검증자의 분리입니다. 자가 검수는 오류를 못 잡으므로, 한동노무법인처럼 작성 에이전트와 검증 에이전트(legal-document-verifier)를 따로 둡니다.
  • ✓Managed Agents는 서버가 실행 환경을 제공·운영하는 방식으로, 예약 실행과 결합하면 신착 판례 정리 같은 정기 작업을 자동화할 수 있습니다.

이 강의가 어떠셨나요?