개인 블로그를 통해 저와 같은 Junior 개발자를 대상으로 소프트웨어 개발을 하면서 겪은 경험을 공유하거나 스스로 리마인드 하기 위한 내용을 정리해왔습니다.

블로그를 통해서 데이터의 규모는 작지만 개발자들이 어떻게 기술 문서를 검색하는가에 대한 흥미로운 통계를 소개하는 것으로 이 글을 시작하려 합니다. 그리고 개발자에게 틈틈이 문서를 작성하는 연습이 어떠한 장점이 있었는지에 대한 작은 경험을 공유하고자 합니다.

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

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

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

모바일개발 기술에 대한 관심이 압도적으로 높다. 그리고 역시 Spring 이다.

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

집중해서 읽으면 좋은 글보다는 짧지만 유용한 팁을 소개하는 포스팅이 조회수가 높다.

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

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

최근 1년동안의 페이지뷰별 Article

제목 작성일 링크 페이지뷰 %
Android 디바이스의 고유 번호 획득 시 고려 해야 할 점 2014.01 http://stunstun.tistory.com/184 12493 11.5%
Spring Boot 에서 Java Config를 통해 myBatis 연동하기 2015.11 http://stunstun.tistory.com/250 8930 8.2%
Open JDK 적용시에 고려해야 할 점 2014.09 http://stunstun.tistory.com/222 7110 6.5%
Google In-App Billing의 상품 등록과 보안 이슈 정리 2014.04 http://stunstun.tistory.com/205 7032 6.5%
Android 4.1 버젼 이후에 Notification 다양하게 노출 하기 2013.08 http://stunstun.tistory.com/101 6400 6%
DB Connection Pool 관리 어떻게 하면 좋을까? 2013.01 http://stunstun.tistory.com/53 5700 5.3%
Android Studio IDE 와 Gradle 2015.06 http://stunstun.tistory.com/231 3600 3.3%
Spring Boot 에서 myBatis 연동시 Multi DataSource 운용하기 2015.12 http://stunstun.tistory.com/252 3195 2.9%
Android 에서의 효율적인 단위테스트와 TDD 2014.12 http://stunstun.tistory.com/225 2986 2.7%

본론으로 들어가서 블로그를 운영한 경험에 대해 회고를 해보자면, 이렇게 블로그를 통해 통계 정보를 수집하는 잉여스러운 일이 쓸데없는 일처럼 보일 수가 있겠지만 이런 일들이 지금까지 개발자로서 성장하는데에 많은 도움을 주고 있다는 생각이 든다. 특정 시기에 ‘내가 이런 분야에 관심이 있었구나’ 혹은 ‘내가 이 기술에 관련된 일을 했었구나’를 통해 ‘앞으로는 어떻게 하면 좋을까?’ 라는 질문을 스스로 할 수 있게 상기시켜 주며, 조회수가 많은 글은 업데이트를 하기 위해 다시 리마인드 할 수 있는 계기를 만들어 주기도 한다.

개발자는 코드로만 말하면 되는 것 아닌가?라고 할 수도 있겠지만 개인적인 경험으로는 개발자에게도 기술과 관련된 내용뿐만 아니라 다양한 주제에 대하여 꾸준히 글을 쓰는 연습은 내 생각을 효과적으로 정리하는 연습이 되며 문제를 해결해 나아가는 과정에서 결국 프로그래밍을 즐겁게 만들어주는 원동력이 될 수 있다고 생각한다.

하지만 아쉽게도 4년 동안 연평균 약 25개의 글을 꾸준히 작성해 오다가 올해부터 세계일주를 시작하면서 10개월 가까이 업데이트를 못하고 있었다. 여행을 마치고 다시 애플리케이션 개발을 시작하게 되면서 ‘정말’ 오랜만에 블로그의 방문자를 조회해 보았는데, 웬걸.. 오히려 방문자수가 점점 늘어난 것을 발견하였다.

Year 월평균 방문자수
2012년 300명 per a month
2013년 800명
2014년 1800명
2015년 3000명
2016년 10월 현재 5800명 (하지만 글을 1도 작성안함..)

가만히 있을 수가 없게 되었다!

해서 동기부여도 할 겸 현재 Swift를 통해 iOS 개발을 시작하였는데 이것을 시작으로 다시 기술문서를 작성하기로 마음을 먹었다. 그리고 이런 글을 통해 소문을 내는 것은 자신을 학대할 수 있는 아주 효과적인 방법이다… 하지만 블로그가 아닌 Markdown 문서를 통해 Github Repository에 기술문서를 작성하기로 결정을 하였는데 그 이유는 다음과 같다.


왜 Markdown 문서인가

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

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

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

바로 이거야!

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

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

Markdown이 무엇이죠?

Markdown은 마크업 언어의 일종인, 존 그루버(John Gruber)와 아론 스워츠(Aaron Swartz)가 만들었다. 읽기도 쓰기도 쉽다는 장점이 있다. 확장자는 .md를 쓴다. 간단히 말해 문서를 쓰는 하나의 방법이라고 해두자. 아래의 페이지를 보면 쉽게 이해 할 수 있다.

Github Markdown Guide


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

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


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

Swift를 통해 iOS 개발을 하면서 겪는 경험을 시작으로 다시 기술문서를 작성할 예정이다. 그 이외에 Junior 개발자에게 친숙한 카테고리를 미리 정해놓고 순차적으로 문서를 작성하고 문서 공유에 관심이 있는 개발자들이 관심 있는 주제에 직접 참여할 수 있었으면 하는 바람이다.

각 주제에 대해서 처음 접근하는 Junior 개발자를 위한 내용이 대다수가 될 것이며, 위키 페이지의 구조는 크게 카테고리와 문서로 이루어져 있다.

앞으로 주니어 개발자를 대상으로 다루고 싶은 주제들

카테고리 설명
Fundamentals 개발자에게 밑천이 되는 소프트웨어 공학 전반
Python Python 관련 카테고리
Java Java의 기본지식 및 Java8에 대한 내용
Front-End Front-End 관련 카테고리
Android Android 관련 카테고리
iOS Swift를 통한 iOS 개발에 관한 지식
Spring Framework Spring Framework에 대한 지식, Spring Boot과 Spring 5.0 에 대한 Insight
DevOps 개발환경 및 인프라 운영에 대한 내용
Git Git에 대한 사용 경험과 그 밖의 협업도구에 대한 이야기

어떻게 참여할 수 있나요?

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

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

예를 들면 Maven을 통해 애플리케이션 빌드를 학습할 때 빌드 도구가 왜 필요한지도 모른 채 시작하다 보니 막막했던 기억이 납니다.

처음에는 내용이 부족할 수도 있겠지만 꾸준하게 이어 나아갈 수 있다면, 이 습관이 결국 프로그래밍을 즐겁게 만들어 준다고 생각합니다. 언제든지 가벼운 마음으로 Pull Request 해주시면 됩니다.

누구나 새로운 주제나 문서를 생성할 수 있습니다.

문서를 작성하시면서 지켜주시면 좋은 것들

  • 최상단의 폴더명은 다루고 싶은 주제에 대한 카테고리명을 뜻합니다.
  • 모든 카테고리는 이 주제가 왜 필요한지에 대한 readme.md 문서를 포함해야 합니다.
  • 모든 문서의 파일명은 영문 소문자로 이루어지고 확장자는 *.md 입니다. 파일명에 띄어쓰기가 필요할 때에는 ‘-‘ 을 사용합니다.
  • 그 이외에 문서에 대한 제약사항은 없습니다 :)