2026년 7월 17일, Cursor의 Slack 연동 기능에 3가지 큰 업데이트가 적용되었습니다. 모두 "Slack 상에서 Cursor에게 코드를 작성하게 하는" 워크플로우를 보다 실무 운영에 견딜 수 있는 형태로 근접시키는 변경 사항입니다.

• 태스크 시작 전에 플랜을 제시하고, 작업 중에는 상태를 수시로 업데이트
• 단일 리포지토리(Single repository) 전제에서 멀티 리포지토리(Multi-repository) 환경에서의 기동·전환 대응 - 다른 Slack 채널·스레드를 횡단하는 읽기·쓰기 대응

특히 멀티 리포지토리 대응은 프론트엔드(Frontend)·백엔드(Backend)·공유 라이브러리가 리포지토리별로 분리되어 있는 조직에게 있어, Slack으로부터 Cursor를 실무 운영 플로우에 편입시키는 데 있어 큰 장벽 중 하나가 제거된 형태가 됩니다.

📌 영향을 받는 사람

• Slack을 경유하여 Cursor에 개발 태스크를 의뢰하고 있는 팀
• 프론트엔드/백엔드/공유 코드가 리포지토리별로 분할되어 있는 조직
• 여러 채널에 걸쳐 리뷰 의뢰나 진척 공유를 수행하고 있는 팀

이번 업데이트는 "Slack 상에서의 Cursor와의 상호작용"이라는 일련의 경험을 시작 전·실행 중·실행 후의 3가지 페이즈로 개선한 것으로 정리할 수 있습니다.

이 그림과 같이, 이번 변경은 "사전 확인 가능한 플랜 제시", "멀티 리포지토리의 동적인 전환", "채널을 횡단하는 정보의 입출력"이라는 3가지 독립된 개선이 결합되어 Slack 상에서의 Cursor 이용 경험 전체를 끌어올리고 있습니다.

Cursor는 Slack에서 태스크를 시작하기 전에 먼저 작업 계획(Plan)을 답변하게 되었습니다. 실행 전에 플랜이 보임으로써, 의도하지 않은 방향으로 진행되기 전에 사용자가 개입하거나 궤도를 수정할 수 있습니다. 실행 중에도 각 단계의 상태(Status)가 업데이트되므로 진척 상황을 파악하기 쉬워졌습니다.

함께 UI도 쇄신되었습니다.

지금까지 Slack에서 Cursor를 기동할 경우, 단일 기본 리포지토리에 귀속되는 형태였습니다. 이번 업데이트로 이름이 지정된 멀티 리포지토리 환경을 지정하여 기동할 수 있게 되었습니다.

• 프론트엔드·백엔드·공유 코드가 별도 리포지토리로 나뉘어 있는 구성에서도, 요청 내용으로부터 Cursor가 필요한 리포지토리를 모두 포함하는 환경을 자동 선택
• 태스크 도중에 현재 환경에 포함되지 않은 리포지토리가 필요해진 경우, "Switch repository" 버튼이 표시됨
• 리포지토리/환경을 다시 선택하면, Cursor는 중단된 지점부터 작업을 재개함 (처음부터 다시 하지 않음)

Cursor가 태스크 실행 중에 워크스페이스 내의 다른 채널·스레드를 읽고 쓸 수 있게 되었습니다.

• 다른 채널이나 다른 스레드로부터 컨텍스트(Context)를 취득할 수 있음
• 원래의 스레드나 관련 채널에 실행 결과나 업데이트 정보를 게시할 수 있음

예를 들어 "#eng-general에서 상담되었던 사양 변경을 바탕으로, 이 스레드에서 구현해줘"와 같은 의뢰가 채널을 넘나들며 성립하게 되는 이미지입니다. 상세한 설정에 대해서는 Slack docs를 참조해 주세요.

이번 변경은 모두 action_required: false (기존 사용자의 설정 변경은 불필요)이지만, 팀의 운영에 따라서는 재검토하면 좋은 점들이 있습니다.

멀티 리포지토리 구성의 팀: 지금까지 Slack 경유의 Cursor 이용을 "단일 리포지토리의 태스크로 한정"하여 운영해 왔다면, 이 제약이 풀렸으므로 이용 범위를 넓힐 수 있을지 검토할 가치가 있습니다 -
Slack 봇 권한 확인: 크로스 채널에서의 읽기/쓰기에 대응하게 되었으므로, Cursor의 Slack 앱에 부여한 채널 액세스 권한(초대 상황)을 다시 한번 확인해 두면 안심할 수 있습니다 -
플랜 제시를 전제로 한 운영: 실행 전에 플랜이 표시되게 되었으므로, "즉시 실행"을 전제로 한 Slack 워크플로우(자동 승인 스크립트 등)가 있는 경우에는 플랜 확인 단계가 끼어든다는 점을 고려해 주세요

💡 Tips

멀티 리포지토리 환경의 자동 선택은 "요청 내용의 해석"에 의존하기 때문에, 의뢰 메시지 내에서 대상 리포지토리 이름이나 서비스명을 명시하면 환경 선택의 정밀도가 높아지기 쉽습니다.

⚠️ Breaking Change

이번 업데이트에 파괴적 변경 (Breaking Change)은 없습니다. 다만 UI 면에서는 「메시지 내 버튼」이 폐지되고 「푸터 링크 (Footer link)」로 통일되었기 때문에, 버튼 조작을 전제로 한 사내 매뉴얼이나 스크린샷이 포함된 절차서가 있는 경우에는 업데이트가 필요합니다.

이번 변경은 프로덕트 코드의 API 변경이 아니라 Slack 상에서의 대화 흐름 (Flow) 변경이므로, 코드 예시 대신 Slack 상에서의 주고받음 (Interaction)의 Before/After를 보여드립니다.

Before (단일 리포지토리 전제)

User: 프론트의 목록 화면에 페이지네이션 (Pagination)을 추가해줘
Cursor: (기본 리포지토리로만 작업을 시작)
Cursor: 완료했습니다. PR은 이쪽입니다.

After (멀티 리포지토리 대응 + 플랜 제시)

User: 프론트의 목록 화면에 페이지네이션 (Pagination)을 추가하고, API도 함께 업데이트해줘
Cursor: 다음과 같은 플랜 (Plan)으로 진행하겠습니다.
1. backend: 목록 API에 페이지네이션 (Pagination) 파라미터 (Parameter)를 추가
...

2026년 7월 17일의 Cursor Slack 연동 업데이트는 다음 3가지로 요약됩니다.

실행 전에 플랜 (Plan)이 보이게 되어, 중간 경과도 추적하기 쉬워졌습니다 (UI도 푸터 링크 (Footer link)로 쇄신)

멀티 리포지토리 (Multi-repository) 환경에서의 기동 및 태스크 (Task) 도중의 전환에 대응하여, 중단된 지점부터 작업을 재개할 수 있습니다

채널을 넘나드는 컨텍스트 (Context) 취득 및 결과 게시(Posting)에 대응했습니다

모두 즉각적인 설정 변경은 필요하지 않지만, 특히 멀티 리포지토리 (Multi-repository) 구성의 팀에게는 Slack을 경유한 Cursor 활용 범위를 넓힐 수 있는 의미 있는 업데이트입니다. 우선 자신들의 워크플로우 (Workflow)에서 「Switch repository」의 동작이나 플랜 (Plan) 제시 내용을 한 번 테스트해 보시는 것을 추천합니다.

참고로, 변경 로그 (Change log)의 diff 상에서 확인된 2026년 6월 18일 자의 Automations 관련 엔트리 (Entry) 삭제는 변경 로그의 로테이션 (Rotation)에 의한 것이며, 해당 기능의 폐지를 의미하는 것은 아니라는 점을 보충해 둡니다.