최근에 새로운 백엔드 개발자와 복지편살 프로젝트를 다시 작업하는 협업을 하면서 마주한 것이 있었다. 백엔드 개발자 분이 개발한 DB API를 활용해, 회사 상세 페이지를 구현하는 과정에서 생긴 일이다.
같은 숫자가 아니다
기존에 다른 백엔드 개발자들과 협업할 때 테이블의 Entity의 ID를 모두 UUID 방식으로 만들어주셔서, 당연히 프론트에서는 String으로 간편하게 처리했다.
그런데 이번 백엔드 개발자 분이 개발하신 API는 회사 정보를 요청하면 응답값으로 숫자로 만들어진 회사ID를 보내주었다.
처음엔 companyId를 쿼리로 해서 각 회사 페이지를 동적 라우팅 처리하려고 했는데, 정작 처리한 후 페이지로 이동하는 버튼을 클릭했더니 페이지가 나오지 않았다.
개발자 도구의 네트워크 탭에서는 잘 통신하고 있는 것으로 나왔는데 이유가 뭔지 해맸는데, 알고보니 숫자 처리의 문제였다.
int의 종류
int는 inteager(정수)의 약자인데, 백엔드에서 DB 환경을 설정할 때 MySQL에서 id 컬럼의 타입을 설정해준다. 이때 id 컬럼을 세팅하는 몇 가지 방식이 있다. id는 고유한 값을 갖는 PK(Primary Key, 기본키)이고, 각 테이블이 id에 의해 구분되기 때문에 서비스 규모에 따라 id의 숫자 크기가 적절하게 커야 한다.
- int : 4bytes(32bit), 4,294,967,295(약 43억)
- bigInt : 8bytes(64bit), 2^64-1(약 1844경)
id는 음수를 갖지 않기 때문에 unsigned 속성을 적용했을 때의 저장 가능한 숫자의 크기이다.
당연히 저장할 수 있는 숫자가 클수록 더 많은 데이터를 담을 수 있으니 좋겠지만, bigInt와 int를 사용했을 때에는 다음의 각각 trade-off도 존재한다.
- bigInt는 int보다 더 많은 메모리 용량과 저장공간, 더 느린 쿼리 처리 속도를 가진다. 만약, 수 십억 개의 id를 가진 데이터를 처리하는 서비스가 아니라면, int를 사용하는 것이 서버 운영 효율 측면에서 유리하다.
- 하지만 향후 업그레이드 용이성을 고려하여 규모가 커진다고 판단한다면, 초기부터 bigInt를 도입하는 것이 유리하다. 테이블 id의 형을 변경하는 명령 자체는 간단하지만, 다른 테이블에서 FK로 해당 테이블을 참조하고 있다면 타입 업그레이드에 따르는 시간적 비용이 압도적으로 크다.
그래서 어떻게 처리했는가
프론트엔드에서 bigInt를 처리하는 라이브러리를 활용하는 방법도 있었지만, 백엔드 개발자 분과 협의하여 bigInt를 사용하되 API에서 id를 문자로 변환하여 보내주는 방식을 선택하게 되었다.
트위터의 경우에도 당연히 bigInt를 id 타입으로 채택하고 있었고, API에 id-str라는 속성을 둬서 id를 문자로 바꾸는 유도속성을 두고 있었다. 트위터 개발자 플랫폼 페이지 참고
트위터 API 응답값 일부
위 사례를 참고해서, API를 변경했더니 클라이언트에서도 문제없이 원하는 페이지를 가져올 수 있게 되었다.
복지편살 API 응답값 일부
