[실무에서 만나는 AI·AX 이야기] #5, 기획서 쓰기 전에 기능 범위부터 확인합니다

AI로 기능 범위를 확인하는 서비스 기획자

서비스 기획에서 기능 범위를 어떻게 정할까요. 재고 질문 하나에 기획서가 멈췄던 날, 도메인 경험 없이도 AI로 기능의 연결 범위를 기획 전에 확인하는 방법을 정리했습니다.

---

: 도메인은 몰라도, 범위는 알아야 합니다.

재고 질문 하나에 기획서가 멈췄습니다

기능 테스트를 하던 날이었습니다.

기획자와 함께 기능을 하나씩 눌러보는 중이었습니다.

재고 관련 케이스가 나왔을 때, 시니어 백엔드 개발자가 물었습니다.

"사용자가 클릭하는 순간 재고를 잡는 건가요, 장바구니에 담을 때인가요?"

 

기획자가 멈췄습니다.

기본 룰은 있었습니다.

클릭하는 순간 임시로 재고를 잡는다.

 

그런데 그 임시 재고가 실시간 전체 재고를 잡는 건지,

예외는 어떻게 되는지,

재고관리 화면에서는 그걸 어떻게 보여줄 건지.

 

연계된 기능들과 어떻게 맞물리는지가 기획서 어디에도 없었습니다.

"아, 주문에서는 문제가 안 되는데. 재고관리에서는 문제가 되는군요."

기획자가 그때 처음 깨달았습니다.

---

주문 기능이 재고·ERP까지 연결돼 있었습니다

저는 회의를 한 번 더 만들었습니다.

현업 담당자와 DB 모델링 담당이 참석했습니다.

모델링 레벨에서 다시 짚어볼 생각이었습니다.

 

현업 담당자가 설명을 시작했습니다.

그런데 이 사람도 정확히는 몰랐습니다.

자기는 쓰는 사람이라, 어떻게 돌아가는지까지는 몰랐습니다.

 

거기서 일이 커졌습니다.

 

주문 처리인 줄 알았던 게, 재고·트랜잭션·ERP 영역까지 걸리는 문제였습니다.

범위 자체가 달랐습니다.

지금 우리가 만드는 게 실제 업무 전체를 감당하는 규모의 제품이라는 걸, 저도 그때 알게 됐습니다.

---

결국 현업 담당자와 DB 모델링 담당이 실제 업무 수준의 관리체계를 가져왔습니다.

임시 재고는 실제 재고와 연결됐고, 입출고 보정과 예외 처리를 전부 함께 만들었습니다.

그렇게까지 해야 돌아가는 기능이었습니다.

 

그런데 현업 담당자도,

기획자도,

개발자도

 

그게 얼마나 큰 일인지 몰랐습니다.

각자 자기 것만 봤습니다.

현업 담당자는 쓰는 법만 알았고, 기획자는 기능만 봤고, 개발자는 구현만 봤습니다.

 

이 기능이 어디까지 연결되는지, 먼저 물은 사람이 없었습니다.

---

기획자에게 필요한 건 도메인이 아니라 범위입니다

기획자가 도메인을 전부 이해하고 제품을 만드는 건 불가능합니다.

하지만 제품을 기획하는 사람이라면 최소한 이건 알아야 합니다.

이 기능이 이 제품에서 어느 범위까지 연결되는지.

그게 없으면 기능은 기획할 수 있어도, 제품은 만들 수 없습니다.

---

지금이라면, AI로 기능 범위부터 확인합니다

지금이라면 AI를 활용해, 기획서를 쓰기 전에 그 범위를 먼저 정할 수 있습니다.

먼저 현업 담당자에게 요구사항을 듣고, 그걸 정리합니다.

 

그다음 AI에 레퍼런스를 요청합니다.

"이 기능 보통 어디까지 연결돼? 비슷한 제품에서 재고는 어떻게 처리해?"

주문 처리가 재고로,

재고가 입출고 보정으로,

거기서 예외 처리까지 이어진다는 게 여기서 나옵니다.

 

도메인 경험이 없어도 됩니다.

여기까지 보고 나면, 다른 기능과 충돌하는 지점을 체크합니다.

 

재고를 임시로 잡는 룰이 주문에서는 괜찮은데 재고관리에서는 문제가 되는지, 그런 연계 지점을 미리 짚습니다.

 

마지막으로 빠르게 시뮬레이션을 돌려 경계를 정합니다.

이 기능이 어디서 멈추고, 어디까지 다른 기능을 건드리는지 확인합니다.

 

이 과정을 기획서 쓰기 전에 밟으면,

도메인을 다 몰라도 이 제품이 어디까지를 다루는지 범위는 알 수 있습니다.

 

그때는 이걸 알려면 전문가들을 다시 불러 모아야 했습니다.

지금은 기획자가 혼자, 기획서를 쓰기 전에 할 수 있습니다.