Gall's Law

처음부터 모든걸 예상할 순 없다.

우리는 시스템을 만들려고할 때 처음부터 완벽하게 만들려고하는 경향이 있습니다.

처음부터 제대로 설계하면 나중에 크게 바꿀 일이 없겠지.

그런데 실제 프로젝트는 생각처럼 흘러가지 않습니다.

사용자는 우리가 예상하지 못한 요구사항을 이야기하고 운영하면서 새로운 문제가 발견되고 우리가 내린 설계 자체가 잘못되었다는 것을 뒤늦게 알게 됩니다.

제 경험상 개발하며 요구사항과 주변 상황은 우리의 의지와 상관없이 변합니다. 그 풍파를 견뎌내려면 우리의 시스템은 최대한 유연해야합니다.

소프트웨어 공학에선 위와같은 상황과 연관된 법칙이 있습니다.

Gall’s Law

A complex system that works is invariably found to have evolved from a simple system that worked.

작동하는 복잡한 시스템은 대개 작동하는 단순한 시스템에서 발전해 왔다.

— John Gall (General Systemantics: How Systems Work and Especially How They Fail (1975))

처음부터 완벽한 복잡한 시스템을 설계하는 것이 아니라 먼저 작동하는 단순한 시스템을 만들고 필요한 기능과 구조를 하나씩 추가해 나가는 것을 의미합니다.

다시말해서 미래의 모든 요구사항을 미리 예측하지말고 현재 작동하는 작은 시스템을 만들고 그 위에서 다음 변화를 받아들이는 것에 대한 이야기 입니다.

단순 과 대충은 다르다

단순 (Simple) 한 시스템은 대충 만든 시스템을 의미하는것이 아닙니다.

여기서 말하는 Simple 은 불필요한 기능과 복잡성을 제거하고 현재 해결해야 하는 문제에 집중한 시스템에 가깝습니다.

대충 만든 시스템은 변화가 발생했을 때 수정하기 어렵지만 단순한 시스템은 변화가 발생했을 때 유연하게 수정하고 진화할 수 있습니다.

John Gall

존 갤은 소아과 의사가 본업이면서 시스템 이론가 (theorist of systems) 였다고 합니다.

처음엔 30개의 출판사에서 거절 당하고 직접 책을 출판했습니다. 이후 학술지에 소개가되고 시간이 지나 cult classic 이 되었다는 재밌는 이야기가 있습니다.

당시 출판사로부터 외면받았던 책이 지금에서도 인용되는점이 정말 멋집니다.

Gall’s Law 사례

저를 포함한 모든 개발자분들은 실전에서 이미 경험을 했습니다. 세상에 확정이란 없다는것을요. 그리고 이미 설계된 구조로 인해 신규 기능을 반영하는데 높은 Cost 가 드는것도 이미 경험을 하였습니다.

1970 년대에도 이런 고민이 있었습니다. 갤의 법칙은 우리의 이런 상황과 정말 잘 맞습니다.

Facebook 은 처음부터 거대한 서비스가 아니었다.

처음의 Facebook은 지금과 같은 거대한 서비스가 아니었습니다. 하버드 학생을 위한 디렉터리·소셜 네트워킹 서비스 시작했고 작은 규모에서 실제로 작동하는 서비스를 만든 뒤 사용자가 늘어나면서 기능과 규모를 점차 확장했습니다. 처음부터 현재의 Facebook과 같은 규모와 기능을 구현하려 했다면 훨씬 더 복잡한 문제를 동시에 해결해야 했을 것입니다.

Instagram 은 복잡함을 걷어냈다.

Instagram의 전신인 Burbn 은 체크인, 게임, 사진 공유 등 여러 기능을 제공하는 비교적 복잡한 서비스였습니다. 하지만 서비스가 기대만큼 성장하지 않자 창업자들은 기능을 다시 살펴봤고 그중 사용자들이 가장 많이 사용하는 사진 공유 기능에 집중하기로 결정했습니다. 결국 복잡했던 Burbn에서 핵심 기능만 남겨 단순화했고 이것이 Instagram의 출발점이 되었습니다.

MSA (Microservice Architecture)

갤의 법칙은 애플리케이션 아키텍처를 설계할 때도 생각해볼 수 있습니다. 예를 들어 새로운 서비스를 시작하면서 처음부터 여러 개의 마이크로서비스로 나누기 보다 Modular Monolith 로 구성할수도 있습니다.

이후 특정 도메인에 독립 배포, 별도 확장, 장애 격리 등 필요성이 실제로 생기면 그 부분을 분리합니다. 핵심은 마이크로서비스 자체가 목적이 아니라 현재의 복잡성과 조직의 역량에 맞는 구조를 선택하는 것입니다.

마치며

과거 요구사항의 변화를 적용하기 어려울 때는 ‘설계가 부족했던 탓일까?’ 라는 생각을 한적도 있습니다.

초기 과한 설계는 자유로운 생각과 아이디어 가로막고 현재 설계에 맞춰 생각을하게 만들기도 합니다. 어쩌면 한계를 정해놓고 시작하는거나 다름없습니다.

MSA에서 모놀리스로 구조를 단순화한 경험이 있습니다. 당시에는 이를 두고 시대를 역행하는 선택이라는 의견도 있었습니다. 하지만 팀의 규모와 역량, 회사의 자본, 서비스의 현재 복잡도를 고려하면 당시에는 더 많은 서비스를 유지하는 것보다 복잡성을 줄이는 편이 합리적이었습니다.

돌이켜보면 그 선택도 갤의 법칙에서 벗어나지 않았습니다. 처음부터 완벽했던 구조는 없었고 현재 요구사항과 변화에 따라 작동하는 단순한 형태로 되돌아간것입니다.

중요한 것은 최신 트렌드나 기술 자체가 아닙니다. 지금 해결하려는 문제에 그 기술이 정말 필요한지 그리고 그 복잡성을 감당할 수 있는지를 먼저 고민해야 합니다.

처음부터 모든 걸 예상할 순 없습니다.

지금 작동하는 단순한 시스템에서 출발해 다음 변화를 받아들이는 것

이것이 어쩌면 오래 살아남는 복잡한 시스템의 가장 기본이되는 방식일지도 모르겠습니다.