<면접관 관점에서 관심이 생기는 개발 블로그 주제>

1. 직접 측정하고 검증한 자료

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

2. 상세한 개발 기록

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

3. 읽기 쉽게 정리한 자료

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

4. 기술적 트러블 슈트

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

5. 구현 과정의 이슈 해결

대부분의 사람은 한번에 이슈 없이 구현해낼 수 없다.
이미 한번 경험을 통해 숙련이 되어야 보통 가능하다.
구현 과정에서도 어떠한 생각으로 어떠한 자료를 찾아봤고, 그 자료에 어떤 부분을 참고해서 구현했으며, 어떠한 부분은 의구심이 들었다 등의 전반적 개발 과정에 대한 글은 좋은 글이 되곤 한다.
또는 어떠한 부분에 우려 사항이 생겼다던지, 잠재적 우려 사항이 떠올라 커버리지를 어떻게 끌어올렸다던지 같은 이슈는 아주 좋다.
복잡한 비즈니스 이슈에 대한 해결 과정은 항상 궁금하다.

6. 버그 해결 과정

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

아티클 전문 보러 가기