LLM이 코드를 짜주는 시대에 제품 업데이트 주기를 어디까지 줄일 수 있을까. 풀스택 개발자 한 명이 유저 피드백을 모아 다음 날 자동으로 배포되는 웹게임 제작을 직접 시도해봤다고 한다.

그는 Gemini 등 AI 도구를 활용해 초기 프로토타입을 30분 만에 구현하며 개발 속도가 약 10배 빨라지는 경험을 했다. 하지만 복잡한 스킬 트리 로직이나 런타임 오류 수정 단계에서는 AI가 근본 원인을 잡지 못하고 가드 코드만 남발하는 한계를 발견했고, 결국 인간 개발자가 직접 코드를 수정해 해결해야 했다. 구현의 속도가 비약적으로 상승했지만, 그만큼 검증에 드는 피로도가 함께 커지는 AI 코딩의 실무적 트레이드오프가 드러난 지점이다.

Gemini와 node:cron 기반의 자동 배포 파이프라인

25%의 런타임 버그 발생률. 초기 설계했던 2시간 단위 실시간 자동 배포 시스템이 기록한 수치다. 빌드 안정성이 떨어지는 문제를 해결하기 위해 개발자는 배포 주기를 일일 테스트 빌드 생성 및 배포 방식으로 전환했다. 이 시스템의 핵심은 node:cron(노드 크론, 정해진 시간에 작업을 수행하는 스케줄러)을 활용한 자동화 파이프라인이다. 유저의 피드백을 수집하고 이를 정제한 뒤 Gemini(제미나이, 구글의 생성형 AI 모델)가 코드를 생성하면 빌드와 릴리즈 생성, 최종 배포까지 한 번에 이어지는 모놀리식 구조를 구축했다. 게임 구현에는 TypeScript(타입스크립트), Vite(비트, 프론트엔드 빌드 도구), Phaser(페이저, HTML5 게임 엔진) 스택을 사용해 빠른 프로토타이핑 환경을 만들었다.

AI에게 매번 같은 지시를 내리는 번거로움을 없애기 위해 GEMINI.md라는 지침 파일을 도입했다. 이는 세밀한 설계보다 AI와의 대화를 통해 빠르게 구현하는 바이브 코딩(Vibe Coding) 실험의 일환으로, 프로젝트의 기술 스택과 작동 방식을 명시해 AI가 일관된 코드를 생성하도록 가이드한다. 코드 작업이 완료되면 에이전트의 구동 시간과 입력된 지시 프롬프트, 작업 요약 내용이 포함된 커밋 메시지를 자동으로 생성하는 설정까지 더했다. 단순 리뷰에 들어가는 공수를 줄이고 AI의 작업 이력을 명확히 남기려는 장치다. 이는 개발 구현 속도는 빨라지지만 검증에 드는 피로도가 커지는 상황에서 관리 효율을 높이는 방법이 된다.

인프라 구성에서는 Docker(도커, 컨테이너 기반 가상화 플랫폼) 인스턴스 간에 서버 목록 파일을 공통 볼륨으로 공유하는 방식을 적용했다. 여기에 5분 만료 캐시를 설정해 반복적인 파일 접근으로 인한 서버 부하를 제어했다. 유저가 보낸 다양한 언어의 피드백은 영어로 먼저 정제한 뒤 다시 번역하여 릴리즈 노트에 노출하는 프로세스를 거친다. 피드백 수집부터 실제 서비스 반영까지의 전 과정을 사람이 개입하지 않고 스케줄러와 AI가 처리하게 만든 구조다. 전체 소스 코드는 GitHub 저장소에 공개되어 있으며, 실제 구현된 게임은 SpiralWave에서 확인할 수 있다.

구현 속도 10배 증가와 QA 피로도의 트레이드오프

코드를 짜는 시간은 줄었지만, 그것이 맞는지 확인하는 시간은 늘었다. 이번 프로젝트를 통해 확인한 개발 구현 속도는 약 10배 증가했으나, 이에 비례해 검증(QA)에 투입되는 시간과 개발자가 느끼는 피로도는 함께 상승했다. AI가 순식간에 생성해내는 코드의 양이 많아질수록, 개발자는 그 코드가 의도대로 작동하는지 하나하나 대조하고 검토하는 작업에 더 많은 에너지를 쏟아야 한다. 구현 단계에서 얻은 물리적 시간의 이득이 검증 단계의 심리적 부하와 시간적 비용으로 전이되는 트레이드오프가 발생한 것이다. 이는 도구의 속도가 빨라질수록 인간이 감당해야 할 검토의 밀도가 높아짐을 의미한다.

단순한 규칙은 빠르게 처리하지만 얽혀 있는 로직 앞에서는 멈춘다. 스킬 트리 개발 과정에서 기본적인 선행 스킬 로직은 AI가 무리 없이 구현해냈지만, 중간 노드를 취소했을 때 그에 연결된 하위 노드들이 연쇄적으로 취소되어야 하는 복잡한 상태 제어 로직은 해결하지 못했다. AI가 제시한 대안들이 계속해서 꼬이면서 결국 개발자가 직접 로직을 설계하고 코드를 작성해 문제를 해결했다. AI가 개별 함수나 독립적인 기능 조각은 수준 높게 생성하지만, 여러 단계의 상태 변화가 맞물린 복잡한 시스템 설계에서는 여전히 인간의 개입이 필수적이라는 점이 드러난 대목이다.

오류를 수정하는 방식에서도 AI와 인간의 접근법은 극명하게 갈린다. UI 코드를 분리하는 리팩토링 작업 이후, 상태 갱신과 UI 표시 순서가 뒤바뀌어 발생하는 런타임 오류가 나타났다. 이때 AI는 문제의 근본 원인을 찾아 수정하기보다, 오류가 발생하지 않도록 막는 가드 코드를 반복적으로 남발하는 방식으로 대응했다. 하지만 개발자가 전체 흐름을 파악해 직접 수정한 코드는 단 두 줄에 불과했다. AI는 정답에 가까운 코드를 내놓는 것처럼 보이지만, 때로는 문제의 본질을 비껴가는 방식으로 작동하여 오히려 수정 범위를 넓히는 결과를 초래했다.

코드의 질적 측면에서도 효율성과 가독성의 충돌이 관찰된다. AI가 작성한 코드는 함수 단위의 완성도는 매우 높지만, 전체적인 흐름을 한눈에 파악하기 어렵게 만드는 낮은 가독성 문제를 안고 있다. 특히 특정 상황에서 지엽적인 하드 코딩을 사용하는 것이 훨씬 유리하고 간결한 경우에도, AI는 불필요하게 비대한 일반화 패턴을 도입하여 코드를 복잡하게 만드는 경향이 확인됐다. 이는 AI가 학습한 보편적인 코딩 패턴을 기계적으로 적용하면서, 실제 구현 환경에 최적화된 단순함보다는 형식적인 구조화를 우선시하기 때문이다. 결국 코드의 양적 팽창이 관리 효율의 저하로 이어지는 결과가 나타났다.

전통적인 게임 업데이트 주기는 수주에서 수개월이 소요되지만, 스파이럴웨이브는 이를 24시간 단위의 자동 배포 체계로 단축했다. 유저 피드백이 즉각적으로 코드에 반영되고 배포되는 구조는 개발자의 수동 개입을 최소화하며 게임의 진화 속도를 높인다. 단순한 콘텐츠 추가를 넘어 유저의 요구가 실시간으로 제품의 형상을 결정하는 구조로 전환되는 지점이다. AI가 개발과 운영의 경계를 허물며 게임의 생명주기를 완전히 재정의한다.