#2는 단순히 DB가 살아 있는지 확인하는 이슈가 아니라, 현재 8081 기준 백엔드 저장 구조를 운영 가능한 상태로 정리하는 이슈다. 사용자가 SQL을 직접 보지 않아도 현재 어떤 테이블이 실제 운영 데이터인지, 어떤 원본이 적재됐는지, 어떤 화면이 어떤 저장 구조를 읽는지 파악할 수 있어야 한다.
현재 기준
작업 기준 브랜치: work-8081
작업 기준 경로: .dev-worktree-8081
8081 backend는 FastAPI + PostgreSQL 구조로 동작 중
현재 DB에는 members, seat_maps, seat_positions, member_versions, seat_assignment_versions, integration_*, auth.* 등 운영 테이블이 존재
integration_binary_sources 테이블 생성 누락 이슈를 코드 기준으로 보완 중
허브에서 바로 확인 가능한 DB 상태 화면을 추가해 #2 범위를 구체화함
이번 차수 반영
/api/admin/db-status 추가
핵심 운영 테이블 row 수
최근 갱신 시각
import batch 상태
바이너리 원본 보관 상태
/admin/db-status 화면 추가
허브 상단 DB 상태 탭에서 접근 가능
SQL 없이 저장 구조를 읽을 수 있는 관리자용 뷰어
integration_binary_sources를 DB 스키마에 정식 반영
DB 상태 화면도 app source -> publish -> served 구조로 관리
남은 작업 범위
DB 상태 화면 고도화
raw 적재 테이블과 standard 운영 테이블 관계를 더 명확히 표시
테이블별 컬럼/의미/주요 화면 연결 설명 강화
운영 검증용 체크포인트를 화면에 더 노출
저장 흐름 검증
서버 재기동 후 데이터 유지 재검증
업로드 후 DB 반영 및 화면 반영 흐름 점검
8080/8081 간 DB 프로토콜 재확인
정합성 검증 기반 마련
원본 파일, raw 적재, 표준화 결과 간 비교 포인트 정리
주요 화면 집계값이 어느 테이블을 근거로 계산되는지 문서화
데이터 검증 항목
organization.xlsx, MH.xlsx, payment.csv, ptj.csv 원본과 DB 적재 결과 비교
raw 적재 테이블과 standard 운영 테이블 간 변환 결과 비교
integration_binary_sources와 실제 서빙 파일/기본 원본 간 연결 검증
누락 행, 중복 행, 이름/사번 매칭 오류, 프로젝트 분류 오류 점검
날짜 필터 적용 전후 결과가 원본 로우데이터와 맞는지 확인
완료 기준
DB의 핵심 운영 테이블과 역할을 화면/문서에서 파악할 수 있다.
재기동 후에도 조직/구성원/자리배치/integration 데이터가 유지된다.
원본 파일, raw 적재, standard 운영 데이터의 연결 관계가 설명 가능하다.
운영 전 점검 체크리스트가 문서와 실제 동작 기준으로 일치한다.
사용자가 SQL 없이도 현재 저장 상태를 허브에서 확인할 수 있다.
### 배경
`#2`는 단순히 DB가 살아 있는지 확인하는 이슈가 아니라, 현재 8081 기준 백엔드 저장 구조를 운영 가능한 상태로 정리하는 이슈다. 사용자가 SQL을 직접 보지 않아도 현재 어떤 테이블이 실제 운영 데이터인지, 어떤 원본이 적재됐는지, 어떤 화면이 어떤 저장 구조를 읽는지 파악할 수 있어야 한다.
### 현재 기준
- 작업 기준 브랜치: `work-8081`
- 작업 기준 경로: `.dev-worktree-8081`
- 8081 backend는 FastAPI + PostgreSQL 구조로 동작 중
- 현재 DB에는 `members`, `seat_maps`, `seat_positions`, `member_versions`, `seat_assignment_versions`, `integration_*`, `auth.*` 등 운영 테이블이 존재
- `integration_binary_sources` 테이블 생성 누락 이슈를 코드 기준으로 보완 중
- 허브에서 바로 확인 가능한 `DB 상태` 화면을 추가해 `#2` 범위를 구체화함
### 이번 차수 반영
- `/api/admin/db-status` 추가
- 핵심 운영 테이블 row 수
- 최근 갱신 시각
- import batch 상태
- 바이너리 원본 보관 상태
- `/admin/db-status` 화면 추가
- 허브 상단 `DB 상태` 탭에서 접근 가능
- SQL 없이 저장 구조를 읽을 수 있는 관리자용 뷰어
- `integration_binary_sources`를 DB 스키마에 정식 반영
- `DB 상태` 화면도 `app source -> publish -> served` 구조로 관리
### 남은 작업 범위
1. DB 상태 화면 고도화
- raw 적재 테이블과 standard 운영 테이블 관계를 더 명확히 표시
- 테이블별 컬럼/의미/주요 화면 연결 설명 강화
- 운영 검증용 체크포인트를 화면에 더 노출
2. 저장 흐름 검증
- 서버 재기동 후 데이터 유지 재검증
- 업로드 후 DB 반영 및 화면 반영 흐름 점검
- 8080/8081 간 DB 프로토콜 재확인
3. 정합성 검증 기반 마련
- 원본 파일, raw 적재, 표준화 결과 간 비교 포인트 정리
- 주요 화면 집계값이 어느 테이블을 근거로 계산되는지 문서화
### 데이터 검증 항목
- `organization.xlsx`, `MH.xlsx`, `payment.csv`, `ptj.csv` 원본과 DB 적재 결과 비교
- raw 적재 테이블과 standard 운영 테이블 간 변환 결과 비교
- `integration_binary_sources`와 실제 서빙 파일/기본 원본 간 연결 검증
- 누락 행, 중복 행, 이름/사번 매칭 오류, 프로젝트 분류 오류 점검
- 날짜 필터 적용 전후 결과가 원본 로우데이터와 맞는지 확인
### 완료 기준
- DB의 핵심 운영 테이블과 역할을 화면/문서에서 파악할 수 있다.
- 재기동 후에도 조직/구성원/자리배치/integration 데이터가 유지된다.
- 원본 파일, raw 적재, standard 운영 데이터의 연결 관계가 설명 가능하다.
- 운영 전 점검 체크리스트가 문서와 실제 동작 기준으로 일치한다.
- 사용자가 SQL 없이도 현재 저장 상태를 허브에서 확인할 수 있다.
hyunho
changed title from [P0] [Infra] 이미지 서버 구축 및 월말 조직 데이터 DB 스냅샷 기능 to [P0] [Infra] ?? ?? ??? ??? ?? ? ?? ??? ??? ?? ??2026-03-25 09:10:08 +09:00
hyunho
changed title from [P0] [Infra] ?? ?? ??? ??? ?? ? ?? ??? ??? ?? ?? to [P0] [Infra] Build persistent backend storage and monthly org snapshots2026-03-25 09:12:28 +09:00
hyunho
changed title from [P0] [Infra] Build persistent backend storage and monthly org snapshots to [P0] [인프라] 백엔드 영속 저장 구조 운영 마무리 및 스냅샷 검증2026-03-25 10:30:14 +09:00
hyunho
changed title from [P0] [인프라] 백엔드 영속 저장 구조 운영 마무리 및 스냅샷 검증 to [P0] [인프라] 백엔드 영속 저장 구조 운영 마무리2026-03-27 08:44:57 +09:00
이번 세션에서 dev/prod 운영 기준을 문서화하고 작업용 DB를 공개용 정본 기준으로 맞추는 절차를 추가했습니다.
반영 내용
docs/DEV_PROD_DB_PROTOCOL.md 추가
원칙 고정
코드 선행은 8081
데이터 정본은 8080
8081 DB는 독립 정본이 아니라 8080 기준 복제본처럼 관리
docs/INFRA_VALIDATION_CHECKLIST.md, docs/NEXT_SESSION_CHECKPOINT.md에 프로토콜 링크 및 운영 원칙 반영
scripts/sync_prod_db_to_dev.sh 추가
minimal: 조직도/멤버/자리배치 검증용 동기화
full: 분석 데이터까지 포함한 동기화
실제 확인된 차이 문서화
members: 8080=227, 8081=236
member_retirements: 8080=9, 8081=0
seat_maps: 8080=21, 8081=3
seat_positions: 8080=5, 8081=0
seat_slots: 8080=57308, 8081=370
추가 보정
작업용 DB에 minimal 범위 동기화 수행
seat_positions는 prod/dev 스키마 차이를 확인했고, 이 문제를 피하도록 동기화 스크립트를 보정
동기화 후 members, member_retirements, seat_maps, seat_slots, seat_positions, auth.users 재정렬 완료
현재 해석
기능 검증 전 8081 DB 기준 불일치가 원인인 혼선이 컸음
이후부터는 공개용 기준 데이터가 필요한 작업은 먼저 동기화 후 검증하는 방식으로 진행해야 함
2026-03-27 작업 정리
이번 세션에서 dev/prod 운영 기준을 문서화하고 작업용 DB를 공개용 정본 기준으로 맞추는 절차를 추가했습니다.
반영 내용
- `docs/DEV_PROD_DB_PROTOCOL.md` 추가
- 원칙 고정
- 코드 선행은 `8081`
- 데이터 정본은 `8080`
- `8081` DB는 독립 정본이 아니라 `8080` 기준 복제본처럼 관리
- `docs/INFRA_VALIDATION_CHECKLIST.md`, `docs/NEXT_SESSION_CHECKPOINT.md`에 프로토콜 링크 및 운영 원칙 반영
- `scripts/sync_prod_db_to_dev.sh` 추가
- `minimal`: 조직도/멤버/자리배치 검증용 동기화
- `full`: 분석 데이터까지 포함한 동기화
- 실제 확인된 차이 문서화
- `members`: `8080=227`, `8081=236`
- `member_retirements`: `8080=9`, `8081=0`
- `seat_maps`: `8080=21`, `8081=3`
- `seat_positions`: `8080=5`, `8081=0`
- `seat_slots`: `8080=57308`, `8081=370`
추가 보정
- 작업용 DB에 `minimal` 범위 동기화 수행
- `seat_positions`는 prod/dev 스키마 차이를 확인했고, 이 문제를 피하도록 동기화 스크립트를 보정
- 동기화 후 `members`, `member_retirements`, `seat_maps`, `seat_slots`, `seat_positions`, `auth.users` 재정렬 완료
현재 해석
- 기능 검증 전 `8081` DB 기준 불일치가 원인인 혼선이 컸음
- 이후부터는 공개용 기준 데이터가 필요한 작업은 먼저 동기화 후 검증하는 방식으로 진행해야 함
/api/admin/db-status, /api/admin/db-status/table 추가
SQL 없이 전체 27개 테이블 현황과 샘플 row를 확인 가능하게 구성
전체 테이블을 유지 / 주의 / 원본·추적 / 정리 후보로 분류한 운영 기준 문서 추가
docs/architecture/DB_TABLE_CATALOG.md
현재 판단:
전체 물리 테이블은 27개지만, 바로 줄여야 할 상태는 아님
핵심은 숫자보다 역할 분류와 운영 기준 정리
다음 우선 점검 대상은 seat_maps 과거 DXF 시도본 정리 기준과 entity_change_events 실제 사용 여부
2026-04-01 진행상황
- 허브에 `DB 상태` 탭 추가
- `/api/admin/db-status`, `/api/admin/db-status/table` 추가
- SQL 없이 전체 27개 테이블 현황과 샘플 row를 확인 가능하게 구성
- 전체 테이블을 `유지 / 주의 / 원본·추적 / 정리 후보`로 분류한 운영 기준 문서 추가
- `docs/architecture/DB_TABLE_CATALOG.md`
현재 판단:
- 전체 물리 테이블은 27개지만, 바로 줄여야 할 상태는 아님
- 핵심은 숫자보다 역할 분류와 운영 기준 정리
- 다음 우선 점검 대상은 `seat_maps` 과거 DXF 시도본 정리 기준과 `entity_change_events` 실제 사용 여부
핵심 운영 구조는 이미 올라와 있고, 지금 필요한 것은 대규모 축소보다 운영 관점 분류와 가시화
다음부터는 DB 상태 탭과 docs/architecture/DB_TABLE_CATALOG.md를 기준으로 판단
2026-04-01 추가 진행상황
- `DB 상태` 화면을 전체 테이블 기준으로 확장
- 현재 전체 물리 테이블 수는 `26개`
- 테이블명을 누르면 컬럼/샘플 row를 팝업으로 확인 가능하게 정리
- 전체 테이블을 `유지 / 주의 / 원본·추적 / 정리 후보`로 분류
- 과거 DXF seat_map 시도본 17개 정리, 최신 DXF 1개만 유지
- `entity_change_events`는 실제 사용되지 않고 row도 0이어서 제거
현재 판단:
- DB 상태는 구조적으로 불안정하거나 비정상적인 상태는 아님
- 핵심 운영 구조는 이미 올라와 있고, 지금 필요한 것은 대규모 축소보다 운영 관점 분류와 가시화
- 다음부터는 `DB 상태` 탭과 `docs/architecture/DB_TABLE_CATALOG.md`를 기준으로 판단
유지/주의/원본·추적 분류 외에 탭 데이터 / 로그인·권한 / 히스토리 / 로우데이터·적재 / 보정·보조 제품 관점 묶음 추가
조직 현황 / 자리배치도 / 프로젝트별 분석 / 팀·개인별 분석 / 사업관리대장 / 로그인별 실제 데이터 소스 테이블과 저장 흐름 설명 추가
DB 상태 진입 경로와 문서 기준을 현재 동작하는 /db-status.html 기준으로 정리
현재 판단:
DB는 불안정하거나 붕괴 직전인 상태가 아니라, 운영 기준을 점점 명확히 하는 단계다.
지금은 물리 테이블을 더 합치기보다, 화면/권한/이력/로우데이터 관점으로 묶어 보고 관리하는 편이 적절하다.
다음 후보:
테이블 상세 팝업에 CSV 내보내기 또는 검색 보강
주의 그룹 테이블의 실제 입력/수정 주체 문서화
#14로 넘어가 publish 흐름/중복 구조 정리 이어가기
`#2` 진행상황 업데이트
이번 라운드 반영:
- `DB 상태` 화면을 단순 테이블 목록에서 운영 관점 뷰로 확장
- 전체 테이블 수 기준을 `26`으로 정리하고 문서/화면 문구 동기화
- `유지/주의/원본·추적` 분류 외에 `탭 데이터 / 로그인·권한 / 히스토리 / 로우데이터·적재 / 보정·보조` 제품 관점 묶음 추가
- `조직 현황 / 자리배치도 / 프로젝트별 분석 / 팀·개인별 분석 / 사업관리대장 / 로그인`별 실제 데이터 소스 테이블과 저장 흐름 설명 추가
- `DB 상태` 진입 경로와 문서 기준을 현재 동작하는 `/db-status.html` 기준으로 정리
현재 판단:
- DB는 불안정하거나 붕괴 직전인 상태가 아니라, 운영 기준을 점점 명확히 하는 단계다.
- 지금은 물리 테이블을 더 합치기보다, 화면/권한/이력/로우데이터 관점으로 묶어 보고 관리하는 편이 적절하다.
다음 후보:
1. 테이블 상세 팝업에 CSV 내보내기 또는 검색 보강
2. `주의` 그룹 테이블의 실제 입력/수정 주체 문서화
3. `#14`로 넘어가 publish 흐름/중복 구조 정리 이어가기
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
배경
#2는 단순히 DB가 살아 있는지 확인하는 이슈가 아니라, 현재 8081 기준 백엔드 저장 구조를 운영 가능한 상태로 정리하는 이슈다. 사용자가 SQL을 직접 보지 않아도 현재 어떤 테이블이 실제 운영 데이터인지, 어떤 원본이 적재됐는지, 어떤 화면이 어떤 저장 구조를 읽는지 파악할 수 있어야 한다.현재 기준
work-8081.dev-worktree-8081members,seat_maps,seat_positions,member_versions,seat_assignment_versions,integration_*,auth.*등 운영 테이블이 존재integration_binary_sources테이블 생성 누락 이슈를 코드 기준으로 보완 중DB 상태화면을 추가해#2범위를 구체화함이번 차수 반영
/api/admin/db-status추가/admin/db-status화면 추가DB 상태탭에서 접근 가능integration_binary_sources를 DB 스키마에 정식 반영DB 상태화면도app source -> publish -> served구조로 관리남은 작업 범위
데이터 검증 항목
organization.xlsx,MH.xlsx,payment.csv,ptj.csv원본과 DB 적재 결과 비교integration_binary_sources와 실제 서빙 파일/기본 원본 간 연결 검증완료 기준
[P0] [Infra] 이미지 서버 구축 및 월말 조직 데이터 DB 스냅샷 기능to [P0] [Infra] ?? ?? ??? ??? ?? ? ?? ??? ??? ?? ??[P0] [Infra] ?? ?? ??? ??? ?? ? ?? ??? ??? ?? ??to [P0] [Infra] Build persistent backend storage and monthly org snapshots[P0] [Infra] Build persistent backend storage and monthly org snapshotsto [P0] [인프라] 백엔드 영속 저장 구조 운영 마무리 및 스냅샷 검증[P0] [인프라] 백엔드 영속 저장 구조 운영 마무리 및 스냅샷 검증to [P0] [인프라] 백엔드 영속 저장 구조 운영 마무리2026-03-27 작업 정리
이번 세션에서 dev/prod 운영 기준을 문서화하고 작업용 DB를 공개용 정본 기준으로 맞추는 절차를 추가했습니다.
반영 내용
docs/DEV_PROD_DB_PROTOCOL.md추가808180808081DB는 독립 정본이 아니라8080기준 복제본처럼 관리docs/INFRA_VALIDATION_CHECKLIST.md,docs/NEXT_SESSION_CHECKPOINT.md에 프로토콜 링크 및 운영 원칙 반영scripts/sync_prod_db_to_dev.sh추가minimal: 조직도/멤버/자리배치 검증용 동기화full: 분석 데이터까지 포함한 동기화members:8080=227,8081=236member_retirements:8080=9,8081=0seat_maps:8080=21,8081=3seat_positions:8080=5,8081=0seat_slots:8080=57308,8081=370추가 보정
minimal범위 동기화 수행seat_positions는 prod/dev 스키마 차이를 확인했고, 이 문제를 피하도록 동기화 스크립트를 보정members,member_retirements,seat_maps,seat_slots,seat_positions,auth.users재정렬 완료현재 해석
8081DB 기준 불일치가 원인인 혼선이 컸음2026-04-01 진행상황
DB 상태탭 추가/api/admin/db-status,/api/admin/db-status/table추가유지 / 주의 / 원본·추적 / 정리 후보로 분류한 운영 기준 문서 추가docs/architecture/DB_TABLE_CATALOG.md현재 판단:
seat_maps과거 DXF 시도본 정리 기준과entity_change_events실제 사용 여부2026-04-01 추가 진행상황
DB 상태화면을 전체 테이블 기준으로 확장26개유지 / 주의 / 원본·추적 / 정리 후보로 분류entity_change_events는 실제 사용되지 않고 row도 0이어서 제거현재 판단:
DB 상태탭과docs/architecture/DB_TABLE_CATALOG.md를 기준으로 판단#2진행상황 업데이트이번 라운드 반영:
DB 상태화면을 단순 테이블 목록에서 운영 관점 뷰로 확장26으로 정리하고 문서/화면 문구 동기화유지/주의/원본·추적분류 외에탭 데이터 / 로그인·권한 / 히스토리 / 로우데이터·적재 / 보정·보조제품 관점 묶음 추가조직 현황 / 자리배치도 / 프로젝트별 분석 / 팀·개인별 분석 / 사업관리대장 / 로그인별 실제 데이터 소스 테이블과 저장 흐름 설명 추가DB 상태진입 경로와 문서 기준을 현재 동작하는/db-status.html기준으로 정리현재 판단:
다음 후보:
주의그룹 테이블의 실제 입력/수정 주체 문서화#14로 넘어가 publish 흐름/중복 구조 정리 이어가기