Make, FastAPI, OpenAI, Monday CRM을 활용한 Human-in-the-Loop AI 워크플로 자동화

데모에서는 AI 워크플로 자동화(AI workflow automation)가 단순해 보입니다.

양식 제출이 들어옵니다.
AI 모델이 이를 읽습니다.
CRM이 업데이트됩니다.
Slack 메시지가 발송됩니다.
이메일이 전송됩니다.

하지만 데모에서 프로덕션(production) 단계로 넘어가면, 워크플로는 훨씬 더 민감해집니다.

AI 요약이 틀리면 어떻게 될까요?

불완전한 데이터로 CRM이 업데이트되면 어떻게 될까요?

고객 요청이 다음 단계로 넘어가기 전 사람의 승인이 필요하다면 어떻게 될까요?

워크플로가 중간에 실패하면 어떻게 될까요?

바로 그 지점에서 AI 워크플로 자동화는 더 나은 아키텍처(architecture)를 필요로 합니다.

최근 한 프로젝트에서 우리는 다음과 같은 도구들을 사용하여 AI 워크플로 자동화 시스템을 설계했습니다:

Make.com: 워크플로 오케스트레이션(workflow orchestration)용
FastAPI: 커스텀 백엔드 로직(custom backend logic)용
OpenAI/GPT API: 요약 및 구조화된 출력(structured output)용
Monday.com CRM: 레코드 관리용
Slack: 내부 알림용
Gmail: 이메일 기반 커뮤니케이션용
Human review steps: 승인 및 제어를 위한 사람의 검토 단계

목표는 챗봇(chatbot)을 만드는 것이 아니었습니다.

목표는 워크플로를 제어 가능하고, 추적 가능하며, 일상적인 비즈니스 사용에 실용적으로 유지하면서 반복적인 수동 검토 작업을 줄이는 것이었습니다.

워크플로 문제

기존 워크플로는 여러 수동 단계가 있었습니다:

새로운 요청이 들어옵니다.
누군가가 요청을 수동으로 검토합니다.
중요한 정보가 추출됩니다.
CRM 레코드가 생성되거나 업데이트됩니다.
내부 팀에 알림이 전송됩니다.
후속 이메일이 준비되거나 발송됩니다.
팀이 워크플로를 수동으로 추적합니다.

이러한 종류의 워크플로는 서비스 비즈니스, 운영 팀, 영업 팀, 그리고 CRM 중심의 프로세스에서 흔히 볼 수 있습니다.

고통스러운 점은 특정 단계가 너무 어렵다는 것이 아니었습니다.

고통스러운 점은 동일한 단계가 계속해서 반복된다는 것이었습니다.

이로 인해 워크플로는 느려지고, 일관성이 없으며, 수동 복사-붙여넣기 작업에 의존하게 됩니다.

왜 모든 것을 완전히 자동화하지 않을까요?

당연한 생각은 다음과 같습니다:

AI가 요청을 읽고 모든 것을 자동으로 업데이트하게 하자.

하지만 이는 위험할 수 있습니다.

AI가 생성한 출력(output)은 불완전하거나, 과도하게 확신에 차 있거나, 약간 틀릴 수 있기 때문입니다.

출력이 단지 초안(draft)일 뿐이라면 이는 허용될 수 있습니다.

하지만 출력이 검토 없이 CRM 필드를 직접 업데이트하거나, 고객에게 이메일을 발송하거나, 내부 액션을 트리거(trigger)한다면 이는 허용될 수 없습니다.

따라서 우리는 완전히 눈먼(blind) 자동화 흐름을 피했습니다.

대신, 워크플로(workflow)는 더 안전한 패턴을 따랐습니다:

입력 수신 (Input received)
      ↓
AI가 데이터를 처리하고 구조화 (AI processes and structures data)
...

이것이 Human-in-the-loop AI 자동화의 핵심 아이디어입니다.

AI는 반복적인 작업을 줄여줍니다.

인간은 판단, 승인 또는 비즈니스 맥락(business context)이 중요한 부분에 계속 관여합니다.

Make.com의 역할

Make.com은 오케스트레이션(orchestration)에 유용했습니다.

이는 서로 다른 시스템을 연결하고 도구 간의 액션을 트리거하는 데 도움을 주었습니다.

전형적인 책임 범위는 다음과 같았습니다:

워크플로 트리거(workflow triggers) 수신
앱 간의 데이터 이동
API 호출
Slack 알림 전송
Gmail 액션 트리거
백엔드 엔드포인트(backend endpoints)로 데이터 전달
단계 간 워크플로 상태 업데이트

많은 자동화 사례에서 Make.com만으로도 충분합니다.

하지만 워크플로에 커스텀 검증(custom validation), 구조화된 AI 처리, 더 고급 API 로직, 또는 제어된 실패 처리(failure handling)가 필요할 때는 백엔드 레이어(backend layer)가 유용해집니다.

그 지점에서 FastAPI가 등장했습니다.

왜 FastAPI를 추가했는가?

FastAPI는 노코드(no-code) 자동화 흐름 내에 완전히 존재해서는 안 되는 로직에 대해 더 많은 제어권을 제공했습니다.

몇 가지 예시는 다음과 같습니다:

구조화된 프롬프트(structured prompts) 준비
들어오는 페이로드(payloads) 검증
요청 데이터 정규화(normalizing)
AI API 응답 처리
AI 출력을 CRM용 필드에 매핑(mapping)
실행 전 비즈니스 규칙 적용
승인 상태 관리
오류 및 폴백(fallback) 응답 처리
향후 워크플로 확장을 용이하게 유지

단순화된 백엔드의 책임 구조는 다음과 같았습니다:

Make.com 트리거
      ↓
FastAPI 엔드포인트가 페이로드 수신
...

이러한 분리는 시스템을 더 깔끔하게 만들었습니다.

Make.com은 자동화 흐름을 처리했습니다.

FastAPI는 커스텀 비즈니스 로직을 처리했습니다.

AI 모델은 요약 및 구조화된 해석을 처리했습니다.

CRM은 운영 기록을 처리했습니다.

Slack과 Gmail은 커뮤니케이션 (Communication)을 담당했습니다.

각 도구는 고유한 역할을 수행했습니다.

AI 처리 계층 (AI processing layer)

AI 계층은 "모든 결정을 내리도록" 설계되지 않았습니다.

주로 다음과 같은 작업을 지원하는 데 사용되었습니다:

들어오는 요청 요약 (summarizing incoming requests)
주요 세부 사항 추출 (extracting key details)
의도 식별 (identifying intent)
구조화된 정보 준비 (preparing structured information)
다음 작업 제안 (suggesting next actions)
수동 읽기 및 복사-붙여넣기 노력 감소 (reducing manual reading and copy-paste effort)

프로덕션 워크플로 (Production workflows)에서는 구조화된 출력 (Structured output)이 중요합니다.

길고 자유로운 형식의 AI 응답에 의존하는 대신, 백엔드 (Backend)는 모델이 예측 가능한 필드 (Predictable fields)를 생성하도록 유도해야 합니다.

예를 들어:

{
  "summary": "요청에 대한 짧은 요약",
  "intent": "support_request",
...

이러한 구조는 워크플로를 검토, 검증하고 다운스트림 시스템 (Downstream systems)으로 전달하기를 더 쉽게 만듭니다.

인간 검토 계층 (Human review layer)

인간 검토 계층은 시스템에서 가장 중요한 부분 중 하나였습니다.

검토가 없다면 AI 출력물이 CRM이나 고객 커뮤니케이션에 직접적인 영향을 미칠 수 있습니다.

검토를 통해 팀은 다음과 같은 사항을 빠르게 확인할 수 있습니다:

요약이 정확한가?
요청 카테고리가 올바른가?
권장되는 다음 단계가 유효한가?
이 업데이트를 Monday.com CRM에 반영해야 하는가?
알림이나 이메일을 트리거 (Trigger)해야 하는가?
이 케이스에 수동 처리가 필요한가?

이를 통해 워크플로를 실용적으로 유지할 수 있습니다.

사람이 모든 수동 작업을 처음부터 수행할 필요는 없습니다.

사람은 AI가 준비한 출력을 검토하고 승인하거나 조정하기만 하면 됩니다.

보통 바로 이 지점에서 가장 큰 생산성 향상이 일어납니다.

CRM 업데이트 계층 (CRM update layer)

Monday.com CRM은 운영 기록 시스템 (Operational system of record)으로 사용되었습니다.

자동화는 통제된 방식으로 CRM 데이터를 업데이트해야 했습니다.

이는 CRM 매핑 (Mapping)이 신중하게 처리되어야 함을 의미합니다.

예를 들어:

AI 요약 → CRM 노트 (Notes)
요청 의도 (Request intent) → CRM 카테고리 (Category)
우선순위 (Priority) → CRM 우선순위 필드 (Priority field)
...

중요한 원칙은 다음과 같습니다:

AI의 가공되지 않은 출력 (Raw AI output)을 CRM 필드에 맹목적으로 밀어넣지 마십시오.

AI 출력은 검증되어야 하고, 필요한 경우 검토되어야 하며, 의도적으로 필드에 매핑되어야 합니다.

CRM 데이터 품질이 중요합니다.

잘못된 CRM 업데이트는 영업(Sales), 지원(Support), 운영(Operations) 및 보고(Reporting) 부서에 혼란을 야기할 수 있습니다.

알림 계층 (Notification layer)

커뮤니케이션을 위해 Slack과 Gmail이 사용되었습니다.

Slack은 요청에 주의, 검토 또는 후속 조치가 필요할 때 내부 팀원들에게 알리는 데 도움을 주었습니다.

Gmail은 이메일 관련 워크플로 단계를 지원했습니다.

하지만 다시 한번 강조하지만, 워크플로는 주의를 기울여야 합니다.

AI가 생성한 모든 메시지를 자동으로 전송해서는 안 됩니다.

어떤 경우에는 AI가 초안(Draft)을 작성할 수 있습니다.

사람이 이를 승인하거나 편집할 수 있습니다.

그 후에 이메일이 전송될 수 있습니다.

이렇게 하면 고객을 대상으로 하는 커뮤니케이션을 더 안전하게 유지할 수 있습니다.

로깅 및 가시성 (Logging and visibility)

로깅(Logging)은 자동화 프로젝트에서 종종 무시되곤 하지만, 워크플로가 매일 실행되기 시작하면 매우 중요해집니다.

시스템은 다음과 같은 질문에 답할 수 있어야 합니다:

어떤 요청이 들어왔는가?
AI가 무엇을 생성했는가?
사람의 검토가 필요했는가?
누가 출력을 승인하거나 변경했는가?
CRM이 업데이트되었는가?
Slack 알림이 전송되었는가?
이메일이 트리거(Triggered)되었는가?
어떤 단계에서 실패했는가?
어떤 폴백(Fallback)이 사용되었는가?

이는 AI가 워크플로의 일부일 때 특히 중요합니다.

로그는 디버깅(Debugging), 신뢰 구축 및 지속적인 개선에 도움이 됩니다.

로그가 없으면 자동화는 블랙박스(Black box)가 됩니다.

그리고 블랙박스 자동화는 비즈니스 운영에 위험 요소가 됩니다.

아키텍처 패턴 (Architecture pattern)

전체적인 아키텍처는 다음과 같았습니다:

Incoming Request
      ↓
Make.com Scenario
...

이 패턴은 하나의 도구가 모든 것을 수행하는 것에 의존하지 않기 때문에 유용합니다.

또한 팀에 유연성을 제공합니다.

나중에 워크플로가 변경되면 백엔드 로직(Backend logic)을 업데이트할 수 있습니다.

CRM 필드가 변경되면 매핑(Mapping)을 조정할 수 있습니다.

AI 프롬프트(Prompt)를 개선해야 한다면 이를 정교화할 수 있습니다.

새로운 알림 채널이 필요하다면 오케스트레이션 계층(Orchestration layer)을 통해 추가할 수 있습니다.

주요 설계 교훈 (Key design lessons)

이러한 종류의 AI 워크플로 자동화 프로젝트에서 얻은 주요 교훈은 다음과 같습니다.

1. AI 모델로 시작하지 마십시오

워크플로부터 시작하십시오.

도구를 결정하기 전에 정확한 비즈니스 프로세스를 매핑하십시오.

다음과 같이 질문하십시오:

무엇이 반복적인가?
무엇에 판단이 필요한가?
무엇을 요약해야 하는가?
무엇을 승인해야 하는가?
무엇을 자동으로 업데이트해야 하는가?
무엇을 기록(log)해야 하는가?

AI는 워크플로 (workflow)에 맞춰져야 합니다.

워크플로를 AI에 억지로 맞추어서는 안 됩니다.

2. 정확성이 중요할 때는 AI가 CRM을 직접 업데이트하는 것을 피하십시오

CRM 업데이트는 실제 비즈니스 운영에 영향을 미칩니다.

만약 AI의 출력이 틀렸다면, 그 실수는 후속 조치, 보고, 그리고 팀의 워크플로 (workflow)로 확산될 수 있습니다.

필요한 경우 검증 (validation) 및 검토 단계를 사용하십시오.

3. 모든 것을 처리하기 위해서가 아니라, 오케스트레이션 (orchestration)을 위해 노코드 (no-code) 도구를 사용하십시오

Make.com과 같은 도구는 시스템을 연결하는 데 매우 훌륭합니다.

하지만 검증 (validation), 구조화된 AI 처리, 규칙, 그리고 더 나은 오류 제어가 필요할 때는 여전히 커스텀 백엔드 로직 (custom backend logic)이 유용합니다.

4. 별도의 증명이 없는 한 AI 출력을 초안으로 취급하십시오

많은 비즈니스 워크플로 (workflow)에서 AI는 작업을 준비하는 역할을 해야 합니다.

민감한 부분은 사람이 승인해야 합니다.

그것이 더 안전하고 실용적인 모델입니다.

5. 처음부터 로그 (logs)를 구축하십시오

로그 기록 (logging)을 나중에 생각나는 대로 추가하지 마십시오.

자동화가 비즈니스 운영을 실행할 만큼 중요하다면, 이를 적절히 추적 (track)하는 것 또한 충분히 중요합니다.

마지막 생각

AI 워크플로 (workflow) 자동화는 단순히 API를 연결하는 것만이 아닙니다.

그것은 적절한 수준의 제어 (control)를 설계하는 것에 관한 것입니다.

어떤 단계는 완전히 자동화될 수 있습니다.

어떤 단계는 AI의 지원을 받아야 합니다.

어떤 단계는 사람의 검토를 필요로 해야 합니다.

어떤 단계는 제안만 생성해야 합니다.

최고의 자동화 시스템은 모든 곳에서 사람을 제거하는 시스템이 아닙니다.

워크플로 (workflow) 내에서 판단, 맥락, 그리고 책임 (accountability)을 유지하면서 반복적인 작업을 줄여주는 시스템입니다.

그것이 AI 자동화가 데모를 넘어 유용해지는 방법입니다.

전체 케이스 스터디 (case study)는 여기에서 확인하십시오:

https://www.zestminds.com/ai-workflow-automation-make-fastapi-monday-crm