요즘 개발하면서 한 가지 기능이 한 저장소 안에서 끝나는 경우가 점점 줄었습니다. 제가 만들고 있는 Rona도 웹, 데스크톱 앱, 에이전트 스킬이 각각 다른 저장소에 있습니다.
예를 들어 사용자가 Rona에서 기간 계획을 만든 뒤 코칭을 시작하는 흐름만 해도 이렇습니다.
웹은 사용자의 계획과 챌린지 정보를 보관합니다.
데스크톱 앱은 로컬 계획을 찾고 코칭 세션을 연결합니다.
에이전트 스킬은 계획 파일을 읽고 코칭을 시작하거나 이어갑니다.
이런 기능을 확인할 때는 저장소 세 개를 번갈아 열면서 앞 단계의 정보가 다음 단계로 제대로 이어지는지 봐야 합니다. 한쪽 코드만 읽으면 멀쩡해 보이는데, 세 저장소를 이어서 보면 빠진 연결이 나오는 경우가 있습니다.
이번에는 Paseo를 기능 소개용으로만 써보지 않고, 실제로 미뤄두었던 이 교차 검토를 맡겨봤습니다.
Paseo는 여러 코딩 에이전트를 모아두는 작업 공간입니다
Paseo는 Codex, Claude Code, OpenCode 같은 코딩 에이전트를 한 화 면에서 실행하고 관리할 수 있는 오픈소스 도구입니다. 새로운 AI 모델이라기보다는, 이미 사용하고 있는 에이전트를 프로젝트와 작업 단위로 정리해주는 관리 화면에 가깝습니다.
제 컴퓨터에 설치된 Codex와 Claude Code의 기존 인증을 그대로 사용했고, 별도의 API 키를 새로 만들 필요는 없었습니다. 웹 화면과 CLI가 같은 로컬 데몬을 바라보기 때문에 터미널에서 작업을 만들고 화면에서 결과를 확인할 수도 있었습니다.
실제 Rona 저장소 세 개를 동시에 조사해봤습니다
먼저 기존 작업 폴더는 건드리지 않고, 최신 코드를 복사한 독립적인 작업 폴더를 세 개 만들었습니다. Paseo에서는 이를 worktree라고 부릅니다. 원래 작업 폴더에는 진행 중인 변경이 있었기 때문에, 에이전트가 그 파일을 덮어쓰지 않게 분리하는 것이 중요했습니다.
역할은 다음처럼 나눴습니다.
Codex GPT-5.6-Terra: 웹과 서버에서 기간 계획이 어떻게 저장되는지 조사
Claude Sonnet 4.6: 데스크톱 앱에서 계획을 찾고 코칭을 시작·재개하는 흐름 조사
Codex GPT-5.6-Luna: 에이전트 스킬의 계획 파일과 동기화 규칙 조사
세 에이전트 모두 파일을 수정하지 않고, 현재 코드와 테스트를 읽어 결과에 파일 경로와 줄 번호를 붙이도록 했습니다.
한국어 텍스트가 있는 검은 화면의 스크린샷
이렇게 해두니 한 에이전트에게 저장소 세 개를 모두 설명하는 대신, 각 에이전트가 한 저장소의 계약에 집중할 수 있었습니다. Paseo 왼쪽에는 세 작업 공간이 함께 보이고, 오른쪽에는 선택한 에이전트가 읽은 명령과 결론이 한 흐름으로 남았습니다.
제가 확인하고 싶었던 것은 하나의 사용자 경험이었습니다
이번 조사에서 확인하고 싶었던 상황은 단순했습니다.
사용자가 Rona에서 실행 계획을 만든다. 나중에 그중 한 가지를 코칭으로 진행한다. 코칭을 마치면 계획과 웹 진행표에도 완료한 결과가 자연스럽게 이어진다.
사용자에게는 한 번의 경험이지만, 실제로는 세 시스템이 차례로 움직입니다. 웹은 사용자가 어떤 챌린지와 계획을 진행하는지 기억합니다. 데스크톱 앱은 사용자가 작업할 폴더와 코딩 에이전트를 연결합니다. 에이전트 스킬은 선택한 계획을 읽고 코칭을 시작한 뒤 진행 상태를 기록합니다.
한 저장소만 읽으면 자기 역할은 잘 구현된 것처럼 보입니다. 그래서 각 에이전트에게 “이 기능이 있나요?”라고 묻는 대신, 한 명은 웹이 기억하는 내용을, 한 명은 앱이 넘겨받는 내용을, 한 명은 코칭이 실제로 기록하는 내용을 조사하게 했습니다.
세 결과를 합치니 정상 흐름과 빈틈이 함께 보였습니다
개별 조사가 끝난 뒤에는 데스크톱 앱을 조사한 Claude에게 다른 두 에이전트의 결과도 읽게 했습니다. 세 저장소를 합쳐보니 의도한 흐름은 다음과 같았습니다.
사용자가 기간 계획을 만들면 계획은 우선 사용자 컴퓨터에 저장됩니다.
웹에는 이 사용자가 어느 계획을 진행하는지 식별할 수 있는 정보가 연결됩니다.
사용자가 코칭을 시작하면 Rona Coach가 열리고, 사용자는 작업 폴더와 사용할 에이전트를 고릅니다.
에이전트는 현재 계획을 확인하고, 이번 코칭을 계획의 어느 단계와 연결할지 사용자에게 묻습니다.
연결이 정상적으로 확인된 뒤에만 코칭을 시작하고, 코칭이 끝나면 사용자의 동의를 받아 기간 계획에도 완료 상태를 반영합니다.
이 순서를 지키면 에이전트가 엉뚱한 계획을 이어가거나, 아직 연결되지 않은 코칭의 작업부터 시작하는 일을 막을 수 있습니다. 여기까지는 세 저장소가 같은 방향을 바라보고 있었습니다.
다만 실제 사용자 경험이 끝까지 이어진다고 확신하려면 세 가지를 더 확인해야 했습니다.
앱에서 완료한 내용이 웹에도 보이는가
현재 코드에서는 에이전트가 코칭을 마친 뒤 사용자 컴퓨터에 있는 계획을 완료 상태로 바꾸는 과정까지 확인할 수 있었습니다. 하지만 바뀐 내용을 웹 진행표에도 다시 보내는 경로는 찾지 못했습니다.
이 연결이 실제로 없다면 사용자는 앱에서 한 단계를 끝냈는데 웹에서는 아직 진행 전으로 보게 됩니다. 아직 실제 화면에서 재현한 버그는 아니므로, 다음 단계는 코드를 바로 고치는 것이 아니라 한 번의 통합 테스트로 앱과 웹의 표시가 일치하는지 확인하는 것입니다.
연결한 계획이 정말 이 사용자의 계획인가
서버는 코칭과 함께 들어온 계획 정보가 정해진 형식에 맞는지는 확인하고 있었습니다. 하지만 그 계획이 실제로 현재 사용자가 만든 계획인지까지 다시 대조하는 과정은 찾지 못했습니다.
이 역시 곧바로 결함이라고 단정할 수는 없습니다. 사용자 컴퓨터의 계획을 신뢰하기로 한 설계일 수 있기 때문입니다. 다만 잘못된 작업 폴더를 선택하거나 에이전트가 다른 계획을 읽었을 때도 연결이 받아들여지는지 확인할 필요는 있습니다.
중간에 다른 곳에서 상태가 바뀌면 다시 이어갈 수 있는가
Rona는 변경할 때마다 번호를 붙여, 오래 된 내용이 최신 내용을 덮어쓰지 않게 합니다. 처음 코칭을 연결할 때는 앱과 서버가 기억하는 번호가 정확히 같아야 합니다. 기존 코칭을 이어갈 때는 서버에 더 최신 내용이 있으면 그 내용을 받아와 계속할 수 있습니다.
상태를 보호하는 장치는 있었지만, 차이가 발견됐을 때 에이전트가 무엇을 다시 읽고 어떻게 이어가야 하는지는 모든 경우에 명확하지 않았습니다. 실제 사용 중 이런 상황이 생겼을 때 코칭이 안전하게 복구되는지 확인하는 것도 다음 검증 후보로 남겼습니다.
이렇게 정리하고 나니 “저장소를 여러 개 볼 수 있다”보다 구체적인 결과가 생겼습니다. 사용자가 계획을 만들고 코칭을 끝낼 때까지 어느 연결을 실제로 시험해야 하는지가 보였습니다.
에이전트를 세 개 붙여도 결론이 자동으로 맞아지지는 않았습니다
오히려 이번 사용에서 가장 인상적이었던 장면은 에이전트가 틀린 제안을 했을 때였습니다.
첫 종합 결과는 웹에서 데스크톱 앱을 열 때 계획 정보도 함께 보내자고 제안했습니다. 코드만 이어서 보면 꽤 그럴듯했습니다. 앱을 여는 주소에 정보가 없으니 연결이 끊겼다고 판단한 것입니다.
하지만 현재 제품 결정은 반대였습니다. 웹의 버튼은 앱을 여는 역할만 맡습니다. 어떤 계획을 사용할지는 앱이 열린 뒤 사용자가 작업 폴더를 고르는 과정에서 정합니다. 주소에 계획 정보를 넣지 않은 것은 빠진 기능이 아니라, 두 역할을 분리하기 위해 정한 방식이었습니다.
그래서 같은 에이전트에게 이 제품 결정을 알려주고 기존 결론을 다시 검토하게 했습니다. 에이전트는 앱을 여는 주소에 계획 정보를 넣자는 제안을 철회하고, 앱 안에서 계 획을 발견하고 선택하는 현재 과정을 다시 정리했습니다.
여러 항목이 표시된 검은색 화면의 스크린샷
이 경험 덕분에 Paseo의 쓰임을 조금 다르게 보게 됐습니다. 여러 에이전트의 답을 한데 모은다고 정확도가 저절로 올라가는 것은 아닙니다. 대신 조사 역할을 나누고, 결과를 한곳에 모은 뒤, 제품 결정과 충돌하는 결론을 다시 되묻게 만드는 작업 흐름을 만들 수 있었습니다.
직접 써보며 느낀 장점
가장 실용적이었던 것은 작업 폴더를 분리하는 기능이었습니다. 기존 Rona 작업 폴더에는 수정 중인 파일이 있었지만, 세 에이전트는 모두 Paseo가 만든 별도 폴더에서 최신 코드를 읽었습니다. 원래 작업 폴더를 정리하거나 변경사항을 임시로 치울 필요가 없었습니다.
두 번째는 서로 다른 에이전트의 기록을 다시 입력으로 사용할 수 있다는 점이었습니다. 웹 조사 결과를 복사해 옮기는 대신, 종합 담당 에이전트가 Paseo CLI로 다른 작업의 로그를 읽고 자기 조사와 합쳤습니다. 여러 창을 오가며 결과를 찾아 붙이는 일이 줄었습니다.
세 번째는 같은 대화에 후속 지시를 이어갈 수 있다는 점이었습니다. 잘못된 제안을 발견했을 때 새 작업을 만들지 않고, 해당 결론이 나온 대화에 제품 계약을 추가해 다시 검토하게 했습니다. 처음 결론과 정정된 결론이 같은 기록에 남아 판단 과정을 비교하기도 쉬웠습니다.
아직 거친 부분도 있었습니다
제가 사용한 버전은 v0.8.0이었습니다. Claude에게 다른 에이전트의 로그를 읽게 하는 과정에서 읽기 전용 명령에도 권한 확인이 여러 번 나타났습니다. 조사 범위를 확인한 뒤 해당 에이전트만 자동 권한 모드로 바꿔야 했습니다. 권한을 세밀하게 통제할 수 있다는 장점은 있지만, 여러 저장소를 넘나드는 조사에서는 중간 확인이 자주 생길 수 있습니다.
또 새로 분리한 작업 폴더에는 테스트 실행에 필요한 프로그램이 설치되어 있지 않았습니다. 웹 저장소의 관련 테스트를 실행하려 했지만 시작하지 못했고, 이번 결과는 코드와 테스트 항목을 읽은 조사에 머물렀습니다. 스킬 저장소 테스트도 9개 중 8개만 통과했고, 나머지 하나는 분리된 폴더에서 함께 확인해야 할 다른 저장소를 찾지 못해 실패했습니다.
따라서 이번에는 각 서비스가 정보를 주고받는 방식과 아직 직접 시험하지 못한 부분까지 확인했습니다. 실제 사용자 환경의 오류를 재현하거나 Rona 코드를 수정·병합·배포한 것은 아닙니다.
어떤 사람에게 추천할 수 있을까
코딩 에이전트 하나로 저장소 하나만 다룬다면 Paseo가 꼭 필요하지는 않습니다. Codex 앱이나 Claude Code만 사용하는 편이 더 단순할 수 있습니다.
반대로 다음과 같은 상황이라면 한번 써볼 만합니다.
하나의 기능이 여러 저장소에 걸쳐 있습니다.
Codex와 Claude Code를 작업 성격에 따라 나눠 씁니다.
진행 중인 원본 작업 폴더를 건드리지 않고 여러 조사를 병렬 로 돌리고 싶습니다.
개별 결과를 다시 다른 에이전트에게 교차 검토시키고 싶습니다.
처음에는 Paseo를 여러 코딩 에이전트의 실행 화면 정도로 생각했습니다. 실제 업무에 적용해보니 더 유용했던 것은 에이전트를 많이 띄우는 기능이 아니라, 각자 맡은 범위와 결과, 정정 과정을 한곳에 남기는 일이었습니다.
이번 조사로 바로 버그를 고친 것은 아닙니다. 대신 다음 통합 테스트에서 확인할 세 가지 후보가 생겼고, 그보다 더 중요한 잘못된 우선순위 하나를 개발 목록에 올리기 전에 걷어냈습니다. 저에게는 이 정도면 단순한 기능 체험보다 훨씬 유의미한 사용 결과였습니다.
