SLA 정책을 어떻게 가져갈 것인가

결재가 며칠씩 묵힙니다. 누군가의 책상에서 멈춰 있습니다. SLA(처리 기한)를 시스템에 넣기로 했을 때 진짜 어려운 건 “며칠로 정할까”가 아니라 “기한을 넘긴 걸 누가, 어떤 기준으로 판단하고, 그래서 무엇을 할 것인가”였습니다. 이 글은 SLA가 알림이 아니라 거버넌스 설계임을 깨달은 과정입니다.

SLA·병목·준수율

용어: SLA (Service Level Agreement, 처리 기한 약속)

“이 일은 며칠 안에 처리한다”는 시간 기준입니다. 결재로 치면 “각 단계는 N시간 안에 결정한다” 같은 것입니다. 넘기면 “SLA 위반”입니다.

용어: 병목(bottleneck)

전체 흐름에서 가장 자주, 가장 오래 막히는 지점입니다. 강물이 좁은 데서 막히듯, 결재도 특정 단계·특정 사람에게서 반복적으로 멈춥니다.

용어: 준수율

전체 중 기한을 지킨 비율입니다. “이번 달 결재의 80%가 기한 내 처리됨” 같은 수치입니다.

숫자만으로는 SLA가 작동하지 않는다

SLA를 “24시간 넘으면 빨간불”처럼 단순 임계값으로 시작하는 건 쉽습니다. 그런데 그것만으로는 아무 일도 일어나지 않습니다. 빨간불이 켜져도 왜 막혔는지, 누가 책임인지, 다음에 뭘 해야 하는지를 사람이 다시 일일이 들여다봐야 한다면, SLA는 그냥 또 하나의 알림 소음이 됩니다. 빨간불이 많아질수록 사람은 그걸 무시하기 시작합니다.

그래서 처음부터 두 가지를 분리해서 생각해야 했습니다. 기계적으로 측정 가능한 것과 맥락을 읽어야 판단되는 것입니다. 이 둘을 섞으면 둘 다 망가집니다.

SLA를 작동시키려면 측정과 진단을 갈라야 합니다. 왼쪽(시간·건수)은 규칙·통계로 충분하고, 오른쪽(왜·정상인가)은 추론이 필요한 다른 층위의 일입니다. 이 둘을 한 덩어리로 묶으면 둘 다 부정확해집니다.

측정과 진단을 나눈 이유

단계별 소요 시간·병목 단계 탐지는 규칙과 통계로 충분합니다. 하지만 “왜 막혔고 무엇이 문제인가”를 사람이 읽을 수 있는 문장으로 설명하는 건 다른 층위의 일이라, 추론형 모델에 맡기는 서술형 진단을 따로 두는 쪽으로 설계했습니다. 실제로 이 서술형 진단 에이전트를 붙여 동작을 확인했습니다 — 단계별 통계가 아니라, 사람이 읽는 한 문단의 진단을 내놓습니다.

판단 기준을 무엇 단위로 쪼갤 것인가

SLA의 핵심은 “기준”입니다. 그리고 기준은 한 종류가 아니었습니다. 같은 SLA라도 무엇을 보느냐에 따라 잣대가 달라야 했습니다.

무엇을 보는가	어느 단위로 보는가	왜
병목 탐지	전사 기준	회사 전체에서 어느 단계가 가장 자주 막히는지를 봐야 우선순위가 나온다
준수율	결재 유형별	구매요청과 출장신청은 본질적으로 속도가 다르다 — 같은 잣대로 재면 둘 다 왜곡된다

이 구분이 없으면 “전체 평균 준수율 80%” 같은 숫자가 나오는데, 그 숫자는 빠른 결재와 느린 결재를 뭉뚱그려 아무것도 알려주지 않습니다. 빠른 결재가 99%고 느린 결재가 50%여도 평균은 그럴듯하게 80%로 보입니다. 평균 하나에 속는 것입니다. 기준을 무엇 단위로 쪼개느냐가 SLA 설계의 절반이었습니다.

예시 — 같은 “지연 3일”이 다르게 해석되는 경우

1. 구매요청이 3일 지연 — 보통 당일~익일 처리되는 유형입니다. 3일은 명백한 이상입니다. 빨간불.
2. 대규모 투자 품의가 3일 지연 — 원래 검토에 일주일이 걸리는 유형입니다. 3일은 정상 범위입니다. 빨간불을 켜면 오히려 소음입니다.

똑같은 “3일”인데 한쪽은 위반이고 한쪽은 정상입니다. 유형별 기준 없이 전사 임계값 하나로 보면, 둘 다 틀리게 판정합니다.

AI에게 진단을 시킬 때의 거버넌스 질문

서술형 진단을 외부 LLM에 맡기려면 피할 수 없는 질문이 생깁니다 — 결재자의 실명 같은 정보를 외부 모델에 보내도 되는가? 이건 기술 문제가 아니라 경영 판단입니다. 진단의 품질을 높이려고 맥락을 풍부하게 줄수록, 외부로 나가는 정보의 민감도가 올라갑니다. “누가 자꾸 늦는가”를 정확히 진단하려면 그 사람을 식별해야 하는데, 그 식별 정보가 곧 외부로 나가는 민감 정보입니다.

함정: 편리한 기능일수록 선을 먼저 그어야 한다

AI 진단은 분명 편리합니다. 그러나 “무엇을 외부에 내보내는가”라는 선이 먼저 그어지지 않으면, 편리함을 좇다 회사 정보가 통제 없이 흘러나갑니다. 그래서 SLA 진단은 단순한 기능이 아니라 정책 결정과 묶인 채로만 켤 수 있게 했습니다. 무엇을 보낼지, 응답에서 무엇을 가릴지(근거·마스킹), 그 판단을 누가 승인했는지를 함께 기록합니다.

이렇게 묶어 두면, AI 진단을 켜는 결정 자체가 책임자의 명시적 승인을 거칩니다. 외부 모델 활용은 “한 번 켜면 끝”이 아니라, “무엇을 외부로 보내기로 누가 결정했다”는 기록과 함께 켜집니다. 이 선이 먼저 그어져야 비로소 안전하게 도입할 수 있는 기능이었습니다.

SLA를 켜는 순서 — 거꾸로 하면 소음이 된다

정리하면, SLA를 시스템에 넣는 순서는 직관과 정반대입니다. 보통은 “며칠로 정할까”부터 시작하는데, 그건 사실 맨 마지막에 정할 일입니다. 우리가 거친 순서는 이랬습니다.

순서	무엇을 정하는가	거꾸로 하면
① 측정/진단 분리	무엇을 규칙으로, 무엇을 추론으로 볼지	빨간불만 늘고 이유는 없는 알림 소음
② 기준 단위 결정	병목=전사 / 준수율=유형별	”평균 80%” 같은 무의미한 숫자
③ 외부 전송 경계	무엇을 외부 모델에 보낼지·누가 승인할지	편의를 좇다 민감 정보 유출
④ 임계값(며칠)	유형별 기한	—(여기부터는 쉽다)

핵심은 ④가 가장 쉽고 가장 나중이라는 점입니다. 임계값은 운영하며 조정하면 됩니다. 그러나 ①~③을 건너뛰면, 아무리 임계값을 정교하게 잡아도 SLA는 소음 발생기로 끝납니다. 어려운 결정을 먼저, 쉬운 숫자를 나중에.

교훈

SLA는 “며칠”이라는 숫자가 아니라 판단 기준의 설계입니다. 첫째, 측정 가능한 것(소요·병목)과 맥락이 필요한 것(왜 막혔나)을 분리하세요 — 섞으면 둘 다 망가집니다. 둘째, 기준을 무엇 단위(전사 vs 유형별)로 쪼갤지 먼저 정하세요 — 평균 하나에 속지 마세요. 셋째, AI 진단을 붙일 땐 “무엇을 외부 모델에 보내는가”를 기능보다 먼저 결정하고, 그 결정을 기록하세요. SLA는 알림이 아니라 거버넌스입니다. 이 판단들은 결국 에이전트의 권한 경계와 한 몸입니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.