[후기] 블로깅과 테크니컬 라이팅 세미나

글 쓰는 개발자 모임(변성윤님, 데이터 사이언티스트)

• 6개월 간의 의도적인 글쓰기 모임 강제로 진행
• 현재는 1기를 지나 2기 진행
• 2주마다 글을 하나씩 쓰도록 가이드 함.
• 글 쓰는 것도 피드백을 통해 보완점을 찾게 한다.
• 다만, 서로 피드백을 주고 받는데에는 시간이 좀 걸리고, 서로의 친분이 좀 필요로 하다.
• 모임을 하다보니 여러 관심사가 맞는 사람들끼리 오프라인 모임을 진행하게 됨.

기술 블로그 생존 전략: 구글 시대의 글쓰기(김대권님, @44bits.io 운영자, @nacyot)

• 참고

  • 좋은 기술 블로그를 만들어 나가기 위한 8가지 제언
• 구글 검색이 사이트의 인덱싱을 하는데에는 시간이 좀 필요로 하다.
• 신뢰성 있는 사이트로 판단하는 사이트 위주로 빠르게 반영을 한다.
• 좋은 제목이 중요하다.

• 중요한 두 가지

  1. 문서
  2. 구글의 검색(인덱스 기준)은 결국 문서 기반 검색이다. (크롤링 자체를 문서 기준으로 한다.)
  3. 사이트
  4. 신뢰성 자체가 높으면 검색이 잘 된다.
• SEO의 핵심은 질 좋은 컨텐츠이다.
• 완성된 형태의 글을 쓰는 것이 사이트의 신뢰성을 높이는 중요한 포인트가 된다.

• 연구 결과를 보니 사람들이 7분 정도는 집중해서 읽더라.

  • 5200자 정도의 분량이다.
  • 1만자 이상의 글을 시리즈로 나눠서 쓰는 것이 좋다.
• 컨텐츠 관리가 가능한 도구를 사용하는 것이 좋다.
• 보존, 보존, 그리고 보존이 중요하다.

To. 지식 공유를 시작하려는 개발자 (홍연희님, LINE Developer Relations팀)

• 이상한 모임
• 파이콘
• GDG DevFest
• 코딩클럽
• 글 쓰는 프로그래머 협회
• 트레바리

다양한 커뮤니티 활동을 하심.

• 분야는 IT
• 주변의 개발자가 많더라.
• 잘 하는건 컨텐츠 기획이더라…등등

그래서 LINE Developer Relations팀에 합류하게 되었다.

개발자 컨퍼런스 지원 / 개발자 밋업 지원 / 소셜 미디어 관리등

사내 개발자를 위한 Tech Talk / Lightning Talk

그래서 결국에는 컨텐츠, 이벤트, 기획을 함으로써 라인의 브랜딩을 만들어 가는 일을 하고 있다.

사용자를 외면하지 않는 릴리스 노트 (조은별님)

• IT출판 편집자 6년 | 보안 회사 테크니컬 라이터로 근무중

테크니컬 라이터의 일

• 메뉴얼
• 릴리스 노트
• API 문서
• UI 용어/메시지
• 개발 계획서
• 테스트 계획서
• 기술 블로그
• IT 도서

오늘의 이야기는 릴리스 노트를 어떻게 만들어 가는지에 대한 이야기!

• 릴즈 노트의 정의

  • 문제를 정의하고 해결점을 기술한 문서
  • 신규 기능
  • 개선 기능
  • 오류 수정
  • 간결한 문장
• 게임 릴리즈의 경우는 게임 캐릭터 신규 출시에 관한 부분을 강조한다.

• 개발자를 위한 릴리즈 노트에는 대부분 버그 수정, 신규 기능, 개선 기능을 카테고리로 분류해서 작성한다.

  • 정말 예쁘게 작성 된 릴리즈 노트를 찾기 어렵다. (Github)

릴리즈 노트 작성시 고려 사항

1. 제품/사용자 특성
2. 일관된 문서 포맷
3. 세줄 요약

개발자는 왜 블로그를 해야하나요? (이동욱님)

• jojoldu.tistory.com 운영을 하고 있음.
• 테마 구입
• 블로그 개선 - 댓글 (github)
• markdown을 입력하면, 티스토리로 글을 쓰도록 Node.js 모듈을 만듬.

블로그 장점

• 수익
• 기고/집필 요청
• 세미나 초대권
• 인지도
• 인터뷰
• 이직
• 사내 기술 블로그

왜 블로그를 해야 하나?

• 나를 표현 할 수 있는 수식어가 있는가?

• 내가 누구에게나 표현할 수 있는 아이템이 있어야 함.

  • 그게 나에겐 블로그이다.
• 블로그는 아이덴티티이다.

개발 관련 기술 블로그 운영하기(변정훈님, Outsider’s)

• 12년간 기술 블로그를 운영 중
• 3일에 1개의 포스팅 목표
• 글 1개 짧게는 2 ~ 4시간정도 소요됨.
• 글 1개에 길게는 2-3일 걸린다.
• 퇴고는 하지 않는다.

주제

• 개발하면서 적을 수 있는 건 전부
• 새로운 도구, 환경 설치/설정
• 알게 된 라이브러리, 도구의 사용법
• 트러블슈팅, 장애처리
• IT이슈

방향

• 나보다 잘하는 사람도 있음
• 나보다 못하는 사람도 있음
• 누군가에게는 도움이 되도록 쓰는 편
• Dayone을 이용해서 적는다. (Private Note)

왜 하는가?

처음에 글을 쓰게 된 이유

• 공부하는 것이나 글쓰는 것이 똑같음.
• 배운걸 자꾸 잊어버려서.
• 설정해본적이 있는데 기억이 안나서.
• 겪어보던 문제인데, 어떻게 했는지 기억이 안나서.
• 듣거나 알게 된 지식을 내 것으로 만드는 과정이라고 생각함.
• 무언가를 해도 내 것이 되는건 아니라고 생각해서 블로깅을 하다보니 내 것이 되는 것 같다.

글을 공개로 쓰면 좋은 점

• 누구나 이해할 수 있어야 한다.
• 글로 정리하려면 잘 알고 있어야 한다.
• 글로 정리하면서 다시 고민해 볼 수 있다.
• 나의 인지도가 조금 올라감.

글의 흐름

• 하고자 했던 일
• 경험한 문제 상황 정리(격리된 상황)
• 시도해 본 방법
• 왜 동작이 안되는지? 왜 동작 하는지?
• 문제 상황 재현
• 예제 코드
• 관련 링크
• 개념 설명

MCVE(최소한의, 완성된, 입증가능한 예제)

• (Minimal, Complete, and Verifiable Example)

일 하면서도 글을 많이 작성한다. 글을 지속적으로 쓰는 방법은 딱히 없다. 어느 순간 도움이 된다는 걸 느끼게 되다보니 자연스레 쓰게 된다.