LLM 에이전트가 자동화된 흐름 내에서 이메일을 보낼 때, 문제는

또한 이에 대해 엄격해야 하는 기술적인 이유가 있습니다. Google은 팀이 단순히 개별 알림(alerts)만 생성하는 것이 아니라, 장애 발생 시 신호(signals), 소유권(ownership), 그리고 반복 가능한 단계(repeatable steps)를 정의할 때 운영 신뢰성(operational reliability)이 향상된다고 설명합니다: https://sre.google/sre-book/monitoring-distributed-systems/

나에게 가장 효과적이었던 설계

내가 가장 선호하는 설계는 한 문장으로 요약됩니다: 하나의 실행(execution), 하나의 정체성(identity), 하나의 증거(evidence). 거대한 플랫폼을 구축할 필요는 없습니다. 책임 소재를 깔끔하게 분리하는 것이 핵심입니다.

이를 말로 설명하면 다음과 같습니다:

1. 오케스트레이터(orchestrator)가 흐름의 시작 시점에 run_id를 생성합니다.
2. 각 이메일 액션은 해당 run_id와 message_type을 상속받습니다.
3. LLM 에이전트는 콘텐츠를 생성하지만, 최종 라우팅(routing)을 단독으로 결정하지는 않습니다.
4. 전송 서비스(delivery service)가 운영 메타데이터를 추가하고 구조화된 로그(structured log)를 저장합니다.
5. 검증(validation) 단계에서는 해당 실행(run)과 연관된 메시지만 읽습니다.

이 모델은 모호성을 매우 빠르게 줄여줍니다. 또한 사후 분석(post-mortem)의 가독성도 향상시키는데, 이제는

첫 번째는 컨텍스트(context) 없는 재시도입니다. 작업(job)이 다시 실행되더라도 동일한 시각적 참조나 동일한 받은 편지함(inbox)을 재사용한다면, 팀은 결국 잘못된 메시지를 비교하게 됩니다. 두 번째는 대역 외(out-of-band) 인간 승인입니다. 누군가 Slack이나 티켓(ticket)을 통해 응답하지만, 워크플로우(workflow)가 해당 결정을 적절한 곳에 기록하지 않는 경우입니다.

세 번째는 더 미묘합니다. 에이전트(agent)는 글을 잘 쓰지만, 파이프라인(pipeline)이 최종 본문이 케이스의 현재 상태와 일치하는지 검증하지 않는 것입니다. 이는 기술적으로는 정확하지만 운영상으로는 오래된 메시지를 생성합니다. 그리고 네 번째로 꽤 흔한 사례는 이메일이 누락되었을 때 무엇을 해야 하는지 문서화하지 않는 것입니다. 많은 자동화가 매우 견고해 보이지만, 한 단계가 발생하지 않으면 기다려야 할지, 재시도해야 할지, 아니면 에스컬레이션(escalate)해야 할지 아무도 모르게 됩니다.

또한 측정하는 것이 좋습니다. State of DevOps 보고서에 따르면, 배포(delivery) 및 관측성(observability) 관행이 더 성숙한 팀은 프로세스가 반복 가능하고 가시적일 때 더 적은 마찰과 더 짧은 복구 시간으로 변경 사항을 해결합니다: https://cloud.google.com/devops/state-of-devops

이 시점에서 저는 매우 현실적인 점검을 하곤 합니다. 만약 내부 노트에 증거를 설명하기 위해 'dummy email'과 같은 텍스트가 나타난다면, 저는 이미 그 프로세스에 더 나은 명명 규칙(nomenclature)이 필요하다는 것을 압니다. 사소해 보일 수 있지만, 그러한 모호한 라벨은 나중에 대시보드(dashboard), 티켓(ticket) 또는 핸드오프(handoff)에 스며듭니다. 그것 하나만으로 시스템이 망가지지는 않지만, 시스템을 더 혼란스럽게 만듭니다.

많은 혼란을 방지하는 작은 런북(runbook)

20페이지짜리 문서를 작성할 필요는 없습니다. 실제로 잘 유지되는 짧은 런북(runbook)이 보통 더 효과적입니다. 이메일을 활용한 LLM 워크플로우를 위한 저의 런북은 다음과 같은 형태를 띱니다:

1. run_id, 환경 및 프롬프트 버전을 확인합니다.
2. message_type에 대해 단일 발행 이벤트가 존재하는지 확인합니다.
3. 수신처, 제목 및 타임스탬프(timestamp)를 검토합니다.
4. 캡처된 증거가 해당 실행(execution)에만 속하는지 확인합니다.
5. 재시도(retries)가 있었는지, 그리고 내용이 변경되었는지 검증합니다.
6. 인간의 결정을 병렬로 기록하는 것이 아니라 시스템 내부에 기록합니다.
7. 최소한의 추적 가능성(traceability) 신호가 부족하면 에스컬레이션(escalate)합니다.

이 런북(runbook)이 모든 오류를 방지하지는 못하지만, 시스템을 훨씬 더 관리 가능하게(governable) 만듭니다. 또한 합리적인 트레이드오프(tradeoff)를 제공합니다. 즉, 진단 시간을 대폭 줄이는 대가로 약간의 메타데이터(metadata)와 규율을 도입하는 것입니다. 프롬프트, 큐(queue), 웹훅(webhook) 사이에서 이미 작업하고 있는 팀들에게는, 처음에는 다소 관료적으로 느껴질지라도 상당히 괜찮은 거래라고 생각합니다.

Q&A

이것은 복잡한 시스템에만 적용되나요?

아니요. 두 개의 이메일만 있는 작은 흐름이라도 각 실행이 격리되고 명확한 체크포인트(checkpoint)를 가진다면 큰 이득을 얻습니다. 규모는 달라질 수 있지만, 필요성은 달라지지 않습니다.

LLM이 규칙 없이 최종 텍스트를 결정하게 하는 것이 좋을까요?

저는 그렇게 하지 않겠습니다. 저는 변수 영역과 최소한의 검증을 갖춘 유연한 템플릿(template)을 선호합니다. 자유도는 낮아지겠지만, 이상한 돌발 상황도 줄어듭니다.

만약 현재 모든 것이 뒤섞여 있다면 무엇을 가장 먼저 검토해야 할까요?

두 가지부터 시작하겠습니다. 실행별 식별(identity by execution)과 실행별 증거 캡처(capture of evidence by run)입니다. 이것만으로도 거의 모든 다른 것들을 정리할 수 있으며, 나머지 런북(runbook) 단계들도 훨씬 수월하게 적용할 수 있습니다.