요청과 응답 (Request and Response)

요청과 응답(Request and Response)은 클라이언트가 수행할 동작을 보내고 서버가 그 처리 결과를 돌려주는 메시지 교환 방식입니다. 웹의 HTTP 통신에서는 요청에 메서드와 대상이, 응답에 상태 코드가 포함됩니다. 요청을 전송했다는 사실과 서버가 받아들였다는 사실, 실제 업무가 끝났다는 사실은 각각 확인할 대상입니다.

메시지에 담기는 동작과 결과

MDN의 HTTP 메시지 안내는 클라이언트가 서버의 동작을 요청하는 메시지와 서버가 보내는 응답 메시지를 구별합니다. 브라우저에서 문서를 열거나 앱에서 데이터를 저장할 때 이 교환이 일어납니다. 한 화면을 표시하는 동안 문서와 이미지, 추가 데이터를 받는 여러 요청이 발생할 수 있어 화면 하나와 요청 하나가 항상 대응하지는 않습니다.

요청의 메서드는 원하는 동작의 의미를 나타내고 요청 대상은 그 동작을 적용할 자원을 가리킵니다. 헤더에는 메시지를 해석하는 데 필요한 정보가 들어갑니다. 본문이 있다면 서버에 전달할 데이터가 실립니다. 회원 정보를 보내는 요청에서는 같은 주소라도 메서드와 본문이 다르면 처리 의미가 달라집니다. 주소만 복사해 열어 보는 것으로 원래 요청을 재현했다고 판단하기 어려운 이유입니다.

응답에는 상태 코드와 헤더가 있고, 응답 종류에 따라 본문이 붙습니다. 성공한 조회라면 요청한 데이터가, 실패라면 오류를 설명하는 내용이 올 수 있습니다. 본문이 없는 응답도 있으므로 모든 응답을 JSON으로 읽는 코드는 실제 계약과 어긋날 수 있습니다. API를 연결할 때는 요청 형식뿐 아니라 상태별 응답 형식도 함께 맞춥니다.

통신 응답과 업무 완료의 구분

HTTP 의미 명세 RFC 9110은 상태 코드로 요청의 결과와 응답의 의미를 전달합니다. 특히 202 Accepted는 처리를 위해 요청을 받아들였지만 처리가 아직 끝나지 않았음을 나타냅니다. 동영상 생성 요청에서 작업 번호를 받았다면 생성 완료 여부는 그 번호로 조회하는 별도 계약을 따릅니다. 접수 응답을 최종 영상이 만들어졌다는 신호로 바꾸어 해석하지 않습니다.

응답 전체가 한꺼번에 도착하는 것도 아닙니다. 스트리밍으로 내용을 차례로 전달하면 클라이언트는 일부 데이터를 먼저 처리합니다. 첫 조각을 받았을 때와 본문을 끝까지 읽었을 때의 시각은 다릅니다. 연결 중단으로 일부만 받은 경우에는 화면에 글자가 보였더라도 전체 결과가 완성됐는지 확인할 필요가 있습니다. 처리 완료 표시는 서비스가 정한 종료 신호와 연결합니다.

요청을 보낸 뒤 기다리는 동안 연결이 끊기면 서버가 어디까지 처리했는지 알기 어려울 수 있습니다. 클라이언트가 응답을 받지 못했다는 사실만으로 서버도 작업하지 않았다고 단정할 수 없기 때문입니다. 결제나 주문 생성처럼 반복 실행의 영향이 큰 작업은 작업 식별자와 중복 처리 규칙을 확인합니다. 단순히 같은 요청을 다시 보내는 방법이 모든 실패의 복구 방법은 아닙니다.

오류를 나누어 확인하는 기준

같은 HTTP 명세의 메서드 설명은 같은 요청을 여러 번 보내도 의도한 서버 효과가 한 번 보냈을 때와 같은 성질을 멱등성으로 설명합니다. 실제 재시도는 메서드 의미와 서비스의 구현 계약을 함께 봅니다. 요청마다 새 작업을 만드는 동작이라면 응답을 놓쳤을 때 기존 작업을 먼저 찾는 방식이 필요할 수 있습니다.

개발 도구의 네트워크 기록에서는 요청 URL, 메서드, 헤더, 본문과 응답 상태를 연결해 읽습니다. 서버에 도달하지 못한 연결 오류와 서버가 보낸 오류 응답은 조사할 위치가 다릅니다. 인증 정보 누락, 잘못된 데이터 형식, 서버 내부 처리 실패도 같은 현상으로 묶지 않습니다. 로그를 공유할 때는 인증 헤더나 개인 데이터가 포함되는 범위를 확인합니다.

요청과 응답을 시험하는 기록에는 어떤 입력에 어떤 상태와 본문이 돌아왔는지 남깁니다. 성공 상태만 확인하면 필요한 필드가 누락됐거나 내용이 다른 경우를 놓칠 수 있습니다. 반대로 사용자 화면이 정상이어도 뒤에서 보낸 부가 요청은 실패할 수 있습니다. 화면 결과와 개별 통신 기록을 연결하면 어느 교환까지 확인했는지 다시 추적할 수 있습니다.