1 · 오프닝 — Rule No.151 · Opening — Rule No.15

14강에서 우리는 팀을 만드는 법을 배웠습니다. 그런데 팀을 아무리 잘 굴려도, 그 결과를 그냥 믿어 버리면 어떻게 될까요. 신뢰는 우연히 생기는 게 아니에요. 프로세스로 설계하는 겁니다. 오늘은 룰 넘버 피프틴, "신뢰는 설계하는 것이다"를 가지고, 그 신뢰를 어떻게 설계하는지 이야기해 보겠습니다. 이 강을 마치면, '잘해 보이는 답'과 '맞는 답'을 가르는 검증 장치를 여러분의 업무 흐름에 직접 심을 수 있게 됩니다.Last time we learned how to build a team. But no matter how well you run that team, what happens if you just trust its output? Trust doesn't happen by accident — you design it into a process. Today, under Rule Number Fifteen — "trust is designed, not assumed" — we'll talk about how to design that trust. By the end of this lesson, you'll be able to embed a verification mechanism into your own workflow — one that separates answers that merely look correct from answers that actually are.

2 · 잘해 보이는 답2 · Looks correct

한 장면을 볼게요. 작업이 끝났냐고 물었더니, 에이전트가 아주 자신 있게 "네, 완료했습니다"라고 보고합니다. 그래서 그대로 믿고 가져다 썼어요. 그런데 나중에 보니, 테스트는 한 번도 돌리지 않았고, 근거로 댔던 출처는 아예 존재하지 않았습니다. 분명 잘해 놓은 것처럼 보였는데 말이죠.Let's look at one scene. I asked if the work was done, and the agent confidently reports, "Yes, complete." So I trusted it and shipped it. But later it turns out: the tests never ran once, and the source it cited didn't even exist. And yet it looked perfectly done.

여기서 핵심은요, 이게 모델이 나빠서 생긴 문제가 아니라는 겁니다. 우리가 검증을 설계하지 않아서 생긴 일이에요. 14강에서 검증자를 따로 두자는 데까지 왔잖아요. 그럼 그 검증을 도대체 어떻게 설계해야 할까요. 잘했어 보이는 답과 실제로 맞는 답은 다릅니다. 신뢰는 보고가 아니라, 통과로 증명하는 거예요. 오늘 그 설계를 배웁니다.The key here is this: it's not a problem caused by a bad model. It happened because we didn't design any verification. Last time we got as far as placing a separate verifier. So how exactly do we design that verification? An answer that looks done and an answer that's actually correct are different things. Trust is proven not by a report, but by passing. Today we learn how to design that.

3 · 신뢰할 수 없는 결과 4유형3 · Four types of untrustworthy output

못 믿을 결과는 그냥 무작위로 터지는 게 아니에요. 크게 네 가지 유형으로 나뉩니다. 첫째, 사실 오류와 할루시네이션. 3강에서 배운, 없는 사실을 그럴듯하게 채워 넣는 그 버릇이에요. 둘째, 미검증 완료. "다 했다"고 하는데 정작 검증은 한 번도 안 한 경우입니다. 셋째, 명세 이탈. 시킨 것과 다른 걸 만들어 온 경우고요. 넷째, 자기채점 통과. 만든 자가 자기 결과를 스스로 오케이 하는 경우예요.Untrustworthy output doesn't just blow up at random. It splits into four broad types. First, factual errors and hallucinations — that habit from lesson three of plausibly filling in facts that don't exist. Second, unverified "done" — it says it finished, but the check never actually ran. Third, spec drift — it built something different from what you asked. Fourth, a self-graded pass — the maker okays its own result.

여기서 중요한 건, 유형마다 거르는 방법이 다 다르다는 겁니다. 사실 오류는 팩트체크로, 미검증 완료는 자동 테스트로, 명세 이탈은 명세와 승인 게이트로, 자기채점은 별도 검증자로 거릅니다. 그러니까 유형을 알면, 게이트를 어디에 둬야 할지가 자연스럽게 보여요. 오늘 강의는 사실상 이 표 오른쪽 칸을 어떻게 설계하느냐에 대한 이야기입니다.The important thing is that each type is filtered differently. Factual errors by fact-checking, unverified "done" by automated tests, spec drift by spec and approval gates, and self-grading by a separate verifier. So once you know the type, where to place the gate becomes obvious. Today's talk is essentially about how to design that right-hand column.

4 · 검증 없는 워크플로 vs 검증 루프4 · No-verification workflow vs defect loop

왼쪽 그림을 보세요. 생산만 하고 그냥 멈추는 워크플로우입니다. 만들었으면 그대로 가져다 써요. 이러면 결함이 걸러지지 않고, 그대로 하류로, 그러니까 사용이나 배포 단계로 줄줄 새 나갑니다. 아까 콜드 오픈에서 본 그 장면이 정확히 이거였어요.Look at the left diagram. It's a workflow that produces and just stops. Once it's made, you use it as-is. This way, defects aren't filtered out — they leak straight downstream, into usage or deployment. That cold-open scene from earlier was exactly this.

오른쪽은 다릅니다. 생산하고, 검증하고, 수정하고, 다시 검증하는 루프를 박아 둔 거예요. 핵심은 검증을 딱 한 번 끼우는 게 아니라, 통과할 때까지 도는 루프로 설계한다는 겁니다. 그러면 결함이 하류로 새기 전에, 게이트 앞에서 멈춰요. 신뢰는 점검 한 번으로 생기는 게 아니라, 통과 게이트에서 생깁니다.The right side is different. We've baked in a loop: produce, check, fix, and check again. The key is that we don't insert verification just once — we design it as a loop that runs until it passes. Then defects stop at the gate before they can leak downstream. Trust isn't created by a single inspection — it's created at a pass-gate.

5 · 합격 기준 먼저5 · Pass-bar first

검증을 설계하는 첫걸음은, 무엇이 합격인지를 만들기 전에 먼저 적어 두는 겁니다. 예를 들어볼게요. 상품 상세페이지 초안을 쓰기 전에, '원산지, 인증 번호, 교환·반품 규정이 다 들어갔는가'라는 체크리스트를 먼저 적어 둡니다. 그다음에 초안을 쓰고, 마지막에 그 체크리스트가 채점해요. 순서가 뒤집힌 겁니다.The first step in designing verification is to write down what "pass" means before you create anything. Here's an example. Before drafting a product detail page, write a checklist first: 'does it include the country of origin, certification number, and exchange and return policy?' Then write the draft, and finally the checklist grades it. The order is reversed.

이게 왜 강력하냐면요, 체크리스트는 '그럴듯해 보이는가'로 채점하지 않아요. '전부 들어갔는가, 빠진 항목이 있는가'로만 채점합니다. 객관적인 게이트가 되는 거죠. 핵심은 '만들고 나서 확인'이 아니라, '기준 먼저, 그다음 생산'이에요.Why is this powerful? The checklist doesn't grade by 'does it look plausible.' It grades only by 'are all items included, or is something missing?' It becomes an objective gate. The key is not 'build then check' — it's 'bar first, then produce.'

6 · 자기채점 vs 별도 검증6 · Self-grading vs separate verification

그럼 누가 채점하느냐, 이게 또 결정적입니다. 왼쪽은 자기채점이에요. 만든 자가 자기 결과를 스스로 봅니다. 이러면 자기가 깔아 둔 가정을 그대로 통과시켜 버려요. 자기 편향이 그대로 남는 거죠. 그래서 표면만 훑고, 정작 숨어 있는 결함은 못 잡습니다.So who grades it — this is decisive too. The left is self-grading: the maker looks at its own result. This way it just waves through the assumptions it laid down itself. Its own bias stays intact. So it skims the surface and misses the defects that are actually hidden.

오른쪽은 별도 검증입니다. 다른 에이전트나, 자동 테스트나, 게이트가 봐요. 만든 자의 가정에 오염되지 않은 눈이죠. 그래서 숨은 가정을 끄집어내고, 실제로 통과하는지를 잡아냅니다. 검증의 신뢰도는 누가, 무엇으로 채점하느냐에서 갈립니다. 자기가 자기를 채점하게 두면 안 됩니다.The right is separate verification: another agent, an automated test, or a gate looks at it — eyes not contaminated by the maker's assumptions. So it pulls out the hidden assumptions and catches whether it actually passes. The reliability of verification comes down to who grades it and with what. You can't let it grade itself.

7 · 결함 루프: 생산→검증→수정→재검증7 · Defect loop: produce → check → fix → re-check

자, 오늘 메커니즘의 완성형입니다. 결함 루프라고 부르는 건데요. 만들고, 검증하고, 고치고, 다시 검증합니다. 검증에서 실패가 나오면 그냥 멈추는 게 아니라, 그 결과를 다시 생산자에게 되먹여서 수정하게 하고, 또 검증해요. 이걸 통과 기준을 만족할 때까지 자동으로 반복합니다. 그래서 닫힌 루프라고 부르는 거예요.Alright, today's mechanism peak. We call it the defect loop. Make, check, fix, and check again. When verification produces a failure, it doesn't just stop — it feeds that result back to the producer to fix, and checks again. It repeats this automatically until it satisfies the pass-bar. That's why we call it a closed loop.

여기서 사람의 역할이 완전히 바뀝니다. 회차마다 일일이 눈으로 검수하는 게 아니라, 루프 자체와 통과 기준을 설계하고, 마지막 게이트만 봐요. 신뢰를 한 번의 점검이 아니라, 반복 가능한 루프로 박아 두는 거죠.Here the human's role changes completely. Instead of eyeballing every single round, you design the loop itself and the pass-bar, and watch only the final gate. You bake trust in not as a one-time inspection but as a repeatable loop.

8 · 과대광고 검증 도우미 (리테일)8 · Exaggerated-claims verification helper (retail)

네 가지 유형 중에 사실 오류, 기억나시죠. 이건 전담 검증 도우미를 둬서 거릅니다. 마케팅 문구에 '업계 일 위', '최저가' 같은 주장이 들어갔다면, 이 도우미가 그 주장을 받아서 근거, 그러니까 출처와 날짜를 함께 대게 합니다. 근거를 댈 수 있으면 통과, 못 대면 문구에서 빼게 해요.Of the four types, remember factual errors? We filter those with a dedicated verification helper. If marketing copy contains claims like 'number one in the industry' or 'lowest price,' this helper takes those claims and demands the evidence — a source and a date. If evidence can be provided, it passes. If not, the claim is removed from the copy.

왜 이게 필요하냐고요? 과대광고는 소비자보호법 위반 리스크가 있어요. 문구를 쓴 사람이 스스로 확인하면, 자기가 쓴 내용이니까 그냥 통과시키기 쉽습니다. 별도 도우미가 비판적으로만 보니까, 만든 자의 시각에 오염되지 않고 잡아내는 거예요.Why is this needed? Exaggerated claims carry the risk of violating consumer protection laws. If the person who wrote the copy checks it themselves, it's easy to pass their own work. A separate helper looking purely critically catches what the maker's own perspective would miss.

9 · 승인 게이트: 되돌릴 수 없는 행동 앞9 · Approval gate: before irreversible actions

여기서 중요한 질문이 하나 나와요. 그럼 전부 다 자동으로 돌리면 되는 거 아니야? 아닙니다. 루프가 자동으로 잘 돌다가, 다음 단계가 전체 고객 문자 발송인 순간 딱 멈춥니다. 한번 보내면 되돌릴 수 없으니까, 사람의 승인을 요청하는 거예요. 이걸 승인 게이트라고 합니다.An important question comes up here. Can't we just run everything fully automatically? No. The loop runs nicely on its own, and then the moment the next step is sending an SMS to all customers, it stops dead. Because once it's sent you can't take it back, it requests a human's approval. We call this an approval gate.

어디에 사람을 세우느냐. 되돌릴 수 없는 행동 앞입니다. 전체 고객 문자 발송, 가격 일괄 변경, 대량 삭제처럼 한번 하면 되돌리기 어려운 것들이요. 이런 곳에만 사람 게이트를 박아요. 반대로, 초안 하나 수정하거나 내부 파일을 저장하는 것처럼 되돌릴 수 있는 일까지 매번 사람을 세우면 오히려 마찰만 늘어납니다.Where do you place the human? Right before irreversible actions. Things like sending an SMS to all customers, bulk-changing prices, or mass-deleting records — actions that are hard to undo once done. Gate the human only there. On the flip side, if you stop for a human approval every time you revise a draft or save an internal file, you only add friction.

10 · 품질 = 프로세스 설계10 · Quality = process design

지금까지 본 걸 한 장으로 묶어 볼게요. 품질은 그냥 잘 만든다고 생기는 게 아니라, 프로세스를 설계할 때 생깁니다. 네 가지 요소예요. 첫째, 검증 가능한 정의. 기준을 먼저 적어 두는 거죠. 둘째, 결함 루프. 통과할 때까지 반복하는 겁니다. 셋째, 게이트. 팩트체크와 승인으로 거릅니다. 넷째, 통과 기준. 무엇이 통과인지를 명시하는 거예요. 이 네 가지가 우연한 신뢰를 설계된 신뢰로 바꿉니다.Let me tie everything we've seen onto one page. Quality doesn't come from just building well — it comes when you design the process. There are four elements. First, a verifiable definition: writing the bar first. Second, the defect loop: repeating until it passes. Third, gates: filtering with fact-checks and approval. Fourth, the pass-bar: spelling out what "pass" means. These four turn accidental trust into designed trust.

11 · 신뢰를 설계하기 전 5점검11 · Five checks before you trust

자, 오늘의 핵심 정리입니다. 결과를 믿기 전에, 다섯 가지로 검증을 설계했는지 점검하세요. 첫째, 무엇이 맞음인지 먼저 정의했나? 둘째, 결함 루프를 자동화했나? 셋째, 사실은 전담 검증자가 거르나? 넷째, 되돌릴 수 없는 곳에 승인 게이트를 뒀나? 다섯째, 통과 기준을 프로세스에 박았나? 자기채점은 금지입니다. 신뢰는 좋은 모델에서 오는 게 아니라, 설계된 프로세스에서 옵니다.Alright, today's peak. Before you trust the output, check with these five whether you designed the verification. One: did you define what "correct" is first? Two: did you automate the defect loop? Three: does a dedicated verifier filter the facts? Four: did you gate approval on the irreversible? Five: did you bake the pass-bar into the process? No self-grading. Trust doesn't come from a good model; it comes from a designed process.

12 · 신뢰 설계를 한 줄 행동으로12 · Design trust in one line

다섯 가지를 한 줄로 정리해볼게요. 신뢰는, 맞음을 먼저 정의하고, 결함 루프를 자동화하고, 사실과 승인에 게이트를 박고, 통과 기준을 명시해서, 이걸 프로세스에 박아 반복하는 겁니다. 신뢰를 설계할 줄 알면, 어디에 게이트를 박아야 할지가 자동으로 보입니다.Let me lock the five into one line. Trust is: define correct first, automate the defect loop, place gates on facts and approval, spell out the pass-bar — and bake all of it into a process to repeat. Once you know how to design trust, where to place the gates becomes obvious on its own.

13 · 믿고 쓴다 vs 검증을 설계한다13 · Just trust it vs design the verification

맨 처음 콜드 오픈에서 봤던 그 장면, 잘했어 보여서 그대로 믿었던 거 기억나시죠. 그냥 믿으면, 완료 보고만 보고, 자기가 자기를 채점하게 두고, 결함이 그대로 배포로 새 나갑니다. 반대로 검증을 설계하면 어떻게 될까요. 맞음을 먼저 정의하고, 결함 루프와 게이트를 돌려서, 통과로 증명합니다. 신뢰는 더 똑똑한 결과에서 나오는 게 아니라, 설계된 검증에서 나옵니다.That scene from the very first cold open, where it looked done so we just trusted it — remember? Just trust it, and you see only the "done" report, you let it grade itself, and defects leak straight to deployment. Design the verification instead, and what happens? You define correct first, run the defect loop and the gates, and prove it by passing. Trust doesn't come from a smarter output — it comes from designed verification.

14 · 마무리 — Rule No.1514 · Wrap-up — Rule No.15

오늘 한 단어, 아니 네 단어만 가져가신다면 이겁니다. 정의, 루프, 게이트, 통과. 무엇이 맞음인지 먼저 정의하고, 결함 루프를 돌리고, 위험한 곳에 게이트를 박고, 통과로 증명한다. 첫 시간에 배운 룰 넘버 원, "결과를 믿지 말고 검증하라"가 기억나시나요. 그때는 의심하는 태도였어요. 오늘의 룰 넘버 피프틴은, 그 의심을 매번 손으로 하는 대신 프로세스로 설계한 겁니다. 의심은 태도, 신뢰는 설계예요.If you take one word — no, four words — from today, it's these: define, loop, gate, pass. Define what "correct" is first, run the defect loop, place gates on the dangerous, and prove it by passing. Remember Rule Number One from the first lesson, "don't trust the output"? Back then it was an attitude of doubt. Today's Rule Number Fifteen designs that doubt into a process instead of doing it by hand every time. Doubt is an attitude; trust is a design.

한 가지 더. 여러분이 본 이 강의 자체가, 전담 팩트체커가 모든 주장을 게이트한 결과물입니다. 출처를 못 대는 주장은 반려하고, 흔히 사실로 알려진 반증된 통념까지 게이트로 걸러냈어요. 우리가 오늘 가르친 그대로, 검증을 설계한 겁니다. 다음 시간엔 이 개인 도구가 팀 인프라가 되려면 무엇이 필요한지를 다룹니다. 비용과 거버넌스, 룰 넘버 식스틴입니다.One more thing. This very lesson you watched is the product of a dedicated fact-checker gating every claim. Claims that couldn't cite a source were rejected, and even widely-believed but refuted myths were filtered out at the gate. We designed the verification exactly the way we taught today. Next time we'll cover what it takes for this personal tool to become team infrastructure: cost and governance — Rule Number Sixteen.