26년 여름 인턴 준비 리스트

1. AI Agent

순위	요구 지식	이유
1	Python 기초	Agent와 Tool을 함수 및 클래스로 구현
2	API 및 JSON	외부 서비스와 LLM을 연결
3	LLM 기본 원리	모델의 한계와 응답 특성 이해
4	프롬프트 엔지니어링	역할, 규칙, 출력 형식 제어
5	Function Calling 및 Tool Calling	LLM이 적절한 도구를 호출하도록 구현
6	Agent Workflow	분기, 반복, 종료 조건 설계
7	상태 및 메모리 관리	중간 결과와 대화 기록 관리
8	RAG	문서 및 데이터 검색 기반 답변 구현
9	데이터베이스	사용자 정보, 실행 기록, 문서 저장
10	검색 및 재랭킹	관련 자료를 정확하게 선별
11	평가 방법	Agent 성능을 객관적으로 측정
12	비동기 및 병렬 처리	여러 API와 도구를 효율적으로 실행
13	백엔드 개발	Agent를 웹 서비스로 배포
14	보안	API Key, 개인정보, 도구 권한 보호
15	배포 및 운영	로그, 비용, 장애, 버전 관리

 

 

2. 벡터 디비

상황	추천
처음 만드는 학부 프로젝트	Chroma 또는 FAISS
웹 서비스이며 일반 DB도 필요	PostgreSQL + pgvector
기존 PostgreSQL을 사용 중	PostgreSQL + pgvector
로컬에서 간단히 테스트	Chroma 또는 FAISS

 

PostgreSQL
├─ documents 테이블
│  ├─ id
│  ├─ title
│  ├─ content
│  ├─ source
│  ├─ published_at
│  └─ embedding vector(768)
│
└─ 사용자 질문
   → 질문 임베딩 생성
   → pgvector 유사도 검색
   → 관련 문서 추출
   → LLM에 전달

 

 

3. RAG

1. RAG 정의

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 사용자의 질문과 관련된 자료를 먼저 검색한 뒤, 검색된 자료를 LLM에 전달하여 답변을 생성하는 방식입니다.

기본 흐름은 다음과 같습니다.

자료 수집
→ 문서 분할
→ 문서 임베딩
→ 벡터 DB 저장
→ 사용자 질문 임베딩
→ 유사 문서 검색
→ 검색 문서와 질문을 LLM에 전달
→ 답변 생성

 

LLM이 학습할 때 알고 있던 정보만 사용하는 것이 아니라, 외부 문서나 최신 자료를 근거로 답변하게 만드는 것이 핵심입니다.

---

2. RAG의 필수 개념

문서 수집

PDF, 기사, 보고서, 웹페이지, DB 데이터 등 답변 근거로 사용할 자료를 확보하는 단계입니다.

청킹(Chunking)

긴 문서를 일정한 크기의 작은 문단으로 나누는 과정입니다.

예를 들어 100페이지 보고서를 한 번에 검색하지 않고 300~1,000토큰 정도의 문단 단위로 분할합니다.

청크가 너무 크면 불필요한 내용이 많이 포함되고, 너무 작으면 문맥이 끊길 수 있습니다.

임베딩(Embedding)

텍스트를 의미를 나타내는 숫자 벡터로 변환하는 과정입니다.

"전력 수요가 증가하고 있다"
→ [0.14, -0.32, 0.71, ...]

 

의미가 비슷한 문장은 벡터 공간에서도 가까운 위치에 배치됩니다.

벡터 DB

문서의 임베딩 벡터와 원문, 제목, 날짜, 출처 등의 메타데이터를 저장하고 검색하는 데이터베이스입니다.

예시는 다음과 같습니다.

• PostgreSQL + pgvector
• Qdrant
• Pinecone
• Milvus
• Weaviate
• Chroma
• FAISS

검색(Retrieval)

질문 벡터와 문서 벡터를 비교하여 가장 유사한 문서 청크를 찾는 과정입니다.

생성(Generation)

검색된 문서와 사용자 질문을 LLM에 함께 전달하여 최종 답변을 작성하는 단계입니다.

---

3. 문서 임베딩 방식

문서를 임베딩하려면 일반적으로 임베딩 전용 모델을 사용합니다. 반드시 Hugging Face에서 가져와야 하는 것은 아닙니다.

Hugging Face 모델 사용

오픈소스 임베딩 모델을 직접 다운로드하여 로컬에서 실행하는 방식입니다.

대표적인 모델 계열은 다음과 같습니다.

• Sentence-Transformers
• BGE
• E5
• GTE
• KoSimCSE
• multilingual-e5

장점은 무료로 로컬 실행이 가능하다는 것이고, 단점은 모델 관리와 서버 자원이 필요하다는 것입니다.

API 임베딩 사용

OpenAI, Google, Cohere 등의 임베딩 API를 호출하는 방식입니다.

문서 텍스트
→ 임베딩 API 호출
→ 벡터 반환
→ 벡터 DB 저장

 

구현이 간단하고 성능이 안정적이지만, 호출 비용과 외부 전송 문제가 있습니다.

직접 학습한 모델 사용

특정 분야의 검색 성능을 높이기 위해 임베딩 모델을 직접 파인튜닝할 수도 있습니다.

예를 들어 전력시장 문서에서 비슷한 문장과 다른 문장을 학습시켜 에너지 분야 전용 임베딩 모델을 만들 수 있습니다. 다만 일반적인 프로젝트에서는 먼저 기존 임베딩 모델을 사용하는 것이 효율적입니다.

상황별 선택

상황권장 방식

간단한 학부 프로젝트	Hugging Face Sentence-Transformers
한국어 문서 중심	한국어 또는 다국어 임베딩 모델
빠른 서비스 개발	임베딩 API
보안이 중요한 내부 문서	로컬 Hugging Face 모델
전문 분야 검색 정확도 필요	도메인 모델 또는 파인튜닝
대규모 상용 서비스	API 또는 전용 임베딩 서버

---

4. 질문 임베딩 방식

사용자 질문도 문서와 동일하게 임베딩 모델에 입력하여 벡터로 변환합니다.

문서 청크
→ 임베딩 모델 A
→ 문서 벡터

사용자 질문
→ 임베딩 모델 A
→ 질문 벡터

 

가장 중요한 원칙은 문서와 질문에 같은 임베딩 모델을 사용해야 한다는 것입니다.

---

5. 질문과 자료의 유사도 검사 방식

코사인 유사도

RAG에서 가장 일반적으로 사용하는 방식입니다.

질문 벡터와 문서 벡터의 방향이 얼마나 비슷한지를 계산합니다.

질문 임베딩
↕ 코사인 유사도 계산
문서 임베딩

 

값이 높을수록 의미가 유사하다고 판단합니다.

대부분의 Sentence-Transformers 기반 RAG에서는 코사인 유사도를 기본으로 사용합니다.

내적(Dot Product)

두 벡터의 대응 값을 곱한 뒤 합산하는 방식입니다.

정규화된 임베딩에서는 코사인 유사도와 유사한 결과가 나오며, 일부 모델은 내적 검색을 기준으로 학습됩니다.

---

6. 실무에서 가장 일반적인 검색 방식

일반적인 RAG에서는 다음 구조를 많이 사용합니다.

1차 검색
질문 임베딩과 문서 임베딩의 코사인 유사도 계산
→ 상위 10~50개 문서 선택

2차 재랭킹
Cross-Encoder 또는 Reranker로 질문과 문서를 다시 정밀 비교
→ 최종 상위 3~10개 선택

답변 생성
선택된 문서를 LLM에 전달

 

간단한 프로젝트에서는 다음만으로도 충분합니다.

임베딩 모델
+ 코사인 유사도
+ Top-k 검색
+ LLM 답변 생성

 

 

4. LangGraph의 State

1. State 정의

State는 LangGraph 실행 과정에서 여러 노드가 공동으로 읽고 갱신하는 현재 작업 상태 데이터입니다.

쉽게 말하면 Agent가 현재까지 수행한 내용과 다음 작업에 필요한 정보를 담는 공용 저장 공간입니다.

State 예시
├─ 사용자 질문
├─ 대화 기록
├─ 검색된 문서
├─ 선택한 도구
├─ 도구 실행 결과
├─ 현재 처리 단계
├─ 오류 정보
└─ 최종 답변

 

각 노드는 현재 State를 입력받아 작업하고, 변경할 값만 반환합니다. LangGraph는 반환된 값을 기존 State에 반영한 뒤 다음 노드로 전달합니다.

---

2. State의 기본 지식

State는 DB와 다름

State는 Agent의 현재 실행 문맥과 중간 결과를 관리합니다.

반면 DB는 사용자 정보, 문서, 업무 결과 등 장기간 보관해야 하는 데이터를 저장합니다.

State
현재 질문, 검색 결과, 작업 단계, 임시 판단

DB
회원 정보, 원본 문서, 과거 보고서, 장기 기록

 

다만 Checkpointer를 연결하면 State를 실행 단계마다 저장하여 중단된 작업을 이어가거나 이전 상태를 확인할 수 있습니다.

모든 노드가 같은 State 구조를 사용함

검색 노드, 판단 노드, 도구 실행 노드, 답변 생성 노드는 같은 State 구조를 공유합니다. 각 노드는 자신에게 필요한 항목만 읽고 갱신합니다.

노드는 전체 State를 다시 반환하지 않아도 됨

예를 들어 검색 노드는 검색 결과만 반환하고, 답변 노드는 최종 답변만 반환할 수 있습니다. LangGraph가 기존 State와 새 결과를 합칩니다.

같은 항목의 갱신 방법을 정해야 함

기본적으로 새로운 값이 기존 값을 덮어씁니다.

하지만 대화 기록처럼 계속 누적해야 하는 값은 Reducer를 사용하여 기존 목록 뒤에 새 값을 추가하도록 설정합니다.

---

3. State의 주요 구성 요소

State에 어떤 항목이 존재하고 각 항목의 자료형이 무엇인지 정의한 구조입니다.

question        : 문자열
messages        : 메시지 목록
documents       : 문서 목록
tool_name       : 문자열
tool_result     : 문자열
retry_count     : 정수
final_answer    : 문자열

 

Python에서는 일반적으로 TypedDict, dataclass, Pydantic 모델 등으로 정의합니다. TypedDict가 일반적

Reducer

노드가 반환한 새 값을 기존 State에 어떻게 반영할지 결정합니다.

덮어쓰기	기존 검색 결과를 새 검색 결과로 교체
추가	기존 메시지 목록에 새 메시지 추가
병합	기존 딕셔너리와 새 딕셔너리 결합
합산	기존 횟수에 새로운 값을 더함

예를 들어 final_answer는 덮어쓰기가 적절하고, messages는 누적이 적절합니다.

Node

State를 입력받아 실제 작업을 수행하고 State 갱신값을 반환하는 함수입니다.

질문 분석 노드
검색 노드
도구 선택 노드
도구 실행 노드
답변 생성 노드
검증 노드

 

Edge

한 노드가 끝난 후 어느 노드를 실행할지 결정하는 연결입니다.

고정 Edge는 항상 정해진 노드로 이동하고, 조건부 Edge는 State 값을 확인하여 다음 노드를 선택합니다.

START와 END

START는 그래프 실행 시작점을 의미하고, END는 실행 종료점을 의미합니다.

Checkpointer

각 실행 단계의 State를 저장하는 구성 요소입니다.

이를 사용하면 다음 기능을 구현할 수 있습니다.

• 대화 상태 유지
• 오류 발생 후 재시작
• 작업 중단 후 재개
• 사용자 승인 대기
• 이전 실행 단계 확인
• 특정 시점부터 다시 실행

LangGraph는 Checkpointer가 연결된 경우 각 단계의 State를 체크포인트로 저장합니다.

---

4. State 구현 방법

코드 없이 구현 순서를 설명하면 다음과 같습니다.

1단계: Agent가 기억해야 할 정보 결정

먼저 전체 작업에서 어떤 데이터가 계속 전달되어야 하는지 정합니다.

예를 들어 뉴스 검색 Agent라면 다음 항목이 필요합니다.

사용자 질문
검색 키워드
검색 결과
선택된 기사
요약 결과
검증 결과
최종 답변

 

2단계: State Schema 설계

각 항목의 이름과 자료형을 정합니다.

사용자 질문: 문자열
검색 키워드: 문자열 목록
검색 결과: 기사 목록
검증 통과 여부: 참 또는 거짓
반복 횟수: 정수
최종 답변: 문자열

 

State에는 필요한 값만 포함해야 합니다. 모든 원본 데이터나 대형 파일을 State에 직접 저장하면 상태가 지나치게 커질 수 있으므로, 필요하면 파일 경로나 DB ID만 저장합니다.

3단계: 각 필드의 갱신 방식 결정

각 값이 덮어써져야 하는지 누적되어야 하는지 정합니다.

사용자 질문: 기존 값 유지
검색 키워드: 필요 시 교체
검색 결과: 새 결과로 교체하거나 누적
대화 기록: 계속 추가
반복 횟수: 1씩 증가
최종 답변: 새 값으로 교체

 

4단계: Node별 역할 결정

각 Node가 어떤 State를 읽고 어떤 State를 변경할지 정합니다.

Node읽는 State갱신하는 State

질문 분석	사용자 질문	검색 키워드
자료 검색	검색 키워드	검색 결과
자료 검증	검색 결과	검증 결과
답변 생성	질문, 검색 결과	최종 답변
품질 검사	최종 답변	통과 여부, 수정 의견

5단계: Edge와 분기 조건 설계

State의 값에 따라 다음 실행 위치를 정합니다.

검증 통과 = 참
→ 답변 생성

검증 통과 = 거짓
→ 다시 검색

반복 횟수 초과
→ 오류 처리 또는 현재 결과로 종료

 

6단계: 그래프 실행

초기 State에 사용자 질문을 넣고 그래프를 시작합니다.

각 노드는 다음 과정을 반복합니다.

현재 State 입력
→ 노드 작업 수행
→ 일부 State 갱신
→ Edge가 다음 노드 결정
→ 갱신된 State를 다음 노드에 전달

 

7단계: 필요하면 State 영속화

대화를 여러 요청에 걸쳐 유지하거나 작업 중단 후 재개해야 한다면 Checkpointer를 연결합니다.

같은 사용자 또는 같은 대화에 동일한 Thread ID를 사용하면 이전 State를 이어서 사용할 수 있습니다.

---

5. 전체 동작 예시

에너지 뉴스 조사 Agent를 예로 들면 다음과 같습니다.

초기 State
사용자 질문 저장

↓ 질문 분석 노드
검색 키워드 생성
State에 검색 키워드 저장

↓ 뉴스 검색 노드
뉴스 API 호출
State에 검색 결과 저장

↓ 검증 노드
출처, 날짜, 관련성 확인
State에 검증 결과 저장

↓ 조건부 분기
자료가 부족하면 검색 노드로 복귀
자료가 충분하면 요약 노드로 이동

↓ 요약 노드
선택된 기사를 요약
State에 요약 결과 저장

↓ 답변 생성 노드
질문과 요약 결과를 기반으로 답변 작성
State에 최종 답변 저장

↓ END
최종 답변 반환

 

핵심 정리

State는 LangGraph Agent가 실행되는 동안 필요한 데이터와 중간 결과를 노드 간에 전달하는 공용 상태 객체입니다.

LangGraph의 기본 구조는 다음과 같습니다.

State: 현재 정보를 저장
Node: 실제 작업 수행
Edge: 다음 작업 결정
Reducer: State 갱신 방식 결정
Checkpointer: State를 저장하고 복구

 

구현의 핵심은 어떤 정보를 State에 저장할지, 각 Node가 무엇을 읽고 변경할지, 어떤 조건으로 다음 Node를 선택할지를 먼저 설계하는 것입니다.

 

 

5. SQL

다른 문서