[ITSM] ITIL만 있는 게 아니다 — COBIT·ISO 20000·DevOps와 한국 현업 지형

🚨INCIDENT ALERT

HIGH

신입 운영자가 회의실에서 머리가 복잡해집니다.

본부장은 "우리도 ITIL 기반으로 운영체계를 잡자"고 하고, 보안팀장은 "올해 ISMS-P 인증 갱신이 걸려 있다"고 합니다. 옆 팀 PL은 "그건 COBIT 감사 항목이랑 엮어야 한다"고 하고, 개발 리더는 "어차피 DevOps로 가는데 ITIL 같은 무거운 절차가 발목 잡는 거 아니냐"고 받아칩니다.

같은 회의에서 ITIL·ISMS-P·COBIT·DevOps가 한꺼번에 튀어나옵니다. 신입은 속으로 묻습니다. "이게 다 같은 건가? 경쟁하는 건가? 우리가 뭘 골라야 하는 거지?"

답부터 말하면, 이들은 경쟁하지 않습니다. 충위와 목적이 다릅니다. 하나는 '잘 하는 법'(ITIL), 하나는 '경영-IT 정렬과 통제'(COBIT), 하나는 '인증 기준'(ISO/IEC 20000·ISMS-P), 하나는 '빠르게·자동화로 일하는 문화'(DevOps)입니다. 이 모듈은 그 지도를 그려, 회의에서 어떤 단어가 나와도 "그건 왜 꺼낸 거고, 우리가 무엇으로 답해야 하는가"를 분간하게 합니다.

이번 챕터에서 배울 것

1ITIL·COBIT·ISO/IEC 20000·DevOps/SRE/Agile가 각각 무엇을 위한 것인지 한 줄로 구분해 설명할 수 있다
2"모범사례 가이드 vs 거버넌스 프레임워크 vs 인증 표준 vs 일하는 문화"라는 층위 차이로 이들을 분류할 수 있다
3ITIL과 ISO/IEC 20000의 관계(실천 vs 인증), ITIL과 DevOps의 관계(통합)를 설명할 수 있다
4상황(경영 보고·운영 개선·외부 인증·빠른 배포)에 따라 어떤 체계를 꺼낼지 판단할 수 있다
5한국 기업·공공이 실제로 어떤 체계와 자격을 도입·요구하는 경향이 있는지 큰 그림을 그릴 수 있다

왜 하나가 아니라 여러 개인가

💡개념

목적이 다르면 도구도 다르다

IT 관리에 등장하는 이름들이 많아 보이는 이유는, 각자 다른 질문에 답하기 위해 만들어졌기 때문입니다. 서로 경쟁 상품이 아니라, 부엌의 칼·도마·계량컵처럼 역할이 다른 도구에 가깝습니다.

"서비스를 어떻게 잘 운영하지?" → ITIL (실천 가이드, 모범사례)
"IT가 경영 목표에 맞게, 통제·책임이 분명한가?" → COBIT (거버넌스)
"우리 체계가 일정 수준 이상임을 외부에 증명하려면?" → ISO/IEC 20000 (인증 표준)
"빠르게·자동화로·함께 일하는 문화는?" → DevOps / SRE / Agile

핵심은 **층위(layer)**입니다. 위에서부터 보면, 경영이 방향과 통제를 정하고(거버넌스), 그 안에서 서비스를 운영하며(실천), 그 운영 수준을 외부가 인증하고(표준), 일하는 방식 자체는 빠르고 협업적인 문화(DevOps)로 채웁니다. 하나를 고르는 게 아니라 겹쳐 쓰는 것이 정상입니다.

💡개념

ITIL — 서비스 관리 모범사례

ITIL(IT Infrastructure Library) 은 IT 서비스를 잘 관리하기 위한 모범사례(best practice) 모음입니다. 인시던트·문제·변경·요청·서비스수준(SLA) 같은 운영의 핵심 활동을 "이렇게 하면 대체로 잘 된다"는 형태로 정리한 가이드입니다.

성격: '무엇을·어떻게' 할지 알려주는 실천 가이드. 법이나 강제 규격이 아니라 참고 체계입니다.
최신 흐름: ITIL 4 에서 '서비스 가치 시스템(SVS)'과 '가이딩 원칙'을 중심으로 재구성되며, 뒤에 나올 DevOps·Agile·Lean의 가치를 흡수했습니다.
인증의 단위: 개인. 예를 들어 ITIL 4 Foundation 같은 자격은 사람이 시험을 봐서 따는 것입니다. (조직을 인증하는 게 아닙니다 — 이 점이 ISO/IEC 20000과 다릅니다.)

ITIL은 "정답을 강제"하지 않습니다. 그래서 조직마다 자기 상황에 맞게 테일러링(취사선택·조정) 해서 씁니다. 모범사례를 그대로 복붙하는 게 아니라, 필요한 부분만 골라 적용하는 것이 ITIL 4가 강조하는 태도입니다.

💡개념

COBIT — IT 거버넌스·관리 프레임워크

COBIT(Control Objectives for Information and Related Technologies) 은 IT 거버넌스와 관리를 위한 프레임워크입니다. 한 단계 위에서, 경영의 눈으로 IT를 봅니다.

핵심 질문: "IT가 경영 목표에 정렬되어 있는가?", "통제(control)와 책임이 명확한가?", "리스크는 관리되는가?"
강한 관점: 거버넌스·내부통제·감사·경영 보고. 그래서 감사인이나 경영진과 대화할 때 자주 등장합니다.
ITIL과의 관계: 충돌이 아니라 층위 차이. COBIT이 '무엇을 통제하고 누가 책임지는가(거버넌스)'를 정하면, ITIL은 그 안에서 '서비스를 어떻게 운영하는가(실천)'를 채웁니다.

쉽게 말해 COBIT은 "올바른 일을 하고 있는가(거버넌스)", ITIL은 "그 일을 잘 하고 있는가(실천)" 에 가깝습니다. 둘 다 필요한 질문입니다.

💡개념

ISO/IEC 20000 — 서비스 관리 국제 인증 표준

ISO/IEC 20000 은 IT 서비스 관리 시스템(SMS)에 대한 국제 인증 표준입니다. ITIL이 '실천 가이드'라면, ISO/IEC 20000은 그 실천이 일정 수준 이상인지를 외부 심사로 인증하는 기준입니다.

인증의 단위: 조직. 회사·사업부가 심사를 받아 "우리는 표준을 충족하는 서비스 관리 체계를 갖췄다"를 증명합니다. (개인 자격이 아닙니다.)
ITIL과의 관계: 흔히 "ITIL로 프로세스를 만들고, ISO/IEC 20000으로 인증받는다" 고 표현합니다. ITIL=실천 노하우, ISO/IEC 20000=충족 여부를 가리는 인증 기준.
왜 받나: 공공·대형 발주처가 입찰·계약에서 인증 보유를 요구하거나 가점을 주는 경우가 있어, 대외 신뢰·수주 경쟁력 목적이 큽니다.

여기서 자주 헷갈리는 짝을 정리하면: ITIL Foundation = 개인 자격, ISO/IEC 20000 = 조직 인증 입니다. "ITIL 인증받았다"는 말이 나오면, 사람이 딴 자격인지 조직 인증인지 되물어야 정확합니다.

💡개념

DevOps · SRE · Agile — 일하는 방식·문화

DevOps·SRE·Agile 은 프레임워크라기보다 일하는 방식과 문화에 가깝습니다.

DevOps: 개발(Dev)과 운영(Ops)의 벽을 허물고, 빌드·테스트·배포를 자동화(CI/CD) 해 변경을 빠르고 자주, 안전하게 흘려보내는 접근.
SRE(Site Reliability Engineering): 운영을 소프트웨어 엔지니어링 문제로 다뤄, 오류예산(error budget)·SLO 같은 지표로 신뢰성과 속도의 균형을 공학적으로 관리.
Agile: 큰 계획을 한 번에 던지지 않고 짧은 반복(스프린트) 으로 자주 만들고 피드백받아 방향을 조정하는 개발 철학.

ITIL과의 관계가 중요합니다. 과거의 무거운 절차 중심 운영과 빠른 배포 문화는 충돌하는 것처럼 보였지만, ITIL 4 는 가이딩 원칙(협업, 반복적 개선, 자동화 등)과 가치 사슬로 이 가치들을 명시적으로 통합했습니다. 그래서 현실의 모범 답안은 "둘 중 택일"이 아니라:

배포는 CI/CD로 빠르게(DevOps),
그 변경은 변경관리로 추적·통제(ITIL),
장애는 인시던트관리로 대응하고 포스트모템으로 학습(ITIL + SRE 문화),

처럼 결합하는 것입니다.

프레임워크들이 무엇으로 인증되는가를 세 부류로 나눠, ITIL 4와 Agile·Scrum은 사람이 시험을 보고 따는 개인 자격, ISO/IEC 20000은 회사가 외부 심사를 받는 조직 인증, COBIT·DevOps·SRE는 자격증보다 체계·문화·역량으로 갖추는 부류로 분류한 비교 구조

그림: 가장 헷갈리는 '인증 단위' — 개인 자격(ITIL·Scrum) vs 조직 인증(ISO 20000) vs 문화·역량(COBIT·DevOps·SRE).

프레임워크 한눈 비교 (필수 표)

💡개념

프레임워크 × 목적 × 인증 단위 × 언제 쓰나

아래 표가 이 모듈의 핵심 산출물입니다. 회의에서 어떤 이름이 나와도 이 표의 한 행으로 돌려놓을 수 있어야 합니다.

이름	무엇인가(성격)	핵심 목적	인증 단위	언제 꺼내나
ITIL (ITIL 4)	서비스 관리 모범사례 가이드	서비스를 어떻게 잘 운영할지	개인 자격(예: ITIL 4 Foundation)	운영 프로세스 정비·용어 통일·SLA/인시던트/변경 체계화
COBIT	IT 거버넌스·관리 프레임워크	경영-IT 정렬, 통제·책임·감사	(조직 차원 적용; 통제 체계 평가)	경영 보고·내부통제·감사·리스크 관점 정렬
ISO/IEC 20000	서비스 관리 국제 인증 표준	서비스 관리 체계 수준을 외부 인증	조직 인증	대외 신뢰 증명·입찰/계약 요건·수주 경쟁력
DevOps	일하는 방식·문화(자동화·협업)	빠르고 잦은, 안전한 변경 흐름	(인증보다 문화·역량)	CI/CD·배포 자동화·개발-운영 통합
SRE	운영의 공학화	신뢰성과 속도의 균형(SLO·오류예산)	(역량·직무)	가용성 목표 관리·장애 대응 공학화
Agile/Scrum	반복적 개발 철학	짧은 주기·피드백·적응	개인 자격(예: Scrum Master)	요구 변화가 큰 개발·점진적 인도

표를 보는 법: '인증 단위' 열이 특히 실수가 많은 곳입니다. ITIL·Scrum은 개인이 자격을 따고, ISO/IEC 20000은 조직이 인증을 받습니다. COBIT·DevOps·SRE는 "자격증을 따느냐"보다 "체계·문화·역량으로 갖추느냐"의 성격이 강합니다.

COBIT은 거버넌스 층위, ITIL은 실천 층위, ISO/IEC 20000은 인증 층위, DevOps·SRE·Agile은 문화 층위로 각각 목적과 인증 단위가 다르게 쌓여 서로 경쟁하지 않고 겹쳐 쓰이는 프레임워크 지형도

그림: 이름이 많아 보여도 "거버넌스(COBIT)·실천(ITIL)·인증(ISO 20000)·문화(DevOps)" 네 칸으로 나누면 정리된다 — 하나를 고르는 게 아니라 겹쳐 쓴다.

상황별로 무엇을 꺼낼까

이 요구에는 무엇으로 답하나

경영진이 'IT가 전략에 기여하는지, 통제·감사는 적절한지' 보고 싶어한다COBIT(거버넌스)통제목표·책임(RACI)·경영 정렬 관점으로 정리

인시던트·변경·SLA 같은 '운영 프로세스'를 일관되게 잡고 싶다ITIL(실천 가이드)필요한 프랙티스만 테일러링해 적용

입찰·계약에서 '서비스 관리 체계 인증'을 요구받았다ISO/IEC 20000(조직 인증)ITIL로 만든 프로세스를 인증 기준에 맞춰 정비

정보보호·개인정보보호 관리체계를 국내 제도로 인증받아야 한다(공공·금융 등)ISMS-P(국내 정보보호 인증)서비스 관리가 아니라 '정보보호' 초점 — 목적이 다름

배포가 느리고 개발-운영이 서로 떠넘긴다DevOps/SRE(문화·자동화)CI/CD·SLO 도입, 단 변경관리(ITIL)로 추적성 유지

요구사항이 자주 바뀌어 한 번에 다 설계하기 어렵다Agile/Scrum짧은 반복으로 인도·피드백, PM 트랙에서 심화

직접 해보기 — 회의 발언을 분류하기

1튀어나온 단어를 '층위'로 분류하기

아래 회의 발언 5건을 읽고, 각각이 어느 층위(거버넌스·실천·인증·문화)이며 어떤 이름과 연결되는지 적어 보세요. 정답은 ObserveBlock에 있습니다.

TEXT

A. "경영진 감사 대비로 IT 통제목표와 책임자를 정리해 둡시다."
B. "인시던트·변경 프로세스를 표준화해서 누가 해도 같은 절차로 돌게 하죠."
C. "이번 사업 입찰 요건에 서비스 관리 체계 인증 보유가 들어가 있어요."
D. "배포를 CI/CD로 자동화해서 주 1회는 안전하게 나가게 합시다."
E. "올해 ISMS-P 갱신 심사가 있으니 정보보호 항목부터 점검합시다."

힌트: 같은 회의에 거버넌스·실천·인증·문화가 섞여 나오는 게 정상입니다. 각 발언이 '무엇을 위한 말인지' 를 기준으로 나누세요.

분류: 거버넌스 / 실천 / 인증 / 문화

🔍실행 후 확인할 것

A = 거버넌스(COBIT 관점). 통제목표·책임·감사 정렬 — 경영의 언어
B = 실천(ITIL). 인시던트·변경 프로세스 표준화 — 운영의 언어
C = 인증(ISO/IEC 20000, 조직 인증). 입찰·계약 요건·대외 신뢰
D = 문화/방식(DevOps). CI/CD 자동화 — 단, 변경은 ITIL 변경관리로 추적해야 충돌이 없다
E = 인증(ISMS-P, 국내 정보보호 인증). 서비스 관리가 아니라 정보보호 초점 — C와 목적이 다름
핵심 감각: 이름이 많아 보여도 "거버넌스·실천·인증·문화" 네 칸으로 나누면 대부분 정리된다

현장에서 자주 보는 함정

증상: 누군가는 "우리 팀 ITIL 인증 있다"고 하고, 누군가는 "ISO 20000 자격증 따려고 한다"고 합니다. 그런데 막상 인증서를 확인하면 기대와 다릅니다. 입찰 담당자가 "조직 인증이 필요한데 왜 개인 자격증만 있냐"고 당황하는 식입니다.

원인: 인증의 '단위'를 헷갈린 것입니다.

ITIL Foundation 등은 개인이 시험 봐서 따는 자격입니다.
ISO/IEC 20000 은 조직이 심사받아 얻는 인증입니다.
둘을 "ITIL 인증/ISO 자격증"처럼 뒤섞어 부르면, 계약·입찰 요건을 잘못 충족했다고 착각합니다.

해결 방향:

누가 "인증"을 말하면 항상 "개인 자격인가, 조직 인증인가?" 를 되묻는다.
입찰·계약 요건은 보통 조직 인증(예: ISO/IEC 20000, ISMS-P)을 가리키니, 개인 자격으로 대체할 수 없다.
그리고 ISO/IEC 20000(서비스 관리) 과 ISMS-P(정보보호) 도 목적이 다르므로, 요건이 어느 쪽을 요구하는지 정확히 읽는다. 정보보호 요건을 서비스 관리 인증으로 충족했다고 착각하면 안 됩니다.

용어 하나를 정확히 되묻는 것만으로 잘못된 합의의 절반은 막힙니다.

💼

실무 맥락

현업 패턴

한국의 IT서비스(SI/SM) 현업에서 이 지형은 추상이 아니라 계약서와 채용공고에 실제로 박혀 있는 단어입니다.

대기업 계열 IT서비스사와 그 협력사의 운영(SM) 조직은 대체로 ITIL 기반 용어와 프로세스(인시던트·변경·SLA)로 운영체계를 설명하는 경향이 있습니다. 채용공고에서 "ITIL 이해" "ITIL Foundation 우대"가 자주 보이는 이유입니다. 한편 공공·금융처럼 규제가 강한 영역에서는 정보보호 인증(국내 제도인 ISMS-P 등) 이 사업 수행의 전제 조건으로 등장하곤 합니다 — 다만 기관·사업마다 요구가 달라, "어디나 무조건 ISMS-P"라고 단정하긴 어렵습니다. 실제 요건은 RFP·계약서를 직접 확인해야 합니다.

자격 측면에서, 관리·운영 직무를 노리는 주니어가 자주 함께 준비하는 조합은 대체로 ITIL Foundation(서비스 관리 공용어)과 정보처리기사(국내 IT 직무의 기본 국가기술자격)입니다. 전자가 "운영의 언어를 안다", 후자가 "IT 기초 직무 역량을 국가 자격으로 증명한다"는 신호를 주기 때문입니다. 다만 이 조합이 모든 회사·직무의 정답은 아니며, 트랙 후반의 자격증 로드맵 모듈에서 직무별로 더 구체화합니다.

관리자에게 진짜 중요한 역량은 자격증 개수가 아니라, 이 모듈의 비교표를 머릿속에 갖고 있어서 — 경영진에겐 거버넌스(COBIT) 언어로, 운영팀에겐 실천(ITIL) 언어로, 발주처에겐 인증(ISO/IEC 20000·ISMS-P) 언어로, 개발팀에겐 흐름(DevOps) 언어로 — 상대에 맞는 단어로 같은 사안을 설명하는 통역 능력입니다.

관련 모듈로 더 깊이:

ITIL 4 한눈에 — 이 지형의 중심에 있는 ITIL 4가 무엇을 다루는지 다시 보는 지도
IT 거버넌스·운영 KPI·지속적 개선(CSI) — COBIT 계열 거버넌스 언어를 KPI·경영보고로 풀어내는 실무

다음 모듈에서는 Phase 2를 시작하며, 이 모든 체계의 한가운데서 매일 벌어지는 일 — 인시던트 관리(서비스가 멈췄을 때 어떻게 접수·분류·대응·복구하고 기록하는가)의 라이프사이클을 본격적으로 다룹니다.