AI 에이전트와 30분 만에 끝내는 주간 리뷰: 에이전트가 초안을 쓰고, 사람이 고치고, 팀이 읽는다

사람의 교정 단계가 핵심인 이유

자동 상태 보고서는 몇 년 전부터 있었습니다. 대부분 무시되는 이유는 정확하지만 의미가 없기 때문입니다. "이슈 14개 닫힘, 3개 열림, 속도 안정." 상태 업데이트가 유용한 때는 그 숫자가 계획에 무엇을 뜻하는지 말할 때이고, 그러려면 계획을 아는 사람이 필요합니다.

처음부터 쓰는 대신 짧고 고정된 교정 단계를 두자는 생각은 Indie Hackers 같은 창업자 커뮤니티에서 한동안 돌고 있었습니다. 도구가 사실을 모으게 하고, 제한된 시간(30분이 흔히 언급되는 수치)을 들여 그것을 메시지로 바꾸는 것입니다. 우리는 이를 증명된 방법이 아니라 합리적인 커뮤니티 관행으로 봅니다. 확실히 말할 수 있는 것은, 수집이 수작업이 아니게 된 뒤로 우리 업데이트가 "가끔, 늦게, 모호하게"에서 "매주 금요일, 구체적으로"로 바뀌었다는 점입니다.

초안은 에이전트의 것입니다. 판단은 당신의 것입니다. 그 경계가 흐려지게 두지 마세요.

주간 상태 템플릿

템플릿은 고정입니다. 에이전트가 매주 같은 방식으로 채우고 독자가 어디를 볼지 알게 하기 위해서입니다.

사람 섹션 셋, 에이전트 섹션 넷. 에이전트가 "다음 주"와 "요청"까지 쓰게 되면 리뷰는 더 이상 리뷰가 아닙니다.

단계별: 금요일 루프

1. 매주 금요일 오후 캘린더에 30분을 막아 둔다. 그 블록이 의식입니다. 없으면 리뷰는 월요일 아침에 일어나고, 그 주를 바꾸기엔 너무 늦습니다.
2. 에이전트에게 고정 브리프를 준다. 입력: 지난 7일간 닫힌 이슈, 지난 7일 마감이면서 아직 열린 이슈, 14일간 손대지 않은 열린 이슈, 목표와 최신 체크인. 출력: 위 템플릿에서 에이전트 섹션 넷을 채우고 사람 섹션은 자리표시자로 남김. 제약: 읽기 전용, 상태 변경 없음, 밀린 이유 지어내지 않음.
3. 출시 목록을 먼저 읽고 묶음을 고친다. 에이전트는 제품별로 묶지만, 때로는 고객별이나 주제별이 더 흥미롭습니다. 고치세요.
4. 밀린 날짜를 모두 확인한다. 에이전트는 이슈의 새 마감일을 보고합니다. 아무도 정하지 않았다면 그렇게 말하고, 지금 정하거나 그 이슈가 중요하지 않다고 결정합니다.
5. 정체 항목마다 처리를 결정한다. 닫기, 재배정, 또는 이유를 적고 두기. 리뷰 세 번을 살아남은 정체 항목은 정체가 아니라 일이 아닌 것입니다. 삭제하세요.
6. 헤드라인은 마지막에 쓴다. 모두 읽은 뒤 한 문장. 쓸 수 없다면 그 주가 좋았는지 모르는 것이고, 그것이 발견입니다.
7. 다음 주와 요청은 직접 쓴다. 일곱이 아니라 셋. 요청은 사람 이름을 명시합니다.
8. 팀이 읽는 곳에 게시한다. 피드 게시물이나 고정 메시지. 아무도 열지 않는 문서가 아닙니다.

브리프가 안정되면 30분이면 충분합니다. 처음 두 주는 보고서가 아니라 브리프를 고치느라 더 걸립니다.

에이전트가 읽는 것, 그리고 틀리는 것

에이전트에게는 이슈, 목표, 팀 피드의 읽기 접근만 필요합니다. 그 외에는 없습니다. Atrix에서는 MCP 서버나 에이전트 채팅을 통해 work.read, goals.read, feed.read 스코프가 해당하고, 쓰는 도구는 날짜 필터가 있는 work_list_issues, 제품별 project_status, goals_list, 그리고 이미 제품별로 한 주의 활동을 요약하는 pulse_report_latest입니다. 최종 업데이트 게시는 feed_post_update를 쓰는데, 사람들의 휴대폰에 알림을 보내므로 그 스코프는 에이전트에 주지 않고 교정 후 직접 게시합니다.

몇 주마다 보는 꾸준한 실패:

• 밀린 이유. 담당자가 휴가 중이었던 것이 진짜 이유인데, 에이전트는 댓글에서 이유를 추론합니다("디자인 대기로 막힘"). 절대 "왜"를 쓰게 하지 마세요. 에이전트는 "무엇"을 씁니다.
• 목표 진행을 선형으로 읽기. 2주 남은 상황에서 40%인 핵심 결과는 40이 0보다 크다고 해서 "정상"이 아닙니다. 체크인 문장은 당신 몫입니다.
• 같은 이슈를 두 번 세기. 닫혔다가 다시 열리고 다시 닫힌 경우. 사소하지만 "출시"를 부풀립니다.
• 지나친 공손함. 내버려 두면 초안은 "전반적으로 좋은 진전"이라고 씁니다. 그 문장을 지우세요. 판단은 헤드라인에 담기며, 때로는 "지연"이라고 써야 합니다.

에이전트 없이 하기

도구에 에이전트가 없어도 저장된 필터로 루프는 작동합니다. 어떤 트래커든 네 개의 뷰를 저장하세요. 지난 7일 닫힘, 지난 7일 마감이면서 열림, 14일간 미수정, 그리고 목표. 금요일에 순서대로 열고 템플릿에 붙여 넣고 같은 교정을 합니다. 30분 대신 45분이 걸리고, 수집은 건너뛰고 싶어지는 부분이며, 그것이 자동화의 근거입니다.

Linear의 인사이트, Jira의 대시보드, 날짜 필터가 있는 Notion 데이터베이스 모두 네 개의 뷰 역할을 합니다. 에이전트가 만드는 차이는 출시와 밀림 섹션의 첫 문장 초안이며, 10분쯤 아끼고 무엇보다 빈 페이지를 없애 줍니다.

실제 금요일

지난주 리뷰를 약간 가렸습니다. 출시: Calendar와 Pages에 걸쳐 9개, 예약 리마인더 이메일 포함. 밀림: 2개, 둘 다 Pages, 담당자와 대화 후 둘 다 다음 주 수요일로 재조정. 정체: 4개, 그중 2개는 더 이상 관련 없어 닫고 1개는 재배정. 목표: "셀프서브 활성화" 핵심 결과가 31%에서 38%로. 체크인 문장은 "움직이고 있지만 가장 큰 지렛대(체험 이메일)는 다음 주에 나가니 그때 판단". 헤드라인: "사이클 정상 진행. 목표 하나는 다음 주 체험 이메일로 결정됨." 다음 주: 체험 이메일, Android 빌드 테스터 배포, 가격 페이지 문구. 요청: Android 베타를 가격 변경 전에 내보낼지에 대한 결정 하나.

게시까지 총 시간: 28분. 에이전트 초안은 출시된 9개 이슈를 제품별로 묶었는데 이는 맞았고, 밀린 이슈 하나에 "디자인 피드백 대기로 막힘"이라고 썼는데 이는 틀려서 잘라냈습니다.

자주 묻는 질문

주간 상태 업데이트에는 무엇이 들어가야 하나요?

한 줄 헤드라인(정상, 위험, 지연), 출시된 것, 새 날짜와 함께 밀린 것, 정체된 것, 각 목표의 움직임, 다음 주 우선순위 셋, 이름을 명시한 구체적 요청. 한 화면에 담으세요.

AI 에이전트가 주간 상태를 혼자 쓸 수 있나요?

사실 섹션은 쓸 수 있습니다. 출시, 밀림, 정체, 목표 수치. 헤드라인, 밀린 이유, 다음 주 우선순위, 요청은 쓰면 안 됩니다. 그것은 계획을 아는 사람이 필요하고, 그게 30분 교정 단계입니다.

주간 리뷰는 얼마나 걸려야 하나요?

브리프와 템플릿이 안정되면 30분. 처음 두세 주는 브리프를 고치느라 더 걸립니다. 꾸준히 한 시간을 넘긴다면 템플릿이 너무 길거나 트래커가 최신이 아닙니다.

에이전트는 어떤 데이터 접근이 필요한가요?

이슈(닫힘, 마감, 마지막 수정 날짜), 목표와 체크인, 팀 피드의 읽기 접근. 고객, 채용, 급여, 무언가를 바꾸는 능력은 필요 없습니다. 읽기만 부여하고, 최종 업데이트는 직접 게시하세요.

주간 리뷰를 팀 전체에 게시해야 하나요?

네, 팀이 이미 읽는 곳에. 피드 게시물이나 채팅의 고정 메시지. 아무도 열지 않는 문서는 개인 일기입니다. 휴대폰에서 읽히도록 한 화면에 담으세요.

스프린트 회고와는 어떻게 다른가요?

주간 리뷰는 상태와 다음 주 우선순위에 관한 것이며, 30분이 걸리고 메시지를 만듭니다. 회고는 한 사이클 동안 팀이 어떻게 일했는지에 관한 것이며, 한 시간이 걸리고 프로세스 변경을 만듭니다. 둘 다 하되 합치지 마세요.

다음 단계

쓰고 있는 트래커에 네 개의 뷰(닫힘, 밀림, 정체, 목표)를 만들고 금요일 15:00을 막아 두세요. 작업이 Atrix에 있다면 프로젝트 관리에 에이전트가 읽는 사이클, 라벨, 목표 체크인이 이미 있고, 창업자 페이지에는 작은 팀이 이 루프를 처음부터 끝까지 돌리는 방법이 나와 있습니다.