혼자 미니게임 만들기: AI에 맡길 일과 직접 판단해야 할 일

몇 주 동안 AI로 코드를 작성해 기능은 모두 돌아가게 만들었는데, 핵심 로직 하나를 고치려는 순간 전체 아키텍처가 얽혀 있다는 사실을 알게 됩니다. 한 곳을 건드리면 다른 곳이 줄줄이 무너집니다. 결국 어떤 개발자는 AI가 쓴 코드를 전부 지우고 처음부터 직접 다시 작성했습니다. 반대로 어떤 사람은 AI를 써서 오후 한 번에 미니게임 프로토타입 8개를 끝까지 플레이할 수 있는 수준으로 만들었습니다. 예전이라면 최소 일주일은 걸렸을 작업입니다. 두 경험은 모두 실제이지만, 서로 완전히 다른 결론을 가리킵니다.

GDC 2026 데이터에 따르면 개발자의 52%는 AI가 게임 업계에 부정적 영향을 준다고 봅니다. 2년 전보다 거의 세 배 늘어난 수치입니다. 아트 직군의 반대율은 64%로 가장 높고, 관리자의 AI 사용률은 47%인 반면 일선 실무자는 29%에 그칩니다. 온도 차가 뚜렷합니다. 게임 개발에서 AI는 만병통치약도 아니고 재앙도 아닙니다. 문제는 경계입니다. 특히 인디 개발에는 경계 감각이 더 필요합니다. 1인 팀에는 실수를 받아 줄 여분의 인력이 없기 때문에 AI를 잘못 쓰면 대가가 그대로 돌아오고, 제대로 쓰면 효율은 몇 배까지 올라갑니다.

이 글은 AI가 무엇을 할 수 있는지 다루지 않습니다. 그런 글은 이미 충분히 많습니다. 여기서 말하려는 것은 AI가 무엇을 할 수 없는지, 그리고 더 중요한 질문입니다. 언제 반드시 직접 판단해야 하는가.

핵심 질문은 단순합니다. 구체적인 작업 앞에서 이것을 AI에 맡길 것인가, 직접 할 것인가? 답은 ‘할 수 있느냐’가 아니라 ‘맡겨도 되느냐’에 있습니다.

AI가 할 수 있는 일 - 반복 작업은 AI에 맡기기

먼저 분명히 해둘 것이 있습니다. 게임 개발에서 AI가 정말 쓸 만한 영역은 몇 가지 있습니다. ‘쓸 수도 있다’ 수준이 아니라, 실제로 써 보면 시간이 확실히 줄어드는 영역입니다.

1년 넘게 써 보면서 함정도 밟았고 장점도 느꼈습니다. 정리하면 AI에 맡길 수 있는 작업은 한 부류입니다. 표준 답이 있고, 반복성이 강하며, 창의적 가치가 낮은 작업입니다.

코드 생성과 자동 완성

프로토타입 검증에서는 AI의 효율이 눈에 보입니다.

NetEase의 한 심층 기사에는 이런 사례가 나옵니다. 기획자가 브레인스토밍 회의에서 요구사항을 쪼개고 초안을 쓰면, Bot이 옆에서 듣고 있다가 회의 후 바로 실행 가능한 프로토타입 코드를 출력합니다. 예전에는 이런 프로토타입을 만드는 데 일주일이 걸렸지만, 이제는 오후 한 번이면 끝납니다.

Zhihu에도 비슷한 피드백이 있습니다. 어떤 개발자는 수학 문제나 엔진 API 지식은 AI가 몇 초 만에 답을 준다고 말했습니다. “예를 들어 Unity Animator를 어떻게 쓰는지, URP RenderFeature를 어떻게 설정하는지 같은 것은 문서를 한참 뒤져야 했는데, AI는 한 문장으로 정리해 줍니다.”

제 경험도 비슷합니다. 탑다운 RPG의 기본 이동 로직을 작성할 때 AI가 준 코드 골격은 바로 쓸 수 있었습니다. 이후 조작감 조정과 충돌 검사는 제가 보완했지만, 뼈대는 AI가 만들었습니다.

Sohu의 실측 자료에는 40분 안에 탑다운 RPG Demo 기능의 약 70%를 완성했다는 데이터가 있습니다. 저는 이 수치를 믿습니다. 제 속도도 거의 비슷했기 때문입니다.

다만 여기서 말하는 것은 ‘골격’과 ‘프로토타입 검증’입니다. 정식 출시 전에는 AI가 준 코드를 직접 한 번 훑어야 합니다. 최적화할 것은 최적화하고, 리팩터링할 것은 리팩터링해야 합니다. AI가 프로덕션급 코드를 바로 줄 것이라고 기대하면 안 됩니다.

문구 대량 생성

이 영역은 AI의 강점입니다. NPC 대화, 퀘스트 설명, 아이템 설명, 업적 이름은 모두 채우기 성격의 텍스트입니다. 창의성은 아주 높지 않지만 양이 많습니다.

NetEase의 시나리오 기획자는 이런 방법을 공유했습니다. ‘짐 나르는 일’에 가까운 채우기 문구는 AI에 던지면 몇 분 만에 끝납니다. 그다음 직접 교정하고 표현을 다듬으며, AI 출력과 비교해 자신의 결과물을 보정합니다.

“우리는 AI를 대조군으로 두고, 내가 쓴 문구와 명확한 격차가 있는지 확인합니다.” 이 방식은 꽤 실용적입니다. AI는 당신을 대체하는 것이 아니라 결과물을 보정하도록 돕습니다.

Sohu의 가이드에서는 AI가 초반 단계 퀘스트 10개를 생성할 수 있으며, 트리거 조건과 보상 메커니즘까지 포함할 수 있다고 언급합니다. 이런 구조화된 콘텐츠는 AI가 꽤 잘 처리합니다.

저도 AI로 아이템 설명 50개 정도를 작성한 적이 있습니다. 걸린 시간은 15분이었습니다. 직접 썼다면 최소 두 시간은 걸렸을 겁니다. 품질 차이는 거의 없었습니다. 아이템 설명 자체가 아주 높은 창의성을 필요로 하지 않고, 정확하고 간결하며 세계관에 맞기만 하면 되기 때문입니다.

아트 프로토타입 생성

아트는 논쟁이 가장 큰 영역이지만, Demo 단계에서는 사실 쓸 수 있습니다.

Zhihu의 한 개발자는 Demo 단계에서 AI로 임시 아트를 생성했는데 “보기에도 꽤 괜찮았다”고 말했습니다. 핵심은 그대로 출시할 생각을 하지 않는 것입니다. 인체 구조 오류, 스타일 불일치, 거친 디테일은 전문 아티스트가 수정해야 합니다.

저도 Demo 하나를 만들면서 AI로 캐릭터 색 블록과 배경 이미지를 생성한 적이 있습니다. 친구들에게 보여 주니 “괜찮다”는 반응이었습니다. 하지만 저는 그것이 임시 방안일 뿐이라는 것을 알고 있었습니다. 실제로 출시하려면 결국 사람에게 의뢰해 그려야 합니다.

인디 개발자 관점에서 Demo 단계의 AI 아트는 현실적인 선택입니다. 아티스트를 고용할 예산은 없지만, 플레이를 검증하려면 시각화된 무언가가 필요하기 때문입니다.

핵심은 임시로는 쓸 수 있지만, 정식 출시에는 안 된다는 점입니다.

아이디어 확장과 프로토타입 검증

이 영역에서 AI의 역할은 ‘참고 보조자’에 더 가깝습니다.

Sohu 가이드는 Ludo.ai를 언급합니다. Steam과 TapTap 데이터를 분석해 게임 콘셉트를 생성할 수 있습니다. 이런 시장 조사 성격의 출력은 AI가 사람보다 빠릅니다. 데이터가 많고 차원이 다양하며, 사람이 직접 분석하기에는 너무 느립니다.

ACM 논문도 AI가 창의적 과정을 지원할 수 있지만 창의적 의사결정을 대체해서는 안 된다고 말합니다. 쉽게 말해 AI는 여러 선택지를 줄 수 있지만, 무엇을 고를지는 직접 결정해야 합니다.

저는 AI로 GDD 골격을 만들어 본 적이 있습니다. 핵심 플레이 설명을 하나 주자 AI가 가능한 확장 방향 5가지를 출력했습니다. 저는 그중 2개를 골라 더 깊게 생각했습니다. AI의 일은 ‘생각의 폭을 넓히는 것’이지 ‘결정하는 것’이 아닙니다.

AI가 할 수 없는 일 - 반드시 직접 판단해야 하는 것들

앞에서는 AI에 맡길 수 있는 일을 이야기했습니다. 이제 맡기면 안 되는 일을 이야기하겠습니다.

이 부분이 더 중요합니다. AI를 잘못 쓰는 대가는 AI를 쓰지 않는 것보다 더 클 때가 많기 때문입니다.

창의적 의사결정과 게임 감각

핵심 플레이, 세계관, 감정 경험은 AI가 정말 할 수 없습니다.

ACM 논문에는 날카로운 관점이 있습니다. “AI는 게임에 대한 이해가 없다.” AI는 코드를 어떻게 쓰는지는 알지만, 무엇이 ‘재미있다’는 감각인지는 모릅니다.

Medium 글은 더 직접적으로 말합니다. 게임의 마법은 코드가 아니라 ‘feel’에 있습니다. 조작감, 리듬, 감정의 흐름은 개발자가 직접 경험하고 조정해야 합니다.

Stardew Valley의 제작자 Eric Barone은 AI에 반대하는 업계 대표 인물 중 하나입니다. 그는 “인간의 창의성은 영혼 없는 기계보다 우선해야 한다”고 말했습니다. 다소 과격하게 들릴 수 있지만, 창작자의 관점에서는 맞는 말입니다. 농사 게임의 리듬감, 마을 주민과의 따뜻한 상호작용, 수확할 때의 만족감은 코드만으로 표현되는 것이 아닙니다. 디자이너가 반복해서 다듬어 만든 경험입니다.

저도 핀볼 게임을 만든 적이 있습니다. AI가 준 물리 파라미터는 처음부터 돌아갔습니다. 하지만 ‘손맛’이 맞지 않았습니다. 공의 반발이 너무 딱딱했고, 리듬은 너무 빨랐으며, 플레이어에게 제어감이 없었습니다. 사흘 동안 수많은 파라미터를 바꾼 끝에야 ‘시원하지만 통제 불능은 아닌’ 감각을 찾았습니다.

AI는 코드를 줄 수 있지만 ‘손맛’은 줄 수 없습니다.

아트 스타일 통제

아트는 논쟁이 가장 큰 영역이자 AI가 가장 쉽게 문제를 일으키는 영역입니다.

Zhihu 피드백에는 AI가 인체 구조를 잘못 생성해 전문 아티스트의 수정이 필요하다는 이야기가 나옵니다. 손가락 개수가 틀리거나, 원근 관계가 어긋나거나, 빛과 그림자가 어색한 문제는 AI에서 흔히 보이며 플레이어도 한눈에 알아봅니다.

Reddit에서는 AI 아트가 “정해진 아트 방향을 따를 수 없다”는 불만도 나왔습니다. 픽셀 스타일을 원했는데 AI는 카툰 스타일을 주고, 차가운 색조를 원했는데 AI는 따뜻한 색을 줍니다. 스타일 일관성은 게임 아트의 핵심인데, AI는 이 부분에서 거의 재앙에 가깝습니다.

일선 아티스트들은 AI를 써 본 뒤 이런 사실을 알게 됩니다. AI가 주는 결과물은 믿기 어렵고, 수정하는 일이 새로 그리는 것보다 더 피곤합니다.

저도 Demo를 만들면서 AI로 캐릭터 초상화를 생성한 적이 있습니다. 결과적으로 캐릭터 5명의 스타일이 완전히 달랐습니다. 하나는 카툰, 하나는 실사, 하나는 픽셀, 하나는 애니메이션풍, 하나는 무슨 스타일인지 알 수 없었습니다. 결국 전부 지우고 아티스트를 찾아 다시 그렸습니다.

스타일 일관성은 AI의 약점입니다. 이 문제는 현재로서는 해결책이 없습니다.

아키텍처 설계와 문제 이해

이 영역은 Reddit의 ‘모든 코드를 지우고 처음부터 다시 쓴’ 사례의 핵심 문제입니다.

AI가 준 코드는 돌아갑니다. 하지만 아키텍처는 자주 얽혀 있습니다. 기능 간 결합이 심하고, 한 곳을 바꾸면 여러 곳에 영향을 줍니다. 이런 코드를 ‘아키텍처 악몽’이라고 부릅니다.

ACM 논문은 AI를 “Ill-Informed Co-Worker”라고 표현합니다. 기술 능력은 있지만 깊은 이해가 부족한 동료라는 뜻입니다. AI는 기능을 구현하는 방법은 알지만 왜 그렇게 구현해야 하는지, 그 구현이 미래에 어떤 영향을 주는지는 모릅니다.

Zhihu의 한 개발자는 아주 잘 정리했습니다. “사고방식의 문제는 AI가 도와줄 수 없다.”

사고방식의 문제란 무엇일까요? 예를 들면 다음과 같습니다.

• 게임의 핵심 메커니즘은 무엇인가?
• 각 시스템은 어떻게 상호작용해야 하는가?
• 이후 확장 방향은 무엇인가?
• 성능 병목은 어디에 있는가?

이 질문들에는 표준 답이 없습니다. 개발자가 직접 생각해야 합니다. AI는 보조할 수 있지만 결정할 수는 없습니다.

Reddit 원문에는 이런 문장이 있습니다. “AI를 쓰면 롤백과 조정 능력이 심각하게 제한된다.” 아키텍처가 명확하지 않기 때문에 로직 하나를 고치려 해도 영향 범위가 너무 커져 손댈 수 없게 됩니다.

보안과 유지보수 통제

SonarSource의 분석은 AI 코드에 보안 취약점이 숨어 있을 수 있다고 말합니다. 입력 검증 누락, 권한 검사 누락, 민감 데이터 노출은 AI가 쉽게 놓치는 세부 사항이며 출시 후에는 치명적인 문제가 됩니다.

독일 연방정보보안청의 권고는 AI 코드 도우미에는 경험 있는 개발자의 감독이 필요하다는 것입니다. 완전히 쓰지 말라는 뜻이 아니라, 사용한 뒤 사람이 검토해야 한다는 뜻입니다.

장기 유지보수 관점에서 AI 코드의 문제는 더 은밀합니다. AI가 주는 코드는 주석, 문서, 설계 설명이 없는 경우가 많습니다. 세 달 뒤 수정하려고 열어 보면 당시 왜 이렇게 썼는지 이해할 수 없습니다.

저도 이 함정을 밟은 적이 있습니다. AI가 생성한 한 모듈은 출시 후 정상적으로 돌아갔습니다. 반년 뒤 새 기능을 추가하려고 코드를 열었더니 완전히 낯설었습니다. 변수명은 혼란스럽고, 로직 흐름은 이상하며, 주석은 없었습니다. 결국 이틀 동안 리팩터링했습니다. 처음부터 직접 썼을 때보다 더 느렸습니다.

AI는 개발 시간을 줄여 줄 수 있지만, 유지보수 시간까지 줄여 준다고 보장하지는 않습니다. 이 점을 많은 사람이 놓칩니다.

판단 프레임워크 - 언제 맡기고 언제 직접 해야 할까

앞의 두 부분에서는 ‘할 수 있는 일’과 ‘할 수 없는 일’을 이야기했습니다. 하지만 실제 개발에서 마주치는 작업은 대부분 그 사이에 있습니다.

이때 필요한 것이 판단 프레임워크입니다.

지식형 문제 vs 사고형 문제

Zhihu의 한 개발자는 아주 실용적인 판단법을 정리했습니다. “지식형 문제는 AI에게 묻고, 사고형 문제는 직접 해결한다.”

지식형 문제란 무엇일까요? 절대적으로 맞는 답이 있는 문제입니다. 예를 들면 다음과 같습니다.

• Unity Animator에서 상태 머신은 어떻게 설정하는가?
• Cocos Creator에서 충돌 검사는 어떻게 구현하는가?
• 이 수학 공식은 어떻게 계산하는가?

이런 문제는 AI가 정확한 답을 줄 수 있습니다. 답이 하나이고 검증할 수 있기 때문입니다.

사고형 문제란 무엇일까요? 절대적으로 맞는 답이 없고, 미감과 경험의 판단이 필요한 문제입니다. 예를 들면 다음과 같습니다.

• 핵심 플레이가 재미있는가?
• 세계관이 일관적인가?
• 조작감이 매끄러운가?

이런 문제에는 AI가 답을 줄 수 없습니다. 답은 당신의 미감, 목표 플레이어, 디자인 철학에 달려 있기 때문입니다.

제 판단 습관은 이렇습니다. 문제를 만나면 먼저 스스로 묻습니다. “이 문제에는 표준 답이 있는가?”

있다면 AI에게 묻습니다.
없다면 직접 생각합니다.

예를 들어 점프 로직을 작성할 때 AI는 코드 골격을 줄 수 있습니다. 하지만 점프 높이가 어느 정도가 적당한지, 체공 시간이 얼마나 길어야 하는지, 착지 피드백을 어떻게 만들지는 직접 조정해야 합니다. ‘손맛’에는 표준 답이 없기 때문입니다.

프로토타입 단계 vs 정식 단계

단계 판단도 중요합니다.

프로토타입 단계의 목표는 아이디어의 가능성을 검증하는 것이지 출시 품질을 만드는 것이 아닙니다. 이때는 AI를 과감히 써도 됩니다. 코드는 돌아가면 되고, 아트는 색 블록으로 대체해도 되며, 문구도 대충 넣어도 됩니다.

정식 단계는 플레이어를 마주하는 단계이며 완성된 경험을 추구합니다. 이때는 사람이 반드시 통제해야 합니다. 코드는 리팩터링하고, 아트는 정교하게 다듬고, 문구는 손봐야 합니다.

Sohu의 실측 자료는 40분 안에 RPG Demo 기능의 70%를 완성했다고 말합니다. 이것은 프로토타입 단계의 이야기입니다. 이 Demo를 정식 출시 제품으로 만들려면 40분으로는 턱없이 부족합니다. 나머지 30%의 핵심 기능을 완성해야 하고, 아키텍처를 리팩터링해야 하며, 아트를 교체하고 문구를 교정해야 합니다.

NetEase 사례도 비슷합니다. 기획자는 AI로 오후 한 번에 프로토타입을 돌렸지만, 이후 정식 개발은 여전히 직접 통제했습니다.

저도 핀볼 게임 Demo를 만든 적이 있습니다. AI가 준 코드로 20분 만에 돌아가게 만들었습니다. 하지만 출시 가능한 버전으로 바꾸는 데는 다시 2주가 걸렸습니다. 조작감을 조정하고, 성능을 최적화하고, 레벨을 설계하고, UI를 완성해야 했습니다.

프로토타입 단계의 AI는 가속기입니다. 정식 단계의 AI는 신중하게 써야 합니다.

반복 작업 vs 핵심 창의성

이 판단 기준은 더 직관적입니다.

반복 작업은 창의적 가치가 낮고, 시간이 많이 들며, 반복성이 강한 작업입니다. 예를 들면 NPC 대화 대량 생성, 아이템 설명 채우기, 업적 이름 생성입니다.

핵심 창의성은 창의적 가치가 높고 게임의 영혼을 결정하는 작업입니다. 예를 들면 스토리 분기 설계, 핵심 메커니즘 혁신, 캐릭터 성격 구축입니다.

반복 작업은 AI에 맡기면 시간을 절약할 수 있고 품질에 큰 영향을 주지 않습니다.
핵심 창의성은 직접 통제해야 게임의 핵심 경쟁력이 결정됩니다.

NetEase 시나리오 기획자의 방식은 이렇습니다. 채우기 문구는 AI에 맡기고, 핵심 서사는 직접 씁니다. 이렇게 하면 시간도 절약하고 창의성도 희생하지 않습니다.

저는 NPC 대화 약 100개를 작성한 적이 있습니다. 일상 대화, 잡담, 중요하지 않은 이야기의 농담은 AI로 생성해 15분 만에 끝냈습니다. 하지만 메인 스토리, 핵심 캐릭터의 성격이 드러나는 대사, 감정 전환 지점은 직접 썼고 이틀이 걸렸습니다.

반복 작업은 AI로, 핵심 창의성은 직접. 이 역할 분담이 효율을 극대화합니다.

간단한 판단표로 정리할 수 있습니다.

작업 유형	AI 처리	직접 처리	이유
지식형 문제	✅	❌	표준 답이 있음
사고형 문제	❌	✅	미적 판단 필요
프로토타입 단계	✅ 보조	✅ 통제	가능성 검증
정식 단계	❌	✅	품질 추구
반복 작업	✅	❌	창의적 가치가 낮음
핵심 창의성	❌	✅	창의적 가치가 높음

작업을 마주할 때마다 스스로 세 가지를 물어보세요.

1. 이 작업에는 절대적으로 맞는 답이 있는가?
2. 이 작업에는 내 미적 판단이 필요한가?
3. 이 작업은 프로토타입 단계인가, 정식 단계인가?

이 세 질문을 거치면 답은 대체로 분명해집니다.

실전 사례 - 직무별 AI 사용 경계

앞에서는 판단 프레임워크를 이야기했습니다. 이제 구체적인 직무에서는 어떻게 적용되는지 보겠습니다.

직무마다 작업의 성격이 다르기 때문에 AI 사용 경계도 다릅니다.

기획 직무

기획자의 업무 범위는 넓고 AI 사용 장면도 많습니다.

NetEase의 사례가 있습니다. 기획자가 브레인스토밍 회의에서 요구사항을 쪼개고 초안을 쓰면, Bot이 옆에서 기록하고 회의 후 실행 가능한 프로토타입 코드를 출력합니다. 이것은 기획 직무에서 AI를 쓰는 가장 전형적인 방식입니다. 아이디어를 빠르게 검증 가능한 것으로 바꾸는 일입니다.

하지만 기획의 핵심 업무는 창의적 의사결정입니다. 세계관 설계, 핵심 플레이, 스토리 구조는 AI가 할 수 없고 반드시 직접 통제해야 합니다.

저는 한 기획자가 AI로 플레이 방식 10개를 생성한 뒤, 그중 3개를 골라 더 깊게 생각하는 모습을 본 적이 있습니다. AI의 역할은 ‘생각의 폭을 넓히는 것’이지 ‘결정하는 것’이 아닙니다.

기획 직무의 AI 사용 경계는 다음과 같습니다.

• AI가 하는 일: 요구사항 분해, 초안 작성, 브레인스토밍 기록, 프로토타입 코드 출력
• 직접 하는 일: 세계관 설계, 핵심 플레이, 창의적 의사결정, 스토리 구조

시나리오/문구 직무

시나리오와 문구 직무에서 AI 사용 경계는 비교적 명확합니다.

NetEase 시나리오 기획자는 채우기 문구를 AI에 맡기고, 핵심 서사는 직접 쓴다고 공유했습니다. 그런 다음 AI 출력과 비교해 자신의 결과물을 보정합니다.

구체적으로는 다음과 같습니다.

• AI가 하는 일: NPC 일상 대화, 아이템 설명, 업적 이름, 퀘스트 설명
• 직접 하는 일: 메인 스토리, 핵심 캐릭터 대사, 세계관 문구, 감정 전환 지점

저는 한 게임의 NPC 대화 시스템을 작성한 적이 있습니다. 일상 잡담과 중요하지 않은 이야기에는 AI를 썼습니다. “오늘 날씨가 좋네요”, “요즘 장사가 잘 안돼요” 같은 문장입니다. 하지만 메인 스토리, 악역의 핵심 대사, 캐릭터 성격을 만드는 대화는 직접 썼습니다. 각 문장이 감정을 짊어져야 했기 때문입니다.

AI가 주는 채우기 문구는 시간을 줄여 주지만 감정을 짊어지지는 않습니다. 문구의 핵심 가치는 감정에 있고, 이 부분은 반드시 직접 통제해야 합니다.

프로그래머 직무

프로그래머는 AI를 가장 자주 쓰는 직무이자 논쟁도 가장 큰 직무입니다.

GDC 데이터에 따르면 36%가 AI를 사용하지만, 대부분은 에셋 생성이 아니라 코드와 워크플로에 씁니다. 이는 프로그래머가 AI를 비교적 잘 받아들이지만, 사용 범위에는 경계가 있다는 뜻입니다.

ACM 논문의 제안은 경험 있는 개발자가 AI 코드를 감독해 보안 취약점을 막아야 한다는 것입니다. 완전히 쓰지 말라는 뜻이 아니라, 사용한 뒤 검토해야 한다는 뜻입니다.

프로그래머 직무의 AI 사용 경계는 다음과 같습니다.

• AI가 하는 일: 코드 자동 완성, API 지식 답변, 수학 계산, 프로토타입 검증
• 직접 하는 일: 아키텍처 설계, 복잡한 로직, 성능 최적화, 보안 통제, 장기 유지보수

Reddit의 ‘모든 코드를 지우고 처음부터 다시 쓴’ 사례는 프로그래머가 AI에 과도하게 의존했을 때의 반면교사입니다. AI가 준 코드는 돌아갔지만 아키텍처가 얽혀 있었고, 이후에는 고칠 수 없었습니다.

제가 코드를 쓰는 습관은 이렇습니다. AI가 골격을 주면, 핵심 로직과 아키텍처 설계는 제가 보완합니다. 단순 함수, 반복 코드, 문서 검색은 AI를 씁니다. 하지만 시스템 아키텍처, 성능 핵심 경로, 보안 관련 코드는 직접 작성합니다.

아트 직무

아트는 AI 사용이 가장 신중한 직무입니다.

Reddit 피드백은 AI 아트가 “정해진 아트 방향을 따를 수 없다”고 말합니다.

Zhihu 피드백은 AI가 인체 구조를 잘못 생성해 전문 아티스트의 수정이 필요하다고 말합니다.

아트 직무의 AI 사용 경계는 다음과 같습니다.

• AI가 하는 일: 프로토타입 단계의 임시 아트, Demo 표시용 소재, 색 블록 대체
• 직접 하는 일: 인체 구조 수정, 스타일 일관성 통제, 시각 품질, 출시용 아트

저도 Demo 하나에서 AI로 캐릭터 초상화를 생성한 적이 있습니다. 결과는 스타일 불일치였고, 결국 지우고 아티스트를 찾아 다시 그렸습니다. 이 경험은 저에게 한 가지를 분명히 알려 주었습니다. AI 아트는 Demo 단계에서는 쓸 수 있지만, 정식 출시에는 안 됩니다.

아트의 핵심 가치는 스타일 일관성입니다. AI가 주는 결과물은 스타일이 뒤섞여 있고, 수정하는 일이 새로 그리는 것보다 더 힘들 수 있습니다. 이 문제는 현재 해결책이 없습니다.

직무별 비교표로 정리하면 다음과 같습니다.

직무	AI 사용률	AI 처리	직접 처리	반대율/논쟁
기획	중상	요구사항 분해, 프로토타입 코드	세계관, 핵심 플레이	낮은 편
문구	중상	채우기 문구, NPC 대화	메인 스토리, 캐릭터 대사	낮은 편
프로그래머	가장 높음	코드 자동 완성, API 조회	아키텍처 설계, 보안 통제	중간
아트	가장 낮음	Demo 임시 아트	스타일 통제, 인체 수정	가장 높음

이 표에서 알 수 있는 것은 창의성이 낮은 작업일수록 AI 수용도가 높다는 점입니다. 창의성이 높은 직무일수록 AI에 대한 경계가 강합니다.

NetEase 관리자의 AI 사용률은 47%이고 일선 실무자는 29%에 그칩니다. 이 온도 차 뒤에는 일선 직원들이 AI의 한계를 더 잘 안다는 사실이 있습니다. 그들은 매일 사용하기 때문에 무엇이 믿을 만하고 무엇이 믿기 어려운지 압니다.

결론

처음의 Reddit 개발자 이야기로 돌아가 보겠습니다. 그는 AI 코드를 모두 지우고 처음부터 직접 다시 작성했습니다. 이것은 AI를 부정한 것이 아니라 올바른 경계를 찾은 것입니다.

Sealos 블로그에는 이런 관점이 있습니다. AI는 ‘도구’이지 ‘건축가’가 아닙니다. 도구는 진입 장벽을 낮추지만, 방향을 결정하는 것은 건축가입니다. 인디 개발자는 여전히 크리에이티브 디렉터이고 AI는 가속기일 뿐입니다.

가장 성공적인 모델은 무엇일까요? GDC 데이터와 NetEase 사례는 같은 답을 가리킵니다. AI는 반복 작업을 처리하고, 핵심 창의성은 직접 통제하는 것입니다.

이것은 ‘전부 AI에 맡기기’와 ‘AI를 전혀 쓰지 않기’ 사이의 양자택일이 아닙니다. 역할 분담입니다. AI에 맡겨야 할 것은 맡기고, 맡기면 안 되는 것은 직접 지키는 것입니다.

세 가지 판단 습관을 가져보세요.

1. ‘지식형 vs 사고형’의 의식을 세우기. 문제를 만나면 먼저 묻습니다. 여기에 표준 답이 있는가? 없다면 직접 생각합니다.

2. ‘프로토타입 단계 vs 정식 단계’를 구분하기. 프로토타입에서는 AI를 과감히 쓰고, 정식 단계에서는 신중히 통제합니다.

3. AI를 쓸 때마다 스스로 묻기. 이 작업의 창의적 가치는 높은가? 내 미적 판단이 필요한가? 장기 유지보수에 영향을 주는가?

이 질문들에는 AI가 대신 답해 줄 수 없습니다. 이것이 인디 개발자의 핵심 능력, 즉 판단력입니다.

판단력은 경험에서 나옵니다. AI를 쓴다고 판단력이 쌓이지는 않습니다. 의존만 쌓일 수 있습니다. 판단력은 판단하는 과정에서만 쌓입니다.

AI는 좋은 도구입니다. 하지만 그것이 당신 대신 판단하게 두지는 마세요.

---

AI를 구체적으로 어떻게 쓰는지 알고 싶다면 이 시리즈의 13편인 “AI로 Cocos 미니게임 개발하기: 나의 전체 워크플로와 효율 비교”를 참고해 보세요. AI에게 요구사항을 쓰는 법을 배우고 싶다면 14편 “AI에게 미니게임 개발 요구사항 쓰기: 장면, 노드, 컴포넌트, 상호작용을 어떻게 설명할까”를 보면 됩니다. 이 글은 의사결정 프레임워크를 제공하고, 이후 글들은 구체적인 실천 방법을 다룹니다.