웹검색 내장 LLM API, 토큰 87%가 버려진다는 실측 — 직접 조립과 비용 비교
r/OpenAI에 올라온 한 개발자 측정 보고가 눈길을 끌었어요. OpenAI의 웹검색 내장 API가 주입한 컨텍스트 토큰 중 약 87%가 최종 답변에 쓰이지 않았다는 겁니다. 제가 직접 써본 경험으로도 내장 웹검색은 편하지만 비용 투명성이 떨어진다는 느낌이 있었는데, 이 수치를 보니 의심이 확신으로 바뀌더군요. 검색 결과를 직접 조립해 LLM에 넘기는 팀이라면 내장형보다 월 비용을 30~50% 줄일 수 있습니다. 반대로 개발 리소스가 없고 빠른 프로토타입이 목적이라면 내장형 편의가 여전히 유효하죠.
비교 기준 — 비용·제어권·운영부담
제가 하루 200건 처리하는 자동 Q&A 파이프라인에서 두 방식을 모두 운영해본 경험을 바탕으로, 비교 기준을 세 가지로 잡았습니다.
- 토큰 단가 기준 월 비용: 내장형은 입력 토큰이 블랙박스지만, 직접형은 검색 API 비용과 LLM 토큰을 각각 산출할 수 있어요.
- 제어권: 내장형은 몇 개 출처를 주입하는지 모르지만, 직접형은 상위 3개만 쓸지 10개까지 쓸지 내 마음대로 조절됩니다.
- 운영 부담: 내장형은 코드 한 줄로 끝나지만, 직접형은 검색 API 키 관리부터 결과 파싱·프롬프트 조립까지 직접 구현해야 하죠.
한쪽은 OpenAI API 웹검색 파라미터를 켜고, 다른 쪽은 Serper API로 검색 결과를 먼저 따와 직접 프롬프트에 끼워넣어 비교했습니다.
커뮤니티 실측으로 본 비용 차이 — 토큰 87%가 버려졌다
r/OpenAI에 올라온 측정 보고에 따르면, "최근 AI 규제 동향" 같은 질의에 내장 웹검색 API를 호출했더니 평균 입력 토큰이 약 4,200개 나왔다고 해요. 이 중 실제로 모델이 인용한 부분은 평균 500~600토큰 정도였고, 나머지 3,600토큰은 검색 스니펫이 주입됐지만 답변엔 반영 안 된 거죠. 이게 87% 불필요 토큰 패턴입니다.
이 수치를 OpenAI 공식 요금표 기준(요금은 수시로 바뀌니 발행 시점 공식 페이지에서 확인하세요)으로 계산해봤어요. 직접 조립형은 Serper API로 상위 5개 결과를 가져와 제목과 스니펫만 뽑아 프롬프트에 넣으면 평균 입력 토큰이 1,800개로 줄어듭니다. GPT-4o 입력 토큰 단가를 약 $2.50/1M으로 가정하면, 내장형은 호출당 약 $0.0105, 직접형은 약 $0.0045예요. 여기에 검색 API 호출 비용을 더해도 직접형이 건당 약 $0.0065로 내장형 대비 약 38% 저렴했습니다.
| 구분 | 내장 웹검색 API | 직접 조립형 |
|---|---|---|
| 호출당 입력 토큰 | 약 4,200개 | 약 1,800개 |
| 호출당 LLM 비용 | $0.0105 | $0.0045 |
| 검색 API 비용 | 포함 | +$0.002 |
| 호출당 총 비용 | $0.0105 | $0.0065 |
| 월 6,000건 기준 | $63 | $39 |
월 6,000건 처리하면 내장형이 $63, 직접형이 $39로 월 $24 차이죠. 규모가 커지면 이 격차가 눈에 띄게 벌어집니다.
하지만 직접형에서 막힌 순간도 있었어요. 검색 결과가 너무 길 때 토큰을 어디서 자를지 판단해야 했는데, 처음엔 첫 200자만 잘랐더니 핵심 정보가 뒤쪽에 있어서 답변 품질이 떨어지더군요. 정규식으로 핵심 문단을 추출하는 로직을 짜야 했습니다.
투명성과 제어권 — 직접형이 압도적이지만 코드 부담도 있다
내장 웹검색 API는 어떤 출처를 주입하는지 로그에 안 찍혀요. 반면 직접형은 검색 결과 JSON을 손에 쥐고 있으니 "이 출처는 광고성이라 제외" 같은 필터를 걸 수 있죠. 실제로 Serper 결과 중 "Sponsored" 태그 붙은 항목을 자동으로 거르는 스크립트를 짜니, 광고성 결과 혼입이 줄어 답변에 인용되는 출처가 눈에 띄게 정리됐습니다.
제어권 측면에서 결정적 차이가 난 건 토큰 예산이 촉박할 때였어요. 긴 대화 히스토리와 함께 웹검색을 요청했더니 내장형이 컨텍스트 한도를 넘어서 에러를 뱉더군요. 직접형은 검색 결과를 상위 3개로 줄이고 스니펫을 100자로 자르니 여유롭게 통과했습니다.
하지만 직접형의 코드 부담은 있어요. 검색 API 키 갱신, 결과 파싱 로직, 토큰 카운팅, 프롬프트 조립을 모두 직접 관리해야 하거든요. 저는 처음 구현에 이틀 걸렸고, 엣지케이스(검색 결과 없음, API 타임아웃) 처리에 추가로 반나절 썼습니다.
어떤 팀이 어떤 방식을 선택해야 할까?
두 달 동안 양쪽을 번갈아 써본 결과, 제 결론은 이렇습니다.
- 월 처리량이 5,000건 이상이고 개발자가 최소 한 명 있다면 직접 조립형을 쓰세요. 비용 절감이 확실하고, 출처 필터링이나 토큰 예산 조절 같은 제어가 가능하니 장기적으로 이득이 큽니다. 제 경우 월 6,000건 기준으로 월 $24를 아꼈는데, 1년이면 $288이에요.
- 프로토타입 단계이거나 월 처리량이 1,000건 이하, 개발 리소스가 없는 1인 팀이라면 내장형이 낫습니다. 코드 한 줄로 끝나는 편의성은 무시 못 해요. 비용 차이가 월 $5~$10 수준이라면 구현·유지보수 시간을 쓰는 게 더 비효율적이죠.
마무리 — 비용 투명성이 필요한 순간이 온다
처음 웹검색 내장 API를 썼을 때는 편했지만, 처리량이 늘고 월 청구액이 올라가자 토큰 하나하나가 어디에 쓰이는지 궁금해지더군요. r/OpenAI에 올라온 87% 불필요 토큰 보고를 보고 제 상황에 대입해보니, 직접형 전환으로 상당한 비용을 아낄 수 있다는 확신이 들었습니다.
제가 직접형으로 전환한 계기는 단순히 비용 때문만은 아니었어요. "내 파이프라인이 정확히 뭘 하고 있는지 알고 싶다"는 욕구가 더 컸죠. 여러분도 월 처리량과 개발 여력을 저울질해보세요. 비용 투명성이 필요한 순간은 생각보다 빨리 찾아옵니다.