AI 어시스턴트가 게임에 만든 변경은 남기기 전에 어떻게 검토하나요?

바뀐 파일을 작업 요청과 비교하고, diff를 삭제된 부분부터 읽고, 확인을 직접 실행하고, 바뀐 곳을 플레이한 뒤에야 커밋합니다.

네 가지를 이 순서로 보세요. 어떤 파일이 바뀌었는지, diff가 무엇을 지우고 무엇을 더했는지, 확인을 직접 실행했을 때 결과가 무엇인지, 그리고 변경이 들어간 곳이 실제로 어떻게 플레이되는지. 네 가지가 모두 요청한 내용과 맞을 때만 변경을 남기고, 커밋으로 남기세요. 하나라도 맞지 않으면 변경을 되돌리고 더 나은 작업 요청으로 다시 부탁하세요. 어시스턴트의 보고는 어디를 볼지 알려 줄 뿐, 검토 자체는 아닙니다.

왜 "완료했습니다"로는 부족한가요?

그것은 주장이고, 증거는 변경 그 자체이기 때문입니다. 어시스턴트는 코드가 빌드되는지만 확인하고 기능이 작동한다고 말할 수 있고, 파일 하나만 건드렸다고 하면서 실행한 명령이 파일 세 개를 다시 쓴 경우도 있습니다.

이 중 일부는 편집기에서 아예 보이지 않습니다. Visual Studio Code의 AI가 만든 편집 검토 페이지는 보류 중인 편집이 이미 디스크에 저장되어 있고, 터미널 명령이나 스크립트로 만든 변경은 편집 목록에 나타나지 않으며, 체크포인트는 터미널 명령이나 배포를 되돌리지 않는다고 설명합니다. 2026년 10월 29일에 읽은 내용이며, 마지막 업데이트는 10월 21일이었습니다. 어떤 도구를 쓰든 믿을 수 있는 화면은 버전 관리가 보여 주는 것, 곧 마지막 커밋과 다른 모든 파일입니다.

그래서 첫 단계는 어시스턴트가 시작하기 전에 있습니다. 작동하는 버전을 커밋으로 저장해 두세요. 그것이 없으면 변경을 비교할 대상도, 돌아갈 곳도 없습니다.

무엇부터 보나요?

바뀐 파일 목록입니다. 명령 두 개로 볼 수 있습니다.

git status
git diff --stat

git status는 바뀐 파일과 새 파일을 모두 보여 줍니다. git diff --stat은 파일마다 몇 줄이 늘고 줄었는지를 더해 줍니다. git diff만으로는 새로 만들어져 아직 Git에 추가되지 않은 파일이 보이지 않습니다. git status에는 보이니 둘 다 읽으세요.

이제 목록을 작업 요청과 비교하세요. 변경이 어디에 들어가고 무엇은 바뀌면 안 되는지 적은 작업 요청을 썼다면 몇 초면 끝납니다.

이것들은 그 자체로 잘못은 아닙니다. 하지만 하나하나가 검토할 계획이 없던 것이므로 먼저 봅니다.

프로그래머가 아니라면 diff를 어떻게 읽나요?

지워진 줄(빨간색, - 표시)과 더해진 줄(초록색, + 표시)의 목록으로 읽고, 지워진 줄부터 시작하세요. 사라진 한 줄은 가장 놓치기 쉽고 플레이하면서 알아채기도 가장 어렵습니다. 플레이어가 벽을 통과하지 못하게 막던 검사, 점수 초기화, 빈 저장 데이터에 대한 방어 같은 것들입니다.

그다음, 언어를 몰라도 찾기 쉬운 패턴 몇 가지를 살펴보세요.

• 바뀐 숫자: 속도, 목숨, 타이머, 가격. 하나하나가 작업 요청에 있어야 합니다.
• 주석으로 바뀐 코드, 또는 통째로 지워졌다가 다른 곳에 다시 쓰인 블록.
• 예전 함수와 닮은 새 함수: 같은 일을 두 번 하게 되고, 두 사본은 나중에 서로 달라집니다.
• 플레이어가 보는 글: 메뉴, 힌트, 오류 메시지. 여전히 맞고, 제자리에 있나요?

읽을 수 없는 줄이 있으면 그 줄이 무엇을 하고 무엇이 그것을 호출하는지 어시스턴트에게 물어보세요. 묻는 데는 비용이 들지 않고, 코드와 맞지 않는 답이 돌아오면 그것 자체가 발견입니다.

어떤 확인을 직접 실행하나요?

작업 요청에서 지정한 확인을, 보고로 넘기지 말고 직접 실행합니다. 작업 요청에 테스트가 있었다면 테스트를 실행하고 결과를 읽으세요. 페이지가 오류 없이 열려야 한다고 했다면 브라우저 콘솔을 연 채로 게임을 여세요. 통과하는 것을 직접 본 확인은 통과했다는 한 문장보다 값집니다.

초록색 테스트는 그 테스트가 확인하는 것만 증명합니다. 같은 diff에서 테스트 파일이 바뀌었다면 그 부분을 읽으세요. 다시 시작한 뒤 점수 0을 기대하던 테스트가 이제 코드가 돌려주는 값을 그대로 기대한다면, 더 이상 아무것도 확인하지 않습니다.

변경을 남기기 전에 무엇을 플레이하나요?

먼저 작업 요청에 적은 대로 변경 그 자체를. 그다음 게임의 나머지를 짧은 경로로 돕니다. 한 곳의 변경이 다른 곳을 망가뜨리는 일이 잦으니 매번 같은 경로로 하세요.

1. 새로 연 페이지에서 게임을 시작합니다.
2. 모든 조작을 한 번씩 써 봅니다. 키보드로, 그리고 게임에 터치 조작이 있다면 휴대폰으로도.
3. 일시 정지, 패배, 다시 시작.
4. 저장, 페이지 새로 고침, 불러오기.

이 경로는 몇 분이면 끝나고, 테스트가 좀처럼 잡지 못하는 것을 잡아냅니다. 더 이상 반응하지 않는 버튼, 빠져나올 수 없는 화면, 돌아오지 않는 저장 데이터 같은 것들입니다. 변경으로 키나 화면이 늘었다면 터치로도 작동하는지 확인하세요. KittenGalaxy에 터치 조작을 추가한 뒤로 저희가 지키는 규칙입니다.

변경을 남기거나 버리려면 어떻게 하나요?

남기려면, 무엇이 바뀌었는지 플레이어의 말로 적은 메시지와 함께 커밋하세요. "웨이브마다 10% 빨라지고, 최대 시작 속도의 두 배까지"처럼요. 작업 하나에 커밋 하나. 나중에 무언가 망가지면 어떤 변경 때문인지 찾아 정확히 그것만 되돌릴 수 있습니다.

버리려면 마지막 커밋으로 돌아가세요. Git에서 git restore .는 Git이 이미 추적하는 파일을 마지막 커밋의 상태로 되돌립니다. 단, 변경이 git add로 스테이징되지 않았을 때입니다. 어시스턴트가 새로 만든 파일은 이 명령으로 지워지지 않으니 git status를 다시 보고 직접 삭제하세요. 자체 되돌리기나 체크포인트가 있는 편집기도 설명된 범위 안에서 같은 일을 할 수 있습니다. 그런 다음 더 나은 작업 요청을 쓰세요. 무엇이 잘못됐는지 적고, 그것을 잡아냈을 확인을 더하세요.

대부분 맞는 변경을 남기고 나머지는 다음 작업에서 고치고 싶어집니다. 무엇이 틀렸는지 말할 수 있고 그것이 작을 때만 그렇게 하세요. 이해하지 못하는 변경은 다음 변경이 그 위에 쌓인다고 이해하기 쉬워지지 않습니다. 어시스턴트와 만든 게임은 이렇게 통제를 벗어나고, 그래서 작은 첫 게임이 작동하는 상태를 지키기 더 쉽습니다.

다른 AI에게 검토를 맡길 수 있나요?

diff를 함께 읽을 수는 있습니다. 줄을 설명하고, 지워진 검사를 짚고, 새 함수가 무엇을 위한 것인지 물어봐 줍니다. 코드를 읽지 않는다면 특히 도움이 됩니다. 하지만 게임이 여전히 원하는 대로 작동하는지는 판단할 수 없습니다. 그건 당신만 알고, 게임을 대신 플레이해 줄 수도 없습니다. 두 번째 독자로 쓰되, 승인으로는 절대 쓰지 마세요.

자주 묻는 질문

검토에는 시간이 얼마나 걸려야 하나요? 변경이 작은 만큼 짧게 걸립니다. diff를 읽는 데 작업 요청을 쓰는 것보다 오래 걸린다면 작업이 너무 컸을 가능성이 큽니다. 다음 작업은 나누세요.

이를 위해 Git이 필요한가요? 무엇이 바뀌었는지 보고 되돌아갈 방법이 필요합니다. Git이 흔히 쓰는 방법이고 무료이며, 대부분의 편집기와 어시스턴트가 Git과 함께 작동합니다.

변경은 맞는데 코드가 지저분해 보이면요? 작동하고 이해할 수 있다면 남기고, 정리는 같은 확인을 붙인 별도 작업으로 맡기세요. 정리를 새 기능 변경에 섞지 마세요.

그림, 소리, 레벨 파일의 변경도 검토하나요? 네, diff를 읽는 대신 보고 플레이해서요. 어떤 파일을 봐야 하는지는 여전히 바뀐 파일 목록이 알려 줍니다.

다른 사람들은 언제 플레이할 수 있나요? 위 경로가 새 페이지에서 통과하고, 처음 보는 사람이 도움 없이 게임을 끝낼 수 있을 때입니다. 그때 HeapPlay에 제출할 수 있습니다.