에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가

CollabOps VS Code 확장을 마켓플레이스에 올렸습니다. 이슈와 변경요청, 저장소, 문서를 에디터 안에서 다루는 확장입니다.

기능 목록보다 먼저 이야기하고 싶은 것이 있습니다. 에디터 안에 일감을 들여놓는 일의 의미가 지난 2년 사이에 달라졌다는 점입니다. 예전에는 있으면 편한 기능이었지만 지금은 아닙니다.

개발자의 시간은 어디로 갔는가

코딩 에이전트가 코드를 다 쓰면 병목은 어디로 가는가에서 다룬 것처럼, 무너진 것은 코드를 쓰는 비용입니다. 저희 팀도 변경요청이 주에 몇 건에서 수십 건이 됐습니다. 사람이 부지런해진 게 아니라 한 구간의 마찰이 사라진 것입니다.

그러면 개발자의 하루는 어떻게 바뀔까요. 타이핑이 빠져나간 자리를 채우는 것은 세 가지입니다.

• 무엇을 시킬지 정하기 — 어떤 이슈를, 어떤 맥락과 함께
• 나온 것을 읽고 판단하기 — diff, CI 결과, 영향 범위
• 승인하기 — 병합, 배포, 되돌리기

그런데 셋 다 에디터 밖에 있었습니다. 이슈는 브라우저에, 리뷰 요청도 브라우저에, 빌드 결과도 브라우저에.

타이핑이 하루의 대부분이던 시절에는 이 왕복이 가끔 벌어지는 일이었습니다. 지금은 왕복이 곧 업무입니다. 그만큼 확장이 하는 일도 달라졌습니다. 예전에는 하루 몇 번의 번거로움을 덜어 주는 정도였다면, 지금은 늘어난 판단과 승인을 통째로 작업하는 자리에 되돌려 놓습니다.

에디터는 이제 개인 작업 공간이 아닙니다

더 중요한 변화가 하나 더 있습니다. 에이전트가 에디터 안으로 들어왔습니다.

Claude Code 도, Cursor 도, Copilot 도 브라우저가 아니라 에디터에서 돌아갑니다. 사람이 앉아 있던 자리에 에이전트가 같이 앉은 셈입니다. 에디터는 혼자 코드를 치던 개인 공간에서, 사람과 에이전트가 만나는 협업 지점이 됐습니다.

그런데 그 자리에 일의 정의와 결과만 없었습니다. 무엇을 고쳐야 하는지(이슈), 무엇이 나왔는지(변경요청), 통과했는지(CI)가 전부 브라우저 탭에 있었습니다. 사람도 에이전트도 에디터에 있는데, 정작 둘이 맞춰야 할 대상만 다른 창에 있었습니다.

이게 확장을 만든 이유입니다. 사람의 클릭을 줄이는 것보다, 협업이 벌어지는 자리에 협업의 대상을 놓는 것이 목적입니다.

아래는 그 생각으로 만든 확장의 설계 선택들입니다. 설치와 화면별 사용법은 VS Code 확장 문서에 단계별로 정리해 두었습니다.

이제 비싼 것은 타이핑이 아니라 읽기입니다

변경요청이 주에 세 건이면 순서를 정할 일이 없습니다. 수십 건이 되면 무엇부터 읽느냐가 그날 처리하는 양을 정합니다.

그래서 사이드바 맨 위를 목록이 아니라 역할별 묶음으로 만들었습니다. 내가 만든 변경요청, 내 리뷰를 기다리는 변경요청, 나에게 할당된 이슈. "전체 변경요청 47건" 은 정보가 아니지만 "내 리뷰 대기 3건" 은 다음 행동입니다.

한 건을 읽는 데 드는 품도 마찬가지입니다. 변경요청 하나를 판단하려면 설명, 연결된 이슈, CI 결과, 활동 이력을 봐야 하는데 브라우저에서는 탭 세 개였습니다. 확장은 이걸 한 문서로 만듭니다.

에이전트가 올리는 변경요청이 늘어날수록 여기가 전체 속도를 정합니다. 코드 생산이 열 배가 돼도 사람이 읽는 속도가 그대로면, 늘어난 만큼 쌓이기만 합니다.

화면이 아니라 텍스트로 만든 이유

확장에서 화면을 그리는 흔한 방법은 웹뷰입니다. HTML 을 그대로 넣을 수 있는 대신, CSS 로 에디터 테마를 흉내 내고 라이트와 다크를 따로 맞춰야 합니다.

CollabOps 확장은 상세 화면을 마크다운 가상 문서로 만듭니다. VS Code 에 기본으로 들어 있는 마크다운 프리뷰가 렌더합니다. 편집도 같은 원칙이라, 필드마다 입력창을 띄우는 대신 속성과 본문을 한 파일에 담아 열고 Cmd+S 로 저장하면 바뀐 항목만 서버에 반영합니다.

테마가 자동으로 맞고 검색·복사·되돌리기가 에디터 기본 동작 그대로라는 점은 부수 효과입니다. 더 중요한 이유는 따로 있습니다.

에이전트와 함께 일하는 화면에서 텍스트는 공통 인터페이스입니다.

에이전트가 내놓는 결과는 모델 성능에 컨텍스트 품질을 곱한 값입니다. 앞쪽은 모델 회사가 올려 주고, 뒤쪽이 우리 몫입니다. 그리고 컨텍스트를 조립하는 사람은 지금 에디터 앞에 앉아 있습니다.

변경요청 상세가 마크다운이면 설명과 연결된 이슈, 실패한 체크 이름이 한 덩어리 텍스트입니다. 그대로 선택해서 프롬프트에 넣을 수 있습니다. 웹뷰로 그린 화면은 사람 눈에만 보입니다. 요약해 달라고 시킬 수도, 이 CI 실패가 저 이슈와 관련 있는지 물어볼 수도 없습니다. 브라우저 탭을 오가며 손으로 옮겨 적는 만큼 컨텍스트는 부실해집니다.

편집 버퍼도 마찬가지입니다. 폼은 사람 손가락만 채울 수 있지만, 텍스트 버퍼는 사람이 쓰든 에이전트가 제안하든 같은 형식입니다. 검토도 저장도 diff 로 확인됩니다.

화면을 직접 그릴 여력이 없어서 텍스트를 고른 것이 아닙니다. 사람과 에이전트가 같은 것을 읽어야 하는 환경에서는 텍스트가 더 넓은 인터페이스입니다.

확장 안에 챗은 넣지 않았습니다

명령이 55개인데 그중 AI 기능은 하나도 없습니다. 의도한 것입니다.

에이전트는 이미 에디터에 있습니다. 사용자가 Claude Code 를 쓰든 Cursor 를 쓰든, 저희가 챗 창을 하나 더 넣어 봐야 네 번째 선택지일 뿐이고, 대개 앞의 셋보다 못합니다. 물어볼 곳이 하나 늘면 사용자는 어디에 물을지부터 정해야 합니다.

에이전트 도구를 만드는 회사와 실행 계층을 만드는 회사가 할 일은 다릅니다. 저희가 할 일은 에이전트가 읽을 수 있는 상태를 제공하고, 사람이 판단할 화면을 주는 것입니다. 앞은 MCP 서버가, 뒤는 이 확장이 맡습니다.

하나의 API 위에 세 개의 표면

확장은 웹 UI 를 감싸거나 CLI 를 호출하지 않습니다. 웹 화면이 쓰는 것과 같은 api/v2 를 직접 부릅니다. 감싸면 감싸인 쪽의 가정까지 그대로 물려받고, 웹이 바뀔 때마다 같이 깨집니다. 같은 API 를 직접 부르면 확장은 웹과 같은 권한을 갖고 같은 감사 기록을 남깁니다.

그 위에 지금 세 개의 표면이 있습니다.

같은 계약을 공유하기 때문에 셋이 보는 상태가 갈라지지 않습니다. 에이전트가 MCP로 이슈를 읽고 상태를 옮기는 동안, 사람은 같은 이슈를 에디터 사이드바에서 봅니다. 어느 쪽이 진짜인지 따질 필요가 없습니다.

이게 Execution Layer에서 말한 "상태·권한·실행이 같은 평면에 있어야 한다"의 실제 모습입니다. 평면이 하나면 표면은 늘려도 됩니다. 다음 플러그인이 새로 만들어야 하는 것은 화면뿐입니다.

빨라질수록 승인 지점은 명시적이어야 합니다

확장은 Git 명령을 실행할 수 있습니다. 그런데 전부 실행하지는 않습니다.

fetch 처럼 읽기만 하는 명령은 바로 돌립니다. checkout 이나 clone 처럼 작업 트리를 바꾸는 명령은 통합 터미널에 입력만 해 둡니다. 마지막 Enter 는 사람이 누릅니다. 병합도 확인 창에 변경요청 번호와 브랜치 방향을 적어, 누르기 전에 무엇이 일어날지 읽게 합니다.

클릭 한 번 줄이자고 만든 확장에 굳이 한 단계를 남겨 둔 이유는, 자동화의 총량이 늘어날수록 어디서 사람이 개입했는지가 기록으로 남아야 하기 때문입니다. 변경요청 상세의 활동 이력에 누가 무엇을 언제 했는지가 행위자와 함께 남는 것도 같은 이유입니다. 사람이 고친 것과 자동화가 만든 것이 섞여 들어올 때, 나중에 되짚을 수 있는 건 그 기록뿐입니다.

에이전트가 production 배포 권한을 가질 수 있는가에서 다룬 문제와 같습니다. 도구가 빨라질수록 승인 지점은 흐려지는 게 아니라 더 또렷해져야 합니다.

아직 웹이 나은 것

줄 단위 리뷰 코멘트와 파이프라인 화면입니다. diff 를 나란히 놓고 특정 줄에 코멘트를 다는 일은 넓은 화면과 파일 트리가 있어야 하고, 파이프라인도 로그와 단계별 그래프를 함께 봐야 판단이 됩니다. 담당자·라벨 지정과 영구 삭제도 아직 웹에서 합니다.

나머지는 에디터 안에서 끝납니다. Cmd+Alt+P 로 이슈·변경요청·문서·프로젝트·저장소를 한 번에 찾고, 골라서 고치고, CI 결과를 확인하고, 리뷰 브랜치를 받아 읽어보고, 병합하는 것까지입니다.

다른 IDE는요?

Eclipse 플러그인은 이미 나와 있고, JetBrains 와 Neovim 도 준비하고 있습니다.

확장은 마켓플레이스의 CollabOps 확장 페이지에서 받을 수 있습니다.