eomsangdonandClaude Opus 5
eb30b774f8
- `docs/` 를 .gitignore 에서 빼 git 추적 대상으로 전환 (위키·완료 이력·검증 기록) - `docs/raw/PLAN.md` · `docs/raw/OWNERS.md` 를 저장소 최상위로 이동 후 .gitignore 에 등록 — 창끼리 공유하되 저장소에는 안 올리는 장부 - 살아 있는 경로 참조 7개 파일 정정 (아카이브 107건은 그때 사실이라 그대로 둠) - graphify 날짜별 산출물(`docs/wiki/graphify-out/20*/`) 제외 — `graphify update` 가 다시 만듦 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
171 lines
12 KiB
Markdown
171 lines
12 KiB
Markdown
# OWNERS 이력 이관 — 2026-09-09 (장부에서 뗀 실사례·실측)
|
||
|
||
> **`docs/raw/OWNERS.md` 에서 옮긴 원문임. 줄이지 않았음.**
|
||
> 옮긴 까닭 — 그 파일은 **누가 어디서 무엇을 쓰는지 적는 장부**인데
|
||
> **개발 이력·실사례 서술**이 절반을 넘게 차지하고 있었음(2026-09-09 사용자 지시).
|
||
> 장부에는 **규칙만** 남겼음. 위키화는 다른 AI 몫.
|
||
|
||
|
||
## 저장소 통째 시놀로지 동기화 — 실사고 기록 (2026-09-07)
|
||
|
||
## ⚠⚠ 저장소가 통째로 시놀로지 동기화됨 (2026-09-07 발견 — git 밖의 두 번째 경로)
|
||
|
||
**`docs/` 만 링크인 줄 알았으나 아님. 저장소 폴더 전체가 PC 사이로 동기화되고 있음.**
|
||
증거 — 랩탑 상위 폴더 `C:\Program_coding\` 에 `.SynologyWorkingDirectory` 가 있고
|
||
그 아래에 저장소 폴더가 통째로 들어 있음 (laptop-main 창 실물 확인).
|
||
|
||
**그래서 생기는 것 — 실사고 1건이 이미 남**
|
||
|
||
- **커밋 전 작업물이 PC 사이로 새어 나감.** 데스크탑이 `main.py` 에 넣은 등록 두 줄이
|
||
랩탑 폴더에 나타났고, **정작 새 라우터 파일은 아직 안 건너와** 랩탑 서버가
|
||
`ModuleNotFoundError` 로 죽었음 (2026-09-07 20:07).
|
||
- **git 은 한 커밋이라도 파일 동기화는 파일 단위·시간차** — 그래서
|
||
「수정분만 먼저 도착하고 새 파일은 나중」인 **반쪽 상태**가 생김.
|
||
git 경로로는 절대 못 생기는 모양이라 원인 추적이 오래 걸림.
|
||
- **남의 미커밋 편집이 내 워킹트리를 덮을 수 있음.**
|
||
- **autopush 폴백(`auto:` 커밋)이 남의 편집을 주워 담음** — 랩탑 `e46b89df` 가
|
||
데스크탑에서 새어 온 편집을 자동 커밋함.
|
||
|
||
|
||
## DB 한 벌을 여러 환경이 같이 씀 — 실사례·원인·세 번째 통로 (2026-09-08)
|
||
|
||
## ⚠⚠ DB 한 벌을 4환경이 같이 씀 — 자료가 발밑에서 바뀜 (2026-09-08 실사례)
|
||
|
||
`.env` 의 `DB_HOST=dsm.chemifactory.com` · `DB_NAME=aislo_db` — **로컬 DB 가 아니라 원격 공용 서버 한 대**임.
|
||
이 표 위쪽 「자원 점유」에 이미 적혀 있으나 **스키마·세션 이야기로만 읽혀 왔음.**
|
||
**진짜 무서운 것은 자료임** — 어느 창이든 그 프로젝트로 종단·횡단을 다시 돌리면
|
||
**코드를 하나도 안 건드려도 나머지 세 창의 값이 그 자리에서 바뀜.**
|
||
|
||
**실사례 (2026-09-08 06:00)** — 데스크탑 두 창이 「성토 물량이 +1.14 % 움직인」 것을
|
||
반나절 추적함. 커밋 diff·계산 코드·설정을 다 뒤졌으나 **코드 탓이 아니었고**,
|
||
**공용 DB 의 단면 자료가 다른 환경에서 갱신된 것**이었음.
|
||
```
|
||
route 169 단면 DB 105측점 ↔ 저장 파일 63장 ← 어긋나 있음
|
||
fill_volume_m3 15,718.081 → 15,897.028 (+178.947)
|
||
B05_Profile/route/ 폴더 mtime 09-08 04:38 (안의 파일은 09-07)
|
||
```
|
||
|
||
**규칙**
|
||
1. **값이 움직였는데 코드 diff 에 없으면 「남의 창이 자료를 바꿨나」를 먼저 볼 것.**
|
||
오늘은 코드부터 뒤져 시간을 버렸음.
|
||
2. **되받기 전후로 산출을 파일에 떠 둘 것.** 그래야 「어느 줄이 얼마나」로 말할 수 있음.
|
||
B08 은 `tmp/snapshot_b08.py before|after` 를 둠(읽기 전용, `tmp/` 라 git 밖).
|
||
3. **남의 프로젝트로 [저장]·[확정]·자동체인을 돌리지 말 것.** 검증용 프로젝트는 환경마다 따로.
|
||
4. **[해소] `cross_sections` 시각 칸 — 안 넣기로 확정** (2026-09-08 사용자).
|
||
**까닭 — 검증용 프로젝트를 워크트리마다 나누기로 확정했으므로 남의 값이 안 흔들림.**
|
||
즉 「누가 언제 바꿨나」를 추적할 일이 없어짐. **마이그레이션 020~ 계획은 취소.**
|
||
⚠ 대신 **프로젝트 나눔이 곧 안전장치**이므로 아래 표를 반드시 지킬 것.
|
||
5. **[해소] DB 105 ↔ 파일 63 은 어긋난 것이 아님** (2026-09-08 laptop-main 실측).
|
||
`cross_sections` 105행은 **설계 정본**(`data.design`, 전부 `CONFIRMED`) — 20m 배수 55 +
|
||
구조물·곡선 등 불규칙 50. 파일 63장은 그 계산의 **입력인 지반 샘플**이고 파일명이
|
||
`cross_00020m` 꼴 **정수 미터**라 소수 누가거리(258.122 등)는 파일로 안 떨어짐.
|
||
**⇒ 수량은 DB 를 봄. 파일은 입력.**
|
||
|
||
### [해소] 위 실사례의 원인 (2026-09-08 laptop-main 자진 보고)
|
||
|
||
**laptop-main 이 사용자 지시로 `5601e828` 실화면 검증을 하며 [확정] 1회·[저장] 여러 번**을
|
||
불렀음. 확정이 **전 측점을 다시 계산**해 성토가 +178.947㎥ 움직였음.
|
||
`B05_Profile/route/` mtime 09-08 04:38 = 그 창의 마지막 구조물 저장.
|
||
**의도된 조작이었고, 그것이 다른 창 값에 닿는다는 것을 몰랐던 것이 전부임.**
|
||
|
||
**⇒ 그래서 규칙 6 을 더함 — 실화면 검증으로 [확정]·[저장]을 부르기 전에 알릴 것.**
|
||
laptop-main 이 앞으로 그렇게 하기로 함(2026-09-08 합의). 남의 프로젝트면 특히.
|
||
**추적 수단(`updated_at`·`updated_by`)이 없는 동안은 이 통보가 유일한 방법임.**
|
||
스키마 보강은 B06 소관(laptop-main)이 **사용자 확정 뒤 마이그레이션 020~ 으로** 넣기로 함.
|
||
|
||
### ⚠ 세 번째 통로 — [저장]도 전 측점을 다시 계산함 (2026-09-08 laptop-main 실측)
|
||
|
||
같은 프로젝트 값이 **두 번째로** 움직였음. 이번엔 [확정] 없이 **[저장] 두 번**뿐이었는데도
|
||
토공이 −14~−19 %(토사) / +16 %(암) / 성토 −16.81 % 로 갈렸음.
|
||
|
||
**⇒ 까닭은 「무엇을 눌렀나」가 아니라 「어느 코드로 다시 계산했나」임.**
|
||
```
|
||
앞 기준선 = laptop-main 확정 직후 서버 코드 09-07 17:46
|
||
이번 값 = laptop-main 04:38 저장 서버 04:35 기동, 코드 09-08 00:41
|
||
└ 그 사이 4환경 병합분이 다 들어옴
|
||
```
|
||
**같은 자료를 다른 코드로 두 번 계산한 결과**임. 토사↔암이 서로 반대로 움직인 것은
|
||
사면 구간 재료를 그린 경사비로 가르게 한 변경, 성토 쪽은 소단·옹벽 의무 판정 재정의가
|
||
닿는 자리로 보임(laptop-main 지목).
|
||
|
||
**⇒ 규칙 7 — 스냅숏에 서버 코드 시각을 함께 적을 것.**
|
||
`GET /api/health` 의 `code_mtime`. 그래야 값이 움직였을 때
|
||
**「자료가 바뀌었나 / 코드가 바뀌었나」를 한 번에 가름.** 오늘 그 둘이 겹쳐 헷갈렸음.
|
||
|
||
**⇒ 규칙 8 — 저장된 「정본」은 코드 버전에 매여 있음.**
|
||
[저장]·[확정]은 그 시점 코드로 전 측점을 다시 계산해 정본에 씀. 따라서
|
||
**되받기 뒤 남의 창이 [저장]을 한 번만 눌러도 정본 수치가 통째로 갱신됨.**
|
||
수량·금액을 대조할 때는 **자료 시각과 코드 시각을 함께** 볼 것.
|
||
|
||
**검증용 프로젝트 나눔 (2026-09-08 사용자 승인 — 이 표가 값 보호의 정본)**
|
||
|
||
⚠ **2026-09-08 실측 정정** — 앞서 이 표가 `b269ea34`·`2f940d8a` 를 「구조물 있음」이라 적었으나
|
||
**둘 다 0개였음.** 구조물이 있던 것은 `5601e828`(7) 과 사용자 것 `5cff3920`(1) 뿐이었고,
|
||
그래서 B08 이 구조물 원단위·자재총괄을 **남의 프로젝트로 읽어야** 했음(오늘 화면 점검 때 실제로 그랬음).
|
||
**⇒ 검증 프로젝트는 「단면이 있다」만으로 모자람 — 그 창이 검증할 것이 실제로 서는지**까지 봐야 함.
|
||
|
||
**검증용 구조물 심는 법** — `tmp/seed_verify_structures.py <project_id> [--dry]`
|
||
(⚠ `tmp/` 는 git 밖이라 창마다 따로 있어야 함. 없으면 만들어 쓸 것.)
|
||
심는 세트는 **값이 서는 것과 일부러 막히는 것을 섞음** — 검증에는 둘 다 필요함:
|
||
```
|
||
masonry_wet NO.80 H=2.5·L=10·뒷길이 45㎝ → 값 섬 (FP-13-04-05)
|
||
masonry_dry NO.140 H=2.0·L=10·뒷길이 35㎝ → 값 섬 (FP-13-04-02)
|
||
retaining_wall NO.200 반중력식 H=2.0·L=10 → 값 섬 (관측 원단위 m당) + 철근 자재
|
||
boulder_masonry NO.320 직경 60~80㎝·L=10 → ⚠ 일부러 막힘
|
||
「쌓기 방식(메/찰)이 아직 입력되지 않았습니다」
|
||
```
|
||
⚠ **집수정(`pipe_inlet_basin`)은 심지 말 것** — 레지스트리에 독립 구조물로 없음. 배수관의
|
||
**부속**이라 `pipe` 에 `inlet_basin_form` 을 주면 딸려 섬. 그런데 배수관 자체는
|
||
`pipe_points.json` 이 주인이라 여기서 심으면 **정본이 두 벌**이 됨.
|
||
```
|
||
5cff3920 사용자 활성 — 아무도 손대지 말 것
|
||
5601e828 laptop-main (B06 검증) — 확정 (2026-09-08). 사본 이관 취소 — 세 창이 각자 몫으로
|
||
갈라섰으므로 같이 볼 일이 없어짐. [확정]·[저장] 은 누르기 전 알릴 것
|
||
b269ea34 desktop-main (B08) 단면파일 60 · DB측점 118 · 구조물 4 (2026-09-08 심음)
|
||
2f940d8a desktop-sub (B09) 단면파일 24 · 구조물 0 ⚠ 심어야 함
|
||
8879c53b laptop-sub (B05 노선 편집) 단면파일 273 · 구조물 0
|
||
└ 2026-09-08 사용자 승인. 노선 [확인] 은 배수유역부터 전 단계를 다시 돎.
|
||
325f57d9 · 89449bf5 · fae94c66 빈 프로젝트(단면 0) — 예비
|
||
└ 쓰려면 자동설계 체인을 처음부터 돌려야 함(90초+ · 원자료 필요).
|
||
⚠ 325f57d9 는 노선 파일이 깨져 있음 — route_main.geojson 정점 135개가
|
||
모두 같은 점(선 길이 0), 관 좌표는 30km 밖. 검증용으로 고르지 말 것
|
||
```
|
||
|
||
|
||
## 나머지 전부 — 장부에 남아 있던 규칙·표 (2026-09-09 이관)
|
||
|
||
## ⚠⚠ 저장소 폴더가 PC 사이로 동기화됨 — git 밖의 두 번째 경로
|
||
|
||
⚠ **`tmp/` 는 안 건너감** (2026-09-09 실측 — 두 메인 폴더 사이에 표식 파일이 안 나타남).
|
||
`docs/` 는 건너감. **git 밖 파일이라고 다 건너간다고 보지 말 것.**
|
||
실사고 기록은 `verification/2026-09-09d_OWNERS_이력.md`.
|
||
|
||
**규칙 (2026-09-07 두 창 합의)**
|
||
|
||
1. **공용 파일 등록 줄은 「신규 파일 push 확인 → 등록 줄 push」 두 걸음으로.**
|
||
「부르는 줄만 있고 파일이 없는」 구간을 아예 만들지 말 것.
|
||
2. **autopush 폴백 전에 `git status` 로 남의 파일이 섞였는지 볼 것.**
|
||
3. 남의 폴더에서 온 듯한 변경이 보이면 지우지 말고 **`SendMessage` 로 주인에게 확인.**
|
||
4. **반쪽 상태를 만나면 기다리기 전에 먼저 `git sync` 로 원격을 확인할 것.**
|
||
두 번 다 「상대에게 요청하고 기다렸는데 파일은 이미 원격에 있던」 모양이었음
|
||
(2026-09-07, B08 라우터 · B09 라우터). 원격에 있으면 sync 만으로 풀리고,
|
||
**없을 때만** 상대에게 요청할 것.
|
||
|
||
## ⚠⚠ DB 한 벌을 두 환경이 같이 씀 — 자료가 발밑에서 바뀜
|
||
|
||
> 실사례·원인·「[저장]도 전 측점을 다시 계산함」 실측은 옮겼음 —
|
||
> `verification/2026-09-09d_OWNERS_이력.md`.
|
||
### 재계산을 부르는 조작 — 세 등급 (2026-09-08 정리)
|
||
|
||
값이 발밑에서 바뀌는 통로를 크기 순으로 적음. **누르기 전에 알릴 것**(규칙 6).
|
||
|
||
| 등급 | 조작 | 무엇이 도나 | 미치는 범위 |
|
||
|---|---|---|---|
|
||
| 大 | **노선 [확인]** | `run_redesign_chain` — 배수유역 재분석(90초대) → 관 재배치 → 종·횡단 재생성 → 옛 측점 설계 이월 → B05·B06 확정 | **[확정]이 하는 일을 포함하고 그 위에 노선 교체가 얹힘.** 그 프로젝트의 종·횡단·유토를 통째로 갈아엎음 |
|
||
| 中 | **[확정]** | 전 측점 재계산 후 정본 기록 | 토적·사면·운반 전부 |
|
||
| 中 | **[저장]** | 같음 — **저장도 전 측점을 다시 계산함** | 위와 같음 |
|
||
| 小 | **개발용 「확정 없이 다음으로」** | 워크플로 상태 한 칸(`state`)만 | **계산 안 돎 · 정본 값 안 만듦** |
|
||
|
||
**⇒ 값 변동을 추적할 때 후보 순서** — ① 노선 [확인] ② [확정]·[저장] ③ 그 사이 서버 코드가 바뀌었나(규칙 8).
|
||
**「안 눌렀음」도 보고할 값어치가 있음** — 후보를 지울 수 있음(laptop-sub 제안, 채택).
|