Claude Code 프롬프트 실험 (3/4) — 스킬 에이전트까지 투입하면?

이 시리즈는

Claude Code에 같은 앱을 만들되, 프롬프트를 어떻게 넣느냐에 따라 결과가 얼마나 달라지는지를 실험한 기록입니다.

1편에서는 10분 만에 "동작은 하지만 빈틈이 있는" 결과가 나왔고, 2편에서는 자기검증과 사용자 피드백을 더해 50분 만에 안정성이 올라간 결과를 얻었습니다.

이번에는 스킬 에이전트라는 요소를 추가합니다. Claude Code가 스스로 필요한 전문 도구(스킬)를 찾아서 설치하거나 만들어서 사용하도록 한 것입니다.

스킬 에이전트란?

Claude Code에는 "스킬"이라는 개념이 있습니다. 특정 영역(TDD, UI 패턴, 테스팅 등)에 대한 가이드라인과 절차를 정의해둔 파일입니다. 스킬이 있으면 Claude Code가 해당 영역의 작업을 할 때 더 체계적으로 진행할 수 있습니다.

1편과 2편에서는 사용자가 미리 세팅해둔 기본 설정(TDD, 클린 아키텍처)만 있었습니다. 이번에는 프롬프트에서 "필요한 스킬을 알아서 찾아서 설치하거나 만들어서 진행해줘"라고 지시했습니다.

실험 조건

• Claude Code 기본 세팅: TDD + 클린 아키텍처 + 자기검증 (모두 활성)

• 스킬 에이전트: 활성 — 필요한 스킬을 스스로 탐색/설치/생성

• 사용자 피드백: 없음 (기능 추가 요청 안 함)

• 총 소요시간: 약 2시간 20분 (1편의 약 14배, 2편의 약 3배)

프롬프트 #1 — 리서치 + 계획 + 스킬 탐색

간단한 todo프로그램을 만들고 싶어. 대신 디자인과 기능은 상업용 프로그램의 퀄리티로 만들고 싶어. 구현에 필요한 리서치를 자세하게 하고 그걸 토대로 구현 계획을 세워줘. 그리고 계획부터 구현까지 필요한 에이전트와 스킬이 있는지 알아보고 필요한 에이전트와 스킬을 설치하거나 만들어서 진행해줘. 대신 모든 과정은 자기검증을 하고 수정할 필요가 없을 때까지 반복을 한 후 진행해줘.

1편, 2편과 비교했을 때 핵심 차이는 "필요한 에이전트와 스킬이 있는지 알아보고 필요한 에이전트와 스킬을 설치하거나 만들어서 진행해줘"라는 부분입니다.

Claude Code가 한 일

리서치 — 1편, 2편과 마찬가지로 상용 앱 분석 + 기술 스택 조사를 병렬로 진행했습니다. 기술 스택은 이번에는 Vite 8 + React 19를 선택했습니다 (2편은 Next.js 16이었음).

스킬 마켓플레이스 검색 — SkillsMP 마켓플레이스에서 관련 스킬을 검색했습니다. ui-styling, vitest, react-testing, tdd 등 4개 스킬을 발견했습니다.

스킬 보안 검증 시도 — 마켓플레이스 스킬의 소스코드를 검증하려 했으나, GitHub 접근이 차단되어 있어 직접 확인이 불가능했습니다.

결국 커스텀 스킬 직접 제작 — 외부 스킬 대신 프로젝트에 최적화된 커스텀 스킬 2개를 직접 작성했습니다:

• tdd-workflow — TDD 레드-그린-리팩터 절차와 도메인별 테스트 전략

• ui-patterns — 상용 수준 UI 컴포넌트 패턴과 접근성 가이드

계획 수립 — 클린 아키텍처 본격 적용

1편, 2편과 달리 4계층 클린 아키텍처를 명시적으로 설계했습니다:

domain/          → 순수 TypeScript, 외부 의존성 0
application/     → 유스케이스, domain만 의존
infrastructure/  → Dexie.js, 외부 구현
presentation/    → React UI

10단계 Phase로 구현 계획을 수립하고, 자기검증에서 수정 사항 없음을 확인한 뒤 진행했습니다.

구현 과정 — TDD로 도메인부터 쌓아올리기

이전 테스트들과 가장 큰 차이는 구현 순서입니다.

1편과 2편에서는 프로젝트 초기화 후 바로 UI 컴포넌트를 만들기 시작했습니다. 이번에는 도메인 레이어부터 TDD로 시작합니다.

Phase 1: Domain Layer — 72개 테스트

UI가 아닌 비즈니스 로직부터 만들었습니다:

• 값 객체: Priority, DueDate, TodoId, ProjectId, SortOrder

• 엔티티: Todo, Project, Subtask (불변 객체)

• 도메인 서비스: TodoFilterService, TodoSortService, SearchService

외부 의존성 0. 순수 TypeScript로만 작성하고, 72개 테스트로 검증.

Phase 2: Application Layer — 26개 테스트

유스케이스(CreateTodo, UpdateTodo, CompleteTodo 등)를 작성하고, InMemory 모킹으로 테스트.

Phase 3: Infrastructure Layer — 8개 테스트

Dexie.js(IndexedDB) 저장소를 구현하고, fake-indexeddb로 테스트.

Phase 4~8: UI + 통합

DI 컨테이너, Zustand 스토어, React 컴포넌트, React Router, shadcn/ui 통합, 다크모드, 키보드 단축키 11개, Undo 토스트, 애니메이션까지 구현.

최종: 107개 테스트 전체 통과, 빌드 성공.

1차 리뷰 — 직접 사용해본 결과

스크린캡쳐는 UX 개선과 자기검증 반복까지 완료된 최종 결과만 남아있습니다.

기능적으로 동작은 나쁘지 않았지만 몇 가지 문제가 있었습니다:

• 단축키 J/K(태스크 이동)가 동작하지 않음

• 사이드바 명칭이 "수신함"으로 되어 있어 어색함 — 일반적인 TODO 앱에서 쓰는 "Inbox" 같은 표현이 아님

• / 단축키가 검색 포커스만 줄 뿐, 바로 검색어 입력으로 이어지지 않음

• 할 일 추가 시 우선순위/날짜/반복을 바로 설정할 수 없고, 등록 후 상세를 열어야 함

• 기능 추가를 요청하지 않아서인지 캘린더 뷰가 구현되지 않음 — 2편에서는 사용자 피드백으로 요청해서 나왔던 기능

추가 프롬프트 — UX 개선 + 자기검증 반복

1편, 2편과 동일한 프롬프트를 넣었습니다:

지금 간단하게 몇가지 문제점이 있어. 우선 사용자의 관점에서 어떻게 하면 더욱 편하게 사용할지에 대해서 검색을 하고 UI/UX를 변경해줘.

이후 "자기검증을 수정할 내용이 없을 때까지 반복해줘"까지 지시했습니다.

자기검증 5회 반복 결과

최종: 109개 테스트 전체 통과, tsc/빌드 에러 0건, 자기검증 이슈 0건.

최종 결과

ALT

Google 중국 달력의 스크린샷

2차 리뷰

잘된 점:

• Q를 입력하면 바로 할 일 등록이 가능 (수신함, 오늘, 완료됨에서 동작)

• 날짜와 시간 입력이 편함

• 화살표 위/아래 키로 태스크 이동 가능 (J/K 대체)

• 한국어 UI — "수신함", "오늘", "예정", "완료됨"으로 표시. 다른 테스트는 영어였음

• 우선순위 뱃지("긴급")가 태스크에 인라인으로 표시되고, 해당 행에 배경색이 적용됨

• 사이드바 하단에 단축키 힌트가 표시됨

• 전체적으로 기능적인 큰 문제 없음

여전히 아쉬운 점:

• "예정" 메뉴에서만 Q 단축키가 동작하지 않음 — 다른 메뉴에서는 되는데 이 메뉴에서만 안 됨

• J/K 단축키는 여전히 동작하지 않음 — 1편의 N키, 2편의 Q키에 이어 3편의 J/K까지. 단축키 미동작은 모든 테스트의 공통 문제

• 할 일 등록 시 날짜/우선순위를 바로 설정할 수 없음 — 등록 후 클릭해서 상세를 열어야 수정 가능

• 캘린더 뷰 없음 — 사용자가 요청하지 않으면 나오지 않음 (2편에서는 요청해서 구현됨)

3개 테스트 비교 (1편 vs 2편 vs 3편)

스킬 에이전트가 가져온 차이

코드 품질 면에서는 확실한 차이가 있었습니다:

• 도메인부터 TDD로 쌓아올린 구조 (109개 테스트)

• 클린 아키텍처 4계층 분리 (도메인에 외부 의존성 0)

• 자기검증에서 발견된 13건을 전부 수정 (2편은 21건 중 19건)

하지만 사용자 관점에서 체감하는 차이는 제한적이었습니다:

• 단축키 미동작 문제는 여전

• 할 일 등록 시 속성 바로 입력 불가

• 캘린더 뷰는 사용자가 말하지 않으면 나오지 않음

• 2시간 20분이라는 시간 대비, 1편의 17분짜리 결과와 사용자가 체감하는 완성도 차이가 크지 않음

이 테스트에서 알 수 있는 것

1. 스킬 에이전트는 "코드 품질"에 효과적입니다. 테스트 109개, 클린 아키텍처, 자기검증 완전 해소. 코드를 유지보수하거나 확장해야 하는 상황이라면 의미 있는 차이입니다.

2. 하지만 "사용자가 보는 결과물"에는 큰 차이를 만들지 못했습니다. 단축키 미동작, 기능 부재(캘린더) 같은 문제는 코드 품질과 무관한 영역입니다.

3. 사용자 피드백의 부재가 느껴집니다. 2편에서는 "캘린더 넣어줘, 반복 작업 넣어줘"라는 한 마디가 기능 범위를 결정했습니다. 이번에는 그 피드백이 없어서 캘린더가 빠졌습니다. 스킬 에이전트가 사용자의 요구를 대체하지는 못합니다.

4. 시간 투자 대비 효과의 한계가 보입니다. 17분 → 50분 → 2시간 20분으로 시간이 늘었지만, 사용자 체감 품질이 비례해서 올라가지는 않았습니다.

다음 글 예고

마지막 글(4/4)에서는 세 테스트의 결과를 한 곳에 놓고 종합 비교합니다. 프롬프트, 시간, 기능, 버그, 코드 품질을 모두 대조하고, "Claude Code를 어떻게 쓰는 것이 가장 효율적인가"에 대한 결론을 내려보겠습니다.