[PM온보딩] 프로젝트 시작 : 간트차트 작성

Jun 5. 2025

Chapter 4 간트차트 작성법

프로젝트를 데드라인에 맞게 이끌어가기 위해서는 간트차트를 통해 일정을 기록하고, 공유하는 것이 중요합니다.
간트차트는 ‘누가, 언제, 무엇을’ 할지를 한눈에 볼 수 있도록 시각화한 것으로, 전체 일정의 흐름을 파악하고 관리하는 데 도움을 줍니다.

프로젝트를 착수하면 팀원들이 제일 먼저 어려워하는 부분 중 하나가 바로 간트차트 작성인데요.
특히 전체 일정을 어떻게 잡아야 할지, 그리고 세부 항목을 어디까지 나눠야 할지 고민하는 경우가 많습니다.

이번에는 실무에서 사용하고 있는 간트차트 템플릿을 예시로 설명해보고자 합니다.

1. 큰 범위부터 태스크를 나눠보세요.

먼저 프로젝트를 기획, 디자인, 개발, QA, 하자보수 등 큰 단위의 태스크로 나누고, 이를 기준으로 1차 간트차트를 작성합니다.

2. 세부 일정은 점차 세분화하세요.

프로젝트가 진행되면서 일정이 구체화되기 시작합니다. 상시로 세부일정을 채워나가세요.
예:

디자인 전달 일정 (1차, 2차)

디자인 피드백을 받은 일자와 반영 일자 및 픽스 일자

화면 개발 일정

API 개발 일정 등

점점 세분화하여 간트차트를 정교하게 만들어갑니다.

3. QA 일정을 포함시키세요.

내부 QA와 클라이언트 QA 일정을 미리 확보해 두면 안정적인 마무리에 큰 도움이 됩니다.

4. 담당자를 표기하세요.

각 단계별로 PM, 디자이너, 프론트/백엔드 개발자, QA 담당자 등을 함께 표시하면 책임과 커뮤니케이션에 도움이 됩니다.

5. 일정은 ‘함께’ 조율합니다.

디자인팀, 개발팀과의 논의를 통해 팀 전체가 같은 로드맵을 바라보고 있어야 합니다.

6. ‘뒤에서 앞으로’ 역산해 보세요.

계약 종료일 및 런칭일에 따라
→ 종료일에서 QA 일정 확보
→ QA 이전에는 반드시 개발 완료
→ 개발을 완료해야 하는 일정에 따라 개발 기간 확보

위와 같이 역순으로 계획을 잡으면 각 태스크의 일정을 수립할 수 있습니다.

7. QA는 넉넉하게!

최소 2주 이상 확보를 권장합니다. 내부 QA와 클라이언트 QA를 모두 고려하세요.

8. 앱 심사 기간도 포함해 주세요.

앱 출시가 포함된 프로젝트라면, 앱 심사 소요 기간(최대 2주)을 미리 작성합니다.

9. 일정 변동 시 즉시 공유를 잊지 마세요.

일정 변동은 늘 발생할 수 있습니다. 빠르게 클라이언트와 논의하여 일정 재조정 사유 전달과 안내를 해주세요.

간트차트는 단순한 일정표를 넘어, 프로젝트의 지도를 그리는 일입니다. PM은 이 지도를 바탕으로 팀원들과 일정을 조율하고, 진행 상황을 트래킹해야 합니다.

무엇보다도, 클라이언트가 “지금 어디까지 진행됐나요?”라고 묻기 전에 간트차트를 통해 먼저 미리 공유하는 것이 중요합니다.

구글 시트 템플릿 예시를 통해 좀 더 자세히 들여다볼게요.

1. 프로젝트의 시작일과 종료일을 명시합니다.

- Project Start Date와 Project End Date를 명시하여 전체 일정의 기준을 잡습니다.

2. 큰 범위로 태스크를 구분합니다. 다음과 같이 상위 태스크를 나눠보았습니다.

a. 일정관리

b. 디자인

c. 프론트엔드 개발

d. 백엔드 개발

e. 검수

f. 하자보수

3. 포지션과 담당자 명시

- 각 작업 구분(예: PM, 디자인, FE, BE, QA 등)에 맞춰 담당자 이름을 함께 기입합니다.

4. 하위 태스크 구성 예시

<디자인> 상위 태스크의 하위에는 다음과 같은 세부 작업을 포함했습니다.

a. 디자인 컨셉

b. UX UI 디자인

위와 같이 큰 범위로 태스크를 나누고 담당자를 기입하는 것이 첫 번째 단계입니다.

1. 프로젝트 종료일을 기준으로 역산하여 QA 일정을 작성합니다.

종료일이 2025년 8월 29일이므로

a. 외부 (=상호) QA를 8월 25일 ~ 8월 29일 (1주)

b. 내부 QA를 8월 18일 ~ 8월 22일 (1주)

로 설정합니다.

2. 하자보수는 프로젝트 종료일 다음 날부터 시작되는 일정으로 기입합니다.

프로젝트 종료 다음날인 9월 1일부터 시작하여, 계약 또는 정책에 따라 일정 기간을 작성합니다.

이처럼 종료일 → QA → 개발 → 디자인 순으로 역산하면, 필요한 기간 확보가 눈에 보이고 우선순위를 기반으로 간트차트를 좀 더 현실적으로 계획할 수 있습니다.

1. <일정관리> 상위 태스크 내에 아래와 같이 하위 태스크를 추가했습니다.

a. 고객사 킥오프 : 프로젝트 시작과 함께 고객사와의 첫 미팅 및 요구사항 조율.

b. 리소스 관리 : 디자이너, 개발자, QA 등 각 포지션별 리소스를 관리합니다.

b-1. 간트차트 작성 : 전체 일정을 한눈에 파악할 수 있도록 간트차트를 구성하며, 이후의 모든 일정 계획 수립의 기준이 됩니다.

c. 기능정의서 작성 : 실제 개발에 필요한 기능들을 정의하고 문서화합니다.

c-1. 내부 기능 리뷰 : 내부 팀원들에게 먼저 리뷰 후, 공수 판단과 조율을 진행합니다.

c-2. 외부 기능 리뷰 : 클라이언트 또는 외부 파트너에게 리뷰를 통해 기능을 조율합니다.

2. <디자인> 상위 태스크 내에 아래와 같이 하위 태스크를 추가했습니다. : 본격적인 디자인 UI 작업에 앞서 디자인 컨셉이 선행되어야 합니다.

a. 디자인 컨셉 : 디자인 초기 방향성을 제시하기 위해 톤 앤 매너 및 메인 화면의 시안을 전달합니다.

a-1. 디자인 컨셉 인터뷰 : 클라이언트와의 인터뷰를 통해 서비스의 톤 앤 매너 방향성과 기대 수준을 먼저 파악합니다.

a-2. 디자인 컨셉 시안 작업 : 수집된 인터뷰를 바탕으로 디자인 시안 작업을 진행합니다.

a-3. 디자인 컨셉 피드백 : 시안에 대한 피드백을 수집합니다.

a-4. 디자인 컨셉 피드백 반영 : 피드백 내용을 토대로 시안을 수정 및 개선합니다.

b. UX/UI 디자인 : 위에서 컨펌이 난 디자인 컨셉을 토대로 전체 서비스 흐름을 고려하여 본격적인 상세한 화면 디자인을 작업합니다.

이와 같이 간트차트의 계층 구조(Level)를 활용해 상위 태스크와 하위 태스크를 나누어, 일정의 흐름을 기록합니다.

또한, <디자인> 하위 태스크와 같이 인터뷰 → 시안 작업 → 피드백 → 반영 순으로 작성하면, 클라이언트나 협업자와의 조율 시 일정 예측과 커뮤니케이션에 도움이 됩니다.

1. 기능정의서에 정의된 화면(Page) 기준으로 UI 디자인 작업 일정을 세분화하여 작성해 보았습니다.

디자인 업무를 하나로 통으로 잡기보다는, 기능정의서 항목을 기반으로 화면 단위로 세부 태스크를 나누어 작성하였습니다. 각 페이지 별로 피드백과 반영 일정이 상이할 수 있고 어느 화면에서 병목 현상이 일어났는지를 빠르게 파악할 수 있습니다.

상위 태스크인 <UX UI 디자인>에 각 페이지별로 하위 태스크를 세분화합니다.

각 화면별로 "피드백" → "피드백 반영 및 컨펌" 단계로 구성하여, 디자인 피드백과 수정 반영까지의 흐름을 시각화했습니다.

1. 스플래시

2. 메인 (판매 리스트)

3. 판매 상세

4. 글쓰기 (= 내 물건 팔기)

5. 마이페이지

6. 프로필 수정

7. 판매물품 (= 나의 판매내역)

페이지 별로 작업 소요 일수를 나누고 담당자와 시작/종료일을 나눠 일정 트래킹이 가능하도록 작성했습니다.

1차적으로 작성해 놓은 기능정의서의 기준이 되는 화면 단위로 일정을 나누면, 전체 작업이 막연하게 느껴지지 않고, 우선순위와 병렬 작업이 가능한 구간을 파악하는데 도움이 됩니다.

간트차트를 통해 현재 위치와 다음 단계를 팀원들과 공유하면서 프로젝트 흐름을 정돈하고 일정 지연을 예방할 수 있습니다.

1. 디자인 일정이 어느 정도 그려졌다면, 컨펌이 난 화면에 따라 마무리되는 시점에 맞춰 프론트엔드 및 백엔드 개발 일정을 병렬적으로 설계하는 것이 중요합니다. 개발 일정은 디자인 컨펌 속도에 따라 타이트해질 수도 있기에, 디자인 완료 시점을 기준으로 개발 리소스를 효율적으로 활용해야 합니다.

2. 프론트엔드 개발 일정은 퍼블리싱과 API 연동을 나눠, 각 디자인 컨펌이 난 화면 단위로 병렬적으로 작업을 진행하여 개발 기간을 확보합니다. 프론트 개발을 위한 세팅 후 -> 우선적으로 퍼블리싱을 진행하고 -> 이후 백엔드에서 개발한 API 연동 작업을 진행합니다.