6개월간의 바이브 코딩: 시작할 때 알았더라면 좋았을 것들

이건 그냥 간단한 HTML 게임이었다. 프로젝트라고 할 것도 없이 그냥 iCloud 환경에 박아두고 썼다. 게임 전체를 그냥 main 브랜치에 다 때려 박았고, 처음에 프롬프트 한 페이지 쓴 걸로 게임의 80%는 다 만들어졌다.

딱 이 정도 수준만 원한다면, 그냥 Claude Code나 ChatGPT 켜서 프롬프트 가지고 놀아봐라. 코딩 경험 1도 없어도 꽤 그럴싸한 걸 만들 수 있다.

근데 좀 복잡한 앱을 만들기 시작하니까 금방 깨닫게 되더라. AI한테 코드 짜달라고 하는 건 사실 제일 쉬운 부분이고, 그 외에 관리해야 할 것들이 훨씬 더 귀찮고 시간도 많이 잡아먹는다는 걸 말이다.

요즘은 'Plate It'이라는 앱을 만들어서 쓰고 있다.

Plate It은 영상이나 웹페이지에 있는 레시피를 긁어와서 보기 편하게 정리해 주는 앱이다. 광고도 없고, 레시피 찾으려고 스크롤 끝도 없이 내릴 필요도 없다.

레시피 언어 번역도 되고, 장보기 목록도 짜주고, 식단 관리, 즐겨찾기, 알레르기 태그, 전체 검색까지 다 된다. 친구나 가족들한테 레시피 공유하는 기능도 넣었다.

요리 좋아하는 사람으로서 이거 만드는 과정 자체가 진짜 즐거웠다.

근데 Plate It을 만들면서 바이브 코딩이 얼마나 빨리 복잡해질 수 있는지 뼈저리게 느꼈다.

내가 배운 것 중 가장 중요한 것들을 정리해 봤다.

1. 어떤 AI 코딩 모델이 제일 좋은지 따지는 데 너무 목매지 마라.

Claude Code랑 ChatGPT 둘 다 코딩은 기가 막히게 잘한다.

인터넷 보면 서로 자기 게 최고고 상대방 건 쓰레기라고 싸우는 애들 천지인데, 그런 거에 휘둘리지 마라. 둘 다 써본 입장에서 말하자면, 둘 다 내가 필요한 결과물 뽑아내는 데는 아무 문제 없었다.

개인적으로는 요즘 Claude Code를 더 자주 쓴다. 내 작업 방식에 딱 맞는 서드파티 플러그인 생태계가 더 잘 갖춰져 있거든.

근데 내가 깨달은 가장 중요한 사실은, 모델 자체가 뭐냐보다 그 모델을 어떻게 굴리느냐가 훨씬 중요하다는 거다. 아무리 좋은 모델이라도 프롬프트 개판으로 짜고, 계획도 없고, 검토도 안 하고, 코드베이스 이해도 없이 시키면 결과물은 그냥 쓰레기통 되는 거다.

2. AI한테 코드 짜게 하는 건 쉬운 부분이다.

처음 시작할 때 내 작업 방식은 딱 이거였다.

아이디어 떠올린다 -> Claude한테 설명한다 -> Claude가 짜게 한다 -> 테스트한다 -> 에러 나면 Claude한테 고치라고 한다.

간단한 HTML 게임 만들 때는 이게 놀라울 정도로 잘 먹혔다.

근데 프로젝트가 커지니까 바로 무너지더라. 이건 나중에 어떻게 해결했는지 얘기해 줄게.

기능들이 서로 얽히기 시작했다. 하나 고치면 다른 게 터지고, 왜 이렇게 짰는지 기억도 안 나고. AI한테 수정 좀 해달라고 하면 내가 건드리지 말라고 한 부분까지 싹 다 건드려놔서 멘붕 온 적이 한두 번이 아니다.

앱이 커질수록 계획 짜는 게 진짜 중요해지더라.

3. main 브랜치에 바로 코딩 좀 하지 마라.

알아, 벌써부터 머리 쥐어뜯는 소리 들린다.

나도 처음엔 브랜치가 뭔지, worktree가 뭔지 1도 몰랐다. 그냥 main에 바로 코딩하는 게 제일 편했으니까.

근데 결국엔 에이전트끼리 서로 방해 안 받으면서 여러 기능을 동시에 만들고 싶어지더라.

그래서 찾은 게 worktree다.

나처럼 비전공자인 사람들을 위해 쉽게 설명하자면, worktree는 에이전트한테 프로젝트 복사본을 하나씩 쥐여주는 거다. 거기서 마음껏 만들고 테스트해도 내 메인 앱은 안전하니까.

이거 도입하고 나서 진짜 신세계였다.

근데 또 다른 문제가 생기더라.

이제는 그 수많은 worktree를 내가 다 관리해야 한다는 거다.

4. 코딩 전에 계획부터 짜니까 결과물이 차원이 달라졌다.

하면서 제일 좋았던 것 중 하나가 Compound Engineering이다. Claude에 추가할 수 있는 플러그인인데, 이거 진짜 강추한다. Github에서 무료로 받을 수 있다.

그냥 AI한테 "이거 만들어줘"라고 던지는 게 아니라, 체계적인 과정을 거치게 된다.

같이 아이디어 브레인스토밍하고, 코드베이스 분석하고, 계획 세우고, 에이전트가 작업하고, 결과물 검토하고, 나중에 다른 에이전트가 참고할 수 있게 학습 내용까지 기록한다. 그냥 /ce-brainstrom 명령어 치고 프롬프트 입력하면 끝이다.

그래, 토큰은 더 많이 든다.

근데 그냥 무작정 기능 요청해서 코딩 시킬 때보다 결과물 퀄리티가 10배는 더 좋다.

내가 배운 가장 큰 교훈은, 코딩 시작하기 전에 뭘 만들지 정확히 정하는 데 시간을 더 쏟는 게 나중에 시간 엄청나게 아껴준다는 거다.

5. AI 코딩 에이전트를 여러 개 돌리면 또 다른 문제가 생긴다.

이게 나한테는 제일 큰 반전이었다.

worktree 쓰는 법 익히고 나서 여러 작업을 동시에 돌리기 시작했거든.

처음엔 진짜 개꿀이었다.

근데 갑자기 이런 고민들이 쏟아지더라.

다음엔 어떤 기능을 작업해야 하지?

어떤 worktree를 동시에 돌려도 되지?

이 기능은 저 기능이 끝나야 시작할 수 있는 건가?

어떤 브랜치가 준비됐지?

뭐가 테스트 됐더라?

뭐가 검토됐지?

뭐를 안전하게 main으로 합칠 수 있지?

두 에이전트가 앱의 같은 부분을 수정하려고 하면 어떻게 될까?

결국 깨달은 건, 내가 더 이상 코드 짜는 것 자체로 끙끙대고 있는 게 아니라는 사실이었음.

진짜 문제는 코드를 짜면서 그 모든 걸 관리하는 거였어.

프로젝트 관리를 편하게 해줄 괜찮은 오케스트레이션 레이어나 IDE를 찾아봐. 나도 Claude Code 돌리다가 창 지옥에 빠져서 길 잃고 헤맸거든.

지금은 화면 하나에 다 몰아넣고, IOS 시뮬레이터에서 테스트하거나 Xcode로 폰에 코드 올릴 때만 오케스트레이션 레이어 밖으로 나감.

요즘 내 세팅은 이래: 왼쪽엔 파일들, 중앙엔 터미널, 오른쪽엔 에이전트랑 워크트리, 그리고 하단엔 단축키.

6. 결국, AI를 관리할 AI가 필요했음.

이게 내가 요즘 개발하는 방식에서 가장 크게 바뀐 점임.

에이전트랑 워크트리를 여러 개 돌리기 시작하니까, 각 코딩 에이전트가 다음에 뭘 해야 할지 일일이 관리할 능력이 나한테 없다는 걸 깨달았거든.

그래서 AI 오케스트레이터를 위한 꽤 간단한 미션 스테이트먼트를 짰는데, 대충 이런 내용임:

• 내 대략적인 제품 아이디어를 가져와서 완벽한 엔지니어링 요구사항으로 바꿔라.
• 진짜 제품 관련 결정이 필요할 땐 나한테 물어봐라.
• 작업을 티켓으로 쪼개고 그 티켓들을 스프린트로 정리해라.
• 실제로 코드를 짜는 엔지니어링 에이전트들을 조율해라.
• 병렬로 처리할 수 있는 작업이랑 의존성이 있는 작업을 파악해라.
• 워크트리, 브랜치, 테스트, 리뷰, 머지 과정을 통해 개발 현황을 추적해라.
• 에이전트들이 내가 승인한 범위 안에서만 움직이게 해라.

그리고 제일 중요한 거, 내가 밑바닥 코드까지 다 이해하거나 파헤칠 필요 없게 상황을 계속 보고해라.

나한테 중요한 교훈은 특정 도구가 아니라, AI 에이전트가 실제 엔지니어링 업무를 점점 더 많이 맡게 된다면 그 과정을 관리해 줄 상위 무언가가 필요하다는 거였음.

나는 요즘 Scape 안에서 Argus를 써서 이걸 해결함.

이제 Argus한테 대충 제품 아이디어만 던져주면 됨. 그럼 얘가 나한테 후속 질문을 던지고, 아이디어를 완전한 제품 요청서로 만들고, 개발 일정 어디에 끼워 넣을지, 다른 작업이랑 뭐가 엮여 있는지 파악해서 코딩 에이전트들을 조율함. 결국 내가 테스트할 수 있는 단계까지 딱 만들어 놓는 거지.

이게 얘가 나를 위해 만든 티켓팅 시스템이랑 내가 작업하는 환경 스냅샷임. 티켓팅 시스템부터 요청서 내용까지 전부 다 내 AI가 만든 거임.

내 역할은 이제 제품 아이디어 내고, 나만 할 수 있는 결정 내리고, 만들어진 거 테스트하는 게 다임.

6개월 전까지만 해도 코딩이 뭔지도 몰랐던 사람치고는 진짜 미친 수준이지.

7. AI 슬롭(AI slop)은 진짜 심각함.

나도 엄청나게 만들어냈거든.

특히 초반에 말이야.

진짜 위험한 건, 밑바닥 코드는 점점 썩어가는데 앱은 계속 돌아간다는 거임.

그러다가 겉보기엔 간단해 보이는 기능 하나 추가해달라고 하면, 갑자기 모든 게 다 박살 나기 시작함.

나한테 가장 큰 도움이 됐던 건 코딩하기 전에 속도를 좀 늦추고, 요구사항을 더 제대로 정리하고, 작업물을 검토하고, 에이전트가 정해진 범위 안에서만 놀게 하고, 배운 내용을 문서화해서 다음 에이전트가 똑같은 삽질을 안 하게 만드는 거였어.

8. 코딩 말고 다른 것도 좀 해라.

이거 좀 웃기게 들릴 수도 있겠네.

처음 '바이브 코딩(vibe coding)' 시작했을 때, 눈앞에서 척척 만들어지는 거 보니까 진짜 장난 아니더라고. 도파민이 계속 뿜어져 나오니까 코딩밖에 안 보이더라.

밥 먹는 것도 잊어버리고 14시간씩 코딩만 붙잡고 있었어.

기능은 끝도 없이 추가하고 싶고.

아이디어는 계속 떠오르고.

고치고 싶은 건 왜 이렇게 많은지.

이제는 밖에도 좀 나가고, 운동도 하고, 컴퓨터랑 좀 떨어져서 시간도 보내려고 노력 중이야. 앱이 당장 내일 완성될 필요는 없다는 걸 받아들이기로 했지.

진도가 좀 느려졌을 수도 있는데, 오히려 그게 더 나은 것 같아.

나도 아직 배우는 중이야.

6개월 동안 바이브 코딩 좀 했다고 내가 갑자기 소프트웨어 엔지니어가 됐다고 말하는 건 절대 아니야.

근데 6개월 전이랑 지금 내가 뭘 만드는 방식을 비교해보면 진짜 격세지감이야.

다른 사람들은 점점 복잡해지는 바이브 코딩 프로젝트를 어떻게 관리하고 있는지 진짜 궁금해. 특히 에이전트 여러 개 돌리거나 워크트리(worktrees) 쓰는 사람들은 어떻게 하는지 말이야.

더 궁금한 거 있으면 알려줘.