에이전트 창을 늘리기 전에 세션 경계부터 그려야 하는 이유

코딩 에이전트를 여러 개 띄우는 일은 이제 어렵지 않다. 어려운 쪽은 그다음이다. 어느 대화가 어떤 파일을 바꿨는지, 옆에서 던진 질문이 본 작업의 문맥을 얼마나 가져갔는지, 다른 창에서 이어받은 세션이 같은 상태를 보고 있는지 확인해야 한다. 창의 개수는 병렬성을 보여주지만 작업 경계까지 보장하지는 않는다.

GitHub가 8월 31일 공개한 VS Code용 Copilot 월간 변경 기록은 이 문제를 정면으로 다룬다. 8월에 배포된 VS Code 1.132~1.135에는 채팅 나란히 배치, /btw 보조 대화, 프롬프트 타임라인, 외부 세션 이어받기, 여러 VS Code 창에서 같은 Agent Host 세션 연결, 모델별 토큰 사용량 표시가 들어갔다. 통합 브라우저에서는 여러 HTML 요소를 골라 한꺼번에 피드백할 수도 있다.

기능 목록만 보면 생산성 업데이트처럼 보인다. 하지만 운영 관점에서 보면 더 중요한 변화가 있다. 에이전트 작업의 기본 단위가 "채팅창 하나"에서 "여러 화면과 도구가 연결된 세션"으로 커지고 있다. 이때 공유 문맥, 파일 변경, 검토 증거를 서로 다른 것으로 관리하지 않으면 편리한 이어받기가 곧 상태 혼선이 된다.

이번 업데이트에서 달라진 것

세션 쪽 변화는 세 묶음으로 나눠 볼 수 있다. 첫째는 표시 방식이다. 여러 채팅을 가로·세로 그룹으로 나란히 놓고, 돌아왔을 때 그 배치를 복원한다. 긴 대화에서는 transcript gutter의 프롬프트 타임라인으로 특정 요청과 관련 파일 변경을 함께 찾는다.

둘째는 문맥의 분기와 연결이다. /btw는 본 작업이 계속 실행되는 동안 옆 대화를 연다. 공식 설명에 따르면 이 대화는 주 대화의 문맥과 prompt cache를 공유한다. Agent Host는 같은 세션을 여러 VS Code 창에 연결할 수 있고, 다른 애플리케이션에서 시작한 Copilot 또는 Claude 세션도 Sessions 목록에서 이어갈 수 있다.

셋째는 검토 보조다. 실험 기능인 /rubber-duck은 보완 모델에 놓친 세부 사항과 경계 사례를 묻는다. 응답 footer에서는 입력, 캐시된 입력, 출력 토큰을 모델별로 확인할 수 있다. 통합 브라우저의 요소 주석 기능은 여러 HTML 요소를 선택해 수정 피드백을 묶어서 전달한다.

에이전트 세션 ID, 작업공간 ID, 실행 소유권, 검토 증거를 분리하고 문맥과 프롬프트 캐시만 선택적으로 공유하는 운영 경계도

세션은 대화의 연속성을 나타낼 뿐 파일 변경의 격리를 보장하지 않는다. 작업공간과 쓰기 소유권, 검토 증거를 별도로 기록해야 한다. 출처: github.blog/changelog/2026-08-31-github-copilot-in-vs-code-august-2026-releases.

공유 문맥과 공유 작업공간은 같은 말이 아니다

/btw가 문맥과 prompt cache를 공유한다는 설명은 비용과 응답 연속성에는 유리하다. 본 대화의 배경을 다시 길게 설명하지 않고 옆 질문을 던질 수 있기 때문이다. 그러나 공식 변경 기록은 보조 대화가 파일 쓰기 권한, 작업 디렉터리, 도구 실행 잠금까지 별도로 격리된다고 말하지 않는다. "문맥을 공유한다"를 "변경이 서로 안전하게 분리된다"로 읽으면 안 된다.

여러 창을 같은 Agent Host 세션에 연결하는 기능도 마찬가지다. 같은 상태를 다른 화면에서 볼 수 있다는 뜻이지, 두 창이 동시에 내린 수정 명령의 순서를 자동으로 안전하게 직렬화한다는 보장은 아니다. 외부 세션을 이어받을 때도 이전 도구 호출이 끝났는지, 승인 대기 상태가 남았는지, 현재 체크아웃과 세션이 기억하는 커밋이 같은지 확인해야 한다.

그래서 세션 ID와 작업공간 ID를 분리해 기록하는 편이 낫다. 세션은 대화와 추론의 연속성을 가리키고, 작업공간은 실제 파일과 브랜치의 변경 경계를 가리킨다. 하나의 세션을 여러 창에서 볼 수 있어도 쓰기 작업자는 한 명으로 제한할 수 있다. 반대로 서로 다른 세션이라도 같은 작업 디렉터리를 쓰면 파일 충돌 가능성이 있다.

타임라인은 로그가 아니라 검토용 색인이다

프롬프트 타임라인은 특정 요청과 관련 파일 변경으로 이동하는 데 유용하다. 긴 대화에서 "어느 요청 뒤에 이 diff가 생겼나"를 찾는 시간이 줄어든다. 하지만 화면에서 탐색할 수 있다는 것과 변경 증거가 완전하다는 것은 별개다.

운영 기록에는 최소한 프롬프트 ID, 세션 ID, 시작 시점의 커밋, 도구 호출 결과, 최종 diff 해시가 필요하다. 타임라인은 이 기록을 사람이 읽는 입구로 쓰고, 저장소와 CI 결과를 최종 증거로 삼아야 한다. 터미널 출력이 채팅 안에서 보기 좋게 reflow되더라도 명령의 종료 코드나 전체 로그가 바뀌지는 않는다는 점도 같다.

모델별 토큰 표시도 비용 추적의 출발점일 뿐이다. 입력 토큰이 적다고 작업이 싸게 끝났다는 뜻은 아니다. 에이전트가 반복 실행한 테스트 시간, 브라우저 조작 횟수, 생성한 뒤 버린 diff까지 함께 봐야 한다. prompt cache는 과금과 지연을 줄일 수 있지만 오래된 가정을 재사용하는 통로도 된다. 브랜치나 요구사항이 바뀌었다면 캐시 이점보다 상태 재확인이 먼저다.

두 번째 모델은 승인자가 아니다

/rubber-duck은 한 모델이 놓친 경계 사례를 다른 모델에 묻는 기능이다. 아이디어 검토에는 쓸 만하다. 그러나 두 모델이 같은 잘못된 파일 상태나 불완전한 요구사항을 읽으면, 두 번째 답변도 독립 검증이 아니다. 서로 다른 모델을 썼다는 사실만으로 검토가 분리되지는 않는다.

두 번째 의견은 검토 후보를 늘리는 단계로 제한하는 편이 안전하다. 어떤 테스트를 추가할지, 어떤 입력 경계를 확인할지, 어느 diff가 의심스러운지 제안하게 한다. 실제 승인은 재현 가능한 테스트와 사람이 읽은 diff, 필요하면 별도 작업공간에서의 재실행으로 결정한다.

통합 브라우저의 다중 요소 주석도 같은 원칙을 적용할 수 있다. 화면의 여러 문제를 한 번에 지시하되 각 주석을 안정적인 DOM 선택자나 스크린샷 좌표, 기대 결과와 연결한다. 에이전트가 배치 수정한 뒤에는 원래 선택한 요소가 모두 바뀌었는지 확인한다. "요청을 전달했다"와 "수정이 반영됐다" 사이에 검증 단계를 둬야 한다.

주 에이전트와 보완 모델의 의견을 경계 사례 후보로 모은 뒤 독립 테스트, 사람이 읽은 diff, 재현 가능한 결과로 승인하는 검토 게이트

보완 모델과 프롬프트 타임라인은 검토할 지점을 찾는 도구다. 최종 승인은 독립 테스트와 diff 검토가 맡아야 한다. 출처: github.blog/changelog/2026-08-31-github-copilot-in-vs-code-august-2026-releases.

실전에서는 네 개의 경계를 둔다

첫째, 작업 경계다. 세션마다 브랜치나 worktree를 배정하고 시작 커밋을 기록한다. 같은 Agent Host 세션을 여러 창에서 열더라도 파일 쓰기는 한 창만 맡긴다.

둘째, 문맥 경계다. /btw에는 조사, 설명, 대안 비교처럼 읽기 중심 질문을 우선 보낸다. 파일 수정이 필요해지면 본 대화로 명시적으로 합치고 어떤 결론을 가져왔는지 남긴다.

셋째, 실행 경계다. 외부 세션을 이어받기 전에 실행 중인 도구, 승인 대기, 변경 파일, 현재 브랜치를 확인한다. 확인이 끝나기 전에는 새 명령을 겹쳐 실행하지 않는다.

넷째, 검토 경계다. 타임라인과 /rubber-duck은 검토를 돕는 인터페이스로 사용하되, 병합 조건은 테스트 결과와 diff 해시로 고정한다. 토큰 사용량은 세션 비용에 포함하고, 테스트 시간과 재시도 횟수는 별도 운영 지표로 기록한다.

주의할 점

이번 변경 기록은 기능 제공 범위를 설명하지만 동시 수정 충돌률, 세션 복구 정확도, /btw의 비용 절감 폭을 측정한 벤치마크는 제공하지 않는다. 따라서 "여러 에이전트를 안전하게 병렬 실행할 수 있게 됐다"거나 "캐시 공유로 비용이 몇 퍼센트 줄었다"고 말할 근거는 없다.

또 여러 항목은 실험 기능이다. /rubber-duck, hybrid Markdown editor, GitHub 로그인 없이 Agents 창을 여는 설정은 안정성이나 인터페이스가 바뀔 수 있다. 팀 표준에 넣기 전에는 사용 중인 VS Code 버전과 설정 이름을 고정하고 작은 저장소에서 복구 절차를 시험해야 한다.

Claude 세션에서 Anthropic 구독과 Copilot 구독의 모델을 바꿀 수 있다는 기능도 결과 동일성을 보장하지 않는다. 모델을 바꾸는 순간을 타임라인에 남기고, 변경 전후의 모델·도구 권한·토큰 사용량을 함께 기록해야 재현 가능한 검토가 된다.

결론

VS Code의 8월 업데이트는 에이전트 대화를 찾고, 나누고, 이어받는 마찰을 줄였다. 이제 한 세션은 옆 대화, 여러 창, 외부 애플리케이션, 통합 브라우저까지 뻗을 수 있다. 그래서 창을 많이 여는 법보다 경계를 정하는 일이 먼저다.

세션 ID는 대화의 연속성을, 작업공간과 시작 커밋은 파일 변경의 범위를, 타임라인은 검토 위치를, 테스트와 diff 해시는 승인 근거를 맡게 하자. 이 네 가지를 섞지 않으면 새 기능을 편하게 쓰면서도 "누가 어느 상태에서 무엇을 바꿨나"를 다시 확인할 수 있다.

참고 자료

댓글

댓글 쓰기

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

이미지
1. --worktree 가 해결하는 충돌은 무엇인가 에이전트 두 개가 같은 저장소에서 동시에 파일을 고치면 가장 먼저 부딪히는 것은 모델이 아니다. 한쪽이 바꾼 작업 트리와 인덱스를 다른 쪽이 읽고, 테스트 산출물이 섞이고, 아직 정리하지 않은 변경을 다음 작업이 자기 입력으로 오해한다. OpenAI는 GitHub 기준 2026년 9월 9일 22:35 UTC, 한국 시각 10일 07:35에 공개한 Codex 0.154.0에 실험적 managed worktree 기능을 넣었다. 새 실행이나 기존 세션의 fork를 --worktree 로 시작할 수 있고, TUI에서는 /worktree 로 새 대화 또는 현재 대화의 fork를 별도 체크아웃에 둘 수 있다. 공식 릴리스 설명은 이를 "isolated checkouts"라고 부른다. 다만 이 표현을 저장소 전체와 외부 환경까지 격리한다는 뜻으로 읽으면 곤란하다. Git worktree가 분리하는 것은 체크아웃의 파일과 작업별 관리 상태다. Git 공식 문서에 따르면 연결된 worktree는 HEAD , index 같은 파일을 따로 갖지만 나머지 저장소 데이터는 공유한다. 따라서 같은 소스 파일을 동시에 편집하는 충돌은 줄일 수 있어도, 같은 원격 브랜치에 push하거나 같은 배포·테스트 데이터베이스를 건드리는 충돌까지 사라지지는 않는다. 그림 1. Codex 0.154 managed worktree는 체크아웃 생성과 thread 소유권을 연결한다. binding 전 실패 시 체크아웃을 보존한다. 출처: github.com/openai/codex/releases/tag/rust-v0.154.0 . 2. Codex는 새 체크아웃을 어떻게 만든다 0.154.0 태그가 가리키는 커밋의 codex-rs/worktree/src/lib.rs 를 보면 생성 순서가 꽤 보수적이다. 먼저 현재 HEAD 를 commit SHA로 확정한다. 그 SHA에서 git worktree add --detach --...
자세한 내용 보기

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

이미지
1. 잠금은 작업을 소비했다는 기록이 아니다 에이전트 작업자를 여러 개 띄웠다. 각 작업자는 PostgreSQL에서 FOR UPDATE SKIP LOCKED 로 작업 하나를 가져온다. 다른 작업자가 잡은 행을 기다리지 않으니 병렬 처리도 잘되는 것처럼 보인다. 그런데 커밋한 뒤 같은 작업이 다시 나온다면 무엇이 빠진 걸까? 핵심은 행을 잠갔다는 사실과 작업을 맡았다는 상태가 서로 다르다 는 점이다. PostgreSQL 공식 문서는 행 잠금이 트랜잭션 종료 때 풀린다고 설명한다. SKIP LOCKED 는 지금 즉시 잠글 수 없는 행을 건너뛰는 옵션이지, 그 작업을 영구히 큐에서 제거하는 명령이 아니다. 공식 PostgreSQL 18.0 소스의 회귀 테스트에도 이 차이가 드러난다. 상태를 바꾸지 않고 조회만 하는 순서에서 세션 A가 작업 1을 잠그면 B는 작업 2를 받는다. A가 커밋한 뒤 B가 다시 조회하면 작업 1이 나온다. 프로젝트가 저장한 기대 출력과 별도로, 이번 글에서는 PostgreSQL 16.2의 격리된 로컬 DB 에서도 이 순서를 실제 확인했다. 문서와 고정 소스는 18 계열, 직접 실행한 엔진은 16.2다. 두 버전을 같은 실험으로 섞거나 최신 버전의 성능 측정이라고 부르지 않는다. 그림 1. 잠금이 해제돼도 작업 상태가 그대로면 같은 작업이 다시 선택된다. 공식 18.0 기대 출력과 별도 16.2 로컬 확인에 근거한 자체 도식. 출처: www.postgresql.org/docs/18/sql-select.html . 조회 결과가 0행일 때도 해석에 주의해야 한다. 모든 후보가 다른 작업자에게 잠겨 있으면 SKIP LOCKED 는 아무것도 반환하지 않을 수 있다. 로컬 확인에서는 일반 조회로 보이는 행이 2개인데 잠금 건너뛰기 조회는 0행이었다. 따라서 “지금 가져올 작업이 없다”와 “큐 자체가 비었다”는 같은 말이 아니다. 공식 문서 역시 이 옵션이 일반적인 일관된 조회에는 적합하지 않고, 큐와 비슷한 테이블의 여러 소비자 사이 경합을...
자세한 내용 보기

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다

이미지
코딩 에이전트를 위한 문서를 만든다고 하면 보통 API 레퍼런스나 상세한 개발 가이드부터 떠올린다. 그런데 실제 에이전트의 작업 기록을 분석한 연구에서는 다른 문서가 훨씬 자주 등장했다. AGENTS.md , CLAUDE.md 같은 지시 파일과 계획·작업 노트였다. 2026년 8월 공개된 논문 From Agent Behaviour to Agent-Friendly Documentation 은 공개된 코딩 에이전트 세션과 풀 리퀘스트를 이용해 에이전트가 어떤 문서를 읽고 쓰는지 조사했다. 연구진이 분석한 데이터는 다음과 같다. SWE-chat의 파싱 가능한 세션 557개 개발 이벤트 94,813개 문서 관련 이벤트 3,033개 AIDev의 에이전트 풀 리퀘스트 33,097개 파일·커밋 단위 변경 기록 690,260개 에이전트가 가장 자주 만진 문서 문서 상호작용에서 가장 큰 비중을 차지한 것은 에이전트 지시 파일이었다. 문서 유형 이벤트 수 비중 에이전트 지시 파일 1,074 35.4% 계획·작업 노트 760 25.1% 작업 및 요구사항 문서 301 9.9% 설정 문서 205 6.8% README 197 6.5% API 레퍼런스 40 1.3% 지시 파일과 작업 노트를 합하면 전체 문서 상호작용의 60.5%다. API 레퍼런스는 1.3%에 그쳤다. 지시 파일이 API 레퍼런스보다 약 27배 많이 관찰된 셈이다. 코딩 에이전트의 문서 관련 이벤트 분포. 지시 파일과 계획·작업 노트가 전체의 60.5%를 차지했다. 출처: Gao & Chen, arXiv:2608.20195v1 . 이 수치를 "API 문서는 필요 없다"고 해석하면 곤란하다. 연구가 추적한 것은 저장소 안에서 명시적으로 열린 파일이다. 웹 문서, 모델이 이미 학습한 지식, 코드 주석, 런타임이 자동으로 주입한 문맥은 잡히지 않는다. 정확한 결론은 코딩 에이전트가 저장소 안에서 작업할 ...
자세한 내용 보기