머신러닝 연구의 선과 예술

1 hour ago 1

세계적 수준의 AI 연구는 재능만으로 이어지지 않으며, 읽기와 만들기를 반복하면서 오래 버티는 기질이 성과를 가름함
주제 선택은 6개월짜리 유행어보다 cross-entropy, SVD, policy gradients 같은 기초 개념을 깊게 이해하는 데서 출발해야 함
좋은 연구는 기존 벤치마크 점수 상승에 머물지 않고, 새 방법이 실제로 드러내는 능력을 시험할 데이터셋까지 찾아야 함
실험 결과는 좋든 나쁘든 정보를 주지만, 너무 좋아 보이는 결과일수록 버그나 잘못된 측정일 수 있어 건강한 편집증이 필요함
코딩 에이전트는 속도를 높이는 동시에 시스템 이해 부족과 컨텍스트 전환을 키우므로, 결과를 만든 전체 시스템을 직접 이해해야 함

연구자가 되는 출발점

AI 연구는 읽기와 학습, 그리고 무언가를 직접 만드는 일을 함께 반복하면서 시작됨
둘 중 하나만으로는 부족하며, 연구자는 이 두 활동을 오가며 만들어짐
연구는 명상과 비슷해서 통찰이 오는 날에도 앉고, 오지 않는 날에도 계속 앉아 있어야 함
과학적 통찰은 무작위처럼 찾아오며, 대부분의 날에는 오지 않음
음악, 스포츠, 영업처럼 세계적 수준에 도달하려면 많은 시간과 노력, 큰 훈련량이 필요함
SwiGLU 논문에서 Noam Shazeer는 “이 구조가 왜 작동하는지 설명하지 않으며, 그 성공을 다른 모든 것처럼 신의 자비에 돌린다”고 적어 연구 아이디어 성공의 무작위성을 드러냄
논문을 너무 많이 읽는 것도 문제가 될 수 있음
- 먼저 해법을 시도하고, 막히고, 직접 해결해 본 뒤, 자기 아이디어가 바닥났을 때 문헌을 찾는 방식이 검증된 길임

무엇을 연구할 것인가

처음 시작한다면 정확한 연구 주제 자체는 크게 중요하지 않음
다만 유행한 지 6개월도 안 된 주제를 고르는 일은 피하는 편이 좋음
- AI는 빠르게 움직이지만 근본 아이디어는 40년 동안 크게 바뀌지 않았음
- 2026년의 harnesses, agents, context engineering 같은 개념에 커리어를 지나치게 걸어서는 안 됨
더 많이 배우려면 기초로 돌아가야 함
- cross-entropy가 무엇인지 배우고, 작은 분포에 대해 손으로 계산해 봐야 함
- SVD를 머릿속에서 시각화할 수 있을 정도로 깊이 이해해야 함
- 코딩용 RL만 보지 말고 policy gradients의 아이디어, 유용성, 수십 년 동안 인기가 있었던 이유를 배워야 함
연구 프로젝트의 최선의 결과가 기존 벤치마크 점수 상승뿐이라면 충분히 깊지 않음
- 기존 데이터셋은 새롭고 흥미로운 능력을 시험하지 못하는 경우가 많음
- Jason Wei는 새 방법이 실제로 작동하는 능력을 행사하게 만드는 데이터셋을 찾는 일을 AI 연구에서 과소평가됐지만 성패를 가를 수 있는 기술로 봄
구체적인 주제는 스스로 찾아야 하며, 깊게 들어가고 기초에 집중하며 벤치마크 추격에 갇히지 않아야 함

초심과 열린 판단

“초심자의 마음에는 많은 가능성이 있고, 전문가의 마음에는 적다”는 Suzuki의 말은 연구에도 적용됨
현대 AI 연구에서는 기존 AI 연구 경험이 좋은 연구 직관에 오히려 역효과를 낼 수 있다는 말이 Silicon Valley에서 자주 반복됨
pre-scaling 시대 연구자 중 일부는 작은 규모에서는 작동하지만 규모를 키우면 실패할 방법을 설계하는 데 계속 관심을 둠
OpenAI에서 기술 측면으로 회사를 운영하는 다수는 35세 미만이며, ChatGPT의 중요한 의사결정자 중 다수는 30세 미만임
ChatGPT가 나온 지 4년도 되지 않은 초기 분야라서, 아무도 아주 오래 일해 온 압도적 우위를 갖고 있지 않음
아이디어를 너무 오래 붙잡으면 역효과가 날 수 있으므로, 열린 마음을 유지하고 자아가 판단을 흐리지 않게 해야 함

영감은 연구 밖에서도 온다

영감은 예상하지 못한 순간에 찾아옴
benzene ring 구조의 발견은 꿈에서 나온 것으로 유명함
- 이전에 본 적 없는 구조였지만, 자기 꼬리를 문 뱀의 이미지로 상상됨
Ozempic은 도마뱀에서 비롯된 사례임
- Ozempic이 모방하는 GLP-1 호르몬은 1년에 몇 번만 먹는 사막 도마뱀 Gila monster의 독에서 처음 발견됨
- 이 발견은 인간에게도 작동하는 방식으로 이어짐
좋은 연구를 하려면 연구가 아닌 일도 해야 함
많은 “아하” 순간은 키보드 앞이 아니라, 특히 산책 중에 일어남
Darwin, Tesla, Feynman, Aristotle 같은 사상가들은 다리를 펴고 조금 걷는 일의 큰 이점을 말했음

실험 결과를 대하는 태도

완벽하게 구현했더라도 아이디어가 근본적으로 참이 아닐 수 있음
실험을 분석할 때는 잘된 결과와 안 된 결과를 모두 좋은 것으로 받아들이는 실험적 평정심이 필요함
두 결과 모두 같은 양의 정보를 줌
- 하나의 긍정 결과보다 연속된 부정 결과에서 더 많이 배울 수도 있음
좋은 결과에 지나치게 흥분하지 않아야 함
- 좋은 결과의 상당수는 버그 때문에 나옴
- 결과가 실제로 좋은 것이 아니라 잘못 측정됐고, 스스로를 설득한 경우일 수 있음
자기 아이디어가 작동하길 바라는 마음은 자연스럽지만, 경험 많은 연구자들은 특히 너무 좋아 보이는 결과 앞에서 강한 회의감을 공유함
너무 좋아 보이는 결과는 거의 항상 실제와 다름

비교, 운, 깊이

연구는 결과 중심성이 매우 강함
특히 학계에서는 다른 사람의 논문상 성공을 보고 감정적으로 흔들리기 쉬움
사람들은 서로 다른 이유로 성공함
- 일부는 운이 좋음
- 학술 리뷰 과정은 일관적이지도 공정하지도 않음
자기 분야에서 감탄할 만한 새 연구가 나왔을 때는 “내가 이 통찰을 직접 만들 수 있을 정도의 깊이에서 작업하고 있었는가?”를 물어야 함
- 답이 “예”라면 과정은 제대로였지만 다른 일을 하느라 그 발견을 하지 못한 것임
- 답이 “아니오”라면 더 깊이 들어갈 동기로 삼아야 함

보이지 않는 반복 작업

깨달음 전에도 나무를 패고 물을 긷고, 깨달음 후에도 나무를 패고 물을 긷는다는 말처럼 연구에도 반복 작업이 많음
성공한 프로젝트 다수에는 뒤에서 수백 시간의 잡무성 작업이 들어감
Andrej Karpathy는 ImageNet의 상당 부분을 손으로 라벨링했음
SWEBench 제작자들은 평가에 유용한 작고 다루기 쉬운 GitHub 이슈 집합을 만들기 위해 GitHub 데이터를 수백 시간 동안 세심하게 필터링함
위대한 연구자들의 커리어를 보면 성공 전에 오랫동안 보이지 않는 곳에서 일한 시간이 많음
야심 있고 미래지향적인 아이디어일수록 철저한 구현과 평가에 더 많은 작업이 필요할 수 있으며, 이 어려움은 결함이 아니라 특징임

버그를 의심하는 연구 습관

Collin Raffel은 많은 아이디어가 나쁜 아이디어라서가 아니라 연구자가 찾지 못한 코드 버그 때문에 실패한다고 봄
LLM 세계에서는 이 문제가 특히 어려움
현대 딥러닝 소프트웨어 스택은 매우 복잡하며 버그는 어디에나 있을 수 있음
- 학습
- 추론
- 하네스
- 데이터
무언가 잘못돼 보이면 그냥 넘어가면 안 됨
많은 지표를 로깅하고 모두 이해하려고 해야 함
일부 지표가 예상과 다르면 이유를 찾아야 하며, 실제로 무언가 잘못됐을 수 있음
연구자에게 중요한 특성 중 하나는 건강한 편집증임

빠른 피드백과 컨텍스트 전환

딥러닝 실험 대부분은 너무 오래 걸림
- 모델 학습은 몇 주 또는 몇 달이 걸릴 수 있음
- 단일 작업에서 모델을 평가하는 데도 며칠이 걸릴 수 있음
에이전트로 코딩할 때는 여러 실험을 병렬로 띄우고 느린 주기로 실행하고 싶어질 수 있음
단순 병렬화는 어느 정도 도움이 되지만, 컨텍스트 전환은 해로운 패턴임
빠른 실험 피드백을 지원하는 인체공학적 연구 워크플로를 설계해야 함
- 학습의 콜드 스타트 시간을 줄여야 함
- 빠르게 결과를 반환하는 작은 평가를 만들어야 함
Keller Jordan의 nanoGPT speedrun은 빠른 반복 주기에서 얼마나 많이 배울 수 있는지 보여주는 사례임
일부 결과는 결국 피할 수 없이 오래 걸림
- 여러 날에 걸쳐 상태를 유지하고, 오늘 끝난 지난주 실험을 이해하는 능력은 매우 유용함

코딩 에이전트가 악화시키는 문제

코딩 에이전트는 더 빠르게 움직이게 해주지만 두 가지 문제를 악화시킴
- 기본 세부사항을 이해하기 어려워짐
- 컨텍스트 전환이 더 잦아짐
좋은 연구자는 두 힘에 맞서 적극적으로 일해야 함
Codex는 학습 스크립트를 작성하고, 실행하고, 실행 중 지켜보고, 결과를 해석하고, 이메일로 보낼 수 있음
하지만 다음 같은 작은 오류가 생길 수 있음
- 오류가 나자 묻지 않고 system prompt를 줄임
- 평가가 합리적인 시간 안에 돌도록 sequence length를 줄임
- 사용자가 명시하지 않아 잘못된 config를 실행함
엔지니어링 관점에서는 쉽게 고칠 작은 오류일 수 있지만, 과학 관점에서는 중대함
- 작은 누락도 논문의 중요한 결과를 물질적으로 바꿀 수 있음
- 따라서 허용될 수 없음
직접 코드를 쓰지 않았더라도 결과를 이해하려면 그 결과를 만든 시스템을 이해해야 함
좋은 과학에는 전체 시스템이 어떻게 작동하는지 배우는 일이 필요하며, 그래야 관찰이 참이라고 확신할 수 있음