2강에서 개발 흐름을 먼저 잡았다면, 3강의 핵심은 “어떤 순간에 어떤 도구를 꺼내야 하는가”입니다. 바이브 코딩을 시작하면 ChatGPT, Claude Code, Cursor, Codex 같은 이름이 한꺼번에 등장합니다. 모두 AI 개발 도구처럼 보이지만, 실제로는 맡기는 일이 꽤 다릅니다.
처음부터 한 도구만 고집하면 오히려 헷갈립니다. 기획을 물어볼 때 좋은 도구, 기존 코드를 고칠 때 좋은 도구, 프로젝트 전체를 읽고 여러 파일을 수정할 때 좋은 도구가 따로 있습니다. 같은 AI라도 “대화 상대”, “코드 편집자”, “프로젝트 에이전트” 중 무엇에 가까운지 구분하면 선택이 쉬워집니다.
1. ChatGPT: 아이디어·설명·학습용 대화형 도구

ChatGPT는 바이브 코딩의 출발점으로 가장 다루기 쉽습니다. 아직 폴더도 없고 코드도 없을 때, 만들고 싶은 서비스의 방향을 말로 풀어내기에 좋습니다.
예를 들어 이런 상황에 잘 맞습니다.
“동네 독서모임 신청 페이지를 만들고 싶은데 어떤 기능이 필요할까?”
“회원가입 없이 신청만 받는 MVP 구조를 잡아줘.”
“프론트엔드, 백엔드, 데이터베이스가 각각 무슨 역할인지 비개발자 기준으로 설명해줘.”
ChatGPT의 강점은 대화 흐름입니다. 모르는 개념을 풀어 설명받고, 요구사항을 정리하고, 기능 우선순위를 나누는 데 적합합니다. 코드도 만들 수 있지만, 프로젝트 폴더 전체를 직접 읽고 수정하는 방식보다는 “코드 조각을 제안받는 방식”에 가깝습니다.
그래서 ChatGPT는 이런 용도로 쓰는 편이 좋습니다.
- 아이디어를 기능 목록으로 바꾸기
- 화면 구성 초안 만들기
- 개발 개념 설명받기
- 에러 메시지 의미 해석하기
- 프롬프트 초안 다듬기
- 구현 전에 작업 순서 정하기
반대로 이미 여러 파일로 구성된 프로젝트를 한꺼번에 고치거나, 실제 터미널에서 명령을 실행하며 수정하는 작업은 ChatGPT만으로는 한계가 있습니다. 코드를 붙여넣어 설명받을 수는 있지만, 파일 구조 전체를 계속 기억하고 직접 수정하는 방식은 다른 도구가 더 적합합니다.
2. Claude Code: 프로젝트 전체를 다루는 터미널형 에이전트

Claude Code는 터미널에서 프로젝트를 열고, 여러 파일을 읽고, 수정하고, 필요한 명령 실행까지 이어가는 형태의 도구로 알려져 있습니다. 일반 채팅창에서 “이 코드 고쳐줘”라고 묻는 방식보다 한 단계 더 개발 환경에 가까이 들어갑니다.
프로젝트 폴더 안에서 작업한다는 점이 중요합니다. 단일 파일이 아니라 전체 구조를 기준으로 생각할 수 있기 때문입니다. 예를 들어 로그인 기능을 추가한다고 하면, 단순히 로그인 버튼 코드만 쓰는 것이 아니라 라우팅, API 호출, 환경 변수, 에러 처리, 관련 파일 수정까지 함께 확인하는 식입니다.
Claude Code가 특히 어울리는 상황은 다음과 같습니다.
- 이미 만들어진 프로젝트를 전체적으로 파악해야 할 때
- 여러 파일을 동시에 수정해야 할 때
- 기능 하나를 끝까지 구현하도록 맡기고 싶을 때
- 테스트 실행, 빌드 확인, 오류 수정이 이어져야 할 때
- “이 프로젝트 구조를 읽고 개선 방향을 제안해줘” 같은 작업이 필요할 때
다만 터미널형 도구는 편한 만큼 주의도 필요합니다. AI가 파일을 직접 바꾸거나 명령을 실행할 수 있으므로, 변경 내역을 확인하는 습관이 필수입니다. Git을 사용한다면 작업 전후 차이를 확인하고, 한 번에 너무 큰 변경을 맡기지 않는 편이 안전합니다.
비개발자 입장에서는 Claude Code가 처음부터 가장 쉬운 도구는 아닐 수 있습니다. 대신 프로젝트가 어느 정도 생긴 뒤 “이제 여러 파일을 함께 손봐야 한다”는 시점에는 큰 힘을 발휘합니다.
3. Cursor: 에디터에 통합된 코드 수정 도구

Cursor는 코드 에디터 안에 AI 기능이 들어간 도구입니다. Visual Studio Code와 비슷한 사용 경험을 제공하는 것으로 알려져 있어, 파일을 열고 코드를 보면서 바로 질문하고 수정할 수 있습니다.
ChatGPT가 대화 중심이라면, Cursor는 코드 편집 중심입니다. 눈앞에 열린 파일, 선택한 코드, 프로젝트 일부를 바탕으로 “이 부분을 이렇게 바꿔줘”라고 요청하기 좋습니다. 코드가 실제로 어디에 들어가는지 보면서 작업할 수 있다는 점이 큰 장점입니다.
Cursor가 잘 맞는 상황은 이런 경우입니다.
- 특정 파일의 코드를 고치고 싶을 때
- UI 문구, 버튼, 레이아웃처럼 눈에 보이는 부분을 수정할 때
- 에러가 난 줄 근처를 바로 고치고 싶을 때
- 기존 코드를 선택한 뒤 설명이나 리팩터링을 요청할 때
- 작은 기능을 빠르게 추가하고 결과를 확인할 때
예를 들어 “이 버튼을 오른쪽으로 옮겨줘”, “이 함수 이름을 더 명확하게 바꿔줘”, “이 컴포넌트를 두 개로 나눠줘” 같은 요청은 Cursor에서 처리하기 좋습니다.
바이브 코딩 초반에는 Cursor가 체감상 가장 실용적으로 느껴질 수 있습니다. 화면 왼쪽에는 파일 구조가 있고, 가운데에는 코드가 보이며, 옆에서 AI에게 바로 요청할 수 있기 때문입니다. 다만 프로젝트 전체의 큰 설계 판단이나 요구사항 정리는 ChatGPT 같은 대화형 도구에서 먼저 잡고 들어가는 편이 덜 흔들립니다.
4. Codex: 코드 읽기·수정·실행형 에이전트

Codex는 OpenAI 계열의 코드 작업 에이전트로, 코드베이스를 읽고 수정하며 실행 결과를 바탕으로 작업하는 흐름에 초점이 맞춰져 있습니다. 이름은 문맥에 따라 예전 코드 생성 모델을 가리키기도 하고, 최근의 개발 작업용 에이전트를 가리키기도 하므로 사용 중인 제품 화면과 공식 문서 기준으로 확인하는 것이 안전합니다.
Codex를 이해할 때는 “코드를 실제 작업 단위로 처리하는 에이전트”에 가깝다고 보면 됩니다. 단순히 설명을 잘하는 도구라기보다, 저장소 안에서 버그를 찾고, 수정안을 만들고, 테스트를 돌려보는 흐름에 어울립니다.
사용하기 좋은 상황은 다음과 같습니다.
- 버그 원인을 코드베이스 안에서 추적해야 할 때
- 테스트 실패를 보고 관련 코드를 고쳐야 할 때
- 기존 기능을 유지하면서 작은 변경을 넣어야 할 때
- 반복적인 코드 수정 작업을 맡기고 싶을 때
- 변경 사항을 검토 가능한 형태로 받고 싶을 때
Codex 역시 실행형 에이전트 성격이 있기 때문에 “맡긴 뒤 결과만 믿기”보다는 변경된 파일, 실행 로그, 테스트 결과를 함께 확인해야 합니다. 특히 로그인, 결제, 개인정보 처리처럼 민감한 영역은 AI가 제안한 코드라도 반드시 사람이 기준을 세워 검수해야 합니다.
5. 상황별 도구 선택 가이드
도구 선택은 “지금 내가 막힌 지점이 어디인가”로 판단하는 편이 가장 간단합니다.
아직 아이디어 단계라면 ChatGPT가 적합합니다. 만들고 싶은 서비스가 흐릿할 때, 기능을 정리하고 화면 구성을 잡고 개발 용어를 이해하는 데 좋습니다. 바이브 코딩을 처음 시작하는 분이라면 ChatGPT로 요구사항을 먼저 문장화하는 습관을 들이는 것이 좋습니다.
코드를 직접 열어 조금씩 고치는 단계라면 Cursor가 편합니다. 버튼 위치, 문구, 컴포넌트 수정, 간단한 기능 추가처럼 눈앞의 파일을 보면서 고치는 작업에 잘 맞습니다. “이 부분이 왜 동작하지 않는지 설명해줘”처럼 선택한 코드 기준으로 묻는 방식도 효과적입니다.
프로젝트 전체를 읽고 여러 파일을 함께 수정해야 한다면 Claude Code나 Codex 같은 에이전트형 도구가 어울립니다. 기능 하나가 프론트엔드, 백엔드, 설정 파일에 동시에 걸쳐 있을 때는 단순 채팅보다 프로젝트 맥락을 다루는 도구가 유리합니다.
조금 더 실전적으로 나누면 다음과 같습니다.
- 무엇을 만들지 정해야 한다: ChatGPT
- 개발 개념을 쉽게 설명받고 싶다: ChatGPT
- 특정 파일을 보면서 바로 수정하고 싶다: Cursor
- UI나 컴포넌트를 빠르게 다듬고 싶다: Cursor
- 프로젝트 구조 전체를 이해시키고 싶다: Claude Code
- 여러 파일에 걸친 기능을 구현하고 싶다: Claude Code
- 버그를 추적하고 실행 결과 기반으로 고치고 싶다: Codex
- 테스트 실패나 코드 수정 작업을 에이전트에게 맡기고 싶다: Codex
한 가지 도구로 모든 일을 끝내려 하기보다, 작업 흐름에 맞춰 넘겨주는 방식이 안정적입니다. 예를 들면 ChatGPT로 요구사항을 정리하고, Cursor에서 첫 화면을 만들고, Claude Code로 여러 파일에 걸친 기능을 붙인 뒤, Codex로 버그 수정과 테스트 확인을 맡기는 식입니다.
중요한 기준은 도구 이름이 아니라 작업의 성격입니다. 말로 정리할 문제인지, 파일 하나를 고칠 문제인지, 프로젝트 전체를 바꿀 문제인지부터 구분하면 됩니다. 이 기준만 잡아도 바이브 코딩에서 흔히 겪는 “어떤 도구를 켜야 할지 모르겠다”는 혼란이 크게 줄어듭니다.
댓글 0