<div id="readability-page-1" class="page"><time>2023-07-16 에 작성하고, 2023-07-16 14:44:33 에 업데이트한 문서입니다. ✅</time> — <a href="/tags/postmortem">Postmortem</a> — 3 min read<section>매 2주의 끝무렵마다 급하게 개인 노트북을 편다. 집중용도의 헤드폰을 귀에 끼우고 끼우고 일주일 정도 머리에 굴리고 있던 것들을 막 쏟아내기 시작한다. 글감과 공부하고 싶은 마음은 아주 작은 불꽃같아서, 즉시 자리를 잡고 키우지않으면 사그라들어버린다. 시간이 넉넉할 때는 최대한 상세한 그림 설명을 덧붙여서 미래의 나를 향해 지식을 마구 던진다. 17년부터 쌓아왔던 글들이 약 152 개를 돌파했다. 가벼운 글도 버려진 글도 있다. 대체로 뭔가의 표면을 다 쓸어보는 (?) 것을 좋아해서 넓고 얇게 훑는 글들이 대부분이다. 많은 글이 ~ basics 혹은 101 으로 끝나는 것도 그런 것에서 비롯했다. 기술 블로그를 열심히 관리하고 하시는 분들에 비하면 미미한 양이지만 그렇다고 결코 적은 양도 아니다. 글을 쓰는 것, 또 기술 글쓰기를 하는 것은 지리한 작업이다. 간단하게 침대에 누워서 유튜브를 틀고 영상물을 틀면 간단하게 내 도파민이 분비되면서 즐거움을 맛볼 수 있는데, 고통 속에서 공부와 검증을 통해 한 편의 글을 발행하고 그 글이 어떤 독자에게도 닿지 못하는 경우도 있으니 여가를 보낸다는 차원에서는 비효율적이기도하다. 시간을 들여 만들어낸 이미지가 아무렇지도 않게 어떤 블로그에서 쓰이는 것을 볼 때는 또한 기분이 이상하기도 하다. 해당 이미지를 사용하지 말아주세요, 하고 댓글에 남기면서도 나는 남의 것을 기워서 글을 쓰지 않았나 검열을 하기도 한다. 그럼 그게 무엇이 다른거지! 그럼에도 불구하고 기술 글쓰기를 한다. 직업인으로서 따로 글을 쓰고 공유하는 문화가 있다는 것은 사실은 좀 이상한 일이라고 생각한다. 그것도 서로의 이야기를 엄청나게 많이 참고하고 본다는 것은. 어쩌다 이런 문화의 직업인으로 폭 떨어져버린걸까? 그런 문화를 지탱해주는 커뮤니티도 있다. 이번에도 참가한 글또다. 2020년에 <a href="https://juneyr.dev/retrospective-geultto-4">글또 4기에 참가한 바</a> 있는데, 23년에도 참가하게 되었다. 왜였을까? 혼자 글을 쓰는건 엄청난 열정과 폭발적인 인풋 받아들이기가 있어야한다. 실제로 1년차의 나는 계속해서 지식을 받아들였고 이를 정리하고 내보낼 곳이 많이 필요했다. 그때는 아무도 밀어주지 않아도 계속 앞으로 나갔고, 이런 시기가 영원할 줄 알아버렸지! 모르는 것이 너무 많으니까 계속해서 공부하지 않으면 안됐다. 시간이 지나고 삶의 괴로움이 앞으로 나갈 때의 마찰이 줄면 내 원동력도 줄어버린다. 그 때 커뮤니티가 등장한다. 처음 참여했을 때도 딱 그런 시점이었다. 글또 4기에 참가하면서 9개 정도의 글을 썼고 지금 봐도 아직 쓰고 있는 기술들과 지식이다. 그런 경험이 좋았어서 이번에도 같은 걸 기대하면서 신청했다. <h3 id="8기에-쓴-글"><a href="#8%EA%B8%B0%EC%97%90-%EC%93%B4-%EA%B8%80" aria-label="8기에 쓴 글 permalink"></a>8기에 쓴 글</h3><ul><li><a href="https://juneyr.dev/gslb-and-dns">GSLB 는 LB 가 아니라 사실 DNS ver.2래..</a><ul><li>GSLB 와 이제는 꽤 친해지게 되었지만, 너무 혼란스러워서 썼던 글. 기술 글쓰기를 하면 아직도 이런 것도 모르는 자신에 놀라게 된다. </li></ul></li><li><a href="https://juneyr.dev/jvm-basics">JVM 과 그 메모리</a><ul><li>JVM 에 대해서 모르면 GC 도 모르고.. 왜 터지는지 알수가 없다. 한번 주르륵 정리하고 나니까 큰 도움이 되었던 글쓰기. </li></ul></li><li><a href="https://juneyr.dev/jvm-gc">GC 알고리즘 + JVM 이 채택한 GC 취사선택해서 알아보기😋</a><ul><li>jar / war 패키징 해서 띄울 때 꼭 GC 알고리즘을 선택해서 띄우는 스크립트가 있는데, 그에 대한 지식도 없기때문에 쓴 글.</li></ul></li><li><a href="https://juneyr.dev/make-backend-in-10days">10일안에 협업하는 최소의 웹 백엔드 만들기</a><ul><li>자신감이 떨어질때는 처음부터 끝까지 한번 만들어 보면 좋다 - 비사이드에서 진행하는 포텐데이를 참여해서 FE 와 협업하는 백엔드를 만든 글. 작은 admin 까지 만들었고 데브옵스도, 실제 어플리케이션 올리는 일도 했는데 너무 재밌었다! </li></ul></li><li><a href="https://juneyr.dev/quick-cassandra">Cassandra DB 간단하게 알아보기</a><ul><li>건너 건너의 협업 부서가 사용하고 있다는 DB에 대해서 알아본 글. 실제로 딥하게 사용해보지는 못해서 궁금했는데, 이게 어떻다 정도만 알 수 있어도 나중에 큰 도움이 된다고 생각한다. </li></ul></li><li><a href="https://juneyr.dev/http-series">HTTP 1-2-3 + HTTPS</a><ul><li>웹 어플리케이션 서비스를 제공하고 있으면서 http 를 잘 모르면 꽤 ... 괴롭다 (?) 스터디에서 나온 겸해서 한바닥 정리하고, 스터디로 다시 들었더니 머릿속에 좀더 잘 박혀서 좋았다. </li></ul></li><li><a href="https://juneyr.dev/image-basics">컴퓨터에서의 이미지로 하겠습니다, 이제 웹 최적화를 솔솔 뿌린</a><ul><li>웹 최적화 스터디를 하다보니 계속 마음에 가는 주제 중 하나. 이미지 ! 이미지가 어떻게 컴퓨터에 저장되고 어떤 형식을 가졌고 최적화를 위해서는 어떻게 해야하는지 까지 정리해봤다. </li></ul></li><li><a href="https://juneyr.dev/unique-id">유일한 ID 생성기 설계 by 가상면접사례로 보는 시스템 설계 기초</a><ul><li>이 글을 위해 공부하면서 첫 프로젝트에서 했던 복잡한 ID 생성기가 많이 생각 났다. 그것도 데이터 센터와 현재 시간을 기반으로 한 ID를 생성했었는데 지금 보니까 그게 snowflake 방식을 채택한 방식이었음. id 자체가 타임스탬프가 된다는건 엄청 유리하고 개발에 편리하다. 언젠간 꼭..! </li></ul></li><li><a href="https://juneyr.dev/rate-limit-algorithm">트위터가 볼 수 있는 트윗수를 제한한다고? rate-limit</a><ul><li>점점 설계에 대한 이야기를 많이 하게 되는 것 같은데, rate-limit 는 아주 중요한 컴포넌트중 하나다. 마침 트위터가 볼 수 있는 트윗수를 제한하는 정책을 펴면서 재밌게 쓸 수 있었다. </li></ul></li></ul><h3 id="그래도-좋아하는-건"><a href="#%EA%B7%B8%EB%9E%98%EB%8F%84-%EC%A2%8B%EC%95%84%ED%95%98%EB%8A%94-%EA%B1%B4" aria-label="그래도 좋아하는 건 permalink"></a>그래도 좋아하는 건</h3>나의 기술 글쓰기는 크게 두가지로 나뉜다. 1) 개념을 알고 구현을 해보기 위해 공부하는 경우 2) 구현체를 보고 이게 뭐지 싶어 개념을 알아보는 경우.2)와 같은게 ID 생성기와 rate-limit 다. 일을 하면서 오히려 구현체를 먼저 접하고 개념을 나중에 배우는 경우, 훨씬 이해하기가 좋다. 오히려 이번에는 1)이 적었다고 해야하나. cassandra 를 제외하고는 이미 쓰고 있는 기술에 대한 보충 이해를 위해서 적은 글이었다. 초반에 계속 1번 스타일의 글이 많았던 것 과는 대조되는 부분이다. 여기서 기술 글쓰기의 즐거움이 나온다. 기술 글쓰기는 그 자체로 내가 걸어온 길의 역사가 된다. 업무일지는 원할 때 한눈에 읽어볼 수는 없는데 반해, 블로그는 제목과 시간을 훑어보는 것만으로도 당시에 했던 업무와 관련있던 기술이 모두 떠오른다. 기술글쓰기를 하는 것 자체가 나의 외장하드로서의 뇌를 만드는 일이라, 당연히 옛날 글에 도움도 많이 받는다. 거기에 과거의 글을 속독으로도 빠르게 이해하는 자신을 보면서 성장감을 느끼기도 하고!문서를 작성하는 능력도 아마 크게 성장했으리라 생각한다. 150개, 여기저기 산재했던 구 블로그들을 합치면 한 180여개 되지 않을까. 학창시절에 쓰라고 했던 글들을 모두 합쳐도 이정도는 안되지 싶다. 다량의 글을 꾸준한 템포로 써오면서, 기술 블로그를 쓰지 않은 멀티버스의 준영보다는 훨씬 잘하게 됐을 터다. 기술블로그를 개발 + 운영하는 점도 재미 중 하나다. 가독성을 늘리기 위해서 css 를 그렇게도 건드렸다. 배포 플랫폼을 바꿔보고 gatsby 로 전환하고 ... 잘 모르는 리액트 컴포넌트를 건드려가면서 개선해봤다. utterance 에서 giscus 로 옮겨봤고, ga 를 최근엔 ga4 로 이전했다. 블로그에 광고 붙이면서 google ad 도 써봤고. 내가 개발자이자 기획자이자 마케터가 될 수 있는 그 자체의 사이드 프로젝트인 셈이다. 무엇보다 나는 내 글을 다시 읽어보는 걸 너무 좋아한다. 바보같은 표현도, 지나치게 수사적이여서 이해하기 어려운 표현도 그때의 그대로 받아들이는 걸 좋아한다. 기술글쓰기의 특성 상 아주 정보적인 글이면서도 쉽게 설명하려고 하는 노력의 글쓰기를 좋아한다.그러니까 나는 앞으로도 기술 글쓰기를 할 것 같다. 매번 머리를 쥐어짜며 마감 직전에 초인적인 힘으로 써내는 일이 참 괴롭더라도, 계속 글을 써낼 것 같다. 재미없는 정보가 나를 거쳐 재밌어지길 바라면서. 내 꿈은 소스가 참 맛있지만 알고보니 고기도 고품질인 제육볶음 글을 뽑아내는 사람이다. (ㅋㅋ) </section></div>

기술글쓰기와 복잡한 관계입니다

댓글