코드의 죽음은 과장되었다
(stevekrouse.com)도입 — 영어 스펙의 착각
- "충분히 상세한 명세는 코드다"라는 글에서 영감을 받아 시작. 영어 명세는 직관적으로 정밀해 보이지만, 실제로 구현하려 하면 모호함이 드러남
- "모든 것은 정밀하게 만들려 하기 전까지는 모호하다" — 버트런드 러셀
- 프로그래밍은 글쓰기처럼, 하면서 점점 날카롭게 다듬는 반복 활동 (이 에세이도 수많은 초안을 거침)
바이브 코딩 — 왜 작동하고, 왜 위험한가
- AI가 영어→실행 코드 변환을 점점 빠르고 잘 해주기 때문에, 영어 수준의 "느낌(vibe)"으로 코드를 만들 수 있게 됨
- AI가 만든 결과물에 반응하면서 — "버튼 저기로 옮겨줘, 더 파랗게" — 점점 정밀해지는 과정
- "바이브 코딩"이라는 표현이 완벽한 이유: 영어 수준의 바이브를 유지하면서 AI 산출물로 사고를 날카롭게 하는 것
- 핵심 문제: 바이브가 정밀한 추상화라는 착각을 준다. 기능이 늘거나 스케일이 커지면 추상화가 깨지면서(leaky abstraction) 예상 못한 버그가 하루를 통째로 망침
실제 사례 — Dan Shipper의 바이브코딩 앱
- Dan Shipper가 바이브코딩으로 만든 텍스트 에디터 앱이 바이럴 → 서버 다운
- 원인: "실시간 협업(live collaboration)"이 직관적으로 간단해 보이지만, 실제로는 악몽 수준의 복잡성
- 우리 모두 Google Docs, Notion을 써봤기 때문에 "실시간 협업"이 정밀하게 스펙된 것처럼 느낌. 왜 그렇지 않은지를 사전에 파악하기가 극히 어려움
- 저자 본인도 10년 전 협업 에디터를 만들다가 예상 못한 복잡성의 악몽을 경험. 뭐가 어려웠는지? 기억도 안 남! 그게 문제의 일부 — 복잡성은 지루하고, 생각하기 싫고, 디테일과 엣지케이스를 기억하기 어려움
- 예시: Slack이 알림을 보낼지 결정하는 클래식 플로우차트 — 이 정도의 복잡성이 "알림 보내기" 같은 단순한 말 뒤에 숨어있음
추상화 — 복잡성을 다루는 유일한 도구
- 인간 뇌의 근본적 한계: 한 번에 7±2개만 처리 가능
- 7개 이상을 다루는 유일한 방법: 여러 개를 하나로 압축(compress). 이걸 재귀적으로 무한히 반복할 수 있어서 인간은 무한한 복잡성을 다룰 수 있음. 이 압축 단계가 바로 추상화(abstraction)
- "추상화의 목적은 모호해지는 것이 아니라, 절대적으로 정밀해질 수 있는 새로운 의미 수준을 만드는 것이다" — 다익스트라
- Sophie Alpert가 Slack의 악명 높은 알림 플로우차트를 영리한 추상화로 훨씬 단순하게 리팩토링한 사례
- 프로그래밍의 가장 좋은 부분: 점점 더 좋은 추상화를 만들어서 복잡성을 정복하는 것. ReactJS나 TailwindCSS가 각 영역에서 해낸 것처럼
- 협업 텍스트 에디터가 근본적으로 복잡하다는 건, 그저 더 나은 추상화를 계속 찾아야 한다는 뜻
AGI — 그래도 좋은 코드는 사라지지 않는다
- 1년, 2년, 5년, 10년, 100년 후를 그려보면: AI가 점점 좋아지고/빨라지고/싸지고, 언젠가 기계 지능이 인간과 구분 불가능해지는 시점(AGI)이 옴
- AGI 세계 = 바이브 세계처럼 보일 수 있음. 100명의 카파시급 천재를 $1000/월에 쓸 수 있다면, 왜 귀찮은 디테일을 신경 쓰겠나?
- "이건 진짜 웃긴 소리다." 이런 생각은 기술이 도착하기 전, 추상적으로만 가능한 생각
- 그 수준의 지능에 접근할 수 있다면, 더 많은 슬롭을 찍어내는 데 쓸 사람은 0%. 당연히 아님
- 우리가 혼동하는 이유: 코드가 소프트웨어 생산만을 위한 것이라고 (잘못) 생각하기 때문. 코드 자체도 핵심 산출물임. 잘 만들면 시(poetry)
- "아무도 '바이브 라이팅'은 얘기 안 하잖아?" — 글쓰기에서 ChatGPT가 위대한 소설가나 저널리스트를 대체한다고 아무도 안 믿음. 코드도 마찬가지인데, 실행되는 코드의 "신비함" 때문에 착각이 생기는 것
- AI는 (점점 덜) 구린 코드를 만듦. 우리 모두 이걸 앎. AI를 쓰는 건 나쁜 코드에도 "불구하고" 쓰는 것이지, "때문에" 쓰는 게 아님
- Simon Willison 인용: "AI는 더 나은 코드를 만드는 데 도움을 줘야 한다"
- AGI가 오면 가장 먼저 할 일: 가장 어려운 추상화 문제를 풀는 것. 더 나은 추상화를 만들어서 복잡성을 더 잘 이해하고 정복하는 것
- AI가 똑똑해질수록 좋은 코드의 필요성이 사라진다고? 그건 ChatGPT로 더 많은 슬롭을 찍겠다는 것과 같은 소리
- 실제 사례: Opus 4.6이 Val Town의 풀스택 React 프레임워크(vtrr)를 만드는 데 미해결 문제를 원샷으로 해결. 50줄짜리 싱글파일 풀스택 앱 데모가 그 결과
결론 — 코드는 이제 시작이다
- 사회의 99%가 "코드는 죽었다"에 동의한 것 같음. 어제도 팟캐스터 Sam Harris가 "모두가 코딩은 죽었다고 동의한다, 아무도 코딩을 배울 필요 없다"고 자신 있게 말하는 걸 들음
- "이건 슬프다. 인쇄기 발명에 '스토리텔링은 죽었다'고 말하는 것과 같다. 바보들아, 코드는 이제 시작이다. AI는 코딩에 엄청난 축복이 될 것이다."
- 마무리 인용들:
- "형식 기호를 쓰는 의무를 부담으로 볼 게 아니라, 쓸 수 있다는 것을 특권으로 봐야 한다. 덕분에 학생들이 예전엔 천재만 할 수 있던 일을 할 수 있게 됐다" — 다익스트라
- "모국어를 '자연스럽게' 쓸 수 있다는 건, 넌센스가 명백하지 않은 문장을 쉽게 만들 수 있다는 것에 불과하다" — 다익스트라, "자연어 프로그래밍의 어리석음에 대하여"
- "소프트웨어 설계에는 두 가지 방법이 있다: 하나는 너무 단순해서 결함이 명백히 없게 만드는 것, 다른 하나는 너무 복잡해서 명백한 결함이 없게 만드는 것" — 토니 호어
- "대수 기호로 작은 공간에 압축된 의미의 양이, 우리가 그것을 통해 수행하는 추론을 용이하게 한다" — 찰스 배비지
협업 편집 얘기까지 가기 전에, 혼자 쓰는 에디터 하나를 제대로 구현하는 것만 해도 커서 처리, undo/redo 스택, IME 입력 등 예상치 못한 복잡함이 넘칩니다. 글에서 지적한 것처럼 "직관적으로 정밀하게 느껴지는 명세"의 함정이 에디터만큼 잘 드러나는 소프트웨어도 없죠. 결국 쉬워 보이는 건 쉬운 게 아니라, 그 복잡함을 잘 추상화해서 숨긴 겁니다.
다른 검증 방법으로 대체될 수 있는지를 봐야할 거 같습니다. 프론트에 가까울수록, 브라우저 동작으로 E2E만 해도 잘 작동한다고 검증할 수 있을 겁니다. 하지만 백, 그리고 인프라에 가까운 코드일수록 코드 리뷰가 필수적일 거 같습니다. 그렇치 않으면 눈에 보이지 않는 트렌젝션 열리고 닫히거나 api 콜 날라가는 등 사이드 이펙트를 검증하기 어려울 테니까요.