[AI&GameDev] AI 사용 기록을 모으기 시작한 이유

About this offer

1. AI를 일상적으로 사용하게 된 이후 내가 AI를 개발에 적극적으로 활용하기 시작한 계기는 팀원이 바이브코딩으로 결과물을 내는 것을 보고 Spec-Driven Development 를 시도하면서부터였다. About Spec Driven Development 처음에는 개발할 내용을 Spec(명세)로 정리해두니 AI에게 작업의 맥락을 전달하기 쉬웠다. 나 역시 무엇을 만들고 있고, 어디까지 진행됐는지 따라가기 편했다. AI에게 작업을 일임하면서도 개발의 흐름을 놓치지 않을 수 있다는 점이 좋았다. 그런데 실제로 개발을 진행하다 보니 기획, 설계, 구현, 테스트가 생각처럼 매끄럽게 이어지지는 않았다. 코드를 작성한 뒤에도 게임 엔진이나 다른 소프트웨어 도구 안에서 데이터를 설정하고, 상태를 확인하는 일은 여전히 내 몫이었다. AI의 작업이 끝나면 내가 도구를 조작하고, 그 결과를 다시 전달하는 과정이 반복됐다. 이 간격을 줄이기 위해 MCP서버 를 하나 둘 추가해보기 시작했다. AI가 개발 도구에 직접 접근할 수 있게 되면서, 코드 작성 이후의 작업까지 연결할 수 있었다. 그제야 개발 과정이 조금씩 하나의 흐름으로 이어지기 시작했다. Unreal Engine MCP 활용 작업을 맡길 수 있는 범위가 넓어지자 Codex, Claude와 같은 여러 에이전트도 함께 사용하고 세션도 여러 개를 사용하게 되었다. 그 무렵 AI LLM Wiki나 Harness Engineering 같은 이야기를 자주 접했고, 에이전트 작업을 한곳에서 관리하는 멀티플렉서도 알게 됐다. 나는 Herdr 를 활용해 여러 에이전트의 진행 상황을 한곳에서 확인하기 시작했다 Herdr: the runtime coding agents run on 이 과정에서 내가 하는 일도 달라졌다. 직접 손으로 처리하던 작업이 줄어든 대신, 무엇을 맡길지 정하고 결과가 의도에 맞는지 확인하는 일이 늘었다. 그래서 이때쯤부터 도메인에 대한 기초 지식이 탄탄해야겠다는 것을 느꼈다. 여러 작업을 동시에 진행할 수 있게 됐지만, 그만큼 내가 각 작업의 목적과 완료 기준을 분명하게 알고 있어야 했다. 그다음에는 작업 환경의 제약이 눈에 들어왔다. 에이전트가 작업하는 동안 계속 컴퓨터 앞에 앉아 있어야 할 필요는 없겠다는 생각이 들었다. 필요한 순간에 진행 상황을 확인하고 다음 방향을 전달할 수 있으면 됐기 때문이다. 이전에 Perforce를 온프레미스로 구축했던 경험을 살려 Tailscale을 이용해 외부에서도 개발 PC에 접속할 수 있는 환경을 구성했다. 이제 나는 휴대폰이나 노트북 등으로 어디서든 작업 상황을 확인하고, 자리를 비운 동안에도 작업을 이어갈 수 있었다. 처음부터 이런 환경을 계획한 것은 아니었다. AI를 활용하다가 막히는 부분을 하나씩 해결하다 보니 개발 방식과 도구, 작업 환경까지 전부 바꾸게 된 것이다. 물론 아직도 계속 이런 저런 시도를 하고있고, 앞으로도 상황과 변화에 맞춰 끊임없이 변해나가야 할 것이다. 2. 나는 AI를 어디에 가장 많이 활용했는가 AI를 일상적으로 사용하다 보니, 어느 순간부터 나는 AI가 제공하는 편리함에 너무 익숙해져 있었다. 문제에 부딪히면 스스로 원인을 짚어보기보다 AI부터 찾았다. 무엇을 해결해야 하는지 충분히 정리하지 않은 채, AI가 알아서 이해하고 적절한 답을 내놓기를 기대하기도 했다. 작업이 막히면 내 요청이나 접근 방식을 돌아보기보다 더 좋은 모델을 찾는 내 모습이 보였다. 하지만 모델을 바꾸는 것만으로 해결할 수 있는 문제였을까? 내가 문제를 제대로 설명하지 못했거나, 작업의 방향을 정하지 못한 채 수정을 반복하고 있었을 수도 있다. AI가 개발 과정 전반에 관여하게 된 지금, 내가 어떤 작업에 AI를 많이 활용하고 있는지 성찰해 볼 필요성을 느끼게 되었다. 특히 어디에서 작업이 반복되고, 그 반복 중 무엇이 필요한 개선이고 무엇이 불필요한 재작업인지 살펴볼 필요가 있었다. 그래서 실제 사용 기록을 모아보기로 했다. 막연히 많이 사용하고 있다는 감각을 넘어, 어디에 자원을 쓰고 있는지 확인하고 내 작업 방식을 돌아보기 위해서였다. 같은 비용으로 더 효율적으로 개발하려면, AI의 성능만큼이나 내가 AI를 어떻게 사용하고 있는지 살펴보는 일도 중요하다고 생각했다. 나의 AI 사용 기록 살펴보기 (물론 이 작업 역시 AI를 사용했다는 것이 아이러니한 상황이다.) 2-1. 숫자로 확인한 나의 AI 사용량 먼저 Codex와 Claude Code의 로컬 사용 기록을 모아 전체 사용량을 집계해보았다. 막연히 많이 사용하고 있다고 생각했는데, 숫자로 보니 AI가 내 개발 과정에 얼마나 자주 관여하고 있는지 조금 더 실감할 수 있었다. 다만 이 기록에는 웹이나 모바일, 직접 API를 호출한 사용량이 포함되지 않는다. 두 도구 모두 부분 수집된 기록이며 수집 기간도 다르다. 활동 추정 시간 역시 기록 사이의 간격을 최대 5분으로 제한해 합산한 값이므로 실제 작업 시간과는 구분해야 한다. API 추정비용도 실제 구독료가 아니라 기록된 사용량을 일반 API 단가로 환산한 값이다. 따라서 이 숫자들은 전체 사용의 정확한 결산보다는, 수집된 범위 안에서 내 작업 방식을 살펴보기 위한 자료로 삼게 되었다 토큰별 사용량 특히 눈에 들어온 것은 캐시 읽기 토큰이 약 30억 이라는 점이었다. 출력 토큰이 약 1,145만이였던 것과 비교하면 상당히 큰 숫자였다. 어디에서 발생한 사용량인지 모델별로 살펴보았다. Claude 모델의 기록에서는 일반 입력보다 캐시 읽기 토큰이 훨씬 크게 나타났다. Claude는 캐시 읽기를 일반 입력과 분리해 기록하고, Codex는 입력 토큰에 캐시 관련 토큰을 포함하므로 모델별 숫자를 그대로 비교하기는 어렵다. OpenAI 모델의 기록에서도 캐시 읽기가 추정비용에서 상당한 비중을 차지하고 있었다. 캐시는 비용을 줄여주는 기능으로 알고 있었는데, 왜 이렇게 큰 금액으로 나타나는지 궁금해 공식 문서를 찾아봤다. “Cache read tokens are 0.1 times the base input tokens price” 캐시 읽기 토큰에는 일반 입력 토큰 단가의 10%가 적용된다. 다만 모델별 예외가 있으며, Claude Opus 5.5는 5% 가 적용된다. Anthropic 공식 문서 · Prompt caching “Subsequent reads cost 0.1× that rate on most of these models and 0.05× on GPT-6.1 Sol.” GPT-5.6 이후 대부분의 모델은 캐시 읽기에 일반 입력 단가의 10%를 적용하며, GPT-6.1 Sol은 5% 를 적용한다. OpenAI 공식 문서 · Prompt caching 두 문서 모두 캐시 읽기를 일반 입력보다 저렴하게 책정하고 있었다. 다만 저렴하다는 것이 무료라는 뜻은 아니었다. 같은 문맥을 재사용할 때마다 사용량이 누적되기 때문에, 긴 문맥으로 호출을 반복하면 할인된 단가라도 총비용은 커질 수 있었다. 예를 들어 10만 토큰의 문맥을 캐시에서 100번 재사용하면, 누적 캐시 읽기는 1,000만 토큰이 된다. 내가 짧게 “다시 수정해줘”라고 요청해도, 그 작업에 필요한 기존 문맥까지 짧아지는 것 은 아니었던 것이다. 2-2. 어디에 가장 많은 자원을 쓰고 있었을까? 전체 사용량을 확인했으니, 이제 그 사용량이 어디에서 발생했는지 살펴볼 차례였다. 세션의 대화 기록을 직무 와 작업 단계 로 분류해 집계해 보았다. 아래 비율은 전체 입력 토큰에서 각 작업이 차지하는 비중이다. 실제 작업 시간이나 성과를 직접 나타내는 값은 아니지만, AI에게 어떤 작업의 맥락을 많이 전달했는지 살펴볼 수 있었다. 직무별 사용량 가장 높은 비중을 차지한 분야는 게임플레이 프로그래밍 으로, 전체의 52.2% 였다. 다른 분야를 모두 합친 것보다도 조금 많았다. 게임을 개발하고 있으니 예상할 수 있는 결과였다. 다만 막연히 여러 작업에 AI를 사용한다고 생각했던 것과 달리, 기록에서는 게임플레이에 사용량이 꽤나 집중되어 있었다. 그다음으로 많이 사용한 분야는 다음과 같았다. 개발 도구·자동화 : 20.8% 게임 개발 기타 : 9.7% 아트 자산 제작 : 7.5% UI 프로그래밍 : 6.5% 그동안 나름대로 반복 작업을 줄여보겠다고 전용 툴을 만들거나 AI를 통해 좀 더 쉽게 편집할 수 있는 기반을 마련한 점이 개발 도구·자동화의 비율로 나타난 것 같다. 게임플레이와 개발 도구·자동화를 합치면 무려 73.0% 다. 기록상으로는 게임의 동작을 만들고, 그 작업을 진행할 환경을 만드는 두 분야가 중심이었다. 단계별 사용량 개발 프로세스의 단계별로 묶어보니, 가장 높은 비중을 차지한 것은 수정 작업 으로, 전체의 40% 였다. 수정 : 40.0% 설계 : 20.1% 구현·제작 : 19.1% 검증 : 14.1% 조사 : 6.0% 기타 : 0.7% 수정 단계의 사용량은 구현·제작의 약 두 배였다. 설계와 구현·제작을 합친 39.2% 보다도 조금 높았다. AI를 활용하면서 무엇을 새로 만들었는지는 쉽게 떠올릴 수 있었다. 반면 만들어진 결과를 고치고 다시 확인하는 데 얼마나 자원을 썼는지는 크게 의식하지 못했다. 하지만 이번 기회에 기록을 보니 그 과정이 상당한 비중을 차지하고 있음을 깨달을 수 있었다. 물론 이 결과만으로 “AI가 만든 것을 고치느라 자원을 낭비했다”고 말할 수는 없다. 기존 버그 수정이나 리팩터링, 필요한 기능 개선도 여기에 포함될 수 있다. 긴 맥락을 반복해서 읽은 작업이 토큰 비중을 높였을 가능성도 있다. 그래도 돌아볼 지점은 분명해졌다. 나는 무엇을 수정하고 있었고, 왜 다시 수정해야 했을까? 도구별 호출량 이번에는 AI가 어떤 도구를 많이 호출했는지 살펴봤다. 가장 많이 호출된 도구는 Codex의 exec 로, 9,644회였다. shell_command 와 Bash 같은 명령 실행 도구도 상위에 있었고, 두 가지 이름으로 기록된 Unreal MCP 호출은 합계 1,912회였다. 아마 로그 분석을 자주 시키다보니 이런 결과를 만들어낸 것 같다. 하지만 호출이 많다는 사실을 마냥 긍정적으로 받아들일 수는 없었다. 내가 불필요한 도구 호출로 비용을 늘리고 있었던 것은 아닐까? 작업을 맡길 때 이미 확인한 정보와 다음에 필요한 확인을 충분히 정리하지 않았다면, 같은 상태를 다시 조회하거나 비슷한 명령을 반복했을 수도 있다. 이런 과정에서는 도구의 결과를 읽고 다음 행동을 판단하는 모델 호출도 이어지므로, 불필요한 반복이 토큰 사용량을 늘릴 수 있다. 물론 호출 횟수만으로 낭비를 확정할 수는 없다. 다만 비용을 돌아볼 때 모델 선택뿐 아니라, 이번 기회에 내 요청이 불필요한 확인과 재시도를 유발하고 있지는 않은지도 다시 살펴봐야 겠다 는 생각이 들었다. 3. 성찰과 반성 물론 이런 간단한 로컬 사용 기록 분석만으로 내 작업 방식의 모든 문제를 파악할 수는 없다. 하지만 막연하게 느끼던 문제와 고민을 이번에 구체적으로 돌아볼 계기는 된 것 같다. 글을 쓰면서 느낀 것은, 문제를 알아차리는 것 과 습관을 바꾸는 것 은 별개의 일이라는 점이다. 지금은 개선이 필요하다고 느끼고 있지만, 개발에 몰입하다 보면 어느 순간 다시 반복하고 있을 수도 있다. 그래서 한 번의 반성으로 끝내기보다, 꾸준히 내 작업 방식을 돌아보는 자세가 중요하다고 생각한다. 생각했던 개선을 실제로 시도했는지, 그 시도가 어떤 변화를 가져왔는지 확인하며 조금씩 나아가고 싶다. 나는 앞으로도 AI의 기록은 꾸준히 남기고자 한다. 시간이 지난 뒤 다시 살펴봤을 때, 내가 어떤 시행착오를 거쳐 어떻게 달라졌는지 보여줄 수 있는 기록이 됐으면 좋겠다. 4. AI와 개발자의 미래 AI는 지금까지 유례가 없을 정도로 혁신적인 도구로 자리잡고 있다. 그만큼 앞으로 AI를 더 적극적으로 활용해야 할 순간이 많이 있을 것이다. 혹은 누구나 느끼는 불안감처럼 언젠가 AI가 인간을 모두 대체할 지도 모르는 일이다. 미래가 어떻게 달라질지는 모르겠다. 하지만 적어도 이 글을 읽는 모든 분들이 자신의 AI 사용 방식을 한 번쯤 돌아보는 계기가 되었으면 한다.