2026 백엔드 개발 AI 에이전트 활용: Cursor·Rocket.new로 생산성 2배에 가까워지는 실전 워크플로

# 2026 백엔드 개발, AI 에이전트로 생산성 높이기 AI 에이전트는 개발자를 대체하는 도구가 아니다. 결정을 더 빨리 내리도록 돕는 보조 시스템이다. 백엔드 개발에서 시간을 잃는 지점은 타이핑이 아니다. 변경의 파급 범위를 계산하고, 안전장치를 설계하고, 검증 근거를 남기는 과정이 병목이다. Cursor와 Rocket.new는 그 병목의 일부를 덜어준다. 다만 구조를 잘못 잡으면 더 빠르게 망가질 수 있다. 이 글은 도구 소개가 아니다. 2026년 기준, 백엔드 개발자가 Cursor와 Rocket.new를 실제 업무에 배치했을 때 어디서 일이 줄고 어디서 일이 늘어나는지에 대한 기록이다. ## 1) 백엔드의 병목은 코드가 아니라 의사결정과 검증이다 백엔드 개발의 반복 작업은 일정하다. 문제는 반복이 연쇄적이라는 점이다. API 하나를 바꾸면 DTO, Validator, Mapper, 문서, 테스트가 줄줄이 흔들린다. 개발자는 코드를 쓰기보다 영향 범위를 계산하는 데 시간을 쓴다. 두 번째 병목은 데이터 계층이다. 쿼리 한 줄이 성능과 락을 바꾸고, 트랜잭션 경계가 장애 양상을 바꾼다. 실행계획과 인덱스는 그럴듯한 오답을 만들기 쉽다. 이 구간에서는 검색과 실험이 본작업이 된다. 세 번째 병목은 반복되는 규칙이다. 권한, 로깅, 에러 포맷, 감사 필드, 입력 검증. 팀은 규칙을 갖고 있지만 변경 작업에서 일관되게 적용하려면 시간이 든다. 실수는 규칙의 누락에서 나온다.  AI 에이전트의 역할은 여기서 선명해진다. 더 빨리 코드를 쓰게 하는 것이 아니라, 반복 판단과 검증 비용을 줄여 변경의 리드타임을 단축하는 것이다. ## 2) 도구를 '기능'이 아니라 '역할'로 배치한다 도구를 기능으로 외우면 적용이 어색해진다. 역할로 치환하면 쓸 자리가 보인다. ### Cursor: 코드 옆에 앉아 있는 페어 프로그래머 Cursor는 변경 작업에서 힘을 발휘한다. 레거시나 중간 규모 서비스에서 어디를 고쳐야 하는지 좁히는 데 도움이 된다. 다만 이 페어 프로그래머는 기억이 불완전하다. 맥락 관리는 사람이 해야 한다. 내가 Cursor에 기대는 지점은 세 가지다. 첫째, 영향 범위 탐색을 빠르게 한다. 둘째, 반복 수정(이름 변경, 매퍼 정리, 테스트 뼈대)을 덜어준다. 셋째, 리뷰 관점에서 놓친 조건을 체크리스트로 돌려준다. 반대로 Cursor에 기대면 곤란한 지점도 있다. 도메인 규칙이 복잡할수록 그럴듯한 일반론을 코드로 굳혀버릴 위험이 크다. 이때는 초안 생성기로만 활용해야 한다. ### Rocket.new: 초기 골격을 빠르게 세우는 스캐폴딩 도구 Rocket.new는 신규 서비스나 모듈을 시작할 때 유용하다. 폴더 구조, 기본 의존성, 라우팅/핸들러 스캐폴딩, 테스트 프레임을 빠르게 만든다. 중요한 점은 도메인 규칙은 사람이 주도한다는 원칙이다. 나는 Rocket.new가 생성한 결과를 그대로 신뢰하지 않는다. 먼저 경계를 본다. 계층이 섞였는지, 인프라 코드가 도메인으로 침투했는지, 로깅/에러 포맷이 조직 규칙과 어긋나는지부터 확인한다. 골격은 빨리 세워도 경계가 흐리면 이후 변경 비용이 폭증한다. 도구를 역할로 배치하면 "어디까지 맡기고 어디부터 사람이 책임지는가"를 명확히 할 수 있다. ## 3) 실전 워크플로: 하루의 흐름으로 굴린다 AI 에이전트는 순서가 없으면 잡음이 된다. 순서가 있으면 품질 관리 장치가 된다. 내가 정착시킨 흐름은 다섯 단계다. ### 3.1 요구사항을 '불변/가변'으로 분해한다 프롬프트는 길수록 좋지 않다. 구조가 있어야 한다. 나는 요구사항을 네 줄로 고정했다. - 불변: 절대 바뀌면 안 되는 규칙(권한, 데이터 무결성, 에러 규격) - 가변: 이번 변경에서만 달라지는 동작(API 필드 추가, 상태 전이) - 금지: AI가 건드리면 안 되는 구역(보안 로직, 결제/정산 핵심) - 검증: 통과해야 하는 체크(테스트, 로그, 마이그레이션, 실행계획) 이 형식은 Cursor에도, Rocket.new에도 그대로 쓴다. 도구가 바뀌어도 프롬프트의 계약은 유지된다. ```text 불변: 에러 응답은 {code,message,traceId} 유지. 권한은 RBAC 규칙 그대로. 가변: POST /v2/orders에 couponId(optional) 추가. 적용 시 할인 금액 계산 변경. 금지: auth/, billing/ 하위 로직 수정 금지. 기존 트랜잭션 경계 변경 금지. 검증: unit test 3개 이상, 통합 테스트 1개. DB 변경 시 실행계획 캡처. ``` 핵심은 "무엇을 만들까"가 아니라 "무엇을 지킬까"다. 불변을 먼저 적으면 AI가 내는 초안도 그 틀 안에서 움직인다. ### 3.2 Rocket.new로 스캐폴딩을 만든 뒤, 경계부터 검사한다 신규 모듈을 만들 때 가장 위험한 것은 빠르게 쌓인 코드가 경계를 흐리게 만드는 것이다. Rocket.new로 생성한 결과는 다음 순서로 검토한다. 첫째, 폴더 구조가 의존성 방향을 강제하는가. 둘째, 에러/로그 포맷이 조직 규칙과 맞는가. 셋째, 설정 값이 코드에 박혀 있지 않은가. 이 단계에서 수정보다 삭제를 많이 한다. 초안이 과하면 유지보수 비용이 된다. 골격은 얇을수록 좋다. ### 3.3 Cursor로 변경 작업: "한 번에 한 레이어" 원칙 처음엔 욕심이 났다. 컨트롤러, 서비스, 리포지토리, 테스트까지 한 번에 바꾸라고 시켰다. 결과는 예측 가능했다. 레이어가 섞였고, 책임이 이동했으며, 테스트는 통과를 위한 테스트가 되었다. 그 뒤로는 규칙을 고정했다. 한 번에 한 레이어만 바꾼다. 1) 컨트롤러/핸들러: 요청·응답 형태만 정리 2) 서비스: 도메인 규칙과 트랜잭션 경계 확정 3) 리포지토리: 쿼리/인덱스 검토, 실행계획 확인 4) 테스트: 실패 케이스를 먼저 박고, 성공 케이스를 채움 이 원칙은 AI를 위한 것이 아니라 리뷰를 위한 것이다. 레이어가 섞이면 리뷰어는 판단 근거를 잃는다. AI가 만든 코드의 위험은 오류보다 경계 붕괴에서 나온다. ### 3.4 테스트·로그·마이그레이션을 체크리스트로 강제한다 AI 에이전트는 체크리스트를 주면 강해지고, 없으면 산만해진다. 나는 PR 전에 아래 항목을 강제했다. - 테스트: 변경된 규칙마다 최소 1개 테스트 - 로그: 장애 시 역추적 가능한 키(traceId, entityId 등) 포함 - 마이그레이션: 스키마 변경 시 롤백 경로 명시 - 문서: API 변경 시 스펙과 예외 케이스 기록 특히 "AI 생성 구간은 테스트 우선"이라는 규칙을 팀 차원에서 합의하면 효과가 크다. 책임 소재를 명확히 하기 위함이다. ### 3.5 PR 올리기 전, 'AI가 만든 부분'과 '내가 보증하는 부분'을 분리한다 리뷰는 설득의 과정이다. AI 코드가 섞이면 설득이 더 필요하다. 그래서 PR 설명에 두 줄을 넣는다. - AI 생성/수정 구간: 파일 목록과 변경 요약 - 내가 보증하는 구간: 도메인 규칙, 보안, DB 판단 근거 DB 변경이 있으면 실행계획 캡처를 남긴다. 이 한 장이 논쟁을 줄인다. 느낌이 아니라 근거로 대화가 바뀌기 때문이다. 이 흐름이 정착되면 줄어드는 것은 코딩 시간이 아니라 PR 리드타임과 재작업이다. 반복 판단이 줄어들고 검증의 순서가 고정되기 때문이다. ## 4) 언제 쓰면 망하는가: 트레이드오프를 분리해 둔다 도구의 가치는 장점보다 한계에서 갈린다. AI 에이전트는 빠른 오답을 만든다. 다음 구간은 경계를 두껍게 잡아야 한다. ### 보안·권한 로직: 자동생성에 맡길수록 위험이 커진다 권한은 코드보다 정책이다. 정책은 예외로 자라고, 예외는 사고로 이어진다. AI는 일반적인 RBAC 패턴을 잘 안다. 그러나 조직의 예외 규칙까지는 모른다. 결국 가장 위험한 버그, 즉 정상 동작처럼 보이는 권한 누수가 생긴다. 내 원칙은 단순하다. 권한 로직은 사람이 작성하고, AI는 테스트 케이스 확장에만 참여한다. 코드 생성보다 검증 확대가 안전하다. ### DB 쿼리·최적화: 맞는 듯한 틀린 답이 잦다 AI는 쿼리를 작성할 수 있다. 그러나 실행계획, 락 경합, 인덱스 선택은 환경 의존적이다. 특히 대규모 테이블에서의 조인 순서나 조건절 선택성은 실제 데이터 분포 없이는 단정하기 어렵다. 따라서 쿼리 초안과 최종 판단을 분리해야 한다. AI가 만든 쿼리는 시작점일 뿐이다. 최종은 사람이 실행계획을 보고 결정한다. 이 구간에서 타협하면 장애 대응 비용으로 되돌아온다. ### 조직 규칙: 프롬프트보다 리포지토리 문서가 우선이다 코딩 컨벤션, 에러 포맷, 로깅 정책은 프롬프트로 강제할 수 있다. 하지만 프롬프트는 휘발된다. 반면 리포지토리의 규정 문서는 축적된다. 규칙은 문서로, 예시는 코드로 남겨야 한다. AI 에이전트 활용이 성숙해질수록 프롬프트를 잘 쓰는 사람보다 규칙을 잘 남기는 사람이 팀을 살린다. AI 에이전트는 강력하지만 무책임하다. 책임은 언제나 사람이 진다. ## 5) 상황별 권장 사항: 신규/레거시/핫픽스의 기준 도구 선택을 강요할 생각은 없다. 상황별로 무엇을 우선시해야 하는지 기준만 남긴다. ### 신규 프로젝트: Rocket.new로 뼈대, Cursor로 규칙 고정 신규에서는 속도가 필요하다. Rocket.new로 스캐폴딩을 만들되, 첫날 해야 할 일은 기능 추가가 아니라 규칙 고정이다. 에러 포맷, 로깅, 테스트 베이스라인을 먼저 박아야 한다. 그 다음부터 Cursor로 반복 작업을 줄인다. ### 레거시 개선: Cursor로 영향 범위 좁히기 레거시는 모르는 코드가 비용이다. Cursor는 탐색과 요약에서 힘이 난다. 다만 레거시의 핵심은 변경 범위를 작게 유지하는 것이다. 한 번에 한 레이어 원칙을 지키고 변경 단위를 작게 쪼개야 한다. ### 핫픽스: AI는 가속이 아니라 안전장치로만 핫픽스에서 가장 위험한 것은 과잉 변경이다. 이때 AI는 코드를 더 만들기보다 체크리스트로 실수를 줄이는 쪽이 낫다. 영향 범위 요약, 롤백 플랜 정리, 테스트 누락 탐지 같은 보조 역할이 적합하다. ## 6) 바로 쓰는 체크리스트: PR 전 10분 점검 아래는 내가 PR 올리기 전에 실제로 보는 항목이다. 팀 상황에 맞게 조정하면 된다. - [ ] 불변 조건(권한/무결성/에러 규격)을 PR 설명에 명시했다 - [ ] 변경은 한 레이어씩 진행되었고 책임 이동이 없다 - [ ] AI 생성 구간을 파일 단위로 분리해 표시했다 - [ ] 실패 케이스 테스트가 먼저 존재한다 - [ ] 로그에 추적 키가 있고 민감 정보는 마스킹된다 - [ ] DB 변경이 있으면 실행계획 또는 근거를 남겼다 - [ ] 마이그레이션의 롤백 경로를 적었다 - [ ] 리뷰 포인트(의심 지점/가정)를 PR 본문에 적었다 이 정도만 지켜도 헤매는 시간이 줄어든다. 생산성은 속도가 아니라 방향에서 나온다. --- AI로 빨라지는 것은 타이핑이 아니라, 판단을 반복하는 고통이다.