NaggingMachine

Snake Traverse 문제

naggingmachine — Thu, 19 Dec 2013 22:42:12 +0900

2006년도에 Microsoft 본사 면접을 봤을 때 두번째로 면접볼때 풀었던 문제다. 화이트보드에 직접 코드를 작성하기란 여간 까다로운게 아니어서 15분만에 풀었어야 하는 문제를 30분정도 걸렸던것 같다. 다행히도 면접을 봤던 Diago(현재는 구글 Japan에 근무)가 친절하게 기다려줘서 clear했던 문제. 그런데 이 문제가 구글이나 MS와 같은 IT 기업의 문제 은행으로 등록되어 있다니. 그땐 사전에 미리 공부도 하지 못해서 "뭐 이런 문제를 내지?"라고 생각했었는데, 오늘 우연히 발견하게 되어서 간단하게 풀어보았다. 머리도 식힐겸~

문제의 요구 사항은 NxN 배열이 있을 때 해당 배열의 각 항목을 뱀 꼬리를 잡듯이 하나씩 출력하는 문제다.

영어로 설명하자면, 이렇다.

Given a 2-d array, write code to print it out in a snake pattern. For example, if the array is this:
1, 2, 3
4, 5, 6
7, 8, 9
the routine prints this:
1,2,3,6,9,8,7,4,5
The array is an NxN array.

편의상 Python으로 작성했다. 주석이나 이런저런 코드를 빼면 20줄 내외로 작성 가능하다. 생각한 방안은 진행 방향을 고려해서 x와 y의 증가(또는 증감)을 자동으로 계산되도록 한다. 그리고 이 순환이 끝날 수 있도록 min과 max 값을 잘 조절하는게 핵심. 더 좋은 방법이 있을 수 있고, 이게 최선은 아닐 수도 있습니다.

# -*- coding: utf-8 -*-

class SnakeTraverse:
    def __init__(self, dim, tables):
        self.dim = dim
        self.tables = tables

    def traverse(self):
        # 스네이크 traverse를 하기 위해서는 x와 y 좌표를 통해 방향을 지정한다.
        # 0 --> 오른쪽으로, 1 --> 아래로, 2 --> 왼쪽으로, 3 --> 위쪽으로
        switch = [[1, 0], [0, 1], [-1, 0], [0, -1]]
        switch_type = 0

        # 한번의 traverse가 끝나면 다음 시작 좌표를 조절한다.
        adjust_to_next_point = [[-1, 1], [-1, -1], [1, -1], [1, 1]]

        x = 0
        y = 0
        min_x = 0
        max_x = self.dim - 1
        min_y = 0
        max_y = self.dim - 1

        while True:
            # x와 y의 최소값과 최대값을 변경하여 해당 좌표안에서만 탐색하도록 한다.
            while ((min_x <= x <= max_x) and (min_y <= y <= max_y)):
                # 현재 좌표의 값을 찍고
                print str(x) + ", " + str(y) + " ==> " + str(self.tables[y][x])

                # 다음 좌표로 이동
                x = x + switch[switch_type][0]
                y = y + switch[switch_type][1]

            # 모든 위치가 탐색될 때 끝난다.
            if min_x > max_x or min_y > max_y:
                break;

            # 다음 순환을 위해 좌표를 보정한다.
            x = x + adjust_to_next_point[switch_type][0]
            y = y + adjust_to_next_point[switch_type][1]

            # 방향에 따라서 x와 y 값의 최대값과 최소값을 변경한다.
            if switch_type is 0:
                min_y = min_y + 1
            elif switch_type is 1:
                max_x = max_x - 1
            elif switch_type is 2:
                max_y = max_y - 1
            else:
                min_x = min_x + 1

            # 방향을 바꾼다.
            switch_type = (switch_type + 1) % 4

if __name__ == "__main__":
    tables_3 = [[0,1,2], [3,4,5], [6,7,8]]
    tables_4 = [[0,1,2,3],[4,5,6,7],[8,9,10,11],[12,13,14,15]]

    traverse = SnakeTraverse(3, tables_3)
    traverse.traverse()

    traverse = SnakeTraverse(4, tables_4)
    traverse.traverse()

Global company의 Global Promotion 작업을 마무리 하며...

naggingmachine — Fri, 13 Dec 2013 11:56:50 +0900

그동안 약 5개월간 진행된 글로벌 프로모션 서비스의 개발 및 운영이 모두 완료되었다. 4개의 기업과 계속해서 영어로 커뮤니케이션하고 주기적으로 컨퍼런스콜을 하는 등 나에게는 잊지 못할 경험과 한단계 성숙할 수 있는 기회를 제공해 주었다. 이번 프로젝트를 통해서 알게되고 느낀점들을 적어보도록 한다. 나중의 나에게, 또는 누군가에게 도움이 될 수 있지 않을까 생각한다.

- 미국과의 작업은 역시나 시차 문제로 인해서 항상 어려움이 따른다. 이번 프로젝트의 경우에는 미국 시간 기준(PCT)으로 진행되었고, 심지어 미국 내에서도 시차가 있어서 약속을 잡고 진행하는게 쉽지 않았다. 더구나 우리 회사에는 컨퍼런스콜을 할 수 있는 별도의 장비가 마련되어 있지 않아서 매번 스카이프를 이용했는데 네트워크의 상태나 마이크의 상태에 따라서 회의가 취소되기도 했다. 시차가 다르면 한쪽은 항상 고생한다는 거.

- 글로벌 서비스는 역시나 어느 타임 존에 맞추느냐도 매우 중요하다. 예를 들면, 특정 이벤트의 시작과 끝을 어떻게 맞출 것인지. 이번의 경우에는 약간 유동적이었던게, 이벤트를 알리는 것은 주로 미국 시간 기준이었지만, 공식적인 알림은 UTC 기준으로 했다. 몇개의 국가만 선택되었어도 조금은 다르지 않았을까. 그것이 맞는지 틀린지는 아직도 잘 모르겠다. 다수의 사용자에게 가장 잘 알려질 수 있는 시간이 좋다고 생각이 되지만, 꼭 그렇지도 않을 수 있다. 특히 이번 프로모션에는 투표(voting) 시스템이 도입되어 있었으므로 시간은 굉장히 민감할 수 밖에 없다.

- 영어 때문에 오해가 생긴다. 영어를 할 수 있다고 생각하지만 역시나 네이티브는 아니므로 화상 회의나 전화 통화등을 통해 중요 사항이 결정되는 시점에서는 신경이 곤두설수밖에 없고. 마지막에 정확하게 이해했느냐 또는 이대로 결정하겠다라는 말에는 반드시 관련된 내용을 이메일로 공유해달라고 요청을 했다. 내가 요구하는 사항도 컨퍼런스콜 전 또는 후에 반드시 이메일을 통해 관련 내용을 숙지하도록 했다. 하지만 그렇게 했는데도 불구하고 특정 사안에 대한 책임을 따지게 되는 상황이 발생하기도 했는데, 참 난감했다. 다행히도 이메일 로그 덕분에 원만하게 해결되었지만 역시나 쉽지 않다. 그리고 영어 단어의 미묘한 차이를 감지하지 못하는 것도 문제다. 나는 역시나 사전을 통해 학습을 했고, 말이라는게 미묘해서 상황에 따라 다양하게 해석되는 면이 있으므로 이 부분을 간과해서도 안된다. 커뮤니케이션은 원래 어려운데 하물며 외국말은 더 하겠지.

- 24/7 작동하는 서비스를 구축하기 위해 클라우드의 도입을 고려했고 최종적으로는 Google AppEngine(GAE)를 선택했다. 이유는 관리가 용이하고 개발이 쉬우며, 내 입장에서는 서버에 대한 고려가 거의 없이도 시스템을 구축할 수 있었기 때문이다. 다만 비용이 다소 높아 사용자의 숫자에 따라서 지나치게 높은 금액이 지불될 수 있다는 점이 문제가 되었다.(다행히도 그런 문제가 발생하지 않았다) 기대했던대로 서버는 안정적으로 작동하였고 모든 이벤트를 손쉽게 관리하고 처리할 수 있었다. 하지만 GAE는 로그를 별도로 관리하거나 DataStore에 저장된 데이터를 분석하기가 용이하지 않아, 이 부분은 GAE에 의존하기 보다는 별도의 관리 도구를 개발하는 방향으로 문제를 해결했다.

- GAE는 사용하는 만큼 비용을 지불하는 서비스지만, 그렇다고 해서 모든 서비스를 무한정 사용할 수는 없다. 예를 들면, 이메일은 하루에 5,000(??)정도밖에 안되고 그 이상에서는 오류가 발생한다. 상식적으로는 무한정 보내는게 맞다고 생각이 되지만 돈과 상관없이 제한이 걸려있다. 다른 몇가지 서비스들도 마찬가지다. 해결하는 방법은 Billing시에 Premium Account로 등록하여 제한을 없애거나 숫자를 높일 수 있다. 하지만 Premium Account로 등록하기 위해서는 별도의 오프라인 검증 과정을 구글과 함께 진행해야 하는 번거로움이 있다. 또한 온라인에서 간단하게 신청할 수 있도록 되어 있지만 아무리 기다려도 소식이 없어 결국 구글 코리아의 도움을 받아 진행하게 되었다는 점은 다소 의아했다. 그런데 이 과정에서 이메일은 SendGrid라는 3rd party 툴을 활용하는게 더 낫다는 사실도 알게 되었으며 구글이 적극적으로 이 방법을 추천했다. GAE는 외부 서버로의 호출이 자유롭기 때문에(마찬가지로 비용 지불) 얼마든지 외부의 자원을 활용할 수 있다. SendGrid를 사용하면 메일을 무한정 보낼 수 있다.

- 페이스북 로그인은 가끔 실패한다. 사용자가 웹 브라우저에서 페이스북으로 로그인을 하면 Access Token을 얻을 수 있는데, 서버에서는 해당 Access Token을 이용하여 사용자를 인증한다. Python 라이브러리를 이용하면 Facebook 서버에서 사용자 계정 정보를 가져오고 해당 사용자가 정상 사용자인지를 판단할 수 있는데, 문제는 가끔(?) 페이스북 로그인이 실패할 때가 있다. 처음에 개발할 때에는 Facebook API에서 실패가 발생하지 않을거라고 생각했기 때문에 이 부분에 대한 고려를 하지 못했다가 나중에 반영했다.

- 로그를 잘 남겨야 한다. 서비스를 운영하면 다양한 상황에 처하게 된다. 악의적인 공격이라든지 여러가지 시도들. 이런 것들을 사전에 파악하기 위해서 로그를 남기게 되는데, GAE에서는 로그의 양에 따라서 서버 비용이 발생하므로(그렇게 크지는 않음) 로그를 스마트하게 남겨야 한다. 물론 이건 비용 뿐만 아니라 분석할 때에도 고생하게 되니까 당연한 일이겠지만. 이번 프로젝트의 경우 로그를 지나치게 남긴 면이 있어서(분석에 도움은 됐다), 나중에 좀 후회하기도 했다. :-)

- 비용을 줄이는데 캐시(Cache)만 한게 없다. 서버를 처음 설계하면서부터 가장 중점적으로 염두해두었던 부분은 캐시의 활용에 관한 것이었다. 비용과 효율성, 속도에 이르기까지 모든 면에서 큰 영향을 미치기 때문이다. 따라서 사용되는 모든 데이터의 생명주기를 분석하고 각 데이터에 대해서 valid, invalid를 잘 구분해 두었다. 덕분에 서버에서 hit ratio는 80% 수준이었고 비용도 매우 절감할 수 있었다. hit ratio가 더 높아지지 못한데에는 사용자가 투표를 할 때마다 갱신되는 정보를 어쩔 수 없었기 때문이다.

- 버전 관리는 필수다. 절대로 발생해서는 안되지만 아무래도 혼자서 개발하다 보니까(단위 테스트를 수행했음에도 불구하고), 라이브 서버에 올린 최종 버전에 문제가 발생하기도 했다. 올려보면 error 로그가 주루룩 뜨고 나도 눈물이 주루륵 난다. ㅠㅠ 다행히도 GAE는 모든 instance에 버전이 존재하므로 해당 버전으로 급하게 롤백하면 된다. 그래서 버전 이름을 명확하게 지정하는게 필요한데, 대략 이런 식이었다. [서비스-v버전-날짜] 그리고 오래된 버전이라고 하더라도 하나의 버전에는 로그가 함께 저장되어 있으므로 섣불리 삭제하지는 말자. 로그 복구가 안된다.

- 로컬에서 충분히 테스트하자. GAE는 로컬 서버만으로도 거의 모든 기능을 테스트할 수 있다. 비용을 측정하기 위해서라도 로컬 테스트가 필요하다. 단위 테스트에도 필요하다.

- 블랙리스트를 잘 활용하자. GAE는 최대 100개까지 IP 기준으로 블랙리스트를 등록할 수 있다. 서버를 운영해보니 악의적인 접근들이 있었고, 상당히 많은 IP를 블록할 수 밖에 없었다.(물론 IP를 차단하기까지 로그 분석을 해야 하는 수고로움은 따른다) 다행히도 GAE가 최근 시간 기준으로 접근이 많은 IP들을 추천(?)해주기 때문에 몇가지 후보군들을 뽑아볼 수 있다.

- Index를 잘 설계하자. DataStore는 RDB 형태의 쿼리가 불가능하다. 모든 데이터에 조건을 걸어서 검색하는건 불가능하다. 이때 검색이 되느냐 안되느냐의 기준은 Indexing을 사전에 설정해두었느냐 아니냐에 따라 다른데, 나중에 조건 검색을 하려고 했더니 검색이 안된다는 둥, 그래서 망했다는 둥의 어려움을 겪게 된다. 따라서 본인이 관심을 갖는 데이터의 종류와 성격, 그것들간의 관계를 사전에 잘 파악해두고 당연히 Index에 속할 수 있도록 해야 한다. 나 같은 경우에는 정말 필요한 데이터였는데 index가 걸려있지 않아 검색이 불가능했고 결국에는 데이터를 따로 구해서 연산을 통해 처리하는 불편함이 있었다. 머리가 멍청하면 몸이 고생이다. index의 중요성은 MySQL만 사용한 사람은 모른다. 힝~

- 서비스 운영에는 책임감이 따른다. 이미 세상 사람 모두가 알고 있는 진리라고 할까. 그것이 아무리 간단하고 보잘것 없어도 다른 사람이 사용할 수 있도로 세상에 내 놓았다면 거기에는 무한의 책임이 따른다. 그리고 그 책임을 어느 정도까지 본인이 실감하고 있느냐에 따라서 서비스는 더 나아지기도 또는 망가지기도 한다. 2000년도에 처음으로 EBS에 납품되는(10만개 분량) 소프트웨어를 개발했을 때에 느꼈던 심리적 부담감, 2001년도에 안철수 연구소에서 백신 치료 데이터(최소 1,000만명 기준)를 작성하면서 매주 엔진데이터 갱신되기 전에 느꼈던 심리적 부담감. 이전 직장에서 사람의 목숨과 국가의 미래가 걸려있다는 부담감은 매번 내가 일에 집중할 수밖에 없는 이유이기도 했다. 이번 프로젝트는 대기업의 프로모션일 뿐만 아니라, 그것이 SNS를 통해서 무한 공유될 수 있다는 부담감이 너무 커서 항상 노트북을 소지하고 다니고, 새벽에 중간에 깨어나서 로그 확인하고, 매일 아침이면 제일 먼저 메일부터 확인하는 등 심리적 부담감이 컸다. 더구나 도와줄 사람이 없다는게 함정. 세상의 모든 서비스들이 문제 없이 돌아갈 수 있도록 애쓰는 보이지 않는 분들에게 박수를 보내고 싶다. :-)

이외에도 너무 많은 일들이 있었지만, 모두 다 언급하기에는 개인적인 치부(?)가 너무 많아 힘들것 같고, 결론적으로는 이번 미션이 잘 완수된것 같아 다행스럽게 생각하고 있다. 긴 미션을 통해 1등으로 선발된 분께도 축하의 말씀을 드리고, 그동한 수고한 GAE에도 감사의 말씀을 전하고 싶다. 사실 개발에는 오랜 시간이 걸리지 않았다. Python도 땡큐~

인생의 깊이

naggingmachine — Thu, 12 Dec 2013 00:44:04 +0900

人生의 깊이는

삶에 대한 진지한 고민의 정도

한낱 인간에 불과한 나를

유일한 존재로 만들 수 있는 방법은

나를 아는것

Google AppEngine의 데이터를 export 하는 방법

naggingmachine — Tue, 10 Dec 2013 10:52:15 +0900

Google AppEngine의 데이터를 Export 하는 방법은 어렵다. 어려워도 너무 어렵다. 왜 이렇게 어렵게 만들어 놓았는지 모르겠지만, 너무 어렵다. 하지만 방법이 없지는 않다. 원한다면 다양한 방법으로 export할 수 있다.

우선 구글이 추천하는 방법이 있다.

https://developers.google.com/bigquery/articles/datastoretobigquery

구글에서도 알고 있듯이 일반적인 패턴은 DataStore에 데이터를 생성한 다음, 만들어진 데이터를 분석하기 위해서 아마도 BigQuery와 같은 쿼리 기반의 데이터 저장소로 옮겨야 할 것이다. 그런데 이게 방식이 좀 어려운게 DataStore에서 스키마를 작성하는 것만으로도 곧바로 BigQuery로 넘어가면 좋으련만 그렇게 되지 않고, DataStore -> Cloud Storage -> BigQuery 이런식이다. 그러니까 DataStore에서 Cloud Storage로 export하고, BigQuery가 Cloud Storage에서 데이터를 import하는 방식이다. 여기에 추가적으로 권한 문제까지 있어서 Google API Console등에서 권한을 적절하게 설정하지 않으면(권한 설정하려면 Billing까지 등록해야 한다. ㅠㅠ), 실행되지가 않으므로 주의해야 한다.

다행히도 구글이 이를 위한 아주 간단한 툴을 제공하고 있다는 소식이다! 베타테스터로 등록하면 사용해볼 수 있다고 하는데, 나도 등록 신청을 했다

https://docs.google.com/spreadsheet/viewform?formkey=dHdpeXlmRlZCNWlYSE9BcE5jc2NYOUE6MQ

그런데 이 방법 말고 그냥 DataStore에서 Cloud Storage로 export한 다음 그걸 로컬로 불러들여와서 분석하는 방법도 있다. 하지만 이것도 간단하지는 않다.

http://gbayer.com/big-data/app-engine-datastore-how-to-efficiently-export-your-data/

여기에 추가적으로 GAE에서 생성한 로그를 export해야하는데(로그는 소중하니까), 이 방법도 여의치가 않다. log2bq라는 툴이 있다. 그런데 구글이 제공한 log2bq는 여러가지 제약 사항이 있어서 이를 개선한 오픈소스 프로젝트를 개발해봤다. l2bq(https://github.com/kevinseo/l2bq)인데 자바로 되어 있다. 하지만 전체적인 논리를 이해하는데에는 큰 무리가 없을 것이다.

ElasticSearch를 이용한 PDF와 Word 문서 검색 서비스 만들기

naggingmachine — Sun, 1 Dec 2013 18:08:37 +0900

PDF 문서를 검색하는 방법은 다양하다. Windows의 탐색기를 이용하는 방법에서부터 Google Desktop Search를 이용하는 방법도 있다. 물론 그 외에도 로컬 데스크톱의 문서를 검색해주는 다른 도구를 사용할 수도 있다. 하지만 조직내의 PDF (Word도 가능해요. Tika에서 지원하는 문서를 참고하세요)를 검색해야 하는 방법을 제공해야 한다면 어떻게 해야 할까? 얼마전 누군가가 그런 고민을 하고 있던터라 '그거 그렇게 어렵지 않을텐데요..'라는 생각을 하고선 만들어 봤다. ElasticSearch(이하 ES)에 대해서 잘 알고 계신분께는 큰 도움이 안될 수 있도 있고, 어쩌면 내가 한 방법이 틀릴수도 있다는 사실을 미리 말씀드린다. 구축에 필요한 시간은 서버 설치 포함해서 3시간 정도이다.

ES는 루씬 기반의 검색 엔진이다. 그냥 Json 데이터를 넣어주기만 하면 알아서 인덱싱을 걸어주고 웹 API를 호출하는 것만으로도 구글과 같은 검색 엔진을 구축할 수 있다. 구현할 시스템의 전체적인 구조는 다음과 같다.

1. ES를 활용한 문서 검색 서버

- ES

- 텍스트 추출을 위한 TIKA 라이브러리

- 분석 자동화를 위한 PHP 스크립트

2. 사용자가 입력한 키워드로 문서를 검색할 수 있는 검색 전용 사이트

- Bootstrap을 이용한 사이트 구축

3. 검색에 사용할 문서를 자동으로 등록할 FTP 서버 또는 공유 폴더

- Samba 활용

문서 검색 서버는 다음과 같은 순서대로 작동한다.

1. 문서를 수집하여 특정 폴더에 저장한다.

2. 주기적으로 해당 폴더에 올려진 문서를 분석한다.

2-1. 하나의 문서를 선택한 후 메타데이터(작성자, 생성일, 문서 종류 등)와 본문(텍스트)를 추출한다.

2-2. 이미지로 저장된 PDF 문서의 경우에는 OCR 엔진으로 텍스트를 추출한다.

3. 생성된 JSON 데이터를 ES에 등록한다.

검색 전용 사이트는 다음과 같이 작동한다.

1. 사이트가 로드되면 전체 인덱싱된 문서의 개수를 가져온다.

2. 사용자가 키워드를 입력하면,

2-1. AND 검색인지 OR 검색인지를 판단한다(체크박스 형태로 제공, ES의 기본검색은 OR임)

2-2. "_search?q=" 쿼리를 통해 서버로 전달

2-3. JSON 형태로 결과를 전달 받는다.

3. JSON 데이터를 분석하여 화면에 리스트 형태로 뿌려준다.

ES 설치는 구글神을 통해 쉽게 알 수 있는데, 한글 문서를 분석하기 위해서는 반드시 인덱싱 저장공간을 생성할 때 한글 형태소 분석기를 플러그인으로 등록해야 한다. 이와 관련된 자세한 내용은 다음 링크를 참고하자.

>> ElasticSearch 설치 및 샘플 사용기 (http://mimul.com/pebble/default/2012/02/23/1329988075236.html)

>> ElasticSearch로 로그 검색 시스템 만들기 (http://helloworld.naver.com/helloworld/273788)

>> elasticsearch 설치 및 한글형태소분석기 적용 따라하기 (http://jjeong.tistory.com/711)

또는 이전에 올린 글처럼 자바로된 한글 형태소 분석기를 통해 본문을 형태소 분석한 후 해당 텍스트를 저장하는 방법도 있을것 같다.

>> 형태소 분석기로 웹 문서 파싱하여 단어만 추출해보자 (http://naggingmachine.tistory.com/823)

세상에는 참 福 받아야 하는 사람들이 많다. 소중하게 공유한 자료는 소중하게 공유하는 것으로~

ES 설치는 그렇다고 하더라도 PDF에서 텍스트를 어떻게 추출해야 할까?라는 고민이 될텐데, 사실 처음부터 별다르게 고민하지도 않았다. 어딘가에서 이미 오픈소스로 만들었을테고 이렇게 중요한 라이브러리인 경우에는 보통 Apache 프로젝트로 등록되어 있는 경우가 많으니까. 역시나 찾아보니 있다. tika! 그냥 가져다가 옵션 주고 사용하면 된다. 메타데이터는 XML이나 JSON 형태로 추출이 가능하고 텍스트도 별도로 추출할 수 있다. 이 옵션들을 이용하면 인덱싱에 사용할 데이터를 JSON 으로 구성할 수 있고 만들어진 데이터를 curl을 이용하여 ES에 등록하면 된다.

문서를 분석하기 위해서 사용한 스크립트는 다음과 같다.

이 코드를 살펴보기 위해서는 다음과 같은 디렉터리 구조임을 이해해야 한다.

Search (directory, 루트 디렉터리)

--> elasticsearch (directory)

--> elasticsearch-0.90.7 (directory)

--> create_index.php (file)

--> tika-app-1.4.jar (file)

--> home (directory, 웹 사이트 홈)

--> pdf (directory, 분석할 문서가 있는 디렉터리)

--> download (directory, 분석하고 난 후 다운로드가 가능한 디렉터리)

다음은 create_index.php의 소스 코드이다.

<?php

$dir = "../pdf";

$count = 0;

changeDirFileNames($dir);

if ($handle = opendir($dir)) {
	while(false !== ($readdir = readdir($handle))) {
		if ($readdir != '.' && $readdir != '..' && (strpos($readdir, '.pdf') !== FALSE || strpos($readdir, '.doc') !== FALSE)) {
			$path = $dir . '/' . $readdir;
			if (is_file($path)) {
				process($path);
			}
		}
	}
	
	closedir($handle);
}

// 디렉터리의 모든 파일 이름에서 열리지 않는 문자를 _로 대체한다.
function changeDirFileNames($dir) {
	$order = array("(", "&", "'", ",", " ", "+" , "@", "-", ")");

	if ($handle = opendir($dir)) {
		while(false !== ($readdir = readdir($handle))) {
			if ($readdir != '.' && $readdir != '..' && (strpos($readdir, '.pdf') !== FALSE || strpos($readdir, '.doc') !== FALSE)) {
				$path = $dir . '/' . $readdir;
				if (is_file($path)) {
					// 파일 이름 변경 시도
					$new_path = str_replace($order, "_", $path);
					if ($path != $new_path) {
						exec("mv \"" . $path . "\" \"" . $new_path . "\"");
					}
				}
			}
		}
		
		closedir($handle);
	}

}


function process($filename) {
	ob_start();
	passthru("java -jar tika-app-1.4.jar -t ". $filename);
	$text = ob_get_clean();
	$text = trim(preg_replace('/\s+/u', ' ' , $text));

	ob_start();
	passthru("java -jar tika-app-1.4.jar -j ". $filename);
	$json = ob_get_clean();

	$json_arr = json_decode($json, true);
	$json_arr['text'] = $text;

	// 파일 이름을 title로 넣어준다.
	$order = array(".", "_", "/");
	$title = str_replace($order, " ", $filename);
	$json_arr['title'] = $title;

	$str = json_encode($json_arr);

	exec("curl -silent -XPOST 'http://localhost:9200/hr/file/' -d '" . $str . "'");

	if (strlen($text) == 0) {
		echo $filename . " might be image.\n";
	}
	else {
		echo $filename . " processed\n";		
	}

	exec("mv \"" . $filename . "\" ../download");
	return "";
}
?>

이 소스 코드를 실행하면 pdf 디렉터리에 있는 문서들을 가져다가 ES에 등록하는데, 인덱스의 이름은 hs 이며, 디렉터리는 file 이고 문서의 아이디는 자동 생성(생략되어 있음)하도록 했다. 만약 문서의 이름에 따라서 업데이트를 하고 싶다면 문서의 이름을 hash 값으로 사용해야한다. 그렇지 않으면 문서가 중복해서 등록된다.

이제 문서의 분석이 준비되었으며, 마지막으로 구글과 같은 검색 인터페이스를 제공하기만 하면 된다.

나의 경우에는 PDF로 작성된 이력서를 검색하기 위한 용도였으므로 다음과 같은 화면을 구성하였다.

키워드들이 포함된 가능한 많은 문서를 검색해 달라는 요구 사항이 있어서 키워드 양쪽에 *를 추가해서 검색하고 있으며, 페이징 기능을 추가하지 않았다(가져오는 갯수는 10000으로 설정). 원한다면 얼마든지 코드를 편집할 수 있을 것이다.

다음은 index.html 파일의 소스 코드이다.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>PDF Search System</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <!-- Loading Bootstrap -->
    <link href="css/bootstrap.css" rel="stylesheet">

    <!-- Loading Flat UI -->
    <link href="css/flat-ui.css" rel="stylesheet">
    <link rel="shortcut icon" href="images/favicon.ico">

    <!-- HTML5 shim, for IE6-8 support of HTML5 elements. All other JS at the end of file. -->
    <!--[if lt IE 9]>
      <script src="js/html5shiv.js"></script>
    <![endif]-->
  </head>
  <body>
    <div class="container">
      <div class="demo-headline">
        <h1 class="demo-logo">
          Resume Search
        </h1>
        <div id="count_index"></div>
        <br><br>
          <div class="span3"></div>
          <div class="span3">
            <input type="text" class="login-field" value="" placeholder="Keyword" id="search-keyword" />
          </div>        
          <div class="span2">
            <a class="btn btn-primary btn-large btn-block" href="#" id="search-button">Search</a>
          </div>
        <br><br><br>
        <div class="span12"><input type="checkbox" name="chk_operator" id="chk_operator" value="OR 검색">OR 검색        
        <br><br>
        <div id="count_result"></div>
      </div> <!-- /demo-headline -->
      <div class="span12">
        <div class="block">
          <div id="result_table">
          </div>
        </div>
      </div>

    <!-- Load JS here for greater good =============================-->
    <script src="js/jquery-1.8.2.min.js"></script>
    <script src="js/jquery-ui-1.10.0.custom.min.js"></script>
    <script src="js/jquery.dropkick-1.0.0.js"></script>
    <script src="js/custom_checkbox_and_radio.js"></script>
    <script src="js/custom_radio.js"></script>
    <script src="js/jquery.tagsinput.js"></script>
    <script src="js/bootstrap-tooltip.js"></script>
    <script src="js/jquery.placeholder.js"></script>
    <script src="http://vjs.zencdn.net/c/video.js"></script>
    <script src="js/application.js"></script>
    <!--[if lt IE 8]>
      <script src="js/icon-font-ie7.js"></script>
      <script src="js/icon-font-ie7-24.js"></script>
    <![endif]-->
    <script type="text/javascript">
      var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
      document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
    </script>
    <script type="text/javascript">
      try{
        var pageTracker = _gat._getTracker("UA-19972760-2");
        pageTracker._trackPageview();
        } catch(err) {}


      $("#search-button").click(function() {
        search();
      });

     
      $("#search-keyword").live('keypress', function(e) {
        if (e.which == 13) { search(); }
      });

      $(document).ready( function() {
          update_count();
      });
        
      // count 업데이트
      function update_count() {
        $.ajax( {
          url: 'http://192.168.1.198:9200/hr/file/_count',
          dataType:'json',
          type: 'get'
        }).done(function(data) {
          if (data != null) {
            html = "총 " + data.count + "개의 문서가 색인되어 있습니다.";
            $("#count_index").html(html);
          }
        }).error(function(e) {
          alert("error");
        });
      }

        
      // 검색 메뉴 실행
      function search() {
        var keyword = $("#search-keyword").val();

        if (keyword.length == 0) {
          alert('입력된 키워드가 없습니다.');
          return;
        }

        var start = new Date().getTime();
          
        var checked = "&default_operator=AND";
        if ($("#chk_operator").is(':checked')) { checked = "&default_operator=OR"; }

        $.ajax( {
          url: 'http://192.168.1.198:9200/hr/file/_search?size=10000&q=*' + keyword + '*' + checked,
          dataType:'json',
          type: 'get'
        }).done(function(data) {
          if (data != null) {
            var count = 0;
            var html = "<table class='table table-striped'><thead><th width=30>순서</th><th>파일이름</th><th width=50>구분</th><th width=150>생성시간</th></thead>";
            
            var end = new Date().getTime();
            var time = end - start;
            
            html_count = "총 <b>" + data.hits.hits.length + "</b>개의 문서가 검색되었습니다.<br>" + (time/1000) + "초의 시간이 소요되었습니다.";
            $("#count_result").html(html_count);
              
            $.each(data.hits.hits, function(index, value) {
              count++;
              var docu_type = "문서";

              if (value["_source"]["text"] == "") { docu_type = "이미지"; }
	
              html += "<tr><td>" + count + "</td><td>" + "<a href='../download/" + value["_source"]["resourceName"] + "' target=_blank>" + value["_source"]["resourceName"] + "</a></td><td>" + docu_type + "</td><td>" + value["_source"]["created"] + "</td></tr>";
            });
            html += "</table>";
            $("#result_table").html(html);
          }
        }).error(function(e) {
          alert("error");
        });
      }
    </script>
  </body>
</html>

AppInventor2 소스 코드 구동시키기

naggingmachine — Mon, 21 Oct 2013 20:17:46 +0900

예전부터 AI2를 직접 서버에서 구동도 하고 가능하다면 오픈소스인만큼 소스 개선에도 참여하고 싶다는 생각이 있었는데, 오늘 약간의 시간이 허락하여 소스 코드를 다운받아서 빌드도 해보고 테스트도 해보았다.

테스트 방법은 우선은 로컬에서 소스 코드를 빌드한 다음, 문제가 없는지 확인한 후 구글 앱 엔진과 클라우드 서버에 코드를 올려서 원격으로 작업을 해보는 것이었는데, 생각만큼 어렵지도 않고 잘 되는것 같다.

본 내용의 모든 출처는 MIT에서 운영하는 AppInventor Source Repository에 있음을 밝힌다. 이 글에서 다루지 못하는 모든 세부적인 내용들을 해당 페이지에서 다루고 있으니 차근차근 따라해보면 된다.

http://appinventor.mit.edu/appinventor-sources/

소스 코드를 변경해보기 위해서 우선 AI2 소스 코드를 fork 했다. fork한 소스 코드는 아래 링크에서 다운로드

https://github.com/kevinseo/appinventor-sources/archive/master.zip

사실 맥에서는 다음 링크에 있는대로 따라하기만 하면 된다.

How to build App Inventor from MIT Sources

나는 아주 간단한 과정을 통해서 로컬에서 작동하는걸 확인해보았고, 곧바로 구글 앱 엔진과 클라우드 서버(BuildServer 용)를 만들었다.

우선 빌드 서버는 Microsoft Azure에서 구동시켜봤는데, OS는 Ubuntu 12.0을 기준으로 했다. 새로운 OS가 설치되었다고 가정하고 다음과 같이 일련의 명령을 실행한다.

$ sudo apt-get update

$ sudo apt-get install git

$ sudo apt-get install ant

$ sudo add-apt-repository ppa:webupd8team/java

$ sudo apt-get update

여기서 주의할 점은 Java의 SDK의 경우 반드시 Oracle에서 공식적으로 배포하는 SDK를 설치해야만 정상적으로 apk 파일이 장비에 등록이 된다고 한다. Open SDK를 설치하지 않도록 한다.

$ sudo apt-get install oracle-java7-installer

소스 코드를 다운받아서 압축 해제 후,

$ ant clean

$ ant

나의 경우에는 ant 명령을 내렸을 때 build failed가 떴다. 만약 WARNING: YAIL compiler - AAPT execution failed. 라는 오류가 뜬다면, 다음 두 명령을 실행해서 관련된 라이브러리들을 설치해준다.

$ sudo apt-get install lib32z1

$ sudo apt-get install lib32stdc++6

그리고 차례대로 다음 명령들을 실행한다.

$ ant PlayApp

$ cd buildserver

$ ant RunLocalBuildServer

또는 백그라운드 프로세스를 돌리기 위해서 다음 명령을 실행한다.

$ nohup ant RunLocalBuildServer > ../../buildserver-log.out &

서버가 잘 작동하는지는 다음 페이지를 방문해서 확인할 수 있다.

http://localhost:9990/buildserver/vars

http://localhost:9990/buildserver/health

참고로 AI2 버전을 사용하고 싶다면, 다음 사이트를 방문하면 된다.

http://ai2.appinventor.mit.edu/

Facebook App을 이용해서 Wall에 글쓰기 How write to Facebook wall via Facebook App

naggingmachine — Mon, 23 Sep 2013 14:50:00 +0900

아주 아주 간단한건데, 그래도 검색을 해야 해서 남겨본다.

GET method로 다음과 같이 Graph API를 호출해주면 간단하게 링크와 메시지를 남길 수 있다. 게임같은 곳에서 결과를 공유할 때 사용하면 유용하겠다.

아래는 https://graph.facebook.com/feed 로 호출할 때 연결되는 GET parameter들이다.

method:
POST
link:
[링크 주소, 예) http://www.naver.com]
message: [메시지, 예) 안녕~]
format:
json
suppress_http_code:
1
access_token:
로그인을 통해서 얻은 Facebook Access Token 값

반드시 Facebook App 권한 설정에서 extension 권한에 publish_stream을 추가해야 한다.

끝.

# graph api explorer : https://developers.facebook.com/tools/explorer/205983426237011/?method=POST

벤처를 돌아보며..

naggingmachine — Mon, 23 Sep 2013 06:55:47 +0900

언제든지 옆에두고 참고하고 싶은 글이다.

https://medium.com/p/72c6f8bec7df

---------

Postmortem of a Venture-backed Startup

Lessons Learned from the rise and fall of @Sonar

For those unfamiliar, Sonar Media Inc. was a mobile app created to help make the world a friendlier place. Our mobile app buzzed in your pocket when friends were near and ushered in a new wave of “Ambient Social Networking” companies. Downloaded by millions of people all over the world, Sonar was promoted by Apple and Google in 100+ countries, won numerous awards such as runner-up at TechCrunch Disrupt and Ad:Tech Best Mobile Startup, raised nearly $2,000,000 from prominent angels and VCs, and was featured on more than 300 publications including the New York Times, CNN, CNBC, TechCrunch, and TIME.

And yet, we failed.

We did lots of thing right and lots of things wrong at Sonar. Below I do my best to share a few of our lessons learned.

The Search For Product/Market Fit

“Make something people want.” —Paul Graham

Listening to your users: False positives

We launched Sonar with Facebook, Twitter, and Foursquare support. Shortly thereafter, users buffeted us with requests for Linkedin integration. Ostensibly, they wanted to use the app to meet fellow professionals.

Eager to please, we rushed to add Linkedin. The net effect? Nada. My guess is that the people asking were not actual users, but rather people that “wanted to be” users. We had mistaken noise for signal.

Lesson learned:

“I would use your product if only you had X feature” is a dangerous signal to follow. Users do their best to anticipate what they want before they’ve seen it but, like entrepreneurs, they are often wrong.

Enterprise companies should validate demand by asking customers to put their money where their mouths are. Media and social networking companies should double down on analytics to find, observe, and build for actual user behavior.

Listening to your users: False negatives

One of the most requested features was a “map like foursquare” for our check-ins. Instead, we appended a simple “@Sonar” to content that users shared from our app. Although we had designs for a map, we never got around to building one. We were too busy building the future of ambient social networking!

Mistake. People didn’t like the bland “@Sonar” text string so they stopped sharing updates from Sonar. Their friends never engaged with our updates in the first place. Facebook noticed this and started hiding our posts. Instead of optimizing for actual user behavior, we spent countless whiteboarding sessions trying in vain to design an alternative.

Lesson learned:

You are probably not the Steve Jobs of ______.

Removing friction from existing user behaviors (e.g. checkins) almost always has a higher ROI than building castles in the sky (e.g. hypothesizing about your API). Find all the dead ends/local maxima in your current products before building new ones!

Growth vs. Engagement

We received conflicting advice from lots of smart people about which is more important. We focused on engagement, which we improved by orders of magnitude. No one cared.

Lesson learned:

Growth is the only thing that matters if you are building a social network. Period. Engagement is great but you aren’t even going to get the meeting unless your top-line numbers reach a certain threshold (which is different for seed vs. series A vs. selling advertising).

Things I Wish I Spent Less Time On

“Focus is saying no to 1,000 good ideas.” — Steve Jobs

Events

I realized the error of my customer acquisition strategy as I awkwardly made my way through a small Meetup I had just pitched. It was 11pm on a Tuesday, I was exhausted and still had real work to do once I got home. Yet there I was, in a shitty bar trying not to skewer anyone with my Sonar sign as I dodged person after person asking me to install THEIR app.

Lesson Learned:

Events are for research, business development, and hiring; NOT for getting to 10,000,000 downloads.

Brands & Agencies

When MTV, Kraft, Digitas, and the like reached out to us we weren’t sure what they wanted. It took us at least 10 meetings to realize that, rather than delivering us millions of their customers on a silver platter, they were keeping tabs on us so that they could get access to OUR audience if we ever took off!

Lesson Learned:

Be polite, but postpone brand and agency “intros” until you’ve built your own audience. If you build it, they will come (and pay).

Corollary: Investors know this. You sound stupid when you talk about your impending “big deal” with “XYZ brand” that’s going to drive massive customer acquisition and revenue.

Side projects

In the winter of 2011, we signed a partnership w/ Wired magazine to demonstrate our technology by providing visitors of their Times Square popup store with personalized in-store product recommendations.

That “small side project” cost us 6 weeks of development and delivered no appreciable benefit other than getting to hang out with the cool people at Wired.

Lesson Learned:

You do not have 20% time. Identify your top three priorities. Throw away numbers two and three.

Competition

In the run up to SXSW 2012 when the insider media had fabricated Highlight as heir to the throne and some of our more fair weather investors had written us off, my confidence was against the ropes. We reordered our roadmap to rush out comparable features but were now BEHIND. I put on my best brave face but inside my gut was rotting away. I still remember thinking on the flight to Austin “fck, we had it, and now we are going to lose it.”

Oops! Highlight never went anywhere but we definitely wasted a ton of energy and sleep “responding to the threat” when we should have been figuring out how to make our own business work.

Lesson Learned:

Be steady at the wheel. The only way one startup can kill another startup is by getting into the other’s head and leading them off a cliff.

If you don’t believe me, try this proof. Are your competitors releasing a bunch of the same features that you have on your roadmap? Yes? Do you know what consumers want*? No? Great, then neither do your competitors. Get back to figuring out what users want!

*Hint: If you did, you would already have traction.

Selling the company

When the ambient social networking space iced over in the spring of 2012, Sonar’s controlling investors decided it was time to “flip the asset.” They connected us with a daily deals company looking for “Big Data” solutions. We stopped working on the app and devoted all of our resources to repacking our backend technology to solve BigCo’s problems. Instead of pairing down expenses to extend our dwindling runway, we piled on hires and ramped up our infrastructure.

The daily deals space imploded but we spent nearly nine months, dozens of meetings, and several hundred thousand dollars “selling” Sonar into a company that nearly went bankrupt.

Lesson Learned:

Companies don’t get sold, they get bought. The best way to get bought is to build something of value. That’s hard to do when you are trying to sell.

Misalignment

We built Sonar out of an incubator that I helped launch in 2010. To be absolutely clear, the incubator was instrumental to getting Sonar off the ground and helped us considerably along the way. Unfortunately, there are a number of structural issues facing incubators and the operators they employ. I address some of these below.

The decoupling of responsibility from control created ambiguity and confusion, tension and frustration for all parties. From day to day decisions such as negotiating an employment contract to company defining ones such as when to sell the firm, alignment was a constant challenge. Occasionally, we were simply at odds.

Perhaps the most detrimental aspect of the incubator model was not its potential for hinderance but its facility as a crutch. As someone responsible for building and running a company that I ultimately didn’t control, it was far too easy to point a finger.

In my opinion, the most tragic example came when our incubator sat on a financing that would have rebooted the company. After nearly a month at loggerheads, our would-be investors gave us 48 hours to “take it or leave it.” In hopes of saving the company, I made an ultimatum: we move forward together or I would have to walk away. No one budged, time elapsed, and our term sheet evaporated. I resigned as promised, blaming them for killing my baby.

Lesson Learned:

As John Burroughs said, “A man can fail many times, but he isn’t a failure until he begins to blame somebody else.” Avoid bad relationships like the plague but when you inevitably find yourself in a difficult partnership, don’t waste precious energy wailing against it. Make it work or move on quickly.

It’s All About People

“The essence of competitiveness is liberated when we make people believe that what they think and do is important – and then get out of their way while they do it.” — Jack Welch

Be practical about team building

We lost our first would-be hire, a fantastic Google engineer. While we were debating his contract, he was taking a job elsewhere. Conversely, we hired another, much less proven, engineer on the spot. While he ultimately wasn’t a great cultural fit and we definitely waited too long to part ways, he was instrumental in getting V1 out the door.

Lesson Learned:

If you are an experienced entrepreneur with lots of options, by all means, hold out. For most first time entrepreneurs, holding out risks never getting off the ground.

In the beginning, established people probably won’t work with you. Prove yourself by finding diamonds in the rough, like yourself. With their help, you can level up your organization and convince the big fish to join.

Culture is your cofounder

We built an amazing team at Sonar. Everyone was extremely smart, passionate, dedicated, and hardworking. We celebrated milestones with tequila. We hung at the beach. Even when times were tough, everyone pushed as far as they possibly could, and then some. I have big love for all of my former colleagues and am confident they feel similarly.

That said, our culture was more of an emergent property than a deliberate choice. Sure, we had brainstorming sessions and posted goals prominently but most of our culture we absorbed from the people with whom we were surrounded ourselves.

Lesson Learned:

Think of culture as a cofounder that is present when you are not. You are decisive, communicative, and respectful but its your culture that helps everyone know how to act when you are out of the room. Give that voice clarity and authority.

The trick is to avoid hollow words. Since a startup’s culture ultimate mirrors that of its founder, maybe the best thing that you can do is work hard to get clear on who you are. Write that down and share it with your team. If you’ve been honest, every action you take will reinforce your values.

Onward

“What we fight with is so small, and when we win, it makes us small. What we want is to be defeated, decisively, by successively greater things.” — Rainer Maria Rilke via Tim O’Reilly

Startups don’t die when they run out of money, they die when their founders let go. I ultimately stepped away from Sonar when I came to the conclusion that, despite all that we had invested, everyone stood a better chance starting anew. It’s difficult to accept, but sometimes you have to concede a battle to win the war.

I am indebted to the hundreds of people that invested their sweat, money, love, and/or time into Sonar, be it three years of labor or a casual phone call. Special thanks to my amazing team, faithful advisors & investors, and supportive family & friends. Finally, huge shout out to the millions of users that gave Sonar a shot. Your stories about meeting your boyfriend on Sonar made it all worthwhile.

We started Sonar with a belief that everyone has the potential to be amazing and that technology can unlock that potential. My experience at Sonar has only strengthened my conviction. I can’t wait to bring everything I’ve learned to bear on what’s next.

Let’s do this.

짧은 주기의 (모바일) 프로젝트 진행하기

naggingmachine — Fri, 23 Aug 2013 18:18:06 +0900

이글의 주제는 "3~4명의 팀원들이 2개월 정도만에 모바일(웹) 서비스 만들기"라고 요약할 수 있겠다.

소프트웨어 마에스트로 프로그램에 참여하는 학생들은 프로그램에 참여하는 순간 멘토와 함께 프로젝트를 진행하게 된다. 2010년부터 시작했으니 4년째 프로그램이 돌아가고 있는데, 매년 프로그램의 운영 방식이 달라지긴 했지만 그래도 만나는 팀원들(3~4명)과 함께 새로운 프로젝트를 진행하기란 여간 까다롭지가 않다. 특히나 짧은 순간에 진행됨에도 불구하고 평가에 있어서 철저한 만큼 멘토로써 내가 해줄 수 있는 가장 큰 선물은 맛있는 저녁이나 간식이 아닌 좋은 평가를 받을 수 있도록 결과물의 완성도를 높이는 일이다. 2달이라고 해봤자. 8주다. 일주일에 두번 만나면 16번의 만남만으로 모든 과정이 정리되어야 한다.

언젠가 한번은 정리해보고 다른 사람들의 의견을 들어보고 싶었던 건데, 혹시나 이 글을 보시고 이견이 있으시거나 나 같으면 이렇게 해볼텐데라고 생각하시는 분들은 가감없이 말씀해주시면 큰 도움이 되겠습니다.

무엇을 어떻게 할 것인가?

멘토와 멘티가 만나게 되는 최초의 접점은 바로 "프로젝트 기획서"다. 그것이 멘토가 제안했든, 아니면 멘티들이 제안했든 우리는 서로에 대해서 잘 알지 못한채로 "프로젝트"에 대해서만 서로의 공감대를 형성한다. 다소 짧은 시간이 주어지는 만큼 평소에 관심있었던 기술이나 서비스등에 호감을 표시하고 매칭이 된다.

1. ICE breaking

멘토링의 첫주는 무조건 ICE Breaking이다. 서로에 대해서 잘 알고 서로의 배경을 알아본다. 그리고 가급적 작은 부분이라도 서로의 공통 관심사를 이끌어내야 서로에 대해서 비로소 공감하고 호감을 갖는다. 그 다음으로는 각자가 원하는 목표에 대해서 알아간다. 나는 주로 이 시점에서 일종의 개인 신상정보 카드 같은걸 작성한다. 일종의 PM으로써 앞으로 어떤 꿈과 희망(비전)을 심어줄지, 어떤 부분들을 채워줄 수 있는지를 명확하게 기억하기 위해서다. 또 내가 받은 첫인상도 함께. 그리고 다른 팀원들과의 관계 형성시에 알아두어야 할 점들을 파악한다. 대부분의 경우 첫번째 모임이 있는 날에는 회식을 한다. 더 진솔한 얘기를 들을 수 있기 때문이다.

2. 기획서 작성

우리가 비록 "프로젝트 기획서"를 통해 매칭이 되었다고는 하지만, 이것은 한 개인의 일방적인 기획서일뿐 각자의 요구 사항을 전혀 반영하지 못하고 있기 때문에 반드시 새로운 기획서를 작성한다. 개인들의 기술셋과 도메인 지식(knowledge)을 총 동원하여 살을 붙이고 떼어낸다. 보통 기획서를 작성하는 데에는 2주 정도(전체 기간의 25%)를 할애하는데 핵심은 모든 팀원들이 문제와 해결책을 명확하게 이해하는 순간까지 기획서를 작성한다는 점이다. 누구라도 동의하지 않고 이해하지 못한다면 서로가 서로를 끊임없이 설득하는 과정을 거쳐 모두의 동의를 얻을 수 있도록 한다. 이는 마에스트로라는 프로그램이 특별해서 이기도 하지만(만드는 제품이 상업적으로 반드시 성공해야 하는 것은 아니므로), 한편으로는 참여하는 팀원들이 서비스나 기술의 소비자라고 했을 때 우리 멤버끼리 공감대를 갖지 못한다면 아마 외부의 고객도 마찬가지 일거라는 생각이 깔려있다. 기획서 작성은 우선 리서치(Research)부터 시작한다. 내가 아는 문제가 실제 문제가 아닐 수도 있고, 이미 누군가가 스마트하게 해결했을 수도 있고, 어쩌면 지금 당장 해결하기 어려울 수도 있기 때문이다. 우리는 무턱대고 도전하는 것만이 아닌 그것이 무엇이든지간에 "잘" 해결하는 방법을 배워야 하기 때문에, 간혹 문제가 너무 당연해보인다고 하더라도 반드시 리서치를 하도록 요구한다. 리서치 방법은 관련 서비스를 검색하는 것부터 시작하는데, 발견되어지는 정보는 기사나 글, 유사한 서비스의 피드백등이 있다. 모바일 서비스의 경우 유사한 서비스를 분석하는 것이 정말 중요하다고 생각한다. 한편 관련자료를 제대로 검색하기 위해서는 키워드를 잘 선정해야 한다. 이는 아직은 부족하지만 우리의 서비스를 좀더 단순하게 그리고 본질적으로 이해하는 첫번째 과정이라고 생각한다. 리서치 관련해서 현재 진행하고 있는 팀에서는 다음과 같은 내용들을 조사했다.

[ 서비스 관련 ]

1) 구글 플레이에서 관련 서비스들을 적어도 10개 검색한다.

2) 서비스를 설치하고 핵심 기능들을 정리한다.

3) 다운로드 수와 평가 및 긍정적인 피드백과 부정적인 피드백을 조사한다.

4) 상위권에 해당하는 서비스의 경우 구글에서 관련된 정보(기사)를 조사한다.

[ 도메인 관련 ]

1) 해결하고자하는 문제의 도메인과 관련 키워드들을 구글에서 검색한다.

2) 솔루션이 나와있는 경우 우리가 생각하는 해결책과 비교해본다.

3) 도메인 전문가를 찾아서 인터뷰를 한다.

이것말고도 해야 할 일들은 굉장히 많은데, 여기서 아주 요상한 의문이 생긴다. "도대체 언제까지 얼마나 리서치를 하란 말이요? 우린 언제 설계하고 구현하냔 말이요?" 이런 질문에 대한 답은 이렇다. 우리 모두가 문제를 충분히 공감할 때까지, 그리고 그렇게 해서 나온 서비스를 한 문장으로 요약할 수 있을 때까지. 그럼 이렇게 물어본다. "만약 모두가 공감하지 못하면 끝까지 우린 다음 작업을 하지 못하는 건가요?" 맞는 말씀. 아니 문제가 뭔지도 발견하지도 못했는데 도대체 무슨 작업을 시작하는 걸까? 머리속에 그냥 대충 그려본걸 가지고 개발을 한다는건 애초에 말이 안된다. 기획이 되지도 않았다면 시나리오도 생각해볼 수 없고, 화면 설계도 잡을 수 없을 뿐만 아니라 기능 정의도 불가능하므로 결국에는 아무것도 없는 상태(VOID)를 무작정 프로그래밍 언어로 때려박는 상태일 뿐이다. 이를 두고 "우선 만들어보고 피드백을 받아보면 되잖아요."라고 말한다면 그냥 도박을 하세요라고 말하고 싶다. 도박도 생각해보면 이길 확률은 어느정도 있다. 그것이 1%든 0.1%든지간에. 우리가 자원을 투입할 때에는 가급적 성공 가능성을 높이기 위해서다. 설계에 공을 들이는것도, 개발을 잘하는것도, 마케팅을 열심히 하는 것도 성공이 100%라고 했을 때 십시일반 몇 %라도 성공 확률을 높이기 위한 과정이라는 것을 기억해둘 필요가 있다. 기획을 할 때 나는 가급적 기술적인 부분에 있어서도 검증하기를 요구한다. 이때 핵심적으로 필요한 기술들에 대해서는 간단하게 프로토타입을 작성하도록 요구한다. 그래야 다음 과정을 진행할 때 모두가 근본적인 부분에서 모든걸 뒤집는 결과에 대해서 불안해하지 않아도 되기 때문이다. 결과적으로 팀원들 모두가 문제에 공감하고 확신을 가졌다면 이제 다음 과정으로 넘어가도 좋다.

3. UX/UI 설계

이쯤되면 총 8주 중에서 3주가 지나간다. 그래도 걱정할 필요는 없다. 참여한 팀원들은 개발에 있어서는 선수니까. 기획을 통해 우리가 무엇을 해야할지, 최종 완성되는 형태는 무엇이 되어야할지를 모두가 이해하게 되었다면 이제 곧바로 만들어야 할 서비스의 모습을 그려본다. 모바일나 웹 서비스라면 화면을 스토리 보드를 그리면 되지만 엔진을 만든다거나 라이브러리를 구현하는등의 프로젝트는 다를 수 밖에 없다. 스토리 보드를 그리면 우리가 파악하고 있는 것들을 좀더 명확하고 분명하게 이해할 수 있게 되는데, 방법으로는 핵심 기능들을 가장 먼저 나열하고 필요하다고 생각되는 부가적인 기능들을 나중에 고려해본다. 그리고나서 외부의 도움을 받을 수 있다면 몇몇 지인들에게 핵심기능들에 대해 피드백을 받아본다. 이렇게 만들어보면 쓸모가 있을까요? 없을까요? 서비스의 근간을 흔드는 부정적인 질문이 아닌 경우에는 크게 두려워할 필요 없다. 왜냐하면 입장바꿔놓고 생각해봐도 그림이나 설명만 떡하니 가지고 오고선 좋아? 싫어?라고 물어보면 누가 거기다 대고 찬란한 미래를 말해줄 수 있을까? 우린 이미 기획단계에서 철저하게 준비했으니 가벼운 피드백이라고만 생각해두자. 일단은. 스토리 보드를 완성하고 나서 가상이긴 하지만 만들 서비스를 사용하는 모습을 연출해본다. 자연스러운지, 재밌는지, 필요한지의 느낌이 전해질 것이다. 이 때 디자이너의 도움이 좀 필요하다. 보기좋은 떡이 먹기도 좋다고, 스토리 보드에 올라가는 내용도 최종은 아니지만 우리의 컨셉이 반영된 작품(?)이 나왔을 때와 아닐때는 느껴지는 서비스의 품질이 다르기 때문이다. 이 정도의 작업을 거치면 아마도 1.5주 정도 지났을 것이다. 벌써 4.5주나 지났다.

4. 아키텍처 설계

스토리 보드가 완성되면 필요한 요소들이 모두 반영되었기 때문에 필요한 데이터(자료 구조)와 데이터의 흐름, 처리 방식에 대해서 쉽게 파악할 수 있다. 방법은 스토리 보드의 각 페이지마다 사용되는 데이터를 뽑아내고 해당 데이터를 얻기 위한 방식(서버에서 가져오는지 사용자로부터 얻는지, 아니면 가공하는지)을 적어둔다. 소프트웨어는 별거 없다. 입력->(자료)->처리->(자료)->출력이라는 단순한 구조만 기억하자. 스토리보드를 기준으로 한 페이지씩 만들다보면 데이터베이스에 그려넣은 Table들이 보이게 되고 그것들의 관계가 자연스럽게 정리된다. 억지로 생각할 필요도 없고, 서비스와 동떨어진 데이터 구조를 만들 이유도 없다. 그냥 만들어질 뿐이다. 필요한 만큼, 부족하지도 않고 넘치지도 않는다. 이 과정이 모두 끝나면 서비스의 세 축이 완성된다. 크게는 클라이언트-서버 구조가, 작게는 클라이언트-서버-데이터베이스 구조가 완성된다. 이쯤 되면 팀원들의 역할 분담이 가능하게 되는데 분량이 많다고 생각되거나 전문 분야가 있는 경우를 고려해서 팀원들이 분야를 전담하게 한다. 워낙 주기가 짧아서 전담분야를 잘 매칭시켜야만 프로젝트가 원활하게 돌아갈 수 있다. 현실적으로는 충분한 기술셋을 갖추지 못했을 가능성이 높으므로 반드시 멘토가 전체적인 틀에서 문제를 해결할 수 있어야 한다. 프로젝트 전체를 보면 멘토의 역할이 프로젝트를 리드하는 입장이지만 이 단계에서는 가급적 실무적으로 참여할 수 있어야 한다. 그것이 곧 역량있고 경험있는 멘토를 선정한 이유일 테니까. 역할을 나누기는 했지만 모두가 함께 배워나가야하는것이 목표이므로 매번 모임을 할 때마다 진척도를 발표하고 피드백을 받을 수 있도록 한다. 스토리보드에서 정의한 내용들을 기준으로 클라이언트와 서버는 각자의 아키텍처를 설계하고 최종적으로는 서로간의 Interface를 정의하는 단계까지 이르게 된다. 이 기간은 1주가 걸리므로 어느덧 5.5주가 지났다.

5. 구현

이제 막판에 달려야 한다. 남은 시간은 약 2주 가량이다. 이게 가능해?라고 묻는다면, 이렇게 대답하고 싶다. 우리가 구현하고자 하는 기능들이 명확하고 목표가 분명하지만 어쩔 수 없는 기간으로 인해 개발 기간이 짧다면 결국 최선의 방안은 남은 기간내에 구현할 수 있는 기능들을 정리하고 Milestone을 찍는 수밖에 없다고. 이것은 정해진 시간(2주)을 기준으로 무작정 개발하다가 여기까지 밖에 못했네요라는 것과는 다르다. 철저하게 계획적으로 움직일 필요가 있다. 어차피 소프트웨어라는게 "2013년 8월 23일 완성. 더 이상의 업데이트는 없음." 이런게 말이되냐고. 그런 일은 애시당초에 없기 때문에, Milestone을 잘 찍어가는 것도 배워둘 필요가 있다. 암튼 이런저런 이유에도 불구하고 가능하다면 일정내에 완성할 수 있는 Scope을 정하고 일을 진행하는 것이 좋다. 나는 짧은 기간이 주어졌으니 문제도 그 만큼 작아야해요라기보다는 리서치 과정중에서 나온 결과를 토대로 일정이나 Scope을 정해가면서 일을 진행하는 것도 나쁘지 않다고 생각하기 때문이다. 프로젝트 진행은 Scope-Time-Cost의 세 축을 예술적으로(?) 잘 조정하는것 아니겠는가? Time과 Cost가 상수라면 남은건 Scope이니 저거라도 변수로 만들어야지. 앞서 팀원들의 역할이 나뉘었기 때문에 매번 모임 때마다 진척도를 점검하고 문제가 있을 때에는 언제든지 연락해서 해결할 수 있도록 한다. 그것이 내부의 리소스이든, 아니면 외부든지 간에. 완전히 기술적으로 구현이 불가능한 문제가 아니라면 대부분의 경우 2주안에 기능을 구현하기에 충분했다. 2주라는 시간이 짤기는 하지만 그렇다고 해서 아무것도 못하는 정도는 아니다. 뭘해야하는지 명확하다면, 진격의 시간만이 남아있을 뿐이다.

Project Management Triangle

구현을 할 때에는 가급적 테스트 코드를 작성할 수 있도록 한다. 특히 서버의 경우에는 문서를 작성하는 것보다 잘 짜여진 UnitTest가 두고두고 도움이 된다. 클라이언트가 서버 개발자를 귀찮게 하지 않아도 되기 때문이거니와 코드를 검증하는 차원에서도 중요하다. UnitTest가 잘 작성되어 있으면 Stress Test에도 활용할 수 있어서 매우 유용하다. 두달짜리 프로젝트에 왠 QA?라고 할수도 있겠지만, 그래도 프로젝트를 마무리하기 전에 팀원 모두가 서비스를 사용해보면서 QA 시간을 갖는다. 서로에게 피드백도 주고 제품에 대해서 둘러본다. 이쯤되면 서비스의 기능이 완성되었거나 아니면 버전 1.0에 해당하는 Milestone정도를 완성했다고 봐야하는데, 한 턴을 잘 마무리하는 단계도 중요해보인다. 이렇게 작업을 하면 7.5주가 된다. 이제 0.5주 남았다.

6. 자료 정리

지금까지의 과정을 잘 따라왔다면 별도의 자료를 정리할 이유는 거의 없다. 그냥 만들어진 산출물만 짜맞춰도 훌륭한 보고서(?)나 발표자료를 만들 수 있을테니까. 사람의 기억력이 좋지 않기 때문에 일의 순서대로 정리하면 나중에 봐도 큰 도움이 된다. 만약 이 단계에서 누군가에게 발표를 해야 한다면 오히려 구현에 관한 내용보다는 문제를 어떻게 정의했고 어떤 방식으로 해결하려고 했는지를 강조하는게 좋겠다.

짧은 글로 시작하려고 했는데, 쓰다보니 길어지고 더 자세하게 언급하고 싶지만 대략 이정도로 마무리하려고 한다. 이쯤에서 몇가지 질문을 정리해 보면,

Q) 프로젝트 관리 도구는 뭘 쓰나요?

- 형상 관리는 반드시 해야 하는데, Git이나 SVN을 사용하게 된다. 요즘 친구들은 왠만하면 둘 중 하나는 이미 사용해본 경험이 있어서 선호하는 방식을 쓰고 이를 위해서 별도의 서버를 구축하지는 않는다. Bitbucket의 경우에는 private도 무료로 저장소를 제공하고 있다. 일정 관리는 엑셀이나 구글 드라이브 정도로만 정리한다. 팀원 모두가 익숙한 도구가 있다면 모르겠지만, 새로운 툴을 학습하고 "잘" 사용하기란 쉽지 않아서 추가적인 부담을 주지는 않는다.

Q) 꼭 이렇게 해야 하나요?

- 아니 절대로 그렇지는 않다. 여전히 가능성의 문제이긴 하지만 그래도 전체적인 과정을 거치면서 '확신'을 가져가는 편이 좋지 않을까 싶어서다. 나는 성공을 하더라도 왜 성공했는지를 배우는게 중요하다고 생각한다(아직도 배우고 있는 중이라서 성공 못했다). 그래야만 성공 DNA가 생기니까. 하긴, 인생 한방도 중요하다. 가끔 그다지 큰 고민을 하지 않고 서비스를 만들었는데 성공했어요라고 하더라도 조금만 더 들여다보면 처음만 고민없이 시작했을 뿐이지 그것이 고객에 의해서 사용되는 순간부터는 끊임없이 개선하고 발전시켜나가는 고통의 순간을 겪게 된다. 운좋게 빵 터졌다는 뻥은 믿지 말자. 아니 안 믿는게 속편하다.

Google App Engine 오류 모니터링

naggingmachine — Mon, 12 Aug 2013 20:22:41 +0900

GAE에서는 에러가 발생했을 때 이메일로 알려주는식의 방법으로 처리해야 하는데, Web Request Handler 클래스쪽에 handle_exception 메서드를 추가해주면 됩니다. 그리고는 다음과 같이 이메일을 발송하도록 처리하면 깔끔하게 처리할 수 있죠.

def global_handle_exception(response, exception):
# Log the error.
logging.exception(exception)

# Set a custom message.
response.write('An error occurred.')

mail.send_mail(sender="Alert <error@test.com>",
to= "test@test.com",
subject="GAE Error",
body="GAE error" + """:

""" + traceback.format_exc())

# If the exception is a HTTPException, use its error code.
# Otherwise use a generic 500 error code.
if isinstance(exception, webapp2.HTTPException):
response.set_status(exception.code)
else:
response.set_status(500)

(자바의 경우 http://lkubaski.wordpress.com/2012/02/15/error-handling-in-google-app-engine/ 링크를 참고하세요)

* 그런데 이 방법 말고도 Google Talk에 실시간으로 메시지를 전송하는 방법도 있군요.

http://lkubaski.wordpress.com/2012/02/16/real-time-error-monitoring-in-google-app-engine/

수고!