Cursor iPad·Inbox: 에이전트가 만든 PR을 이동 중에 닫는 법

클라우드 에이전트가 PR을 만들어 두는 동안, 병목은 더 이상 “코드를 쓰는 손”이 아니라 “머지해도 되는지 판단하는 사람”입니다. 2026년 7월 29일 Cursor가 iPad 앱을 유료 플랜 전체에 열고, iPhone·iPad에 Inbox와 풀 PR 리뷰 화면을 넣은 이유는 여기에 가깝습니다.

한 줄 요약: 모바일 Cursor는 작은 IDE가 아니라, 에이전트 산출물을 검토·승인·머지하는 인간 게이트입니다.

왜 중요한가

에이전트 워크플로가 성숙하면 작업은 비동기로 쌓입니다. 노트북을 덮어도 클라우드 VM 위의 에이전트는 테스트·디모·로그·diff를 남기고 PR을 엽니다. 그런데 팀의 실제 처리량은 “에이전트가 얼마나 빨리 쓰느냐”보다 “사람이 얼마나 빠르게, 그리고 안전하게 리뷰 루프를 닫느냐”에 좌우됩니다.

Jul 29 업데이트의 핵심은 세 가지입니다.

1. Inbox — 진행 중 에이전트, 내 확인이 필요한 항목, 리뷰 중인 PR을 한곳에서 봅니다.
2. 풀 PR 리뷰 — 코멘트·체크·승인까지 모바일에서 다루고, 리뷰어를 바꾸거나 에이전트에게 코멘트 해결을 지시할 수 있습니다.
3. iPad 레이아웃 — 사이드바에 여러 채팅을 고정하고, 리뷰와 채팅을 나란히 두며, 파일 diff를 크게 봅니다.

여기에 Bitbucket·Azure DevOps SCM 지원, 한 채팅에서 열린 여러 PR을 모두 여는 멀티 PR 세션, 앱 안에서의 팀 전환이 붙었습니다. “이동 중에도 에이전트 루프를 닫는다”는 제품 메시지가 기능 목록으로 구체화된 셈입니다.

기존 방식과 비교

중요한 대비는 “모바일에서 코딩한다”가 아닙니다. 공식 도움말도 앱의 역할을 에이전트 지시와 리뷰로 못 박습니다. 편집이 필요하면 데스크톱이나 웹 Agents로 돌아가면 됩니다. 이 구분이 흐려지면 “폰으로 리팩터링” 같은 기대를 심고, 실제로는 리뷰 품질만 떨어집니다.

이전 iOS 앱(6월 29일)이 클라우드 에이전트 실행·Live Activities·푸시·머지를 열었다면, 7월 29일은 리뷰 표면을 풀스택으로 키우고 iPad를 1급 디바이스로 승격한 단계입니다. Conductor식 멀티플레이어 협업 이야기와도 겹치지 않습니다. 오늘은 “혼자, 자리 밖에서, 인간 승인 게이트를 닫는 법”입니다.

실무 체크리스트 예시

팀에 공유할 수 있는 “모바일 머지 게이트” 체크리스트 예시입니다. 저장소 루트에 두고 에이전트·리뷰어가 같은 기준을 보게 하세요.

# .cursor/mobile-merge-gate.yaml
# Human gate for cloud-agent PRs reviewed on Cursor iOS/iPad
version: 1
when: before_merge_from_mobile
require:
  checks: green_or_explicitly_waived
  diff_scope: "single concern; no drive-by refactors"
  secrets: "no new env keys or tokens in diff"
  migrations: "forward-only; rollback note in PR body"
  artifacts: "demo/screenshot/log reviewed when agent attached them"
ask_agent_to_fix_if:
  - "CI failed on a flake you cannot reproduce on mobile"
  - "review comment needs a code change larger than a one-liner"
never_merge_on_mobile_if:
  - "auth, billing, or data-deletion paths changed"
  - "you cannot see the full diff (too large) without desktop"

코드라기보다 운영 계약에 가깝습니다. 모바일 머지의 위험은 타이핑 실수가 아니라, 작은 화면에서 “대충 괜찮아 보임”으로 넘어가는 판단 오류입니다.

실무에서 쓰는 법

실무 루프는 단순하게 잡히는 편이 좋습니다.

1. 데스크톱/웹에서 에이전트를 클라우드로 보냅니다. 장시간 작업은 노트북을 닫아도 이어지게 둡니다.
2. 알림이 오면 Inbox를 엽니다. “진행 중 / 내 확인 필요 / PR 리뷰”를 먼저 분류합니다.
3. 아티팩트 → diff → 체크 → 코멘트 순으로 봅니다. 에이전트가 남긴 데모·스크린샷·로그가 있으면 diff보다 먼저 의 가설을 검증하세요.
4. 한 줄·명확한 수정은 에이전트에게 재지시하고, 구조 변경은 데스크톱으로 넘깁니다.
5. 머지 가능 조건을 충족하면 모바일에서 승인·머지합니다. 조건을 못 채우면 Inbox에 “blocked”로 남기고 이유를 한 줄 적습니다.

처음 Inbox를 켰을 때는 “알림이 오면 바로 머지” 습관이 생겨 위험했습니다. CI가 초록이어도 diff 범위가 넓은 PR을 지하철에서 승인했다가, 돌아와 보니 의도치 않은 설정 파일 변경이 섞여 있던 경험이 있습니다. 그다음부터는 위 체크리스트의 never_merge_on_mobile_if를 먼저 보게 됐습니다.

Bitbucket·Azure DevOps를 쓰는 팀은 Jul 29 이전보다 모바일 경로가 현실적으로 열렸습니다. GitHub만이 에이전트 머지 루프의 전제가 아니라는 점이 실무적으로 큽니다. 한 채팅이 PR을 여러 개 만든 경우에도, 이제는 마지막 PR만 보고 끝내기 어렵습니다 — 멀티 PR 세션으로 전부 열어 확인하세요.

시니어 엔지니어 관점

에이전트 시대의 시니어 역할은 “더 빨리 타이핑하는 사람”이 아니라 품질 게이트를 설계하는 사람으로 이동합니다. 모바일 Inbox는 그 게이트를 주머니에 넣는 도구입니다. 반대로, 게이트 기준이 없으면 Inbox는 그냥 알림 폭주 UI가 됩니다.

권장하는 팀 규칙:

• 모바일 머지 허용 범위를 문서화한다 (위 YAML 수준이면 충분).
• 고위험 경로는 데스크톱 리뷰 필수 + 두 번째 리뷰어.
• 에이전트 재지시 문구를 템플릿화한다 (“이 코멘트만 최소 diff로 고쳐라. 새 리팩터링 금지”).
• Inbox SLA를 둔다 (예: needs attention은 4시간 내 분류 — 머지가 아니라 분류).

또한 “풀 PR 리뷰”가 가능해졌다고 해서 모바일에서 아키텍처 토론을 끝내려 하지 마세요. 코멘트 스레드는 가능하지만, 설계 결정은 기록이 남는 RFC/이슈로 올리는 편이 안전합니다.

Cursor에서 바로 쓰기

Cursor 안에서 오늘 당장 해볼 수 있는 순서입니다.

1. 유료 플랜 계정으로 iPhone/iPad에 Cursor 앱을 설치·로그인합니다 (조직 SSO가 있으면 먼저 웹에서 통과).
2. 데스크톱 Agents Window에서 클라우드 에이전트 실행(또는 Remote Control 핸드오프) 후, 폰에서 동일 세션이 보이는지 확인합니다.
3. Jul 29 이후 빌드에서 Inbox를 열고, 의도적으로 “needs attention” 항목을 만듭니다 (에이전트에 애매한 follow-up을 남겨 보세요).
4. PR 리뷰 화면에서 체크·코멘트·리뷰어 변경을 한 번씩 눌러 권한/SCM 연결을 검증합니다. Bitbucket/ADO 사용 중이면 연결부터 확인합니다.
5. 한 채팅이 PR을 2개 이상 만든 테스트 브랜치로 멀티 PR 세션 UX를 연습합니다.
6. 팀 채널에 “모바일 머지 게이트” YAML을 공유하고, 1주일간 위반 사례만 모아 규칙을 조정합니다.

편집이 필요하면 억지로 모바일에서 끝내지 마세요. diff를 보고 “데스크톱에서 이어서”가 올바른 탈출구입니다.

FAQ

Cursor 모바일 앱으로 코드를 직접 편집할 수 있나요?

공식 도움말 기준으로는 아닙니다. 앱은 에이전트 지시·상태 확인·diff/아티팩트 리뷰·PR 머지에 초점이 있고, 에디터·터미널·파일 브라우저는 제공하지 않습니다.

Inbox와 일반 에이전트 목록은 무엇이 다른가요?

Inbox는 진행 중 작업, 내 확인이 필요한 항목, 리뷰 중 PR처럼 “사람이 손을 대야 하는 큐”를 전면에 둡니다. 단순 세션 목록보다 게이트 운영에 가깝습니다.

iPad는 iPhone 앱을 키운 것뿐인가요?

Jul 29 기준으로 iPad 레이아웃은 여유 공간을 쓰도록 다시 짜였습니다. 사이드바 채팅 고정, 리뷰·채팅 스플릿, 큰 diff가 강조됩니다. “큰 아이폰”이 아니라 리뷰 워크스테이션에 가깝게 설계된 편입니다.

GitHub만 지원하나요?

아니요. Jul 29 변경로그에 Bitbucket과 Azure DevOps SCM 지원이 명시되어 있습니다. 팀 SCM이 GitHub가 아니어도 모바일 리뷰 루프를 열 수 있는 방향입니다.

모든 PR을 모바일에서 머지해도 될까요?

아니요. 인증·결제·데이터 삭제·대형 마이그레이션처럼 회귀 비용이 큰 변경은 데스크톱에서 전체 diff와 로컬 검증을 거친 뒤 머지하는 편이 안전합니다. 모바일은 범위가 좁고 체크가 초록인 에이전트 PR에 특히 잘 맞습니다.

참고 자료

• Cursor, now on iPad (Changelog, 2026-07-29)
• Cursor Changelog index
• Build from anywhere with Cursor for iOS
• Cursor for iOS help
• Cursor Mobile App for iOS (Changelog)

마무리

에이전트가 코드를 대신 쓸수록, 엔지니어의 희소 자원은 집중력 있는 승인이 됩니다. Cursor의 iPad·Inbox·풀 PR 리뷰는 그 승인을 자리 밖으로 옮기되, 제품 스스로 “모바일은 편집기가 아니다”라고 선을 그어 둔 점이 좋습니다. 앞으로 팀 경쟁력은 더 많은 에이전트 실행이 아니라, Inbox를 얼마나 규율 있게 비우느냐로 갈릴 가능성이 큽니다.