고객사 사례 기반 거래소 제품 기획

화이트라벨 거래소를 운영하며 쌓인 고객사 요구와 실제 사용 사례를 비교해 새 서비스에 공통 적용할 현물 거래 정책을 정했습니다.

고객사마다 달랐던 방식을 하나의 기준으로 정리했습니다

화이트라벨 거래소는 고객사마다 원하는 기능과 운영 방식이 달랐습니다. 기존 서비스를 그대로 복사하면 특정 고객사의 요구가 새 제품의 기본 정책이 될 수 있었습니다. 반대로 처음부터 새로 만들면 이미 여러 고객사에서 사용한 차트와 호가 기능까지 다시 개발해야 했습니다.

특히 기존 선물 화면에는 포지션과 레버리지가 포함돼 있었지만 현물 거래에는 맞지 않았습니다. 웹과 모바일도 차트 구현 방식, 화면 높이와 주문 내역 표시 방식이 달랐습니다. 어떤 기능을 공통으로 가져가고 무엇을 제외할지, 플랫폼별 차이는 어디까지 허용할지를 PO가 먼저 결정해야 했습니다.

고객사 사례와 실제 API를 함께 비교했습니다

기존 고객사별 서비스와 운영 요청을 살펴보고 실제 API에서 제공하는 주문, 잔고와 거래 내역을 대조했습니다. 한 고객사의 화면을 기준으로 삼지 않고 여러 서비스에서 반복해서 사용된 기능과 현물 거래에 필요한 기능을 구분했습니다. 이후 개발팀과 플랫폼 담당자가 기술 제약과 공수를 확인할 수 있도록 1차 범위를 문서로 정리했습니다.

참고 서비스와 현재 화면을 비교해 결정했습니다

필터 표기처럼 작은 화면 요소도 의미가 분명한지와 기존 사용 방식이 유지되는지를 함께 봤습니다. 현행 화면, 모바일 참고 서비스와 기능 명세를 비교한 뒤 현물 필터는 축약 기호보다 드롭다운 방식이 이해하기 쉽다고 판단해 변경을 요청했습니다.

웹 화면, 모바일 참고 사례와 기능 명세를 한 번에 비교하고 필터 방식을 결정한 기록입니다.

요구사항과 업무 기록을 이슈 단위로 관리했습니다

제품 요구사항과 진행 기록이 여러 채널에 흩어지지 않도록 별도 Jira 공간을 만들었습니다. 에픽, 신규 기능, 개선, 작업과 하위 작업 등 이슈 유형을 정하고, 요청사항과 기획 내용을 기능 단위로 등록할 수 있는 기준을 공유했습니다.

제품 요구사항과 업무 기록을 한곳에서 관리하기 위해 Jira 공간과 기본 운영 기준을 공유한 내용입니다.

기능 목록보다 사업 기준을 남겼습니다

제가 맡은 일은 화면 요구사항을 전달하는 데 그치지 않았습니다. 고객사별 사례 중 무엇을 제품의 기본값으로 삼을지, 기존 기능을 어디까지 재사용할지, 첫 배포에서 어떤 범위를 먼저 개발할지를 결정했습니다.

그 결과 현물 거래 구축 계획서, 모바일 스펙과 차트 명세에 공통 정책과 플랫폼별 범위가 남았습니다. 이후 고객사 요청이 추가되더라도 특정 사례를 그대로 반영하지 않고 공통 기능과 고객사별 예외를 구분해 검토할 수 있는 기준을 만들었습니다.