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

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

처음에 던진 질문은 설계 상담이었습니다.

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

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

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

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

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

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

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

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

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

이것을 처음에 명확히 하지 않으면, 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년에 몇 번의 작업이기 때문에')
• 예외는 기준을 정하고 수를 줄인다