안녕하세요. PIVOT에서 테크 리드(Tech Lead)를 맡고 있는 @tawachan입니다.

2026년 6월 시점에서 몇 주 정도 자신의 개발 플로우에서 시도하고 있는 운영 방식 중 하나가 "PR 리뷰 워크플로우의 전 단계에 AI를 비서로 끼워 넣는 것"입니다. 구체적으로는 Claude Code의 Routines 기능을 사용하여, 평일 아침·점심·저녁 3회에 걸쳐 각 리포지토리(Repository)와 Slack을 한 바퀴 돌게 하여, "이것은 이미 다 봤으니 신경 쓰지 않아도 된다", "이것은 이 부분의 판단만 필요하다"와 같이 논점을 좁힌 상태로 자신의 times(개인용 작업 로그용 Slack 채널)에 올려주도록 하고 있습니다.

포인트는 리뷰 관점 그 자체를 AI에게 맡기는 것이 아니라, 그 전 단계인 "지금 나는 어떤 PR을 봐야 하는가"의 트리아지(Triage)를 AI가 대신하게 한다는 점입니다. 범용 AI 리뷰를 구현자 대신 작성하게 하는 방향이 아니라, 내가 리뷰하기 전 단계의 문맥 정리(Context Organization)만을 "비서"로서 담당하게 하는 것입니다. 게다가 내가 직접 상황을 물으러 가는 Pull 방식이 아니라, 정기적으로 상대방으로부터 상황이 전달되는 Push 방식으로 운영하고 있습니다.

이 기사는 베스트 프랙티스를 제시하기보다는, 하나의 운영 플로우로서 시도하고 있는 방향성을 공유하는 것입니다. 왜 시작했는지, 어떻게 설계했는지, 실제로 어떤 알림이 오는지에 대해 쓰겠습니다. 전제가 되는 코드 리뷰 관점에 대한 이야기는 이전 기사인 「AI 시대의 코드 리뷰 — 무엇을 봐야 하고, 무엇을 보지 않아도 되게 되었나」에 적었으므로, 그 글과 함께 읽어주시면 내용이 이어집니다.

참고로, 이 운영은 "PR·Issue·Slack에 평소부터 문맥이 남아 있는 팀", "리뷰어 본인의 관점이 어느 정도 언어화될 수 있는 사람"을 전제로 합니다. 정보가 저장된 위치가 어지러워 비서가 수집할 수 없거나, 무엇을 봐야 하는지가 상황에 따라 언어화하기 어려운 경우에는 다른 대책이 더 효과적일 것입니다.

과제: 개발량이 늘어나면서 리뷰가 돌아가지 않게 되었다

"리뷰가 병목(Bottleneck)이다"라는 말은 어느 팀에서나 오래전부터 해온 이야기라고 생각합니다. 솔직히 말해서, 소규모 팀에서 한 차례의 리뷰를 혼자서 다 볼 수 있었던 시절에는 저도 그것을 크게 실감하지 못했습니다. 하지만 PIVOT에서 AI 활용이 진전되면서 1인당 아웃풋(Output)량이 체감상 크게 늘어났고, 백엔드(Backend) 팀 구성도 확장되면서 명확하게 따라가지 못하게 되었습니다.

내가 봐야 할 open PR은 여러 리포지토리(제품 본체, 스키마 정의, 인프라, 주변 서비스)에 걸쳐 쌓여 있습니다. Slack으로 직접 "봐달라"고 날아오는 리뷰 요청도 있고, GitHub 상에서 내가 리뷰어로 지명된 채 쌓여 있는 것도 있습니다. 자, 어떻게 해야 할까요.

막다른 길: 리뷰라는 행위 자체는 더 이상 효율화할 수 없었다

가장 먼저 생각하는 것은 "리뷰라는 행위를 더 빠르게 할 수 없을까"입니다. 하지만 저의 경우 이 부분은 금방 막다른 길에 부딪혔습니다.

그 이유는 리뷰 어시스턴트(Review Assistant)로서의 AI 활용은 이미 팀 내에서 일반적이 되었기 때문입니다. 구현자가 PR 생성 시 AI 리뷰를 거치는 것은 당연하며, 리뷰어 측도 코멘트를 남기기 전에 AI와 대화(Wall-hitting)하며 브러시업(Brush-up)하는 것이 일상입니다. PR 상의 코멘트 자체가 AI를 매개로 한 주고받기로 구성되어 있는 것도 흔한 광경입니다. 처음에는 "AI가 쓴 문장이네"라며 이질감을 느꼈던 시기도 있었지만, 지금은 AI의 문장끼리 서로 브러시업하며 오가는 것이 당연해졌습니다(단순히 떠넘기는 것이 아니라, 랠리를 하며 다듬어진 코멘트가 나온다는 전제하에 읽히고 있습니다). 즉, AI로 어시스트하여 빠르게 할 수 있는 부분은 이미 거의 다 빨라진 상태입니다.

여기서 더 효율화하려고 하면 "리뷰를 AI에게 완전히 위임하는" 방향으로 나아갈 수밖에 없습니다. 하지만 리뷰에는 본질적으로 "인간이 승인을 부여했다"라는 프로세스로서의 측면이 있습니다. 그렇기에 PR이 main에 병합(Merge)되는 것이 조직적으로 성립됩니다. 그 부분을 인간인 척하는 AI가 승인하는 방향은, 현재의 개발 사상으로는 아직 어렵다고 느낍니다.

이것은 「AI가 작성한 코드를 인간이 검토할 것인가」라는 논쟁과도 연결되는 이야기로, Martin Fowler는 「Vibe Coding」과 「Agentic Programming」에 관한 글을 거의 동시에 발표하며 명칭 단계부터 구분하려고 시도하고 있습니다. AI에게 맡기는 정도(농도)에 따라 개발의 방식이 달라진다는 정리인데, 이 구분이 어떻게 진화해 나갈지는 흥미로운 대목입니다. 적어도 저희의 현 상황은 Vibe Coding 방향으로 키를 틀지 않았기에, 승인의 최종 책임은 인간이 갖는다 —— 이른바 human-in-the-loop —— 라는 전제하에 운용하고 있습니다[1].

노이즈 관점에서도 같은 결론에 도달합니다. AI가 실수하여 본의 아니게 의도치 않은 지적을 섞는 일은 흔히 발생하며, 그것을 자신의 명의로 양산해 버리면 구현자 입장에서는 읽고 넘겨야 하는 비용만 늘어날 뿐입니다. 범용적인 1차 AI 리뷰가 필요하다면 구현자 측에서 직접 가져다 쓸 수 있으므로, 거기에 자신의 명의로 더욱 느슨한 AI 리뷰를 덧씌우는 것은 노이즈를 중첩시키는 결과가 되기 쉽습니다.

요컨대, 사상을 바꾸지 않는 한 리뷰라는 행위 자체의 효율화는 이미 한계에 다다라 있었습니다.

깨달음: 정말로 힘들었던 것은 「애초에 무엇을 봐야 하는가」를 파악하는 것이었다

리뷰 본체를 줄일 수 없다면, 고통의 정체를 한 단계 더 분해해서 살펴봐야 합니다. 다시 한번 자신의 부하를 관찰해 보니, 인지 자원(Cognitive resources)을 가장 많이 잡아먹고 있었던 것은 개별 PR을 읽는 것이 아니라,

• 어떤 것이 신규이며 리뷰가 필요한가
• 어떤 것은 지난번에 이미 코멘트했고, 상대방의 답장을 기다리는 중인가
• 어떤 것은 내가 확인했으니, 이제 건드리지 않아도 되는가
• 어떤 것은 Approve(승인) 완료되어, 잊어도 되는가

하는 것들을 머릿속에서 계속 돌리는 일이었습니다. 여러 리포지토리와 Slack에 흩어져 있는 상태를 대조하며 「지금 나는 무엇을 봐야 하는가」를 파악하는 것 자체가 정신없는 상태였던 것입니다.

알림이 부족한 것은 아닙니다. 오히려 알림은 산더미처럼 옵니다. 리뷰어로 어사인(Assign)되면 GitHub App에서도, Slack 연동에서도 날아옵니다. 문제는 그 하나하나가 「무언가 일어났다」는 사실만을 알려준다는 점입니다. 그것이 나에게 「지금 봐야 할 것」인지, 「나는 코멘트를 남겼고 author의 답장을 기다리는 중」인지, 「이미 다른 사람이 Approve 하여 넘겨도 되는 것」인지에 대한 의미 부여는 알림에 적혀 있지 않습니다. 문맥을 알 수 없는 알림이 대량으로 흘러들어오기만 하면, 결국 한 건씩 열어서 상황을 떠올리는 작업이 필요하므로 파악에 드는 부하는 줄어들지 않습니다.

이 파악을 스스로 해결해 보려고 여러 가지 시행착오도 겪었습니다. 처음에는 단순하게 기억에 의존했습니다. 그다음에는 Slack의 리뷰 요청 메시지에 「나중에 리마인드하기」(메시지 메뉴에서 선택하면 3시간 후 등에 재알림을 주는 기능)를 설정했습니다. 그래도 안 되어서 times에 「지금 이 PR이 신경 쓰임」이라고 메모를 남기면 좀 나을까 하는 구질구질한 궁리도 해보았습니다. 그러다 보니 「지금 내가 봐야 할 PR은 무엇인가」를 스팟으로 물어볼 수 있는 전용 Skill을 만들어 보기도 했습니다.

하지만 어느 것도 잘 돌아가지 않았습니다. 「나중에 리마인드하기」도 times 메모도, 결국 스스로 설정하지 않으면 시작되지 않고, PR 수가 늘어나면 설정하는 것 자체가 누락됩니다. Skill로 만들어도 이쪽에서 「물어보러 가야지」라고 생각하지 않으면 구동되지 않기 때문에(즉, Pull 방식), 내가 잊어버리면 통째로 잊게 됩니다. 즉, 어떤 궁리도 결국 마지막에는 자신의 주의력에 의존하게 됩니다. 「리뷰는 최대한 빨리 보자」, 「요청이 오면 알아차리자」와 같은 마음가짐도 중요하지만, 「인간이 주의력으로 할 수 있는 일에는 한계가 있다」는 것이 저의 실감이었고, 인내심이나 정신력으로 계속 버티는 것은 최후의 수단으로 남겨두고 싶었습니다.

다행히 이 「봐야 할 대상의 관리」는 리뷰의 본질인 「인간의 판단」과는 관계없는 사무적인 부하입니다. 즉, 시스템으로 해결해도 되는 영역입니다. 리뷰어를 늘리거나, PR을 잘게 나누거나, 관점을 좁히는 등의 다른 축의 방책(이것들은 병행할 수 있습니다)도 있지만, 이번에 시도하고 있는 것은 「내가 봐야 할 범위를 좁히는 메커니즘」을 AI에게 대신 맡겨 주의력을 보조하는 접근 방식입니다.

설계: 리뷰 워크플로우에 「AI 비서」를 끼워 넣기

워크플로우 전체를 그림으로 나타내면 다음과 같은 배치가 됩니다.

포인트는 내가 심도 있게 읽는 화살표가 단 하나(논점을 좁혀서 제시 → 내가 리뷰 본체 수행)로 압축되어 있다는 점입니다. 찬성 코멘트 부분은 가벼운 최종 확인만으로 충분하며, 나머지는 비서가 처리하여 요약(Summary)만 times로 흘려보냅니다. 실제로 routine이 대신해 주고 있는 것은 바로 이런 업무들입니다.

• 상태 관리 (State Management): 관련된 여러 리포지토리(Repository)의 open PR을 「내가 리뷰어로 지명된 것」, 「과거에 내가 리뷰에 참여했던 것」이라는 두 가지 축으로 횡단 스캔하여, Slack의 리뷰 요청(지난 72시간)과 대조합니다.
• 판정: 각 PR에 대해 「이것은 이미 확인하셨습니다」, 「이것은 작성자(Author)의 답장을 기다리는 중이라 아직 움직일 수 없습니다」, 「이것은 다른 리뷰어가 승인(Approve)했으므로 잊어도 됩니다」, 「이것은 새로 확인하실 필요가 있습니다」를 구분해 줍니다.
• 논점 좁히기: 「새로 확인하실 필요가 있습니다」라고 판정된 PR에 대해서는, 「이 부분의 결정만 필요함」, 「이 방침이 이전 아키텍처 논의와 일치하는지 확인만 필요함」과 같이, 봐야 할 초점을 한 단계 좁힌 형태로 나열해 줍니다.
• 에스컬레이션 (Escalation): 사양의 타당성이나 비즈니스적인 트레이드오프(Trade-off) 등, AI만으로는 판단하기 어려운 것은 결론을 내지 않고 논점으로서 제시하여 본인의 판단에 맡깁니다.

즉, 자신이 리뷰를 열 때는 「무엇을 위해, 어디를 보러 가는지」가 이미 준비되어 있는 상태가 됩니다. 리뷰 본체는 변함없이 자신이 수행하지만, 그곳에 도달하기까지의 인지 부하(Cognitive Load)가 한 단계 낮아져 있다는 것이 이 운용의 핵심입니다.

관점 프롬프트에 자신의 시각을 이식하기

「비서」로서 기능하게 하려면, 자신의 시각을 프롬프트(Prompt)에 이식할 필요가 있습니다. 구체적으로는 자신이 평소 리뷰에서 신경 쓰고 있는 포인트를 언어화하여 작성하고 있습니다. 예를 들어:

• 도메인(Domain)의 경계를 넘어가고 있지는 않은가
• 기존의 아키텍처 방침(모듈러 모놀리스(Modular Monolith)의 분할 방침 등)과 일관성이 있는가
• 인터페이스(Interface)의 책임이 분산되어 있지는 않은가
• DB의 하위 호환성이나, 과거의 설계 결정(ADR)과 모순되지 않는가
• 과거의 PR에서 논의되었던 포인트가 재발하고 있지는 않은가

관점 그 자체뿐만 아니라, 소견의 농도도 지시하고 있습니다. 내려놓을 레거시(Legacy) 영역은 가볍게, 앞으로 키워나갈 도메인은 무겁게. PR의 규모에 따라 논점의 개수도 좁히게 하여, 작은 PR마다 매번 3개의 논점이 붙는 「시끄러운 비서」가 되지 않도록 하고 있습니다. 이 부분의 정밀도가 곧 「비서로서 쓸모가 있는지 없는지」로 직결되기 때문에, 운용하면서 조금씩 내용을 추가하거나 조정하고 있습니다.

Slack · PR · Issue · 코드를 횡단하여 문맥을 파악하기

또 하나 중요한 것은, 단발적인 PR diff(차이점)만을 보여주지 않는다는 점입니다.

구체적으로 참조하고 있는 것은 다음과 같습니다. Slack은 MCP를 통해, GitHub와 각 리포지토리는 routine에 연동되어 있으므로 필요한 컨텍스트(Context)는 거의 갖춰집니다 [2].

• GitHub의 PR과 Issues / Projects: 태스크 관리를 Issues / Projects에 집중시키고 있으므로, 티켓 생성 시의 의도나 논의 중에 첨부된 Slack 스레드 링크도 그곳에서 찾아낼 수 있습니다.
• 각 리포지토리의 소스 코드 그 자체: routine에는 대상 리포지토리를 모두 연동해 두었으므로, PR의 차분(Diff)에 그치지 않고 판단에 필요하다면 관련 소스 코드까지 스스로 읽으러 갈 수 있습니다.
• 관련된 타 플랫폼의 PR: 백엔드와 클라이언트에서 연동되는 태스크가 맞물려 있는지, Proto 정의대로 구현 측이 되어 있는지와 같은 가로 방향의 정합성.
• Slack의 리뷰 요청 스레드: 요청 시 어떤 온도감과 전제로 던져졌는지, 요청 이후의 주고받은 대화, 관련된 다른 논의.
• GitHub 상의 과거 리뷰 코멘트: 이전 사이클(Cycle)까지 자신이나 다른 리뷰어가 무엇을 말했는지 / 작성자가 어떻게 반응했는지.

이를 통해,

• 「이 PR은 Slack으로 리뷰 요청이 왔는데 내가 아직 답장하지 않았다」
• 「이전 사이클에서 내가 방침 확인 코멘트를 남겼고, 그 후 작성자가 아직 답장하지 않았다 (작성자 답장 대기 중)」
• 「이미 다른 리뷰어로부터 승인(Approve)되어 있어서, 내가 볼 필요는 더 이상 없다」

와 같은 상태를 판정할 수 있게 됩니다. 비서로서 기능하기 위해서는 여기서 횡단적으로 상황을 파악할 수 있는 것이 전제 조건이 됩니다.

여기서 효과를 발휘하는 것이, 평소부터 정보의 위치를 Issues / Projects / Slack / PR 코멘트와 같이 「AI가 읽을 수 있는 곳」으로 모아두었다는 점입니다. 태스크 생성 의도, 논의 링크, PR 간의 연동 관계와 같은 문맥이 그곳에 갖춰져 있는 상태를 만들어 두었기에, 비서가 읽으러 갈 때도 문맥을 담당자 수준의 해상도로 맞출 수 있는 장면이 생기게 됩니다.

이는 클라우드 실행(Cloud execution)만의 논점이기도 합니다. 로컬 PC에서 실행하는 Claude Code라면, 로컬에 있는 메모나 작업 디렉터리 내의 파일과 같은 잡다한 정보에도 파일 탐색의 연장선상에서 접근할 수 있고, 로컬에서 DB나 클라우드의 CLI를 호출하여 가져올 수 있는 정보도 있습니다. 반면 routine은 원격 클라우드 서버에서 동작하므로, MCP로 연결된 곳에 있거나 연동된 리포지토리(Repository)에 있는 것과 같이 '원격에서 접근 가능한 위치'에 정보가 놓여 있지 않으면 애초에 접근할 수 없습니다. 접근 장벽이 한 단계 높아지는 셈입니다. 저희의 경우에는 판단에 필요한 정보가 원래 접근하기 쉬운 곳에 통합 및 중앙 관리되어 있었던 덕분에, 클라우드 실행에서도 로컬과 다를 바 없이 동작할 수 있었다는 실감이 듭니다 [3].

또한 Notion도 MCP로 연결할 수 있으므로, 원리적으로는 설계서나 PRD(제품 요구 사항 문서)에도 접근할 수 있어 'PRD와의 정합성', '설계서로부터의 이탈'과 같은 관점까지 리뷰에 포함할 수 있습니다. 이 부분은 아직 튜닝(Tuning)하지 않았으며, 정확히는 인간이 리뷰할 때 매번 그 정도의 관점까지 포함하는지에 대해서는 별도의 논의가 필요하다고 생각합니다. 리뷰의 역할이나 논점에 따라, 어디까지 비서에게 맡길지는 커스터마이징(Customizing)할 수 있다는 감각입니다.

구현: Routines를 Push형으로 구성하기

Pull형이 아닌 Push형 흐름으로 만들기

구현에서 가장 효과적이었던 설계 판단은 Push형으로 만든 것입니다. 앞서 언급했듯이, 필요할 때마다 물어보러 가는 Pull형(전용 Skill)은 '물어보는 것 자체를 잊어버리는' 문제 때문에 실패했기에, 스스로 기억하지 않아도 업무 시간대에 비서 측에서 "지금 이런 상황입니다"라고 정기적으로 리마인드(Remind)를 겸해 전달되는 형태로 만들었습니다. 이는 개인적으로 지금 상당히 마음에 드는 업무 흐름입니다.

이를 실현하는 수단으로 Claude Code의 Routines(2026-06 시점 research preview)를 사용하고 있습니다. Routines는 prompt, 대상 리포지토리, MCP connector 등을 하나로 묶은 routine을 Anthropic의 클라우드 환경에서 trigger(트리거)로 실행할 수 있는 메커니즘이며, CLI라면 /schedule 명령어로 생성할 수 있습니다. trigger에는 schedule / API / GitHub event의 세 종류가 있으며, 이번에 사용 중인 것은 schedule trigger를 사용한 정기 실행입니다. 평일 아침, 점심, 저녁 세 번 자동으로 실행되어 그 출력을 자신의 Slack times 채널(#times-tawachan)로 흘려보내는 구성입니다.

여기에 더해, 정기 실행 타이밍에 다 담지 못할 때는 수동 키크(Manual kick, 정기 실행을 기다리지 않고 스스로 routine을 실행하는 것)도 병행하고 있습니다. GitHub 알림을 통해 "PR이 왔구나"라고 인지하고, 그것이 어느 정도 쌓였다 싶을 때 다음 cycle(routine이 한 번 돌아가는 단위)을 기다리지 않고 routine을 한 번 실행합니다. 첫 번째 판단(상태 관리 + 논점 좁히기)을 마친 후, 그 이후의 정기 cycle에 그대로 태우는 방식입니다.

여기서 효과를 발휘하는 것이 비서가 과거 cycle의 실행 상태를 고려해 준다는 점입니다. 지난 cycle에서 "초기 소견 완료", "본인 대응 완료"라고 판정했던 결과를 Slack의 과거 게시물이나 GitHub 코멘트 이력으로부터 다시 읽어 들여 차이점(diff)에 대해서만 동작하므로, 몇 번을 추가로 돌려도 동일한 PR에 중복 코멘트를 남기거나 같은 건을 두 번 통지하지 않습니다 [4]. 이 덕분에 정기 cycle과 수동 키크를 부담 없이 섞어서 사용할 수 있게 되어, 운용 측면에서 상당히 편해졌습니다.

액션은 "찬성 코멘트", "초기 리뷰 소견", "스킵" 세 가지

routine이 개별 PR에 대해 취하는 액션은 세 가지로 나누었습니다.

• 찬성 코멘트 (賛同コメント): 소규모이거나 기존 패턴을 따르고 있으며 중대한 논점이 없는 PR에는, "방향성은 좋아 보입니다. 본인의 최종 확인을 기다려 주세요"라는 소견 코멘트를 남기도록 합니다. 승인이 아니라 어디까지나 코멘트이며, routine의 지시서에서는 Approve를 명시적으로 금지하고 있습니다. -
• 초기 리뷰 소견 (初期レビュー所見): 신경 쓰이는 관점에 걸리는 PR에는, 논점을 좁힌 소견 코멘트를 남기도록 합니다 (최종 판단은 자신이 내린다는 전제의 톤으로) -
• 스킵 (スキップ): 볼 필요가 없는 것(Draft, 자신이 author인 경우, dependabot/renovate, 이전 cycle에서 대응 완료되어 변경 사항이 없는 경우 등)은 왜 스킵했는지 이유와 함께 알림에 남깁니다.

"전부 보기"도 "전부 안 보기"도 아닌, 자신의 인지 자원을 할애할 가치가 있는 것만 손에 올라오도록 분류하는 것이 기본 사고방식입니다. 승인 그 자체는 자신(인간)이 내린다는 전제하에, 비서 측은 판단에 관여하지 않습니다.

여기서 "결국 비서도 리뷰 코멘트를 쓰고 있는 것 아닌가?"라고 생각하실지도 모르겠습니다. 겉보기에는 확실히 리뷰 코멘트입니다. 다만, 인간의 리뷰에는 애초에 단계가 있어야 한다고 생각합니다. 처음에 확인하는 것은 설계 사상과 맞는지, 이번 구현의 온도감(어디까지 만들어 놓을 전제인지)은 타당한지 등과 같은 큰 틀입니다. 되돌아가는 작업(rework)이 발생한다면 여기서 발생합니다. 그 확인이 끝났다는 전제하에, 비로소 세부적인 부분을 살펴나가는 것입니다.

그리고 이 첫 번째 큰 틀의 질문은, PR이 달라도 대략 비슷하게 같은 질문이 되기 쉽습니다. 그렇기에 자신의 관점을 이식한 비서가 선제적으로 (先出し) 해줄 수 있습니다. 본인의 리뷰를 기다리는 동안 author와 큰 틀의 논의가 진행되고, 어느 정도 좁혀졌을 때 자신이 확인하는 흐름을 만들 수 있습니다. 질문은 선제적으로 던지되, 결론이나 승인은 내지 않습니다. 이 라인은 비서의 소견에서도 변하지 않습니다.

알림 포맷

routine으로부터 오는 알림은 매번 거의 동일한 포맷으로 정리되어 있습니다. 실제 사례를 3가지 패턴으로 소개합니다 (이미지 내의 리포지토리 이름, PR 제목 등에는 블러 처리를 하였고, 텍스트 필사본에서는 익명 처리로 대체하였습니다).

예시 1: 신규 대상 PR에 초기 리뷰 소견이 붙은 cycle

본 게시물은 건수의 요약(summary)일 뿐이며, 스레드에 PR별 상세 정보(작성자 / 규모 / 트리거 / 영역 판정 / 소견 / 논점 / GitHub 코멘트 링크)가 나열됩니다. 스레드 끝에는 "팔로우 대기 리마인더"가 붙어 있어, 이전 cycle에서 초기 리뷰를 마쳤음에도 자신이 아직 반응하지 않은 PR을 경과 시간 및 작성자 측의 움직임 유무와 함께 상기시켜 줍니다.

예시 2: 이전 cycle의 리마인더가 해소된 cycle

이전 cycle에서 "팔로우 대기" 상태였던 PR이 그 후 어떻게 되었는지를 차이점(diff)으로 보고해 주는 패턴입니다. 이후부터는 이미 이미지를 파악하셨을 것이라 생각하여 텍스트 필사본으로 올립니다.

🤖 Claude routine - PR 초기 리뷰 (時刻 JST)
금일 해당 PR 없음. 지난번 (14:06 JST)의 리마인더 2건은 모두 해소되었습니다.
이전 cycle (14:06 JST)로부터의 차이점:
...

예시 3: 모두 정리되어 "대상 0건"이 된 cycle

이렇게 움직임이 있는 것들이 차례로 해소되다 보면, 최종적으로 모든 것이 "대응 완료"가 되어 스킵 이유만 나열되는 깔끔한 알림이 됩니다.

🤖 Claude routine - PR 초기 리뷰 (時刻 JST)
대상: 총 0건 (내역: 찬성 코멘트 0건 / 초기 리뷰 소견 0건 / 스킵 전건)
그중 Slack 리뷰 요청: 0건
...

알림에 반드시 "왜 그것을 올렸는지", "왜 스킵했는지"에 대한 이유가 붙기 때문에, 자신은 링크를 열기 전에 "이것을 정말로 볼 필요가 있는가"를 판단할 수 있습니다. 또한 소소한 팁으로, 본 게시물은 요약으로만 제한하고 상세 내용은 스레드에 접어두는(collapse) 방식의 구분 출력도 지시서에 적어두었습니다 [5].

효과: 인지 부하의 경감과 "정보의 흐름" 재구성

이 운용에서 가장 효과를 보고 있는 것은, "대상 0건"이라는 알림이 정기적으로 도착한다는 사실 자체가 인지 부하를 낮추고 안심감을 만들어준다는 점입니다. 리뷰가 빨라졌다거나 정확해졌다기보다, 이 부분이 핵심적으로 작용하고 있습니다.

리뷰를 안고 있으면 머릿속 한구석에 "내가 무언가 놓치고 있는 건 아닐까", "누군가를 기다리게 하고 있는 건 아닐까" 하는 찜찜함이 상주하게 됩니다. 이것이 의외로 인지 자원 (Cognitive Resources)을 소모합니다. 실제로 리뷰 작업을 하고 있는 것도 아닌데, 계속 옅은 긴장 상태를 유지하고 있는 느낌에 가깝습니다.

"대상 0건, 모두 스킵 사유 포함"이라는 알림은 그 찜찜함을 사유와 함께 명시적으로 해소해 줍니다. "A는 이전 cycle에서 내가 이미 답장함", "B는 Approve 완료", "C는 Draft 상태라 대상 제외"와 같이 한 건씩 나열되어 있으면, 머릿속 상태와 현실의 상태가 동기화됩니다. 리뷰 양이 줄어든 것은 아닌데, 리뷰를 안고 있다는 느낌이 줄어든다는 것이 실감 나는 부분입니다.

"정보의 흐름"을 재구성한다는 관점

다른 각도에서 보면, 이번 운용은 AI가 개별 작업을 대신해 주었다기보다, 리뷰에 필요한 정보의 흐름을 재구성했다고 표현하는 것이 더 가까운 느낌이 듭니다.

이전에는 PR의 상태(누구를 기다리는지 / Approve 완료 여부 / 내가 답장을 했는지)가 GitHub와 Slack에 흩어져 있었고, 그것을 자신의 머릿속에서 명寄せ (데이터 통합/대조) 하여 (즉, 흩어진 정보를 대조하여 하나의 PR에 연결하는 작업), 거기서부터 "지금 봐야 할 것"을 다시 골라낸 뒤에야 비로소 리뷰 본론에 들어가는 흐름이었습니다. AI를 활용한다고 해도 리뷰 본론만을 빠르게 만들려고 하면, 이 전 단계인 "흩어진 정보를 머릿속에서 명寄せ 하는" 비용은 그대로 남습니다.

이번 운용은 그 전 단계의 명寄せ를 routine이 대신해 줌으로써, "내가 리뷰에 착수할 때는 정보가 이미 정리된 상태로 손에 들어와 있다"는 식으로 흐름을 바꾸고 있습니다. AI를 작업의 대체가 아닌 정보의 흐름의 재구성으로서 사용하는 감각에 가깝습니다[6]. 이는 리뷰에 국한되지 않고, AI 활용의 효과적인 지점에 대해 최근 자주 고민하고 있는 내용이기도 합니다.

"AI 활용 = 눈앞의 작업이 빨라진다"는 이미지로 이야기되곤 하지만, 이번 운용을 통해 얻은 것은 오히려 해야 할 일이 안심하고 원활하게 진행되는 상태였습니다.

운용상의 배려: AI의 1차 대응임을 명시하기

운용하면서 신경 쓰고 있는 점은, AI의 코멘트인지 본인의 코멘트인지를 혼동하게 만들지 않는 것입니다. AI 에이전트가 일상적으로 사용되면서 "이것은 AI가 작성한 것인가, 본인이 작성한 것인가"가 모호해지기 쉽습니다. 본인이 내용을 보고 판단한 뒤 AI에게 문장만 대필하게 하는 경우도 있으므로, "AI 같은 문장 = 본인이 보지 않았다"라고 단정할 수도 없습니다. 리뷰에 있어서 이러한 모호함은 꽤 큰 영향을 미칩니다.

AI가 작성한 코멘트를 "리뷰어 본인의 공식적인 지적"으로 받아들이게 되면, 본인이 확인하기 전까지 구현자가 수정 방향을 결정할 수 없게 됩니다. 반대로 "이건 AI겠지"라며 가볍게 취급되어 중요한 지적이 간과될 가능성도 있습니다. 앞서 리뷰 자체를 AI에게 대체시키는 방향은 취하지 않겠다고 썼지만, 여기서 비서가 작성하는 초기 소견은 별개의 카테고리입니다. 어디까지나 AI 명의로, 최종 판단을 유보하는 톤으로 작성된다는 점이 전자와의 구분점입니다.

따라서 AI에게 소견을 쓰게 하는 코멘트에는 "Claude routine (AI)에 의한 초기 리뷰입니다"라는 푸터를 반드시 붙이고, 단정적인 지적이 아닌 "본인도 병행하여 확인 중이므로 최종 판단은 기다려 주세요"라는 톤에 머물도록 하며, 최종적인 판단은 본인(나)이 리뷰하는 타이밍에 수행한다는 규칙을 지시서에 적어두고 있습니다. 아울러 PR을 만들어 준 사람에게 방해가 되지 않도록, 쓸데없이 트집을 잡는 듯한 코멘트는 하지 않도록 하는 것도 이 조정의 일부입니다.

실제로 GitHub에 달리는 코멘트는 다음과 같은 모습입니다. 서두와 푸터 양쪽에서 AI의 초기 리뷰임을 명시하면서, "본인의 최종 확인을 기다려 주세요"로 마무리합니다.

또 하나, 코멘트 안에 "리포트 전체"로서 자신의 times에 게시된 상황 공유 스레드로의 링크를 걸게 하고 있습니다. 비서가 자신에게 어떤 내용을 알리고 있는지를 다른 멤버들도 찾아보고 싶다면 찾아볼 수 있도록 해두려는 의도입니다. 어디까지나 자신 전용의 프라이빗한 알림 AI로 폐쇄하는 것이 아니라, 비서가 어떻게 움직이고 있는지는 팀에 대해 오픈해 두는 형태를 취하고 있습니다.

무반응으로 방치되는 것보다, 첫 단계에서 문맥과 우려 사항이 제시되는 편이 구현자 입장에서도 다음 액션을 취하기 쉽다는 생각입니다. 한편으로 "AI가 OK를 냈으니 머지(Merge)"와 같은 움직임으로 이어지지 않도록, 톤과 위치 설정은 신중하게 만들고 있습니다. 승인은 기본적으로 자신(인간)이 한다는 원칙은 유지하고 있습니다.

시도하며 변한 점

비서 워크플로우를 돌리기 시작한 후, 제 안에서 변한 감각을 몇 가지 꼽아보겠습니다.

가장 큰 것은 "봐야 할 것의 관리"에서 해방됨으로써, "그 PR 답장했었나?", "이거 내가 봐야 하는 건가?"를 머릿속에 담아두지 않아도 되게 되었다는 점입니다. 컨텍스트 (Context) 재구축 비용도 낮아져서, 한 번 떠나있던 PR로 돌아갈 때 루틴 (routine)이 쌓아준 이전 사이클 (cycle)까지의 경위로부터 바로 파악할 수 있습니다. 승인 완료(Approve 済み)·자신이 볼 필요 없음 판정을 비서가 해주기 때문에, 링크를 열기 전에 "볼 것인가 말 것인가"의 판단이 끝나 있다는 점도 효과적입니다.

소감으로는, 모든 방향에서 정보를 가져와 자신의 타임즈 (times)로 흘려보내 주기 때문에, 그것만 보면 된다는 점이 안심이 됩니다. 알림에는 문맥이 붙어 있으므로, 그 링크를 따라가며 신경 쓰이는 점을 코멘트(Comment)한다. 혹은 그 자리에서 동기적(Synchronously)으로 AI와 상담하며 "역시 그렇네"라고 확인하며 코멘트를 남긴다. 그리고, 그 이후는 잊어버려도 상관없다. 코멘트에 작성자(Author)로부터 답장이 와 있다면 다음 회차에 AI가 이를 포착하여 팔로업 (Follow-up) 해주므로, 다음 회차 전까지 안심하고 잊을 수 있는 것입니다.

산재해 있던 것들이 하나의 흐름 속에 통합되었다. 이것이 인지 부하 (Cognitive load)의 감소로 이어지고 있다는 것이 현재의 소감입니다.