AI 자율 주간회의는 실제 문제를 어떻게 해결할까

AI 자율 주간회의를 운영한다고 시스템이 저절로 나아지는 것은 아닙니다. 회의에서 발견한 문제가 "다음 주에 고치자"는 문장으로만 남으면 담당자와 완료 기준이 흐려집니다. 다음 회의에서는 같은 문제를 처음부터 다시 다루게 돼요. 실제 수정과 검증으로 이어지지 않는 AI 자율 주간회의는 기록을 잘 만드는 장치에 머뭅니다.

BigValue의 AI 자율 주간회의는 회의록을 만드는 데서 멈추지 않습니다. 평시 기록에서 이상 징후와 막힌 일을 문제로 올리고 회의에서 해결 방향을 정한 뒤 주관 Agent의 파이프라인이 액션아이템에 상태를 부여해 티켓으로 바꿉니다. 티켓은 담당 역할과 완료 기준, 의존성을 담고 칸반을 따라 움직여요. Agent가 코드나 도구를 수정하면 커밋과 산출물, 테스트 결과로 문제가 실제로 줄었는지 확인하고 사람의 승인을 거쳐 운영에 반영합니다.

이번 글에서는 자율 주간회의가 실제 문제를 발견한 뒤 해결 가능한 티켓으로 바꾸고 수정과 검증을 거쳐 해소하는 과정을 살펴봅니다. Agent들이 평시 기록을 읽어 현황을 보고하고 회의록을 만드는 과정은 첫 번째 글에 정리했습니다.

평시 기록에서 발견한 문제는 티켓으로 구체화되고 해결안은 검증과 사람의 승인을 통과한 뒤 운영에 반영됩니다. 커밋과 산출물은 다음 회의가 문제 해소 여부를 다시 판단하는 증거가 됩니다.

회의에서 발견한 문제를 액션아이템으로 고정합니다

회의록은 그 시점의 결론을 설명하는 문서입니다. 반면 실행할 일에는 현재 상태와 담당자, 기한, 완료 기준이 필요해요. 회의록에 두 역할을 함께 맡기면 문장은 남아도 일이 어디까지 진행됐는지 추적하기 어렵습니다.

그래서 회의가 끝나면 주관 Agent의 파이프라인이 액션아이템을 후속 티켓 후보로 바꿉니다. 티켓은 별도 시스템 대신 팀 메신저의 다른 포럼에 스레드로 발행해요. 회의가 열린 장소와 업무를 추적하는 장소가 같은 메신저 안에 있지만 회의 스레드와 티켓 스레드의 수명주기는 분리합니다.

후속 티켓은 회의록 파일만으로 발행하지 않습니다. 실제로 게시된 회의 스레드와 메시지 식별자가 있어야 움직여요. 파일만 만들어지고 메신저 게시가 실패한 상황에서 후속 티켓이 생기는 일을 막기 위한 조건입니다.

업무는 말이 아니라 상태로 남아야 다음 주까지 이어집니다. 그래서 회의록의 문장을 티켓으로 옮깁니다.

액션아이템을 해결 가능한 티켓으로 바꿉니다

티켓 발행을 실행하는 주체는 Agent입니다. 다만 LLM이 새 안건을 판단하지는 않아요. 감지 규칙이 회의록과 주간보고에서 정해진 표식을 찾아 후보를 만들고 제목과 담당 역할, 우선순위, 스프린트, 기간, 완료 기준, 의존성을 템플릿에 채웁니다. 규칙 밖에서 새로 등장한 안건은 자동 발행하지 않고 사람이 회의 맥락과 책임 범위를 검토합니다.

자동 발행에는 중복 방지도 필요합니다. 같은 회의를 다시 처리했을 때 동일한 티켓이 두 번 생기면 칸반 상태가 갈라지기 때문이에요. 파이프라인은 내용을 요약한 식별값과 포럼의 기존 제목을 대조하고 이미 발행한 항목은 건너뜁니다.

담당 역할도 추측하지 않습니다. 각 Agent에게 등록된 업무 범위 안에서만 배분해요. 소집 단계에서 등록되지 않은 Agent 이름을 비슷하다는 이유로 연결하지 않는 것과 같은 기준입니다.

회의록의 액션아이템
  → 감지 규칙으로 티켓 후보 추출
  → 제목 | 담당 | 우선순위 | 기간 | 완료 기준 | 의존성 채움
  → 중복 지문과 기존 티켓 대조
  → 메신저 포럼에 티켓 발행

회의와 티켓을 분리해도 게시 식별자와 내용 식별값으로 연결 관계를 남깁니다. 같은 회의록을 다시 처리해도 중복 티켓은 생기지 않습니다.

자동화 범위는 일부러 좁혔습니다. 같은 회의록을 여러 번 읽어도 티켓이 중복되지 않게 하고 규칙 밖 판단은 사람에게 남겼어요. 발행 속도보다 책임 범위를 분명히 하는 쪽을 택했습니다.

문제가 해결될 때까지 칸반으로 추적합니다

발행된 티켓은 대기부터 차단까지 일곱 단계의 칸반을 따라 움직입니다. 회의록에서 판정한 상태는 정해진 표를 거쳐 티켓 상태로 바뀌어요. 완료는 완료로, 검증중은 검증으로, 보류는 차단으로 옮깁니다.

한 보고가 여러 티켓을 묶어 "완료"라고 말하면 티켓별 상태는 검증으로 낮춥니다. 어떤 티켓에 대한 완료 주장인지 분리되지 않았기 때문이에요. 한 줄의 완료 보고만으로 여러 티켓이 한꺼번에 닫히지 않게 합니다.

티켓 사이의 순서는 의존성 조건이 강제합니다. 데이터 수집 티켓이 막혀 있으면 그 데이터를 쓰는 분석 티켓은 완료로 갈 수 없어요. 증거가 없거나 해석할 수 없으면 다음 단계로 넘기지 않고 보수적으로 판정합니다.

상태 변경은 원본 보드를 매번 덮어쓰지 않습니다. 변경 내역을 별도 기록에 쌓고 읽는 시점에 합치며 갱신마다 출처와 시각을 남겨요. 늦게 도착한 과거 실행 결과가 최신 상태를 되돌리는 일을 막기 위한 구조입니다.

사람의 결정을 기다리는 항목은 진행 중인 것처럼 꾸미지 않습니다. 보류 상태로 남기고 실제 반영 없이 결과만 보여주는 시험 실행으로 확인해요. Agent는 반복 가능한 상태 반영을 맡고 규칙 밖 결정은 사람이 승인합니다.

해결됐다는 판단은 증거로 확인합니다

티켓이 만들어졌다고 개선이 끝난 것은 아닙니다. Agent가 "완료했습니다"라고 보고해도 확인할 기록이 없으면 검증중으로 남아요. 로그와 링크, 수치, 티켓 번호처럼 대조할 수 있는 근거가 필요합니다.

개발 작업에서 가장 먼저 확인하는 신호는 git 커밋입니다. 수집기는 git 이력과 위키, 티켓, 문서, 캘린더를 함께 읽어요. 다섯 소스 중 하나라도 읽지 못하면 그날의 완료 판정을 거부합니다. 가져온 내용은 길이를 제한한 뒤 이메일과 인증 정보를 가립니다.

커밋량은 진척이 아닙니다. 커밋은 무언가 움직였다는 신호일 뿐이에요. 테스트 결과와 산출물, 티켓 상태가 함께 있을 때만 완료를 인정합니다.

Agent의 완료 보고
  → 담당 티켓 확인
  → git | 위키 | 문서 | 캘린더 기록 대조
  → 테스트 결과와 산출물 검사
  → 완료 또는 검증중 판정

신호가 충돌하면 억지로 하나의 결론으로 맞추지 않습니다. 커밋은 있는데 테스트가 실패했거나 티켓이 아직 차단 상태라면 불일치로 표시해요. 기록이 조용하다는 이유만으로 완료 처리하지 않고 근거에 없는 완료 날짜도 만들지 않습니다.

초기 판정기는 "완료"라는 단어가 있는지만 봤습니다. "미완료"를 완료로 읽은 뒤 단어 판정을 고쳤지만 그것만으로는 부족했어요. 이 일을 계기로 완료 여부를 표현이 아니라 증거를 대조해 판단하도록 바꿨습니다.

해결책은 검증과 승인 뒤 운영에 반영합니다

티켓을 완료로 바꾸려면 말이 아니라 실행 결과가 필요합니다. 코드와 도구, Agent의 스킬 수정안은 격리된 평가 환경에서 먼저 검증해요. 실패를 재현하고 수정한 뒤 같은 평가를 다시 돌려, 문제는 줄었지만 다른 동작이 깨지지 않았는지 확인합니다.

검증을 통과해도 바로 운영에 반영하지 않습니다. 사람이 수정 내용과 결과를 승인해야 운영 기준으로 채택해요. Agent가 제안하고 시험할 수는 있지만 운영 코드를 바꾸는 마지막 권한은 분리합니다.

수정 가능한 파일도 미리 제한합니다. 형식 검사와 빌드를 통과해야 산출물을 발행하고 중간 단계가 실패하면 변경을 되돌려요. 승인되지 않은 결과가 서버의 기준선을 바꾸지 못하도록 git을 변경 경계로 삼습니다.

그만큼 반영은 느려집니다. 검증과 승인 단계를 거치므로 회의 직후 모든 변화가 적용되지는 않아요. 대신 회의록의 완료에는 증거가 붙고 운영 기준선은 검증하지 않은 수정으로 깨지지 않습니다.

실제 문제: 38건의 공격 시도를 어떻게 해소했나

이 흐름이 실제 스프린트에서 어떻게 움직였는지 보겠습니다. 5월 말의 금요일 회의에서 모니터링 Agent는 적대적 프롬프트 38건을 보고했어요. 시스템 지시를 바꾸거나 공개하라고 요구한 인젝션 유형이 21건, 정보 탈취 시도가 9건, "이 단지 사면 무조건 오르죠"처럼 투자 단정을 유도한 시도가 8건이었습니다.

탐지 집계는 회의의 참고 수치로 끝나지 않고 대응 원칙과 구현 티켓을 나누는 기준으로 쓰였습니다.

자율 주간회의는 탐지 건수를 단순 집계로 끝내지 않고 탐지 결과를 세 가지 대응 방식으로 나눴습니다. 지시 변경과 시스템 노출, 다른 세션 접근 요청은 차단하고 도메인 밖 요청은 정중히 거절하는 대응안을 구현 티켓 후보로 올렸어요. 보장성 단정을 금지하고 확인한 데이터로만 답한다는 원칙은 팀의 공통 응답 기준으로 정리했습니다.

세 가지 후속 작업은 다음 스프린트에 등록됐습니다. 인젝션과 정보 탈취를 차단하고 투자 결과를 보장하는 표현을 금지하며 탐지 건수는 주간 리포트에서 계속 관찰하기로 했어요. 하나의 보고가 원칙과 구현, 관찰 업무로 나뉜 셈입니다.

Agent는 티켓에 적힌 완료 기준에 따라 가드레일을 수정하고 격리 환경에서 같은 공격 유형을 다시 평가합니다. 테스트와 산출물이 기준을 통과한 뒤 사람의 승인을 받아 운영에 반영해요. 반영된 변경은 다시 git 커밋과 실행 결과로 남습니다.

이 문제는 회의에서 대응 문구를 정리하는 것으로 끝나지 않았습니다. 탐지 로그가 안건이 되고 안건이 티켓이 되며 티켓이 검증된 코드 변경으로 이어졌어요. 변경 결과를 보여 주는 기록은 다음 회의가 읽을 새로운 입력이 됩니다.

해결되지 않은 문제는 다음 회의로 돌아옵니다

문제가 실제로 해결됐는지는 다음 자율 주간회의에서 다시 확인합니다. 금요일에는 주관 Agent의 의제 생성 절차가 운영 지표와 칸반 상태, 지난 결정 로그를 다시 읽어요. 완료되지 않은 티켓은 현재 상태 그대로 돌아오고 오래 멈춘 티켓에는 정체 기간과 해제 조건이 붙습니다.

회의 보고
  → 액션아이템
  → 티켓 발행과 칸반 상태
  → 수정안 검증과 사람 승인
  → 커밋 | 산출물 | 실행 결과
  → 다음 주 의제와 보고

이렇게 지난주의 약속은 회의록 속 문장으로만 남지 않습니다. 티켓 상태와 증거가 다음 주 보고의 재료가 되고 완료되지 않은 일은 기억에 의존하지 않고 다시 드러납니다.

실패를 모두 자동으로 복구하지는 않습니다. 전체 체인을 다시 돌리면 보고가 중복 게시되거나 첫 실행 당시의 입력과 맥락을 잃을 수 있기 때문이에요. 대신 티켓 발행 실패와 증거 없는 완료, 오래 멈춘 상태를 각각 기록하고 마지막 감시가 사람에게 알립니다.

한계는 여전히 남습니다. 증거 형식은 확인하지만 모든 링크의 실제 내용까지 검증하지는 못하고 감지 규칙은 입력 형식이 바뀌면 함께 고쳐야 해요. Agent가 스스로 제안한 새 의제도 검토와 시험 운영을 통과하기 전에는 바로 발행하지 않습니다.

발견한 문제를 티켓으로 바꾸고, 검증을 거쳐 해결합니다

AI 자율 주간회의의 결과는 회의록이 아니라 해결된 문제로 확인해야 합니다. 액션아이템이 담당과 완료 기준을 갖춘 티켓으로 바뀌고 수정안이 검증과 승인을 거쳐 운영에 반영돼야 문제가 실제로 줄어듭니다. 그 과정은 커밋과 산출물로 남습니다.

다음 자율 주간회의는 그 기록을 다시 읽습니다. 완료된 티켓은 증거와 함께 닫히고 막힌 티켓은 풀리는 조건과 함께 의제로 돌아와요. 회의에서 정한 일이 실행되고 그 결과가 다음 회의의 근거가 됩니다. 이 자율성은 사람의 판단을 없애는 것이 아닙니다. 반복 가능한 수집·판정·발행은 Agent에게 맡기고 규칙 밖 결정과 운영 반영은 사람에게 남깁니다.

이 글의 그림과 수치는 운영 기록에서 확인한 흐름을 식별 정보 없이 일반화한 것이며 실제 내부 대화 원문이나 시스템 식별자는 포함하지 않았습니다.