누가 보느냐에 따라 전혀 다른 의미를 가지는 요구사항
PART 3. 이미 시작된 프로젝트를 붙잡는 시간
요구사항을 문서로 정리해도, 요구사항은 쉽게 줄어들지 않는다.
오히려 실무에서는 문서를 만든 뒤에 질문이 더 많아지는 경우가 흔하다.
정리했는데 다시 묻고, 적어놨는데 다시 확인하고, 분명 합의했다고 생각했던 내용이 다른 말로 돌아온다.
“이건 포함된 거죠?”
“이건 그때 이야기한 거랑 같은 건가요?”
“이건 왜 여기에는 없어요?”
처음에는 이런 질문들이 괜히 번거롭게 느껴지기도 한다. 문서로 정리해뒀는데 왜 또 묻는지, 왜 같은 이야기를 다시 해야 하는지 이해가 되지 않는다. 하지만 프로젝트를 조금만 더 진행해 보면, 이 질문들이 나오는 이유는 생각보다 분명해진다.
요구사항은 처음부터 하나의 모습으로 존재하지 않는다. 같은 기능이라도 누가 보느냐에 따라 전혀 다른 의미로 읽히기 때문이다. 운영 담당자는 운영할 때 문제가 생기지 않는지를 먼저 떠올리고, 현업 담당자는 자기 업무 흐름 안에서 이게 필요한지를 기준으로 말한다. 디자이너는 사용자 경험을 기준으로 다시 질문을 던지고, 개발자는 구현 가능성과 구조, 유지보수 관점에서 요구를 바라본다.
모두 같은 프로젝트, 같은 기능을 이야기하고 있지만 각자가 생각하는 기준은 서로 다르다. 그래서 요구사항을 정리한다는 일은 단순히 기능 반영 여부를 결정하는 것만으로 끝나기 어렵다. 무엇을 만들 것인가보다, 이 요구를 어떤 조건과 맥락에서 받아들일 것인지를 먼저 살펴봐야 한다.
프로젝트는 대개 고객사의 요청으로 시작되지만, 요구사항은 고객사에게서만 나오지 않는다.
실무를 하다 보면 디자이너나 개발자로부터 먼저 제기되는 요구도 자연스럽게 생긴다. 화면을 설계하다가 지금 구조로는 사용자 흐름이 어색하다는 판단이 들기도 하고, 구현을 고민하다가 현재 방식으로는 유지가 어렵다는 이야기가 나오기도 한다.
이때 등장하는 요구들은 새로운 아이디어라기보다, 기존 결정사항을 그대로 유지하면 문제가 생길 수 있다는 징후에 가깝다. 그리고 이 요구사항이 정리되지 않으면, 문제는 형태만 바꾼 채 계속 다시 등장할 수 있다.
그래서 실무에서 중요한 것은 “누가 먼저 말했는가”가 아니라 “어떤 기준과 상황에서 나왔는가”다. 같은 요구라도 왜 나왔는지에 따라 지금 확정해야 할 내용인지, 조율 중인 내용인지, 아니면 다음 단계로 넘겨도 되는지 판단이 달라진다.
문제는 이 과정이 한 번으로 끝나지 않는다는 점이다. 처음에는 단순한 기능처럼 보였던 요구가 설계 단계에서는 정책 문제로 다시 나타나고, 개발 단계에서는 예외 처리 이슈로 돌아올 수 있다. 같은 요구사항인데도 등장하는 시점과 질문의 형태가 계속 바뀌는 것이다.
이럴 때 기획자는 이런 생각을 하게 된다.
“이거… 분명 정리했던 요구사항인데?”
하지만 이 반복은 기획이 부족해서 생기는 문제가 아니다.
요구사항은 프로젝트가 진행되는 과정에서 여러 관점과 조건을 거치며 계속 다시 해석된다. 그래서 요구사항 정리는 ‘기획’이라는 말보다 ‘조율’이라는 말에 더 가까워진다.
조율이란, 같은 말을 같은 기준으로 맞추는 일이다.
여기서 말하는 조율은 누군가를 설득하거나 양보를 끌어내는 일이 아니다. 각자 다른 기준으로 이해하고 있던 요구사항을, 지금 이 시점에서 하나의 기준으로 다시 맞춰보는 일이다. 무엇을 하기로 했는지보다, 어디까지를 기준으로 삼을 것인지를 다시 확인하는 과정이다.
그래서 요구사항 정리는 한 번에 끝나는 작업이 아니라, 프로젝트의 진행 속도에 맞춰 반복될 수밖에 없다. 이 상황을 단순히 “회의를 많이 해서 생기는 문제”로 오해하는 순간, 프로젝트는 쉽게 흔들린다.
이 장에서 하고 싶은 말은 단순하다. 요구사항 정리가 반복되는 이유는 기획이 부족해서가 아니다.
요구사항은 프로젝트를 따라 계속 움직이고, 서로 다른 관점에서 계속 다시 읽히기 때문이다.
그래서 기획자가 해야 하는 일은 ‘정리’로 끝내는 것이 아니라, 그 요구가 다시 등장하더라도 같은 기준으로 판단할 수 있도록 하는 것이다.
다음 장에서는 기획 미팅이 왜 짧게 끝나지 않는지를 기획자의 입장에서 다시 들여다보려 한다.