what-did-my-team-do-this-week
관리에서 가장 단순한 질문이 왜 가장 대답하기 어려운지, 그리고 누구도 방해하지 않고 자동으로 답하는 시스템을 만드는 방법.
By Ellis Keane · 2026-03-27
선장은 항해 일지를 기록했다. 기록하기를 좋아해서가 아니라, 항해가 3주째 접어들었을 때 무슨 일이 있었는지 재구성할 수 있는 유일한 방법이 작업 자체의 부산물로 만들어진 지속적인 기록이었기 때문이다. 일지를 만들기 위해 회의를 열지는 않았다.
2026년의 많은 엔지니어링 팀은 지난주에 무슨 일이 있었는지에 대한 가시성이 상선이 어제 날씨를 파악하는 것보다 낮다. "이번 주 팀이 한 일은 무엇인가"라는 질문은 어렵지 않아야 하는데, 매주 월요일 엔지니어링 매니저와 프로덕트 리드는 회의를 잡아 물어보거나, Linear 보드, GitHub 피드, Slack 스레드, Notion 문서를 클릭하며 수동으로 답을 조합하려 한다. 정보는 존재한다 – 그러나 서로 연결되지 않는 도구들에 흩어져 있고, 그것을 엮는 것이 누군가의 역할이 아니다.
"2026년의 많은 엔지니어링 팀은 지난주에 무슨 일이 있었는지에 대한 가시성이 상선이 어제 날씨를 파악하는 것보다 낮다." – Ellis Keane
"이번 주 팀이 한 일은?"이 대답하기 어려운 이유
팀이 사용하는 모든 도구는 이미 활동을 추적하고 있다. Linear는 어떤 이슈가 "완료"로 이동했는지 알고 있다. GitHub는 어떤 PR이 병합됐는지 알고 있다. Slack은 어떤 스레드가 활발했는지 알고 있다. 각 도구는 독립적으로는 무슨 일이 있었는지 완벽하게 기록하고 있다.
하지만 어떤 도구도 전체 그림을 가지고 있지 않으며, 도구를 넘나드는 활동 간의 관계는 보이지 않는다. Linear 이슈를 닫는 PR이 Figma 프로토타입을 참조하는 Slack 스레드에서 논의됐다면 – 이것은 하나의 작업 단위이지만 네 개의 별도 피드에 네 개의 독립적인 이벤트로 나타난다. 팀이 무엇을 달성했는지 파악하려면 머릿속에서 그래프 순회를 해야 하고, 탭을 넘나들며, 타임스탬프를 맞추고, 누군가가 조용히 다른 세 사람의 장애물을 해결한 스레드를 놓치지 않기를 바라야 한다.
주간 상태 회의가 계속되는 것은 단일 도구가 그 질문에 답할 수 없고, 답할 수 있는 도구들을 상관시킬 시간이 누구에게도 없기 때문이다.
"가시성"이 실제로 의미하는 것(그리고 의미하지 않는 것)
더 나아가기 전에(잠시 멈출 가치가 있다), "팀 가시성"은 말하는 사람이 원하는 것을 의미하는 문구가 되었고, 이것이 많은 해결 시도가 감시처럼 느껴지는 이유 중 하나다.
이번 주 팀이 한 일을 물을 때 대부분의 매니저가 실제로 원하는 것은 이런 것이다: 어떤 프로젝트가 진전됐는지, 무엇이 출시됐는지, 무엇이 막혔는지, 그리고 문제가 되기 전에 알아야 할 것이 있는지. 커밋 수를 세거나 시간을 측정하려는 게 아니다 – 모두가 작업을 멈추고 작업에 대한 보고서를 작성하지 않아도 도움이 될 만큼 충분한 정보를 갖고 싶은 것이다.
이 구분이 중요한 것은, "팀 가시성"을 제공한다고 주장하는 대부분의 도구가 실제로는 활동 메트릭, 즉 커밋 수, 티켓 속도, 상태별 소요 시간 분석을 제공하기 때문이다. 이것들은 처리량 분석에는 유용하지만 의사 결정 맥락을 이해하는 데는 약하다. 팀이 47개의 PR을 병합했다는 것을 알아도 중요한 것이 완료됐는지, 또는 중요한 결정이 Slack 스레드와 Linear 댓글 사이 어딘가에서 놓친 작업이 됐는지는 거의 알 수 없다.
"팀이 이번 주에 달성한 것"과 "도구가 기록한 것" 사이의 격차는 가시성 문제가 아니라 연결 문제다. 정보는 도구 전반에 존재한다; 그 사이의 관계가 없다.
다섯 가지 도구로 보는 한 주: 답이 있는 곳
엔지니어 6명을 관리하고 있고 누구에게도 묻지 않고 이번 주에 무슨 일이 있었는지 파악하고 싶다고 하자. 각 도구가 실제로 제공하는 것은 다음과 같다:
Linear에는 이슈 보드가 있다 – "이번 주 완료"로 필터링하면 어떤 티켓이 닫혔는지 볼 수 있다. 하지만 Linear는 3일간의 아키텍처 작업을 포함한 닫힘과 2분짜리 설정 변경을 구분할 수 없고, 티켓 밖에서 일어난 작업(항상 티켓 밖의 작업이 있다)도 캡처하지 못한다.
GitHub에는 PR 활동 – 병합, 리뷰, 댓글 – 이 있다. Linear와 교차 참조하면 더 풍부한 그림을 얻을 수 있지만, 수동으로 그것을 하는 것은 번거롭고, 특정 접근 방식이 선택된 이유나 어떤 트레이드오프가 논의됐는지의 맥락은 여전히 놓친다.
Slack은 좋든 싫든 실제 의사 결정의 대부분이 이루어지는 곳이다. 중요한 대화들은 존재했다는 것을 알아야만 찾을 수 있는 스레드에 묻혀 있다. Slack 검색은 누군가가 사용한 정확한 문구를 알면 작동하지만, "이번 주 인증 마이그레이션에 대해 누군가 논의했나?"를 찾는데 스레드에서 "로그인 리팩터링"이라는 단어를 사용했다면 완전히 놓치게 된다.
Figma는 디자인 반복을 캡처하지만, 관련 댓글에 태그되지 않았다면 무엇이 변경됐는지와 이유를 이해하기 위해 파일 버전 기록을 탐색해야 한다.
Notion에는 회의 메모, 사양서, 결정 기록이 있다 – 사람들이 업데이트했다는 가정 하에(그랬으면 좋겠지만 우리 경험상 새 문서 구조의 첫 달 이후 업데이트율이 급격히 떨어진다).
"이번 주 팀이 한 일은?"에 대한 완전한 답은 이 모두에 걸쳐 존재하며, 어떤 단일 피드도 연결된 전체 그림을 제공하지 않는다.
존재하는 임시방편(그리고 그것이 무너지는 지점)
대부분의 팀은 의식과 수동 노력으로 이것을 해결한다. 우리가 본 것들이다:
스탠드업 요약. 일부 팀은 EM이 스탠드업 메모에서 주간 요약을 정리한다. 스탠드업이 내용이 있을 때는 효과가 있다 – 하지만 "어제와 같음, 차단 없음"으로 변질됐다면(솔직히 많은 팀이 그렇다), 요약은 아무것도 없는 것을 정리한 것에 불과하다.
금요일 업데이트 스레드. 모두가 출시한 것을 게시하는 Slack 채널. 사람들이 실행할 때는 놀랍도록 잘 작동하지만, 우리 경험상 누군가가 적극적으로 독려하지 않으면 몇 주 내로 참여율이 떨어진다. 업데이트도 공식화된다 – 사람들은 눈에 보이는 작업을 나열하고 시간의 대부분을 소비한 보이지 않는 조율 작업은 생략한다.
자동화된 프롬프트. Geekbot이나 DailyBot 같은 도구가 업데이트를 요청하고 다이제스트를 정리한다. 없는 것보다는 낫지만, 자기 보고 데이터에 의존하기 때문에 실제로 일어난 것이 아니라 사람들이 언급하기를 기억한 것을 받게 된다.
커스텀 대시보드. GitHub 및 Linear API에서 가져오는 Retool 또는 Notion 데이터베이스. 정량적인 측면에는 좋지만, 정성적 맥락 – 논의, 방향 전환, "X를 시도했지만 작동하지 않았다"는 서사 – 을 완전히 놓친다. 이것이 보통 팀의 한 주를 이해하는 데 가장 중요한 부분이다.
이 모두는 동일한 격차를 해소하려 한다: 도구가 서로 맥락을 공유하지 않기 때문에 인간이 수동으로 보완한다.
보고 루프에서 인간을 제거하기
우리는 이 접근 방식 대부분을 직접 시도해봤다(작은 팀이라서 우리 규모에서는 중요하지 않을 것 같지만 – 5명에서도 중요하다). 템플릿 기반 접근 방식 – 주간 업데이트 문서, 구조화된 스탠드업 프롬프트, 금요일 회고 스레드 – 은 한동안 효과가 있다가 조용히 사라졌다. 사람들이 신경 쓰지 않아서가 아니라, 한 일을 쓰는 것은 항상 다음 할 일을 하는 것보다 덜 긴급하게 느껴지기 때문이다.
실제로 작동한다고 밝혀진 것은 보고 단계에서 인간을 완전히 제거하는 것이다. 작업에서가 아니라 – 사후에 작업을 설명하는 행위에서.
우리의 현재 가설은 – 솔직히 아직 검증 중이지만 – "활동 피드"와 "유용한 주간 요약" 사이의 격차가 관계 매핑 문제라는 것이다. 활동 피드는 PR이 병합됐다고 알려준다; 크로스 도구 연결 시스템은 그 PR이 이 Linear 이슈를 닫았고, 이것이 지난 화요일 이 Slack 스레드에서 논의됐으며, Figma의 디자인 결정을 참조했고, 전체가 Notion의 분기 목표와 관련 있다고 알려준다. 그것이 이벤트 목록과 무슨 일이 있었는지에 대한 이해의 차이다.
실제 한계도 있다: 시스템이 볼 수 없는 비공개 Slack 채널, 연결하지 않은 도구에서 이루어진 작업, 서면 기록 없이 화상 통화에서 이루어진 대화, 두 가지가 키워드를 공유하지만 실제로는 관련 없는 잘못된 결합의 항상적인 문제. 이것이 모든 것을 캡처한다고 주장하지 않는다 – 하지만 어떤 자기 보고 시스템보다 훨씬 더 많이 캡처하고, 누구도 방해하지 않고 캡처한다.
진정으로 이것이 필요 없을 때
팀이 같은 방에 3명뿐이라면 이번 주에 무슨 일이 있었는지 이미 알고 있다. "팀이 한 일은?" 문제는 팀이 주변 인식이 모든 것을 커버할 수 있는 규모를 넘어 성장했을 때 나타나는 경향이 있다 – 우리 경험상 6명에서 8명 정도, 또는 원격이거나 여러 시간대에 걸쳐 있거나 각기 다른 주요 도구를 사용하는 여러 분야에 걸쳐 있다면 더 일찍 나타난다.
팀이 한 번에 한 가지에 집중하고 있다면 덜 중요하다. 모두가 단일 프로젝트와 단일 보드에 집중하고 있다면, Linear의 "이번 주 완료" 필터가 주간 진행 추적에 필요한 대부분을 제공한다. 여러 프로젝트, 도구, 이해관계자에 걸쳐 작업이 파편화됐을 때야 정보 격차가 실제 해결책을 정당화할 만큼 고통스러워진다.
월요일 아침에 지난주에 무슨 일이 있었는지 파악하는 데 몇 분 이상 보내고 있다면, 아마도 수동 접근 방식이 더 이상 확장되지 않는 임계값을 넘은 것이다.
다섯 가지 도구를 클릭해서 하나의 질문에 답하는 것을 그만두세요. Sugarbug는 작업이 이미 이루어진 도구들에서 주간 그림을 자동으로 조합합니다.
Q: Sugarbug는 "이번 주 팀이 한 일은?"을 어떻게 자동으로 답합니까? A: Sugarbug는 팀의 도구들(Linear, GitHub, Slack, Figma, Notion)에 연결하여 모든 활동의 지식 그래프를 구축합니다. 각 사람에게 업데이트를 요청하는 대신, 자동 생성된 주간 펄스가 완료된 작업, 활성 스레드, 내려진 결정을 실제 작업이 이루어진 도구에서 직접 보여줍니다.
Q: Sugarbug가 주간 상태 회의를 대체할 수 있습니까? A: 많은 팀에서 부분적으로 또는 완전히 대체할 수 있습니다. Sugarbug는 상태 회의와 동일한 정보(누가 무엇을 했는지, 무엇이 출시됐는지, 무엇이 막혔는지)를 슬라이드 준비나 업데이트 작성 없이 제공합니다. 일부 팀은 토론을 위한 짧은 주간 싱크는 유지하되 상태 보고 부분은 완전히 없앱니다.
Q: Sugarbug는 어떤 도구에서 주간 진행 데이터를 가져옵니까? A: Sugarbug는 현재 Linear, GitHub, Slack, Figma, Notion, 이메일, 캘린더 도구와 통합되어 있습니다. 각 통합은 공유 지식 그래프에 연결되므로, GitHub PR의 진행 상황은 관련 Linear 이슈와 해당 이슈가 논의된 Slack 스레드에 연결됩니다.
Q: 자동화를 설정하거나 Zapier 워크플로를 작성해야 합니까? A: 아닙니다. Sugarbug의 지식 그래프 접근 방식은 트리거-액션 자동화와 다릅니다. 도구를 연결하면 Sugarbug가 팀의 작업에 대한 맥락을 지속적으로 구축합니다. 설정하거나 유지해야 하는 워크플로가 없습니다.
---
월요일 아침에 5개의 앱을 클릭하며 지난주 팀이 한 일을 재구성하려 해본 적이 있다면, 그것이 우리가 Sugarbug를 만든 이유입니다. 작동 방식 보기