교육 영상 · 셀프 재생Learning video · self-running

RULE No.14

멀티에이전트 & 하네스 · 혼자 쓰지 말고 팀을 만들어라 · 시작을 누르면 음성과 함께 슬라이드가 자동 재생됩니다. Multi-agents & Harness · don't work solo, build a team · Press start and slides advance with narration.

1·2 언어 전환 · ← → 수동 이동 · Space 재생/정지1·2 language · ← → navigate · Space play/pause
멀티에이전트 & 하네스 · No.14
01 / 14 목차Index
  이동 · F 전체화면 · RULE №14 · BUILD A TEAM   navigate · F fullscreen · RULE №14 · BUILD A TEAM Privacy[email protected]
일시정지Paused
0 / 0
Home
4부 자동화 & 품질 · 신뢰는 설계한다Phase 4 · trust is designed

RULE No.15

신뢰는 설계하는
것이다.
Trust is designed,
not assumed.

팀을 잘 굴려도, 결과를 그냥 믿으면 위험하다. 신뢰는 우연이 아니라 — 프로세스로 설계하는 것. 오늘은 그 신뢰를 어떻게 설계하는지 다룬다. Even with a great team — just trusting the output is risky. Trust isn't luck — it's something you design into a process. Today: how to design that trust.

As of 2026-06 · 모델은 좋아져도 '검증을 설계한다'는 원리는 같습니다. [추론]As of 2026-06 · models improve but the principle 'design the verification' stays. [inference]

신뢰 · TRUSTTRUST
1막 — 잘해 보이는 답 ≠ 맞는 답Act 1 — Looks right ≠ is right

'잘했어 보이는 답'을, 그대로 믿었다.It looked done — so we shipped it.

> 작업 끝났어?
네, 완료했습니다 ✓

… 그런데 테스트는 안 돌렸고
… 출처는 존재하지 않았다  ← 나중에 드러남

그대로 믿고 가져다 썼다
> is the work done?
Yes, complete ✓

… but the tests never ran
… the source didn't exist  ← surfaced later

trusted it and shipped it

모델이 나빠서가 아니다 — 검증을 설계하지 않아서.Not because the model is bad — because verification wasn't designed.

[추론] '완료 보고'와 '실제 통과'는 다르다. 신뢰는 보고가 아니라 통과로 증명한다.[inference] A "done" report and an actual pass are different. Trust is proven not by a report, but by passing.

2막 — 무엇을 못 믿나Act 2 — What you can't trust

'못 믿을 결과'에는 유형이 있다.Untrustworthy output comes in types.

유형Type 어떻게 새나How it leaks 무엇으로 거른다What filters it
사실 오류·할루시네이션Factual error·hallucination 없는 사실을 채움Fills in nonexistent facts 팩트체크Fact-check
미검증 '완료'Unverified 'done' 테스트 안 돌림Tests never ran 자동 테스트Automated tests
명세 이탈Spec drift 요구와 다름Differs from the ask 명세·승인 게이트Spec·approval gate
자기채점 통과Self-graded pass 만든 자가 OKThe maker says OK 별도 검증자Separate verifier

[추론] 유형을 알면 게이트를 어디 둘지 보인다 — 각 유형마다 거르는 설계가 다르다.[inference] Know the type, and where to place the gate becomes obvious — each type is filtered differently.

2막 — 신뢰가 새는 곳Act 2 — Where trust leaks

생산만 하고 멈추면, 결함이 그대로 흐른다.Produce-and-stop lets defects flow downstream.

검증 없음No verification

[생산] → [그대로 사용]
결함이 하류(배포)로 그대로 샌다.
[produce] → [use as-is]
Defects flow straight downstream.

검증 루프Verification loop

[생산] → [검증] → [수정] → [재검증] → 통과해야 사용
결함이 게이트 앞에서 멈춘다.
[produce] → [check] → [fix] → [recheck] → use only on pass
Defects stop at the gate.

신뢰는 '점검 1회'가 아니라 — 통과 게이트.Trust isn't a single inspection — it's a pass-gate.

[추론] 통과할 때까지 도는 루프로 설계하면, 결함이 하류로 새지 않는다.[inference] Design it as a loop that runs until it passes, and defects won't leak downstream.

2막 — 기준을 먼저 적는다Act 2 — Write the bar first

무엇이 '맞음'인지, 결과물 만들기 전에 적어 둔다.Define 'correct' before you build it.

① 기준·테스트
먼저 작성무엇이 통과인지 정의
① Write bar·tests
firstdefine what 'pass' means
② 통과하도록
생성기준을 목표로
② Generate
to passthe bar is the target
통과 ✓Pass ✓③ 테스트가 채점③ Tests grade it
실패 → 수정 반복Fail → fix, repeat

테스트는 '그럴듯함'이 아니라 '통과 여부'로 채점한다 — 객관 게이트.Tests grade by 'pass or fail', not 'looks plausible' — an objective gate.

[출처: https://www.anthropic.com/engineering/claude-code-best-practices] 테스트 우선(TDD)은 검증 기준을 먼저 정의해 모델이 그 기준을 통과하도록 작업하게 하는 대표적 워크플로다. 구체 워크플로·명령은 2026-06 기준, 공식 문서로 현행 확인.[source: https://www.anthropic.com/engineering/claude-code-best-practices] Test-first (TDD) defines the bar before work begins, making the model work toward passing that bar. Confirm specific workflows with the official docs as of 2026-06.

2막 — 누가 채점하나Act 2 — Who grades it

만든 자가 채점하면, 약점이 안 보인다.The maker grading itself hides its own gaps.

⚠️ 자기채점⚠️ Self-grading ✅ 별도·객관 검증✅ Separate·objective check
누가 본다Who looks 만든 자 자신The maker itself 다른 에이전트·테스트·게이트Another agent·test·gate
무엇을 놓치나What it misses 자기 가정·편향Its own assumptions·bias (없음)(none)
무엇을 잡나What it catches 표면만Surface only 숨은 가정·실제 통과Hidden assumptions·real pass

[추론] 검증의 신뢰도는 '누가·무엇으로' 채점하느냐에서 갈린다. 자기가 자기를 채점하게 두면 안 된다.[inference] The reliability of verification comes down to who grades it and with what. You can't let it grade itself.

3막 — 통과할 때까지 도는 루프Act 3 — The loop until it passes

만들고 → 검증하고 → 고치고 → 다시 검증한다.Make → check → fix → check again.

생산결과 생성Producegenerate
검증기준 대조Checkvs bar
통과 → 게이트 통과 ✓Pass → gate cleared ✓
실패 → 수정 → ↺ 재검증Fail → fix → ↺ recheck

한 번 검증이 아니라, 기준을 통과할 때까지 자동으로 돈다 — 사람은 루프를 설계하고 게이트만 본다.Not a single check — it runs automatically until it passes the bar; the human designs the loop and watches the gate.

[추론] 결함 루프는 자동 검증 결과를 다시 생산자에 되먹여 통과 기준을 만족할 때까지 반복하는 닫힌 루프다. 정량 평가·벤치마크는 s18 소관 — 여기선 통과/실패 게이트 수준만.[inference] The defect loop is a closed loop that feeds verification results back to the producer until it satisfies the pass-bar. Quantitative evaluation belongs to s18 — here we go only as far as the pass/fail gate.

3막 — 검증을 전담시킨다Act 3 — A dedicated checker

사실 검증만 하는 '검증 전담' 에이전트를 둔다.Give fact-checking its own dedicated agent.

생산자주장·결과Producerclaims·output
팩트체크 에이전트출처 대조·반증 탐지Fact-check agentmatch sources·detect refutations
근거 태그 통과 ✓Evidence tag passes ✓
근거 없음 → 반려No evidence → rejected

전담 검증자는 별도 컨텍스트에서 비판적으로만 본다 — 만든 자의 가정에 오염되지 않는다.The dedicated checker looks critically from a separate context — uncontaminated by the maker's assumptions.

[추론] 팩트체크 에이전트: 사실 검증만 전담하는 별도 에이전트가 주장을 출처와 대조하고 반증을 탐지한다. [출처: How_to_claude/CLAUDE.md '근거 태그 원칙'][inference] Fact-check agent: a separate dedicated agent matches claims against sources and detects refutations. [source: How_to_claude/CLAUDE.md 'evidence tag principle']

3막 — 자동과 사람의 경계선Act 3 — The auto / human line

자동으로 굴리되, 되돌릴 수 없는 곳엔 사람을 세운다.Automate the loop — but gate the irreversible.

루프 자동 진행 중… ✓
다음: 프로덕션 배포

⏸ 멈춤 — 되돌릴 수 없음
승인 필요
loop running automatically… ✓
next: deploy to production

⏸ paused — irreversible
approval needed

전부 자동 ≠ 좋은 것 — 되돌릴 수 없는 것에만 사람 게이트를 박는다.All-auto ≠ good — gate the human only on the irreversible.

[출처: https://code.claude.com/docs/en/iam] [추론] 승인 게이트는 되돌리기 어려운 행동(배포·외부 부수효과·권한 변경) 앞에 사람 승인을 요구한다. 구체 권한 설정은 2026-06 기준, 공식 문서로 현행 확인(대표 예).[source: https://code.claude.com/docs/en/iam] [inference] Approval gates require human approval before irreversible actions (deploy, external side effects, permission changes). Confirm specific settings with the official docs as of 2026-06 (representative example).

3막 — 품질은 설계의 산물Act 3 — Quality is a designed process

품질은 '잘 만든다'가 아니라 '프로세스를 설계한다'.Quality isn't 'build well' — it's 'design the process'.

요소Element 무엇을 박나What it bakes in
검증 가능한 정의Verifiable definition 기준 먼저 (TDD·명세)Bar first (TDD·spec)
결함 루프Defect loop 통과까지 반복Repeat until pass
게이트Gates 팩트체크·승인Fact-check·approval
통과 기준Pass-bar '통과'를 명시Spell out 'pass'

[추론] 이 네 가지가 '우연한 신뢰'를 '설계된 신뢰'로 바꾼다. Rule No.1("결과를 믿지 말고 검증하라")을 프로세스로 자동화한 것이 Rule No.15. 정량 측정·벤치마크는 s18 소관.[inference] These four turn accidental trust into designed trust. Rule No.15 is Rule No.1 ("don't trust the output — verify it") automated into a process. Quantitative measurement belongs to s18.

4막 — 신뢰를 설계하기 전에Act 4 — Before you trust the output

이 5가지로, '믿는' 대신 '검증을 설계'한다.Design the verification with these five — don't just trust.

  1. 1
    무엇이 '맞음'인지 먼저 정의했나?Did you define 'correct' first? → 기준·테스트를 앞에 (S05)→ put the bar·tests up front (S05)
  2. 2
    결함 루프를 자동화했나?Did you automate the defect loop? → 통과까지 반복 (S07)→ repeat until pass (S07)
  3. 3
    사실은 전담 검증자가 거르나?Does a dedicated verifier filter facts? → 팩트체크·근거 태그 (S08)→ fact-check·evidence tags (S08)
  4. 4
    되돌릴 수 없는 곳에 승인 게이트를 뒀나?Did you gate approval on the irreversible? → 위험한 곳만 사람 (S09)→ human only on the dangerous (S09)
  5. 5
    통과 기준을 프로세스에 박았나?Did you bake the pass-bar into the process? → 자기채점 금지 (S06·S10)→ no self-grading (S06·S10)

[추론] 신뢰는 좋은 모델이 아니라 설계된 프로세스에서 온다. 믿기 전에 '검증을 설계했는가'를 먼저 묻는다.[inference] Trust comes from a designed process, not a good model. Before you trust, first ask whether you designed the verification.

4막 — 한 줄로 굳히기Act 4 — Lock it into one line

그래서 — 정의·루프·게이트·통과 기준을 프로세스에 박는다.So — bake definition, loop, gates & pass-bar into the process.

신뢰 = ['맞음'을 먼저 정의] + [결함 루프 자동화] + [사실·승인 게이트] + [통과 기준 명시]
  → 프로세스에 박아 반복
Trust = [define 'correct' first] + [automate the defect loop] + [fact·approval gates] + [spell out the pass-bar]
  → bake into the process, repeat

[추론] Rule No.1(결과를 믿지 말고 검증하라)·No.13(환경을 설계하라)·No.14(검증자를 둔다)가 만나는 지점, 그 자동화가 Rule No.15. 신뢰를 설계할 줄 알면, 어디에 게이트를 박을지 자동으로 보인다.[inference] Where Rule No.1 (don't trust the output — verify it), No.13 (design the environment), and No.14 (place a verifier) all meet — automating that meeting is Rule No.15. Once you design trust, where to place the gates becomes obvious.

4막 — 같은 결과, 다른 신뢰Act 4 — Same output, different trust

'믿고 쓴다'와 '검증을 설계한다'는 다르다.'Just trust it' and 'design the verification' are different.

그냥 믿음Just trust it
완료 보고만 보고, 자기채점 통과, 결함이 배포로 샌다.Only the "done" report, self-graded pass, defects leak to deploy.
검증을 설계Design verification
'맞음'을 먼저 정의, 결함 루프·게이트, 통과로 증명한다.Define 'correct' first, defect loop·gates, proven by passing.

[추론] 신뢰는 더 똑똑한 결과가 아니라 설계된 검증에서 온다. 모든 걸 다 검증하면 비용만 늘므로 '위험한 곳에 게이트'로 균형을 잡는다.[inference] Trust comes from designed verification, not smarter output. Trying to verify everything only adds cost — balance by placing gates on the dangerous spots.

닫으며 · 의심을 설계로 바꾼다Closing · turn doubt into design

결과를 믿지 마라 —
대신, 신뢰를 설계하라.
Don't trust the output —
design the trust.

한 단어로: 정의 → 루프 → 게이트 → 통과.In a word: define → loop → gate → pass.

이 강도 전담 팩트체커가 모든 주장을 게이트했다. 다음 강 예고 — 품질을 설계했으니, 이제 팀 인프라 — 비용 & 거버넌스 (Rule No.16).This lesson too: a dedicated fact-checker gated every claim. Next up: you designed quality — now team infrastructure: cost & governance (Rule No.16).

RULE No.15

[추론] Rule No.1("결과를 믿지 말고 검증하라")의 자동화가 Rule No.15("신뢰는 설계하는 것이다"). 이 코스 자체도 전담 fact-checker로 근거 태그를 게이트한다. As of 2026-06.[inference] Automating Rule No.1 ("don't trust the output — verify it") is Rule No.15 ("trust is designed"). This course itself gates claims with a dedicated fact-checker. As of 2026-06.