오늘 GeekNews 최신 글 1위는 개인 실험이지만, AI 코딩 에이전트를 운영한다면 상당히 유용합니다. 작성자는 동일 코드에 약 400회의 LLM 호출을 사용해 리뷰와 수정 패턴을 비교했습니다. 이 결과는 단일 연구 프로젝트이므로 일반적인 과학적 결론으로 확대해서는 안 되지만, 실제 workflow 설계에는 참고할 만합니다. news.hada.io
가장 흥미로운 결과는 리뷰 반복과 리뷰→수정 반복이 전혀 달랐다는 것입니다.
같은 코드를 그대로 놓고 리뷰만 반복했을 때 실제 결함 발견률은:
34% → 61% → 76%
로 올라갔습니다.
반면 매번 리뷰 결과를 곧바로 수정하게 했을 때는 테스트상 계약 준수율은 개선되지 않았는데 코드 크기만 24~152% 증가하는 경우가 나타났습니다. edgelog.dev
또 가장 강한 개선은 모델을 바꾸는 것이 아니라 리뷰어에게 전체 저장소를 읽을 수 있게 하는 것이었습니다. 대상 파일 하나만 제공했을 때 오탐률이 29%였지만 호출자·헤더·초기화 경로 등을 확인할 수 있게 하자 반복적으로 발생했던 오탐 네 종류가 두 모델 모두에서 사라졌습니다. edgelog.dev
실무 적용
AI 코드 리뷰 pipeline이라면 다음 구조가 합리적입니다.
Review 1
↓
Review 2
↓
Review 3
↓
Findings merge / dedupe
↓
Repository context 검증
↓
Fixer 1회
↓
Tests
즉 AI가 지적할 때마다 코드를 수정시키는 것보다 여러 리뷰를 먼저 모은 뒤 검증·중복제거하고 한 번에 수정하는 방식이 코드 churn을 줄일 가능성이 있습니다.
그리고 에이전트에게 파일 한 개만 던지는 것보다 repository-level context를 읽을 수 있게 하는 것이 모델 업그레이드보다 효과적일 수 있다는 점도 눈여겨볼 만합니다. edgelog.dev
짧게 볼 개발 신호
GeekNews에는 SonicMoE GPU 커널 최적화 사례도 올라왔습니다. 핵심은 MoE에서 gather → projection → scatter 사이에 발생하는 대규모 중간 텐서와 메모리 IO를 줄이기 위해 kernel fusion을 적용하는 방식입니다. 특히 gather 결과를 별도 메모리에 쓰지 않고 다음 projection에서 직접 읽도록 융합해 순수 IO 오버헤드를 제거합니다. AI 모델 성능 경쟁이 아키텍처뿐 아니라 메모리 이동을 얼마나 줄이느냐의 경쟁이 되고 있음을 잘 보여주는 개발 사례입니다. blog.trillionlabs.co