2단계 인증(OTP)과 백업 코드, 계정별로 어떻게 보관해야 나중에 안 잠기나

다계정을 시작하고 제가 가장 크게 당황한 순간은 계정이 정지됐을 때가 아니었어요. 제 손으로 켜둔 2단계 인증 때문에 제 계정에 못 들어갔을 때였습니다.

폰을 바꾸면서 인증 앱을 새 기기에 그냥 다시 설치했는데, 코드 목록이 텅 비어 있었어요. 백업 코드는 "나중에 저장하기" 를 누르고 잊었고요. 계정 7개 중 3개가 그날 하루 종일 먹통이었습니다. 복구하는 데 며칠 걸린 것도 있고, 결국 못 살린 것도 하나 있어요.

그 뒤로 보관 방식을 처음부터 다시 짰습니다. 이 글은 저처럼 "보안은 켜두면 좋은 거지" 정도로만 알고 시작한 분들을 위한 정리예요.

2단계 인증은 왜 다계정에서 더 까다로워지나

계정이 하나일 때는 OTP가 단순합니다. 내 폰에 앱 하나 깔고, 코드 하나 보면 끝이죠. 그런데 계정이 늘어나면 성격이 완전히 달라져요.

• 인증 앱 목록에 비슷한 이름이 10개 넘게 쌓입니다. 어느 코드가 어느 계정인지 헷갈려요
• 계정마다 복구 이메일·전화번호가 다른데, 그 복구 수단 자체도 각각 2단계 인증이 걸려 있어요
• 계정 하나가 제한되면 그 계정에 묶인 복구 이메일로 받던 다른 계정 알림도 같이 막힙니다
• 운영 환경을 계정별로 나눠 쓰고 있으면(브라우저 프로필·프록시 분리), 평소와 다른 환경에서 로그인할 때 추가 인증이 더 자주 뜹니다

즉 다계정에서 OTP는 "보안 기능" 이 아니라 운영 자산이에요. 자산이면 대장이 있어야 하고, 백업이 있어야 하고, 점검 주기가 있어야 합니다.

백업 코드의 정체 — 저는 이걸 몰랐어요

제가 처음에 잘못 알고 있던 것부터 짚고 갈게요.

특히 세 번째가 중요해요. 저는 불안해서 백업 코드를 두 번 재발급했는데, 메모 앱에 남아 있던 건 첫 번째 목록이었습니다. 쓸 수 없는 숫자를 안심이라고 들고 있었던 거죠.

계정별 보관 원칙 5가지

제가 지금 지키는 규칙입니다. 복잡한 도구 없이도 됩니다.

1. 한 계정 = 한 줄 기록

계정 식별자, 인증 앱 등록 여부, 백업 코드 보관 위치, 복구 이메일, 복구 전화, 마지막 확인일. 이 여섯 칸을 한 줄로 관리해요. 칸이 많아지면 안 채우게 되더라고요.

2. 백업 코드는 "남은 개수" 를 같이 적는다

10개 중 몇 개를 썼는지 모르면 백업이 아니라 추측입니다. 한 개 쓸 때마다 그 줄을 지우고 남은 수를 갱신해요.

3. OTP 비밀키와 백업 코드를 같은 곳에 두지 않는다

한 곳이 날아가도 다른 경로가 남아야 복구가 됩니다. 저는 인증 앱은 기기, 백업 코드는 암호 관리자, 종이 사본은 집 서랍 이렇게 셋으로 분산했어요.

4. 복구 이메일은 운영 계정과 분리한다

판매 계정의 복구 이메일을 같은 플랫폼 메일로 걸어두면, 그 플랫폼에 문제가 생길 때 양쪽이 동시에 막힙니다. 복구용 메일은 마케팅·판매에 전혀 쓰지 않는 별도 주소로 두는 게 안전합니다.

5. 인증 앱 안의 이름을 내가 정한 규칙으로 바꾼다

플랫폼이 자동으로 붙여주는 이름은 비슷비슷해서 구분이 안 됩니다. 저는 용도-번호-플랫폼 형태로 직접 고쳐 적어요. 예: 스토어-03-A플랫폼. 급할 때 코드를 잘못 넣어 실패 횟수를 쌓는 일이 줄었습니다.

보관 매체별로 느낀 장단점

정답은 하나가 아니고, 서로 다른 두 가지 이상을 겹쳐 쓰는 것이 핵심이었어요. 어떤 방법도 혼자서는 충분하지 않습니다.

기기를 바꿀 때 순서

제가 사고를 낸 지점이라 순서를 고정해 뒀습니다.

1. 새 기기 준비 전에 모든 계정의 백업 코드 유효성을 먼저 확인한다

2. 인증 앱의 이전 기능(계정 내보내기)이 있으면 그걸 먼저 쓴다

3. 이전이 안 되는 계정은 2단계 인증을 해제했다가 새 기기에서 다시 등록한다

4. 재등록이 끝날 때까지 이전 기기를 초기화하지 않는다

5. 전부 끝난 뒤에 백업 코드를 새로 발급받고, 기록된 옛 목록을 폐기한다

3번이 겁나서 저는 처음에 건너뛰었어요. 그런데 "해제 → 재등록" 은 잠깐 보안이 낮아지는 구간이 생기는 대신, 기기 교체 후 영구 잠김보다는 훨씬 나은 선택이었습니다. 하는 동안 다른 작업은 멈추고 그 작업만 하세요.

전화번호 재활용의 함정

다계정에서 자주 나오는 문제인데요. 번호 하나를 여러 계정의 복구 수단으로 돌려 쓰면 두 가지가 겹칩니다.

첫째, 플랫폼 쪽에서는 동일 번호가 걸린 계정들을 서로 연관된 것으로 볼 여지가 생깁니다. 계정 하나에 문제가 생겼을 때 연결된 다른 계정까지 들여다볼 단서가 되죠.

둘째, 번호를 해지하거나 명의를 바꾸면 그 번호를 복구 수단으로 둔 계정 전부가 한꺼번에 복구 불가 상태가 됩니다. 저는 안 쓰는 번호를 정리하다가 이걸 늦게 알아챘어요.

그래서 지금은 복구 전화가 꼭 필요한 계정에만 번호를 걸고, 나머지는 인증 앱 + 백업 코드 조합으로 둡니다. 번호를 정리할 계획이 있으면 해지 전에 그 번호가 걸린 계정 목록을 먼저 뽑아 보세요.

분기마다 돌리는 점검 루틴

보관은 한 번 해두면 끝나는 게 아니라 썩습니다. 3개월에 한 번, 30분 정도로 이렇게 봅니다.

• 기록표의 계정 수 = 실제 운영 중인 계정 수가 맞는지
• 인증 앱에 등록돼 있는데 기록표에 없는 항목(유령 항목) 정리
• 백업 코드 남은 개수가 2개 이하인 계정은 재발급 후 기록 갱신
• 복구 이메일에 실제로 메일이 도착하는지 테스트 발송
• 쓰지 않는 계정은 자료를 내리고 정리 — 방치된 계정이 나중에 제일 골치였어요

제가 하지 말라고 말리고 싶은 것

• 백업 코드를 로그인 아이디·비밀번호와 같은 줄에 적어 두기
• 백업 코드를 캡처 이미지로 사진첩에 두기(동기화되면서 어디까지 퍼지는지 추적이 어렵습니다)
• "일단 2단계 인증 끄고 나중에 켜자" 로 미루기 — 저는 끝까지 안 켰습니다
• 계정 수를 먼저 늘리고 관리 체계를 뒤에 만들기. 순서가 반대면 반드시 꼬입니다

정리

2단계 인증은 외부 침입을 막기 위한 장치인데, 다계정 환경에서는 나 자신을 막아버리는 사고가 훨씬 자주 일어납니다. 적어도 제 주변 초심자들은 해킹보다 자기 잠김으로 계정을 더 많이 잃었어요.

제가 내린 결론은 단순합니다. 계정을 하나 만들 때 OTP 등록, 백업 코드 저장, 복구 수단 기록까지를 한 세트로 끝내고 넘어가는 것. 나중에 하겠다고 남겨 둔 건 저는 한 번도 돌아가서 한 적이 없습니다.

이 방식이 모든 잠김을 막아주는 건 아니고, 플랫폼 정책이나 확인 절차는 계속 바뀝니다. 다만 복구 경로를 두 개 이상 준비해 두면 선택지가 생긴다는 점은 분명했어요. 저는 그 차이로 계정 하나를 살렸습니다.