ComfyUI API 자동화를 만들다 보면 JSON 문법도 정상이고 /prompt 요청도 서버까지 도착했는데 Prompt outputs failed validation에서 실행이 멈추는 경우가 있다. 이때 JSON 전체를 처음부터 다시 읽기보다 응답에 포함된 node_errors부터 확인하는 편이 빠르다.
node_errors에는 문제가 발생한 node ID와 해당 node의 오류 정보가 들어갈 수 있다. 따라서 이번 JSON 오류 찾기의 핵심은 node ID → class_type → errors → details 순서로 내려가며 실제 실패 입력을 찾는 것이다.
json 오류 찾기에서 가장 먼저 볼 변화
먼저 error보다 node_errors를 확인한다
ComfyUI가 prompt validation 단계에서 실패하면 응답의 최상위 error에는 prompt_outputs_failed_validation처럼 전체 실패 유형이 표시될 수 있다. 하지만 이것만으로는 어떤 node가 잘못됐는지 바로 알기 어렵다.
실제 원인을 좁힐 때 더 중요한 부분은 함께 반환되는 node_errors다. 여기에는 오류가 발생한 node ID를 key로 해서 해당 노드의 세부 오류가 정리될 수 있다.
node ID부터 찾으면 JSON 범위가 크게 줄어든다
예를 들어 node_errors 안에 "32"가 있다면 전체 API JSON을 뒤지는 대신 우선 node ID 32를 확인하면 된다. API Format workflow는 node ID를 기준으로 각 node가 구성되기 때문에 오류 응답과 원본 JSON을 연결하기 쉽다.
즉 오류 메시지를 읽은 뒤 첫 번째로 해야 할 일은 전체 workflow 수정이 아니라 실패 node ID를 특정하는 것이다.
node ID를 찾았다면 원본 API JSON에서도 같은 ID를 검색한다. 그러면 해당 node의 class_type과 inputs를 바로 확인할 수 있다.
class_type과 errors로 실패 종류를 좁힌다
node_errors의 세부 오류에는 class_type이 포함되는 경우가 있다. 이 값은 오류가 발생한 node가 어떤 종류인지 확인하는 데 유용하다.
예를 들어 실제 오류 사례에서는 PixverseImageToVideoNode, OnnxDetectionModelLoader 같은 class_type과 함께 잘못된 입력값이 표시됐다. node ID만 봐서는 역할을 알기 어렵지만 class_type까지 보면 어느 node 설정을 확인해야 하는지 바로 좁힐 수 있다.
json 오류 찾기가 ComfyUI 워크플로우에 미치는 영향
errors 배열의 type도 같이 본다
기존 방식과 비교해야 할 부분
세부 오류에는 type이 포함될 수 있다. 대표적으로 value_not_in_list처럼 입력한 값이 허용 목록에 없는 상황이나 required input is missing처럼 필요한 입력이 빠진 상황을 확인할 수 있다.
따라서 node가 확인됐다고 곧바로 JSON 문법을 수정할 필요는 없다. 먼저 해당 오류가 값 선택 문제인지, 필수 입력 누락인지 구분하는 것이 중요하다.
이 구분만 해도 원인을 찾는 방향이 달라진다. 값이 허용 목록에 없다면 해당 input 값을 확인하고, 필수 입력이 없다고 나오면 그 node의 inputs 구조에서 빠진 항목을 확인하면 된다.
details에서 실제 input 이름과 값을 찾는다
가장 직접적인 단서는 details에 들어 있는 경우가 많다. 실제 오류 응답에서는 어떤 input 이름에 어떤 값이 들어갔고 왜 유효하지 않은지가 함께 표시되기도 한다.
예를 들어 duration_seconds에 넣은 값이 허용 목록에 없거나, yolo_model에 지정한 모델명이 현재 선택 가능한 값이 아닌 상황처럼 구체적인 입력 이름을 확인할 수 있다.
이 경우 JSON 전체에서 비슷한 문자열을 일괄 변경하기보다 오류 node의 inputs 안에서 해당 key를 찾아 수정하는 것이 좋다. node ID까지 이미 알고 있기 때문에 수정 범위도 최소화할 수 있다.
성능과 결과 품질에서 확인할 차이
ComfyUI 모델 Loader 계열에서는 JSON에 적힌 파일명이 현재 환경에서 사용할 수 있는 목록에 없을 때 validation 오류가 발생할 수도 있다. JSON 파일 자체가 손상된 것과는 다른 문제이므로 오류 type과 details를 먼저 읽어야 한다.
워크플로우 구성에서 놓치기 쉬운 부분
Required input is missing은 입력 구조를 다시 본다
오류가 Required input is missing이라면 단순한 숫자나 문자열 값 문제가 아니다. 실행에 필요한 입력 자체가 API prompt에 없다는 의미로 좁혀 볼 수 있다.
실제 API validation 사례에서도 특정 Custom Node의 secure 입력이나 다른 node의 custom_ratio가 빠져 validation이 실패한 경우가 보고됐다.
UI에서 실행되던 Workflow도 API JSON은 다시 본다
ComfyUI 화면에서 구성했던 workflow와 API로 전달하는 prompt 구조는 같은 용도로 저장되는 JSON이 아니다. 따라서 UI에서 보이는 연결만 확인하고 API JSON의 inputs가 모두 제대로 들어 있다고 단정하면 안 된다.
특히 workflow를 프로그램에서 변환하거나 node input을 동적으로 제거·교체했다면 최종 전송 직전의 JSON을 기준으로 확인해야 한다.
node_errors가 있으면 수정 순서를 고정한다
ComfyUI JSON 오류 찾기를 자동화할 때는 다음 순서로 보는 것이 단순하다.
최상위 error에서 validation 실패인지 확인
node_errors에서 실패 node ID 확인
실제로 적용할 때 체크할 점
class_type으로 실제 node 종류 확인
errors의 type 확인
details에서 문제 input과 값 확인
원본 API JSON의 해당 node inputs만 수정
다시 /prompt로 전송해 validation 확인
이 방식의 장점은 수십 개 또는 수백 개 node가 있는 workflow에서도 오류가 난 위치부터 바로 접근할 수 있다는 점이다.
JSON parser나 schema validator는 문서 구조를 검사할 때 유용하지만, ComfyUI가 실제 node 입력을 검증하면서 발생시킨 오류는 서버가 반환하는 validation 정보를 보는 편이 직접적이다.
마지막 확인
ComfyUI API JSON에서 Prompt outputs failed validation이 뜬다면 메시지만 보고 workflow 전체를 다시 만들 필요는 없다. 먼저 응답의 node_errors를 열어 실패한 node ID와 class_type을 찾고, 이어서 errors의 type과 details를 확인하자.
value_not_in_list라면 해당 input 값을, Required input is missing이라면 빠진 입력을 우선 확인하면 된다. 수정도 전체 JSON이 아니라 문제가 표시된 node의 inputs부터 시작하는 것이 가장 빠르다.