인공지능 작동 원리 — 데이터로 학습하고 추론하는 비용 판단 기준

TL;DR AI 원리는 데이터로 파라미터를 맞추는 학습과, 그 모델로 다음 토큰을 확률로 고르는 추론 두 과정입니다. 비용과 위험도 이 둘에서 갈립니다.

2026년 국내 기업과 공공기관의 AI 도입 담당자는 “AI가 어떻게 답을 만드는가”를 알아야 예산·보안·품질을 판단할 수 있기 때문에, 이 글은 학습·추론·토큰이라는 세 가지 열쇠말을 통해 AI 원리를 처음부터 끝까지 풀어 설명합니다.

“AI 원리”나 “인공지능 작동 원리”를 검색하면 신경망 그림, 트랜스포머 논문 해설, 챗봇 사용법이 뒤섞여 나옵니다. 각각은 맞는 설명이지만 처음 읽는 사람에게는 조각난 지도에 가깝습니다. 이 글은 조각을 한 줄로 꿰어 봅니다. 데이터가 어떻게 모델이 되고, 모델이 어떻게 답을 내며, 그 과정에서 비용과 위험이 어디서 생기는지를 순서대로 정리합니다. AI가 무엇인지부터 큰 그림을 잡고 싶다면 AI(인공지능)란 무엇인가를 먼저 읽고 오면 흐름이 이어집니다.

AI 원리를 검색하는 IT 의사결정권자와 실무자가 실제로 궁금해하는 질문을 순서대로 골랐습니다.

1. AI 원리를 한 문장으로 설명하면 무엇인가
2. 규칙을 짜 넣은 프로그램과 학습하는 AI는 무엇이 다른가
3. AI는 데이터에서 무엇을, 어떻게 배우는가
4. 토큰과 임베딩은 무엇이고 한국어는 왜 토큰을 더 쓰는가
5. AI는 왜 같은 질문에도 다른 답을 내고, 왜 그럴듯하게 틀리는가
6. 학습 비용과 추론 비용은 어떻게 다르고 무엇이 비용을 키우는가
7. RAG·파인튜닝·프롬프트는 원리상 어떤 차이가 있는가
8. 기업은 AI 원리를 알고 나서 무엇을 점검해야 하는가

AI 원리를 가장 짧게 줄이면 이렇습니다. AI는 데이터에서 패턴을 숫자로 배워 두었다가, 새 입력이 들어오면 그 숫자로 가장 그럴듯한 출력을 계산하는 프로그램입니다. 여기서 “배워 두는” 과정을 학습(training)이라 하고, “계산해 내는” 과정을 추론(inference)이라 합니다. 오늘날 쓰이는 거의 모든 AI는 이 두 과정의 조합으로 움직입니다.

예를 들어 스팸 메일 필터는 수십만 통의 메일과 “스팸인지 아닌지”라는 정답을 보면서, 어떤 단어와 발신 패턴이 스팸과 함께 나오는지를 숫자로 기록합니다. 이것이 학습입니다. 새 메일이 오면 기록해 둔 숫자를 적용해 스팸일 확률을 계산합니다. 이것이 추론입니다. ChatGPT 같은 대화형 AI도 구조는 같습니다. 차이는 다루는 데이터가 메일 대신 인터넷 규모의 글이고, 계산 결과가 “스팸 확률” 대신 “다음에 올 글자 조각의 확률”이라는 점뿐입니다.

이 관점은 기업 의사결정에 바로 쓰입니다. 학습은 한 번에 크게 드는 비용이고, 추론은 사용할 때마다 쌓이는 비용입니다. 학습에 쓴 데이터가 모델의 지식 한계를 정하고, 추론 방식이 응답 속도와 운영비를 정합니다. 그래서 AI 원리를 이해하면 “어느 모델을 살까”보다 먼저 “우리는 학습에 돈을 쓸 것인가, 추론에 돈을 쓸 것인가”를 물을 수 있습니다.

표에서 볼 수 있듯 대부분의 기업에게 AI 원리의 실무적 의미는 추론 쪽에 몰려 있습니다. 거대한 모델을 처음부터 학습시키는 곳은 국내외를 통틀어 손에 꼽히고, 나머지 조직은 이미 학습된 모델을 골라 자기 데이터와 업무에 맞게 추론을 설계하는 일을 합니다. 이 글의 뒷부분이 추론 비용과 운영 기준에 많은 분량을 쓰는 이유입니다.

AI 원리를 이해하는 첫 관문은 “사람이 규칙을 쓰는가, 데이터가 규칙을 만드는가”의 차이입니다. 전통적인 프로그램은 사람이 조건문으로 규칙을 적습니다. “금액이 1,000만 원을 넘고 해외 송금이면 경고”처럼 말입니다. 규칙이 명확하고 예외가 적은 업무에서는 지금도 이 방식이 가장 싸고 정확합니다.

문제는 규칙을 말로 적을 수 없는 일입니다. 사진 속 제품의 미세한 흠집, 민원 글에 담긴 불만의 강도, 계약서 문장의 위험한 뉘앙스는 조건문으로 옮기기 어렵습니다. 학습 기반 AI는 여기서 출발합니다. 사람은 규칙 대신 예시와 정답을 주고, AI가 예시에서 규칙에 해당하는 숫자를 스스로 찾습니다. 이 방식을 머신러닝이라 부르고, 여러 층의 인공신경망으로 숫자를 찾는 방식을 딥러닝이라 부릅니다. 둘의 관계와 차이는 AI·머신러닝·딥러닝 차이 정리에서 따로 자세히 다룹니다.

두 방식은 경쟁 관계가 아니라 분업 관계입니다. 국내 은행의 이상거래탐지 시스템을 보면 법규와 내부 통제 기준은 규칙으로 걸러 내고, 규칙으로 잡기 어려운 새로운 사기 패턴은 학습 모델이 점수를 매기는 구조가 흔합니다. 규칙은 설명 가능하고 학습 모델은 유연합니다. 어느 쪽이 더 좋은가가 아니라, 업무마다 어느 쪽 성질이 더 필요한가를 따지는 것이 실무의 질문입니다.

마지막 행이 중요합니다. 규칙 기반 프로그램의 오류는 재현이 쉬워서 고치기도 쉽습니다. 학습 기반 AI의 오류는 확률적이라 같은 질문에서 맞다가도 틀릴 수 있습니다. AI 원리를 아는 조직은 이 차이 때문에 검증과 감시 체계를 처음부터 설계에 넣습니다.

AI가 답을 만드는 흐름은 네 단계로 나누면 한눈에 들어옵니다. 데이터를 모으고, 그 데이터로 학습하고, 학습 결과를 모델로 저장하고, 모델로 추론합니다. 단계마다 들어가는 자원과 생기는 위험이 다르기 때문에, 이 네 단계는 기술 설명이면서 동시에 도입 계획서의 목차이기도 합니다.

첫째 단계는 데이터입니다. 대화형 AI라면 웹 문서, 책, 코드, 논문 같은 글이고, 제조 품질 검사라면 정상과 불량 제품 사진입니다. 데이터의 양보다 더 중요한 것이 품질과 대표성입니다. 특정 공장 조명에서 찍은 사진만으로 학습한 검사 모델은 조명이 바뀐 다른 공장에서 성능이 떨어집니다. AI의 지식 한계는 학습 데이터가 정합니다.

둘째 단계는 학습입니다. 모델이 예측을 내고, 정답과 비교해 얼마나 틀렸는지 계산하고, 덜 틀리는 방향으로 숫자를 조금씩 고치는 일을 수없이 반복합니다. 이 과정에 GPU 같은 가속기가 대량으로 들어갑니다. 셋째 단계는 모델입니다. 학습이 끝나면 그 결과는 수십억~수천억 개의 숫자 묶음, 즉 파라미터 파일로 남습니다. 이 파일이 흔히 말하는 “모델”의 실체입니다.

넷째 단계가 추론입니다. 사용자의 질문을 숫자로 바꿔 모델에 넣고, 모델이 계산한 결과를 다시 사람이 읽는 글이나 판단으로 바꿉니다. 대화형 AI에서는 이 과정이 글자 조각 하나마다 반복됩니다. 사용자가 체감하는 속도·비용·품질은 대부분 이 넷째 단계에서 결정됩니다.

이 표를 업무 과제에 하나씩 대입해 보면 막연한 “AI 도입”이 구체적인 질문으로 바뀝니다. 예를 들어 공공기관 민원 상담 AI라면 데이터 단계에서 개인정보 비식별 기준을, 모델 단계에서 국내 모델 사용 여부를, 추론 단계에서 내부망 운영 가능성을 각각 결정해야 합니다.

학습의 원리는 “틀린 만큼 고친다”는 한 문장으로 요약됩니다. 이 문장을 수학으로 옮긴 것이 손실 함수와 경사 하강입니다. 어렵게 들리지만 산에서 안개 속을 걸어 내려오는 장면으로 생각하면 쉽게 이해할 수 있습니다.

먼저 손실 함수(loss function)는 모델이 얼마나 틀렸는지를 하나의 숫자로 재는 자입니다. 고양이 사진을 보고 “고양이일 확률 30%”라고 답했다면 정답(100%)과의 차이만큼 손실이 큽니다. “고양이일 확률 95%”라고 답했다면 손실이 작습니다. 대화형 AI라면 “다음 단어로 정답 단어에 얼마나 높은 확률을 줬는가”가 손실이 됩니다.

다음으로 경사 하강(gradient descent)은 손실을 줄이는 방향을 찾아 파라미터를 조금씩 옮기는 방법입니다. 안개 낀 산에서 발밑 경사만 느끼며 한 걸음씩 내려가는 등산객을 떠올리면 됩니다. 등산객은 전체 지형을 모르지만 매 걸음 가장 가파르게 내려가는 쪽으로 움직이면 결국 골짜기에 가까워집니다. 여기서 고도가 손실이고, 등산객의 위치가 파라미터 값입니다. 한 번에 내딛는 보폭을 학습률이라 부르는데, 너무 크면 골짜기를 지나쳐 버리고 너무 작으면 내려가는 데 한없이 오래 걸립니다.

신경망은 층이 여러 겹이라 “어느 파라미터를 얼마나 고쳐야 하는가”를 계산하는 일이 복잡합니다. 이 계산을 효율적으로 해 주는 방법이 역전파(backpropagation) 입니다. 출력에서 생긴 오차를 마지막 층에서 첫 층 방향으로 거꾸로 전달하면서, 각 파라미터가 오차에 얼마나 기여했는지를 한 번에 계산합니다. 1980년대에 정리된 이 방법이 지금의 딥러닝을 가능하게 한 핵심 기술입니다.

학습 방식에는 정답을 사람이 붙여 주는 지도 학습, 정답 없이 데이터의 구조를 찾는 비지도 학습, 행동의 결과로 보상을 받는 강화 학습이 있습니다. 대형 언어 모델의 사전 학습은 이 중 특이한 경우입니다. 글 자체에서 “다음 단어”라는 정답을 자동으로 만들어 쓰기 때문에 사람이 라벨을 붙이지 않아도 지도 학습처럼 학습할 수 있습니다. 이를 자기지도 학습이라 부르며, 인터넷 규모의 데이터를 라벨링 비용 없이 쓸 수 있게 한 것이 대형 언어 모델이 가능해진 결정적 이유입니다.

이 과정을 데이터 묶음마다 수백만 번 반복하는 것이 학습입니다. 대형 언어 모델은 수조 개의 토큰을 읽으며 이 반복을 수행하므로 GPU 수천 장이 몇 주에서 몇 달 동안 쉬지 않고 계산합니다. 학습 비용이 큰 이유는 계산 한 번이 비싸서가 아니라 반복 횟수가 상상을 넘을 만큼 많기 때문입니다.

학습에서 조심해야 할 현상이 과적합(overfitting)입니다. 시험 문제를 이해하지 않고 답만 외운 학생처럼, 학습 데이터에는 완벽하지만 처음 보는 데이터에서는 엉뚱하게 답하는 상태입니다. 그래서 실무에서는 데이터를 학습용과 검증용으로 나누고, 검증 데이터 성적이 떨어지기 시작하면 학습을 멈춥니다. 기업이 자체 데이터로 모델을 조정할 때도 같은 원칙을 지켜야 합니다. 평가용 데이터를 학습에 섞지 않는 것이 AI 품질 관리의 첫 규칙입니다.

“70B 모델”, “8B 모델”처럼 AI 모델 이름 뒤에 붙는 숫자는 파라미터 개수를 뜻합니다. B는 10억(billion)이므로 70B는 파라미터가 약 700억 개라는 의미입니다. 파라미터는 학습으로 맞춰진 숫자 하나하나이며, 모델이 배운 지식과 패턴이 이 숫자들에 흩어져 저장됩니다. 데이터베이스처럼 “이 칸에 이 사실”이 저장되는 구조가 아니라, 수많은 숫자의 조합이 패턴을 표현하는 구조입니다.

파라미터가 많을수록 더 복잡한 패턴을 담을 수 있습니다. 2020년 OpenAI의 연구는 모델 크기·데이터 양·연산량을 늘리면 성능이 예측 가능한 규칙에 따라 좋아진다는 스케일링 법칙을 보고했고, 2022년 DeepMind의 Chinchilla 연구는 파라미터만 늘리기보다 학습 데이터도 함께 늘려야 같은 연산량에서 더 좋은 모델이 된다는 점을 보였습니다. 이 연구들이 지난 몇 년간 모델이 빠르게 커진 배경입니다.

그러나 기업 입장에서 큰 모델이 늘 정답은 아닙니다. 파라미터는 추론할 때마다 메모리에 올라가 있어야 하므로, 모델 크기가 곧 추론 서버의 메모리 요구량이 됩니다. 파라미터 하나를 16비트(2바이트)로 저장하면 70B 모델은 가중치만 약 140GB가 필요하고, 8B 모델은 약 16GB면 됩니다. 이 차이가 GPU 한 장으로 돌릴 수 있는가, 여러 장을 묶어야 하는가를 가릅니다.

그래서 국내 기업과 공공기관에서는 범용 대형 모델 대신 특정 업무에 맞춘 수십억~수백억 파라미터의 sLLM(소형 언어 모델)을 내부에 두는 사례가 늘고 있습니다. 민원 분류, 사내 규정 검색, 보고서 요약처럼 범위가 정해진 일은 작은 모델로도 충분한 경우가 많기 때문입니다. 비용 구조는 프라이빗 sLLM과 TCO 정리에서 더 구체적으로 볼 수 있습니다. 모델 크기는 성능의 상한을 정하지만, 업무에 필요한 성능은 대개 그보다 낮은 곳에 있습니다.

대화형 AI의 원리를 이해하려면 토큰을 알아야 합니다. 토큰은 AI가 글을 읽고 쓰는 최소 단위인 글자 조각입니다. AI는 문장을 글자 그대로 받지 않고, 미리 정해 둔 사전에 따라 조각으로 자른 뒤 각 조각에 번호를 붙여 처리합니다. 이 자르는 과정을 토큰화(tokenization)라고 합니다.

토큰은 단어와 같지 않습니다. 자주 쓰이는 영어 단어는 한 단어가 토큰 하나가 되고, 드문 단어는 여러 조각으로 나뉩니다. OpenAI는 영어 기준으로 토큰 하나가 대략 4글자, 단어로는 4분의 3 정도에 해당한다고 안내합니다. 이미지와 음성도 같은 원리로 작은 조각으로 잘라 토큰처럼 다루기 때문에, 오늘날의 멀티모달 AI는 글·그림·소리를 같은 방식으로 처리할 수 있습니다.

한국어 사용자에게 토큰이 중요한 이유는 비용 때문입니다. 많은 모델의 토큰 사전은 영어 비중이 높은 데이터로 만들어져서, 같은 뜻의 문장도 한국어가 영어보다 더 많은 토큰으로 잘리는 경우가 많습니다. 한국어는 조사와 어미가 붙는 교착어라 같은 단어도 형태가 다양하고, 사전에 없는 조합은 더 잘게 쪼개집니다. 최근 모델들은 다국어 사전을 넓혀 이 차이를 줄였고, 국내 기업이 만든 모델은 한국어 토큰 효율을 장점으로 내세웁니다.

구체적인 장면으로 보면 차이가 더 잘 보입니다. “연차 휴가 신청 절차를 알려 주세요”라는 문장은 사람에게는 단어 다섯 개지만, 토큰 사전에 따라 “연차”, “휴”, “가”, “신청”, “절차”, “를”, “알려”, “주”, “세요”처럼 열 개 안팎의 조각으로 잘릴 수 있습니다. 반면 같은 뜻의 영어 문장은 대부분 단어 하나가 토큰 하나라 조각 수가 더 적게 나오는 경우가 많습니다. 정확한 개수는 모델마다 다르므로, 비교할 때는 공개된 토큰 계산 도구에 우리 문서를 직접 넣어 보는 것이 가장 확실합니다.

토큰은 세 가지 숫자를 움직입니다. 첫째, API 요금은 입력 토큰과 출력 토큰 수로 매겨집니다. 둘째, 응답 속도는 출력 토큰 수에 비례합니다. 셋째, 한 번에 넣을 수 있는 문서 분량을 정하는 컨텍스트 창도 토큰 수로 잽니다. 따라서 같은 업무라도 어떤 모델의 토큰 사전을 쓰느냐에 따라 월 비용과 처리 가능한 문서 길이가 달라집니다. 모델을 비교할 때는 영어 벤치마크 점수뿐 아니라 실제 우리 업무 문서를 넣었을 때의 토큰 수를 측정해 봐야 합니다.

토큰 번호만으로는 의미를 알 수 없습니다. 3,401번 토큰과 3,402번 토큰이 비슷한 뜻이라는 보장이 없기 때문입니다. 그래서 AI는 각 토큰을 수백~수천 개의 숫자로 이뤄진 좌표로 바꿉니다. 이것이 임베딩(embedding)이며, 의미가 비슷한 말일수록 좌표 공간에서 가까운 자리에 놓이도록 학습됩니다.

아래 그림은 글이 AI 안에서 거치는 변환을 한 줄로 보여 줍니다. 입력 글이 토큰 번호가 되고, 번호가 임베딩 벡터가 되고, 트랜스포머 계산을 거쳐 다음 단어의 확률이 나온 뒤 다시 글로 돌아오는 순서입니다.

그림. 텍스트가 토큰·임베딩·확률을 거쳐 다시 텍스트로 돌아오는 대화형 AI의 다섯 단계

지도에 비유하면 쉽습니다. 서울과 인천은 지도에서 가깝고 서울과 부산은 멉니다. 임베딩 공간에서는 “계약”과 “협약”이 가깝고 “계약”과 “날씨”는 멉니다. 차이는 지도가 2차원인 데 비해 임베딩은 수천 차원이라는 점입니다. 차원이 많기 때문에 “공식적인 정도”, “법률 분야와 관련된 정도”, “긍정적인 정도”처럼 여러 의미 축을 동시에 담을 수 있습니다.

임베딩은 대화형 AI 내부에서만 쓰이는 개념이 아닙니다. 기업 문서 검색에서 가장 실용적으로 쓰입니다. 사내 문서를 문단 단위로 임베딩해 벡터 데이터베이스에 저장해 두면, 질문의 임베딩과 가까운 문단을 찾아낼 수 있습니다. 키워드가 정확히 일치하지 않아도 뜻이 비슷하면 찾아 주기 때문에 “휴가 규정”을 물었을 때 “연차 사용 지침” 문서를 찾는 검색이 가능해집니다. 이것이 RAG(검색 증강 생성)의 출발점이며, 파이프라인 전체는 RAG란 무엇인가에서 단계별로 정리돼 있습니다.

임베딩에도 한계가 있습니다. 좌표는 학습 데이터에서 함께 쓰인 패턴을 반영하므로, 데이터에 섞인 편견이 좌표에도 남을 수 있습니다. 또 업계 전문 용어나 사내 약어는 일반 임베딩 모델에서 엉뚱한 자리에 놓일 수 있습니다. 사내 검색 품질이 기대에 못 미칠 때는 생성 모델보다 임베딩 모델과 문서 분할 방식을 먼저 점검해야 합니다.

대화형 AI가 답을 만드는 원리는 놀라울 만큼 단순합니다. 지금까지의 글을 보고 다음에 올 토큰 하나의 확률을 계산한 뒤, 하나를 골라 붙이고, 다시 다음 토큰을 계산하는 일을 반복합니다. “대한민국의 수도는”이라는 입력을 받으면 모델은 사전에 있는 수만 개 토큰 전체에 확률을 매기고, “서울”에 가장 높은 확률을 줍니다. “서울”을 붙인 뒤에는 “대한민국의 수도는 서울”을 다시 입력으로 삼아 다음 토큰을 계산합니다. 이 과정을 자기회귀(autoregressive) 생성이라고 부릅니다.

이 원리에서 두 가지 성질이 나옵니다. 첫째, 답이 길수록 계산이 오래 걸립니다. 출력 토큰 하나마다 모델 전체를 한 번씩 계산해야 하기 때문입니다. 긴 보고서를 쓰게 하면 짧은 답보다 느리고 비싼 이유가 여기에 있습니다. 둘째, AI는 답을 미리 정해 두고 쓰는 것이 아니라 한 토큰씩 그 자리에서 고릅니다. 앞에서 고른 토큰이 뒤의 선택을 끌고 가기 때문에, 초반에 엉뚱한 방향을 잡으면 뒤까지 그 흐름이 이어질 수 있습니다.

같은 질문에도 매번 답이 조금씩 다른 이유는 토큰을 고르는 방식에 있습니다. 가장 확률이 높은 토큰만 고르면 답이 늘 같지만 글이 딱딱하고 반복적이 됩니다. 그래서 대부분의 서비스는 확률에 비례해 무작위로 고르는 샘플링을 씁니다. 이때 무작위의 정도를 조절하는 값이 온도(temperature) 입니다. 온도를 낮추면 높은 확률의 토큰이 더 자주 뽑혀 답이 일정해지고, 온도를 높이면 낮은 확률의 토큰도 뽑혀 답이 다양해집니다.

업무 시스템에 AI를 붙일 때 이 설정은 생각보다 큰 차이를 냅니다. 민원 답변처럼 일관성이 중요한 업무에 높은 온도를 쓰면 같은 문의에 다른 안내가 나가는 사고가 생길 수 있습니다. AI 원리를 아는 운영자는 업무 성격에 맞춰 온도를 정하고, 그 값을 설정 관리 대상으로 기록합니다. 다음 토큰 예측과 확률 분포가 신경망 안에서 어떻게 계산되는지는 LLM 작동 원리를 8분 동영상으로 정리한 글이 트랜스포머와 어텐션까지 그림으로 보여 줍니다.

대화형 AI는 대화를 “기억”하는 것처럼 보이지만, 원리를 보면 기억이라기보다 매번 지금까지의 대화 전체를 다시 읽는 방식입니다. 사용자가 세 번째 질문을 하면, 서비스는 첫 질문과 답, 두 번째 질문과 답, 세 번째 질문을 모두 이어 붙여 모델에 다시 넣습니다. 모델 자체는 대화가 끝나면 아무것도 저장하지 않습니다.

이렇게 한 번에 읽을 수 있는 토큰의 최대 분량을 컨텍스트 창(context window) 이라고 합니다. 사람으로 치면 책상 위에 펼쳐 놓을 수 있는 서류의 양입니다. 초기 대화형 모델은 수천 토큰 수준이었지만 지금은 수십만~백만 토큰을 받는 모델도 있습니다. 긴 계약서나 여러 보고서를 한 번에 넣고 비교할 수 있게 된 것이 이 변화 덕분입니다.

그렇다고 컨텍스트 창을 무작정 채우는 것이 좋은 전략은 아닙니다. 첫째, 입력 토큰이 많을수록 요금과 응답 시간이 늘어납니다. 둘째, 연구와 실무 경험 모두에서 긴 입력의 중간에 놓인 정보를 모델이 덜 활용하는 경향이 보고됩니다. 셋째, 컨텍스트 창이 넘치면 앞쪽 대화가 잘려 나가 AI가 앞서 합의한 조건을 “잊은” 것처럼 행동합니다.

숫자로 감을 잡아 보면 이렇습니다. A4 한 쪽 분량의 한국어 문서는 모델과 서식에 따라 대략 1,000~2,000토큰 안팎이 됩니다. 컨텍스트 창이 12만 8천 토큰인 모델이라면 수십 쪽 분량의 보고서를 한 번에 넣을 수 있지만, 그 대가로 질문 한 번마다 수십 쪽을 읽는 요금과 시간을 냅니다. 같은 질문을 하루 수천 번 받는 상담 시스템이라면 이 차이가 월 비용을 몇 배로 벌립니다.

그래서 실무에서는 필요한 정보만 골라 넣는 설계가 중요합니다. 질문과 관련된 문단만 검색해 넣는 RAG, 긴 대화를 중간중간 요약해 두는 방식, 사용자별 선호를 별도 저장소에 두고 필요할 때만 꺼내는 방식이 모두 컨텍스트 창이라는 제약에서 나온 기술입니다. “AI가 우리 회사 일을 기억하게 하려면 무엇을 어디에 저장할 것인가”는 모델 선택이 아니라 시스템 설계의 질문입니다.

인터넷 글을 읽고 다음 토큰을 맞히도록 학습한 모델은 문장을 이어 쓰는 데는 뛰어나지만 그대로는 쓸모 있는 비서가 아닙니다. “보고서 요약해 줘”라고 입력하면 요약 대신 “보고서 요약해 줘라는 요청이 많은 이유는…”처럼 글을 이어 쓰기도 합니다. 이 단계의 모델을 사전 학습(pre-training) 모델 또는 기반 모델이라고 부릅니다.

다음 그림의 왼쪽은 앞 문맥에 따라 다음 단어 후보의 확률이 달라지는 모습을, 오른쪽은 대화형 AI를 만드는 사전 학습·지시 튜닝·정렬의 세 단계를 보여 줍니다.

그림. 문맥에 따라 바뀌는 다음 단어 예측과 사전 학습에서 정렬까지 이어지는 세 단계

쓸모 있는 비서로 만드는 과정이 사후 학습(post-training) 입니다. 첫 단계는 지시 튜닝으로, “이런 요청에는 이렇게 답한다”는 예시 수만~수십만 건을 보여 주며 추가 학습합니다. 다음 단계는 사람의 선호를 반영하는 학습입니다. 같은 질문에 대한 여러 답변을 사람이 비교해 순위를 매기고, 모델이 더 선호되는 답을 내도록 조정합니다. 이 방식을 RLHF(사람 피드백 기반 강화 학습)라고 부르며, 최근에는 비슷한 목적의 다양한 변형 기법이 함께 쓰입니다.

사후 학습의 효과는 생각보다 큽니다. OpenAI의 2022년 InstructGPT 연구에서는 사람 피드백으로 조정한 13억 파라미터 모델의 답변을, 평가자들이 100배 이상 큰 1,750억 파라미터 원본 모델보다 더 선호했습니다. 모델의 크기보다 “어떻게 답하도록 다듬었는가”가 체감 품질을 좌우할 수 있다는 뜻입니다.

기업에게 이 구분은 두 가지 의미가 있습니다. 첫째, 사후 학습 과정에서 안전 기준과 거절 기준이 정해지므로 같은 기반 모델이라도 제공사에 따라 답하는 태도가 다릅니다. 둘째, 기업이 자체 데이터로 하는 파인튜닝은 대부분 이 사후 학습 단계의 연장입니다. 새로운 지식을 대량으로 넣기보다는 말투·형식·업무 절차를 몸에 익히게 하는 작업에 가깝다는 점을 알고 기대치를 정해야 합니다. 생성형 AI 전체의 흐름은 생성형 AI란 무엇인가에서 결과물 종류와 함께 정리돼 있습니다.

2024년 이후 AI 원리에 새로 추가된 흐름이 추론 모델(reasoning model) 입니다. 기존 대화형 AI가 질문을 받자마자 답을 쓰기 시작했다면, 추론 모델은 답을 쓰기 전에 중간 풀이 과정을 길게 생성하고 그 풀이를 바탕으로 최종 답을 냅니다. 수학 문제를 풀 때 바로 답을 적지 않고 연습장에 풀이를 적어 보는 학생과 비슷합니다.

원리상으로는 새로운 마법이 아니라 앞에서 본 다음 토큰 예측의 연장입니다. 다른 점은 강화 학습으로 “풀이를 길게 써서 정답에 도달하는 습관”을 집중적으로 훈련했다는 점과, 추론할 때 더 많은 토큰과 연산을 쓰는 대신 정확도를 높인다는 점입니다. 학습에 연산을 더 쓰던 기존 방향에 더해, 답할 때 연산을 더 쓰는 방향이 열린 것입니다. 이를 테스트 시점 연산(test-time compute)을 늘린다고 표현합니다.

기업 관점에서 추론 모델은 장단점이 분명합니다. 복잡한 규정 해석, 여러 조건이 얽힌 일정 계획, 코드 분석처럼 단계가 많은 문제에서 정확도가 눈에 띄게 오릅니다. 반면 풀이 토큰까지 요금과 시간에 포함되므로 간단한 질문에 쓰면 비용만 늘어납니다. 민원 분류나 짧은 요약처럼 단순한 업무에는 일반 모델을, 판단 근거가 중요한 복잡한 업무에는 추론 모델을 배정하는 식으로 업무별로 나눠 쓰는 것이 합리적입니다.

비용을 가늠할 때 놓치기 쉬운 점이 하나 있습니다. 추론 모델의 풀이 토큰은 사용자 화면의 답변에는 보이지 않아도 출력 토큰으로 계산됩니다. 그래서 답변 길이만 보고 비용을 어림하면 실제 청구액과 어긋나고, 그 차이는 과제가 어려울수록 커집니다. 코드를 고치고 시험하고 다시 고치는 업무처럼 한 과제가 여러 번의 호출로 이어지면, 화면에 남는 결과가 몇 줄이어도 그 뒤에서 생성된 토큰은 수천에서 수만에 이를 수 있습니다. 추론 모델의 비용은 화면이 아니라 서빙 계층이 집계한 토큰 수로 재야 합니다.

비용 차이를 예로 들어 보겠습니다. 일반 모델이 200토큰으로 답하는 질문에 추론 모델은 풀이로 수천 토큰을 쓴 뒤 같은 길이의 답을 낼 수 있습니다. 출력 토큰 단가가 같다면 한 번 묻는 비용이 열 배 이상 차이 나고, 사용자가 기다리는 시간도 그만큼 길어집니다. 그래서 추론 모델을 도입할 때는 “정확도가 몇 % 오르면 이 비용을 감수할 만한가”라는 기준을 업무별로 정해 두는 것이 좋습니다. AI 원리에서 보면 추론 모델은 더 똑똑한 모델이라기보다 더 오래 계산하도록 훈련된 모델입니다.

또 하나 짚을 점은 풀이 과정이 곧 정답의 근거라는 보장은 없다는 것입니다. 풀이가 그럴듯해 보여도 결론이 틀릴 수 있고, 일부 서비스는 풀이를 요약만 보여 줍니다. 감사와 설명 책임이 중요한 공공·금융 업무라면 AI의 풀이를 근거 자료로 그대로 쓰지 말고, 출처 문서와 대조하는 절차를 따로 둬야 합니다.

AI 원리를 비용으로 번역하면 학습과 추론이 전혀 다른 구조라는 점이 드러납니다. 학습은 거대한 데이터를 한꺼번에 처리하는 일이라 GPU 여러 장의 연산 능력(FLOPS)과 GPU 사이의 통신 속도가 병목입니다. 추론은 한 번에 처리하는 양은 작지만 요청이 끊임없이 들어오고, 토큰 하나를 만들 때마다 모델 전체 파라미터를 메모리에서 읽어야 하므로 메모리 용량과 메모리 대역폭이 병목이 되는 경우가 많습니다.

추론 메모리는 모델 가중치만으로 끝나지 않습니다. 대화형 AI는 앞에서 읽은 토큰들의 중간 계산 결과를 저장해 두고 다음 토큰을 만들 때 재사용하는데, 이 저장 공간을 KV 캐시라고 부릅니다. KV 캐시는 입력이 길수록, 동시에 대화하는 사용자가 많을수록 커집니다. 그래서 같은 모델이라도 “10명이 짧게 묻는 서비스”와 “500명이 긴 문서를 넣는 서비스”는 필요한 GPU 메모리가 몇 배씩 차이 납니다.

아래 그림은 다음 토큰을 하나 만들 때마다 앞 토큰들의 계산값을 GPU 메모리에 보관해 다시 쓰는 KV 캐시의 동작을 보여 줍니다.

그림. 토큰 생성과 KV 캐시 재사용, 그리고 그 대가로 늘어나는 GPU 메모리

추론 비용은 빠르게 떨어지고 있습니다. 스탠퍼드 HAI의 2025년 AI 인덱스는 GPT-3.5 수준 성능의 모델을 쓰는 추론 비용이 2022년 11월부터 2024년 10월 사이 280배 넘게 낮아졌다고 보고했습니다. 그러나 단가가 떨어지는 만큼 사용량이 늘어나기 때문에 전체 추론 비용은 오히려 늘어나는 조직이 많습니다. 업무 자동화가 확산되고 에이전트가 사람 대신 여러 번 모델을 호출하면 토큰 사용량은 사람 사용자일 때보다 수십 배로 커질 수 있습니다.

외부 상용 모델을 API로 쓰는 구성에서는 이 구조가 더 직접적으로 드러납니다. 조직은 모델 가중치도 가속기도 갖지 않고, 요청 한 건마다 오간 입력·출력 토큰 수만큼 값을 치릅니다. 공개 가격표를 보면 대부분의 상용 모델이 출력 토큰을 입력 토큰보다 몇 배 비싸게 매기므로, 같은 업무라도 답을 길게 쓰게 하는 설계가 비용을 크게 키웁니다. 국내 조직 상당수가 첫 AI 시스템을 이 형태로 짓고, 사용량이 쌓인 뒤에 내부 구축을 검토하는 순서를 밟습니다.

그래서 추론 비용은 단가가 아니라 구조로 관리해야 합니다. 어떤 업무가 몇 토큰을 쓰는지, 어느 부서가 얼마나 쓰는지, 어떤 요청이 비싼 모델로 가는지를 측정하지 않으면 예산이 언제 넘칠지 알 수 없습니다. GPU 장수보다 GPU를 어떻게 나눠 쓰고 측정하는지가 성패를 가른다는 점은 LLM 도입이 실패하는 이유는 GPU가 부족해서가 아니다에서도 같은 결론으로 다룹니다.

추론 비용과 지연이 메모리에서 생긴다는 원리를 알면, 이를 줄이는 기술도 자연스럽게 이해됩니다. 대부분은 “메모리를 덜 쓰게 하거나, 한 번 읽은 메모리로 더 많은 일을 하게 하는” 방향입니다. 대표 기술 다섯 가지를 정리하면 다음과 같습니다.

첫째, 양자화(quantization) 는 파라미터를 16비트 대신 8비트나 4비트로 줄여 저장하는 방법입니다. 앞에서 본 70B 모델은 16비트로 약 140GB지만 8비트면 약 70GB, 4비트면 약 35GB 수준으로 줄어듭니다. 정밀도를 낮추는 만큼 품질이 조금 떨어질 수 있으므로, 업무 데이터로 전후 성능을 비교해 보고 결정해야 합니다.

둘째, 배치 처리(batching) 는 여러 사용자의 요청을 묶어 한 번에 계산하는 방법입니다. 모델 파라미터를 메모리에서 한 번 읽을 때 여러 요청을 같이 처리하므로 GPU 활용률이 크게 오릅니다. 요청이 들어오는 대로 빈자리에 끼워 넣는 연속 배치(continuous batching)가 요즘 추론 서버의 기본 기능입니다.

셋째, KV 캐시 관리입니다. 2023년 발표된 vLLM 프로젝트는 운영체제의 가상 메모리처럼 KV 캐시를 작은 블록으로 나눠 관리하는 PagedAttention 기법으로 메모리 낭비를 줄였고, 기존 시스템 대비 처리량을 2~4배 높였다고 보고했습니다. vLLM의 구조와 도입 효과는 vLLM이란 무엇인가에 정리돼 있습니다. 같은 질문 앞부분(시스템 프롬프트 등)을 여러 요청이 공유하도록 캐시를 재사용하는 기법도 비용을 크게 줄입니다.

넷째, 모델 배정(라우팅) 입니다. 모든 요청을 가장 큰 모델로 보내지 않고, 간단한 요청은 작은 모델로, 어려운 요청만 큰 모델이나 추론 모델로 보냅니다. 업무량의 상당 부분이 단순 질의라면 이것만으로 비용이 크게 내려갑니다. 다섯째, 추측 디코딩(speculative decoding) 은 작은 모델이 여러 토큰을 미리 써 보고 큰 모델이 한 번에 검증하는 방식으로, 품질을 유지하면서 응답 속도를 높입니다.

이 기술들은 하드웨어 선택과도 연결됩니다. GPU 외에 NPU 같은 추론 전용 가속기가 등장한 것도 추론이 연산보다 메모리 이동에 묶인다는 원리 때문입니다. 가속기 종류와 특성은 AI 가속기란 무엇인가에서 비교할 수 있습니다. 추론 최적화는 모델 교체 없이도 비용을 크게 줄일 수 있는 가장 빠른 수단이므로, 운영팀은 도입 초기부터 측정 지표를 함께 설계해야 합니다.

AI가 사실과 다른 내용을 자신 있게 말하는 현상을 환각(hallucination)이라고 부릅니다. 이 현상은 버그라기보다 다음 토큰 예측이라는 AI 원리에서 자연스럽게 나오는 성질입니다. 모델은 “사실인 문장”을 고르도록 학습된 것이 아니라 “그럴듯한 다음 토큰”을 고르도록 학습됐기 때문입니다. 학습 데이터에 없는 질문을 받아도 모델은 “모르겠다”보다 그럴듯한 문장을 이어 쓰는 쪽으로 기울기 쉽습니다.

환각이 자주 생기는 조건은 원리로 설명됩니다. 첫째, 학습 데이터가 끝난 시점 이후의 일을 물을 때입니다. 모델의 지식은 학습 시점에 멈춰 있습니다. 둘째, 사내 규정이나 최신 단가처럼 공개 데이터에 거의 없는 정보를 물을 때입니다. 셋째, 숫자·고유명사·인용처럼 정확한 값이 필요한 질문입니다. 확률적으로 비슷한 숫자나 이름이 섞여 나오기 쉽습니다. 넷째, 앞에서 본 것처럼 온도가 높거나 질문이 모호할 때입니다.

따라서 환각을 줄이는 방법도 원리에서 나옵니다. 모델이 기억에 의존하지 않도록 근거 문서를 입력에 함께 넣어 주고(RAG), 답변에 출처를 표시하게 하며, 정확한 값이 필요한 계산이나 조회는 모델이 직접 하지 않고 계산기·데이터베이스 같은 도구를 호출하게 합니다. 온도를 낮추고 질문 형식을 표준화하는 것도 도움이 됩니다. 문서 간 관계까지 함께 검색하는 방식은 GraphRAG로 구현하는 정확한 엔터프라이즈 AI에서 사례로 볼 수 있습니다.

그러나 어떤 방법도 환각을 0으로 만들지는 못합니다. 그래서 운영 기준이 필요합니다. 대국민 안내, 대출 심사, 의료 정보처럼 오류 비용이 큰 업무는 AI가 초안을 만들고 사람이 확인하는 구조로 시작하고, 정답 데이터셋으로 정기적으로 정확도를 측정해야 합니다. 환각률을 측정하지 않고 “우리 AI는 정확하다”고 말하는 것은 원리상 근거가 없는 주장입니다.

AI를 우리 회사 업무에 맞추는 방법은 크게 세 가지입니다. 질문 방식을 다듬는 프롬프트 설계, 근거 문서를 찾아 입력에 넣어 주는 RAG, 모델의 파라미터 자체를 추가 학습으로 바꾸는 파인튜닝입니다. 셋은 자주 비교되지만 원리로 보면 바꾸는 대상이 서로 다릅니다. 프롬프트와 RAG는 추론 단계의 입력을 바꾸고, 파인튜닝은 학습 단계로 돌아가 모델을 바꿉니다.

아래 표 슬라이드는 같은 목적을 이루는 방법을 학습 쪽과 추론 쪽으로 나눠 정리한 것입니다. 실무 개발은 대부분 추론 쪽 방법, 즉 프롬프트·워크플로·도구·지식 관리로 진행된다는 점이 핵심입니다.

그림. 학습으로 바꾸는 방법과 추론 구성으로 끌어내는 방법의 구분

실무에서 가장 흔한 오해는 “우리 회사 문서를 학습시키면 AI가 우리 회사를 알게 된다”는 기대입니다. 원리를 보면 파인튜닝은 지식을 정확히 저장하는 방법이 아닙니다. 파라미터에 패턴이 흐릿하게 섞여 들어갈 뿐이라 어떤 문서의 어느 조항인지 정확히 되짚기 어렵고, 규정이 바뀔 때마다 다시 학습해야 합니다. 사내 지식을 답하게 하려면 RAG가 먼저이고, 파인튜닝은 말투와 형식을 맞추는 보조 수단으로 쓰는 것이 일반적인 순서입니다.

선택 순서를 정리하면 이렇습니다. 먼저 프롬프트로 해결되는지 확인하고, 사내 문서 근거가 필요하면 RAG를 붙이고, 그래도 형식이나 전문 용어 처리가 부족할 때 파인튜닝을 검토합니다. 이 순서는 비용이 싼 것부터 시도하는 순서이기도 합니다. 처음부터 파인튜닝 예산을 잡는 계획서가 있다면 RAG로 먼저 검증했는지를 결정해야 합니다.

지금까지의 AI 원리는 “글을 받아 글을 내는” 과정이었습니다. 여기에 한 가지를 더하면 AI가 실제로 일을 하게 됩니다. 바로 도구 호출(tool calling) 입니다. 모델이 답을 바로 쓰는 대신 “날씨 조회 도구를 서울로 호출하라” 같은 정해진 형식의 요청을 출력하면, 시스템이 실제 도구를 실행하고 그 결과를 다시 모델 입력에 넣어 줍니다. 모델은 도구 결과를 읽고 다음 행동이나 최종 답을 정합니다.

원리상 도구 호출도 다음 토큰 예측입니다. 다만 사후 학습 단계에서 “이런 상황에서는 이런 형식으로 도구를 부른다”는 패턴을 익혔기 때문에 가능해졌습니다. 이 과정을 여러 번 반복하면서 목표를 달성할 때까지 계획·실행·확인을 이어 가는 구조가 AI 에이전트입니다. 에이전트는 새 원리가 아니라 추론을 반복하고 도구와 연결한 시스템 설계입니다. 정의와 구조는 AI Agent란 무엇인가에서 자세히 볼 수 있습니다.

도구를 연결하는 방식을 표준화하려는 움직임도 있습니다. MCP(Model Context Protocol)는 AI 모델과 사내 시스템·데이터 소스를 연결하는 규격으로, 도구마다 연동 코드를 따로 짜는 부담을 줄여 줍니다. 자세한 내용은 MCP란 무엇인가에 정리돼 있습니다.

에이전트로 넘어가면 AI 원리에서 본 비용과 위험이 함께 커집니다. 한 작업에 모델 호출이 수십 번 일어나므로 토큰 사용량이 늘고, 앞 단계의 작은 오류가 뒤 단계로 전파됩니다. 무엇보다 AI가 글이 아니라 실제 시스템을 움직이므로 권한과 감사 기록이 필수가 됩니다. 메일 발송, 결재, 데이터 수정 같은 되돌리기 어려운 행동은 사람 승인을 거치게 하고, 모든 도구 호출을 기록으로 남겨야 합니다. 이 운영 원칙은 엔터프라이즈 AI 거버넌스 정리에서 더 넓게 다룹니다.

AI 원리는 업종마다 다른 모습으로 현장에 나타납니다. 같은 학습과 추론이라도 데이터 성격과 오류 비용이 다르기 때문입니다. 국내에서 흔히 볼 수 있는 적용 유형을 원리와 연결해 정리하면 다음과 같습니다.

공공 분야에서는 민원 분류와 상담 보조가 대표적입니다. 민원 글을 임베딩해 담당 부서를 추천하고, 관련 법령과 지침을 RAG로 찾아 답변 초안을 만드는 구조입니다. 개인정보와 행정 정보가 많아 추론 서버를 내부망에 두는 온프레미스 운영이 선호되고, 그래서 GPU 한두 장으로 돌릴 수 있는 sLLM과 양자화가 함께 검토됩니다. 오류 비용이 큰 대국민 안내는 담당자 확인을 거치는 방식이 일반적입니다.

금융 분야에서는 이상거래탐지처럼 오래된 머신러닝 모델과, 상담·내부 문서 검색 같은 대화형 AI가 함께 쓰입니다. 이상거래탐지는 정형 데이터를 학습한 판별 모델이 점수를 매기는 전통적인 원리이고, 상담 보조는 다음 토큰 예측 원리입니다. 금융권은 설명 가능성과 감사 요구가 강하므로 답변 근거 문서와 모델 버전, 온도 설정까지 기록으로 남기는 체계가 도입 조건이 되는 경우가 많습니다.

제조 분야에서는 비전 AI의 비중이 큽니다. 정상·불량 이미지를 학습한 검사 모델이 라인에서 실시간으로 추론하며, 이때는 응답 속도가 생명이라 라인 가까이에 둔 엣지 장비에서 작은 모델을 돌립니다. 최근에는 설비 매뉴얼과 정비 이력을 RAG로 연결해 현장 작업자가 대화로 조치 방법을 묻는 사례도 늘고 있습니다. 같은 공장 안에서도 검사는 판별 모델, 정비 지원은 생성형 모델이라는 식으로 원리가 다른 AI를 나눠 씁니다.

유통·서비스 분야도 같은 원리로 설명됩니다. 상품 추천은 고객과 상품을 임베딩 좌표로 바꿔 가까운 상품을 찾는 원리이고, 고객 상담 챗봇은 주문·배송 시스템을 도구로 호출해 실제 정보를 조회한 뒤 답합니다. 상담 챗봇이 배송 날짜를 기억에 의존해 답하면 환각이 생기지만, 도구로 조회한 값을 넣어 주면 정확해집니다. AI 원리를 알면 “챗봇이 틀렸다”는 불만이 모델 문제인지, 데이터 연결 문제인지를 구분할 수 있습니다.

세 업종의 공통점은 “어느 모델이 가장 똑똑한가”보다 “데이터를 어디에 두고, 추론을 어디서 돌리고, 오류를 어떻게 잡을 것인가”가 먼저 결정된다는 점입니다. 국내 모델 선택지는 국내 LLM 모델 총정리에서 성능과 비용을 함께 비교해 볼 수 있습니다.

AI 원리를 이해했다면 이제 그 지식을 도입 판단으로 옮길 차례입니다. 앞에서 본 네 단계(데이터·학습·모델·추론)와 토큰·컨텍스트·환각·비용의 원리를 운영 점검 항목으로 바꾸면 다음과 같습니다. 도입 회의에서 아래 질문에 답하지 못하면 아직 파일럿 단계로 넘어갈 준비가 되지 않은 것입니다.

이 표에서 특히 놓치기 쉬운 것이 토큰과 비용 행입니다. 파일럿 때는 사용자가 적어 비용이 보이지 않다가 전사 확산 단계에서 예산이 급격히 늘어나는 일이 흔합니다. 여러 모델을 쓰는 조직이라면 모델 호출을 한곳으로 모으는 LLM 게이트웨이를 두고 부서별 사용량과 한도를 처음부터 측정하는 편이 안전합니다. GPU 활용률을 관리하는 방법은 LPM(LLM Performance Management) 정리에서 참고할 수 있습니다.

데이터 행도 원리를 알면 범위가 넓어집니다. 지켜야 할 데이터는 사용자가 넣은 원본만이 아닙니다. 추론 과정에서 생기는 임베딩 벡터와 캐시 같은 중간 데이터, 사용자에게 돌아간 출력, 누가 언제 어떤 질문으로 모델을 불렀는지 남는 호출 로그까지 모두 조직의 업무 정보를 담고 있습니다. 공공기관 사업에서는 이 세 가지 데이터와 로그의 보관 위치·접근 권한·삭제 권한이 기관에 있는지를 계약 조항으로 명시하는 것이 점점 표준이 되고 있습니다. 외부 플랫폼을 쓸 때는 “로그 분석을 위해 공급자 클라우드로 전송한다” 같은 조항이 없는지 점검해야 합니다.

MSAP.ai는 이런 운영 요건을 하나의 플랫폼에서 다룹니다. 모델 서빙과 게이트웨이, RAG 파이프라인, 에이전트 실행 환경, 사용량 계측을 쿠버네티스 기반 위에 묶어 온프레미스와 클라우드 어디서든 같은 방식으로 운영할 수 있게 합니다. AI 원리를 아는 조직일수록 “모델 하나”가 아니라 “추론을 운영하는 체계”를 먼저 준비해야 한다는 결론에 도달합니다. 도입 단계별 판단은 LLM이란 무엇인가 — 원리부터 기업 도입 판단까지도 함께 읽어 보면 좋습니다.

• AI 원리는 학습과 추론 두 과정입니다. 학습은 데이터로 파라미터를 맞추는 일이고, 추론은 맞춰 둔 파라미터로 새 입력의 답을 계산하는 일입니다.
• 학습은 손실 함수로 틀린 정도를 재고, 경사 하강과 역전파로 덜 틀리는 방향으로 파라미터를 고치는 반복입니다.
• 대화형 AI는 글을 토큰으로 자르고, 토큰을 임베딩 좌표로 바꾼 뒤, 다음 토큰의 확률을 계산해 하나씩 붙여 답을 만듭니다.
• 한국어는 같은 뜻도 토큰이 더 많이 드는 경우가 있어, 모델 비교 때 우리 문서의 실제 토큰 수를 재 봐야 합니다.
• 온도는 답의 일관성과 다양성을 조절하고, 컨텍스트 창은 한 번에 읽을 수 있는 분량의 한계를 정합니다.
• 환각은 “그럴듯한 다음 토큰”을 고르는 원리에서 나오므로 RAG·출처 표시·도구 호출·사람 확인으로 줄이고 측정해야 합니다.
• 학습은 연산, 추론은 메모리가 병목입니다. 양자화·배치·KV 캐시 관리·모델 배정이 추론 비용을 줄입니다.
• 사내 지식은 RAG가 먼저, 파인튜닝은 형식과 말투를 맞추는 보조 수단입니다.
• 에이전트는 추론과 도구 호출을 반복하는 시스템 설계이며, 권한과 감사 기록이 도입 조건입니다.

AI 원리를 쉽게 설명하면 무엇인가요?

AI 원리는 데이터에서 패턴을 숫자로 배워 두는 학습과, 그 숫자로 새 입력의 답을 계산하는 추론 두 과정으로 설명할 수 있습니다. 학습은 모델이 예측하고 정답과 비교해 틀린 만큼 파라미터를 고치는 일을 수없이 반복하는 과정이고, 추론은 완성된 모델이 질문을 받아 가장 그럴듯한 출력을 계산하는 과정입니다. 대화형 AI는 추론할 때 다음에 올 토큰의 확률을 계산해 하나씩 붙이는 방식으로 답을 만듭니다.

AI의 학습과 추론은 어떻게 다른가요?

학습은 데이터로 모델의 파라미터를 맞추는 단계로, 모델을 만들거나 고칠 때 GPU를 대량으로 써서 한 번씩 수행합니다. 추론은 학습이 끝난 모델로 사용자의 질문에 답하는 단계로, 질문이 들어올 때마다 매번 일어납니다. 학습은 연산량과 GPU 간 통신이, 추론은 메모리 용량과 대역폭이 주된 병목이며, 대부분의 기업은 학습보다 추론을 설계하고 운영하는 일에 비용과 노력을 씁니다.

AI에서 토큰이란 무엇인가요?

토큰은 AI가 글을 읽고 쓰는 최소 단위인 글자 조각입니다. AI는 문장을 미리 정해 둔 사전에 따라 조각으로 자르고 각 조각에 번호를 붙여 처리하며, 영어 기준으로 토큰 하나는 대략 4글자 정도입니다. API 요금, 응답 속도, 한 번에 넣을 수 있는 문서 분량이 모두 토큰 수로 정해지고, 한국어는 같은 뜻도 영어보다 토큰이 더 많이 드는 경우가 있어 실제 업무 문서로 토큰 수를 측정해 보는 것이 좋습니다.

AI는 왜 같은 질문에도 다른 답을 하나요?

대화형 AI는 다음 토큰을 고를 때 가장 확률이 높은 것만 고르지 않고 확률에 비례해 무작위로 뽑는 샘플링을 쓰기 때문입니다. 무작위의 정도는 온도라는 설정값으로 조절하는데, 온도를 낮추면 답이 일정해지고 높이면 다양해집니다. 규정 안내처럼 일관성이 중요한 업무는 온도를 낮게, 아이디어 발상처럼 다양성이 필요한 업무는 높게 설정합니다.

AI가 틀린 내용을 사실처럼 말하는 이유는 무엇인가요?

AI는 사실인 문장이 아니라 그럴듯한 다음 토큰을 고르도록 학습됐기 때문에, 모르는 내용도 그럴듯하게 이어 쓰는 경향이 있습니다. 이 현상을 환각이라고 하며, 학습 이후의 정보나 사내 정보처럼 학습 데이터에 없는 질문, 숫자·고유명사처럼 정확한 값이 필요한 질문에서 자주 생깁니다. 근거 문서를 입력에 넣어 주는 RAG, 출처 표시, 계산과 조회의 도구 호출, 사람 확인 절차로 줄일 수 있지만 완전히 없앨 수는 없으므로 정기적으로 측정해야 합니다.

우리 회사 문서를 학습시키려면 파인튜닝을 해야 하나요?

대부분의 경우 파인튜닝보다 RAG가 먼저입니다. 파인튜닝은 모델 파라미터에 패턴을 흐릿하게 섞어 넣는 방식이라 특정 문서의 조항을 정확히 되짚기 어렵고, 규정이 바뀔 때마다 다시 학습해야 합니다. RAG는 질문과 관련된 문서를 검색해 입력에 넣어 주므로 문서만 갱신하면 답도 바로 바뀌고 출처를 표시할 수 있습니다. 파인튜닝은 전문 용어 처리나 고정된 출력 형식, 업무 문체를 맞추는 보조 수단으로 검토합니다.

AI 추론 비용을 줄이려면 무엇부터 해야 하나요?

먼저 업무별·부서별 토큰 사용량을 측정해 어디서 비용이 나가는지 파악해야 합니다. 그다음 간단한 요청은 작은 모델로, 어려운 요청만 큰 모델로 보내는 모델 배정을 적용하고, 양자화로 메모리 요구량을 줄이며, 배치 처리와 KV 캐시 재사용을 지원하는 추론 서버를 씁니다. 반복되는 지시문은 캐시로 재사용하고 불필요하게 긴 입력을 줄이는 것만으로도 비용이 크게 내려갑니다.

MSAP.ai · OPENMARU · Cloud Native Forum

• AI(인공지능)란 무엇인가 — 뜻·원리·종류부터 기업 도입까지
• LLM 작동 원리, 8분 동영상으로 보는 AI 개념 이해
• LLM이란 무엇인가 — 원리부터 기업 도입 판단까지
• vLLM이란? LLM 추론 속도를 높이는 오픈소스 엔진
• RAG란 무엇인가 — 파이프라인 해부와 도입 체크리스트
• AI 가속기란 무엇인가? GPU, NPU, TPU 대세는?
• 프라이빗 sLLM Qwen 3.6 27B — 데이터 주권과 TCO를 함께
• ChatGPT와 LLM 완전 이해하기 (OPENMARU)
• LLM의 한계를 넘는 AI Agent — 엔터프라이즈 IT 아키텍처의 핵심 (Cloud Native Forum)

외부 자료

• OpenAI Academy — AI란 무엇인가
• Oracle — AI 추론이란 무엇인가요?
• Attention Is All You Need — 트랜스포머 원 논문
• Scaling Laws for Neural Language Models (Kaplan et al., 2020)
• Training Compute-Optimal Large Language Models (Chinchilla, 2022)
• Training language models to follow instructions with human feedback (InstructGPT, 2022)
• Efficient Memory Management for LLM Serving with PagedAttention (vLLM, 2023)
• Stanford HAI — AI Index Report 2025