LLM 시대에 프로그래밍을 배운다는 것, 30년차 개발자의 답

출처: ploeh blog (Mark Seemann)
원문: https://blog.ploeh.dk/2026/09/16/on-learning-programming-in-an-age-of-llms/
작성자: 팔복소프트-김팔복

한눈에 보기

• 『Code That Fits in Your Head』의 저자 Mark Seemann이 LLM 시대의 프로그래밍 학습에 관한 독자 편지에 공개적으로 답했습니다.
• 편지를 보낸 독자는 CS 전공 없이 AI로 TypeScript/PostgreSQL 기반의 큰 시스템을 만들었지만, 운영 단계에서 자신이 이해하지 못하는 코드에 막혔습니다.
• Seemann은 "바로 아래와 바로 위의 추상화 계층을 이해하라"는 경험칙을 다시 제시합니다.
• 그는 LLM으로 질문을 더 정확하게 할 수는 있어도, 사람의 뇌가 지식을 흡수하는 속도 자체는 크게 빨라지지 않는다고 봅니다.
• LLM에는 검증 가능한(falsifiable) 질문만 하고, "다음에 뭘 배워야 하나" 같은 질문은 하지 않는다고 밝혔습니다.
• 그는 AI에 대해 스스로 비판적인 입장임을 먼저 밝혔고, 경제학자 관점에서 지식노동자 대량 실업에 대한 우려도 표했습니다.

배경

Mark Seemann은 의존성 주입(DI)과 함수형 프로그래밍 분야에서 널리 알려진 개발자이자 저자입니다. 원문은 새 제품 발표가 아니라 에세이입니다. 최근 개발 커뮤니티에서는 요구사항만 말하고 AI가 만든 코드를 거의 읽지 않는 이른바 '바이브 코딩'이 퍼지고 있습니다. 이 글은 그 흐름의 끝에서 생기는 문제를 정면으로 다룹니다.

주요 내용

"만든 것"과 "이해한 것" 사이의 간극

편지의 핵심 고민은 이렇습니다. 잘 돌아갈 때는 보이지 않던 이해의 공백이 장애가 나는 순간 드러났다는 것입니다. 오류 하나를 AI로 고치면 다른 곳이 깨지고, 결국 다음 행동을 정하는 것조차 또 다른 모델에게 물어야 하는 상황이 됐습니다. 독자는 1년 동안 제품을 만든 건지, 제품처럼 보이는 무언가를 만든 건지 자문합니다.

Seemann은 이 문제가 완전히 새롭지는 않다고 봅니다. 웹 개발자는 컴파일러를 잘 모르고, 컴파일러 개발자는 반도체 설계를 잘 모르는 식으로 개발자는 원래 자기가 다 이해하지 못하는 추상화 위에서 일해 왔다는 것입니다. 그래서 그가 권하는 기준은 자기 계층의 바로 아래와 바로 위만큼은 이해하라는 것입니다. 그 정도면 대부분의 문제를 추적할 수 있다고 봅니다.

기초를 다시 배워야 하나

Seemann 자신도 1999년 무렵 이해도가 낮은 상태에서 C++로 COM 컴포넌트를 만들며 경력을 시작했습니다. 그러다 한발 물러나 기초를 체계적으로 공부했습니다. 다만 그 방식이 지금도 통할지는 확신하지 못합니다. 과거의 자신이 Dunning-Kruger 곡선의 '모르는 줄도 모르는' 구간에 있었다는 걸 깨닫기까지 수십 년이 걸렸기 때문입니다.

그가 LLM을 쓰는 방식

그는 LLM을 학습 도구로 거의 쓰지 않습니다. LLM의 답을 신뢰하지 않기 때문입니다. 대신 "이 Haskell 식을 더 간결하게 쓸 수 있나?"처럼 돌려보면 맞는지 틀린지 바로 확인되는 질문만 합니다. 반대로 학습 방향처럼 검증할 수 없는 질문은 맡기지 않습니다.

학습 이력도 소개합니다. 경제학 석사 논문을 위해 QBasic으로 분기 다이어그램과 Lorenz attractor를 계산한 것이 첫 실질적 프로젝트였습니다. C#은 문서와 예제로, F#과 Haskell은 책으로 익혔습니다. 지금은 호기심 때문에 대학 과정에서 자료구조와 언어 의미론을 공부하고 있다고 합니다.

커리어와 사회에 대한 비관

지금 시작한다면 목공이나 금속가공처럼 손을 쓰는 일을 진지하게 고려하겠다는 답도 있습니다. 경제학자로서는 지식노동자 대량 실업이 사회에 미칠 충격을 우려합니다. 기술 발전이 새 일자리를 만든다는 논리에도, 새 일자리가 일자리를 잃은 사람에게 돌아가지는 않았다며 회의적인 입장을 보입니다.

팔복소프트 관점

• 국내 상황과 거의 그대로 겹칩니다. 부트캠프 출신이나 비전공 개발자가 많고, 신입 채용이 얼어붙은 한국에서 "AI로 포트폴리오는 만들었는데 면접이나 장애 대응에서 무너지는" 사례는 이미 흔합니다. 이 글은 그 현상에 이름을 붙여줍니다.
• '위아래 한 계층' 원칙은 실무 체크리스트로 쓰기 좋습니다. Spring Boot 개발자라면 JPA가 만드는 SQL과 커넥션 풀, 그리고 위쪽의 API 계약까지는 설명할 수 있어야 한다는 식으로 구체화할 수 있습니다. AI가 생성한 코드 리뷰 기준으로 삼기에도 적합합니다.
• "검증 가능한 질문만 한다"는 원칙이 이 글에서 가장 바로 쓸 만한 조언입니다. 테스트가 있는 코드베이스에서 Cursor나 Claude Code를 쓰면 제안이 맞는지 기계적으로 확인됩니다. 테스트 없는 레거시에서 AI 리팩터링을 하는 것은 검증할 수 없는 질문을 계속 던지는 것과 같습니다. AI 도입 전에 테스트 커버리지부터 챙겨야 하는 이유입니다.
• 한계도 분명합니다. Seemann은 스스로 AI를 싫어하는 쪽으로 기울어 있다고 밝혔고, 답변도 개인 경험에 기댄 에세이입니다. 목공을 배우겠다는 말은 진지한 커리어 조언이라기보다 정서의 표현에 가깝습니다. 조직이 실제로 어떻게 대응해야 하는지에 대한 답은 이 글에 없습니다.
• 팀 리더에게는 주니어 육성 문제로 읽어야 합니다. 주니어가 AI로 빨리 결과를 내면 단기 생산성은 오르지만, 장애 대응을 맡을 사람은 줄어듭니다. 온콜이나 디버깅 과제를 의도적으로 맡기는 설계가 필요합니다.

정리

AI 덕분에 만드는 속도는 크게 빨라졌지만, 이해하는 속도는 그대로입니다. 이 글에서 기억할 것은 두 가지입니다. 자기 계층의 위아래 한 칸까지는 직접 이해할 것, 그리고 LLM에는 결과를 검증할 수 있는 질문을 던질 것. 그 간극을 인정하고 관리하는 쪽이 오래 버팁니다.

• LLM
• 개발자학습
• 바이브코딩
• 커리어
• MarkSeemann