연구 가속이라는 말을 OpenAI 안에서 들여다보기

노시욱 (Patrick Rho) · AI 연구 해설

Simon Willison이 9월 6일에 쓴 글 Research acceleration: The view inside OpenAI를 읽었습니다. 이 글은 OpenAI가 같은 시기에 내놓은 RSI에 관한 글들과 연구팀의 코딩 에이전트 사용법을 정리하면서 2026년의 연구 가속 흐름을 전합니다. 이 글에서 말하는 가속이란 연구자 한 명이 쓰는 AI 연산량이 빠르게 늘고 에이전트 엔지니어링이 일상 작업이 되었다는 뜻입니다. 원문 링크는 제목 아래에 붙어 있습니다.

짧은 정리 글인데 읽는 데 시간이 걸렸습니다. 표면적으로는 OpenAI 내부 소식 전달에 가깝습니다. 그런데 문장 사이마다 질문이 생깁니다. 왜 하필 지금 RSI라는 말이 나왔을까, 에이전트가 연구를 어떻게 바꾸었을까, 지출 그래프의 꺾임은 무엇을 말할까 같은 질문입니다. 제가 이 글에서 가장 흥미롭게 본 부분은 거창한 선언이 아니라 일상과 숫자가 만나는 대목입니다. 연구팀이 매일 쓰는 도구 이야기와 연구자당 지출 곡선 이야기가 같은 글에 나란히 있습니다. 선언은 흘려보낼 수 있어도 도구와 숫자는 곱씹게 됩니다. 이 글에서는 그 두 가지를 천천히 따라가 보겠습니다.

왜 이 짧은 정리 글을 길게 읽어야 했을까

Willison의 글은 길지 않습니다. OpenAI가 RSI를 이야기하는 시점이라는 관찰로 시작하고, Jakub Pachocki가 쓴 An Alien Mind라는 동반 에세이를 소개하고, 연구팀의 코딩 에이전트 활용 이야기로 이어지고, 연구자당 AI 지출 차트를 보여주면서 끝납니다. 요약하면 몇 줄로 끝납니다. 그런데 요약하고 나면 남는 것이 있습니다. OpenAI라는 조직이 자기 연구 방식을 바깥에 설명하기 시작했다는 사실 자체입니다. 예전에는 모델과 논문이 먼저 나왔고 일하는 방식은 나중에 단편적으로 알려졌습니다. 이번에는 순서가 다릅니다. 일하는 방식과 쓰는 양, 그리고 그 흐름을 가리키는 단어가 함께 나옵니다.

저는 평소에 모델 발표를 볼 때 성능표보다 작업 일지를 먼저 찾습니다. 어떤 도구를 쓰고, 어디서 시간이 줄었고, 어디서 사람이 더 들어가는지를 봅니다. 성능표는 결과입니다. 작업 일지는 과정입니다. 과정이 바뀌면 결과가 따라옵니다. Willison이 전하는 OpenAI 소식도 같은 각도에서 읽힙니다. 어떤 모델이 나왔다는 소식보다 연구팀이 매일 무엇을 돌리고 있는지가 더 많은 것을 말합니다. 에이전트가 실험 코드를 짜고, 실패를 정리하고, 다음 시도를 이어가는 장면이 상상됩니다. 상상이라고 말하는 이유는 원문이 세부 절차를 공개하지 않기 때문입니다. 그럼에도 방향은 분명합니다. 연구의 단위 작업이 사람의 손에서 에이전트의 실행으로 옮겨가고 있습니다.

저희가 새로운 AI 연구를 볼 때도 발표 숫자만 보지 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 팀의 하루를 어떻게 바꾸는지를 함께 봅니다. 숫자 뒤에 작업 방식의 변화가 없으면 유행으로 봅니다. 작업 방식이 바뀌면 구조 변화로 봅니다. 이번 소식은 후자에 가깝습니다. 2026년을 에이전트 엔지니어링이 본격화된 해로 적시하고, 내부 지출 곡선을 보여주고, RSI라는 단어까지 꺼냅니다. 각각은 작은 조각이지만 모으면 연구 생산 방식이 달라졌다는 이야기가 됩니다.

RSI라는 말이 설명 없이 등장했다는 사실이 말해주는 것

이 글에서 눈에 띄는 대목은 RSI라는 말이 별다른 정의 없이 등장한다는 점입니다. Willison은 오늘이 OpenAI의 RSI 날인 것 같다고 적습니다. Recursive Self-Improvement의 줄임말이라는 것만 밝히고 넘어갑니다. 동반 에세이 An Alien Mind도 같은 주제를 다룬다고 덧붙입니다. 독자가 이미 RSI라는 말을 알거나, 적어도 낯설어하지 않는다는 전제가 깔려 있습니다. 저는 여기서 조금 멈췄습니다. 보통 새로운 개념을 바깥에 내놓을 때는 정의를 먼저 줍니다. 정의 없이 쓴다는 것은 안쪽에서는 이미 통용되는 말이라는 뜻이기 때문입니다.

RSI는 오래된 말입니다. 시스템이 스스로를 개선하고, 개선된 시스템이 다시 개선을 이어가면서 속도가 붙는다는 생각을 가리킵니다. 말 자체는 단순합니다. 실제로는 질문이 많습니다. 무엇을 개선한다는 말인지, 코드인지 가중치인지 실험 설계인지, 사람이 어디까지 개입하는지, 평가는 누가 하는지가 정해져야 합니다. Willison의 글은 이런 정의를 주지 않습니다. OpenAI가 여러 글을 같은 시기에 내놓았다는 사실만 전합니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 여러 글이 한꺼번에 나온다는 것은 메시지를 맞춘 움직임입니다. 조직이 바깥 대화를 특정 단어로 모으고 싶을 때 이런 방식을 씁니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. RSI라는 말이 나왔다고 해서 자기 개선 루프가 완성되었다는 뜻은 아닙니다. 말과 구현 사이에는 거리가 있습니다. 안쪽에서 통용되는 말이 바깥에 처음 나올 때는 선언의 성격이 짙습니다. 방향을 알리고, 인재를 모으고, 논의의 중심을 잡으려는 의도가 섞입니다. 그래서 저는 이 소식을 능력의 증명보다는 어휘의 등장으로 읽습니다. OpenAI 안에서 쓰던 말이 바깥으로 나왔다는 사실, 그 말이 에이전트 사용법과 지출 곡선과 함께 나왔다는 사실이 중요합니다. 말 alone이 아니라 말과 도구와 숫자의 묶음으로 읽어야 합니다.

2026년이 에이전트 엔지니어링의 해가 된 이유

Willison은 2026년이 OpenAI 안에서 에이전트 엔지니어링이 본격화된 해라고 전합니다. 업계 전반의 흐름과도 맞는다고 덧붙입니다. 저는 이 문장을 읽고 작년부터 이어진 변화를 떠올렸습니다. 코드 완성이 에이전트 실행으로 넘어가고, 단일 파일 편집이 저장소 단위 작업으로 넓어지고, 한 번의 호출이 계획을 세우고 도구를 쓰고 결과를 정리하는 흐름으로 바뀌었습니다. 연구실도 예외가 아닙니다. 오히려 연구실이 이런 변화에 더 민감합니다. 실험이 많고, 실패가 많고, 반복이 많기 때문입니다.

에이전트 엔지니어링이라는 말은 두 가지 뜻을 함께 담습니다. 에이전트를 만드는 엔지니어링과 에이전트와 함께 하는 엔지니어링입니다. 전자는 모델과 도구와 평가를 엮는 일입니다. 후자는 사람의 하루를 다시 짜는 일입니다. 무엇을 에이전트에 맡기고, 무엇을 사람이 직접 보고, 어디서 멈추게 할지를 정하는 일입니다. Willison이 전하는 소식은 후자에 가깝습니다. 연구팀이 실제로 코딩 에이전트를 쓴다는 이야기, 그 사용량이 빠르게 늘었다는 이야기가 중심입니다. 새로운 에이전트 모델이 나왔다는 발표가 아니라 일하는 방식이 바뀌었다는 보고입니다.

문제는 그다음입니다. 도구가 좋아졌다는 말과 일이 잘된다는 말은 다릅니다. 에이전트가 코드를 빨리 짜면 실험 주기가 짧아집니다. 주기가 짧아지면 시도 횟수가 늘어납니다. 시도 횟수가 늘면 좋은 결과가 나올 확률도 오릅니다. 여기까지는 자연스럽습니다. 그런데 시도 횟수가 늘면 검토 부담도 늘어납니다. 어떤 시도가 왜 실패했는지, 실패가 우연인지 구조적인지, 다음 시도로 무엇을 바꿔야 하는지를 가려내야 합니다. 에이전트가 실행을 맡을수록 사람의 일은 판단으로 모입니다. 판단이 병목이 됩니다. 2026년의 이야기는 실행 병목이 풀렸다는 이야기입니다. 판단 병목을 어떻게 풀지는 다음 질문으로 남습니다.

연구자가 코딩 에이전트를 매일 쓰는 풍경

원문이 전하는 장면 가운데 저에게 가장 구체적으로 다가온 부분은 연구팀의 일상적인 에이전트 사용입니다. 거대한 비전이 아니라 매일의 작업입니다. 코드를 짜고, 테스트를 돌리고, 결과를 정리하고, 다음 실험을 설계하는 흐름 안에 에이전트가 들어와 있습니다. 저는 이 대목을 읽으면서 예전에 겪은 장면을 떠올렸습니다. 처음에는 에이전트에 작은 일을 맡깁니다. 파일 몇 개를 고치고 테스트를 돌리는 일입니다. 잘되면 맡기는 범위가 넓어집니다. 저장소 전체를 훑고 계획을 세우는 일을 맡깁니다. 잘 안 되면 범위를 줄입니다. 이 사이클이 몇 주 반복되면 팀마다 자기 방식이 생깁니다. 어떤 일은 에이전트에 맡기고 어떤 일은 사람이 직접 한다는 감각이 생깁니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 에이전트가 만지는 저장소는 얼마나 크고, 테스트는 얼마나 걸리고, 실패했을 때 원인을 얼마나 빨리 찾을 수 있을까. 연구 코드는 제품 코드와 성격이 다릅니다. 수명이 짧고, 가설에 묶여 있고, 깨지기 쉽습니다. 의존성이 엉켜 있고, 문서가 없고, 저자만 아는 가정이 숨어 있습니다. 이런 코드에서 에이전트가 잘 움직이려면 실행 환경이 단단해야 합니다. 한 번의 명령으로 테스트를 돌릴 수 있어야 하고, 실패 로그가 읽기 쉬워야 하고, 되돌리기가 쉬워야 합니다. 도구가 좋아도 환경이 약하면 속도가 나지 않습니다. 환경이 단단하면 평범한 도구로도 속도가 납니다. 저는 OpenAI의 이야기가 모델 성능 이야기인 동시에 환경 정비 이야기라고 봅니다.

또 하나 생각할 지점이 있습니다. 연구자가 에이전트를 쓴다는 말은 연구자가 코드를 덜 읽는다는 뜻이 아닙니다. 오히려 읽는 방식이 바뀝니다. 직접 짜면서 읽던 방식에서 결과물을 검토하면서 읽는 방식으로 바뀝니다. diff를 보고, 테스트 결과를 보고, 이상한 선택을 골라내는 일이 늘어납니다. 이 검토가 느리면 전체 속도가 느려집니다. 검토가 빠르면 전체 속도가 빨라집니다. 그래서 에이전트 시대의 실력은 코드를 빨리 짜는 능력이 아니라 이상함을 빨리 알아채는 능력으로 옮겨갑니다. 어디가 어색한지, 어디가 우연히 통과한 것인지, 어디를 더 파야 하는지를 아는 감각입니다. 원문은 이런 감각의 세부 내용을 공개하지 않습니다. 그럼에도 방향은 분명합니다. 사람의 손은 실행에서 판단으로 이동하고 있습니다.

연구자 한 명당 AI 지출 그래프가 가파르게 꺾인 지점

Willison이 꼽은 장면 가운데 숫자로 남은 것은 연구자당 AI 지출 그래프입니다. 내부 추적 수치로 보이는 이 그래프는 오른쪽으로 갈수록 가파르게 올라갑니다. 특히 7월 말 근처에서 기울기가 확 꺾인다고 합니다. 저는 이 문장을 읽고 그래프의 모양을 상상했습니다. 완만하게 오르던 곡선이 어느 시점을 지나면서 위로 치솟는 모양입니다. 이런 모양은 현장에서 자주 봅니다. 도구가 좋아지거나, 권한이 넓어지거나, 조직이 공식적으로 쓰라고 말하는 시점에 곡선이 꺾입니다. 개인의 자발적 사용이 조직의 공식 흐름이 되는 지점입니다.

지출이라는 말은 조심해서 다뤄야 합니다. 돈이 많이 나갔다는 사실만으로 연구가 빨라졌다고 말할 수는 없습니다. 무엇을 사는지가 중요합니다. 추론 연산인지 학습 연산인지, 실험용인지 평가용인지, 성공한 시도인지 실패한 시도인지에 따라 해석이 달라집니다. 원문은 세부 내역을 공개하지 않습니다. 연구자 한 명당 쓰는 AI 연산량이 빠르게 늘었다는 사실만 전합니다. 저는 이 지점에서 숫자를 그대로 믿기 전에 조건을 봅니다. 분모가 연구자 수라는 점, 분자가 내부 추적 수치라는 점, 시점이 7월 말이라는 점입니다. 분모가 안정적이라면 분자의 증가는 사용 강도의 증가를 말합니다. 내부 추적이라는 말은 과금 기준이 아니라 실행 기준일 가능성을 말합니다. 시점이 분명하다는 점은 원인을 물을 수 있게 합니다.

좋은 건 알겠는데, 이걸 실제로 어떻게 받아들여야 할까요. 저는 지출 곡선을 능력 곡선으로 바로 읽지 않습니다. 지출은 투입입니다. 투입이 늘면 산출이 늘 가능성이 크지만 자동으로 따라오지는 않습니다. 투입이 어디에 쓰였는지가 빠져 있습니다. 그럼에도 무시할 수는 없습니다. 연구 조직은 돈에 민감합니다. 효과가 없는데 쓰는 양을 늘리지는 않습니다. 특히 연구자당 수치로 관리한다는 것은 조직이 이 지표를 본다는 뜻입니다. 보는 지표는 행동을 바꿉니다. 팀이 에이전트를 쓰도록 환경을 만들고, 쓰는 양을 정당화하는 문화가 생깁니다. 곡선의 꺾임은 그래서 단순한 과금 기록이 아니라 조직이 방향을 튼 흔적에 가깝습니다.

7월 말의 꺾임 앞에서 멈추고 생각해 볼 일

Willison은 꺾임의 원인으로 한 가지 가설을 전합니다. 내부 구성원이 나중에 GPT-6 Astra로 공개된 모델에 접근한 시점이 그때라는 설명입니다. 표현을 잘 봐야 합니다. 단정적인 문장이 아니라 추측의 형태입니다. 내부 접근 시점과 곡선의 꺾임이 겹친다는 관찰, 그리고 그 겹침에 의미를 부여하는 해석이 함께 있습니다. 저는 이 가설을 흥미롭게 읽었지만 바로 받아들이지는 않았습니다. 시점이 겹친다는 사실과 원인이 된다는 말 사이에는 검증이 필요합니다.

왜 이런 가설이 나올까요. 새 모델이 들어오면 행동이 바뀌기 때문입니다. 답이 좋아지면 맡기는 일이 늘어납니다. 맡기는 일이 늘면 호출량이 늘어납니다. 호출량이 늘면 지출 곡선이 올라갑니다. 이 연결은 자연스럽습니다. 특히 코딩과 실험처럼 반복이 많은 일에서는 모델 품질 차이가 사용량 차이로 바로 이어집니다. 조금 더 정확하고, 조금 더 지시를 잘 따르고, 조금 더 도구를 잘 쓰면 맡기는 범위가 넓어집니다. 범위가 넓어지면 곡선이 꺾입니다. 가설의 뼈대는 이렇습니다. 새 모델이 들어왔고, 그래서 쓰는 양이 늘었다는 이야기입니다.

여기서는 조금 의심해 볼 필요가 있습니다. 같은 시기에 다른 변화가 있었을 수도 있습니다. 에이전트 실행 환경이 정비되었을 수도 있고, 팀 차원에서 사용을 권장했을 수도 있고, 평가 방식이 바뀌었을 수도 있습니다. 모델 하나가 모든 변화를 설명하지는 않습니다. 현장에서는 여러 변화가 겹쳐서 곡선을 만듭니다. 저는 이 가설을 배제하지 않지만 하나로 확정하지도 않습니다. 내부 접근 시점이라는 설명은 그럴듯합니다. 그럴듯하다는 말은 검증이 필요하다는 말과 같습니다. 다음에 공개될 글이나 발언에서 이 시점 전후에 무엇이 바뀌었는지 더 구체적으로 나오기를 기대합니다. 환경인지 모델인지 정책인지, 아니면 세 가지가 함께인지를 가려내는 정보가 필요합니다.

내부 모델 접근이 연구 속도를 바꾸는 방식

가설을 잠시 받아들이고 생각해 보겠습니다. 내부 팀이 새 모델을 바깥보다 먼저 쓰면 무슨 일이 생길까요. 가장 먼저 바뀌는 것은 시도 횟수입니다. 기다리는 시간이 줄고 돌리는 횟수가 늘어납니다. 밤에 걸어두던 실험을 낮에 여러 번 돌립니다. 실패해도 다시 돌립니다. 다시 돌리니까 실패를 무서워하지 않게 됩니다. 실패를 무서워하지 않으니까 더 어려운 시도를 합니다. 이 순환이 연구 속도의 몸통입니다. 모델이 좋아지면 순환이 빨라집니다. 순환이 빨라지면 팀의 감각이 바뀝니다. 안 되던 일에 시간을 쓰는 팀과 되던 일을 더 빠르게 하는 팀은 다릅니다.

다음으로 바뀌는 것은 맡기는 일의 종류입니다. 이전 모델에는 짧고 분명한 일만 맡겼다면 새 모델에는 길고 모호한 일을 맡깁니다. 저장소 전체를 이해하고 계획을 세우는 일, 실패 로그를 읽고 원인을 추정하는 일, 여러 실험 결과를 모아 다음 가설을 고르는 일 같은 일입니다. 이런 일은 지시를 문장으로 다 적기 어렵습니다. 맥락을 읽고 빈 곳을 채워야 합니다. 채움의 품질이 좋아지면 맡기는 범위가 넓어집니다. 범위가 넓어지면 사람의 하루가 바뀝니다. 직접 짜는 시간이 줄고 고르는 시간이 늘어납니다. 고르는 일이 늘면 고르는 기준이 중요해집니다. 무엇을 좋은 결과로 볼지, 어디까지 믿을지를 팀이 정해야 합니다.

제가 앞으로 보고 싶은 것은 이 고르는 기준에 대한 이야기입니다. 내부 모델이 좋아졌다는 말은 자주 나옵니다. 그 모델을 어떻게 썼다는 이야기는 드뭅니다. 어떤 작업부터 맡겼는지, 어디서 막혔는지, 막힌 자리를 어떻게 풀었는지가 궁금합니다. Willison이 전하는 소식은 그 세부 내용을 담지 않습니다. OpenAI의 글이 앞으로 나온다고 하니 그 글에서 이 대목이 풀리기를 바랍니다. 도구가 좋아졌다는 선언보다 실패를 다루는 방식이 바뀌었다는 보고가 더 도움이 됩니다. 연구 속도는 성공의 속도가 아니라 실패를 통과하는 속도에서 정해지기 때문입니다.

가속을 측정하는 숫자가 놓치는 것들

지출 그래프는 눈에 잘 들어옵니다. 위로 치솟는 곡선은 이야기를 쉽게 만듭니다. 그런데 곡선이 보여주지 않는 것도 많습니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 누가 무엇을 위해 얼마나 돌렸는지, 그 실행이 어떤 결과로 이어졌는지가 빠져 있습니다. 투입 그래프만으로 산출을 말하기는 어렵습니다. 산출 그래프가 따로 필요합니다. 논문 수인지, 실험 성공률인지, 모델 품질인지, 아니면 연구자가 체감하는 속도인지가 정해져야 합니다. 정해지지 않으면 가속이라는 말은 느낌에 머뭅니다.

표면적으로 보면 단순합니다. 쓰는 양이 늘었으니 빨라졌겠지라고 읽힙니다. 실제로는 그렇지 않습니다. 쓰는 양이 늘어난 자리가 중요합니다. 탐색에 쓰였는지, 검증에 쓰였는지, 반복 작업의 자동화에 쓰였는지에 따라 의미가 달라집니다. 탐색에 쓰였다면 시도 범위가 넓어졌다는 뜻입니다. 검증에 쓰였다면 확인이 꼼꼼해졌다는 뜻입니다. 자동화에 쓰였다면 사람이 판단에 쓸 시간이 늘었다는 뜻입니다. 어느 쪽도 나쁘지 않습니다. 다만 같은 곡선이라도 내용은 다릅니다. 원문은 이 구분을 주지 않습니다. 그래서 저는 곡선을 방향 신호로 읽고 내용에 대해서는 판단을 미룹니다.

또 하나 놓치기 쉬운 것은 분모 이야기입니다. 연구자당 수치라고 할 때 연구자의 범위가 중요합니다. 코드를 매일 짜는 연구자인지, 기획과 검토가 중심인 연구자인지, 새로 합류한 연구자인지에 따라 평균의 뜻이 달라집니다. 일부 팀이 많이 쓰고 다른 팀이 적게 써도 평균은 올라갑니다. 평균 뒤의 분포를 봐야 합니다. 고르게 늘었는지, 일부 팀이 끌고 갔는지가 궁금합니다. 일부 팀이 끌고 갔다면 그 팀의 작업 방식이 다음 표준이 될 가능성이 큽니다. 고르게 늘었다면 조직 전체의 문화가 바뀌었다는 뜻입니다. 두 경우의 다음 수는 다릅니다. 다음 글이 나온다면 분포 이야기가 함께 나오기를 바랍니다.

새 연구 방식을 볼 때 저희가 함께 보는 질문들

저희가 새로운 AI 연구를 볼 때도 발표 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이번 소식에도 같은 잣대를 댑니다. 에이전트를 쓴다는 말 다음에 오는 질문들입니다. 실행 환경은 어떻게 되어 있을까, 평가는 얼마나 자주 돌까, 실패를 어떻게 분류할까, 사람의 검토는 어디에 들어갈까 같은 질문입니다. 이런 질문에 답이 있어야 가속이라는 말이 손에 잡힙니다.

저는 여기서 실행 환경 이야기를 먼저 봅니다. 연구 코드에서 에이전트가 잘 돌려면 되돌리기가 쉬워야 합니다. 실험 하나가 저장소를 어지럽히면 다음 실험이 느려집니다. 격리가 잘 되어야 합니다. 테스트가 빨라야 합니다. 느린 테스트는 에이전트를 기다리게 하고 기다림은 시도를 줄입니다. 로그가 읽기 쉬워야 합니다. 로그가 지저분하면 원인을 찾는 데 사람이 붙어야 합니다. 이런 조건이 갖춰지면 모델이 조금 부족해도 속도가 납니다. 조건이 안 갖춰지면 좋은 모델을 써도 속도가 나지 않습니다. OpenAI의 곡선이 꺾인 자리에 모델만 있었을지, 환경 정비도 함께 있었을지가 궁금한 이유입니다.

다음으로 보는 것은 검토 자리입니다. 에이전트가 많이 돌리면 사람이 볼 것도 많아집니다. 다 보면 병목이 됩니다. 안 보면 위험합니다. 어디를 보고 어디를 넘길지를 정해야 합니다. 저는 이 선택이 팀의 실력이라고 봅니다. 위험한 변경은 사람이 보고, 반복적인 변경은 규칙으로 넘기고, 애매한 변경은 샘플로 보는 식의 층위가 필요합니다. 이런 층위가 있으면 투입을 늘려도 품질이 버팁니다. 층위가 없으면 투입을 늘릴수록 빚이 쌓입니다. 원문은 이 층위의 모습을 전하지 않습니다. 앞으로 나올 글에서 이 대목이 풀리면 좋겠습니다. 얼마나 돌렸는지보다 어떻게 골랐는지가 더 오래 남기 때문입니다.

다음에 공개될 글에서 확인하고 싶은 장면들

Willison의 글은 정리가 목적이라 세부 내용을 담지 않습니다. 앞으로 OpenAI의 글이 나온다고 하니 그 글에서 보고 싶은 장면을 적어봅니다. 첫째, 에이전트가 맡은 작업의 구체적인 범위입니다. 파일 편집인지, 실험 설계인지, 결과 분석인지가 궁금합니다. 범위가 넓을수록 검토 방식도 궁금해집니다. 둘째, 실패를 다루는 방식입니다. 실패한 시도를 어떻게 버리고 어떻게 살리는지, 그 판단에 사람이 얼마나 들어가는지가 궁금합니다. 셋째, 7월 말 전후에 바뀐 것의 목록입니다. 모델인지 환경인지 권장 사항인지가 가려지면 곡선의 뜻이 분명해집니다.

이 결과는 마음에 들지만, 여기까지 일반화하기에는 정보가 부족합니다. OpenAI의 이야기가 모든 연구실에 그대로 적용되지는 않습니다. 컴퓨팅 자원이 다르고, 코드 상태가 다르고, 팀의 크기가 다릅니다. 큰 조직에서 되는 방식이 작은 팀에서 그대로 되지는 않습니다. 작은 팀에는 작은 팀의 방식이 필요합니다. 적은 연산으로 많은 판단을 뽑아내는 방식, 실패를 빨리 버리는 방식, 검토를 얇게 유지하는 방식 같은 것입니다. 저는 OpenAI의 소식을 부러움으로 읽지 않습니다. 빌려올 수 있는 대목을 찾는 마음으로 읽습니다. 환경 정비 같은 대목은 규모와 상관없이 빌릴 수 있습니다.

마지막으로 남는 질문을 적습니다. 가속이 빨라지면 무엇을 먼저 해야 할까. 저는 판단 기준을 먼저 다듬겠다고 답합니다. 실행이 빨라질수록 고르는 일이 중요해집니다. 무엇을 좋은 결과로 볼지, 어디서 멈출지, 무엇을 기록으로 남길지를 정해야 합니다. 기준이 없으면 속도는 소음이 됩니다. 기준이 있으면 속도는 자산이 됩니다. 다음 글이 나온다면 기준에 대한 이야기가 나오기를 바랍니다. 얼마나 빨리 돌렸는지보다 무엇을 남겼는지가 연구의 속도이기 때문입니다. 이 글에서 다룬 소식은 선언보다 작업 일지에 가깝습니다. 작업 일지답게 읽으면 배울 점이 많습니다. 저는 그 배울 점을 다음 글에서 더 구체적으로 확인하고 싶습니다.