리서치: 코드를 쓰기 전에 먼저 코드베이스를 깊이 읽어야 합니다
클로드 코드 같은 AI 코딩 도구를 쓸 때 많은 사람이 가장 먼저 하는 실수가 있습니다. 하고 싶은 기능을 바로 프롬프트에 적고 곧장 구현으로 들어가는 것입니다. 처음에는 이 방식이 빨라 보입니다. 간단한 화면 하나, 버튼 하나, 짧은 기능 하나 정도는 금방 나오는 것처럼 느껴집니다. 그런데 기능이 조금만 복잡해지면 그때부터 문제가 시작됩니다. 앞에서 만든 구조가 뒤에서 발목을 잡고, 새로운 기능을 붙일수록 기존 코드와 충돌이 나고, 결국 전체를 다시 뜯어고쳐야 하는 상황이 옵니다. 저도 처음에는 그렇게 했습니다. 눈앞의 결과물이 빨리 나오는 게 좋아 보여서 기획 없이 바로 코딩을 시작했는데, 나중에는 이미 만든 것들을 통째로 뒤집는 일이 반복됐습니다. 그 원인은 단순했습니다. 실행은 했지만, 리서치를 하지 않았기 때문입니다.
바이브 코딩의 출발점은 프롬프트가 아니라 리서치입니다. AI에게 바로 만들라고 시키기 전에 먼저 현재 코드베이스를 충분히 이해하게 해야 합니다. 어떤 폴더가 핵심인지, 데이터 흐름은 어떻게 이어지는지, 이미 존재하는 컴포넌트와 함수는 무엇인지, 어디를 건드리면 영향 범위가 커지는지부터 파악해야 합니다. 이 단계에서 중요한 것은 AI가 정말 깊이 읽도록 지시하는 것입니다. 그냥 “분석해 줘”라고 하면 대충 훑고 지나갈 가능성이 큽니다. 그래서 “깊이 읽어라”, “매우 상세히 정리해라”, “세부 사항까지 분석해라” 같은 표현을 분명하게 넣어야 합니다. 그렇지 않으면 함수 이름 몇 개, 파일 구조 몇 줄 정도만 요약하고 끝나는 경우가 많습니다. 실제 작업에서는 이 차이가 매우 큽니다. 얕은 이해 위에서 시작한 구현은 결국 중간에 방향을 틀게 되지만, 충분한 리서치 위에서 시작한 구현은 훨씬 안정적으로 이어집니다. 그래서 리서치 결과도 반드시 별도의 마크다운 문서로 남겨야 합니다. 채팅창 속 답변은 흘러가지만, 파일로 정리된 리서치는 이후 계획과 구현의 기준점이 됩니다.
또 하나 중요한 점은 리서치를 단순 요약으로 끝내면 안 된다는 것입니다. “이 폴더에는 컴포넌트가 있다”, “이 파일에는 API 호출이 있다” 정도로 끝나면 실제 개발에 큰 도움이 되지 않습니다. 어떤 파일이 진짜 핵심인지, 어떤 함수가 여러 군데에서 재사용되는지, 어디가 수정에 민감한 부분인지까지 확인해야 합니다. 결국 리서치는 구현 속도를 늦추는 단계가 아니라, 나중에 되돌리는 비용을 줄이는 단계입니다. 처음에 이 시간을 아끼면 나중에 훨씬 큰 시간을 잃게 됩니다. 바이브 코딩에서 흔히 말하는 “AI가 똑똑하니까 알아서 해주겠지”라는 기대가 가장 위험한 이유도 여기에 있습니다. AI는 맥락을 잘 정리해 주면 훨씬 강력해지지만, 맥락 없이 던져진 요청에는 그럴듯한 추측으로 대응할 가능성이 큽니다. 그래서 리서치는 선택이 아니라 필수입니다. 코드를 쓰기 전에 먼저 읽고, 읽은 내용을 문서로 남기고, 그 문서를 기준으로 다음 단계로 넘어가는 습관이 있어야 프로젝트가 커져도 덜 흔들립니다.
계획: 채팅창이 아니라 수정 가능한 문서로 큰 그림을 먼저 확정해야 합니다
리서치가 끝났다면 그다음은 바로 구현이 아니라 계획입니다. 여기서도 많은 사람이 서두릅니다. “이제 구조를 이해했으니 만들어줘”라고 곧장 넘어가는데, 바로 이 지점에서 코드가 다시 꼬이기 시작합니다. 리서치가 현재 상태를 이해하는 단계였다면, 계획은 앞으로 무엇을 어떻게 바꿀지 정하는 단계입니다. 이때 중요한 것은 계획을 채팅으로만 주고받지 않는 것입니다. 채팅창 안에 떠 있는 계획은 수정이 불편하고, 세션이 길어지면 찾기 어렵고, 끊기면 맥락이 흐려집니다. 그래서 계획 역시 별도의 마크다운 파일로 작성하는 것이 좋습니다. 에디터에서 직접 열 수 있고, 인라인으로 수정할 수 있고, 프로젝트 산출물처럼 남기에도 좋기 때문입니다.
좋은 계획 문서에는 단순한 할 일 목록만 있으면 안 됩니다. 접근 방식, 변경 이유, 수정될 파일 경로, 필요한 코드 스니펫, 예상되는 부작용, 지켜야 할 제약 조건까지 담겨야 합니다. 예를 들어 어떤 컴포넌트를 수정할지, 어떤 상태 관리 방식을 유지할지, 어떤 함수 시그니처는 절대 바꾸면 안 되는지까지 미리 적어두는 식입니다. 이렇게 해야 구현 단계에서 AI가 멋대로 해석할 여지가 줄어듭니다. 그리고 이 문서를 사람이 직접 검토하면서 주석을 다는 과정이 핵심입니다. “이건 새로 만들지 말고 기존 구조를 재사용해”, “이 필드는 여기 말고 리스트 레벨에 둬”, “이 방식은 패치가 아니라 구조 변경이라 다시 설계해야 해” 같은 메모를 해당 위치에 직접 남기는 것입니다. 이 과정이 있어야 사람이 주도권을 잃지 않습니다.
저는 예전에 챗GPT로 대략적인 기획만 잡고 바로 개발을 시작했다가, 실제 작업 중에 기능이 계속 추가되는 바람에 구조가 복잡하게 꼬인 적이 많았습니다. 특히 페이지가 큰 경우에는 나중에 붙일 기능이 너무 많아져서 처음 만든 기반 자체가 부담이 됩니다. 그래서 처음부터 큰 그림을 잘게 나눠 여러 개의 작은 프로젝트 단위로 쪼개는 계획이 필요합니다. 무엇을 지금 만들고, 무엇을 나중으로 미루고, 어떤 선은 넘지 않을지 미리 정해야 합니다. 계획이 명확하지 않으면 AI는 계속 새 기능을 얹으려 하고, 사용자는 그 결과를 보며 또 수정 요청을 하게 되고, 그렇게 프로젝트는 점점 무거워집니다.
여기서 중요한 것이 바로 문서를 주고받는 반복 과정입니다. 계획서를 한 번 만들고 끝내는 것이 아니라, 사람이 주석을 달고 AI가 그 메모를 반영해 다시 문서를 고치도록 해야 합니다. 이때도 “모든 메모를 반영하고 문서를 업데이트해. 아직 구현하지 마”처럼 구현 금지를 분명히 적어주는 것이 중요합니다. 그렇지 않으면 AI가 혼자 판단해서 바로 코딩을 시작하는 경우가 있습니다. 이 반복은 단순한 수정 작업이 아니라, 사람과 AI가 같은 문서를 공유하면서 설계를 계속 다듬는 과정입니다. 결국 계획은 단순한 준비 단계가 아니라 바이브 코딩 전체를 안정시키는 중심축입니다. 구현 능력보다 먼저 필요한 것은, 구현 전에 결정할 수 있는 것들을 최대한 문서로 확정하는 습관입니다.
구현: 계획이 끝난 뒤에만 실행하고, 잘못되면 패치보다 리셋이 낫습니다
계획이 충분히 다듬어졌다면 그때부터 구현을 시작하면 됩니다. 이 시점의 구현은 아이디어를 탐색하는 과정이 아니라, 이미 정해진 방향을 실행하는 과정이어야 합니다. 그래서 구현 지시도 가능한 한 구체적일수록 좋습니다. 예를 들어 “계획 문서 기준으로 전부 구현해”, “끝난 항목은 문서에 완료 표시해”, “모든 작업이 끝날 때까지 멈추지 마”, “애니 타입은 쓰지 마”처럼 명확하게 범위와 규칙을 정해줘야 합니다. 여기서 중요한 것은, 구현 단계에 와서 AI가 다시 아키텍처를 결정하게 두지 않는 것입니다. 그런 판단은 이미 계획 단계에서 끝났어야 합니다. 구현은 말 그대로 손을 움직이는 단계가 되어야 코드가 덜 흔들립니다.
구현이 시작되면 사람의 역할도 바뀝니다. 이때는 공동 설계자라기보다 감독자에 가깝습니다. 중간 결과를 보면서 “이 함수 빠졌어”, “이 설정은 여기 말고 어드민 쪽으로 옮겨”, “여기 간격이 어색해”, “이 버튼은 더 넓어야 해”처럼 짧고 명확하게 피드백을 주면 됩니다. 특히 프론트엔드는 브라우저에서 바로 확인하면서 수정 지시를 주면 효율이 좋습니다. 스크린숏을 첨부하면 더 정확해집니다. 즉, 구현 단계에서는 긴 설명보다 짧고 구체적인 수정 지시가 훨씬 효과적입니다. 사람이 이미 큰 방향을 정했기 때문에, 이제는 세부 오차를 빠르게 조정하는 식으로 가는 것이 맞습니다.
다만 이 과정에서 반드시 기억해야 할 원칙이 하나 있습니다. 잘못된 방향으로 가는 코드 위에 계속 덧붙이지 말아야 한다는 점입니다. 많은 사람이 이미 만들어둔 것이 아까워서 거기에 패치를 계속 올리는데, 그러면 구조는 점점 더 취약해집니다. 오히려 깃으로 되돌리고 범위를 다시 정하는 편이 훨씬 낫습니다. 잘못 쌓인 구조를 억지로 살리는 것보다 깨끗하게 리셋한 뒤 다시 가는 편이 결과도 좋고 시간도 덜 듭니다. 실제로 작업을 하다 보면 “여기까지 왔으니 그냥 이어가자”는 유혹이 큽니다. 하지만 잘못된 토대 위에 계속 기능을 얹는 것은 결국 더 큰 수정 비용으로 돌아옵니다.
결국 바이브 코딩의 핵심은 AI에게 코드를 잘 쓰게 만드는 데 있지 않습니다. 무엇을 쓰게 할지 사람이 먼저 분명히 정하는 데 있습니다. 좋은 것만 취하고, 필요 없는 것은 과감히 빼고, 절대 바꾸면 안 되는 선을 미리 긋고, 기술 선택도 직접 결정해야 합니다. AI는 매우 빠른 실행 도구이지만, 방향을 잡는 두뇌까지 대신해주지는 못합니다. 그래서 프로젝트가 커질수록 리서치, 계획, 구현을 분리하는 습관이 중요해집니다. 처음부터 완벽한 기획을 하라는 뜻은 아닙니다. 오히려 작은 프로젝트부터 시작하면서 이 흐름을 반복해 보는 것이 가장 좋습니다. 다만 적어도 코드를 쓰기 전 단계에서 무엇을 만들고 왜 그렇게 만들지 정도는 분명히 정해야 합니다. 그 차이가 나중에 코드를 뒤집느냐, 안정적으로 쌓아가느냐를 가릅니다.