Claude Code를 '옆에 붙어 지켜보는' 운영에서 졸업하기: /goal · agents 뷰 · auto mode 실무 도입 가이드

이 기사에서 알 수 있는 것

• Claude Code에 2026년 봄 이후 추가된 '방치형 운영' 계열 기능(claude agents, /goal, auto mode, Monitor, Routines)의 역할 분담
• 여러 세션을 병렬로 실행할 때, 어떤 기능을 어떤 순서로 도입해야 하는가
• 자동 승인 (auto mode)을 업무 리포지토리(Repository)에서 사용하기 전에 결정해야 할 경계선

정보원은 모두 Claude Code 공식의 What's new (주간 다이제스트)입니다. 확인되지 않은 소문이나 유출 정보는 포함하지 않았습니다.

과제: 에이전트는 늘어났지만, 눈은 두 개뿐이다

Claude Code를 실무에서 사용하기 시작하면, 즉시 "세션을 여러 개 병렬로 돌리고 싶다"는 욕구가 생깁니다. 리팩터링(Refactor) 하나, 테스트 추가 하나, 조사 하나. 하지만 실제로 해보면 다음과 같은 문제에 부딪힙니다.

• 어떤 세션이 지금 돌아가고 있는지, 어떤 것이 내 승인을 기다리며 멈춰 있는지 알 수 없다
• "끝나면 다음으로"가 자동으로 이어지지 않고, 턴(Turn)마다 인간이 재촉해야 한다
• 허가 프롬프트(Permission prompt)에 답하기 위해서만 터미널로 돌아와야 한다

2026년 3월~5월의 업데이트는 이 세 가지에 각각 대응하는 기능이 갖춰진 기간이었습니다. 차례대로 살펴보겠습니다.

claude agents: 모든 세션을 한 화면에 집약한다

1. 2026년 5월 중순 (v2.1.139~v2.1.142)에 추가된 에이전트 뷰(Agent view)입니다.

claude agents

공식 설명은 다음과 같습니다.

원문: "claude agents opens one screen for every Claude Code session, showing what's running, what's blocked on you, and what's done."

일본어 번역: "claude agents는 모든 Claude Code 세션을 하나의 화면에서 열어, 무엇이 실행 중이고, 무엇이 당신의 대응을 기다리고 있으며, 무엇이 완료되었는지 표시한다."

운용상의 포인트는 '실행 중'이 아니라 '당신의 대응 대기(blocked on you)'가 보이는 것입니다. 병렬 운용의 병목 현상은 모델의 속도가 아니라, 인간의 승인 대기열입니다. 우선 이곳을 가시화하지 않으면, 세션을 늘릴수록 방치 시간이 길어집니다.

/goal: "턴마다 재촉하기"를 그만두다

2. 마찬가지로 5월 중순에 도입된 /goal은 완료 조건이 충족될 때까지 턴을 넘나들며 작업을 계속하게 하는 기능입니다.

기존에는 "테스트가 통과할 때까지 계속해"라고 써도, 1턴의 응답이 끝나면 멈추고 인간이 "계속해"라고 재촉하는 운용이 되기 일쑤였습니다. /goal은 완료 조건(예: 테스트가 모두 통과함, lint 에러가 0이 됨)을 선언해 두면, 조건이 성립할 때까지 Claude 측이 작업을 계속합니다.

실무에서는 완료 조건을 기계적으로 판정할 수 있는 형태로 작성하는 것이 요령입니다.

• 좋은 예: "npm test가 exit code 0으로 종료된다"
• 나쁜 예: "적절하게 리팩터링되어 있다"

후자는 판정이 불가능하므로, 끝없이 작업이 이어지거나 어중간한 시점에서 "완료"라고 판단될 리스크가 있습니다.

3. auto mode: 허가 프롬프트를 분류기에 위임하다

2026년 3월 하순에 리서치 프리뷰(Research preview)로 도입된 auto mode는, 허가 프롬프트를 분류기(Classifier)가 처리하여 안전한 조작은 중단 없이 실행하고, 위험한 조작은 차단하는 메커니즘입니다. "전부 수동 승인"과 --dangerously-skip-permissions 사이의 중간 위치를 차지합니다.

나아가 5월 초순 (v2.1.128~v2.1.136)에 hard deny rules가 추가되었습니다. 이는 allow 측의 예외 설정과 관계없이 무조건적으로 차단하는 규칙입니다.

업무 리포지토리에 도입한다면, 다음과 같은 순서를 추천합니다.

• 먼저 hard deny로 "절대로 허용하지 않을 조작"을 정의한다 (예: 운영 환경 배포, force push, 비밀 정보가 포함된 경로에 대한 액세스)
• 그 다음 auto mode를 활성화하고, 1~2주간은 판정 로그를 확인한다
• 판정을 신뢰할 수 있게 되면, 방치 시간을 늘린다

deny를 먼저 고정하지 않고 auto mode만 도입하면, "분류기를 신뢰할 수 있는가"를 매번 자신의 감각으로 판단하게 되어, 결국 옆에 붙어 지켜보는 운용으로 돌아가게 됩니다.

4. Monitor와 Routines: 이벤트 드리븐(Event-driven)과 정기 실행

• Monitor (4월 초): 백그라운드 이벤트를 대화로 스트리밍하여, Claude가 로그를 tail(추적)하고 반응할 수 있게 하는 도구입니다. "빌드가 실패하면 조사하고 수정하기"와 같은 대기형 방식으로 사용할 수 있습니다.
• Routines (4월 중순, Claude Code on the web): 스케줄, GitHub 이벤트, API 호출을 트리거로 하여 템플릿화된 클라우드 에이전트 (Cloud Agent)를 실행합니다. 야간의 의존성 (Dependency) 업데이트 체크나, Issue가 생성되었을 때의 1차 조사 등이 이에 해당합니다.

로컬에서 대화형으로 사용하는 /goal과 서버 측에서 자동으로 실행되는 Routines는 상호 보완 관계입니다. "인간이 리뷰한다는 전제의 정형 작업"부터 우선적으로 Routines로 분리하면, 실패하더라도 복구 (Recovery)가 용이합니다.

도입 체크리스트

순서	할 일	대응 기능
1	승인 대기 상태의 가시화	claude agents
...

역순(auto부터)으로 도입하면 사고가 발생했을 때 원인 파악 (Troubleshooting)을 할 수 없습니다. 1번에서 5번 순서로 한 단계씩 확장하는 것이 안전합니다.

주의사항

• auto mode와 Monitor는 리서치 프리뷰 (Research Preview) 단계의 기능으로, 동작이나 명칭이 변경될 가능성이 있습니다. 도입 전에 공식 다이제스트 (Official Digest)를 통해 최신 상태를 확인하십시오.
• /goal을 통한 방치형 운용은 토큰 소비량을 예측하기 어렵게 만듭니다. /usage를 통해 소비 요인을 확인하며 사용하는 것을 권장합니다.
• "방치할 수 있다"와 "확인하지 않아도 된다"는 별개의 문제입니다. 결과물에 대한 리뷰 게이트 (Review Gate: PR 리뷰, 테스트, 운영 반영을 위한 수동 승인)는 제거하지 마십시오.

요약

병렬 에이전트 운용의 본질은 "모델을 늘리는 것"이 아니라 "인간이 병목 (Bottleneck)이 되는 지점을 특정하고, 안전하게 제거할 수 있는 것만 제거하는 것"입니다. claude agents로 대기열을 가시화하고, /goal로 촉구 작업을 없애며, hard deny → auto mode 순으로 승인을 위임하십시오. 이 순서를 따른다면 신뢰를 단계적으로 쌓아 올릴 수 있습니다.

업무에서의 AI 활용 및 자동화 상담은 ITPRODX로 문의해 주세요.

Discussion