AI 깊이 이해하기 — 자율 시스템 설계까지 · 01
프롬프트를 고쳐 답변이 좋아졌다고 해서 모델의 가중치가 바뀐 것은 아니다. 일반적인 LLM 추론에서는 같은 가중치에 다른 입력을 넣어 결과를 바꾼다. 여기서 다루는 신경망 학습은 Loss를 기준으로 학습 가능한 Parameter를 갱신하는 과정이다. 이 차이를 구분해야 잘못된 답변을 고칠 때 프롬프트, 검색, 모델 학습, 실행 코드 중 어디를 손댈지 판단할 수 있다.
이 연재는 인공지능의 학습 원리에서 출발해, 정해진 업무를 스스로 수행하고 결과를 검증하는 자율 시스템을 설계하는 데까지 나아간다. 여기서 ‘완전 자율’은 모든 상황에서 인간 없이 작동한다는 선언이 아니다. 어떤 업무와 환경에서, 어느 권한까지, 어떤 검증을 거쳐 사람의 개입 없이 완료할 수 있는가를 명세하고 시험하는 목표다. 범용 지능이나 의식의 구현을 약속하지 않는다.
답변이 바뀌었다는 사실만으로는 무엇이 변했는지 알 수 없다
가상의 문서 검토 Assistant를 생각해보자. 처음에는 메모를 길게 정리한다. 사용자가 “결론 세 문장, 근거 두 항목으로 써줘”라고 하자 다음 답변부터 짧아졌다. 이 장면만 보고 ‘나를 학습했다’고 말하면 네 가지 다른 변화를 한데 묶게 된다.
| 바뀐 곳 | 실제 변화 | 확인할 증거 |
|---|---|---|
| Context | 이번 입력에 지시나 예시가 추가됨 | 모델에 전달한 입력 |
| Memory | 다음 호출에도 쓸 정보를 별도 저장 | 저장된 항목과 다음 검색 결과 |
| 가중치 | 학습 가능한 Parameter가 갱신됨 | 학습 실행 기록과 모델 버전 |
| 실행 시스템 | 형식 검사·저장·재시도 방식이 바뀜 | 코드 변경과 실제 실행 결과 |
이 표는 특정 제품의 구현 설명이 아니라 문제를 찾기 위한 구분이다. 같은 답변 개선도 원인이 다를 수 있다. Memory를 저장했어도 다음 호출에서 가져오지 않았다면 그 정보는 답변에 영향을 주지 않는다. 새 대화에서도 같은 형식을 따른다는 사실만으로 가중치 학습을 입증할 수도 없다. 시스템이 저장된 선호를 다시 넣었을 수 있기 때문이다.
LLM이 계산하는 확률은 무엇인가
이 글에서는 다음 Token을 예측하는 자기회귀 언어 모델을 다룬다. 모든 AI 모델이 같은 방식으로 학습하는 것은 아니다. Token은 모델이 처리하는 텍스트 단위이며, 실제 분할 방식은 Tokenizer에 따라 달라진다.
모델은 앞에 놓인 Token들을 바탕으로 다음 Token의 확률분포를 계산한다. 가중치 전체를 θ, 앞선 입력을 x라고 쓰면 핵심은 Pθ(다음 Token | 앞선 Token들)이다. θ는 학습으로 조정되는 수치들이고, x는 지금 읽는 내용이다. 같은 θ라도 x가 바뀌면 다음 Token의 분포가 달라진다.
예를 들어 “이 문장을 번역해줘”라는 입력과 “다음 예시처럼 짧게 번역해줘”라는 입력은 조건이 다르다. 입력 조건이 바뀌면 출력 분포도 달라질 수 있다. 다만 Sampling을 쓰면 같은 입력에서도 출력이 달라질 수 있으므로, 답변 하나의 차이만으로 변화의 원인을 확정할 수는 없다. 가중치가 갱신됐다는 증거는 별도로 필요하다. 언어 모델의 조건부 확률과 Token 단위 Loss는 Dive into Deep Learning의 Language Models 장에서 수식으로 확인할 수 있다.
학습에서는 Loss가 가중치를 바꿀 방향을 만든다
다음 Token 예측 학습에서는 학습 데이터에 실제로 이어진 Token을 목표로 삼는다. 그 Token에 모델이 낮은 확률을 주면 큰 손실을 부과한다. 한 위치의 단순화한 식은 Loss = −ln(목표 Token의 예측 확률)이다. 여기서 ln은 자연로그다. 확률이 0.8이면 Loss는 약 0.223, 0.2이면 약 1.609다. 일반적으로 여러 학습 위치의 Loss를 모아 최적화한다.
그다음 필요한 것은 ‘틀렸다’는 평가를 가중치별 변화 방향으로 바꾸는 계산이다. Backpropagation은 연쇄법칙을 사용해 각 Parameter에 대한 Loss의 Gradient를 계산한다. Gradient는 해당 수치를 조금 움직였을 때 Loss가 어떻게 변하는지를 나타낸다. Optimizer는 이를 이용해 Parameter를 갱신한다. 가장 단순한 Gradient Descent에서는 새 가중치 = 현재 가중치 − Learning Rate × Gradient로 표현할 수 있다.
PyTorch의 Autograd 문서는 Gradient 계산을, Optimization 튜토리얼은 계산된 Gradient로 Parameter를 갱신하는 단계를 구분해 설명한다. 두 단계는 같지 않다. Gradient를 계산하기만 하고 갱신하지 않으면 가중치는 그대로다.
수치 하나를 실제로 바꿔보면
복잡한 신경망 대신 출력이 ‘예/아니오’ 둘뿐인 교육용 모형을 놓자. 실제 LLM의 성능 실험이 아니라, 학습 한 번을 계산으로 확인하기 위한 예제다. 하나의 학습 가능한 수치 z가 ‘예’의 확률을 p = 1 / (1 + exp(−z))로 정한다고 가정한다. 이번 목표는 ‘예’, 즉 y = 1이다.
| 계산 단계 | 값 |
|---|---|
| 초기 Parameter | z = 0 |
| ‘예’의 예측 확률 | p = 0.500000 |
| 초기 Loss | −ln(p) = 0.693147 |
| z에 대한 Gradient | p − y = −0.500000 |
| Learning Rate 0.2로 갱신 | z = 0 − 0.2 × (−0.5) = 0.1 |
| 갱신 후 예측 확률 | p = 0.524979 |
| 갱신 후 Loss | 0.644397 |
가중치 역할을 하는 z가 바뀌었고 같은 조건에서 목표에 부여하는 확률이 올라갔다. 이것이 이 예제에서 확인한 학습이다. 이 한 번의 결과로 다른 입력에서도 좋아졌다고 말할 수는 없다. 그 판단에는 학습에 사용하지 않은 사례가 필요하다. 실제 LLM에서는 많은 Parameter가 함께 작용하고, Optimizer와 데이터 구성도 훨씬 복잡하다.
이 예제를 직접 확인하려면 아래 Python 코드를 실행하면 된다. 별도 패키지나 유료 API는 사용하지 않는다.
import math
z, target, learning_rate = 0.0, 1.0, 0.2
p_before = 1 / (1 + math.exp(-z))
gradient = p_before - target
z_after = z - learning_rate * gradient
p_after = 1 / (1 + math.exp(-z_after))
print(f"z: {z:.6f} -> {z_after:.6f}")
print(f"p: {p_before:.6f} -> {p_after:.6f}")
print(f"loss: {-math.log(p_before):.6f} -> {-math.log(p_after):.6f}")추론 중에는 무엇이 달라지는가
일반적인 생성 추론에서는 θ를 고정한 채 입력과 중간 계산값이 달라진다. 생성한 Token을 다음 입력의 일부로 삼아 이어서 생성할 수 있다. 여기서 Inference는 이미 학습한 모델을 적용하는 계산을 뜻한다. 논리적으로 문제를 푸는 Reasoning과 같은 단어로 번역되기도 하지만, 두 개념을 그대로 겹쳐 읽으면 안 된다.
Few-shot Prompting은 이 차이를 보여주는 사례다. 입력 안에 작업 예시를 주고 그 형식을 따르게 한다. Language Models are Few-Shot Learners는 GPT-3를 평가할 때 Gradient 갱신이나 Fine-tuning 없이 텍스트 지시와 예시로 작업을 지정했다고 명시한다. ‘In-context Learning’의 Learning을 곧바로 가중치 학습으로 이해해서는 안 되는 이유다.
그렇다고 추론 시점에 가중치를 바꾸는 기법이 절대로 없다는 뜻은 아니다. 별도 적응·학습 절차를 넣는 설계도 있다. 여기서 구분하는 대상은 가중치를 고정한 일반적인 생성 추론이다. 대화 데이터가 나중에 학습에 사용되는지에 관한 서비스 정책 또한 별개의 문제다.
문서 검토 Assistant가 실패했을 때, 어디를 고칠 것인가
앞의 가상 Assistant에 입력 문서와 “결론 세 문장, 근거 두 항목”이라는 지시를 전달했다고 하자. 모델은 초안을 생성했다. 실행 시스템은 형식을 검사하고 결과를 파일에 저장한다. 아래는 실제 운영 로그가 아니라, 같은 작업에서 생길 수 있는 실패를 구분한 설계 예시다.
첫째, 형식은 맞지만 중요한 단서가 빠졌다. 입력 문서가 잘려 전달됐는지부터 확인한다. 문서에 없는 정보를 더 긴 프롬프트로 요구한다고 복구되지는 않는다. 필요한 구간을 입력에 넣거나 원문을 검색하는 경로가 먼저다. Context가 늘면 읽어야 할 Token과 지연도 늘 수 있으므로, 전체 문서를 무조건 추가하는 방식은 별도로 평가해야 한다.
둘째, 한 예시에서는 잘되지만 다른 문서에서는 무너진다. 프롬프트를 고친 뒤 같은 예시만 재검사하면 그 사례에 맞춘 개선인지 구분하기 어렵다. 길이, 문체, 예외 조건이 다른 미사용 문서에도 동일한 평가 기준을 적용해야 한다. Fine-tuning을 검토하더라도 좋은 학습 사례와 분리된 평가 자료가 먼저 필요하다.
셋째, 답변은 정확한데 파일이 두 번 저장됐다. 이 문제는 Parameter가 언어를 잘 예측하는지와 다른 층에 있다. 저장 요청 뒤 응답이 끊겨 같은 작업을 재시도했다면 이미 저장됐는지 확인할 방법과 중복 처리 설계가 필요하다. 모델을 다시 학습시키기 전에 실행 코드와 저장 기록을 확인해야 한다.
넷째, 모델이 “저장했습니다”라고 썼지만 파일이 없다. 자연어 응답을 완료 증거로 삼은 설계가 원인일 수 있다. 저장 기능의 실제 반환값과 저장된 파일을 조회해야 한다. 모델의 설명과 외부 시스템의 상태는 서로 다른 관찰 대상이다.
| 관찰한 문제 | 먼저 확인할 대상 |
|---|---|
| 지시가 모호하거나 예시가 부적절함 | Prompt와 평가 사례 |
| 필요한 정보가 입력에 없음 | 원문 전달·검색 결과 |
| 충분한 입력에서도 작업 능력이 부족함 | 모델 선택·학습 데이터·Fine-tuning 가능성 |
| 출력 이후 저장·권한·재시도가 잘못됨 | 실행 코드와 외부 상태 |
이 표는 원인을 확정하는 진단기가 아니다. 관찰할 위치를 좁히는 순서다. 여러 원인이 함께 존재할 수 있으므로 모델 입력, 출력, 도구 결과를 구분해 남겨야 한다.
자율 시스템의 자기개선은 무엇을 바꿨는지부터 밝혀야 한다
실패한 문서의 패턴을 기록해 다음 Prompt에 넣는 것, 검색 대상을 바꾸는 것, 실행 코드를 수정하는 것, 모델 가중치를 갱신하는 것은 모두 시스템 개선에 쓰일 수 있다. 하지만 평가 대상과 되돌릴 방법은 다르다. ‘스스로 배웠다’는 표현만으로는 무엇이 좋아졌고 무엇이 위험해졌는지 알 수 없다.
이 연재에서 설계할 시스템은 공개 문서의 변경 사항을 읽고, 이전 버전과 비교해 근거가 있는 변경 보고서를 만드는 교육용 Agent다. 먼저 읽기와 로컬 결과 생성으로 범위를 한정하고, 잘못된 입력·중단·재실행을 넣어본다. 정해진 비교 규칙만으로 충분한 부분은 일반 코드로 작성한다. 다음 행동을 관찰 결과에 따라 선택해야 하는 부분에서만 Agent의 필요성을 따진다. 이 구분은 Anthropic의 Building effective agents가 제시하는 Workflow와 Agent의 경계와도 연결된다.
Fine-tuning도 처음부터 전제하지 않는다. 최신 문서가 빠진 문제에는 조회 경로가, 파일 중복에는 실행 제어가 먼저다. 필요한 데이터와 검증 비용을 감당할 수 없거나 간단한 코드가 더 정확한 문제라면, 학습 절차를 추가할 이유가 약하다.
앞으로의 학습 경로
| 구간 | 다룰 질문과 만들 결과 |
|---|---|
| 01–05 · 학습의 내부 | 학습·추론, Token·Embedding, 신경망·Gradient, Attention·Transformer, Pretraining·Post-training. 작은 수치 예제로 계산 확인 |
| 06–10 · 답변의 신뢰성 | 생성·Sampling, Reasoning, Hallucination, RAG·Fine-tuning 선택, 미사용 데이터 평가. 실패 원인 분류표 작성 |
| 11–15 · 자율성의 범위 | 업무·완료 조건, 관찰 가능성, State 전이, 계획 수정, Memory 오류. 문서 변경 보고 Agent의 실행 명세 작성 |
| 16–20 · 실행 구조 | Tool 계약, 중복 실행 방지, 중단·복구, 단일·다중 Agent 비교, MCP의 경계. 로컬 모의 도구로 구조 검증 |
| 21–25 · 신뢰와 통제 | 권한, Prompt Injection, 독립 검증, 예산·중단 조건, 평가와 Trace. 실패를 의도적으로 넣어 방어 확인 |
| 26–30 · 통합 실험 | 기준 Workflow, Agent 연결, 장애 실험, 운영 지표, 자율 범위 판정. 실행한 결과와 미검증 범위를 분리한 보고서 작성 |
학습 순서는 위와 같지만, 이미 발행한 Agent 입문 글은 연결해 읽고 동일한 설명을 다시 발행하지 않는다. 이후의 실습은 설계 예시와 실제 실행 결과를 구분한다. 유료 API나 별도 클라우드 구매를 필수 조건으로 삼지 않으며, 모의 실행으로 확인한 구조를 실제 LLM 성능으로 보고하지 않는다.
오늘의 확인 질문은 하나다. 답변이 좋아졌다면 입력, 저장된 정보, 가중치, 실행 코드 중 무엇이 바뀌었는가? 이를 구분해 기록할 수 있어야 다음 개선의 비용과 효과를 비교할 수 있다. 다음 글에서는 Token과 Embedding을 살펴본다. 문장이 숫자로 바뀌는 과정부터 알아야 모델에 무엇을 넣고 있는지 더 정확히 볼 수 있다.
이어 읽기
- AI Agent란 무엇인가: 챗봇과 무엇이 다른가
- AI Agent Memory와 Session의 차이
- Tool Calling이란 무엇인가: Model은 Tool을 직접 실행하지 않는다
- 다음 편: Token과 Embedding — 문장은 어떻게 모델의 입력이 되는가. 발행 후 링크를 연결한다.
참고 자료
- Dive into Deep Learning — Language Models: 조건부 확률과 Token 단위 Cross-entropy.
- PyTorch — Automatic Differentiation: Gradient와 Backpropagation.
- PyTorch — Optimizing Model Parameters: Loss 계산과 Parameter 갱신.
- Brown et al. — Language Models are Few-Shot Learners (2020): 가중치 갱신 없이 지시·예시를 제공한 평가 조건.
- Anthropic — Building effective agents: Workflow와 Agent의 경계.
자료 확인일: 2026-09-29. 수치 예제는 위에 공개한 교육용 모형의 계산값이다. 실제 LLM의 학습 결과나 자율 시스템의 성능 측정값이 아니다.