산업 장비 레시피 관리 시스템

프로젝트 배경

산업 장비 레시피는 Cycle 안에 Step, 종료·안전·기록 조건과 기능 블록이 결합되는 구조다. 블록 수를 줄일 수 없는 요구에서 초기 Blockly 편집기는 데이터가 커질수록 Chrome 탭이 멈추거나 차단됐다. PixiJS로 화면을 그리면서 Blockly의 결합 로직을 유지한 방식도 내부 계산 비용을 해결하지 못해, 편집 데이터와 렌더링을 함께 다시 설계했다.

2026-01-20 QA에서는 488 Step 레시피의 Block 모드 전환 시 초기 무반응, 495 Step 로드 후 블록 이동 시 화면 멈춤, 조건을 최대로 설정한 Step의 복사·붙여넣기에서 95번째 Step 이후 화면 멈춤이 기록됐다. 반복 이동 중 Chrome 단일 탭 메모리가 3GB 이상으로 올라간 사례도 있었다.

핵심 구현

블록 로직을 독립된 Scene Graph로 분리

레시피 데이터를 블록 트리로 변환하고, 연결·분리·이동·생성·삭제를 패치로 처리했다. 구조 변경에 따라 Cycle·Step 순번과 Goto Step·SOC/DOD 참조를 갱신하고, 위치만 바뀐 경우에는 불필요한 참조 재계산을 줄였다.

렌더링과 저장 경로 연결

PixiJS 기반 WebGL Stage가 Scene Graph를 그리도록 분리했다. 기존 레시피를 그래프로 불러오고, 편집 결과를 다시 레시피 DTO로 직렬화해 서버 저장·검증 흐름에 연결했다. My Step을 캔버스에 불러와 기존 단계도 재사용할 수 있게 했다.

대용량 상호작용에 가상화 적용

뷰포트 밖 블록은 화면에서 분리하고 렌더 객체를 해제하며, 다시 보이는 블록은 재생성한다. 선택·드래그·필드 편집 중인 블록은 해제 대상에서 보호했다. 생성 작업에는 실행당 개수·시간 예산을 두고, 빠른 휠 스크롤 입력도 제한해 짧은 순간에 렌더 작업이 몰리지 않도록 했다.

성과

495 Step 로드 후 반복 이동, 조건이 많은 Step의 95번째 이후 복사·붙여넣기, 488 Step 모드 전환과 빠른 스크롤을 포함한 후속 QA에서 화면 멈춤이 재현되지 않았고 메모리 증가 문제도 개선됐다. 이는 담당자가 동일 재현 조건에서 확인한 결과다.

개선 전에는 Chrome 단일 탭 메모리 3GB 이상이 기록됐지만, 개선 후 메모리·FPS·응답 시간 수치는 보관되지 않았다. 따라서 감소율이나 처리 속도 배수는 제시하지 않는다. 대용량 편집에서는 화면에 그리는 방식과 블록 결합·참조 계산, 렌더 객체의 수명주기를 함께 설계해야 한다는 점을 확인했다.

트러블슈팅

현상과 재현 조건

488 Step 레시피에서 Block 모드 전환 직후 반응이 지연됐다. 495 Step을 불러온 뒤 블록을 이동하면 화면이 멈췄고, 반복 이동 중 Chrome 단일 탭 메모리가 3GB 이상으로 올라갔다. 조건을 최대로 설정한 Step을 연속 복사·붙여넣기 하면 95번째 Step 이후 화면이 멈췄다. 이 값들은 개선 전 관찰값이며, 모든 상황의 공통 실패 임계값은 아니다.

원인 분석과 선택

블록 수를 줄일 수 없어 렌더링만 PixiJS로 바꾸고 Blockly의 연결·계산 로직을 유지하는 방식도 시도했다. 그러나 결합과 참조 갱신의 비용이 남았다. 화면 밖 블록의 렌더 객체가 계속 유지되거나 한 번에 많이 생성되는 경로도 메모리·프레임 부담을 키울 수 있어, 데이터 계산과 객체 수명 관리를 별도로 다뤘다. 개별 경로가 3GB 증가에 기여한 비율은 측정되지 않았다.

수정

블록 연결·분리와 순번·참조 갱신을 자체 Scene Graph의 패치 처리로 옮겼다. PixiJS Stage에는 뷰포트 가상화와 화면 밖 객체 해제, 선택·드래그·편집 중 객체 보호를 적용했다. 생성량·처리 시간 예산과 스크롤 입력 제한으로 반복 이동과 빠른 이동 중 렌더 작업이 몰리는 구간을 줄였다.

검증과 남은 과제

후속 QA에서 488 Step 모드 전환, 495 Step 반복 이동, 조건이 많은 Step의 95번째 이후 복사·붙여넣기와 빠른 스크롤을 같은 조건으로 다시 확인해 화면 멈춤과 메모리 문제의 개선을 확인했다. 개선 후 수치가 없어 정량 감소율은 산정하지 않았다. 현재 스냅샷 적용 경로에는 화면 밖 객체를 먼저 만든 뒤 제거하는 부분이 남아 있어 초기 메모리 피크는 추가 개선 여지가 있다.