AI 기능을 붙인 작은 도구는 대개 한 번의 모델 호출로 끝나지 않는다. 입력을 정리하고, 모델에 넘기고, 결과를 다른 서비스나 함수로 보내며, 마지막에 사람이 확인할 값을 만든다. 처음에는 Python 함수 몇 개와 로그만으로도 충분하다. 다만 결과가 이상해졌을 때는 이야기가 달라진다. 어느 단계가 잘못된 값을 만들었는지, 같은 입력을 다시 넣으면 어느 지점부터 달라지는지 찾는 일이 기능을 만드는 시간보다 길어지기 쉽다.
8월 25일 Hugging Face는 Gradio에 내장되는 gr.Workflow를 소개했다. 입력, 처리 단계, 출력을 타입이 붙은 노드와 선으로 표현하고, 각 노드를 실행하면서 중간 결과를 캔버스에서 볼 수 있게 하는 기능이다. 모델과 Hugging Face Spaces, 데이터셋, 직접 작성한 Python 함수를 한 그래프 안에서 연결할 수 있다. 그래프는 REST API로도 노출되고 Hugging Face Spaces에 배포할 수도 있다.
이번 소식에서 눈여겨볼 부분은 ‘드래그 앤드 드롭으로 AI 앱을 만든다’는 표현보다 파이프라인을 관찰 가능한 단위로 바꾼다는 점이다. AX를 작은 실험으로 시작할 때 필요한 것은 복잡한 오케스트레이터가 아니라, 자동화가 어떤 입력을 받아 어디까지 처리했고 어느 결과를 사람이 봐야 하는지 드러내는 구조일 때가 많다.
보이는 그래프가 해결하는 문제는 코딩 속도만이 아니다
문서에 따르면 Workflow는 세 종류의 노드로 구성된다. reference는 텍스트나 파일 같은 입력, operator는 모델·Space·데이터셋·Python 함수처럼 실제 일을 하는 단계, subject는 최종 출력이다. 포트에는 텍스트, 숫자, 이미지, JSON 같은 타입이 붙어 연결의 호환성을 확인한다.
이 구분은 실무에서 의외로 유용하다. 예를 들어 회의 메모를 정리하는 자동화가 있다고 하자. 메모 정리 함수, LLM 요약, 검토용 체크리스트 생성, Notion 저장 후보 생성이 한 줄의 코드에 섞여 있으면 실패 원인을 분리하기 어렵다. 반대로 각 단계를 노드로 나누면 ‘원문 정리는 정상인데 요약이 근거를 빠뜨렸는지’, ‘요약은 맞지만 저장 전 형식 검사가 실패했는지’를 같은 입력으로 확인할 수 있다.
중간 결과가 보인다고 해서 결과가 자동으로 신뢰할 만해지는 것은 아니다. 그래도 검토할 위치를 숨기지 않는다는 이점은 있다. 특히 모델 출력 뒤에 외부 API 호출이나 파일 저장 같은 부작용이 이어지는 흐름이라면, 생성 단계와 실행 단계를 분리해 두는 것만으로도 사람이 멈춰 볼 지점이 생긴다.
그림으로 만든 흐름도 결국 파일과 API가 된다
Workflow를 단순한 시연 화면으로만 볼 필요는 없다. 편집한 그래프는 workflow.json으로 저장된다. Python에서 graph= 경로를 지정해 기존 토폴로지를 불러올 수 있고, 직접 작성한 함수는 bind=로 노드에 연결한다. 고정된 구조가 필요한 초기 그래프라면 코드에서 함수 간 edge를 선언할 수도 있다.
이 방식은 실험과 운영 사이의 간격을 줄인다. 캔버스에서 입력과 출력을 연결해 본 뒤, 그래프 파일을 Git에서 코드와 같이 검토하는 흐름을 생각해 볼 수 있다. 다만 그래프 파일이 있다고 해서 실행 환경까지 재현되는 것은 아니다. 모델 ID, 외부 Space의 동작, 접근 토큰, 데이터셋의 상태는 별도로 관리해야 한다. 그래프는 작업 순서를 설명하지만, 의존성의 버전과 권한까지 대신 기록해 주지는 않는다.
또한 로컬에서 실행할 때 편집 권한이 있는 URL은 비공개로 다뤄야 한다. Gradio 문서는 이 URL에서 한 변경이 해당 Workflow를 보는 모든 방문자에게 영향을 줄 수 있다고 안내한다. Spaces에 배포할 때도 OAuth를 켜지 않으면 소유자를 식별할 수 없어 실행 전용 상태가 된다. 빠르게 공유하기 전에는 누가 그래프를 편집할 수 있는지부터 정하는 편이 낫다.
병렬 실행과 API 호출은 같은 동작이 아니다
그래프 모양만 보고 성능을 추정하면 놓치는 부분도 있다. 공식 가이드에 따르면 인터랙티브 캔버스에서는 같은 의존 깊이에 있는 분기 노드가 병렬로 실행된다. 반면 생성된 Gradio API로 같은 Workflow를 호출하면 현재는 그 분기를 순차 실행한다. 하나의 입력을 여러 모델에 동시에 보내 비교하거나, 여러 데이터 진단을 병렬로 돌릴 때 화면에서의 체감과 API를 통한 운영 성능이 달라질 수 있다는 뜻이다.
이 차이는 작은 데모가 서비스로 넘어갈 때 자주 문제를 만든다. 캔버스에서 잘 보였던 팬아웃 흐름을 API로 붙인 뒤 응답 시간이 길어졌다면, 모델 성능만 탓하기 전에 실행 경로가 바뀌었는지 확인해야 한다. 호출 횟수, 각 노드의 대기 시간, 실패 재시도, 외부 제공자의 제한을 분리해서 기록하는 편이 안전하다.
타입 검사도 유용하지만 완전한 검증은 아니다. 포트 타입이 맞아도 텍스트의 의미가 맞는지는 알 수 없고, JSON 형식이 유효해도 필수 필드가 업무 규칙을 만족하는지는 별도 검사해야 한다. 모델이 만든 SQL, 파일명, 고객용 문구처럼 영향이 큰 출력에는 다음 노드에서 형식 검증과 사람 승인을 명시적으로 넣는 편이 좋다.
작은 자동화로 시험해 볼 수 있는 방식
처음부터 여러 모델을 연결한 복잡한 앱을 만들 필요는 없다. 다음처럼 실패 비용이 낮고 결과를 비교하기 쉬운 흐름부터 시작할 수 있다.
- 두 단계만 나눠 보기: 기존 Python 자동화에서 입력 정리와 모델 호출, 또는 모델 호출과 결과 검사를 별도 노드로 만든다. 같은 샘플을 세 번 넣어 중간 결과가 어디서 달라지는지 기록한다.
- 승인 전 출력 하나 만들기: 외부 전송이나 데이터 변경 전에 사람이 읽는 검토용 subject를 둔다. 실행 버튼을 누르는 일과 결과를 확인하는 일을 같은 단계로 묶지 않는다.
- 캔버스와 API를 따로 측정하기: 병렬 분기가 있는 흐름이라면 화면 실행과 API 호출 각각의 총 시간, 노드별 시간, 실패 횟수를 비교한다. 차이가 나면 배포 전에 순차 실행을 전제로 비용과 대기 시간을 다시 계산한다.
도입 판단은 ‘시각화가 편한가’보다 검토가 남는가로
gr.Workflow는 아직 모든 AI 워크플로의 대체재라고 보기 어렵다. 문서가 설명하는 실행 방식과 권한 모델을 읽으면, 장기 실행 작업의 스케줄링, 복잡한 재시도, 비밀 관리, 조직 단위 감사 기록은 별도의 운영 도구가 필요할 가능성이 크다. 그래프에 연결할 수 있다는 사실만으로 외부 모델과 Space의 데이터 처리 조건이 해결되는 것도 아니다.
그럼에도 작은 팀이나 개인이 AI 자동화를 만들 때 좋은 출발점이 될 수 있다. 코드 속에 감춰 둔 작업 순서를 꺼내 놓고, 중간 산출물을 함께 보고, API로 부를 때의 동작 차이까지 확인할 수 있기 때문이다. 새 도구를 도입할 때는 멋진 캔버스를 평가하기보다 한 가지 실제 업무 흐름을 골라 보자. 어느 노드의 결과를 믿지 않고 다시 확인할지, 누가 편집할 수 있을지, API에서도 같은 시간 안에 끝나는지를 먼저 정해 보면 이 도구가 줄여 주는 병목이 보일 것이다.