왜 중앙 관리자 허브인가

사이드프로젝트가 하나씩 늘면 관리자 UI 도 하나씩 늘어납니다. 3 ~ 5 개가 되면 숫자로 보이는 비용이 세 군데서 쌓입니다.

1. 세 가지 비용

• 운영자 학습 — 도메인마다 사이드바 · 테이블 모양 · 검색 위치가 달라 "이 사이트에서는 어디가 추가 버튼이지?" 를 매번 다시 기억
• 개발자 보일러플레이트 — Next 프로젝트 초기화 + AuthGuard + OAuth + 테이블 페이지네이션을 프로젝트마다 한 번 더
• 감사 추적 분산 — 사고 조사 시 "어느 사이트 로그부터 뒤져야 하지?" 가 매번 문제

한 Next.js 앱이 여러 도메인 DB 에 직접 연결하면 셋 다 줄어듭니다.

2. "한 앱 · 여러 풀" 이 가능한 이유

PostgreSQL 풀은 pg 드라이버 레벨에서 여러 개 만들 수 있습니다. 한 풀은 한 DB 싱글톤.

export const blogPool = new Pool({ host: 'pg-blog', ... });
export const marketPool = new Pool({ host: 'pg-market', ... });
export const supabasePool = new Pool({ host: 'aws-0-sa-east-1.pooler.supabase.com', ... });

블로그 글 저장 · 마켓 유저 목록 · Supabase 에서 운영 통계 조회 — 각각이 풀 한 번씩 거쳐서 한 페이지 안에서 순차 수행.

3. 도메인 서비스 API 를 거치지 않음

"도메인 서비스가 이미 API 를 가지고 있으니 관리자 앱은 그 API 를 호출하면 된다" 가 흔한 답변. 그러나 관리자 기능은 대체로 도메인 서비스의 외부 API 와 관심사가 다름 (소프트 삭제 · 강제 병합 · 감사 필요한 작업). 관리자 전용 API 를 도메인 서비스에 또 만들면 두 배의 코드가 발생.

관리자 앱이 DB 풀에 직접 접속하면:

• 도메인 서비스는 사용자용 로직에 집중
• 관리자 앱은 자기가 필요한 쿼리만
• 감사 로그가 관리자 앱 단일 지점

4. 예외는 최소화

그래도 몇 가지는 도메인 서비스에 위임하는 편이 단순합니다.

• LLM 추론 — 로컬 GPU · API 키 · 스케줄러가 이미 있는 쪽
• 무거운 크롤러 — 외부 사이트 접속 · Playwright 브라우저 풀이 이미 있는 쪽
• 알림 발송 — FCM · SMTP 설정이 이미 있는 쪽

이들은 POST /api/internal/generate-horoscope 같은 내부 전용 endpoint 로 위임. 나머지 90 % 는 관리자 앱이 DB 직접.

하고픈 말

중앙 허브가 처음부터 필요한 건 아닙니다. 서비스 1 ~ 2 개일 때는 각 서비스 안의 hidden admin 페이지 한 장이 더 단순합니다. 3 번째 서비스가 생기고 "어제 그 유저 어디서 차단했지?" 를 헤매게 되는 순간이 허브 도입의 자연스러운 계기입니다.

Next

• 02-project-setup