Notice

Recent Posts

Recent Comments

Link

250x250

« 2025/08 »
일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

Tags more

Archives

Today

Total

관리 메뉴

몸과 마음이 건전한 SW 개발자

[인공지능] Claude Code VS Cursor AI 본문

인공지능

[인공지능] Claude Code VS Cursor AI

스위태니 2025. 8. 11. 12:40

728x90

커서(Cursor)

커서는 AI를 활용한 코드 작성 및 편집 도구로, 개발자가 코드를 빠르게 작성하고 수정할 수 있도록 지원한다. 특히 반복 작업의 자동화와 다양한 AI 모델의 통합이 강점이다.

장점

1. Tab 기능

기계적 작업 자동화: 탭(Tab) 키를 활용해 반복적인 코딩 작업을 빠르게 수행 가능. 예를 들어, 비슷한 패턴의 코드를 여러 번 작성해야 할 때, 탭 키로 자동 완성 및 생성을 지원.
코드 분석 기반 즉시 작성: 기존 코드베이스를 분석한 상태로 동작하므로, 사용자가 원하는 코드를 맥락에 맞게 즉시 생성. 이는 프로젝트의 일관성을 유지하는 데 유용.
- 예: 특정 함수나 컴포넌트의 구조를 파악한 후, 비슷한 구조의 코드를 자동으로 제안.

2. 여러 모델 사용 가능

커서는 다양한 AI 모델을 통합적으로 사용 가능:
- Claude: Anthropic의 모델로, 코드 생성 및 자연어 처리에 강점.
- GPT: OpenAI의 모델로, 범용적인 코드 작성 및 문제 해결에 유용.
- Gemini: Google의 모델로, 특정 작업에 최적화된 성능 제공.
장점: 사용자는 작업의 성격에 따라 적합한 모델을 선택하거나, 여러 모델을 조합해 문제를 해결 가능. 예를 들어, Claude로 코드 구조를 잡고, GPT로 세부 로직을 작성.
단점: 모델 간 전환 시 일관성 문제가 발생할 가능성 있음(예: 코드 스타일 차이).

3. 개별 수정 기능

수정 단위별 Accept 버튼: 코드 수정 시 변경된 부분마다 Accept 버튼이 제공되어, 사용자가 원하는 수정만 선택적으로 적용 가능.
직관적 변경 구분: 수정된 부분과 기존 코드가 명확히 구분되어 표시. 이는 디버깅이나 코드 검토 시 가독성을 높임.
- 예: 특정 함수만 수정하고 나머지는 유지 가능.
장점: 세밀한 코드 제어가 가능하며, 대규모 수정 시 실수를 줄이는 데 효과적.

단점

모델 의존성: 여러 모델을 사용 가능하지만, 특정 모델의 성능에 의존할 경우 결과물의 품질이 달라질 수 있음.
제공된 정보 부족: 사용량 제한이나 구독 플랜에 대한 정보가 없어, 비용 효율성을 판단하기 어려움.

클로드(Claude) 코드

클로드는 Anthropic에서 개발한 AI 모델로, 코드 생성 및 수정에 특화된 기능을 제공한다. 특히 Sonnet 4.0과 Opus 모델을 활용해 꼼꼼하고 정밀한 코드 작업을 지원한다. 제공된 정보에 따르면, 클로드는 특정 구독 플랜(Pro, Max)에 따라 사용량과 기능이 달라진다.

장점

1. claude sonnet 4.0

기본 모델: Sonnet 4.0이 디폴트로 설정되어 있어, 별도 설정 없이 고성능 코드 생성 및 수정 가능.
성능: 코드 이해와 생성에서 높은 정확도를 제공하며, 일반적인 개발 작업에 적합.
- 예: 중소 규모 프로젝트의 컴포넌트 작성, 디버깅, 리팩토링.
장점: 별도 설정 없이 바로 사용 가능하며, 안정적인 성능을 보장.

2. claude opus

고급 모델: Max 구독 플랜에서 사용 가능. 대규모 코드 수정이나 복잡한 프로젝트에 최적화.
빠른 이해 및 수정: 대량의 코드베이스를 빠르게 파악하고, 일관성 있는 수정 제안.
- 예: 레거시 코드 리팩토링, 복잡한 DOM 구조 수정.
장점: 대규모 작업에서 시간 절약 가능. 특히 복잡한 구조의 코드를 한 번에 처리할 때 유리.

3. ToDo

꼼꼼한 문제 해결: ToDo 리스트를 기반으로 문제를 체계적으로 분석하고 해결.
- 예시: 제공된 코드 블록에서 DOM nesting 에러를 단계적으로 해결.
  - 문제 식별: Typography 컴포넌트의 <p> 태그 내 <div> 중첩 문제 발견.
  - 해결 과정:
    1. ToDo 리스트 작성(문제 찾기, 수정, 테스트).
    2. 코드 분석(165번째 줄의 문제 확인).
    3. 수정 제안(Typography를 Box로 변경, 색상 및 스타일 조정).
    4. ToDo 업데이트 및 완료 보고.
  - 결과: 올바른 DOM 구조로 수정 완료, 에러 해결.
- 코드 예시

● 이 에러는 HTML DOM 구조 규칙 위반 때문입니다. <p> 태그 안에 <div> 태그가 들어가면       
  안 되는데, Typography 컴포넌트가 기본적으로 <p> 태그를 렌더링하고 그 안에 Grid나        
  div가 포함되어 있어서 발생합니다.

● Update Todos
  ⎿  ☐ Find the DOM nesting issue in onedb page components
     ☐ Fix Typography component with nested div elements
     ☐ Test the fix

● 에러 스택을 보면 TopListBox 컴포넌트에서 문제가 발생하고 있습니다. 이 컴포넌트를        
  확인해보겠습니다:

● Read(src\views\components\box\top-list-box.tsx)
  ⎿  Read 216 lines (ctrl+r to expand)

● 문제를 찾았습니다! 165번째 줄에서 Typography 컴포넌트 안에 Link가 있고, 그 Link
  안에 다시 Stack과 Typography가 중첩되어 있습니다. Typography는 기본적으로 <p>
  태그로 렌더링되는데, 그 안에 <div> (Stack)가 들어가면 DOM 규칙 위반입니다.

● Update Todos
  ⎿  ☒ Find the DOM nesting issue in onedb page components
     ☐ Fix Typography component with nested div elements
     ☐ Test the fix

● 이제 이 문제를 수정하겠습니다. Typography를 Box나 div로 바꾸거나, component prop을      
   사용해서 올바른 HTML 태그로 렌더링하도록 수정하겠습니다:

● Update(src\views\components\box\top-list-box.tsx)
  ⎿  Updated src\views\components\box\top-list-box.tsx with 4 additions and 3
     removals
       162                          textAlign={'start'}
       163                        >{`${data.category.categoryName} >
             ${data.category.child.categoryName}`}</Typography>
       164                        {sessionTypeChip(data)}
       165 -                      <Typography variant='body2' color={'primary'} 
     textAlign={'start'} sx={{ cursor: 'pointer' }}>
           - textAlign={'start'} sx={{ cursor: 'pointer' }}>
       165 +                      <Box sx={{ cursor: 'pointer' }}>
       166                          <Link
       167                            onClick={event => {
       168                              event.preventDefault()
       169
     router.push(`/onedb/content/${data.onedbId}`)
       170                            }}
       171 +                          color={'primary'}
       172                          >
       173                            <Stack direction={'row'} spacing={2}
             alignItems={'center'}>
       174 -                            <Typography variant={'Body2'} 
     fontWeight={600} textAlign={'start'}>
           - fontWeight={600} textAlign={'start'}>
       174 +                            <Typography variant={'Body2'} 
     fontWeight={600} textAlign={'start'} color={'primary'}>
           + fontWeight={600} textAlign={'start'} color={'primary'}>
       175                                {data.subject}
       176                              </Typography>
       177                              {data.hasAttachments && <Icon
             icon={'fa:paperclip'} style={{ flexShrink: 0 }}></Icon>}
     ...
       184                              )}
       185                            </Stack>
       186                          </Link>
       187 -                      </Typography>
       187 +                      </Box>
       188                      </Stack>
       189
       190                      <Typography variant={'body2'} minWidth={'80px'}>

● Update Todos
  ⎿  ☒ Find the DOM nesting issue in onedb page components
     ☒ Fix Typography component with nested div elements
     ☒ Test the fix

● 완료! DOM nesting 에러를 수정했습니다.

  문제:
  - Typography 컴포넌트(기본적으로 <p> 태그로 렌더링)
  - 그 안에 Link 컴포넌트가 있고
  - Link 안에 다시 Stack(div) 컴포넌트가 중첩되어 있음
  - HTML 규칙상 <p> 안에 <div>가 올 수 없음

  해결:
  - Typography를 Box로 변경 (<div>로 렌더링됨)
  - 텍스트 색상을 Link에 직접 적용
  - Typography 내부의 텍스트 색상을 명시적으로 설정

  변경 사항:
  // 이전 (잘못된 DOM 구조)
  <Typography variant='body2' color={'primary'}>
    <Link>
      <Stack>...</Stack> // ❌ p > a > div 구조
    </Link>
  </Typography>

  // 수정 후 (올바른 DOM 구조)
  <Box sx={{ cursor: 'pointer' }}>
    <Link color={'primary'}>
      <Stack>...</Stack> // ✅ div > a > div 구조
    </Link>
  </Box>

  이제 onedb 페이지에서 DOM nesting 경고가 더 이상 나타나지 않을 것입니다!

중간 저장 및 수정: 작업 중 Esc 키를 눌러 ToDo를 일시 중지하고, 필요한 부분만 수정 후 재개 가능.
장점: 체계적이고 투명한 워크플로우 제공. 복잡한 디버깅 시 작업 추적이 용이.

사용량 (월 기준)

Pro 플랜: Sonnet 4: 40 ~ 80시간
Max X5 플랜: Sonnet 4: 140 ~ 280시간, Opus: 15 ~ 35시간
Max X20 플랜: Sonnet 4: 800 ~ 1,600 시간

소넷 모델 기준 월 사용량 비교

커서 (Cursor) - Sonnet 4 기준

Pro ($20/월): 월 225회 요청
Pro+ ($60/월): 월 675회 요청
Ultra ($200/월): 월 4,500회 요청

클로드 (Claude) - 5시간마다 리셋 기준

월 사용량 계산 (30일 기준: 144번의 5시간 주기)

Pro ($20/월): 월 6,480회 메시지
- 5시간마다 45개 × 144주기 = 6,480개
Max 확장 ($100/월): 월 32,400회 메시지
- 5시간마다 225개 × 144주기 = 32,400개
Max 최대 ($200/월): 월 129,600회 메시지
- 5시간마다 900개 × 144주기 = 129,600개

결론

같은 $20 가격대에서:

커서 Pro: 월 225회
클로드 Pro: 월 6,480회

느낀점

코드 품질 측면에서의 우위

현재 시점(2025년 8월)에서 코드 개발에 있어 Claude Sonnet과 Opus를 능가하는 AI 모델은 없다고 단언할 수 있다. 특히 복잡한 로직 구현과 코드 구조 설계에서 보여주는 Claude의 성능은 압도적이다.

비용 효율성의 명확한 차이

이런 상황에서 자연스럽게 "어떤 플랫폼이 우수한 모델을 더 경제적으로 사용할 수 있게 해주는가?"라는 질문이 생긴다.

같은 $20 투자 기준:

Cursor Pro: 월 225회 사용
Claude Pro: 월 6,480회 사용 (약 29배 차이)

이는 단순히 숫자상의 차이가 아니다. 실제 개발 과정에서 반복적인 질문과 수정이 필요한 상황을 고려하면, Claude의 압도적인 사용량은 개발 속도와 직결된다.

일관성과 품질에 대한 기대

Claude의 또 다른 강점은 모델의 일관성이다. Cursor의 경우 여러 모델(Claude, GPT, Gemini)을 자동으로 전환하는 시스템이지만, 이로 인해 코드 스타일이나 접근 방식에서 일관성이 떨어질 수 있다.

반면 Claude는 Sonnet과 Opus라는 검증된 모델만을 사용하기 때문에, 프로젝트 전반에 걸쳐 일관된 코드 품질과 스타일을 유지할 수 있다.

실제 사용 경험을 통한 결론

3개월간의 Cursor 사용과 1개월간의 Claude 사용 경험을 비교해본 결과, 터미널 기반의 Claude 환경이 다소 불편함에도 불구하고 다음과 같은 이유로 Cursor 구독을 취소하게 되었다:

Claude의 장점

압도적인 비용 효율성 (29배 많은 사용량)
일관된 고품질 모델 사용
체계적인 문제 해결 접근법 (ToDo 시스템)
정확한 코드 분석과 수정 제안

개발자로서의 최종 판단

결국 개발 도구는 생산성과 비용 효율성의 균형이 가장 중요하다. 터미널 환경의 불편함은 적응으로 극복할 수 있지만, 비용 대비 성능의 차이는 장기적으로 더 큰 영향을 미친다.

특히 개인 개발자나 스타트업처럼 예산에 민감한 환경에서는 Claude의 선택이 거의 필수적이라고 생각한다. 같은 예산으로 29배 많은 AI 어시스턴스를 받을 수 있다는 것은, 곧 더 많은 실험과 더 빠른 개발 사이클을 의미한다.