2,200편을 직접 돌려보니 보인 것들

Hugging Face 팀이 공개한 What We Learned by Reproducing 2,200 papers from ICML은 ICML 논문 2,200편의 중심 주장을 하나씩 직접 다시 실행해 본 기록입니다. 이 시도가 내린 진단은 한 문장으로 정리됩니다. 재현 성공을 가른 가장 센 변수는 아이디어의 참신함이 아니라 코드가 있는지였습니다. 원문은 제목 아래 링크로 연결해 두었습니다.

안녕하세요, 패트릭입니다. 저는 이 글을 읽으면서 예전에 겪었던 장면이 떠올랐는데요. 동료가 공유한 학습 코드를 받아서 그대로 돌렸는데, 첫 실행에서 바로 멈췄던 날이 있었죠. 오류 메시지는 친절하지 않았고, 문제는 코드가 아니라 제 환경에 있었습니다. 그때는 그저 운이 없었다고 넘겼는데, 이번 2,200편짜리 기록을 보고 생각이 달라졌습니다. 그날의 멈춤은 예외가 아니라 흔한 경우에 속했으니까요.

논문은 많은데 왜 직접 돌려보기로 했을까

논문을 읽는 일과 논문을 돌리는 일은 서로 다른 감각을 씁니다. 읽을 때는 수식과 그림이 매끄럽게 이어지면 이해한 것 같은 기분이 드는데요. 막상 코드를 받아서 실행하면 그 매끄러움이 어디에서 왔는지 묻게 되죠. 빠진 설정이 있는지, 전처리가 같은지, 시드가 고정됐는지 같은 질문이 바로 생깁니다.

이번 작업은 그 질문을 2,200번 반복한 셈입니다. 각 논문의 중심 주장을 골라 다시 실행했고, 평균적으로 한 편당 전문가의 몇 시간이 들어갔다고 합니다. 저는 이 대목에서 멈칫했습니다. 몇 시간씩 2,200편이면 단순 계산으로도 엄청난 노동인데, 그 비용을 감수하면서까지 직접 돌린 이유가 궁금했기 때문입니다.

이유는 생각보다 분명합니다. 문서로만 읽으면 보이지 않는 틈이 실행할 때 드러나니까요. 어떤 저장소는 바로 돌아가고, 어떤 저장소는 의존성 하나 때문에 멈춥니다. 어떤 결과는 소수점까지 같고, 어떤 결과는 방향만 같습니다. 이런 차이는 초록을 열심히 읽는다고 알 수 없죠. 손으로 돌려봐야만 남는 기록입니다.

그렇다면 2,200이라는 숫자는 어떻게 받아들여야 할까요. 저는 이 숫자를 순위표로 보지 않습니다. 특정 학회가 유난히 부실하다는 이야기도 아니죠. 오히려 연구가 실제로 공유되는 방식을 넓게 비춰주는 거울에 가깝습니다. 그리고 그 거울에 비친 모습은 생각보다 정직합니다.

코드는 있는데 왜 바로 실행이 안 될까

재현을 시도한 논문 가운데 바로 실행되는 경우는 일부에 그쳤다고 합니다. 그런데 그 일부를 제외한 나머지는 한 가지 이유로 멈춘 게 아니라, 코드가 아예 없거나 코드가 있어도 데이터와 실행 방법이 함께 있지 않아서 멈췄다고 하는데요. 저는 이 대목이 유난히 현실적으로 느껴졌습니다. 논문에는 방법이 적혀 있는데, 그 방법을 컴퓨터가 알아들을 형태로 옮기는 마지막 다리가 빠져 있었던 셈이니까요.

생각해보면 사람도 요리법을 보고 바로 같은 맛을 내기는 어렵습니다. 이를테면 소금 한 꼬집이라는 말이 누구에게는 2그램이고 누구에게는 5그램이듯이, 논문의 저장소도 보는 사람마다 다르게 읽히기 때문입니다. 그래서 저장소가 있어도 설치 순서가 빠져 있으면 첫 명령에서 멈추고, 데이터 경로가 하드코딩되어 있으면 다른 컴퓨터에서는 바로 깨지는데, 이런 생략은 쓰는 사람에게는 당연해 보여서 더 자주 일어납니다. 결국 이런 생략이 반복되는 이유는 문서에는 전제가 숨어들기 쉽기 때문입니다.

여기서 재미있는 질문이 생깁니다. 그렇다면 코드 공개라고 할 때 어디까지를 말해야 할까요. 그게 파일 몇 개를 올리는 일일까요, 아니면 낯선 사람이 새 컴퓨터에서 같은 명령으로 같은 그림을 얻을 수 있는 상태일까요. 이번 기록이 말하는 기준은 분명히 후자에 가까운데, 바로 실행되는지와 필요한 자료가 함께 있는지, 그리고 순서가 적혀 있는지를 함께 보기 때문입니다. 저는 이 기준이 마음에 들었습니다. 친절을 재는 대신 통로를 재고 있으니까요.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데, 같은 태도로 재현을 보면 코드 유무는 단순한 예절의 문제가 아닙니다. 오히려 주장과 증거를 잇는 통로가 열려 있는지를 묻는 일이라서, 그 통로가 좁으면 아무리 좋은 아이디어도 다른 사람의 손에서 확인되기 어렵습니다. 그래서 다음 절에서는 그 통로를 좁히는 사소해 보이는 틈을 조금 더 들여다보겠습니다.

실패는 속임수가 아니라 빠진 설명에서 온다

이번 기록에서 제가 가장 오래 머문 문장은 이것입니다. 대부분의 실패는 부정이 아니라 빠진 설명에서 왔다는 대목인데요. 처음에는 의외로 느껴졌지만, 곱씹을수록 수긍이 갔습니다. 누군가 숫자를 속였다기보다, 숫자를 만든 과정의 일부가 종이에 옮겨지지 않은 경우가 많았다는 뜻이니까요.

이 구분은 생각보다 큽니다. 만약 실패의 원인이 널리 퍼진 속임수라면 대책은 검증과 처벌에 가까워집니다. 반면 원인이 빠진 설명이라면 대책은 기록의 습관에 가깝죠. 무엇을 적어야 하는지, 어디까지 고정해야 하는지, 어떤 전제를 드러내야 하는지를 바꾸면 됩니다.

물론 여기서는 조금 조심해서 읽을 필요가 있습니다. 빠진 설명이 많았다는 말이 모든 논문이 정직했다는 뜻은 아니기 때문입니다. 다만 2,200편이라는 넓은 범위에서 반복된 패턴은 꽤 분명합니다. 고의보다는 생략이 흔했고, 생략은 대개 악의가 아니라 시간과 관습에서 왔습니다. 쓸 때는 당연해 보여서 적지 않은 것들이죠.

(참고로 저도 예전에 전처리 코드를 노트북에만 두고 논문 본문에는 한 줄로 넘긴 적이 있는데요. 그 한 줄이 다른 사람에게는 몇 시간짜리 수수께끼가 됩니다.)

그렇다면 생략은 왜 반복될까요. 연구자는 자신의 환경에서 돌아가는 코드를 갖고 있고, 그 환경에서는 생략된 부분이 자동으로 채워집니다. 문제는 다른 사람의 컴퓨터에서는 그 자동 채움이 일어나지 않는다는 점입니다. 그래서 재현은 일종의 이사를 닮았습니다. 살던 집에서는 당연했던 동선이 새집에서는 설명이 필요하죠.

숫자만 적힌 논문은 왜 다시 돌리기 어려울까

재현이 깨지는 지점을 꼽으면 세 가지가 자주 등장합니다. 빠진 하이퍼파라미터, 빠진 데이터 전처리 단계, 그리고 빠진 랜덤 시드 설정입니다. 저는 이 목록을 보고 고개를 끄덕였는데요. 어느 하나 거창한 이론이 아니라 실행의 디테일이기 때문입니다.

하이퍼파라미터는 학습률이나 배치 크기 같은 숫자만이 아닙니다. 옵티마이저의 종류, 스케줄러의 시점, early stopping의 기준, 가중치 감쇠의 적용 범위까지 묶여 있죠. 이 가운데 하나만 달라져도 학습 곡선은 다른 길을 갑니다. 논문에 최종 성능만 적혀 있고 그 숫자에 이른 경로가 빠져 있으면, 다른 사람은 같은 산을 다른 등산로로 오르는 셈입니다.

전처리도 비슷합니다. 텍스트를 어떻게 자르고, 이미지를 어떤 크기로 바꾸고, 결측을 어떻게 다루고, 정규화를 어떤 순서로 적용했는지가 결과에 스며듭니다. 코드는 있는데 전처리 스크립트가 없으면 이야기가 달라지죠. 같은 모델을 같은 데이터에 돌려도 입력이 미묘하게 다르면 출력도 달라집니다.

시드는 더 미묘합니다. 같은 코드라도 시드가 다르면 초기화와 셔플이 달라지고, GPU 연산 순서가 달라지면 소수점 아래가 흔들립니다. 이 흔들림이 우연히 크게 번지면 재현자는 자신의 실수를 의심하는데요. 실제로는 코드의 잘못이 아니라 기록의 빈칸일 때가 많습니다.

좋은데, 이걸 어디에 적을까요. 저는 답이 부록이나 저장소의 실행 스크립트에 있다고 봅니다. 본문은 아이디어를 설명하고, 부록과 코드는 실행을 보장하는 식으로 역할을 나누는 것이죠. 읽는 사람은 본문에서 방향을 잡고, 돌리는 사람은 스크립트에서 맨발로 밟을 자갈을 치웁니다.

코드가 있으면 이야기가 달라진다

이번 기록에서 반복되는 관찰이 하나 있습니다. 그 관찰은 열린 코드 저장소와 고정된 의존성을 갖춘 논문이 그렇지 않은 논문보다 훨씬 잘 재현됐다는 점인데요. 저는 이 대목보다 그 뒤의 구조가 더 중요하다고 봅니다. 다시 말해 코드가 있다는 사실 자체보다, 어떤 형태의 코드인지가 갈림길을 만들기 때문입니다.

흔히 코드 공개라고 하면 깃허브 링크 하나로 충분하다고 생각하기 쉽습니다. 그런데 링크만 있고 실행 순서가 없으면 재현자는 안내를 받는 게 아니라 탐정이 되는데, README를 뒤지고 이슈를 뒤지고 과거 커밋을 뒤지면서 시간을 쓰게 됩니다. 반면 설치 순서와 의존성 버전이 고정된 저장소는 처음부터 안내원처럼 움직여서, 낯선 환경에서도 같은 길을 걷게 해줍니다. 같은 링크인데 한쪽은 단서이고 다른 쪽은 지도인 셈이죠.

의존성 고정은 겉으로 보면 지루해 보이지만, 막상 겪어보면 효과가 큽니다. 실제로 패키지 하나가 올라가면 함수 이름이 바뀌기도 하고 기본값이 바뀌기도 하는데, 심할 때는 어제까지 경고였던 것이 오늘은 오류로 바뀌기 때문입니다. 그래서 한 달 전에는 돌아가던 코드가 오늘 멈추는 일이 생기는데, 버전을 고정하면 시간의 흐름을 잠시 멈출 수 있어서 완벽하지는 않아도 재현자에게는 큰 도움이 됩니다. 저는 여기서 멈칫했습니다. 왜냐하면 평소에는 귀찮아서 미루던 일이 2,200편 규모에서는 성공과 실패를 가르는 선이 되었기 때문입니다.

그렇다면 pseudocode만 있는 논문은 어떻게 받아들여야 할까요. 저는 pseudocode의 역할을 낮게 보지 않습니다. 이는 아이디어의 뼈대를 보여주는 데는 분명히 쓸모가 있어서, 읽는 사람이 방향을 잡는 데는 큰 도움이 되기 때문입니다. 다만 뼈대만으로 같은 걸음을 걷기는 어려운데, 뼈대에 살을 붙이는 과정마다 선택이 들어가고 그 선택이 모여 결과가 달라지기 때문입니다. 표면적으로 보면 파일을 올리는 일이라 단순해 보이지만, 실제로는 다른 사람의 실행을 설계하는 일에 가깝습니다. 명령 두세 개로 같은 그림이 나온다면, 저는 그 저장소를 논문의 또 다른 본문이라고 부르고 싶습니다.

정확히 같은 숫자는 왜 거의 안 나올까

재현에서 자주 나오는 장면이 있습니다. 소수점까지 같은 숫자를 기대했는데, 다시 돌리면 조금 어긋나는 장면인데요. 이번 기록은 그 어긋남을 이렇게 정리합니다. 정확한 값은 드물게 맞았지만, 경향은 자주 유지됐다고요. 저는 이 문장을 처음에 가볍게 읽었다가 다시 돌아왔습니다. 숫자 재현과 주장 재현이 다른 일일 수 있겠다는 생각이 들어서입니다.

원인은 여러 겹입니다. 랜덤 초기화에 따라 시작점이 달라지고, 데이터 순서에 따라 학습 경로가 달라지며, GPU의 병렬 연산은 순서를 바꿔 미세한 차이를 만듭니다. 이런 차이는 하나씩은 작아도 쌓이면 눈에 보이는 어긋남이 되죠. 같은 코드를 같은 기계에서 돌려도 매번 비트 단위로 같다는 보장이 없습니다.

그래서 보고된 신뢰 구간 안에서 평가하면 통과하는 경우가 많았다고 합니다. 점 하나를 맞히는 대신 띠 안에 들어오는지를 보는 방식이죠. 저는 이 전환이 마음에 들었습니다. 과학의 질문이 이 숫자가 정확히 82.4인가에서 이 방법이 대체로 80대 초반에 머무는가로 바뀌니까요.

여기서 재미있는 질문이 생깁니다. 논문의 표에 적힌 소수점 둘째 자리는 무엇을 위한 숫자일까요. 순위를 가르는 데는 필요할지 몰라도, 아이디어의 방향을 판단하는 데는 앞자리와 구간이 더 정직할 때가 많습니다. 숫자를 조금 흐리게 보는 일이 오히려 판단을 선명하게 만들죠.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 운영 환경에서는 입력도 하드웨어도 매번 조금씩 달라지는데, 소수점에 예민한 개선이 현장에서도 살아남을까요. 저는 그래서 구간 안에서 유지되는 경향을 더 눈여겨봅니다. 현장의 아침을 지켜주는 것은 소수점이 아니라 흔들림에 대한 내성이기 때문입니다.

큰 실험일수록 손이 잘 안 닿는다

재현율이 가장 낮았던 부류는 분명합니다. 그 안을 들여다보면 대규모 연산이 필요하거나 비공개 데이터와 외부 API에 기대는 작업이었는데요. 그 이유는 비용과 접근의 장벽 때문이라고 하는데, 저는 이 결과를 보고 재현의 불평등에 대해 생각했습니다. 다시 말해 누구나 같은 방식으로 확인할 수 있는 주장이 있는 반면, 특정 조건을 갖춘 사람만 확인할 수 있는 주장도 있다는 뜻이니까요.

대규모 학습은 결국 시간과 돈의 문제라서, 수천 시간짜리 학습을 다시 돌리라고 말하기는 어렵습니다. 설령 코드와 데이터가 완벽해도 전기요금 앞에서 멈추게 되는데, 그렇다고 큰 실험을 하지 말자는 이야기는 아닙니다. 다만 큰 실험의 주장은 작은 실험과 다른 방식으로 믿음을 얻어야 해서, 중간 산출물을 나누거나 축소판 실험으로 방향을 보이거나 평가 코드를 열어두는 식의 장치가 필요합니다. 저는 이 대목이 솔직해서 좋았습니다. 규모를 탓하는 대신 규모에 맞는 증거의 모양을 묻고 있으니까요.

비공개 데이터는 또 다른 벽을 세웁니다. 그 가운데 의료나 산업 데이터처럼 바깥으로 내보내기 어려운 자료가 대표적이라서, 애초에 같은 입력을 구할 수 없는 경우가 많기 때문입니다. 외부 API도 비슷한데, 모델 버전이 바뀌거나 과금이 바뀌면 같은 호출이 다른 답을 내놓아서 어제의 결과가 오늘의 결과와 달라지게 됩니다. 결국 코드가 아니라 바깥 환경이 답을 바꾸는 셈이죠. 생각해보면 사람도 비슷하게 배웁니다. 이를테면 교실에서 배운 조리법은 집에서 따라 할 수 있지만, 전문 주방의 화력을 집에서 재현하기는 어려운데, 조리법이 틀린 게 아니라 주방이 다른 경우와 같습니다.

그렇다면 큰 실험의 저자는 무엇을 더 적어야 할까요. 저는 계산 예산과 데이터 접근 조건을 본문의 일부로 다뤘으면 합니다. 구체적으로 얼마나 썼는지와 어디서 막히는지, 그리고 축소판으로는 무엇을 확인할 수 있는지를 미리 밝혀두면 읽는 사람이 자신의 주방에서 어디까지 따라 할 수 있는지 가늠할 수 있기 때문입니다. 이렇게 기대치를 정해주는 것만으로도 헛걸음이 줄어드니까요.

저자가 답장을 하면 왜 달라질까

이번 기록에서 눈에 띄는 대목이 또 있습니다. 저자가 문의에 답해 주면 재현 성공 가능성이 분명히 올라갔다는 점인데요. 저는 이 결과가 연구를 사람 사이의 일로 되돌려서 반가웠습니다. 문서가 아무리 잘 쓰여도 사람 사이를 잇는 한 줄의 답이 빈칸을 메울 때가 있으니까요.

어떤 답이 도움이 될까요. 빠진 버전 번호 하나, 전처리 순서에 대한 확인, 평가 스크립트의 실행 플래그 같은 것들이 대표적입니다. 길게 쓸 필요도 없습니다. 재현자가 막힌 지점을 정확히 짚어주면 막힘이 풀리죠. 몇 시간짜리 헤맴이 한 줄로 정리되는 순간입니다.

반대로 답이 없으면 재현자는 갈림길마다 추측해야 합니다. 추측이 쌓이면 원래 실험과 멀어지고, 멀어진 만큼 결과도 어긋납니다. 나중에는 어긋난 원인이 코드인지 추측인지 구분하기 어려워지죠. 그래서 응답은 단순한 친절을 넘어 오차를 줄이는 장치입니다.

(참고로 저는 예전에 모르는 저자에게 메일을 보내기까지 한참을 망설인 적이 있는데요. 막상 보내고 나면 하루 만에 돌아온 답 한 줄이 일주일을 아껴준 경우가 많았습니다.)

그렇다면 응답을 개인의 성실에만 맡겨야 할까요. 저는 그렇게 보지 않습니다. 연락처를 남기고, 이슈를 열어두고, 자주 묻는 실행 질문을 저장소에 모아두는 일은 구조의 문제죠. 답을 잘하는 사람이 아니라 답이 오갈 수 있는 구조가 재현율을 올립니다. 연구실의 문화와 학회의 규범이 만나는 지점이 여기 있습니다.

시간이 지나면 링크부터 끊긴다

재현성은 시간이 흐르면서 낮아졌다고 합니다. 바깥 링크가 깨지고, 패키지가 올라가고, 보관되지 않은 데이터가 사라지기 때문인데요. 저는 이 대목을 읽으면서 오래된 북마크 폴더를 떠올렸습니다. 분명히 저장해 둔 페이지인데, 몇 년 뒤에 열면 사라져 있거나 전혀 다른 내용이 뜨죠. 연구의 링크도 같은 운명을 겪습니다.

이른바 비트 롯(bit rot)이라고 부를 수 있는 현상인데요. 코드는 그대로인데 세상이 바뀌는 겁니다. 의존하던 라이브러리가 새 버전을 내고, 데이터 호스팅이 끝나고, 데모 서버가 내려갑니다. 논문은 PDF로 남지만, 논문을 둘러싼 실행 환경은 조금씩 허물어지죠. 그래서 같은 논문도 발표 직후와 3년 후의 재현 난이도가 다릅니다.

문제는 이 허물어짐이 조용히 온다는 점입니다. 어느 날 갑자기 깨지는 게 아니라 틈새마다 조금씩 어긋납니다. 경고 하나가 늘고, 다운로드 하나가 막히고, 기본값 하나가 바뀌죠. 각각은 사소해 보이지만 모이면 실행이 멈춥니다. 돌이켜보면 처음부터 깨져 있었던 게 아니라 서서히 멀어진 겁니다.

그렇다면 시간을 버티는 저장소는 무엇이 다를까요. 저는 보관의 태도가 다르다고 봅니다. 바깥 링크 대신 파일을 직접 보관하거나 해시를 남기고, 의존성을 고정하고, 컨테이너나 잠금 파일로 환경을 묶어두는 식이죠. 완벽한 영생은 없어도 수명을 늘리는 방법은 분명히 있습니다.

저희 팀에서도 오래된 실험을 다시 돌릴 때 비슷한 일을 겪습니다. 반년 전 코드는 어제 쓴 코드가 아니죠. 그래서 요즘은 실행 명령과 환경을 같은 곳에 두려고 애씁니다. 미래의 저와 미래의 동료가 같은 버튼을 누를 수 있게 말입니다. 이 기록을 읽고 그 습관이 틀리지 않았다는 느낌이 들었습니다.

평균 몇 시간이라는 말에서 무엇을 읽을까

논문 한 편을 재현하는 데 평균적으로 전문가의 몇 시간이 들었다는 대목은 곱씹을수록 묵직합니다. 몇 시간은 짧아 보이지만, 2,200편에 곱하면 이야기가 달라지죠. 저는 이 숫자를 비용의 언어로 읽었습니다. 확인에는 품이 들고, 그 품은 누군가 내야 한다는 뜻이니까요.

이 비용을 누가 낼까요. 지금은 대체로 읽는 사람이 냅니다. 재현하려는 학생이나 엔지니어가 막힌 부분을 뚫고, 버전을 맞추고, 데이터를 찾아오죠. 그런데 이 구조는 묘하게 비대칭입니다. 쓰는 사람은 생략으로 시간을 아끼고, 읽는 사람은 생략을 메우느라 시간을 씁니다. 생략의 비용이 다른 사람의 통장에서 빠져나가는 셈입니다.

그래서 저는 실행 가능성을 논문의 예절이 아니라 설계로 봤으면 합니다. 처음부터 다른 사람이 돌릴 것을 전제로 쓰고, 저장하고, 고정하는 것이죠. 추가 작업처럼 느껴지지만, 길게 보면 쓰는 사람의 시간도 아껴줍니다. 문의 메일에 답하는 시간, 오래된 코드를 다시 살리는 시간, 논문 출판 뒤에 붙는 뒷수습이 줄어드니까요.

여기서 practical한 질문이 생깁니다. 심사나 게재 과정이 이 비용을 나눌 수 있을까요. 실행 스크립트를 함께 보게 하거나, 의존성 목록을 확인하거나, 데이터 접근 조건을 명시하게 하는 것만으로도 풍경이 달라집니다. 거창한 제도가 아니어도 됩니다. 돌려볼 수 있는지를 묻는 칸 하나가 습관을 바꾸죠.

반면 이런 말을 덧붙이고 싶습니다. 모든 논문이 같은 수준의 재현 패키지를 갖출 필요는 없습니다. 아이디어 논문과 시스템 논문의 무게가 다르고, 공개할 수 있는 자료의 범위도 다르니까요. 다만 어디까지 따라 할 수 있고 어디부터는 막히는지를 솔직히 적어두는 일은 누구에게나 필요합니다. 기대치를 정해주는 것만으로도 헛걸음이 줄어듭니다.

그래서 다음 논문은 어떻게 읽어야 할까

2,200편의 기록을 다 읽고 나면 질문도 바뀌었습니다. 이 논문이 맞는가에서 이 논문을 어디까지 따라 할 수 있는가로 말이죠. 저는 앞으로 논문을 읽을 때 코드와 데이터의 상태를 먼저 보려고 합니다. 저장소가 있는지, 실행 순서가 있는지, 의존성이 고정됐는지, 데이터 접근이 가능한지부터 확인하는 겁니다.

이런 읽기는 의심이 아니라 효율의 문제입니다. 재현 패키지가 탄탄하면 숫자를 깊게 파고들 수 있고, 패키지가 비어 있으면 아이디어의 방향만 가져오면 됩니다. 기대를 먼저 맞추면 실망도 줄고, 오해도 줄죠. 모든 논문에 같은 잣대를 들이댈 필요는 없습니다. 다만 어떤 잣대를 들지 먼저 고르는 일은 필요합니다.

그렇다면 연구자로서 무엇을 남겨야 할까요. 저는 답을 실행 스크립트라고 봅니다. 본문이 생각을 정리한다면 스크립트는 손을 안내하니까요. 하이퍼파라미터와 시드, 전처리 순서와 평가 명령이 한곳에 모여 있으면 재현자는 헤매지 않습니다. 거기에 연락이 닿는 창구까지 있으면 더 좋습니다.

제가 앞으로 보고 싶은 것은 재현의 풍경이 바뀌는 모습입니다. 코드 가용성이 성공을 가른다는 말이 당연해져서 굳이 강조하지 않아도 되는 상태, 구간으로 보는 평가가 점 하나로 보는 평가만큼 익숙해지는 상태, 시간이 지나도 돌아가는 저장소가 늘어나는 상태 말이죠. 이런 변화는 한 번의 선언으로 오지 않고, 저장소 하나하나의 습관에서 옵니다.

사람이 함께 일하다 보면 작은 메모 한 줄이 팀 전체의 속도를 바꾸기도 합니다. 연구도 다르지 않다고 봅니다. 빠진 한 줄을 채우는 일이 2,200번 모이면 학문의 속도가 달라지죠. 그렇다면 우리의 역할은 무엇일까요. 저는 답을 기록의 쪽에 두고 싶습니다. 다음 사람이 같은 자리에서 헤매지 않게, 실행의 다리를 함께 놓는 일이니까요.