회원번호 하나 바꾸자 연결된 곳이 줄줄이 따라왔다

회원번호를 조금 정리하고 싶었다.

기존에는 회원에게 임의의 번호가 붙는 방식이었는데, 관리할 때 한눈에 보기 어렵다고 생각했다. 그래서 신규 회원부터 1001, 1002, 1003처럼 순서대로 번호가 부여되도록 바꿨다.

처음에는 단순한 변경처럼 보였다.

회원이 만들어질 때 번호를 하나 차례대로 붙여주면 끝이라고 생각했다.

그런데 작업 내용을 다시 확인해보니 회원번호는 회원 정보에만 들어가는 값이 아니었다.

서비스 이용기록을 남길 때도 들어가고, 사용자의 행동을 기록하는 로그에도 들어갔다. 이용내역을 다시 불러올 때도 사용했고, 마지막 로그인 기록이나 관리자가 사용자의 플랜을 변경하는 기능에도 연결돼 있었다.

회원번호를 만드는 방법 하나를 바꿨는데 확인해야 할 기능이 여러 개로 늘어났다.

문제는 각각의 기능이 따로 움직이는 것처럼 보여도 결국 같은 사용자 정보를 기준으로 연결된다는 점이었다.

회원가입에서는 새 번호가 제대로 만들어졌는데 이용기록에는 번호가 빠진다면 나중에 데이터를 확인할 때 연결이 끊어진다.

로그에는 들어갔는데 이용내역을 불러올 때 그 번호를 돌려주지 않는다면 저장된 정보와 화면에서 사용하는 정보가 서로 달라진다.

관리 기능에서 예전 방식의 값을 기준으로 사용하고 있다면 그 부분도 다시 확인해야 했다.

그래서 한 군데를 고쳤다는 것으로 작업을 끝내지 않았다.

회원번호를 사용하는 곳을 먼저 전부 찾아보도록 했다.

확인해보니 로그를 남기는 기능, 이용횟수를 기록하는 기능, 이용내역을 조회하는 기능, 마지막 로그인 시간을 갱신하는 기능, 사용자의 플랜을 변경하는 기능까지 같은 회원번호를 사용하고 있었다.

새 번호가 만들어지는 것보다 더 중요한 것은 그 번호가 필요한 곳까지 제대로 전달되는 것이었다.

여기까지 확인하고 나니 코드만 보는 것으로도 부족했다.

실제 동작과 문서가 같은 내용을 말하고 있는지도 확인할 필요가 있었다.

전날에도 결과값 하나를 다루는 방식이 바뀌었는데 문서에는 이전 방식이 그대로 남아 있던 부분이 있었다. 그래서 이번에는 수정부터 하지 않고 프로젝트 안에 있는 문서들을 먼저 확인해 달라고 했다.

어떤 내용이 실제 코드와 다르게 적혀 있는지, 있다면 정확히 어느 문서의 어느 부분인지 먼저 정리하도록 했다.

그러자 API 설명, 사용 안내, 데이터 구조 문서 사이에서 여러 차이가 나왔다.

그중 이번에 중요한 것은 회원번호가 실제 코드에서는 여러 기능에 전달되고 있는데, 문서에서는 그 연결 관계가 충분히 드러나지 않는 부분이었다.

이쯤 되면서 처음 생각했던 작업의 크기가 달라 보였다.

처음에는 회원번호를 랜덤에서 순차 방식으로 바꾸는 일이었다.

하지만 실제로 한 일은 회원번호라는 하나의 값이 시스템 안에서 어디에서 만들어지고, 어디로 전달되고, 어디에 남는지를 확인하는 일이었다.

작은 값 하나도 한 기능 안에서 끝나지 않았다.

하나의 사용자 정보가 만들어지면 그 정보는 이용기록으로 가고, 로그로 가고, 관리자 기능으로도 이어졌다.

한 곳에서 값을 바꾸면 연결된 곳도 같이 확인해야 했다.

이번 작업을 하면서 앞으로는 기능 하나를 수정할 때 그 기능만 보지 말아야겠다는 생각이 들었다.

먼저 확인해야 할 것은 바꾸려는 값 자체보다 그 값이 어디까지 연결돼 있는지였다.

회원번호 하나를 바꾸는 일도 결국은
그 번호를 쓰는 모든 곳을 찾아보는 일이었다.

그날의 성장 노트

남은 생각 · 회원번호 하나를 바꾸는 일도 그 번호가 어디에서 만들어지고 어디까지 전달되는지 함께 봐야 했다. 한 기능만 확인해서는 전체 흐름이 맞는지 알기 어려웠다.

그때의 기준 · 값을 바꿀 때는 그 값이 연결된 기능과 문서를 먼저 확인한다. 한 곳의 수정으로 끝내지 않고, 실제 동작과 기록이 함께 맞는지 본다.