오픈API 처음 사용해보다.

이 바닥이 원래 그랬는진 모르겠지만 조그만 회사가 하면 본체만체 하고 구글이나 네이버나 다음같이 빽 있는 회사가 나서면 언론이 알아서 떠들어준다. 큰 회사 하는 일 다 알아야 하는 법칙은 없다지만 이 바닥이 또 남 몰라라 할 순 없다. 싫든 좋든 네이버가 뛰면 같이 뛰어야 하고 덩달아 자칭 타칭 인기 블로거들마저 속보에 질세라 논평을 늘어놓으니 모르려 해도 모를 수 없다. 오픈API만 해도 그렇다. 2007년 7월 현재 국내 사이트 중에서 오픈API를 제공하는 곳은 아무리 뒤져도 열 손가락 채우기도 버겁다. 그래도 이 바닥에서 오픈API 모르면 간첩이다. 구글과 네이버와 다음이 제공하니 말이다. 혹시라도 서점에서 이 책 집어든 사람 중에 오픈API를 모른다면 아마도 책 제목에 낚였거나 혹은 아는 사람 부탁으로 사다 주는 경우일 테다.

오픈API라는 녀석이 쓸만한지 아닌지는 제쳐두고 거대 닷컴이 추진하니 매쉬업이 번창하더라 하고, 웹2.0의 핵심 개념으로도 등장하더니 미래 인터넷 서비스는 오픈API를 이용한 매쉬업 서비스라고 다들 한 목소리다. 정작 써본 사람 얘기는 쏙 들어가고(써본 사람도 별로 없다. 궁금하면 네이버 오픈API 까페를 가보라. 주스는 openapi.naver.com), 아니, 써본 사람이 막상 써보니 별로 할 말도 없고 해서 조용했더니 매쉬업 서비스 한번 안 만들어본 사람들이 남이 별 생각 없이 만든 걸 두고 이리 해석 저리 분석 난리가 이만저만 아니다. 여전히 랭키닷컴 상위200에 매쉬업 사이트는 안 올라오고 매쉬업으로 돈 벌었다는 소리도 좀체 들리지 않는 판에 “머 매쉬업할 거 없어?”하고 두리번두리번거리기가 하루 일과처럼 된 사람도 있나 보다. 따지고 보면 필자도 그랬고 우리 회사도 그랬으니까.

어쨌든 필자도 구글맵으로 매쉬업 한번 해봤다. 이 서비스의 이름은 트라이블(http://www.tryvel.com인데, 디지털카메라로 찍은 원본 사진을 최고 3천장(나중에는 무제한이 되거나 유료화되겠지만 시작은 3천장이었다. 굳이 3천장으로 정한 건 3기가 정도의 무료 용량이 고객에게 최선이고 내부적으로도 수지타산이 맞았기 때문이다… 라고 하는 말은 접대용 멘트고 실은 별 생각 없던 차에 영화 300이 인기 있어서 동그라미 하나 더 붙여 3000으로 정했다. 사장님이 알면 안 되겠지만 CEO, 그들도 알아야 한다. 대부분의 중요한 결정은 지치고 지친 회의 막판에서 ‘그냥 그걸로 하자’로 결정되거나 혹은 별다른 생각 없이 결정하고 뒤늦게 이유를 붙이는 경우가 아주 아주 많다는 것을…)까지 한번에 올릴 수 있는데 이 때 사진에 붙어있는 EXIF(exchangeable image file format)를 이용하여 날짜와 시간 단위로 사진을 배열된다. EXIF에는 카메라 종류, 촬영 일시, 각종 촬영 옵션에 대한 상세 정보가 기록되어 있고, GPS가 달린 디지털카메라로 찍으면 위경도 정보도 포함된다. 어쨌든 사진을 올리면 날짜와 시간을 이용해서 자동으로 배열하는 건 웬만한 데스크탑용 사진 편집 프로그램에 다 있는 기능인데 트라이블은 여기에 시간차를 이용해서 장소에 따라 다시 한번 배열시킨다는 점이 핵심이다.

시간차로 사진을 재배열하는 건 아마도 세계 최초로 필자가 생각해 낸 게 아닌가 싶다(‘아니다! 전에 봤다’하고 열 받지 말고 정말 그랬다면 증거를 출판사로 보내기 바란다). 시간차는 흔히 여행가서 사진을 찍을 때 사람들이 각 장소에서 여러 장을 짧은 시간에 찍고 그 다음 목적지까지는 덜 찍거나 아예 안 찍는 행태를 이용한 것이다. 예컨대 서울 사는 어느 가족이 부산 해운대에 놀러 갈 경우 우선 집에서 몇 장 찍고 KTX역에서 다시 몇 장, 기차에 타서 몇 장, 그리고 죽 안 찍다가 부산KTX역에서 다시 몇 장을 찍는다. 그리고 해운대로 가는 버스 안에서는 거의 안 찍다가 해운대에서 다시 집중적으로 찍는다. 따라서 어떤 사진이든 일단 연속된 2장의 사진은 시간차가 자동으로 생기게 되는데 그게 1초 간격이면 거의 아무런 의미도 없지만 1시간 정도 차이 나면 이 경우 두 사진은 각각 다른 장소에서 찍었다고 볼 수 있다. 집에서 찍은 사진은 각각의 시간차가 10분 이내겠지만 서울KTX역에서 찍은 사진과 부산KTX역에서 찍은 사진은 1시간 이상의 시간차가 나기 때문이다. 이게 잘 이해가 안되면 트라이블에 자신의 여행 사진 원본을 올려보라.

시간차로 사진을 재배열하면서 얻는 이익은 간단하다. 사람들이 사진을 보며 먼저 묻는 말이 “어디서 찍은 거에요?”이듯 일반 상식으로 볼 때 사람들은 장소별로 사진을 분류하고 태깅한다. 그러려면 폴더를 미리 생성한 뒤 해당 사진을 일일이 업로드하거나, 혹은 모든 사진을 펼쳐놓고 일일이 체크박스를 선택해가며 장소별로 구분했어야 했다. 트라이블에선 10분차, 20분차, 1시간차 등의 옵션을 선택하면 이 시간차로 사진을 구분시키고 일단 구분된 사진을 전체 선택하여 동일한 태그를 달 수 있도록 한 서비스다.

그럼 이게 구글맵이란 무슨 상관이 있을까? 이미 짐작했겠지만 사진을 찍은 장소를 구글맵과 연동시키기가 매우 쉬워졌다. 플리커가 구글맵을 사용한 경우는 1)사진을 업로드하거나 이미 업로드된 사진을 선택해서, 2)구글맵의 특정 위치로 드래그앤드롭해서, 3)사진에 관한 태그를 다는 순서다. 또 하나는 위에서 1과 2를 바꾸는 경운데 일단 맵의 특정 위치를 잡은 뒤 사진을 업로드하는 방식이다. 사진과 맵을 이용한 대부분의 사이트는 이 두 가지 UX를 사용한다. 이에 비해 트라이블은 1)사진을 업로드해서, 2)시간차로 구분된 사진을 선택해서, 3)스팟명(특정한 장소의 이름, 예컨대 강남역, 경복궁 등)을 검색해서 선택하는 순서다. 즉 스팟명을 찾지 못하는 경우만 아니라면 실제로 맵을 보는 건 맨 마지막이다. 다른 서비스는 맵 기반에 사진을 얹히는 식이지만, 트라이블은 사진 서비스에 맵뷰(맵으로 사진을 보여주는 페이지)가 옵션으로 붙어 있는 셈이다. 플리커의 핵심은 사진 저장과 공유다. 플리커가 구글맵을 붙인 건 사진을 보여주는 여러 방법 중의 하난데 달력으로 보여줄 수도 있고, 슬라이드로 보여줄 수도 있다. 트라이블도 그래서 달력으로 보기, 슬라이드로 보기, 지도로 보기와 같은 여러 옵션이 있고 그 중에 지도로 보기를 구글맵과 매쉬업한 것이다.

오픈API는 개똥이다. 쓰려면 없다.

얼마 전 읽은 블로그 글에서 “이제는 새로운 컨텐츠를 생산하기보다는 각종 오픈API를 이용해서 매쉬업한 서비스가 인기가 있을 것이다”란 게 있었다. 실제로 이런 사이트가 몇몇 오픈했는데(거의 대부분은 개인이 시험적으로 만들어놓고 방치한 경우다) 그 중 하나가 구글맵과 플리커 사진을 매쉬업한 것이다. 기능은 매우 단순하다. 지도에서 특정 장소를 찍으면 플리커에서 검색해서 보여준다. 자기 컨텐츠는 하나도 없고 오픈API로 제공된 컨텐츠를 섞어놓기만 했다. 필자가 하느님은 아니지만 필자가 보기에 매쉬업의 오류 중 가장 큰 것이 바로 이것이다.

매쉬업은 2개 이상의 서비스, 혹은 컨텐츠, 혹은 플랫폼을 섞은 것이다. 이까지는 아무나 안다. 그런데 2개 이상에서 반드시 하나는 자신만의 서비스여야 하고, 자신만의 서비스가 전체 서비스에서 핵심을 차지해야 한다. 일 테면 플리커와 구글맵 2개만 가지고 백날 붙여 봤자 소용없는 짓이다. 플리커는 사진 서비스를 갖고 있고 이 게 핵심이다. 구글맵이 없어도 잘 나가는 상황에서 구글맵을 붙이니 조금 더 알려진 것밖에 없다. 구글맵을 해킹해서 맨 처음 매쉬업했다는 하우징맵도 원래는 부동산정보사이트였다. 부동산의 위치 정보를 보여주는 옵션 하나로 구글맵을 사용한 것이지 원래부터 어디 다른 곳의 부동산 정보와 구글맵을 합쳐 놓은 것은 아니다. 확신에 차서 얘기하건대 구글맵을 매쉬업했다는 이유로 하우징맵을 방문할 수는 있지만 그 이유로 하우징맵에 가입하지는 않는다.

다시 필자의 경험으로 돌아오자. 대부분의 막 시작하는 사이트처럼 트라이블 역시 컨텐츠가 미약했다. 그렇다고 디지털카메라 원본 사진을 아르바이트를 동원해서 마구잡이로 올려놓을 수 있는 상황도 아니다(첫째는 돈이고 둘째는 도덕이다). 비록 검색이 있긴 하지만 ‘경복궁’으로 검색하면 1장의 사진도 나오지 않았다. 그래서 생각해 낸 것이 네이버와 다음이 제공하는 오픈API를 사용하는 거였다. 트라이블에서 검색을 하면 맨 처음에는 스팟이 검색되고 그 다음에는 사진이, 그리고 마지막엔 동영상이 검색된다. 동영상이 바로 네이버 오픈API를 삽입한 것이다. 처음엔 동영상뿐 아니라 책, 쇼핑, 여행상품, 블로그, 웹사이트 등 다양했다. 그러다 보니 트라이블의 원래 핵심인 사진이 너무 죽어 보이는 게 아닌가. 게다가 검색 몇 번 했더니 사진은 하나도 안 나오니 네이버 짝퉁 된 듯했다. 그래서 동영상만 맨 밑에 놔두고 나머지는 다 뺐다. 일단은 사진이 상당한 수로 모이기 전까지는 괜히 쓸데없이 붙여 넣어서는 아니 되었다.

오픈API 사용하기는 어렵지도 않았다. 흔히 네이버 안티(안티에 별 이유 없듯 네이버 안티도 별 이유 없다)가 하는 말투로 “일일 쿼리 수 제한해 놓고 뭘 사용하라는 거냐! 네이버 또 구색 맞춘다!”고 투덜거릴 것도 없었다. 일일 쿼리 수 엄청나게 날려서 서버 다운시킬 트라이블도 아니고, 그런 사이트도 별로 없으니 말이다(그 정도 트래픽 갖고 있는 사이트는 국내 오픈API를 쓰지도 않는다. 스스로 네이버 경쟁사라 자칭하거나 아니면 쪽팔리거나 둘 중 하나니까. 싸이월드가 네이버 오픈API를 썼다고 해보자. 이건 상상만 해도 끔찍하다.) 구글도 일일 쿼리 수 제한을 두고 있는 판이니 5천 쿼리든 5만 쿼리든 일단 넘어본 사람들이나 얘기하자.

오픈API를 한번이라도 써보려고 한 사람이라면 다 느꼈듯이 이건 개똥이나 마찬가지다. 제법 있는 것 같은데 막상 쓸라치면 없다. 그래도 허벅지를 탁 치며 “앗! 이거 좋다”며 하나 건졌는데 그게 네이버 추천검색어다. 예컨대 검색엔진이 없는 사이트에서는 ‘북경’으로 검색하면 ‘북경’이란 단어가 제목이나 내용, 혹은 태그에 포함되어 있어야 검색된다(검색엔진 있다 해도 시시각각으로 변하는 트랜드를 따라잡기는 빅3 안에 드는 포털이 아니고서는 불가능하다). 그런데 ‘북경’과 표현은 다르지만 의미는 똑 같은 ‘베이징’의 경우는 검색되지 않는다. ‘도쿄’와 ‘동경’, ‘한국’과 ‘대한민국’, ‘디카’와 ‘디지털카메라’도 다 마찬가지다. 궁금하면 디씨인사이드 게시판에서 검색해보라(물론 or 검색으로 해결할 수는 있지만 이건 특허청 같은 공공기관 사이트에서나 하는 거지 상업 사이트가 이러면 욕먹는다). 트라이블도 이 문제가 있었다. 특히 똑 같은 장소를 나타내는 단어가 여러 개다 보니 같은 장소에서 찍은 사진이 검색어에 따라 다르게 검색되었다. 그래서 네이버 추천검색어가 확 와 닿았다. 지금 트라이블에서 ‘북경’으로 검색하면 “이런 검색어는 어때요?” 다음에 ‘베이징’, ‘중국’을 표시해 주고 각각에 검색 링크가 걸려있는데 이게 네이버의 추천검색어API를 이용한 것이다. 추천컨대 쓰기도 별로 어렵지 않고 나름대로 잘 추천해주는 편이니 한번 사용해 보면 좋겠다. 이건 비단 검색에만 쓰는 건 아니다. 태그를 쓸 때 요즘 자동완성은 기본인데 이 때도 추천 검색어를 사용하면 좋다. 태터툴즈를 많이들 사용할 텐데 태터툴즈의 태그 입력도 기본적으로 단어 매칭이다. 여기서도 ‘북경’을 입력하면 ‘북경’이 포함된 추천 태그만 자동완성되는데 이 때 추천검색어API를 이용해서 ‘베이징’, ‘중국’도 태깅시키면 훨 낫다.

가끔은 거침없이 매쉬업

2007년초에 다음과 네이버가 공동주최한 “2007 대한민국 매쉬업 경진대회(http://mashupkorea.org)”에 필자도 출품한 적이 있다. 서비스명은 가계부로그였는데 비록 예선도 못 올랐지만 개념은 이러했다. 가계부를 쓰는 화면은 글쓰기 화면 하나뿐인데 여기에 글을 쓰면 띄어쓰기를 기준으로 각 단어마다 자동으로 네이버와 다음의 오픈API로 쿼리를 날린다. 그래서 매칭되는 것을 자동완성으로 보여주고 이를 선택하거나 아니면 계속 글을 써나가면 된다. 선택할 경우는 당연히 링크를 걸어주고 이 단어를 태그에 올린다. 사진의 경우도 가능했는데 사진을 선택하면 해당 사진을 화면에 출력시키게 된다. 예컨대 “맥도날드에서 불고기버거 5천원”이라고 쓰면 ‘맥도날드’를 쿼리로 보내서 상호명과 일치하면 매장별로 리스팅시켜 자동완성시킨 뒤에 유저가 선택하면 링크를 네이버 지도의 해당 위치로 걸어줬다. 비슷한 방식으로 ‘불고기버거’도 검색하는데 사진을 선택하면 ‘불고기버거’ 사진이 출력된다. 필자가 직접 만들다보니 버그도 많고 이래저래 개념도 이해하기 어려웠던 탓에 예선에서 물 먹은 걸까? 다소 억울하긴 하지만 대상을 차지한 “거침없이 글짓기”를 보면 그래도 제대로 심사한 듯하다.(그래도 하도 답답해서 여기 적자면 이렇다. 예선 심사위원이 8명이었는데 그 중 3명만이 필자가 출품한 서비스를 사용해봤다. 사실 어느 서비스든 처음 이용하면 이해도 안되고 해서 헤매기 마련인데 그래도 겨우 한 두 단어 찍어보고 심사를 끝내는 게 아닌가. 필자가 각 파일마다 로그분석기를 다 달아놨고, 첫화면에서 심사자들마다 개별 아이디를 다 부여했기 때문에 알아낸 사실이다. 물론 심사자들은 이 사실을 몰랐겠지만… 그렇다고 심사를 영 안한 것도 아니고, 필자 역시 네이버 못 들어가는 찌질이패에 끼고 싶지도 않다. 이 바닥이 원래 그런 게 있다. 2~3년차 이상치고 이 바닥에서 하늘 우러러 한 점 부끄럼 없을 사람 없을 게다)

어쨌든 대상작은 필자가 보기에도 대상감이다. 영작 도우미 프로그램이라고 칭하던데 개념은 이렇다. 영작을 한 후에 검사 버튼을 누르면 단어나 문장을 구글 검색API로 쿼리를 날려서 얼마나 많은 결과가 리턴 되는지 보여주는 것이다. 중요한 것은 그 결과인데, 사용자가 쓴 단어나 문장, 혹은 표현 방식이 실제로 얼마나 많이 사용되는지 알 수 있다는 것이다. 단어 철자 교정이 되는 건 당연한데 이는 둘째치고 사용자로 하여금 제대로 영작하고 있는지를 알 수 있게 했다는 점에서 참으로 놀라운 아이디어다. 보통의 생각으로는 내가 사용한 단어의 철자가 맞는지 틀린지 알려주는 정도밖에 못할 텐데(‘true냐 false냐’와 같다. 흔히 하듯 검색 결과가 있으면 보여주고 없으면 마는 식이다), 이건 문장 표현 자체가 얼마나 쓰이는지 알 수 있게 했다는 점에서 보통을 뛰어넘는다(‘how many’와 같다. 결과 자체가 의미를 담고 있고, 사용자가 의미를 재해석할 수 있으니 말이다).

단순히 보여주는 방식을 플래시로 멋있게 하는 건 매쉬업이라 할 수 없다. 구글맵에 사진 갖다 붙이는 것도 매쉬업이라 하기는 모자라다. 컨텐츠와 UI의 조합으로 전보다 쉽게 보이도록 하는 것도 매쉬업은 아니다. 모름지기 매쉬업은 UI에 관계없이 컨텐츠와 컨텐츠가 만나서 새로운 가치를 창조해야 하는 것이다. 마치 댓글이 원래의 텍스트와 만나서 새로운 가치를 제공하듯이 말이다. “거침없이 글짓기”는 화려한 플래시도, 정교한 구글맵도, 어려운 UI를 개선한 것도 아닌데 대상을 차지했다. 그럴 만하고 따라할 만하다.

필자의 자랑 같기도 하고 뻥치는 것 같기도 하지만 트라이블에서도 제대로 된 매쉬업 하나 해보려 했다. 만드는 건 어렵지 않는데 이래 저래 다른 일로 못했었다. 굳이 이름을 붙이자면 ‘자동 루트 추천’이다. 필자가 2005년에 6개월간 육로로 터키까지 간 적이 있다. 여행 중에 매번 고민하는 것 중 하나가 “여기 다음에는 어디를 갈까”였다. 패키지나 일정이 확정된 여행은 이런 고민할 이유 없지만 유럽 배낭여행이나 1년짜리 세계여행, 혹은 자유여행처럼 일정이나 루트가 미확정된 경우는 다음에 이동할 장소(보통은 관광지나 도시)를 선택하느라 고민하지 않을 수 없다. 대부분은 현지에서 다른 여행자나 게스트하우스 직원, 혹은 가이드북을 보고 결정하곤 하는데 이 것을 트라이블에 적용해 보려고 하는 것이다. 개념은 이렇다. 검색창에 현재 장소를 쓰고 ‘루트 검색’을 클릭하면 네이버의 블로그API나 다음의 까페API를 검색한다. 그 결과 중에서 내용 부분을 파싱하여 다른 장소 이름을 찾아낸다. 물론 그 전에 어떤 것이 장소를 나타내는 단어인지 알기 위해서는 지역정보API로 한번 더 거르거나 자체 장소 데이터가 있어야 된다. 그리고 그 결과를 검색 결과수에 따라 순위를 매긴다. 예컨대 현재 장소가 ‘에펠탑’이라면 그 결과로 세느강 다리, 루브르박물관, 오르세미술관, 사이요궁 등의 장소가 검색되는데 이것을 순위로 매기면 가장 많이 검색된 장소가 에펠탑 가기 전의 장소, 혹은 에펠탑 다음 장소일 확률이 높아진다.

일단 여기서 말이 안 되거나 이해가 안 되는 부분을 해결하자. 첫째, 검색된 내용이 모든 글이 아니라 한두 문장이니 정확한 검색은 불가능하다는 점. 이건 오히려 낫다. 대부분의 사람들이 여행기를 쓸 때는 한 문장에 두 장소 이름을 쓰는 경우가 많다. 예컨대 “꽃소년도 너무나 공감을 하여 곧바로 에펠탑을 내려와 택시를 잡아타고 샹젤리제로 날아가 퀵버거에 가서 스파이더맨 버거를 사먹었다”, “친구는 에펠탑을 올라가기 위해 줄을 서고 나는 예전에 한번 올라가봤으므로 주변을 산책하기로 한다. 에펠탑 앞의 다리를 건너 센강을 따라 위로 올라가는데 저 멀리 파리 자유의 여신상이...”(이상은 실제 네이버에서 블로그 검색한 결과다)처럼 말이다. 그래서 불필요하게 많은 내용 전체를 다 검색하느라 서버 터지게 하지 않아도 된다. 그래도 아쉬운 건 맞다. 이왕이면 다 검색하는 게 당연히 더 낫다. 둘째, 검색된 장소가 반드시 현재 장소와 관련 있지는 않다. 그렇다. 너무도 당연한 얘기다. 그래서 궁리 끝에 나온 결론은 블로그API를 사용하는 것이다. 웹페이지나 까페와는 달리 블로그는 비교적 여행기 성격이 강하다. 여행기만 따로 등록된 게시판을 오픈API로 제공한다면 더 정확한 결과를 얻을 수 있겠는데 아직은 없으니 울며 겨자 먹기다. 셋째, 두 장소가 서로 연관이 높다고 해서 반드시 추천 루트로 볼 수는 없고 게다가 어느 장소가 처음인지 알 수 있는 방법이 없다. 그렇다. 그래서 못했다!

매쉬업 좀 해주세요.

매쉬업을 우습게 보면 별 거 아닌 서비스 나오거나 혹은 필자처럼 구상만 하고 실천은 못하게 된다.. “요즘 매쉬업이 유행이라는데 오픈API 한두 개 써보자”고 접근했다가는 실무자만 고생고생 시키고 끝에 가선 안 하니만 못하게 되고 왜 했나 싶어 진다. 아무리 웹2.0 시대라 해도 생각 없이 따라 하다간 큰 코 다치는 법이다. 그러기 위해선 처음부터 매쉬업을 이용하는 수준을 명확히 해야 한다. 현재 서비스에서 추가되는 옵션으로 만들 건지, 아니면 신규사업 수준의 새로운 가치를 만들 것인지 분명하게 해야 한다. 그저 주는 대로 받아 먹으면 체한다.

옵션은 옵션일 뿐이다. 요즘도 기사 한 줄 나가려고 아무도 안 쓰는 매쉬업 해놓고 자화자찬 자랑하는 사이트 많다. 이건 그나마 낫다. 최소한 매쉬업하는 사이트는 중소 닷컴(영세 닷컴이라 하려다가 누워 침 뱉기 같아서 ‘중소’로 대신한다)이니 이런 걸로라도 기사 나가야 된다. 신규사업 수준으로 매쉬업하는 경우도 불안하긴 마찬가지다. 앞서 얘기했던 5천 쿼리 5만 쿼리는 둘째치고 매쉬업 사이트가 잘 나가면 나중에 API를 제공한 데서 딴지나 걸지 않을까, 공짜 API 사용하니 지네들 돈 없다고 서버 줄여서 로딩 속도 느려지면 누구 탓할까, 괜히 남의 것 쓰다가 저작권이네 음란물 사용이네 걸리면 서비스 접어야 되지 않을까 하는 불안은 떨칠 수 없다. 필자가 사용했던 구글맵이라고 별 수 없다. 지금은 돈 많지만 닷컴 바닥이 1년 앞도 못 내다보는 업종 아닌가.

그래도 오픈API를 제공하는 사이트는 “제발 매쉬업 좀 해주세요”한다. 트라이블도 오픈API를 만들어 제공하고 있는데 고객을 위한다거나 웹2.0에 대응한다거나 인터넷 업계의 발전을 위한다거나 하는 건 순 거짓말이고 100% 마케팅 때문이다. 서비스는 오픈했는데 마케팅 비용이 적으니 유행에 붙어가는 게 정석이다. 오픈API로 태터툴즈 플러그인도 만들었으니 할 말 다했다. 그런데 생각해 보니 이거 참 아이러니하다. 오픈API를 이용하면서 동시에 오픈API를 내보낸다. 가져오는 입장이기도 하고 내보내는 입장이기도 하다. 그런데 화장실 갈 때 나올 때 다르다고 하더니 딱 이런 심정이다. 남의 오픈API 쓰면서 이래저래 투덜거렸는데 우리 API를 쓰는 고객도 똑같지 않을까? 그래서 일단은 쿼리 제한을 없앴고 불필요한 정보 입력도 없앴다. 그래도 여전히 남는 건 누가 우리를 믿어줄까 하는 문제다. 겨우 20명밖에 안 되고 창업 1년도 안되고 자본금도 적은 회사의 API를 대체 누가 써줄까? 판도라TV가 동영상API를 제공하기 시작했지만 그나마 거긴 이름이라도 있지 우리는(‘컨텐츠플래닛’이다) 아무도 모른다. 사정이 이럴진대 우리처럼 일단 API 열어놓고 남 몰라라 하는 닷컴도 많다. 쓰면 좋고 안 쓰면 그만인 셈이다.

어떻게 해야 오픈API를 많이 이용하게 할까? 일단은 뭐가 있는지부터 알아야겠다. 웹2.0 허브 사이트는 국내에도 몇 개 있지만 오픈API 허브 사이트는 하나도 없다(외국에는 몇 개 있다). 필자가 만들어보려고 했지만 실상 오픈API를 제공하는 국내 사이트도 별로 없으니 만들 것도 없었다. 위에서 안 나온 곳 중에는 투어익스프레스의 여행API나 알라딘의 책API가 필자가 찾은 대부분이다(나머지는 어떤 사이튼지도 모르니 API 사용하지도 않을 거다). 어쨌든 온라인에서는 잘 알 수 없으니(이럴 땐 당황스럽다) 다음과 네이버는 매쉬업 경진대회를 열었다. 돈도 주고 취직할 때 점수도 높여준다. 이것으로도 부족해서 개발자들이 개발 관련 컨퍼런스마다 찾아 다니며 자기 회사의 오픈API를 소개하고 다닌다. 심지어 다양한 예도 직접 만들어서 소개하고 강의도 다니고 캠프도 연다. 세상에! 포털의 개발자들이 이렇게 열심이었던 적이 있었던가?

아무튼 이런 저런 상황을 보고 막상 실무에서 직접 뛰어보면서 얻은 결론은 이렇다. 첫째, 기획자나 마케터를 상대로 오픈API를 소개한다. 개발자한텐 백날 얘기해도 소용없다. 개발자가 아이디어를 내고 프로젝트를 이끄는 경우가 거의 없다시피 한 우리나라 닷컴에선 아무리 기술 가르쳐줘도 못하는 건 못하는 거다. 그러니 기획자나 마케터에게 실질적인 이익을 알려주는 편이 낫다. 매쉬업을 직접 만드는 사람은 개발자지만, 매쉬업을 할 것인지, 만약 한다면 어떻게 할 것인지를 결정하는 사람은 대부분 기획자나 마케터고, 이들은 서비스에 도움이 되거나 혹은 한 명이라도 더 많은 회원을 확보할 수 있다면 마다 않는다. 더 나은 사람을 원한다면 당연히 CEO다. CEO끼리 얘기하는 게 가장 속 편하다.

둘째, 개발자에게 소개할 때는 UI API도 같이 제공한다. UI API는 구글이나 야후, 요즘엔 네이버에서도 제공한다. 이와 똑같지는 않지만 오픈API를 실제 적용할 때 UI나 디자인을 쉽게 개발하여 적용할 수 있는 수준까지는 줘야 한다. 현장에서 뛰어본 사람은 다 알겠지만 개발자들, UI개발하는 거 여간 귀찮아하는 사람들이 아니다. 디자인은 거의 죽음이다. 그러니 안 하던 공부하면서 XML 파싱도 하고 AJAX도 썼지만 막상 모양을 만드려니 UI와 디자인에서 턱 걸려 버린다. 대부분이 그렇듯 여기서 그러고 만다. 팀장이나 동료에게 보여주기도 민망하다. 그저 연습 한번 했다 셈치고 마는 것이다. 앞에서 우리나라에선 개발자가 프로젝트를 이끄는 경우가 거의 없다고 했는데, 이 경우도 마찬가지다. 기획자와 디자이너를 휘두르는 사람이 개발자인 적은 내 경험으로도 한번도 없었고 여러분도 마찬가지일 게다. 물론 SI는 틀리지만.

셋째, 괜찮은 웹사이트를 운영하는 곳엔 직접 어플리케이션 수준(UI나 디자인이 완료된 수준, 해당 웹사이트에 커스터마이징되어야 할 게다)까지 만들어준다. 네이버나 다음이야 자존심이 있으니 ‘을’이 되고 싶진 않을 테고, 나머진 일단 허리 굽혀서 들어가야 된다. 자신의 오픈API가 가장 괜찮게 활용될 수 있는 서비스를 찾아서 직접 제안하고 만들어준다. CEO가 열심히 아는 사람 통해서 공짜 배너 자리 구해 오는 것처럼 실무자들도 개발 샘플만 만들어놓을 게 아니라 특정 사이트를 골라서 거기에 맞게 만들어서 제안해야 한다.

넷째, 인터넷에서 벗어나서 다양한 분야에 적용한다. 오픈API를 제공하는 닷컴은 기본적으로 컨텐츠를 보유하고 있다. 예컨대 설치형 인트라넷 프로그램에도 주소록 같은 것은 네이버 지도와 연동시킬 수 있다. 대학교 도서관의 도서 목록에 알라딘 책 이미지를 넣을 수도 있다. 지하철 광고용 TV에 최신 동영상을 넣어줄 수도 있다. 차량용 네비게이션 지도 위에 그 장소의 사진을 보여줄 수도 있다. 하려고 마음만 먹으면 한둘이 아니다. 굳이 인터넷만 붙잡고 있을 필요도 없고 오픈API를 XML로만 보내야 된다고 범위를 축소시킬 필요도 없다. 어차피 컨텐츠를 밖으로 보내주는 것이니 그 형태는 중요하지 않다. 필자는 해외여행자가 PMP나 UMPC를 갖고 갈 경우 트라이블 서비스 자체를 넣어보려고 했다. 인터넷이 안 되어도 데이터 검색이 가능하고, 생산된 데이터는 인터넷 연결이 될 경우 싱크를 맞춰주고 반대로 디바이스에 들어 있지 않는 정보는 여행지 PC방에서 ZIP파일로 다운받을 수 있도록 하는 식이었다. 물론 요즘의 매쉬업 수준을 보면 이까지 오려면 한두 해도 짧다.

다섯째, 오픈API에 대한 기대 수준을 낮춘다. 사이트를 기획하고 개발하고 디자인하면서 수십 번도 넘게 ‘핵심’을 찾아 헤매지만 그 어떤 경우에도 오픈API가 핵심으로 등장한 적은 없다. 다만 다양한 마케팅 전술 중 하나로 얘기가 오가는 경우가 다다(전략 단계에서도 오가긴 한다. 허나 하도 허무맹랑하고 공허해서 여기 옮기기도 싫다). 그런데 수준은 참 높이도 잡는다. 서비스 전반에 걸쳐 그 어느 것 하나 웹2.0스럽지 않다 해도 오픈API 하나만 제공하면 단번에 웹2.0 사이트가 되는 걸로 착각한다. 정작 본인들이 만든 오픈API지만 본인들도 매쉬업 못하는 걸 누가 더 잘할 수 있을까?

P.S.

이렇게 써놓고 다시 읽어보니 내가 썼지만 참 암울하다. 그래서 하라는 건지 말라는 건지 웹2.0만큼이나 나도 가물가물하다. 일은 많이 하라면서 기대 수준은 낮추라니 이런 어불성설이 어딨나. 결론도 다섯 가지나 짜냈지만 필자더러 다시 해보라 그러면 난감하다. 그래도 이해할 사람은 이해하겠지만, 다만 웹2.0 제대로 이해 못한 CEO가 이 거 읽고 실무자들 고생시킬까 싶어 염려된다. 웹2.0만으로도 족하다.

이올린에 북마크하기(0) 이올린에 추천하기(0)