주니어 개발자의 기술 블로그 운영 회고

먼저 이 글은 10개월동안 업데이트가 되지 않아 죽어가던 블로그를 살리기 위한 잡담 섞인 글임을 밝힙니다.

2012년 신입시절부터 개인 블로그 를 통해 저와 같은 Junior 개발자를 대상으로 소프트웨어 개발을 하면서 겪은 경험을 공유하거나 스스로 리마인드 하기 위한 내용을 정리하기 시작하였는데, 이 블로그를 통해서 데이터의 규모는 작지만 개발자들이 어떻게 기술 문서를 검색하는가에 대한 흥미로운 통계를 소개하는 것으로 이 글을 시작하고자 합니다. 그리고 개발자에게 틈틈이 문서를 작성하는 연습이 어떠한 장점이 있었는지에 대한 작은 경험을 공유하고자 합니다.

티스토리 블로그의 통계 조회 기능이 많이 부족해 개인적인 호기심으로 Google Analystics 정보를 수집할 수 있는 Javascript 코드를 넣어 놓았는데, 시간이 누적됨에 따라 생각보다 재미있는 정보를 보여주고 있었습니다. 이 정보는 블로그의 최근 1년간 방문자의 접속 정보를 토대로 작성하였습니다.

방문한 사용자의 환경 정보

개발자의 친구는 Chrome ... ? 

• 접속한 Browser 는 Chrome이 75.25%로 압도적이였으며, Internet Explorer 11이 9.65%, 그 뒤로는 미미한 수치로 Explorer 7.0 Firefox, Safari 가 뒤를 이었다.
• 한국에서의 접속이 당연하게 95.66%로 가장 많았으며, 일본, 미국, 필리핀순으로 접속자가 많았으며 이탈리아, 영국도 있었다
• 도시는 서울이 62%으로 압도적이었으며 그 다음으로는 성남, 부산, 대전 순이었다.
• 운영체제는 Windows가 75.6% Mac이 21.4% Linux의 비율도 2%나 되었다. 충격적인 결과는 기술 문서는 모바일에서의 조회수는 생각보다는 많이 낮다는 것이다. 이것을 통해 데스크탑에서 업무 중 문제 해결을 위한 검색 시도가 가장 많을 것이라고 예상해본다.

 주말에는 방문자가 1/5로 줄어든다!

•    공감하시죠(..)
•    아니군요, 주말에는 방문자가 없는 세상이 와야 합니다.
•    연말에 비교적 방문자 수가 높다. 왜죠....?

•    블로그에서는 주로 Java, Spring 에 대한 글의 비율이 많음에도 Android 개발에 대한 포스팅의 페이지뷰가 가장 높았다.
•    Spring Framework에 대한 포스팅의 페이지뷰 역시 높았다.

 평균 페이지에 머무는 시간은 04분 26초

•    그래도 작정하고 글을 쓰는 습관을 기릅시다...

 

"정말 하고 싶은 이야기는 앞으로는 기술 문서를 어떻게 관리해야할까?"에 대한 고민

앞서 말한 통계는 흥미를 이끄는 주제 였다면, 본론으로 들어가서 기술 문서를 작성한 경험을 회고 해보고 이를 통해 앞으로의 대한 이야기를 하려고 한다. 이렇게 블로그를 통해 통계 정보를 수집하는 잉여스러운 일이 쓸데없는 일처럼 보일 수가 있겠지만 이런 일들이 지금까지 개발자로서 성장하는데에 큰 도움을 주고 있다는 생각이 든다.

특정 시기에 '내가 이 시기에는 이런 분야에 관심이 있었구나' 혹은 '내가 이 기술에 관련된 일을 했었구나'를 시작으로 리마인드 하다보면, 앞으로는 어떻게 하면 좋을까?' 라는 질문을 스스로 할 수 있게 상기시켜 주며, 조회수가 많은 글은 업데이트를 하기 위해 다시 살펴보게 만드는 계기를 만들어 주기도 한다.

개발자는 코드로만 말하면 되는 것 아닌가?라고 할 수도 있겠지만 개인적인 경험으로는 개발자에게도 기술과 관련된 내용뿐만 아니라 다양한 주제에 대하여 꾸준히 글을 쓰는 연습은 내 생각을 효과적으로 정리하는 연습이 되며 문제를 해결해 나아가는 과정에서 결국 프로그래밍을 즐겁게 만들어주는 원동력이 될 수 있다고 생각한다. 하지만 아쉽게도 4년 동안 꾸준히 글을 작성해 오다가 올해부터 세계일주를 시작하면서, 10개월 가까이 업데이트를 못하고 있었다.

여행을 마치고 다시 본격적으로 애플리케이션 개발을 시작하게 되면서 '정말' 오랜만에 블로그의 방문자를 조회해 보았는데, 웬걸.. 오히려 방문자수가 점점 늘어나고 있는 것을 발견하였다.

하.. 이걸 보고는 가만히 있을 수가 없게 되었다.

현재 Swift를 통해 iOS 애플리케이션 개발을 시작하였는데 동기부여 차원에서 나와 같이 Swift를 통해 iOS 애플리케이션 개발을 시작하는 사람을 대상으로 다시 기술문서를 작성하기로 하였다. 이런 글을 통해 소문을 내는 것은 자신을 학대할 수 있는 아주 효과적인 방법이라고 생각한다.. 하지만 블로그가 아닌 Markdown 문서를 통해 Github Repository 에 기술문서를 작성하기로 결정을 하였는데 그 이유는 다음과 같다.

왜 Markdown 문서인가

사실 Markdown 같은 도구가 중요하다기보다는 Markdown을 통해 개발자들이 쉽게 위키 문서를 생산해 낼 수 있다는 것이다. 2014년에 NHN Ent 로 이직 후에 놀라웠던 점은 개발환경에 대한 표준 가이드가 있다는 것, 빌드&배포, 모니터링 등을 돕는 사내 플랫폼과 협업을 위한 프로세스 등이 이전에 근무하던 회사와 비교했을 때 잘 갖추어져 있었다는 것이었다.

이전 근무지에서는 이런 부분들이 왜 필요한지에 대한 경험을 뼈저리게 할 수 있어서 역시나 좋았습니다..

하지만 그 무엇보다도 가장 관심이 갔던 것은 사내의 위키 서비스였다. 그 이유는 평소에 협업을 하면서 내가 가장 치열하게 했던 고민을 아주 쉬운 방법으로 해결하고 있었다는 것이다.

바로 이거야!

다양한 구성원들과 협업을 할 때에는 프로젝트를 시작하기에 앞서 우리가 하는 일이 왜 필요한지에 대해 서로 이해하고 의견을 좁혀나가는 것이 가장 중요하다고 생각한다. 위키 서비스를 통해서 개발자들이 자신의 경험을 손쉽게 정리하고 자연스럽게 다른 사람들이 볼 수 있는 구조를 통해 소통하고 있었다.

그래서 이후부터는 업무에 필요한 정보를 먼저 위키 페이지에 정의하고 함께 Overview & Review 할 수 있는 환경을 만드는 것을 시작으로 하위에 필요한 Task 및 기술적 요소들을 점진적으로 정리해 나아가는 습관을 기를 수가 있었다.

Markdown이 무엇이죠?

• Github Markdown Guide : https://guides.github.com/features/mastering-markdown/

왜 Github에서 문서를 관리하기로 하였나

• 먼저 문서관리에 대한 일관성을 유지하고 싶었다. 즉 여기저기 흩어져 있는 문서 덕분에 정보의 단절이 일어나는 문제를 해결하기 위함이다. 사내에서 작성한 문서는 기본적으로 회사의 자산이지만 사내에서 진행한 프로젝트를 통해 얻은 경험을 개인적으로도 지속적으로 리마인드 할 수 있었으면 했다. 프로젝트 진행을 하면서 학습한 내용부터 운영 노하우까지.. 미련하게 제대로 관리하지 못해 영원히 사라지게 된 문서들을 돌아보면 정말 너무 아쉽다.
• 가장 중요한 요소는 이렇게 쌓인 Reference는 나와 같은 Junior 개발자들에게는 본인이 스스로 성장하기 위한 좋은 발판을 마련해 줄 수 있다는 것이다.
• 혼자 하는 것이 아니라 Github에서 문서를 관리하고 공유해서 다른 개발자들의 참여를 이끌어 낼 수 있지 않을까?
• 비슷한 이유로 나만이 볼 수 있는 문서와 다른 개발자도 볼 수 있게 되는 문서는 큰 차이가 있다. 같은 내용도 조금 더 고민하게 만들어 주며 지속적으로 수정하게 된다. 이 차이는 다른 이들이 보다 더 쉽게 문서를 읽을 수 있게 만들어준다.
• 소스코드와 같이 자신이 작성한 모든 문서는 Github Repository에서 master로 관리하고 블로그와 같은 다른 페이지는 branch로 생각하자.

프로젝트만 레거시 시스템이 있는 것은 아니라고 생각한다. 지속적인 리마인드를 위해서는 이전 글에서 현재까지의 경험을 반영하여 더 나은 문서를 생산해 나아가야 한다.

앞으로 기술문서를 다시 작성한다면 어떤 주제를 다루지?

Swift를 통해 iOS 개발을 하면서 겪는 경험을 시작으로 다시 기술문서를 작성할 예정이다. 그 이외에 Junior 개발자에게 친숙한 카테고리를 미리 정해놓고 순차적으로 문서를 작성하고 문서 공유에 관심이 있는 개발자들이 관심 있는 주제에 직접 참여할 수 있었으면 하는 바람이다. 각 주제에 대해서 처음 접근하는 Junior 개발자를 위한 내용이 대다수가 될 것이며, 위키 페이지의 구조는 크게 카테고리와 문서로 이루어져 있다.

 앞으로 Junior 개발자를 대상으로 다루고 싶은 주제에 대한 카테고리

어떻게 참여할 수 있나요?

아래의 Github Repository를 통해서 참여할 수 있습니다.

• Github Repository : https://github.com/wjdsupj/stunstun-wiki/

이 문서의 내용에 대해 공감하시는 모든 분들은 카테고리 또는 문서를 추가하거나 수정할 수가 있습니다. 저와 같은 Junior 개발자의 시선에서 고민하신 과정을 공유해주시면 더욱 좋을 것 같습니다.

예를 들면 저와 같은 경우에는 Maven을 통한 프로젝트 빌드를 학습할 때 빌드 도구가 왜 필요한지도 모른 채 시작하다 보니 막막했던 기억이 납니다. 그 이유는 첫 조직에서는 IDE에서 빌드한 결과물을 서버에 직접 배포하고 있었기 때문입니다.

처음에는 내용이 부족할 수도 있겠지만 꾸준하게 이어 나아갈 수 있다면, 이 습관이 결국 프로그래밍을 즐겁게 만들어 준다고 생각합니다.

누구나 새로운 주제나 문서를 생성할 수 있습니다. 언제든지 가벼운 마음으로 위의 Github에 Pull Request 해주세요 :)