docs: remove section 10 and rename process summary heading

README.md

@@ -1,3 +1,7 @@
 # 샘플 이슈 저장소
 
-## 이슈가 만들어지고 관리하는걸 체험해 봅니다.
+## 이슈가 만들어지고 관리하는걸 체험해 봅니다.
+
+## 문서
+
+- [바이브코딩 대시보드 작업 요약](docs/vibe_coding_dashboard_summary_2026-03-31.md)

docs/vibe_coding_dashboard_summary_2026-03-31.md

@@ -0,0 +1,51 @@
+# 바이브코딩 대시보드 작업 요약
+
+## 무엇을 했는가
+
+기존에는 엑셀 피벗테이블로 데이터를 보고, 필요한 내용을 다시 한글 문서로 옮겨 정리했다.  
+이번에는 그 과정을 줄이기 위해 `사업관리대장`, `프로젝트별 분석`, `팀/개인별 분석`을 한 화면에서 볼 수 있는 대시보드로 만들었다.
+
+## 무엇을 보여주려 했는가
+
+대시보드에서 중심으로 본 것은 프로젝트였다.
+
+- 프로젝트별 매출
+- 프로젝트별 비용
+- 프로젝트별 투입시간
+- 직급별, 팀별, 개인별 인력 투입 현황
+- 전표 데이터와 근무 데이터를 연결한 상세 분석
+
+즉, "얼마를 벌었는가"만이 아니라 "얼마를 썼고, 누가 얼마나 투입됐는가"까지 같이 보려는 목적이었다.
+
+## 기존 방식과의 차이
+
+기존 방식은 사람이 직접 데이터를 조합하고 다시 문서로 옮겨야 했다.  
+바이브코딩으로 만든 대시보드는 데이터를 업로드하면 같은 기준으로 다시 계산하고, 같은 화면에서 반복해서 확인할 수 있다.
+
+- 피벗테이블: 매번 사람이 기준을 잡고 다시 본다
+- 대시보드: 한 번 만든 규칙으로 반복 조회가 가능하다
+- 한글 문서 작업: 복사, 표 정리, 재작성 반복이 많다
+- 대시보드: 화면 자체가 설명자료 역할을 해 반복작업이 줄어든다
+
+## 작업하면서 중요했던 점
+
+가장 중요한 것은 화면보다 데이터였다.
+
+- 컬럼명이 다를 수 있다
+- 프로젝트명이 서로 다를 수 있다
+- 숫자와 날짜 형식이 다를 수 있다
+- 두 개 이상의 데이터를 매칭할 때 누락이 생길 수 있다
+
+그래서 데이터 에러는 반드시 난다고 보고, 결과 화면만 믿지 말고 원본 데이터와 함께 검증해야 한다.
+
+## 효율적으로 하려면
+
+- 먼저 기능을 명확히 정의하기
+- 무엇을 어떻게 보여줄지 정리해서 요청하기
+- 한 번에 너무 많은 수정 요청하지 않기
+- 참고할 디자인이나 기존 코드가 있으면 같이 주기
+- 데이터 오류는 꼭 직접 확인하기
+
+## 한 문장 요약
+
+이번 작업은 엑셀 피벗과 한글 수작업으로 나뉘어 있던 업무를, 프로젝트 기준으로 매출, 비용, 투입시간, 인력구성을 한 번에 볼 수 있는 대시보드로 바꾸는 작업이었다.

docs/대시보드_작업가이드.md

@@ -0,0 +1,152 @@
+# 대시보드 작업가이드
+
+## A. 작업과정 요약
+
+### 0) 이 대시보드에서 내가 기획한 것(표출 의도 분석)
+- 핵심 목적: `사업관리 + 전표 + MH 근무기록`을 한 화면에서 연결해 프로젝트 단위 의사결정을 빠르게 하도록 설계
+- 보고 싶은 질문:
+  - 어떤 프로젝트가 수입/지출/인건비 구조상 건강한가?
+  - 지출은 인건비/출장비/복리후생비/구매비/외주비 중 어디에 집중되는가?
+  - 인력은 어떤 직급이 얼마나(명, 시간, 비율) 투입됐는가?
+  - Activity(서브코드) 기준으로 시간과 투입자가 어떻게 분포되는가?
+- 결과적으로 만든 화면 흐름:
+  - 상단 KPI: 필터 기준 현재 합계 + 전체 합계 비교
+  - 분야별 프로젝트 상세분석: D1/D2/D3, 프로젝트별 수입/지출/지출구성/인력
+  - 지출구성 상세: 그래프+범례+상세내역 연동
+  - 직급별 인원투입 상세: 직급별 시간/인원/비율
+  - 프로젝트별 Activity 분석: 프로젝트별 Activity 시간/인원/투입자
+
+### 1) 기존 업무 방식과 바이브코딩 방식의 차이
+- 기존 방식:
+  - 엑셀 피벗테이블로 각각 데이터 분석
+  - 2개 이상 데이터(전표, MH)를 사람 손으로 조합
+  - 결과를 한글문서로 옮기며 반복 편집/정렬/서식 작업 수행
+- 바이브코딩 방식:
+  - 규칙을 코드로 고정해 매번 같은 방식으로 자동 집계
+  - 여러 데이터 소스를 한 번에 매칭해 같은 기준으로 즉시 재계산
+  - 화면에서 바로 필터/탭/상세 확인 가능(문서 재작성 최소화)
+- 피벗 대비 장점:
+  - 동일 로직 반복 재사용(사람마다 다른 해석/클릭 실수 감소)
+  - UI에서 즉시 drill-down 가능(추가 시트/피벗 재구성 불필요)
+  - 집계 단위(D1/D2/D3, 직급, Activity)를 한번 정의하면 계속 재사용
+- 한글문서 반복작업 축소:
+  - 숫자/표/구조를 코드가 생성하므로 복붙·서식맞춤 반복 감소
+  - 데이터 업데이트 시 문서를 새로 만들기보다 대시보드 재실행으로 대체
+
+### 2) 코딩 시 주의사항(실제 반복됐던 문제 중심)
+- 가장 자주 반복된 문제:
+  - 열 순서 변경(K/O/P/Q/X/Y/AA/U 등)로 잘못된 컬럼 매핑
+  - 프로젝트명 매칭 실패(공백/특수문자/표기 차이/유사명)
+  - 인코딩(euc-kr, utf-8) 불일치로 한글 깨짐
+  - 필터 상태별 소계/합계 행에서 컬럼 밀림
+  - 0원 표기 규칙 불일치(`₩0`, `0원`, `-`)
+  - 브라우저/로컬 환경에 따라 자동 로드 실패
+- 2개 이상 데이터 매칭 시 주의점:
+  - 공통 키를 먼저 고정: `프로젝트명 정규화`, `날짜 형식`, `분류(D1/D2/D3)`
+  - 원본 키 + 정규화 키를 함께 보관(추적 가능성 확보)
+  - 매칭 실패 목록을 별도 로그로 남겨서 눈으로 검증
+  - 우선순위 규칙을 명시(예: 전표 우선 / MH 우선 / 표출순서 CSV 보정)
+  - 샘플 프로젝트 3~5개를 정해 매 수정마다 회귀검증
+
+### 3) 효율적으로 작업하기 위한 실전 방법
+- 기능 정의를 먼저 고정:
+  - 입력/출력/성공기준을 1문장씩 작성 후 개발 시작
+- 아이디어 요청 방식:
+  - “무엇을 왜 보여줄지”를 먼저 정리하고, 화면 예시를 함께 전달
+  - 한 번에 큰 요구보다 작은 단위(레이아웃 → 집계 → 디테일)로 분할 요청
+- 과다 요청 방지:
+  - 한 턴에 1~3개 변경만 요청하고 즉시 검증
+- 디자인 참고 제공:
+  - 원하는 레퍼런스(스크린샷, 사이트)를 주면 시행착오 크게 감소
+- 데이터 에러는 전제:
+  - “에러는 난다”를 기본 가정으로 매핑 로그/검증표를 반드시 확인
+- 기존 코드 참고:
+  - 이미 잘 동작한 버전을 기준 파일로 고정하고 파생본에서 수정
+  - 변경 시 타임스탬프 파일 생성 + 기존 파일 보관
+
+### 발표 마무리 문장(바로 사용 가능)
+- “이번 바이브코딩의 핵심 성과는 데이터 분석 자체보다, 분석 로직을 재사용 가능한 시스템으로 만든 것입니다.”
+- “즉, 엑셀·문서 반복 작업을 줄이고, 데이터가 바뀌어도 같은 기준으로 빠르게 의사결정할 수 있게 만들었습니다.”
+## 1. 목적
+이 가이드는 대시보드 수정 업무에서 시행착오를 줄이고, 작업자가 심리적으로 편안하게 일할 수 있도록 돕기 위한 표준 절차입니다.
+핵심은 "크게 한 번에"가 아니라 "작게 나누고 빠르게 검증"입니다.
+
+## 2. 실제 작업 이력에서 확인된 패턴
+- 2026-03-04: 단일 파일 기반 시작 (`total_share_3.html`)
+- 2026-03-05: 짧은 간격의 복제본 수정 반복 (`...1725`, `...1740`, `...1744`, `...1750`)
+- 2026-03-06: 데이터 처리/임베드 구조 확장 (`total_share_4.html`)
+- 2026-03-10: 목적 분리형으로 발전
+- `사업관리_대시보드(K)_v260310.html`: 통합 허브형(탭, iframe, postMessage)
+- `사업관리_대시보드(H)_v260310.html`: 편집 UX 특화형(모달, 토스트, 상세편집)
+
+해석:
+- 좋은 점: 빠른 실험, 즉시 피드백 반영
+- 어려웠던 점: 파일이 늘수록 최종본 혼선, 중복 수정 가능성 증가
+
+## 3. 시행착오를 줄이는 표준 작업 방식 (SOP)
+1. 시작 전에 5분 정리
+- 이번 작업 목표를 1문장으로 적는다.
+- 예: "사업관리 업로드 후 합계 카드 계산 오류 수정"
+
+2. 기준 파일 1개 고정
+- "이번 작업의 기준 파일"을 명시한다.
+- 파생본을 만들더라도 기준 파일을 잃지 않는다.
+
+3. 변경 단위 분리
+- UI 변경
+- 데이터 파싱/집계 변경
+- 탭/메시지(postMessage) 변경
+- 위 3가지를 한 번에 섞지 않는다.
+
+4. 저장 규칙 통일
+- 파일명 규칙: `이름_YYMMDD_HHMM_변경요약.html`
+- 예: `사업관리_대시보드_K_260320_1530_합계카드수정.html`
+
+5. 매 수정마다 스모크 테스트
+- 업로드 정상 동작
+- 탭 전환 정상 동작
+- 합계/수금률 계산 정상
+- 상세 모달/팝업 표시 정상
+
+6. 종료 시 3줄 기록
+- 무엇을 바꿨는가
+- 왜 바꿨는가
+- 어떻게 검증했는가
+
+## 4. 작업자가 편안해지는 운영 원칙
+- 완벽한 설계보다 작은 성공 1개를 먼저 만든다.
+- "문제 분석"과 "수정 구현"을 분리해 생각한다.
+- 매 단계 완료 기준을 눈으로 확인 가능한 문장으로 둔다.
+- 모호한 요구는 즉시 질문 1개로 좁힌다.
+- 최종 결과물은 1개(`latest`)로 명확히 유지한다.
+
+## 5. 권장 파일 구조
+- `사업관리_대시보드_latest.html` (실사용)
+- `archive/` (시간별 스냅샷)
+- `docs/변경기록.md` (간단 로그)
+
+## 6. 변경 요청을 받을 때 체크리스트
+- 목표가 1문장으로 말해지는가?
+- 수정 범위(허용/금지 파일)가 정해졌는가?
+- 입력 데이터 샘플이 있는가?
+- 성공 기준이 3개 이상 정의됐는가?
+- 완료 후 검증 방법이 정해졌는가?
+
+## 7. 재작업 방지 체크리스트
+- 한글 인코딩(UTF-8) 확인
+- 숫자 파싱 규칙 확인(콤마, 공백, 빈값)
+- 탭 전환 시 상태 유지 확인
+- iframe 통신 실패 시 fallback 처리 확인
+- 오류 메시지(사용자 친화 문구) 확인
+
+## 8. 보고 템플릿 (짧게)
+- 작업 목표: [한 문장]
+- 수정 파일: [파일명]
+- 핵심 변경: [3줄 이내]
+- 검증 결과: [PASS/FAIL + 근거]
+- 잔여 이슈: [있으면 1~2개]
+
+## 9. 이슈 라벨 규칙
+- 기본 라벨: `MH대시보드`
+- 대시보드 관련 이슈는 모두 `MH대시보드` 라벨로 발행/관리한다.
+