유튜브 AI 팁 보고서 — 2026-09-08 — 스펙주도개발

오늘의 영상 4편 · 누적: 팁 568개 / 다룬 영상 143편(후보 등재 1,146편)

한눈에 (TL;DR)

• 네 편이 서로 다른 도구로 같은 첫 단계에 도달했다 — 코드보다 명세가 먼저. Spec Kit(영어), GSD(한국어), OpenSpec(한국어), 발표자 자작 툴킷(영어)으로 각각 설명했는데 첫 명령이 전부 "구현 말고 사양부터"였다. 서로 모르는 네 편의 교차 확인이 이번 호에서 가장 강한 신호다.
• 세 편은 그 다음 단계도 같았다 — 명세·계획 문서를 코드와 함께 커밋한다. 근거는 조금씩 다르다: 인수인계 시 '왜 이렇게 만들었나'의 이력(Gui Ferreira), 대화창을 닫아도 남는 저장소(큰돌의터전), 세션을 깨끗이 리셋하기 위한 체크포인트(Andrea Bizzotto). 결론은 하나 — 결정은 채팅창이 아니라 파일에 산다.
• 가장 값싼 반대편은 30일 실사용 후기였다. 같은 저자가 절차를 설명하고 대가도 계산했다: 스펙→동작까지 피드백 사이클이 길어 결과가 어긋나면 스펙 수정보다 전면 롤백이 잦고, 문서가 컨텍스트를 잡아먹어 Claude Max 한도를 처음으로 소진했으며, 몇 주 지나 compaction이 돌면 TDD 지시 같은 프로세스가 유실된다.

오늘의 팁

1. 새 기능은 먼저 명세로 왜·무엇·어떻게 쓰일지부터 답하라

• 방법: 순서를 지킨다. ①specify: "why we are building this?", "what we are building?", "how will it be used?" 세 질문에 답한다 → 기능 요구사항이 도출된다. ②plan: 그제서야 '어떻게 만들 것인가', 어떤 기술을 쓸 것인가를 결정한다. ③tasks: plan과 spec에서 구현 태스크를 뽑는다. ④implementation: 태스크를 하나씩 순서대로 구현한다. 각 단계마다 불명확한 것이 드러나고 거기서 결정을 내린다.
• 출처: I Used GitHub's Spec Kit for 30 Days. Here's the Truth. — Gui Ferreira · 03:20
• 교차 확인: 오늘 네 편 전부. 큰돌의터전은 "스펙은 어떻게 만들지가 아니라 무엇을 만들지를 적는 것"이라며 구현 방법은 오히려 빼라고 못박고, 독자를 사람이 아닌 AI로 두라고 한다. OpenSpec 편은 같은 자리를 propose 단계(제안서·명세·설계 3종 문서)로, Andrea Bizzotto는 spec 명령(=PRD)으로 부른다.
• 보정: 피드백 사이클이 길어 그 사이 다른 일을 하다 진행 중인 것을 잊게 되고, 결과가 마음에 안 들면 스펙 수정이 쉽지 않아 전부 롤백하고 처음부터 다시 하는 경우가 잦다(Gui Ferreira 자기 보고).

2. 명세·계획·리서치 문서를 풀 리퀘스트에 함께 커밋해 결정 이력을 남겨라

• 방법: spec → plan → tasks 과정에서 생성되는 리서치 문서와 결정 기록을 그대로 pull request의 일부로 커밋한다. 트레이드오프·명확히 한 사항·기능 요구사항·계획·접근 방식이 전부 마크다운으로 저장소에 남아 추론의 완전한 이력이 된다. 나중에 넘겨받은 개발자가 '왜 이렇게 만들었나'를 spec과 plan으로 되짚을 수 있다.
• 출처: I Used GitHub's Spec Kit for 30 Days — Gui Ferreira · 08:05
• 교차 확인: 큰돌의터전은 같은 것을 "결정을 대화창에 두지 말고 파일로 디스크에 쓴다"로 말한다(.planning 디렉토리, 사람도 AI도 읽고 깃 커밋도 되며 컨텍스트를 지워도 다시 읽힘). Andrea Bizzotto는 단계마다 커밋해 세션을 새로 시작할 수 있게 하고(스펙 55,000 토큰·계획 직전 80,000 토큰 시점에 리셋), 끝에 push make PR로 완료 태스크 목록이 담긴 PR을 자동 생성한다.
• 보정: 문서가 많이 생성되는 만큼 컨텍스트로 끌려 들어가는 양도 커서 토큰을 크게 소모한다 — 발표자는 이것 때문에 Claude Max 한도를 처음 소진했다. commit all·push make PR은 Andrea Bizzotto의 유료 툴킷 명령이라 툴킷 없이는 그대로 쓸 수 없다.

3. 기존 프로젝트에는 먼저 constitution 파일을 생성해 규칙을 정의하고 모든 명세가 이를 따르게 하라

• 방법: brownfield(기존) 프로젝트에서는 Spec Kit의 핵심 파일인 constitution을 먼저 만든다. constitution은 그 프로젝트에서 통용되는 규칙과 무슨 일이 벌어지고 있는지의 정의다. 이후 모든 spec이 이 constitution을 존중하게 하고, 이미 있는 것들 위에 spec으로 기능을 쌓는다. 설치 시 설정 폴더 간 링크를 만들면 팀원이 다른 코드 어시스턴트를 써도 같은 spec과 프로세스를 공유한다.
• 출처: I Used GitHub's Spec Kit for 30 Days — Gui Ferreira · 09:10
• 보정: "적어도 시작은 할 수 있다" 수준이라고 스스로 말한다. 브라운필드에서 잘 안 되는 부분이 따로 있고, 몇 주 지나면 컨텍스트가 빠르게 차 compaction이 돌면서 TDD 같은 지시가 유실돼 프로세스가 그대로 지켜지지 않는다.

4. 구현 전에 AI가 임의로 정할 빈칸을 먼저 글로 채워라

• 방법: "게시판 만들어 줘" 같은 일곱 글자 지시는 빈칸이 99%인 스펙이다. 구현 전에 최소한 이런 것을 글로 정한다 — 로그인을 구글로 할지 이메일로 할지 아예 없앨지, 글쓴이 이름을 실명으로 보여줄지 익명으로 할지, 댓글을 1단계까지 허용할지 아예 허용하지 않을지. 정하지 않은 항목은 AI가 목표 달성을 위해 혼자 결정해 버린다.
• 출처: K사 개발자가 설명하는 클로드코드로 스펙주도 개발하기 — 큰돌의터전 · 01:30

5. 버그가 나오면 코드를 먼저 고치지 말고 스펙을 고친 뒤 코드를 재생성하라

• 방법: 원본(진실)은 스펙이고 코드는 스펙에서 다시 뽑아낼 수 있는 출력물로 본다. 버그를 발견하면 코드를 바로 고치지 말고 스펙을 고치고, 바뀐 스펙으로 코드를 다시 생성한다.
• 출처: K사 개발자가 설명하는 클로드코드로 스펙주도 개발하기 — 큰돌의터전 · 03:50
• 보정: 원문도 '원칙적으로'라는 단서를 단다. 테스트와 달리 스펙은 통과/실패를 기계적으로 알려주지 않아 검증 절차가 따로 필요하다고 스스로 말한다.

6. 프로젝트 목적·범위·로드맵·현재 상태를 각각 별도 마크다운 파일로 분리해 두어라

• 방법: GSD 프로젝트를 만들면 .planning 디렉토리가 생긴다. project.md에는 이 프로젝트가 왜 존재하는지(목표·비전), requirements.md에는 범위(무엇을 만들고 무엇을 만들지 않을지), roadmap.md에는 전체 방향과 단계, state.md에는 지금 어디까지 왔고 무엇을 결정했는지를 계속 갱신해 담는다. 하위 폴더에는 단계별 계획서와 검증 기록이 쌓인다.
• 출처: K사 개발자가 설명하는 클로드코드로 스펙주도 개발하기 — 큰돌의터전 · 09:10
• 보정: 파일명은 자동 자막의 음성 인식 표기(점플래닝·requirement먼트.md 등)에 근거하므로 실제 철자는 GSD 문서로 확인이 필요하다.

7. 무엇을 만들지 막연할 땐 explore로 코드베이스를 읽히고 방향부터 잡아라

• 방법: Node가 설치된 상태에서 터미널 한 줄로 OpenSpec을 설치하고 프로젝트 폴더에서 초기화 명령을 한 번 실행한다. 그다음 explore를 부르면 AI가 코드를 먼저 읽고 어떤 방법들이 있는지 따져 계획을 함께 잡아준다(예: 다크 모드를 어떻게 깔끔하게 넣을지).
• 출처: AI한테 코드부터 시키면 다시 짜는 이유 | 스펙 주도 개발 OpenSpec — 헤이제임스 · 01:40
• 보정: 설치·초기화를 '한 줄', '초기화 명령'이라고만 말하고 실제 명령어 문자열은 영상에 나오지 않는다 — 그대로 따라 하려면 OpenSpec 공식 문서가 필요하다.

8. propose로 제안서·명세·설계·할 일 체크리스트를 한 변경 폴더에 만들어라

• 방법: 만들고 싶은 기능을 적어 propose를 부르면 그 변경 하나를 담을 폴더가 생기고, 안에 제안서(왜)·명세(요구사항과 시나리오)·설계(기술적 해법)·할 일 체크리스트가 각각 들어간다. 생성된 문서를 AI와 함께 다듬어 생각을 맞춘 뒤 구현으로 넘어간다.
• 출처: AI한테 코드부터 시키면 다시 짜는 이유 | OpenSpec — 헤이제임스 · 02:00
• 보정: 폴더 경로·파일명 규칙과 propose 호출 형식은 영상에 없다.

9. apply로 합의된 할 일 체크리스트를 순서대로 하나씩 구현시켜라

• 방법: apply를 부르면 앞 단계에서 만든 체크리스트를 AI가 순서대로 하나씩 처리한다(예: 테마 전환 버튼 → 색상 변수 → 설정 저장). 구현 시작 전에 대화 맥락을 한 번 깨끗이 비우고, 추론을 잘하는 상위 모델로 돌리면 결과가 더 좋다.
• 출처: AI한테 코드부터 시키면 다시 짜는 이유 | OpenSpec — 헤이제임스 · 03:10
• 보정: 중간에 끊어 검토하는 방법은 언급되지 않고 체크리스트를 자동으로 죽 처리한다는 설명만 있다 — 통제를 원하면 팁 13을 함께 본다.

10. 기능 완성 후 archive로 변경을 보관하고 프로젝트 명세를 최신화하라

• 방법: 기능을 다 만든 뒤 archive를 부르면 이번 변경이 날짜와 함께 보관함으로 들어가고 프로젝트 명세가 최신 상태로 갱신된다. 그러면 곧바로 다음 기능의 explore 단계로 들어갈 수 있다. 가끔 업데이트 명령을 실행하면 최신 명령어와 안내가 프로젝트에 다시 맞춰진다.
• 출처: AI한테 코드부터 시키면 다시 짜는 이유 | OpenSpec — 헤이제임스 · 03:30
• 보정: '업데이트 명령'의 실제 이름과 archive 산출물의 저장 위치는 영상에 없다.

11. 초기 아이디어를 채팅창이 아닌 번호 매긴 파일로 적고 스펙 명령에 입력으로 넘겨라

• 방법: ai_specs 폴더에 순번을 붙인 파일(예: 028-history-chart-stacked)을 만들고 현재 동작과 원하는 동작을 문장으로 적는다. 예: "Currently, the history page shows a line chart of my total portfolio value over time as a single line chart. However, I would like to show a stacked line chart so I can see how different investment types grow or shrink over time." 저장·커밋한 뒤 코딩 CLI에서 @028-history-chart-stacked로 참조해 spec 명령의 입력으로 넘긴다.
• 출처: Spec-Driven Development with AI: Building a Real Flutter Feature Step by Step — Andrea Bizzotto · 07:30
• 보정: 폴더명·번호 규칙은 발표자 개인 관례이며 툴이 강제하는 형식이 아니다.

12. refine spec으로 스펙과 실제 코드베이스 간 갭·불일치를 적대적으로 검증하라

• 방법: 생성된 spec을 먼저 커밋하고(그래야 컨텍스트를 버려도 된다) 새 세션에서 refine spec <스펙파일>을 실행한다. 에이전트가 관련 파일을 읽어 스펙의 가정을 검증하고 라이브러리가 원하는 동작을 지원하는지 같은 구현 리스크까지 확인한 뒤 critical → important → minor 순으로 문제와 제안을 정리한다. 동의하지 않는 항목은 직접 답을 타이핑한다. 예: "For the stacking order on point four, consider the most recent snapshot in time and sort the different investment types by decreasing value on that specific snapshot, such that the largest value is at the bottom of the stack. Proceed with the remaining suggestions."
• 출처: Spec-Driven Development with AI (Flutter) — Andrea Bizzotto · 17:40
• 보정: 지적 내용이 코드베이스에 밀착돼 매우 기술적이라 발표자조차 세부를 설명하지 않고 넘어간다. 이 편 전체가 본인 유료 툴킷(Flutter 특화) 홍보이며, 스펙을 잘 써도 Y축 클리핑 같은 UI 문제는 남아 수동 QA가 필수라고 스스로 인정한다.

13. 구현은 단계별 통제가 필요하면 --single-phase 플래그로 한 페이즈씩 끊어라

• 방법: plan 파일은 여러 phase로 나뉘고 각 phase가 목표와 체크리스트를 갖는다(예: phase 1 TDD·journey 테스트, phase 2 렌더링, phase 3 선택 동작·범례). work 명령을 그냥 실행하면 모든 phase를 연달아 구현하며 중간중간 개별 커밋을 만든다. 더 세밀한 통제를 원하면 --single-phase를 붙여 첫 미완료 phase만 끝내고 멈추게 하고, 여러 세션에 걸쳐 phase 단위로 진행한다.
• 출처: Spec-Driven Development with AI (Flutter) — Andrea Bizzotto · 23:00
• 보정: 정작 영상에서는 플래그를 지우고 전체를 한 번에 돌려 단계별 실행 화면은 시연되지 않는다.

시도 후보

• 빈칸 목록 먼저 묻기(팁 4): 다음 앱·계기 요청 때 구현 전에 'AI가 혼자 정하게 될 항목' 3~5개를 뽑아 먼저 확인한다.
• 계획 대 코드 갭 검증(팁 12): 수리 계획을 세운 뒤 새 세션에서 그 계획만 주고 "코드베이스와 어긋나는 가정을 critical/important/minor로 정리하라"를 한 번 돌려 본다.
• 요청을 번호 파일로(팁 11): 긴 요청 하나를 ai_specs/NNN-제목 형식으로 적어 보고 재참조가 실제로 쓸모 있는지 본다.

오늘의 영상

• I Used GitHub's Spec Kit for 30 Days. Here's the Truth. — Gui Ferreira · 26,893회 · 24:15 · 2026-03-16 — 오늘 유일하게 절차와 대가를 같은 입으로 말한 편. 4단계를 설명한 뒤 토큰 소모·롤백·compaction 유실을 자기 경험으로 계산한다. 정면 회의론 영상은 아니지만 오늘 반대편 시각의 대부분이 여기서 나왔다.
• K사 개발자가 설명하는 클로드코드로 스펙주도 개발하기 — 큰돌의터전 · 6,236회 · 9:03 · 2026-07-27 — 한국어 층이자 오늘 가장 신선(6주 전). 9분에 원리 세 개(무엇만 적기·빈칸·스펙이 진실)를 압축했고 도구 소개가 아니라 판단 기준을 말한다. 팁 밀도 대비 길이가 가장 짧다.
• AI한테 코드부터 시키면 다시 짜는 이유 | 스펙 주도 개발 OpenSpec — 헤이제임스 · 2,559회 · 6:35 · 2026-07-01 — 6분 35초에 explore→propose→apply→archive 한 바퀴가 다 들어 있다. 사이클 전체를 이름 붙여 보여준 유일한 편이지만, 실제 명령어 문자열이 하나도 나오지 않아 그대로 따라 하려면 문서가 필요하다.
• Spec-Driven Development with AI: Building a Real Flutter Feature Step by Step — Andrea Bizzotto · 2,231회 · 34:14 · 2026-05-08 — 오늘 유일하게 실제 기능 하나를 끝까지 만든다. spec 섹션 구성·refine 단계·phase 통제·토큰 시점까지 수치로 말해 재현성이 가장 높다. 다만 본인 유료 툴킷 홍보이고 명령 상당수가 그 툴킷 소유다.

지켜볼 점 / 내일 주제 후보

• 어제 코딩 호가 '한 편도 정독 못했다'고 남긴 층을 오늘 걷었다. 도구 이름(Spec Kit·OpenSpec·BMAD·Kiro)으로 건 질의가 주제어 질의보다 훨씬 나은 후보를 냈다 — §2-3 ③번 규칙이 또 확인됐다. 반면 'BMAD'는 통과 후보가 거의 없었고(한 편은 아예 삭제된 영상) 'Kiro'는 검색 자체가 9건에 그쳤다.
• 화석층 비율이 이례적으로 높았다 — 날짜 확인 69편 중 180일 통과는 27편(39%)뿐. 탈락 42편의 대부분이 2025년 9~11월, 즉 Spec Kit 공개 직후 쏟아진 같은 무리의 튜토리얼이었다. 계절성 규칙이 여섯 번째로 확인됐다.
• '스펙 주도 개발' 도구 시장이 이미 갈라졌다. 오늘 네 편이 각각 다른 도구(Spec Kit·GSD·OpenSpec·자작 툴킷)를 쓰는데 절차 이름은 거의 같다(사양→계획→태스크→구현). 도구 이름을 따라가면 같은 팁을 네 번 수집하게 되므로, 다음에 이 주제를 걸면 도구가 아니라 실패 지점(스펙 수정 vs 롤백, 컨텍스트 유실, 스펙 검증)으로 걸어야 한다.
• 아직 안 읽은 인접 층: 스펙과 테스트의 관계(SDD+TDD), 그리고 팀 단위 도입기. 오늘 통과 27편 중 SDD+TDD 편이 있었으나 층 균형으로 제외했다.
• 내일 주제 후보: 음성(네 호 연속 지목되고도 계속 밀렸다) / 디버깅(어제 코딩 호 지목) / 신도구.

이 호의 한계

• 자막만 읽었고 실제로 돌려보지 않았다 — 효과는 전부 검증 전이다.
• 검색 8질의(한국어·영어 원천·도구 고유명사 4종·회의론·행위 어휘) 91건 → 중복·원장 제외 후 76편. 이 중 상위 70편만 날짜 조회했고 6편은 편수 상한에 걸려 조회하지 않았다(원장에도 넣지 않았으므로 다음 호에 다시 후보로 올라온다). 1편은 조회 실패했다 — uqgeskWQGuE(BMAD, "This video is not available").
• 날짜 확인 69편 중 180일(2026-03-12) 통과 27편, 그중 정독 4편. 통과분 나머지 23편은 주제 적합도·층 균형으로 not_selected, 탈락 42편은 too_old로 원장에 남겼다.
• 자막 전사 실패 0편(4편 전부 성공). 팁 후보 53개 중 13개 채택.
• 정면 회의론 영상은 없었다. 회의론 질의("spec driven development overrated problems")로 6개월 안쪽 통과분이 마땅치 않아, 30일 실사용 후기(Gui Ferreira)가 그 자리를 대신했다. 반대편 시각의 독립성은 그만큼 약하다.
• 자동 자막의 고유명사 표기가 불확실한 곳이 있다 — GSD의 .planning 파일명(팁 6)은 음성 인식 결과라 실제 철자를 확인하지 않았다.