소규모 팀을 위한 비동기 주간 업데이트 템플릿

주간 업데이트는 매주 같은 요일에 올리는 짧은 글로, 세 부분으로 이루어집니다. 지난주 이후 무엇이 진행됐는지, 다음 주에 무엇을 할 계획인지, 무엇이 가로막고 있는지. 제품이나 영역마다 한 사람이 담당하고, 팀 전체가 읽는 한 곳에 올립니다. 제대로 하면 쓰는 데 15분, 읽는 데 5분이면 되고, 월요일 상태 회의를 완전히 대체합니다.

템플릿은 바로 아래에 있고, 그다음에 이것이 정착하게 만드는 규칙을 다룹니다. 누가 올리고, 언제, 어디에, 그리고 아무도 읽지 않을 때는 어떻게 하는지.

주간 업데이트 템플릿

팀이 쓰는 어떤 도구에든 그대로 복사하세요. 대괄호 안만 바꾸면 됩니다.

**[제품 또는 영역] — [날짜] 주**

**상태:** 순조로움 / 위험 / 지연
**담당:** [이름]

**진행**
- [출시하거나 끝낸 항목, 링크 포함]
- [출시하거나 끝낸 항목, 링크 포함]
- [내린 결정, 기록한 위치]

**계획**
- [다음 업데이트까지 끝낼 것]
- [다음 업데이트까지 끝낼 것]
- [시작할 것]

**문제**
- [막힌 것, 풀어줄 수 있는 사람, 기한]
- [일정을 밀 수 있는 위험, 무엇이 있으면 달라지는지]
- 없음 (정말 없다면)

**숫자**
- [지표]: [값] (지난주 [값])
- [지표]: [값] (지난주 [값])

**결정이 필요한 것**
- [질문], [이름]이 요청, [날짜]까지

소제목 여섯 개, 대략 열두 줄, 한 문장을 넘는 문단은 없습니다. 누구든 엘리베이터 안에서 휴대폰으로 읽을 수 있습니다.

진행·계획·문제 형식이 통하는 이유

이 형식이 수십 년을 살아남은 것은 각 섹션이 읽는 사람의 질문 하나에 답하기 때문입니다.

진행은 "무슨 일이 있었나?"에 답합니다. 작업한 것이 아니라 끝낸 것을 적어야 합니다. "결제 화면 작업함"은 활동이고, "결제 화면을 트래픽의 40%에 적용"은 진행입니다. 각 항목에 링크를 달아 자세히 알고 싶은 사람이 묻지 않고 직접 찾아가게 하세요.

계획은 "다음 주에 무엇을 기대하면 되나?"에 답합니다. 이것은 약속이므로 세 항목으로 제한합니다. 다음 주의 진행 섹션은 이번 주의 계획과 나란히 읽히고, 그 비교에서 정직함이 나옵니다. 같은 계획이 3주 연속 나타나면, 아무도 말하지 않아도 업데이트가 문제를 드러낸 것입니다.

문제는 "어디서 내가 필요한가?"에 답합니다. 관리자가 가장 먼저 읽는 섹션이면서, 쓰는 사람이 가장 자주 건너뛰는 섹션입니다. 좋은 문제 한 줄은 막힌 것, 풀어줄 수 있는 사람, 기한을 적습니다. "법무팀 대기 중"은 불평입니다. "목요일까지 Dana의 계약 승인이 없으면 파일럿이 일주일 밀림"은 요청입니다.

추가 섹션 두 개, 숫자와 결정이 필요한 것은 선택 사항이지만, 업데이트를 회의보다 가치 있게 만드는 부분입니다. 숫자는 시간에 따른 한 주의 모양을 보여 줍니다. 결정 요청은 읽는 사람에게 답할 이유를 줍니다.

주간 업데이트는 누가 올리는가

사람마다가 아니라 제품이나 영역마다 담당자 한 명입니다. 제품이 세 개인 여덟 명 팀이라면 업데이트는 여덟 개가 아니라 세 개입니다. 개인 업데이트는 할 일 목록이 되고, 남의 할 일 목록을 읽는 사람은 없습니다.

담당자는 회의에서 "어떻게 되고 있어요?"라는 질문을 받을 사람입니다. 보통 제품 리드, 가장 많은 일을 맡은 엔지니어, 또는 리드가 정해지지 않은 것이라면 창업자입니다. 돌아가며 맡는 방식은 잘 되지 않습니다. 업데이트의 가치는 한 목소리가 한 대상을 여러 주에 걸쳐 추적하는 데서 나옵니다.

아무 일이 없어도 올리세요. "진행: 없음, 팀 전원이 컨퍼런스 참석"이라는 주도 유용한 업데이트입니다. 빠진 주는 구멍이고, 읽는 사람은 그 구멍을 걱정으로 채웁니다.

언제 올리는가

요일과 시각을 하나 정하고 옮기지 마세요. 우리가 아는 팀 대부분은 기억이 생생할 때 한 주를 마무리하는 금요일 오후, 또는 한 주를 여는 월요일 10시 이전에 올립니다. 금요일 업데이트는 어차피 월요일에 읽히므로, 선택은 대체로 쓰는 사람이 언제 쓰고 싶은지에 달렸습니다.

댓글 마감은 게시 시각으로부터 두 시간 정도 뒤로 정합니다. 그 이후에 스레드에서 해결되지 않은 것은 다음 주 문제 섹션의 항목이 되거나, 의견이 다른 두 사람 사이의 예정된 통화가 됩니다. 마감이 없으면 스레드는 일주일 내내 열려 있고, 업데이트는 끝나지 않는 회의가 됩니다.

상태 회의를 무엇이 대체하는가

상태 회의는 네 가지 일을 합니다. 진행을 보고하고, 막힌 것을 드러내고, 결정을 강제하고, 서로의 이야기를 듣게 합니다. 글로 쓴 업데이트는 앞의 두 가지를 회의보다 잘합니다. 기록이 남고 아무도 참석할 필요가 없기 때문입니다. 나머지 두 가지에는 각자의 자리가 필요합니다.

상태 회의의 역할	비동기 대체 수단	잃는 것
진행 보고	링크가 달린 진행 섹션	없음. 기록은 오히려 더 좋음
막힌 것 드러내기	사람과 기한을 적은 문제 섹션	담당자가 정직하다면 없음
결정 강제	결정이 필요한 것 섹션, 그리고 댓글 마감 후에도 남은 건만 다루는 15분 통화	속도, 하루 이틀 정도
서로의 이야기 듣기	상태 보고가 안건에 없는 짧고 선택적인 주간 통화	회의를 좋아하는 사람에게는 그 일부

효과가 있는 패턴은 이렇습니다. 상태 회의를 없애고, 모두가 업데이트를 읽었다고 전제하는 20분짜리 주간 통화를 남기며, 그 시간은 미결 결정과 대화에만 씁니다. 다룰 것이 없으면 5분 만에 끝냅니다. 통화에 참석할 가치가 생겼다는 것을 사람들이 알아차립니다.

어디에 올리는가

올바른 장소는 필요한 사람들이 이미 보고 있는 곳이며, 세 가지 조건이 있습니다. 나중에 검색할 수 있어야 하고, 그 아래에 댓글을 달 수 있어야 하며, 그날의 채팅에 묻혀 사라지지 않아야 합니다.

팀 채팅 채널은 세 번째 조건에서 탈락합니다. 활발한 채널에 올린 주간 업데이트는 점심시간이면 스크롤에 밀려 사라집니다. 채팅이 유일한 도구라면 업데이트를 고정하거나, 다른 것은 아무것도 올리지 않는 채널에 올리세요.

Slack 캔버스는 Slack 안의 문서로, 채널 탭으로 고정하고 댓글을 달 수 있습니다. Slack 도움말 센터에 따르면 캔버스는 유료 플랜에서 사용할 수 있고, Pro 플랜은 2026년 10월 기준 월간 결제 시 사용자당 월 8.75달러, 연간 결제 시 7.25달러입니다. 제품마다 캔버스 하나를 두고 매주 갱신하면 이력이 한곳에 모이고 대화 바로 옆에 놓입니다.

Basecamp 자동 체크인은 반대 방향에서 문제를 풉니다. "이번 주에 무엇을 했나요?" 같은 질문을 매일, 매주, 매월 중 하나의 주기로 설정하면 Basecamp가 각 사람에게 묻고 답을 한곳에 모읍니다. Basecamp 요금은 2026년 10월 기준 Freelancer 플랜이 월 29달러에 최대 5명, Pro가 79달러에 최대 10명, Pro Plus가 99달러에 최대 15명이며, 무료 플랜은 3명으로 제한됩니다. 체크인 방식은 개인 업데이트에 가장 잘 맞고, 숫자가 들어간 제품 단위 업데이트에는 여전히 문서가 필요합니다. 제품의 나머지 부분은 Basecamp 비교에서 다룹니다.

피드가 있는 프로젝트 도구가 우리가 쓰는 방식입니다. Atrix에서는 각 제품에 고유한 업데이트 스트림이 있는 페이지가 있고, 거기에 올린 업데이트는 워크스페이스 피드에도 올라갑니다. 업데이트에 누군가의 이름을 쓰면 그 사람에게 알림이 가고 휴대폰 푸시 알림까지 가기 때문에, 업데이트가 정말 그 사람을 필요로 할 때만 이름을 씁니다. 실제로는 문제 섹션과 결정이 필요한 것 섹션뿐이고, 그 외에는 쓰지 않습니다. 여섯 명의 이름을 적은 업데이트는 회의 소집의 다른 모습입니다. 이어지는 대화는 팀 채팅에서 합니다.

숫자 섹션의 값은 기억이 아니라 트래커에서 가져와야 합니다. Atrix MCP 서버에는 project_status 도구가 있어 제품 하나의 상태 수치를 돌려줍니다. 완료율, 상태별 작업 수, 기한이 지난 것, 일주일 넘게 진행 중이나 검토 중에 멈춰 있는 것, 앞으로 7일 안에 기한이 오는 것, 이번 주에 끝난 것. 어시스턴트에게 "project_status를 바탕으로 Checkout의 이번 주 업데이트 초안을 써 줘"라고 하면 진행과 숫자 섹션이 1분 정도 만에 나오고, 담당자는 쓰는 대신 고치기만 하면 됩니다. 문제 섹션은 대신 써 주지 않습니다. 트래커는 Dana가 휴가 중이라는 것을 모릅니다.

다섯 단계로 도입하기

담당자와 요일을 정합니다. 모두가 볼 수 있는 곳에 적어 두세요. 담당자가 분명하지 않은 제품이 있다면, 그것이 업데이트가 드러낼 첫 번째 문제입니다.
첫 업데이트는 직접 올립니다. 창업자나 리드가 위 템플릿으로 첫 업데이트를 쓰되, 진짜 문제 섹션을 넣습니다. 팀은 첫 글의 어조를 따라 하므로 정직하고 짧게 쓰세요.
둘째 주부터 상태 회의를 없앱니다. "줄이기"가 아닙니다. 회의가 남아 있으면 업데이트는 조용히 그리로 돌아갑니다.
마감 안에 읽고 답합니다. 둘째 주에 담당자는 누군가 댓글을 달았는지 확인합니다. 아무도 달지 않았다면 리드가 각 업데이트에 질문 하나씩을 답니다. 업데이트는 노력 때문이 아니라 침묵 때문에 죽습니다.
6주 뒤에 돌아봅니다. 계획 섹션과 그 뒤의 진행 섹션을 비교합니다. 계획이 거의 지켜지지 않았다면 템플릿은 제 역할을 한 것이고, 고쳐야 할 것은 계획 방식입니다.

흔한 실수

너무 길다. 휴대폰에서 스크롤이 필요하면 업데이트가 아니라 보고서입니다. 세부 내용은 링크된 페이지로 옮기세요.
한 달 내내 문제 없음. 4주 동안 문제가 전혀 없는 팀은 없습니다. 비어 있는 문제 섹션은 보통 담당자가 적기를 꺼린다는 뜻입니다. 자연스러워질 때까지 매주 문제 하나씩을 요청하세요.
성과 대신 활동. "공급업체와 세 번 통화함"은 활동입니다. "공급업체가 11월 12일 납품을 확정함"은 진행입니다.
모두의 이름을 적기. 언급한 사람에게 알림을 보내는 도구라면 이름 하나가 방해 하나입니다. 관심이 있을 법한 사람이 아니라 행동해야 할 사람의 이름을 적으세요.
지난주 값이 없는 숫자. 지표 하나만 있으면 사실이고, 지난주 값 옆에 두면 추세입니다.

자주 묻는 질문

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

최소 세 섹션입니다. 지난주 이후의 진행(끝낸 것, 링크 포함), 다음 주 계획(약속은 최대 세 개), 문제(각각 담당자와 기한 명시). 지난주 값을 나란히 적은 숫자 섹션과, 읽는 사람에게 요청하는 결정의 짧은 목록을 더하세요.

팀 주간 업데이트는 얼마나 길어야 하나요?

휴대폰에서 거의 스크롤 없이 읽을 수 있을 만큼 짧게. 150~300단어, 또는 글머리 기호 대략 열두 줄입니다. 그보다 많은 공간이 필요한 것은 업데이트를 늘리지 말고 링크된 페이지로 만드세요.

주간 상태 업데이트는 누가 써야 하나요?

제품이나 영역마다 담당자 한 명으로, 보통 리드이거나 가장 많은 일을 맡은 사람입니다. 팀원 전원의 개인 업데이트는 아무도 읽지 않는 할 일 목록이 됩니다. 제품이 세 개인 여덟 명 팀이라면 업데이트 세 개를 올려야 합니다.

글로 쓴 업데이트가 정말 상태 회의를 대체할 수 있나요?

보고에 해당하는 절반을 대체합니다. 미결 결정과 서로 대화하기 위한 짧고 선택적인 통화는 남기되, 상태 보고는 안건에서 뺍니다. 회의를 완전히 없애고 통화만 남긴 팀은 통화가 매주 짧아지는 것을 봅니다.

비동기 주간 업데이트에 좋은 도구는 무엇인가요?

업데이트를 나중에 검색할 수 있고, 댓글을 달 수 있고, 채팅에 묻혀 사라지지 않는 도구라면 무엇이든 됩니다. 채널에 고정한 Slack 캔버스, Basecamp 자동 체크인, Atrix처럼 제품별 업데이트 피드가 있는 프로젝트 도구는 모두 통과합니다. 일반 채팅 채널은 통과하지 못합니다.

주간 업데이트와 일일 스탠드업은 무엇이 다른가요?

일일 스탠드업은 다음 24시간의 조율이 목적이고 보통 사람 단위입니다. 주간 업데이트는 한 주 동안의 제품 상태가 대상이고 제품이나 영역 단위입니다. 소규모 팀은 주간 업데이트가 안정되면 보통 일일 스탠드업을 없앨 수 있습니다.

다음 단계

업데이트가 작업 바로 옆에 있으면 진행 섹션은 거의 저절로 채워집니다. 제품, 사이클, 업데이트 피드가 어떻게 맞물리는지는 Atrix 프로젝트 관리에서 확인하거나, 지금 쓰는 도구에서 위 템플릿으로 바로 시작하세요.

비동기 주간 업데이트 템플릿: 진행·계획·문제 형식과 누가 올리는가