COO·CHRO와 새로 떠오른 C레벨: CTO·CPO·CAIO·CQO

개념

COO — 일상적인 사업 운영과 생산 관리를 총괄

CEO가 어디로 갈지 정한다면, COO는 매일 굴러가게 만든다. 회사마다 범위 편차가 가장 큰 직함이기도 하다 — 생산·물류·CS 운영을 모두 갖기도 하고, 사업부 몇 개만 맡기도 한다.

SLO를 숫자로 감각하기

모듈 14 레슨 7에서 SLI·SLO·에러 버짓의 개념을 배웠다. COO와 대화하려면 가용성 퍼센트가 시간으로 얼마인지 알아야 한다. (30일 기준)

에러 버짓(Error budget)은 "허용 중단 시간 중 남은 양" 이다. 이번 달 버짓을 다 썼다면 새 기능 배포보다 안정화가 먼저라는 합의를 만드는 도구다. QA는 배포가 버짓을 얼마나 쓰게 했는지 데이터를 줄 수 있다.

운영 매뉴얼(런북)도 테스트 대상이다. "결제 장애 시 수동 전환 절차" 가 문서대로 실제로 되는지, 장애가 나기 전에 확인한다.

CHRO — 채용, 평가, 복지 등 인사 업무 총괄

QA가 CHRO와 만나는 두 방향.

1. 내 커리어 — 경력 사다리가 없으면 QA는 "시니어 다음" 이 안 보인다. 역량 모델 초안을 QA 리드가 먼저 제안하는 경우가 많다.
2. HR 시스템 테스트 — 급여 계산은 결정테이블과 경계값의 교과서다(모듈 3 레슨 1·3). 입사일·퇴사일 경계, 수습 기간, 휴직, 연장근로 조건이 얽힌다. 그리고 가장 민감한 개인정보를 다룬다.

AI 도입에 따른 역할 재정의도 CHRO 의제다. "테스트 실행" 비중이 줄고 "AI 산출물 검증·판단" 비중이 커지는 변화(스테이지 6)를 직무 기술서와 교육 계획으로 옮기는 일에 QA가 근거를 줄 수 있다.

평가 지표 설계 예:

(지표 자체는 모듈 6 레슨 5에서 다뤘다)

CTO — 제품 기술과 개발 조직

CTO가 자주 보는 개발 성과 지표로 DORA 4대 지표가 있다.

속도(앞의 둘)와 안정성(뒤의 둘)을 함께 보는 지표라서, QA가 "속도를 늦추는 조직" 이 아니라는 것을 보여주기 좋다.

CPO — 제품 비전과 로드맵

Chief Product Officer. PM 조직을 이끌고 무엇을 만들지, 무엇을 먼저 할지 정한다.

약어 주의 — CPO가 Chief Privacy Officer(개인정보 보호책임자)일 수도 있다. 한국 법에서 CPO라고 하면 보통 이쪽이다. (레슨 4)

CAIO — AI 전략과 거버넌스

Chief AI Officer. AI를 어디에 쓸지, 어떻게 안전하게 쓸지를 책임진다. 최근 빠르게 늘어난 직함이다.

규제 흐름 두 가지 — EU AI Act의 위험 기반 분류는 모듈 18b 레슨 6에서 다뤘다. 여기서는 미국과 한국을 본다.

• 미국 — 연방정부 관리예산처(OMB)가 2024년 각 연방기관에 CAIO 지정을 요구했고(M-24-10), 2025년 4월 이를 대체한 M-25-21 에서도 기관별 CAIO 지정과 고영향 AI 관리 절차를 유지했다.
• 한국 — 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」(AI 기본법) 이 2026년 1월 22일 시행됐다. 고영향 인공지능의 안전성·신뢰성 확보 조치, 생성형 AI 결과물 표시 등이 핵심이고, 정부는 시행 초기 최소 1년 이상의 계도기간을 두겠다고 밝혔다.

이 법들이 민간 기업에 CAIO라는 직함을 두라고 강제하는 것은 아니다. 하지만 이런 의무에 대응하는 일이 CAIO나 AI 거버넌스 조직의 몫이 된다.

QA 접점 — AI 기능은 QA가 가장 필요한 영역이다

CQO — 전사 품질 책임자

Chief Quality Officer. 품질경영 체계, 규제 준수, 지속적 개선, 품질 문화를 책임지고, 보통 CEO에게 보고한다.

QA 커리어의 최상단이 어떤 모습인지 보여주는 역할이다. 소프트웨어 회사에서 품질이 C레벨 의제가 되는 순간은 대개 대형 장애·보안 사고 직후다. 그 전에 지표와 체계를 준비해 둔 QA 리드가 그 자리를 맡는다.

C레벨 지도 완성

방향     CEO · CSO · (CEO Japan: 지역)
돈       CFO
매출·고객 CRO · CMO · CCO
운영     COO
사람     CHRO
기술     CTO · CIO · CDO
제품     CPO(Product)
위험     CISO · CPO(Privacy) · CLO
AI       CAIO
품질     CQO / Head of QA

런북 테스트는 장애 전에 한다

위에서 "운영 매뉴얼(런북)도 테스트 대상" 이라고 했는데, 이것이 COO 조직과 일하는 가장 구체적인 접점이다. 확인 항목이 정해져 있다.

두 번째가 실제 장애에서 가장 많이 걸린다. 절차는 맞는데 그 시각에 실행할 권한을 가진 사람이 없는 경우다. 이것은 기능 결함이 아니라 운영 설계의 공백이고, 평시에 한 번 돌려 보면 드러난다.

사례 — 포스트모템에서 QA가 앉는 자리

결제 장애로 47분간 주문이 안 된 날이 있었다. 다음 날 포스트모템에 COO·CTO·개발 리드·QA가 앉았고, 첫 질문이 QA에게 왔다.

"이건 왜 테스트에서 안 걸렸습니까?"

QA가 처음 준비한 답은 범위 설명이었다 — "해당 조건은 테스트 범위에 없었습니다." 사실이었지만 그 자리에서는 변명으로 들렸다. 분위기가 "QA 책임" 쪽으로 기울었다.

두 번째 장애 때는 답의 구조를 바꿨다. 같은 질문에 세 줄로 답했다.

3번이 자리의 성격을 바꿨다. 대화가 "누가 놓쳤나" 에서 "무엇을 만들면 다음에 잡히나" 로 옮겨졌고, 그 자리에서 모의 서버 개선이 과제로 배정됐다.

그리고 COO가 추가로 물은 것이 있었다.

"이 장애로 에러 버짓을 얼마나 썼습니까?"

QA가 그 숫자를 갖고 있었다 — 47분은 99.9% 목표의 한 달 버짓(43분)을 이미 넘긴 양이었다. 그 한 줄이 "이번 달은 새 기능보다 안정화" 라는 결정을 만들었다.

여기서 남는 교훈이 셋이다.

• 범위 설명만으로 끝내면 변명이 된다 — "무엇을 바꾸면 잡히나" 를 붙인다
• 에러 버짓을 숫자로 알고 있으면 장애의 의미를 운영 언어로 말할 수 있다
• 포스트모템에서 QA의 가치는 원인 분석이 아니라 "재발을 막을 장치" 제안 이다(모듈 10의 결함 분석과 같은 태도)

마지막 줄을 놓치기 쉽다. 원인 분석은 개발이 더 잘하고, "그 시점에 아무도 그것을 볼 수 없었던 구조" 를 찾는 것이 QA의 강점이다(모듈 6 레슨 3).

"QA가 속도를 늦춘다" 에 답하는 법

이 오해는 거의 모든 조직에 있다. 그리고 감정으로 반박하면 이기지 못한다 — DORA 4대 지표가 숫자로 답하는 틀을 준다.

핵심은 네 지표를 함께 본다는 것이다. 속도 둘만 보면 QA는 비용이고, 안정성 둘을 함께 보면 QA는 그 둘을 지키는 조직이 된다. 그래서 QA가 먼저 DORA를 꺼내는 편이 유리하다.

실무적으로 준비할 것은 하나다 — 우리 팀의 변경 실패율(배포 중 장애· 롤백 비율)을 알고 있는 것. 모듈 6 레슨 5의 지표에 그 한 줄을 더해 두면, 이 대화에서 쓸 숫자가 생긴다.

실무에서 왜 필요한가

운영(COO)과 인사(CHRO)는 QA가 직접 보고할 일은 적지만 영향은 크게 받는 조직이다. 장애가 나면 포스트모템 자리에 COO가 앉고, 평가 시즌에는 QA의 성과를 무엇으로 볼지 인사 기준이 정한다. 두 조직의 언어(SLO, 에러 버짓, 역량 모델, 평가 지표)를 모르면 QA는 자기 일의 결과가 어떻게 해석되는지 통제할 수 없다.

그리고 AI 기능이 붙은 서비스가 늘면서 CAIO나 AI 거버넌스 조직이 생기고 있다. 이들이 가장 필요로 하는 것이 AI 기능을 평가하고, 모델이 바뀔 때마다 회귀를 잡는 능력 — 즉 QA의 역량이다. 스테이지 6에서 배운 검증 기법이 조직 안에서 누구에게 쓰이는지를 알면, 그 역량을 어디에 가져가야 하는지도 보인다.

새 C레벨이 생긴다는 것은 새 이해관계자가 생긴다는 뜻이고, 그 자리에서 QA의 역할은 새로 정의된다. CTO·CPO와의 관계는 이미 익숙하겠지만, 그들이 보는 지표(DORA, 로드맵)로 말할 수 있어야 "QA가 속도를 늦춘다"는 오해에 숫자로 답할 수 있다.

채용시장에서의 위치

• 장애 대응·포스트모템 경험은 운영 성숙도가 높은 회사일수록 필수로 본다. COO·CTO와 같은 테이블에 앉는 일이다.
• AI 기능을 가진 서비스가 늘면서 "AI 품질 평가", "LLM 평가", "AI 레드팀" 이 QA 공고에 등장했다. CAIO 조직과 협업하는 자리다.
• 리드 공고의 "QA 조직 구축, 역량 모델·온보딩 설계" 는 CHRO와 함께 하는 일이다.
• DORA 지표로 품질을 말할 수 있으면 "QA가 속도를 늦춘다" 는 편견에 숫자로 답할 수 있다.

질문별로 갈리는 지점은 이렇다.

두 번째가 가장 변별력이 크다. 같은 사실을 전하면서 변명이 아니라 제안으로 만드는 능력이고, 그것은 포스트모템 자리를 실제로 겪어 본 사람만 안다.

네 번째는 COO·SRE 조직과 일하는 자리에서 바로 쓰인다. 퍼센트를 시간으로 바꿔 말할 수 있는지가 그 조직의 언어를 아는 신호다.

실습 과제

과제 1 — SLO 감각 익히기 (10분)

1. 본인 서비스(또는 가상 서비스)의 가용성 목표를 정한다
2. 한 달 허용 중단 시간을 계산한다
3. 지난 한 달 장애 기록(또는 가상 기록)으로 남은 에러 버짓을 구한다
4. 버짓이 20% 남았을 때 QA가 제안할 배포 정책을 한 문단으로 쓴다

목표          99.9% (30일)
허용 중단     43,200분 × 0.1% = 43.2분
지난달 장애   25분
남은 버짓     43.2 − 25 = 18.2분 → 약 42%

과제 2 — COO용 포스트모템 초안 (15분)

기억나는 장애 하나(또는 가상 장애)로 작성한다. 비난하지 않는(blameless) 형식이다.

[요약]        무엇이, 언제부터 언제까지, 누구에게 영향
[영향]        중단 시간, 영향 사용자, 매출·CS 영향
[타임라인]    감지 → 판단 → 조치 → 복구
[근본 원인]   왜 발생했나 / 왜 사전에 못 잡았나
[재발 방지]   테스트·모니터링·프로세스 (담당, 기한)

"왜 사전에 못 잡았나" 칸이 QA의 몫이다.

과제 3 — QA 경력 사다리 초안 (15분)

CHRO에게 제안한다고 가정하고 4단계를 설계한다.

이 모듈의 내용(비즈니스 영향 보고, 예산 설득)이 어느 단계부터 요구되는지 표시한다.

과제 4 — AI 기능 출시 체크리스트 (15분)

사내 챗봇(고객 문의 응답)을 출시한다고 가정하고, CAIO에게 가져갈 체크리스트 10개를 만든다.

• 품질 평가(데이터셋, 합격 기준)
• 편향·안전 (민감 질문 목록)
• AI 생성 결과물 표시
• 사람 상담원 전환 경로
• 모델 교체 시 회귀

법 조항 해당 여부는 "법무 확인 필요" 로 표시한다. QA가 단정하지 않는다.

과제 5 — AI 결과 검증 (10분)

평소 쓰는 AI 도구(ChatGPT·Claude·Gemini 등)에 요청한다.

한국 AI 기본법에 따라 고객 상담 챗봇을 운영하는 기업이 해야 할 일을 정리하라.

자가 체크리스트

• COO가 하는 일과 대표 숫자(SLA, MTTR 등)를 말할 수 있다
• 99.9%·99.99% 가용성이 한 달에 몇 분인지 계산할 수 있다
• 에러 버짓이 배포 정책 합의 도구임을 설명할 수 있다
• 런북도 테스트 대상임을 안다
• CHRO와 QA가 만나는 두 방향(커리어, HR 시스템)을 안다
• 결함 발견 수가 나쁜 평가 지표인 이유를 설명할 수 있다
• CTO와 CIO의 차이를 제품/사내 시스템으로 구분할 수 있다
• DORA 4대 지표와 QA의 연결을 설명할 수 있다
• CPO가 Product와 Privacy 두 뜻임을 알고 문맥으로 구분한다
• CAIO의 역할과 AI 기능 QA 검증 항목을 5개 이상 안다
• 한국 AI 기본법 시행일과 핵심 의무의 방향을 안다
• 법이 CAIO 직함을 강제하는 것은 아님을 안다
• CQO가 흔한 업종과 소프트웨어 업계의 대응 직함을 안다

흔한 실수

• 가용성 퍼센트를 시간으로 바꿔보지 않는다. 99.9%와 99.99%는 한 달 약 43분과 약 4분의 차이다.
• 런북을 장애가 난 뒤 처음 실행한다. 수동 전환 절차도 사전에 테스트한다.
• 포스트모템을 책임자 찾기로 쓴다. 비난하는 순간 다음 사고의 정보가 숨는다.
• 결함 발견 수를 QA 성과 지표로 제안한다. 결함 쪼개기와 개발자와의 대립을 부른다.
• CTO와 CIO에게 같은 이야기를 한다. 한쪽은 제품 기술, 한쪽은 사내 시스템이 관심사다.
• CPO를 문맥 없이 해석한다. Product와 Privacy는 완전히 다른 조직이다.
• AI 기능을 일반 기능처럼 한 번 통과시키고 끝낸다. 모델·프롬프트가 바뀔 때마다 회귀가 필요하다.
• AI 규제 해당 여부를 QA가 단정한다. 체크리스트에 법무 확인 필요로 표시한다.
• 법이 CAIO 직함을 강제한다고 오해한다. 의무는 조치에 있고, 직함은 회사의 선택이다.

참고 자료

• Service Level Objectives (Google SRE Book) — SLO·에러 버짓
• DORA 연구 (dora.dev) — 4대 지표
• 인공지능 발전과 신뢰 기반 조성 등에 관한 기본법 (국가법령정보센터)
• White House Unveils Updated AI Guidelines for Federal Agencies (Perkins Coie) — OMB M-25-21 요약
• The role of chief quality officer (Wolters Kluwer)
• Postmortem Culture: Learning from Failure (Google SRE Book) — 비난 없는 포스트모템의 원칙

이 커리큘럼 안에서

• 모듈 26 레슨 1 — CxO 지도. 이 레슨이 그 지도를 완성한다
• 모듈 26 레슨 3 — CFO. 운영 공수를 비용으로 바꾸는 방법
• 모듈 26 레슨 7 — 경영진 보고. 포스트모템 보고의 형식
• 모듈 6 레슨 3 — 비난 없는 소통. "어떤 질문이 없었나" 로 묻는 태도
• 모듈 6 레슨 5 — 지표. 변경 실패율을 거기에 더해 둔다
• 모듈 7 레슨 9 — 조직·역량. CHRO와 함께 하는 경력 사다리
• 모듈 10 — 결함 분석. 재발 방지 장치를 설계하는 절차
• 모듈 14 레슨 6~7 — 관측성·SLO. 에러 버짓의 토대
• 모듈 18b — AI 시스템 검증. CAIO 조직이 필요로 하는 역량
• 모듈 36·57 — AI 품질 표준과 심화. 거버넌스 쪽 요구

한 줄 정리 — COO·CHRO는 직접 보고할 일이 적지만 QA의 결과가 어떻게 해석되는지를 정하는 조직이다. 포스트모템에서 QA의 자리는 원인 분석이 아니라 "무엇을 바꾸면 다음에 잡히나" 를 제안하는 것이고, "QA가 속도를 늦춘다" 는 말에는 DORA 네 지표를 함께 꺼내 답한다 — 변경 실패율과 복구 시간은 QA가 내리는 숫자다.