Engineering
코드를 거의 타이핑하지 않고 3주 만에 DL모델 만들기
Whale여기어때
2026년 8월 12일
원문에서 보기 ↗글. 이철우(Whale) / 랭킹추천개발팀
여기어때 랭킹추천개발팀에서 랭킹추천개발을 하고 있는 웨일입니다.
이번 내용은 최근 3주 동안 검색용 DL 모델학습을 어떻게 작업했냐에 대한 이야기를 하려고 합니다.
학습 코드도, 평가 코드도, 데이터 생성 스크립트도 제가 한 줄씩 타이핑하지 않았습니다. 대부분 에이전트가 쓰고 저는 읽고 고쳤습니다.
혼자였고, GPU 서버는 한 대였고, 학습 한 번에 3시간이 걸렸습니다. 그 3주를 어떻게 굴렸는지에 대한 글입니다.
정답은 아닐 겁니다. 더 좋은 방법도 많을 거고요. 3주 동안 이렇게 굴려봤더니 잘 맞았던 것들을 공유드립니다.
“AI-Native 학습”이 남 얘기가 아니었다
최근 이 인터뷰를 봤습니다.
📺 High School Dropout to OpenAI Researcher — Gabriel Petersson Interview
고등학교 중퇴. 엔지니어링 경험 없음. 지금은 OpenAI 연구원.
① 원리부터가 아니라, 문제부터 시작해 원리로 거슬러 올라간다. 이번 실험이 그랬습니다. 이론을 다 알고 시작하지 않았습니다. 안 되는 이유를 쫓다가 알게 됐습니다.
② 중요한 건 지식의 양이 아니라, 자기 빈틈을 알아채고 그걸 AI와 함께 메우는 능력이다. 3주 내내 이게 제일 중요했습니다.
③ 결국 루프를 몇 번 돌렸느냐다. 가설 → 실험 → 확인. 몇 바퀴 돌았는지가 결과를 만듭니다. 그래서 한 바퀴에 걸리는 시간을 줄이는 게 전부입니다.
1. 명령은 에이전트가 만들고, 실행은 내가 한다
로컬에서 코드 수정 → 서버에 옮기고 → 실행 → 에러
↓
검색하고, 문서 뒤지고, 고쳐서 다시 올리고
에러 하나에 30분씩 날아갑니다. 대부분은 환경 문제였습니다. 모델이 아니라 도커 옵션, 경로, 권한 같은 것들요.
나: "이 설정으로 학습 돌리는 명령 만들어줘"
→ 에이전트가 실행할 명령을 뱉음
→ 내가 복사해서 서버 터미널에 붙여넣고 실행
→ 로그를 그대로 복사해서 다시 에이전트에게
→ 원인 분석과 수정된 명령
서버에 손을 대는 건 끝까지 사람입니다. 에이전트는 명령을 만들고 로그를 읽을 뿐, 실행 버튼은 제가 누릅니다.
- 실행은 사람이 한다. 에이전트에 서버 접근 권한이 필요 없고, 뭐가 돌아가는지 항상 압니다.
- 로그는 요약하지 말고 원문 그대로 준다. 사람이 추려서 주면 정작 중요한 단서가 빠집니다.
- 반복 명령은 스크립트로 굳힌다. 세 번 붙여넣은 건 스크립트로. 다음부터 한 줄입니다.
환경 에러로 날리는 시간이 거의 사라졌습니다. 로그를 통째로 붙여넣으면 원인과 수정안이 같이 나옵니다. 검색해서 비슷한 사례를 찾아 헤매던 30분이 2분이 됐습니다.
모르는 옵션을 그냥 쓰지 않게 됐습니다. “이 플래그 왜 필요하냐”고 물으면 답이 옵니다. 붙여넣기 전에 이해하고 넣습니다.
그리고 반복이 사라집니다. 데이터 받기, 학습 시작, 결과 검증. 전부 스크립트 한 줄입니다. 그 스크립트도 에이전트가 썼고, 제가 읽고 실행했습니다.
2. 사람이 안 붙어 있어도 도는 루프
- 첫 주 — 설정을 잘못 준 채 방치했고, GPU도 다른 작업과 동시에 점유했습니다. 약 하루를 날렸습니다.
- 둘째 주 — 검증 안 된 경로를 주말 자동 실행에 처음 투입했습니다. 주말 전체가 날아갔습니다.
학습 한 번에 3시간입니다. 밤에 걸고 아침에 읽는 리듬이 안 되면 하루 두 바퀴가 한계입니다.
① 세션과 학습을 분리했습니다. 접속이 끊겨도 학습이 안 죽습니다. 노트북을 닫아도 계속 돕니다.
② 중간 저장을 남깁니다. 죽으면 마지막 지점부터 다시 시작합니다.
③ 감시견을 붙였습니다. 메모리를 비정상적으로 먹으면 그 작업만 자동 종료합니다. 서버 전체가 멎어서 아침에 아무것도 안 남아 있는 상황을 막습니다.
④ 본 실행 전에 2분 리허설을 합니다. 3시간짜리를 걸기 전에 20스텝만 돌립니다. 주말을 통째로 날린 사고가 이걸 만들게 했습니다.
이 넷을 붙이고 나서야 리듬이 생겼습니다. 밤에 돌리고 아침에 읽습니다.
유형 정의 → 대량 생성 → 검수 → 걸러내고 재생성
최종 성능을 만든 건 모델 구조가 아니라 이 데이터였습니다.
3. 학습이 도는 3시간 동안 논문을 읽었습니다
학습을 걸어두면 3시간이 빕니다. 그동안 논문을 읽었습니다.
예전에 하던 학습 방식과 달랐습니다. 알던 걸로는 안 됐습니다. 따로 공부해야 했습니다. 학습이 서버에서 알아서 도는 동안이 그 시간이었습니다.
논문 원문을 던지면 한글 정리본이 나옵니다. 용어집도 나옵니다. 수식도 풀어줍니다. 막히면 되묻습니다. “이 손실 함수가 왜 필요한지 모르겠다”고 하면 앞으로 돌아가 설명합니다.
혼자 PDF를 붙들고 있을 때보다 훨씬 빨랐습니다. 정확히는, 모르는 걸 모르는 채로 넘어가지 않게 됐습니다.
논문 정리는 매번 같은 순서입니다. 그래서 직접 커맨드로 만들었습니다. 링크만 던지면 정리본·용어집·수식 풀이가 한 번에 나옵니다.
공개된 것도 가져다 썼습니다. 논문을 코드로 옮겨주는Paper2Code. 계획 → 분석 → 코드 생성 단계를 거쳐 돌아가는 구현체를 만들어 줍니다.
플러그인도 깔아 썼습니다. 논문 읽기·리뷰용 academic-research-skills. Claude Code는 플러그인을 설치하면 커맨드가 통째로 늘어납니다.
직접 만들 필요 없는 건 안 만듭니다. 없는 것만 만듭니다.
리서치도 에이전트로.
더 중요한 건 이쪽이었습니다.
논문은 많습니다. 다 읽을 수 없습니다. 뭘 읽을지 고르는 게 일입니다. 지금 막힌 문제를 설명하면 관련 논문을 찾아옵니다. 왜 관련 있는지도 같이 말해줍니다.
그렇게 14편을 훑었습니다. 전부 읽진 않았습니다. 그중 두 편이 실제 실험 설계로 이어졌고, 최종 결과를 만든 선택이 거기서 나왔습니다.
자동화의 진짜 이득은 시간을 아끼는 게 아니었습니다. 그 시간에 다른 걸 할 수 있다는 것이었습니다.
4. 그럼 사람은 뭘 했나
앞에서 코드를 거의 타이핑하지 않았다고 했습니다. 그럼 3주 동안 제가 한 일은 뭐였느냐. 셋이었습니다.
- 무엇을 만들지 정하기. “성능 올려줘”가 아니라 “정답/오답 모순부터 없애자”고 말하는 것.
- 결과가 이상한지 판단하기. 숫자가 너무 잘 나왔을 때 의심하는 것.
- 바꾸면 안 되는 것을 못 박기. 재현성에 영향 주는 코드는 손대지 말라고 규약 파일에 명시해두는 것.
코드를 안 쓰면 빨라집니다. 대신 문제가 하나 생깁니다. 내가 안 쓴 코드가 만든 숫자를 믿어야 합니다.
그래서 검증을 자동화했습니다. 그게 다음 얘기입니다.
5. 새 모델이 나오면 회귀 테스트부터
3주 사이에도 도구는 계속 좋아집니다.
작업하는 동안 쓰던 모델이 버전업됐습니다. 새 모델도 나왔습니다.
더 좋은 게 나오면 씁니다. 안 쓸 이유가 없습니다. 문제는 실험이 진행 중일 때 바꾼다는 겁니다.
같은 걸 시켜도 결과가 달라질 수 있습니다. 그럼 성능이 변한 게 도구 때문인지 실험 때문인지 구분이 안 됩니다.
그래서 갈아탈 때마다 회귀 테스트를 돌렸습니다.
기준 숫자를 미리 고정해뒀습니다. 한 줄로 확인됩니다.
./verify.sh # → PASS / FAIL
새 모델로 넘어가기 전후에 이걸 돌립니다. 같은 숫자가 나오면 그대로 진행합니다. 다르면 거기서 멈추고 원인부터 찾습니다.
이게 있으니 마음 놓고 갈아탈 수 있었습니다. 없었으면 “좋은 모델이 나왔는데 지금 바꿔도 되나” 하고 계속 망설였을 겁니다.
그리고 이상하면 그냥 다시 물었습니다.
스크립트가 잡는 건 숫자가 틀어진 경우뿐입니다. 답변이 이상한 건 사람이 알아채야 합니다.
그럴 땐 되묻습니다. “왜 그렇게 판단했는지 근거를 달라.” 질문을 바꿔서 다시 묻기도 합니다. 같은 걸 다른 각도로요.
되물으면 상당수는 스스로 정정합니다. 그냥 넘어갔으면 그 잘못된 결과 위에 다음 실험을 설계했을 겁니다.
이상함을 감지하는 건 결국 사람 몫이었습니다. 앞에서 말한 그 감각입니다.
도구는 계속 좋아집니다. 갈아타야 합니다. 갈아탈 수 있으려면 기준이 고정돼 있어야 합니다.
6. 문서는 따로 쓰지 않습니다
작업 기록을 공유용으로 다시 정리하는 일. 대부분 안 하게 됩니다. 그래서 몇 주 지나면 아무것도 안 남습니다.
지금은 마크다운으로 쓴 문서를 에이전트가 위키에 바로 올립니다. 반복 작업이라 커맨드로 만들어 뒀습니다. “이거 올려줘” 한 줄이면 끝납니다.
이 글의 초안도 그렇게 나왔습니다.
정리하면
- 환경 세팅부터 맡기세요. 제일 지겹고 기록도 안 남는 구간입니다. 이득이 제일 큽니다.
2. 루프를 먼저 만드세요. 실험은 그 다음입니다. 저는 순서를 반대로 해서 며칠 날렸습니다.
3. 비는 시간에 공부하세요. 서버가 도는 동안이 그 시간입니다. 읽을 걸 고르는 것부터 맡기면 됩니다.
4. 기준 숫자를 한 줄로 확인되게 만드세요. 그래야 새 모델이 나올 때 망설임 없이 갈아탑니다.
5. 산출물이 곧 문서가 되게 하세요. 따로 쓰기로 하면 안 씁니다.
인터뷰에서 가장 남은 말로 마무리합니다.
중요한 건 얼마나 아느냐가 아닙니다. 내가 뭘 모르는지 알아채는 감각입니다. 그건 아직 AI가 대신 안 해줍니다.