데이터 맵에서 클래스 타일을 눌렀더니 인스턴스 2,732개를 부채꼴로 세로로 쌓아 캔버스가 92,948px이 됐습니다. 목록으로 보내는 대신 이름 접두어로 묶음 단을 끼웠고, 한 글자씩만 깊어지는 사슬을 같은 단에 미리 펼쳐 최악 경로를 3클릭으로 줄였어요. 같은 날 두 번 방식을 바꿨고, 이튿날 붙인 핵심어 탭은 그날 저녁에 다시 뺐습니다.
관리 화면의 jsTree가 클래스 하나에 인스턴스 수천 건을 매달고 있었습니다. 오후에 더 보기 노드를 고치고, 스크롤 자동 적재까지 갔다가, 저녁에 창 하나만 DOM에 두는 가상 스크롤로 확정했어요. 창 밖은 padding으로 높이만 세우는데, 그 여백을 인라인이 아니라 우리가 소유한 style 규칙으로 줘야 했고, jsTree 펼침 애니메이션은 꺼야 했습니다.
상세 화면 세 곳의 필드명·M/O·최대 반복이 통째로 `-`로 서 있었습니다. 파서는 멀쩡했고 테스트도 34건 통과했는데, 값을 읽어 오려던 슬롯이 어느 클래스에도 등록돼 있지 않았어요. 출처를 필드 자신의 등록값으로 바꾸고, 줄 세우기도 한 곳이 정하게 모았습니다.
메시지가 무엇으로 이뤄졌는지 보려면 상세를 계속 타고 들어가야 했습니다. 전체를 좌→우 계층 트리 한 장으로 그리는 전용 뷰어를 만들었어요. 재귀 구조인데 쿼리는 깊이당 한 번이고, 순환은 자르되 잘랐다고 화면에 적습니다. 같은 날 오전에 넣은 디스플레이 유형 하나를 오후에 걷어낸 이야기도 같이 적었습니다.
JS를 고치고 새로고침해도 화면이 안 바뀌는데 서버를 다시 띄우면 바뀌는 증상이 있었습니다. 범인은 캐시를 깨라고 만들어 둔 add_hash 필터 자신이었어요. 입력이 전부 상수라 Jinja가 컴파일 시점에 한 번 접어버렸고, 그래서 서버 기동 시각이 URL에 굳어 있었습니다. @pass_context로 접힘을 막고 값을 파일 수정시각으로 바꿨습니다.