22557e7132
- 7-8월 초기 구축 문서 12개를 _archive/troubleshooting/2025_07-08_initial_setup/로 이동 - book/300_architecture/390_human_in_the_loop_intent_learning.md를 journey/research/intent_classification/로 이동 (개발 여정 문서) - 빈 폴더 제거 (journey/assets/*)
163 lines
4.7 KiB
Markdown
163 lines
4.7 KiB
Markdown
# 프론트엔드-백엔드 연결 및 Company → Workspace 전환
|
|
|
|
**날짜**: 2025-07-30
|
|
**작업자**: happybell80 & Claude
|
|
**관련 프로젝트**: frontend-customer, auth-server
|
|
|
|
## 오전 10시 30분
|
|
|
|
### 프론트엔드 모바일 뷰포트 문제 해결
|
|
|
|
**문제점**:
|
|
- 모바일에서 채팅창이 16:9 비율로 고정되어 본문이 2-3개 메시지만 표시됨
|
|
- `aspect-video` 클래스로 인한 높이 제한
|
|
|
|
**해결 방안** (Sequential Design 분석):
|
|
1. 모바일에서 aspect-video 제거
|
|
2. 전체 높이 활용하도록 변경
|
|
3. 최대 너비 600px, 최소 높이 300px 설정
|
|
|
|
**수정 내용**:
|
|
```tsx
|
|
// game-layout.tsx
|
|
// 변경 전
|
|
<div className="w-full aspect-video max-h-full">
|
|
|
|
// 변경 후
|
|
<div className="w-full h-full min-h-[300px] max-w-[600px] mx-auto">
|
|
```
|
|
|
|
**추가 최적화**:
|
|
- 채팅 인터페이스 패딩/간격 모바일 최적화
|
|
- 헤더, 메시지, 입력창 컴팩트하게 조정
|
|
|
|
## 오전 10시 45분
|
|
|
|
### 프론트엔드-백엔드 연결 아키텍처 재검토
|
|
|
|
**초기 잘못된 이해**:
|
|
- 각 로빙이 자체 프론트엔드를 포함한다고 생각
|
|
- 로빙 컨테이너 내부에 프론트엔드를 통합하려 시도
|
|
|
|
**올바른 아키텍처**:
|
|
```
|
|
51123 서버 (프론트엔드)
|
|
├── frontend-customer (중앙 집중식)
|
|
├── 항상 켜져있음
|
|
└── 여러 로빙 API와 통신
|
|
|
|
51124 서버 (로빙들)
|
|
├── rb8001 (경량 API only)
|
|
├── rb10508_test (경량 API only)
|
|
├── rb10408 (경량 API only)
|
|
└── 레벨업 시 재시작 가능
|
|
```
|
|
|
|
**핵심 이유**:
|
|
1. 로빙 레벨업 시 컨테이너 재시작 → 프론트엔드 끊김 방지
|
|
2. 로빙 컨테이너 경량화 유지
|
|
3. UX 연속성 보장
|
|
|
|
## 오전 11시 00분
|
|
|
|
### 사용자-로빙 매핑 플로우 설계
|
|
|
|
**Sequential Design 분석 결과**:
|
|
- 현재 auth-server에 사용자-로빙 매핑 테이블 없음
|
|
- 개별 사용자 정보 저장 테이블 없음
|
|
- JWT/세션 기반 인증만 존재
|
|
|
|
**필요한 DB 확장**:
|
|
1. `users` 테이블: 개별 사용자 정보
|
|
2. `workspace_member` 테이블: 사용자-워크스페이스-로빙 매핑
|
|
3. `workspaces` 테이블: company 테이블 이름 변경
|
|
|
|
**개발 우선순위**:
|
|
1. auth-server 데이터 모델 확장
|
|
2. 로빙 할당 API 구현
|
|
3. 프론트엔드 Auth Context 확장
|
|
4. 프론트엔드-로빙 연결
|
|
|
|
## 오전 11시 15분
|
|
|
|
### Company → Workspace 용어 변환
|
|
|
|
**변환 이유**:
|
|
- "Company"는 개인 사용자에게 부적합
|
|
- "Workspace"는 개인/기업 모두에게 자연스러움
|
|
- Slack, Notion 등 이미 검증된 용어
|
|
|
|
**DB 모델 생성**:
|
|
1. `app/models/user.py` - User, WorkspaceMember 모델
|
|
2. `app/models/workspace.py` - Workspace 모델 (Company 대체)
|
|
3. `migrations/add_user_workspace_tables.sql` - 마이그레이션 SQL
|
|
|
|
**새로운 테이블 구조**:
|
|
```sql
|
|
-- users 테이블
|
|
CREATE TABLE user (
|
|
id UUID PRIMARY KEY,
|
|
email VARCHAR(255) UNIQUE NOT NULL,
|
|
name VARCHAR(255),
|
|
oauth_provider VARCHAR(50),
|
|
...
|
|
);
|
|
|
|
-- workspace_member 테이블
|
|
CREATE TABLE workspace_member (
|
|
workspace_id UUID REFERENCES workspaces(id),
|
|
user_id UUID REFERENCES user(id),
|
|
role VARCHAR(50),
|
|
robeing_id VARCHAR(100), -- 할당된 로빙
|
|
...
|
|
);
|
|
```
|
|
|
|
## 오전 11시 25분
|
|
|
|
### Company → Workspace 변환 작업
|
|
|
|
**Sequential Design 분석으로 영향받는 파일 파악**:
|
|
1. `app/api/company.py` → `app/api/workspaces.py`
|
|
2. `app/providers/slack.py` - OAuth 처리
|
|
3. `app/api/slack_router.py` - Slack 이벤트 라우팅
|
|
4. `app/db/init_db.py` - DB 초기화
|
|
5. `app/main.py` - 라우터 등록
|
|
|
|
**변환 작업**:
|
|
1. `company.py` 파일 삭제
|
|
2. 모든 import 문 변경
|
|
3. 변수명/함수명 변경 (company → workspace)
|
|
4. API 엔드포인트 경로 변경
|
|
|
|
**API 엔드포인트 변경**:
|
|
```
|
|
/api/company → /api/workspaces
|
|
/api/company/{company_id} → /api/workspaces/{workspace_id}
|
|
/api/company/subdomain/{subdomain} → /api/workspaces/subdomain/{subdomain}
|
|
```
|
|
|
|
## 교훈
|
|
|
|
1. **아키텍처 이해의 중요성**
|
|
- 초기에 잘못 이해하면 큰 시간 낭비
|
|
- 프론트엔드와 백엔드 분리 이유를 명확히 파악
|
|
- 컨테이너 재시작과 UX 연속성 고려
|
|
|
|
2. **Sequential Design의 효과**
|
|
- 체계적인 분석으로 누락 요소 발견
|
|
- 의존성 파악으로 올바른 개발 순서 결정
|
|
- 영향 범위 파악으로 안전한 변환
|
|
|
|
3. **용어 선택의 중요성**
|
|
- 개인/기업 모두를 포괄하는 용어 선택
|
|
- 업계 표준 용어 사용 (Workspace)
|
|
- 일관성 있는 변환 작업
|
|
|
|
4. **DB 설계 우선**
|
|
- 데이터 모델이 없으면 기능 구현 불가
|
|
- 사용자-로빙 매핑은 핵심 요구사항
|
|
- 마이그레이션 스크립트 미리 준비
|
|
|
|
---
|
|
**작성 완료**: 2025-07-30 11:30 |