블로그를 운영하다 보면 아직 공개하기 어려운 페이지가 생깁니다. 새로운 기능을 테스트하거나, 특정 사람에게만 보여주고 싶은 프로토타입 같은 것들이죠. 검색 엔진에는 절대 노출되면 안 되고, URL을 알아도 아무나 접근하면 안 되는 그런 페이지들 말입니다.
저도 최근 비슷한 고민이 있었습니다. Google OAuth 인증이나 광고 API 연동 같은 프로토타입을 만들어야 했는데, 이걸 블로그의 어딘가에 두고 싶었습니다. 별도 서버를 띄우기엔 과하고, 그렇다고 로컬에서만 테스트하기엔 불편했습니다.
처음엔 복잡한 로그인 시스템을 구현해야 하나 고민했습니다. 세션 관리, 토큰 발급, 데이터베이스에 사용자 저장... 생각만 해도 일이 커지는 느낌이었습니다.
그러다 HTTP Basic Authentication을 떠올렸습니다. 브라우저에서 특정 페이지에 접근하면 팝업이 뜨면서 아이디와 비밀번호를 묻는, 그 오래된 방식 말입니다. nginx 설정에서 자주 봤던 것인데, 프레임워크 레벨에서도 충분히 구현할 수 있겠다는 생각이 들었습니다.
HTTP Basic Authentication의 동작 방식은 생각보다 단순합니다.
클라이언트가 보호된 경로에 접근합니다
서버가 401 Unauthorized와 함께 WWW-Authenticate: Basic 헤더를 응답합니다
브라우저가 자동으로 인증 팝업을 띄웁니다
사용자가 입력한 정보를 username:password 형태로 Base64 인코딩해서 전송합니다
서버가 이를 검증하고 통과시키거나 다시 401을 반환합니다
브라우저가 인증 팝업을 알아서 띄워준다는 점이 핵심입니다. 별도의 로그인 페이지를 만들 필요가 없습니다.
Next.js에서는 미들웨어를 통해 이를 구현할 수 있습니다. 프로젝트 루트의 middleware.ts 파일에서 특정 경로에 대한 요청을 가로채고, 인증 여부를 확인하면 됩니다.
// 인증 헤더 검증
const authHeader = request.headers.get('authorization');
if (!authHeader?.startsWith('Basic ')) {
return new NextResponse('Authentication required', {
status: 401,
headers: {
'WWW-Authenticate': 'Basic realm="Protected Area"',
},
});
}
// Base64 디코딩 후 검증
const credentials = atob(authHeader.split(' ')[1]);
const [username, password] = credentials.split(':');
사용자 정보는 환경변수로 관리하면 됩니다. DEV_USERS=admin:password123,guest:guest456 같은 형태로 저장하고, 미들웨어에서 파싱해서 사용합니다.
단순히 인증만 하는 것에서 한 발 더 나아가, 사용자별로 다른 컨텐츠를 보여주고 싶었습니다. 예를 들어 관리자는 모든 프로토타입을 볼 수 있고, 특정 사용자는 지정된 프로토타입만 볼 수 있도록 말입니다.
이를 위해 인증이 성공하면 사용자 이름을 쿠키에 저장하도록 했습니다. 그러면 페이지에서 쿠키를 읽어 현재 사용자가 누구인지 알 수 있고, 그에 따라 보여줄 항목을 필터링할 수 있습니다.
// 인증 성공 시 쿠키 설정
response.cookies.set('dev-user', username, {
httpOnly: true,
secure: process.env.NODE_ENV === 'production',
sameSite: 'strict',
path: '/dev',
});
HTTP Basic Authentication은 편리하지만 몇 가지 주의할 점이 있습니다.
HTTPS 필수: Base64는 인코딩이지 암호화가 아닙니다. HTTP 환경에서는 네트워크를 감청하면 비밀번호가 그대로 노출됩니다. 반드시 HTTPS 환경에서 사용해야 합니다.
브라우저 캐싱: 한 번 인증하면 브라우저가 인증 정보를 캐시합니다. 로그아웃 기능을 구현하기가 까다롭습니다. 브라우저를 완전히 닫거나, 401 응답을 의도적으로 유발해야 합니다.
용도 제한: 프로토타입 보호나 간단한 접근 제한에는 적합하지만, 실제 서비스의 사용자 인증에는 적합하지 않습니다. 세션 관리, 비밀번호 변경, 권한 체계 같은 기능이 필요하다면 제대로 된 인증 시스템을 구축해야 합니다.
HTTP Basic Auth만으로도 접근은 막을 수 있지만, 완전한 보호를 위해서는 검색 엔진 차단도 함께 적용하는 것이 좋습니다.
robots.txt에서 해당 경로를 Disallow 처리
페이지의 <meta> 태그에 noindex, nofollow 설정
사이트맵에서 해당 페이지 제외
이렇게 3중으로 보호하면 검색 엔진에 노출될 걱정 없이 프로토타입을 운영할 수 있습니다.
처음에는 복잡하게 생각했던 문제가, 오래된 웹 표준 하나로 깔끔하게 해결되었습니다. 새로운 기술이 항상 정답은 아니라는 것을 다시 한번 느꼈습니다. HTTP Basic Authentication은 1990년대에 정의된 RFC 7617 표준인데, 2020년대의 모던 프레임워크에서도 여전히 유용하게 쓰이고 있습니다.
다만 이 방식은 어디까지나 "간단한 보호"를 위한 것입니다. 민감한 데이터를 다루거나, 다수의 사용자를 관리해야 한다면 OAuth나 세션 기반 인증 같은 더 강력한 방식을 고려해야 합니다. 도구의 한계를 알고 적절한 상황에 사용하는 것이 중요하겠습니다.