Human-in-the-loop Agent 설계: 어떤 단계에서 사람의 승인이 필요한가

Feishu (Lark) 메시지 초안은 이미 만들어졌습니다. 제목, 본문, 첨부 링크까지 들어가 있습니다. 남은 것은 전송뿐입니다. 하지만 Agent는 send_message 직전에 멈추고 사용자의 확인을 기다립니다.

이메일 내용은 자동으로 만들 수 있습니다. 그러나 고객에게 보내기 전에는 수신자, 제목, 본문 요약, 첨부 파일을 보여줘야 합니다. CMS 폼도 자동으로 채울 수 있지만 submit_form은 policy에 막히고 owner approve를 기다립니다. 겉으로는 UI의 “확인” 버튼처럼 보이지만 실제 경계는 실행 상태의 일시정지입니다. Agent의 RunState를 저장하고, 사람이 결정한 뒤에만 실행을 재개합니다. 어디에서 멈출지, 누가 승인할지, 거절이나 timeout을 어떻게 처리할지는 프런트엔드 문제가 아니라 tool 시스템의 안전 경계입니다.

이 글은 위험 분류 매트릭스, 승인 지점 체크리스트, pause/resume 메커니즘, 감사 필드 템플릿을 제공합니다. “확인 버튼 하나 추가”가 아니라 “직렬화 가능하고, 재개 가능하고, 감사 가능한 상태”로 설계하는 방법입니다.

위험 분류 매트릭스: 어떤 작업을 승인 대상으로 둘 것인가

모든 작업에 승인이 필요한 것은 아닙니다. 읽기 작업은 자동으로 실행할 수 있고, 삭제와 결제는 사람을 기다려야 합니다. 판단은 다음 5가지 축에서 시작합니다.

축	분류 기준	예시 작업
외부 영향	외부 시스템 또는 사용자에게 영향을 줌	이메일 전송, 폼 제출, 외부 API 호출, Feishu/Slack 같은 협업 시스템에 쓰기
되돌릴 수 있는지	작업을 취소할 수 있는가	레코드 삭제(불가역), 초안 저장(가역), 결제(일부는 보상 필요), 메시지 전송(불가역)
데이터 민감도	다루는 데이터 수준	공개 데이터 조회, 내부 레코드 수정, 사용자 개인정보 내보내기, 프로덕션 설정 읽기
금액/권한 임계값	돈 또는 권한 변경 포함	결제, 송금, 환불, 권한 변경, 대량 작업, 사용자 데이터 삭제
자율 수준	허용되는 자동화 수준	읽기 전용 조회(완전 자동), 초안 작성(완전 자동), 외부 전송(확인), 삭제/결제(승인)

이 매트릭스는 OWASP LLM06의 과도한 기능, 과도한 권한, 과도한 자율성 위험과 잘 맞습니다. 그대로 써도 되고 비즈니스에 맞게 임계값을 조정해도 됩니다.

외부 영향: 다른 시스템이나 사람에게 닿는 작업은 조심해야 합니다. 이메일은 보낸 뒤 되돌릴 수 없습니다. 폼 제출은 주문을 만들 수 있습니다. 외부 API는 다른 시스템의 데이터를 바꿀 수 있습니다.

되돌릴 수 있는지: 레코드 삭제는 되돌리기 어렵고, 초안은 언제든 고칠 수 있습니다. 결제는 환불이나 보상 절차가 필요할 수 있습니다.

데이터 민감도: 공개 데이터는 비교적 자유롭게 읽을 수 있습니다. 내부 데이터는 쓰기를 제한하고, 개인정보나 프로덕션 설정은 승인 대상입니다.

금액/권한 임계값: 돈이나 권한이 있으면 멈춰야 합니다. 결제, 송금, 환불, 권한 변경, 대량 작업은 고위험 지점입니다.

자율 수준: 읽기는 자동 실행이 가능합니다. 초안도 아직 초안이므로 자동화할 수 있습니다. 외부 전송은 확인이 필요하고, 삭제와 결제는 승인이 필요합니다.

매트릭스는 한 번 정하고 끝나는 설정이 아닙니다. 내부 알림용 Feishu 메시지는 확인으로 낮출 수 있습니다. 실제 돈을 움직이는 결제는 승인과 2인 검토를 유지해야 합니다.

세 가지 실제 시나리오로 보는 위험 분류

사례 1: Feishu 메시지 초안

Agent가 Feishu 메시지 초안을 쓰는 것은 자동 실행(L0)입니다. 초안함에 저장될 뿐 전송되지 않고, 되돌릴 수 있으며 외부 영향도 없습니다. 하지만 고객에게 보내기 위해 send_message를 호출하는 순간은 승인(L2)이 필요합니다. 메시지는 전송 후 되돌릴 수 없고 외부 사용자에게 도달하며 민감하거나 오해를 부를 수 있습니다. MCP tools/call 전 확인이 여기에 해당합니다.

사례 2: 이메일 전송

이메일 내용을 생성하는 것은 자동 실행(L0)입니다. 아직 문자열일 뿐입니다. 이메일 API로 고객에게 보내는 단계는 수신자, 제목, 첨부 파일을 보여주는 승인(L2)이 필요합니다. 승인 UI는 “전송 확인” 버튼만 보여주면 안 되고, 요약과 근거를 보여줘야 합니다.

사례 3: CMS 폼 제출

Agent가 폼을 채우는 것은 자동 실행(L0)입니다. 아직 제출되지 않았고 데이터는 로컬에 있습니다. CMS API로 제출할 때는 policy가 막고 owner approve를 기다려야 합니다(L2). “금액이 임계값을 초과” 같은 guardrail일 수도 있고, “모든 CMS 제출은 승인”이라는 정적 policy일 수도 있습니다.

사례 4: 프로덕션 데이터베이스 삭제

프로덕션 DB를 조회하는 것은 자동 실행(L0)입니다. 읽기 작업이며 데이터를 변경하지 않습니다. 하지만 삭제 API를 호출한다면 강한 사람 승인 + backup 감사(L3)가 필요합니다. 프로덕션 삭제는 불가역이고 민감하며 사용자에게 영향을 줍니다. Guardrail만 믿지 말고 Policy 강제 규칙으로 제한해야 합니다.

이 사례들이 말하는 것은 명확합니다. 같은 작업 안에서도 단계마다 위험이 다릅니다. 초안은 자동, 전송은 승인, 프로덕션 삭제는 2인 검토입니다. 위험 분류는 구체적인 작업 단위로 해야 합니다.

승인 지점 체크리스트: 작업 유형까지 구체화하기

매트릭스가 있으면 승인 레벨을 정합니다.

L0 자동 실행: 데이터베이스 조회, 벡터 검색, 설정 읽기, 초안 저장, preview 생성입니다. 외부 영향이 없고 되돌릴 수 있으며 민감 데이터를 다루지 않습니다.

L1 확인: 이메일, 폼, 외부 API 같은 외부 메시지/데이터 전송과 데이터 export 같은 대량 읽기입니다. 외부 영향은 있지만 비교적 통제 가능합니다.

L2 승인: 레코드 삭제, 권한 변경, 대량 삭제, Feishu/Slack/CRM 쓰기입니다. 되돌리기 어렵거나 외부 영향이 큽니다.

L3 강한 승인 + 2인 검토: 결제, 환불, 개인정보 export, 프로덕션 설정 변경, 프로덕션 DB 삭제입니다. 돈이나 민감 데이터를 다룹니다.

이 목록은 OpenAI Agents SDK의 needs_approval 흐름과 MCP tool 안전 권고에 대응합니다. MCP는 tool 호출이 보이고, 거절 가능하며, 민감 작업은 확인 가능해야 한다고 봅니다.

비즈니스에 맞게 조정할 수 있습니다.

Feishu 메시지가 내부 알림뿐이라면 L1 확인으로 낮출 수 있습니다.
레코드 삭제가 사용자 데이터에 닿는다면 L2를 유지합니다.
결제가 매우 위험하다면 L3로 올리고 승인 이유와 2인 검토를 요구합니다.

이 목록도 고정이 아닙니다. 비즈니스 규칙이 바뀌면 “메시지 전송”을 승인 목록에서 뺄 수도 있습니다.

승인 플로우 상태 머신: 멈추고, 저장하고, 재개하기

승인은 UI 팝업이 아니라 실행 상태의 일시정지입니다. tool 호출에 승인이 필요하면 Agent의 RunState를 저장하고, 결정 후 재개합니다.

상태 전이도

승인 상태 머신은 다음 흐름입니다.

request -> pending -> approved/rejected/timeout -> resume/abort/compensate

request: tool 호출이 승인 요청을 만들고 RunState에 tool 이름, 인자, 컨텍스트를 담습니다.
pending: 사람의 결정을 기다립니다. 상태는 checkpoint에 저장되고 thread_id와 연결됩니다.
approved: 승인이 나면 checkpoint에서 재개하고 tool을 호출합니다.
rejected: 거절되면 abort 또는 convert to draft로 갑니다.
timeout: 시간이 지나면 escalate 또는 auto-reject로 갑니다.
resume/abort/compensate: 실행 재개, 작업 중단, 보상 처리를 수행합니다.

재개 방식

approve: 계속 실행하고 tool을 호출한 뒤 다음 단계로 갑니다.
reject: 중단하거나 초안으로 바꾸고 tool은 호출하지 않습니다.
edit: 수신자나 내용을 수정한 뒤 다시 승인하고 계속합니다.

checkpoint와 thread state는 상태 저장의 기술적 배경입니다. 이미 공개된 LangGraph checkpoint/thread state 글에서 실행 지점 저장과 복귀 방식을 다룹니다.

OpenAI Agents SDK HITL 코드 예시

아래 코드는 OpenAI Agents SDK의 승인 흐름 예시입니다. API는 바뀔 수 있으므로 프로덕션 코드에서는 공식 문서를 확인해야 합니다.

from agents import Agent, Runner, function_tool


@function_tool(needs_approval=True)
def send_email(to: str, subject: str, body: str) -> str:
    return send_email_handler(to=to, subject=subject, body=body)


agent = Agent(
    name="EmailAgent",
    tools=[send_email],
    instructions="이메일 초안을 작성하고 전송 전 승인을 기다립니다",
)

result = Runner.run_sync(agent, "고객에게 보낼 환불 안내 메일을 작성하세요")

if result.interruptions:
    state = result.to_state()

    for interruption in result.interruptions:
        print(f"승인 대기 tool: {interruption.tool_name}")
        print(f"인자: {interruption.arguments}")

        decision = show_approval_ui(interruption)

        if decision == "approve":
            state.approve(interruption)
        elif decision == "reject":
            state.reject(interruption)

    result = Runner.run_sync(agent, state)

핵심은 다음과 같습니다.

needs_approval=True로 tool에 승인 필요를 표시합니다.
interruptions에는 승인 대기 중인 tool 호출이 들어갑니다.
result.to_state()는 일시정지 결과를 직렬화 가능한 RunState로 변환합니다.
state.approve() 또는 state.reject()로 결정을 기록합니다.
Runner.run_sync(agent, state)로 정지 지점에서 재개합니다.

필드 이름은 2026-07 이후 바뀔 수 있으므로 공식 문서를 확인합니다.

LangGraph interrupt/resume 코드 예시

아래 코드는 LangGraph의 interrupt와 Command(resume=...) 예시입니다.

from langgraph.graph import StateGraph, MessagesState
from langgraph.checkpoint.memory import MemorySaver
from langgraph.types import Command, interrupt


def send_email_node(state: MessagesState):
    approved = interrupt({
        "action": "send_email",
        "summary": state["email_summary"],
    })

    if approved != "approved":
        return {"messages": ["이메일 전송이 거절되어 메시지를 초안으로 저장했습니다"]}

    email_result = send_email(state["email_params"])
    return {"messages": [email_result]}


graph = StateGraph(MessagesState)
graph.add_node("send_email", send_email_node)
graph.add_edge("draft_email", "send_email")

checkpointer = MemorySaver()
app = graph.compile(checkpointer=checkpointer)

thread_id = "thread_123"
config = {"configurable": {"thread_id": thread_id}}

result = app.invoke(
    {"messages": ["고객에게 보낼 환불 안내문을 작성하세요"]},
    config=config,
)

# graph가 멈추면 interrupt payload가 호출자에게 반환됩니다.
# 승인 UI를 표시하고 사람의 결정을 기다립니다.
decision = show_approval_ui(result["__interrupt__"])

if decision == "approve":
    app.invoke(Command(resume="approved"), config=config)
elif decision == "reject":
    app.invoke(Command(resume="rejected"), config=config)
elif decision == "edit":
    app.update_state(config, {"email_params": {"to": "new_customer@example.com"}})
    app.invoke(Command(resume="approved"), config=config)

핵심은 다음과 같습니다.

interrupt()가 graph를 멈춥니다.
Command(resume=...)가 실행을 재개합니다.
checkpoint + thread_id가 상태 일관성을 유지합니다.
approve/reject/edit 세 가지 재개 방식을 다룰 수 있습니다.

LangGraph API도 공식 문서에서 확인해야 합니다.

승인 증거 필드: 무엇을 저장하고 어떻게 추적할까

승인은 결정이면서 기록입니다. 최소 감사 로그 필드는 다음과 같습니다.

필드	설명	예시
tool_name	tool 이름 + 작업 유형	send_email / delete_record
tool_arguments	전체 인자 JSON	{“to”: “customer@example.com”, “subject”: “환불 안내”}
invoker_id	호출자 ID	user@example.com / agent_run_abc123
request_time	승인 요청 시간	2026-06-23T09:26:10Z
approver_id	승인자 ID	on-call-engineer@example.com
decision_time	결정 시간	2026-06-23T09:35:12Z
decision	결정 결과	approved / rejected / timeout_auto_reject
evidence	승인 근거(스크린샷 또는 요약)	“수신자가 올바르고 민감 정보가 없습니다”
audit_trail_id	실행 로그 연결 ID	run_abc123_step_5_tool_3

이 필드는 MCP Tools의 감사 권고와 OpenAI API의 mcp_approval_request item에서 가져온 것입니다. 승인 로그는 관측 가능성의 일부입니다. 더 넓은 logging 설계는 이미 공개된 Agent monitoring/recovery 글을 참고하면 됩니다.

RunState는 어떻게 직렬화할까요? OpenAI Agents SDK에서는 result.to_state()로 일시정지 결과를 RunState로 바꿀 수 있습니다. LangGraph는 checkpoint + thread_id를 사용합니다. 직렬화한 상태를 DB 또는 로그 시스템에 저장하고 audit_trail_id와 연결합니다.

감사 로그의 용도는 세 가지입니다.

사고 추적: 데이터 유출이 발견되면 누가 언제 어떤 작업을 승인했는지 확인합니다.
컴플라이언스 증거: 기업 환경에서는 고위험 작업에 사람 승인이 있었다는 증거가 필요합니다.
정책 개선: 자주 승인, 거절, timeout되는 작업을 집계해 승인 정책을 조정합니다.

필드는 확장할 수 있습니다. 승인 소요 시간, 승인 채널, 2인 검토 여부를 추가할 수 있습니다. 하지만 최소 세트는 유지해야 합니다.

거절과 timeout: 승인이 실패하면 무엇을 할까

승인은 항상 통과하지 않습니다. reject와 timeout 경로가 명확해야 task가 멈춘 채로 남지 않습니다.

거절 후 세 가지 경로

경로 1: continue with fallback. 더 낮은 위험 작업으로 계속합니다. 이메일 전송이 거절되면 초안으로 저장하고 계속합니다.

경로 2: convert to draft. 작업을 초안 상태로 바꿉니다. CMS 제출이 거절되면 초안으로 저장하고 사람이 수정한 뒤 다시 제출합니다.

경로 3: abort task. 전체 작업을 멈춥니다. 프로덕션 DB 삭제가 거절되면 run은 중단되어야 합니다.

선택 기준은 작업 유형입니다.

되돌릴 수 있는 작업: fallback 또는 convert to draft.
불가역 고위험 작업: abort task.
사람 개입이 필요한 경우: escalate.

timeout 후 두 가지 경로

경로 1: escalate to backup approver. 주 승인자가 30분 동안 응답하지 않으면 on-call engineer에게 넘깁니다.

경로 2: auto-reject. 1시간 뒤 자동 거절하고 task를 멈춥니다. 상대적으로 낮은 위험이지만 시간 제한이 있는 작업에 적합합니다.

선택 기준은 맥락입니다.

고위험 작업: escalate. 자동 실행으로 넘어가면 안 됩니다.
시간 민감 작업: auto-reject. 무한정 멈추지 않게 합니다.
일반 상황: escalate.

이미 실행한 단계를 되돌리는 방법

거절 후에는 이미 실행된 단계가 있을 수 있습니다. 결제 승인이 거절되기 전에 주문을 만들었다면 주문을 취소해야 합니다.

전략은 다음과 같습니다.

Checkpoint rollback: approval 전 checkpoint로 돌아갑니다.
보상 트랜잭션: 주문 취소 같은 보상 API를 호출합니다.
사람 개입: 자동으로 처리할 수 없으면 사람에게 알립니다.

항상 되돌릴 수 있는 것은 아닙니다. 보낸 이메일은 되돌릴 수 없습니다. 이 경우 감사 로그를 남기고 사후 처리합니다.

네 가지 안전 경계: Policy, Guardrail, Approval, Audit 조합

Approval은 단독 보호 장치가 아닙니다. Policy, Guardrail, Approval, Audit은 함께 동작하며 서로 대체하지 않습니다.

네 계층 책임표

계층	책임	예시
Policy	정적 규칙으로 tool 범위를 제한	”프로덕션 DB 삭제 금지”, “결제 tool은 sandbox만 호출”
Guardrail	입력/출력 이상을 자동 검사	입력 검증, 출력 정리, 민감 정보 필터, 금액 임계값 검사
Approval	고위험 작업에 대한 사람 결정	이메일 전 수신자/본문 표시, 레코드 삭제 전 확인, 결제 승인
Audit	사후 추적 가능성	승인 로그, tool call 로그, 상태 변경 로그

Policy는 Guardrail을 대체하지 않습니다. 정적 규칙은 동적 입력을 검사하지 못합니다.
Guardrail은 Approval을 대체하지 않습니다. 자동 검사는 비즈니스 판단을 하지 못합니다.
Approval은 Audit을 대체하지 않습니다. 결정과 추적은 다릅니다.
Audit은 앞의 세 계층을 대체하지 않습니다. 사후 기록일 뿐 위험을 막지 못합니다.

조합 예시입니다.

결제: Policy로 금액 상한을 제한하고, Guardrail로 인자를 검증하며, Approval로 2인 검토하고, Audit으로 기록합니다.
이메일: Policy로 수신 도메인을 제한하고, Guardrail로 민감 내용을 검사하며, Approval로 요약을 보여주고, Audit으로 전송을 기록합니다.

MCP tool 안전 경계

MCP (Model Context Protocol) tool 호출에는 자체 경계가 있습니다. 2025-06-18 spec은 게시 전 다시 확인해야 합니다.

tools/list는 사용 가능한 tool을 보여줍니다.
tools/call 전 민감 작업 확인은 Approval 계층입니다.
inputSchema 검증은 Guardrail 계층입니다.
timeout은 tool call이 멈춘 채로 남는 것을 막습니다.
audit logging은 Audit 계층입니다.

중요한 점: MCP approval은 OAuth scope나 server-side authorization을 대체하지 않습니다. MCP approval은 tool call 전 확인이고, OAuth scope는 API 접근 권한이며, server-side authorization은 비즈니스 권한 검사입니다. 세 가지가 모두 필요합니다.

Feishu MCP server가 OAuth를 통과했고 send_message scope가 있어도 모든 메시지가 안전하다는 뜻은 아닙니다. MCP approval은 전송 전 내용을 확인하고, server-side authorization은 수신자가 허용 범위인지 확인합니다.

외부 메시지, 협업 시스템 쓰기, 테이블 대량 변경 승인 시나리오는 계획 중인 Feishu MCP 글에서 다룹니다.

승인 UI 설계 포인트

승인 UI는 approve/reject 버튼만으로 충분하지 않습니다. 판단에 필요한 정보를 보여줘야 합니다.

설계 원칙:

tool과 인자를 보여줍니다.
예상 영향을 보여줍니다. 예: “customer@example.com에게 환불 안내 제목의 이메일 전송”.
되돌릴 수 있는지 보여줍니다. “전송 후 취소 불가” 또는 “삭제 후 복구 가능”.
데이터 민감도를 보여줍니다.
cancel과 reject를 구분합니다. cancel은 UI 상호작용 중단이고, reject는 tool call을 거절하고 감사 로그에 남기는 것입니다.

핵심 요소:

tool + 작업 유형
전체 인자(필요하면 접기)
예상 영향 요약
되돌릴 수 있는지 경고
데이터 민감도 라벨
승인 이유 입력
approve / reject / cancel 버튼

중요합니다. UI는 server-side authorization을 대체하지 않습니다. 확인을 눌러도 backend는 호출자, 대상 객체, 권한을 검증해야 합니다.

UI가 “record ID=123 삭제”를 보여줘도 backend는 그 record가 현재 사용자에게 속하는지, 삭제 권한이 있는지 확인합니다.

HITL은 고립된 팝업이 아닙니다. tool gateway, logging, 권한 시스템 안에 있어야 합니다. 계획 중인 MCP 프로덕션 아키텍처 글에서 더 다룹니다.

OWASP LLM01/LLM06 위험 매핑

OWASP LLM Top 10은 LLM과 Agent 시스템의 보안 위험을 정의합니다. 번호와 버전은 바뀔 수 있으므로 게시 전 확인해야 합니다. 승인 설계와 직접 관련 있는 두 가지는 다음과 같습니다.

위험 번호	위험 설명	승인 대응
LLM01 Prompt Injection	외부 입력이 무단 함수 호출, 데이터 유출, 외부 명령 실행을 유도	고위험 작업에는 사람 승인을 요구하고 prompt 규칙만 믿지 않으며 UI에 인자와 영향을 표시
LLM06 Excessive Agency	과도한 기능, 권한, 자율성이 tool 시스템 위험을 만듦	Policy로 tool 범위를 제한하고 Approval로 자동화 수준을 제한하며 “always allow” 범위를 좁힘

LLM01은 prompt injection이 모델을 무단 tool call로 밀어붙일 수 있음을 보여줍니다. Approval은 고위험 작업 앞에서 멈추고 인자와 영향을 사람에게 보여줍니다.

LLM06은 자율성이 과하면 위험하다는 점을 보여줍니다. Approval은 만능이 아니며 Policy와 Guardrail과 함께 동작해야 합니다. “이번 세션 항상 허용”은 좁게 제한해야 합니다.

NIST AI RMF Core 매핑

NIST AI RMF Core는 AI 위험 관리를 네 단계로 정리합니다. 작은 팀은 가벼운 버전으로 충분합니다.

단계	승인 책임	예시
Govern	역할과 위험 규칙 정의	owner/on-call engineer 역할, L0-L3 레벨, reject/timeout 전략
Map	고위험 시나리오 식별	매트릭스로 삭제, 결제, 권한 변경, prompt injection 경로 찾기
Measure	커버리지와 거절률 측정	approval coverage, rejection rate, timeout rate 추적 및 policy 조정
Manage	사고 대응과 복구	로그 사용, rollback, 보상 처리

Govern은 규칙을 정의합니다. Map은 위험을 찾습니다. Measure는 통제가 작동하는지 봅니다. Manage는 사고와 복구를 처리합니다.

작은 팀이라면 승인 레벨, 고위험 작업, 거절률, 감사 로그만으로도 충분합니다.

결론

위험 분류가 첫 단계입니다. 모든 작업에 승인이 필요하지 않습니다. 읽기와 초안은 자동화할 수 있고, 삭제와 결제는 사람을 기다려야 합니다. 외부 영향, 되돌릴 수 있는지, 데이터 민감도, 금액/권한, 자율 수준으로 판단합니다.

Approval은 팝업이 아닙니다. 직렬화 가능하고 재개 가능하며 감사 가능한 시스템 상태입니다. RunState를 checkpoint에 저장하고, run은 정지 지점으로 돌아오며, audit log는 결정과 실행 체인을 남깁니다.

네 가지 안전 경계는 역할이 다릅니다. Policy는 tool을 제한하고, Guardrail은 자동 검사하며, Approval은 사람 판단을 추가하고, Audit은 추적 가능하게 합니다. 함께 써야 합니다.

OWASP LLM01과 LLM06은 prompt injection과 excessive agency가 핵심 위험임을 보여줍니다. Approval은 Policy와 Guardrail과 함께 동작해야 합니다.

NIST AI RMF Core는 틀을 제공합니다. 작은 팀은 approval 레벨, 고위험 작업, 거절률, audit log만 잡아도 충분합니다.

다음에 읽을 글:

공개된 LangGraph checkpoint/thread state 글: 승인 상태 저장의 기술적 배경.
공개된 Agent monitoring/recovery 글: approval log를 관측 가능성에 넣는 방법.
계획 중인 MCP 프로덕션 아키텍처 글: HITL이 gateway와 권한 시스템 안에 있어야 하는 이유.
계획 중인 Feishu MCP 글: 외부 메시지와 협업 시스템 쓰기 승인 시나리오.