같은 결제 장애, 두 조직.
조직 A는 사용자가 "결제가 안 돼요"라고 전화하면 그 전화를 받은 사람이 그때그때 처리합니다. 어떤 날은 인프라 담당이, 어떤 날은 옆자리 개발자가 받습니다. 기록은 제각각이고, 누가 책임자인지 불분명하며, 같은 장애를 두 사람이 동시에 만지다 충돌합니다.
조직 B는 다릅니다. 모든 신고는 서비스데스크(1선) 로 들어가 티켓이 열립니다. 1선이 5~10분 안에 못 풀면 운영팀(2선), 그래도 안 되면 인프라·DBA(3선), DB 엔진 버그로 의심되면 벤더(4선) 로 — 정해진 경로로 넘어갑니다. P1 장애라면 동시에 운영관리자에게 보고가 올라가고, 야간이면 온콜 당번이 책임을 집니다.
A는 "사람이 어떻게든 처리"하고, B는 "조직이 책임지고 처리"합니다. 이 모듈은 B의 구조 — IT 운영 조직의 계층·역할·에스컬레이션 경로, 그리고 한국 현업의 원청-협력사 R&R — 를 정리합니다.
- 1서비스데스크(1선)·운영팀(2선)·개발/인프라/DBA/네트워크(3선)·벤더(4선)의 계층과 각 선의 책임을 구분해 설명할 수 있다
- 2기능적 에스컬레이션과 계층적 에스컬레이션의 차이를 알고, 신고를 올바른 선·경로로 흘려보낼 수 있다
- 3NOC(관제)·온콜·교대근무(shift)·L1/L2/L3 티어의 개념과 목적을 자기 말로 정의할 수 있다
- 4운영관리자·상담원·시스템 엔지니어·PMO·벤더 엔지니어 등 핵심 직무가 무엇을 책임지는지 매핑할 수 있다
- 5한국 SI/SM 현장의 원청-협력사 구조에서 누가 접수·조치·승인·보고를 맡는지 RACI로 정리할 수 있다
IT 운영 조직은 왜 '계층'으로 나뉘는가
모두가 모든 걸 하면, 아무도 책임지지 않는다
신고 한 건이 들어왔을 때 "아무나 처리"하는 조직은 빠른 것 같지만 세 가지가 무너집니다 — 기록(누가 무엇을 했는지 모름), 책임(누구 차례인지 모름), 전문성(쉬운 일에 비싼 전문가가 붙음). 그래서 IT 운영은 '난이도와 권한'에 따라 계층(tier/line) 으로 나눕니다.
핵심 원리는 두 가지입니다.
- 단일 접점(SPOC, Single Point of Contact): 사용자는 어디로 신고해야 할지 고민하지 않습니다. 모든 신고는 1선(서비스데스크) 한 곳으로 들어갑니다.
- 선별과 위임(triage & escalation): 1선이 풀 수 있으면 거기서 끝냅니다(이걸 못 하면 전문가가 단순 문의에 매달립니다). 못 풀면 정해진 기준에 따라 윗선으로 넘깁니다.
흔히 '선(線)'과 'L(Level/Layer) 티어'를 섞어 부릅니다. 한국 현업에서는 1선/2선/3선, 글로벌·도구(ServiceNow 등)에서는 L1/L2/L3로 부르는데, 가리키는 것은 거의 같습니다.
| 계층 | 통칭 | 누가 | 주 책임 | 입력 |
|---|---|---|---|---|
| 1선 | L1 / 서비스데스크 | 상담원·접수 담당 | 접수·기록·분류·1차 대응·에스컬레이션 | 사용자 신고 |
| 2선 | L2 / 운영팀 | 시스템 운영자·SM 엔지니어 | 시스템 레벨 조치, 운영 절차 실행, 모니터링 대응 | 1선 에스컬레이션, 알람 |
| 3선 | L3 / 전문팀 | 개발자·인프라·DBA·네트워크 | 근본 원인·코드·아키텍처 레벨 해결 | 2선 에스컬레이션 |
| 4선 | L4 / 벤더 | 제조사·솔루션사 엔지니어 | 제품 버그·라이선스·하드웨어 등 공급자 영역 | 3선 에스컬레이션 |
위로 갈수록 전문성·권한·비용이 커지고, 처리 건수는 줄어듭니다(피라미드 형태). 잘 설계된 조직은 대부분의 신고를 1선에서 끝내고, 소수의 어려운 것만 위로 올립니다.
그림: 사용자 신고는 1선으로 들어와 못 풀면 위로 기능적 에스컬레이션되고, 영향이 커지면 관리자에게 계층적 에스컬레이션이 동시에 진행된다.
1선부터 4선까지 — 각 선이 실제로 하는 일
각 선의 경계를 구체적인 행동으로 봅니다. "결제가 느리다"는 같은 신고가 선을 타고 내려가는 모습입니다.
| 선 | 한국 통칭 | "결제가 느리다"에 대한 행동 | 못 풀면 |
|---|---|---|---|
| 1선 | 서비스데스크 | 티켓 생성, 영향(전체/일부)·긴급도 확인, 알려진 조치(캐시·세션 안내) 시도, 우선순위 부여 | 2선으로 |
| 2선 | 운영팀(SM) | 서버 자원·로그 확인, WAS 재기동, 배치 상태 점검, 운영 매뉴얼대로 1차 시스템 조치 | 3선으로 |
| 3선 | 개발/인프라/DBA | 슬로우쿼리·인덱스·코드 병목 분석, 설정 변경, 근본 원인 수정(변경관리로) | 4선으로 |
| 4선 | 벤더(제조사) | DB 엔진 버그·스토리지 펌웨어·라이선스 한계 등 제품 자체 문제 처리 | (공급자 SLA) |
여기서 자주 헷갈리는 두 가지를 짚습니다.
- 2선 vs 3선: 2선은 '정해진 운영 절차'로 시스템을 다룹니다(재기동·점검·복구 매뉴얼 실행). 3선은 '절차에 없는 것'을 만들어 냅니다(코드 수정·아키텍처 변경·인덱스 설계). 한쪽은 운영(Operation), 한쪽은 엔지니어링(Engineering)에 가깝습니다.
- 3선 vs 4선: 3선은 '우리가 통제할 수 있는 것'까지(우리 코드·우리 설정), 4선은 '우리가 통제할 수 없는 것'(제조사 제품 내부)입니다. 4선으로 넘어가면 우리 손을 떠나 공급자 계약·SLA의 영역이 됩니다.
에스컬레이션 — 넘기는 데에도 규칙이 있다
기능적 에스컬레이션 vs 계층적 에스컬레이션
에스컬레이션은 "내가 못 푸니 떠넘긴다"가 아니라, 정해진 기준에 따라 적절한 쪽으로 흘려보내는 통제된 행위입니다. 방향이 두 가지입니다.
- 기능적(functional) 에스컬레이션 — 옆/위의 전문가에게: 더 높은 기술 전문성이나 권한이 필요해서 넘깁니다. 1선 → 2선 → 3선 → 4선이 이 방향입니다. "지식이 부족해서" 넘기는 것.
- 계층적(hierarchical) 에스컬레이션 — 관리자·의사결정자에게: 시간이 너무 걸리거나 영향이 너무 커서 '보고·결정·자원 투입'이 필요해 넘깁니다. 상담원 → 운영관리자 → 임원 방향. "권한·결정이 필요해서" 넘기는 것.
이 둘은 동시에 일어날 수 있습니다. 전사 결제 중단(P1)이라면, 기술적으로는 3선/벤더에 기능적 에스컬레이션을 하면서, 동시에 운영관리자·CIO에게 계층적 에스컬레이션(보고)을 합니다. 한쪽은 '고치는 라인', 한쪽은 '알리고 결정하는 라인'입니다.
에스컬레이션의 트리거(언제 넘기나) 는 보통 이렇게 정합니다.
| 트리거 종류 | 예시 기준 | 어디로 |
|---|---|---|
| 시간 초과 | "1선 15분 내 미해결" | 2선(기능적) |
| 난이도 | "운영 매뉴얼 밖, 코드/설정 변경 필요" | 3선(기능적) |
| 제품 한계 | "제조사 제품 자체 결함 의심" | 4선/벤더(기능적) |
| 영향 확대 | "전사·핵심서비스·SLA 위반 임박" | 운영관리자(계층적) |
그림: 한 장애에서 에스컬레이션은 '고치는 라인'(기능적)과 '알리는 라인'(계층적)으로 동시에 흐른다.
NOC · 온콜 · 교대근무 — 24x7을 떠받치는 장치들
서비스는 사람이 자는 동안에도 돌아갑니다. 그래서 운영 조직은 '시간'을 커버하는 장치를 둡니다.
- NOC(Network Operations Center, 관제센터): 사용자의 신고를 기다리는 서비스데스크와 달리, NOC는 시스템의 신호(모니터링 알람·이벤트·임계치) 를 24x7 대시보드로 감시합니다. 사용자가 신고하기 전에 이상을 포착해 선제적으로 인시던트를 띄우는 게 목적입니다. 입력이 '사람'이 아니라 '기계'라는 점에서 서비스데스크와 다릅니다(역할이 겹쳐 한 팀이 겸하기도 함).
- 온콜(on-call): 정규 근무 외(야간·주말)에 "긴급 호출이 오면 정해진 시간 내 응답·대응할 책임을 진 당번". 상주하지 않지만 책임은 집니다. 누가 지금 당번인지(로테이션), 안 받으면 누구에게 넘어가는지(에스컬레이션·콜트리)를 함께 정합니다.
- 교대근무(shift): 24x7 상주가 필요한 NOC·콜센터형 운영은 인력을 주간/야간/심야로 나눠 돌립니다(예: 3교대). 교대 시 빠지면 안 되는 것이 인수인계(handover) — 진행 중 장애·주의 대상·예정 작업을 다음 조에 넘깁니다.
- L1/L2/L3 티어: 앞서 본 1/2/3선과 같은 개념입니다. 도구·글로벌 문서에서는 티어(Tier)·레벨(Level)로 부릅니다.
핵심 감각: 이 장치들은 모두 "지금 이 순간, 누가 책임자인가" 를 한순간도 비우지 않기 위한 것입니다. 장애가 났는데 "내 차례인 줄 몰랐다"가 나오면 조직 설계가 실패한 것입니다.
누가 무엇을 하는가 — 핵심 직무
운영 조직의 주요 역할(R&R)
같은 '운영'이라도 직무에 따라 보는 것이 다릅니다. 한국 현업 호칭을 병기합니다.
| 직무 | 영문/통칭 | 무엇을 책임지나 | 보통 어느 선 |
|---|---|---|---|
| 운영관리자 / 서비스 오너 | Operations Manager / Service Owner | 서비스 품질(SLA)·우선순위·자원·대외 보고·계층적 에스컬레이션 수신 | 관리 |
| 서비스데스크 상담원 | Service Desk Agent | 접수·기록·분류·1차 응대·사용자 커뮤니케이션 | 1선 |
| 시스템 엔지니어 / 운영자 | System Engineer / SM Engineer | 서버·OS·미들웨어 운영, 매뉴얼 기반 조치, 모니터링 대응 | 2선 |
| 인프라/DBA/네트워크 엔지니어 | Infra / DBA / Network Engineer | 인프라·DB·네트워크의 근본 조치·설계·변경 실행 | 3선 |
| 개발자(유지보수) | Maintenance Developer | 애플리케이션 코드 레벨 원인 분석·수정 | 3선 |
| PMO | Project Management Office | 프로젝트·운영 전환의 일정·범위·산출물·이슈/리스크 관리·보고 취합 | 관리(횡단) |
| 벤더 엔지니어 | Vendor Engineer | 제조사 제품의 버그·패치·기술지원(공급자 SLA 범위) | 4선 |
특히 PMO는 한 선에 속하기보다 횡단(cross-cutting) 입니다. 운영 안정화나 신규 구축, '운영 이관(전환)' 같은 프로젝트성 활동에서 일정·이슈·리스크·산출물·보고를 가로질러 관리합니다.
한국 현업 — 원청·협력사 구조와 운영 이관
발주사(원청)와 운영사(협력사), 그리고 R&R
한국 SI/SM 현장의 운영 조직은 대개 두 회사가 한 팀처럼 움직입니다.
- 원청(발주사 / 그룹사 IT): 시스템의 '주인'. 예산·계약·승인·대외 책임을 가집니다. 발주사 IT 담당자(또는 그룹 IT서비스사)가 서비스 품질을 '관리'합니다.
- 협력사(하도급 운영사 / SM 업체): 상주 인력을 투입해 실제 운영 실무(서비스데스크·시스템 운영·모니터링·1차 조치·문서 작성)를 '수행'합니다.
여기서 가장 중요한 경계는 "수행은 협력사, 책임·승인·대외 보고는 원청" 이라는 점입니다. 구체적으로:
| 활동 | 누가 수행(실행) | 누가 승인/책임 |
|---|---|---|
| 사용자 신고 접수·기록 | 협력사(상주 서비스데스크) | — |
| 인시던트 1차 조치 | 협력사 운영 엔지니어 | 원청(SLA 책임) |
| 운영 시스템 변경(패치·배포) | 협력사가 작업 수행 | 원청이 변경 승인 |
| 장애보고서 작성 | 협력사 | 원청이 검토·확정 |
| 경영진·고객 대외 보고 | (협력사 초안) | 원청이 보고 |
이 경계를 흐리는 것 — 특히 협력사가 원청 승인 없이 운영 시스템을 임의 변경하는 것 — 은 한국 현업에서 사고와 계약 분쟁의 단골 원인입니다. "되겠지 싶어 바로 적용"이 아니라 "신청 → 승인 → 작업 → 보고"가 원칙입니다.
운영 이관(전환) — 구축이 끝나면 운영으로 넘긴다
신규 시스템을 구축(SI) 한 뒤에는 그것을 운영(SM) 으로 넘기는 단계가 있습니다. 이를 운영 이관 또는 운영 전환(transition) 이라고 합니다.
이관 시 넘겨야 하는 것: 운영 매뉴얼·구성도·계정/권한·모니터링 지표·에스컬레이션 연락처(콜트리)·알려진 이슈(Known Error)·SLA 정의. 이 인수인계가 부실하면 "만든 사람은 떠났고, 운영하는 사람은 모르는" 공백이 생깁니다. 그래서 이관은 보통 안정화 기간(병행 운영) 을 두고, 구축팀과 운영팀이 한동안 함께 대응한 뒤 정식으로 책임을 넘깁니다.
직접 해보기 — 분류와 R&R 판단
아래 5건을 (1) 처음 받는 선과 (2) 못 풀 때 넘길 선/대상, (3) 기능적인지 계층적 에스컬레이션인지로 정리해 보세요. 정답은 ObserveBlock에 있습니다.
A. "마우스가 안 움직여요." (개인 1명, 업무 약간 지장)
B. "전사 그룹웨어 로그인 불가." (오전 9시, 전 직원)
C. "특정 화면에서만 저장 시 에러 — 코드 문제로 보임." (운영팀이 로그 확인 후)
D. "DB 이중화 솔루션이 장애 — 제조사 패치가 필요할 듯." (DBA 분석 후)
E. "협력사가 야간에 결제 서버 설정을 바꾸려 한다." (점검 예정)
각 건마다 '누가 접수하고, 누가 조치하고, 누가 승인/보고하는가'를 한 줄로 적어 보세요.
판단: 선(1~4) / 에스컬레이션 종류- A = 1선(서비스데스크)에서 접수·처리 가능성 높음. 단순 단말 문제는 1선/현장지원에서 종결. 영향 1명·긴급도 낮음 → 우선순위 낮게, 기록은 남긴다
- B = 1선 접수 즉시 P1 판단 → 2선/3선으로 기능적 에스컬레이션 + 운영관리자에게 계층적 에스컬레이션(보고) 동시 진행. 전사 영향이므로 보고 라인이 핵심
- C = 2선이 1차 확인 후 코드 레벨이므로 3선(개발/유지보수)으로 기능적 에스컬레이션. 근본 수정은 변경관리 절차로 반영
- D = 3선(DBA)이 분석했으나 제품 자체 결함 → 4선(벤더)으로 기능적 에스컬레이션. 이 시점부터는 공급자 SLA·지원 채널의 영역
- E = 협력사가 수행 주체이지만 운영 시스템 변경이므로 원청에 변경 신청 → 원청 승인 후 작업 → 작업 후 보고. 협력사 임의 변경은 금지
- 핵심 감각: 같은 "장애"라도 (1) 어느 선의 전문성이 필요한가(기능적) (2) 누구의 결정·보고가 필요한가(계층적) (3) 누가 승인 권한을 쥐고 있는가(원청/협력사)를 분리해서 본다
현장에서 자주 보는 함정
증상 1 — 1선 우회: 사용자(또는 임원)가 친한 인프라 엔지니어에게 카톡·전화로 직접 장애를 알립니다. 빠른 것 같지만, 티켓이 없어 기록·통계·재발분석이 사라지고, 3선 엔지니어는 근본 작업 대신 단순 문의에 끌려다니며, 같은 장애를 다른 사람이 또 만집니다.
증상 2 — 협력사 임의 변경: 협력사 엔지니어가 "금방 되겠지" 하고 원청 승인 없이 운영 서버 설정을 바꿨다가 장애가 납니다. 책임 소재·복구·계약 분쟁이 한꺼번에 터집니다.
원인: 두 경우 모두 정해진 경로(SPOC·에스컬레이션·승인 절차)를 사람의 편의로 우회한 것입니다. 조직 설계가 있어도 지켜지지 않으면 없는 것과 같습니다.
해결 방향:
- 모든 신고는 반드시 1선·티켓을 통과하게 한다(직접 연락이 와도 "티켓 먼저"로 되돌린다).
- 에스컬레이션 트리거(시간·난이도·영향)를 문서화해 누구나 같은 기준으로 넘기게 한다.
- 운영 변경은 예외 없이 신청 → 승인(원청) → 작업 → 보고 순서. 긴급해도 긴급변경(emergency change) 절차로 사후 승인까지 남긴다.
- 임원·VIP 신고도 별도 우회가 아니라 우선순위(P1) 부여로 흡수한다.
조직 계층과 절차는 관료주의가 아니라, "누가 해도 같은 품질, 책임이 끊기지 않는 운영"을 위한 장치입니다.
이 트랙이 향하는 자리 — 발주사 IT 운영 담당, SM 서비스 운영관리자, PMO 보조 — 는 대부분 직접 서버를 만지기보다 "이 일을 누가, 어느 선에서, 어떤 권한으로 처리·승인·보고하는가"를 설계하고 통제합니다.
한국 현업에서 당신은 높은 확률로 원청(발주사) 측 관리자이거나, 그 사이에서 조율하는 PMO 자리에 섭니다. 그러면 협력사 엔지니어가 실제 손을 움직이더라도, 변경 승인·SLA 준수·대외 보고의 책임은 당신에게 옵니다. 그래서 "에스컬레이션 경로가 명확한가", "콜트리·온콜 당번이 비어 있지 않은가", "협력사가 임의로 운영을 바꾸지 않게 승인 절차가 도는가", "운영 이관 때 인수인계가 부실하지 않은가"를 점검하는 것이 일상 업무가 됩니다.
면접에서도 "장애가 났을 때 어떻게 대응하느냐"를 물으면, 손기술이 아니라 "접수→분류→우선순위→에스컬레이션→보고→재발방지"라는 조직적 흐름으로 답하는 사람이 관리 직무 적합자로 보입니다. 기술을 아는 관리자는 협력사와 대등하게 대화하고, "조치했습니다"라는 보고가 진짜인지 가려냅니다.
관련 모듈로 더 깊이:
- 서비스 데스크 — 이 조직의 1선, 사용자 신고가 가장 먼저 닿는 단일 접점이 어떻게 구성되는가
- 우선순위와 에스컬레이션 — 1선~3선 에스컬레이션 경로를 우선순위와 함께 규칙으로 만드는 법
다음 모듈에서는 이 조직과 절차를 하나의 표준 체계로 묶은 글로벌 프레임워크 — ITIL 4의 전체 구조(서비스 가치 시스템, 가이딩 원칙, 거버넌스)를 한 장의 지도로 정리합니다.