Slack은 승인(approvals)과 알림(alerts)에는 훌륭합니다.

하지만 장시간 실행되는 에이전트(agents)를 감독하기 위한 신뢰할 수 있는 정보원(source of truth)으로는 끔찍합니다.

실제 웹사이트 업데이트 워크플로우(workflow)를 Slack을 통해 실행해 보기 전까지는 이 말이 과장처럼 들릴 것입니다.

제가 말하는 것은 현재 흔히 사용되는 다음과 같은 설정입니다:

• 에이전트가 사이트 문구(site copy)를 업데이트함
• CMS에 접근함
• 스크립트(script)를 실행할 수도 있음
• 내부 API를 호출할 수도 있음
• 사람이 마지막 단계를 승인할 수 있도록 진행 상황을 Slack에 게시함

서류상으로는 깔끔해 보입니다.

하지만 실제로 Slack은 풍부한 실행 추적(execution traces)을 단순한 '느낌(vibes)'으로 바꿔버립니다.

그리고 에이전트가 운영 환경(production)의 콘텐츠를 편집할 때는 그 '느낌'만으로는 충분하지 않습니다.

실패 모드는 매우 일반적입니다

저는 웹사이트 업데이트 자동화를 위한 에이전트 감독(agent supervision) 패턴을 살펴보던 중 이 문제에 직면했습니다.

r/openclaw의 스레드에서 정확히 이 문제를 포착했습니다:
https://reddit.com/r/openclaw/comments/1v1nmnk/how_to_get_agent_commentary_and_tool_calls_to/

해당 사용자는 이미 해설(commentary), 내레이션(narration), 도구 진행 상황(tool progress)을 포함한 Slack 스트리밍(streaming)을 활성화한 상태였습니다:

{
  "channels": {
    "slack": {
...

이것은 게으른 설정이 아닙니다.

에이전트 감독을 올바르게 수행하려는 사람의 시도입니다.

하지만 수많은 테스트 끝에, 그들은 여전히 실제로 필요로 하는 세부 정보 대신 헤더와 같은 파편들만 보여주는 Slack을 마주하게 되었습니다.

핵심적인 문장은 다음과 같았습니다:

OpenClaw 대시보드(dashboard)에서는 해설과 도구 호출(tool calls)을 볼 수 있지만, Slack에서도 그것들을 보고 싶습니다.

이것이 문제의 핵심입니다.

대시보드에는 진실(truth)이 있습니다.
Slack에는 요약(summary)이 있습니다.

만약 인간 감독자가 Slack만 지켜본다면, 그들은 압축된 버전의 현실을 보고 있는 것입니다.

왜 이런 일이 발생하는가

Slack은 채팅 앱이기 때문입니다.

에이전트는 더 이상 채팅 형태(chat-shaped)가 아닙니다.

현대적인 에이전트 워크플로우는 다음과 같은 구조화된 이벤트(structured events)를 방출합니다:

• 계획 단계 (planning steps)
• 도구 호출 (tool calls)
• 부분적인 도구 출력 (partial tool output)
• 재시도 (retries)
• 승인 체크포인트 (approval checkpoints)
• 상태 전환 (state transitions)
• 최종 작업 (final actions)

OpenAI Responses API는 도구 사용 (tool use) 및 응답 항목 (response items)에 대해 이벤트와 유사한 출력 (event-like output)을 스트리밍합니다.
Anthropic Messages API 스트리밍은 tool_use 및 콘텐츠 델타 (content deltas)와 같은 세밀한 블록 (granular blocks)을 노출합니다.

이것이 실제 환경에서 에이전트가 동작하는 방식입니다.

트레이스 (trace)는 다음과 같은 모습에 더 가깝습니다:

1. 페이지 상태 조사 (inspect page state)
2. 요청된 카피 변경 사항 비교 (compare requested copy changes)
3. CMS 도구 호출 (call CMS tool)
4. 유효성 검사 오류 수신 (get validation error)
5. 수정된 필드로 재시도 (retry with corrected field)
6. 차이점 요약 생성 (generate diff summary)
7. 승인 요청 (request approval)
8. 게시 (publish)

대시보드는 이러한 구조를 보존할 수 있습니다.

하지만 Slack 스레드는 이를 텍스트로 평탄화 (flatten) 시켜버립니다.

한번 평탄화되고 나면, 에이전트가 신중하게 행동하고 있는지 아니면 그저 자신감 있게 들리도록 말하고 있는지를 판단하는 데 인간에게 필요한 정확한 맥락 (context)을 잃게 됩니다.

진짜 문제: 생략을 통한 거짓말

이 부분이 핵심입니다.

만약 Slack이 다음과 같이 표시한다면:

• Commentary (해설)
• bash
• tool running (도구 실행 중)

그것은 투명성 (transparency)이 아닙니다.
그것은 레이블 (label)일 뿐입니다.

그것은 다음과 같은 유용한 질문들에 답하지 못합니다:

• 어떤 명령어가 실행되었는가?
• 어떤 파일이 변경되었는가?
• 어떤 API 페이로드 (payload)가 전송되었는가?
• 첫 번째 시도가 실패했는가?
• 에이전트가 재시도했는가?
• 스테이징 (staging) 환경을 건드렸는가, 아니면 프로덕션 (production) 환경을 건드렸는가?

이것들은 매우 다른 이야기들입니다.

하지만 Slack은 이 모든 것을 동일해 보이게 만들 수 있습니다.

웹사이트 자동화의 경우, 이는 순식간에 위험해질 수 있습니다.

다음 사이에는 엄청난 차이가 있습니다:

• 이미지 크기 조정 (resizing an image)
• 블로그 제목 업데이트 (updating a blog title)
• 가격 카피 교체 (replacing pricing copy)
• SEO 메타데이터 변경 (changing SEO metadata)
• Webflow, WordPress 또는 Contentful에서 게시 트리거 (triggering publish)

만약 Slack이 보여주는 것이 전부 tool running뿐이라면, 당신의 감독 계층 (supervision layer)은 중요한 부분을 놓치고 있는 것입니다.

Slack의 한계는 에이전트 트레이스에 부적합합니다

이것은 단순한 UX 불만이 아닙니다.

Slack의 API 제약 사항은 챗봇이나 알림에는 적합합니다.
하지만 고충실도(high-fidelity) 에이전트 스트리밍에는 적합하지 않습니다.

Slack은 메시지 텍스트를 4,000자 미만으로 유지할 것을 권장하며, 40,000자가 넘는 메시지는 잘릴 수 있다고 명시합니다.

또한 Slack은 메시지 게시 속도를 채널당 초당 약 1개로 제한하며, 더 넓은 워크스페이스 제한도 적용합니다.

일반적인 봇에게는 문제가 되지 않습니다.

하지만 다음과 같은 것을 방출하는 에이전트에게는:

• 코멘터리 (commentary)
• 도구 진행 상황 (tool progress)
• 명령 출력 (command output)
• 재시도 (retries)
• 승인 체크포인트 (approval checkpoints)

이러한 것들은 병목 현상 (bottleneck)이 됩니다.

무엇이 먼저 망가지는가

보통 에이전트가 아닙니다.

감시 계층 (supervision layer)이 먼저 망가집니다.

Slack에 너무 많은 실행 세부 정보를 밀어 넣으면, 다음과 같은 현상 중 하나가 발생합니다:

• 업데이트가 모호한 요약으로 배치 (batched) 처리됨
• 업데이트가 늦게 도착하거나 순서가 뒤바뀜
• 업데이트가 잘림 (truncate)
• 부하가 걸리면 업데이트가 사라짐

그러면 사람은 이렇게 말합니다. “에이전트가 좀 이상했어.”

그럴 수도 있습니다.

하지만 많은 경우, 트레이스 (trace)는 멀쩡했으나 Slack이 그것을 엉망으로 만든 것입니다.

잘못된 패턴: Slack을 관측성 시스템 (observability system)처럼 취급하기

팀들이 다음과 같이 행동하는 것을 계속 보게 됩니다:

에이전트 (Agent) -> 도구 호출 (tool call) -> 도구 출력 (tool output) -> 진행 상황 업데이트 (progress update) -> 재시도 (retry) -> 승인 요청 (approval request) -> 게시 (publish) -> 최종 요약 (final summary)

이 모든 것이 하나의 Slack 스레드 (thread)로 직접 스트리밍됩니다.

모두가 이미 Slack을 사용하고 있기 때문에 이것이 편리하게 느껴질 수 있습니다.

하지만 이것은 잘못된 확신 (false confidence)을 만드는 가장 빠른 방법이기도 합니다.

업데이트로 가득 찬 스레드는 가시성 (visibility)처럼 보입니다.
하지만 그것은 실행 가시성 (execution visibility)과는 다른 것입니다.

더 나은 패턴: 주의 집중을 위한 Slack, 진실을 위한 트레이스 UI

이것은 제가 웹사이트 업데이트 자동화를 위해 매번 사용할 패턴입니다.

그 하이브리드 설정이 실제 운영 환경 (production)에서 살아남는 방식입니다.

제가 실제로 구축할 것

1. Slack을 짧고 의사 결정 중심적으로 유지하기

Slack 메시지는 다음 질문에 답해야 합니다:

• 무엇이 일어나고 있는가?
• 사람이 조치를 취해야 하는가?
• 전체 트레이스 (full trace)는 어디에 있는가?

좋은 Slack 마일스톤 (milestones):

• 계획된 변경 (planned change)
• 도구 단계 실행 중 (running tool step)
• 승인 대기 중 (awaiting approval)
• 완료됨 (completed)
• 실패 및 검토 필요 (failed and needs review)

나쁜 Slack 콘텐츠:

• 전체 명령 출력 (full command output)
• 가공되지 않은 차이점 (raw diffs)
• 긴 추론 스트림 (long reasoning streams)
• 모든 재시도 이벤트 (every retry event)
• 모든 중간 도구 페이로드 (every intermediate tool payload)

Slack 메시지 예시:

{
  "text": "웹사이트 에이전트가 스테이징 환경의 홈페이지 히어로 카피(hero copy)를 업데이트했습니다. 게시 전 승인을 기다리는 중입니다. 전체 트레이스(Full trace): https://your-trace-ui/runs/abc123"
}

그것만으로는 충분하지 않습니다.

2. 실제 실행 기록을 트레이스 UI(trace UI)에 기록하기

모든 Slack 체크포인트는 트레이스(trace)로 연결되어야 합니다.

해당 트레이스에는 다음 내용이 포함되어야 합니다:

• 원시 도구 입출력 (raw tool input/output)
• 명령 텍스트 (command text)
• 파일 차이점 (file diffs)
• 타임스탬프 (timestamps)
• 재시도 (retries)
• 승인 이벤트 (approval events)
• 각 단계에서 사용된 모델 (model used for each step)

OpenClaw, LangSmith 또는 자체 트레이싱 레이어(tracing layer)를 사용하고 있다면, 실제 디버깅(debugging)은 바로 이곳에서 이루어집니다.

해당 OpenClaw 스레드의 한 답글에서는 다음과 같이 시도해 보았다는 언급이 있었습니다:

"commandText": "raw"

일부 설정에서는 이것이 가시성(visibility)을 개선할 수도 있습니다.

그럼에도 불구하고, 설령 원시 명령 텍스트(raw command text)가 나타난다 하더라도 Slack을 공식 로그(canonical log)로 만들지는 않을 것입니다.

3. Slack에서 승인하고, 트레이스에서 조사하기

이것이 깔끔한 분리 방법입니다.

Slack은 다음 용도로 적합합니다:

• “이 게시를 승인하시겠습니까?”
• “이 단계에서 실패했습니다.”
• “에이전트가 당신의 응답을 기다리고 있습니다.”

트레이스 UI는 다음 용도로 적합합니다:

• “왜 이 필드를 건드렸는가?”
• “실제로 어떤 명령이 실행되었는가?”
• “첫 번째 시도가 실패했는가?”
• “어떤 모델이 도구 호출(tool call)을 결정했는가?”

인터페이스가 다르면 역할도 다릅니다.

구체적인 구현 스케치

사이트를 업데이트하고 Slack에 게시하는 에이전트를 위한 간단한 패턴입니다.

에이전트 흐름 (Agent flow)

계획(plan) -> 조사(inspect) -> 초안 편집(edit draft) -> 검증(validate) -> 차이점 요약(summarize diff) -> 승인 요청(request approval) -> 게시(publish)

트레이스에 저장되는 내용

{
  "run_id": "site-update-4821",
  "model": "gpt-5.4",
...

Slack으로 전송되는 내용

웹사이트 에이전트가 홈페이지 업데이트를 준비했습니다.

변경 사항: 히어로 헤드라인 업데이트
...

이러한 분리를 통해 Slack의 가독성을 유지하면서 트레이스의 유용성을 확보할 수 있습니다.

에이전트가 발전할수록 이것이 더욱 중요한 이유

이상한 점은 이것입니다. 더 풍부한 감독(supervision)은 대개 트래픽을 증가시킨다는 것입니다.

에이전트 운영이 개선된다고 해서 항상 메시지 수가 줄어드는 것은 아닙니다.
그것은 종종 다음과 같은 의미를 갖습니다:

• 더 많은 체크포인트 (checkpoints)
• 더 많은 재시도 (retries) 노출
• 더 많은 도구 이벤트 (tool events)
• 더 많은 검토 루프 (review loops)
• 프롬프트 및 라우팅 (routing)에 대한 더 많은 실험

이는 다음 두 가지 모두에 압박을 가합니다:

• 사람을 향한 채널 (human-facing channel)
• 기반이 되는 모델/도구 예산 (underlying model/tool budget)

이 지점에서 가격 책정이 아키텍처에 영향을 미치기 시작합니다.

모든 추가적인 트레이스 (trace), 재시도 (retry), 검토 루프 (review loop)가 비용이 많이 든다고 느껴지면, 팀은 가시성을 억제하게 됩니다.
그들은 로그를 덜 남깁니다.
감독을 덜 합니다.
각 체크포인트마다 비용이 발생하기 때문에 유용한 체크포인트를 피하게 됩니다.

만약 n8n, Make, Zapier, OpenClaw 또는 커스텀 워크플로 (custom workflows)에서 에이전트를 실행하고 있다면, 이는 잘못된 인센티브입니다.

에이전트 중심의 자동화의 경우, 토큰당 과금 (per-token billing) 방식보다는 고정 월간 컴퓨팅 (flat monthly compute) 방식이 훨씬 더 합리적으로 판단하기 쉽습니다.

만약 팀이 사용량을 계속 감시하지 않으면서 더 많은 감독, 더 많은 트레이스, 더 많은 반복 (iteration)을 원한다면, 그것이 바로 Standard Compute와 같은 제품이 존재하는 이유입니다:
https://standardcompute.com

이 서비스는 고정 월간 가격으로 OpenAI 호환 API를 제공하므로, 모든 추가 체크포인트가 과금 이벤트처럼 느껴지지 않게 에이전트 워크플로를 실행할 수 있습니다.

이는 사람들이 생각하는 것보다 더 중요합니다.

왜냐하면 감독이 개선될수록, 일반적으로 더 많은 모델 활동이 생성되기 때문입니다.

나의 현재 규칙

만약 사람이 다음과 같이 물어봐야 할 수도 있다면:

에이전트가 정확히 무엇을 했나요?

Slack이 그 답변이 존재하는 유일한 장소여서는 안 됩니다.

Slack은 안내 데스크 (front desk)로 사용하세요.
트레이스 UI (trace UI)를 보안 카메라 영상 (security camera footage)으로 사용하세요.

이것이 여기서 얻을 수 있는 명확한 교훈입니다.

Slack은 주의 환기, 승인, 그리고 에스컬레이션 (escalation)에 매우 좋습니다.

하지만 프로덕션 에이전트의 실행 이력 (execution history)의 유일한 사본을 보관하고 싶은 곳은 아닙니다.

이 점을 명확히 이해하면 아키텍처는 더 단순해집니다:

• 요약은 Slack으로
• 증거는 대시보드 (dashboard)로
• 승인은 채팅에서 사람이
• 디버깅은 트레이스 (traces)에서 사람이

이러한 설정은 모든 것을 스레드 (thread)로 스트리밍하는 것보다 덜 화려합니다.

하지만 제가 신뢰하는 방식이기도 합니다.

실질적인 시사점

이번 주에 웹사이트 업데이트 자동화를 구축하고 있다면, 다음과 같이 하세요:

1. Slack으로 마일스톤 (milestones) 스트리밍하기
2. 전체 트레이스 (full traces)는 다른 곳에 저장하기
3. 모든 Slack 업데이트를 트레이스 (trace)와 연결하기
   ...

만약 2단계를 건너뛴다면, 당신은 에이전트 (agent)를 감독하고 있는 것이 아닙니다.

당신은 그저 에이전트의 상태 메시지 (status messages)를 읽으며, 그것들이 모든 이야기를 들려주기를 바라고 있을 뿐입니다.