요구사항 수집하랬더니 질문만 늘어나는 건에 대해..

 

개발하다 보면 요구사항에 없는 내용을 결정해야 할 때가 있습니다.

---

오래 전, 첫 SI 회사에 다닐 때에 사수와 함께 클라이언트를 만나러 간 적이 있습니다.

사수는 이야기를 들으면서 필요한 내용을 질문하고, 요구사항을 정리해 나갔습니다. 어떻게 그렇게 잘 정리하시냐고 물었는데, 경험이 쌓이면 된다고 답했던 것으로 기억합니다. 당시에는 그 모습이 그저 신기했죠.

 

이번에 요구사항을 분석하는 공부를 하다가 문득 그때가 떠올랐습니다.

그럼 지금의 저는 어떻게 하고 있을까요?

일단 만들고, 나중에 맞추는 편입니다

지금 업무에서는 주로 영업 담당자가 요구사항을 전달합니다. 먼저 함께 내용을 정리하고, 추가로 궁금한 점은 메일로 보내는 식입니다.

다만 서로 다른 업무로 바쁘다 보니 답을 바로 받기는 어렵습니다.

그렇다고 계속 기다릴 수는 없으니, 제가 이해한 의도와 영향 범위, 예상되는 예외 상황을 적고 먼저 구현하는 편입니다.

나중에 바꾸기 쉬워 보이는 부분은 직접 판단(경험과 작업자의 감) 하고, 중요한 정책이라고 생각한 부분은 답변을 기다리고요.

 

나름대로 기준은 있었습니다.

 

그런데 어떤 건 제가 정해도 되고, 어떤 건 기다려야 하는지 설명하려니 생각보다 명확하지 않았습니다. 나중에 피드백을 받고 변경하면서 맞춰나간 경우도 많았던 것 같습니다. AI가 있으니 코드 수정은 빨라졌습니다. 그렇다고 고친 코드가 다른 동작에 영향을 주지 않는지 확인하는 일까지 없어지지는 않았습니다. 그만큼 테스트와 E2E 확인에도 시간을 들였고요.

 

이번에는 이런 제 방식을 좀 돌아보게 됐습니다.

쿠폰 하나인데 궁금한 건 왜 이렇게 많을까?

이번에 읽은 요구사항은 다음과 같았습니다.

구매자는 주문 확정 전에 보유 쿠폰을 적용할 수 있고, 확정된 할인 금액은 이후에도 유지됩니다.

 

한 주문에 쿠폰 한 장을 적용하고, 같은 요청에는 기존 결과를 재사용한다는 조건도 있었습니다.

최종 금액은 원금에서 할인 금액을 빼서 계산하고, 쿠폰 만료 여부는 요청 시작 시각으로 판단합니다.

 

읽으면서 이런 생각이 들었습니다.

 

• 주문 확정은 정확히 언제일까요?
• 환불하면 사용한 쿠폰을 다시 쓸 수 있을까요?
• 같은 사람이 여러 브라우저에서 다른 상품을 주문하면서 같은 쿠폰을 쓰면 어떻게 될까요?
• 여기서 원금은 상품 가격을 합친 금액일까요, 다른 할인이 이미 반영된 금액일까요?

생각하다 보니 물어볼 내용이 계속 늘어났습니다.

 

원래는 이런 경우의 수를 많이 생각하는 게 요구사항을 잘 분석하는 방법이라고 생각했습니다.

그런데 질문을 늘어놓고 보니, 어디까지 이번에 확인해야 하는 건지 오히려 더 어려워졌습니다.

 

답변이 없을 때 제가 어디까지 판단해도 되는지도 고민이었지만, 그전에 제가 물어보려는 내용부터 정리가 필요했습니다.

 

발제에서 주어진 약속과 조건, 확인할 질문을 나누는 내용을 읽고 질문 목록을 다시 봤습니다.

제가 궁금한 걸 전부 묻기보다, 지금 요구를 처리하려면 무엇을 알아야 하는지부터 보려고 했습니다.

환불이면 다 같은 질문인 줄 알았는데

처음 떠올렸던 질문 중 하나는 이거였습니다.

환불하면 그 주문에 사용한 쿠폰을 다시 사용할 수 있을까?

 

쿠폰과 관련된 상황이니 자연스럽게 같이 생각했습니다. 그런데 이 질문에 답하려면 환불 이후 쿠폰을 다시 사용할 수 있게 할지, 가능하다면 어떤 조건으로 허용할지도 정해야 했습니다.

 

잠깐, 원래 확인하려던 게 뭐였죠?

 

주어진 요구는 ‘확정된 할인 금액은 이후에도 유지된다’였습니다. 이 내용을 보면서 환불을 떠올렸는데, 어느새 할인 금액이 아니라 쿠폰을 다시 사용하는 이야기로 넘어가 있었습니다. 그래서 질문을 이렇게 바꿔봤습니다.

환불한 주문에도 기존의 확정 할인 금액을 보존하나요?

 

둘 다 환불 이야기인데 묻는 건 달랐습니다.

 

처음 질문은 쿠폰의 재사용 여부를 묻고, 바꾼 질문은 ‘확정된 할인 금액을 유지한다’는 약속이 환불한 주문에도 적용되는지 묻습니다.

 

쿠폰 재사용이 중요하지 않다는 뜻은 아닙니다. 다만 그것도 이번에 다룰 내용인지는 별도로 확인해야 합니다.

쿠폰과 관련된 상황이라는 이유만으로 전부 한꺼번에 정하려고 했던 것 같습니다.

 

처음에는 경우의 수를 더 찾아야 한다고 생각했는데, 이번에는 떠올린 질문이 어디서 시작됐는지 되짚어보는 게 도움이 됐습니다.

‘이런 경우도 있지 않을까?’ 다음에 ‘그런데 이건 주어진 요구의 무엇을 확인하려는 질문이지?’를 한 번 더 생각해보게 됐습니다.

다음에는 이렇게 해보려고 합니다

처음에는 여러 상황을 생각해두면 그만큼 꼼꼼하게 분석한 거라고 생각했습니다.

그런데 질문을 계속 늘리다 보니, 정작 뭘 만들어야 하는지 더 헷갈리기도 했습니다.

 

다음에는 ‘이런 경우도 있지 않을까?’가 떠오르면, 그게 지금 요청받은 기능을 만드는 데 필요한 질문인지부터 보려고 합니다.

있으면 좋을 기능이라면 따로 제안하면 되고요.

 

답을 기다리면서 먼저 진행해야 하는 경우는 앞으로도 있을 것 같습니다. 그때 제가 임시로 정한 내용은 표시해두려고 합니다.

나중에 다시 봤을 때 전달받은 요구인지, 제가 정한 건지 헷갈리지 않도록요. AI에게 작업을 맡길 때도 이런 부분이 중요하다고 생각해요.

제가 보기엔 괜찮은 방향이어도, 그게 요청한 분이 원하는 동작인지는 다른 이야기일 수 있으니까요.

 

물론 아직 애매한 건 있습니다. 답변이 계속 늦어지면 어디까지 진행해도 될지, 제품 담당자 없이 제가 처음부터 만들어야 할 때는 어떻게 할지까지 답을 찾은 건 아닙니다.

 

일단 다음 요구사항을 받으면 질문 옆에 왜 궁금한지도 짧게 적어볼 생각입니다. 그러다 보면 지금 물어볼 것과 나중에 이야기해도 될 것을 조금은 구분할 수 있지 않을까 싶습니다.