코드의 죽음에 대한 보도는 크게 과장되었다

Reports of code's death are greatly exaggerated

요약

AI 시대에도 코드는 여전히 필수적이며, 영어 사양만으로는 복잡성을 충분히 표현할 수 없고, 추상화를 통해 복잡성을 마스터하는 것이 프로그래밍의 핵심이라고 주장합니다.

핵심 포인트

  • 'Vibe coding'은 초기에는 정확해 보이지만 기능 추가나 규모 확장 시 예기치 못한 버그가 발생하는 한계 존재
  • 인간은 7±2개 항목만 한 번에 생각할 수 있으므로 추상화를 통해 복잡성을 관리
  • 코드는 단순히 소프트웨어 산출물을 위한 것이 아니라 그 자체로 중요한 예술적 산출물

왜 중요한가

AI가 코드 작성을 자동화할 때에도 개발자가 설계와 추상화에 집중해야 하는 이유를 설명합니다.

📄 전문 번역

충분히 자세한 명세는 곧 코드다

이 글은 다음의 인상적인 만화에서 시작합니다.

여기엔 근본적인 긴장 관계가 있습니다. 영어 명세는 직관적으로는 정확해 보이지만, 실제로 구현하다 보면 그렇지 않다는 걸 깨닫게 되죠. (마지막 장면의 표정이 정말 다 말해줍니다.)

> "당신이 정확하게 만들어보기 전까진, 얼마나 모호한지 깨닫지 못할 거예요."

프로그래밍은 글쓰기와 마찬가지입니다. 계속 반복하면서 자신이 하는 일을 점점 더 정확하게 다듬어나가는 활동이거든요. (이 글도 몇 번을 고쳐 썼는지 모릅니다.)

AI가 변화를 일으킨 이유

AI는 이 과정을 획기적으로 바꿨습니다. 영어를 실행 가능한 코드로 빠르고 정확하게 변환해주니까요. 그러면 당신은 그걸 보고 반응할 수 있습니다. "버튼을 저기로 옮겨봐", "더 파란색으로 해봐" 이런 식으로 점진적으로 원하는 바를 더 정확히 정의해나갈 수 있다는 뜻입니다.

이게 바로 "바이브 코딩(vibe coding)"이라는 표현이 완벽하게 맞아떨어지는 이유입니다. 당신은 영어 수준의 막연한 감각에서 머물면서도, AI가 만들어준 산출물을 보고 반응하면서 자신의 생각을 점점 더 구체화할 수 있거든요.

하지만 문제가 있습니다

그런데 바이브 코딩은 당신의 감각을 정확한 추상화처럼 보이게 만드는 착각을 줍니다. 기능을 계속 추가하거나 규모가 커질 때까지는 실제로 정확해 보이기도 합니다.

하지만 언젠가는 균열이 생깁니다. 당신이 이해하지 못하는 하위 레벨의 추상화에서 예상 밖의 동작(버그)이 나타나면서 하루를 망쳐버리는 거죠.

Dan Shipper가 바이브 코딩으로 만든 텍스트 에디터 앱이 바이럴되었다가 서비스가 중단되었던 경험이 정확히 이겁니다. 그 과정에서 그가 깨달은 건 간단했습니다. "실시간 협업은 정말, 정말 어렵다"는 것.

명세가 명확해 보이는 이유

"실시간 협업"은 마치 완벽하게 명확한 요구사항처럼 들립니다. 우리 모두 Google Docs나 Notion을 써봤으니까요. 그럼 당연히 명확히 정의된 것처럼 느껴집니다.

10년 전, 제가 만들고 있던 제품에 협업 기능을 가진 텍스트 에디터를 추가하려 했을 때만 해도 이게 얼마나 복잡한지 몰랐습니다. 시작했을 땐 간단할 줄 알았는데, 정말 예상 밖의 악몽 같은 복잡성과 마주쳤거든요.

정확히 뭐가 어려웠나요? 솔직히 기억이 안 납니다. 그리고 이게 바로 문제입니다. 복잡성은 지루하고, 생각하기 싫고, 모든 세부사항과 엣지 케이스를 기억하기 힘들거든요.

예를 들어, Slack이 언제 사용자에게 알림을 보낼지 결정하는 과정을 나타낸 고전적인 플로우차트를 보면 얼마나 복잡한지 감을 잡을 수 있습니다.

추상화라는 도구

하지만 여기서 끝이 아닙니다. 우리는 복잡성을 다루기 위한 강력한 도구를 가지고 있거든요.

인간의 뇌에는 근본적인 한계가 있습니다. 한 번에 7개(±2개) 정도의 것만 생각할 수 있다는 거죠. 그래서 7개 이상의 것들을 생각하려면, 여러 개를 하나로 압축해야 합니다. 다행히 이 과정을 재귀적으로 무한정 반복할 수 있어서, 인간은 무한한 복잡성도 다룰 수 있게 됩니다.

이 압축 단계를 우리는 추상화라고 부릅니다.

추상화의 목적은 모호함을 만드는 게 아니라, 정확성을 유지하면서 새로운 의미 수준을 만드는 것입니다.

예를 들어, Sophie Alpert는 영리한 추상화를 통해 앞서 본 Slack의 복잡한 플로우차트를 훨씬 간단한 다이어그램으로 리팩토링했습니다. 이게 바로 프로그래밍의 가장 아름다운 부분입니다. 복잡성을 다루기 위해 점점 더 좋은 추상화를 찾아나가는 과정 말이에요.

저는 함수형 프로그래밍 개념, 특히 함수형 반응형 프로그래밍(functional reactive programming)을 좋아합니다.

네, 협업 텍스트 에디터는 근본적으로 복잡합니다. 하지만 그건 우리가 계속 더 나은 추상화를 찾아야 한다는 뜻일 뿐입니다. React나 TailwindCSS가 각 영역에서 그렇게 한 것처럼요.

머나먼 미래를 생각해봅시다

이제 1년, 2년, 5년, 10년, 심지어 100년 뒤를 상상해봅시다. AI는 엄청난 속도로 발전하고 있습니다. 마법이 없는 한, 기계 지능이 인간 지능과 구별할 수 없는 수준에 도달하는 것은 시간 문제일 뿐입니다. 우리는 이를 AGI(초지능)이라고 부릅니다.

AGI 시대에서는 모두가 바이브 코딩을 할까요? 만약 월 1,000달러에 Karpathy급 천재를 100명 고용할 수 있다면, 왜 굳이 세부사항 따위에 신경 쓸까요? 그냥 당신의 천재 군단에 맡기면 되지 않을까?

이건 정말 황당한 생각입니다. 이 기술이 없을 때나 할 수 있는 말이에요.

만약 제게 그 수준의 지능에 접근할 수 있다고 하면, 저는 그걸 더 많은 형편없는 코드를 배포하는 데 쓸 생각은 절대 없습니다. 진지하게요. 절대로요.

코드는 소프트웨어만이 아닙니다

우리가 헷갈리는 이유는 코드가 소프트웨어 생산만을 위한 것이라고 (잘못) 생각하기 때문입니다. 물론 그것도 일부긴 하지만, 코드 자체도 중심적으로 중요한 산출물입니다. 제대로 작성하면, 그건 시입니다. 저는 Stockholm Syndrome에 걸려서나 기득권이 있어서 이런 게 아닙니다. 자동차가 발명되자 말을 탄 기수가 말을 옹호하는 것처럼 그렇지 않다는 뜻입니다.

이건 글쓰기에 비유하면 훨씬 더 명확합니다. 누가 "바이브 라이팅(vibe writing)"에 대해 얘기합니까?

우리가 글쓰기에 대해 혼동하지 않는 이유는 문법적으로 올바른 문장에는 실행 가능한 코드에 있는 것처럼 신비로운 부분이 없기 때문입니다. 아무도 ChatGPT가 위대한 소설가나 기자의 일자리를 빼앗는다고 주장하지 않습니다. 우리 모두 그건 말도 안 된다는 걸 알거든요.

물론 AGI가 도래하면 얘기가 달라질 수도 있습니다. 하지만 그때는 기계도 놀라운 글을 쓸 텐데…