RSS

월간 보관물: 4월 2011

탈도시를 꿈꾸는 개발자1

우리 회사의 친하게 지내는 IT전문가들과 이야기 할 때, 장난처럼 함께 귀농하자는 이야기를 나눈다. 현실의 퍅퍅함을 극복하는 한가지 대안으로 귀농을 이야기 하지만, 속을 들여다 보면 귀농하여 농사짓고 살자는 것보다는 탈脫도시에 가깝다. 값비싼 물가, 꽉막힌 도로, 맹목적인 경쟁사회, 매마른 인정(人情)등 수 만가지 이유로 도시를 떠나고 싶지만, 도시의 마수魔手에 걸려 살아가고 있다는 자기인식을 갖고 있는 것이다.

님과 함께

저 푸른 초원위에 그림같은 집을 짓고
사랑하는 우리 님과 한 백년 살고 싶어

봄이면 씨앗 뿌려 여름이면 꽃이 피네
가을이면 풍년되어 겨울이면 행복하네

멋쟁이 높은빌딩 으시대지만
유행따라 사는것도 제멋이지만
반딧불 초가집도 님과 함께면
나는 좋아 나는 좋아 님과 함께면
님과 함께 같이 산다면

저 푸른 초원위에 그림 같은 집을 짓고
사랑하는 우리 님과 한백년 살고 싶어

소프트웨어 엔지니어들은 어린 시절부터 꿈을 쫓아 살아온 사람들이 많다.  어린시절 “세상을 깜짝 놀라게 만들” 소프트웨어를 만들어 이름을 떨치겠다며 프로그래밍을 공부한 사람들이 필자를 포함해서 꽤 있다. 이런 사람들에게 최근의 앱스토어 붐이 창작의 즐거움을 되살려 주었으며, 구지 회사에 소속되지 않더라도 호구지책糊口之策에는 문제가 없다는 경제적 독립정신을 북돋우고 있다.

매뚜기도 한 철이라며, 앱스토어 붐이 꺼지면 어떻게 할 것이냐는 걱정의 목소리도 들린다. 앱스토어가 아직도 단편의 현상으로 여기는 분들의 진심어린 충고이다. 하지만 앱스토어 현상은 찻잔 속의 폭풍이 아니고, 시장이 점점 다양해지고 그 규모도 커지고 있다. 아울러 클라우드化가 급속히 진행되고 Open 시스템의 발전으로 힘없는 개인도 얼마든지 괜찮은 앱이나 서비스를 개발할 수 있는 시기가 도래한 것이다.

이런 배경이 이른바 스스로를 ‘디지털 노매드 digital nomad’로 바라보는 개발자가 늘어가게 된 이유다. 필자의 경우도 편안한 의자, 개발할 수 있는 노트북, 충분한 전원, 그리고 빠른 무선 인터넷만 있다면 어디든 ‘사무공간’이 될 수 있다. 따라서 그 공간이 복잡한 도심일 필요는 없는 것이다. 협업을 위한 커뮤니케이션 역시 이메일과 전화로 충분히 극복될 수 있다.

개발자 개인이 탈도시하는 데 어떤 문제도 존재하지 않는 세상이 ‘이미’ 되었다. 하지만 개발자 개인의 문제가 아니다. 내가 부양해야할 ‘가족’이 있다. 한적한 곳에서 살고 싶지만, 교육이 문제가 있고 쇼핑이 문제인 것이다. 도시의 경쟁일변도의 교육을 비평하면서도 대안을 찾지 못하고 국가의 교육에 자식을 맡겨야하는 대부분의 사람들과 마찬가지로 개발자들도 예외일 수 없다. 홈 스쿨링을 통하여 대안을 제시하고자 하는 가정들이 있지만 정착하기까지는 많은 시행착오를 해야할텐데 우리 아이들에게 그것을 시도해볼 수 있는 용기가 부족하다. 도시에서 누릴 수 있었던 소비의 욕구를 채워주기엔 부족할 것이며, 탈도시와 함께 소비에 대한 개념도 많이 바뀌어야 할텐데 그것을 우리 혹은 배우자가 받아들일 수 있을지가 탈도시를 꿈꾸는 개발자들에게 또하나의 걸림돌이다.

이쯤에서 글을 잠깐 멈추고 더 생각해보려고 한다. (생각이 바닥났기 때문이다)

이런 생각 공감하시거나 다른 의견이 있으신 분들의 피드백은 언제든 환영합니다.  🙂

최피디 드림

관련링크

Advertisements
 
댓글 남기기

게시자: 켬 2011년 4월 30일 in Uncategorized

 

우리나라의 공공정보

필자는 정보가 공공재라는 생각을 예전부터 가졌지만, 요즘들어 더욱 관심을 갖게 된 것은 몇 해 전부터 잊을만하면 다시 듣게 되는 정부2.0같은 IT와 접목된 공유의 방법의 전환이라는 트랜드 때문이다.

공유의 방법이 바뀌어도 참 많이 바뀌었다. 정보가있는 기관을 찾아가서 보던 방식에서 웹을 통한 조회가 과거와 현재의 방법이었다면, 공개API(어플리케이션 프로그래밍 인터페이스)를 통하여 공개됨으로 개발자나 개발사에서 누구나 쉽게 그 정보를 재가공하여 전달할 수 있는 기회를 갖게 되었다.

예컨데, 공공도서관의 책 정보를 생각해보자. 예전에는 도서관에 직접 가서 사람과 사람이 만나서 책 정보를 검색했었다. 그 후에 터미널이나 웹이란 게 생겨서 원격으로도 필요한 책을 검색해볼 수 있었다. 즉 컴퓨터와 사람이 만난 것이다. 그런데 최근의 변화는 API라는 프로그래밍 규칙에 의해서 책 정보를 컴퓨터와 컴퓨터사이에 주고 받을 수 있게 되었다. 이제 컴퓨터 프로그래머들은 공공정보의 공개API의 힘을 빌려서 자신의 목적에 부합하는 어플리케이션을 만들 수 있고 그것을 공유하여 다른 사람들에게 까지 가치를 전달할 수 있게 된 것이다.

최근 스마튼 폰의 보급이 천만대를 넘어서면서, 어플리케이션(이하 앱스, apps) 개발자들도 많아졌다. 이들은 저마다 창조성을 발휘하여 가치있는 앱스를 만들고 있는데 공공정보가 공개API형태로 제공된다면, 이들이 개발하는 앱스에서 쉽게 공공정보를 가져다가 유용하게 사용할 수 있을 것이다. 가령, 스마트폰 유저는 자신의 현재 위치에서 가장 가까운 곳에 위치한 공공도서관의 책을 찾을 수 있게 되는 것이다.

우리나라는 2009년도 말부터 앱스 붐이 일기 시작했다. 아이폰을 위시하여 수많은 스마트폰들이 출시되었고, 자연스레 앱스 개발도 활성화 되었다. 하지만, 우리나라의 공공정보의 제공 수준은 이런 스마트폰 혁명과는 전혀 다른 나라에 와있는 듯, 질과 양의 모두 낮은 수준에 머물러 있다. 필자는 최근에 우리나라의 공공정보의 양과 질이 어떠한지 알아보기 위해서 기사와 웹사이트를 검색해봤다. 대표적인 공공정보에 대한 사이트로 공공정보 활용 지원센터와 서울시 모바일 공공정보 OpenAPI 였다.

공공정보 활용 지원센터는 양적인 측면에서는 서울시의 모바일 공공정보에 비하여 더 많았지만 해당 공공정보가 API형태로 제공되지 않고 단순히 해당정보를 관리하는 주무부처의 일관되지 않는 웹서비스 형태로만 지원되고 있었다. 이것은 정보공개를 수행하는 표준이 없는 상태에서 각 사업자들의 자신들만의 방식으로 웹서비스를 만들었기 때문이라고 생각한다. 이런 표준이 없는 이유는 아직도 정보공개에 대한 우리의 시민의식의 현주소 때문일 것이다.

서울시 모바일 공공정보 OpenAPI는 표방한 이름처럼 OpenAPI를 염두에 두고 공공정보 제공 사업을 진행하고 있었다. 하지만 제공하는 정보의 종류가 7종에 불과한 초보적인 단계에 머물고 있다.

나눌 때에 비로소 가치가 부여되는 공공정보가 누군가에 의해 빗장이 꼭꼭 걸어잡긴 채 곰팡이만 쓸고 있는 게 씁쓸한 현실이다. 국가 재정, 복지, 인권 등에 대한 시민들의 감시를 위해서는 팩트(fact)가 필요한데 그것에 대한 접근을 매우 어렵도록 방조하는 정부는 부도덕한 정부다. 또 팩트를 있는 그대로 전달하지 않고 자신의 입맛에 맞게 변질 시키는 정치인, 정당, 언론등도 부도적하기는 매한가지다. 다행이도 IT의 힘으로 정보를 다루는 기술은 매우 발전했다. 이제는 팩트를 공유하고 그것을 객관적으로 분석하는 일이 양식있는 시민들이라면 큰 힘을 들이지 않고서도 할 수 있는 범위의 일이 되었다.

정부2.0을 구지 언급하면서 거창하게 이야기 하지 말고, 각론으로 들어가서 공공재로서의 정보를 어떻게 수집하고 관리하고 공유할 지에 대한 구체적인 논의가 시민사회에서 또한 정부에서 진행되길 기대해보며 어리석은 글을 마무리한다.

최피디 드림

 
댓글 한 개

게시자: 켬 2011년 4월 19일 in OpenAPI

 

태그: ,

KR Domain 검색 OpenAPI

한국인터넷진흥원(KISA)에서 OpenAPI를 지원한다는 기사를 보고 평소에 오픈API에 호기심이 많았던 제가 사용해보려고 신청을 했습니다. 누구든지 이메일과 사용목적만 채워서 신청 하면 API를 사용할 수 있는 것 같습니다. 하지만 키가 발급되니 과도한 사용에 대해서는 규제가 될 수 있겠습니다.

제공하는 API는 한종류로  Whois OpenAPI 입니다. kr로 끝나는 도메인을 검색해서 누가 등록했는지 정보를 XML형식으로 리턴해줍니다. 이 API를 이용해서 KR 도메인을 검색해주는 페이지를 하나 만들어 봤습니다.

요즘은 JSON을 주로 쓰시는거 같던데, 여기는 XML로 내려주는 게 좀 아쉬웠습니다. JSON으로 주면 좋겠다는 생각이 간절하더군요.

그래서 gateway역할을 하는 놈을 하나 만들었습니다. 🙂

whois 요청을 하면 json으로 내려주는 앱스입니다.

사용법은 간단합니다.

post나 get방식으로 key, domain_name을 채워서 request하면 json으로 response해줍니다.

요청할 주소는, http://social-tools.appspot.com/whois.json 입니다.

key는 당연히 KISA에서 받으셔야 합니다. domain_name은 abc.kr 이런 식으로 kr로 끝나는 도메인이어야 합니다.

필요하신 분들은 맘껏 쓰시기 바랍니다. 😉

최피디 드림

 
댓글 남기기

게시자: 켬 2011년 4월 18일 in 100LoC, OpenAPI, Python

 

태그: , , ,

GAE용 python2.5 설치하기

OSX 사용자들에게는 이미 python이 설치되어 있는데 그 버전이 2.6.x입니다.  구글 앱엔진의 python runtime 2.5.x와 차이가 있어서, urllib같은 모듈을 사용할 때 ctype 모듈을 가져올 수 없다는 에러를 보신분이 계실겁니다. 그럼 내 맥북에도 2.5를 설치할 동기는 충분해졌다고 봐야겠죠?

어떻게 설치하는게 가장 빠른가 하면, macports입니다. mac port는 BSD계열의 유닉스에서 패키지를 아주 쉽게 설치할 수 있도록 해주는 유틸인데요. 리눅스의  yum, apt-get같은 것이라 보시면 됩니다. 맥포트가 기본으로 깔려 있지 않기 떄문에 설치를 해줘야 합니다. macport사용을 위해서는 개발툴인 Xcode가 깔려 있어야 합니다. 앱스 개발자분들이라면 이미 깔려있으리라 예상되니 pass! (ptyhon 문법이더군요)

설치방법은 정말 간단합니다.

sudo port install python25

이 한 줄이면 설치됩니다. 설치는 /usr/bin/ 아래에 되었군요. 그런데 terminal 에서 python이라고 치면 2.6x가 뜹니다. 아마도 관련 심볼릭 링크 때문인가보네요. 단순히 python 링크만 바꿔주는게 아니라 library도 2.6 이 아닌 2.5로 바꿔줘야 하는데 이것들이 귀찮습니다. 이때 쓰려고 python_select란 유틸이 있습니다. 이것도 macport를 써서 쉽게 설치할 수 있습니다.

sudo port install python_select

설치되었다면 실행시켜야지요~!

python_select python25

이제 python을 실행시키면 2.5.x가 뜹니다. (올레~!)

하지만 appengine launcher를 실행시켜서 앱스를 실행해봐도 여전히 2.6.x의 라이브러리를 참조하는 듯 에러를 내고 있습니다. 이럴 때는 appengine laucher의 preferences에서 Python Path:를 /usr/bin/python2.5 로 바꿔주고 리스타트 하면 해결됩니다.

이게 2.5.x 환경의 appengine 테스트 환경이 구성되었습니다.

즐프하세요~!

최피디 드림

 
댓글 남기기

게시자: 켬 2011년 4월 18일 in AppEngine, OSX, Python

 

태그: , , ,

하루 100줄의 코드

파이썬을 공부해볼 요량으로 검색어를 조합해봤다. 백일동안 파이썬 마스터가 되는 방법이 없을까? 생각하면서 100days python 이라고 구글링해봤더니 이 글을 만날 수 있었다.

Write 100 lines of python code each day

글쓴이는 지난 10년간 하루에 100줄씩의 코딩을 해왔다며 우공이산을 언급한다.  기막힌 아이디어라고 생각하고 오늘부터 실행해보려고 한다. 100LoC라는 카테고리를 만들어서 날마다 코드를 써보기로 결심했다. 시간과의 싸움에서 얼마나 즐길 수 있을지 모르겠지만 일단 시작해보기로 한다.

최피디

 
댓글 남기기

게시자: 켬 2011년 4월 17일 in 100LoC

 

아이폰 앱스을 웹을 통하여 배포하는 방법 (2)

앞에 썼던 “아이폰 앱스를 웹을 통하여 배포하는 방법” 에 이어 또하나의 웹 배포방법을 소개하려고 합니다.

다름이 아니고 diawi.com 이란 웹 서비스입니다.

앱스를 모두 만들고 나면 보통 앱스토어에 올리기 전에, ad-hoc 빌드를 한 다음 그것을 메일로 공유하곤 합니다. 이 diawi.com 사이트를 이용하면, 메일이 아닌 서버로 ipa나 zip파일을 올리면 축약 링크하나가 떨어집니다. 이 링크를 클라이언트들에게 메신저나 메일로 공유해주면, 테스터나 클라이언트들이 모바일 사파리에서 바로 설치할 수 있게 됩니다.

소규모 회사라서 엔터프라이즈 프로그램에 가입되어 있지 않은 경우라면, 이 웹사이트를 통해서 손쉽게 공유해보는 것도 나쁘지 않아보입니다.

사용법은 매우 간단합니다.

위 그림과 같이 빈 화면에 나의 provisioning profile과 ipa파일을 끌어다 놓고 Send하면 끝납니다. 정말 쉽습니다. 🙂

유용하게 사용하시길 바랍니다.

최피디 드림

 
댓글 남기기

게시자: 켬 2011년 4월 14일 in iOS개발, 테스팅

 

Google App Engine 사용 후기

gae icon

구글 앱엔진으로 프로젝트 하나를 마쳤습니다.

간단한 이미지 콘텐츠 관리서버와 API를 앱엔진에서 구성하고, 아이폰에서 해당 API를 호출하여 이미지를 보여주는 형태의 서비스입니다.

처음으로 앱엔진을 이용해봤지만 간단한 후기를 적어 보고자 에어를 펼쳤습니다. 혹시 누군가에게 도움이 되길 바라며, 유리병에 넣고 바다에 던져보는 거지요. 🙂

처음 앱엔진을 접했던 것은 2008년 12월쯤 아이폰 앱스를 개발하면서 cocos2d라는 라이브러리를 이용할 때였습니다. 거기 글로벌 랭킹를 관리해주는 아이가 바로 앱엔진이었던 것이였죠. 벌써 2년이 훌쩍 넘었군요. 좀 더 호기심을 가지고 들여다 봤다면 클라우드를 먼저 접해볼 수 있었겠지만 그리 못했습니다. 아쉬움이 많이 남습니다.

2년사이에 간간히 앱엔진으로 뭔가를 해봐야겠다는 생각 뿐이었고 실행에 옮기지 못했습니다. 그 사이에 저는 전업 앱개발자가 되어가고 있었지요. 이전에 하던 서버쪽 개발은 별로 흥미를 끌지 못했던 시기였습니다. 전업 앱개발자로서 SNS를 개발해보고 나서 API서버의 역할과 앱과의 통신에 대해서 이해하게 되었지요.

그래서 개인 프로젝트에 적용해보기로 맘먹었고, 그래서 머리 속 기억 저편의 앱엔진을 다시 전두엽으로 불러냈습니다. 😉

2년이란 시간이 지나는 동안 앱엔진은 자바 런타임을 도입했다는 것 외에는 큰 변화가 없었습니다. 하지만 관련해서 사용자들의 리뷰는 넘쳐나고 있었지요. 이들의 리뷰와 간증 덕분에 쉽게 이것을 해보자는 결정과 함께 착수했습니다.

약 2달간의 짬짬이 공부가 시작된 셈입니다. 꾸준하진 못했지만 토요일마다 카페에서 앱엔진을 배우기 위해서 이런저런 코딩을 해보고 실제로 서비스를 구현해봤습니다.

결론적으로 서비스는 파이썬 기반의 앱엔진으로 구현이 되었습니다.

구현하기까지 삽질한 순서를 회고해보면,

1. 초기 샘플 코드 재구현해보기 (방명록 구현하기)
2. 사진 올리고 보여주기 구현
3. data model 구현
4. json출력하기 구현
5. 관리자 페이지 작성
6. API 페이지 작성
7. Memcache 적용

이렇게 꼽을 수 있겠네요.

이 정도로 앱엔진의 모든 기능을 써봤다고 말하기는 많이 부족하지만, 간단한 RESTful 웹서비스 구현은 할 수 있겠구나는 확신이 생기더군요. 각 단계에서 느꼈던 소회를 불어보려고 합니다.

1. 초기 샘플를 따라서 구현

앱엔진의 초기 화면에서 삐적 마른 아저씨가 보여주는 동영상을 몇 번 보면서 따라했습니다. 모방을 충분히 해보니까 이 동네가 어떻게 돌아가는 지 조금 알 거 같더군요. 이 방명록 샘플에 필요한 모든 게 다 들어있다고 해도 되겠습니다. webapp framework를 사용하여 request 처리하는 방법과 처리 결과를 django를 이용해서 response하는 방법 datastore Model를 만드는 방법 이것만으로도 기본적인 웹서비스를 만들기 위한 기초는 놓여졌다고 봐야겠더군요.

2. 사진 업로드하고 보여주기

사진데이터는 BLOB로 datastore에 저장됩니다. 마치 테이블의 한 필드에 저장되는 것 처럼 말이죠. BLOB처리도 매우 간단히 처리가 되더군요. 그런데 그 이미지를 보기 위한 핸들러가 필요했습니다. 각 이미지가 들어있는 row에 대해서 key값으로 blob데이터를 불러와서 이미지로 Content-Type를 이미지로 설정해서 뿌려주니 잘 되네요. 이것도 모두 앱엔진 문서화에 포함되어 있습니다.

3. Model 설계

데이터 모델을 서비스에 맞게 디자인하고 테이블을 설계하듯이 파이썬 클래스를 db.Model를 상속받아 만들면 모델이 만들어집니다. 그 모델을 get(), put(), delete()이런 메소드를 사용할 수 있게 됩니다.

4. json으로 출력하기

django.utils에 simplejson모듈을 그냥 가져와 쓰면 되더군요. 오히려 파이썬의 dictionary와 list에 대응하는 {}, [] 표기법이 익숙치가 않아서 조금 햇갈렸습니다만 곧 이해가 되었습니다. 아울러 json의 구조상 reculsion으로 구현해야하는 부분에서 살짝 고민스러웠는데 다른 사람들이 해놓은 패턴을 따라해서 곧 해결했습니다. 그럴듯한 json를 리턴해주는 API도 구현이 끝났습니다.

5. 관리자 페이지

사실 관리자 페이지에서 콘텐츠를 입력하기 때문에 초반부터 작업이 되었습니다만 효과적인 구현이 어려웠습니다. 관련해서 찾아보니 앱엔진의 Model을 기준으로 자동으로 admin페이지를 구성해주는 appengine-admin프로젝트가 있더군요. 그것을 이용하면 어땠을까 아쉬움이 남았습니다.

6. API 구현

이제 아이폰 앱스와 앱엔진 사이의 API를 구현했습니다. json으로 쉽게 만들 수 있어 쉽게 구현했습니다. 이때 Model사이의 join개념을 사용하기 위해서 ReferenceProperty를 사용하여 최종적으로는 tree형태의 자료구조가 json으로 출력되도록 했습니다. 뭔가 무거운 느낌이 들었지만 그냥 잘 작동 되는 것 같아(?) 넘어갔습니다.

7. Memcache 적용

API를 호출하면서 본격적인 테스트에 들어갔는데, 이상하게도 좀 무거운 API를 호출하면 앱엔진 어드민 콘솔에서 로그에 빨간색으로 경고가 떴습니다. cpu사용과 api호출이 과하다는 경고였습니다. 몇 번 사용하지 않았는데도 cpu가 쿼터의 90%에 육박하는 것이었죠. 실 서비스로 간다면 쿼터를 넘어서 서비스가 불가능했겠지요. 결국 같은 내용을 리턴해주는 쿼리를 매번 할 필요없이 특정 시간동안은 memcache에 저장한 다음 그것을 리턴해주는 방식으로 cpu와 api호출 과부하 문제를 해결했지요.

아직 앱 승인전이고 실 서비스가 진행됨에 따라 예기치 못한 문제가 발생할 수 있겠습니다. 그렇게 경험한 뒤에 그 경험을 나눌 것을 약속드립니다. 🙂

글을 마무리 하면서, 앱엔진은 독립 앱스 개발자들에게 날개를 달아주는 서비스라고 생각합니다. 클라우드 세상은 이미 도래했고 서로 나를 이용해달라고 아우성입니다. 앱엔진을 공부하는 동안 AWS(아마존 웹 서비스)에도 급 관심이 생기더군요. 특히 대용량 저장을 위한 S3는 먼저 써보고 싶어질 정도였죠. 앱스 개발자 여러분 클라우드에 도전해보십시오. 막연한 두려움 가질 필요가 없어요. 해보면 별거 없습니다.  주저하고 있다면 저질러보십시오. 이년전에 제가 주저하다가 말아버린 걸 후회하는 전철을 밟지 마시길 당부드립니다.

최피디 드림.

 

태그: , , , , , , ,