기존 IDE에 agent 기반 코딩을 통합하는 방식은 잘못된 방향이라고 생각함. 여러 Git worktree를 관리하고 각각의 agent가 동시에 동작하는 방식이 더 나음. Claude Code가 작업을 끝내기를 20분 이상 기다릴 필요가 없음. 그래서 이를 관리하는 UI를 직접 만들었고, 점점 여러 agent를 관리/검토하는 새로운 유형의 IDE로 발전 중임. 기존과 달리 한 번에 하나씩 작업하는 게 아님. https://github.com/stravu/crystal
- 나는 개인적으로 다르게 생각함. 매일 Cursor를 상업적 프로젝트에 사용함. background agent는 특정 상황에서는 유용하긴 하지만 대부분은 산만함만 유발함. 내가 선호하는 코딩 방식은 하나의 목표에 집중해서 반복적으로 해결에 가까워지는 방식임. 작업이 끝나기를 기다리는 동안은 문서나 관련 정보를 탐색해서 다음 단계를 고민함. 기존 코드나 변경사항을 검토하면서 현재 진행 상황을 정확히 파악하는 것도 무척 중요함. 각각의 작업에 여러 agent를 관리하는 개념은 내 스타일과 맞지 않음. 컨텍스트 전환과 멀티태스킹이 너무 많아짐.
- 이런 워크플로우 제안에서 항상 궁금한 점은 내 개인 컨텍스트를 어떻게 관리할 수 있냐는 것임. 동료 코드 리뷰에서도 모든 코드를 완벽하게 이해하고 검증하는 대신, 주로 큰 실수(코드 스타일, 베스트 프랙티스 등)만 빠르게 확인함. 그래서 하루에 많은 PR을 빠르게 검토할 수 있음. 더 중요한 작업(내가 책임지는 경우)에는 branch를 테스트하고 구현을 꼼꼼히 확인함. PR 업데이트마다 이 작업을 반복하니 많은 시간이 소요됨. 여러 agent가 동시에 diff를 제안하면, 특히 검증이 필요할 때 컨텍스트 전환을 어떻게 하면 좋을지, 그리고 한 번의 업데이트가 다른 작업에 미묘하게 영향을 줄 때 module 의존성은 어떻게 관리할지 고민임.
- 이런 방식도 IDE 플러그인으로 동일하게 만들 수 있음.
- 멋진 툴임! Claude Code TS SDK를 쓰지 않은 이유가 궁금함. 패키지는 설치했지만 별도로 claude 명령어를 직접 실행하는 구조인 듯함. 참고로 electron-trpc도 살펴보길 추천함. IPC 처리가 훨씬 간편해짐.
- 이 툴도 멋지지만 해결하는 문제가 다름. background agent에는 두 가지 큰 문제가 있음. 1) 분리된 환경을 제대로 세팅하는 데 진입장벽이 존재함. 프로젝트마다 난이도가 차이가 크고, 간단하게 컨테이너 고르는 것부터 모든 의존성 세팅이 지옥인 경우까지 다양함. 반면 IDE 내에서 작업하면 보통 모든 게 이미 갖추어져 있음. 2) 사람들이 agent가 코드를 어떻게 빌드하는지 배워야 함. agent가 IDE에서 동작하고 내가 실시간으로 조언하거나 교정해줄 수 있으면 background agent에 장기적으로 훨씬 도움이 됨.
내가 바라는 점은 다음과 같음. git worktree 기반 컨텍스트 전환을 동일한 IDE 창에서 강력하게 지원하는 환경, 각 worktree branch마다 터미널 기반 agent를 연결할 수 있는 프레임워크, 결국엔 diff, 권한 요청 알림, 진행상황 알림을 위해 더 나은 오픈 프로토콜로 진화하는 환경, 각 worktree branch별로 agent 상태와 알림을 모니터링하는 사이드바, 여러 branch 전체에서 agent 메시지에 알림처럼 빠르게 대응할 수 있는 인터페이스임. standalone agent manager 툴에는 이런 기능이 있지만, 실제 엔지니어로 바로 뛰어들고 싶을 땐 그런 툴을 제대로 쓸 수 없음. branch별로 브라우저 테스트 창이나 모바일 에뮬레이터/시뮬레이터 인스턴스와의 연동도 필요함. 빠른 모델 기반의 코드완성, 다양한 언어 서버 지원, 고품질 IDE 역할의 확장 생태계도 갖추어야 함. 나는 현재 macOS 데스크탑 여러 개에서 Windsurf, Claude agent, 웹브라우저, 모바일 시뮬레이터를 각각 분리해 관리중임. 이 방식 매우 번거로움.
- 내가 원하는 건 디버깅 기능을 가진 코딩 agent임. 스택을 따라가고, 로컬 변수와 인자 값을 살펴보고, print나 assert 대신 실제로 내부에서 무슨 일이 벌어지는지 들여다보기 원함.
- 여러 branch에서 agent 메시지에 알림처럼 빠르게 반응하는 기능 관련해서, 나도 VSCode용 플러그인을 만들어보려 했음. Claude가 파일과 라인으로 바로 점프하게 하는 기능이었는데, 어느 정도 작동했지만 계속 멈추는 문제가 있었음.
Cursor와 Claude Code 사이의 실제 차이가 뭔지 잘 모르겠음. 둘 다 써봤고 회사에서 지원해서 그냥 Cursor로 이동함. CLI냐 UI냐 외에는 둘 다 멀티파일 수정이 되어서 별다른 차이점을 발견 못했음. 여러 에디터를 동시에 쓰거나 JetBrains와 Cursor를 오가야하는 불편한 과도기가 빨리 끝나길 바람.
- 품질과 활용도 측면에서 둘은 큰 차이임. Claude Code는 완전한 agentic 방식임. 작업을 맡기면 전체를 직접 구현해, 아주 괜찮고 잘 작동하는 코드를 만들어냄. 테스트, 커밋, 커맨드 실행, 원격 시스템 접속, 디버깅 등 가능함. Token 사용 최적화는 하지 않으므로 Cursor보다 첫 시도에서 더 고품질 코드가 나오지만, 그만큼 비용이 높음. Cursor의 agent 모드는 아직 초기 단계임. Cursor는 주로 파일 수정 툴에 가깝고 Claude Code는 주니어 개발자 같은 역할임.
- 두 툴을 함께 쓰는 경우가 많음. Cursor는 IDE, Claude Code는 IDE의 터미널에서 실행하는 방식임. 퍼포먼스 측면에서 agent 방식이 다르고, 같은 기본 모델을 쓰더라도 코드베이스 분석, 하위 모델 사용, 툴 연계 등에서 차이가 큼.
- 별다른 차이를 못 느낀다니 신기함. 내게는 Claude가 모든 면에서 월등함. scala, python, js, dart를 주로 씀. Claude로 굉장히 생산적인 어시스턴트 역할을 얻음. 작은/중간 변경에 특히 매우 쓸모 있음. 계획을 잘 세우고 쓰면 마법 같은 느낌임. 코드 중복이 좀 있지만 그 정도임. Cursor는 많은 손질이 필요해서 오히려 속도만 느려졌음.
- Claude Code 진짜 인상 깊음. 마치 또 다른 프로그래머가 내 터미널에 같이 앉아있는 느낌임. 완벽하진 않고 하고 싶은 걸 제대로 이해할 때까지는 도움을 주는 게 필요함. 하지만 컨텍스트만 잘 맞추면 정말 놀라움. 내 경우에는 프로젝트를 완전히 이해시킨 것도 아니고 TypeScript나 웹 개발에도 안 쓰고 있음.
- Cursor는 별도의 IDE로 전환해야 하고(VSCode를 원래 쓰지 않는 한), Claude Code(또는 Aider)는 현재 IDE와 병행으로 터미널에서 바로 프로젝트 파일을 수정함. 내 경우 vim+tmux+bash 조합이라 CLI 어시스턴트를 선호하지만, VSCode 말고 다른 GUI IDE 쓰는 사람에게도 동일하게 해당되는 장점임.
지난주 github이 copilot의 프리미엄 요청 제한을 도입했을 때 큰 반발이 없던 게 오히려 충격적이었음. 본격적으로 제한에 걸리는 사람들이 생기면 더 큰 반발이 있을 거라 예상함. 경쟁 제품이 있다는 게 정말 다행임.
- Claude Code는 한 번 실행에 10달러도 순식간에 사라질 수 있음.
VSCode Copilot을 Agent 모드 + Claude Sonnet 3.7이나 4로 사용할 때 대비해서 특별한 장점이 있는지 궁금함. 내가 놓치고 있는 게 뭔지 알고 싶음.
- 직접 Claude Code를 경험해봐야 이 질문에 답할 수 있음. 그냥 여기서 논쟁해봐야 의미 없음. 리눅스 터미널을 주력으로 쓴다면 바로 빠져들게 됨. 반드시 문서도 읽어 볼 것. CLAUDE.md를 쓰고, 큰 작업은 마크업 형식의 계획 문서로 만들고, 반복해서 계획-수정하고 구현을 맡겨야 함. context limit에 가까워지면 메모리를 파일로 write해서 /clear 후 다시 읽어오는 방식 사용하면 훨씬 효율적임.
- Playwright MCP와 Copilot agent 모드를 연동하려 했는데 실패함. 설치되고 툴 선택에서도 보이지만 끝내 Copilot이 기능 접근을 허용하지 않음.
Copilot agent 모드에서 Claude backend를 쓸 때에 비해 이 솔루션의 이득은 뭔지 궁금함
- 이 스레드의 다른 설명(특히 https://news.ycombinator.com/item?id=44353972)이 vscode copilot에도 적용됨
- 며칠 써본 결과, 이 통합으로 인해 파일을 직접 열어서 업데이트를 확인해야 했던 불편함이 개선됨. terminal 모드에서는 모든 게 백그라운드에서 처리되어 무슨 일이 벌어지는지 몰랐지만, 통합 IDE에서는 실시간으로 모든 걸 볼 수 있음. 다만 agent가 붙여주는 이름(예: Pondering, Twerking, Juggling 등)은 처음엔 신선했지만 곧 쓸모가 없어짐.
다소 탈선된 질문이지만, VSCode에서 Roo를 사용하는 사람이 있는지 궁금함. 그리고 Roo의 브라우저 기능이 GitHub copilot이 제공하는 Claude와 잘 연동되는지도 궁금함
알고 있기로는, VSCode(또는 Cursor)에서 Claude Code를 실행하면 이것이 자동 설치됨. 굳이 따로 찾아서 설치할 필요가 없음, 맞는지?
- Claude Code를 VSCode에서 실행하면 자동 설치된다는 사실, 좀 침해받는 느낌 아닌가?
- 맞음. 익스텐션 웹페이지에도 명시되어 있음.
```
Auto-installation: When you launch Claude Code from within VSCode’s terminal, it automatically detects and installs the extension
```
Claude Code가 여러 단계를 한 번에 이해한다는 사실을 인지하면서 워크플로우가 변하기 시작함. 파일별로 고민하던 방식이 점점 “모듈 분리, 테스트 작성, 호출부 리팩토링” 같은 단일 행동 단위로 전환됨. Claude도 이를 하나의 단위로 이해함(최대 노력 모드). 이런 변화가 점진적으로 코딩 접근법을 바꿈. 구문 걱정을 덜고, 더 많은 스캐폴딩을 작성하며, 여러 작업을 묶어서 처리하게 됨. 미묘하지만 장기적 영향이 큼. 앞으로 LLM agent가 더 잘 탐색할 수 있도록 코드베이스 구조(플랫, 최소 우회, 선언적 메타데이터 등)를 의도적으로 개선하는 시점이 얼마나 빨리 올지 궁금함.
- 언제를 미래라고 말하기 전에 이미 진행 중임. Armin Ronacher가 Python에서 Go로 코드 작성 비중을 높인 것도 LLM이 Go를 더 잘 이해해서임. 내 동료도 데스크탑 앱을 Rust로 옮긴 게 툴링과 타입 시스템 덕분에 agent가 탐색하기 쉬워서임. AI가 읽기 쉽게 문서화하는 방향으로 이미 고민이 이동 중임.
- LLM이 Go처럼 명확한 정적 타입과 간결한 문법, 일관된 작성 방식이 있는 언어에서 확실히 잘 작동한다는 이야기를 들으면서 이런 부분을 계속 생각 중임. 도구(언어, 프레임워크, 라이브러리 등)에서 파생되는 불필요한 복잡성을 얼마나 걱정하지 않아도 되는지에 따라 우리의 두뇌 자원을 더 본질적인 문제 해결에 쓸 수 있음.
Claude Code가 Jetbrains에도 들어간다니 기대됨! https://plugins.jetbrains.com/plugin/27310-claude-code-beta-
- 왜 이 댓글에 비추천이 많은지 모르겠음. 나도 동일하게 기대하고 있음. 공유해줘서 고마움

답변달기