SF는 실무에서 언제 쓰나요?

교대와 전환 상황에 한정됩니다. 신 시스템 가동 시작이 구 시스템 운영 종료를 구속하는 컷오버, 인력 교대, 임대 장비 반납 같은 경우입니다. 다만 SF가 필요해 보이는 자리의 절반은 작업 정의를 바꾸면 사라집니다. "구 시스템 운영"을 상태가 아니라 "구 시스템 정지 작업"으로 잡으면 평범한 FS가 됩니다.

Lead와 Lag의 차이가 뭔가요?

Lag은 종속 관계에 얹는 기다림입니다. FS +7d는 대금 지급 대기처럼 아무도 일하지 않는 시간입니다. Lead는 겹침입니다. FS −5d는 선행이 끝나기 전에 후행을 미리 시작한다는 뜻입니다. 구현상 같은 축의 양수와 음수지만 의미가 다릅니다. 특히 Lead를 많이 쓴 일정은 빠른 일정이 아니라 재작업 리스크를 감수한 일정입니다.

종속성 대신 날짜를 고정하면 안 되나요?

결과가 같아 보여도 선행이 밀릴 때 동작이 정반대입니다. 종속성으로 묶인 후행은 함께 밀려 지연이 드러나고, 고정 날짜는 그 자리에 남아 "지연 없음"이라는 거짓 신호를 줍니다. 외부 계약·법정 기한처럼 진짜로 고정된 날짜만 제약으로 두고 나머지는 선으로 표현하십시오.

종속성이 순환(사이클)을 만들면 어떻게 되나요?

A→B→C→A처럼 순환이 생기면 일정 계산 자체가 불가능해집니다(어느 작업의 시작도 확정할 수 없습니다). 그래서 사이클은 계산 시점이 아니라 선을 추가하는 시점에 차단해야 합니다. 순환이 만들어졌다면 대개 작업 분해가 잘못됐다는 신호이므로, 선을 지우기 전에 두 작업의 경계를 다시 보십시오.

FS + Lag 3일과 후행 시작일을 3일 미루는 건 다른가요?

다릅니다. FS +3d는 선행의 끝을 기준으로 상대적으로 계산되므로 선행이 5일 밀리면 후행도 5일 밀립니다. 시작일을 3일 뒤로 직접 입력하면 그 날짜는 선행과 무관하게 고정되어, 선행이 밀려도 후행은 제자리에 남고 크리티컬 패스가 왜곡됩니다.

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

종속성(dependency)은 두 작업이 어떤 순서로 이어지는지 정해 두는 규칙이다. 선행 작업의 시작이나 끝이 후행 작업의 시작이나 끝을 구속한다. 그 조합이 4가지이고, 이름이 FS·SS·FF·SF다. 여기에 기다림이나 겹침을 나타내는 Lag·Lead를 얹으면 일정 논리를 거의 다 적을 수 있다.

종속성 4종을 정확히 구분해야 하는 이유

종속성은 간트차트를 꾸미는 화살표가 아니라 크리티컬 패스 계산에 그대로 들어가는 입력값이다. 선을 잘못 걸어도 계산은 멈추지 않는다. 잘못된 입력으로 뽑은 답이 그럴듯한 모습으로 화면에 나올 뿐이다.

종속성	읽는 법	언제 쓰는가
FS (Finish-to-Start)	선행이 끝나야 후행이 시작	산출물을 넘겨받아야 다음 일이 가능할 때 (기본형, 실무의 대부분)
SS (Start-to-Start)	선행이 시작해야 후행이 시작	병행하되 착수 순서만 있는 일 (개발 착수 후 테스트 케이스 작성)
FF (Finish-to-Finish)	선행이 끝나야 후행이 끝	함께 끝나야 하는 일 (개발 완료 없이는 코드 리뷰도 못 끝난다)
SF (Start-to-Finish)	선행이 시작해야 후행이 끝	교대·전환 (신 시스템 가동 시작 = 구 시스템 운영 종료)

FS는 기본값이고 실무의 대부분이다

가장 자연스러운 형태다. "설계서 승인이 끝나야 개발을 시작한다." 산출물이 다음 사람에게 넘어가는 지점에 선을 긋는다고 보면 된다.

FS를 기본으로 두고 시작하자. 나머지 3가지는 FS로 표현할 수 없을 때만 쓴다. 실제 프로젝트의 종속성 목록을 열어 보면 10개 중 8~9개가 FS인 것이 정상이다. FS 비중이 절반 아래로 떨어져 있다면 병행 작업을 억지로 SS로 묶었거나 선을 지나치게 많이 걸었을 가능성이 크다.

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

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

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

FF는 함께 끝나야 하는 일에 쓴다

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

감리·검수·문서화처럼 본 작업과 나란히 가는 일이 대개 FF다. 이런 일을 FS로 걸면(본 작업이 다 끝난 뒤 검수 시작) 실제로는 병행하는 작업이 일정에서 직렬로 길게 늘어난다.

SF는 드물지만 쓸 자리가 있다

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

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

실무에서는 SF를 쓰기 전에 작업 정의부터 다시 보자. "구 시스템 운영"을 작업으로 잡지 않고 "구 시스템 종료(정지 작업)"로 잡으면 평범한 FS가 된다. SF가 필요해 보이는 자리의 절반은 이렇게 작업을 다시 정의하면 풀린다.

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

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

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

둘은 같은 축의 양수·음수로 구현되지만 뜻이 다르므로 나눠서 생각하는 편이 안전하다. 규칙 3가지를 권한다.

기다림은 Lag으로 적고 가짜 작업을 만들지 않는다. "대금 지급 대기 7일"을 기간 7일짜리 작업으로 만들면 진척률과 공수 집계가 오염된다. 아무도 일하지 않는 시간은 작업이 아니다.
Lead는 리스크를 적어 두는 방식이다. 설계가 확정되기 전에 개발을 시작한다는 것은 재작업 가능성을 감수하겠다는 뜻이다. Lead가 많은 일정은 빠른 일정이 아니라 위험한 일정이다.
Lag 대신 후행 시작일을 고정하지 않는다. 결과가 같아 보여도 선행이 밀리면 정반대로 움직인다. Lag으로 걸어 둔 후행은 함께 밀리지만, 고정한 날짜는 그 자리에 남아 논리를 깨뜨린다.

선을 잘못 걸면 계산 결과가 틀린다

종속성을 잘못 건 대가는 바로 드러나지 않는다. 계산은 정상으로 끝나고 화면에는 그럴듯한 크리티컬 패스가 그려진다. 문제는 그 답이 틀렸다는 것이다.

대표적인 증상 3가지다.

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

3번째가 가장 흔하고 가장 위험하다. WBS와 간트를 다른 파일로 관리하면 거의 반드시 벌어지는 일이기도 하다(엑셀로 만든 계획은 만든 날부터 죽는다).

선택 가이드

두 작업의 관계를 한 문장으로 말해 보고 아래에서 고르면 된다.

상황을 말로 하면	답
"A의 산출물을 받아야 B를 한다"	FS
"A가 시작되면 B도 시작할 수 있다"	SS
"B는 A보다 먼저 끝날 수 없다"	FF
"A와 B는 같이 시작하고 같이 끝난다"	SS + FF (둘 다)
"A가 켜지면 B를 끈다"	SF
"A 끝나고 며칠 기다린 뒤 B"	FS + Lag
"A가 거의 끝나갈 때 B를 미리 시작"	FS + Lead (재작업 리스크 감수)
"B는 무조건 3월 1일 시작"	종속성이 아니라 제약(constraint)이다. 정말 필요한지 다시 검토

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

다음에 읽을 것

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

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