내 Cursor 워크플로우에 내가 만든 최고의 개선
Source: Dev.to
tl;dr: 코딩 에이전트가 런타임 출력을 접근하도록 하세요
저는 이게 새로운 아이디어라고는 확신하지 않으며, 이미 많은 사람들이 어느 정도는 하고 있을 것이라 생각합니다. 하지만 Cursor와 함께하는 로컬 AI‑지원 개발에서 가장 큰 돌파구였으며, 너무 간단해서 공유하고 싶습니다.
코딩 에이전트가 프로그램이 무엇을 하고 있는지 볼 수 없으면, 디버깅할 수 없습니다
Cursor는 머신에서 일어나는 모든 일을 마법처럼 읽는 능력이 없습니다. 출력물을 명시적으로 노출하지 않으면, 에이전트는 사실상 눈이 먼 상태입니다.
프로그램의 출력을 보게 하면, 이전에 30분 정도 걸리던 문제를 약 30초 만에 해결할 수 있었고, 스타트업의 다른 영역에 시간을 할애할 수 있게 되었습니다.
문제점
내 로컬 개발 환경은 세 가지 구성 요소로 이루어져 있습니다:
- Python FastAPI 백엔드
- React 프론트엔드
- WorkOS와 통신하여 인증을 제공하는 Python FastAPI 인증 라우터
세 구성 요소 모두 로그를 출력하고, 독립적으로 실패할 수 있으며, 정상 가동을 위해 디버깅이 필요할 수 있습니다.
Cursor는 당신이 요청하거나 제안하는 명령을 실행할 수 있지만, 다음은 할 수 없습니다:
- 사용자가 직접 연 터미널 창에 붙는 것
- 실시간 stdout/stderr를 읽는 것
- 핫‑리로딩 서버를 감시하는 것
- 브라우저 콘솔 로그를 마법처럼 보는 것
에이전트가 실행 중인 서버나 클라이언트를 종료해서 ‘수정’하려고 하면, 전체 핫‑리로드 설정이 파괴되어 모든 것을 다시 시작해야 하고 생산성이 크게 떨어집니다.
해제된 잠금
코딩 에이전트는 생각보다 더 능력 있을 수 있으며, 때로는 궁금한 것이 가능한지 단순히 물어보는 것이 가장 좋은 방법입니다. 한 번은 “screen 세션 안의 내용을 읽을 수 있나요?”라고 물었습니다.
놀랍게도 Cursor는 다음과 같이 답했습니다:
screen -X hardcopy를 실행하면, 출력 내용을 읽을 수 있습니다.
그 후 저는 Cursor에게 screen -ls를 사용해 현재 실행 중인 스크린을 확인하고, 서버 출력의 마지막 50줄을 가져오라고 요청했습니다. Cursor가 수행했습니다.
이렇게 하면 에이전트가 코드뿐만 아니라 실제 출력도 살펴볼 수 있게 됩니다.
설정 방법
저는 runnem이라는 작은 도구를 사용합니다. 이 도구는 전혀 다른 목적, 즉 실행 설정을 기억하고 여러 프로젝트 간에 원활하게 전환할 수 있게 만들기 위해 제가 직접 만들었습니다.
각 서비스를 자체 screen 세션에서 실행하므로 이 잠금 해제가 가능해집니다. 비슷한 접근성을 제공하는 다른 도구도 사용할 수 있습니다:
- 독립적인
screen tmux- Docker (로그 파일 또는
docker logs) - 디스크에 파일로 로그 기록
원칙은 보편적입니다.
runnem을 사용하면 Cursor는 다음을 할 수 있습니다:
screen -ls로 세션 목록 확인- 백엔드와 프론트엔드 세션 구분
- 해당 세션의 출력을 중단 없이 디스크에 저장
- 로그를 분석하면서 모든 서비스를 유지하고 다음 코드 변경 시 핫‑리로드가 가능하도록 준비
내 .cursor/rules 스니펫
에이전트를 안내하기 위해 .cursor/rules 파일에 다음을 추가했습니다:
# Example command to fetch the last 200 lines of the backend logs
screen -S 94383.runnem-flow-myna-server -X hardcopy /tmp/backend_logs_200.txt && \
tail -200 /tmp/backend_logs_200.txt-server접미사가 붙은 screen은 백엔드입니다.-app접미사가 붙은 screen은 프론트엔드입니다.
때때로 저는 에이전트에게 screen -ls를 사용해 로그를 확인하라고 명시적으로 지시합니다. 그러면 에이전트가 서버가 다시 실행될 때까지 오류를 수정하는 루프에 들어갑니다.
runnem이 꼭 필요할까요?
아니요. 원하는 어떤 설정이라도 사용하세요.
runnem은 다음과 같은 이유로 워크플로우를 매우 간단하게 만들어 줍니다:
- 각 서비스마다 이름이 지정된 screen이 있음
- 두 가지 언어로 구성된 세 개의 서비스를 실행함
- 에이전트가 모든 서비스를 교차 검증해야 함
- 모든 서비스가 핫