2020년 개발 회고 글에서 말했듯, 우리 회사는 trust-chain-services 라는 Go 언어로 짜여진 백엔드 서버가 존재한다. 지난 2주 정도 동안 이 백엔드 서버에 대해 몇가지 업그레이드를 수행하고 버전을 1.5.3.x 에서 1.5.4로 업데이트 했다. ...글을 쓰며 생각해보니, 1.6.x 로 업데이트를 했어야 하나 하는 생각이 들지만, 여튼. 이 업데이트를 수행하면서, 이제는 정말 고정적인 절차가 필요하다는 생각이 들어 이를 정리해둔다.
우리의 프론트엔드 앱들은 크게 웹앱들과 모바일앱으로 나눌 수 있다. 여기서 웹앱들은 서버와 함께 즉시 업데이트 배포가 가능하지만, 모바일앱은 그렇지 못하다. 우선 애플과 구글의 심사를 통과하는 시간이 존재하며, 설사 통과해서 배포가 되더라도, 사용자가 업데이트하지 않고 그냥 쓸 가능성이 존재한다. 즉각적이고 강제적으로 업데이트 내용을 배포할 수 있는 웹앱과는 사정이 다르다. 그렇기에 프론트엔드에 모바일앱이 존재한다면, 서버는 반드시 API의 호환성, 즉, Compatiability 를 신경 쓸 수 밖에 없다.
서버 측면
개인적으로 앞뒤를 모두 개발하는 위치에 있어 서버 API의 시그니처(signature)를 변경하는데 큰 고민이 없었던 바 있다. 근데 이제는 모바일 앱 사용자들도 제법 존재하는 등, 상황이 좀 달라졌다. 그래서 서버 업데이트 개발 때는 다음과 같은 원칙을 세웠다.
- API의 기존 시그니처는 유지해야 함. 더하는 것은 되도, 빼는 것은 안됨.
- API의 기존 시그니처에서 빼는 것들은
// @Deprecated주석을 달아둘 것. - 함수의 수행 내용이 바뀌더라도, 기존 파라미터와 반환값은 동일하게 제공하고 있어야 함.
이래서 서버 코드가 계속 지저분해질 수 밖에 없는 것인가 싶기도 하고, 애초에 API 설계를 좀 제대로(?) 했어야 하지 않나 싶기도 하다. 하지만 내가 미래를 예측할 순 없고, 스타트업이라는게 급격한 서비스의 변화를 언제나 대비해야 하는 것이니 어쩔 수 없이 이 현실을 받아드려야 할 것이다.
업데이트 절차
API에 대한 변경이 있을 경우, 서버의 업데이트는 세심한 절차가 필요하다고 생각된다. 모든 코드에 대한 기본적인 테스트가 수행되었다는 가정하에, 나는 다음 절차를 따라 업데이트를 수행했다.
- 서버 업데이트 (각종 DB 마이그레이션 API 실행)
- 기존 웹앱, 모바일앱이 새로운 서버와도 잘 동작하는지 확인 (만약 여기서 예기치 못한 에러가 발견되면, 서버 즉시 롤백)
- 새로운 웹앱 배포, 모바일 앱 심사 신청
기존 웹앱과 모바일앱의 동작을 확인하는 과정이 추가된 것이 예전과 달라진 지점이라 할 수 있다.
모바일 앱 측면
모바일앱에도 준비가 필요한데, 만약 서버에서 deprecated 된 파라미터, 또는 반환값을 제거하게 된다면, 사용자에게 앱 업데이트를 유도하기 위한, 알림 등을 UX 경험을 해치지 않는 선에서 띄울 수 있어야 할 것이다.
이 부분은 계속 고민 중인데, 각 API 엔드포인트별로 version 값을 갖고, 반환시 이를 같이 반환하여, 만약 모바일앱의 서버 API 라이브러리의 version 값과 불일치할 경우, 해당 API를 사용하는 페이지에서 "앱 업데이트를 수행하여야 이 페이지를 이용하실 수 있습니다" 정도의 메세지를 띄우도록 하면 어떨까 싶다. 이러면, 매번 코드를 수정할 필요 없이 동일한 코드로 서버 API 변경에 대한 대응을 할 수 있을 것 같기도.
결론
나는 소프트웨어 개발 능력이 고도화 된다는 건, 개발 과정이 절차화 되가는 과정이라고 생각한다. 많은 경험이 쌓이고, 여러 시도들에 대한 결과가 나오면서 그것들이 모여 "이런 경우에 이렇게 하면 좋다더라" 라는 소위 'practice'가 생기게 된다. 그리고 이런 것들이 잘 정리되면 하나의 "절차"가 되게 된다. 이 절차는 또 여러 경험들을 거치며, 수정되고 발전될 것이다. 이러한 과정들이 바로 회사의 소프트웨어 개발 능력이 고도화되는 과정이 아닐까. 이런 관점에서 나는 서버 API 업데이트를 개발하는 과정에 아주 작은 절차 하나를 더해 조금이나마 소프트웨어 개발 능력을 고도화했다고 말할 수 있겠다.
