로그인은 빠를 필요가 없다
유튜브롤 보다가 재밌는 지점을 봤다. 거의 모든 기능은 빠를수록 좋은데, 느릴수록 좋은 기능이 있다는 것. 로그인이다. 로그인이 빠를수록 보안이 깎이고, 서버 비용이 오르고, 정작 사용자는 그 속도를 체감하지 못한다. “느려도 괜찮다”는 말이 아니다. “빠름을 추구할 이유 자체가 없다”는 말이다.
빠른 로그인은 공격자에게 선물이다
비밀번호 검증은 사실 일부러 느리게 만든 연산이다. bcrypt, argon2 같은 해시 함수는 계산 비용을 “조절 가능”하게 설계돼 있다. work factor를 올리면 한 번 해시하는 데 걸리는 시간이 늘어난다. 사람 눈엔 0.2초나 0.4초나 차이가 없지만, 브루트포스 공격자 입장에선 하늘과 땅이다. 1억 번 시도할 때 2천만 초냐 4천만 초냐가 갈린다.
여기서 “로그인 빠르게 만들자”는 제안은 work factor를 낮추자는 말과 같다. 사용자는 0.2초 빨라진 걸 못 느끼지만, 공격자는 크래킹 시간이 절반으로 준다. 금고 문을 가볍게 만들어서 손님이 편하게 들어오게 했더니, 도둑도 똑같이 편해진 꼴이다.
대부분의 기능은 빨라지면 사용자만 덕 본다. 로그인만 예외다. 빨라지는 만큼 공격자도 같이 빨라진다. 이 비대칭이 핵심이다.
해시는 일부러 무겁게 만든 연산이다
서버 관점에서 봐도 그림이 비슷하다. bcrypt 한 번이 1ms 걸린다고 쳐도, 초당 수만 건의 요청을 처리하는 웹 서비스에선 결코 가벼운 연산이 아니다. 로그인 시도가 몰리는 시간대엔 CPU가 금세 튄다.
이 연산을 더 빠르게 만들겠다고 work factor를 내리면 보안이 깎인다. 캐싱을 한다? 비밀번호 해시는 캐싱하면 안 되는 대표 주자다. 병렬화를 한다? 이미 각 요청은 독립적이라 자동으로 병렬이다. 결국 로그인 속도를 올리는 합법적인 방법은 “계산을 덜 하는 것”인데, 그건 보안을 버리는 길이다.
그래서 로그인은 최적화할 여지가 거의 없다. 있어도 안 해야 한다. 이건 느린 게 아니라, 느리게 유지돼야 하는 기능이다.
하루에 한 번 누르는 버튼에 왜 힘을 쓰나
더 결정적인 이유는 따로 있다. 로그인은 사용 빈도가 낮다. 보통 사용자는 하루에 한 번, 많아야 두세 번 로그인한다. 세션이 살아 있는 한 다시 안 뜬다. 앱이라면 자동 로그인이 깔려서 아예 안 뜨는 경우가 많다.
체감 속도 개선은 빈도의 함수다. 수십 번 쓰는 기능의 0.1초 단축은 누적돼서 인지된다. 하루 한 번 쓰는 기능의 0.5초 단축은 인지되지 않는다. 성능 최적화에 드는 엔지니어의 시간을 생각하면, 로그인 튜닝은 투자 대비 회수가 가장 낮은 축에 든다.
한국 독자라면 떠오르는 장면이 있을 거다. 공인인증서 시절의 액티브X 로그인. 그거 진짜 느렸다. 그런데 사람들이 불편해했던 포인트는 속도가 아니었다. 매번 뭘 깔아야 했던 과정의 복잡도였지, 인증 자체의 지연이 아니었다. 빠름과 편함을 구분 못 하면 엉뚱한 데를 깎게 된다.
“느려도 괜찮다”와 “빠를 필요가 없다”는 다르다
여기서 구분을 하나 해야 한다. 이 글은 로그인이 느려도 상관없다는 말이 아니다. 30초씩 걸리는 로그인은 당연히 문제다. 응답 자체가 없는 건 UX 파탄이다.
말하고 싶은 건 다르다. 적정선을 넘어서까지 빠르게 만들려고 애쓸 이유가 없다는 거다. 0.5초면 충분하다. 0.2초로 줄이려고 work factor를 내리거나 아키텍처를 뒤집는 건 득보다 실이 크다. 이 선을 그을 줄 아는 게 엔지니어링 판단이다.
성능 최적화는 “어디를 깎을까”의 문제가 아니다. “어디를 절대 깎으면 안 되는가”를 먼저 정하는 문제다. 그걸 정하고 나면 나머지 대상은 훨씬 선명해진다.
빠르게 만들 대상을 고르는 감각
로그인을 기준점으로 삼으면 다른 기능을 보는 눈도 달라진다. “이 기능은 얼마나 자주 쓰이나”, “빠르게 만들 때 다른 속성(보안, 정확도)이 깎이진 않나”, “사용자가 이 단축을 체감할 만한 빈도인가”. 세 가지 질문을 통과한 기능만 최적화 대상이다.
검색 자동완성, 피드 스크롤, 결제 확인. 이런 건 거의 다 통과한다. 자주 쓰고, 보안 트레이드오프가 없고, 체감이 분명하다. 반면 로그인, 회원가입, 비밀번호 재설정. 이쪽은 거의 다 떨어진다. 드물게 쓰이거나, 빠르게 만들면 보안이 깎이거나, 둘 다다.
엔지니어가 성능 개선 과제를 받았을 때 해야 할 일은 “어떻게 빠르게 할까”보다 “이걸 빠르게 하는 게 맞나”가 먼저다.
마무리
빠름은 기본값이 아니다. 빠름은 선택적으로 투자하는 속성이다. 로그인처럼 느린 게 미덕인 기능도 있고, 빠르면 오히려 해로운 기능도 있다. 엔지니어의 역량은 결국 “어디에 자원을 투자할지 고르는 눈”에서 갈린다.