소프트웨어 모델링의 진화
소프트웨어 설계의 단위가 객체(Object) 에서 마이크로서비스(Microservice)로 진화해온 과정은, 단순히 코드를 짜는 방식의 변화를 넘어 '거대하고 복잡한 시스템을 인간이 어떻게 통제할 것인가'에 대한 끊임없는 해법 찾기의 역사였습니다. 이는 작은 벤처 기업이 성장을 거듭하며 글로벌 대기업으로 성장하면서 겪는 조직의 성장과정을 모델링 기술의 발전과정에 비추어 이야기해 보겠습니다.
1. OOAD 시대: 열정적인 개인들의 직접 소통 (객체 기반)
가장 초기 단계인 OOAD(Object-Oriented Analysis and Design) 시절, 기업은 모든 구성원이 각자의 역할과 책임(R&R)을 가지고 일사불란하게 움직이는 소규모 조직과 같았습니다. 이 시기 소프트웨어의 최소 단위는 '객체'였으며, 모든 객체는 단일 컨테이너라는 하나의 건물 안에서 살았습니다. 구성원들은 옆 자리에 앉아 있는 동료의 이름을 부르며 직접 소통했고, 데이터와 기능을 공유하며 기민하게 움직였습니다. 하지만 기업 규모가 커져 직원이 100명을 넘어서자 대혼란이 찾아왔습니다. 사장은 누가 어떤 전문성을 가졌는지, 누가 노는지 한눈에 파악하기 어려워졌고, 구성원 간의 동선이 꼬이면서 소통 비용이 업무 효율을 잡아먹기 시작했습니다. 물리적인 한 공간에 너무 많은 개별 단위가 모여 있다 보니, 작은 변화 하나가 전체 조직의 질서를 흔드는 비효율이 발생한 것입니다.
2. CBD 시대: 부서 체계의 도입과 전문성 확보 (컴포넌트 기반)
이러한 관리의 한계를 극복하기 위해 사장은 CBD(Component-Based Development)라는 개념을 도입합니다. 이는 '부서'라는 개념을 만들어 연관된 업무를 수행하는 객체들을 하나의 덩어리(컴포넌트)로 묶는 작업이었습니다. 인사팀, 재무팀, 개발팀처럼 명확한 경계를 나누고, 부서 안에서 직책을 부여하여 팀 단위의 협업 체계를 구축했습니다. 이제 사장은 100명을 직접 관리하는 대신, 10여 개의 부서장만 관리하면 되었습니다. 조직은 훨씬 체계적으로 변했고, 각 부서는 자신들만의 전문성을 쌓으며 재사용 가능한 '부품'처럼 작동하기 시작했습니다. 그러나 여전히 숙제는 남았습니다. 타 부서와의 협업이 필요할 때마다 직접 사무실로 찾아가거나 오프라인 회의를 소집해야 하는 '대면 중심 소통'의 한계였습니다. 구조는 나뉘었지만, 소통 방식은 여전히 본사 건물이라는 물리적 공간에 묶여 있었습니다.
3. SOA 시대: 온라인 네트워크와 서비스의 탄생 (서비스 기반)
기업이 구성원은 200명으로 늘어나고 업무가 복잡해지자, 사장은 물리적 거리와 대면 소통의 비효율을 완전히 제거하기 위해 SOA(Service-Oriented Architecture)를 선포합니다. 사장은 모든 부서에 '표준 전화기(RESTful API)'를 설치하고, 부서 간 소통은 반드시 이 표준화된 선로를 통해서만 이루어지도록 명령했습니다. 이 단계에서 부서는 단순한 조직 단위를 넘어, 외부에서 호출 가능한 기능을 제공하는 '서비스'로 격상됩니다. 이제 직원들은 굳이 상대 부서 건물을 찾아가 줄을 서지 않아도 됩니다. 잘 정의된 인터페이스를 통해 원격으로 업무를 요청하고, 실시간으로 결과를 전달받는 디지털 소통 체계가 완성된 것입니다. 그러나 이 모델 역시 '단일 본사 건물(단일 컨테이너)'이라는 굴레를 벗어나지는 못했습니다. 만약 본사 건물의 서버가 다운되거나 전력이 차단되면, 모든 부서의 서비스가 동시에 멈춰버리는 구조적 취약성을 안고 있었습니다.
4. MSA 시대: 독립 채산제와 완전 분산 오피스 (마이크로서비스 기반)
회사의 성장과 함께 조직의 구성원은 300명을 넘어섰습니다. 사장은 거대해진 본사 건물의 비효율과 리스크를 완전히 해소하기 위해 MSA(Microservices Architecture)를 도입하기에 이릅니다. 이는 기업을 사업부 단위나 특정 영업 조직을 위한 '독립 오피스'로 완전히 쪼개어 분산 배치하는 것을 의미합니다. 이제 각 조직은 '마이크로서비스'라는 이름 아래, 자신들만의 오피스 공간과 전산 장비, 심지어는 독자적인 운영 규칙을 가진 작은 기업처럼 행동합니다. 서울의 고객에게는 강남 지점이 대응하고, 지방 고객에게는 해당 지역 오피스가 즉각 반응합니다. 특정 지점에 화재 등의 문제가 발생하더라도 다른 지역의 오피스는 아무런 차질 없이 업무를 계속할 수 있습니다. 객체(개인)에서 시작해 부서(컴포넌트)를 만들고, 온라인 소통망(SOA)을 구축한 뒤, 마침내 완전한 독립성과 민첩성을 갖춘 분산형 전문화 조직(MSA)으로 진화한 것입니다. 이 흐름은 시스템의 규모가 커질수록 결합도는 낮추고 독립성은 높여야 한다는 공학적 진리를 기업 조직이라는 거울을 통해 명확히 보여줍니다. 이처럼 기술의 발자취를 따라가 보면, 우리가 현재 마주하고 있는 MSA는 단순히 유행하는 기술이 아니라, 거대 조직이 관료주의와 비효율을 걷어내고 생존하기 위해 선택한 최선의 조직 설계와도 같은 것임을 알 수 있습니다.
5. 불변의 본질: 모든 진화의 뿌리는 '객체'에 있습니다
우리는 지금까지 객체에서 컴포넌트로, 다시 서비스와 마이크로서비스로 이어지는 거대한 아키텍처의 외형적 변화를 살펴보았습니다. 조직의 규모가 커지고 소통 방식이 디지털화되면서 겉모습은 몰라보게 달라졌지만, 그 심장을 들여다보면 결코 변하지 않는 핵심 요소가 자리 잡고 있습니다. 그것은 바로 "객체(Object)"입니다. 컴포넌트는 결국 특정한 목적을 달성하기 위해 협력하는 여러 유형의 객체들의 집합이며, 서비스나 마이크로서비스 역시 그 내부를 채우고 있는 것은 유기적으로 상호작용하는 객체들의 그룹입니다. 아키텍처의 진화는 이 객체들을 어떻게 더 큰 단위로 묶고(Aggregation), 어떻게 경계를 나누어(Encapsulation) 격리할 것인가에 대한 방법론적 변화일 뿐입니다. 즉, 개별 객체가 자신의 책임을 다하고 다른 객체와 협업하는 "객체 모델링"의 원리는 모든 시대를 관통하는 소프트웨어 공학의 가장 근본적인 뿌리라고 할 수 있습니다.
레베카 워프스브록(Rebecca Wirfs-Brock)은 그녀의 저서에서 객체를 단순히 데이터의 묶음이 아닌, 시스템 안에서 특정한 '역할'을 수행하는 살아있는 실체로 정의했습니다. 그녀가 제시한 객체의 유형은 다음과 같습니다. 우리가 설계하는 마이크로서비스 내부에는 이런 유형의 객체들의 협업하고 있습니다.
[ 참고 ] 레베카 워프스브록의 객체 유형 (Object Role Stereotypes)
- ① 정보 제공자 (Information Holder): 시스템이 필요로 하는 정보를 유지하고 제공하는 객체입니다.
- ② 구조 조정자 (Structurer): 객체 간의 관계를 유지하고 조직화하여 시스템의 구조를 잡는 객체입니다.
- ③ 서비스 제공자 (Service Provider): 특정한 작업이나 계산을 수행하여 다른 객체에 도움을 주는 객체입니다.
- ④ 조정자 (Coordinator): 여러 객체 간의 상호작용을 관리하고 작업의 흐름을 제어하는 객체입니다.
- ⑤ 제어자 (Controller): 시스템의 상태 변화를 감지하고 의사결정을 내리는 주도적인 객체입니다.
- ⑥ 외부 인터페이스 (Interfacer): 시스템 외부(사용자나 타 시스템)와 소통하는 통로 역할을 하는 객체입니다.
결국, 훌륭한 마이크로서비스를 설계한다는 것은 그 내부에 존재하는 다양한 유형의 객체들에게 적절한 역할(Role)과 책임(Responsibility)을 부여하고 협업하게 하는 과정과 같습니다. 기업 조직으로 비유하자면, 아무리 거대한 글로벌 사업부(MSA)라 할지라도 그 안에서 실제로 가치를 만들어내는 것은 각자의 전문성을 가진 구성원(객체)들이기 때문입니다.
결론적으로, 기술의 흐름이 객체 지향(OOAD)에서 컴포넌트(CBD/CBSE)를 지나 마이크로서비스로 나아가는 것처럼 보일지라도, 그 기저에는 항상 '객체 모델링'이 실체로 자리잡고 있습니다. 우리가 객체의 책임을 명확히 정의하고 그들 사이의 협력 관계를 올바르게 설계할 수 있을 때, 비로소 컴포넌트도, 서비스도, 그리고 마이크로서비스도 비효율 없이 견고하게 작동할 수 있는 것입니다. 시대가 변해도 소프트웨어 모델링의 본질은 여전히 "객체"에 머물러 있습니다.
doitsong