AI 코딩 도구에 “주문 취소 기능 만들어 줘”라고 하면 코드는 금방 나온다. 문제는 그 다음이다. 취소 가능 상태는 어디까지인가? 환불 요청이 두 번 오면? 정산이 이미 끝났다면? 질문이 뒤늦게 나오면 구현한 코드를 다시 걷어내야 한다.

가재코드, Kiro, Ouroboros의 Seed는 모두 이 문제를 다루지만 같은 종류의 물건은 아니다. 가재코드는 에이전트를 굴리는 환경, Kiro는 명세를 만들고 구현하는 개발 환경, Ouroboros는 요구를 Seed로 고정하고 실행 결과를 다시 평가하는 워크플로 엔진이다. 셋을 IDE 성능 순위처럼 놓으면 비교가 어긋난다.

아래 내용은 2026년 9월 28일 공개된 각 프로젝트의 문서를 기준으로 정리했다. 세 도구에 동일 과제를 넣어 속도나 코드 품질을 측정한 벤치마크는 아니다.

먼저, 무엇을 사거나 설치하는가

기준 가재코드(Gajae-Code) Kiro Ouroboros Seed
정체 여러 모델·코딩 플랜을 연결하는 독립 코딩 에이전트 하네스 IDE·CLI·웹에서 명세와 구현을 다루는 개발 환경 다양한 에이전트 위에서 돌아가는 명세 우선 워크플로 엔진의 핵심 산출물
주로 마주하는 화면 터미널의 gjc, 외부 메시지 채널 VS Code 기반 IDE, CLI, 웹 ooo 명령 또는 연결한 에이전트
요구사항을 다루는 방식 인터뷰 → 계획 → 비평 → 승인 후 변경 요구사항·설계·작업 목록을 파일로 작성하고 실행 인터뷰로 모호함을 줄인 뒤 Seed로 의도를 고정
남는 핵심 흔적 계획·실행 증거와 에이전트 작업 맥락 requirements.md, design.md, tasks.md Seed, 실행·평가 이력(Ledger)
강점이 드러나는 곳 여러 구독/모델을 쓰고, 원격에서 에이전트 질문에 답하는 작업 팀이 읽고 고칠 요구사항·설계·작업 목록이 필요한 기능 개발 긴 작업에서 처음 합의한 목표와 평가 이력을 추적할 때
주의할 점 프로젝트 스스로 실험적 베타라고 밝힘. 구독 로그인 지원이 곧 모든 플랜의 무제한 사용을 뜻하지는 않음 문서가 생겼다는 사실만으로 요구가 정확해지지는 않음 Seed를 잘못 정하면 일관되게 잘못된 목표를 향할 수 있음

Seed는 별도 IDE가 아니다. Ouroboros의 명세 산출물이다. Kiro 안에서 Ouroboros 인터뷰를 돌리는 예시도 공식 저장소에 있으므로, 둘은 상호 배타적인 선택지가 아니다.

같은 요청을 넣으면 어디서 멈추는가

예를 들어 “주문 취소 API를 만들어 줘”라고 요청해 보자.

가재코드에서는 먼저 인터뷰로 범위를 좁히고 계획을 비평한 다음 변경 승인 지점을 둔다. 모델을 어느 공급자로 쓸지, 작업 중 생긴 질문에 터미널 밖에서 어떻게 답할지도 제품의 중요한 부분이다. 즉 명세뿐 아니라 에이전트를 어떻게 운영할지에 무게가 있다.

Kiro에서는 요구사항의 수용 기준을 requirements.md에 남기고, design.md에 구조와 예외 흐름을, tasks.md에 실행 단위를 둔다. 현재 공식 문서는 요구사항 우선과 설계 우선 흐름을 모두 안내한다. 빨리 초안을 만들 때는 Quick Spec으로 세 파일을 한 번에 생성할 수도 있다. 개발자가 파일을 읽고 고쳐 가며 작업의 기준으로 삼기 쉽다.

Ouroboros에서는 인터뷰로 “취소”의 의미를 먼저 캐묻고, 답을 Seed에 담아 실행 기준을 고정한다. 실행 결과는 평가 단계로 넘어가며, 부족한 부분은 다음 세대의 Seed를 만드는 입력이 된다. 공식 설명의 흐름은 interview → crystallize → execute → evaluate → evolve다. 여기서 핵심은 문서 세 장의 형식보다 무엇을 성공이라고 볼지, 그 약속에서 구현이 벗어났는지다.

이를 실제 요구로 바꾸면 이런 질문이 먼저 나와야 한다.

  • 배송 준비 전까지만 취소 가능한가, 부분 취소도 가능한가?
  • 동일 요청이 두 번 들어올 때 환불과 재고 복원은 한 번만 수행되는가?
  • 외부 결제사가 실패하면 주문 상태와 정산 상태는 어떻게 남는가?
  • 완료의 증거는 어떤 테스트와 운영 지표로 확인하는가?

도구가 질문을 대신 제기할 수는 있다. 답의 책임까지 대신 지지는 않는다.

셋의 “스펙 드리븐”은 같은 말이 아니다

Kiro의 Spec은 사람이 검토할 수 있는 개발 문서와 작업 관리에 가깝다. 요구사항에서 설계와 구현 작업으로 이어지는 경로가 눈에 보인다. 사내 기능 개발이나 인수인계에서 이점이 크다.

Ouroboros의 Seed는 에이전트가 실행 중 지켜야 할 계약과 평가의 출발점에 가깝다. 결과를 평가하고 다음 시도로 이어 가는 구조까지 포함한다. 긴 작업이나 반복 개선에서 매번 프롬프트를 새로 설명하는 비용을 줄이려는 접근이다. 다만 “불변”이라는 말은 요구 변경이 금지된다는 뜻으로 읽으면 곤란하다. 실행 중인 세대의 기준을 고정하고, 변경은 다음 Seed와 이력으로 다루는 식이다.

가재코드도 계획 전에 인터뷰와 비평을 둔다. 그렇지만 제품의 차별점은 특정 명세 파일 형식 하나보다 코딩 플랜 연결, 모델 선택, 실행 통제, 터미널 밖의 응답 경로를 묶은 운영 경험에 있다. 따라서 “가재코드에는 스펙이 없고 Kiro에만 있다”는 식의 비교는 틀린다.

내 프로젝트에 대입하면

정산 기능을 만든다고 해 보자. 등급별 수수료, 역정산, 홀드백, 동일 거래의 중복 반영 금지는 한 줄짜리 프롬프트로 넘길 항목이 아니다.

  • Kiro에서는 요구사항마다 입력, 상태 전이, 예외, 수용 기준을 적어 팀원과 검토하겠다. 설계 파일에는 트랜잭션 경계와 외부 결제 연동 실패 흐름을 남긴다.
  • Ouroboros Seed에는 “동일 거래의 원장 반영은 한 번”, “대사 차이는 0원”, “실패 후 재시도해도 결과가 같다”처럼 실행과 평가가 붙을 수 있는 성공 조건을 고정하겠다.
  • 가재코드는 구현 에이전트를 여러 모델·구독과 함께 운영하거나, 장시간 작업 중 질문을 휴대폰에서 받아야 할 때 검토하겠다.

이것은 기능 소개를 실무 상황에 적용한 내 판단이다. 정산 시스템에서 세 도구를 동일 조건으로 돌려 본 결과는 아니다. 어느 쪽을 쓰든 금액의 정밀도, 멱등성, 대사 테스트와 실제 데이터 검증은 개발자가 책임져야 한다.

그래서 무엇을 고를까

IDE 안에서 요구사항부터 작업 목록까지 팀과 공유하려면 Kiro. 산출물이 파일로 남아 검토와 변경 이력을 관리하기 편하다.

여러 모델과 구독을 연결해 에이전트 작업 자체를 운영하려면 가재코드. 계획 승인과 원격 응답 경로까지 필요할 때 의미가 커진다.

모호한 목표를 계약으로 굳히고 실행·평가를 반복하려면 Ouroboros. Seed와 평가 이력이 필요한 긴 작업에서 성격이 분명하다.

그리고 조합도 가능하다. Kiro에서 요구사항을 정리하고 Ouroboros로 더 엄격한 인터뷰·평가 루프를 적용하거나, 가재코드를 실행 환경으로 쓰면서 별도 명세를 기준으로 둘 수 있다. 다만 도구를 겹쳐 쓴다고 자동으로 품질이 오르지는 않는다. 수용 기준 하나를 제대로 쓰고 실패 사례 하나를 재현하는 일이 먼저다.

참고 자료

확인 기준: 2026-09-28. 기능과 지원 범위는 버전에 따라 바뀔 수 있다.