현재 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/조직현황 기능을 건드릴 때 수정 지점을 좁힐 수 있을 것
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
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 서빙 보조` 영역이다.
사업관리대장 기본 원본 동기화/기본 원본 응답/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 보조 묶음이다.
다음 단계는 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 쪽 중 어느 축을 추가로 쪼갤지 선택하는 것
기존 비밀번호 해시/세션 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` 축 중 하나
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` 축
main.py는 register_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` 축
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)이 빠져서 라우터와 계산/변환 로직 경계가 크게 선명해짐
- 다음 단계는 남은 로직 헬퍼를 도메인별로 추가 분리할지, 여기서 한 번 커밋하고 멈출지 판단하는 것
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.
상위 이슈
#14배경
현재
backend/app/main.py에 인증, 멤버, 통합데이터, 업로드, 자리배치도, legacy/integration 파일 서빙이 과도하게 집중되어 있다.db.py도 스키마 초기화와 운영성 로직이 한 파일에 몰려 있어 영향 추적이 어렵다.이번 차수 목표
기능을 바꾸지 않고,
8081백엔드 구조를 읽기 쉬운 책임 단위로 분리한다.작업 범위
main.py라우트 성격 구분db.py에서 스키마 초기화와 운영 쿼리/보정 로직 분리 검토제외 범위
완료 조건
main.py의 주요 책임이 분리되어 변경 영향 추적이 쉬워질 것현재 기준으로 우선순위를 낮춰도 됨.
현황:
#18,#20,#21에서 상당 부분 선행됨main.py의 deeper router/module 분리는 아직 남아 있지만, 지금 즉시 기능 작업을 막는 수준은 아님현재 남은 실제 범위:
main.py의 auth / members / integrations / seatmaps / serving 단위 deeper 분리db.py의 schema/init 와 운영 쿼리 책임 분리즉 지금은 구조 고도화 성격의 후순위 리팩터링으로 보는 것이 맞다.
[P1] [리팩터링 2차] 8081 백엔드 라우터/서빙 책임 분리to [P2] [리팩터링 2차] 8081 백엔드 라우터/서빙 deeper 모듈 분리#191차 진행상황 업데이트이번 라운드 반영:
DB 상태관련 상수/메타데이터/스냅샷/테이블 프리뷰 로직을backend/app/admin_db_status.py로 분리main.py는 DB 상태 라우트와 앱 조립 역할만 남기고, 상세 로직은 별도 모듈 import 구조로 변경main.py에서 약 400줄 규모의 보조 로직이 빠져, 이후 라우터/서빙 책임 분리를 더 진행하기 쉬운 상태가 됨현재 판단:
DB 상태영역부터 떼어내는 방식이 안전했다.사업관리대장 기본 원본 동기화/서빙 보조또는integration 서빙 보조영역이다.#192차 진행상황 업데이트이번 라운드 반영:
사업관리대장기본 원본 동기화/기본 원본 응답/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진행상황 업데이트이번 라운드 반영:
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(...)로 조립만 하도록 정리현재 판단:
main.py에서 독립성이 높은 운영/서빙 라우트가 먼저 분리됨#19추가 진행상황 업데이트이번 라운드 반영:
auth라우트를 별도 모듈로 분리backend/app/auth_routes.py/api/auth/login/api/auth/logout/api/auth/me/api/mock-loginmain.py는register_auth_routes(...)로 조립만 하도록 정리현재 판단:
main.py에서 운영/서빙 + auth 라우트가 빠지면서 분리 기준이 더 명확해짐members/history또는integration축 중 하나#19추가 진행상황 업데이트이번 라운드 반영:
members/history라우트를 별도 모듈로 분리backend/app/member_routes.py/api/members/api/history/members/compare/api/membersPOST/api/members/bulk-sync/api/members/{member_id}PUT/DELETE/api/members/importmain.py는register_member_routes(...)로 조립만 하도록 정리현재 판단:
main.py에서 시스템/서빙 + auth + members/history 라우트가 빠지면서 책임 경계가 더 명확해짐integration또는seat-map축#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-sourcemain.py는register_integration_routes(...)로 조립만 하도록 정리현재 판단:
main.py에서 시스템/서빙 + 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-mapsPOST/PUT/api/seat-maps/{seat_map_id}/layout/api/seat-maps/{seat_map_id}/viewermain.py는register_seatmap_routes(...)로 조립만 하도록 정리현재 판단:
main.py에서 주요 라우트 축(system/serving, auth, members/history, integration, seat-map/uploads)이 빠져서 라우터와 계산/변환 로직 경계가 크게 선명해짐