Chopin은 팀과 에이전트가 함께 계획을 세우는 도구다

오늘날 에이전트는 아직 프로덕션 수준의 코드를 완벽하게 작성하지는 못하지만, 상당히 가까워지고 있다. 최첨단 모델과 철저한 사전 계획, 충분한 테스트와 검증을 갖춘 일부 시니어 개발자는 텍스트 편집기를 내려놓고 코드 변경 사항을 꼼꼼히 읽는 일도 멈췄다.

이제 문법과 변수 이름, for문 작성법은 크게 신경 쓰지 않아도 된다. 에이전트가 이런 단순한 결정을 빠르게 내릴 수 있기 때문이다. 그 결과 구현에 쓰는 시간은 줄어들고, 코드 작성 전후에 이뤄지는 계획과 검토가 중요한 일이 됐다. 이 두 과정은 아직 해결되지 않은 문제다.

코딩 에이전트가 등장하기 전에는 개발 시간 대부분을 구현에 썼다. 도식은 페이지를 스크롤할수록 구현 영역이 줄어들고 계획과 검토 영역이 커지는 모습으로, 에이전트 등장 전후 소프트웨어 개발의 변화를 표현한다. 도식에는 ‘에이전트 이전의 소프트웨어 개발’, ‘에이전트 이후의 소프트웨어 개발’, ‘계획’, ‘구현’, ‘검토’, ‘시간’이라는 표기가 있다.

계획은 나머지 모든 일이 그에 따라 진행되므로 특히 중요하다. 기능의 성공과 실패를 가르는 요소이며, 숙련된 개발자가 계획을 이끌 때 큰 차이가 난다. 검증 기준이 분명하지 않은 대략적인 기능 아이디어를 코딩 에이전트에 넘기면, 허술하게 만들어진 결과물이 나올 수 있다.

오늘날 AI 에이전트에는 이미 널리 쓰이는 ‘계획 모드’가 있다. 이는 2025년 6월 Claude Code 변경 기록에서 큰 인기를 끈 초기 기능 중 하나였다. 다만 Claude가 이를 처음 만든 것은 아니다. 행동에 나서기 전에 생각하고 계획하게 해 에이전트의 결과를 개선하는 접근은 2022년 ReAct 논문에서 먼저 제안됐고, Cline 같은 덜 알려진 에이전트 하네스에도 구현됐다.

계획 모드를 매트 포콕(Matt Pocock)의 유명한 grill-me 같은 스킬과 함께 사용하면, 만들려는 것이 무엇인지 에이전트가 빠짐없이 질문하도록 해 본격적인 구축에 앞서 작업을 깊이 이해하고 가능한 방향을 살펴볼 수 있다. 사람과 에이전트가 문제 영역을 논의하고 분명한 해법을 함께 정하는 방식이다. 원문은 OpenCode, GitHub Copilot, Codex의 계획 화면을 예로 들었다.

계획은 개발 과정에서 여러 역할을 한다. 코딩 에이전트에 구현을 맡길 수 있는 산출물인 동시에, 검토 단계에서 결과를 대조할 최초 의도의 기록이 된다. 계획을 세우는 방식 자체는 에이전트 이전 시대와 크게 다르지 않다. 개발자와 제품 관리자, 디자이너를 비롯한 이해관계자는 엔지니어링 팀의 작업을 안내하기 위해 설계 사양서, PRD, RFC 등 여러 문서를 작성하는 데 많은 시간과 노력을 들였다. 달라진 점은 이제 구현 과정에 사람이 관여하지 않는다는 것이다. 작업이 시작된 뒤 결정을 조정하거나 방향을 바꿀 수 없으므로, 사전에 충분히 계획하는 일이 더 중요해졌다.

기존 계획 도구의 한계

기존 도구에는 여러 한계가 있지만, 특히 상호작용, 팀 협업, 결정의 책임 소재, 시각적 설명이라는 네 가지 문제가 두드러진다.

터미널에서 CLI 도구를 쓰면 계획은 대개 수정할 수 없는 정적인 텍스트 덩어리다. Markdown을 인라인으로 표시하더라도 평평하고 꾸밈이 없어 읽기 어렵다. 데스크톱 앱의 GUI는 Markdown 서식을 갖춘 더 풍부한 화면을 제공하지만, 계획을 직접 수정할 수 없는 경우가 있다. 일부 인터페이스에서는 미리보기 안에 계획 일부가 가려져 전체를 읽기 어렵고, 대부분 계획을 수락하거나 거부하는 두 가지 선택지만 제공한다. 원문은 OpenCode CLI의 수정할 수 없는 최종 계획과 Codex의 최종 계획 확인 화면을 예로 든다.

이런 방식으로는 계획의 세부 내용을 함께 검토하고 무엇에 동의하는지 파악하기 어렵다. 3,000단어에 이르는 긴 계획을 조금씩 수정하고 반복해서 다듬기도 쉽지 않다. 현재 도구 대부분에서는 특정 부분을 가리켜 더 자세히 설명해 달라고 하거나, 제안을 삭제해 달라고 하거나, 해당 접근을 권하는 이유를 묻기가 어렵다. 대신 복잡한 논점과 서로 다른 생각을 기억해 둔 채 계획을 읽고, 모든 피드백을 채팅창 하나에 입력한 다음 에이전트가 빠짐없이 반영하기를 기대해야 한다.

질문을 주고받는 과정에서 37개 질문에 답하더라도 그 결정이 최종 계획에 모두 반영된다는 보장은 없다. 이는 가능한 방식에 비해 원시적인 인터페이스다. 에이전트와 계획을 ‘작성’하는 과정은 상호작용하며 함께 쓰는 경험이라기보다, 완성된 계획이 갑자기 나타나는 것처럼 느껴질 수 있다. 사람이 계획의 중요한 결정을 모두 이해하고 소화하며 그 과정에 참여했다고 느끼려면 무엇이 필요할까?

예를 들어 계획의 질문이나 불확실한 세부 사항마다 별도의 대화 스레드를 둘 수 있다. 어떤 스레드에서는 추가 조사를 요청하고, 다른 스레드에서는 동료와 논의하며, 또 다른 스레드에서는 여러 설계 방향을 시험해 볼 수 있다. 계획은 막다른 문서가 아니라 다양한 토론과 탐색으로 이어지는 분기점이어야 한다.

두 번째 문제는 팀 협업의 부족이다. 현재 시장의 도구는 모두 혼자 쓰는 경험을 중심으로 설계됐다. 필요한 사람들과 떨어진 채 작은 터미널이나 데스크톱 앱에서 홀로 계획을 세운다. 하지만 소프트웨어 개발은 혼자 하는 게임이 아니라 협업을 통한 문제 해결 활동이다. 좋은 소프트웨어를 만들려면 회사 리더, 제품 관리자, 디자이너, 엔지니어, 연구자 등 서로 다른 역량을 지닌 사람이 필요하다. 다양한 기술과 관점이 있어야 개인이 옳다고 생각하는 해법에 그치지 않고 문제에 맞는 해법을 찾을 수 있다. 어떤 개발자도 특정 문제나 제품에 필요한 맥락과 지식을 모두 갖고 있지는 않다.

팀 전체가 실시간으로, 또는 원하는 경우 비동기 방식으로, 마찰 없이 계획을 작성하고 유용한 에이전트도 바로 활용할 수 있어야 한다.

세 번째 문제는 계획에 담긴 각 결정을 누가 내렸고 어떤 과정을 거쳤는지 알기 어렵다는 점이다. 계획의 결정을 에이전트가 내렸는가, 사람이 내렸는가? 에이전트에 넘기기 전에 누군가 계획을 논의했는가? 디자인 팀이 검토했는가? 왜 B가 아니라 A를 선택했는가?

현재는 최종 계획이 어떻게 만들어졌는지 확인할 방법이 없다. 누가 무엇을 결정했는지 보여 주는 감사 기록이나 로그가 없다. 기능 계획 단계에서 이뤄지는 중요한 사전 검토가 개인 세션의 일시적인 채팅 기록에 묻히고, 핵심 결정으로 이어진 대화를 추적하기 어렵다. 사람과 논의하지 않은 채 에이전트가 조용히 결정했는데도 사람이 알아차리지 못했다는 사실을 드러내기도 어렵다.

중요한 소프트웨어를 만들려면 결정의 감사 기록과 책임 주체를 명확히 해야 한다. 이는 누군가를 탓하기 위해서가 아니다. 팀원이 결정의 맥락을 파악해 언제 의문을 제기할지, 누군가 이미 충분히 검토한 결정을 언제 받아들일지 판단하도록 돕기 위해서다.

네 번째 문제는 시각적 설명의 부족이다. 현재 계획은 모두 텍스트가 많고, 에이전트가 만드는 결과물도 대체로 그렇다. 에이전트는 텍스트를 좋아하며 사람이 읽고 이해할 수 있는 속도보다 훨씬 빠르게 초당 수천 단어를 쏟아낸다.

사람이 조용히 읽는 평균 속도는 분당 238단어다. 최첨단 모델은 초당 약 50~150토큰을 생성하며, 이는 분당 평균 4,500토큰(단어)에 해당한다. 사람이 읽는 속도와 에이전트가 쓰는 속도의 비율은 1 대 15다. 여기에 최첨단 모델이 지나치게 장황하고 간결하게 핵심을 말하기보다 복잡한 상투어를 쓴다는 점도 도움이 되지 않는다.

텍스트만으로는 이해하기 어려운 내용이 있으므로 순수한 텍스트에서 벗어나야 한다. 특히 복잡한 개념, 얽힌 관계, 시간에 따른 사건, 프로그래밍에서 볼 수 있는 아키텍처 시스템을 이해할 때는 텍스트가 항상 이상적인 매체는 아니다.

사람은 시각 피질과 공간 추론 체계가 발달해 도표와 시각적 설명을 더 쉽게 이해한다. 이 능력은 글보다 5억 년 이상, 구어보다 2억 년 앞서 나타났다(시각 피질의 초기 진화에 관한 연구, 구어의 진화에 관한 연구). 이미지는 많은 정보를 한꺼번에 처리해 패턴과 관계, 대상을 병렬적으로 볼 수 있다. 텍스트를 이해하는 과정은 순차적이므로 더 느리다.

프로그래밍에는 팀이 복잡한 시스템을 생각하고 계획하며 소통하도록 돕는 도표와 지도, 시각 자료를 활용해 온 역사가 있다. 데이터 흐름도, 상태 머신, UML, 아키텍처 지도 같은 시각 자료는 같은 내용을 글로만 표현하는 것보다 개발자가 정보를 더 효과적으로 이해하게 돕는다. 에이전트가 각 계획 안에 맞춤형 대화형 시각 자료를 만들어 텍스트 과부하에서 벗어나도록 하는 데는 아직 충분히 탐구되지 않은 가능성이 크다고 본다. 원문은 데이터 흐름도, UML 클래스 다이어그램, 멀티플레이어 아키텍처 다이어그램을 예로 든다.

Chopin 소개

Chopin은 에이전트와 함께하는 협업 계획을 개선하는 방법을 탐색하는 프로젝트다. 여기서 ‘협업’은 에이전트 무리와 함께한다는 뜻이 아니라 실제 사람들과 협력한다는 뜻이다. 다만 Chopin에도 에이전트 무리가 참여할 예정이다.

Chopin은 실시간 멀티플레이어 계획 환경이다. 동료와 에이전트가 함께 아름다운 MDX 기반 편집기에서 계획을 작성할 수 있다. MDX는 문서에 대화형 React 구성 요소를 넣을 수 있도록 Markdown을 확장한 형식이다. 계획은 GitHub 저장소를 중심으로 구성되며, 해당 저장소에 접근할 수 있는 사람과 공유된다.

계획 바깥의 아이디어를 논의할 수 있는 작은 채팅방도 제공한다. 에이전트도 채팅에 참여한다. 에이전트에게 편집, 댓글 반영, 조사 등을 요청할 수 있다. 원문에는 Chopin에서 계획을 실시간으로 함께 작성하는 모습과, 문서 어디에나 댓글 스레드를 추가하고 에이전트가 이를 해결하도록 계획을 업데이트하는 모습을 보여 주는 영상이 포함돼 있다.

현재는 다듬어지지 않았지만, 특정 질문이나 주제를 에이전트에게 조사하도록 요청하고 그 보고서를 계획 안에 삽입하는 조사 블록 유형도 만들었다.

Chopin에 지금까지 구현한 주요 기능은 다음과 같다.

• 탭, 차트, 다이어그램, 수식 등을 넣을 수 있는 시각적 구성 요소를 갖춘 위지윅(WYSIWYG) 편집기
• 사용자 접속 상태와 실시간 업데이트를 포함한 실시간 멀티플레이어 협업
• 계획을 편집하는 에이전트가 다른 사용자처럼 행동하는 자연스러운 AI 에이전트 참여
• 스레드를 만들고 에이전트의 작업 방향을 이끌 수 있는 댓글 시스템
• 지속적으로 보존되는 결정 기록. 댓글 스레드의 결과와 에이전트가 던진 질문에 대한 답변을 계획의 해당 부분에 연결하며, 계획이 바뀌어도 최신 상태를 유지한다.
• 어떤 에이전트든 Chopin과 함께 쓸 수 있게 하는 MCP 서버. 에이전트와 먼저 대화한 뒤 계획을 Chopin에 넘겨 팀원과 작업하고, 구현 단계에서는 원하는 에이전트로 돌아갈 수 있다.
• 즐거운 사용자 경험(개발 중)

현재 Chopin은 아주 작은 초기 연구 프로토타입이다. 아직 특별히 인상적인 수준은 아니지만, 풍부하고 비교적 덜 탐구된 연구 분야로 들어가는 출발점이 될 수 있다고 본다.

Chopin은 더 야심차지만 복잡하고 출시하기 어려웠던 실시간 멀티플레이어 에이전트 엔지니어링 제품 Ace에서 이어진 프로젝트다. Ace는 별도 공지가 있을 때까지 중단된 상태다. 팀은 Ace의 유망한 아이디어를 가져와 멀티플레이어 계획 도구라는 더 단순한 환경에서 탐색하고 있다.

또한 Chopin은 오픈소스로 공개됐다. GitHub 저장소에서 코드를 볼 수 있다.

앞으로의 계획

Chopin은 제품도 완성된 프로토타입도 아니다. 지금 사용해 보라고 권하지 않는다. 다만 한 달 정도 안에 몇 가지 문제를 다듬어 알파 사용자 참여를 본격적으로 검토할 수 있기를 기대한다.

지금 오픈소스로 공개하는 것은 공개적으로 개발하고 조사 과정에서 배운 점을 공유하겠다는 약속이다. 이는 GitHub뿐 아니라 이 문제에 관심 있는 누구에게나 도움이 되기 위한 것이다. GitHub 안에는 github.com에 실시간 협업형 계획 문서를 제공하는 팀이 있으며, Chopin 프로젝트가 그 작업에 영향을 주고 기여하기를 바란다.

이 분야에 관심이 있다면 저장소를 살펴보고 의견을 남기거나 이슈를 열 수 있다. 프로젝트의 에이전트는 새로운 아이디어를 검토하고 버그를 수정하는 일을 언제든 도울 수 있다.