【국립대학교와 연구한 테크 리드가 말하는 AI의 뒷모습 제2회】 Gemini 1.5 Pro의 진실과 억 단위의 액세스를 처리하는 뒷세계

지난 제1회에서는 AI가 단어의 의미를 「이해」하고 있는 것이 아니라, 거대한 뉴럴 네트워크 (Neural Network)를 이용한 「매우 고도화된 연상 게임 (확률적 추론)」을 수행하고 있을 뿐이라는 점을 해설했습니다.

하지만 AI의 진짜 대단함, 그리고 무서움은 「모델의 똑똑함」만이 아닙니다.

전 세계에서 끊임없이 쏟아지는 억 단위의 액세스를 치명적인 에러나 정보 유출 없이, 악의적인 공격으로부터 지켜내며, 나아가 미리 정해진 GPU 리소스 제한 내에서 순식간에 처리해내는 것. 이 「인프라와 운영의 아키텍처 (Architecture)」야말로 진정한 괴물입니다.

본 연재의 제2회인 이번에는 AI의 뒷면에서 꿈틀거리는 실태에 다가갑니다.

우리가 평소 사용하고 있는 Gemini 1.5 Pro의 「진정한 스펙」에 대한 추측부터, 해커와의 알려지지 않은 공방전까지, 시스템 엔지니어라면 피가 끓을 「투박한 인프라의 현실」을 파헤쳐 보겠습니다.

우리가 사용하는 AI는 사실 훨씬 더 똑똑한 것이 아닐까? 그런 의문을 가져본 적 없으신가요.

우리가 이용하고 있는 API 버전이나 Web 버전의 Gemini 1.5 Pro는 의도적으로 성능이 제한(Detune)되어 있습니다. Google의 연구소 내부에서는 아마도 현재의 수십 배에 달하는 컨텍스트 (Context)를 순식간에 처리할 수 있는 「본래의 괴물」이 움직이고 있을 것입니다.

"최신 AI를 써봤지만, 조금 복잡한 지시를 내리면 금방 무너지네. AI의 한계는 이 정도인가"

엔지니어 중에도 출시된 API의 성능만을 보고 그렇게 판단해 버리는 사람이 있습니다. 하지만 시스템 인프라의 관점에서 보면 그것은 큰 오해입니다. 그들은 「지능의 한계」로 틀린 것이 아니라, 「계산 비용과 응답 시간 (Response Time)의 제약」에 의해 사고를 중단당하고 있는 것입니다.

왜 Google 정도의 기업이 성능을 제한하여 출시하는 것일까요? 이유는 단순합니다. 비즈니스로 성립되지 않기 때문입니다.

추론 (Inference)에는 막대한 GPU/TPU 리소스와 전력이 소모됩니다.

여기서 잠시 페르미 추정 (Fermi Estimation)을 해보겠습니다. Google의 최신 TPU (Tensor Processing Unit) 클러스터 규모와 1.5 Pro가 자랑하는 수백만 토큰의 처리 능력으로부터 역산합니다. 만약 그들이 연구소 (Google DeepMind)에서 가동하고 있는 「일체의 제한이나 중단이 없는 완전판 모델」을 그대로 일반 공개한다면, 1개의 요청을 처리하는 데 필요한 하드웨어 점유 시간과 소비 전력의 원가는 1회당 수백 엔에서 수천 엔 규모가 될 것으로 추측됩니다.

이를 무료 사용자나 저가형 API 플랜에 개방한다면, Google의 서버군은 열기로 녹아내려 며칠 만에 대적자로 전락할 것입니다. 그렇기에 우리가 접하고 있는 것은 「제한 시간 내에, 한정된 리소스로, 적당한 정답을 내도록 최적화 (양자화 (Quantization)나 가지치기 (Pruning))된 모델」인 것입니다.

일반 공개용 모델에서는 너무 긴 계산을 피하기 위해 「Early Exit (조기 종료)」와 같은 아키텍처가 포함되어 있다고 추측할 수 있습니다.

# 【의사 코드】 추론 비용을 제한하는 아키텍처의 추상화
def generate_response(prompt: str, user_tier: str) -> str:
# 사용자의 플랜 (무료, API, Pro 등)에 따라 계산 리소스의 상한을 결정
...

특정 연구자만이 다룰 수 있는 폐쇄 환경이라면, max_compute_budget을 무한히 설정하여 모든 레이어 (Layer)를 여러 번 왕복하며 추론하게 하는 것이 가능합니다.

그때의 Gemini의 진정한 IQ는 우리의 상상을 초월하는 수준에 도달해 있을 것입니다.

F1 카 (연구소 모델)와 양산차 (릴리스 버전)의 차이입니다.

F1 카는 시속 300km 이상으로 달릴 수 있지만, 연비가 너무 나빠 일반 도로 (일반 공개)에서는 달릴 수 없고 아무도 운전할 수 없습니다. 그래서 제조사는 F1에서 쌓은 기술을 사용하여, 연비가 좋고 누구나 안전하게 운전할 수 있는 양산차 (우리가 사용하고 있는 AI)로 디튠 (Detune)하여 판매하고 있는 것입니다.

AI의 이용자 = 인간이라는 상식은 버리십시오.

AI에 액세스하고 있는 것은 인간뿐만이 아닙니다. 프로그램 (RPA나 API)에 의한 무자비한 자동 액세스나, 제한을 돌파하려는 해커의 공격이 매초 수만 건 수준으로 인프라에 쏟아지고 있습니다.

Web 화면의 채팅 UI에서 「인간이 하나씩 질문을 입력하고 있다」는 것은 빙산의 일각입니다.

이면에서는 기업의 업무 시스템(RPA)으로부터 「모든 고객 데이터를 한꺼번에 요약하라」는 초거대 요청이 API를 통해 무수히 날아옵니다. 더욱 무서운 것은, 악의적인 해커들이 DDoS 공격처럼 대량의 트래픽을 가하면서 AI의 보안 취약점(Security Hole)을 찌르려 한다는 점입니다. 이러한 「기계적인 액세스」를 그대로 받아들이면, 일반 사용자의 응답 속도가 극도로 악화되거나 시스템 전체가 다운되어 버립니다.

이를 방지하기 위해, AI 인프라 전단에는 매우 견고한 「트래픽 제어·라우팅 계층 (Traffic Control/Routing Layer)」이 존재합니다.

대표적인 것이 「토큰 버킷 알고리즘 (Token Bucket Algorithm)」 등을 이용한 엄격한 레이트 리미트 (Rate Limit, API 호출 횟수 제한)입니다. 인간으로부터의 요청과 프로그램으로부터의 요청을 IP나 헤더(Header)로 판정·분리하여, 우선순위가 높은 큐(Queue)와 낮은 배치 처리용(Batch Processing) 큐로 분배합니다.

또한, 유사한 질문이 대량으로 들어오는 경우에는 모델에 추론시키기 전에 캐시 계층(Redis 등)에서 즉시 반환(시맨틱 캐시, Semantic Cache)함으로써, 귀중한 GPU 리소스의 고갈을 방지하고 있습니다.

AI 추론 서버(GPU)에 도달하기 전에 요청을 어떻게 처리하고 있는지에 대한 인프라 아키텍처 추측도입니다.

// 【의사 코드】 API 게이트웨이 계층에서의 트래픽 제어 로직
async function handleAiRequest(request) {
const clientId = request.headers['x-api-key'] || request.ip;
...

「1시간에 몇 억 건의 액세스」라는 엄청난 처리를 에러 없이 해낼 수 있는 것은, AI 모델이 우수해서가 아니라, 이 전단의 API 게이트웨이나 큐잉 시스템(Queuing System)을 설계한 인프라 엔지니어들의 피와 땀의 결정체입니다.

인기 라멘집(AI)에 몰려드는 손님을 처리하는 「능숙한 안내원」입니다.

가게의 좌석 수(GPU)는 한정되어 있는데, 인간뿐만 아니라 자동 주문 로봇이나 공짜로 먹으려는 사기꾼이 1초에 1만 명씩 몰려드는 상황을 상상해 보십시오. 안내원은 순식간에 「당신은 로봇이니까 나중에」, 「당신은 어제도 왔으니까 이 자리」, 「당신은 출입 금지」라며 정리권을 배부하여, 주방이 패닉에 빠지지 않도록 컨트롤하고 있는 것입니다.

아무리 성능이 좋아도, 「한 마디의 실언」이 기업을 망하게 하는 것이 AI의 세계입니다.

AI의 답변은 메인 모델이 생성한 직후에 그대로 사용자에게 표시되는 것이 아닙니다. 반드시 「안전 필터 (Safety Filter)」라는 엄격한 검열관을 거친 후에 출력됩니다.

AI는 과거의 모든 인터넷 데이터를 학습했기 때문에, 그대로 두면 「폭탄 제조법」, 「특정 민족에 대한 혐오 표현 (Hate Speech)」, 「역사 왜곡」과 같이 기업에 치명적인 인시던트(Incident)가 될 답변을 아무렇지 않게 출력해 버립니다.

제1회에서 설명한 대로, AI는 「확률적으로 올바른 문자열」을 출력하고 있을 뿐이며, 그것이 「법적으로, 혹은 도덕적으로 허용되는가」라는 선악의 개념을 가지고 있지 않습니다. 이를 모델 자체의 학습만으로 100% 방지하는 것은 불가능합니다.

그래서 현재의 상용 AI 시스템에서는 답변을 생성하는 「메인 모델」과는 별개로, 완성된 답변을 검사하는 「도덕 판정용 필터 모델 (가드레일, Guardrail)」을 직렬로 배치하는 아키텍처를 채택하고 있습니다.

나아가, 모델을 똑똑하게 만드는 과정에서 RLHF (Reinforcement Learning from Human Feedback: 인간의 피드백으로부터의 강화학습)라는 기법을 사용합니다. 「이런 답변은 인간이 싫어하니까 점수를 낮춘다」, 「이런 말투는 안전하니까 점수를 높인다」라는 조교를 방대한 시간과 인해전술(어노테이션, Annotation)을 들여 수행하고 있는 것입니다.

사용자의 질문으로부터 답변이 표시되기까지의 안전 확보 파이프라인 (파이프 & 필터 패턴, Pipe & Filter Pattern)입니다.

# 【의사 코드】 절대로 논란을 일으키지 않기 위한 가드레일 파이프라인
def process_prompt_safely(user_prompt: str) -> str:
# 1. 입력 프롬프트의 독성 체크 (프롬프트 인젝션 등)
...

AI가 가끔 「저는 AI이므로 개인적인 의견은 가지고 있지 않습니다」라고 모범생 같은 답변을 하는 것은, 이 안전 필터가 강력하게 작동하여 리스크가 있는 답변을 낱낱이 차단하고 「무난한 템플릿」으로 교체하고 있기 때문입니다.

실력 있는 셰프(생성 AI)가 만든 요리를 손님에게 내놓기 전에 반드시 맛을 보는 「독 검사관」입니다.

셰프는 천재이지만, 가끔 '맛있지만 맹독을 품은 버섯'을 사용해 버릴 때가 있습니다. 그렇기 때문에 제공하기 전에 반드시 독 검사관(필터 모델 (Filter Model))이 체크하여, 조금이라도 알레르기 유발 물질이나 독이 들어있다면 폐기하고 무난한 샐러드로 교체합니다. 이 독 검사관을 육성하기 위해, 인간이 수만 번이나 "이것은 독!" "이것은 안전!"이라고 가르치는 꾸준한 작업이 RLHF입니다.

제2회에서는 AI를 지탱하는 인프라와 운용의 뒷면에 다가갔습니다.

AI가 '단순히 똑똑한 프로그램'이 아니라, 제한된 리소스 안에서의 비용 계산, 해커나 RPA로부터의 방어전, 그리고 절대로 논란(炎上)을 일으키지 않기 위한 겹겹의 검열 시스템이라는, 지저분하고 치열한 인프라 기술의 결정체라는 점을 이해하셨으리라 생각합니다.

우리 엔지니어가 API를 호출하여 몇 초 만에 돌아오는 답변의 이면에서는, 이토록 처절한 싸움이 펼쳐지고 있는 것입니다.

자, 드디어 다음 회는 최종회(제3회)입니다.

"AI를 쓰면 금방 할 수 있잖아?"라는 비즈니스 측의 무리한 요구에 맞서기 위해, "왜 AI 개발은 지옥인가? 현장 엔지니어가 울며 매달리는 어려운 점 TOP 5"를 전달해 드립니다. 무한한 데이터 청소, 테스트할 수 없는 공포, 그리고 해커와의 쫓고 쫓기는 싸움……. 현장의 리얼한 비명에 기대해 주세요!

TPU (Tensor Processing Unit)

Google이 독자적으로 개발한, 머신러닝 (AI)의 계산 처리에 특화된 전용 프로세서. GPU보다 더욱 AI의 추론·학습 병렬 처리에 최적화되어 있다. -
페르미 추정 (Fermi Estimation)

실제로 조사하기 어려운 수치를, 몇 가지 단서가 되는 기지의 데이터를 바탕으로 논리적으로 추론하여 개략적인 수치를 도출하는 기법. -
토큰 버킷 알고리즘 (Token Bucket Algorithm)

네트워크의 트래픽 제어 (Rate Limit)에서 자주 사용되는 알고리즘. 일정 속도로 버킷에 "토큰 (Token)"이 보충되며, 요청 처리 시 토큰을 소비한다. 버킷이 비어 있으면 에러를 반환하는 구조. -
시맨틱 캐시 (Semantic Cache)

일반적인 캐시 (완전히 일치하는 문자열만 재사용)와는 달리, 입력된 문장의 "의미"를 벡터화하여 비교하고, 의미가 가까우면 과거의 답변을 재사용하는 구조. AI의 계산 비용 절감을 위한 핵심 카드. -
RLHF (Reinforcement Learning from Human Feedback)

인간의 피드백을 이용한 강화학습 (RL). AI가 내놓은 여러 답변에 대해 인간이 "좋음·나쁨"의 평가 (랭킹)를 수행하여, AI가 인간의 가치관이나 윤리관에 부합하도록 길들이는 기법.