Compare commits
23 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 2ddf30f8e4 | |||
| 17730da7dd | |||
| 2a2a1ad3b1 | |||
| 22cd97698e | |||
| 0165cd367e | |||
| 5d4f85424e | |||
| 4302c516b2 | |||
| f767e388b0 | |||
| 346f773856 | |||
| 9e617af1ef | |||
| 4fe51ad645 | |||
| a3f63e56e2 | |||
| 1e4bad30f1 | |||
| f069b5775e | |||
| 2b246d30f1 | |||
| 1fb86e13de | |||
| 5586ac3f39 | |||
| dc27f71275 | |||
| 5aacea4ba6 | |||
| 32dc6adcf5 | |||
| 166c4319ee | |||
| 76f02260d5 | |||
| 3069c8aee5 |
@@ -1,56 +0,0 @@
|
||||
# Wiki — Project Architecture Context
|
||||
|
||||
> Auto-managed sections (between the AUTO markers) are rewritten by Astra on every refresh.
|
||||
> The rest below is yours — Astra never touches it once this file exists.
|
||||
|
||||
<!-- ASTRA:AUTO-START -->
|
||||
|
||||
## Snapshot
|
||||
- **Workspace**: `Wiki` _(absolute path varies by environment; resolved from the active VS Code workspace)_
|
||||
- **Stack**: _(unknown)_
|
||||
- **Stats**: 5 source files, ~96 lines across 1 top-level modules.
|
||||
|
||||
## Last Refresh
|
||||
- **Time**: 2026-05-20T14:48:25.240Z
|
||||
- **Files newly analysed**: 5
|
||||
- **Files reused from cache**: 0
|
||||
|
||||
## Directory Map
|
||||
```mermaid
|
||||
mindmap
|
||||
root((Wiki))
|
||||
docs/
|
||||
records/
|
||||
```
|
||||
|
||||
## Modules
|
||||
|
||||
### `docs/` — 5 files, ~96 lines
|
||||
|
||||
**Sub-directories**
|
||||
- `docs/records/` (5) — Wiki Chronicle Records
|
||||
|
||||
**Key files**
|
||||
- `docs/records/Wiki/README.md` (18 lines) — Wiki Chronicle Records
|
||||
- `docs/records/Wiki/chronicle.config.json` (11 lines) — JSON configuration
|
||||
- `docs/records/Wiki/development/2026-05-07_volumes-data-project-antigravity-wiki-여기는-내-지식-창고야-내용에-대한-평가_implementation.md` (29 lines) — Development Log: /Volumes/Data/project/Antigravity/Wiki 여기는 내 지식 창고야. 내용에 대한 평가해줘.
|
||||
- `docs/records/Wiki/project-profile.md` (31 lines) — Project Profile
|
||||
- `docs/records/Wiki/timeline.md` (7 lines) — Project Timeline
|
||||
|
||||
_Last auto-scan: 2026-05-20T14:48:25.240Z · signature `f5e5c8af`_
|
||||
<!-- ASTRA:AUTO-END -->
|
||||
|
||||
## Purpose
|
||||
_TODO: 이 프로젝트가 해결하려는 문제를 1–3문장으로._
|
||||
|
||||
## Key Workflows
|
||||
_TODO: 사용자/시스템의 주요 흐름 (예: 입력 → context assembly → model 호출 → action)._
|
||||
|
||||
## Current Constraints
|
||||
_TODO: 의도된 제약 (local-first, offline, 특정 API 의존 등)._
|
||||
|
||||
## Known Risks
|
||||
_TODO: 알려진 위험/디버깅 함정._
|
||||
|
||||
## Active Decisions
|
||||
_TODO: 살아 있는 ADR/원칙 (e.g. "기록은 markdown으로", "agent별 model override 우선")._
|
||||
@@ -1,41 +0,0 @@
|
||||
{
|
||||
"version": 1,
|
||||
"generatedAt": "2026-05-20T14:48:25.247Z",
|
||||
"files": {
|
||||
"docs/records/Wiki/README.md": {
|
||||
"mtimeMs": 1778171727000,
|
||||
"size": 407,
|
||||
"lines": 18,
|
||||
"role": "Wiki Chronicle Records",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/Wiki/chronicle.config.json": {
|
||||
"mtimeMs": 1778171727000,
|
||||
"size": 502,
|
||||
"lines": 11,
|
||||
"role": "JSON configuration",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/Wiki/development/2026-05-07_volumes-data-project-antigravity-wiki-여기는-내-지식-창고야-내용에-대한-평가_implementation.md": {
|
||||
"mtimeMs": 1778171727000,
|
||||
"size": 1597,
|
||||
"lines": 29,
|
||||
"role": "Development Log: /Volumes/Data/project/Antigravity/Wiki 여기는 내 지식 창고야. 내용에 대한 평가해줘.",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/Wiki/project-profile.md": {
|
||||
"mtimeMs": 1778171727000,
|
||||
"size": 566,
|
||||
"lines": 31,
|
||||
"role": "Project Profile",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/Wiki/timeline.md": {
|
||||
"mtimeMs": 1778171727000,
|
||||
"size": 274,
|
||||
"lines": 7,
|
||||
"role": "Project Timeline",
|
||||
"imports": []
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,3 @@
|
||||
# ASTRA runtime artifacts
|
||||
.astra/
|
||||
docs/records/
|
||||
@@ -0,0 +1 @@
|
||||
{"offset":619328157,"ts":1778162777308}
|
||||
@@ -0,0 +1 @@
|
||||
{"pid":19848,"heartbeat":1778168497853}
|
||||
@@ -1,46 +0,0 @@
|
||||
# [회의록] 롯데월드 이머시브 커머스 및 AI 스타일링 샵 기술 검토 회의
|
||||
|
||||
날짜: 2026년 05월 12일 | 17:00
|
||||
참석자: 김원일, 홍지훈, 김지환, 정현욱, 오경득, 오상묵, 정승민, 김준호, 김태현, 한예성
|
||||
주제 요약: 이머시브 스토어(360도 뷰)의 모바일/PC 최적화 현황을 시연하고, AI 스타일링 샵의 UI 개선 및 향후 개발 일정(5/19 목표)을 확정함.
|
||||
|
||||
🔹 요약 보고
|
||||
본 회의는 수정된 이머시브 커머스 결과물을 리뷰하고, 기술적 제약 사항(로딩 속도, 모바일 UI, 데이터 용량)에 대한 대응 방안을 논의하기 위해 진행되었습니다. 특히 롯데월드 앱 내 웹뷰 환경에서의 성능 이슈와 AI 스타일링 샵의 사용자 경험(UX) 개선을 위한 구체적인 가이드라인을 도출하였습니다.
|
||||
|
||||
1. 주요 논의 사항
|
||||
|
||||
[이머시브 스토어 기술 검토 및 최적화]
|
||||
현황: 외부 웹 호출 시 모바일 환경에서의 로딩 속도 및 캐싱 동작 확인 필요.
|
||||
핵심 논의:
|
||||
- 최초 접속 시 이미지/영상 다운로드로 인한 지연 발생(캐싱 적용 시 개선됨을 확인).
|
||||
- 모바일/PC 간의 카메라 뷰(View) 차이 조정: 의자가 너무 크게 보이는 문제 해결을 위해 카메라 높이 및 각도 재설정 필요.
|
||||
- 웹뷰 환경에서의 '뒤로 가기' 시 초기화 이슈: 롯데원 앱 내 웹뷰 특성상 발생하는 사이드 이펙트로, 현업 팀장이 인지하고 수용하기로 함.
|
||||
결론: [논의 중] (모바일 최적화를 위해 카메라 앵글 조정 및 리소스 경량화 작업 진행)
|
||||
|
||||
[AI 스타일링 샵 UI/UX 개선]
|
||||
현황: 상품 이미지(썸네일) 깨짐 현상 및 AI 어시스턴트 캐릭터 가독성 문제 발생.
|
||||
핵심 논의:
|
||||
- 썸네일 이미지 최적화: 고해상도 이미지가 리사이징되면서 발생하는 깨짐 현상을 방지하기 위해 해상도를 조정(2048 → 1024)하고 용량을 경량화함.
|
||||
- AI 어시스턴트 캐릭터 개선: 현재 제품 이미지가 노출되어 대화의 초점이 흐려지는 문제를 해결하기 위해, 캐릭터(여성 모델)를 전면에 배치하여 '어시스턴트'로서의 정체성을 강화하는 방향으로 수정 제안.
|
||||
- 가격 표기 정책: 할인율 변동에 따른 혼선을 방지하기 위해 모든 가격은 '정가 기준'으로 명시하고, 실제 할인가 정보는 구매 페이지에서 확인하도록 안내 문구 추가.
|
||||
|
||||
2. 리스크 및 이슈
|
||||
* 성능 저하 위험: 모바일 환경에서의 고해상도 이미지 로딩 시 메모리 점유율 상승 우려.
|
||||
* UI 불일치: PC와 모바일 간의 카메라 앵글 차이로 인한 사용자 경험 이질감.
|
||||
|
||||
3. 결정 사항
|
||||
* 캐릭터 교체: AI 어시스턴트 역할을 수행할 여성 모델 캐릭터를 전면에 배치하기로 함.
|
||||
* 가격 표기 원칙: 모든 UI 내 가격은 '정가' 기준으로 노출하며, 할인가 정보는 별도 안내함.
|
||||
* 이미지 최적화: 썸네일 해상도를 1024px로 하향 조정하여 로딩 속도 개선.
|
||||
|
||||
4. 오픈 이슈
|
||||
* 웹뷰 '뒤로 가기' 시 초기화되는 현상에 대한 기술적 우회 방안(필요시).
|
||||
* 파노라마 이미지 슬라이싱 작업의 최종 완료 여부 확인.
|
||||
|
||||
5. 액션 아이템
|
||||
담당 작업 내용 기한
|
||||
개발팀 AI 어시스턴트 캐릭터 교체 및 제품 아이콘/하이라이트 효과 검토 2026-05-19
|
||||
디자인/기술팀 모바일 환경 최적화(이미지 해상도 및 리소스 용량 조정) 2026-05-19
|
||||
기획/운영팀 가격 표기 문구(정가 기준) 및 안내 멘트 UI 반영 확인 2026-05-19
|
||||
기획팀 시연용 홍보 영상 제작 (목요일 오후 4시 전 완료 목표) 2026-05-14
|
||||
전체 팀 최종 빌드 배포 전 모바일 기종별 자체 QA 실시 2026-05-19
|
||||
@@ -1,7 +0,0 @@
|
||||
<find>
|
||||
# [Test Plan] 사내 성능 및 서버 부하 테스트 계획서
|
||||
... (생략) ...
|
||||
</find>
|
||||
<replace>
|
||||
(이 파일은 이동되었으므로 삭제하거나 참조용으로만 남겨둡니다.)
|
||||
</replace>
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,744 @@
|
||||
제목: AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀
|
||||
영상: https://www.youtube.com/watch?v=Qu4X0auqnqA
|
||||
비디오 ID: Qu4X0auqnqA
|
||||
언어 우선순위: ko, en
|
||||
세그먼트: 737개
|
||||
------------------------------------------------------------
|
||||
|
||||
회사 팀 차원에서 AI를 활용하는
|
||||
가장 좋은 방법은 뭘까요? 왜 기존
|
||||
회사들은 AI 시대에 뒤쳐질 수밖에
|
||||
없을까요? 그리고 왜 지금이 작은
|
||||
스타트업이 거대 기업을 이길 수 있는
|
||||
역사적 기회일까요? 다이에나 후는
|
||||
세계 최고의 스타트업 엑셀러레이터,
|
||||
와이 콤비네이터의 파트너입니다.
|
||||
그녀가 지금 몇 달 사이에 목격한
|
||||
아주 놀라운 현상에 대해 이야기하려고
|
||||
나섰습니다. 만약 당신이 창업자거나
|
||||
팀을 이끄는 사람이거나 혹은 조금 전
|
||||
질문의 답이 궁금하시다면 꼭 끝까지
|
||||
들어보세요. 저는 보충 설명과 내용
|
||||
정리로 여러분의 이해를 도와드릴게요.
|
||||
Hi, I'm Diana and
|
||||
I'm a partner at YC.
|
||||
Over the past few
|
||||
months, it's become
|
||||
clear to me that AI
|
||||
is not just going to
|
||||
change how quickly
|
||||
software gets built
|
||||
or what workflows
|
||||
get automated. It's
|
||||
going to
|
||||
fundamentally change
|
||||
the way startup
|
||||
should be run from
|
||||
what rules will
|
||||
exist to what
|
||||
products are
|
||||
possible to build.
|
||||
In this episode, I'm
|
||||
going to discuss how
|
||||
founders should
|
||||
think about building
|
||||
an AI native
|
||||
company, what roles
|
||||
their team should
|
||||
have, and what
|
||||
concrete internal
|
||||
practices they can
|
||||
adopt right now to
|
||||
move much faster.
|
||||
Currently, most
|
||||
people talk about AI
|
||||
in terms of
|
||||
productivity.
|
||||
They'll talk at
|
||||
length about how it
|
||||
can make engineers
|
||||
more productive or
|
||||
say we need to add
|
||||
copilot to existing
|
||||
workflows and ship
|
||||
more features. This
|
||||
framing misses the
|
||||
shift we're
|
||||
currently seeing
|
||||
which is less about
|
||||
productivity booths
|
||||
than entirely a new
|
||||
capabilities. The
|
||||
right person with AI
|
||||
tools can now build
|
||||
features that used
|
||||
to require an entire
|
||||
team or were just
|
||||
impossible. Thinking
|
||||
about AI in terms of
|
||||
new capabilities has
|
||||
several implications
|
||||
for how founders
|
||||
should run their
|
||||
companies. At a high
|
||||
level, the way to
|
||||
think about AI is
|
||||
that should not be a
|
||||
tool your company
|
||||
just uses. It should
|
||||
be the operating
|
||||
company runs on.
|
||||
Yor은 유수의 회사들을 초기에
|
||||
키워낸 세계에서 가장 영향력 있는
|
||||
벤처 캐피털이에요. 2005년 폴
|
||||
그레이엄이 설립했고 오픈 AI의
|
||||
샘트먼이 약 5년 정도 사장직을
|
||||
여임했죠. YC 파트너라는 자리는
|
||||
매년 수백개 회사가 어떻게 성공하고
|
||||
실패하는지를 가장 가까이 있어
|
||||
지켜보는 위치입니다. 따라서 AI는
|
||||
도구가 아니라 운영 체제가 되어야
|
||||
한다는이에나의 주장은 최근 실제로
|
||||
빠르게 성장하는 회사들에서 공통적으로
|
||||
관찰된 패턴이라는 점에서 무게가
|
||||
실리죠. 참고로 다이에나 본인도
|
||||
엔지니어 출신이고요. 포켓몬 고를
|
||||
만든 회사 나이엔틱에서 AIAR AR
|
||||
분야를 이끈 경력이 있습니다. 어떤
|
||||
이야기를 하는지 더 들어보시죠.
|
||||
workfow, every
|
||||
decision and every
|
||||
process should flow
|
||||
through an
|
||||
intelligent layer
|
||||
that is constantly
|
||||
learning and
|
||||
improving. What this
|
||||
means concretely is
|
||||
every important
|
||||
process in your
|
||||
company should be
|
||||
captured by an
|
||||
intelligent close
|
||||
loop. A close loop
|
||||
captures
|
||||
inflammation, feeds
|
||||
it back into an
|
||||
intelligence
|
||||
systems, and improve
|
||||
the process over
|
||||
time. If you've ever
|
||||
studied control
|
||||
systems, you will be
|
||||
familiar with the
|
||||
difference between
|
||||
an open loop and a
|
||||
close loop system.
|
||||
Open loops are
|
||||
control systems
|
||||
without feedback
|
||||
loops. In the old
|
||||
world, companies
|
||||
basically ran as
|
||||
open loops. You made
|
||||
a decision, executed
|
||||
it, and didn't
|
||||
always
|
||||
systematically
|
||||
measure the outcome
|
||||
and adjust the
|
||||
process. Open loops
|
||||
are inherently
|
||||
lossy. A close loop,
|
||||
on the other hand,
|
||||
is self-regulating.
|
||||
It continuously
|
||||
monitors its output
|
||||
and adjusts its
|
||||
process to better
|
||||
meet the stated
|
||||
goal. Close loops
|
||||
are extremely
|
||||
powerful for
|
||||
correctness and
|
||||
stability with ag
|
||||
개방 폐쇄루프에 대한 이야기가
|
||||
나왔는데요. 이걸 이해하는 가장 쉬운
|
||||
비유는 요리인 것 같습니다. 개방
|
||||
루프는 레시피만 보고 요리하는
|
||||
방식이에요. 물m, 뭐 간장 두
|
||||
스푼, 10분 끓이기 적힌 대로만
|
||||
요리하고 중간에 맛을 보지 않습니다.
|
||||
음식이 짠지 싱거운지 미리 알 수
|
||||
없죠. 반면 폐쇄 루프는 중간중간
|
||||
간을 보면서 요리하는 방식이에요.
|
||||
끓이다가 한번 맛보고 싱거우면 소금을
|
||||
더 넣고 다시 맛보고 이렇게 결과를
|
||||
측정하고 조정하는 행위를 반복합니다.
|
||||
에어컨도 그렇죠. 설정 온도에
|
||||
도달했는지 계속 측정하면서 에어컨
|
||||
스스로 더우면 더 강하게 그리고
|
||||
시원해지면 약하게 자동 조절하죠.
|
||||
이런게 폐쇄 루프입니다. 다이에나가
|
||||
말하는 핵심은 이겁니다. 기존
|
||||
회사들은 회의, 결정, 실행으로
|
||||
끝나고 그 결과가 좋았는지 나빴는지
|
||||
체계적으로 확인하지 않습니다.
|
||||
체계적으로라는 말이 중요한데 결과를
|
||||
확인하고 반영하고자 하는 의지가
|
||||
있다고 해도 기존의 운영 체제가 이걸
|
||||
받쳐 주지 못합니다. 반면 AI
|
||||
네이티브 회사는 실행부터 결과 분석
|
||||
그다음 결정까지 체계적이고 근본적으로
|
||||
가능합니다. 속도도 빠르고 정확도도
|
||||
높죠. these close
|
||||
loops you will need
|
||||
to make your entire
|
||||
company queryable in
|
||||
other words the
|
||||
whole organization
|
||||
should be legible to
|
||||
AI every important
|
||||
action should
|
||||
produce an artifact
|
||||
that the
|
||||
intelligence at the
|
||||
center of the
|
||||
company can learn
|
||||
from and use to
|
||||
self-improve this
|
||||
means recording your
|
||||
meetings with a AI
|
||||
notaker, minimizing
|
||||
DMs and emails, and
|
||||
embedding agents
|
||||
throughout
|
||||
communication of all
|
||||
channels. It also
|
||||
means building
|
||||
custom dash with
|
||||
everything in the
|
||||
company. revenue,
|
||||
sales, engineering,
|
||||
hiring, ops,
|
||||
everything. Here's a
|
||||
concrete example of
|
||||
how it could work.
|
||||
Take engineering,
|
||||
management, and
|
||||
sprint planning. If
|
||||
you have an agent
|
||||
that has access to
|
||||
your linear tickets,
|
||||
all your Slack
|
||||
engineering
|
||||
channels, all
|
||||
customer feedback
|
||||
from emails or tools
|
||||
like PIN and GitHub,
|
||||
highlevel plans in a
|
||||
notion or Google
|
||||
doc, sales calls and
|
||||
recordings from
|
||||
daily standups, then
|
||||
the agent can
|
||||
analyze what was
|
||||
actually shipped in
|
||||
your previous print
|
||||
and how well they
|
||||
met customers needs
|
||||
for real. From
|
||||
there, you can go a
|
||||
step further with
|
||||
full visibility into
|
||||
what shipped, what
|
||||
worked and what
|
||||
didn't. Agents can
|
||||
start looking ahead.
|
||||
They can propose
|
||||
sprint plans for
|
||||
engineers that are
|
||||
way more predictable
|
||||
and accurate and on
|
||||
track. The days of
|
||||
manager status
|
||||
rollups that are
|
||||
super lossy are
|
||||
gone. Having managed
|
||||
engineering teas
|
||||
myself and now
|
||||
seeing this across
|
||||
multiple YC
|
||||
companies, this is a
|
||||
game changer. What
|
||||
used to require
|
||||
constant
|
||||
coordination becomes
|
||||
legible and querable
|
||||
by default. I've
|
||||
seen teams that do
|
||||
this cut their
|
||||
engineering sprint
|
||||
time in half and get
|
||||
close to 10x more
|
||||
than in that time.
|
||||
The overarching
|
||||
principle here is
|
||||
that to get their
|
||||
full capabilities,
|
||||
you need to provide
|
||||
models with as much
|
||||
context as you would
|
||||
provide an employee.
|
||||
When you do this,
|
||||
your company stops
|
||||
operating as a open
|
||||
loop where
|
||||
information is
|
||||
fragmented and
|
||||
manually
|
||||
interpreted. It
|
||||
becomes instead a
|
||||
close loop system.
|
||||
Status, decisions
|
||||
and outcomes are
|
||||
continuously
|
||||
captured and fed
|
||||
back into this
|
||||
intelligence layer.
|
||||
The result is a
|
||||
system that has an
|
||||
update view of리는
|
||||
데이터베이스에 질문한다라는 뜻인데요.
|
||||
다이에나가 말한 AI 네이티브 운영
|
||||
체제가 작동한다면 데이터베이스가
|
||||
아니라 AI에게 질문함으로써 서비스에
|
||||
대한 모든 답이 나오는 상태가 되는
|
||||
거겠죠. 뭐 예를 들어 지난달 우리
|
||||
고객들이 가장 많이 불평한 문제 세
|
||||
가지가 뭔가? 이번 분기에 영업 팀이
|
||||
어떤 기능을 가장 많이 요청받았는가?
|
||||
지난 6개월간 우리 회사가 내린 결정
|
||||
중에 실패한 것의 공통점은 무엇인가?
|
||||
다음 업데이트 때 반드시 넣어야 하는
|
||||
기능은 이런 질문을 누구나 할 수
|
||||
있고 누구에게나 정확도가 높은 응답이
|
||||
돌아옵니다. 현재 이런 시스템이 잘
|
||||
거쳐지지 않는 이유는 회사의 정보가
|
||||
여기저기 흩어져 있기 때문이고요.이를
|
||||
사람이 이어주고 전달해 주는 방식은
|
||||
정보 전달에 누수가 생길 수밖에
|
||||
없어요. 주요 정보가 오가하는 회의는
|
||||
반드시 전부 데이터화해야 한다고
|
||||
말하고 중요한 정보가 오가지만 정보가
|
||||
공유되지도 않고 쌓이지도 않는
|
||||
다이렉트 메시지나 산의 이메일은
|
||||
최소한으로 사용하라는 팁도 중요한 것
|
||||
같습니다. 메신저 메시지나 구두로
|
||||
중요 정보가 오가는 바람에 특정
|
||||
관리자와 친하지 않으면 정보와
|
||||
멀어지는 상황. 회사를 다녀본 분들은
|
||||
한 번쯤 경험하시거나 목격하셨을
|
||||
거예요. DM으로 업무 지시를 받고
|
||||
구두로 회의 결론을 내고 결정 과정을
|
||||
문서로 남기지 않는 문화. 저는
|
||||
스타트업에서도 많이 보고 들었습니다.
|
||||
이런 관행은 AI 시대에는 큰 약점이
|
||||
됩니다. AI가 학습할 수 있는
|
||||
데이터가 남지 않기 때문이죠.
|
||||
product AI software
|
||||
factories. If you're
|
||||
familiar with the
|
||||
test driven
|
||||
development or TDD,
|
||||
this is the next
|
||||
evolution of that.
|
||||
With software
|
||||
factories, humans
|
||||
right aspect and a
|
||||
set of tests that
|
||||
define success. And
|
||||
then AI agents
|
||||
generate the
|
||||
implementation
|
||||
and code and iterate
|
||||
until the test pass.
|
||||
The human defines
|
||||
what to build and
|
||||
judges the output.
|
||||
The actual code is
|
||||
the agent job. Some
|
||||
companies have
|
||||
already pushed this
|
||||
to the point where
|
||||
the repost contain
|
||||
no handwritten code,
|
||||
just specs and test
|
||||
hardnesses. Strong
|
||||
DMs AI team is an
|
||||
example of how to do
|
||||
this. Their end goal
|
||||
was a system that
|
||||
essentially
|
||||
eliminated the need
|
||||
for a human to write
|
||||
or review code. And
|
||||
so they build their
|
||||
own software factory
|
||||
where specs and
|
||||
scenario based
|
||||
validations drive
|
||||
agents to write test
|
||||
and iterate and code
|
||||
until it meets a
|
||||
probabilistic
|
||||
satisfaction
|
||||
thresold and it
|
||||
works. This is how
|
||||
you achieve thex
|
||||
engineer that Steve
|
||||
talked about by
|
||||
surrounding a single
|
||||
engineer with a
|
||||
system of agents
|
||||
that enable them to
|
||||
build things they
|
||||
would have never
|
||||
been able to build
|
||||
before. The era of
|
||||
10,000 X engineer is
|
||||
here.
|
||||
>> AI 소프트웨어 팩토리와 기존 회사의
|
||||
차이를 좀 더 쉽게 이야기해 보면요.
|
||||
기존 방식은 건축가가 설계도를 그리고
|
||||
인부들이 직접 벽돌를 쌓아서 집을
|
||||
짓는 방식이라면 AI 소프트웨어
|
||||
팩토리에서는
|
||||
건축가가이 집은 침실 세 개, 화장실
|
||||
두 개 무너지지 않아야 하고 단열이
|
||||
잘 되어야 한다. 이런 요구 사항과
|
||||
어 합격 기준만 작성합니다. 그러면
|
||||
로봇 인부들이 알아서 집을 짓고 또
|
||||
테스트도 하고 통과할 때까지
|
||||
자기들끼리 고치고 짓는 걸 반복하죠.
|
||||
중간 피드백, 최종 검수 이런
|
||||
절차까지도 사라지겠죠. td라는 말은
|
||||
간단히 말씀을 드리면 코드를 짜기
|
||||
전에 합격 기준을 먼저 정하는
|
||||
방식인데요. 시험 문제를 먼저 만들어
|
||||
놓고 그 시험을 통과하는 답안을
|
||||
나중에 작성하는 것과 비슷합니다.
|
||||
단, td에서는 그 답안을 사람이
|
||||
쓰는데 AI 소프트웨어 팩토리는
|
||||
사람은 시어 문제, 즉 스펙과
|
||||
테스트까지만 만들고 답안을 쓰는 건
|
||||
AI 에이전트가 맞습니다. 요약하면
|
||||
소프트웨어 팩토리는 사람은 무엇을
|
||||
만들지만 결정하고 AI는 어떻게
|
||||
만들지를 알아서 처리하는 분업입니다.
|
||||
심지어 사람이 다음에 무엇을 만들지
|
||||
결정할 때 도움이 될 만한 분석
|
||||
자료와 정보들까지 제공해 주겠죠.
|
||||
꿈만 같은 일처럼 들리지만 이미
|
||||
도입되고 있고 가능한 일입니다.
|
||||
In the new world,
|
||||
the intelligence
|
||||
layer serves that
|
||||
purpose. If your
|
||||
company is
|
||||
queryable, artifact
|
||||
rich and legible to
|
||||
an AI, you should
|
||||
have almost no human
|
||||
middleware. This
|
||||
matters because your
|
||||
company's velocities
|
||||
is only as fast as
|
||||
its information
|
||||
flow. Every layer of
|
||||
human routing you
|
||||
can remove is a
|
||||
direct speed gain. A
|
||||
great example is
|
||||
what Jack Dory is
|
||||
doing over at block.
|
||||
After going deep on
|
||||
the tools, he's come
|
||||
to the same
|
||||
conclusion many
|
||||
half. This is about
|
||||
more than just
|
||||
incremental
|
||||
productivity gains.
|
||||
His view is that if
|
||||
you keep the same
|
||||
org chart and
|
||||
management
|
||||
structure, you miss
|
||||
the shift entirely.
|
||||
The company itself
|
||||
has to be rebuilt as
|
||||
an intelligence
|
||||
layer with humans at
|
||||
the edge guiding it
|
||||
rather than routing
|
||||
information through
|
||||
it. Going forward,
|
||||
Jack suggests every
|
||||
company will have
|
||||
three employee
|
||||
archetypes. The
|
||||
first is the
|
||||
individual
|
||||
contributor or IC.
|
||||
Basically the
|
||||
builder operator.
|
||||
This is someone who
|
||||
directly makes and
|
||||
runs things. In an
|
||||
AI native company
|
||||
this is not limited
|
||||
to engineers.
|
||||
Everyone builts,
|
||||
ops, support sales.
|
||||
Everyone comes to
|
||||
meetings with
|
||||
working prototypes,
|
||||
not pitch. Second is
|
||||
the DRI, the
|
||||
directly responsible
|
||||
individual. Focus on
|
||||
strategy and
|
||||
customer outcomes.
|
||||
This is not a
|
||||
classic manager is
|
||||
the person with a
|
||||
clear responsibility
|
||||
for the result. One
|
||||
person, one outcome,
|
||||
no hiding. The third
|
||||
is the AI founder
|
||||
type. This person
|
||||
still builds, still
|
||||
coaches and leads by
|
||||
example. If you're
|
||||
the founder, this
|
||||
needs to be you at
|
||||
the forefront.
|
||||
showing your team
|
||||
what massive
|
||||
capability gains
|
||||
look like. Not
|
||||
delicating your AI
|
||||
strategy to someone
|
||||
else. With this
|
||||
structure, companies
|
||||
will be able to get
|
||||
outsized results
|
||||
with much smaller
|
||||
teams. Maximizing
|
||||
token usage not head
|
||||
count will be the
|
||||
critical shift. The
|
||||
best companies will
|
||||
be the ones that are
|
||||
maxing. 잭도시가 누구냐면요
|
||||
지금은 X죠. 트위터의 공동
|
||||
창업자이자 결제회사 블록의
|
||||
CEO인데요. 실리콘 밸리에서 가장
|
||||
영향력이 있는 창업자 중에 한
|
||||
명입니다. 블록은 미국의 카드 결제
|
||||
서비스, 송금앱 등을 운영하고
|
||||
있어요. 즉 도시는 2024년
|
||||
경부터이 블록의 조직 구조를 과감하게
|
||||
뜯어친 것으로 화자가 됐습니다. 중간
|
||||
관리자가 너무 많다면서 매니저 직급을
|
||||
대거 주렸고 직접 만들고 실행하는
|
||||
사람들 중심으로 팀을 재편한 거죠.
|
||||
어, 다시 보니까이 세 가지 유형
|
||||
중에 하나에 속한다는 개념이라기보다
|
||||
복수의 유형을 한 사람이 겸할 수
|
||||
있는 속성의 개념인 것 같습니다.
|
||||
내가 100% 책임을 져야 하는 담당
|
||||
지표, 업무 이런게 있고요.이를 위해
|
||||
AI 도구를 능통하게 쓰면서 필요할
|
||||
땐 직접 제품이나 도구를 만드는
|
||||
사람, 포지션을 불문하고 최고의
|
||||
직원이 되겠죠. 이런 직원을 원한다면
|
||||
AI 운영 체제를 세팅하는 것은
|
||||
기본이고 정보를 전달하는 중간
|
||||
관리자를 없애거나 최소화하는 것도
|
||||
필수적으로 동반되어야 될 것 같아요.
|
||||
중간 관리자의 존재는 책임이 분산되는
|
||||
체계이자 작업자가 자기 미션을
|
||||
달성하기 위한 정보를 100% 얻기
|
||||
어려운 체계의 방증입니다. 참고로
|
||||
크랙 팀에서는 팀 내에서 필요한 여러
|
||||
가지 도구들을 AI로 그때그때 빠르게
|
||||
만들어 주는 전단 포지션이 있다고
|
||||
합니다. 예전에는 개발자한테 어떤
|
||||
고객 데이터를 모아서 달라고 요청하면
|
||||
뭐 하루 이틀 뒤에 엑셀 파일로 주는
|
||||
방식이었죠. 대부분. 그런데 이제는
|
||||
개발자가 아니어도 궁금한 고객
|
||||
데이터를 마음껏 물어볼 수 있는
|
||||
간단한 프로그램을 하루 이틀 기다리지
|
||||
않아도 이용할 수 있다는 겁니다. 잭
|
||||
도시가 말한 세 가지 유형의 팀원들만
|
||||
남도록 체질 개선을 하는 것이 너무
|
||||
무리인 것 같다면 중간 단계로 시도해
|
||||
볼 만한 방법인 것 같습니다.
|
||||
Think of the tradeof
|
||||
this way. One person
|
||||
with AI tools can be
|
||||
the equivalent of
|
||||
what used to take a
|
||||
large engineering
|
||||
team at a pre
|
||||
company. That means
|
||||
grammatically
|
||||
engineering, design,
|
||||
HR and admin teams.
|
||||
And so you should be
|
||||
willing to run an
|
||||
uncomfortably high
|
||||
API bill because
|
||||
it's replacing what
|
||||
would have taken a
|
||||
far more expensive
|
||||
and inflated head
|
||||
count. But don't
|
||||
just take my word
|
||||
for any of this. You
|
||||
cannot outsource
|
||||
your conviction on
|
||||
the power of these
|
||||
tools. You need to
|
||||
develop it yourself
|
||||
by actually sitting
|
||||
with coding agents
|
||||
and using them until
|
||||
you start to break
|
||||
your own priors
|
||||
about what is now
|
||||
possible to build.
|
||||
If you are an early
|
||||
stage founder, you
|
||||
have a huge
|
||||
advantage in getting
|
||||
ahead on this. You
|
||||
don't have legacy
|
||||
systems, interest or
|
||||
charts or thousands
|
||||
of people to
|
||||
retrain. You are
|
||||
small enough to
|
||||
build your company
|
||||
right from day one.
|
||||
The opposite is the
|
||||
case for existing
|
||||
companies. They have
|
||||
to maintain and grow
|
||||
a live product while
|
||||
unwinding years of
|
||||
standard operating
|
||||
procedures and core
|
||||
assumptions about
|
||||
how software gets
|
||||
built. Some
|
||||
companies can
|
||||
achieve this by
|
||||
spinning up small
|
||||
internal scunkw
|
||||
teams that can build
|
||||
AI native systems
|
||||
from scratch
|
||||
separate from the
|
||||
core business.
|
||||
Mutney is a great
|
||||
example of this but
|
||||
for most every
|
||||
change to their core
|
||||
processes risk
|
||||
breaking something
|
||||
that already works.
|
||||
So by their nature
|
||||
these large
|
||||
companies will have
|
||||
a much harder time
|
||||
going AI native.
|
||||
Startups don't have
|
||||
that constraint and
|
||||
that's a major edge
|
||||
to take advantage
|
||||
of. You can design
|
||||
your system workfows
|
||||
and culture around
|
||||
AI from the start
|
||||
and as a result
|
||||
operate
|
||||
다이에나는 제로베이스에서 AI
|
||||
네이티브 운영 체제를 세팅할 수 있는
|
||||
스타트업에게 유리한 판이라는 것을
|
||||
강조하면서도 기존 회사에게도
|
||||
아이디어를 주고 있어요. 먼저 스크
|
||||
웍스란 말이 나왔는데요. 회사 본부의
|
||||
복잡한 절차와 보고 라인에서 떨어져
|
||||
나와서 소수의 정애 멤버가 자유롭게
|
||||
새로운 것을 실험하는 작은 팀을
|
||||
의미합니다. 별동대라는 개념과 비슷할
|
||||
것 같은데요. 기존 회사가 AI
|
||||
리이티브 운영 체제를 도입하고 싶다면
|
||||
핵심 비즈니스와 아무런 관계가 없는
|
||||
작은 AI 네이티브 팀이 스краਅ크
|
||||
웍스 팀을 만들어서 그 팀이 완전히
|
||||
새로운 방식으로 일하면서 실험해 보는
|
||||
겁니다. 영상에 언급된 뮤티니는
|
||||
Y콤비네이터 출신 스타트업으로
|
||||
영업팀, 마케팅 팀이 필요한 고객
|
||||
대면 자료를 AI로 만들어 주는
|
||||
서비스인데요. 2018년에 설립되어서
|
||||
AI 네이티브 조직은 아니었어요.이
|
||||
레거시 팀이 AI 네이티 운영 체제와
|
||||
조직으로 아주 잘 변모한 듯합니다.이
|
||||
영상의 핵심을 간단하게 요약하면요.
|
||||
가장 중요한 메시지는 이겁니다.
|
||||
여러분은 AI가 일을 더 빨리 하게
|
||||
해 주는 도구가 아니라 팀의 체질를
|
||||
바꾸는 새로운 운영 방식으로
|
||||
이해하셔야 합니다. 뭐 지금까지 업무
|
||||
보조 도구로 생각하면서 직원들에게 뭐
|
||||
보조금, 지원금 정도만 주고 있다면
|
||||
생각을 크게 바꾸시는게 좋겠습니다.
|
||||
세 가지 핵심 개념이 나왔는데요. 첫
|
||||
번째는 폐쇄 루프 회사. 스스로
|
||||
학습하는 회사 시스템이죠. 모든 의사
|
||||
결정과 그 결과를 AI가 추적하고
|
||||
분석할 수 있게 만들어야 하고요. 두
|
||||
번째는 AI 소프트웨어 팩토리죠.
|
||||
사람은 무엇을 만들지 스펙만 정하고
|
||||
AI가 어떻게 만들지를 담당하는
|
||||
구조죠. 이게 잘 작동하면 엔지니어
|
||||
한 명이 과거 천명이 하던 일을 할
|
||||
수 있게 됩니다. 세 번째는 새로운
|
||||
조직 구조예요. 중간 관리자가 없는
|
||||
평평한 조직이 필요합니다. 정보를
|
||||
위아래로 전달하는 중간 관리자는 더
|
||||
이상 필요가 없습니다. 모든 직원이
|
||||
직접 만들고 명확한 책임을지면서
|
||||
창업자는 AI 활용에 선두에서야
|
||||
합니다. 우리에게 가장 힘이 되는
|
||||
대목은 마지막에 나온 것 같은데요.
|
||||
지금이 스타트업이 강좌를 앞지를 수
|
||||
있는 저로의 기회입니다. 기존
|
||||
시스템, 업조, 직원수, 소수
|
||||
정애입니다. 의사 결정 속도는
|
||||
기본적으로 빠르고요. AI 네이티브
|
||||
전환은 처음부터 [음악] 기초부터
|
||||
가능합니다. 작고 빠른 AI 네이티브
|
||||
스타트업은 기존 기업을 압도할
|
||||
[음악] 수 있는 역사적인 기회를
|
||||
거어줄 수 습니다.
|
||||
[음악]
|
||||
[음악]
|
||||
[음악]
|
||||
@@ -0,0 +1,155 @@
|
||||
# 유튜브분석 AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀 (정보) 2026-05-27
|
||||
|
||||
- **영상 URL**: https://www.youtube.com/watch?v=Qu4X0auqnqA
|
||||
- **분석 시각**: 2026-05-27T03:18:22.952Z
|
||||
- **분석 모드**: info
|
||||
- **생성**: Astra /youtube · Datacollect youtube insight
|
||||
|
||||
## 📜 전체 스크립트 (Full Script)
|
||||
|
||||
**[00:00]** 회사 팀 차원에서 AI를 활용하는 가장 좋은 방법은 뭘까요? 왜 기존 회사들은 AI 시대에 뒤쳐질 수밖에 없을까요? 그리고 왜 지금이 작은 스타트업이 거대 기업을 이길 수 있는 역사적 기회일까요? 다이에나 후는 세계 최고의 스타트업 엑셀러레이터, 와이 콤비네이터의 파트너입니다. 그녀가 지금 몇 달 사이에 목격한 아주 놀라운 현상에 대해 이야기하려고 나섰습니다. 만약 당신이 창업자거나 팀을 이끄는 사람이거나 혹은 조금 전 질문의 답이 궁금하시다면 꼭 끝까지
|
||||
|
||||
**[0:30]** 들어보세요. 저는 보충 설명과 내용 정리로 여러분의 이해를 도와드릴게요. Hi, I'm Diana and I'm a partner at YC. Over the past few months, it's become clear to me that AI is not just going to change how quickly software gets built or what workflows get automated. It's going to fundamentally change the way startup should be run from what rules will exist to what products are possible to build. In this episode, I'm going to discuss how
|
||||
|
||||
**[1:00]** founders should think about building an AI native company, what roles their team should have, and what concrete internal practices they can adopt right now to move much faster. Currently, most people talk about AI in terms of productivity. They'll talk at length about how it can make engineers more productive or say we need to add copilot to existing workflows and ship more features. This framing misses the shift we're currently seeing which is less about productivity booths than entirely a new
|
||||
|
||||
**[1:30]** capabilities. The right person with AI tools can now build features that used to require an entire team or were just impossible. Thinking about AI in terms of new capabilities has several implications for how founders should run their companies. At a high level, the way to think about AI is that should not be a tool your company just uses. It should be the operating company runs on. Yor은 유수의 회사들을 초기에 키워낸 세계에서 가장 영향력 있는
|
||||
|
||||
**[2:00]** 벤처 캐피털이에요. 2005년 폴 그레이엄이 설립했고 오픈 AI의 샘트먼이 약 5년 정도 사장직을 여임했죠. YC 파트너라는 자리는 매년 수백개 회사가 어떻게 성공하고 실패하는지를 가장 가까이 있어 지켜보는 위치입니다. 따라서 AI는 도구가 아니라 운영 체제가 되어야 한다는이에나의 주장은 최근 실제로 빠르게 성장하는 회사들에서 공통적으로 관찰된 패턴이라는 점에서 무게가 실리죠. 참고로 다이에나 본인도 엔지니어 출신이고요. 포켓몬 고를
|
||||
|
||||
**[2:30]** 만든 회사 나이엔틱에서 AIAR AR 분야를 이끈 경력이 있습니다. 어떤 이야기를 하는지 더 들어보시죠. workfow, every decision and every process should flow through an intelligent layer that is constantly learning and improving. What this means concretely is every important process in your company should be captured by an intelligent close loop. A close loop captures inflammation, feeds it back into an intelligence systems, and improve the process over time. If you've ever studied control
|
||||
|
||||
**[3:00]** systems, you will be familiar with the difference between an open loop and a close loop system. Open loops are control systems without feedback loops. In the old world, companies basically ran as open loops. You made a decision, executed it, and didn't always systematically measure the outcome and adjust the process. Open loops are inherently lossy. A close loop, on the other hand, is self-regulating. It continuously monitors its output and adjusts its process to better meet the stated
|
||||
|
||||
**[3:30]** goal. Close loops are extremely powerful for correctness and stability with ag 개방 폐쇄루프에 대한 이야기가 나왔는데요. 이걸 이해하는 가장 쉬운 비유는 요리인 것 같습니다. 개방 루프는 레시피만 보고 요리하는 방식이에요. 물m, 뭐 간장 두 스푼, 10분 끓이기 적힌 대로만 요리하고 중간에 맛을 보지 않습니다. 음식이 짠지 싱거운지 미리 알 수 없죠. 반면 폐쇄 루프는 중간중간
|
||||
|
||||
**[4:00]** 간을 보면서 요리하는 방식이에요. 끓이다가 한번 맛보고 싱거우면 소금을 더 넣고 다시 맛보고 이렇게 결과를 측정하고 조정하는 행위를 반복합니다. 에어컨도 그렇죠. 설정 온도에 도달했는지 계속 측정하면서 에어컨 스스로 더우면 더 강하게 그리고 시원해지면 약하게 자동 조절하죠. 이런게 폐쇄 루프입니다. 다이에나가 말하는 핵심은 이겁니다. 기존 회사들은 회의, 결정, 실행으로 끝나고 그 결과가 좋았는지 나빴는지 체계적으로 확인하지 않습니다.
|
||||
|
||||
**[4:30]** 체계적으로라는 말이 중요한데 결과를 확인하고 반영하고자 하는 의지가 있다고 해도 기존의 운영 체제가 이걸 받쳐 주지 못합니다. 반면 AI 네이티브 회사는 실행부터 결과 분석 그다음 결정까지 체계적이고 근본적으로 가능합니다. 속도도 빠르고 정확도도 높죠. these close loops you will need to make your entire company queryable in other words the whole organization should be legible to AI every important action should produce an artifact
|
||||
|
||||
**[5:00]** that the intelligence at the center of the company can learn from and use to self-improve this means recording your meetings with a AI notaker, minimizing DMs and emails, and embedding agents throughout communication of all channels. It also means building custom dash with everything in the company. revenue, sales, engineering, hiring, ops, everything. Here's a concrete example of how it could work. Take engineering, management, and sprint planning. If you have an agent that has access to your linear tickets,
|
||||
|
||||
**[5:30]** all your Slack engineering channels, all customer feedback from emails or tools like PIN and GitHub, highlevel plans in a notion or Google doc, sales calls and recordings from daily standups, then the agent can analyze what was actually shipped in your previous print and how well they met customers needs for real. From there, you can go a step further with full visibility into what shipped, what worked and what didn't. Agents can start looking ahead.
|
||||
|
||||
**[6:00]** They can propose sprint plans for engineers that are way more predictable and accurate and on track. The days of manager status rollups that are super lossy are gone. Having managed engineering teas myself and now seeing this across multiple YC companies, this is a game changer. What used to require constant coordination becomes legible and querable by default. I've seen teams that do this cut their engineering sprint time in half and get close to 10x more than in that time.
|
||||
|
||||
**[6:30]** The overarching principle here is that to get their full capabilities, you need to provide models with as much context as you would provide an employee. When you do this, your company stops operating as a open loop where information is fragmented and manually interpreted. It becomes instead a close loop system. Status, decisions and outcomes are continuously captured and fed back into this intelligence layer. The result is a system that has an update view of리는
|
||||
|
||||
**[7:00]** 데이터베이스에 질문한다라는 뜻인데요. 다이에나가 말한 AI 네이티브 운영 체제가 작동한다면 데이터베이스가 아니라 AI에게 질문함으로써 서비스에 대한 모든 답이 나오는 상태가 되는 거겠죠. 뭐 예를 들어 지난달 우리 고객들이 가장 많이 불평한 문제 세 가지가 뭔가? 이번 분기에 영업 팀이 어떤 기능을 가장 많이 요청받았는가? 지난 6개월간 우리 회사가 내린 결정 중에 실패한 것의 공통점은 무엇인가? 다음 업데이트 때 반드시 넣어야 하는
|
||||
|
||||
**[7:30]** 기능은 이런 질문을 누구나 할 수 있고 누구에게나 정확도가 높은 응답이 돌아옵니다. 현재 이런 시스템이 잘 거쳐지지 않는 이유는 회사의 정보가 여기저기 흩어져 있기 때문이고요.이를 사람이 이어주고 전달해 주는 방식은 정보 전달에 누수가 생길 수밖에 없어요. 주요 정보가 오가하는 회의는 반드시 전부 데이터화해야 한다고 말하고 중요한 정보가 오가지만 정보가 공유되지도 않고 쌓이지도 않는 다이렉트 메시지나 산의 이메일은
|
||||
|
||||
**[8:00]** 최소한으로 사용하라는 팁도 중요한 것 같습니다. 메신저 메시지나 구두로 중요 정보가 오가는 바람에 특정 관리자와 친하지 않으면 정보와 멀어지는 상황. 회사를 다녀본 분들은 한 번쯤 경험하시거나 목격하셨을 거예요. DM으로 업무 지시를 받고 구두로 회의 결론을 내고 결정 과정을 문서로 남기지 않는 문화. 저는 스타트업에서도 많이 보고 들었습니다. 이런 관행은 AI 시대에는 큰 약점이 됩니다. AI가 학습할 수 있는 데이터가 남지 않기 때문이죠.
|
||||
|
||||
**[8:30]** product AI software factories. If you're familiar with the test driven development or TDD, this is the next evolution of that. With software factories, humans right aspect and a set of tests that define success. And then AI agents generate the implementation and code and iterate until the test pass. The human defines what to build and
|
||||
|
||||
**[9:00]** judges the output. The actual code is the agent job. Some companies have already pushed this to the point where the repost contain no handwritten code, just specs and test hardnesses. Strong DMs AI team is an example of how to do this. Their end goal was a system that essentially eliminated the need for a human to write or review code. And so they build their own software factory where specs and scenario based validations drive
|
||||
|
||||
**[9:30]** agents to write test and iterate and code until it meets a probabilistic satisfaction thresold and it works. This is how you achieve thex engineer that Steve talked about by surrounding a single engineer with a system of agents that enable them to build things they would have never been able to build before. The era of 10,000 X engineer is here. >> AI 소프트웨어 팩토리와 기존 회사의 차이를 좀 더 쉽게 이야기해 보면요.
|
||||
|
||||
**[10:00]** 기존 방식은 건축가가 설계도를 그리고 인부들이 직접 벽돌를 쌓아서 집을 짓는 방식이라면 AI 소프트웨어 팩토리에서는 건축가가이 집은 침실 세 개, 화장실 두 개 무너지지 않아야 하고 단열이 잘 되어야 한다. 이런 요구 사항과 어 합격 기준만 작성합니다. 그러면 로봇 인부들이 알아서 집을 짓고 또 테스트도 하고 통과할 때까지 자기들끼리 고치고 짓는 걸 반복하죠.
|
||||
|
||||
**[10:30]** 중간 피드백, 최종 검수 이런 절차까지도 사라지겠죠. td라는 말은 간단히 말씀을 드리면 코드를 짜기 전에 합격 기준을 먼저 정하는 방식인데요. 시험 문제를 먼저 만들어 놓고 그 시험을 통과하는 답안을 나중에 작성하는 것과 비슷합니다. 단, td에서는 그 답안을 사람이 쓰는데 AI 소프트웨어 팩토리는 사람은 시어 문제, 즉 스펙과 테스트까지만 만들고 답안을 쓰는 건 AI 에이전트가 맞습니다. 요약하면 소프트웨어 팩토리는 사람은 무엇을
|
||||
|
||||
**[11:00]** 만들지만 결정하고 AI는 어떻게 만들지를 알아서 처리하는 분업입니다. 심지어 사람이 다음에 무엇을 만들지 결정할 때 도움이 될 만한 분석 자료와 정보들까지 제공해 주겠죠. 꿈만 같은 일처럼 들리지만 이미 도입되고 있고 가능한 일입니다.
|
||||
|
||||
**[11:30]** In the new world, the intelligence layer serves that purpose. If your company is queryable, artifact rich and legible to an AI, you should have almost no human middleware. This matters because your company's velocities is only as fast as its information flow. Every layer of human routing you can remove is a
|
||||
|
||||
**[12:00]** direct speed gain. A great example is what Jack Dory is doing over at block. After going deep on the tools, he's come to the same conclusion many half. This is about more than just incremental productivity gains. His view is that if you keep the same org chart and management structure, you miss the shift entirely. The company itself has to be rebuilt as an intelligence layer with humans at the edge guiding it rather than routing information through
|
||||
|
||||
**[12:30]** it. Going forward, Jack suggests every company will have three employee archetypes. The first is the individual contributor or IC. Basically the builder operator. This is someone who directly makes and runs things. In an AI native company this is not limited to engineers. Everyone builts, ops, support sales. Everyone comes to meetings with working prototypes, not pitch. Second is the DRI, the directly responsible individual. Focus on
|
||||
|
||||
**[13:00]** strategy and customer outcomes. This is not a classic manager is the person with a clear responsibility for the result. One person, one outcome, no hiding. The third is the AI founder type. This person still builds, still coaches and leads by example. If you're the founder, this needs to be you at the forefront. showing your team what massive capability gains look like. Not delicating your AI strategy to someone else. With this structure, companies
|
||||
|
||||
**[13:30]** will be able to get outsized results with much smaller teams. Maximizing token usage not head count will be the critical shift. The best companies will be the ones that are maxing. 잭도시가 누구냐면요 지금은 X죠. 트위터의 공동 창업자이자 결제회사 블록의 CEO인데요. 실리콘 밸리에서 가장 영향력이 있는 창업자 중에 한 명입니다. 블록은 미국의 카드 결제 서비스, 송금앱 등을 운영하고 있어요. 즉 도시는 2024년 경부터이 블록의 조직 구조를 과감하게
|
||||
|
||||
**[14:00]** 뜯어친 것으로 화자가 됐습니다. 중간 관리자가 너무 많다면서 매니저 직급을 대거 주렸고 직접 만들고 실행하는 사람들 중심으로 팀을 재편한 거죠. 어, 다시 보니까이 세 가지 유형 중에 하나에 속한다는 개념이라기보다 복수의 유형을 한 사람이 겸할 수 있는 속성의 개념인 것 같습니다. 내가 100% 책임을 져야 하는 담당 지표, 업무 이런게 있고요.이를 위해 AI 도구를 능통하게 쓰면서 필요할 땐 직접 제품이나 도구를 만드는
|
||||
|
||||
**[14:30]** 사람, 포지션을 불문하고 최고의 직원이 되겠죠. 이런 직원을 원한다면 AI 운영 체제를 세팅하는 것은 기본이고 정보를 전달하는 중간 관리자를 없애거나 최소화하는 것도 필수적으로 동반되어야 될 것 같아요. 중간 관리자의 존재는 책임이 분산되는 체계이자 작업자가 자기 미션을 달성하기 위한 정보를 100% 얻기 어려운 체계의 방증입니다. 참고로 크랙 팀에서는 팀 내에서 필요한 여러 가지 도구들을 AI로 그때그때 빠르게
|
||||
|
||||
**[15:00]** 만들어 주는 전단 포지션이 있다고 합니다. 예전에는 개발자한테 어떤 고객 데이터를 모아서 달라고 요청하면 뭐 하루 이틀 뒤에 엑셀 파일로 주는 방식이었죠. 대부분. 그런데 이제는 개발자가 아니어도 궁금한 고객 데이터를 마음껏 물어볼 수 있는 간단한 프로그램을 하루 이틀 기다리지 않아도 이용할 수 있다는 겁니다. 잭 도시가 말한 세 가지 유형의 팀원들만 남도록 체질 개선을 하는 것이 너무 무리인 것 같다면 중간 단계로 시도해 볼 만한 방법인 것 같습니다. Think of the tradeof
|
||||
|
||||
**[15:30]** this way. One person with AI tools can be the equivalent of what used to take a large engineering team at a pre company. That means grammatically engineering, design, HR and admin teams. And so you should be willing to run an uncomfortably high API bill because it's replacing what would have taken a far more expensive and inflated head count. But don't just take my word for any of this. You cannot outsource your conviction on
|
||||
|
||||
**[16:00]** the power of these tools. You need to develop it yourself by actually sitting with coding agents and using them until you start to break your own priors about what is now possible to build. If you are an early stage founder, you have a huge advantage in getting ahead on this. You don't have legacy systems, interest or charts or thousands of people to retrain. You are small enough to build your company right from day one. The opposite is the case for existing companies. They have to maintain and grow a live product while
|
||||
|
||||
**[16:30]** unwinding years of standard operating procedures and core assumptions about how software gets built. Some companies can achieve this by spinning up small internal scunkw teams that can build AI native systems from scratch separate from the core business. Mutney is a great example of this but for most every change to their core processes risk breaking something that already works. So by their nature these large companies will have a much harder time going AI native.
|
||||
|
||||
**[17:00]** Startups don't have that constraint and that's a major edge to take advantage of. You can design your system workfows and culture around AI from the start and as a result operate 다이에나는 제로베이스에서 AI 네이티브 운영 체제를 세팅할 수 있는 스타트업에게 유리한 판이라는 것을 강조하면서도 기존 회사에게도 아이디어를 주고 있어요. 먼저 스크 웍스란 말이 나왔는데요. 회사 본부의 복잡한 절차와 보고 라인에서 떨어져
|
||||
|
||||
**[17:30]** 나와서 소수의 정애 멤버가 자유롭게 새로운 것을 실험하는 작은 팀을 의미합니다. 별동대라는 개념과 비슷할 것 같은데요. 기존 회사가 AI 리이티브 운영 체제를 도입하고 싶다면 핵심 비즈니스와 아무런 관계가 없는 작은 AI 네이티브 팀이 스краਅ크 웍스 팀을 만들어서 그 팀이 완전히 새로운 방식으로 일하면서 실험해 보는 겁니다. 영상에 언급된 뮤티니는 Y콤비네이터 출신 스타트업으로 영업팀, 마케팅 팀이 필요한 고객
|
||||
|
||||
**[18:00]** 대면 자료를 AI로 만들어 주는 서비스인데요. 2018년에 설립되어서 AI 네이티브 조직은 아니었어요.이 레거시 팀이 AI 네이티 운영 체제와 조직으로 아주 잘 변모한 듯합니다.이 영상의 핵심을 간단하게 요약하면요. 가장 중요한 메시지는 이겁니다. 여러분은 AI가 일을 더 빨리 하게 해 주는 도구가 아니라 팀의 체질를 바꾸는 새로운 운영 방식으로 이해하셔야 합니다. 뭐 지금까지 업무 보조 도구로 생각하면서 직원들에게 뭐
|
||||
|
||||
**[18:30]** 보조금, 지원금 정도만 주고 있다면 생각을 크게 바꾸시는게 좋겠습니다. 세 가지 핵심 개념이 나왔는데요. 첫 번째는 폐쇄 루프 회사. 스스로 학습하는 회사 시스템이죠. 모든 의사 결정과 그 결과를 AI가 추적하고 분석할 수 있게 만들어야 하고요. 두 번째는 AI 소프트웨어 팩토리죠. 사람은 무엇을 만들지 스펙만 정하고 AI가 어떻게 만들지를 담당하는 구조죠. 이게 잘 작동하면 엔지니어 한 명이 과거 천명이 하던 일을 할 수 있게 됩니다. 세 번째는 새로운
|
||||
|
||||
**[19:00]** 조직 구조예요. 중간 관리자가 없는 평평한 조직이 필요합니다. 정보를 위아래로 전달하는 중간 관리자는 더 이상 필요가 없습니다. 모든 직원이 직접 만들고 명확한 책임을지면서 창업자는 AI 활용에 선두에서야 합니다. 우리에게 가장 힘이 되는 대목은 마지막에 나온 것 같은데요. 지금이 스타트업이 강좌를 앞지를 수 있는 저로의 기회입니다. 기존 시스템, 업조, 직원수, 소수 정애입니다. 의사 결정 속도는
|
||||
|
||||
**[19:30]** 기본적으로 빠르고요. AI 네이티브 전환은 처음부터 [음악] 기초부터 가능합니다. 작고 빠른 AI 네이티브 스타트업은 기존 기업을 압도할 [음악] 수 있는 역사적인 기회를 거어줄 수 습니다. [음악] [음악] [음악]
|
||||
|
||||
---
|
||||
|
||||
# AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀 — 정보 추출 카드
|
||||
|
||||
> **영상 URL**: https://www.youtube.com/watch?v=Qu4X0auqnqA · **분석 일자**: 2026-05-27 · **길이**: 20:01 · **채널**: Ladder Game
|
||||
|
||||
## 📋 구조화된 요약 (Structured Overview)
|
||||
*상단 대시보드 — 영상을 안 다시 보고도 핵심을 잡을 수 있게 압축. 아래 상세 섹션은 같은 내용의 깊이 버전.*
|
||||
|
||||
### 🎯 핵심 3요소
|
||||
- **주제**: AI 시대에 기업이 단순한 도구 활용을 넘어 'AI 네이티브 운영 체제'로 전환해야 하는 이유와 방법
|
||||
- **핵심 주장**: AI는 단순히 생산성을 높이는 도구가 아니라, 회사가 돌아가는 방식 자체를 바꾸는 운영 체제(OS)가 되어야 함
|
||||
- **근거/사례**:
|
||||
- '폐쇄 루프(Closed Loop)' 시스템을 통한 데이터 피드백과 자동 조정의 중요성
|
||||
- AI 소프트웨어 팩토리를 통한 개발 프로세스의 혁신 (인간은 스펙 결정, AI는 구현)
|
||||
|
||||
### ⏱️ 타임라인 기반 요약
|
||||
*영상이 짧아 생략 (아래 🧭 구조 요약 참조)*
|
||||
|
||||
### 📝 한 줄 요약 + 기억할 포인트
|
||||
- **한 줄**: 기업의 모든 프로세스를 AI가 학습하고 개선할 수 있는 '지능형 레이어'로 구축하여, 정보의 누락 없는 폐쇄 루프 시스템을 만들어야 함
|
||||
- **기억할 포인트 3~5개**:
|
||||
1. AI는 도구가 아닌 회사의 운영 체제(Operating System)여야 함
|
||||
2. 결과값을 측정하고 반영하는 '폐쇄 루프(Closed Loop)' 구조 구축이 핵심임
|
||||
3. 모든 회의와 결정 과정은 AI가 학습할 수 있도록 데이터화되어야 함 (DM, 이메일 최소화)
|
||||
4. 인간은 무엇을 만들지 결정하고, AI는 어떻게 만들지를 처리하는 '소프트웨어 팩토리'로 진화해야 함
|
||||
|
||||
## 🎯 한 줄 요약 (TL;DR)
|
||||
AI 시대의 기업은 단순한 생산성 향상을 넘어, 모든 비즈니스 프로세스가 AI에 의해 읽히고(legible) 질문 가능한(queryable) 상태인 'AI 네이티브 운영 체제'를 구축함으로써 거대한 규모의 인력을 대체하는 강력한 효율성을 확보해야 합니다.
|
||||
|
||||
## 💡 화자 한 줄 비유 (Anchor Metaphor)
|
||||
"개방 루프는 레시피만 보고 요리하는 방식(맛을 보지 않음)인 반면, 폐쇄 루프는 중간중엇간 간을 보면서 요리하는 방식입니다." (04:15)
|
||||
|
||||
## 📌 핵심 주장 3~5개
|
||||
- **[화자 주장]** "AI는 회사가 단순히 사용하는 도구가 아니라, 회사가 운영되는 운영 체제(Operating System)여야 합니다." — (01:28)
|
||||
- **[근거 명시]** "기존 회사들은 결정하고 실행한 뒤 결과를 체계적으로 측정하지 않는 '개방 루프' 방식이지만, AI 네이티브 회사는 실행부터 결과 분석까지 가능한 '폐쇄 루프'를 구축할 수 있습니다." — (04:35)
|
||||
- **[화자 주장]** "AI 소프트웨어 팩토리에서 사람은 무엇을 만들지 결정하고, 실제 코드를 작성하는 것은 AI 에이전트의 몫입니다." — (08:50)
|
||||
- **[근거 명시]** "잭 도시(Block CEO)는 중간 관리자를 줄이고 직접 실행하는 사람 중심으로 조직을 재편하며 새로운 직원 유형을 제시했습니다." — (10:20)
|
||||
|
||||
## 📊 사실·데이터·인용
|
||||
| 항목 | 값 / 정의 | 출처 (영상 내) | 타임스탬프 |
|
||||
| --- | --- | --- | --- |
|
||||
| AI 네이티브 운영 체제 핵심 원칙 | 모든 프로세스가 지능형 레이어를 통해 흐르고 학습되어야 함 | 다이애나 후 (YC 파트너) | 01:28 |
|
||||
| 잭 도시의 3가지 직원 유형 | IC(Builder), DRI(Strategy/Outcome), AI Founder Type | 잭 도시 (Block CEO) | 10:25 |
|
||||
way | 인간은 스펙과 테스트를 만들고, 에이전트는 구현을 담당함 | AI 소프트웨어 팩토리 개념 | 08:30 |
|
||||
|
||||
## 🧭 구조 요약 (Sectioned Summary)
|
||||
- **[00:00–01:27]** 도입부: AI 시대, 스타트업이 거대 기업을 이길 수 있는 이유와 다이애나 후의 관점 소개 (00:00–01:27)
|
||||
- **[01:28–04:30]** AI 네이티브 운영 체제: 도구를 넘어선 OS로서의 AI, 그리고 개방 루프 vs 폐쇄 루프(요리 비유) (01:28–04:30)
|
||||
- **[04:31–07:00]** 데이터 가용성: 회사의 모든 것을 AI가 질문 가능한 상태로 만들기 (모든 프로세스의 데이터화) (04:31–07:00)
|
||||
- **[07:01–08:59]** 소프트웨어 팩토리: 인간의 코딩 없이 스펙과 테스트만으로 작동하는 에이전트 기반 개발 방식 (07:01–08:59)
|
||||
- **[09:00–11:30]** 조직의 미래: 잭 도시가 제시한 세 가지 직원 유형과 중간 관리자 최소화 전략 (09:00–11:30)
|
||||
- **[11:31–끝]** 결론 및 제언: 초기 창업자의 이점과 AI 도구 활용을 통한 개인의 역량 확장 (11:31–끝)
|
||||
|
||||
## 🔗 인용용 한 줄 카드 (Citation Sniability)
|
||||
- "AI는 단순히 생산성을 높이는 것에 대한 논의가 아니라, 완전히 새로운 능력을 만드는 것에 대한 것입니다." — AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀, Ladder Game (01:05)
|
||||
- "모든 중요한 프로세스는 지능형 폐쇄 루프(intelligent closed loop)에 의해 캡처되어야 합니다." — AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀, Ladder Game (02:15)
|
||||
- "사람은 무엇을 만들지 결정하고, AI는 어떻게 만들지를 알아서 처리하는 분업이 이루어집니다." — AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀, Ladder Game (09:15)
|
||||
- "회사의 속도는 정보가 흐르는 속도와 같습니다. 제거할 수 있는 모든 인간의 중개 단계는 직접적인 속도 향상을 의미합니다." — AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재한 팀, Ladder Game (09:45)
|
||||
|
||||
## ❓ 더 파고들 질문 (Open Questions)
|
||||
- "본문에서 언급된 'AI 소프트웨어 팩토리'를 실제 엔지니어링 워크플로우에 적용하기 위한 구체적인 도구(Agentic Workflow 도구 등) 리스트는 무엇인가?"
|
||||
- "중간 관리자를 최소화하는 조직 구조가 기업의 장기적인 문화적 응집력이나 인재 유지(Retention)에 미칠 수 있는 부정적 영향은 없는가?"
|
||||
|
||||
## 🧩 정리자 노트 (원본 보강) — 선택
|
||||
*정리자 추가 노트 없음 — 본문 그대로가 명확함*
|
||||
@@ -1,290 +0,0 @@
|
||||
# 웹벤치마크 www.caliverse.io 2026-05-20
|
||||
|
||||
- **원본 URL**: www.caliverse.io
|
||||
- **스캔 시각**: 2026-05-20T04:11:24.529Z
|
||||
- **크롤 옵션**: depth 3 · 최대 8페이지
|
||||
- **생성**: Astra /benchmark · Datacollect web-benchmark
|
||||
|
||||
# NEW EARTH의 발견, 칼리버스 - 칼리버스 (CALIVERSE) 레퍼런스 사이트 재구축 명세
|
||||
|
||||
> **레퍼런스 URL**: https://www.caliverse.io
|
||||
> **분석 일자**: 2026-05-20
|
||||
> **분석 관점**: 4-렌즈 (Visual / Layout / Interaction / Voice) + IA 및 페이지 템플릿 + 재구축 명세
|
||||
> **스캔된 페이지**: 1개 (crawlDepth: 3)
|
||||
|
||||
## 한 줄 요약 (One-line Impression)
|
||||
무채색(Neutral) 중심의 강렬한 포인트 컬러(`rgb(26, 229, 172)`)를 사용하여 미래지향적이고 몰입감 있는 메타버스 세계관을 시각적으로 구현한 사이트입니다.
|
||||
|
||||
## 1. 시각적 정체성 (Visual Identity)
|
||||
### 1-1. 컬러 팔레트 (Color Palette)
|
||||
전체 구성 중 무채색이 94%로 매우 압도적인 비중을 차지하며, 포인트 컬러(Accent)는 6%로 제한되어 있어 극도의 대비를 보여줍니다.
|
||||
* **Primary Neutral**: `rgb(32, 332)` (가장 높은 빈도: 142회)
|
||||
* **Primary Accent**: `rgb(26, 229, 172)` (포인트 컬러로 사용됨)
|
||||
* **Secondary Neutral**: `rgb(255, 255, 255)` (48회)
|
||||
* **Link/Disabled State**: `rgba(255, 255, 255, 0.4)` (6회)
|
||||
* **Background**: `rgba(0, 0, 0, 0)` (스캔 데이터상 투명값으로 명시됨)
|
||||
|
||||
### 1-2. 타이포그래피 (Typography)
|
||||
글꼴은 가독성이 높은 산세리프 계열을 사용하며, 시스템 폰트 스택을 정교하게 구성하고 있습니다.
|
||||
* **Primary Font Stack**: `Pretendard`, `"Noto Sans KR"`, `"Noto Absent JP"`, `sans-serif`
|
||||
* **Body Text**: `16px` 크기, `400` 웨이트, `normal` 라인 높이 적용
|
||||
* **Button Text (UI Component)**:
|
||||
* `24px` 크기의 대형 버튼 요소 존재 (`fontFamily: "Arial"`)
|
||||
* 일반 텍스트는 `14px` 및 `16px` 위주로 구성됨
|
||||
* **Font Weights**: `400`(166회), `500`(35회), `600`(18회) 순으로 사용되어 정보의 계층을 분리함
|
||||
|
||||
## 2. 레이아웃 및 여백 (Layout & Whitespace)
|
||||
### 2-1. 그리드 시스템 (Grid System)
|
||||
* **Viewport**: `1440px` x `900px` 기준 설계
|
||||
* **Container**: `header`와 `main`은 `width: 1440px`이며, `maxWidth: none`으로 설정되어 화면 전체를 활용함
|
||||
* **Header Padding**: `0px 30px`의 좌우 여백을 가짐
|
||||
|
||||
### 2-2. 섹션 간 여백 (Section Spacing)
|
||||
* 스캔 데이터 내 명시적인 섹션 간 간격 수치는 "스캔 데이터 부족"으로 확인됨
|
||||
|
||||
### 2 3. 카드/카드 그리드 (Card Spacing)
|
||||
* **Card Layout**: `MuiList-root` 클래스를 통해 구현된 리스트 형태의 구조를 가짐
|
||||
* **Gap**: 요소 간 `horizontalGapPx: 25px`의 간격이 적용됨
|
||||
|
||||
### 2-4. Border Radius / 컨테이너
|
||||
* **Button/UI**: `4px`(버튼), `8px`(KR 선택기), `100px`(Log-in 버튼) 등 목적에 따라 상이함
|
||||
* **Media**: 비디오 요소(`video`)에는 `20px`의 큰 곡률 적용
|
||||
|
||||
## 3. 마이크로 인터랙션 (Micro Interaction)
|
||||
### 3-1. Hover / Focus 효과
|
||||
* **Button Hover**: `.mui-style-1s7qa4e:hover` 시 배경색이 `rgba(32, 32, 32, 0.1)`로 변화하며 색상 대비를 제공함
|
||||
* **Link/Input**: `input:focus` 시 `outline: none` 처리가 되어 있으며, 특정 요소에 대해 `box-shadow`를 통한 피드백을 설계함
|
||||
|
||||
### 3-2. Transition 패턴
|
||||
* 모든 속성(`all`)에 대해 `0.2s` 동안 `ease-in-out` 및 `ease` 가속도가 적용되어 부드러운 움직임을 구현함 (`duration: 0.2s`, `count: 3/1`)
|
||||
|
||||
### 3-3. 레이어링 (z-index / position)
|
||||
* **Fixed Header**: `header` 요소는 `position: fixed`, `z-index: 1000`으로 설정되어 스크롤 시 상단에 고정됨
|
||||
* **Overlay/Layer**: `MuiBox-root mui-style-5iw4aw`와 같이 `z-index: 1000`을 가진 레이어가 존재함
|
||||
|
||||
## 4. 라이팅 톤앤매너 (Microcopy & Voice)
|
||||
### 4-1. 헤드라인 / 서브헤드라인 / CTA 카피
|
||||
* **Headline/Description**: "In our exploration, we’ve discovered a strange new world..."와 같이 미지의 세계를 탐험하는 듯한 서사적 문체를 사용함
|
||||
* **CTA Samples**: `Shop`, `Workshop`, `Log-in`, `KR` 등 명확하고 짧은 명령형/명사형 단어를 사용하여 행동 유도력을 높임
|
||||
|
||||
### 4-2. Placeholder 및 보이스 신호
|
||||
* **Voice Signal**: 감정적 동요가 없는 정중한(Polite) 톤을 유지하며, 이모지나 느낌표 등의 과도한 사용은 배제됨 (`usesPolite: false`, `usesEmoji: false`)
|
||||
* **Body Sample**: "About"과 같은 간결한 단어를 통해 정보의 성격을 정의함
|
||||
|
||||
---
|
||||
|
||||
## 5. 정보 구조 / 사이트 맵 (Information Architecture)
|
||||
|
||||
### 5-1. 사이트 트리 다이어그램 (Page Tree)
|
||||
```text
|
||||
/ (other · list-card · imgs:19 · CTA:4) NEW EARTH의 발견, 칼리버스 - 칼리버스 (CALIVERSE)
|
||||
```
|
||||
|
||||
### 5-2. 페이지 목록 (Flat View)
|
||||
* `https://www.caliverse.io/` (메인 랜딩 페이지)
|
||||
|
||||
### 5-3. 페이지별 구성 요약 (Page Composition)
|
||||
| 페이지 URL | 주요 역할 | 주요 섹션 구성 (Section Roles) | 콘텐츠 타입 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `/` | 브랜드 및 서비스 소개 랜딩 | `header` → `main` → `footer` | `list-card` |
|
||||
|
||||
### 러5-4. IA 특징 정리
|
||||
* **단일 페이지 구조**: 전체 사이트가 하나의 페이지(`totalPages: 1`)로 구성된 싱글 페이지 애플리케이션(SPA) 형태의 랜딩 페이지입니다.
|
||||
* **내비게이션 중심**: `header`와 `nav`를 통해 `About`, `Caliverse`, `Guide`, `Company`, `Contact` 등 서비스의 주요 섹션으로 연결되는 구조를 가집니다.
|
||||
* **콘텐츠 집중도**: 텍规律적인 페이지 이동보다는 스크롤을 통한 정보 전달(Depth 3~4)에 집중되어 있습니다.
|
||||
|
||||
### 5-5. 재구축용 컴포넌트 명세 (Component Reconstruction Spec)
|
||||
| 컴포넌트 ID | 타입 | 속성 및 스타일 명세 (Attributes & Styles) | 비고 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `btn-shop` | Button | `width: 63px`, `height: 24px`, `border-radius: 4px`, `font-size: 24px` | Icon/Text형 |
|
||||
| `btn-workshop` | Button | `width: 99px`, `height: 24px`, `border-radius: 4px`, `font-size: 24px` | Icon/Text형 |
|
||||
| `btn-login` | Button | `width: 125px`, `height: 42px`, `padding: 8px 25px`, `border-radius: 100px`, `bg: rgb(0,0,0)`, `color: rgb(26,229,172)` | Primary CTA |
|
||||
| `btn-lang` | Button | `width: 70px`, `height: 24px`, `border-radius: 8px`, `font-size: 14px`, `font-weight: 600` | Language Switcher |
|
||||
| `nav-item` | List Item | `font-size: 16px`, `font-weight: 400`, `background: rgba(0,0,0,0)` | Navigation Link |
|
||||
| `card-link` | List Item | `font-size: 16px`, `text: "AboutCaliverse..."`, `padding: 0px` | Footer/Menu Link |
|
||||
|
||||
### 5-6. 미디어 처리 (Media Treatment)
|
||||
* **이미지(Img)**: 총 19개 요소 중 스캔 데이터상 확인된 규격화된 이미지 포함 (`width: 207px, height: 19px` 등). `object-fit: contain` 적용 필요.
|
||||
* **비디오(Video)**: 4개의 비디오 소스 존재. `width: 1100px`, `height: 280px`, `aspectRatio: 3.s93`, `border-radius: 20px` 규격 준수 필요.
|
||||
|
||||
---
|
||||
|
||||
## 6. 준비해야 할 리소스 (Resources You Need to Prepare)
|
||||
|
||||
### 6-1. 페이지별 이미지/비디오 수
|
||||
* **이미지**: 총 19개 (로고, 아이콘, 배너 등 포함)
|
||||
* **비디오**: 4개 (`aspectRatio: 3.93`의 고정 규격 영상)
|
||||
|
||||
### 6-2. 카피라이팅 분량
|
||||
* **Headline/Description**: "In our exploration, we’ve discovered a strange new world..." (약 150자 내외 영문 텍스트)
|
||||
* **Footer Info**: 상호, 대표자명, 주소, 연락처 등 법적 고지 정보 포함.
|
||||
|
||||
### 6-3. 폼/입력 필드 목록
|
||||
* 스캔 데이터상 `formField` 개수: 0 (입력 폼 없음)
|
||||
|
||||
---
|
||||
|
||||
## 7. 디자인 토큰 (Design Tokens)
|
||||
|
||||
### Color & Typography
|
||||
| 분류 | Token | Value (Exact) |
|
||||
| :--- | :--- | :--- |
|
||||
| **Color** | Primary Text | `rgb(32, 32, 32)` |
|
||||
| | Accent Color | `rgb(26, 229, 172)` |
|
||||
| | Link Color | `rgba(255, 25*s, 255, 0.4)` |
|
||||
| | Background (Neutral) | `rgb(32, 32, 32)` (count: 142), `rgb(255, 255, 255)` (count: 48) |
|
||||
| **Typography** | Primary Font | `Pretendard`, `"Noto Sans KR"`, `"Noto Sans JP"`, `sans-serif` |
|
||||
| | Body Size | `16px` |
|
||||
| | Button Size | `24px` |
|
||||
| | Font Weight | `400`, `500`, `600`, `700` |
|
||||
|
||||
### Layout & Spacing
|
||||
| 분류 | Token | Value (Exact) |
|
||||
| :--- | :--- | :--- |
|
||||
| **Spacing** | Header Padding | `0px 30px` |
|
||||
| | Footer Padding | `20px 0px` |
|
||||
| **Radius** | Border Radius Scale | `4px`, `8px`, `20px`, `100px` (Pill shape) |
|
||||
| **Layout** | Viewport Size | `1440px * 900px` |
|
||||
|
||||
---
|
||||
|
||||
## 8. 페이지 템플릿 맵 (Page Template Map)
|
||||
|
||||
| 템플릿 ID | 적용 URL | 공통 블록 순서 (위 → 아래) | 페이지별 차이점 | 재사용 컴포넌트 |
|
||||
|---|---|---|---|---|
|
||||
| T1: Brand Landing | `/` | Header → Nav → Main(Hero/Content) → Footer | (단독 페이지) | Header, Nav, Main, Footer |
|
||||
|
||||
**Template Specification Notes:**
|
||||
* **T1 (Brand Landing)**: `header`와 `nav`는 `position: fixed` 또는 `sticky`로 상단 고정(`zIndex: 1000`)을 기본으로 하며, `main` 섹션 내의 콘텐츠는 `viewport` 높이에 따라 스크롤되는 구조임. `main` 태그 내부에는 비디오 요소(`video`, `borderRadius: 20px`)가 포함된 섹션이 배치되어야 함.
|
||||
|
||||
---
|
||||
|
||||
## 9. 원본 사이트 재구축 명세 (Rebuild Spec — Same Site, Built From Scratch)
|
||||
|
||||
> **⚠️ 이 단계의 미션 (절대 이탈 금지)**
|
||||
> - 이 섹션은 **원본 레퍼런스 사이트와 가능한 한 같은 사이트를 처음부터 다시 만들기 위한 개발 명세**다.
|
||||
> - 다른 서비스로 재해석하거나 개선하지 않으며, 오직 원본의 수치를 그대로 복원하는 데 집중한다.
|
||||
> - 모든 결정값(색상, 폰트, 여백, Radius, 전환 속도)은 제공된 JSON 스캔 데이터의 값을 정확히 인용한다.
|
||||
|
||||
### 9-1. 디자인 토큰 정의 (원본 값 그대로)
|
||||
|
||||
```css
|
||||
/* CSS Variables Definition */
|
||||
:root {
|
||||
/* Colors - Palette from JSON */
|
||||
--color-neutral-dark: rgb(32, 32, 32);
|
||||
--color-white: rgb(255, 255, 255);
|
||||
--color-accent: rgb(26, 229, 172);
|
||||
--color-black: rgb(0, 0, 0);
|
||||
--color-transparent-white: rgba(255, 255, 255, 0.4);
|
||||
--color-transparent-white-low: rgba(255, 255, 255, 0.6);
|
||||
--color-black-alpha: rgba(0, 0, 0, 0);
|
||||
|
||||
/* Typography */
|
||||
--font-primary: "Pretendard", "Noto Sans KR", "Noto Sans JP", sans-serif;
|
||||
--font-body: "Noto Sans KR", -apple-system, BlinkMacSystemFont, "system-ui", Roboto, "Helvetica Neue", "Segoe UI", "Apple SD Gothic Neo", "Malgun Gothic", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", sans-serif;
|
||||
--font-size-base: 16px;
|
||||
--font-size-button-text: 24px; /* From button.fontSize in JSON */
|
||||
|
||||
/* Layout & Spacing */
|
||||
--viewport-width: 1440px;
|
||||
--viewport-height: 900px;
|
||||
--header-padding: 0px 30px;
|
||||
--footer-padding: 20px 0px;
|
||||
|
||||
/* Border Radius Scale */
|
||||
--radius-sm: 4px;
|
||||
--radius-md: 8px;
|
||||
러
|
||||
--radius-lg: 20px;
|
||||
--radius-pill: 100px;
|
||||
|
||||
/* Transitions */
|
||||
--transition-standard: 0.2s ease-in-out;
|
||||
}
|
||||
```
|
||||
|
||||
### 9-2. 컴포넌트 명세 (원본 사이트의 카드/버튼/네비 등)
|
||||
|
||||
| 컴포넌트 타입 | 속성 (Props/CSS) | 상세 수치 및 값 (JSON 근거) |
|
||||
| :--- | :--- | :--- |
|
||||
| **Button (Primary)** | `background`, `color`, `border-radius`, `padding` | `rgb(0, 0, 0)`, `rgb(255, 255, 255)`, `100px`, `8px 25px`, `font-weight: 600` |
|
||||
| **Button (Ghost/Link)** | `background`, `border`, `font-size` | `rgba(0, 0, 0, 0)`, `0px none rgb(32, 32, 32)`, `24px` |
|
||||
| **Navigation Item** | `font-size`, `font-weight` | `16px`, `400` |
|
||||
| **Card (List Item)** | `padding`, `border-radius`, `font-size` | `0px`, `0px`, `16px` |
|
||||
| **Video/Media Container**| `border-radius`, `object-fit` | `20px`, `cover` |
|
||||
|
||||
### 9-3. 페이지별 레이아웃 마크업 가이드
|
||||
|
||||
#### [Template T1: Main Landing Page]
|
||||
**구조 (HTML Skeleton):**
|
||||
```html
|
||||
<!-- Header Section -->
|
||||
<header class="e1rkdor11 MuiBox-root mui-style-1c8koze" style="padding: 0 30px; display: flex;">
|
||||
<!-- Logo & Navigation -->
|
||||
<nav class="MuiBox-root mui-style-1ypl5o3">
|
||||
<ul>...</ul>
|
||||
</nav>
|
||||
<!-- CTA Buttons (Shop, Workshop, Log-in, KR) -->
|
||||
<div class="button-group">...</div>
|
||||
</header>
|
||||
|
||||
<!-- Main Content Section -->
|
||||
<main class="e1rkdor10 MuiBox-root mui-style-17l764i">
|
||||
<!-- Hero/Video Section -->
|
||||
<section class="hero-section">
|
||||
<video width="1100" height="280" style="border-radius: 20px;"></video>
|
||||
<h1>JUMP IN CALIVERSE...</h1>
|
||||
</section>
|
||||
<!-- Content List/Cards -->
|
||||
<section class="content-grid">
|
||||
<!-- MuiList-root components -->
|
||||
</section>
|
||||
</main>
|
||||
|
||||
<!-- Footer Section -->
|
||||
<footer class="MuiBox-root mui-style-1d7wxpy" style="padding: 20px 0px;">
|
||||
<p>상호: 주식회사 칼리버스 | ...</p>
|
||||
</footer>
|
||||
```
|
||||
|
||||
### 9-4. 인터랙션 재현 명세
|
||||
|
||||
* **Button Hover (Link/Icon Type):**
|
||||
* `selector: .mui-style-1s7qa4e.MuiButtonBase-root:hover`
|
||||
* `background: rgba(32, 32, 32, 0.1)`
|
||||
* `color: rgb(32, 32, 32)`
|
||||
* **Global Transition:**
|
||||
* `property: all`, `duration: 0.2s`, `easing: ease-in-out` (또는 `ease`)
|
||||
* **Input Autofill Fix:**
|
||||
* `selector: input:-webkit-autofint`
|
||||
* `transition: background-color 9999s ease-out`
|
||||
|
||||
### 9-5. 콘텐츠 및 자산 준비 목록
|
||||
|
||||
* **[이미지/비디오 자산]**
|
||||
* [ ] 로고 이미지 (Width: 207px, Height: 19px)
|
||||
* [ ] 메인 비주얼 비디오 (3개 세트, 1100x280px, `object-fit: cover`, `border-radius: 20px`)
|
||||
* [ ] 기타 아이콘 및 UI 요소 (12px~24px 크기의 PNG/SVG)
|
||||
* **[텍래프트/카피]**
|
||||
* [ ] 메인 헤드라인 ("JUMP IN CALIVERSE...")
|
||||
* [ ] 푸터 정보 (주소, 대표자명, 이메일 등 텍스트 데이터)
|
||||
* **[기타]**
|
||||
* [ ] KR 언어 선택을 위한 국가 아이콘/텍스트
|
||||
|
||||
### 9-6. 개발 티켓 (원본 복원 기준)
|
||||
|
||||
* **[FE]** 디자인 토큰(CSS Variables) 기반 테마 설정 (`:root` 정의)
|
||||
* **[FE]** Material UI(MUI) 스타일 클래스(`mui-style-...`)를 활용한 레이아웃 구조 구현
|
||||
* **[FE]** Header/Navigation 컴포넌트 및 반응형 미디어 쿼리(`max-width: 1280px` 등) 적용
|
||||
* **[Asset]** 비디오 플레이어 컴포넌트 제작 (`border-radius: 20px` 적용)
|
||||
* **[Asset]** 로고 및 UI 아이콘 에셋 등록
|
||||
|
||||
---
|
||||
|
||||
## 🔍 복원 시 추정이 필요한 영역 (Buildability Gaps)
|
||||
|
||||
* **Dynamic Data:** `AboutCaliverseCaliumGuideCompanyContact`와 같이 하나의 문자열로 뭉쳐 있는 리스트 항목들의 개별 분리 구조.
|
||||
* **Video Source:** 비디오 태그(`video`) 내부에 실제 재생될 소스 파일의 경로 및 포맷.
|
||||
* **Navigation Logic:** `nav` 태프트 내의 각 메뉴 클릭 시 이동할 내부/외부 링크(URL) 매핑 정보.
|
||||
* **Font Files:** `Pretendable`, `Noto Sans KR` 등의 웹폰트 호스팅 및 `@font-face` 선언 경로.
|
||||
@@ -1,25 +0,0 @@
|
||||
# 웹벤치마크 www.caliverse.io 분석해줘. 2026-05-20
|
||||
|
||||
- **원본 URL**: www.caliverse.io 분석해줘.
|
||||
- **스캔 시각**: 2026-05-20T03:04:08.592Z
|
||||
- **생성**: Astra /benchmark · Datacollect web-benchmark
|
||||
|
||||
### 메타
|
||||
- **title**: (없음)
|
||||
- **description**: (없음)
|
||||
- **lang**: (없음)
|
||||
|
||||
### 디자인 토큰 (상위)
|
||||
- **컬러 팔레트 Top 5**: (없음)
|
||||
- **컬러 비율**: (없음)
|
||||
- **Primary Font**: `(없음)`
|
||||
- **그리드**: (없음)
|
||||
|
||||
### 사이트맵 (1페이지, depth 1)
|
||||
```
|
||||
/ (unknown)
|
||||
```
|
||||
|
||||
### 마이크로카피
|
||||
- **헤드라인**: (없음)
|
||||
- **CTA Top 5**: (없음)
|
||||
@@ -0,0 +1,49 @@
|
||||
# [회의 제목] 롯데월드 신규 어트랙션 홍보를 위한 이머시브 커머스 제안 검토 회의
|
||||
|
||||
- **날짜**: 2026년 05월 08일 금요일
|
||||
- **참석자**: 한예성, 참석자 1, 참석자 2, 참석자 3, 참석자 4, 참석자 5, 참석자 6, 참석자 7, 참석자 8, 참석자 9
|
||||
- **주제 요약**: 롯데월드 신규 어트랙션 홍보를 위한 3D 파노라마 기반의 이머시브 커머스 콘텐츠 기획안 및 개발 구현 방안 논의
|
||||
|
||||
## 🔹 요약 보고
|
||||
* **콘텐츠 컨셉**: 3D 파노라마 탐험(70~80%)과 미니 게임(10~20%)을 결합하여 신규 어트랙션의 세계관을 체험하고 홍보하는 방식.
|
||||
* **개발 방향성**: 모바일 우선(Mobile First) 환경에 최적화된 UI/UX 구현 및 웹 기반의 가벼운 기능 중심 설계.
|
||||
* **핵심 과제**: 롯데월드 측으로부터 신규 어트랙션 관련 리소스(영상, 이미지 등)를 적기에 확보하는 것과 미니 게임의 난이도 조절 및 개발 공수 관리.
|
||||
* **비즈니스 전략**: 단순 정보 전달을 넘어 세계관 체험을 통한 방문 유도 및 이벤트(쿠폰, 하이패스 권한 등) 연계 제안.
|
||||
|
||||
## 1. 주요 논의 사항
|
||||
### [신규 어트랙션 홍보 콘텐츠 기획]
|
||||
- **현황**: 롯데월드 측에서 신규 어트랙션 홍보를 목적으로 하는 이머시브 커머스 제안을 검토 중임. 현재 아틀란티스를 예시로 한 샘플 구현 상태.
|
||||
- **핵ess 논의**:
|
||||
- 3D 파노라마 공간 내에서 미션을 수행하고, 간단한 미니 게임(타이밍 맞추기 등)을 통해 어트랙션 정보를 전달하는 플로우 구성.
|
||||
- 사용자가 체험 후 실제 예매 페이지로 연결될 수 있도록 랜딩 구조 설계.
|
||||
- 롯데월드 홈페이지의 배너 형태를 활용하여 자연스러운 진입 유도 필요.
|
||||
- **결론**: 결정됨 (기획안 기반 제안 진행)
|
||||
|
||||
### [개발 구현 및 기술적 검토]
|
||||
- **현황**: 웹 환경에서 3D 파노라마와 미니 게임을 구동하기 위한 기술적 검토 중.
|
||||
- **핵심 논의**:
|
||||
- 모바일 사용 비중이 높으므로(약 95%) 모바일 최적화 및 UI/UX 구현이 필수적임.
|
||||
- 미니 게임이 너무 복잡해지면 웹 환경에서 무거워질 수 있으므로, 단순하고 가벼운 형태의 게임을 유지해야 함.
|
||||
- 유니티(Unity)를 활용한 웹 포팅 시 발생할 수 있는 개발 공수 및 성능 이슈 고려 필요.
|
||||
- **결론**: 논의 중 (미니 게임 수준에 따라 개발 범위 변동 가능성 있음)
|
||||
|
||||
## 2. 리스크 및 이슈
|
||||
* **리소스 확보 문제**: 신규 어트랙션의 구체적인 정보나 영상, 이미지 등 개발에 필요한 리소스가 사전에 제공되지 않을 경우 구현이 불가능함.
|
||||
* **개발 일정 및 공수**: 미니 게임의 난이도가 높아지거나 기능이 복잡해질 경우, 약 2개월~2개월 반의 예상 개발 기간 내 완수가 어려울 수 있음.
|
||||
* **유출 리스크**: 신규 어트랙션 정보가 사전에 노출되는 것에 대한 롯데월드 측의 우려 존재.
|
||||
|
||||
## 3. 결정 사항
|
||||
* **개발 방향**: 모바일 우선(Mobile First) 원칙을 준수하여 개발 진행.
|
||||
* **콘텐츠 구성**: 파노라마 탐험을 메인으로 하되, 이벤트성 미니 게임을 포함하는 구조로 유지.
|
||||
* **제안 전략**: 단순한 기능 제공보다는 세계관을 체험할 수 있는 '경험' 중심의 가치 전달에 집중.
|
||||
|
||||
## 4. 오픈 이슈
|
||||
* **미니 게임 범위 확정**: 상대방(롯데월드)이 요구하는 새로운 형태의 게임이나 높은 난이도의 게임 요청 시 대응 방안 필요.
|
||||
* **연동 기술 검토**: 쿠폰 발급 또는 하이패스 권한 부여를 위해 롯데월드 계정 연동 및 IT 시스템과의 연계 가능 여부 확인 필요.
|
||||
|
||||
## 5. 액션 아이템
|
||||
| 담당 | 작업 내용 | 기한 |
|
||||
| --- | --- | --- |
|
||||
| 개발팀 | 스포티 니치(속도 개선 버전) PC/노트북 테스트 및 피드백 제공 | 즉시 |
|
||||
| 제안팀 | 롯데월드 측과 미팅을 통한 상세 요구사항 확인 및 추가 제안 진행 | 차기 미팅 시 |
|
||||
| 기획팀 | 신규 어트랙션 리소스 확보를 위한 일정 관리 및 현업 소통 | 프로젝트 착수 시 |
|
||||
@@ -0,0 +1,53 @@
|
||||
# [회의 제목] 스포티앤리치 피드백 대응 및 서비스 개선 회의
|
||||
|
||||
- **날짜**: 확인 불가
|
||||
- **참참석자**: 오상무, 김준호(발표자), 김태현팀장, 김원일 이사, 송병준팀장, 안현제팀장, 오경득팀장, PM 한예성
|
||||
- **주제 요약**: 롯데온 피드백에 따른 서비스 수정 사항 검토 및 향후 개발/운영 가이드라인 수립
|
||||
|
||||
## 🔹 요약 보고
|
||||
* 롯데온 측 피드백을 바탕으로 '오픈 전 필수 수정'과 '이후 개선 사항'으로 구분하여 대응 전략 수립.
|
||||
* 상품 가격 표기 방식 변경 및 UI(구매하기 버튼 위치) 조정 결정.
|
||||
* iOS 기기 속도 저하 문제에 대한 기술적 가이드라인(최소 스펙 안내) 마련.
|
||||
* 3D 아바타 기능 및 오프라인 스토어 구현 등 중장기적 요구사항에 대한 기술적 한계 및 정책적 방향성 확인.
|
||||
|
||||
## 1. 주요 논의 사항
|
||||
### [롯데온 피드백 대응: 가격 및 UI]
|
||||
- **현황**: 롯데온 측에서 할인 가능 여부 표기를 요청함. 현재 정가로 표시되어 있음.
|
||||
- **핵심 논의**: 텍스트 수정(정가 기준, 할인가는 구매 페이지 확인)과 함께 기존 박스 내에 위치한 '구매하기' 버튼을 상단으로 이동시켜 텍상 겹침 방지 필요.
|
||||
- **결론**: 결정됨 (버튼 위치 상단 이동 및 문구 수정 완료 예정)
|
||||
|
||||
### [iOS 기기 성능 이슈]
|
||||
- **현황**: 특정 iOS 기기에서 매장 진입 속도가 갤럭시 대비 느림(약 0.5~1초).
|
||||
- **핵심 논의**: 현업 사용 기기의 스펙 한계를 명시하여 가이드라인을 제공함으로써 기술적 책임 소재를 명확히 함.
|
||||
- **결론**: 결정됨 (최소 사양 가이드라인 제공)
|
||||
|
||||
### [모델 신체 스펙 옵션 추가]
|
||||
- **현황**: 키, 몸무게, 체형 등 선택 기능에 대한 요구사항 존재.
|
||||
- **핵심 논의**: 기능 구현 시 이미지 렌더링 속도 및 제작 시간 이슈 발생 가능성.
|
||||
- **결론**: 보류 (향후 적용 검토)
|
||||
|
||||
### [이머시브 스토어 내 기능 개선]
|
||||
- **현항**: 마네킹 상품 정보 보기 활성화 시 줌 인/아웃 불편 및 터치 영역 문제.
|
||||
- **핵심 논고**: '피팅룸' 터치 시 AI 스타일링 샵으로 연결되는 범위를 넓혀 사용자 편의성 증대. 브랜딩 컨셉(공간 탐험)에 집중하여 개발 범위 조정.
|
||||
- **결론**: 결정됨 (터치 영역 확대 및 가이드라인 작성)
|
||||
|
||||
## 2. 리스크 및 이슈
|
||||
* **데이터 휘발성 문제**: 롯데온으로 이동 후 뒤로가기 시 이전 상태(스타일링 숍 세팅값) 유지가 어려움. 쿠키 값 저장 등 기술적 협의 필요.
|
||||
* **개발 부하**: 3D 모델링 기반의 360도 회전 및 오프라인 매장 구현은 비용 및 개발 부하가 매우 높음 (현재는 AI 이미지 샷 기준으로 대응 중).
|
||||
|
||||
## 3. 결정 사항
|
||||
* **UI 수정**: 구매하기 버튼 위치 상단 이동 및 가격 안내 문구 변경.
|
||||
* **개발 정책**: 3D 아바타 이동 기능 제공 등은 브랜드 탐험 컨셉에 따라 제외하거나 스타일링 샵 위주로 추진.
|
||||
* **오픈 일정**: 6월 8일 프로모션 혜택 시작을 목표로 함.
|
||||
|
||||
## 4. 오픈 이슈
|
||||
* **채널 ID 확보**: 광고/마케팅용 채널 코드가 다음 주 중으로 확보되어야 테스트 및 QA 가능.
|
||||
* **롯데온 협업**: 뒤로가기 시 데이터 유지 기능을 위해 롯데온 개발자와의 기술적 규격(쿠키 값 등) 협의 필요.
|
||||
|
||||
## 5. 액션 아이템
|
||||
| 담당 | 작업 내용 | 기한 |
|
||||
| --- | --- | --- |
|
||||
| 개발팀 | 구매하기 버튼 위치 이동 및 UI 수정 | 차주 초 |
|
||||
| 개발팀 | 가격 안내 문구 수정 (정가 기준, 할인 확인 문구) | 차주 초 |
|
||||
| 기획/운영 | 롯데온 측에 전달할 기술 가이드라인(최소 스펙 등) 작성 | 완료 시까지 |
|
||||
| 개발팀 | 채널 코드 확보 및 테스트/QA 진행 | 다음 주 중 |
|
||||
@@ -0,0 +1,48 @@
|
||||
# [.Net 이슈 관련 업데이트 및 운영 프로세스 점검 회의]
|
||||
|
||||
- **날짜**: 2026년 5월 27일 | 오전 11시
|
||||
- **참석자**: 김원일 이사, 김상엽, 박준범, 최성연, 한예성
|
||||
- **주제 요약**: .Net 이슈 해결을 위한 라이브 빌드 QA 진행 현황 점검 및 운영 툴 관리/패치 노트 작성 프로세스 확립
|
||||
|
||||
## 🔹 요약 보고
|
||||
* **라이브 빌드 QA 및 업데이트**: 현재 전달받은 라이브 빌드에 대해 오늘 중 QA를 완료하고, 문제 없을 시 내일 중 업데이트 반영을 목표로 함.
|
||||
* **일본 법인 대응**: 로그인 후 칼리브레이션 오류 이슈 해결을 위해 일본 측(홍 실장)에 테스트 플라이트 등록 및 확인 요청 예정.
|
||||
* **운영 프로세스 정립**: 운영 툴 관리 및 강제 업데이트 판단 주체를 기획 담당자(성혜)로 지정하고, 패치 노트 작성 시 개발팀의 기술적 지원을 포함하기로 함.
|
||||
* **보안 및 기타**: 운영 툴 사용 권한 및 비밀번호 보안 관리 필요성 언급과 함께, 테스트용 단말기(S25 등) 활용 계획 논의.
|
||||
|
||||
## 1. 주요 논의 사항
|
||||
### [.Net 이슈 대응 및 업데이트 계획]
|
||||
- **현황**: .Net 적용 건은 라이브 확인을 마쳤으나, 현재 최신 라이브 빌드를 전달받기 위해 대기 중임. 일본 지역에서 발생하는 로그인 후 칼리브레이션 미인식 이슈를 해결하기 위한 코드 수정이 진행됨.
|
||||
- **핵심 논의**:
|
||||
- 오늘 중 QA를 마무리하고 문제없으면 즉시 업데이트 요청을 진행할 것.
|
||||
- 내일 중 업데이트 반영을 목표로 함.
|
||||
- **결론**: 결정됨
|
||||
|
||||
### [운영 툴 관리 및 패치 노트 작성 프로세스]
|
||||
- **현황**: 강제 업데이트 버전 설정 및 운영 툴 관리에 대한 책임 소재가 불분명함.
|
||||
- **핵심 논의**:
|
||||
- 운영 툴 관리는 기획 담당자(성혜)가 수행하며, 일본 법인장 확인 결과에 따라 강제 전환 여부를 판단함.
|
||||
- 패치 노트는 개발 측에서 1차 정리(서버/클라 개발자)하여 예성이 및 성혜에게 전달하고, 이를 바탕으로 유저용 언어로 수정함.
|
||||
- **결론**: 결정됨
|
||||
|
||||
## 2. 리스크 및 이슈
|
||||
* **일본 지역 이슈**: 일본 법인장 및 홍 실장이 겪고 있는 로그인/칼리브레이션 오류가 지속적으로 발생하고 있어, 코드 수정 후 재검증이 필요함.
|
||||
* **보안 위험**: 서버 팀장의 비밀번호 관리 방식(주기적 교체 등)에 대한 보안 취약점 우려 및 AI 해킹 시대의 보안 강화 필요성 제기.
|
||||
|
||||
## 3. 결정 사항
|
||||
* **운영 툴 관리 주체**: 기획 담당자(성혜)로 지정.
|
||||
* **패치 노트 작성 절차**: 개발자(1차 정리) $\rightarrow$ 예성이/성혜(2차 정리 및 유저용 언어 변환).
|
||||
* **업데이트 방식**: 일본 법인장이 확인한 후, 문제가 해결된 시점에 강제 업데이트 전환 여부를 결정함.
|
||||
|
||||
## 4. 오픈 이슈
|
||||
* **테스트 플라이트 등록**: 홍 실장에게 테스트 플라이트를 등록하여 QA를 동시에 진행할 수 있는 환경 구축 필요.
|
||||
* **단말기 테스트**: S25 등 최신 단말기를 활용한 퀄리티 체크 및 카메라 위치에 따른 필름형 테스트 버전 검증.
|
||||
|
||||
## 5. 액션 아이템
|
||||
| 담당 | 작업 내용 | 기한 |
|
||||
| --- | --- | --- |
|
||||
| 개발팀 | 라이브 빌드 QA 완료 및 업데이트 요청 | 오늘 중 |
|
||||
| 개발팀 | 패치 노트 초안 작성 (서버/클라 개발자) | 업데이트 전 |
|
||||
| 김원일 이사 | 홍 실장에게 테스트 플라이트 등록 지원 및 안내 | 완료 시 즉시 |
|
||||
| 성혜 | 운영 툴 관리 및 강제 업데이트 여부 판단 | 상시 |
|
||||
| 개발팀 | QA 결과값 정리 및 전달 (24 버전 관련) | 확인 후 즉시 |
|
||||
Vendored
BIN
Binary file not shown.
@@ -8,12 +8,12 @@
|
||||
## Snapshot
|
||||
- **Workspace**: `00_Raw` _(absolute path varies by environment; resolved from the active VS Code workspace)_
|
||||
- **Stack**: _(unknown)_
|
||||
- **Stats**: 5 source files, ~83 lines across 1 top-level modules.
|
||||
- **Stats**: 6 source files, ~110 lines across 1 top-level modules.
|
||||
|
||||
## Last Refresh
|
||||
- **Time**: 2026-05-13T14:14:16.214Z
|
||||
- **Files newly analysed**: 5
|
||||
- **Files reused from cache**: 0
|
||||
- **Time**: 2026-05-27T10:07:53.609Z
|
||||
- **Files newly analysed**: 0
|
||||
- **Files reused from cache**: 6
|
||||
|
||||
## Directory Map
|
||||
```mermaid
|
||||
@@ -25,19 +25,20 @@ mindmap
|
||||
|
||||
## Modules
|
||||
|
||||
### `docs/` — 5 files, ~83 lines
|
||||
### `docs/` — 6 files, ~110 lines
|
||||
|
||||
**Sub-directories**
|
||||
- `docs/records/` (5) — 00Raw Chronicle Records
|
||||
- `docs/records/` (6) — JSON configuration
|
||||
|
||||
**Key files**
|
||||
- `docs/records/00_Raw/README.md` (18 lines) — 00Raw Chronicle Records
|
||||
- `docs/records/00_Raw/chronicle.config.json` (11 lines) — JSON configuration
|
||||
- `docs/records/00_Raw/discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md` (16 lines) — Discussion: /Volumes/Data/project/Antigravity/Wiki/10Wiki/00Raw 여기 아래에 저장된거 같은데? topics폴더가...
|
||||
- `docs/records/00_Raw/development/2026-05-27_e-wiki-2nd-00-raw-폴더에-있는-회의록-a-b-e를-wiki화-해주고-저장은-e-wiki-2nd_implementation.md` (24 lines) — Development Log: E:\Wiki\2nd\00Raw 폴더에 있는 회의록 a,b,e를 wiki화 해주고 저장은 E:\Wiki\2nd\10Wiki\Topicsme...
|
||||
- `docs/records/00_Raw/discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md` (16 lines) — Discussion: /Volumes/Data/project/Antigravity/Wiki/10Wiki/00Raw 여기 아래에 저장된거 같은데? topics폴더가...
|
||||
- `docs/records/00_Raw/project-profile.md` (31 lines) — Project Profile
|
||||
- `docs/records/00_Raw/timeline.md` (7 lines) — Project Timeline
|
||||
- `docs/records/00_Raw/README.md` (18 lines) — 00Raw Chronicle Records
|
||||
- `docs/records/00_Raw/timeline.md` (10 lines) — Project Timeline
|
||||
|
||||
_Last auto-scan: 2026-05-13T14:14:16.214Z · signature `230d82a4`_
|
||||
_Last auto-scan: 2026-05-27T10:07:53.609Z · signature `1c09705`_
|
||||
<!-- ASTRA:AUTO-END -->
|
||||
|
||||
## Purpose
|
||||
|
||||
@@ -1,39 +1,46 @@
|
||||
{
|
||||
"version": 1,
|
||||
"generatedAt": "2026-05-13T14:14:16.215Z",
|
||||
"generatedAt": "2026-05-27T10:07:53.617Z",
|
||||
"files": {
|
||||
"docs/records/00_Raw/README.md": {
|
||||
"mtimeMs": 1778681649000,
|
||||
"size": 394,
|
||||
"lines": 18,
|
||||
"role": "00Raw Chronicle Records",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/chronicle.config.json": {
|
||||
"mtimeMs": 1778681650000,
|
||||
"size": 427,
|
||||
"mtimeMs": 1779876330777.5742,
|
||||
"size": 372,
|
||||
"lines": 11,
|
||||
"role": "JSON configuration",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md": {
|
||||
"mtimeMs": 1778681650000,
|
||||
"size": 1039,
|
||||
"docs/records/00_Raw/development/2026-05-27_e-wiki-2nd-00-raw-폴더에-있는-회의록-a-b-e를-wiki화-해주고-저장은-e-wiki-2nd_implementation.md": {
|
||||
"mtimeMs": 1779876330769.102,
|
||||
"size": 1560,
|
||||
"lines": 24,
|
||||
"role": "Development Log: E:\\Wiki\\2nd\\00Raw 폴더에 있는 회의록 a,b,e를 wiki화 해주고 저장은 E:\\Wiki\\2nd\\10Wiki\\Topicsme...",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md": {
|
||||
"mtimeMs": 1778720006542.9683,
|
||||
"size": 1055,
|
||||
"lines": 16,
|
||||
"role": "Discussion: /Volumes/Data/project/Antigravity/Wiki/10Wiki/00Raw 여기 아래에 저장된거 같은데? topics폴더가...",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/project-profile.md": {
|
||||
"mtimeMs": 1778681649000,
|
||||
"size": 484,
|
||||
"mtimeMs": 1778720006542.9683,
|
||||
"size": 515,
|
||||
"lines": 31,
|
||||
"role": "Project Profile",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/README.md": {
|
||||
"mtimeMs": 1778720006541.4622,
|
||||
"size": 412,
|
||||
"lines": 18,
|
||||
"role": "00Raw Chronicle Records",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/timeline.md": {
|
||||
"mtimeMs": 1778681650000,
|
||||
"size": 238,
|
||||
"lines": 7,
|
||||
"mtimeMs": 1779876330771.1025,
|
||||
"size": 429,
|
||||
"lines": 10,
|
||||
"role": "Project Timeline",
|
||||
"imports": []
|
||||
}
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
{
|
||||
"projectId": "00-raw",
|
||||
"projectName": "00_Raw",
|
||||
"projectRoot": "/Volumes/Data/project/Antigravity/Wiki/10_Wiki/00_Raw",
|
||||
"recordRoot": "/Volumes/Data/project/Antigravity/Wiki/10_Wiki/00_Raw/docs/records/00_Raw",
|
||||
"description": "Auto-created by Project Architecture activation.",
|
||||
"projectRoot": "e:\\Wiki\\2nd\\10_Wiki\\00_Raw",
|
||||
"recordRoot": "e:\\Wiki\\2nd\\10_Wiki\\00_Raw\\docs\\records\\00_Raw",
|
||||
"description": "Auto-detected from workspace folder.",
|
||||
"corePurpose": "",
|
||||
"detailLevel": "standard",
|
||||
"createdAt": "2026-05-13T14:13:57.873Z",
|
||||
"updatedAt": "2026-05-13T14:22:59.615Z"
|
||||
"createdAt": "2026-05-27T10:00:54.426Z",
|
||||
"updatedAt": "2026-05-27T10:05:30.777Z"
|
||||
}
|
||||
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
# Development Log: E:\Wiki\2nd\00_Raw 폴더에 있는 회의록 a,b,e를 wiki화 해주고 저장은 E:\Wiki\2nd\10_Wiki\Topics_me...
|
||||
|
||||
## Purpose
|
||||
Record the implementation or verification outcome from the current conversation.
|
||||
|
||||
## Implementation Summary
|
||||
결론: 세 개의 회의록 파일을 읽어 위키 문서로 재구성한 뒤, 지정하신 `E:\Wiki\2nd\10_Wiki\Topics_meeting` 경로에 각각 저장하겠습니다. 진행 상황: - [v] `회의록 a 2026-05-21.md` 분석 및 위키화 준비 완료 - [v] `회의록 b 2026-05-21.md` 분석 및 위키화 준비 완료 - [v] `회의록 e 2026-05-27.md` 분석 및 위키화 준비 완료 <create_file path="E:\Wiki\2nd\10_Wiki\Topics_meeting\회의록_a_2026-05-21.md"> [위키] 롯데월드 신규 어트랙션 홍보 이머시브 커머스 제안 검토 🔹 핵심 요약 - 날짜: 2026년 05월 08일 - 주제: 3D 파노라마 기반 이머시브 콘텐츠 기획 및 개발 방안 - 핵심 결정: 모바일 우선(Mobile First) 원칙 준수, 미니 게임을 포함한 경험 중심 가치 전달 1. 주요 논의 사항 [콘텐츠 기획] - 3D 파노라마 탐험...
|
||||
|
||||
## Architecture
|
||||
Captured automatically from the assistant response and active project context.
|
||||
|
||||
## Changed Files
|
||||
- 회의록 a 2026-05-21.md
|
||||
- 회의록 b 2026-05-21.md
|
||||
- 회의록 e 2026-05-27.md
|
||||
|
||||
## Dependency Notes
|
||||
No new dependency note was captured automatically.
|
||||
|
||||
## Bugs
|
||||
No bugs recorded.
|
||||
|
||||
## Lessons
|
||||
- Automatic project records should be generated in the background when the turn contains durable project knowledge.
|
||||
@@ -5,3 +5,6 @@
|
||||
|
||||
## 2026-05-13
|
||||
- Auto discussion record created: discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md
|
||||
|
||||
## 2026-05-27
|
||||
- Auto development record created: development\2026-05-27_e-wiki-2nd-00-raw-폴더에-있는-회의록-a-b-e를-wiki화-해주고-저장은-e-wiki-2nd_implementation.md
|
||||
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
id: /prompt-endpoint
|
||||
title: "/prompt endpoint"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy_api_python.py", "/workflow/convert", "new_pipeline.py", "comfyui_to_python.py"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[/prompt endpoint]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
`/prompt endpoint`는 시각적 노드 그래프를 실행 가능한 백엔드 명령으로 전환하여 ComfyUI의 강력한 생성 능력을 외부 애플리케이션 및 자동화 파이프라인과 연결하는 핵심 게이트웨이이다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **API Format (Backend Format):** `/prompt` 엔드포인트는 시각적 메타데이터가 제거되고 실행에 필수적인 노드 입력 및 연결 정보만 포함된 전용 JSON 형식을 요구한다 [1, 4, 5].
|
||||
- **Flattened Execution Graph:** 엔드포인트에 전달되는 데이터는 링크가 노드 입력 내부에 직접 삽입된 형태로, 백엔드 엔진이 즉시 처리할 수 있도록 최적화된 구조를 가진다 [1, 6, 7].
|
||||
- **Programmatic Interaction:** HTTP POST 요청을 통해 JSON 페이로드를 전송함으로써 GUI 없이도 워크플로우를 실행하고 실시간으로 파라미터를 수정할 수 있다 [8-10].
|
||||
- **Self-Contained Requests:** 이미지 입력을 Base64로 인코딩하여 JSON 내에 직접 포함시킴으로써 별도의 파일 저장 없이도 서버 사이드 처리가 가능한 독립적인 생성 요청을 구성한다 [10, 11].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **UI-API 분리 패턴:** 사용자 인터페이스를 위한 `workflow.json`(Frontend)과 실제 실행을 위한 `workflow_api.json`(Backend)을 엄격히 구분하여 효율성을 극대화한다 [4, 12, 13].
|
||||
- **직접 딕셔너리 조작(Direct Dictionary Manipulation):** Python 등의 언어로 JSON 파일을 로드한 후, 노드 ID를 키로 사용하여 프롬프트나 시드(Seed) 값을 동적으로 교체하는 패턴이 주로 사용된다 [9, 10].
|
||||
- **웹소켓(WebSocket) 결합 구조:** `/prompt` 엔드포인트로 작업을 큐잉(Queueing)한 후, `/ws` 엔드포인트를 통해 진행 상황과 최종 생성된 바이너리 데이터를 실시간으로 수신한다 [10].
|
||||
- **실행 모델 인버전(Execution Model Inversion):** 백엔드 엔진은 전달된 JSON에서 최종 출력 노드(Save Image 등)부터 역추적하여 필요한 노드만 실행하는 최적화 로직을 수행한다 [14].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
`/prompt endpoint`는 ComfyUI 서버가 외부로부터 실행 명령을 받는 표준 HTTP API 경로이다 [3, 10]. 이 엔드포인트는 일반적인 저장용 JSON(Frontend Format)과 호환되지 않으며, 반드시 **'Dev mode Options'**를 활성화하여 추출한 **API Format JSON**을 페이로드로 사용해야 한다 [8, 15, 16].
|
||||
|
||||
API 요청 시 JSON의 루트 키는 노드 ID(숫자 또는 문자열)가 되며, 각 값은 해당 노드의 `class_type`과 `inputs`를 포함하는 객체로 구성된다 [9, 17]. 이때 입력 필드는 단순한 값뿐만 아니라 다른 노드의 출력 슬롯에 대한 참조(`[node_id, slot_index]`)를 포함하여 데이터 흐름을 정의한다 [6].
|
||||
|
||||
서버는 요청을 받으면 내부적으로 `validate_prompt` 함수를 호출하여 그래프의 무결성을 검증한 후, 이를 `ExecutionList`로 변환하여 순차적으로 노드를 실행한다 [18]. 만약 워크플로우에 필요한 커스텀 노드가 로컬 서버에 설치되어 있지 않으면 실행이 거부되므로, ComfyUI Manager 등을 통한 사전 의존성 해결이 필수적이다 [19-21].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **호환성 문제:** 일반적인 `Save` 버튼으로 생성된 JSON을 `/prompt` 엔드포인트에 직접 전송하면 에러가 발생한다 [16]. 반드시 `Save (API Format)`를 사용하거나 별도의 변환 도구를 거쳐야 한다 [15, 16].
|
||||
- **메타데이터 손실:** API 형식으로 변환된 JSON은 노드 위치나 그룹 정보가 모두 삭제되므로, 이를 다시 ComfyUI 캔버스에 드래그하면 시각적 레이아웃이 파괴된 "뼈대" 형태만 남게 된다 [22]. 따라서 원본 워크플로우 파일의 별도 보관이 권장된다 [22].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **comfy_api_python.py:** Python의 `urllib.request`를 사용하여 `http://{server_address}/prompt` 경로에 JSON 데이터를 POST 방식으로 전송하는 실제 구현 코드가 포함되어 있음 [10].
|
||||
- **/workflow/convert 엔드포인트:** 시각적 워크플로우 JSON을 서버 사이드에서 즉시 API 형식으로 변환하여 `/prompt` 엔드포인트에 바로 보낼 수 있도록 지원하는 커스텀 노드가 개발됨 [16, 21].
|
||||
- **Mystic Pipeline (new_pipeline.py):** 클라우드 환경에서 ComfyUI 서버를 구동하고 사용자 입력을 워크플로우 JSON에 주입하여 실행하는 파이프라인 자동화에 적용됨 [23, 24].
|
||||
- **ComfyUI-to-Python-Extension:** API 포맷의 워크플로우 JSON을 독립적으로 실행 가능한 `.py` 스크립트로 변환하는 CLI 도구 및 라이브러리 구조에서 핵심 참조 대상으로 사용됨 [25, 26].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 발견됨)
|
||||
- **출처 신뢰도:** B (Official Documentation / API Docs / GitHub Source Code)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
id: api-json-(backend-format)
|
||||
title: "API JSON (Backend Format)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["workflow_api.json", "Backend Format"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow_api.json", "/workflow/convert", "new_pipeline.py", "SaveImageWebsocket"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[API JSON (Backend Format)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
API JSON은 UI 메타데이터를 배제하고 실행 로직과 데이터 흐름만을 압축하여 서버 측 실행 및 프로그래밍 방식의 자동화에 최적화된 백엔드 전용 워크플로우 규격이다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **실행 중심 그래프 (Execution Graph):** 위치, 크기, 색상 등 시각적 요소를 제거하고 엔진이 노드를 처리하는 데 필요한 핵심 논리 구조만 포함한다 [1, 3, 4].
|
||||
2. **참조 기반 노드 연결:** 링크 객체를 별도로 관리하는 대신 노드 입력(`inputs`) 필드 내에 소스 노드 ID와 출력 슬롯 인덱스를 직접 배열(예: `[node_id, slot_index]`) 형태로 임베딩한다 [1, 5, 6].
|
||||
3. **데이터 경량화:** 시각적 메타데이터 제거를 통해 프런트엔드 JSON보다 파일 크기가 훨씬 작으며, 네트워크 전송 및 API 호출 페이로드로 사용하기에 적합하다 [2, 7, 8].
|
||||
4. **개발자 모드 활성화:** 표준 저장 방식과 달리 ComfyUI 설정에서 'Dev mode'를 명시적으로 활성화해야만 생성 및 내보내기가 가능하다 [9-11].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **노드 ID 키 매핑 패턴:** JSON의 루트 레벨에서 각 노드의 고유 숫자 ID(문자열 형태)를 키값으로 사용하며, 그 내부에 `class_type`과 `inputs`를 정의한다 [3, 12, 13].
|
||||
- **입출력 노드 최적화:** API 활용 시 이미지를 웹소켓으로 직접 수신하기 위해 `SaveImageWebsocket` 노드를 사용하거나, `Load Image (Base64)`를 통해 이미지 데이터를 직접 주입하는 구조를 취한다 [14].
|
||||
- **역방향 그래프 탐색:** 백엔드 엔진은 API JSON을 실행할 때 출력 노드(예: Save Image)부터 역방향으로 탐색하여 결과 도출에 필요한 종속 노드만 식별하고 실행한다 [15].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
API JSON(일반적으로 `workflow_api.json`으로 명명)은 ComfyUI의 백엔드 엔진과 직접 통신하는 언어 역할을 수행한다 [1, 2, 16].
|
||||
|
||||
- **프런트엔드 포맷과의 차별성:** 표준 `workflow.json`이 인간의 가독성과 편집 편의성을 위해 노드 좌표(`pos`), 크기(`size`), 그룹, 위젯 상태(`flags`) 등을 포함하는 것과 달리, API 포맷은 이러한 정보를 모두 폐기하고 오직 실행에 필요한 데이터만 남긴다 [1-3, 17, 18].
|
||||
- **내부 구조 분석:**
|
||||
- **`class_type`:** 노드 레지스트리에 등록된 실제 Python 클래스 이름을 참조한다 [4, 12, 19].
|
||||
- **`inputs`:** 위젯 값(텍스트, 숫자 등)과 다른 노드로부터 오는 동적 링크 정보를 모두 포함한다 [4, 5].
|
||||
- **생성 프로세스:**
|
||||
1. ComfyUI 설정 아이콘을 클릭한다 [9, 10, 20].
|
||||
2. 'Enable Dev mode Options' 체크박스를 활성화한다 [9-11].
|
||||
3. 메인 메뉴에 새로 나타난 'Save (API Format)' 버튼을 클릭하여 다운로드한다 [10, 11, 21].
|
||||
- **이미지 메타데이터와의 관계:** ComfyUI에서 생성된 PNG 파일의 메타데이터에는 프런트엔드 포맷(workflow)과 API 포맷(prompt) 데이터가 동시에 저장되어 있어, 이미지만으로도 시각적 복구와 프로그래밍 방식의 재실행이 모두 가능하다 [8, 22, 23].
|
||||
- **자동화 및 확장:** Python의 `json` 라이브러리를 사용하여 노드 ID를 기반으로 프롬프트나 시드 값을 동적으로 변경한 후 서버의 `/prompt` 엔드포인트로 전송하여 대량의 이미지를 생성할 수 있다 [6, 12, 14].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **가역성의 한계:** API JSON을 다시 ComfyUI 인터페이스로 드래그하여 불러올 경우, 시각적 위치 정보가 없기 때문에 노드들이 모두 겹쳐서 나타나는 '스켈레톤(skeleton)' 상태가 된다 [24]. 따라서 재편집을 위해서는 반드시 원본 프런트엔드 포맷을 별도로 보관해야 한다 [24].
|
||||
- **버전 호환성 문제:** ComfyUI의 빈번한 업데이트로 인해 구버전 JSON 파일이 최신 버전에서 정상적으로 작동하지 않을 수 있으며, 특히 커스텀 노드 의존성이 있는 경우 더욱 빈번하게 발생한다 [25].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **RunComfy Serverless API:** `workflow_api.json`을 내부적으로 저장하여 서버리스 실행 시 베이스라인으로 활용하며, API 호출 시 입력값만 오버라이드한다 [4, 16].
|
||||
- **Mystic Pipeline (`new_pipeline.py`):** Python SDK를 통해 ComfyUI 서버를 시작하고 API 포맷 JSON에 프롬프트를 주입하여 실행하는 템플릿에 적용됨 [26, 27].
|
||||
- **ComfyUI Workflow Converter (`bc85382`):** `/workflow/convert` 엔드포인트를 통해 비 API 포맷(Frontend)을 실시간으로 API 포맷으로 변환하여 `/prompt` 엔드포인트에 즉시 사용할 수 있도록 지원 [28-30].
|
||||
- **SaveImageWebsocket 노드:** API 환경에서 생성된 이미지를 파일 저장 대신 웹소켓을 통해 실시간 바이너리로 수신할 때 사용됨 [14].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
id: api-json-(workflow_api.json)
|
||||
title: "API JSON (workflow_api.json)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["Backend Format", "API Format JSON", "Execution Graph"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법", "API", "JSON"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["SethRobinson/comfyui-workflow-to-api-converter-endpoint", "fofr/any-comfyui-workflow", "Mystic Pipeline", "ComfyUI-to-Python-Extension"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[API JSON (workflow_api.json)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
API JSON은 ComfyUI의 시각적 메타데이터를 제거하고 백엔드 엔진의 즉각적인 실행을 위해 최적화된 경량화된 실행 그래프 형식이다 [1], [2], [3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **백엔드 실행 그래프 (Backend Execution Graph):** 노드 위치, 크기, 색상 등의 UI 정보를 배제하고 오직 노드 유형, 입력값, 연결 관계만을 포함하는 실행 전용 데이터 구조이다 [1], [4], [3].
|
||||
- **직접 링크 임베딩 (Direct Link Embedding):** 연결 정보가 별도의 객체 배열로 관리되지 않고, 각 노드의 입력 필드 내에 소스 노드 ID와 출력 슬롯 번호의 참조(`[node_id, slot_index]`) 형태로 직접 포함된다 [1], [2], [5].
|
||||
- **개발자 모드 의존성 (Dev Mode Dependency):** 표준 내보내기(Save)와 달리, ComfyUI 설정에서 'Enable Dev mode Options'를 활성화해야만 생성 및 수동 추출이 가능하다 [6], [7], [8], [9].
|
||||
- **프로그래밍적 제어 (Programmatic Control):** 텍스트 프롬프트, 시드(Seed) 등 위젯 값을 노드 ID를 통해 직접 수정할 수 있어 외부 애플리케이션 및 스크립트와의 자동화 연동에 핵심적인 역할을 한다 [10], [11], [12].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **UI-Stripping 패턴:** 시각적 요소(Litegraph 메타데이터)를 삭제하여 파일 크기를 축소하고 데이터 파싱 속도를 향상시킨다 [1], [13], [3].
|
||||
- **ID 기반 맵 구조:** 전체 JSON 구조가 노드 ID를 키(Key)로 하고 노드 정의(Inputs, Class Type)를 값(Value)으로 하는 단일 딕셔너리 형태를 취한다 [10], [14].
|
||||
- **입력 우선주의 (Execution Model Inversion):** 백엔드 엔진이 출력 노드(Save Image 등)로부터 역추적하여 필요한 노드만 실행하도록 하는 구조적 기반을 제공한다 [15].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **데이터 구조 및 구성 요소:** API JSON의 각 노드 객체는 해당 노드의 클래스 이름을 나타내는 `class_type`과 노드에 전달될 데이터인 `inputs`를 필수적으로 포함한다 [10], [3]. `inputs` 내에는 사용자가 직접 입력한 위젯 값과 다른 노드에서 전달되는 링크 정보가 공존한다 [5].
|
||||
- **프론트엔드 형식과의 차이:** 시각적 편집을 위한 `workflow.json`은 노드 위치(`pos`), 크기(`size`), 그룹 정보 등을 포함하여 다시 불러왔을 때 캔버스를 재구성할 수 있게 하지만, API JSON은 이를 모두 제거하여 "스켈레톤(skeleton)" 상태의 데이터만 남긴다 [1], [13], [16].
|
||||
- **생성 및 변환 프로세스:**
|
||||
- **수동 생성:** ComfyUI 설정 메뉴의 기어 아이콘을 클릭하여 'Enable Dev mode Options'를 활성화한 후, 메뉴 상단에 나타나는 'Save (API Format)' 버튼을 사용한다 [6], [7], [8].
|
||||
- **자동 추출:** ComfyUI에서 생성된 PNG/WebP 파일의 메타데이터(tEXt 또는 zTXt 청크)에서 `prompt` 태그를 통해 API 형식을 추출할 수 있다 [17], [18], [19].
|
||||
- **서버측 변환:** `comfyui-workflow-to-api-converter-endpoint`와 같은 커스텀 노드를 사용하여 일반 워크플로우 JSON을 API 형식으로 실시간 변환하여 `/prompt` 엔드포인트로 전송할 수 있다 [20], [21].
|
||||
- **실행 환경에서의 활용:** API JSON은 파이썬 스크립트에서 `urllib`이나 `requests`를 통해 ComfyUI 서버의 `/prompt` 경로로 POST 요청을 보낼 때 페이로드(Payload)로 사용된다 [11], [22]. 또한 Replicate와 같은 클라우드 플랫폼에서 서버리스 엔드포인트를 구동하는 기본 사양으로 채택된다 [23], [24], [4].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **가역성 상실:** API JSON을 ComfyUI 캔버스로 다시 드래그하면 시각적 레이아웃 정보가 없기 때문에 모든 노드가 겹쳐서 나타나거나 그룹 정보가 유실되어 수동 편집이 매우 어렵다 [16]. 따라서 편집용 'Full Workflow'를 항상 별도로 보관하는 것이 권장된다 [16].
|
||||
- **버전 호환성 주의:** ComfyUI의 잦은 업데이트로 인해 이전 버전에서 생성된 API JSON이 최신 백엔드 엔진에서 유효하지 않은 노드 클래스나 입력 방식을 참조할 경우 실행 오류가 발생할 수 있다 [25], [26].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **SethRobinson/comfyui-workflow-to-api-converter-endpoint:** 클라이언트 측의 자바스크립트 변환 로직을 파이썬으로 구현하여, 서버 측에서 비-API 워크플로우를 API 형식으로 즉시 변환해주는 커스텀 노드 (Commit: `bc85382`) [27], [20].
|
||||
- **fofr/any-comfyui-workflow (Replicate):** 사용자가 제공한 API JSON 블롭(blob)을 해석하여 이미지 및 비디오를 생성하는 범용 API 모델 [23], [24].
|
||||
- **Mystic Pipeline:** `new_pipeline.py` 스크립트를 통해 API JSON 워크플로우를 로드하고 입력 프롬프트를 동적으로 주입하여 서버리스 엔드포인트로 배포하는 구조 [9], [28].
|
||||
- **ComfyUI-to-Python-Extension:** API JSON 파일을 입력받아 독립적으로 실행 가능한 파이썬 스크립트(`.py`)로 변환하는 도구 [29], [30].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 발견으로 검증 가능성 높음)
|
||||
- **출처 신뢰도:** B (공식 문서 및 주요 오픈소스 프로젝트 기술 사양 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
id: base64-image-encoding
|
||||
title: "Base64 Image Encoding"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["이미지 Base64 인코딩", "Base64 Data Embedding"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.90
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법", "API", "Python"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy_api_python.py"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Base64 Image Encoding]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Base64 인코딩은 별도의 파일 스토리지 없이 이미지 바이너리를 문자열로 변환하여 ComfyUI API JSON 페이로드에 직접 포함시킴으로써 워크플로우를 데이터-논리 통합형 자립 구조로 변환하는 핵심 기술이다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Load Image (Base64) 노드:** 워크플로우 내에서 파일 경로 대신 Base64 인코딩 문자열을 직접 입력받아 이미지 데이터로 변환하는 전용 입력 노드이다 [1, 2].
|
||||
- **데이터 임베딩(Self-contained Request):** 이미지 원천 데이터를 JSON의 `inputs` 필드 내 `base64_data` 키에 직접 삽입하여, 요청 하나에 생성 로직과 원본 데이터를 동시에 전달한다 [1, 2].
|
||||
- **서버리스 스토리지 우회:** 서버에 임시 이미지 파일을 생성하거나 업로드 경로를 관리할 필요가 없어, 스테이트리스(Stateless) API 환경에서의 처리 효율성을 극대화한다 [1].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **동적 페이로드 수정 패턴:** 템플릿 JSON 파일을 로드한 후, 특정 노드 ID(예: #37)의 `inputs` 딕셔너리에 접근하여 실시간으로 인코딩된 문자열을 주입하는 방식을 취한다 [2, 3].
|
||||
- **Python 기반 인코딩 파이프라인:** `open(file, "rb")` -> `base64.b64encode()` -> `.decode("utf-8")` 과정을 거쳐 JSON 규격에 맞는 문자열을 생성한다 [2].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로우를 API로 호출할 때, 특히 이미지-투-이미지(Img2Img)나 컨트롤넷(ControlNet)과 같이 입력 이미지가 필요한 경우 Base64 인코딩이 광범위하게 활용된다 [1].
|
||||
|
||||
1. **API 전송 메커니즘:** 개발자는 이미지를 문자열로 인코딩한 뒤, API 포맷 JSON(workflow_api.json)의 관련 노드 입력값에 이를 할당한다. 이는 서버 사이드에서 이미지 파일을 따로 찾을 필요가 없게 만들어준다 [1].
|
||||
2. **구현 방법:** Python 환경에서는 내장 `base64` 라이브러리를 사용하여 이미지 파일의 바이너리를 읽고 이를 UTF-8 문자열로 변환한다. 이후 워크플로우 JSON 객체를 딕셔너리로 다루어 해당 노드 ID의 `base64_data` 필드 값을 교체한다 [2].
|
||||
3. **효율성 및 용도:** 배너 광고 자동 생성 시스템이나 스타일 전송(Style Transfer) 등 대량의 이미지를 동적으로 처리해야 하는 운영 환경에서, 파일 시스템 입출력(I/O) 오버헤드를 줄이기 위해 권장된다 [1, 4].
|
||||
4. **제약 사항:** 소스에 따르면 워크플로우의 전체 크기가 1MB를 초과할 경우 보안 및 성능상의 이유로 제한될 수 있으므로, 고해상도 이미지 임베딩 시 페이로드 크기 관리가 필요하다 [5, 6].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **데이터 관리의 이중성:** 이미지 임베딩은 별도 저장소가 필요 없어 편리하지만, JSON 파일 자체의 크기를 비대하게 만들어 네트워크 전송 지연을 초래할 수 있다는 점이 간접적으로 시사된다 [5, 7].
|
||||
- **전용 노드 필요성:** 표준 `Load Image` 노드는 서버 내 로컬 경로를 참조하므로, Base64 데이터를 처리하기 위해서는 반드시 `Load Image (Base64)`와 같은 커스텀 노드가 워크플로우에 포함되어 있어야 한다 [1, 2].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Python API 연동 스크립트:** 소스 [2]에서 `image_base64(filename)` 함수를 통해 이미지를 인코딩하고, `prompt[str(load_image_node_id)]["inputs"]["base64_data"] = image` 형태로 데이터를 주입하는 실무 코드가 확인되었다.
|
||||
- **배너 자동 생성 워크플로우:** 이미지 데이터를 동적으로 교체하여 배너 광고를 생성하는 프로젝트에서 실제 적용 사례로 언급되었다 [4].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (제시된 Python 코드를 통해 실제 구현 방법이 구체적으로 명시됨)
|
||||
- **출처 신뢰도:** B (공식 가이드 및 전문 기술 블로그를 통한 검증)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
id: comfy-nodekit
|
||||
title: "Comfy Nodekit"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["Comprehensive Architectures for ComfyUI Workflow JSON Generation and Serialization"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Comfy Nodekit]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Comfy Nodekit은 수동적인 딕셔너리 조작 대신 타입 안전성이 보장된 **Python 우선 방식(Python-first approach)**을 통해 ComfyUI 워크플로를 프로그래밍적으로 구축하고 직렬화하는 라이브러리이다 [1].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **타입 안전한 워크플로 구축:** 원시 JSON 딕셔너리를 직접 수정하는 대신, 정적 타입을 지원하는 Python 환경에서 워크플로를 설계하여 오류를 최소화한다 [1].
|
||||
- **노드 팩토리(Node Factories):** 서버에 설치된 커스텀 노드와 자동으로 동기화되는 노드 팩토리를 제공하여 사용 가능한 노드를 정확하게 반영한다 [1].
|
||||
- **복잡성 관리:** 수백 개의 노드로 구성된 복잡한 그래프를 다룰 때 발생할 수 있는 참조 오류와 구조적 결함을 줄이는 데 최적화되어 있다 [1].
|
||||
- **프로그래밍적 직렬화:** Python 코드를 통해 정의된 노드 관계를 ComfyUI가 실행 가능한 JSON 포맷으로 변환하는 기능을 수행한다 [1, 2].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **추상화 패턴:** 노드의 고유 ID(numeric ID)를 직접 지정하는 파편화된 방식에서 벗어나, 프로그래밍 언어의 객체와 함수를 통해 논리적 구조를 정의하는 추상화 계층을 형성한다 [1, 3].
|
||||
- **서버-클라이언트 동기화:** 로컬의 개발 도구가 서버의 실제 노드 레지스트리 상태를 실시간 또는 주기적으로 반영하여 호환성을 보장하는 설계 패턴을 따른다 [1].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
Comfy Nodekit은 ComfyUI가 단순한 시각적 도구를 넘어 **운영 환경(Production environments)**으로 확장됨에 따라 발생하는 프로그래밍적 요구를 충족하기 위해 설계되었다 [1, 3]. 기존의 수동 JSON 편집 방식은 노드 ID가 변경되거나 워크플로가 복잡해질 때 매우 취약해지는 단점이 있다 [1].
|
||||
|
||||
이 라이브러리는 다음과 같은 기술적 특징을 가진다:
|
||||
- **딕셔너리 조작의 대체:** 개발자가 `json` 라이브러리를 사용하여 중첩된 딕셔너리 구조를 일일이 탐색하고 수정할 필요가 없도록 만든다 [1, 3].
|
||||
- **자동 동기화:** 사용자의 ComfyUI 서버에 설치된 커스텀 노드들을 인식하고 이에 대응하는 Python 인터페이스를 자동으로 생성하여 개발 효율성을 높인다 [1].
|
||||
- **대규모 그래프 지원:** 수백 개의 연결 노드가 존재하는 대규모 프로젝트에서도 타입 체크를 통해 연결 오류를 사전에 방지할 수 있는 'Python-first' 워크플로 빌드 환경을 제공한다 [1].
|
||||
|
||||
이는 "Comfy API Simplified"가 노드 제목(Title)을 기준으로 파라미터를 설정하는 방식이나, "ComfyUI-to-Python-Extension"이 기존 JSON을 Python 스크립트로 변환하는 방식과는 차별화된, **코드 기반의 신규 생성 및 관리**에 초점을 맞춘 도구이다 [1].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **접근 방식의 차이:** 일반적인 사용자가 GUI를 통해 JSON을 내보내는 방식과 달리, 개발자가 처음부터 코드로 워크플로를 작성하는 방식을 제안하며, 이는 시각적 프로그래밍과 텍스트 기반 프로그래밍 사이의 브릿지 역할을 수행한다 [1, 4].
|
||||
- **최신성:** LLM을 이용한 자연어 기반 JSON 생성 방식이 등장하는 등 워크플로 생성 기술이 진화하는 과정에서, Nodekit은 코드의 엄격함과 안전성을 강조하는 전문 개발자용 도구로서 위치한다 [1, 5].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **운영 환경의 워크플로 생성:** "Comprehensive Architectures for ComfyUI Workflow JSON Generation and Serialization" 문서에서 프로그래밍적 워크플로 생성 및 수정을 위한 주요 래퍼 라이브러리 중 하나로 인용되었다 [1, 2].
|
||||
- **Hacker News 사례:** "Show HN: Comfy Nodekit – build/serialize ComfyUI workflows in Python"이라는 제목으로 공개되어, Python 환경 내에서 ComfyUI 워크플로를 구축하고 직렬화하는 실제 구현 사례로 제시되었다 [2].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: comfygpt
|
||||
title: "ComfyGPT"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["ComfyUI-WorkflowGenerator"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI-WorkflowGenerator", "Workflow Generator Pipeline node", "UpdateNodeCatalog", "ComfyUI/models/LLM/"]
|
||||
github_commit: "82df278"
|
||||
---
|
||||
|
||||
# [[ComfyGPT]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
자연어 설명을 다단계 LLM 에이전트 파이프라인을 통해 실행 가능한 ComfyUI 노드 그래프(JSON)로 자동 변환하는 자기 최적화 시스템 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **3단계 생성 파이프라인 (Three-stage Pipeline):** 사용자의 의도를 논리적 합성(Generator), 의미론적 검증(Validator), 그래프 컴파일(Builder) 과정으로 분리하여 처리하는 아키텍처 [2, 3].
|
||||
- **의미론적 노드 매핑 (Semantic Node Mapping):** 훈련 데이터에 없는 최신 커스텀 노드를 인식하기 위해 로컬 설치된 노드 레지스트리 및 의미론적 임베딩을 활용하여 노드 이름을 수정하는 메커니즘 [2, 4].
|
||||
- **특화 LLM 통합 (Specialized LLM Integration):** ComfyUI의 내부 노드 레지스트리 및 스키마 사양에 맞춰 미세 조정(Fine-tuned)된 모델(Qwen2.5-14B 등)을 핵심 엔진으로 사용 [4, 5].
|
||||
- **노드 카탈로그 자동화 (Node Cataloging):** 로컬 환경의 기본 노드 및 커스텀 노드를 스캔하여 LLM이 참조할 수 있는 데이터베이스를 구축하는 프로세스 [6, 7].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **논리-물리 분리 패턴:** 자연어 의도를 먼저 논리적인 그래프 구조로 합성한 뒤, 실제 로컬 환경의 가용 노드와 대조하여 실행 가능한 물리적 JSON으로 변환하는 '중계 컴파일' 패턴 [2, 8].
|
||||
- **검증 기반 보정 패턴:** LLM이 생성한 노드 이름이 실제 환경과 다를 경우, 의미론적 유사도 검색을 통해 유효한 노드 이름으로 교정하는 가디언(Guardian) 패턴 [9, 10].
|
||||
- **계층적 에이전트 협업:** 단일 노드가 아닌 Generator, Validator, Builder라는 독립적인 역할을 가진 에이전트들이 순차적으로 결과를 전달하며 최종 워크플로우를 완성하는 다단계 협업 구조 [2, 9].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyGPT는 "ComfyGPT: A Self-Optimizing Multi-Agent System for Comprehensive ComfyUI Workflow Generation" 연구를 기반으로 하며, 사용자의 자연어 지시(예: "SDXL을 사용한 텍스트-투-이미지 워크플로우 생성")와 실제 실행 가능한 노드 그래프 사이의 간극을 좁히는 것을 목적으로 한다 [1, 2].
|
||||
|
||||
**1. 주요 파이프라인 단계 [2, 3, 8]:**
|
||||
- **생성기 (Generator):** 사용자의 자연어 프롬프트를 해석하여 논리적 그래프 구조(JSON)를 생성한다. Qwen2.5-14B와 같이 워크플로우 데이터에 특화된 모델이 사용된다.
|
||||
- **검증기 (NodeValidator):** 생성된 노드 이름이 로컬 ComfyUI 환경에 설치된 노드와 일치하는지 확인한다. 불일치 시 의미론적 검색(MiniLM 모델 활용) 또는 LLM 정제 모드를 통해 이름을 교정한다.
|
||||
- **빌더 (WorkflowBuilder):** 검증된 논리 구조를 ComfyUI 실행 엔진이 즉시 인식할 수 있는 최종 API 형식 또는 프론트엔드 형식의 JSON 파일로 컴파일한다.
|
||||
|
||||
**2. 활용 모델 아키텍처 [4, 11]:**
|
||||
- **WorkflowGenerator:** Qwen2.5-14B 기반 미세 조정 모델로, 128K 컨텍스트 윈도우를 지원하며 GGUF 형식으로 양자화되어 효율적인 추론이 가능하다.
|
||||
- **Embedding Model:** `sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2`를 사용하여 노드 간의 의미론적 유사도를 계산한다.
|
||||
- **NodeValidator:** Qwen2.5-7B-Instruct 모델을 사용하여 추가적인 LLM 정제를 수행할 수 있다.
|
||||
|
||||
**3. 로컬 환경 동기화:**
|
||||
시스템의 신뢰도를 높이기 위해 `UpdateNodeCatalog` 노드를 통해 현재 설치된 모든 커스텀 노드를 스캔하고 카탈로그화해야 한다. 이는 LLM이 훈련 컷오프 이후에 출시된 새로운 노드를 인식하지 못하는 한계를 보완한다 [6, 7].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **정적 모델의 한계:** 미세 조정된 모델은 훈련 시점 이후에 출시된 노드에 대해 환각(Hallucination)을 일으킬 수 있다. 소스에서는 이를 해결하기 위해 향후 RAG(검색 증강 생성) 아키텍처로의 전환이 필요함을 시사한다 [12, 13].
|
||||
- **I/O 타입 인식 부재:** 현재 시스템은 노드 이름의 의미론적 일치에는 강점이 있으나, 노드 간 데이터 타입(Float, Latent, Image 등)의 엄격한 스키마 호환성을 검증하는 기능은 아직 미래 과제로 남아있다 [13].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI-WorkflowGenerator:** DanielPFlorian이 개발한 GitHub 저장소(`DanielPFlorian/ComfyUI-WorkflowGenerator`)에 ComfyGPT 아키텍처가 네이티브 노드 세트로 구현되어 있다 [1, 14].
|
||||
- **Workflow Generator Pipeline 노드:** Generator, Validator, Builder 단계를 단일 실행으로 통합한 원클릭 솔루션 노드로 구현되었다 [3, 6].
|
||||
- **모델 경로 규격:** GGUF 모델 및 토크나이저를 `ComfyUI/models/LLM/` 경로에 배치하여 관리하는 방식이 적용되었다 [6].
|
||||
- **GitHub 커밋:** 커밋 해시 `82df278`에서 드롭다운 모델 중복 수정 등의 유지보수 기록이 발견된다 [14].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (ComfyUI-WorkflowGenerator 프로젝트를 통해 실제 노드 형태로 구현됨)
|
||||
- **출처 신뢰도:** B (GitHub 기술 문서 및 연구 기반 구현체 소스 코드 설명)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
id: comfyui-api-integration
|
||||
title: "ComfyUI API Integration"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfyui-workflow-to-api-converter-endpoint/README.md", "pydn/ComfyUI-to-Python-Extension", "deimos-deimos/comfy_api_simplified/examples", "Mystic/pipeline.yaml", "Mystic/new_pipeline.py", "DanielPFlorian/ComfyUI-WorkflowGenerator"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[ComfyUI API Integration]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI API Integration은 시각적 노드 그래프를 실행 최적화된 **API JSON(Backend Format)**으로 직렬화하여, 외부 애플리케이션 및 서버리스 환경에서 생성 AI 워크플로우를 프로그래밍 방식으로 자동화하고 확장하는 핵심 매개체이다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **워크플로우 포맷의 이분화 (Bifurcation):** 사용자의 시각적 편집을 위한 'Frontend Format(workflow.json)'과 서버 실행을 위해 UI 메타데이터를 제거한 'API Format(workflow_api.json)'으로 구분된다 [2, 4-6].
|
||||
- **API JSON 직렬화:** 노드 위치, 크기, 그룹 등 시각적 정보를 배제하고 노드 클래스(class_type), 입력 매개변수(inputs), 노드 간 연결 관계만을 포함하는 압축된 실행 그래프이다 [2, 6, 7].
|
||||
- **개발자 모드 (Dev Mode):** 표준 UI에서는 숨겨져 있으며, 설정에서 활성화해야만 API 전용 JSON을 내보낼 수 있는 기능이 활성화된다 [8-12].
|
||||
- **엔드포인트 연동:** 생성된 API JSON은 ComfyUI 서버의 `/prompt` 엔드포인트로 전송되어 실제 이미지나 미디어 생성 명령으로 변환된다 [2, 4, 12, 13].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **개발자 모드 활성화 패턴:** `Settings` 아이콘 클릭 → `Enable Dev mode Options` 체크 → 메뉴의 `Save (API Format)` 버튼 사용 [8-11, 14].
|
||||
- **메타데이터 추출 패턴:** PNG/WebP 이미지의 `tEXt` 또는 `zTXt` 청크에 포함된 JSON 데이터를 `exiftool`이나 전용 추출 도구를 통해 복구하여 재사용하는 방식 [15-18].
|
||||
- **동적 템플릿 패턴:** 기본 JSON 파일을 로드한 후 Python 딕셔너리 조작을 통해 특정 노드 ID의 `seed`, `prompt`, `image` 등의 값을 실시간으로 변경하여 큐에 삽입하는 전략 [13, 19, 20].
|
||||
- **고유 식별자(ID) 타겟팅:** 각 노드에 부여된 숫자형 문자열 키(예: "37")를 사용하여 특정 노드의 입력 필드에 접근하는 패턴 [5, 20].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로우 JSON은 생성 AI 프로세스를 **유향 비순환 그래프(DAG)**로 정의하며, 이를 직렬화함으로써 이식성과 자동화를 실현한다 [1].
|
||||
|
||||
### 1. 워크플로우 JSON의 주요 유형 및 구조
|
||||
- **Frontend JSON (workflow.json):** Litegraph 표준을 따르며 노드 좌표, 그룹화, 색상 등 캔버스 레이아웃 정보를 포함한다 [2, 5, 21].
|
||||
- **API JSON (workflow_api.json):** 백엔드 엔진이 프롬프트를 실행하는 데 필요한 논리적 연결만 남긴 효율적인 그래프이다 [2, 4, 6]. 링크는 별도 객체가 아닌 노드 입력 내에 직접 임베딩된다 [2, 22].
|
||||
- **구조적 제약:** JSON v1.0 스키마에 따라 각 노드는 고유 `id`, `type`, `inputs`, `outputs`를 가져야 하며, 실행 엔진은 출력 노드에서 역방향으로 그래프를 탐색하여 필요한 의존성만 실행하는 '실행 모델 반전' 방식을 사용한다 [23-25].
|
||||
|
||||
### 2. JSON 생성 및 획득 방법
|
||||
- **수동 내보내기:** 웹 인터페이스에서 개발자 모드를 활성화한 후 전용 저장 버튼을 사용한다 [8, 9, 11].
|
||||
- **알고리즘 추출:** ComfyUI가 생성한 PNG 파일에는 워크플로우가 메타데이터로 자동 저장되므로, 이를 드래그 앤 드롭하거나 `exiftool` 명령어를 사용하여 추출할 수 있다 [15, 17, 26-28].
|
||||
- **자연어 기반 생성:** LLM(예: Qwen2.5-14B)을 사용하여 자연어 설명을 논리적 그래프 구조로 합성하고 로컬 노드 카탈로그와 대조하여 유효한 JSON으로 변환하는 방식이 도입되었다 [29-32].
|
||||
|
||||
### 3. 프로그래밍 방식의 통합 및 변환
|
||||
- **Python 직접 조작:** Python의 `json` 라이브러리를 사용하여 노드 ID를 기반으로 텍스트나 이미지 데이터를 업데이트한다 [19, 20]. 이미지는 주로 Base64로 인코딩되어 JSON 내에 직접 포함된다 [13, 33].
|
||||
- **추상화 래퍼:** `comfy_api_simplified`와 같은 라이브러리는 숫자 ID 대신 노드 제목으로 매개변수를 설정하게 하여 유지보수성을 높인다 [34, 35].
|
||||
- **스크립트 변환:** `ComfyUI-to-Python-Extension`은 JSON 워크플로우를 실행 가능한 독립형 `.py` 스크립트로 변환하여 헤드리스 환경에서 실행할 수 있게 한다 [34, 36, 37].
|
||||
|
||||
### 4. API 기반 자동화 및 배포
|
||||
- **서버리스 플랫폼:** Replicate나 Mystic 같은 서비스는 API JSON 블롭을 입력받아 클라우드 GPU에서 실행하고 결과를 반환하는 엔드포인트를 제공한다 [9, 38-40].
|
||||
- **의존성 관리:** JSON 로드 시 누락된 커스텀 노드는 '빨간 박스'로 표시되며, `ComfyUI-Manager`를 통해 자동으로 식별 및 설치할 수 있다 [41-43].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **포맷 호환성 문제:** 표준 저장 방식으로 생성된 JSON은 API 엔드포인트에서 오류를 발생시키므로 반드시 API 포맷으로의 변환이 필요하다 [12].
|
||||
- **메타데이터 손실:** 소셜 미디어나 이미지 편집기(GIMP 등)를 통해 이미지를 전송 또는 수정할 경우 워크플로우 메타데이터가 삭제될 수 있다는 경고가 반복적으로 확인된다 [16, 26, 44, 45].
|
||||
- **노드 ID 변동성:** 워크플로우를 UI에서 수정하면 노드 ID가 변경될 수 있어, 하드코딩된 Python 스크립트가 파손될 위험이 존재한다 [19, 34]. 이에 대한 해결책으로 노드 제목 기반 매핑이 권장된다 [34, 35].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **서버 측 변환 엔드포인트:** `comfyui-workflow-to-api-converter-endpoint`는 클라이언트 측의 자바스크립트 로직을 파이썬으로 변환하여 서버에서 일반 JSON을 API JSON으로 실시간 변환하는 `/workflow/convert` 엔드포인트를 구현했다 [12, 46, 47].
|
||||
- **독립 실행형 스크립트 변환:** `pydn/ComfyUI-to-Python-Extension` 프로젝트는 `Save As Script` 기능을 통해 워크플로우를 `.py` 파일로 다운로드하여 자동화된 실행 환경을 구축했다 [37, 48].
|
||||
- **매개변수 스케줄링:** `comfy_api_simplified` 라이브러리는 수백 개의 이미지를 야간에 생성하기 위해 여러 프롬프트와 매개변수를 반복 실행하는 예제 코드를 제공한다 [35, 49].
|
||||
- **배너 광고 자동 생성:** ComfyUI API를 Python과 연동하여 입력 이미지와 텍스트를 변경하며 대량의 광고 소재를 생성하는 실제 사례가 보고되었다 [50].
|
||||
- **Mystic 파이프라인 배포:** `pipeline.yaml`과 `new_pipeline.py`를 사용하여 텍스트-비디오 워크플로우를 서버리스 엔드포인트로 배포하는 구조가 상세히 기술되었다 [51-53].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
id: comfyui-custom-scripts
|
||||
title: "ComfyUI Custom Scripts"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI root directory"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[ComfyUI Custom Scripts]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI의 기본 저장 및 로드 기능을 확장하여 워크플로 관리의 효율성을 극대화하고, 노드 그래프를 시각적 파일로 변환하여 공유 편의성을 높이는 통합 UI 강화 도구 세트 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **워크플로 관리 최적화:** 저장(Save) 및 불러오기(Load) 버튼 아래에 드롭다운 메뉴를 생성하여 특정 루트 디렉토리의 워크플로에 즉시 액세스할 수 있도록 지원함 [1, 3].
|
||||
- **시각적 내보내기 (Visual Export):** 워크플로를 표준 JSON 형식 외에도 PNG 또는 SVG 파일로 내보낼 수 있어 소셜 미디어나 문서화에 용이한 시각적 자료를 생성함 [2, 3].
|
||||
- **UI 기능성 강화:** 노드 자동 정렬, 그리드 스냅(Snap to grid), 노드 잠금 등 캔버스 작업의 정밀도와 속도를 높이는 편의 기능을 제공함 [2].
|
||||
- **입력 지능화:** 프롬프트 작성 시 임베딩(Embedding) 리스트를 활용한 자동 완성 기능을 제공하고, 위젯 값 입력 시 수학적 표현식을 사용할 수 있게 함 [2].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **네이티브 UI 확장 패턴:** 기존 ComfyUI 제어 패널의 버튼 구조를 변경하지 않고 하단에 드롭다운 레이어를 추가하여 사용자 경험의 연속성을 유지하면서 기능을 확장함 [1].
|
||||
- **워크플로 시각화 전략:** 복잡한 노드 연결망을 이미지 파일(PNG/SVG)로 직렬화하여 JSON 파일 없이도 워크플로의 전체 구조를 한눈에 파악할 수 있도록 함 [3].
|
||||
- **정보 밀도 향상 패턴:** 체크포인트, LoRA, 임베딩에 대한 추가 정보를 화면에 표시하여 사용자가 모델의 세부 사항을 즉각적으로 인지하도록 설계됨 [2].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI Custom Scripts는 일반적인 워크플로 제작 방식을 넘어 파워 유저를 위한 정교한 제어 기능을 제공하는 커스텀 노드 패키지이다 [1].
|
||||
|
||||
**1. 워크플로 저장 및 관리의 고도화**
|
||||
이 스크립트는 ComfyUI 패널의 저장 및 로드 버튼 아래에 원활한 드롭다운 메뉴를 생성한다 [1]. 이 메뉴는 ComfyUI 내의 특정 루트 디렉토리를 참조하며, 사용자가 복잡한 파일 탐색기 과정 없이 사전에 정의된 경로에서 워크플로를 빠르게 교체하거나 저장할 수 있게 한다 [1, 3]. 이는 업데이트로 인해 워크플로가 덮어씌워지는 것을 방지하는 안전한 백업 환경을 구축하는 데 기여한다 [3].
|
||||
|
||||
**2. 시각적 워크플로 공유 기술**
|
||||
기존의 JSON 기반 공유 방식은 텍스트 데이터에 의존하지만, Custom Scripts는 워크플로 자체를 PNG 또는 SVG 형식으로 내보내는 기능을 제공한다 [2, 3]. 이는 소셜 미디어나 Discord와 같은 플랫폼에서 워크플로의 시각적 형태를 즉시 공유할 수 있게 하며, 동시에 시각적 문서화 도구로 활용된다 [3]. 특히 PNG 파일로 저장할 경우 워크플로 데이터를 포함할 수 있는 옵션이 포함된다 [2].
|
||||
|
||||
**3. 캔버스 작업 편의성 및 데이터 처리**
|
||||
- **노드 배치:** 노드 자동 정렬 기능과 그리드 스냅 기능을 통해 엉킨 노드 그래프를 정돈하고 구조화된 레이아웃을 유지할 수 있다 [2].
|
||||
- **데이터 활용:** 프롬프트 입력창에서 자동 완성을 지원하여 임베딩 선택 시 오류를 줄이고, 레이턴트(Latent) 생성 등 위젯 값 입력 시 수학적 수식을 직접 사용하여 동적인 값 계산이 가능하다 [2].
|
||||
- **상태 제어:** 노드 잠금(Lock) 기능을 통해 실수로 배치를 변경하는 것을 방지하며, 이미지 피드를 UI 상에서 직접 확인할 수 있는 향상된 뷰어를 제공한다 [2].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **정보의 상호 보완:** 소스 데이터는 이를 "UI 향상 도구"이자 "인기 있는 커스텀 노드"로 정의하고 있다 [2, 4].
|
||||
- **JSON과의 관계:** 표준 저장 방식인 JSON 파일과 대조적으로, 이 스크립트는 PNG/SVG와 같은 시각적 내보내기를 강조하지만 이것이 JSON 형식을 완전히 대체하는 것이 아니라 보완적인 공유 수단으로 작동함을 시사한다 [3].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI 루트 디렉토리 관리:** 워크플로를 저장하고 로드할 때 참조되는 기본 경로 설정 로직에 적용되어 있다 [1, 3].
|
||||
- **클라우드 플랫폼 지원:** Replicate와 같은 환경에서 인기 있는 커스텀 노드 리스트로 분류되어 기본적으로 지원되거나 권장되는 도구로 포함되어 있다 [4, 5].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
id: dev-mode-options
|
||||
title: "Dev mode Options"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["개발자 모드", "Developer Mode"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["Replicate fofr/any-comfyui-workflow", "Mystic pipeline-ai", "ComfyUI Workflow Converter Endpoint", "ComfyUI-to-Python-Extension"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Dev mode Options]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Dev mode Options는 시각적 편집 중심의 워크플로우를 프로그래밍 방식의 실행이 가능한 최적화된 API 포맷으로 변환 및 추출하기 위해 반드시 거쳐야 하는 ComfyUI의 핵심 설정 관문이다. [1-3]
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **API 포맷 직렬화 (Serialization)**: 프론트엔드의 시각적 메타데이터(노드 위치, 크기 등)를 제거하고 백엔드 엔진이 즉시 실행할 수 있는 평탄화된 실행 그래프(Flattened Execution Graph)를 생성한다. [1, 4]
|
||||
- **기능 잠금 해제 (UI Unlocking)**: 설정 활성화 시 ComfyUI 메뉴에 기존에 보이지 않던 'Save (API Format)' 버튼을 추가하여 사용자가 직접 API용 JSON을 내보낼 수 있게 한다. [5-7]
|
||||
- **데이터 흐름 최적화**: 링크를 별도의 객체가 아닌 노드 입력 내의 직접적인 참조(Origin node ID 및 Slot index)로 포함시켜 데이터 처리 효율을 극대화한다. [1, 8]
|
||||
- **프로그래밍 통합의 필수 조건**: 외부 애플리케이션, 원격 서버, 또는 헤드리스(Headless) 환경에서 워크플로우를 실행하기 위한 전제 조건이다. [2, 9]
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **활성화 메커니즘**: `톱니바퀴 아이콘(Settings)` -> `Enable Dev mode Options 체크박스 활성화` -> `메뉴/패널에 새로운 내보내기 옵션 노출` 순의 정형화된 패턴을 따른다. [2, 3, 7]
|
||||
- **포맷의 이원화 패턴**: 인간의 가독성과 시각적 편집을 위한 `Frontend JSON(workflow.json)`과 기계적 실행만을 목적으로 하는 `Backend/API JSON(workflow_api.json)`으로 워크플로우 포맷을 분리하여 관리한다. [1, 10]
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **기능적 역할**: 기본 ComfyUI 저장 방식은 Litegraph 표준을 따르며 캔버스 레이아웃 정보를 포함하지만, 이는 `/prompt` 엔드포인트에 직접 전달할 경우 오류를 발생시킨다. [11] Dev mode는 백엔드가 요구하는 특정 노드 클래스와 매개변수 리스트로 구성된 간결한 JSON 페이로드를 생성할 수 있게 한다. [2, 5]
|
||||
- **접근 경로**: ComfyUI 설정 메뉴(Settings) 내에서 'Enable Dev mode Options'를 선택하면 활성화된다. [3, 7, 12] 활성화 후에는 메뉴의 'Export' 섹션 또는 제어 패널 상단에 'Save (API Format)'라는 명칭의 새로운 버튼이 등장한다. [5, 7]
|
||||
- **API JSON의 특징**: 시각적 메타데이터가 제거되어 파일 용량이 작고 효율적이다. [1, 10] 노드 간의 링크 정보가 노드의 `inputs` 필드 내에 직접 배열 형태(예: `[node_id, slot_index]`)로 포함되는 것이 기술적 차별점이다. [8]
|
||||
- **주요 활용 사례**:
|
||||
- **Replicate/Mystic**: 서버리스 클라우드 환경에서 워크플로우를 API 엔드포인트로 배포할 때 필수적으로 요구된다. [3, 6, 7, 13]
|
||||
- **Python 스크립트 실행**: 워크플로우를 독립적인 파이썬 스크립트로 변환하거나 API를 통해 동적으로 매개변수를 수정하여 실행할 때 기반 데이터로 사용된다. [9, 14, 15]
|
||||
- **자동화 도구**: LLM을 이용한 워크플로우 자동 생성이나 대량의 이미지 처리 파이프라인 구축 시 'Dev mode'를 통해 추출된 스키마가 참조 모델이 된다. [16, 17]
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **가역성 문제**: 일반적인 'Save'로 생성된 JSON은 ComfyUI에 드래그 앤 드롭 시 레이아웃이 복구되지만, Dev mode를 통해 추출된 'API Format' JSON은 레이아웃 정보가 없으므로 다시 UI로 불러왔을 때 시각적 구조가 파괴된 '골격(Skeleton)' 상태로 나타난다. [18]
|
||||
- **도구별 요구사항**: 대부분의 튜토리얼은 API 실행을 위해 Dev mode 활성화를 권장하지만, 일부 커스텀 확장 기능(예: ComfyUI-to-Python-Extension)은 일반 저장 파일에서도 스크립트 변환을 지원하는 별도의 기능을 UI에 추가하기도 한다. [19, 20]
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Replicate 배포 프로세스**: `settings` -> `Enable Dev mode Options` -> `Save (API format)` 순서로 JSON을 획득하여 `fofr/any-comfyui-workflow` 모델의 `workflow_json` 입력값으로 사용함. [3, 6]
|
||||
- **Mystic 서버리스 통합**: 워크플로우를 Mystic 파이프라인으로 배포하기 전, GUI의 설정 메뉴에서 Dev mode를 켜고 `.json` 파일을 API 포맷으로 내보내는 과정이 필수 단계로 포함됨. [7]
|
||||
- **SethRobinson의 Workflow Converter**: API 포맷 변환 시 클라이언트 측 자바스크립트 로직을 서버 측 파이썬으로 구현하여, 개발자가 매번 수동으로 Dev mode를 켜고 API 포맷을 저장해야 하는 번거로움을 해결함. [11]
|
||||
- **ComfyUI-to-Python-Extension**: CLI 사용 시 API 포맷 워크플로우를 입력값으로 받아 실행 가능한 파이썬 코드를 생성함. [21]
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 발견으로 검증됨)
|
||||
- **출처 신뢰도:** B (공식 문서 및 주요 개발자 도구의 가이드라인에 근거함)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
id: draft-07-specification
|
||||
title: "Draft-07 Specification"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["JSON Schema v1.0"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI Workflow v1.0", "WorkflowExecutor", "comfyui-workflow-to-api-converter-endpoint"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Draft-07 Specification]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Draft-07 Specification은 ComfyUI Workflow JSON v1.0의 구조적 무결성을 정의하는 공식 표준으로, 노드 속성과 링크 연결성을 규제하여 워크플로의 이식성과 실행 가능성을 보장한다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **JSON Schema v1.0:** Draft-07 사양을 따르는 최신 ComfyUI 워크플로 표준으로, 실행 엔진이 인식하기 위한 기술적 제약 조건을 정의한다 [1, 2].
|
||||
- **Mandatory Node Properties:** 노드 객체가 포함해야 하는 필수 속성(id, type, pos, size, order, mode)을 통해 그래프의 구조를 명시한다 [1].
|
||||
- **Slot Connectivity Indexing:** 링크 및 슬롯의 원본/대상 ID와 인덱스를 지정하여 데이터 흐름의 정확성을 확보한다 [3].
|
||||
- **Serialization Validation:** 워크플로가 직렬화될 때 이 사양을 준수해야만 ComfyUI 백엔드에서 유효한 프롬프트로 처리될 수 있다 [1, 4].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Bifurcation Compliance:** 시각적 메타데이터를 포함하는 Frontend 포맷(`workflow.json`)과 실행 최적화된 Backend 포맷(`workflow_api.json`) 모두가 동일한 Draft-07 기반의 핵심 논리 구조를 공유한다 [5, 6].
|
||||
- **Dependency Inversion Traversal:** 엔진이 출력 노드에서 시작하여 사양에 정의된 링크를 역추적(backward traversal)하여 필요한 노드만 실행하는 구조적 패턴을 보인다 [7].
|
||||
- **Metadata Redundancy:** PNG 파일의 메타데이터 청크(tEXt/zTXt)에 두 가지 포맷을 동시에 저장하여 표준 준수와 사용자 편의성을 동시에 유지한다 [8].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로의 구조적 무결성은 **Draft-07 사양을 따르는 공식 JSON Schema v1.0**에 의해 검증된다 [1, 2]. 이 사양은 워크플로가 단순한 시각적 도표를 넘어 실행 가능한 프로그램으로서 작동하기 위한 기술적 제약 사항을 명시한다.
|
||||
|
||||
**1. 노드 객체의 필수 속성 규격 [1]:**
|
||||
- **id:** 그래프 탐색을 위한 고유 식별자 (Integer 또는 String).
|
||||
- **type:** 노드 레지스트리의 클래스 이름과 매핑되는 필수 문자열.
|
||||
- **pos / size:** UI 렌더링을 위한 캔버스 좌표 및 크기 정보.
|
||||
- **order:** 엔진이 참조하는 권장 실행 또는 렌더링 순서.
|
||||
- **mode:** 노드의 활성화, 바이패스(Bypass) 등의 운영 상태.
|
||||
|
||||
**2. 링크 및 슬롯 연결 사양 [3]:**
|
||||
연결성은 노드 내부의 `inputs` 및 `outputs` 배열을 통해 정의된다. `inputs` 속성의 `link` 프로퍼티는 들어오는 와이어의 고유 ID를 식별하며, `outputs`의 `links` 배열은 하나의 출력이 여러 노드로 전달될 수 있음을 나타낸다. 특히 VAE Loader와 같이 다중 출력 슬롯을 가진 노드의 경우, **정확한 슬롯 인덱싱**이 사양 준수의 핵심이다 [3].
|
||||
|
||||
**3. 유효성 검사 및 실행 [4]:**
|
||||
워크플로 JSON이 생성되면 ComfyUI의 `validate_prompt` 함수는 이 사양을 기준으로 데이터 구조를 검증한다. 검증을 통과한 JSON은 `DynamicPrompt`로 구성되어 `ExecutionList`로 변환되며, 이 과정에서 사양에 어긋나는 연결이나 속성이 발견되면 실행이 거부된다 [4].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **버전 업데이트:** 이전의 0.4 버전 사양에서 최신 1.0(Draft-07 기반)으로 표준이 업데이트되었으며, 이는 공식 문서에서 권장되는 최신 규격이다 [2, 9].
|
||||
- **포맷 간 차이:** API 포맷은 효율성을 위해 UI 관련 메타데이터를 삭제하지만, 핵심적인 노드 클래스 매핑과 입력 구조는 여전히 Draft-07의 논리적 범주 내에 있다 [5, 6].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI Workflow v1.0:** Draft-07 사양을 공식적으로 채택한 최신 워크플로 직렬화 규격 [1, 2].
|
||||
- **WorkflowExecutor.execute():** 독립 실행 스크립트에서 `validate_prompt`를 호출하여 워크플로 JSON이 사양을 준수하는지 검증하는 로직이 적용됨 [4].
|
||||
- **comfyui-workflow-to-api-converter-endpoint:** 비 API 포맷을 API 포맷으로 변환할 때 ComfyUI의 노드 레지스트리와 사양을 참조하여 유효한 JSON을 생성함 [10, 11].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
id: executing-comfyui-workflows-as-standalone-scripts
|
||||
title: "Executing ComfyUI Workflows as Standalone Scripts"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["pydn/ComfyUI-to-Python-Extension", "WorkflowExecutor", "ExecutionCache", "new_pipeline.py", "bc85382"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Executing ComfyUI Workflows as Standalone Scripts]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI 워크플로우를 시각적 인터페이스 없이 실행 가능한 독립형 스크립트로 변환하는 프로세스는 **API 형식의 JSON 직렬화와 Python 환경의 실행 오케스트레이션**을 통해 고도의 자동화와 헤드리스(Headless) 환경 배포를 가능하게 한다 [1-4].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **API JSON Format (Backend JSON):** 시각적 메타데이터를 제거하고 노드 입력과 연결 정보만을 남긴 실행 최적화 그래프 파일로, 독립형 스크립트 실행의 기초가 된다 [2, 5, 6].
|
||||
- **WorkflowExecutor:** 워크플로우 실행 환경을 초기화하고, 노드 유효성 검사(`validate_prompt`) 및 실행 목록(`ExecutionList`) 구축을 담당하는 오케스트레이션 객체이다 [7].
|
||||
- **ExecutionCache:** 노드 출력, UI 데이터 및 객체 인스턴스를 캐싱하여 중복 계산을 줄이고 실행 성능을 최적화하는 통합 관리 클래스이다 [8].
|
||||
- **Headless Processing:** 웹 브라우저나 GUI 없이 서버 백엔드 또는 독립형 스크립트 형태로 워크플로우를 구동하여 실행 오버헤드를 줄이는 방식이다 [4].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Serialization Bifurcation (직렬화 이분화):** 시각적 편집을 위한 Frontend JSON(`workflow.json`)과 자동화 실행을 위한 Backend API JSON(`workflow_api.json`)을 분리하여 관리하는 설계 패턴이 발견된다 [2, 5, 6, 9].
|
||||
- **Execution Model Inversion (실행 모델 역전):** 모든 노드를 실행하는 대신 'Save Image'와 같은 출력 노드에서 역추적하여 필요한 의존성만 식별하고 실행하는 효율적 패턴을 사용한다 [10].
|
||||
- **Python-to-Script Conversion:** `.json` 워크플로우를 `.py` 코드로 직접 변환하여 별도의 JSON 처리 없이 Python 런타임에서 즉시 실행 가능하게 하는 추상화 패턴이 존재한다 [3, 11].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로우를 독립형 스크립트로 실행하기 위해서는 먼저 **'Dev mode'**를 활성화하여 **API 형식의 JSON**을 추출해야 한다 [6, 12, 13]. 표준 Frontend JSON은 노드 위치나 그룹화 등 시각적 정보를 포함하지만, API JSON은 이를 제거하고 노드 간의 링크를 입력 필드 내의 직접 참조(`[origin_id, output_slot]`)로 포함하여 백엔드 엔진이 즉시 해석할 수 있도록 최적화되어 있다 [2, 14, 15].
|
||||
|
||||
독립형 실행의 핵심 구성 요소인 **WorkflowExecutor**는 `DynamicPrompt`를 구성하고 이를 노드 단위의 실행 목록인 `ExecutionList`로 변환한다 [7]. 각 노드는 `_execute_node` 메서드를 통해 순차적으로 실행되며, 이때 `get_input_data`와 `get_output_data` 함수가 사용되어 데이터 흐름을 처리한다 [8, 16]. **ExecutionCache**는 `HierarchicalCache`를 기반으로 구축되어 이전 실행 결과를 보존함으로써 연속적인 실행 시 성능을 비약적으로 향상시킨다 [8].
|
||||
|
||||
더 고도화된 방식으로는 **ComfyUI-to-Python-Extension**을 사용하여 워크플로우 자체를 실행 가능한 `.py` 파일로 변환하는 것이 가능하다 [3, 11]. 이 방식은 생성된 스크립트 내에 노드 실행 로직이 포함되어 있어 별도의 프롬프트 서버 호출 없이도 단독 실행(Single-shot runner)이 가능하며, 메모리 관리 플래그(`--highvram` 등)를 스크립트 인자로 전달받아 제어할 수 있다 [17, 18].
|
||||
|
||||
생산 환경에서는 **Mystic**이나 **Replicate**와 같은 플랫폼을 통해 이러한 스크립트를 서버리스 엔드포인트로 배포할 수 있으며, 이때 Python SDK를 사용하여 워크플로우 JSON 내의 시드(seed)나 프롬프트 값을 프로그래밍 방식으로 수정하여 실행한다 [19-21].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **워크플로우 유연성 대 변환 복잡성:** 일부 연구에서는 `ComfyUI-to-Python-Extension`이 중간 변환 단계를 요구하여 **동적(Dynamic) 워크플로우** 실행에 어려움이 있을 수 있다고 지적하며, 대신 API JSON을 직접 로드하는 방식을 권장하기도 한다 [4].
|
||||
- **JSON 버전 호환성:** ComfyUI는 빈번하게 업데이트되므로 구버전의 JSON 파일이 최신 버전의 실행 엔진에서 정상 작동하지 않을 수 있다는 경고가 명시되어 있다 [22, 23].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **pydn/ComfyUI-to-Python-Extension:** 워크플로우를 독립형 `.py` 스크립트로 자동 번환하는 도구로 구현되었다 [3, 24].
|
||||
- **WorkflowExecutor & ExecutionCache:** SDXL Turbo 워크플로우를 독립형 스크립트로 실행하기 위한 핵심 아키텍처로 제안되었으며 GitHub Gist를 통해 소스 코드가 공유되었다 [7, 8, 25].
|
||||
- **Mystic (new_pipeline.py):** ComfyUI 서버를 시작하고 커스텀 워크플로우를 로드하여 입력 프롬프트를 주입하는 배포용 Python 템플릿 파일이다 [20, 26].
|
||||
- **GitHub Commit (bc85382):** `comfyui-workflow-to-api-converter-endpoint` 프로젝트에서 콤보 위젯의 대소문자 검증 문제를 수정한 커밋 기록이 발견된다 [27].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
id: frontend-format
|
||||
title: "Frontend Format"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["workflow.json", "UI Format"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow.json", "flux_workflow.json"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Frontend Format]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Frontend Format은 ComfyUI 웹 인터페이스의 시각적 상태와 노드 실행 로직을 완벽하게 보존하기 위해 노드 좌표, 크기, 그룹화 등의 풍부한 UI 메타데이터를 포함하는 Litegraph 기반 직렬화 규격이다 [1], [2], [3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **시각적 메타데이터 (Visual Metadata):** 노드의 캔버스 좌표(`pos`), 크기(`size`), 그룹 구조, 노드의 접힘(collapsed) 또는 고정(pinned) 상태 등 사용자 인터페이스 구성을 위한 정보를 포함한다 [1], [2], [4].
|
||||
- **Litegraph 표준 기반:** 웹 기반 그래프 편집기의 시각적 조작과 렌더링을 위해 설계된 Litegraph 형식을 따르며, 이는 인간이 읽고 이해하기 쉬운 구조를 제공한다 [1], [3].
|
||||
- **명시적 연결 객체 (Explicit Links):** 노드 간의 데이터 흐름이 별도의 `links` 배열 내에 정의된 독립적인 연결 객체로 표현되어, 그래프의 시각적 연결성을 관리한다 [2], [5].
|
||||
- **고유 숫자 식별자:** 각 노드는 "1", "2", "3"과 같은 고유한 숫자 기반 문자열 ID를 통해 관리되며, 이는 시각적 위치와 논리적 연결을 매핑하는 기준이 된다 [2], [3].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **GUI 기본 저장 패턴:** ComfyUI 제어판에서 'Save' 버튼을 누르거나 단축키 `Ctrl + S`(Mac은 `Cmd + S`)를 사용할 때 기본적으로 생성되는 포맷이다 [6], [7].
|
||||
- **미디어 메타데이터 내장 패턴:** PNG 또는 WebP 이미지 생성 시, 파일의 `tEXt` 또는 `zTXt` 청크에 Frontend Format JSON이 주입되어 이미지가 자체적인 워크플로우 컨테이너 역할을 하게 된다 [8], [9], [10].
|
||||
- **노드 오브젝트 표준화:** 모든 노드는 `id`, `type`, `pos`, `size`, `widgets_values`, `order`, `mode`라는 필수/선택 속성 세트를 가지는 일관된 객체 구조를 유지한다 [11], [4].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
Frontend Format은 주로 **시각적 편집 및 인간 간의 공유**를 목적으로 사용된다 [2], [7]. 이 포맷은 단순한 실행 로직을 넘어 아티스트가 구성한 작업 환경의 모든 세부 사항을 저장하기 때문에, 파일을 다시 불러왔을 때 노드들이 정확히 같은 위치에 배치되고 설정된 시각적 그룹이 유지된다 [6], [3].
|
||||
|
||||
기술적으로 Frontend JSON은 `nodes`와 `links`라는 두 가지 핵심 배열을 포함한다 [4]. `nodes` 배열의 각 객체는 특정 노드의 클래스 타입과 위젯 값뿐만 아니라 캔버스상의 좌표(`[x, y]`)와 차원(`[width, height]`)을 명시한다 [11], [4]. `links` 배열은 출력 노드 ID, 출력 슬롯, 입력 노드 ID, 입력 슬롯을 포함하는 6개 항목의 배열 또는 객체로 구성되어 노드 간의 물리적 연결을 정의한다 [5].
|
||||
|
||||
이 포맷은 파일 크기가 API Format에 비해 상대적으로 크지만, 모델 가중치(Weights) 파일에 비하면 매우 작아 독립적인 보관과 공유가 용이하다 [12], [2]. 하지만 백엔드 엔진이 직접적으로 해석하기에는 불필요한 UI 정보가 너무 많아, 서버 사이드 실행이나 API 호출 시에는 대개 API Format으로의 변환이 필요하다 [13], [14].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **실행 호환성:** Frontend Format(workflow.json)은 ComfyUI 웹 인터페이스에서는 드래그 앤 드롭으로 즉시 실행되지만, 외부 애플리케이션에서 `/prompt` 엔드포인트를 통해 서버에 직접 전송할 경우 에러가 발생하며 실행되지 않는다 [14].
|
||||
- **데이터 손실 위험:** 이미지에 내장된 워크플로우 메타데이터는 일반적인 이미지 편집기(GIMP 등)로 편집하거나 소셜 미디어 플랫폼에 업로드할 때 압축 및 최적화 과정에서 삭제될 위험이 크다 [15], [9], [16].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **표준 워크플로우 파일:** `workflow.json`이라는 기본 파일명으로 시스템 전반에서 시각적 저장 단위로 사용된다 [1], [7].
|
||||
- **FLUX 예시:** `flux_workflow.json` 파일은 노드 ID, 위치, 위젯 값 및 명시적 링크 구조를 보여주는 Frontend Format의 대표적인 기술 사례로 문서화되어 있다 [7], [17].
|
||||
- **버그 수정 기록:** Git 커밋 `bc85382`에서는 Frontend 포맷에서 API 포맷으로 변환할 때 콤보 위젯의 대소문자 불일치 문제를 해결하기 위해 노드 레지스트리를 대조하는 로직이 적용되었다 [18], [19].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 및 공식 사양을 통해 확인됨)
|
||||
- **출처 신뢰도:** B (공식 문서 및 오픈소스 기술 문서 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
id: frontend-json-(workflow.json)
|
||||
title: "Frontend JSON (workflow.json)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["workflow.json", "UI Format JSON"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["Mystic pipeline root directory", "RunComfy FLUX workflow example (flux_workflow.json)", "ComfyUI Official RFCs repository", "ComfyUI Output folder (metadata embedding)"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Frontend JSON (workflow.json)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI의 시각적 작업 공간 전체(노드 좌표, 그룹, 링크 구조)를 Litegraph 표준에 따라 보존하여 사용자의 편집, 재구성 및 커뮤니티 협업을 가능하게 하는 종합적인 시각적 설계도이다. [1-3]
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Litegraph 표준 기반 시각적 메타데이터**: 노드의 캔버스 좌표(`pos`), 크기(`size`), 색상, 그룹화 구조 및 노드 확장/축소 상태와 같은 UI 전용 정보를 포함한다. [1, 2, 4, 5]
|
||||
- **명시적 링크 배열 (Explicit Link Representation)**: 노드 간의 연결을 별도의 `links` 배열 내 개별 객체로 관리하며, 각 링크는 고유 ID를 통해 원본 노드와 대상 노드의 슬롯을 정의한다. [1, 2, 6, 7]
|
||||
- **인간 중심의 교환 포맷**: 시각적 편집과 공유를 목적으로 설계되었으며, 모델 가중치와 독립적으로 워크플로우 로직을 작고 가독성 있는 텍스트 파일로 아카이브할 수 있게 한다. [6, 8, 9]
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **결과물 내 로직 자가 수용 패턴 (Metadata Embedding)**: 생성된 이미지(PNG/WebP)의 `tEXt` 또는 `zTXt` 청크에 Frontend JSON을 주입하여, 이미지 자체가 해당 이미지를 만든 로직을 운반하는 컨테이너 역할을 수행하게 한다. [3, 10, 11]
|
||||
- **비가역적 정보 손실 패턴 (Frontend to API Transformation)**: Frontend JSON은 실행 최적화된 API JSON으로 변환 가능하지만, 역변환 시 시각적 레이아웃 정보는 복구할 수 없는 비가역적 관계를 가진다. [12, 13]
|
||||
- **의존성 탐지 및 해결 휴리스틱**: 외부 JSON 로드 시 `class_type`을 로컬 레지스트리와 대조하여 누락된 커스텀 노드를 식별하고(Red Nodes), ComfyUI-Manager를 통해 이를 일괄 설치하는 복구 패턴이 존재한다. [14-16]
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
Frontend JSON(주로 `workflow.json`으로 명명됨)은 ComfyUI 웹 인터페이스의 상태를 저장하는 표준 포맷이다. [1, 17] 이 파일은 사용자가 구성한 그래프의 시각적 배치와 모든 매개변수를 캡처하는 포괄적인 청사진 역할을 한다. [8]
|
||||
|
||||
### 1. 기술적 구조 및 속성
|
||||
- **노드 배열 (`nodes`)**: 워크플로우를 구성하는 개별 객체들의 리스트이다. [5]
|
||||
- `id`: 그래프 탐색을 위한 고유 식별자(숫자 문자열)이다. [4, 18]
|
||||
- `type`: 노드 레지스트리의 클래스 이름과 매핑된다. [4, 5]
|
||||
- `pos` & `size`: 캔버스 렌더링을 위한 [x, y] 좌표 및 치수이다. [4, 5]
|
||||
- `widgets_values`: 슬라이더, 텍스트 박스 등 사용자 입력 값을 저장하는 배열이다. [4, 5]
|
||||
- **링크 시스템 (`links`)**: 별도의 최상위 배열에서 관리되며, `origin_id`, `origin_slot`, `target_id`, `target_slot`을 정의하여 데이터 흐름을 명시한다. [7]
|
||||
|
||||
### 2. 생성 및 로드 방법
|
||||
- **수동 내보내기**: 제어판 메뉴의 'Export' 옵션이나 `Ctrl + S` (macOS는 `Cmd + S`) 단축키를 통해 현재 그래프 상태를 JSON으로 다운로드할 수 있다. [5, 19, 20]
|
||||
- **이미지 기반 추출**: ComfyUI에서 생성된 PNG 파일을 캔버스에 드래그 앤 드롭하면 내장된 메타데이터를 분석하여 워크플로우가 즉시 재구성된다. [19, 21-23] `exiftool`과 같은 CLI 도구를 사용하여 바이너리 태그에서 직접 추출할 수도 있다. [24, 25]
|
||||
- **자동 생성**: 최근에는 자연어 설명을 LLM(Qwen2.5 등)이 해석하여 논리적 그래프 구조를 합성하고, 이를 실행 가능한 JSON으로 컴파일하는 기술이 도입되고 있다. [26-28]
|
||||
|
||||
### 3. API JSON(workflow_api.json)과의 차이
|
||||
- **목적**: Frontend JSON은 시각적 편집용이며, API JSON은 서버 측 실행 및 프로그래밍 방식의 호출에 최적화되어 있다. [1, 6, 9, 29]
|
||||
- **메타데이터**: API 포맷은 노드 위치, 크기, 그룹 등 UI 관련 데이터를 제거하여 파일 크기를 압축한다. [1, 30]
|
||||
- **연결 방식**: API 포맷은 링크를 별도 객체가 아닌 노드 입력 내의 직접적인 참조(Origin 노드 ID 및 슬롯)로 임베딩한다. [1, 6, 29]
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **메타데이터 휘발성**: 생성된 이미지 내의 JSON 데이터는 일반적인 이미지 편집기, 소셜 미디어 플랫폼, 또는 파일 압축 유틸리티를 거칠 때 삭제될 위험이 크다. [3, 11, 21]
|
||||
- **버전 호환성 문제**: ComfyUI의 빈번한 업데이트로 인해 구버전의 JSON 파일이 최신 버전에서 정상적으로 작동하지 않을 수 있으며, 특히 커스텀 노드 클래스 이름의 변경이 주요 원인이 된다. [19, 31]
|
||||
- **실행 제한**: Frontend JSON을 API 엔드포인트(`/prompt`)에 직접 전달하면 실행 그래프가 아니라는 이유로 오류가 발생하므로, 반드시 'Dev mode'를 활성화하여 API 포맷으로 변환하거나 서버 측 변환기를 거쳐야 한다. [12, 32]
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Mystic 파이프라인**: 서버리스 엔드포인트 배포 시 메인 디렉토리에 `workflow.json`을 포함하여 관리한다. [33]
|
||||
- **RunComfy 플랫폼**: FLUX 워크플로우 예시로 `flux_workflow.json` 파일이 제공되며, 이는 전체 UI 상태를 포함하는 표준 Frontend 포맷이다. [9, 30]
|
||||
- **추출 도구 활용**: `exiftool -b -workflow input.png > workflow.json` 명령어를 통해 이미지 메타데이터에서 Frontend JSON을 물리적으로 분리하는 방식이 실무에서 사용된다. [24, 25]
|
||||
- **ComfyUI-to-Python-Extension**: Frontend JSON의 시각적 메타데이터를 포함한 상태로 Python 스크립트로 변환하여 드래그 앤 드롭 재가져오기 기능을 유지한다. [34]
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
id: large-language-models-(llm)
|
||||
title: "Large Language Models (LLM)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI-WorkflowGenerator", "ComfyGPT Research"]
|
||||
github_commit: "82df278"
|
||||
---
|
||||
|
||||
# [[Large Language Models (LLM)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
LLM은 자연어 의도를 실행 가능한 ComfyUI 노드 그래프로 변환함으로써 '시각적 프로그래밍'을 '대화형 프로그래밍'으로 진화시키는 핵심 가교 역할을 수행한다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **자연어 기반 워크플로우 합성 (Natural Language Synthesis):** 사용자의 텍스트 설명을 해석하여 복잡한 노드 연결 구조를 자동으로 설계하는 기술 [3, 4].
|
||||
2. **멀티 스테이지 파이프라인 (Multi-stage Pipeline):** 생성(Generator), 검증(Validator), 빌드(Builder)의 세 단계를 거쳐 논리적 설계를 물리적 실행 파일로 변환하는 구조 [5].
|
||||
3. **미세 조정된 도메인 특화 모델 (Fine-tuned Specialized Models):** ComfyUI의 노드 레지스트리와 스키마 규격에 최적화된 특정 파라미터 규모의 모델(예: Qwen2.5-14B) [3, 6].
|
||||
4. **시맨틱 노드 검증 (Semantic Node Validation):** LLM이 생성한 노드 명칭을 실제 설치된 노드 라이브러리와 대조하여 수정하는 시맨틱 검색 및 임베딩 기술 [5, 7].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **논리-물리 분리 설계 패턴:** LLM이 먼저 추상적인 그래프 논리(Logical Graph)를 생성한 후, 이를 로컬 환경의 실제 노드 클래스와 매핑하여 검증하는 이단계 접근 방식을 취함 [1, 5].
|
||||
- **바이트코드로서의 JSON:** JSON 파일을 단순한 저장 포맷이 아닌, 인간의 의도와 AI 실행 엔진 사이의 중간 언어(Bytecode)로 취급함 [1].
|
||||
- **RAG 기반 지식 확장 패턴 (지향점):** 정적 모델의 한계를 극복하기 위해 실시간 노드 데이터베이스를 쿼리하여 새로운 노드 지식을 습득하는 구조로의 발전 경향 [8].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
LLM을 활용한 ComfyUI 워크플로우 생성은 기술적 지식이 부족한 사용자도 복잡한 생성 AI 파이프라인을 구축할 수 있게 돕는다. 소스에 따르면, **ComfyUI-WorkflowGenerator**는 Qwen2.5-14B 모델을 미세 조정하여 자연어 지시(예: "Depth ControlNet을 추가해줘")를 실행 가능한 JSON 구조로 변환한다 [3, 4, 6].
|
||||
|
||||
생성 프로세스는 세 가지 핵심 구성 요소로 운영된다. **Generator**는 LLM을 사용해 사용자의 프롬프트를 해석하고 논리적 그래프 구조를 생성하며, **NodeValidator**는 이 구조가 로컬 ComfyUI 환경의 실제 노드들과 호환되는지 확인하고 수정한다 [5, 7]. 마지막으로 **WorkflowBuilder**는 이를 최종적인 실행 가능 JSON 형식으로 컴파일한다 [5, 9].
|
||||
|
||||
성능 최적화를 위해 GGUF 형식으로 양자화된 모델이 사용되며, 시맨틱 검색에는 `sentence-transformers` 모델이 활용된다 [6, 10]. 현재 시스템은 학습 데이터 컷오프 이후에 출시된 커스텀 노드를 인식하지 못하는 '정적 모델'의 한계를 가지고 있으나, 향후 I/O 스키마(데이터 타입) 인식 및 소형 그래프 추론 모델(SLM)을 통한 개선이 논의되고 있다 [8, 11].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **정적 학습 vs 실시간 생태계:** LLM은 학습된 시점의 노드 정보에 고정(Frozen)되어 있는 반면, ComfyUI 생태계는 매일 새로운 노드가 추가되는 불일치가 발생함 [11]. 이를 해결하기 위해 단순 생성이 아닌 RAG(검색 증강 생성) 기반의 탐색 기술로의 전환이 필요함이 강조됨 [8].
|
||||
- **언어적 타당성 vs 실행적 유효성:** 현재 시스템은 언어적으로 그럴싸한 연결을 생성할 수 있으나, 실제 노드 간의 데이터 타입(LATENT, IMAGE 등)이 물리적으로 일치하는지 완벽히 보장하지 못하는 경우가 있어 향후 'I/O 스키마 인식' 에이전트의 도입이 요구됨 [8].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI-WorkflowGenerator:** Qwen2.5-14B를 기반으로 자연어 설명을 노드 그래프로 변환하는 실제 커스텀 노드 프로젝트 [4, 12].
|
||||
- **ComfyGPT Research:** "ComfyGPT: A Self-Optimizing Multi-Agent System for Comprehensive ComfyUI Workflow Generation" 논문에 기반한 자가 최적화 시스템 설계 [5].
|
||||
- **Update Node Catalog:** 로컬에 설치된 모든 노드(네이티브 및 커스텀)를 스캔하여 LLM이 참조할 수 있는 카탈로그 파일로 생성하는 구현체 [9].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
id: load-image-(base64)
|
||||
title: "Load Image (Base64)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["Base64 Image Loading", "Image-to-Base64 API Input"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy_api_python.py"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Load Image (Base64)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
API 기반 자동화 환경에서 별도의 파일 서버 저장 절차 없이 워크플로우 JSON 내에 이미지 데이터를 텍스트 형태로 직접 포함하여 전송하는 핵심 데이터 주입 기술 [1], [2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **데이터 임베딩 (Data Embedding):** 이미지 바이너리 데이터를 Base64 문자열로 변환하여 워크플로우 JSON의 입력 필드에 직접 삽입함 [2].
|
||||
2. **무저장소 아키텍처 (Stateless Storage):** 서버 측의 임시 파일 저장소에 이미지를 저장할 필요 없이 메모리 상에서 직접 워크플로우를 실행하게 함 [1].
|
||||
3. **자체 완결적 요청 (Self-contained Request):** 생성 로직(Workflow)과 원천 데이터(Image)를 하나의 JSON 페이로드에 통합하여 데이터 관리 복잡성을 해소함 [1].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **동적 파라미터 치환 패턴:** 로컬에서 이미지를 Base64로 인코딩한 후, 워크플로우 JSON에서 해당 노드의 ID를 식별하여 `inputs`의 `base64_data` 필드 값을 동적으로 교체하여 서버에 요청함 [3], [2].
|
||||
- **API 호출 표준화:** 생산용 자동화 시스템(예: 배너 광고 생성)에서 입력 이미지가 매번 바뀔 때마다 파일 경로 관리 대신 데이터 자체를 전송하는 방식을 취함 [1].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **기능 및 정의:** 'Load Image (Base64)' 노드는 주로 API 호출을 통한 프로덕션 자동화 시스템에서 활용된다 [1]. 이 노드는 이미지를 문자열로 인코딩하여 JSON 워크플로우 내에 직접 포함할 수 있게 설계되었으며, 이는 ComfyUI를 외부 애플리케이션이나 원격 서버에 통합할 때 필수적인 요소다 [1].
|
||||
- **동작 메커니즘:** 파이썬(Python)과 같은 외부 언어를 사용하여 이미지를 `base64.b64encode` 방식으로 변환한다 [2]. 이후 API 형태의 워크플로우 JSON 파일에서 해당 노드의 고유 ID(예: #37)를 찾아 `inputs` 딕셔너리 내의 `base64_data` 필드에 해당 문자열을 주입한다 [2].
|
||||
- **운영상의 이점:** 서버 측에 이미지 파일을 업로드하고 경로를 참조하는 번거로운 과정을 우회할 수 있어 시스템이 간결해진다 [1]. 특히 깊이 추정(depth estimation)이나 스타일 변환(style transfer)처럼 다양한 입력 이미지가 반복적으로 요구되는 환경에서 효율적이다 [1].
|
||||
- **연결성:** 이 노드는 이미지를 Base64 데이터로부터 직접 복원하여 워크플로우 내의 다음 노드(예: CLIP Vision Encode, ControlNet 등)로 전달하는 역할을 수행한다 [1], [2].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **파일 경로와의 차이:** 일반적인 'Load Image' 노드는 서버 내 `input` 폴더의 물리적 파일 이름을 참조하지만, 'Load Image (Base64)'는 파일 이름이 아닌 인코딩된 데이터 문자열 자체를 직접 처리한다는 기술적 차이가 존재한다 [1], [2].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Python API 연동 예제 (소스 152):** `comfy_api_python.py`라는 파일 이름으로 구체적인 구현 코드가 제시되었다. 해당 코드에서는 `image_base64(filename)` 함수를 통해 이미지를 인코딩하고, `prompt[str(load_image_node_id)]["inputs"]["base64_data"] = image` 로직을 통해 JSON 데이터를 동적으로 수정하여 ComfyUI 서버에 요청을 보내는 방식이 실제로 적용되었다 [2].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
id: metadata-extraction
|
||||
title: "Metadata Extraction"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["exiftool", "comfyui-extractor.py", "Comfy_UI_prompt_extractor", "ComfyUI-to-Python-Extension", "Weird Wonderful AI Art Extractor"]
|
||||
github_commit: "82df278"
|
||||
---
|
||||
|
||||
# [[Metadata Extraction]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
AI 생성 이미지 파일 자체를 실행 가능한 워크플로우의 '컨테이너'로 활용하여 생성 로직의 영속성과 공유를 보장하는 핵심 메커니즘 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Steganographic Embedding (비가시적 데이터 주입):** PNG의 `tEXt`나 `zTXt`와 같은 메타데이터 청크 내에 JSON 형식의 노드 그래프와 설정값을 주입하여 보존함 [2, 3].
|
||||
- **Format Redundancy (포맷 중복성):** 시각적 레이아웃 정보가 포함된 **Frontend JSON (workflow.json)**과 실행을 위한 경량화된 **API JSON (prompt)**을 동시에 이미지에 저장하여 편집과 재실행을 모두 지원함 [3, 4].
|
||||
- **Self-Documenting Artifact (자기 문서화 아티팩트):** 생성된 미디어가 단순한 결과물이 아니라, 이를 만든 알고리즘(워크플로우)을 내포한 독립적인 소스 코드 역할을 수행함 [2, 5].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Direct Canvas Restoration:** 이미지 파일을 ComfyUI 브라우저 캔버스로 드래그 앤 드롭하여 즉각적으로 노드 레이아웃을 복구하는 패턴 [1, 6-8].
|
||||
- **Binary Chunk Isolation:** 외부 명령줄 도구를 통해 이미지 데이터와 분리하여 특정 메타데이터 태그(`-workflow`, `-prompt`)만을 바이너리 형태로 추출하는 패턴 [9, 10].
|
||||
- **Metadata Fragility (취약성 패턴):** 이미지 편집기(GIMP 등)나 소셜 미디어 플랫폼을 거치며 최적화 과정에서 비정형 메타데이터가 삭제되어 워크플로우 정보가 소실되는 현상 [3, 11-13].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI의 메타데이터 추출은 단순히 정보를 읽는 것을 넘어, **생성 AI 워크플로우를 재구성하는 기술적 토대**가 됨.
|
||||
|
||||
- **데이터 저장 구조:** PNG 파일 내에서 ComfyUI는 주로 두 가지 문자열을 주입함. 하나는 노드 위치와 시각적 그룹을 포함한 **Frontend 형식**이고, 다른 하나는 백엔드 엔진이 즉시 실행할 수 있는 **API 형식(prompt)**임 [3, 14].
|
||||
- **알고리즘적 추출 방법:**
|
||||
- **Native API:** ComfyUI 웹 인터페이스는 이미지를 불러올 때 내부적으로 메타데이터를 파싱하여 `nodes` 배열을 재구성함 [7, 15].
|
||||
- **CLI 기반 도구:** `exiftool`을 활용하여 `-workflow` 태그를 바이너리(`-b`)로 읽어 JSON 파일로 리다이렉션하는 방식이 표준적으로 사용됨 [9, 10].
|
||||
- **전용 추출기:** `comfyui-extractor.py`나 웹 기반의 `Weird Wonderful AI Art` 도구는 이미지에서 긍정적 프롬프트, API 그래프, UI 레이아웃을 각각 분리하여 추출하는 기능을 제공함 [9, 12, 16].
|
||||
- **프로그래밍적 연동:** `ComfyUI-to-Python-Extension`과 같은 도구는 생성된 Python 스크립트로 이미지를 만들 때 워크플로우 메타데이터를 포함시켜, 추후 사용자가 이미지를 다시 ComfyUI로 드롭했을 때 원래의 워크플로우를 열 수 있도록 설계됨 [17].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **정보 누락 가능성:** Save-Image 노드가 워크플로우를 주입할 때, 새로 추가된 노드나 특정 커스텀 노드의 정보가 때때로 누락될 수 있다는 한계가 보고됨 [11].
|
||||
- **편집기 호환성 문제:** GIMP와 같은 외부 편집 도구를 사용하면 워크플로우 메타데이터가 비표준 태그로 인식되어 삭제되는 이슈가 있으며, 이를 해결하기 위해 `exiftool`의 `%unreg` 설정을 통한 재삽입 기능이 논의되고 있음 [10, 13].
|
||||
- **최신 동향:** 단순 추출을 넘어, 워크플로우를 이미지나 SVG에 렌더링하여 시각적으로 확인하면서도 메타데이터를 보존하는 방식(`pythongosssss' workflow image` 등)이 대안으로 활용됨 [13, 15].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ExifTool 자동화:** `exiftool -b -workflow input.png > workflow.json` 명령어를 통해 대량의 이미지에서 워크플로우를 벌크로 추출함 [9].
|
||||
- **ComfyUI-to-Python-Extension:** 내보낸 `.py` 스크립트 실행 시 `Save As Script` 기능을 통해 이미지 메타데이터에 워크플로우 정보를 동봉함 [17].
|
||||
- **Weird Wonderful AI Art:** 웹 인터페이스를 통해 PNG 파일로부터 JSON 및 Prompt 데이터를 1클릭으로 추출 및 다운로드하는 서비스를 구현함 [12, 16].
|
||||
- **Git Commit:** 소스 내에서 `82df278` 커밋(DanielPFlorian)을 통해 모델 경로 해결 및 모델 정보 누락 방지를 위한 코드 변경이 확인됨 [18].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: node-definitions
|
||||
title: "Node Definitions"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["Node Schema", "ComfyUI Node Structure"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.90
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법", "Node Definitions"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow.json", "workflow_api.json", "object_info.json", "comfyui-workflow-to-api-converter-endpoint", "ComfyUI-WorkflowGenerator"]
|
||||
github_commit: "bc85382, 82df278"
|
||||
---
|
||||
|
||||
# [[Node Definitions]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
노드 정의는 ComfyUI 워크플로우의 기능적 논리와 시각적 레이아웃을 결정하는 핵심 원자 단위로, 고유 ID와 입출력 스키마를 통해 복잡한 AI 프로세스를 유향 비순환 그래프(DAG)로 구조화한다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **고유 식별자 (Node ID):** 워크플로우 내에서 각 노드를 구분하는 고유한 숫자 또는 문자열 키(예: "#37")로, 그래프 순회 및 데이터 참조의 기준이 된다 [4, 5].
|
||||
- **클래스 매핑 (Type/Class Type):** JSON의 `type` 또는 `class_type` 필드는 ComfyUI 백엔드 레지스트리에 등록된 특정 Python 클래스와 노드를 연결하여 실행 로직을 정의한다 [2, 6, 7].
|
||||
- **입출력 슬롯 (I/O Slots):** 데이터 흐름을 위한 인터페이스로, `inputs`는 상위 노드의 출력을 참조하고 `outputs`는 하위 노드로 전달될 데이터 링크 정보를 포함한다 [4, 8].
|
||||
- **위젯 및 속성 (Widgets & Properties):** 슬라이더, 텍스트 박스, 체크박스 등 사용자가 직접 입력한 값(`widgets_values`)과 노드의 내부 동작 설정을 저장한다 [2, 4, 9].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **형식의 이분화 (Serialization Bifurcation):** 시각적 정보(위치, 크기, 그룹)를 포함하는 **Frontend 형식(workflow.json)**과 실행에 필요한 논리 정보만 남긴 **API 형식(workflow_api.json)**으로 나뉘어 관리된다 [10-12].
|
||||
- **실행 모델 역전 (Execution Model Inversion):** 엔진은 모든 노드를 실행하는 대신 'Save Image'와 같은 출력 노드에서 역방향으로 그래프를 탐색하여 필요한 의존성 노드만 실행 리스트에 포함시킨다 [13].
|
||||
- **메타데이터 임베딩 패턴:** 생성된 미디어(PNG, WebP)의 tEXt/zTXt 청크 내에 노드 그래프 JSON을 주입하여 파일 자체가 워크플로우 컨테이너 역할을 수행하도록 설계한다 [14-16].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 노드는 **JSON v1.0 스키마**에 따라 정밀하게 정의되며, 각 노드 객체는 다음과 같은 필수 속성을 보유해야 한다 [2, 17]:
|
||||
- **id:** 그래프 순회를 위한 유효한 정수 또는 문자열 식별자 [2, 5].
|
||||
- **type/class_type:** 노드의 기능을 결정하는 레지스트리 클래스명 [2, 6].
|
||||
- **pos & size:** UI 캔버스 렌더링을 위한 좌표 `[x, y]` 및 차원 `[width, height]` 정보 (Frontend 전용) [2, 4].
|
||||
- **widgets_values:** 사용자가 입력한 위젯 상태 값의 배열 또는 객체 [2, 4].
|
||||
- **order:** 노드의 실행 또는 렌더링 우선순위를 나타내는 인덱스 [2].
|
||||
- **mode:** 노드의 작동 상태(활성, 우회/Bypass 등)를 결정하는 수치 [2, 18].
|
||||
|
||||
**연결 구조(Connectivity):**
|
||||
연결은 `inputs`와 `outputs` 배열을 통해 정의된다. `inputs` 내부의 `link` 속성은 들어오는 와이어의 고유 ID를 가리키며, API 형식에서는 이를 소스 노드 ID와 슬롯 인덱스의 쌍(예: `[19, 20]`)으로 직접 포함하기도 한다 [8, 9]. 슬롯 인덱싱은 다중 출력을 가진 노드(예: VAE Loader)에서 특정 데이터를 선택하는 데 필수적이다 [8].
|
||||
|
||||
**스키마 카탈로그 (object_info.json):**
|
||||
실행 중인 인스턴스에서 사용 가능한 모든 노드의 입력/출력 타입, 필수/선택적 입력 항목, 기본값 및 툴팁 정보를 포함하는 레지스트리 역할을 한다 [21, 22]. 이는 워크플로우를 동적으로 생성하거나 검증하는 도구에서 참조 모델로 사용된다 [23].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **JSON 버전 차이:** 소스 데이터는 최신 버전인 **v1.0**을 언급하지만, 이전 버전인 **0.4**와의 호환성 문제나 업데이트 논의가 여전히 진행 중임을 암시한다 [17, 24].
|
||||
- **대소문자 민감도 이슈:** ComfyUI 검증기가 콤보 위젯 값의 대소문자(예: "True" vs "true") 차이로 인해 실행을 거부하는 경우가 발생하여, 최신 변환 엔진에서는 이를 정규화(Normalization)하는 로직이 추가되었다 [25].
|
||||
- **노드 식별 키의 차이:** Frontend JSON은 수치형 문자열을 ID로 사용하는 반면, API JSON은 이를 기능적 키로 활용하며 UI 메타데이터를 완전히 제거한다 [10, 11, 26].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **workflow.json / workflow_api.json:** 노드 정의가 실제로 구현되는 표준 파일 형식으로, RunComfy 및 Replicate와 같은 서비스에서 배포의 기초로 사용된다 [12, 21, 27].
|
||||
- **object_info.json:** 실행 중인 서버의 `/object_info` 엔드포인트를 통해 실시간 노드 스키마를 제공한다 [23].
|
||||
- **comfyui-workflow-to-api-converter-endpoint (v2.3.0):** 비-API 워크플로우를 API 형식으로 변환할 때 `COMFY_DYNAMICCOMBO_V3` 위젯 및 하위 입력을 처리하고 대소문자 문제를 해결하는 로직이 적용되었다 (Commit: `bc85382`) [25, 28-30].
|
||||
- **ComfyUI-WorkflowGenerator:** 자연어 설명을 기반으로 `WorkflowGenerator` -> `NodeValidator` -> `WorkflowBuilder` 단계를 거쳐 노드 그래프를 동적으로 생성하며, `UpdateNodeCatalog` 노드를 통해 로컬 노드 레지스트리를 스캔한다 (Commit: `82df278`) [31-34].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: node-based-visual-programming
|
||||
title: "Node-based Visual Programming"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["시각적 프로그래밍", "그래프 기반 프로그래밍"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["DanielPFlorian/ComfyUI-WorkflowGenerator", "SethRobinson/comfyui-workflow-to-api-converter-endpoint", "pydn/ComfyUI-to-Python-Extension", "docs.comfy.org/specs/workflow_json"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Node-based Visual Programming]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI의 노드 기반 시각적 프로그래밍은 복잡한 AI 생성 프로세스를 **방향성 비순환 그래프(DAG)**로 추상화하여, 코드 작성 없이도 정교한 파이프라인 설계와 실행 로직의 직렬화를 실현한다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **노드 및 그래프 구조 (Nodes & Graph):** 로더, 샘플러, 인코더 등 특정 기능을 수행하는 프로그램 객체(Nodes)를 링크(Links)로 연결하여 전체 데이터 흐름을 정의하는 네트워크를 형성한다 [1, 3].
|
||||
- **방향성 비순환 그래프 (Directed Acyclic Graph, DAG):** 데이터가 한 방향으로만 흐르며 순환하지 않는 구조로, 생성 AI의 절차적 프레임워크를 효율적으로 기술한다 [1, 4].
|
||||
- **워크플로 직렬화 (Serialization):** 시각적으로 구성된 그래프를 인간이 읽을 수 있고 용량이 작은 **JSON 형식**으로 변환하여 아카이빙, 공유 및 프로그래밍 방식의 자동화를 가능하게 한다 [1, 5].
|
||||
- **시각적 추상화:** 정적 메뉴나 선형 파이프라인 대신 노드 간의 동적 연결을 통해 복잡한 시스템을 직관적으로 설계할 수 있는 고수준 환경을 제공한다 [1, 2].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **형식의 이분화 (Bifurcation of Formats):** 시각적 레이아웃 정보를 포함한 **프론트엔드 포맷(workflow.json)**과 실행에 필수적인 로직만 남긴 **API 포맷(workflow_api.json)**으로 구분하여 사용 목적에 최적화한다 [6, 7].
|
||||
- **메타데이터 임베딩 (Metadata Embedding):** 생성된 미디어 파일(PNG, WebP 등) 내부에 워크플로 전체 로직을 주입하여, 이미지 자체가 생성 청사진의 컨테이너 역할을 하도록 설계한다 [5, 8].
|
||||
- **실행 모델 역전 (Execution Model Inversion):** 엔진이 출력 노드(Save Image 등)에서 시작하여 그래프를 역방향으로 탐색, 최종 출력에 필요한 의존성 노드만 식별하여 실행 최적화를 달성한다 [9].
|
||||
- **LLM 기반 합성 파이프라인:** 자연어 설명을 '논리적 합성 → 세만틱 검증 → 그래프 컴파일'의 3단계 과정을 거쳐 실행 가능한 JSON 노드 그래프로 변환하는 자동화 패턴이 등장하고 있다 [10-12].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI는 생성형 AI 콘텐츠를 구축하고 실행하기 위한 **절차적 프레임워크(Procedural Framework)**로 기능한다 [3, 4]. 노드 기반 방식은 전통적인 소프트웨어의 버튼 기반 UI가 제공할 수 없는 수준의 유연성을 제공하며, 사용자는 수학적 지식이나 프로그래밍 코드 없이도 복잡한 시스템을 설계할 수 있다 [2].
|
||||
|
||||
### JSON 스키마 및 데이터 구조
|
||||
ComfyUI 워크플로의 핵심인 JSON 파일은 **v1.0 규격**을 따르며, 각 노드는 고유 ID, 클래스 타입(type), 캔버스 좌표(pos), 크기(size), 입력(inputs) 및 출력(outputs) 슬롯 정보를 포함한다 [13, 14]. 특히 링크는 `[origin_id, origin_slot, target_id, target_slot]`의 구조로 정의되어 노드 간의 정밀한 데이터 전송을 보장한다 [15].
|
||||
|
||||
### 워크플로 생성 및 관리 방식
|
||||
1. **수동 생성:** 웹 인터페이스에서 노드를 배치하고 `Ctrl+S`를 통해 시각적 레이아웃이 포함된 JSON을 내보내거나, 'Dev mode'를 활성화하여 실행 전용 API 포맷을 추출할 수 있다 [16, 17].
|
||||
2. **프로그래밍 방식 생성:** Python의 `json` 라이브러리를 사용해 딕셔너리 구조를 직접 수정하거나, `Comfy Nodekit` 또는 `Comfy API Simplified`와 같은 래퍼 라이브러리를 통해 노드 제목 기반으로 매개변수를 동적으로 변경할 수 있다 [18, 19].
|
||||
3. **미디어 추출:** `exiftool`이나 웹 기반 추출 도구를 사용해 PNG의 `tEXt` 또는 `zTXt` 청크에서 직렬화된 워크플로 데이터를 복구할 수 있다 [20-22].
|
||||
|
||||
### 의존성 및 보안 관리
|
||||
워크플로 공유 시 가장 흔한 문제는 'Missing Custom Nodes' 오류(붉은색 노드)이며, 이를 위해 **ComfyUI-Manager**가 JSON을 파싱하여 누락된 패키지를 식별하고 자동 설치를 지원한다 [23, 24]. 최신 동향으로는 모델 파일의 경로 문제 해결을 위해 파일명 대신 **SHA-256 해시값**을 사용하는 모델 해싱 방식이 도입되고 있다 [25, 26].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **데이터 보존의 취약성:** PNG 메타데이터에 저장된 워크플로는 소셜 미디어나 파일 압축 과정에서 손실되기 쉬우며, 이로 인해 이미지 드래그 앤 드롭 기능을 상실할 수 있는 위험이 존재한다 [20].
|
||||
- **포맷 간 불일치:** API 포맷 JSON을 UI에 직접 로드할 경우 시각적 레이아웃 정보가 없어 그래프가 '스켈레톤' 상태로 나타나는 등 편집이 어려워지는 문제가 발생한다 [27]. 이를 해결하기 위해 서버 사이드에서 비-API 포맷을 API 포맷으로 변환해주는 별도의 엔드포인트 구현 사례가 존재한다 [28].
|
||||
- **버전 호환성:** ComfyUI의 빈번한 업데이트로 인해 구버전 JSON 파일이 최신 버전에서 정상적으로 작동하지 않을 수 있음을 공식적으로 경고하고 있다 [29].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **DanielPFlorian/ComfyUI-WorkflowGenerator:** LLM(Qwen2.5-14B)을 사용하여 자연어 설명을 ComfyUI 노드 그래프로 자동 생성하는 3단계 파이프라인 구현 [30, 31].
|
||||
- **SethRobinson/comfyui-workflow-to-api-converter-endpoint:** 비-API 워크플로 JSON을 서버측에서 실행 가능한 API 포맷으로 자동 변환하는 `/workflow/convert` 엔드포인트 제공 [28, 32].
|
||||
- **pydn/ComfyUI-to-Python-Extension:** 워크플로 JSON을 독립적인 실행이 가능한 Python 스크립트(`.py`)로 변환하는 도구 [33, 34].
|
||||
- **ComfyUI 공식 문서 (`docs.comfy.org/specs/workflow_json`):** 워크플로 무결성 검증을 위한 JSON Schema v1.0(Draft-07 기반) 규격 정의 [14, 35].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (주요 오픈소스 프로젝트 및 공식 문서 내 스펙 확인됨)
|
||||
- **출처 신뢰도:** B (Official Documentation / GitHub Repository / Expert Tutorial Synthesis)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
id: nodes
|
||||
title: "Nodes"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI-WorkflowGenerator", "ComfyUI-to-Python-Extension", "comfyui-workflow-to-api-converter-endpoint"]
|
||||
github_commit: "82df278, bc85382"
|
||||
---
|
||||
|
||||
# [[Nodes]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
노드는 ComfyUI의 핵심 엔진이자 기능적 단위로서, 고유한 메타데이터와 입출력 연결을 통해 생성형 AI 프로세스를 유향 비순환 그래프(DAG)로 추상화한다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **노드 객체 (Node Object):** ID, 타입, 위치 정보를 포함하며 특정 기능을 수행하는 독립적인 프로그램 모듈이다 [3-5].
|
||||
- **입출력 슬롯 및 링크 (I/O Slots & Links):** 노드 간 데이터를 전달하는 통로로, 입력(inputs)은 들어오는 와이어의 ID를, 출력(outputs)은 하나 이상의 하류 노드로 연결되는 링크 ID 배열을 포함한다 [4, 6].
|
||||
- **노드 레지스트리 (Node Registry):** 설치된 모든 노드의 클래스 이름과 입출력 스키마(object_info)를 관리하는 중앙 카탈로그이다 [4, 7, 8].
|
||||
- **실행 모드 (Mode):** 노드의 활성화 상태(active), 우회(bypass) 등을 결정하며, 백엔드 엔진은 이를 기반으로 실행 경로를 계산한다 [4, 5, 9].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **실행 모델 역전 (Execution Model Inversion):** 엔진이 출력 노드(Save Image 등)에서 시작하여 역방향으로 그래프를 탐색, 결과 도출에 필요한 의존성 노드만 실행하여 효율성을 극대화한다 [10].
|
||||
- **형식별 노드 직렬화:** 프론트엔드 형식(workflow.json)은 노드의 좌표, 크기 등 시각적 메타데이터를 유지하는 반면, API 형식(workflow_api.json)은 실행에 필요한 로직과 직접적인 노드 입력 참조만 남긴다 [11-13].
|
||||
- **자동 검증 및 보정:** 생성된 워크플로의 노드 이름을 로컬 설치 환경이나 시맨틱 임베딩과 대조하여 유효성을 검사하고 오류를 수정한다 [14-16].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 노드 객체의 기술적 사양 (v1.0 Schema)
|
||||
ComfyUI 워크플로 JSON 내에서 각 노드는 다음과 같은 속성을 필수적으로 정의해야 한다 [4, 5]:
|
||||
- **id:** 그래프 탐색을 위한 고유 식별자 (정수 또는 문자열) [17].
|
||||
- **type / class_type:** 노드 레지스트리의 클래스 이름과 매핑되는 식별자 [5, 18].
|
||||
- **pos & size:** 캔버스 좌표 [x, y] 및 시각적 크기 [width, height] (프론트엔드 전용) [4, 19].
|
||||
- **widgets_values:** 슬라이더, 텍스트 박스, 토글 등 사용자 입력 값을 저장하는 배열 [4, 20].
|
||||
- **order:** 노드의 실행 또는 렌더링 순서 인덱스 [4].
|
||||
|
||||
### 주요 노드 카테고리 및 기능
|
||||
- **로더 (Loaders):** Checkpoint, LoRA, VAE, ControlNet 등 외부 모델 가중치를 워크플로로 불러온다 [21, 22].
|
||||
- **샘플러 (Samplers):** KSampler, SamplerCustom 등 잠재 공간(Latent space)에서 노이즈를 제거하여 이미지를 생성한다 [23, 24].
|
||||
- **조건화 및 인코딩 (Conditioning & Encoding):** CLIP Text Encode(프롬프트 처리), VAE Encode/Decode(픽셀과 잠재 공간 간 변환) 등을 수행한다 [20, 21, 24].
|
||||
- **유틸리티 (Utils):** Reroute(선 정리), Primitive, Note 등 워크플로의 조직화와 가독성을 돕는다 [23, 25].
|
||||
|
||||
### API 및 자동화 환경의 노드 처리
|
||||
API 기반 실행 시, 노드는 **API JSON 형식**으로 직렬화되어 시각적 정보가 제거된다 [11, 26]. 이때 노드 간 연결은 별도의 링크 배열이 아닌 `inputs` 필드 내에 상류 노드 ID와 슬롯 인덱스 형태로 직접 임베딩된다 [11, 20]. 독립 실행형 스크립트나 외부 앱 연동 시에는 `Load Image (Base64)` 노드를 통해 이미지를 JSON 내에 직접 포함시키거나, `SaveImageWebsocket`을 통해 결과를 실시간으로 수신하는 패턴이 사용된다 [17, 27, 28].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **노드 식별 방식:** 프론트엔드 JSON은 시각적 ID를 사용하지만, API JSON은 기능적 키(Functional keys)를 사용하여 백엔드와 매핑한다 [12].
|
||||
- **커스텀 노드 의존성:** 소스 간 공통적으로 지적되는 문제로, 워크플로 JSON에 포함된 노드가 로컬에 설치되어 있지 않으면 '빨간 박스(Missing Nodes)' 오류가 발생하며 ComfyUI Manager를 통한 해결이 권장된다 [29-31].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI-WorkflowGenerator [32, 33]:** 자연어 설명을 기반으로 `Generator` -> `Validator` -> `Builder` 단계를 거쳐 노드 그래프를 자동으로 생성하고 검증하는 시스템을 구현함.
|
||||
- **comfyui-workflow-to-api-converter-endpoint [8, 25, 34]:** `/workflow/convert` 엔드포인트를 통해 프론트엔드 노드 데이터를 API 규격으로 변환하며, `reroute` 노드 무시 및 `INPUT_TYPES()` 기반 기본값 보정 기능을 포함함 (Commit: `bc85382`).
|
||||
- **ComfyUI-to-Python-Extension [35, 36]:** UI의 노드 그래프를 실행 가능한 Python 스크립트로 변환하여 자동화 환경에서 노드 로직을 재사용할 수 있게 함.
|
||||
- **RunComfy API [7, 37]:** `object_info.json`을 통해 인스턴스 내 모든 노드의 입력/출력 스키마를 제공하여 외부 툴의 유효성 검사에 활용함.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 프로젝트 및 공식 문서 내 스펙 확인됨)
|
||||
- **출처 신뢰도:** B (공식 문서 및 오픈소스 프로젝트 기술 명세 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine. (Sources: [1-6, 8, 11, 33])
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
id: rag-(retrieval-augmented-generation)
|
||||
title: "RAG (Retrieval-Augmented Generation)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["검색 증강 생성"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법", "LLM", "Workflow-Automation"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI-WorkflowGenerator (Future Roadmap)", "Alibaba ViDoRAG"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[RAG (Retrieval-Augmented Generation)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
RAG는 정적인 학습 데이터에 갇힌 LLM의 한계를 넘어, 실시간 노드 생태계와 전문가의 워크플로우 패턴을 동적으로 검색하여 실행 가능한 ComfyUI JSON을 생성하는 차세대 아키텍처의 핵심이다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **노드 정보 검색 (Node Information Retrieval):** 모델 가중치에 노드 지식을 고정하는 대신, 현재 설치된 노드 및 최신 리포지토리를 포함하는 동적 벡터 데이터베이스를 쿼리하여 새로운 노드 정보를 실시간으로 획득한다 [2].
|
||||
- **사례 기반 추론 (Case-Based Reasoning):** 커뮤니티에서 공유된 수천 개의 고품질 워크플로우를 "지식 패턴"으로 인덱싱하고, 특정 문제 해결(예: ControlNet 연결 방식)을 위해 기존 전문가의 하위 그래프를 검색 및 복제한다 [2].
|
||||
- **I/O 스키마 인식 (I/O Schema Awareness):** 단순한 이름 일치를 넘어, 검색된 데이터를 바탕으로 노드 간의 데이터 유형(Float, Image, Latent 등)이 실행 가능한 수준에서 호환되는지 논리적으로 검증한다 [2].
|
||||
- **정적 모델의 한계 극복:** 학습 시점(Cutoff) 이후에 출시된 커스텀 노드에 대해 "환각(Hallucination)" 없이 정확한 연결 구조를 제안하기 위한 수단으로 활용된다 [1, 3].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **3단계 생성 파이프라인의 확장:** 기존 [논리적 합성 -> 세만틱 검증 -> 그래프 컴파일] 과정 중 검증 및 합성 단계에서 외부 지식을 주입하는 패턴이 발견된다 [2, 4, 5].
|
||||
- **에이전트 기반 탐색:** 워크플로우 생성기가 단순한 변환기가 아닌, 실시간 ComfyUI 환경을 "읽고" 문서화된 노드 사양을 학습하여 즉시 적용하는 능동적 에이전트 패턴으로 진화한다 [2, 6].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **정적 모델의 문제점:** 현재의 워크플로우 생성 모델(예: Qwen2.5-14B 기반)은 학습 데이터에 포함되지 않은 새로운 커스텀 노드나 변경된 아키텍처에 대응할 수 없는 "Frozen" 상태이다 [1].
|
||||
- **노드용 RAG (RAG for Nodes):** 미래의 아키텍처는 에이전트가 사용자의 **현재 설치된 노드**와 외부 데이터베이스를 쿼리하도록 설계된다. 이를 통해 오늘 출시된 노드의 문서도 즉시 "읽고" 워크플로우에 반영할 수 있다 [2].
|
||||
- **워크플로우 검색 및 적응:** 무에서 유를 창조하는 대신, 온라인상의 방대한 워크플로우 라이브러리를 인덱싱하여 검색한다. 에이전트는 전문가가 특정 하위 문제(Sub-problem)를 해결한 방식을 식별하고 이를 현재 작업에 맞게 적응시킨다 [2].
|
||||
- **지능형 디버깅:** AI 에이전트가 오류 메시지를 분석하고 RAG를 통해 적절한 대체 노드를 제안하거나 JSON 워크플로우를 수정하는 기능으로 확장될 수 있다 [7].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **현재와 미래의 격차:** 현재 제공되는 `ComfyUI-WorkflowGenerator`는 정적으로 미세 조정(Fine-tuned)된 모델을 사용하며, RAG 기반의 동적 노드 검색은 차세대 도구를 위한 "미래 비전" 및 "로드맵"으로 제시되고 있다 [2, 3, 8].
|
||||
- **기술적 성숙도:** 소스 내에서 RAG는 실제 구현된 기능보다는 모델의 한계를 극복하기 위한 아키텍처적 제안으로 주로 다루어진다 [2, 6].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI-WorkflowGenerator:** 프로젝트의 향후 비전으로 "Retrieval-Augmented Generation (RAG) for Nodes"를 명시하고 있으며, 벡터 임베딩 데이터베이스를 통한 노드 검색 아키텍처를 설계 중이다 [2].
|
||||
- **Alibaba ViDoRAG:** 소스 내 뉴스 목록에 "Intelligent Document Analysis Tool"로서 언급되어 있으나, 구체적인 ComfyUI 워크플로우 생성 연동 방식은 상세히 기술되지 않았다 [9].
|
||||
- **NodeValidator:** 현재 버전에서는 RAG의 초기 형태인 '세만틱 검색(Semantic Search)'을 사용하여 노드 이름의 오타를 수정하거나 설치된 노드 카탈로그와 대조하는 기능을 수행하고 있다 [10].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 RAG 엔진의 상세 구현 코드는 소스에 포함되지 않았으며, 아키텍처 제안 단계임)
|
||||
- **출처 신뢰도:** B (GitHub 오픈소스 연구 및 공식 문서 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine. (Focus: Architectural vision of RAG in workflow generation) [1, 2, 6, 8]
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
id: retrieval-augmented-generation-(rag)-for-nodes
|
||||
title: "Retrieval-Augmented Generation (RAG) for Nodes"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Retrieval-Augmented Generation (RAG) for Nodes]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
정적인 파인튜닝 모델의 지식 유효기간 한계를 극복하기 위해, 현재 설치된 노드와 최신 저장소의 정보를 실시간으로 검색하여 워크플로우를 생성하는 동적 아키텍처 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **동적 벡터 임베디드 데이터베이스 (Dynamic Vector-Embedded Database):** 사용자의 로컬 환경과 인터넷상의 최신 노드 저장소 정보를 실시간으로 쿼리할 수 있도록 벡터화하여 저장하는 시스템 [2].
|
||||
2. **노드 지식의 탈동기화 (Decoupling Node Knowledge):** 모델 가중치에 노드 정보를 고정하는 대신, 외부 지식 베이스에서 정보를 가져와 모델의 지식을 최신 상태로 유지함 [1, 2].
|
||||
3. **실시간 문서 해석 (Real-time Documentation Parsing):** 오늘 출시된 새로운 노드라도 에이전트가 해당 노드의 문서를 즉시 "읽고" 워크플로우 구성에 활용할 수 있게 함 [2].
|
||||
4. **환경 인지형 에이전트 (Environment-Aware Agent):** 사용자의 '현재 설치된' 노드 구성을 분석하고 이를 생성 프로세스에 반영하는 지능형 시스템 [2].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
* **지식 검색 기반 보정 (Retrieval-Based Correction):** 모델이 학습하지 못한 새로운 노드의 연결 방식이나 파라미터를 검색된 지식(RAG)을 통해 보정하는 패턴 [2].
|
||||
* **사례 기반 추론 및 적응 (Case-Based Reasoning & Adaptation):** 온라인의 고품질 워크플로우를 '지식 패턴'으로 인덱싱하고, 이를 검색하여 현재 문제 해결에 맞게 변형하여 적용함 [2].
|
||||
* **I/O 스키마 인식 (I/O Schema Awareness):** 단순히 노드 이름을 맞추는 수준을 넘어, 데이터 타입(Float, Image, Conditioning 등) 간의 실행 가능성을 검색된 정보를 기반으로 검증함 [2].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
* **정적 모델의 한계:** 현재의 `WorkflowGenerator`와 같은 모델은 특정 시점의 데이터로 파인튜닝되어 '동결'된 상태임 [1]. 따라서 매일 업데이트되는 ComfyUI 커스텀 노드 생태계의 변화를 따라잡지 못하며, 학습 데이터에 없는 노드에 대해 잘못된 연결(Hallucination)을 생성할 위험이 있음 [1, 2].
|
||||
* **RAG를 통한 해결책:** 미래의 워크플로우 생성 도구는 정적 파인튜닝을 넘어 RAG 시스템으로 진화해야 함 [3]. 에이전트는 사용자의 로컬 노드 카탈로그와 최신 온라인 데이터베이스를 동시에 쿼리하여 지식을 보충함 [2].
|
||||
* **워크플로우 검색 시스템:** 수천 개의 커뮤니티 워크플로우를 인덱싱하여, 전문가들이 특정 하위 문제(예: ControlNet과 Wan Video 노드의 연결 방식)를 해결하는 방식을 패턴화하고 이를 생성 시점에 검색하여 활용함 [2].
|
||||
* **기술적 이점:** 이 방식은 대규모 모델(70B+) 대신 그래프 이론과 DAG(Directed Acyclic Graph) 추론에 특화된 소규모 전문 모델(SLM)을 사용하면서도, 검색 시스템(RAG)을 통해 방대한 노드 어휘력을 확보할 수 있게 함 [2].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
* **현재와 미래의 격차:** 소스 데이터에 따르면 RAG 기반 노드 생성은 현재 완전히 구현된 기능이 아니라, ComfyGPT 연구를 기반으로 한 '차세대 도구의 진화 방향' 및 '아이디어'로 제시되고 있음 [2, 3].
|
||||
* **카탈로그 업데이트의 필요성:** 현재 구현(WorkflowGenerator)에서는 `UpdateNodeCatalog` 노드를 통해 로컬 노드를 스캔하여 수동으로 지식을 동기화해야 하는 단계에 머물러 있음 [4, 5].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
현재 소스 데이터에서 이 개념이 완전히 구현되어 적용된 실제 코드 사례는 발견되지 않았으며, "Future Vision(미래 비전)" 항목으로 기술되어 있음 [2]. 다만, 이를 위한 기초적인 단계로서 다음의 기능들이 언급됨:
|
||||
* **UpdateNodeCatalog 노드:** 현재 설치된 모든 노드(네이티브 및 커스텀)를 스캔하고 카탈로그화하여 노드 검증 및 빌드에 활용함 [5].
|
||||
* **NodeValidator 노드:** 시맨틱 검색(Semantic Search)을 통해 생성된 노드 이름을 로컬 카탈로그와 대조하여 교정함 [6].
|
||||
* **WorkflowGenerator 아키텍처:** ComfyGPT 연구를 바탕으로 생성-검증-구축의 3단계 파이프라인을 구축하여 RAG 시스템으로의 확장을 위한 토대를 마련함 [3, 7].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: serialization-formats
|
||||
title: "Serialization Formats"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["Workflow JSON Formats", "Frontend vs API Format"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow.json", "workflow_api.json", "object_info.json", "bc85382"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Serialization Formats]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI 직렬화는 인간의 시각적 편집을 위한 **Frontend 포맷(UI 데이터 포함)**과 서버 및 스크립트 실행을 위한 **API 포맷(순수 로직)**으로 이원화되어 워크플로우의 가시성과 실행 효율성을 동시에 확보한다 [1-4].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **Frontend Format (workflow.json):** Litegraph 표준을 따르며 노드 위치, 크기, 그룹화 등 시각적 메타데이터를 포함하여 사용자 인터페이스 재구성을 지원한다 [1, 2, 5].
|
||||
2. **Backend/API Format (workflow_api.json):** 시각적 요소를 제거하고 노드 입력값과 연결 관계만 포함된 스트림라인 실행 그래프로, `/prompt` 엔드포인트를 통한 프로그래밍적 호출에 최적화되어 있다 [1, 2, 6].
|
||||
3. **Metadata Injection:** PNG 또는 WebP 이미지 생성 시, tEXt 또는 zTXt 청크 내부에 Frontend 워크플로우와 API 프롬프트 데이터를 직접 삽입하여 이미지를 워크플로우 컨테이너로 활용한다 [7-9].
|
||||
4. **Schema Specification (v1.0):** 노드 ID, 유형, 위치(pos), 크기(size), 실행 순서(order) 및 모드(mode) 등 그래프 무결성을 보장하기 위한 기술적 제약 조건을 정의한다 [10-12].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Bifurcation Pattern (이원화 패턴):** 동일한 로직을 시각적 레이아웃용(Frontend)과 실행용(API)으로 분리하여 저장함으로써 사용자 경험과 API 확장성을 분리하여 관리한다 [1, 2].
|
||||
- **Link Embedding Strategy:** API 포맷에서는 명시적인 연결 객체 대신 노드 입력 필드 내에 '기원 노드 ID'와 '출력 슬롯 인덱스'를 직접 참조(예: `[13, 14]`)하여 그래프 구조를 단순화한다 [1, 15].
|
||||
- **Schema Validation Pattern:** `object_info.json`을 통해 실행 인스턴스의 노드 스키마(입출력 유형, 범위 등)를 카탈로그화하고, 실행 전 `validate_prompt` 함수로 워크플로우의 유효성을 검증한다 [16-18].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **Frontend JSON 구조 및 특징:**
|
||||
- 노드 식별을 위해 고유한 시각적 ID(숫자 문자열)를 사용하며, 노드가 축소되거나 고정되었는지와 같은 시각적 플래그를 유지한다 [1, 19].
|
||||
- `links` 배열을 별도로 두어 노드 간의 물리적 연결 관계를 정의하며, 6개 항목으로 구성된 배열 형식을 통해 기원/대상 노드 및 슬롯 정보를 명시한다 [3, 11, 19].
|
||||
|
||||
- **API JSON 구조 및 특징:**
|
||||
- 불필요한 UI 메타데이터를 제거하여 파일 크기를 압축하고 전송 효율을 높인다 [1, 2, 6].
|
||||
- 키값은 노드 ID로 구성되며, 각 값은 `class_type`과 `inputs`를 포함한 객체이다. 입력 필드에는 위젯 값 또는 다른 노드로부터의 링크 참조가 포함된다 [6, 18, 20].
|
||||
|
||||
- **메타데이터 저장 방식:**
|
||||
- PNG 파일의 경우, ComfyUI는 워크플로우(Frontend)와 프롬프트(API)를 별개의 문자열로 저장한다. 이는 이미지를 UI로 드래그했을 때 시각적 편집이 가능하게 함과 동시에 프로그래밍적 재실행을 가능하게 하는 중복 구조를 제공한다 [8].
|
||||
- 단, 이미지 편집 소프트웨어나 소셜 미디어 플랫폼을 거칠 경우 이러한 비필수 메타데이터 청크가 손실될 위험이 크다 [8, 21].
|
||||
|
||||
- **기타 주요 직렬화 아티팩트:**
|
||||
- `object_info.json`: 실행 중인 ComfyUI 인스턴스의 모든 노드 스키마 등록부로, 입출력 유형, 허용 범위, 툴팁 등을 포함하여 도구 개발이나 입력값 검증에 사용된다 [5, 17, 18].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **하위 호환성 문제:** ComfyUI가 빈번하게 업데이트됨에 따라, 이전 버전에서 생성된 JSON 파일이 최신 버전의 ComfyUI에서 제대로 작동하지 않을 수 있다는 점이 명시되어 있다 [22].
|
||||
- **데이터 유실 가능성:** 이미지 기반 직렬화는 편리하지만, 압축 소프트웨어나 네트워크 전송 시 메타데이터가 제거될 수 있어 JSON 파일 형태의 별도 저장이 권장된다 [8, 22, 23].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **workflow.json & workflow_api.json:** ComfyUI의 표준 저장 포맷으로 사용되며, RunComfy 및 Mystic 등 서버리스 API 배포 플랫폼의 기본 참조 파일로 활용된다 [1, 17, 24].
|
||||
- **object_info.json:** 실행 인스턴스에서 스키마 정보를 추출하기 위해 `https://<server_id>/object_info` 엔드포인트를 통해 접근 가능하다 [25].
|
||||
- **comfyui-workflow-to-api-converter-endpoint:** Frontend 포맷의 워크플로우를 서버 측에서 실시간으로 API 포맷으로 변환하는 기능을 구현한 커스텀 노드 프로젝트이다 [26].
|
||||
- **Git Commit bc85382:** 콤보 위젯 값의 대소문자 표기 오류(예: "True" vs "true")가 유효성 검사에서 거부되는 문제를 해결하기 위해 대소문자 구분 없는 매칭 로직이 적용되었다 [27, 28].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
id: workflow-extractor
|
||||
title: "Workflow Extractor"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["메타데이터 추출기", "Workflow Metadata Recovery"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy-cli", "Weird Wonderful AI Art Extractor", "Comfy_UI_prompt_extractor"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Workflow Extractor]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
생성된 미디어(PNG/WebP)의 메타데이터 청크에 숨겨진 노드 그래프와 실행 로직을 복원하여 워크플로우의 이식성과 재현성을 보장하는 핵심 기술 도구이다. [1-3]
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **메타데이터 임베딩 (Metadata Embedding):** ComfyUI의 `Save Image` 노드는 실행 시 PNG 파일의 숨겨진 메타데이터(tEXt 또는 zTXt 청크) 내에 전체 노드 그래프, 레이아웃, 설정 및 프롬프트를 주입한다. [3-5]
|
||||
- **데이터 이중성 (Data Redundancy):** 메타데이터에는 시각적 편집을 위한 '프론트엔드 포맷(Workflow JSON)'과 실행을 위한 '백엔드/API 포맷(Prompt JSON)'이 동시에 포함되어 재수정 및 재실행을 모두 지원한다. [5, 6]
|
||||
- **메타데이터 취약성 (Fragility of Metadata):** 표준 이미지 편집기, 소셜 미디어 플랫폼 또는 압축 소프트웨어를 거칠 경우 파일 크기 최적화나 개인정보 보호를 위해 해당 JSON 데이터가 삭제될 수 있다. [2, 5, 7]
|
||||
- **알고리즘 기반 복원 (Algorithmic Extraction):** 드래그 앤 드롭 방식이 불가능한 환경이나 대량의 데이터 처리를 위해 CLI 도구나 웹 기반 도구를 사용하여 바이너리 태그에서 워크플로우를 분리해낸다. [8-10]
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **주입 패턴:** 워크플로우의 종단점인 `Save Image` 노드가 실행될 때 최종 이미지에 노드 레이아웃 정보를 주입하는 자동화된 직렬화 패턴을 따른다. [4]
|
||||
- **복원 패턴:** `exiftool`과 같은 범용 도구를 사용하여 바이너리 데이터를 추출하거나, 전용 파이썬 스크립트를 통해 긍정적 프롬프트와 API 그래프를 분리하여 저장하는 패턴이 관찰된다. [8, 10]
|
||||
- **사용자 편의 패턴:** 사용자가 복잡한 추출 과정 없이 이미지를 캔버스에 드래그 앤 드롭하기만 하면 내부 노드 그래프가 즉시 재구성되는 직관적인 UI 인터페이스를 제공한다. [4, 7, 11, 12]
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
워크플로우 추출은 단순한 파일 읽기를 넘어 인공지능 생성 예술의 '소스 코드'를 관리하는 핵심 프로세스이다. ComfyUI는 시각적 프로그래밍 환경으로서의 특성을 유지하기 위해 이미지 자체를 워크플로우의 컨테이너로 활용한다. [3, 13]
|
||||
|
||||
**기술적 메커니즘**
|
||||
PNG 파일의 경우, ComfyUI는 `tEXt` 또는 `zTXt` 청크를 사용하여 워크플로우 정보를 텍스트 문자열로 저장한다. [5] 이 정보는 인간이 읽을 수 있는 JSON 형식을 따르며, 노드 간의 링크, 위치 정보(Frontend), 그리고 백엔드 실행을 위한 입력값(API)을 포함한다. [14-16]
|
||||
|
||||
**추출 도구의 유형**
|
||||
1. **네이티브 복원:** 이미지를 ComfyUI 브라우저 탭으로 직접 드래그하여 현재 노드를 대체하고 레이아웃을 복구한다. [4, 17, 18]
|
||||
2. **웹 기반 추출기:** 'Weird Wonderful AI Art'와 같은 플랫폼은 사용자가 이미지를 업로드하면 서버에 데이터를 저장하지 않고 브라우저단에서 JSON 데이터를 추출하여 다운로드할 수 있게 한다. [2, 19, 20]
|
||||
3. **CLI 및 프로그래밍 도구:**
|
||||
- `exiftool -b -workflow input.png > workflow.json`: 바이너리 태그를 격리하여 저장하는 표준 CLI 방식이다. [8, 10]
|
||||
- `comfyui-extractor.py`: 대량의 디렉토리를 처리하며 프롬프트와 레이아웃을 분리하여 관리한다. [8, 20]
|
||||
- `ComfyUI-to-Python-Extension`: 워크플로우 메타데이터를 포함한 .py 스크립트를 생성하여 드래그 앤 드롭 재가져오기를 지원한다. [21]
|
||||
|
||||
**추출 시의 제한 사항**
|
||||
워크플로우 추출을 통해 그래프를 복원하더라도, 제작자가 사용한 '커스텀 노드'가 현재 시스템에 설치되어 있지 않으면 '빨간색 상자' 오류가 발생한다. [22-24] 이 경우 ComfyUI Manager의 "Install Missing Custom Nodes" 기능을 사용하여 의존성을 해결해야 한다. [23-25]
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **워크플로우 vs 프롬프트:** 소스에 따라 'Workflow' 파일은 모든 노드 위치와 상태를 포함하는 반면, 'Prompt' 파일은 실행에 필요한 노드 정보만을 포함한다고 정의되어 혼동을 피해야 한다. [6]
|
||||
- **업데이트 호환성:** ComfyUI는 빈번하게 업데이트되므로 구버전의 JSON 파일이 최신 버전에서 정상적으로 작동하지 않을 수 있다는 점이 명시되어 있다. [7]
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **comfy-cli (Issue #341):** `exiftool`을 사용하여 이미지 파일(PNG, WebP, MP4 등)에서 워크플로우를 추출, 삽입 및 복사하는 기능을 제안하고 구현 논의를 진행함. [9, 26]
|
||||
- **Weird Wonderful AI Art Extractor:** 온라인 PNG 파일 분석을 통해 사용자에게 JSON 워크플로우와 프롬프트 데이터를 추출해주는 웹 기반 도구로 실서비스 중임. [2, 19]
|
||||
- **ComfyUI Workflow Converter Endpoint:** 서버 측에서 비 API 형식을 API 형식으로 변환하여 실행 가능하도록 지원하며, 하위 그래프(Subgraph) 매핑 등의 복잡한 변환 로직을 포함함(V2.3.0 커밋 기준). [27-29]
|
||||
- **comfymeta:** 이미지를 처리하여 메타데이터를 추출하는 UI 도구로 분류됨. [10]
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: workflow-json-(frontend-format)
|
||||
title: "Workflow JSON (Frontend Format)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["workflow.json"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.90
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow.json", "SethRobinson/comfyui-workflow-to-api-converter-endpoint/bc85382"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Workflow JSON (Frontend Format)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
사용자 인터페이스의 시각적 레이아웃 정보와 노드 그래프의 모든 논리적 연결성을 보존하여 인간 중심의 공유와 편집을 가능케 하는 ComfyUI의 기본 직렬화 규격이다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **시각적 메타데이터 보존 (Visual Metadata Persistence):** 노드의 좌표(`pos`), 크기(`size`), 그룹 구조, 색상 및 노드 접힘 상태(`flags`)와 같은 UI 전용 데이터를 포함한다 [2-5].
|
||||
- **명시적 링크 표현 (Explicit Link Representation):** 노드 입력부에 연결 정보를 내장하는 대신, 별도의 `links` 배열을 통해 시작점과 끝점 슬롯을 정의하는 명시적 연결 객체 형식을 사용한다 [2, 3, 6, 7].
|
||||
- **Litegraph 표준 준수 (Litegraph Standard):** 웹 기반 그래프 시각화 엔진인 Litegraph 형식을 따라 설계되어 브라우저 캔버스에서의 정확한 복원을 보장한다 [2, 7].
|
||||
- **미디어 임베딩 속성 (Media Embedding):** ComfyUI에서 생성된 PNG 또는 WebP 이미지의 메타데이터(tEXt 또는 zTXt 청크)에 직접 주입되어 생성 로직을 운반하는 컨테이너 역할을 수행한다 [8-10].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **직렬화 이원화 (Serialization Bifurcation):** ComfyUI는 시각적 편집용인 'Frontend 포맷'과 서버 실행 최적화용인 'API 포맷'으로 데이터를 분리하여 관리한다 [2].
|
||||
- **중복 데이터 전략 (Redundancy Strategy):** 생성된 이미지 메타데이터 내에 시각적 복원용 `workflow.json`과 실행용 `prompt` 데이터를 동시에 저장하여 상호 보완성을 확보한다 [9].
|
||||
- **역방향 그래프 탐색 (Execution Model Inversion):** 캔버스에 수많은 노드가 존재하더라도 실행 엔진은 출력 노드에서 시작해 필요한 의존성 노드만 역으로 추적하므로, Frontend JSON에 불필요한 노드가 포함되어도 실행 성능에 영향을 주지 않는다 [11].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
Frontend 포맷은 주로 `workflow.json`이라는 파일명으로 사용되며, ComfyUI 웹 인터페이스에서 사용자가 수행하는 'Visual Programming'의 결과를 저장하는 소스 코드와 같은 역할을 한다 [2, 12, 13].
|
||||
|
||||
### 1. 주요 데이터 구조 (Schema v1.0)
|
||||
- **Nodes Array:** 각 노드 객체는 고유 ID, 클래스 타입(`type`), 좌표, 크기, 위젯 값(`widgets_values`), 실행 순서(`order`), 모드(활성/바이패스 등)를 포함한다 [4, 5].
|
||||
- **Links Array:** 6개의 항목으로 구성된 배열 또는 구조화된 객체로, `origin_id`, `origin_slot`, `target_id`, `target_slot`을 정의하여 노드 간의 데이터 흐름을 명시한다 [6].
|
||||
|
||||
### 2. 생성 및 획득 방법
|
||||
- **GUI 수동 내보내기:** 제어 패널 메뉴의 'Export' 옵션 또는 단축키 `Ctrl + S`(macOS는 `Cmd + S`)를 사용하여 현재 캔버스의 상태를 JSON으로 다운로드할 수 있다 [12, 14].
|
||||
- **미디어 메타데이터 추출:**
|
||||
- **드래그 앤 드롭:** ComfyUI에서 생성된 PNG 이미지를 브라우저 캔버스에 직접 끌어다 놓으면 내장된 JSON을 통해 노드 배치가 복원된다 [14-16].
|
||||
- **CLI 도구 활용:** `exiftool -b -workflow input.png > workflow.json` 명령어를 통해 바이너리 태그에서 JSON 데이터를 분리해낼 수 있다 [17, 18].
|
||||
- **웹 도구:** Weird Wonderful AI Art의 'Workflow Extractor'와 같은 브라우저 기반 도구를 통해 온라인 이미지에서 데이터를 추출할 수 있다 [19, 20].
|
||||
|
||||
### 3. API 포맷과의 차별점
|
||||
Frontend 포맷은 인간이 읽기 쉽고 UI를 완벽히 재구성할 수 있도록 설계되었으나, `/prompt` 엔드포인트에 직접 전달할 경우 오류가 발생할 수 있다 [21]. API 호출을 위해서는 UI 메타데이터가 제거되고 노드 간 연결이 입력 필드에 직접 참조된 'API JSON' 형식이 필요하며, 이는 설정에서 'Dev mode'를 활성화해야만 생성 가능하다 [2, 3, 13, 22].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **포맷 호환성 이슈:** ComfyUI는 업데이트가 매우 빈번하여, 구버전에서 생성된 Frontend JSON 파일이 신버전에서 올바르게 작동하지 않거나 노드가 빨간색 박스로 표시되는(Missing Custom Nodes) 현상이 발생할 수 있다 [14, 23].
|
||||
- **데이터 휘발성:** 이미지 편집기(GIMP 등)로 처리하거나 소셜 미디어 플랫폼에 업로드할 경우, 파일 크기 최적화 과정에서 비표준 메타데이터인 Frontend JSON 정보가 삭제되어 워크플로우 복원이 불가능해지는 경우가 많다 [9, 24].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **SethRobinson/comfyui-workflow-to-api-converter-endpoint:** 클라이언트 측의 자바스크립트 변환 로직을 서버 측 파이썬으로 구현하여, `workflow.json`만으로 API 호출이 가능하도록 변환하는 기능을 제공한다 [21, 25].
|
||||
- **ComfyUI-to-Python-Extension:** Frontend JSON 메타데이터를 포함한 파이썬 스크립트를 생성하여, 실행 후 저장된 결과물을 다시 ComfyUI UI로 드래그 앤 드롭하여 복원할 수 있도록 지원한다 [26].
|
||||
- **기본 저장 규칙:** ComfyUI의 `Save Image` 노드는 실행 시 최종 이미지에 전체 노드 그래프와 설정을 주입하며, 이는 `workflow.json` 규격을 따른다 [16].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
id: workflow-json---comfyui
|
||||
title: "Workflow JSON - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["ComfyUI 워크플로우 JSON", "workflow_api.json", "workflow.json"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfyui-workflow-to-api-converter-endpoint/README.md", "pydn/ComfyUI-to-Python-Extension", "DanielPFlorian/ComfyUI-WorkflowGenerator", "deimos-deimos/comfy_api_simplified"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Workflow JSON - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI Workflow JSON은 복잡한 노드 기반 생성 프로세스를 유향 비순환 그래프(DAG) 형태로 직렬화한 청사진으로, 시각적 편집을 위한 **프론트엔드 포맷**과 무두(Headless) 실행 및 자동화를 위한 **API 포맷**으로 이원화되어 관리된다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **프론트엔드 포맷 (workflow.json):** 시각적 편집과 사용자 상호작용을 위해 설계된 포맷으로, 노드의 좌표(`pos`), 크기(`size`), 그룹 구조 및 색상과 같은 UI 메타데이터를 모두 포함한다 [2-4].
|
||||
- **API 포맷 (workflow_api.json):** 백엔드 실행 엔진 최적화를 위해 UI 관련 메타데이터를 제거한 스트림라인드 포맷으로, 노드 입력부 내에 연결 정보가 직접 삽입되는 구조를 가진다 [2, 5, 6].
|
||||
- **메타데이터 임베딩 (Metadata Embedding):** 생성된 PNG/WebP 파일의 `tEXt` 또는 `zTXt` 청크에 JSON 데이터를 주입하여 이미지 자체가 실행 로직을 포함하는 컨테이너 역할을 수행하게 한다 [7, 8].
|
||||
- **JSON 스키마 v1.0:** 유효한 워크플로우를 보장하기 위한 기술적 제약 조건으로, 고유 ID, 클래스 타입, 위젯 값 등의 속성을 정의한다 [9-11].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **이원화 저장 패턴:** 사용자는 UI에서 수정한 내용을 `Save`로 저장(프론트엔드)하고, 외부 연동을 위해 `Dev Mode`를 활성화하여 `Save (API Format)`으로 내보낸다 [12-15].
|
||||
- **역방향 그래프 탐색 (Execution Model Inversion):** 백엔드 엔진이 출력 노드(Save Image 등)로부터 역방향으로 의존성을 추적하여 실제 실행에 필요한 노드만 식별하고 나머지는 무시하는 최적화 패턴을 사용한다 [16].
|
||||
- **입력값 교체 패턴 (Prompt Injection):** Python 등 프로그래밍 환경에서 템플릿 JSON을 로드한 후, 특정 노드 ID의 `inputs` 딕셔너리를 직접 수정하여 시드(seed)나 프롬프트를 동적으로 변경한다 [17-19].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
### 1. 생성 및 추출 방법론
|
||||
- **GUI 기반 생성:** 기본 인터페이스의 컨트롤 패널에서 `Ctrl + S`를 통해 프론트엔드 JSON을 저장할 수 있다 [12]. API 포맷을 생성하려면 설정 메뉴에서 'Enable Dev mode Options'를 활성화해야 한다 [13, 14, 20].
|
||||
- **이미지 메타데이터 추출:** ComfyUI에서 생성된 이미지를 캔버스에 드래그 앤 드롭하거나 [21-23], `ExifTool`을 사용하여 `exiftool -b -workflow input.png > workflow.json` 명령어로 바이너리 데이터를 추출할 수 있다 [24, 25].
|
||||
- **자동화 도구:** `comfyui-workflow-to-api-converter-endpoint`와 같은 커스텀 노드는 서버 측에서 프론트엔드 형식을 API 형식으로 실시간 변환하는 엔드포인트를 제공한다 [26-28].
|
||||
|
||||
### 2. 프로그래밍적 제어 및 변환
|
||||
- **Python 통합:** 워크플로우 JSON은 중첩된 딕셔너리 구조이므로 Python의 `json` 라이브러리로 쉽게 조작 가능하다 [17]. `ComfyUI-to-Python-Extension`은 JSON을 아예 독립적인 실행 파일(.py)로 변환해주기도 한다 [29-31].
|
||||
- **LLM 기반 생성:** `ComfyUI-WorkflowGenerator`는 자연어 설명을 입력받아 LLM(Qwen2.5 등)이 논리 구조를 합성하고, 유효성 검사(Validator)를 거쳐 최종 JSON을 빌드하는 3단계 파이프라인을 사용한다 [32-35].
|
||||
|
||||
### 3. 데이터 구조 분석 (v1.0 기준)
|
||||
- **노드 객체 속성:** 각 노드는 고유 `id`, 노드 클래스 매핑을 위한 `type`, 실행 순서를 결정하는 `order`, 그리고 사용자 입력값인 `widgets_values`를 보유한다 [4, 9].
|
||||
- **연결 구조:** 프론트엔드에서는 별도의 `links` 배열을 통해 연결을 정의하지만, API 포맷에서는 노드의 `inputs` 내부에 `[origin_id, output_slot_index]` 형태의 참조를 직접 기록한다 [2, 3, 36, 37].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **버전 호환성:** ComfyUI가 빈번하게 업데이트됨에 따라 구버전 JSON 파일이 최신 UI에서 정상적으로 작동하지 않을 수 있다는 경고가 존재한다 [38].
|
||||
- **메타데이터 손실:** 소셜 미디어 플랫폼이나 이미지 압축 소프트웨어는 종종 이미지 내의 JSON 메타데이터 청크를 삭제하여 워크플로우 정보를 소실시킨다 [8, 38].
|
||||
- **API 포맷의 비가역성:** API 포맷으로 내보낸 JSON을 다시 UI로 불러올 경우 시각적 레이아웃 정보(좌표, 그룹 등)가 유실되어 편집이 매우 어려워진다 [26, 39].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **comfyui-workflow-to-api-converter-endpoint (SethRobinson):** `/workflow/convert` 엔드포인트를 통해 비 API 워크플로우를 API 포맷으로 서버사이드 변환 수행. **commit `bc85382`**에서 콤보 위젯 대소문자 정규화 로직 적용 [40-42].
|
||||
- **ComfyUI-WorkflowGenerator (DanielPFlorian):** LLM을 활용하여 자연어 지시문을 워크플로우 JSON으로 변환하는 파이프라인 구현. **commit `82df278`**에서 드롭다운 중복 모델 문제 해결 [34, 43, 44].
|
||||
- **ComfyUI-to-Python-Extension (pydn):** JSON 워크플로우를 실행 가능한 Python 코드로 번역. **commit `6cdcc23`**에서 설치 문제 해결 및 README 업데이트 [30, 31, 45].
|
||||
- **comfy_api_simplified:** 노드 제목(title)을 기반으로 파라미터를 설정하여 숫자 ID에 의존하지 않는 안정적인 API 제어 방식 구현 [29, 46, 47].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 발견으로 검증 수준 높음)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
id: workflow.api.json-(backend-format)
|
||||
title: "Workflow.api.json (Backend Format)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["API Format", "Backend JSON", "workflow_api.json"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["Mystic Pipeline", "Replicate (fofr/any-comfyui-workflow)", "ComfyUI-to-Python-Extension", "comfyui-workflow-to-api-converter-endpoint"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Workflow.api.json (Backend Format)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
비주얼 메타데이터를 배제하고 노드 실행 로직에만 집중하여 서버측 자동화와 프로그래밍적 실행을 가능케 하는 최적화된 데이터 포맷 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **실행 그래프 (Execution Graph):** UI 관련 데이터(좌표, 크기, 그룹 등)를 제거하고 백엔드 엔진이 프롬프트를 실행하는 데 필요한 필수 로직만 남긴 스트림라인화된 구조 [1, 4].
|
||||
- **임베디드 참조 (Embedded References):** 링크 정보가 별도의 객체가 아니라 노드 입력(inputs) 필드 내에 소스 노드 ID와 출력 슬롯 인덱스의 리스트(예: `[node_id, slot_index]`) 형태로 직접 포함됨 [1, 2, 5].
|
||||
- **딕셔너리 구조 (Dictionary Mapping):** 노드 ID를 최상위 키로 사용하며, 각 값은 `class_type`과 `inputs`를 포함하는 객체로 구성된 단일 JSON 객체 형식 [6, 7].
|
||||
- **개발자 모드 의존성 (Developer Mode Dependency):** 표준 웹 UI에서는 숨겨져 있으며, 설정에서 'Enable Dev mode Options'를 활성화해야만 'Save (API Format)' 메뉴가 노출됨 [8-11].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **UI 데이터 스트리핑 (UI Data Stripping):** 캔버스 레이아웃 정보를 삭제함으로써 파일 크기를 축소하고 API 호출의 효율성을 극대화하는 설계 패턴 [1, 2, 4].
|
||||
- **노드 ID 키잉 (Node ID Keying):** 숫자 문자열(예: "5", "37")을 키로 사용하여 유연한 그래프 트래버스 및 특정 노드 파라미터의 동적 오버라이드를 지원 [6, 7, 12].
|
||||
- **입력값 치환 (Input Value Substitution):** Python 등의 언어에서 JSON을 로드한 후 특정 노드 ID의 `inputs` 필드를 직접 수정하여 시드, 프롬프트, 이미지 경로 등을 변경하는 방식의 자동화 패턴 [6, 12, 13].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
**형식적 특성 및 구조**
|
||||
Workflow API JSON은 Litegraph 표준을 따르는 프런트엔드 형식(`workflow.json`)과 달리 ComfyUI 백엔드의 `/prompt` 엔드포인트와 직접 통신하기 위해 설계되었습니다 [1, 2]. 파일 내부의 각 항목은 고유한 노드 식별자를 키로 하며, 해당 노드가 어떤 클래스(`class_type`)인지와 어떤 입력값(`inputs`)을 사용하는지를 명시합니다 [4, 7]. 이때 입력값에는 위젯의 직접적인 값뿐만 아니라 다른 노드로부터 오는 연결 정보도 포함됩니다 [5].
|
||||
|
||||
**생성 및 추출 방법**
|
||||
- **GUI 내보내기:** ComfyUI 설정 메뉴(톱니바퀴 아이콘)에서 'Enable Dev mode Options'를 체크한 후 사이드바 메뉴에 나타나는 'Save (API Format)' 버튼을 클릭하여 생성합니다 [8-11].
|
||||
- **이미지 메타데이터:** ComfyUI가 생성한 PNG 파일의 `tEXt` 또는 `zTXt` 청크에는 프런트엔드 워크플로우와 함께 'prompt'라는 이름으로 API 포맷의 JSON이 포함되어 자동 저장됩니다 [14, 15].
|
||||
- **서버측 변환:** `comfyui-workflow-to-api-converter-endpoint`와 같은 커스텀 노드를 사용하면 클라이언트 측의 자바스크립트 로직 없이도 서버에서 직접 일반 JSON을 API 포맷으로 변환할 수 있습니다 [16, 17].
|
||||
|
||||
**활용 시나리오**
|
||||
이 포맷은 주로 외부 애플리케이션 통합에 사용됩니다. 예를 들어 Python 스크립트에서 워크플로우 템플릿을 로드하고 특정 노드의 텍스트 입력을 변경한 후 ComfyUI 서버에 큐잉하거나, Replicate와 같은 클라우드 환경에서 워크플로우를 실행하는 데 필수적입니다 [6, 12, 18, 19].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **가독성 vs 효율성:** API 포맷은 파일 크기가 작고 처리가 빠르지만, UI로 다시 드래그 앤 드롭했을 때 시각적 구조(노드 위치, 그룹화 등)가 복원되지 않는 "뼈대만 남은(skeleton)" 상태가 됩니다 [1, 20].
|
||||
- **노드 ID의 취약성:** 워크플로우를 UI에서 편집하면 노드 ID가 변경될 수 있으며, 이로 인해 특정 ID를 하드코딩한 자동화 스크립트가 깨질 위험이 존재합니다 [6, 21]. 이를 해결하기 위해 노드 타이틀 기반 접근 방식이 대안으로 제시되기도 합니다 [21, 22].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Mystic Deployment:** `pipeline.yaml`과 함께 `new_pipeline.py`에서 API JSON을 로드하여 입력 프롬프트를 주입하고 서버를 실행하는 구조로 적용됨 [23, 24].
|
||||
- **Replicate API:** `fofr/any-comfyui-workflow` 모델을 통해 API JSON 블롭을 전달받아 이미지를 생성하는 상용 서비스에 적용 [18, 25].
|
||||
- **ComfyUI-to-Python-Extension:** `workflow_api.json` 파일을 입력받아 독립 실행 가능한 `.py` 스크립트로 변환하는 CLI 도구에서 핵심 데이터로 사용됨 [26, 27].
|
||||
- **Workflow Converter:** 서버측 `/workflow/convert` 엔드포인트를 통해 비 API 워크플로우를 API 포맷으로 실시간 변환하여 Unity 기반 AI 도구 등에서 활용 [16, 17].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 확인됨)
|
||||
- **출처 신뢰도:** B (Official Documentation / RunComfy & Replicate API Docs / GitHub Repository READMEs)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
id: workspace-packaging-(.cpack.zip)
|
||||
title: "Workspace Packaging (.cpack.zip)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy-pack"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Workspace Packaging (.cpack.zip)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
워크플로 JSON, 모델 해시, 커스텀 노드 버전을 단일 아카이브로 통합하여 환경 변화에 무관한 완벽한 실행 재현성을 보장하는 표준화된 배포 아티팩트 규격이다 [1].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **표준화된 아티팩트 배포:** 단순한 JSON 파일에 대한 의존성을 넘어, 실행에 필요한 모든 메타데이터를 포함하는 아티팩트 기반 배포 방식이다 [1].
|
||||
2. **패키지 구성 요소:** .cpack.zip 파일 내에는 워크플로 JSON, 모델의 SHA-256 해시값, 그리고 실행에 필요한 커스텀 노드의 특정 버전 정보가 포함된다 [1].
|
||||
3. **모델 해싱(SHA-256):** 모델 파일명에 의존하는 대신 해시값을 사용하여 서로 다른 시스템 환경에서도 정확한 모델을 식별하고 로드한다 [2].
|
||||
4. **미래 지향적 유지보수:** 특정 노드가 업데이트되거나 삭제되더라도 패키지 내 기록된 버전을 통해 생성 시점과 동일한 워크플로 기능을 유지한다 [1].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **논리 및 의존성의 완전 캡슐화:** 워크플로의 실행 논리(JSON)와 그 실행을 뒷받침하는 의존성(모델, 노드)을 하나의 단위로 묶어 관리하는 패턴이다 [1, 3].
|
||||
- **파일 이름에서 내용 기반 식별로의 전환:** 경로 정보나 파일명이 아닌 데이터 고유의 해시값을 통해 리소스를 관리하여 이식성을 극대화한다 [2].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로 생성의 미래는 원본 JSON 파일만 공유하던 방식에서 벗어나 표준화된 **아티팩트 기반 배포(Artifact-based deployments)**로 이동하고 있다 [1]. 기존의 JSON 방식은 다른 사용자의 환경에서 모델 파일명이 다르거나 커스텀 노드 버전이 일치하지 않을 때 실행이 실패하는 고질적인 문제를 안고 있었다 [1, 2].
|
||||
|
||||
Workspace Packaging 규격인 **.cpack.zip**은 이러한 문제를 해결하기 위해 고안되었다 [1]. 이 아카이브 파일은 단순한 압축 파일이 아니라, 워크플로의 실행 환경을 정의하는 고밀도 정보를 담고 있다 [1]. 구체적으로, 생성 시점에 사용된 워크플로 JSON과 함께, 각 모델의 **SHA-256 해시값**을 기록하여 파일명이 다르더라도 로컬 시스템에서 동일한 모델을 찾아낼 수 있게 한다 [2]. 또한, 실행에 필요한 커스텀 노드들의 **특정 버전 정보**까지 포함하여, 시간이 지나 노드가 업데이트되거나 더 이상 지원되지 않더라도 생성 당시의 기능을 보존한다 [1].
|
||||
|
||||
이러한 방식은 ComfyUI를 전문적인 제작 파이프라인에 통합하는 데 필수적이며, 오디오, 비디오, 3D 및 AI 에이전트가 결합되는 복잡한 시스템 간의 통신에서 공통 언어 역할을 수행한다 [3].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **JSON의 한계 극복:** 소스에 따르면 현재의 워크플로 생성 방식은 원시 JSON에 의존하고 있으나, 이는 이식성 면에서 취약하며 점차 .cpack.zip과 같은 워크스페이스 패키징 방식으로 보완 또는 대체되는 추세이다 [1].
|
||||
- **최신 정보:** 소스 데이터 작성 시점 기준으로 .cpack.zip은 "Future Outlook"으로 언급되며 차세대 표준으로 제시되고 있다 [1].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **comfy-pack:** 모델의 파일명 대신 SHA-256 해시를 사용하여 정확한 모델 위치를 식별하고 관리하는 고급 직렬화 도구로 언급된다 [2].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (comfy-pack 등 실제 도구에서 해시 기반 관리 방식이 이미 적용되어 있음 [2])
|
||||
- **출처 신뢰도:** B (Comprehensive Architectures for ComfyUI Workflow JSON Generation and Serialization 문서 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
id: object_info.json
|
||||
title: "object_info.json"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["https://<server_id>-comfyui.runcomfy.com/object_info", "RunComfy Serverless API"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[object_info.json]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
실행 중인 ComfyUI 인스턴스 내 모든 노드의 입출력 규격과 제약 조건을 정의하는 핵심 스키마 레지스트리 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **스키마 카탈로그 (Schema Catalog):** 현재 실행 중인 ComfyUI 인스턴스에 설치된 모든 노드(내장 및 커스텀 노드 포함)의 상세 사양을 담고 있는 청사진이다 [2].
|
||||
- **데이터 타입 및 범위 정의:** 각 노드가 요구하는 필수/선택적 입력값의 종류, 허용되는 수치 범위(Min/Max), 기본값, 그리고 출력 데이터의 타입을 명시한다 [2, 3].
|
||||
- **동적 엔드포인트 정보:** 서버 실행 중에 `/object_info` 경로를 통해 실시간으로 획득할 수 있는 동적 데이터이다 [4].
|
||||
- **유효성 검사 기준:** 외부 애플리케이션이나 사용자 정의 UI에서 입력 데이터를 검증하거나 워크플로우를 프로그래밍 방식으로 수정할 때 참조하는 기준점이 된다 [4, 5].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **서버 기반 동적 쿼리 패턴:** 고정된 파일이 아니라, 현재 서버 환경에 설치된 커스텀 노드 상태를 반영하기 위해 서버 ID 기반의 특정 URL 엔드포인트를 통해 데이터를 추출하는 방식을 취한다 [4].
|
||||
- **입력 유효성 선행 검증 패턴:** API를 통해 워크플로우를 실행하기 전, 이 JSON의 스키마 정보를 활용하여 파라미터 오버라이드 값이 노드의 수용 범위를 준수하는지 사전에 확인한다 [4, 5].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
`object_info.json`은 ComfyUI 서버가 현재 운용 가능한 모든 노드 클래스에 대한 지식 데이터베이스 역할을 수행한다 [2]. 이 파일은 크게 다음과 같은 정보를 포함한다.
|
||||
- **노드 입력 사양:** 필수(required) 및 선택(optional) 입력 항목을 구분하며, 각 입력 항목의 데이터 타입(예: STRING, INT, IMAGE)과 위젯 값의 범위, 기본값 등을 정의한다 [2, 3]. 이는 내부적으로 노드의 `INPUT_TYPES()` 함수 정보에서 기인한다 [3].
|
||||
- **노드 출력 사양:** 해당 노드가 실행 결과로 생성하는 데이터 스트림의 타입을 정의하여 다른 노드와의 연결 가능 여부를 판단하게 한다 [2].
|
||||
- **메타데이터 및 보조 정보:** 노드에 대한 툴팁이나 개발자용 메타데이터 정보를 포함하여, 외부 도구가 노드의 기능을 이해하고 사용자에게 설명할 수 있도록 돕는다 [2].
|
||||
|
||||
이 파일은 특히 **서버리스 API 배포** 환경에서 중요한 역할을 하며, 개발자는 이를 통해 자신만의 사용자 인터페이스를 구축하거나 워크플로우를 동적으로 생성 및 수정하는 도구를 제작할 수 있다 [1, 4]. 실행 중인 서버에서 직접 데이터를 가져오는 방식이 권장되며, 이는 설치된 커스텀 노드의 변경 사항을 즉각적으로 반영하기 위함이다 [4].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
소스 데이터 내에서 직접적인 정보 상충은 발견되지 않았으나, `object_info.json`은 정적인 아카이브 파일이 아니라 실행 환경에 따라 내용이 변하는 **동적 레지스트리** 성격을 가진다는 점이 명확히 기술되어 있다 [1, 4]. 또한, 커스텀 노드 제작 시 `INPUT_TYPES()` 정의가 부정확하면 이 JSON의 신뢰성도 저하될 수 있음을 시사한다 [3].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **RunComfy 플랫폼:** 서버리스 API 배포 시 워크플로우 검증 및 UI 구성을 위한 핵심 파일로 사용된다 [1, 5].
|
||||
- **데이터 추출 엔드포인트:** 실제 서버 환경에서 `https://<server_id>-comfyui.runcomfy.com/object_info` 경로를 통해 이 데이터를 획득할 수 있도록 구현되어 있다 [4].
|
||||
- **comfy_api_simplified MCP 서버:** AI 에이전트가 노드 유형을 나열(`list_node_types`)하거나 특정 노드의 상세 정보(`get_node_type_info`)를 조회할 때 이 스키마 정보를 기반으로 툴 기능을 제공한다 [6].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
id: add-node-docs-for-your-comfyui-custom-node---comfyui
|
||||
title: "Add node docs for your ComfyUI custom node - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/help_page"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Add node docs for your ComfyUI custom node - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[ComfyUI]] 커스텀 노드 개발자는 마크다운(Markdown) 파일을 활용하여 노드의 기능, 파라미터, 사용법을 포함한 풍부한 문서를 UI 내에 직접 구현할 수 있습니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Rich Markdown Documentation**: 일반적인 노드 설명을 넘어 [[HTML]] 요소와 마크레이 형식을 사용하여 상세한 정보를 사용자에게 제공합니다.
|
||||
- **Multi-language Support**: 언어별(영어, 중국어 등) 폴더 구조를 통해 다국어 문서를 지원하며, 사용자의 로케일에 따라 자동 로드됩니다.
|
||||
- **Automated Fallback System**: 특정 언어의 문서가 없을 경우 기본값인 `NodeName.md`를 참조하도록 설계되었습니다.
|
||||
- **Integrated UI Display**: 별도의 외부 페이지 없이 [[ComfyUI]] 인터페이스 내에서 직접 노드 문서를 확인할 수 있습니다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **계층적 문서 구조**: `WEB_DIRECTORY/docs/` 하위에 노드 이름을 따르는 폴더와 파일을 배치하는 정형화된 디렉토리 구조를 가집니다.
|
||||
- **확장 가능한 마크다운 기능**: 표준 문법 외에도 이미지(`![]()`) 및 특정 속성을 가진 `<video>` 태그 등 HTML 요소를 결합하여 풍부한 콘텐츠를 구성합니다.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 🛠️ Setup (설정 방법)
|
||||
문서를 추가하기 위해서는 `WEB_DIRECTORY` 내에 `docs` 폴더를 생성하고 다음과 같은 규칙으로 파일을 배치해야 합니다.
|
||||
|
||||
| 파일 경로 예시 | 설명 |
|
||||
| :--- | :--- |
|
||||
| `WEB_DIRECTORY/docs/NodeName.md` | 기본(Fallback) 문서 (노드 이름은 `NODE_CLASS_MESSAGES`의 키값과 일치해야 함) |
|
||||
| `WEB_DIRECTORY/docs/NodeName/en.md` | 영어 문서 |
|
||||
| `WEB_DIRECTORY/docs/NodeName/zh.md` | 중국어 문서 |
|
||||
| 기타 로케일 (예: `fr.md`, `de.md`) | 필요한 언어 추가 가능 |
|
||||
|
||||
### 📝 Supported Markdown Features (지원되는 마크다운 기능)
|
||||
- **Standard Syntax**: 헤딩(Headings), 리스트(Lists), 코드 블록(Code blocks) 등 표준 문법 지원.
|
||||
- **Images**: `` 형식을 통한 이미지 삽입 가능.
|
||||
- **HTML Media Elements**: `<video>` 및 `<source>` 태그 사용 가능.
|
||||
- 허용된 속성: `controls`, `autoplay`, `loop`, `muted`, `preload`, `poster`
|
||||
|
||||
### 📂 Example Structure (디렉토리 구조 예시)
|
||||
커스텀 노드 패키지 내의 권장 구조는 다음과 같습니다.
|
||||
```text
|
||||
my-custom-node/
|
||||
├── __init__.py
|
||||
├── web/ # WEB_DIRECTORY
|
||||
│ ├── js/
|
||||
│ │ └── my-node.js
|
||||
│ └── docs/
|
||||
│ ├── MyNode.md (기본 문서)
|
||||
│ └── MyNode/
|
||||
│ ├── en.md (영어 버전)
|
||||
│ └── zh.md (중국어 버전)
|
||||
```
|
||||
|
||||
## ⚖️ 모다 및 업데이트 (Contradictions & updates)
|
||||
- 본문 내 정보 간의 상충되는 내용은 발견되지 않았습니다.
|
||||
- `ContextWindowsManualNode`와 관련하여, 이미 파라미터에 툴팁을 추가했다면 추가적인 노드 문서 없이도 정보를 참조할 수 있다는 구현 관련 언급이 있습니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Example Markdown File**: 실제 작성 가능한 마크다운 파일의 예시로, 파라미터(`image`, `strength`), 사용법 설명, 이미지 및 비디오 태그가 포함된 구조를 제시하고 있습니다.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[ComfyUI]] : 문서를 적용할 대상인 커스텀 노드 프레임워크입니다.
|
||||
- [[NODE_CLASS_MAPPINGS]] : 노드를 등록할 때 사용하는 딕셔너리로, 문서 파일명 결정의 기준이 됩니다.
|
||||
- [[WEB_DIRECTORY]] : 문서 파일이 위치해야 하는 웹 디렉토리 경로를 정의합니다.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/help_page 본문에서 초안 생성.
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
id: annotated-examples---comfyui
|
||||
title: "Annotated Examples - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/snippets"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Annotated Examples - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[ComfyUI]]의 기능 구현을 위한 이미지, 마스크, 노이즈 처리 관련 코드 예제 및 구현 방법론을 제공한다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Images and Masks**: [[Load an image]], [[Save an image batch]], [[Invert a mask]] 등 이미지와 마스크 데이터의 조작 기법.
|
||||
- **Mask Transformation**: 마스크를 특정 형태(`[B,H,W,C]`)로 변환하거나 투명도 레이어(Transparency Layers)로 활용하는 방법.
|
||||
나머지 개념은 코드 구현을 위한 구체적인 로직과 [[Noise]] 생성 전략을 포함함.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **데이터 정규화 및 변환**: 이미지를 처리할 때 `exif_transpose`를 적용하거나, 마스크의 범위를 `[0,1]`로 정규화하여 연산하는 패턴.
|
||||
- **차원 확장(Dimension Expansion)**: 마스크 데이터의 형태가 불일치할 경우 `None` 또는 `unsqueeze`를 사용하여 채널(`C`)이나 배치(`B`) 차원을 맞추는 구조적 접근.
|
||||
- **가중치 기반 혼합**: 두 개의 노이즈 소스를 `weight2` 값을 통해 선형 결합하여 변동성을 생성하는 방식.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 🖼️ Images and Masks 구현 예제
|
||||
|
||||
#### [[Load an image]]
|
||||
[[LoadImage]]의 소스 코드를 기반으로, 이미지를 배치 크기 1로 로드하는 과정입니다.
|
||||
- `Image.open`을 통해 경로에서 이미지를 불러온 후 `exif_transpose`를 적용합니다.
|
||||
- 모드가 `'I'`인 경우 값을 `1/255`로 스케일링합니다.
|
||||
- 최종적으로 `torch.from_numpy`를 사용하여 `float32` 타입의 텐서로 변환하며, 배치 차원을 추가합니다.
|
||||
|
||||
#### [[Save an image batch]]
|
||||
[[SaveImage]] 소스 코드를 기반으로, 이미지 배치를 저장하는 과정입니다.
|
||||
- 각 이미지에 대해 `cpu().numpy()`를 통해 넘파이 배열로 변환합니다.
|
||||
- `np.clip`을 사용하여 값을 `[0, 255]` 범위로 제한하고 `uint8` 타입으로 변환합니다.
|
||||
- 지정된 경로(`filepath`)에 저장합니다.
|
||||
|
||||
#### [[Invert a mask]]
|
||||
마스크를 반전시키는 단순 프로세스입니다. 마스크는 `[0,1]` 범위로 정규화되어 있으므로 다음과 같이 계산합니다.
|
||||
- `mask = 1.0 - mask`
|
||||
|
||||
#### [[Convert a mask to Image shape]]
|
||||
마스크의 형태를 `[B, H, W, C]` 구조(C=1)로 맞추기 위한 조건부 차원 확장 로직입니다.
|
||||
- `len(mask.shape)==2` (H,W): `[None, :, :, None]` 적용.
|
||||
- `len(mask.shape)==3` 및 `C=1` (H,W,C): `[None, :, :, :]` 적용.
|
||||
- `len(mask.shape)==3` (B,H,W): `[:, :, :, None]` 적용.
|
||||
|
||||
#### [[Using Masks as Transparency Layers]]
|
||||
마스크를 인페인팅이나 세그멘테이션의 투명 레이어로 활용하는 방법입니다.
|
||||
- 마스크 값을 반전시켜 원래의 투명도 레이어로 복구하거나, 채널(`C`) 차원을 `unsqueeze(-1)`로 확장합니다.
|
||||
- `torch.cat`을 사용하여 RGB 이미지와 마스크를 채널 축(`dim=-1`)을 따라 결합하여 RGBA 이미지를 생성할 수 있습니다.
|
||||
|
||||
### 🔊 Noise Generation
|
||||
#### [[Creating noise variations]]
|
||||
두 가지 노이즈 소스를 혼합하여 새로운 노이즈 객체를 생성하는 예제입니다.
|
||||
- `Noise_MixedNoise` 클래스는 `noise1`, `noise2`, 그리고 가중치 `weight2`를 속성으로 가집니다.
|
||||
- `generate_noise` 메서드는 `noise1 * (1.0 - self.weight2) + noise2 * self.weight2` 공식을 통해 혼합된 노이즈를 생성합니다.
|
||||
|
||||
## ⚖️ 모의 및 업데이트 (Contradictions & updates)
|
||||
본문에서 확인되지 않음
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **이미지 처리 파이프라인**: `torch.Tensor` 기반의 이미지 로드, 변환, 저장 로직 구현 시 활용 가능.
|
||||
- **마스크 조작**: 인페인팅(Inpainting)을 위한 마스크 투명도 레이어 생성 및 차원 재구성 작업.
|
||||
- **노이즈 제어**: 가중치 조절을 통한 노이즈 변동성(Noise variations) 생성 실험.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[ComfyUI]] : 이 문서의 기반이 되는 소프트웨어 프레임워크입니다.
|
||||
- [[LoadImage]] : 이미지 로드 로직의 핵심 노드 구현체입니다.
|
||||
- [[SaveImage]] : 이미지 저장 로직의 핵심 노드 구현체입니다.
|
||||
- [[torch.Tensor]] : 데이터 처리에 사용되는 주요 텐서 구조입니다.
|
||||
- [[Inpainting]] : 마스크를 활용하는 구체적인 작업 사례입니다.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/snippets 본문에서 초안 생성.
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
id: comfyui-mcp-server---comfyui
|
||||
title: "ComfyUI MCP Server - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/development/cloud/mcp-server"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[ComfyUI MCP Server - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[Model Context Protocol]] (MCP)를 통해 AI 에이전트([[Claude]], [[Cursor]] 등)를 [[Comfy Cloud]]와 연결하여 로컬 GPU 없이 클라우드에서 워크플로우를 실행하고 이미지를 생성하는 서버 서비스입니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
* **[[Model Context Protocol]] (MCP) 연동**: AI 어시스턴트가 [[Comfy Cloud]]의 기능을 사용할 수 있도록 도구(Tools)와 리소스를 연결합니다.
|
||||
* **클라우드 기반 실행**: 로컬 GPU 설치 없이 클라우드 GPU를 활용하여 워크로드를 처리하며, API 키를 통해 인증합니다.
|
||||
* **자동화된 워크플로우 생성**: AI 에이전트가 자연어 명령을 바탕으로 [[ComfyUI]] API 형식의 JSON 워크플로우를 구성하고 실행합니다.
|
||||
* **Discovery & Execution**: 템플릿, 모델, 노드를 검색하는 기능과 작업 제출, 파일 업로드, 상태 확인 등의 실행 도구를 제공합니다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
* **Client-Server 구조**: MCP 클라이언트(Claude Desktop, Cursor 등)가 지정된 URL(`https://cloud.comfy.org/mcp`)로 접속하여 기능을 호출하는 방식입니다.
|
||||
* **도구 중심의 기능 분할**:
|
||||
* `Discovery`: 검색 및 탐색 도구
|
||||
* `Execution`: 워크플로우 실행 및 관리 도구
|
||||
* `Saved Workflows`: 저장된 워크플로우 관리 도구
|
||||
* **단계별 설정 프로세스**: API 키 발급 $\rightarrow$ 클라이언트 연결 설정 $\rightarrow$ 서버 URL 및 헤더(X-API-Key) 구성 순으로 진행됩니다.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 🛠️ Available Tools (사용 가능한 도구)
|
||||
|
||||
#### 1. Discovery (탐색)
|
||||
| Tool | Description |
|
||||
| :--- | :--- |
|
||||
| `search_templates` | 텍text, 태그, 미디어 유형 또는 모델을 통해 미리 구축된 워크플Longrightarrow 템플릿 검색 |
|
||||
| `search_models` | 텍스트, 타입, 베이스 모델 또는 소스를 통해 모델 카탈로그 검색 |
|
||||
| `search_nodes` | 텍스트, 카테고리 또는 입/출력 유형을 통해 사용 가능한 노드 검색 |
|
||||
|
||||
#### 2. Execution (실행)
|
||||
| Tool | Description |
|
||||
| :--- | :--- |
|
||||
| `submit_workflow` | Comfy Cloud에서 실행할 ComfyUI API 형식의 워크플로우 제출 |
|
||||
| `upload_file` | 워크플로우(예: LoadImage)에서 사용할 입력 이미지 또는 파일 업로드 |
|
||||
| `get_job_status` | 제출된 워크플로우의 실행 상태 폴링(Polling) |
|
||||
| `get_output` | 완료된 워크플로우로부터 출력 이미지, 비디오 또는 오디오를 가져옴 |
|
||||
| `use_previous_output` | 하나의 출력을 다른 것의 입력으로 재사용하여 워크플로우 체인 형성 |
|
||||
| `cancel_job` | 대기 중이거나 실행 중인 작업 취소 |
|
||||
| `get_queue` | 실행 중이거나 대기 중인 작업 수 확인 |
|
||||
|
||||
#### 3. Saved Workflows (저장된 워크플로우)
|
||||
| Tool | Description |
|
||||
| :--- | :--- |
|
||||
| `list_saved_workflows` | Comfy Cloud에서 저장된 워크플로우 목록 탐색 |
|
||||
| `get_saved_workflow` | 저장된 워크플릿의 노드, 입력 및 구성을 검사 |
|
||||
|
||||
### 🚀 Quick Start (빠른 시작)
|
||||
1. **API Key 발급**: [platform.comfy.org](https://platform.comfy.org/login) 접속 $\rightarrow$ 로그인 $\rightarrow$ `+ New` 클릭 $\rightarrow$ 이름 입력 $\rightarrow$ 생성 및 즉시 저장(재확인 불가).
|
||||
2. **클라이언트 연결**:
|
||||
* 서버 URL: `https://cloud.comfy.org/mcp`
|
||||
* 설정 예시 (Claude Code):
|
||||
```bash
|
||||
claude mcp add comfyui-cloud \
|
||||
--transport http \
|
||||
https://cloud.comfy.org/mcp \
|
||||
-H "X-API-Key: your-api-key-here"
|
||||
```
|
||||
|
||||
### ⚠️ Known Limitations (알려진 제한 사항)
|
||||
* **워크플로우 실행**: 저장된 워크플로우 ID로 직접 실행 불가(브라우징만 가능). 에이전트가 처음부터 재구성해야 함.
|
||||
* **메타데이터 부재**: 생성된 자산에 워크플로우 JSON 메타데이터가 포함되지 않음.
|
||||
* **정확도 의존성**: 복잡한 노드 구성은 AI의 자연어 처리 능력에 따라 반복 작업이 필요할 수 있음.
|
||||
* **인증**: API Key 방식만 지원하며, OAuth는 아직 미지원.
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
* **연구 프리뷰(Research Preview)**: 현재 이 프로젝트는 제한된 초기 액세스(Limited Early Access) 상태이며, 기능과 동작이 변경될 수 있습니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
* **Example Prompts**:
|
||||
* "우주를 떠다니는 우주비행사 고양이 이미지 생성 (카툰 스타일)"
|
||||
* "텍스트-비디오 생성을 위한 워크플로우 템플릿 찾기"
|
||||
* "SDXL 체크포인트 모델 검색 및 가용성 확인"
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
* [[Comfy Cloud]] - MCP 서버가 연결되는 대상 클라우드 인프라입니다.
|
||||
* [[Model Context Protocol]] - AI 에이전트와 서버를 연결하는 표준 프로토콜입니다.
|
||||
* [[Claude Desktop]] - MCP 서버를 사용할 수 있는 주요 클라이언트 중 하나입니다.
|
||||
* [[Cursor]] - MCP 서버를 통해 워크플로우 실행이 가능한 AI 코드 에디터입니다.
|
||||
* [[ComfyUI API Format]] - 에이전트가 생성해야 하는 워크플로우의 데이터 규격입니다.
|
||||
|
||||
## 📝 변경 이履歴 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/development/cloud/mcp-server 본문에서 초안 생성.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
id: data-lists---comfyui
|
||||
title: "Data lists - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/lists"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Data lists - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI 서버는 데이터 흐름을 Python 리스트로 관리하며, `INPUT_IS_LIST`와 `OUTPUT_IS_LIST` 속성을 통해 노드 간 데이터의 순차적 처리 및 일괄 처리를 제어한다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Length one processing**: ComfyUI 서버가 데이터를 전달할 때 기본적으로 각 요소를 길이가 1인 리스트로 래핑하여 관리하는 방식.
|
||||
- **List processing**: 여러 데이터 인스턴스를 하나의 워크플로우에서 순차적 또는 일괄적으로 처리하는 메커니즘.
|
||||
- **INPUT_IS_LIST**: 노드가 단일 호출로 전체 리스트를 수신하도록 입력 동작을 재정의하는 클래스 속성.
|
||||
- **OUTPUT_IS_LIST**: 커스텀 노드의 출력 튜플 중 특정 항목이 래핑되지 않고 순차적 처리를 위한 데이터 시리즈로 취급되도록 지정하는 속성.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **데이터 래핑 구조**: 노드가 출력을 반환할 때 각 요소는 별도의 길이 1인 리스트로 래핑되며, 다음 노드 호출 시 다시 언래핑(unwrapped)되어 전달됨.
|
||||
- **순차 처리 로직**: 입력 리스트의 길이가 다를 경우, 짧은 쪽은 마지막 값을 반복하여 패딩(padding)하며, `main` 메서드는 각 값에 대해 한 번씩 호출됨.
|
||||
- **출력 길이 일관성**: 출력 리스트는 항상 가장 긴 입력 리스트와 동일한 길이를 유지함.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 1. 데이터 처리 메커니즘
|
||||
- **기본 동작**: Comfy 서버는 데이터를 Python 리스트 형태로 표현하며, 일반적으로 길이가 1인 상태로 흐름을 유지함. 이는 배치(batch)와는 다른 개념임.
|
||||
- **패딩 및 반복**: 입력 리스트의 길이가 불일치할 경우, 마지막 값을 반복하여 길이를 맞춤.
|
||||
|
||||
### 2. 노드 속성 제어 (Node Attributes)
|
||||
| 속성 | 타입 | 설명 |
|
||||
| :--- | :--- | :--- |
|
||||
| `INPUT_IS_LIST` | `bool` (Class Attribute) | 설정 시(`True`), 노드가 단일 호출로 전체 리스트를 수신하도록 입력 동작을 변경함. |
|
||||
| `OUTPUT_IS_LIST` | `tuple[bool]` (Class Attribute) | `RETURN_TYPES`와 동일한 길이의 튜플로, 어떤 출력이 순차적 처리를 위한 데이터 시리즈로 취급될지 지정함. |
|
||||
|
||||
### 3. ImageRebatch 노드 기술 스펙
|
||||
커스텀 노드 예시인 `ImageRebatch`의 구성 요소는 다음과 같습니다.
|
||||
|
||||
| 필드 | 타입 | 필수/선택 | 제약·설명 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `images` | `IMAGE` | 필수 | 입력 이미지 데이터 |
|
||||
| `batch_size` | `INT` | 필수 | 기본값 1, 범위 1 ~ 4096 |
|
||||
| `INPUT_IS_LIST` | `bool` | 필수 (Class Attr) | `True`로 설정 시 리스트 형태로 수신 |
|
||||
| `OUTPUT_IS_LIST` | `tuple[bool]` | 필수 (Class Attr) | `(True, )`로 설정하여 출력 처리 지정 |
|
||||
| `FUNCTION` | `string` | 필수 (Class Attr) | 실행할 메서드 명 (`rebatch`) |
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **배치와 리스트의 차이**: 본문은 배치가 단일 엔트리(예: latents, images의 한 요소)임을 명시하며, 리스트 처리 방식과 혼동하지 않도록 주의를 요구함.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ImageRebatch 노드**: `INPUT_IS_LIST = True` 설정을 통해 여러 이미지 배치를 리스트로 수신하고, 이를 사용자가 요청한 `batch_size` 크기의 새로운 배치들로 재구성(rebatch)하는 데 사용됨.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[ComfyUI Server]]: 데이터 흐름과 서버 운영의 기초가 되는 시스템.
|
||||
- [[List processing]]: 노드 간 데이터를 순차적으로 처리하는 핵심 로직.
|
||||
- [[INPUT_IS_LIST]]: 입력 데이터의 형태를 결정하는 노드 속성.
|
||||
- [[OUTPUT_IS_LIST]]: 출력 데이터의 래핑 여부를 결정하는 노드 속성.
|
||||
- [[ImageRebatch]]: 리스트 처리가 적용된 구체적인 구현 예시.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/lists 본문에서 초안 생성.
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
id: datatypes---comfyui
|
||||
title: "Datatypes - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/datatypes"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Datatypes - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI의 데이터 타입은 클라이언트 측에서 워크플로의 데이터 형식을 제어하고 잘못된 데이터 연결을 방지하는 강력한 타입 시스템(Strong Typing) 역할을 수행한다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **클라이언트 측 타입 검증**: JavaScript 클라이언트 코드는 기본적으로 서로 다른 데이터 타입 간의 노드 출력을 입력에 연결하는 것을 허용하지 않는다.
|
||||
- **Python 기반 데이터 타입**: [[INT]], [[FLOAT]], [[STRING]], [[BOOLEAN]] 등 Python의 기본 자료형을 활용하여 노드의 입력을 정의한다.
|
||||
와 [[COMBO]]와 같이 리스트 형태의 옵션을 제공하는 특수 타입이 존재한다.
|
||||
- **텐서 및 멀티미디어 데이터 구조**: [[IMAGE]], [[LATENT]], [[AUDIO]], [[MASK]] 등 텐서(torch.Tensor) 기반의 복잡한 데이터 구조를 지원한다.
|
||||
- **커스텀 샘플링 구성 요소**: [[Noise]], [[Sampler]], [[Sigmas]], [[Guider]]와 같이 샘플링 프로세스를 제통어하는 특수 데이터 타입을 포함한다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Strong Typing 패턴**: 노드 간의 연결 시 데이터 타입 불일치를 방지하기 위해 클라이언트 측에서 엄격한 타입 체크를 수행함.
|
||||
- **계층적 구조화**: 단순 스칼라 값(Python datatypes)부터 복잡한 텐서 구조([[Tensor datatypes]]), 그리고 샘플링 로직을 위한 특수 객체([[Custom Sampling datatypes]])까지 단계별로 데이터 형식을 정의함.
|
||||
- **확장 가능한 파라미터**: `extra options`를 통해 위젯의 동작(기본값, 최소/최대값, 레이블 등)을 제어하는 추가 키 값을 제공함.
|
||||
|
||||
## 📖 세부 내용 (Details
|
||||
|
||||
### 1. Comfy Datatypes
|
||||
- **[[COMBO]]**: 드롭다운 메뉴 위젯을 나타내며, `list[str]`로 정의된다. 첫 번째 옵션이 기본값으로 선택된다.
|
||||
- **[[Primitive and reroute]]**: 클라이언트 측에만 존재하는 노드로, 고유한 데이터 타입을 가지지 않으나 연결된 노드의 데이터 타입을 그대로 따른다.
|
||||
|
||||
### 2. Python Datatypes (INPUT_TYPES 명세)
|
||||
| 필드 | 타입 | 필수/선택 | 제약·설명 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [[INT]] | int | 필수(default) | min, max는 선택 사항임 |
|
||||
| [[FLOAT]] | float | 필수(default) | min, max, step은 선택 사항임 |
|
||||
| [[STRING]] | str | 필수(default) | - |
|
||||
| [[BOOLEAN]] | bool | 필수(default) | - |
|
||||
|
||||
### 3. Tensor Datatypes
|
||||
- **[[IMAGE]]**: `torch.Tensor` 형태이며, shape은 `[B, H, W, C]`이다. (B: 배치, H: 높이, W: 너비, C: 채점/채널)
|
||||
- **[[LATENT]]**: `dict` 형태이며, `samples` 키에 `torch.Tensor` (`[B, C, H, W]`)를 포함한다. 크기는 이미지의 1/8이다.
|
||||
- **[[MASK]]**: `torch.Tensor` 형태로, shape은 `[H, W]` 또는 `[B, C, H, W]`이다.
|
||||
- **[[AUDIO]]**: `dict` 형태이며, `waveform` 키(`[B, C, T]`)와 `sample_rate` 키를 포함한다.
|
||||
|
||||
### 4. Custom Sampling Datatypes
|
||||
- **[[Noise]]**: 노스 소스를 나타내며, `generate_noise` 메서드와 `seed` 속성을 가진 Python 객체로 표현된다.
|
||||
- **[[Sampler]]**: `sample` 메서드를 제공하는 Python 객체이다.
|
||||
- **[[Sigmas]]**: 스케줄러에 의해 생성된 샘플링 단계별 시그마 값으로, 1차원 텐서 형태이다.
|
||||
- **[[Guider]]**: 프롬프트 등에 의한 컨디셔닝을 담당하며, `__call__` 메서드를 통해 노이즈 예측값을 반환한다.
|
||||
|
||||
### 5. Additional Parameters (Extra Options)
|
||||
| Key | Description |
|
||||
| :--- | :--- |
|
||||
| default | 위젯의 기본값 |
|
||||
| min | 숫자(FLOAT/INT)의 최소값 |
|
||||
| max | 숫자(FLOAT/INT)의 최대값 |
|
||||
| step | 위젯의 증감 수치 |
|
||||
| label_on | BOOL이 True일 때 UI에 표시될 레이블 (BOOL) |
|
||||
| label_off | BOOL이 False일 때 UI에 표시될 레이블 (BOOL) |
|
||||
| defaultInput | 지원되는 위젯 대신 입력 소켓으로 사용하도록 설정 |
|
||||
| forceInput | defaultInput을 적용하며, 위젯으로의 변환을 방지함 |
|
||||
| multiline | 멀티라인 텍ext 박스 사용 (STRING) |
|
||||
| placeholder | UI가 비어있을 때 표시될 자리표시자 텍text (STRING) |
|
||||
| dynamicPrompts | 프론트엔드에서 다이내믹 프롬프트를 평가하도록 유도 |
|
||||
| lazy | 해당 입력에 지연 평가(Lazy Evaluation)를 사용함을 선언 |
|
||||
| rawLink | 평가된 값 대신 노드 ID와 인덱스 링크(`["nodeId", index]`)를 수신 |
|
||||
|
||||
## ⚖️ 모동 및 업데이트 (Contradictions & updates)
|
||||
- **업데이트**: `Model datatypes` 섹션에서 [[MODEL]], [[CLIP]], [[VAE]], [[CONDITIONING]]은 기술적인 내용이므로 현재 가이드의 범위 외에 있다고 명시함.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **위젯 커스터마이징**: `extra options` 키를 사용하여 사용자 정의 위젯을 생성하거나 기존 위젯(STRING, INT 등)의 동작(멀티라인, 레이블 지정 등)을 제어할 수 있음.
|
||||
- **데이터 흐름 제어**: `rawLink`를 통해 노드 확장 시 평가된 값이 아닌 직접적인 연결 링크를 전달받아 활용 가능함.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[INT]] - 정수형 데이터 타입 정의 및 제약 사항 설명.
|
||||
- [[LATENT]] - 잠재 공간(Latent Space) 데이터의 구조와 특징 설명.
|
||||
- [[IMAGE]] - 이미지 텐서의 차원과 채널 구성 정보 제공.
|
||||
- [[Custom Sampling datatypes]] - 샘플링 프로세스에 특화된 데이터 타입 그룹.
|
||||
- [[Additional Parameters]] - 위젯 및 입력 정의 시 사용되는 확장 파라미터 모음.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/datatypes 본문에서 초안 생성.
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
id: execution-model-inversion-guide---comfyui
|
||||
title: "Execution Model Inversion Guide - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/development/comfyui-server/execution_model_inversion_guide"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Execution Model Inversion Guide - Com뮬UI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
PR #2666을 통해 실행 모델이 기존의 역방향 재귀 모델에서 순방향 위상 정렬(front-to-back topological sort) 방식으로 변경됨에 따른 커스텀 노드 개발자용 가이드입니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
* **실행 모델 전환**: [[PR #2666]]을 통해 실행 모델이 back-to-front recursive model에서 front-to-back topological sort로 반전되었습니다.
|
||||
* **선택적 입력 검증 (Optional Input Validation)**: 기존에는 "required" 입력에 대해서만 검증이 이루어졌으나, 이제는 "optional" 입력을 사용하는 커스텀 노드에 대해 새로운 검증 규칙과 대응 방안이 적용됩니다.
|
||||
* **실행 순서의 비결정성 (Execution Order)**: 실행 순서는 노드의 ID나 캐시된 값에 따라 달라질 수 있으며, 그래프 구조 외의 요소에 의존해서는 안 됩니다.
|
||||
* **지연 평가 (Lazy Evaluation)**: 입력값이 필요한 시점까지 평가를 미루는 기능이 도입되었습니다.
|
||||
|
||||
## 📌 추출된 패턴 (Extracted patterns)
|
||||
* **Monkey Patching의 위험성**: 실행 모델을 [[Monkey Patching]]하는 코드는 새로운 모델에서 작동하지 않을 가능성이 높습니다.
|
||||
* **검증 실패 대응 전략**: 커스텀 노드 작성 시 검증 오류를 피하기 위해 `VALIDATE_INPUTS` 함수를 정의하거나, 특정 데이터 구조(예: 리스트 대신 딕셔계 사용)를 사용하는 패턴이 권장됩니다.
|
||||
* **확장성 (Node Expansion)**: 런타임에 노드가 서브그래프로 확장되어 루프 구현을 가능하게 하는 구조를 가집니다.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 1. 입력 검증 오류 및 해결 방법 (Optional Input Validation)
|
||||
커스텀 노드 작성 시 발생할 수 있는 검증 실패 사례와 권장 솔루션입니다.
|
||||
|
||||
| 발생 원인 | 상세 내용 | 권장 솔루션/대응 |
|
||||
| :--- | :--- | :--- |
|
||||
| **예약된 추가 파라미터 오용** | 비교 불가능한 타입(예: 딕셔너리)에 `min`, `max` 같은 예약어를 사용 | `uiMin`, `uiMax`와 같은 비예약 키로 변경하여 사용 |
|
||||
| **복합 타입 (Composite Types)** | `CUSTOM_A, CUSTOM_B`와 같은 형태의 출력/입력 사용 시 검증 문제 발생 | 출력 시에는 `MakeSmartType`과 같은 래퍼(Wrapper)를 정의하여 사용하거나, 입력 시에는 `VALIDATE_INPUTS`를 통해 검기 스킵 |
|
||||
| **상수 리스트 사용** | 그래프 정의 내에서 `[1, 2, 3]`과 같은 리스트를 상수로 사용 (이전에는 프론트엔드 확장이 필요했음) | 리스트를 `{ "value": [1, 2, 3] }`와 같이 딕셔너리 형태로 감싸서 사용 |
|
||||
|
||||
### 2. VALIDATE_INPUTS 함수의 새로운 기능
|
||||
검증 오류 영향을 줄이기 위해 추가된 기능들입니다.
|
||||
* **기본 검증 스킵**: `VALIDATE_INPUTS` 함수에 의해 수신된 입력은 기본 검증이 생략됩니다.
|
||||
* **kwargs 지원**: `**kwargs`를 처리할 수 있어, 노드 작성자가 모든 입력을 검증된 것으로 간주하게 할 수 있습니다.
|
||||
* **input_types 인자**: 이 인자가 존재하면 연결된 출력 타입과 입력 타입을 매핑하는 딕셔너리를 제공하며, 이때 타입 검증이 생략됩니다.
|
||||
|
||||
### 3. 기타 기능적 변화
|
||||
* **Lazy Evaluation**: 노드와 그 조상(ancestors) 노드를 평가하기 전에 필요 여부를 먼저 확인하여 효율성을 높입니다.
|
||||
* **Node Expansion**: 런타임 시 노드가 서브그래프로 확장되어 [[tail-recursion]]을 통한 루프 구현을 지원합니다.
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
* **업데이트**: 실행 모델이 기존의 back-to-front 재귀 방식에서 front-to-back 위상 정렬 방식으로 완전히 뒤집혔습니다(Inverted)는 점이 가장 중요한 기술적 변화입니다.
|
||||
* **주의사항**: 실행 순서가 캐시 값에 따라 변할 수 있으므로, 그래프 구조 이외의 요소에 의존하는 것은 위험하다는 경고가 포함되어 있습니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
* **커스텀 노드 개발자**: 새로운 실행 모델 하에서 기존 커스텀 노드가 깨지는 것을 방지하기 위해 `uiMin/uiMax` 사용, `VALIDATE_INPUTS` 정의, 리스트의 딕셔너리화 등의 대응책을 적용해야 합니다.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
* [[PR #2666]] : 실행 모델의 구조적 변화를 일으킨 핵심 변경 사항입니다.
|
||||
* [[Monkey Patching]] : 실행 모델을 수정하려는 시도가 새로운 모델에서 작동하지 않을 수 있음을 나타냅니다.
|
||||
* [[Lazy Evaluation]] : 입력값 평가 시점을 조절하여 성능을 최적화하는 기술입니다.
|
||||
* [[Node Expansion]] : 노드가 서브그래프로 확장되어 복잡한 로직(루프 등)을 수행하게 하는 기능입니다.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/development/comfyui-server/execution_model_inversion_guide 본문에서 초안 생성.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
id: getting-started---comfyui
|
||||
title: "Getting Started - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/walkthrough"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Getting Started - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[ComfyUI]]의 커스텀 노드를 개발하기 위해 Python 백엔드 코드 작성부터 JavaScript 클라이언트 확장까지의 전 과정을 단계별로 안내하는 가이드입니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
* **Custom Node Development**: [[Python]] 클래스를 사용하여 [[ComfyUI]]에 새로운 기능을 추가하는 과정입니다.
|
||||
* **Node Structure**: 커스텀 노드는 `CATEGORY`, `INPUT_TYPES`, `RETURN_TSYPES`, `FUNCTION`이라는 네 가지 필수 요소를 포함해야 합니다.
|
||||
* **Backend-to-Frontend Communication**: `PromptServer`를 통해 서버에서 클라이언트로 메시지를 전송하여 UI에 피드백을 줄 수 있습니다.
|
||||
* **Client Extension**: [[JavaScript]]를 사용하여 클라이언트 측의 동작을 확장하고 인터페이스를 조정할 수 있습니다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
* **Scaffolding Pattern**: `comfy-cli`를 사용하여 프로젝트 디렉토리 구조와 기본 설정을 자동 생성하는 방식입니다.
|
||||
* **Data Processing Pattern**: [[torch.Tensor]] 형태의 이미지 데이터를 입력받아 특정 연산(평균, 채널별 계산 등)을 통해 결과값을 도출하는 로ct 패턴이 반복됩니다.
|
||||
* **Registration Pattern**: `NODE_CLASS_MAPPINGS`와 `NODE_DISPLAY_NAME_MAPPINGS`를 통해 작성된 노드를 [[ComfyUI]] 시스템에 등록하는 구조입니다.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 1. 커스텀 노드 개발 준비
|
||||
* **전제 조건**: 작동 가능한 [[ComfyUI]] 설치 및 `comfy-cli` 설치가 필요합니다.
|
||||
* **프로젝트 설정**: `cd ComfyUI/custom_nodes` 경로에서 `comform node scaffold` 명령어를 사용하여 프로젝트를 생성할 수 있습니다.
|
||||
|
||||
### 2. 노드 정의 (Defining the Node)
|
||||
커스텀 노드는 Python 클래스로 정의되며 다음의 네 가지 핵심 요소를 포함해야 합니다:
|
||||
* **CATEGORY**: 노드가 메뉴의 어느 위치에 표시될지 지정합니다.
|
||||
* **INPUT_TYPES**: 노드가 받을 입력값(Dictionary 형태)을 정의하는 클래 메서드입니다.
|
||||
* **RETURN_TYPES**: 노드가 출력할 데이터 타입의 튜플입니다.
|
||||
* **FUNCTION**: 노드 실행 시 호출될 메서드의 이름입니다.
|
||||
|
||||
### 3. 주요 기능 구현 (The main function)
|
||||
* 이미지 처리를 위해 `torch` 라이러리를 사용하며, 입력된 이미지는 `[B, H, W, C]` 형태의 `torch.Tensor`로 처리됩니다.
|
||||
* `.flatten()`, `torch.mean()`, `.item()` 등의 메서드를 사용하여 텐서 데이터를 Python float 값으로 변로 변환하여 연산할 수 있습니다.
|
||||
|
||||
### 4. 노드 등록 및 확장 (Register & Add Options)
|
||||
* **등록**: `src/nodes.py` 파일의 끝에 `NODE_CLASS_MAPPINGS`를 수정하여 노드를 등록해야 하며, 수정 후에는 [[ComfyUI]] 재시작이 필수적입니다.
|
||||
* **옵션 추가**: `INPUT_TYPES` 내에 새로운 위젯(예: mode 선택)을 추가하여 기능의 범위를 확장할 수 있습니다.
|
||||
|
||||
### 5. 클라이언트 확장 (Client Extension)
|
||||
* `web/js` 디렉토리를 생성하고 `__init__.py`에서 `WEB_DIRECTORY`를 내보내도록 설정합니다.
|
||||
* `app.registerExtension`을 통해 서버로부터 받은 메시지를 수신하는 리스너를 구축할 수 있습니다.
|
||||
|
||||
## ⚖️ 모동 및 업데이트 (Contradictions & updates)
|
||||
본문 내용 중 상충되는 정보는 없으며, 최신 개발 가이드를 따르고 있습니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
* **예제 시나나리오**: 여러 이미지 배치 중 가장 밝은 이미지를 선택하는 노드에서 시작하여, 색상 기준(reddest, greenest 등)을 추가하고 최종적으로 클라이언트 메시지 알림까지 구현하는 전체 워크플로우를 보여줍니다.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
* [[ComfyUI]] - 커스텀 노드 개발의 대상이 되는 메인 프레임워크입니다.
|
||||
* [[Python]] - 백엔드 로직 작성을 위한 핵심 언어입니다.
|
||||
* [[JavaScript]] - 클라이언트 측 확장을 위해 사용되는 언어입니다.
|
||||
* [[torch.Tensor]] - 이미지 데이터 처리를 위한 기본 데이터 구조입니다.
|
||||
* [[comfy-cli]] - 노드 스캐폴딩 및 관리를 위한 도구입니다.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/walkthrough 본문에서 초안 생성.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
id: hidden-and-flexible-inputs---comfyui
|
||||
title: "Hidden and Flexible inputs - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_리스트: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/more_on_inputs"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Hidden and Flexible inputs - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI 커스텀 노드 개발 시 서버로부터 특정 정보를 요청하기 위한 숨겨진 입력(Hidden inputs)과 데이터 타입을 유연하게 정의하는 방법론에 대한 가이드입니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
* **[[Hidden inputs]]**: 클라이언트 측에는 나타나지 않지만, 서버로부터 [[UNIQUE_ID]], [[PROMPT]], [[EXTRA_PNGINFO]], [[DYNPROMT]]와 같은 특정 정보를 요청할 수 있는 입력 옵션입니다.
|
||||
* **[[Custom datatypes]]**: 노드 간 데이터 전달을 위해 고유한 이름을 가진 사용자 정의 타입을 생성하고, `forceInput` 옵션을 통해 위젯이 아닌 입력으로 강제하는 기능입니다.
|
||||
* **[[Wildcard inputs]]**: `*` 기호를 사용하여 모든 소스에 연결 가능한 입력을 정의하며, 백엔드 검증을 건너뛰기 위해 `[[VALIDATE_INPUTS]]`를 활용할 수 있습니다.
|
||||
* **[[Dynamically created inputs]]**: 클라이언트 측에서 동적으로 생성된 데이터를 처리하기 위해 `ContainsAnyDict`와 같은 구조를 사용하여 임의의 이름으로 전달되는 데이터를 수용합니다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
* **서버 요청 패턴**: `INPUT_TYPES` 내 `hidden` 키를 사용하여 서버의 특정 데이터에 접근하는 구조화된 방식.
|
||||
* **타입 안전성 패턴**: 커스텀 타입을 정의하고, 출력과 입력의 타입을 일치시켜 데이터 흐름을 제어하는 방식.
|
||||
* **유연한 검증 패턴**: 백엔드에서 지원하지 않는 와일드카드(`*`) 기능을 사용하기 위해 `VALIDATE_INPUTS` 함수를 통해 검증 로직을 재정의하는 접근법.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 1. Hidden Inputs (숨겨진 입력)
|
||||
커스텀 노드는 `INPUT_TYPES`의 `hidden` 딕셔너리를 통해 서버로부터 다음 정보를 요청할 수 있습니다:
|
||||
|
||||
| 필드 | 타입 | 설명 |
|
||||
| :--- | :--- | :--- |
|
||||
| `unique_id` | `dict[str, str]` | [[UNIQUE_ID]]: 노드의 유일 식별자. 클라이언트 측의 `id` 속성과 일치하며 클라이언트-서버 통커뮤니케이션에 사용됨. |
|
||||
| `prompt` | `dict[str, str]` | [[PROMPT]]: 클라이언트가 서버로 보낸 전체 프롬프트 객체. |
|
||||
| `extra_pnginfo` | `dict[str, str]` | [[EXTRA_PNGINFO]]: 저장될 .png 파일의 메타데이터에 복사될 딕셔너리. 추가 정보 저장 및 노드 간 통신용으로 사용됨. |
|
||||
| `dynamic_prompt` | `dict[str, str]` | [[DYNPROMPT]]: `comfy_execution.graph.DynamicPrompt` 인스턴스. 실행 중 Node Expansion에 따라 변할 수 있음 (고급 루프 구현용). |
|
||||
|
||||
### 2. Flexible Inputs (유연한 입력)
|
||||
|
||||
#### Custom Datatypes (사용자 정의 데이터 타입)
|
||||
* **정의**: 고유한 대문자 이름(예: `CHEESE`)을 가진 타입을 생성하여 노드 간 데이터를 전달합니다.
|
||||
* **제약 사항**: 클라이언트가 해당 타입을 인지하지 못하므로, 위젯이 아닌 입력으로 작동하도록 `forceInput: True` 설정을 권장합니다.
|
||||
|
||||
#### Wildcard Inputs (와일드카드 입력)
|
||||
* `*`를 사용하여 모든 소스에 연결 가능한 입력을 정의할 수 있습니다.
|
||||
* 백엔드 검증을 건너뛰기 위해 `VALIDATE_INPUTS` 함수에서 `input_types` 파라미터를 활용합니다.
|
||||
|
||||
#### Dynamically Created Inputs (동적 생성 입력)
|
||||
* 클라이언트에서 동적으로 생성된 데이터에 접근하기 위해 `ContainsAnyDict(dict)` 클래스를 사용하여 임의의 키를 가진 데이터를 수용할 수 있습니다.
|
||||
|
||||
## ⚖️ 모돌 및 업데이트 (Contradictions & updates)
|
||||
* **메타데이터 관련 주의사항**: `disable_metadata` 옵션으로 ComfyUI를 시작할 경우, `EXTRA_PNGINFO`에 저장된 데이터가 저장되지 않을 수 있습니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
* **고급 노드 구현**: `DYNPROMPT`를 사용하여 커스텀 노드 내에서 루프(loops) 기능을 구현하는 사례.
|
||||
* **데이터 전달 전략**: `CHEESE`와 같은 사용자 정의 타입을 생성하여 특정 타입의 출력만 특정 입력에 연결되도록 제한하는 설계.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검ass 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
* [[INPUT_TYPES]] - 노드의 입력 및 위젯을 정의하는 핵심 메서드.
|
||||
* [[VALIDATE_INPUTS]] - 백엔드에서의 타입 검증 로직을 제어하기 위한 함수.
|
||||
* [[comfy_execution.graph.DynamicPrompt]] - 실행 중 동적으로 변할 수 있는 프롬프트 객체.
|
||||
* [[forceInput]] - 커스텀 위젯을 입력 필드로 강제하는 설정 방법.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/more_on_inputs 본문에서 초안 생성.
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
id: images-latents-and-masks---comfyui
|
||||
title: "Images, Latents, and Masks - ComtyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/images_and_masks"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Images, Latents, and Masks - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI 백엔드 개발을 위한 핵심 데이터 타입인 [[IMAGE]], [[MASK]], [[LATENT]]의 구조적 차이와 [[torch.Tensor]] 조작법에 대한 기술 명세.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **[[IMAGE]] 구조**: $[B, H, W, C]$ 형태를 가지며 $C=3$인 채널 마지막(channel last) 방식의 [[torch.Tensor]] 데이터 타입.
|
||||
- **[[MASK]] 구조**: $[B, H, W]$ 형태를 가지며, 0 또는 1의 값을 통해 특정 연산 범위를 지정하는 데이터 타입.
|
||||
- **[[LATENT]] 구조**: `samples` 키에 $[B, C, H, W]$ ($C=4$) 형태의 데이터를 담고 있는 [[dict]] 타입.
|
||||
- **데이터 변환**: [[PIL.Image]]와 [[torch.Tensor]] 간의 포맷 전환 및 채널 순서(channel first vs last) 관리의 중요성.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **차원 확장 전략**: [[MASK]] 사용 시 $[B, H, W, C]$ 형태를 맞추기 위해 `unsqueeze(-1)`(C 차원) 및 `unsqueeze(0)`(B 차원)을 사용하는 패턴.
|
||||
- **데이터 정규화**: [[LoadImage]] 노드에서 알파 채널을 활용하여 [[MASK]]를 생성할 때 $[0, 1]$ 범위로 정규화하고 반전시키는 프로세스.
|
||||
- **채널 우선순위의 상이성**: [[LATENT]]는 channel first($[B, C, H, W]$) 형식을 따르지만, [[IMAGE]]는 channel last($[B, H, W, C]$) 형식을 따름.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 🖼️ Images
|
||||
- **데이터 구조**: `torch.Tensor` 형태이며, shape은 $[B, H, W, C]$ ($C=3$)입니다.
|
||||
- **주의 사항**: 연산 효율을 위해 일부 PyTorch 연산은 $[B, C, H, W]$ (channel first) 형식을 기대할 수 있으므로 주의가 필요합니다.
|
||||
- **포맷 변환**: 이미지를 저장하거나 불러올 때 [[PIL.Image]] 포맷으로의 변환이 필요합니다.
|
||||
|
||||
### 🖼️ Working with PIL.Image
|
||||
- 이미지 로드 및 저장을 위해 `from PIL import Image, ImageOps`를 사용합니다.
|
||||
|
||||
### 🎭 Masks
|
||||
- **데이터 구조**: `torch.Tensor` 형태이며, shape은 $[B, H, W]$입니다.
|
||||
- **값의 의미**:
|
||||
- 이진 값(0 또는 1): 특정 픽셀이 연산 대상인지 지정.
|
||||
- 0과 1 사이의 값: 투명도 조절, 필터 조정, 레이어 합성 등을 위한 마스킹 범위(extent)를 나타냄.
|
||||
|
||||
#### [[Masks from the Load Image Node]]
|
||||
- **생성 원리**: `LoadImage` 노드는 이미지의 알파 채널(RGBA의 'A')을 사용하여 [[MASK]]를 생성합니다.
|
||||
- **정규화 과정**: 알파 채널 값을 $[0, 1]$ 범위(`torch.float32`)로 정규화한 후 반전시킵니다.
|
||||
- **예외 케이스**: JPEG와 같이 알파 채널이 없는 경우, `LoadImage`는 $[1, 64, 64]$ 크기의 기본 마스크를 생성합니다.
|
||||
|
||||
#### [[Understanding Mask Shapes]]
|
||||
- **차원 특성**: [[numpy]]나 [[PIL]]과 달리, 마스크는 채널 차원이 생략된 2D 배열($[H, W]$)로 표현되는 경우가 많습니다. 따라서 배치 단위의 마스크는 $[B, H, W]$의 3차원을 가집니다.
|
||||
- **Shape 매칭 기법**:
|
||||
- $C$ 차원 확장: `unsqueeze(-1)`를 사용하여 $[B, H, W, 1]$ 생성.
|
||||
- $B$ 차원 확장: `unsqueeze(0)`를 사용하여 배치 차원 추가.
|
||||
- **권장 사항**: 노드가 마스크를 입력받을 때 `len(mask.shape)`를 확인하는 것이 좋습니다.
|
||||
|
||||
### 🧬 Latents
|
||||
- **데이터 구조**: `dict` 형태이며, `samples` 키에 데이터가 저장됩니다.
|
||||
- **형태**: $[B, C, H, W]$ (여기서 $C=4$)의 shape을 가집니다.
|
||||
- **특징**: [[LATENT]]는 channel first 형식을 따릅니다.
|
||||
|
||||
## ⚖️ 모동 및 업데이트 (Contradictions & updates)
|
||||
- **상충 정보**: [[IMAGE]]는 channel last($[B, H, W, C]$)이고, [[LATENT]]는 channel first($[B, C, H, W]$)임이 명시되어 있어 두 타입 간의 구조적 차이를 주의해야 합니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **노드 출력 구현**: 노드의 출력이 단일 텐서인 경우, 반드시 `(image,)` 형태로 반환해야 함을 명시함.
|
||||
- **데이터 처리**: [[LoadImage]] 노드를 통한 알파 채널 기반 마스크 생성 및 정규화 프로세스.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[torch.Tensor]] : 모든 데이터 타입의 기초가 되는 클래스.
|
||||
- [[PIL.Image]] : 이미지 로드 및 저장에 사용되는 라이mer리.
|
||||
- [[LoadImage]] : 알파 채널을 통해 마스크를 생성하는 소스 노드.
|
||||
- [[RGBA]] : 마스크 생성의 근거가 되는 알파 채널 포함 색상 모델.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/images_and_masks 본문에서 초안 생성.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
id: lazy-evaluation---comfyui
|
||||
title: "Lazy Evaluation - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/lazy_evaluation"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Lazy Evaluation - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
불필요한 연산을 방지하기 위해 필요한 시점에만 입력을 평가하여 그래프 실행 효율성을 최적화하는 기술적 전략.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Lazy Evaluation (지연 평가)**: 모든 입력을 미리 계산하지 않고, 실제 사용 여부가 결정될 때까지 평가를 미루어 불필요한 프로세싱을 방지함.
|
||||
- **Lazy Input Marking**: `INPUT_TYPES` 내의 옵션 딕셔너리에 `{"lazy": True}`를 추가하여 특정 입력을 지연 평가 대상으로 지정함.
|
||||
- **check_lazy_status**: 지연된 입력이 필요한지 확인하기 위해 실행 전 호출되는 메서드로, 필요한 입력의 이름을 리스트로 반환함.
|
||||
- **Execution Blocking**: [[ExecutionBlocker]] 객체를 사용하여 특정 노드의 실행을 중단하거나 에러 메시지를 표시하며 흐름을 제어함.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **조건부 평가 전략**: 입력값의 비율(ratio)이 0.0 또는 1.0인 경우, 혹은 마스크가 전체 0.0 또는 1.0인 경우와 같이 특정 조건에서 로딩이나 계산을 생략하는 패턴.
|
||||
- **2단계 구현 구조**: 입력을 지연 대상으로 표시(`lazy: True`)하고, 상태를 확인하는 메서드(`check_lazy_satus`)를 정의하는 일관된 구현 방식.
|
||||
- **계층적 제어**: 직접적인 노드 개발 시에는 Lazy Evaluation을 권장하며, 외부 노드 제어가 불가능할 때는 `ExecutionBlocker`를 사용하는 우회 전략.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 1. 지연 평가의 이점 및 사례
|
||||
기본적으로 모든 입력은 실행 전 평가되지만, 다음과 같은 경우 지연 평가가 유용함:
|
||||
- **ModelMergeSimple 노드**: 비율(ratio)이 0.0이면 첫 번째 모델을 로드할 필요가 없고, 1.0이면 두 번째 모델을 로드할 필요가 없음.
|
||||
- **이미지 보간(Interpolation)**: 마스크나 비율이 완전히 0.0 또는 1.0인 경우 불필요한 이미지 평가를 생금함.
|
||||
- **Switch 노드**: 특정 입력에 의해 다른 입력의 통과 여부가 결정되는 경우.
|
||||
|
||||
### 2. 지연 입력 구현 방법 (Creating Lazy Inputs)
|
||||
지연 입력을 만드는 과정은 두 단계로 나뉨:
|
||||
1. **INPUT_TYPES 정의**: 입력 옵션 딕셔너리에 `lazy: True` 키-값 쌍을 추가함.
|
||||
- 예시: `"image1": ("IMAGE", {"lazy": True})`
|
||||
2. **check_lazy_status 메서드 정의**:
|
||||
- 역할: 지연된 입력 중 추가 평가가 필요한 입력을 찾아 이름 리스트를 반환함.
|
||||
- 특징: 인자로 실제 입력값들을 받으며, 사용 불가능한(None) 지연 입력은 `None`으로 처리됨. 클래스 메서드가 아닌 일반 메서드로 작성되어야 함.
|
||||
|
||||
### 3. 실행 차단 (Execution Blocking)
|
||||
노드의 실행을 제어하는 두 가지 방법:
|
||||
- **직접 구현**: 출력 노드 개발 시 `enabled` 입력을 추가하고 다른 입력을 모두 지연 입력으로 설정하여 조건부로 평가함.
|
||||
- **ExecutionBlocker 활용**:
|
||||
- `None` 전달: 실행을 조용히 차단(silent block)하며, 출력을 비활성화할 때 유용함.
|
||||
- `String` 메시지 전달: 차단 시 사용자에게 보여줄 에러 메시지를 표시함 (예: VAE가 없는 체크포인트 로드 시).
|
||||
|
||||
## ⚖️ 모tes 및 업데이트 (Contradictions & updates)
|
||||
- **주의사항**: `check_lazy_status`는 실제 입력값을 사용하므로 클래스 메서드가 아닌 인스턴스 메서드로 동작해야 함. 또한, `ExecutionBlocker`를 전파 중단 용도로 사용하는 것은 권장되지 않으며(지연 평가 사용 권장), 이는 의도된 설계임.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **MixImages 노드 예시**: 마스크의 최소/최대값이 0.0 또는 1.0인 경우, `image1` 또는 `image2`를 평가하지 않도록 설계하여 연산 효율을 높임.
|
||||
- **에러 핸들링**: `load_checkpoint` 시 VAE가 없는 경우 `ExecutionBlocker`에 에러 메시지를 담아 전달함으로써 사용자에게 명확한 정보를 제공함.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[Lazy Evaluation]] - 입력 평가 시점을 제어하는 핵심 기술.
|
||||
- [[INPUT_TYPES]] - 노드의 입력 구조를 정의하는 메커니즘.
|
||||
- [[check_lazy_status]] - 지연된 입력의 필요 여부를 판단하는 로직.
|
||||
- [[ExecutionBlocker]] - 그래프 실행을 중단하거나 에러를 표시하는 특수 객체.
|
||||
- [[ModelMergeSimple]] - 지연 평가가 적용될 수 있는 구체적인 노드 사례.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/lazy_evaluation 본문에서 초안 생성.
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
id: lifecycle---comfyui
|
||||
title: "Lifecycle - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 1.0
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/lifecycle"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Lifecycle - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI가 시작될 때 `custom_nodes` 디렉토리를 스캔하여 Python 모듈을 로드하고 커스텀 노드를 정의하는 라이프사이클 프로세스.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
* **[[custom_nodes]] 로딩**: ComfyUI 시작 시 `custom_nodes` 폴ের더를 스캔하여 Python 모듈을 찾아 로드함.
|
||||
* **[[NODE_CLASS_MAPPINGS]]**: 모듈이 커스텀 노드로 인식되기 위해 반드시 내보내야(export) 하는 딕셔너리 매핑 정보.
|
||||
* **[[__init__.py]] 역할**: 커스텀 노드 모듈의 진입점으로, 실행 시 `NODE_CLASS_MAPPINGS`를 포함하여 노드 정의를 ComfyUI에 가용하게 함.
|
||||
* **[[WEB_DIRECTORY]] 설정**: 클라이언트 측 JavaScript 파일을 제공하기 위해 모듈 내 상대 경로를 지정하는 기능.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
* **모듈 인식 조건**: Python 모듈은 `__init__.py`를 포함하는 디렉토리 형태이며, `__all__` 속성에 정의된 내용을 내보냄.
|
||||
* **에러 처리 패턴**: 코드에 에러가 발생하더라도 ComfyUI는 계속 진행하지만, 해당 모듈이 로드에 실패했음을 Python 콘솔을 통해 보고함.
|
||||
* **표준화된 구조**: 커스텀 노드의 JavaScript 파일은 관례적으로 `js`라는 하위 디렉토리에 배치함.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
### 1. How Comfy loads custom nodes
|
||||
ComfyUI는 시작 시 `custom_nodes` 디렉토리를 스캔하여 Python 모듈을 로드하려고 시도합니다. 해당 모듈이 `NODE_CLASS_MAPPINGS`를 내보내면 커스텀 노드로 취급됩니다.
|
||||
|
||||
### 2. init.py 구성 요소
|
||||
커스텀 노드 정의를 위해 `__init__.py`에서 관리해야 하는 주요 매핑 정보는 다음과 같습니다.
|
||||
|
||||
| 필드 | 타입 | 필수/선택 | 제약·설명 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [[NODE_CLASS_MAPPINGS]] | dict | 필수 | 커스텀 노드 이름(고유값)을 해당 노드 클래스에 매핑함. |
|
||||
| [[NODE_DISPLAY_NAME_MAPPINGS]] | dict | 선택 | 고유 이름을 사용자에게 보여줄 표시용 이름으로 매핑함. 미제공 시 고유 이름을 사용함. |
|
||||
| [[WEB_DIRECTORY]] | string | 선택 | JavaScript 파일이 위치한 모듈 내 상대 경로를 지정함 (예: `js` 디렉토리). |
|
||||
|
||||
### 3. JavaScript 배포 및 주의사항
|
||||
* **파일 제한**: `.js` 파일만 제공 가능하며, `.css`나 기타 타입은 이 방식으로 배포할 수 없음.
|
||||
* **구 버전 방식 지양**: 과거에는 JavaScript 파일을 Comfy 웹 하위 디렉토리로 복사하는 코드가 필요했으나, 현재는 이를 권장하지 않음.
|
||||
|
||||
## ⚖️ 모모순 및 업데이트 (Contradictions & updates)
|
||||
* **업데이트 사항**: 이전 버전의 Comfy에서는 `__init__.py`가 JavaScript 파일을 메인 웹 디렉토리로 복사하는 작업이 필요했으나, 현재는 이를 수행하는 코드를 사용하지 말라고 명시되어 있음.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
* **단순한 `__init__.py` 예시**:
|
||||
```python
|
||||
from .python_file import MyCustomNode
|
||||
NODE_CLASS_MAPPINGS = { "My Custom Node" : MyCustomNode }
|
||||
__all__ = ["NODE_CLASS_MAPPINGS"]
|
||||
```
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
* [[custom_nodes]] - 커스텀 노드가 로드되는 물리적 경로와 메커니즘 설명.
|
||||
* [[NODE_CLASS_MAPPINGS]] - 노드 클래스를 식별하기 위한 핵심 매핑 구조.
|
||||
* [[WEB_DIRECTORY]] - 클라이언트 사이드 JS 파일 배포를 위한 경로 설정법.
|
||||
* [[__init__.py]] - Python 모듈의 초기화 및 커스텀 노드 로직 실행 지점.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/lifecycle 본문에서 초안 생성.
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
id: messages---comfyui
|
||||
title: "Messages - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/development/comfyui-server/comms_messages"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Messages - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[ComfyUI]] 서버와 클라이언트 간의 실시간 데이터 교환을 위해 [[PromptExecutor]]가 [[PromptServer]]를 통해 메시지를 전송하고, 클라이언트는 소켓 이벤트를 통해 이를 수신하여 처리하는 통신 메커니즘.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **메시지 전달 구조**: [[PromptExecutor]]가 실행 중 또는 큐 상태 변경 시 [[PromptServer]]의 `send_sync` 메서드를 통해 클라이언트로 메시지를 전송함.
|
||||
- **클라이언트 수신 방식**: [[api.js]]에 정의된 소켓 이벤트 리스너가 `CustomEvent` 객체를 생성하여 등록된 리스너로 디스패치함.
|
||||
- **확장성 (Extensibility)**: 기본 제공되는 메시지 타입 외에도 클라이언트와 서버 양측에서 사용자 정의 메시지 타입을 추가하고 처리할 수 있음.
|
||||
- **데이터 구조**: 메시지 핸들러는 `CustomEvent`를 통해 전달받으며, `.detail` 속성을 통해 서버가 보낸 데이터 딕셔너리에 접근 가능함.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **이벤트 기반 통신**: 클라이언트 측에서 `api.addEventListener(message_type, messageHandler)` 형식을 사용하여 특정 메시지 타입에 대한 이벤트를 등록하는 표준 JavaScript 관용구 사용.
|
||||
- **자동 유형 인식**: 정의되지 않은 새로운 메시지 타입이 들어오면 클라이언트는 이를 자동으로 알려진 메시지 목록에 추가함.
|
||||
o **서버-클라이언트 동기화**: 서버 측에서는 `PromptServer.instance.send_sync`를 통해, 클라이언트 측에서는 리스너 등록을 통해 양방향 통신 구조를 형성함.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 1. 내장 메시지 타입 (Built in message types)
|
||||
[[PromptServer]]의 `send_sync` 메서드를 통해 전달되는 주요 이벤트와 그 데이터 구성은 다음과 같습니다.
|
||||
|
||||
| event | when data |
|
||||
| :--- | :--- |
|
||||
| execution_start | When a prompt is about to run: `prompt_id` |
|
||||
| execution_error | When an error occurs during execution: `prompt_id`, plus additional information |
|
||||
| execution_interrupted | When execution is stopped by a node raising `InterruptProcessingException`: `prompt_id`, `node_id`, `node_type` and executed (a list of executed nodes) |
|
||||
| execution_cached | At the start of execution: `prompt_id`, `nodes` (a list of nodes which are being skipped because their cached outputs can be used) |
|
||||
| execution_success | When all nodes from the prompt have been successfully executed: `prompt_id`, `timestamp` |
|
||||
| executing | When a new node is about to be executed: `node` (node id or None to indicate completion), `prompt_id` |
|
||||
| executed | When a node returns a ui element: `node` (node id), `prompt_id`, `output` |
|
||||
| progress | During execution of a node that implements the required hook: `node` (node id), `prompt_id`, `value`, `max` |
|
||||
| status | When the state of the queue changes: `exec_info`, a dictionary holding `queue_remaining` (the number of entries in the queue) |
|
||||
|
||||
### 2. 실행된 메시지 활용 (Using executed)
|
||||
'executed' 메시지는 단순히 노드가 실행을 완료할 때 전송되는 것이 아니라, **노드가 UI 업데이트를 반환할 때만** 전송됩니다. 이를 위해 메인 함수는 튜플 대신 다음과 같은 구조의 딕셔 необходимо 합니다:
|
||||
- `return { "ui": a_new_dictionary, "result": the_tuple_of_output_values }`
|
||||
- `a_new_dictionary`는 `output` 값으로 전송되며, 결과 키(`result`)는 출력값이 없는 경우 생략 가능합니다.
|
||||
|
||||
### 3. 사용자 정의 메시지 타입 (Custom message types)
|
||||
- **클라이언트 측**: `api.addEventListener("my.custom.message", messageHandler);`와 같이 고유한 이름으로 리스너를 등록하여 구현합니다.
|
||||
- **서버 측**: `PromptServer.instance.send_sync("my.custom.message", a_dictionary)`를 사용하여 데이터를 전송합니다.
|
||||
|
||||
### 4. 노드 ID 획득 (Getting node_id)
|
||||
내장 메시지에는 현재 노드의 ID가 포함되는 경우가 많습니다. 서버 측에서 이를 활용하기 위해 `INPUT_TYPES`의 `hidden` 키를 사용하여 `node_id`를 가져올 수 있습니다.
|
||||
```python
|
||||
@classmethod
|
||||
def INPUT_TYPES(s):
|
||||
return {"required" : { }, "hidden": { "node_id": "UNIQUE_ID" } }
|
||||
```
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
본문에서 'executed' 메시지라는 명칭과 실제 동작(UI 업데이트가 있을 때만 전송됨) 사이의 차이점에 대해 설명하고 있습니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **커스텀 노드 개발**: `INPUT_TYPES` 내 `hidden` 설정을 통해 서버 측에서 `node_id`를 식별하고 이를 메시지에 포함시켜 클라이언트에 전달하는 사례.
|
||||
- **확장 기능(Extension) 구현**: `setup()` 함수 내에서 `api.addEventListener`를 사용하여 특정 이벤트에 대한 핸들러를 등록하는 사례.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[PromptExecutor]]: 메시지를 클라이언트로 전송하는 주체.
|
||||
- [[PromptServer]]: `send_sync` 메서드를 통해 메시지 전달을 담당하는 서버 구성 요소.
|
||||
- [[api.js]]: 소켓 이벤트 리스너가 정의되어 있는 클라이언트 측 핵심 파일.
|
||||
- [[InterruptProcessingException]]: 실행 중단 시 발생하는 예외 타입.
|
||||
- [[INPUT_TYPES]]: 노드의 입력 타입을 정의하며 `node_id`를 숨겨진 값으로 가져오는 데 사용됨.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/development/comfyui-server/comms_messages 본문에서 초안 생성.
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
id: node-expansion---comfyui
|
||||
title: "Node Expansion - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/expansion"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Node Expansion - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[Node Expansion]]은 노드가 실행 시점에 새로운 [[subgraph]]를 반환하여 그래프 내에서 해당 노드를 대체하도록 함으로써, [[loop]]와 같은 고급 기능을 구현할 수 있게 하는 기술입니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Node Expansion**: 노드의 실행 결과로 기존 노드를 대체할 새로운 [[subgraph]]를 반환하는 고급 기법입니다.
|
||||
- **GraphBuilder**: [[subgraph]] 생성 시 실수를 방방지하기 위해 권장되는 클래스로, 효율적인 그래프 구축을 지원합니다.
|
||||
ello
|
||||
- **Efficient Subgraph Caching**: 확장된 [[subgraph]] 내의 노드들을 개별적으로 캐싱하여, 변경 사항 발생 시 전체 재로드 없이 특정 모델만 유지할 수 있도록 하는 최적화 전략입니다.
|
||||
- **Expansion Requirements**: 확장을 수행하는 노드는 반드시 결과값(`result`)과 확장될 그래프(`expand`)를 포함하는 딕셔너리를 반환해야 합니다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **구조적 대체 패턴**: 기존의 노드 실행 방식(즉시 결과 반환)에서 벗어나, 실행 중에 새로운 노드 구조를 생성하여 그래프에 삽입하는 패턴을 가집니다.
|
||||
- **캐싱 최적화 전략**: [[subgraph]] 내의 입력을 전달할 때, 직접적인 값 대신 [[subgraph]] 객체에 대한 링크를 전달하여 캐싱 효율을 높이는 패턴을 사용합니다.
|
||||
- **수동 구현 제약 사항**: [[GraphBuilder]]를 사용하지 않을 경우, 노드 ID의 고유성 및 결정론적 유지를 위해 개발자가 직접 관리해야 하는 규칙(ID 중복 방지, 일관된 ID 유지)이 존재합니다.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 🛠️ Node Expansion 구현 요구사항
|
||||
노드가 확장을 수행하기 위해서는 반드시 아래의 키를 포함하는 딕셔너리를 반환해야 합니다.
|
||||
|
||||
| 키 (Key) | 설명 |
|
||||
| :--- | :--- |
|
||||
| `result` | 노드의 출력값에 대한 튜플. 일반적인 최종 값과 노드 출력값이 혼합될 수 있음. |
|
||||
| `expand` | 확장에 사용될 최종화된 그래프. [[GraphBuilder]]를 사용하지 않을 경우 별도의 규칙 준수 필요. |
|
||||
|
||||
### 🛠️ GraphBuilder 미사용 시 추가 요구사항
|
||||
[[GraphBuilder]]를 사용하지 않고 수동으로 구현할 경우, 다음의 조건을 직접 처리해야 합니다.
|
||||
- **Node ID 고유성**: 그래프 전체에서 노드 ID는 반드시 고유해야 합니다 (리스트 사용으로 인한 동일 노드의 다중 실행 포함).
|
||||
- **결정론적 ID**: 그래프의 여러 실행(캐싱에 의한 부분 실행 포함) 사이에서 노드 ID는 결정론적이고 일관되어야 합니다.
|
||||
- **ID 관리 도구**: `GraphBuilder.alloc_prefix()` 또는 `comfy.graph_utils.add_graph_prefix`를 사용하여 기존 그래프를 수정하거나 접두사를 생성할 수 있습니다.
|
||||
|
||||
### 🛠️ 효율적인 Subgraph 캐싱 (Efficient Subgraph Caching)
|
||||
- [[torch.Tensor]]와 같은 비리터럴 입력을 [[subgraph]] 내 노드에 전달할 수 있으나, 이는 캐싱을 저해할 수 있습니다.
|
||||
- 가능한 경우, 노드 자체보다는 [[subgraph]] 객체에 대한 링크를 전달하는 것이 권장됩니다.
|
||||
- 입력의 `Additional Parameters`에서 `rawLink`로 선언하여 쉽게 구현할 수 있습니다.
|
||||
|
||||
## ⚖️ 모tes 및 업데이트 (Contradictions & updates)
|
||||
본문 내 상충되는 정보는 없으나, [[GraphBuilder]] 사용 여부에 따라 개발자가 책임져야 하는 요구사항의 범위가 달라짐을 명시하고 있습니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Checkpoint Merging 예시**: `load_and_merge_checkpoints` 함수를 통해 두 개의 체크포인트를 로드하고, 이를 병합하는 새로운 노드 구조(`ModelMergeSimple`, `ClipMergeSimple`)를 생성하여 반환하는 구체적인 코드가 제시되었습니다. 이 과정에서 [[GraphBuilder]]를 사용하여 확장을 구현하는 방식이 예로 들었습니다.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[Node Expansion]]: 노드가 새로운 그래프 구조를 반환하는 핵심 기술입니다.
|
||||
- [[GraphBuilder]]: [[subgraph]] 생성 시 실수를 방지하기 위해 권장되는 도구입니다.
|
||||
- [[subgraph]]: 확장을 통해 새롭게 생성되어 그래프에 삽입될 노드들의 집합입니다.
|
||||
- [[loop]]: [[Node Expansion]]을 통해 구현 가능한 고급 기능의 예시입니다.
|
||||
- [[Efficient Subgraph Caching]]: 확장된 노드의 재사용성을 높이기 위한 최적화 기법입니다.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/expansion 본문에서 초안 생성.
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
id: node-replacement---comfyui
|
||||
title: "Node replacement - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/node-replacement"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Node replacement - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[Node Replacement API]]는 커스텀 노드 개발자가 구식(deprecated) 노드를 최신 노드로 자동 마이그레이션하여 워크플로우의 호환성을 유지할 수 있게 해주는 기능이다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Migration Path Definition**: [[Node Replacement API]]를 통해 구 버전 노드에서 신규 노드로의 전환 경로를 정의한다.
|
||||
- **Automated Workflow Upgrade**: 노드 클래스 이름 변경, 노드 병합, 입력/출력 리팩토링 시 사용자의 워크플로우를 자동으로 업데이트한다.
|
||||
- **Lifecycle Integration**: 커스텀 노드 확장의 `on_load` 생명주기 훅(lifecycle hook) 단계에서 교체 로직을 등록한다.
|
||||
- **Data Mapping**: [[Input mapping]], [[Output mapping]], [[Widget ID binding]]을 통해 입력/출력 데이터와 위젯 값을 정밀하게 재연결한다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Node Replacement Use Cases**: 노드 클래스 이름 변경, 노드 병합(Merging), 입력 리팩토링, 오타 수정(Typo fix) 등 특정 목적에 따라 API를 활용함.
|
||||
- **Registration Strategy**: `node_replacements.py`와 같은 전용 파일을 생성하여 `on_load` 시점에 등록하는 구조를 가짐.
|
||||
- **Mapping Logic**:
|
||||
- [[Input mapping]]: 기존 입력을 새 입력으로 매핑하거나 고정값(`set_value`)을 설정함.
|
||||
- [[Output mapping]]: 인덱스 기반의 참조를 통해 출력 데이터를 재배치함.
|
||||
- **Frontend Automation**: 프론트엔드에서 API를 호출하여 교체 정보를 가져온 후, 사용자에게 업그레이드를 제안하고 연결 및 위젯 값을 보존함.
|
||||
|
||||
## 📖 세부 내용 (Details
|
||||
|
||||
### 🛠 NodeReplace Parameters
|
||||
| 필드 | 타입 | 필수/선택 | 제약·설명 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `new_node_id` | str | 필수 | 교체될 대상 노드의 클래스 이름 |
|
||||
| `old_node_rypt_id` | str | 필수 | 기존의 구식(deprecated) 노드 클래스 이름 |
|
||||
| `old_widget_ids` | list[str] \| None | 선택 | 상대적 인덱스에 바인딩할 위젯 ID의 정렬된 리스트 |
|
||||
| `input_mapping` | list \| None | 선택 | 기존 노드에서 새 노드로 입력을 매핑하는 방법 |
|
||||
| `output_mapping` | list \| None | 선택 | 기존 노드에서 새 노드로 출력을 매핑하는 방법 |
|
||||
|
||||
### 📥 Input Mapping Details
|
||||
입력 매핑은 다음과 같은 방식으로 정의됩니다:
|
||||
- **기존 입력 매핑**: `{"new_id": "model", "old_id": "model"}`
|
||||
- **고정값 설정**: `{"new_id": "scheduler", "set_value": "normal"}`
|
||||
- **동적/Autogrow 입력 (Dot notation 사용)**: `{"new_id": "images.image0", "old_id": "image1"}`
|
||||
|
||||
### 📤 Output Mapping Details
|
||||
출력 매핑은 인덱스 기반 참조를 사용합니다:
|
||||
- `{"new_idx": 0, "old_idx": 0}` (첫 번째 출력 매핑)
|
||||
- `{"new_idx": 1, "old_idx": 0}` (기존 출력 0을 새 출력 1로 매핑)
|
||||
|
||||
### 🔗 Widget ID Binding
|
||||
`old_widget_ids` 필드는 위젯 ID를 위치 인덱스에 매핑합니다. 워크플로우 JSON은 위젯 값을 ID가 아닌 위치로 저장하기 때문에 이 기능이 필요합니다.
|
||||
- 예: `["steps", "cfg", "sampler"]` -> index 0은 "steps"를 의미함.
|
||||
|
||||
### 🌐 REST API (GET /api/node_replacements)
|
||||
등록된 모든 교체 정보를 반환하며, 응답 구조는 다음과 같습니다:
|
||||
```json
|
||||
{
|
||||
"OldSamplerNode": [
|
||||
{
|
||||
"new_node_im_id": "NewSamplerNode",
|
||||
"old_node_id": "OldSamplerNode",
|
||||
"old_widget_ids": ["num_steps", "cfg_scale", "sampler_name"],
|
||||
"input_mapping": [...],
|
||||
"output_mapping": [...]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
본문에서 확인되지 않음.
|
||||
|
||||
## 🛠 적용 사례 (Applied in summary)
|
||||
- **Simple Node Merge**: `Load3DAnimation` 노드를 `Load3D`로 병합.
|
||||
- **Typo Fix**: `SDV_img2vid_Conditioning`의 오타를 `SVD_imgint2vid_Conditioning`으로 수정.
|
||||
- **Input Renaming**: `ImageScaleBy`를 `ResizeImageMaskNode`로 교체하며 입력/출력 매핑 및 기본값(`set_value`) 적용.
|
||||
- **Autogrow Mapping**: `BatchImagesNode`에서 도트 노테이션을 사용하여 `images.image0`과 같은 동적 입력 처리.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[Node Replacement API]]: 노드 교체 기능을 구현하기 위한 핵심 인터페이스.
|
||||
- [[Input mapping]]: 입력 데이터를 새 노드로 전달하는 메커니즘.
|
||||
- [[Output mapping]]: 출력 인덱스를 재정의하는 방법.
|
||||
- [[Widget ID binding]]: 위젯 위치 기반 매핑을 위한 기술적 요구사항.
|
||||
- [[on_load lifecycle hook]]: 교체 로직을 등록해야 하는 시점.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/node-replacement 본문에서 초안 생성.
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
id: routes---comfyui
|
||||
title: "Routes - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 1.0
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/development/comfyui-server/comms_routes"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Routes - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[ComfyUI]] 서버의 [[Routes]]는 클라이언트와 서버 간의 데이터 교환, 작업 큐 관리, 실시간 상태 업데이트를 위한 HTTP 메서드 및 [[WebSocket]] 엔드포인트의 집합체이다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Core API Routes**: 서버의 기능을 수행하기 위해 정의된 다양한 [[GET]], [[POST]] 메서드들의 모음으로, 모델 관리, 이미지 업로드, 시스템 정보 조회 등을 포함한다.
|
||||
- **WebSocket Communication**: 클라이언트와 서버 간의 양방향 실동기화를 지원하며, 실행 진행 상황 및 노드 상태를 실시간으로 전달하는 통로이다.
|
||||
- **Custom Routes**: 개발자가 [[aiohttp]] 프레임워크를 사용하여 서버에 새로운 경로를 추가하고 클라이언트와의 메시지 송수신 기능을 확장할 수 있는 메커니즘이다.
|
||||
- **Execution Queue Management**: [[prompt]] 제출, 큐 상태 조회, 실행 중단 및 히스토리 관리 등 작업 흐름의 제어를 담당한다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Request/Response Pattern**: 특정 경로(예: `/prompt`)로 데이터를 제출하면 서버가 검증 후 실행 큐에 추가하고 결과를 반환하는 구조를 가진다.
|
||||
- **Real-time Update Pattern**: [[WebSocket]]을 통해 `status`, `progress`, `executed` 등 다양한 타입의 JSON 메시지를 클라이언트에 브리캐스팅한다.
|
||||
- **Extensibility Pattern**: `@routes.post`와 같은 데코레이터를 활용하여 기존 서버 구조를 변경하지 않고 새로운 기능을 추가할 수 있는 확장성을 제공한다.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 1. Core API Routes (Built-in routes)
|
||||
[[server.py]]에 정의된 주요 경로들의 기능은 다음과 같다.
|
||||
|
||||
| path | method | purpose |
|
||||
| :--- | :--- | :--- |
|
||||
| `/` | get | load the comfy webpage |
|
||||
| `/ws` | websocket | WebSocket endpoint for real-time communication with the server |
|
||||
| `/embeddings` | get | retrieve a list of the names of embeddings available |
|
||||
| `/extensions` | get | retrieve a list of the extensions registering a WEB_DIRECTORY |
|
||||
| `/features` | get | retrieve server features and capabilities |
|
||||
| `/models` | get | retrieve a list of available model types |
|
||||
| `/models/{folder}` | get | retrieve models in a specific folder |
|
||||
| `/workflow_templates` | get | retrieve a map of custom node modules and associated template workflows |
|
||||
| `/upload/image` | post | upload an image |
|
||||
| `/upload/mask` | post | upload a mask |
|
||||
| `/view` | get | view an image (includes various options) |
|
||||
| `/view_metadata/` | get | retrieve metadata for a model |
|
||||
| `/system_stats` | get | retrieve information about the system (python version, devices, vram etc) |
|
||||
| `/prompt` | get | retrieve current queue status and execution information |
|
||||
| `/prompt` | post | submit a prompt to the queue |
|
||||
| `/object_info` | get | retrieve details of all node types |
|
||||
| `/object_info/{node_class}` | get | retrieve details of one node type |
|
||||
| `/history` | get | retrieve the queue history |
|
||||
| `/history/{prompt_id}` | get | retrieve the queue history for a specific prompt |
|
||||
| `/history` | post | clear history or delete history item |
|
||||
| `/queue` | get | retrieve the current state of the execution queue |
|
||||
| `/queue` | post | manage queue operations (clear pending/running) |
|
||||
| `/interrupt` | post | stop the current workflow execution |
|
||||
| `/free` | post | free memory by unloading specified models |
|
||||
| `/userdata` | get | list user data files in a specified directory |
|
||||
| `/v2/userdata` | get | enhanced version that lists files and directories in structured format |
|
||||
| `/userdata/{file}` | get | retrieve a specific user data file |
|
||||
| `/userdata/{file}` | post | upload or update a user data file |
|
||||
| `/userdata/{file}` | delete | delete a specific user data file |
|
||||
| `/userdata/{file}/move/{dest}` | post | move or rename a user data file |
|
||||
| `/users` | get | get user information |
|
||||
| `/users` | post | create a new user (multi-user mode only) |
|
||||
|
||||
### 2. WebSocket Communication
|
||||
[[WebSocket]] 엔드포인트인 `/ws`는 실시간 양방향 통신을 위해 사용되며, 다음과 같은 정보를 전달한다.
|
||||
- **주요 용도**: 실행 진행 상황 업데이트 수신, 노드 실행 상태 실시간 확인, 에러 메시지 및 디버깅 정보 수신, 큐 상태 변경 시 라이브 업데이트.
|
||||
- **JSON 메시지 타입**:
|
||||
- `status`: 전체 시스템 상태 업데이트
|
||||
- `execution_start`: 프롬프트 실행 시작 시점
|
||||
- `execution_cached`: 캐시된 결과 사용 시
|
||||
- `executing`: 노드 실행 중 업데이트
|
||||
- `progress`: 장기 실행 작업의 진행률 업데이트
|
||||
- `executed`: 노드 실행 완료 시
|
||||
|
||||
### 3. Custom Routes Implementation
|
||||
클라이언트에서 서버로 메시지를 보내기 위해 새로운 경로를 정의하는 방법이다.
|
||||
- **서버 측 구현**: `aiohttp` 프레임워크를 활용하며, `@routes.post('/path')` 데코레이터를 사용한다. 함수 내부에서는 `request.post()`를 통해 데이터를 수신할 수 있다.
|
||||
- **클라이언트 측 호출**: `FormData` 객체를 사용하여 `api.fetchApi`를 통해 새로운 경로에 요청을 보낼 수 있다.
|
||||
|
||||
## ⚖️ 모의 및 업데이트 (Contradictions & updates)
|
||||
본문 내에서 상충되는 정보는 발견되지 않았습니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Custom Node 개발**: 서버의 기능을 확장하기 위해 `@routes.post`를 사용하여 새로운 경로를 생성하고, `FormData`를 통해 데이터를 전송하는 예시가 제시됨.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[ComfyUI Server]]: 서버의 전반적인 구조와 역할을 이해하기 위한 핵심 개념입니다.
|
||||
- [[WebSocket]]: 실시간 데이터 스트리밍 및 양방향 통신의 기술적 기반입니다.
|
||||
- [[aiohttp]]: 커스텀 라우트를 구현할 때 사용하는 프레임워크입니다.
|
||||
- [[PromptExecutor]]: 실행 큐를 정의하고 관리하는 클래스입니다.
|
||||
|
||||
## 📝 변경 이履歴 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/development/comfyui-server/comms_routes 본문에서 초안 생성.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: server-overview---comfyui
|
||||
title: "Server Overview - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https enough://docs.comfy.org/development/comfyui-server/comms_overview"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Server Overview - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[ComfyUI]] 서버는 [[aiohttp]]와 [[asyncio]]를 기반으로 하며, 클라이언트와 서버 간의 메시지 송수신 및 [[http]] 라우트를 통해 워크플로우 데이터를 처리하는 구조를 가집니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **서버 프레임워크**: [[aiohttp]] 및 [[asyncio]] 기반의 구동 환경.
|
||||
- **메시지 통신 (Server to Client)**: `PromptServer` 인스턴스의 `send_sync` 메서드를 통한 소켓 메시지 전달.
|
||||
- **통신 경로 (Client to Server)**: `api.fetchApi()` 메서드를 통한 [[http]] 라우트 처리.
|
||||
- **데이터 일관성**: 큐(Queue) 요청 시 전체 워크플로우(위젯 값 포함)를 제출하며, 요청 이후의 변경 사항은 서버에 반영되지 않음.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **양방향 통신 구조**: 서버에서 클라이언트로의 소켓 메시지 전송과 클라이언트에서 서버로의 HTTP 요청 처리가 분리되어 존재함.
|
||||
- **상태 고정성**: 클라이언트가 큐에 요청을 제출하는 시점에 워크플로우 데이터가 결정되며, 실행 중 발생하는 수정 사항은 서버에 영향을 미치지 않는 구조적 특성을 보임.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
### [[ComfyUI]] 서버 통신 메커니즘
|
||||
- **서버 구동 환경**: Comfy 서버는 [[aiohttp]] 프레임워크 위에서 실행되며, 이는 [[asyncio]]를 사용합니다.
|
||||
- **메시지 전달 (Messages)**:
|
||||
- **Server $\rightarrow$ Client**: `server.py`에 정의된 `PromptServer` 인스턴스의 `send_sync` 메서드를 통해 소켓 메시지 형태로 전송됩니다. 이 메시지는 `api.js`에 등록된 소켓 이벤트 리스너에 의해 처리됩니다.
|
||||
- **Client $\rightarrow$ Server**: `api.js`에 정의된 `api.fetchApi()` 메서드를 통해 전송되며, 서버에 정의된 [[http]] 라우트에 의해 처리됩니다.
|
||||
- **워크플로우 제출 및 실행**:
|
||||
- 사용자가 요청을 큐(Queue)에 추가할 때 위젯 값을 포함한 전체 워크플로우를 제출합니다.
|
||||
- 서버는 큐에 요청을 보낸 이후에 발생하는 변경 사항을 수신하지 않습니다.
|
||||
- 실행 중 서버의 동작을 수정하려면 별도의 라우트(Routes)가 필요합니다.
|
||||
|
||||
### Documentation Index 정보
|
||||
- 전체 문서 인덱스는 다음 경로에서 확인할 수 있습니다: `https://docs.comfy.org/llms.txt`
|
||||
|
||||
## ⚖️ 모ikan 및 업데이트 (Contradictions & updates)
|
||||
본문에서 확인되지 않음.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
본문에서 확인되지 않음.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[ComfyUI Server]] - 서버의 전반적인 구조와 역할을 설명합니다.
|
||||
- [[aiohttp]] - 서버가 구동되는 기반 프레임워크입니다.
|
||||
- [[asyncio]] - 비동기 처리를 위한 핵심 기술 스택입니다.
|
||||
- [[PromptServer]] - 서버 메시지 전송을 담당하는 클래스입니다.
|
||||
- [[api.js]] - 클라이언트 측 통신 로직이 구현된 파일입니다.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/development/comfyui-server/comms_overview 본문에서 초안 생성.
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
id: subgraph-blueprints---comfyui
|
||||
title: "Subgraph blueprints - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_rypt_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/subgraph_blueprints"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Subgraph blueprints - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[ComfyUI]]에서 커스텀 노드 개발자가 재사용 가능한 서브그래프 컴포넌트를 글로벌 블루프린트로 제공하여 사용자가 워크플로우에 즉시 추가할 수 있게 하는 기능입니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Global Subgraph Blueprints**: 커스텀 노드와 연관된 재사용 가능한 [[subgraph]] 컴포ned를 전역 블루프린트로 가용화하는 기능입니다.
|
||||
- **Automated Scanning**: [[ComfyUI]]는 모든 커스텀 노드 디렉토리를 스캔하여 [[subgraph]] 파일을 자동으로 찾아냅니다.
|
||||
- **API Delivery**: 스캔된 서브그래프 파일은 `/global_subgraphs` API 엔드포인트를 통해 서비스됩니다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **개발자 워크플로우**: 커스텀 노드 디렉토리 내 `subgraphs/` 폴더 생성 $\rightarrow$ `.json` 파일 배치 $\rightarrow$ [[ComfyUI]] 자동 스캔 및 API 제공.
|
||||
- **서브그래프 생성 절차**: [[ComfyUI]]에서 서브그래프 구축 $\rightarrow$ 노드 선택 및 변환 $\rightarrow$ JSON으로 내보내기 $\rightarrow$ `subgraphs/` 폴더에 저장.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
### 🛠️ 구현 방법 (Implementation)
|
||||
노드 개발자는 다음과 같은 방식으로 블루프린트를 배포할 수 있습니다:
|
||||
1. 커스텀 노드 디렉토리 내에 `subgraphs/` 폴더를 생성합니다.
|
||||
2. 해당 폴더 안에 `.json` 형식의 서브그래프 파일을 배치합니다.
|
||||
|
||||
### 📂 파일 구조 예시 (Example Structure)
|
||||
`ComfyUI-MyCustomNodeModule/subgraphs/` 경로 내에 다음과 같은 파일이 포함될 수 있습니다:
|
||||
- `My_upscale_subgraph.json`
|
||||
- `My_effects_subgraph.json`
|
||||
위와 같이 구성된 경우, [[ComfyUI]]의 서브그래프 브라우저에서 해당 블루프린트들을 확인할 수 있습니다.
|
||||
|
||||
### 📝 JSON 파일 생성 프로세스 (Creation Process)
|
||||
서브그래프 JSON 파일은 워크플로우 JSON 파일과 동일한 형식을 사용하며, 가장 쉬운 생성 단계는 다음과 같습니다:
|
||||
1. [[ComfyUI]] 내에서 서브그래프를 구축합니다.
|
||||
2. 포함할 노드들을 선택합니다.
|
||||
3. 해당 노드들을 서브그래프로 변환합니다.
|
||||
4. 서브그래프를 JSON으로 내보내기(Export) 합니다.
|
||||
5. 생성된 JSON 파일을 `subgraphs/` 폴더에 저장합니다.
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
본문에서 확인되지 않음.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **커스텀 노드 배포**: `ComfyUI-MyCustomNodeModule`과 같은 커스텀 노드 모듈에서 사용자가 워크플로우에 즉시 추가할 수 있는 사전 구축된 노드 그룹(pre-built node groups)을 제공하는 사례로 활용됩니다.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[subgraph]]: 사용자가 서브그래프와 상호작용하는 방식에 대한 기본 개념입니다.
|
||||
- [[ComfyUI]] API Reference: `/global_subgraphs` 엔드포인트와 관련된 기술적 명세입니다.
|
||||
- [[Custom Nodes]]: 커스텀 노드 개발 및 배포를 위한 가이드라인입니다.
|
||||
- [[Workflow JSON]]: 서브그래프 파일의 기반이 되는 데이터 형식입니다.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/subgraph_blueprints 본문에서 초안 생성.
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
id: v3-migration---comfyui
|
||||
title: "V3 Migration - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_radix: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/v3_migration"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[V3 Migration - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
기존 V1(Legacy) 방식의 노드 정의 구조를 객체 중심의 새로운 V3 스키마로 전환하여, 더 체계적이고 확장 가능한 방식으로 마이그레이션하는 가이드.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
* **V3 Schema Architecture**: 기존의 딕셔너리 기반 정의에서 벗어나 [[io.Schema]] 객체를 사용하여 입력(Inputs)과 출력(Outputs)을 객체 단위로 정의함.
|
||||
* **Class-based Execution**: 실행 메서드가 `execute`라는 이름의 클래 메서드로 고정되며, `comfy_entrypoint`를 통해 확장을 정의함.
|
||||
* **Type Safety & Modernization**: `io.Int.Input`, `io.Image.Input` 등 클래스 기반의 타입 정의를 통해 강력한 타입 힌트와 구조화된 스키마 관리를 지원함.
|
||||
* **API-driven Extension**: `ComfyExtension` 및 `ComfyAPI`를 사용하여 노드 교체, 진행률 보고, 확장 생명주기를 관리함.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
* **V1 to V3 Transformation Pattern**: `INPUT_TYPES` 딕셔너리를 `define_schema` 메서드의 `io.Schema` 객체로 변환하고, `FUNCTION`을 `execute` 클래 메서드로 변경하는 일련의 문법적 전환 패턴.
|
||||
* **Inheritance Pattern**: 모든 V3 노드는 반드시 `io.ComfyNode`를 상속받아야 하며, 상위 체인에 이 클래스가 포함되어야 함.
|
||||
* **Schema-driven Configuration**: 노드의 ID, 표시 이름, 카테고리, 입출력 정의 등 모든 메타데이터가 하나의 스키마 객체 내로 통합되는 구조.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 1. V3 Migration: 주요 변경 사항 비교
|
||||
| 특징 | V1 (Legacy) | V3 (Modern) |
|
||||
| :--- | :--- | :--- |
|
||||
| **입력/출력 정의** | 딕셔니리(Dictionary) 방식 | 객체(Object) 기반 방식 |
|
||||
| **실행 메서드** | `FUNCTION`에 지정된 이름 사용 | `execute`로 고정 (클래 메서드) |
|
||||
| **노드 등록** | `NODE_CLASS_MAPPINGS` 사용 | `comfy_entrypoint` 및 `ComfyExtension` 사용 |
|
||||
| **상태 관리** | `__init__` 등을 통한 상태 유지 가능성 | 클래 메서드 중심, `state` 노출 없음 |
|
||||
|
||||
### 2. Migration Steps (마이그레이션 단계)
|
||||
* **Step 1: Base Class 변경**: 모든 V3 스키마 노드는 `io.ComfyNode`를 상속받아야 함.
|
||||
* **Step 2: INPUT_TYPES를 define_schema로 전환**: `io.Schema` 객체를 반환하도록 구현하며, 입출력을 클래스 기반으로 정의함.
|
||||
* **Step 3: Execute 메서드 업데이트**: 실행 함수 이름을 `execute`로 변경하고 클래 메서드로 선언함.
|
||||
* **Step 4: 노드 속성 변환**: `RETURN_TYPES`, `CATEGORY`, `FUNCTION` 등의 기존 속성을 `io.Schema` 내의 필드로 재배치함.
|
||||
* **Step 5: 특수 메서드 처리**: `validate_inputs` (기존 `VALIDATE_INPUTS`), `fingerprint_inputs` (기존 `IS_CHANGED`) 등 변경된 명칭 적용.
|
||||
* **Step 6: Extension 및 Entry Point 생성**: `ComfyExtension` 클래스를 정의하고 `comfy_entrypoint`를 구현함.
|
||||
|
||||
### 3. Schema Reference (Schema 데이터클래스 필드)
|
||||
| 필드 | 타입 | 필수/선택 | 제약·설명 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| node_id | str | 필수 | 노드의 글로벌 고유 ID (충돌 방지를 위해 접두사/접미사 권장) |
|
||||
| display_name | str | 선택 | UI에 표시될 이름. 미설정 시 `node_id` 사용 |
|
||||
| category | str | 선택 | "Add Node" 메뉴 내 카테록 (예: "sd") |
|
||||
| description | str | 선택 | 마우스 호버 시 표시되는 툴팁 |
|
||||
| inputs | list[Input] | 선택 | 입력 정의 리스트 |
|
||||
| outputs | list[Output] | 선택 | 출력 정의 리스트 |
|
||||
| hidden | list[Hidden] | 선택 | 요청할 숨겨진 입력(Hidden Inputs) 리스트 |
|
||||
| search_aliases | list[str] | 선택 | 검색을 위한 대체 이름 목록 |
|
||||
| is_output_node | bool | 선택 | True일 경우 노드가 출력 노드로 표시됨 |
|
||||
| is_input_list | bool | 선택 | True일 경우 모든 입력이 `list[type]`로 처리됨 |
|
||||
| is_deprecated | bool | 선택 | 노드 폐기 여부 플래[Flag] |
|
||||
| is_experimental | bool | 선택 | 실험적 기능 여부 표시 |
|
||||
| is_dev_only | bool | 선택 | 개발 모드에서만 보이도록 설정 |
|
||||
| is_api_node | bool | 선택 | Comfy API 서비스용 노드로 지정 |
|
||||
| not_idempotent | bool | 선택 | True일 경우 캐싱된 출력을 재사용하지 않고 항상 재실행함 |
|
||||
| enable_expand | bool | 선택 | NodeOutput에 확장 속성 포함 가능 여부 |
|
||||
| accept_all_inputs | bool | 선택 | 스키마에 정의되지 않은 입력도 kwargs로 전달 허용 |
|
||||
|
||||
### 4. Advanced Features (고급 기능)
|
||||
* **Hidden Inputs**: `cls.hidden`을 통해 접근하며, `unique_id`, `prompt`, `extra_pnginfo` 등을 포함함.
|
||||
* **UI Helpers**: `ui.PreviewImage`, `ui.AudioSaveHelper` 등을 사용하여 노드 출력 시 UI 데이터를 반환할 수 있음.
|
||||
* **Custom Types**: `@io.comfytype` 데코레이터나 `io.Custom` 함수를 통해 사용자 정의 타입을 생성 가능함.
|
||||
* **Dynamic Inputs**: `Autogrow`(입력 자동 증가) 및 `DynamicCombo`(옵션에 따라 입력 변경) 기능을 지원함.
|
||||
|
||||
## ⚖️ 모래 및 업데이트 (Contradictions & updates)
|
||||
* **업데이트 사항**: V1의 `IS_CHANGED` 함수가 V3에서는 `fingerprint_inputs`로 명칭이 변경됨 (개발자의 혼동을 방지하기 위함).
|
||||
* **업데이트 사항**: 입력 검증 메서드가 `VALIDATE_INPUTS`에서 `validate_inputs`로 소문자화되어 변경됨.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
* **노드 마이그레이션 프로젝트**: 기존에 운영 중인 V1 기반 커스텀 노드를 최신 ComfyUI 스키마 표준에 맞춰 업데이트할 때 이 가이드를 참조함.
|
||||
* **확장 프로그램 개발**: `ComfyExtension`을 사용하여 새로운 노드 세트를 등록하고, `comfy_entrypoint`를 통해 실행 환경을 구축하는 데 사용됨.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
* [[io.Schema]] - V3 노드의 핵심 정의 구조체.
|
||||
* [[ComfyExtension]] - 확장의 생명주기와 노드 등록을 관리하는 클래스.
|
||||
* [[io.NodeOutput]] - 실행 결과와 UI 데이터를 반환하기 위한 표준 객체.
|
||||
* [[comfy_api.latest]] - 최신 안정화된 API 참조를 위한 패키지.
|
||||
* [[V1 (Legacy)]] - 마이그레이션의 대상이 되는 이전 방식의 노드 구조.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/v3_migration 본문에서 초안 생성.
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
id: workflow-json---comfyui
|
||||
title: "Workflow JSON - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/specs/workflow_json"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Workflow JSON - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
[[ComfyUI]]의 워크플로우를 정의하기 위해 [[JSON Schema]]를 사용하여 구조화된 데이터를 생성하고 관리하는 규격서입니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **JSON Schema 기반 정의**: [[Workflow JSON]]은 [[JSON Schema]]를 사용하여 정의되며, 변경 사항은 [[rfcs repo]]에서 논의됩니다.
|
||||
- **ComfyWorkflow v1.0 구조**: 워크플로우의 핵심 요소로 [[version]], [[state]], [[nodes]]를 필수적으로 포함합니다.
|
||||
- **노드 및 연결 구조**: [[nodes]], [[links]], [[reroutes]] 등 노드의 위치, 크기, 입력/출력 핀(pins) 및 연결 상태를 정의하는 복잡한 객체 모델을 가집니다.
|
||||
- **상태 관리 (State)**: 마지막으로 사용된 그룹 ID, 노드 ID, 링크 ID 등을 포함하여 워크플로우의 연속성을 유지합니다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **계층적 데이터 구조**: [[nodes]] 내부에 [[inputs]], [[outputs]], [[properties]], [[widgets_values]]와 같은 하위 객체를 두어 노드의 동작을 세부적으로 정의하는 패턴을 보입니다.
|
||||
- **좌표 및 경계 정의**: [[groups]]의 [[bounding]]이나 [[nodes]]의 [[pos]], [[size]]를 수치 배열 또는 객체 형태로 정의하여 UI 상의 위치를 결정합니다.
|
||||
- **관계형 연결 (Linking)**: [[links]] 객체를 통해 [[origin_id]]와 [[target_id]] 사이의 관계를 명시적으로 정의합니다.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
### 1. Workflow JSON v1.0 주요 구성 요소
|
||||
- **Version**: 워크플로우 버전은 상수로 `1`을 가집니다.
|
||||
- **Config**: [[links_ontop]] 또는 [[align_to_grid]]와 같은 설정 값을 포함할 수 있습니다.
|
||||
- **State**: [[lastGroupid]], [[lastNodeId]], [[lastLinkId]], [[lastRerouteId]]를 통해 워크플로우의 마지막 상태를 저장합니다.
|
||||
|
||||
### 2. Nodes (노드) 상세 규격
|
||||
- **필수 속성**: [[id]], [[type]], [[pos]], [[size]], [[flags]], [[order]], [[mode]], [[properties]]가 반드시 포함되어야 합니다.
|
||||
- **입력 및 출력**: [[inputs]]와 [[outputs]]는 각각 이름, 타입, 슬롯 인덱스 정보를 포함하며, 노드 간의 데이터 흐름을 제어합니다.
|
||||
- **기타 속성**: [[widgets_values]], [[color]], [[bgcolor]] 등을 통해 시각적 요소와 사용자 입력값을 관리합니다.
|
||||
|
||||
### 3. Links & Reroutes (연결 및 리라우트)
|
||||
- **Links**: [[id]], [[origin_id]], [[target_id]], [[type]] 등을 포함하며 노드 간의 연결을 정의합니다.
|
||||
- **Reroutes**: [[id]], [[pos]], [[linkIds]]를 통해 연결 경로를 재지정하는 역할을 합니다.
|
||||
|
||||
### 4. 기타 데이터 구조
|
||||
- **Groups**: [[title]], [[bounding]], [[color]], [[font_size]], [[locked]] 속성을 가진 그룹 정보를 포함합니다.
|
||||
- **Models**: [[name]], [[url]], [[hash]], [[directory]] 등을 통해 모델 데이터를 관리할 수 있습니다.
|
||||
|
||||
## ⚖️ 모동 및 업데이트 (Contradictions & updates)
|
||||
- **최신 버전 정보**: 현재 최신 버전은 `Version 1.0 (Latest)`로 명시되어 있습니다.
|
||||
- **이전 버전 존재**: `Older versions`에 대한 언급이 있으나, 구체적인 하위 버전의 상세 스키마는 본문에서 확인되지 않음 (단, 0.4 버전 관련 언급 있음).
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **JSON Schema 검증**: [[ComfyUI]] 워크플로우 파일이 규격에 맞게 작성되었는지 검증하는 도구로 활용될 수 있습니다.
|
||||
- **워크플로우 저장 및 공유**: 노드, 링크, 그룹 정보를 JSON 형태로 직렬화하여 다른 사용자에게 전달하거나 재사용할 수 있습니다.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[JSON Schema]]: 워크플로우 데이터의 구조를 정의하고 검증하는 표준 규격입니다.
|
||||
- [[ComfyUI Server]]: 워크플로가 실행되는 백엔드 환경과 관련된 개념입니다.
|
||||
- [[Node Definitions]]: 워크플로우 내 개별 노드의 동작과 속성을 정의하는 기초 정보입니다.
|
||||
- [[rfcs repo]: 스키마 변경 사항이 논의되는 공식적인 저장소입니다.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/specs/workflow_json 본문에서 초안 생성.
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
id: workflow-templates---comfyui
|
||||
title: "Workflow templates - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/workflow_templates"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Workflow templates - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
커스토머 노드 개발자가 `example_workflows` 폴더를 통해 사용자에게 예제 워크플로우를 제공함으로써 [[ComfyUI]] 템플릿 브라우저에 시각적 가이드를 구축하는 방법.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Workflow Templates**: 커스토머 노드와 연관된 예제 워크플로우 파일을 사용자에게 보여주는 기능.
|
||||
- **Template Browser**: `Workflow/Browse Templates` 메뉴를 통해 사용자가 예제 워크플로우를 탐색할 수 있는 인터페이스.
|
||||
- **Static Serving**: [[ComfyUI]] 서버가 `/api/workflow_templates` 엔드포인트를 통해 템플릿 컬렉션을 정적으로 제공함.
|
||||
- **Thumbnail Support**: `.json` 파일과 동일한 이름을 가진 `.jpg` 파일을 배치하여 템플릿의 썸네일로 활용 가능.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **노드 개발자의 워크플로우 지원 전략**: 노드 개발자는 `example_workflows` 폴더를 생성하고 그 안에 `.json` 파일을 배치함으로써 사용자의 초기 진입을 도울 수 있음.
|
||||
- **폴더 명명 규칙의 유연성**: `example_workflows` 외에도 `workflow`, `workflows`, `example`, `examples` 등의 폴차 이름을 사용할 수 있으나, `example_workflows` 사용을 권장함.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
### 🛠️ 구현 방법 (Implementation)
|
||||
- **폴더 구조**: 노드 개발자는 커스텀 노드 디렉토리 내에 `example_workflows` 폴더를 생성해야 합니다.
|
||||
- **파일 구성**:
|
||||
- `.json` 파일: 워크플로우의 핵심 데이터가 담긴 파일입니다.
|
||||
- `.jpg` 파일 (선용적): 동일한 이름을 가진 이미지 파일을 배치하면 템플릿 브라우저에서 썸네일로 표시됩니다.
|
||||
|
||||
### 📂 디렉토리 예시 (Directory Example)
|
||||
`ComfyUI-MyCustomNodeModule/example_workflows/` 경로 내 구성:
|
||||
- `My_example_workflow_1.json`
|
||||
- `My_example_workflow_1.jpg`
|
||||
- `My_example_workflow_2.json`
|
||||
|
||||
### ⚙️ 시스템 동작 (System Behavior)
|
||||
- **엔드포인트**: [[ComfyUI]] 서버는 `/api/workflow_templates` 엔드포인트를 통해 워크플로우 템플릿 컬렉션을 반환합니다.
|
||||
- **카테고리 표시**: 위 예시와 같이 구성될 경우, 템플릿 브라우저에는 `ComfyUI-MyCustomNodeModule`이라는 카테고리와 함께 항목들이 표시됩니다.
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
본문에서 확인되지 않음.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **실제 사례**: `ComfyUI-Impact-Pack`의 `example_workflows` 폴더 구성이 실제 사례로 언급됨.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신ILD:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
- [[ComfyUI]]: 기본 플랫폼 환경.
|
||||
- [[Workflow templates]]: 워크플로우 템플릿의 정의 및 활용법.
|
||||
- [[Custom Nodes]]: 커스텀 노드 개발 및 확장 방법.
|
||||
- [[API Reference]]: 서버 엔드포인트 및 데이터 구조 확인을 위한 참조.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/workflow_templates 본문에서 초안 생성.
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
id: working-with-torchtensor---comfyui
|
||||
title: "Working with torch.Tensor - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.8
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["web", "wikify"]
|
||||
raw_sources: ["https://docs.comfy.org/custom-nodes/backend/tensors"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Working with torch.Tensor - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI의 핵심 연산은 [[pytorch]]를 기반으로 하며, 이미지, Latent, Mask 데이터는 모두 [[torch.Tensor]] 형태로 내부적으로 처리됩니다.
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
* **[[torch.Tensor]]의 정의**: 벡터나 행렬을 임의의 차원으로 일반화한 수학적 구조체로, Rank(차원 수)와 Shape(크기)를 가집니다.
|
||||
* **텐서 조작(Tensor Manipulation)**: 차원을 축소하는 [[squeeze]], 차원을 확장하는 [[unsqueeze]], 그리고 데이터 구조를 재구성하는 [[reshape]] 기법이 포함됩니다.
|
||||
* **Elementwise Operations**: 텐서 간의 연산(+, -, *, /, ==)은 각 요소별로 독립적으로 적용됩니다.
|
||||
* **Tensor Truthiness**: 다중 요소를 가진 텐서는 Python 리스트와 달리 직접적인 Boolean 평가가 불가능하며, [[all()]] 또는 [[any()]] 메서드를 사용해야 합니다.
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
* **차원 관리 전략**: 1의 크기를 가진 차원을 제거하거나(Squeezing) 삽입하는(Unsqueezing) 패턴을 통해 데이터 구조를 제어합니다.
|
||||
* **슬라이싱 관례**: `None`을 사용한 차원 삽입, `:`를 사용한 전체 범위 유지, `...`(Ellipsis)를 사용한 미지정 차원 처리 등의 표준화된 표기법을 따릅니다 Pol.
|
||||
* **연산 제약 조건**: 이항 연산 시 피연산자들은 동일한 Shape을 갖거나, 하나는 스칼라(Scalar)여야 한다는 규칙이 존재합니다.
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 1. Tensor의 구조와 ComfyUI에서의 활용
|
||||
* **기본 정의**: [[torch.Tensor]]는 벡터나 행렬을 임의의 차원으로 일반화한 것입니다.
|
||||
* **Rank**: 텐서가 가진 차원의 수 (예: 벡터는 Rank 1, 행렬은 Rank 2).
|
||||
* **Shape**: 각 차원의 크기를 나타냅니다.
|
||||
* **ComfyUI 이미지 데이터 구조**:
|
||||
* RGB 이미지는 기본적으로 `[H, W, 3]` 형태를 가질 수 있으나, ComfyUI에서는 배치(Batch) 차원을 포함합니다.
|
||||
* 최종 형태: `[B, H, W, C]` (B: Batch, H: Height, W: Width, C: Channels).
|
||||
|
||||
### 2. 차원 조작 및 변형
|
||||
* **Squeezing**: 크기가 1인 차원(collapsed dimension)을 제거하는 작업입니다.
|
||||
* **Unsqueezing**: 새로운 차원을 삽입하는 작업입니다.
|
||||
* **Reshaping**: 데이터 구조를 유지하며 다른 형태로 재표현하는 것으로, 하부 데이터 구조에 대한 주의가 필요합니다.
|
||||
|
||||
### 3. 주요 표기법 (Important Notation)
|
||||
* **`.shape` 속성**: `torch.Size`를 반환하며, 이는 튜플(tuple)의 서브클래스입니다.
|
||||
* **슬라이싱 도구**:
|
||||
* `None`: 슬라이스 내에서 크기가 1인 차원을 삽입할 때 사용합니다.
|
||||
* `:`: 해당 차원의 전체 범위를 유지합니다.
|
||||
* `...` (Ellipsis): 지정되지 않은 나머지 모든 차원을 나타냅니다.
|
||||
* **`-1` 파라미터**: Shape을 전달받는 메서드에서, 전체 데이터 크기를 기반으로 해당 차원의 크기를 자동 계산하도록 지정할 때 사용합니다.
|
||||
|
||||
### 4. 연산 및 논리값 (Operations & Truthiness)
|
||||
* **Elementwise Operations**: `+`, `-`, `*`, `/`, `==` 등의 연산은 요소별로 독립적으로 수행됩니다. 단, 피연산자의 Shape이 동일하거나 하나가 스칼라여야 합니다.
|
||||
* **Truthiness (논리값 판단)**:
|
||||
* 다중 요소를 가진 텐서는 Python의 기본 Boolean 평가 시 `RuntimeError`를 발생시킵니다(Ambiguous 오류).
|
||||
* 따라서 요소 전체의 논리값을 확인하려면 `.all()` 또는 `.any()`를 명시적으로 사용해야 합니다.
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
* **주의사항**: 일부 커스텀 노드 작성자가 차원이 축소된(squeezed) 텐서를 반환하는 경우가 있으며, 이는 버그의 주요 원인이 될 수 있습니다.
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
* **이미지 처리**: `[B, H, W, 3]` 형태의 텐서 구조를 사용하여 배치 단위로 이미지를 처리합니다.
|
||||
* **코드 예시**:
|
||||
* `a = torch.Tensor((1,2))` $\rightarrow$ `a.shape` 결과: `torch.Size([2])` (본문 내 예시 기준)
|
||||
* `a[:, None].shape` $\rightarrow$ 차원 확장 사례.
|
||||
* `a.reshape((1, -1))` $\rightarrow$ 자동 크기 계산 활용 사례.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual
|
||||
- **출처 신뢰도:** B (Primary Source — 웹사이트 본문 직접 추출)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 🔗 관련 문서 링크 (Related document links)
|
||||
* [[pytorch]]: ComfyUI의 핵심 수치 연산을 담당하는 라이브러리입니다.
|
||||
* [[torch.Tensor]]: 이미지, Latent, Mask를 표현하는 기본 데이터 구조입니다.
|
||||
* [[squeeze]], [[unsqueeze]], [[reshape]]: 텐서의 차원을 제어하는 주요 기법들입니다.
|
||||
* [[all()]] / [[any()]]: 텐서의 논리적 참/거짓을 판별하기 위해 필요한 메서드입니다.
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Astra /wikify 로 https://docs.comfy.org/custom-nodes/backend/tensors 본문에서 초안 생성.
|
||||
Vendored
BIN
Binary file not shown.
Vendored
+1
-1
@@ -17,6 +17,6 @@
|
||||
"repelStrength": 10,
|
||||
"linkStrength": 1,
|
||||
"linkDistance": 250,
|
||||
"scale": 0.19926643092553617,
|
||||
"scale": 0.06501612612551483,
|
||||
"close": true
|
||||
}
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
id: /prompt-endpoint
|
||||
title: "/prompt endpoint"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy_api_python.py", "/workflow/convert", "new_pipeline.py", "comfyui_to_python.py"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[/prompt endpoint]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
`/prompt endpoint`는 시각적 노드 그래프를 실행 가능한 백엔드 명령으로 전환하여 ComfyUI의 강력한 생성 능력을 외부 애플리케이션 및 자동화 파이프라인과 연결하는 핵심 게이트웨이이다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **API Format (Backend Format):** `/prompt` 엔드포인트는 시각적 메타데이터가 제거되고 실행에 필수적인 노드 입력 및 연결 정보만 포함된 전용 JSON 형식을 요구한다 [1, 4, 5].
|
||||
- **Flattened Execution Graph:** 엔드포인트에 전달되는 데이터는 링크가 노드 입력 내부에 직접 삽입된 형태로, 백엔드 엔진이 즉시 처리할 수 있도록 최적화된 구조를 가진다 [1, 6, 7].
|
||||
- **Programmatic Interaction:** HTTP POST 요청을 통해 JSON 페이로드를 전송함으로써 GUI 없이도 워크플로우를 실행하고 실시간으로 파라미터를 수정할 수 있다 [8-10].
|
||||
- **Self-Contained Requests:** 이미지 입력을 Base64로 인코딩하여 JSON 내에 직접 포함시킴으로써 별도의 파일 저장 없이도 서버 사이드 처리가 가능한 독립적인 생성 요청을 구성한다 [10, 11].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **UI-API 분리 패턴:** 사용자 인터페이스를 위한 `workflow.json`(Frontend)과 실제 실행을 위한 `workflow_api.json`(Backend)을 엄격히 구분하여 효율성을 극대화한다 [4, 12, 13].
|
||||
- **직접 딕셔너리 조작(Direct Dictionary Manipulation):** Python 등의 언어로 JSON 파일을 로드한 후, 노드 ID를 키로 사용하여 프롬프트나 시드(Seed) 값을 동적으로 교체하는 패턴이 주로 사용된다 [9, 10].
|
||||
- **웹소켓(WebSocket) 결합 구조:** `/prompt` 엔드포인트로 작업을 큐잉(Queueing)한 후, `/ws` 엔드포인트를 통해 진행 상황과 최종 생성된 바이너리 데이터를 실시간으로 수신한다 [10].
|
||||
- **실행 모델 인버전(Execution Model Inversion):** 백엔드 엔진은 전달된 JSON에서 최종 출력 노드(Save Image 등)부터 역추적하여 필요한 노드만 실행하는 최적화 로직을 수행한다 [14].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
`/prompt endpoint`는 ComfyUI 서버가 외부로부터 실행 명령을 받는 표준 HTTP API 경로이다 [3, 10]. 이 엔드포인트는 일반적인 저장용 JSON(Frontend Format)과 호환되지 않으며, 반드시 **'Dev mode Options'**를 활성화하여 추출한 **API Format JSON**을 페이로드로 사용해야 한다 [8, 15, 16].
|
||||
|
||||
API 요청 시 JSON의 루트 키는 노드 ID(숫자 또는 문자열)가 되며, 각 값은 해당 노드의 `class_type`과 `inputs`를 포함하는 객체로 구성된다 [9, 17]. 이때 입력 필드는 단순한 값뿐만 아니라 다른 노드의 출력 슬롯에 대한 참조(`[node_id, slot_index]`)를 포함하여 데이터 흐름을 정의한다 [6].
|
||||
|
||||
서버는 요청을 받으면 내부적으로 `validate_prompt` 함수를 호출하여 그래프의 무결성을 검증한 후, 이를 `ExecutionList`로 변환하여 순차적으로 노드를 실행한다 [18]. 만약 워크플로우에 필요한 커스텀 노드가 로컬 서버에 설치되어 있지 않으면 실행이 거부되므로, ComfyUI Manager 등을 통한 사전 의존성 해결이 필수적이다 [19-21].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **호환성 문제:** 일반적인 `Save` 버튼으로 생성된 JSON을 `/prompt` 엔드포인트에 직접 전송하면 에러가 발생한다 [16]. 반드시 `Save (API Format)`를 사용하거나 별도의 변환 도구를 거쳐야 한다 [15, 16].
|
||||
- **메타데이터 손실:** API 형식으로 변환된 JSON은 노드 위치나 그룹 정보가 모두 삭제되므로, 이를 다시 ComfyUI 캔버스에 드래그하면 시각적 레이아웃이 파괴된 "뼈대" 형태만 남게 된다 [22]. 따라서 원본 워크플로우 파일의 별도 보관이 권장된다 [22].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **comfy_api_python.py:** Python의 `urllib.request`를 사용하여 `http://{server_address}/prompt` 경로에 JSON 데이터를 POST 방식으로 전송하는 실제 구현 코드가 포함되어 있음 [10].
|
||||
- **/workflow/convert 엔드포인트:** 시각적 워크플로우 JSON을 서버 사이드에서 즉시 API 형식으로 변환하여 `/prompt` 엔드포인트에 바로 보낼 수 있도록 지원하는 커스텀 노드가 개발됨 [16, 21].
|
||||
- **Mystic Pipeline (new_pipeline.py):** 클라우드 환경에서 ComfyUI 서버를 구동하고 사용자 입력을 워크플로우 JSON에 주입하여 실행하는 파이프라인 자동화에 적용됨 [23, 24].
|
||||
- **ComfyUI-to-Python-Extension:** API 포맷의 워크플로우 JSON을 독립적으로 실행 가능한 `.py` 스크립트로 변환하는 CLI 도구 및 라이브러리 구조에서 핵심 참조 대상으로 사용됨 [25, 26].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 발견됨)
|
||||
- **출처 신뢰도:** B (Official Documentation / API Docs / GitHub Source Code)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
id: api-json-(backend-format)
|
||||
title: "API JSON (Backend Format)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["workflow_api.json", "Backend Format"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow_api.json", "/workflow/convert", "new_pipeline.py", "SaveImageWebsocket"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[API JSON (Backend Format)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
API JSON은 UI 메타데이터를 배제하고 실행 로직과 데이터 흐름만을 압축하여 서버 측 실행 및 프로그래밍 방식의 자동화에 최적화된 백엔드 전용 워크플로우 규격이다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **실행 중심 그래프 (Execution Graph):** 위치, 크기, 색상 등 시각적 요소를 제거하고 엔진이 노드를 처리하는 데 필요한 핵심 논리 구조만 포함한다 [1, 3, 4].
|
||||
2. **참조 기반 노드 연결:** 링크 객체를 별도로 관리하는 대신 노드 입력(`inputs`) 필드 내에 소스 노드 ID와 출력 슬롯 인덱스를 직접 배열(예: `[node_id, slot_index]`) 형태로 임베딩한다 [1, 5, 6].
|
||||
3. **데이터 경량화:** 시각적 메타데이터 제거를 통해 프런트엔드 JSON보다 파일 크기가 훨씬 작으며, 네트워크 전송 및 API 호출 페이로드로 사용하기에 적합하다 [2, 7, 8].
|
||||
4. **개발자 모드 활성화:** 표준 저장 방식과 달리 ComfyUI 설정에서 'Dev mode'를 명시적으로 활성화해야만 생성 및 내보내기가 가능하다 [9-11].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **노드 ID 키 매핑 패턴:** JSON의 루트 레벨에서 각 노드의 고유 숫자 ID(문자열 형태)를 키값으로 사용하며, 그 내부에 `class_type`과 `inputs`를 정의한다 [3, 12, 13].
|
||||
- **입출력 노드 최적화:** API 활용 시 이미지를 웹소켓으로 직접 수신하기 위해 `SaveImageWebsocket` 노드를 사용하거나, `Load Image (Base64)`를 통해 이미지 데이터를 직접 주입하는 구조를 취한다 [14].
|
||||
- **역방향 그래프 탐색:** 백엔드 엔진은 API JSON을 실행할 때 출력 노드(예: Save Image)부터 역방향으로 탐색하여 결과 도출에 필요한 종속 노드만 식별하고 실행한다 [15].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
API JSON(일반적으로 `workflow_api.json`으로 명명)은 ComfyUI의 백엔드 엔진과 직접 통신하는 언어 역할을 수행한다 [1, 2, 16].
|
||||
|
||||
- **프런트엔드 포맷과의 차별성:** 표준 `workflow.json`이 인간의 가독성과 편집 편의성을 위해 노드 좌표(`pos`), 크기(`size`), 그룹, 위젯 상태(`flags`) 등을 포함하는 것과 달리, API 포맷은 이러한 정보를 모두 폐기하고 오직 실행에 필요한 데이터만 남긴다 [1-3, 17, 18].
|
||||
- **내부 구조 분석:**
|
||||
- **`class_type`:** 노드 레지스트리에 등록된 실제 Python 클래스 이름을 참조한다 [4, 12, 19].
|
||||
- **`inputs`:** 위젯 값(텍스트, 숫자 등)과 다른 노드로부터 오는 동적 링크 정보를 모두 포함한다 [4, 5].
|
||||
- **생성 프로세스:**
|
||||
1. ComfyUI 설정 아이콘을 클릭한다 [9, 10, 20].
|
||||
2. 'Enable Dev mode Options' 체크박스를 활성화한다 [9-11].
|
||||
3. 메인 메뉴에 새로 나타난 'Save (API Format)' 버튼을 클릭하여 다운로드한다 [10, 11, 21].
|
||||
- **이미지 메타데이터와의 관계:** ComfyUI에서 생성된 PNG 파일의 메타데이터에는 프런트엔드 포맷(workflow)과 API 포맷(prompt) 데이터가 동시에 저장되어 있어, 이미지만으로도 시각적 복구와 프로그래밍 방식의 재실행이 모두 가능하다 [8, 22, 23].
|
||||
- **자동화 및 확장:** Python의 `json` 라이브러리를 사용하여 노드 ID를 기반으로 프롬프트나 시드 값을 동적으로 변경한 후 서버의 `/prompt` 엔드포인트로 전송하여 대량의 이미지를 생성할 수 있다 [6, 12, 14].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **가역성의 한계:** API JSON을 다시 ComfyUI 인터페이스로 드래그하여 불러올 경우, 시각적 위치 정보가 없기 때문에 노드들이 모두 겹쳐서 나타나는 '스켈레톤(skeleton)' 상태가 된다 [24]. 따라서 재편집을 위해서는 반드시 원본 프런트엔드 포맷을 별도로 보관해야 한다 [24].
|
||||
- **버전 호환성 문제:** ComfyUI의 빈번한 업데이트로 인해 구버전 JSON 파일이 최신 버전에서 정상적으로 작동하지 않을 수 있으며, 특히 커스텀 노드 의존성이 있는 경우 더욱 빈번하게 발생한다 [25].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **RunComfy Serverless API:** `workflow_api.json`을 내부적으로 저장하여 서버리스 실행 시 베이스라인으로 활용하며, API 호출 시 입력값만 오버라이드한다 [4, 16].
|
||||
- **Mystic Pipeline (`new_pipeline.py`):** Python SDK를 통해 ComfyUI 서버를 시작하고 API 포맷 JSON에 프롬프트를 주입하여 실행하는 템플릿에 적용됨 [26, 27].
|
||||
- **ComfyUI Workflow Converter (`bc85382`):** `/workflow/convert` 엔드포인트를 통해 비 API 포맷(Frontend)을 실시간으로 API 포맷으로 변환하여 `/prompt` 엔드포인트에 즉시 사용할 수 있도록 지원 [28-30].
|
||||
- **SaveImageWebsocket 노드:** API 환경에서 생성된 이미지를 파일 저장 대신 웹소켓을 통해 실시간 바이너리로 수신할 때 사용됨 [14].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
id: api-json-(workflow_api.json)
|
||||
title: "API JSON (workflow_api.json)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["Backend Format", "API Format JSON", "Execution Graph"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법", "API", "JSON"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["SethRobinson/comfyui-workflow-to-api-converter-endpoint", "fofr/any-comfyui-workflow", "Mystic Pipeline", "ComfyUI-to-Python-Extension"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[API JSON (workflow_api.json)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
API JSON은 ComfyUI의 시각적 메타데이터를 제거하고 백엔드 엔진의 즉각적인 실행을 위해 최적화된 경량화된 실행 그래프 형식이다 [1], [2], [3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **백엔드 실행 그래프 (Backend Execution Graph):** 노드 위치, 크기, 색상 등의 UI 정보를 배제하고 오직 노드 유형, 입력값, 연결 관계만을 포함하는 실행 전용 데이터 구조이다 [1], [4], [3].
|
||||
- **직접 링크 임베딩 (Direct Link Embedding):** 연결 정보가 별도의 객체 배열로 관리되지 않고, 각 노드의 입력 필드 내에 소스 노드 ID와 출력 슬롯 번호의 참조(`[node_id, slot_index]`) 형태로 직접 포함된다 [1], [2], [5].
|
||||
- **개발자 모드 의존성 (Dev Mode Dependency):** 표준 내보내기(Save)와 달리, ComfyUI 설정에서 'Enable Dev mode Options'를 활성화해야만 생성 및 수동 추출이 가능하다 [6], [7], [8], [9].
|
||||
- **프로그래밍적 제어 (Programmatic Control):** 텍스트 프롬프트, 시드(Seed) 등 위젯 값을 노드 ID를 통해 직접 수정할 수 있어 외부 애플리케이션 및 스크립트와의 자동화 연동에 핵심적인 역할을 한다 [10], [11], [12].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **UI-Stripping 패턴:** 시각적 요소(Litegraph 메타데이터)를 삭제하여 파일 크기를 축소하고 데이터 파싱 속도를 향상시킨다 [1], [13], [3].
|
||||
- **ID 기반 맵 구조:** 전체 JSON 구조가 노드 ID를 키(Key)로 하고 노드 정의(Inputs, Class Type)를 값(Value)으로 하는 단일 딕셔너리 형태를 취한다 [10], [14].
|
||||
- **입력 우선주의 (Execution Model Inversion):** 백엔드 엔진이 출력 노드(Save Image 등)로부터 역추적하여 필요한 노드만 실행하도록 하는 구조적 기반을 제공한다 [15].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **데이터 구조 및 구성 요소:** API JSON의 각 노드 객체는 해당 노드의 클래스 이름을 나타내는 `class_type`과 노드에 전달될 데이터인 `inputs`를 필수적으로 포함한다 [10], [3]. `inputs` 내에는 사용자가 직접 입력한 위젯 값과 다른 노드에서 전달되는 링크 정보가 공존한다 [5].
|
||||
- **프론트엔드 형식과의 차이:** 시각적 편집을 위한 `workflow.json`은 노드 위치(`pos`), 크기(`size`), 그룹 정보 등을 포함하여 다시 불러왔을 때 캔버스를 재구성할 수 있게 하지만, API JSON은 이를 모두 제거하여 "스켈레톤(skeleton)" 상태의 데이터만 남긴다 [1], [13], [16].
|
||||
- **생성 및 변환 프로세스:**
|
||||
- **수동 생성:** ComfyUI 설정 메뉴의 기어 아이콘을 클릭하여 'Enable Dev mode Options'를 활성화한 후, 메뉴 상단에 나타나는 'Save (API Format)' 버튼을 사용한다 [6], [7], [8].
|
||||
- **자동 추출:** ComfyUI에서 생성된 PNG/WebP 파일의 메타데이터(tEXt 또는 zTXt 청크)에서 `prompt` 태그를 통해 API 형식을 추출할 수 있다 [17], [18], [19].
|
||||
- **서버측 변환:** `comfyui-workflow-to-api-converter-endpoint`와 같은 커스텀 노드를 사용하여 일반 워크플로우 JSON을 API 형식으로 실시간 변환하여 `/prompt` 엔드포인트로 전송할 수 있다 [20], [21].
|
||||
- **실행 환경에서의 활용:** API JSON은 파이썬 스크립트에서 `urllib`이나 `requests`를 통해 ComfyUI 서버의 `/prompt` 경로로 POST 요청을 보낼 때 페이로드(Payload)로 사용된다 [11], [22]. 또한 Replicate와 같은 클라우드 플랫폼에서 서버리스 엔드포인트를 구동하는 기본 사양으로 채택된다 [23], [24], [4].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **가역성 상실:** API JSON을 ComfyUI 캔버스로 다시 드래그하면 시각적 레이아웃 정보가 없기 때문에 모든 노드가 겹쳐서 나타나거나 그룹 정보가 유실되어 수동 편집이 매우 어렵다 [16]. 따라서 편집용 'Full Workflow'를 항상 별도로 보관하는 것이 권장된다 [16].
|
||||
- **버전 호환성 주의:** ComfyUI의 잦은 업데이트로 인해 이전 버전에서 생성된 API JSON이 최신 백엔드 엔진에서 유효하지 않은 노드 클래스나 입력 방식을 참조할 경우 실행 오류가 발생할 수 있다 [25], [26].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **SethRobinson/comfyui-workflow-to-api-converter-endpoint:** 클라이언트 측의 자바스크립트 변환 로직을 파이썬으로 구현하여, 서버 측에서 비-API 워크플로우를 API 형식으로 즉시 변환해주는 커스텀 노드 (Commit: `bc85382`) [27], [20].
|
||||
- **fofr/any-comfyui-workflow (Replicate):** 사용자가 제공한 API JSON 블롭(blob)을 해석하여 이미지 및 비디오를 생성하는 범용 API 모델 [23], [24].
|
||||
- **Mystic Pipeline:** `new_pipeline.py` 스크립트를 통해 API JSON 워크플로우를 로드하고 입력 프롬프트를 동적으로 주입하여 서버리스 엔드포인트로 배포하는 구조 [9], [28].
|
||||
- **ComfyUI-to-Python-Extension:** API JSON 파일을 입력받아 독립적으로 실행 가능한 파이썬 스크립트(`.py`)로 변환하는 도구 [29], [30].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 발견으로 검증 가능성 높음)
|
||||
- **출처 신뢰도:** B (공식 문서 및 주요 오픈소스 프로젝트 기술 사양 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
id: base64-image-encoding
|
||||
title: "Base64 Image Encoding"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["이미지 Base64 인코딩", "Base64 Data Embedding"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.90
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법", "API", "Python"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy_api_python.py"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Base64 Image Encoding]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Base64 인코딩은 별도의 파일 스토리지 없이 이미지 바이너리를 문자열로 변환하여 ComfyUI API JSON 페이로드에 직접 포함시킴으로써 워크플로우를 데이터-논리 통합형 자립 구조로 변환하는 핵심 기술이다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Load Image (Base64) 노드:** 워크플로우 내에서 파일 경로 대신 Base64 인코딩 문자열을 직접 입력받아 이미지 데이터로 변환하는 전용 입력 노드이다 [1, 2].
|
||||
- **데이터 임베딩(Self-contained Request):** 이미지 원천 데이터를 JSON의 `inputs` 필드 내 `base64_data` 키에 직접 삽입하여, 요청 하나에 생성 로직과 원본 데이터를 동시에 전달한다 [1, 2].
|
||||
- **서버리스 스토리지 우회:** 서버에 임시 이미지 파일을 생성하거나 업로드 경로를 관리할 필요가 없어, 스테이트리스(Stateless) API 환경에서의 처리 효율성을 극대화한다 [1].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **동적 페이로드 수정 패턴:** 템플릿 JSON 파일을 로드한 후, 특정 노드 ID(예: #37)의 `inputs` 딕셔너리에 접근하여 실시간으로 인코딩된 문자열을 주입하는 방식을 취한다 [2, 3].
|
||||
- **Python 기반 인코딩 파이프라인:** `open(file, "rb")` -> `base64.b64encode()` -> `.decode("utf-8")` 과정을 거쳐 JSON 규격에 맞는 문자열을 생성한다 [2].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로우를 API로 호출할 때, 특히 이미지-투-이미지(Img2Img)나 컨트롤넷(ControlNet)과 같이 입력 이미지가 필요한 경우 Base64 인코딩이 광범위하게 활용된다 [1].
|
||||
|
||||
1. **API 전송 메커니즘:** 개발자는 이미지를 문자열로 인코딩한 뒤, API 포맷 JSON(workflow_api.json)의 관련 노드 입력값에 이를 할당한다. 이는 서버 사이드에서 이미지 파일을 따로 찾을 필요가 없게 만들어준다 [1].
|
||||
2. **구현 방법:** Python 환경에서는 내장 `base64` 라이브러리를 사용하여 이미지 파일의 바이너리를 읽고 이를 UTF-8 문자열로 변환한다. 이후 워크플로우 JSON 객체를 딕셔너리로 다루어 해당 노드 ID의 `base64_data` 필드 값을 교체한다 [2].
|
||||
3. **효율성 및 용도:** 배너 광고 자동 생성 시스템이나 스타일 전송(Style Transfer) 등 대량의 이미지를 동적으로 처리해야 하는 운영 환경에서, 파일 시스템 입출력(I/O) 오버헤드를 줄이기 위해 권장된다 [1, 4].
|
||||
4. **제약 사항:** 소스에 따르면 워크플로우의 전체 크기가 1MB를 초과할 경우 보안 및 성능상의 이유로 제한될 수 있으므로, 고해상도 이미지 임베딩 시 페이로드 크기 관리가 필요하다 [5, 6].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **데이터 관리의 이중성:** 이미지 임베딩은 별도 저장소가 필요 없어 편리하지만, JSON 파일 자체의 크기를 비대하게 만들어 네트워크 전송 지연을 초래할 수 있다는 점이 간접적으로 시사된다 [5, 7].
|
||||
- **전용 노드 필요성:** 표준 `Load Image` 노드는 서버 내 로컬 경로를 참조하므로, Base64 데이터를 처리하기 위해서는 반드시 `Load Image (Base64)`와 같은 커스텀 노드가 워크플로우에 포함되어 있어야 한다 [1, 2].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Python API 연동 스크립트:** 소스 [2]에서 `image_base64(filename)` 함수를 통해 이미지를 인코딩하고, `prompt[str(load_image_node_id)]["inputs"]["base64_data"] = image` 형태로 데이터를 주입하는 실무 코드가 확인되었다.
|
||||
- **배너 자동 생성 워크플로우:** 이미지 데이터를 동적으로 교체하여 배너 광고를 생성하는 프로젝트에서 실제 적용 사례로 언급되었다 [4].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (제시된 Python 코드를 통해 실제 구현 방법이 구체적으로 명시됨)
|
||||
- **출처 신뢰도:** B (공식 가이드 및 전문 기술 블로그를 통한 검증)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
id: comfy-nodekit
|
||||
title: "Comfy Nodekit"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["Comprehensive Architectures for ComfyUI Workflow JSON Generation and Serialization"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Comfy Nodekit]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Comfy Nodekit은 수동적인 딕셔너리 조작 대신 타입 안전성이 보장된 **Python 우선 방식(Python-first approach)**을 통해 ComfyUI 워크플로를 프로그래밍적으로 구축하고 직렬화하는 라이브러리이다 [1].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **타입 안전한 워크플로 구축:** 원시 JSON 딕셔너리를 직접 수정하는 대신, 정적 타입을 지원하는 Python 환경에서 워크플로를 설계하여 오류를 최소화한다 [1].
|
||||
- **노드 팩토리(Node Factories):** 서버에 설치된 커스텀 노드와 자동으로 동기화되는 노드 팩토리를 제공하여 사용 가능한 노드를 정확하게 반영한다 [1].
|
||||
- **복잡성 관리:** 수백 개의 노드로 구성된 복잡한 그래프를 다룰 때 발생할 수 있는 참조 오류와 구조적 결함을 줄이는 데 최적화되어 있다 [1].
|
||||
- **프로그래밍적 직렬화:** Python 코드를 통해 정의된 노드 관계를 ComfyUI가 실행 가능한 JSON 포맷으로 변환하는 기능을 수행한다 [1, 2].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **추상화 패턴:** 노드의 고유 ID(numeric ID)를 직접 지정하는 파편화된 방식에서 벗어나, 프로그래밍 언어의 객체와 함수를 통해 논리적 구조를 정의하는 추상화 계층을 형성한다 [1, 3].
|
||||
- **서버-클라이언트 동기화:** 로컬의 개발 도구가 서버의 실제 노드 레지스트리 상태를 실시간 또는 주기적으로 반영하여 호환성을 보장하는 설계 패턴을 따른다 [1].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
Comfy Nodekit은 ComfyUI가 단순한 시각적 도구를 넘어 **운영 환경(Production environments)**으로 확장됨에 따라 발생하는 프로그래밍적 요구를 충족하기 위해 설계되었다 [1, 3]. 기존의 수동 JSON 편집 방식은 노드 ID가 변경되거나 워크플로가 복잡해질 때 매우 취약해지는 단점이 있다 [1].
|
||||
|
||||
이 라이브러리는 다음과 같은 기술적 특징을 가진다:
|
||||
- **딕셔너리 조작의 대체:** 개발자가 `json` 라이브러리를 사용하여 중첩된 딕셔너리 구조를 일일이 탐색하고 수정할 필요가 없도록 만든다 [1, 3].
|
||||
- **자동 동기화:** 사용자의 ComfyUI 서버에 설치된 커스텀 노드들을 인식하고 이에 대응하는 Python 인터페이스를 자동으로 생성하여 개발 효율성을 높인다 [1].
|
||||
- **대규모 그래프 지원:** 수백 개의 연결 노드가 존재하는 대규모 프로젝트에서도 타입 체크를 통해 연결 오류를 사전에 방지할 수 있는 'Python-first' 워크플로 빌드 환경을 제공한다 [1].
|
||||
|
||||
이는 "Comfy API Simplified"가 노드 제목(Title)을 기준으로 파라미터를 설정하는 방식이나, "ComfyUI-to-Python-Extension"이 기존 JSON을 Python 스크립트로 변환하는 방식과는 차별화된, **코드 기반의 신규 생성 및 관리**에 초점을 맞춘 도구이다 [1].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **접근 방식의 차이:** 일반적인 사용자가 GUI를 통해 JSON을 내보내는 방식과 달리, 개발자가 처음부터 코드로 워크플로를 작성하는 방식을 제안하며, 이는 시각적 프로그래밍과 텍스트 기반 프로그래밍 사이의 브릿지 역할을 수행한다 [1, 4].
|
||||
- **최신성:** LLM을 이용한 자연어 기반 JSON 생성 방식이 등장하는 등 워크플로 생성 기술이 진화하는 과정에서, Nodekit은 코드의 엄격함과 안전성을 강조하는 전문 개발자용 도구로서 위치한다 [1, 5].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **운영 환경의 워크플로 생성:** "Comprehensive Architectures for ComfyUI Workflow JSON Generation and Serialization" 문서에서 프로그래밍적 워크플로 생성 및 수정을 위한 주요 래퍼 라이브러리 중 하나로 인용되었다 [1, 2].
|
||||
- **Hacker News 사례:** "Show HN: Comfy Nodekit – build/serialize ComfyUI workflows in Python"이라는 제목으로 공개되어, Python 환경 내에서 ComfyUI 워크플로를 구축하고 직렬화하는 실제 구현 사례로 제시되었다 [2].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: comfygpt
|
||||
title: "ComfyGPT"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["ComfyUI-WorkflowGenerator"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI-WorkflowGenerator", "Workflow Generator Pipeline node", "UpdateNodeCatalog", "ComfyUI/models/LLM/"]
|
||||
github_commit: "82df278"
|
||||
---
|
||||
|
||||
# [[ComfyGPT]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
자연어 설명을 다단계 LLM 에이전트 파이프라인을 통해 실행 가능한 ComfyUI 노드 그래프(JSON)로 자동 변환하는 자기 최적화 시스템 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **3단계 생성 파이프라인 (Three-stage Pipeline):** 사용자의 의도를 논리적 합성(Generator), 의미론적 검증(Validator), 그래프 컴파일(Builder) 과정으로 분리하여 처리하는 아키텍처 [2, 3].
|
||||
- **의미론적 노드 매핑 (Semantic Node Mapping):** 훈련 데이터에 없는 최신 커스텀 노드를 인식하기 위해 로컬 설치된 노드 레지스트리 및 의미론적 임베딩을 활용하여 노드 이름을 수정하는 메커니즘 [2, 4].
|
||||
- **특화 LLM 통합 (Specialized LLM Integration):** ComfyUI의 내부 노드 레지스트리 및 스키마 사양에 맞춰 미세 조정(Fine-tuned)된 모델(Qwen2.5-14B 등)을 핵심 엔진으로 사용 [4, 5].
|
||||
- **노드 카탈로그 자동화 (Node Cataloging):** 로컬 환경의 기본 노드 및 커스텀 노드를 스캔하여 LLM이 참조할 수 있는 데이터베이스를 구축하는 프로세스 [6, 7].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **논리-물리 분리 패턴:** 자연어 의도를 먼저 논리적인 그래프 구조로 합성한 뒤, 실제 로컬 환경의 가용 노드와 대조하여 실행 가능한 물리적 JSON으로 변환하는 '중계 컴파일' 패턴 [2, 8].
|
||||
- **검증 기반 보정 패턴:** LLM이 생성한 노드 이름이 실제 환경과 다를 경우, 의미론적 유사도 검색을 통해 유효한 노드 이름으로 교정하는 가디언(Guardian) 패턴 [9, 10].
|
||||
- **계층적 에이전트 협업:** 단일 노드가 아닌 Generator, Validator, Builder라는 독립적인 역할을 가진 에이전트들이 순차적으로 결과를 전달하며 최종 워크플로우를 완성하는 다단계 협업 구조 [2, 9].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyGPT는 "ComfyGPT: A Self-Optimizing Multi-Agent System for Comprehensive ComfyUI Workflow Generation" 연구를 기반으로 하며, 사용자의 자연어 지시(예: "SDXL을 사용한 텍스트-투-이미지 워크플로우 생성")와 실제 실행 가능한 노드 그래프 사이의 간극을 좁히는 것을 목적으로 한다 [1, 2].
|
||||
|
||||
**1. 주요 파이프라인 단계 [2, 3, 8]:**
|
||||
- **생성기 (Generator):** 사용자의 자연어 프롬프트를 해석하여 논리적 그래프 구조(JSON)를 생성한다. Qwen2.5-14B와 같이 워크플로우 데이터에 특화된 모델이 사용된다.
|
||||
- **검증기 (NodeValidator):** 생성된 노드 이름이 로컬 ComfyUI 환경에 설치된 노드와 일치하는지 확인한다. 불일치 시 의미론적 검색(MiniLM 모델 활용) 또는 LLM 정제 모드를 통해 이름을 교정한다.
|
||||
- **빌더 (WorkflowBuilder):** 검증된 논리 구조를 ComfyUI 실행 엔진이 즉시 인식할 수 있는 최종 API 형식 또는 프론트엔드 형식의 JSON 파일로 컴파일한다.
|
||||
|
||||
**2. 활용 모델 아키텍처 [4, 11]:**
|
||||
- **WorkflowGenerator:** Qwen2.5-14B 기반 미세 조정 모델로, 128K 컨텍스트 윈도우를 지원하며 GGUF 형식으로 양자화되어 효율적인 추론이 가능하다.
|
||||
- **Embedding Model:** `sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2`를 사용하여 노드 간의 의미론적 유사도를 계산한다.
|
||||
- **NodeValidator:** Qwen2.5-7B-Instruct 모델을 사용하여 추가적인 LLM 정제를 수행할 수 있다.
|
||||
|
||||
**3. 로컬 환경 동기화:**
|
||||
시스템의 신뢰도를 높이기 위해 `UpdateNodeCatalog` 노드를 통해 현재 설치된 모든 커스텀 노드를 스캔하고 카탈로그화해야 한다. 이는 LLM이 훈련 컷오프 이후에 출시된 새로운 노드를 인식하지 못하는 한계를 보완한다 [6, 7].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **정적 모델의 한계:** 미세 조정된 모델은 훈련 시점 이후에 출시된 노드에 대해 환각(Hallucination)을 일으킬 수 있다. 소스에서는 이를 해결하기 위해 향후 RAG(검색 증강 생성) 아키텍처로의 전환이 필요함을 시사한다 [12, 13].
|
||||
- **I/O 타입 인식 부재:** 현재 시스템은 노드 이름의 의미론적 일치에는 강점이 있으나, 노드 간 데이터 타입(Float, Latent, Image 등)의 엄격한 스키마 호환성을 검증하는 기능은 아직 미래 과제로 남아있다 [13].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI-WorkflowGenerator:** DanielPFlorian이 개발한 GitHub 저장소(`DanielPFlorian/ComfyUI-WorkflowGenerator`)에 ComfyGPT 아키텍처가 네이티브 노드 세트로 구현되어 있다 [1, 14].
|
||||
- **Workflow Generator Pipeline 노드:** Generator, Validator, Builder 단계를 단일 실행으로 통합한 원클릭 솔루션 노드로 구현되었다 [3, 6].
|
||||
- **모델 경로 규격:** GGUF 모델 및 토크나이저를 `ComfyUI/models/LLM/` 경로에 배치하여 관리하는 방식이 적용되었다 [6].
|
||||
- **GitHub 커밋:** 커밋 해시 `82df278`에서 드롭다운 모델 중복 수정 등의 유지보수 기록이 발견된다 [14].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (ComfyUI-WorkflowGenerator 프로젝트를 통해 실제 노드 형태로 구현됨)
|
||||
- **출처 신뢰도:** B (GitHub 기술 문서 및 연구 기반 구현체 소스 코드 설명)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
id: comfyui-api-integration
|
||||
title: "ComfyUI API Integration"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfyui-workflow-to-api-converter-endpoint/README.md", "pydn/ComfyUI-to-Python-Extension", "deimos-deimos/comfy_api_simplified/examples", "Mystic/pipeline.yaml", "Mystic/new_pipeline.py", "DanielPFlorian/ComfyUI-WorkflowGenerator"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[ComfyUI API Integration]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI API Integration은 시각적 노드 그래프를 실행 최적화된 **API JSON(Backend Format)**으로 직렬화하여, 외부 애플리케이션 및 서버리스 환경에서 생성 AI 워크플로우를 프로그래밍 방식으로 자동화하고 확장하는 핵심 매개체이다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **워크플로우 포맷의 이분화 (Bifurcation):** 사용자의 시각적 편집을 위한 'Frontend Format(workflow.json)'과 서버 실행을 위해 UI 메타데이터를 제거한 'API Format(workflow_api.json)'으로 구분된다 [2, 4-6].
|
||||
- **API JSON 직렬화:** 노드 위치, 크기, 그룹 등 시각적 정보를 배제하고 노드 클래스(class_type), 입력 매개변수(inputs), 노드 간 연결 관계만을 포함하는 압축된 실행 그래프이다 [2, 6, 7].
|
||||
- **개발자 모드 (Dev Mode):** 표준 UI에서는 숨겨져 있으며, 설정에서 활성화해야만 API 전용 JSON을 내보낼 수 있는 기능이 활성화된다 [8-12].
|
||||
- **엔드포인트 연동:** 생성된 API JSON은 ComfyUI 서버의 `/prompt` 엔드포인트로 전송되어 실제 이미지나 미디어 생성 명령으로 변환된다 [2, 4, 12, 13].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **개발자 모드 활성화 패턴:** `Settings` 아이콘 클릭 → `Enable Dev mode Options` 체크 → 메뉴의 `Save (API Format)` 버튼 사용 [8-11, 14].
|
||||
- **메타데이터 추출 패턴:** PNG/WebP 이미지의 `tEXt` 또는 `zTXt` 청크에 포함된 JSON 데이터를 `exiftool`이나 전용 추출 도구를 통해 복구하여 재사용하는 방식 [15-18].
|
||||
- **동적 템플릿 패턴:** 기본 JSON 파일을 로드한 후 Python 딕셔너리 조작을 통해 특정 노드 ID의 `seed`, `prompt`, `image` 등의 값을 실시간으로 변경하여 큐에 삽입하는 전략 [13, 19, 20].
|
||||
- **고유 식별자(ID) 타겟팅:** 각 노드에 부여된 숫자형 문자열 키(예: "37")를 사용하여 특정 노드의 입력 필드에 접근하는 패턴 [5, 20].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로우 JSON은 생성 AI 프로세스를 **유향 비순환 그래프(DAG)**로 정의하며, 이를 직렬화함으로써 이식성과 자동화를 실현한다 [1].
|
||||
|
||||
### 1. 워크플로우 JSON의 주요 유형 및 구조
|
||||
- **Frontend JSON (workflow.json):** Litegraph 표준을 따르며 노드 좌표, 그룹화, 색상 등 캔버스 레이아웃 정보를 포함한다 [2, 5, 21].
|
||||
- **API JSON (workflow_api.json):** 백엔드 엔진이 프롬프트를 실행하는 데 필요한 논리적 연결만 남긴 효율적인 그래프이다 [2, 4, 6]. 링크는 별도 객체가 아닌 노드 입력 내에 직접 임베딩된다 [2, 22].
|
||||
- **구조적 제약:** JSON v1.0 스키마에 따라 각 노드는 고유 `id`, `type`, `inputs`, `outputs`를 가져야 하며, 실행 엔진은 출력 노드에서 역방향으로 그래프를 탐색하여 필요한 의존성만 실행하는 '실행 모델 반전' 방식을 사용한다 [23-25].
|
||||
|
||||
### 2. JSON 생성 및 획득 방법
|
||||
- **수동 내보내기:** 웹 인터페이스에서 개발자 모드를 활성화한 후 전용 저장 버튼을 사용한다 [8, 9, 11].
|
||||
- **알고리즘 추출:** ComfyUI가 생성한 PNG 파일에는 워크플로우가 메타데이터로 자동 저장되므로, 이를 드래그 앤 드롭하거나 `exiftool` 명령어를 사용하여 추출할 수 있다 [15, 17, 26-28].
|
||||
- **자연어 기반 생성:** LLM(예: Qwen2.5-14B)을 사용하여 자연어 설명을 논리적 그래프 구조로 합성하고 로컬 노드 카탈로그와 대조하여 유효한 JSON으로 변환하는 방식이 도입되었다 [29-32].
|
||||
|
||||
### 3. 프로그래밍 방식의 통합 및 변환
|
||||
- **Python 직접 조작:** Python의 `json` 라이브러리를 사용하여 노드 ID를 기반으로 텍스트나 이미지 데이터를 업데이트한다 [19, 20]. 이미지는 주로 Base64로 인코딩되어 JSON 내에 직접 포함된다 [13, 33].
|
||||
- **추상화 래퍼:** `comfy_api_simplified`와 같은 라이브러리는 숫자 ID 대신 노드 제목으로 매개변수를 설정하게 하여 유지보수성을 높인다 [34, 35].
|
||||
- **스크립트 변환:** `ComfyUI-to-Python-Extension`은 JSON 워크플로우를 실행 가능한 독립형 `.py` 스크립트로 변환하여 헤드리스 환경에서 실행할 수 있게 한다 [34, 36, 37].
|
||||
|
||||
### 4. API 기반 자동화 및 배포
|
||||
- **서버리스 플랫폼:** Replicate나 Mystic 같은 서비스는 API JSON 블롭을 입력받아 클라우드 GPU에서 실행하고 결과를 반환하는 엔드포인트를 제공한다 [9, 38-40].
|
||||
- **의존성 관리:** JSON 로드 시 누락된 커스텀 노드는 '빨간 박스'로 표시되며, `ComfyUI-Manager`를 통해 자동으로 식별 및 설치할 수 있다 [41-43].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **포맷 호환성 문제:** 표준 저장 방식으로 생성된 JSON은 API 엔드포인트에서 오류를 발생시키므로 반드시 API 포맷으로의 변환이 필요하다 [12].
|
||||
- **메타데이터 손실:** 소셜 미디어나 이미지 편집기(GIMP 등)를 통해 이미지를 전송 또는 수정할 경우 워크플로우 메타데이터가 삭제될 수 있다는 경고가 반복적으로 확인된다 [16, 26, 44, 45].
|
||||
- **노드 ID 변동성:** 워크플로우를 UI에서 수정하면 노드 ID가 변경될 수 있어, 하드코딩된 Python 스크립트가 파손될 위험이 존재한다 [19, 34]. 이에 대한 해결책으로 노드 제목 기반 매핑이 권장된다 [34, 35].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **서버 측 변환 엔드포인트:** `comfyui-workflow-to-api-converter-endpoint`는 클라이언트 측의 자바스크립트 로직을 파이썬으로 변환하여 서버에서 일반 JSON을 API JSON으로 실시간 변환하는 `/workflow/convert` 엔드포인트를 구현했다 [12, 46, 47].
|
||||
- **독립 실행형 스크립트 변환:** `pydn/ComfyUI-to-Python-Extension` 프로젝트는 `Save As Script` 기능을 통해 워크플로우를 `.py` 파일로 다운로드하여 자동화된 실행 환경을 구축했다 [37, 48].
|
||||
- **매개변수 스케줄링:** `comfy_api_simplified` 라이브러리는 수백 개의 이미지를 야간에 생성하기 위해 여러 프롬프트와 매개변수를 반복 실행하는 예제 코드를 제공한다 [35, 49].
|
||||
- **배너 광고 자동 생성:** ComfyUI API를 Python과 연동하여 입력 이미지와 텍스트를 변경하며 대량의 광고 소재를 생성하는 실제 사례가 보고되었다 [50].
|
||||
- **Mystic 파이프라인 배포:** `pipeline.yaml`과 `new_pipeline.py`를 사용하여 텍스트-비디오 워크플로우를 서버리스 엔드포인트로 배포하는 구조가 상세히 기술되었다 [51-53].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
id: comfyui-custom-scripts
|
||||
title: "ComfyUI Custom Scripts"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI root directory"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[ComfyUI Custom Scripts]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI의 기본 저장 및 로드 기능을 확장하여 워크플로 관리의 효율성을 극대화하고, 노드 그래프를 시각적 파일로 변환하여 공유 편의성을 높이는 통합 UI 강화 도구 세트 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **워크플로 관리 최적화:** 저장(Save) 및 불러오기(Load) 버튼 아래에 드롭다운 메뉴를 생성하여 특정 루트 디렉토리의 워크플로에 즉시 액세스할 수 있도록 지원함 [1, 3].
|
||||
- **시각적 내보내기 (Visual Export):** 워크플로를 표준 JSON 형식 외에도 PNG 또는 SVG 파일로 내보낼 수 있어 소셜 미디어나 문서화에 용이한 시각적 자료를 생성함 [2, 3].
|
||||
- **UI 기능성 강화:** 노드 자동 정렬, 그리드 스냅(Snap to grid), 노드 잠금 등 캔버스 작업의 정밀도와 속도를 높이는 편의 기능을 제공함 [2].
|
||||
- **입력 지능화:** 프롬프트 작성 시 임베딩(Embedding) 리스트를 활용한 자동 완성 기능을 제공하고, 위젯 값 입력 시 수학적 표현식을 사용할 수 있게 함 [2].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **네이티브 UI 확장 패턴:** 기존 ComfyUI 제어 패널의 버튼 구조를 변경하지 않고 하단에 드롭다운 레이어를 추가하여 사용자 경험의 연속성을 유지하면서 기능을 확장함 [1].
|
||||
- **워크플로 시각화 전략:** 복잡한 노드 연결망을 이미지 파일(PNG/SVG)로 직렬화하여 JSON 파일 없이도 워크플로의 전체 구조를 한눈에 파악할 수 있도록 함 [3].
|
||||
- **정보 밀도 향상 패턴:** 체크포인트, LoRA, 임베딩에 대한 추가 정보를 화면에 표시하여 사용자가 모델의 세부 사항을 즉각적으로 인지하도록 설계됨 [2].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI Custom Scripts는 일반적인 워크플로 제작 방식을 넘어 파워 유저를 위한 정교한 제어 기능을 제공하는 커스텀 노드 패키지이다 [1].
|
||||
|
||||
**1. 워크플로 저장 및 관리의 고도화**
|
||||
이 스크립트는 ComfyUI 패널의 저장 및 로드 버튼 아래에 원활한 드롭다운 메뉴를 생성한다 [1]. 이 메뉴는 ComfyUI 내의 특정 루트 디렉토리를 참조하며, 사용자가 복잡한 파일 탐색기 과정 없이 사전에 정의된 경로에서 워크플로를 빠르게 교체하거나 저장할 수 있게 한다 [1, 3]. 이는 업데이트로 인해 워크플로가 덮어씌워지는 것을 방지하는 안전한 백업 환경을 구축하는 데 기여한다 [3].
|
||||
|
||||
**2. 시각적 워크플로 공유 기술**
|
||||
기존의 JSON 기반 공유 방식은 텍스트 데이터에 의존하지만, Custom Scripts는 워크플로 자체를 PNG 또는 SVG 형식으로 내보내는 기능을 제공한다 [2, 3]. 이는 소셜 미디어나 Discord와 같은 플랫폼에서 워크플로의 시각적 형태를 즉시 공유할 수 있게 하며, 동시에 시각적 문서화 도구로 활용된다 [3]. 특히 PNG 파일로 저장할 경우 워크플로 데이터를 포함할 수 있는 옵션이 포함된다 [2].
|
||||
|
||||
**3. 캔버스 작업 편의성 및 데이터 처리**
|
||||
- **노드 배치:** 노드 자동 정렬 기능과 그리드 스냅 기능을 통해 엉킨 노드 그래프를 정돈하고 구조화된 레이아웃을 유지할 수 있다 [2].
|
||||
- **데이터 활용:** 프롬프트 입력창에서 자동 완성을 지원하여 임베딩 선택 시 오류를 줄이고, 레이턴트(Latent) 생성 등 위젯 값 입력 시 수학적 수식을 직접 사용하여 동적인 값 계산이 가능하다 [2].
|
||||
- **상태 제어:** 노드 잠금(Lock) 기능을 통해 실수로 배치를 변경하는 것을 방지하며, 이미지 피드를 UI 상에서 직접 확인할 수 있는 향상된 뷰어를 제공한다 [2].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **정보의 상호 보완:** 소스 데이터는 이를 "UI 향상 도구"이자 "인기 있는 커스텀 노드"로 정의하고 있다 [2, 4].
|
||||
- **JSON과의 관계:** 표준 저장 방식인 JSON 파일과 대조적으로, 이 스크립트는 PNG/SVG와 같은 시각적 내보내기를 강조하지만 이것이 JSON 형식을 완전히 대체하는 것이 아니라 보완적인 공유 수단으로 작동함을 시사한다 [3].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI 루트 디렉토리 관리:** 워크플로를 저장하고 로드할 때 참조되는 기본 경로 설정 로직에 적용되어 있다 [1, 3].
|
||||
- **클라우드 플랫폼 지원:** Replicate와 같은 환경에서 인기 있는 커스텀 노드 리스트로 분류되어 기본적으로 지원되거나 권장되는 도구로 포함되어 있다 [4, 5].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
id: dev-mode-options
|
||||
title: "Dev mode Options"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["개발자 모드", "Developer Mode"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["Replicate fofr/any-comfyui-workflow", "Mystic pipeline-ai", "ComfyUI Workflow Converter Endpoint", "ComfyUI-to-Python-Extension"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Dev mode Options]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Dev mode Options는 시각적 편집 중심의 워크플로우를 프로그래밍 방식의 실행이 가능한 최적화된 API 포맷으로 변환 및 추출하기 위해 반드시 거쳐야 하는 ComfyUI의 핵심 설정 관문이다. [1-3]
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **API 포맷 직렬화 (Serialization)**: 프론트엔드의 시각적 메타데이터(노드 위치, 크기 등)를 제거하고 백엔드 엔진이 즉시 실행할 수 있는 평탄화된 실행 그래프(Flattened Execution Graph)를 생성한다. [1, 4]
|
||||
- **기능 잠금 해제 (UI Unlocking)**: 설정 활성화 시 ComfyUI 메뉴에 기존에 보이지 않던 'Save (API Format)' 버튼을 추가하여 사용자가 직접 API용 JSON을 내보낼 수 있게 한다. [5-7]
|
||||
- **데이터 흐름 최적화**: 링크를 별도의 객체가 아닌 노드 입력 내의 직접적인 참조(Origin node ID 및 Slot index)로 포함시켜 데이터 처리 효율을 극대화한다. [1, 8]
|
||||
- **프로그래밍 통합의 필수 조건**: 외부 애플리케이션, 원격 서버, 또는 헤드리스(Headless) 환경에서 워크플로우를 실행하기 위한 전제 조건이다. [2, 9]
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **활성화 메커니즘**: `톱니바퀴 아이콘(Settings)` -> `Enable Dev mode Options 체크박스 활성화` -> `메뉴/패널에 새로운 내보내기 옵션 노출` 순의 정형화된 패턴을 따른다. [2, 3, 7]
|
||||
- **포맷의 이원화 패턴**: 인간의 가독성과 시각적 편집을 위한 `Frontend JSON(workflow.json)`과 기계적 실행만을 목적으로 하는 `Backend/API JSON(workflow_api.json)`으로 워크플로우 포맷을 분리하여 관리한다. [1, 10]
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **기능적 역할**: 기본 ComfyUI 저장 방식은 Litegraph 표준을 따르며 캔버스 레이아웃 정보를 포함하지만, 이는 `/prompt` 엔드포인트에 직접 전달할 경우 오류를 발생시킨다. [11] Dev mode는 백엔드가 요구하는 특정 노드 클래스와 매개변수 리스트로 구성된 간결한 JSON 페이로드를 생성할 수 있게 한다. [2, 5]
|
||||
- **접근 경로**: ComfyUI 설정 메뉴(Settings) 내에서 'Enable Dev mode Options'를 선택하면 활성화된다. [3, 7, 12] 활성화 후에는 메뉴의 'Export' 섹션 또는 제어 패널 상단에 'Save (API Format)'라는 명칭의 새로운 버튼이 등장한다. [5, 7]
|
||||
- **API JSON의 특징**: 시각적 메타데이터가 제거되어 파일 용량이 작고 효율적이다. [1, 10] 노드 간의 링크 정보가 노드의 `inputs` 필드 내에 직접 배열 형태(예: `[node_id, slot_index]`)로 포함되는 것이 기술적 차별점이다. [8]
|
||||
- **주요 활용 사례**:
|
||||
- **Replicate/Mystic**: 서버리스 클라우드 환경에서 워크플로우를 API 엔드포인트로 배포할 때 필수적으로 요구된다. [3, 6, 7, 13]
|
||||
- **Python 스크립트 실행**: 워크플로우를 독립적인 파이썬 스크립트로 변환하거나 API를 통해 동적으로 매개변수를 수정하여 실행할 때 기반 데이터로 사용된다. [9, 14, 15]
|
||||
- **자동화 도구**: LLM을 이용한 워크플로우 자동 생성이나 대량의 이미지 처리 파이프라인 구축 시 'Dev mode'를 통해 추출된 스키마가 참조 모델이 된다. [16, 17]
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **가역성 문제**: 일반적인 'Save'로 생성된 JSON은 ComfyUI에 드래그 앤 드롭 시 레이아웃이 복구되지만, Dev mode를 통해 추출된 'API Format' JSON은 레이아웃 정보가 없으므로 다시 UI로 불러왔을 때 시각적 구조가 파괴된 '골격(Skeleton)' 상태로 나타난다. [18]
|
||||
- **도구별 요구사항**: 대부분의 튜토리얼은 API 실행을 위해 Dev mode 활성화를 권장하지만, 일부 커스텀 확장 기능(예: ComfyUI-to-Python-Extension)은 일반 저장 파일에서도 스크립트 변환을 지원하는 별도의 기능을 UI에 추가하기도 한다. [19, 20]
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Replicate 배포 프로세스**: `settings` -> `Enable Dev mode Options` -> `Save (API format)` 순서로 JSON을 획득하여 `fofr/any-comfyui-workflow` 모델의 `workflow_json` 입력값으로 사용함. [3, 6]
|
||||
- **Mystic 서버리스 통합**: 워크플로우를 Mystic 파이프라인으로 배포하기 전, GUI의 설정 메뉴에서 Dev mode를 켜고 `.json` 파일을 API 포맷으로 내보내는 과정이 필수 단계로 포함됨. [7]
|
||||
- **SethRobinson의 Workflow Converter**: API 포맷 변환 시 클라이언트 측 자바스크립트 로직을 서버 측 파이썬으로 구현하여, 개발자가 매번 수동으로 Dev mode를 켜고 API 포맷을 저장해야 하는 번거로움을 해결함. [11]
|
||||
- **ComfyUI-to-Python-Extension**: CLI 사용 시 API 포맷 워크플로우를 입력값으로 받아 실행 가능한 파이썬 코드를 생성함. [21]
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 발견으로 검증됨)
|
||||
- **출처 신뢰도:** B (공식 문서 및 주요 개발자 도구의 가이드라인에 근거함)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
id: draft-07-specification
|
||||
title: "Draft-07 Specification"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["JSON Schema v1.0"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI Workflow v1.0", "WorkflowExecutor", "comfyui-workflow-to-api-converter-endpoint"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Draft-07 Specification]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Draft-07 Specification은 ComfyUI Workflow JSON v1.0의 구조적 무결성을 정의하는 공식 표준으로, 노드 속성과 링크 연결성을 규제하여 워크플로의 이식성과 실행 가능성을 보장한다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **JSON Schema v1.0:** Draft-07 사양을 따르는 최신 ComfyUI 워크플로 표준으로, 실행 엔진이 인식하기 위한 기술적 제약 조건을 정의한다 [1, 2].
|
||||
- **Mandatory Node Properties:** 노드 객체가 포함해야 하는 필수 속성(id, type, pos, size, order, mode)을 통해 그래프의 구조를 명시한다 [1].
|
||||
- **Slot Connectivity Indexing:** 링크 및 슬롯의 원본/대상 ID와 인덱스를 지정하여 데이터 흐름의 정확성을 확보한다 [3].
|
||||
- **Serialization Validation:** 워크플로가 직렬화될 때 이 사양을 준수해야만 ComfyUI 백엔드에서 유효한 프롬프트로 처리될 수 있다 [1, 4].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Bifurcation Compliance:** 시각적 메타데이터를 포함하는 Frontend 포맷(`workflow.json`)과 실행 최적화된 Backend 포맷(`workflow_api.json`) 모두가 동일한 Draft-07 기반의 핵심 논리 구조를 공유한다 [5, 6].
|
||||
- **Dependency Inversion Traversal:** 엔진이 출력 노드에서 시작하여 사양에 정의된 링크를 역추적(backward traversal)하여 필요한 노드만 실행하는 구조적 패턴을 보인다 [7].
|
||||
- **Metadata Redundancy:** PNG 파일의 메타데이터 청크(tEXt/zTXt)에 두 가지 포맷을 동시에 저장하여 표준 준수와 사용자 편의성을 동시에 유지한다 [8].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로의 구조적 무결성은 **Draft-07 사양을 따르는 공식 JSON Schema v1.0**에 의해 검증된다 [1, 2]. 이 사양은 워크플로가 단순한 시각적 도표를 넘어 실행 가능한 프로그램으로서 작동하기 위한 기술적 제약 사항을 명시한다.
|
||||
|
||||
**1. 노드 객체의 필수 속성 규격 [1]:**
|
||||
- **id:** 그래프 탐색을 위한 고유 식별자 (Integer 또는 String).
|
||||
- **type:** 노드 레지스트리의 클래스 이름과 매핑되는 필수 문자열.
|
||||
- **pos / size:** UI 렌더링을 위한 캔버스 좌표 및 크기 정보.
|
||||
- **order:** 엔진이 참조하는 권장 실행 또는 렌더링 순서.
|
||||
- **mode:** 노드의 활성화, 바이패스(Bypass) 등의 운영 상태.
|
||||
|
||||
**2. 링크 및 슬롯 연결 사양 [3]:**
|
||||
연결성은 노드 내부의 `inputs` 및 `outputs` 배열을 통해 정의된다. `inputs` 속성의 `link` 프로퍼티는 들어오는 와이어의 고유 ID를 식별하며, `outputs`의 `links` 배열은 하나의 출력이 여러 노드로 전달될 수 있음을 나타낸다. 특히 VAE Loader와 같이 다중 출력 슬롯을 가진 노드의 경우, **정확한 슬롯 인덱싱**이 사양 준수의 핵심이다 [3].
|
||||
|
||||
**3. 유효성 검사 및 실행 [4]:**
|
||||
워크플로 JSON이 생성되면 ComfyUI의 `validate_prompt` 함수는 이 사양을 기준으로 데이터 구조를 검증한다. 검증을 통과한 JSON은 `DynamicPrompt`로 구성되어 `ExecutionList`로 변환되며, 이 과정에서 사양에 어긋나는 연결이나 속성이 발견되면 실행이 거부된다 [4].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **버전 업데이트:** 이전의 0.4 버전 사양에서 최신 1.0(Draft-07 기반)으로 표준이 업데이트되었으며, 이는 공식 문서에서 권장되는 최신 규격이다 [2, 9].
|
||||
- **포맷 간 차이:** API 포맷은 효율성을 위해 UI 관련 메타데이터를 삭제하지만, 핵심적인 노드 클래스 매핑과 입력 구조는 여전히 Draft-07의 논리적 범주 내에 있다 [5, 6].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI Workflow v1.0:** Draft-07 사양을 공식적으로 채택한 최신 워크플로 직렬화 규격 [1, 2].
|
||||
- **WorkflowExecutor.execute():** 독립 실행 스크립트에서 `validate_prompt`를 호출하여 워크플로 JSON이 사양을 준수하는지 검증하는 로직이 적용됨 [4].
|
||||
- **comfyui-workflow-to-api-converter-endpoint:** 비 API 포맷을 API 포맷으로 변환할 때 ComfyUI의 노드 레지스트리와 사양을 참조하여 유효한 JSON을 생성함 [10, 11].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
id: executing-comfyui-workflows-as-standalone-scripts
|
||||
title: "Executing ComfyUI Workflows as Standalone Scripts"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["pydn/ComfyUI-to-Python-Extension", "WorkflowExecutor", "ExecutionCache", "new_pipeline.py", "bc85382"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Executing ComfyUI Workflows as Standalone Scripts]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI 워크플로우를 시각적 인터페이스 없이 실행 가능한 독립형 스크립트로 변환하는 프로세스는 **API 형식의 JSON 직렬화와 Python 환경의 실행 오케스트레이션**을 통해 고도의 자동화와 헤드리스(Headless) 환경 배포를 가능하게 한다 [1-4].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **API JSON Format (Backend JSON):** 시각적 메타데이터를 제거하고 노드 입력과 연결 정보만을 남긴 실행 최적화 그래프 파일로, 독립형 스크립트 실행의 기초가 된다 [2, 5, 6].
|
||||
- **WorkflowExecutor:** 워크플로우 실행 환경을 초기화하고, 노드 유효성 검사(`validate_prompt`) 및 실행 목록(`ExecutionList`) 구축을 담당하는 오케스트레이션 객체이다 [7].
|
||||
- **ExecutionCache:** 노드 출력, UI 데이터 및 객체 인스턴스를 캐싱하여 중복 계산을 줄이고 실행 성능을 최적화하는 통합 관리 클래스이다 [8].
|
||||
- **Headless Processing:** 웹 브라우저나 GUI 없이 서버 백엔드 또는 독립형 스크립트 형태로 워크플로우를 구동하여 실행 오버헤드를 줄이는 방식이다 [4].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Serialization Bifurcation (직렬화 이분화):** 시각적 편집을 위한 Frontend JSON(`workflow.json`)과 자동화 실행을 위한 Backend API JSON(`workflow_api.json`)을 분리하여 관리하는 설계 패턴이 발견된다 [2, 5, 6, 9].
|
||||
- **Execution Model Inversion (실행 모델 역전):** 모든 노드를 실행하는 대신 'Save Image'와 같은 출력 노드에서 역추적하여 필요한 의존성만 식별하고 실행하는 효율적 패턴을 사용한다 [10].
|
||||
- **Python-to-Script Conversion:** `.json` 워크플로우를 `.py` 코드로 직접 변환하여 별도의 JSON 처리 없이 Python 런타임에서 즉시 실행 가능하게 하는 추상화 패턴이 존재한다 [3, 11].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로우를 독립형 스크립트로 실행하기 위해서는 먼저 **'Dev mode'**를 활성화하여 **API 형식의 JSON**을 추출해야 한다 [6, 12, 13]. 표준 Frontend JSON은 노드 위치나 그룹화 등 시각적 정보를 포함하지만, API JSON은 이를 제거하고 노드 간의 링크를 입력 필드 내의 직접 참조(`[origin_id, output_slot]`)로 포함하여 백엔드 엔진이 즉시 해석할 수 있도록 최적화되어 있다 [2, 14, 15].
|
||||
|
||||
독립형 실행의 핵심 구성 요소인 **WorkflowExecutor**는 `DynamicPrompt`를 구성하고 이를 노드 단위의 실행 목록인 `ExecutionList`로 변환한다 [7]. 각 노드는 `_execute_node` 메서드를 통해 순차적으로 실행되며, 이때 `get_input_data`와 `get_output_data` 함수가 사용되어 데이터 흐름을 처리한다 [8, 16]. **ExecutionCache**는 `HierarchicalCache`를 기반으로 구축되어 이전 실행 결과를 보존함으로써 연속적인 실행 시 성능을 비약적으로 향상시킨다 [8].
|
||||
|
||||
더 고도화된 방식으로는 **ComfyUI-to-Python-Extension**을 사용하여 워크플로우 자체를 실행 가능한 `.py` 파일로 변환하는 것이 가능하다 [3, 11]. 이 방식은 생성된 스크립트 내에 노드 실행 로직이 포함되어 있어 별도의 프롬프트 서버 호출 없이도 단독 실행(Single-shot runner)이 가능하며, 메모리 관리 플래그(`--highvram` 등)를 스크립트 인자로 전달받아 제어할 수 있다 [17, 18].
|
||||
|
||||
생산 환경에서는 **Mystic**이나 **Replicate**와 같은 플랫폼을 통해 이러한 스크립트를 서버리스 엔드포인트로 배포할 수 있으며, 이때 Python SDK를 사용하여 워크플로우 JSON 내의 시드(seed)나 프롬프트 값을 프로그래밍 방식으로 수정하여 실행한다 [19-21].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **워크플로우 유연성 대 변환 복잡성:** 일부 연구에서는 `ComfyUI-to-Python-Extension`이 중간 변환 단계를 요구하여 **동적(Dynamic) 워크플로우** 실행에 어려움이 있을 수 있다고 지적하며, 대신 API JSON을 직접 로드하는 방식을 권장하기도 한다 [4].
|
||||
- **JSON 버전 호환성:** ComfyUI는 빈번하게 업데이트되므로 구버전의 JSON 파일이 최신 버전의 실행 엔진에서 정상 작동하지 않을 수 있다는 경고가 명시되어 있다 [22, 23].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **pydn/ComfyUI-to-Python-Extension:** 워크플로우를 독립형 `.py` 스크립트로 자동 번환하는 도구로 구현되었다 [3, 24].
|
||||
- **WorkflowExecutor & ExecutionCache:** SDXL Turbo 워크플로우를 독립형 스크립트로 실행하기 위한 핵심 아키텍처로 제안되었으며 GitHub Gist를 통해 소스 코드가 공유되었다 [7, 8, 25].
|
||||
- **Mystic (new_pipeline.py):** ComfyUI 서버를 시작하고 커스텀 워크플로우를 로드하여 입력 프롬프트를 주입하는 배포용 Python 템플릿 파일이다 [20, 26].
|
||||
- **GitHub Commit (bc85382):** `comfyui-workflow-to-api-converter-endpoint` 프로젝트에서 콤보 위젯의 대소문자 검증 문제를 수정한 커밋 기록이 발견된다 [27].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
id: frontend-format
|
||||
title: "Frontend Format"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["workflow.json", "UI Format"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow.json", "flux_workflow.json"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Frontend Format]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
Frontend Format은 ComfyUI 웹 인터페이스의 시각적 상태와 노드 실행 로직을 완벽하게 보존하기 위해 노드 좌표, 크기, 그룹화 등의 풍부한 UI 메타데이터를 포함하는 Litegraph 기반 직렬화 규격이다 [1], [2], [3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **시각적 메타데이터 (Visual Metadata):** 노드의 캔버스 좌표(`pos`), 크기(`size`), 그룹 구조, 노드의 접힘(collapsed) 또는 고정(pinned) 상태 등 사용자 인터페이스 구성을 위한 정보를 포함한다 [1], [2], [4].
|
||||
- **Litegraph 표준 기반:** 웹 기반 그래프 편집기의 시각적 조작과 렌더링을 위해 설계된 Litegraph 형식을 따르며, 이는 인간이 읽고 이해하기 쉬운 구조를 제공한다 [1], [3].
|
||||
- **명시적 연결 객체 (Explicit Links):** 노드 간의 데이터 흐름이 별도의 `links` 배열 내에 정의된 독립적인 연결 객체로 표현되어, 그래프의 시각적 연결성을 관리한다 [2], [5].
|
||||
- **고유 숫자 식별자:** 각 노드는 "1", "2", "3"과 같은 고유한 숫자 기반 문자열 ID를 통해 관리되며, 이는 시각적 위치와 논리적 연결을 매핑하는 기준이 된다 [2], [3].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **GUI 기본 저장 패턴:** ComfyUI 제어판에서 'Save' 버튼을 누르거나 단축키 `Ctrl + S`(Mac은 `Cmd + S`)를 사용할 때 기본적으로 생성되는 포맷이다 [6], [7].
|
||||
- **미디어 메타데이터 내장 패턴:** PNG 또는 WebP 이미지 생성 시, 파일의 `tEXt` 또는 `zTXt` 청크에 Frontend Format JSON이 주입되어 이미지가 자체적인 워크플로우 컨테이너 역할을 하게 된다 [8], [9], [10].
|
||||
- **노드 오브젝트 표준화:** 모든 노드는 `id`, `type`, `pos`, `size`, `widgets_values`, `order`, `mode`라는 필수/선택 속성 세트를 가지는 일관된 객체 구조를 유지한다 [11], [4].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
Frontend Format은 주로 **시각적 편집 및 인간 간의 공유**를 목적으로 사용된다 [2], [7]. 이 포맷은 단순한 실행 로직을 넘어 아티스트가 구성한 작업 환경의 모든 세부 사항을 저장하기 때문에, 파일을 다시 불러왔을 때 노드들이 정확히 같은 위치에 배치되고 설정된 시각적 그룹이 유지된다 [6], [3].
|
||||
|
||||
기술적으로 Frontend JSON은 `nodes`와 `links`라는 두 가지 핵심 배열을 포함한다 [4]. `nodes` 배열의 각 객체는 특정 노드의 클래스 타입과 위젯 값뿐만 아니라 캔버스상의 좌표(`[x, y]`)와 차원(`[width, height]`)을 명시한다 [11], [4]. `links` 배열은 출력 노드 ID, 출력 슬롯, 입력 노드 ID, 입력 슬롯을 포함하는 6개 항목의 배열 또는 객체로 구성되어 노드 간의 물리적 연결을 정의한다 [5].
|
||||
|
||||
이 포맷은 파일 크기가 API Format에 비해 상대적으로 크지만, 모델 가중치(Weights) 파일에 비하면 매우 작아 독립적인 보관과 공유가 용이하다 [12], [2]. 하지만 백엔드 엔진이 직접적으로 해석하기에는 불필요한 UI 정보가 너무 많아, 서버 사이드 실행이나 API 호출 시에는 대개 API Format으로의 변환이 필요하다 [13], [14].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **실행 호환성:** Frontend Format(workflow.json)은 ComfyUI 웹 인터페이스에서는 드래그 앤 드롭으로 즉시 실행되지만, 외부 애플리케이션에서 `/prompt` 엔드포인트를 통해 서버에 직접 전송할 경우 에러가 발생하며 실행되지 않는다 [14].
|
||||
- **데이터 손실 위험:** 이미지에 내장된 워크플로우 메타데이터는 일반적인 이미지 편집기(GIMP 등)로 편집하거나 소셜 미디어 플랫폼에 업로드할 때 압축 및 최적화 과정에서 삭제될 위험이 크다 [15], [9], [16].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **표준 워크플로우 파일:** `workflow.json`이라는 기본 파일명으로 시스템 전반에서 시각적 저장 단위로 사용된다 [1], [7].
|
||||
- **FLUX 예시:** `flux_workflow.json` 파일은 노드 ID, 위치, 위젯 값 및 명시적 링크 구조를 보여주는 Frontend Format의 대표적인 기술 사례로 문서화되어 있다 [7], [17].
|
||||
- **버그 수정 기록:** Git 커밋 `bc85382`에서는 Frontend 포맷에서 API 포맷으로 변환할 때 콤보 위젯의 대소문자 불일치 문제를 해결하기 위해 노드 레지스트리를 대조하는 로직이 적용되었다 [18], [19].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 및 공식 사양을 통해 확인됨)
|
||||
- **출처 신뢰도:** B (공식 문서 및 오픈소스 기술 문서 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
id: frontend-json-(workflow.json)
|
||||
title: "Frontend JSON (workflow.json)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["workflow.json", "UI Format JSON"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["Mystic pipeline root directory", "RunComfy FLUX workflow example (flux_workflow.json)", "ComfyUI Official RFCs repository", "ComfyUI Output folder (metadata embedding)"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Frontend JSON (workflow.json)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI의 시각적 작업 공간 전체(노드 좌표, 그룹, 링크 구조)를 Litegraph 표준에 따라 보존하여 사용자의 편집, 재구성 및 커뮤니티 협업을 가능하게 하는 종합적인 시각적 설계도이다. [1-3]
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Litegraph 표준 기반 시각적 메타데이터**: 노드의 캔버스 좌표(`pos`), 크기(`size`), 색상, 그룹화 구조 및 노드 확장/축소 상태와 같은 UI 전용 정보를 포함한다. [1, 2, 4, 5]
|
||||
- **명시적 링크 배열 (Explicit Link Representation)**: 노드 간의 연결을 별도의 `links` 배열 내 개별 객체로 관리하며, 각 링크는 고유 ID를 통해 원본 노드와 대상 노드의 슬롯을 정의한다. [1, 2, 6, 7]
|
||||
- **인간 중심의 교환 포맷**: 시각적 편집과 공유를 목적으로 설계되었으며, 모델 가중치와 독립적으로 워크플로우 로직을 작고 가독성 있는 텍스트 파일로 아카이브할 수 있게 한다. [6, 8, 9]
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **결과물 내 로직 자가 수용 패턴 (Metadata Embedding)**: 생성된 이미지(PNG/WebP)의 `tEXt` 또는 `zTXt` 청크에 Frontend JSON을 주입하여, 이미지 자체가 해당 이미지를 만든 로직을 운반하는 컨테이너 역할을 수행하게 한다. [3, 10, 11]
|
||||
- **비가역적 정보 손실 패턴 (Frontend to API Transformation)**: Frontend JSON은 실행 최적화된 API JSON으로 변환 가능하지만, 역변환 시 시각적 레이아웃 정보는 복구할 수 없는 비가역적 관계를 가진다. [12, 13]
|
||||
- **의존성 탐지 및 해결 휴리스틱**: 외부 JSON 로드 시 `class_type`을 로컬 레지스트리와 대조하여 누락된 커스텀 노드를 식별하고(Red Nodes), ComfyUI-Manager를 통해 이를 일괄 설치하는 복구 패턴이 존재한다. [14-16]
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
Frontend JSON(주로 `workflow.json`으로 명명됨)은 ComfyUI 웹 인터페이스의 상태를 저장하는 표준 포맷이다. [1, 17] 이 파일은 사용자가 구성한 그래프의 시각적 배치와 모든 매개변수를 캡처하는 포괄적인 청사진 역할을 한다. [8]
|
||||
|
||||
### 1. 기술적 구조 및 속성
|
||||
- **노드 배열 (`nodes`)**: 워크플로우를 구성하는 개별 객체들의 리스트이다. [5]
|
||||
- `id`: 그래프 탐색을 위한 고유 식별자(숫자 문자열)이다. [4, 18]
|
||||
- `type`: 노드 레지스트리의 클래스 이름과 매핑된다. [4, 5]
|
||||
- `pos` & `size`: 캔버스 렌더링을 위한 [x, y] 좌표 및 치수이다. [4, 5]
|
||||
- `widgets_values`: 슬라이더, 텍스트 박스 등 사용자 입력 값을 저장하는 배열이다. [4, 5]
|
||||
- **링크 시스템 (`links`)**: 별도의 최상위 배열에서 관리되며, `origin_id`, `origin_slot`, `target_id`, `target_slot`을 정의하여 데이터 흐름을 명시한다. [7]
|
||||
|
||||
### 2. 생성 및 로드 방법
|
||||
- **수동 내보내기**: 제어판 메뉴의 'Export' 옵션이나 `Ctrl + S` (macOS는 `Cmd + S`) 단축키를 통해 현재 그래프 상태를 JSON으로 다운로드할 수 있다. [5, 19, 20]
|
||||
- **이미지 기반 추출**: ComfyUI에서 생성된 PNG 파일을 캔버스에 드래그 앤 드롭하면 내장된 메타데이터를 분석하여 워크플로우가 즉시 재구성된다. [19, 21-23] `exiftool`과 같은 CLI 도구를 사용하여 바이너리 태그에서 직접 추출할 수도 있다. [24, 25]
|
||||
- **자동 생성**: 최근에는 자연어 설명을 LLM(Qwen2.5 등)이 해석하여 논리적 그래프 구조를 합성하고, 이를 실행 가능한 JSON으로 컴파일하는 기술이 도입되고 있다. [26-28]
|
||||
|
||||
### 3. API JSON(workflow_api.json)과의 차이
|
||||
- **목적**: Frontend JSON은 시각적 편집용이며, API JSON은 서버 측 실행 및 프로그래밍 방식의 호출에 최적화되어 있다. [1, 6, 9, 29]
|
||||
- **메타데이터**: API 포맷은 노드 위치, 크기, 그룹 등 UI 관련 데이터를 제거하여 파일 크기를 압축한다. [1, 30]
|
||||
- **연결 방식**: API 포맷은 링크를 별도 객체가 아닌 노드 입력 내의 직접적인 참조(Origin 노드 ID 및 슬롯)로 임베딩한다. [1, 6, 29]
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **메타데이터 휘발성**: 생성된 이미지 내의 JSON 데이터는 일반적인 이미지 편집기, 소셜 미디어 플랫폼, 또는 파일 압축 유틸리티를 거칠 때 삭제될 위험이 크다. [3, 11, 21]
|
||||
- **버전 호환성 문제**: ComfyUI의 빈번한 업데이트로 인해 구버전의 JSON 파일이 최신 버전에서 정상적으로 작동하지 않을 수 있으며, 특히 커스텀 노드 클래스 이름의 변경이 주요 원인이 된다. [19, 31]
|
||||
- **실행 제한**: Frontend JSON을 API 엔드포인트(`/prompt`)에 직접 전달하면 실행 그래프가 아니라는 이유로 오류가 발생하므로, 반드시 'Dev mode'를 활성화하여 API 포맷으로 변환하거나 서버 측 변환기를 거쳐야 한다. [12, 32]
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Mystic 파이프라인**: 서버리스 엔드포인트 배포 시 메인 디렉토리에 `workflow.json`을 포함하여 관리한다. [33]
|
||||
- **RunComfy 플랫폼**: FLUX 워크플로우 예시로 `flux_workflow.json` 파일이 제공되며, 이는 전체 UI 상태를 포함하는 표준 Frontend 포맷이다. [9, 30]
|
||||
- **추출 도구 활용**: `exiftool -b -workflow input.png > workflow.json` 명령어를 통해 이미지 메타데이터에서 Frontend JSON을 물리적으로 분리하는 방식이 실무에서 사용된다. [24, 25]
|
||||
- **ComfyUI-to-Python-Extension**: Frontend JSON의 시각적 메타데이터를 포함한 상태로 Python 스크립트로 변환하여 드래그 앤 드롭 재가져오기 기능을 유지한다. [34]
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
id: large-language-models-(llm)
|
||||
title: "Large Language Models (LLM)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI-WorkflowGenerator", "ComfyGPT Research"]
|
||||
github_commit: "82df278"
|
||||
---
|
||||
|
||||
# [[Large Language Models (LLM)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
LLM은 자연어 의도를 실행 가능한 ComfyUI 노드 그래프로 변환함으로써 '시각적 프로그래밍'을 '대화형 프로그래밍'으로 진화시키는 핵심 가교 역할을 수행한다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **자연어 기반 워크플로우 합성 (Natural Language Synthesis):** 사용자의 텍스트 설명을 해석하여 복잡한 노드 연결 구조를 자동으로 설계하는 기술 [3, 4].
|
||||
2. **멀티 스테이지 파이프라인 (Multi-stage Pipeline):** 생성(Generator), 검증(Validator), 빌드(Builder)의 세 단계를 거쳐 논리적 설계를 물리적 실행 파일로 변환하는 구조 [5].
|
||||
3. **미세 조정된 도메인 특화 모델 (Fine-tuned Specialized Models):** ComfyUI의 노드 레지스트리와 스키마 규격에 최적화된 특정 파라미터 규모의 모델(예: Qwen2.5-14B) [3, 6].
|
||||
4. **시맨틱 노드 검증 (Semantic Node Validation):** LLM이 생성한 노드 명칭을 실제 설치된 노드 라이브러리와 대조하여 수정하는 시맨틱 검색 및 임베딩 기술 [5, 7].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **논리-물리 분리 설계 패턴:** LLM이 먼저 추상적인 그래프 논리(Logical Graph)를 생성한 후, 이를 로컬 환경의 실제 노드 클래스와 매핑하여 검증하는 이단계 접근 방식을 취함 [1, 5].
|
||||
- **바이트코드로서의 JSON:** JSON 파일을 단순한 저장 포맷이 아닌, 인간의 의도와 AI 실행 엔진 사이의 중간 언어(Bytecode)로 취급함 [1].
|
||||
- **RAG 기반 지식 확장 패턴 (지향점):** 정적 모델의 한계를 극복하기 위해 실시간 노드 데이터베이스를 쿼리하여 새로운 노드 지식을 습득하는 구조로의 발전 경향 [8].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
LLM을 활용한 ComfyUI 워크플로우 생성은 기술적 지식이 부족한 사용자도 복잡한 생성 AI 파이프라인을 구축할 수 있게 돕는다. 소스에 따르면, **ComfyUI-WorkflowGenerator**는 Qwen2.5-14B 모델을 미세 조정하여 자연어 지시(예: "Depth ControlNet을 추가해줘")를 실행 가능한 JSON 구조로 변환한다 [3, 4, 6].
|
||||
|
||||
생성 프로세스는 세 가지 핵심 구성 요소로 운영된다. **Generator**는 LLM을 사용해 사용자의 프롬프트를 해석하고 논리적 그래프 구조를 생성하며, **NodeValidator**는 이 구조가 로컬 ComfyUI 환경의 실제 노드들과 호환되는지 확인하고 수정한다 [5, 7]. 마지막으로 **WorkflowBuilder**는 이를 최종적인 실행 가능 JSON 형식으로 컴파일한다 [5, 9].
|
||||
|
||||
성능 최적화를 위해 GGUF 형식으로 양자화된 모델이 사용되며, 시맨틱 검색에는 `sentence-transformers` 모델이 활용된다 [6, 10]. 현재 시스템은 학습 데이터 컷오프 이후에 출시된 커스텀 노드를 인식하지 못하는 '정적 모델'의 한계를 가지고 있으나, 향후 I/O 스키마(데이터 타입) 인식 및 소형 그래프 추론 모델(SLM)을 통한 개선이 논의되고 있다 [8, 11].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **정적 학습 vs 실시간 생태계:** LLM은 학습된 시점의 노드 정보에 고정(Frozen)되어 있는 반면, ComfyUI 생태계는 매일 새로운 노드가 추가되는 불일치가 발생함 [11]. 이를 해결하기 위해 단순 생성이 아닌 RAG(검색 증강 생성) 기반의 탐색 기술로의 전환이 필요함이 강조됨 [8].
|
||||
- **언어적 타당성 vs 실행적 유효성:** 현재 시스템은 언어적으로 그럴싸한 연결을 생성할 수 있으나, 실제 노드 간의 데이터 타입(LATENT, IMAGE 등)이 물리적으로 일치하는지 완벽히 보장하지 못하는 경우가 있어 향후 'I/O 스키마 인식' 에이전트의 도입이 요구됨 [8].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI-WorkflowGenerator:** Qwen2.5-14B를 기반으로 자연어 설명을 노드 그래프로 변환하는 실제 커스텀 노드 프로젝트 [4, 12].
|
||||
- **ComfyGPT Research:** "ComfyGPT: A Self-Optimizing Multi-Agent System for Comprehensive ComfyUI Workflow Generation" 논문에 기반한 자가 최적화 시스템 설계 [5].
|
||||
- **Update Node Catalog:** 로컬에 설치된 모든 노드(네이티브 및 커스텀)를 스캔하여 LLM이 참조할 수 있는 카탈로그 파일로 생성하는 구현체 [9].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
id: load-image-(base64)
|
||||
title: "Load Image (Base64)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["Base64 Image Loading", "Image-to-Base64 API Input"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy_api_python.py"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Load Image (Base64)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
API 기반 자동화 환경에서 별도의 파일 서버 저장 절차 없이 워크플로우 JSON 내에 이미지 데이터를 텍스트 형태로 직접 포함하여 전송하는 핵심 데이터 주입 기술 [1], [2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **데이터 임베딩 (Data Embedding):** 이미지 바이너리 데이터를 Base64 문자열로 변환하여 워크플로우 JSON의 입력 필드에 직접 삽입함 [2].
|
||||
2. **무저장소 아키텍처 (Stateless Storage):** 서버 측의 임시 파일 저장소에 이미지를 저장할 필요 없이 메모리 상에서 직접 워크플로우를 실행하게 함 [1].
|
||||
3. **자체 완결적 요청 (Self-contained Request):** 생성 로직(Workflow)과 원천 데이터(Image)를 하나의 JSON 페이로드에 통합하여 데이터 관리 복잡성을 해소함 [1].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **동적 파라미터 치환 패턴:** 로컬에서 이미지를 Base64로 인코딩한 후, 워크플로우 JSON에서 해당 노드의 ID를 식별하여 `inputs`의 `base64_data` 필드 값을 동적으로 교체하여 서버에 요청함 [3], [2].
|
||||
- **API 호출 표준화:** 생산용 자동화 시스템(예: 배너 광고 생성)에서 입력 이미지가 매번 바뀔 때마다 파일 경로 관리 대신 데이터 자체를 전송하는 방식을 취함 [1].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **기능 및 정의:** 'Load Image (Base64)' 노드는 주로 API 호출을 통한 프로덕션 자동화 시스템에서 활용된다 [1]. 이 노드는 이미지를 문자열로 인코딩하여 JSON 워크플로우 내에 직접 포함할 수 있게 설계되었으며, 이는 ComfyUI를 외부 애플리케이션이나 원격 서버에 통합할 때 필수적인 요소다 [1].
|
||||
- **동작 메커니즘:** 파이썬(Python)과 같은 외부 언어를 사용하여 이미지를 `base64.b64encode` 방식으로 변환한다 [2]. 이후 API 형태의 워크플로우 JSON 파일에서 해당 노드의 고유 ID(예: #37)를 찾아 `inputs` 딕셔너리 내의 `base64_data` 필드에 해당 문자열을 주입한다 [2].
|
||||
- **운영상의 이점:** 서버 측에 이미지 파일을 업로드하고 경로를 참조하는 번거로운 과정을 우회할 수 있어 시스템이 간결해진다 [1]. 특히 깊이 추정(depth estimation)이나 스타일 변환(style transfer)처럼 다양한 입력 이미지가 반복적으로 요구되는 환경에서 효율적이다 [1].
|
||||
- **연결성:** 이 노드는 이미지를 Base64 데이터로부터 직접 복원하여 워크플로우 내의 다음 노드(예: CLIP Vision Encode, ControlNet 등)로 전달하는 역할을 수행한다 [1], [2].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **파일 경로와의 차이:** 일반적인 'Load Image' 노드는 서버 내 `input` 폴더의 물리적 파일 이름을 참조하지만, 'Load Image (Base64)'는 파일 이름이 아닌 인코딩된 데이터 문자열 자체를 직접 처리한다는 기술적 차이가 존재한다 [1], [2].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Python API 연동 예제 (소스 152):** `comfy_api_python.py`라는 파일 이름으로 구체적인 구현 코드가 제시되었다. 해당 코드에서는 `image_base64(filename)` 함수를 통해 이미지를 인코딩하고, `prompt[str(load_image_node_id)]["inputs"]["base64_data"] = image` 로직을 통해 JSON 데이터를 동적으로 수정하여 ComfyUI 서버에 요청을 보내는 방식이 실제로 적용되었다 [2].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
id: metadata-extraction
|
||||
title: "Metadata Extraction"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["exiftool", "comfyui-extractor.py", "Comfy_UI_prompt_extractor", "ComfyUI-to-Python-Extension", "Weird Wonderful AI Art Extractor"]
|
||||
github_commit: "82df278"
|
||||
---
|
||||
|
||||
# [[Metadata Extraction]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
AI 생성 이미지 파일 자체를 실행 가능한 워크플로우의 '컨테이너'로 활용하여 생성 로직의 영속성과 공유를 보장하는 핵심 메커니즘 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **Steganographic Embedding (비가시적 데이터 주입):** PNG의 `tEXt`나 `zTXt`와 같은 메타데이터 청크 내에 JSON 형식의 노드 그래프와 설정값을 주입하여 보존함 [2, 3].
|
||||
- **Format Redundancy (포맷 중복성):** 시각적 레이아웃 정보가 포함된 **Frontend JSON (workflow.json)**과 실행을 위한 경량화된 **API JSON (prompt)**을 동시에 이미지에 저장하여 편집과 재실행을 모두 지원함 [3, 4].
|
||||
- **Self-Documenting Artifact (자기 문서화 아티팩트):** 생성된 미디어가 단순한 결과물이 아니라, 이를 만든 알고리즘(워크플로우)을 내포한 독립적인 소스 코드 역할을 수행함 [2, 5].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Direct Canvas Restoration:** 이미지 파일을 ComfyUI 브라우저 캔버스로 드래그 앤 드롭하여 즉각적으로 노드 레이아웃을 복구하는 패턴 [1, 6-8].
|
||||
- **Binary Chunk Isolation:** 외부 명령줄 도구를 통해 이미지 데이터와 분리하여 특정 메타데이터 태그(`-workflow`, `-prompt`)만을 바이너리 형태로 추출하는 패턴 [9, 10].
|
||||
- **Metadata Fragility (취약성 패턴):** 이미지 편집기(GIMP 등)나 소셜 미디어 플랫폼을 거치며 최적화 과정에서 비정형 메타데이터가 삭제되어 워크플로우 정보가 소실되는 현상 [3, 11-13].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI의 메타데이터 추출은 단순히 정보를 읽는 것을 넘어, **생성 AI 워크플로우를 재구성하는 기술적 토대**가 됨.
|
||||
|
||||
- **데이터 저장 구조:** PNG 파일 내에서 ComfyUI는 주로 두 가지 문자열을 주입함. 하나는 노드 위치와 시각적 그룹을 포함한 **Frontend 형식**이고, 다른 하나는 백엔드 엔진이 즉시 실행할 수 있는 **API 형식(prompt)**임 [3, 14].
|
||||
- **알고리즘적 추출 방법:**
|
||||
- **Native API:** ComfyUI 웹 인터페이스는 이미지를 불러올 때 내부적으로 메타데이터를 파싱하여 `nodes` 배열을 재구성함 [7, 15].
|
||||
- **CLI 기반 도구:** `exiftool`을 활용하여 `-workflow` 태그를 바이너리(`-b`)로 읽어 JSON 파일로 리다이렉션하는 방식이 표준적으로 사용됨 [9, 10].
|
||||
- **전용 추출기:** `comfyui-extractor.py`나 웹 기반의 `Weird Wonderful AI Art` 도구는 이미지에서 긍정적 프롬프트, API 그래프, UI 레이아웃을 각각 분리하여 추출하는 기능을 제공함 [9, 12, 16].
|
||||
- **프로그래밍적 연동:** `ComfyUI-to-Python-Extension`과 같은 도구는 생성된 Python 스크립트로 이미지를 만들 때 워크플로우 메타데이터를 포함시켜, 추후 사용자가 이미지를 다시 ComfyUI로 드롭했을 때 원래의 워크플로우를 열 수 있도록 설계됨 [17].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **정보 누락 가능성:** Save-Image 노드가 워크플로우를 주입할 때, 새로 추가된 노드나 특정 커스텀 노드의 정보가 때때로 누락될 수 있다는 한계가 보고됨 [11].
|
||||
- **편집기 호환성 문제:** GIMP와 같은 외부 편집 도구를 사용하면 워크플로우 메타데이터가 비표준 태그로 인식되어 삭제되는 이슈가 있으며, 이를 해결하기 위해 `exiftool`의 `%unreg` 설정을 통한 재삽입 기능이 논의되고 있음 [10, 13].
|
||||
- **최신 동향:** 단순 추출을 넘어, 워크플로우를 이미지나 SVG에 렌더링하여 시각적으로 확인하면서도 메타데이터를 보존하는 방식(`pythongosssss' workflow image` 등)이 대안으로 활용됨 [13, 15].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ExifTool 자동화:** `exiftool -b -workflow input.png > workflow.json` 명령어를 통해 대량의 이미지에서 워크플로우를 벌크로 추출함 [9].
|
||||
- **ComfyUI-to-Python-Extension:** 내보낸 `.py` 스크립트 실행 시 `Save As Script` 기능을 통해 이미지 메타데이터에 워크플로우 정보를 동봉함 [17].
|
||||
- **Weird Wonderful AI Art:** 웹 인터페이스를 통해 PNG 파일로부터 JSON 및 Prompt 데이터를 1클릭으로 추출 및 다운로드하는 서비스를 구현함 [12, 16].
|
||||
- **Git Commit:** 소스 내에서 `82df278` 커밋(DanielPFlorian)을 통해 모델 경로 해결 및 모델 정보 누락 방지를 위한 코드 변경이 확인됨 [18].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: node-definitions
|
||||
title: "Node Definitions"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["Node Schema", "ComfyUI Node Structure"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.90
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법", "Node Definitions"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow.json", "workflow_api.json", "object_info.json", "comfyui-workflow-to-api-converter-endpoint", "ComfyUI-WorkflowGenerator"]
|
||||
github_commit: "bc85382, 82df278"
|
||||
---
|
||||
|
||||
# [[Node Definitions]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
노드 정의는 ComfyUI 워크플로우의 기능적 논리와 시각적 레이아웃을 결정하는 핵심 원자 단위로, 고유 ID와 입출력 스키마를 통해 복잡한 AI 프로세스를 유향 비순환 그래프(DAG)로 구조화한다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **고유 식별자 (Node ID):** 워크플로우 내에서 각 노드를 구분하는 고유한 숫자 또는 문자열 키(예: "#37")로, 그래프 순회 및 데이터 참조의 기준이 된다 [4, 5].
|
||||
- **클래스 매핑 (Type/Class Type):** JSON의 `type` 또는 `class_type` 필드는 ComfyUI 백엔드 레지스트리에 등록된 특정 Python 클래스와 노드를 연결하여 실행 로직을 정의한다 [2, 6, 7].
|
||||
- **입출력 슬롯 (I/O Slots):** 데이터 흐름을 위한 인터페이스로, `inputs`는 상위 노드의 출력을 참조하고 `outputs`는 하위 노드로 전달될 데이터 링크 정보를 포함한다 [4, 8].
|
||||
- **위젯 및 속성 (Widgets & Properties):** 슬라이더, 텍스트 박스, 체크박스 등 사용자가 직접 입력한 값(`widgets_values`)과 노드의 내부 동작 설정을 저장한다 [2, 4, 9].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **형식의 이분화 (Serialization Bifurcation):** 시각적 정보(위치, 크기, 그룹)를 포함하는 **Frontend 형식(workflow.json)**과 실행에 필요한 논리 정보만 남긴 **API 형식(workflow_api.json)**으로 나뉘어 관리된다 [10-12].
|
||||
- **실행 모델 역전 (Execution Model Inversion):** 엔진은 모든 노드를 실행하는 대신 'Save Image'와 같은 출력 노드에서 역방향으로 그래프를 탐색하여 필요한 의존성 노드만 실행 리스트에 포함시킨다 [13].
|
||||
- **메타데이터 임베딩 패턴:** 생성된 미디어(PNG, WebP)의 tEXt/zTXt 청크 내에 노드 그래프 JSON을 주입하여 파일 자체가 워크플로우 컨테이너 역할을 수행하도록 설계한다 [14-16].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 노드는 **JSON v1.0 스키마**에 따라 정밀하게 정의되며, 각 노드 객체는 다음과 같은 필수 속성을 보유해야 한다 [2, 17]:
|
||||
- **id:** 그래프 순회를 위한 유효한 정수 또는 문자열 식별자 [2, 5].
|
||||
- **type/class_type:** 노드의 기능을 결정하는 레지스트리 클래스명 [2, 6].
|
||||
- **pos & size:** UI 캔버스 렌더링을 위한 좌표 `[x, y]` 및 차원 `[width, height]` 정보 (Frontend 전용) [2, 4].
|
||||
- **widgets_values:** 사용자가 입력한 위젯 상태 값의 배열 또는 객체 [2, 4].
|
||||
- **order:** 노드의 실행 또는 렌더링 우선순위를 나타내는 인덱스 [2].
|
||||
- **mode:** 노드의 작동 상태(활성, 우회/Bypass 등)를 결정하는 수치 [2, 18].
|
||||
|
||||
**연결 구조(Connectivity):**
|
||||
연결은 `inputs`와 `outputs` 배열을 통해 정의된다. `inputs` 내부의 `link` 속성은 들어오는 와이어의 고유 ID를 가리키며, API 형식에서는 이를 소스 노드 ID와 슬롯 인덱스의 쌍(예: `[19, 20]`)으로 직접 포함하기도 한다 [8, 9]. 슬롯 인덱싱은 다중 출력을 가진 노드(예: VAE Loader)에서 특정 데이터를 선택하는 데 필수적이다 [8].
|
||||
|
||||
**스키마 카탈로그 (object_info.json):**
|
||||
실행 중인 인스턴스에서 사용 가능한 모든 노드의 입력/출력 타입, 필수/선택적 입력 항목, 기본값 및 툴팁 정보를 포함하는 레지스트리 역할을 한다 [21, 22]. 이는 워크플로우를 동적으로 생성하거나 검증하는 도구에서 참조 모델로 사용된다 [23].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **JSON 버전 차이:** 소스 데이터는 최신 버전인 **v1.0**을 언급하지만, 이전 버전인 **0.4**와의 호환성 문제나 업데이트 논의가 여전히 진행 중임을 암시한다 [17, 24].
|
||||
- **대소문자 민감도 이슈:** ComfyUI 검증기가 콤보 위젯 값의 대소문자(예: "True" vs "true") 차이로 인해 실행을 거부하는 경우가 발생하여, 최신 변환 엔진에서는 이를 정규화(Normalization)하는 로직이 추가되었다 [25].
|
||||
- **노드 식별 키의 차이:** Frontend JSON은 수치형 문자열을 ID로 사용하는 반면, API JSON은 이를 기능적 키로 활용하며 UI 메타데이터를 완전히 제거한다 [10, 11, 26].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **workflow.json / workflow_api.json:** 노드 정의가 실제로 구현되는 표준 파일 형식으로, RunComfy 및 Replicate와 같은 서비스에서 배포의 기초로 사용된다 [12, 21, 27].
|
||||
- **object_info.json:** 실행 중인 서버의 `/object_info` 엔드포인트를 통해 실시간 노드 스키마를 제공한다 [23].
|
||||
- **comfyui-workflow-to-api-converter-endpoint (v2.3.0):** 비-API 워크플로우를 API 형식으로 변환할 때 `COMFY_DYNAMICCOMBO_V3` 위젯 및 하위 입력을 처리하고 대소문자 문제를 해결하는 로직이 적용되었다 (Commit: `bc85382`) [25, 28-30].
|
||||
- **ComfyUI-WorkflowGenerator:** 자연어 설명을 기반으로 `WorkflowGenerator` -> `NodeValidator` -> `WorkflowBuilder` 단계를 거쳐 노드 그래프를 동적으로 생성하며, `UpdateNodeCatalog` 노드를 통해 로컬 노드 레지스트리를 스캔한다 (Commit: `82df278`) [31-34].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: node-based-visual-programming
|
||||
title: "Node-based Visual Programming"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["시각적 프로그래밍", "그래프 기반 프로그래밍"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["DanielPFlorian/ComfyUI-WorkflowGenerator", "SethRobinson/comfyui-workflow-to-api-converter-endpoint", "pydn/ComfyUI-to-Python-Extension", "docs.comfy.org/specs/workflow_json"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Node-based Visual Programming]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI의 노드 기반 시각적 프로그래밍은 복잡한 AI 생성 프로세스를 **방향성 비순환 그래프(DAG)**로 추상화하여, 코드 작성 없이도 정교한 파이프라인 설계와 실행 로직의 직렬화를 실현한다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **노드 및 그래프 구조 (Nodes & Graph):** 로더, 샘플러, 인코더 등 특정 기능을 수행하는 프로그램 객체(Nodes)를 링크(Links)로 연결하여 전체 데이터 흐름을 정의하는 네트워크를 형성한다 [1, 3].
|
||||
- **방향성 비순환 그래프 (Directed Acyclic Graph, DAG):** 데이터가 한 방향으로만 흐르며 순환하지 않는 구조로, 생성 AI의 절차적 프레임워크를 효율적으로 기술한다 [1, 4].
|
||||
- **워크플로 직렬화 (Serialization):** 시각적으로 구성된 그래프를 인간이 읽을 수 있고 용량이 작은 **JSON 형식**으로 변환하여 아카이빙, 공유 및 프로그래밍 방식의 자동화를 가능하게 한다 [1, 5].
|
||||
- **시각적 추상화:** 정적 메뉴나 선형 파이프라인 대신 노드 간의 동적 연결을 통해 복잡한 시스템을 직관적으로 설계할 수 있는 고수준 환경을 제공한다 [1, 2].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **형식의 이분화 (Bifurcation of Formats):** 시각적 레이아웃 정보를 포함한 **프론트엔드 포맷(workflow.json)**과 실행에 필수적인 로직만 남긴 **API 포맷(workflow_api.json)**으로 구분하여 사용 목적에 최적화한다 [6, 7].
|
||||
- **메타데이터 임베딩 (Metadata Embedding):** 생성된 미디어 파일(PNG, WebP 등) 내부에 워크플로 전체 로직을 주입하여, 이미지 자체가 생성 청사진의 컨테이너 역할을 하도록 설계한다 [5, 8].
|
||||
- **실행 모델 역전 (Execution Model Inversion):** 엔진이 출력 노드(Save Image 등)에서 시작하여 그래프를 역방향으로 탐색, 최종 출력에 필요한 의존성 노드만 식별하여 실행 최적화를 달성한다 [9].
|
||||
- **LLM 기반 합성 파이프라인:** 자연어 설명을 '논리적 합성 → 세만틱 검증 → 그래프 컴파일'의 3단계 과정을 거쳐 실행 가능한 JSON 노드 그래프로 변환하는 자동화 패턴이 등장하고 있다 [10-12].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI는 생성형 AI 콘텐츠를 구축하고 실행하기 위한 **절차적 프레임워크(Procedural Framework)**로 기능한다 [3, 4]. 노드 기반 방식은 전통적인 소프트웨어의 버튼 기반 UI가 제공할 수 없는 수준의 유연성을 제공하며, 사용자는 수학적 지식이나 프로그래밍 코드 없이도 복잡한 시스템을 설계할 수 있다 [2].
|
||||
|
||||
### JSON 스키마 및 데이터 구조
|
||||
ComfyUI 워크플로의 핵심인 JSON 파일은 **v1.0 규격**을 따르며, 각 노드는 고유 ID, 클래스 타입(type), 캔버스 좌표(pos), 크기(size), 입력(inputs) 및 출력(outputs) 슬롯 정보를 포함한다 [13, 14]. 특히 링크는 `[origin_id, origin_slot, target_id, target_slot]`의 구조로 정의되어 노드 간의 정밀한 데이터 전송을 보장한다 [15].
|
||||
|
||||
### 워크플로 생성 및 관리 방식
|
||||
1. **수동 생성:** 웹 인터페이스에서 노드를 배치하고 `Ctrl+S`를 통해 시각적 레이아웃이 포함된 JSON을 내보내거나, 'Dev mode'를 활성화하여 실행 전용 API 포맷을 추출할 수 있다 [16, 17].
|
||||
2. **프로그래밍 방식 생성:** Python의 `json` 라이브러리를 사용해 딕셔너리 구조를 직접 수정하거나, `Comfy Nodekit` 또는 `Comfy API Simplified`와 같은 래퍼 라이브러리를 통해 노드 제목 기반으로 매개변수를 동적으로 변경할 수 있다 [18, 19].
|
||||
3. **미디어 추출:** `exiftool`이나 웹 기반 추출 도구를 사용해 PNG의 `tEXt` 또는 `zTXt` 청크에서 직렬화된 워크플로 데이터를 복구할 수 있다 [20-22].
|
||||
|
||||
### 의존성 및 보안 관리
|
||||
워크플로 공유 시 가장 흔한 문제는 'Missing Custom Nodes' 오류(붉은색 노드)이며, 이를 위해 **ComfyUI-Manager**가 JSON을 파싱하여 누락된 패키지를 식별하고 자동 설치를 지원한다 [23, 24]. 최신 동향으로는 모델 파일의 경로 문제 해결을 위해 파일명 대신 **SHA-256 해시값**을 사용하는 모델 해싱 방식이 도입되고 있다 [25, 26].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **데이터 보존의 취약성:** PNG 메타데이터에 저장된 워크플로는 소셜 미디어나 파일 압축 과정에서 손실되기 쉬우며, 이로 인해 이미지 드래그 앤 드롭 기능을 상실할 수 있는 위험이 존재한다 [20].
|
||||
- **포맷 간 불일치:** API 포맷 JSON을 UI에 직접 로드할 경우 시각적 레이아웃 정보가 없어 그래프가 '스켈레톤' 상태로 나타나는 등 편집이 어려워지는 문제가 발생한다 [27]. 이를 해결하기 위해 서버 사이드에서 비-API 포맷을 API 포맷으로 변환해주는 별도의 엔드포인트 구현 사례가 존재한다 [28].
|
||||
- **버전 호환성:** ComfyUI의 빈번한 업데이트로 인해 구버전 JSON 파일이 최신 버전에서 정상적으로 작동하지 않을 수 있음을 공식적으로 경고하고 있다 [29].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **DanielPFlorian/ComfyUI-WorkflowGenerator:** LLM(Qwen2.5-14B)을 사용하여 자연어 설명을 ComfyUI 노드 그래프로 자동 생성하는 3단계 파이프라인 구현 [30, 31].
|
||||
- **SethRobinson/comfyui-workflow-to-api-converter-endpoint:** 비-API 워크플로 JSON을 서버측에서 실행 가능한 API 포맷으로 자동 변환하는 `/workflow/convert` 엔드포인트 제공 [28, 32].
|
||||
- **pydn/ComfyUI-to-Python-Extension:** 워크플로 JSON을 독립적인 실행이 가능한 Python 스크립트(`.py`)로 변환하는 도구 [33, 34].
|
||||
- **ComfyUI 공식 문서 (`docs.comfy.org/specs/workflow_json`):** 워크플로 무결성 검증을 위한 JSON Schema v1.0(Draft-07 기반) 규격 정의 [14, 35].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (주요 오픈소스 프로젝트 및 공식 문서 내 스펙 확인됨)
|
||||
- **출처 신뢰도:** B (Official Documentation / GitHub Repository / Expert Tutorial Synthesis)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
id: nodes
|
||||
title: "Nodes"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI-WorkflowGenerator", "ComfyUI-to-Python-Extension", "comfyui-workflow-to-api-converter-endpoint"]
|
||||
github_commit: "82df278, bc85382"
|
||||
---
|
||||
|
||||
# [[Nodes]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
노드는 ComfyUI의 핵심 엔진이자 기능적 단위로서, 고유한 메타데이터와 입출력 연결을 통해 생성형 AI 프로세스를 유향 비순환 그래프(DAG)로 추상화한다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **노드 객체 (Node Object):** ID, 타입, 위치 정보를 포함하며 특정 기능을 수행하는 독립적인 프로그램 모듈이다 [3-5].
|
||||
- **입출력 슬롯 및 링크 (I/O Slots & Links):** 노드 간 데이터를 전달하는 통로로, 입력(inputs)은 들어오는 와이어의 ID를, 출력(outputs)은 하나 이상의 하류 노드로 연결되는 링크 ID 배열을 포함한다 [4, 6].
|
||||
- **노드 레지스트리 (Node Registry):** 설치된 모든 노드의 클래스 이름과 입출력 스키마(object_info)를 관리하는 중앙 카탈로그이다 [4, 7, 8].
|
||||
- **실행 모드 (Mode):** 노드의 활성화 상태(active), 우회(bypass) 등을 결정하며, 백엔드 엔진은 이를 기반으로 실행 경로를 계산한다 [4, 5, 9].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **실행 모델 역전 (Execution Model Inversion):** 엔진이 출력 노드(Save Image 등)에서 시작하여 역방향으로 그래프를 탐색, 결과 도출에 필요한 의존성 노드만 실행하여 효율성을 극대화한다 [10].
|
||||
- **형식별 노드 직렬화:** 프론트엔드 형식(workflow.json)은 노드의 좌표, 크기 등 시각적 메타데이터를 유지하는 반면, API 형식(workflow_api.json)은 실행에 필요한 로직과 직접적인 노드 입력 참조만 남긴다 [11-13].
|
||||
- **자동 검증 및 보정:** 생성된 워크플로의 노드 이름을 로컬 설치 환경이나 시맨틱 임베딩과 대조하여 유효성을 검사하고 오류를 수정한다 [14-16].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
|
||||
### 노드 객체의 기술적 사양 (v1.0 Schema)
|
||||
ComfyUI 워크플로 JSON 내에서 각 노드는 다음과 같은 속성을 필수적으로 정의해야 한다 [4, 5]:
|
||||
- **id:** 그래프 탐색을 위한 고유 식별자 (정수 또는 문자열) [17].
|
||||
- **type / class_type:** 노드 레지스트리의 클래스 이름과 매핑되는 식별자 [5, 18].
|
||||
- **pos & size:** 캔버스 좌표 [x, y] 및 시각적 크기 [width, height] (프론트엔드 전용) [4, 19].
|
||||
- **widgets_values:** 슬라이더, 텍스트 박스, 토글 등 사용자 입력 값을 저장하는 배열 [4, 20].
|
||||
- **order:** 노드의 실행 또는 렌더링 순서 인덱스 [4].
|
||||
|
||||
### 주요 노드 카테고리 및 기능
|
||||
- **로더 (Loaders):** Checkpoint, LoRA, VAE, ControlNet 등 외부 모델 가중치를 워크플로로 불러온다 [21, 22].
|
||||
- **샘플러 (Samplers):** KSampler, SamplerCustom 등 잠재 공간(Latent space)에서 노이즈를 제거하여 이미지를 생성한다 [23, 24].
|
||||
- **조건화 및 인코딩 (Conditioning & Encoding):** CLIP Text Encode(프롬프트 처리), VAE Encode/Decode(픽셀과 잠재 공간 간 변환) 등을 수행한다 [20, 21, 24].
|
||||
- **유틸리티 (Utils):** Reroute(선 정리), Primitive, Note 등 워크플로의 조직화와 가독성을 돕는다 [23, 25].
|
||||
|
||||
### API 및 자동화 환경의 노드 처리
|
||||
API 기반 실행 시, 노드는 **API JSON 형식**으로 직렬화되어 시각적 정보가 제거된다 [11, 26]. 이때 노드 간 연결은 별도의 링크 배열이 아닌 `inputs` 필드 내에 상류 노드 ID와 슬롯 인덱스 형태로 직접 임베딩된다 [11, 20]. 독립 실행형 스크립트나 외부 앱 연동 시에는 `Load Image (Base64)` 노드를 통해 이미지를 JSON 내에 직접 포함시키거나, `SaveImageWebsocket`을 통해 결과를 실시간으로 수신하는 패턴이 사용된다 [17, 27, 28].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **노드 식별 방식:** 프론트엔드 JSON은 시각적 ID를 사용하지만, API JSON은 기능적 키(Functional keys)를 사용하여 백엔드와 매핑한다 [12].
|
||||
- **커스텀 노드 의존성:** 소스 간 공통적으로 지적되는 문제로, 워크플로 JSON에 포함된 노드가 로컬에 설치되어 있지 않으면 '빨간 박스(Missing Nodes)' 오류가 발생하며 ComfyUI Manager를 통한 해결이 권장된다 [29-31].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI-WorkflowGenerator [32, 33]:** 자연어 설명을 기반으로 `Generator` -> `Validator` -> `Builder` 단계를 거쳐 노드 그래프를 자동으로 생성하고 검증하는 시스템을 구현함.
|
||||
- **comfyui-workflow-to-api-converter-endpoint [8, 25, 34]:** `/workflow/convert` 엔드포인트를 통해 프론트엔드 노드 데이터를 API 규격으로 변환하며, `reroute` 노드 무시 및 `INPUT_TYPES()` 기반 기본값 보정 기능을 포함함 (Commit: `bc85382`).
|
||||
- **ComfyUI-to-Python-Extension [35, 36]:** UI의 노드 그래프를 실행 가능한 Python 스크립트로 변환하여 자동화 환경에서 노드 로직을 재사용할 수 있게 함.
|
||||
- **RunComfy API [7, 37]:** `object_info.json`을 통해 인스턴스 내 모든 노드의 입력/출력 스키마를 제공하여 외부 툴의 유효성 검사에 활용함.
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 프로젝트 및 공식 문서 내 스펙 확인됨)
|
||||
- **출처 신뢰도:** B (공식 문서 및 오픈소스 프로젝트 기술 명세 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine. (Sources: [1-6, 8, 11, 33])
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
id: rag-(retrieval-augmented-generation)
|
||||
title: "RAG (Retrieval-Augmented Generation)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["검색 증강 생성"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법", "LLM", "Workflow-Automation"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["ComfyUI-WorkflowGenerator (Future Roadmap)", "Alibaba ViDoRAG"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[RAG (Retrieval-Augmented Generation)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
RAG는 정적인 학습 데이터에 갇힌 LLM의 한계를 넘어, 실시간 노드 생태계와 전문가의 워크플로우 패턴을 동적으로 검색하여 실행 가능한 ComfyUI JSON을 생성하는 차세대 아키텍처의 핵심이다 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **노드 정보 검색 (Node Information Retrieval):** 모델 가중치에 노드 지식을 고정하는 대신, 현재 설치된 노드 및 최신 리포지토리를 포함하는 동적 벡터 데이터베이스를 쿼리하여 새로운 노드 정보를 실시간으로 획득한다 [2].
|
||||
- **사례 기반 추론 (Case-Based Reasoning):** 커뮤니티에서 공유된 수천 개의 고품질 워크플로우를 "지식 패턴"으로 인덱싱하고, 특정 문제 해결(예: ControlNet 연결 방식)을 위해 기존 전문가의 하위 그래프를 검색 및 복제한다 [2].
|
||||
- **I/O 스키마 인식 (I/O Schema Awareness):** 단순한 이름 일치를 넘어, 검색된 데이터를 바탕으로 노드 간의 데이터 유형(Float, Image, Latent 등)이 실행 가능한 수준에서 호환되는지 논리적으로 검증한다 [2].
|
||||
- **정적 모델의 한계 극복:** 학습 시점(Cutoff) 이후에 출시된 커스텀 노드에 대해 "환각(Hallucination)" 없이 정확한 연결 구조를 제안하기 위한 수단으로 활용된다 [1, 3].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **3단계 생성 파이프라인의 확장:** 기존 [논리적 합성 -> 세만틱 검증 -> 그래프 컴파일] 과정 중 검증 및 합성 단계에서 외부 지식을 주입하는 패턴이 발견된다 [2, 4, 5].
|
||||
- **에이전트 기반 탐색:** 워크플로우 생성기가 단순한 변환기가 아닌, 실시간 ComfyUI 환경을 "읽고" 문서화된 노드 사양을 학습하여 즉시 적용하는 능동적 에이전트 패턴으로 진화한다 [2, 6].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **정적 모델의 문제점:** 현재의 워크플로우 생성 모델(예: Qwen2.5-14B 기반)은 학습 데이터에 포함되지 않은 새로운 커스텀 노드나 변경된 아키텍처에 대응할 수 없는 "Frozen" 상태이다 [1].
|
||||
- **노드용 RAG (RAG for Nodes):** 미래의 아키텍처는 에이전트가 사용자의 **현재 설치된 노드**와 외부 데이터베이스를 쿼리하도록 설계된다. 이를 통해 오늘 출시된 노드의 문서도 즉시 "읽고" 워크플로우에 반영할 수 있다 [2].
|
||||
- **워크플로우 검색 및 적응:** 무에서 유를 창조하는 대신, 온라인상의 방대한 워크플로우 라이브러리를 인덱싱하여 검색한다. 에이전트는 전문가가 특정 하위 문제(Sub-problem)를 해결한 방식을 식별하고 이를 현재 작업에 맞게 적응시킨다 [2].
|
||||
- **지능형 디버깅:** AI 에이전트가 오류 메시지를 분석하고 RAG를 통해 적절한 대체 노드를 제안하거나 JSON 워크플로우를 수정하는 기능으로 확장될 수 있다 [7].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **현재와 미래의 격차:** 현재 제공되는 `ComfyUI-WorkflowGenerator`는 정적으로 미세 조정(Fine-tuned)된 모델을 사용하며, RAG 기반의 동적 노드 검색은 차세대 도구를 위한 "미래 비전" 및 "로드맵"으로 제시되고 있다 [2, 3, 8].
|
||||
- **기술적 성숙도:** 소스 내에서 RAG는 실제 구현된 기능보다는 모델의 한계를 극복하기 위한 아키텍처적 제안으로 주로 다루어진다 [2, 6].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **ComfyUI-WorkflowGenerator:** 프로젝트의 향후 비전으로 "Retrieval-Augmented Generation (RAG) for Nodes"를 명시하고 있으며, 벡터 임베딩 데이터베이스를 통한 노드 검색 아키텍처를 설계 중이다 [2].
|
||||
- **Alibaba ViDoRAG:** 소스 내 뉴스 목록에 "Intelligent Document Analysis Tool"로서 언급되어 있으나, 구체적인 ComfyUI 워크플로우 생성 연동 방식은 상세히 기술되지 않았다 [9].
|
||||
- **NodeValidator:** 현재 버전에서는 RAG의 초기 형태인 '세만틱 검색(Semantic Search)'을 사용하여 노드 이름의 오타를 수정하거나 설치된 노드 카탈로그와 대조하는 기능을 수행하고 있다 [10].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 RAG 엔진의 상세 구현 코드는 소스에 포함되지 않았으며, 아키텍처 제안 단계임)
|
||||
- **출처 신뢰도:** B (GitHub 오픈소스 연구 및 공식 문서 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine. (Focus: Architectural vision of RAG in workflow generation) [1, 2, 6, 8]
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
id: retrieval-augmented-generation-(rag)-for-nodes
|
||||
title: "Retrieval-Augmented Generation (RAG) for Nodes"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: []
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Retrieval-Augmented Generation (RAG) for Nodes]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
정적인 파인튜닝 모델의 지식 유효기간 한계를 극복하기 위해, 현재 설치된 노드와 최신 저장소의 정보를 실시간으로 검색하여 워크플로우를 생성하는 동적 아키텍처 [1, 2].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **동적 벡터 임베디드 데이터베이스 (Dynamic Vector-Embedded Database):** 사용자의 로컬 환경과 인터넷상의 최신 노드 저장소 정보를 실시간으로 쿼리할 수 있도록 벡터화하여 저장하는 시스템 [2].
|
||||
2. **노드 지식의 탈동기화 (Decoupling Node Knowledge):** 모델 가중치에 노드 정보를 고정하는 대신, 외부 지식 베이스에서 정보를 가져와 모델의 지식을 최신 상태로 유지함 [1, 2].
|
||||
3. **실시간 문서 해석 (Real-time Documentation Parsing):** 오늘 출시된 새로운 노드라도 에이전트가 해당 노드의 문서를 즉시 "읽고" 워크플로우 구성에 활용할 수 있게 함 [2].
|
||||
4. **환경 인지형 에이전트 (Environment-Aware Agent):** 사용자의 '현재 설치된' 노드 구성을 분석하고 이를 생성 프로세스에 반영하는 지능형 시스템 [2].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
* **지식 검색 기반 보정 (Retrieval-Based Correction):** 모델이 학습하지 못한 새로운 노드의 연결 방식이나 파라미터를 검색된 지식(RAG)을 통해 보정하는 패턴 [2].
|
||||
* **사례 기반 추론 및 적응 (Case-Based Reasoning & Adaptation):** 온라인의 고품질 워크플로우를 '지식 패턴'으로 인덱싱하고, 이를 검색하여 현재 문제 해결에 맞게 변형하여 적용함 [2].
|
||||
* **I/O 스키마 인식 (I/O Schema Awareness):** 단순히 노드 이름을 맞추는 수준을 넘어, 데이터 타입(Float, Image, Conditioning 등) 간의 실행 가능성을 검색된 정보를 기반으로 검증함 [2].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
* **정적 모델의 한계:** 현재의 `WorkflowGenerator`와 같은 모델은 특정 시점의 데이터로 파인튜닝되어 '동결'된 상태임 [1]. 따라서 매일 업데이트되는 ComfyUI 커스텀 노드 생태계의 변화를 따라잡지 못하며, 학습 데이터에 없는 노드에 대해 잘못된 연결(Hallucination)을 생성할 위험이 있음 [1, 2].
|
||||
* **RAG를 통한 해결책:** 미래의 워크플로우 생성 도구는 정적 파인튜닝을 넘어 RAG 시스템으로 진화해야 함 [3]. 에이전트는 사용자의 로컬 노드 카탈로그와 최신 온라인 데이터베이스를 동시에 쿼리하여 지식을 보충함 [2].
|
||||
* **워크플로우 검색 시스템:** 수천 개의 커뮤니티 워크플로우를 인덱싱하여, 전문가들이 특정 하위 문제(예: ControlNet과 Wan Video 노드의 연결 방식)를 해결하는 방식을 패턴화하고 이를 생성 시점에 검색하여 활용함 [2].
|
||||
* **기술적 이점:** 이 방식은 대규모 모델(70B+) 대신 그래프 이론과 DAG(Directed Acyclic Graph) 추론에 특화된 소규모 전문 모델(SLM)을 사용하면서도, 검색 시스템(RAG)을 통해 방대한 노드 어휘력을 확보할 수 있게 함 [2].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
* **현재와 미래의 격차:** 소스 데이터에 따르면 RAG 기반 노드 생성은 현재 완전히 구현된 기능이 아니라, ComfyGPT 연구를 기반으로 한 '차세대 도구의 진화 방향' 및 '아이디어'로 제시되고 있음 [2, 3].
|
||||
* **카탈로그 업데이트의 필요성:** 현재 구현(WorkflowGenerator)에서는 `UpdateNodeCatalog` 노드를 통해 로컬 노드를 스캔하여 수동으로 지식을 동기화해야 하는 단계에 머물러 있음 [4, 5].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
현재 소스 데이터에서 이 개념이 완전히 구현되어 적용된 실제 코드 사례는 발견되지 않았으며, "Future Vision(미래 비전)" 항목으로 기술되어 있음 [2]. 다만, 이를 위한 기초적인 단계로서 다음의 기능들이 언급됨:
|
||||
* **UpdateNodeCatalog 노드:** 현재 설치된 모든 노드(네이티브 및 커스텀)를 스캔하고 카탈로그화하여 노드 검증 및 빌드에 활용함 [5].
|
||||
* **NodeValidator 노드:** 시맨틱 검색(Semantic Search)을 통해 생성된 노드 이름을 로컬 카탈로그와 대조하여 교정함 [6].
|
||||
* **WorkflowGenerator 아키텍처:** ComfyGPT 연구를 바탕으로 생성-검증-구축의 3단계 파이프라인을 구축하여 RAG 시스템으로의 확장을 위한 토대를 마련함 [3, 7].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: serialization-formats
|
||||
title: "Serialization Formats"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["Workflow JSON Formats", "Frontend vs API Format"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow.json", "workflow_api.json", "object_info.json", "bc85382"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Serialization Formats]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI 직렬화는 인간의 시각적 편집을 위한 **Frontend 포맷(UI 데이터 포함)**과 서버 및 스크립트 실행을 위한 **API 포맷(순수 로직)**으로 이원화되어 워크플로우의 가시성과 실행 효율성을 동시에 확보한다 [1-4].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **Frontend Format (workflow.json):** Litegraph 표준을 따르며 노드 위치, 크기, 그룹화 등 시각적 메타데이터를 포함하여 사용자 인터페이스 재구성을 지원한다 [1, 2, 5].
|
||||
2. **Backend/API Format (workflow_api.json):** 시각적 요소를 제거하고 노드 입력값과 연결 관계만 포함된 스트림라인 실행 그래프로, `/prompt` 엔드포인트를 통한 프로그래밍적 호출에 최적화되어 있다 [1, 2, 6].
|
||||
3. **Metadata Injection:** PNG 또는 WebP 이미지 생성 시, tEXt 또는 zTXt 청크 내부에 Frontend 워크플로우와 API 프롬프트 데이터를 직접 삽입하여 이미지를 워크플로우 컨테이너로 활용한다 [7-9].
|
||||
4. **Schema Specification (v1.0):** 노드 ID, 유형, 위치(pos), 크기(size), 실행 순서(order) 및 모드(mode) 등 그래프 무결성을 보장하기 위한 기술적 제약 조건을 정의한다 [10-12].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **Bifurcation Pattern (이원화 패턴):** 동일한 로직을 시각적 레이아웃용(Frontend)과 실행용(API)으로 분리하여 저장함으로써 사용자 경험과 API 확장성을 분리하여 관리한다 [1, 2].
|
||||
- **Link Embedding Strategy:** API 포맷에서는 명시적인 연결 객체 대신 노드 입력 필드 내에 '기원 노드 ID'와 '출력 슬롯 인덱스'를 직접 참조(예: `[13, 14]`)하여 그래프 구조를 단순화한다 [1, 15].
|
||||
- **Schema Validation Pattern:** `object_info.json`을 통해 실행 인스턴스의 노드 스키마(입출력 유형, 범위 등)를 카탈로그화하고, 실행 전 `validate_prompt` 함수로 워크플로우의 유효성을 검증한다 [16-18].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
- **Frontend JSON 구조 및 특징:**
|
||||
- 노드 식별을 위해 고유한 시각적 ID(숫자 문자열)를 사용하며, 노드가 축소되거나 고정되었는지와 같은 시각적 플래그를 유지한다 [1, 19].
|
||||
- `links` 배열을 별도로 두어 노드 간의 물리적 연결 관계를 정의하며, 6개 항목으로 구성된 배열 형식을 통해 기원/대상 노드 및 슬롯 정보를 명시한다 [3, 11, 19].
|
||||
|
||||
- **API JSON 구조 및 특징:**
|
||||
- 불필요한 UI 메타데이터를 제거하여 파일 크기를 압축하고 전송 효율을 높인다 [1, 2, 6].
|
||||
- 키값은 노드 ID로 구성되며, 각 값은 `class_type`과 `inputs`를 포함한 객체이다. 입력 필드에는 위젯 값 또는 다른 노드로부터의 링크 참조가 포함된다 [6, 18, 20].
|
||||
|
||||
- **메타데이터 저장 방식:**
|
||||
- PNG 파일의 경우, ComfyUI는 워크플로우(Frontend)와 프롬프트(API)를 별개의 문자열로 저장한다. 이는 이미지를 UI로 드래그했을 때 시각적 편집이 가능하게 함과 동시에 프로그래밍적 재실행을 가능하게 하는 중복 구조를 제공한다 [8].
|
||||
- 단, 이미지 편집 소프트웨어나 소셜 미디어 플랫폼을 거칠 경우 이러한 비필수 메타데이터 청크가 손실될 위험이 크다 [8, 21].
|
||||
|
||||
- **기타 주요 직렬화 아티팩트:**
|
||||
- `object_info.json`: 실행 중인 ComfyUI 인스턴스의 모든 노드 스키마 등록부로, 입출력 유형, 허용 범위, 툴팁 등을 포함하여 도구 개발이나 입력값 검증에 사용된다 [5, 17, 18].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **하위 호환성 문제:** ComfyUI가 빈번하게 업데이트됨에 따라, 이전 버전에서 생성된 JSON 파일이 최신 버전의 ComfyUI에서 제대로 작동하지 않을 수 있다는 점이 명시되어 있다 [22].
|
||||
- **데이터 유실 가능성:** 이미지 기반 직렬화는 편리하지만, 압축 소프트웨어나 네트워크 전송 시 메타데이터가 제거될 수 있어 JSON 파일 형태의 별도 저장이 권장된다 [8, 22, 23].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **workflow.json & workflow_api.json:** ComfyUI의 표준 저장 포맷으로 사용되며, RunComfy 및 Mystic 등 서버리스 API 배포 플랫폼의 기본 참조 파일로 활용된다 [1, 17, 24].
|
||||
- **object_info.json:** 실행 인스턴스에서 스키마 정보를 추출하기 위해 `https://<server_id>/object_info` 엔드포인트를 통해 접근 가능하다 [25].
|
||||
- **comfyui-workflow-to-api-converter-endpoint:** Frontend 포맷의 워크플로우를 서버 측에서 실시간으로 API 포맷으로 변환하는 기능을 구현한 커스텀 노드 프로젝트이다 [26].
|
||||
- **Git Commit bc85382:** 콤보 위젯 값의 대소문자 표기 오류(예: "True" vs "true")가 유효성 검사에서 거부되는 문제를 해결하기 위해 대소문자 구분 없는 매칭 로직이 적용되었다 [27, 28].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
id: workflow-extractor
|
||||
title: "Workflow Extractor"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["메타데이터 추출기", "Workflow Metadata Recovery"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy-cli", "Weird Wonderful AI Art Extractor", "Comfy_UI_prompt_extractor"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Workflow Extractor]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
생성된 미디어(PNG/WebP)의 메타데이터 청크에 숨겨진 노드 그래프와 실행 로직을 복원하여 워크플로우의 이식성과 재현성을 보장하는 핵심 기술 도구이다. [1-3]
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **메타데이터 임베딩 (Metadata Embedding):** ComfyUI의 `Save Image` 노드는 실행 시 PNG 파일의 숨겨진 메타데이터(tEXt 또는 zTXt 청크) 내에 전체 노드 그래프, 레이아웃, 설정 및 프롬프트를 주입한다. [3-5]
|
||||
- **데이터 이중성 (Data Redundancy):** 메타데이터에는 시각적 편집을 위한 '프론트엔드 포맷(Workflow JSON)'과 실행을 위한 '백엔드/API 포맷(Prompt JSON)'이 동시에 포함되어 재수정 및 재실행을 모두 지원한다. [5, 6]
|
||||
- **메타데이터 취약성 (Fragility of Metadata):** 표준 이미지 편집기, 소셜 미디어 플랫폼 또는 압축 소프트웨어를 거칠 경우 파일 크기 최적화나 개인정보 보호를 위해 해당 JSON 데이터가 삭제될 수 있다. [2, 5, 7]
|
||||
- **알고리즘 기반 복원 (Algorithmic Extraction):** 드래그 앤 드롭 방식이 불가능한 환경이나 대량의 데이터 처리를 위해 CLI 도구나 웹 기반 도구를 사용하여 바이너리 태그에서 워크플로우를 분리해낸다. [8-10]
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **주입 패턴:** 워크플로우의 종단점인 `Save Image` 노드가 실행될 때 최종 이미지에 노드 레이아웃 정보를 주입하는 자동화된 직렬화 패턴을 따른다. [4]
|
||||
- **복원 패턴:** `exiftool`과 같은 범용 도구를 사용하여 바이너리 데이터를 추출하거나, 전용 파이썬 스크립트를 통해 긍정적 프롬프트와 API 그래프를 분리하여 저장하는 패턴이 관찰된다. [8, 10]
|
||||
- **사용자 편의 패턴:** 사용자가 복잡한 추출 과정 없이 이미지를 캔버스에 드래그 앤 드롭하기만 하면 내부 노드 그래프가 즉시 재구성되는 직관적인 UI 인터페이스를 제공한다. [4, 7, 11, 12]
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
워크플로우 추출은 단순한 파일 읽기를 넘어 인공지능 생성 예술의 '소스 코드'를 관리하는 핵심 프로세스이다. ComfyUI는 시각적 프로그래밍 환경으로서의 특성을 유지하기 위해 이미지 자체를 워크플로우의 컨테이너로 활용한다. [3, 13]
|
||||
|
||||
**기술적 메커니즘**
|
||||
PNG 파일의 경우, ComfyUI는 `tEXt` 또는 `zTXt` 청크를 사용하여 워크플로우 정보를 텍스트 문자열로 저장한다. [5] 이 정보는 인간이 읽을 수 있는 JSON 형식을 따르며, 노드 간의 링크, 위치 정보(Frontend), 그리고 백엔드 실행을 위한 입력값(API)을 포함한다. [14-16]
|
||||
|
||||
**추출 도구의 유형**
|
||||
1. **네이티브 복원:** 이미지를 ComfyUI 브라우저 탭으로 직접 드래그하여 현재 노드를 대체하고 레이아웃을 복구한다. [4, 17, 18]
|
||||
2. **웹 기반 추출기:** 'Weird Wonderful AI Art'와 같은 플랫폼은 사용자가 이미지를 업로드하면 서버에 데이터를 저장하지 않고 브라우저단에서 JSON 데이터를 추출하여 다운로드할 수 있게 한다. [2, 19, 20]
|
||||
3. **CLI 및 프로그래밍 도구:**
|
||||
- `exiftool -b -workflow input.png > workflow.json`: 바이너리 태그를 격리하여 저장하는 표준 CLI 방식이다. [8, 10]
|
||||
- `comfyui-extractor.py`: 대량의 디렉토리를 처리하며 프롬프트와 레이아웃을 분리하여 관리한다. [8, 20]
|
||||
- `ComfyUI-to-Python-Extension`: 워크플로우 메타데이터를 포함한 .py 스크립트를 생성하여 드래그 앤 드롭 재가져오기를 지원한다. [21]
|
||||
|
||||
**추출 시의 제한 사항**
|
||||
워크플로우 추출을 통해 그래프를 복원하더라도, 제작자가 사용한 '커스텀 노드'가 현재 시스템에 설치되어 있지 않으면 '빨간색 상자' 오류가 발생한다. [22-24] 이 경우 ComfyUI Manager의 "Install Missing Custom Nodes" 기능을 사용하여 의존성을 해결해야 한다. [23-25]
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **워크플로우 vs 프롬프트:** 소스에 따라 'Workflow' 파일은 모든 노드 위치와 상태를 포함하는 반면, 'Prompt' 파일은 실행에 필요한 노드 정보만을 포함한다고 정의되어 혼동을 피해야 한다. [6]
|
||||
- **업데이트 호환성:** ComfyUI는 빈번하게 업데이트되므로 구버전의 JSON 파일이 최신 버전에서 정상적으로 작동하지 않을 수 있다는 점이 명시되어 있다. [7]
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **comfy-cli (Issue #341):** `exiftool`을 사용하여 이미지 파일(PNG, WebP, MP4 등)에서 워크플로우를 추출, 삽입 및 복사하는 기능을 제안하고 구현 논의를 진행함. [9, 26]
|
||||
- **Weird Wonderful AI Art Extractor:** 온라인 PNG 파일 분석을 통해 사용자에게 JSON 워크플로우와 프롬프트 데이터를 추출해주는 웹 기반 도구로 실서비스 중임. [2, 19]
|
||||
- **ComfyUI Workflow Converter Endpoint:** 서버 측에서 비 API 형식을 API 형식으로 변환하여 실행 가능하도록 지원하며, 하위 그래프(Subgraph) 매핑 등의 복잡한 변환 로직을 포함함(V2.3.0 커밋 기준). [27-29]
|
||||
- **comfymeta:** 이미지를 처리하여 메타데이터를 추출하는 UI 도구로 분류됨. [10]
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
id: workflow-json-(frontend-format)
|
||||
title: "Workflow JSON (Frontend Format)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["workflow.json"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.90
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["workflow.json", "SethRobinson/comfyui-workflow-to-api-converter-endpoint/bc85382"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Workflow JSON (Frontend Format)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
사용자 인터페이스의 시각적 레이아웃 정보와 노드 그래프의 모든 논리적 연결성을 보존하여 인간 중심의 공유와 편집을 가능케 하는 ComfyUI의 기본 직렬화 규격이다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **시각적 메타데이터 보존 (Visual Metadata Persistence):** 노드의 좌표(`pos`), 크기(`size`), 그룹 구조, 색상 및 노드 접힘 상태(`flags`)와 같은 UI 전용 데이터를 포함한다 [2-5].
|
||||
- **명시적 링크 표현 (Explicit Link Representation):** 노드 입력부에 연결 정보를 내장하는 대신, 별도의 `links` 배열을 통해 시작점과 끝점 슬롯을 정의하는 명시적 연결 객체 형식을 사용한다 [2, 3, 6, 7].
|
||||
- **Litegraph 표준 준수 (Litegraph Standard):** 웹 기반 그래프 시각화 엔진인 Litegraph 형식을 따라 설계되어 브라우저 캔버스에서의 정확한 복원을 보장한다 [2, 7].
|
||||
- **미디어 임베딩 속성 (Media Embedding):** ComfyUI에서 생성된 PNG 또는 WebP 이미지의 메타데이터(tEXt 또는 zTXt 청크)에 직접 주입되어 생성 로직을 운반하는 컨테이너 역할을 수행한다 [8-10].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **직렬화 이원화 (Serialization Bifurcation):** ComfyUI는 시각적 편집용인 'Frontend 포맷'과 서버 실행 최적화용인 'API 포맷'으로 데이터를 분리하여 관리한다 [2].
|
||||
- **중복 데이터 전략 (Redundancy Strategy):** 생성된 이미지 메타데이터 내에 시각적 복원용 `workflow.json`과 실행용 `prompt` 데이터를 동시에 저장하여 상호 보완성을 확보한다 [9].
|
||||
- **역방향 그래프 탐색 (Execution Model Inversion):** 캔버스에 수많은 노드가 존재하더라도 실행 엔진은 출력 노드에서 시작해 필요한 의존성 노드만 역으로 추적하므로, Frontend JSON에 불필요한 노드가 포함되어도 실행 성능에 영향을 주지 않는다 [11].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
Frontend 포맷은 주로 `workflow.json`이라는 파일명으로 사용되며, ComfyUI 웹 인터페이스에서 사용자가 수행하는 'Visual Programming'의 결과를 저장하는 소스 코드와 같은 역할을 한다 [2, 12, 13].
|
||||
|
||||
### 1. 주요 데이터 구조 (Schema v1.0)
|
||||
- **Nodes Array:** 각 노드 객체는 고유 ID, 클래스 타입(`type`), 좌표, 크기, 위젯 값(`widgets_values`), 실행 순서(`order`), 모드(활성/바이패스 등)를 포함한다 [4, 5].
|
||||
- **Links Array:** 6개의 항목으로 구성된 배열 또는 구조화된 객체로, `origin_id`, `origin_slot`, `target_id`, `target_slot`을 정의하여 노드 간의 데이터 흐름을 명시한다 [6].
|
||||
|
||||
### 2. 생성 및 획득 방법
|
||||
- **GUI 수동 내보내기:** 제어 패널 메뉴의 'Export' 옵션 또는 단축키 `Ctrl + S`(macOS는 `Cmd + S`)를 사용하여 현재 캔버스의 상태를 JSON으로 다운로드할 수 있다 [12, 14].
|
||||
- **미디어 메타데이터 추출:**
|
||||
- **드래그 앤 드롭:** ComfyUI에서 생성된 PNG 이미지를 브라우저 캔버스에 직접 끌어다 놓으면 내장된 JSON을 통해 노드 배치가 복원된다 [14-16].
|
||||
- **CLI 도구 활용:** `exiftool -b -workflow input.png > workflow.json` 명령어를 통해 바이너리 태그에서 JSON 데이터를 분리해낼 수 있다 [17, 18].
|
||||
- **웹 도구:** Weird Wonderful AI Art의 'Workflow Extractor'와 같은 브라우저 기반 도구를 통해 온라인 이미지에서 데이터를 추출할 수 있다 [19, 20].
|
||||
|
||||
### 3. API 포맷과의 차별점
|
||||
Frontend 포맷은 인간이 읽기 쉽고 UI를 완벽히 재구성할 수 있도록 설계되었으나, `/prompt` 엔드포인트에 직접 전달할 경우 오류가 발생할 수 있다 [21]. API 호출을 위해서는 UI 메타데이터가 제거되고 노드 간 연결이 입력 필드에 직접 참조된 'API JSON' 형식이 필요하며, 이는 설정에서 'Dev mode'를 활성화해야만 생성 가능하다 [2, 3, 13, 22].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **포맷 호환성 이슈:** ComfyUI는 업데이트가 매우 빈번하여, 구버전에서 생성된 Frontend JSON 파일이 신버전에서 올바르게 작동하지 않거나 노드가 빨간색 박스로 표시되는(Missing Custom Nodes) 현상이 발생할 수 있다 [14, 23].
|
||||
- **데이터 휘발성:** 이미지 편집기(GIMP 등)로 처리하거나 소셜 미디어 플랫폼에 업로드할 경우, 파일 크기 최적화 과정에서 비표준 메타데이터인 Frontend JSON 정보가 삭제되어 워크플로우 복원이 불가능해지는 경우가 많다 [9, 24].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **SethRobinson/comfyui-workflow-to-api-converter-endpoint:** 클라이언트 측의 자바스크립트 변환 로직을 서버 측 파이썬으로 구현하여, `workflow.json`만으로 API 호출이 가능하도록 변환하는 기능을 제공한다 [21, 25].
|
||||
- **ComfyUI-to-Python-Extension:** Frontend JSON 메타데이터를 포함한 파이썬 스크립트를 생성하여, 실행 후 저장된 결과물을 다시 ComfyUI UI로 드래그 앤 드롭하여 복원할 수 있도록 지원한다 [26].
|
||||
- **기본 저장 규칙:** ComfyUI의 `Save Image` 노드는 실행 시 최종 이미지에 전체 노드 그래프와 설정을 주입하며, 이는 `workflow.json` 규격을 따른다 [16].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
id: workflow-json---comfyui
|
||||
title: "Workflow JSON - ComfyUI"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["ComfyUI 워크플로우 JSON", "workflow_api.json", "workflow.json"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfyui-workflow-to-api-converter-endpoint/README.md", "pydn/ComfyUI-to-Python-Extension", "DanielPFlorian/ComfyUI-WorkflowGenerator", "deimos-deimos/comfy_api_simplified"]
|
||||
github_commit: "bc85382"
|
||||
---
|
||||
|
||||
# [[Workflow JSON - ComfyUI]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
ComfyUI Workflow JSON은 복잡한 노드 기반 생성 프로세스를 유향 비순환 그래프(DAG) 형태로 직렬화한 청사진으로, 시각적 편집을 위한 **프론트엔드 포맷**과 무두(Headless) 실행 및 자동화를 위한 **API 포맷**으로 이원화되어 관리된다 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **프론트엔드 포맷 (workflow.json):** 시각적 편집과 사용자 상호작용을 위해 설계된 포맷으로, 노드의 좌표(`pos`), 크기(`size`), 그룹 구조 및 색상과 같은 UI 메타데이터를 모두 포함한다 [2-4].
|
||||
- **API 포맷 (workflow_api.json):** 백엔드 실행 엔진 최적화를 위해 UI 관련 메타데이터를 제거한 스트림라인드 포맷으로, 노드 입력부 내에 연결 정보가 직접 삽입되는 구조를 가진다 [2, 5, 6].
|
||||
- **메타데이터 임베딩 (Metadata Embedding):** 생성된 PNG/WebP 파일의 `tEXt` 또는 `zTXt` 청크에 JSON 데이터를 주입하여 이미지 자체가 실행 로직을 포함하는 컨테이너 역할을 수행하게 한다 [7, 8].
|
||||
- **JSON 스키마 v1.0:** 유효한 워크플로우를 보장하기 위한 기술적 제약 조건으로, 고유 ID, 클래스 타입, 위젯 값 등의 속성을 정의한다 [9-11].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **이원화 저장 패턴:** 사용자는 UI에서 수정한 내용을 `Save`로 저장(프론트엔드)하고, 외부 연동을 위해 `Dev Mode`를 활성화하여 `Save (API Format)`으로 내보낸다 [12-15].
|
||||
- **역방향 그래프 탐색 (Execution Model Inversion):** 백엔드 엔진이 출력 노드(Save Image 등)로부터 역방향으로 의존성을 추적하여 실제 실행에 필요한 노드만 식별하고 나머지는 무시하는 최적화 패턴을 사용한다 [16].
|
||||
- **입력값 교체 패턴 (Prompt Injection):** Python 등 프로그래밍 환경에서 템플릿 JSON을 로드한 후, 특정 노드 ID의 `inputs` 딕셔너리를 직접 수정하여 시드(seed)나 프롬프트를 동적으로 변경한다 [17-19].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
### 1. 생성 및 추출 방법론
|
||||
- **GUI 기반 생성:** 기본 인터페이스의 컨트롤 패널에서 `Ctrl + S`를 통해 프론트엔드 JSON을 저장할 수 있다 [12]. API 포맷을 생성하려면 설정 메뉴에서 'Enable Dev mode Options'를 활성화해야 한다 [13, 14, 20].
|
||||
- **이미지 메타데이터 추출:** ComfyUI에서 생성된 이미지를 캔버스에 드래그 앤 드롭하거나 [21-23], `ExifTool`을 사용하여 `exiftool -b -workflow input.png > workflow.json` 명령어로 바이너리 데이터를 추출할 수 있다 [24, 25].
|
||||
- **자동화 도구:** `comfyui-workflow-to-api-converter-endpoint`와 같은 커스텀 노드는 서버 측에서 프론트엔드 형식을 API 형식으로 실시간 변환하는 엔드포인트를 제공한다 [26-28].
|
||||
|
||||
### 2. 프로그래밍적 제어 및 변환
|
||||
- **Python 통합:** 워크플로우 JSON은 중첩된 딕셔너리 구조이므로 Python의 `json` 라이브러리로 쉽게 조작 가능하다 [17]. `ComfyUI-to-Python-Extension`은 JSON을 아예 독립적인 실행 파일(.py)로 변환해주기도 한다 [29-31].
|
||||
- **LLM 기반 생성:** `ComfyUI-WorkflowGenerator`는 자연어 설명을 입력받아 LLM(Qwen2.5 등)이 논리 구조를 합성하고, 유효성 검사(Validator)를 거쳐 최종 JSON을 빌드하는 3단계 파이프라인을 사용한다 [32-35].
|
||||
|
||||
### 3. 데이터 구조 분석 (v1.0 기준)
|
||||
- **노드 객체 속성:** 각 노드는 고유 `id`, 노드 클래스 매핑을 위한 `type`, 실행 순서를 결정하는 `order`, 그리고 사용자 입력값인 `widgets_values`를 보유한다 [4, 9].
|
||||
- **연결 구조:** 프론트엔드에서는 별도의 `links` 배열을 통해 연결을 정의하지만, API 포맷에서는 노드의 `inputs` 내부에 `[origin_id, output_slot_index]` 형태의 참조를 직접 기록한다 [2, 3, 36, 37].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **버전 호환성:** ComfyUI가 빈번하게 업데이트됨에 따라 구버전 JSON 파일이 최신 UI에서 정상적으로 작동하지 않을 수 있다는 경고가 존재한다 [38].
|
||||
- **메타데이터 손실:** 소셜 미디어 플랫폼이나 이미지 압축 소프트웨어는 종종 이미지 내의 JSON 메타데이터 청크를 삭제하여 워크플로우 정보를 소실시킨다 [8, 38].
|
||||
- **API 포맷의 비가역성:** API 포맷으로 내보낸 JSON을 다시 UI로 불러올 경우 시각적 레이아웃 정보(좌표, 그룹 등)가 유실되어 편집이 매우 어려워진다 [26, 39].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **comfyui-workflow-to-api-converter-endpoint (SethRobinson):** `/workflow/convert` 엔드포인트를 통해 비 API 워크플로우를 API 포맷으로 서버사이드 변환 수행. **commit `bc85382`**에서 콤보 위젯 대소문자 정규화 로직 적용 [40-42].
|
||||
- **ComfyUI-WorkflowGenerator (DanielPFlorian):** LLM을 활용하여 자연어 지시문을 워크플로우 JSON으로 변환하는 파이프라인 구현. **commit `82df278`**에서 드롭다운 중복 모델 문제 해결 [34, 43, 44].
|
||||
- **ComfyUI-to-Python-Extension (pydn):** JSON 워크플로우를 실행 가능한 Python 코드로 번역. **commit `6cdcc23`**에서 설치 문제 해결 및 README 업데이트 [30, 31, 45].
|
||||
- **comfy_api_simplified:** 노드 제목(title)을 기반으로 파라미터를 설정하여 숫자 ID에 의존하지 않는 안정적인 API 제어 방식 구현 [29, 46, 47].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 발견으로 검증 수준 높음)
|
||||
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
id: workflow.api.json-(backend-format)
|
||||
title: "Workflow.api.json (Backend Format)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: ["API Format", "Backend JSON", "workflow_api.json"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["Mystic Pipeline", "Replicate (fofr/any-comfyui-workflow)", "ComfyUI-to-Python-Extension", "comfyui-workflow-to-api-converter-endpoint"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Workflow.api.json (Backend Format)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
비주얼 메타데이터를 배제하고 노드 실행 로직에만 집중하여 서버측 자동화와 프로그래밍적 실행을 가능케 하는 최적화된 데이터 포맷 [1-3].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
- **실행 그래프 (Execution Graph):** UI 관련 데이터(좌표, 크기, 그룹 등)를 제거하고 백엔드 엔진이 프롬프트를 실행하는 데 필요한 필수 로직만 남긴 스트림라인화된 구조 [1, 4].
|
||||
- **임베디드 참조 (Embedded References):** 링크 정보가 별도의 객체가 아니라 노드 입력(inputs) 필드 내에 소스 노드 ID와 출력 슬롯 인덱스의 리스트(예: `[node_id, slot_index]`) 형태로 직접 포함됨 [1, 2, 5].
|
||||
- **딕셔너리 구조 (Dictionary Mapping):** 노드 ID를 최상위 키로 사용하며, 각 값은 `class_type`과 `inputs`를 포함하는 객체로 구성된 단일 JSON 객체 형식 [6, 7].
|
||||
- **개발자 모드 의존성 (Developer Mode Dependency):** 표준 웹 UI에서는 숨겨져 있으며, 설정에서 'Enable Dev mode Options'를 활성화해야만 'Save (API Format)' 메뉴가 노출됨 [8-11].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **UI 데이터 스트리핑 (UI Data Stripping):** 캔버스 레이아웃 정보를 삭제함으로써 파일 크기를 축소하고 API 호출의 효율성을 극대화하는 설계 패턴 [1, 2, 4].
|
||||
- **노드 ID 키잉 (Node ID Keying):** 숫자 문자열(예: "5", "37")을 키로 사용하여 유연한 그래프 트래버스 및 특정 노드 파라미터의 동적 오버라이드를 지원 [6, 7, 12].
|
||||
- **입력값 치환 (Input Value Substitution):** Python 등의 언어에서 JSON을 로드한 후 특정 노드 ID의 `inputs` 필드를 직접 수정하여 시드, 프롬프트, 이미지 경로 등을 변경하는 방식의 자동화 패턴 [6, 12, 13].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
**형식적 특성 및 구조**
|
||||
Workflow API JSON은 Litegraph 표준을 따르는 프런트엔드 형식(`workflow.json`)과 달리 ComfyUI 백엔드의 `/prompt` 엔드포인트와 직접 통신하기 위해 설계되었습니다 [1, 2]. 파일 내부의 각 항목은 고유한 노드 식별자를 키로 하며, 해당 노드가 어떤 클래스(`class_type`)인지와 어떤 입력값(`inputs`)을 사용하는지를 명시합니다 [4, 7]. 이때 입력값에는 위젯의 직접적인 값뿐만 아니라 다른 노드로부터 오는 연결 정보도 포함됩니다 [5].
|
||||
|
||||
**생성 및 추출 방법**
|
||||
- **GUI 내보내기:** ComfyUI 설정 메뉴(톱니바퀴 아이콘)에서 'Enable Dev mode Options'를 체크한 후 사이드바 메뉴에 나타나는 'Save (API Format)' 버튼을 클릭하여 생성합니다 [8-11].
|
||||
- **이미지 메타데이터:** ComfyUI가 생성한 PNG 파일의 `tEXt` 또는 `zTXt` 청크에는 프런트엔드 워크플로우와 함께 'prompt'라는 이름으로 API 포맷의 JSON이 포함되어 자동 저장됩니다 [14, 15].
|
||||
- **서버측 변환:** `comfyui-workflow-to-api-converter-endpoint`와 같은 커스텀 노드를 사용하면 클라이언트 측의 자바스크립트 로직 없이도 서버에서 직접 일반 JSON을 API 포맷으로 변환할 수 있습니다 [16, 17].
|
||||
|
||||
**활용 시나리오**
|
||||
이 포맷은 주로 외부 애플리케이션 통합에 사용됩니다. 예를 들어 Python 스크립트에서 워크플로우 템플릿을 로드하고 특정 노드의 텍스트 입력을 변경한 후 ComfyUI 서버에 큐잉하거나, Replicate와 같은 클라우드 환경에서 워크플로우를 실행하는 데 필수적입니다 [6, 12, 18, 19].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **가독성 vs 효율성:** API 포맷은 파일 크기가 작고 처리가 빠르지만, UI로 다시 드래그 앤 드롭했을 때 시각적 구조(노드 위치, 그룹화 등)가 복원되지 않는 "뼈대만 남은(skeleton)" 상태가 됩니다 [1, 20].
|
||||
- **노드 ID의 취약성:** 워크플로우를 UI에서 편집하면 노드 ID가 변경될 수 있으며, 이로 인해 특정 ID를 하드코딩한 자동화 스크립트가 깨질 위험이 존재합니다 [6, 21]. 이를 해결하기 위해 노드 타이틀 기반 접근 방식이 대안으로 제시되기도 합니다 [21, 22].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **Mystic Deployment:** `pipeline.yaml`과 함께 `new_pipeline.py`에서 API JSON을 로드하여 입력 프롬프트를 주입하고 서버를 실행하는 구조로 적용됨 [23, 24].
|
||||
- **Replicate API:** `fofr/any-comfyui-workflow` 모델을 통해 API JSON 블롭을 전달받아 이미지를 생성하는 상용 서비스에 적용 [18, 25].
|
||||
- **ComfyUI-to-Python-Extension:** `workflow_api.json` 파일을 입력받아 독립 실행 가능한 `.py` 스크립트로 변환하는 CLI 도구에서 핵심 데이터로 사용됨 [26, 27].
|
||||
- **Workflow Converter:** 서버측 `/workflow/convert` 엔드포인트를 통해 비 API 워크플로우를 API 포맷으로 실시간 변환하여 Unity 기반 AI 도구 등에서 활용 [16, 17].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (실제 적용 사례 다수 확인됨)
|
||||
- **출처 신뢰도:** B (Official Documentation / RunComfy & Replicate API Docs / GitHub Repository READMEs)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
id: workspace-packaging-(.cpack.zip)
|
||||
title: "Workspace Packaging (.cpack.zip)"
|
||||
category: "10_Wiki/Topics"
|
||||
status: "draft"
|
||||
verification_status: "conceptual"
|
||||
canonical_id: ""
|
||||
aliases: []
|
||||
duplicate_of: ""
|
||||
source_trust_level: "B"
|
||||
confidence_score: 0.85
|
||||
created_at: 2026-05-20
|
||||
updated_at: 2026-05-20
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: ["research", "Comfyui workflow json 생성 방법"]
|
||||
raw_sources: ["NotebookLM Synthesis"]
|
||||
applied_in: ["comfy-pack"]
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[Workspace Packaging (.cpack.zip)]]
|
||||
|
||||
## 🎯 한 줄 통찰 (One-line insight)
|
||||
워크플로 JSON, 모델 해시, 커스텀 노드 버전을 단일 아카이브로 통합하여 환경 변화에 무관한 완벽한 실행 재현성을 보장하는 표준화된 배포 아티팩트 규격이다 [1].
|
||||
|
||||
## 🧠 핵심 개념 (Core concepts)
|
||||
1. **표준화된 아티팩트 배포:** 단순한 JSON 파일에 대한 의존성을 넘어, 실행에 필요한 모든 메타데이터를 포함하는 아티팩트 기반 배포 방식이다 [1].
|
||||
2. **패키지 구성 요소:** .cpack.zip 파일 내에는 워크플로 JSON, 모델의 SHA-256 해시값, 그리고 실행에 필요한 커스텀 노드의 특정 버전 정보가 포함된다 [1].
|
||||
3. **모델 해싱(SHA-256):** 모델 파일명에 의존하는 대신 해시값을 사용하여 서로 다른 시스템 환경에서도 정확한 모델을 식별하고 로드한다 [2].
|
||||
4. **미래 지향적 유지보수:** 특정 노드가 업데이트되거나 삭제되더라도 패키지 내 기록된 버전을 통해 생성 시점과 동일한 워크플로 기능을 유지한다 [1].
|
||||
|
||||
## 🧩 추출된 패턴 (Extracted patterns)
|
||||
- **논리 및 의존성의 완전 캡슐화:** 워크플로의 실행 논리(JSON)와 그 실행을 뒷받침하는 의존성(모델, 노드)을 하나의 단위로 묶어 관리하는 패턴이다 [1, 3].
|
||||
- **파일 이름에서 내용 기반 식별로의 전환:** 경로 정보나 파일명이 아닌 데이터 고유의 해시값을 통해 리소스를 관리하여 이식성을 극대화한다 [2].
|
||||
|
||||
## 📖 세부 내용 (Details)
|
||||
ComfyUI 워크플로 생성의 미래는 원본 JSON 파일만 공유하던 방식에서 벗어나 표준화된 **아티팩트 기반 배포(Artifact-based deployments)**로 이동하고 있다 [1]. 기존의 JSON 방식은 다른 사용자의 환경에서 모델 파일명이 다르거나 커스텀 노드 버전이 일치하지 않을 때 실행이 실패하는 고질적인 문제를 안고 있었다 [1, 2].
|
||||
|
||||
Workspace Packaging 규격인 **.cpack.zip**은 이러한 문제를 해결하기 위해 고안되었다 [1]. 이 아카이브 파일은 단순한 압축 파일이 아니라, 워크플로의 실행 환경을 정의하는 고밀도 정보를 담고 있다 [1]. 구체적으로, 생성 시점에 사용된 워크플로 JSON과 함께, 각 모델의 **SHA-256 해시값**을 기록하여 파일명이 다르더라도 로컬 시스템에서 동일한 모델을 찾아낼 수 있게 한다 [2]. 또한, 실행에 필요한 커스텀 노드들의 **특정 버전 정보**까지 포함하여, 시간이 지나 노드가 업데이트되거나 더 이상 지원되지 않더라도 생성 당시의 기능을 보존한다 [1].
|
||||
|
||||
이러한 방식은 ComfyUI를 전문적인 제작 파이프라인에 통합하는 데 필수적이며, 오디오, 비디오, 3D 및 AI 에이전트가 결합되는 복잡한 시스템 간의 통신에서 공통 언어 역할을 수행한다 [3].
|
||||
|
||||
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
||||
- **JSON의 한계 극복:** 소스에 따르면 현재의 워크플로 생성 방식은 원시 JSON에 의존하고 있으나, 이는 이식성 면에서 취약하며 점차 .cpack.zip과 같은 워크스페이스 패키징 방식으로 보완 또는 대체되는 추세이다 [1].
|
||||
- **최신 정보:** 소스 데이터 작성 시점 기준으로 .cpack.zip은 "Future Outlook"으로 언급되며 차세대 표준으로 제시되고 있다 [1].
|
||||
|
||||
## 🛠️ 적용 사례 (Applied in summary)
|
||||
- **comfy-pack:** 모델의 파일명 대신 SHA-256 해시를 사용하여 정확한 모델 위치를 식별하고 관리하는 고급 직렬화 도구로 언급된다 [2].
|
||||
|
||||
## ✅ 검증 상태 및 신뢰도
|
||||
- **상태:** draft
|
||||
- **검증 단계:** conceptual (comfy-pack 등 실제 도구에서 해시 기반 관리 방식이 이미 적용되어 있음 [2])
|
||||
- **출처 신뢰도:** B (Comprehensive Architectures for ComfyUI Workflow JSON Generation and Serialization 문서 기반)
|
||||
- **중복 검사 결과:** 신규 생성 (New discovery)
|
||||
|
||||
## 📝 변경 이력 (Change history)
|
||||
- 2026-05-20: Initial draft generated via Datacollector_MAC P-Reinforce engine.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user