본문 바로가기
최신IT 정보/IT 개발정보

AI 에이전트는 어떻게 밤새 실험하고, 아침에 리뷰 가능한 코드만 남길 수 있을까? (feat. pi-autoresearch)

by cool21th 2026. 4. 19.
반응형

pi-autoresearch 저장소를 읽으며 본 자동 실험 루프의 구조

AI 코딩 에이전트를 쓰다 보면 한 번쯤 이런 생각을 하게 된다.

“이 작업은 사람이 계속 붙잡고 있을 필요가 있을까?”

예를 들어 테스트 시간이 너무 길다. 번들 크기를 줄이고 싶다. 빌드 속도를 조금이라도 올리고 싶다. Lighthouse 점수를 개선하고 싶다.
이런 일들은 대개 정답이 하나로 정해져 있지 않다. 작은 아이디어를 여러 번 시도하고, 숫자를 재고, 좋아진 방향만 남기는 식으로 접근한다.

사람이 하면 지루하다.
에이전트가 하면 반복할 수 있다.

그런데 여기서 중요한 질문이 하나 생긴다.

에이전트가 정말로 여러 번 실험한다면, 그 결과를 우리는 어떻게 믿고, 어떻게 리뷰하고, 어떻게 코드베이스로 되돌릴 수 있을까?

이번에 읽은 davebcn87/pi-autoresearch는 바로 이 질문을 다루는 저장소다.

겉으로 보면 “AI가 자동으로 최적화해주는 도구”처럼 보인다. 하지만 저장소를 조금 더 열어 보면, 이 프로젝트의 진짜 관심사는 단순한 성능 개선이 아니다.

핵심은 이것이다.

에이전트가 실험을 반복하고, 결과를 파일에 기억하고, 실패한 시도는 되돌리고, 성공한 변경만 나중에 사람이 리뷰할 수 있는 브랜치로 정리하는 워크플로.

나는 이 저장소를 읽으며 “자동 최적화 도구”보다 “AI 에이전트 시대의 실험 운영 방식”에 더 가깝다고 느꼈다.

한 문장으로 말하면

pi-autoresearch는 Pi 터미널 에이전트에 붙는 자동 실험 루프 확장 기능이다.

사용자가 목표와 측정 방법을 정하면, 에이전트는 코드를 수정하고, 벤치마크를 실행하고, 지표를 기록한다. 결과가 좋아지면 남기고, 나빠지면 되돌린다. 그리고 이 과정을 반복한다.

흐름은 단순하다.

아이디어를 시도한다
→ 벤치마크를 실행한다
→ 숫자를 기록한다
→ 좋아지면 keep
→ 나빠지면 revert
→ 다시 시도한다

이 구조만 보면 흔한 자동화처럼 보일 수 있다. 하지만 이 저장소의 흥미로운 점은 루프 자체보다, 루프를 둘러싼 운영 장치에 있다.

에이전트가 중간에 끊겨도 이어갈 수 있도록 autoresearch.jsonl과 autoresearch.md를 남긴다. 실험이 끝난 뒤에는 성공한 커밋들을 다시 사람이 리뷰하기 좋은 브랜치로 나눈다. 실패한 실험도 단순히 버리지 않고, 다음 실험을 위한 힌트로 남긴다.

즉 이 프로젝트는 “AI가 코드를 바꿨다”에서 끝나지 않는다.

AI가 바꾼 코드를 사람이 다시 이해할 수 있는 상태로 되돌리는 것까지 생각한다.

왜 흥미로운가

자동화 도구는 많다. 성능 측정 도구도 많다. 벤치마크 스크립트도 누구나 만들 수 있다.

그런데 pi-autoresearch가 흥미로운 이유는, 이 모든 것을 에이전트의 장기 작업 흐름으로 엮는다는 점이다.

AI 에이전트는 기본적으로 대화형이다.
지시를 받고, 코드를 읽고, 수정하고, 설명한다.

하지만 긴 실험은 대화형 작업과 잘 맞지 않는다. 실험은 지루하고 반복적이다. 문맥은 길어지고, 세션은 끊기고, 왜 이전 아이디어가 실패했는지도 잊기 쉽다.

pi-autoresearch는 이 문제를 파일로 푼다.

autoresearch.jsonl에는 실험 결과가 한 줄씩 쌓인다.
autoresearch.md에는 사람이 읽을 수 있는 세션 설명이 남는다.
autoresearch.sh에는 실제 측정 명령이 담긴다.
필요하면 autoresearch.checks.sh로 성능 외 검증도 분리한다.

이렇게 하면 에이전트의 기억은 대화창 안에만 머무르지 않는다. 저장소 안의 파일로 남는다.

이 점이 중요하다.

AI 에이전트가 긴 작업을 하려면, 똑똑한 추론만으로는 부족하다.
끊겨도 다시 이어갈 수 있는 기록 방식이 필요하다.

이 저장소는 성능 도구라기보다 워크플로 도구다

처음에는 나도 이 저장소를 성능 최적화 도구로 읽으려고 했다.

하지만 곧 생각이 바뀌었다.

이 저장소의 핵심 가치는 더 빠른 벤치마크 알고리즘이 아니다. 더 정교한 프로파일러도 아니다. 오히려 중요한 것은 에이전트가 실험을 어떻게 조직하고, 어떤 기준으로 남기고 버리며, 마지막에 사람이 검토할 수 있는 결과물로 어떻게 정리하는가다.

그래서 이 프로젝트는 이렇게 분류하는 편이 더 정확하다.

에이전트 자동화 워크플로 저장소.

확장 기능은 실행 인프라를 맡는다.
스킬 문서는 에이전트가 따라야 할 절차를 맡는다.
Bash 스크립트는 마지막 브랜치 정리를 맡는다.
로그 파일은 실험 기억을 맡는다.

이 구조를 이해하고 나면 pi-autoresearch의 설계가 꽤 선명해진다.

Extension = 실행 도구
Skill = 에이전트 운영 규칙
JSONL = 기계가 읽는 실험 기록
Markdown = 사람이 읽는 실험 문서
finalize = 자동 실험을 리뷰 가능한 브랜치로 회수하는 단계

이 분리가 이 저장소의 가장 큰 장점이다.

저장소를 읽는 순서

이런 저장소는 README만 읽으면 절반만 이해하게 된다.
README는 제품 약속을 말해주지만, 실제로 중요한 건 그 약속이 코드와 스크립트에서 어떻게 구현되어 있는지다.

내가 읽은 순서는 대략 이렇다.

먼저 README.md에서 프로젝트가 스스로를 어떻게 설명하는지 확인했다. 여기에는 설치 방법, 기본 명령, 자동 실험 루프, 대시보드, finalize 단계가 소개되어 있다.

그다음 핵심 구현인 extensions/pi-autoresearch/index.ts를 봤다. 이 파일에는 실험 초기화, 명령 실행, 로그 기록, 대시보드, 세션 재개 흐름이 꽤 많이 모여 있다.

이후 skills/autoresearch-create/SKILL.md와 skills/autoresearch-finalize/SKILL.md를 읽었다. 전자는 새 실험 세션을 어떻게 만들지, 후자는 성공한 실험을 어떻게 정리할지에 대한 운영 규칙에 가깝다.

마지막으로 skills/autoresearch-finalize/finalize.sh와 tests/finalize_test.sh를 확인했다. 특히 finalize 단계는 이 저장소가 단순 자동 실험 도구가 아니라는 것을 보여주는 핵심 부분이다.

핵심은 세 개의 도구다

pi-autoresearch의 루프는 크게 세 가지 도구로 설명할 수 있다.

첫째, init_experiment.

이 단계에서는 실험의 기준선을 잡는다. 무엇을 최적화할지, 어떤 지표를 볼지, 낮을수록 좋은지 높을수록 좋은지 같은 기준을 정한다.

둘째, run_experiment.

여기서는 실제 벤치마크 명령을 실행한다. 실행 시간, 출력, 실패 여부, METRIC name=value 형식의 지표를 수집한다.

셋째, log_experiment.

이 단계가 가장 중요하다. 실험 결과를 기록하고, 좋아진 변경은 keep하고, 실패하거나 나빠진 변경은 되돌린다.

이 구조는 간단하지만 강력하다.
특히 log_experiment는 이 저장소의 철학을 잘 보여준다.

실험은 많이 하는 것보다, 어떤 실험을 남길지 결정하는 것이 더 중요하다.
나쁜 실험을 많이 쌓으면 저장소는 망가진다.
좋은 실험만 남기면 나중에 리뷰할 수 있다.

pi-autoresearch는 이 판단을 Git 작업과 연결한다.

좋은 결과는 커밋한다.
나쁜 결과는 되돌린다.
실패 이유는 로그에 남긴다.

이것이 자동 실험 루프의 최소한의 질서다.

숫자는 흔들린다

벤치마크를 해본 사람이라면 안다.
숫자는 항상 조금씩 흔들린다.

같은 테스트를 두 번 실행해도 시간이 달라진다. CPU 상태, 캐시, 백그라운드 프로세스, 네트워크, 파일 시스템 상태에 따라 결과가 바뀐다.

그래서 자동 실험 루프에서 가장 위험한 순간은 이것이다.

에이전트가 우연한 숫자 개선을 진짜 개선으로 착각하는 순간.

pi-autoresearch는 이 문제를 어느 정도 의식하고 있다. 코드에는 confidence 계산 흐름이 들어 있고, 현재 실험 세그먼트 안에서 baseline 대비 개선이 얼마나 의미 있는지 보려는 장치가 있다.

이 부분이 인상적이었다.

완벽한 통계 검증이라고 말하기는 어렵다. 하지만 적어도 이 프로젝트는 “숫자가 좋아졌으니 무조건 성공”이라고 단순하게 접근하지 않는다. 벤치마크 노이즈를 문제로 인식하고, 루프 안에서 다루려 한다.

자동화 도구에서 이런 태도는 꽤 중요하다.

AI 에이전트는 자신감 있게 틀릴 수 있다.
자동 실험 루프는 그 자신감을 숫자로 검증해야 한다.
하지만 숫자도 흔들린다.

결국 좋은 자동 실험 도구는 코드만 잘 바꾸는 도구가 아니라, 측정의 불확실성까지 관리하는 도구여야 한다.

상태 파일이 곧 기억이다

이 저장소에서 가장 마음에 들었던 부분은 상태 관리 방식이다.

autoresearch.jsonl은 기계가 읽기 좋은 로그다. 실험마다 지표, 상태, 커밋, 설명이 한 줄씩 쌓인다.

autoresearch.md는 사람이 읽기 좋은 문서다. 목표, 제약, 전략, 실패한 아이디어, 다음에 시도할 방향을 적는다.

둘은 역할이 다르다.

JSONL은 정확하고 반복 가능하다.
Markdown은 맥락을 전달한다.

이 조합이 좋다. AI 에이전트의 작업은 기계적인 실행과 사람의 판단 사이 어딘가에 있다. 그래서 둘 중 하나만 있으면 부족하다.

JSONL만 있으면 사람이 읽기 어렵다.
Markdown만 있으면 에이전트가 안정적으로 재개하기 어렵다.

pi-autoresearch는 이 둘을 함께 쓴다.

이 방식은 앞으로 다른 에이전트 워크플로에서도 꽤 자주 보게 될 것 같다. 긴 작업을 하려면 대화 기록보다 파일 기반 상태가 더 안정적이기 때문이다.

실패한 실험도 버리지 않는다

자동화 루프에서 흔히 놓치는 것이 있다.

실패한 실험도 정보라는 점이다.

어떤 변경은 성능을 떨어뜨린다. 어떤 변경은 테스트를 깨뜨린다. 어떤 변경은 아예 빌드가 되지 않는다. 이 경우 코드는 되돌리는 게 맞다.

하지만 그 실패에서 얻은 정보까지 버리면, 에이전트는 같은 실수를 반복할 수 있다.

pi-autoresearch는 실패한 실험을 단순히 지우지 않는다. 코드 변경은 revert하더라도, 실패 이유와 다음 힌트는 로그에 남기도록 유도한다.

이 부분은 작지만 중요하다.

사람 연구자도 실험 노트를 쓴다. 실패한 실험을 기록해야 다음에 같은 길로 가지 않는다. AI 에이전트도 마찬가지다. 자동 실험 루프가 정말 연구처럼 작동하려면, 성공보다 실패 기록이 더 중요할 때도 있다.

이 저장소가 “autoresearch”라는 이름을 가진 이유도 여기서 이해된다.
단순한 자동 최적화가 아니라, 작은 연구 루프에 가깝다.

가장 중요한 차별점은 finalize다

많은 자동화 도구는 결과가 나오는 순간 끝난다.

“성능이 10% 좋아졌습니다.”
“테스트 시간이 줄었습니다.”
“커밋이 만들어졌습니다.”

하지만 실제 개발팀에서는 그다음이 더 어렵다.

자동 실험 브랜치에는 여러 시도가 섞인다. 어떤 커밋은 성공했고, 어떤 커밋은 실패했으며, 어떤 변경은 서로 다른 아이디어가 같은 파일을 건드렸을 수 있다.

이 상태 그대로 PR을 만들면 리뷰어는 힘들다.

pi-autoresearch가 흥미로운 이유는 여기서 한 걸음 더 간다는 점이다.
autoresearch-finalize 단계는 성공한 실험만 추려서, 논리적으로 독립된 브랜치로 다시 나누는 역할을 한다.

즉 이런 흐름이다.

자동 실험 브랜치
  ├─ 실험 1 성공
  ├─ 실험 2 실패
  ├─ 실험 3 성공
  ├─ 실험 4 중단
  └─ 실험 5 성공

finalize 이후
  ├─ 리뷰 브랜치 A
  ├─ 리뷰 브랜치 B
  └─ 리뷰 브랜치 C

이 단계가 없으면 자동 실험은 그저 “에이전트가 많이 건드린 브랜치”가 되기 쉽다.

하지만 finalize가 있으면 이야기가 달라진다.

AI가 실험을 많이 하더라도, 마지막에는 사람이 이해할 수 있는 단위로 나눌 수 있다. 이건 실제 팀 워크플로에서 매우 중요하다.

결국 자동화의 끝은 자동화가 아니다.
사람이 리뷰할 수 있는 형태로 돌아오는 것이다.

예제는 작을수록 좋다

이 저장소를 처음 소개할 때는 거창한 예제보다 작은 예제가 좋다. 핵심은 자동 실험 루프의 감각을 전달하는 것이다.

예를 들어 테스트 시간을 줄이는 작업을 생각해보자.

#!/usr/bin/env bash
set -euo pipefail

START=$(date +%s%3N)
npm test
END=$(date +%s%3N)

DURATION=$((END - START))
echo "METRIC test_ms=${DURATION}"

이 스크립트는 단순하지만 좋은 예제다.

실행 가능하다.
성공과 실패가 exit code로 드러난다.
마지막에 숫자 지표를 출력한다.

여기에 correctness check를 분리하면 더 실전적이다.

#!/usr/bin/env bash
set -euo pipefail

npm run typecheck
npm run lint

성능만 좋아지고 타입 검사나 린트가 깨지는 변경은 좋은 변경이 아니다. 자동 실험 루프를 돌릴 때는 반드시 “숫자 개선”과 “정상 동작”을 분리해서 봐야 한다.

이런 예제는 작지만, 이 저장소의 핵심을 잘 보여준다.

자동 실험을 하려면 먼저 좋은 측정 스크립트가 있어야 한다.
측정이 흔들리면 에이전트도 흔들린다.

어디에 잘 맞을까

pi-autoresearch는 모든 프로젝트에 잘 맞는 도구는 아니다.

잘 맞는 프로젝트는 조건이 분명하다.

측정할 지표가 있어야 한다.
벤치마크가 너무 오래 걸리면 안 된다.
결과가 어느 정도 안정적이어야 한다.
실험 브랜치를 따로 둘 수 있어야 한다.
자동 커밋과 revert를 받아들일 수 있어야 한다.

이 조건이 맞으면 꽤 흥미로운 도구가 된다.

예를 들어 이런 작업에는 잘 어울린다.

테스트 시간을 줄이는 작업.
번들 크기를 줄이는 작업.
빌드 시간을 줄이는 작업.
쿼리 성능을 개선하는 작업.
Lighthouse 점수를 올리는 작업.
모델 학습 손실처럼 숫자로 확인 가능한 작업.

반대로 이런 경우에는 조심해야 한다.

지표가 자주 흔들리는 프로젝트.
정성적 판단이 중요한 UI 작업.
여러 사람이 동시에 main 브랜치에서 작업하는 팀.
규제나 감사 때문에 자동 커밋이 부담스러운 환경.
테스트가 빈약해서 성능 개선이 기능 손상으로 이어질 수 있는 코드베이스.

이 도구를 도입하기 전에 먼저 물어야 할 질문은 “AI가 얼마나 똑똑한가”가 아니다.

내 프로젝트는 좋은 실험 지표를 갖고 있는가?

이 질문이 먼저다.

성숙도는 어떻게 봐야 할까

이 저장소는 빠르게 성장하는 프로젝트처럼 보인다. 관심도도 높고, 관련 포트와 분석 글도 나오고 있다.

하지만 블로그에서 별 개수나 포크 수 같은 숫자를 전면에 내세우는 것은 조심하는 편이 좋다. GitHub 지표는 빠르게 바뀌고, 외부 인덱스마다 값이 다르게 보일 수 있다.

성숙도를 볼 때는 숫자보다 다음 질문이 더 중요하다.

상태 파일 구조가 명확한가.
실패한 실험을 복구할 수 있는가.
성공한 변경을 리뷰 가능한 단위로 나눌 수 있는가.
측정 노이즈를 어느 정도 고려하는가.
특정 런타임에 너무 강하게 묶여 있지는 않은가.
테스트가 핵심 경로를 충분히 덮고 있는가.

이 기준으로 보면 pi-autoresearch는 방향성이 분명한 프로젝트다. 특히 파일 기반 상태 지속과 finalize 단계는 강점이다.

다만 아직 완성형 제품이라기보다는 빠르게 움직이는 실험적 확장 기능에 가깝다. Pi 런타임에 의존하고, 실제 팀 환경에서 얼마나 매끄럽게 작동할지는 각 프로젝트의 벤치마크 품질과 Git 운영 방식에 크게 좌우된다.

즉 “지금 당장 모든 팀이 써야 할 도구”라기보다는, AI 에이전트가 장기 실험을 어떻게 수행할 수 있는지 보여주는 좋은 관찰 대상에 가깝다.

비슷한 흐름과 비교하면

이 프로젝트를 이해하려면 Karpathy의 autoresearch 같은 흐름과 함께 보는 것이 좋다.

원형에 가까운 autoresearch가 작은 연구 실험 루프를 보여줬다면, pi-autoresearch는 그 아이디어를 일반 개발 작업으로 넓히려는 시도에 가깝다.

단순히 모델 학습 손실을 줄이는 것이 아니라, 테스트 시간, 번들 크기, 빌드 속도, 웹 성능 점수처럼 개발 현장에서 자주 만나는 지표로 확장한다.

또 다른 포트들이 Claude Code 같은 다른 에이전트 환경으로 같은 패턴을 옮기는 것도 흥미롭다. 이것은 이 아이디어가 특정 도구 하나의 기능이라기보다, 앞으로 여러 에이전트 런타임에서 반복될 수 있는 작업 패턴이라는 뜻이기도 하다.

핵심은 플랫폼이 아니다.

핵심은 패턴이다.

측정 가능한 목표를 준다
→ 에이전트가 작은 실험을 반복한다
→ 결과를 파일에 남긴다
→ 실패는 되돌린다
→ 성공은 리뷰 가능한 형태로 회수한다

이 패턴이 앞으로 꽤 중요해질 가능성이 있다.

내가 이 저장소에서 배운 것

이 저장소를 읽고 나서 가장 크게 남은 생각은 이것이다.

AI 에이전트의 실무 활용은 “얼마나 똑똑하게 코드를 쓰는가”만의 문제가 아니다.

오히려 더 중요한 것은 주변 구조다.

어떻게 지시할 것인가.
어떻게 측정할 것인가.
어떻게 실패를 기억할 것인가.
어떻게 되돌릴 것인가.
어떻게 사람이 리뷰할 수 있게 만들 것인가.

pi-autoresearch는 이 질문들에 대해 꽤 구체적인 답을 내놓는다.

JSONL로 실험을 기록한다.
Markdown으로 맥락을 남긴다.
Bash 스크립트로 측정을 고정한다.
Git으로 keep과 revert를 관리한다.
finalize로 리뷰 가능한 브랜치를 만든다.

이 구성은 화려하지 않지만 현실적이다.
그리고 바로 그 점이 좋다.

AI 에이전트는 언젠가 더 똑똑해질 것이다. 하지만 아무리 똑똑해져도 긴 작업에는 기록과 복구와 검증이 필요하다. pi-autoresearch는 그 당연한 사실을 저장소 구조로 보여준다.

결론

pi-autoresearch를 “AI가 알아서 성능을 올려주는 도구”라고 소개하면 조금 과장된 느낌이 있다.

더 정확히 말하면 이렇다.

pi-autoresearch는 AI 에이전트가 측정 가능한 실험을 반복하고, 그 결과를 파일로 기억하고, 성공한 변경을 사람이 리뷰할 수 있는 브랜치로 회수하게 만드는 워크플로 저장소다.

이 프로젝트의 진짜 가치는 자동화 그 자체가 아니다.
자동화된 실험을 다시 인간의 개발 흐름으로 되돌리는 구조에 있다.

에이전트가 코드를 바꿀 수 있다는 건 이제 새롭지 않다.
앞으로 더 중요한 질문은 이것이다.

에이전트가 바꾼 코드를 우리는 어떻게 믿고, 어떻게 이해하고, 어떻게 병합할 것인가?

pi-autoresearch는 이 질문에 대한 꽤 흥미로운 답안지다.

완성형 제품이라기보다, 앞으로 에이전트 기반 개발 워크플로가 어떤 방향으로 갈 수 있는지 보여주는 사례에 가깝다. 자동 실험 루프를 이해하고 싶다면 README만 읽고 끝내기보다, index.ts, 세션 파일, 그리고 finalize.sh까지 함께 읽어보는 편이 훨씬 좋다.

AI가 밤새 실험하는 시대가 온다면, 아침에 우리가 보고 싶은 것은 수십 개의 뒤섞인 커밋이 아니다.

우리가 보고 싶은 것은 설명 가능한 변화, 검증 가능한 숫자, 그리고 리뷰 가능한 브랜치다.

pi-autoresearch는 바로 그 지점을 향해 있다.

 

참고 자료

반응형
저작자표시 비영리 변경금지 (새창열림)

'최신IT 정보 > IT 개발정보' 카테고리의 다른 글

데이터베이스는 정답이 아니라 타이밍이다. DB Pro 벤치마크 글 번역  (0) 2026.04.18
Codex CLI 실행 오류 해결 방법 총정리  (0) 2026.04.18
26.4.14일 기준, pgmicro는 PostgreSQL의 경량 대안일까?  (0) 2026.04.14

관련글

티스토리툴바