바이브코딩은 장난감 앱만 만든다? 1인 개발자가 Claude로 게임 엔진을 통째로 갈아엎었습니다

핵심 요약 (TL;DR)

취미 개발자 한 명이 Claude와 페어 코딩으로 485개 자율 에이전트가 도는 우주 경제 시뮬레이션을 만들고, 성능 벽에 부딪히자 엔진 언어를 Elixir에서 Rust로 통째로 이식했다고 밝혔습니다. 핵심은 도구가 아니라 태도입니다. Claude를 '자동완성'이 아니라 '동료'로 쓰면, 1인도 시니어급 작업을 완주할 수 있습니다.

"이런 복잡한 시스템은 혼자선 무리지." 규모 있는 프로젝트 앞에서 한 번쯤 그어본 선일 겁니다. 그런데 kalcode라는 개인 개발자가 Show HN에 올린 사례가 그 선을 넘어갑니다(news.ycombinator.com/item?id=48996187).

그가 만든 것은 '주말 CRUD 앱'이 아니었다

완전 자율 우주 무역 시뮬레이션입니다. 절차적으로 생성되는 시장, 진영별 인센티브, 수요·공급 기반 가격, 인구 이동, 스테이션 폐쇄 같은 창발적 경제가 돌아갑니다. 배송 AI는 GOAP 플래너로 항해 중 더 나은 기회가 생기면 실시간으로 경로를 다시 짜죠. 현재 약 485개 자율 에이전트가 틱당 10~20밀리초(p50)로 구동되고, 10만 개 이상까지 확장하도록 설계했다고 그는 밝혔습니다. 이 수치들은 외부 벤치마크가 아닌 본인 진술이라는 점은 감안해서 보시면 됩니다.

핵심 장면: 엔진을 통째로 갈아엎다

원래는 Elixir/Phoenix 프로토타입이었습니다. 그런데 윈도우 게이밍 PC에서 성능이 안 나왔죠. 보통 여기서 프로젝트가 멈춥니다. 언어를 바꾼다는 건 엔진을 다시 쓴다는 뜻이니까요. 그는 Claude와 함께 엔진을 Rust + Bevy로 재작성했습니다. 결과물은 SQLite를 내장한 단일 네이티브 바이너리, 런타임 의존성 0입니다. 본인 말로 "혼자였다면 여기까지 못 왔을 대역폭을 Claude 페어링이 열어줬다"고 하죠.

그럼 나는 어떻게 써야 하나 — 3단계

1. 문제를 통째로 설명하라. 함수 한 줄이 아니라 "지금 Elixir로 이걸 하는데 성능이 안 난다, Rust로 옮기려면 아키텍처를 어떻게 잡아야 하나"를 통째로 던지세요. 자동완성은 다음 줄을 채우고, 동료는 방향을 같이 고민합니다.
2. 왕복하며 결정하라. 아래처럼 선택지를 요구하는 프롬프트가 핵심입니다.

현재: Elixir/Phoenix, 485개 에이전트, 틱당 20ms 목표.
목표: 10만 에이전트 확장.
Rust 이식 시 ECS 라이브러리 후보 2~3개를 제시하고,
각각의 트레이드오프(러닝커브·생태계·성능)를 표로 비교해줘.

1. 검증은 당신 몫으로 남겨라. AI가 낸 아키텍처를 그대로 믿지 말고, 작은 프로토타입으로 성능을 직접 재보세요. 페어링에서 코드는 AI가, 판단은 사람이 쥡니다.

자주 묻는 질문

Q. 485개 에이전트, 10~20ms 같은 수치는 믿어도 되나요?
전부 개발자 본인의 진술이고 외부 벤치마크는 없습니다. 아직 완성 게임이 아니라 샌드박스 단계라는 점도 함께 보세요.

Q. 나도 언어 이식 같은 큰 작업을 맡겨도 되나요?
규모보다 '문제를 얼마나 명확히 정의하느냐'가 관건입니다. 통째로 설명하고 왕복하며 좁혀가면, 1인이 감당하는 작업의 상한이 확실히 올라갑니다.

Q. 자동완성처럼 쓰면 왜 안 되나요?
자동완성은 당신이 이미 아는 것을 빨리 쳐줄 뿐입니다. 모르는 영역을 함께 설계하려면 '동료'로 대해야 합니다.

바이브코딩의 결과물이 허접한 장난감이라는 인식은, 도구가 아니라 도구를 쥐는 방식에서 옵니다. 오늘 당신의 프롬프트는 자동완성에게 말을 걸고 있나요, 동료에게 말을 걸고 있나요.