갑자기 이런 생각이 들었다. 업체들은 왜 오픈 API를 이용할 까? 그리고 왜 사용할까?

기존의 응용 프로그램을 개발할 때 라이브러리에서 제공하는 다양한 API를 사용한다. 클라이언트측의 사용자 인터페이스도 구현하고 서버측에서 데이타의 생성,수정, 삭제 등을 위한 로직과 비지니스 로직을 개발한다. 윈도우의 개발시 사용하던  MFC나 WPF 등이 이에 해당된다. 이 때 사용하는 API는 오픈 API가 아니다.

그렇다면 오픈 API가 무엇일까? 위키를 검색해 보면 다음과 같이 말하고 있다.

Open API (often referred to as OpenAPI) is a word used to describe sets of technologies that enable websites to interact with each other by using SOAP, Javascript and other web technologies

오픈 API와 이를 이용하여 개발된 메쉬업 응용을 주로 다루는 프로그래머블웹 사이트를 보면 총 949개의 오픈API가 존재하고 있고 이중 REST 방식은 587개 , SOAP 방식이 215개로 주를 이루고 있다. 과연 업체들은 오픈 API를 통해 무엇을 얻으려는 것일까?  일반적으로 업체들은 오픈 API를 통해 개발자들을 중심으로 한 생태계를 구성하고 이를 통해 보다 창의적인 서비스를 개발하고 그 세를 확산하는 데 목적이 있다고 한다.

그렇다면 사용자들은 과연 오픈 API를 통해 무엇을 원할까? 가장 크게는 서비스를 통해 데이타를 얻길 원하며 다음으로는 서비스 그 차체이다. 사용자는 오픈API를 통해 웹 클라우드에 있는 개인 정보나 플리커 사진처럼 공유 가능한 정보 또는 구글 맵이나 야후 맵처럼 원하는 주소를 이미지맵으로 매팅시킨 맵데이타를 원한다. 다음의 표를 보면 사용자들에게 가장 인기있는 오픈API들이 맵이나 사진 , 동영상, 상품 및 가격 정보 , 검색 결과 등을 얻길 원하는 것임을 알 수 있다. ( 아마존의 경우  S3나 EC2 등의 클라우드 컴퓨팅의  API보다 상품 정보를 제공하는 API가 주로 사용된다. )


웹2.0을 설명하는 가장 적합한 키워드는 자발적 참여와 공유이다. 오픈API는 참여와 공유를 위한 가장 적극적인 방법이라 할 수 있다.

그렇다면 자발적 참여와 공유가 수반되지 않는 오픈API가 존재할 수 있을까?
몇년 전 웹 서비스 기술을 이용해서 민간과 정부에서 활용할 수 있는 웹 서비스를 국가 차원에서 모아 등록한 후 공유하기 위한 거대한(?) 목적에 의해 추진된 프로젝트인 국가 웹 서비스 등록 저장소에 접속해 보았다.


한참 SOA, 웹 서비스라는 것이 유행처럼 번지던 시기에 만들어진 서비스로 기억된다. 개인적으로 무척 창의적이고 진보적인 프로젝트였다고 생각한다. 그런데 결과론적으로 많은 예산을 투자하고 개발된 이 서비스는 현재 149개의 정부 관련 기관 서비스를 공개하고 있다. 이들 서비스를 이용하여 매쉬업된 응용 서비스를 아직까지 소개된 적이 없다.

왜 이 서비스는 활성화되지 못한 것일까? 먼저 정부 관련 기관들의 자발적 참여와 공유가 부족한데서 그 원인을 찾을 수 있을 것이다. 경찰청의 치안 정보와 교통 정보 그리고 여기저기 설치되어 있는 카메라를 제어할 수 있는 API를 공개하고 이를 구글맵과 연동하여 24시간 방범 시스템을 만들어 보면 어떨까!  현재 프로그래머블웹에서 정부 기관에서 제공하는 오픈 API와 이를 통해 개발된 매쉬업을 검색해 보면 많은 생각을 하게 한다.

결론적으로 오픈 API는 기술이 아니라 참여와 공유를 위한 웹 문화이다. 내가 제공하는 가치 있는 서비스를 사용자들이 원하는 형태로 다양하게 이용할 수 있도록 공개하고 이를 통해 공유하는 것이다. 역설적으로 말하면 가치 있는 서비스를 제공하지 못한다면 오픈API도 의미가 없다고 말할 수 있다.

웹 서비스를 이용할 때 항상 첨부 파일은 큰 골치덩이가 아닐 수 없습니다. 더구나 HWP나 오피스 파일을 만날 때 뷰어가 설치되어 있지 않다면 더욱 그러합니다. 번거롭더라도 다운로드를 받고  해당 뷰어를 설치하고  문서를  조회해야 합니다.  이러한 번거로움은  메일 서비스를 이용하거나 위키나 게시판 등에 업로드된 오피스 문서의 경우에 빈번히 발생합니다. 이러한 불편함을 없애는 방법을 소개하고자 합니다.

사례1 , 짐브라(Zimbra)의 오피스 첨부 파일 보기
짐브라는 Ajax  기반의 메세징 회사입니다. 야후의 인수로 인해 널리 알려졌습니다. 짐브라는 특히 아웃룩의 Aajx  버전(을 제공하는 데 무척 쓸만합니다. 씽크프리에서도 내부 웹 메일로 사용중이고 여러 나라의 ISP 들을 통해 널리 사용되고 있습니다. 그런데 짐브라를 이용할 때 오피스 첨부 파일을 앞서 설명드린 것처럼 뷰잉시 골치거리입니다.  그런데 이를 Arkasoftf 에서 씽크프리의 뷰어를 이용하여 이 문제를 해결했습니다.

아래 화면은 짐브라의 웹 메일의 첫화면입니다. 아웃룩과 거의 유사합니다. 사용자가 오피스 문서를 첨부 메일로 받은 경우 , 해당 메일을 끌어서 왼쪽 하단의 Zimlet에 있는 ThinkFree 에 놓으면 별도의 뷰어없이 해당 오피스 파일을 조회해 볼 수 있습니다.
참고로 Zimlet은 짐브라의 오픈 플랫폼으로 외부 개발자들에게 추가 기능을 개발하게 해주는 플랫폼입니다.  그 결과 , 아래와 같이 실시간에 해당 오피스 문서를 씽크프리의 뷰어의 오픈 API를 이용하여 SWF 파일로 변환한 후 뷰잉하거나 심지어 슬라이드 쇼를 수행할 수도 있습니다.


사례2. 마인드터치의  Deki Wiki에서 오피스 첨부 파일 처리하기
국내에서는 아직 위키가 널리 보급되지 않았지만 미국 등 외국에서는 지식 공유 프레임웍으로 엔터플라이즈 위키라 널리 사용되고 있습니다. 이들 엔터프리이즈 위키 솔루션중 DekiWiki는 마인드터치사의 제품입니다.  DekiWiki도 웹에서 위키 페이지에 업로드된 오피스 파일을 웹에서 아래와 같이 손쉽게 처리하고 있습니다.

아래 화면은  DekiWiki의 My New Page 화면입니다. 해당 화면을 보면 첨부된 오피스 파일을 보실 수 있습니다. 해당 파일의 오른쪽 끝을 보면  Preview 라는 버튼을 클릭하면,
아래와 같이 별도의 플러그-인 프로그램이나 로컬 컴퓨터상에 오피스 프로그램을 설치하지 않고도 해당 문서를 조회할 수 있습니다.


위의 화면은 자바 뷰어인데 왼쪽의 버튼을 눌러 바로 슬라이드 쇼 기능들을 실행할 수도 있습니다.

물론 오피스 문서의 뷰잉외에도 직접 편집을 할 수도 있습니다. 아직 편집  API는 공개되지 않았지만 조만간 공개될 예정입니다. 실제, 이들 사례외에도 이미 국내에서는 네이버 웹 메일에서 오피스 파일의 미리 보기 기능을 이용하실 수 있습니다.

국내의 경우에도 정부 기관이나 금융권 사이트 등에 가보면  HWP나 오피스 문서 등이 첨부로 제공되는 경우가 많습니다. 또한 메신저들을 통해 오피스 문서를 교환하는 경우도 허다합니다. 각종 커뮤니티에도 수많은 첨부문서가 있습니다. 이런 경우 위와 같이 서비스를 제공하면 얼마나 편할지요! 서비스 업체 입장에서도 해당 오피스 문서를 웹 문서로 변환하면 광고 등 새로운 수익공간을 만들어 내는 기획를 얻을 수도 있습니다. 씽크프리 뷰어 API로 위의 작업을 할 경우 하마 국내 개발자의 경우 1주면 충분히 위와 같은 서비스를 구현할 수 있을 겁니다. ^-^ 추석 연휴가 오늘로서 끝나네요. 남은 연휴 잘 보네세요. 저는 에이콘 출판사에 보내 준 "신기술 성공의 법칙"이란 책을 마무리 해야 할 것 같습니다. 행복한 추석 연휴되세요.