기술 블로그 (Tech Blog) 기획/철학

 

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

지금으로부터 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에서 얼마나 속도가 걸리는지도 넣어주는 것도 만들어 줄려고 했다.

 

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

 

 

<결론>

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

 

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