AI 시대에 더 중요해진 소프트웨어 기본기 - Matt Pocock의 5가지 실패 모드와 스킬
목차
개요
Matt Pocock이 Code with Claude 콘퍼런스에서 “소프트웨어 기본기가 그 어느 때보다 중요하다”라는 메시지를 던졌다. 그는 최근 “Clojure Code for Real Engineers”라는 강의를 준비하면서 AI 코딩 커리큘럼을 다듬는 과정에서 이 결론에 도달했다. 강연의 핵심 주장은 단순하다. “코드는 싸지 않다(Code is not cheap).” 오히려 나쁜 코드는 AI 시대에 그 어느 때보다 비싼 비용을 만들어낸다는 것이다.
이 글에서는 그가 제시한 5가지 실패 모드와 각각에 대응하는 스킬(skill)을 정리한다. 모든 스킬은 그의 GitHub 저장소 macpocockskills에 공개되어 있다.
스펙-투-코드 운동의 한계
컴파일러를 돌릴수록 나빠지는 코드
스펙-투-코드(specs-to-code) 운동은 다음과 같은 흐름을 주장한다. 애플리케이션의 동작을 명세로 작성한다. AI를 컴파일러처럼 사용해 명세를 코드로 변환한다. 문제가 생기면 코드를 보지 않고 명세만 수정한 뒤 다시 컴파일한다. Matt Pocock은 이 방식을 직접 시도해 보았다고 한다.
결과는 기대와 정반대였다. 처음에는 코드가 나왔지만, 다시 돌릴수록 더 나쁜 코드가 나왔다. 계속 컴파일러를 돌리니 결국 쓰레기 같은 코드만 남았다. 그는 이를 “코드를 무시하고 스스로 관리하게 두는 것은 다른 이름의 바이브 코딩일 뿐”이라고 평가한다.
소프트웨어 엔트로피
그는 두 권의 고전을 다시 펼쳤다. John Ousterhout의 A Philosophy of Software Design은 “나쁜 코드(complex code)”를 시스템을 이해하고 수정하기 어렵게 만드는 모든 구조적 요소로 정의한다. 즉, 바꾸기 어려운 코드베이스가 나쁜 코드베이스다. The Pragmatic Programmer는 “소프트웨어 엔트로피” 챕터에서 같은 현상을 설명한다. 시스템 전체의 설계를 생각하지 않고 개별 변경만 누적하면 코드베이스는 점점 더 나빠진다.
여기서 핵심 명제가 나온다. 좋은 코드베이스에서 AI는 정말 잘 동작한다. 따라서 좋은 코드베이스가 더 중요해졌고, 소프트웨어 기본기도 더 중요해졌다는 것이다.
5가지 실패 모드와 대응 스킬
실패 1 AI가 원하는 것을 만들지 않는다
머릿속에 있는 아이디어와 AI의 결과물이 어긋나는 경우다. The Pragmatic Programmer는 “누구도 자신이 원하는 것을 정확히 알지 못한다”라고 말한다. 사용자와 AI 사이에는 항상 커뮤니케이션 장벽이 있고, AI는 결국 요구사항 수집(requirements gathering)을 수행하고 있는 셈이다.
Frederick P. Brooks의 The Design of Design은 “디자인 컨셉(design concept)”이라는 개념을 제시한다. 둘 이상이 무언가를 함께 설계할 때, 둘 사이를 떠다니는 무형의 아이디어가 디자인 컨셉이다. 마크다운 파일에 담을 수 있는 자산이 아니라, “만들고 있는 것의 보이지 않는 이론”이다.
Matt Pocock의 대응 스킬은 Grill Me다. 스킬의 본문은 다음과 같이 매우 짧다.
1
2
3
4
Interview me relentlessly about every aspect of this plan
until we reach a shared understanding.
Walk down each branch of the design tree, resolving
dependencies between decisions one by one.
이 짧은 지시문이 AI를 끈질긴 면접관으로 바꾼다. 40개, 60개, 때로는 100개의 질문을 던지며 공유된 이해(shared understanding)에 도달할 때까지 멈추지 않는다. 그렇게 나온 대화는 그대로 PRD(Product Requirements Document)로 정리하거나, 작은 변경이면 이슈로 변환해 AFK(Away From Keyboard) 에이전트에게 넘긴다.
그는 Claude Code의 기본 plan mode보다 이 방식을 선호한다고 밝혔다. 기본 plan mode는 자산을 만들고 작업을 시작하려는 성향이 강한 반면, Grill Me는 디자인 컨셉을 먼저 정렬하는 데 더 적합하기 때문이다.
실패 2 AI가 지나치게 장황하다
AI가 같은 의도를 너무 많은 단어로 표현해 서로 다른 언어로 이야기하는 느낌이 드는 경우다. 이는 도메인 전문가와 일하는 개발자의 경험과 닮았다. 마이크로칩에 대해 모르는 개발자가 마이크로칩 도메인 전문가와 일하려면, 서로 사용하는 용어를 정렬해야 한다.
Matt Pocock은 도메인 주도 설계(DDD, Domain-Driven Design)에서 답을 찾았다. DDD의 “보편 언어(ubiquitous language)”는 개발자 간 대화, 코드의 표현, 도메인 전문가와의 대화가 모두 동일한 도메인 모델에서 파생되도록 한다. 실무적으로는 코드베이스와 AI가 공유하는 용어 목록이 담긴 마크다운 파일이다.
그는 Ubiquitous Language 스킬을 만들었다. 이 스킬은 코드베이스를 스캔해 용어를 추출하고, 용어 정의가 담긴 마크다운 테이블을 생성한다. 이 파일은 AI에게 전달하는 동시에 사람이 항상 열어두고 계획·구현 단계에서 참조한다.
| 항목 | 설명 |
|---|---|
| 도구 | macpocockskills 저장소의 ubiquitous language 스킬 |
| 산출물 | 도메인 용어 마크다운 파일 |
| 효과 | 계획 품질 향상, AI 사고의 장황함 감소, 구현이 계획과 정렬됨 |
AI의 사고 트레이스를 읽어보면, 보편 언어를 가진 AI는 덜 장황한 방식으로 사고하고 구현이 계획에 더 부합한다고 한다.
실패 3 코드가 동작하지 않는다
올바른 것을 만들었지만 동작하지 않는 경우다. 대응 방법은 익숙하다. TypeScript 같은 정적 타입, 프런트엔드 앱이라면 LLM에게 브라우저 접근권을 주는 것, 자동화된 테스트.
그러나 LLM은 이러한 피드백 루프를 능숙하게 활용하지 못한다. 한 번에 너무 많은 코드를 생성한 뒤에야 “아, 타입 체크를 해야겠다”라고 떠올리는 식이다. The Pragmatic Programmer는 이를 “헤드라이트보다 빨리 달리기(outrunning your headlights)”라고 표현한다.
“피드백의 속도가 곧 당신의 속도 제한이다(The rate of feedback is your speed limit).”
이에 대한 대응 스킬은 TDD(Test-Driven Development)다. TDD는 LLM이 작은 단계로 움직이도록 강제한다. 먼저 테스트를 만들고, 테스트가 통과하게 만든 뒤, 코드를 정리하고 설계를 다시 고민한다.
실패 4 테스트 가능한 코드베이스 만들기
문제는 테스트 작성 자체가 어렵다는 것이다. 단위 크기, 무엇을 모킹할 것인지, 어떤 행위를 테스트할 것인지 같은 결정들은 모두 서로 의존한다. “좋은 코드베이스는 테스트하기 쉬운 코드베이스”라는 관찰이 핵심이다.
Matt Pocock은 다시 John Ousterhout로 돌아간다. Ousterhout는 깊은 모듈(deep module)과 얕은 모듈(shallow module)을 구분한다.
| 모듈 유형 | 구조 | 인터페이스 |
|---|---|---|
| Deep module | 많은 기능을 내부에 숨김 | 단순한 인터페이스 |
| Shallow module | 적은 기능 | 복잡한 인터페이스 |
얕은 모듈로 가득한 코드베이스는 작은 블롭들이 흩어져 있어 AI가 의존성을 따라가기 어렵다. 결과적으로 AI는 코드를 이해하지 못하고 잘못된 위치에서 작업한다.
깊은 모듈로 구성된 코드베이스는 위쪽에 잘 설계된 인터페이스가 노출되고, 구현부는 그 뒤에 캡슐화된다. 인터페이스 설계는 사람이 강하게 통제하고, 내부 구현은 AI에게 맡겨도 된다.
그는 Improve Codebase Architecture 스킬을 통해 이 변환 작업을 정형화했다. 관련된 코드를 찾고, 그 주변에 깊은 모듈 경계를 두르는 단계들의 반복이다. 경계가 단순하므로 인터페이스 수준에서 테스트하고 검증할 수 있다. 즉, TDD를 보상하는 코드베이스가 만들어진다.
실패 5 두뇌가 코드 속도를 따라가지 못한다
피드백 루프가 잘 굴러가면 그 어느 때보다 많은 코드를 출하할 수 있게 된다. 문제는 사람의 두뇌가 이 속도를 따라가지 못해 그 어느 때보다 피곤해진다는 점이다.
해법은 깊은 모듈 구조에서 나온다. 각 모듈을 “그레이 박스(gray box)”로 다룬다. 인터페이스만 설계하고, 구현은 너무 자세히 들여다보지 않는다. 물론 금융 같은 크리티컬 영역에는 적용하기 어렵지만, 많은 모듈에서는 다음 조건만 만족하면 충분하다.
- 외부에서 테스트 가능한 경계가 있다.
- 모듈의 목적을 이해하고 외부에서 설계할 수 있다.
이 접근은 두뇌의 부담을 크게 줄여 준다. “인터페이스를 설계하고, 구현을 위임하라(Design the interface, delegate the implementation)”가 다섯 번째 팁이다.
이 원칙을 유지하려면 코드 변경이나 계획 단계에서 항상 애플리케이션의 모듈 지도를 의식해야 한다. 모듈 지도는 보편 언어의 일부가 되어야 하고, 계획 스킬에도 녹아들어야 한다. Matt Pocock은 PRD를 작성할 때 어떤 모듈의 인터페이스가 어떻게 바뀌는지 구체적으로 명시한다고 한다.
이 지점에서 Kent Beck의 격언이 등장한다. “매일 시스템 설계에 투자하라(Invest in the design of the system every day).” 스펙-투-코드는 정반대로 시스템 설계에서 손을 떼는 방향이다. Matt Pocock은 이 차이가 결정적이라고 본다.
의미와 시사점
이 강연은 AI 코딩 도구가 만들어내는 새로운 책임 분담 구조를 제시한다.
| 역할 | 담당 |
|---|---|
| AI | 현장의 전술적 프로그래머, 코드 변경을 수행하는 sergeant |
| 사람 | 전략 수준의 사고, 시스템 설계, 인터페이스 결정 |
AI가 전술 영역을 효율적으로 처리할수록, 사람은 전략과 기본기에 더 많은 시간을 쏟아야 한다. 즉, AI 시대에 가치를 잃은 것은 코드 타이핑이지 소프트웨어 기본기가 아니다.
또 한 가지 시사점은 스킬(skill) 단위의 재사용이다. Grill Me, Ubiquitous Language, Improve Codebase Architecture 모두 짧은 마크다운 지시문이지만, 명확한 소프트웨어 원칙을 LLM의 작동 방식에 주입한다. 좋은 스킬은 새로운 기법이 아니라 오래된 책에서 다시 꺼내온 원칙을 LLM이 일관되게 적용하도록 강제하는 도구다.
결론
Matt Pocock의 메시지는 한 줄로 요약된다. “코드는 싸지 않다.” 좋은 코드베이스에서 AI는 풍부한 가치를 만들어내지만, 나쁜 코드베이스에서는 그 잠재력이 무의미해진다. 따라서 디자인 컨셉 정렬, 보편 언어, TDD, 깊은 모듈, 인터페이스 위임 같은 20년 묵은 기본기는 폐기되는 것이 아니라 오히려 핵심 자산이 된다. 스펙-투-코드처럼 설계에서 손을 떼는 흐름과는 정반대 방향이며, 이 흐름이 다섯 가지 실패 모드를 만들어낸다. AI를 전술가로 두고, 전략은 우리가 매일 다듬어야 한다는 것이 이 강연이 남기는 실용적인 가이드라인이다.