AI가 잘하는 시대일수록 펀더멘털은 더 중요해진다

요즘 AI로 코드를 짜다 보면 "Code is cheap" 이라는 말을 자주 듣습니다. 어차피 AI가 다 짜주니까 코드는 일회용이고, 결국 중요한 건 스펙(spec)이라는 거죠.

근데 솔직히 일을 해보면 좀 갸우뚱한 느낌이 들 때가 많습니다. AI가 코드를 빠르게 뽑아주긴 하는데, 결과물 품질은 코드베이스 상태에 따라 천차만별이거든요. 깔끔하게 정리된 코드베이스에선 한 줄만 시켜도 알아서 잘 하는데, 좀 엉켜있는 코드베이스에선 길게 설명해도 엉뚱한 데를 고치고 있는 식이었습니다.

그러던 중에 Matt Pocock의 영상 두 편을 보게 됐습니다. Matt Pocock은 제가 타입스크립트를 처음 배울 때 정말 많이 참고했던 유튜버라서, 이 분이 AI 코딩 얘기를 한다고 했을 때부터 좀 궁금했었어요. 영상은 컨퍼런스 강연(Software Fundamentals Matter More Than Ever)과, 그 강연 이후에 본인이 만든 스킬을 갈아엎은 후속 영상(I stopped using /grill-me for coding) 인데, 두 영상이 제가 막연히 느끼던 부분을 정리해줘서 도움이 많이 됐습니다.

이번 글에서는 영상에 등장하는 스킬들을 잠깐 짚고, Grill Me 스킬이 v2(Grill with Docs)로 어떻게 진화했는지 가볍게 다루려고 합니다. 그리고 본론으로 "AI를 쓸수록 펀더멘털이 왜 더 중요해졌는지" 에 대한 생각을 좀 더 길게 적어보려고 합니다.

1. 스킬은 결국 AI와 말이 통하게 만드는 도구

영상에서 Pocock이 만든 스킬이 몇 개 등장하는데, 처음엔 그냥 좋은 프롬프트 모음으로 보였습니다. 근데 자세히 보면 각 스킬이 풀려는 문제가 명확히 다릅니다.

1.1 Grill Me

가장 먼저 등장하는 게 Grill Me입니다. 사실 별 거 없습니다. 단 4문장짜리 프롬프트인데, 요약하면 "공유된 이해에 도달할 때까지 끝없이 인터뷰해줘" 입니다. AI에게 design tree의 가지를 따라 내려가며, 결정들 사이의 의존성을 하나씩 짚어보도록 시킵니다.

이게 풀려는 문제는 결국 "AI가 내가 원하는 걸 안 만들어준다" 입니다. 같이 무언가를 설계하는 두 사람 사이에는 무형의 "머릿속 그림" 이 떠다니는데, 사람과 AI도 똑같이 그걸 공유해야 한다는 거죠. Grill Me는 그걸 어쩔 수 없이 맞추도록 만드는 스킬이라고 보면 됩니다.

Claude Code의 기본 plan 모드보다 이게 좋다고 본 이유는, plan 모드는 plan markdown 같은 산출물을 만드는 데 너무 급한 반면, Grill Me는 산출물보다 머릿속 그림을 먼저 맞춘다는 점입니다. 저도 plan 모드를 쓰다가 "어 잠깐, 내가 이걸 시킨 게 맞나?" 싶었던 적이 종종 있었는데, 그 지점을 정확히 짚어준 느낌이었습니다.

1.2 Ubiquitous Language

두 번째 스킬은 DDD에 나오는 ubiquitous language를 그대로 가져온 겁니다. 코드베이스를 한 번 훑어서 도메인 용어를 마크다운 표로 정리해두는 단순한 스킬입니다.

풀려는 문제는 "AI가 같은 걸 매번 너무 많은 단어로 설명한다" 입니다. 같은 개념을 매번 길게 풀어쓰는 대신 "이 도메인에선 이 단어가 이 뜻이다" 를 한 번만 합의해두면, AI의 thinking trace도 짧아지고 변수명이나 파일명까지 자연스럽게 정렬됩니다.

1.3 ADR

ADR(Architectural Decision Record)은 스킬이라기보다는 그냥 포맷에 가깝습니다. 글로서리(ubiquitous language)로는 표현이 안 되는, 되돌리기 어려운 결정을 마크다운 한 장으로 남깁니다.

예를 들어 라이브러리 A와 B 중 뭘 쓸지처럼 나중에 갈아끼울 수 있는 결정은 ADR로 안 남겨도 됩니다. 한 번 정하면 코드 곳곳에 퍼져서 되돌리기 어려운 결정, 또는 컨텍스트 없이 보면 이상해 보이는 결정만 ADR로 남기는 게 핵심입니다.

2. Grill Me는 어떻게 Grill with Docs로 진화했나

여기서 재밌는 부분이 있습니다. Pocock은 본인이 만든 Grill Me가 입소문이 나서 매일 5명씩 좋다는 메시지를 받는데도, 후속 영상에서 "나는 더 이상 코딩에는 Grill Me를 안 쓴다" 라고 선언합니다.

이유는 좀 단순합니다. Grill Me를 계속 쓰다 보니까 같은 문제가 반복됐던거죠.

매번 도메인의 not-obvious한 부분을 처음부터 설명해야 했고, 세션 중에 공들여서 만든 좋은 용어가 끝나면 휘발돼버렸습니다. 다음 세션이 되면 또 처음부터 다시 설명. 영상에선 "standalone video" 라는 용어를 예로 드는데, 본인 입장에선 너무 당연한 단어인데도 AI는 매번 처음 듣는 단어처럼 굴어서 verbose하게 풀어줘야 했다고 합니다.

그래서 처음에는 Grill Me 세션을 하다가 Ubiquitous Language 스킬을 중간에 끼워서 같이 썼다고 합니다. 그러다가 "이거 그냥 합쳐버리는 게 낫겠다" 해서 만든 게 Grill with Docs 입니다.

2.1 v2가 개선한 부분

Grill with Docs는 Grill Me의 4문장은 그대로 들고 가면서 세 가지를 더 얹었습니다.

먼저 세션을 시작할 때 context.md 를 자동으로 읽어옵니다. DDD의 bounded context 개념을 그대로 가져온 건데, 모노레포처럼 큰 곳이면 여러 개의 context map으로 나눠두고, 작은 레포면 루트에 하나만 두는 식입니다.

그리고 세션 중에 새로 등장한 용어가 기존 글로서리와 충돌하면, 그 자리에서 짚고 넘어가도록 만들어놨습니다. 영상에 나오는 실제 세션을 보면, 구현 디테일은 한참 뒤에 나오고 그 앞에서 AI가 "pitch와 standalone video의 카디널리티가 모호한데 1:N 맞느냐", "기존 standalone video 정의랑 충돌이 나는데 어떻게 정리할거냐" 같이 언어 차원의 충돌부터 잡습니다.

마지막으로 세션이 끝나면 합의한 내용을 다시 context.md에 업데이트 합니다. 한 번 합의한 게 다음 세션에도 살아남는 거죠.

이걸 두 줄로 정리해보면 이렇습니다.

합의된 언어가 휘발되지 않고 누적된다 → 다음 세션이 점점 짧아진다
언어 정렬이 구현 직전이 아니라 가장 먼저 일어난다 → 코드, 변수명, UI 텍스트까지 자연스럽게 같은 단어로 맞춰진다

참고로 Pocock은 Grill Me가 죽은 건 아니라고 합니다. 코드베이스가 없는 상황에서는 여전히 Grill Me가 최고라고 하는데, 영상에 어머니 추도사를 쓰던 사람이 Grill Me로 어머니에 대한 기억을 끌어냈다는 사연이 나와서 인상 깊었습니다. 코드베이스가 있으면 Grill with Docs, 없으면 Grill me 정도로 역할만 나눠둔 거죠.

여기까지가 영상에서 소개한 스킬과 v2에 대한 이야기입니다. 사실 이번 글에서 더 길게 적어보고 싶었던 건 다음 내용입니다.

3. "Code is cheap" 이 거짓말인 이유

요즘 한참 유행하는 specs-to-code 사조의 핵심 주장은 대충 이렇습니다.

스펙만 잘 쓰면 된다. 코드는 어차피 AI가 다시 쓴다. 코드 보지 말고 스펙만 봐라.

Pocock도 본인이 직접 해봤다고 합니다. 결과는 좀 충격적이었는데, 컴파일러(=AI)를 한 번 돌릴 때마다 코드가 점점 더 나빠졌다고 합니다. 처음엔 그래도 봐줄 만 한데, 두 번째 돌리면 더 안 좋아지고, 세 번째 돌리면 그냥 garbage가 나왔다는 거죠.

이건 결국 소프트웨어 엔트로피 라고 부르는 현상이랑 똑같습니다. 시스템 전체의 설계를 신경 쓰지 않고 부분 변경만 누적시키면, 시스템은 반드시 무너지는 방향으로 갑니다. AI는 그 부분 변경을 사람보다 훨씬 빠르게 누적시키니까, 무너지는 속도도 같이 빨라지는 거고요.

그래서 "Code is cheap" 이라는 말은 반은 맞고 반은 틀린 것 같습니다. 코드를 짜는 시간은 분명히 싸졌습니다. 근데 나쁜 코드의 비용은 오히려 더 비싸졌다고 봅니다. 왜냐하면 좋은 코드베이스에서는 AI가 정말 잘 동작하고, 나쁜 코드베이스에서는 AI가 빠른 속도로 나쁜 코드를 누적시키기 때문입니다.

이게 두 영상의 가장 큰 메세지인 것 같습니다.

AI 시대에는 좋은 코드베이스가 더 중요해진다. 좋은 코드베이스를 만드는 능력 = 소프트웨어 펀더멘털이다.

4. 펀더멘털이 왜 더 중요해졌나

영상에서는 펀더멘털이 필요한 지점을 실패 모드별로 매핑하는데, 그 중 제가 보면서 와닿았던 4가지를 정리해보겠습니다.

4.1 공용 언어가 없으면 AI는 끝없이 장황해진다

도메인 전문가랑 일해본 분들은 다 아는 경험이 있을 거에요. 처음 며칠은 도메인 용어를 모르니까 30분 회의가 한 가지 주제에서 막혀있다가, 한 달쯤 지나면 한 단어로 끝납니다. DDD의 ubiquitous language가 노리는 효과가 정확히 이거죠.

AI랑 일할 때도 똑같았습니다. AI도 결국 언어로 사고하는데, 합의된 짧은 단어가 없으면 매번 "이전에 이런 식으로 처리하던 video 중에서 lesson에 묶이지 않은 것들..." 이렇게 길게 풀어 설명해야 합니다. 그 verbose한 사고가 그대로 코드에 반영되니까 변수명도 길어지고, 파일명도 길어지고, 결국 코드 리뷰도 힘들어지는 식입니다.

신기한건 이게 새로운 기술이 아니라는 점이에요. 20년 전 DDD에서 사람끼리 협업하려고 만든 기법이, AI와의 협업에서도 거의 그대로 통한다는게 흥미로웠습니다.

4.2 Deep module이 아니면 AI는 길을 잃는다

영상에서 인상 깊었던 개념이 하나 있었는데, 좋은 모듈은 인터페이스가 단순하고 내부는 깊다(deep), 나쁜 모듈은 인터페이스가 복잡하고 내부는 얕다(shallow) 는 거에요.

문제는 AI가 기본적으로 shallow module을 만드는 경향이 있다는 점입니다. 자잘한 함수 수십개를 만들고, 인터페이스를 잔뜩 노출시키죠. 그런 코드베이스에선 AI 본인도 길을 잃습니다. 어디서 뭐가 일어나는지 추적이 안 되니까 잘못된 모듈을 고치거나, 의존성을 놓치고 변경을 하게 됩니다.

좋은 코드베이스의 정의가 바뀐 게 아니라, AI라는 새 협업자가 합류하면서 좋은 코드베이스의 가치가 더 올라간 거라고 보면 될 것 같습니다.

4.3 피드백 루프가 곧 속도 제한이다

"헤드라이트보다 더 빨리 달리지 말라" 는 말이 있는데, AI는 기본적으로 헤드라이트 따위 안중에도 없이 달립니다. 타입 체크 한 번 안 하고 수백 줄을 쓰거나, 테스트 한 번도 안 돌리고 다음 task로 넘어가버리는 식이죠.

그래서 영상에서 추천하는 게 TDD입니다. 테스트 먼저 쓰고, 통과시키고, 리팩토링하는 사이클이 결국 AI에게 작은 보폭으로 걷도록 강제합니다.

근데 여기서 중요한 게 있는데, 테스트는 좋은 코드베이스에서만 잘 쓸 수 있다는 점이에요. shallow module이 잔뜩 있는 코드베이스에선 뭘 mock해야 하는지, 어디까지가 한 unit인지가 불분명해서 테스트 자체가 깨지기 쉽고 결국 의미가 없어집니다.

다시 같은 결론으로 돌아옵니다. 좋은 코드 → 좋은 테스트 → 좋은 피드백 → 좋은 AI 결과물. 이 사슬의 가장 앞에 있는 게 결국 코드 설계 능력입니다.

4.4 인터페이스는 설계하고, 구현은 위임하라

이 부분이 개인적으로 가장 와닿았습니다. AI 덕분에 코드를 빠르게 짤 수 있게 되니까, 오히려 사람 뇌가 못 따라가는 상황이 생기더라구요. AI가 짠 코드를 한 줄 한 줄 다 리뷰하려고 하면 금방 번아웃이 옵니다.

해법은 모듈 경계를 사람이 설계하고, 내부 구현은 AI에게 맡기되 경계에서 검증하는 거였습니다. 모듈을 일종의 회색 박스(gray box) 로 다루는 거죠. 인터페이스만 잘 설계되어 있으면 내부를 매번 정독할 필요가 없습니다. 외부에서 테스트만 잘 걸어두면 끝입니다.

물론 결제나 보안처럼 critical한 영역은 여전히 내부까지 다 봐야 합니다. 다만 앱의 대부분은 회색 박스로 운영해도 큰 문제가 없다는 게 핵심이라고 봤습니다.

이게 가능하려면 결국 인터페이스를 잘 짜는 능력이 필요한데, AI는 인터페이스를 그렇게 잘 짜진 못합니다. 그건 도메인 이해랑 트레이드오프 판단이 같이 가야하는 일이라서, 사람이 해야합니다.

5. AI 시대의 개발자는 sergeant가 아니다

Pocock이 강연 마지막에 쓴 비유가 좋았습니다. AI는 현장의 sergeant(부사관)고, 사람은 그 위에서 전략을 짜는 사람이라는 비유입니다.

AI는 정해진 모듈 안에서 정해진 인터페이스를 구현하는 일은 정말 잘합니다. 어떻게보면 사람보다 잘하는것 같기도 해요. 다만 아래 같은 결정들은 여전히 사람이 해야 합니다.

이 도메인에서 어떤 단어가 어떤 의미인가 (ubiquitous language)
모듈을 어디서 끊을 것인가 (bounded context, deep module)
어떤 결정이 돌이키기 어려운가 (ADR)
어떤 인터페이스가 좋은 인터페이스인가

결국 정리해보면 "무엇(What)을 만들 것인가" 와 "어떻게(How) 구조화할 것인가" 의 영역입니다. 예전에 선언적 프로그래밍 글에서 적었던 결론이랑도 자연스럽게 이어집니다. AI 시대의 개발자는 task를 처리하는 사람이 아니라, 시스템의 흐름을 설계하는 사람이라는 것.

강연에 인용된 한 줄이 핵심인 것 같습니다.

Invest in the design of the system every day.

specs-to-code의 가장 큰 문제는 시스템 설계에 매일 투자하지 않고 오히려 거꾸로 가는 행위라는 거에요. 코드 설계를 안 보고, 스펙만 보고, 결과물은 AI한테 맡긴다는 건 시스템 설계의 책임을 AI에게 떠넘기는 건데, AI는 그 책임을 감당할 능력이 (적어도 지금은) 없는 것 같습니다.

6. AI 포모(FOMO) 그리고 결국 남는 것

사실 이번 글을 쓰면서 한 번 더 깨달은 게 있는데, 요즘 AI 관련 신기능, 신모델, 신스킬, 신도구가 정말 하루가 멀다 하고 쏟아져 나오잖아요. 잠깐 한눈 팔면 새로운 워크플로우가 등장해 있고, MCP 서버는 또 새로 생기고, 어제 봤던 best practice가 오늘은 outdated 라는 식의 글이 올라와 있고. 솔직히 저도 그걸 다 따라가야 할 것 같은 압박감, 일종의 AI 포모(FOMO)를 자주 느꼈습니다.

처음엔 그게 정상이라고 생각했어요. "어차피 새 도구가 더 좋을 텐데 빨리 갈아타야지" 하면서 매번 워크플로우를 갈아엎곤 했습니다. 그런데 어느 순간부터 이게 좀 비효율적이라는 생각이 들었습니다. 새 도구를 익히는 데 시간이 더 들었고, 그 사이에 정작 제가 풀고 있던 문제는 그대로 남아있었거든요.

근데 이번 영상들을 보면서 좀 마음이 가벼워졌습니다. 어차피 이 새로운 스킬들도 다 뜯어보면 결국 예전부터 있던 얘기더라구요. Grill Me도, Grill with Docs도, 사실 새 발명이라기보다는 오래된 책에 나오는 얘기를 AI 시대에 맞춰서 다시 꺼낸 것에 가까웠습니다.

그러다보니 모든 새 도구를 다 따라잡을 필요는 없다는 생각이 들었어요. 어차피 결국 같은 얘기를 조금씩 다른 포장으로 내놓는 거고, 펀더멘털만 잘 잡혀있으면 새 도구가 나와도 "아 이거 그 얘기네" 하고 금방 따라갈 수 있으니까요. 반대로 펀더멘털 없이 도구만 쫓아다니면 매번 처음부터 다시 배우는 느낌이 들 것 같습니다.

생각해보면 결국 안 변하는 건 펀더멘털이고, 도구는 그때그때 옷만 갈아입는 것 같아요. AI 포모에 휘둘리지 않는 가장 빠른 방법이 오히려 가장 오래된 책들을 다시 펴는 거였다는 게, 좀 역설적이지만 정직한 결론인 것 같습니다.

7. 마무리

두 영상을 같이 보고 나니까 가장 명료해진 게 이 한 줄이었습니다.

좋은 코드베이스에서는 AI가 사람보다 빠르고, 나쁜 코드베이스에서는 AI가 사람보다 빠르게 무너뜨린다.

스킬이나 프롬프트는 결국 표면에 보이는 부분이고, 그 아래엔 도메인 이해, 언어 설계, 모듈 경계, 테스트, 인터페이스 같은 펀더멘털이 그대로 있는 것 같습니다. AI가 이걸 대신 해주는 게 아니라, 오히려 이게 잘 갖춰져 있어야 AI가 제 성능을 냅니다.

저도 한동안 "AI가 다 짜주는데 굳이 펀더멘털을 깊게 팔 필요가 있을까?" 라는 의문이 들 때가 있었습니다. 근데 두 영상을 보고 나서는 오히려 반대 방향으로 정리되더라구요. AI가 잘 짜줄수록 펀더멘털의 ROI가 더 높아지는 시대인것 같다는 생각입니다. 결국 AI는 도구고, 그 도구를 더 잘 쓰기 위한 가장 빠른 길이 펀더멘털이라는 결론으로 돌아오게 됩니다.

Reference