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으로 다시 들어간다. 이때 다음으로 넘길 것은 코드 산출물이다. 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이라 부르기 어렵다. harness-maker가 open source라서 모든 사용자에게 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가 코드 변경에 민감하게 반응하는지 확인하는 데 있다. spec coverage도 함께 본다. spec coverage가 100%라도 mutation score가 낮으면 그 PR은 거부한다. rubric이 분명할수록 PR 리뷰에서 사람이 직접 들여다볼 것은 줄어든다.

운영 주기는 sprint 단위로 잡는다. 매일 돌리지는 않는다. PR 리뷰는 빨라도 한 건에 5분이 걸리고, 매일 2시간을 review에 쓰는 생활은 오래 갈 수 없다. 매일 굴리면 그 자체의 효과도 떨어진다. trivial한 PR은 정적 조건으로 자동 merge해서 아예 사람의 큐에서 빼낸다. 이 부분은 아직 설계하지 못해서 막힌 곳에서 다시 꺼낸다. 이 모든 것이 향하는 곳은 하나다. 사람이 손대는 두 자리를 가볍게 만드는 것.

루프 자체는 내가 직접 만든 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는 naming, test, error, 보안 패턴 같은 mechanical한 것을 잡고, 사람은 intent에 집중한다 (How Humans Review AI-Generated PRs). 숫자를 보면 왜 그런지 짐작이 간다. AI가 생성한 코드의 syntax correctness는 95%를 넘지만, 기본값으로 안전한 비율은 55%에 그친다 (Security-related AI-Generated PRs). 돌아가기는 하는데 의도와 안전에서 어긋나는 것이다. AI가 아무리 빨리 발전해도 이 흐름은 당분간 이어지리라고 본다. 만약 여기까지 AI가 대신하게 된다면, 그때 사람에게는 할 일이 남아 있을까.

설계 각 결정의 근거

내가 가장 먼저 걱정한 것은 spec gaming이었다. 이건 언젠가 생길지 모르는 hypothetical risk가 아니다. 늘 깔려 있는 base rate다. “스펙을 LLM이 편하게 해석해서, 그냥 개선되었다고 판단하고, PR을 올리는 경우”는 이미 측정된 현상이다. METR 2025 report와 Palisade Research 모두 reasoning 모델일수록 reward hacking이 더 자주 일어난다고 보고한다 (Reward Hacking Benchmark).

panel에 multi-vendor를 강제한 것도 같은 걱정에서 나왔다. 같은 vendor 3개는 panel이 아니다. 이 대목에서 내가 남긴 말은 이랬다. “당연히 B 겠지. 학습한 데이터와 학습 방식이 전혀 다를테니까.” opus/sonnet/haiku는 결국 같은 표 3장이다. Mozilla AI의 Star Chamber 패턴이 이걸 production에서 쓰는 예로 보여 준다 (Star Chamber). 거기서는 3 모델이 default이고, confidence에 따라 consensus / majority / individual로 나눈다.

gate의 A+ rubric은 명확하게 쓸수록 reviewer agreement가 올라간다. 처음에는 “A+의 명확한 criteria와 예시를 명시해야 겠지.” 하는 감이었는데, 숫자로 확인되는 이야기였다. MultiChallenge benchmark에서는 rubric을 주었을 때 LLMAJ alignment가 37.3%에서 93.95%로 뛰었다 (Snorkel rubric design). 등급 라벨만으로는 모자랐고, 결과를 움직인 것은 주로 checklist criteria였다.

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에서 다 풀지 못했거나 아직 손에 잡히지 않는 영역이 6개 있었고, Round 2에서 하나가 더 붙었다.

가장 헷갈리는 것은 panel consensus trend를 어떻게 읽느냐다. consensus 비율이 70%에서 95%로 오르면 “maturity 신호”로 읽고 싶어진다. 그런데 그렇게만 읽어서는 안 된다. diversity가 유지될 때에만 좋은 신호이고, 그렇지 않다면 panel이 single voice로 무너진 spec gaming의 신호일 수 있다. 그래서 consensus rate와 따로 잴 diversity metric이 필요하다.

sprint success criteria도 아직 분명하게 정의하지 못했다. “1주차 = infrastructure phase”라는 reframe은 받아들였다. 그런데 실제로 sprint 1을 평가할 때 어떤 숫자로 성공과 실패를 가를지는 모르겠다. 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에게 넘기거나, 2 reviewer consensus를 거친 뒤 auto-merge로 흘려보내는 흐름이 필요한데, 아직 설계하지 못했다.

일반화에도 한계가 있다. 이 부분을 두고 나는 이렇게 적었다. “이 과정은 일반적인 harness 에서는 100% 못하는 시스템이 되겠어.” panel/gate/utility 구조는 일반화할 수 있지만 spec/TC는 project마다 다르다. 어디까지 harness-maker가 기본으로 주고 어디부터 project tuning인지, 그 경계를 아직 긋지 못했다.

마지막 질문은 사람의 리뷰가 결국 병목이라는 것이다. 앞에서 말한 trivial 자동 merge나 2인 peer 리뷰로 병목을 줄일 수는 있다. 하지만 사람이 자기 책임을 다해 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.