# 코드의 죽음은 과장된 주장임 > Clean Markdown view of GeekNews topic #27776. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27776](https://news.hada.io/topic?id=27776) - GeekNews Markdown: [https://news.hada.io/topic/27776.md](https://news.hada.io/topic/27776.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-23T15:35:17+09:00 - Updated: 2026-03-23T15:35:17+09:00 - Original source: [stevekrouse.com](https://stevekrouse.com/precision) - Points: 1 - Comments: 1 ## Topic Body - 프로그래밍은 **모호한 명세를 정밀하게 다듬어 가는 창조 행위**로, AI는 영어 명세를 코드로 변환해 이 과정을 가속함 - **‘Vibe coding’** 은 감각적 개발 방식을 가능하게 하지만, 추상화의 누수로 인한 **복잡성과 버그 문제**를 피할 수 없음 - 인간은 복잡성을 다루기 위해 **추상화와 압축을 활용**하며, 이는 프로그래밍의 본질적 가치로 작동함 - **AGI 시대**에는 AI가 더 나은 추상화를 지원해 **정교하고 예술적인 코드 창조**를 가능하게 할 전망임 - “코드는 죽었다”는 인식과 달리, **AI는 코딩의 종말이 아니라 새로운 시작을 여는 도구**로 제시됨 --- ### 코드의 죽음은 과장된 주장임 - **영어 명세의 모호함과 정밀성의 한계**를 지적하며, 프로그래밍은 글쓰기처럼 반복적으로 정밀도를 높여가는 행위임 - Bertrand Russell의 인용문을 통해 “정확히 만들려 시도하기 전까지는 모든 것이 모호하다”는 점을 강조 - AI는 영어로 작성된 명세를 실행 가능한 코드로 빠르게 변환해, 사용자가 점진적으로 원하는 결과를 구체화할 수 있게 함 - **‘Vibe coding’** 은 AI가 생성한 결과물에 반응하며 감각적으로 개발하는 방식이지만, 이는 **정확한 추상화의 환상**을 줄 수 있음 - 추상화가 누수될 때 예기치 못한 버그가 발생하며, 이는 규모가 커질수록 심각해짐 - Dan Shipper의 사례처럼, ‘vibe coding’으로 만든 협업 텍스트 에디터가 인기를 얻은 뒤 복잡성 문제로 다운된 경험이 소개됨 - “라이브 협업”은 직관적으로 단순해 보이지만 실제로는 매우 어려운 문제로, 복잡성의 본질을 보여줌 ### 추상화와 복잡성의 통제 - 인간은 한 번에 약 7±2개의 항목만 인지할 수 있어, **복잡성을 다루는 유일한 방법은 ‘압축’**, 즉 **추상화**임 - Edsger Dijkstra의 인용문을 통해 “추상화의 목적은 모호함이 아니라 새로운 의미 수준에서의 정밀성”임을 강조 - Sophie Alpert가 Slack의 복잡한 알림 흐름도를 단순화한 사례를 예시로 제시 - 프로그래밍의 핵심은 **복잡성을 다루기 위한 더 나은 추상화의 창조**이며, 함수형 반응형 프로그래밍 등에서 그 아름다움을 찾을 수 있음 - 협업 텍스트 에디터처럼 본질적으로 복잡한 문제도 ReactJS나 TailwindCSS 같은 추상화 도구를 통해 점진적으로 정복 가능 ### AGI 시대와 코드의 역할 - AI가 점점 더 빠르고 저렴하게 발전함에 따라, 결국 **인간과 구별되지 않는 지능(AGI)** 에 도달할 것임 - AGI 시대에는 누구나 ‘Karpathy급 천재 100명’을 저렴하게 활용할 수 있을 정도로 강력한 지능을 이용하게 될 전망 - 그러나 이는 ‘더 많은 부실한 코드’를 양산하기 위한 것이 아니라, **더 나은 추상화와 복잡성 이해를 위한 도구**로 사용될 것임 - 코드는 단순히 소프트웨어를 만드는 수단이 아니라, **그 자체로 중요한 예술적 산물**이며, 잘 작성된 코드는 시(詩)에 비유됨 - 글쓰기에 ‘vibe writing’이 존재하지 않듯, 코딩 역시 단순한 감각적 행위로 대체될 수 없음 - AGI가 도래하면 기계가 ‘비부실(non-slop)’ 코드를 작성할 수 있게 되며, 이는 인류에게 영광스러운 진전이 될 것임 ### AI와 코드 품질의 향상 - 현재 AI는 여전히 **불완전한 코드**를 생성하지만, 개발자들은 이를 감안해 활용하고 있음 - Simon Willison의 견해처럼, AI는 **더 나은 코드를 만드는 도구**로 사용되어야 함 - AGI가 등장하면 가장 먼저 **가장 어려운 추상화 문제 해결**에 투입되어, 협업 에디터 라이브러리 등 복잡한 시스템을 개선하게 될 것임 - Opus 4.6을 활용해 Val Town용 **풀스택 React 프레임워크(vtrr)** 를 개발한 사례가 소개됨 - React Router 7 관련 미해결 문제를 한 번에 해결했으며, 50줄짜리 단일 파일 데모로 복잡성을 우아하게 다룸 - 이처럼 **AI와 인간의 협업을 통한 정교한 코드 창조**가 가능함을 보여줌 ### 코드의 미래와 형식주의의 가치 - 사회의 다수가 “코드는 죽었다”고 믿지만, 이는 **인쇄기의 발명으로 이야기의 종말을 선언하는 것과 같은 오류**임 - AI는 코딩의 종말이 아니라 **코딩의 새로운 시작**을 의미함 - Edsger Dijkstra, Tony Hoare, Charles Babbage의 인용문을 통해 **형식적 사고와 기호의 압축력**이 인간 사고를 확장시킨다는 점을 강조 - Dijkstra는 형식 언어 사용을 부담이 아닌 특권으로 보아야 한다고 언급 - Hoare는 “결함이 명백히 없는 단순한 설계”와 “결함이 명백하지 않은 복잡한 설계”의 두 가지 접근을 대비 - Babbage는 **기호의 압축이 사고를 촉진하는 힘**임을 지적 - 결론적으로, **코드는 죽지 않았으며 오히려 AI 시대에 더욱 강력한 창조적 도구로 부상**함 ## Comments ### Comment 53657 - Author: neo - Created: 2026-03-23T15:35:17+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47476315) - Chris Lattner가 **Claude AI**로 작성된 컴파일러를 검토했는데, 혁신적인 부분은 없었다고 함 AI는 기존 지식을 평균적으로 재조합하는 경향이 있어 **비판적 사고**나 새로운 패러다임을 스스로 만들지 못함 인간은 기존의 합의에서 벗어나 사고할 수 있지만, AI는 그 합의로 되돌아가려는 힘이 있음 결국 AI는 **순응주의자(conformist)** 이며, 그것이 동시에 강점이자 약점임 [관련 글](https://www.modular.com/blog/the-claude-c-compiler-what-it-r...) - 나는 여러 시스템을 통합할 때 LLM이 가장 큰 도움이 됨 OAuth나 SAML 같은 복잡한 인증 설정을 직접 문서로 파악하느라 몇 시간을 쓸 필요 없이, LLM이 빠르게 **작동 가능한 통합 코드**를 만들어줌 또 AI와 대화하며 내 생각을 정리하는 **러버덕 디버깅**처럼 쓰기도 함 이런 대화는 실제 개발 경험이 없는 사람은 하기 어려운 수준의 복잡성을 가짐 - AI가 인간을 대체하느냐의 문제는 **이분법적**이 아니라 스펙트럼의 문제라고 생각함 진짜 걱정은 AI가 수요를 줄여서 업계가 **공급 과잉**이 되는가임 새로운 비즈니스 문제들이 계속 생긴다면 AI는 도구로서 도움을 주겠지만, 그렇지 않다면 AI 유무와 상관없이 일자리는 줄어들 것임 - “AI는 기존 사고의 중심 근처에서 답을 생성한다”는 말은 **보편 근사 정리**(Universal Approximation Theorem)와 관련 있음 신경망은 본질적으로 **보간(interpolation)** 을 수행하지, **외삽(extrapolation)** 은 하지 않음 즉, 학습된 영역 안에서는 정교하지만, 그 밖에서는 예측이 불가능함 [Wikipedia 문서](https://en.wikipedia.org/wiki/Universal_approximation_theorem)와 [SolidGoldMagikarp 예시](https://github.com/NiluK/SolidGoldMagikarp)가 이를 잘 보여줌 - Lattner의 평가는 **불공정한 비교**라고 생각함 Claude의 목표는 혁신이 아니라 “AI가 컴파일러를 만들 수 있는가”를 증명하는 것이었음 AlphaDev나 AlphaEvolve 같은 사례를 보면, **탐색적 학습과 지식 결합**으로 AI가 실제로 혁신을 만들어낼 가능성도 충분함 - AI가 **관습적 사고**를 따른다는 건 맞지만, 그게 오히려 강점임 대부분의 경우 우리는 예측 가능한 도구를 원하지, 스스로 학습하는 불안정한 존재를 원하지 않음 AI는 모순된 요구사항을 정리해 **일관된 구현**을 만들어내는 능력이 있음 예를 들어 “파란 잉크로 빨간 선 7개를 그려줘” 같은 불가능한 요청에도 논리적으로 대응함 Claude가 실제로 “그건 불가능하니 0개의 선을 그리는 게 정직한 답”이라고 한 건 **비판적 사고의 예시**임 - “AI가 새로운 기술을 만들 수 있을까?”라는 질문에 대해, 나는 회의적임 AI는 기존 데이터에 의존하므로, 새로운 언어나 프레임워크가 등장하면 학습 데이터가 부족해 **진화 속도가 느려질 위험**이 있음 - 하지만 소프트웨어는 이미 **도구의 변화 속도가 둔화**되고 있음 AI 코딩이 오히려 “바퀴 재발명”을 줄이고, **NIH 증후군**에서 벗어나게 할 수도 있음 - 나는 AI 모델로 **새로운 프레임워크**를 다루고 있음 학습 데이터가 거의 없어도 문서를 읽고 코드를 작성하며 **새로운 시도를 수행**할 수 있음 - 인간만이 새로운 것을 만든다는 전제는 근거가 약함 언젠가 AI도 **창의적 기술 합성**을 할 수 있을 것이라는 가능성을 열어둬야 함 - 더 큰 문제는, AI가 학습하지 않은 프레임워크는 **존재하지 않는 것처럼 취급**된다는 점임 결국 개발자들이 AI 학습 데이터에 포함되기 위해 **돈을 내야 하는 시대**가 올 수도 있음 - 이미 이런 문제를 해결하려는 시도가 있음 예를 들어 **skills.sh** 같은 플랫폼은 AI에게 새로운 프레임워크를 가르치는 **스킬 시스템**을 제공함 문서와 예제 코드만으로도 AI가 해당 프레임워크를 바로 사용할 수 있게 됨 - 나는 코드에 대해 **모순된 감정**을 가지고 있음 업무에서는 코드가 **부채**이지만, 동시에 **취미로서의 즐거움**이기도 함 Star Trek의 컴퓨터처럼 “말로 요청하면 알아서 처리되는” 세상이 가까워지고 있다는 생각이 듦 - 하지만 어떤 사람은 Star Trek식 미래와 지금의 현실은 **정반대 방향**이라고 말함 - 사회의 많은 **지적 자원**이 광고 기술이나 감시 산업에 쓰이고 있음 AI가 코딩을 대체하면, 이런 **인재 재배치의 계기**가 될 수도 있음 - 하지만 그런 산업 목표는 기술 변화만으로는 쉽게 사라지지 않음 - 나는 트리 구조에서 tombstone 없이 **이동·삭제·정렬이 가능한 CRDT**를 만들고 있음 Claude Code가 코드를 잘 쓰지만, 계속 tombstone을 추가하려고 해서 **논리적 증명**으로 설득해야 했음 아직 이런 세밀한 구조적 이해는 AI가 완전히 갖추지 못한 듯함 - 이런 프로젝트에는 **Codex**를 쓰는 걸 추천받음 - 새로운 기술이 등장할 때마다 인간은 항상 **과도한 기대와 실험의 시기**를 거침 그 과정을 통해 기술의 한계를 배우는 게 인간의 방식임 **에이전트형 프로그래밍**의 약속이 너무 좋아 보이지만, 결국 모두가 시행착오를 통해 현실을 배우게 될 것임 - 나는 “코드가 죽었다”는 주장보다는, 인간이 **추상화 수준을 한 단계 올리고 있다**고 봄 이제는 영어로 명세를 쓰면 AI가 코드를 작성함 하지만 완전한 **명확성(specificity)** 이 필요할 때는 여전히 코드가 더 유용함 사진 편집처럼, 정밀한 제어가 필요하면 직접 하는 게 낫지만, 대부분의 경우엔 AI에게 맡겨도 충분함 시간이 지나면 AI가 **안정적이고 보안성 높은 코드**를 인간보다 잘 쓸 것이라 생각함 - 물론 인간의 버그율이 LLM보다 높아지는 시점이 오면, **AI의 환각보다 인간의 오류**가 더 큰 문제가 될 수도 있음 - Simon Willison이 말한 것처럼, **vibe coding**의 진짜 가치는 “더 빠르게”가 아니라 “**더 나은 코드**”를 만드는 데 있음 여러 설계 모델로 프로토타입을 생성하고, **가독성·신뢰성·내결함성** 기준으로 반복 개선할 수 있음 - 나도 같은 희망을 가짐 이제는 코드 리뷰에서 “이 부분 이렇게 바꾸자”고 하면 AI가 바로 수정해줌 하지만 많은 동료들은 단지 “코드가 사라지는 세상”만을 기대함 - 얼마 전 Donald Knuth가 AI에게 증명을 요청했더니, AI가 **기존에 알려지지 않은 증명**을 찾아냈다는 기사가 있었음 하지만 그건 새로운 발견이라기보다, **잊힌 자료를 찾아낸 것**일 가능성이 큼 이런 점이 LLM을 **강력한 연구 도구**로 만드는 동시에, 마치 창의적인 것처럼 보이게 함 - “이미 다 발명됐다”는 1899년 특허청장의 말처럼, 인간의 **창의성은 계속 진화**함 - C 컴파일러를 만드는 건 생각보다 어렵지 않음 **Dragon Book**을 보면 몇 달 안에 작동하는 걸 만들 수 있고, 그 과정에서 모든 원리를 이해하게 될 것임 - C#이 2000년대 초반에 보여준 **혁신들**처럼, 앞으로도 새로운 언어적 진보는 계속 나올 것임 - 사실 C는 그렇게 복잡하지 않아서, 며칠 만에도 컴파일러를 만들 수 있을 것임 - 나는 프로그래밍 언어가 인간의 **의도를 압축적으로 표현**하는 수단이라고 생각함 하지만 때로는 자연어가 더 **정확하고 밀도 높은 의도 전달**을 할 때도 있음 좋은 추상화는 이 간극을 줄이는 것이며, DSL이나 ML/Lisp 계열 언어가 그 예임 예를 들어 [Electric Clojure 튜토리얼](https://electric.hyperfiddle.net/fiddle/electric-tutorial.tw...)처럼, 코드가 의도를 가장 잘 담을 수도 있음 결국 **Wittgenstein**의 말처럼, “모호한 그림이 때로는 우리가 필요한 바로 그것일 수도 있음” - 이에 대해 “**추상의 목적은 모호함이 아니라, 새로운 의미 수준에서의 명확성**”이라는 **Dijkstra**의 말을 덧붙이고 싶음