[WhaTap] GPU·LLM·애플리케이션, '따로' 보면 원인을 놓칩니다

AI 서비스의 문제를 찾으려면 GPU와 LLM, 애플리케이션을 하나의 흐름으로 봐야 합니다.

2026. 7. 30.

안녕하세요, 와탭입니다.

요즘 AI 서비스를 막 운영하기 시작한 팀들과 이야기를 나누다 보면, 약속이나 한 듯 비슷한 장면을 마주하게 됩니다. 오늘은 그 이야기로 시작해 보려 합니다.

"AI 챗봇이 갑자기 평소보다 세 배 느려졌습니다." 이럴 때 어디부터 확인해야 할까요?

추론에 쓰는 GPU가 부족할 수도 있고, 외부 LLM API가 느려졌을 수도 있습니다. RAG 검색 단계에서 병목이 생겼거나, 애플리케이션의 호출 방식이 문제일 수도 있습니다. 문제는 이 모든 원인이 사용자에게는 똑같이 '느린 응답'으로만 보인다는 점입니다.

기업의 AI 투자가 본격화되면서 GPU를 확보하고 LLM 기반 서비스를 만드는 조직이 빠르게 늘고 있습니다. 그런데 막상 서비스를 운영하기 시작하면 예상하지 못한 질문들이 따라옵니다. 와탭이 현장에서 자주 듣는 고민이기도 합니다.

이번 뉴스레터에서 살펴볼 내용

• GPU를 확보하고도 실제 활용률을 알기 어려운 이유

• LLM 서비스의 비용·속도·품질 문제가 숨어드는 지점

• GPU와 LLM, 애플리케이션을 함께 봐야 하는 이유

그럼 지금 어떤 일이 벌어지고 있는지부터 하나씩 짚어보겠습니다.

GPU는 빠르게 늘었지만, 질문은 더 복잡해졌습니다

AI 인프라 확보 경쟁은 개별 기업을 넘어 국가 단위로 커지고 있습니다. 국내에도 앞으로 몇 년간 상당한 규모의 GPU가 들어옵니다.

엔비디아는 2030년까지 국내에 26만 장 이상의 GPU를 공급하기로 했습니다. 자원은 세계적 수준으로 쌓이지만, '얼마나 잘 쓰고 있는가'라는 질문은 그만큼 더 무거워집니다.

출처: 대한민국 정책브리핑, 전자신문 (2025, APEC 계기 한·엔비디아 협력 발표)

자원을 확보하는 일과, 그 자원을 잘 쓰는 일은 전혀 다른 문제입니다.

GPU는 확보했다고 해서, 잘 쓰고 있는 것은 아닙니다

비싼 자원일수록 '실제로 얼마나 쓰이는지'가 중요합니다. 하지만 확보한 GPU의 사용률과 유휴 시간을 파악하지 못하면, 투자는 곧 비용으로 남습니다. 일부 산업 조사에서는 기업의 평균 GPU 활용률이 50%를 밑도는 것으로 나타납니다.

활용률이 낮아지는 이유는, 다음 세 가지가 한 화면에 보이지 않기 때문입니다.

• 누가 쓰는가 : 팀·프로젝트별 사용량이 흩어져 책임 소재가 불분명합니다.

• 얼마나 쓰는가 : 할당만 받고 쉬는 유휴 GPU가 조용히 비용을 발생시킵니다.

• 어디가 막히는가 : 메모리·연산·통신 중 어디서 병목이 오는지 파악하기 어렵습니다.

총평균만 보면 유휴 구간이 잘 드러나지 않습니다. 시간대별로 나누어 보면, 업무 시간 이후 자원이 반복적으로 쉬는 패턴이 보입니다.

GPU 관측의 핵심은 보유량이 아니라, 실제 사용 맥락을 보는 것입니다.

정상 응답만으로는 LLM의 품질을 알 수 없습니다

LLM을 핵심 기능으로 쓰는 서비스가 빠르게 늘고 있습니다. 하지만 LLM 기반 서비스는 응답 코드가 200 OK 라고 해서 정상이라고 단정하기 어렵습니다. 답변이 사실과 다르거나, 민감 정보를 포함하거나, 지나치게 많은 토큰을 썼을 수 있기 때문입니다.

• 비용 : 불필요하게 긴 프롬프트와 반복되는 재시도로 비용이 조용히 늘어납니다.

• 속도 : 응답이 느려져도 모델·검색·네트워크 중 어디가 원인인지 알기 어렵습니다.

• 품질 : 환각, 편향, 민감 정보 노출이 응답 안에 숨어 있을 수 있습니다.

속도 문제를 예로 들면, 사용자가 질문한 뒤 첫 답변이 나오기까지 걸리는 시간과, 그 이후 답변이 생성되는 속도를 나누어 보면 지연이 시작된 위치를 더 정확히 짚을 수 있습니다. 최근에는 운영자들이 이런 지표를 먼저 챙길 만큼 눈높이가 올라와 있습니다.

TTFT (Time To First Token) : 질문 후 첫 응답 토큰이 나오기까지 걸리는 시간

TPOT (Time Per Output Token) : 첫 토큰 이후 토큰 하나가 생성되는 데 걸리는 평균 시간

핵심은 '응답했는가'가 아니라, '어떻게 응답했는가'를 보는 것입니다.

세 개의 화면으로는 하나의 원인을 찾기 어렵습니다

기존 IT에서는 각 계층이 비교적 독립적이었습니다. 'DB가 느리다'면 DB만 보면 됐습니다. 하지만 AI 시스템은 계층이 서로 얽혀 있어, 한 계층의 문제가 다른 계층의 증상으로 나타납니다.

앞서 예로 든 "챗봇이 세 배 느려졌다"는 상황에도 최소 네 가지 원인이 숨어 있습니다.

• GPU : 추론용 자원이 부족했을 수 있습니다.

• LLM : 외부 모델 API 응답이 지연됐을 수 있습니다.

• RAG : 검색 단계에서 병목이 생겼을 수 있습니다.

• 애플리케이션 : 잘못된 호출 방식이 원인일 수 있습니다.

문제는 이 계층들을 각각 다른 도구로 보고 있다는 점입니다. GPU 도구, LLM 도구, 애플리케이션 도구가 따로 있으면, 계층 사이의 인과 관계는 어디에도 보이지 않습니다. 결국 사람이 세 화면을 오가며 머릿속에서 짜맞춰야 합니다.

세 개의 화면으로는 하나의 원인을 찾기 어렵습니다

앞서 예로 든 "챗봇이 세 배 느려졌다"는 상황에도 최소 네 가지 원인이 숨어 있습니다.

• GPU : 추론용 자원이 부족했을 수 있습니다.

• LLM : 외부 모델 API 응답이 지연됐을 수 있습니다.

• RAG : 검색 단계에서 병목이 생겼을 수 있습니다.

• 애플리케이션 : 잘못된 호출 방식이 원인일 수 있습니다.

그래서 AI 관측 솔루션을 검토한다면, 기능 목록보다 다음 기준을 먼저 확인하는 편이 좋습니다.

✓ 인프라와 애플리케이션 데이터를 연결할 수 있는가

✓ GPU·LLM·RAG 등 여러 계층을 하나의 맥락으로 볼 수 있는가

✓ 단순 지표를 넘어 원인 분석을 지원하는가

✓ 서비스·업무·팀 단위로 자원 사용을 구분할 수 있는가

중요한 것은 각 지표가 아니라, 지표 사이의 인과 관계입니다.

와탭은 이 데이터를 하나의 운영 흐름으로 연결합니다

이런 흐름에 맞춰 시장에는 GPU 모니터링과 LLM 옵저버빌리티를 제공하는 솔루션이 늘고 있습니다. 다만 각 계층을 별도 화면에서 보여주는 경우가 많아, 서비스 지연과 인프라 문제 사이의 관계를 파악하기는 여전히 어렵습니다.

와탭도 이 문제를 해결하기 위한 선택지 중 하나입니다. 오랜 기간 애플리케이션과 인프라를 관측해 온 경험을 바탕으로, GPU와 LLM 데이터를 연결하고 사용자의 요청부터 실제 자원 사용까지 하나의 흐름으로 추적하는 방향으로 제품을 확장하고 있습니다. 나아가 상태를 분석하는 단계에서 원인을 추론하고 대응을 돕는 단계로 로드맵을 이어가고 있습니다.

오늘의 요약

• GPU 관측의 핵심은 보유량이 아니라 실제 사용 맥락입니다.

• LLM은 응답 여부를 넘어 비용·속도·품질까지 봐야 합니다.

• AI 운영의 관건은 각 지표가 아니라 지표 사이의 인과 관계입니다.

AI 운영에서 중요한 것은 더 많은 지표를 모으는 일이 아니라, 서로 다른 지표 사이의 관계를 이해하는 일입니다. GPU와 LLM, 애플리케이션을 하나의 흐름으로 볼 수 있어야 원인도 더 빨리 찾을 수 있습니다.

와탭도 이 방향으로 제품을 넓혀가고 있습니다. 앞으로도 실제 운영팀이 마주하는 문제와 그 해결 방법을 뉴스레터로 전해드리겠습니다.

여러분의 조직에서는 AI 서비스에 문제가 생겼을 때, 어디부터 확인하고 계신가요?

GPU와 LLM, 애플리케이션을 한 화면에서 관측하는 경험을 직접 확인해 보세요.

👉 와탭 무료로 시작하기

어떤 제품으로 관측하는지 궁금하다면?

👉 와탭 제품 라인업 알아보기