개념
시스템은 섬이 아니다
지금까지의 탐험은 대체로 시스템 내부를 다뤘다. 하지만 실제 서비스는 거의 항상 외부 시스템과 연결되어 있다 — 결제 게이트웨이, 이메일·SMS 발송 서비스, 지도 API, CDN, 다른 팀이 관리하는 내부 마이크로서비스 등.
생태계 다이어그램 그리기
우리 시스템을 가운데 두고, 그것과 대화하는 외부 시스템들을 화살표로 연결해 그려본다.
[우리 서비스]
├──→ [결제 게이트웨이]
├──→ [이메일 발송 서비스]
├──→ [배송 조회 API (3rd party)]
└──→ [재고 관리 서비스 (내부, 다른 팀)]이 다이어그램 자체가 "어디를 탐험해야 할지"에 대한 지도가 된다.
신뢰 경계(Trust Boundary)
신뢰 경계는 데이터가 "우리가 통제할 수 있는 영역"에서 "우리가 통제할 수 없는 영역"으로 넘어가는 지점이다. 화살표 하나하나가 신뢰 경계다. 경계를 넘어오는 데이터는 우리가 기대한 형식이 아닐 수 있고, 경계 너머의 시스템은 느려지거나 멈출 수 있다 — 우리 쪽에서 그걸 어떻게 다루는지가 탐험 대상이다.
"만약 ~한다면?"을 생태계에 적용하기
- 만약 결제 게이트웨이가 응답하지 않고 멈춰 있다면(타임아웃)?
- 만약 이메일 서비스가 다운되어 있다면? 사용자에게는 뭐라고 보여지는가?
- 만약 배송 조회 API가 예상과 다른 형식의 응답을 준다면(필드 이름이 바뀌었거나)?
- 만약 재고 관리 서비스가 순간적으로 옛날 데이터를 준다면(캐시 지연)?
이 질문들은 실제로 재현하기 어려울 수 있지만, **최소한 "이런 상황이면 어떻게 될지 아는 사람이 팀에 있는가?"**를 확인하는 것만으로도 가치가 있다. 개발 환경에서 외부 서비스를 흉내 낸 목(mock) 서버로 응답 지연이나 에러를 인위적으로 만들어볼 수 있다면 실제로 탐험해볼 수도 있다.
실무에서 왜 필요한가
실제 장애 사고의 상당수는 우리 코드가 아니라 외부 의존성이 원인이다 — 결제사가 느려지자 우리 서비스 전체가 함께 멈추거나, 이메일 서비스 장애로 회원가입은 되는데 인증 메일이 영영 안 오는 식이다. 내부 로직만 탐험하는 QA는 이런 리스크를 절대 못 본다. 생태계 다이어그램을 그려보는 것만으로도 "우리가 전혀 고려 안 하고 있던 실패 지점"이 눈에 보이기 시작한다. 이건 모듈 16(비기능 테스트)의 호환성·네트워크 테스트와도 연결된다.
실습 과제
과제 1 — 생태계 다이어그램 그리기 (12분)
가상의 "음식 배달 앱"이 대화할 법한 외부 시스템을 최소 4개 떠올려 텍스트로 생태계 다이어그램을 그린다 (결제, 지도/위치, 알림, 배달원 배정 등을 생각해본다).
과제 2 — "만약 ~한다면?" 질문 만들기 (10분)
과제 1에서 그린 외부 시스템 중 하나를 골라, 그 시스템이 실패하거나 느려지는 상황에 대한 "만약 ~한다면?" 질문을 3개 만들고, 사용자에게 어떤 화면이 보여야 이상적일지 적는다.
자가 체크리스트
- 생태계 다이어그램을 직접 그려 외부 의존성을 시각화할 수 있다
- 신뢰 경계가 무엇이고 왜 탐험 대상이 되는지 설명할 수 있다
- 외부 시스템의 실패·지연 상황에 대해 "만약 ~한다면?" 질문을 만들 수 있다
- 실제 장애 사고에서 외부 의존성이 원인이 되는 경우가 많은 이유를 설명할 수 있다
흔한 실수
- 우리 시스템 내부 로직만 탐험 대상으로 삼는다. 실제 사고의 상당수가 경계 바깥에서 시작된다는 것을 놓친다.
- 외부 시스템 실패를 "우리 책임이 아니다"라고 생각해 테스트 대상에서 제외한다. 외부 시스템이 실패했을 때 우리 시스템이 어떻게 반응하는가는 명백히 우리 책임이다.
- 생태계 다이어그램을 한 번 그리고 갱신하지 않는다. 새로운 외부 연동이 추가될 때마다 다이어그램도 함께 갱신해야 계속 쓸모 있다.
참고 자료
- Elisabeth Hendrickson, Explore It! — 생태계 다이어그램과 신뢰 경계 탐험 기법을 다룬 장
- OWASP — Trust Boundaries — 신뢰 경계 개념을 보안 관점에서 다루는 자료 (모듈 16과 연결)