GitHub Issues와 Projects에서 agent session 관리하는 법

에이전트를 실제 팀 workflow에 붙이면 가장 먼저 부딪히는 문제가 있습니다. 에이전트가 일을 하는 건 알겠는데, 지금 어디까지 했는지 보려면 별도 화면으로 들어가야 하고, 이슈·프로젝트 보드와 상태가 끊긴다는 점입니다. 결국 사람은 다시 슬랙이나 메모로 "지금 agent 뭐 하고 있죠?"를 묻게 됩니다. 이건 자동화가 아니라 관찰 비용을 다른 곳으로 옮긴 것에 가깝습니다.

GitHub가 공식 변경사항으로 issues와 projects 안에서 cloud agent session을 직접 보고, 로그를 확인하고, steer까지 할 수 있게 만든 이유도 여기에 있습니다. 기능 설명 자체는 짧지만, 실무 의미는 분명합니다. 이제 에이전트 진행 상황이 개발자의 기존 작업 표면 안으로 들어왔습니다.

이번 기능이 해결하는 실제 문제

기존 에이전트 도구의 가장 큰 단점은 맥락 분리였습니다. 이슈는 GitHub 이슈에 있고, 우선순위는 프로젝트 보드에 있고, 실제 agent 실행 상황은 별도 화면에 있고, 피드백은 채팅 도구에 흩어졌습니다. 그러면 세 가지 문제가 반복됩니다.

첫째, 담당자 가시성이 낮습니다. 누가 agent를 돌렸고 지금 멈췄는지 한눈에 안 보입니다.

둘째, steer 타이밍을 놓칩니다. 에이전트가 잘못된 방향으로 가도 늦게 발견합니다.

셋째, 기록이 분산됩니다. 나중에 왜 그런 결정을 했는지 추적하기 어렵습니다.

이번 업데이트는 이 세 가지를 줄이는 쪽으로 설계됐습니다. 이슈 헤더에 session pill이 생기고, 이슈와 프로젝트에서 session side panel을 열 수 있고, 프로젝트 뷰에는 "Show agent sessions"가 기본 활성화됩니다. 즉, 별도 도구를 찾아가지 않아도 기존 이슈 보던 자리에서 상태를 볼 수 있게 된 겁니다.

실제로 유용한 사용 시나리오

이 기능이 진짜 빛나는 건 단순 조회보다 중간 개입입니다. 예를 들어 버그 이슈 하나가 있다고 해보겠습니다.

이슈에서 agent를 실행합니다.
session pill에서 진행 상황을 바로 봅니다.
로그를 확인하다가 잘못된 가정을 발견합니다.
side panel에서 steer 지시를 넣습니다.
agent가 같은 이슈 맥락 안에서 계속 작업합니다.

이 흐름이 중요한 이유는 인간의 감독 비용을 줄이기 때문입니다. 예전에는 새 탭을 열고, 별도 실행 화면으로 이동하고, 무슨 이슈와 연결된 실행인지 다시 기억해야 했습니다. الآن은 이슈 중심으로 붙습니다.

프로젝트 보드에서도 마찬가지입니다. 백로그, 진행중, 리뷰대기 같은 칼럼을 보다가 특정 카드의 agent session을 열어 보면, 실제로 멈춘 상태인지, 완료됐는지, 추가 지시가 필요한지 바로 알 수 있습니다. 이건 운영 관점에서 큰 차이입니다. 프로젝트 보드가 다시 정적인 상태판이 아니라 실행 상태판에 가까워집니다.

기능보다 중요한 운영 규칙

도구가 좋아졌다고 바로 생산성이 올라가지는 않습니다. session이 이슈와 프로젝트에 붙는 순간 오히려 규칙이 더 중요해집니다. 안 그러면 모든 사람이 agent를 돌리지만 아무도 책임지지 않는 상태가 생깁니다.

최소한 아래 규칙은 있어야 합니다.

하나의 이슈에는 기본적으로 하나의 목표만 맡깁니다. "버그 찾고, 테스트 고치고, 문서도 업데이트"처럼 섞지 않는 편이 좋습니다.
agent session 시작 전에 완료 기준을 이슈 본문에 적습니다.
steer는 감정적 코멘트보다 제약 조건 형태로 남깁니다. 예: "auth 모듈은 건드리지 말 것", "테스트 추가 전 재현 로그 먼저 남길 것".
프로젝트 보드에서 session이 멈춘 카드는 24시간 내 사람이 triage합니다.
완료된 session은 이슈 코멘트에 결정 근거를 요약해 둡니다.

에이전트는 일하지만, 책임과 승인 구조는 여전히 사람이 가져가야 합니다.

이 기능을 제대로 쓰는 팀과 못 쓰는 팀의 차이

잘 쓰는 팀은 session을 "마법의 자동화"로 보지 않고, 비동기 협업 단위로 취급합니다. 그래서 로그, 중간 산출물, steer, 완료 기준을 다 기록 자산으로 남깁니다. 반면 못 쓰는 팀은 session을 그냥 더 똑똑한 실행 버튼처럼 씁니다. 그러면 실패했을 때 왜 실패했는지 아무도 설명하지 못합니다.

제가 보기엔 이 기능의 핵심 가치는 생산성보다 정렬(alignment)입니다. 이슈와 프로젝트 안에 session이 보이면, 에이전트 활동이 팀의 공식 backlog 안으로 들어옵니다. 그 순간부터 에이전트는 개인 실험이 아니라 팀 자산이 됩니다.

바로 적용할 때 추천하는 셋업

처음 도입할 때는 아래 정도만 해도 충분합니다.

버그 재현, 테스트 추가, 문서 정리처럼 비교적 안전한 작업부터 붙입니다.
프로젝트 보드에 "agent running" 또는 "agent needs steer" 같은 운영 라벨을 정합니다.
side panel을 볼 사람을 정합니다. 보통 이슈 assignee나 tech lead가 적당합니다.
session 로그 검토 기준을 만듭니다. 예: 10분 이상 무진전, 반복 오류 3회, 범위 이탈 시 개입.
완료 보고 템플릿을 통일합니다. 수정 파일, 검증 결과, 남은 위험, 추가 질문 네 줄이면 충분합니다.

이 정도만 있어도 agent session이 이슈 관리 흐름 안에 자연스럽게 녹습니다.

그래서 무엇이 달라지나

이번 기능은 화려해 보이지 않지만 꽤 실용적입니다. 에이전트를 별도 실험 환경에 가두지 않고, 팀이 이미 쓰는 이슈와 프로젝트의 실행 단위로 끌어왔기 때문입니다. 이 변화가 쌓이면 agent 도입의 병목이 모델 성능보다 운영 관찰성(operability)으로 이동합니다.

좋은 팀은 이걸 기회로 삼아 에이전트를 더 많이 돌릴 겁니다. 하지만 더 중요한 건 많이 돌리는 게 아니라, 멈췄을 때 빨리 발견하고 정확하게 steer할 수 있느냐입니다. 지금 팀의 문제도 아마 거기 있을 가능성이 큽니다.

실행 체크리스트

GitHub Issues에서 session pill이 보이는지 확인했다
Projects에서 Show agent sessions 기본 활성화 상태를 점검했다
side panel을 누가 보고 steer할지 역할을 정했다
이슈 본문에 완료 기준과 금지 범위를 먼저 적었다
session 개입 기준(시간 초과, 오류 반복, 범위 이탈)을 문서화했다
완료된 session의 수정 파일·검증 결과·남은 위험을 이슈에 남기도록 정했다

공식 출처: GitHub Changelog, View and manage agent sessions from issues and projects (2026-04-23)