LLM으로 만드는 속도와 프로그래밍을 이해하는 속도
AI로 복잡한 시스템을 만들었지만 이해가 따라가지 못한 독자의 질문에서 출발해, 추상화의 경계와 기초 학습, 검증 가능한 LLM 활용을 살펴본다.
TL;DR
- AI로 시스템을 완성하는 능력과 고장 난 시스템을 이해하고 고치는 능력은 다를 수 있다. 마크 시먼에게 편지를 보낸 독자는 실제 제품으로 전환하는 과정에서 그 차이를 체감했다. 작동하는 결과물이 곧 충분한 이해를 뜻하지는 않는다.
- 모든 기술 계층을 알 필요는 없지만 자신이 일하는 추상화의 바로 위와 아래는 이해하는 편이 좋다. 시먼은 이를 대부분의 문제를 추적하는 데 도움이 되는 경험칙으로 소개한다. 기초를 쌓으면 낯선 환경에서도 기존 지식을 활용할 수 있다.
- LLM은 필요한 설명을 빨리 찾게 해도 인간의 학습 속도까지 같은 비율로 높인다고 보장할 수는 없다. 시먼은 답의 진위를 확인할 수 있는 질문에 LLM을 주로 쓴다. 코드가 실제로 동작하는지는 확인하기 쉽지만 다음에 무엇을 배워야 하는지는 그렇지 않다.
- 이 글은 AI 시대의 확정적인 진로 처방이 아니다. 시먼은 기술 변화가 만든 새 일자리가 실직한 당사자에게 돌아오지 않을 수 있다고 우려한다. 기초 학습의 가치와 그 학습이 취업·소득으로 보상될지는 구분해야 한다.
작동하던 시스템을 제품으로 바꾸면서 드러난 격차
정식 컴퓨터과학 교육을 받지 않은 한 독자가 LLM의 도움으로 상당한 규모의 TypeScript·JavaScript 시스템을 만들었다. API와 PostgreSQL, LLM 파이프라인, 조사 자동화와 여러 모델을 연결하는 작업 흐름까지 포함했다. 아이디어를 실제 프로그램으로 옮기는 거리가 갑자기 짧아졌지만 운영 가능한 제품으로 다듬으려 하자 문제가 달라졌다. AI로 오류 하나를 고치면 다른 오류가 나타났고 시스템의 일부가 왜 그렇게 동작하는지 설명하기 어려웠다.
독자는 몇 달 동안 리팩터링한 뒤 자신이 이해할 수 있는 수준보다 복잡한 시스템을 만들었을지 모른다고 의심했다. 정상적으로 작동할 때는 보이지 않던 이해의 부족이 고장 앞에서 드러났다. 다음에 무엇을 해야 할지조차 다른 모델에게 물어야 하는 상황도 생겼다. 이 편지의 질문은 AI로 만들어 낸 프로그램을 스스로 이해하고 책임질 수 있을 만큼 어떻게 배워야 하는가에 있다.
추상화의 위아래를 이해하는 경험칙
마크 시먼은 이해하지 못하는 기술 위에서 소프트웨어를 만드는 일이 AI와 함께 처음 생긴 문제는 아니라고 짚는다. 웹 개발자가 컴파일러 구현을 모두 아는 것은 아니고 컴파일러 개발자도 집적회로 설계까지 숙달한 것은 아니다. 반대로 회로를 설계하는 사람이 그 위의 소프트웨어 계층을 모두 알지도 못한다. 모든 계층을 처음부터 이해해야 개발할 수 있다는 기준은 예전에도 현실적이지 않았다.
그의 경험칙에 따르면 자신이 다루는 추상화의 바로 아래 계층과 바로 위 계층을 이해하는 편이 좋다. 문제가 발생했을 때 그 경계를 넘나들며 원인을 좁힐 수 있으면 대부분의 문제 해결에 도움이 된다. 이는 모든 장애를 해결한다는 보장이나 AI 시대에 검증된 교육과정은 아니다. 다만 어디까지 공부해야 하는지 막막할 때, 지금 하는 작업과 맞닿은 계층을 학습 범위로 잡는 기준이 된다.
기초가 쌓인 사람은 낯선 환경에서도 이미 아는 개념을 활용한다. 시먼은 자신에게 익숙하지 않은 RISC-V 어셈블리로만 작성된 애플리케이션을 맡는 상황을 예로 든다. 적응은 어렵겠지만 프로그래밍 자체가 처음인 사람과 출발점은 다르다. 실제로 그는 RISC-V 연습 프로그램과 그 대상으로 코드를 생성하는 연습용 컴파일러를 작성한 경험이 있다. 숙련자의 AI 활용법을 초보자에게 그대로 적용하기 어려운 이유도 이런 배경 지식의 차이에 있다.
필요한 답을 빨리 찾는 것과 배우는 것은 다르다
시먼도 처음부터 원리를 충분히 이해하며 개발하지는 못했다. 1999년부터 C++로 COM 컴포넌트를 작성할 때는 제대로 알지 못하는 부분이 많았지만 어떻게든 동작하게 만들고 눈에 띄는 메모리 누수도 제거했다. 그 상태에 만족하지 못해 일을 진행하는 한편 기초를 체계적으로 공부했다. 이 방식은 자신의 경력에는 도움이 됐지만 오늘의 입문자에게도 같은 결과를 약속할 수는 없다는 입장이다.
LLM은 당장 필요한 내용을 겨냥해 질문할 수 있게 한다. 과거에는 도움이 될 내용을 찾으려고 책을 사서 현재 문제와 직접 관련 없는 부분까지 읽어야 했다. 그러나 시먼은 이런 탐색 비용의 감소가 인간의 학습 속도를 크게 높일 수 있는지는 의심한다. 가장 큰 제약이 교사나 자료의 부족보다 뇌가 새로운 지식을 받아들이는 속도에 있을 수 있기 때문이다. 과거의 자신이 얼마나 모르고도 확신했는지 깨달을 수준에 이르기까지 수십 년이 걸렸다는 회고도 같은 맥락이다.
따라서 그의 답변은 프로젝트를 중단하고 기초부터 배우라는 단순한 처방으로 끝나지 않는다. 일을 하면서 배우고 별도로 기초를 공부한 자신의 경험은 설명하지만 그 긴 학습 과정에 필요한 시간을 지금도 확보할 수 있을지는 열어 둔다. 현재도 호기심 때문에 대학 과정에서 자료구조와 언어 의미론 등을 공부하며 큰 금전적 보상은 기대하지 않는다. 이해를 넓히는 선택과 그 선택의 경제적 전망을 같은 질문으로 다루지 않는다.
학습 방법은 이미 알고 있는 것에 따라 달라진다
시먼의 초기 학습은 시행착오와 예제, 문서, 때때로 읽은 책에 의존했다. 경제학 석사 논문에서 분기 다이어그램과 로렌츠 끌개를 계산할 때는 손에 있던 QBasic을 사용했고 제공된 예제와 친구의 도움으로 배웠다. 여러 Basic 계열 언어와 C#도 주로 문서와 예제 코드로 익혔다. 반면 F#과 Haskell을 배우는 데는 책이 큰 역할을 했다. 언어마다 같은 학습 경로를 밟은 것은 아니다.
지금은 많은 언어를 접한 경험 덕분에 기존 코드를 읽다가 분명하지 않은 부분만 찾아보는 식으로 새 언어에 접근한다. 하지만 이는 이미 축적된 지식을 전제로 한 방법이다. 익숙한 계열에서 크게 벗어나는 APL로 돌아가야 한다면 자신도 튜토리얼부터 찾아야 한다고 인정한다. 숙련자가 적은 자료만으로 빨리 배우는 모습에는 그 기초를 이미 다른 곳에서 익혔다는 배경이 있다. 기초 학습이 불필요하다는 증거로 볼 수는 없다.
LLM에는 확인하거나 반박할 수 있는 질문을 한다
시먼은 LLM을 완전히 배제하지 않지만 답변을 쉽게 신뢰하지는 않는다. 학습에 적극적으로 의존하기보다 확인 가능한 결과를 얻는 쪽으로 질문을 제한한다. 예를 들어 Haskell 표현식을 더 간결하게 바꿀 수 있는지 물으면 대개 코드 제안을 받는다. 제안된 코드가 동작하는지, 실제로 더 짧아졌는지를 확인할 수 있으므로 답을 그대로 믿지 않고도 사용할 여지가 있다.
다음에 무엇을 배워야 하는지 묻는 질문은 성격이 다르다. 추천이 그럴듯해 보여도 그 선택이 옳았는지 곧바로 검사하기 어렵다. 시먼이 선호하는 기준은 답을 현실의 결과와 대조해 틀렸는지 확인할 수 있는가, 곧 반증 가능성이다. 이는 LLM을 학습에 쓰지 말라는 보편적 금지 규칙보다, 자신이 검증할 수 있는 범위 안에서 활용하려는 개인적 원칙이다.
기초의 가치와 진로의 보상은 별개다
시먼은 글의 시작부터 답변이 확정된 진리가 아니며 자신이 AI를 좋아하지 않는 쪽으로 기운다는 점을 밝힌다. 우려의 범위도 개인의 프로그래밍 경력에 한정되지 않는다. 기술 발전으로 새 일자리가 생기더라도 기존 일자리를 잃은 사람이 그 자리를 얻는다는 보장은 없다는 지적이다. 과거 산업 변화와 무역 확대를 낙관론의 반례로 떠올리는 이유도 총량의 성장과 개인의 전환 비용이 다르기 때문이다.
글에 등장하는 30~40% 실업은 실측치나 발생 확률을 계산한 예측이 아니라, 그런 대규모 실업이 일어날 경우 경제가 받을 충격에 대한 가정이다. 지금 출발한다면 목공이나 금속 가공처럼 손과 눈의 협응이 필요한 일을 고려하겠다는 말도 같은 불확실성 속의 개인적 판단이다. 그는 로봇 기술의 발전도 인정하면서 수작업의 대체가 상대적으로 더 먼 미래일 것으로 본다. 자신의 우려가 틀리기를 바라고 계속 프로그래밍하고 싶다는 바람까지 함께 남긴다.
이 글에서 얻을 수 있는 학습 기준은 미래 직업을 확정하는 예언보다 좁고 구체적이다. 작업하는 추상화의 경계를 이해하고 낯선 문제에 옮겨 쓸 기초를 쌓으며 LLM의 답을 확인할 수 있는 질문을 고른다. 반면 얼마나 오래 공부하면 어떤 일자리와 소득을 얻을 수 있는지는 답하지 못한다. 프로그램을 만들고 이해하는 능력을 기르는 문제와 그 능력이 보상받을 사회를 전망하는 문제는 끝까지 구분된다.