에이전트 캔버스(Agent Canvases)는 채팅 전용 코딩 도구의 종말을 의미한다

GitHub는 이번 주 Copilot 앱에 UI 기능처럼 들리면서도 카테고리의 변화처럼 느껴지는 무언가를 추가했습니다.

캔버스(Canvases)입니다.

당연하게는 GitHub가 Copilot 앱을 더 좋게 만들고 있다는 해석이 가능합니다. 더 시각적으로, 더 데스크톱 앱처럼 만들고 있다는 것이죠. 좁은 채팅창에 타이핑을 하며 에이전트(Agent)가 과제를 제대로 이해하기를 바라는 방식에서 벗어나는 것입니다.

하지만 저는 그렇게만 보기에는 부족하다고 생각합니다.

흥미로운 점은 앱이 작업물을 보여줄 더 예쁜 공간을 갖게 되었다는 것이 아닙니다. 흥미로운 점은 에이전트의 작업이 대화 기록(Transcript)의 범위를 넘어서고 있다는 사실입니다. 에이전트가 계획을 세우고, 편집하고, 브라우징하고, 터미널을 실행하고, 풀 리퀘스트(Pull Request)를 생성하고, 리뷰 코멘트에 응답하며, 세션 전반에 걸쳐 작업을 지속할 수 있게 되면, 채팅은 매우 취약한 제어 인터페이스(Control Surface)가 됩니다.

채팅은 의도(Intent)를 전달하기에는 좋습니다.

하지만 상태(State)를 관리하기에는 좋지 않습니다.

채팅은 좋은 시작점이었습니다

채팅은 AI 코딩 도구를 위한 올바른 첫 번째 인터페이스였습니다.

익숙합니다. 관대합니다. 모호하게 말하다가 점차 구체적으로 바꿀 수 있습니다. 차이점(Diff)을 요청하기 전에 "어떻게 생각해?"라고 물어볼 수도 있습니다. 에러를 붙여넣고 모델이 스택 트레이스(Stack Trace)를 읽는 첫 번째 단계를 수행하게 할 수도 있습니다.

단순한 작업에는 그것으로 충분합니다.

"이 함수를 설명해줘."

"이 엣지 케이스(Edge Case)에 대한 테스트를 작성해줘."

"이 컴포넌트가 새로운 프롭(Prop)을 사용하도록 변경해줘."

채팅 기록(Chat Transcript)이 우아하지는 않지만, 작업이 작기 때문에 작동합니다. 인간이 목표, 컨텍스트(Context), 그리고 결과를 머릿속에 담아둘 수 있기 때문입니다.

장시간 실행되는 에이전트 작업은 다릅니다.

에이전트가 브랜치, 브라우저, 터미널, 체크리스트, 그리고 풀 리퀘스트를 넘나들며 30분을 보낸다면, 채팅 기록은 고고학 유물 더미가 되어버립니다. 그 어딘가에 계획이 있고, 또 다른 어딘가에 방향을 바꾼 이유가 있으며, 또 다른 어딘가에 테스트 실패 기록이 있고, 또 다른 어딘가에 최종 차이점(Diff)이 있습니다. 스크롤을 할 수도 있고, 검색을 할 수도 있습니다. 에이전트에게 스스로를 요약해달라고 요청할 수도 있는데, 이는 유용하면서도 동시에 약간은 황당한 일입니다.

그것은 진지한 검토 표면(review surface)이 아닙니다.

작업에는 객체(object)가 필요하다

GitHub의 변경 로그(changelog)는 캔버스(canvases)를 사람과 에이전트가 작업을 검토, 편집, 승인 및 재지시하는 양방향 작업 표면(bidirectional work surfaces)으로 설명합니다. 예시들은 시사하는 바가 큽니다: 계획(plans), 풀 리퀘스트(pull requests), 브라우저 세션(browser sessions), 터미널(terminals), 릴리스 체크리스트(release checklists), 마이그레이션 보드(migration boards), 인시던트(incidents), 대시보드(dashboards), 워크플로 상태(workflow state).

이 목록이 중요한 이유는 그것이 실제 문제를 지적하기 때문입니다.

에이전트 기반의 소프트웨어 작업은 텍스트만을 생성하지 않습니다. 그것은 객체(objects)를 생성합니다:

단계와 의존성(dependencies)을 포함한 계획(plan)
의도와 리스크를 포함한 디프(diff)
증거를 포함한 브라우저 세션(browser session)
명령과 실패를 포함한 터미널 실행(terminal run)
소유권(ownership)을 포함한 체크리스트(checklist)
리뷰 상태(review state)를 포함한 풀 리퀘스트(pull request)
진행 상황을 포함한 배포(deployment) 또는 마이그레이션(migration)

만약 이러한 객체들이 채팅창의 메시지로만 존재한다면, 인간은 결정을 내리고 싶을 때마다 매번 작업을 재구성해야 합니다.

그것은 주객전도입니다.

인터페이스는 객체를 직접 노출해야 합니다. 대화는 작업을 조종(steer)해야 하지만, 작업은 검토 가능한 어딘가에 존재해야 합니다.

이는 모든 엔지니어링 시스템이 결국 배우게 되는 것과 같은 교훈입니다. 이슈 트래커(Issue trackers)가 복도에서의 대화보다 나은 이유는 이슈가 지속 가능한 객체가 되기 때문입니다. 풀 리퀘스트(Pull requests)가 패치를 이메일로 보내는 것보다 나은 이유는 변경 사항이 검토 표면(review surface)을 갖기 때문입니다. CI 대시보드(CI dashboards)가 "내 컴퓨터에서는 됐는데요"라는 말보다 나은 이유는 결과가 실행(run)에 부착되기 때문입니다.

에이전트에게도 동일한 변화가 필요합니다.

에이전트 경험(agent experience)은 단순히 새로운 라벨을 붙인 개발자 경험(developer experience)이 아니다

GitHub는 이를 위해 "에이전트 경험(agent experience)"이라는 문구를 사용하고 있으며, 저는 이것이 예상보다 마음에 듭니다.

개발자 경험(Developer experience, DX)은 보통 인간이 도구(에디터, CLI, 문서, API, 테스트, 배포 워크플로, 관측성(observability))를 사용할 때 마찰을 줄여주는 것에 관한 것입니다. 좋은 DX는 인간이 문맥(context)을 놓치거나 실수로 잘못된 행동을 할 가능성을 낮춰줍니다.

에이전트 경험은 여기에 또 다른 참여자를 추가합니다.

이제 워크플로(workflow)는 인간이 사용할 수 있어야 하며, 에이전트(agent)가 읽을 수 있어야 합니다. 에이전트는 읽을 수 있는 구조화된 상태(structured state)가 필요합니다. 인간은 신뢰할 수 있는 가시적인 상태(visible state)가 필요합니다. 앱은 허용되는 작업이 무엇인지 강제해야 합니다. 시스템은 미래의 검토자가 채팅 로그를 유일한 진실의 원천(source of truth)으로 취급하지 않고도 무슨 일이 일어났는지 이해할 수 있도록 충분한 이력(history)을 기억해야 합니다.

이것은 단순히 외관상의 문제가 아닙니다.

이는 우리가 내부 엔지니어링 워크플로를 설계해야 하는 방식을 변화시킵니다.

만약 마이그레이션 보드(migration board)가 에이전트가 조작 가능하려면, 그 보드는 주석에 암묵적인 규칙(tribal rules)이 적힌 모호한 스프레드시트여서는 안 됩니다. 만약 릴리스 체크리스트(release checklist)가 에이전트가 조작 가능하려면, 체크리스트는 명확한 상태, 담당자, 증거, 그리고 중단 조건(stop conditions)을 갖추어야 합니다. 만약 풀 리퀘스트(pull request, PR)가 에이전트가 조작 가능하려면, 에이전트는 어떤 리뷰 코멘트가 지시 사항인지, 어떤 것이 토론인지, 그리고 계속 진행하기 전에 어떤 것에 인간의 판단이 필요한지를 알아야 합니다.

UI는 단지 눈에 보이는 부분일 뿐입니다.

더 깊은 작업은 엔지니어링 프로세스를 인간과 기계 모두가 추측 없이 참여할 수 있을 만큼 충분히 구조화하는 것입니다.

기록(transcripts)은 너무 많은 것을 숨긴다

기록(transcript)에는 한 가지 큰 장점이 있습니다. 바로 대화를 보존한다는 점입니다.

하지만 그것이 바로 문제입니다.

대화는 무질서합니다. 대화에는 잘못된 시작, 수정, 미완성된 아이디어, 농담, 명확화 과정, 그리고 두 참여자가 5분 전에 무슨 일이 있었는지 기억하기 때문에 비로소 의미를 갖게 되는 결정들이 포함됩니다. 인간은 그 순간에는 이를 꽤 잘 해냅니다. 하지만 나중에는 더 못합니다. 에이전트는 훨씬 더 위험할 수 있는데, 무질서한 이력을 실제 작업보다 더 깔끔하게 들리는 자신감 넘치는 요약본으로 바꿔버릴 수 있기 때문입니다.

에이전트 기반 코딩(agentic coding)을 위해, 나는 최종 상태가 기록(transcript)에서 느껴지는 분위기(vibes)에 의존하는 것을 원치 않습니다.

나는 계획(plan)이 현재 상태를 보여주기를 원합니다.

나는 차이점(diff)이 무엇이 왜 변했는지를 보여주기를 원합니다.

나는 터미널(terminal) 화면이 어떤 명령어가 실행되었고 어떤 것이 실패했는지를 보여주기를 원합니다.

나는 브라우저(browser) 화면이 무엇이 검증되었는지를 보여주기를 원합니다.

나는 PR 화면이 무엇이 미결 상태로 남아있는지를 보여주기를 원합니다.

채팅은 조종(steering)을 위해 유용하게 남을 수 있습니다. 하지만 검토(review)에는 그것을 만들어낸 대화 속에 파묻히는 것이 아니라, 작업 객체(work object)에 부착된 증거가 필요합니다.

에이전트(agent)가 발전할수록 이 점은 더욱 중요해집니다. 성능이 나쁜 에이전트는 불신하기 쉽습니다. 하지만 성능이 좋은 에이전트는 다듬어지고 그럴듯한 결과물을 만들어냅니다. 인터페이스는 문장이 자신만만하게 들릴 때조차 불확실성을 가시화할 수 있어야 합니다.

내가 살펴볼 것들

만약 내가 팀을 위해 에이전트 코딩 도구를 평가한다면, 채팅이 마법처럼 느껴지는지 묻는 데 시간을 덜 쓰고 작업 표면(work surfaces)을 살펴보는 데 더 많은 시간을 쓸 것입니다.

에이전트에게 요약을 요청하지 않고도 현재 계획(plan)을 검사할 수 있는가?

계획을 직접 수정할 수 있는가?

어떤 파일이 범위(scope) 내에 있고 어떤 파일이 범위 외에 있는지 볼 수 있는가?

어떤 명령어가 실행되었고 어떤 환경(environment)에서 실행되었는지 알 수 있는가?

에이전트가 왜 방향을 전환했는지 알 수 있는가?

최종 풀 리퀘스트(pull request)가 검토를 위한 충분한 증거를 보존할 수 있는가?

이 질문들은 가장 좋은 의미에서 지루한 질문들입니다. 이 질문들은 AI 코딩 도구가 프로덕션 도구(production tool)가 되고 있는지, 아니면 데모 인터페이스(demo interface)에 머물러 있는지를 보여주는 질문들이기 때문입니다.

마법 같은 텍스트 박스만으로는 충분하지 않습니다.

한 번도 충분했던 적은 없었습니다.

그것은 단지 우리가 시작할 수 있게 해줄 정도였을 뿐입니다.

핵심 요점

에이전트 캔버스(Agent canvases)가 흥미로운 이유는 업계가 한동안 주변을 맴돌던 사실을 인정하기 때문입니다. 즉, 채팅은 소프트웨어 에이전트(software agents)를 위한 최종 인터페이스가 아니라는 점입니다.

채팅은 의도(intent)를 표현하기에는 좋은 장소입니다. 하지만 지속 가능하고, 검사 가능하며, 검토 가능한 작업을 관리하기에는 형편없는 장소입니다.

소프트웨어 엔지니어링에는 이미 진지한 협업을 위한 객체들이 존재합니다: 이슈(issues), 브랜치(branches), 풀 리퀘스트(pull requests), CI 실행(CI runs), 대시보드(dashboards), 인시던트(incidents), 릴리스 계획(release plans), 그리고 배포 기록(deployment records)입니다. 에이전트가 등장한다고 해서 이러한 객체들의 필요성이 사라지는 것은 아닙니다. 오히려 인간의 결정 사이에 더 많은 작업이 일어날 수 있게 되면서, 이 객체들은 더욱 중요해집니다.

그러므로 그렇습니다, Copilot 앱에 캔버스가 추가되는 것은 제품 업데이트입니다.

하지만 더 깊은 신호는 아키텍처(architectural)적인 것입니다.

에이전트(Agent) 작업에는 대화 기록(transcript) 이외의 상태(state)가 필요합니다. 인간이 검토하고 방향을 재설정할 수 있는 표면(surfaces), 에이전트가 구조화된 의도(structured intent)를 읽고 업데이트할 수 있는 곳, 그리고 시스템이 경계(boundaries)를 강제할 수 있는 곳이 필요합니다.

코딩 도구의 미래는 모두가 더 열심히 채팅을 하는 것이 아닙니다.

대화(conversation), 상태(state), 증거(evidence), 그리고 검토(review)가 마침내 한 곳에 공존하는 작업대(workbenches)입니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하기 위한 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.