대시보드는 당신에게 조용히 거짓말을 하기 직전까지만 훌륭합니다.

저도 다른 사람들만큼이나 깔끔한 관리자 화면을 좋아합니다. 초록색 체크 표시. 멋진 합계. 마치 데이터베이스가 평생 중복된 행을 한 번도 본 적이 없는 것처럼 위로 향하는 차트 말이죠.

하지만 제가 본 최악의 운영(Ops) 실수 중 일부는 똑같은 문장으로 시작되었습니다:

“대시보드에는 문제가 없다고 나와 있어.”

그래서 Reddit의 작은 사례 하나가 제 기억에 남았습니다. r/openclaw 스레드에서 어떤 사용자는 앱 화면을 신뢰하는 대신, 자신의 활동 기록으로부터 Garmin의 장치 동기화 워크시트를 채우기 위해 OpenClaw를 사용했다고 말했습니다.

그것은 아주 작은 활용 사례입니다. 하지만 동시에 AI 에이전트가 실제로 무엇을 잘하는지를 보여주는 가장 명확한 사례 중 하나이기도 합니다.

트윗을 작성하는 것.
동료인 척 역할극(Roleplaying)을 하는 것.
요약본을 다시 요약하는 것.

이런 것들이 아닙니다.

유용한 움직임은 바로 이것입니다:

에이전트가 소스 레코드(Source records)로 돌아가 스스로 답변을 재구성하게 하는 것.

이것은 에이전트를 챗봇(Chatbot)에서 검증 레이어(Verification layer)로 변화시킵니다.

그리고 자동화를 구축하는 개발자들에게 이것은 훨씬 더 흥미로운 일입니다.

채팅 부분은 가장 흥미롭지 않은 부분입니다

대부분의 사람들은 여전히 에이전트를 몇 가지 도구가 부착된 채팅 UI로 생각합니다.

그러한 프레임은 실제 가치를 놓치고 있습니다.

중요한 점은 GPT-5나 Claude가 자연어로 답변할 수 있다는 것이 아닙니다. 중요한 점은 에이전트가 다음을 조사(Inspect)할 수 있다는 것입니다:

• Gmail 스레드
• Slack 메시지
• SQLite 또는 PostgreSQL 행
• CSV 내보내기
• Google Sheets
• 앱 활동 로그
• 캘린더 이벤트

그런 다음 에이전트는 해당 기록들을 당신의 대시보드가 주장하는 내용과 비교할 수 있습니다.

이것이 바로 아키텍처의 변화(Architectural shift)입니다.

에이전트가 기본 레코드에 직접 접근할 수 있다면, 특정 앱의 요약 화면을 신뢰할 필요가 없습니다.

검증 워크플로우(Verification workflows)에서 이것은 다음과 같은 차이를 만듭니다:

• “페이지의 숫자를 읽기”
• “증거로부터 숫자를 계산하기”

저는 두 번째를 훨씬 더 신뢰합니다.

왜 대시보드가 종종 잘못된 진실의 원천(Source of truth)이 되는가

대시보드는 가독성과 속도에 최적화되어 있습니다.

포렌식적 정확도(Forensic accuracy)에 최적화되어 있는 것이 아닙니다.

대시보드의 숫자는 다음과 같을 수 있습니다:

• 캐시된 (cached)
• 지연된 (delayed)
• 필터링된 (filtered)
• 중복 제거된 (deduplicated)
• 반올림된 (rounded)
• 당신이 존재조차 잊어버린 비즈니스 규칙에 기반한 (based on business rules you forgot existed)

대략적인 추세(trend)를 확인할 때는 괜찮습니다.

하지만 다음과 같은 결정을 내려야 할 때는 괜찮지 않습니다:

• 고객에게 연락이 닿았는지 여부
• 동기화 작업(sync job)이 실제로 완료되었는지 여부
• CRM이 받은 편지함과 일치하는지 여부
• 지원 백로그(support backlog)가 증가하고 있는지 여부
• 결제 보고서(billing report)를 안전하게 발송해도 되는지 여부

Garmin 사례가 설득력을 갖는 이유는 고통스러울 정도로 익숙하기 때문입니다. 앱 화면은 한 가지를 말하고, 히스토리는 다른 것을 말했기에, 사용자는 근본적인 활동(underlying activity)으로부터 정답을 재구성했습니다.

그것이 바로 패턴입니다.

AI에게 대시보드를 신뢰하라고 요구하지 마세요. AI에게 영수증(receipts)을 확인하라고 요구하세요.

이를 가능하게 하는 스택 (The stack that makes this work)

에이전트 워크플로우(agent workflows)를 파헤치던 중, 대부분의 벤더 페이지보다 통합 문제(integration problem)를 더 잘 설명하는 r/openclaw의 또 다른 토론을 발견했습니다. 한 댓글 작성자는 이를 네이티브 도구(native tools), MCP 연결(MCP connections), 그리고 Composio와 같은 관리형 OAuth 레이어(managed OAuth layers)의 계층으로 나누었습니다.

그것이 진짜 설계 문제입니다.

"어떤 모델이 가장 똑똑한가?"가 아닙니다.

더 나은 질문은 다음과 같습니다:

이 에이전트가 내가 실제로 신뢰하는 기록에 얼마나 직접적으로 접근할 수 있는가?

실제적인 버전은 다음과 같습니다.

제 생각에는, 검증(verification)이 중요하다면 OpenClaw + MCP + Composio 조합이 또 다른 호스팅된 채팅 앱보다 훨씬 흥미롭습니다.

OpenClaw가 검증 작업에 적합한 이유

OpenClaw가 흥미로운 이유는 채팅 장난감이라기보다 인프라(infrastructure)처럼 작동하기 때문입니다.

만약 제가 에이전트에게 다음과 같은 것들을 대조(reconcile)하라고 요청한다면:

• 로컬 내보내기 파일 (local exports)
• 받은 편지함 히스토리 (inbox history)
• SQLite 행 (SQLite rows)
• Slack 메시지
• 3주 전에 누군가 이메일로 보낸 스프레드시트

저는 검사 가능한(inspectable) 무언가를 원합니다.

OpenClaw는 이를 가능하게 하는 명령어를 노출합니다:

openclaw status
openclaw status --all
openclaw status --deep
...

이것이 중요합니다.

검증 계층 (verification layer)은 디버깅이 가능해야 합니다. 만약 에이전트가 대시보드가 틀렸다고 말한다면, 저는 에이전트가 무엇을 건드렸는지, 무엇이 실패했는지, 그리고 어떤 소스 (source)를 신뢰했는지 알고 싶습니다.

MCP가 유용해지는 지점

MCP (Model Context Protocol)가 중요한 이유는 에이전트가 화면 하나를 스크래핑 (scraping)하고 그것을 진실인 양 가장하는 대신, 실제 시스템에 접근할 수 있는 표준화된 방법을 제공하기 때문입니다.

예를 들어, 에이전트가 다음과 같은 서비스에 연결할 수 있다면:

• Gmail
• Google Calendar
• PostgreSQL
• SQLite
• 로컬 파일 (local files)
• Notion

에이전트는 소스 레코드 (source records)로부터 답변을 재구성할 수 있습니다.

이는 "대시보드를 열고, 합계를 읽고, 합계를 반복한다"는 방식보다 훨씬 더 건강한 패턴입니다.

최소한의 예시는 개념적으로 다음과 같을 수 있습니다:

const records = await Promise.all([
  gmail.getThreads({ since: "2026-06-01" }),
  slack.getMessages({ channel: "support", since: "2026-06-01" }),
...

정확한 API는 다르지만, 패턴은 동일합니다:

1. 소스 레코드 가져오기 (fetch source records)
2. 정규화하기 (normalize them)
3. 답변 계산하기 (compute the answer)
4. 앱 요약과 비교하기 (compare it to the app summary)
5. 증거 출력하기 (output evidence)

Composio가 OAuth 지옥으로부터 당신을 구하는 방법

이 부분은 개발자들이 인증 (auth) 흐름 때문에 주말을 통째로 날려버리기 전까지는 과소평가하는 영역입니다.

Composio는 다음과 같은 까다로운 통합 계층 (integration layer)을 처리해주기 때문에 유용합니다:

• OAuth
• 사용자별 연결 (per-user connections)
• 토큰 갱신 (token refresh)
• 트리거 (triggers)
• SDK 및 CLI 액세스
• 수많은 앱 통합 (app integrations)

즉, 모든 커넥터 (connector)에 대해 인증 로직을 직접 구현(hand-rolling)할 필요 없이, 에이전트가 Gmail, Slack, Google Sheets, Linear와 같이 팀이 실제로 사용하는 시스템에서 데이터를 가져올 수 있음을 의미합니다.

설치 과정은 놀라울 정도로 간단합니다:

curl -fsSL https://composio.dev/install | bash

그리고 네, 이것은 검증에 있어 매우 중요합니다. 만약 에이전트가 Slack의 원시 메시지 (raw messages)를 가져와 CRM 활동이나 티켓 수와 비교할 수 있다면, 누군가 잘못된 보고서를 전달하기 전에 불일치를 잡아낼 수 있습니다.

실질적인 검증 워크플로우 (verification workflow)

여기서 아이디어는 추상적인 단계에서 벗어납니다.

견고한 조정 파이프라인 (reconciliation pipeline)은 보통 다음과 같은 형태를 띱니다:

1. 관련된 모든 시스템으로부터 소스 데이터 (source data) 추출
2. ID, 타임스탬프 (timestamps), 중복 항목 정규화 (Normalize)
3. 모델에게 차이점을 조정 (reconcile)하도록 요청
4. 모델이 계산한 결과와 대시보드 값을 비교
5. 증거 링크가 포함된 불일치 보고서 (mismatch report) 생성

만약 n8n을 사용하고 있다면, 이는 매우 자연스럽게 적용될 수 있습니다.

예시 워크플로우 (Example flow):

• 노드 1: Gmail 스레드 내보내기 가져오기
• 노드 2: Slack 메시지 가져오기
• 노드 3: Google Sheets 행 읽기
• 노드 4: PostgreSQL 쿼리
• 노드 5: Claude 또는 GPT-5를 사용하여 조정 (reconciliation) 실행
• 노드 6: Slack 또는 이메일로 불일치 보고서 게시

이것은 에이전트에게 사이드바에서 똑똑해 보이도록 요구하는 것보다 훨씬 더 나은 활용법입니다.

예시: 대시보드 지표와 소스 레코드 비교

다음은 워크플로우의 형태를 보여주는 간소화된 Node.js 예시입니다.

async function verifyContactCount({ dashboardCount, gmailThreads, crmRecords }) {
  const contactedEmails = new Set();

...

이것은 화려한 AI가 아닙니다. 그저 규율 있는 검증 (verification)일 뿐입니다.

레코드가 지저분하고 여러 시스템에 흩어져 있을 때, 그리고 무엇이 왜 일치하지 않는지에 대한 읽기 쉬운 설명을 원할 때 모델은 유용해집니다.

내가 즉시 추가할 체크리스트

소스 레코드로부터 재구성하는 것이 대시보드를 신뢰하는 것보다 안전합니다.

하지만 이것이 자동으로 정확하다는 뜻은 아닙니다.

원시 데이터 (raw data)가 지연되었거나, 불완전하거나, 형식이 잘못되었거나, 중복된 경우에도 에이전트는 여전히 잘못된 답을 내놓을 수 있습니다. 다만 아주 자신감 있게 내놓을 뿐입니다.

따라서 제가 이것을 프로덕션 (production) 환경을 위해 구축한다면, 에이전트가 다음 사항들을 보고하도록 요구할 것입니다:

• 소스별 레코드 수 (record counts)
• 누락된 날짜 범위
• 중복된 ID
• 소스 신선도 타임스탬프 (freshness timestamps)
• 확정된 결론 vs 추론된 결론
• 모든 불일치 사항에 대한 정확한 증거 행 또는 링크

마지막 항목이 가장 중요합니다.

에이전트가 대시보드가 틀렸다고 말한다면, 그것을 증명할 수 있는 정확한 Gmail 스레드, Slack 퍼머링크 (permalink), SQLite 행, 또는 CSV 라인을 지목해야 합니다.

그렇지 않다면 당신은 그저 하나의 불투명한 요약을 또 다른 불투명한 요약으로 대체했을 뿐입니다.

이것을 수행할 가치가 있는 경우

모든 워크플로우에 이것이 필요한 것은 아닙니다.

때로는 대시보드만으로도 충분할 수 있습니다.

다음과 같은 경우에는 검증 계층 (verification layer)을 구축해야 합니다:

• 여러 시스템의 데이터가 일치하지 않을 때
• 대시보드의 지연 (lag)이 알려져 있을 때
• 사람이 이미 수동으로 기록을 교차 검증 (cross-checking)하고 있을 때
• 잘못된 답변의 비용이 높을 때
• 워크플로우가 자동화할 수 있을 만큼 충분히 반복적일 때

적합한 사례:

• 지원 운영 (support ops)
• CRM 위생 관리 (CRM hygiene)
• 백오피스 에이전트 워크플로우 (back-office agent workflows)
• 동기화 검증 (sync verification)
• 컴플라이언스 성격의 감사 추적 (compliance-ish audit trails)
• 결제 및 활동 대조 (billing and activity reconciliation)

부적합한 사례:

• 중요도가 낮은 허영 지표 (vanity metrics)
• "대충 맞아도" 실제로 괜찮은 모든 경우

모델 비용은 빠르게 숨겨진 장애물이 됩니다

사람들이 말하기를 꺼려하는 실질적인 문제도 있습니다.

검증 워크플로우는 토큰을 많이 소비합니다 (token-hungry).

에이전트가 끊임없이 기록을 가져오고, 정규화 (normalizing)하고, 재시도하고, 출력을 비교하며, 증거 기반 보고서를 생성한다면, 토큰당 과금 방식 (per-token pricing)은 금방 번거로워집니다.

이것이 바로 팀들이 스스로 검열을 시작하게 되는 바로 그런 종류의 워크로드입니다:

• "너무 자주 실행하지 마세요"
• "규모가 작은 계정은 전체 대조 (full reconciliation)를 건너뛰세요"
• "누군가 불만을 제기할 때만 대시보드를 확인하세요"

이는 본래의 목적을 저해합니다.

검증은 누군가가 청구서 걱정을 할 때가 아니라, 일관되게 실행될 때 가장 유용합니다.

그렇기 때문에 저는 에이전트 운영 (agentic ops) 작업에 있어 정액제 추론 (flat-rate inference)이 과소평가되어 있다고 생각합니다.

Standard Compute를 사용하면 OpenAI 호환 API를 사용하여 예측 가능한 월간 가격으로 무제한 AI 컴퓨팅을 사용할 수 있습니다. 즉, 토큰 불안 (token anxiety) 때문에 스택을 재설계할 필요 없이 기존 SDK, n8n 플로우 또는 맞춤형 에이전트에 바로 연결할 수 있다는 의미입니다.

이러한 상시 가동 대조 (always-on reconciliation) 워크플로우의 경우, 모든 확인 작업을 마치 사치스러운 기능처럼 측정하는 것보다 이러한 가격 모델이 더 합리적입니다.

특히 에이전트가 자동화를 통해 24/7 가동되는 경우라면 더욱 그렇습니다.

더 큰 변화

에이전트에 대해 가장 과소평가된 점은, 최고의 유스케이스가 종종 생성 (generation)에 관한 것이 아니라는 사실입니다.

그것은 재구성 (reconstruction)에 관한 것입니다.

네, 모델 선택은 중요합니다. GPT-5는 구조적 추론 (structured reasoning)에 능숙합니다. Claude는 세심한 종합 (synthesis)에 강점을 보이는 경우가 많습니다. 다른 모델들도 제약 조건에 따라 충분히 훌륭할 수 있습니다.

하지만 에이전트가 실제 기록에 접근할 수 없다면, 그 어떤 것도 그리 중요하지 않습니다.

Gmail, Slack, PostgreSQL, SQLite, 그리고 로컬 내보내기 (local exports)에 직접 접근할 수 있는 평범한 에이전트가, 대시보드 탭 안에 갇혀 있는 천재적인 모델을 이길 것입니다.

그것이 바로 변화의 핵심입니다.

이것을 깨닫고 나면, 당신은 더 이상 다음과 같이 묻지 않게 됩니다:

"AI가 이 화면을 요약할 수 있을까요?"

대신 더 나은 질문을 던지기 시작할 것입니다:

"만약 에이전트가 대시보드를 완전히 무시하고, 증거(evidence)를 바탕으로 수치를 재구성한다면 그 답은 무엇이 될까요?"

그것이 바로 제가 신뢰하는 방식입니다.