성심당

귀국길 비행기 안에서 2시간 동안 한 흐름에 읽었다. 그만큼 빠르고 쉽게 읽혀서 좋다.

나는 원래 이런 책을 좋아한다 – ‘살아있는 사람의 이야기’

원래 이 책은 사자마자 읽은 프롤로그에서 지나치게 비현실적인 부분이 있어서 읽을 맛이 확 사라졌는데 그 부분을 꾹 참고 넘어가니 한 번에 읽을 수 있었다. 다행이었달까. 비현실적인 부분은, 빵집이 불에 활활 타고 있는데 주인은 현장에서 벗어나 성당에 가서 무릎꿇고 기도했다는거다. 이게 사실이었다면 믿음이 어마어마한 사람이라는 생각도 들지만 글쎄. 미화된 것이든 사실이든 그것은 책 전체의 스토리에는 별 영향이 없으니 넘어가자.

나에게 성심당은, 대전에 잠깐 있던 몇 년전 서울 올라올 때마다 KTX 역에서 ‘판타롱 부추빵’을 하나 사서 열차 안에서 야금야금 먹었던 추억이 있다. 나는 튀김소보로는 별로 입에 안맞더라.

이야기를 가진 집단은 그렇지 않은 집단보다 생존 가능성이 높다. (…) 이야기를 중심으로 임직원들은 단합하고, 같은 비전과 목표를 공유한다. 또한 이야기는 기업의 독특한 문화를 만들어낸다. 자기만의 문화를 가진 기업은 시장 안에서도 독자적인 생명력을 유지할 수 있다. [p25-p26]

책의 1장 시작에 나오자마자 주옥같은 내용을 건져서 기분이 좋았다. 이 문장이 하나로 끝까지 읽을 수 있었는지도 모른다. 우리 회사는 다른 유사 서비스보다 풍부한 이야기가 있다. 이를 잘 활용하면 좋겠다는 생각을 했다.

튀김소보로를 먹어본 사람과 그렇지 않은 사람으로 나뉘었다. [p84]

학생들도 우리 서비스를 써 본 사람과 아닌 사람으로 나뉘기를 바란다. 우리 기술, 우리 서비스, 우리의 진심을 접해본 학생과 아닌 학생으로 나뉠 정도로 우리의 아이덴티티가 있기를 바란다.

성심당의 인상깊은 점은, 지역에 대한 사명감이 대단하다는거다. 나는 그럴 수 있을까? 그러지 못했을 것 같아서 존경스럽다. 그까짓 지역이 뭐라고 말이다. 하지만 나 역시 한 지역을 넘어, 한 나라, 한 대륙(동아시아)에 대해서 그런 생각을 가지고 있다. 뭐든 작은 지역 부터가 시작이 아닐까도 싶다. 가끔 O2O 스타트업을 보면 서초구/강남구 등 구단위 부터 출발하는데 이제는 그런 것에 대해 ‘어느 세월에’라는 생각보다는 ‘결국 해낼 수 있겠지’라는 생각을 가지기로 했다.

사실 이 책을 읽으면서 질질 눈물이 날 때가 여러번 있었다. 재미난 점은, 이 책은 그런 최루성 내용이 전혀 없이 우여곡절을 꽤 담담한 필체로 적어나가고 있다는거다. 어쩌면 비행기 기내가 워낙 건조해서 그랬는지도 모르겠다.

한편, ‘아이고 왜이리 눈물이 날까’ 하면서 스스로를 돌아봤는데 어쩌면 이 책에서 이룬 많은 내용들은 내가 그토록 갈망하던 어떤 포인트들을 자극해서 그런게 아닐까 싶기도 했다. 예를 들어, 누군가의 평생직장을 만들고 싶던 꿈이라거나, 한 지역(또는 한 국가)의 아이콘을 만들고 싶던 꿈이라거나, 아주 차별화된 한가지를 만들고 싶던 꿈이라거나, 그것이 온전히 하나의 책으로 나오는 꿈 같은거 말이다.

여전히 나는 그것들을 이루고 싶다.

우리 회사의 기업문화에 대해

스타트업들은 회사 홍보를 할 때 기업문화가 수평적이라던가 발랄하다던가 등등 긍정적인 기운이 느껴지도록 노력하는 경우가 있다.

예를 들어 해변가에서 단체점프하는 사진이나 회사 안에서 탁구치는 모습을 홈페이지에 걸어놓는거 말이다.

그에 비해 우리 회사 바풀은 참으로 잔잔한 편인데, 우리 자신도 기업문화가 어떻다고 분명히 말을 못한다. 사실 그럴 필요가 없는지도 모른다.

곰곰히 생각하면 이렇게 말할 수 있겠더라.

우리의 기업 문화는 지극히 건전하다.

문화적, 정신적 건전함은 일과 목적에 집중할 수 있도록 한다.

“우리는 비전을 공유하고-만들고-가꾼다.”

그래서 인터넷과 세상 문화의 한 구석을 조금이라도 더 좋게 바꿔보고 싶은거다. 이것을 위한 각자의 삶이 모인게 지금의 기업문화다.

요즘은 건전함이 넘쳐서, 어떤 레벨의 누가 오든 그 사람이 충분히 탁월해짐을 경험한다.

부족한 사람이 와도 능력자가 되는. 우리의 건전함이란 그 정도로 탄탄하다.

우리가 좋은 인재들을 빨리 뽑는 이유는, 사실 당시엔 그렇게 탁월하지 않아도 우리의 문화가 좋게 만들 자신이 있기 때문이다.

궁극적으로 좋은 기업문화는,

우리가 바라보는 가치에 대해서 흔들리는 시점엔 서로 불나는 토크를 할 줄도 알고, 모두가 의견을 말할 수 있고, 모두가 그에 반박할 수 있고, 때로는 ‘이 의견은 독재적으로 결정합시다’라며 상대의 결정에 온전히 맡길 수 있는.

…그런 믿음이 탄탄하게 흐르고 있는거라고 본다.

문화란, 그렇게 조직 사이에 말 없이 흐르는거다.

YJ

이슈트래커 YouTrack의 단점

유명 개발사 JetBrains의 YouTrackAtlassian Jira보다는 개발자 집단에 특화된 이슈트래커입니다. 개발자 집단에 특화되었다는 말은 JetBrains CEO의 말에 의하면 그렇고 저도 동의합니다.

마치 콘솔작업처럼 키보드 하나만 쳐도 바로 커맨드 창이 뜨고 자사의 IDE제품군과의 매끈한 연결, 강력한 검색 기능 등이 그런 특징을 나타냅니다. 특히 이슈와 칸반을 모두 지원하기에 빠른 이슈리스팅과 시각적인 업무 흐름을 함께 파악하기에 좋습니다.

장점은 이전 글에서 읽으실 수 있고 이 글은 제가 있는 조직이 YouTrack을 도입한지 1년 즈음 지나서 느끼는 단점에 대해서 적습니다.

1. 매우 유연한, 그만큼 고민해야 하는 사용법

YouTrack의 칸반보드는 매우 다양한 기준으로 구성할 수 있습니다.

YouTrack 칸반보드. 출처: JetBrains blog
YouTrack 칸반보드. 출처: JetBrains blog

기본적인 틀은 하나의 이슈(=티켓)에 사용되는 특정 프로퍼티를 기준으로 하게 되는데, 중요도, 분야, 프로젝트, 담당자 등 그야말로 enumerable한 속성이면 모두 가능합니다.

또한 각 이슈의 위상을 결정하는 것(feature-task, feature-task-subtask 등), 이슈 간 연결 형태(주종관계/참조관계 등) 등을 직접 정의할 수 있습니다. 쉽게 말해 YouTrack은 ‘이슈트래커 만드는데 필요한 데이터 덩어리를 적당히 GUI로 엮어준 것’에 가깝습니다.

그러다보니 어떤 기준으로 어떻게 구성해야 하는지에 대한 시행착오와 판단 또한 끊임없이 겪습니다.

2. 빈약한 Integration

사실 이게 YouTrack을 사용하면서 가지는 가장 큰 불만일겁니다. GitHub issue, Trello 등이 slack 초창기부터 연동이 되었지만 YouTrack은 아직 연동도 되지 않고, IDE 플러그인은 자사 JetBrains 제품군 외에는 없다시피 합니다.

API는 오픈이니 직접 개발해도 되지만 어느 천년에, Atlassian JIRA가 직접 IDE들의 플러그인을 꽤 좋은 품질로 제공한다는 것에 비해서는 안타깝긴 합니다.

Visual Studio 연동이 안되는 것은 우리 팀에겐 치명적이고요. API가 오픈되어도 Zapier같은 API브릿징 서비스에도 관련 서비스는 없습니다. 회사의 모든 IDE가 JetBrains 제품군(IntelliJ IDEA, PyCharm, WebStorm, Android Studio 등)이라도 불만은 있는 셈입니다.

참고로 저희 회사는 (아마도) 우리나라에서 JetBrains 제품군을 가장 많이 사용하는 회사일겁니다. Products 페이지에서 2개(CLion, Rubymine) 빼고는 다 쓰고 있으니까요. 그럼에도 업무에 완결성이 잘 안이루어지는거죠.

3. 모든 것이 다 가능하지만 모든 것이 그냥 되지는 않아

안드로이드나 리눅스를 만져보면 처음에 이런 인상을 가지죠. ‘우와! 리눅스는 다 된다! 내가 상상했던 것, OS의 소스를 직접 보고 수정도 할 수 있고, 그야말로 전지전능해진 것 같아’

하지만 함정은, 쉽게 되지는 않는다는 거죠. YouTrack은 Workflow라는 기능이 있고 Workflow Editor라는 별도의 설치프로그램이 있어서 많은 것을 자동화할 수 있습니다. 일종에 스크립트 언어인데 익숙해지는데 시간이 꽤 필요합니다.

YouTrack WorkFlow Editor
YouTrack WorkFlow Editor. 자, 만능 편집기를 만들었으니 다 해보렴 ㄷㄷㄷ

Workflow editor는 몇 십개의 기본 workflow가 제공되는데, 예를 들어 이슈가 끝나면 코멘트를 못달게 하는 것, 상위 이슈가 fixed되면 하위 이슈도 자동으로 종료 처리하는 것, duplicate 처리되면 자동으로 닫는 것 등등입니다.

일하기 바쁜데 이슈트래커 스크립트 언어도 익히고 기술문서도 읽어야 하지요. 이런 것을 마치 아웃룩의 규칙 정하는 것처럼 콤보박스들과 조건 몇가지 만으로 만들 수 있다면 좋았을 겁니다.

4. InCloud 제약

InCloud는 YouTrack의 구독형 서비스입니다. 저희는 클라우드 구독형 서비스를 선호합니다. 설치형으로 머신을 관리하는 것 자체를 부담으로 생각하지요. JetBrains의 개발 툴체인은 IDEs(개발툴들)-YouTrack(이슈트래커)-UpSource(코드리뷰)-TeamCity(CI빌더)로 구성되어 있는데, 이 중 YouTrack만은 설치형 외에 구독형을 제공합니다.

이대로 되긴 한다만...
JetBrains 개발 툴체인. 이대로 되긴 한다만…출처: JetBrains

저희가 구독하는 YouTrack InCloud는 AWS의 East-Europe에 구성되어있다고 나오는데 일단 속도가 느립니다. 또한, 위에 언급한 개발 툴체인이 단일 계정으로 묶여야 하는데 InCloud account(Hub라고 합니다)와 나머지 설치형 account는 통합이 되지 않습니다.

그러므로, YouTrack을 사용하신다면 반드시 설치형으로 사용하시길 권합니다. 그 외에 InCloud임에도 SLA도 없고 공지된 유지보수 스케줄과 어긋나게 하루 내내 안된 적도 있습니다.

5. 칸반에 자동 새로고침이 없다

칸반보드는 한 눈에 진행상황을 보기에 좋습니다. 하지만 뭔가 이슈가 슉슉(!) 이동하는게 없이 꼭 새로고침을 눌러줘야 합니다. 더 나아가 이것을 TV에 쏘라고 ‘TV 모드’라는 뷰도 제공합니다. 이 TV 모드에도 자동 새로고침이 없습니다. 그냥 디자인 테마인거죠.

뭐 브라우저 플러그인으로 인터벌 새로고침 기능을 돌리면 되지만 그 때마다 전체가 깜박이겠죠. 오래된 컴플레인인데 구현하기 복잡한가봅니다. PivotalTracker에서 가장 만족했던게 누군가의 변경사항이 실시간으로 보였던 것입니다.

현재는 GitHub Issue로

바풀 개발팀이 3명 이하였을 때, 이슈트래커로 PivotalTracker를 열렬히 사용했습니다. 하지만 5명이 넘으면서 프로젝트를 나누면 한 눈에 파악하기가 불편하고 합치면 너무 와글와글해보여서 YouTrack으로 옮겼습니다.

이제 YouTrack은 5~10명 정도의 팀에는 너무나 방대한 기능이 있다는 생각이 들었습니다. 그래서 두 달 전부터 GitHub Issue를 사용하기 시작하고 있습니다. GitHub은 마일스톤-이슈라는 단순한 위계, 각종 규칙은 라벨로 적당히 유연하게 구성할 수 있고, YouTrack보다는 폭넓은 integration을 가지고 있습니다.

GitHub 이슈로 위의 단점들이 해소되는 것은 아니지만, 어차피 비슷한 단점일 바엔 좀 더 단순한걸 사용하자는 판단입니다.

10년을 생각하며

2010년 1월 1일 새벽 6시에, 나는 집에서 나와서 연구실로 향했다.

나는 그 때의 새벽 공기, 어스릇한 대기의 색상, 교차로의 신호등 불빛과 내 차에서 손가락을 가볍게 물고 있던 나의 자세와 생각을 모두 생생히 기억한다.

10년간 내가 교육을 기술로 재해석해보겠다고 스스로와 약속했고, 이제 4년이 되어 간다.
– 참신했고 호응이 좋았으나 널리 쓰이지 못한 ‘탭스터디’
– 많이 사용되지만 언제나 미완성으로 될 것 같은 지금의 ‘바로풀기’
– …

이제 내년이면 5년차가 되므로, 그 다음의 5년을 생각해야 할 때이다.
이 다음의 5년은, 어쩌면 나의 다짐에는 마지막 여정이 될 수도 있다.
그만큼 당시만큼의 고민을 하게 된다.

현재는 건축 관련 책을 많이 읽고 있다. 아마도, 좀 더 현실 세계와 연결성이 있던가, 작지만 단단한 건축과 같은 것을 상상하거나, 확장해도 전체가 어색하지 않은 어떤 구조를 만들고 싶은 욕망때문일게다.

지금 머리 속에 드는 생각은 ‘마인크래프트’와 비슷한 무언가가 머리 속에 자리잡는다. 하지만, 개념이 그렇다는거지 어떻게 발전할지는 모른다.

다음의 5년. 그리고 그 완성이 될 것 같은 10년.
나는, 인생에 어떤 족적을 남길까…?

Local Storage on Windows Azure

Azure Worker Role에서 LocalStorage 사용하기위한 방법입니다.

Azure Worker Role은 클라우드 시스템이므로 LocalDisk의 개념이 아닌 LocalStorage라는 가상화된 드라이브를 제공합니다. 이것은 프로세스 리부팅 때 사라질 수도 있습니다. 물론 롤을 삭제하면 같이 사라지지요.

Convective

12/20/2009 This post has been updated to be consistent with the latest version of the Azure SDK. The primary changes are from RoleManager to RoleEnvironment and the addition of a new cleanOnRoleRecycle attribute to the schema definition for LocalStorage.

Windows Azure Storage supports several types of storage: tables, queues and blogs. These can be accessed RESTfully over a network by applications resident either in the cloud or on client machines. However, Windows Azure also supports the concept of local storage which can be accessed using standard .Net Stream operations and which does not require network access.

Local storage is created by a role instance and is only accessible by the instance that created it. This means that one instance of a web role or worker role can not access the local storage of another instance even of the same role. For example, in a simple application with one instance of…

원본 글 보기 640단어 남음

Hello world!

여기저기 방황하다가 워드프레스에 정착합니다. 워드프레스에 정착하는 이유는 세가지입니다.

  1. 마크다운 입력 지원
  2. 편리한 코드하이라이트
  3. 그러면서도 미디어의 편한 추가
  4. 페이지로 목차기능을 대신할 수 있음

그럼에도 무료라니 놀랍습니다.