에이전트가 다음 분기를 고른다: Dify 1.18의 이동·추적 가능한 업무 흐름

에이전트 시연은 요청 한 번만 성공해도 설득력 있어 보입니다. 다른 팀이 재사용하려 할 때 더 어려운 질문이 나옵니다. 어느 분기를 선택하고, 어떤 파일이 앱과 함께 이동하며, 중첩된 작업 흐름 안에서 무슨 일이 있었는지 어디서 볼 수 있을까요?

2026년 10월 23일 출시된 Dify 1.18.0은 이 질문들을 함께 다룹니다. 에이전트 Output Routes, 이동 가능한 .ifpkg 앱 패키지, 더 깊은 작업 흐름 가시성을 도입했습니다. 더 인상적인 답변을 주기보다는 앱 안에서 에이전트의 역할을 이해하고 재사용하기 쉽게 만드는 변화입니다. 공식 릴리스.

Dify는 시각적 작업 흐름, 모델, 지식, 도구로 AI 앱을 만드는 플랫폼입니다. 같은 프롬프트를 채팅에 반복해서 복사하는 대신 모델의 판단을 앱의 단계와 연결할 수 있습니다. 이번 릴리스가 흥미로운 이유는 다음 단계 결정, 앱 이동, 실행 확인이라는 세 가지 실용적 문제를 함께 다루기 때문입니다.

작업 흐름 인터페이스 이미지: LangGenius / Dify 문서 기여자, CC BY 4.0. 잘라내지 않고 크기를 조정해 WebP로 변환했습니다. 시각적 편집기를 보여주는 화면이며 새 제어 기능이 모두 표시된 것은 아닙니다.

분기는 다음 목적지가 있는 결정이다

전통적인 작업 흐름은 알려진 값을 조건으로 확인하는 경우가 많습니다. 상태가 승인됐는지, 필드가 비었는지, 점수가 임계값을 넘었는지를 봅니다. 언어로 된 요청은 덜 정돈돼 있습니다. 고객이 질문, 불만, 예외 요청을 메시지 하나에 섞을 수 있습니다.

Dify의 새 Output Routes는 에이전트가 설정된 경로 중 하나를 골라 해당 분기로 계속 진행하게 합니다. 해석이 생성 문장 안에만 남지 않고 다음 단계가 표현된 절차 안의 선택이 됩니다.

이렇게 하면 앱을 설계하고 확인하기 쉬워질 수 있습니다. 제작자는 목적지를 정합니다. 에이전트는 요청에 맞춰 하나를 고릅니다. 작업 흐름은 연결된 단계를 수행합니다. 자연어 설명이 최종 결과물이 아닌 경우에도 경로 선택은 유용합니다.

경계는 중요합니다. “상향 보고” 경로를 골랐다고 법률·재무상 상향 보고가 필요하다는 것이 증명되지는 않습니다. “답장 초안” 경로 선택은 전송 허가가 아닙니다. 선택 후 가능한 행동과 예외 담당자는 흐름 안에 여전히 명시해야 합니다.

첫 번째 예는 고객 메시지 하나와 세 가지 경로다

제품 질문과 예외 요청을 함께 받는 고객 지원팀을 생각해 보겠습니다. 승인된 도움말로 답하기, 사람이 볼 초안 준비하기, 특이 사례를 상향 보고하기라는 세 경로를 구분하는 앱이 필요합니다.

명시적 경로를 쓰면 목적지가 흐름에 드러납니다. 단순한 설정 질문은 지식 기반 답변으로, 계정별 불확실성이 있는 요청은 검토로, 상업적 조건 변경 요청은 해당 결정을 맡는 팀으로 갈 수 있습니다.

Dify가 제공하는 완성된 고객 지원 규정이 아니라 앱 설계 예입니다. 무엇이 각 경로에 속하는지 정의하고 적절한 예를 주며 입력이 모호할 때 처리할 방식을 정해야 합니다. 설득력 있는 설명 때문에 권한 경계가 사라져서는 안 됩니다.

모든 메시지를 쉽게 분류한다는 것이 이점은 아닙니다. 제작자가 구체적인 결정을 평가할 수 있다는 점이 중요합니다. 어려운 메시지를 일반 답변 분기로 보내면 실패가 분명합니다. 모든 요청을 사람에게 보내면 안전할 수 있지만 자동화의 실용성은 낮아집니다.

까다로운 메시지와 기대 목적지를 묶어두세요. 복합 요청, 빠진 정보, 실제 고객 유입과 비슷한 언어 변형도 포함하면 좋습니다. 가장 깔끔한 예만 성공하는 흐름은 도식이 완성돼 보여도 여전히 시연 단계입니다.

설정된 경로는 언어 판단을 눈에 보이는 목적지로 바꿉니다. 각 목적지에는 허용 행동과 검토 규칙이 필요합니다.

이동 가능하다는 것은 프롬프트 복사 이상의 일이다

AI 앱은 지시, 에이전트 정의, Skills, 파일, 작업 공간 자원 참조에 의존할 수 있습니다. 가장 눈에 띄는 프롬프트만 복사하면 앱의 많은 부분이 빠집니다.

Dify 1.18의 .ifpkg 패키지에는 인라인 Agents, Skills, 해당 파일이 들어갈 수 있습니다. 릴리스는 가져올 때 자원을 다시 만들고 참조를 재매핑한다고 설명합니다. 파일과 URL로 YAML 또는 패키지를 가져올 수 있고 명시적 YAML 내보내기도 유지됩니다. 패키지와 가져오기 변경.

재사용 측면에서 의미 있는 변화입니다. 동료가 수동 지시 목록에서 구조를 복원하도록 두는 대신, 에이전트 작동 방식을 설명하는 연결 요소를 함께 옮길 가능성이 높아집니다.

모든 외부 의존성이 자동으로 이동한다는 뜻은 아닙니다. 모델 접근, 인증 정보, 플러그인 제공 여부, 네트워크 권한, 지식 자원은 목적지 환경에 따라 다를 수 있습니다. 구조를 온전히 가져와도 실행 전에 설정이 필요할 수 있습니다.

패키지를 검사 과정이 필요한 유용한 앱 결과물로 다루세요. 파일에는 받는 팀이 작성하지 않은 지시와 자료가 들어갈 수 있습니다. 중요한 접근 권한을 가진 작업 공간에 가져오기 전에 출처와 에이전트·도구가 수행할 일을 이해해야 합니다.

두 번째 예는 다른 팀으로 이동하는 제안서 흐름이다

서비스 회사가 첫 제안서 초안을 준비하는 흐름을 만들었다고 생각해 보겠습니다. 요청을 모으고, 글쓰기 Skill을 적용하고, 필수 구역을 확인한 뒤 불확실한 상업 조건을 사람에게 보냅니다.

다른 팀은 서비스 목록만 달리해 같은 방식을 쓰고 싶어 합니다. 프롬프트만 넘기면 불완전합니다. 재사용하는 작성 지침, 첨부 템플릿, 에이전트 참조도 동작의 일부이기 때문입니다. 패키지 형식은 이런 연결 요소를 더 많이 함께 옮기도록 설계됐습니다.

받는 팀에도 할 일이 남습니다. 서비스 정보를 교체하거나 확인하고, 허용할 모델과 도구를 설정하고, 제안서 승인자를 검증해야 합니다. 새 작업 공간에 맞지 않는 자원을 참조한다면 가져오기 성공만으로 그대로 둘 이유가 되지는 않습니다.

이동 전후 같은 샘플 요청 몇 개를 실행해 보세요. 경로 선택, 필수 구역, 도구 접근, 검토 동작을 비교합니다. 이동 가능한 앱은 의도한 절차를 보존하면서 목적지별 정보를 의도적으로 바꿀 수 있어야 합니다.

이 지점에서 패키징은 운영 기능이 됩니다. 복원 수고를 줄일 수 있지만 유용한 결과는 다른 팀이 이해하고 시험할 수 있는 반복 가능한 인계입니다. 가져오기 클릭 수 절약은 일부에 불과합니다.

흐름 내부를 보면 디버깅 질문이 달라진다

릴리스는 중첩 실행을 포함한 더 깊은 작업 흐름 가시성도 강조합니다. 앱 실패는 사용자가 알아차린 지점에서 몇 단계 떨어진 곳에서 생길 수 있으므로 중요합니다.

최종 초안이 나쁜 이유는 경로 오류, 지식 소스 누락, 불완전한 도구 결과, 중첩 흐름의 지시일 수 있습니다. 마지막 답변만 볼 수 있으면 책임 없는 프롬프트를 계속 다시 쓸 수 있습니다.

실행이 더 잘 보이면 질문을 좁힐 수 있습니다. 이 단계에 어떤 입력이 왔고, 어떤 결과를 냈으며, 다음에 누가 사용했을까요? 여러 부분을 한꺼번에 바꾸는 것보다 정확한 수정을 뒷받침합니다.

가시성과 모델 내부 추론의 완전한 설명은 다릅니다. 실행 정보는 앱 이벤트와 데이터 흐름을 보여줄 수 있지만 모든 토큰이나 경로를 선택한 이유까지 확정하지는 않습니다. 어떤 추적 내용을 누구에게 보여줄지도 자동으로 정하지 않습니다.

제공되는 가시성으로 관찰 가능한 동작을 이해하세요. 추적 보존 기간, 포함될 수 있는 민감한 자료, 접근할 사람은 따로 정해야 합니다. 비밀 요청을 다루는 앱에서 디버깅 편의가 무제한 열람으로 바뀌어서는 안 됩니다.

릴리스 공개와 실제 업그레이드는 별도 문제다

공식 GitHub 릴리스는 날짜가 있는 소프트웨어 공개입니다. 모든 호스팅 Dify 작업 공간에서 동시에 같은 기능이 활성화됐다는 증거는 아닙니다. 관리형 서비스를 쓴다면 특정 제어 기능을 전제로 계획하기 전에 실제 작업 공간과 제품 문서를 확인해야 합니다.

자체 호스팅에는 다른 책임이 있습니다. Dify 1.18 릴리스 노트는 API, 작업자, Agent Backend, 실행 이미지에 걸친 조정과 바뀐 에이전트 실행 프로토콜을 설명합니다. 여러 구성 요소 사이 통신이 바뀌는 릴리스에서 눈에 보이는 구성 요소 하나만 업데이트하는 방식은 신뢰하기 어렵습니다.

노트는 로컬 에이전트 샌드박스와 도구의 설정·마이그레이션 세부 사항도 짚습니다. 실제 설치를 기준으로 업그레이드 계획에 반영할 내용입니다. 제품 소개에서 복사한 보편적 명령 하나로 줄여서는 안 됩니다.

업그레이드 전에 현재 설정과 앱 결과물을 보존하고, 지원 구성 요소 버전을 확인하고, 적절한 환경에서 마이그레이션을 시험하세요. 예시 설정에 새 값이 보인다는 이유로 기존 인증·암호화 관련 설정을 바꾸면 안 됩니다. 릴리스의 정확한 이전 지침을 따라야 합니다.

당장 경로나 패키지를 평가하려는 팀이라면 별도 테스트 앱에서 시작하는 것이 합리적일 수 있습니다. 가장 중요한 흐름의 마이그레이션과 첫 실험을 결합하지 않고 새 동작을 익힐 수 있습니다.

유용한 평가 계획은 한 장에 담을 수 있다

도움이 되는지 알려고 수십 개 에이전트를 만들 필요는 없습니다. 실제 결정이 있는 앱 하나와 가져오기 시험용 두 번째 환경만 있어도 중요한 속성이 드러납니다.

1. 범위가 정해진 작업을 고릅니다. 검토할 고객 답장 준비처럼 입력과 결과를 알아볼 수 있는 절차를 고르고 예외 담당자를 정합니다.
2. 작은 경로 집합을 정의합니다. 경로마다 운영상 의미와 후속 행동을 정합니다. 안전하게 분류하기 어려운 요청의 경로도 포함합니다.
3. 대표 사례를 모읍니다. 정상 요청, 복합 의도, 정보 누락 사례를 넣고 실행 전 기대 경로를 적습니다.
4. 최종 답만 아니라 실행을 봅니다. 관련 중첩 단계를 따라 예상 밖 값이나 선택이 처음 생긴 지점을 확인합니다.
5. 앱을 내보내고 가져옵니다. 포함 자원을 검토하고 목적지의 참조, 도구, 모델, 비밀 정보를 확인합니다. 빠진 접근을 자동으로 부여해야 한다고 생각하지 않습니다.
6. 이동 후 같은 사례를 반복합니다. 경로와 출력을 비교하고 받는 팀 설정에서 의도적으로 바꾼 점을 기록합니다.

유용한 측정은 구체적입니다. 요청이 의도한 곳에 도달하는 비율, 인계에 필요한 설정량, 전체 실행을 복원하지 않고 실패를 찾을 수 있는지를 봅니다. 어느 지표도 생성 문장을 자기 정확성의 근거로 삼을 필요가 없습니다.

패키지는 앱 구조를 옮길 수 있습니다. 목적지에는 자체 접근 확인과 성공 동작을 정의하는 사례의 반복 검증이 필요합니다.

재사용의 기대와 실수의 확산을 함께 본다

유망한 방향은 더 재사용하기 쉬운 앱 단위입니다. 명시적 목적지, 더 많은 지원 에이전트 자원, 실패 시 더 잘 보이는 실행을 함께 담을 수 있습니다. 프롬프트 하나를 넘어섰지만 앱마다 맞춤 통합 프로젝트를 만들고 싶지는 않은 팀에 유용한 조합입니다.

동시에 이동성은 좋은 패턴만큼 실수도 효율적으로 퍼뜨릴 수 있습니다. 모호한 경로 정의나 과도한 권한의 도구가 깔끔한 패키지에 들어 있다고 적절해지지는 않습니다. 파일이 열리는지뿐 아니라 가져올 동작을 검토해야 합니다.

Dify의 다음 의미 있는 시험은 변화 속에서도 앱을 유지할 수 있는지입니다. 모델 교체, 새 Skill, 업무 규정 변경, 다른 작업 공간으로의 이동이 여기에 해당합니다. 첫 가져오기 성공도 고무적입니다. 의도한 동작을 보존하는 통제된 갱신이 더 강한 성숙도의 신호입니다.

Dify 1.18은 에이전트 결정을 눈에 보이는 구조와 연결해 이 실험을 더 흥미롭게 만듭니다. 작은 절차로 시작하고, 경로를 이해하기 쉽게 유지하고, 인계를 반복 가능하게 만드세요. 설득력 있는 시연이 다른 팀도 책임 있게 쓸 수 있는 도구로 바뀌는 방법입니다.

출처

• Dify 1.18.0 릴리스 노트, 2026년 10월 23일 06:33 UTC 게시.
• Dify 공식 문서, 제품 배경 자료. 릴리스 기능 제공 여부는 실제 작업 공간에서 확인해야 합니다.

작업 흐름 노트, 예시 요청, 수정의 결정 근거를 검색 가능한 곳에 남기고 싶으신가요? 참고 자료를 Telli.sh에 모아 인계 과정을 이해하기 쉽게 보관해 보세요.