최근 업무를 진행하면서 신규 프로젝트에 대한 검증을 프로토타이핑으로 할 일이 생겼다. 이전에는 코딩 못하는 기획자답게, 페이퍼 프로토타이핑을 비롯하여 온갖 할 수 있는 최적의 아이디어를 쥐어 짜내 여러가지 방법으로 프로토타이핑을 했던 반면, 어느 정도 폼이 올라온 ChatGPT 4o를 활용하여 검증해야 할 게임 메카닉을 직접 만들어보면 어떨까 하는 꽤 당돌한 생각이 떠올랐다.
처음에는 공부를 한다는 샘 치고 언리얼 엔진을 이용해 보기로 했으나, 곧 포기했다. GPT의 추천으로 블루프린트 프로젝트를 선택했던 것이 문제의 시작이었는데, GPT는 언리얼 블루프린트의 구조를 텍스트로만 학습했던 것 같고, 때문에 정확한 블루프린트의 구조를 안내하는데 거의 항상 실패했다. 노드의 위치나 어디에 어떤 노드를 연결해야 하는지 등의 내용을 제대로 알고 있지 못했기 때문에 설명은 당연히 엉망이었다. 시각적인 자료가 가장 중요한 블루프린트 예시를 GPT는 이미지로든 그래프로든 적절하게 생성해 내지 못했고, 때문에 기능 하나를 구현하기도 매우 벅찼다.
그리고 코딩 못하는 기획자는 C++을 건드릴 엄두를 내지 못했기 때문에 언리얼은…
GPT와 상성이 잘 맞는 것은 결국 직접 코드를 작성하는 것이고, 개인적으로 C# 은 그래도 C++ 보다는 이해하기 편하다는 점 때문에 빠르게 유니티를 사용하는 것으로 선회. 이전에 GPT와 유니티로 작업을 할 때, 엔진 버전에 맞지 않는 클래스나 코드를 쓰는 바람에 그다지 신뢰하지 않았는데, 짧은 시간 동안 많은 개선이 있었던 듯, 이전 버전의 함수나 코드를 불러오는 일은 예전의 GPT 버전 때 보다는 확실히 많이 줄었다.
하지만, 바이브 코딩이라 불리우는 환상종은 여전히 내 눈에는 보이지 않았다. 이는 사용자의 문제와 GPT의 문제가 동시에 얽혀 있는데, 인간 대 인간 관계에서 이른바 커뮤니케이션이라고 하는 부분이 가장 문제가 된 듯 하다.
일단 GPT 에게 업무를 내리는데 있어 매우 구체적이고 명확한 업무 지시는 필수다. 우선, ChatGPT 4o 가 개떡같이 말해도 찰떡같이 알아듣는 능력이 많이 향상되긴 했다. 이른바 맥락을 찾아내는 능력이 상당히 높아졌기 때문에, 꽤 짧은 지시어임에도 불구하고 원하는 결과를 출력하는 경우가 매우 자주 있었다.
하지만, 논리적인 맥락에서 이과 감성이 있는 GPT는 종종 이상한 결과를 내곤 한다. 지시문 중 논리적으로 햇갈릴 만한 지시를 내리면 결국 GPT는 기계적인 답을 내놓기 때문에, 두세번의 반복 작업을 불러오곤 한다.
프로토타이핑이기 때문에 GPT를 이용해서 만드는 기능들이 미리 잘 고려되어 있지 않다면 GPT가 만들어내는 기능 역시 점차 산으로 가기 시작한다. 지나치게 많은 컴포넌트, 자동으로 처리되게 만들어도 되는 것을 굳이 사용자가 일일히 세팅을 해야 하는 기능을 만든다던가 하는 것은 차라리 개선을 요청하면 빠르게 정리가 된다. GPT 를 이용하여 코딩을 할 때 가장 큰 문제가 되는 부분은 아래와 같은 경우이다.
- 전체 기능 중 가장 핵심이 되는 큰 기능들을 우선 구현한다.
- 큰 기능을 쪼개가면서 예상 못한 예외 처리를 정리하면서 수정한다.
- 필연적으로 GPT 채팅 세션이 길어지면서 할루시네이션이 발생한다.
평균적으로 하나의 GPT 채팅 세션에서 3 ~ 4개 정도의 기능을 만들고 수정하면 GPT는 점점 이상한 짓을 하기 시작한다. 중간에 코드를 삭제하거나 건너뛰고, 기존 선언한 변수명 이나 함수명을 매 대화 때 마다 지 멋대로 새로 쓰기 시작한다. 컴포넌트끼리 참조를 잔뜩 만들어 놓았다는 것을 잊어버리고 이상한 참조를 불러오거나 한다. 이 상태에서 업무를 계속 진행하면 당연히 복구 불가능할 정도로 코드가 망가지고 프로토타입은 더 이상 동작하지 않는다.
이 문제를 해결하기 위한 방법이 없는 것은 아니다. 복구 불능 상황은 빠르게 대처가 가능한데, git, SVN 같은 형상 관리 도구를 적극적으로 사용하고 자주 커밋 및 푸시를 하면 된다.
세션이 길어질 때 할루시네이션이 발생하는 문제는 새로운 세션을 시작하면 된다. 이 경우 문제는 프로젝트에 대한 전체 맥락을 다시 주입해야 한다는 매우 귀찮은 번거로움이 있다. 그나마 ChatGPT의 유료 버전은 세션 간 맥락을 유지시킬 수 있는 프로젝트 라는 기능이 있긴 하지만, 그래도 안전한 동작을 위해서는 맥락을 새로 먹이는 게 필요하다. 이 작업을 매일 반복하고 있다 보면, 엣지 오브 투머로우에서 에밀리 블런트에게 매일 같이 맥락을 주입하는 톰 크루즈의 기분이 어떤지 확실히 알 수 있다.
GPT와 언리얼의 상성에 대해서 투덜거렸지만, 유니티에서도 GPT가 상성이 안 좋은 부분이 딱 하나 더 있는데, 바로 UI 관련 기능 개발이다. 기본적으로 GPT는 인간이 사용할 수 있는 UI 에 대한 이해가 부족하며, 지나치게 복잡한 유니티의 UI 관련 기능의 문제와 상호 시너지를 일으켜 문제를 일으킨다. 때문에 지나치게 크거나, 지나치게 작거나, 혹은 구조적으로 동작하지 않는 UI를 동작한다고 바득바득 우기는 경우가 꽤 존재한다. 이 경우는 그냥 GPT를 포기하고 그냥 직접 UI를 만들면서 필요한 컴포넌트만 정리해서 만들어 달라고 하는 편이 낫다.
꽤 툴툴거리며 GPT에 대한 불만을 이야기 한 것 같지만, 그럼에도 불구하고 GPT와 유니티를 이용한 프로토타이핑의 생산성은 꽤 고무적이다. 간단한 게임을 혼자 학습하면서 만드는데 걸렸던 시간이 예전에 약 1달 정도 였는데, GPT 를 이용해 목표한 프토토타입을 만드는데 5근무일 정도 소요 되었다(그 중 약 1 ~ 2일은 GPT와 합을 맞춰보는 데 걸린 시간). 최소 4배의 작업 효율이 증가했다는 이야기.
이번 경험을 통해 AI가 인간의 직업을 대체 할 것이라는 주장에 더욱 공감을 못하는 반면, 인간의 작업 효율을 높여주는 유용한 도구가 될 수 있다는 생각은 더욱 강화 되었다. 그리고 그 툴이 최대한의 효율을 반영하려면 툴을 사용하는 방법과 특성에 대해 공부해야 한다는 확신이 생겼다. AI를 이용해 이른바 대딸깍시대 가 도래했다는 주장은 반은 맞고 반은 틀리다. AI가 만들어내는 딸깍물을 제대로 된 품질의 결과물로 올리는 데에는 AI를 쓴다고 하더라도 매우 많은 비용과 노력이 든다. 결국 AI가 사람을 내쫓는 게 아니라, AI를 잘 다루는 사람이 AI를 못 다루는 사람을 내쫓게 될 것이다.