Cloud Agents와 모바일에서 일 시작하기

노트북을 닫아도 일이 계속되는 순간

솔로 메이커에게 가장 부족한 자원은 시간이 아니라 "이어지는 시간"입니다. 오전에는 고객 문의를 보고, 점심에는 결제 오류를 확인하고, 오후에는 새 기능을 만들다가, 밤에는 배포 로그를 들여다봅니다. 회사라면 프론트엔드 개발자, 백엔드 개발자, QA, PM이 나눠 가질 일을 혼자서 모두 붙잡고 있는 셈입니다.

그래서 Cursor의 Cloud Agents는 단순히 "클라우드에서 돌아가는 AI"가 아닙니다. 이것은 솔로 메이커에게 잠깐의 빈 시간을 작업 시작 시간으로 바꿔주는 장치입니다. 지하철에서 이슈를 보고, 카페에서 모바일로 작업을 걸어두고, 집에 돌아와 데스크톱에서 diff를 확인합니다. 예전에는 노트북 앞에 앉아야 일이 시작됐지만, 이제는 노트북 앞에 앉기 전에도 일이 시작될 수 있습니다.

Cursor는 웹과 모바일에서도 Agent를 사용할 수 있게 하면서, 버그 수정, 새 기능 초안 작성, 코드베이스 질문 같은 작업을 백그라운드에서 실행할 수 있다고 설명합니다. 웹에서는 cursor.com/agents로 접근하고, 모바일에서는 PWA로 설치해 앱처럼 사용할 수도 있습니다.¹ 중요한 변화는 "모바일에서 코딩한다"가 아닙니다. 더 정확히 말하면 "모바일에서 작업을 시작하고, 데스크톱에서 판단한다"입니다.

이 장에서는 로컬 Agent와 Cloud Agent를 어떻게 구분해 써야 하는지, 모바일·웹·Slack·GitHub·Linear에서 시작된 일을 Agents Window에서 어떻게 모아보는지, 그리고 클라우드 Agent가 만든 결과물을 안전하게 내 제품에 가져오는 절차를 다룹니다.

로컬 Agent와 Cloud Agent는 무엇이 다른가

로컬 Agent는 지금 내 컴퓨터에서 일하는 동료에 가깝습니다. Cursor 에디터 안에서 프로젝트 파일을 읽고, 터미널을 실행하고, 내가 보고 있는 맥락에 맞춰 코드를 고칩니다. 응답을 보면서 중간에 방향을 바꿀 수 있고, 실시간으로 "아니, 그 방식 말고 이 파일부터 봐줘"라고 말하기 쉽습니다. 즉각적인 상호작용이 장점입니다.

Cloud Agent는 독립된 작업자에 가깝습니다. Cursor의 클라우드 환경에서 저장소를 가져오고, 별도의 실행 환경에서 의존성을 설치하고, 코드를 수정하고, 테스트를 돌리고, 완료되면 변경 사항과 PR을 남깁니다. 공식 문서에서 Agents Window는 로컬, 클라우드, Remote SSH 등 여러 환경의 에이전트를 한 작업 공간에서 관리하는 인터페이스로 설명됩니다.² 여기서 핵심은 실행 위치가 달라진다는 점입니다. 로컬 Agent는 내 책상 위에서 일하고, Cloud Agent는 밖에 마련된 작은 작업실에서 일합니다.

이 차이는 생각보다 큽니다. 로컬 Agent는 내 개발 환경을 그대로 씁니다. 이미 로그인된 로컬 서비스, 열려 있는 파일, 방금 만든 임시 변경 사항을 활용하기 쉽습니다. 대신 오래 걸리는 작업을 맡기면 내 컴퓨터의 CPU와 메모리를 쓰고, 노트북을 닫으면 작업 흐름이 끊길 수 있습니다.

반대로 Cloud Agent는 내 컴퓨터를 점유하지 않습니다. 노트북을 덮어도 작업이 계속됩니다. 여러 개의 독립적인 작업을 동시에 맡기기도 쉽습니다. 다만 코드를 클라우드 환경으로 보내야 하므로 보안과 비용을 고려해야 하고, 중간중간 손으로 운전하듯 개입하는 작업에는 덜 적합합니다.

그래서 기준은 간단합니다. 함께 앉아 토론해야 하는 일은 로컬 Agent에게, 지시서를 주고 맡길 수 있는 일은 Cloud Agent에게 보냅니다.

장시간 작업은 클라우드로 넘긴다

Cloud Agent를 써야 하는 대표적인 순간은 "기다림이 긴 작업"입니다. 예를 들어 테스트를 대량으로 추가해야 하거나, UI의 작은 버그를 여러 화면에서 확인해야 하거나, 문서 전체의 깨진 링크를 점검해야 하는 일입니다. 이런 작업은 어렵다기보다 오래 걸립니다. 솔로 메이커가 직접 붙잡고 있으면 하루가 순식간에 사라집니다.

반대로 제품의 핵심 아키텍처를 바꾸거나, 결제 흐름을 새로 설계하거나, 데이터 모델을 크게 바꾸는 일은 Cloud Agent에게 통째로 던지기보다 로컬에서 대화하며 진행하는 편이 안전합니다. 이런 작업은 코드 작성보다 판단이 더 중요하기 때문입니다.

Cloud Agent에게 적합한 작업은 보통 다음 조건을 가집니다.

• 목표가 명확하다.

• 변경 범위가 어느 정도 예측된다.

• 테스트나 화면 확인처럼 검증 방법이 있다.

• 실패해도 제품 전체가 위험해지지 않는다.

• PR 단위로 리뷰하고 버릴 수 있다.

예를 들어 "관리자 페이지의 사용자 목록에 검색 입력창을 추가하고, 이름과 이메일 기준으로 필터링되게 해줘. 기존 테이블 컴포넌트를 재사용하고, 관련 테스트를 추가해줘"는 좋은 Cloud Agent 작업입니다. 반면 "우리 SaaS를 더 빠르게 만들어줘"는 나쁜 작업입니다. 느린 원인이 DB인지, API인지, 프론트 렌더링인지, 캐시 정책인지 모호하기 때문입니다.

Cloud Agent는 모호함을 싫어합니다. 더 정확히 말하면 모호한 지시도 처리하려고 하지만, 그 과정에서 비용과 시간이 늘고 결과의 품질이 흔들립니다. 솔로 메이커의 목표는 AI를 오래 일하게 만드는 것이 아니라, 짧고 독립적인 승리를 여러 번 만드는 것입니다.

좋은 지시는 이렇게 생겼습니다.

repo: my-saas/web
base branch: main

작업:
/settings/billing 페이지의 결제 수단 카드에서 카드 만료일이 30일 이내이면 경고 배지를 보여줘.

조건:
- 기존 Badge 컴포넌트를 사용해줘.
- 날짜 계산 유틸은 src/lib/date.ts에 추가해줘.
- 만료 30일 이내, 이미 만료됨, 정상 상태를 각각 테스트해줘.
- UI 변경 결과를 스크린샷으로 남겨줘.

여기에는 파일 위치, UI 위치, 재사용할 컴포넌트, 검증 조건, 결과물 형식이 들어 있습니다. 이 정도면 Cloud Agent는 혼자 움직일 수 있습니다.

시작점은 하나가 아니다

Cursor의 에이전트 시대에서 흥미로운 점은 작업 시작점이 IDE 하나로 고정되지 않는다는 것입니다. 웹에서 시작할 수도 있고, 모바일 브라우저에서 시작할 수도 있고, Slack 대화에서 호출할 수도 있고, GitHub 이슈나 Linear 티켓에서 시작할 수도 있습니다.

웹과 모바일의 역할은 "작업 지시 센터"에 가깝습니다. 긴 코드를 읽고 정교하게 편집하는 곳이라기보다, 지금 떠오른 일을 잊기 전에 에이전트에게 넘기는 곳입니다. Cursor는 웹·모바일 Agent에서 이미지를 첨부하거나 후속 지시를 추가하고, 여러 에이전트를 병렬로 실행해 결과를 비교할 수 있다고 소개합니다.¹

Slack은 대화에서 작업으로 넘어가는 다리입니다. Cursor의 Slack 통합은 @Cursor 멘션으로 Background Agent를 실행할 수 있고, 에이전트가 Slack 스레드의 문맥을 읽은 뒤 GitHub에 PR을 만들 수 있다고 설명합니다.³ 예를 들어 고객 지원 채널에서 이런 대화가 오갔다고 해봅시다.

나: 방금 고객이 비밀번호 재설정 메일을 못 받는다고 함.
나: 로그를 보니 resendPasswordEmail에서 provider timeout 발생.
나: 실패 시 재시도 로직이 없는 것 같음.
나: @Cursor 이 스레드 내용을 바탕으로 재시도 로직 추가하고 테스트까지 만들어줘.

이때 중요한 것은 Slack이 코딩 도구가 된다는 뜻이 아닙니다. Slack은 문제의 맥락이 처음 발생한 장소입니다. 그 맥락을 복사해서 IDE로 가져가는 대신, 그 자리에서 에이전트를 부를 수 있다는 점이 강력합니다.

GitHub는 이슈와 PR 중심의 시작점입니다. 버그 이슈에 @cursor를 호출해 수정 작업을 맡기거나, PR 리뷰 코멘트에서 "이 부분 테스트 추가해줘"라고 지시하는 식입니다. Linear는 제품 작업 관리와 더 잘 맞습니다. Linear의 Cursor 통합은 이슈를 Cursor에 할당하면 클라우드 에이전트가 해당 이슈의 내용을 바탕으로 작업을 시작하고, 진행 상황과 PR 결과를 Linear, Cursor 웹 앱, IDE에서 추적할 수 있다고 설명합니다.⁴

솔로 메이커에게 이것은 꽤 현실적인 장점입니다. 당신이 혼자 일하더라도 문제는 여러 곳에서 들어옵니다. 고객 문의는 이메일에서 오고, 버그는 Sentry나 Slack에서 발견되고, 기능 아이디어는 Linear나 GitHub Issue에 적어둡니다. Cursor의 Cloud Agent 워크플로우는 이 흩어진 시작점을 하나의 작업 흐름으로 묶습니다.

Agents Window는 관제탑이다

여러 곳에서 에이전트를 실행하기 시작하면 곧 새로운 문제가 생깁니다. "내가 뭘 시켜놨지?"라는 문제입니다. 모바일에서 하나, Slack에서 하나, GitHub에서 하나를 실행했다면 작업은 늘었지만 머릿속은 더 복잡해질 수 있습니다.

이때 Agents Window가 관제탑 역할을 합니다. 공식 문서에 따르면 Agents Window는 여러 저장소와 실행 환경에 걸친 에이전트를 관리하는 agent-first 인터페이스입니다.² 쉽게 말해, 지금 뛰고 있는 에이전트들을 한 화면에서 보는 곳입니다.

Agents Window를 열면 작업 중인 Agent, 리뷰가 필요한 Agent, 완료되었거나 실패한 Agent를 흐름에 따라 확인할 수 있습니다. 로컬에서 시작한 작업과 클라우드에서 시작한 작업이 분리된 세계에 있는 것이 아니라, 하나의 목록 안에 들어옵니다. Slack에서 시작했든, 웹에서 시작했든, Linear에서 시작했든, 결국 당신은 Agents Window에서 상태를 확인하고 다음 결정을 내립니다.

여기서 솔로 메이커의 운영 감각이 필요합니다. 에이전트를 많이 실행하는 것보다 중요한 것은 "리뷰 가능한 양만 실행하는 것"입니다. Cloud Agent가 다섯 개의 PR을 만들어도, 당신이 검토할 수 없다면 병목은 그대로입니다. 코드를 쓰는 병목이 코드 리뷰 병목으로 바뀐 것뿐입니다.

처음에는 동시에 두 개까지만 실행해보는 것을 권합니다. 하나는 버그 수정, 하나는 테스트 추가처럼 성격이 다른 작업이면 좋습니다. 결과물을 비교하면서 어떤 종류의 지시가 잘 먹히는지 감을 잡을 수 있습니다. 이후에 익숙해지면 문서 업데이트, 테스트 보강, 작은 UI 수정처럼 위험이 낮은 작업을 병렬로 늘려가면 됩니다.

로컬에서 시작한 일을 클라우드로 넘기기

하루 중 가장 흔한 장면을 떠올려봅시다. 당신은 로컬 Cursor에서 새 기능을 만들고 있습니다. 어느 정도 방향은 잡혔지만, 아직 테스트가 부족합니다. 동시에 관련 문서도 업데이트해야 합니다. 그런데 곧 외출해야 합니다.

이때 모든 것을 멈출 필요는 없습니다. 로컬에서 Agent와 함께 계획을 잡고, 독립적으로 처리 가능한 후속 작업을 Cloud Agent로 넘기면 됩니다.

흐름은 이렇습니다. 먼저 로컬에서 현재 상태를 정리합니다. 변경 사항을 커밋하거나, 최소한 작업 브랜치를 깨끗하게 만들어둡니다. 그다음 Cloud Agent에게 넘길 작업을 별도로 정의합니다. "지금 만든 기능을 완성해줘"가 아니라 "이 브랜치 기준으로 누락된 테스트를 추가해줘"처럼 구체적으로 나눕니다.

예를 들어 로컬에서 결제 내역 다운로드 기능을 만들고 있었다면, Cloud Agent에게는 이렇게 맡길 수 있습니다.

현재 billing-export 브랜치를 기준으로 작업해줘.

목표:
결제 내역 CSV 다운로드 기능에 대한 테스트를 추가해줘.

확인할 것:
- 결제 내역이 없을 때 빈 CSV 헤더만 내려가는지
- 날짜 범위를 지정했을 때 해당 범위만 포함되는지
- 권한 없는 사용자가 접근하면 403이 반환되는지

주의:
구현 코드는 크게 바꾸지 말고, 테스트 실패를 해결하는 데 필요한 최소 수정만 해줘.

이런 지시의 장점은 명확합니다. Cloud Agent가 해야 할 일이 "기능 설계"가 아니라 "검증 보강"입니다. 외출 중에는 이런 작업이 좋습니다. 결과가 마음에 들지 않으면 PR을 닫으면 되고, 마음에 들면 로컬로 가져와 마지막 확인을 하면 됩니다.

모바일에서는 코드를 쓰지 말고 일을 건다

모바일에서 Cursor를 쓸 때 가장 조심해야 할 함정은, 작은 화면에서 큰 결정을 내리려는 욕심입니다. 휴대폰으로 diff를 훑어볼 수는 있지만, 복잡한 변경을 정확히 리뷰하기는 어렵습니다. 특히 인증, 결제, 데이터 삭제, 권한 처리처럼 실수 비용이 큰 코드는 모바일에서 병합하지 않는 편이 좋습니다.

모바일에서 할 일은 네 가지 정도로 제한하는 것이 안전합니다.

• 새 작업을 시작한다.

• 진행 상태를 확인한다.

• 실패한 작업에 추가 맥락을 준다.

• 완료된 작업을 나중에 검토할 목록에 올린다.

예를 들어 출근길에 고객이 보낸 스크린샷을 보고 UI 깨짐을 발견했다면, 모바일에서 바로 Cloud Agent를 시작할 수 있습니다.

모바일 Safari에서 /pricing 페이지의 Pro 플랜 카드 CTA 버튼이 줄바꿈되며 깨진다.
첨부한 스크린샷을 참고해서 원인을 찾고 수정해줘.
반응형 기준으로 375px, 768px, 1280px 화면에서 확인해줘.
변경 후 스크린샷을 남겨줘.

이것은 모바일에 적합한 요청입니다. 문제 상황이 분명하고, 화면 크기라는 검증 기준도 있습니다. 하지만 Agent가 만든 PR을 그 자리에서 병합하는 것은 별개의 문제입니다. 병합은 데스크톱에서 해야 합니다. 가능하면 로컬에서 브랜치를 내려받아 실행하고, 최소한 핵심 화면과 테스트를 확인한 뒤 머지해야 합니다.

모바일은 운전석이 아니라 출발 버튼입니다. 이 구분을 지키면 이동 중에도 생산성을 얻으면서, 제품 안정성은 잃지 않을 수 있습니다.

Slack, GitHub, Linear에서 시작하는 실제 패턴

Slack에서 시작하는 작업은 "대화가 곧 명세"일 때 좋습니다. 버그 리포트가 스레드에 쌓였고, 누군가 재현 조건을 적었고, 로그 일부가 공유됐다면 굳이 새 문서로 옮기지 않아도 됩니다. 다만 마지막 지시에는 반드시 작업 범위를 다시 못 박아야 합니다.

@Cursor 이 스레드의 로그인 실패 문제를 수정해줘.
범위는 web 앱의 로그인 폼과 auth callback 처리로 제한해줘.
수정 후 관련 단위 테스트를 추가하고 PR을 만들어줘.

GitHub에서 시작하는 작업은 "이슈가 잘 정리되어 있을 때" 좋습니다. 재현 절차, 기대 결과, 실제 결과가 있는 이슈라면 Cloud Agent가 읽고 움직이기 쉽습니다. 이때 이슈 본문에 체크리스트를 써두면 더 좋습니다.

@cursor 이 이슈를 해결해줘.
완료 조건:
- 재현 케이스를 테스트로 추가
- 원인 수정
- 기존 API 응답 형식 유지
- PR 설명에 원인과 수정 방식을 요약

Linear에서 시작하는 작업은 "제품 백로그를 바로 실행으로 연결하고 싶을 때" 좋습니다. Linear 통합은 이슈를 Cursor에 할당하거나 코멘트에서 호출하면 Cloud Agent가 이슈 맥락을 바탕으로 작업하고, 완료 후 PR 정보를 이슈에 남기는 방식으로 동작합니다.⁴ 솔로 메이커라면 Linear의 이슈를 작게 쪼개두는 것만으로도 에이전트에게 줄 일감 목록이 됩니다.

다만 어느 도구에서 시작하든 원칙은 같습니다. 작업은 작게, 완료 조건은 명확하게, 병합은 신중하게. 에이전트가 시작점을 자유롭게 만들어줄수록, 사람은 종료 조건을 더 엄격하게 관리해야 합니다.

결과물 검토: 데모, 스크린샷, diff, 그리고 로컬 테스트

Cloud Agent의 결과를 받을 때 가장 먼저 볼 것은 코드가 아닐 수도 있습니다. UI 작업이라면 스크린샷이나 데모가 먼저입니다. Cursor 3 관련 자료에서는 Cloud Agent가 작업 결과를 확인할 수 있도록 데모와 스크린샷을 생성하는 흐름이 소개됩니다.⁵ 코드 diff만 보면 정상처럼 보여도, 실제 화면에서는 여백이 무너지거나 버튼이 사라지는 일이 많습니다.

검토 순서는 이렇게 잡으면 안전합니다.

첫째, Agent의 요약을 읽습니다. 무엇을 바꿨다고 주장하는지 확인합니다. 이 요약은 정답지가 아니라 지도입니다. 지도만 믿고 목적지에 도착했다고 생각하면 안 됩니다.

둘째, 데모 영상이나 스크린샷을 봅니다. UI 변경이라면 특히 중요합니다. 로그인 전후, 빈 상태, 에러 상태, 모바일 화면이 포함되어 있는지 확인합니다.

셋째, diff를 봅니다. 변경 파일 수가 예상보다 많다면 멈춰야 합니다. "버튼 줄바꿈 수정"을 맡겼는데 인증 로직과 DB 스키마까지 건드렸다면 좋은 신호가 아닙니다. 의도하지 않은 변경은 과감히 되돌리거나, Agent에게 범위를 줄여 다시 시키는 편이 낫습니다.

넷째, 로컬로 가져와 테스트합니다. PR 브랜치를 체크아웃하고 의존성을 설치한 뒤, 관련 테스트와 전체 타입 체크를 돌립니다. 프론트엔드라면 실제 브라우저에서 핵심 경로를 눌러봅니다. 특히 결제, 회원가입, 로그인, 데이터 삭제처럼 제품의 신뢰를 좌우하는 경로는 반드시 직접 확인합니다.

git fetch origin
git checkout cursor/fix-billing-card-expiry
pnpm install
pnpm test
pnpm typecheck
pnpm dev

다섯째, 필요하면 로컬 Agent에게 리뷰를 시킵니다. "이 PR의 변경 사항을 보안, 회귀 가능성, 불필요한 변경 관점에서 리뷰해줘"라고 요청하면 사람이 놓친 부분을 다시 볼 수 있습니다. 여기서도 최종 판단은 사람의 몫입니다.

안전한 솔로 메이커의 규칙

혼자 일하면 코드 리뷰어도 나 자신이고, 배포 승인자도 나 자신입니다. Cloud Agent는 이 상황에서 강력한 도우미가 되지만, 동시에 실수를 빠르게 확산시키는 도구가 될 수도 있습니다. 그래서 솔로 메이커에게는 몇 가지 운영 규칙이 필요합니다.

첫 번째 규칙은 "모바일에서는 병합하지 않는다"입니다. 예외를 만들고 싶다면 문서 수정이나 오타 수정 정도로 제한하세요. 제품 동작에 영향을 주는 코드는 데스크톱에서 확인한 뒤 병합합니다.

두 번째 규칙은 "Cloud Agent에게 프로덕션 비밀을 주지 않는다"입니다. 필요한 환경변수는 도구가 제공하는 Secret 관리 기능이나 최소 권한의 테스트 키를 사용해야 합니다. API 키를 프롬프트에 직접 붙여넣는 습관은 절대 만들지 않는 편이 좋습니다.

세 번째 규칙은 "작업 단위를 PR 하나로 리뷰 가능한 크기로 유지한다"입니다. PR이 너무 크면 Agent가 잘했는지 못했는지 판단하기 어려워집니다. 리뷰할 수 없는 PR은 병합할 수 없는 PR입니다.

네 번째 규칙은 "배포는 별도의 의식으로 남겨둔다"입니다. Agent가 PR을 만들고 테스트가 통과해도, 배포 버튼은 사람이 누르는 편이 안전합니다. 특히 솔로 메이커의 제품은 작은 장애 하나가 고객 신뢰에 직접 영향을 줍니다.

다섯 번째 규칙은 "실패한 Agent를 억지로 살리지 않는다"입니다. 방향을 잘못 잡은 Agent에게 후속 지시를 계속 붙이면, 엉킨 실을 더 엉키게 만들 수 있습니다. 이럴 때는 작업을 중단하고, 더 작은 범위로 새 Agent를 시작하는 편이 빠릅니다.

클라우드에 맡기기 전 준비해야 할 것

Cloud Agent의 품질은 프롬프트만으로 결정되지 않습니다. 저장소가 얼마나 잘 정리되어 있는지도 큰 영향을 줍니다. Agent는 사람처럼 눈치로 모든 것을 파악하지 못합니다. 프로젝트에 규칙과 실행 방법이 명확할수록 더 잘 일합니다.

먼저 README를 정비하세요. 로컬 실행 방법, 테스트 방법, 주요 디렉터리 구조, 환경변수 설명이 있어야 합니다. 사람에게도 좋은 README는 Agent에게도 좋습니다.

다음으로 .cursor/rules/를 점검하세요. 앞 장에서 다룬 것처럼 이 디렉터리는 Agent에게 주는 작업 규칙입니다. Cloud Agent도 결국 같은 코드베이스 안에서 일하므로, 컴포넌트 작성 방식, API 에러 처리 방식, 테스트 규칙을 명시해두면 결과가 안정됩니다.

그리고 테스트 명령을 단순하게 만들어야 합니다. pnpm test, pnpm typecheck, pnpm lint처럼 한눈에 알 수 있는 명령이 좋습니다. Agent가 검증 루프를 돌릴 수 있어야 스스로 고칠 기회가 생깁니다.

마지막으로 브랜치 전략을 단순하게 유지하세요. 솔로 메이커라면 복잡한 Git flow보다 main과 짧은 feature branch 중심의 흐름이 낫습니다. Cloud Agent가 만든 PR도 같은 기준으로 들어오게 하면 관리가 쉬워집니다.

하루 워크플로우 예시

아침 8시, 출근길에 휴대폰으로 고객 문의를 봅니다. "모바일에서 가격표 버튼이 눌리지 않는다"는 내용입니다. 당신은 Cursor 모바일 웹을 열고 Cloud Agent에게 스크린샷과 함께 작업을 맡깁니다. 조건은 간단합니다. 모바일 Safari 기준으로 재현하고, 원인을 고치고, 스크린샷을 남기라는 것입니다.

오전 10시, 데스크톱 앞에 앉습니다. Agents Window를 열어 밤사이 또는 이동 중 실행한 작업을 확인합니다. 가격표 버튼 수정 PR이 준비되어 있습니다. Agent의 스크린샷을 보고, diff를 확인하고, 로컬로 브랜치를 가져와 실행합니다. 실제 모바일 뷰포트에서 버튼이 눌리는지 확인한 뒤 병합합니다.

점심 전에는 Linear에 쌓인 작은 개선 이슈 두 개를 Cursor에 할당합니다. 하나는 설정 페이지 문구 수정, 하나는 회원 탈퇴 안내 문구 개선입니다. 둘 다 제품 핵심 로직을 건드리지 않는 작업입니다.

오후에는 로컬 Cursor에서 새 기능의 핵심 설계를 직접 진행합니다. 이 일은 Cloud Agent에게 맡기지 않습니다. 중간 판단이 많고, 제품 방향과 연결되어 있기 때문입니다. 대신 기능 뼈대가 잡힌 뒤 테스트 추가와 문서 업데이트를 Cloud Agent에게 넘깁니다.

저녁에는 Slack 알림으로 완료된 PR을 확인하지만 병합하지 않습니다. 제목만 보고 내일 아침 리뷰 목록에 넣습니다. 급하지 않은 일은 다음 날 맑은 정신으로 봅니다. 이것이 솔로 메이커에게 특히 중요합니다. 피곤한 밤의 머지는 다음 날의 장애가 되기 쉽습니다.

에이전트에게 일을 맡긴다는 감각

Cloud Agent와 모바일 워크플로우의 본질은 "언제 어디서나 코딩"이 아닙니다. 작은 화면에서 코드를 더 많이 쓰자는 이야기도 아닙니다. 핵심은 제품 개발의 다음 동작을 지연시키지 않는 것입니다.

예전에는 생각이 떠올라도 노트북 앞에 앉을 때까지 기다려야 했습니다. 기다리는 동안 맥락은 흐려지고, 에너지는 떨어지고, 해야 할 일은 쌓였습니다. 이제는 그 순간에 작업을 시작시킬 수 있습니다. 단, 시작과 완료를 구분해야 합니다.

이동 중에는 계획하고 시작합니다. 클라우드에서는 초안을 만들고 검증 자료를 남깁니다. 데스크톱에서는 리뷰하고 테스트하고 병합합니다. 이 세 단계를 섞지 않는 사람이 Cloud Agent를 오래, 안전하게 쓸 수 있습니다.

솔로 메이커는 혼자 일하지만, 혼자 모든 시간을 채울 필요는 없습니다. Cursor의 Cloud Agents는 당신이 자리를 비운 동안에도 다음 PR의 초안을 만들 수 있습니다. 그러나 제품의 방향, 품질의 기준, 배포의 책임은 여전히 당신에게 있습니다.

좋은 솔로 메이커는 AI에게 모든 것을 맡기지 않습니다. 대신 AI가 잘할 수 있는 일을 끊임없이 찾아내고, 자신은 더 중요한 판단에 시간을 씁니다. Cloud Agent는 그 전환을 가능하게 하는 도구입니다. 노트북 앞에 앉아 있지 않아도 일은 시작될 수 있습니다. 하지만 제품을 세상에 내보내는 마지막 클릭은, 여전히 당신의 손끝에서 이루어져야 합니다.

참고

¹Cursor Agent on web and mobile

²Agents Window | Cursor Docs

³Cursor 1.1 changelog: Background Agents in Slack

⁴Linear Cursor integration

⁵New Cursor 3 ditches the classic IDE layout for an agent-first interface