작전회의 — AI 직원이 매일 아침 나에게 일을 제안하게 만들기

왜 작전회의가 필요했나

AI 직원들을 더 쓰고 싶은데, 정작 매번 내가 “뭘 시키지”를 발명해야 했다. 비서가 있어도 위임할 일을 내가 떠올려야 하면, 병목은 여전히 나다. 그래서 방향을 뒤집었다. 내가 일을 던지는 구조가 아니라, 직원이 먼저 일을 제안하고 나는 버튼 하나로 판단하는 구조를 만들기로 했다.

이번 이름은 작전회의다. 매일 아침 애니가 둘러볼 만한 것을 훑고, 제안 카드 몇 장을 올리고, 나는 관심 있는 카드만 누른다. 관심을 누른 뒤 스레드에 다시 들어가 “진행해”라고 말하는 것도 이상했다. 카드가 이미 무엇을 할지 말하고 있다면, 관심 클릭은 곧 착수 신호여야 한다.

즉, 목표는 더 똑똑한 잡담 비서가 아니라 먼저 제안하는 직원 + 원탭 판단 + 좁은 실행 계약이었다.

먼저 스레드가 일을 할 수 있는지 봤다

처음 확인한 것은 거창한 자동화가 아니었다. 카드 스레드 안에서 애니가 정말 대화 맥락을 물고 답할 수 있는지부터 봤다. 멘션을 달고, 이어서 스레드에 질문을 던졌다. 애니는 앞 대화와 채널 식별자를 잡고 답했다.

여기서 작은 사실도 하나 나왔다. 애니는 채널 이름을 직접 아는 게 아니라 메타데이터의 ID를 본다. 그러니 직원에게는 “이 ID가 #작전회의다”라는 사무실 지도를 별도로 줘야 했다. 사람에게 당연한 공간 감각도 에이전트에게는 계약이다.

그 다음부터는 논스톱 구축이었다. 애니의 제안 렌즈, 실행 러너, 카드 렌더러, 장부, 플러그인, 오프라인 어서션까지 한 줄로 깔았다. 검수는 중간에 끊지 않고, 일단 끝까지 만든 뒤 실물로 하기로 했다.

카드가 제안하고 버튼이 판단하게 했다

첫 실사격에서 애니는 실제 제안 3건을 올렸다. 중요한 건 제안 자체보다 폼이었다. 카드가 사람에게 판단을 요구하려면, “왜 지금” 같은 라벨을 장황하게 붙이는 것보다 제목·근거·집행 범위가 눈에 바로 갈라져야 했다.

그래서 카드 폼을 다시 깎았다.

• 제목: 가장 크게 보이는 한 줄. 내가 눌러야 할 판단 대상이다.
• 근거: 왜 이 일이 지금 후보인지 설명한다.
• 집행 범위: 누르면 어디까지 알아볼지 작게 붙인다.
• 상태: 순번이나 장식 대신, 버튼과 스레드의 실제 변화로만 보여준다.

처음엔 “관심” 버튼이 말 그대로 관심 표시였다. 그런데 이건 한 번 더 사람을 부른다. 관심을 누르고 스레드로 들어가 다시 진행 지시를 해야 한다면 버튼의 의미가 약하다. 그래서 설계를 바꿨다. 관심 = 진행이다. 버튼 핸들러가 바로 실행 스크립트를 띄우고, 결과는 같은 카드 스레드에 남긴다.

이 구조에서 사람의 판단은 얇아진다. “이 제안이 볼 만한가”만 고르면 된다. 나머지는 직원이 가져간다.

가장 큰 사고는 가짜 완료였다

여기서 첫 번째 사고가 났다. 관심을 두 개 눌렀는데 스레드에 결과가 남지 않았다. 그런데 시스템은 완료처럼 보였다. 나중에 보니 애니가 조사는 했다. 문제는 실행 스크립트가 조사 결과 본문을 게시 단계로 넘기는 배관에서 증발시켰고, 그래도 “완료” 도장을 찍었다는 점이었다.

완료는 스크립트 마커가 아니라 산출물 실물을 보고 말한다.

이 문장이 다시 확인됐다. 실행 로그가 끝났다는 사실과 사용자가 볼 산출물이 생겼다는 사실은 다르다. 게시 0발인데 완료라고 말하는 시스템은 거짓말을 하는 시스템이다.

처방은 단순했다.

문제	처방
결과 본문이 게시 단계에서 사라짐	조사 결과를 실행 파일로 먼저 보존한다
게시가 0발이어도 성공 처리	0발이면 실패로 잡는다
스레드에 실제로 떴는지 모름	Slack API로 댓글 실물을 다시 확인한다

핵심은 “좋은 마음으로 더 조심한다”가 아니었다. 완료 조건을 산출물 쪽으로 옮기는 것이다. 사용자가 읽을 수 있는 댓글이 없으면 완료가 아니다.

두 번째 사고는 같은 모델의 품질 차이였다

배관을 고친 뒤에도 바로 만족스럽지는 않았다. 재실행 결과가 결론 없는 산문처럼 나왔고, 슬랙 화면에서는 마크다운 표까지 깨졌다. 여기서 원인을 모델 탓으로만 돌리면 쉬웠다. 하지만 같은 gpt-5.5가 한쪽에서는 근거 있는 제안을 만들고, 다른 한쪽에서는 기대 이하의 실행 댓글을 냈다.

차이는 모델이 아니라 하네스였다.

구간	먹인 것	결과
제안 러너	렌즈, 후보 기준, 근거, 금지 규칙	비교적 쓸 만한 제안 카드
실행기	빈약한 맥락, 흐린 출력 계약	결론이 약한 댓글

그래서 실행기에도 계약을 박았다.

• 첫 줄은 결론: 바로 답을 말한다.
• 20줄 상한: 스레드 댓글은 리포트가 아니라 응답이다.
• 슬랙 문법만 사용: 표, 깨지는 볼드, 파일 링크를 금지한다.
• 출처는 3개까지: 근거는 남기되 화면을 덮지 않는다.
• 계약 위반 방어 변환: 모델이 깨지는 문법을 내도 렌더 직전에 안전한 형태로 바꾼다.

즉, 같은 모델도 어떤 컨텍스트와 출력 계약을 먹이느냐에 따라 전혀 다르게 일한다. 모델의 지능은 출발점이고, 하네스는 그 지능이 화면에 닿는 모양을 결정한다.

제안도 아무 일이나 올리면 안 된다

작전회의가 매일 아침 돈다면 제안 품질도 중요하다. “기준 세우기”, “표 만들기”, “한번 정리하기” 같은 메타 작업만 올라오면 회의가 곧 잡음이 된다. 그래서 애니의 제안 렌즈에는 5관문을 세웠다.

• 실물성: 누르면 받아볼 결과물이 있어야 한다.
• 즉시성: 오늘 확인할 이유가 있어야 한다.
• 범위성: 실행 시간이 과하게 늘어나지 않아야 한다.
• 판단성: 내가 고를 가치가 있어야 한다.
• 비반복성: 이미 정한 일의 단순 반복이면 카드로 올리지 않는다.

이건 능동성을 통제하는 장치다. 직원이 먼저 제안하게 만들수록, 제안하지 말아야 할 것도 명확해야 한다. 자유를 주는 대신 회의실 입구에 필터를 세운다.

마지막 검증은 무개입 완주였다

수정 뒤에는 검증 카드 한 장으로 다시 쐈다. 클릭, 조사, 스레드 댓글까지 사람이 중간에 개입하지 않고 46초에 끝났다. 그 다음 매일 08:30에 작전회의가 돌도록 크론을 등록했다.

이번 구축에서 얻은 값은 자동화 하나보다 크다.

• 위임 부담 제거: 내가 할 일을 떠올리는 부담을 직원 쪽으로 넘겼다.
• 판단의 버튼화: 깊은 지시는 버튼 하나의 판단으로 압축했다.
• 완료의 실물화: 로그가 아니라 화면에 남은 댓글을 완료 조건으로 삼았다.
• 하네스의 중요성 확인: 같은 모델도 계약이 다르면 전혀 다른 직원처럼 일한다.

내 감각으로 헤르메스는 깊은 지식 노동자라기보다 상주 노동자에 가깝다. 매일 같은 일을 얕은 판단으로 반복하고, 조금씩 숙달해 나가는 쪽에 값어치가 있다. 반대로 두꺼운 맥락을 붙잡고 한 번에 깊게 파는 일은 별도 세션 에이전트가 더 맞다.

그래서 결론은 “상주 직원을 더 똑똑하게 만들자”가 아니었다. 판단을 버튼과 계약으로 작게 자르고, 반복 가능한 노동으로 바꾸자는 쪽이었다. 작전회의는 그 구조의 첫 실물이다.