AI 성능 프로파일러를 하루 만에 만들기

Об этом предложении

소마 프로젝트의 핵심 기능은 음식 사진을 AI에게 보내 어떤 음식인지 판별 하는 것이다. 백엔드 팀원이 이미 Gemini API로 이 기능을 구현해둔 상태였다. 소마는 지원비가 넉넉해서 비용 걱정이 없었고, 마침 새로 나온 Gemini Flash 모델이 이미지 식별을 아주 잘한다는 소식도 있었다. 팀원은 자연스럽게 Gemini Flash 3.8 을 골라 구현을 마쳤다. 앱에서 직접 테스트해보면 잘 되는 것 같긴 했다. 그런데 3가지 질문이 자연스럽게 따라왔다. 이게 정말 잘 되는 게 맞나? 정확도가 높은건지.... 낮은건지... 추론에 8~10초씩 걸리는데, 더 줄일 수는 없나? 나중에 지원금 없이도 이 서비스를 유지하려면 api 호출 비용을 더 절약하고 싶은데... 당장 떠오른 아이디어, 또 바로 떠오른 그에 대한 반박 추론 시간을 줄일 방법으로 세 가지를 제안했다. 더 경량화된 모델을 쓰는건 안될까? 이미지 해상도를 줄여서 보내면 추론이 빨라지지 않을까? 이미지를 압축해서 파일 크기를 줄이면 더 빨라지지 않을까? 그런데 당장 떠오른 아이디어에는 당장 떠오른 반박도 있었다. ᄒ 너무 경량화된 모델은 부정확하지 않을까? 어쩌면 지금 모델이 이미 최선 아닐까? 속도 조금 챙기려고 사진크기 줄였다가 정확도가 너무 떨어지는 건 아닐까? Gemini Flash가 멀티모달이라지만 근본적으로는 LLM인데, 내부적으로 결국 토큰으로 변환해서 처리한다면 해상도가 같을 때 파일 크기는 의미가 없는 것 아닐까? 결국 "모델을 더 경량화해서 속도를 챙기자!"라고 주장하려면, 모두가 납득할만한 이유 가 필요했다. 이것이 AI 성능 프로파일러 를 만들게 된 계기다. 오늘은 내가 바이브코딩 요리사~ 이 도구에서 정말 중요한 건 무엇을 측정하고, 무엇을 비교할지에 대한 설계 와 그 프로파일링 결과 다. 도구 자체를 손으로 짜는 건 별 의미가 없다고 판단해서, 개발은 클로드에게 전적으로 맡기는 풀 바이브코딩을 해보기로 했다. ᄏᄏ 기술 스택도 마찬가지였다. 어차피 로컬에서 돌려 결과를 얻고, 그걸 정적 페이지로 만들어 GitHub Pages에 올려 팀원에게 공유할 생각이었기 때문에 스택이 중요하지 않았다. 그래서 기술 스택 선택도 클로드에게 전부 맡겼다. 내가 지시한 프롬프트는 이게 전부였다. 프로파일링할 모델을 선택할 수 있어야 하고, 원본 이미지 + 512/256 리사이즈 2개 + 85%/50% 압축 2개, 이렇게 5개의 대조군을 가져야 하고, API 1회당 응답 시간과 정답 여부를 계측할 수 있는 시스템. 그리고 프로파일링 뷰에서는 두 측정 결과를 나란히 비교해서, 뭐가 더 나은지 시각적으로 한눈에 볼 수 있는 화면. 물론 이후로 ui나 더 필요할 것 같은 통계 정보는 추가적인 프롬프트를 입력해서 개선해나갔다. 어쨌든 "모델이 얼마나 잘 맞추는데?"라는 질문에 감으로만 답하는 게 싫어서, 이런 시스템을 만들었다. 그런데 만들면서 깨진 경험 이 인상적이었어서 블로그에 남겨보려한다. 바이브코딩? AI? 절대 그를 신뢰하지마.... 가장 테스트하고 싶었던 건 Gemini Flash로 정확도가 충분한지 , 그리고 flash-lite 같은 더 경량화된 모델을 써도 괜찮을지 였다. 그래서 이 두 모델로 측정을 시작했다. 만족스러운 결론을 얻지 못했다면 다른 모델도 측정해봤겠지만, 스포를 하자면 다른 모델을 더 해볼 이유는 없었다. ᄏᄏ Google AI 콘솔에 크레딧을 만 원 정도 충전하고 프로파일링을 돌렸다. 요금표 기준 가격은 다음과 같다. 모델 입력 (100만 토큰당) 출력 (100만 토큰당) Flash 3.8 $0.75 $3.75 Flash Lite 3.5 $0.30 $2.50 참고로 내년부턴 가격이 2배 오른다.... 호출 한 번을 넉넉하게 잡아보자. 입력 : 이미지(256 리사이즈면 258토큰, 원본 사진도 1,500토큰 안팎) + 프롬프트 해서 약 1,000토큰 출력 : 음식 이름 JSON 몇십 토큰 그러면 flash 3.8은 1회당 약 $0.001(약 1.4원), flash-lite는 약 $0.0004(약 0.6원) 수준이다. 이미지 715개 × (원본 + 리사이즈 2개 + 압축 2개) = 모델당 3,575회 호출 . 두 모델을 다 돌려도 $5 안팎, 7천 원 남짓 이라는 계산이 나온다. 단순 계산으로는 절대 만 원을 넘을 수 없는 양 이었다. 그런데...! flash-lite 3.5는 문제없이 프로파일링을 마쳤는데, flash 3.8을 돌리던 도중 만 원이 증발했다. 💸 flash 3.8은 추론 기능이 default로 설정되어있다..? 왜 안 알려줬어...클로드야... 콘솔의 사용량 내역을 뜯어보고 나서야 알았다. flash 3.8은 thinking(추론) 기능이 있고, 모델이 답을 내기 전에 속으로 생각하는 이 thinking 토큰이 전부 출력 토큰으로 과금 되고 있었다. 나의 행복회로 내에서는 "입력 = 이미지 + 프롬프트, 출력 = 음식 이름 JSON 몇십 토큰"의 흐름이었다. 그런데 실제로는 호출 한 번마다 눈에 보이는 응답 뒤에 수천 토큰짜리 thinking이 숨어 있었다. 출력 단가는 $3.75/1M로 입력의 5배인데, thinking이 호출당 1,500토큰만 붙어도 출력 비용은 예상($0.0002)의 약 30배($0.0058)가 되고, 프로파일링 예상 총 비용은 약 $24, 3만 원 이 되는 것이다.. 만 원이 중간에 증발할 만했다. 클로드는 내가 시킨대로 API를 기본값 그대로 호출했을 뿐이고, 그 기본값에 thinking이 켜져 있었을 뿐이다. 바이브코딩의 무서운 점은 코드가 안 돌아가는 게 아니라, 잘 돌아가는데 내가 모르는 방식으로 돌아간다 라는 점임을 실제로 사고를 쳐보면서 경험해볼 수 있었던 것 같다! 경험값으로 10,000원은 값싼거 아니었을까...?ᄒ 의도치 않은 측정에서 알 수 있었던 재밌는 사실 2가지 2가지였다. 추론 기능이 켜져있으면 정확도가 올라가는가? 추론 기능이 끄면 속도가 빨라지는가? 결과는 의외였다. 추론 기능의 유무는 정확도의 큰 영향을 주지 않을 정도로 정확도는 0.7%밖에 차이가 안났고, 속도는 4.4초나 빨랐다. 거기에 비용은 절반보다 더 적었다. 우리는 gemini api로 각 사진이 어떤 음식인지 판별 하기 위해서만 사용한다. 그렇기에 추가적인 추론이 크게 의미가 없었던 듯하다. 이번 실수에서 배운 것 💡 API 호출 비용도 계측해야한다! 나는 AI 성능 프로파일링을 할때 계측 해야할 것을 크게 호출 시간, 정확도 이 2가지로 보았지만, 사실 특히 더 중요한 가격 을 빼먹고 있었다. 처음부터 호출 비용을 측정하고 있었으면 내 예상보다 가격이 비싸게 진행되고 있음을 알 수 있었을 것이다! 사진 크기가 AI 성능에 큰 영향을 미칠까? 모델 비교와 별개로 꼭 확인하고 싶었던 게 있다. 이미지를 어떤 형태로 보내야 가장 효율적인가? 해상도를 줄이면(resize) 빨라질까? 정확도는 얼마나 떨어질까? 해상도는 그대로 두고 압축만 하면(JPEG 품질 85% / 50%) 어떨까? 하나의 original 사진을 resize(512, 256), 압축(q85, q50)로 변형하기 때문에 결과가 다르다면 분명 이 변형으로 생긴 것일 것이다. 1. 정확도: 해상도를 줄이면 조금 떨어진다 모델 original resize512 resize256 q85 q50 Flash 3.8 90.9% 89.2% 88.1% 90.0% 90.1% Flash Lite 3.5 85.3% 83.9% 83.3% 85.0% 83.4% 해상도를 줄일수록 정확도가 1~3% 정도 떨어진다. 256px까지 줄이면 가장 많이 떨어진다. q85는 원본과 사실상 같다. 파일 크기가 119KB에서 76KB로 줄었는데 정확도는 그대로다. q50은 Lite에서 resize만큼 떨어졌다. 다만 같은 설정으로 두 번 돌려봤더니 원본 정확도가 84.9%와 85.3%로 0.4% 차이가 났다. 그러니까 1% 안팎의 차이는 노이즈일 수 있다. 확실하게 말할 수 있는 건 "줄일수록 조금씩 떨어지는 경향이 있다" 정도뿐이다. 2. 속도: 평균의 함정 Flash 3.8에서 이상한 결과가 나왔다. 사진이 가장 작은 resize256이 평균 처리시간은 오히려 가장 길었다 (9.3초, 원본은 8.6초). DB를 뜯어보니 평균의 함정 이었다. 가끔 1분 넘게 걸리는 요청 이 섞여 있었고(최대 1~3분!), 이런 이상치 몇 건이 어느 변형에 걸리느냐에 따라 평균이 크게 흔들린 것이다. 그래서 분포를 그려보고 중앙값 으로 다시 비교했다. 모델 (중앙값) original resize512 resize256 q85 q50 Flash 3.8 3,676ms 3,574ms 3,584ms 3,621ms 3,524ms Flash Lite 3.5 1,535ms 1,501ms 1,484ms 1,536ms 1,503ms 중앙값으로 보면 어떤 변형이든 차이가 -100ms ~ +100ms밖에 안 난다. 해상도를 줄여도 추론이 빨라지지는 않았다. 3. 반전: 입력 토큰이 전부 똑같다 해상도를 줄였는데 왜 빨라지지 않을까? 이유가 궁금해서 변형별 입력 토큰 을 뽑아봤다. 다섯 변형의 입력 토큰이 전부 약 2,445개로 똑같았다. 427×640 원본도, 171×256으로 줄인 사진도, 50%로 압축한 사진도 전부 거의 같았다. 뒤통수맞은 느낌이었다. ᄏᄏᄏ 으악ᄏᄏᄏᄏ 이미지 입력 토큰이 항상 같기 때문에 gemini 3 계열은 내부적으로 이미지 사이즈가 무엇이든 고정된 크기로 변환해서 사용한다. 그렇기 때문에 입력토큰 크기가 일정했던 것이다. 이걸 알고 나니 앞의 결과가 전부 설명된다. 속도가 그대로인 이유 : 모델이 처리하는 토큰 수가 같으니 추론 시간도 같다. 물론 네트워크로 이미지가 전송되는 시간은 이미지 크기를 줄인 것이 살짝 더 빠를 것이다! 정확도가 떨어진 이유 : 토큰 수는 같아도 그 안에 담긴 정보가 다르다. 작은 사진은 원래 디테일이 사라진 상태로 같은 칸 수를 채우는 거라, 흐린 사진을 같은 크기 화면에 꽉 채워 보는 것과 비슷하다. 결국 해상도를 줄이는 건 속도도 비용도 그대로인데 정확도만 조금 잃는 선택 이었다. ᄏᄏ 4. 진짜 조절 레버: media_resolution 그럼 이미지 토큰을 줄이는 방법은 없을까? 찾아보니 이미지 토큰 수를 정하는 건 사진 크기가 아니라 요청 파라미터인 media_resolution 이었다. media_resolution 이미지 토큰 LOW 280 MEDIUM 560 HIGH (= 지정하지 않았을 때 기본값) 1,120 우리는 지금까지 전부 이 값을 지정하지 않았으니 HIGH로 돌아간 셈이다. 그래서 원본 사진으로 LOW / MEDIUM / HIGH를 각각 돌려봤다. Flash Lite 3.5 LOW MEDIUM HIGH 정확도 84.7% 86.0% 85.1% 입력 토큰 1,622 1,897 2,445 1,000건당 비용 $0.50 $0.58 $0.74 처리시간 (중앙값) 1,119ms 1,234ms 1,387ms Flash 3.8 LOW MEDIUM HIGH 정확도 91.2% 89.7% 91.6% 입력 토큰 1,622 1,897 2,446 1,000건당 비용 $1.54 $1.73 $2.18 처리시간 (중앙값) 2,398ms 2,403ms 2,559ms resize와는 결과가 완전히 달랐다. 정확도는 사실상 그대로다. 비용은 약 30% 줄었다. 입력 토큰이 2,445에서 1,622로 줄어든 덕분이다. 속도도 빨라졌다. 사진을 우리가 직접 줄이면 정보만 잃는다. 반면 media_resolution 을 낮추면 모델이 처리하는 양 자체가 줄어든다. 음식 종류를 판별하는 정도의 작업이라면 LOW로도 충분했다. 이 실험에서 배운 것 💡 앞으로 누군가 나에게 "A가 빠를까? B가 빠를까?" 라고 묻는 다면, "측정해봤어?" 라고 답할것이다...!!! "해상도를 줄이면 토큰이 줄고 빨라진다"는 너무 당연해 보여서 의심조차 안 했다. 그런데 측정해보니 별 차이가 없음을 알 수 있었고, 입력 토큰은 media_resolution 라는 입력 파라미터의 의해 고정되어있음을 뒤늦게 알 수 있었다. 직접 측정해보기 전까지 나의 직관을 무지성 신뢰하지 않아야겠다고 다짐할 수 있는 경험이었다...!!! 그래서, 결과를 정리해보면? Gemini Flash 3.8 Gemini Flash 3.8 - Low Gemini Flash Lite 3.5 Gemini Flash Lite 3.5 - Low 처음의 세 가지 질문에 답해보면 이렇다. 1. 정확도가 충분한가? Flash 3.8은 약 91%, Lite 3.5는 약 85%. 두 모델의 차이는 약 6%p다. 2. 추론 시간을 줄일 수 있나? 사진 크기나 압축으로는 줄일 수 없다. 방법은 세 가지다. thinking 끄기 media_resolution 을 LOW로 낮추기 Lite 모델로 바꾸기 3. 비용을 아낄 수 있나? media_resolution=LOW 만으로 정확도 손실 없이 약 30%를 아낄 수 있다. Lite로 바꾸면 Flash LOW 대비 추가로 약 1/3 수준까지 내려간다. 조합 정확도 처리시간 (중앙값) 1,000건당 비용 Flash 3.8 (기존 설정) 90.9% 3.7초 $2.11 Flash 3.8 + LOW 91.2% 2.4초 $1.54 Flash Lite 3.5 + LOW 84.7% 1.1초 $0.50 결국 선택은 정확도 6%p를 얼마의 가치로 볼 것인가 의 문제가 됐다. 우리 팀의 경우 정확도 6%는 사실 큰 수치가 아니라고 판단하였다. 왜냐하면 아래의 사진을 보면 이 6퍼센트도 과장된 수치임을 알 수 있기 때문이다. 사진을 보고 ai는 고추장진미채볶음이라고 판별했으나 사실 ai의 답도 어떻게 보면 답이라고 볼 수 있기 때문이다. 그렇기에 이런 사소한 정확도의 집중하기 보단 처리 시간과 비용의 이점이 더 큰 Flash Lite 3.5 의 입력 토큰이 가장 낮은 LOW 로 설정해서 사용하는 것이 가장 우리 프로젝트에 적합하다고 판단하였다.!! 🎉