게임 개발팀 Decision Latency 측정법: 승인 체계를 단순화하는 의사결정 운영

핵심 요약

Decision Latency는 결정 요청이 등록된 시점부터 최종 결정이 문서로 확정된 시점까지 걸린 시간입니다. 게임 개발팀은 결정 유형별로 P50과 P90을 측정하면 회의가 아니라 승인 대기와 책임자 부재가 병목인지 확인할 수 있습니다. 승인 체계는 의사결정권자를 한 명으로 지정하고 자문과 승인을 분리하며 기한과 에스컬레이션 규칙을 문서화하는 방식으로 단순화할 수 있습니다.

Decision Latency란 무엇인가?

Decision Latency는 팀이 결정을 내리는 데 소비한 시간을 나타내는 운영 지표입니다. 단순히 회의 시간을 합산하는 것이 아니라 다음 두 시각의 차이를 측정합니다.

requested_at: 결정이 필요하다고 요청이 등록된 시각
decided_at: 선택안과 책임자가 문서에 기록되어 실행 가능한 상태가 된 시각

Decision\ Latency = decided\_at - requested\_at

게임 개발에서는 아트 방향, 기능 스코프, 플랫폼 대응, 출시 일정처럼 여러 직군이 관여하는 결정에서 지연이 자주 발생합니다. 이때 실제 작업 시간과 결정 대기 시간을 분리하지 않으면 일정 지연의 원인을 잘못 판단하게 됩니다.

지표	측정 구간	확인할 문제
Decision Latency	요청부터 결정 확정까지	팀 의사결정 자체가 얼마나 느린가
Queue Latency	검토 가능 상태부터 검토 시작까지	승인자 대기열이 긴가
Review Time	검토 시작부터 의견 확정까지	자료 부족이나 논쟁이 긴가
Execution Lead Time	결정 확정부터 작업 완료까지	결정 이후 실행 체계가 느린가

예를 들어 새로운 튜토리얼 연출안이 요청된 뒤 5일 후에 확정되었다면 Decision Latency는 5일입니다. 그중 승인자가 3일 동안 확인하지 않았다면 리뷰 품질보다 승인 대기열을 먼저 개선해야 합니다.

팀 의사결정은 왜 오래 걸리는가?

대부분의 지연은 판단 능력보다 운영 구조에서 발생합니다. 다음 신호를 함께 확인하면 원인을 구분하기 쉽습니다.

관찰되는 현상	가능한 원인	측정할 데이터
같은 안건이 여러 회의에 반복 등장	결정권자가 불명확함	회의 횟수, 담당자 수
피드백은 많지만 결론이 없음	자문과 승인이 섞임	의견 작성자와 최종 승인자
담당자가 자료를 다시 준비함	결정 기준과 입력 형식이 없음	요청 반려 횟수, 재작성 시간
특정 리더의 확인만 기다림	단일 병목과 대리 권한 부재	승인 대기 시간, 승인자별 P90
결정 후 다시 원안으로 돌아감	가역성과 리스크 기준이 없음	결정 번복률, 번복 사유

특히 모두의 동의를 승인 조건으로 사용하면 책임은 분산되고 결정은 늦어집니다. 의견을 낼 사람은 여러 명일 수 있지만 최종 선택에 책임지는 사람은 한 명이어야 합니다.

Decision Latency를 어떻게 측정할까?

1. 측정 시작과 종료 조건을 고정한다

먼저 팀에서 같은 의미의 이벤트를 사용해야 합니다. 요청 메시지가 채팅방에 올라온 시각을 시작점으로 삼을 수도 있지만 나중에 비교하려면 이슈 트래커나 문서에 구조화된 필드를 두는 편이 안전합니다.

권장 이벤트는 다음과 같습니다.

{
  "decision_id": "D-2026-014",
  "decision_type": "feature_scope",
  "requested_at": "2026-08-20T09:00:00+09:00",
  "ready_for_decision_at": "2026-08-21T14:00:00+09:00",
  "decided_at": "2026-08-22T11:00:00+09:00",
  "owner": "product_manager",
  "approver": "game_director",
  "status": "decided"
}

ready_for_decision_at은 모든 필수 자료가 준비된 시각입니다. 이를 별도로 기록하면 자료 준비 지연과 승인 지연을 섞지 않을 수 있습니다.

2. 평균보다 P50과 P90을 본다

평균은 한두 건의 극단값에 영향을 크게 받습니다. 일반적인 결정 속도는 P50으로 반복적으로 발생하는 긴 지연은 P90으로 확인하는 것이 실무에 유용합니다.

PostgreSQL을 사용한다면 다음과 같이 결정 유형별 분포를 조회할 수 있습니다.

SELECT
  decision_type,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY decided_at - requested_at) AS p50_latency,
  percentile_cont(0.9) WITHIN GROUP (ORDER BY decided_at - requested_at) AS p90_latency
FROM decisions
WHERE requested_at >= CURRENT_DATE - INTERVAL '30 days'
  AND status = 'decided'
GROUP BY decision_type;

P50은 대부분의 안건이 경험하는 기본 지연을 보여줍니다. P90이 지나치게 높다면 특정 승인자, 특정 결정 유형, 휴일 직전의 대기 같은 예외 상황이 팀 전체 일정에 영향을 주고 있다는 뜻일 수 있습니다.

3. 지연 원인을 상태별로 나눈다

모든 Decision Latency를 하나의 숫자로만 관리하면 개선 방향을 정하기 어렵습니다. 최소한 다음 상태를 구분하세요.

Draft: 질문과 선택지를 작성하는 단계
Waiting for input: 필수 자료나 담당자 의견을 기다리는 단계
Ready for decision: 결정에 필요한 정보가 준비된 단계
Waiting for approval: 승인자의 판단을 기다리는 단계
Decided: 선택안과 책임자가 확정된 단계

이렇게 나누면 Waiting for input이 긴 팀과 Waiting for approval이 긴 팀에 서로 다른 해결책을 적용할 수 있습니다.

승인 체계를 어떻게 단순화할까?

결정 유형별로 승인 수준을 나눈다

모든 결정을 같은 승인 절차에 넣지 말고 영향 범위와 되돌리기 어려운 정도에 따라 분류합니다.

등급	결정 기준	예시	권장 승인 방식
D0	쉽게 되돌릴 수 있고 영향 범위가 작음	UI 문구, 이펙트 색상	담당자가 즉시 결정하고 기록
D1	한 직군이나 한 기능에 영향	캐릭터 애니메이션 범위	기능 오너 1인 승인
D2	여러 직군의 일정이나 스코프에 영향	튜토리얼 단계 추가	PM 또는 제품 오너 1인 결정, 관련 직군 자문
D3	출시일, 예산, 플랫폼 계약처럼 되돌리기 어려움	출시 일정 변경	지정된 책임자 승인과 리스크 기록

핵심은 D2와 D3에만 명확한 상위 승인을 두는 것입니다. D0와 D1까지 리더 승인으로 올리면 상위 의사결정자는 사소한 안건을 처리하느라 중요한 결정을 늦추게 됩니다.

자문과 승인을 분리한다

Consulted는 의견을 제공하는 역할이고 Approver는 최종 결과에 책임지는 역할입니다. 문서에 두 필드를 따로 만들고 승인자는 한 명으로 제한하세요. 여러 명의 서명이 반드시 필요한 법무, 보안, 계약 관련 사안은 예외 규칙으로 별도 관리합니다.

실무 문구는 다음처럼 간결하게 쓸 수 있습니다.

의견은 관련 직군이 자유롭게 남긴다. 최종 승인자는 한 명이며 승인자는 모든 의견을 반영할 의무가 아니라 결정 이유를 기록할 의무를 가진다.

승인 기한과 에스컬레이션을 정한다

승인 요청에는 요청일과 필요한 결정일을 함께 적습니다. 예를 들어 D1은 영업일 1일, D2는 영업일 2일, D3는 영업일 5일 안에 판단하도록 기준을 둘 수 있습니다. 팀 규모와 리더의 가용 시간에 맞춰 조정하되 모든 유형에 동일한 기한을 적용하지는 않는 편이 좋습니다.

기한이 지나면 자동으로 결정을 간주하기보다 다음 순서로 에스컬레이션합니다.

승인자에게 미확인 상태를 알린다.
대체 승인자 또는 상위 책임자에게 전달한다.
일정 영향과 임시 실행안을 기록한다.
결정이 확정되면 임시 실행안을 유지할지 되돌릴지 명시한다.

자동 승인 규칙은 실패 비용이 낮고 되돌릴 수 있는 D0 또는 일부 D1 안건에만 적용해야 합니다.

게임 개발팀용 의사결정 문서 템플릿

짧은 문서 하나가 회의 여러 번을 대체하려면 질문과 권고안이 분리되어 있어야 합니다.

Decision ID:
결정 질문:
결정 유형: D0 / D1 / D2 / D3
Owner:
Approver:
결정이 필요한 날짜:
배경과 제약:
선택지 A:
선택지 B:
권고안:
일정 영향:
스코프 영향:
리스크와 되돌리기 조건:
최종 결정:
결정 이유:
후속 작업:

예를 들어 보스전 2단계에 신규 페이즈를 추가할 것인가?라는 질문에는 예상 개발일, QA 범위, 메모리 영향, 출시 일정 영향을 함께 적어야 합니다. 논의의 질을 높이는 자료와 결정을 늦추는 장황한 배경 설명을 구분하는 것이 중요합니다.

Decision Latency 개선 절차를 4단계로 적용하기

1단계: 최근 결정 20~30건을 표본으로 만든다

지난 30일의 스코프 변경, 일정 변경, 기능 승인, 아트 방향 결정을 모읍니다. 각 안건에 요청 시각, 확정 시각, 승인자, 결정 유형, 번복 여부를 채웁니다. 기록이 없다면 채팅과 이슈의 타임스탬프를 사용하되 추정값임을 표시합니다.

2단계: P50과 P90을 결정 유형별로 계산한다

전체 평균 하나보다 feature_scope, art_direction, release_schedule처럼 유형을 나누어 보세요. 특정 유형의 P90만 높다면 전사 프로세스를 바꾸기보다 해당 유형의 승인자와 입력 자료를 먼저 조정합니다.

3단계: 승인자를 한 명으로 지정하고 예외를 명시한다

각 결정 유형에 Owner, Approver, Consulted를 지정합니다. 승인자가 여러 명이면 누가 최종 타이브레이커인지 정하고 문서에 남깁니다. 계약, 보안, 법무처럼 다중 승인이 필요한 안건은 일반 흐름과 분리합니다.

4단계: 매주 상위 지연 안건만 리뷰한다

모든 결정의 내용을 다시 논의하지 말고 P90을 악화시킨 안건 3~5개만 확인합니다. 지연 사유가 정보 부족인지 승인 대기인지 책임자 부재인지 분류하고 다음 주에 바꿀 운영 규칙을 하나만 정합니다.

함께 보면 좋은 운영 지표

지표	의미	개선 신호
P50 Decision Latency	일반적인 결정 속도	기본 흐름이 빨라짐
P90 Decision Latency	긴 꼬리 지연	예외와 병목이 줄어듦
Approval Hops	승인자를 거친 횟수	불필요한 결재 단계가 감소함
Reopen Rate	확정 후 다시 열린 비율	결정 기준과 기록의 품질을 확인함
Reversal Rate	결정을 번복한 비율	빠르기만 한 결정의 부작용을 확인함
Stale Decision Rate	기한을 넘긴 미결정 비율	승인 SLA가 작동하는지 확인함

Decision Latency만 낮추면 좋은 것은 아닙니다. 너무 빠른 결정으로 번복률과 재작업률이 올라갈 수 있으므로 P90, Reopen Rate, Reversal Rate를 함께 봐야 합니다.

자주 묻는 질문 FAQ

Decision Latency와 업무 처리 시간은 같은가?

다릅니다. Decision Latency는 결정을 기다린 시간이고 업무 처리 시간은 결정 후 실제 작업에 걸린 시간입니다. 두 지표를 분리해야 일정 지연의 원인을 정확히 찾을 수 있습니다.

승인자를 한 명으로 줄이면 품질이 떨어지지 않는가?

자문 인원을 줄이는 것이 아니라 최종 책임자를 한 명으로 명확히 하는 방식입니다. 관련 직군의 의견은 유지하되 승인 조건을 모두의 동의로 만들지 않으면 속도와 책임성을 함께 관리할 수 있습니다.

P90이 높은데 어떤 안건부터 개선해야 하는가?

P90에 가장 크게 기여한 결정 유형과 승인자를 먼저 확인하세요. 지연 시간이 길고 발생 빈도도 높은 안건부터 입력 자료 템플릿, 승인 SLA, 대체 승인자 규칙을 적용하는 것이 효과적입니다.

정리

Decision Latency는 팀이 느리다는 인상을 실제 데이터로 바꾸는 지표입니다. 요청과 확정 시각을 표준화하고 P50과 P90을 결정 유형별로 측정하면 병목의 위치를 찾을 수 있습니다.

개선의 핵심은 승인 단계를 무조건 늘리거나 줄이는 데 있지 않습니다. 되돌릴 수 있는 결정은 가까운 담당자에게 위임하고 영향이 큰 결정만 한 명의 책임자에게 모으며 자문, 승인, 에스컬레이션 규칙을 문서화해야 합니다. 이렇게 운영하면 회의 수를 줄이는 것보다 중요한 변화인 결정의 예측 가능성을 확보할 수 있습니다.