요즘IT
위시켓
최근 검색어
전체 삭제
최근 검색어가 없습니다.

개발에는 과정과 결과가 있다. 결과물은 쉽게 보여줄 수 있지만 과정을 설명하기는 어렵다. 하지만 사람들은, 특히 면접관들은 지원자가 어떻게 그 결과물을 만들었는지 알고 싶어 한다. 개발에 얼마나 시간이 소요되는지, 어떤 부분에서 막히는지, 고민을 어떤 방식으로 해결해나가는지 등을 알아야 채용을 결정할 수 있기 때문이다. 이력서나 포트폴리오 외에 이런 내용을 담을 수 있는 창구가 바로 개발 블로그이다. 그래서 이번 글에서는 개발 블로그를 운영하면 좋은 점에 대해 살펴보려고 한다.

회원가입을 하면 원하는 문장을
저장할 수 있어요!

다음

회원가입을 하면
성장에 도움이 되는 콘텐츠를
스크랩할 수 있어요!

확인

개발

개발자가 블로그를 운영하면 좋은 점

년차,
어떤 스킬
,
어떤 직무
독자들이 봤을까요?
어떤 독자들이 봤는지 궁금하다면?
로그인

 

개발에는 과정과 결과가 있다. 결과물은 쉽게 보여줄 수 있지만 과정을 설명하기는 어렵다. 하지만 사람들은, 특히 면접관들은 지원자가 어떻게 그 결과물을 만들었는지 알고 싶어 한다. 개발에 얼마나 시간이 소요되는지, 어떤 부분에서 막히는지, 고민을 어떤 방식으로 해결해나가는지 등을 알아야 채용을 결정할 수 있기 때문이다. 이력서나 포트폴리오 외에 이런 내용을 담을 수 있는 창구가 바로 개발 블로그이다. 그래서 이번 글에서는 개발 블로그를 운영하면 좋은 점에 대해 살펴보려고 한다.

 

지루하게 쓰면 안 되는 이유

이력서는 간결하게 핵심만 적는 것이 좋다. 그래야 읽기 편하기 때문이다. 반면 개발 블로그는 길어도 괜찮다. 개발과정을 기록할 때 필요하다면 여러 편을 작성해도 괜찮다. 단, 지루해서는 안 된다.

 

어떤 글이 지루한 글일까? 너무 어렵게 쓴 글이나 특색이 없는 글은 읽기에 지루하다. 만약 이 글을 읽고 “기능을 개발하느라 고민할 시간도 모자라는데 글의 재미까지 고민해야 하냐?”라고 물어본다면 단호하게 “맞다”라고 답변하겠다. ‘내가 누구이며 어떤 것을 왜 만들었는지’를 전달하려면, 일단 독자가 글을 끝까지 읽을 수 있어야 하기 때문이다.

 

그래서 개발 블로그에는 단순 ‘TIL(Today I Learnde, 그날 내가 공부한 내용을 정리한 것)’을 주로 올리는 건 지양해야 한다. 하루하루 공부한 내용은 개인 노션에 정리해도 된다. 물론 블로그에 적으면 훗날 누군가에게 도움이 될 수 있을 것이다. 하지만 공부한 내용을 정리한 것만으로는 특색을 갖기 어렵다.

 

개발 블로그에 자주 연재하면 좋은 글은 바로 서론과 본론, 결론 형식으로 구성된 ‘아티클’이다. 정보는 물론 나의 개인적인 생각에 재미를 더한다면 우연히 개발 블로그에 찾아온 독자들에게 좋은 인사이트를 제공할 것이다.

 

 

아티클이 재미있는 이유

아티클은 주제와 구성이 명확한 글이다. 개발하며 가진 고민이 곧 주제가 되고, 이를 해결하기 위해 고민하는 과정이 서론, 본론, 결론에 들어간다. 똑같은 문제를 놓고도 사람들마다 고민과 해결 방법이 다르기 때문에 글 쓴 사람의 개성이 잘 드러날 수밖에 없다.

 

명확한 주제 의식은 글의 몰입감을 높인다. 또한 해결방안에 대한 궁금증도 불러일으킬 수 있으며 독자가 글을 계속 읽고 싶게 만드는 힘이 있다. 개인 아티클 중 가장 조회수가 높은 글은 대부분 개발할 때 만난 버그를 나만의 방식으로 해결하는 과정을 담은 글이었다. 나에게 닥친 문제를 나만의 방법으로 풀어갈 때 그 이야기가 흥미로워진다.

 

개발자 블로그
(출처 : Photo by Anita Jankovic on Unsplash )

 

 

아티클 쓰기 로드맵

아티클은 긴 호흡의 글이기 때문에 계획을 잘 작성해야 중간에 길을 잃지 않는다. 그러면 어떻게 계획을 짜야 글을 잘 쓸 수 있을까?

 

우선 본인이 최근에 가장 주목하거나 집중하고 있는 기술을 주제로 선택하면 좋다. 앞으로 유행할 기술을 공부하기 전에 해당 기술을 먼저 주제로 삼고 글을 작성하면 성장에도 도움이 된다. 또는 버그를 해결하는 과정에서 탐구한 기술을 주제로 삼을 수 있다. 무엇보다 주제는 구체적일수록 좋다. 가령 ‘리액트’보다는 ‘리액트 리렌더링’이 조금 더 구체적인 글을 쓸 수 있는 주제이다.

 

주제를 골랐으면 이제 글감(글을 이루는 이야깃거리)을 정해야 한다. 역시 구체적일수록 좋다. 예를 들어 리액트는 리렌더링이 발생하는 자연스러운 조건을 4가지 정도로 설정했고, 위에서 아래 방향으로의 리렌더링을 ‘자연스러운 것’으로 간주한다. 역방향 리렌더링은 권장하지 않으며, 억지로 시도하면 경고 혹은 에러가 발생한다. 이 규칙 덕분에 앱의 예측 가능성이 커진다. 제한된 규칙 속에서 일방향적 업데이트를 통해 원하는 부분만 빠르게 업데이트하고, 의도치 않은 업데이트가 발생할 확률을 현저히 줄일 수 있다. 다시 말해, 리액트 리렌더링 기술은 앱의 성능과 예측 가능성을 동시에 높이는 장점을 가진 기술이다.

 

이제 더 근본적인 부분을 생각해봐야 한다. 앞서 말한 예시를 이어가자면, 리액트 개발팀은 자바스크립트로 돔 구조를 변경시킬 때 번번이 전체 페이지가 통째로 새로 그려지는 비효율성을 개선하기 위해 고민했다. 그 결과 ‘가상 돔’과 ‘리렌더링’이라는 기술이 만들어졌다. 변경된 가상 돔과 오리지널 돔을 비교하여 변경이 발생한 일부분만 새로 그리는 기술이다.

 

여기까지 리액트 리렌더링에 관해 알아보았다. 그런데 막상 글을 쓰려니 아직 개념이 명확하지 않다. 개념 자체가 낯선 것일까? 아니면 이를 이해하기 위해 연관된 다른 개념을 알아야 하는데 아직 모르고 있기 때문일까? 전자의 경우라면 여러 번 읽어서라도 완전히 이해한 후에 글을 쓰는 것이 좋다. 후자의 경우라면 가능한 범위 내에서 최대한 연관개념들을 샅샅이 공부한 후에 글을 쓰는 것이 글의 깊이를 더해준다. 정리가 끝났다면 이제 본격적으로 글을 쓸 시간이다.

 

시작은 제목에 문제의식을 던지면서 작성하면 좋다. ‘리액트 렌더링 사용 시 성능 최적화가 필요한 이유’, 혹은 ‘props, state 변경 없이 리렌더시킬 수 있을까’처럼, 내가 최초에 가졌던 문제의식을 제목이나 첫 문장으로 적는다. 문제의식이 잘 생각이 나지 않는다면 기술을 처음 개발한 개발자에게 감정이입을 해도 좋다. ‘리액트에는 왜 버추얼 돔이 있을까?’처럼 말이다.

 

어느 정도 글이 마무리되었으면 다음에는 독자의 입장이 되어 매끄럽게 글이 읽어질 때까지 여러 번 읽으면서 고치는 것이 좋다. 그래야 나의 개성도 살리면서 좋은 글이 완성된다. 특히 개발 글은 잘 모르는 사람이 읽어도 이해할 수 있게 쓰는 게 가장 좋다. (물론 참 어려운 일이다) 가끔 쉽게 설명하기 위해 불필요하고 추상적인 글을 덧붙이게 되는데, 이러한 설명은 어느 정도 생략해야 한다. 최소한 이 정도의 노력을 들여서 작성해야 개발 블로그에서 읽기 좋은 아티클이 완성된다.

 

 

코드 스니펫 넣기

개발 아티클에는 종종 코드 스니펫이 필요하다. 긴 설명보다 직접 코드를 보여주는 것이 쓰는 사람도, 읽는 사람도 편한 경우가 많기 때문이다. 특히 스니펫을 넣을 때 이해를 돕기 위한 예시라면 일정 부분 생략해서 너무 길지 않게 작성하는 것을 추천한다.

 

최근 들어 좋은 블로그 플랫폼들이 많이 생기면서 개발자들을 위한 코드 스니펫 기능을 제공한다. 만약 본인이 사용하는 플랫폼에 코드 스니펫 기능이 없으면 ‘깃허브 지스트’를 이용하면 좋다. 작성한 지스트(짧은 코드)를 링크로 심을 수 있고, 미리보기 기능이 제공되는 경우 링크 하단에 깔끔한 코드 스니펫이 나타난다.

 

깃허브 코드 스니펫
(출처: 본인)

 

 

개발 블로그 지속해서 운영하기

위에서 설명한 방식으로 아티클을 쓰려면 많은 시간이 든다. 경험담인데, 하나의 아티클을 쓰기 위해 일주일 이상이 걸린 적도 있다. 이렇게 많은 시간이 드는 이유는 끊임없이 ‘왜’ ‘어떻게’에 대해 생각하기 때문이다. 어떤 기술을 선택하고 사용법을 판단하고 코드를 작성하는 과정은 순식간에 이루어진다. 하지만 이 과정을 복기하면서 글로 쓰려고 하면 일일이 생각의 고리를 역으로 추적해야 하므로 시간이 오래 걸린다. 내가 했던 생각들을 천천히 따라가다 보면, 습관처럼 넘어갔던 지식에 대해 더 정확하게 알 수 있기도 하다.

 

하지만 하나의 아티클을 쓸 때 이렇게 시간이 오래 걸리면 포스팅 주기가 길어지는 단점이 생긴다. 그러면 블로그를 지속하기가 어렵다. 그래서 TIL과 아티클을 번갈아 작성하는 것도 좋은 방법이다. 짧은 주기로 TIL을 올리고, 이 중 하나를 주제로 삼아 긴 호흡의 아티클을 작성하는 방식도 있다. 이렇게 하면 글들 사이에 연속성이 생기고, 같은 주제를 여러 번 공부하는 복습의 효과도 얻을 수 있다.

 

TIL을 쓸 때 아예 아티클을 염두에 두고 여러 가지 의문을 제기하는 것도 좋다. 예를 들어 본문 아래쪽에 TMI란을 만들고, 공부하면서 생긴 호기심을 모두 쏟아내 보자. 호기심을 혼자 삼키지 말고 이렇게 잘 보이는 곳에 적어 두면, 나중에 본인의 TIL을 읽었을 때 주제에 대해 다시 궁금해져서 공부하고 싶은 마음이 들 때가 있다. 바로 이 순간이 아티클을 작성하기 좋은 타이밍이다.

 

 

개발자라면, 블로그를 통해 성장하자

개발 블로그는 지속적인 성장의 원동력이 되어준다. 오랜만에 예전에 썼던 글을 읽으면 때로는 그때보다 성장했다는 뿌듯함을 느끼기도 하고, 때로는 오히려 그때 알던 것을 잊어버린 것 같은 위기의식을 느끼기도 한다. 어느 쪽이든 확실한 동기부여가 되고 슬럼프에 빠지지 않게 도와준다.

 

개발 블로그의 장점은 하나 더 있다. 그건 바로 책임감이 생기는 것이다. 잘못 알고 올린 정보 하나가 독자에게 잘못된 정보를 줄 수 있기 때문에 블로그에 글을 올릴 때는 책임감이 필요하다. 독자에게 설명하기 위해 여러 번 찾아보고 잘못된 정보가 아닌지 끊임없이 확인하는 일은 필수이다.

 

아티클은 남에게 보여주기 위한 글이기 이전에, 성장을 위한 복기의 글이다. 개발한 내용을 하나의 완결된 아티클로 적는 경험은 관련 지식을 머릿속에 명확하게 정리해주고, 기억에 오래 남게 해준다. 나의 성장을 위한 글이므로 솔직해도 된다. 어쩌면 아무도 안 읽을 수도 있으니 부끄러워하지 않고, 자신의 고민과 실수를 가감 없이 작성해도 된다. 결국엔 유일한 독자인 나에게 도움이 되는 일이 될 것이다.

 

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.

좋아요

댓글

공유

공유

댓글 0
프론트엔드 엔지니어
137
명 알림 받는 중

작가 홈

프론트엔드 엔지니어
137
명 알림 받는 중
2년차 프론트엔드 개발자입니다. 리액트와 자바스크립트를 좋아합니다.

좋아요

댓글

스크랩

공유

공유

지금 회원가입하고,
요즘IT가 PICK한 뉴스레터를 받아보세요!

회원가입하기
요즘IT의 멤버가 되어주세요! 요즘IT의 멤버가 되어주세요!
요즘IT의 멤버가 되어주세요!
모든 콘텐츠를 편하게 보고 스크랩해요.
모든 콘텐츠를 편하게 보고 스크랩 하기
매주 PICK한 콘텐츠를 뉴스레터로 받아요.
매주 PICK한 콘텐츠를 뉴스레터로 받기
로그인하고 무료로 사용하기