2018.08.21

모든 개발자가 알아야 할 15가지 API

Peter Wayner | InfoWorld

거인의 어깨 위에 올라 앉아있었기에 더 멀리 바라 볼 수 있었다고 말한 사람이 아이작 뉴튼이었던가? API는 코드를 작성하는 사람들에게는 함축적이고, 풍자적인 인용구와 같은 것이다. API는 프로그래머들이 더 멀리 볼 수 있고 거인들의 어깨 위에 서있을 수 있게 해준다.

Image Credit : GettyImagesBank

지난 10년간, 개발자 커뮤니티는 공개 API에 집착하게 되었으며, 공개 API의 개발은 계속 폭발적으로 증가하고 있다. 일부 개발자는 멋진 생각이 떠 올라서, 아주 훌륭한 코드를 작성했으며, 그 다음에는 우리가 그 코드를 원격지에서 실행할 수 있게 해주는 웹사이트를 개설함으로써 코드를 공개하기로 결정했다. 과거였다면, 도입 계약, 다운로드, 컴파일 문제, 그리고 거인의 어깨에 서기 위한 끝없는 고통의 시간이 있었을 것이다. 이제는 웹사이트에 몇 가지 JSON을 게시하기만 하면 순식간에 답을 얻을 수 있다.

기술적으로, 대부분의 라이선스 문제가 남아있기는 하지만, 이제는 그런 끝없는 문서에 서명하는 일이 계정을 만들고 버튼을 클릭하는 것으로 간단해졌다. 최초의 배치(Batch)는 대개 무료이며, 이는 개발은 물론이고 출시 초기 과정도 훨씬 간단하게 만들어준다.

테스트는 쉬우며 비용도 들지 않는다. 이 단계가 지나면, 비용에 각별한 주의를 기울여야 할 것이다. 다수 API의 가격은 아주 낮게 책정되어 있지만, 개발한 프로젝트가 입 소문이 나면, 이 작은 액수가 눈덩이처럼 불어날 수 있다.

API는 끊임없이 변화하며 API에 대한 액세스가 결코 항구적이거나 완전히 보장되지 않는다는 점을 인식하는 것 역시 중요하다. 몇몇 영악한 사람들이 벤모(Venmo) 거래 내역(Transaction)이 종종 공개된다는 것을 알아내고, 명예스럽다고 할 수 없는 단어로 태그된 거래 내역을 훑어보고 싶어하는 사람들을 위한 바이스모(Vicemo) 웹사이트를 개설했다. 때로는 당혹스러운 이런 세부사항들이 대중들에게 공개되어야 할까? 누군가는 프라이버시 침해에 주의를 기울이고 있기를 바란다. 페이스북은 과거에 충분히 주의를 기울이지 않았지만 이제는 페이스북 API가 훨씬 더 적은 정보를 드러내고 있다.

경험 많은 API 개발자들은 보다 철저한 인증, 더 나은 보안, 그리고 더욱 신중한 계정관리를 추가함으로써 이런 난처한 사항을 피하고 있다. 일부 API 애호가들은 API를 호스팅하고 있는 중앙 서버 팜에 데이터를 보관하는 것이 분산된 지역에서 인터넷을 떠 돌도록 하는 것보다는 훨씬 더 낫다고 주장하고 있다. 중앙 웨어하우스가 튼튼하게 유지된다면, 데이터도 계속 보호되고 있을 것이다.

이 모든 것은 API를 사용하는 것이 전에 없이 복잡해졌지만, 대부분 관리 가능하다는 것을 의미한다. 대부분의 경우, API가 사용자 대신 관리 작업을 수행할 것이다. 이는 개발자가 인터페이스 뒤에 있는 코드를 애플리케이션과 통합할 수 있는 영특한 방법을 고안해낼 수 있는 여지를 준다.

이제 우리의 눈을 사로잡고 우리가 보유하고 있는 모든 앱을 재구성하고 싶게 만드는 15가지 API를 살펴보자.

슬랙(Slack)
훌륭한 프로그래밍 팀이 API에 대한 멋진 아키텍처를 정의할 수 있지만, 진정한 수요의 척도는 사람들이 그 플랫폼을 사용하고 있는지의 여부이다. 그리고 슬랙의 경우, 점점 더 많은 사무실에서 수용하고 있다. 갈수록 더 많은 팀이 회의를 슬랙 채널로 대체하고 있으며, 이들 팀은 워크플로우를 정의하기 위해 슬랙 메시지를 사용하고 있다.

이는 다른 모든 오피스 도구를 슬랙에 연결하려는 더 많은 수요가 있음을 의미한다. 올바른 채팅 방에 업데이트를 게시해서 해당 팀원들이 일이 어떻게 돌아가는지 업데이트를 받을 수 있도록 하기 위해 챗봇 수요도 많다. 업데이트를 게시하기 위한 슬랙의 수신 메커니즘(Incoming Mechanism)은 아주 간단하다. 그것으로 부족하다면, 이벤트와 실시간 메시징에 액세스하기 위한 쌍방향 API도 있다. “우리에게 연락하지 말라” “우리가 당신에게 연락하겠다”고 문서는 말하고 있다.

웹댐(Webdam)
한 기업의 디지털 존재감의 상당 부분은 이미지에 의해 정의되며, 이런 이미지는 저장, 분류, 그리고 게시되어야 한다. 예전에는, 이미지를 여러 개의 폴더가 있는 파일 서버에 넣어두곤 했다. 웹댐은 진일보해서, 관리되고 조직화된 워크플로우가 있는 안전한 클라우드 스토리지를 제공한다. 사진과 삽화는 창작자로부터 파일 형태로 전달되지만, 브랜드를 정의하는 광고, 웹사이트, 그리고 브로셔를 위한 승인 과정을 거치면서 시스템 내부에서 “자산”이 되어간다.

중소기업에 근무하고 있으며 브랜드 이미지를 관리하고 있는 유일한 담당자라면, 많은 파일 공간을 사용해서 혼자 할 수 있을 것이다. 그렇지만, 팀과 함께 작업하기 시작하면, 흐름을 관리하기 위한 도구가 필수적이다. 웹댐 API는 사용자가 자체 내부 코드를 활용하고 이미지를 저장하고 조직화하는 파일 시스템으로 웹댐에 의지할 수 있게 해준다.

링센트럴(RingCentral)
전화는 여전히 기업의 난제이다. 많은 기업은 직원들이 자신의 개인 전화기를 가져오고 책상 위에 있는 고가의 회사 전화기를 거의 무시하는데 적응하기 위해 애를 쓰고 있다. 결국, 개인 휴대 전화는 회의에 참석하지만 회사 전화기는 그렇지 않다.

링센트럴은 웹 인터페이스를 사용해서 회사의 전화 인프라와 개인 그리고 기업의 모바일 전화기를 통합시켜줄 최신 교환기이다. 중요한 고객의 전화를 놓치지 않도록 하기 위해 착신 통화를 전체 작업 그룹과 관리 팀에 라우팅할 수 있다.

링센트럴 API는 이런 전화번호와 역할 목록을 조직화하고 최신으로 유지하기 위한 자동화 방식이다. 많은 기업들이 직원들의 전화번호를 효율적으로 조직화하기 위해 자사의 입사 (그리고 퇴사) 스크립트를 통합하고 싶어할 수 있다. 이 API는 통화량을 추적해서 분석과 시각화를 사용함으로써 직원들이 통화에 소비하는 시간도 측정할 수 있게 해준다. 더 많은 자동화를 원하는 경우, 챗봇 API는 사용자들에게 중요한 상태 업데이트 정보를 회람한다.

트윌리오(Twilio)
사무실을 중심으로 인프라가 동작하게 하는 것 이상의 전화 통합이 있다. 트윌리오는 사용자의 앱을 전화기의 음성과 문자 기능 즉, “스마트폰”이란 유행어가 등장하기 이전에 우리 전화기에서 할 수 있었던 작업과 더 쉽게 인터페이스 할 목적으로 설계되었다.

누군가에게 메시지를 전해야만 하고 그 사람에게 연락할 수 있는 최상의 방법이 음성 통화인 경우, 그 메시지를 트윌리오의 TwiML API에 넘겨주면 트윌리오가 전화를 걸고, 메시지를 음성으로 변환한 다음, 전화를 받은 사람에게 메시지를 들려준다. 다른 트윌리오 API는 사용자가 문자 메시지를 보내고 전용 트윌리오 번호로 걸려온 음성 전화에 응답할 수 있게 해준다.

이것 외에도 일일이 나열할 수 없는 수 많은 옵션들이 있다. 트윌리오의 주된 역할은 최종적으로 대기열로 들어온 전화를 받는 전문 집단을 활용해서 수천 건의 일상적인 통화를 효율적으로 처리할 수 있게 만들어주는 인프라를 구축하는 것이다. 트윌리오는 기존의 전화 옵션 즉, 음성과 문자 메시지를 최우선으로 취급해서 이를 통해 사람들과 더 쉽게 연락할 수 있게 해준다.

왓슨(Watson)
API에 대한 광범위한 관심으로 인해 왓슨이란 브랜드 이름이 IBM 자체보다 더 커졌다. 왓슨은 이미 사용자가 이미지, 소리, 그리고 텍스트를 이해하는데 도움이 되는 약 12가지 정도의 상이한 API를 포함하고 있다. 사용자가 학습 세트를 입력하면 API는 질문에 응답하기에 충분할 정도로 학습을 한다. 시각 인식 API(Visual Recognition API)는 사용자의 이미지를 받아서 그림에 있는 항목들을 분류하는 태그를 적용하기 시작한다. 말투 분석 API(Tone Analyzer API)는 텍스트 중에서 특정 감정을 나타내는 단어를 찾는다. IBM은 이 정보를 챗봇에 보내서 챗봇이 적절하게 동작하게 하라고 권고하고 있다.

자신의 “코그니티브(Cognitive) 앱”을 작성하려면 왓슨 문서, 스타터 키트, 그리고 SDK를 참고하라. 아니면, 코드를 작성하기 전에 API가 어떤 일을 하는지 알아보기 위해 왓슨 API 익스플로러(Explorer)를 둘러보라.



2018.08.21

모든 개발자가 알아야 할 15가지 API

Peter Wayner | InfoWorld

거인의 어깨 위에 올라 앉아있었기에 더 멀리 바라 볼 수 있었다고 말한 사람이 아이작 뉴튼이었던가? API는 코드를 작성하는 사람들에게는 함축적이고, 풍자적인 인용구와 같은 것이다. API는 프로그래머들이 더 멀리 볼 수 있고 거인들의 어깨 위에 서있을 수 있게 해준다.

Image Credit : GettyImagesBank

지난 10년간, 개발자 커뮤니티는 공개 API에 집착하게 되었으며, 공개 API의 개발은 계속 폭발적으로 증가하고 있다. 일부 개발자는 멋진 생각이 떠 올라서, 아주 훌륭한 코드를 작성했으며, 그 다음에는 우리가 그 코드를 원격지에서 실행할 수 있게 해주는 웹사이트를 개설함으로써 코드를 공개하기로 결정했다. 과거였다면, 도입 계약, 다운로드, 컴파일 문제, 그리고 거인의 어깨에 서기 위한 끝없는 고통의 시간이 있었을 것이다. 이제는 웹사이트에 몇 가지 JSON을 게시하기만 하면 순식간에 답을 얻을 수 있다.

기술적으로, 대부분의 라이선스 문제가 남아있기는 하지만, 이제는 그런 끝없는 문서에 서명하는 일이 계정을 만들고 버튼을 클릭하는 것으로 간단해졌다. 최초의 배치(Batch)는 대개 무료이며, 이는 개발은 물론이고 출시 초기 과정도 훨씬 간단하게 만들어준다.

테스트는 쉬우며 비용도 들지 않는다. 이 단계가 지나면, 비용에 각별한 주의를 기울여야 할 것이다. 다수 API의 가격은 아주 낮게 책정되어 있지만, 개발한 프로젝트가 입 소문이 나면, 이 작은 액수가 눈덩이처럼 불어날 수 있다.

API는 끊임없이 변화하며 API에 대한 액세스가 결코 항구적이거나 완전히 보장되지 않는다는 점을 인식하는 것 역시 중요하다. 몇몇 영악한 사람들이 벤모(Venmo) 거래 내역(Transaction)이 종종 공개된다는 것을 알아내고, 명예스럽다고 할 수 없는 단어로 태그된 거래 내역을 훑어보고 싶어하는 사람들을 위한 바이스모(Vicemo) 웹사이트를 개설했다. 때로는 당혹스러운 이런 세부사항들이 대중들에게 공개되어야 할까? 누군가는 프라이버시 침해에 주의를 기울이고 있기를 바란다. 페이스북은 과거에 충분히 주의를 기울이지 않았지만 이제는 페이스북 API가 훨씬 더 적은 정보를 드러내고 있다.

경험 많은 API 개발자들은 보다 철저한 인증, 더 나은 보안, 그리고 더욱 신중한 계정관리를 추가함으로써 이런 난처한 사항을 피하고 있다. 일부 API 애호가들은 API를 호스팅하고 있는 중앙 서버 팜에 데이터를 보관하는 것이 분산된 지역에서 인터넷을 떠 돌도록 하는 것보다는 훨씬 더 낫다고 주장하고 있다. 중앙 웨어하우스가 튼튼하게 유지된다면, 데이터도 계속 보호되고 있을 것이다.

이 모든 것은 API를 사용하는 것이 전에 없이 복잡해졌지만, 대부분 관리 가능하다는 것을 의미한다. 대부분의 경우, API가 사용자 대신 관리 작업을 수행할 것이다. 이는 개발자가 인터페이스 뒤에 있는 코드를 애플리케이션과 통합할 수 있는 영특한 방법을 고안해낼 수 있는 여지를 준다.

이제 우리의 눈을 사로잡고 우리가 보유하고 있는 모든 앱을 재구성하고 싶게 만드는 15가지 API를 살펴보자.

슬랙(Slack)
훌륭한 프로그래밍 팀이 API에 대한 멋진 아키텍처를 정의할 수 있지만, 진정한 수요의 척도는 사람들이 그 플랫폼을 사용하고 있는지의 여부이다. 그리고 슬랙의 경우, 점점 더 많은 사무실에서 수용하고 있다. 갈수록 더 많은 팀이 회의를 슬랙 채널로 대체하고 있으며, 이들 팀은 워크플로우를 정의하기 위해 슬랙 메시지를 사용하고 있다.

이는 다른 모든 오피스 도구를 슬랙에 연결하려는 더 많은 수요가 있음을 의미한다. 올바른 채팅 방에 업데이트를 게시해서 해당 팀원들이 일이 어떻게 돌아가는지 업데이트를 받을 수 있도록 하기 위해 챗봇 수요도 많다. 업데이트를 게시하기 위한 슬랙의 수신 메커니즘(Incoming Mechanism)은 아주 간단하다. 그것으로 부족하다면, 이벤트와 실시간 메시징에 액세스하기 위한 쌍방향 API도 있다. “우리에게 연락하지 말라” “우리가 당신에게 연락하겠다”고 문서는 말하고 있다.

웹댐(Webdam)
한 기업의 디지털 존재감의 상당 부분은 이미지에 의해 정의되며, 이런 이미지는 저장, 분류, 그리고 게시되어야 한다. 예전에는, 이미지를 여러 개의 폴더가 있는 파일 서버에 넣어두곤 했다. 웹댐은 진일보해서, 관리되고 조직화된 워크플로우가 있는 안전한 클라우드 스토리지를 제공한다. 사진과 삽화는 창작자로부터 파일 형태로 전달되지만, 브랜드를 정의하는 광고, 웹사이트, 그리고 브로셔를 위한 승인 과정을 거치면서 시스템 내부에서 “자산”이 되어간다.

중소기업에 근무하고 있으며 브랜드 이미지를 관리하고 있는 유일한 담당자라면, 많은 파일 공간을 사용해서 혼자 할 수 있을 것이다. 그렇지만, 팀과 함께 작업하기 시작하면, 흐름을 관리하기 위한 도구가 필수적이다. 웹댐 API는 사용자가 자체 내부 코드를 활용하고 이미지를 저장하고 조직화하는 파일 시스템으로 웹댐에 의지할 수 있게 해준다.

링센트럴(RingCentral)
전화는 여전히 기업의 난제이다. 많은 기업은 직원들이 자신의 개인 전화기를 가져오고 책상 위에 있는 고가의 회사 전화기를 거의 무시하는데 적응하기 위해 애를 쓰고 있다. 결국, 개인 휴대 전화는 회의에 참석하지만 회사 전화기는 그렇지 않다.

링센트럴은 웹 인터페이스를 사용해서 회사의 전화 인프라와 개인 그리고 기업의 모바일 전화기를 통합시켜줄 최신 교환기이다. 중요한 고객의 전화를 놓치지 않도록 하기 위해 착신 통화를 전체 작업 그룹과 관리 팀에 라우팅할 수 있다.

링센트럴 API는 이런 전화번호와 역할 목록을 조직화하고 최신으로 유지하기 위한 자동화 방식이다. 많은 기업들이 직원들의 전화번호를 효율적으로 조직화하기 위해 자사의 입사 (그리고 퇴사) 스크립트를 통합하고 싶어할 수 있다. 이 API는 통화량을 추적해서 분석과 시각화를 사용함으로써 직원들이 통화에 소비하는 시간도 측정할 수 있게 해준다. 더 많은 자동화를 원하는 경우, 챗봇 API는 사용자들에게 중요한 상태 업데이트 정보를 회람한다.

트윌리오(Twilio)
사무실을 중심으로 인프라가 동작하게 하는 것 이상의 전화 통합이 있다. 트윌리오는 사용자의 앱을 전화기의 음성과 문자 기능 즉, “스마트폰”이란 유행어가 등장하기 이전에 우리 전화기에서 할 수 있었던 작업과 더 쉽게 인터페이스 할 목적으로 설계되었다.

누군가에게 메시지를 전해야만 하고 그 사람에게 연락할 수 있는 최상의 방법이 음성 통화인 경우, 그 메시지를 트윌리오의 TwiML API에 넘겨주면 트윌리오가 전화를 걸고, 메시지를 음성으로 변환한 다음, 전화를 받은 사람에게 메시지를 들려준다. 다른 트윌리오 API는 사용자가 문자 메시지를 보내고 전용 트윌리오 번호로 걸려온 음성 전화에 응답할 수 있게 해준다.

이것 외에도 일일이 나열할 수 없는 수 많은 옵션들이 있다. 트윌리오의 주된 역할은 최종적으로 대기열로 들어온 전화를 받는 전문 집단을 활용해서 수천 건의 일상적인 통화를 효율적으로 처리할 수 있게 만들어주는 인프라를 구축하는 것이다. 트윌리오는 기존의 전화 옵션 즉, 음성과 문자 메시지를 최우선으로 취급해서 이를 통해 사람들과 더 쉽게 연락할 수 있게 해준다.

왓슨(Watson)
API에 대한 광범위한 관심으로 인해 왓슨이란 브랜드 이름이 IBM 자체보다 더 커졌다. 왓슨은 이미 사용자가 이미지, 소리, 그리고 텍스트를 이해하는데 도움이 되는 약 12가지 정도의 상이한 API를 포함하고 있다. 사용자가 학습 세트를 입력하면 API는 질문에 응답하기에 충분할 정도로 학습을 한다. 시각 인식 API(Visual Recognition API)는 사용자의 이미지를 받아서 그림에 있는 항목들을 분류하는 태그를 적용하기 시작한다. 말투 분석 API(Tone Analyzer API)는 텍스트 중에서 특정 감정을 나타내는 단어를 찾는다. IBM은 이 정보를 챗봇에 보내서 챗봇이 적절하게 동작하게 하라고 권고하고 있다.

자신의 “코그니티브(Cognitive) 앱”을 작성하려면 왓슨 문서, 스타터 키트, 그리고 SDK를 참고하라. 아니면, 코드를 작성하기 전에 API가 어떤 일을 하는지 알아보기 위해 왓슨 API 익스플로러(Explorer)를 둘러보라.



X