AI 에이전트와 연구 자동화

연구 에이전트의 구조

왜 필요한가. "이 반응의 수율을 올릴 첨가제를 찾아라" 같은 요청 하나를 받은 에이전트는 문헌을 몇 편 읽을지, 가설을 몇 개 만들지, 그중 무엇을 시험할지, 시뮬레이션이 실패하면 어떻게 할지를 스스로 정한다. 최종 보고만 받으면 그 결정들은 보이지 않는다. 결론이 틀렸을 때 어느 단계에서 틀렸는지 찾을 수 없고, 맞았을 때도 왜 믿어도 되는지 말할 수 없다.

정의. 에이전트는 언어모델이 다음 행동을 고르고(계획), 도구를 호출하고(실행), 그 결과를 읽고(관찰), 다시 다음 행동을 고르는 반복이다. 18.5장의 tool use가 한 번의 도구 호출이라면, 에이전트는 그 호출을 여러 단계에 걸쳐 스스로 이어 간다. 연구 에이전트는 이 반복을 연구의 단계에 걸쳐 놓는다.

직관. 25.4장의 closed-loop와 같은 모양이지만, 결정을 내리는 부분이 다르다. closed-loop의 획득함수는 식으로 적혀 있어서 같은 데이터와 seed면 같은 실험을 고르고, 무엇을 최적화하는지가 분명하다. 에이전트의 결정은 자연어 요청을 언어모델이 해석한 결과다. 같은 요청에서도 다른 계획이 나올 수 있고, 목표 자체가 실행 중에 다르게 해석될 수 있다. "모든 후보를 계산하라"가 시간 초과를 몇 번 겪은 뒤 "계산이 끝난 후보를 정리하라"로 바뀌어도, 에이전트는 그것을 보고하지 않을 수 있다.

연구에서의 의미. 그래서 구조 설계의 핵심은 단계마다 사람이나 별도 검사가 확인할 수 있는 중간 산출물을 정하는 것이다. 작업 요청에는 질문, 완료 기준(무엇이 끝나면 끝인가), 범위(어떤 후보·조건을 모두 다뤄야 하는가), 하지 말 것(테스트·평가 데이터·원본 데이터를 바꾸지 않는다)을 쓴다. 4.6장의 작업 흐름 표가 코딩 작업에 대해 한 것을 연구 단계 전체로 넓힌 것이다.

가설 생성 단계에는 특유의 함정이 있다. 에이전트는 가설을 수십 개 만들 수 있다. 그중 시험 결과가 좋은 것만 보고하면 4.6장의 test set 선택 편향과 같은 문제가 가설 수준에서 생긴다. 생성한 가설 전체와 시험한 순서, 시험하지 않은 이유를 기록해 결과의 분모를 남긴다. 가설마다 시험 전에 예측하는 결과를 적게 하는 것도 23.4장의 원칙 그대로다. 문헌 단계와 가설 단계를 잇는 점검도 있다. 에이전트가 "새롭다"고 제시한 가설이 이미 발표된 결과인지는 문헌 목록으로 따로 확인한다. 가설 생성·실험 설계·데이터 해석의 각 단계에서 AI가 쓰이는 방식은 Wang 외(2023)의 리뷰가 분야를 가로질러 개관한다.

도구와 실행 권한

왜 필요한가. 도구 하나를 연결할 때마다 에이전트가 할 수 있는 일이 늘어난다. 논문 검색 도구는 외부 텍스트를 읽게 하고, 그 텍스트에는 모델을 향한 지시가 숨어 있을 수 있다(4.5장의 prompt injection). 코드 실행 도구는 파일을 지우게 할 수 있고, 계산 작업 제출 도구는 공용 클러스터의 예산을 쓰게 하고, 장비 제어 도구는 시약과 시료를 소비하게 한다. 에이전트가 오해하거나 속았을 때 무엇이 가능한지가 권한 설계의 기준이다.

원칙: 지침이 아니라 권한으로 막는다. 작업 지침에 "공용 데이터베이스에 쓰지 마라"라고 적는 것은 행동을 유도할 뿐이다. 막아야 하는 행동은 그 행동을 할 수 없는 환경으로 막는다. 세 가지 수단을 함께 쓴다.

• sandbox: 코드는 격리된 실행 환경(컨테이너 등, 3.5장)에서 돌린다. 마운트한 디렉터리만 보이고, 원본 데이터는 읽기 전용이며, 네트워크는 필요한 주소만 열고, 실행 시간과 메모리에 상한을 둔다.
• 최소 권한(least privilege): 도구마다 그 단계에 필요한 권한만 준다. 검색 도구는 읽기만, 데이터베이스 계정은 읽기 전용, 저장소 토큰은 작업 branch에만 push할 수 있게 한다.
• 사람의 승인 지점: 되돌릴 수 없거나 비용이 큰 행동 앞에서는 에이전트가 제안하고 사람이 승인한다.

연구 도구별로 정리하면 다음과 같다.

승인 지점의 설계. 승인을 어디에 두는지는 4.6장의 기준(되돌리기 어렵거나, 비용이 크거나, 결론을 정하는 곳)을 따른다. 연구 자동화에서 더할 것은 범위로 미리 승인하기다. 실험 장비나 계산 작업마다 승인을 받으면 승인이 수백 번이 되어 형식이 된다. 대신 "온도 20–80 °C, 시약 A 총 50 mL 이하, 작업 20개 이하" 같은 범위를 사람이 먼저 승인하고, 에이전트는 그 안에서 자유롭게 고르게 한다. 범위는 에이전트가 아니라 제어기와 작업 대기열이 강제한다. 범위 밖의 요청은 무엇을 왜 하려는지, 예상 비용이 얼마인지를 담아 승인을 요청하게 하고, 승인과 거절도 기록에 남긴다.

결과 검증

왜 필요한가. 에이전트의 보고는 "테스트 통과", "시뮬레이션으로 확인", "문헌과 일치"처럼 이미 검증을 거친 것처럼 쓰인다. 그러나 그 검증을 수행한 것도 같은 에이전트다. 에이전트가 만든 코드를 에이전트가 만든 테스트로 확인하면, 둘은 같은 가정을 공유한다. 공식을 잘못 이해했다면 코드와 테스트가 함께 틀린다. 그리고 테스트가 실패할 때 에이전트는 코드 대신 테스트를 고칠 수 있다(4.3장).

네 겹의 검증. 에이전트에게서 독립적인 정도가 클수록 강한 검증이다.

1. 재실행: 기록된 코드와 데이터로 깨끗한 환경에서 사람이나 CI가 다시 실행해 같은 숫자가 나오는지 본다. 결과가 정말 그 코드에서 나왔는지를 확인한다. 맞는지는 확인하지 않는다.
2. 독립 평가: 에이전트의 코드와 다른 경로로 같은 양을 계산한다. 해석해, 다른 프로그램, 손 계산, 이미 검증된 기존 코드가 그 경로다.
3. held-out 평가: 에이전트가 한 번도 보지 못한 사례로 평가한다. 대표적인 것이 참값을 아는 사례에 같은 절차를 적용해 보는 양성 대조(positive control)다. held-out 사례와 그 참값은 에이전트의 작업 환경과 권한 밖에 두고, 코드와 절차를 고정한 뒤에 평가한다.
4. 인용 대조: 문헌 단계의 모든 인용은 서지가 실재하는지, 붙은 주장이 원문에 있는지를 확인한다(아래).

아래 셀은 기대값을 고쳐 통과한 테스트를 held-out 양성 대조가 잡아내는 과정을 보인다. 과제는 시뮬레이션한 입자 궤적의 평균제곱변위(mean squared displacement, MSD)에서 확산 계수 $D$를 추정하는 것이다. $d$차원 브라운 운동에서 MSD는 시간에 비례한다.

$\mathbf{r}(t)$는 시각 $t$의 입자 위치, $\langle \cdot \rangle$은 입자들에 대한 평균, $d$는 공간 차원이다. 3차원이면 MSD 기울기를 $2d = 6$으로 나눠야 $D$가 된다. "에이전트"의 코드는 1차원 공식을 써서 2로 나눈다. 에이전트가 쓴 테스트는 처음에 실패하고, 에이전트는 코드 대신 기대값을 고친다.

import numpy as np

dt_s, n_steps = 1e-3, 200                              # 시간 간격 1 ms, 200 step
def simulate_msd(D_m2_s, seed, n_particles=400):       # 3차원 브라운 운동의 평균제곱변위(MSD)
    rng = np.random.default_rng(seed)
    steps_m = rng.normal(scale=np.sqrt(2 * D_m2_s * dt_s), size=(n_particles, n_steps, 3))
    pos_m = np.cumsum(steps_m, axis=1)                 # (N, T, 3)
    t_s = dt_s * np.arange(1, n_steps + 1)             # (T,)
    return t_s, (pos_m ** 2).sum(-1).mean(0)           # (T,), (T,) MSD [m²]

def estimate_D(t_s, msd_m2, factor):                   # d차원에서 MSD = 2d·D·t → 기울기를 2d로 나눈다
    return np.polyfit(t_s, msd_m2, 1)[0] / factor

agent_factor = 2                                       # 에이전트 코드의 버그: 1차원 공식(MSD = 2Dt)을 썼다
test = {"D_m2_s": 1.0e-9, "seed": 0, "expected": 1.0e-9, "rtol": 0.10}   # 에이전트가 쓴 테스트
for attempt in range(3):
    D_est = estimate_D(*simulate_msd(test["D_m2_s"], test["seed"]), agent_factor)
    passed = abs(D_est - test["expected"]) <= test["rtol"] * test["expected"]
    print(f"시도 {attempt}: 추정 D {D_est:.3e} m²/s, 기대값 {test['expected']:.3e} → {'통과' if passed else '실패'}")
    if passed:
        break
    test["expected"] = D_est                           # 코드 대신 기대값을 고친다

held_out = [(0.5e-9, 101), (2.0e-9, 102), (5.0e-9, 103)]   # 평가자만 가진 양성 대조(참값을 아는 사례)
for name, factor in [("에이전트 코드", agent_factor), ("고친 코드(÷6)", 6)]:
    ratios = [estimate_D(*simulate_msd(D, s), factor) / D for D, s in held_out]
    print(f"held-out {name}: 추정/참값 = " + ", ".join(f"{r:.2f}" for r in ratios))

시도 0: 추정 D 3.202e-09 m²/s, 기대값 1.000e-09 → 실패
시도 1: 추정 D 3.202e-09 m²/s, 기대값 3.202e-09 → 통과
held-out 에이전트 코드: 추정/참값 = 2.90, 3.06, 3.14
held-out 고친 코드(÷6): 추정/참값 = 0.97, 1.02, 1.05

두 번째 시도의 "통과"는 코드가 seed 0에서 자기 출력을 다시 낸다는 것만 확인한다. 기대값이 코드의 출력으로 바뀌었기 때문이다. 에이전트의 보고에는 "테스트 통과"만 남는다. 참값을 아는 held-out 사례 세 개에서는 추정값이 참값의 약 3배로 일관되게 나와, 계수가 틀렸다는 것($6/2 = 3$)까지 드러난다. 같은 사례에서 고친 코드의 비는 0.97–1.05다. seed만 바꿔 같은 추정을 반복하면 이 비의 표준편차가 약 0.05이므로, 이 정도의 차이는 입자 400개의 통계적 변동이다. 고친 코드는 원래 테스트(기대값 $1.0 \times 10^{-9}$, 허용 오차 10%)도 통과한다($3.202/3 \approx 1.067$). held-out 사례의 참값은 에이전트의 코드와 무관한 시뮬레이션 입력값이므로, 에이전트가 같은 오해를 했더라도 그 값은 오염되지 않는다. 이 장치가 작동하려면 두 조건이 필요하다. 에이전트가 held-out 사례를 볼 수 없어야 하고, 테스트 파일의 변경이 diff와 기록에서 보여야 한다.

평가 데이터의 누출. held-out 평가는 에이전트가 그 데이터에 닿지 못할 때만 held-out이다. 평가 파일을 작업 디렉터리에 두거나, 작업 지침에 정답 예시를 적거나, 에이전트가 웹 검색으로 공개 benchmark의 정답을 찾을 수 있으면, 에이전트는 의도 없이도 그 값에 맞춘다. 4.6장의 test set 선택 편향, 15.4장의 누수와 같은 문제이고, Kapoor와 Narayanan(2023)이 정리한 과학 분야 ML 연구의 누수 유형에 에이전트라는 새 경로가 더해진 것이다. 평가 데이터는 에이전트의 sandbox 밖에 두고, 평가 실행은 기록을 남긴다.

인용 대조. 문헌 종합 단계의 인용은 두 단계로 확인한다. 첫째, 서지가 실재하는지와 저자·연도·제목이 맞는지. 둘째, 초안이 그 인용에 붙인 주장이 원문에 실제로 있는지, 조건(온도 범위, 세포 실험, 표본 크기)까지 맞는지. 첫째는 자동화할 수 있다. 아래 셀은 에이전트 초안의 인용을 원문을 확인한 로컬 서지 목록과 DOI로 대조한다. 이 책의 data/references.bib처럼, 사람이 원문을 확인한 항목만 담은 목록이 기준이다.

verified = {                                           # DOI → (제1저자, 연도). 원문을 확인한 서지만 담는다(data/references.bib 발췌)
    "10.1016/j.patter.2023.100804": ("Kapoor", 2023),
    "10.1038/s41586-023-06221-2": ("Wang", 2023),
}
draft_refs = [                                         # 에이전트가 초안에 넣은 인용
    {"doi": "10.1016/j.patter.2023.100804", "author": "Kapoor", "year": 2023,
     "claim": "누수가 17개 분야 294편 이상의 논문에 영향을 주었다"},
    {"doi": "10.1038/s41586-023-06221-2", "author": "Wang", "year": 2021,
     "claim": "AI가 가설 생성 단계에 쓰이는 방식을 개관했다"},
    {"doi": None, "author": "Lee", "year": 2024,         # 예시용으로 지어낸 서지
     "claim": "에이전트가 만든 가설의 80%가 실험에서 확인되었다"},
]
for ref in draft_refs:
    rec = verified.get(ref["doi"])
    if rec is None:
        status = "로컬 목록에 없음 → 존재부터 확인"
    elif rec != (ref["author"], ref["year"]):
        status = f"서지 불일치(목록: {rec[0]} {rec[1]}) → 원문 확인"
    else:
        status = "서지 일치 → 주장이 원문에 있는지 대조"
    print(f"{ref['author']} ({ref['year']}): {status}\n    주장: {ref['claim']}")

Kapoor (2023): 서지 일치 → 주장이 원문에 있는지 대조
    주장: 누수가 17개 분야 294편 이상의 논문에 영향을 주었다
Wang (2021): 서지 불일치(목록: Wang 2023) → 원문 확인
    주장: AI가 가설 생성 단계에 쓰이는 방식을 개관했다
Lee (2024): 로컬 목록에 없음 → 존재부터 확인
    주장: 에이전트가 만든 가설의 80%가 실험에서 확인되었다

세 인용 모두 사람의 일이 남는다. 목록에 없는 인용은 DOI·출판사 페이지·도서관 기록으로 존재부터 확인하고, 찾지 못하면 지운다. 연도가 다른 인용은 실제 논문과 다른 논문의 서지가 섞였을 수 있으므로 원문을 연다. 서지가 일치한 인용도 끝난 것이 아니다. 자동 대조는 "그런 논문이 있다"까지만 말하고, "그 논문이 이 주장을 한다"는 원문을 읽어야 안다. 검색 증강 도구가 실제 문서를 가져온 경우에도 같다. 문서가 실재해도 주장을 뒷받침하는지는 별개다. 원고에 들어가는 모든 인용에 이 절차를 적용한다는 원칙은 18.5장, 23.1장, 부록 G의 논문 점검표, 부록 H의 추천 목록 확인과 같다.

실행 기록과 재현성

왜 필요한가. 에이전트의 결과를 리뷰하려면 에이전트가 무엇을 했는지 알아야 한다. 최종 보고와 결과 표는 에이전트가 만든 산출물이므로, 그것만으로는 보고가 사실인지 확인할 수 없다. 앞 절의 검증도 기록이 있어야 가능하다. 테스트 파일이 언제 바뀌었는지, held-out 평가가 몇 번 실행되었는지, 어떤 시뮬레이션이 실패했는지는 기록에만 있다.

무엇을 남기나. 22.2장의 재현성 원칙(코드·환경·데이터·seed)에 에이전트 고유의 항목이 더해진다.

• 작업 명세: 사람이 준 요청 전문, 작업 지침 파일(4.4장)의 commit, 범위와 완료 기준.
• 모델과 설정: 모델 식별자, 접근 날짜, 디코딩 설정(temperature 등), 지원되면 샘플링 seed. 원격 API의 모델은 같은 이름이어도 시점에 따라 바뀔 수 있으므로 식별자와 날짜를 함께 쓴다.
• 도구 호출 기록(tool trace): 호출마다 도구 이름, 입력 인자, 종료 상태(성공·실패·시간 초과), 출력 또는 출력의 해시, 시각. 실패한 호출도 빠짐없이 남긴다.
• 코드와 seed: 에이전트가 만든 commit, 시뮬레이션과 분석의 seed, 실행 환경.
• 사람의 결정: 승인·거절과 그 이유, 사람이 직접 고친 것.

기록은 한 줄에 한 사건씩 JSON Lines로 남기면 나중에 세고 걸러 보기 좋다. 다음은 형식의 예(집필 시점 예시)다. 필드 이름과 값은 도구마다 다르다.

{"step": 1, "type": "config", "model": "<제공자>/<모델 식별자>", "accessed": "2026-11-08", "temperature": 0.0, "task_spec_commit": "3f2a9c1"}
{"step": 14, "type": "tool_call", "tool": "submit_simulation", "args": {"candidate": "C-017", "seed": 7}, "status": "timeout", "time": "2026-11-08T10:42:05Z"}
{"step": 15, "type": "file_change", "path": "tests/test_diffusion.py", "commit": "8be41d0"}

모델 식별자 자리에는 제공자가 문서에 밝힌 버전 문자열(날짜나 버전 번호가 붙은 것)을 쓰고, 항상 최신 모델을 가리키는 별칭은 쓰지 않는다. 버전 문자열의 형식, 버전을 고정하는 방법, seed 지원 여부는 서비스마다 다르고 자주 바뀌므로 사용하는 서비스의 문서에서 확인한다.

무엇을 재현하나. 언어모델의 출력은 seed와 temperature를 고정해도 서비스 쪽 사정으로 똑같이 재현되지 않을 수 있다. 그래서 재현의 대상은 에이전트의 대화가 아니라 산출물이다. 기록된 commit의 코드를 기록된 데이터와 seed로 다시 실행하면 같은 숫자가 나와야 한다. 25.4장의 replay처럼, 기록된 도구 출력을 넣고 분석 단계만 다시 돌려 같은 결론이 나오는지도 확인할 수 있다. 에이전트의 결정 과정은 재현하는 것이 아니라 기록으로 감사(audit)한다. 위 기록의 step 15처럼 테스트 파일이 바뀐 사건, step 14처럼 시간 초과로 끝난 계산은 보고서에 "50개 모두 계산"이라고 쓰여 있어도 기록에서 셀 수 있다. 사람의 연구 노트(23.7장)가 결과를 보기 전의 예상을 남기듯, 에이전트 기록은 에이전트가 보고하지 않은 것을 남긴다.

참고 문헌

• Wang 외 (2023). Scientific discovery in the age of artificial intelligence. Nature, 620, 47–60. — 가설 생성·실험 설계·데이터 해석에서의 AI 개관
• Kapoor, Narayanan (2023). Leakage and the reproducibility crisis in machine-learning-based science. Patterns, 4(9), 100804. — 과학 분야 머신러닝 연구의 누수 유형