AI, 엔트로피, 그리고 현대 소프트웨어에서의 수렴의 착각

발행: 2일 전 (2026년 2월 7일 오후 07:30 GMT+9)

13 분 소요

Source: Dev.to

번역할 텍스트를 제공해 주시겠어요? 현재는 소스 링크만 포함되어 있어 번역할 내용이 없습니다. 텍스트를 알려주시면 한국어로 번역해 드리겠습니다.

Source: …

시스템은 팀이 무엇이 변함없이 유지되어야 하는지 합의하기도 전에 더 빨리 변한다

코드는 진화하고, 기능은 누적되며, 테스트 스위트는 커진다 — 그러나 자신감은 조용히 사라진다. 테스트는 가드레일 역할을 멈추고 잡음만 만든다.

얼마 전, 나는 Khalil Stemmler의 통찰을 접했는데, 이는 내가 소프트웨어 시스템을 바라보는 방식을 바꾸었다. 그는 창조를 두 가지 힘, 즉 divergence와 convergence 사이의 균형으로 설명한다.

“세상에서 무언가를 창조하는 것은 이 두 가지 창조적 힘, 즉 divergence와 convergence에 의존한다.”
— Khalil Stemmler, Why You Have Spaghetti Code

Divergence

Expansion – 확장
Emergence – 출현

Divergence는 우리가 탐색하는 단계이다. 우리는 접근 방식을 시도하고, 변형을 만들고, 해결책을 스케치하며, 직접 해보면서 배운다.

대부분의 divergent 작업은 저렴하고 되돌릴 수 있다: 아이디어는 버릴 수 있고, 코드는 다시 작성할 수 있으며, 테스트는 삭제할 수 있다.
여기서 목표는 정확성이 아니라 이해이다 — 무엇이 작동할 수 있는지 공간을 넓힌 뒤, 무엇을 선택할지 결정한다.

Convergence

Contraction – 수축
Contracts – 계약

Convergence는 우리가 결정하는 단계이다. 우리는 많은 가능성을 작은 약속 집합으로 압축하여, 시스템이 미래 변화에 견고하도록 만든다.

Convergent 작업은 의도적이며 비용이 더 많이 든다. 왜냐하면 이는 미래 작업이 따라야 할 제약을 만들기 때문이다.
여기서 contracts가 형성된다: 구조, 행동, 불변 조건에 대한 결정으로, 시스템이 시간이 지나도 적극적으로 방어하게 된다.

균형의 필요성

건강한 시스템은 두 가지 힘이 모두 필요합니다. 균형이 깨지면 엔트로피가 스며듭니다. 레거시 코드에 관한 또 다른 기사에서 Khalil은 엔트로피를 발산 뒤에 수렴이 따르지 않을 때 발생하는 현상의 은유로 사용합니다:

“우주가 자연적인 상태인 엔트로피와 마찬가지로, 코드는 시간이 지남에 따라 무질서해지는 경향이 있습니다. 테스트는 일종의 ‘엔트로피 역전’ 메커니즘 역할을 합니다.”
— Khalil Stemmler, How to Improve Legacy Code w/ Characterization Tests

탐색은 계속되지만, 결정은 결코 완전히 고정되지 않습니다. 시스템은 확장되지만, 결코 안정되지 않습니다.

AI‑지원 개발

이 구도는 저에게 깊이 와닿았으며, 특히 AI‑지원 개발에 더 깊이 파고들수록 그렇습니다.

처음에는 테스트 스위트가 활짝 피어나는 것을 보고 신났지만, 그 흥분은 오래가지 못했습니다.
스키마 변경과 리팩터링이 점점 어려워졌습니다. 작은 변경이 시스템 전체에 퍼졌습니다.
테스트 스위트에 대한 자신감이 서서히 떨어졌습니다. 곧 새로운 테스트 중 거의 대부분이 제가 직접 내린 결정과는 관련이 없다는 것을 깨달았습니다.

LLM이 구동하는 발산

LLM은 발산적인 작업에 매우 뛰어납니다. 빠르게 탐색하고, 대안을 생성하며, 인간이 따라잡기 어려운 속도로 반복합니다. 이는 학습, 실험, 초기 탐색을 위한 강력한 도구가 됩니다.

변경된 것은 발산의 기능이 아니라 비용입니다: 현대 AI 도구는 솔루션 공간을 탐색하는 데 필요한 노력을 크게 줄여줍니다.

발산이 거의 마찰 없이 이루어지면, 시스템은 인간이 수렴시키기보다 더 빠르게 확장됩니다 — 리뷰는 얕아지고, 테스트는 관성에 의해 병합되며, 아무도 동의한 기억이 없는 계약이 쌓입니다. 그래서 AI는 처음엔 힘을 실어주는 느낌을 주지만, 시간이 지나면 불안정해집니다.

수렴은 인간이 주도해야 함

잘 활용하면 AI는 발산을 지원하고 판단에 정보를 제공합니다. 그러나 AI가 수렴적 결정—요구사항, 경계, 계약을 인간의 소유 없이 고정하는—을 장악하도록 하면 단순히 도움이 되지 않을 뿐만 아니라, 무질서를 억제하려는 메커니즘을 약화시켜 엔트로피를 적극적으로 가속화합니다.

이러한 결정은 양은 적지만 영향은 불균형적으로 큽니다. 그리고 저는 그 교훈을 힘들게 배웠습니다.

테스트를 수렴 메커니즘으로

인터페이스와 스키마는 구조를 수렴시킨다; 테스트는 동작을 수렴시킨다.

테스트는 종종 검증 도구로 설명된다: 시스템이 기대대로 동작하는지를 확인하는 방법이다. 이것이 틀린 것은 아니지만, 테스트를 수렴 메커니즘으로 생각하면 훨씬 더 강력해진다.

테스트는 단순히 현재 시스템이 어떻게 동작하는지를 설명해서는 안 된다 — 그것은 소스 코드가 하는 일이다.
테스트는 시스템이 진화하면서도 계속 수행해야 할 것을 정의해야 한다.

코드를 작성하듯이 테스트를 작성하는 것도 탐색을 포함할 수 있다. 우리는 시나리오를 시도하고, 경계 조건을 탐색하며, 시스템이 어떻게 동작하는지를 학습한다. 테스트 엔지니어링의 수렴적 행위는 어떤 신호가 충분히 안정적이라 인코딩할지, 어떤 동작을 계약으로 만들지 결정할 때 시작된다.

테스트가 이 역할을 잘 수행하면 변경이 더 안전해진다. 시스템이 반드시 유지해야 할 것이 무엇인지 합의했기 때문에 리팩터링이 덜 두려워진다.

반대로 테스트가 구현 세부 사항을 그대로 반영하거나 부수적인 동작을 하드코딩한다면, 시스템을 수렴시키지 못한다. 엔트로피를 되돌리는 대신, 결코 안정적일 것으로 의도되지 않은 것들에 시스템을 얽매게 함으로써 엔트로피를 증폭시킨다.

Source: …

계약 지속성

계약의 가치는 예상되는 유지 기간에 따라 달라집니다. 일부 계약은 단기간에 끝나지만, 다른 계약은 수년간의 변화를 견디도록 설계됩니다. 수렴 노력은 그 수명에 비례해야 합니다.

단위 테스트

구현에 가깝게 계약을 인코딩합니다.
가치가 있지만, 종종 변동성이 큽니다.
코드가 리팩터링되거나, 추상화가 바뀌거나, 책임이 이동할 때 변경됩니다.
정밀성을 위해 지속성을 포기합니다.

사용자‑대면(엔드‑투‑엔드) 테스트

시스템과 사용자 사이 경계에서 계약을 인코딩합니다.
제품이 무엇을 하는지를 설명하며, 어떻게 구축되었는지는 설명하지 않습니다.
내부 변경(리팩터링, API 변경, 때로는 전체 아키텍처 개편)에도 오래 지속됩니다.

메트릭 함정

팀이 안정적인 계약이 필요한 곳에 단기 계약을 적용하면 문제가 발생합니다. 메트릭은 테스트의 존재를 보상하고, 그들이 인코딩하는 약속의 강도를 보상하지 않음으로써 이 실수를 강화합니다.

커버리지는 증가하지만, 신뢰도는 오르지 않습니다 — 시스템이 잘못된 것에 수렴하고 있기 때문입니다.

AI를 사용해 대량의 테스트 코드를 생성하거나 커버리지 메트릭을 만족하는 사용자 흐름을 기록하는 것이 유혹적입니다. 하지만 이러한 산출물은 장기적인 의도를 거의 인코딩하지 못합니다. 겉으로는 수렴한 것처럼 보이지만, 근본적인 약속은 얕게 남아 있습니다.

요점

계약이 변화에 오래 버틸수록, 그 수렴 노력은 더욱 신중해야 합니다. AI‑구동 발산을 인간‑주도 수렴과 균형 있게 맞추면 엔트로피를 억제하고 시스템 진화에 대한 신뢰를 유지할 수 있습니다.

Generate we must be in defining it, and no contract is longer-lived than the promises we make to users.  

The forces here aren’t new. Software has always required exploration followed by consolidation. What has changed is how cheap exploration has become.  

AI accelerates divergence. Convergence — deciding what must remain true — is the bottleneck.  

That decision shows up as contracts.  

Some contracts are short‑lived and can change freely. Others are meant to survive refactors, rewrites, and architectural shifts. The longer a contract is expected to hold, the more deliberate we need to be about defining it.  

Testing is where this tension becomes visible.  

Seen through this lens, ask yourself:  

- Which of your tests are actually reducing entropy — and which are quietly increasing it?