새벽 2시, 결제가 멈췄습니다.
운영팀이 로그를 까보니 우리 서버는 멀쩡합니다. 멈춘 건 결제를 대신 처리해 주는 외부 PG(결제대행) 쪽이었습니다. 전화를 걸었더니 "정기 점검 중이었고, 새벽 시간대는 계약상 가용성 보장 구간이 아니다"라는 답이 돌아옵니다.
발주사 IT 담당은 다릅니다. "우리 계약서엔 결제 서비스 99.9%라고 적혀 있는데요. 그 PG가 누구든, 그건 당신들이 데려온 협력사 아닙니까?"
여기서 두 가지가 동시에 드러납니다. 첫째, 우리가 고객에게 한 약속(SLA)은 우리가 데려온 외부 공급자의 계약(UC)이 받쳐주지 못하면 그냥 깨집니다. 둘째, 실제 작업을 외부가 했더라도 발주사에 대한 책임은 계약 당사자인 우리에게 있습니다. 책임은 하도급 사슬을 따라 아래로 흘러내리지 않습니다.
이 모듈은 서비스에 관여하는 외부 공급자 — 클라우드, SaaS, 솔루션 벤더, 운영 외주, 그리고 한국 특유의 다단계 협력사 — 를 어떻게 계약과 SLA로 통제하는지를 다룹니다. 외부에 맡기는 것은 책임을 넘기는 것이 아니라, 책임지는 방식을 설계하는 일입니다.
- 1공급자 관리의 목적(서비스 가치를 외부 의존 속에서도 지키는 것)을 설명할 수 있다
- 2공급자를 전략/전술/상품 유형으로 구분하고 관계 강도를 다르게 가져가는 이유를 말할 수 있다
- 3UC(공급자 계약)가 SLA·OLA를 떠받쳐야 한다는 정렬 원리와, 못 받칠 때 SLA가 깨지는 구조를 설명할 수 있다
- 4공급자 성과를 측정 가능한 지표로 정기 평가하는 방법과 산출물(평가표)을 만들 수 있다
- 5공급자 종속(lock-in)·단일 공급자 리스크와 출구 전략을, 한국 다단계 하도급 책임 구조와 연결해 판단할 수 있다
왜 공급자를 따로 '관리'해야 하는가
외부에 맡겨도 가치는 우리 책임으로 남는다
서비스는 혼자 만들어지지 않습니다. 클라우드(IaaS), 결제 PG, 메일 발송 SaaS, 인증 솔루션 벤더, 야간 운영을 맡은 외주 — 거의 모든 실제 서비스는 외부 공급자들의 조합 위에서 돌아갑니다.
문제는, 고객은 그 조합을 모른다는 것입니다. 고객은 '결제 서비스'를 받을 뿐, 그 안에 PG가 누구고 클라우드가 어디인지 관심 없습니다. 그래서 외부 공급자가 무너지면 고객이 느끼는 건 "당신들 서비스가 안 된다"입니다.
공급자 관리(supplier management)의 목적은 한 문장입니다: 외부 의존 속에서도 우리가 고객에게 약속한 서비스 가치를 지키는 것. 외주를 줬다고 책임이 사라지지 않습니다. 오히려 외부가 많아질수록, 그것들을 계약·SLA·평가로 통제하는 일이 운영의 핵심이 됩니다.
| 흔한 오해 | ITSM의 시각 |
|---|---|
| "외주를 줬으니 그쪽 책임" | 대외 서비스 책임은 계약 당사자(우리)에게 남는다 |
| "잘 돌아가니 관리할 게 없다" | 무사고는 운(運)이 아니라 관리의 결과여야 한다 |
| "계약서는 법무가 보는 것" | UC는 SLA를 떠받치는 운영 문서, 운영자가 봐야 한다 |
| "벤더가 알아서 해준다" | 정렬·평가·출구 전략이 없으면 종속만 깊어진다 |
공급자도 다 같은 공급자가 아니다 — 유형 구분
전략 · 전술 · 상품 공급자
모든 공급자를 똑같은 강도로 관리할 수는 없습니다. 자원이 한정돼 있으니, 서비스에 미치는 영향과 대체 가능성에 따라 관계 강도를 다르게 가져갑니다.
| 유형 | 성격 | 예 | 관계 관리 방식 |
|---|---|---|---|
| 전략(strategic) 공급자 | 핵심 서비스의 근간, 대체가 어렵고 장기 파트너 | 주력 클라우드(AWS/Azure), 핵심 코어뱅킹 솔루션 벤더 | 임원급 정기 거버넌스, 로드맵 공유, 깊은 신뢰·상호 투자 |
| 전술(tactical) 공급자 | 중요하지만 대체 가능, 상거래 관계 | 결제 PG, 모니터링 SaaS, 운영 외주(SM) 협력사 | SLA·UC 기반 정기 성과 평가, 분기 리뷰, 교체 카드 유지 |
| 상품(commodity) 공급자 | 표준화된 저관여 품목, 쉽게 대체 | 일반 SMS 발송, 사무용 SaaS, 표준 라이선스 | 가격·기본 SLA 중심, 최소 관리, 다(多)공급자 |
핵심은 **차등(差等)**입니다. 상품 공급자에 임원 거버넌스를 붙이면 낭비고, 전략 공급자를 가격만으로 매년 갈아치우려 하면 서비스가 흔들립니다. "이 공급자가 무너지면 어떤 서비스가 어떻게 되는가"를 먼저 묻고, 그 답이 클수록 관계를 깊고 단단하게 가져갑니다.
한국 SI/SM 맥락에서 운영을 떠받치는 하도급 협력사는 대개 전술 공급자입니다 — 핵심 인력을 제공하므로 중요하지만, 계약·평가·교체의 대상으로 관리해야 한다는 뜻입니다.
그림: 모든 공급자를 같은 강도로 관리할 수 없다 — "이 공급자가 무너지면 어떤 서비스가 어떻게 되나"의 답이 클수록 관계를 깊게, SI/SM 운영 협력사는 대개 전술 공급자다.
UC가 SLA를 떠받쳐야 한다 — 약속의 정렬
UC · SLA · OLA의 정렬 — 한 군데만 느슨해도 SLA가 깨진다
서비스 수준 관리에서 배운 세 약속을 공급자 관점에서 다시 봅니다.
- SLA(Service Level Agreement): 우리 ↔ 고객(발주사). 우리가 고객에게 한 약속.
- OLA(Operational Level Agreement): 우리 조직 내부 팀 간 약속(예: 운영팀 ↔ 인증 플랫폼팀).
- UC(Underpinning Contract): 우리 ↔ 외부 공급자. 외부에 맡긴 부분의 계약상 약속.
핵심 원리는 단순합니다. SLA는 그것을 떠받치는 모든 OLA·UC가 SLA 이상으로 단단할 때만 성립합니다. 결제 SLA가 99.9%인데 그 경로에 99.5%짜리 PG UC가 끼어 있으면, PG가 계약을 100% 지켜도 우리 서비스 상한은 99.5%입니다. 약속이 설계 단계에서 이미 깨진 것입니다.
| 약속 | 당사자 | 정렬되지 않으면 |
|---|---|---|
| SLA | 우리 ↔ 고객 | (받침이 약하면) 우리가 위반자가 된다 |
| OLA | 내부 팀 간 | 내부 한 팀의 점검·지연이 SLA를 깬다 |
| UC | 우리 ↔ 외부 공급자 | 공급자가 자기 계약 다 지켜도 SLA가 깨질 수 있다 |
그래서 새 서비스를 설계하거나 공급자를 들일 때, 운영자는 **"이 UC가 우리 SLA를 받치는가?"**를 숫자로 점검해야 합니다. 가용성뿐 아니라 대응·해결시간, 점검(maintenance window) 시간대, 보안·데이터 처리 조건까지 — SLA 항목 하나하나에 대응하는 UC 조항이 더 느슨하지 않은지 줄을 맞춰 보는 것입니다. 이 점검표는 이 모듈의 핵심 산출물입니다.
그림: SLA는 그것을 받치는 모든 UC가 SLA 이상으로 단단할 때만 성립하며, 다단계 하도급에서도 대외 책임은 계약 당사자(원청)에게 남는다.
직접 해보기 — UC가 SLA를 받치는지 점검하고 공급자를 평가하기
아래는 결제 서비스 SLA와, 그 경로에 들어가는 외부 PG 공급자의 UC를 나란히 둔 점검표 골격입니다. 각 행에서 UC가 SLA를 받치는지(OK) 또는 **못 받치는지(위험)**를 판정해 보세요. 판정 기준은 단순합니다 — UC가 SLA와 같거나 더 강하면 OK, 더 느슨하면 위험입니다.
[UC–SLA 정렬 점검표 — 결제 서비스]
SLA 항목 우리 SLA(고객 약속) PG UC(공급자 계약) 판정
----------------- --------------------- ------------------------ ------
가용성 99.9% 99.5% ?
장애 대응 착수 15분 이내 30분 이내 ?
정기 점검 시간대 사전 고지 + 새벽만 "고지 의무 없음" ?
데이터 보관 위치 국내 "해외 리전 포함 가능" ?
보안 사고 통지 24시간 이내 "합리적 기간 내" ?
각 행이 왜 OK/위험인지 한 줄로 근거를 적고, 위험으로 판정된 행에 대해 "재협상 / 이중화 / 보강 설계 / 계약 명시" 중 어떤 대응을 할지 골라 보세요. 정답과 해설은 ObserveBlock에 있습니다.
각 SLA 항목 옆에 받치는 UC 조항을 적고, 느슨한 칸을 표시한다이번엔 운영을 맡은 협력사(전술 공급자)를 분기마다 평가할 공급자 평가 항목 표를 직접 설계해 봅니다. '느낌'이 아니라 측정 가능한 지표여야 갱신·페널티·교체 판단의 근거가 됩니다. 아래 골격을 채워 보세요.
[공급자 분기 성과 평가표 — 운영 협력사 B]
평가 항목 지표(측정 방법) 목표 실적 가중치
------------------ ------------------------- -------- ----- ------
SLA 달성 월별 SLA 리포트 달성률 ≥ 99.9% ? 30%
인시던트 대응 평균 대응시간(접수→착수) ≤ 15분 ? 15%
인시던트 해결 평균 해결시간(접수→정상화) ≤ 4시간 ? 15%
재발 방지 동일 원인 재발 건수/분기 0건 ? 15%
변경 안정성 변경 성공률(롤백 제외) ≥ 95% ? 10%
보안·산출물 준수 보안점검·문서 제출 준수율 100% ? 15%
------------------ ------------------------- -------- ----- ------
종합 등급 가중 합산 → S/A/B/C A 이상 ? 100%
이 표가 있으면 분기 리뷰에서 "잘하고 있다" 대신 "SLA 달성 99.7%로 목표 미달, 재발 2건 — 종합 B, 시정계획 요청"이라고 말할 수 있습니다.
합의된 지표로 분기 평가표를 만든다- 가용성: SLA 99.9% > UC 99.5% → 위험. PG가 계약을 다 지켜도 우리 SLA 상한이 99.5%로 내려간다. 대응: UC 재협상 또는 PG 이중화(다중 PG)
- 대응 착수: SLA 15분 < UC 30분 → 위험. 공급자가 느긋하게 30분을 써도 우리는 15분 약속을 못 지킨다. 대응: UC 재협상, 또는 1차 대응을 우리 인력이 직접 떠안도록 보강
- 점검 시간대: SLA는 사전 고지+새벽 한정, UC는 고지 의무 없음 → 위험. 공급자가 업무시간에 말없이 점검하면 SLA 위반. 대응: 점검창·사전 고지 의무를 UC에 명시
- 데이터 위치: SLA 국내, UC 해외 리전 가능 → 위험(계약·규제 리스크 포함). 대응: 국내 보관을 계약에 명시(특히 개인정보·금융 규제 대상)
- 보안 통지: SLA 24시간, UC "합리적 기간" → 위험. 모호한 표현은 분쟁 시 공급자에게 유리하게 해석된다. 대응: 구체적 시간(예: 24시간)으로 계약 명시
- 핵심 감각: 점검표에서 위험 칸이 하나라도 있으면 SLA는 이미 구조적으로 깨질 수 있다 — 위반이 터지기 전에 보이는 것이 이 표의 목적
- 평가표: 실적을 채우면 "잘한다/못한다"가 아니라 등급·가중점수로 나와, 갱신·페널티·교체를 객관적 근거로 결정할 수 있다 — 그리고 그 기록이 분쟁 때 입증 자료가 된다
현장에서 자주 보는 함정
증상: SLA가 깨진 장애의 원인이 우리가 데려온 PG, 혹은 협력사 B가 재하도급한 C에 있었습니다. 발주사 회의에서 "그건 PG 문제다", "그건 C가 한 작업이다"라는 말이 나오고, 발주사 담당의 표정이 굳습니다. 그 뒤로 보고를 믿지 않기 시작합니다.
원인: 두 가지가 겹쳤습니다. (1) 책임 구조에 대한 오해 — 발주사 입장에서 계약 상대는 원청이며, 하도급이 몇 단계든 대외 서비스 책임은 아래로 전가되지 않습니다. "C가 했다"는 발주사에게 의미 없는 변명입니다. (2) UC 정렬 부재 — 애초에 SLA를 받치는 UC를 하위 협력사까지 백투백(back-to-back)으로 맞춰 두지 않았기에, 책임을 내부적으로 물을 근거조차 없습니다.
해결 방향(공급자 관리의 핵심):
- 대외적으로는 원청이 책임진다. 발주사 앞에서 협력사를 가리키지 않는다. 복구·보고·재발방지의 단일 창구가 된다.
- 내부적으로는 UC/백투백 조항으로 책임을 정렬해 둔다. 우리 SLA와 같거나 강한 조건을 B·C의 UC에 걸어 두면, 위반 시 시정·구상(求償)을 객관적으로 물을 수 있다.
- 평가표·SLA 리포트로 공급자 성과를 데이터로 남긴다. 책임을 미루는 대신, 누가 무엇을 못 지켰는지 기록으로 정리한다.
- 핵심 기능이 한 공급자/한 협력사에 묶여 있으면 단일 공급자 리스크로 등록하고 대체·이중화를 검토한다.
공급자 관리는 "남 탓할 사람을 정해 두는 일"이 아니라, 우리가 책임지되 그 책임을 통제 가능하게 설계하는 일입니다.
한국 SI/SM 현장은 거의 항상 원청–하도급 다단계 구조입니다. 발주사가 원청 SI에 사업을 맡기고, 원청은 운영을 협력사에, 협력사는 다시 특정 모듈·인력을 재하도급합니다. 실제 키보드를 두드리는 사람은 사슬의 맨 아래일 때가 많지만, 발주사에 대한 서비스 책임은 계약 당사자인 원청·협력사 관리자에게 남습니다.
이 구조에서 관리 직무(원청 PM/PMO, 운영(SM) 관리자, 발주사 IT 담당)가 하는 일은 직접 작업이 아니라 공급자 사슬을 통제하는 것입니다 — 어떤 외부에 무엇을 맡길지(유형 구분), SLA를 받치도록 UC를 정렬했는지, 협력사를 정기적으로 평가하고 그 기록을 남기는지, 핵심 기능이 한 곳에 종속(lock-in)되어 협상력을 잃지 않았는지, 계약이 끝날 때 데이터와 운영을 안전하게 회수할 출구 전략이 있는지.
특히 한국 맥락에서 자주 깨지는 지점이 책임 미루기입니다. 장애 원인이 협력사에 있어도 발주사 앞에서 "협력사가 했다"고 말하는 순간 관리자는 신뢰를 잃습니다. 성숙한 관리자는 대외적으로 책임을 지고, 내부적으로는 UC·백투백 조항·평가표라는 통제 장치로 협력사에 시정과 책임을 묻습니다. 발주사 담당이라면 반대로, 원청이 하위 협력사 SLA를 백투백으로 정렬했는지·정기 평가를 하는지를 점검해 원청을 관리합니다.
기술을 아는 관리자는 공급자가 "그건 원래 어렵습니다", "새벽이라 보장 구간이 아닙니다" 같은 말로 책임을 회피할 때, UC 조항과 평가 데이터를 들어 대등하게 반박할 수 있습니다. 공급자 관리는 결국, 외부에 의존하면서도 서비스 가치의 주도권을 우리가 쥐는 기술입니다.
관련 모듈로 더 깊이:
- 서비스 수준 관리 — 공급자 UC를 SLA에 정렬해 외부 의존을 약속 수준으로 묶는 법
- PMO 운영과 벤더 관리 — 다단계 하도급 구조에서 PMO가 벤더를 평가·관리하는 실무
- IT 거버넌스·운영 KPI·지속적 개선(CSI) — 공급자 성과를 KPI로 측정해 거버넌스 보고로 연결하는 흐름
다음 모듈에서는 개별 서비스·공급자 관리를 넘어, 조직 전체가 IT 투자를 어떻게 방향 짓고 통제·평가하는지 — IT 거버넌스와 운영 KPI를 다룹니다.