가상 면접 사례로 배우는 생성형 AI 서비스 설계 - 생성형 AI 개요

들어가며

가상 면접 사례로 배우는 생성형 AI 서비스 설계 책을 읽고, 1장 '생성형 AI 개요'에서 이해한 내용을 정리했습니다.

1장은 본격적인 시스템 설계로 들어가기 전에 생성형 AI가 무엇이고, 왜 하필 지금 이 기술이 통하게 되었는지를 짚는 장입니다. 개별 모델의 동작 원리보다는 뒤에서 다룰 설계 이야기의 전제를 깔아주는 역할에 가깝습니다.

1. 인공지능, 머신러닝, 생성형 AI

인공지능은 컴퓨터 과학의 한 분야로, 추론·계획·문제 해결처럼 사람의 지능이 필요한 일을 기계가 수행하도록 하는 것을 목표로 합니다.

용어가 자주 섞여 쓰이는데, 포함 관계로 보면 정리가 됩니다.

• 인공지능 : 사람의 지능이 필요한 작업을 수행하는 시스템 전반. 사람이 규칙을 직접 적어넣은 규칙 기반 시스템도 여기에 들어갑니다.
• 머신러닝 : 규칙을 사람이 적는 대신 데이터로부터 학습하는 알고리즘. 인공지능의 부분집합입니다.
• 판별형 / 생성형 : 머신러닝 모델이 데이터의 무엇을 학습하느냐에 따른 구분.

여기서 놓치기 쉬운 점은 판별형과 생성형이 서로 다른 기술이 아니라는 것입니다. 같은 데이터를 두고 어떤 확률분포를 학습하느냐가 다를 뿐입니다.

판별형

판별형 모델은 입력의 특징을 보고 클래스 사이의 경계를 찾습니다. 입력 X가 주어졌을 때 정답이 Y일 확률, 즉 조건부확률 P(Y|X) 를 학습합니다.

주로 분류와 회귀에 쓰입니다. 스팸 메일 분류, 이미지 분류, 집값 예측 같은 작업이 여기에 해당합니다.

판별형 모델은 데이터가 어떻게 생겼는지에는 관심이 없습니다. 라벨을 가르는 데 필요한 특징만 학습하면 되기 때문에, 같은 데이터양이라면 분류 성능은 대체로 판별형 쪽이 좋습니다.

대신 새로운 데이터를 만들어낼 수는 없습니다. 경계선만 알고 있지, 데이터가 어떤 모양으로 분포하는지는 모르기 때문입니다.

생성형

생성형 모델은 데이터에 내재된 분포 자체를 이해하고 복제하는 작업을 합니다. 데이터 자체의 분포 P(X) 나, 라벨까지 포함한 결합분포 P(X, Y) 를 학습합니다.

분포를 알고 있으면 거기서 샘플링해서 학습 데이터에는 없던 새로운 인스턴스를 만들어낼 수 있습니다. 이것이 '생성'입니다.

한 가지 더 짚어두면, 결합분포 P(X, Y) 를 알고 있으면 베이즈 정리로 P(Y|X) 를 유도할 수 있습니다. 즉 생성형 모델은 판별 작업도 할 수 있지만, 판별형 모델은 생성을 할 수 없습니다. 대신 분포 전체를 배워야 하므로 훨씬 많은 데이터와 연산이 듭니다. 뒤에 나오는 "왜 이제서야 생성형 AI인가"라는 이야기가 결국 이 비용 문제와 이어집니다.

2. 생성형 AI가 인기를 얻은 이유

크게 두 가지로 정리됩니다.

1. 도메인을 넘나드는 작업 수행

기존 머신러닝 모델은 작업 하나에 모델 하나였습니다. 스팸 분류기는 스팸만 걸렀고, 번역기는 번역만 했습니다. 반면 지금의 생성형 모델은 하나의 모델로 요약, 번역, 코드 작성, 문서 초안까지 처리합니다. 작업마다 모델을 새로 학습시킬 필요가 없다는 점이 이전과 가장 크게 달라진 부분입니다.

2. 생산성 향상

글쓰기, 코딩, 자료 정리처럼 사람이 시간을 많이 쓰던 작업의 초안을 대신 만들어줍니다. 완성품을 뽑아주지는 못해도 0에서 1을 만드는 구간을 줄여주기 때문에 체감 효과가 큽니다.

여기에 하나 덧붙이자면, 자연어가 인터페이스가 되었다는 점도 컸다고 생각합니다. 기존 모델은 쓰려면 API 스펙과 입력 형식을 알아야 했지만, 지금은 말로 요청하면 됩니다. 기술 자체보다 진입 장벽이 낮아진 것이 확산 속도를 만들었습니다.

3. 생성형 AI가 강력해진 배경

책은 그 이유를 데이터, 모델, 연산 세 가지로 나눠 설명합니다. 이 셋은 따로 노는 조건이 아니라 서로를 끌어올리는 관계입니다.

3-1. 데이터

모델의 효과는 결국 학습 데이터에 달려 있습니다. 그런데 데이터를 늘리는 데는 오랫동안 라벨링이라는 병목이 있었습니다. 사람이 일일이 정답을 달아줘야 했기 때문에, 데이터를 열 배 늘리려면 비용도 열 배가 들었습니다.

이 지점을 푼 것이 자기지도학습(self-supervised learning) 입니다. 데이터 자체에서 정답을 만들어내는 방식으로, 문장의 다음 단어를 맞추거나 가려진 단어를 복원하는 식입니다. 정답을 사람이 달아줄 필요가 없으니 인터넷에 있는 원시 텍스트를 그대로 학습 데이터로 쓸 수 있게 되었습니다.

라벨링 비용이 사라지자 데이터 규모의 상한이 사실상 풀렸고, 그것이 다음 이야기인 모델 크기 확장의 전제가 됩니다.

3-2. 모델의 역량

모델이 얼마나 많은 것을 담을 수 있는지는 보통 매개변수 수로 이야기합니다. 매개변수는 학습 과정에서 모델이 조정하는 값, 즉 가중치와 편향입니다. 매개변수가 많을수록 더 복잡한 패턴을 담을 수 있습니다.

크기만큼 중요한 것이 구조입니다. 트랜스포머가 전환점이 된 이유는 성능 자체보다도 병렬 학습이 가능한 구조라는 데 있습니다. 순차적으로 처리해야 했던 이전 구조와 달리 GPU를 잔뜩 붙여 한 번에 학습시킬 수 있게 되면서, 모델을 키우는 것이 비로소 현실적인 선택지가 되었습니다.

3-3. 연산 성능

모델과 데이터가 커져도 그것을 실제로 돌릴 하드웨어가 없으면 의미가 없습니다. GPU 성능 향상과 분산 학습 기법이 나머지 한 축을 맡았습니다.

연산량을 이야기할 때 FLOP과 FLOP/s를 구분해서 쓰면 헷갈리지 않습니다.

• FLOP : 부동소수점 연산 횟수. 단위가 붙지 않은 총량입니다. "이 모델을 학습시키는 데 몇 번의 연산이 들었나"를 나타내며, 학습 비용의 척도로 쓰입니다.
• FLOP/s (FLOPS) : 1초 동안 처리 가능한 부동소수점 연산 횟수. 하드웨어의 처리 속도입니다.

둘의 관계는 단순합니다. 필요한 총 연산량(FLOP)을 하드웨어 속도(FLOP/s)로 나누면 학습에 걸리는 시간이 나옵니다. 그래서 같은 모델이라도 더 빠른 GPU를 쓰면 학습 기간이 줄어듭니다.

참고로 트랜스포머 계열 모델의 학습 연산량은 매개변수 수 N과 학습 토큰 수 D에 대해 대략 C ≈ 6ND 로 근사됩니다. 모델을 키우면서 데이터도 함께 늘리면 비용이 곱으로 늘어난다는 뜻이고, 이 제약이 바로 다음 절의 스케일링 법칙으로 이어집니다.

4. 스케일링 법칙

연산 비용은 무한하지 않습니다. 그래서 정해진 예산 안에서 손실을 가장 줄이려면 모델 크기와 데이터양을 어떤 비율로 가져가야 하는가라는 질문이 생깁니다. 스케일링 법칙은 이 질문에 대한 경험적인 답입니다.

핵심은 두 가지입니다.

1. 구조를 바꾸는 것보다 규모를 키우는 쪽이 성능에 더 크게 작용합니다.

모델 구조를 정교하게 손보는 것보다, 같은 구조를 그대로 두고 크게 키우는 쪽이 더 확실한 개선을 냈습니다. 연구의 무게중심이 아키텍처 설계에서 스케일링 전략으로 옮겨간 배경입니다.

2. 손실은 매개변수 수, 데이터 규모, 연산량에 대해 멱법칙을 따라 줄어듭니다.

세 값을 키우면 손실이 예측 가능한 곡선을 그리며 떨어집니다. 학습을 돌려보기 전에 성능을 어느 정도 예측할 수 있다는 뜻이라, 대규모 학습에 예산을 걸 수 있는 근거가 되어주었습니다.

다만 멱법칙이라는 점은 양날입니다. 손실을 일정 폭 더 줄이려면 규모를 몇 배로 키워야 하기 때문에, 키울수록 투입 대비 개선폭은 작아집니다.

한 가지 덧붙이면, 초기에는 예산이 늘면 주로 모델을 키우는 쪽으로 썼습니다. 이후 연구에서 대부분의 모델이 크기에 비해 데이터를 덜 먹은 상태였다는 점이 드러났고, 모델 크기와 학습 토큰 수를 비슷한 비율로 함께 늘리는 것이 같은 예산에서 더 낫다는 쪽으로 정리되었습니다. 실제로 더 작은 모델을 더 많은 데이터로 학습시켜 큰 모델을 앞선 사례가 나오면서, "무조건 크게"에서 "예산에 맞는 균형점" 으로 관점이 옮겨갔습니다.

정리하며

1장을 읽고 남은 것을 한 줄로 요약하면, 생성형 AI는 갑자기 등장한 기술이 아니라 라벨 없는 데이터를 쓸 수 있게 된 것, 병렬로 키울 수 있는 구조가 나온 것, 그것을 감당할 하드웨어가 준비된 것이 같은 시기에 맞물린 결과라는 점입니다.

그리고 스케일링 법칙을 보면서 든 생각은, 결국 이 분야의 설계 문제 대부분이 주어진 예산을 어디에 쓸 것인가의 문제로 환원된다는 것이었습니다. 다음 장부터 나올 서비스 설계 이야기도 같은 질문의 연장선일 것 같습니다.