책임 할당 매트릭스(RAM/RACI) 기반 IT 프로젝트 역할·책임 설계
1. 개요
가. 정의
책임 할당 매트릭스(Responsibility Assignment Matrix, RAM)는 작업분류체계(WBS)와 조직분류체계(OBS) 또는 역할 목록을 교차해 산출물·활동·의사결정마다 누가 어떤 수준으로 관여하는지를 명시하는 관리 도구이다.
RACI는 RAM의 대표적인 표현 방식이다. R은 실제 작업을 수행하는 Responsible, A는 결과를 최종 승인하고 설명할 Accountable, C는 사전에 의견을 제공하는 Consulted, I는 진행 또는 결과를 통보받는 Informed를 뜻한다. 따라서 RACI는 단순한 연락망이 아니라 업무 결과와 의사결정 권한을 연결하는 운영 설계도이다. 조직이 커질수록 한 업무에 여러 부서가 관여하지만 최종 책임자가 불분명해지는 문제가 발생한다. RACI는 이 모호성을 표면화하여 일정 지연, 승인 누락, 중복 검토, 책임 전가를 줄인다.
나. 등장 배경과 필요성
IT 프로젝트는 기획자, 현업 부서, 개발자, 인프라 운영자, 보안 담당자, 개인정보 담당자, 외부 공급자가 함께 움직인다. 각 역할은 전문성이 다르므로 하나의 사람이 모든 판단을 맡을 수 없다. 반대로 모든 사람을 모든 회의에 참여시키면 의사결정이 느려지고 책임감도 희석된다.
WBS가 무엇을 해야 하는지를 보여준다면, RACI는 그 일을 누가 수행하고 누가 결과를 보증하는지를 보여준다. 일정표만으로는 승인권자와 협의 대상을 알 수 없고, 조직도만으로는 특정 산출물의 책임자를 알 수 없다. RAM은 WBS·OBS·일정·조달·품질·보안 통제를 하나의 책임 구조로 연결한다.
특히 클라우드와 외부 SaaS를 활용하는 프로젝트에서는 고객과 공급자의 책임 경계가 중요하다. 서비스 사업자가 플랫폼 보안을 담당해도 고객은 계정, 데이터 분류, 접근정책, 업무 설정을 책임질 수 있다. 이 경계를 문서로 남기지 않으면 장애가 발생했을 때 계약상 책임과 운영상 조치가 서로 어긋난다.
다. 목표와 적용 범위
RACI의 첫 번째 목표는 모든 핵심 산출물에 최소 한 명의 실행 주체와 최종 책임 주체를 연결하는 것이다. 두 번째 목표는 협의와 통보의 범위를 필요한 수준으로 제한하여 의사결정 속도와 품질을 함께 확보하는 것이다. 세 번째 목표는 역할 변경, 범위 변경, 외주 변경이 생겨도 책임 공백을 조기에 발견하는 것이다.
RACI는 프로젝트 초기의 계획 문서에만 머무르지 않는다. 요구사항 승인, 아키텍처 심의, 코드 배포, 보안 점검, 장애 대응, 인수인계, 서비스 전환과 같은 운영 이벤트에도 사용할 수 있다. 다만 모든 세부 작업을 한 장의 표에 넣으면 행과 열이 폭발하므로 의사결정 단위와 관리 수준에 맞게 분할해야 한다.
2. RAM과 RACI의 개념 구조
가. WBS·OBS·RAM의 연결
WBS는 프로젝트 범위를 계층적으로 분해하여 산출물과 작업 패키지를 만든다. OBS는 조직, 부서, 팀 또는 직무 역할을 계층적으로 표현한다. RAM은 WBS의 행과 OBS의 열을 매핑하여 어떤 역할이 어떤 작업에 관여하는지 표시한다.
flowchart LR
scope["프로젝트 범위"] --> wbs["WBS<br/>산출물·작업 패키지"]
org["조직·직무·공급자"] --> obs["OBS<br/>역할 목록"]
wbs --> ram["RAM<br/>작업 × 역할 매트릭스"]
obs --> ram
ram --> raci["RACI 규칙<br/>R·A·C·I"]
raci --> governance["승인·보고·에스컬레이션<br/>운영 거버넌스"]
WBS의 수준과 RACI의 수준은 가능한 한 맞춰야 한다. WBS가 업무를 너무 크게 잡으면 하나의 행에 여러 책임이 섞여 A가 누구인지 판단하기 어렵다. 반대로 API의 모든 함수까지 행으로 만들면 관리비용이 커지고 표가 실제 의사결정을 방해한다. 따라서 의사결정, 승인, 인수조건, 외부 약속이 발생하는 단위부터 행을 만드는 것이 실무적으로 적절하다.
나. R·A·C·I의 의미
Responsible(R)는 작업을 직접 수행하거나 결과물을 만들어 내는 역할이다. 한 행에 여러 R을 둘 수 있지만, 실제로 누가 주도하는지 모호하다면 작업을 더 작게 나누거나 주 수행자를 지정해야 한다. R은 일을 하는 권한과 필요한 자원을 가지고 있어야 하며, 단순히 회의에 참석하는 사람을 R로 표시해서는 안 된다.
Accountable(A)는 결과가 기준을 만족하도록 최종적으로 보증하고 승인하는 역할이다. A는 결과에 대한 설명과 의사결정 권한을 가져야 하며, 문제가 생겼을 때 최종 판단을 내릴 수 있어야 한다. 일반적으로 하나의 업무·산출물에는 한 명 또는 한 조직만 A로 두는 원칙이 유용하다. 두 명 이상을 A로 지정해야 한다면 승인권의 범위와 충돌 시 최종 결정자를 별도로 명시한다.
Consulted(C)는 작업 전에 전문 의견이나 검토를 제공하는 역할이다. C와의 대화는 양방향이므로 의견을 반영했는지 기록할 수 있어야 한다. 보안, 법무, 개인정보, 데이터 품질처럼 전문 판단이 필요한 영역은 C를 생략하면 나중에 재작업과 규제 리스크가 커진다.
Informed(I)는 진행 상태 또는 결정을 전달받는 역할이다. I는 통보를 받지만 모든 단계의 승인이나 회의 참여가 요구되는 것은 아니다. 보고서 수신자를 무조건 I로 늘리면 알림 과잉이 발생하므로, 무엇을 언제 어떤 형식으로 전달할지를 함께 정의해야 한다.
| 구분 | 핵심 질문 | 행동과 권한 | 대표 산출물 |
|---|---|---|---|
| R | 누가 실제로 수행하는가? | 실행·작성·조치 | 코드, 설계서, 시험결과 |
| A | 누가 최종 결과를 보증하는가? | 승인·자원결정·위험수용 | 승인기록, 의사결정 |
| C | 누구의 전문 의견이 필요한가? | 사전 검토·협의 | 검토의견, 조건 |
| I | 누가 결과를 알아야 하는가? | 통보·보고 수신 | 상태보고, 공지 |
다. 역할과 개인의 구분
초안에서는 개인 이름보다 역할을 열 제목으로 쓰는 편이 안정적이다. 개인이 바뀌어도 역할과 책임 구조는 유지되어야 하며, 인사 이동 때마다 매트릭스를 다시 설계할 필요가 없기 때문이다. 다만 최종 승인 문서에는 실제 담당자와 대리자, 연락 경로를 연결하여 실행 가능성을 확보한다.
역할은 조직도와 일치해야 하지만 조직도와 동일하지는 않다. 예를 들어 제품 책임자는 사업 의사결정의 A일 수 있고, 프로젝트 관리자는 일정과 조정의 R일 수 있다. 같은 사람이 여러 역할을 맡는 소규모 프로젝트에서는 겸임 자체보다 권한 충돌과 자기검토 위험을 기록하는 것이 중요하다.
3. RACI 작성 및 운영 절차
가. 입력자료와 기준선 준비
먼저 프로젝트 헌장, 범위기술서, WBS, 일정, 이해관계자 목록, 계약서, 보안·개인정보 요구사항을 수집한다. 이 자료가 없으면 RACI가 실제 업무가 아니라 작성자의 추측에 의존하게 된다. 각 자료의 버전과 기준일을 기록하여 어느 범위에 대한 책임표인지 명확히 한다.
업무를 산출물, 주요 활동, 승인 게이트, 의사결정으로 분류한다. 예를 들어 모바일 뱅킹 개편에서는 화면 개발만이 아니라 개인정보 영향평가, 보안성 검토, 대외 공지, 장애 전환 훈련도 책임 대상이다. 운영 전환처럼 여러 팀이 함께 참여하는 지점은 별도 행으로 두어야 인수인계 공백을 발견할 수 있다.
나. 역할 식별과 초안 작성
역할 목록에는 프로젝트 내부 팀만 아니라 고객, 운영조직, 보안감사, 규제 대응, 외부 공급자를 포함한다.
역할을 너무 일반적으로 개발팀이라고만 쓰면 실제 승인권과 실행자가 분리되지 않는다.
필요한 경우 백엔드 개발 리드, 서비스 오너, CISO 대리, 클라우드 사업자 기술지원처럼 책임 수준을 구체화한다.
각 행에 먼저 R과 A를 배치하고 그다음 C와 I를 추가한다. R과 A가 비어 있으면 아무도 일을 하거나 결과를 보증하지 않는 것이므로 우선 해결해야 한다. 반대로 모든 열에 C와 I가 채워지면 중요한 협의 대상이 묻히므로, 실제 의사결정에 기여하는 사람만 남긴다.
flowchart TD
s["범위·WBS·이해관계자 수집"] --> d["산출물·활동·결정 단위 정의"]
d --> r["역할 목록과 권한 확인"]
r --> a["R·A 우선 배치"]
a --> ci["C·I를 필요 기준으로 추가"]
ci --> check{"공백·중복·권한 불일치?"}
check -- "예" --> review["워크숍·협상·승인"]
review --> a
check -- "아니오" --> baseline["기준선 등록·공유"]
baseline --> monitor["변경·게이트·회고 때 갱신"]
다. 검증 규칙
첫 번째 검증은 행 기준 검증이다. 모든 핵심 업무에 최소 한 개의 R과 한 개의 A가 있는지 확인한다. 업무가 실제로 수행되려면 R에게 자원과 접근권한이 있어야 하고, A에게 결과를 승인하거나 중단할 권한이 있어야 한다.
두 번째 검증은 열 기준 검증이다. 특정 역할에 R이 과도하게 몰리면 병목과 단일 실패점이 발생한다. 반대로 어떤 역할에도 R이나 A가 없으면 조직이 형식적으로만 참여하고 실제 책임을 지지 않는다는 의미일 수 있다.
세 번째 검증은 경계와 의존성 검증이다. 한 행의 결과가 다음 행의 입력으로 사용될 때 인계자와 인수자가 연결되어야 한다. 예를 들어 개발 완료를 R로 표시했더라도 운영팀의 배포 승인과 보안팀의 검토가 누락되면 실제 출시 게이트는 완성되지 않는다.
| 검증 관점 | 점검 질문 | 문제가 있을 때의 조치 |
|---|---|---|
| 행 완결성 | 모든 핵심 행에 R·A가 있는가? | 담당자·권한·업무 범위 보완 |
| 단일 책임 | A가 여러 명이거나 없는 행은 없는가? | 최종 결정자와 승인 범위 확정 |
| 역할 과부하 | 특정 역할에 R·A가 과도하게 몰렸는가? | 위임, 분할, 백업 지정 |
| 협의 효율 | C가 지나치게 많아지는가? | 필수 검토와 선택 검토 분리 |
| 통보 품질 | I가 실제로 필요한 정보를 받는가? | 이벤트·주기·채널 정의 |
| 권한 정합성 | 표시된 책임과 계약·조직 권한이 일치하는가? | 권한 위임 또는 계약 보완 |
라. 합의와 기준선 관리
RACI는 PM 혼자 작성한 뒤 배포하는 문서가 되어서는 안 된다. 역할을 부여받는 당사자가 자신의 권한, 자원, 완료 기준을 확인하고 동의해야 실행 가능성이 높아진다. 특히 A로 지정된 사람은 책임을 수락할 수 있는 예산·인력·중단 권한이 있는지 확인한다.
합의 과정에서 이견이 발생하면 사람의 이름을 놓고 다투기보다 업무 결과와 의사결정 권한을 먼저 분리한다. 한 조직이 R이면서 다른 조직이 A인 것이 자연스러운 경우도 있다. 다만 A가 C의 의견을 무시할 수 있는지, C의 검토가 필수 게이트인지, I에게 어느 시점에 알려야 하는지를 문서에 남긴다.
승인된 RACI에는 버전, 적용 범위, 승인일, 변경 사유, 다음 검토일을 기록한다. 범위 변경, 조직 개편, 공급자 교체, 보안사고, 주요 단계 종료 때는 변경 영향 분석과 함께 RACI를 갱신한다.
4. 변형 모델과 유사 도구 비교
가. RASCI·RACI-VS·DACI
RACI만으로는 수행 지원이나 검증의 차이를 표현하기 어려운 경우가 있다. RASCI는 Support를 추가하여 R과 협력하지만 결과를 직접 소유하지 않는 지원 역할을 구분한다. 예를 들어 플랫폼팀이 배포 파이프라인을 제공하지만 애플리케이션의 출시 책임자는 아닌 경우 S가 유용하다.
RACI-VS는 Verify와 Sign-off를 추가하는 변형이다. 테스트나 감사처럼 독립적으로 결과를 확인하는 역할과 공식 서명·승인 역할을 나누고 싶을 때 사용한다. 하지만 변형 문자가 많아질수록 교육과 해석 비용이 커지므로 조직 표준을 먼저 정해야 한다.
DACI는 Driver, Approver, Contributors, Informed로 의사결정 자체에 초점을 둔다. RACI가 작업과 산출물의 책임을 표현하는 데 강하다면 DACI는 회의와 선택지 비교의 책임을 선명하게 한다. 프로젝트에서는 두 표를 무작정 섞기보다 작업용 RACI와 핵심 의사결정용 DACI를 연결하는 편이 관리하기 쉽다.
| 도구 | 주된 대상 | 강점 | 주의점 |
|---|---|---|---|
| RAM | WBS와 조직의 매핑 | 산출물·조직 수준을 조절 가능 | 표현 규칙을 별도로 정해야 함 |
| RACI | 작업·산출물 책임 | 이해가 쉽고 범용적 | 검증·지원 역할이 뭉칠 수 있음 |
| RASCI | 작업과 지원 관계 | 플랫폼·공급자 협업 표현 | 문자가 늘어 해석 필요 |
| DACI | 의사결정 | Driver와 Approver가 명확 | 반복 작업 책임에는 부족 |
| 조직도 | 보고 체계 | 공식 조직 관계 표현 | 특정 산출물 책임은 알기 어려움 |
| WBS | 범위와 작업 분해 | 누락·중복 범위 발견 | 책임자와 권한은 표현하지 않음 |
나. 애자일과 DevOps에서의 적용
애자일에서는 팀이 자기조직화된다고 해서 책임이 사라지는 것이 아니다. 제품 백로그, 스프린트 목표, 품질 기준, 릴리스 승인, 운영 대응에 대한 책임을 역할 수준으로 표현할 수 있다. 다만 매일의 태스크까지 RACI로 통제하면 팀의 자율성이 약화되므로 제품·플랫폼·보안 같은 경계에 집중한다.
DevOps에서는 개발팀과 운영팀의 책임이 연결되어야 한다. 코드 작성자는 배포 파이프라인의 품질과 관측성 설정에 R일 수 있고, 서비스 오너는 출시 위험을 A로 맡을 수 있다. SRE는 오류 예산과 신뢰성 검토에 C 또는 A가 될 수 있으나, 모든 장애의 단일 A로 지정하면 개발팀의 운영 책임이 약해진다.
5. 적용 사례
가. 공공 민원 시스템 전환
공공 민원 시스템을 클라우드로 전환하는 경우 WBS에는 데이터 이관, 개인정보 영향평가, 성능시험, 사용자 교육, 전환 리허설, 서비스 오픈이 포함된다. 사업자는 이관 스크립트와 시험환경을 만드는 R이 될 수 있지만, 데이터 품질과 업무 적합성을 최종 승인하는 A는 발주기관의 서비스 오너일 수 있다. 개인정보 담당자는 C로서 보유기간과 파기 조건을 검토하고, 감사 부서는 결과 보고를 I로 받을 수 있다.
전환 리허설의 R이 인프라 사업자 한 곳뿐이면 부족하다. 업무부서가 실제 민원 시나리오를 수행하는 R이 추가되어야 하고, 장애 시 원복 여부를 결정할 A와 연락을 받아야 하는 I를 구분해야 한다. 이렇게 작성하면 기술적으로 서버가 준비되었지만 업무 승인이나 개인정보 검토가 끝나지 않은 상태를 출시 완료로 오인하는 일이 줄어든다.
나. 금융 이상거래 탐지 서비스
금융 이상거래 탐지 서비스에서는 데이터 과학자가 탐지 모델과 평가 결과를 R로 만들 수 있다. 준법·AML 책임자는 규제 기준과 업무 위험을 고려하여 운영 적용을 A로 승인할 수 있다. 보안팀과 개인정보 담당자는 특성 데이터의 접근과 보유를 C로 검토하고, 영업점과 고객센터는 정책 변경을 I로 받아야 한다.
모델 정확도가 높아도 오탐으로 정상 거래가 차단되면 고객 불편과 민원이 증가한다. 따라서 모델 성능 보고, 임계값 변경, 수동 해제 절차, 사고 보고, 재학습 승인 등을 별도 행으로 두는 것이 필요하다. 모델 운영 담당자에게 R만 주고 임계값을 바꿀 권한을 주지 않으면 표와 실제 운영이 어긋난다.
다. 장애 대응과 서비스 복구
장애 대응 RACI는 평시 프로젝트 RACI와 분리하여 시간대와 심각도별로 작성한다. 온콜 엔지니어는 초기 진단과 완화 조치의 R, 서비스 오너는 고객 영향과 복구 우선순위의 A가 될 수 있다. 보안관제는 침해 가능성을 C로 검토하고, 경영진·고객지원·규제 담당은 I로 통보받는다.
복구 단계에서는 원인 분석을 기다리느라 복구가 늦어지지 않도록 조치와 설명의 책임을 나눈다. 인시던트 커맨더가 전체 조정을 A로 맡고, 데이터베이스·네트워크·애플리케이션 담당이 각 기술 조치의 R을 맡는 방식이다. 장애 종료 후에는 사후보고서와 재발방지 항목의 A를 지정하여 임시 완화책이 영구 대책으로 오인되지 않게 한다.
6. 한계와 실패 패턴
첫째, 모든 칸을 채우려는 형식주의가 발생한다. 실제 관여하지 않는 사람까지 C와 I로 넣으면 표가 커지지만 의사결정 품질은 좋아지지 않는다. 책임표는 빈 칸이 있어도 괜찮으며, 빈 칸이 의도된 비관여인지 설명할 수 있어야 한다.
둘째, A와 R을 구분하지 못하는 문제가 발생한다. 팀장이 A라는 이유만으로 모든 일을 R로 표시하면 실행 주체가 사라지고 병목이 생긴다. 반대로 실무자만 R로 두고 A를 비워 두면 결과 승인과 위험 수용의 주체가 없어진다.
셋째, 매트릭스를 승인했지만 권한과 자원을 주지 않는 경우다. 책임을 맡은 팀이 시스템 접근권한, 예산, 의사결정권을 갖지 못하면 RACI는 책임 전가 문서가 된다. 권한 위임, 예산, 계약상 의무, 대체 인력을 함께 확인해야 한다.
넷째, 한번 만든 RACI를 끝까지 재사용하는 문제다. 애자일 스프린트, 조직 개편, 공급자 변경, 운영 전환 때 역할은 바뀐다. 변경관리와 연결하지 않으면 오래된 A가 여전히 승인자로 남거나 퇴사자가 온콜 목록에 남는다.
7. 심화: 책임 데이터를 운영 거버넌스로 확장
RACI를 정적 문서에서 책임 데이터로 발전시키려면 산출물 ID, 역할 ID, 권한, 승인 증적, 유효기간을 구조화한다. 예를 들어 릴리스 파이프라인은 서비스 ID를 기준으로 현재 A, 배포 R, 보안 C, 경영진 I를 조회할 수 있어야 한다. 변경 티켓이 생성될 때 RACI 기준선과 비교하여 책임 공백을 자동 경고하면 문서와 운영의 차이를 줄일 수 있다.
접근제어와 RACI를 무조건 일치시킬 필요는 없지만 서로 모순되어서는 안 된다. R로 지정된 사람이 실제 저장소에 접근할 수 없다면 업무 위임 또는 권한 부여 절차가 필요하다. A라고 해서 모든 데이터에 직접 접근해야 하는 것도 아니므로 승인 권한과 데이터 접근 권한을 분리하여 최소권한을 유지한다.
AI와 자동화가 늘어날수록 자동화된 시스템 자체를 R로 표기하는 유혹이 커진다. 그러나 시스템은 책임을 설명하거나 위험을 수용하는 A가 될 수 없다. 자동화 서비스는 수행 주체 또는 통제 대상이며, 결과를 검토하고 중단할 인간·조직 A를 명확히 남겨야 한다.
성과지표에도 RACI를 연결할 수 있다. 승인 대기시간, 재작업률, 책임 공백 건수, 변경 후 RACI 갱신 지연, 장애 에스컬레이션 준수율을 측정하면 책임 체계의 품질을 확인할 수 있다. 다만 지표를 개인 평가에 직접 연결하면 구성원이 위험한 업무를 회피할 수 있으므로 팀 단위 학습과 프로세스 개선에 우선 사용한다.
8. 고려사항 및 시사점
가. 기술사 관점의 설계 원칙
첫째, RACI의 행은 조직도가 아니라 서비스 결과와 통제 게이트를 기준으로 만든다. 사용자가 체감하는 업무 결과, 규제상 증적, 보안상 승인, 운영상 복구 지점을 우선하면 표가 실제 위험을 반영한다.
둘째, A에는 책임뿐 아니라 권한과 자원을 함께 부여한다. 권한이 없는 책임자는 승인 지연을 만들고, 자원이 없는 R은 일정 지연을 만든다. RACI 검토 시 역할별 의사결정권, 예산, 접근권한, 대리자, 에스컬레이션 경로를 함께 점검한다.
셋째, RACI를 WBS·OBS·일정·리스크·변경관리와 연결한다. 범위나 조직이 바뀌었는데 책임표가 그대로라면 기준선의 무결성이 깨진다. 변경 승인 시 관련 RACI 행의 영향과 증적 위치를 필수 항목으로 만들면 누락을 줄일 수 있다.
넷째, 표의 단순함과 현실의 복잡함 사이에서 수준을 조절한다. 경영진에게는 핵심 산출물 수준의 요약표를 제공하고, 팀에는 세부 작업표와 의사결정표를 제공한다. 여러 표 사이에는 산출물 ID와 역할 ID를 사용하여 서로 다른 해석이 생기지 않게 한다.
다섯째, 책임을 개인 탓으로 만들지 않고 학습 가능한 운영체계로 만든다. 사고 후에는 누가 잘못했는지만 묻지 말고 R이 실행할 권한이 있었는지, A가 위험을 볼 정보가 있었는지, C가 적시에 참여했는지를 확인한다. 이 분석은 RACI를 비난의 근거가 아니라 통제 설계 개선의 근거로 바꾼다.
나. 출제 답안 구성 전략
논술형 답안에서는 정의와 필요성을 먼저 제시한 뒤 WBS·OBS·RAM의 관계를 개념도로 표현한다. R·A·C·I의 의미는 표로 정리하되, A와 R을 분리해야 하는 이유와 한 행에 단일 A를 권고하는 이유를 산문으로 설명한다. 작성 절차에서는 입력자료, 역할 식별, 배치, 검증, 합의, 기준선, 변경관리의 흐름을 보여준다.
마지막에는 공공 클라우드 전환이나 금융 탐지 서비스처럼 책임 경계가 중요한 사례를 제시한다. 애자일·DevOps·외부 공급자 환경에서 RACI를 그대로 강제할 때 생기는 과잉통제도 함께 언급한다. 결론은 권한·자원·증적·최소권한·변경 연계라는 기술사 관점의 시사점으로 마무리하면 답안의 실무성을 높일 수 있다.
참고자료
- PMI, “The brick and mortar of project success” — https://www.pmi.org/learning/library/project-success-core-values-key-accountabilities-6262
- PMI, “Roles, responsibilities, and resources” — https://www.pmi.org/learning/library/best-practices-managing-people-quality-management-7012
- University of Essex, “Responsibility matrix” — https://www.essex.ac.uk/staff/strategic-project-delivery/responsibility-matrix
한 줄 요약: RAM/RACI는 WBS의 일과 조직의 권한을 연결하여 누가 수행하고 누가 최종 책임지며 누구와 협의·공유할지를 명확히 하고, IT 프로젝트의 책임 공백과 승인 지연을 줄이는 실행형 거버넌스 도구이다.