# 코드는 싸다. 이제는 ‘말’을 보여줘라 > Clean Markdown view of GeekNews topic #26333. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26333](https://news.hada.io/topic?id=26333) - GeekNews Markdown: [https://news.hada.io/topic/26333.md](https://news.hada.io/topic/26333.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-02T11:00:02+09:00 - Updated: 2026-02-02T11:00:02+09:00 - Original source: [nadh.in](https://nadh.in/blog/code-is-cheap/) - Points: 36 - Comments: 10 ## Summary LLM 코딩 도구의 확산은 리누스 토발즈가 말했던 "Talk is cheap. Show me the code" 의 반대인 “**코드는 싸다, 이제는 말을 보여줘라**”는 새로운 패러다임을 열고 있습니다. 이제 개발의 핵심은 코드를 얼마나 잘 쓰느냐가 아니라, 문제를 상상하고 명확히 설명하며 구조를 설계하는 **언어적 사고력**으로 이동하고 있습니다. AI가 완벽한 코드와 문서를 즉시 생성하는 시대에, 코드의 가치는 품질보다 **출처·책임·인간성**으로 재편되고 있으며, FOSS 생태계 역시 협업보다 **신뢰와 거버넌스** 중심으로 재구성되는 흐름을 보입니다. ## Topic Body - LLM 코딩 도구의 등장으로 **수십 년간 이어져 온 소프트웨어 개발의 기본 전제 자체가 붕괴**되었으며, 코드 작성보다 **문제를 정의하고 구조를 설계하는 능력**이 핵심 역량이 됨 - 이제 개발의 핵심은 **‘코드를 잘 쓰는 능력’이 아니라, 문제를 상상하고 명확히 설명하는 ‘말하기 능력’** 으로 이동 중 - 깔끔한 코드 구조, 잘 정리된 README와 문서는 더 이상 **성실함이나 숙련도의 신뢰 신호가 아니며**, 오히려 지나치게 완벽할수록 **슬롭(slop)** 일 가능성도 커짐 - AI가 생성한 코드와 인간이 작성한 코드의 **외형적 구분이 사실상 불가능**해지면서, 품질보다 **책임성·출처·인간성**이 코드의 가치를 가르는 기준으로 부상 - FOSS 생태계를 지탱해 온 **협업과 공유의 인센티브**가 약화되고 있으며, 코드 자체보다 **신뢰, 거버넌스, 큐레이션 역량**이 더 중요한 자산이 됨 - 이 도구들은 숙련된 개발자에게는 강력한 증폭기이지만, 초보자에게는 **기초 이해를 쌓을 기회를 앗아갈 수 있는 위험한 요정(genie)** 이 될 수 있음 --- ### 서론: Linus Torvalds의 격언과 그 전복 > "Talk is cheap. Show me the code" - 2000년 Linus Torvalds의 이 말은 **실제 코드를 써서 증명하지 않는 한 말에는 가치가 없다**는 태도를 상징했음 - 당시에는 아무리 명확한 개발 계획이 있어도, 복잡한 프로그램을 구현하는 일 자체가 **막대한 노력과 시간, 반복적인 지루함**을 요구했음 - 진짜 병목은 기술이 아니라 인간의 한계였음: **인지적 대역폭, 개인의 시간과 에너지**, 그리고 대규모 시스템 전체를 머릿속에 유지한 채 코드를 한 줄씩 써 내려가야 하는 생물학적 비용 - 그 결과 대부분의 아이디어는 **‘언젠가 해보고 싶은 위시리스트’에 쌓인 채**, 실제로 시도조차 되지 못한 채 사라졌음 ### 25년 후: LLM이 모든 것을 뒤집다 - 2025년, Linus Torvalds는 자신의 취미 프로젝트에 **AI가 생성한 코드**를 머지하며 “내가 손으로 직접 쓴 것보다 나은가? 물론이다”라고 언급 - 수십 년간 소프트웨어를 만들어 온 개발자의 시선에서, 저자는 **우리가 알던 방식의 소프트웨어 개발은 이미 끝났다고 단언**함 - 다이얼업에서 기가비트로, Basic에서 Node.js로, SourceForge에서 GitHub로 이어진 수많은 전환기를 직접 겪어온 세대로서, 이번 변화가 **일시적인 유행이 아니라 질적 단절**임을 분명히 인식 ### 코드 품질 평가 기준의 붕괴 - 과거에는 FOSS 프로젝트를 평가할 때 **프로젝트의 연령, 커밋 빈도, 코드 구조의 일관성, README와 문서의 품질** 등이 중요한 판단 기준으로 작동했음 - 간결한 주석과 잘 정리된 문서는 **개발자의 사려 깊음과 다른 개발자에 대한 배려**를 보여주는 신호로 받아들여졌음 - 그러나 LLM이 **완성도 높은 문서 페이지, 과도할 정도로 상세한 README, 깔끔한 UI, 정돈된 패턴과 주석**을 한 번에 생성할 수 있게 되면서 이러한 신호들이 더 이상 유효하지 않게 됨 - 결과적으로 해당 저장소가 **비기술자가 바이브 코딩으로 만든 것인지**, 아니면 **숙련 개발자가 설계한 결과물인지**를 외형만으로 구분하기 어려워짐 - 오히려 지나치게 완벽해 보일수록 **저노력 원샷 생성물**일 가능성을 의심해야 하는 역설적인 상황이 형성됨 - 전문가 수준의 세밀한 검토와 분석 없이는 **밀(wheat)과 슬롭(slop)을 가려내기 점점 어려워짐** - 이에 따라 코드 자체보다도 **누가 만들었는지, 왜 만들었는지, 어떤 이력을 가진 주체인지, 거버넌스와 유지 계획이 있는지** 같은 출처(provenance)가 더 중요한 판단 요소로 부상함 ### 노력의 가치 변화 - 과거에는 숙련된 개발자가 **의미 있는 결과를 내는 고품질 코드 10,000줄**을 만들기 위해 오랜 시간의 집중과 반복적인 개선 과정을 거쳐야 했음 - 코드 줄 수 자체는 품질의 척도가 아니지만, 잘 정제된 10,000줄의 코드는 **시간, 집중력, 인내, 전문성, 그리고 일정 수준의 프로젝트 관리 역량**이 투입되었음을 의미했음 - LLM은 이러한 결과물을 **단 몇 초 만에 생성**할 수 있으며, 테스트, 시스템 설정, 배포에 이르는 기술적 워크플로우 전반을 처리할 수 있음 - 인간의 전문성과 판단이 함께 개입될 경우, 결과물은 **충분히 실사용 가능한 높은 품질**에 도달할 수 있음 - 개인적으로도 **몇 주 혹은 몇 달이 걸렸을 작업을 며칠, 때로는 몇 시간 안에 끝낸 경험**을 반복적으로 겪음 - AGENT.md나 복잡한 멀티 에이전트 오케스트레이션 없이, **단순한 LLM 에이전트 CLI만으로** 이러한 압축이 가능했음 - 소프트웨어 결과물을 얻기 위해 지불하던 **생리적·인지적·감정적 비용**이 여러 자릿수 단위로 감소 - 이렇게 확보된 시간과 인지적 여유는 **엔지니어링 사고, 아키텍처 설계, 토론, 실험, 상상력 확장**에 재투자됨 - **“프로그래밍은 90% 생각이고 10% 타이핑이다”** 라는 오래된 말이 **비유가 아니라 현실이 된 상태** ### 슬롭(Slop)의 정의와 코드의 가치 - 코드를 한 줄도 써본 적 없는 사람조차 몇 초 만에 산업적 규모로 코드를 만들어낼 수 있는 상황에서, **코드라는 산출물 자체의 가치는 무엇일까?** - “AI 코드 대신 순수한 인간 코드만 원한다”는 주장은 현실을 고려하면 **아이러니에 가까운 농담**에 불과함 - CrowdStrike IT 장애(2024), Boeing 737 MAX 운항 중단, 영국 우체국 스캔들, 인도 대규모 데이터 침해, Equifax 데이터 유출 등 **인간이 작성한 코드로 인한 대형 사고 사례**가 이미 충분히 존재 - 전 세계에서 인간이 매일 작성하는 코드의 **상당 부분은 품질 면에서 경계선에 걸린 상태**임 - 소프트웨어 개발은 여전히 **객관적인 성숙 단계에 도달한 전문 학문이라고 보기 어려운 분야** - 의사나 토목 기사는 엄격한 교육과 면허, 실무 결과에 대한 책임이 요구되지만, 소프트웨어 개발에는 유사한 제도가 거의 없음 - 오늘날의 사회는 **허술하게 설계되고, 대충 이어 붙여지고, 과도하게 부풀려진 코드 시스템** 위에서 돌아가고 있음 - 감정을 자극하는 주장으로 보자면, AI가 만든 슬롭은 최소한 **형식은 깔끔하고, 문서는 잘 정리되어 있으며, 구문적으로는 일관성**을 갖춘 경우가 많다고 말할 수도 있음 - 인터넷을 채운 **영혼 없는 LLM 생성 문장과 메시지**를 읽는 일은, 표현 그대로 편도체 뉴런 활성화의 낭비에 가깝다는 인식이 확산됨 - 인간의 창작 과정, 그 안에 포함된 완벽함과 결함이 빠지면 **언어·문학·예술·음악은 본질적으로 즐길 수 없는 대상**이 됨 - 노력 없이 **무한히, 즉각적으로 생성 가능한 것**은 인간에게 가치 판단을 부여하기 극도로 어려운 대상이 됨 ### 코드는 예술과 다르다 - 코드는 본질적으로 언제나 **목적을 위한 수단**이었지, 그 자체가 목적이었던 적은 없음 - 최종 사용자는 코드를 읽지도, 읽을 필요도 없으며, 코드 자체에 관심을 두지 않음 - 포털 뒤에서 돌아가는 수백 개의 시스템이 **어떤 언어, 프레임워크, 아키텍처로 구현되었는지**는 사용자에게 의미가 없음 - **코드는 철저히 감춰진 존재**이며, 사용자는 UX를 통해 코드가 만들어낸 결과와 효과만을 경험 - 기능적으로 동일한 AI 코드가 슬롭인지 아닌지를 가르는 기준은 **책임(accountability)의 구조와 인간성(humanness)의 개입 여부** - 오픈소스 저장소에 사람이 직접 작성해 올린 PR은, 코드 품질과 무관하게 **그 안에 들어간 인간의 시간과 노력을 전제로 한 공감과 가치**를 자연스럽게 부여받음 - 반대로 LLM이 생성한 PR은 품질과 관계없이 첫 반응이 “슬롭!”이 되는 경우가 많은데, 이는 **그 안에 담긴 인간의 노력을 즉시 가늠할 수 없기 때문** - 그와 동시에, 해당 코드를 읽고 검증해야 하는 부담은 **작성 비용과 비교해 불균형적으로, 기하급수적으로 커짐** - 결국 이는 노력 없이 생성된 **무한한 변형 중 하나**일 뿐이며, 의미 있는 출처나 맥락을 갖지 못함 - 이 지점에서 우리의 현실은 점점 **Borges가 묘사한 ‘바벨의 도서관’** 에 가까워짐 ### FOSS의 미래 - FOSS는 아마도 **인류가 만들어낸 가장 위대한 공공재** 중 하나 - FOSS의 출발점에는 소프트웨어가 **극도로 비싸고, 소수의 전문가만이 만들 수 있던 시대적 전제**가 있었음 - 전 세계에서 극소수만이 소프트웨어를 만들 수 있었고, 나머지는 그 결과물을 사용하는 쪽에 머무를 수밖에 없었음 - 이제는 아무리 틈새적인 요구라도, 전문가라면 **자신의 필요에 정확히 맞춘 소규모 라이브러리를 빠르게 만들어낼 수 있는 환경**이 됨 - 더 나아가, 어느 정도만 영리하다면 누구나 **개인 용도로 필요한 작은 도구를 바이브 코딩으로 직접 만들어 쓰는 시대**가 도래 - StackOverflow에서 벌어진 변화가, 속도는 느리지만 **소프트웨어 전반에서도 유사하게 진행 중** - 이는 FOSS 협업과 공유를 떠받쳐 온 **인간적 동기, 사회적 조건, 참여 인센티브의 핵심을 정면으로 흔드는 변화**로 보임 - 전례 없는 규모로 쏟아질 FOSS 프로젝트의 **캄브리아기적 대폭발**을 감안하면 - 결국 살아남고 번성하는 고품질 FOSS 프로젝트에서는 **코드 자체보다 전문가 거버넌스, 큐레이션, 신뢰 구조**가 더 중요한 자산이 될 가능성이 큼 ### 나무만 보고 숲을 못 보는 양극단 - 구문 강조나 IDE, 각종 도구가 없던 시절에도 인간은 이미 **놀라운 수준의 소프트웨어를 만들어냈음** - 반대로, 모든 도구와 자원이 넘쳐나는 지금도 **형편없는 소프트웨어는 계속 만들어지고 있음** - **표현력이 뛰어나고 품질에 관심을 가진 유능한 개발자**는 LLM이든 다른 도구든 자신만의 방식으로 활용해 좋은 결과를 만들어냄 - 반면 **문제를 설명하지 못하고 품질에 무관심한 개발자**는 LLM 사용 여부와 관계없이 나쁜 결과물을 생산 - 극단적인 ‘에이전틱’ 바이브 코딩 신봉자와 LLM을 전면 부정하는 사람들 모두, **결국 숲을 보지 못하고 나무에만 집착**하고 있음 - 경험과 전문성, 사고력과 표현력을 갖춘 사람이 **적절한 트레이드오프를 선택해 원하는 결과를 얻는 실용적인 중간 지점**이 분명히 존재 - 바이브 코딩은 비기술자가 **처음으로 소프트웨어를 만지고, 실험하고, 즐기며 역량을 키울 수 있는 중요한 진입점**이기도 함 - 그러나 바이브 코딩을 맹신하는 이들은 인간이 어떤 산출물을 진지하게 받아들이게 만드는 핵심 요소, 즉 **유한성(finitude)** 을 놓치고 있음 - 그 결과, 스스로도 **아첨하는 에이전트가 만들어낸 슬롭의 바다** 속에서 길을 잃기 쉬운, 거대한 보르헤스식 도서관을 쌓아 올리는 중 - 노력 없이 무한히 생성되고, 의미 있는 출처가 없는 산출물은 **가치를 부여하기도, 진지하게 받아들이기도 극히 어려움** - 인간은 본질적으로 **무한한 공급, 특히 선택지의 무한함을 잘 감당하지 못하는 존재** - 한편 LLM 부정론자들은 종종 **불신의 논증(argument from incredulity)** 을 넘어서지 못함 - 개인적으로 마음에 들지 않거나, 원하는 결과를 얻지 못했거나, 기대가 어긋났거나, 단순히 질렸다는 이유로 기술 자체를 부정 - 그러나 이는 동일한 도구를 **효과적으로 활용하며 정반대의 경험을 하고 있는 상당수의 사람들**이 존재한다는 사실 앞에서 설득력을 잃음 - 과대광고와 광란, 탐욕에 의해 추진되는 **어리석고 해로운 구현들**은 분명 현실이며 중대한 우려 대상 - AI 비즈니스 버블은 아마도 **역사상 가장 거대한 버블 중 하나**가 될 가능성 - 그럼에도 불구하고 **FOSS AI 기술의 확산은 분명 희망적인 신호** - 나쁜 행위자나 숫자 놀음, 터무니없는 구현을 **이 기술들이 가진 근본적이고 물리적인 능력과 동일시하는 것은 비합리적** ### 인간적 비용 - 경험 많은 개발자와 엔지니어의 관점에서 보면, 이러한 AI 기술은 **매우 강력하고 효과적인 보조 수단**으로 작동함 - 그러나 이제 막 업계에 발을 들인 **초기 단계의 학습자와 주니어들에게는 전혀 다른 문제가 제기됨** - 기초가 부족하고, 시스템과 소프트웨어 개발 과정에 대한 **내재적이고 미묘한 이해가 형성되지 않은 상태**라면, 이 기술은 **신뢰할 수 없고 위험한 요정(genie)** 에 가까움 - 코드를 요구하면 코드를 내놓고, 변경을 요청하면 즉시 수정해 주는 방식은 겉보기에는 편리함 - 하지만 곧 사용자는 **작동 원리를 이해하지 못하는 코드베이스**에 갇혀, 문제 해결을 위해 요정에게 계속 의존하게 됨 - 이러한 의존이 반복되면, 기초적이고 근본적인 역량이 자연스럽게 형성될 **학습 환경 자체가 사라지며**, 인지적 퇴화로 이어질 위험까지 존재 - 그 결과 **의미 있는 시니어로 성장할 기회를 얻지 못하는 주니어 세대 전체**가 등장할 가능성이 제기됨 - 진정한 우려는 슬롭이 무엇인지, 무엇이 아닌지를 **객관적으로 구별할 전문성을 습득할 기회가 학습자 세대에게서 사라진다는 점** - 더 심각한 문제는, 이 도구들을 능숙하게 활용하는 숙련자들마저 **주니어를 기초적인 방식으로 멘토링하고 훈련시킬 동기를 잃을 수 있다는 가능성** - 이는 소프트웨어 개발을 넘어, 인간이 **주체성과 의사결정을 블랙박스에 전면 위임하는 방향**으로 이어질 위험을 내포함 ### 결론: 이제 말(Talk)이 코드보다 가치 있다 - 손으로 직접 개발해 온 개발자에게도 이제는 **코드를 읽고 비판적으로 평가하는 능력**이, 구문을 익히고 한 줄씩 타이핑하는 능력보다 더 중요해짐 - 물론 후자는 여전히 중요한 기술이며, 효과적으로 코드를 읽는 능력은 결국 그 토대 위에서 형성됨 - 그럼에도 불구하고 **일상적인 소프트웨어 개발 워크플로우 자체는 이미 완전히 뒤집힌 상태** - **잘 말할 수 있는 숙련 개발자**, 즉 상상하고, 설명하고, 문제를 정의하며, 아키텍처를 설계하고 엔지니어링할 수 있는 사람은 그렇지 못한 사람에 비해 **그 어느 때보다 불균형적으로 큰 이점**을 가짐 - 특정 언어, 문법, 프레임워크에 대한 지식은 더 이상 **주요 병목 요소가 아님** - 과거 개발자를 묶어 두던 생리적·물리적 제약 역시 **더 이상 결정적인 장애물로 작용하지 않음** - 대규모 코드를 즉시 만들어내는 기계는 이제 **상품화된 도구**가 되었고, 누구나 `pip install` 수준으로 접근 가능 - 별도의 전문 훈련이나 새로운 언어, 프레임워크를 배울 필요도 사실상 사라짐 - 요구되는 것은 **오래된 비판적 사고력, 기초적인 인간적 역량, 그리고 이 기계를 다룰 수 있는 최소한의 운영 능력**뿐 - 그 결과 기존의 소프트웨어 개발 방법론과 역할 구분—Waterfall과 Agile, 개발자와 테스터, 시니어와 주니어—는 **근본적인 변화를 겪고 있음** - 전통적인 경계들은 **상상할 수 없을 정도로 빠르고, 압축되며, 흐릿해진 반복적 ‘에이전틱’ 루프**로 통합되는 중 - 이에 따라 소프트웨어 개발을 둘러싼 사람, 조직, 공공 커뮤니티의 동학과 **공유·협업을 지탱하던 인간적 인센티브** 역시 빠르게 변하고 있음 - curl의 버그 바운티 종료, Zulip의 AI 사용 가이드라인 도입, Ghostty의 명시적 AI 정책 등 사례가 이를 보여줌 - 역사상 처음으로, **좋은 말(talk)은 좋은 코드보다 기하급수적으로 더 큰 가치를 가지는 요소**가 됨 - 이 변화가 가져올 파급효과는 **중대하며, 동시에 매우 파괴적** ## Comments ### Comment 50548 - Author: orange - Created: 2026-02-03T17:44:25+09:00 - Points: 2 "코드를 한 줄도 써본 적 없는 사람조차 몇 초 만에 산업적 규모로 코드를 만들어낼 수 있는 상황" -> 수수깡으로 아파트를 지으면 그게 산업적 규모인가요 ### Comment 50454 - Author: goathead - Created: 2026-02-02T13:53:45+09:00 - Points: 2 토발즈의 저 말 좋아했는데... 시대가 완전히 달라졌네요 ### Comment 50558 - Author: kuthia - Created: 2026-02-03T21:44:59+09:00 - Points: 1 "학습 환경 자체가 사라지는 것"에 깊은 공감이 돼요. 지식의 접근 비용이 제로에 가까운 세상에서 교육이란 이제 어떤 형태가 되는 걸까요? ### Comment 50516 - Author: tested - Created: 2026-02-03T10:30:41+09:00 - Points: 1 현실은 대부분의 채용에서 자바 등의 언어 경력 N년차+ 이상 경력을 항상 요구함 ### Comment 50479 - Author: allinux - Created: 2026-02-02T21:00:43+09:00 - Points: 1 "말"과 "글"은 다른 것입니다. 사실 "말"보단 "글"을 잘 적어야 하는 것 같습니다. ### Comment 50469 - Author: pencil6962 - Created: 2026-02-02T19:19:51+09:00 - Points: 1 🐎🐎🐎🐎🐎 ### Comment 50503 - Author: skageektp - Created: 2026-02-03T09:22:29+09:00 - Points: 1 - Parent comment: 50469 - Depth: 1 키미노 아이바가 즈큥도큥~ ### Comment 50451 - Author: koreacglee - Created: 2026-02-02T12:23:18+09:00 - Points: 1 불과 몇년전만해도 회사 동료 또는 발자 모임등에 나가보면 실력은 없으면서 입만 나불대는(최신 트렌드기술 및 키워드에 대한 무지성 얼리어댑터적인 집착, 끽해야 프레임워크, 라이브러리 사용 경험만 있을뿐 기초적인 것도 직접 만들어본적 없는...) 엔지니어들을 "혀로그래머" 라고 깍아내리곤 했었는데... 이젠 "혀로그래머"가 개발자의 현실이 되었네요. 하 격세지감이다. ### Comment 50430 - Author: neo - Created: 2026-02-02T11:01:01+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46823485) - 오늘 Codex에게 Redux용 **단위 테스트**를 작성해달라고 했음 처음엔 괜찮아 보여서 그냥 넘어갔는데, 나중에 직접 테스트를 추가하려고 다시 보니 “이게 뭐지?” 싶은 부분이 수십 개 있었음 실행은 되지만 엉망이었음. 단순한 코드였는데도 이런 수준이었음 AI를 쓸 때마다 비슷한 경험을 함 — 겉보기엔 괜찮지만, 확장하려 하면 재앙 수준이라 결국 내가 다 정리해야 함 “코드는 싸다”는 말의 문제는, **생성은 싸지만 유지보수는 비싸다는 점**임 하루에 수천 줄씩 생성하는 건 신용카드로 빚을 쌓는 것과 같음. 공짜인 줄 알았다가 나중에 청구서가 날아오는 셈임 - 나도 항상 “**한 줄의 코드도 부채**”라고 말해왔음. 우리의 일은 그 부채를 최소화하는 것인데, 요즘은 그 원칙이 거의 사라진 느낌임 - 나는 Redux의 주요 유지관리자임. 어떤 코드가 생성됐는지 정말 궁금함 우리가 직접 영향을 줄 수 있을지는 모르겠지만, 어떤 일이 있었는지 보고 싶음 참고로 Redux의 테스트 접근법은 [공식 문서](https://redux.js.org/usage/writing-tests)에 정리되어 있음 - “Redux용 단위 테스트를 써달라”는 건 “개를 그려달라” 수준의 모호한 요청임 테스트 방법론을 먼저 정리하고, 그걸 기반으로 모델에 요청해야 함 AI는 명시되지 않은 부분을 **임의로 가정**하기 때문에 주의가 필요함 근본적으로 테스트가 핵심임. AI 코드에 대해 감으로 판단하지 말고, 테스트로 검증해야 함 코드의 가치는 테스트 수준에 비례함. “LGTM” 식으로 대충 넘기면 오토바이를 눈 감고 모는 것과 같음 - 지금 시점에서 LLM이 테스트를 작성하는 건 **위험할 때가 많음** 어떤 경우엔 잘 되지만, 어떤 경우엔 완전히 엉망임 예를 들어, 올바른 유즈케이스를 줬는데 코드가 틀렸고, 테스트가 실패하자 AI가 테스트를 다시 써버림 즉, 자기 기준으로 성공을 정의해버리는 위험이 있음 예전에 Claude 인스턴스를 두 개 띄워서 하나는 테스트, 하나는 구현을 맡겨봤는데, 설정이 너무 번거로웠음 - 코드 생성은 원래부터 싸게 느껴졌음 그래서 이 기술이 **팀에 강제로 도입되는 이유** 중 하나라고 생각함 클라우드 전환처럼, 진짜 비용은 나중에 드러남. 다만 이번엔 훨씬 빠를 것 같음 - 자동차 조립 비유로 설명하자면, 단순히 스펙에 맞춰 부품을 조립하는 사람은 로봇 팔이 대체할까 걱정할 만함 하지만 설계를 실험하고, 프로토타입을 만들고, 로봇 팔을 프로그래밍하는 사람은 자동화 걱정을 덜 함 많은 반론이 “AI가 그 두 번째 역할도 자동화한다”는 식이지만, 실제로는 **전자의 일을 후자로 착각하는 경우**가 많다고 봄 - LLM을 쓰는 **소프트웨어 엔지니어**는 일반 사용자보다 훨씬 강력함 디버깅, 방향 전환, 구체적 지시가 가능하기 때문임 일반 사용자는 “이거 안 돼요, 고쳐주세요”만 반복함 그래서 일의 형태는 바뀌겠지만, **직업 자체가 사라지진 않음** - 내 일은 돈 있는 사람들에게 내가 **필수적**이라고 믿게 만드는 것임 AI가 이걸 흉내 낼 수 있다면 나를 대체할 수도 있음 경쟁이 적은 경제라면 ‘그럴듯한 흉내’만으로도 충분함 - 문제는 자동화 여부보다, **CEO가 신경 안 쓴다는 점**임 형편없는 AI 결과물이라도 수익과 엑싯만 보장되면 충분함 세상은 언제나 ‘분산된 쓰레기’를 용인해왔음. Windows를 보라 - 나도 예전엔 “두 번째 유형”이라 자부했는데, 요즘은 내 일의 상당 부분이 **잘못 분류된 것 같음** 실제로는 자동화 가능한 부분이 많았고, 그동안 내 자존심이 과대평가됐던 듯함 - 네가 말한 건 전통적인 **결정론적 자동화**임 하지만 오늘날의 LLM은 훨씬 일반적이라, 어떤 클래스의 일도 맡을 수 있음 로봇 팔에게 “올해 자동차 디자인을 개선하라”고 하면 멈추겠지만, AI는 의견을 낼 수 있음 아이디어 → 설계 → 제작 → 테스트 → 평가까지 AI가 전 과정을 수행할 수 있다면, 이건 과거 기술과는 **본질적으로 다른 혁신**임 - “코드를 손으로 쓰는 시대가 끝났다”는 말은 과장임 이런 과장은 사람들의 **전문성을 흔들고 FOMO를 자극**하려는 수법임 겁먹지 말고, 스스로의 판단을 믿어야 함 - 어떤 기술이든 **표현의 틈새 시장**은 남아 있음 다만 기술이 실천 방식을 바꾸는 건 사실임 결국 중요한 건 성능, 비용, 일정, 품질의 균형을 맞추는 능력임 - “엔지니어링은 끝났다”는 주장에 늘 반발이 많지만, 내가 보기엔 대규모 제품에서 **코드 작성은 전체의 10~20% 정도**에 불과함 나머지는 설계, 실험, 분석, 커뮤니케이션 등인데, LLM이 이 부분을 대체하긴 어려움 오히려 협업과 조율이 더 복잡해지고, LLM이 그걸 악화시키는 경우도 많음 그래서 AI는 **대체재가 아니라 도구**로 보는 게 맞음 - 사실 글쓴이와 완전히 반대 입장은 아닐 수도 있음 그들도 “수십 년간의 개발 방식이 끝났다”고 했지, 엔지니어링이 끝났다고 한 건 아님 코드 작성이 10~20%라면, 나머지 ‘대화’가 더 중요해졌다는 뜻임 - “Code is cheap”의 진짜 의미는 **엔지니어링의 본질이 더 중요해졌다는 것**임 Linus의 말처럼 “코드가 의도대로 동작함을 보여줘야 함” LLM으로 몇 줄 쓰는 건 쉽지만, 안전하게 수정하는 건 여전히 어려움 Honeycomb의 Liz Fong-Jones도 이런 실수를 한 적이 있다고 함 - 실제로 **코딩은 전체의 10% 이하**라는 데 동의함 기업들이 LLM의 ROI를 추적하면서 현실을 깨닫게 될 것임 지금은 Gartner의 **하이프 사이클** 상단에 있고, 곧 환멸의 골짜기로 내려갈 것 같음 - 나도 비슷한 경험을 했음 Claude 덕분에 빠르게 리팩터링하다가, 어느 순간 완전히 멈췄음 이유는 내가 **무엇을 원하는지 몰랐기 때문**임 데이터 모델이 명확하지 않은 상태에서 “계속 써줘” 하면, 아주 나쁜 결과가 나옴 - 『**Software Engineering at Google**』에서도 말하듯, 프로그래밍은 단기적 활동이지만 **소프트웨어 엔지니어링은 장기적 과정**임 AI는 전자를 빠르게 하지만, 후자를 대체하진 못함 - “명확한 개발 계획과 구현 노하우”라는 전제는 현실적이지 않음 프로그래밍 자체가 곧 **계획 행위**이며, 언어는 훌륭한 사고 도구임 그래서 LLM을 보는 시각이 갈림 — 언어를 사고 도구로 보는 사람과, 단순 실행 도구로 보는 사람 전자는 프로그래밍 그 자체의 가치를 보고, 후자는 코드를 숨기려 함 결국 선택의 문제임: 처음부터 개념 모델을 잘 세울 것인가, 나중에 **디버깅 지옥**을 겪을 것인가 지금의 도구들은 전자에 맞춰져 있지 않음. **툴링 격차**가 큼 - 대부분의 사람은 LLM을 **사고의 도구**로 보고, 프로그래머는 여기에 **코딩 도구**로서의 관점을 더함 일부는 두 가지를 결합해 새로운 방식으로 일하고 있음 - “Talk is cheap”의 원래 의미는 “말은 쉽고 가치가 없다”는 것임 그런데 “Code is cheap. Show me the talk.”은 그보다 더 무가치하다는 식이라, 처음부터 불쾌했음 실제로 글을 읽어보니 예상이 맞았음 - 제목에 너무 집착하는 것 같음. 그건 그냥 **농담**임 글쓴이는 코드에 무지하지 않음. 오픈소스 활동도 활발함 요지는 단순함 — 과거엔 좋은 설계를 코드로 구현하는 게 비쌌지만, 지금은 싸졌으니 **설계의 질이 더 중요**하다는 것임 - 사실 이 문구는 Linus의 말, [“Talk is cheap, show me the code”](https://www.goodreads.com/quotes/437173-talk-is-cheap-show-m...)의 **역전 패러디**임 - 다른 맥락에서 보면 “말”이 더 중요할 수도 있음 코드보다 **개발자의 머릿속 모델**이 핵심임 코드는 그 모델의 부산물일 뿐, 인간 해석 없이는 의미가 없음 이런 관점이 LLM 사용에도 큰 영향을 줌 - “수십 년간 해오던 방식이 끝났다”는 말에 동의하기 어려움 2005년, 2015년, 2025년의 개발 방식은 다 달랐음 변화는 늘 있었고, “수십 년간 동일했다”는 전제가 틀림 - 하지만 지난 20년간 **핵심 워크플로우는 크게 변하지 않았음** 도구는 발전했지만, 개발자의 일 방식은 비슷함 - 예전 Visual Age for Java의 **즉시 컴파일** 기능을 떠올리면, 지금의 neovim은 그때보다 훨씬 강력함 지난 30년의 점진적 발전을 과소평가하는 경향이 있음 - 1995년과 2005년의 차이는 훨씬 컸음 당시엔 대부분의 정보가 **종이책이나 리버스 엔지니어링**으로 얻어졌음 - “Talk is even cheaper, still show me the code”라는 말이 더 와닿음 AI가 10배 생산성을 약속하지만, 실제로 그런 결과는 거의 못 봄 AI 덕분에 복잡성이 견딜 만해졌지만, 여전히 **React 앱 작성은 고통**임 비결정적 API를 다루는 것도 힘듦 그래도 오타나 예제 검색에 시간을 덜 쓰게 된 건 장점임 하지만 **추론력 부족과 지식 한계** 때문에 코딩은 여전히 지루함 - 예를 들어 Claude의 터미널 프로그램은 React를 60fps로 렌더링한 뒤 ANSI 문자로 변환해 터미널에 덮어씀 — 사실 **curses로 간단히 할 수 있는 일**을 복잡하게 구현한 셈임 - “Code is cheap. Show me the talk.” 같은 문구는 이제 **클릭 유도용 미끼**로 남용됨 글 자체는 나쁘지 않지만, 새로울 건 없음 AI 열풍을 타는 건 기업뿐 아니라 블로거와 인플루언서도 마찬가지임 AI 관련 긍정·부정 글에 자극적인 제목만 붙이면 HN이나 Reddit에서 트렌드가 됨 참고로 이 문구의 원조는 [이 트윗](https://nitter.net/jason_young1231/status/1935180703416897895)과 [이 밈 페이지](https://programmerhumor.io/ai-memes/code-is-cheap-show-me-the-talk-wafz)임 - 드디어 누군가 **극단 사이의 현실적 중간지대**를 잘 표현했음 LLM은 신도 아니고, 재앙도 아님. **도구**임 OpenAI, Google, Microsoft 같은 기업의 **렌트 추출**을 비판하면서도 Qwen이나 Mistral 같은 **로컬 모델**을 활용할 수 있음 클라우드 LLM은 보안상 **E2EE 불가능**하므로, 기업 환경엔 부적합함 하지만 로컬 LLM 덕분에 이제 **혼자서도 엔터프라이즈급 작업**이 가능함 Mac Mini 하나로 데이터베이스 질의, API 통합, 자동화까지 처리함 대규모 조직이 아니라면, **시니어 제너럴리스트 한 명이 세 명의 미드레벨을 대체**할 수 있음 물론 일자리 축소나 저작권 문제 등엔 여전히 불만이 많지만, 로컬 LLM은 내 **핵심 툴킷**으로 자리 잡았음 ### Comment 50493 - Author: xfile284 - Created: 2026-02-03T00:35:54+09:00 - Points: 1 - Parent comment: 50430 - Depth: 1 "신앙"을 하고있는 사람들에게 보여주고 싶은 글이군요