API에 대해서 알아보자
아마도 PM이 현업에서 가장 많이 쓰게 될 개발 용어
PM이 개발자와 커뮤니케이션할 때 가장 많이 쓰는 개발 용어 중 하나를 꼽아보라면 단연 API라 소개하고 싶다.
사실 PM 입장에서 제품 과제를 할 때의 알파이자 오메가는 주요 API를 어디서 어떻게 붙여주고, 어떤 내용을 받아오고 넘겨줄지를 의사결정하는 것이라 표현할 수 있을 정도이니, API 개념을 제대로 이해하고 사용하는 것은 매우 중요하다고 할 수 있겠다.
API가 뭔데?
API는 Application Programming Interface의 약자인데, 사실 API 용어의 근본 개념 자체를 세세하게 이해할 필요까지는 없다. 사실 개발자가 아닌 PM이나 기획자 입장에서 보면 특정 서비스가 제공 가능한 기능 정도로 이해해도 큰 무리가 없다.
(물론 대부분 용어들이 그러하듯 깊이 파고들면 파고들수록 매운맛 지식들이 필요하긴 하다.)
예를 들어 우리 서비스에서 카카오톡으로 로그인이 가능하게끔 구현해야 한다고 해보자. 당연하지만 이런 경우 카카오에서 제공하는 카카오톡 로그인 기능을 제공받아서 사용해야 하며, 이럴 때 카카오 로그인 API를 사용한다고 표현한다.
카카오 로그인 API특정 키워드를 넣었을 때 네이버 검색 결과를 보여주는 기능을 구현해야 한다고 생각해보자. 이런 경우 네이버의 검색 기능을 사용해야 하고, 이 때도 마찬가지로 네이버 검색 API를 사용한다고 볼 수 있다.
네이버 검색 API이런 기능(API)를 제공하는 서비스가 있다는 것은, 바꿔 말하면 우리 서비스 역시 API를 만들어 다른 서비스나 개발자들에게 제공할 수 있다는 의미다.
예를 들어 우리 회사가 특정 지역의 지도 정보를 만드는 회사이고, 제작한 지도 정보를 외부에 제공해 판매하는 사업을 하고 있다고 해보자. 지도 정보를 외부에 이메일 같은 형태로 넘겨줄 수도 있겠지만, 사용자가 요청했을 때 필요한 만큼의 정보만을 실시간으로 제공하는 것이 핵심이다. 이런 경우 외부 서비스에 지도 정보를 보여주는 기능(API)을 제공하고, 제공된 정보만큼 돈을 받을 수도 있다.
짐작하겠지만 이는 구글 맵스나 네이버 지도와 같은 서비스이며, 실제로 이들은 이렇게 외부에 API를 제공하는 것을 메인 비즈니스 모델 중 하나로 가지고 있다.
구글 맵스즉 "카카오로 로그인하는 기능을 제공한다", "특정 키워드에 대한 네이버 검색 결과 기능을 제공한다", "지도 정보 조회 기능을 제공한다"와 같이, API는 일종의 기능을 제공하는 것이라 생각하면 이해가 쉽다.
API는 내부 제품들 사이에서도 사용된다
위에서 설명한 것들만 보면 API는 무슨 거대한 회사들에서 핵심 기능들을 제공할 때나 쓰는 것처럼 보일 수 있지만, 실제로는 서비스 간 주고받는 기능들을 모두 포괄한다. 따라서 당연히 API는 내부 제품들 사이에서도 동작할 수 있다.
예를 들어 우리 앱에서 사용자가 화면에서 결제 버튼을 누르면 실제로 결제가 진행되어야 하는 상황을 보자.
먼저 클라이언트(화면)는 결제 서버(예시)로부터, 사용자가 결제를 요청했으니 결제 기능을 동작시켜줘!라는 요청을 보낸다. 결제 서버는 이 요청을 받고, 회원이 돈이 충분히 있는지를 확인하기 위해 회원DB로부터 정보를 받고, 상품DB로부터 상품이 충분하 재고가 있는지 등의 정보를 받아온다. 그리고 여기에 모두 문제가 없다면 최종적으로 결제를 완료하고, 문제가 있다면 문제가 있다는 알림을 준다.
이 케이스에서 설명했던 액션 하나하나가 대부분 API를 통해서 이루어진다. 즉 내부 제품 또는 DB들 사이에서도 필요한 기능을 구현하는 데에도 API를 사용하는 것이다.
API는 예상되는 동작 결과가 있어야 한다
API는 일종의 기능처럼 이해하면 된다고 설명한 바 있다. 즉 우리 서비스는 API 기능을 제공받아서 사용할 수도, 외부에 API 기능을 제공할 수도 있다.
기능이라고 한다면 사용자 입장에서는 그 기능을 사용했을 때 어떤 결과를 기대할 것이다. 즉, 각각의 API들은, 해당 서비스에 API를 요청했을 때 '특정 결과'가 있을 것을 가지고 있어야 한다. 즉 카카오 로그인 API는 카카오로 로그인을 시켜줘야 하며, 구글 지도 API는 요청했을 때 지도 결과를 주어야 한다는 것이다.
PM이나 기획자라면 제품 작업을 하거나, 외부와 연동할 때 이러한 관점에서 각각의 API들이 얼마나 필요할지, 어떻게 제공되어야 할지 등을 사용과 결과 중심으로 이해할 수 있어야 한다.
API의 세계에서를 보통 이를 요청과 반환(응답, 결과라고도 함)이라고 부른다.
API는 요청(request)과 결과의 반환(return)으로 이루어진다이렇듯 API는 서비스 구현에 필수적인 기능들을 주고받는 방식이기 때문에, 상용 서비스는 수많은 API들의 구현되어 통해 이루어진다.
실제 네이버 사이트들도 보면 이와 같이 수많은 요청/응답값들이 모인 API들을 많이 활용하는 것을 볼 수 있다.
위에서는 로그인, 검색 결과, 지도값 반환 같은 일반 사용자들이 쓰는 기능들을 이야기했지만, 실제 현업에서는 네트워크 상태 확인, DB 적재, 회원 정보 수정 등과 같은 수많은 뒷단의 작업들 역시 API로 많이 구현된다.(물론 다른 방식으로 구현하는 곳도 많다)
API의 핵심은 주고받는 정보의 정의
API는 기능, 그 중에서도 어떤 결과를 요청했을 때 그에 대한 응답을 받는 것이라 요약한 바 있다. PM이라면 API에서 어떤 정보를 주어 어떤 결과를 받아올 것인지를 핵심적으로 설계할 수 있어야 한다.
예를 들어 카카오 로그인 API라면, 카카오 계정 아이디/비밀번호라는 정보를 주어 로그인 결과를 받아오는 것이 핵심이다. 네이버 검색 API라면 검색 키워드라는 정보를 주면, 검색에 대한 결과를 받아온다. PM은 서비스를 설계하거나 개선할 때 각 API가 큰 틀에서 어떻게 동작하는지 주고받는 정보와 결과를 중심으로 알고 있어야 한다.
물론 API가 어떻게 구성/구현되어야 하는지에 대해 PM이 개발자 수준으로 알고 있을 필요는 없다. 다만 중요한 것은 내 서비스, 다른 서비스에서 제공하고 있는 API가 각각 어떤 역할을 하는지를 대략적으로 이해하고 있으면 된다. 그 정도만 알고 있어도 팀 내 개발자/다른 팀 담당자들과의 협업에서 굉장히 큰 도움이 되며, 흔히 말하는 "개발자는 다 안 된다고만 한다"와 같은 기본적인 개발자와의 커뮤니케이션 문제를 해소할 수 있다.
가용한 API가 어떤 것들이 있는지 알아보는 방법: API 도큐먼트
아니 그렇다면, 어떤 API들이 있는지 알아야 뭘 알든지 말든지 할 것 아니냐 하는 질문이 있을 수 있다. 이는 API 도큐먼트라는 것을 통해 알 수 있다. API 도큐먼트는 제공되는 API들의 명세이다.
예를 들어 아래 이미지를 보자. 아래는 전자계약 서비스를 제공하는 모두싸인의 API 도큐먼트 페이지다.
https://developers.modusign.co.kr/reference/api-reference이 페이지를 보면 모두싸인에서 제공 가능한 API들의 리스트들을 볼 수 있다. 이렇게 외부 연동을 위한 제품을 제공하는 서비스들은 대부분 이와 같이 API 도큐먼트를 고객사에 공개적으로 제공하고 있다.
API에 대한 개념을 어느 정도 알고 있는 PM이라면, 이 API명세를 보고 직감적으로 "이 서비스를 활용하면 우리 서비스에서 어디서부터 어디까지 활용할 수 있겠군"을 판단할 수 있게 된다. 물론 여전히 최종 구현 가능 여부에 대해 팀 내 개발 조직의 컨펌이 필요하지만, PM이 이렇게 1차적으로 서비스의 구현 가능 범위에 대한 직감을 구할 수 있는 것 자체만으로도 엄청나게 큰 도움이 된다.
모두싸인의 사례는 외부 서비스에 대한 API이고, 우리 서비스의 API 리스트들은 어떻게 알 수 있을까?
회사마다 다르겠지만, 어느 정도 체계가 잡힌 회사나 서비스라면 내부적으로도 API 도큐먼트를 가지고 있다.(당연히 위처럼 고객사에 제공되는 수준으로 깔끔하게 작성/관리하지는 않는 경우가 대부분이다) 이를 바탕으로 우리 서비스가 어떤 api들로 구성되어 있는지를 어느 정도 파악할 수 있다.
거듭 강조하지만 개발자 수준으로 각 api들을 이해할 필요는 없으며(가능하지도 않다), 서비스의 대략적인 API 흐름이나 핵심 API들이 각각 어떤 기능을 제공하는지 대한 윤곽 정도만 파악하고 있어도 충분하다. 가장 추천하는 것은 PM으로서 팀에 첫 온보딩을 할 때, 담당 개발자 분에게 대략적인 서비스의 api 플로우에 대한 설명을 요청하는 것이다.(PM으로 첫인사 하는 것도 겸하여)
