앱 화면을 실제 기능으로 구현하는 개발 과정

입력 항목을 정할 때는 데이터 형식과 허용 범위도 함께 정합니다. 작업명에 공백만 들어온 경우를 허용할지, 내용이 비어 있으면 무엇을 저장할지, 입력 길이는 어디까지 받을지 앱과 서버가 같은 규칙을 사용해야 합니다. 이 예시에서는 공백만 있는 작업명은 받지 않고, 비어 있는 내용은 빈 문자열로 다룹니다.

이번 기능의 완료 조건은 서버가 저장을 확정하고 작업 번호를 돌려주며, 그 번호로 같은 내용을 다시 조회할 수 있는 것입니다. ‘등록 완료’는 작업 요청을 저장했다는 뜻이고, 실제 안내판 교체 작업까지 끝났다는 뜻은 아닙니다. 그 업무 상태는 ‘접수’로 구분합니다.

이번 예시에서는 다음과 같이 정합니다. 아래 주소와 필드명은 이 예시를 위한 설계입니다.

앱에서 입력한 두 항목과 서버가 정하는 값을 구분합니다. 작업 번호와 최초 상태, 등록 시각을 앱이 임의로 정해서 저장시키는 방식으로 만들지 않습니다. 서버의 처리 결과를 앱이 받아 같은 기준으로 표시하도록 연결합니다.

이런 요청·응답은 예시 데이터와 함께 명세로 남깁니다. OpenAPI는 HTTP API의 요청과 응답을 기술할 수 있는 표준 형식 중 하나입니다. 명세를 만들었다는 것과 서버를 구현했다는 것은 별개이며, 구현 결과가 이 약속과 맞는지 확인해야 합니다.

작업 번호의 고유성과 필수값 같은 기준은 서버 코드뿐 아니라 데이터베이스의 제약으로도 맞춥니다. 예를 들어 관계형 데이터베이스의 기본키는 기록을 고유하게 식별하는 기준입니다. 이 예시에서 어떤 저장소를 사용할지는 조회 방식·운영 조건에 맞춰 결정합니다.

이번 예시의 서버 처리 순서는 다음과 같습니다.

1. 작업명과 내용의 형식을 확인하고 작업명의 앞뒤 공백을 제거합니다.
2. 작업명이 비었거나 허용되지 않는 요청이면 오류를 반환하고 등록하지 않습니다.
3. 통과한 값으로 새 작업을 저장하고 작업 번호·접수 상태·등록 시각을 연결합니다.
4. 저장이 확정된 작업을 성공 응답으로 반환합니다.

등록 API와 상세 조회 API는 같은 작업 번호와 저장 구조를 사용합니다. 등록 때 받은 1042를 조회하면 ‘안내판 교체’와 같은 내용이 돌아와야 합니다. 조회할 때도 요청자가 그 기록을 볼 수 있는지 서버에서 확인합니다.

서버가 알려진 저장 실패를 반환했을 때는 등록 성공으로 안내하지 않습니다. 응답을 받지 못해 저장 여부를 알 수 없는 경우에는 결과가 확정되지 않은 상태로 다뤄야 합니다. 이때의 결과 확인과 재시도는 요청 실패·중복 처리 과정에서 이어 설명합니다.

작업명 오류가 오면 해당 입력 항목 옆에 수정할 이유를 안내하고, 작성한 내용은 유지합니다. 저장 실패나 결과 미확정 상황도 등록 완료와 구분합니다. 이 상태를 API 명세와 맞춰 두면 화면이 서버의 실제 결과와 다른 성공 안내를 보여주는 문제를 줄일 수 있습니다.

등록 성공 후에는 1042의 상세 화면으로 이어지도록 연결합니다. 상세 화면의 작업명·내용·상태는 조회 API의 결과로 표시합니다. 입력 화면에서 임시로 가지고 있던 값만 계속 보여주면 저장·조회 연결을 확인하기 어렵습니다.

화면 검사에서는 안내와 상태 변화가 맞는지 보고, API 검사에서는 요청·응답이 명세와 맞는지 봅니다. 연결 검사에서는 실제 저장과 별도의 재조회를 대조합니다. 화면에 미리 넣어 둔 결과를 보여주는 시연으로 데이터베이스 저장까지 검증했다고 판단하지 않습니다.

소개한 단계는 같은 기능의 화면·서버·데이터를 맞추는 설명 순서입니다. 실제 개발에서는 API와 저장 구조를 함께 조정하고 검증에서 발견한 문제를 앞 단계에 반영합니다. 언어와 프레임워크는 서비스 조건에 맞춰 선택하되, 입력 규칙·요청·저장·응답·재조회가 같은 기능을 가리키도록 구현하고 확인하는 것이 이 개발 과정의 핵심입니다.