[P2] [리팩터링 2차] 8081 백엔드 라우터/서빙 deeper 모듈 분리 #19

Open
opened 2026-04-01 09:29:22 +09:00 by hyunho · 8 comments
Owner

상위 이슈

  • 연결: #14

배경

현재 backend/app/main.py에 인증, 멤버, 통합데이터, 업로드, 자리배치도, legacy/integration 파일 서빙이 과도하게 집중되어 있다. db.py도 스키마 초기화와 운영성 로직이 한 파일에 몰려 있어 영향 추적이 어렵다.

이번 차수 목표

기능을 바꾸지 않고, 8081 백엔드 구조를 읽기 쉬운 책임 단위로 분리한다.

작업 범위

  • main.py 라우트 성격 구분
    • auth
    • members
    • integrations
    • seatmaps
    • file serving
  • 모듈/라우터 분리 가능한 경계 정의 및 단계적 분리
  • db.py에서 스키마 초기화와 운영 쿼리/보정 로직 분리 검토
  • 정적 파일/원본 파일 서빙 경로 책임 명확화

제외 범위

  • DB 스키마 자체의 의미 변경
  • 권한 정책 변경
  • API 응답 스펙 변경
  • 신규 기능 추가

완료 조건

  • main.py의 주요 책임이 분리되어 변경 영향 추적이 쉬워질 것
  • 파일 서빙 경로와 API 경로가 역할 단위로 정리될 것
  • 이후 사업관리대장/seatmap/조직현황 기능을 건드릴 때 수정 지점을 좁힐 수 있을 것
## 상위 이슈 - 연결: `#14` ## 배경 현재 `backend/app/main.py`에 인증, 멤버, 통합데이터, 업로드, 자리배치도, legacy/integration 파일 서빙이 과도하게 집중되어 있다. `db.py`도 스키마 초기화와 운영성 로직이 한 파일에 몰려 있어 영향 추적이 어렵다. ## 이번 차수 목표 기능을 바꾸지 않고, `8081` 백엔드 구조를 읽기 쉬운 책임 단위로 분리한다. ## 작업 범위 - `main.py` 라우트 성격 구분 - auth - members - integrations - seatmaps - file serving - 모듈/라우터 분리 가능한 경계 정의 및 단계적 분리 - `db.py`에서 스키마 초기화와 운영 쿼리/보정 로직 분리 검토 - 정적 파일/원본 파일 서빙 경로 책임 명확화 ## 제외 범위 - DB 스키마 자체의 의미 변경 - 권한 정책 변경 - API 응답 스펙 변경 - 신규 기능 추가 ## 완료 조건 - `main.py`의 주요 책임이 분리되어 변경 영향 추적이 쉬워질 것 - 파일 서빙 경로와 API 경로가 역할 단위로 정리될 것 - 이후 사업관리대장/seatmap/조직현황 기능을 건드릴 때 수정 지점을 좁힐 수 있을 것
Author
Owner

현재 기준으로 우선순위를 낮춰도 됨.

현황:

  • serving 경로와 runtime 책임 분리는 #18, #20, #21에서 상당 부분 선행됨
  • main.py의 deeper router/module 분리는 아직 남아 있지만, 지금 즉시 기능 작업을 막는 수준은 아님

현재 남은 실제 범위:

  • main.py의 auth / members / integrations / seatmaps / serving 단위 deeper 분리
  • db.py의 schema/init 와 운영 쿼리 책임 분리

즉 지금은 구조 고도화 성격의 후순위 리팩터링으로 보는 것이 맞다.

현재 기준으로 우선순위를 낮춰도 됨. 현황: - serving 경로와 runtime 책임 분리는 `#18`, `#20`, `#21`에서 상당 부분 선행됨 - `main.py`의 deeper router/module 분리는 아직 남아 있지만, 지금 즉시 기능 작업을 막는 수준은 아님 현재 남은 실제 범위: - `main.py`의 auth / members / integrations / seatmaps / serving 단위 deeper 분리 - `db.py`의 schema/init 와 운영 쿼리 책임 분리 즉 지금은 구조 고도화 성격의 후순위 리팩터링으로 보는 것이 맞다.
hyunho changed title from [P1] [리팩터링 2차] 8081 백엔드 라우터/서빙 책임 분리 to [P2] [리팩터링 2차] 8081 백엔드 라우터/서빙 deeper 모듈 분리 2026-04-01 14:39:24 +09:00
Author
Owner

#19 1차 진행상황 업데이트

이번 라운드 반영:

  • DB 상태 관련 상수/메타데이터/스냅샷/테이블 프리뷰 로직을 backend/app/admin_db_status.py로 분리
  • main.py는 DB 상태 라우트와 앱 조립 역할만 남기고, 상세 로직은 별도 모듈 import 구조로 변경
  • 결과적으로 main.py에서 약 400줄 규모의 보조 로직이 빠져, 이후 라우터/서빙 책임 분리를 더 진행하기 쉬운 상태가 됨

현재 판단:

  • 한 번에 전체를 쪼개는 것보다, 독립성이 높은 DB 상태 영역부터 떼어내는 방식이 안전했다.
  • 다음 분리 후보는 사업관리대장 기본 원본 동기화/서빙 보조 또는 integration 서빙 보조 영역이다.
`#19` 1차 진행상황 업데이트 이번 라운드 반영: - `DB 상태` 관련 상수/메타데이터/스냅샷/테이블 프리뷰 로직을 `backend/app/admin_db_status.py`로 분리 - `main.py`는 DB 상태 라우트와 앱 조립 역할만 남기고, 상세 로직은 별도 모듈 import 구조로 변경 - 결과적으로 `main.py`에서 약 400줄 규모의 보조 로직이 빠져, 이후 라우터/서빙 책임 분리를 더 진행하기 쉬운 상태가 됨 현재 판단: - 한 번에 전체를 쪼개는 것보다, 독립성이 높은 `DB 상태` 영역부터 떼어내는 방식이 안전했다. - 다음 분리 후보는 `사업관리대장 기본 원본 동기화/서빙 보조` 또는 `integration 서빙 보조` 영역이다.
Author
Owner

#19 2차 진행상황 업데이트

이번 라운드 반영:

  • 사업관리대장 기본 원본 동기화/기본 원본 응답/ledger served index 응답 보조 로직을 backend/app/ledger_runtime.py로 분리
  • main.py는 startup에서 ledger runtime helper를 호출하고, /api/integration/business-ledger-default, /integrations/ledger 라우트는 helper를 사용하는 얇은 진입점만 남기도록 정리

현재 판단:

  • DB 상태사업관리대장 runtime처럼 독립성이 높은 보조 영역부터 떼어내는 방식이 안정적이다.
  • 다음 분리 후보는 integration payment/mh/ledger/db-status 서빙 보조 묶음 또는 auth/user sync 보조 묶음이다.
`#19` 2차 진행상황 업데이트 이번 라운드 반영: - `사업관리대장` 기본 원본 동기화/기본 원본 응답/ledger served index 응답 보조 로직을 `backend/app/ledger_runtime.py`로 분리 - `main.py`는 startup에서 ledger runtime helper를 호출하고, `/api/integration/business-ledger-default`, `/integrations/ledger` 라우트는 helper를 사용하는 얇은 진입점만 남기도록 정리 현재 판단: - `DB 상태`와 `사업관리대장 runtime`처럼 독립성이 높은 보조 영역부터 떼어내는 방식이 안정적이다. - 다음 분리 후보는 `integration payment/mh/ledger/db-status` 서빙 보조 묶음 또는 auth/user sync 보조 묶음이다.
Author
Owner

#19 진행상황 업데이트

이번 라운드 반영:

  • backend/app/main.py에서 시스템/정적 서빙 라우트를 별도 모듈로 분리
  • 새 파일: backend/app/system_routes.py
  • 분리 대상:
    • /api/health
    • /api/admin/db-status
    • /api/admin/db-status/table
    • /admin/db-status
    • /api/integration/business-ledger-default
    • /api/integration/mh-workbook
    • /legacy/organization
    • /legacy/organization-backup
    • /integrations/payment
    • /integrations/ledger
    • /integrations/mh
    • /uploads/{filename}
  • main.pyregister_system_routes(...)로 조립만 하도록 정리

현재 판단:

  • 4500줄대 main.py에서 독립성이 높은 운영/서빙 라우트가 먼저 분리됨
  • 다음 단계는 auth / members / integration / seat-map 쪽 중 어느 축을 추가로 쪼갤지 선택하는 것
`#19` 진행상황 업데이트 이번 라운드 반영: - `backend/app/main.py`에서 시스템/정적 서빙 라우트를 별도 모듈로 분리 - 새 파일: `backend/app/system_routes.py` - 분리 대상: - `/api/health` - `/api/admin/db-status` - `/api/admin/db-status/table` - `/admin/db-status` - `/api/integration/business-ledger-default` - `/api/integration/mh-workbook` - `/legacy/organization` - `/legacy/organization-backup` - `/integrations/payment` - `/integrations/ledger` - `/integrations/mh` - `/uploads/{filename}` - `main.py`는 `register_system_routes(...)`로 조립만 하도록 정리 현재 판단: - 4500줄대 `main.py`에서 독립성이 높은 운영/서빙 라우트가 먼저 분리됨 - 다음 단계는 auth / members / integration / seat-map 쪽 중 어느 축을 추가로 쪼갤지 선택하는 것
Author
Owner

#19 추가 진행상황 업데이트

이번 라운드 반영:

  • auth 라우트를 별도 모듈로 분리
  • 새 파일: backend/app/auth_routes.py
  • 분리 대상:
    • /api/auth/login
    • /api/auth/logout
    • /api/auth/me
    • /api/mock-login
  • main.pyregister_auth_routes(...)로 조립만 하도록 정리
  • 기존 비밀번호 해시/세션 payload/토큰 파싱 헬퍼는 그대로 두고, route handler만 먼저 분리해서 회귀 위험을 낮춤

현재 판단:

  • main.py에서 운영/서빙 + auth 라우트가 빠지면서 분리 기준이 더 명확해짐
  • 다음 분리 후보는 members/history 또는 integration 축 중 하나
`#19` 추가 진행상황 업데이트 이번 라운드 반영: - `auth` 라우트를 별도 모듈로 분리 - 새 파일: `backend/app/auth_routes.py` - 분리 대상: - `/api/auth/login` - `/api/auth/logout` - `/api/auth/me` - `/api/mock-login` - `main.py`는 `register_auth_routes(...)`로 조립만 하도록 정리 - 기존 비밀번호 해시/세션 payload/토큰 파싱 헬퍼는 그대로 두고, route handler만 먼저 분리해서 회귀 위험을 낮춤 현재 판단: - `main.py`에서 운영/서빙 + auth 라우트가 빠지면서 분리 기준이 더 명확해짐 - 다음 분리 후보는 `members/history` 또는 `integration` 축 중 하나
Author
Owner

#19 추가 진행상황 업데이트

이번 라운드 반영:

  • members/history 라우트를 별도 모듈로 분리
  • 새 파일: backend/app/member_routes.py
  • 분리 대상:
    • /api/members
    • /api/history/members/compare
    • /api/members POST
    • /api/members/bulk-sync
    • /api/members/{member_id} PUT/DELETE
    • /api/members/import
  • main.pyregister_member_routes(...)로 조립만 하도록 정리
  • 실제 데이터/이력 헬퍼는 기존 구현을 그대로 재사용해서 회귀 위험을 낮춤

현재 판단:

  • main.py에서 시스템/서빙 + auth + members/history 라우트가 빠지면서 책임 경계가 더 명확해짐
  • 다음 분리 후보는 integration 또는 seat-map
`#19` 추가 진행상황 업데이트 이번 라운드 반영: - `members/history` 라우트를 별도 모듈로 분리 - 새 파일: `backend/app/member_routes.py` - 분리 대상: - `/api/members` - `/api/history/members/compare` - `/api/members` POST - `/api/members/bulk-sync` - `/api/members/{member_id}` PUT/DELETE - `/api/members/import` - `main.py`는 `register_member_routes(...)`로 조립만 하도록 정리 - 실제 데이터/이력 헬퍼는 기존 구현을 그대로 재사용해서 회귀 위험을 낮춤 현재 판단: - `main.py`에서 시스템/서빙 + auth + members/history 라우트가 빠지면서 책임 경계가 더 명확해짐 - 다음 분리 후보는 `integration` 또는 `seat-map` 축
Author
Owner

#19 추가 진행상황 업데이트

이번 라운드 반영:

  • integration 조회/적재 라우트를 별도 모듈로 분리
  • 새 파일: backend/app/integration_routes.py
  • 분리 대상:
    • /api/integration/import
    • /api/integration/summary
    • /api/integration/projects
    • /api/integration/members
    • /api/integration/teams
    • /api/integration/project-breakdowns
    • /api/integration/payment-source
    • /api/integration/mh-source
  • main.pyregister_integration_routes(...)로 조립만 하도록 정리

현재 판단:

  • main.py에서 시스템/서빙 + auth + members/history + integration 라우트가 빠지면서 책임 분리가 의미 있게 진행됨
  • 다음 분리 후보는 seat-map/uploads
`#19` 추가 진행상황 업데이트 이번 라운드 반영: - `integration` 조회/적재 라우트를 별도 모듈로 분리 - 새 파일: `backend/app/integration_routes.py` - 분리 대상: - `/api/integration/import` - `/api/integration/summary` - `/api/integration/projects` - `/api/integration/members` - `/api/integration/teams` - `/api/integration/project-breakdowns` - `/api/integration/payment-source` - `/api/integration/mh-source` - `main.py`는 `register_integration_routes(...)`로 조립만 하도록 정리 현재 판단: - `main.py`에서 시스템/서빙 + auth + members/history + integration 라우트가 빠지면서 책임 분리가 의미 있게 진행됨 - 다음 분리 후보는 `seat-map/uploads` 축
Author
Owner

#19 추가 진행상황 업데이트

이번 라운드 반영:

  • seat-map/uploads 라우트를 별도 모듈로 분리
  • 새 파일: backend/app/seatmap_routes.py
  • 분리 대상:
    • /api/uploads/profile-photo
    • /api/uploads/seat-map-image
    • /api/seat-maps/dxf
    • /api/seat-maps/active
    • /api/seat-maps POST/PUT
    • /api/seat-maps/{seat_map_id}/layout
    • /api/seat-maps/{seat_map_id}/viewer
  • main.pyregister_seatmap_routes(...)로 조립만 하도록 정리

현재 판단:

  • main.py에서 주요 라우트 축(system/serving, auth, members/history, integration, seat-map/uploads)이 빠져서 라우터와 계산/변환 로직 경계가 크게 선명해짐
  • 다음 단계는 남은 로직 헬퍼를 도메인별로 추가 분리할지, 여기서 한 번 커밋하고 멈출지 판단하는 것
`#19` 추가 진행상황 업데이트 이번 라운드 반영: - `seat-map/uploads` 라우트를 별도 모듈로 분리 - 새 파일: `backend/app/seatmap_routes.py` - 분리 대상: - `/api/uploads/profile-photo` - `/api/uploads/seat-map-image` - `/api/seat-maps/dxf` - `/api/seat-maps/active` - `/api/seat-maps` POST/PUT - `/api/seat-maps/{seat_map_id}/layout` - `/api/seat-maps/{seat_map_id}/viewer` - `main.py`는 `register_seatmap_routes(...)`로 조립만 하도록 정리 현재 판단: - `main.py`에서 주요 라우트 축(system/serving, auth, members/history, integration, seat-map/uploads)이 빠져서 라우터와 계산/변환 로직 경계가 크게 선명해짐 - 다음 단계는 남은 로직 헬퍼를 도메인별로 추가 분리할지, 여기서 한 번 커밋하고 멈출지 판단하는 것
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: hyunho/MH-DashBoard-organization#19