생성을 멈추고, 생각을 시작하세요

• LLM 코드 생성 도구에 대한 업계의 열광적 수용에 대해, 소프트웨어 개발에서 사고의 중요성을 강조하는 글
• 자동 생성 코드는 비결정적(non-deterministic) 이며 내부 작동이 불투명해, 매번 동일한 결과를 보장하는 기계화와는 본질적으로 다름
• LLM이 기존의 저품질 코드를 학습해 같은 실수를 반복하고, 이를 다시 학습하는 "인간 지네 인식론(human centipede epistemology)" 문제 존재
• 코드 생성을 에이전트에 위임하면 PR 리뷰 시 공유 맥락과 책임 소재가 약화되어 소프트웨어 품질에 악영향
• LLM은 프로토타이핑 등 제한적 용도에서는 유용하지만, 개발자가 사고 자체를 외주화하는 것은 위험하며 이해 없이 유지보수 불가

---

LLM 코드 생성에 대한 불편함

• 오랫동안 업계 최신 동향을 따라가며 CSS, JS 신기능을 동료들과 공유해온 경험이 있음에도, LLM 기반 코드 생성이 급속히 확산되면서 뒤처지는 듯한 불안감 경험
• Copilot과 Claude를 "spicy autocomplete"(매운 자동완성)와 디버깅 보조 도구로 사용해왔으나, 조금이라도 복잡한 작업을 시키면 결과가 엉망
• 충분한 컨텍스트를 제공해야 하지만 너무 많으면 과부하가 걸리고, "당신은 분산 시스템 전문가입니다"처럼 LLM의 자아를 달래는 긴 프롬프트를 작성해야 하는 상황
• 프롬프트를 다듬는 시간보다 직접 코드를 작성하는 것이 더 빠른 경우가 많음
• 엔지니어들이 코딩이라는 즐거운 작업을 버리고, 리뷰라는 지루한 작업만 남기려 하는 현상에 의문

"산업혁명의 재현"이라는 주장에 대한 반론

• 산업혁명이 기후변화에 기여한 것처럼, AI 데이터센터의 막대한 에너지 소비에서 유사한 패턴 확인
  • 모든 전력이 화석연료 기반은 아니지만, "새우 예수" 이미지 생성 같은 데 엄청난 자원 낭비
• 기계화는 상품을 저렴하고 널리 보급했지만 품질 하락을 초래, SHEIN에서 커피 한 잔 값보다 싼 바지를 살 수 있는 현실로 이어짐
  • 숙련 노동의 쇠퇴, 저임금 국가로의 공장 이전과 노동자 착취로 악화
• 생성된 코드는 패스트 패션과 유사: 겉보기엔 괜찮아 보이지만 시간이 지나면 구멍투성이, 종종 다른 사람의 코드를 무단 차용, 환경에도 악영향
• 핵심적 차이: 기계화는 매번 동일한 결과를 생산하고 문제 발생 시 내부를 들여다볼 수 있었지만, LLM 출력은 비결정적이고 내부 작동이 불투명
  • 매번 다른 결과를 내놓고 환각(hallucination) 이 섞이는 기계화 프로세스는 유용하지 않음

"추상화의 새로운 계층"이라는 주장에 대한 반론

• Java나 Go를 쓰면서 어셈블리를 배울 필요가 없어진 것은 사실이며, 가비지 컬렉션이나 메모리 할당을 런타임이 처리
• 그러나 시스템 아키텍처, 크리티컬 패스에 대한 영향, 유지보수성 대 배포 속도 간의 트레이드오프, 브라우저 호환성, 접근성, 보안, 성능 등은 여전히 개발자가 직접 사고해야 할 영역
• LLM이 가장 큰 피해를 주는 지점은 엔지니어가 소프트웨어 개발에 필요한 사고 자체를 외주화할 때
  • LLM은 추론 능력이 없으므로, 개발자도 생각하지 않고 LLM도 생각하지 않으면 아무도 생각하지 않는 상태
• Horizon 스캔들 사례: Post Office 소프트웨어 버그로 무고한 직원들이 수감되고, 13명이 자살
  • 소프트웨어에 대한 책임(accountability) 이 그 어느 때보다 중요

저품질 코드가 근본 문제

• 인간 개발자도 접근성이 떨어지고, 성능이 낮으며, JavaScript에 과도하게 의존하는 코드를 작성하고 있음
• LLM은 이런 저품질 코드를 학습 데이터로 훈련(명시적 동의 없이)받아 동일한 실수를 반복 출력
• LLM이 생성한 저품질 코드를 다시 다른 LLM이 학습하는 순환 구조, 이른바 "인간 지네 인식론(human centipede epistemology)"
• 보조 기술 사용자, 열악한 인터넷 환경의 사용자, 안면인식 소프트웨어의 인종 차별 피해자 등을 고려하면 현재의 소프트웨어 품질은 충분하지 않음
• 인간으로서 학습하고 개선하는 대신, 실수를 사고 없는 알고리듬에 외주화한 상황

PR 리뷰와 공유 맥락의 약화

• FFConf에서 Jessica Rose와 Eda Eren의 발표 핵심 메시지: "직접 작성하지 않은 코드는 이해하지 못하는 코드이며, 이해하지 못하는 코드는 유지보수할 수 없음"
• 동료가 작성한 PR에는 일정 수준의 신뢰와 사고 과정이 담겨 있지만, LLM 생성 PR에는 그런 보장이 없음
• 오픈소스 메인테이너들이 저품질 LLM 생성 PR의 폭증을 경험 중
• 일부 기업이 Slack에서 Claude에게 채팅으로 코드 변경을 요청하고, 자동 생성된 PR을 같은 사람이 승인하는 방식 사용
  • 이 경우 책임이 리뷰어 한 명에게만 집중되고, 두 쌍의 눈 중 하나를 잃게 됨
  • 팀 내 공유 맥락(shared context) 도 감소
• PR 리뷰는 버그 확인뿐 아니라 코드와 변경사항에 대한 이해 공유 과정

진보 반대가 아닌 과대광고 반대

• LLM 자체를 반대하는 것이 아니라, "인공지능"이라는 브랜딩에 반대
  • LLM은 지능적이지 않으며, 머신러닝의 한 형태
  • "생성형 AI"는 사람들이 과도한 기대를 거는 매우 잘 만든 마르코프 체인
• 프로토타입이나 와이어프레임, 인터랙티브 데모를 빠르게 만드는 용도에서는 합리적
• 문제는 "바이브 코딩(vibe code)" 으로 프로덕션 수준 소프트웨어를 만들 수 있다고 믿거나, 코딩의 사고 과정 자체를 위임하는 것
• Zed 블로그의 Mikayla Maki 견해: 에이전트는 신뢰하지 않는 외부 기여자처럼 다루고, 이미 수행 방법을 아는 작업에만 사용해야 하며, 코드를 이해하는 것이 필수
• "spicy autocomplete"는 계속 사용하되, 사고를 외주화하지는 않을 것이며, 이 일을 처음 좋아했던 이유를 기억해야 함

[crawler]

자동 생성 코드는 비결정적(non-deterministic)
"인공지능"이라는 브랜딩에 반대

정말 가장 중요한 말입니다..
긱뉴스에서도 계산기, 카메라로 비유하시는 분들이 있던데 개발자들도 이런 인식이면 일반인들은 어떨지 심각해 보여요.

[GN⁺]

Hacker News 의견들

• AI가 ‘마음의 자전거’가 아니라 대기업의 이윤 극대화를 위한 상품으로만 인식되는 한, 현재의 AI 상태를 정당화하기 어렵다고 생각함
  진정한 학습 과정 없이 데이터를 긁어모아 가공해 되돌려주는 구조는 인간의 정신적 성장에 불리함

  • 동의하지 않음. ‘상품화’ 논의는 경제적 지속 가능성의 문제이며, 지금 AI 산업은 경제적으로 불안정한 상태임
    결국 수익 모델을 세우는 것이 핵심이며, 그렇지 않으면 고품질 LLM을 유지할 수 없음
  • 책을 스캔한 뒤 불태우는 문제는 저작권법 탓이 아님?

• 나는 이제 거의 수동 편집을 하지 않음. Claude Code에 티켓 URL만 던져도 대부분 한 번에 해결됨
  이 방식에 투자하는 팀은 그렇지 않은 팀보다 훨씬 생산성이 높아질 것이라 믿음
  LLM은 사람마다 완전히 다른 경험을 주는 기술이며, 프롬프트의 자유도가 매우 큼

  • 이건 코드를 직접 보지 않을 때만 통함. 새 프로젝트에서 svelte 5 코드를 생성하라 했더니 버전 혼합 코드를 내놓음
    특정 디자인을 구현할 때는 오히려 직접 작성하는 게 더 빠름
  • Claude Code나 Cursor를 안 쓰는 사람들은 결국 시대에 뒤처질 위험이 있음
  • 나는 AI가 만든 코드를 검토하는 입장인데, 품질이 엉망이라 짜증남
  • 나도 같은 생각임. 이 사람들은 내가 쓰는 도구를 안 써본 듯함

• “내가 작성하지 않은 코드는 이해할 수 없다”는 말은 현실적이지 않음
  코드 리뷰의 목적은 작성자 신원이 아니라 시스템적 신뢰성 확보임
  인간이든 AI든, 심지어 골든 리트리버가 쳤든 상관없음

  • 코드를 직접 쓰지 않아도 읽고 디버깅하며 이해할 수 있음
    하지만 AI가 만든 PR을 굳이 이해하느라 시간을 쓰느니, 차라리 내가 직접 프롬프트를 날려 결과를 얻는 게 낫다고 느낌
  • 코드 리뷰도, 페어 프로그래밍도, TDD도 효과가 없다면 무엇이 효과적일지 궁금함
  • 이 논점은 ‘작성자가 코드를 이해하지 못하는 문제’임
    LLM에 의존하면 개발자가 프로젝트 구조를 학습할 기회를 잃고, 결국 시스템을 블랙박스로 다루게 됨
    이런 흐름은 개발자를 ‘프롬프트 키디(prompt kiddie) ’로 만드는 변화임

• “프롬프트를 다듬느라 시간을 낭비하느니 직접 코드를 쓰겠다”는 말에 공감함

  • 하지만 프롬프트가 재사용 가능한 기술이 된다면 이야기가 달라짐
    문제는 ‘생성’이 아니라 비구조적 생성임
    즉흥적 프롬프트 대신, 명확한 스킬 단위 구성(composition) 으로 접근해야 함

• “AI에게 ‘너는 분산 시스템 전문가야’라고 말해야 한다”는 건 GPT-3 시대 이야기임
  지금은 파인튜닝과 후처리 기법 덕분에 이런 롤 기반 프롬프트가 필요 없음

• LLM 코드 생성 열풍을 보며 ‘내가 뒤처지는 건 아닐까’ 불안했음
  Copilot과 Claude를 자동완성 도우미로만 써왔는데, 복잡한 코드는 여전히 엉망이었음
  그런데 요즘은 에이전트 기반 도구가 코드베이스를 검색하고, 웹에서 자료를 찾아 스스로 컨텍스트를 조정함
  결국 “기술을 제대로 이해하지 못한 채 불평하는 사람들”의 문제임

  • 이전 HN 스레드를 보면, “LLM이 내 알고리즘을 재현 못 한다”는 사람들은 프롬프트를 공개하지 않음
    실제로는 프롬프트 기술 부족일 가능성이 큼
  • LLM은 생각하는 존재가 아니라 통계적 모델임
    주변 툴이 검색과 실행을 자동화해주는 덕분에 마치 ‘생각하는 것처럼’ 보일 뿐임
    결국 이는 자동화이지 지능이 아님
  • “롤 기반 프롬프트는 이제 구식”이라며 에이전트 중심 시대를 풍자함
  • “그냥 프롬프트를 잘못 쓴 거네?”라며 농담함

• 요즘 HN의 많은 글과 댓글은 LLM이 쓴 것처럼 느껴짐
  새로움이 없고, 대부분 피상적인 일반화만 반복함

  • (풍자적으로) “그렇지, 완전히 맞는 말임”
  • “너 제대로 읽고 있긴 해?”라며 반박
  • “이제 그만하고 밖에 나가서 잔디나 만져보자”는 농담으로 마무리함

• 최근 뉴스들을 보면 AI가 아직 충분히 성숙하지 않음
  예: Microsoft의 Copilot 매출 목표 하향과
  Moltbook의 보안 문제 사례
  결국 대부분의 사람들은 AI를 신뢰하지 않음
  AI는 아이디어 탐색이나 보일러플레이트 작성엔 유용하지만, 여전히 사고력이 핵심임

  • 사고력은 인간의 본능적 생존 도구임
    AI는 인간의 사고를 대신해주는 최고의 유혹이지만, 장기적으로 사고 근육을 약화시킬 위험이 있음
    일정 기간 사용 후 다시 손으로 코딩해보면 유창성이 떨어졌음을 느낄 것임
  • 아직은 판단하기 어려움
    Copilot이 아니라 Claude가 더 나아서일 수도 있고, Moltbook의 보안 문제는 초기 서비스의 숙명일 수도 있음
    결국 AI 도입 기업과 비도입 기업의 생존율로 결과가 드러날 것임

• 나도 예전엔 “AI는 멍청한 블랙박스”라 생각했지만, 최근 6개월 사이에 관점이 완전히 바뀜
  제대로 배우면 놀라운 결과를 낼 수 있음
  지금은 AI를 증폭기로 보고, 나의 역량을 확장시키는 도구로 씀