Kiro vs 커서: 스펙이 남는 개발, 대화가 남는 개발

30초 결론: Kiro와 Cursor 중 어디를 고를 것인가#

스펙이 남는 개발과 대화가 남는 개발을 감사 추적과 온보딩 비용의 관점에서 살펴봅니다. Cursor에서도 계획을 파일로 저장할 수 있고, Kiro의 문서도 유지·검토하지 않으면 실제 변경과 달라질 수 있습니다. 감사 적합성이나 온보딩 시간은 아직 측정하지 않았습니다.

비교표: 인터페이스, 모델, 권한, 한국어, 가격 (6–8행)#

아래 공식 자료는 각각 2026-11-01에 확인했습니다. 기능과 승인 방식은 사용 환경과 설정에 따라 다릅니다.

1. 요구사항·설계·작업을 별도 파일로 검토하고 유지할 팀이라면 Kiro Spec을 살펴보세요. Quick Spec의 승인 방식은 다릅니다.
2. 에디터에서 계획을 세우고 필요한 계획만 작업공간에 저장하고 싶다면 Cursor를 시험하세요. 기록의 공유와 최신화는 팀이 정하세요.
3. 같은 저장소에서 승인 요청, 변경 diff, 테스트 출력과 문서 유지 부담을 직접 확인하고 계정별 데이터·비용 조건을 비교하세요.

요금 조건은 위 비교표와 아래 가격 항목의 공식 자료를 참고하세요.

Kiro가 강한 경우 / Cursor가 강한 경우#

Kiro는 요구사항부터 설계와 작업까지 나눠 검토하려는 팀에 후보입니다. 문서가 늘면 변경에 맞춰 유지할 책임도 생기며, Spec 자체가 규정 준수를 보증하지는 않습니다. Cursor는 에디터에서 계획을 검토하고 필요할 때 작업공간에 보관하려는 팀에 후보입니다. 계획은 기본적으로 홈 디렉터리에 저장되므로 공유하려면 저장 위치를 확인하세요.

같은 과제 비교: Kiro와 Cursor에 같은 이슈를 맡겼을 때#

동일 이슈를 두 도구로 실행한 기록과 리뷰 시간 측정치는 아직 없습니다. 직접 시험한다면 같은 요구사항과 저장소에서 Kiro Spec과 Cursor 계획의 내용, 변경 diff, 테스트 출력, 사람이 수정한 문서와 승인 요청을 각각 기록하세요. 리뷰 시간은 측정 조건을 정한 뒤 비교해야 합니다.

어느 쪽이든 문서가 존재한다는 사실만으로 추적성이나 온보딩 효과가 검증되지는 않습니다. 요구사항이 바뀌었을 때 문서와 코드·테스트를 함께 갱신했는지 확인하세요.

추가 검증 필요: 익명화한 Kiro Spec 산출물 샘플.

파일의 형태는 Kiro 대안의 공식 공개 Spec 발췌에서 볼 수 있습니다. 공개 저장소의 예시와 이 비교 과제에서 직접 생성한 익명화 산출물은 다른 증거이므로 아래 체크 항목은 아직 완료하지 않았습니다.

가격: 구독과 사용량#

2026-11-01에 확인한 공식 요금과 사용 조건은 위 비교표를 참고하세요. 기존 구독, 지역 가격, 세금과 추가 사용료는 결제 화면에서 확인하세요.

2026-11-01 확인 기준 Cursor 요금표는 신규 Plus에 Grok 모델만 사용 가능하다고 설명하지만, 모델 요금 문서는 Grok 외에 Composer 2.5도 명시합니다. 실제 이용 범위는 현재 계정과 결제 화면, 모델 선택기에서 확인하세요.

Kiro FAQ는 크레딧을 사용자 프롬프트에 대한 작업 단위로 정의하고, 간단한 프롬프트는 1크레딧보다 적게 쓸 수 있지만 spec 작업 실행처럼 복잡한 요청은 보통 1크레딧을 넘는다고 적습니다. 같은 문서는 모델마다 크레딧 소비율이 다르다고도 설명합니다. Kiro 요금 페이지는 Pro에서 추가 크레딧을 크레딧당 $0.04에 살 수 있다고 표시합니다.

미르 코드가 맞는 경우 / 맞지 않는 경우#

Mirr Code는 한국어를 우선하는 터미널 작업을 원할 때 살펴볼 수 있습니다. Kiro Spec과 같은 구조화된 산출물이나 Cursor의 에디터 흐름을 동일하게 제공하는지는 이 페이지에서 확인하지 못했습니다. 요금제와 결제 화면에서 현재 조건을 확인하고, 세 도구의 작업 결과를 비교한 기록이 없다는 점을 고려하세요.

스펙의 존재와 추적 가능한 변경은 다릅니다#

요구사항 문서가 저장소에 있다는 사실은 좋은 출발점일 수 있지만 실제 코드와 맞는지 검토하세요. 문서가 오래된 상태로 남으면 새로 온 사람에게 잘못된 동작을 알려 줄 수 있습니다. Kiro의 Spec과 Cursor의 저장된 계획을 비교할 때는 파일 수보다 요구사항, 설계와 실제 diff의 연결을 보세요. 어떤 조건을 바꾸었고 어떤 조건은 유지했는지 읽을 수 있어야 합니다. 이 페이지는 그 연결을 실제 과제에서 검증한 자료가 아니며 감사 적합성을 인증하지 않습니다.

추적성에는 책임도 포함됩니다. 요구사항이 바뀌면 누가 문서를 고치고, 구현 중 발견한 예외는 어디에 남길지 정하세요. 생성된 작업 목록이 모두 완료 표시여도 실제 검증이 누락될 수 있습니다. 계획 파일과 테스트 출력을 연결하고 실행하지 않은 항목은 따로 남기는 운영 규칙이 필요합니다. 도구가 문서를 만들 수 있다는 기능과 팀이 문서를 유지한다는 관행은 다릅니다. 둘 중 하나만으로 온보딩 효과나 리뷰 시간 절감이 입증되지는 않습니다.

일반 Spec과 Quick Spec의 선택 기준#

2026-11-03 다시 읽은 Spec 안내와 Quick Spec은 단계별 검토와 단계 사이 승인 없이 문서를 만드는 경로를 구분합니다. Quick Spec도 요구사항, 설계와 작업 파일을 만들지만 각 단계의 승인 지점을 거치지 않습니다. 따라서 Spec 파일이 있으니 사람이 각 단계를 승인했다고 표현할 수는 없습니다. 비교 기록에는 어떤 경로를 사용했는지 적으세요. 문서 형식의 유사함과 승인 과정의 동일함은 다른 조건입니다.

일반 Spec에서는 단계마다 확인 지점이 있습니다. 2026-11-03에 확인한 Kiro Spec 안내는 CLI에서 Ctrl+X로 그 단계 문서를 열어 줄 단위 의견을 남기고, 확인 질문에 답하면 의견 전체가 한 번의 수정 요청으로 전달된다고 설명합니다. IDE에서는 문서의 Review 버튼으로 Markdown Review를 여는 방식입니다. Quick Spec 문서는 requirements.md의 사용자 스토리와 수용 기준을 EARS 표기로 적는다고 설명합니다.

요구가 익숙하고 예외가 적은 과제라면 빠르게 초안을 만들고 나중에 검토하는 방식이 맞을 수 있습니다. 낯선 도메인이나 계약 변경이 큰 과제라면 초기에 질문과 검토를 나눌 이유가 있습니다. 이것은 과제를 설계하는 판단 기준이며 Kiro가 특정 과제에서 더 빠르다는 실측 결론은 아닙니다. 어떤 경로를 선택해도 잘못된 요구사항이 자동으로 맞아지지는 않습니다. 질문에 답할 사람과 최종 수용 기준이 있어야 문서 생성이 작업의 방향을 좁히는 데 도움이 됩니다.

Cursor 계획을 공유 가능한 자산으로 남기기#

Cursor에서도 계획을 검토하고 저장할 수 있으므로 대화만 남는 도구라고 단정하지 않습니다. 다만 팀이 다시 읽을 수 있는 위치와 실제 저장 범위를 확인하세요. 어느 계획이 현재 변경의 기준인지 표시하고 오래된 계획을 그대로 인용하지 않도록 관리하세요. 이 페이지는 실제 작업 공간의 계획 저장을 시험하지 않았습니다. 공식 지원 기능이 있다는 사실과 팀 전체가 같은 기록을 읽는다는 사실은 별도로 확인할 항목입니다.

계획을 공유할 때는 도구 전용 형식보다 내용의 계약을 먼저 봅니다. 왜 이 변경이 필요한지, 무엇을 바꾸지 않을지와 어떤 테스트로 수락할지 적으면 다른 도구나 사람이 읽기 쉽습니다. 내부 주소와 고객 자료는 공개 문서에서 제외해야 합니다. 계획을 버전 관리한다면 코드 변경과 함께 검토할 수 있지만 모든 대화 전문을 저장할 필요는 없습니다. 필요한 근거와 결정만 남기고 민감한 입력과 일시적인 추측은 구분하는 편이 좋습니다.

2026-11-03에 확인한 Cursor 규칙 문서에 따르면 Cursor에는 계획과 별도로 저장소에 남는 지침도 있습니다. 프로젝트 규칙은 .cursor/rules 안의 .mdc 파일로 버전 관리되고 경로 패턴으로 적용 범위를 나눌 수 있습니다. 확장자가 .md인 파일은 frontmatter가 없어 규칙 시스템이 무시한다고 같은 문서는 적습니다. AGENTS.md는 마크다운으로 쓰는 더 간단한 대안이며, 팀 규칙은 Team과 Enterprise 플랜에서 대시보드로 관리합니다.

Cursor 규칙은 항상 적용, 관련성에 따라 적용, 지정한 파일 패턴에 적용, 채팅에서 수동으로 호출하는 방식으로 나뉜다고 문서는 적습니다. 문서는 언어 모델이 완성 사이에 기억을 유지하지 않으므로, 규칙이 프롬프트 수준에서 재사용 가능한 문맥을 제공한다고 설명합니다.

요구사항 변경을 추적하는 가상 과제#

예를 들어 목록에서 보관된 항목을 기본으로 숨기고 필요할 때 다시 보는 기능을 가정해 봅시다. 요구사항에는 기본 표시, 필터 상태와 기존 링크의 동작을 적을 수 있습니다. 설계에는 현재 데이터 조회와 화면의 연결을 설명하고, 작업에는 코드와 테스트 변경을 나눌 수 있습니다. 이것은 실제 생성된 Spec이 아니라 아래 추적 예시를 위한 가상 과제입니다.

구현 중 보관 항목도 관리자에게는 기본 표시해야 한다는 새 조건이 생겼다고 가정하면 변경을 어디에 반영할지 볼 수 있습니다. 요구사항만 고치고 작업 목록과 테스트를 두면 문서가 서로 어긋납니다. 코드만 바꾸고 설계를 그대로 두어도 새로 온 사람은 이전 동작을 읽게 됩니다. 두 도구에서 이 변경을 반영하는 데 어떤 사람의 개입이 필요한지 기록하면 유지 부담을 평가할 수 있습니다. 현재 이 페이지는 그러한 변경 실험이나 소요 시간 측정을 수행하지 않았습니다.

요구 파일을 고친 뒤에는 Sync Files로 작업 목록을 다시 만들 수 있다고 Quick Spec 문서는 2026-11-03에 확인한 기준으로 설명합니다. 다만 다시 만든 목록이 기존 완료 표시를 어떻게 다루는지는 이 페이지에서 확인하지 않았으므로, 변경 뒤에는 목록의 상태를 요구별로 다시 대조해야 합니다.

문서 리뷰 시간을 비교하는 설계#

리뷰 시간을 재기 전에 무엇을 읽고 어떤 결정을 내릴지 정하세요. 코드만 읽는 리뷰와 요구사항·설계·코드를 함께 읽는 리뷰는 범위가 다릅니다. Spec 경로에서 문서를 읽는 시간이 늘어도 누락을 더 잘 찾았다면 단순히 느리다고 볼 수는 없습니다. 반대로 문서가 많아도 중요한 예외를 놓쳤다면 도움이 됐다고 주장하기 어렵습니다. 시간과 정확성, 보완 작업을 따로 기록하는 편이 낫습니다.

표는 문서와 코드를 읽는 평가 기준입니다.

개인정보와 감사 자료를 함께 다룰 때#

스펙에는 코드보다 구체적인 사업 요구와 내부 절차가 들어갈 수 있습니다. 코드만 익명화하고 요구사항의 고객 이름이나 내부 주소를 남기지 않도록 주의하세요. 2026-11-03 읽은 Kiro 데이터 보호는 개인과 기업 사용자, 서비스 개선 이용과 별도의 보관 조건을 구분합니다. Cursor도 계정과 기능별 처리 범위를 확인하세요. 유료 구독이라는 이유만으로 기업 계약과 같다고 가정하지 않습니다. 공개할 자료의 범위는 조직의 허가를 받아야 합니다.

감사용 자료를 남기는 목적과 장기 보관은 별도 결정입니다. 검토에 필요한 결정을 남기되 비밀값과 불필요한 대화를 무조건 모두 저장하지 않습니다. 누가 원본을 읽을 수 있고 공개 발췌는 어떤 과정을 거치는지 정하세요. 이 페이지가 제시한 절차는 규정 준수의 법률 자문이나 실제 감사 결과가 아닙니다. 문서를 생성하는 방식과 운영 책임을 이해하기 위한 안내입니다. 스펙 유지의 책임을 맡을 팀인지, 필요한 계획을 선택해서 보관할 팀인지에 따라 시험할 후보를 좁힐 수 있습니다. 2026-11-03에 확인한 Kiro Spec 안내는 Kiro 웹 세션의 산출물을 Download 버튼으로 .md 파일을 받아 보관하거나 Kiro IDE에서 이어 작업할 수 있다고 안내합니다.

변경된 요구 하나를 끝까지 추적하는 예시#

앞의 보관 항목 기능에 “관리자에게는 기본 목록에서도 보관 항목을 보여 준다”는 새 요구가 들어왔다고 합시다. 다음 문서 내용은 이 글에서 작성한 가상 예시이며 Kiro가 생성한 산출물이 아닙니다. 최초의 일반 사용자 기본 동작은 유지하고 관리자 예외만 추가하는 것이 목표입니다. 이 요구는 화면에 보관 필터가 있는지와 다른 권한 조건을 포함하므로 조회, 화면과 테스트의 연결을 각각 검토하게 됩니다.

Kiro Feature Spec의 요구사항을 읽는 단계에서는 requirements.md에 주체와 조건을 분리할 수 있습니다. “일반 사용자의 기본 목록은 보관 항목을 제외한다”와 “관리자 기본 목록은 보관 항목을 포함한다”는 두 조건입니다. “모든 사용자가 보관 항목을 볼 수 있다”로 바꾸면 원래 권한 경계를 넓힐 수 있으므로 같은 요구가 아닙니다. 여기서 사람의 질문은 구현 파일이 어디냐보다 관리자라는 주체와 기존 정책의 뜻이 맞느냐입니다.

Kiro는 Analyze Requirements 기능으로 요구사항의 불일치, 모호함과 빈틈을 설계 이전에 찾는다고 설명하며, 이 기능을 IDE와 CLI에서 쓸 수 있다고 표에 표시합니다. 실행하지 않은 가정으로 보면, 관리자 예외 문장을 적은 뒤 이 점검을 거치면 주체와 권한 조건이 어긋나는지를 설계 전에 볼 수 있습니다.

design.md에서는 이 예외를 어느 기존 경로에 붙일지 읽습니다. 기존 조회 계층이 권한 정보를 알고 있다면 그곳에서 조건을 결정할지, 화면에서 조건을 만들어 전달하는지 검토할 수 있습니다. 화면에서 숨기는 것과 조회 대상 자체를 제한하는 것은 다릅니다. 예시에서는 기존 권한 계약을 유지한다는 원칙을 설계에 연결해야 합니다. Kiro의 단계별 검토를 쓰려는 팀은 이런 결정이 내려지기 전에 다음 구현으로 넘어갈지 판단할 수 있습니다.

tasks.md에서는 요구 문장을 다시 복사하기보다 실제 수정과 검증을 나눕니다. 조회 조건의 기존 경계를 읽는 작업, 관리자 기본값을 연결하는 작업, 일반 사용자 회귀 검증과 관리자 예외 검증을 별도로 둘 수 있습니다. 코드 검토자는 작업 개수보다 어느 요구가 어느 변경과 테스트에 연결되는지 봅니다. 조회만 고치고 화면의 기본 선택값을 그대로 두면 표시와 실제 데이터가 어긋날 수 있으므로 그 연결도 작업에 드러나야 합니다.

2026-11-03에 확인한 Kiro Spec 안내는 작업을 실행할 때 tasks.md의 의존 관계로 그래프를 만들고, 의존이 없는 작업끼리 같은 wave에서 동시에 실행한다고 설명합니다. 그러므로 두 작업이 같은 조회 함수를 고친다면 그 의존 관계를 tasks.md에 적어야 충돌 위험을 줄일 수 있습니다.

같은 요구를 Cursor 계획으로 관리한다면#

Cursor Plan Mode 문서는 코드베이스를 조사하고 질문한 뒤 검토 가능한 계획을 만든다고 설명합니다. 이 예시에서는 관리자 권한이 어느 코드에 있는지 조사한 결과와 조회·화면을 연결할 안을 하나의 계획에서 읽을 수 있습니다. Kiro의 파일 구분과 똑같은 이름의 문서를 만들 의무는 없지만, 수용 기준과 구현 선택을 구분해 적으면 리뷰어가 같은 질문을 할 수 있습니다.

계획은 기본적으로 홈 디렉터리에 저장되고 Save to workspace로 작업 공간에 옮길 수 있습니다. 개인이 잠깐 검토할 계획인지 팀이 이후 읽을 기록인지에 따라 이 저장 결정을 내려야 합니다. 팀과 공유할 예외 조건이 홈에만 남으면 새 리뷰어는 코드에서 관리자 분기의 이유를 다시 추론해야 할 수 있습니다. 반대로 모든 대화 전문을 저장하는 것이 목적은 아닙니다. 이 변경에서 유지하기로 한 일반 사용자 계약과 관리자 예외의 이유를 찾을 수 있는 형태가 필요합니다.

Cursor에서 계획을 편집하며 관리자 예외의 범위를 좁힌다면 코드 작성 전에 그 결정이 반영됐는지 확인할 수 있습니다. 구현 중 새로운 권한 경로를 발견했다면 계획의 선택 이유를 갱신하는 방식으로 이어갈 수 있습니다. Kiro에서는 요구·설계·작업이라는 별도 파일 사이의 연결을 읽는 반면 Cursor에서는 선택한 계획의 구조와 공유 위치를 팀이 정하는 부담이 있습니다. 어느 방식이 낫다는 결론보다 기록의 경계가 도구에 의해 얼마나 정해져 있고 팀이 무엇을 맡아야 하는지의 차이입니다.

기능 추가와 버그 수정은 출발 문서가 다릅니다#

Kiro Spec 안내는 Feature와 Bugfix 흐름을 구분합니다. Bugfix 문서는 요구사항 문서 대신 bugfix.md에 현재의 잘못된 동작, 기대 동작과 유지할 동작을 담는다고 설명합니다. 관리자 예외가 새 요구라면 기능의 수용 기준에서 출발하지만, 이미 관리자에게 보여야 한다는 기존 계약을 어긴 버그라면 이 세 구분에서 출발할 수 있습니다. 새 기능의 약속과 기존 동작의 복구를 혼동하지 않으면 범위를 불필요하게 늘리지 않을 수 있습니다. 문서 이름보다 무엇을 바꾸고 보존할지의 출발점이 달라지는 비교입니다.

예시를 버그로 바꾸면 일반 사용자에게 숨겨야 할 항목까지 보이게 하는 전역 조건 변경은 적절한 해결인지 다시 검토하세요. 관리자 분기의 누락이 원인이라면 그 분기를 좁혀 고치는 안이 있고, 권한 데이터 전달이 잘못됐다면 다른 계층을 고칠 이유가 있습니다. 설계에서는 그 가설을 기존 코드와 연결하고 작업에서는 회귀 테스트를 붙입니다. 현재 이 글은 실제 원인을 조사하거나 특정 Kiro 분석 결과를 제시하지 않습니다. 기능과 버그 흐름의 질문이 어떻게 다른지를 설명한 것입니다.

Quick Spec을 쓰면 이동하는 검토 책임#

2026-11-03에 확인한 Quick Spec 문서는 생성한 요구사항·설계·작업을 .kiro/specs/에 저장한다고 설명하고, 구조화된 파일 없이 대화로 진행하는 Vibe 흐름과도 구분합니다. Cursor와 비교할 때 제품 이름만 적기보다 실제로 고른 Spec 경로와 계획의 저장 위치를 같이 적어야 문서화 방식의 차이를 읽을 수 있습니다.

Quick Spec 문서는 처음의 질문에 답한 뒤 요구사항·설계·작업을 한 번에 만들고 단계 사이 승인 없이 이어지는 방식을 설명합니다. 위 예시에서 관리자 예외가 팀에 익숙하고 조건이 명확하다면 초안을 빠르게 묶어 보고 나중에 수정하는 안을 검토할 수 있습니다. 검토 책임은 사라지는 것이 아니라 앞의 질문과 생성 뒤의 읽기로 이동합니다.

관리자라는 용어의 의미부터 불명확하거나 권한 경계의 변경이 큰 과제라면 단계별로 질문을 확정할 이유가 있습니다. 요구를 오해한 설계가 작업 목록까지 확장되기 전에 조건을 고칠 수 있기 때문입니다. Cursor 계획도 구현 전에 질문과 설계를 검토하는 용도로 쓸 수 있습니다. 여기서는 기능 수보다 팀이 어느 단계에서 결정을 멈추고 읽고 싶은지가 선택 기준입니다.

새 팀원에게 남길 정보는 역할별로 다릅니다#

가상 예시에서 일반 사용자의 조회가 바뀌지 않아야 한다는 조건은 문서의 회귀 검토 지점입니다. 새 팀원이 관리자 기본값만 보고 모든 사용자의 기본값을 바꾸려 한다면 요구사항의 주체를 다시 읽게 할 수 있습니다.

Cursor의 공유 계획에서는 같은 주체·경로·검증을 팀이 정한 구조 안에서 찾을 수 있어야 합니다.

새 개발자가 관리자 예외를 고쳐야 한다면 요구에서 주체와 범위를, 설계에서 기존 권한 경로를, 작업·테스트에서 확인할 동작을 찾을 수 있어야 합니다. 리뷰어는 그 연결이 실제 diff와 맞는지 읽습니다. 기록 담당자는 어떤 결정이 최초 계획에서 달라졌는지 보관합니다. Kiro의 구조화된 문서가 이 검색의 위치를 정해 줄 수 있고 Cursor의 공유 계획은 팀이 필요한 밀도로 정리할 수 있습니다.

이 글은 익명화한 실제 생성 Spec이나 새로운 팀원의 읽기 시간을 확보하지 않았습니다. 공개 샘플과 위 가상 추적은 문서의 용도를 설명하는 자료입니다. 문서화 방식의 선택을 코드와 분리된 장식으로 보지 않고, 요구 변경을 어느 기록에서 유지할지라는 운영 결정으로 읽는 데 활용할 수 있습니다.

수정·보완 기록#

Cursor도 계획을 저장할 수 있다는 점과 Kiro의 일반 Spec·Quick Spec 승인 차이를 유지했습니다. Cursor Plus의 상충 안내를 추가했으며, 익명화한 실제 Spec과 리뷰 시간은 문서 링크만으로 충족한 것으로 처리하지 않았습니다.

검증일 · 출처#

기존 일정 날짜: 2026-10-11. 페이지 전체의 사실 검증일을 뜻하지 않습니다.

출처 확인일: 위에 링크한 Kiro와 Cursor 공식 문서·요금표는 각각 2026-11-01에 확인했습니다. 실제 작업 결과와 캡처는 아직 확인되지 않았습니다.

📋 추가 검증 필요

• Kiro spec 산출물 샘플(익명화)
• 스펙 유무에 따른 리뷰 시간 비교표