채용 분야의 SaaS를 소규모 팀으로 개발하고 있습니다. 필자는 PM 겸 엔지니어로, 업무 중 하나로 팀 멤버의 진척 확인이 있습니다. 이전에는 각 멤버가 Notion의 태스크 카드(Task Card)로 자신의 상태를 수동 업데이트하는 운용 방식이었습니다.

곤란했던 점은 업데이트 누락입니다. 정기 회의 때마다 Notion을 열어 확인하고 있었지만, 상태가 오래된 채 방치되어 있는 카드가 있었습니다. 누가 어디에서 막혀 있는지를 그 자리에서 본인에게 다시 물어봐야 했습니다.

그래서 진척을 확인하는 장소를 Notion에서 GitHub의 Issue와 PR(Pull Request)로 옮겼습니다. PR을 머지(Merge)하면 그것이 그대로 상태 변경이 됩니다.

결과적으로 업데이트 누락이라는 개념 자체가 사라졌습니다. 정기 회의에서 본인에게 다시 물어보는 상황도 없어졌습니다. 나아가 git log · PR · Issue · 채팅을 횡단 집계한 진척 리포트를 자동 생성할 수 있게 되었습니다.

이 기사에서는 연동이라는 선택지를 버리고 이행(Migration)에 집중한 이유와, 이행 후 리포트를 자동 생성하기까지의 과정을 작성합니다. 태스크 관리 도구의 상태 업데이트가 형식화되어 있거나, 정기 회의 전 정보 수집에 시간을 뺏기고 있는 PM · 테크 리드(Tech Lead)를 위한 내용입니다.

수동 업데이트도, Notion 연동도 그만두었다

Notion에서의 운용은 심플했습니다. 각 멤버가 태스크 카드를 가지고 진행 중 · 리뷰 대기 · 완료와 같은 상태를 직접 업데이트합니다. PM은 그 보드(Board)를 보고 전체적인 진행 상황을 파악하는 설계였습니다.

문제는 이 '직접 업데이트한다'는 번거로움이었습니다. 구현에 집중하다 보면 업데이트를 잊어버립니다. 잊은 채 며칠이 지나면 본인도 현 상황을 기억해 내는 데 시간이 걸립니다. 정기 회의에서는 상태를 보고 끝나는 것이 아니라, "이거 아직 진행 중으로 되어 있는데 실제로는 어때?"라고 다시 물어보는 상황이 매번 있었습니다.

다시 물어보는 작업이 정기 회의 시간을 잡아먹습니다. 게다가 이것은 멤버의 태만 때문이 아닙니다. Notion 업데이트는 본래의 작업(코드를 작성하거나 PR을 내는 것)과는 별개의 행동이며, 잊어버리는 것이 당연한 번거로움이었습니다.

처음에 검토한 것은 연동이었습니다. Notion API나 Notion MCP를 사용하면 PR이나 Issue의 상태를 Notion 측으로 반영하는 메커니즘 자체는 구축할 수 있습니다. 다만 그 설계와 구현에는 시간이 걸리고, 기존의 운용 규칙을 재검토할 필요도 있습니다. Claude Code에게 진척을 추적하게 하는 상황에서도 Notion 측까지 매번 읽으러 가게 하면 토큰(Token) 소비가 늘어납니다. 동기화를 계속 유지하는 비용 자체가 새로운 부채가 될 것 같았습니다. 연동은 수지가 맞지 않는다, 그렇게 판단했습니다.

그렇게 생각하면 애초에 인간이 손으로 상태를 업데이트하는 운용 자체가 필요 없는 것이 아닌가 하는 이야기가 되었습니다. PR이 머지되었는지, 오픈(Open) 상태인지. GitHub 측의 상태만 봐도 진척은 충분히 판단할 수 있습니다. Notion과 GitHub 양쪽을 계속 동기화하는 것보다, 진척을 확인하는 장소를 GitHub로만 한정하는 것이 더 이치에 맞았습니다.

상태를 PR의 머지로 연결하다

이행 자체는 단순합니다. 상태 변경을 멤버의 수동 업데이트가 아닌, PR 머지라는 기존의 행동에 연결했습니다.

PR을 머지하는 것은 멤버가 원래 하고 있는 행동입니다. 거기에 번거로움을 하나 더 추가하는 대신, 그 행동 자체를 상태 업데이트로 취급하도록 했습니다. '업데이트를 잊어버린다'는 선택지 자체를 없앤 형태입니다.

Issue 작성도 봇(Bot)에게 던지면 끝나도록 하고 있습니다 (이 메커니즘은 별도 기사 「Slack에 던지기만 하면 Issue 작성이 끝난다」에 작성했습니다).

정기 회의에서 보는 것이 바뀌었다

이전에는 정기 회의에서 Notion 화면을 열어 확인했습니다. 지금은 PR 목록과 Issue 목록을 봅니다.

대응 관계는 단순합니다. 머지된 PR은 완료, 오픈된 PR이나 리뷰 대기 중인 PR은 진행 중. Issue도 마찬가지로 클로즈(Close)는 완료, 오픈(Open)은 미착수 또는 진행 중입니다. 이 대응이 명확하기 때문에 화면을 보면 그대로 상황을 알 수 있습니다.

결과적으로 멤버에게 다시 물어보는 일이 없어졌습니다. 상태는 행동의 부산물입니다. 자동으로 결정되기 때문에 업데이트 누락이라는 개념 자체가 발생하지 않습니다. 정기 회의는 '상황을 묻는 자리'에서 '상황을 전제로 다음을 결정하는 자리'로 바뀌었습니다.

git log · PR · Issue · 채팅을 횡단 집계하다

PR 단위 · Issue 단위로 볼 수 있게 되었습니다. 이에 더해 여러 소스를 통합한 리포트도 자동 생성하고 있습니다. 집계는 Claude Code의 담당입니다. 각 소스가 원래부터 기계 판독 가능(Machine-readable)하므로, git log나 API를 통해 직접 읽으러 가서 그대로 리포트를 구성할 수 있습니다. 전용 파서(Parser)는 필요 없습니다.

집계 대상은 4가지입니다. git log·머지된(Merged) PR, 오픈된(Open) PR(리뷰 대기 중이거나 초안(Draft) 상태), Issue(기간 내 종료·신규·남아 있는 오픈 상태), 그리고 채팅에서의 블로커(Blocker)·지연 징후입니다.

이 집계는 Claude Code의 스킬(Skill)로서 준비해 두었습니다. 주간 정례 회의 전에 스킬을 실행하기만 하면, 그것만으로 전체 진척도를 파악할 수 있습니다.

가장 도움이 되는 점은, 누구에게 무엇이 할당(Assign)되어 있고 어디까지 진행되었는지를 한눈에 알 수 있다는 것입니다. 본인에게 매번 확인할 필요 없이, 한 번 훑어보는 것만으로 파악할 수 있습니다.

수치는 반드시 근거를 추적할 수 있는 형태로 구성했습니다. PR 번호나 Issue 번호를 병기하고, '정체되어 있다'라고 판정할 때는 최종 업데이트 날짜를 덧붙입니다. 이는 AI의 추측과 실제 데이터에 기반한 사실을 섞지 않기 위함입니다.

아직 남아 있는 과제

성공한 이야기만으로는 신뢰할 수 없다고 생각하기에 솔직하게 적겠습니다. 남아 있는 문제는 2가지입니다.

• 효과를 수치로 측정하지 못하고 있다. 확인 누락은 해소했지만, 정례 회의의 효율이 얼마나 올라갔는지는 측정하지 않았다. 개선을 주장하려면 먼저 측정 메커니즘을 마련해 두었어야 했다.
• GitHub 쪽이 불편한 면도 있다. 확장성은 Notion 쪽이 더 높고, UI/UX도 좋다. 티켓 관리 그 자체는 솔직히 Notion의 판정승이다.

그럼에도 불구하고, 티켓을 일괄적으로 생성하는 것과 같은 상황에서는 GitHub 쪽이 편했습니다. Claude와 연계하여 그대로 기표(Create)까지 이어갈 수 있기 때문입니다.

요약

돌이켜보면, 이번 이행에서 효과가 있었던 것은 Notion과 GitHub를 둘 다 계속 사용하는 것을 그만둔 것이었습니다. 연동하여 동기화하는 방법도 있었지만, 그것을 선택했다면 동기화가 어긋날 때마다 수정하는 업무가 새로 늘어났을 것입니다. 한쪽으로 몰아주었기에 그 업무는 애초에 발생하지 않았습니다.

수행한 일은 두 가지로 압축할 수 있습니다. 진척을 보는 장소를 하나로 만드는 것. 그리고 상태(Status)를 기존 행동의 부산물로 만드는 것입니다. 전자만으로도 업데이트 누락이라는 문제 자체는 사라집니다.

진척도가 '보고받는 것'에서 '보면 알 수 있는 것'으로 바뀌면서, 정례 회의는 다음 수를 결정하는 장이 되었습니다. 이 변화가 가장 기뻤던 부분입니다.

Discussion