Claude Code v2.1.318, 위임 작업 및 무인 실행을 위한 제어 기능 추가

Anthropic의 Claude Code v2.1.318은 위임 작업을 위한 제어 기능을 추가하는 한편, 무인 코딩 세션을 중단시키는 오류를 해결한다. 이번 업데이트의 핵심 긴장점은 운영 측면에 있다. 에이전트에 더 많은 책임을 부여할수록 자격 증명, 권한, 복구 가능한 상태의 중요성도 커진다.

개발자에게 이는 어시스턴트가 유용한 패치를 만들 수 있는지 여부를 넘어 평가 기준이 확장된다는 뜻이다. 코딩 에이전트는 지침을 보존하고, 실패를 정확히 보고하며, 권한이 끝나면 작업을 중단할 수 있어야 한다. 작업이 활성 터미널 밖에서 계속될 때 이러한 요구사항은 감독하기가 더 까다로워진다.

GitHub Copilot은 문서화된 클라우드 경험에서도 클라이언트 간 에이전트 세션 지속을 강조한다는 점에서 관련 비교 대상이 된다. 더 넓은 질문은 사람, 프로세스, 환경 간 전환을 거치면서 위임된 작업이 얼마나 안정적으로 유지되는가이다. 이번 릴리스는 살펴볼 만한 구체적인 변경 사항을 제공하지만, 릴리스 노트만으로 그 효과를 입증할 수는 없다.

Claude Code v2.1.318의 변경 사항

이번 릴리스는 세션 안정성 수정과 함께 에이전트 실행을 둘러싼 제어 기능에 집중한다.

Anthropic의 릴리스 노트에는 여러 추가 사항이 명시돼 있다. Claude Code는 이제 프로그래밍 방식 확장 기능인 세션 작성 모드 활성화 여부를 묻는 프롬프트에 대한 답변을 기록한다. 모드의 $.model.fork에는 effort 옵션이 추가되어, 위임 작업에서 다른 노력 수준 설정을 사용할 수 있다.

저장된 로그인 만료 시점은 인증 상태의 loginExpiresAt와 프로그래밍 방식 JSON 결과의 credential_expires_at를 통해 확인할 수 있게 됐다. 텍스트 출력에는 만료 10일 전부터 경고가 표시된다.

게이트웨이에는 계정 간 AWS 역할 및 개발자 단위 비용 귀속을 위한 mantle 업스트림의 assume_role 지원도 추가됐다. Anthropic은 대화 지속, 권한 프롬프트, 구성 유지, 잘못 보고된 성공 상태와 관련한 수정 사항도 보고했다. GitHub는 이 릴리스의 날짜를 11월 4일로 표시한다.

이러한 변경 사항은 서로 다른 구성 요소를 다루지만, 실질적인 공통 주제를 갖는다. 에이전트의 운영 조건을 더 명시적으로 드러낸다는 점이다. 개발자는 만료 날짜를 확인하고, 위임 작업에 노력 수준을 할당하며, 승인 결정이 기록됐는지 검토할 수 있다.

이러한 가시성은 위임이 지시와 최종 실행 사이에 거리를 만들기 때문에 중요하다. 한 사람이 터미널을 보면서 작업을 승인한 뒤, 다른 프로세스가 작업을 재개한 후에 돌아올 수 있다. 그 사이에도 원래의 의도는 이해 가능한 상태로 유지돼야 한다.

예를 들어, 밤새 실패한 테스트를 조사하도록 어시스턴트를 사용하는 가상의 엔지니어링 팀을 생각해 볼 수 있다. 예상 결과물은 진단 또는 제안된 패치다. 그러나 이 워크플로는 유효한 신원, 사용할 수 있는 프로젝트 설정, 정확한 완료 신호에도 의존한다.

그럴듯한 답변은 운영 맥락을 조용히 잃어버린 프로세스를 보완할 수 없다. 마찬가지로 온전한 기록이 결과 코드의 정확성을 입증하지도 않는다. 결과물의 품질과 실행 무결성은 별도로 평가해야 한다.

이 구분이 이번 업데이트에 뉴스 가치를 부여한다. 추가된 기능은 코딩 능력을 판단하는 새로운 근거를 제공하기보다, 작업이 진행되는 조건과 관련이 있다. 독자는 운영 제어 기능을 모델 지능 향상의 증거로 간주하지 않아야 한다.

정보를 노출하는 것과 그 정보에 따라 행동하는 것 사이에도 차이가 있다. 만료 필드는 주변 시스템이 이를 확인할 때만 유용해진다. 기록된 결정도 누군가가 이를 관련 작업과 연결할 수 있을 때만 의미가 있다.

노력 수준 선택에도 같은 원칙이 적용된다. 명시적 설정은 개발자에게 또 하나의 제어 수단을 제공하지만, 적절한 설정을 대신 선택해 주지는 않는다. 팀은 여전히 작업 중요도, 검토 요건, 배정 자원 사이에 타당한 관계를 마련해야 한다.

변경 사항을 함께 보면, 대대적인 생산성 주장보다 더 제한적인 결론을 뒷받침한다. Anthropic은 위임형 코딩을 둘러싼 구체적인 운영 경계를 다루고 있다. 이러한 변경이 중단이나 검토 작업을 줄이는지는 실제 배포 환경에서 검증해야 할 경험적 질문으로 남는다.

무인 작업은 주변 시스템에 부담을 준다

직접적인 부담은 대화형 어시스턴트를 반복적인 운영 의존성으로 전환하는 개발자에게 돌아간다.

대화형 세션은 이를 지켜보는 사람이라는 비공식 모니터링 시스템을 제공한다. 그 사람은 망설임을 알아차리고, 예상치 못한 프롬프트를 살피거나, 답변이 너무 일찍 멈췄음을 인식할 수 있다. 무인 실행에서는 이러한 맥락의 상당 부분이 사라진다.

Anthropic의 프로그래밍 방식 실행 문서는 claude -p를 대화형 입력 없이 Claude Code를 실행하는 방법으로 설명한다. 구조화된 출력과 프로세스 종료 상태를 지원하므로, 스크립트가 결과를 소비하고 실패에 대응할 수 있다.

이러한 인터페이스는 통합 책임자에게 중요한 책임을 부여한다. 스크립트에는 성공에 대한 명시적 정의가 필요하다. 예상된 패치, 분석 또는 검증이 완료되지 않았다면 읽을 수 있는 텍스트를 받는 것만으로는 충분하지 않다.

변경 사항을 검토하고 아침 보고서를 생성하는 예약 작업을 상상해 보자. 이는 문서화된 고객 배포 사례가 아니라 설명을 위한 시나리오다. 그 유용성은 정상적인 검토와 불완전한 조사를 구분할 수 있는지에 달려 있다.

두 결과가 모두 비슷하게 자신감 있는 문장을 만들어 낸다면, 보고서 독자는 숨겨진 검증 작업을 떠안게 된다. 누군가는 에이전트가 의도한 자료를 검토했는지, 요청받은 종점에 도달했는지를 재구성해야 한다. 자동화는 노동을 없앤 것이 아니라 옮긴 셈이다.

자격 증명 가시성은 이 문제의 또 다른 부분을 다룬다. 알려진 만료 날짜는 운영자가 일정을 계획할 수 있는 기준을 제공한다. 해당 권한에 의존하는 작업을 배정하기 전에 접근 권한을 갱신할 기회를 만든다.

그러나 신원 유지 관리에는 여전히 책임 주체가 필요하다. 누군가는 경고를 받고, 어떤 워크플로에 영향을 주는지 이해하며, 승인된 대응을 마련해야 한다. 경고를 출력한다고 해서 조직에 그러한 절차가 갖춰졌다는 뜻은 아니다.

이는 책임이 개발자와 인프라 팀에 걸쳐 있을 때 특히 중요하다. 개발자는 작업을 이해하지만, 관리자는 접근 권한을 통제한다. 명확한 인계가 없으면 양측 모두 상대방이 중단 문제를 책임진다고 합리적으로 생각할 수 있다.

운영상의 결과는 더 나은 워크플로 계약이 필요하다는 점이다. 반복되는 에이전트 작업에는 식별 가능한 책임자, 예상 출력, 불완전한 실행에 대한 정의된 대응이 있어야 한다. 이는 모델 역량이 아니라 관리상의 선택이다.

검토자에게도 그에 상응하는 부담이 있다. 모든 상호작용을 다시 재생하지 않고도 결과물을 평가할 수 있을 만큼의 실행 맥락이 필요하다. 정확한 완료 기록은 어디에 주의를 집중해야 하는지 판단하는 데 도움이 된다.

팀은 재시도가 정당한 실패와 개입이 필요한 실패도 구분해야 한다. 중단된 요청을 반복하는 것은 일부 상황에서 적절할 수 있다. 그러나 권한이 불분명한 작업을 반복하는 것은 다른 문제를 만든다.

이 분석은 이번 업데이트가 그러한 조직적 문제를 해결했다고 입증하지는 않는다. Claude Code가 반복 작업의 일부가 되었을 때 영향을 받는 인터페이스가 왜 중요한지를 보여준다. 소프트웨어가 그 신호를 이용해 후속 결정을 내릴 때, 작은 신호도 중요한 결과를 낳는다.

따라서 엔터프라이즈 구매자에게 관련된 질문은 구체적이다. 기존의 모니터링 및 접근 관리 프로세스가 에이전트의 신호를 해석할 수 있는가? 기능 목록만으로는 답할 수 없다. 대표적인 워크플로를 통해 통합이 순환 구조를 완성하는지 확인할 수 있다.

위임 작업에는 계속 이해 가능한 경계가 필요하다

더 많은 위임은 노력 수준, 신원, 권한을 둘러싼 명시적 경계의 가치를 높인다.

노력 수준 제어는 첫 번째 경계를 보여준다. 위임 작업은 범위가 좁은 추출 작업일 수도, 까다로운 조사일 수도 있다. 두 작업을 동일하게 취급하면 요구사항이 크게 달라도 자원 배정 결정은 암묵적으로 이뤄진다.

유용한 분석 질문은 개발자가 오류의 결과에 따라 자원을 할당할 수 있는가이다. 짧은 작업도 민감할 수 있다. 긴 작업도 일상적일 수 있다. 길이만으로 노력 수준을 선택하는 것은 약한 기준이다.

예를 들어, 파일명을 수집하는 작업과 보안에 민감한 변경 사항을 평가하는 작업에는 서로 다른 검토 기대치가 필요하다. 이 가상 비교는 노력 수준 설정 간 성능 차이를 입증하지 않는다. 대신 명시적 설정에 작업별 근거가 필요한 이유를 설명한다.

반환된 설정은 결과 측정과도 다른 목적을 갖는다. 어떤 구성이 전송됐는지는 보여줄 수 있다. 그러나 답변이 수용 가능한 품질 기준에 도달했는지, 선택된 자원 배정이 효율적이었는지는 입증할 수 없다.

신원은 또 다른 경계를 만든다. AWS는 계정 간 역할을 승인된 사용자가 다른 계정의 리소스에 접근하는 방법으로 문서화한다. 역할의 권한이 접근을 규정하며, 신뢰 정책과 권한 정책이 누가 이를 맡을 수 있는지 통제한다.

이 배경은 역할 수임을 기반으로 한 모든 애플리케이션 통합을 평가할 때 중요하다. 이 메커니즘을 지원한다고 해서 조직의 권한 설계가 결정되는 것은 아니다. 관리자는 여전히 어떤 신원이 어떤 리소스에 접근할 수 있는지 결정해야 한다.

비용 귀속 역시 비용 통제와는 다르다. 활동을 개발자에게 귀속하면 사용량을 설명하는 데 도움이 될 수 있다. 그러나 해당 작업이 필요했는지, 결과가 유용했는지, 더 저렴한 자원 배정으로 충분했는지는 결정하지 않는다.

공유 작업에는 거버넌스 문제도 있다. 에이전트는 한 사람이 요청했지만 팀 전체에 도움이 되는 작업을 수행할 수 있다. 소비량을 개인에게 귀속한다고 해서 그러한 더 넓은 가치를 자동으로 포착하는 것은 아니다.

권한은 세 번째 경계다. Anthropic의 권한 시스템은 접근 규칙, 승인 동작, 관리형 정책을 구분한다. 문서에서는 일부 승인은 유지되는 반면 다른 승인은 세션 내에서만 적용된다고 설명한다.

이 구분에는 실질적인 결과가 있다. 기억된 선호와 특정 작업에 대한 권한 부여는 서로 다른 기록이다. 검토자는 어느 기록이 실행을 정당화했는지 이해해야 한다. 그렇지 않으면 겉보기에는 도움이 되는 지속성이 모호한 권한이 될 수 있다.

적절한 기준은 이해 가능한 연속성이다. 작업이 재개되거나 하위 작업을 위임할 때, 관련 제약 조건은 책임 있는 사람들에게 계속 명확해야 한다. 에이전트의 작업 지속 능력은 그러한 제약 안에서만 가치가 있다.

이 때문에 감사 가능성은 구체적인 질문을 통해 판단해야 한다. 누가 작업을 요청했는가? 어떤 신원이 이를 실행했는가? 어떤 범위가 승인됐는가? 어떤 결과가 검토자에게 전달됐는가? 각 질문은 서로 다른 책임을 다룬다.

어느 것도 악의적인 행동을 가정할 필요는 없다. 평범한 오해만으로도 약한 경계는 비용이 커질 수 있다. 개발자는 한 맥락에서는 올바른 작업을 승인하고도, 나중에는 관련 작업이 다른 곳에서 왜 진행됐는지 판단하기 어려울 수 있다.

Claude Code v2.1.318에 대한 시사점은 절제돼 있다. 추가 제어 기능은 더 신중한 위임의 기회를 만든다. 그 유용성은 주변 도구가 이러한 구분을 보존하고 검토 중 접근할 수 있게 하는지에 달려 있다.

지속적인 세션은 경쟁 요건이 되고 있다

경쟁은 개별 답변의 품질뿐 아니라 환경 전반에서 작업이 이어지는 능력까지 점점 포함하고 있다.

GitHub가 문서화한 클라우드 세션은 유용한 비교 기준을 제공한다. GitHub의 최신 Copilot 경험은 지원되는 클라이언트 전반에서 작업이 계속되며, 대화가 에이전트 작업이 실행되는 환경과 연결된다고 설명한다.

GitHub는 클라이언트, 세션, 실행 환경도 구분한다. 클라이언트는 사용자가 사용하는 인터페이스다. 세션에는 대화와 활동이 담긴다. 환경은 작업이 이루어지는 장소다.

이 용어는 동등한 구현을 암시하지 않으면서 경쟁의 핵심을 명확히 하는 데 도움이 된다. 실행 환경이 바뀌어도 대화는 계속 표시될 수 있다. 익숙한 인터페이스 뒤에는 다른 머신, 자격 증명 컨텍스트 또는 사용 가능한 도구 세트가 숨겨져 있을 수 있다.

따라서 구매자에게 연속성이란 이전 채팅을 찾을 수 있다는 것 이상을 의미해야 한다. 중요한 질문은 전환 이후에도 작업을 이해하고 제어할 수 있는지다. 대화 기록은 증거를 제공하지만, 평가의 일부일 뿐이다.

한 개발자가 로컬에서 조사를 시작한 뒤 나중에 다른 인터페이스를 통해 진행 상황을 검토한다고 생각해 보자. 개발자가 현재 상태를 이해하고 적절히 개입할 수 있다면 인수인계는 유용하다. 편의성은 운영상의 명확성에 달려 있다.

이 비교가 어느 제품이 전환을 더 잘 처리한다고 입증하는 것은 아니다. 문서는 공동의 독립 테스트가 아니라 의도된 동작을 설명한다. 순위를 매기려면 일치하는 작업, 비교 가능한 권한, 명확히 정의된 실패 조건이 필요하다.

다만 이는 관련된 평가 범주를 제시한다. 지속되는 에이전트 작업은 과거에는 사람이 직접 감독하던 경계를 넘어 의도를 전달하도록 소프트웨어에 요구한다. 구매자는 세련된 인터페이스만으로 이를 추론하기보다 해당 동작을 직접 살펴봐야 한다.

설득력 있는 데모는 에이전트가 깔끔한 작업을 완료하는 모습을 보여줄 수 있다. 운영 평가는 중단, 접근 권한 변경 또는 사용할 수 없는 종속성이 발생한 뒤 어떤 일이 일어나는지 묻는다. 이러한 조건은 워크플로가 계속 이해 가능한 상태인지 드러낸다.

공급업체는 이러한 전환을 정확히 설명해야 한다는 압박을 받고 있다. 사용자는 무엇이 유지되고, 무엇을 다시 확인하며, 무엇에 재승인이 필요한지 알아야 한다. 연속성에 대한 모호한 약속은 통합 팀이 계약 내용을 스스로 찾아내도록 만든다.

조달 팀에도 같은 압박이 있다. 지원 모델이나 에디터 통합만을 중심으로 한 체크리스트는 운영 동작을 놓친다. 평가는 조직이 실제로 작업을 위임하려는 방식에 맞춰야 한다.

가끔 보조 편집을 수행하는 팀에게 복구 동작은 부차적인 문제일 수 있다. 반복적인 백그라운드 작업을 맡기는 팀에게는 핵심이 된다. 같은 기능도 운영 모델에 따라 중요도가 달라질 수 있다.

엔지니어링 조직은 자체 결정에 대한 지속 가능한 문서화도 필요하다. 검색 가능한 지식 기반은 통합 가정, 장애 보고서, 업그레이드 평가를 보존할 수 있다. 이는 검토자가 의도된 동작과 현지에서 누적된 우회책을 구분하는 데 도움이 된다.

경쟁적 함의는 극적이라기보다 실용적이다. 작업의 지속을 지원하는 공급업체는 책임의 지속도 관리 가능하게 만들어야 한다. 구매자는 세션 지속성을 단순한 예·아니오 기능으로 취급하기보다 그 관계를 테스트함으로써 더 유용한 증거를 얻는다.

릴리스 노트는 중요한 신뢰성 질문을 남긴다

문서화된 수정은 해결된 문제를 식별하지만, 남아 있는 실패 확률을 측정하지는 않는다.

릴리스 노트는 변경 사항에 대한 공급업체의 설명을 제공한다. 모든 지원 구성에서 신뢰성을 추정하는 데 필요한 배포 수준의 증거를 제공하는 경우는 드물다. 이러한 한계는 독자가 이번 업데이트를 해석하는 방식에 반영되어야 한다.

검증된 자료는 설치 전후의 실패율을 입증하지 않는다. 독립적인 생산성 측정치도 제공하지 않는다. 중단 감소나 운영 비용 절감에 관한 주장은 추가 증거가 필요하다.

유용한 구분은 재현 가능한 수정과 광범위한 신뢰성 결론 사이에 있다. 알려진 실패가 더 이상 발생하지 않음을 입증하면 전자를 뒷받침한다. 후자를 확립하려면 대표적인 워크로드와 시간에 따른 관찰이 필요하다.

구성의 복잡성은 이 구분을 중요하게 만든다. 로컬 워크스테이션과 공유 실행 환경은 서로 다른 가정을 드러낼 수 있다. 새 설치 환경을 테스트한다고 해서 모든 기존 통합이 어떻게 동작하는지 확인할 수는 없다.

조직은 불만이 없다는 사실을 확인으로 간주하는 것도 피해야 한다. 실패한 백그라운드 작업은 공개 이슈 보고서를 읽는 사람에게 결코 전달되지 않을 수 있다. 반대로 눈에 띄는 불만은 광범위한 결함이 아니라 드문 구성을 설명할 수 있다.

그 불확실성을 둘러싸고 논쟁을 억지로 만들 필요는 없다. 적절한 회의적 입장은 방법론적이다. 의도한 주장을 위해 필요한 증거를 점검해야 한다. 유지보수 릴리스는 포괄적인 판단을 뒷받침하지 않더라도 유용할 수 있다.

노력 배분에도 같은 규율이 필요하다. 제한된 작업에는 낮은 설정이 적절할 수 있지만, 리소스 선택만으로 전체 워크플로 효율성을 거의 알 수 없다. 검토 노력과 수정 작업도 평가에 포함된다.

저렴한 예비 분석에 이후 광범위한 검증이 필요하다고 가정해 보자. 즉각적인 리소스 소비는 매력적으로 보일 수 있지만, 실질적인 가치는 제한적일 수 있다. 이는 이번 릴리스에서 관찰된 결과가 아니라 설명을 위한 가능성이다.

기여도에도 관련된 한계가 있다. 누가 작업을 시작했는지에 대한 더 명확한 기록은 책임성을 개선할 수 있지만, 누가 혜택을 얻었는지는 입증하지 않는다. 조직은 공유된 엔지니어링 성과의 맥락에서 사용량을 해석해야 한다.

권한 기록도 의미를 가지려면 맥락이 필요하다. 저장된 응답은 검토자가 해당 응답이 다룬 행동과 상황을 이해할 때만 결정을 설명할 수 있다. 예·아니오 답변만 보관한다고 해서 모든 권한 부여 문제가 해결되는 것은 아니다.

실패 보고의 품질은 특히 주목할 만하다. 운영자는 완전한 답변, 부분적으로 유용한 답변, 실패한 실행을 구분할 수 있어야 한다. 이러한 결과를 단일 성공 레이블 아래 결합하면 이후의 판단이 약화된다.

이러한 우려는 전면적 불신이 아니라 표적화된 평가를 뒷받침한다. 팀은 실제 경계를 시험하는 대표 작업을 선택할 수 있다. 목표는 어디에 사람의 검토가 여전히 필요한지, 어디에서 자동화가 예측 가능하게 진행될 수 있는지 파악하는 것이다.

Claude Code v2.1.318에 대한 타당한 평가는 여전히 그 증거에 따라 달라진다. 릴리스는 살펴볼 가치가 있는 구체적인 개선 사항을 설명한다. 그러나 주변 워크플로를 평가하거나 결과 코드의 검증 필요성을 없애지는 않는다.

업데이트 후 살펴볼 점

다음으로 유용한 신호는 복구 증거, 측정 가능한 위임 결과, 더 명확한 환경 간 계약이다.

먼저 사용자가 중단된 워크플로에 관한 재현 가능한 결과를 게시하는지 살펴봐야 한다. 강력한 증거에는 실패를 유발한 조건과 업그레이드 후 관찰된 동작이 포함된다. 모든 것이 좋아진 것 같다는 단순한 진술은 진단적 가치가 낮다.

성공적인 재현 뒤 깔끔한 복구가 이루어진다면 관련 수정에 대한 근거가 강화된다. 일치하는 조건에서 동일한 실패가 보고되면 근거가 약화된다. 서로 다른 구성에서 나온 보고는 어느 결론을 뒷받침하기 전에 조사가 필요하다.

둘째, 완전한 작업 결과를 포함하는 노력 선택 평가를 살펴봐야 한다. 의미 있는 비교는 허용 가능한 결과, 검토 필요성, 수정 작업을 함께 검토한다. 리소스 배분만 측정하면 핵심 생산성 질문은 답을 얻지 못한다.

제한된 작업이 적은 배분 노력으로도 허용 가능한 품질을 유지한다면, 의도적인 위임은 정당화하기 쉬워진다. 검토 부담이 증가한다면 겉보기 이점은 줄어든다. 어느 결과든 모든 작은 작업에는 최소 배분이 적합하다고 가정하는 것보다 더 많은 정보를 제공한다.

셋째, Anthropic과 경쟁 공급업체가 실행 환경 간 전환을 어떻게 문서화하는지 살펴봐야 한다. 명확한 계약은 사용자가 적용되는 신원, 권한, 작업 상태를 이해하도록 도와야 한다. 이러한 세부 사항 없이 연속성을 강조하는 제품 발표는 중요한 운영 질문을 해결하지 못한 채 남긴다.

더 정확한 문서는 조직이 지속 세션을 책임감 있게 통합할 수 있다는 신뢰를 높일 것이다. 반복되는 모호함은 구매자에게 여전히 상당한 현지 보조 체계가 필요하다는 점을 시사한다. 관련 신호는 지원되는 인터페이스 수가 아니라 활용 가능한 세부 정보다.

이러한 관찰은 팀의 실제 배포 패턴을 따라야 한다. 워크스테이션 사용자와 인프라 소유자는 서로 다른 증거를 우선시한다. 둘 다 개선된 AI에 대한 추상적 기대가 아니라 정의된 워크플로에 따라 업데이트를 판단함으로써 이점을 얻는다.

무인 사용을 확대하기 전에 대표적인 워크플로를 선택하고 완료의 의미를 문서화하라. 예상 산출물, 검토 경계, 실행이 중단될 때 책임질 사람을 포함하라. Claude Code v2.1.318 설치 후 관찰된 결과를 그 계약과 비교하라.

평가를 그것이 지원하는 작업에 연결해 두어야 한다. 에이전트가 개입을 필요로 했던 지점과 결과 산출물이 계속 이해 가능한 상태였는지 기록하라. 이러한 결과를 자격 증명, 권한, 통합을 유지하는 사람들과 공유하라. 그런 다음 증거를 바탕으로 어떤 작업에 추가 위임이 필요한지 결정하라. 현재 워크플로에서 가장 큰 불확실성을 만드는 경계는 무엇인가? 작업 자체, 그 작업의 권한 부여, 아니면 완료되었음을 알리는 신호인가?