[코드스테이츠 PMB 13기]W7D3_API
PM도 API를 알아야 할까?
PM 또는 서비스 기획에 관심이 많은 사람들은 API에 대해 들어본 적이 있을 것이다. 사실 나도 API에 대해 들어는 봤으나 '아~ API..'하고 넘어가곤 했다.
API의 구조가 곧 제품의 정보 교환의 구조를 의미한다고 한다. PM은 제품 기능을 이해하고 관리하는 목적에서 자사 제품의 API를 파악하고 분석할 수준의 능력을 갖추는 것이 중요하다. 오늘은 API에 대해 간략하게 정리해보고 오픈 API를 살펴보려 한다.
참고로, 오늘 내용은 '비전공자를 위한 이해할 수 있는 IT 지식' 책을 참고했다!
API는 Application Programming Interface의 줄임말로 '애플리케이션'을 ‘프로그래밍’ 하는데 필요한 ‘인터페이스’이다. 여기서 인터페이스는 모니터 화면, 티비 화면, 티비 리모컨, 마우스와 키보드가 모두 포함될 수 있다. 이렇게 설명하면 솔직히 나도 모르겠어서 '비전공자를 위한 이해할 수 있는 IT 지식' 부분을 요약해보려 한다!
위의 이미지와 같이 클라이언트는 서버에게 다양한 요청을 보낸다. 카카오톡을 예를 들면
"메시지, 비디오 파일, 이미지 파일 줘!"
"로그인, 회원 가입시켜 줘!"
"이 메시지 삭제해 줘!"
위와 같은 요청을 보낼 수 있다.
이때 한글로 요청을 하게 될 경우 서버는 한글을 모르기 때문에 클라이언트 서버가 무엇을 요청하는지 이해하지 못한다. 이 요청을 구분할 수 있도록 하는 '체계'가 필요한데, 이 체계가 API인 것이다.
즉, API는 클라이언트, 서버와 같은 서로 다른 프로그램 중간에서 요청과 응답을 주고받을 수 있게 만든 체계이다.
여기서 알아두어야 할 점은 API를 만들 때는 데이터를 주고받는 기능도 함께 넣는다는 점이다.
예를 들어 로그인을 요청할 경우 아이디와 비밀번호 데이터가 필요하다. 비디오 파일이나 이미지 파일에 대한 응답을 답을 때도 데이터가 함께 와야 한다.
클라이언트가 서버에 요청을 보낼 때 아래의 이미지와 같이 'CRUD'라는 4가지 요청이 있다.
여기서 PM이나 기획자는 CRUD 관점에서 데이터를 바라볼 줄 알아야 한다. 만약 CRUD 중 특정 기능이 없는 기획이라면 그 기획 의도를 명확해야 하며, 이유를 설명할 수도 있어야 한다.
CRUD는 각각의 주소를 가질 수 있는데, 프로덕트 규모가 커질수록 CRUD 주소가 많아져 관리하기가 힘들어진다. 여기서 생긴 것이 RESTful API이다.
RESTful API에서는 CRUD를 하나의 주소로 관리한다. 따라서 이전보다 주소 개수가 줄어들어 관리하기가 편해진 것이다. 요청을 보낼 때 아래와 같이 어떤 요청을 보냈는지 파악할 수 있는 스티커를 붙여서 함께 전송한다.
Creat(생성해 줘): POST
Read(불러와 줘): GET
Update(바꿔줘): PUT(전제)/PATCH(일부)
Delete(지워줘): DELETE
외부 개발자나 사용자들이 직접 응용프로그램과 서비스를 개발할 수 있도록 공개된 소스이다. 지도 서비스와 블로그, 검색 등 다양한 서비스를 개발할 수 있도록 다양한 포털 사이트 및 공공기관에서 제공하고 있으며 누구나 접근하여 사용할 수 있다.
예를 들면 어떤 앱 서비스를 개발 중인데 해당 앱에는 지도 서비스가 필요하다. 이때 직접 개발하려니 비용과 시간이 많이 들 때 네이버나 카카오가 제공하는 지도 API를 적용하면 된다.
여기서 드는 의문점! 도대체 왜 기업들은 힘들게 개발한 API를 무료로 제공할까?
이유는 다양하지만 API를 공개함으로써 많은 사람이 API를 제공하는 서비스를 더 많이 이용하게 된다. 따라서 해당 기업은 매출이 늘어날 수 있고 시장 점유율을 높일 수 있게 된다. 즉, OPEN API를 제공함으로써 유저를 많이 끌어올 수 있게 되는 것이다.
그렇다면 오늘은 카카오의 오픈 API의 구조와 기능에 대해 내가 보면 자세하지만 남이 보면 간략하게 정리해보려 한다.
카카오톡은 현재 위의 이미지와 같이 소셜 통합 API, 인공지능 API, 비즈니스 API 총 17가지의 API를 제공하고 있다. 이중에 나는 카카오톡 지도 API에 대해 둘러보려고 한다.
카카오 지도는 SDK를 통해 제공하는 것을 알 수 있다. 로컬 API는 REST API 방식으로 콘텐츠 및 데이터를 제공한다. 여기서 위에서 말했던 'RESTful API를 제공하는구나!'를 이해할 수 있었다.
제공 기능을 살펴보면, 앱(iOS, Android)과 웹(Javascript)에서 사용할 수 있는 것을 확인할 수 있다. 또, 주소를 지도 위에 정확하게 표시하는 기능, 동을 구분하는 기능, 지번 및 도로명 주소를 제공, 장소 검색 결과, 장소 검색 시 지정된 정렬에 따라 보여주는 기능을 제공하는 것을 확인할 수 있다.
주소 검색하기 부분을 보면 GET 형식을 확인할 수 있다. GET은 REST API에서 READ(불러와 줘!) 부분에 해당하는 매소드(*)이다. 정확하지는 않지만 '주소를 찾아서 불러와 줘'라는 요청인 것 같다.
파라미터(parameter) 부분도 확인할 수 있다. 파라미터가 뭔지 알기 전에 매소드(Method)가 뭔지 알아야 한다.
매소드(Method)란
개발자들 사이에서 수학의 함수와 같은 의미로 사용되는 말이다. 요청을 보내면 결과가 나오는 API의 모습이 함수와 같아서 해당 용어를 사용한다고 한다. CRUD에서 'POST', 'GET', 'PUT', 'PATCH', 'DELETE' 스티커를 붙여서 요청하는데, 이 스티커를 매소드라고 부른다.
파라미터(Parameter)란
함수에서 x를 변수라고 부르듯이 매소드에서의 요청 변수를 파라미터라고 한다. 예를 들면 로그인 요청에서 필요한 ID와 비밀번호를 '로그인 요청에 필요한 요청 변수'를 파라미터라고 부른다.
그럼 위에 나온 표는 주소 검색 요청을 보내기 위해 어떤 파라미터가 필요한지 확인할 수 있는 부분이다.
클라이언트가 서버에 보내는 요청(Request)을 보면, 이제는 반가운 GET 매소드를 확인할 수 있다. json 형식으로 된 주소를 불러와 달라는 요청인 것 같다.
여기서 또 모르는 단어가 보인다. "json"
json은 아래 문장 정도로 간단하게 이해하고 넘어가면 된다고 한다.
'클라이언트와 서버는 요청과 응답을 주고받고, 그때 필요한 데이터들을 JSON 형식으로 주고받는다.'
빨갛게 표시된 '200 OK'를 확인할 수 있다.
클라이언트 요청에 대한 응답은 아래와 같이 성공했을 때와 실패했을 때로 나뉜다.
성공했을 때: 200번대로 응답
실패했을 때: 400번대(JSON의 문제로 인한 실패. 즉, 데이터 문제), 500번대(서버의 문제로 인한 실패)
우리가 자주 보는 404는 서버에 없는 정보를 클라이언트에 요청했을 때 보내주는 코드라고 한다.
그렇다면 위의 샘플 이미지로 서버가 클라이언트의 요청을 성공적으로 응답했다는 것을 의미할 것이다.
오늘은 API에 대해 알아보고, 오픈 API를 아주 살짝 둘러봤다. 지금 봐도 이해를 백 퍼센트 하지는 못했지만, 저번에 읽었던 '비전공자를 위한 이해할 수 있는 IT 지식'을 다시 읽어보면서 그나마 조금은 이해가 됐다. 개발, 데이터에 관련된 지식이 나에게는 정말 어렵게 다가오지만, 그래도 조금씩 알아가는 느낌이 나서 뿌듯하다!
그리고 '비전공자를 위한 이해할 수 있는 IT 지식' 정말 추천 추천 왕추천한다! 아무리 인터넷에서 찾아서 읽어도 이해가 어려운 개발 지식들을 그나마 제일 쉽게 설명해준 책이다. (이번 주 내내 이 책을 다시 펼치고 있다) 최원영님이 어느 방향에 계셨는지 알면 절이라도 올리고 싶은 마음이다! 취업 후에도 계속 꺼내 보는 책일 것 같다. 오늘 과제는 최원영 저자님께 바칩니다.. ㅎㅎ
참고 자료