본문으로 건너뛰기
피드

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

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

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

HTML을 캔버스 안에 넣는 데모 모음이 등장함

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.