업체 선정 원칙
화려한 화면, 짧은 납기와 단정적인 성능 문구는 검증 자료가 아닙니다. 같은 요구사항과 시험 시나리오를 후보 업체에 전달하고 답변·증빙·계약 반영 여부를 비교해야 합니다.
1. 실제 제공 범위를 구분하는가
자체 개발, 제3자 제품 재판매와 외부 API 의존 영역을 구분해 달라고 요청합니다. 공급사가 직접 수정할 수 없는 모듈이 무엇인지 알아야 장애와 변경 책임을 정할 수 있습니다.
2. 데모에서 실패 시나리오도 보여주는가
정상 로그인과 주문만 시연하지 말고 네트워크 단절, 중복 클릭, 부분 체결, 시세 지연과 권한 오류를 시험합니다. 시연 환경의 서버 위치, 버전과 데이터 종류를 기록합니다.
3. 성능 수치의 조건을 공개하는가
평균 지연 하나보다 측정 구간, 동시 요청, 데이터 크기, 오류율과 백분위 값을 확인합니다. 운영 환경과 다른 시험 결과라면 차이를 설명해야 합니다.
4. 외부 데이터와 API 권한이 명확한가
시세, 차트, 브로커, 메시지와 본인인증 서비스의 계약 주체와 비용을 확인합니다. 데모에서 보인 기능이 실제 계약에서도 합법적으로 제공되는지 라이선스 범위를 확인해야 합니다.
5. 주문·리스크 규칙을 문서화하는가
OMS 상태와 RMS 규칙을 설정 화면으로만 설명하지 않고 데이터 사전, 우선순위와 예외 흐름으로 제공하는지 봅니다. 설정 변경과 승인 기록도 중요합니다.
6. 보안 책임과 업데이트 절차가 있는가
관리자 인증, 최소 권한, 비밀정보 관리, 취약점 접수와 패치 절차를 묻습니다. “보안 적용”이라는 문구보다 담당자, 점검 주기와 결과 처리 방식이 필요합니다.
7. 장애 대응 기록을 제공하는가
SLA에는 접수 시간뿐 아니라 장애 등급, 최초 응답, 임시 조치, 복구 목표와 원인 분석 보고 범위를 넣습니다. 외부 서비스 장애가 발생했을 때 상태를 어떻게 공유하는지도 확인합니다.
8. 데이터 반출과 종료가 가능한가
샘플 데이터를 내려받아 새 환경에서 읽을 수 있는지 확인합니다. 해지나 업체 변경 시 필요한 기간, 비용, 병행 운영과 종료 뒤 삭제 절차를 계약에 포함합니다.
9. 분양은 구매사 환경에서 재현되는가
소스 제공만 확인하지 말고 구매사 계정의 깨끗한 환경에서 빌드·배포합니다. 필요한 외부 키와 라이선스, 운영 문서가 함께 인수되는지 확인합니다.
10. 금융업과 데이터 규제를 구분하는가
책임 있는 공급사는 소프트웨어 제공만으로 금융업 운영 자격이 생긴다고 설명하지 않습니다. 사업자의 인가·등록과 시세 재배포 권한을 별도 과제로 구분해야 합니다.
위험 신호
- 근거 없이 수익, 무중단, 특정 지연 수치를 보장한다.
- 계약서보다 메신저 설명만 믿으라고 한다.
- 시세·차트 출처와 라이선스를 설명하지 못한다.
- 관리자 공용 계정을 사용하고 작업 기록이 없다.
- 데이터 반출 샘플이나 종료 절차가 없다.
요구사항 상담에서는 위 질문을 현재 환경에 맞게 정리할 수 있습니다.
적용 전 확인
이 자료는 B2B 소프트웨어 도입을 위한 일반 정보입니다. 금융투자업 인가, 고객 자금 취급, 주문 중개와 데이터 라이선스 요건은 사업 구조와 관할 지역에 따라 달라질 수 있으므로 실제 운영 전 별도 검토가 필요합니다.