hyunho/MH-DashBoard-organization
1
0
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases Wiki Activity

[P0] [인프라] 백엔드 영속 저장 구조 운영 마무리 #2

New Issue
Open
opened 2026-03-25 08:46:48 +09:00 by hyunho · 4 comments
hyunho commented 2026-03-25 08:46:48 +09:00
Owner
Copy Link

배경

#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 운영 테이블 관계를 더 명확히 표시
  • 테이블별 컬럼/의미/주요 화면 연결 설명 강화
  • 운영 검증용 체크포인트를 화면에 더 노출
  1. 저장 흐름 검증
  • 서버 재기동 후 데이터 유지 재검증
  • 업로드 후 DB 반영 및 화면 반영 흐름 점검
  • 8080/8081 간 DB 프로토콜 재확인
  1. 정합성 검증 기반 마련
  • 원본 파일, 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 snapshots 2026-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
hyunho commented 2026-03-27 16:33:02 +09:00
Author
Owner
Copy Link

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 기준 불일치가 원인인 혼선이 컸음
  • 이후부터는 공개용 기준 데이터가 필요한 작업은 먼저 동기화 후 검증하는 방식으로 진행해야 함
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 기준 불일치가 원인인 혼선이 컸음 - 이후부터는 공개용 기준 데이터가 필요한 작업은 먼저 동기화 후 검증하는 방식으로 진행해야 함
hyunho commented 2026-04-01 15:19:03 +09:00
Author
Owner
Copy Link

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 실제 사용 여부
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` 실제 사용 여부
hyunho commented 2026-04-01 15:27:43 +09:00
Author
Owner
Copy Link

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를 기준으로 판단
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`를 기준으로 판단
hyunho commented 2026-04-01 16:23:27 +09:00
Author
Owner
Copy Link

#2 진행상황 업데이트

이번 라운드 반영:

  • DB 상태 화면을 단순 테이블 목록에서 운영 관점 뷰로 확장
  • 전체 테이블 수 기준을 26으로 정리하고 문서/화면 문구 동기화
  • 유지/주의/원본·추적 분류 외에 탭 데이터 / 로그인·권한 / 히스토리 / 로우데이터·적재 / 보정·보조 제품 관점 묶음 추가
  • 조직 현황 / 자리배치도 / 프로젝트별 분석 / 팀·개인별 분석 / 사업관리대장 / 로그인별 실제 데이터 소스 테이블과 저장 흐름 설명 추가
  • DB 상태 진입 경로와 문서 기준을 현재 동작하는 /db-status.html 기준으로 정리

현재 판단:

  • DB는 불안정하거나 붕괴 직전인 상태가 아니라, 운영 기준을 점점 명확히 하는 단계다.
  • 지금은 물리 테이블을 더 합치기보다, 화면/권한/이력/로우데이터 관점으로 묶어 보고 관리하는 편이 적절하다.

다음 후보:

  1. 테이블 상세 팝업에 CSV 내보내기 또는 검색 보강
  2. 주의 그룹 테이블의 실제 입력/수정 주체 문서화
  3. #14로 넘어가 publish 흐름/중복 구조 정리 이어가기
`#2` 진행상황 업데이트 이번 라운드 반영: - `DB 상태` 화면을 단순 테이블 목록에서 운영 관점 뷰로 확장 - 전체 테이블 수 기준을 `26`으로 정리하고 문서/화면 문구 동기화 - `유지/주의/원본·추적` 분류 외에 `탭 데이터 / 로그인·권한 / 히스토리 / 로우데이터·적재 / 보정·보조` 제품 관점 묶음 추가 - `조직 현황 / 자리배치도 / 프로젝트별 분석 / 팀·개인별 분석 / 사업관리대장 / 로그인`별 실제 데이터 소스 테이블과 저장 흐름 설명 추가 - `DB 상태` 진입 경로와 문서 기준을 현재 동작하는 `/db-status.html` 기준으로 정리 현재 판단: - DB는 불안정하거나 붕괴 직전인 상태가 아니라, 운영 기준을 점점 명확히 하는 단계다. - 지금은 물리 테이블을 더 합치기보다, 화면/권한/이력/로우데이터 관점으로 묶어 보고 관리하는 편이 적절하다. 다음 후보: 1. 테이블 상세 팝업에 CSV 내보내기 또는 검색 보강 2. `주의` 그룹 테이블의 실제 입력/수정 주체 문서화 3. `#14`로 넘어가 publish 흐름/중복 구조 정리 이어가기
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
hyunho
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: hyunho/MH-DashBoard-organization#2
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?