왜 만들었는가

기존에 velog를 잘 쓰고 있었지만 직접 만들어 보고 싶었다. 블로그를 만들고 유지보수하면 많은 공부가 될 것 같았다. 앞으로 10년은 작문하고 코딩하지 않을까? 이런 생각이 들자 블로그는 내게 최고의 사이드 프로젝트 소재가 되었다.

삽질 좀 거하게 해 봤습니다

이 블로그는 Next.js를 이용해서 만들었다. 따로 백엔드를 두지 않고 Next.js의 API Routes기능을 활용했다. MongoDB Atlas와 통신하며 필요한 데이터를 가져오고 이미지는 CloudFlare images를 통해 관리되고 있다. 배포는 Vercel을 통해 이루어진다.

위 아키텍처에 만족하고 있지만, 초기에는 완전히 다른 구조의 블로그를 구상했었다.

프로젝트 말미에 구조를 갈아엎어야만 했다

처음에는 이 블로그를 내 모든 개발적 궁금증을 해소하고 다양한 기능구현을 실현하는 올인원 프로젝트로 여겼다. 10년은 쓸 거니깐, 아무런 제약이 없고 A-Z까지 내가 다 직접 설정하며 규모를 점차 확장시켜갈 수 있는 구조를 원했다. 그렇게 Next.js와 Express 두 개의 서버를 두기로 결정했다. 그때도 API routes를 이용해서 Next.js를 풀스택 프레임워크로 활용하는 방법은 얼핏 들었지만, 좀 더 본격적으로 하고 싶었다. '본격적인 서비스라면 프론트와 백을 따로 둬야지.' 이런 생각이었던 것 같다. API Routes에는 추후 확장에 있어 많은 제약이 따를 것 같았다. 대충 AWS 인프라를 활용하면 배포도 문제가 없을 것 같았다.

그렇게 열심히 개발에 착수했다. Material design3의 문서가 너무도 잘 작성되어 있어서 이를 참고하며 디자인 시스템 비슷한 걸 구축했고, MVC 패턴을 적용한 Express에 미들웨어를 이용한 우아한 에러처리 Error Handling in NodeJS (Complete Guide) | Node Tutorial 기법을 적용하며 일이 잘 풀려가는 것 같았다. '와, 백엔드는 폴더 구조부터가 정석으로 확립되어 있네' 하면서 즐거워하곤 했다.

어느 정도 개발이 완료되자 배포환경에서도 잘 구동되는지 확인하고 싶어졌다. 그렇게 배포 방법을 찾아 보며 고민하다가, 결국은 프로젝트를 지금의 구조로 싹 다 갈아엎었다. 안일하게 계획한 과거의 나를 원망하며, 눈물을 훔치고..

AWS 요금을 감당할 수가 없었다. 프리티어의 EC2에서는 Next를 빌드하면 자꾸 뻗었다. 그제서야 다른 사람들은 블로그를 어떻게 배포했는지 찾아봤다. 다들 정적 페이지로 간소하게 배포하는데, 나는 왜 이런 구조를 설계했지? 확장성에 눈이 멀어 본질을 망각했다. 블로그에는 블로그에 맞는 설계가 있을진대 개발하는 동안 그런 건 안중에도 없었다. 그냥 내가 써보고 싶은 라이브러리/프레임워크를 덕지덕지 붙이기에 바빴다. 주객을 전도했다.

There Is No Silver Bullet

차근차근 하나씩 뜯어고쳤다. No Silver Bulltet이라는 격언이 자꾸만 생각났다. 시간을 들여 잘 설계하기만 하면 모든 상황에 대응할 수 있는 완벽한 소프트웨어를 만들 수 있으리라 단단히 착각했다. 리비아의 게롤트도 은검과 강철검이라는 최소한의 선택지를 두고 이를 적재적소에 활용하는데.. 나는 칼 한 자루만 쥐고선 그마저도 엉뚱한 곳에 휘둘렀다. 닭 잡는 데 소 잡는 칼을 썼다.

블로그에는 블로그에 적합한 기술을 활용한다. 그리고 다른 기술을 공부해 보고 싶으면 새로운 구조로 또 다른 사이드 프로젝트를 진행하면 된다. 지금의 블로그는 CSS-IN-JS 구조인데, 어느 날 CSS-IN-CSS를 적용해 보고 싶다고 위 구조를 다 뜯어고칠 필요는 없다. 그냥 Atomic 패턴의 새로운 사이드 프로젝트를 진행해보면 될 일이었다. 이렇게 간단한 생각을 그땐 왜 못했을까. 나는 무언가에 그렇게 홀렸나.

INFP맞아요? J 아니에요?

전 회사에서 MBTI를 좋아하는 직장 동료로부터 위와 같은 말을 자주 들었다. 내가 업무에 관련된 계획을 세우고 문서화하여 정리하고 있으면 놀러 와서 저런 말을 자주 하셨다. P는 무계획,자율... J는 계획적인, 뭐 그런 걸로 이해했다. 그렇다면 나는 P가 맞다.

팀 단위로 작업을 할 때는 지독한 책임감이 발동한다. 나는 어렸을 적부터 부모님께 '남한테 피해를 끼치면 안 된다'는 말을 들으며 자랐다. 그래서 단체생활을 할 땐 나의 안위보다 팀을 먼저 생각하는 쪽으로 진화했다. ('내'가 너무 뒷전이게 되어서 가끔은 저주받았다고 생각한다) 나는 계획 세우는 걸 귀찮아하지만, 업무를 위해서는 했다. 이번 사이드 프로젝트는 업무라기보단 취미였다. 그래서 P 성향이 제대로 발휘되었다.

즉흥적으로 개발하는 건 재밌지만 그 뒷감당은 전혀 재밌지 않았다. 설계구조 뿐만이 아니라 UI도 제대로 구상해 보지 않은 게 많이 아쉽다. 맘에 안 드는 구석이 많다. 앞으로는 혼자 개발할 때도 P 성향을 좀 억누를 필요가 있겠다. 고수만 할 수 있다는 상향식 설계를 습관화하면 좋지 않을까.

blog reop