Claude Code 프롬프트 실험 (2/4) — 자기검증 + 사용자 피드백을 더하면?

이 시리즈는

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

1편에서는 자기검증을 끄고 프롬프트 2개만으로 맡겼습니다. 결과는 "겉보기엔 괜찮지만 실사용 시 빈틈이 보이는" 수준이었습니다.

이번에는 자기검증을 켜두고, 계획 단계에

서 사용자가 피드백도 한 번 넣어봤습니다. 얼마나 달라질까요?

실험 조건

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

• 스킬 에이전트: 없음

• 사용자 피드백: 계획 단계에서 1회

• 총 소요시간: 약 50분 (1편의 약 5배)

1편과의 핵심 차이는 두 가지입니다. 자기검증이 켜져 있다는 것, 그리고 계획을 확정하기 전에 사용자가 "이건 꼭 넣어줘"라는 피드백을 한 번 했다는 것입니다.

프롬프트 #1 — 리서치 + 계획 (자기검증 포함)

간단한 todo프로그램을 만들고 싶어. 대신 디자인과 기능은 상업용 프로그램의 퀄리티로 만들고 싶어. 구현에 필요한 리서치를 자세하게 하고 그걸 토대로 구현 계획을 세워줘. 대신 모든 과정은 자기검증을 하고 수정을 할 필요가 없을 때 진행.

1편과 프롬프트가 거의 같지만, 마지막 부분이 다릅니다. 1편에서는 "자기검증 과정은 제외를 해줘"였고, 이번에는 "모든 과정은 자기검증을 하고 수정을 할 필요가 없을 때 진행"입니다.

리서치 — 1편과 동일하게 에이전트 2개 병렬 실행

상용 TODO 앱 5개(Todoist, Things 3, TickTick, Microsoft To Do, Any.do) 분석 + 기술 스택 조사. 여기까지는 1편과 비슷합니다.

차이가 나기 시작한 지점 — 계획 단계의 자기검증

1편에서는 리서치가 끝나면 바로 계획을 확정하고 구현으로 넘어갔습니다. 이번에는 계획을 세운 뒤 스스로 5개 우려사항을 발견하고 수정했습니다:

• 범위가 너무 넓지 않은지 재점검

• 상태 관리 역할 분리 (Zustand vs Dexie.js)

• 다크모드 적용 시점

• 테스트 전략

• Zustand와 Dexie.js의 책임 경계

또한 기술 스택 선택도 달랐습니다. 1편에서는 Vite + React를 선택했지만, 이번에는 Next.js 16을 선택했고, 데이터 저장도 localStorage 대신 IndexedDB(Dexie.js)를 골랐습니다. 같은 프롬프트인데도 리서치 시점의 판단에 따라 기술 스택이 달라진 것입니다.

프롬프트 #2 — 사용자 피드백

반복 작업과 캘린더 뷰는 추가는 무조건 필요해. 기술 스택은 알아서 해줘. 우선 순위는 드래그앤드랍으로 위치 조정으로 우선 순위를 정하면 되지 않을까?

1편에서는 이 단계가 없었습니다. 이번에는 계획을 보고 "반복 작업과 캘린더는 꼭 넣어라", "우선순위는 드래그 순서로 하자"는 피드백을 한 번 넣었습니다.

Claude Code는 이 피드백을 반영해서 계획을 수정하고, 수정된 계획도 다시 자기검증한 뒤 확정했습니다.

프롬프트 #3 — "시작해줘"

시작해줘.

이 한 마디로 구현이 시작됩니다. 약 15분간 진행된 작업:

• Next.js 16 프로젝트 생성 + shadcn/ui 12개 컴포넌트 설치

• 데이터 레이어 5개 파일 (Task/Project/Tag 타입 + Dexie.js 스키마 + 서비스 레이어)

• 상태 관리 (Zustand — 뷰, 사이드바, 검색, 편집, Undo)

• UI 컴포넌트 12개 파일 (사이드바, 태스크 목록, 인라인 추가, 편집 Sheet, 캘린더 뷰, 검색 다이얼로그 등)

• 키보드 단축키

• 빌드 오류 2건 자체 수정 (TypeScript 타입 불일치 + shadcn/ui API 변경 대응)

1편에서는 빌드 오류가 있었는지 로그에 남아있지 않지만, 이번에는 빌드 오류를 만나서 스스로 수정하고 넘어간 것이 기록에 남아 있습니다.

1차 결과 — 자기검증이 켜진 상태로 나온 것

ALT

숫자가 표시된 검은색 화면의 스크린샷

ALT

항목 목록이 표시된 검은색 화면

ALT

흰색 배경의 웹페이지 스크린샷

1차 리뷰

직접 사용해본 결과입니다:

잘된 점:

• 전체적인 디자인은 1편과 비슷한 수준으로 나옴. 다크모드/라이트모드 모두 문제없이 동작

• 날짜 선택에 아무 문제 없음 — 1편에서는 날짜 선택 버그가 바로 발견되었는데, 이번에는 깔끔

• 프로젝트 폴더 이동, 반복 작업 설정 모두 정상 동작

• 캘린더 뷰가 제대로 동작 — 사용자 피드백으로 추가 요청한 기능

• 오늘 날짜에 해당하는 작업 필터링도 문제없음

• 태스크 클릭 시 우측 상세 패널(Sheet)이 열림 — 날짜, 반복, 프로젝트, 태그를 한 곳에서 편집 가능

아쉬운 점:

• 단축키 Q(Add a task)가 동작하지 않음 — 1편에서 N키가 안 됐던 것과 같은 패턴의 문제

1편에서 발견됐던 날짜 선택 버그는 사라졌지만, 단축키 미동작 문제는 여전히 반복되었습니다.

추가 프롬프트 — UX 개선 요청

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

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

결과 — 눈에 보이는 변화는 크지 않았음

1편에서는 이 프롬프트로 인라인 뱃지, 토스트 알림 등 눈에 보이는 큰 변화가 있었습니다. 이번에는 겉으로 보기엔 크게 달라진 것이 없었습니다.

오히려 Hydration 에러가 발생했습니다. Next.js의 서버 렌더링과 클라이언트 렌더링이 불일치하는 문제입니다. 1편에서는 Vite(클라이언트 전용)를 사용했기 때문에 발생하지 않았던 종류의 에러입니다.

자기검증 반복 지시

에러를 수정 요청한 뒤, "자기검증을 수정할 내용이 없을 때까지 반복해줘"라고 지시했습니다.

자기검증 결과:

자기검증을 3라운드 돌려서 총 21건의 이슈를 발견하고 19건을 수정했습니다. 수정 내용은 대부분 코드 안정성(메모리 누수, null 처리, 타임존 일관성)과 접근성(ARIA, 터치 타겟)에 관한 것이었습니다. 미수정 2건은 데이터 모델 변경이 필요한 항목으로, 현재 범위에서는 영향이 없는 수준이었습니다.

최종 결과 — 자기검증 반복 후

ALT

태블릿의 캘린더 앱 스크린샷

2차 리뷰

• 태스크 추가 폼이 항상 열려 있는 상태로 변경됨 — "Add a task... (press Q)" placeholder

• 태스크 아래에 날짜 뱃지(Today), 반복 아이콘, 프로젝트 컬러 뱃지가 인라인으로 표시

• 날짜/프로젝트/반복 설정 버튼이 폼 안에 바로 보임

• 검색은 / 키로 실행 — 1편의 Ctrl+K보다 오히려 편하게 느껴짐. 이건 기능의 문제가 아니라 리서치 시점에 어떤 패턴을 참고했느냐의 차이로 보임

• Q 단축키는 여전히 동작하지 않음 — 자기검증을 여러 번 거쳐도 해결되지 않음

1편과 비교했을 때

자기검증이 해준 것

• 계획 단계에서 범위와 설계를 한 번 더 점검 → 날짜 선택 같은 기본적인 버그가 사라짐

• 구현 후 코드 리뷰 21건 → 메모리 누수, null 처리, 접근성 등 "눈에 안 보이지만 중요한" 문제들을 수정

• 빌드 오류를 스스로 감지하고 해결

자기검증이 못한 것

• 단축키 미동작은 여전히 잡지 못함 — 1편에서 N키, 2편에서 Q키. 같은 패턴의 버그가 자기검증을 여러 번 돌려도 해결되지 않음

• Next.js를 선택한 것이 오히려 Hydration 에러라는 새로운 문제를 만듦 — 기술 스택 선택의 자기검증은 "동작 여부"까지 검증하지 못함

시간 대비 효과

1편은 17분, 2편은 50분. 약 3배의 시간이 더 들었습니다. 자기검증이 코드 안정성을 높여준 것은 사실이지만, 사용자가 체감하는 수준의 차이가 시간 투자 대비 크지 않았습니다. 오히려 사용자 피드백(반복 작업, 캘린더)이 기능 범위에 더 큰 영향을 미쳤습니다.

이 테스트에서 알 수 있는 것

1. 자기검증은 "기본적인 완성도"를 올려줍니다. 1편에서 바로 발견됐던 날짜 선택 버그 같은 문제는 사라졌습니다.

2. 하지만 자기검증에도 사각지대가 있습니다. 단축키가 표시만 되고 동작하지 않는 문제는 1편과 2편 모두에서 동일하게 발생했고, 여러 번 검증해도 잡히지 않았습니다.

3. 사용자 피드백은 기능 범위를 결정합니다. 반복 작업, 캘린더, 드래그 우선순위 같은 것은 사용자가 말하지 않으면 나오지 않거나 다른 방식으로 구현됩니다.

4. 기술 스택 선택은 매번 달라집니다. 같은 프롬프트인데도 Vite vs Next.js, localStorage vs IndexedDB로 갈렸습니다. 리서치 시점의 판단 차이가 이후 전체 개발 과정에 영향을 줍니다.

다음 글 예고

다음 글(3/4)에서는 자기검증에 스킬 에이전트까지 추가합니다. 스킬 에이전트란, Claude Code가 특정 영역(디자인, 코드 리뷰, UX 등)에 전문화된 역할을 수행하도록 하는 설정입니다. 자기검증의 사각지대를 스킬 에이전트가 메워줄 수 있을까요?