[프로그래밍] API vs 웹사이트

API는 일곱가지 측면에서 웹사이트와 다릅니다. 국내에서 API의 가장 성공적인 사례가 무엇일까요? 국내 API 사례 중에서 단연 주목할 만한 것이 있다면, 날리지큐브사의 Near API입니다.

이 API는 사용자 IP를 받아서 상위주소(구단위까지)를 리턴해주는 서비스입니다. 간단하지만 광고에서 빠질수 없는 기능으로 2005년부터 네이버, DAUM 등의 여러 포털에 사용되고 있습니다. 이 API는 KT, SK 브로드밴드 등으로부터 데이터를 받아서 API 형태로 공급합니다.

이렇게 API라는 영역은 뭔가 좀 특별합니다. APIgee가 그 특성을 웹사이트와 비교해서 잘 설명해주고 있습니다.

1. 이용자 Audience가 다릅니다.

웹사이트는 일반인이 사용합니다. 하지만 API는 개발자가 사용합니다. 그 개발자들은 일반인들이 사용하는 앱을 만듭니다. 즉 웹사이트와 API는 사용자 대상이 다릅니다.

이 사실은 중요합니다. API개발자들은 이미지, 컬러, 폰트 등에 신경쓰지 않기 때문입니다. 그들은 API자체의 외형 LOOK AND FEEL에만 신경씁니다.

  -> 개발하기 쉬운가? REST를 사용하는가? 잘 작동하나? 잘 뻗지는 않나?

즉, API사업의 고객은 일반인이 아니라 개발자들입니다. 따라서 개발자들의 생각과 습성을 잘 이해해야 API를 좋은방향으로 제작할 수 있습니다.

2. 지속성 Longevity이 다릅니다.

웹사이트는 항상 바뀝니다. 하지만 "API는 시간이 지나도 호환성을 유지해야만 한다." 일반 웹사이트 사용자들은 변화에 대해 탄력적으로 적응합니다. 하지만, API 개발자들은 그렇지 않습니다.

일반적으로 개발자는 재개발하기 싫어합니다. 오래된 앱은 개발자도 없습니다. 기능이 업그레이드되어도 모든 사용자가 바로 업데이트하지 않습니다. 따라서 API 기능은 쉽게 삭제될 수 없습니다.

즉, API와 웹사이트는 대상 고객과 관리방법, 개발방법 등이 완전히 다릅니다. 이런점에서 WEB AGENCY가 좋은 API 개발사가 되지 못합니다. PRODUCT가 완전히 다르기 때문입니다.

API 기획은 사업을 잘 아는 내부 개발자가 하는 것이 제일 좋습니다. 일단 API 사용자가 생기면 뒤로 돌아갈 수 없기 때문입니다.

3. 분석방법 Analytics이 다릅니다.

일반적으로 웹분석은 브라우저 환경에 기반합니다. 하지만 API Client는 그렇지 않습니다. javascript, beacon url, cookies 등에 전혀 종속적이지 않습니다.

그래서 API Client가 어떤 정보를 줄거라고 기대하면 안됩니다. 특히 아무 관계가 없는 3rd Party가 개발했다면 더더욱 그렇습니다. 따라서 API에 대한 분석 기능은 서버 애플리케이션에 embedded 시켜야합니다. Request 데이터들을 잘 활용한다면 더욱더 좋습니다.

일단 배포되고 나면 남들이 잘못 사용하고 있어도 어찌할 방법이 없습니다. 따라서 초기에 Request를 잘 수입, 분석할 수 있게 설계에 반영해야 합니다. 큰 플랫폼이라면 Call Flow를 기반으로 로그 수집 분석이 용이한 인터페이스를 만들어둘 필요가 있습니다.

API를 오픈하고도 현황을 제대로 분석하지 못하는 시스템을 여러번 보았습니다. 데이터 분석없이 사업을 한다는 것은 장님이 운전하는 것과 같아서 망하는 지름길이라고 봅니다.

4. 보안 Security 기술도 다릅니다.

웹사이트는 긁어와서 데이터를 얻어내기 힘들고 번거롭습니다. 하지만 API는 매우 쉽고, 심지어 자동화할 수도 있습니다. API는 oauth를, 웹사이트에는 password를, ssl은 양쪽 다 적용해야합니다.

1) API는 데이터 Query 기능의 개발이 쉬워서, (의도치 않게) 피해를 발생시키기도 합니다.

  - API를 이용해서 password를 crack 해보라.

  - compnay catalog를 전부 다운로드해보라.

  - 항공편 전부를 예약해보라.

만일 의도와 다른 일이 생긴다면 미리 조치를 해야합니다.

2) 호출횟수와 사용량 통제는 기본입니다.

3) Public API와 password를 사용하는 것은 바보짓입니다.

  - password는 API를 사용하는 수많은 사이트와 단말들에 자연스럽게 노출됩니다.

  - 대안으로 oauth를 사용하면 됩니다.

저작권이나 개인정보에 민감한 사업들이 있습니다. 어떤 경우는 보안 사고가 터지면 사업을 접어야 하기도 합니다. 하지만, 호출 횟수와 사용량을 통제하는 기능은 생각보다 시간이 많이 들어갑니다. 오픈이 급하다면 대안으로 'API 선별적 차단기능'을 먼저 구현하십시오.

"호출횟수 통제"는 본질적으로 과금관련 기능입니다. 불법사용을 막는데 별로 효과가 없습니다. 선택차단이 비교적 쉬우면서도 효과가 좋은 보안 대처법입니다.

5. 통합방법 Integration이 다릅니다.

웹사이트는 여러 곳의 컨텐츠를 가지고 와서 한 화면에 보여줍니다. 하지만 API는 그냥 자기 사이트의 것들만 제공합니다. 따라서, 웹사이트와 API 아키텍쳐들은 서로 다릅니다.

- 웹사이트는 여러 곳을 참조하는 이미지, 가젯, script 들로 구성되어 있습니다.

- API는 그렇지 않습니다. 개발자는 어떤 기능이 최소한의 CALL횟수로 수행되기를 바랍니다.

- 하지만, 서버에서 둘다 구현해서 쓸 수도 있습니다.

사업관점에서도 API 상품설계는 웹과는 다른 전략이 필요합니다. 기능 FUNCTION 중심의 사고에서 데이터 DATA 중심의 사고로 전환되어야 합니다. 웹만들듯이 API를 만들면 망합니다. 사용자가 일반 유저가 아님을 다시한번 기억해야 합니다.

6. 테스트 방법 Testablity이 다릅니다.

web site test를 자동화하기는 매우 힘듭니다. 하지만, API 테스트 자동화는 매우 쉽습니다. 대부분의 API는 쉽게 바꿀수 있어야하고, 호환성을 보장해야 하고, 지속적으로 수행되어야 합니다.

어떻게 이걸 확인할 수 있나?

  - 처음부터 자주자주 테스트해라.

  - 자동화 반복 테스트가 핵심이다.

  - 좋은 API는 이런 것을 쉽게 만들어야 한다.

Testability는 "유지보수의 용이성 maintainability"을 의미합니다. 운영 시에 shutdown없이 몇 개의 모듈만을 떼어내서 테스트하고, deploy할 수 있는가 하는 것은 중요합니다.

Testability는 반드시 설계 시점부터 중요하게 고려되어야 합니다. 끝에 넣으려면 힘듭니다. 시간도 많이 듭니다. Test Code는 그 로직을 아는 개발자가 넣어야 하기 때문입니다.

7. 결론 Conclusion

훌륭한 API는 훌륭한 web site와는 다릅니다. 훌륭한 API란,

 - 빨리 움직여야 한다. 그런다고 앱이 망가지지 않는다.

 - 안정적이고, 신뢰성이 있어야하고, 빨라야 한다.

 - 이해하기 쉽고, 프로그램하기 쉬워야 한다.

 - SECURE해야하고, FAILURE에 대해 회복력이 있어야 한다.

API는 기술적으로도 사업적으로도 웹과 다릅니다. 즉, 개발자들도 새롭게 API 비즈니스를 공부하고 적응해야 한다는 뜻입니다. API는 컨설팅의 영역도 아니고 기획자의 영역도 아닙니다. 그들은 어떻게 해야 API를 이용해서 잘 개발할 수 있는지 모르기 때문입니다.

API는 서비스 개발자의 몫입니다. API를 이용해 직접 애플리케이션을 개발해보십시오. 그러면, 어떻게 API를 만들어야 할지 금방 알게될 것입니다.