<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Academic Career | Giseop Kim</title><link>https://gisbi-kim.github.io/tags/academic-career/</link><atom:link href="https://gisbi-kim.github.io/tags/academic-career/index.xml" rel="self" type="application/rss+xml"/><description>Academic Career</description><generator>Hugo Blox Builder (https://hugoblox.com)</generator><language>en-us</language><lastBuildDate>Wed, 05 Aug 2026 20:19:49 +0900</lastBuildDate><image><url>https://gisbi-kim.github.io/media/icon_hu567daa2745bcf51c7054a3380349c3ad_4435_512x512_fill_catmullrom_center_3.png</url><title>Academic Career</title><link>https://gisbi-kim.github.io/tags/academic-career/</link></image><item><title>논문을 쓰는 사람에서 연구 시스템을 만드는 사람으로</title><link>https://gisbi-kim.github.io/from-paper-writer-to-research-system-builder/</link><pubDate>Wed, 05 Aug 2026 20:19:49 +0900</pubDate><guid>https://gisbi-kim.github.io/from-paper-writer-to-research-system-builder/</guid><description>&lt;h2 id="ai-시대-대학원생을-위한-연구커리어경영학-강의">AI 시대 대학원생을 위한 연구커리어경영학 강의&lt;/h2>
&lt;p>대학원에 들어오면 대개 논문 쓰는 법을 배우게 될 거라고 생각한다. 좋은 아이디어를 찾고, 코드를 구현하고, 실험을 돌리고, 결과를 논문으로 정리하는 법을 배우면 연구자가 된다고 여긴다. 틀린 말은 아니다. 그러나 이것은 연구자의 일을 지나치게 평면적으로 본 설명이다.&lt;/p>
&lt;p>대학원에서 정말 배워야 하는 것은 논문이라는 문서를 생산하는 기술만이 아니다. 불확실한 문제를 선택하고, 믿을 수 있는 증거를 만들고, 실패를 해석하고, 한 번의 노력이 다음 연구의 비용을 낮추게 하며, 여러 개의 프로젝트를 하나의 장기적인 연구 방향으로 축적하는 법을 배워야 한다. 다시 말해 대학원은 연구 작업을 수행하는 법뿐 아니라 자신의 연구 시스템을 설계하고 운영하는 법을 배우는 곳이다.&lt;/p>
&lt;p>이 차이는 AI 시대에 더 중요해졌다. 이제 문헌을 찾고 요약하는 일, 코드를 작성하는 일, 그래프를 그리는 일, 초벌 문장을 만드는 일은 과거보다 훨씬 싸고 빨라졌다. 몇 년 전이라면 며칠 걸렸을 작업을 몇 시간 안에 끝낼 수도 있다. 하지만 작업의 속도가 빨라졌다고 해서 연구의 방향이 저절로 정확해지는 것은 아니다. 코드가 빨리 만들어져도 실험 설계가 틀릴 수 있고, 결과가 많이 나와도 무엇을 뜻하는지 모를 수 있으며, 문장이 매끄러워도 주장이 비어 있을 수 있다.&lt;/p>
&lt;p>AI가 연구자의 손을 빠르게 만들수록 머리와 눈의 중요성은 커진다. 무엇을 할 것인지 정하는 머리, 결과를 믿어도 되는지 판단하는 눈, 그리고 오늘의 작업을 내일의 자산으로 바꾸는 시스템 사고가 중요해진다.&lt;/p>
&lt;p>이 강의의 핵심 명제는 간단하다.&lt;/p>
&lt;blockquote>
&lt;p>대학원생의 목표는 논문 한 편을 만드는 사람이 되는 데서 끝나지 않는다. 좋은 연구가 반복해서 나오게 만드는 자기만의 시스템을 갖춘 연구자가 되어야 한다.&lt;/p>
&lt;/blockquote>
&lt;hr>
&lt;h2 id="1-연구를-일의-묶음이-아니라-연결된-시스템으로-보라">1. 연구를 ‘일의 묶음’이 아니라 ‘연결된 시스템’으로 보라&lt;/h2>
&lt;p>연구를 처음 시작하면 눈앞의 작업만 보인다.&lt;/p>
&lt;p>논문을 읽어야 한다. 코드를 고쳐야 한다. 데이터셋을 내려받아야 한다. 실험을 돌려야 한다. 표를 채워야 한다. 마감까지 원고를 완성해야 한다. 각 작업은 분명 필요하다. 그러나 이 작업들을 독립된 할 일로만 보면 아무리 바쁘게 움직여도 연구자로서 축적되는 것이 적다.&lt;/p>
&lt;p>시스템 사고는 각 작업이 무엇과 연결되어 있는지를 보는 습관이다.&lt;/p>
&lt;ul>
&lt;li>지금 돌리는 실험은 어떤 주장을 검증하는가.&lt;/li>
&lt;li>그 주장은 논문의 중심 질문과 어떻게 연결되는가.&lt;/li>
&lt;li>이 논문은 기존 연구의 어떤 가정을 바꾸려 하는가.&lt;/li>
&lt;li>이 과정에서 만든 코드와 데이터는 다음 프로젝트에서 다시 쓰일 수 있는가.&lt;/li>
&lt;li>이번 실패는 이후의 의사결정을 더 빠르게 만들어주는가.&lt;/li>
&lt;li>이 프로젝트는 장기적으로 내가 어떤 연구자로 기억되는 데 기여하는가.&lt;/li>
&lt;/ul>
&lt;p>이 질문들을 할 수 있으면 같은 실험을 해도 남는 것이 달라진다.&lt;/p>
&lt;p>한 학생은 실험을 100번 돌리고 성능표 하나를 남긴다. 다른 학생은 30번의 실험을 통해 성능을 결정하는 핵심 변수를 찾아내고, 자동 평가 코드를 만들고, 실패 조건을 분류하고, 다음 학생이 재현할 수 있는 문서를 남긴다. 전자는 더 많은 작업을 했을 수 있다. 하지만 후자는 연구 시스템을 개선했다.&lt;/p>
&lt;p>시스템 사고는 무조건 큰 이야기를 하는 능력이 아니다. 모든 실험을 인류의 미래와 연결하거나 거창한 연구 비전을 붙이는 것도 아니다. 시스템 사고의 가장 실용적인 정의는 다음과 같다.&lt;/p>
&lt;blockquote>
&lt;p>내가 지금 하는 일이 다음 의사결정과 다음 연구의 조건을 어떻게 바꾸는지 이해하는 능력이다.&lt;/p>
&lt;/blockquote>
&lt;p>좋은 연구자는 오늘의 작업을 끝내는 데서 멈추지 않는다. 작업이 끝난 뒤 연구 시스템이 이전보다 나은 상태가 되었는지를 본다.&lt;/p>
&lt;hr>
&lt;h2 id="2-산출물-성과-자산을-구분하라">2. 산출물, 성과, 자산을 구분하라&lt;/h2>
&lt;p>대학원생이 가장 자주 혼동하는 세 가지가 있다. 산출물, 성과, 자산이다.&lt;/p>
&lt;table>
&lt;thead>
&lt;tr>
&lt;th>구분&lt;/th>
&lt;th>예시&lt;/th>
&lt;th>핵심 질문&lt;/th>
&lt;/tr>
&lt;/thead>
&lt;tbody>
&lt;tr>
&lt;td>산출물&lt;/td>
&lt;td>코드, 실험 로그, 표, 그림, 초벌 원고&lt;/td>
&lt;td>무엇을 만들었는가&lt;/td>
&lt;/tr>
&lt;tr>
&lt;td>성과&lt;/td>
&lt;td>가설 검증, 원인 규명, 논문 채택, 성능 개선&lt;/td>
&lt;td>무엇이 달라졌는가&lt;/td>
&lt;/tr>
&lt;tr>
&lt;td>자산&lt;/td>
&lt;td>재사용 가능한 평가기, 데이터, 지식, 평판, 연구 프레임&lt;/td>
&lt;td>다음 연구가 얼마나 쉬워졌는가&lt;/td>
&lt;/tr>
&lt;/tbody>
&lt;/table>
&lt;p>실험을 많이 돌린 것은 산출물이다. 그 실험을 통해 특정 모듈이 실제 성능 향상의 원인임을 밝혀낸 것은 성과다. 그 검증을 다른 방법에도 적용할 수 있는 평가체계로 만든 것은 자산이다.&lt;/p>
&lt;p>논문 한 편을 제출한 것은 산출물에 가깝다. 그 논문이 새로운 사실을 설득력 있게 보여준 것은 성과다. 그 논문이 후속 연구, 데이터셋, 코드베이스, 협업, 연구 정체성으로 이어진다면 자산이 된다.&lt;/p>
&lt;p>대학원 생활이 힘든 이유 중 하나는 산출물을 성과로 착각하기 쉽기 때문이다. 며칠 동안 코딩하고 밤새 실험하면 많은 일을 했다는 감각이 생긴다. 그 감각 자체는 거짓이 아니다. 실제로 노력했다. 그러나 연구는 노력의 양이 아니라 불확실성이 얼마나 줄었는지로 진척을 측정해야 한다.&lt;/p>
&lt;p>그래서 매주 자신에게 세 가지를 물어야 한다.&lt;/p>
&lt;ol>
&lt;li>이번 주에 무엇을 만들었는가.&lt;/li>
&lt;li>그 결과 무엇을 새롭게 알게 되었는가.&lt;/li>
&lt;li>다음 주와 다음 프로젝트를 위해 무엇을 남겼는가.&lt;/li>
&lt;/ol>
&lt;p>첫 번째 질문에만 답할 수 있다면 바빴지만 연구가 전진하지 않았을 가능성이 있다. 두 번째까지 답하면 연구 성과가 생긴 것이다. 세 번째까지 답하면 연구커리어가 축적되기 시작한 것이다.&lt;/p>
&lt;hr>
&lt;h2 id="3-ai가-낮춘-것은-실행비용이지-판단비용이-아니다">3. AI가 낮춘 것은 실행비용이지 판단비용이 아니다&lt;/h2>
&lt;p>AI는 연구의 여러 부분을 빠르게 바꾸고 있다. 논문 검색과 요약, 코드 초안, 디버깅, 데이터 분석, 글쓰기, 발표자료 제작까지 거의 모든 단계에 개입한다. 덕분에 대학원생 한 명이 과거의 작은 팀이 하던 양의 작업을 수행할 수 있게 됐다.&lt;/p>
&lt;p>그러나 여기에는 중요한 착시가 있다. 실행비용이 낮아지면 사람들은 실행이 곧 연구라고 생각하기 쉽다.&lt;/p>
&lt;p>예를 들어 AI에게 새로운 SLAM 방법을 제안해달라고 하면 여러 아이디어를 얻을 수 있다. 그중 하나를 코드로 만들고 공개 데이터셋에서 수치를 얻는 일도 예전보다 쉬워졌다. 하지만 다음 질문은 여전히 남는다.&lt;/p>
&lt;ul>
&lt;li>왜 이 문제가 중요한가.&lt;/li>
&lt;li>제안한 변화가 기존 방법의 어떤 한계를 해결하는가.&lt;/li>
&lt;li>성능 향상이 정말 제안한 원리 때문에 발생했는가.&lt;/li>
&lt;li>비교 방법의 구현과 설정은 공정한가.&lt;/li>
&lt;li>데이터 누수나 평가 편향은 없는가.&lt;/li>
&lt;li>다른 환경에서도 같은 경향이 나타나는가.&lt;/li>
&lt;li>이 결과가 새로운 지식인지 단순한 튜닝 효과인지 어떻게 구분할 것인가.&lt;/li>
&lt;/ul>
&lt;p>AI는 답처럼 보이는 문장을 만들 수 있지만, 그 답을 믿어도 되는지는 보장하지 않는다. 오히려 그럴듯한 결과가 빠르게 많이 만들어지기 때문에 검증해야 할 양이 늘어난다. 생산성이 높아진 만큼 검증부채도 빠르게 쌓인다.&lt;/p>
&lt;p>여기서 검증부채란 아직 이해하거나 확인하지 않은 채 연구에 들어온 주장, 코드, 데이터 처리, 분석 결과가 누적되는 상태를 말한다. AI가 만든 코드가 돌아간다는 이유로 내부 동작을 확인하지 않거나, AI가 요약한 논문을 원문 확인 없이 인용하거나, 자동 분석 결과를 통계적 검토 없이 사용하면 검증부채가 쌓인다. 마감 직전에 그 부채가 한꺼번에 드러나면 실험 전체를 다시 해야 할 수도 있다.&lt;/p>
&lt;p>따라서 AI 유창성은 프롬프트를 멋지게 쓰는 능력이 아니다. 다음 네 가지를 할 수 있는 능력이다.&lt;/p>
&lt;ol>
&lt;li>어떤 작업을 AI에 맡기면 좋은지 안다.&lt;/li>
&lt;li>어떤 작업은 인간이 직접 판단해야 하는지 안다.&lt;/li>
&lt;li>AI가 만든 결과를 검증할 방법을 먼저 설계한다.&lt;/li>
&lt;li>생성된 결과에 대해 최종 책임을 진다.&lt;/li>
&lt;/ol>
&lt;p>AI는 권위자가 아니라 매우 빠른 초급 공동연구자처럼 다뤄야 한다. 넓게 조사하고, 초안을 만들고, 반복적인 구현을 수행하는 데는 뛰어나다. 그러나 문제의 중요성과 증거의 충분성을 최종 판단하는 책임은 연구자에게 있다.&lt;/p>
&lt;hr>
&lt;h2 id="4-아이디어-생산량보다-아이디어-선별-정밀도를-높여라">4. 아이디어 생산량보다 아이디어 선별 정밀도를 높여라&lt;/h2>
&lt;p>과거에는 좋은 아이디어를 얻는 것 자체가 어려웠다. 지금은 아이디어가 부족하기보다 너무 많아서 문제다. AI에게 요청하면 연구 주제 열 개, 백 개도 쉽게 얻을 수 있다. 최신 논문 두세 편을 조합하면 그럴듯한 방법 이름과 구성도도 금방 나온다.&lt;/p>
&lt;p>이 환경에서는 아이디어를 많이 내는 사람이 반드시 유리하지 않다. 중요한 것은 어떤 아이디어에 학생의 시간, GPU, 로봇 실험, 공동연구자의 신뢰를 투입할 것인지 고르는 능력이다.&lt;/p>
&lt;p>좋은 연구 문제는 단순히 새로워 보이는 문제가 아니다. 최소한 다음 세 조건을 만족해야 한다.&lt;/p>
&lt;h3 id="중요성">중요성&lt;/h3>
&lt;p>성공했을 때 누가 무엇을 다르게 할 수 있는가. 연구 공동체가 실제로 어려워하는 문제인가. 성능이 조금 오르는 것 이상의 의미가 있는가.&lt;/p>
&lt;h3 id="검증-가능성">검증 가능성&lt;/h3>
&lt;p>주어진 시간과 자원 안에서 핵심 가설을 반증할 수 있는가. 성공 여부를 분명히 판단할 평가가 있는가. 무엇이 나오더라도 성공이라고 주장할 수 있는 문제라면 좋은 과학적 문제가 아니다.&lt;/p>
&lt;h3 id="비교우위">비교우위&lt;/h3>
&lt;p>왜 하필 내가, 우리 연구실이 이 문제를 풀 가능성이 높은가. 이미 가진 데이터, 코드, 장비, 현장, 지식, 공동연구 네트워크를 활용할 수 있는가. 좋은 문제라도 아무런 우위가 없다면 너무 비싸거나 늦을 수 있다.&lt;/p>
&lt;p>이 세 조건을 합치면 문제 선택의 기준이 바뀐다.&lt;/p>
&lt;blockquote>
&lt;p>가장 화려한 문제가 아니라, 중요하고 검증 가능하며 내가 구조적으로 유리한 문제를 선택하라.&lt;/p>
&lt;/blockquote>
&lt;p>지도교수에게 아이디어 열 개를 던지고 골라달라고 하는 것은 문제 선택을 위임하는 행동이다. 더 나은 방식은 후보를 스스로 걸러낸 뒤 하나의 문제 메모를 가져가는 것이다.&lt;/p>
&lt;p>문제 메모에는 다음이 들어가면 좋다.&lt;/p>
&lt;ul>
&lt;li>현재 분야가 풀지 못한 문제는 무엇인가.&lt;/li>
&lt;li>기존 방법은 왜 그 문제에서 실패하는가.&lt;/li>
&lt;li>내가 의심하는 핵심 원인은 무엇인가.&lt;/li>
&lt;li>가장 작은 검증 실험은 무엇인가.&lt;/li>
&lt;li>어떤 결과가 나오면 이 아이디어를 포기할 것인가.&lt;/li>
&lt;li>우리 연구실의 어떤 자산을 사용할 수 있는가.&lt;/li>
&lt;li>성공하면 다음 연구로 어떻게 확장할 수 있는가.&lt;/li>
&lt;/ul>
&lt;p>이 메모를 쓰는 과정 자체가 연구다. 코드를 열기 전에 문제의 구조를 먼저 쓰는 습관을 들여라. 실행이 싸진 시대에는 잘못된 방향으로 빠르게 달리는 것이 가장 비싼 실패가 된다.&lt;/p>
&lt;hr>
&lt;h2 id="5-첫-번째-양의-결과는-연구의-끝이-아니라-시작이다">5. 첫 번째 양의 결과는 연구의 끝이 아니라 시작이다&lt;/h2>
&lt;p>대학원생은 처음으로 성능이 오른 순간 강한 흥분을 느낀다. 기존 방법보다 2% 좋아졌거나, 실패하던 장면에서 성공했거나, 예상한 그래프가 나왔을 때 “이제 논문이 된다”고 생각하기 쉽다.&lt;/p>
&lt;p>하지만 첫 번째 양의 결과는 논문의 완성이 아니다. 연구할 가치가 있다는 신호일 뿐이다.&lt;/p>
&lt;p>프로토타입은 가능성을 보여준다. 연구 수준의 결과는 그 가능성이 우연, 편향, 구현 차이, 데이터 누수, 잘못된 비교 때문에 생긴 것이 아님을 보여준다. 둘 사이에는 큰 간격이 있다.&lt;/p>
&lt;p>연구 수준으로 넘어가기 위해서는 최소한 여섯 개의 문을 통과해야 한다.&lt;/p>
&lt;h3 id="주장의-문">주장의 문&lt;/h3>
&lt;p>우리가 정확히 무엇을 주장하는가. “성능이 좋아졌다”가 아니라 어떤 원리, 조건, 인과관계에 대한 주장인지 명확해야 한다.&lt;/p>
&lt;h3 id="데이터의-문">데이터의 문&lt;/h3>
&lt;p>데이터가 주장을 검증하기에 적합한가. train과 test의 독립성, 장면 다양성, 센서 조건, GT 품질이 충분한가.&lt;/p>
&lt;h3 id="비교의-문">비교의 문&lt;/h3>
&lt;p>강한 최신 방법과 공정하게 비교했는가. 하이퍼파라미터, 입력 정보, 계산량, 사전학습 조건이 다르다면 그 차이를 공개했는가.&lt;/p>
&lt;h3 id="강건성의-문">강건성의 문&lt;/h3>
&lt;p>여러 seed, 환경, 데이터셋, 조건에서 경향이 유지되는가. 특정 장면 하나의 성공을 일반적 효과로 확대해석하고 있지 않은가.&lt;/p>
&lt;h3 id="설명의-문">설명의 문&lt;/h3>
&lt;p>왜 좋아졌는지 이해하고 있는가. 모듈을 제거하거나 조건을 바꾸었을 때 예측한 방식으로 성능이 변하는가.&lt;/p>
&lt;h3 id="재현성의-문">재현성의 문&lt;/h3>
&lt;p>몇 주 뒤의 나와 다른 연구자가 같은 결과를 다시 만들 수 있는가. 코드, 설정, 데이터 처리, 평가 과정이 기록되어 있는가.&lt;/p>
&lt;p>AI는 프로토타입까지 도달하는 시간을 크게 줄여준다. 그래서 앞으로 연구자의 차이는 프로토타입을 만드는 속도보다 프로토타입을 신뢰할 만한 지식으로 승격시키는 능력에서 벌어진다.&lt;/p>
&lt;p>빠른 데모를 자랑하기 전에 스스로 물어라.&lt;/p>
&lt;blockquote>
&lt;p>이것은 작동하는 장면인가, 아니면 믿을 수 있는 주장인가?&lt;/p>
&lt;/blockquote>
&lt;hr>
&lt;h2 id="6-전문성을-버리지-말고-전문성의-형태를-바꿔라">6. 전문성을 버리지 말고 전문성의 형태를 바꿔라&lt;/h2>
&lt;p>AI 시대에 제너럴리스트가 중요하다는 말을 오해하면 안 된다. 여러 도구를 얕게 써볼 줄 아는 사람이 깊은 전문가를 대체한다는 뜻이 아니다. 연구에서 깊이는 여전히 중요하다. 오히려 표면적인 작업이 자동화될수록 깊은 판단은 더 희소해진다.&lt;/p>
&lt;p>SLAM 코드를 생성하는 것과 SLAM 시스템을 이해하는 것은 다르다. 논문을 요약하는 것과 그 논문의 숨은 가정과 취약한 평가를 알아보는 것도 다르다. 통계 패키지로 유의확률을 구하는 것과 그 통계적 검정이 문제에 적합한지 판단하는 것도 다르다.&lt;/p>
&lt;p>전문성의 핵심은 많이 기억하는 데 있지 않다. 전문가는 다음을 빠르게 알아본다.&lt;/p>
&lt;ul>
&lt;li>무엇이 이상한가.&lt;/li>
&lt;li>어떤 설명이 그럴듯하지 않은가.&lt;/li>
&lt;li>어떤 변수부터 확인해야 하는가.&lt;/li>
&lt;li>어느 정도의 증거가 충분한가.&lt;/li>
&lt;li>무엇이 이 분야에서는 정말 어려운가.&lt;/li>
&lt;li>어떤 결과가 나오면 기존 믿음을 수정해야 하는가.&lt;/li>
&lt;/ul>
&lt;p>이것은 안목과 보정된 판단력이다. 오랜 시간 실제 문제를 풀고 실패를 해석하면서 생긴다. AI가 지식을 제공해줄 수는 있지만, 이 판단력을 자동으로 이식해주지는 않는다.&lt;/p>
&lt;p>미래의 좋은 연구자는 한 분야에만 갇힌 좁은 전문가도 아니고, 어느 분야에서도 책임 있는 판단을 못 하는 얕은 제너럴리스트도 아니다. 중심축과 연결면을 동시에 가진 사람이다.&lt;/p>
&lt;p>중심축은 동료가 의존할 만큼 깊은 전문성이다. 연결면은 그 전문성을 데이터, 시스템, 하드웨어, 인간, 다른 학문과 이어서 더 큰 문제를 푸는 능력이다.&lt;/p>
&lt;p>예를 들어 공간지능 연구자라면 geometry, estimation, representation 중 적어도 하나에서는 깊은 판단력을 가져야 한다. 동시에 learning, language, interaction, hardware deployment와 연결할 수 있어야 한다. 중심축 없이 연결만 많으면 유행을 따라다니는 연구자가 된다. 연결면 없이 중심축만 깊으면 자신의 도구가 맞지 않는 문제에서도 같은 방식만 반복하게 된다.&lt;/p>
&lt;p>대학원 동안 반드시 하나의 질문에 답할 수 있어야 한다.&lt;/p>
&lt;blockquote>
&lt;p>다른 연구자들이 어떤 종류의 판단이 필요할 때 나를 찾게 만들 것인가?&lt;/p>
&lt;/blockquote>
&lt;p>논문 주제보다 더 중요한 커리어 질문이다.&lt;/p>
&lt;hr>
&lt;h2 id="7-한-편의-논문을-비용으로-끝내지-말고-연구-자본으로-바꿔라">7. 한 편의 논문을 비용으로 끝내지 말고 연구 자본으로 바꿔라&lt;/h2>
&lt;p>논문 한 편에는 많은 비용이 들어간다. 문헌조사, 코드 구현, 데이터 수집, 장비 구축, 실험, 실패, 글쓰기, 리뷰 대응까지 수개월 혹은 수년이 든다. 그런데 논문을 제출한 뒤 프로젝트 폴더가 닫히고 아무것도 재사용되지 않는다면 그 비용의 대부분은 소모된 것이다.&lt;/p>
&lt;p>연구커리어경영학에서는 논문을 성과인 동시에 투자로 본다. 좋은 프로젝트는 논문을 만들면서 다음 연구의 생산비를 낮추는 자산을 남긴다.&lt;/p>
&lt;p>연구 자산에는 여러 종류가 있다.&lt;/p>
&lt;h3 id="기술-자산">기술 자산&lt;/h3>
&lt;p>공용 코드베이스, 데이터 수집기, 평가 파이프라인, 시뮬레이터, 로봇 플랫폼, 자동화 도구다. 다음 프로젝트가 처음부터 시작하지 않게 한다.&lt;/p>
&lt;h3 id="데이터-자산">데이터 자산&lt;/h3>
&lt;p>잘 정리된 데이터셋, 메타데이터, 실패 장면, GT, 장기 실험 기록이다. 다른 사람이 쉽게 복제할 수 없는 비교우위를 만든다.&lt;/p>
&lt;h3 id="지식-자산">지식 자산&lt;/h3>
&lt;p>어떤 방법이 어떤 조건에서 실패하는지, 어떤 하이퍼파라미터가 중요한지, 어떤 실험이 의미 없는지를 기록한 지식이다. 성공 결과만큼 실패의 구조도 중요한 자산이다.&lt;/p>
&lt;h3 id="서사-자산">서사 자산&lt;/h3>
&lt;p>문제를 바라보는 프레임, 용어, 평가 지표, 그림, 연구 질문이다. 다른 연구자가 그 언어를 사용하기 시작하면 연구자는 분야의 문제 정의에 영향을 주게 된다.&lt;/p>
&lt;h3 id="신뢰-자산">신뢰 자산&lt;/h3>
&lt;p>재현 가능한 코드, 정직한 한계 공개, 정확한 리뷰 대응을 통해 쌓이는 평판이다. 신뢰는 좋은 학생, 공동연구, 초청, 후속 기회를 불러온다.&lt;/p>
&lt;h3 id="관계-자산">관계 자산&lt;/h3>
&lt;p>공동연구자, 데이터 제공자, 현장 파트너, 다른 분야의 전문가와 만든 연결이다. 혼자서는 접근할 수 없는 문제를 풀게 한다.&lt;/p>
&lt;p>개별 논문에만 맞춘 임시 코드는 그 논문의 비용이다. 여러 논문이 사용하는 코드는 연구 자본이다. 한 번 쓰고 버리는 데이터는 비용이다. 계속 확장되는 데이터셋은 자본이다. rebuttal이 끝난 뒤 잊힌 답변은 비용이다. 다음 논문의 설계 원칙으로 정리된 리뷰 경험은 자본이다.&lt;/p>
&lt;p>프로젝트가 끝날 때 다음 질문을 하라.&lt;/p>
&lt;ul>
&lt;li>다음 학생이 이 연구를 이어받는 데 며칠이 걸리는가.&lt;/li>
&lt;li>같은 실험을 다시 해야 하는가.&lt;/li>
&lt;li>코드와 데이터의 어느 부분을 다른 연구에도 사용할 수 있는가.&lt;/li>
&lt;li>이번에 알게 된 실패 조건이 기록되어 있는가.&lt;/li>
&lt;li>이 논문에서 파생되는 후속 질문이 명시되어 있는가.&lt;/li>
&lt;li>논문이 reject되더라도 남는 자산은 무엇인가.&lt;/li>
&lt;/ul>
&lt;p>좋은 연구 프로젝트는 accept 여부와 무관하게 연구자의 능력과 자산을 늘린다. 나쁜 프로젝트는 accept되더라도 다음 연구를 원점에서 다시 시작하게 만든다.&lt;/p>
&lt;hr>
&lt;h2 id="8-한-단계-위의-질문을-보는-연습을-하라">8. 한 단계 위의 질문을 보는 연습을 하라&lt;/h2>
&lt;p>시스템 사고를 훈련하는 가장 간단한 방법은 현재 작업에서 한 단계만 위로 올라가 보는 것이다.&lt;/p>
&lt;p>실험 중이라면 논문의 주장을 본다. 논문을 쓰고 있다면 연구 흐름을 본다. 여러 논문을 진행하고 있다면 연구 프로그램을 본다. 연구 프로그램을 이끌고 있다면 분야의 문제 정의를 본다.&lt;/p>
&lt;p>흐름은 다음과 같다.&lt;/p>
&lt;p>실험 → 주장 → 논문 → 연구 흐름 → 연구 프로그램 → 분야의 문제 정의&lt;/p>
&lt;p>모든 순간에 가장 위까지 올라갈 필요는 없다. 현재 위치에서 딱 한 단계만 확대해도 많은 오류를 피할 수 있다.&lt;/p>
&lt;p>실험을 하는 학생이 “이 결과가 논문의 어느 문장을 바꾸는가”라고 물으면 의미 없는 실험을 줄일 수 있다. 논문을 쓰는 학생이 “이 논문 뒤에 어떤 후속 연구가 자연스럽게 나와야 하는가”라고 물으면 일회성 아이디어와 연구 프로그램을 구분할 수 있다. 연구 프로그램을 보는 학생이 “우리가 계속 해결하는 공통된 긴장은 무엇인가”라고 물으면 자기 연구 정체성을 발견할 수 있다.&lt;/p>
&lt;p>예를 들어 “새로운 VPR 모델을 만든다”는 것은 프로젝트 수준의 표현이다. 한 단계 위에서는 “환경 변화에도 장소 정체성을 유지하는 표현은 무엇인가”라는 연구 질문이 된다. 더 위에서는 “로봇의 공간기억은 무엇을 보존하고 무엇을 잊어야 하는가”라는 프로그램이 될 수 있다.&lt;/p>
&lt;p>이렇게 올라가면 방법은 바뀌어도 연구 정체성은 유지된다. 특정 네트워크 구조나 유행하는 모델을 자기 정체성으로 삼으면 기술이 바뀔 때마다 커리어가 흔들린다. 반면 지속되는 문제와 긴장을 중심에 두면 새로운 기술을 흡수하면서도 누적된 전문성을 유지할 수 있다.&lt;/p>
&lt;p>매주 자신에게 한 번만 물어라.&lt;/p>
&lt;blockquote>
&lt;p>내가 지금 푸는 작은 문제의 바로 위에는 어떤 더 큰 문제가 있는가?&lt;/p>
&lt;/blockquote>
&lt;p>이 질문은 연구를 거창하게 만들기 위한 것이 아니다. 작은 작업이 큰 목적에서 이탈하지 않았는지 확인하기 위한 것이다.&lt;/p>
&lt;hr>
&lt;h2 id="9-지도교수의-답을-기다리는-학생에서-문제의-소유자로-이동하라">9. 지도교수의 답을 기다리는 학생에서 문제의 소유자로 이동하라&lt;/h2>
&lt;p>대학원 초기에 지도교수에게 의존하는 것은 자연스럽다. 분야를 모르고, 좋은 문제의 기준도 모르며, 실험 결과를 어떻게 해석해야 하는지도 익숙하지 않기 때문이다. 그러나 시간이 지나도 모든 중요한 결정을 교수에게 넘긴다면 독립 연구자로 성장하기 어렵다.&lt;/p>
&lt;p>자율성은 혼자 마음대로 연구하는 것이 아니다. 충분한 정보를 모으고, 선택지를 비교하고, 결과를 책임지는 능력이다.&lt;/p>
&lt;p>지도교수에게 다음과 같이 묻는 학생이 있다.&lt;/p>
&lt;p>“성능이 안 나옵니다. 어떻게 할까요?”&lt;/p>
&lt;p>이 질문은 상황의 해석과 다음 행동의 결정을 모두 교수에게 넘긴다.&lt;/p>
&lt;p>더 성숙한 보고는 다음 구조를 가진다.&lt;/p>
&lt;ul>
&lt;li>상황: 어떤 조건에서 예상과 다른 결과가 나왔다.&lt;/li>
&lt;li>증거: 로그와 대조 실험을 보면 원인 후보가 세 가지다.&lt;/li>
&lt;li>선택지: A는 빠르지만 근본 원인을 확인하지 못하고, B는 시간이 들지만 핵심 가설을 검증하며, C는 프로젝트 범위를 줄인다.&lt;/li>
&lt;li>근거: 현재 마감과 논문의 핵심 주장에 비추어 B가 가장 가치 있다.&lt;/li>
&lt;li>제안: 이틀 동안 B를 수행하고 특정 결과가 나오지 않으면 C로 전환하겠다.&lt;/li>
&lt;/ul>
&lt;p>이 학생도 조언을 구한다. 그러나 문제를 자신의 것으로 소유한 상태에서 조언을 구한다.&lt;/p>
&lt;p>좋은 연구실은 큰 방향과 품질 기준은 강하게 공유하고, 세부적인 방법은 학생이 자율적으로 결정하는 구조를 가진다. 이를 높은 정렬과 느슨한 결합이라고 볼 수 있다.&lt;/p>
&lt;p>높은 정렬은 다음을 공유하는 것이다.&lt;/p>
&lt;ul>
&lt;li>우리가 중요하다고 보는 문제&lt;/li>
&lt;li>받아들일 수 있는 증거의 수준&lt;/li>
&lt;li>연구윤리와 재현성의 기준&lt;/li>
&lt;li>현재 프로젝트의 우선순위&lt;/li>
&lt;li>장기적으로 축적하려는 연구 자산&lt;/li>
&lt;/ul>
&lt;p>느슨한 결합은 그 범위 안에서 학생이 구현, 실험, 일정, 세부 방법을 결정하는 것이다.&lt;/p>
&lt;p>학생의 목표는 교수에게 질문하지 않는 것이 아니다. 질문의 수준을 높이는 것이다. 처음에는 “무엇을 할까요”라고 묻는다. 다음에는 “A와 B 중 무엇이 좋을까요”라고 묻는다. 더 성장하면 “나는 근거 때문에 B를 선택했고, 이 조건에서만 결정을 다시 검토하겠다”고 말한다.&lt;/p>
&lt;p>독립 연구자는 모든 것을 혼자 아는 사람이 아니다. 불확실성 속에서도 합리적인 결정을 내리고, 틀렸을 때 빠르게 수정할 수 있는 사람이다.&lt;/p>
&lt;hr>
&lt;h2 id="10-실패를-숨기지-말고-재사용-가능한-지식으로-바꿔라">10. 실패를 숨기지 말고 재사용 가능한 지식으로 바꿔라&lt;/h2>
&lt;p>연구에서 실패는 예외가 아니라 기본 상태다. 대부분의 아이디어는 처음부터 잘 작동하지 않는다. 성능이 오르지 않고, 데이터가 부족하고, 실험 설계가 잘못되고, 논문이 reject된다.&lt;/p>
&lt;p>문제는 실패 자체가 아니다. 같은 종류의 실패가 지식으로 남지 않은 채 반복되는 것이다.&lt;/p>
&lt;p>실패했을 때 “더 열심히 하겠다”는 결론은 대개 충분하지 않다. 왜 실패했는지를 구조적으로 분류해야 한다.&lt;/p>
&lt;ul>
&lt;li>문제 정의가 틀렸는가.&lt;/li>
&lt;li>핵심 가설이 틀렸는가.&lt;/li>
&lt;li>구현이 잘못됐는가.&lt;/li>
&lt;li>데이터가 가설을 검증하기에 부족했는가.&lt;/li>
&lt;li>평가 지표가 원하는 현상을 측정하지 못했는가.&lt;/li>
&lt;li>비교 대상이 부적절했는가.&lt;/li>
&lt;li>일정과 자원 추정이 틀렸는가.&lt;/li>
&lt;li>이미 알려진 위험을 팀 안에서 전달하지 못했는가.&lt;/li>
&lt;/ul>
&lt;p>분류한 뒤에는 사람에게 “조심하라”고 말하는 대신 시스템을 고친다.&lt;/p>
&lt;p>baseline 오류가 반복되면 회의를 추가하기보다 regression test를 만든다. 데이터 split 실수가 있었다면 다음 학생에게 주의를 주는 데서 끝내지 않고 split 생성기를 고친다. 중요한 실험 설정이 사라졌다면 보고서를 더 자주 쓰게 하기보다 configuration과 결과를 자동 저장하게 한다. 인용 오류가 발생했다면 개인을 질책하는 데 그치지 않고 제출 전 citation audit를 표준화한다.&lt;/p>
&lt;p>좋은 회고는 책임을 없애지 않는다. 오히려 책임을 더 정확하게 만든다. 누가 잘못했는지를 찾는 대신 어떤 판단과 시스템이 실패를 허용했는지 본다.&lt;/p>
&lt;p>다음 형식으로 실패 기록을 남겨라.&lt;/p>
&lt;ol>
&lt;li>무엇을 기대했는가.&lt;/li>
&lt;li>실제로 무엇이 일어났는가.&lt;/li>
&lt;li>어떤 증거로 원인을 판단했는가.&lt;/li>
&lt;li>다음에는 무엇을 다르게 할 것인가.&lt;/li>
&lt;li>코드, 데이터, 절차 중 무엇을 바꾸었는가.&lt;/li>
&lt;li>이 실패가 이후의 문제 선택에 주는 교훈은 무엇인가.&lt;/li>
&lt;/ol>
&lt;p>이 기록이 쌓이면 실패는 시간의 손실이 아니라 연구 자본이 된다.&lt;/p>
&lt;blockquote>
&lt;p>좋은 연구자는 실패하지 않는 사람이 아니라, 같은 실패에 두 번 같은 값을 지불하지 않는 사람이다.&lt;/p>
&lt;/blockquote>
&lt;hr>
&lt;h2 id="11-연구의-최종-고객을-reviewer로-착각하지-마라">11. 연구의 최종 고객을 reviewer로 착각하지 마라&lt;/h2>
&lt;p>논문을 쓰다 보면 reviewer가 세계의 중심처럼 느껴진다. 어떤 실험을 추가할지, 어떤 표현을 피할지, 어떤 결과를 강조할지가 모두 심사를 통과하는 데 맞춰진다. 마감과 심사 과정에서는 어느 정도 불가피하다.&lt;/p>
&lt;p>하지만 reviewer는 연구의 최종 고객이 아니다. reviewer는 출판이라는 관문에서 최소 품질과 기여를 판단하는 사람이다. 진짜 사용자는 논문을 읽고, 재현하고, 인용하고, 가르치고, 실제 시스템에 적용하며, 후속 질문을 만드는 연구 공동체와 현장이다.&lt;/p>
&lt;p>reviewer만 만족시키려는 논문은 채택될 수는 있어도 오래 살아남기 어렵다. 반대로 사용자의 실제 문제를 정확히 풀고 재사용 가능한 자산을 남긴 연구는 한 번의 심사 결과를 넘어 영향력을 축적할 가능성이 크다.&lt;/p>
&lt;p>연구의 최종 가치를 볼 때 다음 질문을 하라.&lt;/p>
&lt;ul>
&lt;li>다른 연구자가 이 논문을 읽고 무엇을 새롭게 할 수 있는가.&lt;/li>
&lt;li>이 논문이 문제를 보는 언어나 기준을 바꾸는가.&lt;/li>
&lt;li>코드, 데이터, 지표, 개념 중 무엇을 가져다 쓸 수 있는가.&lt;/li>
&lt;li>후속 연구를 촉발할 긴장이나 열린 문제가 있는가.&lt;/li>
&lt;li>이 연구가 없어진다면 분야가 실제로 무언가를 잃는가.&lt;/li>
&lt;/ul>
&lt;p>좋은 연구는 단순히 “사람들이 좋아하는” 연구가 아니다. 사람들이 자기 연구를 진행하기 위해 사용하게 되는 연구다.&lt;/p>
&lt;p>인용은 완벽한 가치 측정값이 아니다. 유행, 분야 규모, 저자 네트워크의 영향을 받는다. 그러나 다른 연구가 계속 이 결과를 참조하고 사용한다는 것은 연구가 공동체의 작업 구조 안으로 들어갔다는 신호다. 연구의 목적을 인용 수 자체로 축소할 필요는 없지만, 논문이 다른 사람의 사고와 행동을 어떻게 바꿀지는 처음부터 고민해야 한다.&lt;/p>
&lt;hr>
&lt;h2 id="12-대학원생의-keeper-test">12. 대학원생의 Keeper Test&lt;/h2>
&lt;p>Netflix의 Keeper Test를 연구커리어에 적용하면, 지금 하는 일을 계속 붙들어야 할지 판단하는 강력한 질문이 된다.&lt;/p>
&lt;h3 id="프로젝트-테스트">프로젝트 테스트&lt;/h3>
&lt;p>지금까지 알게 된 모든 사실을 시작 전에 알고 있었다면 그래도 이 프로젝트를 시작했을까?&lt;/p>
&lt;p>대답이 아니오라면 이미 쓴 시간이 아까워 계속하는 것은 아닌지 살펴야 한다. 이미 투입한 비용은 미래의 정당화가 될 수 없다.&lt;/p>
&lt;h3 id="연구방향-테스트">연구방향 테스트&lt;/h3>
&lt;p>이 주제가 내 연구 포트폴리오에서 사라진다면 되찾기 위해 노력할까?&lt;/p>
&lt;p>사라졌을 때 오히려 홀가분할 것 같다면, 그 방향은 연구 정체성의 중심이 아닐 수 있다.&lt;/p>
&lt;h3 id="역량-테스트">역량 테스트&lt;/h3>
&lt;p>내가 가진 이 능력을 잃는다면 동료들이 아쉬워할까?&lt;/p>
&lt;p>아무도 의존하지 않는 능력은 커리어의 핵심 자산이 아닐 수 있다. 반대로 사람들이 반복해서 찾아오는 판단과 능력은 더 깊게 투자할 가치가 있다.&lt;/p>
&lt;h3 id="협업-테스트">협업 테스트&lt;/h3>
&lt;p>지금 아는 것을 알고도 이 사람과 다시 공동연구를 시작할까?&lt;/p>
&lt;p>협업은 논문 수만이 아니라 신뢰, 속도, 학습, 장기적 선택지를 만든다. 관계 역시 포트폴리오로 관리해야 한다.&lt;/p>
&lt;h3 id="정체성-테스트">정체성 테스트&lt;/h3>
&lt;p>내 논문들의 제목과 사용한 모델 이름을 가려도, 다른 사람이 왜 이 연구들이 한 사람에게서 나왔는지 설명할 수 있을까?&lt;/p>
&lt;p>설명할 수 없다면 성과는 쌓였지만 연구 정체성은 쌓이지 않은 것이다.&lt;/p>
&lt;p>이 테스트는 프로젝트를 냉정하게 버리기 위해서만 쓰는 것이 아니다. 정말 지켜야 할 연구, 역량, 관계를 찾아 더 많은 자원을 투입하기 위해 쓴다.&lt;/p>
&lt;p>분기마다 한 번씩 현재 프로젝트를 세 가지로 나누어보라.&lt;/p>
&lt;ul>
&lt;li>계속 키울 것&lt;/li>
&lt;li>조건부로 검증할 것&lt;/li>
&lt;li>정리하고 자산만 회수할 것&lt;/li>
&lt;/ul>
&lt;p>모든 프로젝트를 끝까지 끌고 가는 것은 끈기가 아니다. 때로는 선택을 미루는 것이다. 좋은 연구커리어는 무엇을 시작할지뿐 아니라 무엇을 중단하고 무엇을 남길지를 잘 결정하면서 만들어진다.&lt;/p>
&lt;hr>
&lt;h2 id="13-학년이-올라갈수록-달라져야-하는-것은-작업-난도가-아니라-책임의-범위다">13. 학년이 올라갈수록 달라져야 하는 것은 작업 난도가 아니라 책임의 범위다&lt;/h2>
&lt;p>대학원생의 성장은 더 어려운 코드를 작성하거나 더 큰 모델을 다루는 것으로만 측정할 수 없다. 학년이 올라갈수록 책임지는 범위가 넓어져야 한다.&lt;/p>
&lt;h3 id="초기-단계-정확하게-재현하는-사람">초기 단계: 정확하게 재현하는 사람&lt;/h3>
&lt;p>처음에는 분야의 언어와 기준을 배운다. 중요한 논문을 읽고, baseline을 재현하고, 데이터와 평가체계를 이해한다. 이때의 핵심은 독창성보다 정확성이다.&lt;/p>
&lt;ul>
&lt;li>결과를 재현할 수 있는가.&lt;/li>
&lt;li>논문의 주장과 코드의 실제 동작을 구분할 수 있는가.&lt;/li>
&lt;li>실패했을 때 원인을 추적할 수 있는가.&lt;/li>
&lt;li>실험 조건을 다른 사람이 이해할 수 있게 기록하는가.&lt;/li>
&lt;/ul>
&lt;h3 id="중간-단계-가설을-소유하는-사람">중간 단계: 가설을 소유하는 사람&lt;/h3>
&lt;p>다음에는 주어진 작업이 아니라 가설을 책임진다. 무엇을 비교해야 하는지, 어떤 결과가 주장을 지지하거나 반박하는지 스스로 결정한다.&lt;/p>
&lt;ul>
&lt;li>핵심 연구 질문을 한 문장으로 말할 수 있는가.&lt;/li>
&lt;li>가장 작은 반증 실험을 설계할 수 있는가.&lt;/li>
&lt;li>결과가 나쁘더라도 무엇을 배웠는지 설명할 수 있는가.&lt;/li>
&lt;li>지도교수에게 선택지와 제안을 함께 가져가는가.&lt;/li>
&lt;/ul>
&lt;h3 id="고급-단계-연구-프로그램을-만드는-사람">고급 단계: 연구 프로그램을 만드는 사람&lt;/h3>
&lt;p>박사과정 후반에는 한 편의 논문을 넘어 여러 프로젝트의 연결을 봐야 한다. 후배가 사용할 자산을 만들고, 공동연구를 설계하고, 분야의 빈 공간을 발견한다.&lt;/p>
&lt;ul>
&lt;li>여러 논문을 관통하는 질문이 있는가.&lt;/li>
&lt;li>자신의 연구가 다음 연구를 더 쉽게 만드는가.&lt;/li>
&lt;li>후배가 같은 실패를 반복하지 않도록 시스템을 남기는가.&lt;/li>
&lt;li>어떤 문제를 풀지 스스로 선택하고 자원을 배분할 수 있는가.&lt;/li>
&lt;li>다른 연구자가 자신의 프레임과 자산을 사용하게 만드는가.&lt;/li>
&lt;/ul>
&lt;p>좋은 박사 졸업생은 지도를 받지 않아도 코딩할 수 있는 사람이 아니다. 새로운 환경에서도 중요한 문제를 찾고, 증거를 만들고, 사람과 자원을 조직하며, 지속적으로 연구를 생산할 수 있는 사람이다.&lt;/p>
&lt;hr>
&lt;h2 id="14-매주-실행할-수-있는-연구-시스템">14. 매주 실행할 수 있는 연구 시스템&lt;/h2>
&lt;p>시스템 사고는 철학으로만 남기면 아무 소용이 없다. 주간 업무에 들어가야 한다.&lt;/p>
&lt;h3 id="주초-문제와-결정">주초: 문제와 결정&lt;/h3>
&lt;p>이번 주에 줄여야 할 가장 중요한 불확실성을 하나 정한다.&lt;/p>
&lt;p>“모델을 개선한다”는 목표는 너무 모호하다. “성능 저하의 원인이 feature 표현인지 data association인지 구분한다”처럼 결정 가능한 질문으로 바꾼다.&lt;/p>
&lt;p>주초에는 다음을 적는다.&lt;/p>
&lt;ul>
&lt;li>현재 가장 큰 불확실성&lt;/li>
&lt;li>가능한 원인&lt;/li>
&lt;li>이를 구분할 최소 실험&lt;/li>
&lt;li>결과별 다음 행동&lt;/li>
&lt;li>이번 주에 하지 않을 일&lt;/li>
&lt;/ul>
&lt;h3 id="주중-증거와-기록">주중: 증거와 기록&lt;/h3>
&lt;p>실험을 많이 돌리는 것보다 결정에 필요한 실험을 돌린다. 설정, 코드 버전, 데이터 split, 결과를 자동으로 기록한다. 예상과 다른 결과가 나오면 숨기지 않고 별도의 단서로 다룬다.&lt;/p>
&lt;p>실험마다 다음 문장을 채운다.&lt;/p>
&lt;blockquote>
&lt;p>이 실험은 ______라는 가설을 검증하며, ______가 나오면 다음에는 ______를 한다.&lt;/p>
&lt;/blockquote>
&lt;p>이 문장을 채울 수 없다면 목적 없는 실험일 가능성이 높다.&lt;/p>
&lt;h3 id="주말-성과와-자산">주말: 성과와 자산&lt;/h3>
&lt;p>한 주가 끝나면 작업 목록이 아니라 학습 목록을 정리한다.&lt;/p>
&lt;ul>
&lt;li>무엇을 새롭게 알았는가.&lt;/li>
&lt;li>무엇이 틀렸다고 판명됐는가.&lt;/li>
&lt;li>아직 남은 가장 큰 불확실성은 무엇인가.&lt;/li>
&lt;li>다음 주 의사결정은 무엇인가.&lt;/li>
&lt;li>재사용할 코드, 데이터, 문서는 무엇을 남겼는가.&lt;/li>
&lt;/ul>
&lt;p>주간 보고의 마지막 줄에는 다음 질문에 답한다.&lt;/p>
&lt;blockquote>
&lt;p>이번 주의 연구로 다음 주의 연구가 어떻게 더 싸고 정확해졌는가?&lt;/p>
&lt;/blockquote>
&lt;p>답이 없다면 자산화가 빠진 것이다.&lt;/p>
&lt;hr>
&lt;h2 id="15-지도교수-미팅을-의사결정-회의로-바꿔라">15. 지도교수 미팅을 의사결정 회의로 바꿔라&lt;/h2>
&lt;p>많은 학생이 미팅을 자신이 열심히 일했다는 것을 증명하는 자리로 사용한다. 실험 그래프를 많이 보여주고, 읽은 논문 수와 시도한 방법을 나열한다. 그러나 좋은 연구 미팅은 활동 보고회가 아니라 불확실성을 줄이고 다음 결정을 내리는 자리다.&lt;/p>
&lt;p>미팅 자료를 다음 순서로 구성해보라.&lt;/p>
&lt;h3 id="상황">상황&lt;/h3>
&lt;p>현재 프로젝트가 어디에 있으며 무엇이 막혀 있는지 세 문장으로 설명한다.&lt;/p>
&lt;h3 id="핵심-증거">핵심 증거&lt;/h3>
&lt;p>결정에 필요한 결과만 보여준다. 모든 로그를 넣지 않는다. 무엇을 보여주지 않았는지도 스스로 판단한다.&lt;/p>
&lt;h3 id="해석">해석&lt;/h3>
&lt;p>결과가 무엇을 의미하고 무엇을 의미하지 않는지 구분한다. 관찰과 추론을 섞지 않는다.&lt;/p>
&lt;h3 id="선택지">선택지&lt;/h3>
&lt;p>다음 행동을 두세 개로 정리하고 각각의 비용, 기대 정보, 위험을 비교한다.&lt;/p>
&lt;h3 id="제안">제안&lt;/h3>
&lt;p>자신이 추천하는 선택과 근거를 말한다. 어떤 결과가 나오면 결정을 바꿀지도 명시한다.&lt;/p>
&lt;p>이 구조는 지도교수가 학생 대신 문제를 풀어주는 시간을 줄이고, 학생의 판단을 교정하는 시간을 늘린다. 좋은 지도는 답을 받는 것이 아니라 판단 기준을 배우는 과정이다.&lt;/p>
&lt;hr>
&lt;h2 id="16-연구자의-진짜-생산성은-복리로-측정해야-한다">16. 연구자의 진짜 생산성은 복리로 측정해야 한다&lt;/h2>
&lt;p>하루에 몇 시간 일했는지, 실험을 몇 번 돌렸는지, 논문을 몇 편 냈는지는 모두 중요한 정보다. 그러나 장기적인 연구 생산성을 완전히 설명하지는 못한다.&lt;/p>
&lt;p>연구자의 진짜 생산성은 시간이 지날수록 같은 노력으로 더 크고 정확한 문제를 풀 수 있게 되는가로 측정해야 한다.&lt;/p>
&lt;p>첫 번째 논문에서 데이터 수집기를 만들었다면 두 번째 논문은 데이터 수집에 쓰는 시간이 줄어야 한다. 첫 번째 rebuttal에서 평가의 약점을 배웠다면 다음 논문은 처음부터 더 강한 평가를 설계해야 한다. 한 분야의 문헌 지도를 만들었다면 다음 아이디어의 novelty를 판단하는 시간이 짧아져야 한다. 공동연구에서 신뢰를 쌓았다면 더 어려운 문제에 접근할 수 있어야 한다.&lt;/p>
&lt;p>이것이 연구의 복리다.&lt;/p>
&lt;p>복리가 생기는 연구자는 시간이 흐를수록 다음과 같은 변화를 보인다.&lt;/p>
&lt;ul>
&lt;li>문제 선택이 빨라진다.&lt;/li>
&lt;li>가능성 없는 방향을 일찍 중단한다.&lt;/li>
&lt;li>첫 실험부터 더 많은 정보를 얻는다.&lt;/li>
&lt;li>반복되는 작업이 자동화된다.&lt;/li>
&lt;li>논문의 주장이 더 선명해진다.&lt;/li>
&lt;li>강한 공동연구자가 모인다.&lt;/li>
&lt;li>새로운 프로젝트가 기존 자산 위에서 시작된다.&lt;/li>
&lt;li>연구들이 하나의 정체성으로 묶인다.&lt;/li>
&lt;/ul>
&lt;p>반대로 매 프로젝트를 완전히 새로운 코드, 데이터, 문제, 공동연구자로 시작하면 논문은 늘어도 복리는 생기지 않는다. 새로운 분야를 탐색하지 말라는 뜻이 아니다. 탐색하더라도 기존 자산과 어떤 연결이 생기는지 의식하라는 뜻이다.&lt;/p>
&lt;p>연구커리어를 길게 보면 가장 중요한 질문은 “이번 논문이 accept될까” 하나가 아니다.&lt;/p>
&lt;blockquote>
&lt;p>이 프로젝트가 끝났을 때 나는 다음 프로젝트를 더 잘 선택하고 더 싸게 검증하며 더 강하게 설명할 수 있는 연구자가 되어 있는가?&lt;/p>
&lt;/blockquote>
&lt;hr>
&lt;h2 id="맺음말-좋은-연구자가-된다는-것">맺음말: 좋은 연구자가 된다는 것&lt;/h2>
&lt;p>AI 시대에는 더 많은 사람이 더 빠르게 코드를 만들고, 논문을 요약하고, 실험 결과를 정리할 수 있다. 이 변화는 대학원생에게 위협이면서 동시에 기회다.&lt;/p>
&lt;p>표면적인 작업만으로 차별화하려 했다면 위협이다. 그러나 연구의 본질에 더 가까이 갈 준비가 되어 있다면 기회다. 반복 작업에 쓰던 시간을 문제를 이해하고, 증거를 검증하고, 실패를 해석하고, 연구 자산을 만드는 데 사용할 수 있기 때문이다.&lt;/p>
&lt;p>앞으로 희소해지는 것은 결과물을 만들어내는 손이 아니다. 다음이 희소해진다.&lt;/p>
&lt;ul>
&lt;li>중요한 문제를 알아보는 안목&lt;/li>
&lt;li>가설을 반증 가능한 형태로 만드는 능력&lt;/li>
&lt;li>결과를 믿어도 되는지 판단하는 전문성&lt;/li>
&lt;li>실패를 다음 연구의 자산으로 바꾸는 습관&lt;/li>
&lt;li>여러 프로젝트를 하나의 연구 프로그램으로 묶는 시야&lt;/li>
&lt;li>다른 사람도 좋은 연구를 하게 만드는 시스템&lt;/li>
&lt;li>기술의 유행이 바뀌어도 유지되는 연구 정체성&lt;/li>
&lt;/ul>
&lt;p>대학원생은 처음에는 주어진 일을 정확히 수행하는 사람으로 시작한다. 그러나 거기에 머물러서는 안 된다. 작업의 수행자에서 가설의 소유자로, 가설의 소유자에서 연구 자산의 설계자로, 연구 자산의 설계자에서 연구 프로그램을 만드는 사람으로 성장해야 한다.&lt;/p>
&lt;p>논문 한 편을 잘 쓰는 것은 중요하다. 하지만 더 긴 커리어에서 진짜 경쟁력은 좋은 논문을 우연히 한 번 만드는 데 있지 않다. 무엇을 연구할지 판단하고, 어떤 결과를 믿을지 검증하며, 한 번의 노력이 다음 연구의 비용을 낮추게 하고, 여러 사람과 여러 프로젝트가 장기적으로 복리 성장하도록 만드는 데 있다.&lt;/p>
&lt;p>그러므로 프로젝트가 끝날 때 논문 파일만 남아 있는지 보지 마라. 더 좋은 질문, 더 정확한 판단, 더 강한 코드, 더 믿을 만한 데이터, 더 분명한 연구 정체성, 더 나은 다음 선택이 남아 있는지 보라.&lt;/p>
&lt;p>그것들이 남았다면 논문의 심사 결과와 무관하게 연구자로서 전진한 것이다.&lt;/p>
&lt;blockquote>
&lt;p>논문은 연구자의 결과물이다. 그러나 좋은 연구가 반복해서 나오게 만드는 시스템은 연구자 자신이다.&lt;/p>
&lt;/blockquote>
&lt;hr>
&lt;h2 id="이-강의를-읽고-스스로-답해볼-질문">이 강의를 읽고 스스로 답해볼 질문&lt;/h2>
&lt;ol>
&lt;li>나는 지금 산출물, 성과, 자산 중 무엇을 가장 많이 만들고 있는가.&lt;/li>
&lt;li>현재 프로젝트의 가장 큰 불확실성은 무엇인가.&lt;/li>
&lt;li>어떤 결과가 나오면 지금의 가설을 포기할 것인가.&lt;/li>
&lt;li>내가 반복해서 수작업으로 수행하는 일 중 무엇을 시스템화할 수 있는가.&lt;/li>
&lt;li>이번 프로젝트가 끝난 뒤 다음 학생이 사용할 수 있는 것은 무엇인가.&lt;/li>
&lt;li>AI가 만든 결과 가운데 내가 아직 검증하지 않은 것은 무엇인가.&lt;/li>
&lt;li>다른 연구자들이 어떤 판단이 필요할 때 나를 찾게 만들 것인가.&lt;/li>
&lt;li>지금 하는 실험의 한 단계 위 질문은 무엇인가.&lt;/li>
&lt;li>내 논문들을 관통하는 공통된 문제나 긴장은 무엇인가.&lt;/li>
&lt;li>지금까지 알게 된 사실을 처음부터 알았어도 이 프로젝트를 시작했을까.&lt;/li>
&lt;li>이번 주 연구가 다음 주 연구를 어떻게 더 싸고 정확하게 만들었는가.&lt;/li>
&lt;li>내가 졸업할 때 남길 것은 논문 목록뿐인가, 아니면 계속 작동하는 연구 시스템인가.&lt;/li>
&lt;/ol>
&lt;hr>
&lt;h2 id="바탕이-된-글">바탕이 된 글&lt;/h2>
&lt;ul>
&lt;li>&lt;a href="https://www.youtube.com/watch?v=t0GiTyz4syY&amp;amp;vl=en-US" target="_blank" rel="noopener">Why Netflix is betting on systems thinkers—not specialists—in the AI era | Elizabeth Stone (CPTO)&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://news.hada.io/topic?id=32159" target="_blank" rel="noopener">Netflix가 AI 시대에 전문가보다 시스템 사고형 인재에 베팅하는 이유&lt;/a>&lt;/li>
&lt;/ul></description></item></channel></rss>