올해 사이드 프로젝트 두 개를 AI랑 같이 만들고 있다. 신뢰도 기반 맛집 지도 서비스 Trustbite(트바), 그리고 3년 동안 방치해둔 내 블로그 RamBlog.

그런데 지금 나는 AI한테 코드를 직접 못 짜게 한다. AI 시대에 뭐 하는 짓인가 싶겠지만, 이렇게 된 데는 이 두 프로젝트를 시작하기 전의 여러모로 삽질이 있었다.

고쳐줘, 고쳐줘, 고쳐줘!!! 하 그냥 때려쳐라..

완전 바이브 코딩으로 사이드 프로젝트를 여러개 만들기도 했다. 시키면 나오니까 처음엔 신났다.
오, 되네? 혼자서도 뭐든 만들 수 있겠다 싶었다.

문제는 오류가 났을 때였다. 어디가 문제인지 내가 모르니까 할 수 있는 게 "고쳐줘" 뿐이었다. 고쳐줘. 아직 안 되는데 다시 고쳐줘. 또 고쳐줘. 그렇게 몇 바퀴를 돌다가 답답해서 결국 내가 코드를 열어봤는데, 문제가 어디인지 너무 빠르게 알게 됐다. AI한테 몇 번을 시켜도 못 잡던 걸 내 눈으로 보니 금방이었다. 너무 허무했다.

더 무서웠던 건 ai가 짠 그 코드가 전혀 이해되지 않는 순간이 왔을 때다. 내가 만든 프로젝트니까 내가 로직을 제일 잘 알고 싶은데, 정작 내 머릿속엔 이 프로젝트의 로직도 플로우도 명확하게 남아있지 않았다. 내 프로젝트인데, 내 레포인데, 이 서비스가 어떻게 굴러가는지 내가 설명을 못 한다.ㅎ..

트바에서도 반복한 실수

그래놓고 3월에 트바 프로젝트를 시작하면서 같은 실수를 또 했다.
회사에서는 디자이너가 잡아준 화면을 구현하면 됐지만 사이드 프로젝트엔 그런 게 없었다. 그래서 화면 디자인부터 바이브 코딩으로 예쁘게 프로토타입을 만들도록 시켰다.

하지만 기초 코드가 없는 상태에서 바이브 코딩을 돌리다 보니 코드가 엉망 그자체 였다. 프로토타입을 완성하고 나서 보니 화면은 그럴듯했지만 한 파일에 엄청나게 많은 것들이 파스타처럼 엉켜 들어있었다. 컴포넌트, 상태, 스타일, 데이터 로직이 한 덩어리로~~~!!

기능 요청도 마찬가지였다. 내가 원하는 방향이 있는데 AI는 자꾸 다른 방향으로 구현하거나 추가 판단을 해서 구현하는 일이 잦았다. 또는 내가 명시해주지 않으면 관련된 것이지만 고쳐주지 않는 일들이 많았다.

결국엔 내가 코드를 확인하고 원하는 방향으로 리팩토링하는 일이 빈번해졌다.

AI가 짜는 데 10분, 답답해서 내가 그걸 다시 고치는 데 몇 시간. 이게 반복되니까 현타가 왔다. 빠르게 만들려고 AI를 쓰는 건데, 나는 지금 AI가 싼 코드를 치우는 사람이 된 건가??
실제로 트바 레포의 커밋을 세어보면 Refactor: 커밋이 30건 이상이다. 커밋 4분의 1이 구조를 다시 잡는 일이었다는 뜻이다.(하하..)

문서부터 다시 시작

그래서 방식을 갈아엎었다. 목표는 두 가지였다. 이 프로젝트의 로직과 플로우가 내 머릿속에 명확하게 있을 것, 그리고 태스크 단위로 관리될 것. 그러려면 코드를 시키기 전에 문서가 먼저였다.

흐름은 이렇다. PRD → 로드맵 → 주차별 태스크 → 개발
기획서(PRD)를 먼저 정리하고, 거기서 로드맵을 뽑고, 로드맵을 주 단위 태스크로 쪼갠 다음에야 코드를 만진다.

docs/
├── PRD.md # 기획서 — 신뢰도 시스템, 화면 구조, MVP 로드맵
├── mvp-exclusions.md # 1차 MVP에서 뺄 것들
├── spec/ # 화면별 스펙 + API 계약
│ ├── home/
│ ├── restaurant/
│ └── auth/
└── plan/roadmap1/
├── ROADMAP.md # W0~W4 전체 로드맵
├── week-0.md ~ week-4.md # 주차별 태스크 체크리스트
└── week-3-issues.md # 작업 중 발견한 이슈 로그

로드맵에는 완료 기준과 화면별 현재 상태를 표로 박아뒀다.
"1차 MVP 9개 화면이 모두 실 백엔드 위에서 동작"처럼 끝나는 조건을 먼저 정하고, 매주 태스크가 끝나면 체크리스트에 [x]를 채운다. 체크리스트 갱신도 /check-plan이라는 커스텀 커맨드로 AI가 하게 만들었다.

이렇게 하니까 AI의 결과물이 확 달라졌다. 제일 크게 체감한 건 태스크를 잘게 쪼개 줄수록 AI가 훨씬 구체적으로 답한다는 거였다. 프롬프트 하나에 이것저것 뭉뚱그려 던지면 AI도 뭉뚱그린 답을 주는데, "이번 태스크는 이거 하나"로 범위를 좁혀주면 그 안에서 훨씬 정교하게 파고든다. 생각해보면 당연하다. 사람 개발자도 기획서 없이 "알아서 예쁘게 만들어줘"라고 하면 엉뚱한 걸 만드니까. 문서가 있으니 AI가 매번 같은 그림을 보고 일하고, 좁혀준 태스크 안에서 프론트 스펙을 기준으로 백엔드에 보낼 변경요청 문서까지 알아서 뽑아줬다.

AI한테 코드 뺏기

구조 문제는 문서로 잡았는데, 더 근본적인 문제가 남아 있었다. 코드를 AI가 다 짜면 내가 배우는 게 없다는 것이었다. 사이드 프로젝트를 하는 이유의 절반은 학습인데, 완성된 코드를 받아 읽기만 하는 건 남의 코드 리뷰지 내 성장이 아니라고 생각했다.

AI를 완전히 버릴수는 없었던게, AI랑 태스크를 진행하다 보면 내가 모르던 새로운 방식이나 더 최적화된 방식을 제안해주는 경우가 있기 때문이었다. 하지만 AI가 그걸 그냥 구현해버리면 "오 좋네" 하고 지나가게 된다. 새로운 것일수록 내 손으로 직접 짜보는게 체득하기 더 좋지 않을까 생각했다.

그래서 좀 이상한 규칙을 만들었다ㅋㅋ AI한테서 코드 짜는 일을 뺏어온 거다. 두 프로젝트의 AI 지침 파일에는 이런 규칙이 박혀 있다.

모든 task에 적용. Claude는 코드를 직접 작성하지 않는다. 사용자가 순서대로 모든 코드를 작성하도록 유도한다.

이름은 Learn by Doing.

task 하나를 시작하면 AI가 그걸 2~5개 단계로 쪼개서 순서와 이유를 설명하고, 한 번에 한 단계씩 Context / Your Task / Guidance 형식으로 팁을 주고 나한테 요청한다.
코드는 내가 짠다. 내가 제출하면 AI가 검토하고 인사이트를 한 줄 얹은 다음 다음 단계를 준다. TODO(human) 플레이스홀더조차 AI가 못 쓰게 했다. 파일 생성, 타입 정의, import 한 줄까지 전부 내 손으로. AI가 마치 과외 선생이 된거다.

역할이 뒤집혔다. AI가 코딩하고 내가 리뷰하는 게 아니라, 내가 코딩하고 AI가 리뷰한다. 속도는 당연히 느려졌다. 대신 이제 내 레포에 있는 파일들을 내가 직접 하나하나 건드릴 수 있게 되었다.

물론 탈출구도 만들어놨다. css수정이나 단순 api연결과 같은 반복작업은 내가 작성하면 답답한 마음이 싹 들어서, /auto라는 커맨드를 치면 그 task에 한해 AI가 직접 구현한다. 하지만 딱! 일회성이고, 다음 task부터는 자동으로 Learn by Doing으로 복귀한다.

가드레일 쌓기

내가 코드를 짜게 되니 이번엔 반대 방향의 안전망이 필요해졌다. 내 코드와 AI의 가이드가 프로젝트 컨벤션에서 벗어나지 않게 잡아주는 장치들. 이걸 하나씩 쌓았다.

반복 작업은 커스텀 스킬로. 프로젝트 컨벤션에 정확히 맞춰 코드를 뽑아야 하는 반복 작업 4가지를 스킬로 만들었다. 백엔드 엔드포인트를 주면 API 함수와 React Query 훅을 컨벤션대로 만들어주는 register-api-hook, Zustand 스토어 패턴, Storybook 스토리 자동 생성, 그리고 디자인 감각이 없는 나를 위한 ui-ux-expert(토스·당근 스타일 기준으로 UI를 잡고 작업 끝날 때마다 자체 UX 비평을 내놓는다)(디자인을 어떻게 할지 몰라서 제일 맘에 드는 유저 친화적인 토스·당근 스타일로 디자인 컨벤션을 잡았다.ㅎㅎ)

리뷰는 전용 서브에이전트로. frontend-code-reviewer라는 리뷰 에이전트를 만들어서 기능/아키텍처/컨벤션/스타일/UX/타입/성능 7개 카테고리로 리뷰를 돌린다. 재밌는 건 이 리뷰어한테 메모리를 붙여놨다는 건데, 내가 반복하는 실수를 파일로 축적한다. 실제 메모리 파일에 아래와 같은게 쌓여있다.

북마크 버튼 tap target: w-7 h-7 (28px) 반복 위반 — 44px 이상 필수

내가 터치 영역 28px짜리 버튼을 자꾸 만드니까 리뷰어가 그걸 기억해뒀다가 볼 때마다 잡아낸다. 사수를 경험해본적은 없지만 이제 AI가 나의 사수가 된게 아닐까?..

검증은 훅으로 강제. 세션 중에 수정된 .ts/.tsx 파일을 추적했다가, AI가 작업을 끝내려는 시점에 tsc --noEmit을 자동으로 돌리는 훅을 달았다. 타입 에러가 있으면 종료를 막고(block) AI가 스스로 고치게 한다. "빌드 확인했어?"를 사람이 물어볼 필요가 없어졌다.

3년 방치한 블로그에도 적용해봤다

트바에서 이 방식이 자리 잡고 나서, 5월에 RamBlog를 꺼냈다. 2023년 신입 때 만들고 3년을 방치한 내 블로그다. 블로그로서 잘 사용했지만 코드를 업데이트하고 싶은 마음이 생겨서 열어봤다. 3년 전 코드라 보안이며 SEO며 손볼 게 산더미였는데, 이번엔 처음부터 정비된 워크플로우로 들어갔다.

똑같이 진단 → 로드맵(30일 플랜) → 주차별 태스크로 문서를 깔고, Learn by Doing으로 진행했다. 여기선 커스텀 커맨드를 하나 더 만들었는데, /next를 치면 로드맵에서 다음 미완료 Day를 찾아서 알아서 착수한다. "오늘 뭐 하지"를 고민할 필요 없이 세션을 열고 /next 한 번이면 이어서 진행된다.

추가로 만든 규칙중 제일 마음에 드는 건 learning-notes.md다. Learn by Doing으로 진행하다 보면 ai가 ~이렇게 해봐 하면 "그게 뭔디?" 하는 개념 질문을 많이 하게 되는데("metadataBase는 왜 추가해야 하는 거야?", "Next 16에서는 알아서 캐시되지 않아?"), 이 Q&A를 Day가 끝날 때마다 서브에이전트가 자동으로 파일에 정리한다. 예를 들면 이런 식이다.

Q. next16에서는 페이지 내부에서 호출한 건 알아서 캐시되지 않아?

아니다. Next.js의 자동 dedup(Request Memoization)은 Next가 패치한 전역 Web fetch()를 직접 호출했을 때만 동작한다. getPostDetail은 내부적으로 @sanity/client의 client.fetch(...)를 쓰는데, 이건 이름만 비슷할 뿐 Web fetch()가 아니라서 자동 dedup에서 빠진다. 그래서 이 프로젝트는 명시적으로 React cache()를 쓴다.

바이브 코딩 시절엔 코드가 지나가면 아무것도 남지 않았는데, 지금은 개발이 끝나면 그날 배운 게 자연스럽게 문서로 남는다. 이 노트에 적힌건 시간날때 짬짬이 보고 공부하려고 하고 있다.(이전에 이해했더라도 금방 까먹기 때문에..)

그래서 지금의 워크플로우

결과적으로 정리해보면 아래와 같이 굴러간다.

1. PRD → 로드맵 → 주차별 태스크 문서를 AI와 함께 먼저 만든다
2. 태스크는 /next(또는 로드맵 규칙)로 하나씩 착수, task 1개 단위로만 진행하고 정지
3. 코드는 Learn by Doing으로 내가 직접 작성, 급하거나 단순 노동일 경우 /auto command 로 일회성 위임
4. 반복 작업은 커스텀 스킬, 리뷰는 메모리 달린 리뷰 에이전트, 검증은 tsc 훅으로 자동화
5. 배운 개념은 learning-notes에, 이슈는 issues 파일에, 진행 상황은 체크리스트에 남긴다

얼마 전에 teo님의 글을 읽다가 공감을 많이 했다. AI에게 코딩을 맡기니 요구사항 정리, 문서화, 검수, 구조 정리 같은 코딩 외의 개발이 전면으로 드러난다는 이야기. 특히 프론트엔드 개발자의 역할이 "AI가 일관성 있게 수렴할 수 있는 환경 만들기"가 된다는 대목이 인상 깊었다. 내가 몇 달 동안 삽질하면서 쌓은 게 정확히 그거였다. PRD도, 로드맵도, 지침 파일도, 스킬도, 리뷰어 메모리도 전부 AI가 매번 같은 방향으로 수렴하게 만드는 환경이었다.

돌이켜보면 바이브 코딩이 실패했던 건 AI가 못해서가 아니라, 수렴할 기준을 내가 안 줬기 때문이었다. 기준 없이 시키면 매번 다른 방향으로 발산하고, 그걸 치우는 건 결국 나였다.

AI한테 코드를 뺏어온 게 역설적으로 잘한 선택이었다는 생각이 든다. 속도를 조금 내주는 대신 내 프로젝트의 모든 코드를 내가 설명할 수 있게 됐고, 배운 게 문서로 쌓인다.

사실 이 방식이 맞는건지는 잘 모르겠지만 ai가 모든것을 다 해주는 시대에 바보가 된것만 같은 나에게 개발자로서 그나마 위안을 주는 방식이 된 것 같아 당분간은 이렇게 내 뇌에 지식을 ai와 함께 쌓으면서 진행하려고 한다.

REFERENCE

• AI 시대의 개발자 역할 — 이 글의 마지막 섹션에서 다룬 "코딩 외의 개발", "수렴 환경 만들기" 논지의 원문
• Claude Code 공식 문서 — Skills — 커스텀 스킬 만드는 법
• Claude Code 공식 문서 — Hooks — tsc 자동 검증 훅 같은 걸 만들 때 참고
• Next.js 공식 문서 — Caching and Revalidating — learning-notes에 인용한 fetch 자동 memoization과 React cache() dedup의 근거