노드가 늘어도 무너지지 않는 워크플로우 편집기 구조 설계
eXemble 워크플로우 편집기에서 2025.09부터 FE 설계와 개발을 맡으며, 노드가 계속 늘어나는 상황을 구조로 감당하도록 다시 설계한 과정입니다.
배경
B2B 고객사마다 필요한 노드가 계속 늘어났습니다. 의도 분류, 정기 실행, AI 에이전트, 외부 호출 시작, 재시도, 반복, 병합, 구조화 출력까지 1년 동안 노드와 설정이 쌓였습니다.
그런데 노드 하나를 추가하거나 바꿀 때마다 여러 곳을 손으로 맞춰야 했고, 빠뜨려도 빌드와 테스트는 통과했습니다. 누락은 메뉴에 노드가 보이지 않거나, 다른 서버에서 설정이 사라지거나, 실행 결과가 이상한 것으로만 드러났습니다.
그래서 두 가지를 기준으로 구조를 다시 설계했습니다.
- 노드 하나를 추가·수정할 때 그 노드의 관심사만 건드리면 되도록 관심사를 분리할 것
- 노드마다 반드시 채워야 하는 것을 빠뜨리면 사람이 아니라 컴파일 단계에서 막히게 할 것
1. 요구를 새 노드가 아니라 제품 개념으로 받기
고객사 요구가 들어오면 FDE(고객사 현장 엔지니어)와 함께 요구가 나온 배경과 실제 사용 상황을 먼저 확인했습니다. 그다음 새 노드로 추가할지, 기존 노드의 기능으로 넣을지, 별도 기능으로 분리할지 트레이드오프를 따져 결정했습니다.
- 외부 호출로 워크플로우를 시작하는 요구는 새 노드 타입이 아니라 시작 노드의 시작 방식 중 하나로 설계했습니다. 시작 노드의 입력 필드가 곧 요청 본문이자 뒤 노드의 변수가 되도록 해, 사용자가 익힐 개념을 늘리지 않았습니다.
- 재시도 노드를 만들어 달라는 요구는 모든 노드가 가지는 공통 설정으로 바꾸고, 노출할 노드는 근거와 함께 좁혔습니다.
- 캔버스에 루프를 그리는 방식은 실행 엔진이 허용하지 않아, 반복을 노드를 감싸는 묶음으로 모델링했습니다.
2. 노드의 일은 노드 폴더 안에, 공통 영역은 선언 하나에서 파생
- 노드 하나의 타입·스키마·기본값·서버 변환·검증이 공통 파일 여러 곳에 흩어져 있던 구조를, 노드 폴더 안에 모으고 공통 파일에는 짧은 선언만 남기는 구조로 단계적으로 바꿨습니다. 기존 노드의 속성을 바꿀 때는 공통 파일을 건드리지 않게 됐습니다.
- 조건 반복 노드를 추가하려고 보니 묶음 규칙이 12곳에 흩어져 있었습니다. 판정을 한 곳에 모은 뒤 묶음 선언 하나에서 진입 마커·회차 변수·배지 문구가 파생되게 바꿨고, 새 묶음 추가 절차를 팀 문서로 남겼습니다.
- 설정 패널과 캔버스가 서로 다른 검증을 쓰던 노드 15종의 스키마를 한 벌로 줄였습니다. 미입력을 "키 없음"이 아닌 빈 값으로 표현해 "아직 안 정함"과 "이 노드에는 없는 칸"을 구분했습니다.
3. 누락은 사람이 아니라 컴파일이 막게
- 새 노드를 추가 메뉴에 등재하지 않아도 빌드가 통과하던 문제를, 노드 선언의 타입에서 "메뉴를 가진 노드" 집합을 뽑아 메뉴 목록과 양방향으로 대조하도록 바꿨습니다. 어긋나면 컴파일 에러가 납니다.
- 메뉴 순서는 디자인 결정이라 파생하지 않고 테스트 하나로만 고정했습니다.
- 타입으로 막을 수 있는 것은 타입으로, 나머지만 테스트로 남기는 기준을 테스트 전략 문서에 정리했습니다.
4. 사람이 바뀌어도 같은 규칙으로
노드 추가용 Agent Skill을 만들었습니다. 새 노드에 필요한 결정을 차례로 묻고, 구현 계획·코드 골격·테스트까지 만들어 누가 추가해도 같은 절차와 규칙을 따르게 했습니다.
결과
- 지원 노드 종류 2배 이상, 2026년 1분기 워크플로우 기능 개선 20건 이상 출시
- 팀원들도 같은 선언 방식으로 새 노드(이메일·차트 등)를 추가
- 메뉴 등재·묶음 선언 누락이 실행 전 컴파일 단계에서 드러나는 구조