면접관이 좋아하는, 기술 블로그 쓰는 법(내가 부정적 사례의 표본일수도?)

 

 

 

[이력서]

링크 : ______________________________

 

이제는 이력서, 포트폴리오에서 필수가 되어버린 [기술 블로그] 나 역시도 블로그를 활용하고 있는 사람으로서 이렇게 작성하고 있는게 올바른가(?) 아니 맞는 방향인지 궁금해졌다. 또 velog, tistory, naver blog 등 다양한 플랫폼부터 다양한 포맷으로 작성되는 글들이 많은데 어떤 블로그가 면접관의 마음을 사로잡는지 알고싶었다.

 

면접관의 피드백을 바탕으로 그 내용의 일부를 가져와 나의 생각과 함께 포스팅한다.

 

개요

수많은 개발자의 사례로 인해 개발자 블로그는 취업 스펙이 되어버린 듯하다. 사실 과거에 블로그는 개인 기록의 목적이 강했고 열심히 노력하는 근성, 의욕, 의지에 대한 어필의 장이 되기도 했다. 개발 문화는 과거 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는 다른 블로그 플랫폼에 비해 사용자가 적은 편이며, 블로그를 자유롭게 운영하기에는 제한이 있다.

블로그 작성 경험

블로그에 글을 쓴다는 경험 자체가 개발자로서 유의미하다는 것을 잊지 말아야 한다.

자 과연 그렇다면 어떠한 관점의 글을 써야 경쟁력이 있는 블로그 작성 경험이 되는 것일까?

긍정적 사례

1. 자신이 어떠한 과정을 거쳐서 문제를 해결하는지 드러내는 글
2. 복잡한 비즈니스 로직을 구현한 글
3. 기술 이슈에 대한 고찰 과정의 깊이가 깊은 글
4. 사이드 프로젝트 혹은 토이 프로젝트의 과정, 그리고 그중에서도 어떠한 결정을 어떤 생각으로 했는지 드러내는 글
5. 학습한 내용에 대해서 다른 사람도 이해하기 쉽게 정리한 글

부정적 사례

1. 다른 블로그의 글을 복붙한 글
2. 하루하루 학습한 일기
3. 기술적 연관이 없는 개인사
4. 특정 기술에 대한 자료를 두서 없이 정리

 

사실 나의 블로그 내용들을 살펴보면 거의 대부분 학습일기거나, 기술적 연관없는 개인사도 다룬다. 그 이유는 즉슨 그냥 일상 블로그를 작성하고 싶었던 것도 있다.(그냥.. 글쓰는 것을 좋아하는 편..*) 그러나, 고민해보니 면접관이 보고자 하는 것은 특정 경험 및 기술에 대한 history 라는 것을 알게 되었다.. 

뭐가 맞고 틀린건 아닐 수 있지만, 많게는 몇 천명 넘게 지원서류를 확인하는 사람으로서 채용과 관련되지 않은 내용은 되도록 보고싶지 않은 것이 사실일 수도 있다. 따라서.. 지원자들이 면접관을 배려하는 것도 큰 감동 포인트 중 하나가 아닐까 라는 생각이 든다😊

 

면접관이 본 좋은 블로그

hudi.blog

우테코 수료 기간에 작성하신 글들이 인상 깊었다. 특히 DB 이해도를 높일만한 주제를 아주 잘 정리했으며, 참고한 자료를 언급해 직접 작성한 글들임에 놀랐고 그 글의 주기에 놀랐다. 최근엔 취업하셔서 바쁘셔서 조금 뜸해지시긴 했으나 최근에 조금 여유를 찾으신 듯 새 글이 발행되어서 반가웠다.

 

<추천 글>

• JDBC 라이브러리 구현하기
• JPA의 낙관적 락을 사용한 동시성 이슈 해결
• JPA의 낙관적 락과 비관적 락을 통해 엔티티에 대한 동시성 제어하기

Yun Blog | 기술 블로그

다양한 주제에 대해서 좋은 글을 잘 써주신다. 특히 실제 측정해 보거나 관점을 드러내는 글이 많아서 더욱 좋았다. 모든 글이 참고는 하되, 직접 작성하신 글이다. 참고하지 않고 전체적으로 모두 경험에 의한 글도 많았기도 하고.

<추천 글>

• 코틀린 groupBy, groupingBy, chunked, flatMap, aggregate 정리 - Yun Blog | 기술 블로그
• HTTP Client 책임 분리하기 - Yun Blog | 기술 블로그
• JPA JPQL의 조회 동작 살펴보기 - Yun Blog | 기술 블로그
• velopert (Minjun Kim) - velog

직접 측정하고 검증한 자료

사실 뭐 하나 측정하고 검증하고 자료로 만들기란 공수가 아주 많이 든다. 그래서 이러한 노력을 기울였다는 것을 높게 치고 인정한다. 그리고 이러한 습관이 어플리케이션의 성능을 계측 기반으로 유지하고, 튜닝할 수 있는 능력을 갖춘 엔지니어임을 증명하는 부분이다.

상세한 개발 기록

러프하게 무엇을 만들었다는 내용보다는 디테일하게 어떠한 과정을 거쳤는지 기록되어 있는 개발 블로그는 괜찮다. 기술적인 부분이 중심인 개발 블로그지만 그 과정에 대한 이야기나 좌충우돌한 사건, 협업에서 생긴 이슈, 별거 아닌 거지만 고생한 이야기 등을 잘 푸는 것도 괜찮다. 별거 아닌 이슈로 고생한 내용에 대한 제목을 거창하게 해서 낚는 것도 가끔 한 번 정도는 괜찮을 수도 있는데 다만 너무 자주 낚으면 블로그 자체에 대한 신뢰도에 악영향을 주므로 주의하자.

읽기 쉽게 정리한 자료

기본적으로 참고 자료가 존재하는 것은 당연하다. 공식 사이트, 공식 github, 공식 document 당연히 참고하게 된다. 이외에도 개인 블로그나 stackoverflow 등을 참고할 수 있다. 참고한 자료를 어떻게 이해했고, 그 자료들이 내가 필요한 부분이 뭐였고 어떠한 이해를 하게 됐는지, 그래서 결론이 무엇인지까지 이어지는 것이 좋다. 만약 학습을 위한 내용 정리라면 여러 참고 자료를 바탕으로 다른 사람이 이해하기 쉽게 작성하자.

기술적 트러블 슈트

장애를 겪었던 이야기는 아주 좋은 블로그 소재가 된다. 다만 회사가 허용하는 범주의 내용이나 어느 정도 추상적인 내용으로 작성하는 것이 좋다. 기술 이슈를 해결하는 과정에서 했던 추정, 소거, 확신, 검증 등의 과정을 잘 나열할수록 좋은 개발자의 자질을 증명하는 수단이 될 수 있다 또한 이러한 이슈를 논리적으로 해결하면 할 수록 그게 글로 잘 드러나면 드러날수록 자신의 논리력에 대한 증명도 될 수 있으므로 아주 좋은 주제다.

구현 과정의 이슈 해결

대부분의 사람은 한번에 이슈 없이 구현해낼 수 없다. 이미 한번 경험을 통해 숙련이 되어야 보통 가능하다. 구현 과정에서도 어떠한 생각으로 어떠한 자료를 찾아봤고 그 자료에 어떤 부분을 참고해서 구현했으며 어떠한 부분은 의구심이 들었다 등의 전반적 개발 과정에 대한 글은 좋은 글이 되곤 한다.

또는 어떠한 부분에 우려 사항이 생겼다던지 잠재적 우려 사항이 떠올라 커버리지를 어떻게 끌어올렸다던지 같은 이슈는 아주 좋다. 복잡한 비즈니스 이슈에 대한 해결 과정은 항상 궁금하다.

버그 해결 과정

트러블 슈트랑 버그 해결 과정은 다소 다르다. 보통 트러블 슈트는 기술 부채를 가진 상태에서 트래픽이 폭발 했거나 DB 처리 속도가 지연되어서 서비스 장애가 나는 상황등을 말한다. 버그는 말그대로 비즈니스 로직을 처리하는 과정에서의 이슈 해결이나 잘못된 요구 사항의 이해, 혹은 복잡한 조건이 얽히고 섥혔을 때의 이슈를 주로 말한다. 재발 방지에 대한 고민, 커버리지 확보에 대한 고민도 같이 언급하면 좋다.

마치며

좋은 개발자 블로그는 숙제로 완성될 수 없다. 자주 글을 써야 한다는 강박보다는 메시지가 있는 글을 써야 한다.

주제보다 중요한 것은 어떠한 정보를 얼마나 퀄리티있게 잘 전달하느냐가 더 중요한 부분을 차지한다.(물론 위에 언급했듯 그래도 면접관이나 다른 개발자에게 도움이 되고 관심 있어 할 주제를 가져가는 것 자체는 중요하다.) 이미 알고 있는 정보라도 글로 쓰는 것은 쉽지 않다. 그리고 잘 전달되게 글 쓰는 것은 더욱 쉽지 않다.

 

그럼에도 좋은 개발자의 조건 중에서 글을 잘 쓰는 개발자가 있는 이유는 바로 팀 내 사내 공유할 문서를 쓸 일이 자주 있기 때문이고, 일감이나 문서를 통해서 소통해야 될 일이 많기 때문이다. 모든 사람에게 회의 시간을 내달라고 해서 소소한 내용까지 전달할 수는 없다. 또한 글을 통해 논리력을 보여줄 수 있는 개발자의 오프라인에서의 논리력은 더 뛰어나다. 즉 글을 통해서 최소치를 확인하는 수단이 되기도 한다.