디코히어런스 함정: AI의 잡음이 끝없는 노이즈 속에서 신호를 덮을 때

요약

이 에세이는 **디코히어런스(decoherence)**라는 개념을 소개합니다. 이는 시스템 내에 국소적으로는 유효하지만 서로 양립할 수 없거나 중복되는 모델들이 축적되어, 변경 비용이 그 모델들 간의 번역과 의도치 않은 부작용 방지에 의해 지배되는 현상을 말합니다.

다시 말해, 끝없는 노이즈 속에서 잡음(slop)이 신호를 덮어버리는 상황입니다.

디코히어런스는 시스템의 변화율에 비례하여 증가하며, 시스템이 디코히어런스할수록 더 빠르게 증가하여 통제 불가능한 기하급수적 성장을 초래합니다. 이는 새로운 현상은 아니며, 인류는 항상 적은 것으로 더 많은 것을 하도록 신중하게 방법을 찾아내고, 이질적인 패턴과 모델들을 응집력 있는 전체로 통합함으로써 이에 대응해 왔습니다. 하지만 현재 AI의 광범위한 사용은 지속 불가능한 속도로 이를 만들어내고 있습니다.

좋은 소식은 이것이 통제 불능의 재귀적 자기 개선(runaway recursive self-improvement), 즉 누구나 반응하기 전에 포물선처럼 급증하는 지능 폭발을 배제한다는 것입니다. 디코히어런스는 AI가 거품 속에서 개선되는 것을 막을 뿐만 아니라, 외부에서도 개선할 수 있는 속도를 제한하기 때문입니다. 나쁜 소식은 우리가 다른 종류의 재앙, 즉 **디코히어런스 붕괴(Decoherence Collapse)**를 향해 돌진하고 있다는 것입니다.

작은 오피스 타워 같은 건물을 상상해 봅시다. 이 건물이 지어졌을 때 사용했던 파이프는 시간이 지나면 성능이 저하되어 결국 교체해야 하는 종류였습니다. 이것은 표준적인 인프라 부채(infrastructural debt), 즉 기본적인 마모와 손상을 의미합니다.

그런 다음, 파이프를 교체할 시기가 왔다고 가정해 봅시다. 이때 새로운 표준으로 바꿔야 할 수도 있습니다. 이는 새로운 건축 법규 요건 때문일 수도 있고, 오래된 파이프가 더 이상 생산되지 않기 때문일 수도 있으며, 아니면 새 파이프가 훨씬 좋고 유지 관리가 쉬워서일 수도 있습니다. 이것은 시간의 흐름에 따른 기술적 진보로 인해 업그레이드하고 전환해야 하는 표준적인 **기술 발전 부채(technical advancement debt)**입니다.

세 번째 부채는 오래된 파이프를 새로운 파이프로 전환하는 방식에 따라 발생할 수 있습니다. 다음 옵션들을 고려해 보세요:

건물 전체를 폐쇄하고 모든 파이프를 한 번에 교체한다. 이 방법은 공사 기간 동안 건물을 사용할 수 없고, 교체 비용을 선지급해야 하므로 매우 방해가 크고 비쌉니다. 하지만 과정이 끝날 때까지 완료됩니다.
층별로 폐쇄하고, 층마다 파이프를 교체한다. 이것은 전반적으로 덜 방해되지만, 여전히 선지급 비용을 지불해야 하고 공사가 진행되는 동안 원활하게 운영을 유지하기 위해 추가 노동에 대한 *추가 비용(premium)*을 지불해야 하므로 다소 더 비쌉니다.
파이프가 고장 나기 시작할 때 필요한 만큼 교체한다. 이것은 가장 방해가 적은 전략이며, 작은 수리 하나하나를 거치면서 모든 파이프 교체 비용을 시간에 걸쳐 상각(amortize)할 수 있게 해줍니다.

대부분의 사람들에게 옵션 3은 매우 매력적입니다. 원활하게 운영을 유지하고 유지보수 비용을 분산시킬 수 있도록 해주기 때문입니다. 그리고 만약 우리가 *테세우스의 배 [1]*처럼 파이프를 하나씩 교체할 수 있다면, 왜 그렇게 하지 말아야 할까요?

음, 한 가지 이유는 그것이 **디코히어런스(decoherence)**를 만들기 때문입니다.

그리고 디코히어런스는 단연코 최악의 기술 부채(tech debt) 형태입니다.

진화

테세우스의 배는 실제로 우리가 디코히어런스의 진정한 범위를 이해하는 데 좋은 렌즈를 제공합니다. 우리는 나무로 만든 배와 강철로 만든 배를 만드는 방법을 알고 있습니다. 원래 사고 실험에서처럼, 부품 하나하나를 같은 재료로 수리할 수 있으며, 배는 기능적 상태를 유지하고 모든 원래 설계 및 구조가 온전하게 남아있습니다.

하지만 나무와 강철 사이의 모든 반복(iteration)을 가진 배를 만드는 방법을 알고 있을까요? 만약 전함(man-of-war)의 모든 부품을 서서히 교체하면서 점진적으로 현대 구축함(modern destroyer)으로 바꿀 수 있다면 어떨까요? 그리고 이 과정의 매 단계에서 기능적 상태(어떤 정의의 기능적인지라도)를 유지할 수 있을까요?

답이 절대적인 "아니오"는 아닙니다. 우리가 충분히 창의적이고 최고의 인재들이 이 문제에 매달린다면, 분명 이것을 수행할 어떤 방법은 있을 것입니다. 하지만 그것은 *독창성(ingenuity)*과 기술(skill) 그리고 *장인 정신(craftsmanship)*을 요구할 것입니다. 세부 사항에 대한 주의가 필요합니다. 그리고 결정적으로, 그 과정을 완료하고 싶을 것입니다. 왜냐하면 전함의 절반과 구축함의 절반이 결합된 배는 현대 전투에서 그다지 좋은 성능을 발휘하지 못할 가능성이 높기 때문입니다.

다시 배관(plumbing) 예시로 돌아가면, 같은 전략이 건설 분야의 세계에서 얼마나 규칙적으로 나타나는지 볼 수 있습니다. 파이프가 깨질 때마다 배관공을 부르고, 벽을 열고, 그 특정 영역에 맞춰 수리 작업을 손으로 진행한 다음, 모든 것을 다시 닫습니다. 운이 좋으면 배관공이 상세한 메모를 남기지만, 그렇지 않다면 몇 년 후 누군가가 그 벽을 다시 열고 스스로에게 "도대체 여기서 무슨 일이 벌어지고 있는 거야?"라고 말할 것입니다.

이제 시간이 지남에 따라 건물 내의 파이프를 서서히 교체하는 과정을 곱해나가면, 그 최종 결과물은 오래된 파이프와 새로운 파이프가 뒤섞인 패치워크이며, 이는 어느 한쪽 시스템 자체보다 훨씬 더 큰 *복잡성(complexity)*을 가집니다. 모든 연결부, 모든 손으로 만든 패치는 연구가 부족한 고유한 힘과 특성의 작은 묶음이며, 따라서 두 모든 시스템에 대한 전문가만이 완전히 이해하고 작업할 수 있도록 요구합니다.

겉보기에는 괜찮습니다. 파이프가 작동하니까요. 그것들이 어떻게 작동하는지는 왜 중요할까요? 패치만 좋다면 누가 신경 쓰겠어요?

자, 만약 우리가 예를 들어 별관(annex)을 짓고 싶다면 어떻게 될까요?

이 사고 실험의 목적을 위해, 별관의 물이 기존 파이프를 사용하여 최소한 우리 건물 일부를 거쳐야 한다고 가정하겠습니다. 그리고 결정적으로, 우리는 시스템의 *전반적인 수압(overall water pressure)*을 높여야 합니다.

이제 질문은 이것입니다: 압력을 높이는 것이 안전할까요?

만약 우리가 모두 type A 파이프나 모두 type B 파이프를 가지고 있고, 심지어 시간이 지나면서 패치되고 수리된 것들까지 포함한다면, 이것은 간단한 질문일 것입니다. 두 시스템 모두 잘 이해되어 있으며, 용량 계산을 위한 도구와 프로세스를 갖추고 있고 사람들은 이 계산을 항상 수행합니다.

하지만 만약 우리가 두 시스템의 알려지지 않은 혼합물을 가지고 있다면, 그 질문에 답하기 위해 갑자기 훨씬 더 많은 분석을 해야 합니다. 모든 패치가 답을 바꿀 수 있으며, 심지어 시스템의 다른 끝에 있는 것들까지도 마찬가지입니다. 왜냐하면 이 모든 것이 연결되어 있기 때문입니다.

그리고 바로 여기서 디코히어런스(decoherence)의 진정한 복잡성이 명확해집니다. 우리가 디코히어런트한 시스템에 변경을 시도할 때, 이는 단일 시스템으로 작업하는 것보다 훨씬 더 많은 전문 지식과 기술을 요구합니다. 이 시스템에서 작업하는 엔지니어는 자신의 변경 사항이 의도하지 않은 결과를 초래할 수 있기 때문에, 이를 훨씬 더 철저하고 신중하게 추적하고 이해해야 합니다. 그리고 네, 저는 배관공(plumbers)을 엔지니어로 계산하는데, 적어도 소프트웨어 개발자만큼은 그렇습니다. 그들이 실시간으로 하수구 파이프의 압력 힘을 생각하는 것을 본 적이 있습니까? 정말 놀랍습니다.

이는 결코 작은 작업이 아니며, 서두르지 않는 것이 가장 좋습니다. 하지만 문제의 깊이를 이해하지 못한 외부 관찰자에게는 이것이 좌절스러울 수 있습니다. 보통 이 부분은 쉽습니다. 왜 이번에는 이렇게 오래 걸리는 걸까요?

이런 상황에서 경영진은 종종 일을 더 빨리 끝내기 위해 압력을 가합니다. 압력이 가해지면, 전문가는 전체 분석을 더 빠르게 수행하는 것이 아니라, 분명히 작동할 것이라고 '꽤 확신'하는 무언가만 하고 멈춥니다. 부실한 연결, 특이한 부품, 만약을 위한 추가 안전장치 같은 것입니다.

하지만 작업을 철저히 완료하지 않으면 연쇄 효과(knock-on effect)를 일으킵니다. 이 특정 변경은 품질이 낮아지고, 시스템을 더 취약하고 복잡하게 만듭니다. 이는 다음 변경이 훨씬 더 많은 생각과 주의를 요한다는 것을 의미하며, 엔지니어에게 가해지는 압력이 동일하다면, 그들은 심지어 더 나쁜 작업을 하게 될 것입니다.

현재 상황은 상당히 복잡합니다. 여기서 일종의 지수적(exponential) 복잡성 증가가 일어나고 있는 것을 이미 볼 수 있습니다. 하지만 더 나빠집니다! 디코히어런스(decoherence)의 다음 단계, 즉 첫 번째 전환을 완료하기 전에 두 번째 전환을 시작하는 경우를 고려해 봅시다.

미로 (The Maze)

물리적인 건물이나 다른 종류의 실제 시스템과 비교했을 때 소프트웨어의 까다로운 점은 모든 것이 일종의 눈에 보이지 않는다는 것입니다.

코더들은 매일 코드베이스(codebases)의 복도를 걸어 다닙니다. 우리는 그 미로를 너무 자주 성공적으로 탐색해서 모든 구석과 모든 모퉁이에 익숙해지지만, 우리의 산책이 더 길어지고 복도와 막다른 골목, 함정 문 등이 많아질수록, 우리는 그것을 훨씬 더 즉각적이고 직관적으로 느낍니다.

하지만 이것은 미로를 볼 수도 없고 매일 함께 걸어 다닐 수도 없는 사람들에게는 설명하기 어렵습니다. 그리고 부채(debt)를 정리하거나, 미로를 더 짧고 덜 구불구불하게 만들 때, 당신의 제안은 상위 단계에서 팔기 어려우며, 심지어 예전에 미로를 오래 걸었던 사람들조차도 그렇습니다. 결국 그들 누구도 당신의 미로를 알지 못합니다. 그들이 그것을 통과할 때마다 당신이 직면하는 시련들을 모릅니다.

비교하자면, 실제 세계의 배관공 친구는 건물주에게 자신의 파이프의 터무니없음을 훨씬 더 직접적으로 보여줄 수 있습니다.

[2]

우리가 두 개 이상의 시스템을 함께 섞고, 시간이 지남에 따라 무계획하게 여러 패치(patches)를 적용하기 시작하면, 미로의 복잡성은 폭발합니다. 이제 그것은 조합적(combinatorial)입니다. A -> B, A -> C, B -> C, A -> B -> C, C -> B -> A 등 모든 경우를 생각해야 합니다.

물론 우리는 엔지니어들을 어느 정도 보호할 수 있습니다. 모범 사례(best practices)를 만들거나, 도구와 프레임워크를 사용하여 시스템의 일부를 다른 부분으로부터 격리(isolate)할 수 있습니다 (예를 들어, 파이프에 압력 제한 밸브를 사용하는 것처럼). 하지만 필연적으로는 아무리 뛰어난 엔지니어, 가장 똑똑한 사람들도 미로를 안전하게 탐색할 수 없는 지점에 도달합니다.

그들은 80%나 90%의 확률로는 할 수 있겠지만, 결국 잘못된 길을 택하게 될 것입니다.

따라갈 흔적의 문자열을 잊어버리고 끝없는 성장 속에서 길을 잃는다. 이 성장은 그들의 모든 발걸음을 앞지르며 영원 속으로 나아간다. 이것이 바로 디코히어런스 함정(Decoherence Trap)이다. 미로는 계속해서 확장되어 당신을 통째로 삼키고 어둠 속에 길을 잃게 만든다. 너무 거대해져서 탐색하는 데 평생이 걸릴 정도가 될 때까지 말이다.

인간에게는 아무리 해도 평생이라는 시간이지만, AI는 어떨까?

시뮬레이션 (Simulation)

인간은 지치고 물리적 한계에 도달하지만, 자율 에이전트 군집(autonomous agent swarms)은 마치 착한 로봇들처럼 24시간 내내 집단적으로 지치지 않고 미로를 매핑할 수 있다. 규모가 문제라면, 그냥 컴퓨팅 파워를 더 많이 투입해서 끝내는 것이 아닌가?

글쎄, 그것은 우리가 직면한 복잡성의 본질에 달려있다. 이것이:

• 전체 코드베이스 크기에 따라 선형적으로 증가하는지, 아니면
• 변경 사항마다 *기하급수적(exponentially)*으로 증가하여 다음 변경 사항이 더 많은 복잡성을 추가할 가능성을 높이는지 말이다.

만약 전자가 맞다면, 문제의 크기가 커질수록 에이전트와 데이터 센터를 계속 추가하고 비슷한 속도로 문제를 해결해 나갈 수 있다. 하지만 후자라면, 단순히 용량을 늘리는 것은 미로의 크기가 지구(그리고 SpaceX 계획[3]대로 진행된다면 우주에서도)에 있는 모든 컴퓨팅 파워를 위협할 때까지 조금 더 밀어붙일 수 있는 능력만 줄 뿐이다.

내 경험상으로는 후자다. 배관공이 벽을 열고 난장판을 보면 무엇이 문제인지 명확하지 않다. 그들은 A 파이프를 사용하기로 결정하거나, B 파이프를 사용하기로 결정하거나, 아니면 혼란 속에서 완전히 새로운 유형의 파이프를 추가할 수도 있다. 코딩에서도 이와 같은 상황이 훨씬 더 흔하다.

아래 간단한 시뮬레이션에서 이를 확인할 수 있다. 여기에는 코드베이스(또는 다른 복잡한 시스템)를 나타내는 그래프가 있는데:

노드 (Nodes): 시스템 내의 서로 다른 구성 요소들을 나타낸다.

노드 크기 (Node Size): 해당 구성 요소의 크기를 나타낸다.

**노드 색상(Node Color)**은 해당 구성 요소가 속하는 지배적인 패러다임을 나타냅니다. 이를 '종류'의 구성 요소라고 생각할 수 있습니다. 파이프의 다른 재료, 코드의 다른 구조물, 시스템의 다른 유형 등과 같습니다.

**엣지(Edges)**는 이러한 구성 요소들 간의 연결을 나타냅니다.

미리 계산된 타임라인 로딩 중...

여기는 몇 번의 실행 기록입니다. 만약 직접 전체 시뮬레이션을 가지고 놀고 싶다면, 설정을 변경하고 무슨 일이 일어나는지 지켜볼 수 있는 링크를 여기에서 찾을 수 있습니다.

개발자를 나타내는 액터(actor)가 그래프의 임의의 하위 섹션을 따라 이동한 다음 이를 변형함으로써 '기능(feature)'을 구현합니다. 이 액터의 기본 행동은 그 *일관성 계수(coherence factor)*에 의해 형성됩니다: