Claude Code 프롬프트 실험 (4/4) — 세 결과 비교, 그리고 결론

이 시리즈는

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

한눈에 보는 비교

투입 조건

기술적 결과

사용자 체감 결과

실험에서 드러난 것들

1. 자기검증은 "기본적인 안정성"을 올려준다

1편에서는 날짜 선택 버그가 바로 발견되었습니다. 2편과 3편에서는 자기검증이 켜져 있었고, 이런 종류의 기본적인 버그는 발생하지 않았습니다.

자기검증의 효과는 눈에 안 보이는 곳에서 더 크게 나타났습니다. 메모리 누수, null 처리, 타임존 일관성, 접근성(ARIA, 터치 타겟) 같은 문제들을 스스로 찾아서 수정했습니다. 2편에서 21건, 3편에서 13건을 잡았습니다.

2. 하지만 자기검증에는 사각지대가 있다

단축키 미동작은 세 번의 테스트에서 전부 발생했습니다.

• 1편: N키

• 2편: Q키

• 3편: J/K키

자기검증을 여러 번 반복해도 이 문제는 잡히지 않았습니다. 화면에 "Q: 빠른 추가"라고 표시되어 있고 코드에도 단축키가 등록되어 있지만, 실제로 눌러보면 동작하지 않는 경우입니다. Claude Code의 자기검증은 "코드를 읽고 논리적으로 점검"하는 방식이기 때문에, 실제로 UI를 조작해서 확인하는 테스트와는 다릅니다.

이건 사용자가 직접 "이 단축키 안 되니까 고쳐"라고 구체적으로 짚어줘야 해결됩니다.

3. 사용자 피드백이 기능 범위를 결정한다

2편에서는 "캘린더 넣어줘, 반복 작업 넣어줘"라는 피드백을 한 번 넣었습니다. 그 결과 캘린더 뷰와 반복 작업이 구현되었습니다.

3편에서는 스킬 에이전트까지 투입했지만, 이 피드백이 없었기 때문에 캘린더가 빠졌습니다. 스킬 에이전트가 아무리 정교해도 "사용자가 뭘 원하는지"는 사용자가 말해야 알 수 있습니다.

4. 스킬 에이전트는 코드 품질에 확실한 차이를 만든다

3편만 유일하게 테스트 109개를 가지고 있고, 클린 아키텍처 4계층이 적용되었습니다. 코드를 유지보수하거나 기능을 추가해야 하는 상황이라면 3편의 코드가 압도적으로 유리합니다.

하지만 "지금 당장 쓸 수 있는 앱"이라는 관점에서 보면, 17분 만에 나온 1편과 2시간 20분이 걸린 3편의 체감 차이가 크지 않았습니다.

5. 기술 스택 선택은 매번 달라진다

같은 프롬프트를 넣었는데도 Vite, Next.js, 다시 Vite로 기술 스택이 바뀌었습니다. localStorage와 IndexedDB로 갈리기도 했습니다. 이건 리서치 시점에 Claude Code가 어떤 정보를 먼저 찾느냐에 따른 차이이며, 사용자가 "Vite로 해줘"라고 지정하지 않는 한 매번 달라질 수 있습니다.

시간 대비 효과

시간을 3배, 8배 더 투자한다고 해서 사용자 체감 품질이 비례해서 올라가지는 않았습니다. 오히려 사용자 피드백 한 줄(2편의 캘린더/반복 요청)이 시간 투자보다 큰 영향을 미쳤습니다.

결론 — 코딩을 모르는 사람도 만들 수 있다

이번 실험을 통해 확인한 것은, Claude Code가 모든 것을 완벽하게 해주지는 못한다는 점입니다. 단축키가 안 되고, 사용자가 말하지 않은 기능은 빠지고, 매번 다른 기술 스택을 고릅니다.

하지만, 사용자가 올바른 역할을 한다면 이야기가 달라집니다.

이번 실험에서는 의도적으로 사용자 개입을 최소화했습니다. 실제로 앱을 만드는 상황이라면 다음과 같은 것들을 사용자가 제공할 수 있습니다:

1. 확실한 계획 "TODO 앱 만들어줘"가 아니라, 어떤 기능이 필요하고 어떤 순서로 만들지를 구체적으로 전달하는 것. 2편에서 "캘린더 넣어줘"라는 한 마디가 기능 범위를 바꾼 것처럼, 계획이 구체적일수록 결과가 좋아집니다.

2. 충분한 레퍼런스 이번 실험에서는 하지 않았지만, 마음에 드는 다른 앱의 UI 스크린샷을 이미지로 첨부하면 디자인 방향을 훨씬 구체적으로 잡을 수 있습니다. "상업용 수준으로"라는 말보다 Todoist 스크린샷 한 장이 더 명확합니다.

3. 충분한 피드백 "잘 됐어" / "안 됐어"가 아니라, "이 단축키가 안 된다", "날짜 선택할 때 이런 버그가 있다", "이 메뉴에서만 동작이 다르다"처럼 구체적으로 짚어주는 것. Claude Code의 자기검증이 잡지 못하는 문제는 사용자의 리뷰가 잡아야 합니다.

4. 충분한 버그 리뷰 자기검증은 코드 수준의 논리적 점검입니다. 실제로 앱을 열어서 버튼을 눌러보고, 이상한 동작을 발견해서 알려주는 것은 사용자의 몫입니다. 이번 실험에서 단축키 미동작이 세 번 다 발생한 것이 이를 증명합니다.

이 네 가지를 사용자가 제공한다면, 코딩을 모르는 사람도 충분히 원하는 결과물을 만들 수 있습니다. 프로그래밍 지식이 필요한 것이 아니라, "내가 뭘 원하는지 명확하게 전달하고, 결과물을 꼼꼼하게 확인하는 능력"이 필요합니다.

상용화까지 가능할까요? 이번 실험에서는 인증, 서버 연동, 배포 같은 영역을 다루지 않았지만, 실은 저는 이전에 Claude Code로 이 모든 것을 해본 경험이 있습니다. 인증, 서버 연동, 배포, 성능 최적화, 브라우저 호환성까지 Claude Code로 전부 진행했고, 그렇게 만들어서 실제로 사용하고 있는 프로젝트가 여러 개 있습니다. 그때는 지금보다 코딩에 대해 더 모를 때였지만 충분히 가능했습니다.

즉, 상용화는 이론이 아니라 이미 실현 가능한 영역입니다. 이번 실험은 "프롬프트에 따른 결과 차이"에 집중하기 위해 범위를 좁힌 것이지, Claude Code의 한계가 거기까지인 것은 아닙니다.

시리즈를 마치며

Claude Code는 도구입니다. 좋은 도구를 잘 쓰려면 "도구에게 무엇을 시킬지"를 아는 것이 중요합니다. 코딩을 아는 것이 아니라, 자신이 원하는 결과물을 명확하게 정의하고, 결과를 꼼꼼하게 검증하는 것. 그것이 Claude Code를 잘 쓰는 방법이었습니다.