Python Crash Course의 저자인데, 이번 주에 나도 똑같은 이메일을 받았음. 제대로 답하려면 글 한 편은 필요하고, 지금 프로그래밍에 입문하는 많은 이들이 비슷한 질문을 하고 있어 공개 답변을 고민하던 참임.
AI가 이해하는 속도보다 빠르게 개발하게 해주느냐고 묻는다면, 분명히 그렇다고 봄. 불과 5년 전에는 어느 정도 복잡한 MVP를 만들려면 필요한 기초·중급 개념을 배워야 했지만, 이제는 LLM을 적절히 이끌면 자신이 구현을 이해하는 범위를 훨씬 넘어서는 MVP도 빠르게 만들 수 있음.
모든 질문에 명확한 답이 있다고 보지는 않음. 서로 다른 영역을 더 빨리 연결하며 학습 속도를 높일 수는 있지만, 학습과 작업 방식에 숙련과 절제가 필요함. 프로젝트를 만드는 동시에 의도적으로 이해도 쌓아야 함.

어느 정도 동의하지만, 5년 전에도 모든 내부 원리를 알아야 MVP를 만들 수 있었던 것은 아님. TCP 소켓을 열거나 HTTP 헤더를 파싱하는 법, 관계형 데이터베이스, B-트리, 캐시 지역성, Linux 설치법을 몰라도 가능했음.
이제는 Stripe나 Auth0 연결, Kubernetes 클러스터 설정의 세부 사항을 몰라도 되는 것임. 알아야 할 것과 몰라도 될 것은 작업 내용, 규모, 위험에 따라 달라지며, 그 점은 예전에도 마찬가지임.

인기 없는 생각일 수 있지만, 자동차 운전을 배우기 전에 오토바이 안전 교육을 받고 두 바퀴부터 익히는 편이 좋다고 봄. 프로그래밍도 데스크톱이나 웹 앱보다 ESP32나 소형 Raspberry Pi 컨트롤러 같은 임베디드 시스템으로 시작하길 권함. 내가 지도했던 이들 중 가장 잘 성장한 이들이 그렇게 시작했기 때문임.
코드가 무엇을 하는지 이해하려면 하드웨어를 직접 다뤄야 함. LLM이나 복사한 MicroPython 코드로 모터를 제어하더라도, 작동하지 않으면 저렴한 소형 오실로스코프를 꺼내 파형을 살펴봐야 함. 라이브러리에 가려진 큐가 아니라 하드웨어가 구동하는 큐를 이해하고, LED가 왜 예상과 다르게 깜빡이는지 알아내는 과정이 필요함.
내가 강좌를 만든다면 의도적으로 점점 더 잘못된 복사용 코드를 주고, 고치는 일은 학습자의 과제로 남기겠음.

더 빨리 배울 수 있다는 데 동의하지만, AI 이전부터 숙련된 개발자였던 이들에게만 해당한다고 봄. 기초를 건너뛴 뒤 5~10년 후 우리의 실력이 어떨지 지켜봐야 함.

내 결론은 LLM 걱정을 그만하자는 것임. 커리–하워드 동형성에 따르면 프로그래밍 언어는 일종의 형식 논리를 표현하는 표기법임. 프로그램을 유지보수할 때 자연어가 형식 논리보다 쉽고 관리하기 좋을까? 그렇지 않으므로 형식적 기술을 읽고 새 요구사항에 맞게 바꿀 프로그래머가 필요함.
LLM은 놀라운 기술이지만 자연어 자체는 그다지 좋은 도구가 아니므로, LLM이 꼭 필요한 것은 아님. https://en.wikipedia.org/wiki/AI_effect도 참고할 만함.
LLM을 좋아하는 이유는 마술사를 좋아하는 이유와 비슷하다고 봄. 마술에 숨은 기법이 있듯 LLM도 보이지 않거나 이해하지 못하는 알고리즘을 실행함. LLM이 프로그래머의 일자리를 빼앗을까 걱정하는 것은 물건을 공중에 띄우는 마술사가 창고 노동자를 대체할까 걱정하는 것과 비슷함. 이미 컴파일러라는 자동화된 프로그래머도 존재함.

자연어에 관해서는 Edsger W. Dijkstra의 글을 참고할 만함. https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667....
내 생각을 덧붙이자면, 자연어는 말하지 않는 부분에도 가치가 있음. 모호함은 기능의 핵심이며 복잡한 사회적 관계를 다룰 때 유용함. 글 역시 전달하지 않는 부분에 가치가 있음. 의사소통의 90%가 비언어적이라는 관점에서 보면, 글은 그 나머지 90%를 전달하지 않고도 말을 전할 수 있어 협상 등에 도움이 됨.

LLM은 자연어를 실행하지 않음. 자연어로 문제나 요청을 설명하면, LLM은 그 요청을 충족할 것으로 예측하는 형식 논리를 생성하고 시험함.

동의하지만, 지난 몇 달간 명세를 위한 최적의 언어가 무엇인지 고민 중임. 영어 Markdown은 아니라고 보지만 Java도, Gherkin도 아닌 듯함. Lisp일 수도 있겠지만 아직 찾고 있음.

악의는 없지만, 자연어가 형편없다는 말은 언어를 제대로 다루지 못하는 논리학자의 도피처임. 복잡한 언어는 자연계에서 분명히 우월하며, 계산에서도 그렇다는 사실을 이제 알아가는 중임.

소프트웨어 개발과 시스템 유지보수, 네트워크·전화 시스템을 담당하고 주니어들과도 일하는 엔지니어로서, AI는 속도를 높이면서 동시에 늦출 수도 있는 도구임. 여러 장비에서 빠르게 처리해야 하는 유지보수 작업을 응답에 시간이 걸리는 클라우드 AI에만 의존할 수는 없음.
AI를 만능 해결사처럼 쓸수록 실력이 떨어질 수 있음. 전문가에게도 양날의 검이고, 주니어는 그럴듯한 웹사이트나 시각적 결과물을 빨리 만들 수 있어도 AI 의존의 고리에서 벗어나지 못하면 전문가로 성장할 수 없음. AI가 순전히 긍정적 효과만 내려면 데이터베이스 선택, 고가용성 시스템, 프로그래밍 언어 같은 소프트웨어 공학적 판단이 중요하지 않은 세상이어야 할 것 같음.

제대로 일하려 애쓰는 엔지니어지만, 소프트웨어 공학이 중요하지 않은 것은 아닌지 걱정되기 시작함. 나는 모든 줄을 이해하고 유지보수성과 구조를 고민하며 코드를 쓰지만, 유지보수 불가능한 코드를 엄청난 속도로 쏟아내는 동료들보다 훨씬 느림.
지금까지 고객이 코드 구조나 품질에 불평한 적은 한 번도 없음. 죽어가는 산업의 유사에 빠져드는 기분임.

AI로 만들었지만 이해하지 못하고, 수정도 고장 원인 추론도 못 한다는 것 아닌가? LLM으로 만들기 전에 직접 프로그래밍할 수 있어야 함. 그렇지 않으면 결과물을 평가할 방법이 없음. AI가 아니라 프로그래밍을 배우는 과정이 프로그래머를 만들어줌.
흥미로운 글이지만, 내 조언은 전통적인 어려운 길로 배우라는 것임. 지식과 기술, 배움에는 왕도가 없음.

동료가 “프로그래머가 하면 바이브 코딩이 아니다”라고 했음. 소프트웨어 내부와 구조화 패턴을 이해하는 가치는 여전히 확신하지만, 이런 지식이 단순한 학문적 관심 이상의 가치를 지니는 기간이 얼마나 남았는지는 궁금함.

계산기를 쓰기 전에 손으로 수학을 푸는 이유를 다시 배우는 중임. 현실에서는 금방 검색할 수 있어도 시험에서 대개 인터넷을 허용하지 않는 이유도 마찬가지임.

성공한 스타트업 중 상당수는 좋은 아이디어와 끔찍하게 유지보수하기 어려운 코드로 출발함. 현재 LLM은 그 초기 단계를 빠르게 통과하게 해줌. 일주일 된 진흙 덩어리 같은 코드에 계속 진흙을 덧붙이고, 그 덩어리를 무슨 수를 써서라도 보존하려 애쓰게 됨.
그래도 제품은 제법 잘 작동할 수 있음. 사람이 테스트와 세부 개선, 제품 설계와 UX 선택을 충분히 챙긴다면 시스템 설계에는 크게 신경 쓰지 않고도 버틸 수 있음. 실제로 재작성이 필요한 1~3년 뒤에는 모델도 나아질 가능성이 크며, 지금도 끈기 있게 모델을 나쁜 설계에서 벗어나도록 유도하면 어느 정도 성과가 있음.
모델 업체들은 개별 코딩 과제의 통과율뿐 아니라, 오랜 기간 우아한 코드와 단순하고 깔끔한 아키텍처를 목표로 삼게 하는 후속 학습도 개선할 것임. 실행 환경의 지시로 그런 성향을 특히 강화할 수도 있을 것임.
앞으로도 숙련된 프로그래머가 더 좋은 결과를 얻겠지만 비프로그래머와의 격차는 점차 줄어들 것으로 봄. 좋은 아이디어가 있어 당장 시작하려는 사람이라면, 개발 지식 없이 먼저 초기 버전을 만들고 작업을 이어가며 실제 소프트웨어 개발을 배우는 편이 더 나을 수 있음. 모델이 지금 수준에 머물러도 그렇다고 보며, 실제로는 프로그래밍 능력이 훨씬 좋아질 가능성이 큼.

중국의 WTO 가입은 AI가 대량 실업을 일으킨다는 근거로 부적절함. 당시 미국 실업률은 이미 상승 중이었고 가입 직후 정점을 찍은 다음 가입 시점보다 훨씬 낮아졌음. 다시 오른 것은 중국과의 경쟁과 거의 무관한 글로벌 금융위기 때였음.
일자리가 대규모로 사라지지 않았다는 뜻은 아니지만, 다른 일자리로 대체됐고 최근 미국 실업률은 역대 최저 수준에 가까웠음. 중국의 WTO 가입은 AI로 사라진 일자리를 새로운 일자리가 대체할 것이라는 전망의 반례보다 뒷받침하는 근거에 가까움. https://fred.stlouisfed.org/series/UNRATE

글의 핵심도 새 일자리가 실직한 당사자에게 돌아가지는 않았다는 것임. 탄광 노동자가 하루아침에 프로그래머가 된 것은 아님.
중간 소득의 산업 일자리가 수는 더 적고 소득은 높은 서비스·지식·첨단 산업 일자리로 대체됐지만, 두 집단의 노동자는 거의 겹치지 않았음. 미국 러스트벨트나 잉글랜드 북부 같은 지역이 황폐해지고 빈곤해진 이유임.

몇 년째 아이들에게 프로그래밍을 가르치는 중이라 절실한 주제임. 내가 사랑하는 프로그래밍을 배워야 한다는 전제가 AI로 무너지는 듯해 우울하지만, 앞으로 살아갈 세상에 대비하도록 세 가지 학습 원칙을 세웠음.
첫째, 고통스러울 만큼 느리더라도 항상 AI 없이 직접 만드는 프로젝트를 진행하게 함. 둘째, AI를 소스 코드가 아니라 자료구조·알고리즘·아키텍처 요구사항을 입력받는 컴파일러처럼 다루게 함. 조립을 지시하기 전에 이론적 구성요소를 이해해야 함.
셋째, AI를 알고리즘과 문제 해결 지식을 넓히는 도구로 활용하되, 모델보다 먼저 원인 가설을 세우게 함. 직접 만든 칸반 도구에 가설을 이슈 카드로 적은 뒤, 모델과 조사하며 실제 원인에 얼마나 가까웠는지 확인함.
평생 코딩하며 쌓은 디버깅 경험과 비슷한 것을 얻길 바람. AI와 코딩할 때 내게 가장 유용한 역량은 좋은 유지보수 가능한 아키텍처를 알아보는 능력과 “전에 본 문제”를 알아채는 경험임. 이제 시작해 성과는 아직 거의 없고 수업에 AI를 들이는 것도 위험하게 느껴지지만, 피하기만 하는 것도 답은 아니라고 봄.

AI로 인한 주식시장 위험에 대비하고, 동료애를 느끼며, 젊은 사람들을 지도하려고 은퇴 후 복귀했음. 그런데 AI가 복귀 이유를 모두 무색하게 만듦. 에너지와 AI 때문에 주식시장은 스트레스가 크고, 동료들은 혼자 에이전트를 관리하며 일함.
젊은 이들에게 해주는 개발 조언도 3년 전에는 통했겠지만 이제는 거의 의미가 없음. 이들이 괜찮을지 걱정되고, 미래의 일자리 상실에 구체적인 이름과 얼굴이 생겨 더 우울해짐. 모든 게 무의미하게 느껴짐.

진짜 문제는 건강하게 배울 환경이 사라졌다는 것임. 어릴 때는 아무도 무슨 일이 벌어지는지 잘 모르는 상태에서 고통스러울 만큼 느리게 배우는 데 마법 같은 매력이 있었음. 완성 여부보다 무언가를 작동시키려 애쓰는 즐거움이 중요했음.
AI는 초점을 최종 결과물로 옮기는데, 솔직히 지루함. 아이들은 빠른 초기 성과 때문에 AI를 쓰겠지만, 빈 화면에서 자기 힘으로 무언가를 만들어가는 환경은 사라짐. 기업은 단기 이익을 좋아하겠지만, AI를 발명한 것 자체가 세상 전체에 해를 끼쳤다고 봄. 모두가 생산자가 되도록 길들여지는 중임.
작은 학습 환경을 따로 만들면 가능할지도 모르지만, 요즘 프로그래머들은 AI의 재미에 눈이 멀어 삶의 만족에는 재미 이상의 것이 필요하다는 사실을 잊는 듯함.

최근 좋았던 튜토리얼을 다른 기술로 옮겨 다시 학습하는 방식이 흥미로웠음. Catlike Coding, libtcod 로그라이크 같은 튜토리얼을 Astra에게 다른 기술·구성·언어로 변환하게 하되, 저자가 의도한 시행착오와 막다른 길도 모두 남기도록 했음. 소프트웨어 스크린샷은 그대로 옮기고, 도표는 입력에 따라 그래프·도형·값이 어떻게 바뀌는지 보여주는 상호작용형으로 재현하게 함. 파일 수정을 유도하는 방식도 보존해야 함. 어떤 대목은 메서드를 통째로 교체하고 설명하지만, 다른 대목은 새 메서드 시그니처에 맞게 특정 파일의 조건문을 고치라고 함. 후자는 무작정 복사하지 않고 직접 따라가며 시도하도록 만듦. 원래 튜토리얼처럼 새 기술에 대한 통찰을 얻는 느낌임.
다만 결과물은 철저히 개인 학습용임. 이를 공개하는 것은 사회 전반과 특히 원저자에게 도덕적으로 해로운 일이라고 봄. 원저자가 원했다면 직접 만들 수 있었을 것임.

2002년쯤 프로그래밍을 시작해 강력한 LLM이 있는 세상에서 입문하는 느낌은 모를 것임. 그래도 조언하라면 일단 만들고 호기심을 유지하라고 하겠음.
LLM으로 사이트 전체를 만든 뒤 궁금한 부분을 파고들면 됨. 코드를 보고 작동 원리를 물으며 프로그램 구성을 이해할 때까지 탐구하는 것임. 장난감 예제가 아니라 실제 프로그램을 살핀다는 장점이 있음. 버그나 성능 문제가 생기면 LLM과 디버깅하며 느려진 이유와 관련 개념을 배울 수도 있음.
멋진 것을 만드는 동시에 실제 사례에 기반한 자기만의 교육과정을 즉석에서 구성할 수 있음. 가장 큰 장벽은 동기일 것임. 호기심 없이 그저 작동하기만 바라면 아무것도 배우지 못함.

먼저 어떤 사람이 되고 싶은지 물어야 함. 프롬프트를 잘 쓰는 사람이 되고 싶은가? 훌륭한 요리사가 Uber Eats 주문을 잘하는 사람으로 바뀌는 것과 비슷함. 주니어에게도 그것만으로 충분하지 않을 수 있음.
우리는 프로그램을 만들지만, 프로그램을 쓰는 과정도 우리를 만듦. 자신이 하는 일과 조직을 움직이는 프로그램을 이해하지 못하는 사람에게 의존할 이유도, 그런 프롬프트 작성자의 경력 경로도 보이지 않음.
다만 인간과 기계의 협력은 강력할 수 있음. 기능 50개 중 25개는 직접 구현하고 나머지 25개는 클래스·메서드 뼈대와 프롬프트 역할을 할 주석을 작성하는 방식임. AI는 내 코드를 검토하고 개선점과 사각지대를 찾아주며 좋은 관행을 배우고, 나는 생성된 코드를 같은 방식으로 검토함. 운이 좋으면 AlphaGo와 이세돌의 2국 37수처럼 전혀 새로운 해결책을 제안해 나도 배울 수 있음. 직접 구현과 상호 코드 검토를 병행하면 코드 읽는 능력도 좋아지고, 전부 위임하지 않은 채 실력을 유지하며 새 기술도 따라갈 수 있음. 토큰 가격이 오르는 와중에 다른 AI만 유지보수할 수 있는 기술 부채 덩어리로 코드베이스가 변하는 것도 피할 수 있음.

프롬프트 작성은 기껏해야 과도기적 역할임. 앞으로 가장 돈이 되는 AI 분야는 법적 책임을 묻는 소송일 것 같음. 작은 국가 규모로 성장한 소수 AI 기업에 자신들이 세상에 풀어놓은 것의 책임을 물어야 하기 때문임.

내가 바로 그렇게 배우는 중임. LLM 코딩을 시작한 뒤 코딩 자체를 배우고 싶어졌음. 공학을 떠날 때는 물리학이 최고라고 생각했지만, 이제는 내가 무언가를 만드는 데 얼마나 열정적인지, 양자역학은 내게 얼마나 지루했는지 알게 됨. 늦게라도 깨달아서 다행임.