소프트 웨어 개발 방식 진화
사용자가 요구사항을 직접 정의하거나, 필요한 규칙을 함수로 정의하여 프로그래밍 (룰베이스) → 전통적 개발
인간의 업무 처리 결과로 생성된 정형 데이터를 기반으로 학습하여 다음 결과를 예측하는 모델(컴퓨터가 직접 찾은 함수) 생성(예측, 분류, 추천) → AI 개발
기존 CPU- Memory - Disk를 병렬로 연결하며 인간 뉴런을 모방한 딥러닝일 가능해졌다는 배경 아래 활발히 연구 재개
딥러닝 모델 중 Transformer model이 등장한 후로
텍스트 이해(Encoder)를 중점으로 하여 마스킹된 단어를 예측하고 문맥 이해도를 높인 BERT와,
텍스트 생성(Decoder)를 중점으로 하여 이전 토큰만 보고 예측하는 방식으로 자연스러운 생성이 가능해진 LLM(GPT) 이 등장하게 되었다.
(해당 글에 Transformer와 LLM 등장에 관련한 글을 참고하면 된다.)
BERT의 대표 활용 사례로는 문서 분류, 질문 응답, 감정 분석 등이 있고,
GPT의 활용 사례는 텍스트 생성(대화형) 등이 있다.
그럼 이제 LLM을 이해해보자
LLM은 Lage Language Model (거대 언어 모델)의 줄임말이다.
즉, ‘Large(거대)’ 는 기존의 언어 모델에 비해 매우 많은 양의 파라미터를 갖는다는 뜻에서 붙여졌다. 파라미터도 거대하지만, 텍스트 양도 거대하다. 다량의 파라미터에 대량의 텍스트를 학습하여, 뛰어난 언어 능력을 가진 모델이라는 뜻이다.
LLM을 이해하기 전에 Foundation model 먼저 이해하고 가는게 좋다.
Foundation model
Foundation model은 말 그대로 기반 모델이라는 의미이다.
기반 모델은 무슨 의미이지??
기반 모델을 하기 위해서 Foundation model 이 생기기 전의 모델 훈련 방식을 살펴보자.
[ Foundation model 생기기 전 ]
리뷰가 긍정적인지 부정적인지 분류하기 위해선 리뷰 데이터들을 긁어온 뒤 긍정인지 부정인지 라벨을 붙이는 작업을 실행했다. 이러한 작업을 Annotation or Tagging 이라고 한다.
태깅 작업을 끝낸 데이터들을 모델에 학습시켜 성능을 확인해보고, 좋지 못하다면 데이터를 더 긁어와 또 태깅 작업을 하거나 이리저리 모델을 튜닝시킨다.
하지만, 이번엔 리뷰의 감정 분석이 아닌 문장에서 사람 이름과 장소를 찾고 싶다면??
그럼 다시 데이터들에 사람이름과 장소 태깅 작업을 시작해야 한다.
이렇게 각 태스트에 맞게 데이터를 모으고, 훈련시켜야 한다.
하지만, 여기서 의문이 제기된다.
다 언어를 다루는건데 매번 태스크마다 데이터 모아서 태깅하는거 힘들어! 조금 더 효율적이고 쉬운 방법 없을까?
문과생과 이과생이 서로 전공 분야 이야기는 안통해도 일상 이야기는 할 수 있잖아. 각자 전공지식만 다르게 배운거지, 둘 다 공통으로 한국어를 쓰기도 하고, 둘 다 같은 공통 교육 과정을 지내왔으니깐!
[Foundation model]
여기서 한국어, 공통 교육과정이 Foundation model 이다.
자연어처리(Natural Language Processing, NLP)를 하기위해 학습시킨 Foundation model 이 NLP Foundation model 이다.
NLP Foundation model 에다가 긍정, 부정 데이터를 살짝 더해주면, 리뷰를 긍정, 부정으로 분류하는 시스템이 만들어지고,
사람 이름과 장소 데이터를 살짝 더해주면, 사람이름과 장소를 찾아내는 시스템이 만들어지는거다.
이렇게 Foundation Model 이 기존 방식 대비 의미있기 위해서는 아래 2가지 조건을 만족해야한다.
- 기존 방식보다 조금의 데이터를 써도 되거나
- 같은 양의 데이터를 쓰면 성능이 더 좋아지거나
두가지 조건을 만족하지 않으면 굳이 Foundation model을 쓸 이유가 없다.
그리고 현재 가장 좋은 NLP Foundation model로 인정 받는 것이 바로 LLM, Large Language Model 이다.
NLP에서의 Language Model 은 ‘주어진 텍스트 바로 뒤에 온 단어를 예측하는 모델’ 이다. 문장 그대로 외우는 것이 아닌, 패턴을 학습하는 모델이다.
그럼 이제 본격적으로 LLM에 대해 공부해보자.
Large Lanugage Model
Language Model은 텍스트 바로 뒤에 오는 단어를 예측하는 모델이다.
그럼 Large Language Model은? 큰~~Language Model이다.
하지만 이렇게 거대 언어 모델(LLM)을 만들기 위해서는 3가지 조건이 필요하다.
- 엄청나게 많은 훈련 데이터
- 뒤에 오는 단어를 잘 예측하는 강력한 알고리즘
- 엄청나게 많은 데이터를 강력한 알고리즘으로 학습해낼 성능 좋은 컴퓨팅 파워
Machine Learning → Deep Learning 으로 넘어갈 수 있었던 이유도 바로 이 3가지 이유가 충족됐기 때문이다.
LLM 관점에서는 어떻게 해결됐는지 살펴보겠다.
-
훈련데이터
모델을 학습시키기 위해서는 먼저 데이터 라벨링 과정이 필요하다. 앞서 말한 태깅 과정이다.
라벨링 과정을 자동화 시키기 위해 Auto Rabelling이라는 많은 연구가 진행되고 있다.
그만큼 라벨링 과정은 사람이 직접 개입해야 하므로 시간과 돈이 많이 드는 일이다.
하지만!! LM 훈련을 위한 데이터에는 사람이 개입할 필요가 없다.
LM의 훈련 방식이 Self-supervised Learning이기 때문이다.
Self-supervised Learning은 데이터 스스로 정답을 만들면서 학습하는 방식이다.
아래 예시를 보면,
- "나는" → "어제"
- "나는 어제" → "학교에"
- "나는 어제 학교에" → "갔습니다."
위와 같은 방식으로 문장의 일부를 기반으로 다음 단어를 예측하는 훈련 데이터를 자동으로 생성할 수 있다.
Unsupervised Learning은 정답이 전혀 없는 상태에서 패턴을 찾는 것이라면, Self-supervised Learning은 데이터 자체에서 정답을 만들어내어 패턴을 찾는다고 이해하면 된다.
훈련 데이터의 라벨링 과정이 어느정도 해결되었다고 해도, 근본적인 훈련 데이터의 양이 많은지가 중요하다.
하지만, Web Scale Data가 등장하면서 데이터 규모가 급격히 커졌고, 많은 데이터를 보유한 웹사이트들도 공개 범위내의 우수한 품질의 데이터를 공개하고 있다.
⇒ 이렇게 LM을 훈련시키기 위해 Self-Supervised Learning 특성과 Web Scale Data가 만나면서 엄청난 양의 데이터를 확보하게 되었다.
-
단어 예측하는 강력한 알고리즘 : Transformer
이제는 위에서 확보한 많은 데이터를 학습시킬 좋은 알고리즘이 필요하다.
이때, Transformer가 등장하게 된다.
LM은 텍스트 뒤에 오는 단어를 예측하여야 하는데, 이를 기가 막히게 잘하는 모델이 바로 Transformer인 것이다.
Transformer에 관하여는 Transformer의 등장과 LLM의 발전 이라는 포스팅에서 설명하고 있으니 읽고 오면 된다!
Transformer 는 Encoder와 Decoder로 이루어져 있고, Decoder only로 모델을 만든게 요즘의 대세 LLM 모델 GPT, LLaMA, Claude등이 있다.
왜 Decoder만 사용하여 모델을 만들었을까??
LM은 Decoder의 역할인 “텍스트 바로 뒤 단어 예측”만 필요하다.
Encoder는 전체적인 문장을 압축하여 Context로 문장을 변환하는 역할인데 이러한 문장을 얼마나 잘 수학 행렬로 압축 했는지에 관한 Encoder의 결과가 필요없고, 원본 문장 뒤에 생성될 내용에만 관심이 있다면?!
Transformer의 Decoder만 사용하면 전통적인 Language Model을 만들 수 있게 되고, auto-regressive 방식으로 계속해서 긴 글을 만들 수도 있는것이다.
-
GPU (Cloud)
딥러닝 시대를 연 것은 CPU를 병렬로 연결한 GPU로, 딥러닝을 학습시킬 수 있는 빠른 연산이 가능해졌다. Nvidia가 바로 이 GPU 최강자다.
또한 AWS, MS가 Cloud로 직접 GPU장비를 사지 않아도 딥러닝을 학습 시킬 수 있도록 인프라 발전시켰고, 계속 발전시키고 있는 중이다.
이렇게
- Self-Supervised Learning과 Web Scale Data 등으로 거대한 양의 훈련 데이터가 제공되고,
- Transformer 알고리즘 등장으로 강력한 모델을 만들 수 있게 되었으며,
- 이 모든 연산을 뒷받침할 GPU와 Cloud 인프라가 발전하면서
LM이 LLM, Large Language Model로 빠르게 발전할 수 있게 되었다.
LLM의 사용
Transformer의 인코더를 사용하여 문맥 이해를 중점으로 향상 시킨 모델이 BERT이고,
Transformer의 디코더를 사용하여 문자열 생성 중점으로 향상 시킨 모델이 GPT라고 소개했다.
Transformer, BERT, GPT 모델의 주요 차이점을 비교
| 구분 | Transformer | BERT | GPT |
|---|---|---|---|
| 출시 연도 (논문) | 2017 (Attention is All You Need) | 2018 (BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding) | 2018 (GPT-1: Improving Language Understanding by Generative Pre-training) |
| 주요 목표 | 방향성을 고려한 변환 및 시퀀스 생성 | 문맥을 양방향으로 이해 | 단일 방향 텍스트 생성 |
| 입력 처리 방식 | Sequence-to-Sequence 방식 | 전체 문장의 문맥을 고려하여 해석 | 이전 단어를 기반으로 다음 단어를 예측 |
| 모델 구조 | Encoder-Decoder 구조 | Encoder 기반 | Decoder 기반 |
| Self-Attention | 양방향(Self-Attention) | 양방향(Self-Attention) | 단방향(Causal Self-Attention) |
| 사전 훈련 목표 | - | 마스킹된 단어 예측, 문장 간 관계 학습 | 언어 모델링(Language Modeling) |
| 특징 | 병렬 연산이 가능하여 연산 속도가 빠름 | 문맥을 고려한 단어 예측으로 문장 이해도가 높음 | 이전 단어를 보고 예측하는 방식으로 자연스러운 문장 생성 가능 |
| 파라미터 확장 방식 | 복잡한 구조에 따라 확장 가능 | 파라미터 증가 시 더 정교한 문맥 이해 가능 | 파라미터가 커질수록 자연스러운 텍스트 생성 가능 |
| 대표적인 활용 사례 | 번역, 요약 | 문서 분류, 질문 응답, 감정 분석 | 텍스트 생성, 대화형 AI |
GPT와 같이 생성형 모델을 LLM으로 분류하고 있고, GPT말고도 LLaMA, Gemini 등 다양한 모델들이 있다.
Meta에서 개발한 LLaMA와 같은 오픈 소스들은 직접 커스터마이징이나 파인튜닝, 재배포가 가능하고,
OpenAI에서 개발한 GPT와 같이 Closed Weight로 사용자는 API형태로만 접근할 수 있는 모델들이 있다.
LLM의 확장과 Agentic Work
우리는 LLM이 어떻게 발전해왔는지를 살펴봤다.
기존 프로그래밍 방식에서 AI를 활용한 모델 개발로 넘어왔고, 거대 언어 모델(LLM)이 등장하며 자연어 이해와 생성이 가능해졌다.
그렇다면, 이제 LLM을 더 능동적으로 활용하는 방법에 대해 고민해보자.
단순히 "입력 → 출력"만을 수행하는 모델이 아니라, LLM이 스스로 목표를 설정하고, 계획하고, 실행하는 방식으로 발전하는 흐름을 이해해야 한다.
이를 가능하게 하는 개념이 바로 능동적인 작업, Agentic Work다.
[Agentic Work란?]
기존 LLM이 사용자의 질문에만 반응했다면, Agentic Work는 LLM이 스스로 목표를 설정하고 작업을 수행하는 방식을 의미한다.
즉, AI가 단순한 응답형 시스템이 아니라, 자율적으로 행동하는 에이전트(Agent)로 발전하는 과정이다.
[Agentic Work의 핵심 요소]
- 목표 지향적 (Goal-Oriented) → 단순 질의응답이 아닌, AI가 목표를 설정하고 해결책을 찾아감.
- 자율성 (Autonomy) → 사용자의 개입 없이 AI가 독립적으로 판단하고 실행.
- 계획 및 실행 (Planning & Execution) → AI가 문제를 해결하기 위한 계획을 세우고, 단계적으로 수행.
- 다중 에이전트 협업 (Multi-Agent Collaboration) → 여러 AI가 역할을 나누어 함께 작업.
이러한 Agentic Work 개념이 등장하면서, LLM을 실질적인 업무에 적용하기 위한 다양한 프레임워크들이 등장했다.
그중 대표적인 것이 LangGraph와 CrewAI다.
[LangGraph: 그래프 기반 멀티 에이전트 프레임워크]
LangGraph는 LLM을 활용한 복잡한 워크플로우 자동화를 가능하게 하는 프레임워크다.
이름에서 알 수 있듯이, Graph(그래프) 구조를 활용하여 여러 개의 에이전트가 협업할 수 있도록 설계되었다.
[LangGraph의 특징]
- 그래프(Graph) 기반 구조
- 각 에이전트가 노드(Node) 가 되고, 작업 흐름이 엣지(Edge) 로 연결된다.
- 순차적 실행(Sequential)뿐만 아니라, 병렬 처리(Parallel)도 가능하다.
- 상태 관리(State Management)
- AI가 작업을 진행하면서 이전 결과를 기억하고 활용할 수 있음.
- 멀티 에이전트 협업
- 여러 개의 LLM이 각각 역할을 맡아 연속적인 작업을 수행.
- 여러 개의 LLM이 각각 역할을 맡아 연속적인 작업을 수행.
[LangGraph 사용 예제]
📌 뉴스 분석 및 요약 시스템
- 1단계: 뉴스 기사 크롤링 → 2단계: 핵심 내용 요약 → 3단계: 분석 보고서 생성
📌 자동 이메일 작성
- 1단계: 요청 분석 → 2단계: 이메일 초안 작성 → 3단계: 오타 및 문법 검사 → 4단계: 최종 이메일 전송
LangGraph는 복잡한 흐름을 자동화하는 데 특화된 프레임워크로, 여러 LLM이 함께 작업할 때 강력한 성능을 발휘한다.
[CrewAI: 역할 기반 협업형 에이전트 시스템]
CrewAI는 LangGraph와 유사하지만, 각 AI에게 특정 역할(Role) 을 부여하여 협업하도록 설계된 프레임워크다.
쉽게 말해, AI가 "팀을 구성하여 협력하는 방식"으로 동작한다.
[CrewAI의 특징]
- 역할(Role) 기반 구조
- 각 AI가 특정 직무(예: 연구원, 작가, 분석가) 를 맡아 협업한다.
- 자율적인 협업 시스템
- 단순히 입력을 받아 출력하는 것이 아니라, 각 에이전트가 서로 상호작용하며 작업을 진행.
- LLM과의 통합 가능
- GPT, LLaMA, Claude 같은 LLM과 연동하여 쉽게 구축 가능.
[CrewAI 사용 예제]
📌 논문 요약 및 분석 AI 팀
- 연구원(Researcher) → 논문 검색 및 핵심 내용 요약
- 작가(Writer) → 요약된 내용을 논리적으로 정리
- 검토자(Reviewer) → 문법 검사 및 보완
- 출력(Submitter) → 최종 보고서 생성
📌 자동 보고서 작성 시스템
- 1단계: 데이터 수집 (데이터 분석가)
- 2단계: 인사이트 추출 (비즈니스 애널리스트)
- 3단계: 보고서 작성 (문서 작성 AI)
- 4단계: 최종 검토 및 발송 (QA AI)
CrewAI는 AI를 단순한 도구가 아니라, "역할을 수행하는 팀원" 으로 활용하는 방식이다.
각 AI가 협업하며 더 정교한 결과물을 만들어낼 수 있도록 설계된 점이 LangGraph와의 차이점이다.
LangGraph vs CrewAI 비교
| 비교 항목 | LangGraph | CrewAI |
|---|---|---|
| 구조 | 그래프(Graph) 기반 | 역할(Role) 기반 |
| 워크플로우 관리 | 노드(Node)와 엣지(Edge)로 작업 흐름을 설계 | 각 AI에게 역할을 부여하여 협업 |
| 적용 방식 | 복잡한 프로세스 자동화 | AI 팀을 구성하여 협력 |
| 사용 예제 | 뉴스 크롤링 → 분석 → 보고서 생성 | 연구원 → 작가 → 검토자 협업 |
LangGraph는 작업의 흐름을 설계하는 데 최적화,
CrewAI는 각각의 AI가 역할을 수행하며 협업하는 데 초점을 맞춘 방식이다.
LLM은 더 이상 단순히 질문에 답하는 AI가 아니다.
이제는 스스로 목표를 설정하고, 계획을 세우고, 실행하는 Agentic Work 개념이 적용되면서, LLM은 자율적으로 업무를 수행하는 AI로 발전하고 있다.
이를 위해 LangGraph, CrewAI 같은 프레임워크가 등장했고,
앞으로 LLM은 더 능동적으로 인간의 업무를 돕는 AI 시스템으로 자리 잡을 것이다.
추가 자료
LangChain과 VectorDB
기존 LLM에는 몇 가지 한계점이 존재하며, 이를 보완하기 위해 LangChain과 VectorDB 같은 기술이 등장했다.
[LLM의 한계점]
- 정보 접근 제한
- 기존 GPT 모델들은 사전에 학습된 데이터 내에서만 답변 가능하다.
- 예를 들어, GPT-3.5는 2021년까지의 데이터만 학습했기 때문에 그 이후 정보는 알지 못하며, 가끔 거짓된 답변을 생성한다.
- 입력 토큰 제한
- 한 번에 처리할 수 있는 입력 토큰(문장의 길이) 에 제한이 있다.
- 최신 모델일수록 점점 증가하지만, 긴 문서를 한 번에 처리하는 데는 한계가 있다.
- 환각 현상(Hallucination)
- LLM은 확률적으로 적절한 단어를 예측하는 방식이기 때문에,때때로 팩트가 아닌 내용을 그럴듯하게 만들어내는 환각 현상이 발생할 수 있다.
⇒ 이런 한계를 보완하는 기술이 바로 LangChain과 VectorDB다!
[LangChain이란? ]
LLM을 더 똑똑하게 활용하는 방법이다.
- GPT 같은 LLM을 활용한 애플리케이션을 개발할 수 있도록 도와주는 프레임워크.
- 단순한 챗봇이 아니라, 다양한 데이터 소스와 연결하여 지능형 AI 시스템을 만들 수 있도록 지원.
[LangChain 역할]
-
데이터 연결 (데이터 인식)
- LLM이 내가 가진 문서, 인터넷 검색 결과, CSV 파일 등에서 원하는 정보를 가져와 답변할 수 있도록 한다.
- 예: 특정 보고서나 문서에서 원하는 정보를 자동으로 찾아 제공.
-
에이전트(Agent) 기능
- LLM이 특정 툴을 사용하여, 적절한 방법을 자동으로 선택하고 실행할 수 있게 한다.
- 예: 인터넷 검색이 필요한 질문이라면, LangChain이 알아서 검색 후 답변 생성.
-
GPT의 한계를 보완하는 기능
GPT 한계 LangChain 보완 방법 정보 접근 제한 VectorStore 기반 정보 탐색 또는 Agent 활용한 검색 결합 입력 토큰 제한 Text Splitter로 긴 문서를 분할하고 요약 환각 현상 (거짓 정보) 특정 문서 기반으로만 답변하도록 Prompt 조정
즉, LangChain을 활용하면 GPT가 더 똑똑하게 동작하도록 만들 수 있다!
[LangChain의 핵심 구조]
- LLM (초거대 언어 모델)
- GPT, LLaMA, Claude 같은 모델이 LangChain의 엔진 역할을 함.
- LangChain을 통해 이 엔진을 활용하여 더 강력한 기능 구현 가능.
- Prompt (프롬프트 템플릿)
- LLM에게 원하는 답변을 기대하는 형식으로 지시하는 역할.
- 예: "날씨 알려줘" → "서울 날씨: 맑음"처럼 원하는 출력 형식 지정 가능.
- Index (색인화 모듈)
- LLM이 문서를 쉽게 탐색할 수 있도록 데이터를 구조화하는 기능.
- 예: 문서 로딩(Document Loaders), 텍스트 분할(Text Splitter), 벡터 저장(Vectorstores).
- Memory (대화 기억 기능)
- 챗봇이 이전 대화를 기억하고, 대화의 흐름을 유지할 수 있도록 함.
- 예: "아까 말한 제품 추천해줘" → 이전 대화를 기억하고 적절한 답변 제공.
- Chain (체인 모듈)
- 여러 개의 LLM 호출을 연결하여 연속적인 작업을 수행할 수 있도록 함.
- 예: 질문 분석 → 검색 → 요약 → 최종 답변 제공.
- Agent (에이전트 모듈)
- GPT가 기존 프롬프트 템플릿으로 해결할 수 없는 복잡한 작업을 수행하도록 도와줌.
- 예: 웹 검색, SQL 데이터 조회, API 호출 등 자동 실행.
[VectorDB]
GPT는 자체 학습된 데이터만 사용하기 때문에, 실시간 정보 검색이 어렵다.
이 문제를 해결하기 위해 VectorDB(벡터 데이터베이스) 가 사용된다.
[VectorDB가 필요한 이유]
- GPT는 문장을 벡터(숫자)로 변환하여 이해한다.
- 우리가 원하는 정보를 효과적으로 검색하려면 벡터 형태로 저장된 데이터베이스가 필요하다.
- VectorDB는 실시간 검색이 가능하고, 기업 내부 데이터나 문서를 저장해 맞춤형 답변이 가능하도록 한다.
[VectorDB 활용 방식]
- RAG (검색 증강 생성, Retrieval-Augmented Generation)
- LLM이 학습된 데이터가 아니라, VectorDB에서 검색한 정보를 바탕으로 답변 생성.
- 예: 최신 논문을 VectorDB에 저장하고, LLM이 이를 검색 후 답변.
- 효율적인 문서 검색 (Chunking 기법)
- 데이터를 작은 단위(Chunk)로 나누어 저장하여 검색 효율을 높임.
- Chunk 크기를 적절히 조절하여, LLM이 정보를 잘 찾을 수 있도록 구성.
- GPT + VectorDB + LangChain 조합
- VectorDB에서 저장된 데이터를 LangChain을 통해 LLM에 제공.
- 예: 기업 내부 문서를 학습한 챗봇이 고객 질문에 적절한 답변 제공.
[LangChain + VectorDB + GPT의 조합]
- GPT 단독 사용 시 → 사전에 학습된 데이터만 활용 (최신 정보 X)
- LangChain 적용 시 → 외부 데이터 접근 가능 (인터넷 검색, 데이터 연결)
- VectorDB 적용 시 → 최신 정보 및 기업 데이터 검색 가능
결론 : LangChain과 VectorDB를 활용하면 GPT를 단순한 대화형 모델이 아니라, 실질적인 AI 시스템으로 만들 수 있다.
마무리
지금까지 LLM의 등장 배경과 발전 과정, 그리고 LLM을 활용한 기술 트렌드인 Agentic Work에 대해 살펴보았다.
처음에는 단순한 규칙 기반 프로그래밍에서 출발한 AI가, 점차 딥러닝과 Transformer 모델의 발전을 통해 LLM으로 성장했다.
그리고 이제는 단순한 질의응답 시스템을 넘어서 스스로 목표를 설정하고, 협력하며, 문제를 해결하는 AI 에이전트로 진화하는 단계에 도달했다.
LangGraph와 CrewAI 같은 프레임워크들은 이러한 흐름을 더욱 가속화하며,
LLM이 더 능동적으로 실생활과 비즈니스에 적용될 수 있는 환경을 조성하고 있다.
🔮 LLM의 미래는?
앞으로 LLM이 단순한 텍스트 생성 도구가 아니라,
- 자율적인 AI 에이전트로서 업무를 자동화하고,
- 사람과 협력하며 최적의 의사결정을 지원하는 시스템으로 발전할 것이다.
참조
https://jins-sw.tistory.com/entry/Large-Language-Model-1-Foundation-Model
https://jins-sw.tistory.com/entry/Large-Language-Model-2-LLM을-가능케한-삼박자
