기술부채라는 말은 이제 개발 현장에서 흔하게 쓰인다. 하지만 모든 부채가 같은 무게를 지니는 것은 아니다. maevyn.codes에 공개된 에세이 'The Decoherence Trap'은 여러 형태의 기술부채 가운데 가장 치명적인 유형으로 '디코히런스(decoherence)'를 지목한다. 저자가 내리는 정의는 이렇다. 하나의 시스템 안에 국소적으로는 타당하지만 서로 양립하지 않거나 중복되는 모델들이 쌓여서, 변경의 비용이 기능 자체보다 '그 모델들 사이를 번역하고 의도치 않은 부작용을 막는 일'에 지배당하는 상태다. 더 거칠게 말하면, 끝없는 잡음의 바다에서 신호가 슬롭(slop)에 묻혀버리는 현상이다.
핵심은 이 부채가 선형적으로 늘지 않는다는 점이다. 디코히런스는 시스템의 변화 속도에 비례해 커지고, 이미 디코히런트한 시스템일수록 더 빠르게 증가한다. 결과적으로 기하급수적인 폭주로 이어진다. 저자는 이것이 전혀 새로운 현상은 아니며, 인간은 늘 서로 다른 패턴과 모델을 하나의 일관된 전체로 통합하면서 '적은 것으로 더 많은 일을 하는' 방식으로 이에 맞서왔다고 본다. 문제는 지금이다. AI의 광범위한 사용이 디코히런스를 감당할 수 없는 속도로 생산해내고 있다는 것이 이 글의 출발점이다.
배관공과 테세우스의 배
저자는 추상적인 개념을 소규모 사무용 빌딩의 배관 교체에 빗대 설명한다. 오래된 배관은 언젠가 교체해야 하는데(마모에 따른 통상적 인프라 부채), 교체 시점에는 새 규격으로 바꿔야 하는 경우가 많다(기술 발전에 따른 부채). 여기까지는 익숙한 이야기다. 세 번째 부채는 '어떻게 전환하느냐'에서 생긴다. 대부분은 운영을 멈추지 않고 비용을 분산할 수 있는 점진적 교체, 즉 배관을 한 번에 하나씩 바꾸는 '테세우스의 배' 방식을 선호한다. 그리고 바로 이 방식이 디코히런스를 만든다.
테세우스의 배 사고실험은 같은 재료로 한 조각씩 교체할 때 성립한다. 우리는 나무 배도, 강철 배도 만들 줄 안다. 그러나 나무와 강철 사이의 모든 중간 형태를, 전함을 한 조각씩 현대 구축함으로 바꿔가면서 매 단계마다 '어느 정도 작동하는' 상태로 유지하는 법은 알지 못한다. 불가능하진 않겠지만 뛰어난 장인정신과 세심함을 요구하며, 무엇보다 중도에 멈추면 전투에 쓸모없는 반쪽짜리 배가 남는다. 배관도 마찬가지다. 파이프가 터질 때마다 벽을 열고 그 자리에 맞춰 수작업으로 때우고 덮는다. 시간이 흐르면 구형과 신형이 뒤섞인 패치워크가 되고, 이음새 하나하나가 두 시스템을 모두 아는 전문가라야 다룰 수 있는 고유한 미지의 덩어리가 된다.
변경 비용이 폭발하는 지점
평소에는 이 혼합이 문제가 되지 않는다. 물만 잘 흐르면 그만이다. 진짜 문제는 변경이 필요할 때 드러난다. 저자는 기존 건물 배관 일부를 거쳐 증축 건물로 물을 보내면서 전체 수압을 높여야 하는 상황을 든다. 단일 규격이라면 용량 계산은 일상적인 작업이다. 그러나 두 시스템이 정체불명으로 섞여 있으면, 멀리 떨어진 패치 하나가 답을 바꿀 수 있어 훨씬 많은 분석이 필요해진다. 모든 것이 연결돼 있기 때문이다. 즉 디코히런트한 시스템의 변경은 각 시스템을 따로 다룰 때보다 훨씬 많은 전문성과 추적, 주의를 요구한다.
여기서 관리의 압박이라는 악순환이 끼어든다. 외부 관찰자에게는 평소 쉬웠던 작업이 왜 이번엔 오래 걸리는지 이해되지 않는다. 압박이 가해지면 전문가는 분석을 더 빨리 하는 게 아니라, 더 일찍 멈추고 '대충 될 것 같은' 방법을 택한다. 엉성한 이음새, 비표준 부품, 혹시 몰라 덧붙인 임시 안전장치. 이번 변경의 품질이 낮아지면 시스템은 더 취약하고 복잡해지고, 다음 변경은 더 많은 주의를 요구하며, 같은 압박 아래 더 나쁜 결과가 나온다. 저자는 소프트웨어가 물리적 건물과 달리 '보이지 않는다'는 점에서 이 문제가 더 악화된다고 지적한다. 개발자는 매일 걷는 코드베이스의 미로를 몸으로 느끼지만, 그 미로를 본 적 없는 윗선에 부채 정리를 설득하기는 어렵다. 배관공은 적어도 터무니없는 파이프 뭉치를 건물주에게 직접 보여줄 수 있다.
AI는 왜 구원이 아닌가
세 개 이상의 시스템이 뒤섞이면 복잡도는 조합적으로 폭발한다. A→B, A→C, B→C, A→B→C처럼 경로의 수가 불어난다. 모범 사례와 프레임워크, 압력 제한 밸브 같은 격리 장치로 일부를 감쌀 수는 있지만, 결국 최고의 엔지니어조차 미로를 안전하게 통과하지 못하는 지점이 온다. 80~90%는 해내더라도 언젠가 잘못된 길로 들어서 실타래를 놓치고 어둠 속에 갇힌다. 이것이 저자가 말하는 '디코히런스 트랩'이다. 그렇다면 지치지 않고 24시간 돌아가는 자율 에이전트 군집을 투입하면 되지 않을까. 저자의 답은 그것이 복잡도의 '성질'에 달렸다는 것이다. 문제가 규모만 키우는 유형이라면 컴퓨트를 늘려 같은 속도로 밀어붙일 수 있지만, 그의 경험상 디코히런스는 후자, 즉 추가 용량이 잠깐 더 전진하게 해줄 뿐 머지않아 지구상의 모든 연산을 삼켜버릴 수 있는 유형이다.
흥미롭게도 저자는 여기서 역설적 위안을 끌어낸다. 디코히런스는 AI가 폐쇄된 거품 속에서 자기개선하는 것을 막고 외부 개선 속도마저 제약하므로, 아무도 반응하기 전에 포물선처럼 치솟는 '지능 폭발' 시나리오는 배제된다는 것이다. 다만 그 대가로 우리는 다른 종류의 재앙, '디코히런스 붕괴'를 향해 질주하고 있다고 본다. 글 말미의 시뮬레이션은 코드베이스를 그래프로, 개발자를 그래프를 걷고 변형하는 행위자로 모델링한다. 코히런스 계수가 낮은 행위자는 처음엔 빠르지만 그래프가 변하면서 급격히 느려지고, 그 결과 엔지니어에게 익숙한 'Sweet Spot' 곡선이 나타난다. 적당히 일관되면서도 변화를 허용하는 지점이 가장 생산적이고, 그 아래로 내려가면 기능 출시 시간이 사실상 무한대로 발산한다는 것이다.
이 에세이는 엄밀한 데이터보다 비유와 사고실험, 단순화된 시뮬레이션에 기대고 있다는 한계를 분명히 가진다. 'AI가 지속 불가능한 속도로 디코히런스를 만든다'는 핵심 주장도 측정 지표보다는 저자의 관찰과 직관에 의존한다. 그럼에도 한국의 실무자에게 주는 함의는 또렷하다. AI 코딩 도구가 코드 생산량을 끌어올릴수록, 생산성의 병목은 '얼마나 빨리 짜느냐'가 아니라 '시스템의 일관성을 얼마나 지켜내느냐'로 옮겨간다. 점진적 전환이 끝나기 전에 또 다른 전환을 시작하지 말 것, 마이그레이션은 완주할 것, 그리고 리뷰와 리팩터링처럼 코히런스를 유지하는 작업에 대한 투자를 '느려 보인다'는 이유로 깎지 말 것. Sweet Spot은 완벽주의도 방임도 아닌, 지속적인 통합 투자가 만들어내는 균형이라는 메시지가 남는다.