QR 코드 보안: 동적 QR 위험과 단축 URL의 함정

요약 (TL;DR)

얼마 전 한 카페에서 메뉴 QR을 스캔했더니 낯선 ql.st 단축 서비스로 연결됐습니다. 뒤집어 보니 원래 QR 위에 새 스티커가 덧붙어 있었습니다. 사장님은 몇 주 동안 몰랐다고 했습니다. QR을 “공격”하는 정교한 취약점은 드뭅니다. 실제 사건은 거의 이렇게 스티커 한 장에서 시작됩니다.

QR 코드는 “단지 이미지”가 아니라 URL이나 텍스트를 시각적으로 인코딩한 포맷입니다. 그래서 QR 자체에는 보안 기능이 없고, 스캔한 사람이 가게 되는 도착지 URL의 안전성과 QR을 만든 방식이 보안의 거의 전부를 결정합니다. 정적 QR은 URL이 코드 안에 그대로 들어 있고, 발행 이후에는 내용을 바꿀 수 없습니다. 동적 QR은 내용 변경이 가능하지만, 리디렉터 서버에 의존하게 되므로 서비스가 종료되거나 소유권이 바뀌면 스캔 결과가 전혀 다른 페이지로 바뀔 수 있습니다. 짧은 URL도 마찬가지로 만료·납치·추적 문제가 있어, 공공 인쇄물·장기 보관물·오프라인 자료에는 부적합할 수 있습니다. 가장 안전한 기본값은 자기 도메인의 정적 URL을 정적 QR로 만드는 것이고, 캠페인 성격상 추적이 필요하면 신뢰 가능한 제공자의 동적 QR을 사용하되 종료 후 리디렉트 계획을 함께 세워 두는 것입니다.

배경/개념

QR 코드의 정식 명세는 ISO/IEC 18004로, 1–40까지의 버전이 있고 버전이 올라갈수록 모듈(격자 칸) 수가 늘어나 더 많은 데이터를 담을 수 있습니다. 한편 모든 QR은 일정량의 오류 정정(Reed-Solomon) 데이터를 함께 담습니다. 레벨은 4가지입니다.

• L: 데이터 파손의 약 7%까지 복원
• M: 약 15%까지 복원
• Q: 약 25%까지 복원
• H: 약 30%까지 복원

정정 레벨을 높이면 인쇄물이 더러워지거나 로고가 덮여도 스캔이 가능해지지만, 모듈 밀도가 올라가기 때문에 작게 출력하면 오히려 스캔이 어려워집니다. 명함이나 포스터에는 보통 M 레벨이 기본값이고, 로고를 중앙에 올려야 한다면 Q·H를 고려하는 식으로 설계합니다.

정적 QR은 URL 그대로가 모듈에 담기기 때문에 스캔 결과가 영속적입니다. 동적 QR은 “짧은 리디렉트 URL”을 담고, 서비스 제공자가 목적지를 바꿔 줄 수 있는 구조입니다. 편리하지만, 바로 그 유연성이 장기 리스크의 근원이 됩니다.

비교/데이터

기준	정적 QR	동적 QR
인코딩되는 URL	최종 도착지 URL 그대로	리디렉터의 짧은 URL
스캔 추적(집계)	기본적으로 불가	기본 기능으로 제공
만료 리스크	도메인을 유지하는 한 없음	제공자 계약·요금제·폐업에 의존
제3자 의존	없음	리디렉터 제공자
피싱 노출면	도착지 URL만 점검하면 됨	리디렉터가 해킹·소유권 변경되면 목적지가 바뀔 수 있음
수정 가능성	불가(재발행 필요)	가능(유연함)

“짧은 URL을 적어두면 깔끔해 보인다”는 장점이 곧 단점이 되기도 합니다. 사람이 URL을 눈으로 검증할 수 없기 때문입니다.

실전 시나리오

시나리오 1 — 명함·포스터 같은 오프라인 인쇄물. 2019년 명함 한 장을 최근 다시 꺼냈는데 적힌 bit.ly 단축 링크가 이미 404를 뱉고 있었습니다. 당시 트래킹 서비스 계약이 끊긴 것으로 보입니다. 정적 QR에 자기 도메인의 캐노니컬 URL을 그대로 인코딩하는 것이 가장 오래가는 선택입니다. 크기가 작을수록 오류 정정 레벨을 낮추고 모듈 수를 최소화해야 스캔 인식률이 올라갑니다.

시나리오 2 — 마케팅 캠페인 성과 측정. 한 스타트업이 전시회 부스에 동적 QR을 썼다가 3개월 뒤 해당 서비스가 무료 기능을 유료로 돌리면서 “요금제 만료” 페이지로 리디렉트된 일이 있었습니다. 저는 가능하면 yourdomain.com/go/summer-2026 같은 자기 도메인 단축 경로 + UTM 조합을 택합니다. 도메인을 쥐고 있는 한 기한이 없기 때문입니다.

시나리오 3 — 문서 무결성·인증. QR에 URL 대신 문서 해시나 서명된 URL 파라미터(?d=abc123&sig=...)를 담아, 스캔 뒤 원본과의 일치 여부를 확인하는 방식입니다. 한 인증서 프로젝트에서 SHA-256 앞 16자와 HMAC 서명을 넣었더니 QR 버전이 10+까지 올라가 인쇄 크기와 다시 균형을 잡아야 했습니다. 계약서·인증서·제품 라벨 같은 자료에 적용하면 위변조 탐지에 도움이 됩니다.

자주 하는 오해

“QR 자체를 해킹할 수 있다.” QR은 단지 데이터 인코딩 규격이라 “QR을 뚫는” 공격은 드뭅니다. 실제 리스크는 QR에 담긴 URL이 피싱·멀웨어 경로이거나, 기존 QR 위에 스티커를 덧붙여 도착지를 바꾸는 물리적 변조입니다. 공공장소의 QR은 스티커 여부를 육안으로 확인하는 것이 기본입니다.

“짧은 URL을 쓰면 더 깔끔하니까 더 좋다.” 시각적으로는 맞지만 사용자가 URL을 검증할 수 없고, 단축 서비스가 중단·매각·해킹되면 모든 인쇄물의 결과가 바뀝니다. 장기 보관물일수록 자기 도메인의 긴 URL이 안전합니다.

“오류 정정은 항상 H가 최고다.” H 레벨은 로고 삽입에 유리하지만 모듈 수가 늘어 작은 인쇄 크기에선 오히려 인식률이 떨어집니다. 명함처럼 작은 영역에는 M 정도가 일반적인 기본값입니다.

“QR만 보면 어디로 가는지 알 수 있다.” iOS 17·18 기본 카메라는 URL 배너를 띄우지만, 일부 안드로이드 OEM 카메라·서드파티 스캐너는 탭 한 번에 브라우저를 바로 엽니다. 공공 와이파이 로그인 QR을 가장한 피싱이 이 자동 열림을 노립니다. 자동 실행을 끄고, 스캔 후 도메인을 먼저 확인하는 습관이 안전합니다.

체크리스트 또는 의사결정 플로우

1. 수명은 얼마나 긴가?
   • 수년 이상 → 정적 QR + 자기 도메인 URL 권장.
   • 캠페인 단기간 → 동적 QR 또는 UTM 파라미터.
2. 추적이 반드시 필요한가?
   • 아니오 → 정적 QR로 충분.
   • 예 → 신뢰 가능한 제공자의 동적 QR. 대체 리디렉션 계획 필요.
3. 출력 크기는?
   • 매우 작음 → 데이터 양을 줄이고 오류 정정은 M 정도로.
   • 보통–큼 → 로고를 넣고 싶다면 Q·H.
4. 공공장소에 부착되는가?
   • 예 → 정기적으로 덧붙여진 스티커 여부를 점검.
5. 스캔 대상 URL은 안전한가?
   • HTTPS·자기 도메인·현재 유효 여부를 확인.
6. 제작은 어디서?
   • 가능하면 오프라인·브라우저 내 생성을 선택해 URL이 외부 서버에 로그로 남지 않도록.

관련 도구

Patrache Studio의 QR 코드 생성기는 브라우저 안에서 QR을 만들기 때문에 입력한 URL이 외부 서버로 전송되지 않습니다. QR이 들어간 이미지를 웹에 올릴 계획이라면 이미지 압축 완벽 가이드에서 포맷 선택 기준을 맞추고, QR을 문서에 삽입해 전달해야 한다면 브라우저 PDF 병합·분할의 보안 이점에서 다룬 흐름으로 문서를 결합하면 일관된 프라이버시 경계를 유지할 수 있습니다.

참고 자료

• ISO/IEC 18004:2015, “QR Code bar code symbology specification” — 표준 문서 공식 제목(무료 배포는 아님).
• UK NCSC, “Guidance on QR code use” — https://www.ncsc.gov.uk/guidance/qr-codes
• Anti-Phishing Working Group, 피싱 일반 자료 — https://www.phishing.org/phishing-examples
• MDN, URL 구조와 검증 — https://developer.mozilla.org/en-US/docs/Web/API/URL