메인 콘텐츠로 건너뛰기

Codex·Claude·Gemini, AI 코딩 모델 3종으로 카운터 스트라이크 만들어보니

요약

브라우저에서 돌아가는 3D 멀티플레이어 카운터 스트라이크를, 사람 대신 AI 코딩 모델 3개에게 맡기면 어떤 결과가 나올까요?

최신 버전인 Codex Max 5.1, Claude Opus 4.5, Gemini 3 Pro에게 똑같은 미션을 던져봤습니다. "Three.js로 1인칭 FPS 게임을 만들고, 나중에는 멀티플레이까지 붙여라."

이 글에서는 각 모델이 어떤 식으로 문제를 풀었는지, 누가 프론트엔드에서 더 잘했고, 누가 백엔드에서 빛났는지, 실사용 입장에서 느낀 차이를 이야기해 보겠습니다. 결론부터 말하면, "프론트는 Claude, 백엔드는 Gemini, 균형은 Codex"였습니다.

프론트엔드는 Claude, 백엔드는 Gemini, Codex는 안정적인 2등

먼저 전체적인 인상을 정리해볼게요.

Claude Opus 4.5는 여전히 "보이는 것"에 강했습니다. 맵, 캐릭터, 총, 전체적인 분위기까지, 처음부터 게임다운 화면을 잘 뽑아줍니다. 디자인 감각이 좋은 개발자와 일하는 느낌이랄까요.

반면 Gemini 3 Pro는 "눈에 보이는 화려함"보다 "논리와 구조"에 강했습니다. 멀티플레이, 방 생성, 데이터 저장 같은 백엔드·아키텍처 작업에서 에러가 적고, 설계가 자연스럽게 흘러갔습니다.

Codex Max 5.1은 둘 사이 어딘가에 있습니다. 프론트도 나쁘지 않고, 백엔드도 꽤 잘 하지만, 특정 영역에서 "와 이건 확실히 1등이다" 싶은 순간은 적었습니다. 대신 전체적으로 안정적인 2등 느낌이라, 실무에서는 오히려 편할 수도 있습니다.

대략 이런 느낌으로 정리할 수 있습니다.

  • 화면·연출·감성: Claude > Gemini > Codex

  • 구조·에러 대응·멀티플레이: Gemini > Codex > Claude

  • 전체 밸런스: Codex가 가장 "무난한 올라운더"

1단계: 박스와 물리엔진 – 기본 FPS 만들기

첫 과제는 아주 심플했습니다.

Three.js를 이용해서:

  • 1인칭 시점 카메라와 조준점이 있고

  • 적들이 랜덤 위치에 생성되고

  • 적에게 HP가 있어서 총을 쏘면 데미지를 받고 죽고

  • 죽으면 다시 리스폰되는

기본 FPS 틀을 만드는 일이었습니다. 모든 오브젝트는 단순한 직사각형 폴리곤만 사용합니다.

Claude는 여기서부터 뛰어났습니다. 단순한 박스들로 구성했는데도, 바닥과 장애물이 잘 구분되고, 시야도 좋고, "아 이건 실제 게임 맵이네" 싶을 정도로 구성이 깔끔했습니다.

Gemini도 무난하게 작동하는 맵을 만들었습니다. 크게 화려하진 않지만, 기본 기능과 구도는 잘 갖춰진 편입니다.

Codex는 첫 실행 때 함수 import를 빼먹어서 에러가 났지만, 곧바로 자기 코드를 고쳐 해결했습니다. 다만 버그를 잡고 나니, 맵이 전체적으로 어둡고 평평해서, 바닥과 주변을 구분하기가 어려웠습니다. 기능은 되는데, "맛"이 부족한 느낌이었죠.

이 단계에서 느낀 점은,

  • "최소 기능 구현"은 셋 다 충분히 가능하지만,

  • "보기도 좋은 초기 맵"을 뽑아내는 능력은 Claude가 확실히 앞선다는 것.

2단계: 캐릭터와 총 – 폴리곤 인간으로 만들기

기본 박스만 있던 적들을 이제 사람처럼 보이게 만들어 달라고 요청했습니다.

"여러 개의 정사각형 폴리곤을 조합해서 사람처럼 보이게 만들고, 작은 총도 달아줘."

Claude는 진짜 Minecraft를 떠올리게 하는 귀여운 폴리곤 사람을 만들어냈습니다. 머리·몸·팔·다리가 구분되고, 총도 그럴듯하게 보입니다. 디테일이 좋아서, 같은 박스더라도 훨씬 '캐릭터'처럼 느껴졌습니다.

Gemini도 사람 느낌을 잘 살렸습니다. 다만 Claude처럼 "디자인 센스가 터진다"는 정도까지는 아니고, 충분히 쓸 만하고 받아들일 수 있는 수준이었습니다.

Codex는 확실히 개선되긴 했지만, 캐릭터와 총, 모든 게 거의 한 가지 색으로 통일되어 있어서, 다른 모델들에 비해 입체감과 재미가 떨어졌습니다.

이 단계에서 보니,

  • Claude: "게임 아트 감각 있는 프론트엔드 개발자"

  • Gemini: "무난하지만 무난 이상"

  • Codex: "기능은 되는데, 미적 감각은 조금 심심한 개발자" 이런 이미지가 꽤 또렷해졌습니다.

3단계: 1인칭 시점 총과 반동 – 디테일의 승부

다음 미션은 플레이어 시야에 실제로 총을 들려주는 작업이었습니다.

"화면 속 내 시야에 총이 보이게 해줘. 내가 쏘면 총이 약간 움직이면서 반동 느낌이 나게 해줘."

Claude와 Codex는 이걸 한 번에 통과했습니다. 두 모델 모두 1인칭 시점에 총을 붙였고, 발사할 때 총이 살짝 튕기는 반동 애니메이션도 잘 들어갔습니다. 특히 Claude의 총은 "진짜 권총 같다"는 말이 나올 정도로 디테일이 좋았죠.

반면 Gemini는 총을 카메라에 붙이는 부분에서 계속 꼬였습니다. 여러 번 시도 끝에야 원인을 찾을 수 있었는데, 알고 보니 총 모델이 카메라에 붙어 있긴 한데 "투명"으로 처리되어 있어서, 안 보이는 상태였던 겁니다.

재미있었던 점은,

  • Claude와 Codex는 시각적인 부분에서 처음부터 완성도가 높고,

  • Gemini는 "논리적으로 틀린 건 아닌데, 실제로 보면 이상한 결과"가 종종 나온다는 것.

이건 실제 프로젝트에서도 중요하게 체감될 포인트입니다. "결과물이 바로 보이고, 디테일한 연출까지 즉시 나오는 AI냐, 아니면 구조와 로직에 더 강한 AI냐"의 차이니까요.

4단계: 사운드와 사망 연출 – 모두가 똑같이 오해한 문장

프론트엔드 마지막 스텝은 사운드와 애니메이션을 더하는 것이었습니다.

"총알은 칩튠 느낌의 소리로 내고, 죽을 때도 연출을 추가해줘."

여기서 재밌는 일이 하나 생깁니다. 우리는 사실 "죽을 때 나는 소리도 만들자"는 의도로 문장을 썼는데, 세 모델이 모두 똑같이 "죽는 모션을 애니메이션으로 표현하라"는 뜻으로 이해한 겁니다.

다시 읽어 보면, 사람 입장에서 봐도 그렇게 이해할 수 있겠다 싶을 정도로 애매한 문장이긴 했죠.

어쨌든,

  • 세 모델 모두 칩튠 스타일의 총소리는 잘 붙였습니다.

  • 적이 죽을 때의 애니메이션도 만들어줬고요.

그중에서도 Claude의 사망 애니메이션이 가장 재밌고 "게임 같은 느낌"이 강했습니다. 단순히 HP가 0이 되고 사라지는 것이 아니라, 죽는 동작의 타이밍과 모션이 잘 살아 있었습니다.

여기까지가 "AI에게 프론트엔드 게임 화면을 맡겼을 때"의 결과입니다. 이 시점까지는 확실히 Claude가 한 수 위였습니다.

5단계: 멀티플레이 1단계 – 위치 동기화로 시작하기

이제부터는 진짜 핵심인 멀티플레이 단계입니다.

우선은 총알은 잠시 잊고, "서로의 위치를 공유"하는 것부터 시작했습니다. 우리가 사용한 서비스는 Instant의 presence 기능입니다.

요청 내용은 이런 식이었습니다.

  • Instant presence만 사용하고, DB는 건드리지 말 것

  • 단일 방(룸)만 존재

  • 더 이상 랜덤 적은 필요 없고, 접속한 플레이어들만 등장

  • 각 플레이어의 위치를 presence로 공유

여기서 최고의 성적을 낸 건 Gemini였습니다. 거의 한 번에 멀티플레이 위치 공유를 구현해냈고, 에러도 적었습니다.

Codex와 Claude는 조금 더 도움을 필요로 했습니다.

  • Codex는 타입스크립트 라이브러리 내부를 "샅샅이 뒤져보는 스타일"이었고,

  • Claude는 공식 문서를 여러 번 정독하는 스타일이었죠.

  • Gemini는 둘을 섞은 형태로, 문서도 보고, 빌드도 자주 돌리면서 타입 에러를 빠르게 잡는 방식이었습니다.

특히 Gemini는 계속해서 npm run build를 돌려 보며 에러를 체크하는 습관(?) 덕분에, 코드가 점점 안정적으로 변해갔습니다. 반대로 Codex는 빌드를 자주 돌리진 않았고, Claude는 그 중간 어디쯤이었습니다.

여기서 느낀 점은 간단합니다. "문서 이해력 + 실제 빌드/에러 피드백 활용 능력"이 백엔드와 멀티플레이 작업에서는 엄청난 차이를 만든다는 것, 그리고 이 부분에서 Gemini가 확실히 강하다는 것.

6단계: 총알과 HP – 맞았을 때 정말로 죽게 만들기

이제 위치 공유가 되니, 다시 총으로 돌아갈 차례입니다.

이번에는 이렇게 요청했습니다.

"쏘는 순간 그 정보를 topic으로 보내고, 맞은 플레이어의 HP를 깎아줘. HP가 0이 되면 죽고, 다시 리스폰되게 해줘."

여기서는 Claude가 가장 깔끔했습니다. 한 번에 요구사항을 이해하고, 정상적으로 동작하는 코드를 만들어냈습니다.

Gemini와 Codex도 결국은 잘 동작하는 코드를 내놓았지만,

  • 약간의 버그와 타입 에러를 고치는 과정이 필요했고,

  • 우리가 에러 메시지를 그대로 복사해 붙여넣어 주는 식으로 도와주면, 그 다음부터는 스스로 코드를 고쳐 나갔습니다.

즉,

  • "기능 구현 정확도"에서는 Claude가 앞섰고,

  • "에러를 이용해 빠르게 반복 개선"하는 능력은 Gemini가 강점,

  • Codex는 둘 사이 정도의 안정적인 평균값.

7단계: 다중 맵, DB 저장, 리팩터링 – 진짜 실력 차이가 드러난 구간

마지막 미션은 난이도가 확 올라갑니다.

이번 요청은 이랬습니다.

  • 게임 첫 화면에 "맵 리스트"를 보여주고

  • UI는 예전 카운터 스트라이크 맵 선택 화면 느낌으로, 다각형 스타일

  • 맵 정보를 DB에 저장

  • 각 맵은 이름을 갖고, 5개의 랜덤한 멋진 이름을 가진 맵을 자동으로 생성해 seed

  • 권한 설정: 누구나 맵을 조회할 수 있지만, 생성/수정은 못 하게

  • 특정 맵을 선택해 입장하면, 그 맵의 id를 presence의 room id로 사용

UI는 세 모델 모두 정말 잘 뽑았습니다. 개인적으로는 Gemini가 만든 맵 선택 화면이 가장 마음에 들었지만, Codex와 Claude도 충분히 "게임처럼" 보이는 UI를 만들어 줬습니다.

DB 쪽도 세 모델 모두:

  • 맵 스키마 정의

  • 마이그레이션 생성 및 적용

  • 5개 맵 자동 생성 스크립트

까지 무리 없이 해냈습니다.

진짜 차이는 그 다음, "리팩터링"에서 나타났습니다.

이제는 단일 방이 아니라 "여러 맵 = 여러 방" 구조로 바꿔야 했기 때문에, 기존 코드를 재구성하는 작업이 필요했습니다.

여기서:

  • Gemini는 한 번에 일을 끝냈습니다. 그리고 깔끔하게 맵 id를 URL에 포함시키는 방식을 선택해서, 실제 사용성과 유지보수성까지 고려한 설계를 했습니다.

  • Codex는 쿼리 에러로 한 번 막혔지만, 에러를 알려주자 바로 수정하고 정상 동작까지 도달했습니다.

  • Claude는 이 구간에서 크게 고생했습니다. 특히 React의 useEffect 훅에서 반복 실행 문제에 걸려

    • 캔버스가 두 개씩 생성되고

    • 애니메이션 루프가 중복 실행되는 미묘한 버그들이 생겼습니다.

이 버그들은 사실 "사람 개발자도 자주 당하는 흔한 React 함정"과 매우 비슷합니다. dependency array를 빼먹거나, cleanup을 제대로 안 하거나, 그런 실수 말이죠.

결국 이 단계에서는 우리가 직접 코드를 읽고, 문제를 짚어주고, 방향을 제시해줘야 했습니다. "그냥 에러 메시지만 던져주면 알아서 고친다"는 수준까지는 아직 아닙니다.

이 경험에서 나온 두 가지 생각이 있습니다.

첫째, AI 모델이 코드를 짜더라도, 어느 정도 이상 복잡해지면 "사람이 최소한 코드를 읽고 이해할 수 있어야 한다"는 점. 둘째, React 같은 프레임워크의 사용성을 개선하면, 인간뿐 아니라 AI 개발자에게도 큰 도움이 될 거라는 점입니다.

시사점: 지금 AI 코딩 모델, 어떻게 써야 가장 잘 쓸까?

이번 실험에서 세 모델 모두, 사람 손으로 한 줄도 직접 타이핑하지 않았는데도 "실제 멀티플레이 FPS 게임"을 끝까지 만들어냈습니다. 이 사실 하나만 놓고 봐도, AI 코딩 모델은 분명 새로운 단계에 들어와 있습니다.

하지만 동시에, 이런 현실도 드러났습니다.

  • 코드 한 줄도 안 보고 개발하는 시대는 아직 아니다.

  • 특히 리팩터링, 복잡한 상태 관리, React 훅 같은 부분에서는 인간의 개입이 여전히 필요하다.

  • 문서 이해력 + 에러를 활용한 반복 개선 능력이 모델별로 큰 차이를 만든다.

정리해보면, 현 시점 기준으로는 이렇게 활용하는 전략이 좋습니다.

  • "보이는 결과가 중요하고, 처음부터 예쁘고 게임 같은 UI가 필요하다면" → Claude Opus 4.5를 프론트엔드 파트너로 쓰는 게 유리합니다.

  • "멀티플레이, 데이터베이스, 방 구조, 복잡한 로직 설계가 핵심이라면" → Gemini 3 Pro가 에러도 덜 나고, 구조도 깔끔하게 나오는 편입니다.

  • "한 모델로 전체를 무난하게 커버하고 싶다, 극단적인 장단점보다 안정감을 원한다면" → Codex Max 5.1이 가장 균형 잡힌 선택지입니다.

마지막으로, 만약 비개발자라면 한 가지는 꼭 기억해두면 좋겠습니다. "AI가 코드를 다 짜준다"는 말은 점점 더 진실에 가까워지고 있지만, 지금은 아직 "AI와 함께 페어 프로그래밍을 한다"는 마음가짐이 훨씬 현실적입니다.

  • 아이디어와 요구사항은 사람이 잡고

  • 초안과 반복 수정은 AI에게 맡기고

  • 마지막 체크와 중요한 설계 결정은 사람이 하는 구조가, 현재로서는 가장 안전하고 생산적인 조합입니다.

앞으로 모델이 한 단계 더 발전하면, 이 균형이 또 어떻게 바뀔지 궁금해지네요. 다음에는 RPG, 소셜 게임, 혹은 모바일 게임 버전으로 다시 한 번 실험해봐도 재밌을 것 같습니다.

출처 및 참고 : Codex, Opus, Gemini try to build Counter Strike

이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.