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

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

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

  • 참고
  • 구글 검색이 사이트의 인덱싱을 하는데에는 시간이 좀 필요로 하다.
  • 신뢰성 있는 사이트로 판단하는 사이트 위주로 빠르게 반영을 한다.
  • 좋은 제목이 중요하다.
  • 중요한 두 가지
    1. 문서
      • 구글의 검색(인덱스 기준)은 결국 문서 기반 검색이다. (크롤링 자체를 문서 기준으로 한다.)
    2. 사이트
      • 신뢰성 자체가 높으면 검색이 잘 된다.
  • 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)

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