브라우저 개발자 도구에서 Sources 패널을 열어보면 원본 TypeScript 파일이 깔끔하게 표시되곤 합니다. 분명 브라우저가 실행하는 건 번들링되고 압축된 JavaScript일 텐데, 어떻게 원본 코드가 나타나는 걸까요? 바로 소스맵(source map) 덕분이에요. 소스맵은 웹 개발에서 빠질 수 없는 디버깅 도구지만 그 내부를 들여다볼 일은 좀처럼 없는데요. 이 글에서는 소스맵의 JSON 구조와 VLQ 인코딩 원리를 깊이 살펴보고 주요 빌드 도구별 설정 방법도 정리해보겠습니다. 나아가 프로덕션 환경에서 소스맵이 뜻하지 않게
대칭키 암호화는 빠르고 단순합니다. 하지만 한 가지 풀기 어려운 문제를 안고 있는데요. "비밀 키를 어떻게 양쪽이 안전하게 처음부터 나눠 가질 것인가"입니다. 공격자가 통신을 모두 보고 있는 상태에서 비밀 키를 그대로 보낼 수는 없는데, 그렇다고 매번 사람이 직접 만나서 키를 교환할 수도 없는 노릇이죠. 이 닭과 달걀 같은 문제를 풀기 위해 등장한 것이 비대칭키 암호화입니다. 한 사람이 한 쌍의 키를 갖고, 한쪽은 모두에게 공개하고 다른 한쪽은 자기만 가진다는 살짝 마법 같은 발상이에요. 이번 글에서는 비대칭키가 어떻게 동작하는지,
암호화라고 하면 가장 먼저 떠오르는 모습이 자물쇠와 열쇠입니다. 열쇠로 자물쇠를 잠그고, 같은 열쇠로 다시 열고. 이 직관 그대로 동작하는 방식이 바로 대칭키 암호화입니다. 같은 비밀 키 하나로 평문을 암호문으로 바꾸고, 같은 키로 다시 평문으로 되돌리는 약속이죠. 이번 글에서는 대칭키 암호화가 정확히 어떤 약속을 지키는지, AES와 GCM 같은 표준 알고리즘이 어떻게 동작하는지, 그리고 IV나 키 관리 같은 운영 포인트가 무엇인지를 풀어보겠습니다. 대칭키가 지키는 약속 대칭키 암호화는 두 가지 일을 약속합니다. 첫째는 비밀 키를
비밀번호를 다루거나, 파일을 다운로드한 뒤 무결성을 검사하거나, JWT 서명을 살펴볼 때 어김없이 등장하는 친구가 있습니다. 바로 해시 함수입니다. SHA-256이나 bcrypt 같은 이름은 익숙한데, 막상 "해시는 정확히 무엇이고 어디까지 보장하나요"라고 물으면 답이 잘 안 나오는 경우가 많죠. 이번 글에서는 해시 함수가 어떤 약속을 지키는지, 흔히 쓰이는 알고리즘들이 어떻게 다른지, 그리고 실무에서 자주 만나는 쓰임새를 한 번에 정리해 보겠습니다. 해시 함수가 지키는 약속 해시 함수는 임의의 길이를 가진 데이터를 입력으로 받아,
웹 개발을 하다 보면 브라우저 개발자 도구에서 HTTP 요청 헤더를 뜯어볼 일이 종종 있잖아요? 그때 Host, Origin, Referer... 이 세 녀석이 나란히 있는 걸 보면 "이거 다 비슷한 거 아닌가?" 싶을 때가 있는데요. 헤더 자체가 처음이라면 HTTP 메시지가 어떻게 생겼는지부터 보고 오시면 흐름이 더 잘 잡힙니다. 셋 다 URL이나 도메인 정보를 담고 있으니까 대충 같은 역할처럼 보이거든요. 그런데 막상 CORS 문제를 디버깅하거나 보안 설정을 건드려야 할 때 이 헤더들의 차이를 정확히 모르면 삽질을 피할 수가 없
브라우저 주소창에 작은 자물쇠 아이콘이 켜져 있으면 우리는 별다른 의심 없이 정보를 입력합니다. 비밀번호를 치고, 카드 번호를 넣고, 메시지를 보내는데요. 이 자물쇠 한 칸이 사실은 HTTP 위에 한 겹의 보호막을 덧씌운 결과인 셈입니다. HTTPS는 이름에서도 짐작되듯 HTTP에 보안(Secure)을 보탠 형태입니다. 정확히 말하면 HTTP를 TLS라는 암호 통신 위에서 흘려보내는 구조인데요. 이번 글에서는 평문 HTTP가 왜 위험한지, TLS가 그 위에 무엇을 더하는지, 그리고 우리가 평소에 보는 인증서와 자물쇠가 어떻게 신뢰를