이따금 내가 원하는 것이 뭔지 잘 따져 보아야 할 때가 있습니다. 각고의 노력 끝에 마침내 메리는 경영진을 설득시켜 마이크로서비스 아키텍처로 전환하기로 했습니다. 그녀는 흥분과 두려움이 뒤섞인 가슴을 쓸어안고 뭘 어디서부터 시작하면 좋을지 논의하기 위해 아침부터 아키텍트를 전원 소집했습니다. 회의 내내 다들 배포, 서비스 디스커버리 같은 생소한 마이크로서비스 아키텍처 패턴 언어로 어리둥절하기는 했지만 그리 이해하기 어려운 정도는 아니었습니다. 하지만 진짜 문제는 애플리케이션을 기능에 따라 여러 서비스로 분해하는 마이크로서비스 아키텍처의 핵심 과제입니다. 결국 이 아키텍처의 출발점이자, 가장 중요한 요소는 서비스를 어떻게 정의하느냐 하는 것입니다. 화이트 보드 주위에 모인 FTGO 팀원들은 깊은 시름에 잠겼습니다.

이 장에서 다룰 핵심 내용은 마이크로서비스를 정의하는 방법입니다. 여러분은 애플리케이션을 여러 서비스로 분해하는 다양한 전략을 살펴보면서 서비스가 기술 관심사보다는 비즈니스 관심사를 중심으로 구성된다는 사실을 배우게 될 것입니다. DDD(Domain-Driven Design, 도메인 주도 설계)의 개념을 이용해서 만능 클래스(god class, 갓 클래스)¹를 제거하는 방법도 소개합니다.

우선 소프트웨어 아키텍처 관점에서 마이크로서비스 아키텍처를 정의한 후, 애플리케이션의 요건 정의부터 마이크로서비스를 정의하는 과정을 기술합니다. 애플리케이션을 여러 서비스로 분해하는 전략과 이 분해 작업을 가로막는 장애물은 무엇인지, 그리고 어떻게 하면 극복할 수 있는지 알려 드립니다.

 

 

---