똥대

LLM 워크플로우의 필요성

• 범용성을 다소 희생하는 대신, 특정 도메인에 집중하여 더 복잡한 작업을 높은 정확도로 수행하기 위해 LLM 워크플로우를 도입합니다.
• 큰 작업을 작고 명확하게 정의된 세부 작업들로 분해하고, 관리자 프로세스가 이를 조정 및 분배하여 원하는 결과를 도출합니다.

9.1 대화형 에이전트로 충분할까 ?

이렇게 각각 모든 쇼피파이를 사용하는 온라인 매장을 가져와서, 각각 맞는 니즈를 파악해서 메일로 다시 제안한다 ? 

LLM 이라면 가능하다. 어떻게 대화형 에이전트만으로 수행이 되는걸까?

"여러 쇼피파이 온라인 매장을 수집하고, 각 매장에 어울릴 새로운 플러그인 아이디어를 생각한 뒤 각 매장 운영자에게 마케팅 이메일을 보내줘" -> 이건 말도안된다. 별로 도움이 되지 않는다.

하지만, 더 나은 결과를 얻는 것을 돕기 위해 에이전트에 도구를 제공하면 된다.

search_web, browse_site, send_email 같은 ..

9.2 기본 LLM 워크플로

1. 목표 정의하기
   • 워크플로의 목적과 최종적으로 달성하고자 하는 결과물 또는 변화를 명확히 파악합니다.
2. 작업 구체화하기
   • 워크플로를 일련의 작업으로 나누고 순서대로 실행되도록 설계합니다.
   • LLM 기반 작업의 경우 필요한 도구, 입력 및 출력을 파악합니다.
3. 작업 구현하기
   • 입력과 출력이 명확히 정의되도록 작업을 구성합니다.
   • 각 작업이 독립적으로 올바르게 작동하는지 확인합니다.
4. 워크플로 구현하기
   • 작업들을 서로 연결하여 완전한 워크플로를 구성합니다.
   • 전체적인 맥락에서 원활하게 작동하는지 조율합니다.
5. 워크플로 최적화하기
   • 품질, 성능, 비용을 개선하기 위해 작업을 지속적으로 최적화합니다.

9.2.1 작업

두번쨰 작업은, 명세화 하는 것이다.

Shopify 플러그인 프로모터 예시에서 워크플로우를 구성하는 5가지 하위 작업은 다음과 같습니다.

1. 인기 있는 Shopify 스토어 목록 생성 및 웹사이트 HTML 코드 가져오기
2. 각 매장의 제품 구성, 브랜딩, 스타일, 가치관 등 세부 정보 추출
3. 각 매장을 검토하여 비즈니스에 도움이 될 만한 플러그인 고안
4. 각 매장 소유주에게 플러그인 개념을 홍보하는 마케팅 이메일 생성
5. 이메일 전송

세번째 작업을 구현하는 단계로 넘어가서.

전반적인 목표의 하위 단계를 말한다.

작업들이 서로 연결되어 매끄럽게 실행되려면 명확한 데이터 구조(스키마)가 정의되어야 합니다.

LLM을 활용한 작업 구현 방식은 크게 두 가지다.

• 프롬프트 템플릿: 입력 정보를 템플릿에 넣고, 작업에 맞는 결과를 생성한다. 여러 번 실행해 결과를 살펴보며 지침과 맥락을 다듬는다. 생성 결과에서 필요한 부분만 추출해 다음 단계로 전달한다.(랭체인이 권장하는 접근법)
• 도구 호출: HTML 같은 자유 형식 자료에서 이름·주소·전화번호처럼 구조화된 정보를 뽑을 때, 원하는 데이터 형식에 맞는 도구를 정의해 모델이 그 형식으로 결과를 반환하게 한다. 결과 구조가 복잡하면 작은 단위로 나눠 추출한다.

* 작업을 정교하게 다듬기 *

첫 프롬프트의 결과가 기대에 못 미치면 먼저 요구사항을 사람이 읽어도 분명하게 이해할 수 있도록 다듬는다. 그래도 문제가 남으면 다음 방법을 적용할 수 있다.

• 단계별 추론 유도: 모델이 도구를 부르기 전에 먼저 계획하고 생각하게 한다. OpenAI API에서는 도구 사양은 제공하되 tool_choice: "none"으로 당장 도구를 호출하지 못하게 할 수 있다.
• 자기 교정(Reflexion): 결과를 형식 검사, 코드 실행·테스트, LLM 검토 등으로 평가한다. 실패하면 오류 보고서와 이전 시도를 프롬프트에 넣어 다시 생성한다. 품질은 높일 수 있지만 비용과 시간이 늘어난다.
• 에이전트 협업: 개방형·복잡한 문제는 도구를 갖춘 전문가 에이전트와 이를 안내하는 사용자 프록시 에이전트가 협력하게 할 수 있다. AutoGen이 이런 구조를 지원한다.

모든 작업에 LLM을 쓸 필요는 없다.

• 웹 페이지 수집이나 데이터 저장처럼 규칙적인 작업은 크롤러·일반 코드로 처리한다.
• 분류처럼 가벼운 작업은 BERT 같은 전통적 머신러닝 모델이 더 빠르고 저렴할 수 있다.
• 비용이 크거나 되돌리기 어려운 작업, 사람의 판단이 필요한 작업에는 사람의 승인·검토 단계를 둔다.
• LLM이 필요한 경우에도 간단한 작업은 저렴한 모델로, 어려운 작업은 성능 높은 모델로 나눠 맡긴다.

핵심: 작업마다 가장 적합한 방식을 고르고, 결과 검증과 사람의 감독을 워크플로에 포함하면 품질과 안전성을 높일 수 있다.

9.2.2 워크플로 구성하기

이제 워크플로우를 한개로 조립하면된다. 여러 방법들이 있다.

파이프라인 (Pipeline):

• 작업들이 순차적으로 연결되어 각 작업의 출력이 최대 하나의 작업에만 입력으로 사용되는 가장 단순한 구조입니다.
• 장단점: 단순하지만 유연성이 떨어져, 특정 정보를 여러 곳에서 재사용하기 어렵습니다.

방향성 비순환 그래프 (DAG, Directed Acyclic Graph):

• 하나의 작업이 여러 하위 작업으로 출력을 보내거나 여러 상위 작업의 입력을 받을 수 있는 구조입니다.
• 상위 종속 작업이 모두 성공해야만 다음 작업이 실행되며, Airflow나 Luigi 같은 널리 쓰이는 자동화 플랫폼에서 활용됩니다.

순환 그래프 (Cyclic Graph):

• 출력된 정보가 상위 작업으로 되돌아가 루프(Loop)를 형성하는 네트워크입니다.
• LLM의 오류를 수정하기 위한 품질 관리(품질이 부족할 경우 상위 단계로 되돌려 보내는 등)에 유용할 수 있습니다.
• 주의점: 복잡성이 크게 증가하며, 오류 정보 재결합 처리, 실패 정보 처리, 무한 순환 방지(시도 횟수 제한) 등의 복잡한 예외 처리가 필요합니다. 가급적 재귀 호출은 작업 내부에 숨기는 것이 좋습니다.

* 그 외 *

• 일괄 워크플로 (Batch Workflow): 알려져 있고 유한한 작업 항목 집합을 처리하며, 설정 및 유지 관리가 간단하고 대용량 데이터 처리에 유리합니다.
• 스트리밍 워크플로 (Streaming Workflow): 프로세스 도중 생성되거나 검색되는 임의의 작업 항목을 처리하며, 실시간 저지연 작업에 적합하지만 상대적으로 더 복잡합니다.

워크플로 최적화

워크플로를 만든 뒤에는 단순히 프롬프트를 고치는 데 그치지 말고,

작업 자체가 목표에 맞는지 먼저 점검해야 한다. 

작업 결과를 평가해 개선점을 제시하는 작업 단계의 피드백을 넣거나, 실패한 항목을 워크플로 앞단으로 돌려보내는 전체 흐름의 피드백을 설계할 수도 있다.

또한 각 작업의 입력과 출력 예시를 모아 오프라인 테스트를 만들면, 프롬프트를 바꿀 때 결과가 나빠지는지 배포 전에 확인할 수 있다. DSPy와 TextGrad는 이런 예시와 평가 기준을 이용해 프롬프트를 자동으로 최적화하는 프레임워크다.

운영을 시작한 뒤에는 실제 입력·출력 데이터를 기록하고 샘플링해 품질을 살핀다. 실제 트래픽에서 A/B 테스트를 진행하면 서로 다른 구현 방식을 비교할 수 있다.

핵심: 작업 설계, 피드백, 오프라인 테스트, 운영 데이터와 A/B 테스트를 반복해 워크플로의 품질을 지속적으로 개선한다.

9.3 고급 LLM 워크플로

기본 워크플로는 작업과 순서가 정해져 있어 안정적이고 디버깅하기 쉽지만, 미리 설계한 범위를 벗어나는 상황에는 유연하게 대응하기 어렵다. 고급 워크플로는 LLM에 더 많은 자율성을 주어 개방적인 문제를 다룰 수 있지만, 그만큼 예측과 통제가 어려워진다.

1. LLM이 워크플로를 주도

워크플로 자체를 에이전트로 만들어, 상황에 따라 작업을 선택하고 순서를 정하게 할 수 있다. 더 나아가 필요한 작업 에이전트를 즉석에서 만들거나, 여러 작업의 우선순위를 계속 조정하게 할 수도 있다. 이때 에이전트가 대화를 끝없이 이어가지 않도록, 완료 결과를 제출하는 finish 같은 명확한 종료 방식이 필요하다.

2. 상태를 유지하는 작업 에이전트

일반적인 작업은 입력을 받으면 처리한 뒤 끝나지만, 상태 저장 에이전트는 특정 파일이나 자산을 계속 관리한다. 다른 에이전트나 사용자가 변경을 요청하면 해당 내용을 수정하고, 관련 에이전트에 변경 사실을 알릴 수 있다. 다만 서로 의존하는 작업이 순환하며 무한 반복되지 않도록 의존성 관리를 해야 한다.

3. 역할과 위임

각 에이전트에 역할·목표·도구를 부여하고 팀처럼 협력시킬 수 있다. AutoGen은 여러 에이전트를 관리하는 그룹 채팅 구조를 지원하고, CrewAI는 역할과 작업을 가진 에이전트들을 순차적 또는 계층적으로 구성하는 방식을 제공한다. 이런 프레임워크는 편리하지만, 사용 목적에 꼭 필요한지 먼저 따져봐야 한다.

핵심 결론

복잡한 목표는 여러 작은 작업으로 나누고, 가능하면 LLM 없이 일반 코드나 전통적인 머신러닝으로 처리하는 것이 더 안정적이다. LLM이 필요한 단계만 에이전트로 만들고 나머지는 정해진 워크플로로 연결하면 문제를 찾고 개선하기 쉽다. 더 많은 유연성이 꼭 필요할 때 고급 구조를 시도하되, 자율성이 커질수록 신뢰성과 통제는 어려워진다는 점을 고려해야 한다.

이 장에서는 LLM 기반 대화형 에이전트를 구축하는 여러 최첨단의 접근 방식을 소개한다.

8.1 도구 활용

1. 도구 정의 및 활용

LLM 은 혼자서온도조절을 할수 없다.

그렇기에 도구가 필요하다.

여기서 파이썬 라이브러리를 찾는 것은 어렵지 않다.

이렇게 함수를 정의 하고,

AI에게 우리가 만든 도구의 설명서를 제공하면된다. 다음과 같다.

다음을 필요할 때, 이름으로 도구를 조회할 수 있도록 조회용 딕셔너리를 생성한다.

만드는 이유는 이제 AI 가 실행할 수 있도록, 리모콘을 만드는 것이다.

예를들어 AI가 온도조절을 해야하는데, 혼자서는 뭣도 안되니, 리모콘을 누르도록 리모콘을 쥐어주는것.

예제1) 메세지 처리하고 도구를 호출 및 평가하는 알고리즘

• 1단계 (전달): 지금까지 나눈 대화 내역(messages)과 사용할 수 있는 도구 목록(tools)을 AI 모델(gpt-4o)에 보냅니다.
• 2단계 (기록): AI 모델이 보낸 응답(일반 답변 또는 도구 호출 요청)을 대화 내역에 바로 추가합니다.(AI 는 이전 대화를 모른다, 그래서 도구를 호출하거나 답변을 했거나 하는걸 다시 묶어서 던져줘야하기 때문에 기록해두어야 한다.)
• 3단계 (확인): AI가 응답에서 도구(함수)를 실행해야 하는지(tool_calls 여부) 확인합니다.
• 4단계 (실행): 도구 사용이 필요하다면, AI가 지정한 함수 이름과 인자(arguments)를 추출해서 실제 파이썬 함수를 직접 실행합니다.(전에 우리가 만든 리모콘을 실행한다.)
• 5단계 (결과 추가): 함수를 실행해서 얻은 결과값을 role: "tool" 메시지 형태로 만들어 대화 내역 끝에 붙여줍니다.

자 이제 다음은 사용자가 온도 몇도 조절해줄래 ? 했을때 과정이다.

이제 role system user 를 정의하고, process_message 를 호출한다.

process_message는 우리가 도구 호출, 평가, 도작을 정의했던, 함수이다.

그러면 message 리스트에 2개의 메시지가 추가된다.

1. assistant 가 온도 조절하는 리모콘을 눌러달라는 tool call

2. 실제로 눌렀더니, 74도인 것

하지만 온도를 아는것이 다가 아니다, 실제로 세팅을 해야한다.

다시 메세지 client 를 세팅하고 process_messages 를 호출(아래)

그럼 

1. assistant : 아까 74도였으니까 2도 높여서 76도로 실행해줘.

2. 76도 설정완료.

하지만 설정 완료하고 끝이 아니다.

하지만 시스템 내부에서 혼자 처리하고 끝내면 사용자 입장에서는 무슨 일이 일어났는지 알 수 없기 때문에, 사용자에게 결과를 알려주기 위해 마지막으로 process_messages를 한 번 더 호출

2. 내부 작동 원리

겉으로 보기에는 모델이 진짜로 코드를 실행하거나 외부 데이터베이스를 직접 조회하는 대단하고 복잡한 기술처럼 보이지만, LLM 내부에서 일어나는 일은 100% '다음 단어(토큰) 예측' 하나뿐.

( OpenAI는 이 내부 프롬프트 형식을 공식 공개하지 않았습니다.)

우리가 어떤 내용을 호출하면 위처럼 변환이 된다.

우리가 제공한 코드도 있고, tool, functions 다양한 내용이 있다.

OpenAI API 서버는 개발자가 보낸 위 JSON을 받아서, 모델이 가장 잘 이해할 수 있는 TypeScript 형태의 텍스트로 변환한 뒤 시스템 프롬프트 맨 뒤에 합쳐서 모델에게 전달한다.

즉, 모델에맞춰서 TypeScript 형태로 바꾸어야 하는 가장큰 이유는 :

• 토큰 절약: JSON 전체 구조를 그대로 주입하는 것보다 TypeScript 인터페이스 형태의 텍스트로 변환하는 것이 토큰 길이가 더 짧습니다.
• 이해도 향상: 모델은 사전 학습(Pre-training) 때 TypeScript 코드와 주석을 수없이 많이 읽었기 때문에, 이 구문을 만나면 "아, 내가 어떤 인자(Key)와 데이터 타입(Value)을 써서 함수를 불러야 하는구나!"를 훨씬 더 명확하게 파악합니다.(우리가 어셈블러 언어를 배우는 것도 동일한 이치)

우리가 위에서 핑퐁한 대화들의 내용이 여기 있다.

LLM이 assistant to=functions.set_room_temp {"temp": 77}라는 글자를 적을 때, 속으로는

"1. 어시스턴트로 ➔ 2. 도구를 쓰자 ➔ 3. 온도 설정 함수로 ➔ 4. temp 파라미터에 ➔ 5. 77이라는 값을 넣어서 ➔ 6. 끝!"

이라는 6단계 의사결정을 순간적으로 거치며 단어를 하나씩 이어 쓴다는 뜻입니다.

[대화형 AI(LLM)에 사용할 도구(Function/Tool)를 설계할 때 지켜야 할 가이드라인]

. 핵심 전제 (대원칙)

• 사람이 이해하기 쉬운 것이 LLM에게도 쉽다.
• 모델이 이미 대량의 학습 데이터로 알고 있는 형식이나 명명법을 그대로 활용하는 것이 가장 효과적

1. 적절한 도구 선택 (Selecting the right tools)
   • 한 번에 제공하는 도구 개수를 최소화하고, 기능이 중첩되지 않도록 역할을 명확히 분리해야 모델의 혼란을 막습니다.
   • 복잡하고 거대한 백엔드 REST API를 그대로 주입하지 말고, LLM 전용으로 단순화된 도구를 만들어 전달하세요.
2. 도구 및 인수 명명 (Naming tools and arguments)
   • 사람이 읽어도 한눈에 의도를 파악할 수 있도록 의미가 명확하고 자가 설명적인 이름을 지정해야 합니다.
   • retrieveemail처럼 구분 없이 붙여 쓴 소문자 단어는 파싱이 어려우므로 camelCase 같은 명확한 관례를 따르세요.
3. 도구 정의 (Defining tools)
   • 법률 문서처럼 복잡한 용어는 피하고, 모델이 사용법을 직관적으로 이해할 수 있게 가볍고 명확하게 정의하세요.
   • 이미 모델이 잘 알고 있는 공공 API(예: GitHub API 등)를 연동할 때는 기존 문서의 명칭과 스타일을 그대로 따르는 것이 좋습니다.
4. 인수 처리 (Dealing with arguments)
   • 파라미터는 기본 타입(string, number, boolean, enum) 위주로 가급적 적고 단순하게 유지하세요.
   • 대화 맥락에 없는 정보로 모델이 임의의 값을 지어내는 환각을 막으려면 필수 인자를 아예 제거하거나 애플리케이션 기본값을 활용하세요.
5. 출력 처리 (Dealing with tool outputs)
   • 도구의 실행 결과는 모델이 다음에 무엇을 할지 예측할 수 있도록 정형화되거나 깔끔한 텍스트로 전달하세요.
   • "혹시 몰라 넣은" 불필요한 정보는 모델의 주의를 산만하게 만들어 환각이나 오류를 유발하므로 과감히 제외하세요.
6. 오류 처리 (Dealing with tool errors)
   • 도구 실행 중 에러가 발생하면 내부 시스템 로그를 그대로 던지지 말고, 모델이 이해할 수 있는 형태의 에러 정보로 변환하세요.
   • 유효성 검사 실패 등 모델이 직접 수정 가능한 에러는 무엇이 틀렸는지 알려주어 스스로 재시도할 수 있게 유도해야 합니다.
7. 위험한 도구 실행 (Executing "dangerous" tools)
   • 실제 데이터 삭제나 송금처럼 파급력이 큰 작업은 "사용자 확인을 받으라"는 프롬프트 지시문만으로 안전을 보장할 수 없습니다.
   • 모델이 자유롭게 요청을 보내도록 두되, 실제 외부 API가 호출되기 전 애플리케이션 레이어에서 이를 가로채 사용자 승인을 받는 안전장치를 만드세요.

8.2 추론

LLM은 원래 머릿속으로 생각하는 기능이 없이 단어를 이어 붙일 뿐이므로, 프롬프트를 통해 '단계별로 생각하는 과정(내적 독백)'을 출력하도록 강제해야 답변의 수준이 올라간다.

8.2.1 생각의 사슬

-> 필요한 정보를 넣으면서 질문해보면 성능향상에 도움이 된다.

• 햄스터 예시: "답하기 전에 이유부터 써라"라고 모델을 훈련시키기 위한 교재(Example)
• 엑소시스트 답변: 그 교재대로 학습해서 이유를 먼저 적다 보니 찍지 않고 정답을 맞춰낸 실전 결과입니다.

-> 즉, 틀릴만한 문제도 이유를 먼저 서술하면서 가는 느낌으로 가면 정답으로 유도될 수 있다.(환각 없어짐)

또한 , 중요한 개념은, 모델이 여러번 요청을 거칠수록 답변의 품질은 올라가고, 모델이 문제에 대해 생각할 시간을 갖도록 조건을 설정하는게 좋다.(품질 향상의 개념에서)

8.2.2 ReAct: 반복 추론 및 행동

사람도 자기 머릿속 지식만으로 바로 답하지 못하고 아래처럼 행동합니다:

1. 생각 (Reasoning): "두 잡지의 창간일을 각각 검색해서 비교해야겠네."
2. 행동 (Action): 구글에 Arthur's Magazine 검색 ➔ 결과 확인
3. 행동 (Action): 구글에 First for Women 검색 ➔ 결과 확인
4. 생각 (Reasoning): "A 잡지는 1844년, B 잡지는 1989년이네. A가 더 빠르다."
5. 결론 (Finish): 최종 대답 출력

이렇게 '생각(Reason)'과 '도구 사용/행동(Act)'을 번갈아 반복하며 다단계 문제(Multistep Problem)를 푸는 패턴을 ReAct라고 부릅니다.

LLM도 똑같다.

1. Search[entity] = 책장에 가서 책 한 권 뽑아 펼치기
   • 역할: 원하는 주제를 검색해서 위키피디아의 가장 첫 5문장(개요)을 읽어옵니다.
   • 쉽게 말해: "위키피디아에서 Arthur's Magazine 책 좀 찾아와서 맨 첫 페이지 읽어봐!" 하는 것입니다.
2. Lookup[string] = 책 안에서 특정 단어 찾기 (Ctrl + F)
   • 역할: 방금 펼쳐둔 책 안에서, 내가 찾고 싶은 특정 단어(예: "창간일", "출판")가 들어간 다음 문장을 찾아 읽습니다.
   • 쉽게 말해: "책 내용은 너무 길니까, 그 책 안에서 1844년이나 출판이라는 단어가 들어간 부분만 바로 찾아서 읽어봐!" 하는 것입니다.
3. Finish[answer] = 정답지에 답 적고 제출하기
   • 역할: 정보를 충분히 모아서 답을 알게 되었을 때, 검색을 멈추고 최종 답을 사용자에게 내놓습니다.
   • 쉽게 말해: "이제 답 찾았으니까 검색 그만하고, *'Arthur's Magazine이 더 먼저 나왔습니다'*라고 정답 제출하자!" 하는 것입니다.

8.2.3 ReAct를 넘어

ReAct 가 LLM 애플리케이션에서 추론 능력을 개선하는 데, 매우 중요한 진전을 이룬건 맞지만 마지막은 아님.

1. Plan-and-Solve (먼저 계획부터 세우기)

• 방식: 다짜고짜 문제 해결(검색/행동)에 뛰어들지 않고, 전체적인 계획부터 먼저 세운 뒤 단계별로 문제를 풀게 만듭니다.
• 핵심 프롬프트: "먼저 문제를 이해하고 해결 계획을 수립하자. 그다음 그 계획에 따라 단계별로 문제를 풀어보자."
•  
• 특징: 도구(검색)를 쓰기 전에 전체 그림을 그려보게 하여 논리적 실수를 줄이는 방법입니다.

2. Reflexion (자기 반성 및 피드백)

• 방식: 일이 끝난 뒤 자신이 한 작업 결과를 되돌아보고(Review), 어디가 잘못되었는지 반성하여 다음번 계획을 수정하게 만듭니다.
• 실제 활용 예시 (코드 작성):
  1. 모델이 코드를 작성합니다.
  2. 단이 테스트(Unit Test)를 돌렸는데 에러가 발생합니다.
  3. 실패 메시지를 모델에게 다시 보여주면, 모델이 반성하고 코드를 수정하여 재시도합니다.

3. Branch-solve-merge 작동 방식

• Branch (가지치기): 하나의 문제를 $N$개의 서로 독립된 LLM 대화 세션(Solvers)으로 나눕니다.
• Solve (해결하기):
  • 높은 Temperature(창의성 수치)를 주어 각자 다르게 시도하게 만들거나, 서로 다른 관점(Perspective)에서 문제를 해결하도록 프롬프트로 지시합니다.
• Merge (병합하기): 모든 AI가 답을 내놓으면, 이를 병합 전담 AI(Merging Agent)에게 전달하여 3개의 결과물을 종합한 더 뛰어나고 완성도 높은 최종 해결책을 만듭니다.

-> 계획-해결 프롬프트가 ReAct에 선제적인 계획 단계를 추가해 보완하는 방식이라면, Reflxion 방식은 정반대의 접근법을 취한다.

1. "Plan-and-Solve는 외부 도구를 쓰는 기법이 아니라, CoT처럼 내부 추론만 이용하되 '실제 문제를 풀기 전 전체 계획부터 먼저 세우도록' 강제하는 프롬프팅 기법"

2. "Reflexion"은 ReAct처럼 작업을 수행한 뒤, "내가 방금 한 작업의 결과물을 평가(Review)하고, 틀린 이유를 스스로 반성(Self-Reflection)하여 다음 시도에 반영하는 피드백 루프 방식"입니다.

3. "Branch-solve-merge는 여러 AI에게 다양한 관점으로 풀어보게 한 뒤 종합하는 방식이며, 지금까지 나온 모든 기법은 AI에게 '생각하는 시간(내적 독백)'을 주기 위한 도구들"

8.3 작업 기반 상호작용을 위한 콘텍스트

프롬프트를 만드기 위해 콘텍스트를 선택하고 구성할때 고려해야할 사항

1. 어떤 도구(Tool)가 필요한가?

• 대화 맥락상 지금 쓰이지 않을 도구 정의는 프롬프트에서 제외(Drop)하여 AI가 딴길로 새지 않게 주의를 줄여줍니다.

2. 어떤 데이터(Artifacts)를 포함할 것인가?

• 모두 포함하기: 정보는 완벽하지만, 불필요한 데이터가 많아져 AI가 혼란을 느낄 수 있습니다.
• AI에게 선택하게 하기: AI에게 필요한 데이터만 고르게 만드는 별도 요청 과정을 거칩니다 (시스템 복잡도 증가).

3. 데이터를 어떤 형식으로 보여줄 것인가?

• <artifact> 같은 XML 태그나 ## Attached Data 같은 마크다운 구획을 활용해 텍스트/JSON 형태로 직접 넣습니다.
• 또는, 도구 호출 기록(Function Call history) 자체를 대화 기록에 그대로 보존하여 자연스럽게 전달하는 방법도 있습니다.

4. 데이터 양은 얼마나 넣어야 하는가?

• 책 전체 내용을 다 넣을 수 없듯, 필요한 핵심만 추출해야 합니다.
• 요약 + 상세 조회 도구: Bullet 요약만 보여주고, 더 필요한 부분은 details('section 5')처럼 함수를 호출해 펼쳐보게(Unfurl) 만듭니다.
• RAG(검색) 활용: 큰 데이터는 전통적인 RAG 방식을 통해 필요한 부분만 검색해서 주입합니다.

5. 이전 대화 기록은 얼마나 과거까지 유지할 것인가?

• 주제가 바꼈거나 일정 시간 반응이 없으면(Timeout) 과거 대화를 잘라냅니다.
• 작은 모델을 별도로 학습시켜 관련 있는 과거 대화만 골라내도록 선별할 수도 있습니다.

8-4. 대화형 에이전트 구축

8.4.2 사용자 경험

왜 이 이름들이 나왔는지 딱 3초 요약

• Dave(데이브) & HAL(할): 영화 《2001 스페이스 오디세이》에 나오는 사람(Dave)과 우주선 AI(HAL)입니다. 영화에서 AI가 고장 나서 사람을 우주선에 안 들여보내주는 유명한 장면이 있습니다.
• McCoy(맥코이): 영화 《스타트렉》에 나오는 의사 캐릭터 이름입니다.

아무튼, 사용자를, 데이브, 맥코이로 사용자가 변경했을때, 결과가 달라진다.라는걸 보여주는것 이다.

즉, "AI가 함부로 사고 치지 않게 UI로 안전장치를 만들어라"

1. 위험한 작업은 꼭 승인받기
   • AI가 결제, 예약, 데이터 삭제처럼 실제 돈이나 시스템을 건드리는 작업을 할 때는 실행 전 사용자에게 [승인 / 취소] 팝업을 띄워 확인을 받아야 합니다.
2. AI가 보고 있는 화면 보여주기
   • AI가 내 화면의 어떤 문서나 데이터를 읽고 답변 중인지 사용자가 볼 수 있게 해줘야 합니다.
   • AI가 엉뚱한 문서를 참고하고 있으면 사용자가 해당 문서를 닫아서 대화가 딴길로 새는 걸 막을 수 있습니다.

주제가 바뀌었다. 그 이유는 영화추천AI 와 스테이블코인(x402)를 붙이기 어렵다는 점이였다.

왜냐하면 영화는 mock data 로 밖에 할 수 없고, 결제까지 이어지기 힘들다는 것이다.

우리가 영화를 산다고 해도, 그 API 를 제공해주지 못했다고 생각했음.

그렇다고 추천할때, 고품질의 data를 돈주고 스테이블코인을 사용한다해도, 누가 그걸 사용할지에 대한 생각을 많이 했다.

그래서 다시 생각한게, 디자인에 대한 AI를 만들자, 즉 처음에는 컴포넌트와 코드를 제공하는 그런 디자인 AI 를 만드려고 했지만, 그것보단 페이지 안에 컴포넌트가 여러개 들어가고 페이지 안에 컴포넌트가 여러개 있다는 것에 장점을 살렸다.

이런 질문이 있을수 있다. "Codex 혹은 클로드에다가 MCP Tool 연결해서 사용하면 되는거 아니냐?" 라고 할 수 있다.

하지만 우리는 다르게 생각한다. 능력있고, 지시잘하고, 깔끔한 디자이너가 그런 요구를 하면 다 들어주긴 할것이다.

하지만 저품질의 퀄리티는 싫고 그렇다고 고품질은 아니여도 되는 그런 계층을 타겟하는 것이다.

많은 사람이 공감할 것이다.

그리고 일단 AGENT 는 3개로 나눌 것이다.

응대 AGENT, 추천 AGENT, 결제AGENT(x402)

전체적인 구조는 다음과 같다.

자 그럼 주요 문제 3가지를 정의하고 들어가자.

첫째, 언제 질문을 멈추고 만들 것인가.
둘째, ‘그럴싸한 품질’을 무엇으로 확보할 것인가.
셋째, 사용자가 제공해야 하는 사실과 AI가 제안할 수 있는 것을 구분

첫번째에 대해서 간략하게 얘기를 해보고 정해보자.

첫째, 언제 질문을 멈추고 만들 것인가.

자 일단, 예를들어 2~3개 질문에서 끝낸다고 생각해보자.

“정보가 얼마나 많이 모였나?”보다 “지금 만들면 중요한 부분을 추측해야 하나?”로 판단하는게 좋아 보인다.

일단 3가지 관점에서 부족한 관점을 찾는게 나아 보인다.

1. 목적 : 이 화면이 사용자에게 어떤 도움이 되어야 하는가?

ex) “방문자가 구경하는 게 중심인가요, 신청하는 게 중심인가요?”

2.핵심 내용, 행동 : 무엇을 보여주고, 무엇을 할 수 있어야 하는가?

ex) “반드시 들어가야 하는 내용이나 기능은 무엇인가요?”

3. 결과를 크게 바꾸는 조건 : 잘못 가정하면 구성이나 동작을 다시 만들어야 하는가?

ex) “관리자가 쓰는 화면인가요, 일반 고객이 쓰는 화면인가요?”

그리고 모르는 정보보다 틀리게 가정하는게 더 안좋다. 이단계도 추가하는게 좋아 보인다.

ex) 카페 만들건데 페이지 만들어줘. -> 카페 회원관리 프로그램인지, 카페 홍보 페이지인지 애매모호하다.

이제 정보가 충분하다고 생각되면(AI가) :

이 화면은 [누가] [어떤 목적]으로 사용하며, 핵심적으로 [무엇을 보고/할 수 있어야] 한다.

반드시 지킬 조건은 [무엇]이고, 나머지 [어떤 부분]은 AI가 제안한다.

여기서 ‘초안을 만들기에 충분함’과 ‘최종 납품에 필요한 정보가 모두 있음’은 다르다.

초안 단계에서 연락처나 최종 문구까지 다 받을 필요는 없다는걸 명심하자.

LLM 내부적으로는 아마 이렇게 판단할 수 있다. (예시)

프롬프트 선언을 이런식으로 하자.

1. 응대 agent 에 넣을 프롬프트는 이렇게 될 수 있다.

2. 실제 입출력 예시

사용자 입력 예시 : 

카페 페이지 제작해줘.

응대 에이전트 출력 예시:

{
  "summary": "카페 관련 페이지 제작. 용도는 미확인.",
  "next_action": "ASK",
  "questions": [
    "손님에게 카페를 소개하는 페이지인가요, 직원이 사용하는 관리 화면인가요?"
  ],
  "assumptions": [],
  "placeholders": []
}

사용자가 답변:

손님한테 소개하는 거고 메뉴랑 위치 보여주면 돼. 디자인은 알아서 해줘.

업데이트된 출력 예시:

{
  "summary": "손님에게 카페를 소개하며 메뉴와 위치를 보여주는 페이지",
  "next_action": "READY_FOR_DRAFT",
  "questions": [],
  "assumptions": [
    "따뜻한 색상과 사진 중심의 구성을 제안"
  ],
  "placeholders": [
    "카페 이름",
    "실제 메뉴와 가격",
    "주소",
    "실제 카페 사진"
  ]
}

서버에서는 ASK면 질문을 보여주고, READY_FOR_DRAFT면 이 정보를 디자인 에이전트에 전달하도록 코딩하면 된다.

** JEV **

https://typesafe.ai/blog/introducing-system-one-models-and-jev

jev 는 boolean 을 반환한다. 맞다 틀리다의 정보를 줄수 있다.

그러면 우리는 그걸 받아서, 사용자에게 물어볼지 확정할지 할수 있다는 것이다.

또한, 각 노드별로 모델을 지정할수 있다. LLM(프론티어 등등)

그래서 경량 제미나이 플래시 jev 같은거로 전처리 및 후처리 노드 구성하고 

핵심인 것들(디자인 제작, 추천, 코드 제작 등등)이런건 고성능으로 구현할 수 있다.

각 노드의 작업 특성에 맞게 모델을 지정할 수 있다.

전처리·후처리에서는 Gemini Flash 같은 빠른 LLM으로 질문 작성과 요약을 처리하고, Jev로 정보 충족 여부나 다음 행동을 판단한다.
디자인 추천·설계·코드 생성처럼 결과물의 품질이 중요한 핵심 단계에는 고성능 프론티어 모델을 사용한다.
이를 통해 품질을 유지하면서 전체 처리 시간과 비용을 줄이는 것을 목표로 한다.

너희에게 추천하는 순서는 이거야.

1. 지금: DeepEval + 일반 코드 검사
   ASK/READY는 기대값과 비교하고, 추가 질문의 적절성은 평가 기준으로 채점해.
2. 여러 모델을 연결한 뒤: 필요하면 Langfuse 추가
   Flash 단독과 Jev + Flash 중 무엇이 더 정확하고 빠른지 비교해.

두 도구를 함께 쓰는 공식 가이드도 있어서, 나중에 DeepEval의 평가 점수를 Langfuse에 기록할 수 있어. 처음부터 둘 다 구축할 필요는 없어.

<서문>

월가보다 한 발 먼저

"나의 경험에 비추어 보면 포트폴리오에 포함된 10개의 종목 중에서 6개만 오르면 만족스러운 실적을 올릴 수 있다."

"왜그럴까? 주가는 마이너스가 될 수 없으므로 손실액은 처음에 투자한 금액에 한정되지만, 상승하는 주가에는 한계가 없기 때문이다."

"내가 앞에서도 지적했듯 시장이 절대 과대평가되지 않는다는 말이 아니라, 시장이 과대평가되었다고지레 걱정할 필요는 없다는 말이다."

<프롤로그>

아일랜드 여행기

1) 쓸데없는 걱정으로 좋은 포트포를 망치지 말라.

2) 쓸데없는 걱정으로 좋은 휴가를 망치지 말라.

3) 현금이 충분치 않을 때는 절대 해외여행을 하지 말라.

<서문>

아마추어 투자자가 유리하다

"전문가의 말에 귀를 기울이지 말라는 것이다!"

"오히려 아마추어투자자는 전문투자자의 말에 귀를 기울일 때 어리석은 투자자가 될 수 있다."

"스스로 조사해야 한다."

피터 린치가 매수중인 종목을 무시해야 하는 정당한 이유는 적어도 세가지가 있다.

1) 그가 틀렸을지 모른다!

2) 그의 선택이 옳다고 하더라도, 언제 마음을 바꿔 그 종목을 매도할지 절대 알 수가 없다.

3) 투자자의 주위에 더 좋은 정보 원천이 널려 있다. 내가 언제든 원할 때 정보를 분석하여 쓸 수 있는 것처럼 투자자 역시 언제든 그러한 원천을 활용할 수 있다는 점이 커다란 장점이다.

제 1부 : 투자 준비

<1. 펀드 매니저가 되다.>

"지금 돌이켜 보니 통계학보다는 역사와 철학 공부가 나의 주식투자에 훨씬 도움이 되었다. 주식투자는 과학이 아니라 기술이다."

"주식시장에 필요한 수학은 초등학교 4학년 정도 수준의 수학만으로 충분하다."

"주식은 평생 끼고 살아야 하는 아내와 같은 존재다."

"랜덤워크 가설은 시장의 등락은 원래 비합리적이며 예측할 수 없다는 것이다."

<2. 월스트리트의 똑똑한 바보들>

"거대한 펀드에는 그 규모만큼이나 커다란 핸디캠이 뒤따른다."

"월스트리트에서 만연한 사고방식에서 벗어나는 순간, 10루타가 가능해진다."

<3. 투자인가, 도박인가?>

"역사적으로 보면 주식투자는 채권투자보다 틀림없이 높은 수익을 보였다."

"좋은 주식이라도 나쁜 시점에 나쁜 가격으로 매수하면 손실을 크게 본다."

"솔직히 말해서 우리가 안심할 수 있을 정도로 투자와 도박을 깔끔하게 구분할 방법은 없다."

"투자에 위험 요소가 뒤따른다는 사실을 일단 받아 들이면 우리는 채권 매수, 주식 매수, 경주마 선택과 같은 유형이 아니라 투자자의 기술, 노력, 모험심에 따라 도박과 투자를 구분할 수 있다."

"계속해서 이기는 사람은 상황이 유리해지면 판돈을 올리고 불리해지면 게임을 포기하는 반면, 계속해서 지는 사람은 기적을 바라며 패배의 스릴을 즐기다 매번 끝까지 가서 결국 비싼 대가를 치르고야 만다."

"불확실성을 감수하고 주식에 투자하는 사람이 얻을 수 있는 가장 커다란 이점은 올바른 선택에 이례적인 보상을 받는다는 사실이다."

<4. 투자자의 자기진단>

"주식을 매수하기전에 다음 3가지 질문부터 답해야한다. 1)내집이 있는가? 2)나는 돈이 필요한가? 3) 내게 주식 투자자로서 성공할 자질이 있는가?"

<5. 지금 시장이 좋은지 묻지 마라>

"경제 전문가가 경제를 예측하지 못하고, 증시 예측가가 주식시장을 예측하지 못한다면, 아마추어 투자자는 도대체 어떻게 투자하라는 것일까?"

"칵테일 이론"

"비전문가가 나에게 종목을 가르쳐주고, 내가이들의 조언을 듣지 않았다고 후회하는 지경이 된다면, 이것은 시장이 정점에 도달해서 곧 추락할 것이라는 확실한 신호다."

"나도 시장을 예측해서 불황에 대비할 수만 있다면 얼마나 좋을까? 그러나 그것은 애초에 불가능한 일이다."

제 2부 : 종목 선정

<6. 10루타 종목을 찾아라>

<7. 주식을 샀다. 그런데 어떤 유형일까?>

"사전 조사 없는 투자는 패를 확인하지도 않고 벌이는 포커와 같다."

"특정한 종목을 제외하면 대기업 주식은 크게 오를 일이 없다."

"대형우량주는 내가 대개 30~50퍼센트 이익을 바라보고 매수하는 종목이다."

"고성장주는 내가 가장 좋아하는 종목군으로, 연 20~25퍼센트의 성장률을 보이고 작고 적극적인 신생 기업이다."

"경기 순환주에 투자할 때는 시기를 잘 선택해야 한다."

"누구든지 이렇게 벌 수 있다. 단 인내심을 발휘하고, 계속 뉴스를 추적하며, 냉정하게 뉴스를 읽을 수 있어야 한다."

"주식의 유형을 분류하는 것은 투자 논리를 개발하는 첫 단계다."

<8. 정말 멋진 완벽한 종목들!>

1) 따분하고 우스꽝스러운 이름

2) 따분한 사업

3) 혐오스러운 사업

4) 분사한 회사

5) 기간투자자가 보유하지 않고, 분석가가 조사하지 않는 회사

6) 유독 폐기물이나 마피아와 연관이 있다고 소문난 회사

7) 음을한 사업을 하는 회사

8) 성장 정체 업종

9) 틈새를 확보한 회사

"나는 항상 틈새를 찾는다. 완벽한 회사는 반드시 틈새를 보유해야한다."

10) 지속적으로 구입하는 제품의 회사

11) 기술을 사용하는 회사

12) 내부자가 주식을 매수하는 회사

13) 자사주를 매입하는 회사

<9. 내가 기피하는 주식>

"내가 기피하는 종목은 가장 인기 있는 업종 중에서도 세간의 주목을 가장 많이 받고 있는 주식이다."

"제 2의 아무개를 조심해라"

"사업다악화 기업을 피하라"

"소문주를 조심하라"

"이름이 멋진 주식을 조심하라"

<10. 이익이 가장 중요하다.>

"결국 이익은 증가하게 되어 있으며 모든 주가는 이익이 증가한다는 가정에서 출발한다"

"회사는 기본적으로 5가지 방법에 따라 이익을 증대시킬 수 있다.

1) 비용을 절감한다.

2) 가격을 인상한다.

3) 신규 시장에 진출한다.

4) 기존 시장에서 매출을 늘린다.

5) 적자 사업을 재활성화하거나, 중단 혹은 매각한다.

<11. 2분 연습>

"회사가 지속적인 번영과 성장을 가속화하기 위해 어떤 일을 하고, 현 상황에 비추어 전망을 어떻게 기대할 수 있을지를 최대한 파악하는 자업이 필요하다. 이것이 바로 '스토리' 파악 이다."

"나는 주식을 매수하기 전에 이 주식에 흥미를 느끼는 이유, 이 회사가 성공하기 위해 필요한 요건, 장래에 예상되는 걸림돌 등에 대해 혼잣말하기를 좋아한다. 이 2분 독백은 소곤거려도 좋고, 근처에 있는 동료에게 들릴 정도로 크게 떠들어도 좋다."

<12. 사실을 확인하라>

"본사를 방문하라. 분위기를 느껴봐라"

<13. 유명한 숫자들>

"일반적으로 주가수익비율이 연성장률의 절반이면 매우 유망하며, 연성장률의 2배라면 매우 불리하다고 말한다."

<14. 스토리를 재 확인하라>

<15. 최종 점검 목록>

1) 저성장주

- 배당 중요하다. 항상 지급되는지, 꾸준하게 증가 되는지.

- 배당이 이익에서 차지하는 비중도 확인.

2) 대형우량주

- 주요 관심사 : 주가, 주가수익비율을 보면 된다.

- 사업다악화로 장차 이익이 감소될 가능성이 있는지 확인

- 회사의 장기 성장률 확인

- 영원히 보유할거라면, 이전 침체기와 시장 폭락때 실적이 어땠는지 확인

3) 경기순환주

- 재고 계속 지켜보고, 수요 공급 관계 살펴보자

- 시장에 새로 진입하는 기업이 있는지 확인

- 경기 회복하면 점차 주가수익비율이 내려갈것을 예상해라

4) 고성장주

- 최근 몇년동안 이익성장률이 얼마였는가?

- 주가수익비율과 성장률이 비슷한 수준인가?

- 확장속도가 빨라지고 있는가?

5) 회생주

- 채권자들이 자금 회수해도 회사가 생존할 수 있는지 가장 중요하다.

- 부채구조는 어떠한가?

- 이미 파산했다면, 주주에게 남은 몫은 얼마인가?

6) 자산주

- 자산의 가치가 얼마인가? 숨은 자산이 있는가?

- 자산에서 차감해야 하는 부채가 얼마인가?

- 회사가 새로 부채를 발생시켜 자산의 가치를 떨어뜨렸는가?

제 3부. 장기적 관점

<16. 포트폴리오 설계>

"장기적으로 주식 투자에서 4~6퍼센트 정도의 수익만 올린다면 이는 바람직하지 않은 실적이다."

"12~15퍼센트 수익을 올리려면 포트폴리오를 어떻게 설계해야 할까? 주식을 몇 종목이나 보유해야 할까?"

1) 투자자가 특정 분야에 강점이 있고

2) 모든 조사기준을 충족하는 흥미로운전망을 발견했다고 판단한다면 

-> 해당되는 종목을모두 보유하는 것이 최근이다.

"소규모 포트폴리오라면 3~10개 정도의 종목을 보유하면마음이 편할 것 같다."

"아무리 대형우량주라도 이 종목이 과대평가된 것이라면 오히려 위험성을 높이게 된다."

"직장 생활 초기의 젊은 투자자라면 투자 수업으로 생활해야하는 노인 투자자보다 10루타 종목을 더 적극적으로 노릴 수 있다. 젊은 투자자들은 실수를 통해서 경험을 쌓음으로써 나중에 좋은 주식을 고르는 안목을 키울 수 있다."

"적절한 수익을 얻으면서 대형우량주를 몇 차례 반복하여 교체 매매하면 대박 종목 하나만큼 실적을 올릴 수 있다."

<17. 매매의 최적 시점>

"이익은 기회가 있을 때 실현하라."

"모두들 알다시피 먼저 우리가 주식을 매입한 이유를 안다면, 우리는 그 주식과 작별해야 하는 시점도 자연스럽게 알 수 있다."

<18. 가장 어리석고 위험한 열두 가지 생각>

" 떨어지는 주식을 바닥에서 잡으려는 시도는 떨어지는 칼을 잡으려는 행동과 마찬가지다."

"회생주 매입에 관심이 있는투자자라면 단지 주가가 많이 떨어졌으니 오를 것 같다는 이유만을 ㅗ주식을 사서는 안 된다."

"사람들은 상황이 조금 나빠지면 더 이상 나빠질 리 없다고 생각하는 경향이 강하다."

"바보 같은 소리로 들리겠지만 내 친구들은 매일 '뉴욕증권 거래소의 10루타 종목들'을 살펴보면서 이런 종목들을 사지 않아서 엄청난 손해를 보았다며 자학한다."

"대개의 경우 원조 우량기업을 조금 비싸게라도 사는 편이 '제 2의 아무개'를 싸게 사는 것 보다 낫다.

<19. 선물, 옵션, 공매도>

<20. 전문가 5만 명이 모두 틀릴 수도 있다.>

"줄곧 출구만 날카롭게 지켜보면서 이들이 연구하고, 주장하며, 뒷받침하는 그 모든 말 중 마지막 20퍼센트만 옳다는 말이다. 결국 재빨리 돈을 챙겨서 출구 밖으로 달아나려는 속셈이다."

<에필로그>

성공의 순간을 만끽하라

1. 영화추천 Agent 구현 시 문제점

1-1. 챗봇과 Agent의 차이부터 이해하기

단순 챗봇은 이렇게 동작해.

사용자: “인터스텔라 같은 영화 추천해줘.”
LLM: 자신이 학습한 지식을 바탕으로 영화 목록 생성.

문제는 실제 존재하지 않는 작품을 말하거나, 현재 볼 수 없는 플랫폼을 추천하거나, 사용자의 조건을 놓칠 수 있다는 거야.

Agent에서는 외부 기능을 사용하게 해.

요청 해석 → 영화 검색 → 상세 정보 조회 → 조건 확인 → 추천.

예를 들어 모델이 다음과 같은 실행 요청을 만들 수 있어.

{
  "tool": "search_movies",
  "arguments": {
    "theme": "우주 탐험과 가족애",
    "max_runtime_minutes": 130,
    "region": "KR"
  }
}

여기서 LLM이 직접 DB를 실행하는 것은 아니야.

네 Python 프로그램이 이 요청을 받아 인자를 검증하고, 실제 검색 함수를 실행하고, 결과를 모델에 돌려줘. 모델은 그 결과를 바탕으로 답변을 만드는 거야.

Spring으로 비유하면 모델은 호출할 Service와 인자를 제안하고, 실제 실행 권한과 검증은 애플리케이션에 남아 있는 구조야.

1-2. 가장 먼저 막히는 것은 Vector DB보다 영화 데이터야

다음 질문부터 해결해야 해.

• 영화 제목·줄거리·장르·러닝타임은 어디서 가져올까?
• 한국어 제목과 원제가 다른 영화를 어떻게 같은 작품으로 인식할까?
• 동일 제목의 리메이크는 어떻게 구분할까?
• 한국에서 현재 볼 수 있는 OTT 정보가 있을까?
• 영화 정보 조회와 실제 대여·예매가 가능한 API는 같은가?

예를 들어 아래 데이터는 서로 성격이 달라.

영화 정보를 제공하는 API가 있다고 해서 그 서비스에서 영화를 구매할 수 있는 것은 아니야.

TMDB 같은 데이터 제공처를 사용한다면 사용 목적에 따른 라이선스와 표시 의무도 확인해야 해. 공식 FAQ는 비상업적 사용과 상업적 사용을 구분하고 있어. developer.themoviedb.org

첫 실습은 권한이 확인된 영화 데이터 수십~수백 건만 있어도 충분해. 최신 OTT 여부는 아직 확인하지 않는다고 범위를 정해도 돼.

1-3. Vector DB는 무엇이고 왜 필요한가

일반 검색은 정확한 조건에 강해.

SELECT *
FROM movies
WHERE runtime_minutes <= 120
  AND release_year >= 2010;

하지만 다음 요청은 SQL 조건으로 바로 바꾸기 어렵지.

“퇴근하고 편하게 볼 수 있는데, 보고 나면 조금 따뜻해지는 영화.”

이런 문장의 의미를 숫자 배열로 바꾸는 것이 임베딩이야.

cf)

1. 토큰 (Token)

• 개념: LLM이 문장을 이해하기 위해 텍스트를 쪼개는 최소한의 단위입니다.
• 역할: 컴퓨터는 글자 그대로를 이해하지 못하기 때문에, 각 토큰에 번호(ID)를 붙여서 처리합니다. (예: "안녕"이라는 단어가 토큰 ID 105번 식인 것과 같습니다.)
• 핵심: 텍스트를 쪼개는 물리적 단위에 가깝습니다.

2. 임베딩 (Embedding)

• 개념: 토큰화된 단어들이나 문장 전체를 수백~수천 차원의 숫자(좌표)로 변환하는 것입니다.
• 역할: 의미가 비슷한 단어들이나 문장끼리는 숫자 공간상에서 서로 가까운 위치에 모이도록 만들어 줍니다.
  • 예를 들어, "따뜻한 커피"와 "아이스 라떼"는 의미가 비슷하므로 임베딩 공간에서 서로 가까운 좌표 값을 가집니다.
• 핵심: 텍스트가 가진 '의미와 맥락'을 수학적 공간에 배치하는 과정입니다.

영화 소개도 숫자 배열로 바꾸고 사용자 요청도 같은 임베딩 모델로 바꿔서, 서로 가까운 영화를 찾는 거지. Vector DB는 이런 벡터를 저장하고 검색하는 데 도움을 줘.

단, 벡터 유사도는 사용자가 좋아할 확률도 아니고, 조건을 만족한다는 보증도 아니야.

“슬프지 않은 가족 영화”를 검색했는데 가족의 죽음을 다룬 영화가 나올 수 있어. 의미적으로는 가족·감정이라는 주제가 비슷하기 때문이야.

그래서 다음 조합이 필요해.

이렇게 의미 검색과 정확한 조건 검색을 결합해야 해.

PostgreSQL에 pgvector를 붙이면 기존 관계형 데이터와 벡터를 함께 다룰 수 있어. 처음에는 정확 검색으로 시작하고, 데이터가 커졌을 때 근사 검색 인덱스를 검토하면 돼. 근사 검색에서는 필터와 인덱스 설정에 따라 후보가 충분히 안 나오는 문제도 살펴봐야 해. GitHub

1-4. 벡터 검색에서 실제로 생기는 문제

영화 한 편의 설명이 짧다면 일단 영화 한 편을 검색 단위 하나로 만드는 것을 권해. 긴 문서 RAG에서 쓰는 청킹을 처음부터 그대로 적용할 필요는 없어.

또 “힐링”, “우울함”, “잔인함” 같은 태그를 LLM으로 생성한다면 원본 사실과 구분해야 해. 자동 생성 태그가 틀릴 수도 있으니까.

1-5. 검색과 추천은 다르다

검색은 후보를 찾는 일, 추천은 후보 중 누구에게 무엇을 먼저 보여줄지 정하는 일이야.

예를 들어 비슷한 영화 30편을 찾았더라도 다음을 고려해 최종 3편을 골라야 해.

• 사용자가 본 영화인지
• 사용자의 선호 장르와 맞는지
• 요청한 러닝타임을 만족하는지
• 비슷한 감독의 작품만 몰려 있지는 않은지
• 추천 이유를 실제 데이터로 설명할 수 있는지

초기에는 학습형 추천 모델까지 만들 필요 없어.

조건 필터 → 의미 검색 → 간단한 점수 정렬 → LLM의 설명 작성만으로도 배울 것이 충분해.

LLM이 최종 후보를 고르게 한다면 반환된 영화 ID가 실제 후보 안에 있는지 코드로 확인해. 후보에 없는 영화를 새로 만들어내지 못하도록 하는 거야.

첫 실습의 완료 기준

요청에서 조건을 뽑아 실제 DB에 있는 영화 3편을 추천하고, 조건에 맞는 작품이 없으면 없다고 말한다.

2. 결제 Agent 구현 시 문제점: x402를 중심으로

2-1. 먼저 무엇을 결제할지 구분해야 해

영화추천 서비스에서는 적어도 세 가지가 가능해.

x402 실습에는 유료 API나 유료 리포트 접근이 가장 직접적이야.

실제 영화 예매까지 가려면 상영 정보, 좌석 확보, 주문 취소, 티켓 발급 같은 별도의 업무가 필요해. x402를 붙였다고 이 기능들이 생기는 것은 아니야.

cf)

영화 추천 실습용 무료 데이터 (가장 추천)

• TMDB API (The Movie Database):
  • 영화 제목, 줄거리, 포스터, 장르, 평점 등을 무료로 제공하는 대표적인 오픈 API입니다.
  • 회원가입만 하면 테스트용으로 충분하고도 남을 만큼의 영화 데이터(줄거리 포함)를 가져올 수 있어서, 영화 추천 시스템이나 의미 검색(Vector DB) 실습용으로 전 세계 개발자들이 가장 많이 씁니다.
• Kaggle (캐글)의 영화 데이터셋:
  • Kaggle에 들어가서 movies dataset이나 Netflix movies 등으로 검색하면, 전 세계 개발자들이 미리 정제해 둔 CSV 파일 형태의 영화 데이터(줄거리, 감독, 배우 등)를 무료로 다운로드할 수 있습니다. 이걸 그대로 파이썬으로 읽어서 벡터 DB에 넣어보면 실습용으로 완벽합니다.

2-2. 스테이블코인과 x402는 같은 것이 아니다

• 스테이블코인: 특정 자산의 가치에 연동되도록 설계된 토큰.
• 스테이블코인 결제: 해당 토큰을 이용해 대금을 지급하는 방식.
• x402: 유료 자원을 요청할 때 결제 조건과 결제 정보를 주고받는 프로토콜.

비유하면 스테이블코인은 지불 수단, x402는 서비스 이용과 결제를 연결하는 약속에 가까워.

또 x402는 AI 없이 일반 프로그램에서도 사용할 수 있어. Agent는 어떤 유료 기능이 필요한지 판단하는 쪽이고, x402는 그 기능에 접근하기 위한 결제 교환을 담당해.

2-3. x402의 기본 흐름

유료 영화 분석 API를 예로 들면 다음과 같아.

1. 클라이언트가 분석 API를 요청한다.
2. 서버가 402 Payment Required와 결제 조건을 반환한다.
3. 클라이언트가 가격·수취인·네트워크·자산을 확인한다.
4. 허용된 조건이면 지갑 측에서 결제용 서명 데이터를 만든다.
5. 결제 정보를 첨부해 요청한다.
6. 서버가 검증·정산을 수행하고 결과를 반환한다.

HTTP v2 규격에는 결제 조건·서명·결과를 전달하는 PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE 헤더가 정의되어 있어. 검증과 정산은 facilitator라는 보조 서비스를 이용할 수 있어. 서명 검증 성공과 실제 정산 성공은 구분해야 해. GitHub

cf)

요약하자면: x402는 특정 회사의 유료 프로그램이 아니라 "웹에서 AI가 돈을 내고 데이터를 사게 만드는 공통 규칙"이며, 이걸 지원하는 오픈소스 라이브러리를 가져다 서버에 붙이거나, 이미 x402를 지원하는 외부 API(주식 데이터, 날씨, 통계 등)를 골라서 내 AI 에이전트가 호출해 쓰게 되는 구조입니다.

2-4. 결제 Agent의 핵심은 말솜씨보다 실행 통제야

다음처럼 모델이 결제 조건을 자유롭게 정하게 만들면 위험해.

“좋아 보이는 서비스니까 이 주소로 적당한 금액을 보내.”

권장 구조는 역할을 나누는 거야.

개인키는 프롬프트·대화 기록·그래프 상태에 넣지 않아. 모델은 필요한 작업을 요청하고, 서명 서비스가 승인 범위 안에서 실행하도록 만들어야 해.

2-5. 반드시 처리해야 하는 실패 상황

① 중복 결제

결제 요청을 보냈는데 응답이 끊겼다고 해보자.

• 실제로 결제되지 않았을 수도 있고,
• 결제는 됐는데 응답만 유실됐을 수도 있어.

여기서 새 결제를 보내면 두 번 결제될 수 있어.

필요한 개념은 멱등성이야.

같은 업무 요청이 반복되어도 결제 효과는 한 번만 발생하도록 설계한다.

주문 ID와 결제 의도를 저장하고, 재요청에서는 기존 상태를 확인해야 해. x402나 블록체인의 재사용 방지 기능만으로 네 서비스의 모든 중복 주문 문제가 해결되지는 않아.

② 결제 성공 후 결과 제공 실패

돈은 냈는데 리포트 생성이 실패할 수 있어.

이 경우 결제 상태와 결과 제공 상태를 분리해야 해.

• 결제: 정산 완료
• 결과: 생성 실패
• 후속 처리: 같은 주문으로 결과 생성 재시도

단순히 결제부터 다시 실행하면 안 돼.

③ 승인한 조건이 바뀜

사용자가 0.01 USDC를 승인했는데 재조회한 견적이 0.02 USDC가 되면?

기존 승인은 새 견적에 자동 적용하면 안 돼. 승인을 견적 ID·금액·자산·수취인·유효기간에 묶어야 해.

④ 잘못된 자산·네트워크

같은 토큰 이름이라도 네트워크나 컨트랙트가 다를 수 있어.

"USDC"라는 문자열만 확인하지 말고, 지원하는 네트워크와 자산 식별자를 검증해야 해. 금액은 부동소수점 대신 정수 최소 단위나 정확한 소수 자료형을 사용해.

⑤ 응답 대기 중 취소

취소 요청이 왔어도 이미 정산됐을 수 있어.

“작업 취소”와 “돈 되돌리기”는 다른 작업이야. 이미 정산된 지급은 별도의 환불 흐름이 필요해.

첫 실습의 완료 기준

모의 결제에서 승인 없는 요청·예산 초과 요청을 차단하고, 같은 주문을 두 번 요청해도 한 번만 처리한다.

이후 테스트넷에서 같은 흐름을 검증하고 x402 SDK를 붙이는 순서가 좋아.

3. A2A와 영화추천 Agent–결제 Agent 연동 문제

3-1. Agent 두 개가 있다고 A2A가 필수는 아니야

같은 Python 애플리케이션 안에서 다음처럼 호출하는 것도 가능해.

recommendation = recommend_movies(preferences)quote = payment_service.create_quote(product_id)

별도 서버라면 일반 REST API를 사용할 수도 있어.

A2A는 서로 독립된 Agent가 능력을 알리고, 작업을 위임하고, 진행 상황과 결과를 교환하는 표준이야. 다른 프레임워크·팀·서비스 사이의 연동에 의미가 커져. 공식 문서에서는 Agent Card, Message, Task, Artifact 같은 개념을 정의해. A2A Protocol

cf)

결제 기능이 정해진 검증·서명·조회만 한다면, 처음에는 LLM이 없는 결제 서비스여도 돼. “결제 Agent”라는 이름 때문에 모델을 하나 더 넣을 필요는 없어.

3-2. MCP·A2A·x402는 서로 다른 축이다

A2A 요청 안에 결제 관련 업무 데이터를 넣을 수는 있지만, A2A가 결제 규칙·사용자 승인·환불 정책을 대신 만들어주지는 않아.

3-3. 가장 큰 문제는 ‘두 Agent가 같은 의미로 이해했는가’야

추천 Agent가 이렇게 보냈다고 해보자.

“이 영화 결제해줘. 사용자가 괜찮다고 했어.”

결제 Agent 입장에서는 정보가 부족해.

• 영화 대여인지, 추천 리포트인지?
• 어느 판매처인지?
• 어떤 가격을 승인한 것인지?
• “괜찮다”는 말이 추천 만족인지, 결제 승인인지?
• 승인한 사람이 실제 결제 권한자인지?

그래서 자연어 메시지와 별도로 명확한 업무 데이터 계약이 필요해.

예를 들어 아래는 A2A 표준 필드가 아니라, 네가 설계할 업무 데이터 예시야.

{
  "operation": "execute_approved_purchase",
  "order_id": "order_123",
  "quote_id": "quote_456",
  "approval_id": "approval_789",
  "idempotency_key": "purchase_order_123",
  "schema_version": "1"
}

결제 서비스는 approval_id를 받아 서버에 저장된 승인 기록을 직접 검증해야 해. 추천 Agent가 보낸 "approved": true만 믿으면 안 돼.

사용자 신원과 권한도 인증된 요청 문맥에서 확인해야지, 모델이 만들어낸 user_id를 그대로 신뢰하면 안 돼.

cf)

내가 조종하거나 내 서비스를 총괄하는 '메인 AI(오케스트레이터/주인공 에이전트)'가 있고, 그 AI가 직접 처리하기 어려운 전문적인 일(예: 결제, 외부 데이터 조회 등)이 생겼을 때 다른 역할을 하는 전문 AI 에이전트에게 일을 시키거나 요청(API 호출)을 보내는 구조가 바로 A2A(Agent-to-Agent) 통신입니다.

3-4. 연동 시 주요 문제

영화 ID, A2A Task ID, 주문 ID, 결제 거래 ID는 서로 다른 역할을 해. 하나로 뭉치지 않는 게 좋아.

추천 결과에서 결제로 넘어가는 구조는 이렇게 생각하면 돼.

A2A는 이 그림에서 독립된 추천 Agent와 결제 Agent 사이의 통신 방식으로 선택할 수 있어.

4. Eval과 OpenInference

둘은 함께 쓰지만 목적이 달라.

Eval: 잘했는가?
OpenInference 기반 추적: 어떤 과정을 거쳤는가?

4-1. Eval은 AI 애플리케이션의 평가 체계야

기존 테스트에서는 보통 정답이 명확하지.

assert add(2, 3) == 5

하지만 “따뜻한 영화 3편 추천”에는 유일한 정답이 없어.

그래서 평가를 나눠야 해.

평가에는 규칙 기반 검사, 사람 평가, LLM 평가 등을 조합할 수 있고, 개발 중 고정 데이터셋으로 하는 오프라인 평가와 운영 중 평가를 구분할 수 있어. Docs by LangChain

4-2. 추천 평가를 구체적으로 만드는 방법

처음에는 다음처럼 다양한 요청 20~30개를 직접 만들어봐.

검색 지표도 차근차근 배우면 돼.(아래는 추천 시스템이나 검색 엔진의 성능을 평가할때 쓰는 대표적인 평가지표 3가지 이다.)

• Precision@K: 상위 K개 중 관련 있는 영화의 비율.
• Recall@K: 평가셋에서 관련 있다고 표시한 영화 중 상위 K개에서 찾은 비율.
• NDCG@K: 관련성이 높은 영화가 앞에 배치됐는지 평가.

추천은 관련 영화의 정답 목록을 완벽하게 만들기 어렵기 때문에, 작은 데이터셋에서는 조건 준수율과 사람의 선호 비교부터 시작해도 좋아.

4-3. LLM 평가도 틀릴 수 있다

다른 LLM에게 “추천 잘했는지 채점해줘”라고 하면 편하지만 다음 문제가 있어.

• 긴 설명을 좋은 답변으로 착각.
• 영화에 대한 자체 지식이 틀림.
• 같은 답변의 점수가 달라짐.
• 평가 대상 답변 속 지시문에 영향받음.

따라서 이렇게 분리해.

• 러닝타임·영화 ID·결제 금액: 코드로 검사.
• 취향 적합성·설명 이해도: 구체적인 기준으로 사람 또는 LLM 평가.
• 결제 승인·중복 결제: 결제 상태와 실행 기록으로 검사.

“전체적으로 8점”보다 어떤 조건을 위반했는지가 개선에 더 도움이 돼.

그리고 프롬프트를 개선할 때 사용한 문제와 최종 검증 문제를 일부 분리해야 해. 평가 문제에만 잘 맞추는 상황을 피하려는 거야.

4-4. OpenInference는 실행 기록에 공통 의미를 붙인다

OpenInference는 OpenTelemetry 기반으로 AI 애플리케이션의 실행을 기록하기 위한 의미 규약과 계측 도구를 제공해. 추적 데이터는 호환되는 관측 백엔드로 보낼 수 있어. 자체적으로 추천을 평가하거나 모델을 실행하는 엔진은 아니야. openinference

기본 용어는 두 개부터 알면 돼.

• Trace: 사용자 요청 한 건의 전체 실행 흐름.
• Span: 그 안의 개별 작업 하나.

예를 들어 추천 응답이 8초 걸렸다면 다음을 볼 수 있어.

이 기록을 Eval과 연결하면:

“추천 점수가 낮다” → “검색 후보가 부적절했다” → “임베딩 입력에서 분위기 정보가 빠졌다”

처럼 원인을 좁힐 수 있어.

다만 기록되는 것은 호출·입출력·측정 가능한 실행 정보이지, 모델 내부 생각을 완전히 들여다보는 것이 아니야.

또 개인키·인증 토큰·민감한 사용자 정보는 기록하지 않도록 마스킹해야 해. 결제의 최종 원장은 관측 로그가 아니라 결제 DB와 실제 정산 기록이어야 해.

cf)

OpenInference는 한 마디로 "AI 애플리케이션(LLM, 에이전트 등)의 내부 동작을 투명하게 들여다보기 위한 표준 규격(공통 언어)"입니다.

개발자들이 AI 앱을 만들 때, AI가 왜 이런 답변을 냈는지, 어떤 툴을 호출했고, 어떤 문서를 검색(RAG)했는지 추적(Tracing)하고 모니터링해야 하는데, 이를 통일된 방식으로 기록할 수 있게 만든 오픈소스 표준입니다.

1. 왜 이런 게 필요할까요? (문제점)

• 일반 웹 서버는 에러가 나면 로그가 깔끔하게 남지만, LLM 기반 AI 앱은 속이 너무 복잡합니다.
• 유저가 질문 ➔ 프롬프트 가공 ➔ 벡터 DB 검색(RAG) ➔ LLM 호출 ➔ 툴(Tool) 사용 ➔ 최종 답변의 복잡한 과정을 거치는데, 각 프레임워크(LangChain, LlamaIndex 등)마다 로그를 남기는 방식이 다 달랐습니다.
• 이걸 하나의 공통된 규격으로 깔끔하게 기록할 수 있게 만든 것이 바로 OpenInference입니다.

2. 무엇을 기록하나요? (추적 단위)

오픈소스 표준에 따라 AI가 일하는 과정을 다음과 같은 단위로 쪼개서(Trace/Span) 기록합니다:

• LLM 호출: 모델에 입력된 프롬프트, 토큰 사용량, 출력 결과
• Retriever (검색기): 벡터 DB나 검색 엔진에서 어떤 문서를 찾아왔는지
• Tool (도구): 외부 API나 함수를 어떻게 호출하고 실행했는지
• Agent (에이전트): 자율 에이전트가 어떤 생각의 흐름(Reasoning)으로 단계를 거쳤는지

5. LangGraph: loop, 핵심 철학, LangChain과의 관계

5-1. 핵심 철학은 ‘상태를 가진 실행 흐름을 명시적으로 관리한다’야

Spring에서 요청 하나가 여러 Service를 호출하는 경우를 생각해봐.

Agent는 여기에 다음 상황이 추가돼.

• 검색 결과가 부족해 다시 검색.
• 사용자에게 추가 질문.
• 결제 승인까지 실행 중단.
• 서버 재시작 후 작업 재개.
• 외부 API 실패 후 일부 단계 재시도.

LangGraph는 이런 흐름을 State·Node·Edge로 표현해. 각 Node는 LLM 호출일 수도 있고 일반 Python 함수일 수도 있어. Docs by LangChain

모든 Node에 LLM을 넣는 게 아니야. 숫자 비교, 권한 확인, 결제 상태 전이는 일반 코드가 더 적합해.

5-2. Loop는 모델을 다시 학습시키는 과정이 아니다

Agent loop는 대략 다음과 같아.

모델 호출 → 도구 실행 요청 → 도구 실행 → 결과를 모델에 제공 → 다음 행동 판단.

예를 들어:

1. “90분 이하의 잔잔한 영화”를 검색.
2. 후보가 한 편만 나옴.
3. 표현을 바꿔 추가 검색.
4. 충분한 후보를 찾음.
5. 추천 작성 후 종료.

여기서 모델의 가중치가 바뀌는 게 아니라, 새로 얻은 결과를 문맥에 추가해서 다시 호출하는 것이야.

주의할 점은 Agent가 검색에 실패했다고 사용자의 필수 조건을 멋대로 바꾸면 안 된다는 것이야.

“90분 이하”를 “120분 이하”로 바꾸는 것은 검색 표현 수정이 아니라 사용자 조건 변경이야.

5-3. Loop에는 종료 조건이 있어야 해

처음부터 다음을 명시하는 게 좋아.

• 검색 재시도 최대 횟수.
• 전체 도구 호출 횟수.
• 요청 전체 시간 제한.
• 모델 사용 비용 한도.
• 같은 인자 반복 호출 감지.
• 조건을 만족하지 못했을 때의 종료 응답.

LangGraph의 실행 단계 제한도 활용할 수 있지만, 프레임워크 제한과 업무상 재검색 횟수는 별도로 관리하는 게 이해하기 쉬워.

또 다음 두 재시도는 구분해야 해.

• 기술적 재시도: API 일시 오류 → 같은 요청 재시도.
• 업무적 재시도: 후보 부족 → 검색 표현이나 검색 방법 변경.

결제 요청에서는 기술적 재시도조차 상태 조회와 멱등성 설계가 먼저야.

5-4. State는 대화 기록만 뜻하지 않는다

다음은 설계 예시야.

처음에는 이렇게 단순하게 시작하고, 이후 필드별 타입과 상태값을 구체화하면 돼.

특히 세 가지 저장소를 구분해야 해.

그래프 체크포인트가 결제 원장을 대신하지는 않아.

LangGraph의 persistence는 작업 상태 보존·재개를 지원하고, interrupt는 외부 입력을 기다리는 흐름을 지원해. 재개 과정에서는 Node 일부가 다시 실행될 수 있으므로, 외부 효과가 있는 작업은 재실행을 고려해 설계해야 해. Docs by LangChain

5-5. LangChain과 LangGraph는 경쟁 제품인가?

둘은 역할과 추상화 수준이 달라.

• LangChain: 모델·도구 등 공통 인터페이스와 Agent 구성을 편리하게 제공.
• LangGraph: 실행 상태·분기·반복·중단·재개를 직접 설계하는 실행 기반.

현재 LangChain의 Agent 구성은 LangGraph 기반 실행 기능을 활용해. 따라서 “LangChain은 직선 실행만 되고 LangGraph만 Agent를 만들 수 있다”는 설명은 부정확해. 공식 문서도 LangChain의 Agent 구성과 LangGraph의 저수준 오케스트레이션을 구분하고 있어. Docs by LangChain

함께 활용하는 대표 구성은 다음과 같아.

보통 langchain-core의 공통 추상화와 제공사별 패키지를 함께 쓰지만, LangGraph Node 안에서 모델 제공사의 SDK나 일반 함수를 직접 호출하는 것도 가능해.

6. 이외에 추가로 공부해야 하는 것

네 목록에 다음 내용이 들어가면 실제 구현까지 훨씬 잘 이어져.

특히 “프롬프트에 하지 말라고 써두기”와 “코드로 실행을 막기”는 다르다는 점을 기억하면 좋아.

결제 승인, 권한, 금액 제한은 코드로 강제해야 해.

7. 너에게 권하는 학습·구현 순서

아래는 고정 일정이 아니라, 각 단계의 결과를 확인하고 넘어가는 순서야.

첫 번째 구현 범위는 “영화 데이터 100건 정도에서, 취향과 러닝타임을 반영해 3편을 추천하는 Python 프로그램”으로 잡는 게 좋아.

PyCharm에서 시작하고, 검색 함수·조건 검증·추천 설명을 먼저 연결해. 이후 같은 기능을 LangGraph로 옮기면 왜 State와 loop가 필요한지 직접 체감할 수 있어.

결제는 그다음에 **“유료 영화 분석 리포트 하나를 모의 구매한다”**로 붙이면, 실제 극장 예매 인프라 없이도 승인·x402·A2A·실패 복구를 단계적으로 공부할 수 있어.

펀드는 여러 투자자의 돈을 모아서, 미리 정해 놓은 투자 규칙에 따라 운용하고, 그 결과인 수익과 손실을 투자자들이 나눠 갖는 투자기구야.

그리고 주식투자자에게 가장 먼저 알려주고 싶은 사실이 있어.

ETF도 펀드야. 따라서 ETF에 투자하는 사람은 이미 펀드투자자이기도 해.

1. 펀드를 산다는 건 정확히 무엇을 사는 걸까?

네가 삼성전자 주식을 사면 삼성전자라는 기업의 지분을 갖게 되지.

반면 주식형 펀드를 사면 그 펀드가 보유한 투자자산 전체에 대한 몫을 갖게 돼. 법적 형태에 따라 수익증권이나 주식 등으로 표시되지만, 처음에는 ‘공동 투자 바구니에 대한 내 몫’으로 이해하면 충분해.

예를 들어 100명이 각각 100만 원을 넣었다고 하자.

• 모인 돈: 1억 원
• 펀드가 투자한 자산: 삼성전자, 현대차, 여러 해외주식과 현금
• 네 투자금: 100만 원
• 처음 네 몫: 전체의 1%

그 뒤 투자자들의 추가 가입이나 환매가 없다고 가정해 보자.

돈을 굴리는 사람은 매니저지만, 투자 결과는 네 것이야. 일반적인 투자손실을 매니저가 자기 돈으로 메워주지는 않아.

다만 투자손실과 별개로, 사기·불완전판매·운용 의무 위반 등은 책임 문제가 생길 수 있어.

미국 SEC의 투자자 교육자료도 펀드 지분을 공동 포트폴리오와 그 소득에 대한 투자자의 몫으로 설명해.

2. 펀드매니저에게 정말 돈을 직접 맡기는 걸까?

일반적인 펀드는 매니저 개인 계좌에 돈을 보내는 구조가 아니야. 여러 기관이 역할을 나눠.

세부 구조는 펀드마다 다르지만, 운용과 자산 보관을 분리하는 것이 중요한 원칙이야. 

여기서 흔한 오해 두 가지를 바로잡자.

첫째, 은행에서 가입했다고 예금이 되는 건 아니야.

은행이 판매창구일 뿐, 네 돈은 주식이나 채권 등에 투자될 수 있어. 일반적인 투자펀드는 예금처럼 원금을 보장받는 상품이 아니야.

둘째, 운용회사와 펀드 자체는 구분해야 해.

운용회사의 사업이 어려워졌다는 것과 펀드가 보유한 주식·채권의 가치가 사라졌다는 것은 다른 사건이야. 다만 재산이 별도로 보관된다고 해서 투자손실이나 모든 운영상 위험이 없어지는 것은 아니고.

주식투자와 연결하면 이렇게 생각하면 돼.

증권사에서 주식을 샀다고 그 증권사에 투자한 것이 아닌 것처럼, 특정 운용사의 펀드를 샀다고 그 운용회사 자체에 투자한 것은 아니야.

3. 펀드매니저는 마음대로 투자할 수 있을까?

보통은 못 해. 펀드마다 투자설명서와 규약에 정해진 운용 범위가 있어.

예를 들어 ‘국내 주식에 주로 투자하는 펀드’를 운용한다면, 매니저가 갑자기 미국 부동산에 대부분의 돈을 투자하기는 어려워.

규칙에는 이런 내용이 들어가.

• 어떤 자산에 투자하는가?
• 어느 국가와 업종에 투자하는가?
• 특정 종목에 얼마나 집중할 수 있는가?
• 현금을 어느 정도 보유할 수 있는가?
• 파생상품이나 차입을 사용할 수 있는가?
• 투자자가 언제 돈을 돌려받을 수 있는가?

그래서 이런 일이 생길 수 있어.

“매니저가 주식시장이 떨어질 것 같다고 생각하는데, 왜 주식을 다 팔고 현금으로 안 바꾸지?”

해당 펀드가 주식 비중을 일정 수준 이상 유지해야 하거나, 주식시장에 계속 투자하는 상품으로 설계됐기 때문일 수 있어.

투자자는 그 펀드를 통해 주식시장에 투자하려고 가입했는데, 매니저가 마음대로 현금 상품으로 바꿔버리는 것도 문제겠지.

펀드를 고른다는 것은 사람뿐 아니라 그 사람이 따라야 하는 규칙도 고르는 일이야.

4. 펀드 종류가 헷갈리는 이유: 분류 기준이 서로 다르기 때문이야.

‘주식형 펀드, 사모펀드, 인덱스펀드, ETF, 헤지펀드’가 모두 같은 기준으로 나뉜 이름 같지만, 실제로는 그렇지 않아.

한 펀드는 여러 설명을 동시에 가질 수 있어.

“일반 투자자를 대상으로 모집하고, 미국 주식에 투자하며, 특정 지수를 따라가고, 거래소에서 거래되는 펀드”

이 펀드는 동시에 공모펀드·주식형 펀드·인덱스펀드·ETF인 거야.

‘투자펀드’는 대체로 이런 투자기구를 넓게 부르는 말이고, 헤지펀드와 서로 대등한 하나의 세부 종류라고 생각할 필요는 없어.

5. 무엇에 투자하느냐에 따라 위험이 달라져.

펀드는 일종의 그릇이야. 그릇 안에 무엇을 담았는지가 위험을 크게 결정해.

주식투자자는 여기서 두 가지를 기억하면 좋아.

① 종목 수가 많다고 무조건 안전한 것은 아니야.

반도체 기업 30개에 투자하는 펀드는 한 기업의 사고에는 덜 취약할 수 있어. 하지만 반도체 업황 전체가 꺾이면 함께 떨어질 수 있지.

② 채권형 펀드는 예금이 아니야.

채권가격이 떨어지면 펀드가격도 내려갈 수 있어. 특히 일반적인 채권형 펀드는 채권을 계속 교체하기 때문에, 개별 채권처럼 “내가 정한 만기까지 기다리면 정해진 액면금액을 받는다”는 구조와 달라.

만기매칭형 상품도 있지만, 그 경우에도 원금보장 여부는 별도로 봐야 해.

6. 액티브펀드와 패시브펀드: 매니저의 판단을 살까, 정해진 규칙을 살까?

액티브펀드는 매니저가 종목과 비중을 적극적으로 판단해 운용하는 펀드야.

예를 들면:

“반도체 중에서는 A가 저평가돼 있고, B는 기대가 과하다. A를 더 사고 B는 줄이겠다.”

판단에는 기업 분석, 경기 전망, 밸류에이션, 산업 변화 등이 들어갈 수 있어.

패시브펀드는 정해진 지수 등을 추종하는 데 초점을 맞춰.

예를 들면:

“S&P 500 지수의 움직임을 최대한 가깝게 따라가겠다.”

여기서 인덱스펀드는 특정 지수를 추종하는 펀드야. 지수 구성종목을 모두 보유하거나, 일부를 표본으로 선택하거나, 다른 수단을 활용할 수 있어. 비용과 운용 방식 때문에 지수 수익률과 완전히 같지는 않을 수 있고. 

패시브라고 안전한 것은 아니야.

위험한 시장이나 특정 업종을 추종하면 그 위험을 그대로 갖게 돼.

또한 패시브 운용에도 전문성이 필요해. 지수 변경을 반영하고, 거래비용을 줄이고, 현금과 배당을 관리해야 하거든.

7. 펀드와 ETF는 무엇이 다를까?

정확히 말하면 일반 가입형 펀드와 ETF를 비교하는 것이야. ETF 자체가 펀드니까.

ETF는 Exchange-Traded Fund, 즉 거래소에서 거래되는 펀드야.

일반 펀드는 신청 시점에 최종 적용가격을 확정해서 알지 못하는 경우가 많아. 해외자산에 투자하는 펀드는 기준가격 적용과 대금 지급까지 시간이 더 걸릴 수 있고.

ETF는 장중 시장가격으로 거래하지만, 매도했다고 현금을 즉시 출금할 수 있는지는 별도의 결제 일정에 달려 있어.

여기서 꼭 구분해.

인덱스는 운용 방식이고, ETF는 거래 방식이야.

그래서 인덱스펀드 중 ETF가 아닌 것도 있고, ETF 중 액티브로 운용하는 것도 있어.

8. 기준가격과 NAV: 펀드의 ‘한 몫’은 얼마일까?

주식에 주가가 있듯이, 펀드에는 기준가격이 있어.

먼저 **순자산가치(NAV)**를 이해하자.

순자산가치 = 펀드가 가진 자산의 가치 − 펀드가 부담하는 부채

이걸 투자자들이 가진 전체 몫의 수로 나누면 단위당 가치가 돼.

국내 일반 펀드는 보통 1,000좌당 기준가격을 표시해. ‘좌’는 펀드의 몫을 세는 단위라고 보면 돼.

가령 기준가격이 1,000원인 펀드에 100만 원을 투자하면, 비용을 무시할 때 100만 좌를 취득해.

그 뒤 기준가격이 1,100원이 되면:

기준가격이 900원이 되면 90만 원이고.

기준가격이 낮다고 싼 펀드는 아니야.

펀드 A의 기준가격이 800원이고 B가 2,000원이라고 해서 A가 더 저평가됐다고 볼 수 없어.

설정 시점, 과거 성과, 분배금 지급 등이 다르기 때문이야. 투자 매력은 실제 편입자산과 가격, 전략을 봐야 판단할 수 있어.

또 하나 중요한 점이 있어.

신규 투자자가 들어온다고 기존 투자자의 수익이 자동으로 희석되지는 않아.

예를 들어 순자산이 100억 원인 펀드에 누군가 10억 원을 넣으면, 펀드 자산이 늘어나는 동시에 그에 해당하는 좌수가 새로 생겨. 적정 기준가격으로 처리된다면 기존 투자자의 몫의 가치가 이유 없이 줄어들지는 않아.

다만 실제 운용에서는 자금 유출입에 따른 거래비용 등이 영향을 줄 수 있지.

9. ETF에는 가격이 두 개 있다는 점이 중요해.

ETF에는 크게 두 가지 가격 개념이 있어.

• 순자산가치: 안에 든 자산을 계산한 한 주의 가치
• 시장가격: 거래소에서 실제로 사고파는 가격

가령 ETF 한 주에 해당하는 자산가치가 10,000원인데, 시장에서는 10,200원에 거래될 수 있어.

이 경우 순자산가치보다 2% 비싼 가격이야.

이를 프리미엄, 반대로 더 싸게 거래되는 경우를 디스카운트라고 해. 이 차이를 비율로 나타내는 것이 괴리율이야. ETF 시장가격은 순자산가치보다 높거나 낮을 수 있어.

주식투자자에게 유용한 구분은 다음과 같아.

ETF 가격을 순자산가치에 가깝게 만드는 데에는 대규모 설정·환매를 수행하는 지정참가회사(AP)와 시장의 차익거래가 역할을 해.

다만 해외시장 휴장, 시차, 급변장 등에서는 괴리가 커질 수 있어. 화면에 표시된 순자산가치가 최신 시장 상황을 충분히 반영하지 못할 수도 있으니, 숫자만 보고 무조건 ‘싸다’고 판단하면 안 돼.

10. 공모펀드와 사모펀드: 무엇에 투자하는지보다 돈을 어떻게 모으는지의 차이야.

공모펀드는 일반 대중을 대상으로 투자금을 모집하는 펀드야.

사모펀드는 법이 정한 범위의 제한된 투자자들을 대상으로 사적으로 자금을 모집하는 펀드야. 투자자 자격, 인원, 최소 투자금 등의 조건은 국가와 펀드 유형에 따라 달라.

사모라고 무조건 좋은 펀드도, 무조건 위험한 펀드도 아니야.

공모·사모는 일차적으로 모집 구조의 구분이지, 성적표나 위험등급이 아니거든.

한국은 2021년 제도개편에서 사모펀드 체계를 일반 사모펀드와 기관전용 사모펀드로 재편했어. 예전 자료에 나오는 ‘전문투자형·경영참여형’ 구분과 현재 체계를 혼동하지 않는 게 좋아. 여기서 ‘일반’이라는 단어가 누구나 소액으로 가입할 수 있다는 뜻은 아니야.

11. 헤지펀드란 무엇일까?

헤지펀드는 보통 제한된 투자자에게 돈을 모아, 공매도·레버리지·파생상품 등 다양한 수단과 전략을 활용하는 사적 투자펀드를 말해.

전통적인 주식형 펀드보다 운용의 자유도가 큰 경우가 많아. 다만 ‘헤지펀드’가 전 세계에서 완전히 동일한 법적 상품 유형을 뜻하는 것은 아니야.

이름의 **헤지(Hedge)**는 위험을 줄이거나 상쇄한다는 뜻이야.

그런데 현대의 헤지펀드는 전략이 매우 다양해서, 이름에 헤지가 붙었다고 안전하거나 손실을 방지하는 상품은 아니야. 레버리지는 손익을 확대하고, 환매 제한도 있을 수 있어. 

가장 이해하기 쉬운 롱숏 전략으로 살펴보자.

**롱(Long)**은 주식을 사서 보유하는 것이야. 가격이 오르면 이익이지.

**숏(Short)**은 보통 주식을 빌려서 먼저 판 뒤, 나중에 사서 돌려주는 공매도 포지션이야. 가격이 내리면 이익을 볼 수 있어.

주식 한 주를 빌려 10만 원에 팔고, 나중에 8만 원에 사서 돌려주면 비용 전 2만 원 이익이야. 반대로 13만 원에 사서 돌려주면 3만 원 손실이지.

롱숏펀드는 이런 생각을 할 수 있어.

“반도체 업종 전체의 방향은 모르겠지만, A기업이 B기업보다 잘할 것 같다. A는 사고 B는 공매도하자.”

각각 100만 원어치 포지션을 잡았다고 해보자.

두 번째 줄이 중요해.

주식시장이 내려가도, 산 종목이 공매도한 종목보다 덜 떨어지면 돈을 벌 수 있어.

반대로 세 번째처럼 상대적인 방향을 틀리면 손실이 나.

여기서 15만 원은 포지션 손익이지, 펀드 수익률이 자동으로 15%라는 뜻은 아니야. 펀드가 투입한 자기자본과 담보, 레버리지 구조에 따라 수익률 계산이 달라지고, 공매도 비용과 배당 보전 등의 비용도 있어.

12. 헤지펀드의 전략은 롱숏 하나가 아니야.

대표적인 전략을 개념적으로 보면 다음과 같아.

핵심은 ‘언제 무엇을 맞혀야 돈을 버는가’가 전략마다 다르다는 거야.

또 순노출이 작다고 전체 위험도 작은 것은 아니야.

자기자본 100억 원으로:

• 150억 원어치를 매수하고
• 150억 원어치를 공매도했다면

단순 금액 기준 순노출은 0이지만, 총노출은 300억 원이야.

매수 종목이 10% 떨어지고 공매도 종목이 10% 오르면 각각 15억 원씩, 총 30억 원을 잃을 수 있어.

금액상 매수와 매도가 같아도 시장 민감도까지 완벽하게 상쇄되는 것은 아니고.

‘헤지했다’는 말보다 무엇을 얼마나 상쇄했는지를 봐야 해.

13. 뉴스에 나오는 ‘사모펀드가 회사를 인수했다’는 무슨 뜻일까?

여기서는 용어를 한 번 더 구분해야 해.

• Private Fund: 사적으로 자금을 모집하는 펀드를 넓게 가리킴
• Private Equity Fund: 기업 지분 투자, 기업가치 제고와 회수 등에 초점을 맞추는 펀드

한국 뉴스에서는 기업을 인수하는 PE펀드를 흔히 ‘사모펀드’라고 부르기 때문에, 사모펀드는 모두 기업을 사들이는 것처럼 느껴질 수 있어.

하지만 사모펀드에는 헤지펀드처럼 주식시장에서 다양한 전략을 쓰는 펀드도 있어.

전형적인 기업 인수형 PE펀드는 다음처럼 움직여.

1. 기관투자자 등에게 투자 약정을 받는다.
2. 투자할 기업을 찾는다.
3. 지분을 인수한다.
4. 경영 개선·사업 재편·성장 투자 등을 추진한다.
5. 몇 년 뒤 매각하거나 상장하는 등의 방법으로 투자금을 회수한다.

가령 회사를 인수한 뒤 이익을 늘리고 부채를 줄여 더 높은 가치에 매각하려는 거야.

하지만 수익이 모두 경영 개선에서만 나오는 것은 아니야. 인수 가격, 매각 당시 시장의 평가, 차입 규모 등도 큰 영향을 미쳐. 차입을 활용한 인수는 잘되면 자기자본 수익률을 높이지만, 잘못되면 손실과 재무 부담도 커지고.

PE펀드는 투자 대상의 매각에 시간이 걸려 투자자의 돈이 장기간 묶일 수 있어. 

함께 나오는 용어도 알아두자.

VC, 즉 벤처캐피털 펀드는 초기·성장 단계의 비상장 기업에 투자하는 경우가 많아. 기업 인수형 PE와 달리 소수 지분을 투자하는 경우가 흔하고, 소수의 큰 성공이 여러 실패를 상쇄하는 구조가 나타날 수 있어. 다만 VC와 PE의 범위는 일부 겹치며, PE가 반드시 경영권 인수만 하는 것은 아니야. 

14. 펀드는 언제든 돈을 뺄 수 있을까? ‘유동성’을 꼭 봐야 해.

주식을 거래해 온 사람은 “팔고 싶으면 팔면 되지”라고 생각하기 쉬워.

하지만 펀드에는 환매 조건이 있어.

개방형 펀드는 정해진 조건에 따라 펀드에 환매를 요청할 수 있는 구조야.

폐쇄형 펀드는 원칙적으로 펀드에 중도 환매를 요청할 수 없는 구조야. 다만 거래소에 상장되어 있다면 다른 투자자에게 팔 수 있는 경우가 있어.

여기서 중요한 구분은:

펀드에 돈을 돌려달라고 하는 것과, 내 지분을 다른 사람에게 파는 것은 달라.

확인해야 할 항목은 다음과 같아.

• 환매 신청이 가능한가?
• 신청 마감 시각은 언제인가?
• 어느 날의 기준가격이 적용되는가?
• 실제 지급일까지 얼마나 걸리는가?
• 일정 기간 환매를 제한하는 락업이 있는가?
• 특정 상황에서 환매를 연기하거나 제한할 수 있는가?

왜 이런 조건이 필요할까?

펀드가 건물에 투자했는데 투자자들이 내일 당장 돈을 달라고 하면, 건물을 하루 만에 제값에 팔기는 어렵겠지.

이것이 자산의 유동성과 투자자에게 약속한 환매 유동성 사이의 불일치 문제야.

잘 팔리지 않는 자산에 투자하면서 언제든 돈을 돌려줄 수 있다고 기대하게 만드는 구조는 주의 깊게 봐야 해.

좋은 자산이어도 내가 돈이 필요한 시점에 회수할 수 없으면 내게 맞지 않는 투자일 수 있어.

15. 펀드 비용은 어떻게 빠져나갈까?

펀드 비용은 단순히 “매니저에게 주는 수수료” 하나가 아니야.

모든 펀드에 모든 항목이 있는 것은 아니야.

여기서 수수료와 보수를 구분하면 이해가 쉬워.

• 수수료: 특정 거래나 시점에 발생하는 비용
• 보수: 운용 기간에 걸쳐 지속적으로 발생하는 비용

연 보수가 1%인 펀드라면 일반적으로 펀드재산에서 기간에 걸쳐 비용이 반영돼. 매년 네 통장에서 별도로 1%를 한 번 빼가는 방식이라고만 생각하면 안 돼.

그리고 공시된 기준가격 수익률에는 통상 펀드재산에서 차감된 보수가 이미 반영돼 있어. 그 수익률에서 보수를 다시 빼면 중복 계산이 될 수 있어. 다만 개인에게 부과되는 판매수수료나 세금까지 모두 포함됐는지는 별도로 확인해야 해.

표시된 총보수만으로 모든 비용을 파악하지 못할 수도 있어. 매매비용 등 추가 비용도 투자성과를 줄일 수 있거든.

비용이 장기에 얼마나 차이를 만드는지 단순 계산해 보자.

초기 1,000만 원을 넣고, 운용 자체의 수익률이 매년 7%로 같다고 가정할게. 편의상 비용을 연 수익률에서 차감하면:

약 810만 원 차이가 나.

실제 보수 차감 방식과 수익률 변동은 더 복잡하지만, 매년의 비용 차이가 복리로 누적된다는 원리는 같아.

비싼 펀드가 무조건 나쁘다는 뜻은 아니야. 그 비용을 감당하고도 더 나은 성과나 필요한 위험관리를 제공하는지가 핵심이지.

16. 펀드 이름 뒤의 A, C, e와 성과보수는 어떻게 읽을까?

같은 펀드인데 이름 끝에 A, C, A-e, C-e 같은 표시가 붙을 수 있어. 이것을 클래스라고 해.

주로 같은 투자 포트폴리오를 공유하면서 판매 경로, 가입 자격, 비용 구조가 달라지는 거야.

국내에서 흔히 보이는 방식으로는:

• A 계열: 선취 판매수수료가 있고, 지속 보수는 상대적으로 낮을 수 있음
• C 계열: 선취 판매수수료가 없고, 지속 보수는 상대적으로 높을 수 있음
• e 표시: 온라인 가입용 클래스인 경우가 많음

다만 정확한 내용은 해당 펀드 설명서를 확인해야 해. 표기만으로 모든 상품을 단정하면 안 돼.

단순 예를 들어보자.

• A: 처음 1% + 매년 0.7%
• C: 처음 0% + 매년 1.2%

투자금 변동 등을 무시하면 지속 비용 차이는 연 0.5%포인트니까, 처음 낸 1%를 상쇄하는 데 약 2년이 걸려.

따라서 오래 보유할지, 짧게 보유할지에 따라 유리한 클래스가 달라질 수 있어. 실제 국내 투자설명서도 이런 비용의 교차 시점을 설명하고 있어.

헤지펀드 등에서는 운용보수와 성과보수를 함께 받는 구조가 흔해. 자주 언급되는 ‘2 and 20’은 연 운용보수 2%, 성과보수 20%를 뜻하지만, 모든 펀드가 이 조건은 아니야.

성과보수에서는 다음 두 가지가 중요해.

하이워터마크: 과거 성과보수 산정에 사용된 최고 가치 등을 기준으로, 이미 보수를 받은 성과에 중복해서 보수를 매기지 않도록 하는 장치.

예를 들어 100이 120으로 올라 성과보수를 지급한 뒤 90으로 떨어졌다가 다시 120으로 회복했다고 해보자. 해당 조건이 적용된다면 단순히 이전 고점까지 회복한 부분에 다시 성과보수를 매기는 것을 막는 취지야.

허들레이트: 성과보수를 받을 수 있는 기준 수익률.

다만 기준 초과분에만 보수를 매기는지, 기준을 넘으면 더 넓은 수익에 매기는지 등 계산 방식이 다를 수 있어.

‘성과보수 20%’라는 숫자만 보지 말고 무엇의 20%인지 봐야 해.

17. 펀드에서 돈을 벌면 분배금으로 받는 걸까?

반드시 그렇지는 않아.

펀드 안에서 주가가 오르거나 배당·이자가 들어오면 펀드의 자산가치에 반영돼. 그 돈을 계속 재투자할 수도 있고, 일부를 분배금으로 지급할 수도 있어.

여기서 주식투자자들이 특히 많이 착각해.

“분배금이 많이 나오는 펀드는 그만큼 수익률도 높은 것 아닌가?”

그렇지 않아. 분배금은 지급 방식이고, 수익률은 투자성과야.

네 펀드 평가금액이 100만 원인데 5만 원을 분배했다고 해보자. 다른 변동이 없다면:

• 펀드에 남은 평가금액: 95만 원
• 받은 현금: 5만 원
• 합계: 100만 원

5만 원이 새로 생긴 것이 아니야.

분배금은 자산의 배당·이자뿐 아니라 실현이익이나 자본의 반환 성격을 포함할 수도 있어. 분배금을 지급하면 다른 조건이 같을 때 그만큼 순자산가치가 낮아져. 

한 번의 투자와 중간 분배금만 있는 단순한 경우라면:

예를 들어:

• 처음 100만 원 투자
• 분배금 10만 원 수령
• 남은 펀드 가치 85만 원

이라면 총수익률은 **-5%**야.

분배금을 10% 받았다는 말과 수익률이 10%라는 말은 전혀 달라.

18. 펀드 수익률이 10%면 잘한 것일까? 비교 기준이 있어야 해.

펀드 평가에서 중요한 단어가 벤치마크야. 성과를 판단할 때 비교하는 기준이지.

가령 미국 대형주에 투자하는 펀드가 10% 올랐는데 비교지수는 20% 올랐다면, 이익은 났지만 상대적인 성과는 아쉬울 수 있어.

반대로 시장이 20% 떨어졌는데 펀드는 8%만 떨어졌다면, 절대적으로 손실이지만 상대적으로 방어를 잘했을 수 있지.

다만 벤치마크보다 잘했다고 무조건 투자자에게 적합한 것은 아니야. 네가 감당할 수 없는 손실이었다면 다른 문제니까.

관련 용어도 알아두자.

엄밀한 알파는 단순히 ‘펀드 수익률−지수 수익률’과 항상 같지는 않아. 시장 위험이나 다른 요인에 얼마나 노출됐는지 고려한 개념이야.

예를 들어 시장이 10% 오를 때 20% 올랐다고 해도, 사실상 위험을 두 배로 키운 결과라면 전부를 매니저 실력이라고 볼 수 없겠지.

또 연평균 수익률도 조심해야 해.

첫해 +50%, 둘째 해 -50%면:

• 100만 원 → 150만 원 → 75만 원

수익률의 산술평균은 0%지만, 실제 누적손실은 25%야. 투자성과를 볼 때는 누적수익률과 복리 연환산 수익률을 구분해야 해.

19. 좋은 펀드매니저는 어떻게 구분할까?

최근 1년 수익률 1등이라는 정보만으로는 부족해.

내가 펀드를 평가한다면 다음 순서로 질문할 거야.

① 무엇을 해서 수익을 냈는가?

기업을 잘 골랐는지, 특정 업종이 크게 오른 덕인지, 레버리지 때문인지 구분해야 해.

② 투자 철학이 실제 보유종목과 맞는가?

가치주 펀드라고 했는데 최근 유행하는 고평가 성장주로 가득하다면 설명이 필요하겠지. 반대로 가치주 전략이 잠시 부진하다고 무조건 잘못 운용한 것도 아니고.

③ 같은 사람이 같은 전략으로 낸 성과인가?

10년 성과가 좋아도 현재 매니저가 몇 달 전에 바뀌었다면 그대로 이어질 거라고 보기 어려워.

④ 하락장에서 어떤 일이 있었는가?

연말 수익률이 같아도 중간에 -15%까지 하락한 펀드와 -50%까지 하락한 펀드는 투자자가 겪는 경험이 달라.

⑤ 규모가 전략에 맞는가?

소형주 전략은 운용규모가 너무 커지면 원하는 종목을 사고팔기 어려워질 수 있어. 반대로 너무 작은 펀드는 운영 효율이나 지속성에 문제가 있을 수 있고.

⑥ 비용을 뺀 뒤에도 투자할 이유가 있는가?

운용 전 성과가 훌륭해도 투자자가 받는 결과가 중요하니까.

⑦ 좋은 시기만 골라 보여주는 것은 아닌가?

유리한 출발점의 수익률, 사라진 부진 펀드를 제외한 평균, 실제 운용이 아닌 백테스트를 조심해서 구분해야 해.

특히 백테스트는 과거 자료에 전략을 대입한 결과야. 실제 돈으로 운용하면서 발생하는 매매비용, 시장 충격, 행동상의 어려움까지 그대로 검증한 것은 아니지.

20. 전문가는 왜 개인투자자보다 항상 잘하지 못할까?

펀드매니저는 분석 인력, 데이터, 기업 접촉, 거래 시스템 등의 장점이 있어.

하지만 어려움도 있어.

• 다른 전문투자자들과 경쟁한다.
• 운용 규모가 커서 작은 기회를 활용하기 어렵다.
• 투자자들의 환매 때문에 원치 않는 시점에 팔 수 있다.
• 펀드 규칙 때문에 투자 비중을 자유롭게 바꾸지 못한다.
• 단기 성과평가와 사업상 압박을 받는다.
• 비용을 부담한 뒤에도 성과를 내야 한다.

가령 매니저는 어떤 기업이 싸다고 확신하는데, 투자자들이 대거 환매를 요청할 수 있어.

그러면 주식을 더 사고 싶은 시점에 오히려 팔아서 현금을 마련해야 할 수 있지.

반면 개인투자자는 생활자금과 투자금을 잘 분리했다면 기다릴 수 있어. 다른 투자자의 환매 요청도 없고, 소액이어서 매매하기 쉬운 경우도 많아.

그렇다고 개인이 무조건 유리하다는 뜻은 아니야. 개인은 정보 부족, 과도한 집중, 감정적 매매라는 어려움이 있어.

전문가의 강점과 개인의 강점이 서로 다르기 때문에, 직접투자와 펀드투자를 어떤 역할로 조합할지가 중요해.

21. 주식투자자라면 알아둘 만한 특수 펀드도 있어.

커버드콜 하기전에, 풋옵션과 콜옵션을 알아야한다.

풋옵션은 팔수있는 권리, 콜옵션은 살수 있는 권리이다.

예를들어 삼성전자가 7만원에 콜옵션 1000원 권리를 샀다(3년 뒤 살수있는 권리라고 가정). 옵션의 가격을 옵션 프리미엄이라고 

그러면 3년뒤 삼성전자를 7만원에 살수있는 권리이다. 물론 중간에 포기해도되며, 3년뒤 권리를 실행하지 않아도 된다. 그러면 1000원만 손해를 보는 것이다.

풋옵션은 팔수 있는 권리이다. 삼성전자가 7만원에 풋옵션 1000원 권리를 샀다.(3년뒤 팔수 있는 권리라고 가정).

그러면 3년뒤 삼성전자를 7만원에 팔수 있는 권리이다. 이것 또한 중간에 포기해도 된다.

만약 3년뒤에 삼성전자가 5만원이 갔다면, 삼성전자를 7만원에 팔수 있게된다. 그러면 앉아서 돈을 벌고, 보통 숏포지션이다. 

팩터펀드는 “싸거나, 수익성이 좋거나, 최근 강한 주식을 일정 규칙으로 선별한다”처럼 이해하면 돼. 지수를 활용하더라도 그 지수 자체에 특정 투자 판단이 들어간 것이야. SEC도 비전통적 지수펀드의 구성 규칙과 복잡성을 확인하도록 설명해.

커버드콜은 옵션 프리미엄을 받지만, 그 대신 특정 조건에서 상승 이익이 제한돼. 기초자산 하락 위험은 여전히 상당 부분 남을 수 있어. 따라서 분배금이 많다는 이유만으로 예금 대용처럼 생각하면 안 돼.

레버리지에서는 기간이 중요해.

많은 레버리지 ETF는 장기 누적수익률의 배수가 아니라 일간 수익률의 배수를 목표로 해. 

예를 들어 지수가:

• 첫날 100 → 110: +10%
• 둘째 날 110 → 100: 약 -9.09%

이라면 지수는 제자리야.

하지만 일간 2배 상품은 비용과 오차를 무시해도:

• 100 → 120
• 120 → 약 98.18

이 돼.

횡보·등락 과정에서도 결과가 달라질 수 있는 거야. 반대로 일정한 추세가 이어지면 누적 결과가 단순 배수보다 커지는 경우도 있어. 핵심은 장기 성과가 경로에 의존한다는 점이야.

또 ETF와 비슷하게 거래되는 ETN은 펀드가 아니라 발행회사가 수익률 지급을 약속하는 채무증권이야. 따라서 발행회사 신용위험이라는 차이도 봐야 해.

22. 해외 펀드는 투자 대상과 환율을 함께 봐야 해.

미국 주식 펀드에 투자하는 한국 투자자의 수익은 주가만으로 정해지지 않아.

환헤지를 하지 않고 다른 비용을 무시하면 대략:

미국 주식이 10% 올랐는데 달러의 원화 가치가 10% 떨어졌다면:

미국 주식이 올라도 원화 기준으로는 손실일 수 있어.

반대로 미국 주식이 10% 오르고 달러 가치도 10% 오르면 21% 수익이고.

환헤지형 펀드는 환율 영향을 줄이려는 거래를 해. 다만 헤지 비용이나 손익이 발생하고, 환위험이 완벽하게 제거되지 않을 수도 있어.

국내 상품명의 (H)는 환헤지를 나타내는 경우가 많지만 실제 헤지 대상과 비율은 설명서를 확인해야 해.

또 원화로 거래한다고 환위험이 없는 것은 아니야. 국내 거래소에서 원화로 사는 해외주식 ETF도 환율에 노출될 수 있어.

세금도 펀드 선택의 일부야. 다만 여기서는 특정 세율을 외우기보다 다음을 먼저 구분하는 게 좋아.

• 국내에 설정·상장된 상품인가, 해외 상품인가?
• 어떤 자산에서 발생한 소득인가?
• 매매차익인가, 분배금인가?
• 일반계좌인가, ISA·연금계좌 등인가?

이 조합에 따라 과세 방식과 적용 조건이 달라질 수 있으니, 실제 상품을 고를 때 해당 시점의 세후 수익을 비교해야 해.

23. 펀드를 여러 개 사면 분산투자가 잘된 걸까?

펀드 개수보다 그 안의 자산이 중요해.

예를 들어 네가 다음을 모두 샀다고 해보자.

• 미국 대형주 펀드
• 미국 성장주 펀드
• 글로벌 AI 펀드
• 미국 기술주 펀드
• 별도로 미국 대형 기술주 직접투자

계좌에는 상품이 여러 개지만, 실제로는 같은 기업과 같은 성장 기대에 집중할 수 있어.

가상 예시로:

• A펀드에 100만 원 투자, X기업 비중 10%
• B펀드에 100만 원 투자, X기업 비중 20%
• X기업 직접투자 30만 원

이라면 네 X기업 노출은:

이야.

총투자금 230만 원 중 약 26%가 X기업에 연결돼 있는 셈이지.

그래서 직접투자와 펀드를 함께 보유한다면 펀드 안의 종목까지 합쳐서 내 전체 포트폴리오를 봐야 해.

분산투자는 이름표를 늘리는 일이 아니라, 손실을 일으키는 원인이 얼마나 겹치는지 줄이는 일이야.

24. 펀드는 주식시장 가격에도 영향을 줘.

펀드를 공부하면 투자상품뿐 아니라 주식시장 수급도 이해하기 쉬워져.

첫째, 환매에 따른 매도가 생길 수 있어.

기업의 실적이 그대로여도 펀드 투자자들이 돈을 빼면 매니저가 주식을 팔아야 할 수 있어.

둘째, 지수 변경에 따른 매매가 생길 수 있어.

지수를 추종하는 펀드는 편입·편출과 비중 변경을 반영해야 해. 이런 매매는 기업의 절대적인 저평가·고평가 판단만으로 이뤄지는 것이 아니야.

셋째, 자산배분 때문에 오르는 자산을 팔기도 해.

주식 60%, 채권 40%를 유지하는 펀드에서 주가가 크게 오르면, 비중을 맞추려고 주식을 일부 팔 수 있어. 기업 전망이 나빠졌다고 판단해서 파는 것과 다르지.

넷째, 헤지·차익거래 포지션의 일부일 수 있어.

어떤 기관이 A주식을 샀다는 사실만으로 강한 상승 확신을 가졌다고 단정할 수 없어. 다른 종목을 공매도하거나 선물로 위험을 상쇄한 포지션의 한쪽일 수도 있으니까.

따라서 주식투자자에게 중요한 질문은:

“기관이 샀나?”에 더해 “어떤 전략과 제약 때문에 샀나?”야.

25. 실제 펀드를 볼 때는 이 순서로 읽으면 돼.

상품명이나 최근 수익률부터 보면 눈에 띄는 숫자에 끌리기 쉬워. 나는 다음 순서로 확인하는 편을 권해.

자료도 역할이 달라.

• 간이투자설명서: 핵심 구조와 위험을 먼저 파악
• 투자설명서·규약: 자세한 운용 범위와 조건 확인
• 자산운용보고서: 실제로 어떻게 운용했는지 확인
• 월간 보고서·팩트시트: 최근 비중과 성과 확인
• ETF 상품 페이지: 지수, 보유자산, 비용, 괴리 등 확인

과거 수익률과 편입종목을 볼 때는 반드시 기준일도 확인해야 해. 자료가 뒤늦게 공개되거나 과거 비중을 보여줄 수 있거든.

26. 마지막으로 가상의 펀드 하나를 직접 해석해 보자.

다음 상품을 봤다고 가정하자.

가상 글로벌 AI 성장 주식펀드 C-e
최근 1년 수익률 +35%
총보수 연 1.4%
상위 10개 종목 비중 65%
환헤지 미실시
환매대금 지급까지 수 영업일 소요

처음 보면 “AI에 투자하고 35%나 벌었으니 좋은 펀드네”라고 생각할 수 있어.

하지만 지금까지 배운 내용으로는 이렇게 읽어야 해.

‘글로벌’
여러 나라에 고르게 투자한다는 뜻인지는 실제 국가 비중을 봐야 해. 대부분이 한 나라에 집중될 수도 있어.

‘AI 성장’
AI 산업 성장뿐 아니라 현재 주가에 반영된 기대가 중요해. 산업이 성장해도 너무 비싸게 산 주식은 부진할 수 있어.

‘주식펀드’
시장 하락에 상당 부분 노출될 수 있어. 매니저가 하락을 예상해도 투자 규칙상 주식을 모두 처분하지 않을 수 있고.

‘C-e’
온라인 클래스의 비용 구조를 확인해야 해. 같은 펀드의 다른 가입 가능 클래스와 비교할 필요가 있어.

‘최근 1년 +35%’
비교지수가 +45%였다면 상대성과는 뒤졌어. 반대로 비교지수가 +15%였다면 좋은 성과일 수 있지만, 위험을 얼마나 더 부담했는지 확인해야 해.

‘총보수 1.4%’
최종 투자비용이 이것으로 끝나는지, 다른 비용이 있는지 봐야 해. 표시된 과거 수익률에 이미 반영된 보수를 또 차감하면 안 되고.

‘상위 10개 종목 65%’
종목이 수십 개 있어도 실제 수익률은 몇몇 기업에 크게 좌우될 수 있어.

‘환헤지 미실시’
외화 가치의 상승·하락이 원화 기준 성과에 영향을 줄 수 있어.

‘환매까지 수 영업일’
오늘 보이는 수익률로 즉시 현금화된다고 생각하면 안 돼.

여기에 네가 같은 AI·기술주를 직접 보유하고 있다면, 이 펀드가 새로운 분산투자가 아니라 이미 가진 위험을 더 늘리는 투자일 수도 있어.

이 펀드에 투자할지 판단하려면 결국 이렇게 설명할 수 있어야 해.

“나는 이 펀드가 어떤 자산과 전략으로 돈을 버는지 알고, 어떤 상황에서 손실이 날지 이해하며, 그 비용과 환매 조건을 감수할 이유가 있다.”

1. 채권

1.1. 채권의 의미

채권은 돈을 빌려주고, 약속된 이자와 원금을 받을 수 있는 권리야.

기업이나 국가는 자금이 필요할 때 채권을 발행해서 돈을 빌려.

예를 들어 어떤 기업이 다음과 같이 약속한다고 해보자.

“100만 원을 빌려주면 매년 5만 원씩 이자를 줄게. 3년 뒤에는 원금 100만 원도 갚을게.”

이 약속에 따라 돈을 받을 권리가 채권이야.

• 국가가 발행하면 국채
• 기업이 발행하면 회사채

라고 불러.

여기서 중요한 것은 돈을 갚겠다는 약속이 있다는 것과, 실제로 갚을 능력이 있다는 것은 다르다는 점이야.

채권도 발행자가 이자나 원금을 지급하지 못하면 손실이 발생할 수 있어.

1.2. 주식과 채권의 차이

주식을 사면 기업의 주인인 주주가 되고, 채권을 사면 기업에 돈을 빌려준 채권자가 돼.

예를 들어 기업의 이익이 열 배로 증가했다고 해보자.

주주는 기업가치 상승의 혜택을 크게 받을 수 있지만, 연 5% 회사채 투자자가 갑자기 연 50% 이자를 받는 것은 아니야.

반대로 기업의 실적이 조금 나빠져도 지급 능력이 유지된다면, 채권자는 약속된 이자를 받을 수 있어.

주식은 기업의 성장에 참여하는 투자이고, 채권은 약정된 돈을 받는 구조를 중심으로 하는 투자라고 이해하면 돼.

1.3. 채권의 기본 용어

앞으로 아래 채권을 기본 예시로 사용할게.

각 용어의 의미는 다음과 같아.

액면금액과 매수가격은 반드시 구분해야 해.

액면금액이 100만 원이라고 해서 항상 100만 원에 거래되는 것은 아니야. 시장에서는 90만 원이나 110만 원에도 거래될 수 있어.

1.4. 채권에서 돈을 받는 구조

액면금액 100만 원, 표면금리 연 5%라면 연간 이자는 다음과 같아.

이 채권을 발행 시점에 100만 원에 매수했다면:

총 115만 원을 받지만, 이 중 100만 원은 원금을 돌려받는 것이야.

따라서 이자 재투자를 제외한 이익은 15만 원이야.

1.4.1. 이자를 여러 번 지급하면 수익이 늘어날까?

연 5%라는 조건이 같다면, 지급 횟수가 늘어난다고 약정 연간 이자가 늘어나는 것은 아니야.

연 4회 지급한다고 5%를 네 번 받는 것은 아니야.

다만 이자를 일찍 받아 재투자할 수 있다는 차이는 있어. 실제 지급액은 상품의 날짜 계산 방식에 따라 조금 달라질 수 있고.

1.5. 채권에도 시장가격이 있는 이유

거래 가능한 채권은 만기 전에 다른 사람에게 팔 수 있어.

예를 들어 네가 가진 채권은 다음 돈을 받을 권리야.

“매년 5만 원의 이자를 받고, 만기에 100만 원을 받는 권리.”

갑자기 돈이 필요하다면 이 권리를 다른 투자자에게 팔 수 있지.

그런데 매수자는 무조건 100만 원을 내지 않아. 다음을 비교하거든.

• 다른 투자에서 받을 수 있는 수익률
• 만기까지 남은 기간
• 발행자의 상환 능력
• 필요할 때 다시 팔기 쉬운지

그래서 같은 채권이 서로 다른 가격에 거래될 수 있어.

고정된 것은 약정 현금흐름이고, 시장에서 변하는 것은 그 현금흐름을 살 수 있는 가격이야.

1.6. 표면금리·경상수익률·만기수익률의 차이

채권에서 “금리”와 “수익률”이라는 말이 혼란스러운 이유는 서로 다른 기준으로 계산하기 때문이야.

1.6.1. 표면금리

액면금액 100만 원에 연간 이자가 5만 원이라면:

고정금리 채권에서는 시장가격이 바뀌어도 표면금리는 그대로야.

1.6.2. 경상수익률

같은 채권을 90만 원에 샀다면:

이자를 받는 금액은 같지만, 투자한 돈이 적으므로 투자금 대비 이자수익률이 높아지는 거야.

다만 경상수익률은 만기에 발생하는 차익이나 차손을 반영하지 않아.

1.6.3. 만기수익률

90만 원에 산 채권이 만기에 100만 원을 상환한다면, 이자 외에도 10만 원의 상환 차익이 생겨.

만기수익률은 이러한 차익·차손과 돈을 받는 시점을 반영해.

예를 들어 만기가 정확히 1년 남았고, 1년 뒤 원금과 이자를 합쳐 105만 원을 받는다면:

같은 채권에서도 다음 숫자가 동시에 나타날 수 있어.

이 예시는 개념 차이를 보여주기 위해 가격 차이를 크게 잡은 거야.

만기수익률은 미래 현금흐름을 현재가격과 일치시키는 할인율이야. 이를 만기까지의 복리 누적수익률로 실제 달성하려면 약정 지급이 이루어지고, 중간에 받은 이자도 같은 수익률로 재투자하는 등의 조건이 필요해.

1.7. 시장금리가 오르면 채권 가격이 떨어지는 이유

네가 연 5% 이자를 주는 채권을 가지고 있다고 하자.

그런데 동일한 신용과 만기 조건의 새로운 채권이 연 6% 수익률을 제공하기 시작했어.