고치기 요청 보내기

Launch로 실행해 찾은 결함은 "본 것 + 원하는 것" 형식으로 적어, 게임을 만든 같은 대화에 보냅니다. 원인은 AI가 씬과 스크립트를 열어 찾습니다. 이 페이지는 요청문 형식, 여러 결함을 번호로 묶어 보내는 법, 손으로 고치는 편이 나은 경우를 설명합니다.

시작하기 전에

• Launch로 게임을 처음부터 끝까지 해 보고, 이상한 점을 본 그대로 적어 둡니다. 실행 방법은 Launch로 실행하기에 있습니다.
• 결함인지 요청문에 안 적은 것인지 먼저 가릅니다. 요청문에 적었는데 안 됐으면 결함이고, 적지 않은 것이 마음에 안 들면 요청문을 보탤 일입니다. 기준은 요청문 쓰는 원칙에 있습니다.
• 작업이 덜 끝난 상태라면 고치기 요청보다 이어서 시키기가 먼저입니다. 멈췄을 때, 덜 끝났을 때, 맴돌 때를 봅니다.

에디터에서 직접 하기

고칠 곳과 값을 정확히 알면 손으로 고치는 편이 낫습니다. 몇 초면 끝나고 크레딧을 쓰지 않으며, 바꾼 칸만 바뀝니다. AI 요청은 몇 분이 걸리고, 부탁하지 않은 곳까지 바뀐 사례가 있습니다.

실측에서 손으로 고쳐 게임에 반영된 것은 다음과 같습니다.

고칠 값이 어느 엔티티의 어느 칸에 있는지 모르면, AI에게 위치만 묻고 고치기는 손으로 합니다. 요청문은 아래 설명만 원할 때에 있습니다.

AI에게 맡기기

요청문 형식: 본 것 + 원하는 것

고치기 요청은 두 부분으로 씁니다.

1. 본 것: Launch로 실행했을 때 무엇이 어떻게 보였는지 씁니다.
2. 원하는 것: 어떻게 되어야 하는지 씁니다.

원인은 쓰지 않습니다. 짐작이 틀리면 AI가 멀쩡한 곳을 고칠 수 있기 때문입니다. AI는 씬의 엔티티와 스크립트를 직접 열어 볼 수 있으므로, 원인을 찾는 일은 AI에게 맡기고 사람은 본 것을 정확히 전합니다. 반대로 AI는 게임을 끝까지 해 보지 못하므로, 무엇이 이상한지는 사람이 알려 줘야 합니다.

여러 결함은 번호로 묶어 한 번에

결함이 여럿이면 번호를 매겨 한 요청에 보낼 수 있습니다. 번호마다 본 것 하나만 씁니다. 다음은 첫 게임에서 결함 3개를 찾고 실제로 보낸 요청문입니다.

요청문복사

Launch로 실행해 보니 세 가지가 이상합니다.1. 게임을 시작하자마자 화면 가운데에 "You win!"이 떠 있습니다.2. 공이 별에 닿으면 별은 사라지는데 "모은 별" 숫자가 0에서 올라가지 않습니다.3. 공을 굴리면 카메라가 따라오지 않아 공이 화면 밖으로 나갑니다.이 세 가지만 고쳐 주시고 나머지는 그대로 두세요.

AI는 원인을 먼저 찾아 짧게 알리고, 처음 만들 때처럼 ✓ 줄을 늘려 가며 고친 뒤 게임을 실행해 확인했습니다. 이 요청은 약 4분 만에 세 결함을 모두 고쳤습니다.

번호로 묶어 보낸 고치기 요청의 결과는 다음과 같습니다.

7번 중 4번은 한 요청으로 끝났고, 2번은 이어서 시켜야 했고, 1번은 고쳐지지 않아 남은 결함을 다시 적어 보내야 했습니다. 따라서 묶어 보낸 뒤에는 마지막 줄과 바로 위 요약을 읽고, 덜 끝났으면 멈췄을 때, 덜 끝났을 때, 맴돌 때의 "아직 덜 끝났습니다…" 요청문을 이어서 보냅니다.

번호로 묶었을 때 고쳐진 결함이 많아도, 다른 곳이 새로 바뀌었는지는 따로 확인합니다. 결함을 하나씩 보내는 방식과의 비교는 아직 실측하지 않았습니다.

"나머지는 그대로 두세요"

요청문 끝에 "나머지는 그대로 두세요" 또는 "요청한 것 외에는 손대지 마세요"를 붙이면 고칠 범위를 문장으로 밝힐 수 있습니다. AI가 요청하지 않은 곳을 바꾸는 동작은 지금 개선하고 있으므로, 이 문장은 고치기 요청마다 매번 붙입니다(요청문 쓰는 원칙 참고). 다만 이 문장이 부탁하지 않은 변경을 모두 막지는 못했습니다. 이 문장을 붙인 요청에서도 둘레 벽이 지워지고, 자동 점검이 "너무 어둡다"고 판단해 씬 전체 머티리얼을 바꾼 사례가 있습니다. 그래서 고친 뒤에는 고친 곳만 보지 않고 게임 전체를 다시 해 봅니다. 바뀐 곳을 찾는 법은 AI가 바꾼 범위 확인하기에 있습니다.

설명만 원할 때

원인이나 값의 위치를 묻기만 할 때는 "고치지는 말아 주세요"를 붙입니다. 다음은 실제로 보낸 요청문입니다.

요청문복사

공이 굴러가는 빠르기를 정하는 설정값이 어느 물체의 어느 칸에 있는지 알려 주세요.지금 값이 얼마인지도 알려 주세요.고치지는 말아 주세요.

AI는 약 1분 만에 Ball의 ballMove → maxSpeed(당시 값 11)라고 답했고, 아무것도 바꾸지 않았습니다. 이 답대로 SCRIPT 칸을 손으로 고치면 됩니다.

설명·질문 요청 3번 가운데 1번은 "고치지 말아 주세요"를 붙였는데도 자동 점검이 화면의 시간 글자 색과 크기를 바꿨습니다. 설명을 부탁한 스크립트 파일은 그대로였습니다. 설명 요청이 끝난 뒤에도 요약을 읽어 무엇이 바뀌었는지 봅니다.

계획에서 원인과 범위 확인하기

고치기 요청을 보내면 작업 전에 계획 카드가 나옵니다. 2026-10-27 실측에서 결함 2개를 묶어 보냈을 때의 계획은 다음 네 가지를 담고 있었습니다.

• 원인: "두 증상의 원인이 같습니다. 별 스크립트의 scoreText/winText 속성이 연결되지 않아 …"
• 고칠 곳: "recipeCollectible.js: 스크립트가 Score·Win 텍스트를 이름으로 자동으로 찾도록 수정"
• 기대 결과: "시작 시 Win 메시지가 꺼지고, 별을 먹을 때마다 숫자가 올라가며 …"
• 그대로 둘 것: "별 10개, 바닥, 벽, 나무, 카메라, 나머지 UI는 그대로 둡니다"

원인이 본 증상과 맞는지, 기대 결과가 보낸 번호를 모두 덮는지, 그대로 둘 것에 건드리면 안 되는 것이 들어 있는지 보고 예를 누릅니다. 번호 하나가 계획에서 빠졌으면 아니오를 누르고 빠진 번호를 다시 적어 보냅니다. 계획 카드의 읽는 법은 계획 확인과 작업 단계 읽기에 있습니다.

계획대로 끝난다는 보장은 없습니다. 같은 실측에서 다른 판의 고치기 요청은 원인만 찾고 "도구 호출 한도"에 걸려 아무것도 고치지 않은 채 씬에 반영할 변경이 없습니다로 끝났습니다. 이때 같은 대화에 다음 문장을 보내자 계획 카드가 다시 나왔고, 예를 누른 뒤 결함 2개 가운데 1개가 고쳐졌습니다(1회).

요청문복사

찾은 원인대로 고쳐 주세요.

보낸 뒤 보고 읽기

관측한 판에서 고치기 요청의 보고는 두 부분으로 나왔습니다. 제목은 판마다 조금씩 달랐습니다.

마지막 줄이 문제 N건 남음이어도 결함이 다 고쳐진 판이 있었고, 문제 없음이어도 결함이 남은 판이 있었습니다. 마지막 줄은 어디부터 볼지 알려 주는 표시입니다. 해석은 마지막 줄과 자동 점검 해석에 있습니다.

확인하기

1. 열어 둔 게임 탭을 새로 고칩니다. 새로 고치지 않으면 고치기 전 게임이 그대로 보입니다. 게임 탭을 닫았으면 ▶ Launch를 다시 누릅니다.
2. 보고의 "남은 확인"에 적힌 것부터 해 봅니다.
3. 보낸 번호를 하나씩 확인하고, 게임을 처음부터 끝까지 다시 해 봅니다. 고친 곳 말고 다른 곳이 바뀐 사례가 있기 때문입니다.
4. 같은 프로젝트에 다른 씬이 있으면 그 씬도 실행해 봅니다. 공유 스크립트를 고쳐 다른 씬의 게임이 바뀐 사례가 2건 있습니다. 자세한 내용은 씬마다 따로인 것, 프로젝트가 함께 쓰는 것에 있습니다.

막혔을 때

다음으로

• AI가 바꾼 범위 확인하기
• 멈췄을 때, 덜 끝났을 때, 맴돌 때
• 마지막 줄과 자동 점검 해석
• 요청문 쓰는 원칙
• AI 작업 되돌리기
• 크레딧