아이디어가 있으면 무엇부터 하나
아이디어가 있다. 만들고 싶은 것도 있다. 그런데 어디서 시작해야 하는지 모르겠다. Claude Code를 켰는데 첫 줄에 뭘 써야 하는지 막막하다.
이건 익숙하지 않은 문제가 아니다. 개발을 처음 접하는 사람뿐 아니라, 바이브코딩을 여러 번 해본 사람도 첫 세션에서 자주 막히는 지점이 있다. 그 지점들을 순서대로 정리한다.
1단계: 만들 것을 한 문장으로 줄인다
첫 번째 실수는 너무 많은 것을 첫 세션에 넣으려고 하는 것이다.
"사용자가 로그인하고, 일정을 등록하고, 팀원에게 공유하고, 알림도 받을 수 있는 서비스"를 한 번에 만들려고 하면 대부분 실패한다. AI가 처리하는 범위가 넓어질수록 앞부분이 만들어질 때 뒷부분이 어긋나기 시작한다.
첫 세션에서 만들 것을 한 문장으로 줄인다. "로그인 없이 일정을 등록하고 URL로 공유할 수 있는 페이지." 이게 첫 번째 목표다. 나머지는 이게 작동한 다음에 더한다.
기능을 줄이는 게 아깝게 느껴질 수 있다. 하지만 작동하는 핵심 하나가 작동하지 않는 전체보다 낫다. 처음부터 완성품을 만들려는 기대가 첫 세션을 망치는 가장 흔한 원인이다.
2단계: 첫 요청에 포함해야 하는 것
범위를 정했으면 Claude Code에 첫 요청을 넣는다. 이때 포함해야 하는 것이 있다.
무엇을 만드는지. "일정 등록 페이지를 만들어줘"처럼 목적을 먼저 쓴다.
누가 쓰는지. "모바일에서 주로 쓸 예정이야", "비개발자가 쓸 거야"처럼 사용자를 언급하면 결과가 달라진다. 누구를 위한 것인지가 명확하면 AI가 복잡도와 방향을 알아서 맞춘다.
기술 제약이 있는지. 특별히 지정하고 싶은 기술 스택이 없다면 Claude Code가 알아서 선택한다. 처음에는 기술 선택을 Claude에게 맡기는 게 낫다. 어떤 기술이 좋은지 모르는 상태에서 임의로 지정하면 나중에 문제가 생길 수 있다.
3단계: 결과를 눈으로 확인한다
Claude Code가 코드를 만들면, 실행해서 눈으로 확인한다. 코드를 읽으려고 하지 않아도 된다. 실행해서 원하는 대로 보이는지 확인한다.
이 단계에서 많은 사람이 막힌다. 코드를 실행하는 방법을 모르기 때문이다. Claude Code에게 "이걸 실행하려면 어떻게 해야 하나?"라고 물어보면 된다. 설치해야 하는 것이 있으면 무엇을 설치해야 하는지, 어떤 명령어를 입력해야 하는지 알려준다.
실행이 안 되는 오류가 나오면 오류 메시지를 그대로 복사해서 Claude Code에게 붙여넣는다. 오류를 직접 해결하려고 하지 않는다. 그게 바이브코딩의 핵심 흐름이다.
4단계: 피드백을 구체적으로 준다
화면이 나왔다. 원하는 것과 다른 부분이 있다. 이때 피드백을 어떻게 주느냐가 이후 품질을 결정한다.
"좀 이상한 것 같아"는 피드백이 아니다. "버튼이 너무 작아서 모바일에서 누르기 어려울 것 같아. 크기를 키워줘"가 피드백이다. 구체적일수록 한 번에 잘 고쳐진다.
피드백은 한 번에 하나씩 준다. 수정할 점이 다섯 가지라면 하나씩 순서대로 요청한다. 한 번에 다섯 가지를 넣으면 하나가 고쳐지면서 다른 것이 틀어지는 경우가 생긴다. 직렬로 진행하는 것이 병렬보다 결과가 좋다.
5단계: 작동하는 상태에서 저장한다
작동하는 상태가 되면 저장한다. Claude Code를 사용하면 코드가 로컬에 만들어지는데, 이 시점에 변경사항을 커밋해두면 좋다. 이후 수정이 잘못돼서 이전 상태로 돌아가야 할 때를 대비한다.
Claude Code에게 "지금 상태를 저장해줘. 나중에 이 시점으로 돌아올 수 있게"라고 하면 처리해준다. Git을 모른다면 "변경사항을 저장하고 싶어. 어떻게 하면 되나?"라고 물어보면 안내해준다. 저장 습관이 없으면 한 번의 실수로 지금까지 만든 것을 잃을 수 있다.
첫 세션에서 자주 막히는 지점
경험상 처음 세션에서 막히는 지점은 몇 가지로 반복된다.
실행 환경 설정에서 막히는 경우가 많다. Node.js나 Python 같은 것을 설치해야 하는데, 설치 과정에서 오류가 나거나 버전 문제가 생기기도 한다. 이때도 오류 메시지를 그대로 붙여넣고 Claude Code에게 물어보면 해결 방법을 알려준다.
요청이 너무 넓어서 결과가 맞지 않는 경우도 있다. 이때는 요청을 다시 좁혀서 핵심 기능 하나부터 다시 시작한다. 처음 설정을 바꾸는 것을 주저하지 않아도 된다.
같은 오류가 반복되면 접근 방식을 바꾼다. "이 방식으로 계속 안 되는 것 같아. 다른 방법으로 해줘"라고 요청하면 된다. 같은 방법을 계속 시도하는 것보다 방향을 바꾸는 게 빠른 경우가 많다.
첫 프로토타입은 완성품이 아니다
첫 세션의 목표는 완성품이 아니다. 아이디어가 실제로 작동하는지 확인하는 것이다.
작동하는 최소한의 화면 하나가 나오면 그게 성공이다. 거기서 피드백을 받고, 수정하고, 기능을 더하는 과정이 이어진다. 첫 세션에서 완성된 제품이 나오길 기대하면 실망하게 된다.
아이디어에서 작동하는 화면까지, 첫 세션에서 도달해야 하는 목표는 그것뿐이다. 그 다음은 그 다음 세션의 일이다.