swiftER은 나의 첫 스프링부트 프로젝트이자, 처음으로 조장을 맡아 프로젝트를 총괄할 기회였다. 기존 팀 프로젝트와 달리 이번에는 기획, 데이터베이스 구조 작성 등 프로젝트의 처음과 끝을 나와 팀원들이 모두 책임져야했다. 그러다보니 평소에는 별 생각없이 사용했던 기능을 구현할 때도 다방면으로 고민을 해야 하는 경우가 생각보다 많았다. 오히려 개발 단계에 들어간 여러 고민과 숙고 덕분에 사용자인 내가 별다른 생각 없이 기능을 사용할 수 있었구나하는 생각도 들었다.
위의 물음은 사용자가 마이 페이지에서 자신의 회원 정보를 조회하는 기능을 만들다가 문득 떠올랐다. 대부분의 웹서비스에서 사용자가 자신의 아이디를 변경할 수 없는 것이 관례이지만 우리 서비스에서도 역시 아이디 변경 불가 원칙을 고수할 것인지 먼저 고민해보고 싶었다. 사용자는 자신의 아이디를 변경하지 못하더라도 관리자도 사용자들의 아이디를 변경하지 못하게 해야 할까? 스택 오버플로우같은 사이트들을 찾아보기도 하고 팀원들과 머리를 맞대고 고민한 결과, 관리자와 사용자 모두 아이디를 변경하지 못하는 방향으로 결론을 내렸다. 변경 불허의 근거는 다음과 같다:
네이버, 페이스북 등의 서비스는 데이터 무결성을 이유로 대부분의 경우 아이디 변경을 불허한다. 데이터 관련 이슈의 경우, 아이디를 다른 테이블에서 외래키로 참조하고 있다면 아이디가 변경되었을 때 해당 테이블에서도 값을 변경해주어야한다. heidiSQL 기준 외래키 설정에서 on update 항목의 값을 cascade로 설정하면 아이디 변경 시 해당 아이디를 참조하는 테이블의 아이디 값도 자동으로 바뀌기는 하지만 아이디를 참조하는 테이블이 많고, 아이디 변경이 많이 일어난다면 유지보수가 힘들 것이다. 같은 논리로, 만약 사용자의 아이디 변경을 허가하더라도 다른 유저의 변경 전 아이디를 사용하지 못하게 해야 할 것이다.
아이디 변경을 보통 불허하는 또 다른 이유로는 아이디 값이 hard code되는 부분이 있다는 것이다. 예를 들어 사용자가 자신의 개인 페이지에 다른 사람들이 방문할 수 있도록 링크를 공유하는데, 그 링크에 아이디값이 파라미터로 들어있다면 이미 공유된 링크에 대해서는 아이디가 변경되어도 아이디 파라미터값을 바꿀 수 없다.
보안 문제도 생각해보아야 한다. 조원의 개인적인 경험에 따르면, 조원의 스팀 계정이 해킹당하였는데 해커가 이메일 등 모든 정보를 바꾸었지만 스팀 정책 상 아이디는 바꿀 수 없었고, 그 덕분에 기존 아이디로 계정을 복구할 수 있었다고 한다. 만약 해커가 아이디까지 바꾸었다면 기존 계정에 접근할 방법이 없었을 것이다.
새로 아이디를 만드는 대신 이메일을 로그인 식별 정보로 사용하는 방법도 고민해보았다. 어차피 회원가입할 때 이메일을 입력하고 인증까지 거쳐야 하기때문에 이메일을 사용하는 일 자체는 문제가 되지 않을 것이라 생각한다. 그러나 가입 당시 등록한 이메일을 나중에 사용자가 삭제할 경우 등 나름의 문제가 있기 때문에 이메일을 사용하는 방법은 보류하였다. 로그인 식별 정보로서의 아이디, 그리고 아이디 변경 가능 여부는 추후 우리 서비스를 사용하는 사용자들이 생긴다면 다시 깊게 고민해보아야 할 것이다.
