코딩은 해결된 문제가 아니다

코드를 읽는 것과 이해하는 것은 다름. 소프트웨어 일을 하며 얻은 교훈은, 내가 코드를 제대로 이해했다고 믿다가도 실제로는 다르게 작동한다는 사실을 발견하곤 했다는 것임.
LLM에는 가능한 실행 방식들을 분석하고, 퍼저와 속성 기반 테스트를 만들고, 가능한 모든 시나리오를 실행하며 전체 실행 추적과 출력을 기록한 뒤 버그를 분석하라고 요청할 수 있음. 손으로는 불가능한 작업임.
절약한 시간을 검증에 쓰고 자원을 충분히 투입한다면 의료·금융·자동차·국방·발전소·항공·제조업의 소프트웨어도 코드 한 줄 읽지 않고 더 신뢰성 높게 만들 수 있다고 봄. LLM은 논리에도 매우 강함.
이 글은 실제로 LLM으로 소프트웨어를 만들지 않거나 최근 모델을 써보지 않은 관점처럼 느껴짐. 나도 2025년에는 비슷하게 생각했지만, 어려운 코드를 수십만 줄 작성했고 한때 미국의 직불카드 결제 때마다 쓰이던 소프트웨어도 만들었음. 코드를 이해하고 품질을 중시하기 때문에 오히려 LLM 코딩에 전적으로 투자함.

테스트는 코드 이해나 정확성 증명과 다름. 나열한 작업을 LLM에 맡긴다고 해서 사람이나 LLM이 가능한 모든 상태와 입력에 걸쳐 동작을 논리적으로 추론하게 되는 것은 아님.
예상과 다르게 작동한다는 사실을 뒤늦게 발견했다면, 코드와 기반 시스템이 실제로 보장하는 것에 비춰 모든 가정을 사전에 충분히 검토하지 못한 것임. 대학에서 전산학 정리와 알고리즘의 정확성을 증명하는 정규 교육과 관련이 있을지도 모르겠음.

읽기만으로 프로그램의 동작을 이해하기에는 부족할 수 있지만, 상위 계층 코드조차 읽지 않고 동작을 이해할 수 있다는 믿음은 터무니없음.
여기서 상위 계층이란 애플리케이션의 높은 계층을 뜻함. 생성된 어셈블리나 인터프리터, 브라우저 구현을 매번 읽지 않는 이유는 그것들이 프롬프트와 달리 신뢰할 수 있는 추상화이기 때문임.

LLM 사용과 품질·신뢰성 중시를 양자택일로 보는 구도는 그만둬야 함. 글에 나온 핵심 산업들은 광범위한 테스트로 품질을 보장하며, 사람의 코드 검토는 그 위에 얹는 한 계층일 뿐 가장 결정적인 수단과는 거리가 있음.
코드를 이해하는 능력도 줄어든 것이 아니라 늘어났다고 봄. 이제는 AI가 만든 코드베이스가 사람이 만든 것보다 이해하기 쉽고, 막힐 때마다 질문도 할 수 있음. 글의 논지는 프롬프트 하나를 입력한 뒤 아무 생각 없이 곧바로 운영 환경에 배포하는 사람을 상정해야만 성립함.

2024년 이전에도 세상은 돌아갔고, 예로 든 직불카드 결제도 잘 작동했는데 지금은 소프트웨어가 더 나빠지는 것이 이상함. Claude에 사로잡힌 전형적인 간증처럼 들리며, Scientology를 연상시킴.

견해 차이의 원인이 지난 1년간 LLM의 성능 향상에 있다고 보지는 않음. 빠른 반복과 기능 출시가 매출을 이끄는 업계에서 정확성은 원래 우선순위가 아니었음.
제대로 만드는 데는 기회비용이 들고, 이를 아끼면 나중에 기술 부채를 치르게 됨. AI가 주로 취약한 코드를 만드는 데 쓰인다면 AI 기반 해법을 경계하게 될 것임. 안전성과 정렬에 관한 논쟁까지 이어지는 지금, 안전이 핵심인 분야에 AI를 배포하는 일은 꼭 그래야 하는 것은 아닌데도 어느 때보다 위험하게 느껴짐.

AI는 게으르고 무능한 개발자가 더 게으르고 무능하게 일하도록 해주며, 그 결과 제품 품질이 더 빠르게 악화됨. 쏟아지는 코드가 너무 많아 사람이 현실적으로 검토할 수 없으니, 그나마 형편없는 코드를 걸러주던 코드 검토도 사실상 마비됨. AI가 작성하고 AI가 검토하는 구조에서 결정적인 결과를 기대한다면 그 어리석음을 알아야 함.
소비자가 낮은 품질에 적응해 이런 개발자들의 자리를 유지시켜 줄지, 반발해서 기업이 개발자 수준을 높이도록 만들지는 시간이 알려줄 것임.
나도 매일 AI를 사용함. 게으르거나 무능하지 않다면 AI로 고품질 소프트웨어를 만드는 것은 충분히 가능함.

AI의 한계는 분명하지만, 결정적인 결과를 기대할 수 없다는 비판은 이해하기 어려움. 사람이 작성하는 코드에는 결정성을 기대하는 것인가?

개발자가 유능해도, 예전에는 하루 100줄이던 코드가 LLM 이후 5,000줄이 되면 내가 검토할 수는 없음.

모든 곳에 동적 타이핑을 쓰자던 유행과 매우 비슷해 보임. 초급 개발자나 역량이 부족한 개발자들이 타입 선언은 해롭고 정적 타이핑은 개발을 늦춘다고 했으며, 새 프로젝트에서는 실제로 더 빨랐음. 하지만 몇 년 뒤 부채가 쌓이자 거대한 무타입 모놀리스를 유지보수할 수 없다는 사실을 깨닫게 됨. 이제 Python과 JavaScript도 진지한 작업에서는 타입을 쓰므로 사실상 타입을 명시하는 언어가 됐다고 봄.
대화형 데이터 탐색, 간단한 스크립트, 시제품에는 여전히 동적 타이핑이 유용하지만, 업계가 처음에 이를 적용하려던 방식은 명백히 어리석었음. 5~10년 뒤 AI 활용 방식 일부도 비슷하게 돌아보게 될 듯함. Gastown 같은 사례에서는 이미 그런 일이 벌어짐.

LLM은 게으르고 무능한 개발자가 더 오래 버틸 여지를 준다고 표현하고 싶음.

글쓴이는 기업용 소프트웨어의 90%가 얼마나 단순하고 지루한지 과소평가하는 듯함. 항공기나 발전소를 제어하지 않는 소프트웨어 상당수는 하룻밤 만에 만든 코드, 부실하게 관리한 외주, 본업이 따로 있는 사람들이 작성한 낮은 품질의 요구사항에서 출발함.
그런데도 대부분 별 탈 없이 연중무휴로 돌아감. LLM은 그런 소프트웨어를 더 많이 만들게 해줄 뿐이며, 어쩌면 품질도 더 나을 수 있음.

글쓴이에게도 공감했지만 댓글의 반론에도 공감함. AI는 복잡한 작업까지 놀랍게 해내며, 적어도 나보다 코드를 훨씬 잘 작성함. 다만 매번 깊이 생각하지 않아도 되는 손쉬운 선택지를 제공한다는 점이 걸림.
개발자인 내 책임이라는 것을 알기에, 생성물을 이해하고 배우는 데 시간을 쓰려 노력하고 별도의 스킬도 설정해둠. 그래도 LLM 없이 직접 구현하면 오래 걸리는 대신, 출력을 읽고 대화할 때는 얻지 못하는 몰입에 들어가게 됨. 완벽하지 않더라도 훨씬 많이 배우고 문제의 맥락을 깊이 이해한 뒤 LLM으로 검토하면, 결과도 더 좋고 스스로 책임질 수 있는 구현이 됨. 경력 약 2년인 개발자로서 문제 해결 경험이 충분하지 않으므로, AI 도구를 내려놓고 직접 푸는 시간을 확보하지 않으면 성장이 정체될까 가장 걱정됨. 코딩이 대체로 해결됐다는 말에 꼭 반대하지는 않지만, 좋은 소프트웨어 엔지니어가 되기 위한 내 기초는 아직 완성되지 않았음.

Denver의 Explore DDD 행사에서 여러 저명한 인사와 생성형 AI가 소프트웨어 공학에 미치는 영향을 논의했는데, 대부분 모든 일을 AI에 맡기면 집단적 지식이 사라질 것을 크게 걱정함. 나는 반대 입장이었음. 인류는 발전을 단순화하려고 세부 지식을 감춰온 전례가 많으며, 이제 대규모 마이크로칩 납땜을 직접 하지 않고 정교한 기계에 맡기는 것도 그중 하나임.
코딩이라는 분야를 제외하더라도 소프트웨어 설계의 다른 측면들은 남으며, 대학 전산학 교육도 그쪽으로 재편할 수 있다고 봄. 핵심 전환은 코드 검토에서 설계 검토로 옮겨가는 것이며, 이는 생성형 AI와 무관하게 결과를 개선함.
약 1년 된 내 코드베이스 https://github.com/ChicagoDave/sharpee/는 내가 설계하고, 직접 만든 스킬과 에이전트를 안전장치로 삼아 Claude Code가 생성함. 생성된 코드는 사람의 검토가 필요 없다고 상당히 확신하지만, 시스템 설계와 변경 사항은 계속 직접 검토함.
아직 AI와 사람의 경계를 찾는 과정에서 너무 많은 부분을 사람이 개입하는 영역으로 붙들고 있음. 이를 놓아주고 사람의 결정이 필요한 부분을 정의해 거기에 집중해야 함.

통제할 수 없는 것에는 책임질 수 없다는 전제는 잘못됨. 법에서는 완전히 통제하지 못하더라도 소유하거나 관리하는 대상에 책임을 지는 일이 흔함. 개를 풀어놓거나 탈출할 수 있는 환경에 둬서 아이를 다치게 하면 책임이 따름.
합리적인 지침을 충분히 지켰는데도 예측 불가능한 일이 발생했다면 면책될 수는 있음. 하지만 그렇다고 통제하기 어려운 AI나 납품한 AI 생성 코드의 책임을 피할 수 있는 것은 아님. 늑대 무리를 풀어놓거나 아이를 다치게 할 수 있는 위험한 장난감을 판매하는 것과 같으며, 선례는 어디에나 있음.

법적으로 통제하는 위치라면 책임도 져야 함. 개나 위험한 장난감의 실제 대응 사례로는 OpenAI의 에이전트가 Hugging Face를 해킹하는 일을 들 수 있음. 차이라면 일부 기업은 법 위에 있는 듯하다는 것임.

코드를 쓰는 과정은 생각을 명료하게 하는 과정이며, 전에는 보이지 않던 질문에 답하도록 강제함. AI가 가정을 세우면 코드 자체로는 맞아도 더 넓은 맥락에서는 버그나 오류가 생길 수 있음.
반대로 가정하지 않고 사용자에게 묻는다고 해도, 무엇을 가정해도 되고 무엇은 물어야 하는지 AI가 미리 안다는 보장은 없음.

직장에서 최근 AI 글쓰기 제한 정책을 도입함. 서로 방대한 저품질 생성물을 주고받느라 시간이 너무 많이 낭비됐기 때문임. 사실상 쓰지 말라는 정책이고 근거는 “글쓰기는 생각하기”임. 코딩에도 적용할 깨달음에 거의 도달한 듯함.

AI는 설명해줄 수 있지만 대신 이해해줄 수는 없음. 코드는 생각이 명료해진 결과물일 뿐임. LLM은 컴파일러의 제약에 묶이지 않고 코드를 내놓으며, 피드백을 반복해 구문 오류를 없애고, 그다음에는 테스트를 통과시킴. 테스트를 속이는 경우도 있으니 주의해야 함. 이후 실행 오류를 잡고 나서야 개발자가 결과를 확인하며 명세에서 빠졌거나 모델을 혼란스럽게 한 부분을 다듬게 됨.
몇 시간 생각하는 수고를 피하려고 며칠씩 만드는 셈임.

솔직히 현재 LLM만으로도 코딩이 해결되지 않았다고 볼 이유를 모르겠음. 최상위 모델은 거의 모든 언어에서 초인적인 수준으로 코드를 작성·이해·수정·최적화함. 아직 LLM이 풀지 못하는 문제를 만나지 못했음.
논문을 주고 구현하라고 하면 한두 시간 뒤 완성하고, 영상이나 스크린샷을 보여주며 게임 엔진에 해당 기능을 넣으라고 해도 해냄. 완벽하게 최적화되지 않을 수는 있지만 사람의 코드 중 그런 것이 얼마나 될까? 사람의 몇 주 치 작업을 한 시간에 내놓는 속도상의 이점을 빼더라도 숙련 개발자를 압도함.

국방이나 항공은 위험 허용도가 낮겠지만, 의료 기술 분야도 그렇다는 데는 강하게 반대함. 두 의료 기술 회사에서 몇 년간 일한 비교적 짧은 경험이지만, 느리고 버그 많은 UI 때문에 사용자가 매달 몇 시간씩 고통스러운 사무 작업에 낭비해도 너무 쉽게 용인됐음. 물론 내가 맡은 제품은 평범한 CRM이었음.

여기서 위험은 UI의 완성도가 아니라 업데이트 후 소프트웨어가 멈출 가능성을 뜻함. 보통 엄격한 테스트와 배포 일정 대신 반복 개발 속도나 모범 관행을 희생함. Google이나 AWS에 보안을 맡기는 보통의 스타트업이 일반적인 제조업 소프트웨어 업체보다 보안 관행은 훨씬 나을 것이라고 봄.
그런 의미에서 원문의 논지도 잘 모르겠음. 이 산업들의 위험을 피하는 데 사람이 직접 코드를 작성하는지가 핵심이었던 적은 없기 때문임.