코드를 거의 타이핑하지 않고 3주 만에 DL모델 만들기

글. 이철우(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스텝만 돌립니다. 주말을 통째로 날린 사고가 이걸 만들게 했습니다.

이 넷을 붙이고 나서야 리듬이 생겼습니다. 밤에 돌리고 아침에 읽습니다.

데이터도 에이전트가 만들었습니다.

모델보다 데이터가 문제였습니다.

한참 성능이 안 올라서 파봤더니, 학습 데이터의 정답과 오답이 서로 모순돼 있었습니다. 같은 항목이 어떤 자리에선 정답이고 어떤 자리에선 오답이었습니다. 모순을 걷어내고 나서야 처음으로 기준선을 넘었습니다.

그 다음이 더 중요했습니다. 제가 풀려던 유형의 질의는 로그에 거의 없었습니다. 사용자들이 그런 식으로 검색을 안 하니까요. 없는 데이터는 만들어야 했고, 그걸 LLM으로 합성했습니다.

유형 정의 → 대량 생성 → 검수 → 걸러내고 재생성

최종 성능을 만든 건 모델 구조가 아니라 이 데이터였습니다.

3. 학습이 도는 3시간 동안 논문을 읽었습니다

학습을 걸어두면 3시간이 빕니다. 그동안 논문을 읽었습니다.

읽어야 했습니다.

예전에 하던 학습 방식과 달랐습니다. 알던 걸로는 안 됐습니다. 따로 공부해야 했습니다. 학습이 서버에서 알아서 도는 동안이 그 시간이었습니다.

스터디도 에이전트로.

논문 원문을 던지면 한글 정리본이 나옵니다. 용어집도 나옵니다. 수식도 풀어줍니다. 막히면 되묻습니다. “이 손실 함수가 왜 필요한지 모르겠다”고 하면 앞으로 돌아가 설명합니다.

혼자 PDF를 붙들고 있을 때보다 훨씬 빨랐습니다. 정확히는, 모르는 걸 모르는 채로 넘어가지 않게 됐습니다.

만들기도 하고, 가져다 쓰기도 했습니다.

논문 정리는 매번 같은 순서입니다. 그래서 직접 커맨드로 만들었습니다. 링크만 던지면 정리본·용어집·수식 풀이가 한 번에 나옵니다.

공개된 것도 가져다 썼습니다. 논문을 코드로 옮겨주는 Paper2Code. 계획 → 분석 → 코드 생성 단계를 거쳐 돌아가는 구현체를 만들어 줍니다.

플러그인도 깔아 썼습니다. 논문 읽기·리뷰용 academic-research-skills. Claude Code는 플러그인을 설치하면 커맨드가 통째로 늘어납니다.

직접 만들 필요 없는 건 안 만듭니다. 없는 것만 만듭니다.

리서치도 에이전트로.

더 중요한 건 이쪽이었습니다.

논문은 많습니다. 다 읽을 수 없습니다. 뭘 읽을지 고르는 게 일입니다. 지금 막힌 문제를 설명하면 관련 논문을 찾아옵니다. 왜 관련 있는지도 같이 말해줍니다.

그렇게 14편을 훑었습니다. 전부 읽진 않았습니다. 그중 두 편이 실제 실험 설계로 이어졌고, 최종 결과를 만든 선택이 거기서 나왔습니다.

자동화의 진짜 이득은 시간을 아끼는 게 아니었습니다. 그 시간에 다른 걸 할 수 있다는 것이었습니다.

4. 그럼 사람은 뭘 했나

앞에서 코드를 거의 타이핑하지 않았다고 했습니다. 그럼 3주 동안 제가 한 일은 뭐였느냐. 셋이었습니다.

• 무엇을 만들지 정하기. “성능 올려줘”가 아니라 “정답/오답 모순부터 없애자”고 말하는 것.
• 결과가 이상한지 판단하기. 숫자가 너무 잘 나왔을 때 의심하는 것.
• 바꾸면 안 되는 것을 못 박기. 재현성에 영향 주는 코드는 손대지 말라고 규약 파일에 명시해두는 것.

코드를 안 쓰면 빨라집니다. 대신 문제가 하나 생깁니다. 내가 안 쓴 코드가 만든 숫자를 믿어야 합니다.

그래서 검증을 자동화했습니다. 그게 다음 얘기입니다.

5. 새 모델이 나오면 회귀 테스트부터

3주 사이에도 도구는 계속 좋아집니다.

작업하는 동안 쓰던 모델이 버전업됐습니다. 새 모델도 나왔습니다.

더 좋은 게 나오면 씁니다. 안 쓸 이유가 없습니다. 문제는 실험이 진행 중일 때 바꾼다는 겁니다.

같은 걸 시켜도 결과가 달라질 수 있습니다. 그럼 성능이 변한 게 도구 때문인지 실험 때문인지 구분이 안 됩니다.

그래서 갈아탈 때마다 회귀 테스트를 돌렸습니다.

기준 숫자를 미리 고정해뒀습니다. 한 줄로 확인됩니다.

./verify.sh     # → PASS / FAIL

새 모델로 넘어가기 전후에 이걸 돌립니다. 같은 숫자가 나오면 그대로 진행합니다. 다르면 거기서 멈추고 원인부터 찾습니다.

이게 있으니 마음 놓고 갈아탈 수 있었습니다. 없었으면 “좋은 모델이 나왔는데 지금 바꿔도 되나” 하고 계속 망설였을 겁니다.

그리고 이상하면 그냥 다시 물었습니다.

스크립트가 잡는 건 숫자가 틀어진 경우뿐입니다. 답변이 이상한 건 사람이 알아채야 합니다.

그럴 땐 되묻습니다. “왜 그렇게 판단했는지 근거를 달라.” 질문을 바꿔서 다시 묻기도 합니다. 같은 걸 다른 각도로요.

되물으면 상당수는 스스로 정정합니다. 그냥 넘어갔으면 그 잘못된 결과 위에 다음 실험을 설계했을 겁니다.

이상함을 감지하는 건 결국 사람 몫이었습니다. 앞에서 말한 그 감각입니다.

도구는 계속 좋아집니다. 갈아타야 합니다. 갈아탈 수 있으려면 기준이 고정돼 있어야 합니다.

6. 문서는 따로 쓰지 않습니다

작업 기록을 공유용으로 다시 정리하는 일. 대부분 안 하게 됩니다. 그래서 몇 주 지나면 아무것도 안 남습니다.

지금은 마크다운으로 쓴 문서를 에이전트가 위키에 바로 올립니다. 반복 작업이라 커맨드로 만들어 뒀습니다. “이거 올려줘” 한 줄이면 끝납니다.

이 글의 초안도 그렇게 나왔습니다.

정리하면

1. 환경 세팅부터 맡기세요. 제일 지겹고 기록도 안 남는 구간입니다. 이득이 제일 큽니다.

2. 루프를 먼저 만드세요. 실험은 그 다음입니다. 저는 순서를 반대로 해서 며칠 날렸습니다.

3. 비는 시간에 공부하세요. 서버가 도는 동안이 그 시간입니다. 읽을 걸 고르는 것부터 맡기면 됩니다.

4. 기준 숫자를 한 줄로 확인되게 만드세요. 그래야 새 모델이 나올 때 망설임 없이 갈아탑니다.

5. 산출물이 곧 문서가 되게 하세요. 따로 쓰기로 하면 안 씁니다.

인터뷰에서 가장 남은 말로 마무리합니다.

중요한 건 얼마나 아느냐가 아닙니다. 내가 뭘 모르는지 알아채는 감각입니다. 그건 아직 AI가 대신 안 해줍니다.