Human-in-the-Loop Agents 완벽 가이드

AI 에이전트가 중요한 결정을 내리기 전에 사람의 승인을 받는 시스템을 구축하는 방법을 배웁니다. 실무에서 안전하고 신뢰할 수 있는 AI 에이전트를 만드는 핵심 패턴을 소개합니다.

1. 인간 개입 지점 설정

어느 날 김개발 씨는 회사에서 AI 에이전트를 활용한 자동화 시스템을 만들었습니다. 그런데 팀장님이 걱정스러운 표정으로 다가왔습니다.

"이 AI가 실수로 중요한 데이터를 삭제하면 어떡하지요? 사람이 확인할 수 있는 장치가 필요해요."

인간 개입 지점이란 AI 에이전트가 중요한 작업을 수행하기 전에 사람의 확인이나 승인을 받도록 설정한 지점입니다. 마치 은행에서 큰 금액을 이체할 때 관리자 승인이 필요한 것처럼, AI도 위험도가 높은 작업에서는 사람의 판단을 구해야 합니다.

이를 통해 AI의 효율성과 사람의 판단력을 조화롭게 결합할 수 있습니다.

다음 코드를 살펴봅시다.

# 인간 개입 지점을 설정하는 기본 패턴
class HumanApprovalAgent:
    def __init__(self, risk_threshold=0.7):
        self.risk_threshold = risk_threshold

    def execute_task(self, task, risk_score):
        # 위험도가 임계값을 넘으면 사람의 승인을 요청합니다
        if risk_score > self.risk_threshold:
            print(f"작업 '{task}'의 위험도가 {risk_score}입니다.")
            approval = input("승인하시겠습니까? (yes/no): ")
            if approval.lower() != 'yes':
                return "작업이 거부되었습니다."

        # 승인되거나 위험도가 낮으면 작업을 실행합니다
        return self._perform_task(task)

    def _perform_task(self, task):
        return f"'{task}' 작업을 실행했습니다."

김개발 씨는 입사 6개월 차 개발자입니다. 최근 회사에서 AI 에이전트를 활용해 고객 문의를 자동으로 처리하는 시스템을 개발했습니다.

처음에는 모든 것이 순조로웠습니다. AI가 빠르게 답변하고, 고객들도 만족했습니다.

그런데 어느 날 큰 문제가 발생했습니다. AI 에이전트가 실수로 중요한 고객 데이터를 삭제하려는 명령을 실행하려 했던 것입니다.

다행히 직원이 재빨리 발견해서 막았지만, 만약 늦었다면 큰 사고가 날 뻔했습니다. 팀장 박시니어 씨가 김개발 씨를 불렀습니다.

"김 대리, AI가 아무리 똑똑해도 100% 믿을 수는 없어요. 중요한 작업에서는 사람이 확인해야 합니다." 인간 개입 지점이란 정확히 무엇일까요?

쉽게 비유하자면, 인간 개입 지점은 마치 자동차의 브레이크와 같습니다. 차가 아무리 빨리 달려도 위험한 순간에는 운전자가 브레이크를 밟아 멈출 수 있어야 합니다.

이처럼 AI 에이전트도 중요한 순간에 사람이 개입할 수 있는 장치가 필요합니다. 인간 개입 지점이 없던 초기 AI 시스템은 어땠을까요?

개발자들은 AI가 모든 작업을 자동으로 처리하도록 만들었습니다. 효율적이었지만, 문제는 AI가 실수할 때였습니다.

잘못된 데이터를 학습하거나, 예상치 못한 상황을 만나면 AI는 엉뚱한 결정을 내렸습니다. 더 큰 문제는 이런 실수를 사후에야 발견한다는 점이었습니다.

돌이킬 수 없는 피해가 이미 발생한 후였습니다. 바로 이런 문제를 해결하기 위해 Human-in-the-Loop 패턴이 등장했습니다.

인간 개입 지점을 설정하면 위험한 작업을 사전에 차단할 수 있습니다. 또한 AI의 결정 과정을 사람이 검토할 수 있어 투명성이 높아집니다.

무엇보다 AI와 사람의 협업이라는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 risk_threshold는 어느 정도 위험부터 사람의 승인을 받을지 정하는 임계값입니다. 예를 들어 0.7이면 위험도가 70%를 넘는 작업에서 승인을 요청합니다.

execute_task 메서드에서는 작업의 위험도를 평가합니다. 만약 위험도가 임계값을 넘으면 input() 함수로 사용자에게 승인을 요청합니다.

사용자가 "yes"를 입력하면 작업을 진행하고, 그렇지 않으면 작업을 거부합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 이커머스 플랫폼을 개발한다고 가정해봅시다. AI 에이전트가 재고를 자동으로 관리하는데, 100만 원 이상의 주문이나 대량 환불 요청은 위험도가 높습니다.

이럴 때 인간 개입 지점을 설정해서 관리자가 직접 확인하도록 만들 수 있습니다. 아마존, 구글 같은 글로벌 기업들도 이런 패턴을 적극 활용하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 모든 작업에 승인을 요청하는 것입니다.

이렇게 하면 사람이 너무 자주 개입해야 해서 오히려 비효율적입니다. 따라서 위험도를 정확히 평가해서 정말 필요한 순간에만 개입 지점을 설정해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언을 들은 김개발 씨는 시스템에 인간 개입 지점을 추가했습니다.

"이제 중요한 작업은 팀장님이 확인하시니 안심이네요!" 인간 개입 지점을 제대로 설정하면 AI의 효율성과 사람의 판단력을 모두 활용할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 위험도 평가 기준을 명확히 정의하세요 (금액, 데이터 중요도, 영향 범위 등)

승인 요청 메시지에 충분한 컨텍스트를 포함하세요 (무엇을, 왜, 언제)
너무 많은 승인 요청은 오히려 피로도를 높이니 적절한 임계값을 찾으세요

2. 승인 워크플로

김개발 씨는 인간 개입 지점을 성공적으로 구현했습니다. 하지만 새로운 문제가 생겼습니다.

"팀장님이 자리를 비우셨는데 긴급한 승인이 필요하면 어떻게 하죠?" 선배 이테크 씨가 웃으며 말했습니다. "그래서 승인 워크플로가 필요한 거예요."

승인 워크플로는 AI 에이전트의 작업 승인 요청이 어떤 경로로 전달되고 처리되는지 정의한 프로세스입니다. 마치 회사에서 결재 라인이 있는 것처럼, 1차 승인자가 없으면 2차 승인자에게 자동으로 넘어가는 체계를 만듭니다.

이를 통해 승인이 필요한 순간에도 시스템이 멈추지 않고 원활하게 작동할 수 있습니다.

다음 코드를 살펴봅시다.

# 다단계 승인 워크플로우 구현
from enum import Enum
from typing import List, Optional

class ApprovalStatus(Enum):
    PENDING = "대기중"
    APPROVED = "승인됨"
    REJECTED = "거부됨"

class ApprovalWorkflow:
    def __init__(self, approvers: List[str]):
        # 승인자 목록 (순서대로 시도)
        self.approvers = approvers
        self.current_index = 0

    def request_approval(self, task: str) -> ApprovalStatus:
        # 승인자 목록을 순회하며 승인 요청
        while self.current_index < len(self.approvers):
            approver = self.approvers[self.current_index]
            print(f"{approver}님께 승인 요청: {task}")

            # 실제로는 이메일, 슬랙 등으로 알림을 보냅니다
            response = input(f"{approver}님의 응답 (approve/reject/unavailable): ")

            if response == "approve":
                return ApprovalStatus.APPROVED
            elif response == "reject":
                return ApprovalStatus.REJECTED
            else:
                # 승인자가 부재중이면 다음 승인자에게
                print(f"{approver}님이 부재중입니다. 다음 승인자에게 전달합니다.")
                self.current_index += 1

        # 모든 승인자가 부재중이면 대기 상태로
        return ApprovalStatus.PENDING

김개발 씨가 만든 시스템은 잘 작동했습니다. AI가 중요한 작업을 하려 할 때마다 팀장님에게 승인을 요청했습니다.

그런데 어느 금요일 오후, 문제가 발생했습니다. 팀장 박시니어 씨가 외부 미팅으로 자리를 비웠습니다.

그런데 바로 그때 긴급한 고객 요청이 들어왔고, AI는 승인을 기다리며 멈춰 있었습니다. 고객은 "왜 이렇게 오래 걸리나요?"라며 불만을 터뜨렸습니다.

선배 이테크 씨가 상황을 보고 김개발 씨에게 조언했습니다. "단일 승인자만 의존하면 이런 일이 생기죠.

승인 워크플로를 만들어야 해요." 승인 워크플로란 정확히 무엇일까요? 쉽게 비유하자면, 승인 워크플로는 마치 우체국의 배달 시스템과 같습니다.

우편물을 받을 사람이 집에 없으면 이웃이나 관리실에 맡기듯이, 1차 승인자가 없으면 자동으로 2차, 3차 승인자에게 요청이 전달됩니다. 이처럼 승인 워크플로도 여러 경로를 통해 승인을 받을 수 있게 합니다.

단일 승인자만 있던 초기 시스템은 어땠을까요? 개발자들은 보통 한 명의 관리자를 지정해서 모든 승인을 받도록 만들었습니다.

간단하고 명확했지만, 문제는 그 사람이 없을 때였습니다. 휴가, 출장, 회의 등으로 자리를 비우면 시스템이 멈췄습니다.

더 큰 문제는 긴급한 상황에서도 대응할 수 없다는 점이었습니다. 바로 이런 문제를 해결하기 위해 다단계 승인 워크플로가 등장했습니다.

승인 워크플로를 사용하면 업무 연속성을 보장할 수 있습니다. 한 명이 부재중이어도 다른 사람이 대신 승인할 수 있습니다.

또한 역할 기반 승인도 가능합니다. 예를 들어 금액에 따라 팀장, 부장, 임원 순으로 승인 권한을 다르게 설정할 수 있습니다.

무엇보다 유연성이라는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 ApprovalStatus 열거형으로 승인 상태를 명확히 정의합니다. ApprovalWorkflow 클래스는 승인자 목록을 받아서 순서대로 저장합니다.

request_approval 메서드에서는 while 루프로 승인자 목록을 순회합니다. 각 승인자에게 요청을 보내고, "approve"면 즉시 승인됨을 반환하고, "unavailable"이면 다음 승인자로 넘어갑니다.

모든 승인자가 부재중이면 대기 상태를 반환합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 금융 서비스를 개발한다고 가정해봅시다. 10만 원 이하는 팀장 승인, 100만 원 이하는 부장 승인, 그 이상은 임원 승인이 필요합니다.

승인 워크플로를 만들면 금액에 따라 자동으로 적절한 승인자에게 요청을 보낼 수 있습니다. 대형 은행들은 이런 계층적 승인 시스템을 필수로 사용하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 승인자를 너무 많이 추가하는 것입니다.

10명의 승인자를 등록하면 복잡해지고 관리하기 어렵습니다. 따라서 2-3명의 핵심 승인자만 지정하는 것이 좋습니다.

또한 타임아웃 설정도 중요합니다. 승인자가 24시간 이상 응답하지 않으면 자동으로 다음 단계로 넘어가도록 만들어야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 이테크 씨의 조언을 들은 김개발 씨는 승인 워크플로를 구현했습니다.

"이제 팀장님이 자리를 비워도 부팀장님이 대신 승인할 수 있네요!" 승인 워크플로를 제대로 설계하면 시스템의 안정성과 유연성을 동시에 확보할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 승인자는 2-3명으로 제한하고, 역할과 권한을 명확히 정의하세요

타임아웃을 설정해서 승인자가 응답하지 않으면 자동으로 다음 단계로 넘어가게 하세요
승인 이력을 로그로 남겨서 나중에 감사(audit)할 수 있게 하세요

3. 피드백 루프

김개발 씨의 시스템은 이제 안정적으로 작동했습니다. 그런데 팀장 박시니어 씨가 한 가지를 더 제안했습니다.

"승인만 받고 끝나는 게 아니라, 사람의 피드백을 AI가 학습하면 어떨까요?" 김개발 씨는 눈이 반짝였습니다. "그럼 AI가 점점 똑똑해지겠네요!"

피드백 루프는 사람이 AI의 결정을 승인하거나 거부할 때 그 이유와 피드백을 함께 기록하고, AI가 이를 학습해서 다음번에는 더 나은 결정을 내리도록 하는 메커니즘입니다. 마치 학생이 시험을 보고 선생님의 피드백을 받아 실력이 향상되는 것처럼, AI도 사람의 판단을 배우며 성장합니다.

이를 통해 시간이 지날수록 사람의 개입이 줄어들고 AI의 자율성이 높아집니다.

다음 코드를 살펴봅시다.

# 피드백 루프를 구현한 학습형 에이전트
import json
from datetime import datetime

class FeedbackLoop:
    def __init__(self, feedback_file="feedback_history.json"):
        self.feedback_file = feedback_file
        self.feedback_history = self._load_feedback()

    def _load_feedback(self):
        # 기존 피드백 이력을 불러옵니다
        try:
            with open(self.feedback_file, 'r', encoding='utf-8') as f:
                return json.load(f)
        except FileNotFoundError:
            return []

    def collect_feedback(self, task, decision, approved, reason):
        # 피드백을 수집하고 저장합니다
        feedback = {
            "timestamp": datetime.now().isoformat(),
            "task": task,
            "ai_decision": decision,
            "approved": approved,
            "reason": reason
        }

        self.feedback_history.append(feedback)

        # 파일에 저장합니다
        with open(self.feedback_file, 'w', encoding='utf-8') as f:
            json.dump(self.feedback_history, f, ensure_ascii=False, indent=2)

        return feedback

    def analyze_patterns(self):
        # 피드백 패턴을 분석합니다
        if not self.feedback_history:
            return "피드백 데이터가 부족합니다."

        total = len(self.feedback_history)
        approved = sum(1 for fb in self.feedback_history if fb['approved'])
        approval_rate = (approved / total) * 100

        return f"승인율: {approval_rate:.1f}% ({approved}/{total})"

김개발 씨의 시스템은 이제 제법 안정적이었습니다. AI가 중요한 작업을 하기 전에 승인을 받고, 승인자가 부재중이면 다른 사람에게 자동으로 넘어갔습니다.

모든 게 순조로웠습니다. 그런데 한 달쯤 지나자 팀장 박시니어 씨가 피곤한 표정을 지었습니다.

"매일 똑같은 종류의 승인 요청이 오네요. AI가 학습을 못 하는 건가요?" 김개발 씨도 로그를 확인해 보니 그랬습니다.

AI는 비슷한 상황에서도 매번 사람에게 물어봤습니다. 이전에 승인받았던 것과 거의 동일한 케이스인데도 말이죠.

선배 이테크 씨가 다가와 말했습니다. "피드백 루프가 없어서 그래요.

AI가 과거의 승인 결정을 학습하지 못하고 있어요." 피드백 루프란 정확히 무엇일까요? 쉽게 비유하자면, 피드백 루프는 마치 운전 학원의 교육 시스템과 같습니다.

학생이 운전 실수를 하면 교관이 왜 틀렸는지 설명하고, 학생은 그걸 기억해서 다음번에는 같은 실수를 하지 않습니다. 이처럼 AI도 사람의 승인/거부 결정과 그 이유를 배우며 점점 똑똑해집니다.

피드백 루프가 없던 초기 AI 시스템은 어땠을까요? AI는 매번 같은 질문을 반복했습니다.

사람이 "이건 승인해"라고 했어도, 다음에 똑같은 상황이 오면 또 물어봤습니다. 학습 능력이 없었기 때문입니다.

더 큰 문제는 사람의 피로도가 계속 증가한다는 점이었습니다. 아무리 똑똑한 AI라도 학습하지 못하면 단순한 규칙 기반 시스템과 다를 게 없었습니다.

바로 이런 문제를 해결하기 위해 피드백 루프가 등장했습니다. 피드백 루프를 구현하면 AI가 점진적으로 개선됩니다.

처음에는 승인 요청이 많지만, 시간이 지날수록 AI가 패턴을 학습해서 요청이 줄어듭니다. 또한 사람의 판단 기준을 AI가 이해하게 됩니다.

"아, 이런 상황에서는 승인하고, 저런 상황에서는 거부하는구나." 무엇보다 자동화 수준이 높아진다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 FeedbackLoop 클래스는 피드백 이력을 JSON 파일에 저장합니다. _load_feedback 메서드로 기존 피드백을 불러오고, 없으면 빈 리스트를 반환합니다.

collect_feedback 메서드는 핵심입니다. 작업, AI의 결정, 승인 여부, 그리고 이유를 함께 저장합니다.

이 이유가 AI의 학습 데이터가 됩니다. analyze_patterns 메서드는 피드백을 분석해서 승인율 같은 통계를 보여줍니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 콘텐츠 검수 시스템을 개발한다고 가정해봅시다.

AI가 부적절한 콘텐츠를 탐지하면 사람이 최종 검토합니다. 처음에는 AI가 오탐(false positive)을 많이 내지만, 사람이 "이건 괜찮아요"라고 피드백을 주면 AI가 학습합니다.

몇 달 후에는 AI의 정확도가 크게 향상되어 사람의 개입이 절반으로 줄어듭니다. 유튜브, 페이스북 같은 플랫폼이 이런 피드백 기반 학습 시스템을 사용합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 피드백만 수집하고 학습은 안 하는 것입니다.

데이터만 쌓이고 AI는 여전히 똑같은 실수를 반복합니다. 따라서 수집한 피드백을 주기적으로 분석하고, 그 결과를 AI 모델에 재학습시켜야 합니다.

또한 편향된 피드백도 조심해야 합니다. 한 사람의 의견만 계속 반영하면 AI가 편향될 수 있습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 이테크 씨의 조언을 들은 김개발 씨는 피드백 루프를 구현했습니다.

한 달 후, 팀장님이 웃으며 말했습니다. "승인 요청이 절반으로 줄었어요.

AI가 학습하고 있네요!" 피드백 루프를 제대로 구현하면 AI가 사람의 판단을 배우며 점점 자율적으로 성장합니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 피드백을 수집할 때 이유(reason)를 필수로 입력받으세요 - 이게 학습의 핵심입니다

피드백 데이터를 주기적으로(주 1회, 월 1회) 분석하고 AI 모델을 재학습시키세요
여러 사람의 피드백을 균형있게 수집해서 편향을 방지하세요

4. 실습 HITL 시스템

김개발 씨는 이제 이론을 충분히 배웠습니다. "그런데 실제로 어떻게 만들죠?" 선배 이테크 씨가 노트북을 펼치며 말했습니다.

"직접 만들어 보면 금방 이해할 거예요. 간단한 HITL 시스템을 함께 구현해 봅시다."

HITL 시스템 실습은 앞서 배운 개입 지점, 승인 워크플로, 피드백 루프를 하나로 통합한 완전한 시스템을 직접 구현해 보는 과정입니다. 마치 레고 블록을 조립하듯이, 각 구성 요소를 결합해서 실제로 작동하는 AI 에이전트를 만듭니다.

이를 통해 이론과 실무의 간격을 좁히고 진짜 사용할 수 있는 시스템을 경험할 수 있습니다.

다음 코드를 살펴봅시다.

# 완전한 HITL 시스템 통합 예제
class HITLSystem:
    def __init__(self, approvers, risk_threshold=0.7):
        self.workflow = ApprovalWorkflow(approvers)
        self.feedback = FeedbackLoop()
        self.risk_threshold = risk_threshold

    def execute_with_approval(self, task, risk_score):
        # 1단계: 위험도 평가
        if risk_score <= self.risk_threshold:
            return self._execute_task(task)

        # 2단계: 승인 요청
        print(f"\n[HITL] 작업 '{task}'의 위험도: {risk_score}")
        status = self.workflow.request_approval(task)

        # 3단계: 피드백 수집
        if status == ApprovalStatus.APPROVED:
            reason = input("승인 이유를 입력하세요: ")
            self.feedback.collect_feedback(task, "execute", True, reason)
            return self._execute_task(task)
        elif status == ApprovalStatus.REJECTED:
            reason = input("거부 이유를 입력하세요: ")
            self.feedback.collect_feedback(task, "execute", False, reason)
            return "작업이 거부되었습니다."
        else:
            return "승인 대기 중입니다."

    def _execute_task(self, task):
        return f"✓ '{task}' 작업을 완료했습니다."

    def show_statistics(self):
        # 4단계: 통계 확인
        return self.feedback.analyze_patterns()

# 사용 예시
hitl = HITLSystem(approvers=["박팀장", "이부장"], risk_threshold=0.6)
result = hitl.execute_with_approval("고객 데이터 삭제", risk_score=0.8)
print(result)
print(hitl.show_statistics())

김개발 씨는 지금까지 개입 지점, 승인 워크플로, 피드백 루프를 각각 배웠습니다. 하지만 머릿속에서 퍼즐이 완전히 맞춰지지 않았습니다.

"이걸 어떻게 하나로 합치죠?" 선배 이테크 씨가 웃으며 말했습니다. "각 부품을 따로 보면 복잡해 보이지만, 실제로 조립하면 생각보다 간단해요.

마치 자동차를 처음 볼 때는 복잡해 보이지만, 엔진, 바퀴, 핸들이 어떻게 연결되는지 이해하면 전체가 보이는 것처럼요." 이테크 씨가 코드를 작성하기 시작했습니다. 김개발 씨는 옆에서 집중해서 지켜봤습니다.

HITL 시스템 통합이란 정확히 무엇일까요? 쉽게 비유하자면, HITL 시스템 통합은 마치 스마트홈 시스템을 만드는 것과 같습니다.

온도 센서, 조명 스위치, 보안 카메라가 각각 따로 있을 때는 불편합니다. 하지만 이들을 하나의 앱으로 통합하면 집 전체를 손쉽게 제어할 수 있습니다.

이처럼 HITL 시스템도 여러 구성 요소를 하나의 흐름으로 연결합니다. 각 부품을 따로 구현했던 초기 개발 방식은 어땠을까요?

개발자들은 위험도 평가 모듈, 승인 모듈, 피드백 모듈을 각각 만들었습니다. 각자는 잘 작동했지만, 문제는 연결이 어렵다는 점이었습니다.

모듈 간 데이터를 주고받으려면 복잡한 코드를 작성해야 했습니다. 더 큰 문제는 유지보수였습니다.

하나를 수정하면 다른 것들도 영향을 받았습니다. 바로 이런 문제를 해결하기 위해 통합 HITL 시스템이 등장했습니다.

통합 시스템을 만들면 코드가 깔끔해집니다. 모든 로직이 하나의 클래스에 체계적으로 정리됩니다.

또한 흐름이 명확해집니다. 위험도 평가 → 승인 요청 → 피드백 수집 → 실행이라는 단계가 한눈에 보입니다.

무엇보다 재사용성이라는 큰 이점이 있습니다. 한 번 만들어 두면 어디서든 쓸 수 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. HITLSystem 클래스는 세 가지 핵심 구성 요소를 포함합니다.

ApprovalWorkflow로 승인 경로를 관리하고, FeedbackLoop로 피드백을 수집하고, risk_threshold로 개입 지점을 설정합니다. execute_with_approval 메서드가 전체 흐름을 제어합니다.

먼저 위험도를 확인하고, 임계값을 넘으면 승인을 요청하고, 결과에 따라 피드백을 수집합니다. 마지막으로 show_statistics로 시스템 성능을 모니터링합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 마케팅 자동화 플랫폼을 개발한다고 가정해봅시다.

AI가 이메일 캠페인을 자동으로 발송하는데, 10,000명 이상에게 보내는 캠페인은 위험도가 높습니다. HITL 시스템을 구현하면 이런 대규모 캠페인은 자동으로 마케팅 팀장에게 승인을 요청합니다.

팀장이 승인하면서 "타겟팅이 정확함"이라고 피드백을 주면, AI는 이 패턴을 학습합니다. 몇 달 후에는 비슷한 타겟팅의 캠페인은 자동으로 처리할 수 있게 됩니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 복잡하게 만드는 것입니다.

처음부터 완벽한 시스템을 만들려고 하면 오히려 실패하기 쉽습니다. 따라서 간단하게 시작해서 점진적으로 개선하는 것이 좋습니다.

먼저 기본 기능만 구현하고, 실제로 사용해 보면서 필요한 기능을 추가하세요. 다시 김개발 씨의 이야기로 돌아가 봅시다.

이테크 씨의 코드를 보며 김개발 씨는 감탄했습니다. "와, 생각보다 간단하네요!

각 부품을 따로 만들 때는 복잡해 보였는데, 이렇게 조립하니 깔끔하네요." HITL 시스템을 직접 만들어 보면 이론으로만 배울 때보다 훨씬 깊이 이해할 수 있습니다. 여러분도 오늘 배운 코드를 직접 실행해 보세요.

실전 팁

💡 - 처음에는 간단하게 시작하세요 - 기본 기능만 구현하고 점진적으로 확장하세요

각 단계(위험도 평가, 승인, 피드백)를 독립적인 메서드로 분리하면 테스트와 유지보수가 쉽습니다
로그를 남기세요 - 시스템의 모든 결정과 승인 과정을 기록하면 문제 해결이 쉽습니다

5. 실습 인터랙티브 에이전트

김개발 씨는 기본 HITL 시스템을 성공적으로 만들었습니다. 하지만 팀장님이 새로운 요구사항을 제시했습니다.

"AI가 단순히 승인만 받는 게 아니라, 사용자와 대화하면서 더 나은 결정을 내리면 어떨까요?" 김개발 씨는 고개를 끄덕였습니다. "인터랙티브 에이전트를 만들어야겠네요!"

인터랙티브 에이전트는 단방향 승인 요청을 넘어서, 사용자와 양방향 대화를 통해 더 나은 결정을 내리는 AI 시스템입니다. 마치 의사가 환자와 대화하며 증상을 파악하듯이, AI도 사용자에게 질문하고 답변을 받아 맥락을 이해합니다.

이를 통해 단순한 승인/거부를 넘어 협업적 의사결정이 가능해집니다.

다음 코드를 살펴봅시다.

# 사용자와 대화하는 인터랙티브 에이전트
class InteractiveAgent:
    def __init__(self, name="AI Assistant"):
        self.name = name
        self.context = {}

    def ask_clarification(self, question):
        # 사용자에게 추가 정보를 요청합니다
        print(f"\n[{self.name}] {question}")
        response = input("답변: ")
        return response

    def execute_with_interaction(self, task, initial_plan):
        print(f"\n[{self.name}] '{task}' 작업을 수행하려 합니다.")
        print(f"초기 계획: {initial_plan}")

        # 사용자와 대화하며 맥락을 수집합니다
        self.context['urgency'] = self.ask_clarification(
            "이 작업의 긴급도는? (낮음/보통/높음)"
        )

        self.context['impact'] = self.ask_clarification(
            "예상되는 영향 범위는? (작음/중간/큼)"
        )

        # 수집한 정보로 위험도를 재평가합니다
        risk = self._calculate_risk(self.context)
        print(f"\n[{self.name}] 분석 결과:")
        print(f"  - 긴급도: {self.context['urgency']}")
        print(f"  - 영향 범위: {self.context['impact']}")
        print(f"  - 계산된 위험도: {risk}")

        # 사용자에게 최종 확인을 요청합니다
        confirm = self.ask_clarification("이대로 진행할까요? (yes/no)")

        if confirm.lower() == 'yes':
            return f"✓ '{task}' 작업을 실행했습니다."
        else:
            alternative = self.ask_clarification("대안이 있다면 제안해주세요:")
            return f"작업이 취소되었습니다. 대안: {alternative}"

    def _calculate_risk(self, context):
        # 간단한 위험도 계산 로직
        risk_map = {'낮음': 0.2, '보통': 0.5, '높음': 0.8,
                    '작음': 0.2, '중간': 0.5, '큼': 0.8}
        urgency_risk = risk_map.get(context.get('urgency', '보통'), 0.5)
        impact_risk = risk_map.get(context.get('impact', '중간'), 0.5)
        return (urgency_risk + impact_risk) / 2

# 사용 예시
agent = InteractiveAgent("SmartBot")
result = agent.execute_with_interaction(
    "프로덕션 데이터베이스 마이그레이션",
    "스키마 변경 후 데이터 이관"
)
print(result)

김개발 씨의 HITL 시스템은 잘 작동했습니다. AI가 위험한 작업을 하기 전에 승인을 받고, 피드백을 학습했습니다.

그런데 며칠 사용해 보니 아쉬운 점이 있었습니다. 어느 날 AI가 "데이터베이스 백업" 작업에 대해 승인을 요청했습니다.

팀장 박시니어 씨는 고민했습니다. "이게 긴급한 백업인가?

아니면 정기 백업인가? 영향 범위는 어느 정도지?" AI는 단순히 승인만 요청했을 뿐, 맥락 정보를 제공하지 않았습니다.

박시니어 씨가 김개발 씨에게 말했습니다. "AI가 좀 더 똑똑하게 질문하면 좋겠어요.

마치 사람처럼 대화하면서 상황을 파악하는 거죠." 인터랙티브 에이전트란 정확히 무엇일까요? 쉽게 비유하자면, 인터랙티브 에이전트는 마치 숙련된 의사와 같습니다.

환자가 "배가 아파요"라고 하면 의사는 "언제부터 아팠나요? 어디가 아픈가요?

다른 증상은요?"라고 질문하며 정확한 진단을 내립니다. 이처럼 AI도 능동적으로 질문하며 상황을 이해합니다.

단순한 승인 요청만 하던 초기 시스템은 어땠을까요? AI는 "이 작업을 해도 될까요?"라고만 물었습니다.

사용자는 제한된 정보만으로 판단해야 했습니다. 문제는 맥락이 부족하다는 점이었습니다.

왜 이 작업이 필요한지, 영향 범위는 어떤지, 대안은 무엇인지 알 수 없었습니다. 더 큰 문제는 오판 가능성이었습니다.

정보가 부족하면 잘못된 결정을 내리기 쉽습니다. 바로 이런 문제를 해결하기 위해 인터랙티브 에이전트가 등장했습니다.

인터랙티브 에이전트를 사용하면 맥락 기반 의사결정이 가능해집니다. AI가 충분한 정보를 수집한 후 판단하므로 정확도가 높아집니다.

또한 사용자 참여가 증가합니다. 단순히 승인/거부를 누르는 게 아니라 대화에 참여하면서 더 관여하게 됩니다.

무엇보다 신뢰도 향상이라는 큰 이점이 있습니다. AI가 왜 이런 질문을 하는지 이해하면 시스템을 더 신뢰하게 됩니다.

위의 코드를 한 줄씩 살펴보겠습니다. InteractiveAgent 클래스는 context 딕셔너리로 대화 맥락을 저장합니다.

ask_clarification 메서드는 사용자에게 질문을 던지고 답변을 받습니다. 핵심은 execute_with_interaction 메서드입니다.

여기서 AI는 긴급도, 영향 범위 등을 능동적으로 질문합니다. 수집한 정보로 _calculate_risk를 호출해 위험도를 재계산합니다.

마지막으로 최종 확인을 받아 실행 여부를 결정합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 클라우드 인프라 관리 시스템을 개발한다고 가정해봅시다. AI가 서버를 추가하려고 할 때, 단순히 "서버를 추가할까요?"라고 묻는 대신 이렇게 대화합니다.

"어떤 워크로드를 위한 서버인가요? 예상 트래픽은?

비용 한도는?" 이런 정보를 바탕으로 AI는 최적의 서버 스펙을 제안하고, 사용자는 더 정보에 기반한 결정을 내릴 수 있습니다. AWS, Azure 같은 클라우드 플랫폼의 AI 어드바이저가 이런 방식을 사용합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 많이 묻는 것입니다.

10개, 20개의 질문을 던지면 사용자가 피로해집니다. 따라서 핵심 질문 3-5개로 제한하는 것이 좋습니다.

또한 질문의 순서도 중요합니다. 가장 중요한 질문부터 시작해서 점진적으로 세부 사항을 물어봐야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 요청을 받은 김개발 씨는 인터랙티브 에이전트를 구현했습니다.

일주일 후, 박시니어 씨가 만족스럽게 말했습니다. "이제 AI가 맥락을 이해하고 대화하니 훨씬 좋네요.

마치 똑똑한 동료와 일하는 것 같아요." 인터랙티브 에이전트를 제대로 만들면 AI가 단순한 도구를 넘어 진짜 협업 파트너가 됩니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 질문은 3-5개로 제한하세요 - 너무 많으면 사용자가 피곤해합니다

중요한 질문부터 시작해서 점진적으로 세부 사항을 물어보세요
사용자의 답변을 저장해서 다음번에는 더 스마트하게 질문하세요 (학습하는 대화)

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Python#HITL#AI에이전트#승인워크플로우#피드백루프#LLM,HITL,에이전트

Human-in-the-Loop Agents 완벽 가이드

# Human-in-the-Loop Agents 완벽 가이드 AI 에이전트가 중요한 결정을 내리기 전에 사람의 승인을 받는 시스템을 구축하는 방법을 배웁니다. 실무에서 안전하고 신뢰할 수 있는 AI 에이전트를 만드는 핵심 패턴을 소개합니다. --- ## 목차 1. [인간_개입_지점_설정](#인간-개입-지점-설정) 2. [승인_워크플로](#승인-워크플로) 3. [피드백_루프](#피드백-루프) 4. [실습_HITL_시스템](#실습-hitl-시스템) 5. [실습_인터랙티브_에이전트](#실습-인터랙티브-에이전트) --- ## 1. 인간_개입_지점_설정 어느 날 김개발 씨는 회사에서 AI 에이전트를 활용한 자동화 시스템을 만들었습니다. 그런데 팀장님이 걱정스러운 표정으로 다가왔습니다. "이 AI가 실수로 중요한 데이터를 삭제하면 어떡하지요? 사람이 확인할 수 있는 장치가 필요해요." **인간 개입 지점**이란 AI 에이전트가 중요한 작업을 수행하기 전에 사람의 확인이나 승인을 받도록 설정한 지점입니다. 마치 은행에서 큰 금액을 이체할 때 관리자 승인이 필요한 것처럼, AI도 위험도가 높은 작업에서는 사람의 판단을 구해야 합니다. 이를 통해 AI의 효율성과 사람의 판단력을 조화롭게 결합할 수 있습니다. 다음 코드를 살펴봅시다. ```python # 인간 개입 지점을 설정하는 기본 패턴 class HumanApprovalAgent: def __init__(self, risk_threshold=0.7): self.risk_threshold = risk_threshold def execute_task(self, task, risk_score): # 위험도가 임계값을 넘으면 사람의 승인을 요청합니다 if risk_score > self.risk_threshold: print(f"작업 '{task}'의 위험도가 {risk_score}입니다.") approval = input("승인하시겠습니까? (yes/no): ") if approval.lower() != 'yes': return "작업이 거부되었습니다." # 승인되거나 위험도가 낮으면 작업을 실행합니다 return self._perform_task(task) def _perform_task(self, task): return f"'{task}' 작업을 실행했습니다." ``` 김개발 씨는 입사 6개월 차 개발자입니다. 최근 회사에서 AI 에이전트를 활용해 고객 문의를 자동으로 처리하는 시스템을 개발했습니다. 처음에는 모든 것이 순조로웠습니다. AI가 빠르게 답변하고, 고객들도 만족했습니다. 그런데 어느 날 큰 문제가 발생했습니다. AI 에이전트가 실수로 중요한 고객 데이터를 삭제하려는 명령을 실행하려 했던 것입니다. 다행히 직원이 재빨리 발견해서 막았지만, 만약 늦었다면 큰 사고가 날 뻔했습니다. 팀장 박시니어 씨가 김개발 씨를 불렀습니다. "김 대리, AI가 아무리 똑똑해도 100% 믿을 수는 없어요. 중요한 작업에서는 사람이 확인해야 합니다." **인간 개입 지점**이란 정확히 무엇일까요? 쉽게 비유하자면, 인간 개입 지점은 마치 **자동차의 브레이크**와 같습니다. 차가 아무리 빨리 달려도 위험한 순간에는 운전자가 브레이크를 밟아 멈출 수 있어야 합니다. 이처럼 AI 에이전트도 중요한 순간에 사람이 개입할 수 있는 장치가 필요합니다. 인간 개입 지점이 없던 초기 AI 시스템은 어땠을까요? 개발자들은 AI가 모든 작업을 자동으로 처리하도록 만들었습니다. 효율적이었지만, 문제는 **AI가 실수할 때**였습니다. 잘못된 데이터를 학습하거나, 예상치 못한 상황을 만나면 AI는 엉뚱한 결정을 내렸습니다. 더 큰 문제는 이런 실수를 **사후에야 발견**한다는 점이었습니다. 돌이킬 수 없는 피해가 이미 발생한 후였습니다. 바로 이런 문제를 해결하기 위해 **Human-in-the-Loop** 패턴이 등장했습니다. 인간 개입 지점을 설정하면 **위험한 작업을 사전에 차단**할 수 있습니다. 또한 AI의 결정 과정을 **사람이 검토**할 수 있어 투명성이 높아집니다. 무엇보다 **AI와 사람의 협업**이라는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 `risk_threshold`는 어느 정도 위험부터 사람의 승인을 받을지 정하는 **임계값**입니다. 예를 들어 0.7이면 위험도가 70%를 넘는 작업에서 승인을 요청합니다. `execute_task` 메서드에서는 작업의 위험도를 평가합니다. 만약 위험도가 임계값을 넘으면 `input()` 함수로 사용자에게 승인을 요청합니다. 사용자가 "yes"를 입력하면 작업을 진행하고, 그렇지 않으면 작업을 거부합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 이커머스 플랫폼을 개발한다고 가정해봅시다. AI 에이전트가 재고를 자동으로 관리하는데, 100만 원 이상의 주문이나 대량 환불 요청은 위험도가 높습니다. 이럴 때 **인간 개입 지점**을 설정해서 관리자가 직접 확인하도록 만들 수 있습니다. 아마존, 구글 같은 글로벌 기업들도 이런 패턴을 적극 활용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **모든 작업에 승인을 요청**하는 것입니다. 이렇게 하면 사람이 너무 자주 개입해야 해서 오히려 비효율적입니다. 따라서 **위험도를 정확히 평가**해서 정말 필요한 순간에만 개입 지점을 설정해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언을 들은 김개발 씨는 시스템에 인간 개입 지점을 추가했습니다. "이제 중요한 작업은 팀장님이 확인하시니 안심이네요!" 인간 개입 지점을 제대로 설정하면 AI의 효율성과 사람의 판단력을 모두 활용할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 위험도 평가 기준을 명확히 정의하세요 (금액, 데이터 중요도, 영향 범위 등) - 승인 요청 메시지에 충분한 컨텍스트를 포함하세요 (무엇을, 왜, 언제) - 너무 많은 승인 요청은 오히려 피로도를 높이니 적절한 임계값을 찾으세요 --- ## 2. 승인_워크플로 김개발 씨는 인간 개입 지점을 성공적으로 구현했습니다. 하지만 새로운 문제가 생겼습니다. "팀장님이 자리를 비우셨는데 긴급한 승인이 필요하면 어떻게 하죠?" 선배 이테크 씨가 웃으며 말했습니다. "그래서 승인 워크플로가 필요한 거예요." **승인 워크플로**는 AI 에이전트의 작업 승인 요청이 어떤 경로로 전달되고 처리되는지 정의한 프로세스입니다. 마치 회사에서 결재 라인이 있는 것처럼, 1차 승인자가 없으면 2차 승인자에게 자동으로 넘어가는 체계를 만듭니다. 이를 통해 승인이 필요한 순간에도 시스템이 멈추지 않고 원활하게 작동할 수 있습니다. 다음 코드를 살펴봅시다. ```python # 다단계 승인 워크플로우 구현 from enum import Enum from typing import List, Optional class ApprovalStatus(Enum): PENDING = "대기중" APPROVED = "승인됨" REJECTED = "거부됨" class ApprovalWorkflow: def __init__(self, approvers: List[str]): # 승인자 목록 (순서대로 시도) self.approvers = approvers self.current_index = 0 def request_approval(self, task: str) -> ApprovalStatus: # 승인자 목록을 순회하며 승인 요청 while self.current_index < len(self.approvers): approver = self.approvers[self.current_index] print(f"{approver}님께 승인 요청: {task}") # 실제로는 이메일, 슬랙 등으로 알림을 보냅니다 response = input(f"{approver}님의 응답 (approve/reject/unavailable): ") if response == "approve": return ApprovalStatus.APPROVED elif response == "reject": return ApprovalStatus.REJECTED else: # 승인자가 부재중이면 다음 승인자에게 print(f"{approver}님이 부재중입니다. 다음 승인자에게 전달합니다.") self.current_index += 1 # 모든 승인자가 부재중이면 대기 상태로 return ApprovalStatus.PENDING ``` 김개발 씨가 만든 시스템은 잘 작동했습니다. AI가 중요한 작업을 하려 할 때마다 팀장님에게 승인을 요청했습니다. 그런데 어느 금요일 오후, 문제가 발생했습니다. 팀장 박시니어 씨가 외부 미팅으로 자리를 비웠습니다. 그런데 바로 그때 긴급한 고객 요청이 들어왔고, AI는 승인을 기다리며 멈춰 있었습니다. 고객은 "왜 이렇게 오래 걸리나요?"라며 불만을 터뜨렸습니다. 선배 이테크 씨가 상황을 보고 김개발 씨에게 조언했습니다. "단일 승인자만 의존하면 이런 일이 생기죠. 승인 워크플로를 만들어야 해요." **승인 워크플로**란 정확히 무엇일까요? 쉽게 비유하자면, 승인 워크플로는 마치 **우체국의 배달 시스템**과 같습니다. 우편물을 받을 사람이 집에 없으면 이웃이나 관리실에 맡기듯이, 1차 승인자가 없으면 자동으로 2차, 3차 승인자에게 요청이 전달됩니다. 이처럼 승인 워크플로도 **여러 경로**를 통해 승인을 받을 수 있게 합니다. 단일 승인자만 있던 초기 시스템은 어땠을까요? 개발자들은 보통 한 명의 관리자를 지정해서 모든 승인을 받도록 만들었습니다. 간단하고 명확했지만, 문제는 **그 사람이 없을 때**였습니다. 휴가, 출장, 회의 등으로 자리를 비우면 시스템이 멈췄습니다. 더 큰 문제는 **긴급한 상황**에서도 대응할 수 없다는 점이었습니다. 바로 이런 문제를 해결하기 위해 **다단계 승인 워크플로**가 등장했습니다. 승인 워크플로를 사용하면 **업무 연속성**을 보장할 수 있습니다. 한 명이 부재중이어도 다른 사람이 대신 승인할 수 있습니다. 또한 **역할 기반 승인**도 가능합니다. 예를 들어 금액에 따라 팀장, 부장, 임원 순으로 승인 권한을 다르게 설정할 수 있습니다. 무엇보다 **유연성**이라는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 `ApprovalStatus` 열거형으로 승인 상태를 명확히 정의합니다. `ApprovalWorkflow` 클래스는 승인자 목록을 받아서 순서대로 저장합니다. `request_approval` 메서드에서는 while 루프로 승인자 목록을 순회합니다. 각 승인자에게 요청을 보내고, "approve"면 즉시 승인됨을 반환하고, "unavailable"이면 다음 승인자로 넘어갑니다. 모든 승인자가 부재중이면 대기 상태를 반환합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 금융 서비스를 개발한다고 가정해봅시다. 10만 원 이하는 팀장 승인, 100만 원 이하는 부장 승인, 그 이상은 임원 승인이 필요합니다. 승인 워크플로를 만들면 금액에 따라 자동으로 적절한 승인자에게 요청을 보낼 수 있습니다. 대형 은행들은 이런 **계층적 승인 시스템**을 필수로 사용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **승인자를 너무 많이 추가**하는 것입니다. 10명의 승인자를 등록하면 복잡해지고 관리하기 어렵습니다. 따라서 **2-3명의 핵심 승인자**만 지정하는 것이 좋습니다. 또한 **타임아웃 설정**도 중요합니다. 승인자가 24시간 이상 응답하지 않으면 자동으로 다음 단계로 넘어가도록 만들어야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 이테크 씨의 조언을 들은 김개발 씨는 승인 워크플로를 구현했습니다. "이제 팀장님이 자리를 비워도 부팀장님이 대신 승인할 수 있네요!" 승인 워크플로를 제대로 설계하면 시스템의 안정성과 유연성을 동시에 확보할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 승인자는 2-3명으로 제한하고, 역할과 권한을 명확히 정의하세요 - 타임아웃을 설정해서 승인자가 응답하지 않으면 자동으로 다음 단계로 넘어가게 하세요 - 승인 이력을 로그로 남겨서 나중에 감사(audit)할 수 있게 하세요 --- ## 3. 피드백_루프 김개발 씨의 시스템은 이제 안정적으로 작동했습니다. 그런데 팀장 박시니어 씨가 한 가지를 더 제안했습니다. "승인만 받고 끝나는 게 아니라, 사람의 피드백을 AI가 학습하면 어떨까요?" 김개발 씨는 눈이 반짝였습니다. "그럼 AI가 점점 똑똑해지겠네요!" **피드백 루프**는 사람이 AI의 결정을 승인하거나 거부할 때 그 이유와 피드백을 함께 기록하고, AI가 이를 학습해서 다음번에는 더 나은 결정을 내리도록 하는 메커니즘입니다. 마치 학생이 시험을 보고 선생님의 피드백을 받아 실력이 향상되는 것처럼, AI도 사람의 판단을 배우며 성장합니다. 이를 통해 시간이 지날수록 사람의 개입이 줄어들고 AI의 자율성이 높아집니다. 다음 코드를 살펴봅시다. ```python # 피드백 루프를 구현한 학습형 에이전트 import json from datetime import datetime class FeedbackLoop: def __init__(self, feedback_file="feedback_history.json"): self.feedback_file = feedback_file self.feedback_history = self._load_feedback() def _load_feedback(self): # 기존 피드백 이력을 불러옵니다 try: with open(self.feedback_file, 'r', encoding='utf-8') as f: return json.load(f) except FileNotFoundError: return [] def collect_feedback(self, task, decision, approved, reason): # 피드백을 수집하고 저장합니다 feedback = { "timestamp": datetime.now().isoformat(), "task": task, "ai_decision": decision, "approved": approved, "reason": reason } self.feedback_history.append(feedback) # 파일에 저장합니다 with open(self.feedback_file, 'w', encoding='utf-8') as f: json.dump(self.feedback_history, f, ensure_ascii=False, indent=2) return feedback def analyze_patterns(self): # 피드백 패턴을 분석합니다 if not self.feedback_history: return "피드백 데이터가 부족합니다." total = len(self.feedback_history) approved = sum(1 for fb in self.feedback_history if fb['approved']) approval_rate = (approved / total) * 100 return f"승인율: {approval_rate:.1f}% ({approved}/{total})" ``` 김개발 씨의 시스템은 이제 제법 안정적이었습니다. AI가 중요한 작업을 하기 전에 승인을 받고, 승인자가 부재중이면 다른 사람에게 자동으로 넘어갔습니다. 모든 게 순조로웠습니다. 그런데 한 달쯤 지나자 팀장 박시니어 씨가 피곤한 표정을 지었습니다. "매일 똑같은 종류의 승인 요청이 오네요. AI가 학습을 못 하는 건가요?" 김개발 씨도 로그를 확인해 보니 그랬습니다. AI는 비슷한 상황에서도 매번 사람에게 물어봤습니다. 이전에 승인받았던 것과 거의 동일한 케이스인데도 말이죠. 선배 이테크 씨가 다가와 말했습니다. "피드백 루프가 없어서 그래요. AI가 과거의 승인 결정을 학습하지 못하고 있어요." **피드백 루프**란 정확히 무엇일까요? 쉽게 비유하자면, 피드백 루프는 마치 **운전 학원의 교육 시스템**과 같습니다. 학생이 운전 실수를 하면 교관이 왜 틀렸는지 설명하고, 학생은 그걸 기억해서 다음번에는 같은 실수를 하지 않습니다. 이처럼 AI도 사람의 **승인/거부 결정**과 **그 이유**를 배우며 점점 똑똑해집니다. 피드백 루프가 없던 초기 AI 시스템은 어땠을까요? AI는 매번 같은 질문을 반복했습니다. 사람이 "이건 승인해"라고 했어도, 다음에 똑같은 상황이 오면 또 물어봤습니다. **학습 능력이 없었기 때문**입니다. 더 큰 문제는 사람의 **피로도가 계속 증가**한다는 점이었습니다. 아무리 똑똑한 AI라도 학습하지 못하면 단순한 규칙 기반 시스템과 다를 게 없었습니다. 바로 이런 문제를 해결하기 위해 **피드백 루프**가 등장했습니다. 피드백 루프를 구현하면 AI가 **점진적으로 개선**됩니다. 처음에는 승인 요청이 많지만, 시간이 지날수록 AI가 패턴을 학습해서 요청이 줄어듭니다. 또한 **사람의 판단 기준**을 AI가 이해하게 됩니다. "아, 이런 상황에서는 승인하고, 저런 상황에서는 거부하는구나." 무엇보다 **자동화 수준이 높아진다**는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 `FeedbackLoop` 클래스는 피드백 이력을 JSON 파일에 저장합니다. `_load_feedback` 메서드로 기존 피드백을 불러오고, 없으면 빈 리스트를 반환합니다. `collect_feedback` 메서드는 핵심입니다. 작업, AI의 결정, 승인 여부, 그리고 **이유**를 함께 저장합니다. 이 이유가 AI의 학습 데이터가 됩니다. `analyze_patterns` 메서드는 피드백을 분석해서 승인율 같은 통계를 보여줍니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 콘텐츠 검수 시스템을 개발한다고 가정해봅시다. AI가 부적절한 콘텐츠를 탐지하면 사람이 최종 검토합니다. 처음에는 AI가 오탐(false positive)을 많이 내지만, 사람이 "이건 괜찮아요"라고 피드백을 주면 AI가 학습합니다. 몇 달 후에는 AI의 정확도가 크게 향상되어 사람의 개입이 절반으로 줄어듭니다. 유튜브, 페이스북 같은 플랫폼이 이런 **피드백 기반 학습 시스템**을 사용합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **피드백만 수집하고 학습은 안 하는 것**입니다. 데이터만 쌓이고 AI는 여전히 똑같은 실수를 반복합니다. 따라서 수집한 피드백을 **주기적으로 분석**하고, 그 결과를 AI 모델에 **재학습**시켜야 합니다. 또한 **편향된 피드백**도 조심해야 합니다. 한 사람의 의견만 계속 반영하면 AI가 편향될 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 이테크 씨의 조언을 들은 김개발 씨는 피드백 루프를 구현했습니다. 한 달 후, 팀장님이 웃으며 말했습니다. "승인 요청이 절반으로 줄었어요. AI가 학습하고 있네요!" 피드백 루프를 제대로 구현하면 AI가 사람의 판단을 배우며 점점 자율적으로 성장합니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 피드백을 수집할 때 이유(reason)를 필수로 입력받으세요 - 이게 학습의 핵심입니다 - 피드백 데이터를 주기적으로(주 1회, 월 1회) 분석하고 AI 모델을 재학습시키세요 - 여러 사람의 피드백을 균형있게 수집해서 편향을 방지하세요 --- ## 4. 실습_HITL_시스템 김개발 씨는 이제 이론을 충분히 배웠습니다. "그런데 실제로 어떻게 만들죠?" 선배 이테크 씨가 노트북을 펼치며 말했습니다. "직접 만들어 보면 금방 이해할 거예요. 간단한 HITL 시스템을 함께 구현해 봅시다." **HITL 시스템 실습**은 앞서 배운 개입 지점, 승인 워크플로, 피드백 루프를 하나로 통합한 완전한 시스템을 직접 구현해 보는 과정입니다. 마치 레고 블록을 조립하듯이, 각 구성 요소를 결합해서 실제로 작동하는 AI 에이전트를 만듭니다. 이를 통해 이론과 실무의 간격을 좁히고 진짜 사용할 수 있는 시스템을 경험할 수 있습니다. 다음 코드를 살펴봅시다. ```python # 완전한 HITL 시스템 통합 예제 class HITLSystem: def __init__(self, approvers, risk_threshold=0.7): self.workflow = ApprovalWorkflow(approvers) self.feedback = FeedbackLoop() self.risk_threshold = risk_threshold def execute_with_approval(self, task, risk_score): # 1단계: 위험도 평가 if risk_score <= self.risk_threshold: return self._execute_task(task) # 2단계: 승인 요청 print(f"\n[HITL] 작업 '{task}'의 위험도: {risk_score}") status = self.workflow.request_approval(task) # 3단계: 피드백 수집 if status == ApprovalStatus.APPROVED: reason = input("승인 이유를 입력하세요: ") self.feedback.collect_feedback(task, "execute", True, reason) return self._execute_task(task) elif status == ApprovalStatus.REJECTED: reason = input("거부 이유를 입력하세요: ") self.feedback.collect_feedback(task, "execute", False, reason) return "작업이 거부되었습니다." else: return "승인 대기 중입니다." def _execute_task(self, task): return f"✓ '{task}' 작업을 완료했습니다." def show_statistics(self): # 4단계: 통계 확인 return self.feedback.analyze_patterns() # 사용 예시 hitl = HITLSystem(approvers=["박팀장", "이부장"], risk_threshold=0.6) result = hitl.execute_with_approval("고객 데이터 삭제", risk_score=0.8) print(result) print(hitl.show_statistics()) ``` 김개발 씨는 지금까지 개입 지점, 승인 워크플로, 피드백 루프를 각각 배웠습니다. 하지만 머릿속에서 퍼즐이 완전히 맞춰지지 않았습니다. "이걸 어떻게 하나로 합치죠?" 선배 이테크 씨가 웃으며 말했습니다. "각 부품을 따로 보면 복잡해 보이지만, 실제로 조립하면 생각보다 간단해요. 마치 자동차를 처음 볼 때는 복잡해 보이지만, 엔진, 바퀴, 핸들이 어떻게 연결되는지 이해하면 전체가 보이는 것처럼요." 이테크 씨가 코드를 작성하기 시작했습니다. 김개발 씨는 옆에서 집중해서 지켜봤습니다. **HITL 시스템 통합**이란 정확히 무엇일까요? 쉽게 비유하자면, HITL 시스템 통합은 마치 **스마트홈 시스템**을 만드는 것과 같습니다. 온도 센서, 조명 스위치, 보안 카메라가 각각 따로 있을 때는 불편합니다. 하지만 이들을 하나의 앱으로 통합하면 집 전체를 손쉽게 제어할 수 있습니다. 이처럼 HITL 시스템도 여러 구성 요소를 **하나의 흐름**으로 연결합니다. 각 부품을 따로 구현했던 초기 개발 방식은 어땠을까요? 개발자들은 위험도 평가 모듈, 승인 모듈, 피드백 모듈을 각각 만들었습니다. 각자는 잘 작동했지만, 문제는 **연결이 어렵다**는 점이었습니다. 모듈 간 데이터를 주고받으려면 복잡한 코드를 작성해야 했습니다. 더 큰 문제는 **유지보수**였습니다. 하나를 수정하면 다른 것들도 영향을 받았습니다. 바로 이런 문제를 해결하기 위해 **통합 HITL 시스템**이 등장했습니다. 통합 시스템을 만들면 **코드가 깔끔**해집니다. 모든 로직이 하나의 클래스에 체계적으로 정리됩니다. 또한 **흐름이 명확**해집니다. 위험도 평가 → 승인 요청 → 피드백 수집 → 실행이라는 단계가 한눈에 보입니다. 무엇보다 **재사용성**이라는 큰 이점이 있습니다. 한 번 만들어 두면 어디서든 쓸 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. `HITLSystem` 클래스는 세 가지 핵심 구성 요소를 포함합니다. `ApprovalWorkflow`로 승인 경로를 관리하고, `FeedbackLoop`로 피드백을 수집하고, `risk_threshold`로 개입 지점을 설정합니다. `execute_with_approval` 메서드가 전체 흐름을 제어합니다. 먼저 위험도를 확인하고, 임계값을 넘으면 승인을 요청하고, 결과에 따라 피드백을 수집합니다. 마지막으로 `show_statistics`로 시스템 성능을 모니터링합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 마케팅 자동화 플랫폼을 개발한다고 가정해봅시다. AI가 이메일 캠페인을 자동으로 발송하는데, 10,000명 이상에게 보내는 캠페인은 위험도가 높습니다. HITL 시스템을 구현하면 이런 대규모 캠페인은 자동으로 마케팅 팀장에게 승인을 요청합니다. 팀장이 승인하면서 "타겟팅이 정확함"이라고 피드백을 주면, AI는 이 패턴을 학습합니다. 몇 달 후에는 비슷한 타겟팅의 캠페인은 자동으로 처리할 수 있게 됩니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **너무 복잡하게 만드는 것**입니다. 처음부터 완벽한 시스템을 만들려고 하면 오히려 실패하기 쉽습니다. 따라서 **간단하게 시작**해서 점진적으로 개선하는 것이 좋습니다. 먼저 기본 기능만 구현하고, 실제로 사용해 보면서 필요한 기능을 추가하세요. 다시 김개발 씨의 이야기로 돌아가 봅시다. 이테크 씨의 코드를 보며 김개발 씨는 감탄했습니다. "와, 생각보다 간단하네요! 각 부품을 따로 만들 때는 복잡해 보였는데, 이렇게 조립하니 깔끔하네요." HITL 시스템을 직접 만들어 보면 이론으로만 배울 때보다 훨씬 깊이 이해할 수 있습니다. 여러분도 오늘 배운 코드를 직접 실행해 보세요. **실전 팁** 💡 - 처음에는 간단하게 시작하세요 - 기본 기능만 구현하고 점진적으로 확장하세요 - 각 단계(위험도 평가, 승인, 피드백)를 독립적인 메서드로 분리하면 테스트와 유지보수가 쉽습니다 - 로그를 남기세요 - 시스템의 모든 결정과 승인 과정을 기록하면 문제 해결이 쉽습니다 --- ## 5. 실습_인터랙티브_에이전트 김개발 씨는 기본 HITL 시스템을 성공적으로 만들었습니다. 하지만 팀장님이 새로운 요구사항을 제시했습니다. "AI가 단순히 승인만 받는 게 아니라, 사용자와 대화하면서 더 나은 결정을 내리면 어떨까요?" 김개발 씨는 고개를 끄덕였습니다. "인터랙티브 에이전트를 만들어야겠네요!" **인터랙티브 에이전트**는 단방향 승인 요청을 넘어서, 사용자와 양방향 대화를 통해 더 나은 결정을 내리는 AI 시스템입니다. 마치 의사가 환자와 대화하며 증상을 파악하듯이, AI도 사용자에게 질문하고 답변을 받아 맥락을 이해합니다. 이를 통해 단순한 승인/거부를 넘어 협업적 의사결정이 가능해집니다. 다음 코드를 살펴봅시다. ```python # 사용자와 대화하는 인터랙티브 에이전트 class InteractiveAgent: def __init__(self, name="AI Assistant"): self.name = name self.context = {} def ask_clarification(self, question): # 사용자에게 추가 정보를 요청합니다 print(f"\n[{self.name}] {question}") response = input("답변: ") return response def execute_with_interaction(self, task, initial_plan): print(f"\n[{self.name}] '{task}' 작업을 수행하려 합니다.") print(f"초기 계획: {initial_plan}") # 사용자와 대화하며 맥락을 수집합니다 self.context['urgency'] = self.ask_clarification( "이 작업의 긴급도는? (낮음/보통/높음)" ) self.context['impact'] = self.ask_clarification( "예상되는 영향 범위는? (작음/중간/큼)" ) # 수집한 정보로 위험도를 재평가합니다 risk = self._calculate_risk(self.context) print(f"\n[{self.name}] 분석 결과:") print(f" - 긴급도: {self.context['urgency']}") print(f" - 영향 범위: {self.context['impact']}") print(f" - 계산된 위험도: {risk}") # 사용자에게 최종 확인을 요청합니다 confirm = self.ask_clarification("이대로 진행할까요? (yes/no)") if confirm.lower() == 'yes': return f"✓ '{task}' 작업을 실행했습니다." else: alternative = self.ask_clarification("대안이 있다면 제안해주세요:") return f"작업이 취소되었습니다. 대안: {alternative}" def _calculate_risk(self, context): # 간단한 위험도 계산 로직 risk_map = {'낮음': 0.2, '보통': 0.5, '높음': 0.8, '작음': 0.2, '중간': 0.5, '큼': 0.8} urgency_risk = risk_map.get(context.get('urgency', '보통'), 0.5) impact_risk = risk_map.get(context.get('impact', '중간'), 0.5) return (urgency_risk + impact_risk) / 2 # 사용 예시 agent = InteractiveAgent("SmartBot") result = agent.execute_with_interaction( "프로덕션 데이터베이스 마이그레이션", "스키마 변경 후 데이터 이관" ) print(result) ``` 김개발 씨의 HITL 시스템은 잘 작동했습니다. AI가 위험한 작업을 하기 전에 승인을 받고, 피드백을 학습했습니다. 그런데 며칠 사용해 보니 아쉬운 점이 있었습니다. 어느 날 AI가 "데이터베이스 백업" 작업에 대해 승인을 요청했습니다. 팀장 박시니어 씨는 고민했습니다. "이게 긴급한 백업인가? 아니면 정기 백업인가? 영향 범위는 어느 정도지?" AI는 단순히 승인만 요청했을 뿐, 맥락 정보를 제공하지 않았습니다. 박시니어 씨가 김개발 씨에게 말했습니다. "AI가 좀 더 똑똑하게 질문하면 좋겠어요. 마치 사람처럼 대화하면서 상황을 파악하는 거죠." **인터랙티브 에이전트**란 정확히 무엇일까요? 쉽게 비유하자면, 인터랙티브 에이전트는 마치 **숙련된 의사**와 같습니다. 환자가 "배가 아파요"라고 하면 의사는 "언제부터 아팠나요? 어디가 아픈가요? 다른 증상은요?"라고 질문하며 정확한 진단을 내립니다. 이처럼 AI도 **능동적으로 질문**하며 상황을 이해합니다. 단순한 승인 요청만 하던 초기 시스템은 어땠을까요? AI는 "이 작업을 해도 될까요?"라고만 물었습니다. 사용자는 제한된 정보만으로 판단해야 했습니다. 문제는 **맥락이 부족**하다는 점이었습니다. 왜 이 작업이 필요한지, 영향 범위는 어떤지, 대안은 무엇인지 알 수 없었습니다. 더 큰 문제는 **오판 가능성**이었습니다. 정보가 부족하면 잘못된 결정을 내리기 쉽습니다. 바로 이런 문제를 해결하기 위해 **인터랙티브 에이전트**가 등장했습니다. 인터랙티브 에이전트를 사용하면 **맥락 기반 의사결정**이 가능해집니다. AI가 충분한 정보를 수집한 후 판단하므로 정확도가 높아집니다. 또한 **사용자 참여**가 증가합니다. 단순히 승인/거부를 누르는 게 아니라 대화에 참여하면서 더 관여하게 됩니다. 무엇보다 **신뢰도 향상**이라는 큰 이점이 있습니다. AI가 왜 이런 질문을 하는지 이해하면 시스템을 더 신뢰하게 됩니다. 위의 코드를 한 줄씩 살펴보겠습니다. `InteractiveAgent` 클래스는 `context` 딕셔너리로 대화 맥락을 저장합니다. `ask_clarification` 메서드는 사용자에게 질문을 던지고 답변을 받습니다. 핵심은 `execute_with_interaction` 메서드입니다. 여기서 AI는 긴급도, 영향 범위 등을 **능동적으로 질문**합니다. 수집한 정보로 `_calculate_risk`를 호출해 위험도를 재계산합니다. 마지막으로 최종 확인을 받아 실행 여부를 결정합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 클라우드 인프라 관리 시스템을 개발한다고 가정해봅시다. AI가 서버를 추가하려고 할 때, 단순히 "서버를 추가할까요?"라고 묻는 대신 이렇게 대화합니다. "어떤 워크로드를 위한 서버인가요? 예상 트래픽은? 비용 한도는?" 이런 정보를 바탕으로 AI는 최적의 서버 스펙을 제안하고, 사용자는 더 정보에 기반한 결정을 내릴 수 있습니다. AWS, Azure 같은 클라우드 플랫폼의 **AI 어드바이저**가 이런 방식을 사용합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **너무 많이 묻는 것**입니다. 10개, 20개의 질문을 던지면 사용자가 피로해집니다. 따라서 **핵심 질문 3-5개**로 제한하는 것이 좋습니다. 또한 **질문의 순서**도 중요합니다. 가장 중요한 질문부터 시작해서 점진적으로 세부 사항을 물어봐야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 요청을 받은 김개발 씨는 인터랙티브 에이전트를 구현했습니다. 일주일 후, 박시니어 씨가 만족스럽게 말했습니다. "이제 AI가 맥락을 이해하고 대화하니 훨씬 좋네요. 마치 똑똑한 동료와 일하는 것 같아요." 인터랙티브 에이전트를 제대로 만들면 AI가 단순한 도구를 넘어 진짜 협업 파트너가 됩니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 질문은 3-5개로 제한하세요 - 너무 많으면 사용자가 피곤해합니다 - 중요한 질문부터 시작해서 점진적으로 세부 사항을 물어보세요 - 사용자의 답변을 저장해서 다음번에는 더 스마트하게 질문하세요 (학습하는 대화) --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: LLM,HITL,에이전트

언어: Python

태그: Python, HITL, AI에이전트, 승인워크플로우, 피드백루프, LLM,HITL,에이전트

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

Human-in-the-Loop Agents 완벽 가이드

목차

1. 인간 개입 지점 설정

2. 승인 워크플로

3. 피드백 루프

4. 실습 HITL 시스템

5. 실습 인터랙티브 에이전트

댓글 (0)

함께 보면 좋은 카드 뉴스

Code Agent 구축 완벽 가이드

BabyAGI 분석과 구현 완벽 가이드

AutoGPT 분석과 구현 완벽 가이드

Agent Orchestration 완벽 가이드

Swarm Intelligence 분산 처리 완벽 가이드