이런 생각을 갑자기 하게된 것은 아니지만, 맨날 생각만 하고 실천하지 못한 일이다. 그 예로, 기술블로그도 마찬가지고 말이다.
무언가를 적고 공유를 하는 것에 대해서, 오리지널 기술이 아니라면 뭔가 표절하는 것만 같고 레퍼런스는 어디까지 적는게 좋은 것인지, 혹은 이력을 정리하려고 할 때 내가 어디서부터 어디까지를 적어야하는지 헤매다 보면 적는다는 행위조차 까먹는 순간
이 온다.
사회생활을 하는 어떤 한 개발자가 무언가를 적고 정리함에 있어서 어떤 것들을 정리해야할까?
- 사내 위키
- 개인 이력
- 개인적으로 공부한 내용
이렇게 크게 세개가 있다고 나는 생각한다.
쓰기 어려운 순서는 저 우선순위의 반대라고 생각하는데, 회사에서 진행하면 강제성이 어느정도 생겨서 의무감에 하게 되지만, 그 외의 것들은 당장 닥치기 전까지는 바쁜 일정에 계속 밀리게 되기 때문이다.
나의 경우는 저 셋 모두 안하고 있는 상태였는데, 이대로는 안 될 것 같아 회사에서라도 강제성을 부여하여 정리하는 습관을 들이기 위해 처음에는 기술블로그를 만들자고 건의를 했었다.
이게 사실 기술블로그야 쓰면 좋긴 하지만, 잘
만들기가 정말 어려운 것같다. 개인 기술 블로그라면 부담이라도 덜할텐데, 회사 이름을 걸고 나가자니 내가 쓰는 글들은 남들도 알 것 같고... 그러면 왠지 회사이름에 먹칠을 하는 건 아닌가 하는 소심함에 빠지게 되다가 결국 유야무야 되었던 것 같다.
시작을 하자고 내건 내가 어떤 주제로 이끌지도 정하지 못했을 뿐더러, 개인 기술블로그와 마찬가지로 플랫폼만 고르다가 결국 아무것도 못하게 되었다.
그러다가 부담감을 줄이며 사람들이 일단 편하게 글을 쓸 수 있게하고, 뭔가 새로운 팀원이 왔을 때 모르는 것이 있으면 여기를 보면되요.
라고 할 수 있는 위키를 만들어 보는건 어떨까 생각을 했다. 이때 위키가 있긴 했지만, 이곳 저곳 흩어져있기도 했고 아직 기술에 관련한 위키는 없는 상태여서 이것부터 시작하는게 좋을 것 같았다.
위키를 만들자고 슬슬 운을 떼면서, 나도 내가 작업이 끝난 것은 잊지 않도록 회사 위키에 적기 시작했다.
위키 플랫폼은 고민해본 결과 Gitlab Wiki를 사용하기로 했다. 일단 마크다운을 지원하는 것과, 히스토리 트래킹이 되는게 가장 큰 장점이었다. 조금 아쉬운건 카테고라이징이 좀 조악하다는 점인데, 여타 다른 위키들은 히스토리 트래킹이 만족스럽지 않고, 어차피 우리는 Gitlab 을 사용하고 있으니 비용적인 부분에서도 문제가 없었다.
한 두달 간격으로 내가 작업한 것은 위키에 정리를 하고 시간이 되면, 기존 위키에서 정리해서 옮기는 작업을 하고 있었다. 그리고 적는 습관을 들이자는 생각을 강하게 하게 된건 어제 있었던 일 때문이었다.
트위터에 내가 어제 하루동안 개발하다 고생한 일을 짧게 주절거리다가 트친분이 어떤 것인지 물어보시고, 어떻게 해결했는지 물어보신 것이 발단이었다.
분명 하루 내내 고생한 일이고 낑낑거리면서 결국 해결한 일인데, 설명을 할 수 없다는 것에 스스로가 너무 한심했던 것이다. 그 시행착오를 했던 시간들과 시행착오로 이상하게 적은 코드들도 기억에 남지 않아, 현재 남은 간결한 코드를 보며 기억을 더듬으며 이래선 안되겠다는 생각이 들었던 것이다.
이때 돌이켜 생각해보니, 이력에도 적을 것이 없었던 것과 직전에 작업했던 결제사 변경 작업에 대해서 고생한거 대비 위키에 적을 것이 없던 이유를 그제서야 알게되었다.
그래서 오늘 회사에 가서 위키에 대해서 정하다가 TIL까진 아니더라도, 부담없이 한 주에 최소 한개 이상은 매일 자신이 한 것과 시행착오를 겪었던 것을 남기자고 팀원에게 제안했다. 요즘 프로젝트도 리뉴얼 중이고 디자인 가이드도 작성되는 중인데다가 회사에서도 개발자들의 역량을 키우기 위해 좀 더 적극적으로 나서는 분위기인지라 팀원분도 기쁘게 받아 들여주셨다.
일단 1. 사내 위키
라도 제대로 실행하려고 하고 있으니, 습관이 된다면 기술관련한 글을 조금 더 명료하게 작성하고 메모하는 것에 대한 스킬도 늘어날 것이라 기대해 보고 있다.