한 독자가 소프트웨어를 깊이 이해하는 사람들에게 편지를 보냈다. 정식 컴퓨터과학 교육을 받은 적은 없지만 지난 1년간 LLM의 도움으로 API, PostgreSQL, LLM 파이프라인, 리서치 자동화, 멀티모델 워크플로를 아우르는 상당한 규모의 TypeScript/JavaScript 시스템을 만들었다는 사람이다. 처음에는 아이디어와 구현 사이의 거리가 사라지는 듯한 마법 같은 경험이었다고 한다. 그러나 이 시스템을 실제 프로덕트로 다듬는 단계에서 그는 벽에 부딪혔다. 하나의 오류를 고치면 다른 오류가 나타나고, 어떤 부분은 스스로도 완전히 이해하지 못하는 방식으로 동작했다. 몇 달의 리팩터링 끝에 그가 도달한 불편한 결론은 이랬다. '나는 내 이해 수준을 넘어서는 시스템을 만들어 버렸는지도 모른다.'
이 고백은 오늘날 AI 보조 개발에 뛰어든 많은 실무자가 공유하는 감각을 정확히 짚는다. 모든 것이 잘 돌아갈 때 이해의 공백은 거의 보이지 않는다. 그러나 무언가 고장 나는 순간, 그 공백은 매우 현실적인 문제가 된다. 편지를 쓴 사람은 다음 단계에서 무엇을 해야 할지 또 다른 모델에게 묻지 않고서는 알 수 없는 상황에 이르렀고, 자신이 지난 1년간 실제 제품을 만든 것인지 아니면 '제품처럼 보이는 것'을 만든 것인지 자문하게 됐다고 털어놓았다. 작동할 만큼은 정교하지만, 진정으로 소유했다고 말할 만큼 깊이 이해하지는 못한 무언가 말이다.
이해보다 빠른 구축의 함정
답을 내놓은 블로거의 태도는 인상적이다. 그는 확신에 찬 답을 주기보다 상황이 너무 불확실해 자신의 최선을 다한 견해일 뿐 불변의 진리를 주장하지 않는다고 선을 긋는다. 흥미로운 점은 그가 스스로를 AI에 대해 아직 결론을 내리지 못했으며 오히려 싫어하는 쪽으로 기운다고 밝히는 대목이다. AI가 가장 인상적일 때 그는 30여 년간 쌓아온 기술이 여전히 유효하다는 위안을 빼앗기기에 가장 크게 반감을 느낀다고 한다.
그의 우려는 개인적 감정을 넘어 경제학자로서의 관점으로 확장된다. 그는 프로그래밍이 보험 청구 심사 같은 업무보다 검증이 쉬운 분야이기 때문에 오히려 다른 화이트칼라 직군보다 먼저 대체될 수 있다고 본다. 그리고 지식 노동자 사이에 30~40% 규모의 대량 실업이 발생한다면 지금과 같은 사회가 유지될 수 있을지 회의적이다. 기술 발전이 언제나 새로운 일자리를 만들어냈다는 낙관론에 대해서는, 그 새 일자리가 대체로 일자리를 잃은 바로 그 사람들에게 돌아가지는 않았다는 역사적 사실을 든다. 석탄 광부가 하루아침에 프로그래머가 되지는 않았고, 중국의 WTO 가입 이후 창출된 일자리 상당수는 서구가 아닌 곳에 생겼다는 것이다.
아래와 위, 한 단계씩만 이해하라
그렇다면 기초 없이 AI로 큰 시스템을 만든 사람은 어떻게 해야 할까. 그는 자신이 이제 소프트웨어 개발에서 약한 기초를 갖고 있지 않기 때문에 편지를 쓴 사람과 같은 처지는 아니라고 솔직히 인정한다. 다만 그도 한때는 그런 처지였다. 1999년부터 C++로 COM 컴포넌트를 작성하면서 무엇을 하는지 잘 모르는 채로도 어떻게든 동작시켰고, 눈에 띄는 메모리 누수까지 제거해냈다. 그러나 그는 이해 없이 얼기설기 붙이는 방식에 만족하지 못해 결국 한 걸음 물러나 기초를 체계적으로 학습했다. 1990년대 중반에 시작한 경력에서는 이 방식이 잘 통했다.
문제는 오늘날 같은 방식이 통하느냐다. 그는 자신의 과거 자신감이 더닝-크루거 곡선의 '무지해서 자각하지 못하는' 구간에 있었음을 알아차릴 만큼의 역량에 도달하는 데 수십 년이 걸렸다고 말한다. LLM으로 더 겨냥된 질문을 던져 학습을 앞당길 수는 있지만, 병목은 교사나 자료가 아니라 인간의 뇌가 새 지식을 흡수하는 속도이기 때문에 학습 자체를 극적으로 가속하기는 어렵다는 것이 그의 판단이다. 실무자에게 유용한 오래된 경험칙 하나도 제시한다. 자신이 일하는 추상화 계층의 바로 아래와 바로 위 계층을 이해하라는 것. 그 정도면 대부분의 문제를 진단할 수 있다는 조언이다.
검증 가능한 질문만 던진다
학습 방법에 대한 그의 실무적 원칙은 특히 곱씹을 만하다. 그는 LLM을 학습에 거의 쓰지 않는다고 밝히면서, LLM이 환각을 일으키는 것이 아니라 '헛소리'를 하는 것이라며 그들이 말하는 것을 깊이 불신한다고 말한다. 그렇다고 아예 쓰지 않는 것은 아니다. 핵심은 검증 가능한 답이 나오는 질문만 던진다는 것이다. '이 Haskell 표현식을 더 간결하게 만들 수 있을까'라는 질문의 답은 동작하거나 하지 않고, 더 짧거나 그렇지 않아 쉽게 확인된다. 반면 '다음에 무엇을 배워야 할까' 같은 질문은 검증 가능한 답을 주지 못하므로 그는 LLM에게 묻지 않는다. 그는 이를 '반증 가능한 질문을 선호한다'고 정리한다.
이 글은 명쾌한 해법을 제시하지 않는다. 오히려 저자 스스로 자신의 경험이 2026년에 새로 시작하는 사람에게는 거의 쓸모없다고 반복해서 인정한다. 그럼에도 한국 개발 실무자에게 남기는 함의는 분명하다. AI는 구축 속도를 이해 속도보다 훨씬 빠르게 끌어올릴 수 있고, 그 격차가 곧 '이해의 빚'으로 쌓인다는 점이다. 도구를 쓰되 자신이 검증할 수 있는 영역 안에서 쓰고, 자신이 소유할 수 없는 시스템을 소유한 것으로 착각하지 않는 것. 불확실성 속에서 그가 건넬 수 있는 가장 정직한 조언은 결국 그 경계를 스스로 아는 일이었다.