아날로그 의존성 지도: 마이크로서비스를 하나 더 늘리기 전에 손으로 경계를 스케치하라

당신에게 지금 필요한 건, 또 하나의 마이크로서비스가 아닐지 모른다.

적어도, 이미 가지고 있는 시스템을 제대로 이해하기 전까지는 말이다.

팀들은 규모 확장, 성능 개선, 조직 간 마찰 같은 문제에 부딪히면 습관처럼 “새 서비스 하나 더”를 떠올리곤 한다. 하지만 이미 수많은 API, 큐, 게이트웨이, 서드파티 SaaS가 뒤엉켜 있는 환경에 “하나만 더”를 추가하는 일은, 회복탄력성을 높이기보다 눈에 띄지 않는 취약성을 키우기 쉽다.

바로 여기서 아날로그 의존성 지도(Analog Dependency Atlas) 가 필요하다. 새로운 것을 도입하기 전에, 당신의 생태계와 그 경계를 손으로 직접 그려 보는 의도적인 연습이다.

자동 생성 서비스 맵이 넘쳐나는 세상에서 펜과 종이는 원시적으로 들릴 수 있다. 하지만 도구가 놓치는 것, 사람들이 암묵적으로 가정하고 있는 것, 사고가 터지고 나서야 드러나는 것들을 발견하려면 바로 이런 아날로그 도구가 제격이다.

디지털 세상에서 왜 굳이 아날로그로 시작해야 할까?

의존성 그래프, Observability 플랫폼, 아키텍처 대시보드는 분명 유용하다. 하지만 중립적인 도구는 아니다. 이 도구들은 다음에 의해 제한된다.

로그로 남기는 이벤트
수집하기로 한 메트릭
구성해 둔(그리고 종종 까먹은) 인테그레이션

이 도구들이 보여 주는 건 대개, 우리가 관찰하기로 선택한 일부 시스템의 단면일 뿐이다.

손으로 그리는 매핑은 작동 방식이 다르다.

단순히 관찰하는 것을 넘어, 직접 생각하게 만든다.
사람들 머릿속에만 있던 암묵지를 밖으로 끌어낸다.
빠져 있는 박스와 없는 화살표를 통해 이해의 빈틈을 드러낸다.

결과물은 예쁜 다이어그램이 아니다. 진짜 결과물은 대화다. 시스템 전체에 대한 공유 이해, 즉 “우리가 실제로 무엇을 돌리고 있는지”에 대한 공감대이고, 이는 우발적 복잡성을 막는 첫 번째 방어선이 된다.

1단계: “서비스”만 말고 생태계 전체를 인벤토리로 만들기

의존성을 그리려면, 먼저 뭘 운영하고 있는지부터 알아야 한다. 마이크로서비스만 적어서는 부족하다. 전체 환경을 포괄해야 한다.

다음 항목들을 가능한 한 빠짐없이 인벤토리로 만든다.

애플리케이션
웹 앱, 모바일 앱, 내부 도구, 관리자 콘솔, 크론 잡.
마이크로서비스 & API
퍼블릭 서비스, 내부 서비스, 엣지 서비스, 레거시 엔드포인트.
데이터 스토어
데이터베이스(SQL/NoSQL), 데이터 웨어하우스, 캐시, 메시지 큐, 오브젝트 스토리지.
컴퓨트 기반(Compute Substrates)
서버, VM, 컨테이너, Kubernetes 클러스터, 서버리스 함수(Function).
미들웨어 & 통합 레이어
메시지 브로커, ESB, ETL 도구, 워크플로 엔진.
네트워크 & API 경계부
API 게이트웨이, 로드 밸런서, 리버스 프록시, 서비스 메쉬.
아이덴티티 & 접근 제어
SSO 제공자, IAM 시스템, 시크릿 매니저.
서드파티 SaaS & 외부 서비스
결제 대행, 이메일/SMS 서비스, 분석 도구, 로깅, 피처 플래그.

이 목록은 “너무 많은 것 같다”는 느낌이 들 정도여야 한다. 그게 정상이다.

이 인벤토리가 없으면, 어떤 의존성 맵도 부분적인 진실에 그치거나, 최악의 경우 위험할 정도로 오해를 부르는 그림이 되기 쉽다. 장애가 나거나 변경 배포가 실패했을 때, 근본 원인이 되는 건 대개 “보이지 않던” 컴포넌트다. 아무도 모르는 큐, 아직도 트래픽을 받고 있는 옛 게이트웨이 라우트, 시간이 지나며 어느새 핵심이 되어버린 서드파티 서비스 같은 것들 말이다.

2단계: 숨어 있는 인프라를 찾아내기

시스템에서 가장 위험한 컴포넌트는, 종종 누구도 이야기하지 않는 것들이다.

조용히 메시지를 변환·변형·보강하는 미들웨어
인증, 스로틀링, 라우팅 룰을 적용하는 API 게이트웨이
“하위 호환성” 때문에 남겨둔 레거시 프록시
여러 서비스가 몰래 함께 쓰고 있는 공유 데이터베이스

이런 요소들은 직관적이지 않은 의존성을 품고 있다.

게이트웨이 타임아웃은 겉으로 보기엔 “X 서비스 장애”로 보이지만, 실제 병목은 엣지 레이어에 있을 수 있다.
공유 DB 스키마 변경 하나가, 존재조차 몰랐던 여러 서비스를 동시에 깨뜨릴 수 있다.
미들웨어 룰이 마이크로서비스 코드에 있다고 생각했던 행동을 실제로는 강제하고 있을 수 있다.

손그림을 그릴 때, 특히 이런 숨은 레이어에 주의를 기울여라. 각 요소마다 스스로에게 물어본다.

여기에 누가 의존하고 있는가?
누가 이걸 소유하고 있는가(있긴 한가)?
이게 실패하거나 변경되면 무슨 일이 벌어지는가?

“누가 이걸 소유하죠?”라는 질문에 회의실이 조용해진다면, 그 침묵이 바로 신호다. 단순한 테크 부채를 넘어선 시스템적 리스크 지점이라는 뜻이다.

3단계: 다이어그램 도구보다 먼저, 손으로 그려보기

이제 실제로 그림을 그릴 차례다.

즐겨 쓰는 다이어그램 툴을 여는 유혹을 잠시만 참아라. 종이, 포스트잇, 화이트보드부터 꺼내는 게 좋다. 목표는 문서화가 아니라 발견이다.

아날로그 의존성 지도 그리는 방법

인벤토리의 모든 항목에 박스를 그린다
각 박스는 하나의 컴포넌트다. 서비스, 데이터베이스, 게이트웨이, 큐, SaaS 도구 등.
실제 의존 관계를 화살표로 연결한다
- “서비스 A가 HTTP로 서비스 B를 호출한다”
- “서비스 C가 데이터베이스 D에 기록한다”
- “웹 앱이 로그인에 아이덴티티 제공자 E를 사용한다”
화살표에 프로토콜과 의미(시맨틱)를 적는다
- REST / JSON, gRPC, Kafka, S3, Webhooks 등
- 동기 vs 비동기
- 사용자 경험의 핵심 경로(critical path) vs 실패해도 괜찮은 best-effort 경로
외부 경계를 눈에 띄게 표시한다
조직 경계를 굵게 그린다. 그 밖에 있는 건 모두, 자체적인 신뢰도와 SLA, 변경 패턴을 가진 외부 의존성이다.
모르는 부분은 분명하게 표시한다
누가 누구와 통신하는지, 어떻게 동작하는지 확신이 없는 곳에는 물음표를 그려 둔다. 이제 그 물음표는 “미스터리”가 아니라, 해결해야 할 할 일 목록이다.

다 그렸을 때, 종이가 엉망처럼 보일 것이다. 그게 잘 된 것이다. 그동안 암묵적으로 숨어 있던 복잡성이 이제 눈에 보이는 상태가 된 것이다.

이 난잡한 아날로그 단계가 끝나고 나서야, 이 중 일부를 디지털 도구에서 정제된 다이어그램으로 옮길지 고민해도 늦지 않다.

4단계: 모든 서비스에 대해 소유권과 경계를 정의하기

소유자가 분명하지 않은 마이크로서비스는, 그저 분산된 부채일 뿐이다.

마이크로서비스 아키텍처에서 진짜 가치를 얻으려면, 각 컴포넌트마다 다음을 분명히 해야 한다.

이 서비스를 누가 소유하는가?
사람 이름이 아니라 팀 이름이어야 한다. 소유한다는 건 가용성, 변경, 진화를 책임진다는 뜻이다.
이 서비스의 Bounded Context는 무엇인가?
어떤 도메인 개념을 책임지는가? 그리고 무엇을 책임지지 않는가?
이 서비스의 계약(Contract)은 무엇인가?
이 서비스가 노출하는 API, SLA, 데이터 모델은 무엇이고, 어떤 것은 사전 조율 없이 바꾸지 않겠다고 약속하는가?

이걸 전통적인 모놀리식 시스템과 비교해 보자.

코드베이스의 누구나 어디든 바꿀 수 있다.
장애가 나면 책임 소재가 모호하다. “앱이 다운됐네.” 정도로 끝난다.
결합은 공용 라이브러리, 전역 상태, 거대한 관계형 스키마 속에 숨어 있다.

모놀리스의 문제는 종종 모호한 책임이다. 마이크로서비스는 이를 해결하겠다고 등장했지만, 명확한 경계와 소유권이 없으면 상황은 오히려 악화된다. 이를 피하려면 다음이 필요하다.

서비스(또는 서비스 묶음)마다 명시적으로 이름 붙은 한 팀
서비스마다 분명한 시스템 경계
다른 이들이 의지할 수 있는 분명한 계약(Contract)

아날로그 맵에서 각 박스마다 소유 팀을 옆에 적어라. 팀 이름을 적지 못하는 곳이 있다면, 다음을 의미할 수 있다.

실제로는 아무도 책임지지 않는 경계
공용 모놀리스 인프라처럼 동작하는 플랫폼 표면
변경이 느리고, 정치적 갈등이 생기고, 깨지기 쉬운 리스크 핫스팟

마이크로서비스 vs 모놀리스: 소유권과 의존성의 선명함

모놀리스에서는:

의존성이 주로 코드 레벨에 있다. 함수 호출, 공유 모듈, 공유 테이블 등.
도메인과 코드를 깊이 이해하지 않으면 이런 의존성을 알아차리기 어렵다.
“앱은 팀 전체가 같이 소유한다”는 말이 그럴듯해 보이지만, 실상은 “아무도 특정 부분을 책임지지 않는다”가 되기 쉽다.

잘 설계된 마이크로서비스 생태계에서는:

의존성이 서비스 레벨이고 계약 기반이다. API, 이벤트, 스키마를 통해 드러난다.
맵과(이상적으로는) 도구에서 한눈에 보인다.
소유권이 서비스별로 분리되어, 책임이 분명해지고 변경 속도가 빨라진다.

하지만 모놀리스를 그저 여러 개의 배포 단위로 잘라내기만 하고, 명시적인 경계와 소유권을 정의하지 않으면, 결과는 다음과 같다.

모놀리스 시절의 결합은 그대로 남아 있고
마이크로서비스의 운영 오버헤드만 늘어나며
누가 무엇을 책임지는지에 대한 명료함은 전혀 생기지 않는다

아날로그 지도는 다음 같은 질문을 스스로에게 던지게 해 준다.

우리는 도메인과 책임을 기준으로 분해하고 있는가, 아니면 디렉터리 구조와 기술 스택을 기준으로 잘라내고 있을 뿐인가?

5단계: 서비스 작성자가 아니라 시스템 아키텍트처럼 생각하기

마이크로서비스는 로컬 문제에 대한 해법이다. 하지만 장애와 신뢰성 문제는 시스템 전체 차원에서 발생한다.

복잡계와 최적화에서 아이디어를 빌려오면, 우리는 시스템 레벨 관점이 필요하다.

핵심 경로를 식별한다: 핵심 사용자 여정(예: “주문 생성”)이 성공하려면 어떤 서비스·컴포넌트 체인이 반드시 동작해야 하는가?
강한 결합을 찾는다: 어느 지점에서 하나의 변경이 여러 컴포넌트의 연쇄적인 변경을 강제하는가?
피드백 루프를 이해한다: 재시도, 백오프, 서킷 브레이커, 오토스케일 정책이 어떻게 상호작용해 연쇄 장애 같은 emergent behavior를 만들어 내는가?
트레이드오프를 평가한다: 새로운 마이크로서비스가 한 팀의 개발 속도는 높여 주지만, 조직 전체로 보면 팀 간 조율 비용과 시스템 리스크를 키우는 건 아닌가?

전체 아날로그 맵을 바라보며 스스로에게 물어보라.

이 서비스가 느려지면, 그 뒤에서 무엇이 줄줄이 밀려 쌓이는가?
저 SaaS 제공자가 다운되면, 어떤 사용자 여정이 바로 끊기는가?
어디에 “공유 플랫폼”이란 이름을 달고 있지만 사실상 단일 장애점(SPOF) 으로 동작하고 있는 요소가 있는가?

이런 시스템 관점을 갖고 나서야 비로소 정직하게 판단할 수 있다. 새로운 마이크로서비스를 추가하는 일이:

정말로 경계를 선명하게 만드는 움직임인지, 아니면
단지 실패와 조율의 표면적을 한 겹 더 늘리는 일인지 말이다.

언제(그리고 과연) 다음 마이크로서비스를 추가할 것인가

아날로그 의존성 지도를 눈앞에 두었다면, 이제 그것을 의사결정 도구로 써야 한다. 새로운 마이크로서비스를 하나 더 만들기 전에, 다음을 점검해 보라.

새로운 경계가 분명한가?
제안된 서비스가 응집력 있는 도메인이나 능력을 캡슐화하는가, 아니면 기술적 기준으로 코드를 잘라 붙인 것에 불과한가?
소유자가 분명한가?
이 서비스를 장기적으로 기꺼이 책임질 팀이 있는가?
시스템 전체의 결합도를 줄이는가, 아니면 높이는가?
기존 의존성을 정리·퇴역시키는가, 아니면 그 위에 새 것을 하나 더 얹는 것뿐인가?
맵 위에서 이 서비스의 계약을 깔끔하게 표현할 수 있는가?
API나 이벤트 모델을 설명할 때 말이 흐릿하고 손짓이 많아진다면, 서비스 경계 역시 흐릿할 가능성이 높다.

위 질문에 자신 있게 “그렇다”고 답하지 못하겠다면, 가장 탄탄한 선택은 서비스를 늘리기보다 지금 있는 걸 개선하는 것일 수 있다.

결론: 먼저 그려보고, 그다음에 배포하라

요즘 시스템이 무너지는 이유는 도구가 부족해서가 아니다. 공유된 이해가 부족해서다.

아날로그 의존성 지도—손으로 그린, 있는 그대로의 의존성 뷰—는 이 이해를 강제로라도 표면으로 끌어올린다.

반짝이는 마이크로서비스만이 아니라, 모든 컴포넌트를 인벤토리로 만든다.
숨은 인프라와 서드파티 리스크를 드러낸다.
각 박스마다 소유자와 경계를 분명히 해서, 책임 팀을 붙인다.
시스템 레벨에서 생각하며, 생태계 전체 관점에서 트레이드오프를 평가한다.

다음 마이크로서비스를 추가하기 전에 펜부터 들어라. 당신이 실제로 운영하고 있는 시스템을 그려 보라. 그리고 나서야, 새로운 박스 하나—그리고 그에 따라 늘어날 수많은 화살표—가 진짜로 “좋은 다음 한 수”인지 판단할 수 있다.