고전(高専) 로보콘 2026 「걸레 투척」을 주제로, Claude Code와 OpenAI Codex를 합계 약 19.5시간 구동하여 브라우저 상에서 경기를 재현할 수 있는 3D 시뮬레이터를 만들었습니다.

• 경기 시뮬레이터 (브라우저에서 즉시 실행 · 설치 불필요 · 스마트폰 가능)

• 소스 코드

최초의 목적은 「당시 이용 가능했던 최상위 클래스의 모델에게 전국 우승 전략을 쓰게 하면, 어디까지 쓸 만한 안이 나올 것인가」를 시험하는 것이었습니다.

그런데 AI가 작성한 전략서는 문장으로서는 깔끔했지만, 실제 설계 판단에 사용할 수 있을 정도로 구체적이지 않았습니다. 반면, AI에게 필드의 viewer를 만들게 하고 물리 시뮬레이션(Physical Simulation)이나 자동 계측을 추가해 나가자, AI 코딩의 강점이 단번에 보이기 시작했습니다.

이번에 얻은 가장 큰 배움은 이것입니다.

AI에게 정답을 생각하게 하는 것보다, AI 스스로가 구현을 실행하고 결과를 계측하며 수정할 수 있는 「환경」을 만들게 하는 것이 압도적으로 강력하다.

이 기사에서는 viewer가 경기 시뮬레이터로 성장해 가는 과정을 통해, AI 코딩에서 특히 효과적이었던 다음의 점들을 소개합니다.

• AI에게 도면이나 경기 규칙을 올바르게 인식시키는 방법 (PDF는 이미지로 전달)
• AI 스스로 결과를 검증할 수 있는 피드백 루프(Feedback Loop)를 만드는 방법
• AI가 고속으로 시행착오를 겪을 수 있는 기술 스택(Tech Stack)을 선택하는 방법
• AI에게 전략을 직접 쓰게 하는 것만으로는 불충분했던 이유

7월 19일에 NHK 학생 로보콘 2026이 방영되었습니다. 프로그램에서는 여러 팀이 개발에 AI를 활용하고 있는 모습도 소개되었습니다. 그에 자극을 받아 저도 본격적으로 돌려본 것이 이번 내용입니다.

용도에 따라 구분해서 사용했으므로, 먼저 목록화해 두겠습니다.

처음에는 규칙과 필드 PDF를 전달하며 「이 경기에서 전국 우승할 전략을 정리해 줘」라고 시켰습니다.

물론 AI는 그럴싸한 말을 합니다. 득점 효율, 리스크 관리, 우선순위, 기구 안, 경기 전개 —— 문장으로서는 상당히 깔끔하게 정리해 줍니다.

하지만 로보콘 경험자의 시선으로 보면, 그것만으로는 실제 의사결정에 거의 사용할 수 없었습니다.

로보콘에서 정말 어려운 것은 「깔끔한 전략을 생각하는 것」이 아니라, 그 전략을 성립시키는 기구(Mechanism)를 끝까지 만들어내는 것이기 때문입니다. 이 경기에서 이기려고 하면 결국 효과적인 것은 다음 사항들입니다.

• 사출의 기구적 정밀도 / 제어 정밀도
• 장전 · 위치 맞춤 · 재현성
• 경기 중 실패했을 때의 복귀성
• 완성도 80%인 것을 100%로 끌어올리는 진흙탕 싸움 같은 작업

이 진흙탕 같은 부분을 AI에게 단순히 문장으로 생각하게 해봤자 의미가 없다고 느꼈습니다.

그래서 방침을 바꿨습니다. AI에게 「대단한 답」을 문장으로 내놓게 하기보다, 답을 검증할 수 있는 환경을 코드로 만들게 한다. 여기서부터가 AI 코딩의 본게임이었습니다.

처음에는 필드를 보기만 하는 viewer를 의도했지만, 단계적으로 검증 환경으로 성장해 나갔습니다.

• 처음에는 필드를 3D로 표시하기만 하는 viewer였다
• 「걸레가 포물선을 그리며 날아가는 애니메이션」이 단번에 추가되었다
• 로봇 · 사출 조건 · 카메라 (멀티캠 / 크레인 / 선수 시점)를 추가했다
• 물리 엔진 Rapier를 사용한 검증 환경을 추가했다
• 브라우저 표시와 헤드리스(Headless, 화면 없음) 실행을 분리했다
• AI가 스스로 실행 · 계측할 수 있게 되었다

이 순서로 보면 단순한 기능 소개가 아니라, 검증 환경이 단계적으로 성장한 스토리가 됩니다. 「국기관(Kokugikan) 같은 좌석을 만들어 줘」, 「선수 시점으로 움직일 수 있게 해 줘」와 같이 세세한 지시를 수십 건 단위로 내렸습니다. 지나치게 고집을 부린 것은 반성할 점입니다.

이 과정에서 강하게 느낀 것은 Web (Three.js)와 생성형 AI의 궁합이 좋다는 점입니다. 브라우저 상에서 동작하는 3D viewer는 AI가 다루기에 상당히 편리합니다. 핫 리로드(Hot Reload)로 즉시 모습이 반영되고, 타입 체크(Type Check)로 실수를 조기에 잡아내며, URL 하나로 공유할 수 있고, 헤드리스로 자동 실행까지 가능합니다. 이 「AI가 빠르게 돌릴 수 있는 무대」를 선택하는 것 자체가 결과물의 질을 결정한다고 느꼈습니다.

참고로 완성품은 브라우저 상에서 필드를 3D로 표시하며, 로봇의 경로 · 걸레의 사출 · 득점 상황을 시계열로 재생할 수 있습니다. 사출 조건이나 전략을 전환하며 멀티캠 · 크레인 카메라 · 선수 시점에서 확인할 수 있습니다.

검증 환경 중 하나로, 걸레가 날아가는 방식을 물리 엔진 (Physics Engine)인 Rapier로 테스트할 수 있는 헤드리스 시뮬레이션 (Headless Sim)도 만들게 했습니다. 저는 걸레를 실제로 던져본 적이 없어 거동을 알지 못했기에, "AI에게 물리를 테스트할 수 있는 환경을 만들게 하여 수치로 확인하기" 위한 목적이었습니다.

여기서 AI는 걸레를 "한 장의 얇은 시트"가 아니라 질점 (Mass Point)을 스프링으로 연결한 천으로 취급했습니다. 걸레가 날아가는 방식을 정해진 애니메이션으로 구현하는 대신, 질점·스프링·감쇠 (Damping)·공기 저항의 상호작용으로부터 펄럭임, 텀블링 (Tumbling), 활공과 같은 거동이 발생하는 모델을 구축했습니다. 물리 엔진으로 Rapier를 선택한 이유는 "JS에서 동작하는 물리 라이브러리를 찾다 보니 나왔다" 정도의 이유였지만, 상상보다 훨씬 깊은 단계까지 도달한 점은 솔직히 감탄스러웠습니다.

보충: 이 모델 역시 질량, 스프링 상수, 감쇠, 공기 저항, 접촉 마찰, 걸레의 치수와 같은 파라미터 (Parameter)에 의존합니다. "파라미터가 아니라 물리로부터 창발 (Emergence)한다"는 말은 과장이며, 정확하게는 "정해진 애니메이션이 아니라, 소수의 물리 파라미터의 상호작용으로부터 거동이 나오는 모델"입니다. 또한 중요한 주의 사항으로, 실제 걸레를 사용한 파라미터 식별이나 실험과의 비교는 아직 수행하지 않았기 때문에, 이 시뮬레이터는 실기기의 궤도를 고정밀도로 예측하는 것은 아닙니다. 현시점에서는 조건 비교나 구현 검증을 위한 환경으로 사용하고 있습니다.

AI 코딩을 진행하면서 수수하지만 중요했던 점은, AI에게 자료를 전달하는 방식입니다.

PDF에서 추출된 문자 정보만으로는 경기 필드의 도면이나 치수 관계까지는 올바르게 이해하지 못할 것이라고 생각했습니다. 다만, 최신 AI라면 "이 정보만으로는 도면을 이해할 수 없다"라고 스스로 판단하여, PDF 페이지를 이미지로 확인하는 등 필요한 수단으로 자율적으로 전환해 줄 것이라 기대했습니다.

하지만 이번에 사용한 코딩 에이전트 (Coding Agent)에서는 그렇게 되지 않았습니다. AI는 PDF를 텍스트화하여 구조가 무너진 마크다운 (Markdown)을 그대로 계속 읽고 있었고, 필드의 형상이나 물체의 배치, 치수 간의 관계를 거의 이해하지 못하고 있었습니다. 이는 제가 "PDF를 읽게 했다"고 생각했음에도 불구하고, AI는 인간처럼 도면을 보고 있었던 것이 아니었습니다.

• 필드 외곽의 종횡비를 잘못 파악함

• 오브젝트의 좌우 관계를 틀림

• 치수선의 숫자를 다른 부재의 치수로 해석함

• 도면과 주석의 대응 관계를 상실함

• 필드 형상을 올바르게 수정할 수 있었음

• 치수의 기준점을 인식할 수 있었음

• 물체의 배치 관계가 수정되어 시뮬레이터의 수정도 단번에 진행됨

로보콘 규칙에서는 문장뿐만 아니라 도면이나 물체의 배치, 치수 관계가 매우 중요합니다. 이번 환경에서는 도면을 처음부터 이미지로 전달하여 시각 정보로서 인식시킬 필요가 있었습니다. 이 지점은 "PDF를 주면 AI가 경기를 이해할 것"이라는 예단이 명확하게 깨진 포인트였습니다.

이번에 가장 강하게 느낀 배움입니다. 자율성 있는 AI를 활용하는 열쇠는 똑똑한 AI에게 명령하는 것 자체가 아니라, AI가 자신의 출력을 검증할 수 있는 메커니즘을 만드는 것이었습니다.

문장으로 "이 전략이 강해?"라고 물으면 돌아오는 것은 문장입니다. 하지만 뷰어 (Viewer)나 헤드리스 시뮬레이션을 만들게 하면,

• "이 각도라면 닿지 않는다"
• "이 초속이라면 들어갈 것 같다"
• "이 기구는 이쪽으로 크게 튄다"

와 같은 수치의 피드백이 돌아오게 됩니다. 여기서 비로소 AI는 "그럴듯한 말을 하는 상대"에서 "검증하며 완성해 나가는 파트너"로 변했습니다.

구체적으로는 경로 추종 (Path Following) 조정을 다음 루프에서 다듬었습니다.

1. 코딩 에이전트가 경로 추종 알고리즘을 수정
2. 헤드리스 시뮬레이션을 worker_threads로 병렬 실행
3. 파라미터를 다수 스윕 (Sweep)하여 최대 횡편차·도달 시간·오버슈트 (Overshoot)를 측정
...

포인트는 AI가 구현할 뿐만 아니라, AI 스스로 실행하여 수치로 확인하는 부분입니다. 이 루프를 돌리는 데 효과적이었던 프롬프트 (Prompt) 유형은 예를 들어 다음과 같았습니다.

이 변경이 옳다고 가정하지 말고, 구현 후에 헤드리스 시뮬레이터를 실행하십시오.
횡방향의 최대 편차·도달 시간·최종 자세의 오차를 측정하여 변경 전과 비교하십시오.
개선되지 않았다면 원인을 분석하여 재구현하십시오.

"이 변경이 옳다고 가정하지 말고, 실행해서 수치로 증명하라"고 제약을 거는 것만으로도, 성공한 척하는 보고가 줄어들고 실제로 측정된 수치 기반으로 대화할 수 있게 되었습니다.

보충: 개선 전후의 정량적 수치(횡편차나 타임이 몇 mm·몇 초 단축되었는지)는, 실물과의 교정(Calibration)을 거치지 않은 현 시점에서는 「실기의 예측」으로서 내놓을 수 있는 단계가 아니기에, 이 기사에서는 의도적으로 단정을 피하고 있습니다. 이 부분은 향후 실기 로그와의 비교를 통해 채워나가고 싶은 부분입니다.

그림으로 나타내면 다음과 같은 루프입니다.

이 「구현 → 병렬 실행 → 계측 → 스윕(Sweep) → AI가 읽고 수정」 루프를 닫을 수 있느냐가, 자율 AI를 「사용할 수 있는가」를 결정짓는 분수령이라고 느꼈습니다. AI 코딩에서 가장 투자해야 할 것은 똑똑한 모델을 고르는 것보다, 이 검증 루프를 먼저 준비하는 것입니다.

스택 선정의 축은 일관되었습니다. 「AI가 빠르게 돌릴 수 있고, 즉시 확인할 수 있으며, 즉시 공유할 수 있는 것」입니다.

• Vite + Svelte 5 + TypeScript(strict): 가볍고 빠름. 타입 체크(svelte-check)를 통해 AI의 실수를 조기에 잡아낼 수 있음.
• Three.js: 브라우저에서 3D 구현. 이번 개발에서는 궁합이 좋아 「보여줄 수 있는」 화면이 즉시 나옴.
• Rapier (물리): JS로 동작하는 물리 엔진. 브라우저와 Node 양쪽에서 동일한 코드가 돌아가므로, 검증용 시뮬레이션(sim)을 그대로 헤드리스(Headless)화할 수 있음.
• worker_threads: 헤드리스 시뮬레이션을 병렬로 실행하여, 파라미터 스윕(Parameter Sweep)을 현실적인 시간 내에 완료.
• Cloudflare Pages: URL 하나로 누구나 접속할 수 있고, 단시간에 배포 가능.

구성을 대략적으로 그리면 다음과 같습니다. 브라우저와 헤드리스 환경에서 동일한 시뮬레이션 코어를 공유하고 있는 것이 핵심입니다.

중후한 프레임워크보다는 반복 속도와 공유성을 최우선했습니다. AI 코딩에서는 모델이 한 바퀴 도는 시간이 짧을수록 검증 루프가 빠르게 돌아가므로, 이 부분이 효과적입니다.

주의: 아래는 로그를 API 단가로 환산한 참고치이며, 실제 청구 금액 그 자체가 아닙니다. 구독 이용분을 공개 API 단가에 대입하여 계산했습니다. 총 토큰 약 8.7억 개 중 대부분은 「cache 읽기」이며, 이는 과거의 문맥을 매 턴마다 다시 읽기 위해 쌓인 분량입니다.

• 총 토큰 약 8.7억 개 (대부분은 cache 읽기 858M) / 비용 ≈ $716
• 입력 49.4M (중 cache 46.8M) / 출력 0.25M / 비용 ≈ $44
• API 환산 비용 ≈ $761 (Claude $716 + Codex $44)
• 실제 작업 ≈ 19.5h (실질적으로 2일)

의외였던 점은 비용의 대부분이 「cache 읽기」였다는 것입니다. 장시간·대규모 컨텍스트(Large Context) 세션을 반복해서 돌리면, 과거의 문맥을 매 턴마다 다시 읽어야 하므로 이렇게 됩니다. 반성할 점으로는, 한 세션을 너무 길게 가져갔다는 것입니다. 용도별로 세션을 분리하고 문맥을 너무 많이 끌고 오지 않는 것만으로도 이 환산 비용은 상당히 낮출 수 있었을 것입니다. 「AI를 오래 붙잡아둘수록, 출력보다 문맥의 재독(Re-reading)에서 비용이 발생한다」는 것은 실제로 돌려보기 전에는 알 수 없는 감각이었습니다.

• 잡巾(Zoukin) 모델은 미교정 상태입니다. 실물에서의 동정(Identification) 및 실험과의 비교를 거치지 않았으므로, 실기의 궤도를 고정밀도로 예측하는 것은 아닙니다.
• 따라서, 이 시뮬레이션이 전략의 강함을 보장하는 것은 아닙니다. 어디까지나 조건 비교 및 구현 검증을 위한 환경입니다.
• sim-to-real 갭(깨끗한 시뮬레이션이 실기와 맞지 않는 문제)이 최대 리스크입니다. 사용할 경우 실기 로그로 교정한다는 전제가 필요합니다.

AI 코딩 이야기에서 조금 벗어나지만, 이번 작업의 수확으로서 적어둡니다. 결론은 「어느 한쪽」이 아니라 병용이 최적이라는 것입니다. 이번 웹 개발은 ROS2를 대체하는 것이 아니라, ROS2에 없는 계층(전략 시뮬레이션·시각화·공유)을 메우는 것이었습니다.

• Web가 효과적이었던 부분: 반복 속도가 빠름 (Vite 빌드는 초 단위, Cloudflare Pages로 짧은 시간 내 배포) / Three.js를 통해 "보여줄 수 있는" 화면이 나옴 / URL 하나로 마찰 없이 공유 가능 / Pure TS (Pure TypeScript)로 시뮬레이션 (sim)이 완결되어, 하드웨어 없이 대량의 시도가 가능함. AI 코딩과 궁합이 좋은 것은 바로 이 계층입니다.
• ROS2가 필요한 부분: 실제 기기의 드라이버, 실시간 제어 (Real-time control), 센서 통합. 이 부분은 Web으로 대체할 수 없습니다.
• 최대 리스크: Sim-to-real 갭 (Sim-to-real gap). 깔끔한 시뮬레이션이 실제 기기와 맞지 않는 것이 함정이며, 사용할 경우 실제 기기 로그로 교정(Calibration)한다는 전제가 필요합니다.

요컨대 "ROS2에서 갈아타는 것"이 아니라, 실제 기기 제어는 ROS2, 전략 검증·시각화·공유는 Web이라는 역할 분담이 이번에는 적절했습니다. 향후에는 실제 기기 로그나 ROS2 토픽을 Web 시뮬레이터에 rosbridge로 연결하여, 시뮬레이션과 실제 기기의 차이를 교정하는 구성을 생각하고 있습니다. ROS2 + Web 시각화/전략 시뮬레이션(sim)을 잇는 것이, 이번 경험상 가장 발전 가능성이 높은 형태라고 생각합니다.

처음에는 최상위 클래스의 모델에게 "전국 우승 전략"을 쓰게 할 생각이었습니다. 하지만 실제로 해보니, 전략서는 실제 의사결정에 사용할 수 있을 정도로 구체적이지 않았습니다. 흥미로웠던 점은, AI에게 뷰어(viewer)를 만들게 하고 그것을 조금씩 확장하여 경기 시뮬레이터로 만들어가는 과정과, AI 스스로 그것을 실행하여 수치로 확인할 수 있게 만든 부분입니다.

가져가고 싶은 배움은 세 가지입니다.

• AI에게 도면을 이해시키려면 텍스트뿐만 아니라 시각 정보(페이지 이미지)를 전달할 것.
• AI에게는 구현뿐만 아니라 실행·측정·개선까지 수행하게 할 것.
• 기술 스택은 AI의 반복 속도를 기준으로 선택할 것.

마지막으로 한 번만 더.

AI 코딩에서 중요한 것은 가장 똑똑한 모델을 선택하는 것이 아니라, 모델이 실수를 발견할 수 있는 환경을 만드는 것이었다.

고전 로보콘 2026 경기 시뮬레이터

소스 코드