DevLog - 사내 개발블로그 운영 중..!

요약 

그간 일하면서, 회사 내에 기술을 공유하고 연구하는.. 뭔가가 없다는 게 조금 아쉬웠는데.
이번 3월에 제안했던 개발블로그 기획이 통과되면서, 관리자 역할을 맡아 컨텐츠를 쌓으며 달리는 중입니다. 

 

개발블로그?

1년 간 라이브서비스를 운영하면서 느낀 건, 치명적인 문제는 구성원이 그게 문제가 될 수 있다는 걸 몰랐음을 의미한다는 것입니다 ( 각주 1. ) 마치 로그라이크 게임처럼, 라이브에는 밟아봐야 아는 함정이 있습니다.
문제가 있다면, 게임에는 컨티뉴가 있지만 라이브 서비스에는 없다는 것입니다. 심지어 클릭하면 HP가 차오르는 편리한 포션도, 세이브 포인트도 없죠.. 피를 흘리며 그냥 전진할 수밖에 없습니다. 

그래서 라이브를 진행할수록 기술공유가 절실해졌습니다. 완벽하게 모든 문제를 방어할 수는 없겠지만, 최소한 10명 남짓한 사람들이 모여서 생각하는 것보다는 100명이 모인 것이 분명 더 낫겠죠. (바퀴를 발명할 일도 없을 테고요) 서로의 "공략"을 주고받을 수 있는 무언가가 필요했습니다. 그리고 분명 나만 필요한 게 아닐 테니까.. NDC와 넷마블 기술 블로그에 영감을 받아 한번 추진해 보기로 했습니다. 

 

원하는 것을 얻어내기 위한, 전략 한 스푼

니즈와 레퍼런스가 명확했기 때문에, 프레임을 구상하는 것은 어렵지 않았습니다. 9월에 온보딩 페이퍼를 만들면서 이후 컨플루언스에 여러 문서들을 쌓아봤기 때문에, 컨플루언스 특징이나 사용법도 어렵지 않았고. 문서를 작성하면서 "요렇게 하면 더 낫습니다", "이런 일이 있었고 이렇게 해결했습니다", "이런 게 있습니다" 정도로 정보들을 카테고리화할 수 있겠다고 생각했었으니까요. 작성 규칙을 만드는 것은 학회장 시절에 학사내규를 만들어보려고 했던 것 ( 각주 2. ) 이 도움이 되었습니다.

프레임이 순조롭게 만들어지고 있었던 것과는 대조적으로, 승인은 약간의 어려움을 앞두고 있었습니다. 이 "개발 블로그"가 그 목적을 달성하기 위해서는 반드시 사내 모든 개발자들이 접근할 수 있는 공식 저장소의 지위를 획득해야 했는데 ( 각주 3. ) 요 부분이 뚫기 어려운 지점이었습니다. 
일반적으로 사람은 글쓰기를 어려워합니다. 지식을 공유하기 위해서는 글이 필요합니다. 사람은 일이 적은 것을 선호하고  일이 늘어난다면 그것을 줄이고자 하며, 상상과 사실을 엄밀하게 구분하여 판단하지 않기 때문에 '뭔가 적어서 공유해 봅시다'를 추진하는 것은 보통 어렵습니다. 

다시 말해 "공유하는 것 좋지, 근데 그럼 일단 개인 스페이스부터 시작하는 건 어때?" 따위의 말들을 듣게 된다는 것입니다. (이미 회사에서 그걸 하고 있었다는 것은 차치하고 하여간) 이 기획을 실현시키기 위해서는 '저 무언가가 나한테까지 영향을 미치지 않았으면 좋겠다'는 마음을 뚫어야 한다는 얘기고.. 여기서부터는 전략의 영역입니다. ( 각주 4. )   

 

개발 블로그

원하는 것을 얻어내기 위해서 조율하는 지난한 과정을 몇 주 간 진행하고 ( 각주 5. ) 무사히 통과되어서. 사내 컨플루언스에 공식 스페이스와 관리자권한을 얻어낼 수 있었고 4월 1일부터 개발블로그를 운영하게 되었습니다.

전체공개된 스페이스기는 하지만, 정식 오픈과 공지는 6월 1일에 할 예정이며 그전까지는 일단 15명 남짓한 사람들에게 초대장을 보내서 컨텐츠를 쌓아가고 있는 상태입니다. ( 각주 6. ) 그래서 아마 6월까지는 바쁠 것 같습니다. 곧 팀의 메인 프로그래머가 된 지도 슬슬 1년이 되어가는데. 성공적으로 론칭하고 나면 1년간 뭘 했는지도 한번 정리해야겠네요. 

하여간, 힘을 내야죠 재밌습니다.  

 

각주

1. A: A(=치명적 버그 또는 이슈)가 존재함, I(A) : A가 인지됨, D(A) : A가 삭제됨 일 때
   I(A) → D(A) 이므로 A → ¬I(A) 입니다. 
2. 이 학칙은 실제로 도입하는 것에는 실패했는데.. 그 과정에서 규칙은 통제가 아니라 옳은 것을 위해 함께 가는 방향을 합의하기 위해 존재하는 것이며, 책임 없는 선언은 공허하다는 것을 배웠습니다. 하고자 했던 것에 비해 제가 가진 능력이 보잘것없었습니다.
3. 그래야 신뢰를 빠르게 얻을 수 있습니다. 그리고 신뢰가 있어야 그나마 약간의 참여라도 기대할 수 있습니다.  
4. 일은 두 가지 종류로 나눌 수 있는데, 좋음이 명확하냐(or 합의된 좋음이 존재하는가)와 그렇지 않음이 그것입니다. 전자는 그냥 그 좋음의 방향대로 나아가면 됩니다. 메모리를 적게 먹고 읽기 쉬워지고 실행이 빨라지는걸 누가 마다하겠어요. 후자는 조율이 필요합니다. 가장 좋은 건 상대방이 내 의견을 좋아하게 만드는 거고요. 경우에 따라 다르지만 이러한 상황에서 선의는 굉장히 효율적인 도구입니다. 
5. 개인평가에서 최고점을 받은 몇 안 되는 인원 중 하나였던 덕분에 다행히 수월하게 조율할 수 있었습니다. 
6. 첫인상이 중요하기 때문에.. 처음 접속한 사람들이 풍성한(?) 컨텐츠를 볼 수 있도록 최대한 준비하고 있습니다. 그리고 그 때문에 이 블로그 업데이트가 조금 뜸했습니다;;