화면 목록을 넘어, 동작과 검수 기준을 설계합니다

1. 새로 만들 기능과 기존 기능을 먼저 나눕니다

요청서에 ‘HTS, MTS, 관리자 페이지 개발’만 적으면 실제 범위를 판단하기 어렵습니다. 기존 모듈의 설정 변경으로 가능한 작업인지, 외부 시스템을 연결하는 작업인지, 새로운 기능을 설계하는 작업인지 나누세요. 각 범주의 비용과 일정, 검수 방식은 다를 수 있습니다.

특히 이용자 화면의 버튼 하나도 서버 처리, 권한, 상태 조회와 운영자 확인 기능을 함께 요구할 수 있습니다. 화면 설계와 뒤에서 일어나는 업무 흐름을 연결하면 빠지는 항목을 줄일 수 있습니다. 새 화면이 왜 필요한지와 사용자가 작업을 끝냈다고 판단하는 기준부터 설명하는 것이 좋습니다.

• 현재 문제: 어느 사용자나 담당자가 어떤 과정에서 어려움을 겪는지 기록합니다.
• 변경 범위: 유지할 기능, 바꿀 기능과 이번에 제외할 기능을 구분합니다.
• 외부 조건: 접근 권한, 시험 계정, 외부 API 문서와 제공 가능한 자료를 확인합니다.
• 완료 기준: 어떤 동작과 문서를 확인하면 해당 작업을 마쳤다고 볼지 정합니다.

2. 한 기능을 검수 가능한 문장으로 작성합니다

요구사항은 기능 이름보다 입력, 처리, 결과와 예외를 포함해야 합니다. 아래는 주문 취소 화면을 검토할 때 사용할 수 있는 작성 형식입니다. 실제 상태와 처리 규칙은 연결하는 시스템의 명세에 맞춰 합의해야 하며, 예시를 그대로 모든 환경의 규칙으로 사용해서는 안 됩니다.

작은 화면에서는 표를 좌우로 움직여 확인할 수 있습니다.

이렇게 작성하면 화면 개발자, 서버 개발자와 검수 담당자가 같은 질문에 답할 수 있습니다. 아직 결정하지 못한 조건은 임의로 채우지 말고 결정 담당자와 확인 기한을 표시하세요.

3. HTS·MTS·웹 화면의 공통점과 차이를 구분합니다

모든 단말에서 같은 기능 이름을 사용하더라도 화면 크기와 입력 방식, 연결 상태는 다릅니다. 계정·권한·처리 결과처럼 일관되어야 할 항목과 단말별로 다르게 설계할 항목을 구분해야 합니다. 한 화면을 축소해 붙이는 방식만으로 모바일 사용성을 확인할 수는 없습니다.

• HTS: 여러 창과 단축키, 표의 정보 밀도, 확대·축소와 고해상도 화면에서의 동작을 확인합니다.
• MTS: 터치 입력, 화면 회전, 앱 전환 후 복귀와 연결 상태 안내를 검토합니다.
• 웹 화면: 지원 브라우저, 작은 화면, 키보드 이동과 새로고침 이후 상태를 확인합니다.
• 관리 도구: 대량 자료 조회, 역할별 권한, 변경 확인과 감사 기록을 검토합니다.

공통 기능도 단말별 시험 목록을 남기세요. 버튼이 눌린다는 것과 사용자가 현재 상태를 이해하고 다음 행동을 선택할 수 있다는 것은 다른 확인입니다.

4. API 연동은 정상 응답 외의 조건이 중요합니다

연동 문서에는 주소와 요청 예시뿐 아니라 인증, 사용 제한, 오류와 연결 복구 조건이 필요합니다. 외부 공급자의 시험 환경과 운영 환경이 다를 수 있으므로 이용 가능한 기능과 접근 절차를 확인하세요. API 키나 실제 고객 자료를 공개 문서에 포함하지 않도록 전달 경로도 정해야 합니다.

작은 화면에서는 표를 좌우로 움직여 확인할 수 있습니다.

외부 응답이 늦다고 무조건 요청을 다시 보내는 규칙을 두기보다, 대상 시스템의 명세와 확인 가능한 상태를 바탕으로 처리 방식을 합의하세요. 응답을 받지 못한 상황에서 담당자가 무엇을 확인할 수 있는지가 중요합니다.

5. 성능과 품질은 측정 구간부터 정의합니다

‘빠른 체결’ 같은 표현은 프로그램 내부 처리, 네트워크 전달과 외부 시스템의 결과를 섞을 수 있습니다. 어느 지점부터 어느 지점까지 시간을 재는지 정의하고, 시험 환경·부하·자료량·버전을 같이 기록하세요. 다른 조건에서 측정한 하나의 수치만으로 두 제안을 비교하지 않는 것이 좋습니다.

측정값은 목표인지, 시험 결과인지, 계약에서 합의한 기준인지 구분합니다. 평균뿐 아니라 느린 구간, 실패한 요청과 복구 과정을 함께 확인하세요. 성능 시험은 허가된 환경에서 수행하며 실제 외부 서비스에 영향을 주는 시험은 별도의 합의가 필요합니다.

화면 품질도 검수 항목입니다. 오류 문구가 다음 행동을 설명하는지, 입력한 내용이 실수로 사라지지 않는지, 키보드로 주요 기능을 사용할 수 있는지, 확대했을 때 정보가 겹치지 않는지 확인하세요. 출시 후 수정하기 어려운 사용자 흐름을 개발 초기에 검토하는 편이 좋습니다.

6. 단계마다 확인할 산출물을 정합니다

1. 범위 정리: 요구사항 목록, 외부 의존성, 제외 항목과 미정 사항을 합의합니다.
2. 화면·흐름 검토: 주요 화면과 상태 변화, 오류와 권한별 동작을 확인합니다.
3. 핵심 연동 확인: 시험 환경에서 필요한 요청과 상태 조회가 가능한지 검증합니다.
4. 기능 개발·통합: 버전별 구현 항목과 남은 문제를 공유하고 기능 간 연결을 시험합니다.
5. 인수 검수: 합의한 시나리오, 성능 조건과 운영 자료를 기준으로 확인합니다.
6. 운영 전환: 담당자 교육, 배포·복구 계획과 초기 확인 절차를 실행합니다.

이 단계는 협의를 위한 예시이며 고정 납기를 뜻하지 않습니다. 연동 접근권 확보, 요구사항 확정과 검수 응답처럼 도입 기업이 준비해야 하는 일도 일정표에 포함해야 전체 일정을 현실적으로 판단할 수 있습니다.

7. 변경 요청과 결함을 구분해 관리합니다

기존 요구사항과 다르게 동작하는 문제와 새로운 기능 요청을 나눠 기록하세요. 요청의 배경, 변경할 동작, 영향을 받는 화면·연동·자료와 검수 방법을 적으면 작업 범위를 판단하기 쉽습니다. 비용과 일정에 영향이 있다면 적용 전에 승인 절차를 거치는 것이 좋습니다.

긴급 수정도 기록이 필요합니다. 어떤 버전을 변경했고 무엇을 확인했는지, 되돌릴 수 있는 범위가 무엇인지 남기세요. 외부 API나 자료 구조의 변경은 화면 하나의 수정으로 끝나지 않을 수 있으므로 운영 담당자도 함께 검토해야 합니다.

8. 개발 완료와 운영 준비 완료를 따로 확인합니다

기능 구현이 끝나도 설치·백업·장애 확인 방법을 운영팀이 모르면 인계가 완성되지 않습니다. 제공 범위에 맞는 프로그램과 문서, 설정 목록, API 명세, 시험 결과와 알려진 제한을 전달받으세요. 소스 제공이 계약에 포함된다면 대상 모듈과 빌드·사용 조건도 확인합니다.

운영 전환 계획에는 확인 담당자, 적용 순서, 문제 발생 시 중단 기준과 복구 절차가 필요합니다. 자료 구조가 달라지는 작업이라면 이전 자료를 어떤 시점까지 보존하고 결과를 어떻게 대조할지도 정해야 합니다. 구체적인 운영 항목은 운영·장애 대응 가이드에서 확인할 수 있습니다.

자주 묻는 질문

기존 임대 솔루션에 기능을 추가할 수도 있나요?

사용 중인 제품의 변경 권한, 제공 API와 공급사의 지원 범위를 먼저 확인해야 합니다. 가능한 변경과 별도 시스템이 필요한 변경을 나누고, 이후 업데이트 시 유지 조건도 합의하세요.

화면 예시만 보내도 견적을 받을 수 있나요?

초기 상담 자료로 사용할 수 있지만 화면만으로 연동·권한·예외 처리 범위가 정해지지는 않습니다. 사용 목적과 주요 동작을 함께 전달하면 더 구체적인 범위 협의가 가능합니다.

개발이 끝나면 소스를 모두 받게 되나요?

제공 조건은 계약마다 다릅니다. 기존 모듈과 신규 개발물, 외부 구성요소를 나눠 확인하세요. 관련 질문은 분양·소스 인수 가이드에 정리했습니다.

현재 해결할 문제와 필요한 화면·연동을 정리해 개발 상담을 시작하세요. 표준 기능 활용을 먼저 검토한다면 임대 방식과 함께 비교할 수 있습니다.