EP.2 (2025-Q3)

바이브 코딩, 아직도 Cursor만 쓰시나요?

Simon Jo
June 15, 2025

1. 전제조건
2. 실험 과정
- 파일 구조 및 생성 테스트
- 핵심 로직 구현 능력 (Google OAuth 및 북마크)
3. 실험 결과
- Augment Code

오늘은 Ep.1에서 구체화한 기획을 바탕으로 실제 코드 작성을 시작하는, 가장 설레는 단계입니다.

옛날 같았으면 반나절은 꼬박 걸렸을 프로젝트 초기 세팅. 이제는 AI가 대신해 줄 거란 기대감과 함께 요즘 가장 주목받는 바이브 코딩 IDE 2대장(Cursor, Windsurf)을 소환해 성능을 테스트해봤습니다. 그리고 개인적으로 추천받은 Augment Code도 같이 테스트를 해볼 생각입니다.

결론부터 말하자면, 예상과 다른 의외의 결과가 나왔습니다.

1. 전제조건

정확한 비교를 위해, 아래와 같은 몇 가지 규칙과 환경을 설정했습니다.

Free Plan !
동일한 커서 룰(Cursor Rule) 사용
- 최고의 AI 코드 생성을 위해서는 '프롬프트 엔지니어링' 이 필수입니다. 저희는 Cursor.Directory에 공개된, 크롬 확장 프로그램 개발용 프롬프트 규칙을 동일하게 사용했습니다.
- Cursor.Directory란?
  - Cursor 사용자들이 특정 작업을 매우 높은 퀄리티로 수행하기 위해 만든 일종의 '프롬프트 레시피 모음집'입니다. 검증된 규칙을 사용함으로써 AI의 성능을 최대한으로 끌어올릴 수 있습니다.

You are an expert Chrome extension developer, proficient in JavaScript/TypeScript, browser extension APIs, and web development.

Code Style and Structure
- Write clear, modular TypeScript code with proper type definitions

...

Output Expectations
- Provide clear, working code examples

동일한 프롬프트 사용
- EP.1 (2025-Q3) 아이디어는 어떻게 돈이 되는 기획으로 바뀔까(지난 기획)를 기반으로, GPT-4o의 도움을 받아 모든 AI에게 동일하고 상세한 명세의 프롬프트를 전달했습니다.

You are an expert Chrome-extension engineer.

**TASK**  
Create a production-ready Vite project that builds a **Manifest v3** extension with the specs below.

──────────────────────────
1. TOOLING
──────────────────────────
• Vite + React + TypeScript  
• **vite-plugin-web-extension**  (⚠ crxjs NO; use this plugin)  
• TailwindCSS (utility-first, minimalist)  

──────────────────────────
2. MVP FEATURES  
──────────────────────────
A. **Social Login (Google OAuth) — gating**  
   – On first open, show a minimal login screen (Google One-Tap or OAuth popup).  
   – Store basic profile `{ uid, name, avatar }` in `chrome.storage.sync.user`.  
   – All other UI hidden until login success.

B. **Bookmark Save / Delete**  
   – “Save Current Tab” → push `{url, title, ts}` into `chrome.storage.sync.bookmarks`.  
   – List renders newest first; each row has a small “×” icon for delete.

C. **Search (Dummy Results)**  
   – Top search bar filters the local list **AND** shows a separate section “Coming Soon – AI Search”.  
   – For now, return **dummy array** from `src/lib/searchMock.ts`.  
   – **Architecture hook**: expose `searchBookmarks(query): Promise<Result[]>` in `src/api/index.ts` so future API swapping is one-line.

──────────────────────────
3. PROJECT STRUCTURE
──────────────────────────
├── vite.config.ts        (vite-plugin-web-extension config)  
├── public/manifest.json  
└── src  
    ├── background/index.ts (service-worker)  
    ├── popup/Popup.tsx    (main UI)  
    ├── options/Options.tsx (simple settings)  
    ├── lib/searchMock.ts  
    └── api/index.ts       (future real API placeholder)

──────────────────────────
4. SCRIPTS
──────────────────────────
• `dev`   - hot-reload extension  
• `build` - production zip

──────────────────────────
5. OUTPUT FORMAT
──────────────────────────
↳ For **each file**, print exactly:  
```markdown
// path/filename
```ts
// code here

로컬 개발 환경 기반 (⭐ 중요)
- 저는 개발자 백그라운드를 가지고 있어, 생성된 코드를 언제든 직접 열어보고 즉시 수정하는 방식을 선호합니다. 이러한 이유로 Replit, Lovable, v0.dev와 같이 웹 브라우저 기반으로 동작하여 코드 수정의 자유도가 상대적으로 낮거나 복잡한 툴들은 이번 비교 대상에서 처음부터 제외했습니다.
기본 템플릿 위에서 시작 (⭐ 중요)
- 완전한 제로 베이스(빈 폴더)에서 프로젝트 생성을 시도한 결과는 모두 실패였습니다. 모든 AI Agent가 실행조차 되지 않는 프로젝트를 뱉어냈습니다.
- 이를 통해 얻은 다시한번 스스로 확인했습니다.
  - '해줘' 식의 바이브 코딩은 아직 어림도 없다는 걸 다시 한번 뼈저리게 느꼈습니다.
- Vite Plugin Web Extension을 사용해 아주 기본적인 Vite + React + TS + Manifest V3 보일러플레이트(코드 템플릿)을 미리 만들어두고, 그 위에서 AI가 코드를 '추가'하도록 방향을 수정했습니다. 제대로 된 결과물을 원한다면, AI를 위한 최소한의 프레임은 만들어 줘야합니다.
디자인 및 인터랙션은 제외
- 프롬프트에 '미니멀리즘 + 스몰 인터랙션' 같은 디자인 가이드를 포함했지만, 현재 AI가 이와 같은 추상적인 요구사항을 시각적으로 만족스럽게 구현하지 못할 것이라 생각합니다. 이 부분은 추후 직접 개발하기로 하고 이번 실험의 평가 항목에서는 제외했습니다.

2. 실험 과정

파일 구조 및 생성 테스트

첫 번째 테스트는 프롬프트에 명시한 프로젝트 구조를 얼마나 정확하게 생성하는지 확인하는 것입니다. 요구사항은 popup, background, api, lib 등의 명확한 폴더 구조를 갖추는 것이었습니다.

Cursor & Windsurf, Augment Code
- 3가지 툴 모두 프롬프트에 작성된 기본적인 폴더 구조를 생성하는 데에는 문제가 없었습니다.
Augment Code: 프롬프트에 명시된 폴더 구조뿐만 아니라 사용하는 언어, 프레임워크에 필요한 파일, 폴더를 추가적으로 만들어주어, 이 테스트의 목표를 200% 달성했습니다.

핵심 로직 구현 능력 (Google OAuth 및 북마크)

두 번째 테스트는 확장 프로그램의 핵심 기능인 구글 로그인, 북마크 저장/삭제 등의 로직을 Popup.tsx 파일 내에 얼마나 잘 구현하는지 확인하는 것입니다.

Cursor, Windsurf

모든 기능이 하나의 거대한 컴포넌트 안에 들어가 있는 'All-in-One' 방식

const Popup: React.FC = () => {
  // ... 모든 state 선언

  useEffect(() => { /* ... */ }, []);

  const handleLogin = async () => {
    // 컴포넌트 내부에 OAuth 인증 로직이 그대로 노출됨
    try {
      const authResult = await chrome.identity.getAuthToken({ interactive: true });
      const response = await fetch(/* ... */);
      // ...
    } catch (error) { /* ... */ }
  };

  // ... handleSaveBookmark, handleDeleteBookmark 등 모든 함수가 내부에 존재

  if (!user) {
    return ( /* 로그인 UI */ );
  }

  return ( /* 메인 UI */ );
};

API 호출, 상태 관리, 이벤트 핸들러 등 모든 로직이 한 파일에 섞여 있어 유지보수가 매우 어려워 보입니다. 아키텍처 측면에서는 아쉬움이 많이 남는 결과물입니다.

Augment Code

생성된 코드의 양은 Cursor&Windsurf의 1.5~2배에 달했지만, 그 이유는 훨씬 더 체계적이고 모듈화된 구조를 갖추고 있기 때문이었습니다.

import { AuthManager } from '../utils/auth';
import { StorageManager } from '../utils/storage';
import { BookmarkAPI } from '../api';

const Popup: React.FC = () => {
  const [authState, setAuthState] = useState<AuthState>({ /* ... */ });
  // ...

  // 각 기능이 별도의 함수로 깔끔하게 분리됨
  const initializePopup = async () => {
    const user = await AuthManager.getCurrentUser();
    // ...
  };

  const handleSignIn = async () => {
    const user = await AuthManager.signInWithGoogle();
    // ...
  };

  const handleSaveCurrentTab = async () => {
    // 백그라운드 스크립트와 통신하여 역할을 분담
    const response = await chrome.runtime.sendMessage({ type: 'SAVE_CURRENT_TAB' });
    // ...
  };
};

AuthManager, StorageManager, BookmarkAPI처럼 관심사를 명확하게 분리하여 외부 모듈에서 기능을 가져와 사용하는 것을 볼 수 있습니다. 이는 제가 프롬프트에서 요청했던 '아키텍처 설계 의도'를 완벽하게 파악하고 실행한 결과입니다. 코드의 양이 많은 것은 불필요한 코드가 아니라, 더 나은 구조를 위해 필요한 '좋은 코드'입니다. 바로 이 지점에서 Augment Code가 진짜 '코딩 에이전트'에 가깝다고 느꼈습니다.

3. 실험 결과

솔직히 말해, 결과는 '예상 밖'이라는 말로는 부족할 정도로 명확하고 일방적이었습니다.

Augment Code

최종 승자는 Augment Code 입니다. 단순히 '가장 나았다'는 수준이 아니라, 다른 경쟁자들과는 완전히 다른 결과물을 보여주었습니다.

그렇다면 이런 압도적인 차이는 어디서 비롯된 걸까요? 저는 각 AI의 '모델 운용 철학' 에서 그 답을 찾을 수 있었습니다.

Cursor는 작업에 맞춰 최적의 모델을 자동으로 골라주는 'Auto-select' 기능을, Windsurf는 'Claude 3.7 Sonnet과 유사한 성능'이라고 주장하는 자체 모델(SWE-1)을 내세웁니다. 분명 훌륭한 모델을 사용하는 것은 맞지만, 결과적으로는 복잡한 태스크를 해결하는 '능력'으로 이어지진 못했습니다. 좋은 엔진을 얹어두었지만, 그 엔진을 제어하는 드라이버의 실력은 아쉬운 격이었죠.

반면 Augment Code의 철학은 정반대입니다. 그들은 공식 문서에서 "AI 모델 선택은 사용자의 고민이 아니라 우리의 책임" 이라고 단언합니다. 사용자에게 모델 선택권을 주는 대신, 주어진 태스크의 난이도와 맥락을 스스로 판단해 내부적으로 수많은 모델 중 최적의 도구를 동적으로 선택하고 조합합니다. 이는 마치 뛰어난 프로젝트 매니저가 여러 전문가 팀원들에게 가장 적합한 업무를 분배하는 것과 같습니다. 결국 이 '진짜 에이전트'처럼 동작하는 접근 방식이, 단순히 좋은 모델을 가져다 쓰는 것보다 훨씬 더 높은 차원의 결과물을 만들어내는 핵심 비결이 아닌가 싶습니다.

오늘 뉴스레터, 도움이 되었을까요?
💬 질문이나 제안은 언제든 환영합니다

🎥 YouTube 바로가기

— Simon Jo | SwitchUP AI

Reply

or to participate.