LLM으로 내 소프트웨어를 계속 개선해 가려면 어떤 루프가 필요할까?

현재 한 줄 결론: 사람의 의도가 포함되지 않고는 production 레벨의 소프트웨어 자가개선 루프는 성립하지 않는다.

왜 이 질문인가

많은 IT 기업이 이제 LLM으로 소프트웨어를 만든다. 동작은 한다. 그런데 생각보다 이슈가 많다. 특히 엣지케이스에서.

나도 같은 자리에 있다. harness-maker라는 프로젝트를 굴리며 여러 프로젝트의 코드를 그 위로 진행하고 있다. 그러다 이런 생각이 떠올랐다. 매일 밤 LLM 하네스가 내 코드를 한 줄 한 줄 분석해서 밤새 리뷰하고 테스트해서 개선한다면, 품질이 얼마나 좋아질까.

대상으로 점찍은 프로젝트는 내가 굴리는 임베디드 자동 테스트 팜이다. Python 51,674 LOC, imx8mm 보드 풀, 이미 23:00 KST cron으로 nightly hardware test가 돈다. 같은 코드베이스 위에 하드웨어 테스트 cron 옆에 코드 개선 cron이 같이 도는 그림이다.

그래서 질문은 하나로 좁혀진다. LLM으로 이슈가 0이 될 때까지 이 소프트웨어를 계속 개선하려면, 무엇이 필요할까.

현재 가설

한 발 물러나서 보면 핵심은 하나다. 자동 개선 루프를 닫아야 한다. 그 루프의 최종 그림은 이렇다.

소프트웨어 자가개선 루프: spec을 oracle로 세우고 사람은 spec과 PR 두 곳에만, 그 사이는 ultra-audit과 gate로 자동화한다

루프는 input, state, output으로 돈다. 이전 루프의 output 일부가 다음 루프의 input으로 다시 흘러 들어간다. 이때 다음 input으로 가져갈 것은 task 상태 같은 얕은 층위가 아니라 코드 산출물이다. merged PR, rejected PR, 테스트 로그.

이 루프에서 spec은 처음 한 번만 세운다. 사람이 정의하고 잠근다. 그게 oracle이다. 그다음부터 반복 사이클은 spec이 아니라 ultra-audit에서 시작한다. 사람은 한 사이클에서 두 번 리뷰한다. ultra-audit이 올린 개선안(무엇을 고칠지)과, 끝의 PR. 의도는 사람이 쥐고, 그 두 리뷰 사이는 코드가 돌린다.

그 사이를 자동화할 수 있는 이유는 spec이 oracle이기 때문이다. spec이 “무엇이 맞는가”의 기준이라, audit도 gate도 사람 판단 없이 객관적으로 판정한다. spec이 없으면 매 단계 사람이 끼어야 하고, 그게 곧 병목이다.

루프의 심장은 audit이다. 그냥 audit이 아니라 ultra-audit이어야 한다. Claude Code의 dynamic workflow로 수많은 sub-agent를 fan-out해서 모듈별로 강하게 감사한다. (이 글을 쓰며 두 번 돌린 그 워크플로우가 그 예다. 한 번에 30개가 넘는 agent가 병렬로 파고든다.) ultra-audit이 spec 기준으로 이슈와 개선점을 모듈 단위로 길어 올리면, 사람은 코드를 한 줄씩 보는 대신 그 결과만 리뷰해 무엇을 고칠지 고른다. 사람 병목이 여기서 가장 크게 줄어든다.

나머지는 이 루프의 각 자리를 채우는 부품이다. 그리고 각 부품이 사람 부담을 어디서 더는지가 설계 기준이다.

audit 자리의 panel은 spec gaming을 막으려 multi-vendor를 강제한다. 기본은 2 vendor (Claude main + Codex sub). 같은 vendor 여러 개는 panel이 아니다. open source인 harness-maker에서 vendor 다양성을 모두에게 강제하기는 어렵지만, default 설정은 2 vendor부터 시작한다.

gate 자리에는 A+ PR을 판정하는 rubric 5개를 둔다.

정적분석 (clang-tidy 등) 0 이슈 및 Lint 0 이슈
Coding Style 동일함 (camel 등)
Spec의 Criteria 만족
TC 통과 (기존 + 신규)
보안 / UI / UX / 성능 / 동시성 / 사이드이펙트 / 도메인 reviewer에서 이슈 없어야 함

5번 categories는 글로벌 CLAUDE.md에 정의된 specialized sub-agents (concurrency-reviewer, performance-reviewer, side-effect-reviewer 등)와 그대로 매핑된다. 이 5-gate 위에 한 단 더, TC quality gate를 얹는다. 핵심은 mutation을 강제해서 TC가 코드 변경에 sensitive한지 검증하는 것이다. spec coverage도 같이 본다. spec coverage가 100%여도 mutation score가 낮으면 그 PR은 거부한다. rubric이 명확할수록 PR 리뷰에서 사람이 직접 볼 게 줄어든다.

운영 주기는 매일이 아니라 sprint 단위로 간다. PR 리뷰는 한 건당 빨라야 5분이고, 하루 2시간을 매일 review에 쓰는 건 지속 가능하지 않다. 게다가 매일 굴리는 것 자체의 효과도 떨어진다. trivial한 PR은 정적 조건으로 자동 merge해서 아예 사람 큐에서 뺀다 (5번 막힌 곳 참조). 이 모든 게 같은 목적이다. 사람의 두 touchpoint를 가볍게 만드는 것.

루프 자체는 내가 직접 만든 skill로 짠다. 자가개선 사이클을 도는 sw_improve와 그 audit을 맡는 ultra-audit는 harness-maker에 들어 있는 skill이 아니다. harness-maker가 깔아주는 review agent와 gate(production preset) 위에서 도는 내 skill이다. 이걸 대상 프로젝트에 실제 dogfooding한다. 처음엔 매일 아침 PR 30개를 review하는 그림이었지만 Round 1 중에 두 번 갱신됐다.

그래서 자가개선 loop을 붙일 거면 순서는 이렇다. spec을 oracle로 처음 한 번 세워 잠그고, 반복은 ultra-audit에서 시작하고, 사람은 그 audit 결과와 PR만 리뷰한다. 그 사이는 gate로 자동화한다. 사람을 없애는 게 아니라, 사람이 의도에만 집중하도록 병목을 그 두 리뷰로 몰아넣는 것이다. 결국 이 loop를 효율화한다는 건 사람의 병목을 얼마나 줄이느냐의 문제다. 앞으로 기업들이 본격적으로 파고들 지점이 바로 여기다.

Evidence so far

이 가설을 두 층위에서 뒷받침하는 근거가 모였다. 하나는 “사람 의도가 루프를 닫는다”는 큰 주장의 산업 증거, 다른 하나는 설계 각 결정의 근거다.

사람 의도가 루프를 닫는다 (산업에서 이미 이렇게 한다)

이슈에서 자동 PR까지는 이미 production이다. 그래도 의도 확인은 사람 몫이다. GitHub Copilot Autofix를 보자. code scanning이 이슈를 찾으면 30초 안에 자동으로 PR이 올라온다. 당연히 올리기 전에 자동 테스트도 거친다. 하지만 GitHub 문서는 “수정이 의도한 동작을 유지하는지 확인하는 것은 개발자의 책임”이라고 명시한다 (GitHub Copilot Autofix docs). loop는 자동이지만 의도 확인은 사람이라는 뜻이다.

연구도 같은 분담을 가리킨다. AI는 mechanical한 것(naming, test, error, 보안 패턴)을 잡고, 사람은 intent에 집중한다 (How Humans Review AI-Generated PRs). 숫자도 그 이유를 설명한다. AI 생성 코드의 syntax correctness는 95%를 넘는데, 기본값으로 안전한 비율은 55%에 그친다 (Security-related AI-Generated PRs). 동작은 하는데 의도와 안전에서 어긋난다. 이 기조는 당분간 지속되지 않을까 싶다. 아무리 AI가 빠르게 발전해도. 여기까지 AI가 대체한다면, 사람은 할 일이 없는 시대가 오는 걸까.

설계 각 결정의 근거

Spec gaming은 base rate, hypothetical risk가 아니다. “스펙을 LLM이 편하게 해석해서, 그냥 개선되었다고 판단하고, PR을 올리는 경우”는 이미 측정된 현상이다. METR 2025 report와 Palisade Research 모두 reasoning 모델일수록 reward hacking 빈도가 증가한다고 보고 (Reward Hacking Benchmark).

같은 vendor 3개는 panel이 아니다. “당연히 B 겠지. 학습한 데이터와 학습 방식이 전혀 다를테니까.” opus/sonnet/haiku는 같은 표 3장이다. Mozilla AI의 Star Chamber 패턴이 이걸 production reference로 보여준다 (Star Chamber). 3 모델 default, confidence-based classification (consensus / majority / individual).

A+ rubric은 명확하게 쓸수록 reviewer agreement가 올라간다. “A+의 명확한 criteria와 예시를 명시해야 겠지.” MultiChallenge benchmark에서 rubric 제공 시 LLMAJ alignment가 37.3%에서 93.95%로 점프 (Snorkel rubric design). 등급 라벨만으로는 부족하고 checklist criteria가 primary driver.

TC quality gate는 5개 gate 위의 6번째다. “mutation을 강제하여 테스트하는 것이 TC Quality Gate.” spec coverage와 mutation score를 같이 봐야 한다. Coverage 100%여도 mutation score가 15%면 그 PR은 거부 (arxiv 2510.23350).

Sprint 1의 KPI는 양이 아니라 가치다. “양보다는 이러한 중요한 이슈를 발견해 해결하는 것이 ROI가 훨씬 높아. 단순히 많은 양을 수정하는 것이 중요한 것은 아닌 것 같아. spec과 mutation score를 늘리기 위한 test 코드들이 초반에 많이 생성이 필요해.” critical 이슈 1건이 tooling 2,500줄 변경보다 의미 있다.

자가 개선 agent의 ROI는 algorithm이 아니라 tooling이다. SWE-Bench Verified 17%에서 53%로의 개선 사례에서 개선의 출처가 smart edit, AST symbol locator, context summarizer 같은 도구 개선이었다 (A Self-Improving Coding Agent). 내 sw_improve skill 입장에서도 똑같다. skill 자체에 좋은 내부 도구가 있어야 효과가 난다.

막힌 곳 / Open questions

Round 1에서 다 풀지 못하거나 아직 hand-wavy한 영역 6개에, Round 2에서 하나가 더 붙었다.

Panel consensus trend의 양면 해석. consensus 비율이 70%에서 95%로 올라가는 것을 단방향으로 “maturity 신호”로만 읽으면 안 된다. diversity가 유지되는 조건 하에서만 좋은 신호이고, 아니면 panel이 single voice로 collapse한 spec gaming 신호일 수 있다. consensus rate와 별도로 측정할 diversity metric이 필요.
Sprint success criteria의 명시적 정의. “1주차 = infrastructure phase”라는 reframe은 받아들였지만 실제 sprint 1을 평가할 때 어떤 숫자로 success/failure 판단할지 아직 명확하지 않다. spec 항목 N개? mutation-resistant TC N개? threshold는?
Spec 객관성 작성법. spec을 LLM deep interview로 초안 생성, 사람이 review 후 잠그는 패턴까지는 결정 (“이후 수정은 사람의 승인없이는 할 수 없도록 해야겠다”). 하지만 LLM이 “그럴싸한 것으로 결정” 못 하게 spec을 어떻게 쓸지의 구체 패턴은 미정.
UI/UX 트랙. spec/TC로 잡기 어려운 영역이라 별도 트랙으로 분리만 결정. 실제 처리 방식은 미정.
Trivial PR starvation. 매일 30 PR 다 보기는 무리다. trivial한 PR은 별도 트랙으로 분리해서 주니어 또는 second-tier reviewer로 routing하거나, 2 reviewer consensus 후 auto-merge로 흘리는 흐름이 필요하다. 아직 미설계.
Generalizability 한계. “이 과정은 일반적인 harness 에서는 100% 못하는 시스템이 되겠어.” panel/gate/utility 구조는 일반화 가능, spec/TC는 project-specific. 어디까지 harness-maker가 기본 제공하고 어디부터 project tuning인지 경계가 미정.
사람의 리뷰가 결국 병목이다. trivial 자동 merge나 2인 peer 리뷰로 병목을 줄일 수는 있다 (5번 참조). 하지만 사람이 자기 책임을 다해 spec과 PR을 성심껏 본다는 보장은 없다. 개개인 성향에 따라 다르고, 이게 루프의 성공을 가르는 가장 큰 변수다.

다음에 확인할 evidence

Round 2의 핵심 목표는 추상에서 구체로. 실제로 필요한 components 들과 실제 동작하는 workflow 를 자세하게 설계하고 싶다.

구체 산출물 후보:

sw_improve skill의 architecture (gate들, reviewer panel, utility, sprint cycle 흐름도)
A+ rubric 5 criteria의 checklist (각 항목에 examples 부착)
TC quality gate의 측정 방법 (spec coverage matrix + mutation score 어떤 도구로)
Sprint success criteria의 구체 숫자 (infrastructure phase metric threshold)
Panel diversity metric (consensus rate + agreement diversity 같이 보는 식)
Trivial PR routing 정책

그리고 이번 라운드에 새 항목이 하나 붙었다. 지금 이 프로세스를 운영 중인 임베디드 자동 테스트 팜에 통합하고 있다. 실제로 소프트웨어가 얼마나 개선되는지, 사람의 병목이 어느 정도인지를 직접 측정할 계획이다. 가장 궁금한 건 만족도다. 품질 엔지니어(SQE)가 소프트웨어를 주기적으로 테스트해줄 때 느끼는 안정감을 받을 것인가, 아니면 자기가 대체되고 일이 없어진다는 느낌을 받을 것인가. 이건 숫자로만 보기 어려운 부분이라 직접 겪어봐야 안다.

검색 키워드: mutmut python mutation testing, pytest spec coverage tools, sprint kpi infrastructure phase, LLM agent panel agreement diversity metric, code review trivial auto-merge consensus.