콘텐츠로 이동

모드

모드는 스페이스의 속성이며, 스페이스 행의 컬럼 하나로 저장됩니다. 스페이스 안의 모든 대화가 이를 공유합니다. 스레드도 마찬가지입니다. 스레드는 다른 모든 대화와 똑같이 자신이 속한 스페이스의 모드를 상속합니다. 따라서 같은 에이전트가 동시에 서로 다른 스페이스에서 서로 다른 모드에 있을 수 있고, 스페이스의 모드를 바꾸면 에이전트를 건드리지 않고도 다음 턴의 동작이 달라집니다.

모드는 정확히 네 가지입니다: chat, review, plan, orchestrate. 열거형 자체에는 아무 정책도 담겨 있지 않습니다. 모드가 보장하는 모든 것은 역량 프로파일에 한 번 선언되며, 모든 강제 계층이 여기서 투영합니다.

  1. 도구 표면 — 그 모드에 어떤 도구가 존재하는지 자체를 최대 승인 단계, 허용 목록, 거부 목록, 거부되는 효과 클래스 집합으로 표현합니다.
  2. 필수 출력 동사 — 실행이 무언가를 산출했다고 하려면 반드시 호출해야 하는 것입니다.
  3. 거부되는 효과 클래스 — 액션 가드가 아예 거부하는 것입니다.
  4. 워크트리 태세 — 워크트리에 쓸 수 있는지 여부입니다. 이는 변경 도구를 표면에서 제거하는 방식으로 강제되며, 그래서 모든 호스트에서 유지됩니다. 호스트에 OS 샌드박스가 있으면 같은 태세가 파일 시스템 쓰기 규칙까지 함께 정합니다. 읽기 전용 모드는 워크트리를 읽기 전용으로 마운트합니다. 다만 그것은 보장의 두 번째 사본일 뿐, 실제로 일을 하는 쪽은 아닙니다.
  5. 시스템 프롬프트 블록 — 실제로 구성된 도구 목록에서 파생된 생성된 역량 도입부와, 손으로 작성한 지침입니다.

모든 강제 계층이 그 하나의 프로파일에서 투영하므로, 도구 표면, 가드, 워크트리 태세, 프롬프트가 서로 어긋날 수 없습니다.

기본값이며 추가 제약이 없는 유일한 모드입니다. 실행 단계까지의 전체 도구 표면, 쓰기 가능한 워크트리, 거부되는 효과 클래스 없음, 완료 계약 없음입니다. 구현, 버그 수정, 코드베이스에 관한 질문, 그리고 즉흥적인 모든 작업에 사용합니다.

레이블에 주의하세요. 작성기에서 이 모드는 “Chat”이 아니라 **“Agent”**로 표시됩니다.

플랜 — 읽기 전용, 산출물 하나

섹션 제목: “플랜 — 읽기 전용, 산출물 하나”

플랜 모드는 워크트리를 읽기 전용으로 만들고 쓰기 도구를 표면에서 완전히 제거하므로, 제한이 지시된 것이 아니라 구조적입니다. 에이전트는 읽고 검색하고 조사한 뒤 정확히 한 가지를 산출합니다. 타입이 지정된 의존성 그래프, 즉 목표와, 키·제목·설명과 각 노드가 의존하는 노드 키를 가진 노드들을 담은 submit_plan 호출입니다.

플랜은 대화에 간결한 행으로 렌더링되고, 옆 탭에 Plan Studio를 엽니다. 플랜을 승인하면 그래프가 오케스트레이션으로 컴파일되고, 생성된 작업이 실행되며, 작성 스페이스가 에이전트 모드로 되돌아갑니다.

플랜 모드 실행이 submit_plan을 한 번도 호출하지 않고 끝나면, 루프는 먼저 그 호출이 성공하기 전까지는 플랜이 존재하지 않는다는 넛지를 주입합니다. 이 넛지는 “여기에는 플랜이 필요하지 않습니다”라는 정직한 종료를 명시적으로 허용합니다. 플랜 모드는 스페이스 설정이므로, 그 안에서 하는 평범한 질문이 엉터리 플랜을 강요해서는 안 되기 때문입니다.

빠져나가는 방법이 하나 더 있습니다: exit_plan_mode입니다. 이것은 출력 동사가 아니라 엄격한 승인 게이트입니다. submit_plan 대신 이것을 호출한 에이전트는 아무것도 산출하지 않은 것입니다. 첫 호출은 영속적인 plan_exit 승인을 열고 pending을 반환하며, 스페이스는 읽기 전용으로 남습니다. 반복 호출은 두 번째 게이트를 여는 대신 pending에 머뭅니다. 승인이 허가된 뒤에야 이후 호출이 스페이스를 채팅으로 전환합니다. 거부되면 에이전트는 수정된 플랜을 위한 새 요청을 열 수 있습니다.

플랜 모드에서 직접 빠져나오려면 작성기 드롭다운(또는 Shift+Tab)을 전환하세요. exit_plan_mode는 decide_approval MCP 도구로 결정합니다. 받은편지함의 “에이전트 승인” 행은 다른 것입니다. 실행 중인 에이전트가 턴마다 보내는 확인 요청입니다.

리뷰 모드는 PR 리뷰를 위한 것입니다. 워크트리를 읽기 전용으로 만들고, 도구 표면을 실행 단계 아래로 제한하며, 리뷰·티켓·커뮤니케이션 도구의 선별된 허용 목록을 적용합니다. 풀 리퀘스트를 위해 열린 스페이스는 자동으로 리뷰 모드로 생성됩니다.

에이전트의 산출물은 구조화된 발견 사항, 즉 리뷰 노드이며, 리뷰가 마무리되면 판정입니다. 노드는 종류(bug, suggestion, recommendation, question, ticket 중 하나), P0(릴리스 차단)부터 P3(있으면 좋음)까지의 우선순위, 스스로 평가한 신뢰도, 선택적인 앵커(파일과 줄 범위이며, 저장소 전반을 다루는 노트에는 없음), 그리고 동료가 — 절대 작성자가 아니라 — 확인하면 open에서 consensusReady로 이동하는 수명주기 상태를 담습니다. 우선순위나 신뢰도가 없거나 범위를 벗어난 발견 사항은 판정을 오염시키는 대신 읽기 경계에서 버려집니다.

판정은 ship, hold, block 중 하나이며, 여기에 합쳐지는 축별 결과에 의해 더 엄격해질 수만 있습니다. 게이트 대상 축이 실패하면 block이 강제되고, 게이트 대상 축이 실행되지 못하면 최소한 hold가 강제됩니다. 증거의 부재는 결코 초록 게이트로 바뀌지 않습니다.

플랜 및 오케스트레이트와 달리, 리뷰에는 완료 계약이 없습니다. 발견 사항은 add_review_node로 쌓이고 finalize_review로 게시되며, 둘 다 정당하게 0번 호출될 수 있습니다. 리뷰 모드로 실행되는 파이프라인 에이전트는 대신 티켓을 완료하기 위해 그곳에 있을 수 있습니다.

오케스트레이트 — 읽기 전용, 팀을 제안

섹션 제목: “오케스트레이트 — 읽기 전용, 팀을 제안”

오케스트레이트 모드는 하나의 목표를 팀 전체의 플랜으로 바꿉니다. 플랜 모드와 마찬가지로 읽기 전용이며 파일을 쓸 수 없습니다. 조사 표면에 더해 단 하나의 특권 동사 propose_orchestration을 갖추고 있으며, 이것이 역할, 하위 티켓 트리, 종합 단계, 예산으로 이루어진 구조화된 제안을 내놓습니다. 프롬프트에는 표면에 있는 도구만 나열되므로, 모델은 호출할 수도 없는 채용이나 티켓 작업을 읊조리는 데 턴을 낭비하지 않습니다.

제안은 승인하기 전까지 아무것도 실행되지 않습니다. 승인하면 결정적 머티리얼라이저가 에이전트를 고용하고, 티켓과 프로젝트를 만들고, 생성된 파이프라인을 실행합니다. 승인은 운영자만 할 수 있습니다. 이를 위한 MCP 도구가 없으므로 에이전트는 제안할 수는 있어도 자기 플랜을 승인할 수는 없습니다. 에이전트가 시작한 재제안은 2분 쿨다운으로 속도가 제한되므로, 연이은 재계획은 거부되고 하나로 합치라는 안내를 받습니다. 오케스트레이션을 참고하세요.

모드 자체의 출력 동사는 결코 거부될 수 없습니다. submit_plan과 propose_orchestration은 도구 표면에 고정되고 도구 필터, 승인 게이트, 액션 가드를 모두 통과하도록 사전 승인되므로, 스페이스별 자율성 다이얼이 모드의 산출물을 막을 수 없습니다. 하네스의 ask_user도 같은 이유로 고정됩니다. 이것이 바로 실행이 운영자에게 닿는 방법이므로, 이를 게이트하면 무언가를 물어야 하는 실행이 교착 상태에 빠집니다. 읽기 단계에 속하므로 모든 읽기 전용 모드가 이를 유지하며, 승인 래퍼에서 예외입니다. 프롬프트 앞에 또 프롬프트를 두면 승인자가 연결되지 않은 상태에서 닫힌 채 실패하고, 이는 에이전트가 질문하는 행위 자체를 거부하는 셈이 됩니다.

읽기 전용 모드는 네트워크 접근이나 시크릿을 거부하지 않습니다. 리뷰, 플랜, 오케스트레이트 모드가 거부하는 효과 클래스는 세상을 바꾸는 것들입니다: 파일 삭제, 워크트리 밖 쓰기, 커밋, 푸시, PR 생성과 게시, 벤더 동기화 쓰기, 패키지 설치, 프로세스 생성, 워크스페이스 변경, 인클로저 제어입니다. 네트워크 이그레스와 시크릿 접근은 의도적으로 기본값으로 남겨 둡니다. 조사 연구가 읽기 전용 모드의 존재 이유 전체이기 때문입니다.

작성기의 모드 드롭다운은 세 가지 옵션을 제공합니다: Agent(채팅), Plan, Orchestrate입니다. review는 사용자가 선택할 수 없습니다. PR 리뷰 스페이스가 생성될 때 시스템이, 그리고 파이프라인 단계가 설정합니다.

스페이스를 여는 파이프라인 노드는 extras['mode'] 키(chat, review, plan 중 하나)로 그 방의 모드를 고정할 수 있습니다. 이 키는 정확히 일치해야 합니다. orchestrate를 포함해 다른 철자는 조용히 무시되고, 방에는 본문의 기본값이 적용됩니다(스페이스 생성 본문에서는 review). 에이전트 단계는 자신이 만들지 않은 방에 참여하며 그 방의 권한을 다시 설정하지 않습니다.

해석 자체는 단순합니다. 디스패처는 스페이스의 mode 컬럼을 읽습니다. 스페이스가 없는 디스패치 — 일회성 실행, CLI 호출, 또는 이 워크스페이스의 데이터베이스 파일에 아예 없는 다른 워크스페이스의 스페이스 id — 는 chat으로 해석됩니다. 모드를 변경하면 다음 턴부터 적용됩니다.

모드의 도구 표면은 내장 하네스가 만들고 강제합니다. 도구를 단순히 거부하는 데 그치지 않고 보이지 않게 만들고, 모든 호출을 실행 전에 게이트하며, 완료 계약을 관찰할 수 있는 유일한 트랜스포트입니다.

Claude Code 트랜스포트에서는 비채팅 모드가 --permission-mode plan으로 전달됩니다. Claude는 관례적으로 이를 따를 뿐이며, 자체 읽기·쓰기·편집 도구는 보이지 않게 실행되고, 셸 명령은 명령줄을 읽는 훅으로만 확인됩니다. 그 트랜스포트에서 모드는 지침일 뿐 Control Center의 경계가 아닙니다. 에이전트 모델을 참고하세요.

허용 목록은 쓰기 단계 이상 도구를 제약합니다. 내장 하네스의 읽기 단계는 어떤 목록에도 없는 도구까지 여전히 닿습니다. Claude Code에서는 허용 목록이 빠뜨린 도구가 서버에 있든 없든 거부됩니다.