Cursor Projects가 바꾸는 일의 단위, 공유 컨텍스트에 완료 조건을 남겨야 하는 이유 | DAKER 커뮤니티

하루를 넘기는 작업에서는 구현 자체보다 인수인계 비용이 더 크게 느껴질 때가 있습니다. 해커톤이나 마이그레이션처럼 며칠에 걸쳐 이어지는 일일수록, 채팅을 새로 열 때마다 배경을 다시 설명하고 직전 결정을 복원하는 과정이 반복되기 쉽습니다.

TechWealth Hub 채널의 Cursor Projects Explained: An AI Agent That Keeps Working는 이 문제를 개별 채팅이 아니라 계속되는 프로젝트의 관점에서 설명합니다. 이 글에서는 영상이 짚는 코디네이터, 공유 컨텍스트, 클라우드 실행의 의미를 정리하고, 바로 적용할 수 있는 완료 조건 한 줄의 중요성을 함께 살펴봅니다.

채팅이 아니라 프로젝트를 이어 가는 방식

영상이 가리키는 변화는 분명합니다. 새 코딩 채팅을 열 때마다 프로젝트를 다시 설명하고, 관련 파일을 다시 가리키고, 이전 에이전트가 무엇을 시도했는지 다시 떠올리는 비용이 생긴다는 점입니다. Cursor Projects는 이 인수인계 문제를 줄이기 위한 구조로 소개됩니다.

여기서 핵심은 코디네이터입니다. 코디네이터는 직접 코드를 쓰기보다 다른 에이전트에게 일을 맡기고 흐름을 조율합니다. 작업 에이전트가 구현을 진행하는 동안에도 코디네이터는 다음 지시를 받을 수 있고, 요구사항이 바뀌어도 같은 프로젝트 스레드 안에서 방향을 조정할 수 있습니다.

중요한 변화는 에이전트를 더 크게 돌리는 일이 아니라, 실행을 맡긴 뒤에도 사람이 같은 프로젝트 안에서 방향을 계속 조정할 수 있다는 점입니다.

이 구조는 하루짜리 대화보다 여러 단계의 작업에 더 잘 맞습니다. 여러 풀 리퀘스트로 이어지는 기능 개발, 마이그레이션, 앱 전반의 유지보수처럼 맥락이 누적되는 일에서는 특히 그렇습니다.

장기 작업일수록 완료 조건이 먼저 필요합니다

영상은 Projects를 한 번의 채팅으로 끝나지 않는 일에 두라고 설명합니다. 라벨 하나를 바꾸는 일보다 인터페이스, 서비스, 테스트가 함께 움직이는 작업 묶음에 더 적합하다는 뜻입니다. 코디네이터가 일을 나눌 수는 있어도, 무엇이 올바른 결과인지는 사람이 먼저 정해야 합니다.

DAKER 해커톤 같은 환경에서도 같은 기준이 도움이 됩니다. 제출 마감이 며칠에 걸쳐 있고, 기획서와 데모, 코드가 함께 움직이는 상황에서는 날짜마다 새 채팅을 여는 방식이 오히려 인수인계 비용을 키울 수 있습니다. 오늘 할 일과 전체 완료 조건을 같은 프로젝트 단위에 두면, 다음 날 다시 처음부터 설명할 필요가 줄어듭니다.

프로젝트를 오래 끌고 갈수록, 구현 지시보다 먼저 필요한 것은 무엇이 끝난 상태인지에 대한 짧고 분명한 기준입니다.

노트북을 닫아도 멈추지 않는 실행

영상이 설명하는 두 번째 변화는 실행 위치입니다. 설명에 따르면 프로젝트는 자체 클라우드 컴퓨터를 가지며, 노트북을 닫아도 프로젝트가 멈추지 않습니다. 로컬에서만 확인할 일이 있으면 코디네이터가 로컬 에이전트를 띄울 수 있습니다.

다만 이것이 환경 문제를 자동으로 해결해 준다는 뜻은 아닙니다. 의존성, 권한, 테스트 환경, 시크릿, 네트워크 설정은 여전히 작업에 맞게 준비되어 있어야 합니다. 클라우드에서 계속 실행된다는 사실과 실제로 검증 가능한 결과가 나온다는 사실은 다릅니다.

공유 컨텍스트가 쌓이면 결정도 이어집니다

세 번째 변화는 공유 컨텍스트입니다. 프로젝트 에이전트가 사용하는 클라우드와 로컬 머신 사이에 파일이 동기화되고, 조사 메모와 계획, 산출물, 코드베이스에서 배운 내용이 여기에 쌓입니다. 한 에이전트가 테스트 방법을 찾아 두면 이후 에이전트가 그 정보를 다시 활용할 수 있습니다.

이 구조의 장점은 결정이 한 채팅에 갇히지 않는다는 점입니다. 프로젝트를 따라가며 맥락이 이어지기 때문에, 같은 설명을 반복하는 시간을 줄일 수 있습니다. 하지만 영상은 기억이 많을수록 무조건 좋은 것은 아니라고도 강조합니다. 오래된 지시나 잘못된 가정이 남아 있으면 여러 에이전트가 같은 방향으로 빗나갈 수 있기 때문입니다.

공유 메모리는 반복 설명을 줄여 주지만, 잘못된 메모리까지 함께 복제할 수 있습니다.

그래서 프로젝트 노트는 길게 쓰기보다 구체적으로 쓰는 편이 안전합니다. 중요한 가정은 검토하고, 아키텍처나 요구사항이 바뀌면 지시도 함께 갱신하는 것이 좋습니다.

구독 기반 흐름은 좁은 목표부터 보는 편이 좋습니다

영상은 구독 방식도 함께 설명합니다. 코디네이터가 Slack 채널을 보거나, 일정에 따라 돌거나, PR을 따라가며 CI를 고치는 식으로 새 프롬프트를 기다리지 않고 신호에 반응할 수 있다는 내용입니다.

이런 흐름은 반복 테스트 실패처럼 범위가 좁은 목표부터 시작할 때 더 다루기 쉽습니다. 재현 방법과 통과해야 할 검사 기준을 먼저 적고, 실제 반영 전에는 사람이 검토하는 구조가 필요합니다. 영상도 이를 통제된 실험 결과라기보다 평가 접근으로 제시합니다. 즉, 우리 환경에서 프로젝트가 검토 가능한 산출물을 내는지 확인하는 과정에 가깝습니다.

오늘 바로 남기면 좋은 완료 조건 한 줄

이 글의 실무 포인트는 단순합니다. Projects를 만든 뒤 공유 컨텍스트에 완료 조건을 짧게 남기는 것입니다. 길고 포괄적인 설명보다, 결과를 판별할 수 있는 기준이 먼저 있어야 합니다.

오늘의 기준은 공유 컨텍스트에 완료 조건 3줄을 기록하는 일입니다.

예를 들어 어떤 화면이 바뀌는지, 어떤 테스트가 통과해야 하는지, 사람이 반드시 검토할 항목이 무엇인지를 3줄 이내로 적어 두면 됩니다. 구현을 맡기기 전에 코디네이터가 그 조건을 함께 읽게 하고, 첫 산출물을 받은 뒤에는 잘못된 가정이 없는지 조건을 다시 고치면 됩니다.

이 방식은 해커톤뿐 아니라 장기 기능 개발이나 반복 유지보수에도 그대로 적용할 수 있습니다. 완료 조건을 이슈나 노트로 남겨 두면 팀 병합이나 데모 전날에도 다시 쓰기 쉽습니다.

팀에서 바로 쓸 수 있는 짧은 예시

공유 컨텍스트에 넣는 문장은 길 필요가 없습니다. 검사 가능하고, 사람이 확인할 수 있으면 충분합니다.

• 로그인 화면에서 오류 메시지가 한국어로 표시된다.
• 관련 단위 테스트 3개가 통과한다.
• 제출 전 팀장 1명이 데모 스크립트를 한 번 읽는다.

이 정도만 있어도 에이전트는 무엇을 맞추면 끝나는지 알 수 있고, 사람은 무엇을 검토해야 하는지 분명해집니다. 반대로 조건이 모호하면 대충 동작하는 코드가 올라오고, 데모 직전에 기준을 다시 쓰게 될 가능성이 커집니다.

수정이 생기면 같은 공유 컨텍스트 파일을 갱신하는 편이 좋습니다. 채팅에만 남긴 변경은 다음 작업 에이전트에게 이어지지 않을 수 있기 때문입니다.

확대하기 전에 확인할 질문

영상이 제안하는 점검 기준은 세 가지입니다. 계획을 이해할 수 있는지, 변경을 검사하고 테스트할 수 있는지, 사람 입력이 필요한 시점을 볼 수 있는지입니다. 이 기준은 통제권을 보장하는 선언이 아니라, 실제로 써 보기 전에 던져야 할 평가 질문에 가깝습니다.

Projects 베타 롤아웃은 영상 기준으로 9월 10일에 시작되었습니다. 왼쪽 내비게이션에서 프로젝트를 만들고 작업을 설명하면 된다고 소개됩니다. 다만 가격, 이용 가능 범위, 권한은 계정 상태와 시점에 따라 달라질 수 있으므로 계정과 공식 문서를 직접 확인하는 편이 좋습니다.

결국 바뀌는 것은 도구보다 작업 단위입니다

이 영상이 강조하는 지점은 무엇을 더 붙일 것인가보다, 채팅을 넘기는 단위를 프로젝트로 올린다는 데 있습니다. 같은 도구를 써도 한 번 쓰고 버리는 채팅과 계속되는 프로젝트는 인수인계 비용이 다릅니다.

특히 여러 날에 걸쳐 제출과 데모 준비가 이어지는 팀이라면, 모델을 바꾸는 일보다 완료 조건이 따라가는 작업 단위를 먼저 정하는 편이 더 안전할 수 있습니다. 노트북을 닫아도 멈추지 않는 실행도 중요하지만, 그보다 더 중요한 것은 다음 날 다시 열었을 때 무엇을 기준으로 이어 갈지가 남아 있는가입니다.

참고 자료

유튜브: Cursor Projects Explained: An AI Agent That Keeps Working · 채널 TechWealth Hub

여러 날에 걸친 작업을 진행 중이라면, 지금 팀의 공유 컨텍스트에는 완료 조건이 얼마나 분명하게 남아 있나요?