AI로 10분 만에 테스트 코드 완성하기

9분

2025.10.17.

10분 완성 테스트 코드: AI와 함께하는 SDD

목표는 단 10분 안에 테스트 코드를 완성하는 것입니다. 이런 빠른 개발이 가능해지려면, AI에게 거대한 과제를 한 번에 던지는 것이 아닌 AI와 함께 명세(Specification)를 먼저 정의하고 개발을 진행하는 SDD(Spec-Driven Development)’ 워크플로우가 필요합니다.

AI는 명확한 맥락을 제공하지 않으면, 길을 잃고 부정확한 결과물(환각)을 내놓기 쉽습니다. SDD 접근법은 AI가 단계마다 목표에만 집중하며 안정적으로 결과물을 만들어 내게 유도하는 가장 효과적인 방법입니다.

이 워크플로우는 실제 10분이라는 시간 내에서, 다음과 같이 적용할 수 있습니다.

10분 타임어택: 실전 워크플로우

1단계. 명세 정의(Define Spec – 2분): AI에게 테스트 설계와 시나리오를 요청
2단계. 코드 생성(Generate – 2분): 명세에 기반한 테스트 코드 생성
3단계. 검증과 개선(Validate & Refine – 6분): 테스트 에러 수정(4분) 및 코드 리팩토링(2분)

이제 이 계획을 적용해 인증 로직(토큰 갱신, 로그아웃 등)을 처리하는 HTTP 클라이언트 테스트 코드를 직접 구현해 보겠습니다. 도구로는 클로드 코드(Claude Code)를, 모델은 소넷(Sonnet) 4.1을 활용했습니다.*

*집필 시점에 아직 소넷 4.5 업데이트가 적용되지 않았기 때문에, 4.1 모델을 중심으로 내용을 구성했습니다.

AI 협업 SDD 워크플로우 3단계 적용기

1단계. AI와 명세 정의하기(Define Spec)

모든 작업의 시작은 코드가 아닌, 탄탄한 명세에서 출발합니다. 그런 만큼 가장 먼저 AI에게 테스트의 전반적인 설계를 요청했습니다. 때로 AI는 개발자가 미처 고려하지 못한 예외나 고려할 사항을 찾아 더 나은 청사진을 제시하고는 합니다.

Prompt: 이 파일의 중요성과 복잡성을 고려해서, 테스트 계획을 세워줘. 테스트해야 할 시나리오들을 정리하고 비즈니스 중요도에 따라 우선순위를 매겨줘 ultrathink

이 AI 프롬프팅에서 답변의 수준을 결정짓는 두 가지 핵심 요소는 ‘우선순위 지정’과 ‘깊은 사고 유도’입니다.

우선순위 지정: “비즈니스 중요도에 따라 우선순위를 매겨달라”고 명확히 요청하면, AI는 다양한 테스트 시나리오 중 핵심 케이스를 선별해 중요도 순으로 정렬해 줍니다. 이를 통해 가장 중요한 시나리오에 집중할 수 있습니다.
깊은 사고 유도: ‘ultrathink’라는 키워드는 AI에게 더 높은 수준의 분석을 요구하는 명령어입니다. 지시를 받은 AI는 내부적으로 더 많은 연산(토큰)을 사용해 추론 강도를 강화한 모드로 동작합니다. 그 결과, 단순하고 표면적인 답변이 아닌, 예외 상황까지 고려한 다각적이고 정교한 결과물을 생성합니다.

Think 키워드와 AI의 추론 능력 끌어올리기

Think 키워드는 모델의 추론 예산(reasoning budget)을 단계적으로 증가시켜, 더 복잡하고 깊이 있는 문제 해결을 가능하게 하는 명령어입니다. 이 키워드들은 think < think hard < ultrathink 순으로 강력한 성능을 보이며, 특히 ultrathink는 무척 정교한 결과물을 제공합니다. 개발자들은 이 기능으로 클로드를 복잡한 코딩 문제를 해결하는 에이전트형 도구로도 사용할 수 있습니다.

think: 약 4,000 토큰
think hard: 약 10,000 토큰
ultrathink: 최대 약 32,000 토큰

클로드 코드 터미널 환경에서는 이 Think 키워드들을 입력할 때 각기 다른 색상으로 하이라이트되는 재미있는 기능도 있습니다. ultrathink 키워드를 쓰면 무지개 색상으로 예쁘게 보입니다.

다시 돌아와, 실제로 AI는 이러한 요청에 따라 매우 그럴듯한 테스트 계획을 제시했습니다.

각 시나리오는 비즈니스 중요도와 사용자 영향도를 기준으로 P0(매우 높음), P1(높음), P2(낮음)와 같이 체계적으로 분류되었습니다. 가장 중요한 P0 등급에는 ‘토큰 갱신 로직’이나 ‘인증 만료 시나리오’ 등 핵심 비즈니스 로직이 포함되어 있어, AI의 높은 이해도를 볼 수 있었습니다.

2단계. 명세를 코드로 바꾸기(Generate)

이제 계획을 실제 코드로 옮길 차례입니다. 핵심은 ‘선택과 집중’입니다. 테스트 코드가 지나치게 많아지면 오히려 코드 부채(Code Debt)가 되어 유지보수를 어렵게 만듭니다. 또한, 한 번에 너무 많은 테스트 생성을 요구하면 맥락을 놓치며 결과물의 품질이 떨어질 수 있습니다.

따라서 가장 중요한 최우선 순위(P0) 비즈니스 로직에 대한 테스트 코드부터 작성하도록 요청합니다.

Prompt: 최우선 순위의 비즈니스 크리티컬 로직에 대한 테스트 코드를 작성해줘

AI는 이 요청에 따라, 순식간에 350줄에 달하는 테스트 코드를 완성했습니다. 단순히 코드의 양이 많았던 것뿐만 아니라, 시나리오에 대한 상세한 설명과 필요한 주석까지 포함되어 있었습니다. 만약 이 작업을 개발자가 직접 하려면 얼마나 많은 시간이 들어갈까요? AI는 이처럼 복잡하고 시간이 많이 드는 작업을 단 몇 초 만에 해결해 줍니다.

3단계. 검증과 개선의 자동화 루프(Validate & Refine)

하지만 애석하게도, 이 테스트 코드가 처음부터 통과되지는 않았습니다. 테스트 코드를 작성했는데 실패했다? 인간 개발자라면 해고 사유가 될 수도 있겠죠. 하지만, AI는 괜찮습니다. 압도적인 속도로 코드를 생성하고, 그와 비슷한 속도로 문제를 수정할 수도 있기 때문입니다.

AI가 처음 생성한 코드는 실제 실행 환경의 미세한 차이(설정 불일치, 비동기 타이밍 등)까지 예측하기 어렵기 때문에, 첫 시도에서 실패하는 것은 꽤 흔한 일입니다.

이 문제들을 해결하기 위해, 저는 AI에게 다음과 같이 요청했습니다.

Prompt: 실패 원인을 분석하고 테스트가 모두 통과할 때까지 코드를 수정해줘

마침내 모든 테스트를 통과했다고 합니다.

핵심은 프롬프트에 ‘통과할 때까지’라는 조건을 둔 것입니다. 이 조건이 없었다면 AI는 한두 번 수정하다 멈추거나, 여전히 실패하는 코드를 남겼을 가능성도 있습니다. 하지만 이 조건으로 AI는 ‘실패 → 원인 분석 → 수정 → 재실행’의 과정을 스스로 반복하며 문제를 해결했습니다.

물론 이 과정에는 조금 더 시간이 걸릴 수 있습니다. 특히 처음부터 테스트 범위가 과도하게 넓었다면, AI가 길을 잃고 한 번의 프롬프트 요청만으로 모든 테스트를 통과시키지 못했을 수도 있습니다. 정확한 목표 설정과 우선순위 지정이 무엇보다 중요한 이유입니다.

스마트한 리팩토링 전략

AI가 생성한 코드는 기능적으로는 잘 동작하지만, 가독성이나 유지보수 측면에서는 아쉬움이 남는 경우가 많습니다. 이는 AI가 코드를 작성할 때 ‘가장 빠른 경로로 기능을 구현하는 것’에 집중하기 때문인데요. 따라서 코드 품질을 한 단계 끌어올리려면 리팩토링이 필수입니다.

흥미로운 점은, AI는 리팩토링 작업에 상당히 능숙하다는 사실입니다. 코드를 단순히 줄 단위로 읽는 것이 아니라, 구조와 패턴을 추상화해 보기 때문입니다. 사람이 세부 구현에 집중하는 반면, AI는 토큰 단위로 코드를 해석하면서 구조적인 패턴과 규칙을 인식합니다. 단일 책임 원칙(SRP), DRY(Don’t Repeat Yourself), 일관성 유지 등 원칙을 기반으로 코드를 이해하고, 이를 바탕으로 더 나은 형태로 재구성할 수 있죠.

‘어떻게’ 요청하는가

AI에게 리팩토링을 맡길 때 가장 중요한 것은 무엇을, 어떻게 요청하느냐입니다. 단순히 “리팩토링해줘”라고만 지시하면, 의도치 않게 과도한 추상화가 적용되어 코드가 오히려 복잡해질 수 있습니다. 잘못된 추상화는 중복보다 더 나쁘다는 말처럼, 방향 없는 리팩토링은 독이 되기도 합니다. 따라서 지시에는 맥락, 목표, 제약조건을 함께 전달하는 것이 좋습니다.

하지만 저는 AI가 본질적으로 리팩토링에 강하다고 보기 때문에, 지나치게 세세한 지시보다는 적절한 자유도를 부여하고, 대신 우선순위 설정을 요구하는 편입니다. 프롬프트는 모호하지도, 과도하게 구체적이지도 않아야 합니다.

Prompt: 이 테스트 코드의 리팩토링 포인트를 우선순위별로 분석하고 제안해줘. 각 제안의 장단점과 적용 여부를 판단할 기준도 함께 알려줘.

이러한 접근은 AI가 계획을 제안하고, 인간이 최종 실행 여부를 결정하는 SDD의 연장선에 있습니다. AI는 다양한 개선안을 제시하고, 개발자는 가장 적합한 안을 선택합니다. 불필요한 복잡성을 걸러내고 실용적이고 안전한 개선 방식만 취하는 것이죠. 또한, 장단점과 판단 기준을 함께 제시하도록 요청하는 방식은, 특히 경험이 적은 주니어 개발자에게 효율적인 프롬프팅 전략이 될 수 있습니다.

결과에서 보이듯 개발자를 위한 선택지를 요청하면, AI는 훨씬 유용한 피드백을 제공합니다. 여기서는 여러 테스트 코드에 중복된 DOM 선택 로직을 제거하자는 최우선 과제를 제안했습니다. “5개 이상 파일에서 동일한 패턴이 발견되므로 즉시 적용이 필요하다”는 명확한 기준까지 제시한 모습입니다.

Prompt: 즉시 적용 권장(P0) 리팩토링을 진행해줘

이 프롬프트를 적용해 리팩토링한 성과는 수치로도 바로 확인할 수 있었습니다.

중복 코드 라인 수: 8곳 × 4라인 = 32라인 → 4라인 (87.5% 감소)
HTTP 클라이언트 생성 로직 반복: 8회 → 1회 (87.5% 감소)
유지보수 포인트: 8곳 → 1곳 (87.5% 감소)

여기까지 걸린 시간은 10분입니다.

실무에서 우리는 제한된 자원으로 최대의 성과를 내기 위해 가치와 긴급성에 따라 일의 우선순위를 정합니다. AI와 협업하는 ‘바이브 코딩(Vibe Coding)’에서도 마찬가지입니다.

우선순위가 없다면 AI는 중요도가 낮은 코드에 매달리거나, 불필요한 작업을 반복해 시간과 토큰을 낭비하고는 합니다. 그러나 우선순위를 부여하면 AI는 가장 중요한 과제에만 집중하고, 그 결과 개발 속도와 정확성이 눈에 띄게 향상됩니다. 무엇보다 AI는 핵심 과제를 파악하고 정렬하는 능력이 매우 뛰어납니다.

+깃(Git) 워크플로우 자동화: AI 토큰 사용량까지 기록하기

마지막으로, 클로드 코드를 활용하면 브랜치 생성부터 커밋, 푸시, PR(Pull Request) 생성까지 모든 과정을 터미널에서 자연어 한 줄로 처리할 수도 있습니다. 원하는 대로 개발 워크플로우를 개선할 수 있다는 뜻이죠. 아래 두 가지 개선 포인트를 특히 추천합니다.

1. AI 기여도·토큰 사용량 기록

커밋과 PR 템플릿에 AI의 코드 기여율과 토큰 사용량을 자동으로 기록하도록 설정 → 팀 단위로 AI 활용 현황을 정량적으로 추적할 수 있습니다.

2. Husky 스크립트 없는 JIRA 티켓 연동

브랜치명에서 티켓 번호를 자동으로 추출해 커밋 메시지에 포함되도록 구성 → 별도 스크립트 없이도 feature/PSN-49-modal → [PSN-49] 과 같은 모습으로 바로 반영됩니다.

**Commit Message Format**: `<issue-key> <commit-message-summary>`
- Extract issue key from branch: `feature/PSN-49-modal` → `PSN-49`
- Format: `<issue-key> <commit-message-summary>`
**Template**

변경사항 (사용자: X% | Claude: Y%)
사용자 작성 (X%):
[사용자가 작성한 변경사항들]

Claude 작성 (Y%):
[Claude가 작성한 변경사항들 (파일 경로 포함)]

AI 작업 메트릭 (AI Metrics)
토큰 사용량: Input XXX / Output XXX (Total: XXX)
대화 턴 수: X회
주요 작업: [코드 작성/리팩토링/디버깅/문서화]
Co-authored-By: Claude noreply@anthropic.com

이렇게 PR 템플릿에 AI 기여도, 토큰 사용량, 작성된 코드 비율 등을 함께 기록하면 리뷰어는 AI가 작성한 코드 영역에 집중해 검토할 수 있습니다. 전체적인 코드 리뷰 효율이 크게 올라갈 수 있죠.

다만, 이때는 사용자가 직접 입력한 기여 퍼센티지나 변경 내역과 클로드가 실제로 생성한 코드 변경사항이 완전히 일치하지 않는 경우가 종종 발생합니다. 따라서 이러한 정보를 명확하고 일관성 있게 관리할 수 있도록 PR 템플릿을 체계적으로 구성할 필요가 있습니다.

또한 회사 차원에서 AI 활용 정책을 적극적으로 지원한다면, 이렇게 수집한 데이터를 정량적으로 기록·분석하여 개발 프로세스 개선에 활용할 수 있습니다. 나아가 AI 활용량 자체를 주요 지표로 삼는 것도 방법입니다. 예를 들어, 토큰 사용량을 기입하고 깃헙의 커밋이나 PR을 지라 티켓과 연동해 티켓 단위로 총 토큰 사용량을 집계하는 방식도 고려할 수 있습니다.

마치며

물론 ‘10분’이라는 시간은 상징적인 수치입니다. 실제 테스트 과정은 목(Mock) 데이터 준비나 의존성 설정 등으로 인해 더 복잡하며, 긴 시간이 걸릴 수 있습니다. 다만 전하고자 한 핵심은 시간 절약이 아닙니다. 그 과정에서 일어나는 개발 패러다임의 전환에 있습니다.

이제 혼자 테스트 코드를 작성하던 시대는 지나가고, AI와 함께 테스트 전략을 ‘설계’하는 시대가 열렸습니다. AI는 단순히 시간을 아껴주는 조수를 넘어, 인간이 놓칠 수 있는 엣지 케이스를 발견하고 코드의 안정성을 높여주는 동료 역할을 합니다.

그럼에도 결국 AI는 도구입니다. 그 가치를 끌어내는 것은 전문가, 즉, 우리 개발자의 몫입니다. 그래서 서로 경험을 나누는 것이 무엇보다 중요합니다. 이 글이 여러분의 ‘AI 테스트 설계’ 여정에 작지만 의미 있는 이정표가 되기를 바랍니다.