안녕하세요, 1인 사업가와 개발자 여러분! 펭귄 뮤지엄입니다. 🐧
지난 포스팅 마지막, 저는 데이터 병합 작업에 약 2,936시간(122일)이라는 절망적인 예상 시간과 함께 해결책을 찾지 못한 아쉬움을 토로했습니다.
솔직히 그 글을 마무리하면서 '이 프로젝트, 이대로 괜찮을까?' 하는 생각마저 들었습니다.
하지만! 포기하지 않고 이 문제를 계속 파고든 결과, 마침내 해결의 실마리를, 아니, 막힌 도로를 뚫어버릴 고속도로를 찾아냈습니다.
오늘은 122일짜리 작업을 단 18시간으로 단축시킨 그 극적인 과정에 대해 이야기해 보려 합니다.
🤯 나를 괴롭혔던 두 가지 문제: 시간과 에러
문제는 복합적이었습니다. 단순히 시간만 오래 걸리는 게 아니었죠.
- 시간의 장벽: 122일. 이 숫자는 사실상 '자동화 실패'를 의미했습니다. 차라리 제가 직접 손으로 데이터를 비교하는 게 더 빠를 지경이었죠. 하지만 개발자로서 그런 '항복'은 용납할 수 없었습니다.
- 의문의 'Max Token' 에러: 작업을 실행하는 동안, 간헐적으로 제미나이(Gemini) API가 'Max Token' 에러를 뱉어내며 비교를 건너뛰는 현상이 발생했습니다. 분명 이것보다 훨씬 길고 복잡한 프롬프트도 잘 처리해 주던 제미나이였기에, 도무지 원인을 알 수 없었습니다. 프롬프트를 수정하고, API 설정(Config)을 바꿔보는 등 여러 시도를 했지만 문제는 해결되지 않았습니다.
처음엔 '가끔 실패하는 건 어쩔 수 없지'라며 넘겼지만, 이 두 가지 문제는 분명 어딘가에서 연결되어 있을 거라는 의심을 떨칠 수 없었습니다.
🕵️♂️ 원인은 예상 밖의 곳에: 모델 선택의 함정
저는 이 문제를 해결하기 위해 다양한 방법을 시도하며 코드를 분석하고 또 분석했습니다.
그러다 문득, 너무나 당연하게 여겼던 한 가지에 시선이 꽂혔습니다.
"혹시... 문제의 원인이 내가 사용하던 제미나이 모델 자체는 아닐까?"
저는 그동안 '최신 모델이 가장 똑똑하고 빠를 것'이라는 막연한 기대로, 비교적 최신 모델인 Gemini 1.5 Flash를 사용하고 있었습니다. 'Flash'라는 이름답게 빠른 속도를 기대했죠.
하지만 이건 저의 착각이었습니다.
곰곰이 생각해 보니, 제 작업은 '두 개의 노래 제목과 가수 이름을 비교하는' 비교적 단순한 작업이었습니다.
복잡한 추론이나 창의적인 글쓰기가 필요한 작업이 아니었죠. 굳이 고성능의 최신 모델을 사용할 필요가 없었던 겁니다.
"혹시나?" 하는 마음에 저는 모델을 한 단계 낮춰, 안정성이 검증된 Gemini 1.0 Pro 모델로 변경하여 테스트를 진행했습니다.
✨ 결과는 드라마틱했다: 122일에서 18시간으로!
결과는 놀라웠습니다. 모델을 변경하자마자 모든 문제가 해결되었습니다.
- 'Max Token' 에러가 완전히 사라졌습니다. 이전 모델은 제 프롬프트를 안정적으로 처리하는 데 전혀 문제가 없었습니다. 최신 모델이 오히려 특정 유형의 긴 입력 값에 대해 더 민감하게 반응했던 것으로 추측됩니다.
- 처리 속도가 폭발적으로 향상되었습니다.
tqdm(진행률 표시 라이브러리)이 보여주는 예상 완료 시간은 믿을 수 없는 속도로 줄어들기 시작했습니다.
- 변경 전 (Gemini 1.5 Flash): 약 2,936 시간
- 변경 후 (Gemini 1.0 Pro): 약 18 시간
122일이 채 하루도 안 되는 시간으로 단축된 순간이었습니다.
이 숫자를 보고 한동안 모니터 앞에서 멍하니 서 있었던 기억이 나네요.
💡 마무리: 가장 빛나는 망치가 모든 못에 정답은 아니다
솔직히 허무하다면 허무한 해결책일 수 있습니다.
복잡한 알고리즘 개선이나 기발한 로직 변경이 아닌, 단순히 '모델 하나'를 바꿨을 뿐이니까요.
하지만 이 경험은 저에게 아주 중요한 교훈을 남겼습니다.
"가장 크고 빛나는 최신 망치가 모든 못에 가장 좋은 도구는 아니다" 라는 것입니다.
우리는 종종 최신 기술, 최고 사양의 도구를 사용하는 것이 항상 최선이라 생각하는 경향이 있습니다.
하지만 때로는 작업의 본질을 파악하고, 그에 가장 적합한 '안정적이고 검증된 도구'를 선택하는 것이 훨씬 더 효율적일 수 있습니다.
이 글을 읽는 여러분도 AI 모델을 선택할 때 잠시 멈춰 생각해 보셨으면 합니다.
"여러분의 작업에 정말 최신 AI 모델이 필요한가요?" "혹시 더 가볍고 안정적인 모델로도 충분하지는 않나요?"
이 간단한 질문 하나가, 여러분의 프로젝트에서 121일이라는 엄청난 시간을 아껴줄지도 모릅니다.
길고 길었던 데이터 정제 여정에 함께해주셔서 감사합니다.
그럼 다음 포스팅에서 더욱 흥미로운 이야기로 찾아뵙겠습니다!
'사이드 프로젝트' 카테고리의 다른 글
노래방 일본 노래 검색 서비스 | 제 9부 - 수집한 데이터 정재하기 (3)(TJ와 KY, 분열된 노래 데이터를 하나로 합치기 ) (4) | 2025.06.11 |
---|---|
노래방 일본 노래 검색 서비스 | 제 8부 - 수집한 데이터 정재하기 (2)(Gemini API 데이터 자동 생성 실전편) (5) | 2025.06.10 |
노래방 일본 노래 검색 서비스 | 제 7부 - 수집한 데이터 정재하기 (1) | 2025.06.09 |
노래방 일본 노래 검색 서비스 | 제 6부 - Octoparse로 노래방 노래 데이터 쉽게 추출하기 (0) | 2025.06.08 |
노래방 일본 노래 검색 서비스 | 제 5부 - 크롤링으로 노래방 노래 데이터 추출하기 (2) | 2025.06.07 |