AI 요약 · 영어에서 AI 번역
Self-Improving AI Coding Agents Through Accumulated Behavioral Rules: A Closed-Loop Framework
Aditya Aggarwal, Nahid Farhady Ghalaty
TL;DR
정적 코딩 에이전트 지침 은 리뷰 피드백에서 얻은 경험을 반영해 발전하지 않는다. 이 논문은 사람의 리뷰에서 도출한 영속적 규칙과 체크리스트 기반 자기 검토를 결합한다. 관찰 기간에 추적한 오류 유형의 재발이 없었으며, 리뷰의 초점이 설계로 이동하고 규칙이 경계를 넘어 전이되었다고 보고한다.
문제
정적 코딩 에이전트 지침 은 관례를 담지만, 리뷰 결과로 향후 행동을 개선하는 피드백 루프가 없다.
출처: §I · p. 1방법
이 프레임워크는 일반화할 수 있는 사람의 리뷰 피드백을 세션마다 불러오는 영속적 행동 규칙으로 변환하고, 코드 생성에 체크리스트 기반 자기 검토를 결합한다.
출처: C. The Feedback Loop · p. 2결과
추적한 오류 유형 9개와 규칙 도입 후 누적 세션 노출 74회에서 재발 0건이 관찰되었으며, 리뷰의 초점이 설계로 이동하고 규칙이 경계를 넘어 전이되었다.
출처: §X · p. 8시사점과 한계
사람의 리뷰 지식은 미세 조정 없이, 모델별 전용 인프라 없이도 세션 간에 유지될 수 있다.
출처: §X · p. 8통제된 기준선이나 대응 조건의 구성요소 제거 실험이 없으므로, 보고된 오류 억제와 리뷰 초점의 변화는 인과적 증명이 아니라 초기 실증 근거를 제공한다.
출처: §VIII · p. 7
Abstract
from arXiv · showhide
LLM-based coding agents repeat the same classes of mistakes across sessions because they lack a mechanism to retain corrections from human review feedback. We present a closed-loop framework in which every accepted review comment is codified as a persistent behavioral rule, progressively expanding the set of error classes the agent can self-detect. The framework combines an accumulating rule set in a version-controlled instruction file, a self-review checklist executed before code submission, and automated validation that ensures rule set integrity as it grows. In deployment across a 35+ service microservices platform, the rule set grew from 5 to 18 behavioral rules, 15+ language-specific standards, and a 15-item self-review checklist, all derived from real review feedback. We present empirical results from 11 recorded working sessions spanning code generation, PR review, incident investigation, and cross service refactoring. We observe that accumulated rules shift review effort from low-level correctness toward design-level validation, achieve a measured 0% recurrence rate for ruled-against error classes, and transfer across heterogeneous agent interfaces. We compare our approach against related work in experiential LLM learning (Reflexion, ExpeL, Voyager) and automated code review (CodeReviewer, SWE-bench agents), showing that our framework achieves persistent cross-session learning without weight updates, operates on production codebases rather than synthetic benchmarks, and addresses an orthogonal dimension (behavioral consistency over time) that existing benchmarks do not measure. The result is a coding agent that improves with every review cycle, accumulating the engineering wisdom of its human collaborators without changing a single model weight.
I. 서론 · A. 범위와 연구의 위치
이 프레임워크는 수용된 인간 리뷰 피드백을 버전 관리되는 지침 파일에 영구적인 행동 규칙으로 저장하며, 모델 가중치를 갱신하지 않는다. 정해진 코드베이스에서 알려진 코딩 에이전트의 실패 유형을 다루며, 의미적 정확성을 보장하기보다 인간의 리뷰를 보완한다.
I. 서론
- 코딩 에이전트는 세션이 바뀌어도 리뷰에서 지적된 실수를 반복하지만, 미세 조정, RAG, 정적 지침 에는 리뷰 기반 행동 피드백 루프가 없다.미세 조정은 비용이 높고 조직에 특화된 방식으로 설명된다. RAG는 행동 제약이 아닌 코드 맥락을 제공하며, 정적 지침 은 경험에 따라 발전하지 않는다.출처: §I · p. 1
- 수용된 리뷰 의견은 영구적인 자체 검토 규칙이 되어, 프레임워크가 예방하려는 오류 유형의 범위를 줄어들지 않고 계속 확장한다.제안된 행동 규칙 누적 접근법은 예방 가능한 리뷰 지적을 없애는 것을 목표로 한다.출처: §I · p. 1
A. 범위와 연구의 위치
- 버전 관리되는 지침 파일은 가중치 갱신 없이 모델과 도구에 독립적인 운영 기억을 제공한다.이 공유 산출물은 팀원 간에 재사용할 수 있고 즉시 적용할 수 있다. 이 프레임워크는 재학습도 인간 피드백 기반 강화학습(RLHF) 도 사용하지 않는다.출처: §I · p. 1, A. Scope and Positioning · p. 2
I. 서론
- 기록된 11회의 작업 세션을 통해 코드 생성, PR 리뷰, 서비스 간 리팩터링, 장애 조사 전반에 걸쳐 규칙 누적, 오류 유형 억제, 지식 전이를 살펴본다.논문은 시스템 아키텍처와 실제 운영 환경 배포에서 얻은 정량적 실증 결과를 제시한다.출처: §I · p. 1
- Reflexion, ExpeL, Voyager [15], CodeReviewer, SWE-agent [16]와의 비교를 통해 세션 간에 지속되는 행동 일관성을 기존 벤치마크가 다루지 않는 차원으로 제시한다.비교 대상은 경험 기반 LLM 학습과 자동 코드 리뷰를 아우른다.출처: §I · p. 1
A. 범위와 연구의 위치
- 조직의 기억은 오직 수용된 리뷰 결과에서 형성되며, 개별 수정 사항을 정해진 코드베이스 내 오류 유형 단위의 행동 제약으로 전환한다.정적 지침과 달리 지침 파일은 리뷰 결과를 직접 반영하며 확장되고, 모든 새 규칙은 수용된 특정 리뷰 의견으로 근거를 추적할 수 있다.출처: A. Scope and Positioning · p. 2
- 이 프레임워크는 이전에 관찰된 오류를 대상으로 인간의 리뷰를 보완하지만, 의미적 정확성을 증명하거나 가능한 모든 실패를 예방하지는 않는다.의도한 효과는 리뷰어가 더 높은 수준의 문제에 집중할 여유를 확보하는 것이다.출처: A. Scope and Positioning · p. 2
II. 프레임워크 아키텍처 · A. 구조화된 지침 파일 · B. 규칙 표현
이 프레임워크는 수용된 검토 의견을 매 세션에 불러오는 버전 관리 지침 파일의 영속적 행동 규칙으로 변환한다. 구조화된 규칙 표현은 규칙의 근거가 된 검토를 자체 검토 체크리스트 항목과 연결하고, 향후 검증 도구를 지원한다.
II. 프레임워크 아키텍처
- 수용된 검토 의견은 각각 영속적 행동 규칙이 되어, 이후 세션에서 에이전트의 자체 검토 역량을 확장한다.Figure 1은 이 폐루프 피드백 순환을 보여준다.출처: Figure 1 · p. 2
A. 구조화된 지침 파일
- 에이전트는 매 세션을 시작할 때 버전 관리되는 Markdown 지침 파일을 시스템 컨텍스트로 불러온다.이 관례의 예로 AGENTS.md, 규칙 파일, 지침 파일이 있다.출처: A. The Structured Instruction File · p. 2
- 지침 파일은 항목을 추가하기 쉽고 단조 증가하며, 규칙을 추가하고 때때로 다듬되 거의 삭제하지 않는 방식으로 공학적 판단을 축적한다.이러한 축적이 파일의 핵심 속성으로 제시된다.출처: A. The Structured Instruction File · p. 2
- 실제 배포 환경에서는 지침을 행동 규칙, 코드 표준, 자체 검토 체크리스트, 안티패턴, 작업 흐름 규칙으로 구성한다.이들은 운영 안전장치, 언어별 검토 교훈, 코드 승인 전 점검, 금지된 패턴과 대안, 작업별 도구 또는 하위 에이전트 호출 조건을 다룬다.출처: A. The Structured Instruction File · p. 2
B. 규칙 표현
- 사람이 읽을 수 있는 Markdown 규칙은 식별자, 범주, 유래, 적용 범위, 제약, 근거, 체크리스트 매핑, 추가 날짜, 검토 출처 정보를 암묵적으로 담는다.예시로 제시된 R17 규칙은 새로운 내부 HttpClient 등록에 관한 것으로, 자체 검토 항목 #9에 연결된다.출처: B. Rule Representation · p. 2
- 규칙 스키마는 규칙을 그 근거가 된 검토 사건 및 자체 검토 체크리스트 항목과 연결하며, 향후 충돌 탐지와 효과성 점수화를 지원한다.체크리스트 매핑은 지침 파일과 제출 전 점검 사이에 검증 가능한 연결을 만든다.출처: B. Rule Representation · p. 2
C. 피드백 루프 … F. 신뢰성 확보 메커니즘으로서의 작업 공간 검증
이 프레임워크는 일반화 가능한 사람의 리뷰 피드백을 지속적으로 유지되는 행동 규칙으로 전환해, 세션을 거치며 에이전트의 자체 탐지 역량을 확장한다. 규칙 관리와 자동화된 세션 시작 검증으로 늘어나는 지침 집합을 유지·관리한다.
C. 피드백 루프
- 일반화 가능한 실수를 지적한 리뷰 의견이 수용되면 지속적으로 유지되는 규칙으로 전환되어, 에이전트가 이후 세션에서 스스로 탐지할 수 있는 오류 유형이 늘어난다.이 순환은 코드 생성, 체크리스트 기반 자체 검토, 사람의 리뷰, 규칙 추가, 갱신된 지침 다시 불러오기 순으로 진행된다. 지침 파일은 세션, 모델, 도구의 경계를 넘어 조직의 기억을 보존한다.출처: C. The Feedback Loop · pp. 2–3
D. 규칙의 수명 주기와 관리 체계
- 엔지니어는 재발 가능성이 있는 실수를 규칙으로 만들고, 규칙 ID를 보존하면서 지나치게 포괄적이거나 협소한 규칙을 수정한다.피드백을 받은 엔지니어가 해당 실수가 다른 맥락에서도 재발할 가능성이 있는지 판단한다.출처: D. Rule Lifecycle and Governance · p. 3
- 정기 검토에서는 구체적인 규칙이 일반적인 규칙을 흡수하도록 해 중복을 해소하고, 팀은 저장소의 풀 리퀘스트 리뷰 절차를 통해 규칙 간 충돌을 해결한다.공유 지침 파일을 변경하려면 풀 리퀘스트를 거쳐야 한다.출처: D. Rule Lifecycle and Governance · p. 3
E. 대표적인 규칙 예시
- 규칙은 호출자가 팩터리에서 생성한 HttpClient 인스턴스를 해제하지 못하게 하고, 구조화된 로깅 템플릿을 사용하도록 하며, 여러 조건을 모두 부정하는 논리곱에는 !A && !B && !C를 쓰도록 한다.이 규칙들은 자원 수명, 문자열 보간을 사용한 로그 메시지, 잘못된 불리언 가드 절에 관한 리뷰 지적에서 도출되었다.출처: E. Illustrative Rule Examples · p. 3
- 다른 규칙은 ?? throw new ArgumentException(...)을 통한 명시적 null 검증과 새로 등록하는 모든 HttpClient에 대한 SSRF 정책 항목을 요구한다.검토자는 null 허용 연산자 사용과 SSRF 허용 목록 항목이 누락된 내부 HTTP 클라이언트 등록을 지적했다.출처: E. Illustrative Rule Examples · p. 3
F. 신뢰성 확보 메커니즘으로서의 작업 공간 검증
- 세션 시작 검증은 에이전트 정의, 스킬 지침, 지식의 최신성, 지침 파일의 완전성, 자동화 스크립트, 도구 서버 설정을 점검해 잘못된 형식의 내용이 추가되는 것을 방지한다.검증 항목은 유효한 frontmatter와 필수 필드, 올바르게 구조화된 스킬 지침, 최신성 확인용 날짜, 지침의 필수 절, 스크립트의 존재 여부, 올바른 형식의 도구 서버 설정이다.출처: F. Workspace Validation as Reliability… · p. 3
G. 세션 연속성 … C. 지식 출처 분포
실제 운영에서는 세션 인계와 작업 기록으로 진행 중인 작업 맥락을 보존했으며, 여러 인터페이스의 에이전트가 하나의 지침 파일을 공유했다. 분석된 학습 출처 중 사람 검토자의 피드백이 39%를 차지했다.
G. 세션 연속성
- 세션 인계 파일은 진행 중인 작업, 대기 중인 검토, 권장 후속 조치를 세션 간에 보존한다.이를 통해 보존되는 지식의 범위가 행동 규칙에서 진행 중인 작업 맥락으로 확장된다.출처: G. Session Continuity · p. 3
- 작업 로그는 완료된 작업을 시간순으로 기록하여 세션 인계를 보완한다.두 메커니즘이 함께 세션 연속성을 지원한다.출처: G. Session Continuity · p. 3
A. 환경
- 배포 환경은 35+개 서비스와 약 50,000+줄의 공통 인프라 코드로 구성되었으며, 관리형 컨테이너 오케스트레이션과 서비스 메시를 사용했다.여러 인터페이스의 에이전트가 동일한 지침 파일을 읽었다.출처: A. Environment · p. 3
- 에이전트는 코드 생성, 검토, 아키텍처 조사, 장애 대응, 서비스 간 리팩터링을 지원했다.이러한 활동은 배포된 플랫폼 내 여러 에이전트 인터페이스에서 이루어졌다.출처: A. Environment · p. 3
B. 시간에 따른 규칙 축적
- 수 주간의 운영에서 보고된 규칙 집합의 증가 추이와 함께, 축적된 행동 규칙 18개를 출처별로 검토했다.제공된 Table I의 캡션은 관찰 종료 시점의 규칙 집합 구성을 명시하지만, 구성별 수치는 제시하지 않는다.출처: C. Knowledge Source Distribution · p. 3, B. Rule Accumulation Over Time · p. 3, Table I · p. 3
C. 지식 출처 분포
- 학습 출처의 39%는 사람 검토자의 피드백이었으며, 저자들은 이를 규칙 생성을 위한 가장 질 높은 신호로 평가한다.분석에서는 서로 구분되는 네 가지 학습 출처를 식별했다.출처: C. Knowledge Source Distribution · p. 3, Table II · p. 4
D. 관찰된 효과 … A. 실험 설정
규칙 추가 이후 기록된 11회의 작업 세션에서 관찰 기간 내에 규칙으로 금지한 패턴이 재발하지 않았다. 검토자들은 기계적으로 확인할 수 있는 문제에 쓰는 시간이 줄고, 아키텍처의 적절성과 설계상 절충을 검토하는 시간이 늘었다고 보고했다.
D. 관찰된 효과
- 규칙 추가 이후 기록된 11회의 작업 세션에서 관찰 기간 내에 규칙으로 금지한 패턴이 재발하지 않았다.이는 관찰된 배포 조건에서 해당 패턴이 억제되었음을 뜻하며, 기반 모델의 영구적 속성을 의미하지는 않는다.출처: D. Observed Effects · p. 4
- 검토자들은 기계적으로 확인할 수 있는 문제에 쓰는 시간이 줄고, 아키텍처의 적절성과 설계상 절충을 검토하는 시간이 늘었다고 보고했다.출처: D. Observed Effects · p. 4
- 새 팀원들은 축적된 규칙 집합을 즉시 물려받아, 그 규칙들이 만들어지기까지 거쳤던 학습 과정을 생략할 수 있었다.출처: D. Observed Effects · p. 4
- 규칙 집합이 포괄적 지침에서 정밀한 요구사항으로 발전하면서, 구체적이고 실행 가능한 규칙이 일반적 지침보다 더 일관되게 준수되었다.출처: D. Observed Effects · p. 4
E. 규칙 충돌: 구체적 사례
- 모든 IDisposable에 using 선언을 적용하는 규칙과 팩터리에서 생성한 HttpClient 인스턴스는 해제하지 않는 규칙 사이의 충돌 한 건은 일반 규칙의 적용 범위를 좁혀 해결했다.코드 검토에서 모순을 발견했으며, 해결의 기준은 주관적 판단이 아니라 올바른 프레임워크 동작이었다.출처: E. Rule Conflicts: A Concrete Example · p. 4
F. 다중 인터페이스 간 행동 전이
- IDE 통합형 에이전트와 터미널 기반 에이전트가 동일한 지침 파일을 불러오므로, 축적된 규칙이 두 인터페이스 사이에서 즉시 전이되었다.IDE 에이전트는 저장소 분석에, 터미널 에이전트는 실행에 강점을 보였으며, 둘 다 축적된 규칙의 이점을 동등하게 얻었다. 저자들은 이를 전문화된 다중 에이전트 작업 흐름의 공유 메모리로 활용할 수 있다고 제안한다,.출처: F. Multi-Interface Behavioral Transfer · p. 4, D. Observed Effects · p. 4
A. 실험 설정
- 배포 플랫폼은 35+개 서비스로 구성되었으며, 두 에이전트 인터페이스가 동일한 공유 지침 파일을 사용했다.플랫폼에는 맞춤형 에이전트 정의 13개, 운영 스킬 10개, 공유 지식 문서 6개가 포함되었다. 데이터 출처는 날짜가 명시된 작업 로그 항목 11개, 커밋된 지침 파일 수정본 2개와 지속적인 로컬 확장 내역, 주제별 메모리 문서 4개, 저장소 6개에 걸친 PR 검토 36건이었다.출처: A. Experimental Setup · p. 4
B. 규칙 축적 추이 … E. 지식 전이 양상
실제 운영에서 규칙 도입 후 재발은 기록되지 않았으며, 리뷰 의견은 아키텍처, API 설계, 성능에 집중되었다. 시간이 지나면서 규칙 증가세는 둔화되었고, 문서화된 지식 전이의 대부분은 저장소나 도구의 경계를 넘었다.
B. 규칙 축적 추이
- 통합 지침의 분량은 약 4,809단어(∼6,250 토큰)로, 128K 토큰 컨텍스트 윈도우의 5% 미만을 차지했다.출처: B. Rule Accumulation Dynamics · p. 4
- 규칙 축적은 로그 곡선을 따랐다. 초기에는 빠르게 증가했으나, 가장 자주 접하는 패턴을 규칙이 포괄하면서 증가세가 둔화되었다.출처: B. Rule Accumulation Dynamics · p. 4, Table III · p. 4
C. 오류 유형별 재발 분석
- 규칙 도입 후 누적 74회의 세션 노출 동안 추적한 9개 오류 유형에서 재발 0건을 기록했다.이는 오류 유형별 재발 분석의 핵심 결과였다.출처: Table IV · p. 4, C. Error-Class Recurrence Analysis · p. 4
- 재발이 없었다는 결과는 단일 운영 사례에서 얻은 관찰적 증거이며, 통제 실험이나 영구적인 보장이 아니다.이 결과는 관찰 기간에 한정되며, 논문에서 논의한 타당성 위협의 영향을 받는다.출처: C. Error-Class Recurrence Analysis · p. 4
D. 리뷰 의견 범주의 변화
- 리뷰 의견의 14%는 기계적 정확성과 스타일에 관한 것이었고, 66%는 아키텍처, API 설계, 성능에 관한 것이었다.분석 대상은 6개 저장소의 PR 리뷰 36건이었으며, 기존 코드 리뷰 연구, 의 분류 기준을 조정해 적용했다.출처: D. Review Comment Category Shift · p. 5, Table V · p. 5
E. 지식 전이 양상
- 지식 전이의 60%(9/15)가 저장소나 도구의 경계를 넘어 이루어져, 도구 독립적 인코딩의 폭넓은 적용 가능성을 뒷받침했다.전이 유형 체계는 문서화된 리뷰 교훈 15건을 분류했다.출처: E. Knowledge Transfer Patterns · p. 5, Table VI · p. 5
F. 규칙 구체성의 변화 … A. 결과 요약
배포 관찰 기간에 추적한 기존 교정 오류 유형은 재발하지 않았으며, 도구·저장소·작업 유형 간 지식 전이가 관찰되었다. 규칙은 점차 구체화되었고, 3계층 영속 메모리는 128K 컨텍스트 윈도의 5% 미만을 차지했다.
F. 규칙 구체성의 변화
- 구체적인 검토 의견을 바탕으로 구체적 규칙이 새로 생성되고 기존의 일반적 규칙이 정교화되면서 구체성 비율이 단조 증가했다.Table VII는 시간에 따른 규칙 구체성의 변화를 보여준다.출처: Table VII · p. 5, F. Rule Specificity Evolution · p. 5
G. 다계층 메모리 아키텍처
- 프레임워크의 3계층 아키텍처에서 ∼4,809단어(∼6,250토큰)의 영속 메모리가 128K 컨텍스트 윈도에서 차지한 비중은 <5%였다.Table VIII는 메모리 계층 구조를 제시한다.출처: Table VIII · p. 5, G. Multi-Layer Memory Architecture · p. 5
H. 세션 작업의 다양성
- 규칙의 39%는 PR 검토와 장애 조사에서 도출되었으며, 이는 코드 생성 외의 비생성 작업도 규칙 축적에 기여했음을 보여준다.Table IX는 세션별 작업 분포를 제시한다.출처: Table IX · p. 5, H. Session Task Diversity · p. 5
A. 결과 요약
- 모델 자체의 변경 없이, 수용된 인간 검토 피드백에서 행동 규칙 18개, 언어별 코드 표준 15+개, 15개 항목의 자체 검토 체크리스트를 도출했다.이 산출물은 버전 관리되는 지침 파일에 저장되었으며, 여러 에이전트 인터페이스에서 활용되었다.출처: A. Summary of Findings · p. 5
- 4주간의 배포 기간에 추적한 오류 유형 9개와 규칙 도입 후 누적 세션 노출 74회에서 관찰된 재발은 0건이었다.이는 통계적 보장이 아닌 관찰 결과다. 배포 대상은 한 팀과 하나의 주 사용 언어였으며, A/B 대조군은 없었다.출처: A. Summary of Findings · p. 5
- 관찰된 지식 전이 사례의 60%(9/15)는 저장소·도구·작업 유형의 경계를 넘었다.한 인터페이스에서 추가한 규칙은 다른 인터페이스를 사용하는 세션에도 즉시 적용되었다. 일반 Markdown으로 작성한 선언적 자연어 제약은 해당 파일을 시스템 컨텍스트로 불러오는 에이전트로의 전이를 가능하게 했다.출처: A. Summary of Findings · p. 5
B. 연관성과 기여 … C. ExpeL: 과제 간 경험 학습
이 프레임워크는 사람이 검토하고 수용한 피드백을 표준 엔지니어링 절차로 관리하는 영속적이고 감사 가능한 규칙으로 전환한다. 이러한 규칙은 Reflexion 의 에피소드별 자기 성찰 및 ExpeL 이 자율적으로 추출한 통찰과 구별된다.
B. 연관성과 기여
- 이 프레임워크는 특정 공급업체에 종속되지 않는 에이전트를 코드 리뷰에 통합하고, 출처·담당자·변경 이력·제출 전 체크리스트 내 위치가 문서화된 규칙을 통해 조직 지식을 감사 가능한 형태로 만든다.각 규칙은 해당 리뷰 사례, 의견을 수용한 엔지니어, 규칙을 추가한 PR까지 추적할 수 있다.출처: B. Match and Contribution · p. 6
- 배포 가능한 지침 파일은 파인튜닝, 모델별 전용 도구, 특수 메모리 백엔드 없이 표준 인프라를 활용해 규칙 스키마, 수명주기, 검증, 피드백 루프를 결합한다.실제 배포에는 Git, Markdown, PR 리뷰, 일반 텍스트 검증 스크립트를 사용했으며, 조직은 기존 인프라로 이 방식을 재현할 수 있다.출처: B. Match and Contribution · p. 6
- 근거는 단일 팀, 단일 언어, 4주간의 관찰에 한정되며, 통제된 기준선이 없고 규칙 충돌과 수명주기 관리상의 과제도 기록되어 있다.논문은 구체적인 규칙 충돌과 해결 과정, 관리 체계에 관한 쟁점, 실증적 타당성을 위협하는 요인을 보고한다.출처: B. Match and Contribution · p. 6
- 배포 기간에 관찰된 PR 리뷰 의견의 66%는 아키텍처, API 설계 또는 성능에 관한 것이었고, 14%는 기계적 정확성에 관한 것이었다.해당 기간에는 이전에 수정된 오류 유형의 재발이 억제되었다. 축적된 규칙은 새 팀원이 조직의 리뷰 이력을 파악하도록 돕는, 전수 가능한 온보딩 자료로도 기능한다.출처: B. Match and Contribution · p. 6
A. 비교 틀
- Table X는 주요 차원에 따라 관련 연구를 체계적으로 비교한다.제공된 본문은 비교 표를 언급하지만 셀 값이나 순위는 제시하지 않는다.출처: A. Comparison Framework · p. 6
B. Reflexion: 세션 내 언어적 강화
- 과제 피드백에 대한 언어적 성찰을 일화 기억에 저장하는 Reflexion 은 HumanEval에서 91% pass@1을 기록한 것으로 보고된다.논문은 Reflexion의 자체 생성된 에피소드 한정 피드백을, 사람이 수용하고 이후 세션마다 불러오는 규칙과 대비한다. 이후 세션에서는 서로 다른 모델이나 에이전트 인터페이스를 사용할 수도 있다. 두 메커니즘은 상호 보완적인 것으로 보되, 개별 문제의 통과율과 다양한 실무 과제 전반의 오류 유형 억제를 구별한다.출처: B. Reflexion: Verbal Reinforcement… · p. 6
C. ExpeL: 과제 간 경험 학습
- 사람이 검증한 규칙은 전문가 검토 이력을 갖추고 근본적으로 다른 과제 유형 간에 전이된다는 점에서 ExpeL 의 자율적 통찰과 다르다.ExpeL은 자율적으로 경험을 수집하고 자연어 통찰을 추출하며, 동일한 과제 유형 내에서 이를 전이한다. 논문은 잘못된 규칙이 권위 있는 맥락으로 제공되면 세션 전반에 걸쳐 오류를 증폭시킬 수 있으므로 사람의 검증이 필수적이라고 주장한다.출처: C. ExpeL: Experiential Learning Across… · p. 6
D. Voyager: 영구적 스킬 라이브러리 … H. 메모리 증강 LLM 시스템
이 프레임워크는 영구적으로 유지되는 선언적 행동 규칙을 실행 가능한 스킬 라이브러리, 가중치 학습 기반 리뷰 모델, 단일 실행 맥락 내 자기 개선, 이슈 해결 벤치마크와 구분한다. 메모리는 사람이 읽을 수 있고 버전 관리되는 Markdown 규칙으로 구성된다.
D. Voyager: 영구적 스킬 라이브러리
- Voyager [15]는 실행 가능한 Minecraft 스킬을 저장하는 반면, 이 프레임워크는 선언적 자연어 제약을 저장한다. 둘 다 영구적으로 유지되고 버전 관리되는 지식을 활용해 역량을 누적한다.Voyager의 스킬 라이브러리는 실행 가능한 코드 함수로 구성된다.출처: D. Voyager: Persistent Skill Libraries · p. 6
E. 사전 학습된 코드 리뷰 모델
- 사전 학습된 리뷰 모델, 와 달리, 이 프레임워크는 맥락을 통해 규칙을 주입하고 실시간으로 지식을 축적하며 조직 고유의 관례를 반영한다.비교 대상 모델은 가중치를 미세 조정하고 학습 시점에 지식이 고정되며, 공개 코드베이스에 드러나지 않는 관례를 반영하기보다 여러 공개 저장소에 걸쳐 일반화한다.출처: E. Pre-trained Code Review Models · p. 6
F. SWE-bench 에이전트
- 최첨단 에이전트는 SWE-bench Lite 이슈의 20–40%를 해결한다. SWE-bench 와 에이전트 구현체 [16],, [20]은 개별 GitHub 이슈의 해결 능력을 평가한다.이는 배경 정보로 제시한 벤치마크 성능이며, 제안된 프레임워크의 측정 결과가 아니다.출처: F. SWE-bench Agents · p. 7
- 이 프레임워크는 알려진 실수의 재발 방지와 시간에 걸친 행동 일관성을 목표로 하며, 저자들은 기존 벤치마크가 이 차원을 평가하지 않는다고 설명한다.반면 SWE-bench는 에이전트가 이슈를 해결할 수 있는지를 묻는다.출처: F. SWE-bench Agents · p. 7
G. Self-Taught Optimizer, Self-Refine, Self-Debugging
- 하나의 실행 맥락 안에서 작동하는 STOP, Self-Refine, Self-Debugging [22]와 달리, 이 프레임워크는 개선 사항을 영구적으로 유지한다.STOP 은 스캐폴딩 코드를 재귀적으로 개선하고, Self-Refine 은 스스로 생성한 비평을 활용해 개선을 반복하며, Self-Debugging [22]은 러버덕 방식의 설명을 활용한다.출처: G. Self-Taught Optimizer, Self-Refine,… · p. 7
H. 메모리 증강 LLM 시스템
- MemoryBank 및 관련 메모리 시스템과 비교할 때, 이 프레임워크는 더 단순한 저장소, 즉 사람이 읽고 감사할 수 있으며 버전 관리되는 Markdown 규칙을 사용한다.규칙은 일반 텍스트 파일에 저장된다.출처: H. Memory-Augmented LLM Systems · p. 7
I. 지속적 기억을 갖춘 개인용 AI 비서 … A. 타당성 위협
이 프레임워크는 수용된 코드 리뷰 피드백을 여섯 가지 설계 원칙에 따라 팀이 공유하는 행동 제약으로 전환한다. 근거는 아직 예비 수준이며, 대조 조건, 통계적 검정력, 배포 환경의 다양성, 장기 관찰이 제한적이다. 규모 확장과 리뷰 품질에 관한 위험도 해결되지 않았다.
I. 지속적 기억을 갖춘 개인용 AI 비서
- 개별 사용자의 대화 속 사실을 기억하는 OpenClaw 와 달리, 이 프레임워크는 수용된 코드 리뷰 피드백에서 팀 수준의 선언적 제약을 도출해 특정 오류 유형의 발생을 방지한다.OpenClaw 는 개인용 AI 비서에 지속적 기억과 스킬 라이브러리를 제공한다.출처: §I · p. 7
VII. 설계 원칙
- 구체성 비율은 0.60에서 0.78로 증가했다. 여섯 가지 원칙은 단조 증가, 구체성, 출처 추적, 도구 독립적 표현, 검증을 거친 확장, 공동 소유를 강조한다.구체적 제약이 추상적 지침보다 효과적이다. 규칙은 다듬되 삭제하지 않으며, 리뷰 의견이나 운영 환경에서 발생한 사건으로 출처를 추적할 수 있다. 구조화된 Markdown은 2개 플랫폼 간에 이전되었다. 규칙 추가 시 자동 검증을 거치며, 공유 저장소에서 PR을 통해 변경한다.출처: §VII · p. 7
VIII. 한계와 타당성 위협
- 현재 ∼6,250 토큰은 컨텍스트 한도 안에 들어가지만, 규칙의 무제한 증가와 여러 팀에 걸친 관리 체계는 해결되지 않은 규모 확장 제약으로 남아 있다.규칙 집합이 커지면 계층적 구성이나 요약이 필요할 수 있다. 여러 팀에서는 규칙의 분절이나 모순을 피하기 위해 계층적 규칙 또는 네임스페이스별 규칙과 명시적 충돌 해결 정책이 필요하다. 충돌 한 건을 수동으로 찾아내야 했으며, 이는 자동 충돌 탐지의 필요성을 보여준다.출처: §VIII · p. 7
- 도입에는 수용된 서면 리뷰 피드백, 이를 규칙으로 명문화할 엔지니어의 시간, 프로젝트 수준의 지침을 불러오고 따르는 에이전트 인터페이스가 필요하다.전제 조건이 하나라도 빠지면 피드백 순환에 필요한 입력이 고갈되거나 규칙이 무시될 수 있다. 저자들은 모든 변경 사항에 동료 리뷰를 수행하는 중대형 엔지니어링 조직에서 가장 활발한 도입을 예상한다.출처: §VIII · p. 7
- 규칙 도입 후 9개 오류 유형에 대한 74회의 노출, 6개 저장소의 PR 36건, 11회의 세션은 예비 근거를 제공하지만, 인과관계의 입증이나 공식적인 통계적 유의성 주장을 뒷받침하지는 않는다.관찰 기간 내 오류 재발이 없었고 리뷰 의견의 초점이 설계 수준으로 이동했다. 병렬 대조군은 없었으며, 동일한 작업 흐름에서 정적 프롬프트 엔지니어링이나 규칙 없는 기준선과 짝지어 비교한 절제 실험도 없었다.출처: §VIII · pp. 7–8
A. 타당성 위협
- 단일 조직에서 프레임워크 관례가 강한 타입 언어 환경에 배포했다는 점은 다른 코드베이스나 언어, 프레임워크 사용이 덜 일관적인 환경으로의 일반화 가능성을 제한한다.컴파일 시점의 제약이 약하거나 프레임워크 사용이 일관적이지 않으면 리뷰 의견의 분포가 달라지고 규칙 기반 오류 억제의 이점이 줄어들 수 있다.출처: A. Threats to Validity · p. 8
- 규칙의 품질은 인간 리뷰어에게 달려 있다. 잘못된 규칙은 오류를 증폭시키며, 잡음이 많은 리뷰 문화는 검증이 문제를 포착하는 속도보다 빠르게 규칙 집합을 훼손할 수 있다.출처: A. Threats to Validity · p. 8
- 4주와 11회의 세션만으로는 장기적인 증가 양상을 규명할 수 없으며, 규칙이 가용 컨텍스트 윈도우를 가득 채웠을 때의 동작은 아직 관찰되지 않았다.출처: A. Threats to Validity · p. 8
IX. 부재한 벤치마크 … 향후 연구 방향
지속적으로 보존되고 버전 관리되는 규칙은 사람의 검토 피드백을 세션 간 지침으로 전환하며, 배포 후 관찰 기간 동안 추적한 오류 유형에서는 재발이 관찰되지 않았다. 이 절에서는 시간적 벤치마크, 기업의 점진적 도입, 효과·자동화·거버넌스에 관한 후속 연구를 제시한다.
IX. 부재한 벤치마크
- 제안하는 벤치마크는 교정이 세션을 넘어 유지되는지 검증하며, 정적 역량뿐 아니라 시간에 따른 행동 일관성을 평가한다.검토에서 도출해 선별한 규칙 말뭉치, 금지된 패턴을 유발하는 초기 과제, 세션 경계를 넘어 교정의 지속성을 검증하는 과제 시퀀스를 결합한다. 이러한 시간적 차원은 SWE-bench, HumanEval, CodeReview 벤치마크를 보완할 수 있다.출처: §IX · p. 8
X. 결론
- 지속적으로 보존되고 버전 관리되는 규칙은 사람의 검토 피드백을 명문화하며, 가중치 갱신이나 모델별 기반 시설 없이 자체 탐지 가능한 오류 유형을 누적 확장한다.규칙 집합은 행동 규칙 5개에서 18개로 늘었으며, 여기에 15+개의 코드 표준과 15개 항목의 자체 검토 체크리스트가 더해졌다. 미세 조정이나 기존 LLM 아키텍처 변경은 필요하지 않다.출처: §X · p. 8
- 규칙 도입 후 추적한 오류 유형 9개에 대한 누적 세션 노출 74건에서 관찰 기간 동안 재발이 관찰되지 않았다.운영 환경 배포는 35+개의 마이크로서비스와 기록된 세션 11회에 걸쳐 이루어졌다. 이는 관찰 결과이며, 한계도 명시적으로 인정한다.출처: §X · p. 8
- 검토 의견의 66%는 아키텍처/API/성능에, 14%는 기초적 정확성에 관한 것으로, 관심이 설계 수준의 문제로 이동했음을 보여준다.관찰된 사례의 60%에서 규칙이 경계를 넘어 전이되었다.출처: §X · p. 8
기업 환경에서의 프레임워크 운영
- 기업은 공유 지침, 검토에 기반한 규칙 승격, 자동 검증, 풀 리퀘스트 거버넌스를 통해 기존 도구 체계 안에서 점진적으로 도입할 수 있다.버전 관리되는 지침 파일에 모든 에이전트 인터페이스가 읽어 적용하는 행동 규칙, 언어별 표준, 자체 검토 체크리스트를 담는다. 수용된 검토 의견 중 일반화 가능한 내용을 같은 PR이나 후속 PR에서 규칙으로 승격하고, CI나 pre-commit 훅으로 형식과 스키마를 검증하며, 지침 변경도 코드처럼 검토한다.출처: Operationalizing the Framework in an… · p. 8
향후 연구 방향
- 향후 평가에서는 규칙을 불러오는 에이전트를 규칙 없는 기준선과 비교하고, 여러 조직에서 재현 연구를 수행해 효과와 적용 한계를 검증해야 한다.제안하는 A/B 연구는 동일한 유입 과제 흐름과 사전 등록한 검토 의견 수, 결함 유출률, 검토자 작업 시간 지표를 사용한다. 재현 연구에서는 프로그래밍 언어, 코드베이스 규모, 검토 문화를 달리하고, 세션 간 행동 일관성 벤치마크도 함께 적용해야 한다.출처: Future Research Directions · p. 8
- 향후 도구는 유사한 검토 의견에서 규칙을 제안하고, 병합 전에 충돌을 탐지하며, 출처 추적을 통해 여러 팀의 규칙 조합을 지원해야 한다.거버넌스 모델은 드러나지 않은 모순을 방지하고, 규칙의 적용 범위가 팀에서 조직 전체로 확대될 때도 출처를 보존해야 한다.출처: Future Research Directions · p. 9
Related papers
This paper cites
- Training language models to follow instructions with human feedback2022
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues?2023
- Self-Refine: Iterative Refinement with Self-Feedback2023
- Voyager: An Open-Ended Embodied Agent with Large Language Models2023
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering2024
- Agentless: Demystifying LLM-based Software Engineering Agents2024