개념
장애의 주인이 사라지는 순간
사용자가 "결제가 안 된다"고 신고했다. 프런트엔드는 A사, 결제 게이트웨이는 B사 SaaS, 인증은 C사 솔루션, 서버는 D사 클라우드, 서비스 데스크는 E사 위탁이다. 각 회사의 SLA 는 모두 지켜지고 있다. 그런데 사용자는 결제를 못 한다.
레슨 3·4 에서 만든 우선순위 매트릭스와 SLA 정책은 한 조직이 서비스를 소유한다 는 전제 위에 있었다. 공급자가 다섯이면 그 전제가 깨진다. 구간마다 주인이 다르고, 구간 사이의 틈에는 주인이 없다.
SIAM(Service Integration and Management, 서비스 통합 관리)은 이 문제를 다루는 방법론이다. Scopism 이 펴낸 SIAM Foundation Body of Knowledge 가 사실상의 표준 참고서 역할을 하고, 여러 공급자에게서 조달한 서비스가 섞인 환경에 적용하는 관리 방법론으로 SIAM 을 정의한다. 핵심 발상은 단순하다 — 공급자들 위에 "통합"이라는 별도의 책임을 하나 더 만든다.
세 계층
SIAM 생태계는 세 계층으로 나뉜다.
| 계층 | 누구 | 책임 |
|---|---|---|
| 고객 조직(customer organization) | 서비스를 받고 비용을 대는 쪽 | 무엇이 필요한지 정의, 조달 결정, 거버넌스의 최종 권한 |
| 서비스 통합자(service integrator) | 통합을 맡은 한 주체 | end-to-end 서비스에 대한 책임, 공급자 간 조정·거버넌스·보증 |
| 서비스 제공자(service provider) | 실제로 서비스를 만드는 쪽. 내부 팀과 외부 공급사 모두 | 자기 구간의 제공과 합의된 성과 |
두 가지가 중요하다. 첫째, 서비스 제공자에는 내부 팀도 포함된다. 사내 인프라 팀은 "우리 회사니까 예외"가 아니라 다른 공급자와 같은 성과 기준과 같은 인터페이스를 쓴다. 이 점을 흐리면 SIAM 은 "외주사만 조이는 체계"가 되고 통합이 절반만 작동한다.
둘째, 통합자 계층은 하나다. 통합 책임이 둘로 쪼개지면 그 사이의 틈에서 원래 문제가 재발한다. 여러 조직이 분담하더라도 하나의 서비스에 대해 end-to-end 를 묻는 곳은 한 곳이어야 한다.
통합자를 누가 맡는가
SIAM Foundation Body of Knowledge 는 통합자를 누가 맡느냐에 따른 구조들을 소개한다. 확인된 세 가지는 이렇다.
| 구조 | 통합자 | 장점 | 위험 |
|---|---|---|---|
| 내부(internal) | 고객 조직 안의 전담 조직 | 고객 이해관계와 정렬. 지식이 조직에 남는다 | 통합 역량·인력을 직접 키워야 한다 |
| 외부(external) | 별도의 전문 사업자 | 역량을 바로 쓴다. 공급자 관리 경험 | 통합자가 곧 "블랙박스" 가 될 수 있다. 지식 이전 계획 필요 |
| 혼합(hybrid) | 고객 조직과 외부 사업자가 함께 | 초기엔 외부 역량, 점차 내재화 | 두 주체 사이의 역할 경계를 아주 세밀하게 써야 한다 |
문헌에는 주 공급사(lead supplier)가 통합자를 겸하는 형태 도 자주 언급된다. 이 형태가 BoK 의 정식 분류에 포함되는지는 원문으로 확인한다. 분류와 무관하게 구조적 이해충돌이 있다는 점은 분명하다 — 자기 구간의 장애를 자기가 판정한다. 이 구조를 택한다면 공급자 성과 판정만큼은 고객 조직이나 제3자가 하도록 분리한다. 역할 독립성 문제가 계약 구조 층위에서 다시 나오는 것이다.
Scopism 은 SIAM 도입 여정을 Discovery & Strategy → Plan & Build → Implement → Run & Improve 네 단계로 제시한다. 구조 결정은 첫 단계에 속하고,
뒤 단계에서 바꾸기가 가장 비싼 결정이다.
책임 경계 — end-to-end SLA 와 그 아래의 약속들
다중 공급자 환경의 계약 구조는 두 층이다.
end-to-end SLA 고객 조직 ↔ 서비스 통합자
사용자가 겪는 서비스 전체에 대한 약속.
"결제 성공률 99.9%", "P1 복구 4시간" 처럼 사용자 언어로 쓴다.
OLA / 기반 계약 통합자 ↔ 각 서비스 제공자
구간별 약속. 내부 팀과는 OLA(운영 수준 합의),
외부 공급사와는 계약서상의 서비스 수준 조항.두 층 사이에서 가장 자주 나는 사고가 합이 안 맞는 것 이다. 예를 들어 end-to-end 로 P1 복구 4시간을 약속했는데, 구간별 약속이 이렇다면:
서비스 데스크 접수·분류 30분
인프라 공급자 1차 조사 4시간 ← 이미 초과
애플리케이션 공급자 수정 8시간
배포 승인·반영 2시간이 상태에서 end-to-end SLA 는 구조적으로 달성 불가능 하다. 그런데 각 공급자는 자기 SLA 를 100% 지킨다. 성과 회의에서는 전원 녹색인데 고객은 화가 나 있다. 막는 절차는 하나뿐이다 — end-to-end 목표를 구간 목표로 분해하고, 직렬로 더해 합이 맞는지 계산한다.
| 확인 | 질문 |
|---|---|
| 합산 | 직렬로 일어나는 구간 시간의 합이 end-to-end 목표 ≤ 인가 |
| 시계 | 각 구간의 시작·정지 시점 정의가 같은가 (접수 시각? 배정 시각?) |
| 달력 | 업무 시간·공휴일 기준이 공급자마다 다르지 않은가 |
| 제외 | 제외 항목(계획 정비, 고객 책임 대기)이 층마다 같은가 |
| 이관 | 공급자 간 이관(hand-off) 시간은 누구의 시계에 들어가는가 |
마지막 줄이 실무의 진짜 함정이다. A사가 "우리 쪽 조사 끝났습니다" 하고 B사에 넘긴 뒤 B사가 접수하기까지의 40분은 대개 아무의 SLA 에도 들어가지 않는다. 이관 대기 시간을 통합자의 시계에 명시적으로 넣지 않으면 복구 시간의 상당 부분이 측정 밖에 숨는다. 레슨 4 의 SLA 재계산 습관이 여기서 그대로 쓰이되 대상이 하나 늘었다 — 공급자별 보고서의 합과 통합 보고서가 맞는지 까지 본다.
교차 공급자 인시던트 — 소유권과 에스컬레이션
여러 공급자에 걸친 인시던트에서 가장 먼저 정해야 하는 것은 소유자 다. 원인이 어디에 있든 인시던트의 소유는 통합자 에 둔다. 공급자는 자기 구간의 작업을 소유하고, 사용자에게 상태를 알리고 종결을 판단하는 책임은 통합자가 진다. 이 규칙이 없으면 원인 규명 전까지 아무도 주인이 아니게 되고, 그 시간이 곧 복구 시간에 더해진다.
작동하는 조직은 이 셋을 미리 정해 둔다.
1. 단일 접수 지점 사용자·공급자 모두 한 곳으로 티켓을 낸다. 티켓 번호가 하나로 이어진다
2. 교차 공급자 브리지 P1 에서 정해진 시간 안에 모든 관련 공급자가 같은 통화·채널에 모인다.
참여 의무와 응답 시간을 계약에 쓴다
3. 판정 권한 원인이 불명확할 때 "일단 누가 파는가" 를 정할 권한을 통합자에게 준다3번이 핵심이다. 원인이 불명확하면 공급자들은 각자 "우리 구간은 정상"이라는 증거를 먼저 만든다. 티켓 핑퐁 이다. 판정 권한이 통합자에게 없으면 핑퐁은 합리적 행동이 된다 — 자기 SLA 를 지키는 것이 각자에게 이익이다. 구조가 만드는 행동은 선의로 바뀌지 않는다.
공동 근본원인 분석(joint RCA) 은 복구 이후의 절차다. 레슨 3 의 인시던트·문제 구분이 여기서 계약 문제가 된다.
| 요소 | 미리 정해 둘 것 |
|---|---|
| 개시 조건 | 어떤 등급·어떤 반복 횟수에서 공동 RCA 를 의무로 하는가 |
| 참여 | 각 공급자가 며칠 안에 누구를 보내는가 |
| 증거 | 로그·추적·설정 이력을 어느 범위까지 공유하는가, 보관 기간은 |
| 산출물 | 누가 문서를 쓰고, 조치 항목의 소유자와 기한을 누가 정하는가 |
| 후속 | 조치 완료를 누가 확인하는가 — 재발 시 다시 열리는 조건 |
공동 RCA 가 계약에 없으면 사고 뒤에 "우리 쪽 원인이 아니어서 참여 의무가 없다"는 답이 온다. 그리고 그 말은 맞다. 계약에 없으면 의무가 아니다. 그래서 이 절차는 사고 뒤가 아니라 계약 전에 만든다.
계약에 써 둘 것
SIAM 환경의 품질은 운영 회의가 아니라 조달 단계에서 대부분 결정된다. 도구 연동을 나중에 요구하면 추가 비용이 되고, 데이터 공유를 나중에 요구하면 영업비밀을 이유로 거절된다. 네 덩어리를 조달 문서에 넣는다.
| 덩어리 | 구체적으로 |
|---|---|
| 인수 기준 | 서비스 개시 전 무엇을 어떻게 시험해 통과를 판정하는가. 통합 지점 시험 포함. 재작업 조건 |
| 데이터 공유 | 어떤 로그·지표·티켓 필드를 어떤 형식·주기로. 보관 기간. 사고 시 원자료 제공 의무 |
| 도구 연동 | 티켓 양방향 연동(상태·타임스탬프 매핑), 상태 페이지, 구성 정보 제공. 연동 실패의 책임 |
| 성과 지표 | 구간 SLA 와 함께 협업 지표 — 브리지 참여율, 이관 응답 시간, 공동 RCA 참여, 정보 제공 적시성 |
마지막 줄의 협업 지표 가 다중 공급자 환경의 특징이다. 구간 SLA 만 재면 공급자는 "빨리 남에게 넘기는 것"이 이익이 된다. 이관 응답 시간과 브리지 참여를 함께 재야 그 유인이 사라진다.
QA 가 통합 지점에서 시험할 것
SIAM 환경에서 QA 의 자리는 분명하다. 각 공급자가 자기 구간을 시험하고 나면, 아무도 시험하지 않는 곳이 경계 다. 그리고 장애는 거기서 난다.
| 시험 대상 | 무엇을 보는가 | 전형적 결함 |
|---|---|---|
| 데이터 계약 | 필드 이름·타입·필수 여부·인코딩·널 처리 | 한쪽은 선택 필드로 보내고 다른 쪽은 필수로 읽는다 |
| 식별자 | 사용자·주문·티켓 ID 가 구간을 넘어 이어지는가 | 구간마다 새 ID 를 만들어 추적이 끊긴다 |
| 시각·시간대 | 타임스탬프의 시간대·형식·시계 동기화 | UTC 와 KST 혼용으로 SLA 계산이 어긋난다 |
| 오류·재시도 | 오류 코드 매핑, 재시도 정책, 멱등성 | 양쪽이 모두 재시도해 이중 결제가 난다 |
| 타임아웃 | 상·하류 타임아웃의 대소 관계 | 상류가 더 짧아 하류 성공을 실패로 기록한다 |
| 버전·변경 | 한쪽의 변경이 다른 쪽에 통지되는가, 하위 호환 | 공급자 정기 배포가 통지 없이 계약을 깬다 |
| 티켓 연동 | 상태·우선순위·타임스탬프 매핑 | 상태 값 개수가 달라 임의로 뭉개진다 |
시험 방법 자체는 레슨 8 과 같다. 다만 양쪽 시스템을 동시에 보지 못한다 는 제약이 붙는다. 공급자 환경에 접근할 수 없으면 세 가지로 대응한다.
- 계약 시험(contract testing) — 양쪽이 합의한 스키마·예시 요청·응답을 문서로 고정하고, 각자 자기 쪽에서 그 문서에 맞춰 시험한다. 상대 시스템 없이도 계약 위반을 잡는다.
- 합성 거래(synthetic transaction) — 전 구간을 통과하는 시험용 거래를 주기적으로 흘린다. 레슨 9 의 합성 모니터링을 공급자 경계에 적용한 것이다.
- 연결 시험 창(joint test window) — 통합 시험을 위한 합동 시험 시간을 계약에 시간 단위로 명시 한다. 명시하지 않으면 "일정상 어렵다"가 답이 된다.
그리고 SIAM 환경에는 QA 고유의 산출물이 하나 더 있다. 경계 목록 이다. 서비스 하나의 전 구간을 그리고, 공급자가 바뀌는 지점마다 번호를 붙이고, 번호마다 (1) 누가 시험하는가 (2) 무슨 증거가 남는가 (3) 지금 미검증인가 를 적는다. 이 표에서 "아무도"라고 적힌 줄이 다음 장애의 위치다.
실무에서 왜 필요한가
공공·금융·대기업 IT 운영에서 단일 공급자 환경은 드물다. 클라우드 한 곳, SaaS 여럿, SI 사업자 한둘, 운영 위탁사 한 곳이 섞인 것이 보통인데 운영 체계는 대개 단일 공급자 시절의 문서를 그대로 쓴다. 그래서 구간별로는 다 녹색인데 사용자는 아픈 상태가 상시화된다.
SIAM 을 공부한다는 것은 새 프레임워크를 하나 더 외우는 일이 아니다. "이 장애의 주인은 누구인가" 와 "이 약속의 합이 맞는가" 두 질문을 계약·측정·절차로 옮기는 일이다. 조직에 SIAM 이라는 말이 없어도 질문은 그대로 유효하다.
품질 담당자에게 중요한 이유가 하나 더 있다. 다중 공급자 환경에서는 품질 요구사항이 계약 조항이 되지 않으면 존재하지 않는다. 사내 개발팀에는 "이렇게 해 주세요"가 통하지만 계약으로 묶인 상대에게는 통하지 않는다. 그래서 SIAM 환경의 QA 는 조달 문서 검토에 참여해야 한다.
채용시장에서의 위치
"벤더 관리", "다중 공급사 운영", "서비스 통합" 이 적힌 공고는 대개 공공·금융·대형 제조의 IT 운영 조직이거나 통합자 역할을 수주한 IT 서비스 사업자다. 평가되는 것은 도구가 아니라 문서 다 — SLA·OLA 대응표, 에스컬레이션 매트릭스, 경계 목록, 공급자 성과 보고 양식. 면접에서는 보통 "공급자끼리 책임을 미룬 상황을 어떻게 끝냈나요"를 묻는다. 판정 권한과 이관 시계를 말할 수 있으면 대화의 층이 달라진다.