AI(Claude)에게 Unity 개발을 맡기고, 실패 사례 88건을 기록했습니다. 깨달은 것은 0건이었습니다

개인적으로 Unity 게임을 만들면서 설계와 구현 대부분을 AI(Claude / Anthropic)에 의존하고 있습니다.

Claude가 틀릴 때마다 '날짜/Claude가 말한 것/실제는 어땠는지'를 한 줄씩 기록했습니다. 1개월 만에 88건이 쌓였습니다. 같은 기간 동안 Claude가 완료까지 이끈 태스크는 총 138건입니다.

성공 사례는 많이 나와 있으니, 여기서는 실패 사례 위주로, 세 가지 방식으로 나누어 정리합니다.

1. 유형별 분류: 10가지 유형으로 수렴하다

설계를 먼저 전부 작성한 후 구현하게 하면 이 유형이 쌓입니다. Claude는 쓰여진 설계를 구현합니다. 쓰여지지 않은 '연결'은 구현하지 않습니다. 게다가 Claude에게 코드를 점검하게 해도 발견되지 않습니다. Claude 입장에서는 모두 '구현 완료' 상태이기 때문입니다.

2. 깨달은 방식별 분류: 무너진 것은 0건

외부 데이터도 비슷한 양상을 보입니다.

• Stack Overflow 2025 개발자 조사: AI 도구에 대한 불만 중 가장 많은 비율은 '거의 맞지만, 약간 다름'이 **66%**였습니다. 출력의 정확성을 '강하게 신뢰한다'는 응답은 3.1%였으나, 그럼에도 사용하거나 사용할 예정인 비율은 84%입니다. - METR 무작위 비교 시험(2025년 7월): 숙련된 개발자 16명 / 과제 246건에서 AI를 사용했을 때 실제 측정 결과 19% 느려졌습니다. 본인들의 사후 자가 평가는 '20% 빨라졌다'고 했습니다. 다만 METR 측에서는 이 수치가 2025년 초반 도구의 결과이며 현재는 구식이라고 주석을 달았습니다.

조건(100만 줄급 기존 OSS를 다루는 베테랑)이 개인 개발과는 매우 다르므로, 느려지는 부분은 적용되지 않을 가능성이 높습니다. 적용된다고 생각하는 부분은 '느림과 빠름의 구분이 당사자에게 명확하지 않았다'는 점뿐이라고 생각합니다.

3. 기원별 분류: Unity 사용법 오류는 1건

여기서 결정한 운영 방침

• 기능을 설계할 때 '이 기능이 작동하지 않을 경우 어디서 멈추는지'를 한 줄 추가합니다. 적을 수 없다면, 측정 절차를 먼저 작성하여 완료 조건에 포함시킵니다.
• 태스크가 끝날 때마다 오류가 어떤 방식으로 발견되었는지('① 멈춰서 깨달음 ② 측정해서 깨달음 ③ 플레이하면서 깨달음') 기록합니다. 속도를 체감으로 측정하지 않습니다.
• 점검 시간은 엔진 사용법이 아닌, 나만의 게임에만 존재하는 규칙에 할애합니다.
• Unity 버전은 LTS(Long Term Support)로 고정하고, 업그레이드하는 날짜를 스스로 정합니다 (새로운 버전일수록 AI는 모릅니다).

플레이해보면 하루 만에 발견됩니다. 코드를 읽어봐도 1개월 동안 나오지 않습니다. 88건을 나열했을 때 가장 많이 남은 것은 이것이었습니다.

출처

• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR, 2025)
• 2025 Developer Survey — AI (Stack Overflow)

유형별 상세 기록은 블로그에 유형별로 작성하고 있습니다: https://zade-ohajimari.blogspot.com/

Discussion