기술 블로그를 시작하게 된 이유
포스트
취소

기술 블로그를 시작하게 된 이유

누구세요?

안녕하세요? 프론트엔드 개발자 박찬영입니다.
특성화 고등학교를 졸업한 이후 대학도 열심히 다니고 회사 일도 열심히 하면서 살아가는 평범한 개발자입니다.

블로그를 개설한 이유

저는 벌써 약 3년 6개월의 경력을 갖게 되었습니다. 4년차인거죠.

나름 회사에서 인정도 받으며 커리어를 쌓고 있으니 한참 자신감이 뿜뿜하던 2021년. 개발 과정에서 직면한 이슈를 수정하기 위해 짧은 영어 실력을 굴려가며 구글에 검색을 하고 있었습니다.
요즘은 영어만 사용하여 검색을 해도 양질의 한국어 자료가 많이 나오는걸 보면서 “내가 사용하고 있는 언어의 생태계와 한국 개발자 생태계가 예전과는 다르게 급성장 하는구나!”와 같은 감상을 늘어놓음과 동시에 국내 메이저 기업들의 기술 블로그에 당도하게 되었습니다.
메이저 기업에 다니는 훌륭한 개발자가 작성한 문서는 이슈를 해결함과 동시에 저의 지식을 채워주는 양분이 되었습니다.
저였다면 아무런 생각 없이 진행하는 패키지 설치 과정에서마저 불편함을 느끼고 방법을 개선하는 개발자들의 탐구력과 통찰력에 감탄하고 있던 와중 해당 게시글을 작성했던 개발자의 정보가 눈에 들어왔습니다.

“이제 막 개발 업계에 들어온지 1년 된 프론트엔드 개발자입니다!”

자괴감

저는 이 짧막한 자기 소개를 보고는 자괴감이 들기 시작했습니다.

“나는 여태까지 뭘 한거지?”

“나는 사실 프로그래밍을 못하는 편인가?”

“나는 나름 프로그래밍을 잘한다고 생각했는데… 요즘은 저정도 실력이 평균인건가?”

위와 같은 자학적인 생각들이 머리속을 지배하게 되었고, 저의 과거를 곱씹어 보았습니다.

프로그래밍 경진대회 수상, 대학교에서 교수님들께 들었던 수많은 칭찬, 스타트업 입사 2년만에 엔지니어링 매니저로서 개발팀을 지도했던 경험 등 모든게 완벽한 커리어였다고 생각했는데 알고보니 이 모든 것들은 기술자로서의 개발 능력과 친화력 높은 성격만을 인정 받은게 아닌가 라는 생각이 들기 시작했습니다.
제가 되고 싶었던 훌륭한 소프트웨어 연구자의 관점으로서 저를 돌아본다면 내 주변에 상주하는 일상적인 불편함을 해소시켜 본 경험도, 퍼포먼스를 개선시켰지만 이를 얼마나 개선 시켰는지 수치화를 해봤던 경험도, 나의 개발 방식이 어떤 원리로 동작하는 지에 대한 탐구도 전혀 하지 않았다는 것을 알게 되었습니다.
내가 바랐던건 많은 사람들의 멘토가 되는 개발자였고 나름 그 길에 가까워졌다고 생각했는데 알고보니 단순히 요령만 좋았던 기술자 그 이상 그 이하도 아니였던 것입니다.

기록을 시작하게 된 계기

그러던 와중, 과거 우아한형제들의 리드 개발자, 현 인프런 개발자인 Jojoldu선배님의 인터뷰 영상을 보게 되었습니다.
"제 블로그의 타이틀이 저를 나타내는 가장 좋은 말인 것 같아요" "'기억보단 기록을' 이라는 주제인데요."
"어떻게 보면 개발자의 커리어를 쌓아오면서"
"되게 관통하는 주제였던 것 같아요."
"저의 머릿속에 있는 내용들, 혹은 남들에게 말했던 내용들이"
"결국 기록하지 않으면 흐트러지더라구요"
인터뷰 영상을 보면 평범한 어투로 말씀하시는 이 내용들이 제 마음 어딘가에 있던 핵심을 찌르는 듯한 느낌을 받았습니다.

되돌아본 나의 문제점

  1. 돌이켜보면 나름 배운 것도 많고 아는 것도 많은데 이를 어디에도 기록하지 않아 나의 실력을 증명할 수 있는건 나의 입 말고는 없다는 것
  2. 예전에 분명 해결했었던 이슈인데도 동일한 이슈를 다시 접했을 때 해결 방법이 기억이 나지 않아 구글링을 하던 적도 있었다는 것
  3. 기술 면접 때, 어떤 용어에 대한 질문을 듣고 그게 뭔지 한참 생각했던 적이 있는데 나중에 조사해보니 “아 이게 그 뜻이였어?” 라고 생각했던 상황이 정말 많았다는 것

이 모든것을 한번에 해결할 수 있는 방법은 역시 기록이다. 라고 생각하게 되었습니다.

기록의 시작

TIL

문제점을 찾은 저는 4년차 개발자가 되어서야 남들 다 하는 TIL을 시작하게 되었습니다.
TIL을 하다보니 제가 겪었던 대부분의 이슈, 이벤트 등을 지칭하는 용어들이 이미 있다는 사실을 알게 되었고, 동료 개발자들끼리 대화할 때 일부 용어를 못알아 듣는 상황이 현저히 적어졌습니다.

1일 1커밋?

1일 1커밋
1일 1커밋을 목표로 잡고 기록을 시작한지 5개월 째 되었습니다.
중간 중간 친구들과 너무 즐겁게 노는 나머지 커밋 하는 것을 잊어버려서 구멍이 많이 뚫려있지만 그래도 하루 하루 초록색이 쌓여가는 모습이 보기 좋은 Contributions을 얻게 되었습니다.

기록만 해놓으면 뭐하냐

그렇게 기록이 주는 재미의 맛을 알게 될 때 쯤, Vue 생태계에 발을 들이시려는 우리 회사 퍼블리셔분으로 부터 Nuxt 세팅 방법에 대해 질문을 받았습니다.
초기 세팅 방식은 조금 복잡해서 과거 TIL을 정리할 때 기록해 두었던 사항이라 “드디어 나의 기록을 활용할 기회인 것인가?!” 라고 생각하고 정리해뒀던 문서를 건네드렸습니다.
그러자 조금 뒤에 그 분으로부터 답장을 받게 되었습니다.

“여기서 뭐 눌러야 돼요?”

그 질문을 받은 저는 “문서에 분명 상세히 적혀있는데 왜 다시 여쭤보실까?” 라고 생각하며 제 문서를 다시 읽어보았습니다.
그러자 한숨이 절로 나왔습니다.
어차피 저만 읽어볼 것을 상정하고 만든 문서라서 가독성은 말할 것도 없었고, 세부 선택 사항들은 이미 내가 알고 있다는 것을 전제로 적은 문서였기 때문에 디테일한 내용들이 누락 되거나 일부는 아예 기록조차 하지 않았다는 것을 알게 되었습니다.

애초에 “나만 볼 것”을 전제로 만든 나만의 필기노트 같은 느낌으로 작성했던 부분이라서 다른 사람은 이해할 수가 없을정도로 처참한 결과물이 나온 것입니다.
이 일을 계기로 나만 보기 위해서 적는 것이 아닌, 내가 겪었던 문제를 겪는 다른 개발자들을 위한 문서를 적는다는 생각으로 작성하는 방향으로 노선을 바꾸게 되었습니다.

기술 블로그 시작

그런데 “내 Github에만 문서를 잘 정리해놓으면 그걸 누가 보긴 할까?” 라는 가장 원초적인 질문이 제 머리속을 지나갔습니다.
애초에 Github의 README.md 뷰어는 그다지 읽고싶게 생기지도 않았다는 추가적인 이슈는 덤이구요.
곰곰히 생각해본 결과, “개인 블로그에 글을 써보는건 어떨까?” 라는 생각이 들었습니다.

사실 기술 블로그를 시작하는게 처음은 아닙니다. 고등학생 때 그냥 남들 다 하길래 따라서 시작해본, 영양가 없는 문서들이 몇 달 간격으로 하나씩 올라오는 거의 버려진 블로그가 있던 상태였습니다.
처음에는 이 블로그를 어떻게 좀 살려보자는 생각으로 글을 쓰기 시작했는데, 일반적인 글 작가분들께 특화 된 에디터와 뷰어 때문에 코드를 작성하기에 썩 좋은 선택지가 아님을 알게되어 현재의 Github Pages 블로그로 갈아타게 된 것입니다.

그렇게 현재까지

좀 더 꾸준하고 퀄리티있는 문서들로 TIL을 채우면서 저의 귀차니즘 해결과 전문 지식 습득이라는 두마리의 토끼를 열심히 잡고 있습니다.
덤으로, 제 주변에 상주하는 불편함을 발견하는 통찰력을 기르기 위해서 세상 모든 일에 대해 왜? 라는 질문을 던지기 시작했습니다.

  • 담배에는 니코틴만 넣으면 몸에도 해롭지 않은 좋은 담배가 나올텐데 왜 타르같은걸 넣는거지?
  • 사거리 횡단보도가 켜지는 알고리즘은 뭘까?
  • 지하철이 스크린도어에 딱 맞게 멈출 수 있는 원리는 뭘까?

위와 같이 정말 별것도 아닌 것 같은 일에 대해 호기심을 갖고 탐구하는 습관을 가지려고 노력중입니다.
누가 보면 미친것 같다고 할 수도 있지만 원래 어떤 분야든 한 구석이 미친 사람만이 미친듯한 성과도 낼 수 있다고 생각하거든요!
다른 사람이 저를 보고는 “쟤는 좀 미친 것 같은데 일은 잘해” 라고 말하게 되는게 제 단기적인 목표입니다.

마치며

즉흥적으로 끄적인 글이라 문장 구성에 미흡함이 느껴질 수도 있습니다.
그 때 당시에 느꼈던 복잡했던 심리를 그대로 살려 작성한 글이라서 상당히 감정이 많이 실려있다고 느끼실 수도 있습니다.
하지만 이런 감정이 담긴 글을 기재함으로서 블로그에 애착을 갖게 되고, 오랜 활동으로 이어질 수 있는 원동력이 되지 않을까 싶어 이렇게 작성해봅니다.

두서 없는 글 읽어주셔서 감사합니다!

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

[React Native] StyleSheet.create vs Plain Object

React Native Calendars를 통해 오픈소스를 파헤쳐보자