HTS·MTS·WTS, 같은 업무를 다른 환경에서
PC 설치형 HTS, 모바일 중심의 MTS, 브라우저 기반 WTS는 접속 환경이 다릅니다. 모두 필요하다는 결론부터 내리기보다 주로 사용할 단말, 화면에 담을 정보의 양, 설치와 업데이트 방식부터 살펴보세요. 모바일 앱과 모바일 웹도 배포·기기 권한·업데이트 과정이 같지 않습니다.
| 환경 | 화면 설계의 초점 | 검토할 사용 상황 |
|---|---|---|
| HTS | 여러 창의 배치, 키보드 조작, 표시 정보의 밀도 | 해상도 변경, 다중 화면, 프로그램 업데이트 |
| MTS | 작은 화면의 우선순위, 터치 영역, 화면 전환 | 앱 복귀, 네트워크 전환, 기기별 표시 |
| WTS | 브라우저 호환과 반응형 배치, 설치 없는 접근 | 탭 복귀, 확대 보기, 세션 종료 |
| 관리자 도구 | 역할별 조회·변경·승인, 이력 확인 | 권한 변경, 일괄 작업, 잘못된 설정의 복구 |
여러 단말을 제공한다면 동일한 항목을 서로 다른 용어로 표시하지 않는지도 확인해야 합니다. 기능을 똑같이 복제하기보다 각 단말에서 반드시 끝낼 수 있어야 하는 업무를 먼저 정하는 편이 명확합니다.
버튼을 눌렀다는 사실과 처리 결과를 구분합니다
입력, 전송 시도, 응답 대기, 결과 확인은 서로 다른 상태입니다. 사용자 화면은 이 차이를 알아볼 수 있게 표현해야 합니다. 응답이 아직 없는데 완료로 표시하거나, 화면을 다시 열었을 때 이전 요청이 사라져 보이는 상황을 검수 항목에 넣어보세요.
주문·정정·취소 화면에서 확인할 예외
- 입력 조건을 충족하지 못하면 어떤 항목을 수정해야 하는지 구체적으로 안내하는가?
- 연속 클릭이나 재전송이 발생했을 때 중복 요청을 식별할 수 있는가?
- 취소 요청을 보낸 뒤 외부 결과가 확정되기 전까지 대기 상태가 구분되는가?
- 일부 처리, 거절, 상태 불명 등 연동 명세에 있는 결과를 빠뜨리지 않았는가?
- 다시 접속하면 어떤 근거로 최신 상태를 조회하고 이전 화면과 대조하는가?
실제 상태 이름과 전환 규칙은 연결 대상의 명세에 맞춰야 합니다. 취소 버튼을 누르는 행위가 이미 처리된 결과를 되돌린다는 뜻은 아닙니다. 상태를 확인할 수 없는 경우에도 성공이나 실패를 임의로 단정하지 않도록 설계해야 합니다.
시세와 차트에는 데이터의 기준이 필요합니다
가격이 화면에 표시된다는 것만으로 검수가 끝나지는 않습니다. 어떤 출처의 어떤 항목인지, 시간대와 표시 단위는 무엇인지, 업데이트가 멈췄을 때 어떻게 알릴지를 정해야 합니다. 차트와 목록, 상세 화면이 서로 다른 시점의 값을 보여주는 경우를 어떻게 설명할지도 확인하세요.
연결이 끊긴 동안의 값과 복구 후 받은 값을 구분할 수 있어야 합니다. 다시 접속할 때 누락 구간을 조회할 수 있는지, 조회할 수 없다면 화면에 어떤 제한을 알릴지 검토합니다. 서버가 응답하더라도 데이터 갱신이 멈출 수 있으므로 연결 표시와 데이터 최신성은 따로 확인하는 편이 좋습니다.
과거 데이터의 제공 범위, 저장·재표시 가능 여부, 사용자별 이용 조건은 데이터 제공자와의 약정에 따라 확인해야 합니다. 소프트웨어 화면을 개발하는 계약이 필요한 데이터의 이용 권한까지 자동으로 포함하지는 않습니다.
API 연동은 명세와 사용 권한에서 시작합니다
연결 대상의 이름만으로 연동 가능 여부를 확정하기는 어렵습니다. 제공되는 인터페이스, 계정 권한, 시험 환경과 요청 제한을 확인해야 합니다. 기존 시스템과 함께 사용한다면 같은 항목을 어느 시스템에서 관리할지도 정해 두세요.
| 자료 | 확인할 질문 |
|---|---|
| 공식 기술 명세 | 버전, 요청·응답 형식, 오류 코드가 확인되는가? |
| 권한과 시험 환경 | 어떤 작업이 허용되며 운영 환경과 어떻게 구분되는가? |
| 호출·연결 제한 | 요청량 제한, 재접속 조건과 중복 처리 기준은 무엇인가? |
| 상태 대조 방법 | 응답 누락이나 통신 종료 후 최종 결과를 조회할 수 있는가? |
| 변경 안내 방식 | 명세 변경과 서비스 중단을 누가 확인하고 전달하는가? |
초기 상담에는 비밀키 대신 문서와 비식별 예시를 전달하세요. 실제 접속 정보가 필요한 단계에서는 담당자와 안전한 전달·보관·회수 방법을 먼저 합의해야 합니다.
관리자 화면은 권한과 변경 기록을 중심으로
관리 도구의 메뉴가 많다고 운영이 쉬워지는 것은 아닙니다. 조회만 필요한 담당자와 설정을 변경하는 담당자를 구분하고, 영향이 큰 작업은 확인이나 승인 절차가 필요한지 판단하세요. 화면을 숨기는 것과 실제 변경 권한을 제한하는 것은 따로 검증해야 할 항목입니다.
설정 변경 기록에는 누가, 언제, 무엇을 바꾸었는지 확인할 수 있는 범위를 정합니다. 내보내기 파일에 포함할 정보와 내려받기 권한, 검색 조건과 기간 제한도 함께 검토하세요. 모든 정보를 오래 남기는 것이 목적이 아니라 운영에 필요한 근거를 적절한 권한으로 확인하는 것이 목적입니다.
구성표를 실제 사용 시나리오로 검증합니다
성능 비교에는 같은 조건이 필요합니다. 사용자 수뿐 아니라 동시에 처리하는 작업, 데이터량, 단말과 네트워크, 측정 구간을 적어야 결과를 해석할 수 있습니다. 프로그램 내부 처리 시간과 외부 시스템의 응답 시간, 실제 거래 결과를 한 숫자로 묶어 설명하지 않도록 주의하세요.
- 대표 사용자별로 접속부터 업무 종료까지의 흐름을 정합니다.
- 정상 처리와 함께 권한 부족, 응답 지연, 연결 종료를 시험합니다.
- 화면 결과와 관련 기록을 대조하고 다시 접속한 뒤에도 확인합니다.
- 수정한 항목과 남은 제한을 기록한 뒤 같은 조건으로 재검수합니다.
시험은 허가된 환경과 데이터로 진행해야 합니다. 구체적인 검수·인수 과정은 구축과 운영 준비에서, 도입 형태의 차이는 임대·분양·개발 비교에서 이어서 확인할 수 있습니다.