디펜던시를 이해하기
디펜던시(dependency)와 바틀넥(bottleneck)이라는 용어가 있다. 보통 여러 분야에서 쓰이지만, IT 기업 특히 개발 쪽에서 많이 쓰인다. 근데 꼭 개발 쪽에서 쓰는 것뿐 아니라 프로젝트 매니징 분야에서도 많이 쓰인다. 디펜던시, 한국말로 하면 의존성이다. 프로젝트 매니징 관점에서 보면 특정 업무를 하기 위해서 선행 업무가 필요할 때, 후행 업무는 선행 업무에 디펜던시가 있다고 말할 수 있다.
간단한 예를 들면, 특정 기능을 개발하는 과정에서 프론트엔드 파트에서 특정 작업을 하기 위해서는 백엔드 쪽에서 API가 나와줘야 한다. 이 경우에는 프론트엔드 업무는 백엔드 업무에 디펜던시를 갖고 있는 것이라고 할 수 있다(개발자는 아니라서 정확한 표현이 아닐 수도 있다).
디펜던시 관계에 있는 선행 업무와 후행 업무 사이에서, 선행 업무가 완료되지 않아 후행 업무가 진행되지 않는 경우가 있다. 이때 업무 진행에 있어서 선행 업무와 후행 업무 사이에 바틀넥(bottleneck) 있다고 말할 수 있다.
개발 업무를 예로 들었지만, 모든 서로 다른 직군의 업무 간에도 디펜던시와 바틀넥 현상이 존재한다. 예를 들어서 디자인 시안이 나오지 않아서 마크업 작업을 할 수 없기도 하고, 기획이 나오지 않아 DB 테이블을 설계할 수 없기도 하다. 또 기획이 나오지 않아, 디자인이 나올 수 없기도 하고.
혼자서 기획, 디자인, 개발 등등의 업무를 모두 처리한다면 상관없다. 하지만 서로 다른 사람과 직군이 일하는 조직에서는 디펜던시가 어디에 있는지 확인하고, 바틀넥은 없는지, 있다면 어디서 바틀넥이 발생했고 어떻게 해결해야 하는지 파악하는 게 중요하다.
이 디펜던시를 정확히 파악하지 못한다면, 리소스를 효율적으로 쓸 수도 없고, 프로젝트 매니징도 효과적으로 할 수 없다. 리소스 관점에서 선행 업무가 진행되지 않는 한, 후행 업무를 하는 구성원은 해야 할 일을 할 수가 없다. 물론 디펜던시가 없는 업무를 할 수도 있겠지만, 이렇게 일하는 건 한계가 있다.
디펜던시를 정확히 파악하지 못해서 후행 업무를 하지 못하는 것 그 자체로도 문제이지만, 더 정확하게 표현하면 문제는 후행 업무를 제 때 못하는 게 진짜 문제다. 모든 조직은 언제까지 어떤 것을 해야 하는지 계획을 세운다. 그리고 이를 바탕으로, 다른 회사와의 약속을 하기도 하고 추가 계획을 세우고 또 계획을 변경하기도 한다. 따라서 각 업무에 대해 디펜던시를 정확하게 파악하지 못하고, 바틀넥에 대응하지 못한다면 조직의 계획은 계획대로 되지 않을 수밖에 없다.
보통 조직의 계획은 로드맵이라고 큰 계획에서부터 시작된다. 3년, 5년, 10년 등의 계획부터 시작할 수도 있고, 조직마다 시작하는 계획의 큰 단위는 다르다. 초기 스타트업의 경우 보통 1년 단위로 짜는 경우도 많다. 아무튼 가장 상위 직급에서 조직 차원에서 1년 단위의 계획을 짠다고 하면, 아래로 내려올수록 그 계획은 더 짧은 기간 단위로 세분화가 이뤄진다.
조직 차원에서 1년 계획을 달성하기 위해서는, 반기 계획이 나오고, 반기 계획을 달성하기 위해서 분기 계획이 나오고, 분기 계획이 나오기 위해서 월 단위의 계획이 나오고, 월 단위의 계획을 달성하기 위해서 2주 단위의 스프린트 계획이 나와야 한다.
역으로 말하면 2주 단위의 스프린트 계획 2개 정도가 가시화되어야 1달 단위의 계획에 대한 진행률을 파악할 수 있다. 즉, 2개 스프린트 정도에서 업무 간 디펜던시와 바틀넥을 파악해야 1달 단위의 계획이 잘 이뤄지고 있는지, 계획대로 되지 않는다면 어디에 디펜던시가 걸리고 바틀넥이 있는지를 파악해서 문제를 해결할 수 있다. 그리고 이런 1달 단위의 계획들이 모여 반기, 분기 계획의 진행률을 파악할 수 있다.
생각하면 할수록 프로젝트 매니징은 계획을 세분화하고, 계획을 진행하는 데 있어서 디펜던시가 있는지를 파악하고, 또 바틀넥이 있다면 이를 해결하는 것이 전부다. 말로는 단순해 보인다. 그런데 실제로 프로젝트 매니징을 하면서 이 것이 실제로는 정말 어려운 일이라는 걸 매일 느끼고 있다.
특히 커리어 초반에 지식 및 경험이 많이 없는 상태에서, 또 구성원 한 명 한 명이 들고 있는 일이 많을 때 프로젝트 매니징은 생각보다도 더 힘들다. 지식이 많지 않아 처음에는 정확히 어느 부분에서 디펜던시가 발생하는지 알기 힘들고, 디펜던시가 개발 업무 내부의 디펜던시인 경우에는 더 그렇다. 분명히 개발자와 소통해서 진행 현황과 이를 바탕으로 한 진행률을 체크해서 공유를 해야 하는데, 아무것도 파악이 안 되는 느낌을 받기도 한다.
경험이 없다면, 디펜던시가 어디서 발생하는지 알기도 힘들지만, 디펜던시를 정확히 파악했더라도, 바틀넥이 발생했을 때 어떻게 대응해야 하는지 정확한 판단을 내리기도 어렵다. 이 상황에서 의사결정을 혼자 내리긴 어려우니, 더 상위 직급에 이슈를 보고해야 하는데, 이 조차도 지식이나 경험이 없다면 쉽지 않다.
또한 한 명의 PM, 한 명의 디자이너, 한 명의 개발자가 여러 프로젝트를 동시에 진행하고 있다면 프로젝트 관리의 난이도는 급격하게 높아진다. 각자의 프로젝트 별 진행 상황이 다르고, 프로젝트마다의 데드라인이 다르고, 각자 생각하는 우선순위가 다르기 때문이다. 이러한 문제를 해결하기 위해서 이를 해결하기 위해서는 프로젝트 별 리드, 상위 직급자와도 소통하며 우선순위를 정확하게 정리해야 하는데 사실 이게 가장 어려운 부분이다.
많은 아티클에서 이러한 문제를 해결하기 위해서는 전사적으로 우선순위가 명확하게 설정되어야 하며 이를 위해 OKR 등의 도입이 필요하고 데일리 스크럼 등의 프로세스가 꼭 필요하다고 말한다. 맞는 말인데, 현실에 적용하기란 생각보다 너무나 쉽지 않다.
거의 모든 조직, 특히 스타트업에서 한 사람이 하나의 프로젝트만을 담당하는 경우는 거의 없다. 그러다 보니 한 사람이 여러 일들을 개인적으로도 매니징을 해야 하고, 또 각자의 프로젝트 매니징 및 소통 역량에 따라서 언제 어디서 문제가 발생할지 모른다. 또 다들 사람인지라 일이 많아지면, 아무리 꼼꼼하게 체크하더라도 실수나 누락이 발생할 가능성이 급격히 높아진다.
결국 프로젝트 매니징을 잘하려면 지식과 경험을 바탕으로, 프로젝트의 디펜던시와 바틀넥, 인터럽트를 이하고 가시화하는 동시에 전사적인 목표와 로드맵에 따른 작은 목표의 우선순위를 관리하고 또 이에 따라서 업무의 우선순위를 조정할 수 있어야 한다.
오늘 완벽한 계획을 세웠어도, 내일이면 새로운 프로젝트가 생겨, 예상치 못한 인터럽트나 바틀넥으로 인해 계획을 수정해야 할 수도 있다. 프로젝트 하나만 맡아도 힘든데, 커리어 초반에 여러 개의 프로젝트를 맡는다면 몇 배로 더 어렵고 힘들 수밖에 없다.
프로젝트 매니징에서 겪는 어려움의 해결책은 시간 밖에 없다. 다만 해결하기까지 얼마의 시간이 드냐 뿐이다. 의식적으로 더 많은 지식을 쌓기 위해 공부하고, 프로젝트 진행 상황을 회고하면서 동일한 시간에 더 압축적으로 경험을 쌓으면 조금이나마 더 빠르게 프로젝트 매니징에서 겪는 어려움을 해소할 수 있다. 그렇다고 드라마틱하게 그 속도가 빨라지지는 않는다.
커리어 초기, 프로젝트 매니징의 어려움을 온몸으로 느끼고 있는 지금 몸과 마음이 솔직히 힘들다. 원래 성향이 엄청 장기적인 계획과 계획을 세분화하는데 특화된 성향도 아니라서 더 그렇다. 언제 이 힘든 구간을 벗어날 수 있을지도 모르는 상태에서 역시 할 수 있는 건 힘들더라도 의식적으로 지식을 쌓고, 회고를 하기 위해 노력하는 수 밖에는 없는 것 같다. 성장은 계단식이라는 걸 몸소 체험하고 있는 것 같고, 이제 막 새로운 계단에 발을 올린 것 같다.
ASH 님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
