본문으로 건너뛰기
피드

생성을 멈추고, 사고를 시작하라

frontend 약 5분
vote
0
댓글
북마크

프론트엔드 개발자가 AI 코드 생성 열풍에 반박하는 글. LLM을 'spicy autocomplete' 정도로만 쓰고 있으며, 비결정적 출력·사고의 외주화·PR 리뷰 품질 저하 등의 문제를 지적함. 반LLM이 아니라 반하이프 입장.

  • 1

    LLM은 비결정적이라 기계화와 본질적으로 다름

  • 2

    AI 생성 코드는 패스트 패션처럼 겉만 그럴듯함

  • 3

    개발자가 사고를 외주화하면 아무도 생각하지 않는 상태가 됨

  • 4

    AI PR은 공유 맥락과 책임의 눈을 잃게 만듦

  • 5

    LLM 학습 데이터 오염으로 저질 코드의 악순환 발생

프론트엔드 개발자가 AI 코드 생성 열풍에 정면으로 반박하는 글. Copilot과 Claude를 "spicy autocomplete(매운맛 자동완성)" 정도로 쓰고 있지만, 복잡한 작업을 시키면 매번 엉망이 된다고 주장함. 프롬프트를 다듬는 시간에 직접 코드를 작성하는 게 더 빠르다는 것.

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

  • 산업혁명과 AI의 유사점은 인정하되, 핵심적인 차이가 있다고 지적함
  • 기계화는 동일한 결과를 반복 생산했지만, LLM 출력은 비결정적(non-deterministic)이며 내부 작동 방식이 불투명함
  • 기계화가 품질 하락의 경쟁을 초래한 것처럼, AI 생성 코드도 같은 길을 걷고 있다는 비유
  • SHEIN에서 커피 한 잔보다 싼 바지를 살 수 있게 된 것처럼, 코드도 "싸고 빠르지만 질은 엉망"인 방향으로 가고 있음
  • AI 생성 코드 = 패스트 패션: "첫눈에는 괜찮아 보이지만 오래 버티지 못하고, 자세히 보면 구멍투성이"

"LLM은 또 하나의 추상화 계층"이라는 주장에 대한 반론

  • 고수준 언어가 어셈블리를 대체한 건 맞지만, 개발자는 여전히 아키텍처적 사고를 해야 함
  • 가비지 컬렉션이나 메모리 할당을 신경 쓰지 않게 됐을 뿐, 시스템 설계와 유지보수성에 대한 판단은 사라지지 않았음
  • LLM의 가장 큰 피해는 개발자가 사고 자체를 외주화할 때 발생함
  • LLM은 시스템 아키텍처에 대해 "추론"할 수 없음. 왜냐하면 추론을 하지 않기 때문

"우리가 생각하지 않고, LLM도 생각하지 않으면, 아무도 생각하지 않는 것이다(If we're not thinking and they're not thinking, nobody is thinking)."

⚠️주의

> Horizon/Post Office 스캔들: 영국 우체국 소프트웨어의 버그로 인해 무고한 직원들이 횡령 혐의로 투옥됨. 13명이 이 사건의 직접적 결과로 스스로 목숨을 끊었음. 소프트웨어에 대한 책임과 사고의 부재가 어떤 결과를 초래하는지 보여주는 사례.

"인간 지네 인식론(Human Centipede Epistemology)"

  • 저자가 인용한 표현으로, LLM의 학습 데이터 오염 문제를 날카롭게 묘사함
  • LLM은 인간이 작성한 저질 코드로 학습됨 → 저질 코드를 출력함 → 그 출력물로 다시 학습됨
  • 접근성이 나쁘고, 성능이 떨어지고, JavaScript로 도배된 코드를 인간이 이미 양산하고 있었음
  • 인간이 충분히 좋은 코드를 작성하지 못하는 상황에서, 같은 수준의 코드를 더 빨리 생성하는 도구를 원하는 것 자체가 문제

PR 리뷰에서 잃어버리는 것들

  • 동료가 작성한 PR에는 사고의 흔적이 있음. 왜 이렇게 작성했는지에 대한 맥락이 존재함
  • AI가 PR을 생성하면, 리뷰어 한 명에게만 책임이 집중됨. 눈이 네 개에서 두 개로 줄어드는 셈
  • PR 리뷰는 버그 검출만이 아님. 코드와 변경사항에 대한 이해를 팀 내에서 공유하는 과정
  • Slack에서 Claude에게 말 걸어서 PR을 자동 생성하고, 같은 사람이 승인까지 하는 회사들이 있다는 것은 심각한 문제

저자의 입장: 반(反)LLM이 아니라 반(反)하이프

  • "인공지능"이라는 브랜딩 자체에 반대함. 지능적이지 않기 때문. 본질은 기계학습이며, "생성형 AI"는 기대가 과도하게 부풀려진 마르코프 체인일 뿐
  • 프로토타입이나 와이어프레임 생성에 AI를 쓰는 것은 합리적이라고 인정함
  • 문제는 "바이브 코딩"으로 프로덕션급 소프트웨어를 만들 수 있다고 착각하는 것
  • 에이전트를 쓸 때의 원칙: "신뢰하지 않는 외부 기여자처럼 취급하라. 이미 할 줄 아는 작업에만 사용하라"

"나는 계속 매운맛 자동완성(spicy autocomplete)을 쓸 것이다. 하지만 사고를 외주화하지는 않겠다. 생성을 멈추고, 이해를 시작하라(Stop generating, start understanding)."


프롬프트 엔지니어링에 시간을 쏟느니 직접 코드를 작성하겠다는 현직 프론트엔드 개발자의 솔직한 입장문. AI 도구 자체를 부정하는 것이 아니라, 사고 없는 코드 생성의 위험성과 "인공지능"이라는 과대 포장에 경종을 울리는 글임.

AI 도구 자체가 아니라 '사고 없는 코드 생성'이 위험하다는 현직 개발자의 경고. 프로토타입용으로는 인정하되, 프로덕션 코드에서의 무분별한 사용과 '인공지능' 브랜딩의 과대 포장을 비판함.

댓글

댓글

댓글을 불러오는 중...

frontend

타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다

마이크로소프트가 타입스크립트 7.0을 출시하면서 기존 자바스크립트 기반 구현을 Go로 네이티브 포팅했다. 전체 빌드는 평균 8~12배 빨라졌고, VS코드 빌드는 125.7초에서 10.6초로 줄었으며, 슬랙은 CI 타입 검사 시간을 7.5분에서 1.25분으로 낮췄다.

frontend

타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐

마이크로소프트가 고(Go)로 네이티브 포팅한 타입스크립트 7을 공개했다. 전체 빌드는 보통 8~12배 빨라지고, VS 코드 코드베이스에서는 125.7초가 10.6초로 줄었으며, 편집기 첫 오류 표시도 17.5초에서 1.3초 미만으로 내려갔다.

frontend

“98% 지원”이 생각보다 별로 안 넉넉한 이유

브라우저 기능 지원률 98%는 얼핏 높아 보이지만, 실제 서비스에서는 2%의 사용자를 깨진 화면 앞에 세우는 숫자일 수 있다는 글이다. 특히 일반 통계와 내 서비스 방문자 분포는 다를 수 있고, 실제 사례로 어떤 사이트는 최신 중첩 CSS 기능 지원 브라우저가 방문자의 약 70%뿐이었다.

frontend

메타, AI가 읽고 쓰는 디자인 시스템 ‘Astryx’ 오픈소스로 공개

메타가 내부 디자인 시스템 Astryx를 오픈소스로 공개했다. React와 StyleX 기반의 150개 이상 접근성 지원 컴포넌트, 디자인 토큰, 테마, 템플릿, CLI를 제공하며, 특히 AI 에이전트가 컴포넌트 구조를 이해하고 UI를 생성·수정할 수 있도록 MCP 서버까지 포함한 점이 핵심이다.

frontend

shadcn/ui, 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 변경

shadcn/ui가 새 프로젝트의 기본 컴포넌트 라이브러리를 Radix가 아니라 Base UI로 바꿨어. Radix 지원은 계속되지만, Base UI가 안정화됐고 주간 다운로드 600만 이상, shadcn/create 신규 프로젝트 선택 비율 2대1이라는 이유로 기본값을 바꾼 거야. 동시에 채팅 UI용 MessageScroller와 관련 컴포넌트, headless 패키지인 @shadcn/react도 공개됐어.