AI 코딩 도구 이야기는 요즘 너무 쉽게 양극단으로 갑니다. 한쪽에서는 “이제 개발자는 끝났다”고 말하고, 다른 쪽에서는 “자동화가 다 해결해준다”고 말합니다. 그런데 실제 게임 제작 현장에서는 둘 다 조금 뜬 이야기처럼 느껴질 때가 많습니다. 우리에게 중요한 건 AI가 코드를 쓸 수 있느냐가 아니라, 그 결과를 누가 이해하고, 누가 검수하고, 누가 문제가 생겼을 때 고칠 책임을 지느냐입니다.
Godot Foundation이 2026년 6월 30일 공개한 Changes to our Contribution Policies는 이 질문을 꽤 직접적으로 던졌습니다. Godot는 AI가 만든 대규모 코드 기여, 자율 AI 에이전트가 제출하는 PR, 그리고 사람 사이의 커뮤니케이션에 AI가 대신 쓴 텍스트를 더 엄격히 제한하겠다고 밝혔습니다. 겉으로 보면 오픈소스 프로젝트의 내부 규칙처럼 보이지만, 게임 개발자와 테크니컬 아티스트, 디자이너, VFX 아티스트 모두가 읽어볼 만한 이유가 있습니다.
게임 팀도 결국 같은 문제를 겪기 때문입니다. AI가 코드, 셰이더, 툴 스크립트, 블루프린트 보조 로직, 빌드 자동화, 문서 초안까지 빠르게 만들어줄 수는 있습니다. 하지만 그 속도가 팀의 검수 속도, QA 속도, 유지보수 능력까지 같이 올려주지는 않습니다. 오히려 “만드는 비용”만 낮아지고 “책임지는 비용”은 그대로 남을 때, 제작 파이프라인은 더 불안해질 수 있습니다.
이번 글은 Godot 정책을 단순한 찬반 뉴스로 다루기보다, 게임 팀이 AI 코딩 도구를 어떤 기준으로 도입해야 하는지 정리하는 가이드로 보려고 합니다. Unreal, Unity, Godot, 자체 엔진을 쓰는지와 상관없이 적용할 수 있는 이야기입니다.
AI가 만든 초안은 빠르게 늘어날 수 있지만, 팀의 검토와 책임 구조는 여전히 사람이 설계해야 합니다.
저는 이 뉴스를 보면서 “AI를 쓰면 안 된다”보다 “AI 사용을 팀의 제작 언어로 번역해야 한다”는 생각이 더 강하게 들었습니다. 툴을 쓰는 사람은 빠르게 만들 수 있다고 느끼지만, 리뷰하는 사람은 그 빠른 결과물의 의도와 안전성을 다시 천천히 확인해야 합니다. 이 속도 차이를 관리하지 않으면 팀은 어느 순간 자동화 덕분에 빨라진 것이 아니라, 자동화 때문에 더 많은 것을 의심해야 하는 상태가 됩니다.
1. Godot가 막으려는 것은 AI 자체가 아니라 검수 불가능한 속도입니다
Godot 공식 글에서 가장 먼저 보이는 문제는 PR 수가 늘어난 현실입니다. Godot는 몇 년 동안 많은 코드 기여를 받아왔고, 이것 자체는 건강한 신호라고 설명합니다. 사람들이 엔진에 관심을 갖고, 기능을 제안하고, 코드를 넣고 싶어 한다는 뜻이니까요. 하지만 동시에 리뷰 가능한 사람은 제한되어 있고, PR 리뷰는 매우 높은 집중력을 요구합니다.
이 배경을 최근 Godot 흐름과 같이 보면 더 선명합니다. Godot 4.7 릴리스는 300명 이상의 기여자와 1,600개 이상의 PR을 언급할 만큼 큰 규모의 커뮤니티 결과물입니다. 이런 생태계에서는 기여가 많다는 사실만으로는 충분하지 않습니다. 어떤 기여가 실제로 유지될 수 있는지, 어떤 기여가 다음 릴리스에서 회귀를 만들지 않을지, 누가 그 코드를 설명하고 고칠 수 있는지가 중요해집니다.
여기에 AI가 들어오면 균형이 더 흔들립니다. AI를 쓰면 PR 하나를 만드는 비용은 내려갑니다. 적어도 겉으로는 더 빨리 뭔가를 만들어낼 수 있습니다. 그런데 그 PR을 검토하는 유지보수자의 시간은 줄어들지 않습니다. 오히려 더 오래 걸릴 수 있습니다. 코드가 왜 이렇게 작성됐는지, 작성자가 실제로 이해하고 있는지, 테스트가 충분한지, 라이선스나 저작권 문제는 없는지까지 확인해야 하기 때문입니다.
이 지점이 게임 제작팀에도 그대로 들어옵니다. 예를 들어 AI가 에디터 툴 스크립트를 하나 만들어줬다고 해봅시다. 버튼을 누르면 머티리얼 인스턴스가 일괄 정리되고, Niagara 시스템 이름이 규칙에 맞게 바뀌고, 사용하지 않는 텍스처를 찾아준다고 합니다. 데모만 보면 좋아 보입니다. 하지만 실제 프로젝트에 넣는 순간 질문이 생깁니다.
- 삭제하면 안 되는 임시 에셋은 어떻게 구분하나?
- 머티리얼 파라미터 이름이 팀 규칙과 충돌하면 어떻게 되나?
- 소스 컨트롤에서 되돌릴 수 있는 단위로 동작하나?
- 아티스트가 실수로 전체 폴더에 실행했을 때 피해 범위는 어디까지인가?
- 빌드 머신이나 다른 OS에서도 같은 결과가 나오나?
AI가 첫 버전을 만들어주는 일은 생각보다 쉽습니다. 하지만 팀이 믿고 쓰는 내부 도구가 되려면 설명, 테스트, 롤백, 로그, 권한, 에러 처리까지 따라와야 합니다. Godot가 말하는 문제도 바로 여기에 가깝습니다. AI가 만든 산출물이 많아질수록, 사람의 검수 능력은 병목이 됩니다.
현장에서 더 무서운 경우는 버그가 즉시 터지지 않는 상황입니다. 잘못된 배치 스크립트가 모든 에셋을 망가뜨리면 차라리 바로 발견됩니다. 하지만 일부 머티리얼만 미묘하게 바뀌거나, 특정 플랫폼에서만 텍스처 압축 설정이 달라지거나, 테스트 맵에서는 멀쩡한데 실제 월드 스트리밍 환경에서만 레퍼런스가 끊기면 문제를 찾는 데 시간이 훨씬 오래 걸립니다. AI가 만든 코드는 “빨리 만들었다”는 장점이 있지만, 사람이 의도를 충분히 이해하지 못하면 “어디서부터 의심해야 하는지 모르는 코드”가 됩니다.
그래서 AI 도입의 첫 기준은 생성 속도가 아니라 관찰 가능성입니다. 로그가 남는가, 실행 전후 diff를 볼 수 있는가, dry-run 모드가 있는가, 특정 폴더나 브랜치에서만 제한 실행할 수 있는가, 실패했을 때 사용자에게 충분한 정보를 주는가를 먼저 봐야 합니다. 이런 장치가 없으면 자동화는 편의 기능이 아니라 프로젝트 전체를 건드리는 보이지 않는 리스크가 됩니다.
2. 이번 정책의 핵심은 세 단어로 볼 수 있습니다: 책임, 이해, 대화
Godot의 2026년 6월 30일 발표는 몇 가지 구체적인 방향을 제시했습니다. 자율 AI 에이전트 사용과 이른바 vibe coding을 금지하고, AI가 중요한 코드 덩어리를 생성하는 것을 허용하지 않으며, 사람과 사람 사이의 커뮤니케이션에 AI가 만든 텍스트를 쓰는 것도 제한하겠다는 내용입니다. 또 AI를 어떤 방식으로든 사용했다면 PR에서 공개해야 한다는 방향도 포함되어 있습니다.
여기서 인상적인 건 “AI가 틀릴 수 있다”보다 더 깊은 문제를 짚었다는 점입니다. Godot는 기여자가 자기 코드를 이해하고, 유지보수자에게 설명할 수 있어야 하며, 문제가 생겼을 때 고칠 책임을 질 수 있어야 한다고 봅니다. AI는 피드백을 받고 성장하는 미래 유지보수자가 아닙니다. 유지보수자가 긴 시간을 써서 리뷰를 해도, 그 피드백이 사람의 실력으로 축적되지 않으면 오픈소스 프로젝트 입장에서는 손해가 큽니다.
이건 게임 스튜디오에도 꽤 현실적인 이야기입니다. 팀 안에서 주니어 개발자가 어렵게 작성한 코드에는 리뷰 비용이 들어갑니다. 하지만 그 리뷰는 교육이 됩니다. 다음 작업의 품질이 올라가고, 팀의 공통 언어가 쌓입니다. 반면 누군가가 이해하지 못한 AI 코드를 계속 붙여 넣는다면 리뷰는 교육이 아니라 감시가 됩니다. 리뷰어는 “이 사람이 왜 이렇게 판단했지?”가 아니라 “이 코드 어디까지가 우연히 맞는 거지?”를 봐야 합니다.
디자이너와 아티스트 쪽도 비슷합니다. AI가 생성한 노드 그래프, 셰이더 코드, 블루프린트 유틸리티, Python 자동화 스크립트는 당장은 시간을 줄여줍니다. 하지만 작성자가 원리를 설명하지 못하면 팀은 그 산출물을 자산으로 쌓기 어렵습니다. 특히 VFX나 테크니컬 아트에서는 작은 수식 하나, 렌더 타이밍 하나, 파라미터 범위 하나가 화면 품질과 성능에 영향을 줍니다. “돌아가긴 한다”와 “팀이 이해하고 계속 고칠 수 있다”는 완전히 다른 상태입니다.
그래서 저는 이번 뉴스를 AI 반대 선언으로 읽기보다, 책임 없는 자동화를 거르는 기준으로 읽는 편이 맞다고 봅니다. 좋은 AI 도구 사용은 결과물을 감추는 것이 아니라, 사람이 무엇을 판단했고 무엇을 검증했는지 더 선명하게 남기는 쪽이어야 합니다.
특히 팀장이 봐야 할 포인트는 “누가 버튼을 눌렀는가”가 아닙니다. “누가 이 변경의 소유자인가”입니다. AI가 제안한 코드라도 최종적으로 병합하는 사람은 있어야 하고, 그 사람은 코드의 의도와 한계를 설명할 수 있어야 합니다. 테크 아티스트가 만든 툴이라면 담당 테크 아티스트가, 빌드 파이프라인 변경이라면 빌드 담당자가, 게임플레이 로직이라면 해당 시스템 오너가 책임을 가져야 합니다. 책임자가 없는 AI 산출물은 팀 자산이 아니라 임시 실험물로 남겨두는 편이 안전합니다.
3. 팀에서 AI를 허용할 작업과 막아야 할 작업을 먼저 나눠야 합니다
AI 도입은 “쓸까 말까”보다 “어디까지 쓸까”가 먼저입니다. Godot의 새 방향도 완전한 금지보다는 경계선을 세우는 쪽에 가깝습니다. 공식 기여 문서도 AI 사용을 권장하지는 않지만, 단일 라인 코드 완성이나 번역처럼 제한적인 보조 사용까지 모두 같은 수준으로 다루지는 않습니다. 중요한 건 산출물의 위험도입니다.
게임 팀 기준으로 보면 허용하기 좋은 영역은 비교적 명확합니다.
- 반복적인 이름 정리 초안
- 코드 주석이나 문서 초안의 구조 제안
- 이미 사람이 이해한 코드의 테스트 케이스 아이디어
- 로그 메시지, 에러 메시지, 체크리스트 초안
- Regex, 간단한 변환 스크립트, 일회성 데이터 정리 보조
- 블루프린트나 셰이더 그래프를 설명하는 학습용 요약
이런 작업은 틀려도 피해 범위가 작고, 사람이 최종 판단하기 쉽습니다. 반대로 조심해야 할 영역도 있습니다.
- 엔진 내부 동작을 바꾸는 코드
- 빌드, 패키징, 배포, 저장 데이터 마이그레이션
- 런타임 성능에 직접 영향을 주는 렌더링/셰이더/VFX 로직
- 에셋을 삭제하거나 대량 수정하는 자동화
- 보안, 계정, 결제, 네트워크, 서버 권한 관련 코드
- 팀 외부에 배포할 플러그인이나 오픈소스 PR
이 영역에서는 AI가 만든 초안을 그대로 넣는 순간 위험이 커집니다. 특히 게임 개발에서는 “한 번만 돌리면 되는 스크립트”가 나중에 제작 파이프라인의 중심 도구가 되는 일이 자주 있습니다. 처음엔 개인 폴더 정리용으로 만든 툴이, 어느 날 아트팀 전체가 쓰는 배치 툴이 됩니다. 그때 내부에 이해되지 않은 AI 코드가 숨어 있으면 문제를 추적하기 어렵습니다.
도입 가이드는 간단하게 시작할 수 있습니다. AI 사용을 허용하되, 다음 네 가지를 PR이나 작업 기록에 남기게 하는 것입니다.
1. AI가 관여한 범위
2. 사람이 직접 수정한 범위
3. 실제 테스트한 조건
4. 실패했을 때 되돌리는 방법
이 네 가지를 못 쓰면 아직 팀 코드에 넣기 이릅니다. 도구를 잘 쓰는 사람은 AI를 썼다는 사실을 숨기지 않습니다. 오히려 “이 부분은 초안 도움을 받았고, 이 테스트로 검증했고, 이 위험은 남아 있다”고 말할 수 있어야 합니다.
예를 들어 VFX 팀에서 사용하지 않는 Niagara 시스템 찾아서 정리하기 도구를 만든다고 해봅시다. AI에게 초안을 맡길 수는 있습니다. 하지만 최종 도구는 최소한 세 단계로 나누는 편이 좋습니다. 첫 번째는 읽기 전용 스캔입니다. 실제 삭제 없이 후보 목록과 참조 위치를 보여줘야 합니다. 두 번째는 샘플 프로젝트나 복사 브랜치에서의 시뮬레이션입니다. 세 번째가 실제 적용입니다. 이 과정에서 AI가 도와줄 수 있는 부분은 후보 찾기 로직, UI 문구 초안, 테스트 케이스 정리 정도입니다. 삭제 판단, 참조 예외 처리, 팀 규칙 반영은 사람이 가져가야 합니다.
또 하나의 기준은 “AI가 없을 때도 유지 가능한가”입니다. 특정 프롬프트를 다시 넣어야만 고칠 수 있는 툴은 위험합니다. 팀 문서, 코드 주석, 테스트, 실행 예시만 보고도 다른 사람이 이어받을 수 있어야 합니다. AI를 쓴 사실이 문제가 아니라, AI 없이는 아무도 고칠 수 없는 상태가 문제입니다.
팀 내부 규칙으로는 AI 산출물은 초안, 사람의 검증은 승인이라는 문장을 명확히 두는 것도 좋습니다. 이 한 줄만 있어도 문화가 달라집니다. AI가 제안한 코드를 가져오는 건 허용되지만, 그 코드를 병합할 때는 사람이 요구사항, 실패 조건, 성능 영향, 사용자 영향까지 설명해야 한다는 뜻입니다. 초안과 승인을 분리하면 AI 사용이 숨겨진 습관이 아니라 관리 가능한 제작 과정이 됩니다.
4. 코드 리뷰 병목은 결국 플레이어 경험까지 늦춥니다
Godot의 PR 워크플로 문서를 보면, 변경 하나가 들어가기까지의 과정은 단순하지 않습니다. 이슈나 아이디어가 나오고, PR이 열리고, triage와 area maintainer 요청이 붙고, 접근 방식 토론과 코드 리뷰가 이어지고, 충분한 승인이 있어야 병합됩니다. 문서에는 회귀 수정, 버그 수정, 기능 개선의 리뷰 기간 기대치도 나뉘어 있습니다. 또 beta 단계에서는 기능 동결이 들어가고, RC 단계에서는 중요한 수정 위주로만 받아들이는 식으로 릴리스 단계에 따라 기준이 달라집니다.
이 흐름은 오픈소스에만 있는 복잡성이 아닙니다. 게임 팀도 비슷합니다. 기능 브랜치가 열리고, 코드 리뷰가 붙고, QA 빌드가 만들어지고, 아트 리그레션 체크가 들어가고, 기획 검수가 이어집니다. 출시가 가까워질수록 새 기능보다 회귀와 안정화가 중요해집니다. 그래서 AI가 만든 변경이 늘어날 때 가장 먼저 흔들리는 곳은 개발 속도가 아니라 리뷰 우선순위입니다.
예를 들어 런처 최적화, 셰이더 캐시, 그래픽 옵션 저장, 컨트롤러 입력, 모바일 터치 UI 같은 영역은 플레이어가 바로 체감합니다. AI가 이 주변 코드를 빠르게 고쳤다고 해도, 리뷰어가 충분히 이해하지 못하면 팀은 더 보수적으로 움직일 수밖에 없습니다. 결국 “AI로 하루 만에 만들었다”가 “검수에 일주일 걸린다”로 바뀝니다.
테크니컬 아트 쪽에서는 이 문제가 더 미묘합니다. 셰이더 최적화 코드가 눈으로 보기에는 같은 결과를 내도, 특정 GPU에서 분기 비용이 늘거나, 모바일에서 precision 문제가 생기거나, HDR/톤매핑 환경에서 색이 달라질 수 있습니다. Niagara나 파티클 시스템 자동화도 마찬가지입니다. 에디터 안에서는 좋아 보여도 cooked build, 낮은 사양 장비, 긴 플레이 세션에서 다른 결과가 나올 수 있습니다.
플레이어 입장에서는 이런 과정이 보이지 않습니다. 하지만 결과는 바로 느낍니다. 첫 실행 로딩이 길어지거나, 패치 이후 특정 옵션에서 화면이 깜빡이거나, 컨트롤러 입력이 한 박자 늦거나, 이펙트가 많은 장면에서 프레임이 떨어지면 플레이어는 개발팀의 내부 사정을 고려하지 않습니다. AI가 만든 변경이든 사람이 직접 만든 변경이든, 최종 경험은 게임의 품질로 평가됩니다. 그래서 리뷰 병목은 단순한 개발팀 내부 문제가 아니라 플레이어 경험을 지키는 마지막 방어선입니다.
그래서 AI 도구를 쓰는 팀일수록 리뷰 기준은 더 구체적이어야 합니다. “잘 돌아감”이 아니라 다음을 확인해야 합니다.
- 어떤 입력 데이터로 테스트했는가?
- 빈 폴더, 잘못된 에셋, 손상된 레퍼런스에서도 안전한가?
- 로그가 남는가?
- 실패 시 중간 상태가 남지 않는가?
- 소스 컨트롤 diff가 사람이 읽을 수 있는가?
- 성능 변화가 측정됐는가?
- 플레이어가 체감하는 동작이 바뀌지 않았는가?
이런 기준이 없으면 AI는 팀을 빠르게 해주는 도구가 아니라, 리뷰어의 피로를 늘리는 도구가 됩니다. Godot가 이번에 강하게 선을 그은 것도 결국 리뷰라는 희소한 자원을 보호하기 위한 결정으로 볼 수 있습니다.
작은 팀일수록 이 부분을 가볍게 보면 안 됩니다. 대형 스튜디오는 코드 오너, QA 팀, 빌드 엔지니어, 플랫폼 담당자가 나뉘어 있을 수 있지만, 인디 팀이나 소규모 아트 중심 팀에서는 한 사람이 여러 역할을 겹쳐 맡습니다. AI로 산출물이 늘어나면 겉으로는 생산성이 올라간 것처럼 보이지만, 실제로는 검수해야 할 표면적이 급격히 넓어질 수 있습니다. 그러면 창작 시간이 줄고, 리뷰와 디버깅 시간이 늘어납니다. AI 도입을 생산성 투자로 만들려면 “더 많이 만들기”보다 “덜 위험하게 통과시키기”가 먼저입니다.
이 지점에서 프로젝트 단계별 판단이 필요합니다. 프리프로덕션에서는 빠른 실험이 중요하니 AI가 만든 코드나 툴을 가볍게 써볼 수 있습니다. 하지만 라이브 빌드에 들어가는 순간 기준은 바뀝니다. 플레이어 데이터, 세이브, 결제, 네트워크, 플랫폼 SDK, 그래픽 옵션, 접근성 옵션처럼 복구 비용이 큰 영역에서는 AI 초안을 그대로 믿으면 안 됩니다. 같은 코드라도 샘플 맵에서 돌리는 것과 실제 서비스 브랜치에 넣는 것은 전혀 다른 결정입니다.
5. 아트와 디자인 파이프라인에서는 “생성”보다 “검증 가능한 자동화”가 더 중요합니다
AI 이야기를 코드에만 묶어두면 반쪽짜리입니다. 실제 게임 제작에서는 디자이너와 아티스트도 점점 더 많은 자동화 도구를 씁니다. 레벨 데이터 검증, 아이템 테이블 정리, 이펙트 프리셋 생성, 머티리얼 인스턴스 일괄 수정, LOD/나나이트/콜리전 설정 확인, 텍스처 압축 프리셋 검사 같은 작업은 모두 AI 보조의 유혹이 큰 영역입니다.
아트와 테크니컬 아트 파이프라인에서 중요한 것은 더 많은 생성물이 아니라, 팀이 검증할 수 있는 자동화 흐름입니다.
하지만 여기서도 핵심은 생성이 아니라 검증입니다. AI가 “이펙트 프리셋 30개를 만들어줬다”는 것보다, 그 프리셋이 팀의 명명 규칙, 성능 예산, 플랫폼별 옵션, 카메라 거리, 게임플레이 가독성에 맞는지가 훨씬 중요합니다. 플레이어는 우리가 어떤 도구로 만들었는지 모릅니다. 화면이 지저분하거나, 전투 중 피격 신호가 안 보이거나, 프레임이 흔들리면 그냥 게임 경험이 나빠졌다고 느낍니다.
특히 VFX와 Material, Shader 작업에서는 AI가 만든 결과를 바로 믿기 어렵습니다. 그럴듯한 수식, 그럴듯한 노드 이름, 그럴듯한 코드 구조가 실제 비용과 안정성을 보장하지 않기 때문입니다. 그래서 AI를 쓸 때는 다음처럼 역할을 좁히는 편이 좋습니다.
- 반복 설정을 찾는 감시자
- 테스트 케이스를 떠올리는 보조자
- 문서 초안을 만드는 정리자
- 이미 사람이 고른 규칙을 적용하는 도우미
- 위험 후보를 표시하는 리뷰 전 단계 필터
반대로 AI를 “최종 판단자”로 두면 위험합니다. 어떤 이펙트가 화면에서 과한지, 어떤 Shader variation이 실제 플랫폼에서 부담인지, 어떤 툴 버튼이 아티스트에게 실수하기 쉬운지는 결국 프로젝트 맥락을 아는 사람이 판단해야 합니다. Godot가 말한 사람의 책임성은 코드 리뷰에만 해당하지 않습니다. 제작 파이프라인 전체에 적용됩니다.
이 관점은 디자이너에게도 유용합니다. AI가 밸런스 테이블을 제안할 수는 있지만, 플레이 감각은 테스트해야 합니다. AI가 퀘스트 조건을 정리할 수는 있지만, 플레이어가 이해하는 순서는 사람이 봐야 합니다. AI가 UI 문구를 빠르게 바꿀 수는 있지만, 실제 화면에서 길이와 리듬, 문화적 뉘앙스는 검수해야 합니다. 결국 좋은 자동화는 사람의 판단을 대체하지 않고, 사람이 더 빨리 판단할 수 있도록 증거를 정리해줍니다.
교육 관점에서도 같은 결론이 나옵니다. AI가 만든 셰이더 코드를 그대로 보여주는 튜토리얼은 금방 낡습니다. 반면 AI가 제안한 셰이더를 사람이 어떻게 읽고, 어떤 노드를 의심하고, 어떤 GPU 비용을 확인하고, 어떤 화면 기준으로 통과시켰는지를 보여주는 콘텐츠는 오래 갑니다. VFX Diary 같은 블로그에서는 이 차이가 중요합니다. 독자가 필요한 것은 “AI가 대신 만들어줬다”는 자랑보다, 자기 프로젝트에 가져갈 수 있는 판단 기준입니다.
또 하나 생각해볼 부분은 팀 커뮤니케이션입니다. AI가 정리한 피드백 문장은 부드럽고 깔끔할 수 있습니다. 하지만 아트 리뷰에서는 때로 거친 초안보다 구체적인 관찰이 더 중요합니다. “이 이펙트가 과합니다”보다 “보스 공격 전조 이펙트가 배경 광원과 같은 색이라 회피 타이밍이 묻힙니다”가 훨씬 쓸모 있습니다. AI가 문장을 다듬어도, 관찰은 사람이 해야 합니다. Godot가 사람 사이의 AI 생성 텍스트를 조심하는 것도 이런 맥락으로 확장해볼 수 있습니다.
6. 오픈소스, 에셋 스토어, 포트폴리오에서는 신뢰가 더 큰 자산이 됩니다
Godot는 최근 4.7 릴리스와 4.7.1 RC1 흐름을 통해 엔진과 생태계가 계속 커지고 있음을 보여주고 있습니다. 4.7 릴리스 페이지는 300명 이상의 기여자와 1,600개 이상의 PR을 언급했고, 2026년에 Steam에 올라온 Godot 게임 수와 itch.io 생태계의 활발함도 강조했습니다. 2026년 7월 1일 공개된 4.7.1 RC1은 안정판 이후 바로 이어지는 회귀 수정 흐름을 보여줍니다. 27명의 기여자가 41개 개선을 넣었고, 렌더링, 입력, GUI, 네트워크, 내비게이션 같은 영역의 회귀를 다룹니다.
이런 성장 국면에서 AI 기여 정책이 강해지는 건 이상한 일이 아닙니다. 생태계가 커질수록 “누구나 만들 수 있음”만으로는 부족해집니다. “믿고 받을 수 있음”, “문제가 생기면 고칠 수 있음”, “리뷰어의 시간을 존중함”이 더 중요해집니다. 엔진, 플러그인, 애드온, 샘플 프로젝트, 튜토리얼 모두 마찬가지입니다.
AI를 썼다는 사실보다, 결과물을 어떻게 검증하고 설명 가능한 제작 자산으로 바꾸었는지가 포트폴리오의 신뢰를 만듭니다.
개인 포트폴리오에도 이 관점은 중요합니다. 요즘은 AI로 만든 코드나 툴 데모를 보여주는 사람이 많습니다. 그래서 단순히 “AI를 써서 만들었습니다”는 더 이상 강한 메시지가 아닙니다. 오히려 다음을 보여주는 포트폴리오가 더 설득력 있습니다.
- 어떤 문제를 풀려고 했는가?
- 어떤 부분을 AI 도움으로 빠르게 만들었는가?
- 어떤 부분은 사람이 직접 설계하고 고쳤는가?
- 테스트는 어떻게 했는가?
- 실패 사례와 제한 사항은 무엇인가?
- 팀원이 쓰게 하려면 어떤 안전장치를 추가했는가?
이런 기록은 블로그나 유튜브 교육 콘텐츠로도 좋습니다. 예를 들어 AI로 만든 Unreal 에디터 툴을 실제 팀 도구로 바꾸는 과정, Niagara 프리셋 자동 생성기를 검증 가능한 툴로 만드는 법, Godot/Unity/Unreal 프로젝트에서 AI 코드 리뷰 체크리스트 만들기 같은 주제는 단순한 뉴스 요약보다 오래 갑니다. AI를 썼다는 사실보다, AI 결과물을 제작 자산으로 바꾸는 기준이 더 가치 있기 때문입니다.
저는 앞으로 기술 포트폴리오에서 “생성 속도”보다 “검수 가능한 구조”가 더 크게 보일 거라고 봅니다. 게임 업계는 결국 팀 작업입니다. 혼자 만든 프로토타입도 언젠가 다른 사람이 읽고, 수정하고, 테스트하고, 이어받아야 합니다. AI가 들어간 작업일수록 그 연결성을 더 잘 보여줘야 합니다.
이건 구직자에게도 꽤 현실적인 조언입니다. 면접에서 “AI로 만들었습니다”라고 말하면 다음 질문은 거의 정해져 있습니다. 어느 부분을 직접 이해했는지, 어떤 버그를 겪었는지, 왜 그 구조를 선택했는지, 팀 프로젝트라면 다른 사람이 어떻게 쓸 수 있는지입니다. 이 질문에 답할 수 있으면 AI 사용은 약점이 아니라 작업 방식을 설명하는 재료가 됩니다. 답할 수 없다면 결과물이 아무리 그럴듯해도 신뢰를 얻기 어렵습니다.
7. 지금 팀에서 바로 정할 수 있는 AI 코딩 룰
Godot 정책을 그대로 복사할 필요는 없습니다. 오픈소스 엔진과 내부 게임 팀은 상황이 다릅니다. 하지만 원칙은 충분히 가져올 수 있습니다. 작은 팀이라면 너무 복잡한 규정보다, 실제로 지킬 수 있는 짧은 룰이 낫습니다.
먼저 AI 사용 신고 기준을 정합니다. 모든 자동완성까지 기록하라는 뜻은 아닙니다. 하지만 함수 단위 이상의 코드, 데이터 변환 스크립트, 빌드/배포 관련 수정, 대량 에셋 처리 자동화, 외부 배포용 플러그인에는 AI 사용 여부와 범위를 남기게 하는 편이 좋습니다.
둘째, 위험도별 리뷰 단계를 나눕니다. 문서 초안이나 일회성 로그 정리는 작성자 확인으로 충분할 수 있습니다. 반면 프로젝트 파일을 대량 수정하는 스크립트는 별도 샘플 프로젝트에서 먼저 돌리고, 소스 컨트롤 diff를 리뷰하고, 롤백 절차를 확인해야 합니다. 런타임 코드나 렌더링/셰이더/VFX 성능 관련 변경은 측정 결과가 붙어야 합니다.
셋째, “설명 못 하면 병합하지 않는다”는 기준을 둡니다. 작성자가 코드 흐름, 실패 조건, 테스트 방식, 남은 리스크를 설명하지 못하면 아직 팀 코드가 아닙니다. 이 기준은 주니어를 혼내기 위한 규칙이 아니라, 팀이 모르는 코드를 제품 안에 넣지 않기 위한 최소 장치입니다.
여기서 설명은 거창한 발표가 아니어도 됩니다. 짧은 PR 설명, 테스트 영상, before/after 스크린샷, 체크리스트, 실패 사례 하나면 충분할 때가 많습니다. 중요한 건 리뷰어가 추측하지 않아도 되는 상태를 만드는 것입니다. AI 사용이 늘수록 좋은 PR 설명의 가치는 더 올라갑니다. 코드 자체가 빠르게 만들어질수록, 사람이 의도를 확인할 수 있는 문맥이 더 필요해지기 때문입니다.
넷째, AI가 만든 커뮤니케이션을 조심합니다. Godot가 사람 사이의 AI 생성 텍스트를 문제 삼은 부분은 생각보다 중요합니다. 리뷰 요청, 버그 리포트, 기획 설명, 아트 피드백은 단순한 문장이 아니라 협업의 신뢰를 만드는 과정입니다. AI가 문장을 다듬어줄 수는 있지만, 실제로 무엇을 했고 무엇을 모르는지는 사람이 직접 말해야 합니다.
다섯째, 교육용 사용과 제품용 사용을 분리합니다. 학습 단계에서는 AI에게 셰이더 수식 설명을 시키고, 코드 예시를 받아보고, 에러 메시지를 풀어보는 것이 큰 도움이 됩니다. 하지만 제품 브랜치에 들어가는 순간 기준은 달라져야 합니다. 학습용으로 유용한 것과 배포용으로 안전한 것은 같지 않습니다.
이 정도만 정해도 팀 분위기가 달라집니다. AI를 몰래 쓰는 문화가 아니라, AI를 썼더라도 책임 있게 검증하는 문화가 됩니다. 개인적으로는 이쪽이 훨씬 현실적인 방향이라고 봅니다.
마지막으로, 팀의 AI 규칙은 한 번 정하고 끝나는 문서가 아닙니다. 프로젝트 단계에 따라 바뀌어야 합니다. 프로토타입 단계에서는 허용 범위를 넓혀도 됩니다. 많이 시도하고 빨리 버리는 것이 중요하니까요. 반대로 베타, RC, 출시 직전, 라이브 서비스 패치 단계에서는 기준을 좁혀야 합니다. Godot PR 문서가 릴리스 단계에 따라 기능, 버그, critical fix의 우선순위를 다르게 보는 것처럼, 게임 팀도 제작 단계별 AI 사용 기준을 다르게 가져가야 합니다. 같은 도구라도 언제 쓰느냐에 따라 위험도가 달라집니다.
실제로 문서화할 때는 길게 쓸 필요가 없습니다. 허용, 검토 필요, 금지 또는 리드 승인 필요 세 칸으로 표를 만들고, 각 칸에 예시를 넣으면 충분합니다. 허용에는 문서 초안, 테스트 아이디어, 간단한 변환 보조를 넣습니다. 검토 필요에는 내부 툴, 런타임 로직, 셰이더 변경, 대량 에셋 처리를 넣습니다. 리드 승인 필요에는 저장 데이터, 빌드 시스템, 플랫폼 SDK, 보안/계정/결제, 외부 배포 플러그인을 넣습니다. 이 정도만 있어도 팀원은 어디서부터 질문해야 하는지 알 수 있습니다.
Godot의 AI 기여 제한, 우리 팀 AI 코딩 룰을 다시 세울 신호입니다 작업 메모
Godot의 2026년 6월 30일 AI 기여 정책 변경은 단순히 “AI 코딩 금지”로 소비하기에는 아깝습니다. 이 뉴스가 진짜로 보여주는 것은 생성 속도와 검수 능력 사이의 불균형입니다. AI가 더 많은 코드를 더 빨리 만들수록, 팀은 더 명확한 리뷰 기준과 책임 구조를 가져야 합니다.
게임 개발자는 이미 복잡한 제작 파이프라인 안에서 일합니다. 코드, 아트, 셰이더, VFX, UI, 입력, 빌드, QA, 플랫폼 대응이 서로 얽혀 있습니다. 이 안에 AI가 들어오면 속도는 올라갈 수 있지만, 책임이 사라지지는 않습니다. 오히려 누가 이해했고, 누가 테스트했고, 누가 고칠 수 있는지가 더 중요해집니다.
그래서 이번 소식은 Unreal, Unity, Godot 사용자 모두에게 의미가 있습니다. AI 도구를 쓰지 말자는 이야기가 아닙니다. AI를 쓰려면 팀의 언어로 설명하고, 테스트하고, 기록하고, 되돌릴 수 있어야 한다는 이야기입니다. 앞으로 좋은 개발자는 AI를 많이 쓴 사람이 아니라, AI가 만든 결과를 팀이 믿을 수 있는 제작 자산으로 바꿀 줄 아는 사람이 될 가능성이 큽니다.
저는 이 기준이 앞으로 더 중요해질 거라고 봅니다. AI 도구는 계속 좋아질 것이고, 팀은 결국 더 많은 자동화 결과물을 보게 될 것입니다. 그럴수록 차이를 만드는 것은 프롬프트 실력 하나가 아니라, 결과물을 제품 코드와 제작 파이프라인 안으로 들여보내는 판단력입니다.
참고 출처
- Godot Engine,
Changes to our Contribution Policies, 2026-06-30: https://godotengine.org/article/contribution-policy-2026/ - Godot contributing documentation,
Pull request rules and guidelines: https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html - Godot contributing documentation,
Pull request workflow: https://contributing.godotengine.org/en/latest/pull_requests/pr_workflow.html - Godot contributing documentation,
Introduction to engine contributions: https://contributing.godotengine.org/en/latest/engine/introduction.html - Godot Engine,
Release candidate: Godot 4.7.1 RC 1, 2026-07-01: https://godotengine.org/article/release-candidate-godot-4-7-1-rc-1/ - Godot Engine,
Godot 4.7, Lights, Camera, Action!, 2026-06-18: https://godotengine.org/releases/4.7/