AI 에이전트 도입

답변하는 AI가 아니라,
일을 끝내는 AI를 만듭니다.

문의, 견적, 서류 검토처럼 사람이 반복하는 일을 AI가 확인하고 판단하고, 중요한 행동은 사람 승인을 받아 실제로 처리하게 만들어요.

agent-run · 교환 문의 처리마지음 자체 데모 · 고객 사례 아님옆으로 밀어서 전체 흐름 보기 →
AI 에이전트 워크플로 한 사이클: 문의 수신, LLM 의도 분류, 사내 문서 검색·주문 조회·고객 컨텍스트, 에이전트 추론, 검증, 사람 승인, 실행, 로그·평가, 평가 결과의 검색 개선 반영 (마지음 자체 데모)평가 결과 → 검색 · 프롬프트 개선TTRIGGER문의 수신메일 · 폼 · 카카오톡webhookLLLM의도 분류Structured Outputintent · 0.94MMEMORY고객 컨텍스트이력 · 이전 대화12 turnsRRAG사내 문서 검색임베딩 · Vector DBtop-k 5TTOOL주문 조회ERP · 주문 APIGET 200AAGENT에이전트 추론계획 → 근거 결합 → 처리안근거 2건 인용GGUARDRAIL검증근거 · 정책 · PII 마스킹passHHUMAN사람 승인담당자 검토대기 → 승인AACTION실행발송 · ERP 기록2 actionsTTRACE · EVAL로그 · 평가run 기록 · 품질 점수eval 0.91agent run · trace[00.33s]webhook 문의 수신 · channel=쇼핑몰 Q&A[01.10s]router intent=교환요청 · urgency=high · conf=0.94[02.09s]rag retrieve top_k=5 → 교환 정책 §3, 배송 FAQ[02.31s]tool GET /orders/A-1042 → 200 · 배송 완료[03.41s]agent plan: 정책 확인 → 재고 확인 → 처리안 · 근거 2건[04.84s]guard grounded=true · policy=ok · pii=masked[06.05s]approval담당자 승인 대기 …[07.26s]approvalapproved by 담당자 · 2m 14s[08.03s]action send_mail(고객) · create_exchange(A-1042)[08.91s]trace run 저장 · eval=0.91 · latency 1.8s · cost ₩38
트리거부터 실행 · 평가까지 한 사이클. 검색(RAG) · 도구 호출 · 컨텍스트를 합쳐 에이전트가 처리안을 만들고, 가드레일과 사람 승인을 통과해야 실행돼요. 평가 결과는 다시 검색 품질 개선으로 돌아가요.

챗봇 하나 만드는 걸
AI 도입이라고 부르지 않아요.

질문에 답하는 것만으로는 업무가 끝나지 않아요. 차이를 눌러서 비교해 보세요.

요청→고객 · 문서 · DB 확인→판단→시스템 호출→사람 승인→실행 · 기록

AI가 흐름 전체 안에서 일하고, 되돌리기 어려운 행동만 사람이 승인해요.

다음 달에도 이 일을
사람이 똑같이 하고 있을 건가요?

업종은 달라도 구조는 같아요. 들어오고, 확인하고, 판단하고, 승인받고, 처리하는 일. 그 사이를 AI가 맡아요.

커머스 · 쇼핑몰

문의 · 교환을 직원 한 명이 붙잡고 있다면

요청 파악
주문 · 정책 · 재고 확인
담당자 승인 → 발송 · 기록
제조

고객사 사양 메일마다 견적을 새로 만든다면

도면 · 사양에서 품목 · 수량 추출
단가표 · 원자재 · 과거 견적 조회
검토 → 견적서 발송
금융 · 보험

제출 서류를 사람이 한 장씩 대조하고 있다면

서류에서 항목 추출
누락 · 불일치 · 기준 체크
심사 의견 초안 → 심사역 승인
물류 · 유통

배송 지연 · 파손 연락이 매일 쌓인다면

예외 알림 수신
운송장 · 재고 조회
고객 안내 + 재배송 요청
병원 · 클리닉

예약 변경 · 비용 문의 전화가 데스크를 막는다면

문의 유형 분류
일정 · 비용 안내 문서 확인
답변 초안 → 실장 확인
법률 · 세무 사무소

상담 메모를 정리하는 데 저녁을 쓴다면

상담 내용 구조화
유형별 필요 서류 · 쟁점 정리
체크리스트 · 초안 → 담당자 검토
제조 · 품질

불량이 나면 비슷한 과거 사례부터 뒤진다면

불량 보고 수신
과거 사례 · 조치 이력 검색
원인 후보 · 조치안 → 품질팀 승인
교육 · 학원

상담 문의에 같은 답을 매일 반복한다면

문의 의도 파악
커리큘럼 · 일정 · 비용 확인
상담 예약 제안 → 원장 확인
모든 회사 · 사내

직원들이 같은 규정을 계속 묻는다면

권한 확인
규정 · 매뉴얼 · 과거 답변 검색
근거 답변 · 해결 안 되면 담당자
서비스를 운영하는 팀이라면

별도 챗봇이 아니라,
내 제품의 기능으로

로그인한 사용자, 권한, 데이터 범위 안에서 검색 · 추천 · 분류 · 생성이 실제 기능으로 동작하게 만들어요.

AI 데모만 계속 쌓이고 있다면

데모는 하루면 만들어요.
운영되는 AI는 다른 문제예요.

권한 · 기록 · 품질 평가 · 비용 · 실패 대비를 붙여, 만들어 둔 PoC를 실제 서비스에 넣을 수 있게 바꿔요.

업종별 흐름은 일반적인 업무 예시이며, 고객 사례가 아니에요.

모델을 부르는 코드는 짧아요.
성능은 그 주변의 엔지니어링이 결정해요.

검색 품질을 평가셋으로 재고, 실패하면 되돌아가고, 누가 무엇을 승인했는지 남는 구조. 기업 환경에서 백엔드 · 데이터 플랫폼을 수년간 만들고 운영한 위에서, 지금은 RAG와 AI 에이전트를 실제 업무 시스템에 배포하고 있어요.

RAG 품질 자동 복구 루프

검색 품질이 떨어지면 코딩 에이전트가 패치하고,
평가를 통과하지 못하면 자동으로 롤백

고정된 평가셋으로 검색 · 답변 품질을 측정하고, 실패 유형을 진단해 Claude Code · Codex가 파이프라인 코드를 고치게 했어요. 수정본은 같은 평가셋으로 다시 검증하고, 개선되지 않으면 이전 버전으로 돌아가요. 에이전트에게 고칠 권한은 주되, 채택 여부는 평가가 결정해요.

평가셋실패 진단에이전트 패치재평가회귀 시 롤백
멀티 에이전트 공통 도메인

여러 에이전트가 같은 산출물을 다뤄도
충돌하지 않게, 버전과 승인을 도메인 모델로

작업 · 산출물 · 버전 · 승인 · 권한을 에이전트마다 따로 두지 않고 공통 도메인으로 설계했어요. 산출물은 버전 단위로 쌓이고, 승인 상태가 바뀌어야 다음 단계로 넘어가며, 누가 언제 무엇을 승인했는지 추적돼요.

도메인 모델링산출물 버전승인 상태 전이권한 경계감사 로그
구조 보존 문서 파이프라인

문서 구조를 잃지 않고 읽어서
벡터 · 키워드 검색으로 찾게

여러 형식의 문서를 구조를 보존해 파싱하고, 전처리와 청킹을 거쳐 Milvus 벡터 검색과 OpenSearch 인덱스로 적재했어요. 답변이 틀리는 원인의 상당수는 모델이 아니라 이 단계에 있어서, 검색 단계를 따로 평가해요.

구조 보존 파싱청킹 전략MilvusOpenSearch검색 평가
업무 절차를 에이전트 워크플로로

기업의 데이터 표준화 · 검토 · 승인 절차를
에이전트가 초안을 만들고 사람이 승인하는 흐름으로

기존 절차를 상태와 전이로 모델링하고, 에이전트는 구조화된 출력으로 표준안 초안을 만들게 했어요. 사람의 승인이 있어야 다음 상태로 넘어가고, 그 구조 그대로 실제 고객 환경에 배포했어요.

업무 분석Structured OutputTool CallingHuman-in-the-loop고객 환경 배포
백엔드 · 플랫폼Java · Spring · Kafka 이벤트 기반 MSA, PostgreSQL · Redis, 대용량 데이터 처리, Kubernetes 배포 · 운영
AI 엔지니어링Python · FastAPI, 구조 보존 파싱 · 청킹 · 벡터/키워드 검색, Tool Calling · Structured Output, 평가셋 기반 품질 측정
운영권한 경계 · 감사 로그 · 승인 상태 전이 · fallback · 자동 롤백 · CI/CD

위 내용은 마지음 운영자의 실무 경력이며, 마지음의 고객 사례가 아닙니다. 고객과 회사 정보는 공개하지 않습니다.

AI가 무엇을 할 수 있는지보다,
어디까지 해도 되는지를 먼저 설계해요.

식당을 직접 운영해 보면서 반복 업무가 얼마나 손이 가는지, 그리고 틀린 처리 한 번이 얼마나 비싼지 겪어봤어요. 그래서 AI에게 판단을 통째로 맡기지 않아요. 확인할 근거, 손댈 수 있는 범위, 사람이 승인할 지점, 틀렸을 때 돌아갈 길을 먼저 정하고 만들어요.

권한누가 무엇을 볼 수 있고, AI가 어디까지 손댈 수 있는지.
사람 승인발송 · 환불 · 변경처럼 되돌리기 어려운 행동은 사람이 승인.
기록과 평가무엇을 근거로 판단했는지 남기고 품질을 계속 측정.
실패 대비AI가 틀리거나 멈췄을 때의 대체 경로, 비용과 속도 관리.

직접 만들어 공개한 AI 데모 · 설계 보기 (MAJIEM Lab)

개발팀을 뽑기엔 이르고,
외주 한 번으로는 안 되는 문제.

지금 업무를 보고, 가장 작은 범위부터 직접 만들어 실제 업무에 붙여요. 상주 인력 없이 필요한 깊이만큼.

  1. 01업무 보기반복되는 일, 쓰는 도구, 데이터를 봐요.
  2. 02바꿀 곳 정하기AI가 정말 필요한지, 어디부터인지 판단해요.
  3. 03한 업무부터효과가 가장 큰 업무 하나를 실제로 구현해요.
  4. 04실제로 붙이기권한 · 승인 · 기록을 갖춘 상태로 배포해요.
  5. 05넓히기효과가 있는 부분만 다음 업무로 확장해요.

지금 사람이 반복하는
업무를 보내주세요.

어떤 AI가 필요한지 몰라도 괜찮아요. 누가, 어떤 일을, 얼마나 자주 하는지 글 몇 줄이면 충분해요.