🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Claude Code는 Convex 기반 TypeScript 풀스택 작업에서 강력한 agent-first 개발 경험을 보여줬지만, Cursor보다 불편한 CLI UX, 모델 전환, 메시지 큐잉, 비용 통제가 실제 약점으로 드러났다.

📌 핵심 요약

• 글쓴이는 AI 에이전트가 코드를 작성하는 시대에 개발자 경험 엔지니어의 역할이 어떻게 바뀌는지 고민하다가, 논쟁을 추상적으로 이어가기보다 Claude Code를 실제 프로젝트에 적용해 보기로 했다.
• 실험은 IDE, Cursor, VS Code 없이 터미널의 Claude Code와 Convex 백엔드만으로 YouTube API, X API, AI 파싱, 인증, 관리자 도구, 파일 저장소를 포함한 포트폴리오 사이트를 만드는 방식으로 진행됐다.
• Claude Code는 플러그인 확장성, Convex MCP를 통한 데이터베이스 검사, 자동 plan mode, 적절한 도구 호출, 빠른 CLI 시작 속도에서 강점을 보였고, 특히 Convex의 TypeScript 중심 구조와 잘 맞았다.
• 반면 터미널 기반 인터페이스는 기능 발견성, 마우스 조작, 스크린샷 전달, 모델 전환, 메시지 큐잉에서 Cursor 같은 IDE 기반 도구보다 불편했고, UI 작업이나 빠른 반복 과정에서 흐름을 끊었다.
• 총 비용은 Claude Code 구독 20달러와 추가 API 크레딧 40달러로 60달러였으며, Opus 4.5를 주로 사용한 탓에 간단한 작업에도 비싼 모델을 계속 쓰게 되는 비용 통제 문제가 핵심 한계로 제시됐다.

🧩 주요 포인트

1. 글쓴이는 AI 에이전트가 코드를 작성하는 시대에 개발자 경험 엔지니어의 역할이 어떻게 바뀌는지 고민하다가, 논쟁을 추상적으로 이어가기보다 Claude Code를 실제 프로젝트에 적용해 보기로 했다.
2. 실험은 IDE, Cursor, VS Code 없이 터미널의 Claude Code와 Convex 백엔드만으로 YouTube API, X API, AI 파싱, 인증, 관리자 도구, 파일 저장소를 포함한 포트폴리오 사이트를 만드는 방식으로 진행됐다.
3. Claude Code는 플러그인 확장성, Convex MCP를 통한 데이터베이스 검사, 자동 plan mode, 적절한 도구 호출, 빠른 CLI 시작 속도에서 강점을 보였고, 특히 Convex의 TypeScript 중심 구조와 잘 맞았다.
4. 반면 터미널 기반 인터페이스는 기능 발견성, 마우스 조작, 스크린샷 전달, 모델 전환, 메시지 큐잉에서 Cursor 같은 IDE 기반 도구보다 불편했고, UI 작업이나 빠른 반복 과정에서 흐름을 끊었다.
5. 총 비용은 Claude Code 구독 20달러와 추가 API 크레딧 40달러로 60달러였으며, Opus 4.5를 주로 사용한 탓에 간단한 작업에도 비싼 모델을 계속 쓰게 되는 비용 통제 문제가 핵심 한계로 제시됐다.

🧠 상세 정리

1. 실험의 출발점: AI 에이전트 시대의 개발자 경험

글은 Claude Code와 Cursor 중 어느 쪽이 더 나은지를 단순히 주장하는 대신, 실제 프로젝트를 통해 확인하겠다는 문제의식에서 출발한다. 글쓴이는 몇 주 전 X에 AI 에이전트가 코드를 작성하는 상황에서 개발자 경험 엔지니어가 어떤 의미를 갖는지에 대한 솔직한 고민을 올렸다고 설명한다. 이후 추상적인 걱정이나 업계 전망에 머무르지 않고, 사람들이 논쟁하는 도구를 실제로 테스트하기로 한다. 이 실험의 목적은 최고의 코딩 AI를 뽑는 것이 아니라, agent-first 워크플로가 현실적인 복잡도를 가진 프로젝트에서 어떻게 작동하는지 확인하는 데 있었다.

2. IDE 없이 Claude Code와 Convex만으로 만든 풀스택 앱

실험 방식은 명확했다. 글쓴이는 IDE, Cursor, VS Code를 열지 않고 터미널에서 Claude Code만 사용해 Convex 백엔드 기반의 실제 풀스택 앱을 만들었다. 대상 앱은 포트폴리오 사이트였고, YouTube API와 X API에서 데이터를 가져오며, AI로 콘텐츠를 파싱하고, 인증과 관리자 도구까지 포함했다. 백엔드는 Convex의 클라우드 함수, 데이터베이스, 파일 저장소를 중심으로 구성됐다. 글쓴이는 이 프로젝트가 단순한 장난감 데모가 아니라 여러 통합 지점과 충분한 복잡도를 가진 작업이었기 때문에 실제 마찰을 드러내기에 적합했다고 말한다.

3. Claude Code의 강점: 플러그인, MCP, 확장성

Claude Code의 가장 큰 장점 중 하나로는 플러그인 확장성이 제시된다. 글쓴이는 /plugin 시스템이 빠르고 마찰 없이 설치되며, MCP 서버 지원 덕분에 에이전트 기능을 자연스럽게 확장할 수 있었다고 평가한다. 특히 Convex MCP는 개발 중 데이터베이스 상태를 직접 검사할 수 있게 해 주었고, 에이전트가 쿼리와 mutation을 작성하면서 실제 데이터 형태에 대한 가정을 스스로 검증할 수 있게 했다. 사용자가 스키마를 매번 복사해 채팅에 붙여 넣지 않아도 된다는 점은 잘못된 방향으로 가는 일을 줄이는 중요한 요소였다.

4. Convex 구조가 에이전트 개발에 유리했던 이유

글쓴이는 Convex의 구조가 Claude Code와 잘 맞았다고 설명한다. Convex의 쿼리는 데이터베이스 안에서 실행되는 TypeScript 함수이기 때문에, 에이전트가 별도의 쿼리 언어나 ORM과 SQL 사이의 변환을 배울 필요가 없었다. 에이전트는 스키마를 읽고 타입을 이해한 뒤 같은 언어 안에서 쿼리를 작성할 수 있었으며, 이 일관성이 MCP 통합을 부착된 보조 도구가 아니라 자연스러운 개발 흐름처럼 느끼게 했다. 애플리케이션과 데이터베이스 타입이 자동으로 연결되고, 프론트엔드부터 데이터베이스까지 같은 정의를 공유한다는 점이 AI 에이전트에게 특히 이상적인 표면으로 작용했다.

5. 자동 plan mode가 복잡한 작업에서 만든 차이

Claude Code의 plan mode는 에이전트가 바로 코드를 쓰기 전에 멈춰서 생각하고, 문제 범위를 잡고, 접근 방식을 제안하는 기능으로 설명된다. 중요한 차이는 Claude Code가 복잡성을 감지하면 자율적으로 plan mode에 들어갈 수 있다는 점이다. Cursor에도 plan mode가 있지만 사용자가 직접 호출해야 하므로, 사용자가 먼저 이 작업이 계획을 필요로 한다고 판단해야 한다. YouTube API에서 데이터를 가져오고, AI로 응답을 파싱하고, Convex에 저장한 뒤 프론트엔드에 노출하는 작업에서 Claude Code는 스키마 정의, action 작성, mutation 작성, query 연결을 순서대로 나누어 진행했고, 이 구조화된 사고가 여러 레이어를 넘나드는 디버깅 부담을 줄였다.

6. 도구 호출과 CLI 속도가 만든 생산성

빌드 과정에서 Claude Code는 필요한 순간에 적절한 도구를 사용하는 모습을 보였다. Convex CLI로 mutation을 실행하고, 브라우저 플러그인으로 시각적 결과를 확인하며, 문맥이 필요할 때 MCP 서버를 호출했다. 다만 글쓴이는 이것이 모델 자체의 능력인지, 모델을 둘러싼 오케스트레이션의 능력인지 분리해서 보기 어렵다고 지적하며, 현재는 전체 스택을 하나의 단위로 평가하고 있다고 말한다. 또한 터미널에서 아무 디렉터리에서나 claude를 입력하면 바로 작업을 시작할 수 있다는 점, IDE 로딩이나 확장 초기화, 코드베이스 인덱싱 대기가 없다는 점은 터미널 중심 개발자에게 큰 매력으로 제시된다.

7. 터미널 인터페이스의 한계와 Cursor의 UX 우위

Claude Code의 터미널 기반 인터페이스는 백엔드 중심 작업에서는 충분히 괜찮지만, 특정 워크플로에서는 분명한 마찰을 만든다. GUI에서는 메뉴, 버튼, 툴팁이 기능을 드러내지만 Claude Code에서는 문서를 읽거나 명령어를 우연히 알아내야 하므로 발견성이 떨어진다. 마우스 상호작용도 제한적이고, 개별 tool call을 클릭해 살펴보는 방식이 어렵고, 텍스트 선택이나 대량 붙여넣기 경험도 기대와 다르게 작동해 흐름을 늦춘다. 특히 스크린샷 붙여넣기가 안 되는 점은 프론트엔드 작업에서 큰 공백으로, Cursor처럼 보이는 문제를 이미지로 바로 전달하는 방식이 불가능하다는 점이 반복적인 불편으로 나타난다.

8. 모델 전환, 메시지 큐잉, 비용 통제 문제

글쓴이가 지적한 핵심 불편 중 하나는 /model 명령이 에이전트가 idle 상태일 때만 작동한다는 점이다. 작업 중에 다음 단계는 더 저렴한 모델로 충분하다고 판단해도 현재 작업이 끝날 때까지 기다려야 하며, 이는 빠른 반복 개발 흐름을 끊는다. 메시지 큐잉도 안정적이지 않아 에이전트가 작업 중일 때 보낸 메시지가 나중을 위해 쌓이기보다 현재 작업을 방해할 수 있다고 설명한다. Cursor에서는 메시지를 자유롭게 큐에 넣고 필요할 때 Alt+Enter로 즉시 개입할 수 있어, 개발자가 에이전트보다 몇 단계 앞서 생각하는 실제 사고 방식에 더 잘 맞는다고 평가된다.

9. 비용과 Convex 코드 작성 결과

이번 앱을 만드는 데 든 총비용은 60달러였고, 이는 Claude Code 구독 20달러와 추가 API 크레딧 40달러로 구성됐다. 글쓴이는 수작업 개발 시간을 대체했다는 관점에서는 비싸지 않지만, Cursor에서 같은 프로젝트를 진행했을 때보다 비쌀 가능성이 있다고 본다. 이유는 모델 전환이 어려워 변수명 변경, 보일러플레이트 작성, lint 오류 수정 같은 간단한 작업에도 Opus 4.5를 계속 쓰게 되기 때문이다. 그럼에도 Claude Code는 rules 파일이나 템플릿 없이 Convex 쿼리, mutation, ctx.db.query, ctx.db.insert, Convex CLI 사용, reactive query 개념을 올바르게 다뤘고, Convex가 TypeScript 기반으로 일관된 개발 모델을 제공한다는 점이 이 성과를 가능하게 했다.

🧾 핵심 주장 / 시사점

• Claude Code의 강점은 단순히 모델 성능이 아니라 플러그인, MCP, plan mode, CLI 속도가 결합된 agent-first 오케스트레이션에서 나온다.
• Convex처럼 타입, 스키마, 백엔드 로직이 TypeScript 안에서 일관되게 이어지는 플랫폼은 AI 에이전트가 실수할 여지를 줄이고 자기 검증 루프를 만들기 쉽다.
• 실제 일상 도구로 쓰려면 코드 생성 능력만큼이나 모델 전환, 메시지 큐잉, 시각 자료 전달, 비용 제어 같은 작업 흐름의 세부 UX가 중요하다.

✅ 액션 아이템

• 실험 데이터에서 확인한 Convex 기반 TypeScript 풀스택에서는 Claude Code의 플러그인 확장성, MCP 검사, plan mode 장점을 우선 적용할 범위를 정한다.
• 터미널에서 기능 발견성, 마우스 조작, 스크린샷 전달, 모델 전환, 메시지 큐잉이 흐름을 끊는 구간을 작업 유형별로 구분해 제약 조건을 정의한다.
• 총비용 60달러 구조와 Opus 4.5 반복 사용 경향을 반영해 간단 작업의 모델 선택 규칙과 지출 상한을 정한다.

❓ 열린 질문

• CLI 기반 UI 반복 작업에서 흐름이 끊길 때 Cursor로 전환해야 하는 판단 기준은 어디로 둘 것인가?
• Convex 중심 TypeScript 환경에서 Claude Code의 데이터베이스 검사/plan mode 이점이 실제 성과로 확인될 때 비교 지표는 무엇인가?
• 모델 전환 비용과 메시지 큐잉 지연을 분리해 확인하려면 어떤 실행 로그를 우선 모니터링해야 하는가?