우로보로스 vs 가재코드 — 5개 축 10점 채점, 그리고 채점할 수 없었던 것
지난 7월에 두 도구의 구조를 비교했습니다 — 두 하네스, 두 무게중심. 결론은 “Gajae-Code는 런타임을 소유하고(destination), Ouroboros는 런타임을 위임한다(layer)” 였고, 거기엔 점수가 없었습니다.
이 글은 그 빠진 점수판입니다. 다만 채점에는 규칙이 필요합니다.
이 글의 채점 규칙
- 점수는 실측 데이터가 있는 항목에만 매긴다. 근거 없는 축은
미측정으로 표기하고, 왜 못 쟀는지 밝힌다. - 인상은 점수가 아니다. 각 점수 옆에 그 숫자를 만든 원자료를 붙인다.
- 불리한 데이터를 빼지 않는다. 내가 주력으로 쓰는 도구라도 나쁜 수치는 그대로 적는다.
그리고 미리 밝혀 둘 가장 중요한 한계 — 이 글은 두 도구의 head-to-head 벤치마크가 아닙니다. 중립적인 제3자 비교 벤치마크는 (2026-08-09 기준) 존재하지 않고, 저 역시 동일 과제를 두 도구에 각각 물려 본 적이 없습니다. 아래 점수는 Ouroboros 에 대한 제 실사용 로그의 채점이고, Gajae-Code 는 1차 출처 기반 사실 기술입니다. 둘을 같은 표에 나란히 놓지 않은 이유가 그것입니다.
1부. Ouroboros 채점
근거가 된 데이터
Q00/ouroboros 리포에 PR 을 올리며 쌓인 리뷰 로그를, 제가 만든 로컬 드라이버(ouropr)가 JSONL 로 기록해 왔습니다. 2026-08-09 기준 원자료는 이렇습니다.
| 항목 | 값 |
|---|---|
| 기록된 리뷰 라운드 | 72 |
| 봇이 낸 blocker 총합 | 94 |
| 대상 PR | 8건 (1734, 1775, 1776, 1828, 1837, 1893, 1895, 1915) — 전부 merged |
| 판정 분포 | REQUEST_CHANGES 59 / APPROVE 13 |
| PR별 라운드 | 1837: 34, 1734: 25, 1775: 4, 1915: 3, 1828: 2, 1895: 2, 1776: 1, 1893: 1 |
| PR별 blocker | 1734: 44, 1837: 46, 1775: 2, 1828: 1, 1915: 1, 나머지 0 |
여기에 별개로, 다른 레포(settlement)에서 ooo auto 를 실제 실행해 남은 트레이스 파일 1건이 있습니다.
유용성 — 7 / 10
올린 점수의 근거: 94개 blocker 는 인상이 아니라 파일에 남은 지적이고, 그중 상당수가 fail-open — “실패했는데 성공으로 보고되는” 결함 계열이었습니다. 이 계열은 테스트 커버리지로 잘 안 잡힙니다. 통과했다고 말하는 코드가 통과 여부를 확인한 적 없는 경우이기 때문입니다. 8개 PR 이 전부 머지됐으니 지적이 공허하지도 않았습니다.
깎은 점수의 근거: 정작 자기 자신의 실행 결과 보고에서 같은 계열 결함이 관측됐습니다. settlement 레포에 남은 실행 트레이스(.ouroboros/traces/auto_833c600890c9/outcome.json)는 이렇게 끝났습니다.
{
"status": "blocked",
"blocker": "Seed QA timed out after 90s",
"grade": "A",
"degraded": false,
"qa": { "passed": null, "score": null, "verdict": null }
}
QA 가 90초 타임아웃으로 아예 돌지 못했는데, 같은 파일이 grade: "A" 와 degraded: false 를 함께 기록했습니다. 등급이 매겨질 근거(qa.score)가 null 인데 등급은 A 입니다. 리뷰 봇이 남의 코드에서 잡아내는 바로 그 패턴입니다.
상황 적합성 — 6 / 10
맞는 상황: 목표를 얼려서 문서로 고정할 수 있는 작업. 스펙이 먼저 서고 구현이 뒤따르는 종류입니다. 그리고 “됐다고 말하는 것”과 “된 것”의 차이가 비싼 도메인 — 정산, 결제, 검증 로직.
안 맞는 상황: 탐색적 작업. 목표가 대화 중에 바뀌는 일이라면 seed 를 다시 만드는 비용이 얻는 것보다 큽니다.
6점인 이유는 커버리지 폭이 좁아서입니다. 넓은 도구가 아니라 깊은 도구입니다.
사용자 진입장벽 — 4 / 10 (낮을수록 어렵다는 뜻)
이 축의 점수가 가장 낮고, 근거도 가장 직접적입니다. 저는 이 루프를 버티기 위해 별도 도구를 만들어야 했습니다. ouropr 은 현재 76KB 짜리 파이썬 단일 파일이고, 리뷰 라운드 기록·게이트 검사(A1–A12)·과거 blocker 입력 재현(corpus replay) 을 담당합니다. 도구를 쓰기 위해 도구를 만들어야 했다면, 그건 진입장벽에 대한 정직한 측정치입니다.
추가로 알아야 하는 것들: probe 종료코드 규약(0=막힘 / 1=반례 / 77=대상 없음), 리포 자체의 CI 게이트 4종, PR 본문 이슈 링크 규칙, 그리고 사람의 APPROVE 리뷰는 머지 권한이 없다는 규칙.
성능(수렴 효율) — 5 / 10
라운드당 승인율은 13/72 = 18% 입니다. 다섯 번 돌려 한 번 통과합니다.
가장 극단적인 사례가 PR 1837 입니다. +2104 / −6 짜리 변경 하나에 34 라운드, blocker 46개, 그것도 46개 전부가 같은 파일 하나에서 나왔습니다. 그 46개는 서로 다른 34개 라인에 걸쳐 있었고 12개는 완전히 같은 지적의 반복이었으며, 하루(2026-08-05)에만 26 라운드가 몰렸습니다. 봇이 CPython 정규식 opcode 공간을 하나씩 걸어 내려가며(AT / AT_BOUNDARY / GROUPREF / BRANCH / lookaround …) 매번 새 반례를 찾아내는 형태였습니다.
비교군으로, 상태 공간 자체를 제거한 PR 1898(+424 / −127)은 봇 리뷰 첫 판에 APPROVE 였습니다. 크기 차이가 아니라 성질 차이입니다. 없앤 변경은 빨리 통과하고, 새 표면을 늘린 변경은 봇이 그 표면을 끝까지 걸어 봅니다.
낮은 승인율이 곧 나쁜 도구라는 뜻은 아닙니다. 다만 “빠르다”는 이 도구의 미덕이 아닙니다.
내 워크플로우 적합성 — 6 / 10
제가 실제로 유지하는 레포(정산 도메인, MSA 학습 레포, XR 프로젝트) 중 이 도구의 이득이 비용을 넘는 곳은 검증 로직이 핵심 자산인 레포뿐이었습니다. 나머지에서는 seed 를 세우는 비용이 회수되지 않습니다.
그리고 스스로 발견한 가장 큰 누수 — 제가 기록한 94개 blocker 중 47개가 사전 감사(audit) 없이 들어간 라운드에서 나왔습니다. 정확히 절반입니다. 도구 탓이 아니라 제 운용 탓이지만, “적합성”은 도구 혼자 만드는 값이 아니라 운용자와의 조합에서 나오는 값이므로 여기에 반영했습니다.
Ouroboros 종합
| 축 | 점수 | 한 줄 근거 |
|---|---|---|
| 유용성 | 7 | 94 blocker / 8 PR 전부 머지, 그러나 자기 보고에서 동일 계열 fail-open 관측 |
| 상황 적합성 | 6 | 스펙 고정 가능 + 검증이 비싼 도메인에 한정 |
| 사용자 진입장벽 | 4 | 루프를 버티려고 76KB 외부 드라이버를 따로 제작 |
| 성능(수렴) | 5 | 승인율 18%, 최악 34라운드/1PR |
| 워크플로우 적합성 | 6 | 이득이 비용을 넘는 레포가 일부, blocker 절반이 무감사 라운드에서 발생 |
| 평균 | 5.6 |
2부. 가재코드 — 왜 점수를 매기지 않았나
먼저, 제 사용량의 실측치
제 맥에 gjc 는 설치돼 있습니다(gjc/0.11.3). 그리고 로컬 상태 디렉터리를 열어 보면 사용 이력이 정확히 이만큼 남아 있습니다.
- 로그 파일: 하루치 단 하나 —
2026-07-20 - 그날의 활동 구간: 06:45 – 07:06, 약 21분
- 그 안에서 생성된 세션: 13개 (모두 한 개의 실험용 디렉터리)
- 그 이후 오늘까지 추가 사용 기록 없음
21분짜리 첫인상으로 유용성·성능·적합성에 10점 만점을 매기는 건 채점이 아니라 창작입니다. 그래서 가재코드의 5개 축은 전부 미측정 입니다. 점수를 비워 두는 것이 이 글에서 제가 지킬 수 있는 유일한 정직입니다.
| 축 | 점수 | 사유 |
|---|---|---|
| 유용성 | 미측정 | 완주한 실제 과제 0건 |
| 상황 적합성 | 미측정 | 단일 실험 디렉터리 외 적용 이력 없음 |
| 사용자 진입장벽 | 미측정 | 21분은 학습곡선을 관측하기에 부족 |
| 성능 | 미측정 | 수렴 라운드·소요시간 원자료 없음 |
| 워크플로우 적합성 | 미측정 | 실 레포 투입 이력 없음 |
대신 확인 가능한 1차 사실
공식 리포와 공식 사이트에서 직접 확인되는 것만 적습니다 (2026-08-09 조회 기준).
| 항목 | 값 |
|---|---|
| 라이선스 / 언어 | MIT / TypeScript 91.3%, Rust 6.9% |
| 생성일 | 2026-05-26 |
| 스타 / 포크 / 기여자 | 2,043 / 285 / 90명 |
| 릴리스 | 57건, 최신 v0.11.1 (2026-07-16) |
| 설치 | bun install -g gajae-code, 또는 Linux x64/arm64 · Windows x64 · macOS arm64/x64 사전빌드 바이너리 |
| 자기 규정 | “external coding-agent harness” — Codex CLI/Claude Code 의 플러그인이 아님을 명시 |
| 핵심 워크플로우 | deep-interview → ralplan → ultragoal (병렬 작업 시 tmux 워커 팀 실행 옵션) |
| 부가 표면 | rlm(Jupyter 스타일 리서치 모드), computer-use(실험적 데스크톱 제어), Telegram/Discord/Slack 알림 데몬, SDK |
특히 인용해 둘 만한 건 리포가 스스로 붙인 경고문입니다.
“Gajae-Code is an experimental, beta-stage project. Expect rough edges and verify outputs before relying on it for important work.” — 공식 README
프로젝트 스스로 beta 라고 밝히고 있으므로, 안정성에 대한 제 침묵은 비판이 아니라 출처 존중입니다.
눈에 띄는 구조적 수렴
점수와 별개로 기록해 둘 관찰 하나. 두 도구의 파이프라인이 이름만 다르고 형태가 거의 같습니다.
Ouroboros : interview → seed → run/evaluate → evolve
Gajae-Code : deep-interview → ralplan → ultragoal
둘 다 “코드를 쓰기 전에 의도를 먼저 확정한다” 는 같은 전제에서 출발합니다. 서로 다른 팀이 독립적으로 같은 형태에 도달했다는 건, 이게 취향이 아니라 이 문제 영역의 구조적 요구에 가깝다는 신호로 읽힙니다.
갈라지는 지점은 7월 글에서 이미 짚은 그대로입니다. 가재코드는 런타임을 자기가 소유하고(자체 TUI·워커·툴 경계), 우로보로스는 런타임을 남에게 위임한 채 스펙 준수도만 측정합니다.
결론
- Ouroboros 는 느리고 진입장벽이 높은 대신, 다른 방법으로는 안 잡히는 결함 계열을 잡습니다. 평균 5.6점은 낮은 점수지만, 그 5.6은 실측에서 나온 5.6입니다.
- 가재코드는 채점하지 않았습니다. 21분 사용 이력으로 매긴 점수는 아무에게도 쓸모가 없습니다.
- 두 도구의 우열을 이 글에서 주장하지 않습니다. 중립 벤치마크가 없고, 제 데이터는 한쪽에만 있습니다.
다음 글이 있다면, 동일 과제를 두 도구에 각각 물려 라운드 수와 소요 시간을 같은 기준으로 기록한 뒤의 이야기가 될 것입니다. 그때는 가재코드 칸도 채워집니다.
References
- Q00, Ouroboros — https://github.com/Q00/ouroboros (리뷰 로그 원자료의 대상 리포, PR #1734·1775·1776·1828·1837·1893·1895·1915)
- Yeachan-Heo, Gajae-Code — https://github.com/Yeachan-Heo/gajae-code (MIT, 2026-08-09 조회)
- Gajae-Code 공식 문서 — https://gajae-code.com
- 본인 로컬 실측:
ouropr리뷰 로그 JSONL (72 라운드 / 94 blocker),settlement레포ooo auto실행 트레이스outcome.json,gjc로컬 로그2026-07-20(13 세션 / 21분) - 이전 글: 두 하네스, 두 무게중심 — Gajae-Code의 하네스 요소 vs Claude Code Ouroboros 비교분석
면책: 두 도구에 대한 중립적 제3자 head-to-head 벤치마크는 이 글 작성 시점에 확인되지 않았습니다. 1부의 점수는 저자 한 사람의 운용 로그에 기반한 것이므로 일반화된 도구 평가가 아니며, 2부는 의도적으로 점수를 부여하지 않았습니다. 수치는 2026-08-09 기준이며 두 프로젝트 모두 활발히 변경 중입니다.