우리는 매일 수없이 많은 ‘인증번호’를 마주합니다. 은행 앱에 로그인할 때, 새로운 사이트에 회원가입을 할 때, 혹은 중요한 결제를 진행할 때 스마트폰으로 전송되는 6자리 숫자. 너무나 익숙해서 당연하게 여기는 이 짧은 숫자 뭉치가 사실은 고도의 수학적 설계와 정밀한 시간 동기화의 결과물이라는 사실을 인지하는 사용자는 많지 않습니다.

많은 이들이 OTP(One-Time Password)를 단순히 ‘서버가 랜덤한 숫자를 생성해 나에게 보내주는 것’이라고 생각합니다. 하지만 만약 정말로 단순한 랜덤 숫자라면, 네트워크 지연이나 서버 오류가 발생했을 때 인증 시스템은 엉망이 될 것입니다. 또한, 전송 과정에서 누군가 이 숫자를 가로챈다면 보안은 순식간에 무너집니다. 우리가 믿고 쓰는 이 6자리 숫자가 어떻게 복제 불가능한 보안성을 유지하며, 어떻게 서버와 내 기기가 서로 다른 장소에 있음에도 동일한 숫자를 인식하는지 그 내부 메커니즘을 파헤쳐 볼 필요가 있습니다.

OTP의 핵심: 공유 비밀키(Shared Secret)의 개념

OTP 시스템의 가장 밑바닥에는 ‘공유 비밀키(Shared Secret)’라는 개념이 자리 잡고 있습니다. 이는 서버와 사용자 기기가 처음 연결될 때 서로만 알 수 있도록 안전하게 교환한 고유한 암호 키입니다. 우리가 구글 OTP(Google Authenticator) 앱을 설정할 때 QR 코드를 스캔하는 행위가 바로 이 공유 비밀키를 내 스마트폰에 저장하는 과정입니다.

중요한 점은 이 비밀키가 네트워크를 통해 매번 전송되지 않는다는 것입니다. 비밀키는 서버의 데이터베이스와 사용자의 기기에 각각 안전하게 보관되며, 실제 인증 시에는 이 키를 재료로 삼아 ‘계산’된 결과값만을 주고받습니다. 즉, 해커가 네트워크 패킷을 가로채더라도 얻을 수 있는 것은 이미 사용 시간이 만료된 6자리 숫자일 뿐, 다음 숫자를 생성하는 데 필요한 근본적인 비밀키는 알 수 없습니다.

시간 기반 OTP(TOTP)의 작동 원리

가장 널리 쓰이는 방식인 TOTP(Time-based One-Time Password)는 이름 그대로 ‘시간’을 변수로 사용합니다. 알고리즘의 논리는 매우 명쾌합니다. [공유 비밀키 + 현재 시간 = OTP 번호]라는 공식입니다.

• 시간 윈도우(Time Step): 보통 30초 단위로 시간이 쪼개집니다. 현재 시간이 12시 00분 15초든 25초든, 동일한 30초 구간 안에 있다면 알고리즘은 같은 시간 값을 입력값으로 사용합니다.
• 해싱 함수(HMAC): 비밀키와 시간 값을 합친 뒤, HMAC-SHA1과 같은 암호화 해시 함수에 통과시킵니다. 이 과정에서 입력값이 단 1비트만 달라져도 완전히 다른 결과값이 나오는 ‘눈사태 효과’가 발생하여 예측이 불가능해집니다.
• 절삭(Truncation): 해시 함수의 결과물은 매우 긴 문자열입니다. 이를 사용자가 입력하기 편하도록 특정 규칙에 따라 6자리 혹은 8자리 숫자로 변환하여 화면에 표시합니다.

결과적으로 서버와 클라이언트는 각자 가지고 있는 비밀키와 현재 시간을 동일한 알고리즘에 넣고 계산합니다. 두 결과값이 일치하면 인증이 성공하는 방식입니다. 별도의 통신 없이도 두 장치가 동일한 숫자를 만들어낼 수 있는 이유는 바로 ‘시간’이라는 전 지구적 공통 기준점을 사용하기 때문입니다.

HOTP와 TOTP: 무엇이 다른가?

시간 기반의 TOTP 외에도 HOTP(HMAC-based One-Time Password)라는 방식이 있습니다. TOTP가 시간의 흐름에 따라 번호를 바꾼다면, HOTP는 ‘카운터(Counter)’ 값을 사용합니다. 사용자가 버튼을 누를 때마다 카운트가 1씩 증가하고, 이 숫자와 비밀키를 조합해 OTP를 생성합니다.

현실 세계의 적용 사례와 한계

우리가 흔히 사용하는 금융권의 하드웨어 OTP는 주로 HOTP 방식을 사용합니다. 배터리가 내장된 작은 기기 내부의 카운터가 증가하며 번호를 생성하죠. 반면, IT 서비스의 2단계 인증(2FA) 앱들은 TOTP를 선호합니다. 별도의 하드웨어 제조 비용이 들지 않고, 시간 기반이기에 보안성이 더 높기 때문입니다.

하지만 이러한 시스템에도 취약점은 존재합니다. 가장 대표적인 것이 ‘사회 공학적 해킹(Social Engineering)’입니다. 해커는 기술적으로 OTP를 뚫는 대신, 사용자에게 전화를 걸어 “보안팀입니다. 본인 확인을 위해 지금 온 인증번호를 알려주세요”라고 속입니다. 아무리 강력한 암호학적 알고리즘이라도 사용자가 직접 번호를 넘겨준다면 무용지물이 됩니다. 또한, 스마트폰 자체가 해킹되어 메모리에 저장된 공유 비밀키가 유출될 경우, 해커는 실시간으로 OTP를 생성할 수 있게 됩니다.

보안 실무자를 위한 액션 아이템

단순히 OTP를 도입하는 것을 넘어, 더 견고한 인증 체계를 구축하려는 기업이나 개발자라면 다음과 같은 전략을 고려해야 합니다.

• 시간 오차 허용 범위(Drift Window) 설정: 네트워크 지연이나 기기 간의 미세한 시간 차이로 인해 인증이 실패하는 경우가 많습니다. 서버 측에서 현재 시간 기준 앞뒤로 1~2개의 타임스텝(약 30~60초)을 허용 범위로 설정하여 사용자 경험을 개선하십시오.
• 비밀키 저장소의 암호화: DB에 공유 비밀키를 평문으로 저장하는 것은 매우 위험합니다. KMS(Key Management Service)를 활용해 비밀키 자체를 한 번 더 암호화하여 저장하십시오.
• FIDO2/WebAuthn으로의 전환 검토: OTP는 여전히 유효하지만, 피싱에 취약합니다. 생체 인증이나 하드웨어 보안 키를 사용하는 FIDO 표준으로 전환하여 ‘번호 입력’ 단계 자체를 없애는 것이 궁극적인 보안 강화 방향입니다.
• 재사용 방지 로직 구현: 한 번 사용된 OTP 번호는 유효 시간이 남아있더라도 즉시 폐기 처리하여, 동일한 번호로 다시 진입하는 ‘재전송 공격(Replay Attack)’을 차단해야 합니다.

결론: 보이지 않는 곳의 정교한 약속

OTP는 결국 서버와 클라이언트 사이의 ‘정교한 약속’입니다. 서로 같은 키를 가지고, 같은 시간에, 같은 수학적 공식을 적용하겠다는 약속 말입니다. 이 단순한 원리가 현대 인터넷 보안의 거대한 방어벽을 형성하고 있습니다.

기술은 계속 발전하며 OTP를 넘어 패스키(Passkey)와 같은 무암호(Passwordless) 시대가 오고 있습니다. 하지만 그 근간이 되는 해시 함수와 공유 비밀키의 개념은 앞으로도 모든 인증 시스템의 핵심으로 남을 것입니다. 우리가 무심코 입력하는 6자리 숫자 뒤에는, 1초의 오차도 허용하지 않으려는 수학적 치열함이 숨어 있습니다.