월요일에 기획안을 제출했다. 화요일에는 아주 좋다는 평가를 받았다. 수요일에는 조금 수정하라는 연락이 왔다. 목요일에는 방향을 바꾸자는 의견이 나왔다. 금요일에는 처음부터 다시 검토하자는 결론이 내려졌다.
그리고 다음 주 월요일. 처음 제출했던 안과 놀랍도록 비슷한 기획안이 등장한다. 실무자는 잠시 생각한다. “혹시 지난주에 우리가 한 일은 일주일짜리 파일 이름 바꾸기였나?”
기획안이 반복해서 뒤집히는 문제는 수정 횟수 자체보다 무엇을 기준으로 판단하고, 누가 최종 결정하며, 어떤 조건에서 결정을 변경하는지가 불분명할 때 커진다.
기획안은 바뀔 수 있다. 하지만 이유 없이 흔들리면 곤란하다
기획은 미래에 일어날 일을 미리 설계하는 작업이다. 당연히 처음부터 완벽할 수 없다. 새로운 정보가 발견되거나 예산이 달라지면 방향을 바꾸는 것이 오히려 합리적일 수 있다.
문제는 필요한 변경과 불필요한 재작업을 구분하지 못하는 조직이다. 새로운 근거 없이 누군가의 취향에 따라 방향이 바뀌거나, 이미 합의한 목표를 매번 새롭게 해석한다면 실무자는 무엇을 기준으로 일해야 할지 알 수 없다.
그렇다고 수정 자체를 실패로 간주하는 것도 위험하다. 잘못된 기획을 끝까지 고집하는 것은 재작업을 피하는 방법이 아니라 실패를 뒤로 미루는 방법일 수도 있다.
필요한 것은 변경을 금지하는 규칙이 아니다. 변경하는 이유를 설명할 수 있는 공통의 판단 구조다.
서로 다른 사람들이 같은 기획안을 보고 있다
가상의 조직에서 신규 서비스 기획안을 검토한다고 생각해 보자. 실무 담당자는 사용자 편의성을 높이는 데 집중한다. 예산 담당자는 지출을 걱정하고, 관리자는 외부에 보여줄 성과를 생각한다.
세 사람 모두 같은 문서를 읽고 있지만 사실 서로 다른 문제를 해결하고 있다.
빨리 만들자는 사람과 제대로 만들자는 사람
추진형 담당자는 말한다. “일단 최소 기능부터 만들어서 반응을 봅시다.” 신중형 담당자는 반대한다. “처음부터 완성도를 확보해야 신뢰를 얻을 수 있습니다.”
이 의견 차이는 성격 문제가 아닐 수도 있다. 한 사람은 출시 시점을 성공 기준으로 보고, 다른 사람은 초기 품질을 성공 기준으로 보기 때문이다.
목표가 빠른 시장 검증이라면 제한된 기능의 시범 운영이 적절할 수 있다. 반대로 오류 발생 시 회복하기 어려운 서비스라면 사전 검토와 품질 확보의 비중이 커진다.
서로를 설득하기 전에 먼저 해야 할 일이 있다. 이번 기획에서 무엇을 가장 중요하게 보는지 합의하는 것이다.
초보자는 수정 지시를 받아 적고, 숙련자는 기준이 바뀌었는지 확인한다
수정 요청을 받은 초보 담당자는 우선 문서를 고친다. 제목을 바꾸고, 내용을 옮기고, 표를 다시 만든다. 요청한 사람이 만족할 때까지 반복한다.
반면 경험이 많은 담당자는 수정 이유를 확인하려고 한다. 처음 합의한 목표가 변경된 것인지, 새로운 제약이 발견된 것인지, 아니면 표현 방식에 관한 의견인지 구분하는 것이다.
이 차이는 중요하다. 표현 수정이라면 해당 부분만 고치면 되지만, 사업 목표가 바뀌었다면 대상 사용자와 예산, 일정까지 함께 검토해야 할 수 있기 때문이다.
겉으로는 똑같은 “수정해 주세요”라는 말이어도 실제로 요구하는 작업의 범위는 전혀 다를 수 있다.
반복 수정의 원인은 어디에 숨어 있을까?
기획안이 계속 뒤집힐 때는 작성자의 능력만 평가하기보다 기획을 둘러싼 조건을 함께 살펴볼 필요가 있다.
첫 번째, 목표가 지나치게 추상적이다
“사용자가 만족하는 서비스를 만들자.” 누구도 반대하기 어려운 문장이다. 동시에 사람마다 전혀 다르게 해석할 수 있는 문장이기도 하다.
누군가는 화면 디자인을 개선하고, 누군가는 기능을 늘리며, 또 다른 사람은 이용 요금을 낮추려 한다. 모두 사용자 만족을 위한 행동이라고 주장할 수 있다.
기획 목표는 가능하면 대상과 변화 방향을 구체적으로 표현해야 한다. 예를 들어 신규 이용자가 첫 방문에서 핵심 기능을 이해하도록 만드는 것이 우선인지, 기존 이용자의 반복 사용을 높이는 것이 우선인지 구분하는 식이다.
두 번째, 무엇을 선택할지 판단하는 기준이 없다
두 개의 기획안이 있다고 생각해 보자. A안은 비용이 적지만 구현 시간이 길고, B안은 빠르게 실행할 수 있지만 유지비가 높다. 어떤 안이 적절할까?
비용을 우선한다면 A안에 관심이 갈 수 있고, 일정이 급하다면 B안이 검토 대상이 될 수 있다. 우선순위가 정해지지 않은 상태에서는 검토자의 관심에 따라 결과가 매번 달라진다.
이 때문에 기획 초기에는 반드시 지켜야 하는 조건과 조정할 수 있는 조건을 나누는 것이 좋다. 법적 요건이나 안전 기준처럼 타협할 수 없는 조건도 함께 구분해야 한다.
세 번째, 결정권자가 보이지 않는다
팀에서는 승인했다고 생각했는데 부서장이 다시 검토하자고 한다. 부서장이 승인하자 다른 부서에서 이견을 낸다. 결국 최종 결정권자가 누구인지 아무도 명확히 답하지 못한다.
이런 상황에서 실무자에게 기획안을 완벽하게 작성하라고 요구하는 것은 목적지를 알려주지 않고 정확히 도착하라는 말과 비슷하다.
누가 의견을 제시하고, 누가 검토하며, 누가 최종 승인하는지 구분해야 한다. 특히 여러 부서가 참여하는 기획이라면 협의가 필요한 영역과 최종 결정 권한을 처음부터 정리할 필요가 있다.
이상적인 기획과 현실의 기획은 왜 다른가?
이상적인 업무 환경에서는 목표가 명확하고, 필요한 자료가 준비되어 있으며, 모든 이해관계자가 같은 방향을 바라본다. 실무자는 정해진 조건에 따라 결과물을 만들고 승인받는다.
하지만 현실에서는 예산이 중간에 줄어들고, 담당자가 교체되며, 새로운 요청이 추가된다. 외부 환경 때문에 처음 합의한 내용이 더 이상 적절하지 않을 수도 있다.
따라서 좋은 기획 관리란 처음 정한 내용을 영원히 유지하는 것이 아니다. 무엇이 변경됐고, 그 변경이 일정과 비용, 품질에 어떤 영향을 주는지 확인하는 과정이다.
과거에는 문서를 고쳤다면, 이제는 변경 이유도 남겨야 한다
파일 이름 뒤에 최종, 진짜최종, 최종수정, 최종확정 같은 표현을 붙인 경험이 있는가? 그렇다면 이미 아주 원초적인 버전 관리 시스템을 운영해 본 셈이다. 문제는 파일 이름만으로 무엇이 달라졌는지 알기 어렵다는 데 있다.
문서 버전을 보존하는 것과 함께 변경 이유를 간단히 남겨보자. 누가 요청했는지, 어떤 근거가 추가됐는지, 어느 항목이 바뀌었는지, 기존 일정에 영향이 있는지를 구분하면 좋다.
이 기록은 누군가를 탓하기 위한 자료가 아니다. 같은 논의를 반복하지 않고 현재 결정이 만들어진 과정을 확인하기 위한 업무 정보다.
기획이 흔들리지 않게 만드는 세 가지 질문
새로운 기획을 시작할 때 처음부터 거대한 관리체계를 구축할 필요는 없다. 최소한 다음 세 가지 질문에 대한 답을 합의해 두는 것부터 시작할 수 있다.
- 무엇을 달성하려는가? 대상과 최종 목적을 구체적으로 정한다.
- 어떤 기준으로 선택할 것인가? 비용, 시간, 품질, 위험 등에서 우선순위를 확인한다.
- 누가 최종 결정하는가? 의견 제시, 검토, 승인, 실행의 책임을 구분한다.
그리고 새로운 수정 요청이 들어왔을 때는 원래 합의한 세 가지 중 어떤 부분이 달라졌는지 확인한다. 단순한 의견 추가라면 해당 기준에 따라 검토하고, 목표나 필수 조건이 바뀌었다면 기획 전체에 미치는 영향을 다시 살펴본다.
변경을 요청하는 사람에게도 수정의 범위와 결과를 보여주는 것이 좋다. 예를 들어 새로운 기능을 추가하면 일정이 늘어나거나 다른 기능의 우선순위를 낮춰야 할 수 있다는 사실을 함께 제시하는 것이다.
이렇게 하면 기획 변경을 개인의 취향 문제에서 조직의 선택 문제로 옮길 수 있다.
수정이 많았다는 사실보다 더 중요한 것
기획안을 여러 번 고쳤다는 사실만으로 실패했다고 판단할 필요는 없다. 수정할수록 문제를 더 명확하게 이해하고 결과물이 개선될 수도 있다.
다만 수정이 반복되는데도 목표가 더 분명해지지 않고, 앞서 합의한 내용이 아무런 설명 없이 사라진다면 업무 구조를 점검해야 한다. 담당자에게 더 열심히 일하라고 말하는 것만으로는 해결하기 어렵다.
다음 기획안을 작성하기 전에 목표와 판단 기준, 결정권자를 먼저 적어보자. 변경이 발생하면 이전 기준과 무엇이 달라졌는지도 남겨보자.
기획은 미래를 설계하는 일이다. 미래가 바뀌면 설계도도 바뀔 수 있다. 하지만 설계도를 수정할 때마다 건물의 용도까지 다시 정한다면 언젠가 이런 질문을 하게 될지도 모른다.
“그런데 우리, 원래 뭘 만들려고 했죠?”
그 질문이 공사 시작 전에 나왔다면 다행이다. 이미 지붕을 올린 뒤라면 이야기가 조금 복잡해진다.
필요한 것은 변경을 금지하는 규칙이 아니다.
학습 퀴즈 2문항
이 글에서 기억할 것을 두 문항으로 확인해 보세요.
