노코드 LLM 워크플로우가 푸는 문제 — Dify 구조와 셀프호스팅

노코드 LLM 플랫폼을 도입하는 결정은 도구 선택이 아니다. 병목 리스크를 거버넌스 리스크로 교환하는 결정이다. 개발조직이 요청을 처리하느라 막히던 문제는 풀리지만, 대신 난립·중복·데이터 유출·비용 폭주가 새로 생긴다.

이 글은 그 교환을 다룬다. 노코드 플랫폼이 코드 프레임워크와 업무 자동화 SaaS 사이 어디에 놓이는지, 어떤 업무를 노코드로 열고 어떤 업무를 코드로 잠글지 가르는 기준, 앱 5종의 구조가 실제로 어떻게 다른지, 그리고 문서와 질의를 사내망에 남기는 셀프호스팅 구성까지 이어진다. 이어지는 세 편은 노드 체계와 지식베이스 RAG, 워크플로우 9종 해부, 확산과 통제의 설계다.

용어 정리

노코드 플랫폼의 좌표

LLM 애플리케이션을 만드는 방법은 세 층위로 나뉜다.

정확한 위치는 **"개발자가 만든 부품을 비개발자가 조립하는 층"**이다. 이 한 문장이 조직 관점에서 노코드를 이해하는 핵심이다.

무엇이 실제로 바뀌나

노코드 도입은 도구 도입이 아니라 업무 요청 경로의 재배치다.

마지막 행이 이 결정의 실체다. 병목 리스크를 거버넌스 리스크로 교환하는 것이므로, 도입 판단의 진짜 질문은 "노코드가 좋은가"가 아니라 **"우리 조직이 거버넌스 리스크를 감당할 준비가 되었는가"**다.

어디까지 열고 어디부터 잠그나

판정 규칙은 한 줄이다. 결과를 사람이 한 번 더 보는 업무는 노코드로 열고, 결과가 그대로 시스템에 반영되는 업무는 코드로 잠근다.

다만 이 경계는 고정이 아니다. 노코드로 검증된 워크플로우 중 사용량이 늘고 요구가 굳어진 것을 코드로 이관하는 것이 정상 경로다. 노코드는 요구사항 발굴 도구로도 기능한다.

플랫폼 구조 — 앱·지식·블록·도구

앱 5종은 DSL 구조가 다르다

여기가 흔히 헷갈리는 지점이다. 그래프가 없는 챗봇·에이전트는 DSL에 workflow 키 자체가 없고 model_config만 있다.

그래서 "챗봇 앱"과 "채팅플로우 앱"은 이름만 비슷할 뿐 DSL 구조가 완전히 다르다. 마이그레이션 시 챗봇 → 채팅플로우 자동 변환은 되지 않는다.

DSL 임포트가 거버넌스의 열쇠다

DSL 임포트·익스포트가 있다는 사실 자체가 중요하다. 워크플로우를 YAML로 뽑아 Git에 올리면 노코드 산출물에도 버전관리·리뷰·롤백을 붙일 수 있다.

셀프호스팅 — 사내망에서 끝내는 구성

사내 채팅 UI를 앞에 두고 실제 처리는 플랫폼 앱에 위임하는 어댑터 구조다.

어댑터의 구성요소

스트리밍 파싱과 그것이 드러내는 규약

response_mode: streaming일 때 SSE 라인을 파싱해 이벤트별로 다르게 처리한다.

마지막 행이 중요하다. workflow_finished가 outputs["output"]을 하드코딩한다.

즉 워크플로우의 끝 노드 출력 변수 이름을 output으로 통일한다는 사내 규약이 코드에 박혀 있는 셈이다. 실제로 출력 변수명이 text인 앱은 이 어댑터로 최종 산출을 받지 못한다.

노코드 산출물에도 인터페이스 규약이 필요하다는 것을 보여주는 사례다. 화면에서 조립한다고 해서 계약이 없어도 되는 것이 아니다.

데이터 통제 포인트

온프레미스 배치의 요점은 LLM 호출만 외부로 나가고 문서·질의·응답은 사내에 남는 구조를 만드는 것이다. 여기서 더 잠그려면 모델 공급자를 로컬 모델로 바꾸면 된다.

노코드 플랫폼 도입의 첫 설계 결정은 노드가 아니라 경계다. 어디까지가 사내망이고, 어느 호출이 외부로 나가며, 그 호출이 누구 이름으로 기록되는지를 먼저 정한다.

이것을 정하지 않고 시작하면 나중에 전부 다시 만들게 된다. 확산이 시작된 뒤에 경계를 긋는 것은 이미 만들어진 앱을 전수 조사하는 일이 되기 때문이다.

경계를 정했다면 다음은 실제로 무엇을 조립할 수 있는지다. 다음 편에서 노드 체계와 지식베이스 RAG 파이프라인을 다룬다.