개발 관련 스킬을 쓰면 좋은 코드가 나올까? (karpathy-guidelines, yagni, solid, yagni+solid, caveman, ponytail, lazycodex, oh-my-codex)

모두 codex - gpt 5.5 xhigh 로 테스트 했고,

실제 사용한 프롬프트와 완성된 코드는 너무 길어져서 추가하진 않았습니다.

 

----------------------------------------

 

실험 목적

이번 실험은 같은 구현 과제를 여러 AI 코딩 에이전트 세팅에 맡겼을 때 결과가 어떻게 달라지는지 보기 위한 비교 실험이다. 핵심 질문은 세 가지였다.

 

질문	확인하려는 것
토큰을 많이 쓰면 코드가 좋아지는가	token 사용량과 실제 품질의 관계
skill 또는 원칙 프롬프트가 결과를 바꾸는가	Codex 기본값, skill, SOLID/YAGNI 조합의 차이
workflow wrapper는 일반 Codex와 다른 흐름을 만드는가	wrapper-light와 workflow-full의 비용, 구조, 산출물 차이

 

평가는 구현 결과물 자체를 기준으로 했다.

에이전트가 작성한 보고서만 믿지 않고, 각 후보를 중앙 verification harness로 다시 검증했다.

공통 구현 조건

모든 variant에는 같은 세 가지 과제와 같은 운영 guard를 제공했다. 따라서 이번 결과는 "누가 숨은 문제를 우연히 발견했는가"보다 "같은 조건에서 누가 더 잘 구현했는가"에 가깝다.

과제	스택	핵심 요구
reservation	Spring Boot	회의실 예약 API, 같은 room의 시간 겹침 방지, 동시 요청 처리
orderapi	FastAPI	주문 생성/결제/취소 API, idempotency, 재고 무결성
kotlinboard	Kotlin Spring Boot	게시판 API, signup 권한 상승 차단, JWT 401, pagination

 

 

공통 guard는 다음과 같았다.

 

영역	guard
reservation	같은 room의 active overlap을 동시 create 요청에서도 막아야 한다.
orderapi	order create, payment, cancel에 idempotency 전략과 테스트가 있어야 한다.
kotlinboard	public signup으로 ADMIN 사용자를 만들 수 없어야 한다.
kotlinboard	invalid, malformed, tampered JWT는 protected API에서 401이어야 한다.
list endpoint	pagination을 구현하거나, 제외한다면 이유를 명시해야 한다.

 

각 과제는 first-attempt와 self-review 두 단계로 실행했다. self-review에서는 같은 variant의 첫 결과물을 다시 읽고, 같은 관점으로 자체 점검한 뒤 필요한 경우 코드를 수정하게 했다.

비교한 11개 variant

그룹	variant	설명
baseline	codex-default	별도 skill 없이 기본 Codex 지시
skill	karpathy-guidelines	Karpathy Guidelines 기준
skill	caveman-full	Caveman skill, full 옵션
skill	ponytail-full	Ponytail skill, full 옵션
principle prompt	solid-only	SOLID 원칙 중심
principle prompt	yagni-only	YAGNI 원칙 중심
principle prompt	solid-yagni-balanced	SOLID와 YAGNI를 함께 적용
wrapper-light	ohmycodex-wrapper-light	project-local Oh My Codex 환경에서 기본 Codex 실행
wrapper-light	lazycodex-wrapper-light	project-local LazyCodex 환경에서 기본 Codex 실행
workflow-full	ohmycodex-workflow-full	Oh My Codex workflow 를 반영한 실행
workflow-full	lazycodex-workflow-full	LazyCodex workflow 를 반영한 실행

실행 환경

실험을 위해 새로 둔 도구, wrapper, cache, Codex home은 모두 lab 내부 경로를 사용했다.

항목	경로
로컬 Gradle	tools/gradle/gradle-9.6.1
로컬 JDK 21	tools/jdk/temurin-21/jdk-21.0.11+10
Oh My Codex local install	tools/oh-my-codex
LazyCodex local install	tools/lazycodex
Oh My Codex local CODEX_HOME	tools/oh-my-codex/codex-home
LazyCodex local CODEX_HOME	tools/lazycodex/codex-home
prompt	prompts/
구현 결과물	outputs/
개별 보고서	reports/agent-reports/
token telemetry	reports/token-usage/
검증 결과	reports/orchestration/

 

다만 이 실험은 OS 수준의 완전 격리 실험은 아니다.

프로세스 환경에는 기존 사용자 경로가 일부 남아 있을 수 있다.

여기서 보장한 것은 실험을 위해 새로 설치하거나 저장한 항목을 lab 내부로 제한했다는 점이다.

최종 검증 결과

최종 산출물 기준으로 33개 후보를 검증했다.

항목	값
variants	11
tasks	3
최종 후보	33
phase report	66
token telemetry	66
P0	0
P1	0
P2	0
P3	0
P4	0

 

검증은 stack별로 나눠 실행했다.

stack	검증 방식
Python/FastAPI	project-local .venv의 python -m pytest
Java/Kotlin/Spring	lab 내부 Gradle과 JDK로 test --no-daemon

 

P0-P4 기준은 다음과 같이 적용했다.

등급	의미	예시
P0	실행 불가	compile 실패, test collection 실패
P1	보안/데이터 무결성	JWT 우회, 재고 oversell, 예약 race
P2	API contract 위반	잘못된 401/403/404/409 매핑
P3	유지보수성	과도한 결합, 부적절한 추상화
P4	스타일/비용	지나친 verbosity, token 과다

 

모든 최종 후보가 중앙 검증을 통과했으므로, 순위는 correctness보다 운영 guard의 깊이, 코드 구조, self-review로 잡은 문제, 비용, 확장성 리스크를 기준으로 갈렸다.

토큰 사용량

최종 수집된 token telemetry는 66개다.

variant	token files	total	noncached input	output	reasoning
lazycodex-workflow-full	6	28,993,091	898,552	180,171	41,102
lazycodex-wrapper-light	6	10,672,677	579,145	105,692	26,105
ohmycodex-wrapper-light	6	4,824,195	369,935	50,932	5,856
ohmycodex-workflow-full	6	4,594,495	343,448	69,799	7,514
karpathy-guidelines	6	2,621,221	310,793	52,508	6,868
ponytail-full	6	2,553,585	282,245	51,436	9,205
solid-only	6	2,411,583	223,585	54,622	6,172
yagni-only	6	2,407,501	190,561	49,132	5,611
codex-default	6	2,245,509	255,522	54,115	5,123
solid-yagni-balanced	6	2,009,278	263,150	50,768	4,219
caveman-full	6	1,714,780	235,537	48,843	5,703

 

토큰 관점에서 눈에 띄는 결과는 세 가지다.

solid-yagni-balanced는 전체 2번째로 낮은 total token을 쓰면서 best overall로 평가됐다.

caveman-full은 가장 적은 token으로 대부분의 요구를 만족했다.

lazycodex-workflow-full은 가장 많은 token을 썼고 최종 검증도 통과했지만, 비용 대비 효율은 낮았다.

따라서 이번 실험의 결론은 "토큰을 많이 쓰면 좋은 코드가 나온다"가 아니다.

더 정확히는 "토큰은 검토와 탐색의 여지를 늘리지만, 좋은 guard와 검증 없이 쓰이면 비용만 커질 수 있다"에 가깝다.

코드 규모

LOC 기준 코드 규모는 다음과 같았다.

variant	reservation LOC	orderapi LOC	kotlinboard LOC	합계 LOC	해석
ponytail-full	357	61	465	883	가장 작다. 간결하지만 분산 환경 설명력은 약한 부분이 있다.
ohmycodex-wrapper-light	473	97	570	1,140	코드 규모는 작고 결과도 안정적이다.
karpathy-guidelines	478	108	646	1,232	보수적이고 과한 추상화가 적다.
ohmycodex-workflow-full	487	104	682	1,273	비교적 작은 규모로 guard 대응이 좋다.
yagni-only	511	100	678	1,289	필요한 만큼만 구현하는 경향이 강하다.
caveman-full	527	105	716	1,348	낮은 token 대비 구조가 좋다.
solid-only	517	108	797	1,422	계층 분리는 좋지만 코드가 다소 커진다.
codex-default	607	122	742	1,471	baseline치고 강하지만 일부 운영 리스크가 남는다.
solid-yagni-balanced	586	118	828	1,532	중간 이상 규모지만 guard와 구조의 균형이 좋다.
lazycodex-wrapper-light	528	417	823	1,768	orderapi가 상대적으로 크고 token도 많이 쓴다.
lazycodex-workflow-full	643	657	844	2,144	가장 크고 가장 무겁다. 검증은 통과했지만 비용 부담이 크다.

작은 코드가 항상 좋은 것은 아니다.

ponytail-full처럼 작게 끝낸 후보는 읽기 쉽지만, 운영 환경의 분산 lock이나 idempotency race까지 설명하는 힘은 약할 수 있다.

반대로 lazycodex-workflow-full은 가장 많은 코드를 만들었지만, 그 규모가 곧 품질 우위로 이어지지는 않았다.

과제별 분석

reservation

reservation에서 가장 중요한 문제는 같은 room에 대한 동시 예약이다.

단순히 "겹치는 예약이 있는지 조회하고 insert"하면 race가 난다.

요청이 동시에 들어오면 두 요청이 모두 overlap이 없다고 판단하고 둘 다 insert할 수 있다.

좋은 방향은 DB-backed lock이었다.

solid-yagni-balanced, caveman-full, yagni-only, ohmycodex-workflow-full은 room별 lock row를 만들고, transaction 안에서 lock을 잡은 뒤 overlap check와 insert를 수행했다.

모든 app instance가 같은 DB를 공유한다는 전제에서는 JVM-local lock보다 설명력이 좋다.

codex-default와 ponytail-full은 JVM-local lock을 사용했다.

단일 인스턴스 테스트에서는 충분하지만, 여러 인스턴스로 scale-out하면 lock이 공유되지 않는다. MSA나 분산 환경에서 같은 room의 writer가 서로 다른 JVM에 있으면 race가 다시 생길 수 있다.

실제 서비스라면 여기서 더 나아가야 한다.

DB isolation level, lock timeout, deadlock 복구 전략, unique/exclusion constraint, idempotency key, observability, auth, rate limit이 필요하다.

이번 과제는 작은 API였기 때문에 모든 후보가 이 영역까지 완성한 것은 아니다.

orderapi

orderapi의 핵심은 idempotency와 재고 무결성이다.

좋은 구현은 같은 idempotency key와 같은 payload를 replay하고, 같은 key와 다른 payload는 409로 거부해야 한다.

주문 생성, 결제, 취소가 모두 이 원칙을 따라야 한다.

재고도 중요하다.

같은 주문 안에 동일 product가 여러 줄 들어오거나, 같은 상품에 주문이 동시에 몰릴 때 stock이 음수가 되면 안 된다.

이 문제는 단순 CRUD보다 운영 난도가 높다.

solid-yagni-balanced는 이 영역에서 가장 좋은 균형을 보였다.

self-review에서 duplicate product line이 stock 검증을 우회할 수 있는 문제를 잡고, aggregate stock validation을 추가했다.

codex-default도 idempotency unique constraint race를 보강해 losing transaction이 500으로 새지 않도록 했다.

간결한 variant들은 local smoke API 기준으로는 통과했지만, 실제 대용량 주문 시스템으로 확장하려면 더 많은 장치가 필요하다. row-level lock, atomic conditional update, idempotency ledger cleanup, payment provider idempotency propagation, outbox/event log까지 들어가야 한다.

kotlinboard

kotlinboard에서는 public signup으로 ADMIN을 만들 수 없어야 하고, 잘못된 JWT는 protected API에서 401이어야 한다.

여기에 게시글/댓글 ownership, pagination, delete cascade semantics도 중요하다.

대부분의 variant는 핵심 guard를 만족했다. 차이는 self-review에서 드러났다.

solid-yagni-balanced와 ponytail-full은 댓글이 달린 게시글 삭제가 FK 오류로 깨질 수 있는 문제를 잡았다.

사용자가 정상 API로 만든 상태에서 delete가 실패하는 문제이므로 API contract 관점에서 의미 있는 수정이었다.

codex-default는 duplicate signup race를 409로 매핑하도록 보강했다.

karpathy-guidelines는 로그인 실패와 JWT 실패의 status mapping을 더 보수적으로 정리했다.

운영 서비스 기준으로는 refresh token, token revocation, key rotation, rate limit, audit log, admin bootstrap, optimistic locking이 더 필요하다.

이번 후보들은 실험 과제의 경계 안에서 구현했으므로, 이 영역은 다음 단계의 보강 사항으로 보는 편이 맞다.

variant별 평가

solid-yagni-balanced

이번 실험의 best overall이다.

SOLID만 강조하면 구조가 커질 수 있고, YAGNI만 강조하면 운영 guard가 범위 밖으로 밀릴 수 있다.

두 원칙을 함께 주자 필요한 곳에는 구조를 만들고, 불필요한 곳에는 과하게 만들지 않는 방향으로 수렴했다.

reservation에서는 DB-backed lock과 concurrent test가 있었다.

orderapi에서는 idempotency와 stock validation을 균형 있게 다뤘다.

kotlinboard에서는 권한 상승 차단, JWT 401, pagination, delete semantics까지 비교적 고르게 챙겼다.

token도 2,009,278로 낮은 편이다.

caveman-full

가장 token 효율이 좋았다.

총 1,714,780 token으로 모든 최종 검증을 통과했다.

구현도 단순하고 읽기 쉬운 편이다.

다만 "운영에서 끝까지 버티는가"까지 보면 보강할 부분이 있다.

orderapi의 concurrent idempotency race나 payment provider 연계까지 깊게 들어가지는 않는다.

작은 API나 빠른 실험에는 강하지만, 대규모 트래픽 시스템의 기준으로는 한 단계 더 다듬어야 한다.

codex-default

기본값치고 결과가 좋았다.

token 사용량도 2,245,509로 낮은 편이다.

orderapi에서는 idempotency race를 보강했고, kotlinboard에서도 duplicate signup/status mapping을 다뤘다.

감점 요소는 reservation의 single-JVM lock이다.

로컬 테스트에서는 통과하지만, 여러 instance가 같은 DB를 공유하는 운영 구조에서는 lock이 공유되지 않는다.

baseline으로는 강하지만, 분산 환경 관점에서는 best로 보기 어렵다.

ohmycodex-workflow-full

전체적으로 안정적인 결과를 냈다.

token은 4,594,495로 중간 이상이지만, 코드 규모는 1,273 LOC로 비교적 작았다.

reservation과 board API에서 guard 대응도 좋았다.

다만 workflow-full이라는 이름만으로 더 강한 결론을 내리기는 어렵다.

이번 실험은 이 환경에서 나온 결과물을 비교한 것이지, wrapper 제품 전체의 모든 workflow 기능을 평가한 것은 아니다.

ohmycodex-wrapper-light

코드 규모가 작고 결과도 안정적이었다.

token은 4,824,195로 기본 Codex나 skill 계열보다 많았지만, 구현 자체는 과하게 크지 않았다.

wrapper-light는 기본 Codex에 가까운 비교군으로 보는 편이 맞다.

다만 local CODEX_HOME, wrapper context, hook, 설정 차이가 결과에 영향을 줄 수 있으므로 완전히 같은 실행이라고 단정하기는 어렵다.

karpathy-guidelines

보수적인 구현을 만들었다.

token은 2,621,221이고, LOC는 1,232로 과하지 않다.

불필요한 추상화를 줄이고 검증 가능한 성공 기준을 중시하는 방향이 잘 드러났다.

단점은 운영 guard를 코드로 강하게 밀어붙이기보다 분석과 범위 통제 쪽으로 남기는 경우가 있다는 점이다.

안정적인 기본기를 원할 때는 좋은 후보지만, 동시성이나 분산 환경을 적극적으로 해결해야 하는 과제에서는 더 구체적인 guard가 필요하다.

ponytail-full

가장 작은 코드 규모를 만들었다.

총 883 LOC로 압도적으로 작다.

kotlinboard에서는 self-review로 delete semantics 문제를 잡은 점도 좋았다.

다만 reservation에서 JVM-local lock을 쓴 점은 운영 관점에서 약하다.

단일 instance 기준으로는 충분하지만, scale-out 구조에서는 같은 room writer가 여러 JVM으로 갈라질 수 있다.

"작고 깔끔한 구현"에는 강하지만, 분산 환경 안전성까지 보려면 보강이 필요하다.

solid-only

계층과 책임 분리는 좋다.

self-review에서 orderapi의 stock 문제를 잡은 점도 의미 있다.

다만 SOLID만 강조하면 코드가 다소 커지고, 일부 구조는 실험 API 규모에 비해 무거워질 수 있다.

실무에서 장기 유지보수성을 중시하는 팀이라면 나쁜 선택은 아니다.

하지만 빠른 구현과 비용 효율까지 같이 보면 solid-yagni-balanced 쪽이 더 낫다.

yagni-only

필요한 만큼만 구현하는 성향이 강했다.

token도 2,407,501로 낮은 편이고, LOC도 1,289로 적당하다.

단점은 운영 guard를 "지금은 필요하지 않은 것"으로 밀어낼 위험이다.

이번처럼 guard가 명확히 주어지면 통과하지만, 요구가 느슨한 과제에서는 동시성, idempotency, 보안 경계가 빠질 가능성이 있다.

lazycodex-wrapper-light

최종 검증은 통과했지만 비용이 높다.

total token은 10,672,677이고, 코드 규모도 1,768 LOC다.

특히 orderapi가 417 LOC로 다른 후보보다 크다.

품질이 나쁘다는 뜻은 아니다.

다만 wrapper-light라는 이름과 달리 비용 프로필은 가볍지 않았다.

같은 품질을 더 적은 token으로 만든 후보가 있기 때문에 균형 순위에서는 밀린다.

lazycodex-workflow-full

최종 검증을 통과했고, reservation 쪽 evidence는 강했다.

workflow 성격상 더 많은 검토와 산출물을 남기는 경향이 있다.

문제는 비용과 규모다. total token은 28,993,091로 가장 높고, LOC도 2,144로 가장 크다.

orderapi도 657 LOC로 크게 늘었다.

완성도 자체는 후보군에 들어오지만, 비용과 운영 편의성까지 함께 보면 best balance로 보기는 어렵다.

self-review 효과

이번 실험에서 self-review는 분명히 효과가 있었다.

단순히 문서를 고치는 수준이 아니라 실제 코드 결함을 찾고 테스트를 추가했다.

 

variant/task	self-review에서 개선된 대표 항목
solid-yagni-balanced/orderapi	duplicate product line으로 stock 검증을 우회할 수 있는 문제 수정
solid-only/orderapi	유사한 duplicate line oversell 문제 수정
solid-yagni-balanced/kotlinboard	댓글이 있는 게시글 삭제 실패 문제 수정
ponytail-full/kotlinboard	댓글이 있는 게시글 삭제 실패 문제 수정
codex-default/orderapi	idempotency unique constraint race hardening
codex-default/kotlinboard	duplicate signup race/status mapping 보강
여러 variant	pagination validation test 보강

 

다만 self-review는 최종 판정자가 아니다.

좋은 self-review도 결국 테스트와 harness로 확인해야 한다.

이번 실험에서 유의미했던 것은 "스스로 봤다"가 아니라 "스스로 본 뒤 실제 테스트와 중앙 검증까지 통과했다"는 점이다.

wrapper-light와 workflow-full 해석

wrapper-light는 기본 Codex 실행에 가까운 비교군이다.

하지만 완전히 같다고 볼 수는 없다. local CODEX_HOME, wrapper가 제공하는 context, hook, 설정 차이가 입력과 실행 흐름에 영향을 줄 수 있다.

workflow-full은 더 많은 절차와 검토 흐름을 만들 수 있다.

그만큼 evidence가 늘어날 가능성도 있다.

대신 token 비용, 산출물 규모, 운영 복잡성도 함께 늘어난다.

따라서 이번 결과를 "도구 A가 도구 B보다 절대적으로 좋다"로 읽으면 안 된다.

더 정확한 해석은 "같은 과제를 줬을 때 이 실험 환경에서는 어떤 실행 흐름이 어떤 비용과 결과를 냈는가"다.

종합 순위

완성도, 코드 구조, 운영 guard, 검증 evidence를 종합한 순위는 다음과 같다.

순위	variant	판단
1	solid-yagni-balanced	가장 좋은 균형. guard 대응, self-review 효과, token 효율이 모두 좋다.
2	ohmycodex-workflow-full	검증 통과, 코드 규모 안정, guard 대응이 좋다. 비용은 중간 이상이다.
3	caveman-full	token 효율이 가장 좋고 구현도 단단하다. 운영 확장성은 일부 보강이 필요하다.

 

비용과 운영 편의성까지 강하게 보면 순위는 조금 달라진다.

순위	variant	판단
1	solid-yagni-balanced	품질과 비용의 균형이 가장 좋다.
2	caveman-full	가장 적은 token으로 최종 검증을 통과했다.
3	codex-default	기본값치고 강하다. 다만 reservation lock 전략은 감점 요소다.

 

lazycodex-workflow-full은 완성도 후보군에는 들어오지만, 비용과 코드 규모가 커서 균형형 winner로 보기는 어렵다. ponytail-full은 매우 작고 깔끔하지만, 분산 환경에서의 lock 전략이 약하다.

solid-only는 구조가 좋지만 다소 무겁고, yagni-only는 간결하지만 요구가 덜 명확한 상황에서는 운영 guard를 놓칠 위험이 있다.

외부 연구와 연결되는 지점

이번 실험은 작은 lab 실험이지만, AI 코딩 에이전트 평가에서 중요한 흐름과 맞닿아 있다.

SWE-bench는 실제 GitHub issue와 repository를 기반으로 모델이 코드를 수정하고 테스트를 통과하는지 평가한다.

이 실험도 같은 방향을 따른다.

그럴듯한 설명보다 실행 가능한 artifact와 test evidence를 우선했다.

SWE-bench Verified는 평가 문제의 모호함과 환경 문제를 줄이기 위해 human-validated subset을 만들었다.

이 실험에서 모든 variant에 같은 guard를 준 것도 비슷한 문제의식이다.

평가 조건이 흔들리면 결과 해석도 흔들린다.

SWE-agent 논문은 agent-computer interface가 agent의 행동과 성능에 영향을 준다고 본다.

wrapper-light와 workflow-full의 차이도 이 관점에서 볼 수 있다. 같은 모델이라도 어떤 도구 표면과 workflow를 타느냐에 따라 비용과 산출물이 달라진다.

Self-Refine과 Reflexion 계열 연구는 self-feedback이 결과를 개선할 수 있음을 보인다.

이번 실험에서도 self-review는 실제 결함을 잡았다.

다만 self-review의 가치는 보고서가 아니라 수정된 코드와 통과한 테스트로 확인해야 한다.

한계

이 실험은 블로그로 정리할 만한 관찰을 준다. 다만 일반화에는 선이 필요하다.

 

한계	설명
반복 수	variant/task별 1회 실행이다. 통계적 유의성은 없다.
모델 범위	같은 Codex 계열 실행 환경 안의 비교다. 완전히 다른 모델 회사나 독립 agent 제품 비교가 아니다.
token telemetry	top-level 실행 로그 기준이다. wrapper 내부 흐름의 비용이 완전히 분리되지 않았을 수 있다.
부하 검증	실제 대용량 트래픽, 분산 DB, queue, payment gateway를 검증한 것은 아니다.
DB 제약	H2/SQLite 기반 local project가 많다. production RDBMS와 동작 차이가 있을 수 있다.
운영 범위	rate limit, observability, migration, secret rotation, disaster recovery는 대부분 범위 밖이다.
wrapper 해석	wrapper와 workflow 제품 전체를 평가한 것이 아니라, 이 lab 환경에서 나온 산출물을 비교한 것이다.

 

따라서 이 글은 "어떤 agent가 절대적으로 우월하다"는 결론이 아니다.

더 정확히는 "프롬프트, skill, wrapper, workflow, guard, self-review가 결과를 어떻게 바꾸는지 관찰한 기록"이다.

메시지

이번 실험은 "토큰을 많이 쓰면 좋은 코드가 나올까?"라는 질문으로 시작할 수 있다.

답은 단순하다. 아니다. 적어도 이 실험에서는 아니었다.

토큰이 많으면 더 오래 생각하고 더 많이 검토할 수 있다.

하지만 그 검토가 좋은 방향으로 고정되지 않으면 비용만 늘어난다.

반대로 guard가 분명하고, scope가 좁고, 마지막 검증이 있으면 적은 token으로도 꽤 좋은 결과가 나온다.

solid-yagni-balanced가 좋은 예다.

SOLID는 책임과 경계를 잡아줬고, YAGNI는 필요 없는 구조 확장을 막았다.

두 원칙이 충돌하기보다 서로를 보완했다. 필요한 곳에는 구조를 만들고, 필요 없는 곳에는 만들지 않는 쪽으로 수렴했다.

AI 코딩 에이전트를 비교할 때 중요한 것은 "누가 더 길게 말했나"가 아니다.

같은 조건에서 무엇을 만들었고, 어떤 테스트를 통과했고, 어떤 운영 리스크를 남겼는지 봐야 한다.

최종 결론

최종 산출물 기준으로는 모든 후보가 중앙 검증을 통과했다.

그다음 차이는 비용과 구조, 운영 guard의 깊이에서 갈렸다.

가장 믿을 만한 선택지는 solid-yagni-balanced였다.

이 세팅은 화려하지 않았고, 필요한 것을 필요한 만큼 구현했다.

token도 적게 썼다.

caveman-full은 가장 경제적이었다.

빠르게 실험하거나 작은 API를 만들 때 좋은 후보로 보인다.

다만 운영 동시성과 분산 환경까지 밀어붙이면 추가 보강이 필요하다.

lazycodex-workflow-full은 가장 무거웠다.

최종 검증은 통과했고 산출물도 많았지만, 비용 대비 균형은 좋지 않았다.

workflow가 강할수록 품질 가능성도 커지지만, 비용과 복잡성도 같이 커진다는 점을 보여준다.

이번 실험에서 얻은 가장 실용적인 결론은 이것이다.

좋은 AI 코딩 실험은 프롬프트 경쟁이 아니라 검증 설계 경쟁이다. 같은 guard, 같은 과제, 같은 검증 기준을 둬야 결과를 해석할 수 있다. 토큰은 품질의 보증서가 아니다. 품질은 코드와 테스트가 증명한다.

산출물 출처

이번 문서는 아래 산출물을 기준으로 작성했다.

항목	경로
실험 manifest	runs/20260708-guarded-clean-11variant-02/reports/experiment-manifest.json
전체 prompt 원문	runs/20260708-guarded-clean-11variant-02/prompts/
prompt 원문 카탈로그	runs/20260708-guarded-clean-11variant-02/reports/prompt-catalog-full.ko.md
구현 결과물	runs/20260708-guarded-clean-11variant-02/outputs/
개별 agent 보고서	runs/20260708-guarded-clean-11variant-02/reports/agent-reports/
token telemetry	runs/20260708-guarded-clean-11variant-02/reports/token-usage/
최종 검증 요약	runs/20260708-guarded-clean-11variant-02/reports/orchestration/verification-current-33-final-summary.json
분석 metrics	runs/20260708-guarded-clean-11variant-02/reports/orchestration/analysis-metrics.md
검증 harness	scripts/verify_agent_lab.py

외부 참고 자료

아래 자료는 실험 해석을 보조하는 배경 자료로만 사용했다.

이 lab 실험의 수치와 순위는 로컬 산출물에서 나온 것이다.

• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
• SWE-bench Verified
• Introducing SWE-bench Verified - OpenAI
• Why SWE-bench Verified no longer measures frontier coding capabilities - OpenAI
• SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
• Self-Refine: Iterative Refinement with Self-Feedback
• Reflexion: Language Agents with Verbal Reinforcement Learning

 

---------------

 

omx와 카파시가이드라인, caveman을 적당히 사용중이었는데 omx와 카파시가이드라인을 걷어내고, agent가 생성한 solid-yagni-balanced 스킬을 사용해보려고 함, caveman full은 확실히 10%정도 토큰 절약이 되는 것 같음.

스킬은 아래 펼치기

 

---
name: solid-yagni-balanced
description: Use when writing, reviewing, or refactoring code with both SOLID and YAGNI constraints; especially when the user asks for solid-yagni-balanced, SOLID + YAGNI, maintainable but not overengineered code, scope control, or implementation prompts for agent experiments.
---

# SOLID + YAGNI Balanced

Build the smallest design that satisfies the current contract, tests, and operational guardrails. Use SOLID to keep real responsibilities clear. Use YAGNI to stop speculative structure.

## Core Rule

Correct behavior, security, data integrity, status codes, and runnable tests override both SOLID and YAGNI.

If SOLID suggests adding structure but the current problem does not need it, YAGNI wins. If YAGNI suggests keeping code inline but responsibilities are already tangled or unsafe, SOLID wins.

## Decision Rules

| Situation | Do |
|---|---|
| One function/class is mixing API, business rules, persistence, and error mapping | Split responsibilities along existing framework boundaries |
| A new interface would have one implementation | Do not add it unless the framework, test seam, or external boundary requires it |
| A factory/strategy/plugin/event layer is only for possible future variants | Do not add it |
| Validation, auth, idempotency, locking, or transaction rules are business-critical | Make them explicit and test them |
| Duplication appears twice but is small and stable | Leave it until the third real use or until it hides a bug |
| A helper removes real repetition or clarifies a contract | Add the helper |
| A refactor touches unrelated behavior | Stop unless the task explicitly asks for it |

## Implementation Workflow

1. Read the contract first: required behavior, status codes, data rules, security boundaries, and test expectations.
2. Identify P0/P1/P2 risks before shaping code:
   - P0: compile/test/run failure
   - P1: security or data integrity failure
   - P2: API contract failure
3. Choose the simplest conventional structure for the stack.
4. Add only the seams needed for current responsibilities.
5. Write or update tests for required behavior and high-risk edge cases.
6. Run verification commands. Treat missing runnable evidence as a confidence downgrade.
7. In self-review, fix P0/P1/P2 issues first. Only fix P3 cleanup when narrow and low-risk.

## Architecture Guidance

- Prefer framework-native layers when they clarify current work: controller/router, service/use-case, repository/DAO, DTO/schema.
- Keep domain rules out of controllers when they affect data integrity or state transitions.
- Keep persistence details out of DTOs and API response models.
- Keep exception/status-code mapping centralized when the stack makes that natural.
- Do not create clean-architecture ceremony for a small smoke project unless boundaries are already causing confusion.

## Operational Guardrails

Do not let YAGNI remove required operational safety.

- Idempotency: repeated create/payment/cancel-style requests must not double-apply side effects when the contract requires it.
- Concurrency and locking: read-then-write checks need a transaction, lock, constraint, or retry-safe strategy when concurrent requests can violate integrity.
- Distributed deployment: JVM-local or process-local locks do not protect multiple app instances.
- Pagination: list endpoints need pagination or an explicit documented reason for excluding it.
- Auth and roles: public input must not escalate privileges.
- Error mapping: validation, missing resource, conflict, and authentication failures must produce the specified status codes.

## Report Checklist

When producing an implementation or self-review report, include:

- Prompt/settings used.
- Implemented behavior.
- Tests and commands run.
- Guard-by-guard status.
- Code structure and package layout.
- Known gaps using P0-P4 language.
- Operational notes: idempotency, locking/concurrency, high-traffic behavior, MSA/distributed risks, latent production risks.
- Token usage only when measured; do not invent exact token counts.

## Common Mistakes

- Adding interfaces, factories, or strategies because SOLID was mentioned.
- Using YAGNI to skip idempotency, locking, auth, pagination, or status-code requirements.
- Treating static review as equivalent to tests.
- Refactoring unrelated files to make the architecture look cleaner.
- Calling a result "balanced" when it simply has less code but leaves P1/P2 risks.