똥대

내가 꿈꾸는 태평성대는 백성이 하려고 하는 일을 원만하게 하는 세상이다. -세종대왕-

프롤로그

이 글을 읽는다고 세종대왕처럼 큰일을 해낼 수 있는 건 아니지만, 적어도 그의 시선으로 세상을 다시 한번 바라볼 수 있을 것 같습니다.

Chapter. 01. 왜 사람부터 볼 줄 알아야 하는가

001. 알게 하는 것과 통제하려는 것을 구분해라

세종대왕은 자신이 가진 직위와 힘을 이용해 백성을 다스리려고 하기보다는 백성이 스스로 깨닫기를 원했다.

경험으로 보건대, 허조처럼 상대에게 설명하기보다 눈치껏 하기를 바라는 사람은 자신의 권위가 밀리는 것을 두려워하거나, 타인을 도구로 대하는 사람이 대부분이었다. 반대로 세종대왕처럼 다정히 설명하고 그 이유를 말해주는 사람은 그 사람이 정말 잘 되고, 오랫동안 함께하길 바라는 마음을 가진 사람이 대부분이었다.

다그침은 복종을 만들고, 설명은 판단력을 만든다.

002. 문제를 말하는 사람과 문제를 해결하는 사람을 구분해라

현실의 고통을 지적하는 것은 누구나 할 수 있다. 무엇이 잘못됐는지, 어디에 문제가 있는지 불만을 늘어놓는 것은 어렵지 않다. 그래서 많은 이들이 불평불만을 쉽게 한다. 그런데 이런 불만을 토로하는 이들 중 대다수는 ‘해결책’을 말하라고 하면 아무 말도 하지 못한다.

그래서 우리는 부정적인 것들을 논리적으로 말하는 사람을 믿기보다, 그 해결책을 건네는 사람을 따라야 하고 또 그런 사람이 되어야 한다.

차라리 문제점만 지적하며 가만히 있는 편이 덜 웃음거리가 될 수도 있다. 그러나 세종이 바라보는 시각처럼, 진짜로 성장하는 사람은 그런 것에 머물지 않는다.

003. '누가 예민한가'가 아니라 '무엇이 잘못되었는가'를 보라

다섯 개를 이해하면 회사가 돈을 잘 버는가?와 그 회사의 주식을 지금 얼마에 사고 있는가?를 연결해서 볼 수 있다.

아래에서는 같은 가상회사 A기업을 가지고 계산

① ROE는 ‘주주의 자본으로 이익을 얼마나 잘 냈는가’

ROE는 Return on Equity, 자기자본이익률

ROE = 연간 순이익 ÷ 평균 자기자본 × 100

평균 자기자본은 보통 기초와 기말 자기자본의 평균을 사용해. A기업이라면:

“주주의 자본 100원을 활용해서 1년 동안 순이익 10원을 벌었다”는 뜻.

기업이 자기자본을 얼마나 효율적으로 활용하는지 보는 지표지.

투자에서는 높은 ROE를 꾸준히 유지하는 이유를 살펴보는 게 중요.

제품 경쟁력이 강한지, 높은 가격을 받을 수 있는지, 적은 자본으로 사업을 운영할 수 있는지 등을 보는 것이다.

• ROE 20%가 내 투자수익률 20%를 뜻하지는 않음. ROE의 기준은 회사의 장부상 자기자본이고, 내 수익률은 내가 산 주가와 이후 주가·배당에 달려 있다.
• 이익이 늘지 않아도 ROE가 높아질 수 있다. 자사주 매입 등으로 자기자본이 줄면 분모가 작아지기 때문.
• 부채를 많이 활용한 결과일 수도 있다. 차입을 통해 이익을 늘렸다면 높은 ROE와 함께 이자 부담과 재무 위험도 확인해야 함.

ROE가 오른 이유가 이익 증가인지, 자본 감소인지 확인해야 한다는 뜻

② EPS는 ‘회사 전체의 이익을 주식 1주 기준으로 나눈 값’

EPS는 Earnings Per Share, 주당순이익

EPS = 순이익 ÷ 주식 수

EPS 1,000원이라고 해서 주주에게 현금 1,000원을 준다는 뜻은 아니야.

회사는 이익 중 일부를 배당하고, 나머지를 사업에 재투자할 수 있어. 주주에게 실제로 지급하는 1주당 배당금은 별도의 숫자야.

반대로 자사주 매입으로 유통주식 수가 줄면 회사 전체 이익이 그대로여도 EPS가 높아질 수 있다.

따라서 EPS가 올랐다면 사업 성장과 주식 수 변화의 영향을 나눠서 봐야 함.

또 증권 앱에서 기본 EPS와 희석 EPS가 함께 보일 수 있다.

• 기본 EPS: 현재의 보통주를 기준으로 계산.
• 희석 EPS: 전환사채·주식선택권 등이 주식으로 바뀌어 EPS를 낮추는 효과까지 반영.

주식으로 바뀔 수 있는 권리가 많은 기업이라면 희석 EPS도 확인할 필요가 있다.

그리고 서로 다른 회사의 EPS가 5,000원과 1,000원이라고 해서 앞의 회사가 더 좋은 투자라는 뜻은 아니야. 주가와 주식 수 구조가 다르기 때문. 이익과 가격을 연결하는 지표가 바로 PER

③ PER은 ‘현재 이익에 비해 주가가 얼마나 높은가’

PER은 Price-to-Earnings Ratio, 주가수익비율

PER = 주가 ÷ EPS

“연간 순이익 1원에 대해 시장이 20원의 가격을 붙이고 있다”는 뜻이야.

같은 EPS 1,000원이라면:

이익의 성장성·안정성·위험 등이 같다면, 낮은 PER에 사는 쪽이 같은 이익을 더 저렴하게 사는 셈.

그런데 현실에서는 기업들의 미래가 달라. 어떤 회사는 이익이 빠르게 늘고, 어떤 회사는 줄어들 수 있어.

그래서 PER 10배가 무조건 싸고, 30배가 무조건 비싼 것은 아니다. 같은 업종의 비슷한 기업, 해당 기업의 과거 수준, 앞으로의 이익 전망을 함께 비교해야 한다.

주가가 20,000원으로 똑같아도 이익이 달라지면 이렇게 바뀐다.

이 표가 투자에서 아주 중요하다.

지금 PER이 낮아 보여도 앞으로 이익이 급감하면 싸게 산 게 아닐 수 있다.

반대로 지금 PER이 높아도 이익이 크게 늘면 평가가 달라질 수 있다.

특히 경기순환 기업은 호황 때 이익이 급증해서 PER이 낮아지고, 불황 때 이익이 급감해서 PER이 높아질 수 있다.

그래서 한 해 실적만 보지 않고, 경기 흐름을 거친 평상시 이익 수준을 살펴보기도 한다.

증권 앱에서 PER을 볼 때는 계산 기준도 확인해야함.

예상 PER은 미래를 반영하지만, 그 예상이 틀릴 수 있다는 한계.

적자 기업은 PER이 표시되지 않거나 음수로 나타나기도 하는데, 음수라고 더 저렴하다고 해석하면 안된다. 

참고로 “PER 20배면 원금 회수에 20년”이라는 표현은 단순한 비유.

현재 이익이 계속 유지되고 그 이익을 모두 받을 수 있다는 가정 등이 필요하므로, 실제 투자금 회수 기간을 보장하는 숫자는 아.

④ BPS는 ‘주식 1주에 해당하는 장부상 순자산’

BPS는 Book Value Per Share, 주당순자산

BPS = 보통주 몫의 자기자본 ÷ 보통주 수

회사의 장부상 순자산을 주식 수로 나눴을 때 1주당 10,000원에 해당한다는 뜻

EPS와 비교하면 차이가 더 분명

이익을 벌어서 회사 안에 남기면, 다른 변화가 없는 한 자기자본과 BPS가 증가

예를 들어 앞으로 A기업이:

• 1주당 순이익 1,000원을 벌고,
• 그중 300원을 배당하고,
• 700원을 회사에 남긴다면,

주식 수나 다른 자본 변동이 없다는 가정에서 BPS는 10,000원 → 10,700원이 되는 식

다만 BPS는 현금 잔액도, 주가의 하한선도 아니다.

장부상 자산에는 현금뿐 아니라 공장·재고·매출채권 등이 들어 있다.

실제로 팔거나 회수할 때 장부에 적힌 금액을 그대로 받을 수 있다고 보장할 수는 없다.

따라서 BPS 10,000원이라고 회사가 청산될 때 반드시 10,000원을 받는다는 뜻도 아님

투자할 때는 BPS가 늘고 있는지와 함께 그 순자산이 무엇으로 구성돼 있는지를 봐야 함

회수하기 어려운 매출채권이나 팔리지 않는 재고가 많다면, 장부 숫자만으로 자산의 질을 판단하기 어렵다.

⑤ PBR은 ‘장부상 순자산에 비해 주가가 몇 배인가’

PBR은 Price-to-Book Ratio, 주가순자산비율

PBR = 주가 ÷ BPS

“장부상 순자산 1원에 대해 시장이 2원의 가격을 붙이고 있다”는 뜻

BPS가 10,000원인 기업이라면:

여기서 PBR 1배 미만은 ‘장부보다 싸다’는 뜻이지, 투자 가치보다 반드시 싸다는 뜻은 아니야.

예를 들어 순자산이 100억 원인 회사가 계속 적자를 낸다면 그 순자산은 줄어들 수 있다.

자산을 갖고 있어도 이익을 거의 내지 못한다면 시장이 낮게 평가할 수도 있다.

반대로 순자산을 활용해 높은 이익을 꾸준히 내는 기업은 장부보다 높은 가격에 거래될 수 있다.

그래서 PBR을 볼 때 ROE를 함께 보는 것이 중요. 수익성은 PBR을 설명하는 주요 요인 중 하나.

또 기업의 경쟁력이 장부에 얼마나 잘 반영되는지도 고려.

브랜드나 기술력 등은 장부가치만으로 충분히 설명되지 않을 수 있으므로, 이런 기업은 PBR 하나로 평가하기 어렵다.

따라서 낮은 PBR을 발견했다면 이렇게 질문해보기.

“이 회사는 자산에 비해 저렴한 걸까, 아니면 자산으로 이익을 내지 못해서 낮게 평가받는 걸까?”

다섯 지표를 연결하면, 실적이 좋아져도 주가가 떨어질 수 있는 이유까지 이해할 수 있다.

A기업의 주가 20,000원은 두 방식으로 표현할 수 있다.

• EPS 1,000원 × PER 20배 = 20,000원
• BPS 10,000원 × PBR 2배 = 20,000원

여기서 가상의 변화를 보면

EPS는 50% 증가했지만 주가는 25% 하락했다. 시장이 이익에 붙이는 배수가 절반으로 낮아졌기 때문

이 예시는 “회사가 성장하면 주가도 반드시 오른다”라고 판단하기 어려운 이유를 보여준다.

성장 전망과 함께 내가 지불하는 가격도 중요

또 계산 기준을 맞추면 다음 관계도 이해할 수 있다.

ROE는 소수로 넣어야 하므로 A기업에서는:

가 된다. 실제 공시 ROE는 평균 자기자본을, BPS는 기말 자기자본을 사용하는 등 기준 차이가 있어서 항상 정확히 일치하지는 않는다.

이 관계를 이용하면 아래 두 가상기업을 비교. 자기자본과 주식 수 등의 계산 기준이 같다고 가정

PBR 0.5배인 기업이 현재 이익에 비해서는 더 비싼 상황도 가능해. 물론 최종 투자 판단에는 앞으로의 성장과 위험까지 필요하지만, 지표를 함께 봐야 하는 이유는 분명

실제 종목을 공부할 때는 다음 순서로 확인

1. EPS: 최근 3~5년간 주식 1주당 이익이 늘었는가? 일회성 이익이나 주식 수 변화의 영향은 무엇인가?
2. ROE: 그 이익을 자본 대비 효율적으로 내고 있는가? 부채나 자본 감소로 높아진 것은 아닌가?
3. PER: 이익의 성장성과 안정성을 고려할 때 현재 가격은 어떤 수준인가?
4. BPS: 순자산은 늘고 있는가? 그 자산의 실제 가치와 회수 가능성은 어떤가?
5. PBR: 자산으로 만들어내는 수익성을 고려할 때, 장부 대비 할인이나 프리미엄에 이유가 있는가?

멀티모달·사용자 인터페이스·모델 성능의 발전과 앞으로도 유효한 프롬프트 설계 원칙을 설명

멀티모달은 모델이 텍스트뿐 아니라 이미지와 영상도 활용하는 방향이

이미지·영상은 텍스트만으로 전달하기 어려운 정보를 제공하고, 공간 관계·사회적 신호·물리적 상식 등을 학습하는 데 도움이 될 수 있어. 학습 데이터의 범위를 넓힌다는 의미도 있어.

프롬프트를 설계할 때는 기존 원칙을 그대로 적용해.

• 현재 작업과 관련 있는 이미지·영상만 제공하기.
• 이미지가 어떤 역할을 하는지 주변 텍스트로 설명하기.
• 새로운 표현 방식보다 모델에게 익숙한 도표·문서 형식을 활용하기.

사용자 인터페이스는 대화를 통해 하나의 작업물을 계속 수정하는 방향으로 발전해.

책에서 말하는 **‘상태를 가진 대화 대상’**은 문서·코드·그림처럼 대화 중에 변경되면서도 동일한 작업물로 관리되는 대상을 뜻해. 초기 Claude의 Artifacts를 그 사례로 소개해.

앞으로 개선할 방향은 다음과 같아.

• 전체를 다시 생성하지 않고 필요한 부분만 수정하기.
• 여러 작업물과 버전을 명확하게 구분하고 지칭하기.
• 사용자가 직접 수정한 내용도 모델이 인식하도록 반영하기.
• 사용자가 진행 상황을 보고 잘못된 방향을 일찍 바로잡을 수 있게 하기.

모델의 발전은 성능 향상뿐 아니라 비용과 속도의 개선도 포함해.

벤치마크 점수가 높아진 이유는 실제 능력 향상일 수도 있지만, 시험 문제가 학습 데이터에 섞였기 때문일 수도 있어. 따라서 평가 방식도 계속 발전해야 한다고 설명해.

또한 모델이 좋아져도 문제 해결에 필요한 정보가 주어지지 않으면 제대로 해결하기 어렵다는 한계는 남아 있어.

책 전체에서 강조하는 프롬프트 설계 원칙은 ‘익숙한 패턴 활용’과 ‘모델의 관점에서 입력 설계하기’야.

책은 LLM이 입력 맥락과 학습한 패턴을 바탕으로 다음 내용을 생성한다고 설명해. 따라서 마크다운이나 표준 문서 형식처럼 익숙한 구조를 활용하고, 모델이 무엇을 보고 어떻게 해석할지 고려해야 해

GitHub Copilot 팀은 프롬프트나 UI보다 평가 코드를 먼저 작성했어. 이를 통해 변경 사항이 성능 개선인지, 악화인지, 별다른 영향이 없는지 확인하면서 빠르게 개발할 수 있었어.

적절한 평가방식은 상황에 따라 달라진다.

- 애플리케이션이 무엇인지

- 애플리케이션 생애 주기상에서 프로젝트가 어디에 위치하는지 등등

크게 온라인, 오프라인 평가로 나뉜다.

1. 오프라인 평가 - 실제 운영중인 애플리케이션과 독립적인 예제 사례로 평가

-> 하지만 실제와 동떨어진 이론이다.

2. 온라인 평가 - 실제 테스트 해볼 수 있기에 오프라인 평가에 비해 위험요소도 크다.

-> UX는 잘되어 있어야한다. 유의미한 사용자 수도 확보해야 피드백이 정확하다.

10.1 LLM 애플리케이션 평가

평가는 다음 3가지 측면에서 진단한다.

1. 사용하는 모델 자체

2. 모델과의 개별 상호작용(즉, 프롬프트)

3. 이러한 여러 상호작용이 전체 애플리케이션 속에서 어떻게 조화를 이루는지.

-> 전체 상호작용 테스트(회귀 테스트), 구성단위를 테스트(단위 테스트)

처음에는 전체 실행 루프를 최대한 포함하는 테스트를 만들고, 이후 어렵거나 중요한 상호작용에 단위 테스트를 추가하면 된다. 최종 목표는 전체 시스템의 성능을 높이는 것이기 때문

10.2 오프라인 평가

오프라인 평가 모음은 복잡도의 범위가 매우 광범위.

10.2.1 예제 모음

예제 스위트는 여러 입력 예시를 모아, 프롬프트를 바꿀 때마다 결과를 비교하는 구성. 다음 세 가지로 이루어짐.

1. 입력 예시 5~20개: 실제로 발생할 만한 다양한 상황을 준비해.
2. 실행 스크립트: 각 예시에 대해 프롬프트를 생성하고 모델을 호출한 뒤, 프롬프트와 답변을 파일로 저장해.
3. 결과 비교 방법: git diff 같은 도구로 변경 전후의 차이를 사람이 확인해.

다만 사람이 매번 읽을 수 있는 예제 수에는 한계가 있어. 미묘한 성능 차이를 확인하려면 수백~수천 개의 예제가 필요할 수 있으므로, 평가 규모를 키우려면 두 가지를 해결해야 해.

• 예제를 어디서 충분히 확보할 것인가?
• 결과의 품질을 어떻게 자동으로 평가할 것인가?

여러 차례 대화하는 앱에서는 앞선 답변이 다음 단계에 영향을 주기 때문에, 다음 두 방식으로 평가할 수 있어.

10.2.2 샘플 찾기

 **“평가용 샘플은 기존 자료, 실제 사용 기록, 직접 생성한 데이터에서 확보할 수 있으며, 각각의 현실성과 편향을 고려해야 한다”**는 거야.

기존 자료를 활용할 때는 ‘충분한 양’과 ‘실제 문제와의 유사성’ 사이의 균형이 중요해.

Copilot은 사용자가 다음에 입력하려는 코드에 대한 데이터가 부족했기 때문에, 기존 코드를 변형해서 평가 문제를 만들었어.

1. 오픈 소스 코드에서 함수를 선택해.
2. 함수 본문을 지워, 사용자가 구현을 앞둔 상황을 만들어.
3. Copilot이 빈 부분을 완성하도록 해.

실제 자동완성보다 작성할 코드가 길고, 필요한 import가 이미 들어 있는 등 현실과 차이는 있었어. 하지만 방대한 평가 샘플을 확보할 수 있다는 장점이 있었지.

실제 사용 기록에서는 ‘좋은 입력’과 ‘믿을 만한 정답’을 구분해야 해. 사용자의 질문은 좋은 평가 문제가 되지만, 사용자의 최종 행동은 앱의 제안에 영향을 받았을 수 있으므로 정답으로 단정할 수 없어. 또한 기록 수집에는 사용자 동의와 데이터 보호가 필요해. 기준 정답 없이 평가할 수 있는 방식에서는 이러한 입력 기록을 유용하게 활용할 수 있어.

LLM으로 샘플을 생성할 때는 주제를 먼저 나누고, 그 안에서 예제를 만드는 계층적 접근이 좋아.

• 주제·조건 구성: 여러 측면의 선택지를 조합해서 다양한 상황을 만들어. 선택지가 각각 \(n, m, l, k\)개라면 \(n \times m \times l \times k\)개의 조합이 가능해.
• 주제별 샘플 생성: 각 주제에서 여러 예제를 생성해. 책에서는 같은 요청을 반복하는 것보다, 한 번에 여러 예제를 요청하는 편이 더 다양한 결과를 얻을 수 있다고 설명해.
• 해결책에서 역으로 생성: 가능한 경우에는 먼저 해결책을 정하고, 그 해결책에 대응하는 문제를 만들 수도 있어.

특히 평가받는 모델과 샘플을 만드는 모델이 같으면 평가가 편향될 수 있어. 모델 A가 만든 샘플만으로 A와 B를 비교하면, A에 유리한 평가가 될 가능성이 있다는 거야.

10.2.3 답안 평가

핵심은 **“생성된 답변의 품질은 기준 정답과의 비교, 실제 기능 검증, LLM의 판단이라는 세 가지 방식으로 평가할 수 있다”**는 거야.

10.2.4 SOMA 평가

핵심은 **“LLM에게 막연히 ‘좋은 답인가?’라고 묻지 말고, 평가 질문·점수 기준·평가 측면을 구체적으로 정하라”**는 거야. 이를 위한 방식이 SOMA 평가야.

구체적인 질문은 평가할 대상을 좁혀 줘. “이 답변이 맞는가?”라고만 물으면 모델이 어떤 때는 온도를, 어떤 때는 도구 선택을, 어떤 때는 사용자 허락 여부를 평가할 수 있어. 평가 항목을 명시해야 매번 같은 관점으로 비교하기 쉬워져.

서수 척도는 단순한 예/아니오보다 정도의 차이를 표현할 수 있어. 다만 “1~5점으로 평가해”만으로는 부족하고, 각 점수의 의미를 정해야 해. 책의 효과성 평가 기준은 다음과 같아.

평가 측면을 나눌 때는 ‘의도’와 ‘실행’을 구분하는 것이 유용해.

• 의도: 선택한 행동이 사용자의 문제에 적합한 해결책인가?
• 실행: 그 행동을 올바른 도구와 호출 형식으로 구현했는가?

일반적인 답변에서는 **관련성·진실성·완전성(RTC)**으로 나눌 수도 있어. 각각 질문에 맞는 내용인지, 사실이 정확한지, 필요한 내용을 빠짐없이 제공했는지를 평가하는 거야.

또한 “딱 적당한가?”처럼 두 판단이 섞인 질문은 분리해야 해. 예를 들어 “도움이 충분했는가?”와 “불필요하게 개입하지 않았는가?”를 따로 물으면 더 명확해져.

평가 프롬프트에서는 평가 목적과 질문, 점수별 기준을 먼저 제시하고, 그다음 평가할 답변을 제공하라고 권장해.

하지만 SOMA 형식을 갖췄다고 평가의 타당성이 보장되지는 않아. 실제로 잘 평가하는지는 사람의 판단과 비교해야 해.

1. 여러 사람이 동일한 사례를 평가해.
2. 사람들 사이에서도 어느 정도 의견이 갈리는지 확인해.
3. 평가 LLM을 포함했을 때 불일치가 크게 늘어나는지 확인해.

즉, 한 사람의 점수와 완전히 일치하는지를 보기보다 사람들 사이의 의견 차이를 고려해도 LLM의 평가를 받아들일 만한지 확인하는 거야.

본문 마지막에서는 오프라인 평가를 구성할 때 다음 조건을 확인하라고 정리해.

10.3 온라인 평가

10.3.1 A/B 테스트

A/B 테스트는 실제 사용자를 나누어 기존 버전과 수정 버전을 비교하는 온라인 평가야. 중요한 것은 실험 전에 “어떤 지표가 좋아지면 개선이라고 볼 것인가?”를 정하는 것이야.

진행 과정은 다음과 같아.

1. 오프라인 평가로 후보 선별: 효과가 없거나 사용자 경험을 크게 해칠 가능성이 있는 변경안을 미리 걸러.
2. 지표 설정: 높이고 싶은 지표뿐 아니라, 악화되면 안 되는 지표도 정해. 예를 들어 수락률은 높이되 오류·불만은 늘어나지 않아야 해.
3. 무작위로 그룹 배정: 일부 사용자에게 A, 나머지에게 B를 제공해. 앱은 실험 플래그에 따라 두 가지 로직을 실행할 수 있어야 해.
4. 일정 기간 결과 수집·비교: 미리 정한 지표를 기준으로 어떤 버전이 더 좋은지 판단해.
5. 효과가 확인된 버전 적용: 더 나은 대안을 전체 사용자에게 배포해.

온라인 평가는 사용자 수가 제한적이고 피드백 수집과 배포에도 시간이 걸리므로, 오프라인 평가보다 시도할 아이디어를 신중하게 선택해야 해.

10.3.2 평가 지표

평가에 사용할 지표는 크게 다섯 가지야.

**수용도와 영향도의 차이는 ‘받아들였는가’와 ‘최종 결과에 이어졌는가’**야. 추천 링크를 클릭한 것과, 실제로 구매까지 이어진 것은 다른 수준의 신호인 거지.

직접 피드백도 받는 시점에 따라 가치가 달라져. 여행 추천을 받은 직후의 만족도보다 여행을 다녀온 뒤의 평가가 실제 도움을 판단하는 데 더 유용할 수 있어. 이렇게 수집한 피드백은 평가뿐 아니라 모델의 학습 데이터로도 활용할 수 있어.

부수적 지표는 특히 해석에 주의해야 해. 대화가 짧아진 이유가 빠른 문제 해결일 수도 있고, 사용자가 실망해서 떠난 것일 수도 있어. 따라서 단독으로 성공을 판단하기보다 다른 지표와 함께 보고, 예상치 못한 변화의 원인을 조사하는 데 활용해.

책에서는 우선 수용도·영향도 지표를 검토하고, 이것만으로 품질을 판단하기 어렵다면 직접 피드백을 요청하라고 권장해. 이와 함께 기능적 정확성, 지연 시간, 오류도 수집해서 다른 부분이 악화되지 않는지 확인하는 거야.

10.4 요약

앱마다 적합한 평가 방식은 다르지만, 지속적인 개선을 위해 평가는 필수적

샘플 출처, 결과 검증 방법, 사용자 반응 지표를 앱의 특성에 맞게 선택해야 해. 평가 체계에 투자한 시간은 이후의 변경이 실제 개선인지 판단할 수 있게 해 준다는 점에서 가치가 있어.

2026.10.08 - [독서] - 크리스토퍼 브라운 <가치투자의 비밀>

<당신은 투자해야 한다>

가치투자가 장기적으로 탁월한 수익을 선사한다는 확실한 증거가 수없이 많음에도 불구하고 가치투자의 원칙을 따르는 사람은 매우 드물다.

저평가된 좋은 주식을 찾는 것은 좋은 품질의 물건을 가능한 한 싼 가격으로 사는 쇼핑과 같다.

1장. 가치투자의 기본 원칙

1. 주식투자도 쇼핑하듯 하라

또 주식시장이 전반적으로 크게 오를 때는 덩달아 주식투자에 동참하고, 주가가 급락해 사람들이 주식시장에서 도망칠 때는 함께 빠져나오려고 한다. 투자자들이 이러한 행동을 보이는 이유는 홀로 남겨지는 것이 두렵기 때문이다. 

주식시장에서 소외당해 할인 판매 중인 주식을 가치주라고 한다. 반면 주식시장에서 화제를 모으며 인기를 끄는 주식은 대개 성장주다. 

다시 한번 강조하지만 쇠고기나 청바지나 자동차는 세일할 때 사는 것이 경제적이다. 마찬가지로 주식도 할인할 때 사는 것이 합리적이다. 할인 중인 주식은 더 높은 수익을 선사해준다. 주식투자에 성공하려면 싸게 사라!

2. 할인 판매 중인 주식은 어떻게 알 수 있을까?

어떤 주식이 싼지 비싼지 판단할 수 있는 기준은 무엇일까? 바로 기업의 내재가치다.

내재가치가 중요한 이유는 높은 수익을 얻을 수 있게 해주고 고평가된 주식을 사서 손해 볼 위험을 줄여주기 때문이다.

3. 절대로 손해 보지 마라 - 투자의 안전거리를 지켜라

4. 주가가 이익에 비해 싼 주식을 사라 - 저 PER가 고 수익을 낳는다.

5. 기업이 가진 자산보다 더 싼 주식을 사라 - 위험 없는 최고의 투자 기회를 잡는 방법이다.

2장. 황금 같은 가치주를 찾아라

6. 우당탕 떨어지는 주식 - 주가 하락은 양날의 칼이다 (나쁜 점이 있으면 좋은 점도 있다)

7. 기업 내부자가 살 때 따라 사라 - 기업을 그들만큼 잘 아는 사람들도 없다

8. 찾으라, 그러면 구할 것이요 - 할인 중인 주식을 어떻게 찾을까?

9. 싼 게 비지떡'인 주식도 있다 - 주가가 왜 싼지 살펴보라

10. 기업 건강검진 Ⅰ - 투자 실수를 피하려면 기업의 기초체력을 점검하라

11. 기업 건강검진 Ⅱ - 기업의 기초체력이 괜찮다면 얼마나 이익을 내고 있는지 살펴보라

12. 기업 건강검진 Ⅲ - 16가지 질문을 통해 기업의 미래를 가늠하라

경영진이 애널리스트들의 이익 전망치를 편안하게 받아들이지 않는다면, 이익 전망치가 너무 높거나 낮다고 생각한다는 뜻이다.

3장. 해외로 눈을 돌려라

13. 해외로 눈을 돌리면 기회가 두 배로 늘어난다 - 해외 투자는 위험을 분산시킨다

투자 전문가들과 자산관리 전문가들 대부분이 투자의 기회를 넓히고 위험을 분산시키기 위해 다른 나라 주식시장으로 투자 자산을 다각화하라고 권한다.

14. 로마에 가면 로마법을 따르라 - 해외 주식에 투자하려면 외국의 회계기준을 이해하라

이처럼 외국의 회계기준이 다를 수 있다는 사실을 알고 그 차이를 이해하면 믿을 수 없을 만큼 좋은 투자기회가 열린다.

미국 기업들은 가능한 한 실적을 높게 평가해 주주들에게 보고하려고 한다. 실적에 따라 경영진에게 지급하는 보너스와 스톡옵션이 결정되기 때문이다.

15. 해외 투자의 또 다른 변수, 환율 - 환율로 차익을 얻으려는 생각은 버려라

외국 주식에 투자할 때 굳이 환 헤지를 할 필요가 없다고 생각하는 사람들도 있다.

환율변화를 예측하며 환 차익을 노렸던 투자자들은 계속 헤지를 하거나 계속 헤지를 하지 않은 투자자들에 비해 오히려 수익률이 저조했다.

16. 선진국에 투자하라 - 절대 손해 보지 말라는 원칙은 해외 투자에서도 유효하다

돈을 잃어도 크게 개의치 않는다는 심정으로 게임을 즐기듯 투자해야 한다.

4장. 시장에서 승리하는 법

17. 투자는 단거리 달리기가 아니라 마라톤이다 - 중요한 것은 등락의 타이밍이 아니다. 항상 주식시장에 머물러 있어야 한다

주식투자에서 이기기 위해서는 게임이 벌어지고 있는 시장에 항상 머물러 있어야 한다.

주가를 여러 곳에서 너무나 쉽게 확인할 수 있게 되면서 주식투자에서 장기적인 관점을 유지하기는 더욱 어려워지고 있다.

옆집 마당이 지저분하다는 이유로 당신의 집 가격이 2% 떨어졌다면 더 떨어질까 두려워 당장 집을 팔고 이사할 것이다?

가격이란 오르기도 하고 떨어지기도 한다. 중요한 점은 시장이 올라갈 때 좋은 주식을 보유하고 있어야 한다는 것이다.

18. 매수 후 보유? 정말? - 주식과 채권, 어디에 투자할 것인가?

재무 설계에서 가장 표준적인 자산 배분 구성은 3분의 1은 채권에, 3분의 2는 주식에 투자하라는 것이다.

이는 채권에 투자하거나 돈을 예금계좌에 넣어둘 경우 물가 상승분을 제외한 실질 수익률이 오히려 마이너스일 가능성이 50%가 넘는다는 얘기다.

위대한 예측력을 지닌 사람으로 인정받는 것은 기분 좋은일이지만 나는 주식시장의 앞날을 맞출 능력이 없다.

단기 채권에 3년간의 생활비를 넣어두는 이유는 주식시장이 하락한 뒤 이전 고점을 회복하는 데 3년 이상 걸릴 수 있기 때문이다.

회전율 이 낮은 펀드는 대개 성장 잠재력이 높은 주식을 합리적인 가격에 산다.

19. 오직 전문가만이 할 수 있다면? - 펀드매니저를 어떻게 선택할 것인가?

다른 펀드나 주식시장 대표지수를 염두에 둔다면 차라리 인덱스 펀드에 투자하는 것이 낫다.

최소한 5년은 꾸준히 운영되어온 펀드여야 한다. 과거에 수익률 변화가 얼마나 심했는지 살펴보는 것도 좋다.

펀드투자로 성공하는 비결은 처음에 좋은 펀드매니저를 선택해 그와 오랫동안 거래하는 것이다. 수익률이 좀 저도하다고 금세 환매하고 다른펀드로 갈아탄다면 장기적으로 좋은 투자 결과를 기대하기 어렵다.

20. 짜릿한 롤러코스터의 유혹을 뿌리친다 - 원칙을 고수하는 용기를 가져라

가치투자는 간단하다. 가치투자에는 뛰어난 두뇌가 필요하지 않다.

가장 성공한 투자자 또는 펀드매니저가 되는 기회를 놓쳐버리는 원인은 IQ 때문이 아니라 기질과 심리 때문이다.

지나친 자신감도 가치투자를 하는 데 걸림돌로 작용한다. 투자자들이 기다리지 못하고 주식을 자주 샀다 팔았다 하는 이유는 다른 주식으로 갈아타면 더 높은 수익을 올릴 수 있다고 자신하기 때문이다.

대부분 펀드매니저들이 적극적으로 주식을 사고 팔며 자산을 운용하지만 전체 펀드매니저의 단지 15%만이 장기적으로 주식시장의 대표지수보다 높은 수익률을 올린다.

주식시장이 오를 때는 많은 투자자들이 오르는 시장을 이기기 위해 대담하게 행동하고, 주식시장이 떨어질 때는 투자자산을 보존하기 위해 시장에서 탈출하려고 한다.

21. 세월이 흐르면 방법도 변한다 - 그러나 원칙은 변하지 않는다

가치주를 고르는 방법과 기준은 세월이 흐르면서 변해왔다. 앞으로도 시대의 변화와 더불어 진화해 나갈 것이다. 중요한 것은 가치투자의 원칙 그 자체는 변함이 없다는 것이다.

떄로는 가치투자의 기준을 조금 완하해서 당분간 계속 오를 것 같은 최고의 인기 주식을 뒤따라 사고 싶은 유혹도 느낄 것이다.

그러나 기억하라. 가치투자자들이 항복을 선언하고 오르고 있는 주식시장을 뒤늦게 쫓아가고 싶은 유혹을 느낄 때, 그때가 바로 뜨거운 주식시장이 얼음처럼 차가워지기 시작하는 때다.

내가 아는 단 한 가지는 가치투자 기준에 따라 안전마진이 확보된 싼 주식을 여러개 사서 분산 투자하는 것이 가장 건전한 투자전략이라는 사실이다.

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가 엉뚱한 문서를 참고하고 있으면 사용자가 해당 문서를 닫아서 대화가 딴길로 새는 걸 막을 수 있습니다.