[실전 서버리스 18] SSR 상태 코드의 기술, 503·404·410을 정확히

앞서 SEO 시리즈에서 상태 코드를 여러 번 다뤘는데, 서버리스에서 서버 사이드 렌더링을 하며 이 상태 코드를 정확히 다루는 건 별도의 기술이다. 언제 503을, 언제 404를, 언제 410을 줘야 하는지가 헷갈리기 쉽고, 잘못 주면 검색 색인이 무너진다. 이번 편은 서버리스 SSR에서 상태 코드를 정확히 다루는 실전을 정리한다.

이건 서버리스 구축과 SEO가 만나는 지점이다. 워커가 페이지를 렌더할 때 어떤 상태 코드를 내보내느냐가 검색엔진의 신뢰를 좌우한다.

1. 왜 상태 코드가 중요한가

서버 사이드 렌더링에서 워커는 요청을 받아 페이지를 만들어 응답한다. 이때 응답에는 상태 코드가 붙는다. 정상이면 200, 없으면 404 같은 식이다. 이 상태 코드는 사람에겐 잘 안 보이지만 검색엔진에겐 핵심 신호다. 앞서 SEO 시리즈에서 다룬 것처럼, 상태 코드 하나가 색인의 운명을 가른다.

문제는 서버리스 SSR에서 상태 코드를 정확히 통제하기가 생각보다 까다롭다는 것이다. 워커가 페이지를 만드는 과정에서 여러 상황이 생기는데, 각 상황에 맞는 상태 코드를 줘야 한다. 데이터를 못 찾았을 때, 일시적 오류가 났을 때, 영구히 삭제된 걸 요청받았을 때가 다 다르다.

이걸 뭉뚱그려 처리하면 사고가 난다. 일시적 오류인데 없다고 응답하거나, 없는 걸 정상이라고 응답하면 검색엔진이 혼란스러워한다. 그래서 각 상황을 구분해 정확한 상태 코드를 내보내는 게 서버리스 SSR의 중요한 기술이다.

상태 코드가 서버리스 SSR에서 특히 까다로운 건 워커가 페이지를 만드는 과정에 여러 상황이 겹치기 때문이다. 데이터를 못 찾았을 때, 일시 오류일 때, 영구 삭제일 때가 다 다른데 이걸 뭉뚱그리면 사고가 난다. 각 상황을 구분해 정확한 코드를 내보내는 게 서버리스 SSR의 중요한 기술이다.

한 가지 더, 상태 코드는 사람 눈엔 안 보이지만 검색엔진에겐 전부다. 화면에 뭐가 보이든, 서버가 헤더로 돌려주는 세 자리 숫자가 검색엔진의 판단을 결정한다. 그래서 서버리스 SSR에서 페이지를 만들 때, 화면 못지않게 이 상태 코드를 정확히 통제하는 데 신경 써야 한다. 보이지 않는 신호가 색인을 좌우한다.

2. 자산 로딩 실패는 503

가장 조심할 게 자산 로딩 실패다. 페이지를 렌더하려면 워커가 여러 자원, 예를 들어 데이터나 템플릿 자산을 가져와야 하는데, 이걸 일시적으로 못 가져올 때가 있다. 이때 절대 404를 주면 안 된다. 자산을 못 가져온 건 페이지가 없는 게 아니라 일시적 문제이기 때문이다.

이 경우 올바른 응답은 503이다. 503은 지금 일시적으로 서비스가 어려우니 나중에 다시 오라는 뜻이다. 여기에 언제 다시 오라는 정보를 함께 주면 더 좋다. 검색엔진은 503을 받으면 일시적 문제로 이해하고, 기존에 잘 색인해둔 걸 유지한 채 나중에 다시 온다.

만약 이 상황에 404를 주면 재앙이다. 검색엔진이 이 페이지가 영구히 없어졌다고 판단해서, 잘 색인돼 있던 걸 색인에서 빼버린다. 일시적 자산 문제가 영구적 색인 손실로 번지는 것이다. 그래서 자산 실패에는 반드시 503을 준다. 이건 앞서 SEO 시리즈에서도 강조한 핵심 규칙이다.

자산 로딩 실패에 503을 주는 게 가장 조심할 지점이다. 페이지는 있는데 렌더에 필요한 자산을 일시적으로 못 가져온 것이라, 여기에 404를 주면 검색엔진이 페이지가 영구히 없어졌다고 오해해 색인을 뺀다. 일시적 문제엔 503으로 나중에 다시 오라고 알려야, 기존 색인이 유지된다. 이 구분이 색인 방어의 핵심이다.

3. 글이 없으면 404

반면 진짜로 없는 걸 요청받으면 404가 맞다. 존재하지 않는 글 주소로 요청이 오면, 그건 없는 게 맞으니 404로 없다고 정직하게 답한다. 자산 실패의 503과 헷갈리면 안 된다. 자산 실패는 페이지는 있는데 못 만드는 것이고, 404는 페이지 자체가 없는 것이다.

이 구분이 서버리스 SSR에서 특히 중요하다. 워커 코드 안에서 데이터베이스를 조회했는데 글이 없으면 404, 조회 자체가 실패하거나 자산을 못 가져오면 503. 같은 못 만듦이라도 원인에 따라 상태 코드가 갈린다. 이 원인을 정확히 판별해 알맞은 코드를 내보내야 한다.

404를 줄 때도 그냥 빈 응답을 주면 안 된다. 앞서 SEO 시리즈에서 다룬 것처럼, 상태 코드는 404로 정확히 주되 사람이 볼 화면은 없음을 알리는 안내와 돌아갈 링크를 함께 준다. 봇에겐 정확한 상태 코드를, 사람에겐 친절한 화면을 주는 것이다. 상태 코드와 화면은 별개로 다룬다.

없는 글에 404를 주되 자산 실패의 503과 헷갈리면 안 된다. 자산 실패는 페이지는 있는데 못 만드는 것이고, 404는 페이지 자체가 없는 것이다. 같은 못 만듦이라도 원인이 다르다. 데이터베이스 조회 결과 글이 없으면 404, 조회나 자산 로딩이 실패하면 503. 원인을 정확히 판별해 알맞은 코드를 낸다.

또 하나, 상태 코드 처리를 테스트로 검증하는 게 좋다. 없는 글, 삭제된 글, 정상 글을 각각 요청해 기대한 상태 코드가 나오는지 확인하는 것이다. 코드로는 맞게 짰다고 생각해도 실제로는 다른 코드가 나가는 경우가 있다. 그래서 각 경우를 실제로 요청해 상태 코드를 확인하는 검증을 배포 전에 거치는 게 안전하다.

4. 영구 삭제는 410

세 번째 경우가 영구 삭제다. 글이 그냥 없는 게 아니라 확실히 영구적으로 삭제된 거라면 410이 더 낫다. 앞서 SEO 시리즈에서 다뤘듯, 410은 영구히 사라졌다는 명시적 신호라 검색엔진이 더 빨리 색인에서 제거한다. 404보다 확실한 폐기 신호다.

서버리스 SSR에서 이걸 구현하려면, 삭제된 글을 어떻게 표시할지 정해야 한다. 완전히 지워 흔적이 없으면 404가 되고, 삭제됐다는 표시를 남겨두면 410으로 응답할 수 있다. 어느 쪽을 택할지는 정책의 문제다. 나는 확실히 폐기한 것과 그냥 없는 것을 구분해 다뤘다.

그리고 빈 200 응답, 즉 소프트 404는 절대 피한다. 없는 페이지인데 상태 코드는 200을 주면서 빈 내용을 보여주는 것이다. 이건 검색엔진에게 가장 나쁜 신호 중 하나다. 서버리스 SSR에서 데이터가 없을 때 무심코 200으로 빈 페이지를 렌더하지 않게, 상태 코드를 명확히 통제해야 한다.

영구 삭제에 410을 주는 것도 알아두면 좋다. 그냥 없는 것과 확실히 폐기한 것을 구분해, 폐기한 건 410으로 명시하면 검색엔진이 더 빨리 색인에서 뺀다. 그리고 빈 200, 즉 소프트 404는 절대 피한다. 없는 페이지인데 200으로 빈 내용을 주면 검색엔진에게 가장 나쁜 신호가 된다.

5. 상태 코드를 설계로 다룬다

이 상태 코드들을 정확히 다루려면 즉흥적으로 하면 안 되고 설계로 다뤄야 한다. 워커 코드 안에서 각 상황을 명확히 분기해, 자산 실패는 503, 없는 글은 404, 삭제된 글은 410, 정상은 200을 내보내게 구조를 짠다. 이 분기를 명확히 해두면 상태 코드 사고가 안 난다.

특히 새로운 SSR 경로를 추가할 때마다 이 상태 코드 처리를 빠뜨리지 않는 게 중요하다. 새 페이지를 만들면서 상태 코드 처리를 대충 하면, 거기서 소프트 404나 잘못된 404가 생긴다. 그래서 SSR 경로를 만들 때 상태 코드 처리를 필수 체크리스트로 두는 게 좋다. 이건 앞서 SEO 시리즈에서 강조한 원칙이기도 하다.

정리하면 서버리스 SSR에서 상태 코드는 자산 실패면 503, 없는 글이면 404, 영구 삭제면 410, 정상이면 200으로 정확히 구분해야 하고, 빈 200은 피하며, 이걸 즉흥이 아니라 설계로 다뤄야 한다. 다음 편에서는 이 상태 코드와 함께 성능의 핵심인 캐시 계층을 서버리스 관점에서 더 깊이 다룬다.

상태 코드를 설계로 다뤄야 한다는 게 이 편의 결론이다. 즉흥적으로 하지 말고, 각 상황을 명확히 분기해 자산 실패는 503, 없는 글은 404, 삭제는 410, 정상은 200을 내보내게 구조를 짠다. 새 SSR 경로를 만들 때마다 이 처리를 필수 체크리스트로 두면 상태 코드 사고를 예방할 수 있다.

덧붙이면, 상태 코드를 정확히 다루는 이 기술이 서버리스 구축과 SEO를 잇는 다리다. 아무리 사이트를 잘 만들어도 상태 코드가 어긋나면 검색 색인이 무너진다. 그래서 서버리스로 SSR을 구현할 때, 이 상태 코드 처리를 SEO 관점에서 함께 챙겨야 한다. 두 시리즈의 지식이 여기서 만나 하나가 되는 셈이다.

다음 편에서는 이 상태 코드와 함께 성능의 핵심인 캐시 계층을, 서버리스 관점에서 더 깊이 다룬다. 엣지 캐시와 여러 캐시 층을 어떻게 설계하는지를 정리한다.