비정합성의 함정: AI 저질 콘텐츠가 끝없는 잡음 속에 신호를 묻어버릴 때

비정합성(decoherence) 은 개별적으로는 타당하지만 서로 호환되지 않거나 중복되는 모델이 시스템에 쌓이는 현상임. 모델 사이를 오가고 의도치 않은 부작용을 막는 일이 변경 비용의 대부분을 차지하게 됨
비정합성은 시간 자체가 아니라 시스템의 변경 에 따라 커지거나 줄어듦. 복잡한 시스템을 서둘러 고칠수록 다음 변경이 더 어려워지며, AI가 변경 속도를 높이면 이 악순환도 빨라질 수 있음
코딩 에이전트 도입 연구에서는 코드 생산량 증가가 완성된 작업 증가로 이어지지 않거나 , 초기 속도 향상이 사라진 뒤에도 복잡성이 남는 결과가 나타남. 더 많은 코드와 장기적인 개발 능력은 같은 것이 아님
빠르고 작은 코드를 만드는 것과 변화에 잘 적응하는 소프트웨어 를 만드는 것은 다름. 현실과 단절된 환경에서는 AI가 정합성을 개선하는지 검증하기 어려워 고립된 재귀적 자기 개선에도 한계가 있을 수 있음
가장 큰 우려는 인간이 감당할 수 없어 에이전트에 의존하지만 에이전트도 복잡성을 되돌리지 못하는 비정합성 붕괴(Decoherence Collapse) 임. 회복하려면 변경 속도보다 정합성 복원에 집중하고, 기능 개발이 다시 가능해진 뒤에도 복원을 끝까지 이어가야 함
비정합성은 다른 기술 부채와 어떻게 다른가
비정합성 은 각 부분의 해법은 그럴듯하지만 전체적으로는 서로 맞지 않는 모델이 누적된 상태임. 서로 다른 패턴과 모델을 더 적은 수의 일관된 구조로 통합하는 작업이 이를 줄임
건물 배관을 예로 들면 서로 다른 세 종류의 부채를 구분할 수 있음
인프라 부채 는 배관이 낡고 마모되어 교체해야 하는 문제임
기술 발전 부채 는 건축 규정 변경, 기존 부품 단종, 더 나은 신제품 등장으로 새 규격으로 전환해야 하는 문제임
비정합성 은 기존 규격에서 새 규격으로 전환하는 방식에 따라 추가로 생기는 문제임
배관 교체에는 비용과 중단 범위가 다른 세 가지 선택지가 있음
건물을 닫고 한꺼번에 교체하면 중단과 선불 비용이 크지만 전환을 완료할 수 있음
층별로 교체하면 중단 범위는 줄지만, 운영을 유지하기 위한 추가 인건비가 들어 전체 비용은 더 커질 수 있음
고장 난 배관만 교체하면 중단을 최소화하고 비용을 분산할 수 있지만, 서로 다른 규격과 개별적인 접합부가 계속 쌓임
테세우스의 배 에서 같은 재료로 부품을 바꾸는 것과 목선을 강철 구축함으로 점진적으로 바꾸는 것 은 다른 문제임
모든 중간 단계에서 작동하게 만드는 일이 불가능하다고 단정할 수는 없지만, 높은 수준의 기술과 세심한 설계가 필요함
전환을 끝내지 않은 혼합 상태는 완성된 어느 쪽보다도 목적에 부적합할 수 있음
부분 수리가 전체 시스템의 변경을 어렵게 만드는 과정
고장 때마다 현장에 맞춰 배관을 수리하면 구형과 신형의 혼합 시스템 은 어느 한 규격만 사용하는 시스템보다 복잡해짐
각 접합부에는 별도의 힘과 특성이 작용하며, 전체를 이해하려면 두 시스템 모두에 대한 전문성이 필요함
수리 기록이 충분하지 않으면 다음 작업자는 벽을 다시 열어 기존 해법을 역으로 이해해야 함
별관을 연결하면서 전체 수압을 높여야 한다면, 문제는 배관이 지금 작동하는지가 아니라 새 압력을 안전하게 견딜 수 있는지 가 됨
단일 규격이라면 알려진 도구와 절차로 계산할 수 있음
혼합 배관에서는 멀리 떨어진 접합부까지 결과에 영향을 줄 수 있어 훨씬 넓은 분석이 필요함
관리자가 일정을 압박한다고 전문가의 분석이 빨라지는 것은 아님. 분석을 일찍 멈추고 아마 작동할 해법 을 선택하게 될 수 있음
임시 접합, 특이한 부품, 추가 안전장치가 당장의 변경을 가능하게 하지만 시스템의 취약성과 복잡성을 높임
다음 변경은 더 많은 검토를 요구하고, 압박이 계속되면 작업 품질이 더 떨어지는 악순환이 생김
보이지 않는 미로와 겹쳐진 전환
소프트웨어의 복잡성은 배관과 달리 눈으로 보여주기 어려움 . 개발자는 코드베이스의 동선이 길어지고 막다른 길이 늘어나는 것을 체감하지만, 그 미로를 직접 다니지 않는 의사결정자에게 정리 비용을 설득하기는 어려움
첫 전환을 끝내기 전에 다음 전환을 시작하면 조합적 복잡성 이 커짐
A→B뿐 아니라 A→C, B→C, A→B→C, C→B→A 등의 경로를 함께 고려해야 함
모범 사례, 도구, 프레임워크로 일부를 격리할 수 있지만, 복잡성이 계속 커지면 뛰어난 엔지니어도 안정적으로 전체를 탐색하기 어려워짐
비정합성의 함정 은 변경을 위해 탐색해야 하는 미로가 인간의 처리 능력보다 빠르게 커지는 상태임. 대부분의 변경을 성공시키더라도 결국 잘못된 경로를 택할 위험이 남음
시뮬레이션: 빠른 변경과 지속 가능한 속도의 차이
에이전트를 더 투입하는 해법의 효과는 복잡성의 증가 방식 에 달려 있음
코드베이스 크기에 비례해 선형적으로 증가한다면 에이전트와 데이터센터를 늘려 대응할 수 있음
변경이 다음 변경의 복잡성 증가 가능성까지 높인다면, 계산 자원 증설은 한계에 도달하는 시점을 조금 늦출 뿐임
우주 데이터센터 까지 계산 자원을 늘리더라도 지수적 증가 자체는 해결하지 못함
인터랙티브 시뮬레이션 은 시스템을 그래프 로 표현함
노드는 구성요소, 노드 크기는 구성요소의 규모, 색은 지배적인 패러다임, 간선은 구성요소 사이의 연결을 뜻함
개발자를 나타내는 행위자는 그래프의 임의 구간을 탐색하고 변경해 기능을 구현함
행위자의 정합성 계수(coherence factor) 가 작업 방식을 결정함
낮으면 맥락을 충분히 고려하지 않고 빠르고 단순한 결정을 내려 복잡성을 더하기 쉬움
높으면 더 오래 검토하지만 덜 복잡한 변경을 만들거나 기존 복잡성을 제거할 가능성이 커짐
변경 이후의 그래프는 세 가지 방식으로 후속 작업을 늦춤
연결 차수 증가 는 현재 노드를 이해하기 위해 살펴봐야 할 인접 맥락을 늘림
색 사이의 전환 은 서로 다른 패러다임과 그 연결 방식을 이해하는 비용을 발생시킴
탐색 경로가 길어지면 더 많이 읽고 재방문해야 하며, 극단적으로는 어디를 고치든 시스템 전체를 이해해야 함
기능 생산량과 정합성 사이에는 적정 구간 이 나타남
적정 구간에서는 소수의 지배적인 패러다임을 유지하면서도 변화와 적응을 허용하고, 정합성 유지에 계속 투자함
그보다 높은 정합성을 추구하면 완벽주의 때문에 기능 개발이 느려지지만, 시스템 자체는 비교적 쉽게 변경할 수 있는 상태로 남음
그보다 낮으면 복잡성이 빠르게 커져 개발 속도가 급락하며, 계수가 음수라면 기능 출시 시간이 뚜렷한 상한 없이 늘어남
높은 정합성에서 시작해도 +0.2의 계수 로 일부 지름길을 계속 택하면 처음에는 천천히 악화되다가 변곡점을 지나 함정에 빠짐. 반대로 비정합적인 시스템에 복원 노력을 투입하면 정합성과 개발 속도를 함께 높일 수 있음
이 시뮬레이션은 임의의 가중치 를 사용하므로 실제 복잡계가 반드시 이렇게 진화한다는 증거는 아님. 단순한 규칙과 국소적 결정만으로도 이런 곡선이 창발할 수 있음을 보여주는 예시임
변경 속도, 조직의 반복 패턴, 코딩 에이전트 연구
비정합성은 시간이 아니라 변경에 따라 달라짐 . 시스템을 10년간 그대로 두면 다른 기술 부채는 생길 수 있지만 비정합성 자체는 그대로임
따라서 변경당 비정합성 증가량이 작아도 변경을 매우 빠르게 반복하면 문제가 빠르게 커질 수 있음
인간도 이 문제에서 자유롭지 않음. 개인적인 근무 경험에서는 모든 회사에 상당한 비정합성이 있었으며, 경험이 적거나 압박받는 엔지니어가 이를 더하기 쉬웠음
많은 회사가 적정 구간 아래에서 복원과 악화를 반복 할 수 있음
기능 개발이 합리적인 시간 안에 끝나지 않을 정도로 비정합성이 커짐
대규모 정리 작업으로 느리지만 수용 가능한 개발 속도를 회복함
정리를 완료하지 않거나 적정 구간에 도달하기 전에 자원과 관심을 다른 곳으로 돌림
시스템이 다시 비정합적으로 변함
적정 구간을 유지하려면 지속적인 엔지니어링 문화 가 필요함. Apple을 그 사례로 꼽는 데에는 macOS와 Windows에 대한 개인적 평가가 포함되어 있음
코딩 에이전트가 평균적인 엔지니어링 문화보다 정합성을 훨씬 잘 유지한다는 근거는 아직 확인되지 않았으며, 인용된 초기 연구들은 오히려 반대 방향의 결과를 보임
Harvard 연구 의 718개 기업 에서는 에이전트 도입 후 코드 작성량이 30% 늘었지만 완성된 작업은 측정 가능한 증가가 없었음. 풀 리퀘스트 검토 시간은 49% 길어졌고 수정 요청을 받은 건수는 거의 두 배가 됨
Carnegie Mellon 연구 에서 Cursor를 도입한 오픈 소스 프로젝트의 초기 속도 향상은 지속되지 않았지만 코드 복잡성 증가는 남았으며, 이 복잡성이 이후 둔화의 주요 원인 중 하나였음
AI 작성 커밋 분석 은 6,000개 이상 저장소의 30만 개 이상 커밋 을 조사함. 약 11개 중 1개, 도구에 따라 최대 7개 중 1개가 품질 문제를 하나 이상 도입했고, 그 문제의 거의 4분의 1이 분석 시점에도 남아 있었음
산업혁명 비유에서 코드가 차지하는 위치
기술 발전에 기대는 반론 에 따르면, 초기 에이전트의 코드가 열등해도 충분히 쓸 만하다면 인간을 대체하고 이후 더 좋은 에이전트가 등장할 것을 전제로 업무를 재편할 수 있음
방직 자동화도 초기에는 인간보다 품질이 낮았지만 결국 따라잡았음
Cory Doctorow 는 산업가들이 노동을 통제하고 권력을 집중하기 위해 자동화를 서둘렀으며, 노동자와 대중이 여러 세대에 걸쳐 나쁜 노동 조건과 낮은 상품 품질을 감수했다고 비판함
다만 초기 방직 기계는 최소 품질 기준을 충족하는 제품을 오랫동안 생산했고, 가동 자체가 기계의 비정합성을 높이지는 않았다는 차이가 있음
이 비유에서 코드는 직물이 아니라 방직 기계 에 해당함. 사용자가 구매하는 것은 코드가 아니라 애플리케이션이며, 화면 표시, 폼 제출, 레코드 갱신 등이 코드가 생산하는 결과물임
코딩 AI에 더 가까운 비유는 다음 세대 방직 기계를 설계하는 기계 임. 스스로 설계를 개선하는 자동화는 기존 생산 자동화와 다른 문제이며, 기술적 특이점 과 재귀적 자기 개선의 구상으로 이어짐
Goodhart 특이점과 소프트웨어 지능 폭발
Tom Reed는 2026년 5월 Goodhart 특이점 이라는 용어로 새로운 현실 데이터 없이 AI가 고립된 환경에서 반복 개선하는 데 따르는 한계 를 다룸. 이 개념은 Goodhart의 법칙 에 기반함
Forethought의 Tom Davidson 은 데이터 병목 분석 에서 인간 수준 품질의 상한 에 도달하면 발전이 느려질 수 있다고 인정함
더 나은 인간 시연이 남아 있지 않으면 AI가 기존 데이터보다 좋은 데이터를 직접 만들어야 함
다만 이를 넘을 수 없는 벽이 아니라 일회성 둔화로 봄
Davidson의 연구는 이후 AI 2027의 도약 예측 에도 토대가 됨
소프트웨어 지능 폭발(SIE) 구상은 AI가 현실에 존재하는 것보다 좋은 소프트웨어를 만들도록 가르치는 강화학습 환경 을 직접 구축할 수 있다는 데 기대고 있음
Davidson은 어려운 문제를 푸는 것보다 만들고 답을 검증하는 것이 쉬우며, 인간 전문가도 이미 인간 품질 상한을 넘는 데이터를 만드는 환경을 설계한다고 봄
강화학습 의 기본 흐름은 목표 설정, 가능한 행동 정의, 여러 방법 시도, 달성도와 방법의 품질 측정, 최선의 방법 선택임
SIE에는 AI가 이 전체 과정을 독립적으로 수행하며 학습하고 개선하는 알고리듬 자체 를 더 좋게 만들어야 한다는 조건이 붙음
자동차, 로켓, 반도체 설계는 시뮬레이션에서 개선하더라도 현실 검증 이 필요함. 검증 없이 극단적인 설계로 나아가면 현실에서 멀어질 수 있으며, 현실과의 왕복은 개선 속도를 제한함
바둑과 체스 , StarCraft ), Dota 는 규칙과 승리 조건이 정해져 있어 고립된 환경에서도 전략과 전략 탐색 방법을 개선할 수 있음
소프트웨어 역시 독립적으로 실행하고 빠르게 테스트할 수 있다는 점 때문에 SIE의 유력한 경로로 여겨짐
그러나 실행 속도나 안전성 같은 성질을 검증하는 것과 현실에서 유용한 소프트웨어인지 판단하는 것은 다른 문제임
좋은 소프트웨어의 기준과 futures의 사례
소프트웨어는 현실의 목표를 달성하기 위한 도구 임. 코드 줄 수, 실행 속도, 메모리 사용량, 효율은 중요하지만 그것만 최적화하면 작고 빠르면서도 비정합적인 시스템이 될 수 있음
성능 최적화는 흔히 작업을 생략하기 위해 시스템의 다른 부분에 대한 가정 을 도입함
리스트가 이미 정렬되어 있다거나 값이 절대 0이 아니라는 가정은 문서화되지 않은 연결이 됨
최적화한 네이티브 코드를 추상화 뒤에 격리하는 이유도 이런 가정이 다른 부분으로 새어 나가지 않게 하기 위해서임
JavaScript에서 실행 빈도가 높은 경로를 단형적(monomorphic) 으로 유지하려고 여러 논리적 클래스를 하나로 합치는 방식도, 다시 손대지 않는 동안에는 이득이 있지만 변경은 어려워지는 사례임
애플리케이션, 라이브러리, 프레임워크는 사회와 현실의 제약이 바뀔 때 계속 진화해야 함. 따라서 좋은 소프트웨어는 기존 기술 자산을 재조합해 새로운 문제에 적응 할 수 있어야 함
futures 는 서로 맞지 않던 비동기 처리 방식을 통합한 사례임
이전에는 각 방식이 국소적으로는 타당해도 함께 쓰기 어려웠고, 콜백과 비동기 작업이 늘수록 읽기 어려운 코드와 추적하기 힘든 버그가 생겼음
미래 값의 자리표시자라는 개념은 1970년대에 등장했고, 1985년 MultiLisp에서 처음 구체적으로 구현됨
Java가 2004년 도입했으며, 2010년대 JavaScript의 연쇄 가능한 promises와 C#의 Task가 등장하면서 널리 사용됨
초기 futures가 늦게 확산된 데에는 API의 불편함과 실행 오버헤드 가 있었음
값을 읽을 때 블로킹되어 시점을 주의해야 했고, 독립적으로 연결하거나 분기하기 어려웠음
함수 포인터만 저장하는 대신 상태 추적용 래퍼 객체를 만들어야 했음
API가 개선되고 계산 자원과 메모리가 저렴해지면서, 큰 시스템을 이해하고 결합하기 쉬워지는 이점이 비용을 정당화함
고립된 환경에서 정합성을 검증할 수 있는가
데이터센터 내부에서 검증할 수 있는 후보를 게임, 소프트웨어, 수학 으로 좁히더라도, 소프트웨어의 정합성을 확인하려면 추상화가 다양한 맥락과 변화에 얼마나 잘 맞는지 평가해야 함
외부 세계와 접촉하지 않는다면 두 가지 방법에 의존하게 됨
기존 소프트웨어 전체에 적용하기 : 현재 프로그램에 잘 맞아도 미래 프로그램까지 잘 맞는지는 알 수 없음. GUI와 웹이 확산되기 전에는 콜백, 이벤트 루프, futures의 가치가 지금처럼 분명하지 않았으며, 현재의 프로그램에 과적합할 수 있음
새 소프트웨어 생성하기 : 그럴듯한 프로그램을 만들어도 현실에서 유용한지 검증하지 않으면 학습 대상이 현실에서 멀어질 수 있음
정합성은 한 시점의 적합성뿐 아니라 시간에 따른 적응력 도 요구함
데스크톱에서 잘 작동하는 표준이 모바일이나 대규모 클라우드에서는 부적합할 수 있음
모두가 동시에 업그레이드하지 않고, 일부는 뒤처지거나 다른 방향으로 가는 생태계까지 고려해야 함
이 논리에 따르면 기존 소프트웨어의 정합성은 계속 개선할 수 있지만, 아직 존재하지 않는 소프트웨어에 대한 개선 을 확인하려면 현실이 새 문제를 만들기를 기다리거나 직접 만든 소프트웨어를 현실에서 시험하고 진화를 관찰해야 함
고립된 환경에서 더 빠르고 작고 효율적인 소프트웨어를 만드는 것은 가능함
그러나 현실 검증 없이 정합성까지 인간 수준을 넘어 개선하는지 확인하기 어렵다면, 학습 알고리듬의 개선과 현실로부터의 이탈도 구별하기 어려워짐
이런 한계는 고립된 SIE뿐 아니라 연속 세대의 자기 개선 에도 제약을 줄 수 있음
각 세대는 이해의 경계를 넘어 시스템을 확장하므로 비정합성을 도입할 가능성이 있음
너무 빨리 전진하면 복잡성을 고치는 속도보다 쌓는 속도가 빨라져 능력이 정체하거나 후퇴할 수 있음
모든 결과를 검증하면 외부 세계에서 데이터를 수집하는 능력이 속도 상한이 됨
Eth와 Davidson의 SIE 모형은 5개월 이전에 성장 곡선이 급격히 치솟지만, 변형 예시는 누적 작업이 늘면서 변경 비용이 두 배가 된다는 가정 을 추가함
이는 AI가 비정합성을 피할 수 없다는 조건 아래에서 현실의 물리적 한계와 정보적 한계에 묶일 수 있음을 보여주려는 모형이며, 실제 AI 발전 속도를 입증하는 결과는 아님
Davidson은 직업마다 1,000명이 4개월 동안 화면과 머리 착용 카메라로 작업을 기록하면 300년 분량의 경험 을 모을 수 있다고 봄
그러나 끝없는 자기 개선에는 커서 이동이나 영상 속 물체 식별뿐 아니라, 단순 녹화로 포착하기 어려운 맥락과 미묘한 차이, 처음에는 무관해 보이는 것 사이의 연결까지 이해해야 함
수학의 참인 명제와 유용한 이해는 다름
검증 가능한 증명 을 활용하면 수학은 고립된 환경에서 개선할 수 있는 또 다른 후보임. 그러나 형식적으로 타당한 수학을 만드는 능력과 무엇이 유용한지 알아보는 능력은 다름
0과 허수는 처음부터 자연스럽게 받아들여진 개념이 아니었으며, 사원수 역시 낯선 개념이었음
불 대수 는 George Boole이 1847년 발표했지만 거의 한 세기 동안 실용 공학 도구보다 형식논리의 특수한 분야로 연구됨
실제 문제와의 접촉 이 어떤 수학을 찾아야 하는지 알려줬음. 논리 체계를 무한히 생성할 수 있어도, 현실에서 무엇이 중요한지 구별하는 능력까지 고립된 환경에서 개선할 수 있는지는 별개임
2026년 9월 Terence Tao를 포함한 필즈상 수상자 25명 은 AI와 수학의 심각한 목표 불일치에 관한 선언 에 서명함
문제 풀이는 수학의 진짜 목표인 이해를 대신 측정하는 수단일 뿐이며, 참인 명제를 대량 생산하면 새로운 아이디어가 자라는 기반을 약화할 수 있다고 경고함
생태계의 분열과 비정합성 붕괴
정합성을 만드는 작업은 단순히 주어진 문제를 푸는 것이 아니라 어떤 문제들을 함께 풀어야 하는지 찾고 , 복잡성이 폭발하지 않는 공통 해법을 만드는 과정임
Omarchy 는 깔끔한 기본 설정 모음이라는 초기 목표에서 커스텀 커널을 갖춘 완전한 배포판 으로 나아가는 듯함
생태계 가장자리에서 포크하고 제약 없이 실험한 뒤 결과를 공동체에 돌려주는 것은 오픈 소스의 중요한 강점임
실험 자체보다 공동으로 축적한 정합성을 버리고 모든 의존성을 다시 만드는 방향 이 우려스러움
1980년대부터 2000년대까지 기업들은 각자의 의존성, 스크립트, 운영체제 버전으로 구성된 서버 환경을 관리했고, 운영을 유지하는 데 전담 팀이 필요했음
Unix 전쟁 당시에는 Unix의 명확한 후계자가 없는 가운데 Windows가 다른 패러다임으로 성장하며 분열이 더 심했음
Linux와 자유 소프트웨어 운동이 없었다면 클라우드 컨테이너마다 라이선스 비용을 내야 했을지, 얼마나 많은 스타트업이 시작하지 못했을지는 생각해 볼 문제임. 다만 FreeBSD가 Linux의 자리를 대신했을 가능성도 있음
지난 20여 년의 작업 상당수는 생태계의 정합성을 높이는 일 이었으며, 일부 가치는 SaaS 제품으로 포착됨. 단기 문제를 해결하려고 모든 구성요소를 재작성하고 제각각 확장하면 이 축적을 소모할 수 있음
비정합성 붕괴 는 다음 조건이 겹칠 때의 위험임
시스템이 너무 커지고 복잡해져 인간만으로는 유지할 수 없고 에이전트를 반드시 써야 함
에이전트도 정합성을 복원하지 못하면, 복구에 노력해도 시스템이 계속 나빠지는 개발 방식에 갇힐 수 있음
최종적으로 고칠 수 있더라도 수년 또는 수십 년이 걸려, 그동안 기능 개발과 다른 중요한 문제 해결이 지연될 수 있음
AI의 효용 자체를 부정하지는 않지만, 핵심 업무를 대체하거나 완전 자율 운영하기보다는 사람이 통제하는 보조적 활용 을 지지함
회복은 가능하지만 복원을 끝내야 함
비정합성은 AI와 함께 처음 생긴 문제가 아니라 오래전부터 인간이 다뤄온 일종의 엔트로피와 퇴화 임
시스템이 바뀔 때만 비정합성이 달라지므로, 아무리 깊이 빠졌더라도 전진을 멈추고 복원으로 전환할 수 있음
회복에 수년이나 수십 년이 걸리더라도 가장 어려운 부분은 초기에 있으며, 정합성을 개선할수록 후속 복원이 쉬워짐
기능을 다시 만들 수 있을 만큼만 고친 뒤 예전 방식으로 돌아가면 같은 악순환이 재시작됨
인간은 이미 정합성을 높이는 절차 를 만들어 왔고, 그 성과가 지난 수 세기의 기술 발전 규모를 가능하게 했음
특히 오픈 소스 개발 과정 은 소프트웨어 정합성을 만들어내는 데 성공해 여러 영역에서 기업 내부 개발을 능가해 왔음. 이 논의는 후속 글 Open Capital 로 이어짐
댓글과 토론