Show GN: 클로드코드를 좀 더 잘쓰는 방법에 대해서 제 나름의 방식을 공유하고싶습니다.
(wikidocs.net)문제
바이브코딩으로 프로젝트를 시작하면 처음 몇 시간은 신세계입니다. 프롬프트 던지면 코드가 나오고, 뭔가 돌아가는 것 같고, "나 이거 진짜 만드는 건가?" 싶은 순간이 옵니다.
그리고 에러가 나기 시작합니다.
고쳐달라고 하면 다른 데가 깨지고, 30분 지나면 AI가 앞에서 한 말을 까먹고, 1시간 지나면 나도 지금 뭘 만들고 있었는지 헷갈립니다. 다음 날 다시 열면 백지 상태. 결국 같은 자리를 맴돕니다.
여러 프로젝트를 동시에 진행하면 더 심합니다. 월요일에 하던 걸 목요일에 이어하려면 컨텍스트를 처음부터 다시 세팅해야 합니다.
원인
병목이 코드에 있는 게 아니었습니다. 기억에 있었습니다.
AI는 세션이 끊기면 까먹고, 나도 며칠 지나면 까먹습니다. 그런데 아무도 기록하지 않으니 프로젝트가 계속 초기화됩니다.
시도한 방법
Obsidian을 프로젝트의 장기 기억 저장소로 쓰기 시작했습니다.
- Obsidian — 기획, 설계, 세션 로그, 에러 기록을 전부 마크다운으로 관리
- Claude Desktop + MCP — Obsidian 노트를 직접 읽고 설계를 논의하는 "지휘자" 역할
- Claude Code + MCP — 설계가 끝난 작업을 실제로 구현하는 "실행자" 역할
Claude Desktop의 컨텍스트 유실 문제는 날짜_handoff.md 파일로 세션 간 인수인계를 기록해서 해결했습니다. 새 세션을 열 때 이 파일만 읽으면 맥락이 바로 복구됩니다.
핵심은 "기록 → 설계 → 구현 → 기록" 사이클을 반복하는 것이었습니다.
결과
이전에 토이 프로젝트 시작하고 3일 만에 폴더 삭제하기를 반복했는데, 이 방식으로 바꾼 뒤 완성 못 했던 프로젝트들이 하나씩 1차 완성 → 배포 → 검수 → 수정의 사이클로 돌아가기 시작했습니다. 현재 10개 이상의 프로젝트를 Obsidian 캔버스로 동시 관리하고 있습니다.
최근 Claude Code에 Auto Memory 기능이 추가됐는데, 이건 AI가 AI를 위해 쓰는 메모이고, 위 방식은 인간이 인간을 위해 쓰는 기록입니다. 서로 보완 관계라고 생각합니다.
정리
이 워크플로우를 정리해서 위키독스에 책으로 공개했습니다. 전문 무료입니다.
"바이브코딩은 왜 실패하는가 — AI 협업 가이드북" https://wikidocs.net/book/19307
프롤로그~Ch.22 + 부록까지 있고, 피드백은 각 페이지 댓글로 남겨주시면 바로 반영하겠습니다. 따끔한 한마디도 환영합니다.
커서를 쓰는데 그런 경우(까먹는 경우)를 겪지 않아서 클로드로 이런 경우를 가끔 읽으면 의아합니다. 품질이 낮거나 정확히 명시 하지 않아서 겪는 경우는 있어도 까먹는 경우는 없었고, 다른곳에서 에러가 나서 곤란한 경우는 커서 제품의 초기때는 몇번 겪었지만, 지금은 그런 경우가 없었습니다. 제 프로젝트가 충분히 크지 않아서 그런걸까요?
이런 방식으로 합니다:
- 대략적인 구상, 방법, 비슷한 방식이 있다면 그것도을 명시해서 10-20줄 짜리 문서를 씁니다.
- 그것을 읽고 구상과 아케텍쳐, 테스트, 플랜을 써서 자세히 문서로 쓰라고 합니다. 내게 질문 할것 있으면 하라고 합니다. (그럼 곧잘 질문을 번호를 고르는 방식으로 제게 물어봅니다.) 그리고 거기에 대해 의논하며 완성합니다. 따로 Gemini와 대화를 해서 더 많은 조사를 하고 거기에 대해 같이 대화를 합니다.
- 그리고 완성된 문서를 리뷰하며 다시 대화 하면서 조금씩 고쳐 나가고, 그리고는 만들라고 명령합니다. 만들면서 환성된 부분은 완성했다 표시하며 그 문서를 업데이트 하면서 진해 하라고 합니다. 그리고 오래 걸릴 만큼 크거나 복잡한것은 커서룰에 매일 어떤것을 했는지 다른 문서에 기록하라고 합니다.
문서가 프로젝트 내에 있기에 따로 특별히 관리 할 필요는 없습니다. 그리고 커서는 작업을 계속 하지 않습니다. 아무리 끝까지 하라고 해도 계속 중간에 멈춰서 (이게 이상한 루프를 빠지지 않게 하는 안전장치라고는 하는데, 제게 선택권이 없는게 불만입니다), 대화를 강제하게 만듭니다. 그게 도움이 되긴 합니다. 몇시간 후에 보았을때 전혀 엉뚱하게 만들어질 여지를 주지 않게 되는 면도 있습니다.
하나의 IDE내에서 다 처리하기 때문에 다른 서비스를 덧붙히지 않아도 됩니다. 클로드는 API로 LLM기능만 써봐서 코딩은 많은 사람들이 좋다고 하는데 어떤지 모르겠습니다 -- 단지 이런 까먹거나 에러가 난다는 글을 가끔 보면, 프로젝트 사이즈가 작아서 그런건가... 싶기도 하군요.
결론적으론, 회사에서 프로젝트와 팀들을 관리할때 처럼 진행합니다 - 사람들과 진행 할때와 마찬가지 진행 방식인, 문서화및 기록, 대화, 결정...새로운 워크플로우도 아닙니다. 그래서 클로드로 어떤 워크플로우로 해서 '완전자동'으로 했다는 방식이 무척 궁금하고, 완정자동은 아니더라도 잦은 "미팅" (사람으로 구성된 팀과도 잦은 미팅을 줄이려 노력하지요)을 어떻게 줄여 볼까 고민입니다.