에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다

CollabOps Eclipse 플러그인을 마켓플레이스에 올렸습니다. 이슈와 변경요청, 저장소를 Eclipse 안에서 다루는 플러그인입니다.

만들면서 예상하지 못한 일이 하나 있었습니다. 붙일 자리를 찾다 보니 Eclipse 는 이미 20년 전에 이 문제를 풀어 두었더군요.

작업 컨텍스트는 20년 전에도 문제였다

CollabOps 플러그인은 Mylyn 커넥터입니다. Mylyn 은 Eclipse 에 들어 있는 작업 관리 프레임워크입니다.

Mylyn 이 2000년대 중반에 내건 전제는 이랬습니다. IDE 는 지금 개발자가 무슨 일을 하고 있는지 알아야 한다. 파일 트리 전체를 늘어놓는 대신 지금 작업에 관련된 것만 남기고, 작업을 바꾸면 화면도 따라 바뀌어야 한다는 것입니다.

그래서 Mylyn 에는 작업 활성화라는 게 있습니다. 이슈를 Activate 하면 그때 열려 있던 파일들을 기억해 두었다가, 나중에 같은 이슈로 돌아올 때 되살려 줍니다. 이슈 두세 개를 번갈아 처리할 때 머릿속으로 하던 복원을 IDE 가 대신하는 것입니다.

당시 이 아이디어는 사람의 집중력을 아끼자는 이야기였습니다. 화면에 뜬 파일이 30개면 사람이 그중 관련 있는 것을 골라내는 데 시간을 쓰니까요.

달라진 것은 그 컨텍스트를 읽는 쪽입니다

지금 같은 문제를 다시 만나고 있습니다. 이번에는 읽는 쪽이 사람만이 아닙니다.

코딩 에이전트가 코드를 다 쓰면 병목은 어디로 가는가에서 다룬 것처럼, 에이전트가 내놓는 결과는 모델 성능에 컨텍스트 품질을 곱한 값입니다. 앞쪽은 모델 회사가 올려 주고 뒤쪽이 우리 몫입니다.

그 컨텍스트가 무엇인지 따져 보면 Mylyn 이 말하던 것과 거의 같습니다. 지금 무슨 일을 하는지(이슈), 왜 이렇게 생겼는지(설명과 이력), 무엇이 걸려 있는지(연결된 변경요청과 체크 결과). Mylyn 은 그걸 사람 눈앞에 모아 주려 했고, 지금은 같은 것을 에이전트에게도 넘겨야 합니다.

그래서 플러그인이 하는 일은 단순합니다. CollabOps 서버의 작업을 Eclipse 의 작업 목록으로 가져오는 것. 담당 이슈와 변경요청이 IDE 안 목록으로 들어오고, 거기서 바로 고치고, 브랜치를 받아 체크아웃하고, 커밋해서 올립니다.

화면을 새로 그리지 않은 이유

플러그인을 만들 때 자체 뷰와 편집기를 새로 그릴 수도 있었습니다. 그렇게 하지 않았습니다.

Mylyn 커넥터로 만들면 목록과 편집기, 오프라인 동기화, 자격 증명 저장을 Mylyn 이 처리합니다. 우리가 만드는 것은 CollabOps 서버에 연결하는 부분뿐입니다.

얻는 것이 코드 양보다 큽니다. Eclipse 에서 이슈 트래커를 붙이는 표준 방식이라, Mylyn 커넥터를 써 본 적이 있다면 화면 배치나 조작이 낯설지 않습니다. 새 도구를 배우는 게 아니라 쓰던 도구에 서버가 하나 늘어난 것에 가깝습니다.

본문도 같은 원칙입니다. 설명은 마크다운으로 오갑니다. 웹에서 쓴 굵게, 목록, 코드 블록이 그대로 보이고 IDE 에서 고친 것도 웹에 같은 서식으로 나타납니다. 마크다운이면 그대로 선택해 프롬프트에 넣을 수 있다는 점이 VS Code 확장에서와 같은 이유로 중요합니다. 화면으로만 그려진 것은 사람 눈에만 보입니다.

Eclipse 를 쓰는 팀은 대개 에이전트를 못 깔고 있습니다

여기가 이 플러그인을 만든 진짜 이유입니다.

Eclipse 는 금융·공공·제조의 개발 현장에서 여전히 표준 IDE 로 남아 있습니다. 그리고 그런 환경은 대개 폐쇄망이거나 외부 도구 반입이 통제됩니다. 온프레미스에서 AI 에이전트를 도입하기 어려운 이유에서 다룬 조건들입니다.

그래서 이런 팀은 에이전트 도입이 몇 년 늦습니다. 하지만 늦는다고 실행 계층이 필요 없어지는 것은 아닙니다. 오히려 반대입니다. 승인 기록과 추적 요구가 더 엄격한 쪽이 이런 조직이고, 나중에 에이전트가 들어올 때 필요한 계약을 지금 만들어 두어야 하는 쪽도 여기입니다.

Eclipse 플러그인은 화려한 기능이 아니라 그 계약을 오래된 IDE 에도 똑같이 걸어 두는 일입니다. 지금은 사람이 그 목록을 읽고, 나중에는 같은 서버를 에이전트가 읽습니다.

IDE 가 달라도 규칙은 같습니다

플러그인은 웹 화면을 감싸지 않습니다. 웹이 쓰는 것과 같은 API 를 직접 부릅니다. VS Code 확장도, MCP 서버도 마찬가지입니다.

같은 계약을 공유하기 때문에 IDE 가 무엇이든 보는 상태가 갈라지지 않습니다. Eclipse 에서 이슈 상태를 옮기면 웹에서도 옮겨져 있고, 웹에서 단 코멘트가 Eclipse 편집기에도 나타납니다. 어느 쪽이 진짜인지 따질 필요가 없습니다.

이게 Execution Layer에서 말한 "상태·권한·실행이 같은 평면에 있어야 한다"의 실제 모습입니다. 평면이 하나면 표면은 늘려도 됩니다.

Git 도 같은 방식입니다. CollabOps 저장소는 표준 Git 이라 clone 한 다음부터는 Eclipse 에 기본으로 들어 있는 EGit 을 평소대로 쓰면 됩니다. 이미 EGit 을 쓰고 있다면 새로 배울 것이 없습니다.

되돌릴 수 없는 것은 한 단계를 더 거칩니다

변경요청 병합은 확인 대화상자를 한 번 거칩니다. 저장소를 지울 때는 저장소 이름을 한 번 더 입력해야 진행됩니다.

클릭을 줄이자고 만든 플러그인에 굳이 단계를 남겨 둔 이유는, 자동화의 총량이 늘어날수록 어디서 사람이 개입했는지가 기록으로 남아야 하기 때문입니다. 에이전트가 production 배포 권한을 가질 수 있는가에서 다룬 문제와 같습니다.

변경요청에 영구 삭제가 없는 것도 같은 이유입니다. CollabOps 에서 변경요청은 닫기로 끝냅니다.

아직 웹이 나은 것

줄 단위 리뷰 코멘트와 파이프라인 화면입니다. diff 를 나란히 놓고 특정 줄에 코멘트를 다는 일은 넓은 화면과 파일 트리가 있어야 하고, 파이프라인도 로그와 단계별 그래프를 함께 봐야 판단이 됩니다.

나머지는 IDE 안에서 끝납니다. 이슈를 골라 고치고, 코멘트를 달고, 변경요청을 만들고, 리뷰 브랜치를 받아 확인하고, 병합해서 올리는 것까지입니다.

다른 IDE는요?

VS Code 확장은 이미 나와 있고, JetBrains 와 Neovim 도 준비하고 있습니다.

설치에는 Mylyn 과 Java 21 이상이 필요합니다. Eclipse 는 2022-06 릴리스부터 Mylyn 을 기본 패키지에서 뺐으니 최근에 받았다면 따로 설치해야 합니다. 폐쇄망이라면 오프라인 설치용 압축 파일을 별도로 제공합니다. 설치와 화면별 사용법은 Eclipse 플러그인 문서에 단계별로 정리해 두었습니다.