2단계 인증, 문자와 인증 앱 비교

인증 앱이 문자보다 무조건 안전하다고 생각했습니다. 그런데 해외에서 현지 유심을 쓰다가 원래 번호로 인증 문자를 받지 못해 계정에 아예 들어가지 못한 날, 그 생각이 흔들렸습니다. 인증 앱으로 바꾸고 나서는 휴대전화를 교체하다가 기존 코드를 먼저 지우는 실수까지 했습니다. 결국 문자냐 앱이냐보다 중요한 것은 따로 있었습니다.

문자와 인증 앱, 코드를 만드는 방식이 다르다

처음에 문자 인증을 선택한 이유는 단순했습니다. 별도 앱 없이 전화번호만 있으면 됐으니까요. 직접 써봤는데, 국내에서 쓸 때는 아무 문제가 없었습니다. 문제는 해외에 나갔을 때였습니다. 현지 유심을 쓰는 동안 원래 번호로 오는 인증 문자를 바로 받지 못했고, 꼭 로그인해야 하는 계정 앞에서 한참을 막혔습니다. 문자 인증은 통신망 상태, 이동통신사 계정, 전화번호 유지 여부에 직접 영향을 받는다는 걸 그때 몸으로 배웠습니다.

그 뒤 중요한 계정부터 인증 앱 방식으로 전환했습니다. 인증 앱에서 흔히 쓰이는 방식은 TOTP(Time-based One-Time Password)입니다. 여기서 TOTP란 서비스와 앱이 처음 등록할 때 공유한 비밀값과 현재 시각을 조합해 30초마다 새 코드를 생성하는 방식입니다. 인터넷이나 문자 수신이 필요 없어서, 통신 상태가 좋지 않은 곳에서도 코드를 꺼낼 수 있습니다.

여기서 한 가지 짚고 넘어갈 게 있습니다. "인증 앱"이라는 표현 안에는 두 가지 방식이 섞여 있습니다. 화면에 표시된 여섯 자리를 직접 입력하는 것이 TOTP이고, 휴대전화로 온 로그인 알림에서 버튼을 누르는 것은 푸시 인증(Push Authentication)입니다. 푸시 인증이란 서버가 기기에 실시간 알림을 보내 승인 여부를 묻는 방식으로, 편리하지만 반복되는 승인 요청에 지쳐 잘못 누르는 공격에 노출될 수 있습니다. 같은 앱을 쓴다고 해서 위험 구조가 같지 않다는 뜻입니다.

• 문자 인증: 앱 불필요, 통신망·이동통신사 계정 상태에 의존, 해외 유심 교체 시 취약
• TOTP 인증 앱: 인터넷 없이 코드 생성 가능, 비밀값 등록 QR 코드 보관 주의 필요
• 푸시 인증: 편리하지만 반복 알림 공격(MFA 피로 공격)에 노출 가능

인증 앱도 피싱 앞에서는 완전하지 않다

인증 앱으로 바꾸고 나서 한동안은 보안이 완벽해졌다고 느꼈습니다. 그런데 솔직히 이건 예상 밖이었습니다. 공격자가 만든 가짜 로그인 페이지에 비밀번호와 TOTP 코드를 함께 입력하면, 공격자는 30초 안에 그 코드를 진짜 사이트로 전달할 수 있습니다. 미국 사이버보안 및 인프라 보안국(출처: CISA)은 문자나 인증 앱 기반 일회용 코드 방식은 피싱 저항성을 갖추지 않는다고 명확히 구분합니다. 이름만 다를 뿐 문자 코드 역시 같은 방식으로 탈취될 수 있고, 여기에 유심 교체 공격(SIM Swapping)이라는 추가 위험이 더 얹힙니다.

유심 교체 공격이란 공격자가 이동통신사를 속여 피해자의 전화번호를 자신의 유심으로 옮겨오는 방식입니다. 이렇게 되면 문자로 오는 인증 코드가 전부 공격자에게 넘어갑니다. 일반적으로 인증 앱은 이런 위험에서 자유롭다고 알려져 있지만, 실제로는 피싱 페이지 하나로 TOTP 코드도 같이 털릴 수 있습니다.

피싱 자체를 원천 차단하는 데 가장 강한 방식은 FIDO2 기반 패스키(Passkey)나 물리 보안 키입니다. 패스키란 사용자가 접속한 사이트의 실제 도메인 주소와 결합해 인증이 이루어지는 방식으로, 가짜 사이트에서는 인증 자체가 작동하지 않도록 설계되어 있습니다. NIST(미국 국립표준기술연구소)도 일회용 비밀번호(OTP) 계열과 피싱 저항성 인증을 별도로 분류하고 있으며(출처: NIST SP 800-63B), 중요한 계정에는 후자를 우선 권고합니다.

제가 경험상 정리한 우선순위는 이렇습니다. 패스키 또는 보안 키를 지원하면 그걸 먼저, 지원하지 않으면 TOTP 인증 앱, 그마저도 없으면 문자 인증이라도 켜두는 쪽이 낫습니다. 문자가 약하다고 해서 비밀번호 하나만 남겨두는 건 더 나쁜 선택입니다.

인증 방법보다 복구 준비가 더 오래 걸렸다

제가 가장 크게 배운 건 인증 앱 전환 자체가 아니라 그 이후였습니다. 휴대전화를 교체하면서 기존 인증 앱의 코드를 먼저 지워버리는 실수를 했습니다. 앱을 새 기기에 다시 설치하면 다 돌아올 거라 생각했는데, 앱 설치와 인증 항목 복원은 전혀 다른 얘기였습니다. 다행히 로그인이 유지된 노트북과 백업 전화번호가 남아 있어서 계정을 다시 열 수 있었지만, 계정마다 복구 절차가 달라서 예상보다 훨씬 오래 걸렸습니다.

그 경험 이후 제 루틴이 바뀌었습니다. 새 기기에서 코드가 실제로 작동하는지 먼저 확인한 다음, 그때 기존 기기의 인증 항목을 삭제합니다. 순서를 지키는 게 전부입니다. Google Authenticator처럼 계정 동기화를 지원하는 앱도 있지만, 기능과 보호 방식은 앱마다 다르기 때문에 본인이 쓰는 앱이 어떤 방식인지는 미리 확인해 두는 편이 안전합니다.

백업 코드(Backup Code)도 꼭 챙겨야 합니다. 백업 코드란 서비스가 2단계 인증 등록 시 발급해 주는 일회용 복구 코드로, 기기를 분실하거나 인증 수단을 쓸 수 없을 때 계정에 들어갈 수 있는 비상 열쇠입니다. 이걸 이메일 받은편지함이나 사진 앱에 그냥 저장해 두는 분들이 많은데, 잠금이 설정된 비밀번호 관리자나 안전한 오프라인 공간에 따로 보관하는 게 맞습니다. 한 번 쓴 코드는 다시 사용할 수 없는 경우가 많으니 사용 여부도 관리해야 합니다.

제 경험상 이건 좀 다릅니다. 보안을 높이려다 정작 본인이 계정 밖으로 쫓겨나는 경우가 생각보다 많습니다. 강한 인증 방법을 선택하는 것과 복구 수단을 함께 갖추는 것은 서로 반대가 아니라 세트로 준비해야 하는 문제입니다.

자주 묻는 질문

Q. 인증 앱이 문자보다 무조건 안전한가요?

A. 통신망을 통해 코드가 전달되지 않아서 유심 교체 공격 같은 위험은 줄어듭니다. 하지만 공격자가 만든 가짜 로그인 페이지에 TOTP 코드를 직접 입력하면 똑같이 탈취될 수 있습니다. 인증 앱이 더 낫지만, 그게 전부는 아닙니다.

Q. 휴대전화를 바꾸면 인증 앱 코드가 다 날아가나요?

A. 앱을 다시 설치하는 것만으로는 기존 인증 항목이 복원되지 않는 경우가 많습니다. 앱마다 계정 동기화나 기기 간 이전 방식이 다르기 때문에 교체 전에 확인이 필요합니다. 제가 직접 겪어봤는데, 새 기기에서 코드가 실제로 작동하는 것을 확인한 뒤 기존 기기를 정리하는 순서를 지키는 게 가장 안전합니다.

Q. 백업 코드는 어디에 저장해야 하나요?

A. 이메일 받은편지함이나 사진 앱은 피하는 게 좋습니다. 잠금이 설정된 비밀번호 관리자나 외부에서 접근하기 어려운 오프라인 공간에 따로 보관하는 것을 권합니다. 한 번 쓴 백업 코드는 재사용이 안 되는 경우가 많으니 사용 여부도 함께 기록해 두면 좋습니다.

Q. 패스키(Passkey)는 어떤 계정에 먼저 적용하면 좋을까요?

A. 다른 계정의 비밀번호 재설정 링크를 받는 이메일 계정이 1순위라고 생각합니다. 이메일이 뚫리면 연결된 다른 계정도 줄줄이 위험해집니다. 이메일 다음으로는 금융, 클라우드 저장소 순서로 패스키나 보안 키 지원 여부를 확인해 보는 것이 현실적입니다.

Q. 푸시 인증 알림이 여러 번 와도 무시하면 되나요?

A. 무시가 아니라 명확히 거부해야 합니다. 반복 알림에 지쳐 습관적으로 승인하는 것을 노리는 MFA 피로 공격(MFA Fatigue Attack) 때문입니다. 직접 로그인을 시작하지 않았는데 승인 알림이 왔다면, 그건 거부하고 비밀번호도 바꾸는 게 맞습니다.

결론

인증 방법을 고를 때 이름만 보고 결정했다가 두 번 실수했습니다. 문자 인증이 편하다고 뒀다가 해외에서 막혔고, 인증 앱으로 바꾼 뒤에는 복구 준비 없이 기기를 교체했습니다. 그 뒤로 제 기준은 단순해졌습니다. 패스키나 보안 키를 지원하면 먼저 검토하고, 그게 안 되면 TOTP 인증 앱, 그것도 없으면 문자라도 켠다. 그리고 어떤 방법을 쓰든 백업 코드와 두 번째 복구 수단을 반드시 같이 준비합니다.

보안을 높이려다 본인이 계정에서 쫓겨나는 상황은 좋은 설계가 아닙니다. 가장 좋은 2단계 인증은 공격에 강하면서도 분실 상황에서 안전하게 복구할 수 있고, 꾸준히 유지할 수 있는 방식이라고 봅니다. 자주 쓰는 계정 목록을 한번 꺼내서 인증 방식과 복구 수단을 같이 점검해 보는 것, 지금 당장 해볼 수 있는 가장 현실적인 첫 걸음입니다.