트리에서 뺀 신청 상태 표시를 일주일 뒤 되살렸다

이 글은 2026년 9월에 당시 커밋 이력을 다시 보며 정리한 것입니다. 날짜는 작업한 날 기준입니다.

OID 트리의 노드 이름 뒤에 상태를 붙여 보여 주고 있었습니다. 센서 데이터 [신청중] 같은 식으로요. 12월 12일에 넣었고, 22일에 지웠고, 29일에 되살렸습니다.

ef060adb  12-12 11:53  트리 구조에 state가 아닌 current_state 로 추가 변경 하기
4f0d9d71  12-22 19:30  신청 상태를 표시 하던 내용을 삭제 ...
a8e61584  12-29 14:46  (임시) 목표 : state를 통해 트리 구조에 등록 상태 표시 상황 : 깃 참고 (4f0d9d71...)
378f1c6d  12-29 15:21  - state를 통해 트리 구조에 등록 상태 표시 #2 리팩토링 ...

지울 때는 76줄, 이유는 한 줄

12월 12일판은 워크플로의 현재 단계를 썼습니다. OID에 연결된 신청서가 있으면 그 신청서의 current_state 이름을 트리 응답에 실어 보내고, 화면이 그걸 이름 뒤에 붙였어요. 15일에는 한 발 더 나가서, 진행 중인 노드는 상위 OID로 고를 수 없게 막았습니다.

22일 저녁에 이걸 다 지웠습니다. 파일 넷, 76줄.

-            // workflow current_state를 우선 사용, 없으면 state 사용
-            const state = v.current_state_display || v.state_display || v.state || "";
...
-            const hideStateLabel = stateKey === "등록" || stateKey === "배포단계";
-            if (!hideStateLabel) {
-                if (v.current_state_display) {
-                    text += ` [${state}]`;

매니저에서 신청서를 한 번에 조회해 붙이던 코드, 시리얼라이저의 current_state_display 필드, 상위 OID 선택 모달의 차단 로직까지 같이 나갔어요. 커밋 메시지는 지운 항목을 세 개 나열하고 셋째에 "불필요한 파이썬 함수"라고 적었습니다. 왜 불필요해졌는지는 없습니다. 이 글을 쓰면서도 그날 무슨 이야기가 있었는지 찾지 못했어요.

되살릴 때는 지운 커밋을 가리켰다

일주일 뒤 되살린 커밋의 제목이 이렇습니다.

(임시) 목표 : state를 통해 트리 구조에 등록 상태 표시
상황 : 깃 참고 (4f0d9d7165fe354f69fcefb4aefd525263e0b352)
해결 방법 :  text += ` [${state}]`;

지운 커밋의 해시를 "상황"에 적어 두고, 해결은 지운 줄 하나를 다시 쓰는 거였어요. 다만 되살린 것은 같은 것이 아닙니다.

	12월 12일판	12월 29일판
상태의 출처	워크플로 신청서의 `current_state`	OID 모델의 `state` 필드
누구에게	모두	관리자에게만(`checkAccessLevel()`)
숨기는 값	"등록"·"배포단계" 라벨	`ACT` 코드
서버 변경	매니저·시리얼라이저	없음 — 응답에 이미 있던 `state` 사용

워크플로를 다시 붙이지 않고, 응답에 원래 실려 오던 모델 필드를 라벨로 바꿔 붙였습니다. 서버는 안 건드렸어요. "되살렸다"기보다 더 작은 것으로 갈아 끼운 겁니다.

35분 뒤, 공용 파서에서 화면 전용으로

되살린 자리는 commonClassTreeUtils.js의 parseTreeData였습니다. 분류체계·메타클래스·OID 트리가 같이 쓰는 공용 파서예요. 35분 뒤 여기서 빼서 OID 화면 파일의 후처리 함수로 옮겼습니다.

// 트리 노드 배열에 state 정보를 추가하는 후처리 함수 (관리자 전용)
function addStateToTreeNodes(nodes) {
  if (!checkAccessLevel()) return nodes;

  const processNode = (node) => {
    if (node.data && node.data.state && node.data.state !== "ACT") {
      const stateLabel = getStateLabel(node.data.state);
      node.text = `${node.data.name} [${stateLabel}]`;
    }

같은 커밋에 남긴 주석이 이유입니다. "다른 파일들 처럼 공통 파일에서 챙길 시 html 구조 충돌 문제 발생." 공용 파서에 OID 전용 라벨 맵을 두면 다른 트리에도 딸려 들어가니까요.

옮기면서 파서의 버그 하나가 같이 드러났습니다.

             this.text = text;
             if (includeDescription) {
                 this.description = v.description;
             }
-            return;
+            return v;

JSON.parse의 reviver는 undefined를 돌려주면 그 키를 지웁니다. data 키를 만나 text를 만들어 붙인 뒤 return;으로 끝내고 있었으니, 파싱이 끝난 노드에는 data가 없었어요. 파서 안에서 라벨을 붙일 때는 상관없었지만, 파서 밖에서 node.data.state를 읽으려니 그제야 걸렸습니다.

검증

관리자로 트리를 열어 ACT가 아닌 노드에만 [신청중] 같은 꼬리가 붙는지, 일반 사용자로 열면 안 붙는지 눈으로 확인했습니다.
노드를 새로 만들거나 이름을 고친 직후의 꼬리는 buildNodeTextWithState가 따로 붙입니다. 이걸 그날 눈으로 확인했는지는 기록이 없습니다.
회귀 테스트는 없었습니다. 그때 e2e는 아직 이 화면에 없었어요.

남은 것 · 한계

왜 지웠는지 모릅니다. 지운 커밋에 이유가 없고, 되살린 커밋은 "(임시)"로 시작합니다. 임시라고 적은 코드가 그 뒤로 정식이 됐어요.
워크플로 상태와 모델 state는 다른 것입니다. 12월판이 보여 주던 "심사 단계"는 이제 안 보이고, 모델의 여섯 값만 보여요. 그 차이를 사용자에게 설명한 적은 없습니다.
라벨 맵이 두 곳에 있습니다. STATE_OPTIONS와 getStateLabel이 OID 화면에, 같은 값 여섯 개가 서버의 TYPE_STATES에. 서버가 값을 더하면 화면은 코드 그대로 보여 줍니다.
이 트리는 아홉 달 뒤 jsTree에서 조직도로 바뀌었고, 그때는 하루 안의 되돌림을 시각 단위로 적었습니다. 이 글의 되돌림은 일주일 간격인데 이유가 없고, 그 글의 되돌림은 일곱 시간 간격인데 이유가 있어요. 그 사이에 바뀐 건 기록하는 습관입니다.