일정 버퍼와 리스크 관리 기초 — 늦어질 것을 전제로 계획 세우기

프로젝트·일정 · 실용 가이드 · 2026. 09. 25 · 작성 rohan

계획대로 끝난 프로젝트를 몇 번이나 보셨나요. 대부분은 늦어지고, 그때마다 "이번엔 예상 못 한 일이 있어서"라고 말합니다. 그런데 예상 못 한 일은 매번 있습니다. 이 글은 일정이 늦어지는 구조적 이유에서 출발해, 버퍼를 어디에 얼마나 두는지, 버퍼 소진율을 신호등으로 읽는 법, 리스크 목록 양식과 대응 4가지, 그리고 리스크가 실제로 터졌을 때 재계획하는 순서를 정리합니다. 마지막에는 3~5명 팀에서 회의 없이 굴릴 수 있는 최소 버전을 붙였습니다. 일정 전체를 짜는 4단계 흐름은 프로젝트 일정 관리 방법, 어떤 작업이 핵심 경로인지 계산하는 법은 크리티컬 패스 계산법에서 다루고, 이 글은 그 일정에 얹는 여유와 위험 대비에만 집중합니다.

왜 일정은 늘 늦어지나 — 세 가지 구조적 원인

일정이 늦어지는 것은 팀이 게을러서가 아닙니다. 계획을 세우는 방식 자체에 늦어질 수밖에 없는 구조가 들어 있습니다. 원인을 알아야 버퍼를 어디에 얼마나 둘지 정할 수 있습니다.

• 낙관 편향. 사람은 "모든 게 잘 풀렸을 때" 걸리는 시간을 추정합니다. 5일이라고 말한 작업은 대개 "방해가 없고 요구사항이 안 바뀌면 5일"입니다. 실제로는 그런 주가 거의 없습니다. 게다가 상사 앞에서는 숫자를 더 줄여 말합니다.
• 의존성. 작업 A가 끝나야 B가 시작되는 사슬에서는 A의 지연이 그대로 B에 전달됩니다. 반대로 A가 일찍 끝나도 B의 담당자가 준비되어 있지 않으면 그 이득은 사라집니다. 지연은 전파되고 조기 완료는 흡수되지 않는 비대칭이 누적 지연을 만듭니다.
• 인터럽트. 운영 장애, 다른 프로젝트 지원, 갑작스러운 회의. 계획에는 없지만 매주 일정 비율로 반드시 옵니다. 순수 작업 시간을 하루 8시간으로 잡은 계획은 팀에 따라 다르지만 처음부터 20~30%쯤 모자라는 경우가 흔합니다. 지난 2주 동안 계획에 없던 일에 쓴 시간을 한 번 적어 보면 자기 팀의 비율이 나옵니다.

이 세 가지는 없앨 수 없습니다. 그래서 "늦어지지 않게 하자"가 아니라 "늦어질 것을 전제로, 그래도 마감을 지키는 구조"를 만드는 것이 버퍼 관리입니다.

버퍼의 종류 — 작업 버퍼·프로젝트 버퍼·피딩 버퍼

버퍼(buffer)는 계획에 의도적으로 넣어 둔 여유 기간입니다. 어디에 두느냐에 따라 세 종류로 나뉘는데, 이 구분은 핵심 사슬 프로젝트 관리(CCPM, Critical Chain Project Management)에서 정리된 개념입니다. 이론 전체를 몰라도 세 가지 위치만 알면 실무에 충분합니다.

종류	위치	역할	권장 여부
작업 버퍼	각 작업 기간 안에 숨어 있음("5일이면 되는데 7일로")	담당자 개인의 안전장치	없애거나 최소화. 눈에 안 보이고 다 소모됨
피딩 버퍼	핵심 경로가 아닌 가지가 핵심 경로에 합류하는 지점	곁가지의 지연이 핵심 경로로 번지지 않게 막음	합류점마다 작게
프로젝트 버퍼	핵심 경로의 끝, 마감 바로 앞	프로젝트 전체의 지연을 한 곳에서 흡수	반드시. 가장 큰 버퍼

핵심 경로가 무엇인지, 어떤 작업이 곁가지인지는 크리티컬 패스 계산법에서 다뤘습니다. 여기서는 "가장 긴 사슬의 끝에 큰 버퍼 하나, 거기에 합류하는 가지마다 작은 버퍼 하나"로 기억하면 됩니다.

버퍼 크기는 어떻게 정하나 — 세 가지 방법

방법 1. 경로 길이의 비율로

가장 빠른 방법입니다. 작업 기간을 "보통 걸리는 시간"(낙관치가 아닌 50% 확률로 끝나는 시간)으로 잡은 뒤, 그 사슬 길이의 일정 비율을 버퍼로 둡니다. CCPM에서는 흔히 사슬 길이의 절반을 말하지만, 이미 각 작업에 여유가 조금씩 들어 있는 보통의 팀이라면 프로젝트 버퍼 20~30%, 피딩 버퍼 10~15% 정도가 현실적입니다. 핵심 경로가 영업일 40일이면 프로젝트 버퍼 8~12일입니다.

방법 2. 3점 추정으로

불확실한 작업은 낙관치(O)·최빈치(M)·비관치(P) 세 값을 받아 (O + 4M + P) ÷ 6으로 기대 기간을 구합니다. 예를 들어 "잘되면 3일, 보통 5일, 꼬이면 12일"이면 (3+20+12)÷6 ≈ 5.8일입니다. 이때 (P − O) ÷ 6이 그 작업의 표준편차(≈1.5일)인데, 경로 위 작업들의 편차를 제곱해서 더한 뒤 제곱근을 내면 경로 전체의 편차가 나옵니다. 그 값의 1~2배를 버퍼로 둡니다. 계산이 부담스러우면 각 작업의 (P − M)을 모아 그 합의 절반을 버퍼로 잡는 약식도 씁니다.

방법 3. 과거 데이터로

가장 정확한 방법입니다. 지난 프로젝트에서 계획 대비 실제 기간의 비율을 작업 유형별로 기록해 둡니다. "외부 검토는 평균 1.6배, 개발은 1.3배, 문서 작업은 1.1배"처럼 나오면, 그 유형의 작업 사슬에 (비율 − 1)만큼 버퍼를 둡니다. 데이터가 없으면 이번 프로젝트부터 마일스톤별 계획일과 실제일을 기록하는 것으로 시작합니다. 세 번만 쌓여도 감이 크게 달라집니다.

버퍼는 어디에 두나 — 숨기지 말고 끝에 모아서

실무에서 가장 흔한 실패는 담당자마다 자기 작업에 버퍼를 몰래 넣는 것입니다. 이러면 세 가지 일이 벌어집니다. 첫째, 버퍼가 얼마인지 아무도 모릅니다. 둘째, 학생 증후군(마감 직전에 시작)과 파킨슨 법칙(주어진 시간을 다 씀) 때문에 버퍼는 그냥 소진됩니다. 셋째, 일찍 끝나도 다음 담당자가 준비가 안 돼 이득이 사라집니다.

대신 이렇게 둡니다.

1. 작업 기간은 "보통 걸리는 시간"으로 잡고, 담당자에게 "이 기간은 50% 확률로 끝나는 시간이고 늦어도 책임을 묻지 않는다, 대신 버퍼를 따로 둔다"고 명시적으로 말합니다. 이 합의가 없으면 아무도 낙관치를 내놓지 않습니다.
2. 간트차트에 "프로젝트 버퍼"라는 이름의 행을 마감 직전에 넣습니다. 이 사이트의 WBS·간트차트 도구에서는 마지막 단계의 마지막 하위 행으로 '버퍼(영업일 8일)'처럼 넣으면 막대로 보이고, 전체 기간에도 자동 반영됩니다.
3. 핵심 경로에 합류하는 가지 끝에도 "피딩 버퍼" 행을 작게 둡니다. 예를 들어 '디자인 → 개발 합류' 지점에 2일.
4. 버퍼가 얼마나 소진됐는지는 버퍼 행의 비고 칸에 "소진 3/8일"처럼 적습니다. 진행율 칸에 소진 비율을 넣고 싶어지지만, 이 도구는 버퍼 행도 일반 작업처럼 업무량(영업일)에 합산하고 진행율 가중평균에 넣기 때문에, 버퍼를 많이 쓸수록 단계와 전체 진행율이 좋아 보이는 역효과가 납니다.

같은 이유로 버퍼 행의 날짜가 지나가면 진행율을 100%로 바꿔 두세요. 종료일이 지났는데 100% 미만인 행은 자동으로 "지연" 상태가 되어, 실제로는 문제가 없는데 지연 건수에 잡힙니다. 버퍼를 전부 쓰지 않고 끝났다면 남은 일수만큼 버퍼 행의 종료일을 당겨 마감을 앞당길지 팀이 판단하면 됩니다.

버퍼를 눈에 보이게 두면 "그 8일 있으니 기능 하나 더 넣자"는 요청이 반드시 옵니다. 그때 답은 정해져 있습니다. 버퍼는 이미 예상되는 지연을 위해 쓰인 시간이지 남는 시간이 아니라는 것입니다. 단계별 버퍼 배분 예시는 프로젝트 일정 관리 방법에도 있습니다.

버퍼 소진율 모니터링 — 진행 % 대비 소진 % 신호등

버퍼를 끝에 모아 두면 프로젝트의 건강을 숫자 하나로 볼 수 있습니다. 핵심 경로가 얼마나 진행됐는지(진행 %)와 버퍼가 얼마나 소진됐는지(소진 %)를 비교하는 것입니다. 소진 %는 "핵심 경로의 지연 누적 일수 ÷ 버퍼 총 일수"입니다.

상태	기준	예(버퍼 10일)	행동
초록	소진 % < 진행 %	진행 50%, 지연 누적 3일(소진 30%)	정상. 그냥 둠
노랑	소진 % ≥ 진행 %, 그러나 100% 미만	진행 50%, 지연 누적 6일(소진 60%)	회복 계획 준비. 원인 작업 파악, 자원 재배치 검토
빨강	소진 % ≥ 100%, 또는 남은 진행률보다 남은 버퍼가 훨씬 적음	진행 50%, 지연 누적 10일 이상	즉시 실행. 범위 축소·마감 협상·인력 투입 중 하나를 결정

이 표의 좋은 점은 초반 지연에 과민반응하지 않게 해 준다는 것입니다. 진행 20%에 버퍼 15%를 썼다면 초록입니다. 반대로 진행 80%에 버퍼 40%만 썼어도 안심할 수는 있지만, 마지막 20%에 통합·테스트가 몰려 있다면 남은 버퍼 60%가 순식간에 사라지기도 합니다. 그래서 신호등은 매주 같은 요일에 기록해 추세를 봅니다. 3주 연속 소진 %가 진행 %보다 빠르게 오르면 색과 무관하게 노랑으로 취급합니다.

진행 %는 핵심 경로 작업들의 업무량 가중 진행율로 계산합니다. 도구의 대시보드에서 단계별 진행율을 읽어 쓰면 되고, 진행율을 매기는 규칙은 프로젝트 진행율 계산법을 따릅니다.

리스크 목록 양식과 대응 4가지

리스크 목록 — 다섯 열이면 충분하다

버퍼는 "무언가 늦어질 것"에 대한 일반적 대비이고, 리스크 관리는 "무엇이 늦출 것인가"를 구체적으로 적어 두는 것입니다. 둘은 짝입니다. 리스크 목록이 있어야 버퍼 크기의 근거가 생기고, 버퍼가 있어야 리스크가 터졌을 때 대응할 시간이 있습니다. 양식은 다섯 열입니다.

리스크	확률	영향	대응	담당
PG사 테스트 계정 발급 지연	중(3)	상(3) — 결제 연동 1주 지연	완화: 착수 2주 전 신청, 모의 서버로 병행 개발	백엔드 리더
핵심 개발자 1명 이탈	하(1)	상(3) — 4주 지연	완화: 코드 리뷰로 지식 공유, 문서화 주 1회	PM
고객 요구사항 변경	상(3)	중(2) — 화면 재작업	회피: 요구사항 동결 마일스톤 후 변경은 다음 버전으로	PO
디자인 외주 납품 지연	중(2)	중(2)	전가: 계약에 지연 시 감액 조항, 중간 납품 2회	디자인 리더
추석 연휴 전후 생산성 저하	상(3)	하(1)	수용: 연휴 주간 업무량 50%로 계획	PM

확률과 영향은 상·중·하 3단계(또는 1~3점)면 충분합니다. 5단계로 나누면 정밀해지는 게 아니라 논쟁만 늘어납니다. 확률 × 영향이 6 이상(상×중 이상)인 항목만 매주 보고서에 올리고, 나머지는 목록에만 둡니다. 리스크는 보통 5~15개 사이가 관리 가능한 개수이고, 프로젝트 시작 때 팀이 30분 브레인스토밍으로 뽑은 뒤 격주로 갱신합니다.

리스크 대응 4가지 — 회피·완화·전가·수용

• 회피(avoid) — 리스크가 생기는 원인을 계획에서 제거합니다. 검증 안 된 신기술 도입이 위험하면 이번 프로젝트에서는 익숙한 기술을 씁니다. 요구사항 변경이 위험하면 동결 마일스톤을 두고 그 뒤 변경은 다음 버전으로 보냅니다. 가장 확실하지만 무언가를 포기해야 합니다.
• 완화(mitigate) — 확률이나 영향을 줄입니다. 외부 계정 발급이 늦을 수 있으면 2주 일찍 신청하고(확률 감소), 그동안 모의 서버로 개발을 진행해 둡니다(영향 감소). 실무에서 가장 많이 쓰는 대응입니다.
• 전가(transfer) — 영향을 다른 쪽이 지게 합니다. 외주 계약에 지연 시 감액 조항을 넣거나, 보험을 들거나, 위험한 부분을 전문 업체에 맡깁니다. 리스크가 사라지는 게 아니라 비용으로 바뀌는 것입니다.
• 수용(accept) — 아무것도 하지 않기로 결정합니다. 확률이 낮거나 대응 비용이 영향보다 크면 그렇게 합니다. 대신 터졌을 때 쓸 버퍼를 확보해 둡니다. "몰라서 안 한 것"과 "알고 수용한 것"은 사후 평가가 전혀 다릅니다.

대응 열에 이 네 단어 중 하나를 먼저 쓰고 구체 행동을 붙이면(위 표처럼), 팀이 그 리스크를 어떤 태도로 보는지가 분명해집니다.

리스크가 현실이 됐을 때 — 재계획 순서

리스크가 터지면 첫 반응은 대개 "일단 더 열심히"입니다. 그러나 야근으로 메울 수 있는 지연은 2~3일까지입니다. 그 이상이면 계획을 다시 세워야 하고, 순서가 있습니다.

1. 영향 범위를 숫자로 확정합니다. 어떤 작업이 며칠 밀리는지, 그 작업이 핵심 경로인지 확인합니다. 핵심 경로가 아니면 여유시간 안에서 흡수되고 끝납니다.
2. 버퍼 소진율을 갱신합니다. 지연 일수를 프로젝트 버퍼에서 차감하고 신호등 색을 다시 봅니다. 초록이면 재계획 없이 버퍼만 씁니다.
3. 노랑·빨강이면 범위 → 자원 → 일정 순으로 조정 수단을 검토합니다. 먼저 이번 마일스톤에서 뺄 수 있는 범위가 있는지, 다음으로 사람을 옮기거나 병행할 수 있는지(패스트트래킹), 마지막으로 마감을 옮길지 순입니다. 마감을 먼저 옮기는 것은 가장 쉽고 가장 나쁜 선택입니다.
4. 조정 결과를 간트차트에 반영하고 뒤따르는 작업의 시작일을 다시 계산합니다. 이 사이트 도구에서는 밀린 작업의 종료일을 고치면 영업일 기준 업무량과 상위 그룹의 기간은 다시 계산되지만, 의존 관계 기능이 없어 후행 작업의 날짜는 자동으로 밀리지 않습니다. 비고 칸에 적어 둔 선행 관계를 따라 뒤 작업을 한 줄씩 옮기고, 마지막으로 프로젝트 버퍼 행이 얼마나 줄었는지 확인합니다.
5. 이해관계자에게 알립니다. 무엇이 왜 바뀌었고 마감에 영향이 있는지 없는지를 한 문단으로. 이 단계를 빼면 다음에 리스크를 미리 말할 때 아무도 믿지 않습니다.
6. 리스크 목록에 "현실화됨"으로 표시하고 대응이 효과가 있었는지 한 줄 기록합니다. 다음 프로젝트의 버퍼 산정 데이터가 됩니다.

재계획의 세부 절차와 예시는 프로젝트 일정 관리 방법의 '변경이 생겼을 때 재계획 순서'를 함께 보세요.

외부 의존에는 유독 큰 버퍼를 두는 이유

승인·심사·납품·발급처럼 우리가 통제하지 못하는 작업은 다른 작업과 성격이 다릅니다. 내부 작업은 늦으면 야근·인력 추가·범위 조정 같은 수단이 있지만, 외부 작업은 기다리는 것 외에 할 수 있는 게 거의 없습니다. 게다가 외부의 "3영업일"은 그쪽 기준의 정상 상황에서의 3일이고, 서류 미비나 담당자 부재가 끼면 쉽게 두 배가 됩니다.

• 외부 작업의 약속 기간에는 50~100%를 얹습니다. 5영업일 검토 약속이면 8~10일로 계획합니다. 내부 작업의 20~30%와 비교하면 큰 숫자지만, 경험상 여기서 남는 경우는 드뭅니다.
• 외부 작업은 가능한 한 앞당겨 시작합니다. 결과가 필요한 시점이 아니라 신청 가능한 가장 이른 시점에 신청합니다. 이 한 가지가 외부 리스크의 절반을 없앱니다.
• 외부 작업 앞에 "제출물 내부 검토" 작업을 하루 넣습니다. 반려의 대부분은 서류 미비이고, 반려 한 번이면 전체 기간이 두 배가 됩니다.
• 외부 담당자의 휴가·연휴를 미리 묻습니다. 도구의 공휴일 관리에 등록한 날은 모든 작업에서 빠지므로, 상대측만 쉬는 날은 공휴일로 넣지 말고 그 외부 작업의 종료일을 휴무 일수만큼 늘리는 편이 정확합니다. 연휴 처리 요령은 영업일 계산법을 참고하세요.

작은 팀을 위한 최소 버전

3~5명 팀에서 CCPM 용어를 다 쓸 필요는 없습니다. 아래 다섯 가지만 지켜도 효과의 대부분을 얻습니다.

1. 작업 기간은 "보통 걸리는 시간"으로 잡고, 팀에 "늦어도 괜찮다, 버퍼가 따로 있다"고 말한다.
2. 간트차트 맨 끝에 "버퍼" 행 하나를 전체 기간의 20% 크기로 둔다. 외부 의존이 있으면 그 앞에 하나 더.
3. 리스크는 5개만 적는다. 리스크·확률·영향·대응·담당 다섯 열. 격주로 5분 갱신.
4. 매주 금요일 "진행 % / 버퍼 소진 %" 두 숫자를 적고 초록·노랑·빨강을 표시한다.
5. 노랑이 2주 연속이면 범위를 먼저 줄인다. 마감을 옮기는 것은 마지막이다.

이 최소 버전은 회의 없이도 굴러갑니다. 핵심은 버퍼가 눈에 보이는 곳에 있고, 소진 여부를 매주 숫자로 확인한다는 두 가지입니다. 이 둘이 없으면 어떤 정교한 방법도 "이번엔 정말 열심히 하자"로 돌아갑니다.

자주 묻는 질문

버퍼를 두면 팀이 그만큼 느슨해지지 않나요?

각 작업 안에 버퍼를 숨겨 두면 그렇게 됩니다. 마감 직전에 시작하는 학생 증후군과 주어진 시간을 다 쓰는 파킨슨 법칙 때문입니다. 그래서 작업 기간은 보통 걸리는 시간으로 짧게 잡고, 버퍼는 프로젝트 끝에 '버퍼'라는 이름의 행으로 모아 둡니다. 개별 작업은 빠듯하게 움직이고 지연은 공용 버퍼에서 흡수하므로, 오히려 팀은 긴장을 유지하면서도 마감을 지킬 수 있습니다.

버퍼 크기는 몇 %가 적당한가요?

작업 기간을 낙관치에 가깝게 잡았다는 전제에서 프로젝트 버퍼는 핵심 경로 길이의 20~30%, 피딩 버퍼는 가지 길이의 10~15%가 현실적인 출발점입니다. 승인·납품 같은 외부 의존 작업은 약속 기간의 50~100%를 얹습니다. 정확한 값은 지난 프로젝트의 계획 대비 실제 기간 비율을 작업 유형별로 기록해 두면 얻을 수 있으니, 이번 프로젝트부터 마일스톤별 계획일과 실제일을 남기세요.

버퍼 소진율은 어떻게 계산하고 언제 위험한가요?

핵심 경로의 지연 누적 일수를 버퍼 총 일수로 나눈 값이 소진율입니다. 이를 핵심 경로의 진행율과 비교해, 소진율이 진행율보다 낮으면 초록, 진행율 이상이면 노랑, 100%에 이르렀거나 남은 진행분에 비해 남은 버퍼가 훨씬 적으면 빨강입니다. 매주 같은 요일에 기록해 추세를 보고, 3주 연속 소진율이 진행율보다 빠르게 오르면 색과 무관하게 노랑으로 다룹니다.

리스크 대응 4가지(회피·완화·전가·수용)는 어떻게 고르나요?

원인을 계획에서 아예 없앨 수 있으면 회피, 확률이나 영향을 줄이는 행동이 가능하면 완화, 계약이나 보험으로 영향을 다른 쪽이 지게 할 수 있으면 전가, 확률이 낮거나 대응 비용이 영향보다 크면 수용입니다. 실무에서는 완화가 가장 많고, 수용은 아무것도 하지 않기로 '결정'한 것이므로 터졌을 때 쓸 버퍼를 확보해 두어야 합니다. 대응 열에 네 단어 중 하나를 먼저 쓰고 구체 행동을 붙이면 팀의 태도가 분명해집니다.

정리

일정은 낙관 편향·의존성·인터럽트 때문에 구조적으로 늦어집니다. 그래서 작업 기간은 보통 걸리는 시간으로 잡고, 여유는 각 작업에 숨기지 말고 프로젝트 끝의 프로젝트 버퍼와 합류점의 피딩 버퍼로 모아 눈에 보이게 둡니다. 크기는 경로 길이의 20~30%에서 시작해 3점 추정과 과거 데이터로 다듬고, 외부 의존 작업에는 50~100%를 얹습니다. 매주 진행 % 대비 버퍼 소진 %를 신호등으로 기록하고, 리스크는 다섯 열 양식에 5~15개만 적어 회피·완화·전가·수용 중 하나로 대응을 정합니다. 리스크가 터지면 범위 → 자원 → 일정 순으로 조정하고 이해관계자에게 알립니다. 작은 팀이라면 버퍼 행 하나, 리스크 5개, 금요일 숫자 두 개로 시작해도 충분합니다.

→ 크리티컬 패스 계산법 · → 프로젝트 일정 관리 방법 · → 주간 업무 보고서 쓰는 법