사용되는 Dify 앱의 설계론

서론 — Dify 앱은 「만들 수」 있는데 「사용되지 않는」 케이스

시민 개발(Citizen Development)의 확산으로 업무 앱을 「만드는」 허들은 극적으로 낮아졌습니다. Dify를 사용하면 노코드(No-code)에 가까운 감각으로 워크플로우(Workflow)나 챗봇(Chatbot)을 구성할 수 있습니다. PoC(Proof of Concept)는 돌아가고, 데모에서는 분위기가 달아오릅니다. 하지만——실제 업무 플로우에는 올라타지 못하고, 어느샌가 아무도 사용하지 않게 됩니다.

원인을 파헤쳐 보면, 대부분의 경우 그것은 모델이나 워크플로우의 완성도 문제가 아니라, 그 전 단계에 있습니다. 「누가/무엇이 그 앱을 기동하는가」, 「사용자는 어떤 UI로 그것을 접하는가」와 같은, 앱을 업무에 "올리는" 설계가 뒷전으로 밀려나 있기 때문입니다.

1. 전제: AI 구현의 전체상과 이 글의 위치

AI를 업무에서 구동하는 메커니즘은 대략 다음과 같은 구조로 나타낼 수 있습니다.

사용자
↓
UI (채팅 / 업무 시스템 등)
...

이 중 본 기사가 주목하는 것은, **사용자와 가장 가까운 「UI」와 그 전 단계인 「기동 방식」**입니다. 설계 중에서도 뒷전으로 밀리기 쉬운 영역입니다. 서브 에이전트(Sub-agent)를 Dify로 고정하면, 남은 변수는 이곳으로 집약됩니다. 본 기사가 답하고자 하는 질문은 하나입니다.

이 질문을 (1) 기동 방식의 선정 → (2) UI의 선정 → (3) 실현성으로 확정, 이라는 3가지 프레임으로 차례대로 풀어가겠습니다.

2. 프레임 ①: 누가/무엇이 기동하는가 (3가지 기동 방식)

가장 먼저 결정해야 할 것은 "누가/무엇이 그 앱을 기동하는가"입니다. 기동 방식은 다음 3가지뿐입니다.

사용자 실행 — 사람이 그 자리에서 조작하여 기동함 (예: 메일을 연 사람이 「AI 초안 작성」 버튼을 누름)

상태 변화 기점 — 사건을 감지하여 자동으로 기동함 (예: 메일 수신을 감지하여 답장 초안을 생성)

시각 기점 — 정해진 시각/간격으로 자동적으로 기동함 (예: 매일 아침, 미처리 문의를 일괄 처리)

동일한 유스케이스(Use case)라도 이론상으로는 3가지 방식으로 구현할 수 있지만, 실무에서는 최적해가 거의 하나로 수렴합니다. 그 수렴을 이끄는 것이 아래의 판단 플로우입니다.

2.1 사전 정리: 유스케이스의 I/P/O를 작성하기

판단에 들어가기 전에, 대상 유스케이스를 4개 항목으로 언어화합니다. 특히 **인풋 (Input)**은 「입력이 시스템에서 갖춰지는가」의 판정에, **아웃풋 (Output)**은 UI 선정(리치 UI가 필요한가)에 직결됩니다.

항목	기입 내용
목적	이 유스케이스에서 달성하고자 하는 것을 한 문장으로
...

2.2 판단 플로우: 2가지 판단으로 기동 방식이 결정됨

판단 기준 ①: 기동을 자동화할 수 있는가?
├─ 아니오 → 사용자 실행으로 확정
└─ 예 → 판단 기준 ②로
...

포인트는, 사용자 실행을 「3가지 선택지 중 하나」가 아니라, 자동화가 성립되지 않았을 때 남는 선택지로 취급하는 것입니다. 앱을 업무에 올리려면, 사람이 기억해서 기동하는 것보다 자동으로 기동되는 편이 정착되기 쉽기 때문입니다.

판단 기준 ①-질문 1: 기동해야 할 타이밍을 시스템이 감지할 수 있는 사건으로 작성할 수 있는가?

「이때 움직여야 한다」라는 조건을 시스템이 감시할 수 있는 사건(메일 수신 / 파일 등록 / 데이터 업데이트 / 시각 도래 등)으로 기술할 수 있는가.

기술할 수 있음 → 질문 2로
기술할 수 없음 (「본인이 필요하다고 느꼈을 때」 등, 사람 내부에서만 판정할 수 있는 조건) →
사용자 실행으로 확정

주의: 「메일이 왔을 때」라도, 실제 조건이 「중요한 메일이 왔을 때」이고 그 "중요"의 판정을 자동화할 수 없다면 No로 분류합니다.

판단 기준 ①-질문 2: 그 타이밍에 처리에 필요한 입력은 모두 시스템을 통해 갖춰지는가?

질문 1의 사건이 일어난 시점에 인풋이 모두 시스템을 통해 취득 가능한가.

모두 갖춰짐 →
판단 기준 ②로 (완전 자동 후보)
사람의 머릿속에만 있는 정보(최종 판단·의도·문맥)가 필요함 →
판단 기준 ②로 진행하여, HITL (Human-in-the-Loop)이 있는 것으로 취급
어딘가에는 있지만 취득 경로가 미비함 → 현시점은 사용자 실행 (경로를 정비하면 자동화로 격상 가능)

판단 기준 ② (시각 기점인가 상태 변화 기점인가)는 다음 질문 하나로 집약할 수 있습니다.

그 시각에 움직여서 매번 의미 있는 처리가 되는가?

・된다 (대상이 반드시 존재 / 건수가 0이어도 업무 효과가 성립) → 시각 기점

・되지 않는다 (대상이 없을 때 움직이면 헛수고) → 상태 변화 기점

2.3 적용 예시

유스케이스	①질문 1	①질문 2	②기점	결론
메일 수신→답장 초안 작성	Yes	No (답장 판단은 사람)	상태 변화	HITL 있음
...

3. 프레임워크 ②: 어떤 UI로 접하게 할 것인가

기동 방식이 결정되면, 탑재할 UI의 후보도 결정됩니다. 본 기사에서는 사용자가 접하는 UI의 선택지로서 다음을 전제로 합니다.

3.1 사용자 실행의 경우

질문 1: 해당 유스케이스는 특정 업무 시스템 내에서 완결되는가?

메일 읽기/쓰기, 파일 공유, SFA, ITSM 등 입출력이 특정 시스템 내에서 닫혀 있다면, 해당 시스템상에서 AI를 기동하는 것이 업무 플로우(Workflow)에 녹아듭니다.

완결됨 → 해당 업무 시스템을 UI 후보로 함
완결되지 않음 / 여러 시스템을 가로지름 → 범용 UI (Slack / 자사 생성 AI 채팅 기반 / Dify 공개 URL) 중에서 선택 (질문 2로)

질문 2: 입출력은 플레인 텍스트(Plain Text)만으로 성립하는가?

다음 중 하나라도 필요하다면, 리치(Rich)한 입출력에 대응하는 UI (자사 생성 AI 채팅 기반 또는 Dify 공개 URL)를 선택합니다. 리치한지 여부는 '채팅인가 전용 화면인가'가 아니라, 해당 UI가 리치한 입출력에 대응할 수 있는가로 결정됩니다 (같은 채팅이라도 Slack은 텍스트 중심이지만, 자사 생성 AI 채팅 기반은 파일·표·차이(Diff)까지 다룰 수 있음).

파일 투입이 처리의 중심 (의사록, PDF 등)
출력이 표, 그래프, 대시보드
폼(Form) 입력 (다단계 선택식 입력)
원문과 수정안의 사이드 바이 사이드(Side-by-side) / 차이(Diff) 표시

위 사항들이 모두 필요 없다면 (텍스트로 충분하다면), Slack으로 충분합니다.

질문 3: 이용 시나리오 및 동선을 명확하게 설계할 수 있는가?

'언제, 어느 화면에서 사용할지'를 명확하게 설계할 수 있고, 입력 폼이나 용도 특화 화면이 빛을 발한다면, Dify 공개 URL을 전용 UI로 사용합니다. 동선이 모호한 상태에서 전용 화면을 만들어도 사용되지 않으므로, 그 경우에는 자사 생성 AI 채팅 기반(공통 입구)으로 모으는 것이 더 사용되기 쉽습니다.

태스크가 놓여 있는 장소	UI 후보	예
메일 읽기/쓰기가 중심	메일 클라이언트	수신 메일로부터 답장 초안 작성 / 장문 요점 정리·번역
...

3.2 상태 변화 기점의 경우

기점이 되는 업무 시스템을 그대로 UI로 사용하는 것이 원칙입니다. 기점과 UI가 같은 장소에 있음으로써, 사용자는 AI의 존재를 의식하지 않고 업무 플로우 속에서 받아들일 수 있습니다 (예: 메일 수신 → 메일 클라이언트, 파일 등록 → 파일 공유 서비스, 레코드 업데이트 → SFA).

3.3 시각 기점의 경우

기동 트리거가 시각이므로, UI는 '결과를 어디로 배포할 것인가'에 따라 결정됩니다. 배포처는 사용자의 평소 업무 플로우 안에 있는 것이 바람직하며, 대상에 따라 선택합니다 (팀 대상이라면 Slack 채널로 게시, 전사 대상이라면 메일, 특정 업무 시스템 이용자라면 해당 시스템 내의 대시보드 등).

4. 프레임워크 ③: '경로를 구성할 수 있는가'로 확정하기

3장까지 나온 것은 어디까지나 UI 후보입니다. 마지막으로, 그 후보로부터 실제로 Dify를 호출하는 경로를 구성할 수 있는지(실현 가능성)를 따져서 확정합니다.

질문: 후보 UI로부터 Dify를 호출하는 경로를 판단 레벨에서 구성할 수 있는가?

사용자 실행 — 해당 UI에 Dify를 기동하는 트리거 (버튼 / 메뉴 / 애드인)를 심을 수 있는가?
상태 변화 기점 — 기점 시스템이 감지 및 호출을 내보낼 수 있는가 (자동화 기능 / API 연동, 또는 중계 기반 경유)?
시각 기점 — 스케줄러와 결과 배포처로의 경로를 연결할 수 있는가

판정: 구성 가능 → 해당 UI로 확정. 구성 불가능 → 반려 (다른 후보를 찾거나, 불가능하다면 기동 방식 재검토).

참고로, 상태 변화 기점일 때만 '사건을 어떻게 포착할 것인가'를 별도로 결정합니다. 절차는

기동 방식은 두 가지 판단으로 결정된다: 자동화가 가능한가 → 시간 기반인가 상태 변화 기반인가. 사용자 실행은 "남은 선택지"일 뿐이다.
UI는 기동 방식으로부터 도출한다: 사용자 실행은 "업무 시스템 내에서 완결되는가? → 리치 UI (Rich UI) 필요 여부 → 동선" 순으로 결정하며, 자동 기동은 "기점/배포 대상이 그대로 UI가 된다".
후보군에서 멈추고, 경로를 구성할 수 있는지로 확정한다: 연결되지 않는다면 기동 방식 단계까지 거슬러 올라가 재검토한다.

이 세 가지 프레임(Frame)을 만들기 전의 체크리스트로 활용하는 것만으로도, "작동은 하지만 사용되지 않는" 앱은 상당히 줄어들 것입니다. 같은 과제를 다루고 계신 분들께 참고가 된다면 기쁘겠습니다.