이 워크플로를 쓸수록 더 마음에 듦. 진짜 게임 체인저는 (a) worktree마다 병렬 스레드를 돌리고, (b) VM 띄우듯 다룰 수 있을 만큼 라이프사이클 훅이 충분한 부분임
내 경우엔 worktree를 만들면 로컬 config 파일을 복사하고, Postgres가 dev/test DB를 복제해서 격리된 테스트를 하게 해줌. worktree를 닫으면 그 DB도 같이 지움
지금까지는 Conductor가 제일 좋았지만 회사에서는 Copilot만 써야 하고 백엔드도 Claude/Codex로 고정돼 있어서 못 씀. Arbor는 비슷하지만 개발이 덜 활발하고 거친 부분이 많고, Opencode GUI는 create hook은 있어도 teardown이 없음
Zed가 이 부분까지 연결하면서도 좋은 에디터 정체성을 유지하면 확실히 판을 바꿀 수 있다고 봄
반가움. Conductor 만든 사람인데 이런 사용 사례가 정말 도움 됨
더 많은 에이전트를 붙이는 작업 중이고, Copilot과 OpenCode harness 지원 요청이 특히 많음
최근엔 탈출구도 만들었음. Settings → Experimental → Big Terminal Mode를 켜면 가운데 패널에 새 터미널을 만들고(⌘⇧T) Copilot, OpenCode 같은 원하는 에이전트를 쓸 수 있음. 아직 알림 같은 건 부족해서 완성형 경험은 아니지만, 정식 UI가 나오기 전까지는 원하는 harness를 쓸 수 있게 해줌
피드백은 언제든 charlie@conductor.build로 보내주면 됨
내가 뭔가를 오해한 게 아니라면, 이건 외부 도구 없이 헬퍼 셸 스크립트 몇 개로 충분히 만들 수 있어 보임
새 git worktree를 만들고, 로컬 .env나 다른 config 파일을 복사한 뒤 worktree마다 충돌 없는 포트와 변수를 채워 넣으면 됨. localhost 충돌 회피용이고 Docker로도 풀 수 있음
main에 머지한 뒤 worktree를 정리하는 teardown 스크립트도 같이 두면 되고, 자동화 테스트용으로는 Chrome debug port와 임시 user data dir도 worktree별로 다르게 주고 있음
그래서 굳이 별도 라이브러리나 툴이 왜 필요한지는 잘 모르겠음
VSCode에서는 같은 용도로 https://github.com/jackiotyu/git-worktree-manager를 씀
이 확장에는 before create / before destroy hook가 있어서 원하는 작업을 뭐든 넣을 수 있음. 내 쪽에선 main checkout의 workspace 파일을 심링크하고, 패키지 설치하고, 몇몇 파일도 복사하게 해둠. 꽤 편리함
Ouijit도 볼 만함. 나는 업무에서 자주 쓰는데, 원하는 환경 자체에 초점을 맞추고 그 안에서 어떤 툴이든 쓸 수 있는 셸을 줌
필요하면 worktree별 VM 격리도 가능함 https://github.com/ouijit/ouijit
이제는 다들 병렬 에이전트와 worktree 쪽으로 가는 게 분명해 보이는데, Zed가 이걸 내놓은 건 의외였음. 원래는 에디터 중심이고 AI는 철저히 선택 사항이라는 색이 강했으니까
Zed의 강점은 에이전트 불문이라는 점, 저장소마다 worktree를 자동으로 만들어 한 에이전트에서 여러 리포지토리를 다룰 수 있다는 점, 그리고 CLI를 감싼 수준이 아니라 자체 에이전트 UI 품질이 높다는 점임. 내가 알기로 이 조합을 다 갖춘 첫 메이저 도구 같음
맞긴 한데 Claude의 MCP integration 같은 기능은 많이 빠져 있음
이걸 logfire에 붙여서 텔레메트리를 보는데, 최적화나 버그 진단할 때는 체감이 엄청 큼. plugins랑 skills도 아직 없음
그래도 provider를 쉽게 바꿔 끼울 수 있는 건 좋음
새 기본 레이아웃은 내가 원하는 방향과 정확히 반대임
내 기준에선 project tree | text editor | agent view | threads 순서여야 함
대부분 노트북에선 패널 두 개 정도만 제대로 보이고, 네 패널 워크플로를 강조할 게 아니라 패널 관리와 뷰 전환을 쉽게 만드는 쪽에 더 집중해야 함. 울트라와이드가 아니라면 Agents는 차라리 별도 창이 나음
Zed를 많이 쓰고 설정으로 바꿀 수 있는 사소한 부분이긴 한데, 꽤 상징적인 설계 결정처럼 느껴져서 거슬림. 이러다 편집 자체는 덜 중요하다고 판단하고 VI mode 지원도 밀어내는 것 아닌가 싶음
나도 제일 먼저 모든 위치를 원래대로 되돌렸음. 강제로 밀어 넣은 자동 레이아웃 변경이 정말 싫었음
변경 로그를 봐도 요즘은 에이전트 쪽에 대부분의 노력이 들어가는 것 같아서 걱정됨. 내가 Zed를 좋아하는 이유는 좋은 에디터이면서 에이전트를 조금 아는 정도이기 때문이지, 점점 더 깊게 에이전트 관리 중심으로 피벗하길 바라진 않음
VI 지원을 빼면 기여자로서도 사용자로서도 바로 떠날 것임. 애초에 그게 Zed를 쓰기 시작한 이유였음
다만 당장 없앨 것 같지는 않음
편집이 중요하지 않다고 판단해서 VI 지원까지 끊을 거라고 보는 건 너무 비약적임
나는 일부러 병렬 에이전트를 피하는 편임. 인지 부채가 너무 커지고, 작업 중간에 구조적으로 말이 되는 방향으로 에이전트를 계속 조향해야 하는 경우가 많기 때문임
동의함. 단순한 작업엔 잘 맞지만, 그런 작업은 순차적으로 해도 원래 빠름
복잡한 작업은 보통 thinking 출력을 열어두고 중간에 끊거나 가이드를 넣어야 함. 그걸 안 하면 결과물이 엉망일 때가 많고, 그걸 고치기도 힘든데 병렬 프로세스까지 같이 보고 있으면 더 어려워짐
나도 같음. 리뷰 부담도 커지고, 코드 리뷰까지 해야 하면 멀티태스킹은 생산성을 거의 다 죽임
요즘은 한 번에 하나의 변경만 처리하고, 완전히 자신 있게 머지할 수 있을 때까지 그 흐름을 유지함
완전히 동의함. 에이전트를 많이 띄울수록 vibe coding으로 흘러가고 guide coding은 줄어듦
어느 순간 머릿속에서 그냥 커밋하고 넘어가자는 신호가 오는데, 그 유혹을 억지로 참게 됨
기본 레이아웃이 코드와 파일 트리를 밀어내고 AI 도구 자리를 만드는 건 별로 마음에 안 듦
Zed는 정말 좋아하고 매일 쓰지만, 처음 설치했을 때 이 레이아웃을 봤다면 진지하게 보지 않았을 것 같음
신규 사용자 일부는 확실히 밀어낼 수 있다고 봄
오히려 잃는 것보다 더 많은 사용자를 끌어올 것 같음
비슷한 걸 하는 다른 툴들은 대부분 무겁고 버그도 많고 Electron 기반임
다행히 바꾸기는 아주 쉬움. 다만 새 사용자에겐 조금 직관적이지 않음
하단 바의 작은 패널 아이콘을 우클릭해서 도킹 위치를 고르면 되고, 좌클릭은 패널 표시 토글임
이제는 에디터에 4K 모니터가 있으면 좋은 수준이 아니라 거의 요구사항처럼 되어감
지금도 agent, editor, files/git 같은 걸 같이 띄우는데 여기에 네 번째 패널까지 추가하면 저해상도에선 너무 답답함. 나는 4K 모니터가 있긴 하지만 원래는 반쪽에 에디터, 반쪽에 브라우저 같은 다른 창을 두고 썼어서 에디터를 풀스크린으로 써야 하는 흐름은 여전히 약간 거슬림
물론 이건 기본 레이아웃일 뿐이고 Zed에도 아마 바꾸는 방법이 있을 것 같음. JetBrains IDE처럼 좌상/좌하/우하/우상 식으로 패널을 배치하고 한 번에 숨기고 보여줄 수 있으면, 예를 들어 파일은 좌상단, 에이전트는 좌하단에 두고 가운데는 계속 에디터 중심으로 유지할 수 있음
오히려 더 많은 사용자를 끌어들일 수도 있음. 나는 코드를 보고 싶지 않음
여러 프로젝트를 한 곳에 몰아넣고 끝없이 컨텍스트 스위칭하기 쉬운 codex 스타일 앱이 더 좋음
나도 처음엔 그렇게 느꼈는데, 실제 변경은 주로 어느 패널이 왼쪽/오른쪽 어디에 도킹되느냐를 바꾸고 AI 패널을 조금 다듬은 정도로 보임
macOS에서는 여전히 ⌘B가 왼쪽 dock 토글, ⌘R이 오른쪽 dock 토글임
새 레이아웃을 켜면 원래 왼쪽에 있던 패널이 오른쪽으로 가는 식이라, 전통적인 코딩 용도로도 한 번 써볼 생각임. 설정 창에서 각 패널의 도킹 위치는 바꿀 수 있음
나한텐 병렬 에이전트가 기본이 아니라 예외에 가까움. 어쩌면 내가 문제일 수도 있겠지만, 그런 예외적인 상황도 터미널 몇 개 더 열면 충분하다고 느낌
이게 정말 주된 워크플로가 되어야 하는지는 잘 모르겠음. 내 뇌는 한 문제를 깊게 파는 쪽이 더 잘 맞음
나도 완전히 같은 타입인데, 이번 업데이트는 꽤 기대됨
꼭 병렬 실행 자체보다도 스레드 사이를 쉽게 오가는 것이 더 중요함. 메인 편집 컨텍스트를 흐트러뜨리지 않고 옆 스레드에서 잡다한 조사 작업을 파고들 수 있게 해줌
예전엔 거의 안 썼지만 이제는 써보고 싶음. 어떤 작업이든 spin up / tear down을 격리해서 처리할 수 있기 때문임
예를 들면 편집에 들어가기 전에 변경 초안을 먼저 잡거나, 리뷰 전에 브랜치를 checkout해서 코드를 셋업하는 작업 같은 것들임
Zed를 써봤고 충분히 메인 에디터로 쓸 수 있겠다고 느꼈지만, 확장 부족이 아쉬웠음. TODO highlight, TabOut 같은 것과 자잘한 QoL이 부족했고, 라인 번호 이동도 VSCode만큼 쉽지 않았고 다른 댓글에서 말한 탭 필터도 아쉬웠음
그리고 git commit message 에디터에서 폰트 크기를 설정할 수 없는 건 이상했음
최근 추가된 것 중에선 dev container integration은 정말 좋았음
Zed 응원함
참고로 이제 TODO 하이라이팅 확장이 있음. 지금 기계 앞은 아니지만 이름이 아마 comments highlighter 비슷했음
없는 Zed 확장은 zed agents로 직접 만들면 됨
Zed의 agent UI는 내가 본 것 중 가장 혼란스러운 UI임. 아이콘은 작고 모호하고, x를 눌렀을 때 어떤 때는 에디터가 닫히고 어떤 때는 에이전트가 닫히고 어떤 때는 패널이 닫혀서 결과를 예측하기 어려움
새 기능 때문에 다시 써보려 했는데 이 예측 불가능한 동작 때문에 결국 삭제했음. 게다가 내가 구독 중인 opencode Go도 지원하지 않음
Warp도 1주쯤 전에 비슷한 걸 내놨지만, 내가 보기엔 Zed 쪽 구현이 더 논리적임
오랜만에 또 한 번 Zed를 써봐야겠음. 매달 한 번씩 오는 “이번엔 이 터미널/IDE를 써볼까” 하는 itch가 올라온 상태임
Warp도 좋아하지만 뭔가 불투명하고 헷갈리는 느낌이 있음
내가 아직 학습 곡선을 제대로 넘지 못한 걸 수도 있고, 그냥 아직 알파 단계에 가깝고 자주 바뀌어서 그럴 수도 있음
Parallel agents 기능이 git worktree나 로컬 프로젝트 중심으로 설계된 것처럼 보이는데, 로컬 프로젝트 모드는 오히려 핵심을 흐린다고 느낌
내 일상 개발 흐름은 이미 jj workspaces로 완전히 옮겨갔기 때문에, Zed가 jj를 지원하기 전까진 이 기능을 쓸 일이 없음
게다가 이번 변경으로 레이아웃까지 예상 못 하게 뒤섞였는데, 지금은 원래대로 되돌리는 방법도 잘 모르겠음
Hacker News 의견들
이 워크플로를 쓸수록 더 마음에 듦. 진짜 게임 체인저는 (a) worktree마다 병렬 스레드를 돌리고, (b) VM 띄우듯 다룰 수 있을 만큼 라이프사이클 훅이 충분한 부분임
내 경우엔 worktree를 만들면 로컬 config 파일을 복사하고, Postgres가 dev/test DB를 복제해서 격리된 테스트를 하게 해줌. worktree를 닫으면 그 DB도 같이 지움
지금까지는 Conductor가 제일 좋았지만 회사에서는 Copilot만 써야 하고 백엔드도 Claude/Codex로 고정돼 있어서 못 씀. Arbor는 비슷하지만 개발이 덜 활발하고 거친 부분이 많고, Opencode GUI는 create hook은 있어도 teardown이 없음
Zed가 이 부분까지 연결하면서도 좋은 에디터 정체성을 유지하면 확실히 판을 바꿀 수 있다고 봄
더 많은 에이전트를 붙이는 작업 중이고, Copilot과 OpenCode harness 지원 요청이 특히 많음
최근엔 탈출구도 만들었음. Settings → Experimental → Big Terminal Mode를 켜면 가운데 패널에 새 터미널을 만들고(⌘⇧T) Copilot, OpenCode 같은 원하는 에이전트를 쓸 수 있음. 아직 알림 같은 건 부족해서 완성형 경험은 아니지만, 정식 UI가 나오기 전까지는 원하는 harness를 쓸 수 있게 해줌
피드백은 언제든 charlie@conductor.build로 보내주면 됨
새 git worktree를 만들고, 로컬 .env나 다른 config 파일을 복사한 뒤 worktree마다 충돌 없는 포트와 변수를 채워 넣으면 됨. localhost 충돌 회피용이고 Docker로도 풀 수 있음
main에 머지한 뒤 worktree를 정리하는 teardown 스크립트도 같이 두면 되고, 자동화 테스트용으로는 Chrome debug port와 임시 user data dir도 worktree별로 다르게 주고 있음
그래서 굳이 별도 라이브러리나 툴이 왜 필요한지는 잘 모르겠음
https://www.visualjj.com/learn/parallel-ai-agents
이 확장에는 before create / before destroy hook가 있어서 원하는 작업을 뭐든 넣을 수 있음. 내 쪽에선 main checkout의 workspace 파일을 심링크하고, 패키지 설치하고, 몇몇 파일도 복사하게 해둠. 꽤 편리함
필요하면 worktree별 VM 격리도 가능함
https://github.com/ouijit/ouijit
이제는 다들 병렬 에이전트와 worktree 쪽으로 가는 게 분명해 보이는데, Zed가 이걸 내놓은 건 의외였음. 원래는 에디터 중심이고 AI는 철저히 선택 사항이라는 색이 강했으니까
Zed의 강점은 에이전트 불문이라는 점, 저장소마다 worktree를 자동으로 만들어 한 에이전트에서 여러 리포지토리를 다룰 수 있다는 점, 그리고 CLI를 감싼 수준이 아니라 자체 에이전트 UI 품질이 높다는 점임. 내가 알기로 이 조합을 다 갖춘 첫 메이저 도구 같음
이걸 logfire에 붙여서 텔레메트리를 보는데, 최적화나 버그 진단할 때는 체감이 엄청 큼. plugins랑 skills도 아직 없음
그래도 provider를 쉽게 바꿔 끼울 수 있는 건 좋음
새 기본 레이아웃은 내가 원하는 방향과 정확히 반대임
내 기준에선 project tree | text editor | agent view | threads 순서여야 함
대부분 노트북에선 패널 두 개 정도만 제대로 보이고, 네 패널 워크플로를 강조할 게 아니라 패널 관리와 뷰 전환을 쉽게 만드는 쪽에 더 집중해야 함. 울트라와이드가 아니라면 Agents는 차라리 별도 창이 나음
Zed를 많이 쓰고 설정으로 바꿀 수 있는 사소한 부분이긴 한데, 꽤 상징적인 설계 결정처럼 느껴져서 거슬림. 이러다 편집 자체는 덜 중요하다고 판단하고 VI mode 지원도 밀어내는 것 아닌가 싶음
변경 로그를 봐도 요즘은 에이전트 쪽에 대부분의 노력이 들어가는 것 같아서 걱정됨. 내가 Zed를 좋아하는 이유는 좋은 에디터이면서 에이전트를 조금 아는 정도이기 때문이지, 점점 더 깊게 에이전트 관리 중심으로 피벗하길 바라진 않음
다만 당장 없앨 것 같지는 않음
나는 일부러 병렬 에이전트를 피하는 편임. 인지 부채가 너무 커지고, 작업 중간에 구조적으로 말이 되는 방향으로 에이전트를 계속 조향해야 하는 경우가 많기 때문임
복잡한 작업은 보통 thinking 출력을 열어두고 중간에 끊거나 가이드를 넣어야 함. 그걸 안 하면 결과물이 엉망일 때가 많고, 그걸 고치기도 힘든데 병렬 프로세스까지 같이 보고 있으면 더 어려워짐
요즘은 한 번에 하나의 변경만 처리하고, 완전히 자신 있게 머지할 수 있을 때까지 그 흐름을 유지함
어느 순간 머릿속에서 그냥 커밋하고 넘어가자는 신호가 오는데, 그 유혹을 억지로 참게 됨
기본 레이아웃이 코드와 파일 트리를 밀어내고 AI 도구 자리를 만드는 건 별로 마음에 안 듦
Zed는 정말 좋아하고 매일 쓰지만, 처음 설치했을 때 이 레이아웃을 봤다면 진지하게 보지 않았을 것 같음
신규 사용자 일부는 확실히 밀어낼 수 있다고 봄
비슷한 걸 하는 다른 툴들은 대부분 무겁고 버그도 많고 Electron 기반임
하단 바의 작은 패널 아이콘을 우클릭해서 도킹 위치를 고르면 되고, 좌클릭은 패널 표시 토글임
지금도 agent, editor, files/git 같은 걸 같이 띄우는데 여기에 네 번째 패널까지 추가하면 저해상도에선 너무 답답함. 나는 4K 모니터가 있긴 하지만 원래는 반쪽에 에디터, 반쪽에 브라우저 같은 다른 창을 두고 썼어서 에디터를 풀스크린으로 써야 하는 흐름은 여전히 약간 거슬림
물론 이건 기본 레이아웃일 뿐이고 Zed에도 아마 바꾸는 방법이 있을 것 같음. JetBrains IDE처럼 좌상/좌하/우하/우상 식으로 패널을 배치하고 한 번에 숨기고 보여줄 수 있으면, 예를 들어 파일은 좌상단, 에이전트는 좌하단에 두고 가운데는 계속 에디터 중심으로 유지할 수 있음
여러 프로젝트를 한 곳에 몰아넣고 끝없이 컨텍스트 스위칭하기 쉬운 codex 스타일 앱이 더 좋음
macOS에서는 여전히 ⌘B가 왼쪽 dock 토글, ⌘R이 오른쪽 dock 토글임
새 레이아웃을 켜면 원래 왼쪽에 있던 패널이 오른쪽으로 가는 식이라, 전통적인 코딩 용도로도 한 번 써볼 생각임. 설정 창에서 각 패널의 도킹 위치는 바꿀 수 있음
나한텐 병렬 에이전트가 기본이 아니라 예외에 가까움. 어쩌면 내가 문제일 수도 있겠지만, 그런 예외적인 상황도 터미널 몇 개 더 열면 충분하다고 느낌
이게 정말 주된 워크플로가 되어야 하는지는 잘 모르겠음. 내 뇌는 한 문제를 깊게 파는 쪽이 더 잘 맞음
꼭 병렬 실행 자체보다도 스레드 사이를 쉽게 오가는 것이 더 중요함. 메인 편집 컨텍스트를 흐트러뜨리지 않고 옆 스레드에서 잡다한 조사 작업을 파고들 수 있게 해줌
예를 들면 편집에 들어가기 전에 변경 초안을 먼저 잡거나, 리뷰 전에 브랜치를 checkout해서 코드를 셋업하는 작업 같은 것들임
Zed를 써봤고 충분히 메인 에디터로 쓸 수 있겠다고 느꼈지만, 확장 부족이 아쉬웠음. TODO highlight, TabOut 같은 것과 자잘한 QoL이 부족했고, 라인 번호 이동도 VSCode만큼 쉽지 않았고 다른 댓글에서 말한 탭 필터도 아쉬웠음
그리고 git commit message 에디터에서 폰트 크기를 설정할 수 없는 건 이상했음
최근 추가된 것 중에선 dev container integration은 정말 좋았음
Zed 응원함
Zed의 agent UI는 내가 본 것 중 가장 혼란스러운 UI임. 아이콘은 작고 모호하고, x를 눌렀을 때 어떤 때는 에디터가 닫히고 어떤 때는 에이전트가 닫히고 어떤 때는 패널이 닫혀서 결과를 예측하기 어려움
새 기능 때문에 다시 써보려 했는데 이 예측 불가능한 동작 때문에 결국 삭제했음. 게다가 내가 구독 중인 opencode Go도 지원하지 않음
Warp도 1주쯤 전에 비슷한 걸 내놨지만, 내가 보기엔 Zed 쪽 구현이 더 논리적임
오랜만에 또 한 번 Zed를 써봐야겠음. 매달 한 번씩 오는 “이번엔 이 터미널/IDE를 써볼까” 하는 itch가 올라온 상태임
내가 아직 학습 곡선을 제대로 넘지 못한 걸 수도 있고, 그냥 아직 알파 단계에 가깝고 자주 바뀌어서 그럴 수도 있음
Parallel agents 기능이 git worktree나 로컬 프로젝트 중심으로 설계된 것처럼 보이는데, 로컬 프로젝트 모드는 오히려 핵심을 흐린다고 느낌
내 일상 개발 흐름은 이미 jj workspaces로 완전히 옮겨갔기 때문에, Zed가 jj를 지원하기 전까진 이 기능을 쓸 일이 없음
게다가 이번 변경으로 레이아웃까지 예상 못 하게 뒤섞였는데, 지금은 원래대로 되돌리는 방법도 잘 모르겠음