이 블로그에 대해 두 해 동안 생각했습니다.
‘원한다’는 표현은 정확하지 않고, 오히려 집착에 가깝다. 초기에는 프론트엔드·백엔드 코드를 쓰지도 못하고, 임베디드 코드조차 작성하지 못했을 때부터 이런 감정이 생겼다. 그때 전자공학을 만지작거리며 우연히 @ushio의 B站 동영상과 웹사이트를 보게 되었고, 재미있다고 느껴 나도 해보고 싶었다. 이후 약 반년 동안 기초부터 C와 약간의 JS/CSS를 배우고, Hexet을 이용해 정적 블로그를 만들어 GitHub Pages에 배포했다. 이렇게 나만의 작은 공간을 갖게 되었다.
再后来，看到了 @Innei 的小站，设计很精致、功能也很全，当时的我看了一眼我就想要，甚至还赞助支持了，虽然后面没用上但是这钱也花的不怨 因为我摸到了 React 源码，就和我最初看到 C 一样，不过就是代码嘛，有什么大不了的，总有一天我要自己写一个。
그 후에 @Innei님의 작은 사이트를 보게 됐습니다. 디자인이 아주 정교하고 기능도 완벽했어요. 그때 한눈에 보고 바로 갖고 싶었고, 심지어 후원까지 했습니다. 나중에 사용하지는 않았지만, 돈을 쓴 것을 후회하지는 않아요. React 소스 코드를 접하게 되어 처음 C를 봤을 때와 같은 느낌이었거든요. 코드는 그저 코드일 뿐, 큰 일이 아닙니다. 언젠가 제가 직접 하나 만들 날이 올 거라고 믿어요.
조용한 숲
그것은 2024년이었고, 그 후 24, 25, 26년이 현재까지
그 이후로 멈출 수 없게 되었다.
통제불능
처음에는 @colmugx님의 Hexo 테마 Nlvi에 라이트‑다크 토글만 넣고 싶었습니다. Dark Reader 스타일의 JavaScript 코드를 얕게 넣었지만, 보기 흉하고 만족스럽지 않았죠. 이후 CSS @media를 배우고, JS SPA 토글로 넘어가고, TailwindCSS의 .dark 클래스를 사용해보고, SSR next‑theme을 시도한 뒤, 마지막으로 Cookie와 Head Sync Inline 스크립트를 직접 손으로 만들어 FOUC 깜빡임을 해결했습니다. 총 네‑다섯 가지 방법을 써 보았습니다.
하지만 이것은 빙산의 일각에 불과합니다. React를 접한 뒤, 석기 시대의 Hexo와 Vanilla JS에서 시작해 Next.js 13 Page Router까지 오르며, 그 후 Vue를 살펴보고 SPA 라우팅을 연구하고 index.html 폴백을 이해하며 프로젝트를 무수히 새로 만들었습니다. 서버를 구매하고 Docker, Nginx, NAS를 만지작거리다 1Panel이 별로라 생각해 Canopy 패널을 직접 손으로 코딩했고 NAS 스토리지 어레이를 연구해 RFS를 작성했습니다. SSL을 설정하면서 국내 환경에 맞서다 보니 acme.sh가 너무 번거로워 Rust로 역방향 프록시(Vane & Lazyacme)를 만들게 되었습니다. 원래는 밤에 3시간 동안 만든 800줄짜리 쓰레기 코드였지만, 친구의 격려로 4개월 동안 개발하며 HTTP/3, Zero‑Copy, Layer 모델, Flow 엔진을 모두 넣었습니다. 나중에 Seam이라는 풀스택 프레임워크도 있는데, 이것도 또 다른 함정이라 나중에 이야기하겠습니다.
과도한 엔지니어링
그리하여 AI 시대가 찾아왔고, 불안이 두 배가 되었다.
가장 아이러니한 점은, 이 일들은 원래 블로그를 시작한 뒤에 기록하면서 진행해야 했다는 것입니다. 그런데 블로그는 계속해서 포기되었고, 아이디어는 점점 늘어났지만 그것들을 기록할 곳이 없었습니다. 한편으로는 내면에서 비난하고 있습니다; Vane을 완성하기로 약속했지만 할 수 없었고 멈추었습니다. 또 다른 한편에서는 점점 멀어지는 무력감을 느낍니다. 나는 무엇을 해야 할지 늘 기억하지만, 실현하지 못합니다. 곰곰히 생각해보면, 나는 꽤 오랫동안 앉아서 뭔가를 쓰지 않았다는 것을 깨닫게 됩니다. 지금 돌아보면, 이 모든 것이 같은 문제—과도한 엔지니어링을 가리키고 있습니다.
그때 나는 실제로 내가 길을 잃고 있다고는 전혀 느끼지 못했다. Vane? 어쨌든 블로그는 나중에 배포해야 하니 역방향 프록시가 필요할 것이다. Seam? 결국 언젠가 풀스택을 작성해야 하니 내가 이상적인 프레임워크를 먼저 구축하는 것이 낫다. 모든 단계마다 이유가 있고, 모든 단계는 '나중에 쓸 수 있다'는 것이다. 하지만 문제는 '나중에'가 절대 오지 않는다는 점이다. 나는 한 번도 실제로 시작하지 않았기 때문이다…
실패
블로그를 작성하는 데 실제로는 역방향 프록시도, 자체 프레임워크도 필요하지 않습니다. 하지만 그 당시 나는 그것들을 전제조건으로 여기며, 영원히 차단되지만 합리적인 이유라고 생각했지만, 실제로는 그렇지 않았습니다. 진정한 전제조건은 단 하나뿐입니다: 앉아서 첫 번째 글을 써 내려가는 것.
사실 블로그는 손대지 않은 것이 아니라, 오히려 세 번 했습니다.
처음은 아직 Next.js 13 Page Router 시절이었어요. 그때 나는 SPA가 무엇인지 겨우 이해했고, SSR, SSG, ISR 같은 개념은 전혀 몰랐지만, 다른 사람들이 SSR이 좋다고 하길래 나도 써야겠다고 했죠. 코드를 작성하면서 이 아키텍처들이 어떤 문제를 해결하려는 건지 전혀 이해하지 못한다는 것을 깨닫고 더 이상 진행할 수 없었어요. 그 뒤에 Vue 2 순수 SPA로 전향했는데, 왜 Vue를 선택했냐고요? 솔직히 말하면 이름이 멋져 보이고, 새로워 보여서 한번 시도해 본 거예요. 오래 가지도 못했어요. 세 번째는 React로 돌아와서, 순수 JSX부터 시작해 TypeScript를 배우고 TSX도 다루게 되었으며, CJS와 ESM의 차이를 이해하고 Reactive에 빠졌어요. 이후 Lucide, Framer Motion, Radix UI 같은 이제는 없으면 안 되는 라이브러리들을 사용했죠—이번엔 드디어 뭔가 형태가 잡힌 느낌이었어요. 하지만 여전히 실패했어요. 본질적으로 나는 남들이 쓰는 걸 그대로 베끼는 것에 불과했거든요. 겉으로는 괜찮아 보였지만, 왜 그렇게 해야 하는지 전혀 이해하지 못했어요. 게다가 AI의 환상적인 도움으로 많은 것을 MVP 수준으로는 구현할 수 있었지만, 스케일업 단계에서는 온통 함정이었어요.
그 후에 React(Remix) Router Loader, Next.js 15 App Router, RSC 등을 배우게 되었지만, 그때는 일상이 이미 매우 바빠서 코딩할 시간이 거의 없었고, 네 번째 실패를 할 기회조차 없었습니다. 돌아보니 제 사이트는 Next.js 13에서 Next.js 15로 옮겨졌고, 마이그레이션을 막 끝내고 아직 배포되지 않았을 때 Next.js 16 beta‑1이 출시되었습니다.
놓아버리기
"想开了"라고 말하는 것은 실제로 정확하지 않으며, 내가 피곤해서다.
AI 시대의 리듬이 너무 빠릅니다. 모델이 하나씩 연속으로 반복되고, 새로운 기술이 연속으로 나타나면서 점점 불안해집니다. 멈추면 추월당할 것 같은 느낌이 듭니다. 가장 미쳤을 때 하루에 16개의 작은 코드를 작성했고, 토큰은 하루에 약 1,900 USD를 소모할 수 있었습니다 (대략 2월쯤), 몸이 거의 지쳤습니다. 하지만 이 모든 것을 멈추게 만든 것은 어떤 깨달음이 아니라 단순한 피로였습니다. 점점 빨라지는 리듬 속에서 마지막 짚이 내려오자 저는 오히려 안도감을 느꼈고, 마음을 열었으며, 포기했습니다; 이렇게 하면 오히려 좋기도 합니다.
나는 놓기 시작했다. 예전마다 고집하던 것을 포기하고, 적당한 시점에 멈추는 법을 배우며, 내일 일은 내일에 말한다. Vane 아직 안 됐어? 일단 놔두자. Seam 아직 멀었어? 나중에 하자. 블로그가 완벽하지 않아? 먼저 올리자. 완전히 Vibe Coding을 시작하고, 문제가 없으면 신경 쓰지 않고, 문제가 있으면 나중에 이야기한다.
이상하게도, 손을 놓은 뒤에도 품질이 나빠지지 않았다. 이는 아마도 이전의 “古法” 프로그래밍 시절이 헛되지 않았기 때문이라고 생각한다. GPT‑2 시절부터 이미 AI를 사용하기 시작했지만, 그때는 여전히 모든 코드를 한 줄씩 성실히 작성하고 모든 개념을 이해하려고 했다. 그 경험이 토대가 되었고, 이후의 Vibe Coding이라기보다 Context Coding이라고 부르는 것이 맞으며, 필요한 판단력은 여전히 남아 있고, 손을 놓았다고 해서 저급한 실수나 사고가 발생한 것은 아니다.
이전의 모든 고생이 지금 놓아버릴 수 있는 자본을 주었다.
원점
최종 솔루션은 오히려 매우 간단합니다: All in Cloudflare. R2 객체 스토리지, D1 Edge 데이터베이스, KV를 캐시로 사용하고, Worker가 SSR을 실행합니다. 모두 서버리스이며 서버가 없습니다.
이 답변은 빈정거리는 건가요? 아주 빈정거립니다. 이 “간단한” 끝점에 도달하기 전에 나는 한 바퀴를 돌아서 우회했습니다. 한때 자체 구축을 계획했기에 서버 관리, Docker 파헤치기, 컨테이너 관리가 필요했고, 그래서 관리 패널로 Canopy를, 인증서 관리를 위해 Lazycert를, 역방향 프록시로 Vane을, 리소스 모니터링 훅으로 Twig을 작성했습니다. 한 무더기의 프로젝트는 결국 쓰레기 서버를 위해서였습니다.
스토리지는 마찬가지입니다. 객체 스토리지가 비싸다고 생각해서 내 서버의 하드디스크를 사용하고 싶었고, 그래서 RFS라는 VFS를 만들었습니다. 이는 단일 파일을 원자적으로 중복 제거하고 병합하기 위한 것이며, 80~90년대의 레지스트리 개념까지 부활시켰고, 마지막으로 FUSE를 통해 마운트했습니다. 그 결과, 별로 좋지 않은 휠을 만드는 데 더 많은 시간을 들였고, 서버는 1년 동안 빈 채로 돌아갔으며, 완전히 적자 사업이었습니다.
결국 여러 차례 돌아서 다시 Serverless 로 돌아왔습니다. Vercel 의 개념은 좋지만 Next.js 는 마음에 들지 않습니다. 또한 Vercel 은 마법이 너무 많고, Edge 에서 실행되도록 미리 컴파일하는 미들웨어 설계는 결국 파편화되고 몇몇 CVE 가 발생하기까지 했습니다. 모든 것을 원본 서버에 모아두는 것이 더 나을 것 같습니다. 반면 Cloudflare Workers 는 매우 훌륭합니다. 10 MB 이하의 결과물을 WASM 으로 컴파일해 Edge 에서 실제 비즈니스 로직을 실행할 수 있는 또 다른 극단을 구현했으며, 이것이 제가 원하던 것입니다. 비용을 제외하고는 큰 단점이 없으며, 이는 사실상 단점이 아니라 절약된 시간이 곧 돈이기 때문입니다.
적을수록 풍부하다
이 문장을 무수히 들어왔지만, 진정으로 그 의미를 이해하는 데는 두 해가 걸렸습니다.
엔지니어링의 본질은 “Make it function, make it correct, then make it exceptional.”입니다. 나는 마침내 올바른 길을 찾아 functional하게 만들었습니다. 현재 블로그가 소박한가요? 소박합니다. 완전하지 않은가요? 확실히 완전하지 않습니다. 하지만 전혀 없는 것보다는 낫습니다. 만약 출시조차 없고 “아마 필요할지도” 하는 것을 계속 만들면서 보이지 않는 완벽을 추구한다면 결국 아무것도 내놓지 못하게 됩니다. 이는 타협이 아니라 엔지니어링상의 선택입니다. 어쨌든 나는 마음을 열었습니다. 그래서 마음을 열었습니다. 이제는 하나의 세부 사항에 집착하지 않고 밖으로 나갔습니다. 휴대폰 앨범에 야외 사진이 오래 없었기에 길가를 즉흥적으로 찍었는데, 정말 오랜만에 밖에 나왔습니다.
과거에 걸었던 우회로를 되돌아볼 때, 후회하시나요? 전혀 후회하지 않습니다. 스스로 시도해 보지 않으면 영원히 이해 못 할 수도 있습니다. 더구나 AI 시대에 저는 예전의 길을 걷는 것이 거의 불가능해졌습니다. 너무 많은 워크플로가 이미 바뀌었거든요. 또한 이 프로젝트는 Taki이며, 100% AI 코딩이지만 장기적으로 유지 관리할 수 없다는 뜻은 아니며, 인간적인 느낌이 없다는 뜻도 아닙니다. 실제로 AI가 있든 없든 중요하지 않으며, 제가 좋아하는 것은 코드 자체를 쓰는 것이 아니라 무언가를 구축하는 것입니다...