AI 프로젝트의 본질(Soul)을 지키는 방법

트위터를 스크롤하다 보면, 대규모 프로젝트를 성공적으로 구축한 경험이 있는 사람들은 AI가 발전하면서 자신의 지식이 쓸모없어지게 될 것이라고 생각하는 사람들이 많습니다. 하지만 저는 그와 정반대라고 생각합니다.

저는 욕심을 부려 감당할 수 있는 것보다 더 많은 것을 하려는 타입입니다. 이는 주로 저에게 장애물로 작용해 왔는데, 미완성 프로젝트를 발표해야 하거나(제가 가장 좋아하는 방식은 아닙니다), 몇 달 동안 작업한 후 프로젝트를 포기하거나(이 역시 이상적이지 않습니다), 아니면 신의 가호가 있기를 바라며 프로젝트를 완성하는 경우(이것 또한 때때로 발생합니다) 중 하나를 선택하게 만들기 때문입니다.

이제 AI 덕분에 제가 쌓아 올리는 추가적인 작업량을 감당할 수 있게 되었지만, 그 대가는 만만치 않습니다. AI 이전에는 프로젝트에 대해 너무 깊은 지식을 가지고 있어서, 공원 벤치에 앉아서 꿈꾸는 기능을 정확히 어떤 파일에 구현해야 할지 알곤 했습니다. 하지만 AI를 사용한 후에는 주로 어제 AI가 작성해 준 코드를 밝혀낼 수 있는 프롬프트를 생각하고, 의미 있는 개선 사항을 제안하는 데 집중하게 되었습니다.

매일 코드 속에 잠겨 지내는 것도 프로젝트의 아이디어에 대한 다른 종류의 애착을 갖게 했습니다. 결과적인 프로젝트를 형성할 개념과 구조는 AI를 사용할 때 많은 경우 우연에 맡겨지곤 합니다.

6개월 전 비디오 게임 아이디어를 개발하기 시작했을 때, 저는 모든 것을 직접 코딩할지 아니면 어느 정도 AI를 사용할지에 대해 고민했습니다. 모든 것을 수작업으로 하면 더 나은 제품이 나올 것이라고 확신했지만(제 생각으로는), 아마도 개발 시간이 1~2년 더 추가될 것입니다.

어느 날 이 점을 생각하다가 깨달았습니다. 한 가지 방식만 고집할 것이 아니라, AI를 사용해서 무엇을 개발할지 그리고 AI가 절대 건드려서는 안 되는 부분이 무엇인지 매우 구체적으로 정의하는 것이 어떨까 하고 말입니다.

이것이 바로 프로젝트의 '본질(soul)'을 지키는 방법이 필요한 이유입니다.

어떤 종류의 대규모 개발 프로젝트를 구축하든 서로 다른 애플리케이션 레이어 간에 어느 정도의 느슨한 결합(loose coupling)이 필요합니다. 따라서 이를 기준으로 AI가 무엇을 도울 수 있고, 무엇은 피해야 하는지에 대한 지침으로 삼으면 어떨까요.

오늘 제가 할 작업입니다:
프로젝트에는 /Game/이라는 폴더가 있습니다. Game 코드는 엔진에 구애받지 않으며(engine agnostic), 게임은 게임 시작 시 생성되고 게임의 모든 것이 이 안에 표현됩니다. 이곳이 게임의 단일 진실 공급원(single source of truth)입니다. AI 사용 금지.

이 폴더에는 맵/지형 생성, 맵 객체 인스턴스화, NPC 행동 처리, 건물 등 모든 것이 담겨 있습니다. 바로 게임의 본질(soul)이자 실제로 플레이하는 부분입니다.

이제 이것을 엔진으로 구현하는 지점에서 AI가 도입됩니다. 그렇다고 해서 제가 에이전트들이 프로젝트 나머지 부분에서 완전히 제멋대로 날뛰게 둔다는 의미는 아닙니다. 저는 에이전트들을 더 작은 하위 프로젝트로 제한하고, 이를 뷰 클래스(view class)를 사용하여 Game의 진실에 연결합니다.

이제 어떤 기능을 구현하는 비용을 생각할 때, 그 기능이 프로젝트의 본질을 얼마나 건드리는지, 그리고 보조적인 부분(auxiliary parts)을 얼마나 건드리는지를 함께 생각하게 됩니다.

이는 제가 모델들을 마음껏 방치했을 때만큼 빠르게 움직일 수는 없다는 것을 의미하지만, 결과는 비교할 수 없을 정도로 다릅니다. 저는 창밖을 바라보며 제가 플레이하고 싶은 게임을 만들어낼 스마트한 방법들을 꿈꿀 수 있고, 한편 에이전트가 리프 셰이더(leaf shader) 최적화나 바위 생성 작업을 수행하도록 할 수 있습니다.