'바이브코딩'의 약점과 '마이너리티 리포트' (feat. Tiny Cloud) : 클리앙

안녕하세요. 취미로 가끔씩 DIY 프로젝트를 진행하고 클리앙에 그 제작내용을 계속 공유하고 있습니다.

지난 '나의 시간이 예술이 된다' 앱과 관련한 글 이후, 오랜만에 다시 뵙니다.

바이브코딩 시작 이후 당분간은 1년에 2~3개 서비스를 꾸준히 내는 걸 목표로 계속 프로젝트를 진행하고 있습니다.
그리고 세 번째 앱을 출시했습니다.

그동안 바이브코딩을 진행하면서 코드 생성 속도는 분명히 빨라졌는데, 개발이 길어질수록 이상하게 같은 자리를 맴도는 시간이 늘었습니다. 원인을 찾다 보니 문제는 AI가 아니라 '저'였더라구요. 이번엔 바이브코딩을 진행하면서 계속 걸렸던 문제에 대해 공유해 봅니다.

3줄 요약

10minute.studio 세번째 앱 ‘Tiny Cloud’를 출시 했습니다.
Claude Skill 이 정말 유용하더군요.
바이브코딩에서 ‘마이너리티 리포트'는 정말 중요합니다.

'여정'과 '만남'의 힐링게임입니다.

바이브코딩 첫 도전 앱이 'FEVER2048'라는 퍼즐류 게임이었는데, 오랜만에 게임장르로 방향을 잡았습니다.

'Tiny Cloud'라는 이름의 '비를 테마로 한 힐링 게임'으로, 작은 물방울이 세상을 흘러다니며 성장하는 내용입니다.
도파민을 계속 자극하는 시대를 역행하여, 작은 물방울의 성장과 주변 사물과의 만남을 함께 동행하며 잔잔히 지켜보는 게임입니다. '아주 작은 존재에서 점차 성장하는 방식'으로 Osmos나 상어키우기 류의 게임에서 영감을 받았지만, 주변을 흡수해 성장하며 파괴하는 것이 아닌, 그 성장의 감각을 여정의 방식으로 풀어내고 있습니다.

손그림(Doodle) 톤의 그래픽과 잔잔한 배경음악, 그 안에서 작은 물방울의 성장을 보는 어찌보면 단순한 방식입니다. 그러나 골목의 웅덩이에서 시작해 자연으로, 마른 강으로 흘러가며 길에서 만난 개미·거미·씨앗·새를 돕고, 그 과정에서 물방울이 조금씩 자랍니다. 이 과정에서 여러 주변 사물을 만나 그들의 소소한 이야기를 들으며 플레이를 반복하게 됩니다. 플레이어를 압박하는 스코어도, 시간제한도, 게임오버도 없습니다.

기획 초기에는 Godot, Love2D 같은 인디게임 엔진을 고려했었지만, 모바일 플랫폼을 원활히 지원하지 않아 Flutter + Flame 조합의 플랫폼으로 개발을 진행했습니다. 특히 그래픽 구현에 있어서 에셋은 별도로 사용하지 않았고, 수채화 톤의 종이 질감과 손그림 느낌을 Canvas 코드를 최대한 활용하여 힐링톤에 맞게 구현했습니다.

바이브코딩에서 '스킬'은 이제 필수네요.

그동안은 Claude 와의 논의에서 내려진 결론을 문서로 정리하면서 개발을 진행했었습니다. 이번에 Claude Code에 역할별 스킬을 좀 더 활용해 봤는데, 초기 결과물과 작업속도가 확실히 개선되더라구요. 그동안 사용된 여러 스킬들 중, 이 프로젝트에서 최종 정착한 스킬들 입니다.

Karpathy Guideline Skill — 코드부터 짜지 않고, 논리를 먼저 정리한 다음 실행하도록 강제합니다. 기획-개발 순서의 파이프라인이 좀 더 안정적이 되었습니다.
Ponytail Skill — 기능 개발을 요청하면 AI가 늘 새 걸 만들어내면서 규모가 커지고 버그가 속출하는데, 이 스킬은 이미 있는 걸 최대한 재사용하도록 권장합니다. 때문에 토큰 절약에도 도움이 됩니다.
Apple-Design / Dumbify Skill — UX는 애플 HIG 기준으로 사용성을 높이고, 게임 문구는 AI 특유의 기계어투 대신 사용자 친화적으로 다듬어 줍니다.

해당 스킬들은 저에게 만족도가 좋아서 프로젝트에 국한하지 않고 바이브코딩 전반에서 활용할 수 있도록 ‘전역스킬’로 세팅해 두었습니다.

이제, 바이브코딩의 약점이 보이더라구요

바이브코딩을 계속 진행하다 보니, 코드 생성 속도는 분명히 빨라졌는데 같은 이슈를 맴도는 시간이 길어지는 일이 반복적으로 발생했습니다. 분명 2주 전에 검토하고 접었던 방식을 또 Claude가 다시 구현하고 있거나, 신규 검토 과정에서 이전에 왜 A안 대신 B안으로 갔는지 기억이 가물가물해져 A안을 다시 들여다본다거나… 하는 일이 점점 늘어나고 있더라구요.

저는 AI가 맥락을 기억하지 못해서 그런 줄 알고 한동안 Claude를 구박(?)했었는데, 파악해보니 문제는 결국 ‘저’였습니다. 개발과정에서의 논의 과정을 제가 대부분 제대로 기억하지 못하고 있더라구요. 비로소 ‘바이브코딩’의 약점이 보였습니다.

영화 ‘마이너리티 리포트’에서, 범죄를 예지하는 세 예언자의 예언이 갈릴 때 시스템은 다수 의견만 채택하고 소수 의견(minority report)은 폐기해버립니다. 그런데 정작 ‘진실’은 그 폐기된 소수 의견 쪽에 있었죠. 바이브코딩의 개발도 다를 바 없더라구요. 채택된 내용만 코드로 남고, 함께 검토했던 다른 안들은 조용히 사라집니다.

문제는 그 검토 과정을 제가 기억하지 못하고 있었습니다.
직접 개발 코드를 짜던 시절엔, 그 고민과 결정 과정이 노동으로 몸에 새겨졌었습니다. 디버깅을 위해 몇날 며칠을 고민하고 삽질하다 갈아엎더라도 그 선택의 과정은 사라지지 않고 나의 경험이 되고 지식이 되어 기억되었습니다.
그런데 ‘바이브코딩’은 AI가 떠먹여주고 저는 “B로 가자” 선택만 하면 문제가 대부분 해결됩니다. 그러다보니 결정비용은 거의 ‘제로(zero)’가 되어 버리고, 다른 안들은 기억으로 남겨지지 않습니다. 게다가 AI가 이슈마다 선택지까지 친절하게 제시하니 결정해야 하는 횟수는 늘어났지만, 정작 개발자의 고민의 시간은 오히려 줄어듭니다.

결국 ‘바이브코딩’에서 남는 건 코드 뿐인데, 그 코드에는 선택의 결과만이 담겨있습니다. 관리하는 이슈 문서에도 진행결과만 있을 뿐, 검토했다 접은 ‘마이너리티 리포트’는 어디에도 남지 않습니다.

그래서 바이브코딩에서 정말 필요한 것은, 개발 과정에서 우리가 무엇을 선택했고, 무엇을 선택하지 않았는지, 그 논의 과정이라는 생각이 들었습니다.

볼트에 논의를, 레포에 정제본을 정리하고 있습니다

지식을 볼트로 분리하니 다른 프로젝트에서의 활용도도 높아집니다.

지난 글에서 옵시디언 문서를 symlink로 연결해서 주요 정보를 백업/관리하는 방법을 언급했었는데, 이번엔 한 단계 더 나아가 옵시디언 쪽의 워크플로우를 다듬어 논의가 쌓이도록 만들었습니다. 이번 프로젝트에서 가장 도움이 된 변화입니다.

프로젝트를 진행하면서 볼트-레포에 역할을 나눠 논의 내용을 쌓았습니다. 층을 나눈 덕에 볼트 쪽엔 “왜 그렇게 정했나”의 과정이 남고 레포 쪽엔 “그래서 뭘 만들면 되나”와 그 근거만 남습니다. 코딩 세션에서 과거 논의 과정을 다 헤짚을 이유가 없어졌습니다. 레포 readme.md에는 아예 "설계 문서 위치 — 레포 밖 지식 볼트" 섹션을 만들어서, 세션이 시작될 때 어디를 봐야 하는지 알려줍니다.

구조는 카파시(Andrej Karpathy)가 공개한 LLM Wiki 노트를 참고했습니다. 기존 RAG는 매번 검색으로 지식을 다시 발견하는데, LLM Wiki는 반대로 LLM이 마크다운 위키를 계속 갱신해서 지식이 누적되게 만듭니다.

옵시디언에 사용한 플러그인들

Remotely Save — 맥/아이폰/윈도우 등 여러 기기를 원격 동기화해서 볼트를 어디서든 최신 상태로 유지합니다.
Linter — 문서 포맷을 정해진 규칙에 따라 자동으로 정리해 줍니다.
Dataview — 볼트 내 각 폴더에 생성한 문서를 쿼리로 모아서 index 문서로 자동 생성해줍니다.
Auto Link Title — 링크 붙일 때 URL이 아닌, 퍼머링크의 제목을 자동으로 채워줍니다.

기각된 내용도 같이 남깁니다(마이너리티 리포트)

이때 최종 확정된 내용뿐 아니라 기각된 내용도 같이 남겨서, 나중에 같은 논의를 반복하거나 같은 실수를 또 하지 않도록 하고 있습니다. 중요한 건 위치입니다. 기각 기록을 별도 로그 파일로 빼면 아무도 안 보기 때문에, 그 결정이 실제로 사는 문서 안에 붙입니다. 저는 스펙 문서마다 결정 바로 아래에 기각 사유를 답니다.

폐기됨 — 충돌 기반 수분 손실
충돌 시 추가로 수분을 깎는 방식은 힐링 톤 파괴·회피 행동 유발·증발과의 이중 페널티 우려로 기각, 미구현.

프로젝트가 길어질수록 저 결정들은 다시 매력적으로 보이게 됩니다. "충돌하면 물방울이 좀 깎여야 긴장감이 생기지 않나?" 이 생각이 두 번째로 들었을 때, 문서를 열어보고 재논의 없이 바로 패스할 수 있었습니다.

더 유용했던 건 결정 자체보다 판단이 뒤집힌 과정을 남긴 기록입니다. 결론만 있으면 “철회함”으로 끝나지만, 왜 뒤집혔는지가 남으니 비슷한 상황에서 기준이 하나 생기더라구요 — 기술 구현과 서사 일관성이 갈리면 후자를 고른다는 식으로.

논의 과정에서의 저장 여부는 제가 정하되, ‘뭐가 남을 가치가 있었나’의 판단만 미리 시켜둡니다. 결론이 날 때마다 “이건 ISSUES.md §1.3으로 갈 내용입니다" 한 줄만 Claude 가 제시하게 하고, 제가 ‘저장하자’라고 요청하면 미리 정리해둔 맥락 그대로 볼트에 들어갑니다.

다만, 아직 ‘남겨야 할’ 맥락을 어디까지 잡아야 할지 최적화가 필요합니다. 볼트로 분리한 덕분에 용량과 문서 파편화 이슈는 해결됐지만, 지금은 너무 긴 내용이 저장되고 있습니다.

AI와 길게 작업하시는 분들은 결정이나 맥락을 어떻게 남기시는지 궁금합니다. 옵시디언이 아니어도 되고요. 노션이든 그냥 md 파일 하나든, 실제로 굴러가는 방식이 있으면 댓글로 의견주시면 감사하겠습니다.

게임개발은 또 다른 난이도였습니다.

'Tiny Cloud'는 기존 앱들과 다르게 그래픽 요소가 들어간 게임이다 보니, 레벨/밸런스 조정 이외에도 발열과 퍼포먼스 최적화에 많은 시간이 걸렸습니다. 효과음과 배경음을 메모리에 어느 타이밍에 올리냐에 따라 퍼포먼스가 달라지기에 실기기에서 직접 구동하면서 Flutter에서 제공하는 Devtools로 매번 로그를 취합해서 프레임 떨어지는 구간 찾고, CPU와 GPU, 메모리의 병목구간을 확인하며 튜닝작업을 끊임없이 반복했습니다.

그 외에도 수채화 톤의 그래픽 스타일을 잡기 위해 수많은 이미지 타입을 검토하고, 만들었다 폐기하길 반복했습니다. 130여 종의 손그림(Doodle) 아이콘 역시, 초반의 삽질과 폐기한 시도들까지 전부 남겨둔 덕분에 커스텀 스킬로 정리할 수 있었습니다. 잔잔한 분위기에 맞게 등장하는 수집품 하나하나의 '이야기'를 구성하는데도 꽤 시간이 걸리더라구요.

아이콘 제작을 위한 스킬과 빌더를 만들었더니, 작업이 훨씬 효율적이 되었습니다.

'Tiny Cloud'는 지친 하루를 잠시 여백으로 채우는 힐링 게임입니다.
작은 물방울이 성장하면서 동료를 만나 그들의 이야기를 듣고, 함께 여정을 떠나는 과정을 잔잔하게 구현했습니다. 달성할 과도한 목표도 게임오버도 의도적으로 배제하고 있습니다.
도파민의 자극에서 벗어나 지하철 한 정거장, 커피가 나오길 기다리며, 그리고 잠들기 전에 잠시나마 작은 틈으로 채워지길 바랍니다.

본문이 길어져서 상세 내용은 생략했습니다.
레포-볼트 파이프라인에 대한 좀 더 자세한 내용은 미디엄 블로그에 전문을 확인해주세요.

→ Tiny Cloud 게임 소개

→ 미디엄 블로그 전문 확인

앱이 궁금하신 분이나 이미 플레이해보신 분은 댓글로 남겨주시면 감사히 읽겠습니다.
플레이 후기는 1인 개발자에겐 큰 힘이 됩니다.

사용기

서비스/SW '바이브코딩'의 약점과 '마이너리티 리포트' (feat. Tiny Cloud) 6