Files
Aislo/docs/raw/verification/2026-09-09d_OWNERS_이력.md
T
eomsangdonandClaude Opus 5 eb30b774f8 chore(docs): docs 폴더 git 추적 전환 · PLAN·OWNERS 최상위 이관
- `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>
2026-09-09 18:19:07 +09:00

12 KiB
Raw Blame History

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 제안, 채택).