웹캠 하나로 ESP32에 둠을 올린 로컬 LLM — 피드백 루프의 힘
C 언어 코드 한 줄 짤 줄 모르는 비개발자가, 알리에서 파는 몇천 원짜리 초소형 ESP32 보드에 전설의 명작 ‘둠(DOOM)’을 포팅해서 띄워버렸다. 그것도 비싼 클라우드 API 한 번 안 쓰고, 순수 방구석 로컬 LLM으로만. 어제 r/LocalLLM에 올라온 이 경이롭고도 골 때리는 성공담을 읽다가 육성으로 감탄이 터져 나왔다. 이건 단순한 바이브 코딩(Vibe Coding)의 승리가 아니다. AI에게 ‘눈’을 달아줬을 때 어떤 기적이 일어나는지 보여주는 최고의 엔지니어링 우화다.
무엇을 했나
글쓴이(u/Sulya_be)는 스스로를 개발자가 아니라고 소개한다. 그냥 LLM 가지고 노는 걸 좋아하는 흔한 ‘바이브 코더’다.
세팅은 심플했다. RTX 5090 한 장 꽂힌 PC에서 LM Studio로 Qwen 3.8 27B 모델을 띄우고, 에이전트 하네스로는 OpenCode Desktop을 물렸다. 타겟 디바이스는 알리익스프레스에서 만 원도 안 주고 산 싸구려 LCD 개발보드(Cheap Yellow Display, 일명 CYD). 규칙은 딱 하나, “인간은 절대로 코드에 손대지 않는다”였다.
하지만 현실은 녹록지 않았다. GBA(게임보이 어드밴스)용 오픈소스 둠 코드를 쥐어주고 ESP32로 변환하라고 시켰는데, 이틀 내내 삽질한 끝에 화면에 뭔가 뜨긴 했지만 색상이 완전히 깨져서 외계 신호처럼 출력됐다.
진짜 지옥은 디버깅이었다. 임베디드 보드 안에서 무슨 일이 일어나는지 화면을 캡처할 방법이 없으니, 글쓴이가 스마트폰으로 LCD 화면 사진을 수십 장씩 찍어서 채팅창에 일일이 첨부해 줘야 했다. 인간이 AI와 하드웨어 사이에서 육체노동 셔틀을 하다가 결국 녹초가 되어 포기 직전까지 갔다(내가 AI를 부리는 건지 AI가 나를 부리는 건지…).
바뀐 것 하나: 웹캠
사흘째 되던 날, 글쓴이는 기가 막힌 잔머리를 굴렸다.
집구석에 굴러다니던 굴뚝같은 USB 웹캠 하나를 가져와서, 삼각대에 꽂아 ESP32 LCD 화면 바로 앞에 딱 고정해 둔 것이다. 그리고 에이전트에게 덤덤하게 프롬프트를 날렸다.
“네가 짠 코드가 보드에서 어떻게 돌아가는지 궁금하면, 컴퓨터에 연결된 이 웹캠을 직접 봐라.”
# 대략 이런 구조
LLM --코드 빌드 & 플래싱--> ESP32 (둠 실행)
ESP32 실제 LCD 화면 --> 웹캠(영상 캡처) --> LLM이 직접 눈으로 확인 & 디버깅
이건 단순한 편의 기능이 아니었다. 모델에게 드디어 ‘물리적인 시각(Vision Feedback Loop)’이 생긴 순간이었다. 자기가 방금 컴파일해서 보드에 밀어 넣은 코드가 실제 물리 화면에 어떻게 렌더링 되는지 스스로 눈으로 확인하고, 그 피드백을 바탕으로 다음 코드 수정을 판단할 수 있게 된 것이다.
결과는 그야말로 경이로웠다. 단 3시간도 안 걸려서 보드 화면에 영롱한 둠 타이틀 로고가 선명하게 떴다. 터치스크린이 먹통이었지만 “터치가 안 먹는다”고 한마디 던져주자 알아서 드라이버 코드를 고쳤고, 시리얼 통신을 통한 컨트롤러 조작까지 완벽하게 구현해 냈다.
물론 나중에 확인해 보니 깃허브 어딘가에 있던 GBA→ESP32 포팅 오픈소스를 모델이 검색해서 영리하게 참조하긴 했다. 하지만 필요한 레퍼런스를 웹에서 스스로 뒤져서 내 하드웨어 규격에 맞게 깎아 넣는 것 역시 훌륭한 엔지니어링 에이전트의 역량이다.
진짜 흥미로운 부분은 세션 로그
글쓴이가 공개한 에이전트의 터미널 생각(Thinking) 로그를 보면 더 소름이 돋는다.
모델은 둠의 거대한 맵 데이터인 WAD 파일이 ESP32 내부 플래시 메모리에 다 안 들어간다는 사실을 깨닫자, 무식한 스트리밍 대신 파일을 전략적으로 청크 단위로 쪼개 넣는 결정을 내렸다. “SD 카드에서 매번 읽어오는 캐싱 방식은 너무 느려서 프레임이 안 나온다”는 판단까지 곁들였다.
더 압권인 건 터치스크린과 SD 카드가 동일한 SPI 버스를 공유하며 충돌을 일으키자, 터치를 소프트웨어 SPI로 우회할지 고민하다가 “어차피 시리얼 조작이 되니 속도를 위해 SD 카드 인터페이스를 과감히 버린다”는 트레이드오프를 스스로 결단했다는 점이다.
이건 어설픈 임베디드 주니어 개발자보다 훨씬 냉철한 하드웨어 리소스 최적화 판단이다. 70B나 프론티어급 모델도 아니고, 고작 로컬에서 돌아가는 27B짜리 오픈 가중치 모델이 이런 의사결정을 내렸다는 게 믿기지 않는다.
왜 주목할까
인터넷에는 매일같이 “AI로 코딩 혁명이 왔다”는 뜬구름 잡는 찬양과 벤치마크 점수가 넘쳐난다. 하지만 이번 사례는 실패와 성공을 가른 진짜 차이가 무엇인지 너무나 명확하게 보여준다.
하드웨어도 같았고 모델(Qwen 3.8 27B)도 똑같았다. 바뀐 건 오직 인간이 모델에게 쥐어준 ‘피드백 루프(Webcam Feedback)’ 하나뿐이었다.
임베디드 보드에는 브라우저 콘솔도 없고 스크린샷 API도 없다. 그 막막한 블랙박스 상황에서 “웹캠으로 화면을 직접 비춘다”는 지극히 원초적이고 아날로그적인 로우테크(Low-tech) 발상이 하이테크 LLM의 잠재력을 단숨에 폭발시켰다.
결국 에이전트의 지능을 탓하기 전에, 에이전트가 자기 행동의 결과를 스스로 관찰할 수 있는 ‘닫힌 루프(Closed Loop)’를 인간이 제대로 깔아줬는가를 먼저 돌아봐야 한다.
정리
“사람 손은 코드 한 줄 안 댄다”는 철칙을 지키면서 몇천 원짜리 보드에 둠을 올리는 데 걸린 시간은 단 3시간이었다. 마법의 프롬프트가 아니라 웹캠 하나가 이뤄낸 승리다.
오늘도 내 에이전트가 터미널에서 멍청하게 헛돌며 엉뚱한 코드를 뱉어내고 있다면, 모델을 바꾸기 전에 한번 가만히 생각해보자. “지금 이 녀석이 자기가 친 코드의 결과를 제대로 볼 수나 있는 상태인가?”
눈먼 에이전트에게 백날 프롬프트로 설명해 봤자 입만 아프다. 때로는 백 마디 말보다 웹캠 하나 들이밀어 주는 게 백배는 빠르다.