커서가 워크트리와 베스트오브N을 굴리던 코드 약 1만 5천 줄을 지우고 그 자리를 마크다운 지시로 채운 이야기. 베스트오브N은 코드 4천 줄에서 마크다운 마흔 줄이 됐고, 멀티레포와 대화 도중 전환처럼 예전에 안 되던 것이 따라 열렸다. 대신 작업 공간 밖으로 새는 것을 코드가 물리적으로 막던 자리가 프롬프트의 부탁으로 바뀌어, 긴 세션과 작은 모델에서 이탈이 난다. 그것을 재려고 스코어러 둘짜리 평가를 처음 짰다는 대목까지 나온다. 성능·비용 수치는 없다.
한줄 코멘트. 코드 1만 5천 줄이 사라졌다는 것이 눈에 걸리는데, 실제로 옮겨 간 것은 줄 수가 아니라 막는 방식이다. 예전에는 에이전트가 정해진 작업 공간 밖 파일을 건드리는 일 자체가 불가능했고, 지금은 나가지 말라고 프롬프트로 못 박아 두고 지키기를 기다린다. 발표자도 이 대목을 「감에 기댄다」고 말한다. 그래서 이 이야기는 코드를 지운 이야기가 아니라, 지키는 일을 코드에서 모델로 넘긴 뒤 그것을 무엇으로 확인할지 다시 짓는 이야기다.
커서에서 마크다운이 새 코드가 됐다는 이야기를 하겠다고 발표를 연다. 대상은 두 기능이다.
하나가 *워크트리다. 같은 저장소를 여러 벌 받아 놓은 것처럼 갈라 두는 깃 기능이라, 에이전트 여럿이 같은 과제든 다른 과제든 서로 방해하지 않고 동시에 일할 수 있다. 커서에서는 워크트리마다 에이전트를 띄웠고 같은 파일이 워크트리마다 다르게 보였다. 에이전트가 돌리는 명령이나 린트도 그 워크트리 안에 갇혔다. 화면에는 에이전트가 격자로 늘어서 각자 일했고, PR을 열라고 하면 그 워크트리에서 만든 변경으로 열렸다.
다른 하나가 베스트오브N이다. 같은 과제를 여러 모델에 한꺼번에 주고 결과를 견주는 기능이다. 프런트엔드라면 서로 다른 화면 구현을 미리 보고 마음에 드는 것을 고른다. 커서에서 부르는 이름은 「베스트 오브 10」이고, 작년 10월 커서 2.0과 함께 나왔다.
발표자는 최근 이 기능을 통째로 걷어내는 PR을 열었고 코드 1만 5천 줄쯤이 지워졌다고 말한다. 새 구현은 예전 것만큼은 아니어도 거의 그만큼 하면서 유지하기는 훨씬 가볍다고 한다.
지운 것이 무엇이었는지를 발표자가 늘어놓는다.
워크트리를 만들고 관리하고 에이전트에 맥락으로 넣어 주는 코드를 다 짜야 했다. 에이전트가 자기 워크트리를 벗어나지 못하도록 가두는 일도 코드가 했다. 사용자가 정해 둔 셋업 스크립트를 에이전트가 그 워크트리에서 일을 시작할 때마다 돌렸다. 어느 구현이 나아 보이는지 엄지 아이콘으로 알려 주는 판정도 따로 돌렸다. 하네스를 고치고 시스템 리마인더를 넣어 에이전트가 자리를 지키게 도왔다. 사람들이 워크트리를 수백 개씩 만들어 디스크가 불어나니 남은 것을 치워 주는 일까지 했다.
마흔 줄이 시키는 차례
발표자가 고른 부품은 둘이다. 에이전트 *스킬과 *서브에이전트다. 이 둘을 겹치면 워크트리 기능도 베스트오브N도 마크다운만으로 다시 만들 수 있다는 것이 판단이었다.
워크트리 쪽 지시는 이렇다. 워크트리를 어떻게 만드는지 알려 주고, 사용자가 정해 둔 셋업 스크립트를 워크트리마다 돌리게 하고, 그 체크아웃에 머무르라고 시킨다.
베스트오브N 쪽은 더 짧아서 작은 글씨로 화면 하나에 다 들어간다. 마크다운 마흔 줄이고, 예전 구현은 코드 4천 줄쯤이었다고 말한다.
지시에 든 조건도 댄다. 윈도우용 지시와 리눅스·맥OS용 지시를 다 담아 어느 판에서나 돌아야 한다. 가장 어려운 대목은 워크트리를 벗어나지 말라고 시키는 자리라, 절대 밖에서 일하지 말라고 세게 적는다고 한다.
새 명령은 /worktree, 베스트오브N을 부르는 명령, 워크트리를 적용하는 명령과 지우는 명령이다. 커서에서 이것들은 사실 스킬이 아니라 커맨드인데, 사용자가 고를 때만 프롬프트가 맥락에 실린다는 점이 스킬과 같다. 커맨드로 만든 이유는 하나다. 프롬프트를 자기네 서버에서 쥐고 있으면 사용자가 커서를 새로 받지 않아도 고친 프롬프트가 바로 간다.
데모는 영상이다. 키미·그록·컴포저·GPT·오퍼스에 같은 과제를 주자 부모가 서브에이전트 다섯을 띄우고 저마다 워크트리와 맥락을 쥔다. 오퍼스가 예상대로 오래 걸리고, 다 끝나면 부모가 지시받은 대로 결과를 견준다.
갈아치운 뒤 달라진 것
| 방향 | 무엇 |
|---|---|
| 좋아짐 | 유지할 코드가 훨씬 줄었다. 워크트리는 커서 사용자 90%가 쓰는 기능이 아니라 파워 유저용이다 |
| 좋아짐 | 대화 도중에 워크트리로 옮겨 갈 수 있다. 예전에는 안 됐다 |
| 좋아짐 | 저장소를 여럿 놓고 일할 때도 된다. 저장소마다 워크트리를 만들고 PR도 저장소마다 하나씩 연다 |
| 좋아짐 | 판정이 나아졌다. 부모가 서브에이전트들의 작업을 더 많이 알고 있어, 이 구현의 이 조각과 저 구현의 저 조각을 이어 달라고 시킬 수 있다. 예전에는 하나를 골라야 했다 |
| 나빠짐 | 에이전트가 자리를 지키기 어렵다. 예전에는 워크트리 밖 파일을 건드리는 것이 물리적으로 불가능했고 지금은 모델을 믿는다. 긴 세션에서 어디서 일해야 하는지 잊고, 떨어지는 모델일수록 엉뚱한 짓을 한다 |
| 나빠짐 | 느리게 느껴진다. 워크트리를 만드는 과정이 대화창에 그대로 보인다. 실제로 느린 것은 아니라고 말한다 |
| 나빠짐 | 찾기 어렵다. 예전에는 로컬·클라우드·워크트리를 고르는 드롭다운이 있었는데 이제 슬래시 명령을 알아야 한다. 파워 유저 기능이라 눈에 덜 띄는 쪽은 감수한다고 말한다 |
전부 발표자가 스스로 든 것이고 잰 값은 아니다. 포럼에서 반응이 갈리고 있다는 것도 밝힌다. 예전 방식에 익숙하던 사람들이 있다는 것이다.
지키는지를 무엇으로 재나
발표자는 이 기능을 두고 평가를 짜 봤고 그것이 사실상 처음이라고 말한다. 커서 CLI를 화면 없이 띄워 돌리고 채점하는 눈을 둘 뒀다. 하나는 모델이 자기 워크트리에서 할 일을 했는지 보고, 다른 하나는 그 반대로 건드리지 말아야 할 원본 체크아웃에서 뭔가 했는지 본다.
지금 평가가 단순해서 모델이 흐트러지기 시작하는 아주 긴 세션은 아직 흉내 내지 못했다고 말한다.
모델마다 다르다는 것은 나왔다. 하이쿠는 작고 덜 똑똑한 모델이라 원본 체크아웃으로 자주 새고, 컴포저와 그록은 훨씬 낫다고 한다. 몇 번 중 몇 번인지는 대지 않는다.
고치는 길로 둘을 든다. 평가를 늘려 프롬프트를 고치는 쪽과, 강화학습으로 자기네 모델을 고치는 쪽이다. 컴포저 2에는 이런 상황을 다루는 강화학습 과제가 아예 없었고, 컴포저 3이나 4, 5를 낼 때쯤에는 적어도 자기네 모델이 이 일을 훨씬 잘하도록 과제를 파이프라인에 넣는 중이라고 말한다. 남의 회사 모델은 자기가 고칠 수 없으니 다른 연구소와 모델 제공사에 겪은 것을 전해 왔다고 한다.
다음 단계도 밝힌다. 최근 알린 커서 3.0의 새 에이전트 창에 더 온전한 워크트리 구현을 넣을 계획이다. 로컬에서 여럿을 한꺼번에 돌리는 사람과 그 화면을 쓸 사람이 대체로 같은 사람이라는 것이 이유다.
깃 워크트리가 아닌 다른 병렬화 수단도 보고 있다고 말한다. 워크트리는 만드는 데 느리고 디스크를 많이 쓰며 깃 저장소에서만 돈다. 깃을 안 쓰는 사용자에게는 커서에 로컬 병렬화 수단이 아예 없다는 것이다.
성능·비용·지연 수치가 없다. 나온 숫자는 지운 줄 수와 스킬 줄 수, 사용자 비율 하나뿐이다. 새 구현이 예전 것만큼 「거의」 좋다는 말도 무엇으로 잰 것인지 대지 않는다.
평가 결과도 수치가 없다. 하이쿠가 「자주」 새고 컴포저와 그록이 「훨씬」 낫다는 데서 멈춘다. 스코어러 둘을 짜 놓고도 그 눈으로 본 값이 발표에 나오지 않는다.
유지 부담이 얼마나 줄었는지도 코드 줄 수 말고는 없다. 지우기 전과 뒤에 이 기능에 든 손이 얼마나 달라졌는지, 프롬프트를 서버에서 고치는 일이 대신 얼마나 늘었는지는 다루지 않는다.
가장 큰 구멍은 이탈이 났을 때다. 모델이 원본 체크아웃에서 일해 버리면 그 변경이 어떻게 되는지, 되돌릴 길이 있는지, 사용자가 알아채는 자리가 있는지를 발표가 설명하지 않는다. 예전 구현에서는 일어날 수 없던 일이라 예전에는 물을 필요가 없던 물음이다.
데모는 라이브가 아니라 영상이었다. 포럼 반응이 갈린다는 것도 말로만 있고, 어느 쪽이 얼마나인지는 나오지 않는다.
용어