블로그를 왜 직접 만들었나

그럴 생각 없었는데

원래 블로그를 만들 생각은 없었고, 사이드 프로젝트를 가다듬으려고 했었다.
기존 코드를 개선하고 싶었고 그 과정을 일지로 남기고 싶었다.
(그래도 나름 포트폴리오인데 코드를 어디 내놓기 부끄러워서...)

당연히 기록 매체가 필요해졌고 후보는 SNS와 티스토리였다.

SNS
장점이라면 내 일지가 공유될 가능성이 있어서 자연스레 홍보될 수 있다는 점?
단점은 눈 돌아갈 요소들이 너무 많았다. 개발과 전혀 상관없는 피드가 뜨기도 하고.
특히 관심있던 개발자분들의 트윗을 보면 집중해야 할 기술이 아니라 다른 기술에 정신이 뺏길 것 같기도 했고.
나중에 봐야지~ 해놓고 탭이 증식될 게 눈이 뻔히 보였다.
티스토리
예~~전에 만들어뒀던 티스토리가 있긴 했다.
기록과 그 습관을 들이는 게 중요했고 지체없이 시작하려면 이미 잘 갖춰진 곳을 이용하는 게 아무래도 더 수월해보였다.
그래서 티스토리로 결정되나 싶었는데...

결정을 바꿔먹게 한 몇 가지 이유가 생겨버렸다.

나... 어디가서 웹 프론트 쫌 한다고 말하고 싶어... 근데...

내가 웹 개발을 잘 한다고 말할 수 있을까?

현대의 웹 프론트엔드는 정말이지 복잡하다. 그래서인지 '웹 개발 할 수 있어요'와 '웹 개발 잘 해요'의 간극이 큰데,
'개발자가 제품의 어느 영역까지 커버하는가' 에서 그 간극이 발생한다고 본다.
스스로 느끼는, 책임져야할 영역이 기능 구현을 넘어 제품 전반이 될 때 간극은 좁혀진다.

예를 들어, SSR(Server Side Rendering)과 SEO(Search Engine Optimization) 작업은 기능 구현과 거리가 있다.
기능 구현보다 더 중요한 작업인가? 물으면 그건 결코 아니다.
하지만 제품을 둘러싼 비즈니스 영역에서 보면 얘기는 크게 달라진다.
SSR과 SEO는 개발자가 전문적인 마케팅 도구를 이용하지 않고도 제품의 인지도를 높일 수 있는 수단이다.
기능을 만들어내는 개발이 아닌 제품의 성공을 위한 개발이라면 기능 구현만큼이나 중요한 작업이라고 볼 수 있다.

[제품 생명주기 그래프] 도입기(introduction)의 제품은 인지도를 높이는 작업이 필수적이다.

마찬가지로 제품의 성공에 영향을 미치는 또 다른 작업은 최적화다.
번들 사이즈 줄이기, 이미지 최적화, 네트워크 상황 고려하기, 렌더링 속도 높이기 등등의 요소들이 있는데
그저 기능하는 게 중요한 상황이라면 용량이 조금 크고 속도가 조금 느린 건 문제되지 않는다.
하지만 해당 요소가 사용자의 불편을 초래하고 이탈까지 유발한다면 그때부턴 큰 문제가 된다.

물론 사용자가 성능 문제를 덜 느끼게끔, 심지어는 못 느끼게끔하는 마법사같은 디자이너분들의 도움을 받을 수도 있다.
그런데 그건 그분들이 대단하신 거고, 기본적인 성능 문제의 원인과 책임은 개발자에게 있다.
결국 다른 어떤 것보다 내가 작성한 코드가 느려서 사용자가 떠난 거니까.

최적화되지 않은 요소들은 사업 비용 부담으로 이어지기도 한다.
배포/운영 환경을 구성하는 데 드는 비용은 오로지 개발자의 책임이고, 이를 줄일 수 있는 것도 개발자뿐이다.

이처럼 기능을 감싸고 있는 비즈니스 전반의 모습을 볼 수 있어야 '제품 개발자'로 불릴 수 있다고 본다.
사업 비용, 협업 비용, 비즈니스 복잡도 등을 낮췄을 때 제품 기술자(Product Engineer)로 불릴만 한 것 같고.

난 지난 창업을 통해 이런 요소들을 체감했지만 아직 숙달되진 않았다.
일부 기술만 적용해봤거나 적용했더라도 누군가에게 잘 설명할 순 없었다.
변명하자면 저번 팀에선 개발자이면서 프로덕트 오너였고 동시에 서비스 기획자였기 때문인데,
새로운 팀에선 명확히 기술자(Engineer) 포지션으로 임해야 하기에 이젠 써먹을 수 없는 변명이다.

그래서 상대적으로 약했던 웹 프론트엔드 분야도 '잘' 하고 싶다는 의식이 더더욱 강하게 자리 잡았고,
어디가서 '저 웹 프론트도 좀 한다' 고 당당히 말하고 싶었다.

이럴거면 블로그도 직접 만들어서 여러 요소들을 직접 헤쳐나가보는 편이 나아보였다.

Next.js를 '제대로' 써먹어봤나?

현재 Next.js는 시장에서 가장 잘 쓰이고 있는 프레임워크 중 하나다.
쪼~끔 과장하면 지배적이라고까지 말할 수 있지 않을까?
내 가치가 시장에서도 먹히려면 Gatsby나 Jekyll보다 Next.js가 낫겠다고 판단했다.
내가 학습한 기술이 시장에서 원하는 기술이기까지 한다면 더할 나위가 없으니까!
(한땀한땀 만들어나가고 싶기도 했고.)

게다가 그동안 Next.js를 '제대로' 써먹어봤다고 보긴 어려웠고, 큰 변화가 생겼던 Next.js 13과 React 18에 대해서 아는 게 거의 없었다.
뭐가 바뀌었는지는 여러 포스트를 통해 확인했지만 해당 버전에서 코드를 작성해본 적이 한 번도 없었어서 아는 게 없다봐도 무방했다.

지금 React 17과 Next 12는 레거시는 커녕 현역이지만, 기왕 신규 프로젝트를 시작하는 김에 새로운 버전을 도입하고 싶었다.
앞으론 이 버전이 스탠다드가 될 테고, 무엇보다 실제 제품 개발에 앞서 연습장 삼아 써볼 프로젝트도 필요했다.

직접 만들면 그래도 더 손이 가지 않을까

블로그를 만드는 것보다 더 중요한 건 습관을 들이는 일이다.
만들고서 안 쓰면 의미가 없으니까 ㅠㅠ;

난 한결같이 꾸준히 기록하는 일에 약했다.
기록하는 건 좋아하면서도 그걸 꾸준하게 하는 건 참 어려웠다.

손이 탄 곳에 손이 간다고 믿는다.
그래서 이런 이유들로 2가지 목표를 갖게 됐다.

Next.js 13으로 웹 프론트엔드 전반에 능숙해지자!
기록하는 습관을 들여보자!

프로젝트를 설정하면서 고려했던 건 2가지였다.

고려사항

스타일링

원래는 emotion을 사용할 생각이었다. 지난 프로젝트에서 대시보드 만들 때 정말 유용했던 MUI가 emotion을 쓰기도 하니
이참에 styled-components가 아니라 emotion으로 시작해보려 했는데, 이런 문제들이 있더라.

그래서 tailwindcss를 써보기로 했다. tailwindcss는 워낙 익히 들어왔고, 공식 문서에서 권장하는 라이브러리이기도 하다.
스타일링이 블로그 제작에 있어 아주 중요한 고려요건은 아니어서 추후 css-in-js 논의점을 더 살펴보고 바꾸든지 할 생각이다.

근데 tailwindcss 정말 편하고 직관적이더라. 문서 몇 번 보지도 않았고 심지어는 안 보고도 추측해서 쓸 수 있었다.