AI는 '무엇을 만들지 않을지'를 모른다. 사내 CMS를 '대장(台帳)'으로 한정하여 라이브 전환을 단언컨대 거절한 이야기 (Laravel)

고객에게 납품하는 홈페이지의 기능(블로그, 예약, LINE 연동 등)을 고객별로 관리하는 사내 CMS를 Claude Code와 함께 만들었습니다. 그 설계 과정에서 여러 번 효과를 본 것은, '이것은 만들지 않는다'라고 단언컨대 결정할 수 있는 상태로 만드는 것이었습니다.

첫 번째 질문: 멀티테넌트(Multi-tenant)로 할 것인가

처음에 던진 것은 설계에 대한 상담이었습니다.

고객(미용실, 마사지 샵 등 수십 개)에게 홈페이지를 납품하고 있습니다. 블로그, 예약, LINE 연동 등의 기능을 고객별로 ON/OFF하여 제공하고 싶습니다. 하나의 Laravel 앱으로 모든 고객을 관리하는 멀티테넌트 구조로 해야 할지, 아니면 고객별로 다른 앱을 배포해야 할지. 판단 기준을 정리해 달라고 요청했습니다.

돌아온 정리 내용 중 결정적인 두 가지는 다음과 같습니다:

• 디자인의 개별성: 소규모 매장 대상 제작은 건별로 디자인이 크게 다릅니다. 공통 테마으로 흡수하려고 하면, 테마 메커니즘 개발만으로도 몇 주가 걸립니다.
• 호스팅 비용: 개별 배포라면, 고객의 렌탈 서버(Sakura 등)에 둘 수 있고, 비용은 고객 부담으로 할 수 있습니다.

Claude Code의 결론은 다음과 같았습니다.

템플릿 리포지토리를 건별로 복제하여 개별 배포하고, 사내 CMS 측에서는 '어떤 고객에게 어떤 기능을 납품했는지'를 **대장(台帳)**으로 가집니다. 기능의 라이브 전환은 고객 사이트 쪽에서 수행합니다.

저는 '그 방침대로요. 사내 CMS는 대장이고, 매장 사이트는 복제해서 사용하는 틀이며, 기능의 라이브 전환은 고객 사이트 측에서 할게요'라고 단지 한마디로 답했을 뿐입니다.

'대장(台帳)'이란, 제어하지 않는다는 것

사내 CMS의 features / customer_features 테이블은 고객 사이트 기능을 제어하지 않습니다. 어디까지나 '이 고객의 사이트에는 예약 기능과 LINE 연동을 납품했다'는 기록일 뿐입니다.

// app/Services/FeatureLedgerService.php
/**
* 고객에게 기능 납품 상황을 기록한다(고객 사이트 본체의 동작은 전환하지 않고, 사내 대장만 업데이트).
...

주석에 '고객 사이트 본체의 동작은 전환하지 않는다'라고 쓰여 있습니다. 서비스의 내용은 updateOrCreate가 단 한 번입니다.

그래도 AI는 만들려고 한다

이것을 처음에 명확히 해두지 않으면, Claude Code는 친절함으로 '사내 CMS에서 API를 통해 고객 사이트 기능을 ON/OFF하는 메커니즘'을 만들기 시작합니다. 실제로 한 번 요점 정리 과정에 포함된 적도 있었습니다.

저는 '대장입니다. 라이브 전환은 안 합니다'라고 단언컨대 거절했습니다. 이유는 간단해서, 고객 수가 수십 개이고, 기능의 추가/삭제가 발생하는 것은 계약 변경 시에만 하기 때문입니다. 1년에 몇 번의 작업 때문에 고객 사이트에서 사내 CMS로 상시 통신을 설계할 의미가 없습니다.

AI는 '무엇을 만들지 않을지'를 모릅니다. 요구사항이 조금이라도 모호하면, 있으면 편리해 보이는 것을 추가합니다. 추가하는 것이 나쁜 것은 아닙니다. 다만, 작은 시스템에서는 추가한 부분이 그대로 유지보수의 부담이 됩니다.

'단언컨대 거절'할 수 있도록 준비하기

한마디로 막을 수 있었던 이유는 README의 서두에 역할 분담을 적어 두었기 때문입니다.

- 기능 관리(features / customer_features) ※고객 사이트 기능 ON/OFF의 '납품 기록 대장'.
라이브 전환은 고객 사이트 측에서 수행한다

README에 이 전제가 있기 때문에, 어떤 세션에서도 Claude Code는 처음에 그것을 읽습니다. '사내 CMS에 블로그 기능을 만들어줘'라고 잘못 요청해도, '블로그는 고객 사이트 쪽 기능이므로, 틀(雛形) 쪽에 구현해야 합니다'라고 답변해 오게 되었습니다.

예외는 단 하나로 만들기

'원칙은 대장'이지만, 예외가 하나 있습니다. Instagram 연동입니다. Meta 측의 앱 등록 및 심사를 고객별로 하는 것은 비현실적이므로, 사내 CMS가 하나의 Meta 앱으로 모든 고객의 Instagram 게시물을 중계합니다.

'원칙은 대장이고, 예외는 외부 서비스 중개가 필요한 기능만'이라는 선을 긋고 두면, 나중에 망설일 때 기준이 됩니다.

요약

• 설계 상담 시에는 선택지를 나열하게 하고,
  결정적인 관점(이번에는 디자인의 개별성과 호스팅 비용)으로 고른다 -
  '제어하지 않는다'는 것은,
  주석과 README에 '하지 않는다'고 적는다. AI는 쓰여 있지 않은 것을 친절함으로 추가한다 -
  거절은, 이유를 한 문장으로 덧붙이면 단언컨대 끝난다(이번에는 '1년에 몇 번의 작업이기 때문에')
• 예외는 기준을 정하고, 수를 줄인다

이 설계의 전체(대장과 템플릿 두 개의 리포지토리 구성, 템플릿을 git 브랜치로 배포하는 운영 방식, Instagram 연동 중계)는 Zenn에 정리했습니다.

토론