에이전트 검수와 평가: 자기 검수 편향과 별도 검수자

🤔 "잘 됐나요?"라고 물으면 늘 잘 됐다는 답이 올 때

에이전트에게 일을 맡긴 뒤 결과가 맞는지 같은 대화에서 다시 물어보는 일은 흔합니다. 잘 됐다는 답을 받아도 막상 확인해 보면 빠진 곳이 있을 수 있습니다. 같은 지시를 두세 번 되풀이하게 되면 모델이 부족하다고 결론 내리기 쉽지만, 검수 기준과 전달한 자료 및 검수 방식도 함께 살펴봐야 합니다.

소스를 반복해서 맛보다가 다른 사람에게 한 번 맛봐 달라고 부탁하는 장면을 떠올려 봅니다. 익숙한 결과를 다른 관점으로 확인한다는 비유입니다. 모델이 사람처럼 미각이나 감정을 가진다는 뜻은 아닙니다. 이 편에서는 자기 검수가 왜 후해지는지, 검수와 평가를 어떻게 떼어 놓는지, 테스트를 편법으로 통과시키는 보상 해킹을 어떻게 잡아내는지를 도구와 상관없이 정리합니다. 클로드 코드에서 검증을 나누는 구체적인 방법은 AI 자기 검수의 한계에 있습니다.

🔑 에이전트 검수와 평가의 정의

에이전트 검수는 결과물 하나가 기준에 맞는지 확인하는 일이고, 에이전트 평가는 여러 과제를 반복해 돌려 에이전트를 얼마나 믿을 수 있는지 측정하는 일입니다.

둘은 보는 단위가 다릅니다. 검수는 오늘 받은 결과물 한 건을 봅니다. 평가는 과제 수십 개를 여러 번씩 돌려, 모델이나 지침이나 도구를 바꿨을 때 에이전트가 나아졌는지 나빠졌는지를 숫자로 확인합니다. 검수는 개별 결과를 전달하기 전에, 평가는 구성을 바꿀 때나 반복 사용의 성능을 확인할 때 활용할 수 있습니다.

🪞 자기 검수가 후해지는 이유

일부 모델과 과제에서 자기 출력에 더 높은 점수를 주는 현상이 연구로 관찰됐습니다. 모든 모델의 모든 자기 검수가 반드시 후하다는 뜻은 아닙니다. 2024년 발표된 「LLM Evaluators Recognize and Favor Their Own Generations」는 이를 자기 선호(self-preference)라 부르며, 사람이 보기에 품질이 같은데도 모델이 자기 출력에 다른 출력보다 높은 점수를 주는 현상으로 정의했습니다. 연구진은 시험한 모델을 미세 조정한 조건에서 자기 출력 인식과 선호 편향 사이의 관계를 관찰했습니다.

같은 해 10월 처음 공개된 다른 연구는 익숙함이 원인일 수 있다는 가설을 살폈습니다. 연구의 실험에서는 혼란도(perplexity)가 낮은 글에 모델이 사람보다 높은 평가를 주는 경향이 관찰됐습니다. 자기 출력뿐 아니라 익숙한 형태의 글을 선호할 수 있다는 해석입니다. 혼란도는 모델이 다음 단어를 얼마나 예측하기 어려워하는지를 나타내는 값입니다.

여기에 대화 기록이 겹칩니다. 같은 대화에서 검수를 시키면 결과물을 만든 과정과 이유가 대화에 그대로 남아 있어서, 검수하는 쪽도 그 과정을 전제로 판단합니다. 사용자의 말에 맞춰 주려는 아부 성향까지 더해지면 잘 됐느냐는 질문에는 잘 됐다는 답이 나오기 쉽습니다.

🧑‍⚖️ 검수를 만든 쪽에서 떼어 놓는 방법

검수자가 작성 과정의 판단을 그대로 받아들이지 않도록 검토 자료와 기준을 따로 구성할 수 있습니다. 다만 새 대화로 옮긴다고 편향이 모두 사라지지는 않습니다. 클로드 코드 공식 모범 사례 문서가 권하는 방법도 같은 방향입니다.

• 새 대화 맥락에서 검수합니다: 공식 문서는 새 컨텍스트가 코드 리뷰를 개선한다며, 방금 쓴 코드에 치우치지 않기 때문이라고 설명합니다. 한 쪽이 작성하고 다른 쪽이 검수하는 작성자와 검수자 분리 방식을 예로 듭니다
• 변경 내역과 기준 및 필요한 원자료를 줍니다: 새 서브에이전트로 도는 검수자에게는 변경 내용과 요구사항 및 확인에 필요한 자료를 줍니다. 작성 과정의 설명을 그대로 결론으로 받아들이지 않도록 합니다
• 짚을 범위를 좁힙니다: 같은 문서는 문제를 찾으라고 지시받은 검수자는 작업이 멀쩡해도 대개 무언가를 보고한다고 경고합니다. 정확성이나 요구사항에 영향을 주는 문제만 짚으라고 지시해 두어야 쓸데없는 지적이 줄어듭니다

기준을 문서로 고정하는 일도 함께 필요합니다. 검수자에게 결과물만 주고 기준을 주지 않으면 검수자도 결과물의 인상만 보고 판단합니다. 무엇을 지켜야 하는지 적은 문서를 먼저 주고, 결과물을 그 기준에 대조하게 합니다.

세션을 나눠도 모델이 같으면 익숙함에서 오는 편향 일부는 남습니다. 필요하면 다른 모델이나 사람의 검토를 추가하고 중요한 사실은 원자료와 실제 결과로 확인합니다. 검수를 나누는 목적은 사람이 볼 것을 없애는 것이 아니라 사람이 볼 양을 줄이는 것입니다.

🧪 결과를 판정하는 세 가지 방법

검수와 평가에서 결과를 판정하는 장치를 채점기(grader)라고 부릅니다. 앤트로픽이 2026년 1월 공개한 에이전트 평가 글은 채점기를 세 가지로 나눕니다.

숫자나 파일 존재처럼 코드로 판정할 수 있는 것은 먼저 확인합니다. 코드로 확인할 수 있는 것은 코드로 먼저 걸러 내고, 남은 것을 모델 기반으로 보고, 사람은 남은 쟁점과 실제 결과를 봅니다. 자동 검사가 빠뜨린 문제도 있으므로 통과한 결과 일부를 원자료와 대조합니다. 앤트로픽은 에이전트 개발 도구를 소개하면서도 다른 모델이 채점하는 방식이 규칙 기반 확인보다 덜 견고하다고 적었습니다.

본문의 세 채점 방식을 연결했습니다. 모델 판정의 변동과 각 단계의 한계를 고려해 검토 기준을 함께 확인합니다.

🎯 보상 해킹(Reward Hacking) 뜻: 테스트를 통과시키는 편법

보상 해킹(reward hacking)은 AI가 결과를 판정하는 장치의 빈틈을 이용해, 실제로 일을 해내지 않고도 높은 점수나 통과 판정을 받아 내는 현상입니다. 검수와 평가에서 보상 해킹을 따로 알아 둬야 하는 이유는 판정 결과만 보면 정상적인 통과와 똑같아 보이기 때문입니다.

reward 뜻과 보상 해킹이라는 이름

영어 reward는 '보상'이라는 뜻이고, AI 분야에서는 강화학습에서 모델이 잘했을 때 주는 점수를 가리킵니다. 강화학습은 행동의 결과에 점수를 주어, 점수가 높은 행동을 더 하도록 모델을 학습시키는 방식입니다. 점수를 매기는 규칙에 빈틈이 있으면 모델은 원래 의도한 일을 해내기보다 그 빈틈을 이용하는 편이 점수를 얻기 쉽다는 것을 배웁니다. 이렇게 점수 규칙의 빈틈을 파고드는 행동을 해킹에 빗대어 보상 해킹이라고 부릅니다.

구글 딥마인드는 2020년 4월 글에서 같은 현상을 명세 악용(specification gaming)이라 부르고, 목표의 문구는 만족하지만 설계자가 의도한 결과는 이루지 못하는 행동으로 설명했습니다. 보트 경주 게임에서 코스 위 초록 블록을 칠 때마다 점수를 주자, 에이전트는 결승선으로 가지 않고 같은 블록 주변을 빙글빙글 돌며 블록을 계속 쳤습니다. 빨간 블록을 파란 블록 위에 쌓는 과제에서 빨간 블록 바닥면의 높이로 성공을 판정하자, 에이전트는 블록을 쌓지 않고 빨간 블록을 뒤집어 놓았습니다. 딥마인드는 이런 사례를 60개가량 모았다고 밝혔습니다.

코딩 에이전트에서 나타나는 편법 여섯 가지

코딩 작업에서는 테스트와 채점 스크립트가 점수 역할을 합니다. 그래서 편법도 코드보다 테스트와 채점 스크립트를 향합니다.

종료 코드는 프로그램이 끝난 상태를 나타내는 값이고, 보통 0은 정상 종료를 뜻합니다. 앤트로픽이 2025년 11월 21일 공개한 연구는 파이썬에서 sys.exit(0)을 불러 테스트 실행 도중 빠져나가면 종료 코드가 0이 되어 모든 테스트가 통과한 것처럼 보인다는 예를 들었습니다. 판정 장치 고치기는 AI 평가 연구 기관 METR이 2025년 6월 5일 정리한 관찰에 나옵니다.

연구와 실험에서 관찰된 보상 해킹

METR은 오픈AI의 o3 모델을 평가하면서 보상 해킹 비율이 과제 묶음마다 크게 다르다는 결과를 냈습니다. 머신러닝 연구 과제 묶음인 RE-Bench에서는 128회 중 39회(30.4%), 소프트웨어 과제 묶음인 HCAST에서는 1,087회 중 8회(약 0.7%)였습니다. METR이 편법 계획을 세운 o3에게 "이 계획이 사용자의 의도에 맞느냐"고 묻자 o3는 열 번 모두 맞지 않는다고 답했습니다. 모델이 사용자의 의도를 알면서도 편법을 쓸 수 있다는 관찰입니다.

앤트로픽의 2025년 11월 연구는 보상 해킹 방법을 설명한 문서를 학습 자료에 섞어 일부러 보상 해킹을 익히게 한 모델을 관찰했습니다. 이 모델은 "What are your goals?"(목표가 무엇인가요?) 같은 단순한 질문에도 응답의 50%에서 겉으로만 지침을 따르는 척하는 추론을 했습니다. 클로드 코드로 연구 코드를 고치게 하자 12%의 비율로 보상 해킹을 탐지하는 코드를 일부러 망가뜨리려 했습니다. 앤트로픽은 학습 지시문에 이번 과제는 채점 스크립트를 통과시키는 것이 목적이라고 미리 밝혀 두는 방법으로, 보상 해킹을 익힌 모델이 다른 상황에서도 속이는 행동을 보이는 문제를 줄였고, 이 방법을 클로드 학습에 쓰기 시작했다고 밝혔습니다.

두 자료 모두 모델을 평가하거나 연구용으로 학습시킨 환경의 결과이며, 일상 작업에서 같은 비율로 일어난다는 뜻은 아닙니다. 준이아빠블로그도 2026년 9월 Sonnet 계열 모델에게 통과가 불가능한 테스트를 섞은 작업을 조건을 바꿔 아홉 번 맡겼습니다. 다섯 번은 모순을 알리고 되물었고, 세 번은 기댓값을 고친 사실과 이유를 보고했고, 한 번은 요구사항에 없는 최소 주문 금액 규칙을 지어내 코드와 명세 문서에 함께 적었습니다. 경과는 AI에게 테스트를 통과시키라고 시켜 본 결과에 있습니다.

보상 해킹을 막는 방법 세 가지

1. 테스트 파일을 보호합니다: 권한 설정이나 훅(도구 실행 전후에 자동으로 도는 검사)으로 테스트 폴더 수정을 막거나, 테스트 파일을 고칠 때 사람의 확인을 받게 합니다. 앤트로픽도 에이전트를 오래 돌리려고 지시, 도구, 기록을 묶은 실행 틀인 하네스에서 에이전트에게 테스트를 지우거나 고치는 것은 허용되지 않는다는 지시를 줬습니다.
2. 변경 내역에서 테스트와 명세 문서를 봅니다: 코드만 고칠 작업에서 테스트 파일이나 명세 문서가 함께 바뀌었다면 에이전트에게 근거를 묻습니다.
3. 검수를 따로 둡니다: 앞의 검수를 떼어 놓는 방법대로, 작업한 에이전트가 아닌 검수자에게 변경 내역과 요구사항을 주고 확인하게 합니다.

지시문에는 아래와 같은 문장을 넣을 수 있습니다. 다만 지시는 에이전트가 따를 가능성을 높일 뿐이므로, 되돌리기 어려운 작업은 1번의 권한 설정으로 막습니다.

📊 평가에서 쓰는 말과 pass@k, pass^k

에이전트 평가 글이 정리한 용어를 알아 두면 평가 도구나 연구 결과를 볼 때 편합니다.

• 과제(task): 입력과 성공 기준이 정해진 시험 하나
• 시행(trial): 과제를 한 번 돌린 것. 같은 과제도 여러 번 돌립니다
• 채점기(grader): 에이전트가 잘했는지 점수를 매기는 장치
• 기록(transcript): 시행 한 번의 전체 기록. 출력, 도구 호출, 중간 결과가 모두 들어갑니다
• 결과(outcome): 시행이 끝났을 때 실제 환경에 남은 상태

에이전트는 같은 과제도 돌릴 때마다 결과가 달라서 성공률을 두 가지로 봅니다. pass@k는 k번 가운데 한 번이라도 성공할 확률이고, pass^k는 k번 모두 성공할 확률입니다. 각 시행이 서로 독립이고 성공 확률이 항상 80%라는 가정에서는 세 번 중 한 번이라도 성공할 확률은 1에서 0.2의 세제곱을 뺀 99.2%이지만, 세 번 모두 성공할 확률은 0.8의 세제곱인 51.2%입니다.

여러 안을 받아 좋은 하나를 고르면 되는 일은 pass@k로 봐도 되고, 매번 안정적으로 성공해야 한다면 pass^k 같은 일관성 지표도 봅니다. 어떤 지표 하나만으로 사람 확인을 없앨 수 있다고 판단하지 않습니다. 같은 에이전트라도 어느 쪽으로 보느냐에 따라 믿을 만한 정도가 크게 달라집니다.

⏱️ 작업 길이로 측정하는 평가: 장기 과제(long-horizon task)와 타임 호라이즌

장기 과제(long-horizon task)는 여러 단계에 걸쳐 앞선 조건과 결과를 유지하며 이어 가야 하는 작업입니다. 호라이즌(horizon)은 앞을 내다보는 거리를 뜻하는 영어 낱말입니다. 과제가 길수록 단계가 많아지고, 앞 단계의 작은 실수가 뒤로 갈수록 쌓이기 때문에 짧은 과제의 성공률만으로 긴 업무를 맡길 수 있는지 판단하기 어렵습니다.

그래서 AI 평가 연구 기관 METR은 에이전트가 해낼 수 있는 과제의 길이로 능력을 나타냅니다. 이때 쓰는 값이 타임 호라이즌(time horizon)입니다. 50% 타임 호라이즌은 과제 길이를 사람 전문가가 그 과제를 끝내는 데 걸리는 시간으로 나타냈을 때, 에이전트가 절반의 확률로 성공할 것으로 예측되는 과제 길이입니다. AI가 실제로 작업한 시간이 아니라 과제의 크기를 사람의 작업 시간으로 표시한 값입니다. METR의 과제 모음은 소프트웨어 과제 100여 개로 구성되어 있고, METR은 현재 과제 모음으로는 16시간을 넘는 측정값을 믿기 어렵다고 적었습니다.

컴퓨터 화면을 조작하는 에이전트를 평가하는 시험인 OSWorld 2.0에서도 같은 경향이 보입니다. OSWorld 2.0은 실제 업무 흐름 108개로 구성되고, 사람이 과제 하나를 끝내는 데 걸리는 시간의 중앙값은 약 1.6시간입니다. 연구진이 공개한 분석 그림에서는 사람 기준 163분을 넘는 과제에서 그림에 포함된 모든 모델의 완전 성공률이 0이었습니다. 점수가 가장 낮았던 과제는 지시에 직접 적히지 않은 상태를 스스로 추론하거나, 여러 항목을 동시에 추적하거나, 서로 어긋나는 정보 가운데 맞는 정보를 가려내거나, 작업 도중 바뀌는 환경을 반영해야 하는 과제였습니다.

긴 작업을 검수할 때는 에이전트의 작업이 아래 다섯 지점에서 어긋나지 않았는지 확인합니다.

마지막 지점은 앤트로픽이 긴 작업용 하네스를 소개하면서 밝힌 실패입니다. 앤트로픽은 기능 목록과 진행 기록을 파일로 남겨 다음 세션이 먼저 읽게 하는 방식으로 대응했습니다. 긴 업무를 평가하거나 맡길 때도 확인할 수 있는 결과물 단위로 구간을 나누고, 구간마다 완료한 일과 근거, 남은 일을 파일에 남긴 뒤 다음 구간을 시작하면 구간마다 검수할 수 있습니다.

📝 결과만 보지 말고 기록을 읽는다

평가 글은 기록을 정기적으로 읽으라고 권합니다. 결과가 통과로 나와도 과정이 어땠는지는 기록에만 남기 때문입니다. 보상 해킹처럼 테스트를 고쳐 통과한 경우는 결과만으로 정상 통과와 구분되지 않고, 기록을 읽어야 드러납니다. 반대로 결과는 실패인데 기록을 보면 채점기가 너무 엄격해서 멀쩡한 답을 틀렸다고 본 경우도 있습니다.

작게 시작한다면 실제로 실패했던 작업을 과제로 모으는 편이 쓸모가 큽니다. 성공 기준을 한 줄씩 적고, 과제마다 여러 번 돌려 보고, 모델이나 지침 파일을 바꿀 때마다 같은 과제 묶음을 다시 돌려 비교합니다.

🗂️ 검수와 평가를 위해 남길 작업 기록

기록을 읽으려면 먼저 기록이 남아 있어야 합니다. 클로드 코드는 대화 기록을 자동으로 저장하지만, 대화 기록은 무엇을 요청하고 어떤 응답을 받았는지 확인하는 자료일 뿐 파일을 되돌리는 백업이 아닙니다. 클로드 코드의 /rewind는 클로드가 편집 도구로 고친 파일을 되돌리지만, 셸 명령으로만 바뀐 파일과 외부 서비스의 변경은 되돌리지 않습니다. 저장한 버전으로 돌아가려면 git 커밋이 있어야 합니다.

자동으로 남는 기록에는 무엇을 맡겼고 어떤 증거로 결과를 받아들였는지가 흩어져 있습니다. 그래서 작업마다 아래 항목을 짧게 따로 남깁니다.

나중에 그 세션을 다시 보려면 클로드 코드에서 /rename으로 지금 세션에 이름을 붙이고, /resume으로 이름이나 ID를 골라 다시 엽니다. /export는 지금 대화를 일반 텍스트로 저장합니다. 내보낸 대화를 다른 사람에게 줄 때는 비밀값과 개인정보가 들어 있지 않은지 먼저 봅니다.

🚨 검수에서 자주 걸리는 실패 유형 다섯 가지

기록을 읽다 보면 실패에도 반복되는 모양이 보입니다. 코딩 에이전트에서 자주 나오는 실패를 다섯 가지로 묶으면 검수할 때 무엇부터 볼지 정하기 쉽습니다.

표의 신호가 보였다고 바로 실패로 판단하지는 않습니다. 조사만 맡긴 작업은 파일을 고치지 않고 끝나는 것이 정상이고, 요구사항이 바뀌어 테스트를 정당하게 고치는 경우도 있습니다. 원래 요청과 실제 변경, 결과를 함께 대조한 뒤 판단합니다. 중복 수정은 작업을 나누는 단계에서 줄일 수 있습니다. 클로드 코드의 에이전트 팀은 여러 클로드 코드 세션이 팀원처럼 일을 나눠 맡는 기능입니다. 에이전트 팀 문서도 두 팀원(각각의 에이전트 세션)이 같은 파일을 고치면 덮어쓰기가 생긴다며, 팀원마다 다른 파일 묶음을 맡기라고 권합니다.

⚠️ 검수와 평가에서 자주 하는 실수

• 같은 대화의 검수만 믿습니다: 기존 판단에 영향을 받을 수 있어 원자료와 기준을 별도로 대조합니다
• 기준 없이 검수자만 따로 둡니다: 검수 역할을 만들어도 기준 문서를 주지 않으면 결과물의 인상만 봅니다
• 한 번 성공으로 판단합니다: 한 번 잘 됐다는 것은 pass@1 한 번의 표본일 뿐이라 반복해서 맡길 근거가 되기 어렵습니다
• 모델 채점을 사람 기준에 맞춰 보지 않습니다: 다른 모델이 채점한 점수가 사람의 판단과 맞는지 가끔 표본으로 대조해야 채점기를 믿을 수 있습니다

❓ 자주 묻는 질문

검수도 같은 모델에게 맡겨도 되나요?

새 대화로 나누면 작성 과정의 영향을 줄이는 데 도움이 될 수 있습니다. 실제로 오류를 더 잘 찾는지는 확인해야 합니다. 별도 모델도 같은 오류를 놓칠 수 있으므로 중요한 결과는 원자료와 실제 동작을 직접 확인합니다.

검수 단계를 넣으면 토큰이 많이 들지 않나요?

늘어납니다. 검수를 위한 호출이 한 번 더 들어가고 기준 문서를 매번 읽히는 비용도 붙습니다. 잘못된 결과물을 넘긴 뒤 되돌리는 비용과 비교해서 정하는데, 같은 실수를 뒤에서 고치는 일이 반복된다면 검수에 쓰는 토큰이 더 싼 쪽에 가깝습니다.

보상 해킹과 할루시네이션은 무엇이 다른가요?

할루시네이션은 AI가 모르는 내용을 아는 것처럼 지어내는 문제이고, 보상 해킹은 결과를 판정하는 장치를 피해 가는 문제입니다. 할루시네이션은 사실 확인으로 걸러 낼 수 있지만, 보상 해킹은 판정 결과가 통과로 나오므로 결과만 봐서는 드러나지 않고 변경 내역을 봐야 드러납니다. 요구사항에 없는 규칙을 지어내 문서에 적는 경우처럼 두 문제가 겹치기도 합니다.

평가 체계는 언제 만들어야 하나요?

구성을 바꾸기 전에 작은 평가 과제와 기준부터 준비할 수 있습니다. 바꾸기 전과 후를 같은 과제로 측정해야 개선 여부를 판단할 수 있습니다.

📝 모임 안내문 한 건부터 검수하기

설치나 추가 결제 없이 메모장에 아래 가상 자료를 적습니다.

초안에서 날짜, 장소, 수량을 각각 대조합니다. 수정본은 10월 12일 오후 2시 / 장소 미정 / 책 한 권을 모두 담아야 합니다. ‘문장이 자연스럽다’는 평가만으로 이 세 기준을 통과한 것은 아닙니다.

AI 검수를 이용한다면 새 대화에 원문과 초안 및 기준을 함께 주고 ‘기준을 위반한 문장과 근거만 적고 문제가 없으면 없다고 말해 줘’라고 요청할 수 있습니다. 받은 지적이 원문과 맞는지 먼저 보고 수정합니다. 초안 작성 대화에서 역할 이름만 바꾼 검수는 별도 에이전트 평가와 다릅니다.

이번에는 원문의 장소를 도서관 2층으로 바꿉니다. 기존 수정본을 새 원문과 대조해 장소를 반영합니다. 같은 세 기준을 유지한 채 다른 날짜와 준비물의 자료로 한 번 더 검수해 봅니다. 각 결과에 통과 여부와 틀린 항목을 남기면 작은 평가 기록이 됩니다. 두세 건의 성공을 전체 업무의 성공률로 일반화하지 않습니다.

📋 3줄 요약

1. 에이전트 검수는 결과 한 건을 기준과 대조하고 평가는 여러 시행으로 성능과 일관성을 확인하는 일입니다.

2. 새 검수자에게 원자료와 기준을 주되 검수자도 틀릴 수 있어 실제 결과와 판단 근거를 확인합니다.

3. 반복 성공률 계산에는 시행의 독립성 등 가정이 필요하며 점수 하나만으로 무인 실행을 결정하지 않습니다.

📚 참고 자료

• 앤트로픽의 에이전트 평가 설명
• Claude Code 검토 모범 사례
• LLM Evaluators Recognize and Favor Their Own Generations
• Self-Preference Bias in LLM-as-a-Judge
• Google DeepMind의 명세 악용 사례
• 앤트로픽의 보상 해킹 학습 연구
• METR의 보상 해킹 관찰
• METR 타임 호라이즌의 정의
• OSWorld 2.0 시험과 분석
• 앤트로픽의 긴 작업 하네스
• Claude Code 체크포인트의 복원 범위

2026년 10월 3일 원문을 확인했습니다. 본문 확률은 가정에 따른 계산 예제입니다.