일하는 시간을 절반으로 줄여본 한 달

왜 결제·정산 팀에서 대기 시간은 두 배로 비싸게 먹히는가

대부분의 소프트웨어 팀에서 PR 리뷰를 하루 기다리는 건 불편한 일이다. 그런데 결제와 정산을 직접 운영하는 팀에서는 이 불편함이 곧 금전적 리스크로 이어진다. 결제 로직에 버그가 있는 채로 하루가 지나면 잘못 집계된 정산 데이터가 쌓이고, 이를 되돌리는 비용은 버그를 처음 고치는 시간의 수 배가 된다. 우리가 한 달간 시간 사용을 기록하기로 한 건 단순한 효율성 실험이 아니었다.

자동화 파이프라인도 마찬가지다. HEDVION이 운영하는 정산 배치는 매일 특정 시간에 실행된다. 이 배치가 실패했는데 담당자가 슬랙 알림을 두 시간 뒤에야 확인한다면, 그 두 시간은 그냥 '대기'가 아니라 오류가 누적되는 시간이다. 일반적인 개발팀의 생산성 문제가 우리 맥락에서는 운영 리스크 문제로 직결된다. 이 맥락을 이해하고 나서야 측정 결과의 충격도 제대로 해석할 수 있다.

실험 설계: 도구는 단순하게, 분류는 정직하게

2월 말, 세 명이서 한 달간 작업 시간을 네 가지로 구분해 기록했다. 집중 작업(코드 작성, 설계, 분석), 커뮤니케이션(미팅, 슬랙, 문서 공유), 대기(PR 리뷰·배포 파이프라인·질문 응답 대기), 기타(환경 세팅, 도구 트러블슈팅). 별도 앱 없이 구글 스프레드시트 하나로 충분했다. 포인트는 도구가 아니라 분류 기준을 팀 전체가 동일하게 이해하는 것이었다.

가장 중요한 설계 결정은 '대기'를 독립 카테고리로 분리한 것이다. 대부분의 생산성 측정에서 대기는 '기타'에 묻히거나 커뮤니케이션에 포함된다. 하지만 대기는 능동적 행동이 없는 시간이라는 점에서 커뮤니케이션과 구조적으로 다르다. 이걸 별도로 드러내야만 문제의 원인을 제대로 볼 수 있고, 줄일 방법도 찾을 수 있다.

숫자가 드러낸 것: 집중 40%, 나머지 60%는 어디에 있었나

한 달 후 집계한 결과는 예상보다 충격적이었다. 세 명 평균으로 실제 가용 시간 대비 **집중 작업 비율이 약 40%**였다. 나머지 60% 중 커뮤니케이션이 25%, 대기가 22%, 기타가 13%를 차지했다. 커뮤니케이션과 대기를 합치면 전체 시간의 거의 절반이 사라지고 있었다.

대기 시간의 내역이 특히 문제였다. 대기 시간 중 PR 리뷰 대기가 약 45%, 배포 파이프라인 완료 대기가 약 30%, 질문 응답 대기가 약 25%였다. 실험 전 PR 리뷰 평균 대기 시간은 5~8시간이었다. 결제 로직 수정 PR이 오전에 올라오면 다음 날 오전에야 머지되는 경우도 있었다. 그 사이에 작성자는 컨텍스트를 잃고, 리뷰어는 컨텍스트 스위칭을 반복하고, 잠재적 버그는 코드베이스에 하루를 더 머문다. 결제 도메인처럼 트랜잭션 흐름과 상태를 동시에 머리에 담아야 하는 코드에서 이 비용은 단순 계산보다 훨씬 크다.

바꾼 것 세 가지와 실제 효과

PR 리뷰 SLA 명문화. "올라온 PR은 2시간 이내에 1차 피드백"이라는 약속을 팀 내에서 명시적으로 합의했다. 완전한 승인이 아니어도 된다. "지금 보기 어렵다, 오후 3시에 볼게"도 피드백이다. 이 변화 하나만으로 PR 평균 대기 시간이 58시간에서 1.52시간으로 줄었다. 도구 변경 없이, 팀 합의 하나만으로 즉각 효과가 나온 사례다.

비동기 커뮤니케이션 기본값 전환. "급하지 않으면 스레드에 남기고, 급하면 전화한다"는 원칙을 세우고 실제로 지켰다. 슬랙에서 즉각 응답을 기대하는 암묵적 압박을 의식적으로 해제한 것이다. 동시에 수동으로 클릭해야 했던 배포 체크리스트 세 단계(정산 배치 실행 여부 확인, 슬랙 알림 전송, 롤백 스크립트 준비)를 스크립트로 묶었다. 이전에는 이 과정이 평균 20~30분이었다. 자동화 이후 스크립트 실행부터 결과 확인까지 5분 이내로 줄었다. 한 달 후 재측정에서 집중 작업 비율은 40%에서 **62%**로 올랐고, 총 일하는 시간은 하루 평균 0.8시간 줄었는데 배포 횟수와 처리된 이슈 수는 비슷하거나 소폭 증가했다.

트레이드오프: 비동기가 모든 상황의 답은 아니다

실험 결과가 좋았다고 해서 비동기 원칙을 모든 상황에 적용하면 안 된다. 우리가 실제로 겪은 실패가 있다. 실험 3주차, 정산 배치에서 특정 PG사 응답 코드를 잘못 처리하는 버그가 발견됐다. 담당자가 슬랙에 텍스트로 이슈를 남겼고, 다른 팀원이 2시간 뒤 확인했다. 그 2시간 동안 오류는 계속 누적됐고, 수동 보정에 반나절이 걸렸다. 비동기 원칙이 운영 이슈에까지 무분별하게 적용된 결과였다.

이후 우리는 "개발 커뮤니케이션은 비동기, 운영 이슈는 즉각"이라는 규칙을 명확히 분리했다. 고비용 도구는 필요 없었다. 슬랙 채널을 #dev-general과 #ops-alert로 나누고, #ops-alert 멘션은 즉각 확인하는 팀 약속을 만든 것으로 충분했다. 이 구분이 생기자 비동기 원칙을 지키면서도 운영 리스크를 별도로 관리할 수 있게 됐다. 원칙을 도입할 때 예외 조건을 미리 설계하지 않으면 원칙이 리스크가 된다.

지금 바로 써먹을 수 있는 시사점

같은 실험을 시작하고 싶은 팀을 위한 구체적 시작점이다. 추상적 권고 없이, 우리가 실제로 쓴 방법만 적는다.

1. 1주일만 먼저 기록하라. 한 달이 부담스러우면 1주일로 시작한다. 스프레드시트에 30분 단위로 집중/커뮤니케이션/대기/기타를 구분해 기록하면 일주일 치만으로도 패턴이 보인다.

2. '대기'를 반드시 독립 항목으로 분리하라. 기타에 묻히는 순간 아무것도 보이지 않는다. 대기를 꺼내놔야 무엇을 기다리는지가 드러나고, 줄일 방법이 보인다.

3. PR 리뷰 SLA부터 먼저 실험하라. 대기 시간 중 PR 비중이 높다면, "2시간 이내 1차 피드백" 약속 하나만 먼저 해보라. 도구 도입 없이, 팀 합의 하나만으로 효과를 즉시 확인할 수 있다.

4. 운영 이슈는 비동기 원칙에서 반드시 예외 처리하라. 결제·정산·자동화처럼 오류가 누적되는 도메인은 개발 커뮤니케이션 채널과 운영 이슈 채널을 분리해야 한다. 채널 분리와 명시적 약속만으로도 치명적 신호를 놓치는 빈도를 크게 줄일 수 있다.

5. 사람이 기다리는 배포 구간을 스크립트로 묶어라. 반복적인 체크리스트, 알림 전송, 상태 확인처럼 사람이 대기하는 구간은 자동화 ROI가 가장 빠른 영역이다. 20~30분짜리 수동 작업이 5분짜리 스크립트로 바뀌는 순간, 그 절약은 매 배포마다 복리로 쌓인다.

"더 열심히"가 아니라 "덜 기다리게"가 생산성의 핵심 레버다. 결제와 정산을 운영하는 팀이라면 이 레버가 효율 문제를 넘어 리스크 관리 문제라는 것도 반드시 함께 고려해야 한다.