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은 내 핵심 툴킷으로 자리 잡았음