내 메신저와 통화를
하나의 판단 루프로 묶는 법

카카오톡에 고객 메시지가 온다. 조금 뒤에 전화가 오고, 이메일로 자료가 도착한다. 슬랙에서는 팀원이 나를 부르고, 캘린더에는 곧 시작할 미팅이 있다.

각각은 작은 사건이다. 문제는 이 사건들이 서로 다른 앱에 흩어져 있다는 데서 시작한다.

나는 한 앱에서 답장을 하고, 다른 앱에서 약속을 잡고, 통화 중에는 "오늘 보내드리겠다"고 말한다. 그리고 다음 일로 넘어간다. 몇 시간 뒤 내가 기억해야 하는 건 메시지 내용이 아니다. 이 다섯 가지다.

• 누구에게 무엇을 약속했는가
• 지금 공은 누구에게 있는가
• 다음 행동은 무엇인가
• 언제까지 해야 하는가
• 답장 전에 무엇을 준비해야 하는가

그래서 나는 메신저를 하나로 합치는 대신, 메신저와 통화에서 생긴 판단과 약속을 하나의 루프로 묶는 시스템을 만들고 있다. 이름은 Human Gate OS, 줄여서 HGO다. Hermes는 이 안에서 증거를 읽고 다음 행동을 준비하고, 필요한 순간에만 나를 부르는 운영 에이전트다.

HGO는 모든 대화를 모아 보여주는 통합 수신함이 아니다. 흩어진 사건을 "누가, 무엇을, 언제까지 해야 하는가"로 바꾸고, 그 일이 실제로 끝났는지까지 확인하는 상태 시스템이다.

전에 쓴 글 에이전트 서비스 설계는 자동화가 아니라 판단을 복제하는 일이다에서 왜 판단을 복제해야 하는지를 다뤘다. 이번 글은 그 원칙이 실제 운영에서 어떤 루프로 도는지, 그리고 다른 사람이 이걸 따라 만들 때 무엇을 그대로 지키고 무엇을 각자 정해야 하는지에 집중한다.

1. 전체 그림

flowchart LR
  subgraph S[외부에서 일어나는 일]
    M[메신저·문자·이메일]
    C[통화·미팅]
    A[캘린더·고객 행동]
  end

  subgraph H[Human Gate OS]
    E[사건과 근거]
    O[의무·다음 행동·기한]
    Q[지금·다음·대기·검토 큐]
    R[문안·스크립트·자료·발송 근거]
  end

  subgraph X[Hermes]
    J[맥락 확인과 판단]
    P[준비·위임·검증]
  end

  subgraph U[사람]
    N[판단 가능한 한 장]
    G[전화·발송·승인·수정]
  end

  M --> E
  C --> E
  A --> E
  E --> J
  J --> O
  J --> P
  P --> R
  O --> Q
  R --> N
  Q --> N
  N --> G
  G --> E
  E -->|결과와 정정| J

흐름은 단순하다.

1. 메신저, 전화, 이메일, 미팅에서 사건이 생긴다.
2. HGO는 원문 전체를 아무 데나 복제하는 대신, 사건과 출처를 근거로 남긴다.
3. Hermes가 새 사건을 보고 사람, 고객, 기존 약속, 이전 행동과 연결한다.
4. 그 자리에서 담당자, 다음 행동, 기한, 필요한 준비물을 정한다.
5. Hermes가 할 수 있는 준비는 먼저 끝낸다. 답장 문안, 통화 스크립트, 자료 요청, 견적 초안, 검증 같은 일이다.
6. 나는 "무슨 일이 있었나"보다 "지금 무엇을 결정하거나 실행해야 하나"를 본다.
7. 내가 실제로 전화하거나 보내거나 승인하면 그 결과가 다시 HGO에 들어간다.
8. 실제 결과와 내 수정은 다음 판단의 기준을 고치는 근거가 된다.

마지막 화살표가 중요하다. 내가 메시지를 보냈는데 시스템에는 여전히 "보내야 함"으로 남아 있다면 루프는 닫힌 게 아니다. 초안을 만들었다고 고객 진행으로 기록해도 안 된다. 시스템이 실제 세계와 다시 맞아야 루프가 닫힌다.

2. 왜 통합 수신함을 만들지 않았나

처음에는 나도 한 화면에 모든 것을 모으면 해결될 거라고 생각했다. 카카오톡, 문자, 이메일, 슬랙, 통화 기록을 한곳에 보여주면 덜 놓칠 것 같았다.

실제로는 읽을 것이 더 많아졌다.

메시지가 열 개면 요약도 열 개 생긴다. 알림을 줄이려고 만든 시스템이 새로운 알림 발송기가 된다. 대시보드를 추가할수록 어디를 먼저 봐야 하는지 다시 판단해야 한다. 수집은 잘되는데 일은 닫히지 않는다.

내 병목은 정보 부족이 아니었다. 정보가 들어온 순간에 판단이 고정되지 않는 것이었다.

• "나중에 답해야지"는 담당자와 기한이 없다.
• "자료 보내야 함"은 어떤 자료인지, 누가 준비하는지 없다.
• "고객이 관심 있어 보임"은 다음 행동이 아니다.
• "초안 준비됨"은 고객에게 실제로 보냈다는 뜻이 아니다.

그래서 HGO의 중심 단위는 메시지가 아니라 의무다. 한 사건에서 여러 의무가 생길 수도 있다. 고객에게 샘플 데이터를 받아야 하고, Joe는 데모를 준비해야 하고, 나는 가격을 승인해야 할 수 있다. 반대로 메시지가 여러 개여도 실제 다음 행동은 하나일 수 있다.

엔지니어 메모: 메시지 테이블이 아니라 event → obligation

원문 채널은 source adapter다. HGO 쪽에서는 사건을 append-only evidence로 남기고, 그 근거에서 obligation을 만든다. obligation에는 최소한 다음이 있어야 한다.

executor / next_action / due_at / readiness / workflow_state / source_refs

텍스트를 복사해 둔 것만으로는 부족하다. 어떤 근거로 이 의무가 생겼는지, 어떤 실제 행동이 끝내는지, 지금 실행 가능한 상태인지가 필요하다. 같은 고객에게 여러 의무가 생길 수 있으므로 lead = one task 같은 축약도 피한다.

3. Hermes는 HGO에 어떻게 들어오는가

HGO와 Hermes의 관계는 HGO 안에 거대한 AI 두뇌를 심는 구조가 아니다.

HGO는 사실, 상태, 기한, 산출물, 실행 근거를 보관한다. Hermes는 새 사건이나 상태 변화를 전달받아 판단한다. 웹훅이 Hermes를 깨울 수도 있고, 정해진 점검이 바뀐 상태를 발견할 수도 있다. 핵심은 HGO가 고객 문장의 의미를 키워드와 정규식으로 억지 판정하지 않는다는 것이다.

예를 들어 고객이 이렇게 말할 수 있다.

• "내일 오전이면 좋겠습니다."
• "자료는 메일로 드렸어요."
• "입금했습니다."
• "아까 말씀하신 번호로 먼저 테스트해볼게요."

이 문장들은 글자 모양이 아니라 맥락으로 판단해야 한다. "내일"이라는 단어가 있다고 전부 약속은 아니고, "입금"이라는 단어가 없어도 결제가 끝났다는 의미일 수 있다.

Hermes는 기존 고객 상태와 최근 근거를 함께 보고 의미를 판단한다. 코드는 날짜 계산, 권한, 중복 방지, 상태 전이, 근거 ID 확인처럼 결정적으로 처리할 수 있는 일을 맡는다.

이 경계를 뒤집으면 문제가 생긴다. 코드는 문장의 의미를 잘못 단순화하고, 모델은 산술과 라이프사이클을 가끔 틀린다. 둘을 제대로 나누면 백엔드는 오히려 얇아지고, 판단에는 근거가 남는다.

엔지니어 메모: 에이전트는 저장소가 아니라 판단·실행 주체다

HGO 내부에 고객별 하드코딩 규칙, 키워드 분류기, 문안 템플릿 엔진을 계속 추가하지 않는다. 에이전트가 구조화된 출력으로 의미 판단을 기록하고, HGO는 이를 검증해 상태와 산출물로 보관한다.

source event
→ evidence window
→ one-subject adjudication
→ obligations
→ global allocation
→ atomic publication

one-subject adjudication은 서로 다른 고객의 맥락을 한 번에 섞어 판정하지 않기 위한 경계다. global allocation은 각 고객의 의무를 모두 만든 뒤, 회사 전체 관점에서 지금 사람에게 보여줄 순서를 정하는 단계다. 개별 고객에게 중요한 일과 회사 전체에서 지금 가장 중요한 일은 같은 질문이 아니다.

4. 어떤 형태로 내게 오는가

나는 원문 메시지 백 개를 다시 읽고 싶지 않다. 그렇다고 AI가 내린 결론 한 줄만 보고 움직이고 싶지도 않다. 내가 원하는 것은 판단 가능한 최소 표면이다.

HGO의 작업 화면은 다음 질문에 빠르게 답해야 한다.

출력은 상황에 따라 다르다.

여기서 중요한 원칙은 알림 수가 아니라 표면의 역할을 나누는 것이다. Slack은 명령과 예외를 다룬다. HGO는 고객 업무 상태와 실행을 다룬다. 정기 정보는 한 번의 cockpit으로 수렴한다. 고객 문안과 견적은 해당 고객 맥락에 붙는다.

알림이 많아진다고 시스템이 똑똑해지지는 않는다. 같은 판단을 여러 화면에서 반복하게 되면 오히려 나빠진다.

5. 나는 무엇을 판단하는가

Human Gate라는 이름 때문에 "AI가 못하니 사람이 마지막에 검수한다"고 생각하기 쉽다. 내가 의도한 것은 그 반대다.

사람은 AI의 오탈자를 검사하는 최종 작업자가 아니라, 책임이 있는 경계에서 판단하는 사람이다.

Hermes는 고객의 원문을 확인하고, 이전 자산을 찾고, 답장 초안을 만들고, 통화 스크립트를 준비하고, 데모나 견적의 빈칸을 채우고, 검증까지 할 수 있다. 내가 보게 될 때는 가능하면 마지막 행동만 남아야 한다.

내가 남아야 하는 지점은 이런 곳이다.

• 가격, 할인, 계약 범위처럼 돈과 책임이 달라지는 결정
• 고객에게 실제로 나갈 말과 자료
• 실제 전화, 발송, 캠페인 시작
• 프로덕션 데이터나 통신 설정을 바꾸는 일
• 근거가 충돌해 사업적 우선순위를 정해야 하는 일
• 기존 기준을 바꿀 예외와 정정

이 구조에서 Human Gate는 자동화의 실패가 아니라, 상품과 조직의 책임선을 보존하는 장치다.

좋은 Human-in-the-loop는 사람이 모든 단계를 확인하는 구조가 아니다. 사람만 책임질 수 있는 판단 직전까지 에이전트가 일을 끝내 두는 구조다.

6. 내 행동은 어떻게 다시 HGO로 들어가는가

내가 버튼을 눌렀다는 사실과 고객에게 메시지가 실제로 갔다는 사실은 다르다.

• 초안을 열었다: 진행 아님
• 문안을 복사했다: 보낼 의도일 수 있으나 진행 아님
• Joe가 견적을 만들었다: 준비일 뿐 진행 아님
• 실제 발송 근거가 생겼다: 진행
• 고객이 회신했다: 새로운 사건
• 내가 통화를 마쳤고 결과를 남겼다: 상태를 바꿀 근거

나는 이 구분을 Prep ≠ Progress라고 부른다.

실제 발송, 통화 결과, 고객 회신은 다시 사건으로 들어온다. HGO는 기존 의무를 닫거나 새 의무를 만든다. 내가 "이 고객은 지금 전화가 아니라 자료를 먼저 보내야 한다"고 고치면, 그 정정도 다음 판단 기준의 후보가 된다.

다만 모든 정정을 곧바로 전사 규칙으로 만들지는 않는다. 한 번의 예외일 수도 있기 때문이다. 반복되는 정정인지, 특정 고객이나 업종의 맥락인지, 앞으로도 지켜야 할 안전 경계인지 구분한다. 반복 가능한 판단은 스킬과 운영 규칙으로 남기고, 일회성 사실은 해당 사건과 고객 맥락에만 남긴다.

엔지니어 메모: 클릭 이벤트와 현실의 증거를 섞지 않기

UI interaction, agent preparation, external side effect를 서로 다른 이벤트로 기록해야 한다. draft_copied를 message_sent로 취급하면 분석과 다음 행동이 모두 오염된다. 외부 채널의 실제 전송 ID, 통화 결과, 고객 응답, 또는 사용자의 명시적 확인처럼 완료 계약에 맞는 근거가 있어야 상태를 전이한다.

상태를 바꿀 때는 무엇이 바뀌었는지만 저장하지 말고, 어떤 evidence ref가 그 변경을 정당화했는지도 함께 남긴다.

7. 이 시스템을 만든 이유

나는 집중력이 약해서 이 시스템을 만든 게 아니다. 집중력이 비싼 자원이라는 걸 인정했기 때문에 만들었다.

대표가 모든 메시지를 직접 기억하면 회사의 상태는 대표의 머릿속에만 있다. 직원이 늘어도 인수인계가 어렵고, 에이전트를 붙여도 매번 처음부터 설명해야 한다. 대표가 하루 쉬면 약속의 위치도 같이 사라진다.

그렇다고 모든 대화를 무차별로 수집하고 자동으로 행동하게 만들고 싶지도 않았다. 그건 효율적인 운영이 아니라 감시와 무책임한 자동화에 가깝다.

내가 원하는 구조는 네 가지 사이의 균형이다.

이 철학에서 중요한 것은 AI가 얼마나 많은 권한을 가졌는지가 아니다. AI가 어떤 증거를 보고, 어디까지 준비하고, 어디서 멈추며, 사람이 한 판단을 어떻게 다시 시스템에 반영하는지다.

8. 다른 사람과 조직이 그대로 따라야 할 것

HGO, Hermes, Slack이라는 이름은 우리 환경의 구현이다. 다른 조직이 이 이름과 도구를 그대로 쓸 필요는 없다. 하지만 아래 원칙까지 바꾸면 이 루프는 쉽게 통합 수신함이나 알림봇으로 퇴행한다.

시스템 불변 조건

1. 원문 근거가 판단보다 먼저다. 출처, 시각, 대상 없이 만들어진 할 일은 신뢰하지 않는다.
2. 사건이 들어온 시점에 담당자·다음 행동·기한을 정한다. 나중에 한꺼번에 분류하지 않는다.
3. 요약이 아니라 실행 가능한 출력으로 끝낸다. "고객 후속 필요"가 아니라 문안, 통화 목적, 필요한 자료, 완료 기준까지 준비한다.
4. 준비와 실제 진행을 구분한다. 초안, 복사, 내부 검수는 고객 접촉이 아니다.
5. 되돌리기 비싼 행동에는 사람의 gate가 있다. 돈, 외부 발송, 프로덕션 변경, 법적 책임, 민감한 데이터가 대표적이다.
6. 완료는 증거로 닫는다. 에이전트의 "완료했습니다"가 아니라 전송 ID, 테스트 결과, 반영된 상태, 고객 반응을 본다.
7. 같은 일을 여러 알림면에 복제하지 않는다. 평상시는 조용하고, 예외와 결정만 사람의 주의를 쓴다.
8. 사람의 정정이 다시 기준으로 들어간다. 단, 일회성 사실과 반복 규칙을 구분한다.
9. 수집 범위와 보존 기간을 명시한다. 접근할 수 있다는 이유로 모든 사적 대화를 읽지 않는다.

9. 각자 다르게 판단해야 할 것

반대로 아래는 우리 답을 복사하면 안 된다. 사람, 조직, 산업에 맞춰 결정해야 한다.

도구보다 먼저 이 표를 채워야 한다. 그렇지 않으면 남의 조직도를 복사한 자동화가 된다.

10. 이 글을 읽은 에이전트가 해야 할 일

이 섹션은 특정 제품을 설치하라는 지시가 아니다. 이 글을 받은 에이전트가 사용자와 조직에 맞는 운영 루프를 스스로 맞춰가기 위한 계약이다.

목표
- 사용자의 메시지를 더 많이 요약하는 것이 아니라, 약속과 다음 행동이 증거와 함께 닫히는 루프를 만든다.

먼저 할 일
1. 현재 쓰는 메신저, 통화, 이메일, 캘린더, CRM, 작업 보드, 알림을 읽기 전용으로 조사한다.
2. 각 표면에서 무엇이 사실의 원본이고 무엇이 단순 복사본인지 구분한다.
3. 사건 → 판단 → 준비 → 사람 gate → 실제 행동 → 결과 환류의 현재 흐름을 그린다.
4. 이미 있는 상태 저장소와 알림면에 흡수할 수 있는지 먼저 본다. 새 시스템 추가를 기본값으로 두지 않는다.

반드시 지킬 것
- 근거 없는 우선순위, 숫자, 약속을 만들지 않는다.
- 사건마다 owner, next_action, due, evidence를 판정한다.
- 준비를 진행으로 기록하지 않는다.
- 외부 발송, 돈, 법적 책임, 프로덕션 변경은 명시된 승인 경계를 따른다.
- 완료 주장은 원본 시스템의 증거로 확인한다.
- 허용된 데이터 범위 밖을 수집하지 않는다.

질문 방식
- 한꺼번에 설문지를 던지지 않는다.
- 먼저 조사해서 확인된 사실, 가설, 미결정을 나눈다.
- 구조를 바꾸는 가장 영향 큰 질문 하나만 묻는다.
- 답을 반영해 지도를 고친 뒤 다음 질문으로 간다.

최초 질문 순서
1. 이 조직에서 절대 놓치면 안 되는 약속이나 돈은 어디에서 생기는가?
2. 현재 상태를 최종적으로 믿는 시스템은 무엇인가?
3. 어떤 행동은 에이전트가 준비만 하고 사람이 반드시 실행하거나 승인해야 하는가?
4. 사람의 집중을 즉시 깨도 되는 사건은 무엇인가?
5. 수집하면 안 되는 대화와 보존하면 안 되는 데이터는 무엇인가?
6. 실제 완료를 증명하는 근거는 채널별로 무엇인가?

초기 산출물
- 현재 흐름도
- 그대로 지킬 불변 조건
- 조직별로 결정한 로컬 규칙
- 아직 답이 없는 결정
- 실제 사건 1건을 이용한 shadow run 결과

shadow run 완료 기준
- 원문 근거를 찾았다.
- owner/next_action/due를 만들었다.
- 사람이 보기 전 준비 가능한 것을 끝냈다.
- 위험한 행동은 실행하지 않았다.
- 사람이 실제 행동한 뒤 원본 증거로 상태가 닫혔다.
- 사용자의 정정을 규칙과 일회성 사실로 구분했다.

이 계약에서 중요한 건 에이전트가 질문부터 시작하지 않는다는 점이다. 먼저 기존 시스템을 보고 무엇을 이미 알고 있는지 정리한다. 질문은 조사로 알 수 없고 답에 따라 구조가 달라지는 것만, 한 번에 하나씩 묻는다.

처음부터 완벽한 전체 자동화를 설계할 필요도 없다. 실제 사건 하나로 shadow run을 해보면 금방 드러난다. 근거가 부족한지, 사람에게 너무 일찍 넘기는지, 완료 증거가 없는지, 알림만 하나 더 만든 건지 알 수 있다.

11. 아직 완성됐다고 말하지 않는 이유

이 글은 완성된 제품 소개서가 아니다. 지금 HGO는 사건, 의무, 큐, 산출물, 발송 근거를 다루는 구조로 진화하고 있지만, 모든 외부 메신저와 통화가 같은 수준으로 연결된 것은 아니다. 자동 재판정과 실행 표면도 계속 복원하고 다듬는 중이다.

이 점을 숨기고 싶지 않다. 이 시스템의 철학 자체가 "그럴듯한 완료 보고보다 실제 상태를 믿자"이기 때문이다.

그래도 방향은 분명하다. 나는 더 많은 메시지를 한곳에서 읽고 싶은 게 아니다. 내가 한 약속이 사라지지 않고, 에이전트가 준비할 수 있는 일은 미리 끝나 있고, 내가 책임져야 할 판단만 정확한 근거와 함께 도착하기를 원한다. 그리고 내가 행동한 결과가 다시 시스템에 들어가 다음 판단을 바꾸기를 원한다.