Notion Custom Agents로 Dify 헬프데스크를 「자율 주행하는 AI」로 개조했다

서론

우리는 컨설팅/SI 사업자로서 엔터프라이즈 기업의 생성 AI 활용 지원을 수행하고 있습니다. 그중에서도 Dify 공식 판매 파트너로서, Dify를 도입한 클라이언트 기업에 문의 창구를 제공하고 있으며, 매일 다양한 기술 상담과 운영 상담을 받고 있습니다.

이 사내 Dify 헬프데스크는 헬프데스크 운영 시 흔히 발생하는 세 가지 고민에 직면해 있었습니다.

암묵지가 개인에게 고립됨: Slack에서 해결된 문의의 "왜 그렇게 판단했는가"가 본인 외에는 남지 않음 -
지식이 쌓이지 않음: 대응할 때마다 답변이나 사고 과정이 흘러가 버림 -
1차 대응이 개인에게 의존함: 과거 사례를 기억하는 사람이 없으면 매번 제로 베이스에서 조사가 시작됨

이에 대해, 사내 Dify 헬프데스크에서 AI First × Human-in-the-Loop (HITL)의 자율 주행 사이클을 만들었습니다. 두 개의 Notion Custom Agent와 하나의 Notion Automation을 조합하여, **「과거 사례로 1차 답변을 하는 AI」와 「대응 종료를 지식화하는 AI」**를 Notion DB로 연결하는 구조입니다.

본 기사에서는 이 아키텍처의 설계와 운영상의 노하우를 소개합니다. 코드를 작성하지 않고 Notion과 Slack만으로 만들 수 있기 때문에, 자사의 헬프데스크나 문의 창구, 시민 개발자 지원 팀의 운영에도 응용하기 쉬운 구성입니다.

본 기사의 예상 독자

사내 헬프데스크·문의 창구의 운영 개선을 생각하는 분: 1차 대응의 효율화와 지식 축적을 양립시키고 싶은 분 -
시민 개발자 육성·사내 DX를 추진하고 있는 분: AI First 방식의 질문 대응 유스케이스 구현을 검토 중인 분 -
AI 에이전트 설계를 고민하는 아키텍트: HITL을 포함한 자율 주행 사이클의 구현 패턴을 참고하고 싶은 분

1. 전체 아키텍처 — 2개의 에이전트로 돌리는 자율 주행 사이클

1.1 사이클의 전체 모습

Notion, Slack, Notion Custom Agents 세 가지로 구성되어 있습니다. 사이클의 큰 틀은 다음과 같습니다.

「과거의 완료 레코드를 읽고 1차 답변을 하는」 AI와 「미래의 완료 레코드를 만드는」 AI가 Notion DB라는 공유 지식(Knowledge)으로 연결되어 있는 구조입니다.

1.2 각 에이전트의 내부 처리

각 에이전트가 내부에서 어떻게 움직이는지는 다음과 같습니다.

1차 답변 에이전트 (문의 기안 시)

Slack new message로 시작
├─ 기안 알림의 ts를 스레드의 부모 ts로 취득
├─ 본문에서 Notion 페이지 URL을 추출하여 문의 상세 내용을 읽음
...

지식화 에이전트 (대응 완료 시)

상태 변경으로 시작
├─ Slack 스레드 전체를 취득
├─ 클라이언트에게 보낸 답변 원문을 특정 (원문 추출 / 재구성 / 검토 필요) 
...

1.3 각 요소의 역할

구성 요소	역할
Notion 문의 DB	기안 폼 + 과거 사례 검색원 + 지식 축적처 (허브)
Slack 전용 채널	대응 논의를 1차 정보로서 남기는 장소
Notion Automation	기안 시 Slack으로 알림을 게시 (1차 답변 에이전트의 시작 신호)
1차 답변 에이전트	과거 사례로부터 1차 답변 초안을 작성
지식화 에이전트	스레드의 논의를 지식(Knowledge)으로 변환

Notion 문의 DB가 「허브」가 되고 있다는 점이 포인트입니다. 기안·검색·축적의 세 가지를 하나의 DB가 겸함으로써 사이클이 자연스럽게 닫힙니다.

2. Notion 문의 DB 설계

2.1 주요 프로퍼티 (Property)

프로퍼티 (Property)	용도
起票ID (Ticket ID)	UNIQUE_ID, PREFIX INC
タイトル (Title)	문의 제목
種別 (Type)	Incident / Bug / Question / Request / Consultation
緊急度 (Urgency)	Critical / High / Medium / Low (HITL 준거 SLA)
ステータス (Status)	미착수 / 대응 중 / 해결 완료(기록 중) / 완료
担当者 (Assignee)	PEOPLE (복수 가능)
問い合わせ原文 (Original Inquiry)	RICH_TEXT
SlackスレッドURL (Slack Thread URL)	URL
初動日時 / 完了日時 (Initial/Completion DateTime)	DATE

2.2 스테이터스 (Status) 설계

포인트는 「해결 완료(기록 중)」라는 중간 상태를 독립시켜 두었다는 점입니다.

HITL[1]의 인시던트 관리(Incident Management)에서는 Resolved와 Closed를 구분하는 것이 표준적인 방식입니다. 이를 응용하여, **「대응자의 작업은 끝났지만, 지식화(Knowledge化)는 아직」**이라는 상태를 명확하게 표현했습니다.

이 스테이터스가 지식화 에이전트의 시작 신호가 되며, 대응자는 「해결 완료(기록 중)」로 변경하기만 하면 지식화가 자동으로 실행됩니다.

[1]: HITL (Information Technology Infrastructure Library) = IT 서비스 관리의 베스트 프랙티스를 정리한 국제적인 프레임워크. 인시던트 관리(Incident Management)・문제 관리(Problem Management)・변경 관리(Change Management) 등, IT 서비스 운영의 각 프로세스에 대해 표준적인 절차를 정의하고 있다.

3. 1차 답변 에이전트 — 과거 사례로부터 1차 답변 생성

3.1 동작 흐름

Notion Custom Agent로 제작하며, Slack new message로 시작합니다.

• 기표(起票) 알림으로부터 Notion 페이지 URL을 추출
• 문의 레코드의 상세 내용을 읽음
• 문의 DB의 과거 「완료」 레코드로부터 Notion AI search로 유사 사례를 탐색
• 과거 사례를 바탕으로 1차 답변 초안을 작성
• Slack 스레드에 답장으로 투하

3.2 1차 답변의 품질을 뒷받침하는 구조

지식(Knowledge) DB에 레코드가 쌓일수록 검색 적중률이 올라가고, 1차 답변의 품질도 올라가는 구조입니다. 지식화 에이전트가 남기는 「답변 원문」과 「행동 이력」이 이곳의 참조원이 됩니다 (자세한 내용은 후술).

3.3 HITL로서의 대응자 리뷰

AI가 만든 1차 답변 초안은 그대로 클라이언트에게 전송되지 않습니다. 대응자가 스레드 상에서 리뷰·수정하고, 필요하다면 기술 리드(Tech Lead)에게 FYI로 확인한 후 클라이언트에게 송부합니다.

「AI에게 전부 맡기는」 것이 아니라, AI가 초안을 만들고 인간이 판단과 최종화를 담당하는 역할 분담을 통해, 품질을 유지하면서도 「제로에서부터 쓰는」 공수를 제거하고 있습니다.

4. 지식화 에이전트 — 대응 종료를 지식으로 전환

4.1 설계 사상

지식화 에이전트는 스레드를 요약하는 것이 아니라, **Notion AI가 향후 문의 대응 시 과거 사례로 참조할 수 있는 형식지(Explicit Knowledge)**를 만드는 것이 목적입니다.

중요한 설계 판단은 요약(Summary)이 아니라 「답변 원문」과 「행동 이력」을 남기는 것입니다. 이유는 세 가지입니다.

• 요약은 정보가 누락되므로, AI가 유사 사례를 찾을 때의 단서가 줄어듦
• 클라이언트에게 송부한 답변 원문은 「승인을 받은 완성품」이며, 품질이 보증된 자산임
• 행동 이력(사고 과정·판단 근거)은 다음 대응자가 동일한 판단 축을 사용할 수 있는지 배우기 위한 1차 정보임

4.2 3개 섹션 구성

지식화된 페이지는 다음의 3개 섹션으로 구성됩니다.

📨 클라이언트에 대한 답변

클라이언트에게 송부한 답변 원문을 코드 블록(Code Block)에 원문 그대로 넣어 저장합니다. Slack mrkdwn과 Notion Markdown은 굵게(Bold)나 링크를 쓰는 방식이 다르지만, 코드 블록에 넣어두면 변환이 필요 없고 원문의 열화도 방지할 수 있습니다.

답변 원문 추출은 세 가지 패턴을 구분하여 사용합니다.

• 스레드 내에 최종 답변이 있는 경우 추출
• 초안·대화(Wall-hitting)만 있는 경우 통합하여 재구성
• 판별이 어려운 경우 '요리뷰(Review 필요)' 플래그를 붙여 최종 게시물을 채택

🔍 답변에 이르기까지의 대응 이력

시계열로 「암묵지(Tacit Knowledge)의 에센스」를 추출합니다. 작성 방식은 다음과 같습니다:

[MM/DD(ddd) HH:MM 이름] Xxx

Xxx

에는 단순한 행동 기록이 아니라, 다음 내용을 한 줄로 응축합니다.

어떤 상황이 있었는지 (전제·직전의 주고받은 대화·받은 의뢰) -
어떤 논점으로 생각하여 판단했는지 (검토한 관점·참조한 정보원·판단의 근거) -
어떻게 움직였는지 (게시·FYI·확인 요청·송부 등)

예를 들어, 다음과 같은 행들이 나열됩니다.

[04/27(월) 11:55 다나카] 에러 로그 전문을 재게시하며, "이전에 다른 환경에서 발생했던 현상 아닐까요?"라고 과거 유사 사례의 가능성을 가설로 제시

여기서 중요한 것은, "과거 유사 사례의 가능성을 가설로 제시"라는 사고의 움직임 그 자체를 남기는 것입니다. 다른 대응자가 비슷한 문의를 접했을 때, "과거에 이런 방식으로 가설을 세웠다"라는 메타적인 판단 축도 재사용할 수 있습니다.

📎 참고 자료·관련 링크

스레드 내에서 참조된 URL·문서·관련 지식(Knowledge)을 링크로 집약합니다. 링크가 대응의 어느 부분에서 활용되었는지는 대응 이력 섹션에서 다루고 있으므로, 여기서는 액세스용 인덱스(Index)로 사용합니다.

4.3 상태(Status)에 따라 움직임을 바꾸는 판정 로직

지식화 에이전트(Knowledge Agent)의 실행 판정은 **Notion 상태(Status)**로 구분합니다.

상태	움직임
해결됨(기록 중)	통상 실행 (메인 시작 신호)
...

"미착수/대응 중이지만, 사실은 해결된 상태"라는 상태 업데이트 누락을 놓치지 않기 위해, 상태가 업데이트되지 않았더라도 스레드에서 판정하는 우회로를 만들어 두었습니다. 한편, 입력 불비(완료 상태인데 본문이 비어 있는 경우 등)는 Notion 측의 체크 뷰(Check View)를 통해 사람이 육안으로 확인하는 운영 방식과 조합합니다.

5. 구현상의 고안과 주의할 점 (ハマりポイント)

5.1 노이즈 논의의 제외

스레드에는 본 문의와 관계없는 논의(Slack 운영 규칙에 대한 지적, 별도 안건 이야기 등)가 섞일 수 있습니다. 이를 그대로 지식화하면 Notion AI가 유사 사례를 찾을 때 노이즈가 되기 때문에, 명시적으로 제외합니다.

판별 기준은 "지식 기반(Knowledge Base)으로서 재사용할 수 있는가"입니다. 기술적 문의의 지식으로서 가치가 있는지를 기준으로 판단합니다.

5.2 답변 원문의 저장 방법

Slack의 *굵게*, <URL|표시 이름>과 Notion Markdown의 **굵게**, [표시 이름](URL)은 작성 방식이 다릅니다.

처음에는 변환 로직을 작성하려고 했으나, 운영해 본 결과 **"Slack 원문을 그대로 코드 블록(Code Block)에 넣는다"**는 방식으로 타협했습니다.

관점	변환 로직 방식	코드 블록 저장 방식
원문 열화 리스크	변환 실수로 발생할 수 있음	제로
...

클라이언트에게 송부 완료된 답변 원문은 조직으로서 가장 품질이 보장된 자산입니다. 이를 열화시키지 않고 남기는 것을 최우선으로 했습니다. 장식은 사라지지만, 원문을 지키기 위한 것이므로 수용하고 있습니다.

5.3 담당자 속성(Property) 자동 설정

스레드에서 실제로 발언한 멤버를 Notion의 담당자 속성에 자동으로 설정합니다. FYI 멘션만 하고 발언하지 않은 멤버는 대상에서 제외합니다.

절차:

• 스레드에서 발언한 사람의 user_id를 수집한다
• Slack 사용자 프로필에서 email을 가져온다
• email로 Notion 사용자(User)를 찾는다
• Notion 사용자 ID 배열을 담당자 속성에 넣는다

Slack과 Notion을 email로 연결하는 방법이 심플하고 확실했습니다.

5.4 날짜 속성의 타임존(Timezone) 함정

Notion UI에서 날짜 속성의 타임존 설정을 변경하는 조작은, **값의 재해석에 의한 쓰기(Overwrite)**로 동작하는 사양이 있습니다. "UTC → 도쿄"로 바꾸면, 표시 시각은 그대로 유지되면서 내부 값이 9시간 어긋나는 함정이 있습니다.

대책으로서, 에이전트로부터 전달하는 날짜 값에는 반드시 JST 오프셋이 포함된 ISO 8601 형식 (YYYY-MM-DDTHH:MM:SS+09:00)을 사용합니다. UI 조작으로 타임존을 건드리지 않고, API 측에서 확실하게 시각 정보를 남기는 운영 방식입니다.

5.5 타임스탬프(Timestamp) 작성 방식

대응 이력의 시각 표기는 [MM/DD(ddd) HH:MM 이름]으로 하고 있습니다. 헬프데스크 대응은 날짜를 넘기는 경우가 많기(야간 대응·주말 포함·수일에 걸친 조사) 때문에, HH:MM만으로는 시계열을 파악하기 어렵기 때문입니다.

요일까지 포함하면 「당일 대응」 「주말을 넘기는 대응」 「야간 작업」 등의 대응 리듬 (Response Rhythm) 을 한눈에 파악할 수 있습니다.

5.6 입력 미비 검지용 체크 뷰

DB에 두 가지 뷰 (View)를 준비해 두었습니다.

• ⚠️장기 방치 체크: 「미착수」 「대응 중」 상태로 방치되어 있는 레코드
• ⚠️완료 레코드 입력 미비: 「완료」 상태이지만 완료 일시가 비어 있는 레코드 (나리지화 에이전트 (Knowledge Agent)가 실행되지 않았을 가능성이 높음)

에이전트 측에서 모호하게 판정하는 대신, 운영 실수는 인간이 뷰를 통해 육안으로 확인하도록 설계함으로써 에이전트 로직 (Agent Logic)을 심플하게 유지할 수 있습니다.

5.7 Slack 완료 알림으로 피드백 루프를 닫다

나리지화 에이전트는 처리가 완료될 때 Slack 스레드 (Thread)로 완료 알림을 게시합니다.

✅ INC-XX의 대응 로그를 Notion에 나리지화했습니다.
• 처리 타입: 신규 생성
• 답변 특정: 케이스 1 (원문 추출)
...

Slack 측만 확인하는 관계자도 문의의 종료를 파악할 수 있으며, Notion 페이지로도 클릭 한 번에 이동할 수 있습니다. Slack 측에서 피드백이 완결됨으로써 운영 부하를 더욱 낮추고 있습니다.

6. 자율 주행 사이클이 만드는 효과

6.1 나리지가 시간이 흐름에 따라 성장하는 구조

이 시스템의 가장 큰 가치는, 나리지가 시간이 흐름에 따라 자연스럽게 늘어나고, 1차 답변 에이전트의 1차 답변 품질도 시간이 흐름에 따라 올라가는 구조에 있습니다.

시점	상태
초기	나리지 DB 비어 있음, 과거 사례 없이 답변
...

완료 레코드가 1건 늘어나면, 다음번 1차 답변 에이전트의 참조 소스 (Reference Source)로 자동으로 추가됩니다. 자기 강화 루프 (Self-reinforcement Loop) 가 돌기 시작하면, 조직 전체의 문의 대응 능력이 사용하면 사용할수록 크게 향상됩니다.

6.2 AI-First × HITL이라는 역할 분담

「AI에게 전부 맡긴다」도 「인간이 전부 한다」도 아닌, AI가 번거로운 작업을 가져가고 인간은 본래의 지적 판단에 집중한다는 역할 분담을 설계한 것이 이 아키텍처 (Architecture)의 특징입니다.

흥미로운 점은, 인간이 클라이언트 대응을 위해 자연스럽게 수행하는 활동이 그대로 나리지화 에이전트의 「재료」가 된다는 것입니다.

단계	AI가 하는 일	인간이 하는 일	부산물로 남는 것
1차 답변안 작성	과거 사례 검색 + 초안 생성	클라이언트에게 보낼 답변을 완성	최종적으로 클라이언트에게 송부된 답변 원문
...

즉, 인간은 「나리지를 위해 무언가 추가로 기록을 남길」 필요가 없습니다. 평소처럼 Slack으로 대응하는 것만으로도 그 과정이 자동으로 나리지화 에이전트에게 소재를 제공하고 있습니다. 이것이 「인간에게 추가 부하를 주지 않는 자율 주행 사이클」의 본질입니다.

인간이 리뷰하는 단계를 반드시 거치기 때문에, AI의 출력에 문제가 있더라도 하류로 흘러가지 않습니다. AI 출력을 기점으로 논의가 시작되므로, 「제로에서부터 쓰는」 공수도 사라집니다.

6.3 향후 전망 — 접점을 AI에게 개방하다

본 기사에서 소개한 구성은 현시점에서는 「클라이언트의 문의를 당사 측 대응자가 AI의 지원을 받으며 처리하는」 형태입니다. AI와의 접점은 어디까지나 당사 측 담당자에게 있습니다.

하지만 나리지가 충분히 축적된 단계에서는 다음 페이즈 (Phase)로 나아갈 수 있습니다. 클라이언트 스스로가 AI와 직접 주고받으며, AI로 해결되지 않을 때만 인간이 개입하는 형태입니다.

페이즈	클라이언트 측의 경험	당사 측의 관여
현재	당사 측 담당자에게 Slack/메일 등으로 문의	담당자가 1차 답변 에이전트의 지원을 받아 답변
미래	Slack 채널 등에서 AI 챗봇과 직접 주고받음	AI로 해결된 문의는 무인으로 완결. AI가 해결하지 못할 때만 담당자가 개입하여 답변

미래 페이즈의 움직임을 구체적으로 그리면 다음과 같습니다.

• 클라이언트가 Slack 스레드에서 질문을 던짐
• AI 챗봇이 과거 사례로부터 답변 (8할의 문의는 여기서 해결)
• AI가 해결하지 못하는 문의는 당사 측 담당자가 개입하여 스레드 내에서 답변
• 개입한 대화는 다시 나리지화 에이전트에 의해 나리지가 됨
• 나리지가 성장함에 따라, 다음번부터는 동일한 종류의 문의도 무인으로 해결할 수 있게 됨

즉, HITL (Human-In-The-Loop) 사이클은 그대로 계속 돌아가며, 인간의 개입 빈도가 시간이 지남에 따라 낮아지게 된다. 이것이 본 아키텍처의 최종적인 도달점입니다.

7. 문의 대응 이외로의 전개 가능성

이 아키텍처는 「문의 → 논의 → 지견 축적」의 루프를 가진 모든 업무에 응용할 수 있습니다.

적용 영역	상정 시나리오
사내 DX 상담 창구	전 직원의 DX/AI 활용 상담 1차 대응
...

특히, 시민 개발자 (Citizen Developer)를 육성하여 내재화를 진행하는 단계에서는 「베테랑에게 질문이 집중되는」 병목 현상이 자주 발생합니다. 이 아키텍처를 도입하면, 베테랑의 암묵지 (Tacit Knowledge)가 형식지 (Explicit Knowledge)가 되어, 시민 개발자가 스스로 움직일 수 있는 환경을 조성하는 에코시스템 (Ecosystem) 을 구축할 수 있습니다.

8. 요약

본 기사에서는 Notion, Slack, Notion Custom Agents를 조합한 AI First × HITL 헬프데스크 자율 주행 사이클의 설계 및 구현 사례를 소개했습니다.

포인트는 다음과 같습니다.

2개의 Notion Custom Agent를 조합하여, 「과거 사례로 1차 답변하는 AI」와 「대응 종료를 지식화하는 AI」를 Notion DB로 연결

요약이 아니라 「답변 원문」과 「행동 이력」을 남기는 설계로, 향후 문의 대응에 사용할 수 있는 형식지를 축적

암묵지의 핵심 (상황 → 사고·판단 → 행동)을 한 줄로 응축하는 대응 이력 포맷을 통해, 과거 대응의 판단 기준까지 재사용 가능하게 함

상태(Status) 기반의 판정 로직 + 입력 미비 체크 뷰로, 에이전트 로직을 심플하게 유지하면서 운영 실수도 검지

코드를 작성하지 않고도 만들 수 있으며, 시민 개발자도 개선할 수 있는 에코시스템으로서의 범용성도 갖추고 있습니다.

조직의 헬프데스크, 상담 창구, 지식 운영을 재검토하는 데 참고가 되기를 바랍니다. 「우리 조직에서도 문의 대응의 암묵지를 형식지로 만들고 싶다」고 생각하신다면, 오늘부터 Custom Agent의 참조 소스에 과거 사례를 1건 넣는 것부터 시작해 보세요.