소프트웨어를 작성할 때, 타이핑은 결코 핵심 업무가 아니었습니다. 프롬프팅(Prompting) 또한 마찬가지입니다.

AI 코딩과 함께 코딩 단계는 쉬워졌습니다. 하지만 사고(Thinking) 단계는 더 어려워졌습니다.

당신은 기능을 요청했습니다. AI는 그것을 만들었습니다. 실행됩니다. 테스트를 통과합니다. 그리고 완전히 틀렸습니다. 아키텍처(Architecture)적으로 거꾸로 되어 있고, 당신에게 존재하지도 않는 문제를 해결하고 있습니다. 코드는 괜찮습니다. 당신의 명세(Spec)가 문제였습니다.

이것은 프롬프팅(Prompting)의 문제가 아닙니다. 멘탈 모델(Mental model)의 문제입니다.

키보드를 두드리는 시간은 70%, 80% 또는 그 이상 줄어들었습니다. 루프(Loop)는 더 빠르게 닫히고, 상용구(Boilerplate)는 사라지며, 커피를 다 마시기도 전에 초안이 나타납니다. 하지만 정신적인 작업량은 줄어들지 않았습니다. 그것은 왼쪽으로 이동(Shift left)했을 뿐입니다.

코딩의 실제 본질

AI 이전에도 유능한 개발자의 업무는 결코 주로 타이핑에 관한 것이 아니었습니다. 키보드는 다음과 같은 과정의 마지막 단계였습니다:

당신은 문제를 전달받았습니다. 당신은 문서를 읽고, 회의를 하고, 동료들과 토론하고, 샤워를 하고, 달리기를 하고, 밤 11시에 화이트보드를 응시하며 멘탈 모델(Mental model)을 구축하는 데 시간을 보냈습니다. 이 시스템은 실제로 어떻게 작동하는가? 이 기능은 아키텍처(Architecture)의 어디에 위치하는가? 타협할 수 없는 제약 조건은 무엇인가? 이 일이 잘못될 수 있는 세 가지 방법은 무엇이며

그러고 나서야, 오직 그때서야 비로소 코드를 작성하기 위해 자리에 앉았습니다. 타이핑은 번역(Translation)이었습니다. 당신은 이미 구축한 정신적 모델(Mental model)을 기계가 실행할 수 있는 언어로 변환하고 있었던 것입니다. 저의 전형적인 전략은 작성하려는 코드의 개요를 주석으로 작성하여 큰 틀과 전체적인 그림을 스케치한 다음, 세부 사항을 채워 넣는 것이었습니다. 뛰어난 개발자들은 정확한 정신적 모델을 가지고 있었기에 깨끗한 코드를 작성했습니다. 평범한 개발자들은 정신적 모델이 불완전했기 때문에 혼란스러운 코드를 작성했으며, 코드는 그 불완전함을 충실히 반영했습니다.

2005년 튜링상(Turing Award) 수상자이자 ALGOL의 기여자이며 Backus-Naur Form의 공동 창시자인 Peter Naur는 1985년에 이 논거를 공식적으로 제시했습니다. 그의 에세이인 "Programming as Theory Building" [1]은 프로그램이 개발의 일차적인 산물이 아니라고 제안했습니다. 일차적인 산물은 공유된 정신적 모델, 즉 그것을 만든 모든 사람이 보유한 문제에 대한 "이론(Theory)"입니다. 코드는 그 이론을 기계로 투영한 손실이 있는 투영(Lossy projection)입니다. 팀이 해산하면 이론도 그들과 함께 흩어집니다. 남는 것은 지도(Map)뿐입니다. 그 지도가 설명하는 영토(Territory)는 그것을 만든 사람들의 머릿속에만 존재합니다.

지도는 영토가 아닙니다. 공유된 정신적 모델을 가진 개발 팀은 더 적은 버그와 더 견고한 코드를 만들어냅니다. 이는 그들이 더 똑똑해서가 아니라, 지도가 영토와 더 잘 일치하기 때문입니다. 코드는 그들이 단순히 기록해낸 것이 아니라, 팀이 실제로 이해한 내용을 반영합니다.

키보드는 모델이 가시화되는 장소였습니다. 결코 실제 작업이 일어나는 곳이 아니었습니다.

AI 코딩의 실체

AI 코딩도 동일한 요소들을 요구하지만, 다르게 다뤄지고 확장됩니다.

번역 계층(Translation layer)이 변했습니다. 당신의 정신적 모델을 코드로 변환하는 대신, 당신은 그것을 AI가 코드로 변환할 수 있는 사양(Specification)으로 변환합니다. 하지만 그 과정은 그렇게 간단하지 않습니다. 사양을 작성하기 전에 구축해야 하는 정신적 모델은, 직접 코드를 작성하기 전에 필요했던 모델보다 훨씬 더 넓어야 합니다.

전통적인 코딩(Traditional coding)은 하나의 정신적 모델, 즉 문제 모델(problem model)을 요구했습니다. 이것이 어떻게 작동하는가? 무엇을 수행해야 하는가? 기존 시스템과 어떻게 어우러지는가?

AI 코딩은 세 가지를 요구합니다.

문제 모델 (The problem model). 이전과 같습니다. 무엇을 왜 만드는지 이해해야 합니다. 예외 케이스(edge cases)를 파악하세요. 실패 모드(failure modes)를 예측하세요. 여기서 변한 것은 없습니다. 다만 이제는 머릿속에 담아두고 즉석에서 번역하는 대신, 이 모든 것을 글로 외재화(externalize)해야 한다는 점뿐입니다. 이를 위해서는 문제에 대한 정확한 정신적 모델뿐만 아니라 훌륭한 커뮤니케이션 기술도 필요합니다. 그리고 개발자가 이전에는 쓰지 않았던, 프로세스의 초기 단계(left end)에 투입하는 시간이 필요합니다.

도메인 모델 (The domain model). 이 코드베이스에서 정형적인(canonical) 패턴은 무엇인가? 어떤 라이브러리들이 사용되고 있는가? 3년 전의 어떤 아키텍처 결정(architectural decisions)을 새로운 기능이 준수해야 하는가? 숙련된 개발자들은 이를 배경 지식으로서 직관적으로 흡수해 왔으며, 이는 이름 붙여지거나 문서화된 적이 없었습니다. AI 코딩은 이를 명시적으로 만들도록 강제합니다. AI에게는 세 가지 선택지가 있습니다: 사용자가 사양(spec)에 도메인 컨텍스트(domain context)를 제공하거나, AI가 기존 코드베이스에서 추론하거나, 혹은 AI가 스스로 관습(conventions)을 만들어내는 것입니다. 세 번째 선택지는 기술적으로는 정확하지만, 영역의 거대한 부분을 누락한 코드를 생성합니다.

컨텍스트 모델 (The context model). 이것이 새로운 모델입니다. 숙련된 개발자라면 당신의 특수한 상황에 대해 본질적으로 알고 있겠지만, AI는 알지 못하며 코드로부터 추론할 수도 없는 모든 것에 대한 모델입니다.

개발자의 정신적 모델은 얻어지는 것입니다. 그것은 자신을 괴롭혔던 특정 버그들, 결과가 좋지 않았던 아키텍처 결정들, 그리고 더 이상 어떤 문서에도 남아있지 않은 이유로 존재하는 비즈니스 규칙들로부터 구축됩니다. 그들은 그 영역에서 직접 살아왔기 때문입니다.

AI는 매우 훌륭한 지도를 가지고 있습니다. AI는 그 어떤 인간보다도 더 많은 코드를 보았습니다. 하지만 AI의 "모델 (model)"은 학습 데이터에 대한 통계적 분포(statistical distribution), 즉 유사한 문맥에서 코드가 일반적으로 어떻게 보이는지에 대한 정교한 평균값입니다. AI는 자신의 학습 내용과 당신의 상황 사이의 간극을 메울 것입니다. AI는 항상 그 간극을 메웁니다 (그것이 AI의 업무 전부니까요!). 문제는 AI가 그 간극을 당신의 의도(intent)로 채우느냐, 아니면 지금까지 보아온 모든 것에서 추출한 가장 그럴듯한(plausible) 답변으로 채우느냐 하는 것입니다.

그럴듯함(Plausible)과 정확함(Correct)은 같은 것이 아닙니다. 당신의 상황이 학습 분포(training distribution)와 유사할 때는 두 개념이 수렴합니다. 하지만 당신의 시스템이 외부 코드베이스는 알 수 없는 제약 조건, 관례(conventions), 또는 히스토리를 가지고 있을 때, 두 개념은 — 급격하게 — 갈라집니다.

컨텍스트 모델(context model)은 그 간극에 대한 당신만의 지도입니다. 컨텍스트 모델은 다음과 같은 질문에 답합니다: 이 AI가 우리의 상황에 대해 그럴듯하게 틀릴 부분은 무엇인가? 우리가 명시적으로 거부한 어떤 관례를 AI가 기본값(default)으로 선택할 것인가? AI가 통계적으로 합리적인 판단이 아닌 올바른 판단을 내리기 위해 필요한 배경 지식은 무엇인가?

(AI가 기술적으로는 맞지만 아키텍처 측면에서는 잘못된 것을 자신 있게 만들어내는 것을 지켜본 모든 개발자는, 자신이 작성하는 것을 잊어버렸던 컨텍스트 모델을 방금 발견한 것입니다.)

명세(Specs)가 실패하는 이유

나쁜 명세(specification)는 커뮤니케이션의 문제가 아닙니다. 그것은 멘탈 모델(mental model)의 문제입니다.

명세는 멘탈 모델을 손실 압축(lossy compression)한 것입니다. AI는 이를 압축 해제(decompress)합니다. 출력물에서 발생하는 모든 오류는 압축 해제 과정에서 발생하는 아티팩트(artifact)입니다. 즉, 명세가 충분한 정보를 전달하지 못했고, AI가 당신의 의도 대신 학습 데이터에서 무언가를 가져와 대체한 지점입니다.

이것이 바로 "더 나은 프롬프트를 작성하라"는 조언이 불충분한 이유입니다. 당신이 뛰어난 작가일지라도, 그 이면에 있는 멘탈 모델 (Mental Model)이 불완전하다면 여전히 나쁜 명세 (Spec)를 만들어낼 수 있습니다. 제한 요인은 어휘력이나 명확성이 아닙니다. 그것은 당신이 글을 쓰기 시작하기 전에 이해한 내용의 폭과 정확성입니다. 명확성 (Clarity), 완전성 (Completeness), 그리고 적절한 세분성 (Granularity)은 언제나 중요하지만, (모든 커뮤니케이션의 과제와 마찬가지로) 당신의 청중을 알고 주제를 진정으로 이해하는 것(즉, 정확한 멘탈 모델을 갖는 것)이 성공의 열쇠입니다.

바이브 코딩 (Vibe coding)이 일관되지 않은 결과를 생성하는 이유는 구조적입니다. 당신은 AI에게 구현 세부 사항뿐만 아니라, 아키텍처 결정 (Architectural decisions), 도메인 제약 조건 (Domain constraints), 그리고 컨텍스트의 공백 (Context gaps)까지 — 이 중 어느 것도 담지 못한 프롬프트로부터 동시에 채워 넣으라고 요구하고 있는 것입니다. 때로는 AI가 올바르게 추측하기도 합니다. 타율 (Batting average)은 모델의 능력이 아니라, 그 간극의 크기를 반영합니다.

당신의 명세에 존재하는 모든 공백은 AI에게 즉흥 연주(Improvisation)를 하라고 초대하는 것과 같습니다. 때로는 즉흥 연주가 괜찮을 수도 있습니다. 하지만 대개는 그렇지 않습니다. 그 차이는 당신이 그 공백이 어디에 있는지 알고 있느냐에 달려 있습니다.

이제 멘탈 모델이 당신의 주요 결과물입니다

명세 작성을 "멘탈 모델을 가시화하는 과정"으로 생각하면, 누가 가장 가치 있는 개발자인지가 바뀝니다.

과거의 계층 구조는 구현 기술, 즉 알고리즘적 사고 (Algorithmic thinking), 언어 숙련도 (Language fluency), 복잡한 시스템을 작업 기억 (Working memory)에 담아 효율적으로 탐색하는 능력에 높은 가치를 두었습니다. 이러한 기술들은 도메인 모델 (Domain model)과 문제 모델 (Problem model) 모두를 위해 여전히 중요합니다. 하지만 그것들이 더 이상 전체 그림은 아닙니다.

이제 전체 그림에는 멘탈 모델 (Mental model)의 품질이 포함됩니다. 구체적으로는, 세 가지 차원 모두를 아우를 수 있을 만큼 충분히 넓고, 두 번의 번역 과정을 견뎌낼 수 있을 만큼 충분히 정밀한 모델을 구축하는 능력을 의미합니다. 즉, 당신의 머릿속에서 명세서 (Spec)로, 그리고 명세서에서 코드로 이어지는 번역 과정 말입니다. 이를 '전화기 문제 (Telephone problem)'라고 불러봅시다. 각 번역 단계에서는 손실이 발생합니다. 명세서에 존재하는 모든 모호함은 첫 번째 번역 단계에서 유입된 노이즈 (Noise)입니다. AI의 학습 데이터에 존재하는 모든 공백을 AI가 통계적 기본값으로 채우는 것은 두 번째 번역 단계에서 유입된 노이즈입니다. 원래의 메시지는 각 단계를 거칠 때마다 저하됩니다. 유일한 방어책은 최종 출력물에 필요한 것보다 더 넓고 정밀한 모델로 시작하는 것뿐입니다.

시니어 개발자들의 가치가 더욱 높아졌습니다. 도메인 전문 지식 (Domain expertise)은 도메인 모델 (Domain model)의 원재료입니다. 이해하지 못하는 것은 명세화할 수 없습니다. 특정 코드베이스에서 5년을 보낸 개발자는, 프롬프팅 (Prompting) 기술이 더 뛰어난 주니어 개발자가 문서만으로는 복제할 수 없는 도메인 모델을 보유하고 있습니다. LLM (Large Language Models)이 발전하고 더 많은 도메인 특화 학습을 흡수함에 따라 이러한 격차는 줄어들 것입니다. 하지만 현재로서는 여전히 실질적인 무게감을 가집니다.

지금 어려움을 겪고 있는 개발자들은 자신의 정체성과 가치를 구현 유창성 (Implementation fluency) — 즉, 키보드를 직접 두드리는 순간의 즐거움과 정밀함 — 에 두었으며, 자신의 전문성이 실제로 존재하는 곳은 멘탈 모델이라는 사실을 아직 내면화하지 못한 사람들입니다. 키보드는 언제나 수단이었을 뿐입니다. 단지 유일한 수단이 아니었을 뿐입니다.

번창하고 있는 개발자들은 자신들이 항상 해왔던 일이 현실의 모델을 구축하고 이를 실행 가능한 형태로 변환하는 것이었음을 깨달은 사람들입니다. 변환 방식은 바뀌었지만, 모델은 바뀌지 않았습니다.

실무에서의 모습

이제 좋은 명세서를 작성한다는 것은, 과거에 개발자들이 자신의 멘탈 모델 속에서 답하고 코드에 구현했던 질문들에 대해, 질문이나 결정 사항을 어디에도 기록하지 않은 채 답하는 것을 의미합니다:

• 이 기능이 결코 위반해서는 안 되는 불변량 (Invariant)은 무엇인가?
• 이것은 기존의 어떤 패턴을 따르고 있으며, 그 패턴은 코드베이스 (Codebase)의 어디에 위치하는가?
• 합리적인 개발자 (인간 또는 AI)가 이 시스템에 대해 무엇을 잘못 추측할 수 있으며, 올바르게 추측하기 위해 무엇을 알아야 하는가?
• 나의 의도가 내 지시사항의 명백한 해석과 달라지는 지점은 어디인가?

이것은 코드를 작성하는 것보다 쉽지 않습니다. 이는 다른 종류의 엄밀함 (Rigor)을 요구합니다. 즉, 구문 (Syntax)이나 런타임 동작 (Runtime behavior)의 엄밀함이 아니라, 명시적인 표현 (Explicit articulation)의 엄밀함입니다. 당신은 당신의 명세 (Spec)가 모호할 경우, 당신의 말을 문자 그대로 받아들이고 좋은 후속 질문을 던지지 않을 수도 있는 독자를 위해 글을 쓰는 것입니다.

코드 리뷰 (Code reviews), 아키텍처 논의 (Architecture discussions), 요구사항 세션 (Requirements sessions) 등에서 자신의 생각을 다른 사람들에게 설명하는 데 항상 능숙했던 개발자들은 더 빠르게 적응하는 경향이 있습니다. 반면, 키보드 앞에서 혼자 생각하며 직관을 구문으로 직접 번역하는 데 최선을 다했던 사람들은 더 가파른 학습 곡선에 직면하게 됩니다.

AI의 지도와 당신의 영토가 갈라지는 지점

AI의 통계적 모델 (Statistical model)과 당신의 멘탈 모델 (Mental model) 사이의 간극은 고정되어 있지 않습니다. 이는 도메인 (Domain), 코드베이스 (Codebase), 그리고 당신이 구축하고 있는 것의 구체성에 따라 달라집니다.

잘 알려진 도메인 — 표준 웹 애플리케이션, 익숙한 프레임워크, 관습적인 패턴 — 의 경우, AI의 학습 분포 (Training distribution)는 당신의 영토와 가깝습니다. 통계적 완성 (Statistical completion)은 종종 정확합니다. 지도가 대부분 일치합니다.

상황이 더 구체화될수록 그 차이는 커집니다:

• 새롭거나 니치한 도메인 (Novel or niche domains): 학습 데이터가 부족하고 AI의 사전 확률 (priors)이 잘못된 사례를 바탕으로 구축된 경우
• 규제가 엄격한 산업 (Heavily regulated industries): 제약 조건이 표준적이지 않으며, 그럴듯하지만 틀린 답변이 실제 비용을 초래하는 분야: 의료, 법률, 국방, 금융
• 결정 사항이 축적된 성숙한 코드베이스 (Mature codebases with accumulated decisions): 아키텍처 선택 뒤에 숨겨진 "이유 (why)"가 그 어떤 문서에도 기록되지 않은 시스템
• 관습으로부터 의도적인 이탈 (Deliberate departures from convention): 당신의 팀이 특정 이유로 명백한 접근 방식을 거부했으며, 명세서 (spec)에 해당 맥락이 없다면 AI는 매 세션마다 그 명백한 접근 방식을 다시 발견하게 되는 경우