▲

LLM 없이 게임을 만들 때 3개월, LLM과 함께라면 3일

 (marianogappa.github.io)
9P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • 15년 경력의 소프트웨어 엔지니어가 어린 시절 카드 게임을 Go 언어로 개발하는 경험을 공유
  • LLM(대형언어모델) 없이 “Truco”를 개발할 때는 UI 설계와 서버리스 배포 등 모든 문제를 수작업으로 해결하며 3개월 소요
  • “Escoba”를 만들 때는 LLM을 활용해 백엔드 코드 변환 및 구현 속도를 크게 단축, 프롬프트 1회 만에 대부분 동작 성공
  • 글 후반에서는 Tic-Tac-Toe 예제와 함께 Go 백엔드, WASM 변환, React 연동을 통해 누구나 게임을 만들 수 있는 단계별 가이드를 제공
  • 하지만 React 프런트엔드 및 WASM 기반의 게임 상태 관리는 여전히 직접 디버깅 및 구현 필요

소개

  • 15년 경력의 소프트웨어 엔지니어가 자신이 실제로 게임을 만들어 배포해본 적이 없음을 깨달음
  • 어린 시절 아르헨티나에서 친구들과 즐겼던 카드 게임 중 하나를 Go 언어로 개발하기로 결심

Truco: LLM 없이 3개월

  • 2024년 6월 18일부터 Truco라는 카드 게임을 Go 백엔드로 개발 시작. React는 최소한의 지식만으로 프론트엔드를 작성
  • UI 구현이 가장 큰 도전이었고, 서버를 제공하지 않기 위해 TinyGo를 활용해 WASM(WebAssembly)로 트랜스파일 후, 정적 파일을 GitHub Pages에 배포함
  • LLM이 없던 시기라, 모든 세부 사항을 직접 찾아내고 시행착오를 반복하며 약 3개월 동안 완성함
  • 광고나 수익 목적 없이 오로지 게임을 완성하려는 목적이었으며, 출시 1년이 지난 후에도 꾸준히 플레이되고 있음

Escoba: LLM과 함께 3일

  • 1년 후, 가족을 만나러 아르헨티나를 방문하는 도중 조카에게 Escoba라는 두 번째로 인기 많은 카드 게임을 가르쳐줌
  • 이번에는 LLM(Claude) 을 활용하여, Truco의 백엔드를 복제한 뒤 Escoba의 규칙을 프롬프트로 설명, 코드 리팩터링을 요청함
  • 첫 프롬프트만에 거의 완벽하게 구현되었으며, 약간의 사소한 버그와 추가 기능만 수동으로 보완함
  • 프론트엔드는 여러 날 직접 구현/디버깅이 필요했음. LLM의 한계와 React 스킬, 게임 상태를 WASM에서 관리하는 특이한 환경 모두 도전 요소였음

단계별: 자신의 게임 만드는 방법

백엔드 개발

  • 턴 기반 백엔드는 명확하게 기능을 설계 가능함
  • 서버리스 구조 유지, 사람이 서로 플레이하는 구조는 상용 서버가 없다면 피하는 것이 현실적인 선택임

프론트엔드 개발

  • 프런트엔드는 다음과 같은 작업이 필요함
    • 백엔드에 신규 GameState 생성 요청
    • UI에서 상태 표시
    • 유효한 행동 선택 인터페이스 제공
    • 행동 적용 시 백엔드에 커맨드 전송
    • 봇 차례일 경우 백엔드에게 요청

백엔드 WASM 전환

  • Go 코드를 WASM으로 빌드하려면 GOARCH=wasm GOOS=js go build 사용
  • 바이너리 크기가 큰 문제가 있을 수 있으므로, TinyGo를 활용해 사이즈를 줄임
  • 프런트엔드와 연결할 함수들을 내보내기 위해 Go에서 별도의 엔트리포인트(ex: main_wasm.go)를 작성해 빌드시 분기 처리함
  • 메인 함수에서 select {}로 블록킹하여 프로그램이 즉시 종료되지 않게 처리 필요

백엔드-프런트 데이터 연동

  • Go의 자유형 struct인 GameState 등은 WASM에서 직접 serialize/deserialize 불가
  • 모든 데이터는 JSON 포맷으로 교환하는 방식이 필요
  • TinyGo에서 제공하는 문서 참고하여, 입력/출력 모두 JSON 직렬화로 주고받음

프런트엔드-백엔드 인터페이스

  • 프런트엔드에서는 backend 함수들을 직접 호출
  • GameState는 WASM 내에서만 관리되고 프런트엔드는 뮤테이션 불가, 항상 backend가 진실의 소스임
  • WASM 재컴파일 후 파일 교체 필요, Makefile를 통해 자동화 예시 제공

WASM 실행 환경

  • 실행을 위해서 wasm_exec.js를 head에 포함해야 하고, 해당 스크립트 활용해 인스턴스 생성 후 실행함

결론

  • 게임 제작은 즐거운 경험이었으며, Go와 WASM, React 조합으로 누구나 시도할 수 있는 접근법임
  • LLM의 도움으로 생산성이 크게 향상되었지만, 프론트엔드 역량과 디버깅 경험이 여전히 중요함
  • 누구나 이러한 구조로 직접 게임 개발에 도전할 수 있으니 시도해 볼 것
▲
GN⁺ 9시간전  [-]
Hacker News 의견

  • 내가 이 게시글에서 좋게 생각하는 부분은, 많은 개발자들이 간과하는 사실을 짚어줌에 있음. 게임 개발에서 코딩 자체가 병목이었던 적은 별로 없었음. 혼자 개발하는 사람도 AI 없이도 메커닉을 빠르게 만들 수 있음. 실제 어려운 부분은 눈에 보이지 않는 위의 여러 레이어, 예를 들어 게임 루프 밸런싱, 난이도 튜닝, 이질감 없는 에셋 제작, 유저의 관심을 5분 이상 유지시킬 만한 폴리싱 등임. 그래서 LLM 이후로 Steam에 뛰어난 게임이 넘쳐나지 않는 이유도 여기 있음. 기술이 장벽 하나를 낮췄지만, 더 큰 장벽들은 그대로임. 2010년대 Unity의 등장 때도 마찬가지였음. 엔진이 게임 개발을 민주화시켰지만 좋은 게임의 폭발적 증가가 아니라 시도의 숫자만 늘어났음. LLM은 코드에, 이미지 모델은 아트에 동일한 현상을 불러오고 있지만, 어떤 게임이 진짜 재밌는지는 이들 툴이 알려주지 못함. 내게 흥미로운 질문은 AI가 구현뿐만 아니라 플레이테스트까지 한다면 어떤 일이 벌어질까임. 즉, 수천 번 루프를 돌리며, 어떤 메커닉이 시뮬레이션 플레이어를 계속 잡아두는지 알려주는 단계까지 발전하면 생산성 해킹을 넘어 디자인 파트너까지 역할이 확장될 것임. 아직은 그 단계는 아니지만, 이 글이 그 방향으로 가는 초기 데이터 포인트처럼 느껴짐

    • AI가 단순히 구현뿐 아니라 플레이테스트까지 해서 수천 번의 루프를 돌리며 플레이어를 얼마나 더 몰입시키는지 파악하게 된다면 어떤 미래가 올지 궁금하다는 의견에 대해, AI가 어떻게 플레이어를 시뮬레이션할 수 있으며 왜 진짜 사람이 무엇에 몰입할지 제대로 판단할 수 있을지 궁금증이 생김

    • Unity 2010년대 부상 예시에서 정말 좋은 게임 수가 그리 많지 않았다는 점에 반론을 제기하고 싶음. 사실 XBLA 시절과 비교하면 우리가 지금 갖고 있는 수많은 게임 볼륨은 Unity, Godot, Gamemaker, Renpy, RPG Maker 같은 툴 없이는 불가능했을 것임. 즉, 질적으로만이 아니라 양적으로도 분명히 비약적인 성장이 있었음

    • 내 기준에서 생성형 AI의 리트머스 테스트는 2D 픽셀 아트 액션 게임용 스프라이트시트 전체를 만들어내는 것임. 예를 들어 탱크나 주인공 움직임만이라도 완벽하게 뽑는 게 목표였는데, 아직까지 성공 사례를 본 적 없음

    • "AI가 당신의 게임이 실제로 재밌는지 말해줄 수 없다"는 지적이 핵심 인사이트라고 생각함. AI는 인간이 실제로 게임을 경험하는 수준과 같은 방식으로, 혹은 어떤 다른 경험도 인간처럼 할 수 없음. 비슷한 게임에 대한 인간 평가 데이터를 보고 어느정도 예측만 할 수 있을 뿐임. 즉 AI가 당신의 게임을 즐길 수는 없음. 이런 본질이 앞으로 AI 시대 인력의 역할을 정의하게 될 것임. AI가 서류나 코드 같은 건 과거 데이터를 바탕으로 어느 정도 인간처럼 작성할 수 있지만, 진짜 인간만이 해낼 수 있는 의미있는 통합과 경험이 있음을 증명함. 인간만의 가치가 대체될 수 없는 지점이 있고, 다만 그 가치를 어떻게 바라볼지 다르게 접근해야 함

    • 이 패턴은 게임 개발 외 다른 분야에도 해당됨. 누구나 기대하듯 에이전트 기반 코딩에도 엄청난 가능성은 있지만, 일부 태스크(빠른 웹앱 데모, 소규모 라이브러리 연결 등)만 압도적으로 빠르게 해결되고 실제 대규모 소프트웨어엔 아직 적용이 미흡함. 모델이 학습된 방식이나 우리가 활용하는 노하우 모두 아직 부족함. 이런 상황이 놀랍진 않음. git도 등장 후 5년간은 엘리트 기업만 제대로 도입했고, 대중화되기까지 또 5년 걸렸음. 결국 지금은 많이 익숙해졌지만, LLM은 git보다 오히려 제대로 쓰기 어렵다고 봄. 만약 매 제품, OSS, 블로그 포스트마다 "이제 끝났다, 모든 게 혁신됐다"라는 식의 과장만 덜했어도 더 빨리 발전하지 않았을까 생각함. 우리는 아직 시행착오와 실험속에 있고, 시간이 걸림. 너무 빠르게 판단하지 않아야 함. 만약 이미 모든 게 해결된 단계였다면 적어도 훨씬 뛰어난 소프트웨어에 파묻혀 있어야 했겠지만, 아직은 겨우 균형을 맞추고 있는 수준임. 이 정도면 새로운 기술 등장 1~2년만에 꽤 인상적인 성과임

  • LLM이 3개월의 선행을 가진 것은 코드, 이전 게임을 템플릿으로 사용한 것, 그리고 무엇보다 손코딩할 때 쌓인 모든 경험과 실수를 바탕으로 했다는 점임

    • 처음엔 자극적인 제목일 줄 알았는데, 실제로 "Truco 백엔드를 복제하고 Claude에게 Escoba 규칙을 길게 설명한 뒤 코드 리팩토링을 시켰다"는 부분에서 놀라움이 있었음. 사람이 직접 리팩토링하면 얼마나 걸릴까 궁금해짐. 3일 이상 걸릴 것 같기도 하면서도 아닐 수도 있음

    • 또 한 가지, 이 게임이 참가자의 첫 번째 게임이었다는 점이 중요함. 즉, 첫 시도할 땐 수많은 미지의 변수를 상대해야 하지만, 이미 한 번 경험하면서 얻은 인사이트와 노하우를 가지고 다시 시작한다면 LLM 없이도 3개월보다 훨씬 짧은 시간 내에 만들 수 있음

    • 사실 같은 프로젝트를 두 번, 세 번 반복하면 처음 몇 달 걸리던 것도 다음 번엔 1/3 정도로 줄어듦을 직접 경험함

  • <i>기침</i> 24시간 안에 개발해본 적도 있음 nordicgamejam.com 에 예시 있음. LLM, GenAI도 없고 Unity도 없던 시절에는 Microsoft XNA와 C#이 최선이었다는 점을 말하고 싶음. 아트도 대부분 페인트로 그린 손그림 수준이었음. 그래도 매년 즐거운 게임들이 충분히 탄생했고, Baba is You, Braid처럼 대중에게 알려진 경우도 있었음. 코딩이 병목은 아니었고, 개인적으로는 멤버 간의 소통이 진짜 bottleneck이라고 확신함

    • 팀 내 커뮤니케이션이 중요한 병목이라는 의견에 덧붙여서, 자기 마음 속에서의 '커뮤니케이션'도 놀랍게 어려운 경우가 많음을 언급하고 싶음

  • 이 댓글 흐름을 보면 게임 개발 경험 없는 글이 많아 보임. 사실 LLM이 쓰이는 프로젝트는 이미 트레이닝 데이터에 많이 존재하는 유형임. 예를 들어 프로그래밍 입문 과목에서 다루는 프로젝트이기도 하고, 남유럽 국가에는 이 블로그에서 말하는 카드 게임과 유사한 게임이 정말 많음. 나도 대학 1학년 때 아무 경험도 없이 Moon Patrol을 Python으로 처음부터 구현했는데 2~3개월, 주 3일 밤새며 코딩했음. 카드 게임 만드는 건 오히려 그보다 쉬움. LLM이 분명 유용한 부분은 있지만, 이런 간단한 예제는 LLM의 코딩 생산성이나 유용성 벤치마킹에는 적합하지 않음

  • LLM으로 며칠을 띄엄띄엄 들여다보며 이런 작업을 했었음: stacky 대략 이틀 정도 실제로 일한 셈임. 처음엔 그라운드업 개발로, 이후엔 브라운필드 식으로 작성하면서 심각하게 완성할 의도까진 없었음. 그런데 점점 더 디테일과 기능을 추가하다 보니 자꾸 아이디어가 늘어남(슈퍼 로테이션, DAS 등). 아직 전체 게임의 10~20% 수준으로 미완성임. WebGL 버전도 돌아감. 하지만 너무 궁극적인 테트리스 만들기에 도전했다간 소송 당할 것 같고, 그럴 라이선스 비용도 없으니 멈췄음. 결국 얻은 건 자신감과 경험임. 최근 HN에서 파라메트릭 함수에 관한 링크를 보고 1~2시간 만에 playground인 graphy도 만들어봤음. 역시 디테일에 시간 계속 쏟게 됨. 원하는 게 뭔지 명확하면 LLM과 함께 이런 작업은 꽤 즐길 만함

    • 테트리스 리이매지네이션 멋지다고 전함. 새 MacBook Pro M4 Max와 Firefox 조합에서는 코어가 100% 사용률을 보이고 팬이 엄청 돌아가니 참고 바람

  • 일정 수준 이상 취미 게임 개발을 꾸준히 해오며 여러 게임도 완성했음. 그런데 이 댓글 흐름 전체적으로 실제 게임 개발 경험이 많지 않은 것 같음. 게임 개발에서 코딩이 쉽다는 주장에 동의할 수 없음. 신선한 아이디어나 장르 변주 메커닉을 생각하는 건 오히려 쉽고, 실제로 구현하는 코드 부분이 훨씬 어렵다고 느낌. 예를 들어 멀티플레이어 뱀파이어 서바이버에 배틀메크 커스터마이징 추가한다고 상상하는 건 쉽지만, LLM만으로 그걸 구현하는 건 불가능에 가까움. 이번 사례는 이미 완전히 알려진 카드 게임 규칙이니 뱀 게임만큼이나 간단함. 글 작성자에 대한 비난은 아니고, 다만 많은 사람들이 실제 게임 개발 경험 없이 개발을 판단하고 있다는 점을 짚고 싶음

    • 코딩이 게임 개발에서 어려운 부분이라는 주장에 동의하지 않음. 물론 어려울 수 있지만, 진짜 어려운 건 새롭고 재미있는 아이디어를 생각해내는 쪽임. 좋은 아이디어만 있으면 작은 조각으로 쪼개고 반복만 하면 결국 구현할 수 있음. 진짜 난관은 백지 상태에서 무엇을 만들지 정하는 순간임. 산책을 해보거나, 별별 시도를 다 해보거나, 예술에서 수천 년 반복되던 문제임. 반면 코딩은 결국 공학적인 작업임. 나도 최근 게임 개발을 공부하면서 수학 공부까지 병행하는데, 벡터 수학이나 쿼터니언 배우는 건 오히려 "내가 무슨 게임을 만들고 싶은가?"를 결정하는 것보다 훨씬 쉬웠음

    • 기본적으로 동의하지만, 나에게는 오히려 새로운 아이디어를 생각하거나 창의적 시도를 하는 부분이 항상 더 어려웠음. 웬만한 게임 메커닉은 뭐든 코딩할 수 있지만, 글쓰기/창의성 파트는 정말 힘듦. 그게 쉬운 사람이라면 진짜 복받은 것임. 모두에게 자연스러운 일은 아님

  • 완전 클라이언트 사이드 게임을 만들려는 거라면 왜 "백엔드"가 필요하다는 식으로 쓰는지, 그리고 왜 전체 앱이 아닌 백엔드만 따로 기술을 다르게 쓰는지 궁금함

  • 소프트웨어 업계에서 아이디어가 쉽고 빨리 실현되는 영역은 거의 사라졌다고 느낌. 이미 경쟁이 너무 치열해 아무리 작은 시장을 잡아도 글로벌 VC, 글로벌 AI와 직접 경쟁하는 시대임. 과거엔 최소한 대기업이 관심 가지지 않는 틈새를 찾아낼 수는 있었음. 지금은 대형 VC든 니치든 무조건 전 세계와 경쟁해야 하니, 결국 극도로 복잡한 기술이 필요한 작은 시장이나, 수익성 낮고 실패 확률이 높고 라이프사이클이 짧은(대부분 게임이 바로 이분야) 영역만 남음. 전자의 경우엔 일일이 찾아가서 상품 설명하는 수준의 마케팅이 필요함. 게임업계 경험상, 개발 단계 진입 전에 이미 대박 사례란 게 "백만 뷰 얻고 6개월 후 완전 사장되는 수준"임. 반복적인 수익이 거의 없다 보니 시작 자체가 너무나 의욕 상실임. Minecraft 같은 게임 만드는 건 거의 로또와 다름없음. 하지만 게임 업계는 그나마 다른 소프트웨어 업종에 비해 실력주의임. 품질과 재미가 채택여부에 연관이 있긴 함. 다른 업계는 규제, 네트워크 효과로 인한 독점 또는 정부 통제 등 미로 같음. 차라리 초기에 정부가 "이 분야는 이미 이 회사가 장악할 테니 스타트업 말고 딴 데로 가라"고 알려주면 1년 허비하는 일은 없을 거라 바람

  • 언제쯤이면 그린필드(완전 신규) 프로젝트가 에이전트 코딩 실력 벤치마킹에는 최악의 케이스라는 점을 자각할지 궁금함

  • LLM을 좋아하는 이유는 내가 프로그램을 머릿속으로 추상화하는 방식에 더 가깝게 코드를 다룰 수 있게 도와주기 때문임. 코드를 읽으면 마치 AST처럼 함수와 호출을 입력과 결과 추상 노드로 바꿔서 이해함. LLM 덕분에 이걸 코드로 거꾸로 구현하는 작업이 엄청 간단해짐. 일일이 아이디어에 맞는 코드 예제를 찾아 헤매거나 기억을 더듬을 필요 없이, LLM에게 WiFi 초기화 같은 반복 코드를 써달라 명령만 하면 됨. 결과적으로 레고 블록 쌓듯이 프로그램을 조립할 수 있게 됨. LLM 전에도 이 방식은 가능했지만 훨씬 많은 노력이 필요했음. 덕분에 요즘 다양한 언어를 넘나들며 손쉽게 개발 중임. 언어 내부 구조나 문법을 많이 배우지 못하지만, 바로 그 점이 핵심임. 언어나 문법은 프로그램 논리 흐름과는 상관없는 부차적 디테일임. 결국 기계어에서 어셈블리, C, 점점 더 높은 수준 언어로 진화했듯, 이제 코딩이 아니라 '프로그래밍' 그 자체로 점점 가까워질 것임. 마지막 형태가 어떻게 될지는 아무도 모르지만, 분명 갈수록 '작성'에 쏟는 시간보다 '프로그래밍'에 집중하는 시간이 더 많아질 것임

    • 동의함. 예전에도 누군가는 C로 짜면 어셈블리 수준을 진짜 이해하지 못해서 언젠가 큰코다칠 거라 걱정했겠지만, 현실은 개발 생산성 도구의 발전임. AI 역시 너무 뻔한 반복작업을 개발자에게서 떼주는 것이 가장 큰 장점임. 예전엔 C에서 메모리 누수와 시그멘테이션 폴트 잡기에 시간을 허비했음. 이제 모던 언어에선 그럴 필요가 사라졌듯, 자잘한 구현 디테일 예제나 문서 찾는 일도 점점 사라짐. 결국 개발자는 더 창의적인 부분에 집중할 수 있게 됨
답변달기