오래된 연구 아이디어에 Autoresearch 수행하기

2021년에 적어둔 메모가 아직도 노트 앱에 남아 있다

지난주 제 노트 앱에서 “나중에 연구해볼 것”이라는 제목의 메모를 열었더니, 아이디어가 37개 있었습니다. 그중 24개는 지금 읽어도 나쁘지 않았고, 9개는 이미 다른 사람이 제품으로 만들었습니다. 문제는 나머지였습니다. 버리기엔 아깝고, 다시 붙잡기엔 시간이 무서운 아이디어들.

오래된 연구 아이디어는 종종 부채처럼 남습니다. 머릿속에서는 아직 가치가 있는 것 같은데, 막상 꺼내면 어디서부터 검증해야 할지 흐릿합니다. 저는 Autoresearch를 여기서 써야 한다고 봅니다. 새 아이디어를 더 만드는 도구가 아니라, 묵은 아이디어를 살릴지 버릴지 판단하는 자동 실험실로요.

다들 “아이디어를 더 찾아야 한다”고 말하지만, 실제 병목은 검증입니다

비개발자 직장인에게 연구 아이디어는 대개 문장으로 남습니다. “이런 자동화가 되면 좋겠다.” “이 데이터를 묶으면 패턴이 보이지 않을까.” “업무 로그로 다음 액션을 추천할 수 없을까.” 문장은 쉽습니다. 실험은 어렵습니다.

저도 예전에는 좋은 아이디어를 더 많이 모으면 언젠가 하나가 열릴 줄 알았습니다. 그런데 3년쯤 지나 보니, 아이디어 목록은 길어졌고 실행력은 그대로였습니다. 이유는 단순했습니다. 아이디어가 부족한 게 아니라, 아이디어를 작은 실험으로 바꾸는 장치가 없었습니다.

Autoresearch가 흥미로운 지점은 여기입니다. LLM 에이전트가 `train.py` 같은 학습 코드를 반복 수정하고, 성능 지표를 보며 다음 수정을 시도합니다. 사람은 큰 방향과 제약을 주고, 에이전트는 후보 실험을 계속 굴립니다. 이 방식이 모든 연구를 대신하지는 않습니다. 하지만 “이 아이디어가 최소한 움직이는가”를 확인하는 비용은 낮춥니다.

회사 일로 비유하면 이렇습니다. 오래된 아이디어를 팀장 머릿속 회의 안건으로 두지 않고, 신입에게 “오늘 안에 표 하나 만들어 와. 기준은 정확도, 비용, 재현성 세 가지야”라고 시키는 것과 비슷합니다. 완성품을 기대하는 게 아닙니다. 다음 회의에서 계속 이야기할 자격이 있는지 확인하는 겁니다.

Autoresearch의 쓸모는 천재성보다 반복성에 있습니다

제 주장은 분명합니다. Autoresearch는 연구자를 대체하는 발명 기계가 아니라, 오래된 아이디어를 반복 가능한 검증 단위로 쪼개는 운영 도구입니다. 누군가는 “그 정도면 자동화된 하이퍼파라미터 튜닝 아니냐”고 말할 수 있습니다. 저는 절반만 동의합니다. 차이는 수정 대상이 숫자 몇 개에 그치지 않는다는 점입니다.

일반적인 튜닝은 러닝레이트, 배치 크기, 레이어 수처럼 정해진 손잡이를 돌립니다. Autoresearch는 더 거칠게 움직입니다. 손실 함수 일부를 바꾸고, 데이터 전처리 방식을 바꾸고, 모델 구조를 고치고, 실험 로그를 읽고 다음 코드를 제안합니다. 성능이 떨어지면 되돌리거나 다른 방향을 잡습니다. 핵심은 “좋은 연구 감각”이 아니라 “실패를 기록하며 다음 시도를 고르는 루프”입니다.

여기서 중요한 숫자는 거창한 벤치마크가 아닙니다. 이번 manifest에는 별도 출처가 없습니다. 그래서 특정 논문 성능이나 외부 사례 이름을 끌어오지 않겠습니다. 대신 우리가 실제로 확인해야 할 숫자는 더 작고 차갑습니다.

오래된 아이디어	Autoresearch에 맡길 질문	사람이 봐야 할 숫자
회의록에서 다음 할 일을 자동 추출	지시문가 아니라 학습 데이터와 평가 기준을 바꿔도 좋아지는가	F1, 누락률, 오탐률
고객 문의를 난이도별로 분류	기존 규칙 기반 분류보다 일관되게 나은가	정확도, 재검토 건수, 처리 시간
사내 문서에서 답변 생성	검색 범위와 chunk 전략을 바꾸면 환각이 줄어드는가	근거 포함률, 답변 거부율, 검수 통과율
개인 업무 로그로 다음 액션 추천	추천이 실제 행동으로 이어지는가	클릭률보다 완료율, 재사용률

제가 보기에 Autoresearch를 잘 쓰는 사람은 “이 모델이 똑똑해졌나”보다 “이 아이디어가 더 이상 내 시간을 먹을 자격이 있나”를 묻습니다. 이 질문이 실무적입니다. 오래된 아이디어는 감정이 붙어 있어서 버리기 어렵습니다. 자동 실험 로그는 그 감정을 조금 떼어냅니다.

물론 실패담도 있습니다. 저는 예전에 개인 지식관리 자동화를 실험하면서 “내 노트에서 다음 글감을 추천해주는 시스템”을 만들려고 했습니다. 처음에는 그럴듯했습니다. 노트 제목, 태그, 작성일을 넣으면 추천 문장이 나왔습니다. 그런데 2주 뒤 보니 추천이 죄다 비슷했습니다. “AI와 일하는 방식”, “개인 자동화”, “미래 업무” 같은 말만 반복했습니다. 데이터가 얇았고, 평가 기준도 허술했습니다. Autoresearch를 붙였어도 이 문제를 그냥 해결하지 못했을 겁니다. 먼저 해야 할 일은 모델 수정이 아니라, “좋은 추천”의 기준을 사람이 다시 쓰는 일이었습니다.

그래서 저는 Autoresearch를 이렇게 씁니다. 오래된 아이디어를 바로 제품으로 밀지 않습니다. 먼저 아이디어를 실험 문장으로 바꿉니다. 예를 들면 “내 업무 로그에서 내일 할 일을 맞힌다”가 아니라, “지난 30일 업무 로그를 보고 다음 날 실제 완료한 작업 3개 중 1개 이상을 맞힌다”로 바꿉니다. 이 정도로 좁혀야 에이전트가 코드를 고치든 데이터를 바꾸든 방향이 생깁니다.

복붙용으로 남기면 이 한 줄입니다.

> 이 아이디어는 멋진가가 아니라, 24시간 안에 측정 가능한 실패를 만들 수 있는가?

이 문장이 Autoresearch의 출발점입니다. 성공을 묻기 전에 실패를 설계해야 합니다. 실패가 선명하면 반복이 빨라지고, 반복이 빨라지면 오래된 아이디어의 생사가 드러납니다.

자동 연구가 안 통하는 아이디어도 있습니다

Autoresearch를 붙이면 오히려 시간이 낭비되는 아이디어가 있습니다. 평가 지표가 없는 아이디어입니다. 예를 들어 “사용자가 더 만족하는 글쓰기 도구” 같은 문장은 너무 넓습니다. 만족을 어떤 행동으로 볼지, 비교 기준을 무엇으로 둘지, 실패를 어디서 끊을지 정하지 않으면 에이전트는 코드만 바쁘게 고칩니다.

데이터가 너무 적어도 어렵습니다. 12개의 예시로 성능 개선을 주장하면, 그건 연구라기보다 운에 가깝습니다. 민감한 개인정보가 들어간 업무 데이터도 조심해야 합니다. 자동 실험을 돌리기 전에 익명화, 보관 기간, 접근 권한을 먼저 정해야 합니다. 비개발자 직장인에게는 이 부분이 특히 중요합니다. “내 파일을 넣어봤더니 잘 되더라”는 말이 나중에 회사 규정 위반으로 돌아올 수 있습니다.

그리고 사람의 판단이 핵심인 아이디어가 있습니다. 고객의 미묘한 불만을 해석하거나, 조직 정치가 얽힌 의사결정을 예측하는 일은 숫자 하나로 닫기 어렵습니다. 이런 일에는 Autoresearch를 판사처럼 쓰면 안 됩니다. 보조 메모 담당자 정도가 맞습니다.

오늘 할 일은 아이디어를 하나 줄이는 것입니다

오늘 할 일은 새 도구를 설치하는 게 아닙니다. 오래된 아이디어 하나를 꺼내서 아래 네 줄로 바꾸는 겁니다.

① 이 아이디어가 맞다면 어떤 숫자가 좋아져야 하는가 ② 24시간 안에 만들 수 있는 가장 작은 실험은 무엇인가 ③ 실패 기준은 무엇인가 ④ 사람이 직접 판단해야 할 부분은 어디인가

이 네 줄을 채우지 못하면, 그 아이디어는 아직 Autoresearch에 넣을 준비가 안 된 겁니다. 반대로 네 줄이 채워지면 오래된 메모는 다시 움직일 수 있습니다. 저는 이 방식이 미래 대비에 꽤 현실적인 태도라고 생각합니다. 큰 기술을 기다리는 대신, 내 아이디어를 작은 시스템으로 계속 검증하는 일. 자동화는 거기서 시간을 되찾습니다.

다음 편에서는 이 네 줄짜리 메모를 실제 Autoresearch용 실험 요청서로 바꾸는 법을 다루겠습니다. 오늘은 노트 앱에서 오래된 아이디어 하나만 골라 위 체크리스트에 맞춰 줄여보세요.