"admin" == "admin "
Overview
제목에 이끌려서 들어오신 여러분들 환영합니다.
이번 글은 문자열 "admin" 과 "admin "이 같다는 것을 증명하기 위한 글이 될 예정입니다.
먼저 서두에 밝히도록 하겠습니다.
"admin" 과 "admin "은 프로그래밍적 관점에서는 절대 같은 문자열이 아닙니다.
그럼 왜 저는 "admin" 과 "admin "이 같다고 주장하는 것 일까요?
저의 발자취를 한번 따라가보도록 하겠습니다!
로그인을 해보자
저의 네이버 아이디는 "kangactor123" 입니다.
문득 호기심이 들었습니다. 아이디에 공백(White Space)를 포함하면 로그인이 당연히 안되겠지?
웬걸, " kangactor123 " 으로 로그인이 되는겁니다.
나는 가입할 때 "kangactor123" 이라는 문자열로 가입했는데, 로그인 할 때는 " kangactor123 ", "kangactor123 "이라는 문자열을 입력해도 서버에서는 같은 아이디로 판단해 로그인을 시켜주는 겁니다.
"kan gactor123" 이라는 문자열로는 로그인이 안되는걸 보아 서버에서 ID를 받을 때 trim 메서드를 활용해 좌우 공백을 제거하는구나 라고 유추해볼 수 있었습니다.
그럼 과연 네이버만 그럴까? 하며 구글과 카카오 모두 테스트를 해봤는데요. 모두 동일하게 개행을 제거해주고 같은 유저 정보를 내려주는 것을 확인할 수 있었습니다.
결국 여기서 저는 "admin" 과 "admin "이 같다는 결론을 내렸습니다.
데이터 가공
사용자에게 입력받은 데이터나, 수집한 비정형 데이터를 정형 데이터로 변경하는 과정을 데이터 전처리 과정이라고 합니다.
일반적으로 로그인 시 ID나 이메일 값을 trim 메서드를 활용해 전처리 과정을 거쳐서 유의미한 데이터로 가공해 서버에서 정형 데이터로 활용하고는 합니다. 이 과정에서 여러가지 이점을 누릴 수 있습니다.
사용자에게 좋은 경험을 선사
ID를 입력할 때 실수로 공백을 입력하는 경우가 발생할 수 있습니다. 이때 서버에서 전처리 과정으로 공백을 제거하면 사용자는 실수를 했지만 로그인을 할 수 있어 긍정적인 사용자 경험이 발생합니다.
보안
공백을 활용해 다른 계정처럼 보이게 하려는 악의적인 유저의 행동도 막을 수 있습니다. 공백을 활용한 XSS, SQL Injection 공격도 방어가 가능합니다.
프로그래밍, 기획
서두에서 저는 엄연하게 두 문자열이 프로그래밍적 관점에서 다르다는 것을 말씀드렸습니다. 그럼에도 저는 유저, 로그인이라는 특수한 상황에서 두 문자열이 같다고 주장하고 있습니다.
클라이언트(웹)에서 유저가 의도해서 입력한 값은 " admin " 입니다. 하지만 서버에서는 해당 값을 "admin"으로 판단해 같은 값을 내려주고 있죠.
회원가입 당시를 생각해봅시다!
ID는 대부분의 경우 영소문자, 숫자, 특수기호("-" 와 "_")만을 허용하고 있습니다. 공백은 당연히 허락하고 있지 않습니다.
클라이언트, 서버에서 이런 유효성 검증 로직을 거치고 생성된 유저의 ID는 당연히 공백을 포함하고 있지 않을 것 입니다. 그래서 유저의 ID는 당연히 공백을 포함하고 있지 않으니 로그인을 할 때 앞 뒤 공백을 포함해도 같은 유저의 정보를 내려주자 라고 기획을 했을것 같습니다.
데이터 처리의 관점에서도 이점을 취할 수 있습니다. 공백을 제거함으로써 악의적인 사용자의 행동을 사전에 방지할 수 있으니까요.
결국 "admin"과 "admin "은 같은 문자열 일수도 다른 문자열 일수도 있습니다. 프로그래밍적 관점에서 사고하는 것과, 서비스를 기획하는 측에서 사고하는 것은 서로 다른 결과를 도출할 수 있다는 것 입니다.
조금 비틀어진 생각
저는 여기서 조금 이상한 생각이 들었습니다.
"회원가입 당시에 공백을 입력받지 않고 로그인 할 때 ID에는 공백이 포함되어 있지 않으니 앞 뒤 공백을 잘라서 같은 유저 정보를 반환한다." 라면, "adm in"도 같은 유저 정보를 반환해야 하는 것이 아닐까 라는 생각이였습니다.
위와 같은 논리라면 어쨋든 공백을 포함하지 않으니 "adm in"도 " admin "도 "admin"도 다 같은 정보를 내뱉어야 하지 않을까 하는 비틀어진 생각이 들었습니다.
"adm in"이 ID 규칙 상 에러로 판단을 하고 있다면, 동일한 맥락에서 " admin "도 에러로 판단해야 하지 않을까 하는 생각이였습니다. 어쨋든 클라이언트(웹)을 사용하는 유저가 서버에 보낸 요청(의도)는 "adm in"도, " admin " 모두 유저가 직접 의도한 행위의 결과로 요청이 된 것이라고 생각했기 때문입니다.
현재의 사회 통념(대부분의 플랫폼에서 이런 기획으로 구현이 됐으니 사회 통념이라고 하겠습니다.)에서는 유저의 편의성을 위해서 앞, 뒤 공백을 허용하고 있고, 데이터를 가공하여 악의적인 사용자의 행위도 방지할 수 있다는 생각으로 너무 딥하게 생각하고 있구나 라는 결론을 내렸습니다.
서비스 기획은 당연히 치밀해야 하지만, 너무 딥하게 들어간다면 오히려 서비스와 로직의 복잡도가 높아져 유저에게 좋지 못한 경험을 제공할 수 있기 때문입니다.
결국은 기획하기 나름
결국은 기획하기 나름이지 않을까 생각합니다. 서비스 기획에는 정답이 없습니다. 모두가 생각하는 기획이 좋은 기획일수도, 소수의 누군가의 독특한 아이디어가 좋은 기획일수도 있습니다.
여기서 중요한 포인트는 유저에게 얼만큼의 만족감을 줄 수 있는지, 유저가 얼마나 좋은 경험을 할 수 있는지 입니다.
기획하기 나름이니 "admin"과 " admin "도 로그인 상황에서 같은 문자열이라는 결론을 내리도록 하겠습니다.
어쨋든 유저가 실수로 개행을 입력했다면, 이런 기획은 유저에게 좋은 기억과 경험을 선사해줄 수 있으니깐요. (+보안도 챙기고 말이죠.)
마무리하며
조금은 어그로성 제목에 이끌려 제 글을 읽어주셨을 것 이라고 생각합니다.
서두에서 밝혔듯이, 저는 "admin" 과 "admin "은 전혀 같지 않다고 생각합니다! 그리고 글의 후미에서도, 지금도 마찬가지입니다.
서비스를 개발하는 개발자여도, 항상 기획된 내용에 의문을 품고 긍정적으로 토론하며 유저에게 더 좋은 경험을 주고자 하는 마음가짐은 좋은 마음가짐인 것 같습니다.
읽어봐주셔서 감사합니다!