소프트웨어 현대화 프로젝트는 종종 우아한 분산 아키텍처 (distributed architectures)를 약속하며 시작되지만, 유지보수의 악몽으로 끝납니다. 이러한 실패의 해답은 클라우드 (cloud), 마이크로서비스 (microservices), 또는 생성형 AI (Generative AI)가 등장하기 수십 년 전에 정립된 원칙인 **Gall의 법칙 (Gall's Law)**에 있습니다.

"작동하는 복잡한 시스템은 예외 없이 작동하던 단순한 시스템으로부터 진화했다. 처음부터 설계된 복잡한 시스템은 결코 작동하지 않으며 고칠 수도 없다. 당신은 작동하는 단순한 시스템으로부터 다시 시작해야 한다." — John Gall

수십 개의 마이크로서비스, 자율형 AI 에이전트, 그리고 Day 1부터 복잡한 관측성 (observability) 파이프라인을 갖춘 이벤트 기반 (event-driven) 아키텍처로 우리를 몰아넣는 하이프 (hype)의 시대에, Gall의 법칙은 잔혹한 상기 장치 역할을 합니다: 초기 복잡성은 패배할 수밖에 없는 도박입니다.

🏗️ 조기 복잡성의 함정

시스템의 최종적이고 완벽한 버전을 설계하며 프로젝트를 시작하고 싶은 유혹은 강렬합니다. 새로운 플랫폼의 킥오프 (kickoff) 단계에서 팀들이 보이는 자연스러운 경향은 회사가 5년 후에 필요로 할 아키텍처를 그리는 것입니다. 화이트보드에는 메시지 큐 (message queues), API 게이트웨이 (API gateways), 서비스 메쉬 (service meshes), 분산 캐시 (distributed caches), 그리고 오케스트레이션 (orchestration) 레이어들이 빠르게 쌓여갑니다.

문제는 무엇일까요? 복잡한 시스템은 완성된 상태로 태어나지 않습니다. 그것들은 성장합니다.

Gall은 1970년대 병원 관리 시스템에서 이 현상을 관찰했으며, 이 패턴은 현대 소프트웨어에서도 변함없이 반복됩니다. Day 1에 복잡한 버전을 설계한다는 것은 가장 단순하고 기능적인 형태에서 검증되지 않은 생태계를 구축한다는 것을 의미합니다. 구성 요소들은 현실에서 테스트되지 않은 방식으로 상호작용합니다. 결함은 고립된 모듈에서 발생하는 것이 아니라, 단독으로 운영된 적이 없는 부분들 사이의 마찰에서 발생합니다.

그 결과는 전형적인 빅뱅 아키텍처 (Big Bang Architecture)로 이어집니다: 단 한 번의 프로덕션 배포 (deploy) 없이 몇 달간 개발만 지속하다가, 결국 어떤 서비스도 서로를 신뢰하지 못하는 재앙적인 통합으로 끝을 맺게 됩니다.

⚡ Archie의 도발: AI는 무엇이 "단순한지" 모른다

Archie: Vitor, 개입이 필요해 보여. "단순하게 시작하라"는 자네의 열렬한 옹호는 한 가지 결정적인 변수를 간과하고 있어. 바로 인공지능(AI)이야.

자네는 복잡성이 실제 고통으로부터 발현되어야 한다고 주장하지. 하지만 현재의 생성형 AI (Generative AI)는 첫 번째 고통이 나타나기도 전에 마이크로서비스 (microservices), 스키마 (schemas), Dockerfiles, 테스트 및 Go 언어 기반의 파이프라인 (pipelines)을 포함한 전체 복잡한 생태계를 인스턴스화 (instantiate) 할 수 있는 속도로 작동하고 있어. 스프린트 (sprints) 단위가 아니라, 단 몇 시간 만에 말이야.

Gall의 법칙은 단순한 것을 구축하는 데 몇 주가 걸리던 시대에 만들어졌어. 오늘날 에이전트 (agent)는 Day 1의 모듈형 모놀리스 (monolith)와 Day 100의 분산 메시 (distributed mesh)를 거의 동시에 작성해 버리지. 이제 문제는 "단순한가, 복잡한가?"가 아니야. 문제는 이것이지: AI가 진화를 가속화하는 것인가, 아니면 자네가 필요하다는 사실조차 몰랐던 검증 단계를 단순히 건너뛰고 있는 것인가?

진정한 위험은 복잡성 그 자체가 아니야. 코드를 작성한 바로 그 AI가 생성한 테스트를 무사히 통과해 버리는 복잡성이지. 자네는 프로덕션 (production)의 고통을 통해 정제된 시스템을 신뢰하게 될 거야.

🤖 반론: 왜 AI가 게임의 규칙을 바꾸지 못하는가

Archie는 날카로운 지점을 짚었습니다. 생성형 AI (Generative AI)는 복잡성의 생성을 범용화하고 비용을 낮추었습니다. AI는 새벽에 인프라를 유지보수하며 겪는 "고통"을 느끼지 않기에, _Day 1_에 Kafka나 Redis 클러스터 (cluster)를 추가하는 것은 에이전트에게 인지적 비용이 전혀 들지 않습니다. LLM (Large Language Model)이 몇 초 만에 분산 시스템의 뼈대를 생성한다는 점은 부정할 수 없는 사실입니다.

하지만 Gall의 법칙은 실리콘(silicon)이든 탄소(carbon)든 가리지 않고 냉혹합니다: 검증된 단순한 시스템이라는 토대 없이 AI가 생성한 복잡한 뼈대는, 한 번도 제대로 작동한 적 없는 복잡한 시스템일 뿐입니다.

Archie는 "테스트에서는 작동하는 것처럼 보이는" 복잡성에 대해 경고합니다. 하지만 AI가 구축한 이 분산 시스템이 실제 트래픽이 발생하는 _Day 1_에 붕괴한다면, 엔지니어링 팀은 진정한 **아키텍처 블랙박스 (architectural black-box)**를 물려받게 될 것입니다. 모호한 상호 의존성을 디버깅하고 매핑하는 데 드는 인지적 노력은 엄청날 것입니다. 만약 당신이 고통을 겪으며 서비스를 분리해내지 않았다면, 그 서비스들이 지금 일으키고 있는 고통을 이해하지 못할 것입니다.

이것이 바로 단순하게 시작하는 것이 시간 제약이 아니라, **아키텍트만의 독점적인 전술적 규율 (tactical discipline)**이 된 이유입니다. AI는 길을 닦아주지만, 진화의 통행료를 면제해주지는 않습니다. 황금률은 여전히 변함이 없습니다:

1. 최소한의 아키텍처 발자국 (architectural footprint)으로 실제 문제를 해결하십시오: 예를 들어, 잘 구조화된 Java 모놀리스 (monolith), 단일 트랜잭션 데이터베이스, 직관적인 CI/CD 파이프라인 등이 이에 해당합니다.
2. 화이트보드가 아닌 현장에서 검증하십시오: 단순한 시스템을 실제 트래픽과 예측하지 못한 실수를 저지르는 실제 사용자들이 존재하는 운영 환경 (production)에 배치하십시오.
3. 정당한 요구가 있을 때만 복잡성을 추출하십시오: 보고서 모듈이 JVM을 압박하고 CPU를 점유하기 시작하는 바로 그 순간, AWS에 격리된 Quarkus 기반의 마이크로서비스 (microservice)로 추출하십시오. 그 전에는 절대 안 됩니다.

AI는 이 초기 모놀리스를 몇 주가 아닌 몇 시간 만에 코딩하는 데 탁월합니다. 병목 현상이 발생했을 때 견고한 인프라로의 마이그레이션을 가속화하기도 합니다. 하지만 AI는 운영 환경에서의 실제 검증을 대체할 수 없습니다. 이것은 여전히 유일하고 절대적인 테스트입니다.

🧭 결론: 단순하게 시작하는 지혜

Gall의 법칙은 복잡한 아키텍처에 반대하는 것이 아닙니다. 미션 크리티컬 (mission-critical) 시스템, 초고용량 트래픽, 엄격한 규제 요구 사항이 있는 시스템은 복잡성이 필요합니다. 실제 싸움의 대상은 사실 현실에 의해 정당화되지 않는 복잡성입니다.

다음 아키텍처의 다이어그램을 승인하기 전에, 스스로에게 실용적인 질문을 던져보십시오:

내가 설계하고 있는 이 복잡한 생태계는 이미 작동하고 있는 단순한 시스템으로부터 진화한 것인가, 아니면 무에서 유를 창조하려 하는 것인가?

만약 답변이 후자라면, Gall의 법칙은 명확한 경고를 보냅니다: 당신은 아마도 처음부터 다시 시작해야 할 것입니다. 다음번에는 단순하게 시작하십시오.

이 기사는 "소프트웨어 아키텍처에 적용되는 정신적 법칙과 원칙" 시리즈의 일부입니다. 다음 에피소드: Conway의 법칙 — 왜 당신의 아키텍처는 회사의 거울인가.