맹구run 개발기

TL;DR 스펙 주도 개발로 데스크탑 펫 앱을 만들었는데 코드는 한 줄도 안 봤습니다. 스프라이트는 나노바나나가, 코드는 클로드 코드가 짰습니다. prd.json 55번 고치면서 배운 건 — 스펙이 정확하면 코드는 따라온다는 것.

스펙만 쓰면 된다고

매일을 클로드와 함께 일하고 있습니다. 어떻게 하면 내가 원하는 대로 결과물을 만들어 낼 수 있을까. 그 고민을 하던 중에 우연히 11 Tips For AI Coding With Ralph Wiggum이라는 아티클을 보게 됐습니다. 2026년 1월이었는데요, 랄프가 뭐지? 부터 찾아봤습니다. 랄프 루프는 AI한테 일을 시키는 반복 사이클인데, 핵심은 SDD(스펙 주도 개발)를 무한 루프로 돌리는 얘기였습니다.

나름 AI에게 "해줘" 보다는 더 잘 질문한다고 생각했었는데, SDD라는 개념을 알게 되니까 그동안 고민하던 게 풀릴 것 같았습니다.

단순 바이브코딩으로 간단한 건 전에도 해봤습니다. 명함 생성기나 한 페이지짜리 웹사이트(오늘의 핑계라는 정적 페이지였지만, 지금은 디버깅용으로 이용되고 있습니다). 그건 "해줘" 한마디면 됐습니다. 코드를 흐린눈 하면서 양심에 찔리기도 했지만, 어쨌든 결과물은 나왔습니다.

그런데 스펙만 쓰고 중간에 방향을 안 잡아주면 어디까지 되는지는 해본 적이 없었습니다. 해보고 싶었습니다.

맹구

제게는 "맹구"라는 이름을 쓰는 가족이 있는데요. 본가에 있어서 자주 못 보기도 했습니다. 마침 인스타에서 완전 옛날에 있던 "하얀마음 백구" 바탕화면 앱을 보게 됐는데, 겸사겸사 스펙 주도 개발 실험도 하고 우리 맹구도 일하면서 볼 겸 바탕화면에 올리기로 했습니다. 클릭하면 간식 먹고 기뻐하고, 오래 놔두면 구석에 가서 자고, 부르면 뛰어오는 데스크탑 펫. 너무 귀엽고 재밌겠다 싶었습니다.

앱을 처음부터 끝까지 만들었는데 코드는 한 줄도 보지 않았습니다. 쓰지도 고치지도 읽지도 않았습니다. 맹구 스프라이트는 구글의 나노바나나가 뽑아줬고 코드는 클로드 코드가 짰습니다.

첫 커밋

첫 커밋에 코드는 없었습니다.

SPEC.md에 맹구run이 뭔지 적었습니다. 어떤 앱이고 어떤 기능이 있고 저장은 어디에 하는지. AGENTS.md에는 클로드 코드가 지켜야 할 규칙을 적었습니다. 커밋 전에 typecheck, test, lint를 전부 통과해야 한다거나, 파일 삭제할 때 rm 대신 trash를 쓴다거나 하는 것들. 그 다음 커밋에서 아티클에서 참고한 포맷 대로 prd.json으로 구조화했습니다. 기능을 작업 단위로 쪼개서 하나씩 완료 표시를 하도록, 세션이 끝나더라도 컨텍스트는 파일로 남아있도록.

이 세 개가 '쓴' 전부였습니다. AI한테 불필요한 자유를 주면 엉뚱한 데서 사고가 나더라고요. 규칙을 먼저 깔아놓는 게 중요했습니다.

첫날 저녁에 시작했는데 자정쯤에 세이브 시스템이며 투명 윈도우며 애니메이션 상태머신이 다 만들어져 있었습니다. 그 뒤로 조금씩 기능이 붙더니, 일주일 뒤에 맹구가 처음으로 화면 위를 걸어다녔습니다.

스펙만 썼는데 강아지가 돌아다니고 있었습니다.

2월에는 앱이 너무 큰 것 같아서 Electron을 통째로 걷어내고 Tauri로 옮겨버렸습니다. 100MB이던 앱이 8.6MB가 됐습니다. 저는 러스트를 하나도 모르는데요. 의도하지 않았는데 윈도우 앱까지 지원이 완료되더라고요. 저는 only 맥에서만 작업했는데 말이죠.

써봐야 아는 것

사실 처음부터 끝까지 잘 되기만 한 건 아니었습니다.

회사에서는 모니터를 세 대 쓰는데 맹구가 모니터 사이 빈 공간으로 걸어가버렸습니다. 좌표 계산이 틀렸는데 세 번을 고쳤습니다. 클로드 코드가 코드를 못 짠 게 아닙니다. 그런 환경이 있다는 걸 스펙에 적을 수가 없었던 겁니다.

직접 써봐야 나오는 문제들이 있었습니다. 아무리 정교하게 써도 실제 환경을 전부 담을 수는 없습니다. 이건 바이브코딩이라서가 아니라 원래 그렇습니다.

그런데 코드를 직접 안 만지니까 문제가 생겼을 때 접근이 달라지더라고요. 코드가 아니라 스펙에서 먼저 원인을 찾게 됐습니다. 코드를 들여다보는 대신 프로덕트 관점에서 뭐가 부족했는지를 먼저 살펴보게 되는 거였습니다.

코드가 따라왔다

한계는 있었지만 스펙 중심으로 일하는 패턴 자체는 유효했습니다. 커밋이 167개 쌓였는데 하나하나가 작습니다. 기능 하나 붙이고 커밋, 버그 하나 고치고 커밋. 이 기록을 보면 패턴이 있습니다. 문서가 먼저 바뀌고 코드가 따라옵니다. prd.json이 정확하면 기능이 잘 붙었고 부족하면 버그가 났습니다.

prd.json은 55번 수정됐습니다. (클로드에게 분석을 부탁했습니다) 처음에는 할 일 39개를 나열한 체크리스트였는데 나중에 보니까 버전별 피처 문서가 되어 있었습니다. 왜 이렇게 만들었는지, 이 버그는 뭐 때문이었는지, 기술 부채는 뭐가 남았는지 같은 것들이 쌓여서요. 어떤 맥락이 부족해서 AI가 놓쳤던 걸까 생각하다 보니 점점 더 구체적인 컨텍스트를 담게 됐습니다. progress.txt도 만들어서 어떤 결정들을 했는지 기록하게 했고요. 참고로 둘 다 직접 수정하진 않고 시키기만 했습니다. 코드보다 이 파일들이 프로젝트의 역사에 가까웠습니다.

이전 글(추상화에 대하여)에서 "구체적인 구현은 AI가 잘 해줍니다. 하지만 같은 구조라고 알아보는 눈은 사람의 영역입니다"라고 적었는데 맹구run을 만들면서 이 말이 좀 더 구체적이 된 것 같습니다. 코드를 안 봤다기보다는 구현을 맡기고 구조에 집중했다는 게 더 정확합니다.

결론?

일단 맹구run은 만들었습니다. 아직도 버그는 존재하고, 만들고자 하는 로드맵은 계속 보류 중인데요.

스펙을 어떻게 쓰느냐에 따라 AI가 만들어내는 결과물이 달라진다는 걸 직접 확인한 프로젝트였습니다. 그리고 엔지니어가 아니라 프로덕트를 만드는 사람으로서 AI랑 일하는 법을 처음 배운 프로젝트이기도 했습니다.

지금도 제 맹구는 제 모니터에서 잘 자고 있습니다. 맹구run이 궁금하거나 어떤 커밋들이 쌓여서 만들어진 앱인지 궁금하시다면 공개된 레포이니 찾아와서 구경하셔도 됩니다.