클라이언트 프로젝트가 10개일 때, AI 에이전트로 아침 업무 보고를 자동화하는 법

한줄 요약

여러 클라이언트 프로젝트를 동시에 돌리는 에이전시라면, AI 에이전트 기반 아침 브리핑 자동화가 PM 리소스를 아껴준다.

에이전시가 아침마다 낭비하는 시간의 정체

IT 개발 에이전시에서 프로젝트 관리자(PM)나 리드 개발자가 하루를 시작하는 방식은 대체로 비슷하다. 슬랙 채널을 열고, 각 프로젝트 레포지토리의 이슈 상태를 확인하고, 어젯밤에 올라온 클라이언트 요청을 처리하고, 팀원별 진행 상황을 파악하는 루틴이다.

프로젝트가 3개일 때는 30분이면 충분하다. 하지만 동시에 운영하는 프로젝트가 7~10개로 늘어나면 이 루틴만으로 오전의 절반이 사라진다. 정작 중요한 의사결정이나 기술 검토에 쓸 집중력은 이미 소진된 뒤다.

문제의 본질은 정보가 분산돼 있다는 것이다. 프로젝트마다 별도 레포, 별도 채널, 별도 문서가 존재하고, PM은 이 사이를 계속 오가며 맥락을 재조립해야 한다. 이 컨텍스트 스위칭 비용이 에이전시 운영 효율을 조용히 갉아먹는다.

핵심 설계 원칙: 정보는 한 곳에 모아야 AI가 제대로 읽는다

AI 에이전트에게 올바른 판단을 기대하려면 먼저 데이터가 한 곳에 모여 있어야 한다. 에이전시 맥락에서 이 원칙을 적용하면 다음과 같다.

모든 활성 프로젝트의 메타데이터(클라이언트명, 프로젝트 단계, 담당 개발자, 마감일, 현재 블로커 등)를 단일 중앙 레포에 YAML 형태로 관리한다. 각 프로젝트 레포는 여전히 독립적으로 존재하지만, AI 에이전트가 참조하는 컨텍스트는 이 중앙 레포 하나에서만 읽는다.

이 구조의 장점은 명확하다. 새 프로젝트가 추가되면 중앙 레포에 YAML 파일 하나만 추가하면 된다. 에이전트 로직을 건드리지 않아도 자동으로 브리핑 대상에 포함된다. 반대로 프로젝트가 종료되면 상태 필드를 closed로 바꾸는 것만으로 브리핑에서 제외된다.

AI 브리핑 에이전트의 실제 동작 구조

자동화 파이프라인은 크게 네 단계로 구성된다.

첫째, 스케줄러(GitHub Actions 또는 외부 크론 서비스)가 매일 아침 정해진 시각에 Python 스크립트를 실행한다.

둘째, 스크립트가 중앙 레포에서 모든 활성 프로젝트의 YAML 메타데이터를 읽는다. 이때 각 프로젝트의 GitHub 레포에서 오픈 이슈, 미병합 PR, 최근 커밋 현황도 함께 수집한다.

셋째, 수집된 데이터를 LLM API(Claude, GPT 등)에 전달하고 오늘의 우선순위 브리핑을 생성한다. 이 단계에서 프롬프트 설계가 브리핑 품질을 결정한다.

넷째, 완성된 브리핑을 슬랙 워크스페이스의 지정 채널로 자동 발송한다.

에이전시 환경에서는 개인 개발자와 달리 브리핑 수신자가 PM, 팀 리드, 대표 등 여러 역할로 나뉠 수 있다. 따라서 채널을 역할별로 분리하거나, 브리핑 내용의 상세도를 수신자에 따라 다르게 설계하는 것이 현실적이다.

에이전시용 우선순위 판단 프롬프트를 어떻게 설계할까

AI에게 "오늘 뭐부터 해야 하냐"고 물으면 쓸 만한 답이 나오지 않는다. 판단 기준을 구조화해서 넣어야 한다.

에이전시 맥락에 맞는 우선순위 기준은 일반적으로 다음 네 가지 축으로 구성된다.

클라이언트 임팩트: 해당 이슈나 PR이 클라이언트의 서비스 운영에 직접 영향을 주는지 여부. 프로덕션 버그와 신규 기능 요청은 가중치가 달라야 한다.

계약 마감 압박: 납품일이나 스프린트 종료일까지 남은 시간. 이 정보는 YAML 메타데이터에 deadline 필드로 관리하면 자동으로 반영된다.

팀 간 의존성: 특정 작업이 완료돼야 다른 팀원 또는 다른 프로젝트가 진행될 수 있는 블로킹 관계. 에이전시에서 자주 발생하는 병목이다.

계약 규모와 관계 중요도: 동일한 긴급도라면 더 큰 계약이나 장기 파트너 클라이언트 건을 우선하는 비즈니스 판단.

이 네 가지 축을 점수화해서 프롬프트에 명시하면, AI가 단순 나열이 아닌 실제 의사결정에 가까운 우선순위를 출력한다.

---

한 가지 더 중요한 것은 출력 형식을 고정하는 것이다. 브리핑 형식이 매번 달라지면 빠르게 훑기 어렵다. 프롬프트에 "프로젝트명 / 오늘 해야 할 액션 1가지 / 이유 한 줄" 형태로 고정 출력하도록 지시하면 실무에서 바로 사용할 수 있는 브리핑이 나온다.

에이전시가 도입 후 달라지는 것과 남는 과제

이 구조를 실제로 운영하면 PM의 아침 루틴이 "정보 수집과 판단"에서 "브리핑 검토와 실행"으로 바뀐다. 판단을 위한 에너지 소모가 줄고, 프로젝트 누락 리스크도 낮아진다.

다만 현실적인 한계도 있다. AI는 YAML에 기록되지 않은 맥락을 모른다. 커밋이 2주째 없는 프로젝트를 에이전트는 "정체"로 판단하지만, 실제로는 클라이언트 검수 대기 중일 수 있다. 이 간극을 메우는 방법은 결국 YAML의 notes 필드를 PM이 짧게라도 업데이트하는 습관이다.

장기적으로는 프로젝트 간 의존 관계와 상태 변화의 이유를 구조화된 형태로 기록하는 온톨로지 설계가 AI 브리핑 품질의 천장을 결정한다. 에이전트에게 좋은 판단을 기대할수록, 맥락을 구조화하는 사람의 역량이 더 중요해진다.