<예전 일을 생각하며..>

지금으로부터 2년 전 쯤의 이야기이다.
외국에서는 큰 회사들은 하고 있었지만, 국내에서는 기술 블로그가 KTH 에서 하는 정도였다. 대부분은 기업 블로그 정도로 사용하고 있었다.  마침. 조직장으로부터 계속 기술 블로그를 만들어보라고 하셨다. 특별한 내용 없이 초안을 만들어야 해서 고민을 많이 해야 했다.

조직장의 마음을 헤아리기 어렵기 때문에 가장 어렵기도 하지만, 때로는 마음껏 그려볼 수 있어서 참 좋았다.
지금까지도 생생할 정도로 모든 발표 내용의 내용들이 내 머리 속에 있으니..
특별한 능력이 있어서 기회를 받은 것이 아니라, 블로그를 써봤던 경험, 같이 만났던 개발자들의 고민을 잘 알기에 내게 맡겨진 것은 아니었을까 생각이 든다.

<생각>
일을 시작하면서 많은 질문을 내 앞에 꺼집어 놓았다. 그 중에 지금까지 기억나는 질문들은 다음과 같았다.

1. 기술 블로그는 무엇일까? 기업 블로그의 차이는 무엇인가?
2. 왜 기술 블로그가 필요한 것인가? 꼭 필요한 것인가? 어떤 효용 가치가 개인/회사에게 있는가?
3. 다른 곳은 어떻게 하고 있나? 과연 그 싸이트는 기술 블로그인가? 공유인가?
4. 내가 만드는 회사의 기술 블로그의 정체성을 어떻게 지속시킬 수 있는가?
5. 좋은 기술 블로그 싸이트의 특성은 무엇인가?
6. UI는 어떻게 해야 하는가?

굳이 답변을 적지 않아도 회사의 얼굴을 대변하는 것이기 때문에 신중에 신중을 더해야 했다.
미디어라는 매체는 파급력과 영향력이 크기 때문에 좋은 글 보다는 나쁜 글 하나가 회사의 명예를 실추시킬 수 있기 때문이다.

<조사>
기술 블로그에 대한 철학을 찾아보았으나, 우선 여러 웹 싸이트를 돌아다니면서 좋은 블로그 사례를 찾았다.
facebook, netflix, twitter, kth 블로그를 분위기를 살펴보았다. 이 중에 facebook 처럼 친숙하고 따뜻한 느낌으로 운영하면 좋겠다는 생각도 했다. 기술 수준이 높은 것도 있지만, 간단한 UI 변경도 같이 포함될 정도로 소통하고 있는 것을 알려주는 방식으로 가려 했다. 그리고 구글 랩스의 선행 프로젝트 느낌도 추가할 계획을 가졌다.

facebook의 블로그는 굳이 기술 블로그같지는 않았지만, 따뜻하고 자유스러운 분위기가 나를 매력에 빠지게 했다. (아마도 조직문화가 그대로.. 스며 들었던 건 아닐까?)

<의미>
기술 블로그에 글을 쓸 때는 회사를 대표하는 한 개발자에게 대표성을 가질 수 있는 좋은 글을 쓸 수 있도록 도와주고,앞으로 점점 자신의 캐리어 패스를 사람을 돕는데 쓰일 수 있을 수 있는 좋은 기회가 될 것 같은 생각이 들었다.

내가 인터넷 또는 서적으로 통한 지식을 남들에게도 거저 줄 수 있는 일종의 "재능 기부"를 생각했다. 때로는 번역도 좋은 기술 블로그의 재료로 여겼다. (그러나 번역이 '주'가 되면 안되도록 해야 했다.) 또한 특정 진영을 비판하는 것은 하지 않도록 해야 했다. 조직이나 사람을 비판, 음모론으로 모는 것은 좋지 않다고 생각했다.

기술 블로그는 말 그대로 개발자 본인이 공부한 기술, 적용한 기술에 대한 글을 적도록 가이드하려 했다.

흥미로운 것은 조직문화가 기술블로그에 그대로 흘러간다는 것을 깨달았다.

더 정확히 말한다면, 조직장의 리더쉽이 드러나는 곳이 바로 기술 블로그인 것이다.

나 같은 일개 개발자의 역할 모델은 단순하지만, 조직장이 어떤 리더쉽을 세우고 진행하냐에 따라서 방향성과 흥망성쇠가 갈라지는 것을 손보듯 뻔했다. 조직장의 능력과 인내심과 꾸준한 노력이 그대로 보여주는 곳인듯 했다. (지금까지 기술 블로그가 잘 나가는 곳은 조직장이 뛰어난 것이라고 생각한다.)

<큰 그림>
기술 블로그는 정말 기초중의 기초였다. 회사의 이미지를 긍정적으로 메이킹할 수 있도록 하는 기초 중의 기초였다.인터넷이라는 매체안에서 유명해지는 부분이었다. 점차 글들이 많아지고 도전적이면서 책도 발간할 계획을 세웠다. 기술 블로그 글 도 대상이 될 수 있겠지만.
기술 블로그 저자 중에 일부를 간단한 책을 쓰도록 격려하게 하는 것이다. 그렇게 하여 출판업계에도 영향을 미치게 할 수 있을 것이라 생각이 들었다.또한, 컨퍼런스에 발표하도록 계획도 세웠다. 개발자 자신의 개발/운영 노하우가 듬뿍 들어간 자료들이 기술블로그에 쓰이게 하고, 영향력 있는 컨퍼런스에서 발표하도록 지원할 수 있도

록 했다.

개인적으로는 넥슨의 GDC 컨퍼런스개념을 채용하려고 했던 것인데, 개인들의 좋은 자료들을 컨퍼런스에서 발표하게 하고. 기업의 역량,개인의 역량을 더욱 발전시킬 수 있도록

하는 큰 그림을 설계 했다.

<세밀한 퍼블리싱 계획을 진행후의 소감>

1. 글쓰기 교육
다른 것도 마찬가지지만, 기획력과 운영능력이 중요했다. 특히 문서의 품질과 퍼블리싱 정책등을 세밀하게 고민해야 했다. 특히 글쓰기 교육이 절실했다. 내가 내 개인 블로그에 글을 쓸 때마자 좌절하는 것이 있는데,  형편없이 쓴 글, 중복적이고 중의적인 글, 번역투등으로 괴로워하기 때문에 개발자분들을 대상으로 교육을 시켰다. 시간이 지나고 나니. 글쓰기 교육은 즐거운 블로깅대신 그들을 압박시킨 것은 아닐었을까 하는 후회감이 든다.
그냥 편하게 글을 쓰게 한 후, 괜찮은 tech writer에게 일을 맡겨주는 방식이 되는 모델이 좋을 것 같다.

2. 프로세스
기술 블로그는 자유롭게 쓰되, 적절한 가이드가 필요한 부분이 있었다. 이를 위해서 퍼블리싱 게임과 개발/배포환경 개념을 추가했다. 기술 블로그에 개발자의 글이 바로 올라가지 않고 검증하는 절차를 거쳤다. 이것도 시간이 지나서야 복잡하게 한 것은 아니었을까 하는 생각이 들었다. 간결한 프로세스로 했어야 했는데... 조심성이 많다 보니 절차적인 방법론을 채택하는 것 대신 아주 간결한 프로세스를 가지게 하는 것 좋은 것 같다.

3. 독자의 수준
문서를 읽는 독자의 수준을 생각을 해야 했다. 대학생인가? 이직 희망자인가? 정보를 취득하려는 개발자인가?
이 부분에 대한 수준을 상, 중, 하로 나누어 어려운 수준과 쉬운 수준을 적절히 섞는 방법, 편하게 진행하는 것도 좋을 것 같다.

4. 수급
그리고 가장 힘든 부분은 블로그 소재에 대한 Pool이 있어야 했다. output이 있으려면 input이 있어야 했다.
output이 '블로그' 라면 input은 '블로그 소재 + 인센티브 정책'이어야 했다.  인센티브 정책은 조직장의 강력한 리더쉽이 필요로 했다. 인센티브가 단순한 돈만 의미하는 것은 아녔다.  업무와 블로그는 결코 병행하기 어려운 부분이 있다. 업무시간에 글을 쓸 수 있을 정도로 시간적 여유가 필요했다. 그 글을 쓰면 다른 동료들도 배우고 자극할 수 있도록 하는 분위기,  공부하는 분위기를 만드는 것이 중요했다. 필요하다면 조직장이 약간의 소정료나 성과에 반영해야 한다고 생각했다.

5. UI
응답형 디자인이면서, 퍼블리싱을 쉽게 할 수 있는 툴 쪽으로 방향을 정했다.
다른 회사에서 필요로 하는 웹툴을 기술블로그에 붙을 계획도 했다. 예를 들어서 특정 웹 스피드를 체크하는 툴을 설치해 여러 IDC에서 얼마나 속도가 걸리는지도 넣어주는 것도 만들어 줄려고 했다.

<진행과정중에 만난 난제>
신뢰, 조직문화, 리더쉽..

<결론>

생각해보면 나 같은 일개 개발자한테 회사에서 큰 일을 주도록 시켜주신 것 보면.. 진짜 감사한 일이라고 생각한다. 비록 별의 별 상황을 다 만나면서 나를 포함해서 사람이란 얼마나 불안전한가에 대한 인문학적 소양을 더 쌓아야 겠다는 생각이 들었다. 사람들을 이해하고 그들을 어떻게 마음을 움직일지에 대한 공부가 필요하다.

힘이 아닌 진심으로 사람들의 마음을 움직이는 방법을 배워야할텐데….

(1년 전쯤에 리눅스 서버에서의 JDK/Web/WAS 표준화를 마무리했던 것을 작성해보려고 한다. 함께 같이 고민했던 분들이 기억이 난다. 서로 배려해주고, 이해해주고 회사의 장래에 대한 깊은 고민을 같이 했던 분들을 그 때 많이 만난 것 같다. 정말 고마운 분들 ^^)

표준화를 진행하는 것은 상당히 부담스럽다. 무엇이 표준인가? 라는 답에 대답하기가 쉽지 않다. (표준어가 교양 있는 서울 말인가? 하는 고민과 비슷할 수도 있다. )

네이버에 따르면, 표준은 두가지 의미가 있다. 기준 또는 평균 (영어로도 standard, average, norm이다 )이다.

(출처 : http://krdic.naver.com/detail.nhn?docid=40783400)

나는 단어 사전의 의미보다는 사회과학의 ‘표준’의 정의가 마음에 들었다. 단순화와 통일화를 도모하는 방법으로 배치,절차, 방법에 대해서 설정된 기준 정도로 했다.

(출처 : (http://terms.naver.com/entry.nhn?docId=473521))

자유롭게 하지 않고 왜 표준화냐? 에 대한 부분은 공감이 필요할 것 같다.

만약 팀 단위에서 모든 일이 해결한다고 가정하면 이런 표준에 대한 의미가 없을 수 있다. 그러나 점점 버그와 보안 문제로 인한 오픈 소스 거버넌스와 문제, 트러블 슈팅과 같은 기술지원이 빈번해지면서 필요성을 느낄 수 밖에 없었다. 특히 나는 기술지원이나 트러블 슈팅해주다 보니 , 같은 디렉토리를 서로 다른 디렉토리를 쓰다 보니 늘 혼란스러웠다.

어떤 사람은 소스로 설치하고 어떤 사람은 자동 배포(apt-get, yum)으로 하고. 서로 다른 것들로 싸여 있었다. 그렇게 때문에 naming 때문에 고민하기도 했다. 많은 개발자들이 직감적으로 이해할 수 있게 하려고 했다.

웹 서비스가 처음 개발하게 되면 그 상태로 계속 가능 경향이 있었다. 특히 리눅스를 잘 다루는 개발자가 리눅스에서 jdk/web/was를 셋팅한다. 몇 개월 또는 몇 년이 지나 그 환경을 인수인계 받은 사람은 대부분 신입들이 그 자리를 차지한다. 리눅스를 잘 다루면서 코딩까지 자유롭게 하는 사람은 그리 많지 않다. 문제가 생기는데 해결하는 것이 어려워지면서 기술지원팀에 요청하게 되면서 점차 요구사항이 커졌던 것 같다.

코딩은 자유롭게 하되, 리눅스의 환경을 동일하게 맞춘다면 개발자나 시스템 엔지니어가 어떤 팀으로 이동해도 학습 비용은 절감될 수 있을 것이라 믿었다. 또한 root 계정에 쉽게 사용하지 않게 함으로서 보안을 높일 수 있는 믿음이 있었다. 우리가 하향 평준화가 아닌 상향 평준화가 되면 좋겠다는 믿음이 있었다. (잘하는 사람에게는 상당한 부담이 될 수 밖에 없었다. )  마지막으로 일반적인 개발자 입장에서는 표준화된 환경에서 대부분 코드에 집중함으로서 생산성을 높일 수 있는 시간을 줄 수 있도록 하고 싶었다. 그래서 pc나, 리눅스 개발환경의 표준은 일부러 정하지 않고 배포된 서버(release)중심으로 정했다.

<배경>

1. 소프트웨어 버전,설치 방법은 개인역량에 따라서 달라졌다. 웹 서비스 자체를 운영 한다면 다양한 스크립트가 양산되는데, 사람의 역량에 너무 의존한 부분이 있었다. 누구는 perl, csh, bash, python, ruby…. 개념은 같고 먼가 복잡성이 거의 없다. 사실 한번 잘 만들면 더 이상 수정하지 않는 특성이 있다.

2. 부서 이동이 많아지면서 웹 서비스를 지탱하는 소프트웨어나  버전을 정확히 답변하는 사람이 드물었다. 기술 지원하려면 시간이 불필요하게 소요되지 않게 하는 표준화가 필요했다.

3. 일반적인 웹 서비스 개발자는 리눅스 자체가 두려움이 대상이 되어 잘 모르면 다칠 수 있다는 것이 있다. 많이 리눅스를 접하고 리눅스 환경에서 익혀본 개발자가 아닌 어플 개발자의 입장에서는 상당히 곤혹스러울 수 있다. jdk, web, was 설치 자체가 번거롭다.

4. 처음부터 오픈 소스 거버넌스(보안, 버그)로 검증된 표준화된  jdk/web/was가 설치된 상태로 서버가 개발자에게 전달하면 바로 웹 어플리케이션만 배포하면 되니. 속도가 빨라질 수 있다.

5. 처음 웹 서비스 개발하는 사람에게는 리눅스 환경을 전혀 알 수가 없다. 따라서 비슷하게 작업하는 공통의 스크립트과 환경 설정을 모아서 물리 서버에 배포하면 웹 서비스를 처음 하는 사람에게 쉽게 노하우를 전파받을 수 있을 것이다.

<진행>

초안(워드)를 작성해서 같은 TF사람들/ 웹 어플 배포팀 / 보안 팀 / 시스템 엔지니어 와 함께 협의 하며 진행했다. 300페이지가 넘는 ‘설치가이드’,’노하우가 담긴 설정 가이드’,’예제/체크가이드’ 문서를 작성했다. 우리 모두를 위한 서비스를 위한 jdk/web/was 환경이 담겨있었다.

기본적으로 root 계정이 아닌 임의의 계정으로 통일하고, 기본 디렉토리, 좋은 스크립트, 불필요한 설정 제거, history/psacct, jdk 이슈등에 대한 정보와 web 서버인 apache http와 모듈 정보, was인 tomcat, mod_jk에 대한 상세 설정을 작성했다.

내가 가지고 있는 지식과 직접 소스를 파며 얻었던 지식들을 많이 넣었다. (많이 부족한 사람이 쓴 거라 누군가가 더 좋은 글로 탄생해줄 것이라 믿는다.)

책에는 없는 설명들, 운영하면서 중요하게 생각한 팩터들, 장애 및 보안에 대한 깊은 이해와 노력을 넣었다. 기본적인 트러블 슈팅에 대한 정보를 넣었다. 단편적인 인터넷 문서나 너무 많은 jdk/web/was 매뉴얼의 단점을 보완하고 꼭 필요한 내용으로 작성한 문서였다.

PPT를 작성해서 한 눈에 보면 디렉토리 구조와 심볼링 링크를 따라갈 수 있게 했고, 전체적으로 빨리 볼 수 있게 했다.

<마치며…>

저말 개발자에게 도움이 되는 좋은 표준안이 되기를 진심으로 바랬던 마음으로 쓰려고 했다. 한편 다른 마음으로는 그 시간에 코딩을 하고 싶었다. 지금 돌아보니 나의 욕심 대신 개발자를 섬긴 시간들이 소중했던 것 같다. 겸손함과 진지함, 상대방에 대한 존중을 배웠던 것 같다. 

(이미지 출처 : http://www.identropy.com/blog/. 사진만 링크걸음)


2010년 하반기, 나는 회사에서 FOSS 거버넌스 정책에 대한 초안을 잡았다. 조직이동을 하면서 아이디어와 개념만 잡는 일만 하고, 거버넌스에 대한 실무는 내가 직접 하지 않았다는 점이 가장 흠이지만. 큰 틀에서는 내가 생각한 큰 틀은 지금도 이어지고 있다. 사실 내가 하고 싶어서 한 것은 아니고, 시간이 약간 널널한 관계로 정리했었던 것 같다.

(내 생각에는 내가 뛰어나서기 보다는 시간이 많아서 된 것 같다. 절대로 내가 특출난 능력이 있어서 한 것은 아니다. 사실 난 많이 부족한 사람이다. )

회사 특성상, 오픈 소스를 많이 활용하고 있다. 웹 서비스 및 솔루션 특성상 많은 오픈 소스 라이브러리를 알고 언제든기 개발할 준비가 되어있어야 한다. 그러나 워낙 많은 오픈 소스들이 범람하고 있고, 잘못하다가는 장애로 이어질 수 있는 수많은 장애가 있기 때문에 반드시 이 부분이 있어야 했다.

단순히 오픈 소스 소프트웨어 는 아무거나 쓰세요 하기에는 중요한 결정을 하는 조직에 있었고, 많은 개발자들이 새로 나온 오픈 소스 소프트웨어 또는 버그가 충만한(?) 오픈 소스 소프트웨어의 특이 버전을 쓰면서 이슈가 될 수 있었다. 오픈 소스 소프트웨어를 쓰면서 문제나 장애가 생기면 누구의 책임인가? 하는 고민들이 생기던 시점이었다. 그리고 회사에 많은 서비스조직이 있다보니 계속 반복된 장애는 계속 다른 부서에서도 나타났다. 마치 메아리처럼 이 산, 저 산 부딪히듯이 계속 발생되는 경우가 있었다.

또한 거버넌스 (Governance)라는 단어는 사람마다 달리 생각할 수 있는 모호한 단어였다. 거버넌스란 무엇인가? 거버넌스의 한계는 어디까지인가? 정부가 통제하듯이 하는 것인가? 가이던스(Guidance) 라는 단어와 많이 비슷한 느낌이면서 먼가 Push하는 느낌 때문에 초안 잡는 부분에 힘이 들었다. 너무 관여하면 자율성에 문제가 일어나고, 너무 멀리 있으면 장애나 서비스개발에 어려운 점들이 많았다.

인터넷을 통해서 다양한 정보를 얻으려 했지만, 결코 정보를 취합하지는 못했다. 거버넌스 하는 회사가 한국 뿐 아니라 외국에도 없는 독특한 사례였다. 단순히 Test 의 개념이나 Regressive Test 개념정도로 거버넌스를 바라보는 자료도 있었다. 좋은 선례가 없어서 결국 우리 회사안에서의 FOSS 거버넌스를 직접 하기로 했다.

나는 여러가지 인문서와 성경을 참조했다.
- 헤겔의 역사철학 강의
- 예링의 권리를 위한 투쟁
- 키케로의 의무론
- 루소의 사회계약론
- 홉스의 리바이던
- 애덤스미스의 국부론
- 토마스 모어의 유토피아
- 로크의 정부론
- 아리스토텔레스의 정치학
- 하이데거의 존재와 시간

우선 거버넌스를 하기전에 많은 것을 알아햐 했다. 사람에 대해서 알아야 했었다. 조직이란, 사람이란 무엇인가? 그리고, 어떻게 해야 유익할 것인가? 선한 게 행동할 것인가? 개발자는 어떤 사람인가? 관리자는 어떤 사람인가? 이 조직의 롤은 무엇이고, 다른 조직의 롤은 무엇인가? 바람직한 거버넌스는 무엇인가? 협업은 어떻게 할 것인가?하는 많은 고민을 하고 또 고민했다. 사람을 이해하고 조직을 이해하는 과정 속에서 다른 사람들은 어떻게 문제를 해결하려고 했을까 하는 수많은 생각들을 접하면서 깊이 고민했다.
(이런 시간들을 통해서 나는 겸손함을 더욱 더 배웠던 시간이었다. 나보다 똑똑하고 훌륭한 사람들이 많았고, 그 분들을 통해서 사회를 볼 수 있었다. 그러나.. 내 안에 아직도 많은 식견이 부족해서 많이 다듬어야 할 것 같다. )

내가 과연 모든 사람이 만족할만한 완전한 거버넌스를 만들어낼 수 있을까? 라는 고민속에 초안을 작성하기 시작했다. 잘못된 방향과 설득으로 인해서 어중간하게 하다가 종료하는 것은 없도록 해야할 것 같았다. 감사하게도 조직장과 좋은 피드백을 통해서 좋은 초안이 만들어지기 시작했다.

오픈 소스 거버넌스의 사용 조건, 오픈 소스 거버넌스 결과에 대한 게시판, 오픈 소스 거버넌스 조직은 모든 오픈소스를 다 할 수 없기 때문에 오픈 소스를 사용하려고 하는 서비스 부서와의 협업 모델을 생각하며 그렸다. 다양한 시나리오를 따라 흘러가는 플로우 차트를 그리며 오픈 소스 거버넌스에 대한 내용을 작성해서 어른 조직장들의 회의를 통과했다.

내가 가장 바탕을 둔 것은 오픈 소스 라이브러리에 대한 '검증'과 서비스 부서와 거버넌스 조직간의 '신뢰'였다. 첫번째 오픈 소스 소프트웨어에 대한 '검증'은 철저히 하려고 했다. 비슷한 종류의 라이브러리를 비교하고 사용성 팩터들을 모두 나열하고 객관적인 검토와 테스트를 통해서 검증할 수 있게 했다. 그리고 승인받은 오픈 소스 라이브러는 버전 통제를 통해서 잘 쓸 수 있는 것과 못쓰는 것, 문제 있는 것을 구분하려고 했다.

두번째, 상호 조직간의 신뢰였다. 거버넌스 자체가 굉장히 딱딱해질 수 밖에 없고, 특히 칼로 자르듯 하는 부분 때문에 감정이 상하거나 신뢰 관계가 손상되지 않게 하려고 했다. 서로가 돕고 지식을 쌓고 신뢰를 증강시키는 부분을 많이 염두하려고 했다. 신뢰 관계가 손상되면 소문이 나게 되고 불신이 전체 조직으로 흘러갈 수 있는 부분을 줄이려 했다. 이 불신에 대한 방법론이 여러가지로 나타나게 하지 않는 것이 최선이라고 생각했다. 


(이미지 출처 : http://opiniontribunal.wordpress.com, 사진만 링크걸음)

초안을 작성하고 나고 공유하면서. 여러 담당자들로부터 들은 얘기는 다들 할 수 없다는 분위기였다. 그리고 코딩과 상관없는 일들을 하는 것에 대해서 많은 부담을 가지고 있었다. '코딩'의 즐거움이 없어서 부담스러웠을지 모르겠다. 하지만, 조직장의 업무 지시로 다들 잘해갔다. 그리고, 관계에 대한 신뢰 부분을 얘기할 때, 여러 개발자들의 설득이 가장 어려웠다. 관계의 중요성을 잘 얘기하려고 했지만, 이 부분은 잘 이해하는 사람은 많지 않았다. 개발자들에게는 관계의 중요성을 얘기하는 것은 가장 어렵다. (협업 잘하는 것과 관계를 잘 이끄는 것은 비슷하지만, 완전 다른 내용이다. 관계를 잘 이끄는 것은 상대에 대한 신뢰와 섬김과 양보가 필요하다. 때로는 적절한 관계를 두고 하는 것도 포함한다. 나중에 일과 관계에 대해서 써봐야겠다는 생각이 든다.)

모든 오픈 소스 라이브러리를 검증할 수 없기 때문에 중요한 것만 검증을 시도했다. 모든 라이브러리를 검증할 필요가 없었다. 중요한 것만, 장애로 검증한 것만 해도 사실은 충분했다.

시스템적으로 다양하게 변화했다. 위키보다는 Cafe 형태로 제공하는 방법으로 말씀드렸고, 그 부분은 잘 진행할 수 있었다. 또한 좀 더 진화해서 서버에 있는 라이브러리를 검증하여 서비스 개발자에게 이메일로 알려주도록 하는 시스템을 추가하였다. 이렇게 하여 안정성을 확보한 솔루션이 만들어졌다.

실제로 업무가 돌아가는 것을 보면서 기분이 좋았고, 사실 초안을 작성한 나도 확신이 없었다. 오픈 소스 라이브러리에 대한 믿음을 가지고 힘을 가지고 능력을 가진 조직장때문에 일이 잘 진행되었다. 다만, 아쉬운 점은 상호간의 협력 대신 점차 그 의미는 시들어지고, 껍데기인 프로세스만 남는다는 사실이 아쉬웠다. 아마도 많은 사람들이 나와 같은 고민을 했을까? 흐훗..


마치며...

오픈 소스 거버넌스에 대해서 간단하게 적은 글이다. 프로세스를 만들기전 어떤 고민을 했는지를 적었다. 거버넌스에 대한 고민에 대해서 누군가가 이런 일을 할 때 좋은 소스가 되지 않을까 해서 작성해본다.
좋은 오픈 소스 거버넌스는 방법론적 접근보다는 검증과 신뢰 관계가 중요하다는 관점에서 시작했고, 좋은 결과를 가질 수 있었던 것 같다.

운영체제라는 주제를 서비스개발자, 디자이너, 기획자에게 설명하는 것이 너무 어려웠다. 커널이나 알고리즘을 얘기하는 것은 피드백을 주거니 받기 어려운 부분이었다. 게다가 책을 추천하는 것은 그보다 더 어려운 것이었다.  왜 운영체제라는 것이 필요한지 조차도 모르는 분들을 설명하기란 굉장히 어려웠다. 초반에 기술 서적을 설명할 때 'Hard core'라는 단어를 쓰면서 나를 위안했다. 그러나, 시간이 지나면서 상대방을 이해시키려 하지 말고 좋은 마음으로 볼 수 있도록 하는 방법이 생각이 났다. 

PPT와 유투브 동영상을 이용해서 리눅스OS에 대해서 어떤 것인지 보여주었지만, 디자이너, 기획자, 서비스개발자의 표정들이 동감대가 이루어지지 못했다. 어려운 개념을 설명하려고 쉬운 개념이 필요하다는 생각이 들었다. 즉, 눈에 들어오는 제품을 직접 만들어 가지고 가서 왜 운영체제가 필요한지를 설명하였다. 특히 나는 리눅스 OS와 C/Java언어 계통을 좋아하는 까닭에 내가 잘 할 수 있는 것들을 찾아보았다.

처음에는 안드로이드 폰이었다. 안드로이드폰을 직접 들고 가서, 북셀렉터 모임에서 안드로이드 OS에 대한 개괄적인 설명과 아키텍처를 설명하였다.


(이미지는 구글 검색후 찾아낸 것음. 내용과 무관함. 출처 : http://ss.textcube.com/blog/3/31048/attach/XaBhtFDQSb.jpg)


다들 스마트폰을 쓰고 있어서 그런지 안드로이드 OS에 대해서 그렇구나 정도로 설명을 진행했다. 반응이 미비했지만, 마음이 움직일 수 있겠다하는 생각이 들었다.

누구나 쉽게 운영체제를 좀 더 이해할 수 있는 방법이 없을까 하는 생각이 들었다. 운영체제를 깊게 이해하기 보다는 기존의 펌웨어 방식의 특징을 얘기하고 운영체제가 필요하게 되었나를 설명하면 좋겠다는 생각이 들었다. 사실 나도 책으로만 공부했지, 왜 운영체제가 필요한 것인지에 대해서 깊이 생각해본 적은 없었던 부분도 있었다.

중고 레고 마인드스톰을 35만원을 주고 구매했다. 비싸게 주고 샀지만 이런 기기를 언제 만져볼까 싶기도 하면서도 누군가에서 재미있는 설명을 해준다면 좋을 것 같아서 구매했다.


(이미지 출처 : http://ecx.images-amazon.com/images/I/618DwmMkOQL._SL500_AA300_.jpg)


( 펌웨어의 의미는 상당히 고급스러운 데, 이 문서에서는 단순히 어플리케이션처럼 바이너리를 넣은 개념으로 이해하면 좋을 듯)

북셀렉터 모임 때 마인드스톰 로봇에 프로그래밍을 하고 업로드 한후, 안드로이드 OS의 블루투쓰 콘트롤 어플을 이용해서 자유자재로 움직이는 로봇을 시연했더니 반응이 아주 좋았다. 그 다음 달에도 레고 마인드스톰을 이용하여 겉표면에 나와있는 로봇을 만들어서 혼자 흔들어대도록 만들어서 보여주었더니 역시 반응이 좋았다. 
이것저것 시연을 하면서 프로그래밍한 바이너를 저장한 펌웨어의 특징과 펌웨어 형태로 개발하는 것의 한계를 얘기할 수 있었다. 

"펌웨어는 한번에 한가지만 할 수 있다. 바로 마인드 스톰의 특징이라고 할 수 있다. 동작하게 하는 CPU와 작은 메모리로 센서를 인풋으로 삼아 다양한 동작을 가능케 한다.
그러나 동시에 여러개를 할 수 있으려면 운영체제의 개념이 필요하다. 즉 프로세스(일) 관리가 필요한 것이고, 프로세스를 관리하려면 메모리를 침범하지 않도록 보호를 해야 한다. 또한 어느 한 프로세스가 소홀히 되지 않도록 다양한 방법(알고리즘)이 필요한 것이라고 얘기했다. 또한 무엇을 하면서도 언제든지 내가 원하는 일을 바로 처리해 줄 수 있도록 하는 큰 개념을 운영체제라고 얘기했다. "

사람들이 조금씩 운영체제를 이해할 수 있었다. 눈에 보이는 레고 마인드스톰을 가지고 깊이 이해할 수 없었지만, 왜 운영체제가 필요한 것인지를 이해시키는 부분을 설명을 했다. 디자이너, 기획자들이 바로 반응이 왔다.

그 다음은 아두이노 였다. 아두이노는 마인드스톰과 달리 6-8만원 정도로 가격이 쌌고, digital input/output port가  많다보니 좀 살 것 같았다. 마인드 스톰은 레고 블럭으로 로봇 만드는 것은 바쁜 나에게 힘든 경험이었다.



(이미지 출처 : http://arduino.cc/en/uploads/Main/arduino_uno_test.jpg)


아두이노는 리눅스 운영체제를 탑재할 수 없다. 그러나 펌웨어 기반으로 동작할 수 있고, 조금만 할애하면 누구나 쉽게 멋진 예술작품을 만들 수 있기 때문에, 소개하면 좋겠다는 생각이 들었다. 또한 나는 ARM 에 대해서 깊이 알 수 있겠다는 생각이 들었다. 오픈 하드웨어, 오픈 소스를 표방하고 있기 때문에 코드를 볼 때마다 즐거웠다.

아두이노를 가지고 다양하게 시연를 해주었다. 센서. LED, MIDI 스피커, 화이트 캐릭터  LCD를 가지고 폭탄 만들기 시연, LED 방식으로 다양한 효과를 선보이니 역시 반응이 좋았다. 작은 기계에서 다양한 기능을 가지고 재미있는 일을 할 수 있는 것에 호기심을 내비쳤다.

1기 활동을 끝마치고 나서 그들에게 더 좋은 것을 보여줄 수는 없었다. 그러나 소통하는 것이 무엇인지를 조금씩 깨달았다. 기대감과 호기심을 자극시킴으로서 공감과 참여를 이끌어내는 것이 즐거웠던 것 같다. 다들 웃으면서 다양한 얘기를 해주실 때마다 고마움을 느꼈다. 그리고, 아래와 같은 솔직한 얘기를 했다.

운영체제는 항상 필요한 것은 아니다. 필요한 곳에 쓰일 수 있는 소프트웨어이지, 모든 것에 만능은 아니다.
또한  완벽한 운영체제를 만드는 것은 쉽지 않다. 어떤 곳은 펌웨어로, 어떤 곳은 운영체제로 쓰일 수 있을 것이다.

어려운 주제인 운영체제를 공감하기 위해서 사비을 지불했다. 사람들이 어려워하는 주제에 대해서 이해를 조금 높일 수 있도록 노력했다는 점은 잘했다고 생각이 든다. 그러나 눈에 보이지 않은 부분은 도외시 하지 않았나 하는 생각이 들었다. 공감대를 갖도록 하기 위해서 눈에 보이는 것 위주로 하지 않았나 생각을 한다.


기술서적에 대한 북셀렉터 활동을 하면서 배운 것을 정리해 본다.

첫번째, 어려운 주제라도 쉽게 설명할 수 있는 방법이 있다. 그것을 찾아내는 과정에서 많은 고민과 고통이 있을 수 밖에 없다. 상대방이 무지를 존중하자. 그것은 내가 설명할 수 있는 방법을 제공한다. 상대방을 쉽게 이해시키고 동감대를 만들어 낼라면 2배를 고민하고 노력하자.

두번째, 소통의 방법 중 하나는 눈으로 보여주는 것이다. 실제의 현상, 기술이 100%라면 책에서 보여주는 것은 30% 미만이다. 책의 한계를 인정하고 책에서 보여주고 싶었던 그림을 내가 소화하고 보여주자. 완벽하지 않더라도 개념을 현실로 만들어 놓자.

세번째, 쉬운 것부터 시작하자. 쉬운 것부터 시작하니 점차 어려운 것도 쉽게 해낼 수 있는 방법이 생긴다. 정말 시작은 반인 것 같다. 말만 하지 말고 정말 작은 발걸음부터 떼자.


마지막으로 책이란 무엇인가? 라는 하는 물음이 내안에 든다.
'책은 현상에 대한 아무 일부에 대한 모습을 보여주는 거울이다' 라는 생각이 든다.
언젠가 또 다시 바뀌겠지만.. ^^

처음에는 성능때문에 썼지만, 시간이 지나면서 장점보다는 단점이 더 많아지게 된다. 자바 개발바보다  c/c++ 개발자가 뽑기 힘들다. OS 가 바뀌면 골치아파진다. 만약 OS 버전이 추가되면 그에 맞춰 따로 개발되어질 수도 있다.
특히 메모리릭의 경우는 되게 어려운 상황까지 이어가게 할 수 있다. 
결국 문제가 발생된다는 것은 인건비가 나간다는 것이니.. 머리를 잘 굴려야 한다.
 

따라서, 적절하게 분리할 필요가 있다고 생각한다.

내가 생각하는 jni 코드를 하고 싶다면, 다음의 절차를 따라라..


1. jni 코드가 정말 필요한가? jni만이 해결방법인가? 대안이 있다면, jni를 쓰지 않느다. 성능보다는 유지보수성이다.
  jni 코드를 사용하면서 생기는 문제를 최소화하려면 차라리 쓰지를 말라. java lib으로 해결할 수 있게 하자

2. 반드시 써야 할 상황이면, jna는 대안이 되는가? jna (http://jna.java.net/)을 이용해서 최대한 문제가 덜 나게 하자.

3. 최악의 방법으로 jni를 사용한다.
(1) 정적 테스트, 메모리릭 테스트를 반드시 실시한다.
(2) java와 같이 쓰지 않는 아키텍처를 구성한다.
  php 웹 서버에 c++ 코드를 바인딩시켜 따로 웹을 구성한다. 이렇게 해서 적절히 분리시킨다. 
  문제의 원인을 한 서버에 두지 않게 한다.
(3) 최악의 수단으로 java와 jni를 사용한다..
   문제가 생기면, 할 수 없다...
소스 보면서 문제 파악한다..