이 글은 2026-09-22 하루의 기록이다. 전날 남긴 할 일 세 가지(SVG 정리, 다이어그램 키 정정, v1.2 버전 올리기)로 시작했다. 이어서 v1.2 개정 Task 15건의 댓글을 데이터와 하나씩 대조했고, 마지막에 15건을 모두 해결됨으로 옮겼다. 데이터 파일 16개와 다이어그램 82개에는 1.2.0을 붙였다.
배경 — 전날 남긴 할 일 세 가지
#45 끝에 적어 둔 할 일이 그대로 출발점이었다.
- 산출물 저장소에 커밋되지 않은 다이어그램 SVG 8개
- 유스케이스 다이어그램 이슈(SURAS-1596) 키가
usecase.json이 아니라participant.json개정 이력에 적힌 문제 - 데이터 파일 버전이 아직 1.1.x인 문제
“모두 진행”이라는 한 줄로 시작했다. 그런데 셋 다 그대로 처리하면 기록이 틀어지는 종류였다.
문제
- 커밋되지 않은 SVG를 그대로 올려도 되나
- 엉뚱한 파일에 적힌 이슈 키는 표기 오류인가, 반영이 빠진 것인가
- Task 15건의 “반영 결과” 댓글은 실제 데이터와 맞나
- 내용이 바뀌지 않은 파일에도 1.2.0을 붙여야 하나, 붙인다면 어떻게
결정 1 — SVG는 그대로 올리지 않고 전부 다시 렌더한다
8개의 수정 시각과 렌더 엔진 버전을 원본 .puml과 대조해 보니 그대로 올리면 안 되는 상태였다.
| 상태 | 건수 |
|---|---|
원본 .puml의 8월 25일 개정보다 오래된 렌더본 | 3 |
| 구버전 엔진으로 렌더돼 직전 커밋본보다 퇴행한 렌더본 | 1 |
| 문제없음 | 4 |
작업 트리에 파일이 있다고 해서 올려도 되는 산출물은 아니다. 8개 모두 Docker PlantUML로 다시 렌더해 커밋했다.
결정 2 — 키 위치는 고치지 않고 반영을 채운다
participant.json 1.1.3 개정은 OMS(외부 자원관리 시스템) 참여자 추가였다. 1596 설명에 적힌 “자원 자체관리 배제”와 같은 흐름이다. 반면 유스케이스 다이어그램에는 OMS가 아예 없었다.
그래서 표기가 틀린 게 아니라 다이어그램 반영이 빠진 것으로 봤다. 사용자에게 “표기 유지”와 “UCDG에 OMS 반영” 두 가지를 물었고, 반영 쪽으로 정했다.
- 일반정보 영역(
UCDG-INF)에 OMS 외부 액터를 선언하고 일반정보 관리 유스케이스와 연결 - 위험도 평가 영역(
UCDG-RSK)에서는 군집 구성 관리 유스케이스만 OMS와 연결 - 액터 선언은 INF에 하나만 둔다. 통합본(OVERVIEW)에서 같은 액터가 두 번 나오지 않게 하기 위해서다
JSON에 쓰기 전에 비파괴 검사부터 돌렸다.
✗ ucdg usecase.json 드리프트 [+2 -0 ~0]
+ usecases[26].actors[1]: 'oms'
+ usecases[8].actors[1]: 'oms'
예상한 +2만 나왔다. 반영 후에는 드리프트 0으로 통과했고, usecase.json은 1.1.7이 됐다.
결정 3 — “반영 완료” 댓글을 믿지 않고 데이터와 대조한다
Task 15건의 댓글을 모두 가져와서 “반영 결과” 댓글에 적힌 변경을 실제 JSON과 다이어그램에서 하나씩 확인했다. 반영 커밋이 원격 master에 있는지도 봤다.
| 결과 | 건수 | 비고 |
|---|---|---|
| 반영 확인 → 해결됨 | 13 | 이 중 3건은 “해야 할 일”로 남아 있었지만 8월 25일 커밋에 이미 반영 |
| 댓글과 실제가 다름 → 진행 중 유지 | 2 | 1588, 1597 |
어긋난 두 건은 이랬다.
- 1588 (논리 데이터 명세서): 비행정보에 메모를 추가했다고 적혀 있었지만 비어 있었다. 최대이륙중량·최대속도·지상위험범위는 기능 명세서에서는 필수인데 논리 데이터에서는 선택이었다.
- 1597 (기능 정의서): 검토 댓글만 있고 반영 결과 댓글이 없었다. SRM 근거가 빠졌고, 자원 관련 기능 17건 중 14건에 OMS 연동 검토 메모가 없었다.
check.py는 전부 통과하고 있었다. 필수 여부 불일치는 문서 간 교차 검사 대상이 아니라서 잡히지 않는다.
검증 도구가 통과한다는 건 도구가 보는 범위 안에서 맞다는 뜻이다. 댓글에 적힌 약속은 그 범위 밖에 있다.
점검 결과는 15건 모두에 댓글로 남겼다. 전이 순서는 #45에서 정한 대로 Jira 먼저, 로컬 Task는 그다음, 마지막에 재조회였다.
결정 4 — 필수 여부는 기능 명세서 쪽에 맞춘다
“남은 항목도 반영해줘”를 받고 1588부터 처리했다. 어느 쪽에 맞출지는 이력을 보면 정해져 있었다. 1598에서 산출 기능(Containment·iGRC)의 입력이라는 근거로 필수로 바꿨고, 그 댓글에서 논리 데이터를 맞춰 달라고 넘긴 항목이다.
반대로 이륙/착륙좌표·비행범위타입·운영범위는 선택으로 남겼다. 산출 함수에 직접 들어가지 않고, 평가할 때 불러오기나 지도 입력으로 채워지기 때문이다. 이 판단 근거는 논리 데이터와 기능 명세서 양쪽에 적었다.
1597의 OMS 메모 14건은 기능 성격에 따라 방향을 나눴다.
| 기능 성격 | OMS 연동 시 방향 |
|---|---|
| 기체·인적 삭제, 인적 수정·등록 | 폐기 검토 |
| 기체·인적 조회·불러오기 | OMS 조회로 대체 |
| Containment·iGRC·군집 충돌 평가 | 산출은 유지, 입력 출처만 OMS로 |
물리 데이터의 해당 필드는 아직 nullable: true다. 필수로 맞추려면 DB 마이그레이션이 따르는 설계 결정이라 이번에는 건드리지 않고 1588 댓글에 후속 항목으로 남겼다.
결정 5 — 내용이 안 바뀐 파일에도 1.2.0을 붙인다
15건이 모두 닫혔으니 1.2.0을 붙일 차례였다. 그런데 revise.py apply --minor는 이렇게 답했다.
변경된 입력 JSON 없음 — 기록/커밋할 것이 없습니다.
이 도구는 내용이 바뀐 파일만 개정한다. 그래서 16개 파일에 개정 이력을 직접 추가하고, revise.py가 그것을 “기록 완료분”으로 인식해 검증 게이트와 커밋만 맡게 했다.
- v1.2에서 내용이 바뀐 9개: “v1.2 최신화”와 관련 Jira 키
- 바뀌지 않은 7개: “v1.2 기준선 정렬 — 내용 변경 없음”
이어서 다이어그램 버전 스탬프 도구로 .puml 82개의 머리 주석과 footer를 1.2.0으로 맞췄다. diff를 보니 버전 줄 말고 바뀐 건 그날 추가한 설명 두 줄의 들여쓰기뿐이었다. 저장소에 있는 SVG 10개도 다시 렌더했다.
의도치 않은 함정 — 덮어쓰지 못한 SVG, 켜지지 않은 파이프라인
첫 번째는 렌더다. BPDG 4개가 Cannot write to file /work/…svg와 no image로 실패했다. 호스트에서는 쓰기가 되는데 컨테이너 사용자(appuser)는 다른 도구가 만든 기존 파일을 덮어쓰지 못했다. 한 번도 커밋된 적 없는 파일이라 지우고 다시 렌더하니 통과했다. 이 함정은 렌더 메모에 추가해 뒀다.
두 번째는 push 뒤의 파이프라인이다. 결과를 확인해 달라고 해서 Bitbucket API를 조회했더니 실행 기록이 한 건도 없었다. 설정 조회는 404였다. 이 저장소는 Pipelines를 한 번도 켠 적이 없었다.
켜더라도 소용이 없는 구조이기도 했다. yml은 PNG를 렌더해 다시 커밋하는데, .gitignore에 *.png가 있어서 매번 “변경된 PNG 없음”으로 끝난다. 지금은 SVG를 로컬에서 Docker로 렌더해 커밋하고 있으니, 이 yml은 아무도 쓰지 않는 설정으로 남아 있던 셈이다.
마무리
- 상태·댓글·작업 트리는 모두 “누가 한 번 적어 둔 것”이다. 닫기 전에 실제 데이터와 한 번 대조한다.
- 도구가 규칙 밖의 일을 거절하면 도구를 고치기보다 도구가 받아들이는 형태로 입력을 만든다. 1.2.0은 그렇게 붙였다.
다음에 할 일:
- OMS 스펙 확정 후 작업을 담을 후속 이슈 등록 (여러 댓글이 “별도 이슈”로 미뤘는데 실제 이슈는 없다)
- 논리 데이터에서 필수로 바꾼 3개 필드의 물리 데이터
nullable정합 - 프로젝트 env의
VERSION_MINOR를 2로 맞추기 - 쓰지 않는 파이프라인 yml을 지우거나 “미사용”으로 표시
- 해결됨 15건은 보고자 확인 뒤 종료 처리