# TN Site Architecture

## 결정 요약

`tn-site`를 차기 TN Silver 웹 시스템의 단일 저장소로 사용한다. 저장소는
하나로 운영하되 공개 홈페이지와 내부 대시보드는 서로 다른 애플리케이션과
배포 단위로 유지한다.

- `www.tnsilver.com`: 고객에게 공개되는 홈페이지
- `dashboard.tnsilver.com`: 직원만 접근하는 조회 전용 운영 현황판

`dashboard`는 고객 포털이나 업무 처리 시스템이 아니다. 방문 현황과 접수된
문의의 목록·상세를 확인하는 단일 화면을 기본 범위로 한다. 고객과의 대화,
문의 답변, 상태 변경, 삭제, 고객 계정과 프로필, 직원 권한 관리 기능은 이전하지
않는다.

## 현재 단계의 경계

현재 홈페이지 리모델링은 완료되지 않았다. 따라서 `prototype/`을 승인 전까지
계속 디자인과 동작의 기준으로 유지하며, 지금 생산 프레임워크나 워크스페이스를
미리 만들지 않는다.

- `prototype/`의 정적 HTML, CSS, JavaScript 작업을 계속한다.
- 현재 운영 중인 `../tn-home`과 `../tn-portal`은 전환 전까지 변경하지 않는다.
- 운영 도메인, 데이터베이스 계약과 마이그레이션 소유권도 당장 변경하지 않는다.
- 아래 목표 구조는 생산 구현 전환이 명시된 뒤 단계적으로 만든다.

## 목표 저장소 구조

```text
tn-site/
├── prototype/              승인 전까지 유지하는 홈페이지 시안
├── apps/
│   ├── dashboard/          dashboard.tnsilver.com
│   └── www/                www.tnsilver.com
├── packages/
│   └── contracts/          실제로 공유되는 문의·분석 타입과 검증 규칙
├── supabase/               전환 후 유일한 DB 마이그레이션 원본
└── docs/                   결정, 전환 기준과 운영 구조
```

빈 공통 패키지를 미리 만들지 않는다. 두 앱에서 실제로 함께 사용하는 데이터
계약이 확인될 때만 `packages/contracts`로 올린다. 공개 홈페이지와 내부
대시보드는 화면 목적과 보안 경계가 다르므로 UI와 애플리케이션 세션 코드는
기본적으로 공유하지 않는다.

## 애플리케이션 책임

### `apps/www`

- 승인된 공개 홈페이지 렌더링과 탐색
- 문의 접수, 입력 검증과 첨부파일 처리
- 관리자 알림 이메일과 실패 재처리
- 공개 홈페이지 방문 분석 수집
- 고객용 `문의 내역`을 유지하기로 결정한 경우 안전한 본인 확인과 조회

공개 사용자의 데이터 쓰기는 `www`만 소유한다. 공개 `문의 내역`의 유지 여부와
접근 방식은 생산 구현 전에 별도 확정한다.

### `apps/dashboard`

- 사전 등록된 직원의 인증
- 방문·전환·문의 접수 현황 조회
- 문의 목록, 검색·기간 필터와 상세 조회
- 필요할 경우 첨부파일의 안전한 열람

페이지는 단일 진입점 `/`을 기본으로 하고 기간, 필터와 선택 항목은 URL 검색
파라미터로 보존한다. 단일 페이지라고 해서 모든 원본 데이터를 한 번에 내려받지
않으며 집계와 목록은 서버에서 기간·페이지 단위로 조회한다.

조회 전용 원칙은 버튼을 숨기는 수준이 아니라 서버와 데이터베이스 권한으로
보장한다. 브라우저에 관리용 키를 제공하지 않고, 대시보드 서버는 대시보드 전용
읽기 View/RPC를 통해서만 데이터에 접근한다. 로그인과 로그아웃을 제외한 데이터
변경 API는 두지 않는다.

## 배포 경계

두 앱은 같은 Git 저장소와 변경 이력을 사용하지만 배포는 결합하지 않는다.

- Vercel 프로젝트, 도메인과 환경변수를 앱별로 분리한다.
- 홈페이지 배포 실패가 대시보드에 영향을 주지 않도록 한다.
- 대시보드 인증 정보와 읽기 권한을 `www`의 공개 환경과 분리한다.
- 데이터베이스 마이그레이션은 한 위치에서만 실행한다.
- `dashboard.tnsilver.com`은 공개 사이트의 주 탐색에 노출하지 않는다.

별도 저장소로 다시 분리하는 것은 대시보드가 독립 제품이 되거나, 전담 조직과
독립 배포 주기 또는 별도의 규제·보안 경계를 갖게 될 때만 재검토한다.

## 단계적 전환

### 1. Prototype 유지

- 일곱 개 공개 페이지와 반응형·상호작용·중요 상태를 먼저 완성한다.
- `prototype/`을 생산 앱으로 옮기거나 프레임워크 문법으로 중간 변환하지 않는다.
- 기존 홈페이지와 포털이 계속 운영 트래픽을 처리한다.

### 2. Dashboard 우선 이전

생산 구현 시작이 명시되면 홈페이지 완성과 독립적으로 `apps/dashboard`를 먼저
만들 수 있다.

- 기존 `tn-portal`의 분석 조회와 문의 조회 로직만 선별해서 이전한다.
- 고객 포털, 상담, 답변, 상태 변경, 삭제와 직원 관리 화면은 복사하지 않는다.
- 기존 운영 Supabase의 현재 스키마를 읽기 전용으로 사용한다.
- 검증 후 `dashboard.tnsilver.com`을 연결하고 기존 `portal.tnsilver.com`은
  짧은 안내 또는 리다이렉트 기간을 거쳐 종료한다.

이 단계에서는 `../tn-home/supabase`를 마이그레이션 원본으로 유지한다. 같은
마이그레이션 파일을 두 저장소에서 동시에 관리하지 않는다.

### 3. WWW 생산 구현

홈페이지 시안이 승인되고 생산 전환이 명시되면 `apps/www`를 만든다.

- 승인된 시안을 시각·동작 기준으로 보존한다.
- 그 시점의 SEO, 접근성, 성능과 서버 요구를 기준으로 생산 스택을 확정한다.
- 기존 `tn-home`에서 문의 접수, 파일, 이메일, 분석 수집 등 필요한 운영 코드만
  선별 이전한다.
- 폐기하기로 한 고객 포털 기능을 호환 목적으로 다시 만들지 않는다.

### 4. 소유권과 도메인 전환

- 전체 Supabase 마이그레이션 이력을 `tn-site/supabase`로 이전한다.
- 이전 시점부터 `tn-site/supabase`만 새 마이그레이션을 소유한다.
- 새 `www`가 운영 트래픽을 받을 준비가 되면 도메인을 전환한다.
- 롤백 기간이 끝난 뒤 `tn-home`과 `tn-portal`을 읽기 전용 보관 처리한다.

## 생산 전환 게이트

`apps/www` 구현은 최소한 다음 항목이 합의된 후 시작한다.

- 필요한 공개 페이지와 URL 목록
- 데스크톱·모바일 레이아웃
- 탐색 구조와 핵심 상호작용
- 이미지, 영상, 폰트 등 최종 자산
- 로딩, 비어 있음, 오류와 제출 완료 상태
- 공개 `문의 내역`의 유지 여부와 본인 확인 방식
- 시안 승인 기준과 운영 전환 시 롤백 방법

`apps/dashboard`는 공개 홈페이지의 시각 승인과 무관하게 시작할 수 있지만,
조회 대상과 보존 기간, 직원 인증 방식, 읽기 전용 권한 검증이 먼저 확정되어야
한다.