코딩에서 설계·검증·책임으로 바뀌는 개발자의 역할
최근 팀의 게임 프로그래머 네 명이 모여 꽤 긴 이야기를 나눴다.
처음부터 거창하게 “AI 시대에 프로그래머는 어떻게 살아남아야 하는가”를 토론하려고 시작한 것은 아니었다. 활 시스템, 애니메이션 구조, 몬스터 Ability 관리, Behavior Tree, 테스트 코드 같은 실제 개발 업무를 이야기하다 보니 자연스럽게 한 가지 질문으로 이어졌다.
“AI가 이 정도까지 코드를 작성할 수 있다면, 앞으로 게임 프로그래머는 무엇을 해야 할까?”
최근 AI를 실제 개발에 적극적으로 사용하면서 이 질문은 더 이상 먼 미래에 대한 이야기가 아니었다.
이미 코딩 자체는 빠르게 자동화되고 있다
불과 얼마 전까지만 해도 AI에게 코드를 맡긴다는 것은 보조적인 의미가 강했다.
하지만 지금은 상황이 많이 달라졌다.
기능 구현을 요청하면 코드를 작성하고, 컴파일 오류를 수정하고, 기존 코드를 분석하고, 테스트 코드를 만들고, 테스트에 실패하면 다시 코드를 수정한다.
개발자가 하나의 기능을 처음부터 끝까지 직접 작성하지 않아도 되는 경우가 점점 많아지고 있다.
회의에서도 프로그래밍을 전혀 모르는 사람들이 AI와 MCP를 이용해 상당한 수준의 프로그램이나 게임을 만드는 사례가 언급됐다. 그래서 전통적인 형태의 게임 프로그래머 역할이 계속 유지될 것인지에 대한 의문도 자연스럽게 나왔다.
한 참석자는 현재 상황을 이렇게 표현했다.
“AI로 80까지는 누구나 만드는 시대가 왔다.”
다만 마지막 20%, 즉 실제 제품으로 출시하기 위해 필요한 안정성과 품질, 버그 대응은 아직 우리가 책임져야 한다는 이야기였다.
중요한 변화는 여기서 시작된다.
과거 개발자의 업무가
설계 → 구현 → 디버깅 → 완성 이었다면,
AI 시대에는 점점 문제 정의 → 구조 설계 → AI 구현 → 검증 → 수정 지시 → 제품 책임 이라는 형태로 바뀌고 있다.
“돌아가는 코드”와 “좋은 코드”는 여전히 다르다
AI를 사용하면서 가장 위험한 순간은 기능이 너무 쉽게 동작할 때일지도 모른다.
AI는 주어진 목표를 달성하는 데 매우 능숙하다.
문제는 목표를 달성하기 위해 어떤 길을 선택했느냐다.
회의에서는 실제 AI 코드에서 시스템의 원래 처리 단계를 건너뛰거나, 중간 레이어에 임시로 로직을 추가하거나, 필요 이상의 Strong Reference를 만드는 등의 사례가 언급됐다.
기능만 보면 정상적으로 동작한다.
하지만 기존 시스템이 가지고 있던 경계를 무시하면 이후 다른 기능을 수정했을 때 예상하지 못한 사이드 이펙트가 생길 수 있다.
그래서 중요한 질문이 달라진다.
예전에는 “이 코드를 잘 작성했는가?”를 물었다면 앞으로는 “이 시스템을 우리가 계속 통제할 수 있는가?” 를 물어야 한다.
회의에서도 비슷한 결론이 나왔다.
자신이 컨트롤할 수 있는 영역 안에 있어야 한다.
그리고 그 컨트롤 역시 AI를 활용해서 할 수 있다.
개인적으로 이번 이야기에서 가장 중요하게 느낀 부분이다.
게임 프로그래머는 코더에서 아키텍트로 이동한다
AI가 구현을 담당하게 된다면 인간 프로그래머에게 남는 것은 무엇일까?
회의에서 반복적으로 나온 답 중 하나가 아키텍처였다.
AI가 만들어낸 코드를 한 줄씩 직접 작성할 필요는 없더라도 다음과 같은 것은 판단할 수 있어야 한다.
- 이 데이터 구조가 적절한가?
- 시스템 간 의존성이 지나치게 커지지는 않았는가?
- 기능이 앞으로 확장될 수 있는 구조인가?
- 다른 시스템의 책임을 침범하고 있지는 않은가?
- 문제가 생겼을 때 원인을 추적할 수 있는가?
- 장기적으로 유지보수할 수 있는가?
실제로 회의에서도 AI가 작성한 코드를 세세하게 따라가기보다 큰 구조를 확인하고, AI에게 구현 내용을 설명하게 한 뒤 설계가 잘못됐다고 판단되면 다시 방향을 지정하는 방식이 이야기됐다.
즉 앞으로 중요한 능력은 단순히 코드를 많이 생산하는 능력이 아니라,
“AI가 올바른 구조 안에서 코드를 생산하도록 만드는 능력”
일 가능성이 높다.
AI 시대에는 오히려 좋은 설계가 더 중요하다
AI가 등장하면 설계의 중요성이 낮아질 것이라고 생각하기 쉽다.
오히려 반대일 수도 있다.
AI의 가장 큰 장점은 빠른 생산성이다.
하지만 구조가 잘못되어 있다면 잘못된 구조 역시 매우 빠르게 커진다.
회의 초반에 논의된 애니메이션 문제가 좋은 사례였다.
Guard나 Bow 같은 전투 기능을 Montage와 상하체 Blend만으로 계속 해결하면 당장은 빠르게 결과를 만들 수 있다.
하지만 액션 게임의 퀄리티를 높이려면 결국 전투 자세, 이동, Idle, Turn, Animation Set, 같은 요소가 함께 설계되어야 한다.
임시 방식으로 계속 기능을 추가하다 보면 어느 순간 큰 비용을 들여 전체 구조를 다시 만들어야 할 수도 있다는 우려가 나왔다.
AI가 개발 속도를 다섯 배 올려준다고 해서 항상 좋은 것은 아니다.
좋은 구조라면 좋은 시스템을 다섯 배 빠르게 만들지만,
잘못된 구조라면 기술 부채도 다섯 배 빠르게 쌓일 수 있다.
그래서 AI 시대에는 오히려 Architecture → Constraint → AI Implementation 이라는 순서가 중요해질 가능성이 높다.
테스트도 AI에게 맡기면 되는가?
회의에서 가장 의견이 많이 갈린 주제 중 하나가 테스트였다.
AI에게 기능을 구현하도록 하면 자연스럽게 테스트 코드까지 작성하는 경우가 많다.
장점은 분명했다.
예를 들어 활 조준 보정 기능을 테스트하면서 AI가 카메라 각도를 조금씩 바꾸고 반복적으로 화살을 발사한 뒤 궤적과 오차를 기록하는 사례가 있었다.
사람이라면 “조금 더 잘 맞는 것 같다.”
정도로 판단할 일을 AI는 각도와 거리 변화로 정량화할 수 있었다.
이런 종류의 반복 테스트는 오히려 사람보다 AI가 잘할 가능성이 높다.
하지만 반대 문제도 있었다.
AI가 만든 테스트 코드 자체가 잘못되어 있을 수 있다.
심지어 테스트가 실패하면 Production Code를 수정하기보다 테스트 코드를 바꾸어 성공시키려는 상황도 생긴다.
또 Asset Path 같은 리소스에 테스트가 과도하게 의존하면서 단순히 폴더를 정리했을 뿐인데 테스트가 깨지는 사례도 있었다.
여기서 중요한 결론이 하나 나온다.
AI가 테스트를 작성하더라도 Test Architecture는 사람이 설계해야 한다.
무엇을 검증할 것인가.
무엇을 정상 상태라고 정의할 것인가.
어떤 테스트가 실패하면 실제 문제라고 판단할 것인가.
이 기준까지 AI에게 모두 넘기는 것은 아직 위험하다.
AI 코드 리뷰는 좋은 ‘두 번째 시선’이다
AI 코드 리뷰에 대한 평가는 비교적 긍정적이었다.
실제로 의미 있는 문제를 찾아주는 경우가 꽤 있고, 개발자가 놓친 부분을 다시 생각하게 해주는 역할을 한다는 의견이었다.
한 참석자는 이를 “돌다리를 한 번 더 두드려 보는 느낌”이라고 표현했다.
하지만 여기에도 함정이 있다.
AI 리뷰에서 문제가 발견될 때마다 자동으로 수정하고 다시 리뷰한 뒤, 지적이 완전히 없어질 때까지 반복하게 하면 오히려 코드가 이상해질 수 있다.
왜냐하면 AI 리뷰 역시 항상 옳은 것은 아니기 때문이다.
따라서 Review → 자동 수정 보다는
Review → 설계 의도와 비교 → 타당성 판단 → 수정 의 과정이 필요하다.
그리고 이 과정에서 점점 중요해지는 것이 Spec이다.
AI가 무엇이 옳고 그른지를 판단하려면 우리가 원하는 시스템의 목표와 제약조건을 명확하게 알려줘야 한다.
회의에서도 결국 기준이 되는 스펙 문서를 잘 작성하는 것이 중요하다는 이야기가 나왔다.
어쩌면 AI 시대에는 코드를 잘 작성하는 사람보다 좋은 Spec을 작성하는 사람이 더 중요해질지도 모른다.
마지막까지 남는 것은 ‘게임을 아는 능력’이다
그렇다면 프로그래머가 코딩하지 않는다면 무엇을 공부해야 할까?
회의 후반에 흥미로운 이야기가 나왔다.
금융 프로그램을 만들려면 금융 도메인을 이해해야 한다.
게임도 마찬가지다.
특히 액션 게임을 만든다면,
좋은 전투가 무엇인지,
Animation이 왜 어색한지,
Enemy AI가 어떻게 플레이어와 상호작용해야 하는지,
Encounter가 어떻게 구성되어야 하는지,
어떤 데이터 구조가 콘텐츠 확장에 유리한지, 를 알아야 한다.
결국 게임을 만드는 방법을 알고 있는 것 자체가 개발자의 자산이라는 이야기다.
이 관점에서 보면 미래의 게임 프로그래머는
Programming Specialist 보다는
Game Development Specialist who can use AI 에 더 가까워질 수도 있다.
결국 중요한 것은 ‘책임질 수 있는가’
AI가 아무리 발전하더라도 제품을 만드는 조직에서는 결국 누군가 결정을 내려야 한다.
이 구조로 갈 것인지.
이 기술 부채를 받아들일 것인지.
이 테스트 결과를 믿을 것인지.
이 정도의 버그 위험을 가지고 출시할 것인지.
그리고 문제가 발생했을 때 어떻게 해결할 것인지.
회의에서 나온 표현 중 인상 깊었던 것은 이것이었다.
“돌아간다 OK가 아니라, 내가 이해하고 수정할 수 있는 정도의 코드여야 한다.”
AI 시대의 개발자는 모든 코드를 직접 작성할 필요는 없을 것이다.
모든 코드를 한 줄씩 읽을 필요도 없어질 수 있다.
하지만 자신이 맡은 시스템에 대해서는 여전히
이해하고, 판단하고, 통제하고, 책임질 수 있어야 한다.
그래서 앞으로 게임 프로그래머는 무엇을 준비해야 할까?
이번 대화를 정리하면서 개인적으로는 앞으로의 중요도가 다음과 같이 바뀔 것이라고 생각했다.
게임 및 도메인 이해
→ 시스템 아키텍처
→ 문제를 잘게 분해하는 능력
→ 명확한 Spec 작성
→ AI에게 작업을 지시하는 능력
→ Validation과 Test 설계
→ Debugging과 Profiling
→ 직접적인 코드 작성
코딩 능력이 필요 없어지는 것은 아니다.
하지만 지금까지 프로그래머 능력의 중심에 있던 코드 생산 능력의 상대적인 중요도는 내려갈 가능성이 높다.
대신 한 사람이 여러 AI Agent를 이용해 과거 여러 명의 프로그래머가 하던 일을 수행하는 환경이 만들어질 수 있다.
그렇다면 좋은 게임 프로그래머의 정의도 달라질 것이다.
코드를 가장 빨리 작성하는 사람이 아니라,
좋은 게임이 만들어지는 구조를 설계하고 AI가 그 구조 안에서 일하도록 만들 수 있는 사람.
그리고 AI가 만들어낸 결과를 보고
“이 정도면 내가 책임질 수 있다.”
라고 판단할 수 있는 사람이다.
코드는 AI가 짜도, 게임은 사람이 결정한다
AI가 게임 프로그래머를 없앨 것인지는 아직 알 수 없다.
하지만 한 가지는 분명해 보인다.
게임 프로그래머의 일은 이미 변하기 시작했다.
앞으로 중요한 질문은 “AI보다 코드를 잘 짤 수 있을까?” 가 아니라 “AI를 이용해 이전보다 더 좋은 게임을 만들 수 있는가?”가 될 것이다.
그리고 이를 위해서는 역설적으로 프로그래밍 문법보다 게임과 시스템에 대한 더 깊은 이해가 필요할지도 모른다.
AI가 구현을 담당하는 시대가 올수록 개발자는 한 단계 위에서
무엇을 만들지,
어떤 구조로 만들지,
무엇을 믿을지,
어디까지 허용할지,
그리고 그 결과를 책임질 수 있는지
를 결정해야 한다.
어쩌면 앞으로의 게임 프로그래머는 더 이상 단순한 Programmer가 아니라,
AI를 활용해 게임 전체를 설계하고 만들어가는 Technical Game Developer
에 가까워질 것이다.
'프로그래밍 에세이' 카테고리의 다른 글
| Helm: Kubernetes 패키지 매니저 (0) | 2024.11.15 |
|---|---|
| 프로그래밍, 귀찮으면 지는 것이다. (0) | 2020.08.05 |
| 프로그래머, 조급증을 버리자. (0) | 2019.11.03 |