유연한 태도 갖기

며칠 전에 "Create / Update 시 응답에 변경된 리소스를 포함해야 할까?"라는 제목으로 글을 쓴 적이 있다. 여기서 나는 대부분의 경우에 Create나 Update 작업 시 API 응답에 변경된 리소스를 포함해야 한다는 의견이었다. 글을 쓰고 난 지 얼마 안돼서 구글 파이어베이스 시니어 개발자님의 웨비나를 듣게 되었는데, 이번에도 궁금해서 질문을 드렸다.

사실 웨비나 주제가 흥미로워서 듣게 된 거라 질문 자체에는 크게 기대를 하지 않았다. 그런데도 답변을 듣고나서, 웨비나가 끝난 다음에도 한참을 생각했다. 그래서 내가 내린 결론은 나무가 아닌 숲을 봐야한다는 것이다. 나는 사람들이 같은 말이라도 자신만의 경험에 따라 각기 다르게 받아들이고, 해석한다고 생각한다. 나는 그렇게 알아들었다.

결국 팀을 위한 선택을 해야한다. API 응답에 무엇을 담든지 개인 취향의 문제일 수도 있고, 팀의 컨벤션일 수도 있고, 저마다 다른 이유로 만든 것에 대해 굳이 불필요한 소모전을 벌일 필요가 없다. 이렇게, 저렇게 만들었다면 그거에 맞춰 구현을 하면 된다. 이런 구현 능력을 갖추는 게 더 우선이지 않을까? 시간이 지나면서 느끼는 것이 바로 이런 것들이다. 이론적인 정답만 좇는 것이 아닌 팀을 위한 답을 도출하는 것이 더 중요한 것 같다. 회사를 다니면서 내가 생각한 이상적인 모습들이 사라지고, 현실과 타협하다 보니 그런 것 같기도 하다. 코딩만이 아닌 여러 가지 상황을 고려하게 된다.

그렇다고 해서 무조건적으로 받아들여야 한다는 뜻은 아니다. 이런 내용을 아는 상태에서 받아들이는 것과, 내가 모르니까 그저 순응하는 것은 전혀 다른 이야기다. 또한, API 설계에 대해 컨벤션이 정해져 있지 않은 상태에서 새로운 프로젝트를 시작한다거나, 내가 팀을 리드하게 된다면 설득은 해볼 수 있다.

그런 상황에서 좋은 이정표가 될 수 있을만한 게 바로, 구글에서 만든 API 설계 가이드 문서이다.

• The response should include the fully-populated resource, and must include any fields that were sent and included in the update mask unless they are input only (see AIP-203). - AIP 133, AIP 134

API 설계 가이드 문서에 따르면, Create / Update 시 응답에는 완전히 채워진 리소스를 포함해야 하며, 입력 전용이 아닌 경우, 업데이트 마스크에 보내고 포함된 모든 필드를 포함해야 한다.

결국 진리의 팀바팀, 케바케..라고는 하지만 얼마든지 개선의 여지는 있을 것이다.

여담으로, 글을 쓰기 위해 잠깐 공부해 봤는데 API 설계 시 고려해야 할 것들이 너무나 많은 것 같다. 어느 정도는 서로의 분야에 대해 아는 것이 당연히 좋겠지만, 각자의 포지션에서 서로의 전문성을 발휘하는 게 맞지 않을까. API 디자인은 백엔드 개발자가 하고, 프론트엔드 개발자가 검토를 같이 하는 게 맞지 않나 싶다.

https://onlydev.tistory.com/182