API

클라이언트(요청을 보내는 쪽), 서버(요청을 받는 쪽)와 같이 서로 다른 프로그램에서 요청과 응답을 주고 받을 수 있게 만든 체계

+)소프트웨어가 다른 소프트웨어의 기능을 쓰기 위해 중간에 필요한 체계,
기능을 사용하기 위해 요청을 보내면 응답을 해주는 소프트웨어 끼리의 체계

API는 응답을 보내는 쪽에서 만드는 것으로 요청을 보내는 쪽은 활용한다.

*클라이언트 Request(RESTful API)
Create (POST)
Read (GET)
Update (PUT/PATCH)
Delete (DELETE)

*서버 Response
200 : 잘 된 경우
400 : 클라이언트의 요청에서 문제가 있는 경우
500 : 서버에 문제가 있는 경우

*SDK(Software Development Kit) : API를 제공해주는 소프트웨어, 다른 회사와의 협업에서 사용

※출처 : 비전공자를 위한 이해할 수 있는 IT 지식(최원영 지음)
링크텍스트

A)
API에 대해 개인적으로 할 말이 정말 많다. 관련 서비스나 회사에서 API를 제공하지 않는 이유로 말 그대로 내 손으로 데이터를 하나하나 밀어 넣었고 지금도 같은 작업을 하고 있기 때문이다.

B)
일본 OTT 서비스를 담당할 때 저작권료 정산 이슈는 나를 오랫동안 힘들게 했다.

서비스 특성 상 저작권료 처리 건은 상당히 예민한 문제이고 이것을 언제 어떻게 처리 하느냐는 굉장히 중요하다. 다른 곳에서는 어떻게 하고 있는지 잘 모르지만 내가 담당했던 서비스의 경우 일본에서 저작권을 관리하는 협회가 요구한 포맷과 방식으로 분기마다 파일을 업데이트 한 후 저작권료를 청구 받는 방식으로 진행되었다.

문제는, 협회에서 요구한 포맷을 보면 서비스 되고 있는 컨텐츠의 회차 별로 넘버링 되어 있는 저작권 코드도 같이 입력해야 했는데 협회가 저작권 코드 페이지의 API를 제공하지 않아서 저작권 코드를 검색해서 하나하나 직접 입력 해야 했다...

저작권이라는 것이 예민한 이슈라서 어쩔 수 없다는 생각이 들면서도 그 많은 것들을 내 손으로 직접 입력해야 한다는 것이 솔직히 너무 답답하고 짜증이 났다.

이 같은 상황에 이전 담당자도 같은 마음이었던 걸까. 분기별로 업데이트 된 파일들은 진행 여부가 의심스러울 정도로 엉망이었다. 하지만 앞서 말했듯이 저작권 이슈는 예민한 문제이고 잊을 만하면 뉴스거리가 되서 여기저기 오르내리고 있기 때문에 나는 이전 담당자가 한 것처럼 진행 할 수가 없었다. 그렇게 하면 안된다고 생각했다.

결국, 서비스 담당 개발자에게 admin에 저작권료 정산에 필요한 데이터를 취합하고 엑셀 파일로 다운 받을 수 있는 페이지를 만들어 달라고 요청하면서 동시에 저작권 코드를 입력 및 수정, 삭제까지 할 수 있는 기능을 같이 넣어달라고 했다.

저작권료 데이터 페이지가 만들어지고 난 후 약 3개월 간 틈만 나면 저작권 협회 홈페이지에 나오는 코드를 검색해서 하나하나 입력했고 ㅡㅡ^ 이후에는 주기적으로 새로운 컨텐츠가 들어 올 때 앞서 말한 과정을 반복했다.

C)
업무를 신속하고 편리하게 처리한다는 것에 있어 갖추어야 할 기반은 여러가지를 꼽을 수 있다. 내가 속한 조직, 구성원과 더불어 관련되어 있는 외부(담당자, 서비스 등)가 해당 이슈에 어떻게 접근하고 대응하는지에 따라 너무나 많은 것들이 편리해지거나 불편해지거나 한다.

합이 잘 맞다고 하는 거, 그거 참 어려운 일이다.