바퀴를 다시 만들지 말자: 바이브코딩 기획 2단계

이 글에서 알 수 있는 것

• 바이브코딩도 프롬프트를 치기 전에 기획과 리서칭, 두 단계를 먼저 거친다는 것
• 무거운 기획서 없이 바이브코딩 요구사항을 가볍게 정리하는 법
• 바이브코딩 리서칭이 정확히 뭘 찾는 일인지, 그리고 어디서 찾는지
• 이게 AI 시대에 새로 생긴 습관이 아니라 원래 개발자들이 하던 일이라는 근거

추상적으로 “기획이 중요하다”로 끝내지 않을 것이다. 실제로 뭘 적고, 어디서 찾아야 하는지까지 쓴다.

1탄에서 바이브코딩은 코딩을 안 하는 게 아니라 맥락을 관리하는 일이라고 정리했다. 그런데 맥락 관리는 프롬프트를 치는 순간부터 시작되지 않는다. 프롬프트 치기 전에 이미 절반이 정해진다.

지난주에 만들 걸 정하지 않고 바로 프롬프트부터 친 적이 있다. 결과물은 매번 방향이 달랐다. 그 뒤로 뭘 만들지, 뭘 참고할지부터 정리하고 시작하는 습관이 붙었다.

1. 바이브코딩도 순서가 있다, 프롬프트부터 치면 안 되는 이유

바이브코딩은 순서 없이 아무 말이나 던져도 되는 작업이 아니다. AI 코딩 도구를 만든 회사도 같은 이야기를 한다.

Claude Code(앤스로픽의 AI 코딩 도구) 공식 문서는 탐색, 계획, 구현, 커밋 순서를 권장한다. 문서에는 이렇게 쓰여 있다. “클로드가 곧장 코드부터 짜게 두면, 엉뚱한 문제를 푸는 코드가 나올 수 있다.”

그래서 왜 곧장 코드부터 짜면 문제가 생길까? AI는 내가 뭘 원하는지 모른 채로 가장 그럴듯한 답부터 만든다. 방향이 틀리면 그 위에 계속 수정을 쌓게 된다.

그래서 이 글은 프롬프트를 치기 전 두 단계를 정리한다. 1단계는 기획, 2단계는 리서칭이다.

2. 1단계 기획, 바이브코딩 요구사항 정리는 어디까지 하면 될까

바이브코딩 기획은 회사에서 쓰는 기획서(PRD, 요구사항 정의서)만큼 무거울 필요가 없다. 개인 프로젝트라면 표 하나로 충분하다.

기획 항목	정리 예시
목적	할 일을 추가·완료·삭제하는 체크리스트
핵심 기능	추가, 완료 체크, 삭제, 3개만
안 할 것	로그인, 저장, 알림은 이번엔 빼기
완료 기준	브라우저에서 열어 세 동작이 다 되면 끝

Claude Code 공식 문서에는 클로드가 먼저 인터뷰하듯 질문하는 방식도 나온다. 기술적인 접근, 화면 흐름, 예외 상황을 클로드가 먼저 묻고, 답을 스펙(SPEC.md, 요구사항을 정리한 파일) 파일에 저장한 뒤에야 코드를 짠다. 좋은 스펙은 관련 파일과 안 할 일을 명시하고, 끝에는 확인 방법까지 적어둔다고 안내한다.

이 표 하나, 또는 이 인터뷰 하나만 거쳐도 방향이 훨씬 또렷해진다.

3. 2단계 리서칭, 바이브코딩 리서칭은 결국 무엇을 찾는 일일까

기획을 마쳤다면 다음은 리서칭이다. 그런데 리서칭이 정확히 뭘 하는 일인지는 막상 설명하려면 헷갈리기 쉽다.

“리서칭은 결국 기획한 요구사항을 잘 구현하기 위해, 이미 잘 만들어진 것을 찾는 일이다.”

체크리스트 앱을 만들기로 했다면, 체크리스트 앱을 처음부터 짜는 대신 이미 잘 만들어진 체크리스트 코드나 구조를 먼저 찾아본다는 뜻이다. 없는 걸 새로 짓기보다, 있는 걸 빌려 쓰는 쪽이 대체로 빠르고 안전하다.

Claude Code 공식 문서에 나온 예시 프롬프트도 같은 방향이다. “우리 인증 시스템이 토큰 갱신을 어떻게 처리하는지, 재사용할 만한 OAuth 유틸리티가 이미 있는지 조사해줘.” 새로 짜기 전에 이미 있는 것부터 확인하라는 지시다.

같은 문서는 내 프로젝트 안쪽도 리서칭 대상으로 본다. “홈 화면에 이미 있는 위젯들이 어떻게 만들어져 있는지 보고, 이미 쓰고 있는 라이브러리 밖에서는 새로 가져오지 말라”는 예시도 있다. 바깥세상뿐 아니라 내가 이미 만든 코드도 리서칭 대상이라는 뜻이다.

4. 리서칭은 AI 시대에 생긴 습관이 아니다

여기서 하나 짚고 싶은 게 있다. 이 리서칭 습관이 AI 코딩 도구 때문에 새로 생긴 건 아니라는 점이다.

구글의 검색 알고리즘을 만든 것으로 유명한 피터 노빅은 2001년에 쓴 에세이 “프로그래밍을 독학하는 10년”에서 이렇게 적었다. “다른 프로그래머와 대화하고, 다른 사람의 프로그램을 읽어라. 이건 어떤 책이나 강의보다 중요하다.”

같은 글에는 “다른 프로그래머 밑에서 프로젝트를 해보고, 남이 짠 프로그램을 이해해보라”는 조언도 있다.

25년 전 조언과 지금 AI 코딩 도구의 공식 문서가 같은 말을 한다. 새로 짜기 전에 이미 있는 걸 먼저 보라는 원칙은 바뀌지 않았다. 바뀐 건 그 원칙을 도구 사용법 안에 명시적으로 넣었다는 점뿐인 듯싶다.

5. 리서칭 채널 4곳, 어디서 이미 잘 만든 것을 찾을까

그럼 실제로 어디서 찾아야 할까. 리서칭할 때 자주 쓰는 채널을 네 곳으로 좁혀 정리했다.

1. GitHub: 검색 연산자로 걸러 찾는다. stars:>=500으로 별 500개 이상, language:PYTHON으로 언어를 지정할 수 있다. GitHub 공식 문서는 토픽(주제별 저장소 모음) 페이지를 이렇게 설명한다. “토픽을 이용하면 특정 주제의 저장소를 탐색하고, 기여할 프로젝트를 찾고, 문제 해결책을 새로 발견할 수 있다.” “어썸 리스트(awesome-list, 한 주제를 잘 정리한 링크 모음)”라는 이름은 2012년 제이미 요크가 만든 awesome-php 저장소에서 시작됐고, 지금은 거의 모든 분야에 awesome-<주제> 형태로 퍼져 있다. 뼈대만 잡힌 시작 코드가 필요하면 create-react-app처럼 create-<프레임워크> 이름을 가진 스캐폴드(뼈대 생성) 도구를 찾아본다.
2. YouTube: 실제로 실행하는 화면이 있는 영상을 우선 본다. 글만으로는 안 보이는 실행 순서가 영상엔 있다.
3. Google: 공식 문서와 에러 메시지 그대로 검색해 1차 후보를 넓히는 용도로 쓴다.
4. X(트위터)와 Threads: 만드는 중인 프로젝트를 공개적으로 공유하는 문화가 있다. 이런 방식을 빌드 인 퍼블릭(build in public)이라 부르고, #buildinpublic 태그나 Indie Hackers 같은 커뮤니티에서 다른 사람이 고른 기술 스택과 구조를 참고할 수 있다.

리서칭 단계에서 브라우저를 직접 열어 찾아보게 시키고 싶다면, 클로드 MCP 추천 글에서 다룬 Playwright MCP(브라우저를 직접 여는 도구)를 붙여두는 방법도 있다.

“리서칭은 결국 기획한 요구사항을 잘 구현하기 위해, 이미 잘 만들어진 것을 찾는 일이다.” 어느 채널에서 찾든 목적은 같다.

6. 자주 묻는 질문

리서칭할 시간에 그냥 AI한테 만들라고 하면 안 되나요?

될 때도 있다. 다만 곧장 코드부터 짜면 방향이 틀린 채로 진행될 위험이 있다.

Claude Code 공식 문서가 플랜 모드(plan mode, 코드를 고치지 않고 탐색만 하는 모드)를 따로 둔 이유가 여기에 있다. 작은 실험이면 바로 시켜도 되지만, 며칠 쓸 결과물이면 탐색부터 시키는 편이 낫다.

이미 있는 걸 그대로 가져다 쓰면 표절 아닌가요?

목적에 따라 다르다. 코딩 호러(Coding Horror) 블로그를 쓴 제프 앳우드는 “바퀴를 다시 만들지 마라, 바퀴에 대해 더 배우고 싶은 게 아니라면”이라는 글에서 이 지점을 짚었다.

시간을 아끼는 게 목적이면 이미 있는 걸 빌려 쓰는 편이 낫다. 배우는 게 목적이면 직접 만들어보는 것도 나름의 가치가 있다는 이야기다. 오픈소스 코드를 그대로 쓸 때는 라이선스(사용 조건)만 확인하면 된다.

빌드 인 퍼블릭은 꼭 해야 하나요?

아니다. 안 해도 상관없다. 다만 다른 사람이 공개한 진행 과정을 보는 것 자체가 리서칭 채널 중 하나가 될 수 있어서 5장에 같이 정리했다.

정리

• 바이브코딩도 프롬프트 치기 전에 기획과 리서칭, 두 단계를 먼저 거친다
• 기획은 표 하나로 목적, 핵심 기능, 안 할 것, 완료 기준만 정리해도 충분하다
• “리서칭은 결국 기획한 요구사항을 잘 구현하기 위해, 이미 잘 만들어진 것을 찾는 일이다”
• 이 습관은 AI 시대에 생긴 게 아니라 노빅의 2001년 조언에도 이미 있던 원칙이다
• GitHub, YouTube, Google, X·Threads 네 채널을 돌아가며 후보부터 넓혀본다

5분짜리 실행 과제 하나만 남긴다. 다음에 뭔가 만들기 전에 GitHub에서 awesome- 뒤에 주제를 붙여 검색해보면 좋다. 이미 정리된 후보 3개만 골라봐도 시작이 훨씬 쉬워진다.

기획과 리서칭까지 끝났다면 다음은 실제로 만들어볼 차례다. 바이브코딩 첫 프로젝트에서 체크리스트 앱을 직접 만드는 과정을 다룬다. 여러분은 프롬프트 치기 전에 어디까지 정리하고 시작하나요. 겪은 시행착오가 있으면 댓글로 알려달라.