온라인 개인정보 보호, 개발자가 먼저 점검할 계정·코드·브라우저

게시 2026.07.18 · 약 5분 분량

온라인에서 개인정보를 지킬 때 개발자가 가장 먼저 챙길 세 가지는 사이트마다 다른 비밀번호를 관리자로 관리하는 것, 2단계 인증이나 패스키로 계정 탈취를 막는 것, 그리고 코드와 저장소에 비밀키·개인정보를 흘리지 않는 것이다. 2026년 7월 기준 Bitwarden 같은 비밀번호 관리자는 무료로 쓸 수 있고, 지금 쓰는 비밀번호의 유출 여부는 Have I Been Pwned에서 바로 확인할 수 있다. 이 글은 소비자용 일반 수칙이 아니라 개발자가 자기 계정과 자기가 만든 서비스에서 챙길 실무를 다룬다. 계정 보안, 코드 저장소, 브라우저 추적, 통신 암호화 순으로 짚는다.

비밀번호는 어떻게 관리해야 하나

사이트마다 다른 무작위 비밀번호를 만들어 비밀번호 관리자에 맡기는 것이 출발점이다. 비밀번호 관리자는 사이트별 비밀번호를 암호화해 저장하고 로그인 창에 자동으로 채워 주는 프로그램이다. 비밀번호 하나를 여러 사이트에 돌려쓰면 한 곳이 뚫릴 때 나머지가 같이 털리는데, 관리자를 쓰면 사람은 마스터 비밀번호 하나만 외우면 된다.

Bitwarden 무료 플랜은 저장할 비밀번호 개수와 기기 수에 제한이 없고, 서버도 내용을 못 읽는 제로 지식 암호화를 쓴다. 다만 무료와 유료의 기능 경계는 시기에 따라 바뀌므로 Bitwarden 공식 사이트의 가격 페이지에서 최신 기준을 확인하는 편이 정확하다.

지금 쓰는 비밀번호가 이미 유출됐는지는 Have I Been Pwned에서 확인한다. 유출된 계정 정보를 모아 검색해 주는 서비스다. Have I Been Pwned의 Pwned Passwords API 문서에 따르면 비밀번호를 로컬에서 SHA-1로 해시한 뒤 그 해시의 앞 5자리만 서버로 보내고, 서버가 돌려준 후보 목록과 나머지 해시를 브라우저에서 대조한다. 비밀번호 원문이나 전체 해시가 서버로 넘어가지 않는 k-익명성 방식이며, 이 API에는 요청 횟수 제한이 없다.

2단계 인증과 패스키로 로그인 지키기

비밀번호가 새더라도 계정을 지키려면 2단계 인증을 켜고, 지원하는 서비스는 패스키로 옮기는 편이 안전하다. 2단계 인증은 비밀번호에 더해 일회용 코드나 기기 인증을 한 번 더 요구하는 방식이다.

코드 방식의 표준은 TOTP다. IETF의 RFC 6238 표준에 따르면 TOTP는 서비스와 기기가 나눠 가진 비밀값과 현재 시각을 조합해 코드를 만들고, 기본 주기는 30초다. Google Authenticator나 Aegis 같은 인증 앱이 이 표준으로 코드를 생성한다. 문자(SMS)로 받는 코드보다 인증 앱을 권하는 이유는, 문자는 유심 탈취나 중간 가로채기에 노출되지만 인증 앱은 코드를 기기 안에서 오프라인으로 만들기 때문이다.

패스키는 여기서 한 단계 더 나간다. 패스키는 W3C의 WebAuthn 표준과 FIDO2를 기반으로 하며, 로그인 자격이 접속한 사이트 주소에 묶인다. 그래서 진짜 사이트를 흉내 낸 피싱 페이지에서는 아예 동작하지 않는다. Bitwarden을 비롯한 비밀번호 관리자가 패스키 저장을 지원한다.

코드와 저장소에 개인정보를 흘리지 않으려면

개발자에게 가장 흔한 유출 경로는 소스에 박아 둔 API 키와 저장소에 실수로 커밋한 .env 파일이다. 여기에 함정이 하나 있다. .gitignore는 아직 추적하지 않는 파일만 무시할 뿐, 한 번이라도 커밋된 파일은 이미 Git 히스토리에 스냅샷으로 남는다. 뒤늦게 .gitignore에 적어도 과거 커밋 안의 키는 그대로 노출돼 있다는 뜻이다.

공개 저장소에 키가 올라가면 자동 크롤러가 순식간에 긁어 가므로 대응 순서가 중요하다. 먼저 유출된 키를 발급처 대시보드에서 전부 재발급(rotate)하고, 그다음 추적에서 제외한 뒤, 필요하면 git filter-repo로 히스토리에서 파일을 지운다. 애초에 커밋되지 않게 막으려면 커밋 직전에 비밀키를 검사하는 프리 커밋 훅을 붙인다. Gitleaks는 스테이징된 파일에서 키 패턴을 찾아 커밋을 멈춰 세운다.

# 이미 커밋된 .env를 추적에서 제외
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "remove .env from tracking"

# 커밋 전에 비밀키를 검사
gitleaks detect --source . --verbose

로그도 같은 관점으로 본다. 요청 본문이나 토큰, 주민등록번호 같은 개인정보를 그대로 로그에 남기면 그 로그 파일이 곧 유출 지점이 된다. 민감한 필드는 마스킹하거나 로그에서 아예 뺀다.

브라우저 추적은 어떻게 줄이나

광고와 추적 스크립트를 브라우저 단에서 막으면 사이트를 옮겨 다닐 때 수집되는 행동 데이터가 줄어든다. 대표적인 콘텐츠 차단기가 uBlock Origin이다.

다만 크롬의 확장 환경이 바뀌었다. 구글의 확장 프로그램 규격 Manifest V3는 네트워크 요청을 실시간으로 가로채던 webRequest 방식을, 미리 등록한 정적 규칙만 쓰는 declarativeNetRequest 방식으로 바꿨다. 이 때문에 기능이 완전한 uBlock Origin은 파이어폭스에서 쓰고, 크롬에서는 규칙 수가 제한된 축소판 uBlock Origin Lite를 쓴다. 이메일도 서비스마다 다른 주소를 쓰면 추적과 스팸을 나눠 담을 수 있는데, 지메일은 아이디 뒤에 +태그를 붙인 주소([email protected])가 같은 편지함으로 들어와 이 용도로 쓰기 좋다.

내가 만든 서비스의 사용자 정보 지키기

남의 개인정보를 다루는 순간 책임의 무게가 달라진다. 첫 번째 방어선은 전 구간 HTTPS다. Let's Encrypt는 무료로 TLS 인증서를 발급하며, 기본 유효기간은 90일이고 Certbot 같은 클라이언트가 만료 전에 자동으로 갱신한다. Let's Encrypt는 인증서 유효기간을 더 짧게 줄이겠다고 예고했으므로, 갱신 자동화는 선택이 아니라 기본으로 잡아 두는 편이 낫다.

그다음은 데이터를 적게 갖는 것이다. 받지 않은 정보는 샐 일도 없으니 서비스에 꼭 필요한 항목만 수집한다. 비밀번호는 평문으로 저장하지 않고 bcrypt나 argon2 같은 전용 해시 함수로 변환해 보관한다. 한국에서 이용자 개인정보를 다루는 서비스는 개인정보보호법의 수집·이용 규정을 따라야 하므로, 수집 항목과 보관 기간을 처음부터 문서로 정리해 두면 나중에 편하다.

우선순위를 정하자면 계정 쪽은 비밀번호 관리자와 2단계 인증부터, 코드 쪽은 저장소 비밀키 점검부터 손대는 것이 품 대비 지키는 범위가 넓다. 나머지는 여기서부터 하나씩 넓혀 가면 된다.