클라우드에 수 기가바이트에 달하는 대용량 동영상 파일을 업로드하고 있습니다. 진행률 표시줄은 느릿느릿 움직이고 있습니다. 갑자기 브라우저가 멈춥니다. 페이지가 응답하지 않는 것 같습니다. 몇 분간의 초조한 기다림 끝에, 당신은 끔찍한 오류 메시지를 받습니다: 504 Gateway Timeout. 서버가 당신을 포기한 것입니다.
이제 다른 시나리오를 상상해 보세요. 업로드 속도는 여전히 느리지만, 페이지에 작은 회전 표시기가 활성화되어 있습니다. "동영상을 처리 중입니다... 몇 분 정도 걸릴 수 있습니다."라는 알림을 받습니다. 당신은 인내심을 가지고 기다리고, 결국 성공 메시지를 받습니다.
무엇이 달랐을까요? 두 번째 시나리오에서는 서버가 당신의 기대를 관리하기 위해 영리하지만 드문 HTTP 상태 코드인 102 Processing을 사용했을 수 있습니다.
이 상태 코드는 서버가 정중하게 "요청을 받았습니다. 큰 작업이라 완료하는 데 시간이 좀 걸릴 겁니다. 하지만 저는 아직 살아있고 작업 중이니, 제 연결을 끊지 말아 주세요!"라고 말하는 방식입니다.
이는 주방이 복잡한 요리를 준비하느라 바쁜 동안 웨이터가 당신의 테이블을 확인하는 것과 같은 디지털적 비유입니다. 그들은 아직 당신의 음식을 가져오지 않았지만, 당신의 주문이 잊히지 않았음을 확신시켜 주고 있습니다.
웹 개발이나 API 통합에 관여해 본 적이 있다면, 200 OK나 404 Not Found와 같은 인기 있는 HTTP 상태 코드를 분명히 훑어보셨을 겁니다. 하지만 102 Processing과 같이 덜 알려져 있지만 똑같이 중요한 코드들도 존재합니다. 널리 이해되지는 않지만, 이 HTTP 상태는 클라이언트와 서버 간의 통신 효율성을 향상시키는 데 도움이 되며, 특히 복잡하거나 오래 걸리는 요청을 처리할 때 더욱 그렇습니다.
언뜻 보기에 혼란스러울 수 있습니다. "처리 중"이란 정확히 무엇일까요? 서버는 왜 이 메시지를 보내야 할까요? 그리고 가장 중요하게, 개발자는 실제 애플리케이션에서 이를 어떻게 처리해야 할까요?
이 가이드에서 바로 그것을 살펴보겠습니다.
이 상세한 블로그 게시물에서, 당신은 102 Processing 상태 코드가 무엇을 의미하는지, 왜 도입되었는지, 어떻게 작동하는지, 그리고 어떤 시나리오에서 사용되는지 발견하게 될 것입니다. 102 Processing과 같은 희귀한 HTTP 상태 코드를 포함하여 테스트하고 싶다면, 신뢰할 수 있는 API 테스트 플랫폼이 필요합니다. 바로 Apidog이 필요한 지점입니다. Apidog을 사용하면 실시간으로 응답을 검사하면서 API를 설계, 목업, 테스트, 디버그, 그리고 문서화할 수 있습니다. 그리고 가장 좋은 점은? 오늘 Apidog을 무료로 다운로드하여 `102 Processing`과 같은 코드를 직접 탐색할 수 있다는 것입니다.
이제 HTTP 102 Processing 상태 코드의 목적, 역사 및 실제 적용에 대해 살펴보겠습니다.
문제: 참을성 없는 인터넷
인터넷은 참을성 없음이라는 기반 위에 구축되어 있습니다. HTTP 연결은 영원히 열려 있도록 설계되지 않았습니다. 클라이언트(당신의 브라우저)부터 잠재적인 프록시 및 로드 밸런서에 이르는 체인의 모든 구성 요소에는 내장된 타임아웃이 있습니다.
서버가 응답을 보내는 데 너무 오래 걸리면, 이 구성 요소들은 연결이 끊어졌다고 가정하고 연결을 종료하며, 종종 다음과 같은 오류가 발생합니다:
504 Gateway Timeout: 프록시 서버가 업스트림 서버로부터 제시간에 응답을 받지 못했습니다.408 Request Timeout: 서버가 클라이언트로부터의 요청을 기다리는 동안 타임아웃되었습니다.- 클라이언트 측 타임아웃: 브라우저 또는 애플리케이션 자체가 서버를 기다리는 것을 포기합니다.
이는 합리적인 안전장치입니다. 이는 연결 끊김이 귀중한 자원을 소모하는 것을 방지합니다. 그러나 대용량 동영상 처리, 복잡한 보고서 생성, 대량 데이터 작업 수행과 같이 완료하는 데 단순히 오랜 시간이 걸리는 합법적인 작업에는 문제가 됩니다.
질문은 이겁니다: 서버가 최종 응답을 실제로 보내지 않고 "아직 작업 중입니다"라고 클라이언트에게 어떻게 알릴까요?
RFC 2518(WebDAV용)에 정의된 답은 102 Processing 상태 코드입니다.
상태 코드 102 Processing이란 무엇인가요?
HTTP 상태 코드 102 Processing은 1xx 정보 응답 클래스에 속합니다. 이 상태 코드들은 최종 응답을 나타내지 않고, 대신 요청-응답 라이프사이클 동안 추가 정보를 제공합니다.
구체적으로, 102 Processing은 다음을 의미합니다:
"서버가 당신의 요청을 받았으며 활발히 작업 중이지만, 아직 최종 응답은 준비되지 않았습니다."
이 상태 코드는 RFC 2518(HTTP의 WebDAV 확장)에 정의되었습니다. 주로 클라이언트에게 다음을 알리기 위해 설계되었습니다:
- 요청이 유효합니다.
- 서버가 요청을 처리하느라 바쁩니다.
- 응답이 지연된다고 해서 클라이언트가 타임아웃되거나 실패로 가정해서는 안 됩니다.
성공 또는 실패를 알리는 일반적인 응답 코드와 달리, 102는 클라이언트에게 정보를 계속 제공하고 오래 걸리는 요청에서 조기 타임아웃을 방지하는 방법입니다.
WebDAV 연결
102 Processing을 이해하려면 WebDAV (웹 분산 저작 및 버전 관리)에 대해 이야기해야 합니다. WebDAV는 클라이언트가 원격 웹 서버에서 파일을 공동으로 편집하고 관리할 수 있도록 하는 HTTP의 확장입니다. 이는 Windows 또는 macOS에서 매핑할 수 있는 "네트워크 드라이브" 뒤에 있는 기술입니다.
수천 개의 파일이 포함된 폴더를 복사하거나 이동하는 것과 같은 WebDAV 작업은 매우 오랜 시간이 걸릴 수 있습니다. `102` 상태 코드는 이러한 긴 작업 동안 연결을 유지하기 위해 이 컨텍스트에 특화하여 발명되었습니다.
102 Processing은 왜 존재할까요?
현대 웹 요청은 종종 복잡하고 시간이 많이 소요될 수 있으며, 특히 처리가 다음을 포함할 때 더욱 그렇습니다:
- 여러 백엔드 서비스
- 심층적인 데이터 유효성 검사
- 오래 걸리는 계산 또는 데이터베이스 작업
- 복잡한 WebDAV 작업
대용량 파일을 업로드하거나 API를 통해 복잡한 데이터베이스 작업을 실행하는 것을 상상해 보세요. 서버가 응답하는 데 너무 오래 걸리면 클라이언트는 뭔가 잘못되었다고 생각하고 연결을 끊을 수 있습니다.
바로 이 지점에서 102 Processing이 등장합니다.
클라이언트에게 이렇게 말합니다: "진정하세요, 요청을 받았습니다. 시간이 걸리지만 처리 중입니다."
이는 특히 다음 경우에 유용합니다:
- 오래 걸리는 작업: 파일 업로드, 배치 처리, 대규모 쿼리.
- 타임아웃 방지: 클라이언트가 요청이 실패했다고 가정하는 것을 방지합니다.
- 사용자 경험 향상: 최종 결과 없이도 진행 상황을 알림으로써.
102가 도입되기 전에는 클라이언트가 요청이 단순히 느린 것인지 아니면 손실된 것인지 알 수 없었으며, 이는 종종 불필요한 재시도나 연결 타임아웃으로 이어졌습니다. 102 코드는 클라이언트에게 "기다려, 작업 중이야!"라고 말하는 심장 박동과 같은 역할을 합니다.
WebDAV에서 102의 역할
102 Processing은 원래 공동 파일 관리를 위해 HTTP를 확장한 WebDAV(웹 분산 저작 및 버전 관리)에서 도입되었습니다.
예를 들어, 사용자가 500MB 파일을 업로드하는 경우:
- 서버는 이를 처리하는 데 몇 분이 걸릴 수 있습니다.
- 서버는 침묵하는 대신 주기적으로 `102 Processing`으로 응답할 수 있습니다.
- 이는 클라이언트에게 요청이 여전히 활성 상태임을 안심시킵니다.
WebDAV가 주요 동기였지만, `102`는 현대 REST API 및 과도한 워크로드를 처리하는 클라우드 서비스에서도 유용할 수 있습니다.
100 Continue와 102 Processing의 차이점
102가 유사한 100 Continue와 어떻게 다른지 궁금할 수 있습니다:
- 100 Continue: 클라이언트가 요청 본문을 보내기 전에 전송됩니다. 서버가 전체 페이로드를 받을 준비가 되었음을 알립니다.
- 102 Processing: 전체 요청이 수신된 후에 전송되며, 실제 처리가 아직 진행 중임을 클라이언트에게 알립니다.
이러한 상태 코드들은 함께 복잡한 요청 주기 동안 통신 효율성을 향상시킵니다.
작동 방식: 통신 흐름
실제 `102 Processing` 응답의 가상 예시를 살펴보겠습니다.
시나리오: 클라이언트가 서버에게 "업로드된 모든 이미지를 처리하여 파노라마 사진을 생성하라"고 지시합니다. 이는 90초가 소요되는 CPU 집약적인 작업입니다.
요청:
클라이언트가 `/api/generate-panorama`로 `POST` 요청을 보냅니다.
즉각적인 (102) 응답:
서버의 API는 요청을 수신하고 유효성을 검사합니다. 작업에 시간이 걸릴 것이라는 것을 알고 있습니다. 침묵하는 대신 즉시 다음을 다시 보냅니다:
HTTP/1.1 102 Processing
이 응답에는 본문이 없습니다. 단지 상태 라인과 헤더뿐입니다. 유일한 역할은 "처리 중입니다"라고 말하는 것입니다.
대기 기간:
클라이언트는 `102` 코드를 수신합니다. 잘 작동하는 클라이언트는 이것이 연결을 열어두고 계속 기다려야 한다는 의미임을 이해합니다. 클라이언트의 타임아웃 타이머는 사실상 재설정됩니다.
최종 응답:
90초 후, 서버는 파노라마 생성을 완료합니다. 이제 동일한 연결을 통해 실제 응답을 보냅니다:
HTTP/1.1 200 OKContent-Type: application/json
{"status": "success", "url": "/images/panorama-123.jpg"}
요청-응답 주기가 이제 완료되었습니다.
이 간단한 "연결 유지" 신호는 네트워크 장비와 클라이언트가 서버가 다운되었다고 착각하는 것을 방지합니다.
102 Processing이 더 흔하지 않은 이유는 무엇일까요?
이것이 그렇게 유용하다면, 왜 대부분의 개발자는 이를 본 적도 사용한 적도 없을까요? 몇 가지 주요 이유가 있습니다:
비동기 패턴의 부상:
오래 걸리는 요청에 대한 현대적인 해결책은 종종 `102 Processing`보다 낫습니다. 몇 분 동안 연결을 열어두는 대신, 이제 가장 좋은 방법은 다음과 같습니다:
- 요청을 즉시 수락하고 `202 Accepted` 상태 코드를 반환합니다.
- 작업에 대한 고유 ID와 클라이언트가 나중에 상태를 확인할 수 있는 URL(예: `Location: /api/jobs/job-123`)을 반환합니다.
- 백그라운드 워커에서 작업을 비동기적으로 처리합니다(예: Redis Queue, Celery 또는 Amazon SQS 사용).
- 클라이언트가 상태 URL을 폴링하거나 웹훅을 사용하여 작업이 완료되면 클라이언트에게 알리도록 합니다.
이 패턴은 더 확장 가능합니다. 오래 걸리는 작업을 기다리느라 귀중한 서버 프로세스나 연결을 묶어두지 않습니다.
제한된 클라이언트 지원:
102 Processing이 작동하려면 클라이언트가 이를 처리하는 방법을 알아야 합니다. 모든 HTTP 클라이언트와 라이브러리가 단일 연결에서 여러 응답을 예상하거나 올바르게 해석하도록 구축된 것은 아닙니다. 폴링을 사용하는 비동기 패턴은 보편적으로 이해됩니다.
모든 문제를 해결하지는 않습니다:
102 응답은 *연결*의 타임아웃을 재설정하지만, 진행 상황 업데이트는 제공하지 않습니다. 클라이언트는 여전히 작업이 1% 완료되었는지 99% 완료되었는지 알 수 없습니다. 폴링 패턴은 상태 응답에 진행률 필드를 포함할 수 있도록 합니다.
102 Processing의 실제 예시
실제로 어떻게 보이는지 살펴보겠습니다.
클라이언트 요청:
PUT /files/large-video.mp4 HTTP/1.1
Host: example.com
Content-Length: 600000000
서버 응답 (아직 작업 중일 때):
HTTP/1.1 102 Processing최종 서버 응답 (완료 시):
HTTP/1.1 201 Created
Location: /files/large-video.mp4
여기서 `102` 응답은 최종 `201 Created` 응답 전에 진행 상황이 발생하고 있음을 클라이언트에게 안심시킵니다.
현대적 사용 및 대안
순수한 `102 Processing`은 드물지만, 그것이 해결하는 문제는 그렇지 않습니다. 현대 웹은 더 견고하고 확장 가능한 다른 전략을 채택했습니다:
202 Accepted+ 폴링: 위에서 설명했듯이, 이는 오늘날 가장 일반적이고 확장 가능한 패턴입니다.- 서버 전송 이벤트(SSE): 서버가 진행 상황 업데이트를 푸시하려는 오래 걸리는 작업의 경우, SSE는 서버가 클라이언트에게 여러 이벤트를 보낼 수 있는 단방향 채널을 제공합니다.
- 웹훅: 궁극적인 디커플링입니다. 서버는 작업을 처리한 다음, 클라이언트가 제공한 URL로 콜백(웹훅)을 보내 완료를 알립니다.
그러나 `102 Processing`은 특정 시나리오, 특히 다음의 경우 내부 API 또는 시스템에서 여전히 유용한 도구가 될 수 있습니다:
- 동기 인터페이스가 필요하지만 가끔 오래 걸리는 작업이 있는 경우.
- 클라이언트와 서버를 모두 제어할 수 있고, 둘 다 `102` 코드를 올바르게 처리하도록 보장할 수 있는 경우.
- 작업이 길지만, 완전한 비동기 작업 시스템의 복잡성을 정당화할 만큼 길지 않은 경우.
실제 사용 사례
실제로 `102 Processing`을 어디서 만날 수 있을까요?
- 파일 업로드: 파일이 수신되었지만 처리가 더 오래 걸리는 대용량 데이터 제출.
- 데이터베이스 작업: 오래 걸리는 쿼리 또는 업데이트 실행.
- 배치 작업: 복잡한 워크플로 또는 다단계 백엔드 작업을 트리거하는 요청.
- 분산 시스템: 여러 서비스 종속성으로 인해 시간이 더 오래 걸리는 작업.
- WebDAV 클라이언트: 102 Processing은 WebDAV 확장 기능에서 시작되었으며, 요청에 여러 하위 작업이 상당한 시간을 소요할 수 있습니다.
클라이언트는 102 Processing을 수신할 때 무엇을 해야 할까요?
102 응답은 순전히 정보성 응답이므로, 클라이언트는 일반적으로 다음을 수행합니다:
- 연결을 열어두고 최종 상태를 기다립니다.
- 서버가 활발히 처리 중임을 나타내므로 타임아웃으로 인해 요청을 재전송하는 것을 피합니다.
- UX에 적용 가능한 경우 로딩 표시기 또는 진행 상황 정보를 표시합니다.
대부분의 현대 HTTP 클라이언트는 102를 정상적으로 처리하거나 무시합니다. 이는 트랜잭션을 완료하지 않기 때문입니다.
사용자 경험 및 성능에 대한 102 Processing의 영향
102가 조기 타임아웃을 방지하는 데 도움이 되지만, 복잡성을 더할 수 있습니다:
- 클라이언트가 이를 잘 처리하도록 설계되지 않은 경우 클라이언트-서버 상호 작용이 더 느리게 느껴질 수 있습니다.
- 서버는 너무 많은 중간 상태로 클라이언트를 범람시키지 않기 위해 102를 언제 보낼지 신중하게 결정해야 합니다.
- 연결 유지가 필수적인 롱 폴링 또는 스트리밍을 요구하는 API에서 유용합니다.
102 Processing의 이점
굳이 `102 Processing`을 사용할 이유가 있을까요?
- 조기 타임아웃 방지: 클라이언트 연결을 유지합니다.
- 신뢰성 향상: 클라이언트는 서버가 활발히 처리 중임을 압니다.
- 사용자 경험 향상: "조용한" 지연으로 인한 좌절을 피합니다.
- 오래 걸리는 작업을 원활하게 지원: 특히 엔터프라이즈급 API에서.
일반적인 문제 및 함정
유용하지만, 몇 가지 주의할 점이 있습니다:
- 널리 구현되지 않음: 많은 서버와 프레임워크가 기본적으로 이를 지원하지 않습니다.
- 클라이언트 호환성: 일부 HTTP 클라이언트는 1xx 코드를 무시합니다.
- 오버헤드: 너무 많은 102 응답을 보내면 불필요한 네트워크 트래픽이 추가될 수 있습니다.
- 보안 고려 사항: 응답이 위조되거나 오용되지 않도록 보장해야 합니다.
- 테스트 어려움: 102 응답이 포함된 요청을 테스트하려면 중간 응답 코드를 캡처하는 도구가 필요합니다.
- 과도한 사용은 클라이언트를 혼란시킬 수 있음: 과도한 정보 메시지는 불필요한 복잡성을 야기할 수 있습니다.
Apidog으로 API 테스트하기
102 Processing과 같은 상태 코드를 다룰 때, 제대로 테스트하는 것이 중요합니다. 그러나 102 Processing을 사용하는 API를 테스트하는 것은 비동기 및 다단계 응답 때문에 까다로울 수 있습니다.
바로 이 지점에서 Apidog이 진가를 발휘합니다:
- 102 응답을 트리거할 수 있는 요청 시뮬레이션.
- 정보성 상태를 포함한 전체 요청-응답 주기 캡처.
- 오래 걸리는 처리 단계의 올바른 처리를 주장하는 테스트 자동화.
- 지연 또는 실패가 발생하는 지점을 디버그하기 위한 상세 로그 제공.
- 팀과 테스트를 공유하여 모든 것을 일관되게 유지.
API 개발에 진지하다면, Apidog은 희귀한 상태 코드 디버깅을 손쉽게 만듭니다. Apidog을 무료로 다운로드하고 복잡한 102 Processing 워크플로를 처리하는 API를 포함하여 API 테스트를 마스터하세요.
개발자를 위한 모범 사례
102 Processing을 사용할 때의 몇 가지 팁입니다:
- **오래 걸리는 작업**에만 사용하십시오.
- 불필요하게 여러 102 응답을 스팸처럼 보내지 마십시오.
- 항상 **최종 응답**(예: `200` 또는 `201`)으로 이어지도록 하십시오.
- **Apidog**과 같은 도구로 철저히 테스트하십시오.
- API 문서에 그 사용법을 명확하게 문서화하십시오.
결론: 현대 세계의 틈새 도구
그렇다면, 상태 코드 102 Processing이란 무엇일까요?
간단히 말해, 서버가 보내는 신호로 다음과 같이 말합니다:
"요청을 받았습니다. 작업 중입니다. 아직 포기하지 마세요!"
이는 침묵이 클라이언트에게 실패로 가정하게 할 수 있는 오래 걸리는 요청에 특히 유용합니다. 다른 코드만큼 흔하지는 않지만, 적절한 시나리오에서는 강력한 도구입니다.
HTTP `102 Processing` 상태 코드는 웹 개발의 특정 시기에 WebDAV 프로토콜의 긴급한 문제를 해결하기 위해 설계된 흥미로운 유물입니다. 더 확장 가능한 비동기 패턴으로 대부분 대체되었지만, 여전히 HTTP 사양의 유효하고 때로는 유용한 부분으로 남아 있습니다.
102 Processing을 이해하는 것은 네트워크 프로그래밍의 과제와 API 설계의 진화에 대한 더 깊은 통찰력을 제공합니다. 이는 동기적 단순성과 비동기적 확장성 사이의 끊임없는 긴장을 강조합니다.
대부분의 현대 애플리케이션에서는 폴링 또는 웹훅을 사용하는 `202 Accepted` 패턴이 더 우월한 선택입니다. 하지만 `102`가 존재한다는 것을 아는 것은 정보에 입각한 아키텍처 결정을 내릴 수 있게 합니다. 그리고 `102`, `202` 또는 다른 어떤 상태 코드를 사용하든 오래 걸리는 API 동작을 테스트해야 할 때 Apidog과 같은 강력한 도구를 사용하면 요청이 아무리 오래 걸리더라도 원활하고 신뢰할 수 있는 사용자 경험을 보장하는 데 필요한 제어 및 가시성을 얻을 수 있으며, 요청을 시뮬레이션하고, 중간 응답을 확인하고, 전문가처럼 API를 디버그할 수 있습니다.
그냥 읽기만 하지 말고, 오늘 Apidog을 무료로 다운로드하여 직접 실험해 보세요.