DEV

Published on

LeetCode 문제풀이를 블로그에 자동 연동하는 시스템 구축기 #3

Authors
  • avatar
    Name
    Charles

시리즈 목차

  1. 시스템 아키텍처 설계와 기술 스택 선택
  2. 데이터베이스 스키마 설계와 자동화 파이프라인 구축
  3. AI 페어 프로그래밍의 현실 ← 현재 글
  4. 성능 최적화와 사용자 경험 개선 (예정)

들어가며

지난 포스팅에서 LeetCode 자동화 시스템의 핵심 파이프라인이 완성되었고, 이제 jin-blog 프로젝트와의 연동 단계에 들어섰습니다. LeetCode 문제 해설 페이지를 구축하면서, Claude Code와 함께 AI 페어 프로그래밍을 적극적으로 활용했습니다. "AI와 함께라면 개발 속도가 정말 빨라질까?"라는 기대와 함께 시작했는데, 실제 경험을 통해 얻은 현실적 인사이트를 공유합니다.

TL;DR: AI 도구는 분명 개발 속도를 향상시키지만, "5~10분이면 뚝딱" 같은 과장된 기대보다는 현실적인 활용법을 이해하는 것이 중요합니다.

🚀 AI 페어 프로그래밍의 장점들

1. $17 구독료 대비 높은 사용량, 하지만...

기존에 혼자 작업할 때와 비교해서 Claude Code와 함께 바이브 코딩을 진행하니 개발 시간이 확실히 단축되었습니다. 사용량을 보면 구독료 대비 훨씬 많은 작업을 처리해주었고, 특히 다음과 같은 작업들에서 큰 효과를 보았습니다:

// 예시: 컴포넌트 분리 작업
// 기존 269줄의 거대한 컴포넌트를 9개의 모듈로 분리
// Claude Code가 구조 분석부터 개별 컴포넌트 생성까지 도움

그러나 Rate limit으로 기다려야 하는 시간을 제외하고도 실제 개발에서는 상당한 속도 향상을 경험했습니다.

2. 마이그레이션 작업의 강력한 파트너

초기에 Tailwind CSS 설정에서 max-width 기반으로 반응형을 구축해놓았던 문제가 있었습니다. Tailwind는 기본적으로 min-width 기반의 '모바일 퍼스트(Mobile-first)' 방식을 권장합니다. 하지만 초기에 config에서 max-width 기준으로 잘못 셋팅해서, 새로운 화면마다 반응형이 꼬이는 문제가 있었습니다:

// tailwind.config.js - 잘못된 설정 (max-width 기반)
module.exports = {
  theme: {
    screens: {
      'lg': {'max': '1023px'},
      'md': {'max': '767px'},
      'sm': {'max': '639px'},
    }
  }
}

// 권장되는 기본 설정 (min-width 기반)
module.exports = {
  theme: {
    screens: {
      'sm': '640px',
      'md': '768px', 
      'lg': '1024px',
    }
  }
}

새로운 화면을 작업할 때마다 반응형이 엉망이 되는 문제를 발견하고, 이참에 전체적인 마이그레이션을 결정했습니다. AI가 없었으면 엄두도 못 낼 대량 수정 작업이었는데, Claude Code가 이 작업에서 정말 큰 도움이 되었습니다.

  • 패턴 인식: 잘못된 반응형 패턴을 자동으로 찾아서 제안
  • 일괄 변환: 수십 개 파일의 설정을 일관되게 수정
  • 검증: 변경 후 레이아웃이 깨지는 부분을 미리 체크

결과적으로 페어 프로그래밍처럼 Claude가 큰 부분을 처리하고, 제가 검토하면서 작업하는 방식으로 효율적으로 진행할 수 있었습니다.

3. 보안과 반복 작업의 든든한 조력자

보안 관련 작업에서 Claude Code는 정말 유용했습니다:

// 예시: 입력값 검증 로직
const validateLeetCodeInput = (data: unknown): LeetCodeProblem => {
  // Claude가 제안한 포괄적인 검증 로직
  if (!data || typeof data !== 'object') {
    throw new Error('Invalid input data');
  }
  
  // 타입 가드와 sanitization 로직들...
};

반복 처리 작업에서도 큰 힘을 발휘했습니다:

  • 비슷한 컴포넌트들의 타입 정의 자동 생성
  • Supabase 데이터베이스 마이그레이션 스크립트 작성 (2편에서 다룬 복잡한 스키마 변경 작업)
  • 테스트 케이스 패턴 생성
  • GitHub Actions 워크플로우 최적화 (2편에서 구축한 2-stage 파이프라인과 연계)

⚠️ 현실적인 한계들

1. Rate Limit - 가장 큰 걸림돌

가장 크다고 느낀 단점은 Claude Code의 rate limit입니다. 2편에서 언급했듯이 $17 구독료 대비 훨씬 많은 작업을 처리해주지만, 실제 사용성에서는 rate limit으로 인해 기본적으로 2시간 정도 기다려야 하는 시간이 발생했습니다.

실제 개발 패턴을 보면 이런 식이었습니다:

💡 실제 경험한 패턴:
11:00 - 오전에 집중적으로 작업 (1시간 40분 개발)
13:40 - Rate limit 도달 → 2시간 정도 대기...
16:00 - 오후에 다시 작업 재개  (1시간 50분 개발)
17:50 - 또 limit 도달 → 저녁까지 대기
21:00 - 저녁에 간신히 마무리

이런 식으로 개발 플로우가 자주 끊기는 것이 가장 아쉬웠습니다. 특히 디버깅 중에 limit에 걸리면 컨텍스트를 잃어버려서 다시 처음부터 설명해야 하는 경우도 많았습니다.

2편에서 경험한 "2일간 집중적인 바이브 코딩"의 단점이 실제 프론트엔드 개발에서도 동일하게 나타났습니다.

2. 효과적인 협업을 위한 커뮤니케이션 스킬

예전에 프로그래밍을 처음 배웠을 때 본 영상이 생각났습니다. **"컴퓨터에게 어떤 작업을 시킬 때는 아이에게 하나부터 열까지 순서대로 알려줘야 한다"**는 내용이었는데, AI와 협업할 때도 정확히 같은 느낌이었습니다.

협업 도구로서의 AI를 제대로 활용하려면, 단순히 명령어를 던지는 게 아니라 상호작용하는 파트너로 인식하고 소통해야 합니다.

문제 상황들:

  • 축약된 프롬프팅으로 작업을 요청했을 때 → 의도와 다른 결과
  • 모호한 요구사항 전달 → 여러 번의 수정 작업 필요
  • 컨텍스트 부족 → 기존 코드 스타일과 맞지 않는 결과물

효과적인 프롬프트 작성법:

❌ 나쁜 프롬프트:
"페이지네이션 6개로 바꿔줘"

✅ 좋은 프롬프트:
"LeetCode 문제 리스트에서 한 페이지당 표시되는 문제 수를 5개에서 6개로 변경해줘. 
- 메인 리스트 페이지와 상세 페이지의 관련 문제도 모두 6개로 통일
- constants.ts의 DEFAULT_PER_PAGE와 하드코딩된 값들도 찾아서 수정
- 페이지네이션 계산 로직도 확인해줘"

3. 여전히 필요한 인간의 검토

복잡도가 높지 않은 기능들임에도 불구하고, 원하는 결과물을 얻는 데까지 예상보다 시간이 걸렸습니다. "5~10분이면 뚝딱" 같은 과장된 기대와는 달리 현실적으로는:

  • 초기 결과물: 70-80% 완성도
  • 세부 조정: 2-3번의 추가 수정 필요
  • 통합 테스트: 전체 시스템과의 호환성 확인 필요
  • 스타일 통일: 기존 코드베이스와의 일관성 맞추기

🎯 실제 개발 과정에서의 사례들

사례 1: 마크다운 렌더링 이슈 해결

문제: 번호 목록이 이상하게 표시되는 버그 (2편에서 구축한 번역 시스템과는 별개의 렌더링 이슈)

1.
음수확인:

2.
제곱근계산:

AI와의 협업 과정:

  1. 🤖 Claude가 CSS 클래스 분석 및 문제점 파악
  2. 👨‍💻 내가 기존 MarkdownViewer와 비교 분석 요청
  3. 🤖 Claude가 list-inside → list-outside 해결책 제안
  4. 👨‍💻 내가 최종 검토 및 적용

결과: 30분 내 해결 (혼자였다면 문제 파악부터 1-2시간, CSS 디버깅까지 포함하면 더 오래 걸렸을 것)

사례 2: 컴포넌트 리팩토링

목표: 269줄의 거대한 컴포넌트를 모듈화

실제 시간 절약 효과:

  • 전체 작업 시간: 2시간 (AI 협업) vs 예상 6-8시간 (혼자 작업)
  • 컴포넌트 생성: 30분 vs 예상 3-4시간
  • 타입 정의: 15분 vs 예상 1-2시간

AI와 내가 나눈 역할:

🤖 Claude의 역할:
- 컴포넌트 분리 전략 제안
- 개별 컴포넌트 코드 생성  
- TypeScript 인터페이스 초안 작성

👨‍💻 내 역할:
- 아키텍처 방향성 최종 결정
- 컴포넌트 간 의존성 검토
- 네이밍과 디렉토리 구조 조정
- props 설계 및 타입 정제

결과:

  • 9개의 재사용 가능한 컴포넌트로 분리
  • 코드 라인 56% 감소
  • 유지보수성 대폭 향상

💡 AI 페어 프로그래밍 Best Practices

1. 명확한 요구사항 정의

✅ 효과적인 프롬프트 구조:
1. 배경 설명: 현재 상황과 문제점
2. 구체적 요구사항: 원하는 결과물
3. 제약 조건: 지켜야 할 규칙들
4. 예시: 기대하는 결과물의 샘플

2. 점진적 개선을 통한 주도권 교대

AI와의 협업에서 중요한 것은 각 단계별로 주도권을 적절히 나누는 것입니다:

Phase 1: 기본 틀 생성 (AI 주도)
→ "269줄 컴포넌트를 의미있는 단위로 쪼개줘"

Phase 2: 세부 요구사항 반영 (협업)  
→ AI 제안 → 내가 검토 → 수정 요청 → 재생성

Phase 3: 통합 테스트 및 최적화 (내가 주도)
→ props 타입 통일, 네이밍 일관성, 전체 구조 점검

실제 컴포넌트 분리 과정:

  1. AI에게 전체 구조 분석 요청 → 9개 컴포넌트 분리 제안 받음
  2. 개별 컴포넌트 생성 협업 → AI가 기본틀, 내가 props 설계
  3. 최종 통합 및 정제 → 타입 안전성, 재사용성 검토는 내가 직접

3. Rate Limit 우회 전략

  • 배치 작업: 한 번에 여러 유사한 작업을 요청
  • 시간 분산: 하루 중 여러 시간대에 나누어 작업
  • 우선순위: 중요한 작업을 먼저 처리

🔮 앞으로의 AI 활용 계획

단기 목표 (1-2개월)

  • 테스트 코드 작성에 AI 활용해보기
  • 문서화 작업에 AI 도입
  • 코드 리뷰 과정에서 AI 의견 참조

장기 목표 (6개월)

  • AI와의 협업 패턴 체계화
  • 프로젝트별 AI 활용 가이드라인 수립
  • 팀 단위 AI 도구 도입 검토

🤦‍♂️ 실패 경험: AI도 완벽하지 않다

Supabase 스키마 수정에서의 실수

상황: 2편에서 구축한 복잡한 테이블 구조에서 추가 컬럼을 수정하는 작업

내 요청: "examples 컬럼을 TEXT[]에서 JSONB로 변경해줘"

AI의 응답:

-- 위험한 코드 (데이터 손실 가능성)
ALTER TABLE leetcode_problems 
DROP COLUMN examples,
ADD COLUMN examples JSONB;

문제점: 기존에 저장된 수십 개의 LeetCode 문제 데이터가 모두 사라질 수 있는 위험한 마이그레이션 교훈: 데이터베이스 작업은 반드시 사람이 최종 검토해야 함

올바른 방식:

-- 안전한 마이그레이션 (2편에서 배운 교훈 적용)
ALTER TABLE leetcode_problems 
ADD COLUMN examples_new JSONB;
-- 기존 데이터 변환 및 검증
-- 검증 완료 후 기존 컬럼 제거

이런 경험을 통해 AI는 강력하지만 완벽하지 않다는 것을 깨달았습니다. 특히 2편에서 구축한 소중한 데이터를 보호하는 것의 중요성을 다시 한번 느꼈습니다.

마무리

AI 페어 프로그래밍은 만능 해결사가 아니라, 효율을 극대화할 수 있는 강력한 조력자에 가깝습니다. 과장된 기대보다는 현실적인 한계를 인정하고 나만의 활용법을 찾는 것이 장기적으로 훨씬 큰 경쟁력이 됩니다.

이 경험에서 얻은 핵심 인사이트:

  1. 개발 속도는 명확하게 빨라지지만, 완전 자동화는 아직 어렵다
  2. AI와 효과적으로 협업하려면 프롬프트 작성 등 커뮤니케이션 능력이 중요하다
  3. Rate limit 등 도구의 제약조건을 미리 고려해 작업 계획을 세우자
  4. 결국 최종 검토와 품질 판단은 사람의 몫이다

실제로 가장 큰 경쟁력 차이는 단순히 AI 도구를 쓰느냐 마느냐가 아니라, 어떻게 효과적으로 협업하느냐에서 나온다고 생각합니다.

나만의 활용 팁: 복잡한 작업일수록 AI에게 한 번에 모든 걸 맡기지 말고, 작은 단위로 쪼개서 단계적으로 진행하는 것이 성공률이 높았습니다. 특히 2편에서 경험한 "컨텍스트 엔지니어링"의 중요성을 프론트엔드 개발에서도 동일하게 적용할 수 있었습니다.

🔮 다음 단계 예고

현재까지 LeetCode 자동화 시스템의 핵심 인프라는 완성되었습니다:

  • ✅ 1편: 시스템 아키텍처 설계
  • ✅ 2편: 자동화 파이프라인 구축
  • ✅ 3편: AI 협업을 통한 프론트엔드 개발

하지만 실제 사용하다 보니 몇 가지 사용성 문제점들이 발견되고 있습니다. 다음 포스팅에서는:

4편: 실사용 문제점 발견과 Claude Code를 활용한 실시간 해결

🐛 발견된 주요 이슈들:

  1. 필터링 시 화면 일관성 문제

    • 현상: Hard 난이도 필터 적용 시 데이터 부족으로 검색 창이 사라지고 빈 화면 노출
    • 문제점: 사용자가 다른 필터를 시도하기 어려운 UX
    • 해결 예정: 빈 결과에서도 검색/필터 UI 유지하는 개선

  2. 번역 품질 불일치

    • 현상: 일부 LeetCode 문제의 영어→한글 번역이 누락되거나 부자연스러움
    • 문제점: 2편에서 구축한 OpenAI 번역 시스템의 일부 실패 케이스
    • 해결 예정: 번역 검증 로직 추가 및 기존 데이터 일괄 수정

  3. 블로그 전체 검색 기능 부재

    • 현상: LeetCode 페이지에만 검색이 있고, 전체 posts에는 필터링 기능 없음
    • 문제점: 사용자 경험의 일관성 부족
    • 해결 예정: 통합 검색/필터 시스템 구축

🛠️ Claude Code 활용 해결 과정:

  • 실시간 디버깅과 문제 해결 과정 공개
  • 각 이슈별 AI 협업 패턴과 효과적인 프롬프트 전략
  • Rate limit 제약 하에서의 효율적인 작업 진행법

📊 최종 완성도 검증:

  • 처음 목표했던 "GitHub에서 문제 찾기 번거로움" 해결 여부
  • 실제 사용 편의성 개선 전/후 비교
  • 전체 프로젝트 ROI 평가 (투입 시간 vs 실제 편의성 향상)

목표: "AI와 함께 완성도를 높여가는 실제 협업 과정"을 솔직하게 다뤄보겠습니다.