연일 SK컴즈를 때리는 기사들이 나오고 있군요.

비밀번호 대·소문자 섞어 쓰라더니… 싸이월드 시스템 구분 못한다

여기 저기에서 개발자 탓하는 글들이 보이는데요, 이유는 바로 Caps Lock 때문입니다. 웹뿐만 아니라 메신저들에서는 ID 저장은 on으로, PW 저장을 off로 되어 있을 경우, 해당 사용자는 PW만 입력을 합니다. 이럴 때 만약 Caps Lock을 켜 놓았을 경우 제대로 된 로그인이 되지 않게 됩니다.

PW1를 DB에 저장된 값, PW2를 사용자가 입력한 값이라고 했을 경우

따라서 초창기 코드는

A. if (PW1 == PW2)

로 되어 있다가, 고객지원팀의 피드백(Caps Lock 켜 있는 사용자들때문에 문의 전화가 많이 들어 와요) 때문에 다음과 같이 수정되게 됩니다.

B. if (tolower(PW1) == tolower(PW2))

설게 초기에서부터 PW의 로직이 case insensitive하게 가져 가자고 한다면

C. if (PW1 == tolower(PW2))

와 같이 되겠죠. 아마도 사이월드는 C 방식을 채택한듯 하군요.

대형 서비스 해본 업체에 다녀본 개발자라면(혹은 고객지원팀에서 일했던 경력이 있다면) 이런거 보고 욕 못합니다. 서비스를 이용하는 사람 중에 Caps Lock 켜 놓은 사람이 100명중에 한명이라면 고객지원팀(inbound call을 받는)은 한명 문의만 해결하면 되겠지만, 유저 수가 100만명이라고 한다면 문의 전화가 만통이 들어 옵니다. 이러면 고객 지원팀 전화 불통 나서 업무 못합니다.

2000년대 초반, 당시 제가 다녔던 회사에서 서비스하던 Dialpad도 회원이 1000만명이 넘었었고, 주 고객들이 나이 많은 분들이 많았기 때문에(자기 아들, 딸들 외국으로 유학을 보낸 부모님들) 이런 문의가 종종 들어 왔었습니다(마우스가 뭔지 모르는 어르신들한테 Caps Lock 설명하는 거 장난이 아니었음). 그래서 메신저들을 보면 PW를 입력할 때 Caps Lock이 켜져 있을 경우 어플 레벨에서 현재 Caps Lock이 켜져 있다고 Notify를 해 주는 경우도 있죠.

이는 개발자의 miss도 아니고 설계상의 miss도 아니었습니다. 편의가 중요시되던 당시의 상황에는 그렇게 하는 것(case insensitive)이 정답이었다는 얘기입니다. 지금에 와서는 그게 "보안"의 위협을 줄 수 있으므로 점점 바꿔 나가야 한다는 것이구요.  2000년대와 2010년대는 추구하는 방향이 다릅니다. 예전에는 "편의"가 중요,  지금은 "보안"이 중요.

아직도 as-is 서비스를 살펴 보면 case insensitive하게 서비스하는 곳이 많은데, 언론이 자꾸 SK컴즈만 때리는 걸 보면 안타깝습니다(참고로 저는 SK컴즈와는 전혀 상관이 없습니다).