오랫동안 실무 코딩을 놓고 있던 친구가 얼마 전 AI로 상용에 배포할 수준의 대시보드를 만들었다고 했다. 원래 C 개발자인데, vue, spring-boot, rdb, docker까지 자기에게 익숙하지 않은 기술을 엮어서 해냈다. 비결을 물으니 답이 의외로 단순했다. 구성원을 믿듯 AI를 믿고 꾸준히 시도했더니 결과가 나오더라는 것이다. 그 친구 회사의 팀원들 중에는 "전무님이니까 하실 수 있는 것"이라며 자신들은 안 된다고 하는 분들도 있었다고 한다.

그런데 나는 그 일을 조금 다르게 본다. 믿음의 문제가 아니다. 그 친구는 실무 코딩에서 손을 뗀 뒤에도 문제를 정의하고(명세) 결과를 따져보는(검증) 일만큼은 멈춘 적이 없었을 것이다. 구현만 다른 사람에게 맡겨왔을 뿐이다. AI에게 구현을 맡긴 지금도 그가 한 일은 똑같았다. 그가 잘해낸 진짜 이유는 믿음이 아니라, 명세와 검증 역량 때문이라고 생각한다.

그러고 보면 AI와 일을 잘한다는 건 새로운 능력이 아니다. 프로그래밍은 원래 명세하고, 구현하고, 검증하는 과정이었다. AI는 그중 구현을 잘 가져갔을 뿐이다. 그래서 남은 명세와 검증이 중요해졌다. 이 글은 그 두 가지에 대한 이야기다.

명세-구현-검증, 원래 그랬다

Dave Farley는 프로그래밍의 핵심을 세 가지로 정리한다.

1. 명확하게 설명할 수 있을 만큼 문제를 충분히 이해하기 (Understand the Problem in Detail)

2. 그 설명을 컴퓨터가 실행할 수 있는 것으로 변환하기 (Translate into Executable Form)

3. 만든 것이 실제로 작동하고 원래 문제를 해결하는지 검증하기 (Verify the Solution solves the Problem)

AI를 쓴다고 이 원칙이 달라지지는 않는다. 다만 문제를 이해한 후에 실행 가능한 코드를 작성하는 메커니즘이 달라진 것 뿐이다. 한 행씩 직접 코딩하는 대신, AI와 협업을 해서 코드 덩어리를 만든다. 기계적인 작업, 즉 JPA나 REST 같은 우발적 복잡성은 AI가 곧잘 해낸다. 하지만 가장 어렵고 창의적인 부분, 곧 문제를 정밀하고 모호하지 않게 정의하는 본질적 복잡성은 여전히 사람의 몫이다.

결국 AI에게 구현을 시키고 남은 일은 두 가지이다. 문제를 제대로 정의하는 명세, 그리고 결과를 따져보는 검증.

명세 — 문제를 정의하고 설계도를 그리기

명세는 경험이 있으면 AI의 도움으로 꽤 잘 작성할 수 있다. 나는 문제를 정의하는 단계에서 superpowers의 brainstorming 스킬이나 claude code의 planning 모드를 활용한다. 명확하지 않은 상태로 시작해 AI와 대화하며 요구사항을 또렷하게 만들어가는 데 큰 도움이 된다.

다만 명세에는 욕심을 내야 한다. 엔지니어는 설계를 하고, 설계도가 있으면 언제나 같은 결과가 나와야 한다(deterministic). AI 이전의 소프트웨어 엔지니어링에서 그 설계도는 코드였다. 이제는 프롬프트와 스펙이 그 자리를 차지한 것 같다. 하지만 프롬프트와 스펙은 코드만큼 deterministic하지 않다. 그래서 나는 명세를 최대한 deterministic하고 repeatable하게 쓰려 애쓴다. 같은 명세에서는 늘 비슷한 결과가 나오도록.

구현은 더 많은 도움을 받는다. claude code의 auto mode, superpowers의 writing-plans, execute-plans의 도움을 받으면 끝까지 주욱 구현이 된다.

그렇게 마지막에 검증이 남는다.

그리고 검증이 병목이 된다.

하나하나 다 들여다보려면 차라리 내가 짜는 게 낫겠다 싶고, 그렇다고 무작정 승인해서 상용에 배포하기에는 겁이 난다.

검증 — 그런데 왜 이해까지 해야 할까

누군가는 물을 수 있다. 결과만 잘 나오면 됐지, 왜 굳이 이해까지 해야 하느냐고.

나는 프로그래밍의 본질에서 답을 찾는다. 프로그래밍의 주된 목적은 프로그램을 생산하는 것이 아니라, 그 문제가 프로그램 실행을 통해 어떻게 해결되는지에 대한 이론, 곧 머릿속의 멘탈 모델을 구축하는 것이다 (Peter Naur, Programming as Theory Building).

이 멘탈 모델이 없으면 부채가 쌓인다. 그런데 이 부채는 우리가 알던 것과 성격이 다르다. 과거의 기술 부채는 설계 품질이 낮아 변경 비용이 커지고 작업이 더뎌지는, 생산성 저하의 문제였다. 하지만 AI 시대의 인지적 부채는 다르다. 멘탈 모델 없이 쌓인 부채는, 정작 문제가 터졌을 때 손을 댈 수 없게 만든다. 느려지는 정도가 아니라 대처 자체가 불가능해지는 것이다.

vibe 코딩의 위험이 여기에 있다. 동작 원리를 낱낱이 알지 못하니, 그 안에 무슨 문제가 숨어 있는지도 알 수 없다. 당장은 돌아간다. 하지만 멘탈 모델 없이 운영하다 문제가 터지면, 그 시스템을 더 이상 손볼 수 없는 상황을 맞는다.

2025년 10월, AWS의 US-EAST-1 리전에서 대규모 장애가 있었다. 원인은 DNS 문제였지만, 사람들을 놀라게 한 건 원인을 규명하는 데 75분이나 걸렸다는 점이었다. 늘 빠른 복구를 자랑하던 AWS였다. 이 사건을 분석한 Corey Quinn은 기술이 낡아서가 아니라, 비슷한 문제를 겪고 그 패턴을 기억하던 베테랑 엔지니어들이 떠났기 때문이라고 했다. 시스템을 이해하던 사람들의 머릿속 지식, 트라이벌 지식(tribal knowledge)이 사라진 것이다.

AI에게 코드를 맡기고 이해를 건너뛰는 것도 결국 우리가 같은 문제를 겪게 한다. 코드는 그대로 남아 있어도, 멘탈 모델이 AI에게만 있고 팀 안에는 아무도 그 시스템을 이해하지 못하는 상태. 말하자면 버스 팩터가 0인 셈이다.

무엇을, 어떻게 검증하나

그렇다면 무엇을 검증해야 할까. 일을 어떻게 나눴는지를 보면 분명해진다. 우발적 복잡성은 AI가 한 번에 곧잘 해내니, 내가 리뷰할 핵심은 본질적 복잡성, 즉 도메인을 설계하고 메서드를 추출하고 역할에 따라 코드를 나눈 부분에 있다.

조직의 리더로서 나는 DB, Infra, UI처럼 내가 잘 이해하지 못하는 영역의 업무에도 책무(accountability)가 있다. 그 책무를 다하는 길은 하나다. 내가 이해할 수 있어야 한다. 구성원들의 전문성이 아무리 뛰어나도, 내가 이해하지 못하는 것에 책무를 질 수는 없다.

물론 한 줄 한 줄 작성할 때마다 물어보지는 않는다. 그들의 전문성과 책임감을 신뢰하기 때문이고, 한 줄씩 다 검토할 거면 (내가 할 수 있다면) 내가 하는 게 빠르기 때문이다. 대신 나는 이렇게 일한다.

시작하기 전에 가치와 왜, 무엇을 설명한다.

구현 방향을 함께 논의하고 합의한다.

진행 중 이슈가 있으면 논의하자고 한다.

중간에 과정과 일정을 점검한다.

마지막에 최종 결과물을 리뷰한다.

항공기를 설계한 엔지니어가 나사 하나하나까지 직접 검증하지는 않는다. 마찬가지로 프롬프트와 스펙으로 구현을 맡긴 사람이 모든 소스 라인을 검증할 수는 없다. 정적 분석 툴과 테스트로 일부는 거를 수 있지만, 그것만으로는 충분치 않다. 결국 내 머릿속에 멘탈 모델이 있어야 하고, 그러려면 이해를 해야 한다.

그래서 최종 리뷰 자료는 내가 이해할 수 있는 수준이어야 한다. 아니면 나를 이해시키든가. 인프라나 frontend처럼 내 전문 지식이 부족한 영역은, 그 전문성을 가진 구성원에게 내가 이해할 수 있게 설명해 달라고 요청해서 검증한다.

AI에게도 똑같이 한다.

그리고 이것이 지금까지 내가 찾은 가장 좋은 검증 방법이다. 사람 동료에게 그랬듯, AI에게 내가 이해할 수 있는 수준으로 설명해 달라고 요청하는 것. 중간 리뷰와 최종 검증에서 LLM이 쏟아내는 문장이 어렵다면 그냥 넘어가지 않는다.

쉽게 가시화해서 설명해 달라고 요청한다 (필요한 경우 인터랙티브하고 가시성이 높은 html로 설명·리뷰해 주는 스킬을 활용한다)

프로젝트별로 내 지식과 숙련도를 미리 설정해 두고, AI가 내 수준에 맞춰 설명하고 리뷰를 요청하게 한다.

설명을 듣는 것만으로 부족할 때도 있다. AI가 짠 코드가 아무리 훌륭해도, 그것만으로 내 머릿속에 멘탈 모델이 생기지는 않는다. 코드가 좋아서 이해되는 게 아니라, 내가 그 코드를 직접 만지고 테스트를 돌려보고 리팩터링하며 맥락을 직접 만들어냈을 때 비로소 이해되기 때문이다. 그래서 나는 개선이 목적이 아니라 이해가 목적인 '스크래치 리팩토링'을 한다. 인수 테스트와 crap, dry, mutation test로 결과를 검증한다. 그리고 시스템의 개념적 일관성(Conceptual Integrity)을 향한 리팩터링을 거치며 비로소 멘탈 모델을 확보한다.

결국

AI와 일하는 법은 완전히 새로운 무엇이 아니다. 프로그래밍은 원래 명세하고, 구현하고, 검증하는 과정이었다. AI는 그중 구현을 잘 가져갔고, 그래서 명세와 검증이 더 또렷하게 내 몫으로 남았다.

명세는 경험이 있으면 AI의 도움으로 잘 작성할 수 있다. 문제는 검증(새로운 병목)이다. 그리고 검증의 핵심은 결국 이해다. 내가 찾은 가장 좋은 방법은, 사람에게 그랬듯 AI에게 내가 이해할 수 있게 설명해 달라고 요청하고, 직접 만져보며 멘탈 모델을 만드는 것이다.

위임은 하되, 이해만큼은 내 몫으로 남겨 두어야 한다. 그 이해, 곧 멘탈 모델을 놓는 순간, 우리는 인지적 부채에 잠기게 될 테니까.

AI와 함께 개발하기 - 은탄환은 없다

댓글