고객용 사이트와 관리자 페이지, 모노리포로 만들면 좋은 이유

처음에는 고객에게 보여줄 랜딩페이지 하나만 만듭니다.

서비스를 소개하고 문의 폼이나 신청서를 붙여요. 문의가 들어오기 시작하면 곧 다음 기능이 필요해집니다.

새 문의 목록 보기
이름과 연락처로 검색하기
담당자 지정하기
상담 중·완료로 상태 바꾸기
상담 메모 남기기

이제 고객용 사이트와 목적이 전혀 다른 관리자 페이지가 필요한 상황입니다.

두 화면은 같은 문의 데이터를 사용하지만 이용자와 화면의 목적은 달라요. 이럴 때 고려할 수 있는 프로젝트 구조가 모노리포(monorepo)입니다.

조금 기술적인 용어지만 핵심은 단순합니다.

고객용 사이트와 관리자 페이지를 각각 독립된 앱으로 만들되, 하나의 프로젝트 안에서 함께 관리하는 방식입니다.

다만 고객용 화면과 관리자 화면이 있다는 이유만으로 반드시 모노리포를 사용해야 하는 것은 아닙니다. 언제 사용하면 좋은지 장단점과 함께 살펴볼게요.

화면, 서버와 데이터베이스가 어떻게 연결되는지 먼저 알고 싶다면 웹 애플리케이션의 기본 구조를 함께 읽어보세요.

수강생 프로젝트에서 자주 마주치는 구조예요

뚝딱 클로드코드 강의에서 수강생들의 개인 프로젝트를 함께 만들다 보면 고객용 사이트와 관리자 사이트를 나눠야 하는 경우가 많습니다.

처음에는 고객이 서비스를 확인하고 문의나 신청을 남기는 화면으로 시작해요. 실제 문의가 들어오기 시작하면 운영자가 전체 내역을 보고 상태를 바꾸거나 메모를 남길 별도의 화면이 필요해집니다.

공방 예약 사이트
→ 고객은 수업을 예약
→ 운영자는 예약과 정원을 관리

전문가 상담 사이트
→ 고객은 상담을 신청
→ 운영자는 문의를 배정하고 처리

온라인 콘텐츠 사이트
→ 고객은 콘텐츠를 이용
→ 운영자는 콘텐츠와 회원을 관리

고객과 운영자는 같은 데이터를 사용하지만 필요한 화면과 행동은 전혀 다릅니다. 그래서 개인 프로젝트가 실제 운영 단계로 넘어갈 때 두 화면을 어떻게 나눌지가 중요한 결정이 돼요.

뚝딱도 마찬가지입니다. 고객이 강의와 프로그램을 확인하고 신청하는 홈페이지와, 문의·신청·결제·수강생을 관리하는 내부 관리자 페이지를 별도 앱으로 나눠 운영하고 있어요. 두 앱은 독립적으로 움직이지만 같은 데이터와 업무 규칙을 사용하기 때문에 하나의 모노리포에서 함께 관리합니다.

모노리포를 추천하는 이유는 단순히 요즘 많이 쓰는 구조이기 때문이 아닙니다. 수강생 프로젝트와 뚝딱을 실제로 운영하면서, 분리된 두 화면을 함께 고칠 일이 계속 생겼기 때문입니다.

모노리포는 여러 앱을 한곳에서 관리하는 방식이에요

고객용 사이트와 관리자 페이지를 완전히 다른 프로젝트로 만들 수도 있습니다.

고객용 사이트 프로젝트
관리자 페이지 프로젝트

모노리포에서는 두 앱과 함께 사용하는 코드를 하나의 프로젝트에 둡니다.

my-service
├─ apps
│  ├─ web       고객용 사이트
│  └─ admin     관리자 페이지
└─ packages     두 앱이 함께 사용하는 코드

한 프로젝트 안에 있다고 하나의 앱이 되는 것은 아닙니다. 고객용 사이트와 관리자 페이지는 따로 실행하고 별도로 배포할 수 있어요.

www.example.com
→ 고객용 사이트

admin.example.com
→ 관리자 페이지

두 앱의 화면은 나누면서 같은 데이터 기준과 업무 규칙은 함께 관리하는 것이 모노리포의 핵심입니다.

왜 고객용 사이트와 관리자 페이지에 잘 맞을까요?

두 화면은 서로 다른 앱처럼 보이지만 실제로는 같은 업무의 앞면과 뒷면인 경우가 많습니다.

고객용 사이트
→ 고객이 문의를 등록

데이터베이스
→ 문의 내용을 저장

관리자 페이지
→ 운영자가 문의를 확인하고 처리

고객용 사이트에서 받은 이름, 연락처와 문의 내용이 관리자 페이지에 그대로 나타나야 합니다. 관리자가 상태를 새 문의에서 상담 중, 완료로 바꾸면 두 화면과 데이터베이스가 같은 의미를 이해해야 해요.

완전히 다른 프로젝트로 관리하면 같은 기준을 두 곳에 반복해서 만들기 쉽습니다. 한쪽에서는 완료, 다른 쪽에서는 처리됨을 사용하면서 조금씩 어긋날 수도 있어요.

모노리포에서는 같아야 하는 기준을 함께 관리해 이런 차이를 줄일 수 있습니다.

모노리포의 장점

같은 데이터와 규칙을 함께 사용할 수 있어요

문의에 어떤 정보를 저장하고 어떤 상태를 사용할지 한곳에서 정할 수 있습니다.

문의
- 이름
- 연락처
- 문의 내용
- 처리 상태
- 담당자
- 접수 시각

새로운 담당자 항목이 생겼다면 문의 저장 기능과 관리자 화면을 한 작업에서 함께 수정할 수 있어요.

관련된 기능을 한 번에 확인하기 쉬워요

문의 분류 기능을 추가한다고 해볼게요.

문의 폼에 분류 선택 추가
→ 문의 데이터에 분류 저장
→ 관리자 목록에 분류 표시
→ 분류별 검색 기능 추가

모노리포에서는 이 전체 흐름이 한 프로젝트 안에 있습니다. 일부만 수정하고 나머지를 빠뜨릴 가능성을 줄일 수 있어요.

클로드코드에도 “문의가 등록된 뒤 관리자 화면에 나타날 때까지 전체 흐름을 확인해줘”라고 요청하기 편합니다.

화면은 목적에 맞게 나눌 수 있어요

고객용 사이트와 관리자 페이지는 필요한 화면이 다릅니다.

별도 앱으로 만들면 각 목적에 맞게 개발하고 배포할 수 있습니다. 동시에 날짜 표시나 문의 상태처럼 같아야 하는 기준은 함께 사용할 수 있어요.

모노리포의 장점은 모든 것을 합치는 데 있지 않습니다. 나눠야 할 화면은 나누고, 같아야 할 기준은 함께 관리하는 데 있습니다.

모노리포의 단점

처음 구조가 조금 더 복잡해요

앱이 하나일 때보다 폴더와 실행 명령어가 늘어납니다.

고객용 사이트는 어떻게 실행하나요?
관리자 페이지는 어떻게 실행하나요?
두 앱이 함께 쓰는 코드는 어디에 있나요?

AI가 만들어준 구조를 이해하지 않고 사용하면 문제가 생겼을 때 어느 앱을 확인해야 하는지 헷갈릴 수 있어요.

한쪽의 변경이 다른 쪽에도 영향을 줄 수 있어요

함께 사용하는 문의 상태나 데이터 구조를 바꾸면 고객용 사이트와 관리자 페이지를 모두 확인해야 합니다.

같은 기준을 유지할 수 있다는 장점이지만, 작은 변경도 확인할 범위가 넓어질 수 있다는 뜻이기도 해요.

모든 코드를 공유하려 하면 오히려 불편해요

고객용 버튼과 관리자용 버튼은 모양과 목적이 다를 수 있습니다. 비슷해 보인다는 이유로 무조건 하나로 합치면 나중에는 수정하기 더 어려워져요.

함께 관리하기 좋은 것
→ 데이터의 기준, 문의 처리 규칙, 날짜·전화번호 형식

각 앱에 남겨두기 좋은 것
→ 화면 구성, 앱별 디자인, 한 번만 사용하는 기능

정말 같은 규칙만 공유하고, 각 화면에만 필요한 코드는 따로 두는 편이 좋습니다.

이런 경우에는 모노리포를 추천해요

다음 조건이 여러 개 겹친다면 모노리포가 잘 맞습니다.

• 고객용 사이트와 관리자 페이지를 별도로 배포하고 싶습니다.
• 두 앱이 같은 문의, 예약, 주문이나 회원 데이터를 사용합니다.
• 문의를 넘어 결제나 콘텐츠 관리 기능이 늘어날 예정입니다.
• 고객용 화면과 관리자 화면의 로그인·권한·디자인이 분명히 다릅니다.
• 기능 하나를 바꿀 때 두 화면을 함께 수정하는 일이 자주 생깁니다.

특히 이미 고객용 랜딩페이지가 있고, 문의를 조회·검색·배정·상태 변경하는 독립적인 관리자 도구를 새로 만든다면 모노리포를 검토하기 좋은 시점입니다.

작은 관리자 기능이라면 한 앱으로 시작해도 괜찮아요

관리자 페이지가 있다는 이유만으로 앱을 나눌 필요는 없습니다.

다음과 같은 상황에서는 하나의 앱 안에 /admin 페이지를 만드는 편이 더 단순할 수 있어요.

• 관리자가 한 명이고 문의량이 적습니다.
• 관리자 기능이 문의 목록과 메모 정도로 작습니다.
• 고객용 화면과 관리자 화면을 함께 배포해도 괜찮습니다.
• 앞으로 기능이 커질지 아직 알 수 없습니다.

하나의 앱
├─ /             고객용 랜딩페이지
├─ /contact      문의 등록
└─ /admin        관리자 페이지

처음에는 한 앱으로 운영 흐름을 확인하고, 관리자 기능이 커질 때 별도 앱으로 나눠도 됩니다.

반대로 곧 예약, 주문, 결제나 콘텐츠 운영까지 추가할 계획이 분명하다면 처음부터 모노리포로 나누는 편이 중간 이전 작업을 줄일 수 있어요.

관리자 화면에 어떤 기능이 필요한지는 관리자 페이지는 왜 필요할까요?에서 더 자세히 살펴볼 수 있습니다.

클로드코드에는 먼저 비교해달라고 요청하세요

기존 랜딩페이지가 있는데 곧바로 “모노리포로 바꿔줘”라고 요청하면 많은 파일과 설정을 한꺼번에 바꿀 수 있습니다.

먼저 현재 프로젝트를 확인하고 두 방식을 비교하게 하세요.

현재 고객용 랜딩페이지에 문의 접수 기능이 있고,
같은 문의 데이터를 관리할 관리자 페이지를 추가하려고 해.

아직 코드를 수정하지 말고 현재 프로젝트 구조를 먼저 확인해줘.

아래 두 방식을 비교해줘.
1. 현재 앱 안에 /admin 페이지를 추가하는 방식
2. 고객용 앱과 관리자 앱을 나눈 모노리포 방식

각 방식의 장단점과 변경 범위를 쉽게 설명하고,
현재 프로젝트에 더 적합한 방식을 추천해줘.

모노리포를 추천한다면
함께 사용할 코드와 각 앱에 남길 코드를 나누고
단계별 작업 계획을 만들어줘.

계획을 확인한 뒤 구현을 요청합니다.

검토한 계획대로 모노리포로 전환해줘.

목표 구조:
- apps/web: 기존 고객용 사이트
- apps/admin: 문의 관리용 관리자 페이지
- packages: 두 앱이 함께 사용하는 코드

요구사항:
- 기존 고객용 사이트의 기능을 유지해줘.
- 고객용 사이트와 관리자 페이지를 따로 실행할 수 있게 해줘.
- 관리자 페이지는 로그인한 운영자만 접근하게 해줘.
- 화면 코드를 무조건 공용으로 만들지 말고,
  정말 함께 사용해야 하는 데이터와 규칙만 공유해줘.
- 한 번에 크게 바꾸지 말고 작은 단계로 작업해줘.
- 작업 후 두 앱이 정상적으로 실행되는지 확인해줘.

먼저 예상 변경 내용과 작업 순서를 보여준 뒤 시작해줘.

이미 모노리포를 만든 뒤에는 수정할 앱의 범위를 분명하게 알려주세요.

관리자 앱에 문의 상세 화면과 상태 변경 기능을 추가해줘.

기존 고객용 문의 폼은 바꾸지 말고,
현재 문의 데이터와 처리 흐름을 먼저 확인해줘.

관리자는 새 문의를 상담 중 또는 완료로 바꿀 수 있고,
누가 언제 처리했는지 기록해줘.

작업 후 고객용 사이트와 관리자 페이지가
모두 정상적으로 작동하는지 확인해줘.

“관리자 페이지를 만들어줘”라고만 요청하기보다 고객이 입력한 정보가 어디에 저장되고 운영자가 어떻게 처리해야 하는지 함께 설명하면 결과가 좋아집니다.

프로젝트 구조와 반복되는 규칙은 CLAUDE.md에 정리해둘 수 있습니다. 사용법은 CLAUDE.md란?을 참고하세요.

만들 때 유의할 점

앱을 나눴다고 관리자 페이지가 자동으로 안전해지지는 않아요

관리자 페이지를 별도 앱과 주소로 만들었더라도 로그인과 권한 확인은 따로 구현해야 합니다.

관리자 메뉴를 화면에서 숨기는 것만으로는 부족해요. 일반 사용자가 관리자 기능을 직접 요청해도 서버에서 거부해야 합니다.

고객 화면과 관리자 화면이 같은 규칙을 사용하게 하세요

문의 상태를 바꾸거나 예약을 취소하는 규칙을 두 앱에서 따로 만들면 시간이 지나며 결과가 달라질 수 있습니다.

고객 화면의 취소
→ 예약 상태 변경

관리자 화면의 취소
→ 예약 상태 변경 + 안내 메시지 발송

같은 업무라면 같은 규칙을 사용하게 만들어야 일부 처리가 빠지지 않습니다.

공용 폴더를 너무 많이 만들지 마세요

처음부터 모든 코드를 종류별로 잘게 나누면 구조만 복잡해질 수 있습니다.

두 앱이 실제로 함께 사용하는 데이터와 업무 규칙부터 공용으로 두세요. 화면과 디자인은 반복되는 기준이 확인된 뒤 공유해도 늦지 않습니다.

각 앱의 실행과 배포 방법을 기록하세요

고객용 사이트와 관리자 페이지를 어떻게 실행하고 배포하는지 프로젝트 문서에 적어두세요.

고객용 사이트 실행 방법
관리자 페이지 실행 방법
전체 기능 확인 방법
각 앱에 필요한 환경변수
배포할 주소

클로드코드에도 작업을 마친 뒤 어떤 명령으로 확인해야 하는지 알려주면 실수를 줄일 수 있습니다.

정리

• 모노리포는 고객용 사이트와 관리자 페이지 같은 여러 앱을 하나의 프로젝트에서 함께 관리하는 방식입니다.
• 각 앱은 별도로 실행하고 배포하면서 같은 데이터와 업무 규칙을 사용할 수 있습니다.
• 기능 하나에 필요한 고객 화면과 관리자 화면의 변경을 함께 확인하기 쉽습니다.
• 대신 프로젝트 구조와 확인할 범위가 조금 더 복잡해집니다.
• 단순한 문의 목록 정도라면 한 앱의 /admin 페이지로 시작해도 충분합니다.
• 별도 배포와 권한이 필요하고 기능이 계속 늘어날 예정이라면 모노리포를 추천합니다.
• 클로드코드에는 바로 구조를 바꾸게 하지 말고, 현재 프로젝트를 조사하고 두 방식을 비교한 뒤 단계적으로 작업하게 하세요.

고객용 사이트가 서비스를 보여주는 매장이라면 관리자 페이지는 그 서비스를 운영하는 작업실입니다. 모노리포는 둘을 같은 방에 섞는 방식이 아니라, 각자의 공간은 나누면서 함께 쓰는 기준은 한곳에서 관리하는 방식에 가깝습니다.