면접관 관점에서 본 좋은 개발자 블로그
F-Lab : 상위 1% 개발자들의 멘토링
📌 글 작성
성장에 관심이 많은 F-Lab 백앤드 멘토 Elkein
아주 작은 스타트업 여럿과 NHN, 넷마블, 크래프톤 등을 거쳤으며
게임 산업, 클라우드 플랫폼 개발, 웹 개발 등을 두루 경험한 19년 차 엔지니어개요
수많은 개발자의 사례로 인해 개발자 블로그는 취업 스펙이 되어버린 듯하다. 사실 과거에 블로그는 개인 기록의 목적이 강했고 열심히 노력하는 근성, 의욕, 의지에 대한 어필의 장이 되기도 했다.
개발 문화는 과거 sourceforge, code project, google code가 있어왔고 최근에는 github, gitlab, bitbucket을 비롯한 오픈 소스 코드 저장소가 매우 일반화되었다. 이 중 개발자 이력서에 github와 함께 blog가 필수로 첨부해야 될 존재로서 스펙으로써 작용하게 된 것은 개발자 전체에 좋은 문화가 일반화되었다고 볼 수도 있겠지만 그만큼 부담스러운 요소로써 느껴지는 분들도 많은 것 같다.
그래서 그런 분들을 위해 부담스럽지 않게 자신에게도 도움이 되면서 이력서 첨부해도 도움이 되는 블로그를 쓰는 방법을 전달하고자 한다.
블로그 플랫폼 선택 비교
우선 블로그를 시작하려면 플랫폼을 고민해야 한다.
몇 가지 한국에서 메이저한 선택지가 있다.
Tistory
- 구 다음 현 카카오에서 운영 중인 블로그 플랫폼이다.
- 티스토리는 블로그 운영에 필요한 기능을 제공하면서도 사용이 간편하다는 장점이 있다.
- 블로그의 디자인 수정도 쉽게 할 수 있지만 스킨이 아주 많지는 않다. 그럼에도 스킨 편집을 통해서 커스터 마이즈 가능한 부분이 꽤 있다고 볼 수 있음
네이버 블로그
- 커스터마이징이 아주 유리하지는 않다.
- 네이버 검색 유입에 강점이 있다.
Github Pages
- GitHub Pages는 GitHub에서 제공하는 정적 웹 호스팅 서비스
- 무료로 이용할 수 있으며 개발자들 사이에서 매우 인기가 있음
- GitHub Pages는 Jekyll과 같은 정적 사이트 생성기를 이용하여 블로그를 만들기 때문에 빠르고 안정적인 호스팅 서비스를 제공한다. 웹에서 직접 글쓰기는 어렵다고 봐야 하고, 대부분 별도의 markdown editor (나는 VS Code를 markdown editor 용으로도 쓴다)를 쓰는 것이 좋다.
- GitHub Pages는 코드와 텍스트 위주의 콘텐츠를 다루는 것이 적합하며, 블로그의 디자인을 수정하는 것이 상대적으로 어렵다. 어느 정도의 frontend 지식 (HTML, css)이 있지 않으면 스킨의 세세한 부분의 편집이 어렵다.
- 여타 플랫폼의 마크다운 글쓰기와 다른 점은 결국에 HTML 태그를 중간중간 써서 글을 써야 될 때가 있다. 이미 붙여넣기도 손이 꽤 가는 편
- Paste Image - Visual Studio Marketplace
- 해당 익스텐션을 세팅하고 쓰고 클립보드 캡쳐를 활용하면 좀 낫다.
velog
- velog는 개발 블로그 운영에 최적화된 블로그 플랫폼이다.
- 블로그의 디자인 수정도 쉽게 할 수 있어 개발 블로그 운영에도 많은 사람들이 이용하고 있음.
- 시리즈 기능이 있어서 동일 주제에 대한 글을 엮어서 보여주기 좋고, 글쓰기 툴도 준수하고 괜찮다.
- 하지만 velog는 다른 블로그 플랫폼에 비해 사용자가 적은 편이며, 블로그를 자유롭게 운영하기에는 제한이 있다.
개인적인 추천
- Github Pages나 velog를 추천한다.
- tistory는 마크다운 글쓰기 모드가 있긴 하지만 완성도가 아쉽다. 별도의 markdown editor를 이용할 바에는 Github Pages가 나은 측면이 있다고 본다.
- 네이버 블로그도 가볍게 글을 쓰거나 할 때 좋은데 개발 키워드에 대한 SEO가 아쉬운 점도 있고, 편집기가 이제 꽤 좋아졌다는 장점이 있지만 개발자 블로그로 쓰기엔 애매한 면이 있다.
- Github Pages를 추천하는 이유는 나는 backend 개발자도 frontend 이해도가 어느 정도 되어야 하기에 겸사 겸사 이해도를 높일 겸이나 frontend 개발자라면 이미 알고 있는 css, HTML 을 활용해서 블로그를 커스터 마이즈해서 블로그 자체도 포트폴리오로 활용 가능하게 승화 시킬 수 있는 장점이 있다고 생각한다.
- velog는 우선 학습하면서 블로그를 만들기엔 시간이나 여유가 조금 부족하거나 웹에서 글쓰기가 필요한 경우, 이미지 첨부가 많은 경우 Github Pages에 글을 쓸 때 아무리 확장을 쓰고 뭐하고 해도 좀 더 편하다.
블로그 작성 경험
블로그에 글을 쓴다는 경험 자체가 개발자로서 유의미하다는 것을 잊지 말아야 한다.
자 과연 그렇다면 어떠한 관점의 글을 써야 경쟁력이 있는 블로그 작성 경험이 되는 것일까?
긍정적 사례
- 자신이 어떠한 과정을 거쳐서 문제를 해결하는지 드러내는 글
- 복잡한 비즈니스 로직을 구현한 글
- 기술 이슈에 대한 고찰 과정의 깊이가 깊은 글
- 사이드 프로젝트 혹은 토이 프로젝트의 과정, 그리고 그중에서도 어떠한 결정을 어떤 생각으로 했는지 드러내는 글
- 학습한 내용에 대해서 다른 사람도 이해하기 쉽게 정리한 글
부정적 사례
- 다른 블로그의 글을 복붙한 글
- 하루하루 학습한 일기
- 기술적 연관이 없는 개인사
- 특정 기술에 대한 자료를 두서 없이 정리
면접관 관점에서 본 좋은 블로그
우테코 수료 기간에 작성하신 글들이 인상 깊었다. 특히 DB 이해도를 높일만한 주제를 아주 잘 정리했으며, 참고한 자료를 언급해 직접 작성한 글들임에 놀랐고 그 글의 주기에 놀랐다. 최근엔 취업하셔서 바쁘셔서 조금 뜸해지시긴 했으나 최근에 조금 여유를 찾으신 듯 새 글이 발행되어서 반가웠다.
<추천 글>
다양한 주제에 대해서 좋은 글을 잘 써주신다. 특히 실제 측정해 보거나 관점을 드러내는 글이 많아서 더욱 좋았다. 모든 글이 참고는 하되, 직접 작성하신 글이다. 참고하지 않고 전체적으로 모두 경험에 의한 글도 많았기도 하고.
<추천 글>
- 코틀린 groupBy, groupingBy, chunked, flatMap, aggregate 정리 - Yun Blog | 기술 블로그
- HTTP Client 책임 분리하기 - Yun Blog | 기술 블로그
- JPA JPQL의 조회 동작 살펴보기 - Yun Blog | 기술 블로그
- velopert (Minjun Kim) - velog
velog 서비스 공개 및 앞으로 velopert 블로그의 계획 | VELOPERT.LOG
velog를 만드신 velopert님의 블로그다. 실제 velog를 만드시기 이전의 글들도 너무 훌륭해서 velopert.com 도 소개했다.
<추천 글>
시니어 관점에서 관심이 생기는 주제
직접 측정하고 검증한 자료
사실 뭐 하나 측정하고 검증하고 자료로 만들기란 공수가 아주 많이 든다. 그래서 이러한 노력을 기울였다는 것을 높게 치고 인정한다. 그리고 이러한 습관이 어플리케이션의 성능을 계측 기반으로 유지하고, 튜닝할 수 있는 능력을 갖춘 엔지니어임을 증명하는 부분이다.
상세한 개발 기록
러프하게 무엇을 만들었다는 내용보다는 디테일하게 어떠한 과정을 거쳤는지 기록되어 있는 개발 블로그는 괜찮다. 기술적인 부분이 중심인 개발 블로그지만 그 과정에 대한 이야기나 좌충우돌한 사건, 협업에서 생긴 이슈, 별거 아닌 거지만 고생한 이야기 등을 잘 푸는 것도 괜찮다. 별거 아닌 이슈로 고생한 내용에 대한 제목을 거창하게 해서 낚는 것도 가끔 한 번 정도는 괜찮을 수도 있는데 다만 너무 자주 낚으면 블로그 자체에 대한 신뢰도에 악영향을 주므로 주의하자.
읽기 쉽게 정리한 자료
기본적으로 참고 자료가 존재하는 것은 당연하다. 공식 사이트, 공식 github, 공식 document 당연히 참고하게 된다. 이외에도 개인 블로그나 stackoverflow 등을 참고할 수 있다. 참고한 자료를 어떻게 이해했고, 그 자료들이 내가 필요한 부분이 뭐였고 어떠한 이해를 하게 됐는지, 그래서 결론이 무엇인지까지 이어지는 것이 좋다. 만약 학습을 위한 내용 정리라면 여러 참고 자료를 바탕으로 다른 사람이 이해하기 쉽게 작성하자.
기술적 트러블 슈트
장애를 겪었던 이야기는 아주 좋은 블로그 소재가 된다. 다만 회사가 허용하는 범주의 내용이나 어느 정도 추상적인 내용으로 작성하는 것이 좋다. 기술 이슈를 해결하는 과정에서 했던 추정, 소거, 확신, 검증 등의 과정을 잘 나열할수록 좋은 개발자의 자질을 증명하는 수단이 될 수 있다.
또한 이러한 이슈를 논리적으로 해결하면 할 수록 그게 글로 잘 드러나면 드러날수록 자신의 논리력에 대한 증명도 될 수 있으므로 아주 좋은 주제다.
구현 과정의 이슈 해결
대부분의 사람은 한번에 이슈 없이 구현해낼 수 없다. 이미 한번 경험을 통해 숙련이 되어야 보통 가능하다. 구현 과정에서도 어떠한 생각으로 어떠한 자료를 찾아봤고 그 자료에 어떤 부분을 참고해서 구현했으며 어떠한 부분은 의구심이 들었다 등의 전반적 개발 과정에 대한 글은 좋은 글이 되곤 한다.
또는 어떠한 부분에 우려 사항이 생겼다던지 잠재적 우려 사항이 떠올라 커버리지를 어떻게 끌어올렸다던지 같은 이슈는 아주 좋다. 복잡한 비즈니스 이슈에 대한 해결 과정은 항상 궁금하다.
버그 해결 과정
트러블 슈트랑 버그 해결 과정은 다소 다르다. 보통 트러블 슈트는 기술 부채를 가진 상태에서 트래픽이 폭발 했거나 DB 처리 속도가 지연되어서 서비스 장애가 나는 상황등을 말한다. 버그는 말그대로 비즈니스 로직을 처리하는 과정에서의 이슈 해결이나 잘못된 요구 사항의 이해, 혹은 복잡한 조건이 얽히고 섥혔을 때의 이슈를 주로 말한다. 재발 방지에 대한 고민, 커버리지 확보에 대한 고민도 같이 언급하면 좋다.
마치며
좋은 개발자 블로그는 숙제로 완성될 수 없다. 자주 글을 써야 한다는 강박보다는 메시지가 있는 글을 써야 한다.
주제보다 중요한 것은 어떠한 정보를 얼마나 퀄리티있게 잘 전달하느냐가 더 중요한 부분을 차지한다.(물론 위에 언급했듯 그래도 면접관이나 다른 개발자에게 도움이 되고 관심 있어 할 주제를 가져가는 것 자체는 중요하다.) 이미 알고 있는 정보라도 글로 쓰는 것은 쉽지 않다. 그리고 잘 전달되게 글 쓰는 것은 더욱 쉽지 않다.
그럼에도 좋은 개발자의 조건 중에서 글을 잘 쓰는 개발자가 있는 이유는 바로 팀 내 사내 공유할 문서를 쓸 일이 자주 있기 때문이고, 일감이나 문서를 통해서 소통해야 될 일이 많기 때문이다. 모든 사람에게 회의 시간을 내달라고 해서 소소한 내용까지 전달할 수는 없다.
또한 글을 통해 논리력을 보여줄 수 있는 개발자의 오프라인에서의 논리력은 더 뛰어나다. 즉 글을 통해서 최소치를 확인하는 수단이 되기도 한다.
결국 양질의 정보를 어떻게 남기냐인데 이 양질의 정보의 기준이 뚜렷하지 않은 분들에게 도움이 되었으면 좋겠다.
이 컨텐츠는 F-Lab의 고유 자산으로 상업적인 목적의 복사 및 배포를 금합니다.
