당신의 지루한 스택은 충분히 지루하지 않다
Source: Dev.to
나는 “My 2026 Tech Stack is Boring as Hell” 글을 읽고 고개를 끄덕였다. 모놀리식? 물론. SQLite? 아름답다. 단일 VPS? 완벽하다.
그런데 눈에 띈 것이 있다: 아직도 React를 쓰고 있다는 점이다.
React에 문제가 있다는 말은 아니다—실제 문제들을 해결해 주니까. 하지만 우리가 ‘지루함’에 대해 이야기한다면, 한 단계 더 나아갈 수 있을 것 같다.
당신의 프레임워크보다 앞선 스택
인터페이스: 터미널. 웹 앱이 아니다. GUI도 아니다. 텍스트를 입력받아 텍스트를 반환하는 CLI.
접착제: Bash, Python 스크립트, JSON. 오래전부터 모든 Linux 머신에서 동작하는 것들.
프론트엔드: 필요할 때는 HTML + CSS + 바닐라 JavaScript. 빌드 단계 없음. node_modules 없음. 파일만 있으면 된다.
“하지만 그건 웹 스택이 아니잖아요!”
맞습니다. 제가 만드는 대부분은 웹 앱일 필요가 없습니다. 작동해야 할 뿐입니다.
임대된 지식 vs. 소유된 지식
Here’s the thing about React: you’re 임대 that knowledge.
React’s mental model, its hooks, its ecosystem—you’re paying cognitive rent on abstractions someone else controls. When the next thing comes along (and it will), that knowledge depreciates.
The terminal? HTTP? JSON? SQL? Those are 소유된 knowledge.
My Bash scripts from 2015 still run. My Grunt configs are artifacts from a dead civilization.
The Lindy effect seems to hold: things that have survived tend to keep surviving. The Unix philosophy has been here for 50 years. I’m betting it’ll outlast whatever framework is hot right now. Maybe I’m wrong, but historically that’s been a safe bet.
Standards vs. Ecosystems
여기 웹이 프레임워크가 우리를 잊게 만들기 전에 제대로 잡고 있던 관심사의 분리가 있습니다.
- HTML은 콘텐츠입니다.
- CSS는 프레젠테이션입니다.
- JavaScript는 동작입니다.
각각은 독립적으로 유용하고 독립적으로 진화할 수 있습니다. CSS를 건드리지 않고 HTML을 작성할 수 있고, JavaScript를 작성하지 않고 CSS로 스타일을 지정할 수 있으며, 서로의 내부에 의존하지 않기 때문에 함께 조합됩니다.
React는 이를 무너뜨립니다. 당신의 콘텐츠, 프레젠테이션, 동작이 모두 JSX 안에 얽혀 있습니다. 무언가의 모양을 바꾸고 싶다면, 그 동작을 처리하는 같은 파일을 건드려야 합니다. “컴포넌트” 추상화는 분리가 아니라 번들링입니다.
React가 틀렸다고 말하는 것은 아닙니다. 일부 문제에서는 번들링이 의미가 있습니다. 하지만 당신이 포기하고 있는 것을 인식하세요: 다른 레이어를 모두 이해하지 않고도 한 레이어만 바꿀 수 있는 능력.
표준은 조합하고, 생태계는 얽힌다.
HTML을 배우면 그 지식은 HTML이 동작하는 모든 곳에서 통합니다. React 방식으로 무언가를 배우면 그 지식은 … React 안에서만 통합니다. 그리고 다음 버전의 React는 어쩌면 그 방식을 또 바꿀 수도 있습니다.
에코시스템을 배우지 마세요
This is my heretical take: don’t invest heavily in learning ecosystems.
Ecosystems are too big to fit in your head. They have their own idioms, tooling, and ways of thinking. By the time you’ve internalized React’s mental model, you’ve spent cognitive budget that could have gone to things that transfer.
Ecosystems are controlled by others. They can change direction, get abandoned, or fall out of fashion. The npm graveyard is full of packages that were essential three years ago.
Ecosystems don’t compose well with things outside themselves. Try mixing React with a vanilla‑JS library sometime. It’s possible, but you’re fighting the grain.
Learn standards. Learn protocols. Learn the boring stuff that predates the framework wars.
“하지만 CLI는 배우기 어렵다”
그때는 사실이었습니다.
이제 나는 플래그를 찾아내고, 옵션을 설명하며, 명령을 내가 기억하는 것보다 더 잘 조합할 수 있는 LLM을 가지고 있습니다. GUI가 필요하게 만든 탐색성 문제? 대부분 해결되었습니다.
그리고 여기서 중요한 점은: LLM은 CLI 도구를 love합니다.
왜? 텍스트 기반이기 때문입니다. 텍스트 입력, 텍스트 출력. 예측 가능한 동작. 작은 표면적. Unix 도구를 조합 가능하게 만드는 동일한 특성이 AI 오케스트레이션에 완벽합니다.
나는 간단한 CLI 도구를 만들고, 사용 방법을 설명하는 짧은 마크다운 파일을 추가합니다. 그러면 Claude가 나머지를 알아서 처리합니다. “이걸 일반적인 플랫폼에 교차 게시해줘”라고 말하면, 어떤 명령을 어떤 순서로 실행해야 하는지, 중간에 발생하는 오류를 어떻게 처리해야 하는지를 알고 있습니다.
React 컴포넌트 라이브러리로도 같은 방식을 시도해 보세요.
조합성이 핵심이다
원본 글에서는 모놀리스를 디버깅할 때 “그냥 Ctrl + F만 하면 돼”라고 언급했습니다. 같은 느낌이죠.
Unix 철학: 한 가지 일을 잘 하는 작은 도구들을 텍스트 스트림으로 연결한다. 각 조각을 머릿속에 담을 수 있다. 힘은 조합에 있다.
이는 향수가 아니라 공학입니다.
추상화 레이어가 새벽 2시에 깨졌을 때, 그것을 충분히 이해하고 고칠 수 있나요? 200줄짜리 Python CLI라면 가능합니다. 실제 디버깅에 필요한 부분을 모두 추상화해 버린 프레임워크라면… 아닐 수도 있겠죠.
단순한 도구는 단순히 실패합니다. 복잡한 도구는 고고학 학위가 필요할 정도로 복잡하게 실패합니다.
이 부분에서 한계가 나타남
저는 광신자가 아닙니다. 실시간 애플리케이션? 지속적인 연결? 네, 텍스트 스트림은 그곳에서 어려움을 겪습니다. 풍부한 미디어? 모든 것이 텍스트는 아니죠.
하지만 솔직히 말해 보세요: 여러분이 만드는 것 중 실제로 그런 것이 얼마나 필요합니까? 대부분의 CRUD 앱은 WebSocket이 필요하지 않습니다. 대부분의 내부 도구는 React SPA가 필요하지 않습니다.
지루한 답이 보통은 옳습니다.
불확실성 헤지
Nobody knows what the world looks
# Needed webpack? Then it was Parcel. Then Vite. Then… whatever’s next.
Each transition costs you. Each migration is hours you could have spent building.So I hedge:
- 최소한의 의존성. 생태계가 변할 때 깨질 수 있는 요소를 줄인다.
- 전이 가능한 기술. 터미널 지식은 프레임워크 지식보다 패러다임 전환을 더 잘 따라간다.
- 우아한 퇴보. 모든 것이 변할 때, 단순한 도구는 적응하고 복잡한 도구는 무너진다.
I’m not claiming this is the right strategy. I’m claiming it’s a strategy for navigating uncertainty. Your mileage may vary.
내가 포기하지 않을 지루한 도구
당신은 우리가 포기하지 않으려는 지루한 도구가 무엇인지 물었습니다.
내가 고수하는 것은 터미널 자체입니다. 특정 도구가 아니라 인터페이스죠. 내가 태어나기 전부터 대체로 변함없던 그 것. 오늘 우리가 열광하는 어떤 것보다 오래 살아남을 거라 믿고 있습니다. 하지만 이전에 틀린 적도 있었습니다.
더 깊은 질문
모든 것이 변할 때도 여전히 작동할 것은 무엇일까?
모르겠습니다. 아무도 모릅니다. 하지만 저는 한 가지 경험법칙을 가지고 있습니다: 여러 패러다임 전환을 살아남은 것에 베팅한다—텍스트 입력, 텍스트 출력; 조합 가능한 도구; 생태계보다 표준; 빌린 것이 아니라 스스로 소유한 지식.
아마도 이것이 잘못된 베팅일지도 모릅니다. 다음 패러다임이 터미널, 유닉스, 텍스트 처리에 대한 모든 지식을 구시대적으로 만들 수도 있죠. 만약 그렇다면 저는 적응할 것입니다—아마도 새로운 도구를 사용해 새로운 것을 배우게 될 겁니다.
하지만 그때까지는 저는 지루함을 유지하겠습니다. 당신보다 더 지루하게.