401 에러(Unauthorized) 뜻과 원인, 해결 방법: 구글 401 오류까지

401 Unauthorized 오류란 무엇인가?

401 Unauthorized('인증되지 않음') 오류는 서버가 누구인지 증명하라고 요구했는데, 요청에 그 증명이 없었거나 함께 보낸 인증 정보가 거부되었다는 뜻입니다. 비밀번호를 입력하지 않았을 때, 비밀번호가 틀렸을 때, 토큰이 만료되었을 때, API 키가 빠졌을 때 모두 똑같이 401로 끝납니다.

HTTP 표준은 401을 "대상 리소스에 대한 유효한 인증 자격 증명이 없는" 요청으로 정의하며, 401을 보내는 서버는 어떤 로그인 방식을 받는지 알려 주는 WWW-Authenticate 헤더를 반드시(MUST) 포함해야 합니다(RFC 9110 §15.5.2).

쉽게 말해 서버가 들여보내기 전에 "누구세요?"라고 묻는 것입니다.

401 오류의 표시 형태

어떤 화면이 보이는지는 서버와 앱에 따라 다릅니다.

• 401 Unauthorized — 표준 상태 줄이며, 대부분의 앱이 쓰는 문구
• 401 Authorization Required — nginx에 내장된 401 페이지의 제목으로, 아래에 "nginx"(보통 버전 포함)가 표시됩니다(nginx 소스). 오래된 Apache 2.2 서버도 같은 문구를 씁니다
• Unauthorized · This server could not verify that you are authorized to access the document requested — Apache 기본 페이지
• 401 - Unauthorized: Access is denied due to invalid credentials — IIS. 자세한 오류 페이지(서버 자체에서만 표시)와 IIS 로그에는 원인이 401.1, 401.2, 401.3으로 나뉘어 나옵니다. 각각 로그온 실패, 서버 구성, 파일 권한 문제입니다
• 브라우저의 로그인 창 — 서버가 HTTP Basic 또는 Digest 인증을 요구할 때, 또는 (IIS와 회사 인트라넷에서) NTLM이나 Negotiate 인증을 요구할 때
• 페이지가 작동하지 않습니다 · HTTP ERROR 401 — 401 응답에 자체 페이지가 없을 때 한국어 Chrome이 보여 주는 화면(영어 화면은 "This page isn’t working")
• API의 JSON 응답 — 예: {"error":{"message":"Missing Authentication header","code":401}}

브라우저는 이런 로그인 방식에만 로그인 창을 띄웁니다. 토큰 기반 API("Bearer")는 로그인 창을 띄우지 않고, 401을 JSON으로 돌려주어 앱이 처리하게 합니다. 로그인 양식이 있는 웹사이트는 로그아웃 상태의 방문자에게 401 대신 보통 302 리다이렉트로 로그인 페이지를 보여 줍니다.

nginx에서 "401 Authorization Required"가 뜰 때

이 제목은 nginx에 내장된 401 페이지에서 나옵니다. auth_basic으로 보호된 location에 사용자 이름과 비밀번호 없이, 또는 틀린 값으로 요청하면 이 페이지가 뜹니다. 브라우저의 로그인 창에서 취소를 눌러도 이 페이지가 보입니다.

방문자라면 새로고침한 뒤 사이트 운영자에게 받은 사용자 이름과 비밀번호를 입력하세요. 이 정보는 사이트의 회원 계정과는 별개입니다. Basic 인증은 서버에 있는 비밀번호 파일로 확인하기 때문입니다.

사이트 운영자라면 보호를 거는 방법과 특정 경로만 공개로 두는 방법은 다음과 같습니다.

# Create the password file (htpasswd comes with apache2-utils or httpd-tools)
#   sudo htpasswd -c /etc/nginx/.htpasswd alice   # -c creates the file: leave it out when adding users

location /admin/ {
    auth_basic           "Admin area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

# Inside a protected server block, open one path to everyone
location /public/ {
    auth_basic off;
}

# Test, then reload
#   curl -I -u alice:PASSWORD https://example.com/admin/
#   sudo nginx -t && sudo systemctl reload nginx

비밀번호가 맞는데도 401이라면 그 사용자가 파일에 실제로 들어 있는지 확인하세요(htpasswd -c는 파일을 새로 만들어 기존 사용자를 지웁니다). 또 nginx 뒤의 앱도 Authorization 헤더를 쓰는지 확인하세요. nginx의 Basic 로그인과 앱의 Bearer 토큰은 같은 헤더를 쓰기 때문에, 앱이 nginx용 인증 정보를 받고 거부하게 됩니다.

401과 403의 차이점은?

401과 403은 자주 혼동됩니다. 짧게 말하면 401은 "당신이 누구인지 모릅니다", 403은 "들여보내지 않겠습니다"입니다. 403은 신원이 문제든 아니든 거절합니다.

실용적인 기준은 이렇습니다. 올바른 사용자 이름과 비밀번호(또는 API 키)를 보내면 해결되는 경우라면 서버는 401을 반환해야 합니다. 이미 인증된 사용자가 해당 리소스에 접근할 권한만 없는 경우라면 403 Forbidden을 반환해야 합니다.

401 오류의 일반적인 원인

방문자 쪽 원인부터 서버 쪽 원인까지 순서대로 정리했습니다.

• 잘못된 사용자 이름 또는 비밀번호 — 가장 기본적인 원인이며, 특히 비밀번호를 재설정한 직후에 흔합니다
• 인증 토큰 만료 — JWT 토큰, OAuth 액세스 토큰, 세션 쿠키 모두 만료 시간이 있습니다
• Authorization 헤더 누락 — 요청에 인증 정보가 전혀 없는 경우
• 유효하지 않은 API 키 — 키가 폐기·교체되었거나 잘못 복사된 경우
• 잘못된 인증 방식 — 서버는 Bearer 토큰을 기대하는데 Basic 인증을 보낸 경우(또는 그 반대)
• 시간 차이(클럭 스큐) — JWT를 검증하는 서버와 발급한 서버(내 컴퓨터가 JWT에 서명한다면 내 컴퓨터)의 시간이 서로 다른 경우. 허용 오차를 전혀 두지 않는 라이브러리가 많습니다
• CORS 프리플라이트 — 브라우저의 OPTIONS 확인 요청에는 인증 정보가 실리지 않으므로, 여기에도 인증을 요구하는 서버는 401로 답하고 실제 요청은 전송되지 않습니다
• 만료된 세션 — 서버가 이미 끝낸 세션의 쿠키를 브라우저가 계속 보내는 경우
• 중간에서 헤더가 사라짐 — Apache는 따로 설정하지 않으면 PHP-FPM과 CGI 스크립트에 Authorization을 넘기지 않고, CloudFront는 기본 설정에서 GET·HEAD 요청의 Authorization을 제거하며, 앱 앞에 둔 nginx Basic 인증은 이 헤더를 차지합니다
• 잠기거나 폐기된 인증 정보 — 로그인 실패가 너무 많으면 계정이 잠길 수 있습니다(이 경우 429 Too Many Requests로 답하는 API도 있습니다)

방문자를 위한 401 오류 해결 방법

웹사이트에 접속하다가 401 오류가 보인다면 거의 항상 로그인 정보와 관련된 문제입니다. 다음 단계를 순서대로 따라 해 보세요.

1. 로그인 인증 정보 확인하기

401 오류의 가장 흔한 원인은 단순히 잘못된 로그인 정보입니다. 사이트에 로그인 창이나 양식이 보이면 사용자 이름과 비밀번호를 다시 확인하세요.

흔한 실수는 Caps Lock이 켜져 있거나, 예전 비밀번호를 입력하거나(특히 최근에 재설정한 경우), 다른 계정으로 로그인하는 것입니다. 비밀번호 관리자를 쓴다면 자동 입력으로 오타를 막으세요.

2. 브라우저 캐시 및 쿠키 삭제하기

브라우저가 만료된 세션 쿠키를 보내고 있을 수 있습니다. 해당 사이트의 쿠키를 삭제하면 사이트가 새로 로그인하라고 요청합니다.

한국어 Chrome에서는 Ctrl+Shift+Delete(Mac은 Cmd+Shift+Delete)로 인터넷 사용 기록 삭제 창을 열고, 기간을 기본값인 지난 1시간에서 전체 기간으로 바꾼 뒤 쿠키 및 기타 사이트 데이터와 캐시된 이미지 및 파일을 선택해 데이터 삭제를 누르세요. 이렇게 하면 모든 사이트에서 로그아웃되므로, 한 사이트만 지우려면 주소창 왼쪽 아이콘(사이트 정보 보기) → 사이트 설정 → 데이터 삭제를 쓰세요. 아래는 영어 화면 기준 경로입니다.

Chrome, Edge, Firefox: Ctrl+Shift+Delete (Cmd+Shift+Delete on a Mac)
  → Time range: All time → Cookies and site data + Cached files → Delete / Clear
  (this signs you out of every site; the per-site option below doesn't)
Safari: Settings → Privacy → Manage Website Data → the site → Remove
One site in Chrome: the icon left of the address → Site settings → Delete data

삭제한 뒤에는 탭만 닫지 말고 브라우저를 완전히 종료했다가 다시 열어 페이지에 접속하세요. 새 로그인 창이 보여야 합니다.

3. 시크릿 모드 또는 프라이빗 모드로 시도하기

Chrome의 새 시크릿 창, Firefox의 사생활 보호 창, Safari의 개인정보 보호 브라우징 창에서 URL을 열어 보세요. 저장된 쿠키, 확장 프로그램, 저장된 로그인 정보 없이 접속합니다.

시크릿 창에서는 열리는데 평소 창에서만 안 된다면 저장된 쿠키나 인증을 방해하는 확장 프로그램이 원인입니다. 확장 프로그램을 하나씩 꺼 보며 원인을 찾으세요.

4. URL 확인하기

올바른 URL에 접속하고 있는지 확인하세요. 경로 자체가 잘못되었더라도 인증이 필요한 경로에는 401을 돌려주는 서버가 있습니다. 원래 들어가면 안 되는 제한 구역에 접근하고 있을 수도 있습니다.

다른 URL에 공개된 페이지가 있는지 확인하세요. 예를 들어 example.com/admin/은 401을 돌려주지만 example.com/은 누구나 볼 수 있을 수 있습니다.

사이트 자체가 열리지 않는 건지 헷갈린다면 사이트 다운 확인이 11곳에서 사이트를 열어 보므로 로그인 문제와 사이트 장애를 구분할 수 있습니다.

구글에서 "401. 오류가 발생했습니다"가 뜰 때

'구글 401 오류'를 검색하는 분이 많은데, 구글에서 보이는 401 화면은 문구에 따라 뜻과 해결 방법이 다릅니다. 먼저 화면에 적힌 문구를 아래 표에서 찾아 보세요.

검색창에 가장 많이 붙여 넣는 문구는 401. 오류가 발생했습니다. 요청 형식이 잘못되어 서버에서 요청을 처리할 수 없습니다. 다시 시도하지 마세요. 다른 원인은 확인할 수 없습니다.입니다. 구글 로고와 로봇 그림이 있는 이 화면은 구글 서버가 직접 보내는 기본 오류 페이지입니다(같은 형식의 404 페이지에는 '요청하신 URL을 서버에서 찾을 수 없습니다'라고 나옵니다). 문장은 요청 형식이 잘못되었다고 말하지만, 앞의 401은 서버가 요청과 함께 온 로그인 정보를 받아들이지 않았다는 HTTP 코드입니다. 구글은 이 화면에 더 자세한 원인을 적지 않으므로('다른 원인은 확인할 수 없습니다') 내 쪽 로그인 상태부터 확인해야 합니다.

이렇게 해 보세요: 화면에도 '다시 시도하지 마세요'라고 나오듯 같은 주소를 새로고침하면 같은 결과가 나옵니다. 드라이브나 지메일 같은 서비스의 첫 화면에서 다시 여세요. 그래도 같다면 구글 페이지 오른쪽 상단의 프로필 이미지(또는 이니셜) → 모든 계정에서 로그아웃을 누른 뒤 필요한 계정 하나로만 다시 로그인하세요. 구글 계정 고객센터에 따르면 두 계정 이상에 로그인한 상태에서는 어느 계정을 쓰려는 것인지 구글이 판단하지 못할 수 있습니다. 마지막으로 위 2번처럼 쿠키를 삭제하거나 3번처럼 시크릿 창에서 열어 보세요.

참고: 401 뒤에 invalid_client 같은 영어 코드가 붙은 화면은 구글의 오류 코드 안내대로 개발자가 앱을 구글에 제대로 등록하지 않은 경우이며, 서드 파티 개발자만 해결할 수 있습니다. 쿠키 삭제나 재로그인으로는 풀리지 않습니다. 개발자라면 Drive API 오류 안내처럼 Google API의 401은 액세스 토큰이 만료되었거나 유효하지 않다는 뜻입니다. 토큰 없이 호출하면 WWW-Authenticate: Bearer realm="https://accounts.google.com/" 헤더가 함께 오며, HTTP 헤더 검사로 이런 응답 헤더를 확인할 수 있습니다.

개발자를 위한 401 오류 해결 방법

API를 다루는 개발자에게 401은 대개 Authorization 헤더, 토큰 형식, 인증 정보의 수명 주기 문제입니다. 가장 흔한 해결 방법은 다음과 같습니다.

5. Authorization 헤더 확인하기

개발자가 가장 흔히 하는 실수는 Authorization 헤더의 형식 오류입니다. 서버가 WWW-Authenticate 헤더를 보내면 거기에 서버가 기대하는 인증 방식이 적혀 있습니다. 다만 JSON API 중에는(예: GitHub, OpenRouter) 이 헤더를 생략하고 응답 본문에서 문제를 설명하는 곳이 많습니다.

헤더가 요구되는 형식과 일치하는지 확인하세요. 가장 흔한 방식은 Bearer(토큰용)와 Basic(사용자 이름:비밀번호를 Base64로 인코딩)입니다.

# Bearer token authentication (most APIs)
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." https://api.example.com/data

# Basic authentication (username:password in Base64)
curl -u "username:password" https://api.example.com/data
# Equivalent to:
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

# Common mistakes that cause 401:
# Missing "Bearer " prefix:  Authorization: eyJhbGci...  ← WRONG
# Extra space:               Authorization: Bearer  eyJ... ← many servers reject it
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

그다음 401 응답의 WWW-Authenticate 헤더를 읽으세요. 서버가 기대하는 인증 방식이 적혀 있습니다. DNS Robot의 HTTP 헤더 검사로 전체 응답을 볼 수 있습니다.

6. API 키 유효성 확인하기

API 키는 키가 교체되거나 폐기되었을 때, 계정이 정지되거나 하위 요금제로 바뀌었을 때, 테스트 키를 운영 환경에 썼을 때 작동을 멈춥니다. (요청 한도를 넘으면 429가 오고, 해당 엔드포인트를 쓸 권한이 없는 키에는 보통 403이 옵니다.)

공급자 대시보드에서 키가 아직 활성 상태인지 확인한 뒤 직접 테스트해 보세요.

# Test a key: print only the status code (a real GET; some APIs reject HEAD)
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = the key works
# 401 = the key is missing, wrong, revoked or expired
# 403 = the key works but isn't allowed to use this endpoint

# Common slips:
# 1. A space or newline after the key in .env:   API_KEY="abc123 "
# 2. The test key in production, or the reverse
# 3. An empty variable, so the header is just "Authorization: Bearer"

7. 토큰 만료 및 갱신 처리하기

JWT 토큰과 OAuth 액세스 토큰은 수명이 정해져 있으며, 보통 15분에서 24시간입니다. 만료되면 새 토큰을 받을 때까지 모든 API 호출이 401을 반환합니다.

리프레시 토큰이 있다면(OAuth 2.0과 대부분의 JWT 구성) 새 액세스 토큰으로 교환하고, 없다면 다시 로그인하세요.

# Read a JWT's payload (tokens use base64url, so plain base64 -d often fails)
python3 -c 'import sys,base64,json; p=sys.argv[1].split(".")[1]; print(json.dumps(json.loads(base64.urlsafe_b64decode(p+"==")),indent=2))' "$TOKEN"
# "exp" is a Unix timestamp; compare it with: date +%s

# OAuth 2.0: get a new access token with the refresh token
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID"

8. CORS 프리플라이트 문제 해결하기

웹 페이지가 Authorization 헤더를 붙여 다른 도메인의 API를 호출하면, 브라우저는 먼저 프리플라이트 OPTIONS 요청을 보내는데 이 요청에는 인증 정보가 실리지 않습니다. 서버가 OPTIONS에도 인증을 요구하면 401로 답하고, 프리플라이트가 실패해 브라우저는 CORS 오류를 표시합니다. 실제 요청은 전송되지 않습니다.

해결 방법: CORS를 쓰는 엔드포인트에서는 OPTIONS 요청을 인증 없이 통과시키세요.

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin https://app.example.com;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "Authorization, Content-Type";
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    # CORS header on every other answer, the 401 included, or the browser reports a CORS error
    add_header Access-Control-Allow-Origin https://app.example.com always;

    # Normal auth for other methods
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

사이트 관리자를 위한 401 오류 해결 방법

방문자나 사용자가 401 오류를 알려 온다면 서버의 인증 구성에 문제가 있습니다. 다음 항목을 점검하세요.

9. 서버 인증 구성 검토하기

인증이 필요한 경로에만 인증이 켜져 있는지 확인하세요. 특정 경로만 로그인이 필요한데 디렉터리나 사이트 전체를 보호하는 실수가 흔합니다.

nginx에서는 auth_basic 지시어를, Apache에서는 AuthType과 Require를 확인하세요. Node.js/Express에서는 미들웨어 순서를 확인하세요. 공개 라우트보다 먼저 등록한 app.use(auth)는 공개 라우트까지 보호하므로, 공개 라우트를 먼저 등록하거나 인증을 보호할 라우터에만 붙이세요.

# Nginx — WRONG: protects everything, including public pages
server {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # All pages now require login — including your homepage!
}

# Nginx — CORRECT: only protect admin routes
server {
    location / {
        # Public — no auth required
    }
    location /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

10. .htaccess 인증 규칙 확인하기

Apache에서는 .htaccess 파일로 디렉터리에 Basic 또는 Digest 인증을 켤 수 있습니다. 공개 디렉터리의 .htaccess에 AuthType과 Require 지시어가 있으면 모든 방문자에게 401 로그인 창이 뜹니다.

해당 디렉터리와 모든 상위 디렉터리에 .htaccess 파일이 있는지 확인하세요. Apache는 경로에 있는 모든 .htaccess의 규칙을 적용합니다.

# Find all .htaccess files with auth rules
find /var/www/html -name '.htaccess' -exec grep -l 'AuthType\|AuthUserFile\|Require valid-user' {} \;

# Example .htaccess that causes 401 for everyone:
# AuthType Basic
# AuthName "Restricted Area"
# AuthUserFile /etc/apache2/.htpasswd
# Require valid-user

# Fix: remove auth lines from public directories,
# or move them to the specific /admin/.htaccess only

11. Authorization 헤더가 앱까지 전달되는지 확인하기

클라이언트는 올바른 인증 정보를 보내는데 앱이 그것을 받지 못하는 경우입니다. 헤더가 사라지는 곳은 다음과 같습니다.

nginx는 기본적으로 Authorization을 백엔드에 전달하므로 따로 설정을 추가할 필요가 없습니다. 다만 같은 location에서 auth_basic을 쓰면 nginx의 로그인이 이 헤더를 차지합니다(위 nginx 섹션 참고). Apache는 CGIPassAuth(Apache 2.4.13 이상)를 켜지 않으면 PHP-FPM과 CGI 스크립트에 Authorization을 숨깁니다. Apache 뒤에서 돌아가는 WordPress·Laravel API에서 401이 나는 대표적인 원인입니다.

# Apache 2.4.13+ (inside a <Directory> block, or .htaccess): pass Authorization to PHP-FPM and CGI
CGIPassAuth On

# Older Apache: copy it into an environment variable instead
SetEnvIf Authorization "(.+)" HTTP_AUTHORIZATION=$1

HTTP 헤더를 사용한 401 오류 디버깅

401을 가장 빨리 진단하는 방법은 응답을 읽는 것입니다. 서버가 WWW-Authenticate 헤더를 보낸다면 거기에 원하는 로그인 방식이 나오고, JSON API는 보통 본문에 오류 이유를 적습니다.

DNS Robot의 HTTP 헤더 검사를 쓰거나(리다이렉트를 거친 뒤에만 401이 나온다면 리다이렉트 확인으로 어느 단계에서 401이 오는지 볼 수 있습니다), 터미널에서 curl을 쓰세요.

# Print the response headers of a real GET
curl -sS -D - -o /dev/null https://api.example.com/protected-endpoint

# A 401 often carries one of:
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"

# It tells you:
# - the scheme (Bearer, Basic, Digest, Negotiate)
# - the realm (which area is protected)
# - for Bearer tokens, the error: invalid_request, invalid_token or insufficient_scope

WWW-Authenticate가 Bearer라면 토큰이, Basic이라면 사용자 이름과 비밀번호가 필요합니다. error="invalid_token"은 토큰이 만료되었거나, 폐기되었거나, 형식이 잘못되었거나, 그 밖의 이유로 유효하지 않다는 뜻입니다. 헤더가 아예 없다면 응답 본문을 읽으세요. 이유를 본문에 적는 API가 많습니다.

401 오류가 SEO에 영향을 미치는가?

공개 페이지가 401을 반환하면 구글 검색에서 빠집니다. 구글은 429를 제외한 모든 4xx 코드를 똑같이 처리합니다. 크롤러는 콘텐츠가 존재하지 않는다고 보고하고, 이미 색인된 URL은 색인에서 삭제됩니다(구글 크롤러 문서).

로그인이 필요해야 하는 페이지(관리자 패널, 대시보드, API)의 401은 정상이며, 구글은 이 때문에 사이트에 불이익을 주지 않습니다. 다만 Googlebot의 크롤링 속도를 늦추려고 401이나 403을 쓰지는 마세요. 구글은 이 코드들이 크롤링 속도에 영향을 주지 않는다고 밝힙니다.

문제는 공개되어야 할 페이지의 401입니다. 보통 사이트 전체에 인증을 걸었거나, CDN·프록시 규칙이 공개 경로에 인증을 요구할 때 생깁니다.

401 오류를 방지하는 방법

미리 막아 두면 나중에 디버깅할 일이 줄어듭니다. 애플리케이션과 웹사이트의 401 오류를 줄이려면 다음을 실천하세요.

• 토큰 자동 갱신 구현 — 리프레시 토큰으로 액세스 토큰이 만료되기 전에 새 토큰을 자동으로 받습니다
• 인증 범위를 정확히 설정 — 정말 인증이 필요한 경로만 보호하고 공개 페이지는 열어 둡니다
• 알기 쉬운 오류 메시지 — 상태 코드만 보내지 말고 401과 함께 도움이 되는 JSON 오류 본문을 반환합니다
• 인증 실패 모니터링 — 401 응답이 급증하면 알림이 오도록 설정합니다(인증 정보 문제나 공격의 신호일 수 있습니다)
• 서버 시계 동기화 — NTP로 모든 서버를 UTC 기준 몇 초 이내로 맞춰 JWT 시간 차이로 인한 거부를 막습니다
• HTTP 헤더 검사로 테스트 — 공개 페이지는 200을, 보호된 페이지는 의도대로 401을 반환하는지 정기적으로 확인합니다
• 인증 방식 문서화 — API 문서에 Authorization 헤더 형식을 명확히 적습니다
• CORS 프리플라이트 처리 — API 엔드포인트에서는 OPTIONS 요청을 항상 인증 없이 허용합니다