1. 최근에 수십 ~ 수백 기가바이트 단위의 데이터를 핸들링해야만 했습니다. 이 정도 규모의 데이터가 데이터 엔지니어링 작업에서 거지 존(...)에 해당하는데요. 싱글 머신의 RAM 사이즈를 넘어가

1. 최근에 수십 ~ 수백 기가바이트 단위의 데이터를 핸들링해야만 했습니다. 이 정도 규모의 데이터가 데이터 엔지니어링 작업에서 거지 존(...)에 해당하는데요. 싱글 머신의 RAM 사이즈를 넘어가므로 페이징 작업이 연산 속도를 떨어뜨리지만 하드 디스크 사이즈 이내이므로 굳이 클러스터로 넘어갈 필요까지는 없기 때문입니다. 게다가 저는 Pandas로 이루어진 레거시 코드를 가지고 있었고 이를 스케일 업 해야 하는 상황이었습니다. PySpark로 레거시를 대체하려면 비용이 꽤나 커질 거라고 생각했어요. 2. 여러 선택지를 고심한 결과, 저는 Modin을 선택했습니다. Modin은 Pandas 데이터 프레임과 동일한 API를 갖되, 내부적으로 Dask나 Ray 같은 병렬 연산 프레임워크로 각종 계산을 처리합니다. Jupyter Notebook 환경에서 확실히 Modin은 빨랐습니다. c5.18xlarge 인스턴스 기준으로 약 20% 시간 절감 효과가 있었습니다. 후훗, 저의 탁월한 판단력에 감탄, 또 감탄(...)했습니다. 모델링까지 끝내고 프로젝트 막바지, 운영을 위해 도커라이징 해서 동일한 작업을 실행시키자 Modin, 정확히 그것의 백엔드인 Ray는 숱한 에러 로그를 토해내기 시작했습니다. '2001 스페이스 오디세이'에 나오는 HAL 9000 배신에 경악했던 인류의 절망감은 이런 것이었을까요. 😂 3. 애플리케이션의 성숙도는 Reddit 문답의 개수, Github에 열리고 닫힌 Issue의 개수에 비례하죠. 그러니까 유구한 시간 동안 숱한 사람들이 이러저러한 삽질로 용례의 커버리지를 넓힐수록 성숙도가 높은 것입니다. Modin과 Ray는 이런 면에서 부족해요. 제 경우 Docker 공유 메모리 부족 문제에 의심이 갔는데 심지어 나는 SageMaker 프로세서에 올려서 돌리는지라 어떻게 옵션 값을 재설정하는지 당최 찾을 수가 없었습니다. 저는 꽤나 에지 케이스에 있었고 이게 Docker의 문제인지, Modin이나 Ray의 문제인지, SageMaker의 문제인지, 아니면 이 모든 것들의 환장의 엘 클라시코(...)인지 알 수가 없었습니다. 제가 찾은 Github 유사한 이슈들의 댓글은 분노 - 공감 - 연대 - 희망 - 의문의 클로징(...) 순으로 끝나 있었습니다. 4. 결국 저는 Modin을 걷어내고 바닐라 Pandas로 다시 돌아가야만 했습니다. 개발 환경과 운영 환경의 상이함에서 오는 위험이라든가, 애플리케이션의 성숙도를 항상 고려해야 한다는 점은 이미 알고 있었습니다. 그러나 이번 경험은 또 하나의 교훈을 주었는데... Modin은 Pandas와 동일한 API를 가지고 있기 때문에 임포트 구문 딱 한 줄만 바꾸면 된다고 홍보를 합니다. 사실 많은 고수준 라이브러리가 이러한 사용자 확장 전략을 쓰죠. 그렇지만 디버깅을 위해서는 백엔드 동작 원리를 결국 어느 정도 알아야 하는데 저는 사실 Ray를 잘 몰랐어요. 레거시 대체 비용이 아주 적은 것 같아도 제 무지에 대한 비용이 항상 숨어있다는 것, 그게 이번 사단의 교훈이었습니다.