8주 일정이 13주가 되는 구조 — 웹사이트 제작 지연을 대기행렬로 분석하기

초록#

웹사이트 제작 일정이 밀리면 대화는 대부분 "개발이 늦다"로 시작합니다. 그런데 프로젝트 기간을 작업시간(touch time)과 대기시간(wait time)으로 분해해 보면, 늘어난 부분의 대부분은 아무도 작업하지 않는 구간에 있습니다.

이 글은 웹사이트 제작 일정을 승인 게이트가 직렬로 연결된 대기행렬로 모델링합니다. 총 기간을 T = 작업시간 + Σ(게이트별 왕복 횟수 × 회신 지연)으로 두고 감도를 계산하면, 작업시간 30영업일짜리 프로젝트에서 평균 회신 지연이 1일에서 5일로 늘어날 때 총 기간은 37일에서 65일로 76% 증가합니다. 개발 속도는 한 시간도 느려지지 않았는데 일정은 두 배 가까이 됩니다.

두 번째 변수는 제작사 쪽에 있습니다. 대기행렬 이론의 킹먼 근사식에 따르면 대기시간은 활용률 ρ에 대해 ρ/(1-ρ)로 증가합니다. 제작사가 동시에 돌리는 건수가 여유 상태(ρ=0.5)에서 과부하(ρ=0.9)로 가면 대기 배수는 1배에서 9배로 뜁니다. 즉 "이 업체가 지금 몇 건을 동시에 하고 있는가"는 견적서의 어떤 숫자보다 일정 예측력이 높습니다.

결론은 반직관적입니다. 일정을 지키는 가장 값싼 수단은 개발을 재촉하는 게 아니고 회신을 빨리 하는 것입니다.

1. 서론#

1.1 관찰#

제작사가 제시하는 표준 일정표는 대개 이렇게 생겼습니다. 기획 2주, 디자인 3주, 퍼블리싱·개발 4주, 검수 1주. 합계 10주. 그런데 실제로 오픈하는 시점은 14주, 16주, 때로는 그 이상입니다.

여기서 흔한 두 가지 해석이 있습니다. "제작사가 일정을 낙관적으로 잡았다"와 "요구사항이 늘어났다". 둘 다 부분적으로 맞습니다. 그러나 이 해석들은 범위가 하나도 늘지 않았는데도 일정이 밀리는 흔한 경우를 설명하지 못합니다.

1.2 이 글의 관점#

제조와 제품개발 분야에서는 리드타임 분석에 오래된 도구가 있습니다. 리드타임을 작업하고 있는 시간과 기다리는 시간으로 나눠 보는 방식입니다. 소프트웨어·디자인처럼 승인 단계가 많은 일에서는 후자가 지배적인 경우가 많습니다.

이 관점을 웹사이트 제작에 적용하면 질문이 바뀝니다. "왜 개발이 느린가"가 아니라 "이 프로젝트에는 대기 지점이 몇 개이고 각 지점에서 며칠씩 서 있는가"가 됩니다.

1.3 이 글에서 다루는 것#

1. 웹사이트 제작 일정을 승인 게이트 직렬 대기행렬로 모델링하고 감도를 수치로 적었습니다.
2. 지연의 발생원을 세 종류(승인 대기, 자산 대기, 결정권 대기)로 분류하고 각각의 처방이 다름을 보입니다.
3. 발주자가 계약 전에 확인할 수 있는 일정 위험 신호와, 계약서에 넣을 수 있는 일정 보호 문장을 제시합니다.

1.4 이 글의 수치에 대한 주의#

4절과 6절의 숫자는 명시된 가정 위에서 계산한 모델 값이며, 실제 프로젝트를 표본 조사한 통계가 아닙니다. 목적은 "며칠 걸린다"를 예측하는 게 아니고 어느 변수가 결과를 지배하는지를 보이는 데 있습니다. 가정은 모두 본문에 적어 두었으니 자신의 상황에 맞게 바꿔 계산하세요.

2. 배경: 두 종류의 시간#

2.1 작업시간과 대기시간#

프로젝트 총 리드타임은 두 부분으로 나뉩니다.

• 작업시간: 누군가가 실제로 그 일에 손을 대고 있는 시간. 디자이너가 시안을 그리고, 개발자가 코드를 쓰는 시간.
• 대기시간: 결과물이 만들어진 채로 다음 단계를 기다리는 시간. 시안이 완성됐지만 발주자가 아직 안 봤고, 개발이 끝났지만 원고가 안 왔고, 담당자는 봤지만 결정권자가 출장 중인 시간.

이 둘의 비율을 흐름 효율(flow efficiency)이라고 부릅니다.

흐름 효율 = 작업시간 ÷ 총 리드타임

승인 단계가 많은 지식 노동에서 이 값은 흔히 낮습니다. 중요한 것은 개선 여지가 어디에 있는지를 이 비율이 알려 준다는 점입니다. 흐름 효율이 40%라면, 작업 속도를 20% 올려도 총 기간은 8%밖에 줄지 않습니다. 반면 대기시간을 절반으로 줄이면 총 기간이 30% 줄어듭니다.

즉 개선의 지렛대는 큰 쪽에 있습니다.

2.2 리틀의 법칙#

대기행렬 이론의 기본 관계식입니다(J. D. C. Little, 1961).

L = λ × W
   L: 시스템 안에 있는 평균 항목 수 (진행 중인 일)
   λ: 도착률 (단위 시간당 새로 들어오는 일)
   W: 평균 체류시간 (하나가 끝날 때까지 걸리는 시간)

이걸 제작사에 적용하면 이렇게 읽힙니다.

W = L ÷ λ
   → 동시에 진행 중인 프로젝트가 많을수록(L↑),
      완료 속도가 그대로라면(λ 고정) 하나당 걸리는 시간은 길어진다.

여기에 발주자가 알아야 할 함의가 있습니다. 우리 프로젝트가 늦는 이유가 우리 프로젝트 안에 없을 수 있습니다. 제작사가 동시에 여섯 건을 돌리고 있으면, 우리 시안 검토 요청은 다른 다섯 건의 요청 뒤에 줄을 섭니다.

2.3 킹먼 근사 — 바쁠수록 비선형으로 느려진다#

대기시간이 활용률에 어떻게 반응하는지는 킹먼(J. F. C. Kingman, 1961)의 근사식이 잘 보여 줍니다. 일반적인 단일 서버 대기행렬에서 평균 대기시간은 대략 이렇게 움직입니다.

Wq ≈ [(변동성 항)] × [ρ / (1 - ρ)] × [평균 처리시간]
   ρ: 활용률 (0~1). 서버가 얼마나 바쁜가

가운데 항만 떼어 보겠습니다.

활용률이 0.8에서 0.9로 12% 오를 때 대기시간은 2.25배가 됩니다. 이 비선형성이 실무에서 체감되는 방식은 이렇습니다. 평소에 이틀이면 오던 회신이, 제작사가 조금 바빠졌을 뿐인데 갑자기 2주가 됩니다. 제작사가 게을러진 것이 아니라 줄이 임계 구간에 들어간 것입니다.

여기서 나오는 실무 질문: 견적 단계에서 "지금 동시에 몇 건 진행 중이신가요? 저희 건에 몇 명이 몇 % 붙나요?"는 예의 없는 질문이 아니라 일정 예측에 가장 직접적인 질문입니다.

3. 모델: 승인 게이트 직렬 대기행렬#

3.1 구조#

웹사이트 제작은 발주자의 승인 없이는 다음 단계로 못 넘어가는 지점이 여러 개 있습니다. 이를 게이트라고 부르겠습니다.

주황색 상자에서는 아무도 작업하지 않습니다. 제작사는 회신을 기다리고, 발주자는 내부 검토 중입니다.

3.2 식#

T = P + Σᵢ (nᵢ × dᵢ) + B

  T  : 총 리드타임 (영업일)
  P  : 순수 작업시간 합계
  nᵢ : 게이트 i의 왕복 횟수 (1회면 한 번에 승인, 2회면 수정 후 재승인)
  dᵢ : 게이트 i에서의 평균 회신 지연
  B  : 자산 대기 등 차단성 대기 (원고·사진·계정 미제공으로 작업 자체가 멈춘 기간)

3.3 기준 시나리오의 가정#

아래 계산에 쓴 가정을 명시합니다.

• 순수 작업시간 P = 30영업일 (약 6주)
• 게이트 5개
• 게이트당 평균 왕복 n = 1.4회 (10번 중 4번은 한 번 수정 후 재승인)
• 자산 대기 B는 시나리오별로 지정
• 영업일 기준, 주 5일

4. 감도 분석#

4.1 회신 지연이 총 기간에 미치는 영향#

B = 0, 즉 자산은 모두 제때 제공됐다고 두고 회신 지연만 바꿉니다.

읽는 법: 개발 공수는 30일로 고정입니다. 한 줄도 안 늘었습니다. 그런데 "시안 보고 일주일 안에 회신"이라는, 대기업 결재 기준으로는 오히려 빠른 습관 하나가 일정을 6.7주에서 13주로 밀어냅니다.

흐름 효율로 보면 마지막 줄은 30 ÷ 65 = 46%입니다. 프로젝트의 절반 이상이 아무도 일하지 않는 시간입니다.

4.2 자산 대기가 얹힐 때#

원고와 사진이 늦게 오는 경우를 더합니다. 이건 회신 지연과 성격이 다릅니다. 작업 자체가 멈추기 때문입니다.

시나리오 D에서 발주자가 체감하는 것은 "제작사가 넉 달 걸렸다"입니다. 실제로 제작사가 손을 댄 기간은 6주입니다.

4.3 어느 지렛대가 큰가#

시나리오 C(61일)에서 각각 하나씩만 개선했을 때의 결과입니다.

개발 속도를 20% 올리는 것보다 회신을 이틀 빨리 하는 쪽이 더 큽니다. 그리고 앞의 셋은 발주자 쪽에서 비용 없이 통제 가능한 반면, 개발 속도 20% 향상은 인력을 더 투입해야 하는 유상 개선입니다.

5. 대기의 세 종류와 각각의 처방#

지연을 뭉뚱그리면 처방도 뭉뚱그려집니다. 발생원을 나눠야 합니다.

5.1 승인 대기 — "봤는데 아직 못 정했다"#

원인: 검토는 시작됐으나 내부 의견이 갈리거나 우선순위에서 밀립니다.

증상: 회신이 오긴 오는데 "조금 더 보겠다"가 반복됩니다.

처방

• 검토 SLA를 계약에 넣습니다. "발주자는 산출물 제출 후 3영업일 이내에 서면 회신한다. 미회신 시 승인으로 본다."
• 결정 규칙을 미리 정합니다. 시안 검토 전에 "무엇을 기준으로 고를지"(예: 브랜드 톤, 주 고객층 연령, 경쟁사 대비 차별점)를 합의해 두면 취향 다툼이 판정으로 바뀝니다.
• 의견 창구를 한 명으로 모읍니다. 다섯 명이 각각 제작사에 메일을 보내면 왕복 횟수 n이 그만큼 늘어납니다.

5.2 자산 대기 — "원고와 사진이 아직"#

원인: 텍스트·이미지·제품 정보를 발주자가 제공하기로 했는데 준비가 안 됐습니다.

증상: 디자인은 나왔는데 더미 텍스트로 채워져 있고, 그 상태로 검토가 안 됩니다.

이것이 가장 흔하면서 가장 과소평가되는 지연 원인입니다. 계약 시점에는 "원고는 저희가 드릴게요"가 부담 없어 보이는데, 실제로 회사 소개 문구를 쓰는 일은 아무도 하고 싶어 하지 않는 일이기 때문입니다.

처방

• 착수 전에 자산 목록과 마감일을 문서로 고정합니다. 페이지별로 필요한 텍스트 분량과 이미지 수를 표로 받으십시오.
• 담당자를 지정합니다. "마케팅팀에서"가 아니라 사람 이름으로.
• 대체안을 미리 정합니다. "마감일까지 미제공 시 임시 문구로 오픈하고 이후 교체" 같은 합의가 있으면 프로젝트가 멈추지 않습니다.

이 영역의 비용·범위 문제는 별도로 다룰 만큼 큽니다. 견적서의 "콘텐츠 별도" 한 줄이 실제로 무엇을 의미하는지는 원고와 사진은 누가 준비하나에서 따로 정리했습니다.

5.3 결정권 대기 — "위에서 아직 못 봤다"#

원인: 실무 담당자에게 승인 권한이 없고, 결정권자는 프로젝트에 붙어 있지 않습니다.

증상: 3주 동안 순조롭다가 최종 보고 때 전면 재검토가 나옵니다. 이건 지연 중에서도 가장 비쌉니다. 대기시간이 아니라 작업시간까지 버려지기 때문입니다.

처방

• 결정권자를 게이트에 배치합니다. 최소한 게이트 1(기획 확정)과 게이트 3(디자인 확정)에는 결정권자가 직접 참여해야 합니다.
• 되돌릴 수 없는 지점을 미리 알립니다. "이 시점 이후 구조 변경은 추가 비용과 일정이 발생합니다"를 문서로.
• 초기 게이트를 무겁게, 후기 게이트를 가볍게 설계합니다. 앞에서 되돌리는 비용이 뒤에서 되돌리는 비용보다 훨씬 쌉니다.

6. 배치 크기라는 반직관적 변수#

여기서 흔한 오해를 하나 봅니다. "피드백을 모아서 한 번에 주면 왕복 횟수가 줄어 빨라진다"는 생각입니다.

식에서 보면 그럴듯합니다. n이 줄어드니까요. 그런데 실제로는 반대 효과가 더 큽니다.

작은 배치로 자주 주고받는 쪽이 대개 빠릅니다. 화면 20개 디자인을 전부 기다렸다가 한 번에 검토하는 것보다, 핵심 화면 3개를 먼저 확정하고 나머지를 그 규칙으로 전개하는 편이 훨씬 낫습니다. 초기 3개에서 방향이 틀렸다면 17개를 다시 그리지 않아도 되기 때문입니다.

실무 규칙: 게이트를 줄이되, 남긴 게이트를 앞으로 당기십시오. 게이트 수를 줄이는 것과 검토를 미루는 것은 다른 일입니다.

7. 발주자가 계약 전에 확인할 것#

일정 위험은 계약서에 서명하기 전에 상당 부분 예측 가능합니다.

7.1 제작사에게 던질 다섯 질문#

세 번째 질문이 특히 유용합니다. 일정표에 발주자 검토 기간이 칸으로 그려져 있는 제작사는 이 문제를 이미 겪어 본 곳입니다.

7.2 계약서에 넣을 일정 보호 문장#

□ 발주자 검토 기한
   "발주자는 각 산출물 제출일로부터 3영업일 이내에 서면으로
    승인 또는 수정 요청을 통지한다."

□ 미회신 처리
   "기한 내 통지가 없는 경우 승인한 것으로 본다."

□ 발주자 귀책 지연의 일정 조정
   "발주자의 자료 미제공 또는 회신 지연으로 발생한 기간은
    전체 일정에서 제외하며, 그에 상응하여 납기가 연장된다."

□ 제작사 귀책 지연
   "제작사의 귀책으로 납기가 [n]영업일을 초과하여 지연되는 경우
    지연 일수당 계약금액의 [x]%를 감액한다."

□ 자산 제공 마감일
   "발주자는 별첨 자산 목록을 [날짜]까지 제공한다.
    미제공 시 임시 자료로 진행하고 이후 교체하되,
    교체 작업은 [범위] 내에서 무상으로 한다."

세 번째와 네 번째는 쌍으로 넣어야 공정합니다. 발주자 귀책 조항만 있으면 제작사에게 유리한 계약이 되고, 제작사 귀책 조항만 요구하면 협상이 어려워집니다. 둘을 함께 제시하면 양쪽 다 받아들이기 쉽습니다. 계약서의 나머지 조항 구성은 웹사이트 제작 계약서의 일곱 조항에 정리해 두었습니다.

8. 한계#

1. 모델의 단순화. 실제 프로젝트에서 작업 단계는 완전한 직렬이 아니라 부분적으로 병렬입니다. 개발이 진행되는 동안 다른 페이지 디자인이 함께 돌아갑니다. 병렬화는 총 기간을 줄이지만, 게이트에서의 대기는 병렬화되지 않습니다. 그래서 이 모델은 대기 항목의 상대적 중요도를 오히려 과소평가하는 방향입니다.
2. 가정값의 임의성. 게이트당 왕복 1.4회, 작업시간 30일 같은 값은 예시입니다. 자기 프로젝트의 값으로 바꿔 계산하세요. 결론(대기가 지배한다)은 가정을 꽤 넓게 바꿔도 유지되지만, 개별 숫자는 그대로 인용할 값이 아닙니다.
3. 킹먼 근사의 적용 범위. 원래 단일 서버 대기행렬의 근사식이며, 제작사를 하나의 서버로 보는 것은 거친 단순화입니다. 정량 예측이 아니라 "바쁜 업체는 비선형으로 느려진다"는 정성적 함의로 받아들이십시오.
4. 범위 변경은 별도 요인. 이 모델은 범위가 고정된 상태를 가정합니다. 요구사항이 실제로 늘어나는 경우는 여기에 더해집니다.

9. 결론#

제작 기간이 늘어질 때 대부분의 대화는 작업시간을 두고 벌어집니다. 인력을 더 넣을 수 있는지, 야근이 가능한지. 그런데 모델을 세워 보면 그 항목은 총 기간의 절반 이하이고, 개선하려면 돈이 듭니다.

나머지 절반은 아무도 일하지 않는 시간이고, 이 부분은 대부분 발주자 쪽 습관으로 결정되며, 줄이는 데 비용이 들지 않습니다. 회신을 사흘에서 하루로 당기는 일, 원고를 착수 전에 준비하는 일, 결정권자를 첫 게이트에 앉히는 일. 셋 다 청구서가 발생하지 않습니다.

그래서 일정 관리의 실질적 출발점은 제작사를 재촉하는 게 아니고 우리 쪽 게이트를 그려 보는 것입니다. 게이트가 몇 개인지, 각 게이트에서 누가 결정하는지, 그 사람이 며칠 안에 답할 수 있는지. 이 셋을 착수 전에 적어 두면, 위 표에서 우리가 어느 줄에 앉게 될지가 그 자리에서 보입니다.

요구사항을 문서로 만드는 앞 단계는 요구사항이 정리가 안 될 때에, 업체 검증 항목은 홈페이지 제작 업체 고르는 법에 있습니다.

부록. 자기 프로젝트로 계산해 보기#

1) 게이트를 세십시오
   기획 확정 / 시안 선택 / 디자인 확정 / 중간 확인 / 검수
   → 우리 프로젝트의 게이트 수 = ____ 개

2) 각 게이트에서 결정하는 사람을 적으십시오
   결정권자가 게이트마다 다르면 그만큼 지연 위험이 큽니다.

3) 우리 조직의 평균 회신 지연을 정직하게 적으십시오
   최근 외부 업체 메일에 며칠 만에 답했는지 떠올려 보십시오.
   → d = ____ 영업일

4) 자산 준비 상태를 확인하십시오
   원고 완성  □   사진 촬영 완료  □   로고 원본 확보  □
   하나라도 비어 있으면 B에 최소 5일을 잡으십시오.

5) 계산
   T = P + (게이트 수 × 1.4 × d) + B
   P는 제작사가 제시한 순수 작업 일수를 쓰십시오.

6) 비교
   계산된 T가 제작사 제시 일정보다 크다면,
   그 차이가 바로 "우리가 만들 지연"입니다.
   이 숫자를 착수 회의에서 공유하는 것만으로도 절반은 줄어듭니다.

참고 자료#

• J. D. C. Little, A Proof for the Queuing Formula: L = λW, Operations Research, 1961.
• J. F. C. Kingman, The single server queue in heavy traffic, Mathematical Proceedings of the Cambridge Philosophical Society, 1961.
• Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas Publishing, 2009 — 제품개발에서 대기행렬이 지연의 근원이라는 관점과 배치 크기 논의.
• Niklas Modig & Pär Åhlström, This is Lean, Rheologica Publishing, 2012 — 흐름 효율 개념.