Spawn 자율 에이전트, 게임 개발을 라이브 세계로 옮기다
보도에 따르면 Spawn 자율 에이전트는 멀티플레이어 게임 플랫폼을 매시간 업데이트하며, 소프트웨어 개발을 이미 그 안에서 플레이하는 사람들에게 더 가깝게 끌어온다. 창립자 Jacob Sansbury는 AI 에이전트, 즉 행동을 선택하고 도구를 사용하는 소프트웨어가 제품 유지 관리를 자율적으로 지원하는 시스템을 설명한다. 긴장은 즉각적이다. 피드백 주기가 짧아질수록 어떤 변경을 할지 결정하는 시스템의 책임은 더 커진다.
10월 29일자 자율 게임 개발 게시물에서 Simon Willison은 Spawn의 게임 내 어시스턴트 Savi를 통해 성과 탈 수 있는 드래곤을 만들었다고 설명한다. 그의 경험은 제품이 내세우는 대화형 제작의 전제를 뒷받침한다. 그러나 그 이면의 엔지니어링 운영이 얼마나 안정적으로 작동하는지는 독립적으로 입증하지 않는다.
Roblox는 더 넓은 방향성을 이해하는 데 유용한 기준점이다. 즉, 언어를 통해 인터랙티브 세계를 더 쉽게 만들게 하는 것이다. 보도된 Spawn의 접근 방식은 이 야심을 소프트웨어 운영 자체로 확장한다. 핵심적인 상충 관계는 플레이어에게 즉시 대응하는 일과 그들이 신뢰할 수 있는 공유 세계를 보존하는 일 사이에 있다. 개발자는 자율 개발을 인력 운영 공식으로 받아들이기 전에 이 균형을 검토해야 한다.
Spawn 자율 에이전트는 플레이어 경험과 개발을 연결한다
게임 내부에서 무언가를 만드는 일과 그 아래의 플랫폼을 바꾸는 일은 구분할 필요가 있다. 플레이어가 다른 풍경을 요청하는 것은 창작 도구를 사용하는 일이다. 엔지니어링 에이전트가 공유 플랫폼의 동작을 바꾸는 것은 다른 사람들의 경험에 대한 권한을 행사하는 일이다. 이 활동들은 채팅 창에서는 비슷해 보일 수 있지만, 서로 다른 권한과 근거를 요구한다.
중요한 주장은 플레이어 경험이 자율 엔지니어링 프로세스에 직접 반영된다는 점이다. Willison이 전한 Sansbury의 설명에 따르면, 에이전트는 운영 문제와 Savi가 생성한 버그 보고서를 받는다. 보도된 프로세스는 이슈 탐지, 진단, 구현, 배포를 더 가깝게 연결한다. 그 효과는 독립적으로 검증되지 않았다.
이러한 구성은 불만 제기의 역할을 바꾼다. 전통적인 제품 워크플로에서는 플레이어가 문제를 설명하고 누군가가 이를 해석할 때까지 기다린다. 에이전트 기반 워크플로는 주변 상호작용 맥락을 조사 과정으로 가져갈 가능성이 있다. 엔지니어링 측면의 질문은 그 맥락이 실제 결함을 식별하는지, 아니면 그럴듯한 설명을 더 쉽게 만들어 내는 데 그치는지다.
가령 한 플레이어가 다리가 이상하게 느껴진다고 말하는 상황을 생각해 보자. 불만은 외관, 충돌 동작, 이동 속도 또는 다른 참가자가 길을 막는 문제와 관련될 수 있다. 유용한 시스템이라면 변경을 적용하기 전에 이러한 가능성을 구분해야 한다. 잘못된 해석에 빠르게 대응하면 원래 대화에서는 반응성이 있어 보이면서도 새로운 문제를 만들 수 있다.
같은 구분은 기능 요청에도 적용된다. 플레이어가 더 쉬운 도전을 요청하는 것은 반드시 결함을 뜻하는 것이 아니라 선호를 표현하는 것이다. 다른 플레이어는 기존 난이도를 더 높이 평가할 수 있다. 피드백을 변경으로 전환하는 시스템에는 누구의 선호가 기준이 되는지에 대한 명확한 설명이 필요하다. 그렇지 않으면 발언한 사람의 편의가 우연히 제품 정책이 된다.
멀티플레이어 환경에서는 판단의 층위가 하나 더 추가된다. 지역적 변경도 변경을 유발한 대화에 참여하지 않은 사람들에게 영향을 줄 수 있다. 플랫폼은 요청이 개인 창작물, 공유 세션 또는 공통 기능에 관한 것인지 판단해야 한다. 이러한 경계는 어시스턴트가 요청을 받아들이는 동안 얼마나 자연스럽게 들리는지보다 더 중요하다.
Spawn의 공개 제품 설명은 대화를 통해 게임을 만들고 처음부터 멀티플레이어를 제공하는 데 초점을 맞춘다. 이러한 포지셔닝은 즉각적인 반복이 제품 경험의 일부인 이유를 보여 준다. 동시에 안정성도 창작 약속의 일부가 된다. 플레이어는 자신이 만든 작업의 의미가 예측할 수 없이 바뀐다면 함께 자신 있게 구축할 수 없다.
따라서 이 뉴스는 인터페이스만큼이나 개발 경계에 관한 이야기다. 대화형 제작은 사용자에게 보인다. 자율 유지 관리는 그들의 경험 뒤에서 작동한다. 같은 어시스턴트가 이들을 연결하더라도 플랫폼을 평가하려면 두 계층을 분리해 보아야 한다.
크리에이터 플랫폼은 전체 피드백 주기를 단축해야 한다는 압박에 직면한다
가장 뚜렷한 압박을 받는 팀은 더 쉬운 제작을 판매하면서 그 이후에 발생하는 모든 문제의 진단 책임은 사용자에게 남겨 두는 팀이다. 객체 생성은 누군가가 시작하는 데 도움을 준다. 왜 그것이 잘못 작동하는지 이해하는 일은 계속할 수 있게 돕는다. 두 과제를 모두 다루는 플랫폼은 크리에이터와 다른 관계를 제공한다.
더 빠른 제작은 더 빠른 수정에 대한 기대를 높인다. 사용자가 대화로 아이디어를 설명할 수 있게 되면 복잡한 보고 절차는 나머지 경험과 동떨어져 보인다. 그렇다고 모든 수정을 자동화해야 할 의무가 생기는 것은 아니다. 다만 제작, 실패, 지원 사이의 맥락을 보존해야 한다는 압박은 생긴다.
Roblox는 2025년 3월 Cube 3D generation을 소개하며 중요한 기준점을 마련했다. 이 회사는 텍스트로 3차원 객체를 생성하는 방식을 설명하고, 더 기능적이고 인터랙티브한 창작물에 대한 목표를 제시했다. 이는 Spawn과의 현재 성능 비교가 아니라 언어 기반 게임 제작의 역사적 맥락을 제공한다.
관련 비교는 지원 범위에 있다. 객체 생성은 에셋 제작 작업을 다룬다. 인터랙티브 창작에는 동작, 일관성, 그리고 문제가 발생했을 때 유용한 피드백도 필요하다. 자율 플랫폼 엔지니어링은 이러한 경험을 뒷받침하는 환경에 변경을 제안함으로써 더 나아간다. 각각의 확장은 서로 다른 책임을 도입한다.
따라서 Spawn과 Roblox의 비교는 이러한 책임을 하나의 점수로 축소하지 않아야 한다. 설득력 있는 창작 시연이 플랫폼 가용성을 측정하는 것은 아니다. 유용한 에셋 생성기가 자율 유지 관리 역량을 입증하는 것도 아니다. 두 제품의 공개 포지셔닝 모두 동등한 프로젝트 전반의 크리에이터 성공을 통제된 방식으로 비교하지는 않는다.
기존 플랫폼이 마주한 전략적 질문은 대화형 지원이 어디에서 멈춰야 하는가다. 지원은 수정을 제안할 수도, 크리에이터의 프로젝트를 수정할 수도, 공유 기능의 변경을 요청할 수도 있다. 이러한 경계를 넘으려면 더 강한 권한 부여와 검증이 필요하다. 압박은 사용자 기대에서 오고, 제약은 행동의 결과에서 나온다.
소규모 개발팀에게 매력적인 점은 조직 운영 측면이다. 사용자 피드백과 엔지니어링 관심 사이에 지속적인 간극이 있으면 수정 가능한 문제가 해결되지 않은 채 남을 수 있다. 에이전트는 더 많은 피드백을 조사할 수 있는 가능성을 제공한다. 하지만 그 결과물이 추가 유지 관리가 아니라 마찰을 줄일 때에만 조사 확대가 도움이 된다.
개발자는 생산성의 정의가 바뀌는 상황에도 직면한다. 코딩 작업을 완료한 횟수는 반복 세션에 걸쳐 만족스러운 게임을 유지하는 일보다 세기 쉽다. 자율 작업이 늘어난다면 팀에는 엔지니어링 활동을 플레이어 결과와 연결하는 지표가 필요하다. 그렇지 않으면 바쁘게 움직이는 시스템이 성공적으로 보이는 동안 사용자의 신뢰는 낮아질 수 있다.
결국 경쟁 압박은 매력적인 세계를 생성하는 것보다 더 넓은 범위에 걸쳐 있다. 이는 초기 시연 이후에도 크리에이터가 그 세계를 사용할 수 있도록 돕는 일에 관한 것이다. 즉각적인 제작을 약속하는 플랫폼은 지속적인 책임을 얼마나 신뢰성 있게 떠안을 수 있는지 결정해야 한다.
더 빠른 반복은 검증 쪽으로 책임을 이동시킨다
보도된 Spawn의 개발 접근 방식은 실용적인 전제에 기반한다. 피드백은 그것을 만들어 낸 작업과 너무 멀리 떨어져 도착하면 가치를 잃는다. 그 거리를 줄이면 문제를 더 쉽게 이해할 수 있다. 그러나 가치는 단순히 더 빨리 배포하는 데서가 아니라 변경이 작동했는지 학습하는 데서 나온다.
구현이 빨라질수록 검증은 제한 자원이 된다. 에이전트는 팀이 보고된 동작이 바람직하지 않았는지 알기 전에 그럴듯한 패치를 만들 수 있다. 성공적인 개발 프로세스는 그러한 판단을 위한 시간과 권한을 보존해야 한다. 그렇지 않으면 속도는 불확실성을 줄이기보다 증폭시킨다.
Anthropic이 공개한 효과적인 에이전트 설계 지침은 사전 정의된 워크플로와 모델이 자체 행동을 지시하는 시스템을 구분한다. 필요한 경우에만 복잡성을 높일 것을 권고하며, 응답성과 자원 사용 사이의 상충 관계를 인정한다. 이 지침은 아키텍처적 맥락을 제공할 뿐 Spawn 구현에 대한 독립적 검증은 아니다.
게임 플랫폼에서 검증은 여러 의미를 가진다. 변경은 올바르게 실행되어야 하고, 의도된 동작을 보존해야 하며, 영향을 받는 플레이어가 받아들일 수 있어야 한다. 이러한 요구 사항은 겹치지만 서로 대체할 수는 없다. 더 이상 오류를 내지 않는 다리도 일반적인 플레이 중에는 여전히 건널 수 없을 수 있다.
공유 경험은 고립된 점검만으로 충분하지 않게 만든다. 요청자에게는 작동하는 변경도 다른 플레이어가 도착하거나 재접속하면 실패할 수 있다. 유용한 평가는 원래 대화 밖의 조건을 포함해 중요한 상호작용을 시험해야 한다. 좁은 범위의 점검을 통과했다는 것은 그 좁은 결과만을 입증한다.
여기서 자율 반복의 매력은 더 까다로워진다. 시스템에는 자신의 설명을 넘어 유지되는 완료의 정의가 필요하다. “변경이 적용되었다”는 행동을 설명한다. “플레이어가 의도된 상호작용을 완료할 수 있다”는 결과를 설명한다. 후자는 에이전트의 자신감을 신뢰하는 대신 동작을 관찰해야 한다.
복구에도 유사한 구분이 적용된다. 롤백, 즉 이전 소프트웨어 버전을 복원하는 작업은 결함 있는 구현을 되돌릴 수 있다. 그러나 해당 구현이 작동하는 동안 사용자가 경험한 모든 것을 자동으로 복원하지는 않는다. 변경된 진행 상황, 중단된 세션, 손상된 신뢰는 소프트웨어 자체가 알려진 상태로 돌아가더라도 별도로 고려해야 한다.
그렇다고 느린 개발이 본질적으로 더 안전하다는 뜻은 아니다. 지연된 수정은 알려진 문제가 사용자에게 더 오래 영향을 미치게 할 수 있다. 중요한 질문은 시스템이 어떤 변경을 안전하게 가속할 수 있는지 식별할 수 있는가다. 그러려면 영향 범위, 근거, 그리고 중단할 수 있는 능력에 관한 경계가 필요하다.
따라서 Spawn 자율 에이전트를 검토하는 팀은 코딩 프로세스와 함께 검증 프로세스도 살펴봐야 한다. 이전 가능한 교훈은 행동을 관찰 가능한 결과와 연결하는 것이다. 조직이 성공을 어떻게 인식하고, 피해를 어떻게 감지하며, 잘못된 결정을 어떻게 제한하는지 설명할 수 있을 때 구현 위임은 더 신뢰할 만해진다.
Fable 모델 주장은 작동하는 시연을 넘어서는 근거가 필요하다
Sansbury는 Spawn의 보도된 자율성을 가능하게 한 요소로 Fable 5와 5.1을 꼽는다. 이는 이 특정 운영을 뒷받침하는 모델에 관한 주장이다. 비교 가능한 과제, 평가 조건, 결과 없이 이를 모델 역량의 일반적 순위로 확대해서는 안 된다.
작동하는 제품과 그 성공을 설명하는 검증된 근거는 서로 다른 형태의 증거다. 플레이어는 요청한 상호작용이 일어났음을 확인할 수 있다. 어떤 모델이 엔지니어링 시스템을 가능하게 했는지 확립하려면 주변 도구와 제약에 관한 정보가 필요하다. 보이는 결과만으로는 그러한 기여를 분리할 수 없다.
Spawn의 작동 방식을 논의할 때는 이 구분이 특히 중요해진다. 현재 공개된 설명은 운영 방식에 관한 접근법을 제시하지만, 전체 시스템에 대한 재현 가능한 평가를 제공하지는 않는다. 독자는 독립적인 계획 수립, 제한 없는 권한, 또는 지속적인 신뢰성에 관한 가정으로 그 공백을 메우지 않아야 한다.
모델은 환경 안에서 작동한다. 지침은 목표를 정의하고, 도구는 수행 가능한 행동을 정의하며, 권한은 어떤 결과를 만들어낼 수 있는지를 결정한다. 이후 피드백은 다음에 무엇을 시도할지에 영향을 준다. 따라서 모델 간의 겉보기 차이는 각 모델이 주변 구성에 얼마나 잘 맞는지를 반영할 수도 있다.
설득력 있는 평가는 비교가 의미를 갖도록 그 구성을 충분히 안정적으로 유지해야 한다. 동등한 작업에는 비슷한 접근 권한, 맥락, 수용 기준이 필요하다. 사람의 개입 역시 일관된 정의가 필요하다. 그렇지 않으면 “자율적”이라는 표현이 실질적으로 서로 다른 수준의 감독을 감출 수 있다.
Willison이 10월 28일 별도로 논의한 AI 게임 개발은 유용한 독립적 관점을 제공한다. 그는 AI 지원 실험으로 만들어진 게임을 즐겼다고 설명하면서도 반복 작업과 플레이테스트의 중요성을 인정한다. 이는 해당 매체에 대한 관심을 뒷받침하지만, 무인 플랫폼 유지 관리의 신뢰성을 입증하지는 않는다.
따라서 회의적인 질문은 구체적이다. 실제 플레이를 거친 뒤에도 얼마나 많은 유용한 작업이 유지되는가? 검토 과정에서는 완성된 것처럼 보이는 구현도 의도한 경험을 보존하지 못할 수 있다. 그 격차를 평가하려면 생성된 변경의 양이 아니라 유지된 동작, 해결된 문제, 지속적인 사용을 살펴봐야 한다.
공개 시연에는 선택 편향 문제도 있다. 기억에 남는 성공 사례는 중단된 시도나 모호한 수정 사례보다 전달하기 쉽다. 이 관찰이 부정행위를 입증하거나 시연의 가치를 무효화하는 것은 아니다. 다만 유난히 매력적인 사례보다 대표성 있는 기록이 더 중요하다는 점을 설명한다.
현재 이용 가능한 증거는 Spawn을 자율 게임 엔지니어링 실험으로 설명하는 데는 충분하다. 그러나 특정 모델이 보편적으로 대안을 능가하거나 기존의 감독을 불필요하게 만든다는 점까지 입증하지는 않는다. 이 경계를 분명히 유지하면, 책임 있게 재현할 수 있는 것을 판단하려는 개발자에게 이 이야기가 더 유용해진다.
공유 세계에서는 코딩 능력만큼 권한이 중요하다
멀티플레이어 세계에는 서로 경쟁하는 의도가 존재한다. 누군가는 만들고, 누군가는 탐험하며, 또 다른 누군가는 이미 존재하는 것을 보존하려 한다. 그 환경에 참여하는 어시스턴트에는 갈등을 해결하는 규칙이 필요하다. 더 나은 코드 생성만으로는 그러한 규칙이 마련되지 않는다.
어려운 위임은 시스템이 무엇을 변경할 수 있도록 허용할지 결정하는 일이다. 여기에는 요청의 범위, 영향을 받는 사람, 인간의 판단이 필요한 조건이 포함된다. 구현 과정이 덜 보이게 되더라도 권한은 이해할 수 있는 상태로 남아야 한다. 그렇지 않으면 대화형 인터페이스가 사용자가 보통 중요한 결과를 초래한다고 인식할 결정을 가릴 수 있다.
가상의 제작자가 Savi에게 장애물을 제거해 달라고 요청한다고 상상해 보자. 비공개 초안 안에서는 그 요청이 간단할 수 있다. 하지만 공유 챌린지에서 그 장애물은 다른 플레이어가 참여한 활동 자체를 규정할 수 있다. 동일한 기술적 편집도 소유권과 맥락에 따라 서로 다른 의미를 갖는다.
따라서 플랫폼은 역량과 권한을 구분해야 한다. 에이전트는 공유 규칙을 수정하는 방법을 알면서도 그렇게 할 권한은 없을 수 있다. 변경을 제안할 권한은 있지만 이를 적용하려면 승인이 필요할 수도 있다. 이는 명시적으로 유지되어야 하는 제품 결정이다.
요청된 수정이 저장된 작업에 영향을 미칠 때도 유사한 문제가 발생한다. 제작자는 일반적으로 변경 사항이 의도한 대로 지속될 것이라는 확신이 필요하다. 다른 참여자들은 자신의 활동이 계속 의미를 지닐 것이라는 확신이 필요하다. 요청한 대화만을 통해 수정 사항을 평가하면 이러한 이해관계는 충분히 반영되지 않는다.
이 지점에서 제도적 기억도 중요해진다. 반복되는 문제를 조사하는 에이전트는 이전 결정이 왜 내려졌는지 아는 것이 유리하다. 그 이력이 없다면 의도적인 제약을 결함으로 오인할 수 있다. 같은 근거를 반복해서 다시 찾아내는 일은 노력을 낭비하고 유용한 경계를 되돌릴 가능성을 높인다.
엔지니어링 지식과의 연결은 실용적이다. 결정에는 구현 이력과 함께 접근 가능한 설명이 필요하다. 기록은 원래 문제, 의도된 동작, 변경을 뒷받침하는 증거를 연결해야 한다. 그 유용성은 문서의 양이 아니라 정확성과 검색 가능성에 달려 있다.
목표가 충돌할 때도 인간의 책임은 여전히 필요하다. 한 제작자의 편의는 다른 플레이어의 기대나 플랫폼의 운영 제약과 충돌할 수 있다. 자동화 시스템에는 그러한 불일치를 인식할 경로가 필요하다. 누구도 명시적으로 승인하지 않았더라도 조용히 하나의 목표를 선택하는 일 역시 결정이다.
개발자에게 이는 자율 워크플로를 설계한다는 의미를 바꾼다. 엔지니어링 과제에는 허용 가능한 행동을 정의하고 중단해야 하는 이유를 보존하는 일이 포함된다. 시스템은 한계가 보일 때 더 신뢰할 수 있다. 사용자가 결과를 함께 마주하는 세계에서는 이것이 특히 가치 있다.
신뢰성, 제작자 유지율, 독립적 재현을 지켜봐야 한다
다음으로 유용한 증거는 Spawn의 엔지니어링 주장을 지속 가능한 결과와 연결해야 한다. 앞으로 몇 달 동안 관심은 인상적인 상호작용에서 제작자가 플랫폼에 의지할 수 있는지로 옮겨가야 한다. 그 방향의 공개 증거는 보고된 운영 모델의 근거를 강화할 것이다.
신뢰성, 제작자의 지속적인 사용, 독립적 재현은 주시할 만한 가장 유익한 신호다. 각각 서로 다른 불확실성에 답한다. 신뢰성은 운영 통제를 시험하고, 유지율은 지속적인 유용성을 시험하며, 재현은 그 접근법이 원래 팀을 넘어 적용되는지를 시험한다. 완성도 높은 시연만으로는 어느 것도 완전히 답할 수 없다.
먼저, 변경 사항을 그 결과와 연결하는 신뢰성 보고를 지켜봐야 한다. 유용한 공개는 무엇이 실패했는지, 누가 영향을 받았는지, 팀이 복구 완료를 어떻게 판단했는지를 설명할 것이다. 선별적인 성공 사례는 일상적인 운영과 실수에 관한 일관된 기록보다 적은 증거를 제공한다.
가장 강력한 보고는 복구된 소프트웨어와 복구된 플레이어 경험을 구분할 것이다. 서비스가 돌아와도 영향을 받은 제작자에게는 여전히 도움이 필요할 수 있다. 이 차이를 설명하는 것은 변경의 전체 결과에 주의를 기울였음을 보여줄 것이다. 이를 구분하지 못하면 핵심적인 통제 문제는 해결되지 않은 채 남는다.
둘째, 제작자들이 자신의 게임을 유지하고 확장하기 위해 돌아오는지 지켜봐야 한다. 초기 실험은 호기심을 보여 준다. 지속적인 제작은 플랫폼이 사람들이 보존할 가치가 있다고 여기는 작업을 뒷받침한다는 점을 시사한다. 중요한 행동은 사용자가 한계에 부딪히거나 수정이 필요해진 뒤에도 창작물에 계속 투자하는 것이다.
유용한 Spawn 대 Roblox 논의는 관련 없는 시연이 아니라 동등한 제작자 결과를 비교할 것이다. 사람들이 비슷한 경험을 완성하고, 공유하고, 유지하며, 개선할 수 있는지를 물어야 한다. 이런 맥락이 없다면 어느 플랫폼이 이기는지에 대한 광범위한 주장은 현재 증거를 넘어설 것이다.
제작자 유지율은 빠른 반복이 지속적인 가치를 만든다는 근거를 강화할 것이다. 초기 실험 후 반복적으로 이탈한다면 그 근거는 약해질 것이다. 어느 패턴을 해석하든 사용자가 왜 남거나 떠났는지를 이해해야 한다. 새로움, 배포, 개별 게임의 품질은 개발 신뢰성과 함께 이러한 결정에 영향을 줄 수 있다.
셋째, 엔지니어링 접근법의 독립적 재현을 지켜봐야 한다. 다른 팀이 비슷한 결과를 보여 준다면, 이전 가능한 실무와 Spawn에 고유한 조건을 구분하는 데 도움이 된다. 감독과 실패 처리에 대한 명확한 공개는 그 증거를 더 유용하게 만들 것이다. 유사한 인터페이스만으로는 운영 모델을 재현할 수 없다.
독립적 평가는 어떤 책임이 인간에게 남는지도 설명해야 한다. 자율성은 그 경계가 정확히 명시될 때 더 많은 정보를 제공한다. 에이전트가 어디에서 멈추는지 알면 다른 팀은 동일한 구성이 자신의 사용자와 결과에 맞는지 판단할 수 있다.
Spawn 자율 에이전트를 평가하는 독자라면 제한된 질문에서 시작하라. 시스템이 변경 후에도 경험을 보존할 수 있는가? 시연이 무엇을 입증하는지 검토한 뒤, 여전히 증거를 기다리는 운영상 주장을 파악하라. 수정이 다른 플레이어에게 어떤 영향을 미치는지, 결정이 어떻게 유지되는지, 상충하는 목표를 누가 처리하는지 물어보라. 성공적인 상호작용과 실패, 미해결 질문을 함께 기록하라. 그 기록은 모델 명칭이나 고립된 창의적 결과보다 더 유용한 판단을 뒷받침할 것이다. 제작자들이 계속 만들고 있는지, 외부 팀이 그 과정을 재현할 수 있는지도 살펴보라. 다음으로 의미 있는 진전은 대화형 변경이 대화가 끝난 뒤에도 신뢰할 수 있게 유지된다는 증거가 될 것이다.
