참고 :
https://f-lab.kr/blog/graduate-interview-habihow-write-developer-blog
https://yozm.wishket.com/magazine/detail/2134/개발 블로그 작성 이유와 목적을 방향성에 맞춰서 작성하자
- 활용한 내용 기록: 단순히 공부한 내용을 넘어서, 어떻게 프로젝트에 적용하고 개선했는지를 공유하세요. 이는 개념에 대한 실질적 이해를 보여줍니다.
- 깊이 있는 개념 정리: 단순히 개념을 소개하는 것이 아니라, 그 내부 메커니즘을 깊게 파고들어 분석하세요. 예를 들어, WebClient 클래스의 사용법뿐만 아니라, 내부 동작 원리와 장단점을 상세히 설명하세요.
- 글쓰기 목적 명확히 하기: 블로그는 경험과 지식을 공유하는 공간입니다. 따라서 다른 사람들이 이해하기 쉬운 글을 작성하는 것이 중요합니다.
- 이미지 활용: 프로젝트의 구조나 설계 의도를 설명할 때는 그림을 효과적으로 사용하세요. draw.io 같은 도구를 이용해 명확하고 깔끔한 이미지를 만드는 것이 도움됩니다.
- 문단 구분: 읽는 사람이 피곤하지 않도록 적절하게 문단을 나눠 글을 구성하세요.
- 링크 활용: 복잡한 개념에 대해서는 관련 링크를 제공해 독자가 추가 정보를 쉽게 찾을 수 있도록 하세요.
- 글 스타일 적용: 굵게, 기울임체, 리스트 등을 사용해 글의 가독성을 높이세요.
긍정적 사례
- 자신이 어떠한 과정을 거쳐서 문제를 해결하는지 드러내는 글
- 복잡한 비즈니스 로직을 구현한 글
- 기술 이슈에 대한 고찰 과정의 깊이가 깊은 글
- 사이드 프로젝트 혹은 토이 프로젝트의 과정, 그리고 그중에서도 어떠한 결정을 어떤 생각으로 했는지 드러내는 글
- 학습한 내용에 대해서 다른 사람도 이해하기 쉽게 정리한 글
부정적 사례
- 다른 블로그의 글을 복붙한 글
- 하루하루 학습한 일기
- 기술적 연관이 없는 개인사
- 특정 기술에 대한 자료를 두서 없이 정리
관심이 생기는 주제
직접 측정하고 검증한 자료
사실 뭐 하나 측정하고 검증하고 자료로 만들기란 공수가 아주 많이 든다. 그래서 이러한 노력을 기울였다는 것을 높게 치고 인정한다. 그리고 이러한 습관이 어플리케이션의 성능을 계측 기반으로 유지하고, 튜닝할 수 있는 능력을 갖춘 엔지니어임을 증명하는 부분이다.
상세한 개발 기록
러프하게 무엇을 만들었다는 내용보다는 디테일하게 어떠한 과정을 거쳤는지 기록되어 있는 개발 블로그는 괜찮다. 기술적인 부분이 중심인 개발 블로그지만 그 과정에 대한 이야기나 좌충우돌한 사건, 협업에서 생긴 이슈, 별거 아닌 거지만 고생한 이야기 등을 잘 푸는 것도 괜찮다. 별거 아닌 이슈로 고생한 내용에 대한 제목을 거창하게 해서 낚는 것도 가끔 한 번 정도는 괜찮을 수도 있는데 다만 너무 자주 낚으면 블로그 자체에 대한 신뢰도에 악영향을 주므로 주의하자.
읽기 쉽게 정리한 자료
기본적으로 참고 자료가 존재하는 것은 당연하다. 공식 사이트, 공식 github, 공식 document 당연히 참고하게 된다. 이외에도 개인 블로그나 stackoverflow 등을 참고할 수 있다. 참고한 자료를 어떻게 이해했고, 그 자료들이 내가 필요한 부분이 뭐였고 어떠한 이해를 하게 됐는지, 그래서 결론이 무엇인지까지 이어지는 것이 좋다. 만약 학습을 위한 내용 정리라면 여러 참고 자료를 바탕으로 다른 사람이 이해하기 쉽게 작성하자.
기술적 트러블 슈트
장애를 겪었던 이야기는 아주 좋은 블로그 소재가 된다. 다만 회사가 허용하는 범주의 내용이나 어느 정도 추상적인 내용으로 작성하는 것이 좋다. 기술 이슈를 해결하는 과정에서 했던 추정, 소거, 확신, 검증 등의 과정을 잘 나열할수록 좋은 개발자의 자질을 증명하는 수단이 될 수 있다.
또한 이러한 이슈를 논리적으로 해결하면 할 수록 그게 글로 잘 드러나면 드러날수록 자신의 논리력에 대한 증명도 될 수 있으므로 아주 좋은 주제다.
구현 과정의 이슈 해결
대부분의 사람은 한번에 이슈 없이 구현해낼 수 없다. 이미 한번 경험을 통해 숙련이 되어야 보통 가능하다. 구현 과정에서도 어떠한 생각으로 어떠한 자료를 찾아봤고 그 자료에 어떤 부분을 참고해서 구현했으며 어떠한 부분은 의구심이 들었다 등의 전반적 개발 과정에 대한 글은 좋은 글이 되곤 한다.
또는 어떠한 부분에 우려 사항이 생겼다던지 잠재적 우려 사항이 떠올라 커버리지를 어떻게 끌어올렸다던지 같은 이슈는 아주 좋다. 복잡한 비즈니스 이슈에 대한 해결 과정은 항상 궁금하다.
버그 해결 과정
트러블 슈트랑 버그 해결 과정은 다소 다르다. 보통 트러블 슈트는 기술 부채를 가진 상태에서 트래픽이 폭발 했거나 DB 처리 속도가 지연되어서 서비스 장애가 나는 상황등을 말한다. 버그는 말그대로 비즈니스 로직을 처리하는 과정에서의 이슈 해결이나 잘못된 요구 사항의 이해, 혹은 복잡한 조건이 얽히고 섥혔을 때의 이슈를 주로 말한다. 재발 방지에 대한 고민, 커버리지 확보에 대한 고민도 같이 언급하면 좋다.
기술 블로그는 결국 내 생각과 경험을 잘 표현해야하는 공간
기술 블로그란 특정 기술 분야의 정보나 지식을 공유하기 위한 블로그입니다. 개발자들이 주로 소프트웨어 개발, 프로그래밍, 특정 언어 등에 대해 다루며, 기술 업무를 수행하는 다른 개발자들에게 정보를 제공합니다.
기술 블로그는 다양한 형식으로 작성될 수 있습니다:
기술 동향, 최신 트렌드에 대한 글, 유용한 도구, 프레임워크, 라이브러리의 사용법이나 적용 사례 공유, 실무에서 마주친 문제와 해결법에 대한 경험, 진행 중인 프로젝트에 대한 내용
기술 블로그의 필요성은 다음과 같습니다:
경험, 관심사 공유의 효과적인 방법,취업 시 이력서보다 효과적인 본인 PR 수단,개발자의 생각과 접근 방식을 나타내는 공간
기술 블로그 운영에 도움이 되는 팁
1. 본인의 경험과 생각을 기록:
단순 사용법보다는 해당 기술을 사용하며 얻은 경험이나 생각을 공유하는 것이 더 효과적입니다.
글 주제를 명확히 하고 벗어나지 않기: 주제에 집중하고 필요하면 참고 링크를 제공합니다.
- 출처 검증:
정보의 출처를 꼼꼼히 검증해 신뢰도를 유지합니다.
- 활성화된 플랫폼 사용:
사용자 피드백을 통해 글의 퀄리티를 높이고 동기부여를 받습니다.
운영하기 쉬운 방법 선택: 글 작성과 관리가 쉬운 플랫폼을 선택해 지속 가능한 블로그 운영을 지향합니다.
- 완벽하지 않아도 시작하는 것이 중요합니다. 고민이 너무 많으면 시작하기 어려울 수 있으므로, 불완전함을 인정하고 차근차근 성장해 나가는 것이 중요합니다.
아직도..
기술블로그에 대한 글들을 볼 때마다 내 블로그가 많이 부족함을 느끼지만, 다른 이들에게 도움이 될 수 있는 데이터사이언스 블로그가 되도록 노력해야지! 아직까진 나의 경험과 생각에 대한 글들이 많이 없어서 스스로도 아쉽다고 느끼지만, 시간이 생기면 했던 프로젝트를 스스로 성찰하고 더 나아갈 방향을 찾아봐야 겠다. 미래의 나야 고생 더 하자^^
