▲

코드는 싸다. 이제는 ‘말’을 보여줘라

 (nadh.in)
7P by neo 2시간전 | ★ favorite | 댓글 2개
  • 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)은 좋은 코드보다 기하급수적으로 더 큰 가치를 가지는 요소가 됨
  • 이 변화가 가져올 파급효과는 중대하며, 동시에 매우 파괴적
▲
koreacglee 25분전  [-]

불과 몇년전만해도 회사 동료 또는 발자 모임등에 나가보면 실력은 없으면서 입만 나불대는(최신 트렌드기술 및 키워드에 대한 무지성 얼리어댑터적인 집착, 끽해야 프레임워크, 라이브러리 사용 경험만 있을뿐 기초적인 것도 직접 만들어본적 없는...) 엔지니어들을 "혀로그래머" 라고 깍아내리곤 했었는데... 이젠 "혀로그래머"가 개발자의 현실이 되었네요. 하 격세지감이다.

답변달기
▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 오늘 Codex에게 Redux용 단위 테스트를 작성해달라고 했음
    처음엔 괜찮아 보여서 그냥 넘어갔는데, 나중에 직접 테스트를 추가하려고 다시 보니 “이게 뭐지?” 싶은 부분이 수십 개 있었음
    실행은 되지만 엉망이었음. 단순한 코드였는데도 이런 수준이었음
    AI를 쓸 때마다 비슷한 경험을 함 — 겉보기엔 괜찮지만, 확장하려 하면 재앙 수준이라 결국 내가 다 정리해야 함
    “코드는 싸다”는 말의 문제는, 생성은 싸지만 유지보수는 비싸다는 점임
    하루에 수천 줄씩 생성하는 건 신용카드로 빚을 쌓는 것과 같음. 공짜인 줄 알았다가 나중에 청구서가 날아오는 셈임

    • 나도 항상 “한 줄의 코드도 부채”라고 말해왔음. 우리의 일은 그 부채를 최소화하는 것인데, 요즘은 그 원칙이 거의 사라진 느낌임
    • 나는 Redux의 주요 유지관리자임. 어떤 코드가 생성됐는지 정말 궁금함
      우리가 직접 영향을 줄 수 있을지는 모르겠지만, 어떤 일이 있었는지 보고 싶음
      참고로 Redux의 테스트 접근법은 공식 문서에 정리되어 있음
    • “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”의 역전 패러디임
    • 다른 맥락에서 보면 “말”이 더 중요할 수도 있음
      코드보다 개발자의 머릿속 모델이 핵심임
      코드는 그 모델의 부산물일 뿐, 인간 해석 없이는 의미가 없음
      이런 관점이 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에서 트렌드가 됨
    참고로 이 문구의 원조는 이 트윗과
    이 밈 페이지임

  • 드디어 누군가 극단 사이의 현실적 중간지대를 잘 표현했음
    LLM은 신도 아니고, 재앙도 아님. 도구임
    OpenAI, Google, Microsoft 같은 기업의 렌트 추출을 비판하면서도
    Qwen이나 Mistral 같은 로컬 모델을 활용할 수 있음
    클라우드 LLM은 보안상 E2EE 불가능하므로, 기업 환경엔 부적합함
    하지만 로컬 LLM 덕분에 이제 혼자서도 엔터프라이즈급 작업이 가능함
    Mac Mini 하나로 데이터베이스 질의, API 통합, 자동화까지 처리함
    대규모 조직이 아니라면, 시니어 제너럴리스트 한 명이 세 명의 미드레벨을 대체할 수 있음
    물론 일자리 축소나 저작권 문제 등엔 여전히 불만이 많지만,
    로컬 LLM은 내 핵심 툴킷으로 자리 잡았음

답변달기