에헤야디야~~
DXCMS_86ECA4_95ECAC9DEC8082EAA0_B0EBA584EC80_99ECA595EBA4
DXCMS 소설
핵심은 지키고, 가능성은 확장한다 · 기술과 사람에 관한 이야기
1장. 오래된 서버의 불빛
밤 열한 시 사십 분. 작은 사무실 창밖으로 비가 내렸다. 민준은 모니터에 떠 있는 관리 화면을 바라보았다. 오래된 게시판, 복잡하게 얽힌 코드, 그리고 업데이트를 거듭할수록 무거워지는 시스템. 고객은 새로운 기능을 원했지만, 기능 하나를 추가할 때마다 다른 곳에서 문제가 터졌다.
“이대로는 오래 못 가겠어.”
민준은 혼잣말을 했다. 그는 수년 동안 여러 사이트를 만들어 왔다. 처음에는 화면이 멋지면 성공이라고 생각했다. 그러나 시간이 지나면서 진짜 어려운 일은 오픈 이후에 시작된다는 사실을 배웠다.
쌓이는 데이터, 바뀌는 운영 환경, 보안 취약점, 그리고 아무도 기억하지 못하는 예외 처리들.
그날 밤, 그는 기존 시스템을 조금 더 고치는 대신 질문 하나를 적었다.
‘핵심을 건드리지 않고도, 계속 확장할 수는 없을까?’
종이 위에 짧은 선을 그었다. 가운데에는 작은 코어를, 그 주위에는 플러그인과 테마, 스킨을 배치했다. 기능은 바깥에서 더하고, 핵심은 가능한 한 안정적으로 유지한다. 그 단순한 그림이 훗날 DXCMS라 불릴 구조의 첫 씨앗이었다.
DXCMS 소설·01 / 10
2장. 작지만 단단한 뼈대
민준은 거대한 프레임워크를 새로 들여오는 대신 자신이 통제할 수 있는 작은 기반부터 만들기로했다. 설치 과정은 단순해야 했다. 서버에 파일을 올리고 설정하면 시작할 수 있어야 했다. 모든 환경이 최신일 거라는 가정도 버렸다. 오래된 호스팅을 사용하는 사람에게도 문이 열려 있어야 했다.
그는 작은 프레임워크의 규칙을 정했다. 요청은 정해진 경로로 흐르고, 인증은 한곳에서 관리되며, 데이터 접근은 가능한 한 일관되게 다룬다. 반복되는 기능은 모듈로 분리했다. 그리고 무엇보다 코어를 수정해야만 기능을 만들 수 있는 구조를 피하려 했다.
처음에는 느렸다. 편리한 지름길을 택하면 오늘의 작업은 빨리 끝날 수 있었다. 하지만 그 지름길이내일의 발목을 잡을 수도 있었다. 민준은 기능 하나를 추가할 때마다 스스로 물었다.
‘이 기능이 없어도 코어는 그대로 작동하는가?’
답이 아니오라면 설계를 다시 살폈다. 코어를 단단히 하고, 변화는 바깥에서 받아들이는 것. 그 원칙은 개발 속도를 조금 늦췄지만, 시간이 흐를수록 선택의 폭을 넓혀 주었다.
그는 이 구조를 DX 미니 프레임워크라고 불렀다. 그 위에 게시판과 관리 기능을 올리자 비로소 CMS의 윤곽이 드러났다. 이름은 DXCMS. 작고 소박했지만, 더 많은 것을 담을 수 있는 뼈대였다.
DXCMS 소설·02 / 10
3장. 기능은 바깥에서 자란다
첫 번째 의뢰는 단순했다. 고객은 게시판에 새로운 반응 버튼을 달고 싶어 했다. 예전 방식이라면민준은 게시판 소스를 열어 직접 코드를 넣었을 것이다. 하지만 이번에는 다른 길을 택했다. 기능을플러그인으로 분리하고, 필요한 지점에 훅을 연결했다.
버튼은 화면에 나타났다. 기존 게시판의 핵심 파일은 그대로였다. 다음 주 고객이 버튼 모양을 바꾸고 싶다고 했을 때도, 민준은 코어를 건드리지 않았다. 플러그인의 출력과 테마의 표현을 조정하면됐다.
그 작은 성공은 생각보다 큰 의미를 가졌다. 디자인과 기능을 반드시 한 덩어리로 묶어 둘 필요가없었다. 테마는 사이트의 분위기를 결정하고, 스킨은 게시판의 표현을 바꾸며, 플러그인은 새로운능력을 보탰다. 확장 기능이 서로의 영역을 침범하지 않도록 규칙을 세우는 일이 중요했다.
민준은 개발 노트에 적었다.
‘좋은 확장 구조는 무엇이든 마음대로 바꾸게 하는 구조가 아니다. 무엇을 바꾸지 않아도 되는지분명하게 해 주는 구조다.’
그날 이후 DXCMS에 기능을 추가하는 일은 단순히 코드를 더하는 작업이 아니었다. 기존의 것을깨뜨리지 않으면서 새로운 가능성을 열어 두는 일이 되었다. 작은 플러그인 하나가 시스템 전체의수명을 늘릴 수도 있다는 사실을, 그는 조금씩 확인하고 있었다.
DXCMS 소설·03 / 10
4장. 같은 데이터, 다른 세계
어느 날 한 제작사가 찾아왔다. 여러 고객사의 웹사이트를 관리하는 작은 에이전시였다. 고객마다
다른 디자인과 메뉴를 원했지만, 게시판을 비롯한 운영 데이터는 효율적으로 관리하고 싶어 했다.
사이트마다 시스템을 따로 복제하면 유지보수 부담이 커졌다.
민준은 화이트보드에 도메인 세 개를 적었다. 그리고 그 아래에 하나의 데이터 흐름을 그렸다.
“같은 게시판 데이터를 쓰더라도, 도메인에 따라 테마와 스킨을 다르게 적용할 수 있습니다. 운영은 한곳에서 하면서 사이트별 표현은 나눌 수 있다는 뜻입니다.”
제작사 대표는 한참 그림을 보았다. 그들에게 필요한 것은 웹사이트를 하나 더 만드는 능력이 아니었다. 늘어나는 고객사를 감당하면서도 운영비와 관리 복잡성을 줄일 방법이었다.
물론 모든 구성이 자동으로 해결되는 것은 아니었다. 도메인 판별, 권한, 설정 분리, 캐시와 주소 처리 같은 세부 사항을 정확히 설계해야 했다. 민준은 가능성을 과장하지 않았다. 실제 환경에서 검증해야 할 조건을 하나씩 적었다.
며칠 뒤 시험 사이트들이 차례로 열렸다. 같은 콘텐츠가 서로 다른 얼굴을 하고 나타났다. 한곳은기업형 화면이었고, 다른 곳은 커뮤니티에 가까웠다. 데이터는 공유했지만 경험은 각 사이트의 목적에 맞게 달라졌다.
대표가 말했다. “이제 샘플을 한곳에서 관리하면서 고객에게 다른 결과를 보여 줄 수 있겠네요.”
민준은 고개를 끄덕였다. 멀티사이트는 사이트 수를 늘리는 기능만이 아니었다. 반복되는 일을 줄이고, 하나의 기반 위에서 여러 사업 모델을 실험하게 하는 방식이었다.
DXCMS 소설·04 / 10
5장. 공격은 조용히 시작된다
새벽 두 시 십칠 분. 서버 로그에 낯선 요청이 반복해서 쌓이기 시작했다. 존재하지 않는 경로를 두드리고, 입력값에 이상한 문자열을 넣고, 관리자 페이지를 찾으려는 시도들이었다. 화면에서는 아무 일도 일어나지 않는 것처럼 보였지만, 로그는 다른 이야기를 하고 있었다.
민준은 로그를 분류했다. 모든 요청이 침입에 성공했다는 뜻은 아니었다. 일부는 차단되었고, 일부는 잘못된 경로에서 끝났다. 그러나 그는 안심만 하고 있을 수 없었다. 보안은 한 번 설치하고 끝나는 장식이 아니었다.
그는 방어를 여러 층으로 나눴다. 입력값 검증, 접근 권한 확인, 요청 제한, 관리자 영역 보호, 로그관리. 각 기능은 가능한 한 독립된 플러그인으로 두어 개별적으로 점검하고 패치할 수 있게 했다.
서버 환경에 따라 동작 방식이 달라질 수 있다는 점도 문서에 남겼다.
“완벽하게 안전하다고 말하지 말자.” 민준은 자신에게 말했다. “대신 무엇을 막고, 무엇을 확인했고, 무엇은 아직 검증해야 하는지 분명하게 말하자.”
그는 보안 공지를 작성했다. 변경한 시간, 적용한 패치, 확인할 항목을 차례로 적었다. 겁을 주기 위한 공지가 아니라 운영자가 실제로 판단할 수 있게 하는 공지였다.
그날 밤 공격은 계속되었지만, 민준의 태도는 달라져 있었다. 보안은 영웅 한 명이 모든 것을 막아내는 장면이 아니었다. 작은 방어를 겹겹이 쌓고, 기록을 살피고, 실수를 인정하고, 다시 고치는 지루하고도 중요한 일의 연속이었다.
DXCMS 소설·05 / 10
6장. 데이터가 시간을 증명하다
처음 DXCMS를 사용한 사람들은 데이터가 많지 않았다. 게시글 몇 개, 회원 몇 명, 댓글 몇 줄. 그시절에는 시스템이 가벼운지만 확인해도 충분해 보였다. 하지만 시간이 지나면서 게시글은 수백 개가 되고, 수천 개가 되고, 어느새 수만 개로 늘어났다.
민준은 숫자 자체를 자랑으로 내세우지 않았다. 데이터가 쌓이는 동안 어떤 문제가 발생했고, 그것을 어떻게 해결했는지가 더 중요했다. 목록 조회가 느려지면 쿼리를 살폈고, 반복 요청이 많아지면캐시를 검토했다. 로그가 지나치게 커지면 기록 주기를 조정했다. 실제 운영에서 발견한 문제는 다
음 패치의 이유가 되었다.
어느 이용자가 메시지를 보냈다.
“처음에는 작은 게시판으로 시작했습니다. 지금은 우리 업무 기록이 대부분 여기에 쌓여 있습니다.
예전에는 게시판을 바꿀 때마다 자료를 옮기는 게 두려웠는데, 이제는 유지보수 계획부터 생각하게 됐습니다.”
민준은 그 문장을 여러 번 읽었다. 시스템의 가치는 새로 설치한 날보다 몇 년 뒤에 드러나는지도몰랐다. 데이터가 오래 쌓일수록 서비스는 그 데이터에 더 큰 책임을 지게 된다. 백업과 복구, 권한과 개인정보, 호환성과 마이그레이션은 선택 사항이 아니었다.
그는 개발 일지에 썼다.
‘시간은 기능 목록에 적히지 않는다. 그러나 오랫동안 운영된 데이터는 시스템이 견뎌 온 변화의기록이다.’
DXCMS는 완성된 작품이 아니었다. 오히려 시간이 지나며 더 많은 질문을 받아들이는 작업대에가까웠다.
DXCMS 소설·06 / 10
7장. 인공지능이라는 새 동료
인공지능 도구가 개발 현장에 빠르게 들어오기 시작했을 때, 민준은 기대와 경계를 동시에 품었다.
예전에는 작은 플러그인 하나를 만들기 위해 자료를 찾고, 구조를 이해하고, 코드를 작성하고, 오류를 반복해서 고쳐야 했다. 이제 인공지능은 초안을 만들고, 반복 작업을 돕고, 낯선 코드를 설명해줄 수 있었다.
하지만 요청을 잘못 이해하면 그럴듯한 오답도 내놓았다. 존재하지 않는 함수가 만들어지고, 실제구조와 다른 파일 경로가 제안되기도 했다. 코드는 유창해 보였지만 실행하면 실패했다. 민준은 중요한 원칙을 세웠다. 인공지능에게 시스템을 상상하게 하지 말고, 실제 규칙을 알려 주자.
그는 짧은 문서를 만들었다. 폴더 구조, 훅의 사용법, 플러그인 작성 규칙, 금지해야 할 코어 수정, 실제 예제. 한 번에 모든 내용을 쏟아붓는 대신 단계별로 나누었다. 작은 지침을 주고, 결과를 확인하고, 오류를 기록한 뒤 다음 단계로 넘어갔다.
인공지능은 이제 마법사가 아니라 새로운 동료가 되었다. 빠르게 초안을 만들 수 있지만, 설계의 책임과 검증의 책임까지 대신해 주지는 않았다. 민준은 테스트 환경에서 실행하고, 기존 기능이 깨지지 않았는지 확인하고, 보안과 호환성을 살폈다.
“도구가 강해질수록 규칙은 더 중요해지는군.”
그는 웃으며 말했다. DXCMS의 구조가 명확할수록 인공지능은 더 유용해졌다. 잘 정리된 기반은사람뿐 아니라 기계에게도 길을 보여 주었다.
DXCMS 소설·07 / 10
8장. 화려함보다 오래가는 것
어느 날 디자인 회의에서 젊은 기획자가 화려한 애니메이션과 복잡한 화면을 제안했다. 화면은 멋졌지만, 민준은 질문을 멈추지 않았다. 저사양 기기에서도 빠르게 열릴까? 오래된 브라우저 환경에서는 어떨까? 운영자가 콘텐츠를 늘리면 레이아웃은 유지될까? 접근성과 검색엔진은 고려했을까?
그는 디자인을 싫어하는 사람이 아니었다. 오히려 디자인은 중요하다고 믿었다. 다만 멋진 첫인상과 지속 가능한 운영이 서로 싸우게 만들고 싶지 않았다. 기본 테마는 단정하고 빠르게, 확장 테마는 더 풍부하게. 게시판 스킨은 콘텐츠의 성격에 맞게 바꿀 수 있도록. 기능과 표현은 분리하되, 전체 경험은 하나로 이어지게 만들고 싶었다.
그들은 색을 줄이고 여백을 다듬었다. 제목과 본문을 명확히 구분하고, 정보가 많아져도 화면이 무너지지 않도록 구성했다. 꼭 필요한 움직임만 남겼다. 작은 화면에서는 중요한 정보가 먼저 보이게했다.
완성된 페이지는 처음 제안보다 덜 요란했다. 대신 오래 보아도 피곤하지 않았다. 운영자가 새 게시판을 추가해도 전체 디자인이 흔들리지 않았다.
민준은 화면을 바라보며 생각했다. 디자인은 눈길을 끄는 기술인 동시에, 사람의 시간을 아껴 주는기술이었다. 좋은 시스템은 사용자에게 자기 존재를 과시하지 않는다. 사용자가 해야 할 일을 더 쉽게 해 줄 뿐이다.
DXCMS 소설·08 / 10
9장. 혼자 만든다는 것
밤이 깊어질수록 민준은 자신이 얼마나 많은 일을 혼자 감당하고 있는지 깨달았다. 개발, 디자인, 문서, 고객 응대, 서버 관리. 새 기능을 만들면 테스트해야 했고, 테스트를 끝내면 안내문을 써야 했다. 그리고 다음 날에는 생계를 위한 본업도 기다리고 있었다.
그는 가끔 모든 것을 멈추고 싶었다. 시장은 빠르게 변했고, 비슷한 도구는 매일 등장했다. 누구나쉽게 웹사이트를 만들 수 있다면, 자신이 만든 CMS가 여전히 필요할까? 질문은 밤마다 돌아왔다.
그러던 어느 날, 이용자가 작은 수정 사항을 제보했다. 민준이 고쳐서 패치하자 다른 이용자도 같은문제를 해결할 수 있었다. 한 사람의 보고가 여러 사이트의 안정성을 높였다. 커뮤니티의 힘은 거창한 후원이나 칭찬에서만 생기지 않았다. 정확한 재현 방법 하나, 테스트 결과 한 줄, 서로를 존중하는 댓글 하나에서도 시작됐다.
민준은 일정을 다시 정리했다. 모든 기능을 한꺼번에 완성하려 하지 않기로 했다. 생계를 지키고, 잠을 자고, 할 수 있는 만큼 꾸준히 이어 가기로 했다. 프로젝트가 삶을 집어삼키면 오래 지속할 수없었다.
그는 개발 노트에 마지막으로 한 줄을 적었다.
‘지속 가능성은 서버에만 필요한 것이 아니다. 만드는 사람에게도 필요하다.’
그 문장은 어떤 코드보다 오래 마음에 남았다.
DXCMS 소설·09 / 10
10장. 다음 버전의 아침
아침 햇살이 사무실 바닥에 길게 들어왔다. 밤새 작업한 패치가 테스트 서버에서 무사히 작동했다.
모든 문제가 사라진 것은 아니었다. 새로운 환경은 나타날 것이고, 보안 이슈는 다시 발견될 것이며, 이용자는 지금까지 생각하지 못한 기능을 요청할 것이다.
민준은 그 사실이 더는 두렵지 않았다. DXCMS를 완성된 성벽으로 만들겠다는 생각을 버린 뒤, 그는 그것을 고쳐 가며 살아가는 기반으로 바라보게 되었다. 핵심은 안정적으로 지키고, 필요한 기능은 확장으로 더하고, 운영에서 얻은 교훈은 문서와 패치로 돌려준다. 그것이 그가 선택한 방식이었다.
그는 새 버전의 공지 초안을 열었다. 변경 사항을 과장하지 않고, 해결한 문제와 남아 있는 조건을구분해 적었다. 마지막에는 이용자들에게 감사의 말을 덧붙였다. 이 시스템은 혼자 만들었을지 몰라도, 실제로 성장하는 과정에는 많은 사람의 질문과 경험이 들어 있었다.
창밖의 도시는 이미 움직이고 있었다. 누군가는 새 사이트를 만들고, 누군가는 오래된 게시판을 정리하고, 누군가는 처음으로 플러그인에 도전할 것이다. 민준은 그들이 조금 덜 헤매고, 조금 더 안전하게, 자신이 원하는 서비스를 만들 수 있기를 바랐다.
그는 저장 버튼을 눌렀다.
DXCMS의 다음 버전은 아직 완성되지 않았다. 그러나 그건 실패가 아니었다. 다음에 고칠 수 있다
는 것, 다른 사람이 확장할 수 있다는 것, 어제의 선택을 오늘 다시 검증할 수 있다는 것. 그 가능성이야말로 이 프로젝트가 계속 살아 있는 이유였다.
모니터 한쪽에 작은 문장이 남아 있었다.
‘핵심은 지키고, 가능성은 확장한다.’
민준은 커피를 한 모금 마시고 새 작업을 열었다. 또 하루가 시작되고 있었다.
DXCMS 소설·10 / 10
이젠 읽지마세요. 들으세요^^
