탈동조화의 함정: AI 슬롭이 신호를 덮어버릴 때

AI 요약

저자는 탈동조화를 각 부분만 보면 타당하지만 서로 맞지 않거나 중복되는 모델이 시스템에 쌓인 상태로 정의합니다. 이런 시스템에서는 기능을 바꾸는 데 드는 비용이 기존 모델 사이를 오가며 부작용을 막는 작업에 집중됩니다. 오래된 배관을 고장 날 때마다 새 규격으로 바꾸는 상황이 비유로 등장합니다. 부분 수리는 당장의 중단과 지출을 줄이지만, 시간이 흐르면 여러 규격과 맞춤형 연결부가 뒤섞입니다. 그 상태에서 건물을 증축하거나 압력을 높이려면 전체 배관을 파악해야 합니다.

변경이 복잡성을 키우는 방식

소프트웨어에서도 여러 패러다임과 임시 수정이 겹치면 한 부분의 변경이 다른 부분에 미치는 영향을 따져야 합니다. 두 시스템을 섞는 수준을 넘어 여러 전환이 동시에 진행되면 검토해야 할 조합이 늘어납니다. 엔지니어에게 시간 압박을 주면 필요한 분석을 줄이고 서둘러 연결하게 되고, 그 결과 다음 변경은 더 복잡해집니다. 저자는 복잡성이 시간 자체가 아니라 시스템을 바꾸는 과정에서 증가한다고 강조합니다. 변경을 멈춘 시스템은 탈동조화가 저절로 더 커지지 않지만, 잦은 변경이 복잡성을 누적시킵니다.

저자는 간단한 그래프 시뮬레이션으로 이 현상을 설명합니다. 개발자를 나타내는 행위자가 그래프 일부를 골라 기능을 구현하고 구조를 바꿉니다. 낮은 일관성(coherence)으로 움직이는 행위자는 처음에는 빠르지만, 연결 수와 패러다임 전환, 코드 탐색 경로가 늘면서 점차 느려집니다. 저자가 ‘스위트 스폿(Sweet Spot)’이라 부르는 구간에서는 몇 가지 주된 패러다임을 유지하면서도 변화에 대응합니다. 지나치게 엄격하면 개발 속도가 느려지고, 일관성에 거의 신경 쓰지 않으면 복잡성이 급격히 늘어 기능 개발이 어려워집니다. 저자는 시뮬레이션의 가중치가 임의적이며 복잡성이 실제로 반드시 이런 곡선을 따른다는 증명은 아니라고 선을 긋습니다. 단순한 지역적 결정만으로도 시간이 흐르며 변경 비용이 커지는 현상이 나타날 수 있음을 보이려는 도구라고 설명합니다.

AI 에이전트와 재귀적 자기개선

저자는 AI 에이전트가 코드를 더 많이 만들면 사람보다 일관성을 잘 지킬 수 있는지 묻습니다. 글에서 인용한 연구 결과를 근거로 코드 생산량이 늘어도 완성된 작업량은 늘지 않을 수 있고, 리뷰 시간이 길어지거나 코드 복잡성이 커질 수 있다고 주장합니다. 또 AI가 만든 커밋 가운데 품질 문제를 일으킨 사례와 아직 해결되지 않은 문제를 언급합니다. 이 수치들은 저자가 인용한 연구의 결과이며, 글은 에이전트의 생산성보다 변경 이후의 유지보수 부담을 함께 살펴야 한다는 논지를 폅니다.

글의 후반부는 AI가 데이터센터 안에서 스스로 학습 알고리즘을 개선해 빠르게 초지능에 도달한다는 시나리오를 다룹니다. 저자는 성능을 측정하기 쉬운 게임과 수학, 소프트웨어가 이런 개선의 시험장이 될 수 있다는 점을 검토합니다. 하지만 소프트웨어의 속도나 크기만 측정하면 현실의 요구에 맞는지, 추상화가 시간이 지나고 조건이 바뀌어도 잘 작동하는지는 확인하기 어렵다고 봅니다. 이미 있는 프로그램만 대상으로 삼으면 알려진 사례에 과적합할 수 있고, 새로운 프로그램을 만들어 평가하려면 현실에서 유용한지 확인하는 과정이 필요하다는 주장입니다. 수학에서도 증명 가능한 명제를 늘리는 일과 현실에서 의미 있는 문제를 찾는 일은 다르다고 덧붙입니다. 따라서 현실의 피드백 없이 소프트웨어를 계속 개선하는 AI는 개선 여부를 판별하기 어렵고, 데이터센터 안에서 진행되는 재귀적 자기개선에는 한계가 있다고 주장합니다.

저자는 에이전트가 기존 코드의 주변부 작업을 돕는 방식은 인정하면서도, 핵심 개발 과정을 전면 대체하는 데는 회의적입니다. 오픈소스가 서로 다른 시스템을 조율하며 쌓아온 일관성을 AI 주도의 단기 맞춤화가 약화시킬 수 있다고 우려합니다. 복잡성이 쌓인 뒤에도 시스템을 되돌릴 수는 있지만, 회복에 오랜 시간이 들 수 있다는 것이 글에서 말하는 ‘탈동조화 붕괴(Decoherence Collapse)’입니다.

Lobsters 반응

• @andersmurphy — 재미있게 읽었습니다. 정말 엉망이 되겠네요. 엔트로피가 엄청나게 빨라졌습니다.
• @shonfeder — 이 역학을 차근차근 풀어내고 직관적으로 이해할 만한 연결고리를 많이 제시해줘서 고맙습니다. 저는 지난 몇 년간 동료와 가까운 사람들에게 탈동조화에 관해 자주 이야기했지만, 문제가 얼마나 심각한지 전달하거나 알아차리기 어려웠습니다. 긴 설명을 이어간 덕분에 많은 도움이 됐습니다. 복잡성이 코드베이스 전체 크기에 따라 선형으로 커지는지, 아니면 변경 하나가 다음 변경의 복잡성을 키울 가능성을 높여 지수적으로 커지는지에 달렸다는 대목이 특히 그렇습니다. 프로그래밍과 우리가 다루는 대부분의 비자명한 시스템에서 후자라는 사실을 알기 위해 일화나 개인적 경험은 필요하지 않다고 생각합니다. 시스템의 상태 수가 만드는 상태 폭발, API 함수 조합의 폭발, 상속 관계의 폭발, 통합 경계와 하위 시스템의 상태 공간이 합쳐지며 생기는 폭발, 심지어 이름을 정하는 일에서조차 조합 폭발이 일어납니다. 타일 하나하나가 미로로 이루어지고 그 미로가 다시 타일로 이루어진 듯합니다. LLM이 그처럼 거대한 다차원 탐색 공간에서 그럴듯하고 유용한 결과를 만들어내는 도구가 된 건 정말 놀랍습니다. 하지만 그 결과를 결합하면 탈동조화가 생깁니다. 제 생각에는 거의 모든 곳에서 그 현상이 보입니다. 가장 흥미로운 분야는 조합 복잡성이 지수적으로 커집니다.
  • @SamRW — 소프트웨어 복잡성이 지수적으로 커진다는 건 몰랐습니다. 가능한 한 작게 유지해야 한다는 강력한 근거 같네요.
  • @maevyn — 감사합니다. 저도 그런 경험을 자주 했습니다. 개별 기업과 회사마다 시스템을 다시 구현하게 만드는 인위적인 장벽이 많아서 문제가 더 커집니다. 모든 사용 사례를 하나로 통합하는 일은 더 어렵지만, 중장기적으로 복잡성이 폭발하는 것보다 나은 선택입니다. 다음 글에서 더 다뤄보겠습니다. LLM이 거대한 탐색 공간에서 그럴듯하고 유용한 결과를 만든다는 점은 정말 놀랍습니다. 저는 그 이유가 우리가 이미 시스템 안에 많은 일관성을 쌓아왔기 때문이라고 봅니다. 시스템은 잘 정의되고 추상화도 잘 되어 있으며, 에이전트는 기존 추상화의 힘을 잘 결합합니다. 문제는 추상화 사이의 빈틈을 메우거나 새로운 추상화 층으로 나아갈 때입니다. 특히 시간이 지나며 복잡성이 쌓이면 잘 다루지 못합니다.
• @SamRW — AI가 ‘충분히 괜찮은’ 새 코드를 만드는 데 왜 어려움을 겪는지 설명하는 개념으로 탈동조화에 관심이 갑니다. 여기 게시판의 논의 방식에 맞춰 도덕적 고려는 잠시 접어두겠습니다. 하지만 LLM이 오픈소스 코드를 그대로 가져오고 원작자에게 출처를 밝히지 않은 채 자기 창작물인 것처럼 내놓는 듯한 점은 윤리적으로 우려합니다. 노동자의 권리와 기후 영향 같은 문제도 있습니다. 그 점을 제쳐두더라도 LLM은 협업이 필요한 상황에서 충분히 좋은 코드를 내놓지 못합니다. 성과 지표는 잘 달성하지만 프로젝트를 실패로 이끄는 ‘AI 슈퍼스타’를 본 사람이 이제는 많을 겁니다. 코드를 아무리 빨리 만들어도 함께 만드는 코드가 무엇이고 왜 만드는지에 대한 공동의 이해는 여전히 중요합니다. 코드를 빠르게 쓰더라도 팀원 누구도 이해하지 못해 작성자가 떠난 뒤 유지보수할 수 없다면 무슨 의미가 있나요? 사용자 요구에 맞지 않는 코드를 빠르게 써도 무슨 의미가 있나요? 제 답은 둘 다 의미가 없다는 겁니다. 사용자 요구에 맞는 소프트웨어가 가장 중요하며, 요구가 바뀔 때 수정하고 유지보수할 수 없다면 소프트웨어는 쓸모가 없습니다. 이 관점은 탈동조화 개념과 잘 맞습니다. 팀 하나보다 큰 조직에서는 문제도 더 커집니다.
• @ani — 주제와 조금 벗어나지만 글의 그림이 정말 마음에 듭니다. 저자가 그림을 어떻게 준비했는지 궁금합니다.
  • @maevyn — 안녕하세요. 대부분 AI를 사용했고, 이미지를 단순하고 정보 전달에 충실하며 SVG만 사용하도록 제한했습니다. AI 사용 정책에서 시각 자료 생성에 적용한 규칙과 제약을 설명했습니다. 정보 전달에만 쓰고 일반적인 형태로 만들며, 예전 같으면 직접 수작업으로 만들지 않았을 작업에는 쓰지 않는다는 원칙입니다. 사용 가이드에서 설명했듯 이 분야에 대한 제 입장은 계속 바뀌고 있으며 정보 전달 목적의 사용에 관해서는 토론을 열어두고 있습니다.
  • @ondreian — 이를 위한 기술을 매우 높은 수준으로 다듬으셨네요. 그림이 일관성 있고 의미도 있습니다. 관련 블로그 글을 써주시면 좋겠습니다.
• @marcecoll — 재미있게도 동료 한 명이 탈동조화를 억제하는 방법을 찾아보고 있습니다. 아이디어를 주고받으며 이 영역을 탐색 중입니다. 그 동료가 coherence라는 도구를 만들고 있습니다. 아직 탐색 단계라 내부 테스트 말고는 쓸 수 없는 상태지만, 지금까지는 꽤 잘 작동합니다.
• @chobeat — 글이 아주 좋고 분석에도 동의합니다. 다만 이것이 나쁜 일이라는 주장에는 동의하지 않을 수 있습니다. 도구와 전역적으로 일관된 소프트웨어 스택을 만들기 어렵다는 점 때문에 문제가 생기겠지만, 긍정적인 결과도 있습니다. 미로의 각 구석이 불가해해지면서 지역 차원의 자율성이 커질 수 있습니다. 엔지니어의 관점에서는 손실이지만, 비기술적인 사람도 더 큰 시스템과 일관성을 맞추지 않은 채 자기 목적에 맞는 ‘기본적으로 깨진’ 소프트웨어를 만들 수 있습니다. 여러 면에서 이는 빅테크의 힘을 약화시키고 지역 공동체의 기술적 자율성을 키울 수 있습니다. 물론 엔지니어는 이런 문제에 관심이 없겠지만, 전체 그림의 일부입니다. 엔지니어의 독점이 끝날지도 모릅니다.

원문: maevyn.codes / 번역·요약: Trawling