게임 승인 적체 속 Valve, Steam 출시 규정 강화
개발자들이 빌드 검토에 최대 12영업일이 걸리는 상황에서 Valve가 Steam 출시 규정을 강화해 예정된 출시 일정에 부담이 커지고 있다. 변경된 규정은 제출 전에 더 많은 점검을 요구하며, 여기에는 실제로 Steam을 통해 게임을 실행하는 것도 포함된다. AI 생성 게임에 대한 우려가 커지는 가운데 나온 조치이지만, Valve는 AI가 적체에 얼마나 기여했는지는 수치로 밝히지 않았다.
당장의 갈등은 공동 검토 대기열 접근을 둘러싼 문제다. 개발자는 자체 제출물을 신중히 준비할 수 있지만, 반복 검사가 필요한 게임들 뒤에서 기다려야 할 수 있다. Valve의 대응은 검토자가 문제를 발견하기 전에 제작자가 기본적인 문제를 찾아내야 하는 책임을 더 크게 부여한다.
itch.io와의 비교는 이 문제가 왜 중요한지 설명하는 데 도움이 된다. 두 스토어프런트 모두 생성형 콘텐츠 관리에 관한 질문에 직면해 있지만, 테스트 요건과 대량 업로드 제한은 서로 다른 문제를 다룬다. Valve의 최신 조치는 출시 준비 상태를 겨냥한다. 이미 기다리고 있는 개발자들에게 더 큰 불확실성을 만들지 않으면서 승인 시간을 개선할 수 있는지가 성패를 좌우한다.
Valve가 Steam 출시 규정에서 바꾼 내용
Valve는 개발자들에게 게임을 검토에 제출하기 전에 기본적인 출시 준비 상태를 입증하라고 요구하고 있다.
11월 3일 발표한 사전 출시 검토 업데이트는 반복 검사를 줄이기 위한 점검 항목을 추가했다. 개발자는 Steam을 통해 최소 5분 동안 게임을 실행해야 한다. Valve는 필수 소프트웨어 구성 요소, 업적, 클라우드 저장, 스크린샷 카테고리에 관한 점검도 요구한다.
회사는 일반적인 빌드 검토 목표 기간이 3~5일이지만, 현재 대기 시간은 12영업일에 이른다고 밝혔다. 문제 발생 후 제출물을 다시 검토하는 일이 지연의 상당 부분을 차지한다고 설명했다. 이는 플레이어가 게임 구매 후 남기는 고객 리뷰와는 별개의 개발 승인 절차다.
빌드는 테스트나 배포를 위해 제출되는 게임의 패키지 버전이다. 개발자의 컴퓨터에서 해당 패키지를 직접 실행하는 것만으로는 고객이 거치는 모든 단계를 재현할 수 없다. Steam이 게임을 제공할 때 설치, 실행 설정, 지원 소프트웨어는 다르게 작동할 수 있다.
이러한 차이는 플레이 시간 요건이 짧아 보이는 시간보다 더 중요한 이유를 설명한다. 이 점검은 개발자가 실제 배포 경로를 거쳤는지를 묻는다. 작동하는 로컬 실행 파일만으로 충분한 증거를 인정하는 대신, 제공되는 형태의 제품을 최소한으로라도 직접 경험했는지 확인한다.
일반적인 재배포 패키지는 게임 실행에 필요한 DirectX나 Visual C++ 라이브러리 같은 공유 소프트웨어 구성 요소다. 이를 확인하면 기본적인 배포 문제를 해결하는 데 도움이 된다. 개발자의 컴퓨터에는 다른 컴퓨터에 없는 종속성이 설치돼 있을 수 있기 때문이다. 따라서 로컬 테스트가 성공했다고 해서 중요한 질문들이 모두 해소되는 것은 아니다.
지원되는 게임 저장 데이터를 동기화하는 서비스인 Steam Cloud 역시 설정이 중요한 지점이다. 업적과 스크린샷 분류도 제출된 제품을 광고된 기능과 연결한다. 이러한 점검은 게임의 패키징과 표현 방식이 플레이어가 받게 될 내용과 일치하는지를 함께 확인한다.
기존 검토 절차는 이미 게임의 스토어 페이지와 빌드 모두에 대한 승인을 요구한다. 또한 광고한 기능이 제출된 버전에 존재해야 한다고 명시한다. Valve의 새 체크리스트는 이 기존 관문에 명시적인 사전 준비 절차를 더한다.
이 정책의 의미는 Valve가 작업을 어디에 배치하는지에 있다. 개발자는 회사가 지연을 인정한 대기열에 들어가기 전에 더 많은 일상적인 문제를 해결해야 한다. 이 접근 방식은 예방 가능한 재제출을 제작자가 사용하는 개발 도구를 바꾸지 않고도 Valve가 해결할 수 있는 문제로 본다.
이는 회사의 설명을 검증할 명확한 기준도 만든다. 기본적인 제출 실패가 상당한 검토 작업을 차지한다면, 이를 더 일찍 발견하는 것이 도움이 될 것이다. 다른 제약이 더 큰 비중을 차지한다면, 더 상세한 체크리스트를 도입해도 핵심 병목은 대체로 그대로 남는다.
불확실한 대기열의 비용을 떠안는 인디 개발자들
기본 게임이 출시 준비를 마쳤더라도 승인 지연은 출시를 흔들 수 있다.
출시일은 단순한 업로드 이상의 요소를 조율한다. 공지, 크리에이터 보도, 커뮤니티의 기대, 협업자의 일정이 맞물릴 수 있다. 특히 대체 일정을 자신 있게 발표할 수 없을 때, 날짜를 옮기는 일은 개발자가 완전히 통제할 수 없는 약속들을 다시 조정하는 것을 뜻한다.
Cubic Earth는 이러한 압박을 보여준다. 개발자 structmira는 PC Gamer에 게임이 6,000개 이상의 위시리스트를 모았고 트레일러가 YouTube에서 60,000회 이상 조회됐다고 말했다. 빌드 검토 적체 보도에 따르면, 개발자는 승인이 해결되지 않는 동안 플레이어 불만이 커졌다고 설명했다.
이 수치는 구매를 보장하는 것이 아니라 관객의 관심을 보여준다. 그럼에도 기다림이 왜 중대한 문제처럼 느껴질 수 있는지 설명한다. 팀은 이미 사람들에게 관심을 기울여 달라고 요청했고, 그 관심이 접근으로 이어질 순간에 해결되지 않은 플랫폼 결정이 끼어든다.
Wheel Make It도 또 다른 보도 사례다. 퍼블리셔 2 Left Thumbs는 승인 지연이 출시를 방해했다고 비판했다. 개발자 업데이트는 컨트롤러를 통한 해상도 설정 접근과 관련된 검토 실패도 설명했으며, 이는 지연된 게임 출시 보도에서 다뤄졌다.
이러한 조합은 개발자들이 단순히 Valve를 기다린다는 설명을 복잡하게 만든다. 제출물에 정당한 문제가 있을 수 있지만, 그 상태를 해결하는 데 걸리는 시간은 여전히 심각한 문제를 만들 수 있다. 결함을 찾는 일과 신뢰할 수 있는 검토 일정을 전달하는 일은 별개의 책임이다.
업무를 재배치할 여지가 적은 팀일수록 압박은 특히 크다. 출시 지연은 출시 자체를 미루면서 커뮤니티 관리 기간을 늘릴 수 있다. 개발자들은 자신들이 내릴 수 없는 결정을 설명하는 데 시간을 쓰게 되며, 자신들이 만든 게임을 이야기하는 시간은 줄어든다.
불리한 답변과 알 수 없는 답변 사이에도 차이가 있다. 명확한 거절은 팀이 해결할 구체적인 대상을 제공한다. 해결되지 않은 제출물은 원인, 필요한 대응, 또 다른 공개 약속이 신뢰할 만한지에 대한 불확실성을 남긴다.
따라서 Steam 검토 적체에는 검토자의 업무를 넘어선 조율 비용이 있다. 개발자들은 공지에 더 큰 완충 시간을 두거나, 홍보 약속을 미루거나, 정확한 출시 가능 시점을 약속하지 않을 수 있다. 이러한 대응은 이해할 만하지만, 불확실성을 나머지 제작 일정으로 옮긴다.
사전 준비는 보호를 보장하지 않지만 여전히 유용하다. 충분히 테스트된 제출물은 피할 수 있는 문제를 줄여야 하지만, 여전히 공동 플랫폼의 처리 용량에 의존한다. Valve의 체크리스트는 개발자에게 누군가가 검토를 마칠 날짜보다 제출 품질에 대해 더 큰 통제권을 부여한다.
이 구분은 업데이트를 공정하게 평가할 때 중요하다. 개발자는 제출 전에 발견할 수 있는 결함을 책임져야 한다. Valve는 여전히 승인 절차의 명확성과 운영을 책임진다. 전자를 개선한다고 해서 후자에 대한 우려가 자동으로 해소되는 것은 아니다.
더 빨라진 게임 제작과 공동 승인 관문의 만남
게임 제작에 필요한 노력을 줄인다고 해서 책임 있게 배포하는 데 필요한 작업이 사라지는 것은 아니다.
이것이 Steam 출시 규정 업데이트의 핵심 긴장 관계다. 프롬프트나 다른 입력을 바탕으로 새 콘텐츠를 생성하는 소프트웨어인 생성형 AI는 개발의 일부를 지원할 수 있다. 그러나 결과물은 여전히 제대로 작동하는 설치, 정확한 표현, 그리고 둘 다 점검할 책임자를 필요로 한다.
이는 자료를 생산하는 일과 완성된 제품을 검증하는 일 사이의 불일치를 만든다. 이미지를 생성하거나 코드를 작성하는 일은 개별 작업에 해당한다. 게임을 출시하는 일은 다른 사람이 이를 설치하고 플레이할 때 여러 요소가 함께 어떻게 작동하는지에 관한 문제다.
제작자의 개발 폴더에서 실행할 때는 작동하는 가상의 게임을 생각해 보자. 이 결과만으로 배포 패키지에 필요한 모든 것이 포함됐는지는 입증되지 않는다. 관련 코드를 사람이 썼든 AI 보조 도구가 썼든, 문제는 배포에 있다.
Valve의 최소 플레이 요건은 이 간극을 직접 겨냥한다. 제작자에게 무언가를 실행 가능하게 만드는 단계에서 배포되는 무언가를 테스트하는 단계로 넘어가라고 요구한다. 이 구분은 기본적인 내용이기에 기본적으로 들리지만, 공동 승인 시스템은 모든 제출물이 그 단계를 거쳤다고 가정할 수 없다.
경제적 긴장 관계는 분명하다. 사전 준비를 건너뛰는 개발자는 현지에서 노력을 아끼지만, 다른 주체가 그 누락을 발견하도록 남겨 둔다. 그 발견으로 재제출이 발생하면 같은 제품은 플레이어에게 도달하기 전에 추가적인 관심을 소모한다.
신중한 개발자들은 그 결과를 함께 떠안는다. 자체 빌드에 수정 작업이 거의 필요하지 않더라도, 같은 승인 시스템에 의존한다. 이것이 논쟁이 특정 AI 보조 게임이 비판받을 만한지 여부를 넘어서는 이유다.
결과 중심 체크리스트는 이 점에서 설득력 있는 장점이 있다. 개발 방식 전반에 동일한 준비 기준을 적용할 수 있다. AI 보조로 제작된 게임도 올바르게 실행돼야 하며, 사람이 직접 제작한 게임도 같은 요건에서 면제받아서는 안 된다.
대조적인 접근 방식은 itch.io의 콘텐츠 품질 가이드라인에서 나타난다. 이 가이드라인은 과도하게 자동 생성된 콘텐츠와 대량 생산된 제품 페이지를 명시적으로 다룬다. 유용한 생성 콘텐츠의 활용은 허용하면서도, 자동화를 이용해 발견 시스템을 넘쳐나게 만드는 행위는 경고한다.
두 접근 방식은 문제의 서로 다른 단계를 겨냥한다. 제출 점검은 개별 제품이 검사를 받을 준비가 되었는지 묻는다. 대량 생산 제한은 업로드 행위가 마켓플레이스를 압도하고 있는지 묻는다. 모든 AI 보조 제작자를 스패머로 취급하지 않으면서도 스토어프런트에는 둘 다 필요할 수 있다.
독자에게 유용한 비교는 각 플랫폼이 마찰을 어디에 두는지에 관한 것이다. 더 이른 단계의 점검은 명백한 실패가 대기열에 들어오는 것을 막을 수 있다. 반복적 업로드 제한은 물량을 억제할 수 있다. 어느 접근 방식도 단독으로 게임이 독창적인지, 재미있는지, 정직하게 마케팅됐는지는 판단하지 않는다.
Valve는 당장의 승인 문제에 대해 좁은 개입을 선택했다. 이는 개발자들에게 구체적인 기준을 제공하지만, 업데이트가 달성할 수 있는 범위도 제한한다. 기능적 준비 상태는 출시의 필수 요소지만, AI 생성 게임을 둘러싼 논란의 일부만 다룬다.
AI 공개만으로 지연 원인을 알 수는 없다
증거는 검토 절차가 지연되고 있음을 뒷받침하지만, AI 생성 게임이 정확히 얼마나 영향을 미쳤는지는 공개적으로 측정되지 않았다.
Valve의 설명은 반복 검토가 지연의 상당한 원인이라고 지목한다. 이는 절차 내부에 쌓이는 작업에 대해 독자에게 어느 정도 정보를 제공한다. 그러나 실패한 제출물의 개발 방식이 무엇이었는지 밝히거나, 어떤 유형의 게임이 가장 많은 검토 시간을 소비하는지를 입증하지는 않는다.
AI 공개 표시는 다른 질문에 답한다. 이는 공개 정책의 범위 안에서 개발사가 생성형 콘텐츠를 사용했다고 밝힌 내용을 플레이어에게 알린다. 이는 테스트 품질, 독창성 또는 게임에 투입된 노력 전반을 종합적으로 측정하는 지표가 아니다.
Valve의 콘텐츠 설문조사는 관련 정책 체계를 제공한다. 이러한 공개 내용을 읽을 때는 무엇을 다루는지에 주의를 기울여야 한다. 생성된 자료에 관한 표시는 게임 전체가 자동으로 제작되었다는 근거 없는 주장으로 확대되어서는 안 된다.
공개 표시가 없는 게임에도 같은 주의가 필요하다. 표식이 없다고 해서 신중한 테스트가 이루어졌다는 사실이 독립적으로 입증되지는 않는다. 제출물의 품질을 평가하려면 개발사가 선호한 도구에 대한 추정보다는 제출된 제품 자체에 관한 증거가 필요하다.
현재 논쟁의 이면에는 여러 가지 서로 다른 측정 기준이 있다. 출시된 게임은 스토어에 성공적으로 도달한 결과를 보여 준다. 제출된 게임은 새로 유입되는 검토 수요를 나타낸다. 재검토는 그 수요 안에서 발생하는 추가 작업을 뜻한다. 이 범주들을 서로 바꿔 쓸 수 있는 것으로 취급하면, 증거가 뒷받침하는 수준보다 더 강한 인과 주장이 만들어진다.
AI 공개 표시가 확실히 늘어난다고 해도 중요한 질문들은 남는다. 그것만으로는 해당 게임들이 검토를 통과하지 못하는 빈도, 검토자가 투입하는 시간, 또는 실패 양상이 다른 제출물과 다른지를 보여 주지 못한다. 백로그의 구성을 설명하려면 이런 측정치가 필요하다.
그렇다고 개발자들의 우려가 부당하다는 뜻은 아니다. 그들의 불만은 불확실한 승인 절차에 실제로 노출되어 있음을 반영하며, 빠른 콘텐츠 생성은 추가 수요의 그럴듯한 원인을 제공한다. 다만 그럴듯함은 Valve가 아직 공개하지 않은 세부 내역을 대신하는 것이 아니라 조사를 이끄는 역할을 해야 한다.
저품질 생성 자료를 뜻하는 약칭인 “AI slop”이라는 용어에도 관련된 문제가 있다. 이 표현은 불만을 효과적으로 전달하지만 서로 다른 불평을 한데 묶어 버린다. 설치 오류, 반복적인 디자인, 오해를 부르는 표현, 원치 않는 생성형 아트는 각각 다른 증거와 잠재적으로 다른 대응을 요구한다.
작동 여부를 확인하는 출시 점검은 첫 번째 불만에 직접 대응한다. 그러나 게임이 다른 창작자의 아이디어를 베꼈는지, 혹은 플레이할 만한 가치를 제공하는지에 대해서는 훨씬 적게 말해 준다. 이 체크리스트가 모든 AI 우려에 대한 해답이라고 부르는 것은 그 범위를 과장하는 일이다.
따라서 가장 탄탄한 분석은 주장들을 분리해 유지한다. Valve는 지연을 인정했고 재검토를 원인으로 지목했다. 개발자와 보도진은 이러한 어려움을 AI 지원 콘텐츠의 더 광범위한 유입과 연결한다. 그러나 공개 기록은 아직 그 유입이 얼마나 큰 설명력이 있는지 수치화하지 못했다.
정책이 발전하는 동안 이 검증 공백은 계속 드러나 있어야 한다. 독자는 모든 실패를 AI 탓으로 돌리지 않으면서도 운영상의 문제를 심각하게 받아들일 수 있다. 개발자는 대기열을 늦추는 모든 문제를 단일한 원인으로 증명하지 않고도 더 나은 서비스를 요구할 수 있다.
더 나은 점검은 도움이 되지만, Valve에는 여전히 할 일이 남아 있다
체크리스트는 피할 수 있는 실패를 줄일 수 있지만, 승인 시스템에 충분한 처리 역량이 있다는 사실을 입증하지는 못한다.
Valve의 접근에는 분명한 운영 논리가 있다. 제출 전에 누락된 종속성을 찾아내는 편이 검토 중에 발견하는 것보다 낫다. 홍보된 기능을 확인하면 검토자는 더 깔끔한 제품을 평가할 수 있고, 무엇이 포함되어야 하는지를 둘러싼 이견의 여지도 줄어든다.
이를 지지하는 논리는 예방에 기반한다. 창작자가 기본적인 문제를 로컬에서 식별할 수 있다면, 나중에 플랫폼이 이를 발견하도록 할 가치는 거의 없다. 명확한 요구사항은 경험이 적은 개발자에게 게임을 완성하는 일과 배포를 준비하는 일이 별개의 작업임을 이해하도록 돕는다.
그러나 회의적인 관점도 같은 비중으로 살펴볼 필요가 있다. 제출물은 눈에 보이는 체크리스트 항목을 충족하고도 검토가 필요한 문제를 여전히 포함할 수 있다. 최소 플레이 시간으로 모든 운영 환경을 포괄할 수는 없으며, 확인 필드만으로 창작자가 자신이 확인하는 기능을 이해했는지 입증할 수도 없다.
정책의 효과는 그 점검 항목이 빈번하고 예방 가능한 검토 실패와 맞물리는지에 달려 있다. 그렇다면 추가 작업은 유의미한 성과를 낼 수 있다. 개발자가 준비를 개선하지 않은 채 단순히 필드를 작성한다면, 절차는 형식만 늘어나고 결함은 그대로 남는다.
소통 측면의 과제도 있다. 개발자는 일반적인 목표와 현재의 운영 상황을 구분할 필요가 있다. 인정된 지연 때문에 예정된 출시에서는 신뢰할 수 없는 익숙한 예상치가 제시되어도, 계획을 세우는 데는 별 도움이 되지 않는다.
Valve는 승인 날짜를 보장하지 않고도 이 상황을 개선할 수 있다. 명확한 상태 정보와 현재의 예상치는 팀이 책임 있게 약속할 수 있는 범위를 판단하는 데 도움이 된다. 검토자가 무엇을 필요로 하는지 설명하는 것 역시 제출물에 수정이 필요할 때 불확실성을 줄일 수 있다.
개발팀에게 일관된 문서화는 출시 준비의 일부가 된다. 테스트 메모, 구성 결정, 이전 피드백은 협업자가 이미 무엇을 확인했는지 이해하는 데 도움이 된다. 검색 가능한 엔지니어링 지식 베이스는 직접 테스트를 대체하지 않으면서도 이러한 기록을 뒷받침할 수 있다.
더 큰 쟁점은 공동 시스템 전반의 책임에 관한 것이다. 창작자는 준비 상태와 자신들의 주장에 대한 정확성을 통제한다. Valve는 검토 운영, 요구사항의 명확성, 그리고 개발자가 대기 중에 받는 정보를 통제한다. 양쪽 모두 상대방이 대신 수행할 수 없는 일을 맡고 있다.
플레이어에게도 의미 있는 점검이 유지되는 것은 중요하다. 명백한 설치 문제가 그대로 통과한다면 더 빠른 승인 절차의 이점은 제한적이다. 반대로 효과적인 검토도 그 시점 때문에 개발자가 신뢰할 만한 출시 계획을 세울 수 없다면 가치를 잃는다.
이 때문에 속도와 신뢰성은 공동의 목표다. Valve에는 피할 수 있는 수정이 덜 필요한 제출물이 필요하고, 개발자에게는 자신의 동작 방식을 이해할 수 있는 절차가 필요하다. 새 요구사항은 이러한 교환의 일부를 다루지만, 그 존재만으로 교환이 개선되었다는 증거가 되지는 않는다.
공정한 기준은 시행 이후 관찰 가능한 성과다. 더 상세한 양식은 하나의 개입이다. 예방 가능한 실패의 감소와 더 신뢰할 수 있는 승인은 결과다. 그런 결과가 나타나기 전까지 이번 업데이트는 실질적 효과가 아직 확인되지 않은 합리적인 제안에 머문다.
Steam 출시 규정 업데이트 이후 주목할 점
다음 시험대는 개발자가 재검토를 덜 겪고 더 예측 가능한 출시 결정을 받게 되는지 여부다.
첫 번째 신호는 검토 일정 자체다. 앞으로 몇 달 동안 Valve의 현재 예상치가 통상적인 목표 수준으로 돌아가는지 지켜봐야 한다. 개발자 계정은 특히 최초 제출, 요청된 변경 사항, 최종 승인을 명확히 구분할 때 맥락을 더할 수 있다.
대기 시간이 짧아진다면 예방 가능한 재검토가 해결 가능한 병목이었다는 주장에 힘이 실릴 것이다. 지연이 계속된다면 체크리스트만으로 충분했다는 주장은 약해질 것이다. 어느 결과도 그 자체만으로 AI 생성 콘텐츠가 원래 문제에 얼마나 기여했는지를 입증하지는 못한다.
두 번째 신호는 피드백 순환의 품질이다. 더 구체적인 문서, 더 명확한 상태 메시지, 그리고 개발자가 관련 문제를 함께 해결할 수 있게 하는 설명이 나오는지 살펴봐야 한다. 그러한 변화는 제출물 품질과 검토 효율의 상호작용에 주의를 기울이고 있음을 보여 줄 것이다.
새롭게 발견된 기본 요구사항에 대한 보고가 반복된다면 반대 방향을 가리킨다. 개발자가 제출 전에 준비 상태가 무엇을 뜻하는지 알 수 없다면 책임을 배분하기는 여전히 어렵다. 표준은 검토자가 무엇을 놓쳤는지 설명하기 전에 창작자가 적용할 수 있을 때 가장 잘 작동한다.
세 번째 신호는 스토어가 콘텐츠 규모와 운영 결과를 연결하는 증거를 공개하는지 여부다. 더 유용한 보고는 유입되는 제출물과 출시된 게임을 구분하고, 재작업을 유발하는 실패 유형을 식별할 것이다. 이는 AI에 관한 설명을 직접 강화하거나 반박할 수 있다.
경쟁 플랫폼의 조치도 이 측정 문제 안에서 주목할 만하다. 반복적인 업로드 제한과 발견성 개선은 Steam의 승인 관문을 넘어선 압력에 대응한다. 그 가치는 플랫폼이 원치 않는 콘텐츠를 얼마나 강하게 묘사하는지가 아니라, 실제로 무엇을 개선하는지로 판단해야 한다.
AI 제품 개발자에게도 이는 완료된 작업의 기준을 상기시킨다. 하나의 환경에서 실행되는 생성 프로젝트는 경로의 일부만 통과한 것이다. 제작이 쉬워지더라도 배포, 통합, 검증은 여전히 제품 책임으로 남는다.
플레이어에게 실질적인 질문은 스토어가 더 많은 제출물을 처리하면서도 신뢰를 유지하는지 여부다. 정확한 표현과 정상적으로 작동하는 설치는 여전히 합리적인 기대다. 이런 기대가 AI를 둘러싼 모든 논쟁을 해결하지는 않지만, 플랫폼 정책을 평가하는 구체적인 기준선을 제공한다.
출시를 준비하는 스튜디오는 현재 요구사항을 따르고, 확인된 이정표에 맞춰 약속을 해야 한다. 무엇을 테스트했는지, 어떤 버전이 피드백을 받았는지, 무엇이 아직 해결되지 않았는지를 기록하라. 특히 외부 보도나 커뮤니티 이벤트를 조율할 때는 승인 시점을 적극적으로 관리해야 하는 종속 요소로 다뤄야 한다.
그런 다음 발표만이 아니라 실제 결과를 기준으로 Steam 출시 규정을 다시 평가하라. 완성된 제출물이 더 예측 가능하게 진행되고 있는가? 검토자는 피할 수 있는 문제를 더 적게 발견하고 있는가? Valve는 개발자가 지연을 정직하게 설명할 수 있을 만큼 충분한 정보를 제공하고 있는가? 완성된 게임이 플레이 가능한 출시물로 이어지는 경로를 새 점검 항목이 실질적으로 개선했는지 판단하기 전에 이 답을 추적하라.
