백신 프로그램이 30GB를 먹어버린 경험. 노트북에서 진행한 50시간 실험 기록
요약
연구 논문을 위해 MacBook에서 50시간 동안 AI 코딩 에이전트 실험을 진행한 경험을 공유합니다. 이 과정에서 노트북 절전 모드, 백신 프로그램의 과도한 디스크 사용(30GB 이상), 그리고 중복 실행 및 메모리 누수 등 다양한 인프라 문제를 겪었습니다. 궁극적으로 아이디어보다 인프라가 먼저 무너진다는 교훈을 얻었습니다.
핵심 포인트
- 노트북 절전 모드 방지: 작업 환경을 '깨어있게' 유지하는 것이 중요합니다.
- 백신 프로그램 관리: 장시간 실험 시 백신 스캐닝으로 인한 디스크 공간 소모에 유의해야 합니다.
- 중복 실행 방지: 결과 출처를 특정할 수 없는 데이터는 신뢰하지 않고 재실행해야 합니다.
- 인프라 설계 개선: 작업별 새 프로세스 사용, 외부 SSD 활용, 디스크 워치독 도입이 필요합니다.
저는 제 MacBook으로 연구 논문을 위해 약 50시간 동안 컴퓨팅을 돌렸습니다. 클러스터도, 임대하는 GPU 박스도 아니었습니다. 제가 다른 모든 용도로 사용하는 바로 그 노트북이었습니다.
이번 작업은 올해 초에 여기서 작성했던 테스트 품질 하네스인 killcheck의 후속작입니다. 이번에는 Google의 Gemma 4 모델을 기반으로 구축된 AI 코딩 에이전트에 대한 Kaggle 대회 논문입니다. 이 에이전트는 인기 있는 오픈 소스 Python 라이브러리에서 가져온 80개 이상의 실제 버그 수정 작업을 처리합니다. 제출은 11월에 이루어지며, 결과와 코드는 대회가 종료된 후에 공개되므로 제가 발견한 내용에 대해서는 아무것도 없습니다.
이것은 다른 이야기입니다. 아이디어가 문제가 아니었던 경우의 이야기입니다.
노트북 덮개 (The lid)
저는 노트북을 닫았습니다.
그게 전부였습니다. 이것이 첫 번째 실패 전체였습니다. 제가 실행 도중에 덮개를 닫았고, 기기가 절전 모드로 들어갔으며, 작업은 중간 어딘가에서 죽었습니다. 저는 그 후 식별하고 다시 해야 할 배치(batch)를 처리해야 했습니다.
해결책은 놀라울 정도로 단순합니다. 덮개를 열어두고, 충전기를 연결하며, 기기가 제 대신 그런 결정을 내리지 못하도록 작업 주변에 '깨어있게 하는' 명령을 감싸는 것입니다.
저는 이 일로 실질적인 시간을 많이 잃었고, 한 번만 그렇게 잃었던 것처럼 가장하고 싶습니다.
백신 프로그램 (The antivirus)
도중에 기기가 심하게 스와핑(swapping)하기 시작했습니다. 모든 것이 느려졌고, 실행 작업도 마찬가지였으며, 제 코드 중 그 원인을 설명하는 것은 아무것도 없었습니다.
백신 스캐너가 조용히 30GB 이상의 디스크 공간을 소비했습니다. 이 프로그램은 장시간 실험이 생성하는 모든 임시 파일을 실시간으로 인덱싱(indexing)하고 있었는데, 그 파일들이 엄청나게 많았고 결과를 유지하고 있었습니다.
지금은 제거되었습니다.
이 이야기를 할 가치가 있는 점은 이것이 제 작업과 아무 관련이 없었고 눈에 보이는 연결 고리도 없었다는 것입니다. 증상은 제 작업에서 나타났지만, 원인은 제가 1년 동안 생각하지 않았던 소프트웨어 조각이었고, 그 소프트웨어는 자신이 설계된 대로 정확히 작동했으며, 아무도 그것을 위해 설계하지 않은 워크로드(workload)에 대해 그렇게 했습니다.
두 개의 복사본 (The two copies)
저는 첫 번째 사본이 아직 실행 중일 때 작업을 재시작했습니다.
두 복사본이 같은 파일에 쓰기 작업을 했습니다. 한동안 둘 중 어느 것도 명백히 잘못된 것은 아니었는데, 이것이 최악의 경우였습니다. 왜냐하면 결과가 계속 도착했고 괜찮아 보였기 때문입니다.
겹치는(overlapping) 창에서 나온 모든 결과는 휴지통으로 들어가 다시 실행되었습니다. 그것만이 유일하게 정직한 선택이었습니다. 나중에 어느 복사본이 어떤 행을 만들었는지 알 수 없었고, 출처를 특정할 수 없는 결과는 결과가 아닙니다.
느린 누수 (The slow leak)
오래 지속되는(long-lived) 워커 프로세스들이 메모리에서부터 새어 나갔습니다. 그리고 임시 파일들까지, 몇 시간에 걸쳐 점진적으로요. 시스템을 다운시킬 만큼 극적이지는 않았습니다. 단지 실행할수록 상태가 악화되는 기계였고, 이는 후반 결과들이 초반 결과들과 일치하지 않는 조건에서 생산되고 있음을 의미했습니다.
제가 처음부터 갖추었어야 할 세 가지 해결책이 있었습니다.
작업(task)마다 새로운 프로세스를 사용해서 실행 전반에 걸쳐 아무것도 누적되지 않게 하는 것. 시스템 디스크 대신 외부 SSD에 임시 파일을 쓰는 것. 그리고 디스크가 가득 차서 바닥을 치는 것을 발견하는 대신, 디스크 워치독(disk watchdog)이 실행을 일시 중지시키는 장치를 마련하는 것이었습니다.
시간 0일 때 나 자신에게 말하고 싶은 것
인프라가 아이디어보다 먼저 무너진다.
저는 연구 질문 자체가 틀려서 한 시간을도 잃지 않았습니다. 저는 잠 설정, 스캐너, 저 자신의 서투른 손놀림(fat fingers), 그리고 상태가 안 좋게 노화된 프로세스들 때문에 모든 시간을 잃었습니다. 이 중 어느 것도 흥미롭지 않고, 논문에 실리지 않을 것이며, 이것들이 바로 시간이 사라진 곳입니다.
그래서, 가장 많은 시간을 절약해 줄 수 있는 단 한 가지를, 제가 할 수 있는 가장 명료한 방식으로 말씀드리자면:
실행을 시작하기 전에 모든 것을 재개 가능(resumable)하게 만드세요.
첫 번째 충돌 이후가 아니라, 그 이전에요. 기계가 임의의 순간에 멈출 것이라고 가정하세요. 왜냐하면 실제로 그렇게 될 것이기 때문입니다. 그리고 문제는 그것이 5분짜리 비용을 초래할지 하루짜리 비용을 초래할지에 대한 것뿐입니다. 배치(batch) 단위가 아닌, 작업(task) 단위로 체크포인트(checkpoint)를 만드세요. 무엇이 완료되었는지 기록하여 재시작 시 건너뛰게 하세요. 작업을 불변(idempotent)하게 만들어 두 번 실행해도 안전하고 조용히 손상되지 않도록 하세요.
이 목록에 있는 나머지 모든 것은 이 한 가지가 시작부터 사실이 아니었기 때문에 발생한 결과일 뿐입니다.
노트북에 대한 참고 사항
저는 기계를 임대할 수도 있었습니다. 어떤 작업에는 그렇게 해야 합니다.
하지만 몇 주에 걸쳐 진행된 50시간의 시간 동안, 이미 가지고 있는 하드웨어에서, 측정 장치가 돌아가지 않아도, 필요할 때마다 멈추고 다시 시작하고 마음을 바꿀 수 있었다는 점이 중요했습니다. 이것이 순수한 속도보다 더 중요했다는 것이 밝혀졌는데, 왜냐하면 저는 생각이 많이 바뀌었기 때문입니다. 임대된 컴퓨터에서 나쁜 한 시간의 비용은 나쁜 한 시간에 청구서가 추가되는 것입니다. 자신의 노트북에서는 단지 나쁜 한 시간일 뿐입니다.
이것은 더 못한 기계이지만 더 좋은 환경입니다. 저는 다시 이렇게 할 것입니다. 필요한 날에 추가하는 대신, 처음부터 워치독(watchdog)을 설치할 것입니다.
논문은 다음 달에 나갑니다. 경쟁이 끝나면 실제로 무엇을 발견했는지 정리해서 작성하겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기