토큰을 많이 쓰면 좋은 코드가 나올까?
11개 AI 코딩 에이전트 세팅을 같은 과제와 같은 검증 기준으로 비교해, 토큰 총량보다 guard, self-review, 독립 검증이 코드 품질을 더 잘 설명한다는 점을 정리한 실험 노트.
토큰을 많이 쓰면 좋은 코드가 나올까?
한 줄 요약
이번 실험에서는 토큰을 많이 쓴 세팅이 항상 더 좋은 코드를 만들지는 않았다. 가장 좋은 균형을 보인 세팅은 solid-yagni-balanced였고, 품질을 더 잘 설명한 것은 토큰 총량보다 명확한 guard, 실제 결함을 고친 self-review, 그리고 독립 검증이었다.
먼저 읽을 결론
11개 AI 코딩 에이전트 세팅에 같은 3개 구현 과제를 맡겼고, 33개 최종 후보를 같은 중앙 검증 harness로 다시 확인했다. 최종 후보는 모두 검증을 통과했다. 따라서 차이는 "돌아가느냐"보다 비용, 코드 규모, 운영 guard의 깊이, self-review의 수정 효과에서 갈렸다.
핵심 판단은 단순하다.
| 판단 | 근거 |
|---|---|
| 최고 균형 | solid-yagni-balanced가 전체 1위였다. 3개 과제를 모두 통과했고, 전체 토큰은 2,009,278로 비교군 하위권이었다. |
| 토큰 총량의 한계 | lazycodex-workflow-full은 28,993,091 tokens로 가장 많이 썼지만, 비용 대비 균형에서는 밀렸다. |
| 좋은 self-review의 조건 | self-review는 보고서가 아니라 실제 코드 수정과 테스트 통과로 가치를 증명해야 한다. |
| 검증 설계의 중요성 | 같은 과제, 같은 guard, 같은 검증 기준이 있어야 에이전트 결과를 비교할 수 있다. |
이 실험의 결론은 "토큰은 품질을 만들 기회를 늘릴 수는 있지만, 품질을 보장하지는 않는다"에 가깝다. 품질은 결국 코드, 테스트, 검증 결과가 증명한다.
왜 저장했나
AI 코딩 에이전트를 비교할 때 토큰 사용량, 긴 추론, 복잡한 workflow가 품질을 높인다고 쉽게 가정할 수 있다. 이 실험은 그 가정을 바로 믿지 않고, 같은 과제와 같은 검증 기준으로 결과물을 다시 비교했다는 점에서 재사용 가치가 있다.
특히 실무에서 중요한 질문은 "어떤 에이전트가 가장 많이 생각했는가"가 아니다. 같은 조건에서 무엇을 만들었고, 어떤 결함을 남겼고, 어떤 테스트를 통과했으며, 운영 리스크를 얼마나 줄였는지가 더 중요하다.
정리한 질문
AI 코딩 에이전트에서 토큰을 더 많이 쓰거나 workflow를 더 복잡하게 만들면 실제 코드 품질도 좋아지는가? 아니면 명확한 요구사항, self-review, 독립 검증이 더 큰 차이를 만드는가?
실험 설계
모든 variant에는 같은 세 가지 과제와 같은 운영 guard를 제공했다. 각 과제는 first-attempt와 self-review 두 단계로 실행했고, 최종 후보는 중앙 검증 harness로 다시 검사했다.
| 항목 | 값 |
|---|---|
| 비교 variant | 11개 |
| 구현 과제 | 3개 |
| 최종 후보 | 33개 |
| phase 보고서 | 66개 |
| token telemetry | 66개 |
| 최종 P0/P1/P2/P3/P4 이슈 | 모두 0 |
비교 대상은 다음과 같았다.
| 그룹 | 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 | 가벼운 wrapper 비교군 |
| wrapper-light | lazycodex-wrapper-light | 가벼운 wrapper 비교군 |
| workflow-full | ohmycodex-workflow-full | 전체 workflow 실행 |
| workflow-full | lazycodex-workflow-full | 전체 workflow 실행 |
공통 과제와 guard
과제는 작은 API 구현이지만, 일부러 운영에서 문제가 되기 쉬운 guard를 넣었다. 단순 CRUD보다 동시성, idempotency, 권한 상승, 인증 실패, pagination 같은 지점에서 차이가 드러나도록 설계했다.
| 과제 | 스택 | 핵심 요구 |
|---|---|---|
reservation | Spring Boot | 회의실 예약 API, 같은 room의 시간 겹침 방지, 동시 요청 처리 |
orderapi | FastAPI | 주문 생성/결제/취소 API, idempotency, 재고 무결성 |
kotlinboard | Kotlin Spring Boot | 게시판 API, signup 권한 상승 차단, JWT 401, pagination |
| 영역 | 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을 구현하거나, 제외한다면 이유를 명시해야 한다. |
토큰 사용량
총 토큰만 보면 lazycodex-workflow-full이 압도적으로 크다. 하지만 최종 순위는 토큰 총량과 일치하지 않았다. solid-yagni-balanced는 전체 토큰이 낮은 편이면서도 최종 1위였다.
| 순위 | variant | total tokens | non-cached input | output | reasoning |
|---|---|---|---|---|---|
| 1 | lazycodex-workflow-full | 28,993,091 | 898,552 | 180,171 | 41,102 |
| 2 | lazycodex-wrapper-light | 10,672,677 | 579,145 | 105,692 | 26,105 |
| 3 | ohmycodex-wrapper-light | 4,824,195 | 369,935 | 50,932 | 5,856 |
| 4 | ohmycodex-workflow-full | 4,594,495 | 343,448 | 69,799 | 7,514 |
| 5 | karpathy-guidelines | 2,621,221 | 310,793 | 52,508 | 6,868 |
| 6 | ponytail-full | 2,553,585 | 282,245 | 51,436 | 9,205 |
| 7 | solid-only | 2,411,583 | 223,585 | 54,622 | 6,172 |
| 8 | yagni-only | 2,407,501 | 190,561 | 49,132 | 5,611 |
| 9 | codex-default | 2,245,509 | 255,522 | 54,115 | 5,123 |
| 10 | solid-yagni-balanced | 2,009,278 | 263,150 | 50,768 | 4,219 |
| 11 | caveman-full | 1,714,780 | 235,537 | 48,843 | 5,703 |
코드 규모
코드 규모도 품질과 단순한 비례 관계를 보이지 않았다. 작은 산출물이 항상 안전한 것도 아니고, 큰 산출물이 항상 더 좋은 것도 아니다. 다만 지나치게 큰 산출물은 운영 비용과 리뷰 비용을 키운다.
| 순위 | variant | reservation | orderapi | kotlinboard | 합계 |
|---|---|---|---|---|---|
| 1 | ponytail-full | 357 | 61 | 465 | 883 |
| 2 | ohmycodex-wrapper-light | 473 | 97 | 570 | 1,140 |
| 3 | karpathy-guidelines | 478 | 108 | 646 | 1,232 |
| 4 | ohmycodex-workflow-full | 487 | 104 | 682 | 1,273 |
| 5 | yagni-only | 511 | 100 | 678 | 1,289 |
| 6 | caveman-full | 527 | 105 | 716 | 1,348 |
| 7 | solid-only | 517 | 108 | 797 | 1,422 |
| 8 | codex-default | 607 | 122 | 742 | 1,471 |
| 9 | solid-yagni-balanced | 586 | 118 | 828 | 1,532 |
| 10 | lazycodex-wrapper-light | 528 | 417 | 823 | 1,768 |
| 11 | lazycodex-workflow-full | 643 | 657 | 844 | 2,144 |
ponytail-full은 매우 작고 깔끔했지만, 운영 동시성이나 분산 환경까지 고려하면 보강 여지가 있었다. lazycodex-workflow-full은 가장 컸고 최종 검증도 통과했지만, 그만큼 비용과 리뷰 부담이 컸다.
과제별 관찰
reservation에서는 overlap 방지와 동시 요청 처리가 핵심이었다. 단일 프로세스나 단일 JVM 안에서는 lock으로 통과할 수 있지만, 분산 환경이나 DB 제약까지 생각하면 더 강한 설계가 필요하다. 이 지점에서 작고 깔끔한 구현과 운영적으로 단단한 구현의 차이가 났다.
orderapi에서는 idempotency와 재고 무결성이 중요했다. self-review가 duplicate product line으로 stock 검증을 우회할 수 있는 문제를 잡아낸 사례가 있었다. 이 과제에서는 "테스트가 통과한다"보다 "중복 요청과 부분 실패를 어떤 모델로 막는가"가 더 중요했다.
kotlinboard에서는 public signup으로 ADMIN 권한을 만들 수 없어야 했고, 잘못된 JWT는 401로 떨어져야 했다. 댓글이 있는 게시글 삭제, duplicate signup, pagination validation 같은 세부 지점에서 self-review의 효과가 드러났다.
Self-Review 효과
이번 실험에서 self-review는 실제 결함을 일부 잡아냈다. 단, 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 보강 |
Wrapper와 Workflow 해석
wrapper-light는 기본 Codex 실행에 가까운 비교군이다. 그래도 wrapper가 제공하는 context, hook, 설정 차이가 입력과 실행 흐름에 영향을 줄 수 있으므로 완전히 같은 조건이라고 보기는 어렵다.
workflow-full은 더 많은 절차와 검토 흐름을 만들 수 있다. evidence가 늘어날 가능성도 있지만, token 비용, 산출물 규모, 운영 복잡성도 함께 커진다. 따라서 이 결과를 특정 도구의 절대 우열로 읽기보다, 같은 과제를 줬을 때 어떤 실행 흐름이 어떤 비용과 결과를 냈는지에 대한 관찰로 읽는 편이 맞다.
종합 순위
완성도, 코드 구조, 운영 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 전략은 감점 요소다. |
유용한 액션
- AI 코딩 에이전트 비교는 같은 과제, 같은 guard, 같은 검증 harness를 먼저 정한 뒤 진행한다.
- 토큰 예산을 늘리기 전에 실패를 잡아낼 테스트와 독립 검증부터 만든다.
- self-review는 유지하되, "리뷰 보고서 작성"이 아니라 "결함 수정 후 검증 통과"를 완료 조건으로 둔다.
- SOLID만 강조하면 구조가 무거워질 수 있고, YAGNI만 강조하면 운영 guard를 놓칠 수 있다. 이 실험에서는 둘을 함께 잡은
solid-yagni-balanced가 가장 안정적이었다. - wrapper나 workflow 도입 여부는 품질 가능성뿐 아니라 token 비용, 산출물 규모, 리뷰 비용까지 함께 본다.
외부 연구와 연결되는 지점
SWE-bench는 실제 GitHub issue와 repository를 기반으로 모델이 코드를 수정하고 테스트를 통과하는지 평가한다. 이 실험도 그럴듯한 설명보다 실행 가능한 artifact와 test evidence를 우선했다는 점에서 같은 방향을 갖는다.
SWE-bench Verified는 평가 문제의 모호함과 환경 문제를 줄이기 위해 human-validated subset을 만든다. 이번 실험에서 모든 variant에 같은 guard를 준 것도 비슷한 문제의식이다. 평가 조건이 흔들리면 결과 해석도 흔들린다.
SWE-agent는 agent-computer interface가 에이전트의 행동과 성능에 영향을 준다고 본다. wrapper-light와 workflow-full의 차이도 이 관점에서 볼 수 있다. 같은 모델이라도 어떤 도구 표면과 workflow를 타느냐에 따라 비용과 산출물이 달라질 수 있다.
Self-Refine과 Reflexion 계열 연구는 self-feedback이 결과를 개선할 수 있음을 보인다. 이번 실험에서도 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 환경에서 나온 산출물을 비교한 것이다. |
검증이 필요한 주장
- self-review가 잡아낸 결함 목록은 원본 실험 산출물의 diff와 테스트 로그로 재확인하는 편이 좋다.
- token telemetry는 top-level 로그 기준이므로 wrapper 내부 비용 분리가 정확한지 추가 확인이 필요하다.
solid-yagni-balanced의 1위 판단은 이 실험의 가중치에 따른 결론이다. 다른 과제, 다른 모델, 다른 운영 요구에서는 순위가 달라질 수 있다.- H2/SQLite 기반 검증 결과를 production RDBMS, 분산 lock, 실제 payment gateway 환경으로 일반화하면 안 된다.
Source Fidelity Notes
- 핵심 숫자는 유지했다: 11개 variant, 3개 과제, 33개 최종 후보, 66개 phase 보고서, 66개 token telemetry, 최종 P0/P1/P2/P3/P4 모두 0, variant별 token/LOC 표.
- 핵심 구조는 유지했다: 공통 guard,
first-attempt와self-review실행 구조, self-review 개선 사례, 종합 순위와 비용/운영 순위, 추가로 제공된solid-yagni-balanced스킬 원문. - 공개 페이지에서는 개인 폴더명, 로컬 run 식별자, 상세 산출물 경로를 제거했다.
- 원문에 있던 세부 variant별 평가 문단은 압축했다. 해석상 위험을 줄이기 위해 주요 판단, 한계, 검증 필요 항목은 별도 섹션으로 남겼다.
출처 / 참고자료
- 원본: 사용자 제공 로컬 실험 리포트. 개인 폴더명과 로컬 run 식별자는 비공개 처리.
- 추가 자료: 사용자 제공
solid-yagni-balanced스킬 원문. - 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
사용한 스킬: SOLID + YAGNI Balanced
아래는 이 실험에서 사용한 solid-yagni-balanced 스킬 원문이다.
---
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.