Gemini CLI 릴리스 v0.65.0, 워크스페이스 및 세션 안정성 문제 해결

Google의 Gemini CLI 릴리스 v0.65.0은 워크스페이스 설정을 덮어쓰거나 재개한 대화 기록을 삭제할 수 있었던 문제를 해결합니다. 2026년 10월 20일에 공개된 이번 업데이트는 중복 도구 응답, 인증 호환성, 터미널 스크롤도 대상으로 합니다. 그 중요성은 AI 답변 그 자체보다 그 주변의 작업에 있습니다. 즉, 설정을 보존하고 이전 작업을 재구성하며 개발자의 작업 맥락을 온전히 유지하는 일입니다.

핵심적인 긴장은 편의성과 신뢰할 수 있는 상태 관리 사이에 있습니다. 상태란 애플리케이션이 구성, 대화, 완료된 작업에 관해 보존하는 정보를 뜻합니다. 생성한 코드가 그럴듯해 보이더라도 이 정보가 예기치 않게 바뀐다면 코딩 어시스턴트를 신뢰하기는 더 어려워집니다. 이번 릴리스는 눈에 잘 띄지 않는 이러한 책임에 초점을 맞춥니다.

Claude Code는 문서에서도 권한과 실행 경계를 명시적인 제품 고려 사항으로 다루기 때문에 유용한 비교 대상입니다. 그러나 이번 릴리스가 경쟁 구도의 우열을 입증하는 것은 아닙니다. 당면한 과제는 Gemini CLI 유지관리자와 이를 도입하는 팀에 있습니다. 문서화된 수정 사항은 일상적인 중단 상황에서도 예측 가능한 동작으로 이어져야 합니다.

Gemini CLI 릴리스 v0.65.0에서 실제로 바뀌는 점

이번 업데이트의 가장 분명한 주제는 구성 변경, 세션 복구, 인터페이스 상호작용 전반에서 개발자의 작업 환경을 보존하는 것입니다.

공개된 릴리스 변경 사항에는 신뢰되지 않은 워크스페이스 설정, 세션 복구 중 중복 응답, 빠른 종료 뒤 기록 삭제에 대한 수정이 명시되어 있습니다. 또한 인증 검증과 Ctrl+O로 출력을 확장할 때 불필요하게 터미널을 지우는 문제도 포함됩니다.

이러한 변경은 애플리케이션의 서로 다른 부분에 영향을 미칩니다. 구성은 프로젝트의 동작 방식을 결정합니다. 대화 기록은 이전 작업을 기록합니다. 인증은 외부 서비스를 연결합니다. 터미널 출력은 어시스턴트를 감독하는 사람이 무슨 일이 일어났는지 파악하도록 돕습니다.

릴리스의 중요성을 판단하는 독자에게 이러한 분포는 버전 번호만으로 얻을 수 있는 정보보다 더 유용합니다. 특히 저장된 대화와 프로젝트별 설정을 활용하는 기존 워크플로에 맞춰 평가할 가치가 있는 업데이트임을 시사합니다.

릴리스 노트에는 변경 로그 유지관리, 나이틀리 버전 상향, 저장소 워크플로 수정도 담겨 있습니다. 이러한 항목은 릴리스 운영에 속합니다. 코딩 지능의 별도 개선이나 새로운 모델 기능의 증거로 해석해서는 안 됩니다.

안정 릴리스 번호와 나이틀리 버전 문자열 역시 서로 다른 내용을 설명합니다. 전자는 현재 논의 중인 공개 패키지를 식별합니다. 후자는 이 패키지의 개발 이력에 포함된 항목으로 등장합니다.

팀이 업그레이드 결정을 기록할 때 이러한 구분은 중요합니다. 유용한 평가는 설치된 버전, 환경, 확인 중인 동작을 함께 필요로 합니다. 나중에 문제를 재현할 때 기억에 의존한 발표 날짜는 훨씬 덜 도움이 됩니다.

터미널 변경은 겉보기에 사소한 인터페이스 작업이 왜 같은 논의에 속하는지 보여 줍니다. 출력 확장은 점검 작업입니다. 개발자가 자신의 위치를 더 어렵게 복구하게 만들지 않으면서 정보를 검토하도록 도와야 합니다.

더 넓은 해석은 간단합니다. 어시스턴트의 유용성은 프롬프트에 답하는 모델뿐 아니라 그 주변 애플리케이션에도 좌우됩니다. 이는 Google이 새로운 전략 방향을 발표했다는 주장이 아니라 변경 사항에 대한 편집적 평가입니다.

또한 발표가 입증할 수 있는 범위에는 실질적인 한계가 있습니다. 릴리스 항목은 의도된 수정 사항을 문서화합니다. 원래 실패가 사용자 전반에서 얼마나 자주 발생했는지는 측정하지 않습니다.

따라서 개발자는 자신의 설치 환경에서 나열된 모든 문제가 발생했다고 가정하지 않고도 이러한 수정 사항을 점검할 근거를 가집니다. 관련 워크플로를 사용하는 팀은 코드 생성 점수 향상을 찾는 독자보다 이번 업데이트를 평가할 더 구체적인 이유가 있습니다.

가장 중요한 변경 사항은 실패 방식이 서로 다르므로 별도로 살펴볼 가치가 있습니다. 워크스페이스 보호는 애플리케이션이 무엇을 쓸 수 있는지와 관련됩니다. 세션 복구는 이전에 저장한 작업이 보존되고 정확하게 돌아오는지와 관련됩니다.

워크스페이스 신뢰는 구성 쓰기도 관리해야 합니다

프로젝트 설정을 비활성화하면서도 저장 파일 위치를 통한 파괴적 쓰기는 허용한다면 신뢰 경계는 불완전합니다.

워크스페이스는 어시스턴트가 작동하는 프로젝트 디렉터리입니다. 워크스페이스 신뢰는 애플리케이션이 해당 프로젝트의 로컬 구성을 승인된 것으로 취급할지를 결정합니다.

워크스페이스 설정 수정에 따르면 신뢰되지 않은 프로젝트는 메모리에서 빈 구성 표현을 받았습니다. 이 표현은 설정 파일의 위치를 유지했고 쓰기 가능한 상태였습니다.

그 결과 워크스페이스 범위의 구성 명령이 빈 표현을 기존 설정 위에 저장할 수 있었습니다. 수정 사항은 해당 표현을 읽기 전용으로 만들고 구성 변경이 발생하기 전에 영향을 받는 쓰기를 차단합니다.

기여자는 거부된 프로젝트 수준 변경과 기존 파일 보존을 다루는 테스트도 설명합니다. 사용자 범위 설정은 계속 작동하며, 신뢰를 설정하면 일반적인 워크스페이스 쓰기 권한이 복원됩니다.

중요한 차이는 구성을 무시하는 것과 보존하는 것 사이에 있습니다. 이 책임들은 관련되어 있지만 서로 바꿔 쓸 수는 없습니다. 소프트웨어는 파일 활성화를 올바르게 거부하면서도 이후 작업 중 해당 파일을 잘못 처리할 수 있습니다.

낯선 저장소를 살펴보는 가상의 개발자를 생각해 봅시다. 이 개발자는 구성을 승인하지 않았으며 프로젝트 수준 통합 설정을 변경하려 합니다. 이때 명시적인 거부 또는 의도적인 신뢰 결정이 나올 것이라고 기대하는 것이 합리적입니다.

관련 없는 설정을 조용히 교체한다면 그 기대를 저버리게 됩니다. 개발자의 명령은 제한된 의도를 표현하지만, 결과로 발생하는 파일 변경은 훨씬 더 광범위한 영향을 미칩니다.

이 사례는 모든 낯선 저장소에 유해한 구성이 포함되어 있다고 주장하지 않으면서도 위험성을 설명합니다. 우려의 대상은 제한된 조건에서 예측 가능한 애플리케이션 동작입니다.

명시적인 오류는 마찰을 유발하지만, 개발자가 내려야 할 결정을 식별해 줍니다. 이 프로젝트를 신뢰해야 할까요? 변경을 사용자에게 적용해야 할까요? 구성을 그대로 두어야 할까요?

이러한 선택은 어시스턴트를 운용하는 사람에게 속합니다. 빈 임시 표현이 예기치 않은 파일 덮어쓰기를 통해 이를 간접적으로 결정해서는 안 됩니다.

플랫폼 팀에게 이 시사점은 평가 설계로도 확장됩니다. 도구는 승인된 작업을 완료할 때뿐 아니라 작업을 거부할 때도 평가되어야 합니다.

성공적인 거부에는 관찰 가능한 특성이 있습니다. 기존 데이터가 그대로 유지됩니다. 이유를 이해할 수 있습니다. 애플리케이션이 부분적으로 적용된 구성 변경을 남기지 않습니다.

이는 릴리스에 관한 추가 주장이 아니라 제안된 승인 기준입니다. 팀이 자체 환경에서 문서화된 수정을 구체적으로 해석할 수 있는 방법을 제공합니다.

같은 논리는 내부 문서에도 적용됩니다. 배포 가이드는 모두에게 프롬프트를 수락하라고 지시하기보다 프로젝트 신뢰와 구성 범위의 관계를 설명해야 합니다.

이러한 맥락을 유지하는 팀은 검색 가능한 지식 베이스에 결정을 보관할 수 있습니다. 유용한 기록은 경계가 존재하는 이유와 이에 의존하는 워크플로를 설명합니다.

이 문서화가 권한을 강제할 수는 없습니다. 그러나 업그레이드 뒤 동작이 바뀌었을 때 검토자가 예상된 거부와 회귀를 구별하도록 도울 수 있습니다.

세션 복구에는 정확성과 보존이라는 별개의 문제가 있습니다

복구된 대화는 디스크에 보존되어야 할 뿐 아니라 중복 응답을 추가하지 않고 이전 도구 활동을 재구성해야 합니다.

세션 재구성 수정은 기록된 대화가 재개될 때 중복되는 도구 응답을 해결합니다. 도구 응답은 어시스턴트가 외부 작업을 요청한 뒤 반환되는 결과입니다.

기여자에 따르면 복구 과정은 이미 기록된 응답을 재생하는 동시에 저장된 도구 호출 결과에서 또 다른 응답을 생성할 수 있었습니다. 변경 사항은 대체 응답을 생성하기 전에 기존 응답을 확인합니다.

또한 교환 내에서 중복 응답 식별자를 필터링하고 이전 기록을 위한 대체 동작을 유지합니다. 설명된 테스트는 최신 기록, 이전 형식, 병렬 호출, 중복 필터링을 다룹니다.

이는 외부 명령이 반드시 두 번 실행되었다는 증거가 아니라 재구성에 관한 문제입니다. 어시스턴트의 맥락에서 과거 응답을 반복하는 일은 기반 작업을 다시 실행하는 일과 다릅니다.

이 구분은 수정을 해석하는 데 필수적입니다. 부정확한 대화 기록은 애플리케이션이 파일시스템 변경이나 외부 요청을 중복 수행했다는 사실을 입증하지 않고도 혼란을 초래할 수 있습니다.

보존은 별개의 문제입니다. 기록 보존 수정은 사용자가 대화를 재개한 뒤 다른 프롬프트를 제출하기 전에 빠르게 종료하면 저장된 대화가 삭제되는 문제를 설명합니다.

기여자는 재개된 세션 추적과 초기화 과정과의 조정을 수정의 일부로 언급합니다. 초기화는 애플리케이션의 작업 데이터를 준비하는 시작 과정입니다.

또한 이 변경은 메모리에 아직 신뢰할 수 있는 대화 정보가 없을 때 저장된 데이터를 확인하는 방식을 설명합니다. 이 메커니즘은 비어 있는 새 세션과 아직 로드 중인 기존 세션의 차이를 겨냥합니다.

가상의 아침 워크플로는 이 차이를 구체적으로 보여 줍니다. 개발자가 주제를 확인하려고 어제 대화를 열었지만 잘못된 대화를 선택했다는 사실을 깨닫고 즉시 닫습니다.

그 행동이 어제의 작업을 폐기할 권한을 의미해서는 안 됩니다. 기록을 열었다가 떠나는 것은 유용한 내용이 전혀 없었던 빈 기록을 만드는 것과 다릅니다.

정확성은 또 다른 측면에서도 중요합니다. 조사를 다시 시작하는 개발자는 제안된 작업, 완료된 작업, 그리고 그 작업이 산출한 결과를 구분해야 합니다.

실패한 검사 뒤 성공적인 수정이 이어지는 대화를 상상해 보십시오. 복구 과정이 요청과 결과의 관계를 왜곡하면 다음 권고를 평가하기가 더 어려워집니다.

이는 신뢰할 수 없는 기록에서 비롯되는 분석적 결과이지, 이번 릴리스가 측정한 결과는 아닙니다. 이용 가능한 자료는 이후 답변 품질이나 절약된 시간을 수치화하지 않습니다.

그럼에도 평가의 교훈은 분명합니다. 팀은 대화 창이 열리는지만으로 복구를 판단하지 말고, 복구된 증거를 점검해야 합니다.

또한 대화 기록을 완전한 감사 기록으로 취급하지 않아야 합니다. 저장된 교환은 유용한 맥락을 제공할 수 있지만, 코드 변경과 실제 명령 결과를 통해 여전히 확인해야 합니다.

Gemini CLI 릴리스 v0.65.0에서 이러한 수정은 중단 처리 방식을 구체적인 검토 주제로 만듭니다. 핵심 질문은 익숙한 작업이 온전하게 돌아오고 계속 이해 가능한 상태로 유지되는지입니다.

인증 호환성에는 정확한 검증이 필요합니다

클라이언트가 서버가 선언한 기능보다 더 광범위하게 인증 요구 사항을 적용하면 정상적인 연결이 거부될 수 있다.

OAuth는 애플리케이션이 사용자의 비밀번호를 직접 수집하지 않고도 접근 권한을 얻을 수 있게 하는 인가 프레임워크다. 리디렉션 응답에는 인가 서버를 식별하는 값인 iss가 포함될 수 있다.

issuer validation change는 서버 메타데이터가 지원을 명시적으로 선언한 경우에만 해당 응답 파라미터를 필수로 만든다. 메타데이터는 서버의 기능을 설명하는 기계 판독 가능 정보다.

기여자에 따르면 Gemini CLI는 응답에 issuer가 포함될 때마다 계속 이를 검증한다. 따라서 이 수정은 누락되어도 되는 선택적 값과, 제공될 경우 기대값과 일치해야 하는 값을 구분한다.

이 풀 리퀘스트는 영향을 받는 사례로 Notion MCP 인증을 지목한다. MCP(Model Context Protocol)는 어시스턴트가 외부 도구 및 데이터에 연결할 수 있는 공통 방식을 제공한다.

작성자는 서버가 issuer를 게시했지만 issuer 파라미터 반환 지원은 선언하지 않았을 때 실패가 발생했다고 설명한다. 이 사례는 호환성 문제를 설명하지만, 실제로 몇 명의 사용자가 이를 겪었는지는 보여주지 않는다.

제품 측면에서의 교훈은 더 엄격한 동작에는 정확한 정의가 필요하다는 점이다. 적용되는 프로토콜이 해당 정보를 선택 사항으로 취급한다면, 더 많은 정보를 요구한다고 해서 자동으로 더 나은 것은 아니다.

반대로 선택적 필드가 없는 것을 허용한다고 해서 잘못된 필드까지 허용한다는 뜻은 아니다. 존재, 부재, 불일치는 서로 다른 조건이다.

이 구분은 통합 책임자가 검토 과정에서 더 나은 질문을 던지게 한다. 클라이언트는 어떤 서버 기능에 의존하며, 응답의 통과 여부는 어떤 근거로 판단되는가?

일반적인 로그인 실패 메시지는 이런 세부 사항을 숨긴다. 개발자는 문제가 계정 접근, 서비스 가용성, 혹은 구현 가정의 비호환성 중 무엇과 관련됐는지 알기 어렵다.

성공적인 연결 역시 평가의 일부일 뿐이다. 팀은 연결이 예상한 서비스에 도달하고 의도한 접근 권한을 부여하는지도 확인해야 한다.

이는 제안된 검토 우선순위다. 릴리스 출처는 독립적인 보안 평가나 외부 서비스 전반에 대한 포괄적 호환성 조사를 제공하지 않는다.

워크스페이스 신뢰와의 연결은 기계적 관계가 아니라 개념적 관계다. 두 변경 모두 선언된 조건을 올바른 애플리케이션 동작으로 변환하는 데 의존한다.

워크스페이스에서 선언된 조건은 프로젝트가 신뢰할 수 있는지 여부다. 인가에서는 서버가 특정 응답 기능을 알리는지 여부다.

소프트웨어가 불완전한 표현을 완전한 지시로 취급할 때 문제가 발생한다. 빈 구성은 의도치 않은 대체로 이어질 수 있다. issuer 선언은 지나치게 광범위한 콜백 요구 사항으로 바뀔 수 있다.

이 비교는 관련 없는 메커니즘을 하나의 기술적 주장으로 결합하지 않으면서 릴리스를 설명하는 데 도움이 된다. 수정 사항은 서로 다른 코드 경로에서 작동하며 별도의 검증이 필요하다.

연결된 서비스에 의존하는 팀에 즉각적인 시사점은 목표를 좁힌 평가다. 이전에 실패했던 인가 흐름은 서비스 구성 및 예상 권한을 기록한 상태에서 다시 점검할 가치가 있다.

인증이 이제 보편적으로 신뢰할 수 있다는 더 광범위한 선언은 근거를 넘어선다. 문서화된 변경 사항은 특정 검증 규칙에 관한 더 좁고 유용한 결론을 뒷받침한다.

신뢰성은 순위 없이도 경쟁의 문제다

코딩 어시스턴트를 선택하는 팀에는 생성된 코드에 대한 근거와 함께 중단, 권한, 복구에 대한 근거도 필요하다.

Anthropic의 permission architecture는 관련된 경쟁 맥락을 제공한다. 해당 문서는 구성 가능한 권한 모드와 샌드박싱을 통한 파일시스템 및 네트워크 격리를 설명한다.

샌드박싱은 정의된 경계 밖의 리소스에 대한 프로세스의 접근을 제한하는 것을 뜻한다. 권한 제어는 선택한 구성에서 어떤 작업에 승인이 필요한지를 결정한다.

이는 공급업체가 문서화한 기능이지, Claude Code가 모든 원치 않는 작업을 막는다는 독립적인 증거는 아니다. 다만 실행 경계가 경쟁 제품 설계의 명시적인 부분임을 보여준다.

비교는 의도적으로 제한적이다. Gemini CLI의 워크스페이스 설정 수정은 모든 Claude Code 권한 설정에 직접 대응하지 않는다.

또한 출처는 어느 어시스턴트가 결함이 더 적은지, 복구가 더 나은지, 운영 오버헤드가 더 낮은지도 입증하지 않는다. 이러한 판단에는 버전과 환경 전반에 걸친 비교 가능한 테스트가 필요하다.

공정한 비교라면 각 도구를 동일한 관련 워크플로에 적용해야 한다. 여기에는 검사할 프로젝트, 허용된 작업, 연결된 서비스, 그리고 도입되는 중단 상황이 포함된다.

결과물에는 작업 완료 여부 이상의 정보가 포함되어야 한다. 검토자는 무엇이 변경됐고, 무엇이 저장된 채 남았으며, 이후 운영자가 무엇을 해결해야 했는지 이해할 필요가 있다.

이는 구매 논의를 팀이 직접 관찰할 수 있는 작업으로 옮긴다. 수용 가능한 패치를 생성하는 도구라도 로컬 파일과 유지되는 맥락에 대한 조직의 기대에 부합해야 한다.

이 부담은 공유 기본값을 책임지는 엔지니어링 관리자에게 특히 구체적이다. 이들의 결정은 릴리스 노트를 읽거나 구현 논의를 살펴보지 않을 수 있는 동료에게도 영향을 미친다.

그런 관리자는 인수인계 과정에서도 유지되는 예상 동작에 대한 설명이 필요하다. 문서화된 경계는 지원 담당자가 사용자 혼란과 제품 문제를 구분하는 데 도움이 된다.

개별 개발자도 같은 책임의 더 작은 형태를 맡는다. 이들은 프로젝트를 신뢰할지, 이전 조사를 재개할지, 다른 서비스를 연결할지를 결정한다.

예측 가능한 어시스턴트는 그러한 결정 주변의 모호성을 줄인다. 여기서 예측 가능성이란 명시적인 규칙과 일치하고 사후에 확인할 수 있는 동작을 의미한다.

Gemini CLI Release v0.65.0에 대한 회의적인 해석은 여전히 필요하다. 상세한 수정 사항은 유지 관리자가 확인된 문제를 해결하고 있음을 보여주지만, 관련 문제가 없다는 사실을 입증하지는 않는다.

기여자의 설명과 목표가 명확한 테스트는 의도와 적용 범위에 관한 유용한 근거다. 그러나 실제 사용될 환경에서 릴리스 패키지를 관찰하는 일을 대체하지는 못한다.

또한 이 업데이트에 생산성 향상 비율을 부여할 근거도 없다. 잃어버린 대화를 피하는 것은 분명 실질적인 가치가 있지만, 그 누적 영향은 측정되지 않았다.

적절한 결론은 시장의 판정보다 더 좁다. 이 릴리스는 Gemini CLI 사용자에게 평가할 수 있는 구체적인 신뢰성 변경 사항을 제공하며, 경쟁 도구에는 일관된 비교 기준을 제시한다.

업데이트 후 주시할 사항

가장 강력한 후속 근거는 재현 가능한 동작, 보존된 기록, 그리고 이 수정 사항이 겨냥한 조건을 명확히 처리하는 방식에서 나올 것이다.

첫 번째로 살펴볼 신호는 제한된 작업이 거부될 때 워크스페이스 구성이 그대로 유지되는지 여부다. 이는 설정 수정에서 설명한 경계를 직접 테스트한다.

팀 평가에서는 문서화된 재현 절차에 원래 구성, 신뢰 상태, 시도한 작업, 그리고 결과 파일을 담아야 한다. 그래야 결과를 검토할 수 있다.

작업이 깔끔하게 중단되고 관련 없는 설정이 보존된다면 의도한 동작을 뒷받침한다. 구성이 여전히 예기치 않게 바뀐다면 문제의 범위를 추가로 조사해야 한다.

두 번째 신호는 재개된 대화가 중단 상황 전반에서 계속 이용 가능하고 일관되게 유지되는지 여부다. 이용 가능성과 일관성은 서로 다른 질문에 답하므로 별도로 고려해야 한다.

저장된 기록이 살아남더라도 잘못 복원된다면 여전히 불확실성을 만든다. 나중에 빠르게 종료했을 때 저장 이력이 사라진다면, 완벽하게 복원된 대화도 마찬가지로 도움이 되지 않는다.

따라서 유용한 후속 보고서는 디스크에 무엇이 남았는지와 복구 후 무엇이 나타났는지를 모두 설명해야 한다. 재개가 “작동했다”는 모호한 진술은 중요한 동작을 설명하지 못한다.

관련 워크플로가 안정적으로 유지된다면 릴리스 도입에 대한 신뢰가 높아진다. 이전 기록이나 빠른 종료와 관련된 재현 가능한 실패는 이러한 평가를 약화시킨다.

세 번째 신호는 영향을 받는 외부 인가 흐름이 실제로 광고하는 서버 기능 아래에서 성공하는지 여부다. 이는 평가를 문서화된 호환성 문제와 연결해 둔다.

통과 결과는 지원되는 연결을 허용하면서도 의도한 접근 경계를 보존해야 한다. 관련 없는 권한 변경으로 얻은 성공은 다른 질문에 답하는 것이다.

보고서는 인증과 이후 도구 동작도 구분해야 한다. 서비스에 연결된다고 해서 그 서비스가 노출하는 모든 작업이 올바르게 작동한다는 뜻은 아니다.

앞으로 수개월 동안 후속 수정과 상세한 사용자 보고서는 남은 범위를 명확히 하는 데 도움이 될 수 있다. 가장 유용한 보고서는 광범위한 승인이나 비판보다 버전과 조건을 식별할 것이다.

이러한 관찰 지점은 Google이 약속한 이정표가 아니라 제안된 평가 기준이다. 목적은 릴리스 발표를 관찰 가능한 답을 가진 질문으로 바꾸는 데 있다.

또한 팀이 어느 한쪽으로 과도하게 반응하지 않도록 돕는다. 결함 보고는 보편적인 실패를 입증하지 않으며, 성공적인 시연은 보편적인 신뢰성을 입증하지 않는다.

기존 사용자에게 이 업데이트는 문서화된 수정 사항이 일상 업무와 겹치는 지점에서 가장 관련성이 높다. 저장된 조사 기록, 프로젝트 구성, 연결된 서비스는 이를 평가할 구체적인 장소를 제공한다.

팀이 가장 의존하는 워크플로부터 시작한 뒤 Gemini CLI Release v0.65.0 도입 전후에 어떤 일이 발생하는지 기록하라. 비교할 수 있도록 프로젝트 구성, 예상 권한, 저장된 대화를 유지하라. 세션에 대한 자신의 기억에 의존하지 않고 동료에게 결과를 검토해 달라고 요청하라. 경계가 작업을 중단시킨다면 설명이 타당한지, 기존 정보가 그대로 남아 있는지 확인하라. 대화가 재개된다면 기록된 작업을 실제 기반 작업과 비교하라. 이러한 관찰을 바탕으로 업데이트가 환경에 맞는지 결정하라. 팀이 복구하는 데 가장 큰 비용이 드는 중단은 무엇이며, 릴리스된 패키지는 이를 예측 가능하게 처리하는가?