초보 기획자/PM을 위한 API 보는 법 (3)
API가 기대 혹은 예상과 다른 경우
Previously...
1. 모든 서비스는 사용자가 정보를 생성, 수정, 삭제, 조회하는 서비스인데
2. 사용자와 서버 사이에 이렇게 정보가 오고 가려면 API가 필요하고
3. 이를 GET, POST, PUT/PATCH, DELTE 유형으로 분류할 수 있고
4. 이걸 꼭 팀/조직 내에서 만들어 쓰는 대신, 공용으로 제공되는 Open API라는 걸 이용할 수도 있다
5. SWAGGER에서는 주요 기능 단위로 이를 분류해뒀을 거고
6. 각 API에서 어떤 값을 넣으면 어떤 값이 어떻게 돌아오는지 확인할 수 있다
이전 글에서는 초보 기획자가 알아야 할 API에 관한 설명을 했다면, 이번 글에서는 실제 기획, 프로젝트 단계에서 맞닥뜨리는 상황을 SWAGGER의 사례와 함께 살펴보고자 한다.
기획, 프로젝트 과정에서 기획자/PM이 API와 관련해서 맞닥뜨릴 질문은 사실 대부분 아래와 같을 것이다.
1) 이런 정보를 불러와야 하는데 그걸 불러올 api가 있나?
2) 뭐가 있긴 있는 것 같은데 구체적으로 어떤 값을 어떻게 불러오는 거지?
3) 약간 다른 거 같은데 이건 무조건 백엔드 개발자분이 해주셔야 하나?
이번 글에서는 위의 3) 번에 관한 내용을 정리하며, 글을 마무리하고자 한다
1. 기획자/PM이 일일이 API를 챙기진 않는다. 그러나...
외부에 API 자체를 제공하는 일을 담당하는 팀과 그 팀의 기획자/PM이 아니라면야, 사실 이 부분을 기획자/PM이 디테일하게 신경 쓸 일은 없을 거라고 생각한다. 사용자가 사용할 기능이 어떤 값을 어떻게 주고받는지가 정의되면, 이에 맞춰 어련히 개발자가 신경 쓰기 때문이다. 기획자가 일일이 API를 검수하거나 확인하진 않는다.
그러나, 서비스 기획 혹은 프로덕트의 성장에 집중하는 역할보다는 구축 과정을 자체를 담당하는 프로젝트 매니저라면, 이 부분이 때론 문제가 될 수 있다. 정확히는 프론트엔드 개발자와 백엔드 개발자 사이에 이슈가 생긴다.
가령, 동일한 기획안을 보고 프론트엔드 개발자가 생각하는 "이 기능엔 이런 API가 이렇게 있겠군" 하는 기대치와 실제 백엔드 개발자가 짜 놓은 API가 다른 경우가 발생한다.
1. 있어야 할 값이 없거나 : 기획 상에서는 A, B, C 값을 불러와야 하는데 C가 빠졌다
2. 있긴 있는데 호출이 안되거나 : A, B, C 모두 불러올 것처럼 생겼는데 막상 못 불러온다
3. 기획하고 다른 값을 불러오거나 : A, B, C 값을 불러와야 하는데 C 대신 D가 호출된다
4. 기획하고 다른 방식(개수, 정렬 등)으로 값을 불러오거나 : A, B, C를 내림차순으로 가져와야 하는데 오름차순으로 가져온다
이 경우 프론트 개발자와 백엔드 개발자 사이에 이런저런 대화 내지는 약간의 트러블(?)이 발생할 수 있다. 구축 과정을 담당하는 프로젝트 매니저로써의 PM이라면 "이게 무슨 상황이지? 내가 API 설계까지 확인해야 하나?" 하며 당황하지 말고, "아, 백엔드에서 짜준 API 중에 이슈가 있는가 보구나" 정도로 이해하고 다음 일정 등을 조율하면 된다.
API를 가져와 사용해야 하는 프론트엔드 개발자가 생각하는 API와 구성이 다르거나 동작 자체가 안 되는 경우도 존재한다. 혹은 제법 큰 프로젝트여서 프로젝트 시작 단계에 백엔드 개발자가 아무리 잘 챙겨두었다고 해도 일부 API의 작업 자체가 누락되는 경우도 발생할 수 있는데, 이 경우 현재 어떤 API가 부족하고, 어떤 API가 완성되었는지를 동일하게 이해할 수 있도록 돕는 작업이 필요하다.
가령 나의 경우
1) 페이지 단위로
2) 데이터가 생성, 조회, 수정, 삭제 (CRUD) 되는 관점에서 필요한 기능을 분리하고
3) 각 분류별로 해당하는 API가 있는지 확인하여 정리하여 공유해두었다.
어차피 대부분의 웹/앱 서비스는 페이지 단위로 구성되고, 해당 페이지 내에서 주요 기능별로 오고 가는 정보가 달라 API가 나뉠 것이다. 그럼 특정 API가 어떤 식으로 설계되어야 하는지는 기획자/PM이 알 순 없거나 알 필요 없더라도, 적어도 어떤 어디에 어떤 메소드의 API가 필요할지, 그리고 그게 지금 있는지 없는지 정도는 충분히 예상하고 또 파악할 수 있다.
구축 프로젝트 당시 API 현황을 체크한 내용. 페이지, 메뉴 단위 내에서 어떤 API들이 있어야 할지는 충분히 예상할 수 있었기에 누락된 API를 확인할 수 있었다.2. 꼭 백엔드 개발자가 API를 작업하지 않아도 되는 경우도 있다
위와 같이 API를 가져와 실제 서비스에 붙여 구현하는 프론트엔드 개발자가 보기에 API가 기대 혹은 예상과 달라 이슈가 발생하는 경우가 있다. 혹은 아예 특정 API 작업이 누락되어 이를 확인하는 경우도 있다.
그런데 만약 API가 예상과 다르다면, 이는 모두 백엔드 개발자가 작업을 해야 하는 걸까? 결론부터 말하면 "아니오"다.
사실 이 부분은 구축 프로젝트에서 결국 "네 일이야 내 일이냐"를 따지는 그림과 같이 되기도 하는데, 이는 프론트엔드 개발자가 API를 적절히 응용해서 쓸 수 있기 때문이다. 가령 아래의 경우와 같다.
1. 필요한 것 이상의 값들을 호출해주는 경우: 기획에선 A, B, C를 불러오면 되는데 API에서 A, B, C, D를 불러오는 경우, 프론트엔드에서 적절히 D를 서비스에 노출시키지 않게 작업할 수 있다. (물론 A, B, C, D를 불러와야 하는데 A, B, C, 만 불러오는 경우라면 백엔드에서 작업해야 한다)
2. 필요한 것보다 더 많은 개수를 호출해주는 경우 : 기획에선 A를 최신순으로 3개만 가져와주면 되는데, API에선 최신순으로 10개를 가져와주는 경우, 프론트에서 적절히 나머지 7개는 서비스에 노출시키지 않게 작업할 수 있다.
3. 페이지, 메뉴는 다른데 사실상 동일한 값이 오고 가는 경우 : 만약 A를 3개 가져와야 하는 기능이 메뉴1에도 있고 메뉴2에도 있다면, 이를 굳이 두 개의 각기 다른 API로 나눌 필요가 없다. 이 경우 프론트엔드에서 동일한 API를 그대로 가져와 쓰면 된다.
즉 있어야 할 게 없거나 다른 값을 가져오는 경우, 혹은 전혀 다른 방식으로 가져오는 경우에는 백엔드 개발자의 작업이 필요하지만, 있는 것보다 좀 더 가져올 때, 혹은 기존 것과 동일한 걸 가져오면 되는 때에는 굳이 백엔드 개발자의 작업이 필요하지 않을 수 있다.
출력할 값, 출력할 개수 정도는 기획과 API가 달라도 때에 따라 프론트엔드에서도 충분히 작업할 수 있다.이렇게 총 세 편의 글을 통해 초보 기획자/PM이 API에 관해 실질적으로 알아야 할 부분에 대해 정리해보았다.
결국 정리하면 초보 기획자/PM이 알아야 할 API란
1. 모든 서비스는 사용자가 정보를 생성, 수정, 삭제, 조회하는 서비스인데
2. 사용자와 서버 사이에 이렇게 정보가 오고 가려면 API가 필요하고
3. 이를 GET, POST, PUT/PATCH, DELTE 유형으로 분류할 수 있고
4. 이걸 꼭 팀/조직 내에서 만들어 쓰는 대신, 공용으로 제공되는 Open API라는 걸 이용할 수도 있다
5. SWAGGER에서는 주요 기능 단위로 이를 분류해뒀을 거고
6. 각 API에서 어떤 값을 넣으면 어떤 값이 어떻게 돌아오는지 확인할 수 있다.
7. 다만 기획과 구현된 API가 서로 다를 수 있는데 API의 설계를 일일이 기획자/PM이 확인할 일을 극히 드물고
8. 대부분 API를 가져다 쓰는 프론트엔드 개발자와 API를 만드는 백엔드 개발자 사이의 조율, 작업 주체 이슈인데 이를 적절히 조율, 확인하기 위해 API의 설계를 확인하게 되고
9. 어떤 경우에는 굳이 백엔드 개발자의 손을 거치지 않고도 확인, 구현이 가능한 경우가 있다
는 사실 정도 일 것이다.
이번 글을 시작하면서 '기획자/PM이란 알아야 하는 게 참 많구나'하는 생각을 했는데, 한편으로는 '여러 방면으로 알아야 하긴 하지만 또 그렇다고 깊게 알 필요도 없구나' 하는 생각도 했다.
그러니 다소 원론적인 이야기지만 기획자/PM에게 정말로 필요한 능력은, 필요한 것에 대해 필요한 만큼만 알 수 있을 만큼의 빠른 학습력이 아닌가? 하는 생각을 하며 글을 마무리한다.
