[P2] [리팩터링] 누적된 임시 로직 정리 및 중복 코드 제거 #14

New Issue

2026-03-27T18:08:38+09:00

hyunho commented

2026-03-27 18:08:38 +09:00

배경

최근 작업을 대화 기반으로 빠르게 이어가면서 기능 수정이 우선되었고, 그 과정에서 코드가 점점 복잡해지고 있습니다.

현재 체감 문제:

임시 대응 로직이 누적됨
중복 코드가 늘어남
사용하지 않는 코드 / 더 이상 필요 없는 분기 / 과거 호환용 로직이 남아 있음
화면별 상태 처리와 데이터 흐름이 꼬이기 쉬워짐
회귀 버그가 생겼을 때 원인 추적이 어려워짐

이 이슈에서 말하는 작업

쉽게 말하면 코드 정비, 코드 정리, 리팩터링에 해당합니다.

구체적으로는:

더 이상 사용하지 않는 코드 제거
중복 함수 / 중복 분기 / 중복 상태 처리 제거
임시 패치성 로직 정리
seatmap / organization / integration 관련 흐름에서 책임 분리
데이터 fallback 처리와 예외 처리 일관성 정리
캐시 키 / 환경별 분기 / 화면 모드 분기 정돈

왜 필요한가

지금처럼 기능을 말로 지시하면서 빠르게 붙이는 방식에서는 구조 정리가 없으면 코드가 계속 꼬임
같은 문제를 수정할 때 다른 화면이 같이 깨지는 회귀 가능성이 커짐
공개용/작업용 환경을 병행하는 현재 운영 방식에서는 특히 코드 가독성과 흐름 명확성이 더 중요함

우선 정리 대상 후보

frontend/public/app.js
legacy/static/organization.js
backend/app/main.py
seatmap 관련 뷰어 브리지 로직
공개용/작업용 분기 및 동기화 관련 보조 로직

완료 조건

사용하지 않는 코드와 중복 코드가 눈에 띄게 줄어들 것
주요 화면의 상태 흐름이 더 단순해질 것
seatmap / organization / integration 수정 시 회귀 위험이 줄어들 것
이후 기능 추가 시 임시 패치가 아니라 구조적으로 넣기 쉬운 상태가 될 것

## 배경 최근 작업을 대화 기반으로 빠르게 이어가면서 기능 수정이 우선되었고, 그 과정에서 코드가 점점 복잡해지고 있습니다. 현재 체감 문제: - 임시 대응 로직이 누적됨 - 중복 코드가 늘어남 - 사용하지 않는 코드 / 더 이상 필요 없는 분기 / 과거 호환용 로직이 남아 있음 - 화면별 상태 처리와 데이터 흐름이 꼬이기 쉬워짐 - 회귀 버그가 생겼을 때 원인 추적이 어려워짐 ## 이 이슈에서 말하는 작업 쉽게 말하면 `코드 정비`, `코드 정리`, `리팩터링`에 해당합니다. 구체적으로는: - 더 이상 사용하지 않는 코드 제거 - 중복 함수 / 중복 분기 / 중복 상태 처리 제거 - 임시 패치성 로직 정리 - seatmap / organization / integration 관련 흐름에서 책임 분리 - 데이터 fallback 처리와 예외 처리 일관성 정리 - 캐시 키 / 환경별 분기 / 화면 모드 분기 정돈 ## 왜 필요한가 - 지금처럼 기능을 말로 지시하면서 빠르게 붙이는 방식에서는 구조 정리가 없으면 코드가 계속 꼬임 - 같은 문제를 수정할 때 다른 화면이 같이 깨지는 회귀 가능성이 커짐 - 공개용/작업용 환경을 병행하는 현재 운영 방식에서는 특히 코드 가독성과 흐름 명확성이 더 중요함 ## 우선 정리 대상 후보 - `frontend/public/app.js` - `legacy/static/organization.js` - `backend/app/main.py` - seatmap 관련 뷰어 브리지 로직 - 공개용/작업용 분기 및 동기화 관련 보조 로직 ## 완료 조건 - 사용하지 않는 코드와 중복 코드가 눈에 띄게 줄어들 것 - 주요 화면의 상태 흐름이 더 단순해질 것 - seatmap / organization / integration 수정 시 회귀 위험이 줄어들 것 - 이후 기능 추가 시 임시 패치가 아니라 구조적으로 넣기 쉬운 상태가 될 것

hyunho commented

2026-04-01 09:26:15 +09:00

#14를 단순 코드 포맷 정리가 아니라 8081 전체 구조 정리 이슈로 확장해서 사용해야 합니다.

현재 8081 구동 경로를 다시 읽어본 결과, 프런트만이 아니라 백엔드까지 함께 정리해야 할 상태입니다.

핵심 진단:

frontend/public/index.html이 허브 엔트리인데 로그인, 허브, iframe 연결, asset version 쿼리스트링이 한 파일에 섞여 있음
허브 공통 스타일(frontend/public/styles.css)과 8081 전용 디자인 오버라이드가 뒤섞이기 쉬운 상태였고, 최근에야 styles-8081-design.css로 분리 시작함
legacy/static/common.css, legacy/static/organization.css, legacy/static/organization.js가 조직현황 UI/동작/디자인을 함께 떠안고 있음
incoming-files/payment.html, incoming-files/mh.html는 실제 서빙 파일이면서 동시에 원본/복구 자산 역할도 섞여 있음
incoming-files 아래에 참고 자산, 실제 서빙 자산, 복구 백업 자산이 함께 존재함
백엔드 backend/app/main.py가 인증, 멤버, 통합데이터, 업로드, 자리배치도, legacy/integration 파일 서빙까지 모두 한 파일에 과도하게 몰려 있음
backend/app/db.py도 스키마 정의와 마이그레이션/보정 성격 로직이 한곳에 집중되어 있어 변경 영향 추적이 어려움
scripts/prepare_dev_worktree.sh가 런타임 준비뿐 아니라 로컬 전용 자산 복제 정책까지 직접 알고 있어 책임이 큼
현재 구조는 기능 추가보다 어떤 파일이 실제로 서빙되는지를 다시 찾는 비용이 커서, 후속 작업 때 다시 꼬일 가능성이 높음

정리 목표를 아래처럼 재정의하는 것이 맞습니다.

프런트 자산 책임 분리

frontend/public: 허브 엔트리/공통 UI 전용
frontend/public/styles.css: 8080/8081 공통 기본 스타일
frontend/public/styles-8081-design.css: 8081 전용 허브 오버라이드
legacy/static/*: 조직현황 레거시 전용
incoming-files/*: 원본 참고 자산과 실제 서빙 자산을 분리

서빙 경로 고정

어떤 URL이 어떤 파일을 실제로 읽는지 문서와 코드에서 일치시키기
index.html의 asset version과 iframe 연결을 한 번 정리해 기준화
payment.html, mh.html는 incoming-files 임시 보관물이 아니라 정식 서빙 자산 위치를 다시 결정하기

백엔드 책임 분리

backend/app/main.py에서 최소한 아래 단위로 라우터/모듈 분리 검토
- auth
- members
- integrations
- seatmaps
- legacy/static file serving
db.py는 스키마/초기화와 운영 로직을 분리 검토

8081 운영 구조 정리

prepare_dev_worktree.sh는 worktree 준비만 담당
로컬 디자인 자산 복제 정책은 별도 설정/명시 파일로 분리 검토
recovery 백업본과 현재 work-8081 변경을 비교해 정식 흡수 대상만 선별

권장 작업 순서:

1단계: 파일 책임 맵 작성
2단계: 프런트 자산 구조 정리
3단계: 백엔드 라우터/서빙 책임 분리
4단계: 스크립트와 문서 정리
5단계: 회귀 검증 후 다음 기능 작업 재개

주의:

이 이슈에서는 가능하면 디자인 수정 자체보다 구조 정리를 우선
DB 스키마 의미 변경이나 분석 계산식 변경은 별도 이슈 범위로 유지
8080 승격 전까지 모든 정리는 8081에서만 수행

`#14`를 단순 코드 포맷 정리가 아니라 `8081` 전체 구조 정리 이슈로 확장해서 사용해야 합니다. 현재 `8081` 구동 경로를 다시 읽어본 결과, 프런트만이 아니라 백엔드까지 함께 정리해야 할 상태입니다. 핵심 진단: - `frontend/public/index.html`이 허브 엔트리인데 로그인, 허브, iframe 연결, asset version 쿼리스트링이 한 파일에 섞여 있음 - 허브 공통 스타일(`frontend/public/styles.css`)과 `8081` 전용 디자인 오버라이드가 뒤섞이기 쉬운 상태였고, 최근에야 `styles-8081-design.css`로 분리 시작함 - `legacy/static/common.css`, `legacy/static/organization.css`, `legacy/static/organization.js`가 조직현황 UI/동작/디자인을 함께 떠안고 있음 - `incoming-files/payment.html`, `incoming-files/mh.html`는 실제 서빙 파일이면서 동시에 원본/복구 자산 역할도 섞여 있음 - `incoming-files` 아래에 참고 자산, 실제 서빙 자산, 복구 백업 자산이 함께 존재함 - 백엔드 `backend/app/main.py`가 인증, 멤버, 통합데이터, 업로드, 자리배치도, legacy/integration 파일 서빙까지 모두 한 파일에 과도하게 몰려 있음 - `backend/app/db.py`도 스키마 정의와 마이그레이션/보정 성격 로직이 한곳에 집중되어 있어 변경 영향 추적이 어려움 - `scripts/prepare_dev_worktree.sh`가 런타임 준비뿐 아니라 로컬 전용 자산 복제 정책까지 직접 알고 있어 책임이 큼 - 현재 구조는 기능 추가보다 `어떤 파일이 실제로 서빙되는지`를 다시 찾는 비용이 커서, 후속 작업 때 다시 꼬일 가능성이 높음 정리 목표를 아래처럼 재정의하는 것이 맞습니다. 1. 프런트 자산 책임 분리 - `frontend/public`: 허브 엔트리/공통 UI 전용 - `frontend/public/styles.css`: 8080/8081 공통 기본 스타일 - `frontend/public/styles-8081-design.css`: 8081 전용 허브 오버라이드 - `legacy/static/*`: 조직현황 레거시 전용 - `incoming-files/*`: 원본 참고 자산과 실제 서빙 자산을 분리 2. 서빙 경로 고정 - 어떤 URL이 어떤 파일을 실제로 읽는지 문서와 코드에서 일치시키기 - `index.html`의 asset version과 iframe 연결을 한 번 정리해 기준화 - `payment.html`, `mh.html`는 `incoming-files` 임시 보관물이 아니라 정식 서빙 자산 위치를 다시 결정하기 3. 백엔드 책임 분리 - `backend/app/main.py`에서 최소한 아래 단위로 라우터/모듈 분리 검토 - auth - members - integrations - seatmaps - legacy/static file serving - `db.py`는 스키마/초기화와 운영 로직을 분리 검토 4. 8081 운영 구조 정리 - `prepare_dev_worktree.sh`는 worktree 준비만 담당 - 로컬 디자인 자산 복제 정책은 별도 설정/명시 파일로 분리 검토 - `recovery` 백업본과 현재 `work-8081` 변경을 비교해 정식 흡수 대상만 선별 권장 작업 순서: - 1단계: 파일 책임 맵 작성 - 2단계: 프런트 자산 구조 정리 - 3단계: 백엔드 라우터/서빙 책임 분리 - 4단계: 스크립트와 문서 정리 - 5단계: 회귀 검증 후 다음 기능 작업 재개 주의: - 이 이슈에서는 가능하면 `디자인 수정 자체`보다 `구조 정리`를 우선 - DB 스키마 의미 변경이나 분석 계산식 변경은 별도 이슈 범위로 유지 - `8080` 승격 전까지 모든 정리는 `8081`에서만 수행

hyunho commented

2026-04-01 14:39:41 +09:00

현재 기준으로 umbrella 역할은 유지하되, 즉시 착수 대상은 아님.

최근 #18, #20, #21을 통해 파일 책임, served/reference, app source 구조 정리가 선행되었고, 남은 리팩터링은 기능을 막는 임계 경로는 아님.

따라서 #14는 계속 상위 정리 이슈로 두되, 당장 다음 작업보다는 후순위 정리 트랙으로 보는 것이 맞다.

현재 기준으로 umbrella 역할은 유지하되, 즉시 착수 대상은 아님. 최근 `#18`, `#20`, `#21`을 통해 파일 책임, served/reference, app source 구조 정리가 선행되었고, 남은 리팩터링은 기능을 막는 임계 경로는 아님. 따라서 `#14`는 계속 상위 정리 이슈로 두되, 당장 다음 작업보다는 후순위 정리 트랙으로 보는 것이 맞다.

hyunho commented

2026-04-01 16:30:53 +09:00

#14 진행상황 업데이트

이번 라운드 반영:

incoming-files/reference/ledger/ledger 잘못 중첩된 복사본 제거
incoming-files/README.md에 served는 runtime, 실제 수정 원본은 frontend/apps/*라는 규칙 명시
incoming-files/reference/ledger/README.md 추가로 reference 경계와 금지사항(reference/ledger 아래 중첩 복사본 금지) 명시
8081_SERVING_MAP.md에 payment / mh / ledger / db-status는 직접 served를 먼저 수정하지 않고 frontend/apps/* -> publish -> served 흐름으로 관리한다는 규칙 고정

현재 판단:

큰 리팩터링보다 먼저 source-of-truth와 runtime 경계를 문서/파일 구조에서 명확히 하는 정리가 더 효과적이었다.
지금은 publish 구조와 reference 구조가 전보다 덜 헷갈리는 상태다.

#19에서 backend main.py 안에 몰린 DB 상태/서빙 보조 로직부터 작은 단위로 분리

`#14` 진행상황 업데이트 이번 라운드 반영: - `incoming-files/reference/ledger/ledger` 잘못 중첩된 복사본 제거 - `incoming-files/README.md`에 `served`는 runtime, 실제 수정 원본은 `frontend/apps/*`라는 규칙 명시 - `incoming-files/reference/ledger/README.md` 추가로 reference 경계와 금지사항(`reference/ledger` 아래 중첩 복사본 금지) 명시 - `8081_SERVING_MAP.md`에 `payment / mh / ledger / db-status`는 직접 `served`를 먼저 수정하지 않고 `frontend/apps/* -> publish -> served` 흐름으로 관리한다는 규칙 고정 현재 판단: - 큰 리팩터링보다 먼저 source-of-truth와 runtime 경계를 문서/파일 구조에서 명확히 하는 정리가 더 효과적이었다. - 지금은 publish 구조와 reference 구조가 전보다 덜 헷갈리는 상태다. 다음: - `#19`에서 backend `main.py` 안에 몰린 DB 상태/서빙 보조 로직부터 작은 단위로 분리

hyunho commented

2026-04-01 16:48:20 +09:00

#14 진행상황 업데이트

이번 라운드 반영:

incoming-files/reference/ledger/ledger 중첩 복사본 제거
incoming-files/README.md에 served는 runtime, 실제 수정 원본은 frontend/apps/*라는 규칙 명시
incoming-files/reference/ledger/README.md 추가
8081_SERVING_MAP.md에 payment / mh / ledger / db-status는 frontend/apps/* -> publish -> served 흐름으로만 수정한다는 경계 고정

현재 판단:

구조상 헷갈리던 중복 경로와 source-of-truth 경계는 많이 정리됨
다음 정리 포인트는 publish 이후 결과물 비교/복구용 파일을 얼마나 더 줄일지 판단하는 것

`#14` 진행상황 업데이트 이번 라운드 반영: - `incoming-files/reference/ledger/ledger` 중첩 복사본 제거 - `incoming-files/README.md`에 `served`는 runtime, 실제 수정 원본은 `frontend/apps/*`라는 규칙 명시 - `incoming-files/reference/ledger/README.md` 추가 - `8081_SERVING_MAP.md`에 `payment / mh / ledger / db-status`는 `frontend/apps/* -> publish -> served` 흐름으로만 수정한다는 경계 고정 현재 판단: - 구조상 헷갈리던 중복 경로와 source-of-truth 경계는 많이 정리됨 - 다음 정리 포인트는 publish 이후 결과물 비교/복구용 파일을 얼마나 더 줄일지 판단하는 것

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hyunho/MH-DashBoard-organization#14