요즘 기업 AI 도입 관련 대화를 하다 보면 거의 예외 없이 나오는 말이 있다. “우리도 AI 써야 하는 건 알겠는데, 뭘 어디서부터 시작해야 할지 모르겠어요.”
맞는 말이다. 챗GPT 계정 하나 만들어서 팀 전체가 돌려쓰는 걸 ‘AI 도입’이라고 부르기에는 뭔가 아쉽고, 그렇다고 수억 원 들여 자체 AI 시스템을 구축하기엔 부담스럽다. 그 사이 어딘가에 실용적인 답이 있다.
내가 그 답으로 계속 돌아오게 되는 게 Dify다. 특히 ‘1인 1에이전트’ 개념이 기업 현장에 실제로 적용 가능한 형태로 구체화되는 방식이 Dify에서 잘 보인다.
이전 글에서 Dify의 전체 구조와 설치, 기본 메뉴를 다뤘다. 이번엔 한 단계 더 들어간다. 에이전트, 워크플로우, 챗플로우가 실제로 어떻게 다르고, 각 직군이 어떤 기능을 써야 하는지, 그리고 기업에서 1인 1에이전트 체계를 실제로 어떻게 설계하면 되는지까지 풀어보겠다.
에이전트, 워크플로우, 챗플로우 – 헷갈리는 세 가지 정리
Dify를 쓰다 보면 이 세 가지 중 어떤 걸 선택해야 하는지 처음에 잘 안 보인다. 실제로 처음 Dify를 접한 분들이 가장 많이 하는 실수가 다 챗봇으로 만들거나, 반대로 뭐든 워크플로우로 만들려는 거다.
에이전트는 목표만 주면 알아서 판단한다. AI에게 “이 주제 리서치해서 요약해줘”라고 하면 웹 검색 도구를 쓸지, 지식베이스를 뒤질지, 계산기를 쓸지 스스로 결정하고 실행한다. 실행 흐름이 사전에 정해져 있지 않고, 상황에 따라 달라진다. 정해진 공식이 없는 열린 업무에 맞다. 리서치, 분석, 의사결정 보조처럼 매번 다른 경로가 필요한 작업이 여기에 해당한다.
워크플로우는 흐름을 내가 설계한다. 시작 → A단계 → B단계 → 조건 분기 → C단계 → 출력, 이 흐름을 캔버스에 노드로 그린다. 결과가 예측 가능하고 재현성이 중요한 업무에 맞다. 매주 반복되는 보고서 생성, 문서 분류 자동화, 고객 문의 처리 파이프라인 같은 것들이다. 한 번 만들어두면 같은 결과를 계속 안정적으로 뽑아낸다.
챗플로우는 대화하면서 워크플로우를 돌린다. 사용자와 대화 맥락을 유지하면서 복잡한 파이프라인을 실행한다. 단순 챗봇보다는 정교하고, 일반 워크플로우보다는 사용자 친화적이다. 예를 들어 “어떤 제품이 필요하세요?”라고 물어보고, 대답에 따라 다른 지식베이스를 검색하고, 맞춤형 견적을 만들어주는 식의 영업 보조 봇이 챗플로우로 만들기 딱 좋다.
정리하면 이렇다. 흐름을 AI가 스스로 결정해도 되면 에이전트, 흐름을 내가 통제해야 하면 워크플로우, 대화가 섞여야 하면 챗플로우다.
1인 1에이전트가 왜 지금 가능해졌나
몇 년 전까지만 해도 AI 에이전트를 한 사람씩 붙여준다는 개념은 현실적이지 않았다. 에이전트 하나 만드는 데 개발자가 며칠을 써야 했고, 유지보수도 쉽지 않았다.
지금은 다르다. Dify 같은 플랫폼이 나오면서 개발자 없이도 프롬프트를 잘 쓸 줄 아는 사람이라면 에이전트를 만들 수 있게 됐다. 삼성전자가 2500명에게 챗GPT와 클로드를 공식 도입하고, 토스가 오픈AI와 사내 해커톤을 돌린 것도 같은 맥락이다. AI를 한 명씩 쥐어주는 시대로 접어들고 있다.
가트너는 2026년 말까지 기업 애플리케이션의 40%에 작업 특화형 AI 에이전트가 탑재될 것이라고 전망했다. 한 해 만에 5%에서 40%로 뛰는 수치다. 이 속도에서 “언제 도입할까”는 이미 늦은 질문이고, “어떻게 내 업무에 맞게 만들까”가 맞는 질문이다.
여기서 핵심이 있다. 1인 1에이전트가 의미 있으려면 “공통 챗봇 하나를 모두가 쓰는 것”이 아니라 “각자의 업무 맥락에 맞게 세팅된 에이전트를 각자가 갖는 것”이어야 한다. 마케터의 에이전트와 영업의 에이전트, 인사팀의 에이전트는 같은 LLM을 쓰더라도 프롬프트, 연결된 지식베이스, 접근 가능한 도구가 달라야 한다.
직군별 에이전트 설계 – 마케터편
마케터가 반복적으로 하는 일 중 AI로 뺄 수 있는 것들이 꽤 많다. 경쟁사 모니터링, 콘텐츠 초안 작성, 시장 트렌드 조사, SNS 카피 작성, 광고 문구 A/B 변형 생성이 대표적이다.
마케터에게 추천하는 Dify 에이전트 구성은 이렇다.
경쟁사 모니터링 에이전트: 에이전트 유형으로 만들고, 구글 검색 도구와 웹 크롤링 도구를 붙인다. 시스템 프롬프트에 “경쟁사 이름이 주어지면 최근 1개월 내 주요 동향, 신제품 출시, 마케팅 캠페인을 조사하고 자사 전략에 시사점을 정리해줘”라고 넣는다. 자사 제품 정보가 담긴 지식베이스도 연결하면, 경쟁사 정보와 자사 현황을 비교한 분석이 자동으로 나온다. 매주 월요일 아침 이걸 한 번씩 돌리는 것만으로 주간 경쟁사 리포트가 된다.
콘텐츠 생성 워크플로우: 워크플로우 유형으로 만든다. 시작 노드에서 주제, 타겟 독자, 채널(블로그/인스타/링크드인)을 입력받는다. LLM 노드에서 채널별 특성에 맞는 톤과 길이로 초안을 생성한다. 조건 노드에서 채널에 따라 분기해서 블로그라면 SEO 키워드 삽입 단계를 추가하고, SNS라면 해시태그 생성 단계를 붙인다. 이 워크플로우 하나로 채널별 초안이 한 번에 나온다.
실제로 이 구조를 써본 마케터 분이 “보통 하나 쓰는 데 두 시간 잡았는데 이제 30분도 안 걸린다”고 했다. 시간이 줄어든 게 아니라 쓸 수 있는 콘텐츠 수가 늘어난 거다.
직군별 에이전트 설계 – 영업편
영업팀의 반복 업무는 조금 다른 결이다. 고객사 사전 조사, 제안서 초안, 미팅 후 후속 이메일, 견적 조회, 계약 조건 확인이 많다.
고객사 리서치 에이전트: 에이전트 유형. 고객사 이름과 미팅 목적을 입력하면, 웹 검색으로 해당 기업의 최근 동향, 주요 사업, 재무 정보를 수집하고, 자사 제품 지식베이스와 매칭해서 “이 고객사에 우리 어떤 솔루션이 맞는지”까지 제안해준다. 미팅 전 15분 안에 고객사 브리핑 문서가 만들어진다.
제안서 초안 챗플로우: 챗플로우 유형이 맞다. 대화 형식으로 고객 요구사항을 하나씩 확인하면서 제안서 구조를 잡아가는 방식이다. “고객사의 주요 문제가 뭔가요?” → “예산 범위는요?” → “우선순위 기능은?” 이런 식으로 질문하면서 답변을 조합해 제안서 초안을 생성한다. 자사 제품 가격표와 사례집을 지식베이스로 연결해두면 실제 수치까지 제안서에 들어간다.
후속 이메일 워크플로우: 미팅 후 10분 안에 후속 메일을 보내는 영업팀은 성과가 다르다. 워크플로우를 하나 만들어두고, 미팅 핵심 내용을 텍스트로 붙여 넣으면 고객사 이름, 논의 내용, 다음 단계, 담당자 서명이 포함된 후속 이메일이 자동 생성된다. 미팅이 끝나고 주차장 가는 길에 돌리면 된다.
직군별 에이전트 설계 – 인사팀편
인사팀이 특히 힘들어하는 업무가 반복 문의 응답이다. 연차 정산, 복지 혜택 조회, 근태 규정 확인, 채용 공고 작성, 면접 질문 설계. 이 중 상당 부분이 Dify로 해결된다.
HR 챗봇(챗플로우): 취업규칙, 복리후생 안내서, 연차 계산 규정, 사내 복무 규정을 지식베이스에 올린다. 챗플로우로 연결하면 직원들이 “연차 쓰려면 며칠 전에 신청해야 해요?”, “경조사 휴가는 얼마나 줘요?” 같은 질문을 24시간 스스로 해결할 수 있다. 인사팀에 오는 반복 문의의 절반은 이걸로 줄어든다. 실제로 이런 구조를 도입한 조직에서 인사팀 메신저 문의가 눈에 띄게 줄었다는 후기가 여럿 있다.
채용 공고 생성 워크플로우: 직군, 주요 업무, 자격 요건, 우대 사항을 입력하면 회사 톤앤매너에 맞는 채용 공고가 자동 생성된다. 회사 기존 채용 공고 샘플들을 지식베이스로 올려두면 문체와 형식이 일관되게 유지된다. 포지션마다 채용 공고 쓰는 데 한 시간씩 쓰던 걸 10분으로 줄일 수 있다.
면접 질문 생성 에이전트: 지원자 이력서를 붙여 넣으면 해당 직무에 맞는 면접 질문 세트를 생성한다. 공통 질문, 직무 전문성 질문, 컬처핏 질문으로 나눠서 나오게 프롬프트를 설계하면 면접관이 준비 시간을 확 줄일 수 있다.
직군별 에이전트 설계 – 개발자편
개발자도 Dify 에이전트의 수혜자다. 오히려 코드 노드와 HTTP 요청 노드를 자유롭게 쓸 수 있어서 더 강력하게 활용할 수 있다.
코드 리뷰 에이전트: PR 설명이나 코드 스니펫을 붙여 넣으면, 보안 취약점, 성능 이슈, 코드 스타일 가이드 위반을 점검하고 개선 제안을 준다. 회사 코드 스타일 가이드와 보안 정책을 지식베이스로 올려두면 자사 규칙 기준으로 리뷰가 나온다.
기술 문서 자동화 워크플로우: 코드나 API 스펙을 입력하면 README, API 문서, 함수 설명 주석을 자동 생성한다. 개발자들이 가장 귀찮아하는 문서화 작업을 상당 부분 자동화할 수 있다.
장애 대응 챗플로우: 에러 로그나 장애 증상을 대화 형식으로 입력하면, 과거 장애 케이스 지식베이스를 검색해서 유사 사례와 해결 방법을 제안한다. 온콜 중에 새벽 2시에 처음 보는 에러를 마주쳤을 때, 이 챗플로우가 있으면 첫 번째 방어선이 된다. 물론 최종 판단은 사람이 하지만, 실마리를 빠르게 찾는 속도가 다르다.
기업에서 1인 1에이전트를 실제로 굴리는 방법
개념은 이해했는데 실제로 조직에서 어떻게 시작하냐는 질문이 항상 따라온다. 내가 여러 팀에 Dify를 소개하면서 보니 성공하는 패턴이 있다.
첫째, 작은 고통부터 해결한다. “AI로 우리 업무 전체를 혁신하자”가 아니라 “이 반복 업무 하나만 없애보자”로 시작한다. 마케터라면 매주 쓰는 경쟁사 요약 보고서, 영업이라면 후속 이메일, 인사팀이라면 자주 받는 복지 문의. 이 하나가 해결되면 팀 안에서 입소문이 난다.
둘째, 에이전트를 팀 자산으로 관리한다. Dify는 팀 스페이스에서 앱을 공유할 수 있다. 누군가가 잘 만든 에이전트를 팀 전체가 쓸 수 있게 공개해두면, 그게 팀 자산이 된다. 한 명이 만들고 열 명이 쓰는 구조. 이게 쌓이면 팀 전체의 AI 역량이 된다.
셋째, 지식베이스를 살아있게 유지한다. 에이전트 품질의 절반은 지식베이스에서 결정된다. 오래된 문서, 구버전 정책, 폐기된 프로세스가 지식베이스에 남아있으면 AI가 틀린 답을 준다. 문서가 업데이트될 때마다 지식베이스도 함께 갱신하는 프로세스를 팀 루틴으로 넣어야 한다.
넷째, 모니터링은 선택이 아니다. Dify의 모니터링 메뉴에서 어떤 질문이 들어왔고, 어떤 답변이 나갔는지 정기적으로 확인해야 한다. 생각지 못한 질문 유형이 들어오거나, 답변이 엉뚱하게 나오는 케이스를 발견해서 프롬프트를 개선하는 게 에이전트를 유지 보수하는 방법이다. 배포하고 잊으면 안 된다.
다섯째, 보안 정책을 먼저 합의한다. 어떤 정보를 지식베이스에 올릴 수 있는지, 외부 LLM API에 어떤 데이터를 보내도 되는지를 IT 보안팀과 사전에 합의해야 한다. 민감한 개인정보, 미공개 영업 정보, 핵심 기술 문서는 외부 API를 타면 안 된다. 이런 데이터가 포함된 시스템이라면 셀프호스팅에 로컬 LLM을 연결하는 구조가 맞다.
에이전트가 잘 안 되는 케이스도 있다
이 부분을 빼면 반쪽짜리 글이 된다.
에이전트가 답변을 틀리게 주는 경우가 있다. 특히 지식베이스 문서가 구조화되지 않았거나, 서로 모순되는 내용이 섞여 있을 때 그렇다. 이걸 ‘할루시네이션’이라고 부르는데, 에이전트가 확신 있게 틀린 답을 줄 때가 가장 위험하다. 그래서 중요한 의사결정에는 에이전트 답변을 참고 자료로만 쓰고, 최종 판단은 반드시 사람이 해야 한다.
복잡한 멀티스텝 추론도 에이전트가 잘 못 하는 영역이다. “이 계약서 보고 법적 리스크 평가해줘”처럼 전문 법률 지식이 필요한 경우, 에이전트가 그럴싸한 분석을 줄 수는 있지만 그게 맞는지 검증할 전문가가 없으면 오히려 위험할 수 있다.
실시간으로 빠른 응답이 중요한 고객 접점도 Dify 에이전트 단독으로 쓰기엔 조심스럽다. LLM 응답 시간이 보통 몇 초 걸리기 때문에, 실시간 채팅 지원처럼 즉각 응답이 중요한 서비스는 구조 설계를 더 신중하게 해야 한다.
이런 한계를 알고 쓰는 것과 모르고 쓰는 것은 결과가 다르다.
1인 1에이전트는 도구가 아니라 일하는 방식의 변화
토스가 오픈AI와 사내 해커톤을 열면서 나온 결과물 중 하나가 ‘AI 도구를 사는 게 아니라 실험 문화를 만드는 것’이었다고 앞 글에서 다뤘다. 1인 1에이전트도 같은 맥락이다.
직원 각자가 자기 업무에 맞는 에이전트를 하나씩 갖는다는 건, 단순히 도구를 지급받는 게 아니다. 자기 업무를 AI가 이해할 수 있는 언어로 정리하고, 어떤 정보를 줘야 하는지 설계하고, 결과물을 검증하는 역량을 갖춘다는 뜻이다. 이 역량이 쌓이는 조직이 쌓이지 않는 조직과 1~2년 뒤에 어떤 차이가 날지는 굳이 설명이 필요 없다.
Dify는 그 진입 장벽을 낮춰주는 도구다. 에이전트 하나 만드는 데 개발팀이 필요 없어졌다. 프롬프트를 어느 정도 쓸 줄 알고, 자기 업무를 명확하게 설명할 수 있는 사람이면 충분하다.
지금 팀에서 가장 귀찮은 반복 업무 하나를 떠올려보자. 그게 당신 팀의 첫 번째 에이전트 주제다.