바벨탑에서는 공통 언어를 잃자 건설이 멈췄지만, AI 보조 엔지니어링에서는 공동의 이해가 이미 무너진 뒤에도 건설이 계속될 수 있음
즉각적인 실패가 없다는 점이 기묘하고 혼란스럽다. 탑이 무너지지 않으니 무엇을 잃었는지도 모른 채 계속 높아진다. 아직까지는

탑은 AI 이전부터 이미 기울기 시작했음. 대략 2012년 이후의 영리 소프트웨어는 비기술 일반 사용자도 알아챌 만큼 빠르게 나빠지고 있음

규모가 커진 바이브 코딩 프로젝트가 바벨탑이 되는 이유는 소통할 수 없어서가 아니라 소통할 필요가 없어지기 때문이라는 접근에 강하게 반대함
나는 Lobsters의 많은 사용자보다 코딩 AI, 특히 성능이 조금 낮은 로컬 AI에 훨씬 관대한 편이다. 하지만 원래 의미대로 사람이 코드를 전혀 읽지 않은 바이브 코딩 소프트웨어는 대부분 형편없었다. 버그투성이인 경우가 흔하고, 깔끔한 Rust 2만 줄이면 될 것을 조잡한 Go 30만 줄로 만들며, 저장된 데이터까지 손상시킨다. 때로는 단체 채팅에서 작성자의 안부를 확인해야 하는 것 아니냐는 진지한 걱정까지 나올 정도다. 1980년대 Unix GUI나 정체불명의 하드웨어 업체가 만든 1990년대 말 Windows 드라이버 수준으로 충격적인 결과물이 많았다
실질적인 예외는 아키텍처를 완전히 예측할 수 있는 Rails 같은 정형화된 CRUD 앱과 Fable로 만든 신규 프로토타입 정도다. 전자는 LLM이 학습 데이터에 기대어 어느 정도까지는 아키텍처와 리팩터링을 깊이 고민하지 않고도 답을 맞힐 수 있다. 후자는 몇 문단을 주고 질문 몇 개에 답한 뒤 한두 시간 자리를 비우면 20~50달러를 쓰고도 잘 작동하는 앱을 만들어 놓으며, 이 정도 규모에서는 Fable의 엔지니어링 판단도 꽤 좋았다
문제는 Fable이 작성한 괜찮은 코드 2,000줄을 전혀 이해하지 못한 채 돌아오게 된다는 것이다. 프로젝트가 커지면 복잡한 설계 결정을 감독하기 위해 결국 내용을 따라잡아야 한다. 나중에 깊이 생각해야 할 프로젝트라면 곧 필요해질 도메인 지식을 쌓을 수 있도록 처음부터 100% 사람이 작성하는 편이 낫다. LLM 출력을 읽지 않으면 그 결과물이 언제 엉망인지 정의상 알 수 없다

어느 부분에 반대하는지 구체적으로 밝혀야 함. 지금 내용은 인용문을 전혀 다루지 않는 것처럼 보인다

대형 소프트웨어 프로젝트가 개인의 코드 생산 속도만으로 제한된다는 말과는 반대로 봄. 엄격하고 분명한 원칙이 있어야 프로젝트에 맞는 정답이 명확해진다
팀이 시스템별 코드 소유자를 두지 않기 시작하면 개념의 경계가 흐려지고 속도가 조금씩 떨어진다. 결국 모든 것이 뒤섞여 이상한 편법 없이는 진전할 수 없게 된다. 다른 팀이 의존하는 곳에 둥근 구멍과 맞지 않는 네모난 변경 몇 개만 들어가도 시스템의 응집력이 새어나간다. 한 번에 벌어지는 일이 아니라 작은 상처가 누적되는 식이라, 나중에는 모두가 수렁에 빠지고도 이유를 알지 못한다
성숙한 바이브 코딩 코드베이스는 Microsoft Word 현상의 프로그래밍 버전이 될 것 같다. 이미지를 5픽셀 옮겼을 뿐인데 모든 것이 이해하기 어려운 방식으로 재배치되는 식이다

“자, 벽돌을 만들어 단단히 굽자”라고 했지만, 당시에는 Go to가 해로운 것으로 여겨진다는 사실을 몰랐던 모양이다

글의 취지에 더 맞춰 보자면, Babylon 외에 Kowloon Walled City도 흥미롭고 적절한 비유가 될 수 있음

“아무도 소통할 필요가 없다”는 문장에는 잠재적인 조직 기능 장애가 너무 많이 가려져 있음. 음식이나 주거 같은 기본 욕구를 말하는 게 아니므로, 어떤 목표를 달성할 때 소통이 필요 없다는 것인지 완전한 문장으로 밝혀야 한다
아마 “각자가 만족하는 해결책을 찾기 위해서는 아무도 소통할 필요가 없다”는 뜻일 것이다. 하지만 소프트웨어 개발은 거기서 끝나지 않는다. “자신이 선택한 해결책에 사업 전체를 맡기기 위해서는 아무도 소통할 필요가 없다”라고 하면 터무니없다는 데 모두 동의할 것이다
실질적으로 논의해야 할 대상은 겉보기에는 작동하는 코드와 기업이 제안된 해결책을 채택할 준비가 된 상태 사이의 모든 단계다. 이 단계들을 생략해도 된다고 보는 정도는 엔지니어 개인의 성숙도와 직장 내 엔지니어링 관행의 성숙도를 그대로 보여준다

“AI가 기존 현상을 가속한다”는 진부한 결론처럼 보이지만, 실제로는 팀의 공동 이해를 구축하도록 돕는 도구가 거의 없음. 변경 속도가 높아지면 아무도 아무것도 이해하지 못하게 되므로 상황이 더 나빠진다. 코드베이스 전체를 이해하지 않아도 된다는 글에도 공감하며, 누구든 퍼즐의 일부만 머릿속에 담을 수밖에 없다
두 측면을 함께 보면 AI가 도움을 줄 여지가 있다. 정신적 모델과 코드를 구축할 때 AI에 던진 질문이나 AI가 사고 과정을 드러내기 위해 되물은 내용을 바탕으로 Architectural Decision Records(ADR)를 만들면 좋겠다. 이를 저장소 산출물로 보관하면 코드베이스에 대화식으로 질문하는 수단이 된다. 사람들의 이해를 연결하고 코드와 더 능동적으로 상호작용하게 해주는 방법이며, 결국 문서화를 덜 귀찮게 만드는 좋은 관행이기도 하다
프로젝트가 감당할 수 있는 지속 가능한 변경 속도도 팀, 역사, 경영 방식 등에 따라 정해져 있을 것이다. AI는 이를 해결하지 못하며, 코드를 더 빨리 많이 작성한다고 도움이 되지는 않는다는 사실을 받아들여야 한다
고객 가까이에서 짧은 피드백 순환을 만드는 eXtreme Programming, 다른 엔지니어를 돕는 훌륭한 문서화, DDD 같은 역사적 방법론도 연결된다. 모두 지식 공유를 위한 절차 중심의 해법이고, 그 절차를 실제로 계속 수행해야만 목적을 달성할 수 있다는 점에서 마찰 자체가 핵심이다

새 코드베이스를 살펴보기 전에 https://deepwiki.com/ 이 생성한 AI 시스템 개요를 읽으면 꽤 도움이 됐다. 코드베이스가 왜 그렇게 만들어졌는지는 자동으로 포착하지 못하지만, 어떻게 작동하는지는 놀랄 만큼 잘 보여준다
이상적으로는 모든 프로젝트가 모든 내용을 정교한 수작업 문서로 제공해야 하지만, 대개 그럴 시간이 없으므로 deepwiki는 차선책으로 유용하다. 저장소에 ADR 같은 자료를 추가하면 deepwiki 방식의 시스템 개요도 더 잘 생성할 수 있을 것이다
AI가 생성한 개요인 만큼 결과는 달라질 수 있지만, 지금까지는 낯선 코드베이스를 나 자신이나 다른 엔지니어에게 설명하는 데 상당히 유용했다

소프트웨어의 조합 가능성은 테트리스처럼 줄이 지워져야 한다고 오래전부터 생각해 왔음. 미숙하게 에이전트를 쓰거나 경험이 적은 엔지니어는 이런 정리를 놓쳐 탑만 계속 높이는 경향이 있음
에이전트가 기존 요소를 더 나은 추상화로 반복 통합하도록 만들 수는 있지만, 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 시대에 더 쉬워진 이유는 우리가 이런 것들을 더 이상 신경 쓰지 않게 되었기 때문임