마틴 파울러가 본 AI 코딩의 역설, 코드는 싸지고 검증은 비싸진다

한눈에 보기

• 원문 성격: 2026년 4월 2일 마틴 파울러가 올린 짧은 기술 단상 모음
• 핵심 질문: AI가 코딩을 싸게 만들면 개발에서 무엇이 비싸지는가
• 중요한 변화: 코드 작성보다 검증, 이해, 의도 기록의 가치 상승
• 핵심 개념: 기술 부채, 인지 부채, 의도 부채라는 세 겹의 부채
• 서비스 의미: 앞으로 돈이 되는 영역은 코드 생성보다 검증 인프라와 맥락 관리
• 실무 결론: 강한 개발팀은 많이 만드는 팀보다 맞는 것을 설명하고 확인하는 팀

서론

마틴 파울러가 2026년 4월 2일 올린 Fragments: April 2는 긴 칼럼이 아니다. 짧은 메모 몇 개를 이어 붙인 글이다. 그런데 이상하게도 읽고 나면 머릿속에 질문 하나가 오래 남는다.

AI가 코드를 많이, 빠르게, 싸게 만들 수 있다면 개발에서 정말 비싼 것은 무엇이 될까.

처음에는 답이 뻔해 보인다. 더 빨리 만드는 팀, 더 많은 기능을 배포하는 팀, 더 적은 사람으로 더 많은 코드를 쓰는 팀이 이길 것 같다. 하지만 파울러가 소개한 글들을 따라가면 이야기는 조금 다른 방향으로 꺾인다.

코드가 싸질수록 오히려 비싸지는 것이 있다. 바로 검증, 공유 이해, 의도 보존이다. AI 코딩 논쟁이 “개발자가 사라질까”에 머무를 때, 파울러의 메모는 더 현실적인 질문을 던진다. 개발자의 일이 코드 작성에서 무엇이 맞는지 판단하는 일로 옮겨가고 있는 것은 아닐까.

1. 짧은 메모들이 사실은 한 방향을 가리킨다

파울러의 글은 다섯 갈래로 흩어져 보인다. AI가 만든 코드와 팀의 이해 문제, 사람의 사고가 AI에 기대는 문제, 코드 아이콘에 늘 꺾쇠괄호를 쓰는 문제, 코딩 에이전트 시대의 검증 비용, 그리고 소스 코드의 미래 이야기까지 나온다.

겉으로는 서로 다른 조각이다. 하지만 한 줄로 묶으면 꽤 선명하다. 코드를 쓰는 일은 쉬워지는데, 그 코드가 왜 맞는지 설명하는 일은 더 어려워지고 있다.

원문을 길게 직역하기보다 의미를 따라 옮기면 이렇게 정리할 수 있다.

• 코드 생산: AI가 코드를 빠르게 늘리면서 팀의 이해 속도를 앞지를 수 있음
• 사고 방식: AI를 조수로 쓰는 것과 판단을 넘겨주는 것은 전혀 다른 문제
• 검증 비용: 실행이 싸질수록 “맞는 결과”를 정의하는 일이 더 비싸짐
• 코드의 미래: 소스 코드가 사라진다기보다 좋은 이름과 추상화가 더 중요해짐

이 네 가지는 결국 같은 문제로 모인다. AI는 코드를 만들 수 있지만, 시스템이 지켜야 할 뜻까지 자동으로 보존해 주지는 않는다. 그래서 개발팀은 이제 “얼마나 많이 만들었나”보다 “무엇을 이해했고 무엇을 확인했나”를 더 자주 물어야 한다.

 

반응형

2. 기술 부채 옆에 새로운 빚이 생겼다

개발자에게 기술 부채는 익숙한 말이다. 급하게 만든 구조, 테스트 없는 핵심 로직, 이름이 맞지 않는 함수, 복잡하게 꼬인 의존성처럼 나중의 변경을 어렵게 만드는 빚이다.

파울러가 먼저 소개한 마거릿앤 스토리의 논문 From Technical Debt to Cognitive and Intent Debt은 여기서 한 걸음 더 나간다. 2026년 3월 23일 처음 공개된 이 논문은 생성형 AI 시대에는 코드 안의 빚만 볼 수 없다고 말한다.

새로 봐야 할 빚은 두 가지다. 하나는 인지 부채다. 코드는 바뀌었는데 팀이 그 변화를 이해하지 못하는 상태다. 다른 하나는 의도 부채다. 왜 그런 결정을 했는지, 어떤 제약을 지켜야 하는지, 무엇을 절대 바꾸면 안 되는지가 기록에서 사라지는 상태다.

이 차이는 작아 보이지만 현장에서는 크게 다가온다. 예전에는 나쁜 코드가 문제였다. 이제는 겉으로 멀쩡한 코드도 문제가 될 수 있다. 테스트는 통과하지만 아무도 설명하지 못하는 코드, 기능은 돌아가지만 왜 그런 조건이 필요한지 모르는 코드가 늘어날 수 있기 때문이다.

AI가 코드 생산 속도를 높이면 코드, 사람, 기록에 쌓이는 부채를 함께 봐야 한다

3. 가장 위험한 순간은 코드가 잘 돌아갈 때다

인지 부채가 무서운 이유는 조용히 쌓이기 때문이다. 빌드는 통과하고, 테스트도 초록색이고, 배포도 끝났다. 겉으로 보면 성공이다. 그런데 누군가 “이 로직은 왜 이렇게 돌아가나요”라고 물었을 때 아무도 설명하지 못한다면 이미 빚은 쌓인 상태다.

AI 코딩 도구는 이 문제를 더 빠르게 만들 수 있다. 사람이 직접 코드를 쓰면 적어도 작성 과정에서 어느 정도 맥락을 가진다. 반면 AI 에이전트가 만든 코드를 충분히 읽지 않고 합치면, 시스템은 변했는데 팀의 머릿속 지도는 그대로 남는다.

그다음부터는 이상한 일이 벌어진다. 기능은 빨리 늘어나는데 다음 기능을 붙이는 속도는 오히려 느려진다. 새 코드를 쓰기 전에 기존 코드가 무엇을 의도했는지 되짚는 시간이 계속 늘어나기 때문이다.

오래된 시스템을 가진 팀에서 자주 나오는 말이 있다. “그 부분은 건드리지 않는 게 좋습니다.” 이 말은 대개 경험에서 나온다. 하지만 정확히 왜 위험한지 설명하지 못한다면 그 자체가 인지 부채의 신호다. AI가 그 영역을 더 빠르게 고치기 시작하면 위험은 줄어들지 않는다. 더 넓어진다.

4. 왜 만들었는지 모르면 AI도 헛짚는다

의도 부채는 조금 더 낯선 말이다. 쉽게 말하면 시스템이 지켜야 할 뜻이 사라지는 문제다.

예를 들어 결제 시스템에 특정 고객군만 다른 흐름을 타는 조건문이 있다고 해 보자. 코드만 보면 불필요한 예외처럼 보일 수 있다. 하지만 그 조건이 규제 때문인지, 대형 고객 계약 때문인지, 과거 장애를 막기 위한 장치인지는 코드만 보고 알기 어렵다.

그 의도가 기록되지 않으면 AI 에이전트는 그 코드를 “정리할 대상”으로 볼 수 있다. 사람도 다르지 않다. 왜 있는지 모르는 코드는 지우고 싶어진다. 문제는 그 코드가 실제 비즈니스 약속을 지키고 있을 수 있다는 점이다.

그래서 AI 코딩 시대의 문서는 사용법 설명서만 뜻하지 않는다. 좋은 문서는 결정의 이유를 남기는 장치다. 어떤 요구사항을 우선했는지, 어떤 위험 때문에 다른 방식을 버렸는지, 어떤 조건에서는 절대 바꾸면 안 되는지를 남겨야 한다.

앞으로 좋은 개발팀의 기록은 단순한 회의록이 아닐 가능성이 크다. 사람과 AI가 함께 읽는 의도 저장소에 가까워진다.

5. AI에게 맡기는 것과 AI에게 항복하는 것은 다르다

파울러는 이어서 스티브 쇼와 기디언 네이브의 논문을 언급한다. 이 논문은 카너먼의 빠른 사고와 느린 사고 모델에 AI를 세 번째 사고 체계처럼 붙여 생각한다. 관련 연구는 2026년 4월 3일 Ars Technica 기사에서도 다뤄졌다.

여기서 눈에 띄는 표현은 인지 항복이다. 말은 조금 세지만 뜻은 어렵지 않다. 사람이 자기 판단을 멈추고, AI가 내놓은 답을 별다른 검토 없이 받아들이는 상태다.

반대로 인지 위임은 다르다. 계산, 초안 작성, 대안 정리처럼 일부 사고를 도구에 맡기되 최종 판단은 사람이 유지하는 방식이다. 둘은 겉으로 비슷해 보이지만 결과는 완전히 다르다.

개발 현장에서는 이렇게 갈린다.

• 인지 위임: AI가 작성한 코드를 읽고, 테스트하고, 설계 의도와 맞는지 확인
• 인지 항복: AI가 테스트를 통과시켰으니 맞을 것이라고 믿고 병합
• 인지 위임: AI에게 대안 세 개를 만들게 하고 팀이 기준을 정함
• 인지 항복: AI가 제일 그럴듯하게 설명한 선택지를 그대로 채택

AI가 똑똑해질수록 이 위험은 줄어들지 않을 수 있다. 답이 어설프면 사람은 의심한다. 하지만 답이 매끄럽고 문장이 자신 있으면 검토가 느슨해진다. 개발자가 가장 경계해야 할 순간은 AI가 틀렸을 때가 아니라, 틀렸는데도 매우 그럴듯할 때다.

AI를 잘 쓰는 기준은 답을 더 빨리 믿는 것이 아니라, 판단을 더 선명하게 나누는 데 있다

6. 코딩이 싸지면 검증이 비싸진다

원문에서 가장 강한 대목은 아제이 고어의 글 The Expensive Thing을 소개하는 부분이다. 이 글은 2026년 3월 30일 공개됐고, 질문 하나를 던진다. 코딩 에이전트가 실행을 거의 공짜로 만들면 무엇이 비싸지는가.

고어의 답은 검증이다. 여기서 검증은 단순히 테스트를 돌리는 일이 아니다. 무엇이 올바른 결과인지 정의하고, 그 정의가 실제 상황에서도 맞는지 확인하고, 예외를 다루는 일까지 포함한다.

배달 앱의 도착 시간 예측을 생각해 보면 쉽다. “정확한 도착 시간”은 숫자 하나처럼 보이지만 실제로는 교통, 기사 배정, 고객 대기 시간, 기사 수익, 플랫폼 효율이 함께 얽힌다. 이때 맞는 답은 하나의 계산식이 아니라 여러 이해관계 사이의 균형이다.

AI 에이전트는 코드를 만들 수 있다. 하지만 “무엇이 맞는가”를 스스로 정할 수는 없다. 이 기준을 정하는 일은 제품 이해, 도메인 지식, 운영 경험, 위험 판단이 섞인 일이다.

코딩 에이전트 시대에는 많이 만들었는가보다 무엇을 검증했는가가 더 중요한 질문이 된다

7. 서비스 시장의 돈도 그쪽으로 움직인다

이 글을 서비스 관점에서 보면 더 재미있다. 지금 많은 AI 코딩 도구는 “코드를 빨리 써준다”를 앞세운다. 하지만 파울러가 연결한 생각들을 따라가면, 장기적으로 더 비싼 서비스는 코드 생성 자체가 아닐 수 있다.

코드 생성은 점점 흔해질 가능성이 크다. 모델 성능이 올라가고 도구가 많아질수록 가격 경쟁도 심해진다. 반대로 기업마다 다른 기준을 검증하고, 의도를 기록하고, 배포 뒤 영향을 추적하는 일은 쉽게 복제하기 어렵다.

코드 생성이 보편 기능이 될수록 기업 고객의 관심은 검증, 의도 관리, 운영 감시로 이동한다

돈을 낼 만한 지점은 세 곳으로 이동한다.

• 검증 자동화: 제품 요구사항, 보안 기준, 성능 기준, 장애 조건을 함께 확인하는 체계
• 의도 관리: 요구사항, 결정 기록, 예외 규칙, 고객별 제약을 AI가 읽을 수 있게 유지하는 일
• 운영 감시: 에이전트가 만든 변경이 실제 서비스에서 어떤 영향을 냈는지 추적하는 체계

앞으로 기업 고객은 “코드를 써주는 AI”보다 “이 코드가 우리 기준에 맞는지 증명해 주는 AI”에 더 큰 가치를 느낄 가능성이 크다. 결국 AI 코딩 시장의 경쟁은 “누가 더 빠르게 코드를 쓰나”에서 “누가 더 좋은 검증 체계와 맥락 저장소를 제공하나”로 옮겨갈 수 있다.

8. 소스 코드는 사라질까, 아니면 더 중요해질까

파울러는 마지막으로 소스 코드의 미래를 다룬다. AI가 프로그래머처럼 코드를 쓰기 시작하면 언젠가 소스 코드가 사라질까. 이 질문은 요즘 개발자 커뮤니티에서 자주 나온다.

하지만 파울러가 흥미롭게 보는 지점은 조금 다르다. 그는 인간과 LLM이 함께 시스템을 만들려면, 결국 시스템을 설명하는 좋은 언어가 필요하다고 본다. 이는 도메인 주도 설계에서 말하는 보편 언어와 닿아 있다.

좋은 소스 코드는 컴퓨터만 읽는 명령어가 아니다. 팀이 문제를 어떻게 이해했는지 보여주는 지도다. 함수 이름, 클래스 이름, 경계, 모듈 구조는 모두 “우리가 이 문제를 이렇게 보고 있다”는 표시다.

AI가 코드를 더 많이 만들수록 이름 짓기의 중요성은 줄어들지 않는다. 오히려 더 커진다. AI에게 좋은 지시를 하려면 팀 안에 이미 안정된 단어와 개념이 있어야 한다. 말이 흐리면 결과도 흐려진다.

이 대목은 2025년 8월 26일 파울러와 운메시 조시가 나눈 LLMs and Building Abstractions 대화와도 이어진다. 거기서도 중요한 메시지는 비슷하다. LLM은 반복적이고 기계적인 코드 작성에 강하지만, 어떤 추상화를 만들고 어떤 이름으로 문제를 잡을지는 여전히 사람이 주도해야 한다.

9. 제품팀은 무엇을 다르게 운영해야 하나

이 논의는 특정 나라나 특정 개발 문화에만 머무르지 않는다. AI 코딩 도구를 쓰는 모든 제품팀이 마주할 변화에 가깝다. 코딩 속도가 빨라지면 팀의 병목은 개발자 손끝이 아니라, 제품이 무엇을 약속해야 하는지 정하는 회의와 검증 체계 쪽으로 옮겨간다.

그동안 많은 팀은 기능 목록을 중심으로 움직였다. 이번 분기에 무엇을 만들지, 어떤 화면을 열지, 어떤 API를 붙일지가 회의의 중심이었다. 하지만 AI가 구현 속도를 끌어올리면 질문은 조금 달라져야 한다. “무엇을 만들까”만큼 “무엇을 맞다고 볼까”가 중요해진다.

AI가 만든 코드가 늘어날수록 제품팀은 더 자주 이런 질문을 해야 한다.

• 기준 정의: 이 기능에서 맞다는 것은 무엇인가
• 테스트 의미: 지금 테스트는 실제 사용자 문제를 검증하는가
• 의도 기록: 왜 이 결정을 했는지 다음 사람이 알 수 있는가
• 책임 구간: AI가 고친 코드의 최종 판단은 누가 하는가
• 운영 연결: 배포 뒤 문제가 생기면 어떤 지표로 빨리 알아차릴 수 있는가

이 질문에 답하지 못하면 AI 도구는 생산성을 올리는 장비가 아니라, 이해하지 못하는 코드를 빠르게 늘리는 장비가 된다. 반대로 이 질문에 답할 수 있는 팀은 적은 인원으로도 훨씬 큰 일을 할 수 있다.

특히 흥미로운 변화는 제품 관리자, 디자이너, QA, 운영 담당자의 역할이 더 중요해진다는 점이다. AI가 코드를 빨리 만들어도 사용자의 불편, 예외 상황, 실패했을 때의 복구 흐름은 여전히 사람이 정의해야 한다. 앞으로 좋은 제품팀은 개발자만 AI를 잘 쓰는 팀이 아니라, 모든 직군이 검증 기준을 함께 만드는 팀에 가까워질 수 있다.

회의 방식도 달라질 가능성이 있다. 예전 회의가 “기능을 언제까지 만들까”에 가까웠다면, AI 코딩 이후의 회의는 “이 결과를 어떤 조건에서 믿을 수 있을까”를 더 많이 다룰 수 있다. 속도의 시대가 온 것처럼 보이지만, 실제 경쟁력은 뜻밖에 더 꼼꼼한 팀에서 나올 수 있다.

10. 개발자의 가치는 더 까다로운 곳으로 간다

파울러의 글을 관통하는 메시지는 개발자가 필요 없어지는 이야기가 아니다. 오히려 개발자의 일이 더 까다로워진다는 이야기다.

예전에는 코드를 쓰는 능력이 가장 눈에 띄었다. 앞으로는 코드가 맞는지 판단하는 능력, 시스템 의도를 보존하는 능력, AI가 놓친 맥락을 붙잡는 능력이 더 중요해진다.

이 변화는 불편하다. 많은 개발 문화는 여전히 산출량을 좋아한다. 커밋 수, 배포 수, 닫은 티켓 수는 보기 쉽다. 하지만 검증한 기준, 남긴 의도, 줄인 위험은 측정하기 어렵다. 그래서 더 비싸다.

결국 AI 코딩 시대의 좋은 개발자는 “AI보다 코드를 빨리 쓰는 사람”이 아니다. AI가 빨리 만든 결과 중 무엇을 믿어도 되는지 판단하는 사람에 가깝다.

AI가 실행을 맡을수록 개발자의 핵심 역량은 문제 정의, 품질 기준, 검증 설계로 이동한다

결론

2026년 4월 2일 마틴 파울러의 짧은 Fragments 글은 작지만 날카롭다. AI가 코드를 많이 만들수록 문제는 코드 작성에서 끝나지 않는다. 팀이 코드를 이해하는가, 시스템의 의도가 남아 있는가, 결과가 정말 맞는지 검증할 수 있는가가 더 중요해진다.

그래서 이 글의 가장 흥미로운 결론은 단순하다. AI 시대에 코딩은 싸질 수 있다. 하지만 맞는 것을 정의하고 검증하는 일은 더 비싸진다. 앞으로 강한 팀은 AI를 많이 쓰는 팀이 아니라, AI가 만든 결과를 더 잘 이해하고 더 잘 검증하는 팀일 가능성이 크다.

참고 자료

• Fragments: April 2 - Martin Fowler, 2026년 4월 2일
• From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI - Margaret-Anne Storey, arXiv, 2026년 3월 23일 최초 공개, 2026년 4월 6일 v4
• The Expensive Thing - Ajey Gore, 2026년 3월 30일
• Conversation: LLMs and Building Abstractions - Martin Fowler, Unmesh Joshi, 2025년 8월 26일
• “Cognitive surrender” leads AI users to abandon logical thinking, research finds - Ars Technica, 2026년 4월 3일
• Will AI force code to evolve or make it extinct? - The New Stack, 2026년 4월 확인