대부분의 개발자들은 AI를 자동 완성(autocomplete)처럼 사용합니다. 최고의 개발자들은 AI를 소프트웨어 엔지니어처럼 사용합니다.

지난 1년 동안 AI 코딩 어시스턴트(AI coding assistants)는 우리의 일상적인 워크플로(workflow)의 일부가 되었습니다. ChatGPT, Claude Code, Codex, Cursor 또는 GitHub Copilot을 사용하든, 이들은 몇 초 만에 코드를 생성할 수 있습니다.

하지만 여기에 문제가 있습니다:

우리 대부분은 여전히 다음과 같이 프롬프트(prompt)를 작성하고 있습니다:

"로그인 페이지를 만들어줘."

또는

"이 버그를 수정해줘."

하지만 결과는 어떠한가요?
때로는 훌륭합니다. 때로는 엉망진창입니다.
차이는 모델(model)에 있는 것이 아니라, 워크플로(workflow)에 있습니다.

Matt Pocock의 오픈 소스 Skills 저장소(repository)를 탐색한 후, 저는 중요한 사실을 깨달았습니다:

AI에게는 단순히 지시사항만 필요한 것이 아닙니다. 프로세스(process)가 필요합니다.

AI에게 코딩을 해달라고 요청하는 대신, 소프트웨어 엔지니어가 어떻게 일하는지를 가르쳐야 합니다.

AI 스킬(AI Skills)이란 무엇인가?

스킬(Skill)을 재사용 가능한 엔지니어링 워크플로(engineering workflow)라고 생각하세요.

AI에게 단일 프롬프트(single prompt)를 주는 대신, 구조화된 사고 방식을 제공하는 것입니다.

예시는 다음과 같습니다:

• 요구사항 이해하기 (Understanding requirements)
• 제품 요구사항 문서 (PRD, Product Requirements Document) 작성하기
• 구현 계획 세우기 (Planning implementation)
• 체계적인 디버깅 (Debugging systematically)
• 아키텍처 개선하기 (Improving architecture)
• 코드 작성 전 테스트 생성하기 (Creating tests before code)
• 인수인계 문서화하기 (Documenting handoffs)

그 결과는 일회성 프롬프트(one-off prompts)보다 훨씬 더 일관적입니다.

MVP를 구축하든 레거시 시스템(Legacy System)을 유지보수하든

이러한 워크플로(workflows)는 당신의 경험과 상관없이 유용합니다.

🚀 MVP 구축하기

코드를 작성하기 전에:

• 아이디어 검증하기 (Validate the idea)
• 요구사항 명확히 하기 (Clarify requirements)
• 로드맵 생성하기 (Create a roadmap)
• 작업을 관리 가능한 작업 단위로 나누기 (Break work into manageable tasks)

구현으로 서둘러 뛰어드는 대신, 의도를 가지고 구축합니다.

🏢 기존 제품 작업하기

대부분의 소프트웨어 엔지니어들은 그린필드 프로젝트(greenfield projects)를 만드는 것보다 소프트웨어를 유지보수하는 데 훨씬 더 많은 시간을 소비합니다.

스킬(Skills)은 다음과 같은 도움을 줍니다:

• 익숙하지 않은 코드베이스(codebases) 이해하기
• 방법론적으로 버그 조사하기 (Investigate bugs methodically)
• 점진적으로 아키텍처 개선하기 (Improve architecture incrementally)
• 팀의 나머지 인원을 위해 결정 사항 문서화하기 (Document decisions for the rest of the team)

내가 가장 좋아하는 스킬들

1. 나를 심문하라 (Grill Me)

즉시 코드를 생성하는 대신, AI는 질문을 던지기 시작합니다.

예시:

• 이 기능은 누구를 위한 것인가요?
• 어떤 문제를 해결하나요?
• 엣지 케이스 (Edge cases)는 무엇인가요?
• 어떤 제약 사항 (Constraints)이 존재하나요?

이는 마치 당신의 아이디어를 검토하는 시니어 엔지니어(Senior engineer)나 프로덕트 매니저(Product manager)처럼 행동하는 것입니다.

2. PRD 작성하기 (Write a PRD)

단순한 아이디어를 전문적인 제품 요구사항 문서 (Product Requirements Document, PRD)로 변환하세요.

훌륭한 PRD에는 다음 내용이 포함됩니다:

• 목표 (Goals)
• 사용자 스토리 (User stories)
• 범위 (Scope)
• 수락 기준 (Acceptance criteria)
• 리스크 (Risks)
• 성공 지표 (Success metrics)

이는 1인 개발자, 스타트업, 그리고 오픈 소스 (Open-source) 프로젝트에 믿을 수 없을 정도로 가치 있는 일입니다.

1. PRD → GitHub Issues

문서는 유용합니다.

실행 가능한 작업 (Actionable tasks)은 훨씬 더 유용합니다.

이 워크플로우 (Workflow)는 PRD를 자동으로 다음 항목들로 변환합니다:

• 에픽 (Epics)
• GitHub Issues
• 마일스톤 (Milestones)
• 의존성 (Dependencies)

애자일 개발 (Agile development)에 완벽합니다.

1. TDD (Test-Driven Development, 테스트 주도 개발)

구현으로 바로 뛰어드는 대신, AI는 고전적인 사이클을 따릅니다:

실패하는 테스트 작성
기능 구현
테스트 통과시키기
리팩터링 (Refactor)

오늘 당장 엄격한 TDD를 실천하지 않더라도, 이 워크플로우는 자연스럽게 더 깨끗하고 안전한 코드를 만들어냅니다.

1. 진단하기 (Diagnose)

제가 가장 좋아하는 것 중 하나입니다.

무언가 작동할 때까지 무작위로 코드를 바꾸는 대신, AI는 다음과 같이 수행합니다:

• 문제 재현 (Reproduce the issue)
• 가설 수립 (Builds hypotheses)
• 각 가설 검증 (Validates each hypothesis)
• 근본 원인 파악 (Finds the root cause)
• 해결책 제안 (Proposes a solution)

이것이 바로 숙련된 엔지니어들이 운영 환경 (Production)의 문제를 디버깅 (Debug)하는 방식입니다.

1. 줌 아웃 (Zoom Out)

때때로 AI는 단일 파일에 너무 집중합니다.

이 워크플로우는 AI가 더 큰 그림을 이해하도록 강제합니다:

• 프로젝트 구조 (Project structure)
• 모듈 (Modules)
• 의존성 (Dependencies)
• 아키텍처 (Architecture)
• 데이터 흐름 (Data flow)

특히 새로운 팀에 합류하거나 거대한 리포지토리 (Repository)를 탐색할 때 유용합니다.

1. 아키텍처 개선하기 (Improve Architecture)

기술 부채 (Technical debt)는 피할 수 없습니다.

이 스킬은 다음 사항들을 찾기 위해 당신의 프로젝트를 검토합니다:

• 거대한 클래스 (Large classes)
• 강한 결합 (Tight coupling)
• 중복 로직 (Duplicate logic)
• 미흡한 관심사 분리 (Poor separation of concerns)
• 더 나은 추상화 (Better abstractions)

마치 필요할 때마다 아키텍처 리뷰 (Architecture review)를 받는 것과 같습니다.

1. 핸드오프 (Handoff)

모든 엔지니어는 작업 세션을 마치며 다음과 같이 생각하곤 합니다:

"어디까지 했는지 기억할 수 있을 거야."

하지만 아마 그러지 못할 것입니다.

이 워크플로우 (Workflow)는 다음과 같은 내용을 포함하는 깔끔한 핸드오프 (Handoff) 문서를 생성합니다:

• 현재 진행 상황 (Current progress)
• 결정된 사항 (Decisions made)
• 남은 작업 (Remaining work)
• 알려진 문제 (Known issues)
• 다음 단계 (Next steps)

기기를 전환하거나, 다른 AI 어시스턴트 (AI assistant)를 사용하거나, 팀원과 협업할 때 완벽합니다.

추천하는 워크플로우

하루 종일 AI에게 무작위로 질문을 던지는 대신, 다음과 같은 방식을 추천합니다:

💡 새로운 아이디어 (New Idea)
│
▼
🧠 나를 검증하기 (Grill Me)
│
▼
📝 PRD 작성하기 (Write a PRD)
│
▼
📋 GitHub 이슈 생성하기 (Generate GitHub Issues)
│
▼
🧪 TDD로 빌드하기 (Build with TDD)
│
▼
🐛 버그 진단하기 (Diagnose Bugs)
│
▼
🏗 아키텍처 개선하기 (Improve Architecture)
│
▼
📄 핸드오프 생성하기 (Create a Handoff)

이는 숙련된 엔지니어링 팀이 실제로 일하는 방식을 반영합니다.

주니어 개발자에게 이것이 중요한 이유

소프트웨어 엔지니어링 여정을 막 시작했다면, 이러한 워크플로우는 단순히 코드를 짜는 법이 아니라 숙련된 엔지니어가 어떻게 사고하는지를 가르쳐 줍니다.

여러분은 자연스럽게 다음을 배우게 될 것입니다:

1. 요구사항 분석 (Requirement analysis)
2. 제품 사고 (Product thinking)
3. 소프트웨어 아키텍처 (Software architecture)
4. 디버깅 (Debugging)
5. 테스트 (Testing)
6. 문서화 (Documentation)

이것들은 주니어에서 시니어로 성장을 가속화하는 기술들입니다.

시니어 개발자가 관심을 가져야 하는 이유

시니어 엔지니어는 타이핑 속도로 평가받지 않습니다.

그들은 얼마나 결정을 잘 내리는가로 평가받습니다.

구조화된 AI 워크플로우를 사용하면 다음과 같은 도움이 됩니다:

• 컨텍스트 스위칭 (Context switching) 감소
• 코드 품질 (Code quality) 향상
• 개발 관행 (Development practices) 표준화
• AI 출력물의 예측 가능성 향상
• 생성된 코드를 다시 쓰는 대신 문제를 해결하는 데 더 많은 시간 할애

마치며

✅ AI는 소프트웨어 엔지니어링 원칙을 대체하지 못할 것입니다.

✅ 오히려 원칙들을 더욱 중요하게 만듭니다.

✅ 프로세스가 더 나을수록, 여러분의 AI도 더 나아집니다.

✅ AI 어시스턴트에게 단순히 코드를 써달라고 요청하는 것을 멈추세요.

✅ 여러분의 엔지니어링 팀이 어떻게 일하는지 가르치기 시작하세요.

미래의 여러분과 팀원들이 고마워할 것입니다.

어떤 AI 워크플로우가 여러분의 일상적인 개발에 가장 큰 차이를 만들어냈나요? 여러분이 어떻게 활용하고 계신지 정말 듣고 싶습니다.

이것은 이 GitHub 저장소의 요약입니다. 꼭 확인해 보세요!!

mattpocock / skills

진짜 엔지니어를 위한 기술 (Skills). 나의 .claude 디렉토리에서 직접 가져왔습니다.

진짜 엔지니어를 위한 기술 (Skills For Real Engineers)

단순히 느낌대로 코딩하는 것(vibe coding)이 아니라, 실제 엔지니어링을 수행하기 위해 제가 매일 사용하는 에이전트 기술(agent skills)입니다.

실제 애플리케이션을 개발하는 것은 어렵습니다. GSD, BMAD, Spec-Kit과 같은 접근 방식들은 프로세스를 직접 소유함으로써 이를 돕고자 합니다. 하지만 그 과정에서 사용자의 통제권을 앗아가고, 프로세스 도중에 발생하는 버그를 해결하기 어렵게 만듭니다.

이 기술들은 작고, 적응하기 쉬우며, 조합 가능한(composable) 형태로 설계되었습니다. 어떤 모델과도 함께 작동합니다. 수십 년간의 엔지니어링 경험을 바탕으로 만들어졌습니다. 마음껏 실험해 보세요. 여러분만의 것으로 만드세요. 즐기시기 바랍니다.

퀵스타트 (30초 설정)

1. skills.sh 설치 프로그램을 실행합니다:

npx skills@latest add mattpocock/skills

2. 원하는 기술과 이를 설치할 코딩 에이전트(coding agents)를 선택합니다. 반드시 다음을 선택하세요 …

GitHub에서 보기