요즘 유행하는 SDD, Spec Driven Development 운동을 경계하고 fundamentals와 craftmanship이 중요하다고 주장하는 입장입니다.
핵심 주장은 이거입니다:
AI가 코드를 더 많이, 더 빨리 만들수록 나쁜 architecture, 얕은 module, 빈약한 test, 불명확한 domain language는 더 빠르게 부채가 된다.
그래서 최근 SDD 방식으로 문제를 경험한 사람들 때문에 이 영상과 그의 skills repository가 바이럴 되고 있습니다.
아래 영상 요약 한 번 보시고 공감되시면 skills repository 가서 grill-me 한 번 써보시는 것도 괜찮을 것 같네요
@trendingrepo 채널에서도 여러번 소개됐던 스킬이었습니다
【26.04.26 일요일 오늘의 깃헙 트렌딩 repo 2번】
mattpocock / skills (https://github.com/mattpocock/skills)
• 🧩 코드 한줄 설명
에이전트가 PRD 작성, TDD, 리팩터링 같은 일을 더 잘하게 만드는 작업 스킬 모음입니다.
• ✅ 장점
코딩 에이전트 운영 패턴을 템플릿처럼 재사용하기 좋고, 실제로 어떤 업무를 스킬로 분리할지 감을 빠르게 잡게 해줍니다.
• 🗨 코드 코멘트
코드 라이브러리보다는 운영 노하우 모음에 가까워서 그대로 복붙하기보다 팀 방식에 맞게 덜어내는 편이 좋습니다.
• ♻️ 재등장 여부
신규
• 🤖 추천 여부: 추천
• 추천 이유: AI 코딩 에이전트의 실전 운영 감각을 익히는 레퍼런스로 좋습니다.
• 🎯 활용 예시 상황
팀 공통 .claude 스킬셋을 만들거나 개인 에이전트 워크플로를 정리할 때.
• 🌟 총 누적 stars 20,010
• ⚡️ 오늘의 stars 1,139
[영상 내용 요약]
1. AI 시대에도 소프트웨어 기본기가 중요한 이유
1.1. AI가 코드를 엄청 잘 만들어도, 결국 사람이 제대로 설계하고 관리하는 능력이 더 중요해짐
• 1.1.1. AI는 코드를 빨리 만들지만, 복잡한 코드를 계속 만들면 나중에 고치기 힘든 엉망진창 코드가 될 수 있음
• 1.1.2. 마치 로봇이 벽돌을 엄청 빨리 쌓아도, 설계도가 엉망이면 집이 무너지는 것과 같음
1.2. 소프트웨어 기본기는 예전부터 중요했지만, AI 시대에는 더 중요해짐
• 1.2.1. AI가 좋은 코드를 만들도록 사람이 잘 이끌어줘야 함
2. '스펙 투 코드' 방식의 문제점
2.1. '스펙 투 코드(Specs to Code)'는 설계도(명세)만 주고 AI가 코드를 만들게 하는 방식임
• 2.1.1. 문제가 생기면 코드를 직접 고치지 않고, 설계도만 바꿔서 AI에게 다시 코드를 만들라고 하는 식
• 2.1.2. 마치 요리 레시피만 계속 바꾸고, 실제 요리가 어떻게 만들어지는지는 신경 안 쓰는 것과 비슷함
2.2. 하지만 이 방식은 결국 엉망인 코드를 만들게 됨
• 2.2.1. 계속 시도해도 코드가 점점 더 나빠지고, 결국 쓸모없는 코드가 되어버림
• 2.2.2. 마치 레시피만 계속 고치다가 결국 맛없는 음식만 계속 만드는 것과 같음
2.3. 코드를 무시하고 AI에게만 맡기는 건 좋은 방법이 아님
• 2.3.1. 나쁜 코드는 고치기 어렵고, 버그를 많이 만들어서 결국 돈이 더 많이 들게 됨
• 2.3.2. 반대로 좋은 코드는 고치기 쉽고, AI가 더 잘 활용할 수 있게 함
3. AI와 소통하는 방법: 'Grill Me'
3.1. AI가 내가 원하는 대로 코드를 만들지 못하는 경우가 많dma
• 3.1.1. 내가 머릿속으로 생각한 것과 AI가 만든 결과물이 다를 때가 있음
• 3.1.2. 마치 내가 친구에게 '맛있는 거 만들어줘' 했는데, 친구가 내가 생각한 것과 전혀 다른 음식을 만들어주는 것과 같음
3.2. 이건 AI와 나 사이에 생각의 차이(디자인 컨셉)가 있기 때문
• 3.2.1. 우리가 만들려는 것에 대한 '보이지 않는 생각'이 서로 다를 수 있음
• 3.2.2. 마치 같은 그림을 그리는데, 서로 다른 그림을 상상하는 것과 같음
3.3. 이 문제를 해결하려면 AI와 'Grill me' 스킬을 사용하면 좋음
• 3.3.1. AI에게 "내가 계획한 모든 것에 대해 끊임없이 질문해서 서로 완벽하게 이해할 때까지 물어봐 줘"라고 시키는 방식
• 3.3.2. AI가 40~100개까지 질문을 하면서 내가 뭘 원하는지 정확히 파악하게 됨
• 3.3.3. 이렇게 하면 AI와 내가 같은 그림을 그리게 되고, AI가 더 정확한 코드를 만들 수 있음
4. AI와 같은 언어 사용하기: '공통 언어'
4.1. AI가 너무 장황하게 설명하거나, 내가 이해하기 어려운 말을 할 때가 있음
• 4.1.1. 마치 외국인과 대화하는데, 서로 다른 단어를 써서 오해가 생기는 것과 같음
4.2. 이럴 때는 '공통 언어(Ubiquitous Language)'를 만들어야 함
• 4.2.1. 나와 AI가 함께 사용하는 용어 목록을 만들거나
• 4.2.2. 마치 우리만의 '비밀 사전'을 만들어서, 그 단어들만 쓰는 방식
4.3. 이 공통 언어는 코드, 설계 문서, 그리고 AI와 대화할 때 모두 사용함
• 4.3.1. AI가 내 코드를 스캔해서 용어 목록을 자동으로 만들어주기도 함
• 4.3.2. 이렇게 하면 AI가 더 간결하게 생각하고, 내가 계획한 대로 코드를 만들게 됨
• 4.3.3. 마치 같은 언어를 쓰면 대화가 훨씬 잘 통하는 것과 같음
5. AI가 제대로 작동하는 코드를 만들게 하는 방법: '작게 나누어 테스트하기'
5.1. AI가 코드를 잘 만들었는데, 막상 돌려보면 작동하지 않을 때가 있음
• 5.1.1. 마치 로봇이 멋진 장난감을 만들었는데, 스위치를 눌러도 움직이지 않는 것과 같음
5.2. 이럴 때는 '피드백 루프(Feedback Loop)'를 활용해야 함
• 5.2.1. 자동화된 테스트나 타입스크립트(TypeScript) 같은 도구를 사용해서 AI가 만든 코드를 바로바로 확인하는 방식
• 5.2.2. 마치 요리사가 음식을 만들면서 중간중간 맛을 보며 간을 맞추는 것과 같음
5.3. AI는 한 번에 너무 많은 코드를 만들려고 해서 문제가 생김
• 5.3.1. 이건 마치 운전할 때 헤드라이트가 비추는 범위보다 훨씬 빠르게 달리는 것과 같음
• 5.3.2. 그래서 '테스트 주도 개발(TDD)' 방식을 사용해야 함
• • 5.3.2.1. 먼저 작은 테스트를 만들고, AI가 그 테스트를 통과하는 코드를 만들게 하는 식
• • 5.3.2.2. 그리고 코드를 더 좋게 다듬는 과정을 반복
• • 5.3.2.3. 마치 작은 목표를 하나씩 달성하면서 큰 목표에 도달하는 것과 같음
5.4. 'Deep Modules' 구조로 코드를 만들면 테스트하기 쉬워짐
• 5.4.1. 코드를 작은 상자들(모듈)로 나누는데, 이 상자들은 겉은 단순하지만 안에는 복잡한 기능들이 숨어있는 거임
• 5.4.2. 마치 장난감 상자 겉면에는 '자동차'라고만 쓰여 있지만, 안에는 복잡한 부품들이 들어있는 것과 같음
• 5.4.3. 이렇게 하면 AI가 코드를 이해하기 쉽고, 테스트도 간단하게 할 수 있음
• 5.4.4. Matt Pocock은 이 구조를 만들기 위해 '코드베이스 아키텍처 개선'이라는 기술을 사용함
5.5. 이렇게 하면 머리도 덜 피곤해짐
• 5.5.1. 나는 상자의 겉모습(인터페이스)만 설계하고, 안의 복잡한 내용은 AI에게 맡길 수 있음
• 5.5.2. 마치 내가 집의 외관과 방 배치만 정하고, 내부 인테리어는 전문가에게 맡기는 것과 같음
• 5.5.3. 결국, AI 시대에는 시스템 설계에 매일 투자하는 것이 가장 중요함
• 5.5.4. AI는 코드를 만드는 '전술가'이고, 우리는 전체를 지휘하는 '전략가'가 되어야 함