SOA

SOA란 무엇인가

SOA(Service-Oriented Architecture, 서비스 지향 아키텍처)는 시스템을 재사용 가능한 서비스 단위로 나누어 구성하는 아키텍처 방식이다. 각 서비스는 특정 업무 기능을 독립적으로 제공하며, 표준화된 인터페이스를 통해 다른 시스템이 그 기능을 호출해 쓴다.

거대한 단일 시스템을 한 덩어리로 다루는 대신, 결제·인증·재고 같은 업무 능력을 개별 서비스로 떼어 두는 것이 핵심이다. 이렇게 하면 같은 기능을 여러 시스템이 중복 개발하지 않고 공유할 수 있어, 조직 전체의 자산 재사용이 가능해진다.

서비스라는 단위의 의미

SOA에서 말하는 서비스는 단순한 함수나 모듈이 아니라, 비즈니스 의미를 갖는 완결된 업무 기능이다. 호출하는 쪽은 서비스의 내부 구현을 알 필요 없이 약속된 인터페이스만 따르면 되며, 이를 느슨한 결합이라 한다.

서비스가 어떤 언어로, 어떤 데이터베이스 위에서 동작하는지는 외부에 감춰지므로 내부를 자유롭게 교체할 수 있다. 이 독립성 덕분에 서비스 단위로 개발·배포·확장이 가능해지고, 변경의 파급이 한 서비스 안으로 국소화된다.

재사용과 표준 계약

SOA의 가치는 재사용성과 상호운용성에 있다. 한 번 잘 만든 서비스는 여러 채널과 시스템이 공통으로 호출하므로, 동일 로직을 부서마다 다시 구현하는 낭비가 사라진다.

이를 가능하게 하는 전제는 명확한 서비스 계약, 곧 입력·출력·예외를 규정한 인터페이스 명세다. 계약이 흔들리면 그 서비스에 의존하는 모든 소비자가 영향을 받으므로, 계약의 안정성과 버전 관리는 SOA 운영의 핵심 과제다.

잘 설계된 계약은 서비스 제공자와 소비자가 서로의 내부를 몰라도 협업할 수 있게 하는 약속이 된다.

MSA·REST와의 관계

SOA는 흔히 MSA, 계층형 아키텍처, REST API와 함께 언급된다. MSA는 SOA의 정신을 더 작은 단위와 자율적 배포로 밀어붙인 흐름으로 볼 수 있으며, 서비스의 크기와 통합 방식에서 차이를 둔다.

전통적 SOA가 중앙의 통합 버스를 통해 서비스를 엮는 경우가 많았다면, 근래에는 REST API처럼 가벼운 통신 방식으로 서비스를 연결하는 형태가 일반적이다. 세 개념은 대립이 아니라 같은 분해 원리의 변주이므로, 조직 규모와 운영 역량에 맞춰 적정 단위를 선택하는 안목이 중요하다.

도입의 비용과 함정

서비스 분리는 공짜가 아니다. 시스템을 잘게 나눌수록 서비스 간 호출이 늘어 네트워크 지연과 장애 전파 위험이 커지고, 분산된 데이터의 일관성을 맞추기도 까다로워진다.

경계를 잘못 그어 서로를 끊임없이 호출해야 하는 서비스들을 만들면, 분리했음에도 사실상 하나처럼 강하게 묶이는 역설이 생긴다. 또한 서비스 목록·계약·버전을 관리하는 거버넌스가 없으면, 누가 무엇을 제공하는지 알 수 없어 재사용이라는 본래 목적이 무너진다.

분리의 이점은 적절한 경계 설정과 운영 체계가 뒷받침될 때만 실현된다.

적용을 판단하는 기준

SOA가 효과를 내려면 여러 시스템이 공통으로 쓸 만한 업무 기능이 실제로 존재해야 한다. 재사용 수요가 없는 기능을 서비스로 분리하면 통신 비용만 늘고 이득은 없다.

도입을 검토할 때는 어떤 업무 능력이 조직 차원에서 반복적으로 필요한지, 그 경계가 시간이 지나도 안정적인지를 먼저 식별해야 한다. 경계가 자주 흔들리는 영역을 성급히 서비스로 굳히면 계약 변경이 잦아져 오히려 결합도가 올라간다.

결국 SOA의 성패는 기술 선택보다 업무를 어떻게 나누느냐는 분해 설계에서 갈린다.