요구사항의 끝없는 변화
시스템 개발은
요구사항에서 시작됩니다.
무엇을 만들 것인지,
어떤 기능이 필요한지,
어떤 화면으로 구성할지.
회의를 거쳐 정리되고
문서가 만들어집니다.
그 문서는
프로젝트의 기준이 됩니다.
그래서 개발 현장에서는
이 말을 자주 합니다.
“요구사항이 확정되었습니다.”
하지만
수많은 프로젝트를 지나며
한 가지 사실을 알게 됩니다.
요구사항은
확정되는 것이 아니라
변해가는 것이라는 사실입니다.
처음에는
아주 분명해 보입니다.
“이 기능만 있으면 됩니다.”
“이 구조로 가면 될 것 같습니다.”
그렇게 시작된 프로젝트는
개발이 진행될수록
조금씩 다른 이야기가 나오기 시작합니다.
“이 부분은 이렇게 바꾸면 좋겠습니다.”
“운영을 생각해 보니 방식이 달라야 할 것 같습니다.”
“시장 상황을 보니 방향을 조정해야 할 것 같습니다.”
처음에는 작은 수정입니다.
그러나 어느 순간
프로젝트의 모습은
처음과 꽤 달라져 있습니다.
개발자는 종종
이 질문을 합니다.
“처음부터 정확히 정하면 안 될까?”
사람은 처음부터
자신이 원하는 것을
분명하게 알고 시작하는 경우가
과연 얼마나 될까.
돌이켜 보면 대부분의 일들은
시작할 때보다
겪어가는 시간 속에서
조금씩 방향이 또렷해집니다.
사업은
생각으로 시작하지만
현실 속에서 자랍니다.
아이디어로 떠올릴 때와
실제로 시스템을 마주할 때는
느낌이 다릅니다.
화면을 보고
기능을 써 보고
운영을 상상해 보면
그때 비로소
보이지 않던 것들이 보입니다.
그래서 의뢰자는
이렇게 말하게 됩니다.
“아, 이렇게 되는 거였군요.”
“그렇다면 이 부분은
다르게 가야 할 것 같습니다.”
요구가 바뀌는 이유는
변덕 때문이 아니라
이해가 깊어졌기 때문일 때가 많습니다.
예전에 한 대표님이
이런 말씀을 하신 적이 있습니다.
“처음에는 기능 하나만있으면 될 줄 알았습니다.
그런데 시스템을 보니 제가 어떤 사업을 하려는지그때서야 조금 보이더군요.”
그 말을 듣고 한동안 생각했습니다.
우리는 시스템을 만들고 있지만어쩌면 어떤 대표님에게는사업의 모습을 함께 찾아가는과정일지도 모른다는 생각이 들었습니다.
또 하나의 이유는
사업 자체가 움직이기 때문입니다.
프로젝트는 몇 달에서
길게는 1년 이상 이어집니다.
그 사이에 시장은 바뀌고경쟁자는 나타나고전략도 수정됩니다.
사업이 움직이는데시스템만 그대로일 수는 없습니다.
그래서 요구는자연스럽게 다시 쓰입니다.
그래서 개발 프로젝트의 본질은
요구사항을 지키는 일이 아니라
요구사항을함께 이해해 가는 과정에가깝습니다.
좋은 프로젝트는요구가 변하지 않는 프로젝트가 아니라
요구가 변할 때
같은 방향을 바라볼 수 있는
프로젝트입니다.
20년 넘게 현장을 보며느낀 것이 있습니다.
요구가 바뀌는 순간프로젝트의 운명이 갈립니다.
“처음 요구와 다릅니다.”
혹은
“지금 상황이라면이 방향이 더 맞을 것 같습니다.”
두 문장의 차이는
단순한 표현의 차이가 아닙니다.
그 안에는같이 가려는 태도가담겨 있기 때문입니다.
결국 시스템 개발은
코드를 만드는 일이 아니라
생각의 방향을
조금씩 맞춰가는 과정에
더 가깝습니다.
그래서 요구사항이 바뀌는 것은어쩌면 이상한 일이 아닙니다.
사람이사업을 이해해 가는자연스러운 과정일지도 모릅니다.
다만 중요한 것은변화 자체가 아니라그 변화를
같은 방향으로 받아들이는가입니다.
좋은 프로젝트는
요구가 한 번도 바뀌지 않은 프로젝트가 아니라
요구가 여러 번 바뀌어도
결국 같은 방향으로
걸어온 프로젝트입니다.
그리고 시간이 지나면우리는 깨닫게 됩니다.
처음의 요구가 정답이었던 것이 아니라
그 과정을 함께 걸어온 사람들이 결국 정답을 만들어 냈다는 사실을.