Introducing Daggr: Chain apps programmatically, inspect visually

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Daggr는 Gradio 앱, 추론 모델, 파이썬 함수를 코드로 연결하면서 각 단계의 입출력과 상태를 시각적으로 점검하고 개별 재실행할 수 있게 해주는 오픈소스 AI 워크플로 라이브러리다.

📌 핵심 요약

• Daggr는 복잡한 AI 파이프라인을 파이썬 코드로 정의하면 연결 구조와 중간 결과를 확인할 수 있는 시각적 캔버스를 자동으로 생성한다.
• 사용자는 문제가 발생한 노드의 입력을 수정하고 해당 단계만 다시 실행할 수 있으며, 워크플로 상태와 캐시 결과, 캔버스 위치도 이어서 사용할 수 있다.
• GradioNode, FnNode, InferenceNode를 통해 Gradio Space, 사용자 정의 파이썬 함수, Hugging Face Inference Providers 모델을 하나의 그래프에서 연결한다.
• 간단한 예제는 이미지 생성과 배경 제거를 연결하고, 종단 간 예제는 배경 제거·이미지 축소·3차원 스타일 변환·3차원 자산 생성을 순차적으로 구성한다.
• Daggr는 공유 링크와 Hugging Face Spaces 배포를 지원하지만 아직 베타이므로 버전 간 API 변경과 업데이트 중 로컬 상태 손실 가능성을 고려해야 한다.

🧩 주요 포인트

1. Daggr는 복잡한 AI 파이프라인을 파이썬 코드로 정의하면 연결 구조와 중간 결과를 확인할 수 있는 시각적 캔버스를 자동으로 생성한다.
2. 사용자는 문제가 발생한 노드의 입력을 수정하고 해당 단계만 다시 실행할 수 있으며, 워크플로 상태와 캐시 결과, 캔버스 위치도 이어서 사용할 수 있다.
3. GradioNode, FnNode, InferenceNode를 통해 Gradio Space, 사용자 정의 파이썬 함수, Hugging Face Inference Providers 모델을 하나의 그래프에서 연결한다.
4. 간단한 예제는 이미지 생성과 배경 제거를 연결하고, 종단 간 예제는 배경 제거·이미지 축소·3차원 스타일 변환·3차원 자산 생성을 순차적으로 구성한다.
5. Daggr는 공유 링크와 Hugging Face Spaces 배포를 지원하지만 아직 베타이므로 버전 간 API 변경과 업데이트 중 로컬 상태 손실 가능성을 고려해야 한다.

🧠 상세 정리

1. 복합 AI 워크플로가 겪는 문제

여러 모델과 처리 단계를 결합한 AI 애플리케이션에서는 API 호출을 순서대로 연결하고, 각 단계의 결과를 추적하며, 오류가 발생한 지점을 찾는 일이 번거롭다. 특히 열 단계로 구성된 워크플로의 다섯 번째나 일곱 번째 단계가 잘못되었을 때 기존 스크립트 방식은 원인을 확인하기 위해 전체 과정을 다시 실행하게 만들기 쉽다. 단순한 스크립트는 빠르게 작성할 수 있지만 구조가 취약하고 중간 결과를 관찰하기 어려우며, 반대로 운영 환경용 오케스트레이션 플랫폼은 빠른 실험에 사용하기에는 무거울 수 있다. Daggr는 이 간극을 메우기 위해 코드의 재현성과 시각적 도구의 관찰 가능성을 함께 제공하는 가벼운 워크플로 라이브러리로 소개된다.

2. 코드 우선 설계와 시각적 캔버스

Daggr의 핵심은 화면에서 노드를 끌어다 연결하는 방식이 아니라, 워크플로를 파이썬 코드로 먼저 정의하는 데 있다. 개발자가 노드와 입출력 관계를 코드로 작성하면 Daggr가 그 구조를 시각적 캔버스로 자동 변환하므로, 소스 코드를 버전 관리하면서도 실행 흐름과 중간 결과를 눈으로 살펴볼 수 있다. 생성된 캔버스는 단순한 다이어그램이 아니라 각 노드의 출력 확인, 입력값 수정, 특정 단계의 개별 재실행을 지원하는 실행 인터페이스다. 한 모델이나 Space가 제대로 작동하지 않을 때 다른 구현으로 대체하는 백업 노드도 제공할 수 있어, 실험적인 파이프라인에 복원력을 더할 수 있다. 이 설계는 코드와 시각 편집기 중 하나를 선택하는 대신 두 방식의 장점을 결합하려는 접근이다.

3. 설치와 첫 번째 연결 예제

Daggr는 파이썬 3.10 이상에서 pip 또는 uv로 설치할 수 있으며, 첫 예제는 이미지 생성과 배경 제거를 두 개의 GradioNode로 연결한다. 첫 번째 노드는 Z-Image-Turbo Space의 이미지 생성 API를 호출하고, 프롬프트·높이·너비·시드 값을 입력으로 받아 생성 이미지를 출력한다. 두 번째 노드는 background-removal Space를 호출하면서 첫 번째 노드의 이미지 출력을 자신의 입력으로 직접 참조하고, 원본 이미지는 숨긴 채 배경이 제거된 최종 이미지만 노출한다. 두 노드를 Graph에 등록하고 실행하면 기본 포트 7860에서 시각적 캔버스가 열리며, 사용자는 각 노드의 입력과 출력을 확인할 수 있다. 외부 공유가 필요할 때는 실행 옵션을 통해 공개 링크를 생성할 수 있다.

4. 세 가지 노드 유형과 역할

Daggr는 서로 다른 실행 대상을 하나의 그래프에 넣을 수 있도록 GradioNode, FnNode, InferenceNode라는 세 가지 노드 유형을 제공한다. GradioNode는 공개 또는 비공개 Gradio Space의 API 엔드포인트나 로컬에서 실행되는 Gradio 앱을 호출하며, 별도의 어댑터나 래퍼 없이 Space 이름과 API 경로를 지정해 사용할 수 있다. 로컬 실행 옵션을 켜면 Daggr가 해당 Space를 복제하고 격리된 가상환경을 만든 뒤 앱을 실행하며, 로컬 실행에 실패하면 원격 API로 전환한다. FnNode는 문자열 변환이나 이미지 축소처럼 개발자가 작성한 일반 파이썬 함수를 워크플로 단계로 감싼다. InferenceNode는 Hugging Face Inference Providers를 통해 지정한 모델을 호출하므로, 외부 앱·로컬 함수·모델 추론을 동일한 입출력 연결 방식으로 조합할 수 있다.

5. 상태 유지와 워크플로 공유

Daggr는 워크플로 구조만 보여주는 것이 아니라 입력값, 캐시된 실행 결과, 현재 상태와 캔버스 위치를 자동으로 저장한다. 사용자는 작업을 중단한 뒤 이전 상태에서 다시 시작할 수 있고, 시트 기능을 이용해 하나의 앱 안에서 여러 작업 공간을 관리할 수 있다. 중간 결과가 보존되기 때문에 문제가 없는 앞부분까지 반복 실행하지 않고 필요한 노드만 고쳐서 다시 실행하는 디버깅 흐름이 가능하다. 임시 공유가 필요하면 Gradio 터널링을 사용하는 공유 실행 옵션으로 공개 URL을 만들 수 있다. 영구적으로 제공하려면 Gradio SDK 기반의 Hugging Face Space에 배포하고 요구 사항 파일에 daggr를 추가하면 된다.

6. 이미지를 3차원 자산으로 바꾸는 전반부

종단 간 예제는 입력 이미지에서 배경을 제거하고, 처리 효율을 위해 이미지를 축소한 뒤, 3차원 자산에 적합한 모습으로 변환하고, 마지막으로 3차원 결과물을 생성하는 네 단계로 구성된다. 첫 단계에서는 BiRefNet 계열의 배경 제거 Space를 복제해 로컬에서 실행하며, 제시된 CPU용 Space는 처리에 약 13초가 걸린다고 설명한다. 두 번째 단계는 Pillow로 이미지를 읽고 지정된 비율로 너비와 높이를 줄인 다음, Daggr의 파일 디렉터리에 새로운 PNG 파일로 저장하는 사용자 정의 함수를 사용한다. 축소 비율은 최소 0.25에서 최대 0.75 사이의 슬라이더로 조절하며 기본값은 0.25다. 이 함수는 FnNode로 등록되고 배경 제거 노드의 최종 이미지를 입력받아, 다음 추론 단계에서 사용할 파일 경로 형태의 축소 이미지를 출력한다.

7. 이미지 보정과 3차원 생성 연결

세 번째 단계에서는 InferenceNode가 FLUX.2-klein-4B 모델을 호출해 축소된 이미지를 깨끗한 3차원 자산 렌더링 형태로 변환한다. 이 노드는 이전 FnNode의 이미지 출력과 변환 지시문을 입력으로 받고, 3차원 생성에 사용할 보정 이미지를 출력한다. 마지막 GradioNode는 이 결과를 Microsoft의 TRELLIS.2 Space에 전달하며, 안내 강도와 샘플링 단계 값을 지정해 GLB 형식의 3차원 자산 미리보기를 만든다. 네 노드를 순서대로 Graph에 등록하면 배경 제거부터 3차원 생성까지의 전체 흐름이 하나의 실행 가능한 캔버스로 구성된다. InferenceNode를 Hugging Face Spaces에 배포할 때는 Inference Providers 호출 권한만 부여한 세분화된 접근 토큰을 사용하라고 안내한다.

8. 로컬 실행의 제약과 베타 단계

로컬로 실행하는 Space는 내부 구현에서 모델을 CUDA나 ZeroGPU로 이동하도록 작성되어 있을 수 있으므로, 엔비디아 GPU가 없는 장치에서는 그대로 실행되지 않을 수 있다. 글은 CPU 실행이 필요할 경우 대상 Space를 복제한 뒤 해당 동작을 조정하고 로컬로 복제해 사용할 수 있다고 설명한다. Daggr 자체는 의도적으로 가볍게 만든 베타 소프트웨어이므로 버전이 바뀌면서 API가 변경될 수 있고, 상태를 로컬에 저장하더라도 업데이트 과정에서 데이터가 손실될 가능성이 있다. 조건에 따라 다음 노드를 선택하는 기능에 관한 질문에는 결정성을 유지하면서 프로그램 방식의 검사와 API 사용을 지원할 설계를 검토하고 있다는 답변이 제시됐지만, 현재 지원 기능으로 확정되지는 않았다. 오류와 기능 요청은 프로젝트 저장소에 등록하도록 안내하며, 사용자가 만든 워크플로를 공유해 달라고 요청한다.

🧾 핵심 주장 / 시사점

• Daggr의 차별점은 워크플로 작성 수단을 시각 편집기로 대체하는 것이 아니라, 파이썬 코드를 기준으로 삼으면서 실행 상태와 중간 결과를 시각화한다는 데 있다.
• 노드별 입력 수정과 개별 재실행, 캐시된 결과의 보존은 여러 추론 단계를 반복하는 실험에서 전체 파이프라인 재실행을 줄이고 오류 지점을 구체적으로 확인하게 해준다.
• Gradio Space·파이썬 함수·추론 모델을 같은 그래프에서 연결할 수 있지만, 베타 단계의 API 변경과 상태 손실 가능성, 로컬 Space의 하드웨어 의존성은 실제 도입 전에 확인해야 할 제약이다.

✅ 액션 아이템

• Daggr의 GradioNode·FnNode·InferenceNode를 조합해 Gradio 앱·파이썬 함수·추론 모델의 연결 파이프라인을 코드로 정형화한다.
• 문제가 발생한 노드 입력을 수정해 해당 단계만 재실행하고, 워크플로 상태·캐시·캔버스 위치의 연속성을 점검한다.
• 이미지 생성·배경 제거·축소·3차원 스타일 변환·자산 생성 경로를 이어 구성해 중간 산출물의 흐름을 단계별로 추적한다.

❓ 열린 질문

• 베타 배포 상태에서 API 변경이 발생하면 Daggr 노드 호환성은 어떤 지표로 판단할 것인가?
• 공유 링크와 Hugging Face Spaces 배포에서 로컬 상태 손실을 줄이려면 상태 동기화 기준은 어디까지 두어야 할까?
• 문제가 난 노드를 재실행할 때 캐시 결과와 워크플로 상태를 신뢰할 임계 기준은 어떤 방식으로 정의할 수 있는가?