AI Agent 팀은 어떻게 자율적으로 의사결정할까

Agent가 늘면 실행 속도는 빨라지지만 챙겨야 할 기록도 늘어요. AI가 스스로 판단하려면 지난주에 한 일, 멈춘 일, 사람의 결정이 필요한 일을 먼저 가려야 합니다. 회의 때마다 각 Agent에게 다시 물으면 같은 상태에서도 판단이 달라질 수 있습니다.

BigValue의 Agent 팀은 이 판단 절차를 금요일 자동 주간회의로 묶었습니다. 운영·마케팅·모니터링·데이터 수집을 맡은 4개 Agent가 평소 남긴 기록을 읽고 주관 Agent가 의제를 열면 각자 다섯 줄 안에 현황을 보고해요. 판정기는 보고를 정해진 규칙에 따라 상태와 우선순위로 나누고 회의록에 남깁니다. 사람의 결정이 필요한 항목은 따로 모아요.

이 글에서 자율 의사결정은 LLM이 마음대로 결론을 내리는 일을 가리키지 않습니다. Agent 팀은 정해진 기록과 규칙으로 의제, 상태, 우선순위를 판정하고 규칙 밖 안건만 사람에게 넘겨요. 회의 결과를 티켓과 실제 개선으로 잇는 과정은 두 번째 글에서 다룹니다.

자율 의사결정은 평일 기록에서 시작됩니다

판단 근거는 금요일 회의가 열리기 전부터 쌓여요. 4개 Agent의 업무 파이프라인이 평일마다 리포트와 상태 기록을 남기기 때문입니다. 금요일에 지난 일을 기억해 내는 대신, 이미 쌓인 산출물을 회의 형식에 맞춰 다시 읽습니다.

Agent의 역할은 이름이나 성격보다 평소 맡는 일에서 드러납니다. 각 Agent는 자기 봇 계정과 작업 디렉터리인 워크스페이스를 쓰고 도구는 그 경계 안의 파일과 집계 조회로 제한돼 있어요. "API 호출 없이 수치를 기억으로 말하지 않는다" 같은 금지 규칙도 문서로 남깁니다.

금요일 보고는 이 산출물에서 출발합니다. 운영 Agent는 운영 리포트를, 모니터링 Agent는 감시 결과를 읽어요. Agent 팀은 기억이 아니라 기록을 근거로 판단합니다.

판단 근거는 세션 밖에 남깁니다

Agent별 대화 세션은 오래 멈춰 있으면 초기화될 수 있습니다. 회의 보고도 평시 대화가 섞이지 않도록 별도 세션에서 진행해요. 다음 주까지 이어져야 할 정보를 세션에만 두면 회의 때마다 맥락이 끊깁니다. 그래서 진행 현황은 티켓 보드와 워크스페이스 문서처럼 세션 밖 기록에 남깁니다.

4개 Agent는 서로의 대화 세션을 읽지 않습니다. 공유할 내용은 산출물이나 티켓 상태로 남겨요. 기록하지 않은 맥락은 회의에서 빠지지만 세션이 초기화돼도 진행 현황은 확인할 수 있습니다.

상태를 바꿀 때 원본 보드 파일을 직접 고치지 않습니다. 변경 내역은 별도 상태 파일에 쌓고 보드를 읽을 때 원본과 합쳐요. 각 변경에 출처와 전이 시각을 붙여 이전 실행 결과가 늦게 도착해도 최신 상태를 덮어쓰지 못하게 합니다.

Agent에게 전달할 업무도 지난주 문구를 그대로 복사하지 않아요. 회의 직전에 보드를 다시 읽어 현재 티켓 내용으로 채웁니다. 지난주 액션아이템이 티켓 상태로 남기 때문에 최신 상태가 이번 주 보고에 이어집니다.

첫 번째 결정: 무엇을 의제로 올릴지 고릅니다

회의 의제는 주관 Agent가 준비합니다. 하지만 LLM이 새 안건을 떠올리는 방식은 아니에요. 의제 생성은 일반 프로그램이 맡습니다. 금요일 12시 30분에 운영 지표 리포트와 티켓 칸반 상태, 지난 회의의 결정 로그에서 조건에 맞는 항목을 골라 정해 둔 형식에 채웁니다.

같은 기록을 넣으면 같은 의제가 나옵니다. LLM은 의제가 아니라 각 Agent의 현황 보고를 요약할 때만 써요. 의제는 주관 Agent 하나가 조립하지만 재료는 4개 Agent가 평일에 남긴 산출물입니다.

집계 산출물만 읽으면 지난 대화의 표현이나 분위기에 따라 의제가 달라지지 않습니다. 대화 원문에 담긴 개인정보가 회의 기록으로 다시 들어갈 위험도 줄어요.

오래 멈춘 티켓에는 "지연"만 표시하지 않습니다. 멈춘 기간과 함께 어떤 역할이 무엇을 첨부해야 다시 진행할 수 있는지 적어요. 의제는 독촉 목록보다 정체를 푸는 조건에 가깝습니다.

Agent 팀은 70분 동안 같은 판단 순서를 따릅니다

오후 1시가 되면 주관 Agent가 팀 메신저의 포럼에 회의 스레드를 열고 의제와 보고 형식을 게시합니다. 사람이 지켜보다 필요할 때 끼어들 수 있도록, 별도 회의 도구가 아니라 팀이 이미 쓰는 메신저에서 진행해요.

회의 전용 중계기(dispatcher)는 멘션을 받으면 등록된 Agent를 차례로 호출합니다. 먼저 발신 계정과 회의 표식, 포럼과 스레드가 허용 목록에 있는지 확인해요. 등록되지 않은 이름은 비슷해 보여도 연결하지 않습니다. 호출 범위를 좁혀 잘못된 실행과 Agent 사이의 무한 왕복을 막습니다.

호출된 Agent는 자기 워크스페이스의 최신 리포트와 담당 티켓 상태를 읽어 현황을 작성해요. 중계기는 응답을 이미 알고 있는 회의 스레드에 각 Agent 계정으로 게시합니다. 하나가 늦거나 실패해도 그 사실을 기록하고 다음 Agent로 넘어가므로 한 Agent의 장애가 회의 전체를 멈추지 않습니다.

오후 1시 30분에는 보고를 상태와 우선순위로 나눠 회의록을 만듭니다. 완료라고 했지만 확인할 근거가 없으면 상태를 검증중으로 낮추고 사람의 결정이 필요한 항목은 따로 모아요. 오후 1시 40분에는 당일 의제와 회의록이 실제로 게시됐는지, 이번 의제가 지난주와 사실상 같지 않은지 확인합니다.

LLM은 4개 Agent가 현황을 요약할 때만 씁니다. 의제 조립과 소집, 판정, 감시는 정해진 규칙으로 처리해요.

12:30 의제 조립 — 운영 지표 | 티켓 상태 | 지난 결정
  → 13:00 회의 스레드 개설과 4개 Agent 소집
  → Agent별 현황 보고 — LLM이 쓰이는 구간
  → 13:30 증거 대조와 회의록 게시
  → 13:40 게시 여부와 의제 반복 감시

시간표가 고정돼 있어 매주 같은 입력과 확인 지점을 거칩니다. 여기서 자율 의사결정은 자유로운 대화가 아닙니다. 정해진 입력을 일정한 순서로 읽고 정해진 조건으로 상태와 우선순위를 판정하는 일입니다.

같은 보고 형식이 판단 입력을 맞춥니다

주관 Agent는 회의 스레드에 보고 형식도 함께 올립니다. Agent가 자유롭게 쓰는 부분은 다섯 줄 안의 현황입니다. 현재 상태, 확인한 증거, 다음 계획, 필요한 결정을 담아요. 회의록 한 행으로 옮길 수 있을 만큼 형식을 좁히되, 상황을 설명할 여지는 남깁니다.

상태
  → 확인한 증거와 실행 결과
  → 다음 계획
  → 필요한 결정

지시문에는 스레드 정보와 담당 업무, 금지 규칙을 코드로 조립해 넣습니다. 초기에는 Agent가 새 스레드를 직접 찾다가 실패해 "스레드가 없다"고 답한 적이 있었어요. 이제 Agent는 게시 위치를 찾지 않습니다. 중계기가 응답을 받아 이미 알고 있는 스레드에 올립니다.

응답이 비어 있어도 중계기는 내용을 지어내지 않습니다. 중립적인 실패 문구만 남기고 품질 검사에서 빈 보고로 분류해요. 지시문을 그대로 되풀이한 응답도 회의록에 올리지 않습니다.

형식을 제한하면 발언의 자유는 조금 줄어듭니다. 대신 네 보고를 같은 회의록 표에 합칠 수 있고 실패한 보고도 가려낼 수 있어요. 자동 회의에서는 풍부한 표현보다 다음 단계가 안정적으로 해석할 수 있는 입력이 먼저입니다.

두 번째 결정: 상태와 우선순위를 증거로 판정합니다

보고가 모였다고 바로 회의록을 게시하지는 않습니다. 판정기는 중계기가 남긴 기록에서 각 Agent의 보고만 골라 개인정보와 인증 정보를 가린 뒤, 담당 티켓과 대조해요. 상태는 완료·검증중·진행중·보류 네 가지로 제한합니다.

초기에는 보고에 "완료"라는 단어가 있는지를 봤습니다. 하지만 "미완료"에도 완료가 들어갑니다. 실제로 미완료를 완료로 읽는 오류가 난 뒤, 판정의 중심을 단어에서 증거 대조로 옮겼습니다.

완료라고 쓰려면 로그와 링크, 수치, 티켓 번호처럼 확인 가능한 근거가 필요합니다. 근거가 없으면 검증중으로 낮춰요. 같은 보고에는 언제나 같은 결과가 나오도록 판정 순서와 증거 조건을 코드와 테스트로 고정합니다.

Agent 보고
  → 담당 티켓 대조
  → 상태와 우선순위 판정
  → 완료 근거 검사
  → 회의록 표 한 행

회의록도 자유 형식으로 쓰지 않습니다. 한 줄 결론과 Agent별 보고를 비롯해 사람의 분석 결정과 제품 결정처럼 필요한 섹션을 정해 둡니다. 전원 보고가 모이지 않거나 품질 조건을 통과하지 못하면 게시를 미뤄요. 완료로 분류되는 항목은 줄어도 각 항목에는 확인할 근거가 남습니다.

세 번째 결정: 근거가 없으면 판단을 멈춥니다

세 번째로 정할 것은 판단을 멈추는 조건입니다. 근거가 부족하면 억지로 결론 내리지 않고 실패해도 회의 전체를 자동으로 다시 돌리지 않습니다. 처음부터 재실행하면 같은 보고가 두 번 올라가거나 첫 실행 당시의 맥락이 달라질 수 있기 때문이에요. 대신 어디에서 실패했는지 분명히 남깁니다.

소집이 막히면 어떤 조건에서 건너뛰었는지 로그에 남고 증거 없는 완료는 검증중으로 낮아집니다. 동시에 들어온 상태 갱신은 전이 시각으로 구분하고 지시문을 되풀이한 보고는 품질 검사에서 걸러요. 마지막 감시 단계는 당일 회의가 실제로 열렸는지와 산출물이 갱신됐는지를 사람에게 알립니다.

한계도 분명합니다. 증거 형식은 확인하지만 모든 링크가 실제로 열리는지까지 검사하지는 못해요. 입력 형식이 바뀌면 감지 규칙도 함께 고쳐야 합니다. 자동 복구를 줄인 만큼 사람이 직접 처리할 일도 남습니다.

대신 성공처럼 보이는 실패를 찾아냅니다. 회의 스레드가 열렸더라도 지난주 의제가 그대로 복사됐다면 실행 성공 로그만으로는 알 수 없어요. 지난주와 이번 주 의제의 유사도를 계산해 거의 같을 때 경보를 울립니다.

같은 기록과 규칙이 자율 의사결정을 만듭니다

Agent 팀의 자율 의사결정은 금요일 회의에서 갑자기 시작되지 않습니다. 평일에 남긴 리포트와 티켓 상태가 의제가 되고 의제는 각 Agent가 무엇을 확인해 보고할지를 정해요. 보고는 증거와 대조된 뒤 회의록이 됩니다.

Agent 팀은 자유 토론이나 모델의 답변 품질에 의사결정을 맡기지 않습니다. 각자 다른 업무를 하더라도 같은 상태 기록을 읽고 같은 보고 형식과 판정 규칙으로 상태와 우선순위를 결정해요. 규칙 밖 안건은 억지로 결론 내리지 않고 사람에게 넘깁니다.

회의록이 다음 주의 행동으로 이어지려면 한 단계가 더 필요합니다. 두 번째 글에서는 액션아이템을 티켓으로 발행하고 커밋과 산출물로 완료를 확인해 다시 다음 회의의 입력으로 돌려보내는 과정을 살펴봅니다.

이 글의 그림은 실제 내부 스키마나 대화 원문이 아니라, 운영 기록에서 확인한 구성 요소를 식별 정보 없이 일반화했습니다.