Kiro 대안: 스펙 문서가 남는 팀을 위한 선택 기준

30초 결론: Kiro를 떠나야 하는 사람과 남아야 하는 사람#

요구사항과 설계를 파일로 남겨 함께 승인하는 팀이라면 Kiro를 유지할 이유가 있습니다. 별도 스펙보다 터미널에서 한국어로 조사하고 변경을 검토하는 흐름을 원한다면 Mirr Code도 후보입니다. 두 방식의 리뷰 시간은 아직 비교 아직 측정하지 않았습니다.

한눈에 보기: Kiro, 미르 코드, 대안 2–3종 (6행 표)#

2026-11-01 확인. 아래는 작업 방식의 차이이며 품질 순위가 아닙니다.

출처: Kiro 스펙, GitHub 요금·기능, Devin Desktop 시작 안내, Mirr 모델 소개.

어디가 더 나은가: Kiro가 강한 경우 / 미르 코드가 맞는 경우 / 미르 코드가 아직 부족한 점#

Kiro의 강점은 스펙을 요구사항·설계·작업으로 나눠 검토하는 명시적 흐름입니다. 공식 문서는 requirements.md, design.md, tasks.md를 설명합니다. 문서가 많아지는 것이 유익한지 부담인지는 팀의 변경·관리 방식에 달려 있습니다. Mirr는 한국어 중심 터미널 작업을 살펴볼 수 있지만 Kiro와 같은 스펙 생성·추적 경험은 이 페이지에서 입증하지 않았습니다.

다음은 Kiro 공식 저장소의 github-issue-automation 공개 스펙에서 짧게 발췌한 예입니다. 이 세 파일의 발췌 확인일은 2026-11-02이며, 페이지 전체의 검증일이나 이 글의 실행일이 아닙니다.

이 공개 파일들은 산출물의 형태를 보여 줍니다. 문서의 체크 표시가 실행 성공이나 리뷰 시간 단축을 입증하지는 않습니다. 생성된 익명화 Spec, 코드 diff와 테스트 및 두 경로의 리뷰 시간은 아직 수집하지 못했습니다.

데이터 처리 판단: Kiro 데이터 보호 문서에 따르면 무료·개인 구독자의 콘텐츠는 설정에 따라 서비스 개선과 모델 학습에 사용될 수 있으며 수집을 거부할 수 있습니다. 기업 사용자 콘텐츠는 서비스 개선에 사용하지 않지만 관리자 설정에 따른 로그와 모델별 악용 탐지 보관이 적용될 수 있습니다. 무료 사용자의 입력은 별도 악용 탐지를 위해 최대 60일 보관될 수 있습니다. 사용 전 합성 저장소로 시험하고 서비스와 모델 제공자의 전송·보관·삭제 조건을 확인하세요. 확인일 2026-11-01.

실제 작업 흐름: Kiro와 같은 과제를 미르 코드로#

스펙을 쓰는 경로와 쓰지 않는 경로의 동일 과제 실행 기록, diff, 테스트 출력 및 리뷰 시간은 아직 없습니다. 같은 저장소와 수용 기준으로 두 경로를 실행하고 문서 작성·수정 시간과 코드 리뷰 시간을 따로 기록해 비교할 수 있습니다. 이는 실험 제안이지 측정 결과가 아닙니다.

Kiro 없이 스펙 주도 개발하기#

Kiro 없이도 요구사항을 문서로 고정하고 설계·작업·테스트를 연결하는 방식으로 개발할 수 있습니다. 일반 편집기와 Git에서 requirements.md, design.md, tasks.md를 관리하면 됩니다. Kiro의 자동 생성·추적 기능을 그대로 복제하거나 기존 Spec을 자동 이전한다는 뜻은 아닙니다. 아래는 실행 결과가 아니라 도구에 종속되지 않는 제안 절차입니다.

1. requirements.md에 바꿀 동작, 유지할 동작과 수용 기준을 씁니다. ‘사용하기 편해진다’보다 입력과 기대 결과를 구체적으로 적습니다.
2. design.md에 변경할 모듈과 API·데이터 계약, 영향을 받는 호출부와 되돌리는 방법을 연결합니다. 구현 전에 팀이 검토할 수 있게 같은 변경 요청에 보관하세요.
3. tasks.md의 작업마다 요구사항 식별자와 검증 명령을 붙입니다. 문서를 만들었다는 이유로 완료 표시하지 말고, diff와 실제 테스트 결과를 확인한 뒤 상태를 바꿉니다.
4. 구현 중 조건이 바뀌면 요구사항과 설계부터 갱신합니다. 실패한 테스트와 실행하지 못한 검사도 남기고 사람이 수용 기준 충족 여부를 확인합니다.

파일 역할은 위 Kiro 공개 요구사항·설계·작업 샘플을 참고했습니다. 위 순서는 이 글의 제안이며 Kiro가 검증한 대체 절차가 아닙니다. Mirr Code를 쓰더라도 기능 구현 안내에 따라 유지할 동작과 테스트를 명시하고, 실제 결과는 별도로 검토하세요. 이 방식이 더 빠르다거나 문서 유지 비용이 줄어든다는 측정 결과는 아직 없습니다.

가격: 구독료와 모델 사용료#

2026-11-01 확인한 Kiro 공개 가격 기록입니다. 조회 지역과 세금 포함 여부는 확인하지 못했고, 추가 사용 조건은 결제 전에 확인하세요.

Mirr 공개 요금 조회(2026-11-02 03:13 KST): 요금 조회 응답은 Pro 월 29,000원, Max 월 49,000원을 표시합니다. 모델 식별자와 제공 범위는 없으며, 지역·세금은 결제 화면에서 확인하세요. Max라는 이름만으로 무제한이라고 단정할 수 없습니다.

Mirr의 요금 페이지와 그곳에서 연결되는 현재 결제 화면의 금액·세금·조건을 확인하세요. 결제 화면은 이 비교에서 직접 검증하지 않았습니다.

옮기는 방법: 설치, 규칙, MCP, 첫 작업#

기존 .kiro/specs/ 문서는 옮기기 전에 보존하고, 어떤 산출물을 계속 관리할지 팀이 먼저 정합니다. 생성된 요구사항·설계·작업 파일이 있다는 사실만으로 각 단계가 승인됐다고 보지 마세요.

스펙이 자산인지 부담인지 가르는 질문#

Kiro 대안을 고를 때는 문서가 몇 개 생기는지보다 그 문서를 누가 다시 읽는지 살펴보세요. 요구사항을 합의할 사람이 있고 구현 뒤에도 변경 이유를 찾는 팀이라면 남는 문서의 가치가 있을 수 있습니다. 반대로 생성된 문서를 아무도 갱신하지 않으면 현재 코드와 다른 설명을 관리하게 됩니다. 아래 내용은 팀의 검토 방식을 정리하는 제안이며 문서 작성이나 리뷰 시간의 실측 결과는 아닙니다.

최근 변경 하나를 골라 요구사항을 어디에서 확인했는지 적습니다. 이슈, 대화, 설계 문서와 테스트에 서로 다른 조건이 남아 있다면 우선 기준을 정하세요. Kiro를 쓰든 다른 도구를 쓰든 어떤 문서가 최종 요구를 설명하는지 정하지 않으면 구현 결과를 판단하기 어렵습니다. 도구를 바꾸는 일과 요구사항의 권위를 정하는 일을 구분하세요.

문서를 유지할 담당자도 필요합니다. 개발자가 코드만 바꾸고 문서는 다른 사람이 나중에 고치는 방식이라면 그 전달 단계를 작업에 포함해야 합니다. 반대로 구현자가 요구사항과 설계를 함께 갱신한다면 리뷰에서 두 변경을 연결해 볼 수 있습니다. 어느 방식이 항상 빠르다고 말할 근거는 없습니다. 실제 팀에서 누가 어떤 판단을 맡는지 기록한 뒤 비교하는 편이 좋습니다.

스펙이 필요한 변경과 짧은 이슈 설명으로 충분한 변경을 나눌 수도 있습니다. 기존 계약을 유지하는 문구 수정과 여러 모듈의 동작을 바꾸는 기능은 검토 범위가 다릅니다. 모든 작업에 같은 문서 양을 요구하지 않으면서도 필수 수용 기준은 남겨 보세요. 문서를 생략한 경로에서도 코드의 기대 동작까지 생략하면 공정한 비교가 되지 않습니다.

Quick Spec의 산출물과 승인 단계를 구분하기#

출처 확인(2026-11-02): Kiro Quick Spec 문서. 문서는 요구사항·설계·작업 산출물을 유지하면서 단계 사이의 승인 게이트 없이 생성하는 흐름을 설명합니다. 따라서 세 파일이 있다는 사실만으로 각 단계가 사람에게 승인됐다고 판단해서는 안 됩니다. 공개 샘플은 파일 형식을 보여 주는 자료일 뿐, 어떤 팀이 그 과정을 수행했다는 기록이 아닙니다.

승인이 중요한 팀이라면 어떤 지점에서 사람이 무엇을 확인했는지 따로 남기세요. 요구사항 검토는 사용자 동작과 예외 조건을 보는 일이고 설계 검토는 변경할 계약과 영향 범위를 보는 일입니다. 작업 목록 검토에서는 검증과 복구가 빠지지 않았는지 살필 수 있습니다. 파일을 읽었다는 표시와 그 내용에 동의했다는 판단을 같은 체크 표시로 묶지 않는 편이 좋습니다.

스펙을 한 번에 생성한 뒤 검토하는 흐름을 택하더라도 수정한 조건을 기록하세요. 사람이 요구사항을 고쳤다면 설계와 작업 목록도 그 조건을 반영하는지 확인하세요. 문서 하나만 최신이고 나머지는 이전 조건이면 에이전트에 상충하는 지시를 줄 수 있습니다. 이 문제는 Kiro를 떠난다고 자동으로 사라지지 않으므로 새 도구에서도 같은 연결을 검토하세요.

요구사항·설계·작업을 잇는 합성 예제#

다음은 이 글이 직접 구성한 가상 문서 예제이며 Kiro가 생성한 출력이나 실행 결과가 아닙니다. 입력 파일 재고.csv에는 상품,수량 헤더와 연필,2, 지우개,0, 노트, 세 행이 있습니다. 원본은 읽기만 하고 결과는 별도 자료로 반환합니다. 빈 수량을 0으로 간주하지 않는 것이 초기 요구입니다. 외부 서비스와 업무 데이터는 없습니다.

requirements.md에 들어갈 가상 항목은 다음과 같습니다. R-valid: 수량이 정수 문자열이면 0을 포함해 그대로 읽는다. R-empty: 수량이 빈 문자열이면 해당 행을 EMPTY_QUANTITY로 분류한다. R-source: 입력 파일은 수정하지 않으며 한글 상품명을 보존한다. R-negative: 음수는 NEGATIVE_QUANTITY 오류다. 정상 두 행과 잘못된 행이 어떻게 다른지 코드 없이도 검토할 수 있습니다.

design.md의 제안은 입력 파서와 행 검증기를 나누는 것입니다. 파서는 쉼표로 나뉜 문자열을 보존하고, 검증기는 빈 문자열·정수·음수를 순서대로 분류합니다. 호출부는 정상 행과 오류 행을 별도 목록으로 받되 기존 응답 필드 이름은 바꾸지 않습니다. 구현자가 빈 문자열을 숫자로 먼저 변환하면 R-empty를 놓칠 수 있으므로 변환 순서가 설계의 실제 선택이 됩니다.

tasks.md의 가상 작업은 파서 입력 보존, 빈 값 검증, 0과 음수 테스트, 원본 불변 검사의 네 부분입니다. 각각 R-source, R-empty, R-valid/R-negative, R-source에 연결합니다. 이 문서에 완료 표시를 넣지는 않습니다. 여기까지는 예제의 설계이며 파일을 생성하거나 테스트를 돌린 것이 아닙니다. 공개 Kiro 샘플과 이 가상 예제, 실제 팀이 생성할 Spec은 서로 다른 자료입니다.

구현 중 요구가 바뀌었을 때#

팀이 “빈 값은 판매 중단 상품이므로 건너뛴다”로 요구를 바꿨다고 가정합니다. R-empty는 오류 분류에서 제외 행 분류로 바뀝니다. 설계에서는 검증기가 오류 대신 skip 상태를 반환해야 하고, 작업 목록의 빈 값 테스트도 그 상태를 기대하도록 바뀝니다. R-valid의 0은 여전히 유효하므로 0까지 건너뛰면 바뀐 요구를 너무 넓힌 것입니다. 이 추적은 문서가 많아지는 이유와 문서를 남길 가치를 함께 보여 줍니다.

변경 전후를 비교하면 “빈 값만 제외”와 “빈 문자열과 0을 같은 분기로 제외”는 다릅니다. 코드가 빈 문자열과 0을 같은 분기로 처리하면 새 R-empty는 맞아도 R-valid가 깨집니다. 요구사항 리뷰어는 두 상태를 구분하고, 설계 리뷰어는 검증기의 반환 상태가 호출부와 맞는지 봅니다. 어떤 문서가 결정을 바꿨는지 명확하므로 같은 검토 지침을 여러 번 적을 필요가 없습니다.

스펙 있음·없음의 리뷰 시간을 재는 법#

시간 비교를 하려면 무엇을 리뷰 시간으로 셀지 미리 정하세요. 문서를 읽는 시간, 코드 diff를 보는 시간과 누락을 찾아 다시 요청하는 시간을 나눠 기록할 수 있습니다. 스펙을 생성하는 동안 기다린 시간과 사람이 실제로 검토한 시간도 다릅니다. 이 글은 어떤 구간도 측정하지 않았으며 어느 경로가 더 짧다는 숫자를 제시하지 않습니다.

두 경로에 같은 시작 파일과 수용 기준을 줍니다. 스펙 없는 경로에서도 기대 동작과 금지 범위는 전달해야 합니다. 한쪽에는 자세한 문서를 주고 다른 쪽에는 모호한 한 줄만 주면 스펙의 효과와 입력 품질의 차이를 분리할 수 없습니다. 요청 내용과 사람이 추가로 준 설명을 그대로 보관하세요. 정답을 알려 준 시간도 검토와 수정 과정의 일부입니다.

과제 순서도 해석에 영향을 줄 수 있습니다. 같은 사람이 첫 결과에서 오류를 배운 뒤 두 번째 결과를 보면 더 빨리 찾을 수 있습니다. 가능하면 순서를 나누거나 그 한계를 기록하세요. 독립 검토자는 도구가 붙인 완료 표시보다 원래 수용 기준과 결과를 대조해야 합니다. 리뷰어의 이름이나 독립성을 실제로 확보하지 않았다면 임의로 붙여서는 안 됩니다.

결과에는 문서 분량과 함께 문서 때문에 찾은 누락, 문서와 코드가 달라 생긴 혼동을 남깁니다. 코드만 봐도 찾을 수 있었던 문제인지까지 완벽히 분리하기 어렵다면 그 한계를 설명하면 됩니다. 한 번의 과제로 팀 전체의 생산성 향상을 일반화하지 마세요. 어떤 유형의 변경에서 어떤 자료가 검토에 도움이 됐는지 좁게 쓰는 편이 재사용하기 좋습니다.

Kiro를 떠나도 남겨야 할 스펙#

도구를 바꾸기 전에 현재 스펙을 삭제하거나 새 형식으로 일괄 변환할 필요는 없습니다. 원본을 보존하고 계속 유효한 요구사항과 완료된 작업, 미완료 작업을 나눠 읽으세요. 새 도구가 기존 파일을 자동으로 추적한다고 전제하지 말고 필요한 문서의 위치와 우선순위를 명시합니다. 문서 읽기와 작업 상태 변경의 책임을 정하는 것이 먼저입니다.

출처 확인(2026-11-03): Kiro 훅 문서는 에이전트가 파일을 수정하거나 도구를 호출하고 작업을 끝내는 등 세션의 특정 이벤트가 발생하면 셸 명령이나 에이전트 프롬프트가 자동으로 실행된다고 설명합니다. 트리거와 동작은 사용자가 정의하고 실행은 Kiro가 담당하는 구조이며, 문서에는 IDE·CLI·Web·Mobile별 지원 여부를 표로 구분합니다. 스펙 파일과 별개인 이 자동화 경로는 새 도구에서 같은 이벤트를 지원한다고 전제할 수 없으므로, 이전 목록에서 문서 이전과 별도 항목으로 남기세요.

기존 스펙과 현재 코드가 다르면 어느 쪽이 맞는지 바로 단정하지 않습니다. 코드가 요구를 놓쳤을 수도 있고 문서가 실제 결정을 따라가지 못했을 수도 있습니다. 관련 변경 기록과 담당자 판단을 확인하고 차이를 남겨 두세요. 이전 과정에서 에이전트가 보기 좋게 문서를 고쳤다는 이유로 과거 결정까지 지워지지 않도록 주의해야 합니다.

Mirr Code를 검토한다면 한국어로 문서를 읽고 변경 계획을 설명하는 과제부터 시작할 수 있습니다. 이후 승인한 코드 범위와 테스트를 연결해 봅니다. 이것이 Kiro의 스펙 생성과 추적을 그대로 대체한다는 뜻은 아닙니다. 팀이 자동 추적에 의존한다면 그 기능을 별도 필수 조건으로 남기고 실제 지원과 동작을 확인하기 전에는 이전 완료로 쓰지 마세요.

스펙 리뷰에서 실제로 물어볼 질문#

위 예제에 대한 가상 리뷰 답안을 채워 보면 다음과 같습니다. 요구사항과 설계가 어긋날 때 무엇을 고쳐야 하는지가 각 행마다 다릅니다. 실제 리뷰에서 발견한 결과를 제시하는 표는 아닙니다.

여기서는 요구사항을 쓰는 역할과 코드 리뷰 역할이 다른 판단을 합니다. 상품 담당자는 빈 값의 뜻을 정하고, 구현 담당자는 그 뜻을 반환 상태에 반영하며, 리뷰어는 0과 음수의 기존 동작을 보존했는지 봅니다. Kiro의 스펙 흐름이 유용한 팀은 이런 결정을 파일에서 함께 보려는 팀입니다. 반대로 한 사람이 작은 수정을 끝내고 별도 문서를 거의 다시 읽지 않는다면 문서 유지 부담을 따로 볼 이유가 있습니다.

스펙과 이슈가 다른 말을 할 때#

이슈에는 “빈 상품은 건너뛴다”라고 쓰고 스펙에는 “빈 수량은 오류”라고 남아 있다면 먼저 상품과 수량을 구별해야 합니다. 상품명이 비었다는 새 요구인지, 기존 R-empty의 수량이 비었다는 뜻인지에 따라 구현이 다릅니다. 두 문장을 자동으로 같은 요구로 합치면 상품명이 빈 정상 수량 행의 처리가 결정되지 않습니다. 이 예에서 필요한 질문은 문서 갱신 여부보다 어떤 필드의 빈 값을 말하는가입니다.

팀이 새 요구를 “상품명만 비면 제외, 수량 빈 값은 오류 유지”라고 정했다면 새 항목 R-name을 만들 수 있습니다. 기존 R-empty를 삭제할 이유는 없습니다. 설계에는 상품명 검증을 추가하고, 작업에는 빈 상품명과 빈 수량이 동시에 있는 행의 우선 처리까지 선택해야 합니다. 이처럼 구체적인 모호성을 해결하는 일이 스펙 검토이며 세 파일이 있다는 사실 자체가 합의는 아닙니다.

문서가 많아질 때 남길 최소 연결#

가상 팀이 비슷한 CSV 기능을 여러 개 만든다면 공통 파서 설계는 한 곳에 두고, 스펙에는 각 업무의 빈 값 의미만 남길 수 있습니다. 재고에서 빈 수량은 오류지만 설문에서 빈 응답은 허용일 수 있기 때문입니다. 공통 구현을 재사용한다고 요구의 뜻까지 하나로 합칠 수는 없습니다. 같은 “빈 값” 용어가 업무마다 다른 선택을 만드는 예입니다.

Kiro를 떠나 수동 문서를 쓰는 안에서는 이런 참조를 사람이 유지하게 됩니다. Mirr의 한국어 설명을 선택할 수는 있어도 Kiro의 자동 생성·추적과 같은 기능을 확보했다고 표현하지 않습니다. 팀이 정말 필요한 것이 한국어 요청의 편의인지, 요구와 작업을 연결하는 제품 흐름인지에 따라 대안 선택이 달라집니다. 실제 리뷰 시간 비교는 아직 확인하지 못한 항목으로 남깁니다.

문서 비용과 모델 비용을 함께 정리하기#

문서를 많이 생성하면 비용이 늘어난다는 단정 대신 실제 사용량을 기록하세요. 선택 모델과 작업 크기, 재생성 횟수와 계약 조건에 따라 확인할 값이 달라집니다. Kiro 크레딧을 다른 서비스의 요청 수와 같은 단위로 환산하지 않습니다. 사람이 문서를 읽고 고친 시간도 모델 사용료와 별도 항목으로 남기면 어떤 부담을 줄이고 싶은지 설명하기 쉽습니다.

도입 판단은 세 파일의 존재보다 유지 가능한 검토 흐름을 기준으로 하세요. 요구사항을 함께 승인하고 이후 변경 이유를 찾는 팀에는 스펙 흐름을 유지할 이유가 있습니다. 짧은 과제에서 별도 문서가 과한지 살펴보는 팀은 제한된 대체 경로를 시험할 수 있습니다. 실제 비교가 없으면 그 판단은 가설로 남겨 두고 결과와 독립 검토를 확보한 뒤 범위를 넓히면 됩니다.

요구사항마다 검증 담당자가 다른 경우에는 그 역할도 적어 두세요. 코드 테스트로 확인하는 동작과 사람이 문서를 읽어 확인하는 조건이 섞일 수 있습니다. 한 담당자의 완료 표시를 다른 검토까지 끝났다는 뜻으로 읽지 않으면 남은 일을 더 정확히 찾을 수 있습니다.

스펙 없는 경로에도 남길 완료 근거#

스펙 없는 가상 경로에는 세 파일 대신 다음 요청 한 묶음을 줄 수 있습니다. “연필 2와 지우개 0은 정상, 노트의 빈 수량은 EMPTY_QUANTITY, 음수는 NEGATIVE_QUANTITY, 원본은 읽기만 한다.” 이 네 조건은 스펙 경로와 같습니다. 차이는 정답 조건의 양이 아니라 별도 문서와 승인 흐름을 쓰는지입니다. 한쪽에만 이 상세 조건을 주면 문서 형식의 비교가 아니라 입력 품질의 비교가 됩니다.

이 상태에서 코드가 0을 누락했다면 두 경로 모두 같은 요구를 놓친 것입니다. 스펙 경로에서는 R-valid와 설계를 찾아 원인을 살피고, 짧은 요청 경로에서는 원래 문장을 다시 읽어 같은 조건을 대조합니다. 어느 쪽이 실제 리뷰에 도움이 됐는지는 사람이 사용한 시간과 찾은 누락을 관찰해야 합니다. 이 글은 그 측정을 수행하지 않았습니다. 대신 두 경로가 무엇을 공유하고 무엇만 다르게 선택하는지 구체적인 입력으로 보여 줍니다.

표준 Spec과 Quick Spec을 고르는 기준#

Spec 안내는 단계별 검토 경로를 설명하고, Quick Spec은 단계 사이의 승인 없이 요구사항·설계·작업 파일을 만든다고 설명합니다. 두 경로는 파일 형식이 비슷해도 승인 기록이 다르므로, 같은 파일이 있다는 이유로 같은 검토를 거쳤다고 보지 않습니다.

승인 기록을 남겨야 하는 팀은 단계별 검토 경로를 따로 정하고, 작은 과제에서 한 번에 생성된 문서를 쓸지는 팀의 변경 관리 방식으로 판단하세요. 생성된 문서를 누가 다시 읽고 갱신하는지도 함께 적으세요. Quick Spec으로 만든 파일은 승인 전 초안으로 표시해 두면 다음 검토자가 완료본과 혼동하지 않습니다. 이 페이지는 어느 경로가 리뷰 시간을 줄이는지 아직 측정하지 않았습니다.

수정·보완 기록#

출처 범위: 공식 스펙 예시와 이 글의 가상 문서 예제를 구분했습니다. 요구사항·설계·작업 파일의 존재는 리뷰 시간 단축이나 감사 적합성의 측정 결과가 아니며, 생성된 산출물과 리뷰 시간 측정은 이 페이지에 없습니다.

검증일 · 출처 · 관련 페이지#

Kiro 파일 구조는 공식 스펙 문서와 공식 저장소의 실제 스펙 예시에서 2026-11-02 확인했습니다. 두 경로의 동일 과제 실행 및 리뷰 시간 측정은 아직 없습니다.

그래서 Mirr Code는?#

한국어 중심 터미널 코딩 에이전트입니다. 한국어로 코드 조사와 리뷰를 요청하는 흐름에 초점을 둡니다.

명시적인 스펙 생성과 추적이 중심이라면 Kiro가 더 적합할 수 있습니다. 현재 금액과 결제 조건은 요금 페이지에서 확인하세요.

관련#

• 기능 구현하기