탑은 계속 높아진다

• 바이브 코딩된 소프트웨어가 무작위적이고 예상 밖으로 변하는 모습은 공통 언어를 잃어 공사가 멈춘 바벨탑과 닮았지만, AI 시대에는 이해가 무너진 뒤에도 건설이 계속된다는 차이가 있음
• 대규모 소프트웨어의 한계는 개인의 코드 생산 속도뿐 아니라 개념, 경계, 불변 조건, 소유권, 설계 이유에 관한 공유된 이해를 얼마나 잘 조율하는지에 달려 있음
• 코드 탐색과 질문, 리뷰, 팀 간 협의에서 발생하던 마찰은 낭비인 동시에 서로의 이해를 동기화하고 시스템에 대한 합의를 확인하는 과정이었음
• 에이전트는 OAuth 추가, 캐싱, 데이터베이스 재구축 같은 작업을 대화 없이 병렬로 수행하며, 각 변경이 합리적이고 테스트를 통과하더라도 인간의 공통 모델은 약해질 수 있음
• AI 보조 엔지니어링에서는 에이전트가 각 영역을 해석하고 수정해 즉각적인 실패 없이 공사를 이어가므로, 인간이 함께 시스템을 추론하던 아키텍처 언어의 상실을 알아차리기 어려움

---

바벨탑의 힘은 기술보다 조율에 있었음

• 일부 바이브 코딩 소프트웨어가 다소 무작위적이고 예상하지 못한 방식으로 변하는 모습은 Bruegel의 The Tower of Babel을 떠올리게 함
• 바벨탑 이야기는 흔히 오만과 야망, 사람들이 서로 다른 언어를 쓰게 된 이유로 해석되지만, 동시에 기술 발전을 가능하게 하는 단결을 보여줌
• 창세기 11장 3~6절(KJV)에서 사람들은 돌 대신 구운 벽돌, 모르타르 대신 역청을 사용하는 기술 향상을 이루고 하늘에 닿는 도시와 탑을 건설하려 함
• 신이 문제로 본 것은 벽돌이나 제조 지식이 아니라, 사람들이 하나이며 하나의 언어를 공유해 아무것도 제약받지 않는다는 점이었음
• 공동의 언어로 각자의 작업을 결합하면 누구도 혼자 만들 수 없는 것을 건설할 수 있음
• 벽돌이나 제조법이 아니라 서로를 이해하는 능력이 사라지자 조율이 불가능해졌고, 건설도 중단됨

AI 에이전트가 마찰을 없앤 뒤에도 계속 올라가는 탑

• AI 보조 프로그래밍은 개인에게 더 강력한 도구를 제공하며, 에이전트를 사용하는 개발자는 코드베이스를 훨씬 큰 폭으로 변경할 수 있음
• 그러나 대규모 프로젝트의 한계는 개인이 코드를 생산하는 속도만이 아니라, 변경 대상 시스템에 대한 이해를 사람들이 얼마나 잘 조율하는지에도 좌우됨
• 소프트웨어 프로젝트의 공통 언어는 영어 또는 Python 자체가 아니라 다음 요소에 관한 공동의 이해임
  • 각 개념이 무엇을 의미하는지
  • 시스템 경계가 어디에 있는지
  • 어떤 불변 조건이 중요한지
  • 누가 무엇을 소유하는지
  • 시스템이 현재 구조를 갖게 된 이유가 무엇인지
• 이러한 이해는 한곳에 완전히 기록되지 않으며, 문서와 코드뿐 아니라 코드 리뷰, 대화, 논쟁, 다른 사람에게 변경을 설명한 경험에도 축적됨
• 에이전트 이전에는 다른 사람의 스토리지 계층을 변경하려면 코드를 읽고 질문하며, 의존 서비스를 운영하는 다른 팀과 협의해야 하는 경우가 많았음
  • 이 과정에는 낭비도 있었지만, 한 사람의 이해가 다른 사람에게 전달되고 양쪽이 시스템 작동 방식에 여전히 합의하는지 확인하는 기능도 있었음
  • 이런 마찰이 사람들의 이해를 동기화했음
• 에이전트는 이러한 마찰을 크게 줄여 여러 사람이 서로 대화하지 않고도 각기 다른 변경을 요청할 수 있게 함
  • 한 사람은 OAuth를 추가하고, 다른 사람은 캐싱을 넣으며, 또 다른 사람은 데이터베이스를 처음부터 재구축하고 UI를 분홍색으로 만들 수 있음
  • 각각의 변경은 독립적으로 합리적일 수 있으며, 코드가 컴파일되고 테스트를 통과하며 필요할 때 설명까지 생성될 수 있음
  • 누구도 다른 사람과 대화하거나, 과거라면 변경 과정에서 배웠을 공유 모델의 일부를 습득하지 않아도 됨
• 에이전트는 고통을 느끼지 않고 인간만 고통을 느끼며, 이전에는 다른 사람의 도움이 필요했던 시스템 영역과 코드베이스까지 변경할 수 있게 함
• 규모가 커진 바이브 코딩 프로젝트는 소통할 수 없어서가 아니라 소통할 필요가 없어져서 바벨탑 같은 코드베이스가 됨
  • 각 개발자에게는 탑의 특정 영역을 설명하고 원하는 국소적 변경을 수행하는 지치지 않는 번역기가 있음
  • 변경은 계속 반영되지만, 인간들이 함께 시스템을 추론하게 해주던 아키텍처 언어는 사라질 수 있음
• 성경의 바벨탑에서는 공통 언어의 상실이 공사를 멈췄지만, AI 보조 엔지니어링에서는 공유된 이해가 붕괴한 뒤에도 건설이 계속될 수 있음
• 탑이 무너지거나 즉각적인 실패가 발생하지 않기 때문에 무엇을 잃었는지 알아차리기 어렵고, 탑은 계속 높아짐

[GN⁺]

Hacker News 의견들

• 소프트웨어의 조합 가능성은 테트리스처럼 줄이 지워져야 한다고 오래전부터 생각해 왔음. 미숙하게 에이전트를 쓰거나 경험이 적은 엔지니어는 이런 정리를 놓쳐 탑만 계속 높이는 경향이 있음
  에이전트가 기존 요소를 더 나은 추상화로 반복 통합하도록 만들 수는 있지만, Fable이나 5.6 Sol조차 소프트웨어의 미묘한 진화를 예측하는 고차원적 아키텍처 감각은 아직 사람보다 크게 뒤처짐. 현재 시스템은 사람이 다루는 고품질의 희소하고 확대·축소 가능한 세계 모델을 충분히 유지하지 못하는 듯하지만, 이제 차이가 이런 미묘한 수준까지 좁혀졌다는 사실 자체는 희망적임

  • 증명할 수는 없지만, 미래 변경을 고려한 추상화에 필요한 논리와 직관은 예측 토큰의 연속만으로 구현할 수 없다고 강하게 믿음. 측정할 수 없는 무언가가 빠져 있음
  • 과거에는 인간 정신의 역량이 프로그램 복잡도의 상한이었지만 바이브 코딩은 그 장벽을 돌파할 수 있음. 문제가 실제로 그만큼 복잡해서가 아니라, 개발 과정이 간결한 추상화를 향해 수렴하지 않기 때문임
    이는 Brooks가 《The Mythical Man-Month》에서 다룬 확장 문제의 AI 버전으로, 규모가 커질수록 조합 폭발이 악화되고 프로젝트 곳곳에 사실상 같은 기능을 구현한 코드가 중복해서 생김. AI 기반 코딩이 간결성을 추구하도록 만드는 방법이 필요함
  • 사람의 컨텍스트 창은 오늘날 LLM보다 훨씬 작을 수 있음. 이 제약은 작업을 머릿속에 담을 수 있도록 모듈화하고 추상화하게 만드는 장점인데, 훨씬 많은 내용을 한꺼번에 담는 LLM에는 같은 유인이 없어 에이전트가 정리되지 않은 스파게티 코드를 만들게 됨
  • 결국 시간문제임. gpt2나 llama2는 오늘날 모델과 비교하면 충격적일 만큼 형편없고 당시에도 사실상 쓸모없었지만 우리는 감탄했음
    한때 열광했던 GPT3.5와 gpt4도 이제 qwen27b나 gemma31b에 크게 밀림. 충분한 시간과 적절한 강화학습(RL) 이 주어지면 모델도 훌륭한 소프트웨어 시스템 모델을 머릿속에 구축하게 될 것임
  • LLM이 짧은 시간 범위의 과제를 풀도록 강화학습된 결과 아닐까? 테스트 통과 과제와 달리 수년에 걸친 노력, 깔끔한 아키텍처, 좋은 감각은 벤치마크로 최대화하기가 쉽지 않음

• 이 글의 핵심 논지는 Lisp Curse와 Bipolar Lisp Programmer를 떠올리게 함. Lisp는 개인이 원하는 것을 너무 쉽게 만들 수 있어서 프로그래머들이 협력해 범용적이고 복잡한 결과물을 구축할 동기가 약해지고, 상당한 노력이 필요한 언어보다 공개 소프트웨어 생태계가 빈약해진다는 논리였음
  Armin도 AI 코딩에 관해 매우 비슷한 논지를 펼치는 듯함: Lisp Curse, Bipolar Lisp Programmer

  • 어셈블리 프로그래머들도 같은 논리를 폈음. 소프트웨어 공학이 패러다임 전환을 겪을 때마다 되풀이되는 통념이며, 전환을 남들보다 힘들어하는 사람도 있음
  • 정말 같은 논리인지는 의문임. 이제는 함께 모여 협업할 필요 없이 에이전트 무리만 동원하면 상상하는 어떤 복잡한 소프트웨어든 만들 수 있다고 보는 사람도 충분히 많음
  • 오히려 TypeScript와 Rust가 시장을 휩쓸지만 않았다면 지금은 Lisp용 LLM 조종자가 되기에 좋은 시기였을 것임. 요즘 에이전트는 거의 환각 없이 대부분을 설명할 수 있어, 이해하려는 의지만 있다면 이해의 장벽은 사실상 사라지며 이것이 글의 핵심이기도 함
  • 다른 언어가 같은 결과를 내기 위해 “훨씬 많은 노력”을 요구한다는 전제는 분명하지 않음. 많은 비Lisp 개발자는 문법을 중시하지만 Lisp 개발자는 그렇지 않고, Lisp로 사고가 확장되는 체험을 한 뒤에도 Lisp를 선호하지 않는 이들이 많음
    두 집단 사이에는 서로 다른 인지 처리 방식이 있을지도 모름. Lisp가 다른 언어만큼 생산적이려면 동형성(homoiconicity)을 적극 활용해야 하는데, 그 결과 진지한 Lisp 프로그램은 한두 명만 이해하는 도메인 특화 언어(DSL) 들의 집합이 되기 쉬움

• 대규모 소프트웨어 프로젝트의 한계는 개인이 코드를 얼마나 빨리 생산하느냐가 아니라, 시스템을 변경하는 사람들이 그 시스템에 대한 공통 이해를 얼마나 잘 조율하느냐에 있음. 2022년 11월 30일 이후 모든 것이 더 복잡해졌다는 말이 정확함

  • 소프트웨어는 계층 위에 계층을 쌓으며 지나치게 복잡해졌는데, 이를 다루려고 훨씬 더 많은 복잡성을 만드는 도구를 쓰고 있음. 1990년대와 2000년대 초에는 정규 교육 없이도 Visual Basic이나 PHP로 강력한 애플리케이션을 만들 수 있었지만, 오늘날 웹이나 데스크톱 개발은 압도적으로 복잡하고 React조차 제대로 쓰려면 알아야 할 것이 너무 많음
    여기에 AI를 도입하는 것은 기존 복잡성 위에 또 다른 복잡성을 얹는 실수에 가까움. 좋게 봐도 막대한 하드웨어 낭비이고, 나쁘게는 에이전트가 버그를 고치는 만큼 새 버그를 만들고 취약한 쓰레기 소프트웨어가 늘어나는 동시에 사람들이 기술을 배우지 않아 인류 전체의 역량이 약해질 수 있음. 소프트웨어가 본질적으로 이토록 복잡할 필요는 없으며, 해결하려면 장인정신을 중시해야 함
  • 시스템을 바꾸기 전에 이해해야 한다는 사실은 새롭지 않음. Peter Naur의 Programming as Theory Building이 이미 1980년대에 나왔고, 이를 읽지 않았더라도 숙련된 개발자 사이에서는 시스템 이해가 필수라는 것이 상식이었음
  • 모든 것이 더 복잡해진 것만은 아님. 주요 데이터베이스에는 실용적인 고가용성 도구가 포함되고, 마이크로서비스는 퇴조하며, NoSQL 대신 구조화된 데이터베이스가 돌아오고 있음
    HTML과 사전 렌더링도 HTMx, LiveView와 함께 복귀했고 CSS도 과거의 기괴한 우회법에서 벗어남. IE6에서 웹 페이지를 디버깅하던 방법을 젊은 동료에게 설명하면 격세지감이 듦. 일부는 복잡해졌지만 다른 일부는 충분히 성숙해져 더 단순해졌음
  • “2022년 11월 30일 이후”가 아니라 기원전 2022년 이후 모든 것이 더 복잡해졌다고 해야 함. 복잡성 증가는 곧 인류 문명사임
    기원전 2만 년의 사람은 먹을 것을 찾고 추위와 포식자를 피했지만, 기원전 5천 년의 사람은 농사를 짓고 비와 질병을 걱정하며 공동체와 토지를 관리하는 체계를 만들었음. 오늘날 대부분은 식량을 직접 재배하지 않고 거대 사회의 복잡성을 관리함. 1970~80년대 개발자가 보면 LLM 이전의 소프트웨어조차 엄청나게 복잡하며, 이제는 거의 아무도 추상화 계층 없이 하드웨어에 직접 코딩하지 않음. 암호화도 라이브러리가 복잡성을 감추고 “직접 구현하지 말라”고 가르침. 이제 핵심 질문은 LLM이 변경 대상 시스템에 대한 이해를 얼마나 빨리 조율할 수 있는가임

• 소프트웨어 프로젝트의 공유 언어는 영어도 Python도 아니라 개념의 의미, 경계, 불변 조건, 소유권, 시스템이 현재 형태가 된 이유에 관한 공통 이해임. Christopher Alexander의 Pattern Language가 바로 이 문제를 다루며, 각 도메인에 맞는 패턴 언어를 만들라고 권장한 것이 유명한 GoF Design Patterns로 이어졌음
  프로젝트마다 비즈니스·제품·기술 도메인용 패턴 언어 세 개를 AI가 유지하게 하는 기능을 실험 중인데 매우 잘 작동함. 계획할 때 이를 참조하고 구현과 검토 중에 정리하도록 하니, 100% AI로 코딩한 프로젝트도 체계적이고 도메인 간 정렬이 잘 되며 다루기 쉬워졌음

  • 실제 예시가 궁금함. 코드의 성숙 과정이 도시의 자연스러운 성장과 비슷하다는 이야기는 여러 번 들었지만 구체적인 결과는 본 적이 없음
  • 공개된 GitHub 예제가 있는지 궁금함

• 바벨탑에서는 공통 언어를 잃자 건설이 중단되지만, AI 보조 개발에서는 공유된 이해가 무너진 뒤에도 건설이 계속됨. 저자가 좋고 나쁨을 명시하지 않았지만 분명히 나쁜 일로 봄
  토마토가 과일임을 아는 것이 지능이고 과일 샐러드에 넣지 않는 것이 지혜라면, AI는 지혜가 전혀 없는 지능의 궁극적 형태이자 사실상 지능의 환상에 가까움. AI가 무엇을 하는지 이해할 사람이 아무도 없다면 멈추고, 우리가 만드는 것을 통제할 지혜가 부족함을 인정해야 함

  • 저자가 설교하는 대신 이미지 자체가 의미를 전달하게 둔 점이 좋음. 역사에는 똑같은 반복이 없지만 늘 운율은 맞음
  • “토마토가 과일임을 아는 것이 지능” 같은 유치한 상투어는 오도할 목적이 아니라면 피하는 편이 나음. 분류와 의존 관계 이해만 해도 충분히 어려운 문제이며, 슈퍼마켓이나 Nix v. Hedden의 과세 기준에서는 토마토가 채소임

• 나 역시 바벨과 Bruegel의 그림을 떠올리지만 훨씬 덜 낙관적으로 봄. 근시안적인 작은 에이전트들이 알 수 없을 만큼 거대한 전체의 각자 영역을 개발하며, 한쪽에는 흉벽 50개가 있고 다른 쪽에는 기묘한 돌출 탑이 있으며 이유도 모른 채 안뜰 위에는 어도비 지붕, 그 옆 계단참에는 초가지붕이 붙은 탑을 세우는 모습임
  개별 설계 수준에서는 타당하지만 전체 사업을 통합하는 여러 층위의 정책과 판단이 없어 설계의 거대한 괴물이 됨. 충분히 큰 조직에서 공통 언어를 만들고 유지하려면 규율이 필요하다는 사실은 성공한 기업과 군대의 독특한 용어에서도 드러남. “Gastown Mayors”와 그 아래의 “polecats”, 더 아래의 골렘까지 같은 언어를 쓴다고 생각하지만, 모든 것이 완성된 뒤에야 왕좌에서 완벽히 전달했다고 믿었던 이해가 실제로는 공유되지 않았음을 깨닫게 될 것임

• Anakin: “에이전트를 쓰는 개발자는 코드베이스를 바꾸는 능력이 극적으로 커질 거야”
  Padmé: “더 나은 방향으로, 맞지?”
  Anakin: 침묵
  Padmé: “더 나은 방향으로, 맞지?”

• 바이브 코딩이 생성된 코드를 읽지 말라고 하는 이유는 Python 파일 속에 도사리는 공포를 한 번 보면 잊을 수 없기 때문인 듯함. 넓은 의미에서는 요청한 대로 작동하지만, 목표를 달성하는 방법을 선택할 때마다 일관성 없는 결정을 내림
  일부 사용자 입력에만 이상한 검증을 적용하고, 이유 없이 세 단계에서 데이터를 반복 정렬하거나 소문자로 바꾸며, 입력 CSV의 첫 행에 있는 열 이름까지 모두 문자열로 하드코딩함. 절반은 데이터 클래스를 받는 전역 함수를 만들고 나머지는 클래스로 구현하는 식임. 언젠가 직접 갱신하고 유지보수해야 한다고 생각하면 이를 고치지 않기 어렵지만, 그렇게 수정하다 보면 절약한 시간 상당 부분이 사라짐

• 에이전트 기반 프로그래밍은 실제 프로그래밍보다 관리 업무에 훨씬 가까움. 관리자는 개별 기여자가 하는 일을 높은 수준에서만 파악하며, 모든 세부를 이해할 시간·인지 여력·역량이 없는 경우도 많음
  더 많은 소프트웨어가 에이전트로 작성될수록 소프트웨어 엔지니어의 역할은 기술직보다 관리직에 가까워질 것임

  • 프로그래머도 마찬가지임. 대부분의 개별 기여자는 자신이 작업하는 계층 아래에서 무슨 일이 일어나는지 모르며, 라이브러리·프레임워크·원격 API·시스템 호출의 내부 구현까지 파악하지 못함
    모든 것을 이해할 시간과 여력이 없으므로 추상화된 자기 계층에서 필요한 작업을 수행할 뿐임
  • 하루 종일 주니어 개발자의 코드를 검토하는 느낌이라 거의 쓰지 않으며, 주로 내가 놓친 부분을 찾는 용도로만 사용함

• 과거에는 대규모 리팩터링에 큰 노력이 들어가므로 충분한 이유가 필요했음. 이제는 프롬프트가 조금만 모호하고 결과를 제대로 검토하지 않으면 에이전트가 코드 절반을 다시 쓸 수 있어, 프로그램의 영혼이 매일 크게 바뀔 수 있음. 훌륭한 일이면서 동시에 전혀 그렇지 않기도 함

  • 대규모 리팩터링의 가장 큰 장벽은 원래 작업량이 아니라 버그 위험 최소화, 기능 보존, 기존 생태계와의 호환성 보장이었음. AI 시대에 더 쉬워진 이유는 우리가 이런 것들을 더 이상 신경 쓰지 않게 되었기 때문임