RSS

카테고리 보관물: 앱개발

웹사이트의 데이터를 API로~! kimonolabs 소개

업데이트: 2016년 2월 29일을 기점으로 kimonolabs는 서비스를 종료한다고 합니다. 이러한 B2C형태의 API서비스들이 수익모델을 찾지 못하고 서비스를 접게 되는 것은 어떤 의미가 있을까요? 종료 안내 문 링크: https://www.kimonolabs.com

오늘 페이스북에 쓴 글입니다.

얼마전 소개한 적이 있는 kimonolabs의 웹사이트에서 API를 만들어주는 기능을 사용해 봤습니다. 서울시의 25개 구의 대기오염물질의 수치를 알려주고, 종합점수격인 CAI 지표를 출력해주고 상태도 표시해주는 API입니다.

처음 만들었는데, 만드는데 5분도 안걸렸습니다.

http://www.kimonolabs.com/api/7lcmxa14?apikey=0d7e77d3f256eb9502dc9d046b1c6d13

여기 가서 회원가입하고 써보세요. http://www.kimonolabs.com/
베타 기간 중에는 PRO로 모든 기능을 써볼 수 있도록 풀어져 있네요.
이메일로 보내는 기능도 있어서 IFTTT랑 연동하면 특정 조건일 때 다른 행동을 프로그래밍 해볼 수 있을 거 같아요.

요약하면, kimonolabs를 이용하면, 매우 적은 시간으로 웹사이트의 데이터를 기계들이 이해하기 쉬운 정형화된 데이터로 API를 만들어준다는 것입니다.. API는 매우 유연하여, 모바일 앱이나 다른 웹사이트에서 활용하기 쉬운데요. 예를 들어 보면,

서울특별시 대기환경정보 사이트가 있습니다. 시민들이 쉽게 자기 지역의 대기환경정보를 쉽게 볼 수 있도록 다음과 같은 표를 보여주고 있습니다. 다른 공공기관의 데이타들도 형편이 비슷합니다.

2014-03-09 18_00_39-도시대기측정소 측정소별 실시간 오염도 _ 서울특별시 기후대기환경정보

사람들이 읽기 좋게 표에 색상도 넣고 아름답게 구성을 해두었습니다. 하지만 웹사이트 어디에도 기계가 읽기 쉽게 정형화 되어 있는 데이터 API는 찾을 수가 없어 아쉬움이 남는군요. 이럴 때 kimonolabs를 이용하면 JSON 포멧으로 데이터를 뽑아 줍니다. 이런 형태로 보여주는 것이죠.

웹사이트 갱신 주기에 따라서, 비가 오나 눈이 오나 1시간에 한번씩 이 웹사이트에 들어와서 데이터를 읽고나서 JSON으로 변환시켜서 제공해주고 있습니다. 웹사이트가 크게 변화하지 않는 이상 계속 이 API는 유지될 것입니다.

간단히 사용법을 녹화해봤습니다.

공공데이터를 API화 시켜서 여기 공개해주세요.

https://docs.google.com/spreadsheet/ccc?key=0AnpyfRYyrkgzdDQyWjY5T3JRdzFNOWRCdWh2bHQ3V3c&usp=sharing

Happy Coding!

Advertisements
 
댓글 2개

게시자: 켬 2014년 3월 9일 in API Design, 공공정보, 앱개발, OpenAPI

 

태그: ,

2013년 이거 하나 건졌네요.

오늘 이야기 해보려는 것은 ‘성과’입니다. 요즘 회사에서 평가시즌이라서 성과에 대해 민감하죠. 목표를 설정하고 거기까지 해내면 B, 그 이상을 해내면 A 이런 식인데요. 지난 해, 개발자로서의 제 성과는 뭐가 있을까 돌아 보았어요. 회사에서는 관리자로 자리매임하고 있기에 회사 밖에서의 개발자로의 활동에 관한 것이죠.

LightPod라는 앱이 가장 기억에 남아요. 작년 여름 즈음부터 함께 모여 공부하던 html5 platform study 멤버들과 고민하면서 tizen app challenge에 도전해보려는 생각으로 기획했던 앱이지요. tizen os는 아직 상용으로 출시전이라서 앱이 사실상 전무합니다. 당연히 podcast앱도 제대로 된게 없을 것이라 생각해서 가벼운 팟캐스트 클라이언트를 만들어 보자는 취지로 lightweight + podcast 해서 lightpod라고 명명했어요.

기능은 정말 단순합니다. 세계 22개국의 apple podcast ranking 정보를 긁어와서, rss feed로 팟캐스트를 채널을 보여주고, html5의 audio tag를 이용해서 재생해주는게 다입니다. jquery mobile을 이용해서 ui를 구성했고, 백엔드는 baas.io에 ruby로 데이터를 밀어 넣었어요.

jquery mobile로 처음 앱을 만들어 보는 거라서, 시간이 많이 걸렸고, 품질은 좋게 나오지 못했지요. ^^;

디자인은 한국앱개발산업협동조합 예비모임의 김영학님께서 도움주셨고, 리뷰가 길어진 덕분에 제시간에 스토어 등록은 실패해서 app challenge에 나가진 못했지만, 완성했다는 측면에서 기분 좋은 앱입니다.

특히, ruby 송년 모임에 나가서 itunes crawling을 위한 짝코딩을 했었는데 함께한 ruby korea 심상용님이 발군의 실력으로 도와주셔서 아주 진도가 잘 나갔습니다.

그렇게 해서 나온 앱 스크린샷 좀 찍어 봤습니다.

tizen-2014-01-04-064724

플레이어 화면이에요. UI참 단순하지요. 레코드 판이 돌아가듯이 빙글빙글 돕니다. tizen os가 올해 성장한다면 이 앱도 함께 성장할 수 있으리라 기대하고 있습니다.

이 단순한 앱 만들기 위해 얼마나 많은 밤을 코드를 보면서 지새웠는지 생각해보면 제 실력이 짐작가시죠? 하지만 결국 마무리를 했어요. 그래서 참 기쁩니다. 2013년도 이 앱하나 만들고 그만입니다.

이 앱만든 것 외에 2013년도 제 개발인생에서 중요한 투자로 꼽으라면, 한국앱개발산업협동조합 설립을 위해서 발기인으로 활동해온 거에요. 결국 해를 넘기고 설립하지 못했습니다. 맘에 맞는 발기인 다섯을 모으는 게 이렇게 어렵네요. 앱 개발에 관련된 직업을 가진 사람들을 모두 연대해보자는 생각이었는데, 실체가 없다는 비판을 많이 받았어요. 동호회 수준이라는 평가도 있었고… 올해 다시 정관을 손보고 다시 동참할 수 있는 사람들을 찾아봐야겠지요.

끝으로 2014년도를 기대해봅니다. 이대귀 대학 동문의 페이스북 글귀 중에 설교자가 매주 영혼을 울리는 설교를 준비하는 성실함을 본보기 삼아서 자신은 매주 뭔가를 해보겠다는 포부같은 것이었는데, 그 태도가 제게도 성실하게  앱을 개발해낼 수 있다면 어떨까하는 아이디어를 줬어요. 매주? 작년 내내 겨우 하나 만들었는데 가당치 않습니다. 하지만 한 번 도전 해보려고요. 몇 년전에 100LoC를 실천해보겠다는 의지를 불태운 적이 있었는데요. 작심삼일이 되었지만 올해는 취미 앱개발에 더 정진해볼까 다짐해봅니다. 이 다짐에 기름을 붓기 위해서 공유라는 주제로 앱 개발을 해볼까 합니다. 몇개의 앱이 나올지 그게 중요한 것은 아닌데, 쾌속개발을 실천할 수 있는 코딩 감각을 유지할 수 있다면 행복할 거 같아요.

주제도 엉성하고, 깊이도 없는 글이지만, 제 블로그에 와서 글을 읽으시는 여러분들께 새해 복 많이 받으시고 의미있는 한 해 보내시길 기원드립니다.

간만에 마다가스카르에서 최피디였습니다.

 
댓글 3개

게시자: 켬 2014년 1월 4일 in 100LoC, Agile, baas.io, 앱개발, Web app

 

공공 데이터 긁어 오기

예전부터 만들고 싶었던, 착한 가게를 소개하는 sns앱에 대해서 진지하게 고민하기 시작한 지, 오늘로 삼일째. 추석 연휴를 보내고 목요일 근무가 제대로 될 리 없었던 차에, 퇴근 직전에 착한 가격 업소를 정부에서 관리하고 있다는 것을 검색을 통해 알게 되었다.

[관련기사] 우리 동네 착한 가격 업소 아세요? 
– 행정안전부, 7,132개 착한가격업소 선정 –

어려운 경제여건에서도 저렴한 가격으로 영업하며 어려운 이웃과 지역사회를 위해 봉사하는 착한가격업소가 전국적으로 7,132개 선정되었다.

(하략)

이런 공공데이터가 있다면 내가 만들고자하는 “착한 가게”의 기초자료로 활용하기 적절하다는 생각에, 살펴보았다. 하지만 좌절스럽게도 open api나 파일형태로 제공되는 데이터는 없었다. 그냥 게시판처럼 목록과 상세 내용이 있는 페이지가 전부라니. 우리나라의 공공정보의 현주소려니 체념하고, 어떻게 데이터를 긁어올 수 있을지 고민해봤다.

공공 데이터 긁어 오기 시작

쿼리 파라미터를 순차적으로 증가시키면 거기에 맞는 상세 페이지가 만들어지는 형태라서, 순차적으로 주소를 호출하고 HTML를 파싱해서 내가 원하는 데이터를 가져오기로 했다.

이 작업을 위해서 레일스를 활용하기로 했다. 가져온 데이터는 기준위치에서 얼마나 떨어져있는지 쿼리가 가능한 MongoDB를 사용한다. 레일스에서 해당 데이터를 긁어 오기 위해서 rake task를 하나 생성했다.  rake는 rails의 make나 ant같은 툴로 특정 task를 코딩해두면 rake 명령으로 실행할 수 있다. task를 정의하는 부분이다.

Nokogiri를 활용한 HTML 파싱

위 코드에서 Nokogiri라는 gem를 사용했는데, XML이나 HTML같은 well-form document에서 xpath를 사용해서 특정 element(태그)나 attritbute로 찾아내고 이동하고 데이터를 추출하는 일련의 기능을 묶어 놓은 것이다. jquery랑 유사한 기능이다. url로 데이터를 가져와서 Nokogiri로 HTML를 파싱한다.

xpath란?

nokogiri를 제대로 활용하기 위해서는 xpath라는 것을 이해하면 좋은데, Michael Kay의 표현을 빌려오자면, xpath란 ‘데이터베이스에서 SELECT가 있다면 XSLT에는 xpath가 있다’ 즉 HTML이라는 document에서 내가 원하는 데이터를 뽑아내기 위한 문법 정도로 이해하고 있으면 되겠다.

위 코드에서 data.phone = doc.xpath(“//th[text()=’전화번호’]/following-sibling::*”).text 부분을 보면 xpath 함수 안에 들어가는 내용이 xpath 문법이다. 풀어 쓰면 “전화번호를 innerText로 갖고 있는 <th> 태그 바로 뒤에 있는 태그들”에 해당된다.

이렇게 어떤 HTML이나 XML이라 하더라도 xpath를 잘 정의해두면 특정 데이터를 쉽게 가져올 수 있을 것이다. 행안부의 착한 가격 가게 페이지가 아닌 다른 어떤 페이지라고 하더라도 xpath의 내용만 고침으로 필요 데이터를 가져올 수 있게 되었다.

Nokogiri와 xpath의 도움으로 몇 줄안되는 코딩으로 해당 HTML에서 우리가 원하는 데이터를 선택하고 그것을 MongoDB에 담는 데 까지 성공했다. 이제 반은 성공한 셈이다.

주소를 좌표로 바꿔보자

지오코딩

일반적으로 geocoding란 주소나, 우편번호등의 데이터에서 longitude, latitude로 대표되는 좌표계의 경위도를 찾아내는 것이다. 그 반대로 좌표에서 주소를 찾아내는 것은 리버스 지오코딩이라고 한다. 우리는 행안부의 자료에서 착한 가격 가게들의 주소를  이미 받아왔다. 이제 이 주소에 해당되는 좌표가 어떻게 바뀌게 되는지 살펴보려고 한다.

다음 open api중 지역 API를 활용

다음의 open api중에 지역 API를 활용하면 정확한 주소를 입력했을 때, 경위도를 뽑아준다. 심지어 새주소 체계에서도 잘 동작한다. 이를 활용하려면 다음 계정으로 로그인한 상태에서 API 키를 발급받아야 하는데, 매우 간단히 신청이 가능하고 즉시 활성화된다. 제한이 있다면 하루에 이 API를 호출할 수 있는 횟수가 3만번으로 제한되어 있다는 것이다. 우리의 주소데이터가 약 6천개이므로 3만번이면 나쁘지 않다.

이 코드에서 지오코딩이 어떻게 일어나는 지 볼 수 있다. 주소를 받아서 그 주소를 API의 쿼리 파라미터에 넣어 보낸다. 물론 개인적으로 받은 api_key를 함께 보내야 제대로 동작한다. 그런데 그렇게 주소를 요청했지만 데이터를 못받는 경우도 있다. 그러면 주소에서 맨 뒤 어절을 지우고 재귀호출을 한다. 그런식으로 뒤의 상세 주소를 지워감으로 주소가 모호해지고 그러면 API에서 위치를 받아오는데 성공할 수 있게 된다. 좀 어려운가? 예를 들면, “서울시 마포구 공덕동 14-1 2층 서울약국” 이런 주소로 쿼리했을 때 결과값이 오지 않는다면 서울약국을 떼고 “서울시 마포구 공덕동 14-1 2층”으로 요청해본다. 그래도 안되면 2층을 떼낸다. “서울시 마포구 공덕동 14-1” 이렇게 보내면 거의 성공하게 된다. 혹시 주소가 없는 경우라면 14-1도 떼버린다. 그러면 공덕동의 어디 쯤의 좌표를 돌려주게 되어 모호해지긴 하지만 데이터는 받게 되는 것이다. 이런 식의 heuristic 접근이 상당히 유용했다. 재귀호출을 한 것도 코드의 복잡도를 낮춰줘서 괜찮은 아이디어였던 것 같다. 🙂

이렇게 어렵게 얻어온 경위도 좌표는 MongoDB에 잘 저장되었고 이제 소기의 목적을 달성한 것으로 보인다.

남은 작업

이제 남은 작업은, 이 DB에 접근하기 위한 API wrapping layer를 하나 만들어 주고, 그것 호출해서 사용할 iOS, Android 앱을 만들면 되는 것이다. 이번 프로젝트에 Titanium을 써보려고 한다. 과연 어느 정도까지 자유도를 줄 수 있을 지 네이티브 iOS개발자로서 무척 기대된다.

 
댓글 2개

게시자: 켬 2012년 10월 6일 in 공공정보, 앱개발, OpenAPI, rails

 

태그: , , , ,

리치앱(rich apps)의 열 한가지 특징

리치앱(rich apps)이란 말이 요즘 앱쪽에서 회자됩니다. 부자앱? 풍부한 기능의 앱? 알찬앱? 뭐라 딱히 번역하기 어렵기에 그냥 ‘리치앱’으로 부르기로하죠. 이 신조어는 기존의 앱에 없는 특징적인 것들을 갖춰서 시장에서 성공한 앱들을 통칭하는 것 같습니다. 특히 단말 혼자서만 동작하던 앱에서 백앤드 서버와 연동되면서 단말의 ‘제한된 데이터’를 넘어서 DB서버의 ‘풍부한 데이터’을 활용할 수 있게 된 앱을 가리키는 듯합니다. 정의하긴 어렵지만, 그 특징은 뽑아볼 수 있겠습니다. 일반적으로 리치앱은 다음과 같은 특징을 가진다고 봅니다.

하나, 맥락을 이해하고 있다. 앱이 사용자가 누구인지 한번 알려주면 기억하고 있으면서 개인화해준다던가 현 위치를 알고 있으면서 위치에 맞는 응답을 해주는 앱이죠. 요즘은 멀티 디바이스에서 같은 앱을 사용하는 경우도 있는데 내가 디바이스를 바꿔가며 쓰더라도 리치앱은 내가 마지막하던 맥락을 끊김없이 이어주는 사용자 경험을 주기도 합니다.

둘, 상호작용이 폭넓다. 어떤 앱을 사용해보니 이 앱을 함께 쓰는 나의 지인을 알려주며 상호작용을 유도하기도 하고, 사람과 사람사이의 상호작용이 아닌 리치앱 자체가 필요한 백앤드에 붙어서 필요한 정보를 수집하는 것도 일종의 상호작용이라고 할 수 있겠습니다. 날씨나 증권정보등을 필요한 시점에 받아와서 보여주는 것이 상호작용의 예가 되겠지요.

셋, 예외상황 대응력이 좋다. 가령 네트워크 상황이 좋지않은 장소에서 앱을 사용한다고 생각해봅시다. 연결이 끊어졌다 붙었다를 반복하게 되는데, 이런 상황에서도 부드럽게 앱의 기능을 처리할 수 있는 앱이 있는 반면에 그렇지 못하고 종료하거나 무한정 기다리게 만드는 앱들도 있지요. 또, 배터리가 소진되어 10~20%남았을 때는 네트워크 사용을 최소화하고 화면색상을 어둡게하는 등의 조치를 할 수도 있겠습니다.

넷, 안전해야 한다. 리치앱은 사용자 데이터를 소중하게 다뤄야 합니다. 서버로 허락되지 않은 개인정보를 올리거나, 외부로부터 내 단말로 접속해서 정보를 빼가려는 시도를 해서는 안되겠지요. 네트워크로 데이터를 보낼 때는 암호화된 형태로 주고 받아서 중간에 데이터가 유실되어도 쉽게 드러나게 해서는 안됩니다. 이런 부분을 세심하게 고려하는 앱이 있는 반면 아닌 앱들도 많습니다.

다섯, 반응 속도가 빨라야한다. 마치 살아있는 듯한 UI반응을 불러일으키고, 네트워크에 요청해서 받아오는 부분도 통신 속도에 따라 UI가 얼어버리는 현상이 없도록 비동기적으로 처리할 필요가 있겠습니다.

여섯, 고객의 소리를 듣는다. 리치앱은 고객의 의견에 귀를 기울입니다. 의견을 수집할 수 있는 창구를 열고 그 내용을 선별하여 반영할 계획을 세우고 실행하지요. 주로 메일이나 블로그 댓글 형태로 소통합니다. 어떤 앱에서 정말 고치고 싶은 기능이 있는데 도무지 소통할 수 있는 방법을 찾기 힘들 때 그 답답함을 공감하시는 분들이 있을 것입니다. 소통은 모든 면에서 중요하지만 리치앱에서도 마찬가지입니다.

일곱, 오픈된 표준을 따른다. 리치앱은 독자적으로 서비스 되는 경우도 있겠지만, 다른 앱과 서비스와의 연동함으로 그 사용성이 높아질 수 있습니다. 이렇게 연동을 위해서는 공개 표준을 따르는 것이 좋습니다. 가령 앱끼리의 호출에 대한 url scheme을 제공하거나, OpenAPI를 만들어 제공하는 등의 형태가 되겠지요.

여덟, 처음 사용자를 위한 안내가 풍부하다. 앱이 직관적이어서 아무 설명없이도 사용하는데 어려움이 없다면 괜찮겠지만, 기능이 독창적이고 다양한 기능을 제공하다보면 , 초기 사용자를 위한 친절한 안내가 앱의 가치를 전달하고 재사용률을 높일 수 있을 것입니다.

아홉, 콘텐츠나 기능이 풍부하다. 리치앱의 그 이름처럼 풍부해야 합니다. 앱 자체의 콘텐츠가 없거나 별다른 기능이 없다면 유저들은 그 앱을 사용할 가치를 느낄 수 있을까요?

열, 재미를 줘야 한다. 다양한 측면에서 쏠쏠한 재미를 줘야합니다. 부활절 달걀(easter egg)처럼 숨겨진 기능이 있다거나 나 구글에서 검색할 때 feeling lucky같은 기능은 유저에게 흥미를 던져줍니다.

열하나, 심미적 즐거움을 줄 수 있어야 한다. ‘이쁘면 모든 것이 용서된다’는 풍자는 앱 세상에서도 예외는 아닌것 같습니다. 어떤 조사에 의하면 남녀모든 사용자들이 앱을 설치할 지 여부를 결정하는데 가장 중요한 요소가 앱의 스크린샷이라고 합니다. 혁신적인 UX, UI과 기능도 일단 시각적으로 강한 인상을 주지 못한다면 설치되기 어렵고 설치되지 못하면 사용할 수도 없겠지요. 리치앱으로 성공하기는 쉽지 않을 것입니다.

나열하다 보니 꽤 길어졌네요. 앞에 일곱가지는 제가 생각하는 특징이었구요. 나머지는 함께 일하는 동료(곽,조,신,JP님)들의 아이디어을 추가해서 더 멋진 리스트가 만들어졌네요.

아무튼, 그냥 앱으로 주목받던 시기는 ‘이미’ 지났습니다. 잘 만들고 풍성하게 만들어야 유저들의 성은을 입습니다. 그러기 위해서는 리치앱의 특징을 벤치마킹하고 개선해서 내가 만드는 앱에 적용해보는 것도 나쁘지 않을 것 같습니다.

최피디 드림

 
댓글 남기기

게시자: 켬 2012년 8월 24일 in iOS개발, 앱개발