성과로 이어지는 프로젝트 개요 작성법 (원페이지 템플릿 제공)

기억에 남아야 성과로 인정받는다

IT 회사에 10년째 근무하면서 무수히 많은 프로젝트 이름을 들었습니다. 'OOO 시스템 구축', 'A-B 시스템 통합' 등 직관적인 이름부터 '대동단결', '남극횡단', 'OO박멸' 등 위트를 더한 이름까지. 시간이 꽤 흐른 지금, 이름만 들어도 내용이 단번에 생각나는 프로젝트가 있는 반면 진행을 통해 어떤 점이 바뀌었는지 결과가 도무지 떠오르지 않는 미지의 프로젝트도 많습니다.

제가 생각하는 성공하는 프로젝트와 실패하는 프로젝트의 가장 큰 차이는 결국 '사람들의 기억 속에 정확하게 포지셔닝되었느냐'인 것 같습니다. 하나의 예를 들어 볼게요. 

A라는 프로젝트에 대해 동료들은 '이런 소문을 들었는데요'라며 '소문', '추정'이라는 단어를 사용하여 애매모호하게 설명합니다. '어, 제가 아는 버전과 다른데요?' 등 많은 이들이 동일한 프로젝트에 대한 기대 결과를 동상이몽하기도 합니다. 

반면 B 프로젝트는 동료들의 이해도가 높습니다. '프로덕트팀에서 9월 오픈 목표로 소셜 로그인 도입을 준비 중인데, 프로젝트가 끝나면 간편가입이 가능해진대요. 자사몰 회원 가입 단계를 간소화하고, 궁극적으로 회원 수 확대를 기대할 수 있다던데요?' 이처럼 핵심이 모두에게 잘 전달되는 프로젝트가 있습니다.

A와 B프로젝트 중 어떤 게 더 성공 가능성이 높을까요? 당연히 모두가 같은 이해를 하고, 같은 기대를 하는 B프로젝트겠죠. 결국은 많은 사람들에게 지금 하고 있는 일들을 정확하게 설명해야 계획대로 일이 착착 진행되고, 서로의 이해가 달라서 하게 되는 커뮤니케이션이나 불필요한 리소스 낭비를 막을 수 있기 때문입니다. 

또 아무리 프로덕트의 상세 정책을 잘 정리하고, 좋은 레퍼런스로 손꼽힐 만한 차세대 시스템을 도입해도 사실상 사람들 기억에 남지 않는다면 기업에서 인정받는 성과로 이어지기 어렵습니다. 

이를 가능하게 하는 것이 바로 한 장의 프로젝트 개요 문서입니다. 이 문서는 해당 과제를 시작한 지 일주일 안에 작성하는 것을 추천합니다. '아무것도 정해진 게 없는데요?' 라고 반문하실 수 있는데, 우리 회사만 이상한 것이 아니라 IT 업계의 프로젝트가 늘 그렇습니다.

저 역시 10년 동안 이 일을 하면서 프로젝트 킥오프 일주일 만에 모든 것이 완벽하게 확정되고 시작하는 프로젝트는 본 적이 없습니다. 다만, 이 문서가 진행하는 프로젝트의 스케치가 되며, 결정되는 사항과 논의 사항을 계속 수정 반영해 가면서 프로젝트의 형상을 완성하는 데 큰 도움이 될 수 있습니다. 

곧 2025년 새로운 한 해가 시작되니 또 많은 부서에서는 새로운 프로젝트를 시작하고 프로젝트 달성을 위해 향해 최선을 다해 달려갈 것입니다. 이 글을 읽는 분들도 각자의 위치에서 크고 작은 프로젝트 하나씩은 담당하게 될 텐데요.

올해는 나만의 성장과 성과가 아닌 회사에서의 좋은 평가로 인정받는 프로젝트 진행을 위해, 회사 내에 내 이름 석 자를 널리 알릴 수 있는 프로젝트 매니저가 될 수 있는 팁을 공유합니다. 

기억에 남는 프로젝트로 포지셔닝할 수 있는 원페이지 기획서는 아래의 6가지 항목을 포함합니다. 각 항목별로 어떻게 작성하면 좋을지를 예시와 함께 소개하겠습니다.

• 요약
• 배경과 목표
• 제약 조건
• 서비스 주요 Flow
• 플랫폼 영향도
• 프로젝트 대시보드

요약: 기억에 남는 한 줄로 '상상력' 방지하기

사실 원페이지 기획서는 익숙한 개념입니다. 서점에 가면 책장 하나를 빼곡하게 채울 만큼 원페이지 기획안에 대한 무수히 많은 책을 볼 수 있습니다. 하지만 여러 작성 팁을 숙지하고 열심히 공부했어도, 10년 차인 저마저 기획서 첫 줄을 작성하는 것이 무척 어려운데요. 

저는 원페이지 기획서도 읽기 힘든 바쁜 현대인들을 위해, 문서의 가장 첫 줄에는 항상 '프로젝트 요약' 문장을 담습니다.

첫 문단이 '배경'과 '목적'이라면 프로젝트에 대한 배경 지식이 없는 사람이 어떤 프로젝트인지 상상해가며 내용을 읽는 데 시간을 쓰게 됩니다. 그래서 이 문서에서 앞으로 소개할 프로젝트가 어떤 내용인지 첫 줄에 딱 한 문장으로 설명해주는 겁니다.

저는 아래 세 가지 요약문 중 하나를 골라 쓰는 편입니다. 

배경과 목표: 솔직·명확하게 'Why'를 해결하기

요약 문장 다음에는 프로젝트의 '목표'와 '배경'을 꼭 기재해줍니다. 뻔하지만 해당 과제가 시작한 배경을 명확하게 설명해 주는 것이 많은 사람들의 'why?'를 해결해주는 중요한 역할을 하거든요. 

목표는 완성되는 프로덕트의 형상 혹은 프로젝트의 골을 상세하게 설명해주는 역할을 한다고 보시면 됩니다. 한 줄의 요약에 담지 못한 내용들을 조금 더 기재해주고, 주요 타겟과 제공하는 기능 그리고 어떤 효과를 기대해볼 수 있을지를 미리 정의합니다.

사실 탑다운 과제일 경우 '위에서 시키는 일'을 우아하게 포장하기 위해 다른 변명을 찾는 실수를 범하는데요. 그 과정에서 오히려 일의 당위성에 대한 질문과 논의가 불필요하게 길어지는 경우가 많습니다. 대신 진솔하게 탑다운 과제고, 일정은 언제로 박혀 있고, 다만 이 일을 했을 때 어떤 기여도가 있는지를 잘 설명해주는 것이 중요합니다. 

저는 과제를 어떻게 시작했느냐를 중심으로 아래와 같이 3가지로 나눠 배경을 설명하고는 합니다. 

바텀업 과제를 진행하기 위해서는 의사결정자들이 해당 과제에 대한 리소스를 투입할 수 있는 명분을 명확하게 설명해줘야 합니다. 정성적인 유저 보이스를 기술하기보다는 정확한 숫자로 진행 배경을 설명해 줍니다.

예를 들어, '해당 기능을 오픈했을 때 0명 정도로 예상되는 타겟군이 해당 기능을 사용할 수 있고, 그 결과 0% 정도의 플랫폼 참여도를 높일 수 있다' 정도로 설명해주면 좋습니다. 

제약 조건: 한계를 미리 정의하고 설명하기

개인적으로 프로젝트 문서의 가장 중요하다고 생각하는 부분이 바로 '제약 조건'을 정확하게 정의하고 시작하는 것이라고 볼 수 있습니다. 이번 프로젝트의 적용 범위와 한계점을 인지시키는 부분인 거죠. 

제가 사회 초년생때는 '대통합', '차세대' 등의 이름을 붙이고 구축 기간만 무려 1년 넘는 프로젝트들이 정말 많았는데요. 점차 애자일·스프린트 등의 개념이 보편화되고 장기 프로젝트의 여러 단점을 인지하기 시작하면서 요즘은 조금 더 짧은 호흡으로 프로젝트를 진행하는 일이 잦습니다. 그러면서 어쩔 수 없이 프로젝트 범위에서 제외되는 것들이 생겨나고는 합니다. 

만약 제약 조건을 명확하게 설명하지 않는다면, 프로젝트가 끝난 후에 '이건 왜 안 되어 있죠?' '이걸 보고했었나요?' 등의 등골 시린 피드백을 받기 쉽습니다. 프로젝트에 대한 확대 해석도 여기서 나오게 됩니다. 

하여, 프로젝트의 적용 범위 및 한계점을 사전에 정의하고 프로젝트에 관심이 있는 이들에게 미리 알려주는 것이 무척 중요합니다. 일정(리소스)상 적용 제외되거나 기존 시스템 디펜던시*로 인해 불가한 스펙이 있다면 미리 정확하게 알려줍니다. 그 예시는 아래와 같습니다.

* 시스템 디펜던시: 시스템 의존성, 통상적으로 프로젝트를 진행하면서 A 시스템 변경 시 B 시스템이 영향을 받아 함께 개선·대응 작업이 필요한 경우 보통 시스템 디펜던시가 있다고 표현합니다.

플로우 차트: '이래도 되나?' 싶을 만큼 심플하게

프로젝트를 한 장으로 설명할 수 있는 도식화된 이미지가 있다면 금상첨화입니다. 스펙을 잘 정리한 표도 좋고, 유저 입장에서 서비스를 이용하게 되는 서비스 플로우도 좋습니다. 프로젝트의 주요 키포인트를 잘 설명할 수 있는 이미지도 괜찮습니다.

키포인트 작성은 '변화'에 초점을 맞춰서 생각해보면 좋습니다. 이 변화는, '유저 사용성의 변화', '시스템의 변화', '정책의 변화' 등이 있을 텐데요. 반드시 플로우 차트로 표현해야 한다기보다는, 이 변화점을 한눈에 이해할 수 있도록 도식화된 이미지를 첨부하는 것이 좋다는 의미입니다. 백 번의 말보다 한 장의 이미지가 무언가를 전달하기에 더 효과적인 방법이니까요. 

• 프론트 기능이 대대적으로 변경되어 유저 사용성이 완전히 바뀌는 프로젝트라면 → 유저가 시작점이 되는 서비스 플로우를 그리면 작업 이후 어떤 사용성이 바뀌는지 명확하게 알 수 있습니다. 
   
• 만약 유저가 사용하는 프론트 화면은 그대로인데 백엔드 시스템이 바뀌는 프로젝트라면 → 프론트 화면을 기준으로 어떤 시스템으로 변경을 하는지 설명해주는 것보다는, 기존 시스템 구조와 신규 시스템 구조를 대조하여 설명해주는 이미지가 적합합니다.

즉, 이 프로젝트를 통해 어떤 것이 변화하는지를 키포인트로 잡고, 이를 사람들의 머릿속에 인지할 수 있도록 도식화하는 것이 핵심입니다. 

여기서 많이 실수하는 부분이 바로 '디테일'입니다. 디테일을 챙겨야 한다는 이야기가 아니라, 디테일을 빼야 합니다. 기획 업무를 하게 되면 오히려 각 필드별 상세 정의를 빼먹지 않으려고 꼼꼼히 챙기다가 오히려 큰 그림을 놓치게 되는데요.

예를 들어, 위 이미지처럼 너무 당연하게도 가입 동선에서 필수 약관에 동의하지 않았거나, 본인인증을 하지 않았거나, 입력하는 정보가 유효하지 않은 경우 회원 가입 단계를 진행하지 못할 텐데요. 

이러한 세세한 검증(Validation)을 플로우 차트에 담게 되면 정확하게 설명할 수는 있으나 문서를 읽는 이들에게는 중요한 변경 사항이 오히려 전달되지 않을 수 있습니다. 프로젝트 관여도가 높지 않은 사람들에게는 첫 번째 이미지보다 두 번째 이미지가 복잡하게 느껴지면서 오히려 핵심이 잘 전달되지 않을 가능성이 높겠죠? 따라서 상세 스펙은 상세 기획서에 담고, 이 프로젝트 개요 문서에는 핵심 동선만 시각화하여 포함하기를 추천합니다.

플랫폼 영향도: 변경 사항을 표로 정리하기

대형 프로젝트일 경우, 계정·권한·과금 등 플랫폼 전체 정책 변경이 불가피한 경우가 많습니다. 이 경우 변경 사항을 AS-IS, TO-BE로 명확하게 표시하여 설명해주면 좋습니다.

저는 프로젝트를 진행하면서 변경되는 모든 영향도를 '플랫폼 영향도'로 설명하는데요. 이를 사전에 문서화해두지 않는다면, '회원' 관련 프로젝트인데 왜 '결제'에 영향을 주는지, 어떤 부분을 QA*시 참고해야 할지 등 놓칠 수 있는 부분이 정말 많습니다. 

* Quality Assurance. 일정 수준의 품질(Quality)을 가질 수 있도록 제품 출시 이전에 각종 테스트 및 검수 작업을 하는 업무. (네이버 지식백과)

해당 프로젝트를 진행함에 있어서 어떤 점들이 변화하는지를 아래와 같이 하나의 표로 정리한다면 듣는 이들도 지금과 바뀔 부분을 조금 더 뚜렷하게 인식할 수 있습니다. 

프로젝트 대시보드: 전체적인 진행현황을 표로 보여주기

앞으로의 일정 및 담당자를 정리한 대시보드를 작성합니다. 프로젝트의 진행상황을 궁금해하는 팀장님에게, 데일리 리포트로 지금의 프로젝트 진행 현황을 공유한다는 마음으로 촘촘한 일정표를 구성합니다.

보통 하나의 프로젝트에는 수많은 연관부서의 협업이 필요한데, 프로젝트 종료까지 스텝별 과제와 일정 그리고 담당부서의 진행현황을 한눈에 볼 수 있다면 프로젝트 진행의 병목현상이 어디서 발생하는지 쉽게 확인할 수 있을 겁니다. 관련 내용이 더 궁금한 사람들을 위해 프로젝트 하위 문서들도 연결 문서로 연결합니다. 

요즘 WIKI/노션에서 칸반보드를 연결하거나 WBS*를 문서 내에서 바로 보여줄 수 있도록 커스텀도 가능한데요. 실시간으로 정보가 연동된다는 점은 장점이나 너무 많은 정보를 보여주게 되어 오히려 상대가 정보 파악을 어려워하는 경우가 있더라고요.

* Work Breakdown Structure, 작업분할구조도: 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업 (네이버지식백과) 

그래서, 조금은 아날로그적인 방법으로 직접 표를 작성하여 프로젝트 TASK·담당자·일정·진행 현황을 표시합니다. 그리고 이 부분은 하나의 단계가 지날 때마다 꼭 진행 상황을 동기화하여 업데이트합니다. 

관련 문서는 보통의 프로젝트 진행 시 산출물을 링크해두는데요. 정책 문서뿐만 아니라 태스크 진행현황을 볼 수 있는 지라나 테스트 시나리오, 보도자료·공지사항 초안 등 각 유관부서에서 진행한 산출물을 한눈에 볼 수 있도록 연결해주면 프로젝트 종료 후에도 참고할 만한 좋은 자료가 됩니다.

여기까지 작성하면 다음과 같은 원페이지 기획서가 나옵니다.

길고 복잡한 줄글 없이 간단하게 프로젝트의 주요 내용이 들어오죠? 하나의 페이지에 정리한 작성 예시와 복제하여 쓰실 수 있는 템플릿을 공유합니다. 

한 장을 백 번만 이야기해 봅시다

사회 초년생 때 가장 일을 잘하고, 빠르게 할 수 있는 방법은 '선배의 문서를 많이 저장해라'라는 말을 들은 적이 있습니다. 처음에는 프로젝트가 모두 다른데 남들이 하는 그대로 기획서를 작성하는 것이 맞는가 하는 궁금증이 들기도 했고, 후배한테 고작 한다는 조언이 '베끼는 게 최고의 방법이라고?' 같은 묘한 반발심도 들었습니다. 

하지만, 빈 페이지를 띄워 놓은 채 문서를 정리하다 보면 투입한 시간은 많지만 결과는 기존 기획서와 별반 다르지 않다는 것을 경험해보신 적이 있을 것입니다. 결국 프로젝트 문서에 공통적으로 들어가야 하는 요소는 대부분 유사하고, 잘 쓴 기획서와 못 쓴 기획서를 판가름하는 기준은 공통적인 항목에서 내용을 담는 방식이라는 점을 알게 되었습니다. 

• 요약: 어떤 것을 해야 할지 한 줄에 정리하고
• 배경·목표: 왜 필요한지, 언제까지 해야하는지, 누가 시킨 것인지(중요) 설명하고
• 전제 조건: 프로젝트의 범위는 어디까지로 한정할지 선을 긋고
• 플로우차트: 결국 유저(서비스)는 어떻게 변화될 것인지 시각화하는 것

더 나아가, 지금 프로젝트가 일정대로 잘 가고 있는지, 관련 문서는 어디서 찾아볼 수 있는지 연결해두면 한 장의 프로젝트 문서로 팀장님도, 막내도 지금 진행하는 과제에 대한 내용과 상황을 모두 확인할 수 있습니다. 

특히, 실무를 하느라 너무 바쁜데 유관부서의 이름도 잘 모르는 사람들로부터 '프로젝트에 대해 어디서 확인할 수 있을까요?'라는 연락을 참 많이도 받았던 것 같습니다. 그때마다 구구절절 설명하기보다 잘 쓰여진 문서 링크 하나를 전달하는 것이 무척 효율적이었습니다.

사람들의 머릿속에 '성공적인 프로젝트였다' 혹은 '프로젝트 관리가 잘 되었다'라고 기억되기 위해서는 같은 내용을 수십 번, 수백 번 이야기해줘야 합니다. 그때마다 다른 워딩과 파편화된 문서로 이야기하게 된다면 사람들은 쉽게 내 이야기를 잊게 됩니다. 그리고 무수히 많은 종료된 프로젝트의 무덤으로 사라지게 되죠. 

사람들에게 기억되는 프로젝트 한 장을 만들고, 딱 백 번만 회사에서 이야기 해보세요. 그럼 그 프로젝트는 사람들의 머릿속에 오래 살아남을 수 있을 거예요. 그리고 사람들이 오래 기억하는 그 프로젝트는 2025년 가장 핵심적인 나의 성과가 될 수 있다고 확신합니다.