바이브 코딩 이후 AI 활용에 관하여

지난 글에서는 AI 모델들에 대한 소감이랑 워크플로우를 가볍게 소개했다. 지금은 Claude, Codex, Cursor를 모두 쓰고 있다. Claude Opus 5.5가 경제적으로 나와서 정말 고맙다.

SRPG 근황

개발 중이던 SRPG 근황이다.

개발 중인 SRPG 필드. 캐릭터와 지형, 옆의 상태 화면이 보인다.

개발 중인 SRPG 전투. 유닛들이 마주 보고 있고 스킬 이펙트가 나와 있다.

아예 유니티에서 벗어나서 자체 엔진을 만들고 있다.

자체 엔진 에디터. 가운데 뷰포트와 좌우 패널이 있는 편집 화면.

자체 엔진을 만드느라 게임 개발은 잠시 뒷전으로 두고, 시간과 토큰을 쓰고 있다. 나오는 결과물은 만족스럽다. 대학생 때부터 자체 엔진을 만들고 싶다는 로망을 이루고 있다.

바이브 코딩 다음

처음 AI로 개발하면 딸깍딸깍 나와서 신기하다. 바이브 코딩이라는 말처럼, 신나서 춤을 추게 된다.

AI에 관심을 갖고 공부하다 보면 이런 용어들이 보인다.

프롬프트 엔지니어링
컨텍스트 엔지니어링
하네스 엔지니어링
그래프 엔지니어링

요즘은 소프트웨어 팩토리라는 말이 들려온다.

이런 용어를 그다지 좋아하지는 않는다. 당연히 해 오던 것들에 뒤늦게 이름을 붙였고, 본질이 왜곡된 채 접하는 사람도 많아진다고 생각한다. 그냥 "해줘" 하면 다 되는데 뭐하러 공부하나 싶다. 근데 쓰다 보면 그렇지 않다.

결국 이것들이 있는 이유는, 에이전트가 어떻게 일을 더 잘하게 만들 것이냐다. 그리고 이건, 에이전트가 어떻게 신뢰할 수 있는 결과물을 만들 것이냐랑 연결된다.

그냥 해 달라고 하면 잘해 준다. 근데 결국 말로 내 의도를 전달해야 하는데, 이게 번거롭다. 모델 성능이 좋으면 알잘딱으로 좋은 결과물을 내놓겠지만, 쓰다 보면 한계가 온다. 의도를 잘 전달하기 위한 스킬 중 하나가 mattpocock의 grill-me 같은 스킬이다.

활용할 수 있는 도구나 관측 가능한 결과값이 주어지지 않으면, 에이전트는 정확하게 수행할 수 없다. 그럴싸한 대답은 해 주지만, 결론을 채택하는 건 사람 몫이 된다. 이럴 때 흔히 MCP나 CLI를 쓴다. Unity 공식 CLI가 나오기 전에, 나도 직접 unity cli를 만들어 쓴 적이 있다. 요즘은 아예 Computer Use를 쓰기도 한다. 물론 토큰이 아깝다.

그리고 우리 프로젝트에 대한 특별한 프로세스나 의도가 필요할 때가 있다. 이 정보가 코드에 없으면, 모델이 아무리 뛰어나도 시행착오나 헛짓거리를 하기 마련이다. 혹은 코드에는 있지만, 정보를 찾는 데 시간과 토큰 소모가 불필요하게 날 수도 있다. 그래서 이런 정보들을 담은 하네스가 있으면 더욱 좋다. 프로젝트 안에 기획, 플랜 문서나 스킬을 파일로 저장해 둔다.

사람 개입을 줄이는 쪽

요즘은 거기서 더 나아가, 사람의 개입을 어떻게 최소화할 것이냐 쪽으로 가고 있다. 최근 Grok Bot, Meta muse, dots 같은 서비스들이 나왔다. 이들은 24/7 사람 대신 일을 처리해 주는 것을 강조한다. 개발을 넘어서, 관리의 영역까지 개입을 최소화해 준다. 유저 문의나 버그 제보 같은 것을 받았을 때, Grok Bot이 대신 처리해 줄 수 있다. 나도 Grok Bot을 많이 쓰고 있다. 관심 있으면 한번 찾아보면 좋다. 이 글을 쓰는 데도 도움을 받고 있다.

한편으로는, 에이전트가 내 개입 없이 수십 건의 이슈를 처리하고 있다. 결과물은 두 번 정도 확인하는 것 같다. 이렇게 해도 아주 만족스러운 결과물이 나오고 있다.

이게 가능한 이유는, 어떤 결과물을 줘야 하는지 기준을 에이전트에게 알려 줬기 때문이다. Cursor 로렌 탄의 pstack이라는 플러그인이 있다. 보고 많이 배웠다. 그대로 써도 좋고, 공부해서 바꿔 써 봐도 도움이 된다고 생각한다. 이 사람 생각이 담긴 인터뷰 영상이 유튜브에 많이 있다. 관심 있으면 한번 찾아보면 좋다.

Claude나 Grok Bot에게 작업을 지시하면, 이들은 지휘자(orchestrator)가 된다.
GPT 6.1 Sol이나 Grok 4.7 같은 아이들에게 하청을 준다.
하청이 작업을 다 하면 지휘자에게 보고한다.
지휘자가 기준에 따라 검토해 보고, 충족하지 못하면 다시 돌려보낸다.
하청은 다시 작업한다.
그리고 이 과정이 병렬로, 동시에 4~5개 정도 돌아간다. Cursor Cloud 같은 클라우드 환경이라면 더 많이 돌릴 수 있다.

지휘자가 위에 있고, 아래 하청들이 보고하면 기준에 맞춰 검토한 뒤 안 맞으면 다시 돌려보내는 흐름도.

이렇게 몇 시간에 걸쳐 작업이 진행된다. 그리고 게임, 툴, 시스템 구축 같은 프로젝트를 여러 개 만들기도 한다. 시간을 많이 들이지 않아도 되는 수준이 됐다. 모바일이나 아이패드로 결과물을 확인한다.

게임 개발보다는 이런 시스템을 구축하는 게 더 재미있다.