GitHub 캔버스가 던지는 물음: AI 에이전트 시대에 '보이는 일'이 왜 중요할까

한 가지 관찰부터 시작하겠습니다

오늘 GitHub 블로그의 한 글을 읽으면서 흥미로운 대목을 발견했습니다. 저자가 “AI 인라인 완성(inline completion)”이 게임 체인저라고 느꼈던 시절이 이미 과거가 되었다는 점입니다. 그리고 지금 우리는 “에이전트와 인간이 함께 일하는 하이브리드 팀(hybrid teams where agents and humans work in tandem)” 시대에 들어섰다는 관찰이 있습니다.

35년간 기술 교육 현장에서 일하면서 저는 이런 전환점들을 여러 번 목격했습니다. 새로운 도구가 나올 때마다 처음엔 “혁신이다”라고 느끼지만, 실제로 운영 규모가 커지면 “보이지 않는 것들”이 문제가 되곤 합니다. 원문을 살펴보니 GitHub도 지금 그 지점에서 손을 내밀고 있는 것 같습니다.

채팅은 의도 전달에는 좋지만, 실행 기록에는 약하다

원문에서 명확하게 나오는 대목입니다: “Chat is great for intent, but weak for durable execution(채팅은 의도 전달에는 훌륭하지만 지속 가능한 실행에는 약하다).”

지난 몇 년간 n8n 자동화 인프라를 직접 구축하며 느낀 점도 이와 맞닿아 있습니다. 초반엔 에이전트나 AI 도구와 채팅으로 대화하는 것이 충분해 보입니다. “이거 해줘”, “다시 해봐”, “이 부분 수정해” 이런 식의 상호작용이 자연스럽고 빠릅니다.

하지만 작업 규모가 조금만 커지면 문제가 터집니다. 원문이 지적하는 대로입니다: “Context gets lost across threads and surfaces(맥락이 여러 채널과 표면에서 흩어진다).” 무엇이 계획이었는지, 어디서 결정이 났는지, 뭐가 검증됐는지, 무엇이 아직 인간의 판단을 기다리는지—이 모든 게 긴 채팅 스크롤 속에 묻힙니다.

에이전트가 생성하는 변경 사항(changes)이 인간이 검토할 수 있는 속도를 앞지르게 되면(“Agents can produce changes faster than any human can review them”), 상황은 더 복잡해집니다. 당신은 이제 “뭐가 돌았는지, 뭐가 바뀌었는지, 뭐가 승인됐는지, 뭐가 남았는지” 추적할 수 없는 지경에 빠집니다.

캔버스가 던지는 제안: 일을 ‘보여줄 수 있는 곳’

GitHub이 내놓은 답이 캔버스(canvases)입니다. 이건 단순한 UI 개선이 아니라 워크플로우의 철학을 바꾸는 제안처럼 읽힙니다.

원문의 핵심: “Canvases let developers and agents interact on a durable, shared surface(캔버스는 개발자와 에이전트가 견고하고 공유된 표면에서 상호작용하게 한다).” 그리고 “Instead of treating chat as the only place where work happens, canvases make work visible, steerable, and approvable as it unfolds(채팅을 일이 일어나는 유일한 장소로 취급하는 대신, 캔버스는 진행 중인 일을 볼 수 있고 조종할 수 있고 승인 가능하게 만든다).”

저는 이 부분을 읽으면서 “상태를 명시적이고 지속 가능하게 만든다(make state explicit and persistent)”는 표현에 멈췄습니다. 이건 단순히 “기록을 남긴다”는 뜻이 아닙니다. 채팅도 기록이 남으니까요. 진짜 의미는 “지금 뭐가 진행 중인지, 다음 단계가 뭔지, 누가 결정을 내려야 하는지”를 한눈에 볼 수 있는 구조를 만드는 것입니다.

시니어 자동화 운영자 입장에서 바라보면

나 같은 입장—한 명 또는 소수 팀이 수십, 수백 개의 자동화 워크플로우를 돌리는 사람들—에게 이 관찰은 타이밍 있게 들립니다.

n8n으로 복잡한 워크플로우를 짤 때도 이미 이 문제를 만나고 있거든요. 노드가 20개, 30개가 넘어가면 “이 조건에서 뭐가 실행되고, 여기서 뭐가 실패하고, 그 다음엔 어디로 가는가”를 추적하기가 힘들어집니다. 로그는 있지만, 로그는 사후 분석용이지 실시간 조종용이 아닙니다.

GitHub이 제시하는 건 “보이는 일(visible work)”의 중요성입니다. 비용 효율성도 결국 여기서 나온다고 봅니다. 원문의 제목에 “cost-efficient”가 있는 이유도 그겁니다. 왜냐하면 불필요한 재검토, 불명확한 상태 때문의 재실행, 누가 뭘 승인했는지 몰라서 반복하는 작업—이 모든 게 비용(시간, 리소스)을 먹어치우기 때문입니다.

다만 남은 물음들

원문을 읽고 난 후 몇 가지가 아직 명확하지 않습니다. 예를 들어, “캔버스가 정말 팀 협업 상황에서 chat 대체제가 될 수 있는가”라는 질문이 있습니다. 사람마다 work style이 다르고, 어떤 사람은 여전히 빠른 채팅 상호작용을 선호할 텐데, 캔버스의 “견고함(durable)”이 오히려 버거울 수도 있습니다. 이건 단순히 GitHub이 풀 수 있는 문제가 아니라, 팀 문화와 프로세스 설계 차원의 문제입니다.

또한 “에이전트가 정말 이렇게 orchestration되도록 설계될 수 있을까”라는 의문도 있습니다. 현재의 LLM 기반 에이전트들이 캔버스처럼 “계획을 세우고 단계별로 진행하고 의사결정 포인트를 명확히 표시하도록” 훈련되고 있는가—이 부분은 아직 진행 중인 논쟁입니다. 에이전트 오케스트레이션(multi-agent orchestration) 자체가 아직 미성숙한 분야거든요.

끝내며

오늘 이 글을 살펴보니, GitHub이 “보이는 일”이 왜 중요한지를 강하게 주장하고 있다는 점이 분명합니다. 채팅 시대가 끝나는 건 아니겠지만, 실제 워크플로우 운영 층면에서는 “누가, 언제, 뭘, 왜, 어떻게 했는가”를 추적할 수 있는 구조가 이제 선택 아닌 필수가 되어가는 것 같습니다.

다만 “이런 가시성 제공이 정말 비용을 줄일까, 아니면 오버헤드를 늘릴까”라는 효율성 논쟁이 있는데, 이 부분은 계속 지켜봐야 할 지점입니다.

이 이슈가 실제로 개발팀과 자동화 운영팀에서 어떻게 받아들여지고, 캔버스 같은 도구가 정말 chat 문화를 바꿀 수 있을지는 다음 편에서 계속 살펴보겠습니다.