Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

내가 블로그에 글을 쓰는 과정

블로그 글감을 받기로 하고 많은 기대를 하진 않았고 SNS에서는 지인들의 장난스러운 댓글이 좀 달렸지만, 곧 괜찮은 주제가 이슈에 올라오기 시작했다. 내가 쓰기 어려운 글도 있고 기술적으로 이런저런 준비가 필요한 글도 있었지만 가장 먼저 눈에 들어온 이슈가 블로그 포스팅을 하는 과정을 올려달라는 내용이었다.

블로그에서 다른 글을 쓰면서 내가 사용하는 방법 등을 조금씩은 설명한 적이 있었지만, 전체적으로 설명한 적은 없다는 생각이 들었다. 이건 내가 10년 가까이 계속해온 일이라 정리하면 글로 적을 수 있고 내 방식이라 모두에게 도움되진 않겠지만, 누군가에게는 도움될 수도 있겠다 싶었다. 그나마 블로그 글쓰기에 대해 가장 가까이 정리한 글은 재작년에 발표했던 블로그 주도 개발인데 여기서는 블로그를 하는 동기 부여에 가깝지 과정에 관한 내용은 많지 않으므로 여기서는 내가 블로그에 글을 쓰는 과정에 관해서 설명하려고 한다.

포스팅 글감 모으기

블로그에 글을 쓰려면 글을 쓸 주제가 있어야 한다. 이 블로그는 개발 블로그이므로 블로그에 글을 쓸 주제를 적으려면 내가 계속 개발을 해야 하고 개발에 관한 공부를 해야 한다. 개발에 대한 소감을 적는 것은 아니므로 주로는 새로운 것을 해보거나 몰랐던 것을 알게 되면 블로그에 적어야겠다 하는 생각을 하게 된다. 그러다 보니 초반에는 몰랐던 것을 알게 되면 블로그에 올렸다.

  • 프레임워크나 라이브러리에서 새롭게 알게 된 사용방법
  • 프로그램 등의 설치 및 설정 방법
  • 좋은 글을 보면 (허락하에) 번역
  • 새로 등장한 기술을 공부하고 그 내용을 정리
  • 겪은 오부류의 해결 방법
  • 책이나 세미나에 대한 후기

처음 몇 년 동안은 대부분 위의 내용이었던 것 같다. 요즘은 많이 안 적지만 그래서 예전에는 Hello World 부류의 글이나 설치방법을 정리하는 주제를 많이 적었다. 이렇게 적은 글은 내가 한번 공부하거나 겪은 걸 까먹지 않기 위함도 있고 특히 설치 같은 건 한번 하고 나면 몇 개월 내에는 다시 설치할 일이 없다 보니 나중에 다시 설치할 때 나도 많이 참고하게 되었다.

범위가 큰 때도 있고 작은 범위의 주제도 있지만, 주제를 적으려면 그 내용을 어느 정도는 파악하고 있어야 했다. 항상 블로그를 적어야지 생각하고 있었기 때문에 적을 수 있겠다 싶으면 다 블로그에 올렸다. 너무 블로그만 적어서 코딩을 많이 못 할 정도였던 것 같다. 그런데도 글을 적으려면 뭔가 새로운 것을 해봐야 하기에 계속 공부할 수 있는 동기부여가 됐던 것 같다. 지금은 안 그렇지만 예전에는 유지보수 업무를 많이 했기에 내가 적는 글은 내 업무와는 약간 동떨어진 경우가 많았다.(그래서 많은 사람이 나를 프론트엔드 개발자로 알고 있기도 하다.)

새로운 것을 개발에 적용해보고 공부도 해야 하지만 빠르게 변하는 IT에서 트랜드를 좇아가야 어떤 기술을 공부할지 파악할 수 있는데 나 같은 경우는 주로 Twitter를 이용하는 편이다. 현재 1,100명 정도를 팔로잉하고 있는데 대부분은 개발자이거나 IT 쪽 관련이고 가능하면 거의 모든 글을 가볍게라도 읽으려고 하는 편이고 바쁠 때 못 보는 경우를 대비해서 주요 개발 트위터 계정은 별도의 List로 만들어서 바쁠 때는 이 리스트에 올라온 글만 본다. 트위터를 통해서 요즘 어떤 기술들에 사람들이 관심을 가지는지도 보고 새로운 팁도 보고 좋은 글도 접하게 된다.

그 외에는 RSS를 400여 개 정도 구독하고 있어서 여기 올라온 글 중에 괜찮아 보이는 글은 내 메일로 보내서 시간이 날 때 틈틈이 읽어보는 편이다. 전에는 InstapaperPocket처럼 읽을 글을 관리해주는 서비스를 썼지만 읽는 속도보다 쌓는 속도가 훨씬 빨라서 더는 관리할 수 없게 되어 이젠 읽을 글을 그 자리에서 못 읽으면 내 메일로 보내서 읽으면 inbox에서 지우는 방식을 사용하고 있다. 그 외에는 페이스북이나 트위터에서 글을 저장해놓거나 마음을 눌러놨다가 읽으면 지우는 방식을 취하고 있다. 기술 뉴스를 발행한 뒤로는 기술 뉴스 올리려면 내가 글을 읽어야 해서 기술 뉴스 발행 전에 더 열심히 글을 읽고 읽을 글로 쌓아둔 글을 강제로라도 소비하게 되는 효과를 누리고 있다.

포스팅 글감 관리

예전에는 블로그가 우선순위의 최고에 있었기에 개발하고 글로 쓰고 공부하고 글로 쓰고 했기에 따로 관리할 필요가 없었지만, 요즘은 업무 외에 사이드프로젝트도 하고 번역도 하고 공부도 하고 다른 글도 읽고 해야 하기에 주제를 정해도 글을 쓰는 작업이 지연되는 경우가 많아졌다. 다른 부분도 중요하기에 일부러 낮춘 것이기도 하다.

바로 적지 않으면 잊어먹는데 바로 적을 시간이 없으므로 몇 년 전부터는 개인 노트에 이런 내용을 적고 있다.

Day One에 작성한 개발노트

나는 Day One이라는 맥용 앱으로 노트를 작성하는데 나는 블로그를 오래 해서인지 여기에 무엇을 적을지는 큰 고민 없이 나오는 것 같고 메모습관 같은 게 좀 자리 잡은 편이라 Day One에 적기 전에도 Sublime Text 등의 에디터로 뭔가 적어놓는 경우가 많다. 앞에서 얘기한 주제들이나 인터넷에서 팁이나 좋은 방법 등을 보면 즉시 적거나 그날 바로 여기에 적는다. 개인 노트에 적다 보면 코드의 보안을 지키려고 노력하거나 예제를 독립적으로 할 필요 없이 빠르게 적을 수 있어서 많은 시간을 들이지 않아도 된다. 그래서 요즘 글 주제의 반 정도는 Day One에 적은 것 중에 별도의 포스팅으로 올릴 수 있어 보이는 것을 가져와서 다시 정리해서 적는 경우가 많아졌다.

Things에 관리하는 글쓰기 목록

할 일 관리에 Things를 사용하는데 블로그에 올려야겠다고 생각한 주제는 할 일목록에 추가한다. 바로 적어야지 하는 글도 있고 이건 좀 천천히 고민해 보면서 적어야지 하는 글도 있다. 이런 주제를 모두 할 일로 만들어놓고 조만간 써야지 하는 글은 Due Date를 설정해 놓고 있다. 요즘은 3일에 글 하나 정도를 목표로 하고 있어서 내 일정을 보고 내가 쓸 수 있는 시간과 글을 쓰는데 걸릴 시간을 대충 생각해서 Due Date를 설정하지만, 요즘은 제때에 못 쓰는 게 일반적이라 밀리기 시작하면 다시 조정하곤 한다. 위 스크린샷에도 Today에만 걸린 글이 3개나 있는 건 설 연휴에 다 쓸 생각이었지만 하나도 못 쓰면서 밀리면서 오늘까지 모두 밀린 것이다. ㅠ

글 적기

이제 글을 쓸 때가 되었으면 자리를 잡고 글을 쓰기 시작한다. 보통은 주제를 정할 때 어느 내용을 적을지 어느 정도 생각해 놓은 편이고 글쓰기 전에 출퇴근길이나 휴식할 때 어떤 내용을 적을지 어떻게 설명하면 좋을지 좀 미리 생각해보는 편이다. 아주 긴 글이 아니면 레이아웃을 미리 작성해 보거나 하진 않는 편이다.

Sublime Text에서 작성하는 글

글을 쓸 때는 주로 Sublime Text를 쓰는 편이다. 난 JetBrains의 IDE나 vim에서 주로 코딩을 하고 Sublime Text에서는 코딩을 거의 하지 않는다. 내 Sublime Text에는 주로 메모나 최근에 보고 있는 기술 등에 대한 메모 등의 탭이 죽~ 열려있는 게 보통이다. 적을 때는 Markdown으로 적고 있고 블로그도 마크다운을 지원하도록 설정해 놓은 상태이다.

긴 글은 파일로 저장해서 Dropbox에 저장한다

간단한 글을 바로 적어서 발행하고 며칟날에 걸쳐서 쓰는 글은 .md파일로 저장해서 Dropbox에서 관리하고 있다. 관리라기보다는 그냥 보관만 하고 있다. 퍼블리싱한 다음에는 다시 열어볼 일은 없는 편이라서... 간단한 글은 2~3시간 만에 적기도 하지만 예제도 작성해야 하고 테스트도 해봐야 하는 글은 2~3일에 걸쳐서 쓰기도 한다.(2~3일 내내 쓰는 건 아니고...)

초안을 따로 적지는 않고 한 번에 적는 편이다. 앞에서 어떤 식으로 설명할지 머릿속에서 어느 정도는 생각해 놓기도 했고 글의 흐름이 정형화되어 있기도 해서인듯하다. 예전에는 적다가 흐름이 이상해지는 것 같아서 레이아웃 자체를 다시 조정하는 때도 많았는데 이제는 훈련이 되었는지 그런 경우는 많지 않다. 그렇다고 한 번에 글을 죽~ 다 적는다는 것은 아니고 적다가 어색하게 느껴지면 조금씩 조정하면서 적는 게 익숙해졌다.

내가 기술 관련 글을 적을 때는 보통 다음과 같은 흐름으로 적는 것 같다.

  1. 왜 이 글을 적는지를 설명한다. 새로운 기술이라면 왜 기술을 보게 되었는지, 어떻게 사용할 예정인지, 보기 전에는 어떤 기대를 했는지 등을 적고 특정 사용방법이나 오류라면 내가 뭘 하려고 하다가 이런 방법을 찾게 되었는지 등을 초반에 적는다. 이 부분이 이후에 나오는 내용에 대한 사전지식을 갖는 데 도움이 될 것이라고 생각한다.
  2. 간단한 소개를 작성한다. 어떤 도구라면 이 도구가 어떤 도구이고 만든 사람은 어떻게 설명하고 있는지... 스펙이나 다른 문서에서는 어떻게 나와 있는지 내가 공부하면서 알게 된 내용을 정리한다.
  3. (필요하다면) 설치방법이나 설정 방법을 적는다.(원한다면 따라 해 볼 수 있게 하기 위함이다.)
  4. 이해를 돕기 위한 간단한 사용방법을 적는다. 도구라면 아주 기본적인 사용방법을 적고(적다가 이 부분만 따로 글로 올리기도 한다.) 라이브러리 등의 사용방법이면 문서에 나와 있는 정도의 사용방법을 설명한다.
  5. 좀 더 고급의 사용방법을 적는다. 앞에서 소개한 내용을 바탕으로 활용할 수 있는 방법을 적거나 다양한 사용사례를 설명한다.
  6. 사용해본 소감을 적는다.

이렇다 보니 아주 간단한 글은 적지 않게 되었다. 예를 들어 오류 메시지를 검색하면 바로 문서에 잘 설명되어 있다거나 stackoverflow에 명확히 해결책이 나와 있는 글은 뭔가 베껴서 글을 적는 것 같아서 이젠 잘 적지 않게 되었다. 필요할 때 다시 검색하면 되는 일이기도 하고... 최소한 내가 뭔가 학습을 해서 정리를 하거나 여러 곳에 흩어져 있는 내용을 조합해서 적는 편이다.

기술 글이 아닌 지금 이글 같은 에세이류의 글은 좀 다른 편인데 이런 글은 정형화된 패턴은 없다. 기술 글은 설명하는 패턴이 아주 명확하게 보이지만 에세이는 그렇지 않기 때문에 머릿속에서 생각을 더 많이 하는 편이다. 무엇을 말하고 싶은지 어떤 흐름으로 설명을 할지... 등등을 많이 정리해보고 적는다. 이렇게 해도 쓰다 보면 글이 산으로 가게 되어 쓰다 말고 포기한 글도 꽤 많다. 이 글 같은 경우는 이슈에 올려주신 요청을 보고 어떤 내용을 원하는지 내가 어디까지 적을 수 있는지를 많이 생각해 봤다.

글을 쓸 때는 가능한 한 관련 링크를 추가하려고 하고 있다. 처음 보는 사람은 단어만으로는 무언인지 모를 수 있으므로 링크를 추가하고 참조자료 같은 경우는 신뢰성을 높이는 의미도 있고 더 자세히 보고 싶은 사람도 참고할 수 있도록 귀찮지 않은 선에서 최대한 링크를 달고 있다.

퇴고

난 퇴고에는 힘을 별로 안 쓰는 편이다. 개인 블로그이기도 하고 내가 글 쓰는 직업을 가진 것은 아니므로 퇴고에 너무 많은 시간을 들이면 효율(?)이 안 나오기 때문이다. 가볍게 다시 읽어보면서 어색한 부분만 약간 조정하는 정도이다.

dandy를 이용한 맞춤법 검사

맞춤법검사는 꼭 돌린다. 맞춤법을 아주 잘 지키는 편이 아니고 공개적으로 발행되는 글이므로 최소한의 맞춤법 검사 정도는 한다. 예전에는 귀찮아서 못했지만 fallroot님이 macOS에서 쉽게 부산대 맞춤법 검사기를 사용할 수 있도록 dandy를 만들어 주신 뒤로는 dandy를 계속 쓰고 있다. 나는 초기 버전 외에 새 버전을 만들다가 멈추신 develop 브랜치를 포크해서 사용하고 있다. Sublime Text에서 글을 다 쓰고 문단마다 블록을 선택하고 dandy를 실행하면 수정할 부분을 알려주고 나는 선택만 하고 승인을 누르면 해당 블록 내에서 알아서 교체되므로 편하게 맞춤법을 수정하고 있다.

발행

글을 다 썼으면 내 블로그의 관리자페이지에 들어가서 새 글을 등록한다. Markdown을 지원하므로 그냥 내용만 복사해서 넣으면 된다. 위에서는 설명하지 않았지만, 이미지가 필요한 경우에는 Markdown 문법으로 이미지가 들어가야 하는 부분만 표시해 놓고 글을 쓰면서 스크린샷을 찍어놓은 뒤에 Photoshop으로 블로그에 맞게 리사이즈를 하고 용량을 최적화해서 저장한다. 블로그 관리자에서 이미지를 올린 다음에 앞에서 표시해놓은 각 이미지 부분에 이미지를 추가한다.(이 부분까지 자동화하는 방법을 못 찾아서 그냥 이렇게 한다.)

Textcube에서 글 발행

적당한 카테고리와 태그를 추가한 다음에 발행한다. 특별한 이유가 없으면 보통은 그 자리에서 발행을 하는 편이다. 최근에는 광고를 달기도 했고 궁금하기도 해서 발행하는 시간과 방문자 수가 상관관계가 있는지 실험해보고 싶지만 그렇게 하려면 장치가 많이 필요해서 아직은 내버려 두고 있는 상황이다. 글을 발행하면 IFTTT가 RSS에 새로운 글이 올라왔는지 확인하고 새 글이 있으면 내 트위터로 트윗을 올려준다. 난 트위터를 페이스북과 연결해 놔서 자동으로 페이스북까지 발행이 된다.

글 쓰는 습관?

보통 블로그를 하면 일반적인 패턴이 블로그 도구를 세팅하고 더 좋은 블로그 도구를 찾아 이사를 하다가 뭔가 회의감을 느끼고 글을 써야지 했지만 몇 개 쓰다가 멈추게 되는 패턴인 것 같다. 그래서 "어떻게 꾸준히 포스팅할 수 있나요?"가 보통 궁금해하는 부분인 것 같다.

하지만 나는 이런 패턴을 겪지 않아서 솔직히 이 부분은 어떻게 설명해야 하는지 잘 모르겠다. 나는 처음부터 개인 노트에 글을 적다가 내가 글을 적는 게 아니라 좋은 글을 복사해다가 내 노트에 붙여넣기만 해서 뭔 내용인지도 모르고 있다는 걸 깨닫고 공개 블로그에 글을 쓰기 시작했다. 지금 생각하면 엄청나게 좋은 결정이었는데 그때는 블로그가 유행하던 시기라 그냥 블로그를 만든 거고 방문자 수는 많지 않았지만, 그냥 공부하고 복습하듯이 글을 쓰면서 정리하고 하는데 금방 재미를 붙였던 것 같다. 그 뒤부터는 너무 열심히 블로그를 하느라 코딩이나 다른 걸 못하는 게 걱정이었지 글을 못쓰겠어 서가 걱정은 아니었기 때문에 그런 부분에 대한 노하우는 쌓여있지 않다. 블로그 글을 쓰려고 특별히 노력한다기보다는 써야 하는 압박은 느끼는데 다른 작업을 하느라 시간이 모자라서 밀리는 경우가 훨씬 더 많다.

나 같은 경우는 처음 블로그를 시작하던 당시 블로그가 유행하던 때라서 그런지 쉽게 블로그에 안착한 것 같고 블로그에 글쓰기를 다른 모든 작업보다 우선순위에 올려놓고 있어서 그런지 쉽게 금방 블로그를 하는 혜택을 얻기 시작했던 것 같다. 세미나 등에 가서 사람들에게 인사하고 온라인에서 교류하기도 쉬웠고 그 패턴이 계속 반복되어서 지금까지 왔기 때문에 블로그를 버린다는 생각은 전혀 안 하고 있다.

블로그는 오픈소스랑 비슷하다는 생각을 한다. 요즘은 오픈소스가 인기이지만 그런데도 오픈소스를 안 하는 사람들한테 왜 개인 시간을 써서 오픈소스를 하는지, 왜 주말에 오픈소스 프로젝트를 하는지, 소중한 자신의 소스를 왜 공개로 올리는지를 설득하기는 쉽지 않다. 오픈소스를 하는 사람은 이해할 텐데 오픈소스 프로젝트에 도움을 받고 공개된 소스코드에서 배우고 하면서 자연히 내 소스도 (부끄럽지만) 공개로 공유하는 것이다. 같은 맥락으로 다른 사람이 올려준 글로 쉽게 배우면서 내가 배운 걸 다시 올리는 과정도 그 안에 자연히 포함되어 있다고밖에는 설명을 하지 못하겠다. 모든 사람이 글을 쓰는 걸 좋아할지는 모르니 내 성격에 좀 더 맞는 방법이었을 수도 있고...

추가로 언제 블로그 글을 쓰냐? 어떻게 시간이 만드냐? 하는 부분도 마찬가지로 설명이 어려운데 그냥 남는 시간의 상당 부분을 개발에 쏟는 것일 뿐이다. 애기가 있거나 가족과 시간을 많이 보내야 해서 개인 시간이 부족하다거나 회사가 너무 바빠서 시간이 없다거나 하는 건 사람마다 다르고 어쩔 수 없는 부분이라고 생각한다. 피곤할 땐 잠도 많이 자고 미드도 보고 게임도 하지만 주로는 코딩하거나 기술 블로그를 읽거나 글을 쓴다. 나한테는 이 부분이 내 삶에서 가장 재미있는 부분 중 하나이기 때문에 바쁘더라도 이런 시간을 계속 만들고 있는 거고 오히려 장기간 이런 시간을 못 만들면 스트레스를 많이 받는 편이다.(뭔가 전혀 도움이 안 되는 재수 없는 느낌의 설명을 하는 것 같기도 하고...)

시간을 재고 쓰진 않지만 어떤 내용을 쓸지 생각해본 시간은 제외하고 이 글을 쓰는 데는 3시간 정도 걸린 것 같다.

2017/01/31 22:26 2017/01/31 22:26

jq로 JSON 응답에서 원하는 문자열 생성하기

전에 JSON을 탐색하고 조작할 수 있는 커맨드라인 도구 jq를 소개했다. jq는 꽤 유용한 도구이지만 동시에 jq의 문법에 익숙해져야 해서 잘 쓰기가 약간 어렵기도 하다. 최근에는 좀 더 쓰기 편한 jid라는 도구도 나왔다. jq에는 기능이 많은데 쓰는 기능만 사용하다가 좀 더 잘 활용해 보려고 필요할 때 조금씩 기능을 더 찾아가면서 써보고 있다.

최근에 구글 번역 API를 사용해보고 있는데 구글 번역에서 지원하는 언어를 API로 제공하고 있다. 현재 만들고 있는 사이드 프로젝트에서 사용자가 번역하고자 하는 언어를 선택할 수 있도록 지원언어를 셀렉트박스로 만들고 싶었는데 언어가 너무 많았다.

$ curl "https://translation.googleapis.com/language/translate/v2/languages?key=YOUR_API_KEY&target=en"
{
  "data": {
    "languages": [
      {
        "language": "af",
        "name": "Afrikaans"
      },
      {
        "language": "sq",
        "name": "Albanian"
      },
      {
        "language": "am",
        "name": "Amharic"
      },
      {
        "language": "ar",
        "name": "Arabic"
      },
      {
        "language": "hy",
        "name": "Armenian"
      },
      ... 중략 ...
      {
        "language": "xh",
        "name": "Xhosa"
      },
      {
        "language": "yi",
        "name": "Yiddish"
      },
      {
        "language": "yo",
        "name": "Yoruba"
      },
      {
        "language": "zu",
        "name": "Zulu"
      }
    ]
  }
}

이 API는 https://translation.googleapis.com/language/translate/v2/에서 제공되는데 제공하는 언어가 104개나 된다.(영어 기준) 이를 셀렉트박스로 만들기 위해 <option> 태그로 만들고 싶은데 보면서 적기에는 너무 많아서 jq를 이용해서 <option> 태그를 만들도록 했다.

$ curl "https://translation.googleapis.com/language/translate/v2/languages?key=YOUR_API_KEY&target=en" | jq -r '.data.languages[] | "<option value=\"\(.language)\">\(.name)<\/option>"'
<option value="af">Afrikaans</option>
<option value="sq">Albanian</option>
<option value="am">Amharic</option>
<option value="ar">Arabic</option>
<option value="hy">Armenian</option>
...중략...
<option value="xh">Xhosa</option>
<option value="yi">Yiddish</option>
<option value="yo">Yoruba</option>
<option value="zu">Zulu</option>

응답으로 받은 JSON에서 원하는 <option> 태그를 만들었고 이를 복사해서 사용하면 된다.

이 기능은 jq의 String interpolation)을 사용한 것이다. 실제 변환하는 부분은 다음 부분이다.

jq -r '.data.languages[] | "<option value=\"\(.language)\">\(.name)<\/option>"'
  • -r 옵션을 붙이지 않으면 결괏값이 모두 큰따옴표로 묶이므로 이를 제거하기 위해서 raw 값을 받도록 한 것이다.
  • 뒤에 붙은 홑따옴표 내의 부분이 실제 jq가 JSON을 조작하는 부분이다.
  • .data.languages[]는 응답 데이터에서 data 밑에 languages를 가져온 것이고 이 값이 배열이므로 다음 조작에서 배열로 다루기 위해 []를 붙였고 이를 파이프(|)로 연결했다.
  • 앞에서 받은 데이터를 문자열로 만드는 부분이 "<option value=\"\(.language)\">\(.name)<\/option>"이다. 큰따옴표 안에 있는 부분은 그냥 문자열이고 문자열 내에서 앞에서 받은 데이터를 사용할 때는 \(.language)와 같은 문법을 사용한다. 그래서 이는 Google API에서 받은 값에서 language는 value에 넣고 name<option> 태그 안에 넣은 것이다.

배열마다 실행하므로 앞에서 본 것처럼 <option value="hy">Armenian</option>같은 최종문자열이 완성된다.

2017/01/26 23:22 2017/01/26 23:22