화면·서버·저장소의 역할

저장 버튼을 기능 이름으로만 설명하면 무엇을 놓치나요

신청자가 완료 문구를 봤지만 다음 날 승인 결과를 찾지 못했습니다. 기획자가 “저장 기능은 정상입니다”라고 답하면 사용자가 하려던 결과 확인은 남아 있습니다. 앞 조사에서 선택한 Q01은 결과 경로를 모르는 신청자의 재문의이며 E003과 E006이 근거입니다. 이번에는 이 업무를 화면, API, 저장소의 책임으로 나누어 봅니다. 완료 문구가 보였다는 사실만으로 저장 확정이나 승인 완료를 같은 사건으로 취급하지 않는 것이 목표입니다.

이 모듈은 Python 3와 Node를 사용하는 제공 연습입니다. 압축 파일은 별도 연습 폴더에 풀고 명령은 그 패키지 루트에서 실행합니다. 실제 계정이나 연락처 대신 EV01, A001 같은 가명 식별자를 씁니다. 첫 문서 실습은 그림과 표, 다음 레슨은 로컬 요청 재생, 세 번째는 브라우저 조건문, 마지막은 계약 문서입니다. 미션 시작본에는 앞 모듈 solution의 project-brief.json과 research.json이 들어 있습니다. 기존 근거와 출처를 바꾸지 않고 새 data-flow.json을 추가합니다.

주체의 행동과 시스템의 책임을 구분합니다

화면은 신청자가 행사 선택, 제출, 결과 확인을 할 수 있게 보여 주는 접점입니다. 버튼을 누른 순간에는 입력을 읽고 요청을 준비하며 처리 중이라는 표시를 할 수 있습니다. 그 표시는 서버가 받았다는 보증이 아닙니다. API는 화면과 서버가 주고받을 요청과 응답의 약속이며, 서버는 요청의 입력과 권한을 확인하고 업무 규칙을 적용합니다. 데이터베이스는 신청 행과 상태를 보관하고 정해진 조회 조건에 따라 돌려주는 저장소입니다. API 자체를 별도의 사람이나 DB와 같은 저장 장치로 그리지 않습니다.

이 연습에서는 화면이 API를 통해 서버에 신청을 요청하고 서버가 저장소에 기록합니다. 화면에 값이 보인다고 DB에 같은 값이 들어 있다는 뜻은 아닙니다. 화면은 임시 입력, 이전 조회 결과, 처리 중 상태를 보여 줄 수 있습니다. 서버가 기록한 신청 ID와 승인 대기 상태를 응답한 뒤 화면이 그 값을 표시하도록 책임을 연결합니다. 새로 고친 화면에서 같은 ID로 다시 조회되는지 확인하면 첫 표시와 후속 조회 사이의 일관성을 논의할 수 있습니다.

신청 접수와 행사 승인은 다른 결과입니다

F01의 신청 제출 뒤 F02에서는 운영자가 목록을 검토하고 결과를 남깁니다. 그러므로 신청 저장 성공을 ‘승인되었습니다’라고 표시하면 실제 업무보다 앞선 결과를 약속합니다. 제안 계약의 초기 status는 PENDING이며 화면 문구는 ‘신청이 접수되었습니다. 승인 대기 중입니다’입니다. 운영자 검토가 끝난 뒤 APPROVED 또는 REJECTED가 될 수 있지만 이번 모의 API는 승인 변경을 구현하지 않습니다. 업무 단계가 남아 있다는 사실과 실습에서 실행한 기능을 따로 표시합니다.

신입 기획자가 맡을 일은 내부 코드를 추측하는 것이 아니라 각 경계에서 어떤 입력을 받아 어떤 결과를 내야 하는지 묻는 것입니다. “저장 성공 응답은 어느 시점에 보내나요”, “결과 화면은 어떤 신청 ID를 조회하나요”, “검토 전 상태는 어떻게 나타나나요”가 책임을 확인하는 질문입니다. 구현 담당자는 캐시나 여러 서비스가 있다는 사실을 보완할 수 있습니다. 현재 자료로 모르는 구간은 미확인으로 남기고 설명을 들은 날짜와 확인 대상을 별도로 기록합니다.

화살표마다 전달할 데이터를 적습니다

신청 흐름은 화면→API→DB→API→화면 네 전달로 그립니다. 첫 화살표에는 eventId와 재전송 키, 두 번째에는 검증된 신청 저장 요청, 세 번째에는 저장 확정된 신청 행, 마지막에는 applicationId와 PENDING을 씁니다. 화살표에 ‘통신’이라고만 쓰면 저장할 값과 표시할 값의 차이가 사라집니다. 필드가 어느 경계에서 생성되는지도 적습니다. 신청 ID는 이 제안에서 서버가 생성하고 화면은 반환받은 값을 후속 조회에 사용합니다.

조회 흐름은 화면이 applicationId로 요청하고, 서버가 그 ID의 행을 읽고, 상태나 없음 결과를 응답하고, 화면이 알맞은 상태를 표시하는 순서입니다. DB에서 행을 읽은 결과와 신청자가 결과 경로를 발견하는 일은 다릅니다. 저장소가 정확해도 화면에 신청 내역 경로가 없으면 Q01은 남을 수 있습니다. 따라서 저장 이후 안내에 ‘신청 내역에서 상태 확인’을 넣는 설계 후보를 쓰되 그것이 재문의를 줄였다는 효과는 아직 주장하지 않습니다.

경계	신청에서 확인할 결과	성급한 결론
화면→API	어떤 행사와 키를 보냈는가	버튼이 눌렸으니 접수 완료
API→DB	검증 뒤 기록이 확정됐는가	서버에 도착했으니 승인 완료
API→화면	ID와 대기 상태를 표시했는가	성공 색상이므로 결과 경로도 찾음

실패한 위치와 모르는 위치를 나눕니다

필수 행사 값이 비어 서버가 거부했다면 입력 검증 단계에서 멈춘 사례입니다. 저장소 쓰기가 실패했다면 서버가 성공 응답을 만들기 전에 다른 처리가 필요합니다. 응답이 화면에 도착하지 않았다면 저장 전 실패와 저장 후 응답 유실 모두 가능하므로 저장 여부를 확정할 수 없습니다. ‘버튼이 안 됨’ 하나로 합치지 않고 마지막으로 확인한 경계와 확인하지 못한 경계를 표시합니다. 확인되지 않은 화살표를 성공 색으로 칠하지 않습니다.

요청 ID는 한 시도의 화면 기록과 서버 기록을 연결하는 표식입니다. R01로 신청하고 R02로 조회하면 서로 다른 요청입니다. applicationId=A001은 그 두 요청이 다루는 같은 신청입니다. 재전송 키 K01은 같은 제출 의도를 다시 보내는 경우를 식별하는 제안 규칙입니다. 세 식별자는 목적이 다릅니다. 요청 ID가 있다고 전체 경로 로그가 자동으로 생기거나 실제 인증이 완료되는 것은 아닙니다. 각 경계에 기록이 있는지 개발자와 확인합니다.

그림을 검토 가능한 산출물로 바꿉니다

제출 그림 아래에는 현재 조사 근거, 제안한 흐름, 아직 확인하지 않은 구현을 세 줄로 나눕니다. E003의 경로 탐색과 E006의 안내 누락은 제공 사례의 사실이며 ‘새 신청 내역 API가 있다’는 현재 사실이 아닙니다. E005의 성공 사례도 남겨 결과 경로를 이미 아는 사람은 바로 확인할 수 있다는 조건을 보존합니다. 동료가 그림만 보고 신청 접수와 승인, 요청 ID와 신청 ID를 구별할 수 있으면 다음 계약 논의를 시작할 수 있습니다.

흔한 실수는 DB에서 화면으로 직접 화살표를 보내면서 서버의 검증과 응답을 빠뜨리는 것입니다. 이 연습의 구조에서는 API 경계를 거쳐 표시하므로 네 전달을 맞춥니다. 실제 제품에 다른 구조가 있다면 그 관측으로 별도 그림을 그립니다. 또 ‘대기’가 화면의 네트워크 대기인지 운영자 검토 대기인지 표시하지 않으면 로딩 표시로 며칠간의 검토를 해결하려 할 수 있습니다. 대기 주체와 종료 조건을 한 쌍으로 써서 구분합니다.