지금껏 웹사이트를 만든다는 것은 곧 직접 구축한다는 의미였다.
서버를 준비하고 웹프로그램을 설치하고 데이터베이스를 구성했다.
디자인을 입히고 필요한 기능을 개발했다.
쇼핑몰이라면 상품, 장바구니, 주문, 결제, 회원 기능을 갖춰야 했고,
기업 홈페이지라면 게시판과 문의 기능을 붙였다.
국내에서는 그누보드와 영카트 같은 설치형 프로그램이 이런 시장에서 오랫동안 중요한 역할을 했다.
모든 것을 처음부터 개발하는 것보다 이미 만들어진 CMS나 쇼핑몰 솔루션을 설치한 뒤 필요한 부분을 수정하는 것이 훨씬 효율적이었기 때문이다.

하지만 지금은 서버가 무엇인지 몰라도 쇼핑몰을 운영할 수 있다.
FTP를 사용할 필요도 없고 데이터베이스를 직접 관리할 필요도 없다.
프로그램 업데이트나 서버 운영 역시 대부분 서비스 제공자의 영역이 되었다.
최근에는 여기에서 한 단계 더 나아가고 있다.
AI에게 원하는 서비스를 설명하면 화면을 만들고 기능을 구성하고 데이터 구조와 프로그램까지 만들어주는 서비스들이 등장하고 있다.
중요한 것은 특정 서비스가 유행하고 있다는 사실이 아니다.
더 근본적인 변화는 범용 웹사이트를 굳이 처음부터 자체 구축해야 할 이유가 점점 사라지고 있다는 것이다.

기업 홈페이지에는 회사 소개, 제품 소개, 공지사항, 문의 같은 기능이 들어간다.
쇼핑몰에서는 상품을 등록하고 장바구니에 담고 주문하고 결제하고 배송 상태를 확인한다.
이런 기능을 구현하는 것 자체가 개발이었다.
회원 시스템 하나를 제대로 만드는 것도 일이었고
게시판, 주문, 결제, 관리자 기능을 갖추려면 상당한 개발이 필요했다.
그래서 CMS와 쇼핑몰 솔루션이 등장했다.

이제는 여기서 다시 한 단계가 진행되고 있다.
회원, 게시판, 상품, 주문, 결제, 예약, 문의 같은 범용 기능 자체가 상품과 서비스가 되었다.
이런 기능을 사용하기 위해 반드시 프로그램을 설치하고 서버를 직접 운영해야 하는 시대가 아니다.

고객 입장에서는 자연스럽게 질문하게 된다.
이미 있는 것을 왜 다시 개발해야 하는가?
이 질문에 명확하게 답할 수 없는 자체 구축 프로젝트는 앞으로 점점 설 자리를 잃을 가능성이 크다.
그렇다고 웹 개발 자체가 사라지는 것은 아니다.
달라지는 것은 개발해야 할 대상이다.
평범한 쇼핑몰 화면을 만드는 것보다 그 회사의 물류·재고 시스템과 판매 시스템을 연결하는 일이 중요해지고,
평범한 기업 홈페이지를 만드는 것보다 고객 관리와 실제 업무 프로세스를 연결하는 일이 중요해진다.

예약도 마찬가지다.
날짜와 시간을 선택하고 신청을 받는 것만으로 끝난다면 상당 부분 범용화할 수 있다.
하지만 예약이 회원 등급, 결제, 보증금, 포인트, 일정, 알림, 현장 확인, 취소 정책, 정산과 연결되기 시작하면 더 이상 홈페이지에 붙어 있는 단순한 기능이라고 보기 어렵다.

범용적인 것은 이미 만들어진 서비스와 제품이 담당하고,
개발은 사업마다 다른 문제를 해결하는 쪽으로 이동하는 것이다.
전통적인 CMS에서는 하나의 사이트를 먼저 설치하고 그 안에 필요한 기능을 추가했다.
사이트가 중심이고 기능은 사이트에 종속되는 구조였다.

그러나 예약, CRM, 미디어 관리, 분석, 폼, 원장 같은 기능을 각각 독립된 기능으로 본다면 구조는 달라진다.
먼저 사이트를 만들고 기능을 붙이는 것이 아니라
필요한 기능을 선택하고 조합한 결과가 하나의 서비스가 된다.
이때 중요한 것은 특정 사이트의 소스코드가 아니라 각 기능이 어떻게 연결되고 데이터를 주고받을 것인지에 대한 Contract다.
여기서 Contract는 단순한 API 규격만을 의미하는 것이 아니라
데이터 형식, 이벤트, 권한, 확장 생명주기, 버전 호환성처럼 서로 독립된 기능들이 안정적으로 연결되기 위해 지켜야 하는 약속을 의미한다.

Core와 확장의 관계도 마찬가지다.
확장이 Core 내부 구현에 강하게 결합되어 있으면 Core가 변경될 때마다 영향을 받는다.
반대로 Core와 확장 사이의 Contract가 명확하고 안정되어 있다면 Core 내부가 계속 발전하더라도 확장은 Contract의 호환성에 집중할 수 있다.
사이트에 종속된 기능은 그 사이트와 수명을 함께하지만,
Contract를 통해 연결되는 독립적인 확장 기능은 여러 서비스에서 반복해서 사용할 수 있다.
예약, CRM, 미디어 관리, 분석, 경제·원장, 폼 같은 확장 기능이 각각 독립적으로 설치되고 업데이트될 수 있다면
특정 프로젝트를 위해 한 번 개발하고 버리는 소스가 아니라 하나의 제품이 된다.
여러 서비스에서 반복해서 사용되고,
실제 사용자의 요구가 다시 제품의 개선으로 돌아오는 구조도 가능해진다.

확장 기능들 사이의 공통 Contract와 API가 정착되면 독립된 제품들이 서로 연결되기 시작한다.
예약에서 발생한 고객 정보를 CRM이 활용하고,
예약 과정에서 발생한 보증금이나 포인트 변화를 원장이 기록할 수 있다.
폼으로 수집한 데이터를 다른 업무 기능이 사용할 수 있고,
미디어 관리 기능은 여러 모듈에서 사용하는 자산을 공통으로 제공할 수 있다.
분석 기능은 이렇게 연결된 서비스 곳곳에서 발생하는 데이터를 수집하고 분석할 수 있다.

이때부터 개발 방식 자체가 달라진다.
“사이트를 하나 제작한다”가 아니라 “필요한 업무 기능을 조립해서 하나의 서비스를 만든다.”
이것은 단순히 CMS에 확장 기능을 많이 설치한다는 의미와는 다르다.
중요한 것은 기능의 숫자가 아니라 각각의 기능이 특정 사이트에 종속되지 않고 얼마나 독립적인 제품으로 존재할 수 있는가,
그리고 서로 얼마나 안정된 Contract를 통해 결합할 수 있는가에 있다.

Core 역시 모든 기능을 직접 가지고 있을 필요가 없다.
안정된 실행 환경과 확장 체계, 권한, 공통 API와 Contract를 제공하고 실제 업무 기능은 독립적인 확장들이 담당할 수 있다.
그렇게 된다면 Core의 경쟁력은 얼마나 많은 기능을 기본으로 가지고 있느냐보다
얼마나 다양한 기능을 안정적으로 받아들이고 연결할 수 있느냐에서 나오게 된다.

AI가 웹사이트와 프로그램을 만드는 시대가 되면
인간이 직접 파일을 복사하고 설정을 변경하면서 사이트를 구축하는 과정의 가치는 더욱 낮아질 것이다.
사용자는 기술적인 구현 방법보다 자신이 원하는 결과를 이야기하게 될 것이다.
- “예약을 받고 싶다.”
- “예약한 고객을 CRM으로 관리하고 싶다.”
- “예약할 때 보증금을 받고 취소하면 반환하고 싶다.”
- “고객이 작성할 신청서를 추가하고 싶다.”
- “예약과 매출 데이터를 분석하고 싶다.”
사용자는 이것을 구현하기 위해 어떤 파일을 수정해야 하는지, 어떤 테이블을 만들어야 하는지 알 필요가 없다.
AI 역시 모든 기능을 매번 처음부터 새로 프로그래밍할 필요는 없다.
이미 검증된 예약, CRM, 원장, 폼 같은 기능이 존재하고 이들의 Contract가 명확하다면 필요한 기능을 선택하고 설정하고 연결하는 역할을 할 수 있다.
결제, 예약, 정산, 권한, 원장처럼 정확성과 안정성이 중요한 업무 로직을 서비스마다 처음부터 생성하고 다시 검증하는 것보다
이미 사용되고 검증된 기능을 가져와 조합하는 편이 더 합리적일 수 있다.

그래서 AI 시대에는 오히려 잘 정의된 Contract를 가진 독립적인 기능 단위가 더 가치 있는 자산이 될 가능성이 있다.
AI가 모든 것을 새로 만드는 것보다 검증된 기능을 이해하고 조립하는 것이 중요해지는 것이다.
이 변화는 CMS의 역할도 바꾼다.
과거에는 어떤 CMS를 사용할 것인지, 어떤 쇼핑몰 솔루션을 선택할 것인지가 중요했다. 하지만 사용자가 원하는 것은 CMS 그 자체가 아니다. 상품을 판매하고, 예약을 받고, 고객을 관리하고, 자신의 업무를 온라인에서 처리하는 것이다.
그 과정에서 CMS라는 단어가 한 번도 등장하지 않을 수도 있다.

따라서 앞으로 중요한 질문 역시 달라질 수 있다.
“어떤 CMS로 사이트를 만들 것인가?”에서
“어떤 확장 기능들을 어떤 Contract로 연결해서 이 서비스를 만들 것인가?”로 -

웹사이트 자체 구축이 완전히 사라지는 것은 아니다.
특별한 요구가 있는 시스템은 앞으로도 자체 개발될 것이고 기존 서비스로 해결할 수 없는 문제 역시 계속 존재할 것이다.
다만 평범한 홈페이지와 평범한 쇼핑몰, 이미 수없이 구현된 범용 기능까지 프로젝트마다 다시 구축해야 할 이유는 점점 약해지고 있다.
사라지고 있는 것은 웹사이트가 아니다.
범용 웹사이트를 매번 처음부터 ‘구축’해야 했던 이유다.
그리고 그 이유가 사라질수록 웹 개발의 중심도 사이트 제작에서 업무 기능의 제품화, 연결, 조합으로 이동하게 될 것이다.

- 💫Glitter Gim