바이브 코딩 실전 3화: AI 코딩 에이전트 선택 기준

바이브 코딩 실전 3화입니다. Cursor, Claude Code, Codex, Gemini CLI처럼 빠르게 늘어나는 AI 코딩 에이전트 중 무엇을 선택해야 하는지 정리했습니다. 단순한 성능 비교보다 프로젝트 이해력, 수정 계획, 변경 내역 확인, 실행과 테스트, 권한 관리, 프로젝트 규칙, 확장성, 비용 예측 가능성을 기준으로 살펴봅니다.

1. 먼저 ChatGPT와 AI 코딩 에이전트는 뭐가 다를까?

처음에는 이 부분부터 조금 헷갈립니다.

ChatGPT나 Claude 같은 AI에게 코드를 물어볼 수도 있습니다.

예를 들어

Flutter에서 로그인 화면 만들어줘.

라고 하면 코드를 만들어줍니다.

우리가 그 코드를 복사해서 프로젝트에 붙여넣을 수 있습니다.

이것도 충분히 AI 코딩입니다.

하지만 AI 코딩 에이전트는 한 단계 더 들어갑니다.

프로젝트의 파일을 읽고,

필요한 파일을 찾고,

여러 파일을 수정하고,

명령어를 실행하고,

오류를 확인하고,

테스트까지 수행할 수 있습니다.

예를 들어 현재 Claude Code는 코드베이스를 읽고 여러 파일을 수정하며 명령을 실행할 수 있는 에이전트형 개발 도구로 제공되고 있습니다.

Cursor의 Agent 역시 자율적인 코딩 작업과 터미널 명령, 코드 편집을 수행하도록 설계되어 있습니다.

OpenAI Codex도 코드를 읽고 수정하고 명령을 실행하는 형태로 IDE, 터미널, ChatGPT 환경에서 사용할 수 있습니다.

즉 차이를 아주 단순하게 표현하면 이렇습니다.

일반 AI 대화

나 : 로그인 화면 코드 만들어줘

AI : 여기 코드가 있습니다.

나 : 복사
나 : 붙여넣기
나 : 실행
나 : 오류 확인

AI 코딩 에이전트는 조금 다릅니다.

나 : 로그인 기능을 추가해줘.

AI 에이전트

프로젝트 구조 확인
↓
관련 파일 탐색
↓
코드 수정
↓
필요한 패키지 확인
↓
명령 실행
↓
오류 확인
↓
수정
↓
결과 보고

비개발자의 바이브 코딩에서 중요한 변화가 바로 여기 있습니다.

코드를 만드는 AI에서 일을 수행하는 AI로 넘어간 것입니다.

2. 그런데 여기서 함정이 하나 있다

처음 AI 에이전트를 사용하면 꽤 놀랍습니다.

우리가 한 문장만 입력했는데 파일을 여기저기 열어보고 코드를 순식간에 바꿉니다.

터미널도 실행합니다.

문제도 알아서 찾습니다.

그러면 슬슬 이런 생각이 듭니다.

"이 정도면 그냥 전부 맡겨도 되는 거 아닌가?"

여기서 위험한 버튼이 눌립니다. 🚨

AI가 많이 할 수 있다는 것과

AI에게 많이 맡겨야 한다는 것은 다른 문제입니다.

우리가 원하는 것은 가장 많은 코드를 자동으로 변경하는 AI가 아닙니다.

우리가 원하는 것은

비개발자가 결과를 확인하면서 끝까지 제품을 완성할 수 있게 해주는 AI

입니다.

그래서 도구를 고르는 기준도 달라져야 합니다.

3. 선택 기준 1. 프로젝트 전체를 이해할 수 있는가?

첫 번째로 볼 것은 단순한 코드 생성 능력이 아닙니다.

프로젝트 컨텍스트를 얼마나 잘 이해하는가입니다.

앱이 조금만 커져도 파일 하나로 끝나지 않습니다.

화면
로그인
데이터 저장
API
설정
테스트
환경변수
빌드 설정

이것들이 여러 파일에 흩어집니다.

그런데 AI가 현재 열어둔 파일 하나만 보고 수정한다면 문제가 생길 수 있습니다.

예를 들어 우리는 이렇게 말합니다.

기록 삭제 기능 추가해줘.

AI는 화면에 삭제 버튼은 잘 만들었습니다.

그런데 실제 DB 삭제 로직은 빠뜨렸습니다.

화면에서는 사라졌는데 앱을 다시 실행하면 죽었던 기록이 부활합니다.

🧟 좀비 데이터 등장.

제품 개발에서는 이런 상황이 생각보다 골치 아픕니다.

그래서 AI가

현재 프로젝트 구조와 관련 파일을 탐색하고 연결 관계를 파악하는 능력

이 중요합니다.

Claude Code는 코드베이스 전체를 탐색하는 워크플로를 제공하고 있으며, Cursor Agent 역시 코드베이스를 바탕으로 파일을 탐색하고 수정하는 방식으로 동작합니다.

우리가 도구를 고를 때 첫 번째 질문은 따라서 이것입니다.

"이 AI가 코드를 잘 쓰나?"

보다

"내 프로젝트를 얼마나 잘 이해하면서 수정하나?"

입니다.

4. 선택 기준 2. 수정하기 전에 계획을 보여주는가?

이건 비개발자에게 특히 중요합니다.

AI에게

로그인 구조를 개선해줘.

라고 했는데 갑자기 파일 14개를 수정하기 시작한다고 생각해보겠습니다.

화면에는 글자가 쏟아지고,

터미널도 움직이고,

파일도 계속 바뀝니다.

우리는 조용히 화면을 바라봅니다.

🙂

3분 뒤.

앱이 안 됩니다.

😐

이런 일을 줄이는 좋은 방법이 있습니다.

계획 → 검토 → 실행

순서입니다.

예를 들어 이렇게 요청합니다.

현재 로그인 구조를 먼저 분석해줘.

아직 코드를 수정하지 말고

1. 현재 구조
2. 문제점
3. 수정할 파일
4. 변경 방법
5. 예상되는 영향

을 먼저 설명해줘.

그 내용을 확인한 다음 수정하도록 하는 것입니다.

현재 Claude Code에는 코드를 변경하기 전에 프로젝트를 탐색하고 계획을 제안하는 Plan 방식이 제공되며, 일반적인 워크플로에서도 먼저 계획을 검토한 뒤 수정하도록 사용할 수 있습니다.

특정 제품에 이런 이름의 기능이 있느냐보다 중요한 것은 습관입니다.

큰 수정일수록 AI에게 바로 코딩시키지 않는다.

앞으로 우리 연재에서도 이 방법을 꽤 자주 사용하게 됩니다.

5. 선택 기준 3. 무엇을 바꿨는지 사람이 확인하기 쉬운가?

이 부분은 아주 중요합니다.

AI가

완료했습니다.

라고 말했다고 진짜 완료된 것은 아닙니다.

바이브 코딩 세계의

"완료했습니다."

는 가끔

"저는 일단 뭔가 했습니다."

정도로 번역해야 할 때도 있습니다. 😂

그래서 변경된 코드를 사람이 확인할 수 있어야 합니다.

예를 들어 AI가 세 파일을 수정했다면

어떤 파일을 수정했는가?

무엇을 추가했는가?

무엇을 삭제했는가?

왜 수정했는가?

를 확인하기 쉬운 환경이 좋습니다.

Git과 연결해서 변경 내용을 비교할 수 있다면 더욱 좋습니다.

지난 편에서 Git을 강조했던 이유가 여기서 다시 등장합니다.

앞으로 우리는 이런 흐름을 기본 습관으로 만들어보겠습니다.

정상 작동 확인

↓

Git Commit

↓

AI에게 작업 요청

↓

변경 내용 확인

↓

앱 실행

↓

문제없으면 Commit

AI의 기억보다 Git의 기록을 믿겠습니다.

Git은 삐치지도 않고 변명도 하지 않습니다.

6. 선택 기준 4. 직접 실행하고 오류까지 확인할 수 있는가?

코드를 생성하는 것과 실행되는 코드를 만드는 것은 다른 문제입니다.

예를 들어 AI가 이런 말을 했다고 해보겠습니다.

로그인 기능을 구현했습니다.

그런데 실행해보면

Build failed

끝.

이런 상황이 생각보다 자주 발생합니다.

그래서 좋은 코딩 에이전트는 파일만 수정하는 것이 아니라

빌드하고,

테스트하고,

터미널 명령을 실행하고,

발생한 오류를 다시 확인할 수 있어야 합니다.

Codex CLI는 로컬 프로젝트에서 코드를 검사하고 수정하며 명령을 실행할 수 있도록 제공되고 있고, Claude Code와 Cursor Agent 역시 파일 수정과 명령 실행을 결합한 워크플로를 지원합니다.

이 능력은 비개발자에게 특히 큰 차이를 만듭니다.

나쁜 흐름은 이렇습니다.

AI 코드 생성

↓

내가 실행

↓

오류 발생

↓

오류 복사

↓

AI에게 전달

↓

수정 코드 복사

↓

다시 실행

조금 더 발전된 흐름은

AI 코드 수정

↓

AI가 실행

↓

오류 발견

↓

AI가 원인 분석

↓

수정

↓

다시 실행

↓

결과 보고

가 됩니다.

이것이 Agentic Coding의 힘입니다.

7. 선택 기준 5. AI에게 어디까지 권한을 줄 수 있는가?

여기부터 제품 개발 냄새가 조금 나기 시작합니다.

AI가 터미널을 사용할 수 있다는 것은 강력합니다.

하지만 반대로 생각하면

내 컴퓨터에서 명령어를 실행할 수 있다는 뜻이기도 합니다.

파일을 수정할 수 있고,

삭제할 수도 있으며,

외부 도구와 연결할 수도 있습니다.

그래서

모든 걸 자동으로 허용하면 편하겠지?

라는 생각은 잠시 접어두는 편이 좋습니다.

특히 처음에는

파일 읽기
→ 비교적 자유롭게

파일 수정
→ 확인하면서

명령 실행
→ 중요한 명령은 승인

삭제 / 배포 / 외부 서비스 변경
→ 반드시 확인

정도의 보수적인 기준으로 시작하는 것을 권합니다.

AI가 똑똑해질수록 권한 관리도 함께 중요해집니다.

자율주행차의 성능이 좋아졌다고 브레이크 페달을 떼어낼 이유는 없습니다.

8. 선택 기준 6. 프로젝트 규칙을 기억시킬 수 있는가?

앱이 커지면 매번 이런 말을 하게 됩니다.

파일 이름은 이렇게 작성해줘.

기존 구조를 유지해줘.

API Key는 코드에 직접 넣지 마.

작업 후 테스트를 실행해.

기존 UI 스타일을 임의로 바꾸지 마.

처음 몇 번은 괜찮습니다.

20번째쯤 되면 우리가 AI에게 앱을 만드는 건지 가정교육을 하는 건지 헷갈립니다.

그래서 대부분의 주요 코딩 에이전트에는 프로젝트 규칙이나 지속적인 컨텍스트를 제공하는 방법이 발전하고 있습니다.

Claude Code에서는 CLAUDE.md를 이용해 빌드 명령이나 프로젝트 규칙 같은 정보를 제공할 수 있고, /init을 통해 코드베이스를 분석해 시작 파일을 생성할 수도 있습니다.

Cursor 역시 Rules와 Skills 같은 방식으로 프로젝트 지침과 반복 작업을 정의할 수 있습니다.

Gemini CLI도 프로젝트 컨텍스트를 이용하고 GEMINI.md 같은 파일을 통한 사용자 정의 워크플로가 공식 가이드에 소개되어 있습니다.

이 기능은 앞으로 아주 중요하게 사용할 예정입니다.

우리도 MyLog 프로젝트를 시작하면 AI에게

"이 프로젝트에서는 반드시 지켜야 하는 규칙"

을 만들어줄 겁니다.

그 내용은 #08에서 제대로 다루겠습니다.

9. 선택 기준 7. 확장할 수 있는가?

처음에는 AI가 코드만 잘 만들어주면 충분합니다.

하지만 프로젝트가 커지면 욕심이 생깁니다.

GitHub도 확인했으면 좋겠고,

DB 상태도 확인했으면 좋겠고,

문서도 읽었으면 좋겠고,

외부 서비스를 직접 다뤘으면 좋겠습니다.

여기서 요즘 자주 등장하는 것이 MCP와 Skills 같은 확장 방식입니다.

예를 들어 Cursor는 MCP를 통해 외부 도구와 데이터 소스를 연결할 수 있고, Claude Code 역시 MCP 서버를 이용해 데이터베이스나 API, 외부 도구에 접근하는 구조를 지원합니다.

Gemini CLI도 내장 도구와 로컬 또는 원격 MCP 서버를 이용해 작업을 수행하는 구조를 공식적으로 제공하고 있습니다.

지금 당장 MCP를 알아야 할 필요는 없습니다.

현재 단계에서는

"나중에 AI가 코드 바깥의 도구까지 사용할 수 있구나."

정도만 기억해두면 충분합니다.

우리도 연재가 진행되면서 필요한 순간이 오면 꺼내겠습니다.

10. 선택 기준 8. 가격보다 '비용이 예측 가능한가?'를 보자

비개발자 바이브 코딩에서 의외로 쉽게 놓치는 부분입니다.

처음에는 무료 사용량이나 구독료만 봅니다.

그런데 에이전트형 개발은 생각보다 AI를 많이 사용합니다.

프로젝트를 읽고,

코드를 분석하고,

여러 파일을 수정하고,

오류를 다시 분석하면서 사용량이 늘어날 수 있습니다.

Claude Code 공식 문서에서도 실제 비용은 모델 선택, 코드베이스 크기, 여러 인스턴스 사용 방식 등에 따라 크게 달라질 수 있다고 안내합니다.

Cursor 역시 모델과 플랜에 따른 별도의 사용량 및 가격 구조를 안내하고 있습니다.

따라서

"가장 싼 도구가 무엇인가?"

보다

"내가 얼마나 쓰고 있는지 알 수 있는가?"

가 더 중요합니다.

특히 나중에 AI API까지 앱 안에 넣기 시작하면

개발 비용과

서비스 운영 비용은

완전히 다른 이야기가 됩니다.

그건 훗날 또 다른 지갑 괴물이 등장했을 때 이야기하겠습니다. 💸

11. 그래서 Cursor, Claude Code, Codex, Gemini CLI 중 뭘 쓰나요?

드디어 처음 질문으로 돌아왔습니다.

현재 주요 도구들을 아주 거칠게 구분하면 다음처럼 바라볼 수 있습니다.

Cursor

IDE 안에서 프로젝트 파일을 보면서 AI Agent를 사용하는 경험이 중심이라 GUI 환경이 익숙한 사람에게 접근하기 편한 편입니다. Agent, Rules, Skills, MCP, CLI 등으로 기능 영역도 확장되고 있습니다.

Claude Code

터미널뿐 아니라 IDE, 데스크톱, 웹에서도 사용할 수 있으며 코드베이스 탐색, 여러 파일 수정, 명령 실행과 같은 에이전트형 개발 흐름을 지원합니다.

Codex

ChatGPT, IDE 확장, CLI 환경을 오가며 사용할 수 있고 코드 수정, 명령 실행, 테스트와 리팩터링 같은 실제 개발 작업을 에이전트에게 맡기는 형태로 발전하고 있습니다.

Gemini CLI

터미널 기반의 오픈소스 AI 에이전트로 프로젝트 컨텍스트와 도구, MCP 등을 활용해 버그 수정이나 기능 개발 같은 작업을 수행할 수 있습니다.

하지만 이 목록을 캡처해서

"2026 AI 코딩 순위표"

로 저장하지는 마세요.

이 시장에서는 순위표의 유통기한이 우유보다 짧을 때가 있습니다. 🥛

우리는 제품 이름보다 작업 방식을 배우겠습니다.

12. 비개발자라면 처음에는 이렇게 시작하는 것을 권한다

처음부터 도구 네 개를 동시에 배우지 않는 것이 좋습니다.

앱 하나 만들기도 바쁜데 AI 도구 비교가 새로운 취미가 될 수 있습니다.

그래서 처음에는

메인 코딩 에이전트 하나

만 정합니다.

그리고 프로젝트가 익숙해진 다음 필요하면 다른 에이전트를

검토,

디버깅,

코드 리뷰,

별도 분석

용도로 추가하면 됩니다.

우리 연재에서도 기본 흐름은 동일합니다.

사람

무엇을 만들지 결정

↓

AI

현재 프로젝트 분석

↓

사람 + AI

작업 계획 확인

↓

AI

코드 수정

↓

AI

실행 / 테스트

↓

사람

실제 앱 확인

↓

Git

정상 상태 저장

중요한 것은 AI에게 모든 판단을 맡기는 것이 아닙니다.

사람이 방향을 결정하고 AI가 실행하는 구조

를 유지하는 것입니다.

13. AI 모델과 AI 에이전트도 구분하자

이것도 앞으로 자주 등장하기 때문에 한번 짚고 넘어가겠습니다.

AI 모델과 AI 코딩 에이전트는 같은 것이 아닙니다.

모델은 일종의 두뇌에 가깝습니다.

에이전트는 그 두뇌에

파일 읽기,

파일 수정,

터미널 실행,

검색,

Git,

외부 도구

같은 손과 발을 붙인 실행 환경에 가깝습니다.

그래서

어떤 모델이 제일 코딩을 잘해요?

도 중요하지만

제품을 만드는 과정에서는

어떤 에이전트 환경에서 어떤 권한과 컨텍스트를 주고 일하게 할 것인가?

도 그만큼 중요합니다.

앞으로 바이브 코딩 경쟁은 모델 IQ 대결만으로 끝나지 않을 가능성이 큽니다.

얼마나 좋은 개발 환경과 도구를 AI에게 제공하느냐

가 점점 중요해지고 있기 때문입니다.

14. 오늘의 삽질 방지 팁 🛠️

새로운 AI 코딩 도구가 나왔다고 매번 프로젝트를 옮기지 마세요.

SNS에서는 거의 매주 이런 분위기가 등장합니다.

"이제 개발자는 끝났다."

며칠 후.

"이번에는 진짜 끝났다."

다음 달.

"이번 모델은 차원이 다르다."

개발자는 아직 출근하고 있습니다. 😅

도구를 갈아타는 데 시간을 쓰기보다

현재 도구에서

프로젝트를 구조화하고

작업을 작게 나누고

Git으로 기록하고

변경 내용을 확인하고

실제 실행 결과를 검증하는 습관

을 만드는 것이 훨씬 오래 남습니다.

15. 오늘 기억할 선택 기준

AI 코딩 에이전트를 고를 때는 단순히 벤치마크 숫자만 보지 않겠습니다.

다음 질문을 던져보겠습니다.

프로젝트 전체 구조를 이해할 수 있는가?

수정하기 전에 계획을 검토할 수 있는가?

어떤 파일을 바꿨는지 확인하기 쉬운가?

코드를 직접 실행하고 오류를 확인할 수 있는가?

AI에게 줄 권한을 제어할 수 있는가?

프로젝트 규칙을 지속적으로 전달할 수 있는가?

Git과 자연스럽게 사용할 수 있는가?

외부 도구로 확장할 수 있는가?

사용 비용을 파악하고 관리할 수 있는가?

이 기준으로 보면 도구 이름이 바뀌어도 흔들리지 않습니다.

그리고 더 중요한 기준 하나가 남았습니다.

내가 이 도구를 사용하면서 무슨 일이 벌어지고 있는지 이해할 수 있는가?

비개발자에게는 의외로 이것이 가장 중요합니다.

16. 좋은 바이브 코딩은 좋은 AI를 고르는 것에서 끝나지 않는다

AI 코딩 에이전트는 점점 강력해지고 있습니다.

코드를 읽고,

수정하고,

명령을 실행하고,

테스트하고,

외부 도구와 연결할 수도 있습니다.

그렇다면 이제 필요한 능력은 조금 달라집니다.

우리가 직접

for, if, class

부터 외워서 모든 코드를 작성하는 대신,

무엇을 만들 것인지 결정하고

작업 범위를 정하고

결과가 맞는지 판단하는 능력

이 점점 중요해집니다.

그리고 바로 다음 편에서 그 이야기를 해보겠습니다.

많은 바이브 코딩 프로젝트가 실패하는 이유는 AI 성능이 부족해서가 아닙니다.

처음부터 너무 많은 것을 만들려고 하기 때문입니다.

"로그인도 넣고요."

"채팅도 넣고요."

"결제도요."

"AI 추천도요."

"관리자 페이지도 하나..."

잠깐만요.

아직 앱 이름도 결정하지 않았습니다. 🫠

다음 편에서는 우리의 첫 앱 MyLog에서 정말 필요한 것만 남겨보겠습니다.

다음 편

[바이브 코딩 실전 #04] 만들고 싶은 기능부터 적으면 실패합니다 | 첫 앱의 범위를 줄이는 방법

이번에는 드디어

"무엇을 만들 것인가?"

를 결정합니다.

그런데 기능을 추가하는 이야기가 아닙니다.

반대로 기능을 버리는 이야기부터 시작하겠습니다.

바이브 코딩에서 첫 번째 제품을 완성하는 가장 빠른 방법은 AI에게 더 많은 일을 시키는 것이 아니라,

AI가 해야 할 일을 줄이는 것

일지도 모릅니다.

연재 기준: 2026년 8월AI 코딩 에이전트의 기능, 제공 방식, 모델 및 요금 체계는 빠르게 변경될 수 있습니다. 특정 도구의 설치와 실제 사용을 다루는 회차에서는 작성 시점의 공식 문서를 다시 확인합니다.

#바이브코딩 #VibeCoding #AI코딩 #AI코딩에이전트 #비개발자앱개발 #비개발자개발 #Cursor #ClaudeCode #Codex #GeminiCLI #AgenticCoding #AI에이전트 #앱개발 #MVP개발 #Git #바이브코딩실전

바이브 코딩 실전 3화: AI 코딩 에이전트는 무엇을 골라야 할까?

목차