클라우드 코드가 요즘 정말 화제다. 하지만 커서 같은 도구를 써본 사람이라면 궁금할 거다. 과연 클라우드 코드가 정말 더 나을까?
커서와 클라우드 코드를 써보면드는 질문은 첫 번째는 인터페이스에 관한 것이다. 클라우드 코드 같은 터미널 기반 코딩 에이전트가 과연 커서의 UI보다 나을까? 두 번째는 성능 면에서 정말 차이가 있을까 하는 것이다.
클라우드 코드의 기본 철학
클라우드 코드의 창시자인 Anthropic의 보리스 체르니와의 인터뷰를 들어보면 흥미로운 관점을 발견할 수 있다. 그는 이것을 언어의 진화로 본다고 했다. 프로그래밍 언어들이 어느 정도 평준화되었고, 이제는 IDE나 코드 에디터, VS Code, 심지어 터미널 클라이언트 어디서든 클라우드 코드를 실행할 수 있다는 것이다.
정말 멋진 건 인기 있는 IDE들과의 직접 통합이다. 커서, VS Code, 윈서프 등과 모두 연결된다. 터미널에서 클라우드 코드를 실행한 후 `/ide` 명령어로 IDE 연결을 관리할 수 있다.
실제로 써보니 정말 신기했다. 파일 안에 있으면 정확히 어떤 파일에 있는지 알고, 몇 줄을 선택하면 정확히 몇 줄이 선택되었는지도 파악한다. 이 모든 정보가 컨텍스트 윈도우로 들어가서 에이전트에게 특정 코드 라인이나 파일에 대해 질문할 때 활용된다. 마치 커서의 채팅 창에서 하는 것과 똑같다.
실제 사용 경험: 인터페이스의 장단점
터미널 창에서만 써야 하는 건 아니다. 커서 상단에 전용 아이콘이 있어서 클릭하면 터미널을 없애고 전용 창에서 클라우드 코드를 쓸 수 있다. 하지만 개인적으로는 이 방식이 별로였다. 실제 코드 파일들을 가려버리기 때문이다.
클라우드 코드의 철학은 터미널에서 에이전트와 상호작용하면서 실제 코드베이스에서 우리를 멀어지게 하는 것 같다. 하지만 현실적으로는 여전히 코드와 커서 에이전트, 터미널 사이를 자주 오가게 된다. 그래서 터미널 안에서 쓰는 게 더 좋았다. `Command + T`로 터미널을 열고 닫고, 추가 터미널을 띄우고, `Command + L`로 커서 채팅을 여닫는 리듬이 훨씬 자연스럽다.
MCP 통합: 개발 워크플로우의 혁신
정말 흥미로운 기능은 MCP 통합이다. Anthropic이 MCP 프로토콜의 창시자이고, 며칠 전에 클라우드 코드에서 공식 MCP 지원을 발표했다. 이게 뭘 의미하냐면, 개발 워크플로우에서 쓰는 다른 도구들을 클라우드 코드 안에서 바로 연동할 수 있다는 것이다.
예를 들어, 리니어를 티켓과 이슈 관리에 쓰고 있는데, 리니어를 MCP 서버로 클라우드 코드와 연동하면 다음 리니어 이슈를 가져와서 클라우드 코드가 바로 작업하게 할 수 있다. 정말 워크플로우가 개선된다.
리니어 MCP를 연결한 후에는 "가장 최근 리니어 이슈가 뭐야?"라고 물어보기만 하면 된다. 더 빠른 방법은 리니어에서 직접 최신 이슈를 가져오는 것이다.
한 가지 아쉬운 점은 클라우드 코드가 이런 작은 작업들에서는 좀 느리다는 것이다. 그래서 클라우드 코드는 에이전트 역할을 하면서 더 큰 작업들을 처리할 때 진가를 발휘하는 것 같다.
실전 프로젝트: 연락처 폼 개선하기
Builder Methods 웹사이트 작업을 예로 들어보자. 하단에 연락처 폼이 있는데 이름, 이메일, 제목, 메시지 필드가 있다. 이메일과 제목 사이에 드롭다운 선택 필드를 추가하고 싶었다. AI 코칭, 스폰서십, 또는 AI 구축 강의 중 어떤 것에 대한 문의인지 알고 싶었기 때문이다.
또한 연락 메시지가 전송될 때 받는 메일러도 업데이트해서 이 정보가 포함되도록 하고 싶었다. 여러 파일이 관련된 작업이지만 그리 큰 작업은 아니었다.
작업하는 동안 `CLAUDE.md` 파일을 보여주고 싶다. 이건 커서 룰과 비슷한 클라우드의 메모리 같은 것이다. 작업할 때마다 이 노트들을 참조할 수 있다. 리니어 MCP 지시사항을 어떻게 처리할지에 대한 지침도 추가했다. 리니어 이슈에서 나온 작업을 시작할 때 이슈 상태를 '진행 중'으로 바꾸고, 완료되면 이슈에 댓글을 달고, '진행 중'에서 '검토 중'으로 상태를 바꾸는 것 같은 조직적인 작업들이다.
자동화된 작업 흐름의 장점
가끔 권한을 요청하는 창이 뜨는데, `Shift + Tab`을 눌러서 자동 편집 승인을 켤 수 있다. 이렇게 하면 특정 요청에 대한 권한을 부여한다. 이런 권한들은 모두 클라우드 설정에 저장된다.
이게 클라우드 코드로 에이전트와 작업할 때의 차이점 중 하나다. 실제로 여러 파일에 걸쳐 많은 변경사항을 만들도록 할 수 있다. 개별 파일을 하나하나 승인할 필요가 없다. 반면 커서에서는 여러 파일을 편집할 때도 여전히 모든 파일 편집을 검토하고 승인해야 한다. 때로는 좋고, 때로는 클라우드 코드처럼 좀 더 손을 떼고 있는 방식을 선호한다.
작업이 완료되면 `CLAUDE.md` 파일에 추가한 지시사항에 따라 유리 깨지는 소리가 난다. 작업이 끝났다는 걸 알려주는 것이다. 에이전트가 뭔가 작업하고 있을 때 다른 앱에서 작업하고 있어도 오디오로 알려준다. 커서에도 이런 기능이 내장되어 있어서 정말 좋다.
프로젝트 관리 통합의 위력
작업이 끝나고 리니어를 확인해보니 정말 놀라웠다. 리니어 설명에 넣어둔 체크리스트 항목들을 실제로 체크했다. 댓글도 달았는데, 나에게서 온 것처럼 보이지만 실제로는 통합을 통한 클라우드 코드에서 온 것이다. 만든 모든 변경사항들을 나열해놨다. 마지막으로 상태도 '진행 중'에서 '검토 중'으로 바꿨다. 정확히 요청한 대로다.
앱을 확인해보니 선택 드롭다운이 제대로 추가되었다. 스타일링은 좀 더 선택창처럼 보이도록 수정해야 하지만, 원하는 옵션들이 다 있다. 테스트해보니 연락 메시지가 전송될 때 받는 메일러에도 이 정보가 제대로 포함되었다.
커스텀 슬래시 명령어의 활용
클라우드 코드를 정말 강력하게 만드는 또 다른 기능은 커스텀 슬래시 명령어다. 터미널 인터페이스이고 슬래시 키를 사용해서 기능에 접근하는 방식이다.
`/git-commit` 같은 커스텀 명령어를 만들 수 있다. 커스텀 슬래시 명령어들은 클라우드 폴더 안의 commands 폴더에 저장된다. 예를 들어 git commit용으로 하나 만들었는데, 마크다운 파일로 되어 있고 커밋 메시지를 어떻게 만들고 싶은지에 대한 정말 자세한 설명이 들어있다. 좋은 커밋 메시지 예시, 나쁜 커밋 메시지 예시 등 모든 것이 포함되어 있다.
클라우드 코드에 변경사항을 커밋하라고 할 때마다 이 모든 지시사항을 다시 쓸 필요가 없다. 이런 커스텀 명령어들은 계속 재사용할 수 있는 저장된 명령어 모음 같은 것이다. 클라우드 코드를 더 많이 쓸수록 이런 커스텀 명령어 라이브러리를 더 크게 키울 수 있다.
GitHub Actions 통합과 미래 전망
아직 쓰고 있지는 않지만 흥미로운 기능이 GitHub Actions 통합이다. GitHub에서 클라우드를 멘션하고 PR을 검토하거나 작업을 요청하면 GitHub Actions를 통해 그 작업을 수행한다.
이게 정말 흥미로운 점이다. 클라우드 코드를 터미널에서 쓰는 것이 코드를 직접 다루는 것에서 한 걸음 멀어지는 것이라면, GitHub Actions를 통해 클라우드 코드와 상호작용하는 것은 터미널에서도 한 걸음 더 멀어지는 것이다. 이제 말 그대로 원격 에이전트에게 작업을 위임하고, 그것이 가서 작업을 완료하는 것이다. 우리 로컬 환경에서 일어나는 것도 아니다.
이것이 바로 에이전트들이 우리를 위해 일하는 세상으로 나아가고 있다는 주제다. 디자이너, 개발자, 아키텍트로서 우리의 일은 에이전트 자체를 엔지니어링하는 것이다.
인터페이스와 성능: 언제 무엇을 써야 할까
보리스와의 인터뷰에서 흥미로운 부분이 있었다. "손으로 코드를 쓰는 것에 익숙하다면, 이제 업계는 코드를 작성하는 에이전트를 조율하는 방향으로 바뀌고 있다고 생각한다. 코드를 손으로 쓰는 것보다는 코드를 검토하는 것에 더 가깝다."
방향적으로는 맞다. 손으로 코드를 쓰는 것에서 에이전틱 코딩으로 가고 있다. 하지만 여전히 더 직접적으로 관여하고 싶은 상황들이 있다. AI와 함께 일하더라도 말이다.
내 프로젝트 코드의 대략 80%는 이제 내가 직접 타이핑한 게 아니라 AI가 작성한다. 하지만 AI 에이전트와 상호작용하는 방식은 작업에 따라 다르다.
여전히 커서의 인터페이스를 선호하는 상황들이 많다. AI와 적극적으로 협업해서 기능을 설계하고 만들고 완성할 때 특히 그렇다. 특히 프론트엔드 디자인 작업에서 Tailwind CSS를 쓰고, 브라우저를 확인하고, 조정하고, 픽셀 퍼펙트하게 만들 때는 더욱 그렇다.
커서의 에이전트 인터페이스를 페어 프로그래머 같다고 생각한다. 특정 로직 영역에 집중해서 시스템이 정확해질 때까지 개별 코드 라인을 승인하거나 거부할 수 있다. 클라우드 코드는 이런 세밀한 수준의 직접적인 협업에는 별로 좋지 않다.
하지만 클라우드 코드가 정말 빛나는 상황들이 있다. 코드베이스의 여러 파일에 걸친 큰 작업, 많은 기초 작업이 필요한 경우다. 클라우드 코드는 잘 계획되고 잘 범위가 정해진 작업들을 체계적으로 실행하는 데 정말 뛰어나다.
플랜 모드: 성공의 핵심
클라우드 코드가 얼마나 뛰어난지는 실행하라고 요청하는 계획에 달려있다. 그래서 플랜 모드에 대해 이야기해보자.
보리스가 플랜 모드가 왜 클라우드 코드 제품의 핵심 부분이 되었는지에 대해 한 말이 인상적이었다. "파워유저들에게서 본 가장 큰 것은 클라우드에게 코딩을 시작하기 전에 계획을 세우라고 요청하는 것이다. 사람들이 클라우드 코드를 처음 쓸 때 하는 일은 '이 정말 크고 복잡한 기능을 작성해줘'라고 하는 것이다. 그러면 마음속으로 상상한 방식대로 하지 않을 때 좌절한다. 원하는 것과 클라우드가 하려는 것을 맞추는 정말 좋은 방법은 먼저 계획을 세우고 검토받는 것이다."
며칠 전에 Anthropic 팀이 클라우드 코드에서 플랜 모드 기능을 발표했다. `Shift + Tab`으로 접근할 수 있고, 자동 편집 승인과 플랜 모드 사이를 토글할 수 있다.
실제 프로젝트 계획: AI 학습 강의 설문조사
Builder Methods에서 AI 구축 강의들을 출시할 예정이다. '적시 AI 학습 강의'라고 부른다. 네 개 강의가 사전 출시 모드에 있고, 각각 다른 대기자 명단이 있다.
누군가 이메일을 입력하고 대기자 명단에 가입하면, 현재는 "가입되었습니다"라고만 나오는 페이지로 간다. 하지만 이것들이 예정된 강의들이니까 피드백을 수집하고 주요 질문들이 뭔지 이해해서 강의를 최대한 유용하고 도움이 되게 만들고 싶다.
설문조사 폼을 만들고 싶은데, 네 개 강의 모두에 대한 설문조사가 있어야 하고, 각 구독자가 어떤 강의에 관심있는지 파악하고, 강의별로 특화된 질문들을 해야 한다.
이 기능을 리니어 이슈로 작성했다. AI의 도움을 받을 수도 있었지만, 그냥 머릿속의 기본 기능을 정리한 것이다. 리니어 MCP 통합이 연결되어 있으니 그 이슈를 가져와서 "이 이슈를 계획해줘"라고 했다.
계획을 세우는 동안 "think hard" 키워드에 대해 말하고 싶다. 프롬프트에서 "이 이슈를 검토하고 계획을 세우는데 think hard해줘"라고 할 수 있다. 이 키워드는 클라우드 코드가 좀 더 시간을 들여서 생각하고 분석하고 더 합리적인 응답을 하도록 한다. "think harder"나 "ultra think"라고 할 수도 있고, 각각 작업에 투입할 리소스와 시간 수준을 높인다.
현재 클라우드 오푸스 모델을 쓰고 있는데, 이게 최고 중의 최고다. 물론 비싸지만 맥스 플랜을 쓰고 있어서 지금으로서는 클라우드 코드 작업에 최고의 거래다.
계획 검토와 실행
클라우드가 분석하고 계획을 세우는 걸 기다렸더니 계획이 나왔다. 계획 단계는 프로세스의 핵심 부분이고 모범 사례다. Anthropic 팀이 이것을 일급 기능으로 설계한 이유다. 테두리로 강조해서 클라우드 코드로 성공하려면 계획 단계에 시간을 들이고 노력을 앞당겨 투입하는 것이라고 정말 강조하고 있다.
계획을 검토해보니 이미 있는 것들을 설명하고 있어서 클라우드에게 계획을 명확히 하고 싶었다. 백엔드에서 이런 폼들을 구현하는 데 집중하라고 했다.
업데이트된 구현 계획이 나왔는데, 번호와 불릿 포인트로 정말 잘 정리되어 있었다. 모든 걸 검토해보니 정확히 구현하고 싶은 방식이었다. 그래서 진행하기로 했다.
클라우드가 작업하면서 많은 변경사항을 만들고 있다. 클라우드가 자체 할 일 목록을 만들고 진행하면서 항목들을 체크해나가는 게 정말 좋다.
멀티태스킹의 한계와 해결책
클라우드 코드로 작업할 때 좀 어려운 점이 멀티태스킹이다. 클라우드 코드는 자율적인 에이전트로서 큰 작업들을 혼자 처리하는 데 최적화되어 있다. 다른 터미널 탭에서 두 번째, 세 번째 클라우드 코드 인스턴스를 열 수는 있지만, 모두 같은 Git 브랜치에서 작업하게 된다. 당연히 코드 충돌 위험이 있다.
작업들이 코드베이스의 완전히 분리된 부분에서 작업하지 않는 한 말이다. 그런 경우는 드물다. 또한 클라우드가 작업하는 동안 코드베이스의 다른 부분에서 작업할 수 없다는 것도 좌절스럽다. 같은 이유로 충돌이 날 수 있기 때문이다.
Git work trees를 사용한 적절한 멀티태스킹 워크플로우가 있긴 하다. 좀 더 복잡하고 아직 워크플로우를 완전히 정리하는 중이다. 정리되면 클라우드 코드에서의 멀티태스킹에 대한 다른 영상을 올릴 예정이다. 커서처럼 능동적인 에이전트가 아니라 자율적인 에이전트로서 정말 강력한 사용 사례가 될 것 같다.
결과 검토와 개선점
작업이 완료되고 페이지를 새로고침해서 테스트해봤다. 새로운 설문조사 폼이 보였다. 요청하지 않은 추가 스타일링을 좀 넣었다. 클라우드 메모리 파일에 더 구체적인 지시사항을 추가해서 정확히 원하는 것과 원하지 않는 것을 명시해야겠다.
이게 바로 이런 에이전트들과 작업하는 프로세스다. 함께 작업하면서 수정하고 싶은 영역들을 찾고, 시스템에, 지시사항에 반영하는 것이다. 커서 룰이든 클라우드 MD 파일이든 말이다. 이게 바로 에이전트를 엔지니어링한다는 의미다.
전반적으로는 좋아 보였다. 테스트해보니 첫 번째 단계에서 이메일 주소를 잘 전달했다. 이전에는 없던 로직을 추가한 것이다.
하지만 한 가지 눈에 띈 게 있었다. 설문조사 폼을 제출했는데 그 제출 내용이 어디로 갔을까? 연락처 폼에서는 설문조사 정보가 담긴 이메일을 받는다.
클라우드가 컨트롤러의 설문조사 제출 액션에 주석을 달아놨다. "여기서 보통은 설문조사 데이터를 데이터베이스에 저장할 것입니다. 지금은 성공 페이지로 리다이렉트만 하겠습니다."라고 되어 있다. 기능을 완전히 완성하지 않은 것이다.
하지만 이건 클라우드 코드의 잘못이 아니다. 내 잘못이다. 계획에 그 세부사항을 포함하지 않았고, 계획을 검토할 때도 놓쳤다. 연락처 폼과 같은 방식으로 설문조사 응답을 보내야 한다고 가정할 거라고 생각했다. 하지만 이런 세부사항들을 가정할 수는 없다.
클라우드 코드든 다른 에이전트든, 주어진 작업을 수행하는 데는 극도로 뛰어나다. 하지만 정확히 무엇을 하고 싶은지 정말 명시적으로 말해야 한다. 이런 세부사항들을 자연스럽게 이해할 거라고 가정할 수는 없다. 정말 좋은 교훈이었다.
업계 모범 사례: 계획 우선 개발
패턴이 보이기 시작할 것이다. AI에게 기능을 구축하거나 작업을 실행하거나 대형 프로젝트에서 여러 작업을 수행하라고 요청하기 전에 계획을 세우는 것이 빠르게 업계 모범 사례가 되고 있다. 클라우드 코드든, 커서든, 윈서프든 다른 어떤 도구를 쓰든 상관없이 말이다. 미리 계획을 세우고 단계별로 실행하는 것이다.
그래서 PRD(프로젝트 요구사항 문서) 개발이 오늘날 전문가들이 AI로 구축하는 방식이다. 이것이 "바이브 코딩이 프로가 되는 방법"에 대한 다른 영상의 주제이기도 하다.
결론적으로, 클라우드 코드와 커서는 각각 다른 강점을 가지고 있다. 클라우드 코드는 큰 작업을 자율적으로 처리하는 데 뛰어나고, 커서는 세밀한 협업과 실시간 코드 검토에 더 적합하다. 둘 다 현대 AI 기반 개발 워크플로우에서 중요한 역할을 한다. 핵심은 각 도구의 특성을 이해하고 상황에 맞게 적절히 활용하는 것이다.