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

[P2] [구조정리 후속] organization 레거시 구조 승격 및 장기 고도화 #21

New Issue
Open
opened 2026-04-01 12:21:50 +09:00 by hyunho · 8 comments
hyunho commented 2026-04-01 12:21:50 +09:00
Owner
Copy Link

배경

현재 8081 화면 구성은 다음 방식이 혼재되어 있습니다.

  • 허브: frontend/public/* 자체 코드
  • 팀/개인별 분석: incoming-files/served/mh.html 기반 직접 수정 서빙
  • 프로젝트별 분석: incoming-files/served/payment.html 기반 직접 수정 서빙
  • 사업관리대장: 원본 HTML 기반 + override CSS/JS 주입 구조
  • 조직현황: legacy/static/* 레거시 직접 관리 구조

즉, 프로젝트 안에 원본 직접 수정, 원본+override, 별도 앱/레거시 코드가 섞여 있습니다. 이 구조는 단기적으로는 빠르지만, 장기적으로는 아래 문제가 큽니다.

  • 실제 서비스 코드와 참고 원본의 경계가 흐림
  • 어떤 파일이 진짜 서빙 기준인지 혼선 발생
  • 원본 구조 변경 또는 주입 구조 변경 시 화면이 쉽게 흔들림
  • 디자인 SSOT 적용 범위가 불명확해짐
  • 기능 추가 시 reference / served / override / runtime injection 을 동시에 고려해야 함
  • 유지보수자 입장에서 diff 추적과 회귀 원인 파악이 어려움

현재는 디자인 큐 통일 작업을 우선 진행 중이며, 이 작업이 완료된 뒤 실제 서비스 코드를 독립된 정식 구현물로 고정하는 후속 정리가 필요합니다.

목표

원본 파일은 더 이상 직접 실행/서빙 기준으로 사용하지 않고, 참고용(reference) 으로만 남깁니다.

실제 서비스는 다음 원칙으로 고정합니다.

  • reference는 보관/비교 전용
  • served 또는 정식 앱 디렉터리만 실제 서비스 코드
  • backend route는 reference를 모르고, 실제 서비스 코드만 서빙
  • 디자인은 design-tokens.css 및 DESIGN_SSOT.md 기준만 사용
  • runtime override / 주입 구조는 최소화 또는 제거

왜 필요한가

이 작업을 하면 다음이 가능해집니다.

  • 수정 대상 파일이 명확해짐
  • 원본 파일 구조에 덜 휘둘림
  • 사업관리대장처럼 원본+오버라이드 구조에서 발생한 흔들림 감소
  • 새 기능 추가 시 실제 서비스 코드만 보면 됨
  • 디자인 SSOT를 화면 전체에 일관되게 적용 가능
  • 테스트, diff, 회귀 분석이 쉬워짐

범위

포함

  • reference / served / 실제 서빙 경로 역할 재정의
  • 사업관리대장의 원본 의존 구조 정리
  • backend route가 실제 서비스 코드만 서빙하도록 정리
  • 필요 시 incoming-files/served/*를 화면별 정식 서비스 엔트리로 승격
  • 디자인 SSOT 적용을 방해하는 reference 기반 주입 로직 제거
  • 파일 책임 문서 갱신

제외

  • 디자인 큐 통일 자체 작업 완결
  • 세부 기능 추가
  • 데이터 정합성 수정
  • DB 스키마 개편

선행조건

이 이슈는 현재 진행 중인 디자인 큐 통일 작업 완료 후 시작합니다.

이유:

  • 지금 독립화를 먼저 하면, 곧바로 다시 디자인 구조를 손봐야 해서 중복 작업이 큼
  • 먼저 SSOT/토큰 체계를 안정화해야 독립화된 서비스 코드도 같은 기준으로 굳힐 수 있음

현재 문제 진단

1. 팀/개인별 분석

  • incoming-files/mh.html 와 incoming-files/served/mh.html가 같이 존재
  • 실제 서비스 기준과 작업 기준이 분리돼 보이지만, 역할 정의가 아직 완전히 문서화/고정되지 않음
  • 내부 스타일이 길고, 직접 수정 방식이라 공통 시스���으로 녹이기 어려움

2. 프로젝트별 분석

  • incoming-files/payment.html 와 incoming-files/served/payment.html 구조
  • 실제 서비스는 served 쪽이지만, 원본/작업본이 병행돼 있어 혼선 여지 존재
  • React/Tailwind 기반 하드코딩이 많아 디자인 SSOT 적용과 서비스 코드 독립화가 같이 필요함

3. 사업관리대장

  • 가장 불안정했던 화면
  • 원본 HTML을 기반으로 override CSS/JS를 얹는 구조가 있었고, runtime 주입이 많아질수록 화면 흔들림이 발생함
  • 장기적으로는 정식 서비스 HTML/CSS/JS로 독립시키는 것이 맞음

4. 조직현황

  • 레거시 직접 관리 구조라 비교적 안정적이지만, common/design 체계와 완전히 한 몸은 아님
  • 장기적으로는 화면 책임과 공통 디자인 계층을 더 명확히 해야 함

권장 최종 구조

현실적인 최종안

  • incoming-files/reference/*

    • 외부에서 받은 원본
    • 비교/보관 전용
    • 절대 실제 서빙하지 않음

  • incoming-files/served/*

    • 실제 서비스 HTML/JS/CSS
    • 사용자에게 보이는 진짜 코드
    • 기능 수정 대상은 이것만

  • frontend/public/design-tokens.css

    • 디자인 토큰 SSOT

  • docs/architecture/DESIGN_SSOT.md

    • 고정 규칙 / 해석 규칙 / 신규 패턴 승격 규칙

  • backend/app/main.py 또는 분리된 서빙 라우터

    • reference 경로를 모르고 served/정식 서비스 파일만 응답

장기적으로 더 좋은 구조

화면별 앱 구조로 승격

  • frontend/apps/ledger/
  • frontend/apps/payment/
  • frontend/apps/team/
  • frontend/apps/organization/

다만 이 이슈에서는 여기까지 바로 가지 않고, 우선 served 정식 서비스 코드 독립화 까지를 목표로 합니다.

완료 조건

  • 원본 파일은 실행 기준이 아니라 reference 전용으로만 남아 있음
  • 각 화면마다 실제 서비스 엔트리 파일이 1개로 명확해짐
  • backend route는 실제 서비스 엔트리만 서빙함
  • 사업관리대장이 원본 기반 주입/override 중심 구조에서 벗어남
  • served와 reference의 역할이 문서와 코드에서 일치함
  • 디자인 SSOT 적용 대상이 실제 서비스 코드 기준으로 고정됨

제안 작업 순서

  1. 현재 화면별 실제 서빙 파일 재확인
  2. reference / served / legacy / frontend/public 책임 문서화
  3. backend route 정리
  4. 사업관리대장 독립화
  5. 팀/개인별 분석 / 프로젝트별 분석의 기준 파일 고정
  6. 사용하지 않는 원본 직접 참조 제거
  7. 회귀 점검

검증 포인트

  • 8081에서 사업관리대장 / 프로젝트별 분석 / 팀개인별 분석 / 조직현황이 기존과 동일하게 열리는지
  • route 변경 후 기존 iframe 링크가 유지되는지
  • 디자인 토큰이 reference가 아닌 실제 서비스 코드에 적용되는지
  • 특정 화면을 수정할 때 reference가 아니라 served/정식 파일만 보면 되는지

메모

이 이슈는 구조 안정화와 유지보수성 개선을 위한 후속 작업입니다.
우선순위는 높지만, 현재 진행 중인 디자인 큐 통일 작업이 끝난 뒤 착수하는 것이 가장 효율적입니다.

## 배경 현재 8081 화면 구성은 다음 방식이 혼재되어 있습니다. - 허브: `frontend/public/*` 자체 코드 - 팀/개인별 분석: `incoming-files/served/mh.html` 기반 직접 수정 서빙 - 프로젝트별 분석: `incoming-files/served/payment.html` 기반 직접 수정 서빙 - 사업관리대장: 원본 HTML 기반 + override CSS/JS 주입 구조 - 조직현황: `legacy/static/*` 레거시 직접 관리 구조 즉, 프로젝트 안에 **원본 직접 수정**, **원본+override**, **별도 앱/레거시 코드**가 섞여 있습니다. 이 구조는 단기적으로는 빠르지만, 장기적으로는 아래 문제가 큽니다. - 실제 서비스 코드와 참고 원본의 경계가 흐림 - 어떤 파일이 진짜 서빙 기준인지 혼선 발생 - 원본 구조 변경 또는 주입 구조 변경 시 화면이 쉽게 흔들림 - 디자인 SSOT 적용 범위가 불명확해짐 - 기능 추가 시 reference / served / override / runtime injection 을 동시에 고려해야 함 - 유지보수자 입장에서 diff 추적과 회귀 원인 파악이 어려움 현재는 디자인 큐 통일 작업을 우선 진행 중이며, 이 작업이 완료된 뒤 **실제 서비스 코드를 독립된 정식 구현물로 고정**하는 후속 정리가 필요합니다. ## 목표 원본 파일은 더 이상 직접 실행/서빙 기준으로 사용하지 않고, **참고용(reference)** 으로만 남깁니다. 실제 서비스는 다음 원칙으로 고정합니다. - `reference`는 보관/비교 전용 - `served` 또는 정식 앱 디렉터리만 실제 서비스 코드 - backend route는 reference를 모르고, 실제 서비스 코드만 서빙 - 디자인은 `design-tokens.css` 및 `DESIGN_SSOT.md` 기준만 사용 - runtime override / 주입 구조는 최소화 또는 제거 ## 왜 필요한가 이 작업을 하면 다음이 가능해집니다. - 수정 대상 파일이 명확해짐 - 원본 파일 구조에 덜 휘둘림 - 사업관리대장처럼 원본+오버라이드 구조에서 발생한 흔들림 감소 - 새 기능 추가 시 실제 서비스 코드만 보면 됨 - 디자인 SSOT를 화면 전체에 일관되게 적용 가능 - 테스트, diff, 회귀 분석이 쉬워짐 ## 범위 ### 포함 - reference / served / 실제 서빙 경로 역할 재정의 - 사업관리대장의 원본 의존 구조 정리 - backend route가 실제 서비스 코드만 서빙하도록 정리 - 필요 시 `incoming-files/served/*`를 화면별 정식 서비스 엔트리로 승격 - 디자인 SSOT 적용을 방해하는 reference 기반 주입 로직 제거 - 파일 책임 문서 갱신 ### 제외 - 디자인 큐 통일 자체 작업 완결 - 세부 기능 추가 - 데이터 정합성 수정 - DB 스키마 개편 ## 선행조건 이 이슈는 **현재 진행 중인 디자인 큐 통일 작업 완료 후** 시작합니다. 이유: - 지금 독립화를 먼저 하면, 곧바로 다시 디자인 구조를 손봐야 해서 중복 작업이 큼 - 먼저 SSOT/토큰 체계를 안정화해야 독립화된 서비스 코드도 같은 기준으로 굳힐 수 있음 ## 현재 문제 진단 ### 1. 팀/개인별 분석 - `incoming-files/mh.html` 와 `incoming-files/served/mh.html`가 같이 존재 - 실제 서비스 기준과 작업 기준이 분리돼 보이지만, 역할 정의가 아직 완전히 문서화/고정되지 않음 - 내부 스타일이 길고, 직접 수정 방식이라 공통 시스���으로 녹이기 어려움 ### 2. 프로젝트별 분석 - `incoming-files/payment.html` 와 `incoming-files/served/payment.html` 구조 - 실제 서비스는 served 쪽이지만, 원본/작업본이 병행돼 있어 혼선 여지 존재 - React/Tailwind 기반 하드코딩이 많아 디자인 SSOT 적용과 서비스 코드 독립화가 같이 필요함 ### 3. 사업관리대장 - 가장 불안정했던 화면 - 원본 HTML을 기반으로 override CSS/JS를 얹는 구조가 있었고, runtime 주입이 많아질수록 화면 흔들림이 발생함 - 장기적으로는 정식 서비스 HTML/CSS/JS로 독립시키는 것이 맞음 ### 4. 조직현황 - 레거시 직접 관리 구조라 비교적 안정적이지만, common/design 체계와 완전히 한 몸은 아님 - 장기적으로는 화면 책임과 공통 디자인 계층을 더 명확히 해야 함 ## 권장 최종 구조 ### 현실적인 최종안 - `incoming-files/reference/*` - 외부에서 받은 원본 - 비교/보관 전용 - 절대 실제 서빙하지 않음 - `incoming-files/served/*` - 실제 서비스 HTML/JS/CSS - 사용자에게 보이는 진짜 코드 - 기능 수정 대상은 이것만 - `frontend/public/design-tokens.css` - 디자인 토큰 SSOT - `docs/architecture/DESIGN_SSOT.md` - 고정 규칙 / 해석 규칙 / 신규 패턴 승격 규칙 - `backend/app/main.py` 또는 분리된 서빙 라우터 - reference 경로를 모르고 served/정식 서비스 파일만 응답 ### 장기적으로 더 좋은 구조 화면별 앱 구조로 승격 - `frontend/apps/ledger/` - `frontend/apps/payment/` - `frontend/apps/team/` - `frontend/apps/organization/` 다만 이 이슈에서는 여기까지 바로 가지 않고, 우선 **served 정식 서비스 코드 독립화** 까지를 목표로 합니다. ## 완료 조건 - 원본 파일은 실행 기준이 아니라 reference 전용으로만 남아 있음 - 각 화면마다 실제 서비스 엔트리 파일이 1개로 명확해짐 - backend route는 실제 서비스 엔트리만 서빙함 - 사업관리대장이 원본 기반 주입/override 중심 구조에서 벗어남 - `served`와 `reference`의 역할이 문서와 코드에서 일치함 - 디자인 SSOT 적용 대상이 실제 서비스 코드 기준으로 고정됨 ## 제안 작업 순서 1. 현재 화면별 실제 서빙 파일 재확인 2. `reference` / `served` / `legacy` / `frontend/public` 책임 문서화 3. backend route 정리 4. 사업관리대장 독립화 5. 팀/개인별 분석 / 프로젝트별 분석의 기준 파일 고정 6. 사용하지 않는 원본 직접 참조 제거 7. 회귀 점검 ## 검증 포인트 - `8081`에서 사업관리대장 / 프로젝트별 분석 / 팀개인별 분석 / 조직현황이 기존과 동일하게 열리는지 - route 변경 후 기존 iframe 링크가 유지되는지 - 디자인 토큰이 reference가 아닌 실제 서비스 코드에 적용되는지 - 특정 화면을 수정할 때 reference가 아니라 served/정식 파일만 보면 되는지 ## 메모 이 이슈는 구조 안정화와 유지보수성 개선을 위한 후속 작업입니다. 우선순위는 높지만, **현재 진행 중인 디자인 큐 통일 작업이 끝난 뒤 착수**하는 것이 가장 효율적입니다.
hyunho commented 2026-04-01 14:02:49 +09:00
Author
Owner
Copy Link

후속 구조 정리 전 단계로, reference 의존 제거를 준비하기 위한 디자인 기준 승격을 먼저 완료했습니다.

이번 선행 작업:

  • design-tokens.css / design-patterns.css를 공식 런타임 디자인 기준으로 승격
  • 허브, 조직현황, 팀/개인별 분석, 프로젝트별 분석, 사업관리대장 상세 팝업이 이 기준을 직접 참조하도록 정리
  • 체크포인트/룰북/실행 플로우에 디자인 수정 우선 경로를 문서화

의미:

  • 이제 reference/original 파일을 직접 디자인 기준으로 삼지 않고, SSOT 토큰/패턴을 먼저 수정하는 운영으로 넘어갈 수 있음
  • 다음 단계인 실제 서비스 코드 독립화(#21)에서 reference 의존 제거를 진행하기 쉬운 상태가 됨

커밋: fb5b0f0 feat: unify 8081 dashboard design system and views

후속 구조 정리 전 단계로, reference 의존 제거를 준비하기 위한 디자인 기준 승격을 먼저 완료했습니다. 이번 선행 작업: - `design-tokens.css` / `design-patterns.css`를 공식 런타임 디자인 기준으로 승격 - 허브, 조직현황, 팀/개인별 분석, 프로젝트별 분석, 사업관리대장 상세 팝업이 이 기준을 직접 참조하도록 정리 - 체크포인트/룰북/실행 플로우에 `디자인 수정 우선 경로`를 문서화 의미: - 이제 reference/original 파일을 직접 디자인 기준으로 삼지 않고, SSOT 토큰/패턴을 먼저 수정하는 운영으로 넘어갈 수 있음 - 다음 단계인 실제 서비스 코드 독립화(#21)에서 reference 의존 제거를 진행하기 쉬운 상태가 됨 커밋: `fb5b0f0 feat: unify 8081 dashboard design system and views`
hyunho commented 2026-04-01 14:13:51 +09:00
Author
Owner
Copy Link

#21 1차 진행 상황

8081 사업관리대장 runtime이 더 이상 incoming-files/사업관리대장/MH 통합 대시보드_260320.html wrapper를 decode해서 서빙하지 않도록 정리함.

반영 내용:

  • 실제 서비스 경로를 incoming-files/served/ledger/로 승격
  • served/ledger/index.html 생성: 기존 wrapper 내부 base64 원본을 추출한 정식 runtime entry 파일
  • served/ledger/MH 통합 대시보드_260320.css, served/ledger/ledger-override.css, served/ledger/ledger-override.js, served/ledger/사업관리대장-1.xlsx 복제
  • backend /integrations/ledger는 이제 served/ledger/index.html만 응답
  • backend /integrations/ledger-assets/*는 이제 served/ledger/*만 정적 서빙
  • startup 기본 원본 DB 동기화도 우선 served/ledger/사업관리대장-1.xlsx를 봄
  • serving map / incoming-files 문서 / 체크포인트 갱신

검증:

  • backend py_compile 통과
  • served/ledger/ledger-override.js 문법 체크 통과
  • dev backend 내부에서 /integrations/ledger 200 확인
  • dev backend 내부에서 /integrations/ledger-assets/ledger-override.js 200 확인

의미:

  • 원본 사업관리대장/*는 이제 비교용/reference 역할만 남고, runtime 직접 의존은 제거된 상태
  • 다음 단계는 reference 실제 재배치와 화면별 앱 구조 승격 검토
#21 1차 진행 상황 `8081` 사업관리대장 runtime이 더 이상 `incoming-files/사업관리대장/MH 통합 대시보드_260320.html` wrapper를 decode해서 서빙하지 않도록 정리함. 반영 내용: - 실제 서비스 경로를 `incoming-files/served/ledger/`로 승격 - `served/ledger/index.html` 생성: 기존 wrapper 내부 base64 원본을 추출한 정식 runtime entry 파일 - `served/ledger/MH 통합 대시보드_260320.css`, `served/ledger/ledger-override.css`, `served/ledger/ledger-override.js`, `served/ledger/사업관리대장-1.xlsx` 복제 - backend `/integrations/ledger`는 이제 `served/ledger/index.html`만 응답 - backend `/integrations/ledger-assets/*`는 이제 `served/ledger/*`만 정적 서빙 - startup 기본 원본 DB 동기화도 우선 `served/ledger/사업관리대장-1.xlsx`를 봄 - serving map / incoming-files 문서 / 체크포인트 갱신 검증: - backend `py_compile` 통과 - `served/ledger/ledger-override.js` 문법 체크 통과 - dev backend 내부에서 `/integrations/ledger` 200 확인 - dev backend 내부에서 `/integrations/ledger-assets/ledger-override.js` 200 확인 의미: - 원본 `사업관리대장/*`는 이제 비교용/reference 역할만 남고, runtime 직접 의존은 제거된 상태 - 다음 단계는 reference 실제 재배치와 화면별 앱 구조 승격 검토
hyunho commented 2026-04-01 14:16:12 +09:00
Author
Owner
Copy Link

#21 2차 진행 상황

reference 실제 재배치까지 진행함.

반영 내용:

  • 기존 incoming-files/사업관리대장/ 디렉터리를 incoming-files/reference/ledger/로 이동
  • runtime은 계속 incoming-files/served/ledger/*만 사용
  • prepare_dev_worktree.sh도 이제 incoming-files/reference/ledger/를 복사하도록 갱신
  • incoming-files/README.md, incoming-files/reference/README.md, incoming-files/served/README.md, docs/architecture/8081_SERVING_MAP.md, docs/DEV_PROD_DB_PROTOCOL.md, docs/NEXT_SESSION_CHECKPOINT.md 경로 기준 갱신

검증:

  • backend py_compile 통과
  • prepare_dev_worktree.sh 두 경로 모두 bash -n 통과
  • dev backend 내부에서 /integrations/ledger 200, /integrations/ledger-assets/ledger-override.css 200 재확인

현재 상태:

  • 사업관리대장은 경로 기준으로도 served / reference가 분리된 상태
  • 다음 단계 후보는 화면별 앱 구조 승격 검토
#21 2차 진행 상황 reference 실제 재배치까지 진행함. 반영 내용: - 기존 `incoming-files/사업관리대장/` 디렉터리를 `incoming-files/reference/ledger/`로 이동 - runtime은 계속 `incoming-files/served/ledger/*`만 사용 - `prepare_dev_worktree.sh`도 이제 `incoming-files/reference/ledger/`를 복사하도록 갱신 - `incoming-files/README.md`, `incoming-files/reference/README.md`, `incoming-files/served/README.md`, `docs/architecture/8081_SERVING_MAP.md`, `docs/DEV_PROD_DB_PROTOCOL.md`, `docs/NEXT_SESSION_CHECKPOINT.md` 경로 기준 갱신 검증: - backend `py_compile` 통과 - `prepare_dev_worktree.sh` 두 경로 모두 `bash -n` 통과 - dev backend 내부에서 `/integrations/ledger` 200, `/integrations/ledger-assets/ledger-override.css` 200 재확인 현재 상태: - 사업관리대장은 경로 기준으로도 `served` / `reference`가 분리된 상태 - 다음 단계 후보는 `화면별 앱 구조 승격` 검토
hyunho commented 2026-04-01 14:21:05 +09:00
Author
Owner
Copy Link

#21 3차 진행 상황

사업관리대장 화면별 앱 구조 승격의 첫 단계로 source-of-truth 위치를 별도 앱 디렉터리로 분리함.

반영 내용:

  • frontend/apps/ledger/ 생성
  • 현재 runtime served/ledger 파일을 앱 소스 경로로 복제
    • frontend/apps/ledger/index.html
    • frontend/apps/ledger/assets/MH 통합 대시보드_260320.css
    • frontend/apps/ledger/assets/ledger-override.css
    • frontend/apps/ledger/assets/ledger-override.js
  • scripts/publish_ledger_app.sh 추가
    • 앱 소스 -> incoming-files/served/ledger/* publish 역할
  • 문서 갱신
    • NEXT_SESSION_CHECKPOINT.md
    • 8081_SERVING_MAP.md
    • incoming-files/served/ledger/README.md

검증:

  • publish_ledger_app.sh 문법 체크 통과
  • publish 실행 후 app source 와 served ledger 주요 파일 일치 확인
  • dev backend 내부에서 /integrations/ledger 200, /integrations/ledger-assets/ledger-override.js 200 재확인

현재 의미:

  • runtime은 아직 served/ledger를 사용하지만, 수정 원본은 frontend/apps/ledger로 올려두는 구조가 생김
  • 다음 단계에서는 ledger 내부 자산/스크립트 정리를 더 진행하거나, 같은 패턴을 payment/mh에도 확장 가능
#21 3차 진행 상황 `사업관리대장` 화면별 앱 구조 승격의 첫 단계로 source-of-truth 위치를 별도 앱 디렉터리로 분리함. 반영 내용: - `frontend/apps/ledger/` 생성 - 현재 runtime `served/ledger` 파일을 앱 소스 경로로 복제 - `frontend/apps/ledger/index.html` - `frontend/apps/ledger/assets/MH 통합 대시보드_260320.css` - `frontend/apps/ledger/assets/ledger-override.css` - `frontend/apps/ledger/assets/ledger-override.js` - `scripts/publish_ledger_app.sh` 추가 - 앱 소스 -> `incoming-files/served/ledger/*` publish 역할 - 문서 갱신 - `NEXT_SESSION_CHECKPOINT.md` - `8081_SERVING_MAP.md` - `incoming-files/served/ledger/README.md` 검증: - `publish_ledger_app.sh` 문법 체크 통과 - publish 실행 후 app source 와 served ledger 주요 파일 일치 확인 - dev backend 내부에서 `/integrations/ledger` 200, `/integrations/ledger-assets/ledger-override.js` 200 재확인 현재 의미: - runtime은 아직 `served/ledger`를 사용하지만, 수정 원본은 `frontend/apps/ledger`로 올려두는 구조가 생김 - 다음 단계에서는 ledger 내부 자산/스크립트 정리를 더 진행하거나, 같은 패턴을 payment/mh에도 확장 가능
hyunho commented 2026-04-01 14:25:48 +09:00
Author
Owner
Copy Link

#21 4차 진행 상황

프로젝트별 분석(payment)도 같은 방식으로 화면별 앱 구조 승격 1차를 적용함.

반영 내용:

  • frontend/apps/payment/index.html 생성: 프로젝트별 분석 source-of-truth
  • frontend/apps/payment/README.md 추가
  • scripts/publish_payment_app.sh 추가
    • frontend/apps/payment/index.html -> incoming-files/served/payment.html
    • 동시에 incoming-files/payment.html 비교용 복사본도 갱신
  • 문서 갱신
    • incoming-files/served/README.md
    • docs/architecture/8081_SERVING_MAP.md
    • docs/NEXT_SESSION_CHECKPOINT.md

검증:

  • publish_payment_app.sh 문법 체크 통과
  • publish 실행 후 frontend/apps/payment/index.html == incoming-files/served/payment.html
  • publish 실행 후 frontend/apps/payment/index.html == incoming-files/payment.html
  • dev backend 내부에서 /integrations/payment 응답 확인
  • 응답 본문에 const App = () =>, /design-patterns.css 포함 확인

현재 의미:

  • ledger, payment 둘 다 runtime served 파일과 수정 원본이 분리됨
  • 다음 후보는 mh에도 같은 패턴 확장, 또는 이 상태에서 데이터 정합성/세부 기능 작업 진행
#21 4차 진행 상황 `프로젝트별 분석(payment)`도 같은 방식으로 화면별 앱 구조 승격 1차를 적용함. 반영 내용: - `frontend/apps/payment/index.html` 생성: 프로젝트별 분석 source-of-truth - `frontend/apps/payment/README.md` 추가 - `scripts/publish_payment_app.sh` 추가 - `frontend/apps/payment/index.html` -> `incoming-files/served/payment.html` - 동시에 `incoming-files/payment.html` 비교용 복사본도 갱신 - 문서 갱신 - `incoming-files/served/README.md` - `docs/architecture/8081_SERVING_MAP.md` - `docs/NEXT_SESSION_CHECKPOINT.md` 검증: - `publish_payment_app.sh` 문법 체크 통과 - publish 실행 후 `frontend/apps/payment/index.html` == `incoming-files/served/payment.html` - publish 실행 후 `frontend/apps/payment/index.html` == `incoming-files/payment.html` - dev backend 내부에서 `/integrations/payment` 응답 확인 - 응답 본문에 `const App = () =>`, `/design-patterns.css` 포함 확인 현재 의미: - `ledger`, `payment` 둘 다 runtime served 파일과 수정 원본이 분리됨 - 다음 후보는 `mh`에도 같은 패턴 확장, 또는 이 상태에서 데이터 정합성/세부 기능 작업 진행
hyunho commented 2026-04-01 14:27:33 +09:00
Author
Owner
Copy Link

#21 5차 진행 상황

팀/개인별 분석(mh)도 같은 방식으로 화면별 앱 구조 승격 1차를 적용함.

반영 내용:

  • frontend/apps/team/index.html 생성: 팀/개인별 분석 source-of-truth
  • frontend/apps/team/README.md 추가
  • scripts/publish_team_app.sh 추가
    • frontend/apps/team/index.html -> incoming-files/served/mh.html
    • 동시에 incoming-files/mh.html 비교용 복사본도 갱신
  • 문서 갱신
    • incoming-files/served/README.md
    • docs/architecture/8081_SERVING_MAP.md
    • docs/NEXT_SESSION_CHECKPOINT.md

검증:

  • publish_team_app.sh 문법 체크 통과
  • publish 실행 후 frontend/apps/team/index.html == incoming-files/served/mh.html
  • publish 실행 후 frontend/apps/team/index.html == incoming-files/mh.html
  • dev backend 내부에서 /integrations/mh 응답 확인
  • 응답 본문에 <title>팀/개인별 분석</title>, /design-tokens.css?v=20260401-01 포함 확인

현재 구조 상태:

  • ledger, payment, mh 모두 앱 소스 -> publish -> served 구조로 맞춰짐
  • reference / served / app source 역할이 분리된 상태
  • 다음 단계는 이 상태에서 데이터 정합성/세부 기능 작업 진행, 또는 더 깊은 모듈화 검토
#21 5차 진행 상황 `팀/개인별 분석(mh)`도 같은 방식으로 화면별 앱 구조 승격 1차를 적용함. 반영 내용: - `frontend/apps/team/index.html` 생성: 팀/개인별 분석 source-of-truth - `frontend/apps/team/README.md` 추가 - `scripts/publish_team_app.sh` 추가 - `frontend/apps/team/index.html` -> `incoming-files/served/mh.html` - 동시에 `incoming-files/mh.html` 비교용 복사본도 갱신 - 문서 갱신 - `incoming-files/served/README.md` - `docs/architecture/8081_SERVING_MAP.md` - `docs/NEXT_SESSION_CHECKPOINT.md` 검증: - `publish_team_app.sh` 문법 체크 통과 - publish 실행 후 `frontend/apps/team/index.html` == `incoming-files/served/mh.html` - publish 실행 후 `frontend/apps/team/index.html` == `incoming-files/mh.html` - dev backend 내부에서 `/integrations/mh` 응답 확인 - 응답 본문에 `<title>팀/개인별 분석</title>`, `/design-tokens.css?v=20260401-01` 포함 확인 현재 구조 상태: - `ledger`, `payment`, `mh` 모두 `앱 소스 -> publish -> served` 구조로 맞춰짐 - reference / served / app source 역할이 분리된 상태 - 다음 단계는 이 상태에서 데이터 정합성/세부 기능 작업 진행, 또는 더 깊은 모듈화 검토
hyunho commented 2026-04-01 14:30:03 +09:00
Author
Owner
Copy Link

#21 현재 정리 상태 요약

이번 차수 기준으로 8081 integration 화면 구조는 아래처럼 정리됨.

완료된 구조 분리

  • reference
    • 원본/복구/비교용 자산만 유지
    • 사업관리대장 원본은 incoming-files/reference/ledger/로 이동
  • served
    • 실제 backend가 직접 서빙하는 runtime 파일만 유지
    • incoming-files/served/ledger/*
    • incoming-files/served/payment.html
    • incoming-files/served/mh.html
  • app source
    • 수정 원본 위치를 화면별로 분리
    • frontend/apps/ledger/*
    • frontend/apps/payment/index.html
    • frontend/apps/team/index.html

publish 흐름

  • ledger: scripts/publish_ledger_app.sh
  • payment: scripts/publish_payment_app.sh
  • team: scripts/publish_team_app.sh

즉 앞으로는 화면 수정 시 served 파일을 직접 먼저 고치지 않고, app source를 수정한 뒤 publish로 반영하는 구조를 기준으로 본다.

현재 남아 있는 범위

  • organization은 아직 레거시 직접 관리 구조
  • 조직현황은 이후 별도 이슈/차수로 앱 구조 승격 검토
  • 현재 시점에서는 구조 안정화가 끝났으므로, 다음 우선순위는 세부 데이터 정합성/기능 작업으로 보는 것이 맞음
#21 현재 정리 상태 요약 이번 차수 기준으로 `8081` integration 화면 구조는 아래처럼 정리됨. ## 완료된 구조 분리 - `reference` - 원본/복구/비교용 자산만 유지 - 사업관리대장 원본은 `incoming-files/reference/ledger/`로 이동 - `served` - 실제 backend가 직접 서빙하는 runtime 파일만 유지 - `incoming-files/served/ledger/*` - `incoming-files/served/payment.html` - `incoming-files/served/mh.html` - `app source` - 수정 원본 위치를 화면별로 분리 - `frontend/apps/ledger/*` - `frontend/apps/payment/index.html` - `frontend/apps/team/index.html` ## publish 흐름 - `ledger`: `scripts/publish_ledger_app.sh` - `payment`: `scripts/publish_payment_app.sh` - `team`: `scripts/publish_team_app.sh` 즉 앞으로는 화면 수정 시 served 파일을 직접 먼저 고치지 않고, app source를 수정한 뒤 publish로 반영하는 구조를 기준으로 본다. ## 현재 남아 있는 범위 - `organization`은 아직 레거시 직접 관리 구조 - 조직현황은 이후 별도 이슈/차수로 앱 구조 승격 검토 - 현재 시점에서는 구조 안정화가 끝났으므로, 다음 우선순위는 세부 데이터 정합성/기능 작업으로 보는 것이 맞음
hyunho commented 2026-04-01 14:39:29 +09:00
Author
Owner
Copy Link

현재 기준으로 핵심 목표는 거의 달성됨.

완료된 범위:

  • reference / served / app source 역할 분리
  • ledger, payment, mh를 앱 소스 -> publish -> served 구조로 정리
  • 사업관리대장 runtime의 reference 직접 의존 제거

남은 범위:

  • organization 화면의 동일 구조 승격 검토
  • 필요 시 더 깊은 내부 모듈화 / 빌드 체계 고도화

즉 이제는 구조 안정화 핵심 이슈라기보다, 남은 레거시 화면과 장기 고도화 이슈에 가까움.

현재 기준으로 핵심 목표는 거의 달성됨. 완료된 범위: - reference / served / app source 역할 분리 - `ledger`, `payment`, `mh`를 `앱 소스 -> publish -> served` 구조로 정리 - 사업관리대장 runtime의 reference 직접 의존 제거 남은 범위: - `organization` 화면의 동일 구조 승격 검토 - 필요 시 더 깊은 내부 모듈화 / 빌드 체계 고도화 즉 이제는 구조 안정화 핵심 이슈라기보다, 남은 레거시 화면과 장기 고도화 이슈에 가까움.
hyunho changed title from [P1] [구조정리 후속] reference 의존 제거 및 8081 실제 서비스 코드 독립화 to [P2] [구조정리 후속] organization 레거시 구조 승격 및 장기 고도화 2026-04-01 14:39:33 +09:00
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#21
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?