Spec Kit + Claude Code 완벽 설정 튜토리얼 & 솔직 리뷰

AI Unleashed 구독자 7,000명

요약

이 영상에서는 Spec Kit과 Claude Code를 사용해 애플리케이션을 단계별로 재구축하는 과정을 상세히 살펴봅니다. 설치부터 Specify·Plan·Tasks·Implement의 네 가지 명세 기반 워크플로우를 거치며 요구사항 정의, 기술 설계, 작업 분해, 코드 자동 생성 과정을 경험합니다. 최종 결과물을 데모로 확인한 뒤 장단점을 분석하고, 범위를 축소해 부분 기능에 적용할 때 더 유용하다는 결론을 제시합니다.

주요 키워드

Spec Kit Claude Code TDD Contract-first OpenAPI ERD Component Architecture API Contract Next.js Neon

하이라이트

🔑 Spec Kit은 명세 기반 단계별 워크플로우를 제공해 사용자 여정과 기능 요구사항을 체계적으로 정의합니다.
⚡️ Plan 단계에서 Next.js·shadCN·Neon을 지정해 아키텍처 설계, TDD, API 계약 우선 접근법을 자동으로 생성했습니다.
🌟 Tasks 단계는 자동으로 테스트 작성 및 실패 전제 테스트 케이스를 구성해 TDD 흐름을 보장합니다.
📌 Implement 단계는 1시간 이상 걸리며 많은 토큰을 사용하지만 기본 인증·스트리밍 이력서 기능을 동작시키는 코드를 생성했습니다.
🚀 완성된 앱 데모를 통해 기본 기능은 즉시 실행되었으나, 템플릿 기능 일부와 저장 기능이 미구현된 점은 아쉬웠습니다.
🌐 구성된 컴포넌트 아키텍처와 API 계약 관리, 문서화된 OpenAPI 스펙은 코드 품질과 확장성 향상에 기여합니다.
⚠️ 너무 방대한 범위로 전체 애플리케이션을 자동화하려다 보니 중간에 중단·토큰 한계에 부딪혀 효율이 떨어졌습니다.
💡 작은 기능 단위나 신규 피처 개발에만 Spec Kit을 적용하면 더 빠르고 유연한 결과를 얻을 수 있습니다

용어 설명

Spec Kit

단계별(Define, Plan, Tasks, Implement) AI 기반 코드 생성 워크플로우 프레임워크

Claude Code

Anthropic의 Claude 모델을 활용한 AI 코드 어시스턴트

TDD(Test-Driven Development)

테스트를 먼저 작성하고 실패 시 구현을 시작하는 개발 방법론

Contract-first approach

코드 작성 전에 API 계약(스펙)을 먼저 정의하는 설계 기법

OpenAPI Specification

RESTful API 사양을 문서화하는 표준 포맷

ERD(Entity Relationship Diagram)

데이터베이스 테이블 간 관계를 시각화한 다이어그램

Spec Kit과 Claude Code를 이용해 애플리케이션을 재구축하려는 목적을 설명하고, 세 단계 전 계획 기반 워크플로우를 개괄합니다.

[00:00] Spec Kit을 사용해 Claude Code로 전체 애플리케이션을 재구축한 경험을 공유하며, 이러한 구조화된 접근 방식이 실제로 개발에 차이를 만드는지 확인해보겠다고 소개합니다.

[00:07] Spec Kit을 강화된 플래닝 모드로 설명하며, 코드 작성 전에 Claude가 세 가지 별개의 계획 단계를 거치도록 하는 도구라고 설명합니다.

uvx 명령어로 프로젝트에 Spec Kit을 설치하고 Cloud Code와 연동합니다. 템플릿 복사 및 커스텀 명령어 설치 과정을 다룹니다.

[00:16] Claude Code 프로젝트에 Spec Kit을 설치하는 과정을 단계별로 설명하며, uvx 명령어 사용법과 프로젝트명 지정, AI 어시스턴트 선택 방법을 안내합니다.

[00:35] Claude Code, Gemini CLI, Cursor, GitHub Copilot 등의 옵션 중 Claude Code를 선택하는 이유를 설명하고, 맥 환경에서의 스크립트 타입 설정 방법을 안내합니다.

[00:46] Spec Kit이 템플릿을 로컬 프로젝트에 복사하고 Claude Code용 커스텀 명령어를 설치하는 과정을 설명하며, 이것이 설정의 전부라고 안내합니다.

사용자 여정·경험·문제 해결 목표 등을 중심으로 What과 Why만 정의합니다. 마크다운 파일 참조로 초기 요구사항을 기록하고 Spec Kit이 기능 요구사항 목록을 자동 생성합니다.

[00:59] Claude Code에서 새로 생긴 specify 명령어를 소개하며, 이것이 프로세스의 첫 번째 단계로 '무엇을'과 '왜'는 설명하되 '어떻게'는 포함하지 않는 것이 중요하다고 강조합니다.

[01:16] 프롬프트를 직접 입력하는 대신 마크다운 파일을 참조하는 방법을 추천하며, 이를 통해 나중에 참조하고 반복할 수 있는 시작점을 만들 수 있다고 설명합니다.

[01:30] 마크다운 파일의 내용을 설명하며, 사용자 여정, 경험, 원하는 결과, 해결하려는 문제에 집중하고 기술적 세부사항은 포함하지 않는다고 강조합니다.

[01:37] 구체적인 애플리케이션 예시로 AI를 활용한 맞춤형 이력서 작성 도구를 제시하며, 첫 이력서 작성부터 프로필 관리까지의 사용자 기능을 설명합니다.

[01:55] specify 명령어 실행 후 생성되는 spec.md 파일을 설명하며, 초기 프롬프트가 템플릿에 매핑되어 기능 요구사항으로 분류되고 번호가 매겨지는 과정을 소개합니다.

Next.js, shadCN, Neon 등 기술 스택을 지정해 세부 아키텍처 설계를 수행합니다. 자동으로 라이브러리 분리, 테스트 계획, API 계약 우선 설계, 데이터 모델·ERD·인덱스 전략 문서를 생성합니다.

[02:17] 포괄적인 스펙 완성 후 계획 단계로 진입. speckit의 plan 명령어를 통해 Next.js, shadcn, Neon 등 기술 스택을 지정하여 구체적인 구현 방법을 정의.

[02:32] 계획 단계는 약 30분 소요되며 토큰 소모량이 많아 Opus에서 Sonnet 4로 전환 필요. 단순한 vibe 코딩 대비 아키텍처 설계와 5개 라이브러리 구성 등의 장점 제공.

[02:55] 테스트 주도 설계와 contract first 접근법 채택. 코딩 전 API를 먼저 정의하고, OpenAPI 명세서, 데이터 모델, ERD, 스키마 정의, 인덱싱 전략까지 포괄적으로 생성.

Plan 단계 산출물을 바탕으로 개별 구현 작업을 분해하고, 테스트 우선 방식을 적용한 작업 목록을 마크다운 파일로 만듭니다. 각 작업마다 실패하는 테스트 작성 조건을 포함합니다.

[03:37] specify, plan, tasks 명령어의 계층적 구조 설명. specify로 요구사항 정의, plan으로 기술 명세 작성, tasks로 개별 작업 분해하는 단계적 프로세스.

[04:01] tasks 명령어는 몇 분 내 완료되며 마크다운 파일로 결과 제공. 이전 plan.md를 로드하여 설정 작업, 데이터베이스 스키마 작업 등으로 세분화.

[04:17] 테스트 주도 개발 방식 채택. 모든 테스트를 먼저 작성하고 실패시킨 후 실제 애플리케이션 구현을 시작하는 흥미로운 개발 접근법 소개.

Tasks 마크다운 파일을 입력해 실제 코드 생성을 시작합니다. 1시간 이상 걸리며 토큰 한계로 중단과 재연결을 반복해야 했지만, 기본 기능을 완성합니다.

[04:33] 실제 구현을 시작하며 특별한 명령어 없이 task.md 파일을 선택하여 모든 계획과 참조를 연결하는 과정을 설명합니다.

[04:48] 한 시간 넘게 걸린 구현 과정에서 컨텍스트 윈도우가 여러 번 가득 차고 중단되었지만, 많은 토큰을 사용하여 상당량의 코드를 생성했습니다.

생성된 애플리케이션을 실행해 기본 화면·인증·이력서 스트리밍·신뢰도 점수 기능을 테스트합니다. 즉시 동작한 부분과 클럭 통합 사례를 확인합니다.

[05:00] 완전한 사용자 인증, 인가, 스트리밍 응답이 있는 이력서 맞춤화, 신뢰도 점수 등 완전히 기능적인 애플리케이션이 완성되었다고 주장하며 모든 API 키를 설정했습니다.

[05:16] Ben이 자신을 소개하고 AI 코딩에 관심 있는 시청자들에게 Unleash News 뉴스레터 구독을 권유하며 최신 AI 소프트웨어 개발 소식을 전하겠다고 약속합니다.

[05:27] 전체 구현 과정의 최종 결과를 확인하며 첫인상은 깔끔하고 좋아 보이며, 바로 작동하고 Clerk 통합도 Gmail 계정으로 성공적으로 로그인되어 만족스럽다고 평가합니다.

템플릿 기능 일부 오류, 메타데이터 미표시, 저장 미구현 등 핵심 기능 누락을 발견합니다. 전체 앱 완성도가 기대에 못 미친 점을 지적합니다.

[05:44] UI를 살펴보니 프로필과 이력서는 작동하지만 템플릿에서 오류가 발생하며, 실제로는 전체 애플리케이션이 완성되지 않아 모든 계획 대비 실망스럽다고 지적합니다.

[06:00] 새 프로필 생성 시 업무 경험, 교육, 기술 등의 메타데이터 없이 전문 요약만 제공되며, 저장 기능도 구현되지 않아 단순 UI 데모에 불과하다고 실망을 표합니다.

[06:15] 프로젝트 완료 시 모든 것이 프로덕션 준비되었다고 했던 것과 달리 실제로는 프로젝트의 첫 시작에 불과하며, Next.js 14라는 구식 버전 선택도 아쉽다고 평가합니다.

일관된 컴포넌트 구조, 서비스별 분리, API 계약·상태 관리, 문서화된 OpenAPI 스펙, 계약·통합·성능·단위 테스트 분리 등 긍정적 부분을 분석합니다.

[06:35] 긍정적인 면으로는 일관된 컴포넌트 아키텍처가 매우 마음에 들며, 소스 폴더에 잘 구조화된 컴포넌트들이 구축되어 있다고 칭찬합니다.

[06:42] Spec Kit의 API 관리와 상태 관리 구현 방식을 설명하며, 프로필, 이력서, 템플릿 등을 위한 다양한 API 엔드포인트와 헬스 API의 존재를 언급합니다.

[06:53] API와 계약들의 분리가 잘 되어 있고, specs 폴더에 API 문서가 체계적으로 정리되어 있어 새 컴포넌트 추가 시 참조할 수 있다고 평가합니다.

[07:07] 테스트 주도 개발로 인한 테스트 폴더 구조를 소개하며, 계약 테스트, 통합 테스트, 라이브러리 개별 테스트, 성능 테스트, 단위 테스트로 잘 분류되어 있다고 언급합니다.

Spec Kit은 훌륭한 툴셋이지만, 전체 앱 자동화보다는 소규모 기능 단위 적용이 더 효율적이라고 결론 짓습니다. 향후 워크플로우 커스터마이징 전략을 제안하며 마무리합니다.

[07:20] 테스트 스위트가 기대만큼 완전하지는 않지만 좋은 기반을 제공한다고 평가하며, Spec Kit에 대한 초기 평가를 시작합니다.

[07:26] Spec Kit이 좋은 프레임워크이지만 너무 많은 기능을 시도한다고 평가하며, 전체 애플리케이션보다는 새로운 기능 단위로 제한된 범위에서 사용하는 것을 고려한다고 설명합니다.

[07:42] AI와의 상호작용을 선호하지만 Spec Kit이 너무 오랫동안 사용자 상호작용 없이 독립적으로 작업하는 점이 마음에 들지 않는다고 비판합니다.

[07:54] Spec Kit 프레임워크의 마크다운 파일들이 훌륭하다고 평가하며, 필요한 부분만 선택적으로 사용하고 커스터마이즈하는 전략을 제시합니다.

[00:00] 저는 Spec Kit을 사용해서 Claude Code로 전체 애플리케이션을

[00:01] 재구축했습니다. 하지만 이런 새로운

[00:03] 구조화된 접근 방식이 실제로

[00:05] 차이를 만들었을까요? Spec Kit은

[00:07] 강화된 플래닝 모드라고 생각하시면 됩니다.

[00:09] 코드를 작성하기 전에 Claude가

[00:10] 세 가지 별개의 계획 단계를 거치도록

[00:12] 강제합니다. 그럼 설정하고 실제로

[00:14] 결과가 개선되는지 확인해보겠습니다.

[00:16] 먼저 할 일은 Claude Code에서

[00:18] 우리 프로젝트에 Spec Kit을

[00:20] 설치하는 것입니다. 그를 위해서는

[00:22] uvx 명령어가 있고 빠른 설치

[00:24] 가이드를 영상 설명란에 넣어두겠습니다.

[00:25] 기본적으로는 specify net을 입력하고

[00:26] 원하는 프로젝트 이름을

[00:28] 지정하면 됩니다. 이 경우에는

[00:29] ré rocket이라고 하고 그 다음

[00:30] AI 어시스턴트를 선택하면 됩니다.

[00:32] 여기 몇 가지 옵션이 있습니다.

[00:34] 우리는 Claude Code를 선택하겠습니다.

[00:35] Gemini CLI, Cursor나 GitHub Copilot도

[00:37] 사용할 수 있고 단계는 비슷하지만

[00:39] Claude Code가 제가 선호하는 도구입니다.

[00:41] 스크립트 타입은 맥을 사용하고 있으니

[00:42] sh라고 하겠습니다. 이제 할 일은

[00:44] Spec Kit 안에 있는 모든 템플릿을

[00:46] 로컬 프로젝트에 복사하는 것입니다.

[00:47] 또한 Claude Code에서 사용하는

[00:49] 커스텀 명령어들도 설치됩니다.

[00:51] 이게 Spec Kit을 시작하기 위해 해야 할

[00:53] 전부입니다. 나머지는 Claude Code

[00:54] 안에서 진행됩니다.

[00:56] 이제 해당 디렉토리로 이동해서 Claude Code를 열었습니다.

[00:59] 이제 새로운 명령어들을 볼 수 있습니다.

[01:01] specify 명령어가 있고 이것이

[01:03] 프로세스의 첫 번째 단계입니다.

[01:04] 이걸로 하고 싶은 것은

[01:06] '무엇을'과 '왜'를 설명하는 것이지

[01:08] '어떻게'는 아닙니다. 그러니까

[01:10] 애플리케이션 스택이나 기술에 대한

[01:13] 기술적 세부사항은

[01:14] 들어가지 않습니다. 그냥 여기에

[01:16] 프롬프트를 넣을 수도 있지만

[01:18] 더 좋은 방법은 제가 한 것처럼

[01:20] 마크다운 파일을 참조하는 것입니다.

[01:22] 이렇게 하면 나중에 다시 볼 수 있고

[01:24] 항상 제가 반복할 수 있는

[01:25] 시작점이 됩니다.

[01:27] 그 마크다운 파일을 보면

[01:28] 저는 사용자 여정, 경험,

[01:30] 원하는 결과, 해결하려는 문제에

[01:32] 정말 집중하고 있습니다.

[01:35] 개요를 보면 구직자가

[01:36] AI를 사용해 특정 채용공고에

[01:37] 최적화된 맞춤형 이력서를

[01:39] 만들 수 있도록 돕는 애플리케이션을

[01:41] 구축한다고 되어 있습니다. 첫 이력서

[01:43] 작성, 이력서 맞춤화, 반복적 개선,

[01:45] 프로필 관리 같은 사용법이

[01:47] 나와 있습니다. 기본적으로 요구사항과

[01:49] 최종 사용자 관점에서 어떻게 보이는지를

[01:51] 다루고 있습니다. 하지만 여기에는

[01:53] 기술에 관한 내용은 전혀

[01:54] 없습니다. 이제 명령어가 완료되면

[01:55] specs 폴더 아래에 spec MD라는

[01:57] 새로운 파일이 추가됩니다.

[01:59] 이게 뭔지 보면 기본적으로

[02:01] 우리가 제공한 초기 프롬프트를

[02:03] 가져와서 이 템플릿에 매핑하고

[02:05] 알고 있는 형식으로 넣은 것입니다.

[02:06] 정말 멋진 점은 실제로 기능 요구사항으로

[02:08] 분류하고 각각에 번호를

[02:10] 매긴다는 것입니다.

[02:11] 이제 포괄적인

[02:13] 사양을 갖게 되었으니

[02:15] 계획 단계로 넘어갈 수 있습니다.

[02:17] 포괄적인 스펙이 완성되었으니, 이제 계획 단계로 넘어갈 수 있습니다.

[02:19] 그리고 speckit에서 plan 명령어를 추가했습니다.

[02:21] 이제 실제로 구현 방법에 대한

[02:23] 기술적 세부사항을 제공할 수 있습니다.

[02:24] 그리고 plan 명령어를 사용할 건데,

[02:26] 하지만 Next.js를 사용하고,

[02:27] UI는 shadcn을 사용하고,

[02:28] 데이터베이스는 Neon을 사용한다고 명시하겠습니다.

[02:32] 약 30분 정도 걸렸지만,

[02:34] 계획 단계가 마침내 완료되었습니다.

[02:36] 하지만 이 계획 단계는

[02:38] 토큰을 많이 소모합니다.

[02:39] Opus 토큰 한도를 모두 소모해서

[02:41] 중간에 Sonnet 4로 전환해야 했습니다.

[02:43] 하지만 이런 방식으로 하는 것이

[02:45] 단순한 vibe 코딩과 비교했을 때의

[02:47] 몇 가지 장점을 말씀드리면,

[02:48] 실제로 아키텍처를 고려했습니다.

[02:50] profile manager, resume builder,

[02:52] AI analyzer, export service 등 5개의 라이브러리를 생성했습니다.

[02:55] 또한 테스트 주도 설계를 구현하고 있어서

[02:57] 모든 테스트 구축에 대해 고려했습니다.

[02:59] 그리고 이게 정말 멋지다고 생각했는데,

[03:00] 실제로 contract first 접근법을 사용합니다.

[03:02] 즉, 코딩을 시작하기 전에

[03:04] API를 먼저 정의한다는 뜻입니다.

[03:05] 계획 단계에서 제공받은

[03:08] 아티팩트를 보면

[03:09] 여기에 정말 많은 것들이 있습니다.

[03:10] 앞서 언급했듯이

[03:12] 모든 API에 대한

[03:14] OpenAPI 명세서를 실제로 생성했습니다.

[03:17] 데이터 모델과 엔티티 관계 다이어그램도 제공해줬습니다.

[03:19] 여기서 모든 다른 테이블들과

[03:21] 그들이 어떻게 연결되는지 보여줍니다.

[03:22] 정말로 데이터베이스를 매핑했습니다.

[03:24] 스키마 정의도 있고,

[03:25] 성능을 위한 인덱싱 전략까지

[03:27] 고려했습니다.

[03:29] 정말 포괄적으로 작업했습니다.

[03:31] 제 생각에는 너무 포괄적일 수도 있지만,

[03:33] 그건 나중에 이야기하겠습니다.

[03:34]

[03:37] 이제 이러한 다양한 명령어들이

[03:38] 서로 어떻게 쌓이는지 볼 수 있습니다.

[03:40] specify로 시작해서 요구사항과

[03:42] 사용자 관점을 얻었습니다.

[03:44] 그 다음 계획 단계로 넘어가서

[03:45] 실제 기술에 대해 알아보고

[03:47] 정말 상세한 기술 명세서를 작성했습니다.

[03:48] 다음은 tasks입니다.

[03:50] 여기서 모든 계획을

[03:52] AI가 나중에 사용할 수 있는

[03:54] 개별 작업으로 분해하기 시작합니다.

[03:56] 그리고 task 명령어는 실제로

[03:58] 상대적으로 빠르게 실행되어 몇 분 만에

[04:00] 완료되었습니다.

[04:01] 그리고 여기서 볼 수 있는 것은

[04:03] tasks를 위한 마크다운 파일로, 기본적으로

[04:05] 먼저 plan.md를 로드한다고 합니다.

[04:07] 즉, 지난 단계에서 생성한 파일로

[04:09] AI가 모든 것을 구현하는 데 필요한

[04:10] 많은 세부사항을 제공하고

[04:12] 실제로 모든 것을 다양한 작업으로 분해합니다.

[04:14] 설정 작업, 데이터베이스 스키마 작업 등으로 말이죠.

[04:17] 정말 흥미롭다고 생각한 것은

[04:18] 테스트 주도 개발을 하고 싶어한다는 것입니다.

[04:20] 즉, 이 테스트들은 반드시 작성되어야 하고

[04:22] 구현이 시작되기 전에 반드시 실패해야 합니다.

[04:24] 모든 테스트를 작성하고 실패시킨 다음,

[04:26] 실제 애플리케이션 구현을 시작하겠다는 것입니다.

[04:28] 정말 흥미로운 개념입니다.

[04:30] 모든 것을 구현해보겠습니다.

[04:32]

[04:33] 이것을 구현해보고 실제로 잘 작동하는지 확인해보겠습니다.

[04:35] 특별한 명령어는 없습니다.

[04:37] 이제 구현이라고 말하고

[04:38] task.md 파일을 선택하기만 하면 됩니다.

[04:40] 그러면 다른 모든 plan MD와

[04:42] 필요한 모든 참조를 가져올 것입니다.

[04:45] 그래서 거기서 시작하는 것이 좋겠습니다.

[04:46] 좋습니다, 여기 있네요.

[04:48] 한 시간 넘게 걸렸습니다.

[04:50] 컨텍스트 윈도우가 여러 번 가득 찼습니다.

[04:51] 압축해야 했습니다.

[04:54] 여러 번 멈추기도 했습니다.

[04:55] 계속하라고 말해야 했어요.

[04:57] 이것은 정말 많은 토큰을 사용하지만

[04:59] 많은 코드를 작성했습니다.

[05:00] 이제 완전히 기능적이라고 말하고 있습니다.

[05:02] 완전한 사용자 인증, 인가,

[05:04] 스트리밍 응답이 있는 이력서 맞춤화,

[05:06] 그리고 신뢰도 점수를 가지고 있습니다.

[05:08] 많은 약속을 했습니다.

[05:10] 모든 API 키와

[05:11] Neon과 Clerk의 연결 문자열을 입력했습니다.

[05:13] 그리고 이것이

[05:14] 실제로 작동하는지 확인해보겠습니다.

[05:16] 안녕하세요, 저는 Ben입니다.

[05:17] AI 코딩에 관심이 있다면

[05:19] 제 뉴스레터인

[05:20] Unleash News를 구독하세요.

[05:22] AI 소프트웨어 개발의 최신 소식을

[05:23] 전해드리고

[05:24] 제가 작업하고 있는 내용도 알려드릴게요.

[05:27] 설명란의 첫 번째 링크에서

[05:29] 만날 수 있기를 바랍니다.

[05:31] 여기서 그 전체 과정의 최종 결과입니다.

[05:32] 첫인상은 꽤 좋아 보입니다.

[05:34] 꽤 깔끔합니다.

[05:35] 바로 작동했다는 것이 정말 좋았습니다.

[05:37] 꽤 멋졌습니다.

[05:39] 또한 Clerk 통합이 바로 작동했습니다.

[05:41] Gmail 계정으로 로그인하고 이름으로 인사했습니다.

[05:44] 꽤 멋집니다.

[05:45] UI 측면에서 보면

[05:47] 프로필 이력서와 같은 일부는 작동하는 것 같지만

[05:48] 템플릿에 도달하면

[05:50] 일종의 오류가 발생합니다.

[05:51] 실제로는 전체 애플리케이션을

[05:53] 완성하지 않았습니다.

[05:55] 이는 모든 계획에 비해

[05:56] 다소 실망스럽습니다.

[05:58] 그리고 몇 가지 핵심 부분을 빼먹었습니다.

[06:00] 예를 들어

[06:01] 새로운 프로필을 만들 수 있고 모든 정보를 보여주지만

[06:04] 다른 업무 경험,

[06:05] 교육, 기술에 대한

[06:07] 모든 메타데이터를 제공하지 않습니다.

[06:08] 전문 요약만 제공합니다.

[06:10] 그리고 그것도 저장할 수 없습니다.

[06:11] 저장 기능이 아직 구현되지 않았다는

[06:13] 팝업만 표시됩니다.

[06:15] UI 데모일 뿐이라고 하는데

[06:17] 이는 프로젝트를 완료했을 때 말한 것과

[06:20] 정반대입니다.

[06:21] 모든 것이 완성되었고

[06:22] 프로덕션 준비가 되었다고 말했습니다.

[06:23] 그래서 그 부분은 좀 실망스럽습니다.

[06:25] 이것은 정말 프로젝트의 첫 시작입니다.

[06:26] 완전한 프로젝트가 아닙니다.

[06:28] 또한 Next.js 14를 선택했는데

[06:30] 좋은 선택이 아니었다고 생각합니다.

[06:32] 그 모든 계획을 세웠다면

[06:33] 구식 버전을 선택하지 않았을 것이라고 생각했습니다.

[06:35] 제가 마음에 드는 부분으로는

[06:37] 일관된 컴포넌트 아키텍처를 정말 좋아합니다.

[06:39] 여기 소스 폴더에서 보시면

[06:40] 우리를 위해 이 모든 컴포넌트들을 구축했습니다.

[06:42] 관리와 상태 관리가

[06:44] 구현되어 있습니다. 앱 API를 살펴보면,

[06:46] 프로필, 이력서, 템플릿을 위한

[06:49] 다양한 API 엔드포인트가 있습니다.

[06:51] 헬스 API도 있어서 확인할 수 있습니다.

[06:53] API와

[06:54] 계약들을 정말 잘 분리하고 있습니다.

[06:56] 또한 specs 폴더에

[06:58] API에 대한 정말 좋은 문서들이 있어서

[07:00] 새로운 컴포넌트를 추가할 때

[07:02] 참조할 수 있습니다.

[07:03] 이 부분은 단순히 즉석으로 코딩하는 것보다

[07:05] 훨씬 잘 정리되어 있습니다.

[07:07] 또한 테스트 주도 개발을 하고 있어서

[07:08] 이런 테스트 폴더가 있습니다.

[07:09] 테스트를 계약 테스트,

[07:11] 통합 테스트, 라이브러리를

[07:12] 개별적으로 테스트하는 것, 성능 테스트,

[07:15] 그리고 단위 테스트로 나눈 방식이 마음에 듭니다.

[07:16] 적어도 여기서 시작된

[07:18] 포괄적인 테스트 스위트가 있습니다.

[07:20] 실제로는 기획 단계에서 했던

[07:21] 모든 작업을 바탕으로 제가 기대했던 만큼

[07:23] 완전하지는 않지만,

[07:24] 여전히 테스트를 위한 좋은 기반을 갖추고 있습니다.

[07:26] GitHub Spec Kit에 대한 제 초기 평가는

[07:28] 좋은 프레임워크이고 좋은 도구 세트라는 것입니다.

[07:30] 하지만 제게는 너무 많은 것을

[07:33] 하려고 한다고 생각합니다.

[07:34] 예를 들어 전체 애플리케이션 대신

[07:36] 새로운 기능에 대해서만 Spec Kit을

[07:38] 더 제한된 범위로 사용하는 실험을 해볼 생각입니다.

[07:40] 그러면 아마 더 유용할 것 같습니다.

[07:42] 너무 오랫동안 멀어져서

[07:43] 사용자 상호작용 없이 너무 많은 것을 한 점이

[07:46] 마음에 들지 않았습니다.

[07:47] 실제로 저는 AI와 코딩하는 것을 좋아하고

[07:49] 상호작용하는 것을 좋아합니다.

[07:51] 아직 한 시간씩 혼자서 가서

[07:53] 계획만 세울 만큼 충분히 좋지는 않다고 생각합니다.

[07:54] 그렇긴 하지만, Spec Kit 프레임워크를 살펴보면

[07:56] 온갖 훌륭한 마크다운 파일들이 있습니다.

[07:58] 그래서 자신에게 맞는 부분만 가져다가

[07:59] 원하는 방식으로

[08:01] 정확히 커스터마이즈하고

[08:02] 좋은 부분만 가져가서

[08:04] 너무 과한 부분은

[08:06] 옆에 두면 됩니다.

[08:07] 그것이 제가 취할 전략입니다.

[08:09] 영상을 즐겨주셨기를 바라고

[08:11] 멋진 하루 보내시기 바랍니다. 다음 영상에서 뵙겠습니다.