대부분의 이미지 생성 튜토리얼은 여전히 ComfyUI를 시각적인 놀이터처럼 취급합니다.

UI를 엽니다.
노드 몇 개를 드래그하여 연결합니다.
체크포인트 (checkpoint)를 로드합니다.
이미지를 생성합니다.

이것은 유용하지만, ComfyUI가 왜 계속해서 중요한지를 과소평가하는 것입니다.

더 흥미로운 변화는 다음과 같습니다:

ComfyUI는 더 이상 단순한 이미지 생성용 UI가 아닙니다. 그것은 워크플로 레이어 (workflow layer)가 되어가고 있습니다.

이는 AI 에이전트 (AI agents)에게 매우 중요한 의미를 갖습니다.

에이전트는 단순히 프롬프트 (prompt)를 작성하는 것만으로는 부족합니다. 에이전트는 반복 가능한 프로세스를 실행해야 합니다:

• 적절한 모델 선택
• 파일을 올바른 폴더에 배치
• 워크플로 (workflow) 로드
• 작업 큐 (queue) 등록
• 완료 대기
• 출력물 회수
• 출력물의 존재 여부 확인
• 다음 실행을 위해 그래프 (graph) 조정

단순한 프롬프트는 이를 제공하지 못합니다.

그래프는 가능합니다.

그래프가 중요한 이유

ComfyUI의 큰 장점은 워크플로가 명시적이라는 것입니다.

이미지 파이프라인 (image pipeline)을 하나의 텍스트 박스 뒤에 숨기는 대신, ComfyUI는 다음 단계들을 노출합니다:

• 체크포인트 (checkpoint) 로딩
• 프롬프트 인코딩 (prompt encoding)
• 잠재 이미지 (latent image) 생성
• 샘플링 (sampling)
• VAE 디코딩 (VAE decoding)
• 이미지 저장
• ControlNet 입력
• LoRA 로딩
• 업스케일링 (upscaling)
• 커스텀 노드 (custom nodes)

이것이 처음에는 위협적으로 보일 수 있지만, 바로 이 점이 ComfyUI를 진지한 자동화 (automation)에 유용하게 만드는 핵심입니다.

만약 이미지 워크플로가 단순한 프롬프트라면, 에이전트는 무슨 일이 일어났는지 추측해야만 합니다.

만약 이미지 워크플로가 그래프라면, 에이전트는 움직이는 부품들을 검사할 수 있습니다.

에이전트는 그래프에 대해 추론할 수 있습니다. 그래프를 재사용할 수 있습니다. 전체 파이프라인을 다시 작성하지 않고도 한 부분만 변경할 수 있습니다.

이것이 "이와 비슷한 것을 생성해줘"와 "다른 입력값으로 이 시각적 제작 워크플로를 다시 실행해줘"의 차이입니다.

에이전트에게 필요한 것은 느낌(vibes)이 아니라 워크플로입니다

가벼운 생성 작업에는 프롬프트 박스로 충분합니다.

하지만 프로덕션 작업에서 취약한 지점은 첫 번째 이미지가 아닌 경우가 많습니다.

취약한 지점은 바로 일관성 (consistency)입니다.

동일한 스타일을 다시 실행할 수 있나요?
입력 이미지를 교체할 수 있나요?
ControlNet 가이드는 유지하되 피사체(subject)만 바꿀 수 있나요?
결과물을 업스케일(upscale) 단계로 보낼 수 있나요?
UI를 일일이 클릭하는 대신 스크립트에서 동일한 워크플로를 사용할 수 있나요?

이 지점에서 ComfyUI는 단순한 예술 도구라기보다 인프라(infrastructure)처럼 느껴지기 시작합니다.

워크플로 JSON이 계약(contract)이 됩니다.

에이전트(agent)는 모든 단계를 처음부터 기억할 필요가 없습니다. 워크플로를 제출하고, 결과를 폴링(poll)하며, 출력을 다운로드한 다음, 어떤 일이 일어났는지 보고하면 됩니다.

API는 과소평가된 부분입니다

사람들이 가장 먼저 주목하는 것은 시각적 그래프(visual graph)입니다.

하지만 자동화에 친화적으로 만드는 것은 바로 API입니다.

일반적인 에이전트의 경로는 다음과 같습니다:

1. 로컬 또는 GPU 박스에서 ComfyUI를 시작합니다.
2. 워크플로 JSON을 로드하거나 생성합니다.
3. 해당 워크플로를 /prompt 엔드포인트(endpoint)로 제출합니다.
4. 작업이 완료될 때까지 /history/{prompt_id}를 폴링(poll)합니다.
5. /view를 통해 생성된 이미지를 가져옵니다.
6. 출력을 지정된 폴더에 저장합니다.

이는 브라우저 전용 이미지 생성 방식보다 에이전트에게 훨씬 더 적합합니다.

에이전트는 코드로부터 동일한 워크플로를 실행할 수 있습니다. 프롬프트 ID(prompt ID)를 기록할 수 있습니다. 출력 경로를 안정적으로 유지할 수 있습니다. 서버가 다운되거나 모델 파일이 누락되었을 때 깔끔하게 오류를 처리할 수 있습니다.

화려하지는 않지만, 이것이 바로 워크플로를 실용적으로 만드는 요소입니다.

설정 세부 사항이 진짜 함정입니다

어려운 점은 단지 "ComfyUI를 어떻게 사용하는가?"만이 아닙니다.

진짜 어려운 점은 그 주변의 모든 작은 운영 세부 사항들입니다:

• 어떤 Python 버전이 요구되는지
• 어떤 CUDA 또는 ROCm 경로가 사용되는지
• 체크포인트(checkpoint) 파일이 어디에 위치해야 하는지
• LoRA가 어디에 위치해야 하는지
• ControlNet 모델이 어디에 위치해야 하는지
• 커스텀 노드(custom nodes)를 어떻게 설치하는지
• GPU 액세스 권한을 가진 Docker에서 ComfyUI를 어떻게 실행하는지
• 무작위 폴더에서 출력을 잃어버리지 않으려면 어떻게 해야 하는지

이러한 세부 사항들은 지루하지만, 에이전트는 바로 이 지루한 세부 사항들 때문에 작동을 멈춥니다.

이것이 제가 이러한 종류의 워크플로를 단순한 메모로 남겨두는 대신, 하나의 기술(skill)로 패키징하는 것을 선호하는 이유입니다.

예를 들어, 저는 여기에 다음과 같은 ComfyUI 터미널 기술(ComfyUI Terminal Skill)을 보관하고 있습니다:

https://terminalskills.io/skills/comfyui

핵심은 "읽어야 할 페이지가 하나 더 생겼다"는 것이 아닙니다.

핵심은 에이전트(Agent)에게 반복 가능한 운영 경로(Operating path)가 필요하다는 것입니다. 이 기술(Skill)은 ComfyUI 설치 형태, 모델 폴더 컨벤션 (Model folder conventions), API 큐 예시 (API queue example), 결과 폴리 (Result polling), 커스텀 노드 설정 (Custom node setup), ControlNet 패턴, 그리고 Docker 배포 노트 (Docker deployment notes)를 한곳에 제공합니다.

따라서 작업이 "이 워크플로를 위해 ComfyUI를 사용하라"일 때, 에이전트는 검색 결과에서부터 시작하는 것이 아닙니다. 도구를 통하는 이미 알려진 경로를 가지고 있는 것입니다.

에이전트를 위해 직접 설치할 수도 있습니다:

npx terminal-skills install comfyui --agent codex

이것이 에이전트 작업을 위한 유용한 형태의 문서입니다. 브로슈어도 아니고, 일반적인 튜토리얼도 아닌, 에이전트가 실행할 수 있는 압축된 워크플로 (Workflow)입니다.

실용적인 ComfyUI 에이전트 워크플로

만약 제가 에이전트가 제어하는 ComfyUI 플로 (Flow)를 구축한다면, 처음에는 단순하게 유지할 것입니다.

이미 작동이 확인된 하나의 워크플로로 시작하십시오.

열 개의 커스텀 노드 팩 (Custom node packs)과 거대한 실험적 그래프 (Experimental graph)로 시작하지 마십시오.

작은 txt2img 또는 img2img 워크플로를 사용하고, 에이전트가 다음을 수행할 수 있음을 증명하게 하십시오:

• ComfyUI 서버를 시작하거나 도달하기
• 하나의 워크플로 제출하기
• 프롬프트 ID (Prompt ID) 캡처하기
• 완료될 때까지 대기하기
• 생성된 파일 다운로드하기
• 파일이 존재하는지 확인하기
• 정확한 출력 경로 보고하기

그 이후에야 다음과 같은 복잡성을 추가할 것입니다:

• ControlNet
• LoRA 변형 (LoRA variants)
• 업스케일 패스 (Upscale passes)
• 이미지 프롬프트 어댑터 (Image prompt adapters)
• 애니메이션 노드 (Animation nodes)
• 배치 생성 (Batch generation)
• 원격 GPU 배포 (Remote GPU deployment)

첫 번째 마일스톤 (Milestone)은 아름다운 이미지가 아닙니다.

첫 번째 마일스톤은 신뢰할 수 있는 루프 (Loop)입니다.

이것이 창의적 자동화에 중요한 이유

ComfyUI는 AI 이미지 작업이 소프트웨어 엔지니어링 (Software engineering)과 더 닮아가는 지점 중 하나입니다.

단순히 프롬프트를 작성하는 것이 아닙니다.

파이프라인 (Pipeline)을 구축하는 것입니다.

그 파이프라인은 버전 관리 (Versioned)가 가능하고, 재사용 (Reused)할 수 있으며, 검사 (Inspected), 디버깅 (Debugged)할 수 있고, 코드에서 호출 (Called)할 수 있습니다.

인간 아티스트에게는 더 많은 제어권을 제공합니다.

AI 에이전트에게는 훨씬 더 중요한 것, 즉 구조 (Structure)를 제공합니다.

워크플로에 형태 (Shape)가 갖춰져 있을 때 에이전트 (Agents)의 유용성은 훨씬 더 커집니다.

ComfyUI는 이미지 생성에 그 형태를 부여합니다.

그리고 워크플로가 명시적 (Explicit)이 되면, 에이전트는 추측을 멈추고 작동 (Operating)을 시작할 수 있습니다.