브라우저 암호화, 비밀번호 설정은 진짜 잠금이 아니었다

👥 이런 분께 추천

• 정적 사이트(Astro, Next.js, Hugo 등)에 비밀번호 잠금을 걸어둔 분

• 브라우저에서 비밀번호를 확인하는 방식이 얼마나 강한지 궁금한 분

• “잠긴 것처럼 보이는데 진짜 잠긴 걸까?”를 확인하는 법을 배우고 싶은 분

• 개인 블로그나 노트 일부만 진짜로 가리고 싶은 분

📝 한줄 요약

어제 내 학습일지에 걸어둔 비밀번호 잠금이 실은 커튼이었다는 걸 view-source로 확인하고, 진짜 잠금을 만드는 3가지 방법을 정리했습니다.

Before: 화면에 비밀번호 창이 뜨니까 “잠긴 것”으로 안심
After: 원본 HTML에 내용이 다 실려있다는 걸 확인, 진짜 잠금 3가지 방법 파악

🙋 내 스펙 & 환경

진행 방법

1. 왜 확인하게 되었나

어제 학습일지에 비밀번호 잠금을 걸고 뿌듯했습니다. 화면에 “비밀번호를 입력하세요”가 뜨고, 아무 입력 없이는 내용이 안 보였으니까요.

그런데 모리(내가 쓰는 AI 어시스턴트)가 사례글을 정리하다가 이런 말을 했습니다.

“마우스 우클릭 후 페이지 소스 보기만 하면 그냥 보입니다.”

이 말이 걸렸습니다. 진짜 그런지 확인해보고 싶었습니다.

2. 첫 번째 확인: 비밀번호가 소스에 보이나

내 사이트의 학습일지 목록 페이지(/journal)로 가서 우클릭 후 페이지 소스 보기를 눌렀습니다. 그리고 Ctrl+F로 내 비밀번호를 검색했습니다.

ALT

한국사이트 스크린샷

결과: 안 보였습니다.

대신 이런 긴 글자가 있었습니다.

const m = "ea279eca5412c45d2aea499fa21ffd";

이건 비밀번호 지문(SHA-256 해시) 입니다. 원본 비밀번호가 아닙니다. 어제 코드에 비밀번호를 그대로 적지 말라는 조언을 들어서, 지문만 저장해두는 방식으로 이미 바꿔뒀던 게 다행이었습니다.

배운 것: 지문(해시)은 한쪽 방향 함수입니다. 비밀번호로 지문을 만들 순 있지만, 지문으로 비밀번호를 되돌리기는 매우 어렵습니다. 브라우저에 지문만 두면, 소스를 봐도 원본 비밀번호는 못 알아냅니다.

3. 두 번째 확인: 세부 페이지에 직접 들어가면?

목록 페이지에서만 잠금이 걸린 게 아니라, 세부 페이지 URL을 직접 입력해도 잠금이 뜨게 해뒀습니다. 이것도 진짜인지 확인했습니다.

https://내사이트/journal/ertime-questions
복사

이 URL을 새 시크릿 창(비밀번호 세션 없음)에서 열었더니, 예상대로 비밀번호 입력창이 떴습니다.

“이거 봐, 잠긴 거 맞잖아?”라고 모리에게 물었습니다.

4. 결정적 확인: 서버가 실제로 뭘 보내는지

그랬더니 잠금을 하려던 페이지 URL을 직접 들어가서 소스 보기를 해보라고 했습니다.

curl https://내사이트/journal/-questions

보이는 화면은 이렇게 비밀번호 필요라고 나오지만,

ALT

한국어 텍스트가 있는 페이지

실제 소스보기를 눌러보니..

내 학습일지 내용이 그대로 원본 HTML에 다 들어있었습니다.

브라우저에서는 비밀번호 창만 보였는데, 간단하게 내용을 볼 수 있는 것이었습니다.

ALT

한국사이트 스크린샷

5. 왜 이런 일이 벌어졌나: 코드를 열어봤다

세부 페이지 코드를 열어봤습니다.

<div id="contentWrapper" style="display: none;">
  <Content />
</div>

display: none. 이게 원인이었습니다.

display: none은 화면에 표시하지 말라는 CSS 명령입니다. 파일에서 지우는 게 아닙니다.

브라우저는 내용을 다 받아놓고, 그 위에 “이건 안 보이는 걸로 해줘”라는 표시만 붙입니다.

그 위에 있는 자바스크립트가 인증되면 display: block으로 바꿔서 화면에 나타나게 하고, 인증이 없으면 그대로 숨겨둡니다. 하지만 view-source나 curl로 보면 이 CSS는 무시되고 파일 그대로가 보입니다.

배운 것: 안 보이는 것과 없는 것은 다릅니다. 커튼이 쳐져 있어도 방 안에 물건은 있습니다.

6. 그럼 진짜 잠금은 어떻게 만드나

정적 사이트(내 사이트처럼 Vercel에 올리는 방식)에서 진짜 잠금은 3가지 방법이 있습니다.

방법 1: 사이트에서 아예 뺀다

• 학습일지 파일들을 Private GitHub / Notion / Obsidian으로 이동

• URL 자체가 생기지 않으니 100% 안전

• 비용: 무료

• 단점: 사이트에서는 못 봄

방법 2: Vercel Password Protection 기능 켠다

• Vercel 대시보드에서 클릭 몇 번으로 설정

• 서버가 비밀번호를 확인, 인증되기 전엔 브라우저에 파일을 아예 안 보냄

• 비용: Pro 플랜 필요 (월 20달러)

• 단점: 유료

방법 3: staticrypt로 파일 자체를 암호화한다

• 배포할 때 학습일지 HTML 파일 안 내용을 비밀번호로 뒤섞음

• view-source로 봐도 뒤섞인 글자만 보임

• 비용: 무료

• 단점: 초기 설정 복잡, 배포 과정에 단계 추가

셋을 나란히 비교했습니다.

7. 결정하기

지금 상황(개인 학습기록, 무료 유지 원함, 비개발자)이면 방법 1이 제일 깔끔합니다.

하지만 사이트에서 학습일지도 같이 보고 싶은 마음도 있어서, 시간이 될 때 3번의 방법을 다시 시도해보려고 합니다.

당장은 이 학습일지 페이지에 진짜 민감한 정보(비밀번호, 계좌번호, 고객 정보 등)를 절대 넣지 않는 것으로 임시 방어선을 세웠습니다.

🛠 사용한 도구

배운 점

💡 핵심 교훈

1. 화면에 잠긴 것처럼 보인다고 잠긴 게 아닙니다

CSS의 display: none은 화면 표시 여부만 정합니다. 파일 자체는 브라우저에 그대로 전달되어 있습니다. 잠금 여부를 확인하려면 view-source나 curl로 실제 서버 응답을 직접 봐야 합니다.

2. 클라이언트 잠금은 커튼, 서버 잠금은 문

브라우저(클라이언트) 쪽에서 하는 잠금은 파일이 이미 도착한 뒤에 가리는 것입니다. 진짜 잠금은 파일이 도착하기 전에 서버 쪽에서 확인해야 합니다. 정적 사이트는 서버가 없어서 원래 커튼밖에 못 칩니다.

3. 지문(해시)은 비밀번호를 감춰줍니다

비밀번호를 코드에 그대로 적으면 소스 보기로 바로 노출됩니다. 대신 지문(SHA-256 해시)만 두면, 원본 비밀번호를 되돌리기는 어렵습니다. 이 부분은 어제 미리 지켜뒀던 게 다행이었습니다.

4. 설정한 대로 됐는지 눈으로만 판단하면 안 됩니다

어제 화면에 비밀번호 창이 뜨는 걸 보고 “됐다”고 뿌듯해했습니다. 하지만 view-source로 확인해보니 반쪽이었습니다. 보안 관련해서는 실제로 뭐가 오가는지를 직접 확인해야 합니다.

5. 정적 사이트의 진짜 잠금은 3가지 방향뿐입니다

• 파일을 사이트 밖으로 (URL 자체가 없음)

• 서버 쪽 잠금 (Vercel Pro 등)

• 파일 자체 암호화 (staticrypt 등)

브라우저 안에서 이걸 진짜 잠금으로 만들 방법은 없습니다.

솔직한 소감

살짝 무안했습니다. 어제 “학습일지 보안 강화 완료!”라고 자랑스러워했는데, 오늘 그게 반쪽짜리였다는 걸 알았으니까요.

하지만 지금 알게 된 게 다행이었습니다. 만약 정말 민감한 정보를 이 방식으로 가려두고 안심하고 있었다면 큰일 났을 겁니다.

역시 보안이라는 게 만만하지 않았네요.

“보안”이라는 게 화면이 아니라 실제로 뭐가 오가느냐로 판단해야 한다는 걸 몸으로 배웠습니다. 앞으로 다른 웹 서비스를 볼 때도, 화면에 잠금 아이콘이 있다고 그냥 믿지 않고 한 번 view-source로 확인해보고 싶어졌습니다.

적용할 점

🎯 결과