DX 미니프레임워크 :: 저는 프레임워크를 공부하려고 개발하지 않습니다

2026.06.24 01:28 6 0

DX 미니프레임워크 — 저는 이렇게 씁니다

저는 라라벨 같은 구조를 쓰지 않습니다.
정확히 말씀드리면, 저는 애초에 그런 식의 무겁고 번거로운 개발 방식 자체를 선호하지 않습니다. 세상에서는 라라벨이 좋다, 생태계가 크다, 패키지가 많다, 구조가 체계적이다 같은 이야기를 많이 합니다. 그런데 저는 그런 이야기보다 훨씬 더 단순한 기준으로 프레임워크를 봅니다. 그래서 지금 당장 사이트 하나를 빠르게 만들 수 있는가, 서버에 올렸을 때 쓸데없는 제약 없이 바로 굴러가는가, 그리고 나중에 내가 원하는 기능을 코어를 뜯어고치지 않고도 계속 확장할 수 있는가. 저에게 중요한 것은 늘 이 세 가지였습니다.

솔직히 말씀드리겠습니다.
회사 소개 페이지 하나 만들고, 게시판 하나 붙이고, 회원 기능 넣고, 필요하면 결제와 문자 기능까지 연결해야 하는데, 그걸 하겠다고 Composer부터 돌리고, .env 파일 맞추고, 서비스 프로바이더니 미들웨어니 패키지 의존성이니 하면서 프레임워크 세팅에 시간을 쏟는 방식은 제 성향과 전혀 맞지 않습니다. 저는 프레임워크를 공부하려고 개발하는 사람이 아니라, 실제로 돌아가는 사이트를 만들기 위해 개발하는 사람입니다. 사이트를 만들려고 앉았는데 정작 사이트는 못 만들고 프레임워크 구조를 맞추는 데 시간을 다 쓰고 있다면, 제 기준에서는 그건 도구가 일을 도와주는 것이 아니라 오히려 일을 늘리는 쪽에 가깝습니다.

그래서 저는 DX 미니프레임워크를 씁니다.
거창하게 포장된 프레임워크가 아니라, 필요한 것은 다 갖추고 있으면서도, 불필요하게 무겁지 않고, 실전에 바로 투입할 수 있는 구조이기 때문입니다. 저는 이 점이 정말 중요하다고 생각합니다. 개발이라는 것은 결국 결과물을 만드는 일입니다. 화면이 떠야 하고, 글이 써져야 하고, 게시판이 돌아가야 하고, 회원이 가입되어야 하고, 결제가 붙어야 하고, 운영자가 관리할 수 있어야 합니다. 결국 사용자는 프레임워크의 철학을 보는 것이 아니라, 완성된 서비스를 봅니다. 저는 그 사실을 너무 잘 알고 있기 때문에, 프레임워크를 평가할 때도 늘 “이 구조가 실제로 일을 얼마나 빨리, 얼마나 안정적으로 끝내주느냐”를 먼저 봅니다. DX 미니프레임워크는 바로 그 지점에서 만들어진 도구입니다.

DX 미니프레임워크는 거창한 장식보다, 실제로 필요한 것에 집중한 구조입니다

DX 미니프레임워크는 이름 그대로 작은 프레임워크입니다.
그런데 여기서 말하는 “작다”는 것은 기능이 부족하다는 뜻이 아닙니다. 오히려 반대입니다. 웹사이트를 만들 때 실제로 필요한 핵심만 남기고, 개발자를 괴롭히는 군더더기를 덜어냈다는 뜻에 더 가깝습니다. 저는 작은 프레임워크를 만들고 싶었던 것이 아니라, 쓸데없이 큰 프레임워크를 만들고 싶지 않았던 것에 가깝습니다.

웹사이트를 만들려면 기본적으로 필요한 것들이 있습니다.
URL을 처리할 라우터가 있어야 하고, 데이터베이스를 다룰 수 있어야 하고, 공통 로직을 중간에 끼워 넣거나 기능을 확장할 수 있는 구조가 있어야 하고, 세션과 인증이 안정적으로 잡혀 있어야 하며, 업로드와 캐시 같은 실무 기능도 빠지면 안 됩니다. 저는 DX를 만들면서 바로 그 “기본이지만 반드시 필요한 것들”에 집중했습니다. 반대로, 겉으로 보기에는 그럴싸하지만 실제 프로젝트를 만드는 속도를 늦추는 요소들은 최대한 줄였습니다.

라우터는 심플해야 하고, 흐름은 눈에 보여야 합니다

DX 미니프레임워크에는 라우터가 있습니다.
이건 너무 당연한 이야기처럼 들릴 수 있지만, 저는 라우터가 단순해야 한다고 생각합니다. 어떤 URL이 어떤 컨트롤러와 어떤 로직으로 연결되는지, 개발자가 빠르게 파악할 수 있어야 합니다. 프레임워크가 커질수록 이상하게도 가장 기본적인 흐름조차 복잡해지는 경우가 있습니다. 주소 하나 연결하려고 설정 파일을 여러 군데 들여다보고, 미들웨어 흐름을 타고, 컨테이너를 거쳐서 어디서 무슨 일이 벌어지는지 추적해야 한다면, 저는 그 순간부터 피로해집니다.

DX는 그런 방향을 원하지 않았습니다.
저는 개발자가 “이 주소는 여기로 가고, 이 요청은 이 파일에서 처리된다”라는 흐름을 빠르게 읽을 수 있기를 원했습니다. 실제 작업을 할 때 가장 중요한 것은 멋있는 구조가 아니라, 내가 지금 무엇을 고치고 있고 어디를 수정해야 하는지가 명확하게 보이는 것이기 때문입니다. DX의 라우팅은 바로 그 감각을 기준으로 잡혀 있습니다. 괜히 머리를 쓰게 만드는 구조가 아니라, 보면 바로 이해되는 구조, 손을 대면 바로 수정되는 구조를 지향했습니다.

데이터베이스도 마찬가지입니다. 저는 복잡한 추상화보다 직접적인 구조를 선호합니다

DX 미니프레임워크의 데이터베이스 레이어는 PDO 기반입니다.
그리고 저는 이 부분을 일부러 복잡하게 만들지 않았습니다. $db->rows(), $db->find(), $db->insertRow() 같은 식으로 자주 쓰는 흐름이 바로 손에 익도록 잡았습니다. 이유는 간단합니다. 사이트를 만드는 입장에서는 데이터가 어떻게 들어오고 나가는지가 명확해야 하기 때문입니다.

저는 ORM을 화려하게 쌓아 올리고, 모델을 여러 겹 감싸고, 실제로 어떤 쿼리가 나가는지도 모른 채 추상화 위에서 작업하는 방식이 제 취향과 맞지 않습니다. 물론 그런 구조가 필요한 프로젝트도 있겠지요. 하지만 제가 만드는 다수의 프로젝트는 그렇게까지 무거운 구조가 필요하지 않습니다. 오히려 어떤 테이블을 읽고, 어떤 조건으로 가져오고, 어떤 데이터를 저장하는지가 명확하게 보이는 편이 훨씬 빠르고 편합니다. 특히 혼자서 프로젝트를 관리하고, 나중에 유지보수까지 책임져야 하는 입장에서는 더 그렇습니다. DX는 그 점을 아주 솔직하게 받아들인 구조입니다. 괜히 복잡한 척하지 않고, 필요한 쿼리를 빠르게 작성하고 바로 결과를 얻을 수 있는 방식에 더 가깝습니다.

DX의 핵심은 확장입니다. 저는 이 부분이 가장 중요하다고 생각합니다

제가 DX 구조를 이야기할 때 빼놓지 않는 것이 바로 확장성입니다.
저는 오래전부터 늘 같은 생각을 했습니다. 코어를 뜯어고쳐야만 기능을 붙일 수 있는 구조는 오래 못 갑니다. 처음에는 간단해 보여도, 기능이 하나둘 늘어나기 시작하면 결국 코어 파일을 건드리게 되고, 그렇게 수정이 누적되면 업데이트는 어려워지고 유지보수는 점점 더 힘들어집니다. 저는 그런 구조를 너무 많이 봤고, 그래서 DX를 만들 때는 애초에 다른 길을 택했습니다.

DX 미니프레임워크에는 HookManager 기반의 훅 시스템이 있습니다.
이 구조를 통해 중간 지점에 기능을 끼워 넣고, 기존 흐름을 가로채고, 필요한 동작을 추가하고, 플러그인끼리 역할을 나눠가며 확장할 수 있습니다. 쉽게 말해서, 핵심 코어를 무너뜨리지 않고도 원하는 기능을 계속 얹을 수 있도록 만든 구조입니다. 저는 이게 프레임워크든 CMS든 정말 중요하다고 생각합니다. 처음에는 게시판 하나만 필요했는데, 나중에는 소셜로그인이 필요해지고, 결제가 필요해지고, 포인트 시스템이 필요해지고, 외부 API 연동이 필요해지고, 특정 페이지에서만 동작하는 커스텀 기능이 필요해집니다. 이때마다 코어를 열어서 직접 뜯어고쳐야 한다면, 결국 그 구조는 개발자를 도와주는 것이 아니라 발목을 잡는 구조가 됩니다.

그래서 저는 DX를 만들면서 “처음부터 확장을 전제로 둔 구조”를 중요하게 봤습니다.
기능을 추가할 때마다 코어와 싸우는 것이 아니라, 미리 준비된 개입 지점과 플러그인 구조를 활용해서 계속 붙여나갈 수 있어야 합니다. 저는 DX를 두고 종종 “확장의 달인”이라고 표현합니다. 단순히 수식어를 붙이기 위해 하는 말이 아닙니다. 실제로 DX가 가진 가장 큰 힘 중 하나가 바로 여기에 있기 때문입니다. 사이트는 한 번 만들고 끝나는 것이 아닙니다. 결국 시간이 지나면 계속 손을 대야 하고, 기능은 늘어나고, 구조는 더 복잡해집니다. 그때 무너지지 않으려면, 처음부터 확장을 견딜 수 있는 방식으로 설계되어 있어야 합니다. DX는 바로 그 방향을 바라보고 있습니다.

플러그인은 “있으면 좋은 기능”이 아니라, DX 구조의 핵심입니다

DX 미니프레임워크에는 플러그인 구조가 있습니다.
CKEditor4, 소셜로그인, 결제 PG 11종, SMS 4종 같은 기능들이 플러그인 단위로 분리되어 있습니다. 저는 이 방식이 굉장히 현실적이라고 생각합니다. 모든 사이트가 같은 기능을 필요로 하지 않기 때문입니다. 어떤 프로젝트는 게시판과 회원 기능만 있으면 되고, 어떤 프로젝트는 에디터와 파일 업로드가 중요하고, 어떤 프로젝트는 결제와 본인인증이 핵심일 수 있습니다. 그런데 처음부터 모든 기능을 프레임워크 안에 뒤섞어 넣으면 구조는 금방 무거워지고, 유지보수도 어려워집니다.

반면 DX는 필요한 것만 붙여서 쓸 수 있도록 가져갑니다.
프로젝트에 필요한 기능만 켜고, 필요 없는 것은 빼고, 확장은 플러그인으로 처리하는 식입니다. 이렇게 되면 구조가 훨씬 유연해집니다. 저는 이런 방식을 좋아합니다. 왜냐하면 “처음부터 모든 것을 다 안고 가는 구조”보다, “필요할 때 필요한 것만 붙이는 구조”가 실제 프로젝트에 더 잘 맞기 때문입니다. 특히 혼자서 개발하고 운영하고 유지보수해야 하는 환경에서는, 이 차이가 생각보다 큽니다.

세션, 인증, 캐시, 업로드 같은 기본기도 가볍게 보지 않았습니다

프레임워크는 멋있는 개념보다 기본기가 더 중요합니다.
세션이 흔들리면 인증이 꼬이고, 인증이 꼬이면 권한이 무너집니다. 업로드 구조가 엉망이면 파일 관리가 지옥이 되고, 캐시가 없으면 같은 데이터를 계속 다시 읽느라 성능이 떨어집니다. 저는 이런 부분을 절대 가볍게 보지 않습니다. 오히려 실제 운영에서는 이런 기본기들이 훨씬 더 중요하다고 생각합니다.

DX는 세션과 인증을 부트스트랩 단계에서 정리합니다.
페이지마다 session_start()를 일일이 넣고, 인증 여부를 중복 체크하고, 공통 코드를 여기저기 복사하는 방식은 저는 좋아하지 않습니다. 그런 식으로 개발하면 당장은 빨라 보여도, 결국 누락이 생기고 버그가 생기고 유지보수가 힘들어집니다. DX는 이런 반복을 줄이고 공통 흐름을 한쪽으로 모아서 관리할 수 있게 잡아두었습니다.

캐시 역시 마찬가지입니다.
DxCache::set()과 DxCache::get()처럼 단순한 인터페이스로 파일 기반 캐시를 다룰 수 있습니다. 저는 무조건 거대한 캐시 시스템이 필요하다고 생각하지 않습니다. 프로젝트 성격에 따라서는 이런 단순한 캐시만으로도 충분히 체감 성능을 끌어올릴 수 있습니다. 게시판 목록, 설정값, 반복적으로 조회되는 데이터, 공통 출력물 같은 부분은 이렇게 가볍게 캐싱해도 차이가 꽤 큽니다.

업로드 구조도 역할별로 분리해두었습니다.
에디터 이미지는 editor/년/월/ 구조로, 게시판 첨부는 boards/게시판키/ 구조로 자동 분리됩니다. 별것 아닌 것처럼 보여도, 이런 기준이 없으면 나중에 파일이 전부 뒤섞여버립니다. 저는 업로드 구조 역시 “처음부터 관리하기 쉽게” 가는 것이 맞다고 봅니다. DX는 그런 부분까지 포함해서 실제 운영을 생각한 구조입니다.

저는 DX를 멋있어서 쓰는 것이 아니라, 실전에서 편해서 씁니다

이 부분이 가장 중요합니다.
저는 DX를 “이론적으로 좋은 프레임워크”라고 소개하고 싶은 것이 아닙니다. 저는 DX를 실제로 편해서 쓰는 것입니다. 프로젝트를 빨리 시작할 수 있고, 구조를 빠르게 파악할 수 있고, 호스팅 환경 제약이 있어도 비교적 쉽게 대응할 수 있고, 필요한 기능을 붙이기에도 수월하기 때문입니다.

특히 공유호스팅 환경에서는 이런 차이가 더 크게 느껴집니다.
카페24, 닷홈 같은 환경은 아직도 현업에서 자주 마주칩니다. 중소기업 사이트, 개인 쇼핑몰, 학원 홈페이지, 지역 업체 홈페이지, 간단한 회원형 사이트 같은 경우에는 여전히 이런 환경에서 운영되는 경우가 많습니다. 그런데 이런 곳에서 거대한 프레임워크 구조를 그대로 끌고 들어가는 것은 생각보다 피곤합니다. Composer 사용 제약, 서버 설정 제약, SSH 접근 문제, 버전 충돌 같은 현실적인 문제가 따라붙기 때문입니다. DX는 이런 환경에서도 비교적 가볍게 들어갈 수 있고, PHP 중심으로 구조를 이해하기도 쉬워서 훨씬 현실적입니다.

또 하나는 빠르게 결과를 내야 하는 프로젝트입니다.
현실에서는 “몇 달짜리 거대한 서비스”보다, “일단 이번 주 안에 오픈해야 하는 사이트”가 더 많습니다. 소개 페이지를 만들고, 게시판 붙이고, 회원 기능 넣고, 관리자에서 관리할 수 있게 하고, 필요하면 결제까지 달아야 합니다. 이럴 때 개발자에게 필요한 것은 철학 강의가 아니라 속도와 안정성입니다. DX는 그 지점에서 강합니다. 괜히 큰 구조를 세우느라 시간을 버리지 않고, 필요한 기능을 바로 구현하는 데 집중할 수 있기 때문입니다.

DX는 거대한 프레임워크를 대체하려는 것이 아니라, 다른 문제를 해결하는 도구입니다

저는 DX를 두고 “모든 프로젝트를 다 해결하는 만능 프레임워크”라고 말하고 싶지 않습니다.
그런 말은 오히려 신뢰를 떨어뜨린다고 생각합니다. DX는 분명한 방향을 가진 도구입니다. 대규모 엔터프라이즈 시스템을 위한 거대한 플랫폼을 만들겠다는 욕심으로 접근한 것이 아닙니다. 대신 1인 개발자, 실무형 프로젝트, 빠른 구축, 공유호스팅 대응, 코어를 덜 건드리는 확장 구조, 필요한 기능만 골라 붙이는 방식에 초점을 맞춘 구조입니다.

그래서 어떤 분에게는 DX가 정말 잘 맞을 수 있습니다.
특히 이런 분들이라면 더 그렇습니다.

복잡한 프레임워크 세팅보다, 바로 사이트를 만드는 쪽이 더 중요한 분
공유호스팅이나 제약 있는 서버 환경에서 현실적으로 굴러가는 구조가 필요한 분
게시판, 회원, 결제, 문자 같은 기능을 빠르게 붙여야 하는 분
코어를 직접 뜯지 않고 플러그인과 훅 중심으로 확장하고 싶은 분
프레임워크를 연구하는 것보다, 결과물을 빠르게 완성하는 것이 더 중요한 분
혼자서 개발부터 유지보수까지 끝까지 책임져야 하는 분

저는 DX가 이런 분들에게 꽤 강한 도구가 될 수 있다고 생각합니다.
왜냐하면 DX는 애초에 그런 환경을 염두에 두고 만들어졌기 때문입니다.

PHP 5.6부터 8.x까지 동작하는 것도, 저는 상당히 큰 장점이라고 봅니다

이 부분도 현실에서는 무시할 수 없습니다.
개발자 입장에서는 최신 PHP 버전에서 작업하는 것이 당연하게 느껴질 수 있지만, 실제 고객사 서버나 운영 서버를 만나보면 전혀 그렇지 않은 경우가 많습니다. 아직도 오래된 PHP 환경을 쓰는 곳이 있고, 호스팅 문제나 기존 레거시 코드 때문에 버전을 쉽게 올리지 못하는 곳도 많습니다. 이럴 때 “최신 프레임워크를 쓰려면 서버부터 바꾸셔야 합니다”라는 말은, 개발보다 설득이 더 어려운 상황을 만들기도 합니다.

저는 그런 현실을 너무 많이 봤습니다.
그래서 DX는 가능한 한 폭넓은 PHP 환경에서 돌아갈 수 있도록 가져가고 싶었습니다. PHP 5.6부터 8.x까지 대응한다는 것은 단순히 스펙 한 줄이 아니라, 실제로 투입 가능한 환경의 폭이 넓다는 뜻입니다. 이건 생각보다 큽니다. 오래된 서버에서도 버텨야 하고, 새로운 환경에서도 무리 없이 굴러가야 한다면, 결국 이런 현실적인 대응력이 중요해집니다.

결국 저는 “프레임워크의 위대함”보다 “개발자의 실행력”을 더 중요하게 봅니다

저는 프레임워크를 평가할 때 거대한 이름값이나 화려한 생태계를 먼저 보지 않습니다.
그보다 더 중요한 것은, 그 도구가 개발자의 손을 얼마나 덜 피곤하게 해주느냐, 사이트를 만드는 속도를 얼마나 끌어올려주느냐, 나중에 기능을 붙일 때 얼마나 덜 망가지느냐, 그리고 혼자서도 끝까지 통제 가능한 구조냐입니다.

DX 미니프레임워크는 바로 그런 기준에서 나온 도구입니다.
불필요하게 무거운 구조를 걷어내고, 실제 사이트를 만드는 데 필요한 핵심을 남기고, 코어를 최대한 건드리지 않는 확장 구조를 준비하고, 플러그인 중심으로 기능을 붙일 수 있게 만들고, 공유호스팅 같은 현실적인 환경까지 고려한 구조입니다. 저는 이 점 때문에 DX를 높게 평가합니다. 멋있어서가 아닙니다. 실제로 일을 시켜보면 편하기 때문입니다. 그리고 저는 그게 도구의 가장 중요한 가치라고 생각합니다.

저는 그래서 DX 미니프레임워크를 씁니다

거대한 것이 필요한 것이 아니라면,
멋있는 추상화보다 지금 당장 실행되는 구조가 더 중요하다면,
복잡한 프레임워크 세팅보다 실제로 사이트를 완성하는 속도가 더 중요하다면,
코어를 직접 뜯지 않고도 기능을 계속 붙여나갈 수 있는 구조가 필요하다면,
그리고 무엇보다 1인 개발자가 처음부터 끝까지 책임지고 결과물을 만들어야 하는 환경이라면, 저는 DX 미니프레임워크가 꽤 강한 선택지가 될 수 있다고 생각합니다.

저는 프레임워크를 만들기 위해 프레임워크를 만든 것이 아닙니다.
실제로 만들고, 실제로 붙이고, 실제로 운영하기 위해 필요한 구조를 만들다 보니 DX가 된 것에 가깝습니다. 그래서 DX는 거창한 철학보다 실전이 먼저이고, 허세보다 결과물이 먼저이며, 장식보다 확장이 먼저입니다.

저는 그런 도구를 좋아합니다.
그리고 그래서, 지금도 DX 미니프레임워크를 씁니다.

거창한 것이 필요한 것이 아니라면, 딱 필요한 것만 제대로 갖춘 도구가 훨씬 강할 때가 있습니다.
DX 미니프레임워크는 바로 그런 방향에서 만들어진 구조입니다.

designonex.com