PR을 올려놓고 나면 그 뒤가 의외로 사람 손이 많이 갑니다. CI가 돌아가는 몇 분을 기다렸다가 결과를 확인하고, 리뷰어가 코멘트를 남기면 다시 열어서 읽고 반영해야 합니다. 낮에 계속 붙어있을 수 있는 PR이면 상관없는데, 자기 전에 올려둔 PR에 새벽에 CI가 실패하거나 리뷰어가 다음날 오전에야 코멘트를 남기면, 그 사이 시간은 그냥 멈춰 있었습니다. GitHub MCP 서버로 PR 상태를 물어보는 방식은 사람이 "확인해줘"라고 매번 요청해야 움직이니, 결국 사람이 그 타이밍에 자리에 있어야 한다는 전제는 그대로였습니다.
어떤 작업이었나
Claude Code Remote(클라우드 세션)에서 PR을 하나 만든 뒤, 그 뒤처리를 사람이 매번 확인하지 않아도 되게 만들고 싶었습니다. CI가 실패하면 로그를 보고 고쳐서 다시 푸시하고, 리뷰 코멘트가 달리면 반영하거나 답변하는 흐름을 사람의 개입 없이 이어가는 게 목표였습니다.
AI를 어떻게 활용했나
PR을 만든 직후에 세션한테 이렇게 요청했습니다.
이 PR 계속 지켜보고, CI 실패나 리뷰 코멘트 올라오면 알아서 대응해줘
이 요청을 받으면 세션이 해당 PR을 구독합니다. 이후로는 사람이 다시 "확인해줘"라고 물어볼 필요가 없습니다. CI 상태가 바뀌거나, 새 리뷰 코멘트가 달리거나, base 브랜치와 머지 충돌이 생기는 것 같은 이벤트가 GitHub 쪽에서 발생하면 그 자체가 세션을 깨우는 신호가 됩니다. 세션은 그 순간 다시 켜져서 무슨 일이 있었는지 확인하고, 필요하면 코드를 고쳐서 푸시까지 마칩니다. 사람이 폴링하듯 몇 분마다 상태를 확인하는 게 아니라, 상태가 실제로 바뀐 시점에만 반응하는 구조입니다.
실제로 한 번은 자정 넘어 올린 PR에서 타입 체크가 실패했는데, 다음날 아침에 열어보니 이미 새벽 사이에 원인을 찾아 고친 커밋이 하나 더 올라가 있고 CI도 초록불로 바뀌어 있었습니다. 사람이 자는 동안 CI 실패 → 로그 확인 → 원인 코드 수정 → 재푸시까지의 사이클이 알아서 돌아간 셈입니다.
처음에 헷갈렸던 부분
이벤트가 올 때마다 매번 PR에 진행 상황을 코멘트로 남기게 했더니, 그 코멘트 자체가 다시 "새 코멘트가 달렸다"는 이벤트로 잡혀서 자기가 남긴 말에 자기가 또 반응하려는 낌새가 있었습니다. 그래서 본인이 이미 작성한 코멘트나 답글은 새로운 요청으로 취급하지 않고 무시하도록 정리했습니다. 그렇게 하지 않으면 같은 스레드를 계속 맴도는 루프가 생길 수 있습니다.
또 하나는 웹훅 이벤트가 100% 도착한다는 보장이 없다는 점이었습니다. 어쩌다 이벤트 하나가 누락되면 PR이 조용히 멈춰있게 되는데, 그 상태를 사람이 따로 확인하지 않으면 아무도 모르고 지나갈 수 있습니다. 그래서 이벤트만 믿지 않고, 한 시간 간격 정도로 "지금 이 PR 상태가 어떤지 한 번 더 봐줘" 하는 체크인을 같이 걸어뒀습니다. 이벤트가 정상적으로 왔다면 체크인에서는 달라진 게 없어 조용히 지나가고, 이벤트가 새어나간 경우에만 체크인이 그 공백을 메웁니다.
결과와 얻은 팁
- CI 실패나 리뷰 코멘트처럼 "언젠가 일어날 이벤트"를 기다려야 하는 작업은, 사람이 주기적으로 확인하는 것보다 이벤트 발생 시점에 세션이 깨어나는 구조가 훨씬 잘 맞습니다. 사람은 그 시간에 다른 일을 하고 있어도 됩니다.
- 자동으로 대응하게 맡기더라도 모든 걸 알아서 처리하게 두지는 않았습니다. 여러 파일을 건드리는 설계 수준의 리뷰 코멘트는 바로 코드를 고치는 대신 "이렇게 바꾸면 어떨지" 제안만 남기고 사람 판단을 기다리게 했습니다. CI 실패처럼 정답이 분명한 것과, 리뷰 코멘트처럼 판단이 필요한 것을 구분해두는 편이 안전합니다.
- 웹훅 기반 자동화는 이벤트가 빠질 수 있다는 걸 전제로 설계하는 게 낫습니다. 이벤트만 믿고 끝내면 조용히 멈춰버린 PR을 아무도 눈치채지 못합니다. 느슨한 주기의 체크인 하나를 같이 걸어두는 정도로도 그 공백은 충분히 메워졌습니다.