간트차트 종속성 4종(FS·SS·FF·SF)과 Lead/Lag 완전 정리

종속성(dependency)은 두 작업 사이의 시간 약속이다. 선행 작업의 시작 또는 끝이, 후행 작업의 시작 또는 끝을 구속한다 — 그 조합이 네 가지이고 이름이 FS·SS·FF·SF 다. 여기에 기다림이나 겹침을 표현하는 Lag·Lead 를 얹으면 일정 논리를 거의 다 적을 수 있다.

종속성이 약속하는 것

이 네 개를 정확히 쓰는 것이 왜 중요한가. 종속성은 화살표를 그리는 장식이 아니라 크리티컬 패스 계산의 입력이다. 선을 잘못 걸면 계산은 여전히 성실하게 돌아가고, 틀린 답을 자신 있게 내놓는다.

FS — 기본값이자 실무의 대부분

가장 자연스러운 형태다. "설계서 승인이 끝나야 개발을 시작한다." 산출물이 손을 넘어가는 지점이 곧 선이 된다.

FS 를 기본값으로 두고 시작하는 것이 좋은 전략이다. 나머지 세 개는 FS 로 표현할 수 없을 때만 쓴다. 실제 프로젝트의 종속성 목록을 열어 보면 8~9할이 FS 인 것이 정상이다. FS 비중이 절반 아래로 떨어져 있다면, 십중팔구 병행 작업을 억지로 SS 로 묶고 있거나 선을 남용하고 있다.

SS — 나란히 가는 일의 착수 순서

"개발이 시작되면 테스트 케이스 작성도 시작할 수 있다." 두 작업은 병행하지만 착수에는 순서가 있다. 이때 FS 로 걸면(개발이 끝나야 테스트 케이스 작성 시작) 일정이 불필요하게 뒤로 밀린다.

주의할 함정이 하나 있다. SS 는 끝을 구속하지 않는다. 개발이 3개월, 테스트 케이스 작성이 2주라면 SS 만으로는 테스트 케이스가 개발보다 두 달 먼저 끝나도 논리 위반이 아니다. "같이 시작하고 같이 끝나야 한다"를 원한다면 SS 와 FF 를 둘 다 걸어야 한다.

FF — 함께 끝나야 하는 일

"코드 리뷰는 개발이 끝나기 전에 끝날 수 없다." 리뷰는 개발 도중에 시작하지만, 마지막 커밋이 리뷰되지 않은 채로 리뷰를 종료할 수는 없다. 후행의 끝이 선행의 끝에 매인다.

감리·검수·문서화처럼 본 작업을 따라다니는 일이 대개 FF 다. 이런 일을 FS 로 걸면(본 작업이 다 끝난 뒤 검수 시작) 실제로는 병행하는 작업을 일정에서 직렬로 길게 늘여 놓게 된다.

SF — 드물지만 있어야 하는 자리

"신 시스템이 가동을 시작하면 구 시스템 운영을 종료한다." 후행(구 시스템 운영 종료)의 끝이 선행(신 시스템 가동)의 시작에 매인다.

SF 가 드문 이유는 사람의 사고 방향과 반대이기 때문이다 — 우리는 보통 "구 시스템을 내려야 신 시스템을 올린다"처럼 앞에서 뒤로 생각한다. 그래서 SF 가 필요한 자리는 대개 교대(handover)·전환(cutover) 상황으로 한정된다. 병행 운영 기간이 있는 시스템 전환, 인력 교대, 임대 장비 반납 같은 경우다.

실무 조언: SF 를 쓰기 전에 작업 정의를 다시 보라. "구 시스템 운영"을 작업으로 잡지 않고 "구 시스템 종료(정지 작업)"로 잡으면 평범한 FS 로 표현된다. SF 가 필요해 보이면 절반은 모델링을 바꿔 해결된다.

Lead 와 Lag — 부호가 아니라 의미로 구분한다

Lag(지연) 은 선 위에 얹는 기다림이다. "계약 서명 후 착수까지 대금 지급 7일"처럼 아무도 일하지 않지만 시간이 필요한 구간이다. FS +7d 로 적는다.

Lead(선도) 는 겹침이다. "설계가 80% 쯤 되면 개발을 미리 시작한다"를 FS −5d 로 적는다.

둘은 같은 축의 양·음수로 구현되지만 의미가 다르므로 구분해서 생각하는 편이 안전하다. 세 가지 규율을 권한다.

• 기다림은 Lag 으로, 가짜 작업으로 만들지 말 것. "대금 지급 대기 7일"을 duration 7일 작업으로 만들면 진척률·공수 집계가 오염된다. 아무도 일하지 않는 시간은 작업이 아니다.
• Lead 는 리스크의 표현이다. 설계가 확정되기 전에 개발을 시작한다는 것은 재작업 가능성을 감수한다는 뜻이다. Lead 를 많이 쓴 일정은 빠른 일정이 아니라 위험한 일정이다.
• Lag 을 후행 시작일 고정으로 대체하지 말 것. 결과는 같아 보이지만 선행이 밀렸을 때 동작이 정반대다. Lag 은 함께 밀리고, 고정 날짜는 그 자리에 남아 논리를 깨뜨린다.

잘못 걸면: 크리티컬 패스가 거짓말을 한다

종속성 오류의 대가는 즉시 눈에 보이지 않는다. 계산은 정상적으로 끝나고, 화면에는 그럴듯한 크리티컬 패스가 그려진다. 문제는 그 답이 틀렸다는 것이다.

세 가지 대표적인 증상:

• 선이 빠졌다 → 여유(float)가 실제보다 크게 나온다. "이 작업은 15일 여유가 있으니 늦어도 괜찮다"고 판단했다가, 빠진 선이 드러나는 순간 여유가 0 이 된다. 우리가 실제 프로젝트에서 겪은 그 장면은 한 작업이 3일 밀리면, 전체는 며칠 밀리는가에 기록했다 — 3일 지연을 넣었는데 전체 지연이 0일로 나왔고, 그 0일이 문제였다.
• 선을 남용했다 → 실제로는 병행 가능한 작업이 직렬로 묶여 크리티컬 패스가 길어진다. 일정이 저절로 늘어난다.
• 날짜를 고정했다 → 선 대신 시작일을 박아 두면 선행이 밀려도 후행이 움직이지 않는다. 계산 결과는 "지연 없음"인데 현실은 붕괴한다.

세 번째가 가장 흔하고 가장 위험하다. WBS 와 간트를 별도 파일로 관리할 때 거의 필연적으로 벌어지는 일이기도 하다(엑셀로 만든 계획은 만든 날부터 죽는다).

선택 가이드

앞의 작업과 뒤의 작업 관계를 한 문장으로 말해 보고, 아래에서 고른다.

마지막 줄이 실무에서 가장 자주 오용된다. 외부 계약이나 법정 기한처럼 진짜 고정된 날짜만 제약으로 두고, 나머지는 선으로 표현하는 것이 원칙이다. 제약이 많은 일정은 계산이 되지 않는 일정이다.

다음에 읽을 것

종속성을 걸기 전에 작업 목록 자체가 정확해야 한다. 무엇을 쪼갤 것인가는 WBS 작성법에서 다섯 단계로 정리했다.

wbsgantt 는 FS·SS·FF·SF 네 종류와 Lead/Lag 를 그대로 지원하고, 선을 추가하는 순간 사이클(순환 참조)을 트랜잭션 안에서 차단하며, 크리티컬 패스를 자동으로 다시 계산한다. 여유가 0 이 된 작업은 상세 패널에서 즉시 경고로 표시된다 — 위의 첫 번째 증상("선이 빠져서 여유가 과대 표시되는")을 사람이 눈으로 찾지 않아도 되게 만드는 것이 목표다.