앤트로픽이 직접 말아주는 Fable 5.1 지리게 잘 사용하는 법
📺 원본 영상: 앤트로픽이 직접 말아주는 Fable 5.1 지리게 잘 사용하는 법
🎙️ 채널: 코드팩토리
📅 정리 일자: 2026-09-17
⚠️ Note: 본 리포트는 영상의 음성 변환 텍스트를 바탕으로 작성된 제공 리포트를 문맥상 검수한 것이다. 원본 음성과 STT 전문, 화면에 표시된 코드, 차트, 슬라이드 및 공식 문서의 세부 내용은 이번 검수에서 확인하지 않았다. 제목과 전사에 등장하는 ‘Fable 5.1’은 입력 표기를 유지했으며, 정확한 제품명과 버전은 제공된 자료만으로 확정하지 않았다. Anthropic의 권고로 소개되는 내용과 모델별 특성은 강연자의 설명을 옮긴 것으로, 공식 문서와 별도로 대조한 결과는 아니다.
개요
이 영상에서 코드팩토리는 Anthropic의 가이드라고 소개한 내용을 바탕으로, AI를 활용할 때 발생하는 토큰 낭비와 불필요한 대기, 과도한 수정, 대화 기록 관리 문제를 열 가지 주제로 설명한다. 핵심은 추론 강도를 일괄적으로 높이는 데 있지 않고, 작업에 맞는 설정과 도구, 실행 범위, 완료 조건을 구체적으로 정하는 데 있다. 이 리포트는 개발·엔지니어링 관점에서 각 조언의 적용 방법과 조건을 풀어쓰며, 제공된 자료로 확인되지 않는 벤치마크 수치나 API 구현은 재구성하지 않는다.
정상적인 코딩 요청이 거절될 때는 질문과 도구 출력을 살펴본다
강연자는 문제가 없는 코딩 요청이 거절되는 상황에서 먼저 질문의 표현을 바꿔보라고 제안한다. 예를 들어 “오류 없이 컴파일돼?”라고 묻는 대신 “이 코드에 버그가 있어?”라고 질문하면, 모델에 코드의 문제점을 살펴보는 작업을 요청할 수 있다는 설명이다. 다만 두 질문이 확인하는 범위는 같지 않으므로, 이 조언을 컴파일 검증을 생략해도 된다는 뜻으로 해석해서는 안 된다. 영상에서 제시하는 취지는 정상적인 요청이 막혔을 때 표현을 조정해보라는 것이며, 표현 변경만으로 모든 거절 문제가 해결된다는 근거까지 제시되지는 않는다.
두 번째 점검 대상은 모델이 참고할 수 있는 언어 문서다. 강연자는 잘 알려지지 않은 프로그래밍 언어를 다룬다면 문법을 확인할 수 있는 자료를 함께 제공하라고 권한다. 세 번째로는 도구가 반환하는 데이터에 Base64로 인코딩된 내용이 포함되어 있는지 확인하라고 설명한다. 강연자에 따르면 정상적인 작업에서도 이러한 데이터가 거절의 원인이 될 수 있으므로, 도구 결과를 모델에 전달하는 단계에서 해당 내용을 제외하는 방식을 검토할 수 있다. 제공된 리포트에는 구체적인 거절 사례나 판정 원리가 설명되어 있지 않으므로, 이를 Base64 데이터 전체에 대한 일반적인 제한으로 확대할 수는 없다.
추론 강도는 작업별로 비교하며 조정한다
강연자는 작은 모델의 추론 강도인 Effort를 높여 사용하는 경우, 영상에서 소개하는 모델의 Low 설정과 비교해보라고 제안한다. 강연자가 전하는 Anthropic의 설명에 따르면 일부 작업에서는 Opus나 Sonnet과 작업당 비용이 비슷하면서도 평가 점수가 더 높게 나올 수 있다는 것이다. 그러나 제공된 리포트에는 비교에 사용된 정확한 모델 버전이나 평가 과제, 비용 수치가 포함되어 있지 않다. 따라서 이 대목에서 가져갈 실무적인 방법은 특정 모델의 우위를 단정하는 것이 아니라, 같은 작업을 서로 다른 설정으로 수행해 결과와 비용을 비교하는 것이다. 강연자가 제시하는 순서는 영상에서 기본값으로 소개한 High에서 시작한 뒤 Medium과 Low를 시험하고, 결과가 충분하면 낮은 설정을 사용하는 방식이다.
이때 강연자가 특별히 지적하는 차이는 검색 행동이다. 영상에서는 Low 설정이 검색을 덜 하는 경향이 있어, 최신 정보가 필요한 질문에서 문제가 될 수 있다고 설명한다. 이에 대한 대응으로 해당 질문에만 추론 강도를 높이거나, 이미 알고 있다고 생각하는 정보라도 최신성이 중요하면 검색으로 확인하도록 지시하는 방법을 제안한다. 여기서 추론 강도를 조절하는 지시와 검색을 요구하는 지시는 목적이 다르다. 전자는 작업에 투입하는 사고 수준을 조정하려는 것이고, 후자는 최신 정보 확인이라는 행동을 명시적으로 요구하려는 것이다.
반대로 강연자는 X High[?]나 Max처럼 높은 설정이 긴 문서 작성에서는 불필요한 지연을 만들 수 있다고 설명한다. ‘X High’의 정확한 설정명과 표기는 제공된 자료만으로 확인되지 않는다. 생각하는 과정에서 문서 전체를 작성한 뒤 최종 답변에서 다시 작성하는 형태가 나타날 수 있다는 것이다. 이를 줄이기 위해 우선 High로 작업하고, 더 높은 설정이 필요하다면 사고 단계에서는 구성과 핵심 내용만 정하도록 요청하라고 권한다. 최종 문서의 작성은 최종 답변 단계에서 수행하도록 구분하는 방식이다. 이 조언은 높은 설정을 피하라는 의미보다는, 긴 결과물을 만드는 작업에서 계획과 실제 출력의 중복을 줄이려는 방법으로 이해할 수 있다.
작은 숫자를 읽으려면 실제 확대 이미지를 제공해야 한다
차트에 숫자가 빽빽하게 들어 있거나 글자가 작을 때, 강연자는 필요한 영역을 잘라 확대해서 다시 보여주는 방법을 권한다. 예를 들어 매출 그래프를 읽는 작업이라면 모델이 확인할 영역을 선택하고, 도구가 그 영역을 잘라 확대한 이미지로 반환하도록 구성한다. 그러면 모델은 전체 이미지만 볼 때 놓쳤던 숫자와 글자를 다시 확인할 기회를 얻는다. 영상에서는 선택한 영역을 잘라 확대하는 Crop Tool만으로도 상당한 개선 효과가 있다는 가이드의 설명을 소개하지만, 제공된 리포트에는 구체적인 개선율이 제시되어 있지 않다.
이 대목에서 중요한 조건은 실제로 이미지를 처리하는 도구가 있어야 한다는 점이다. 강연자는 “확대해서 봐”라는 문장만 추가해서는 충분하지 않다고 강조하며, PIL이나 OpenCV 같은 이미지 처리 라이브러리를 예로 든다. 설명된 작업 흐름은 모델의 영역 선택, 도구의 자르기와 확대, 처리된 이미지의 재입력으로 이어진다. 다만 제공된 리포트에는 좌표 전달 방식이나 확대 배율, 도구 인터페이스가 나오지 않으므로 구체적인 구현을 확정할 수 없다.
글을 어렵게 만드는 비유는 직접적인 설명으로 바꾼다
강연자는 콘텐츠 작성에서 불필요한 비유와 추상적인 표현이 의미 전달을 방해할 수 있다고 지적한다. 단순히 매개변수의 값을 조정하라는 내용을 과도한 비유로 표현하면, 독자는 실제로 무엇을 해야 하는지 다시 해석해야 한다. 전사에 등장하는 비유의 정확한 문구는 일부 불명확하지만, 강연자가 문제 삼는 것은 장식적인 표현 때문에 설명이 더 어려워지는 현상이다. 이에 따라 문체를 수정할 때는 표현을 화려하게 다듬는 것보다 뜻을 직접 전달하도록 요청하는 것이 중심이 된다.
영상에서 소개하는 영어 지시문은 STT만으로 정확한 원문을 확정하기 어려우므로 그대로 인용하지 않는다. 강연자가 설명한 의미는 멋부린 표현을 제거하고 내용을 직접 설명하라는 것이다. 강연자는 이 지시를 프롬프트에 덧붙이는 방법을 제안하며, 시스템 프롬프트에 넣을 수도 있지만 우선 개별 요청에 직접 적용하는 방식을 권한다고 전한다. 따라서 이 조언은 모든 글의 개성을 없애는 규칙이라기보다, 설명이 불필요하게 추상적이거나 우회적으로 작성되었을 때 적용하는 문체 교정 방법으로 읽을 수 있다.
서브에이전트에 위임했다면 메인 에이전트도 독립적인 작업을 계속한다
강연자는 서브에이전트(Subagent)에 일을 맡긴 뒤 메인 에이전트가 결과를 기다리기만 하는 실행 방식을 개선 대상으로 꼽는다. 강연자가 전하는 Anthropic의 설명에 따르면 메인 에이전트가 그동안 다른 작업을 진행하도록 했을 때, 품질과 비용을 비슷하게 유지하면서 평균 완료 시간을 줄일 수 있다는 것이다. 다만 제공된 리포트에는 시간 단축의 구체적인 수치나 측정 조건이 제시되어 있지 않다. 따라서 결과의 크기보다, 위임 후에도 독립적인 작업을 계속 수행하도록 구성한다는 실행 원리에 주목할 필요가 있다.
이 방식이 가능한지는 작업 사이의 의존관계에 달려 있다. 강연자는 반드시 직렬로 진행해야 하는 작업이라면 기다릴 수밖에 없지만, 병렬 처리가 가능한 경우에는 메인 에이전트가 다음 작업으로 넘어가고 서브에이전트의 결과는 준비되는 대로 전달받도록 하라고 설명한다. 또한 이런 지시를 넣었는데도 메인 에이전트가 계속 기다릴 수 있으므로, 필요하면 실행 중 추가 지시인 Steering으로 행동을 조정할 수 있다고 말한다. 이 설명을 종합하면 병렬화의 핵심은 에이전트 수 자체보다, 다른 작업의 결과 없이도 진행할 수 있는 일을 구분하고 대기 시간을 줄이는 데 있다.
수정 범위와 테스트 범위를 함께 제한한다
강연자는 로그인 오류를 고쳐달라고 했는데 관련 없는 화면까지 바꾸는 상황을 예로 들며, 요청과 무관한 문제는 발견하더라도 수정하지 않고 작업 종료 후 보고하도록 지시하라고 권한다. 동시에 요청한 문제를 해결하는 데 반드시 필요한 변경은 함께 수행하도록 해야 한다고 설명한다. 이는 수정량을 무조건 줄이는 규칙이 아니라, 문제 해결에 필요한 변경과 별도의 개선 작업을 구분하는 규칙이다. 이 구분이 있어야 에이전트가 필요한 수정을 누락하지 않으면서도 사용자가 요청하지 않은 방향으로 작업 범위를 넓히는 일을 줄일 수 있다.
테스트에 대해서도 강연자는 기능 검증과 테스트 파일의 영구 보존을 구분한다. 수정한 기능이 제대로 작동하는지는 확인하되, 확인을 위해 잠시 만든 코드를 모두 테스트 파일로 남기지는 않도록 요청하는 방식이다. 테스트 파일은 사용자가 요청했거나 프로젝트에서 같은 종류의 테스트를 관리하고 있을 때, 기존 방식에 맞춰 필요한 만큼 추가하라고 제안한다. 따라서 이 조언은 검증을 줄이라는 의미가 아니라, 검증 과정에서 생긴 임시 코드와 프로젝트가 계속 관리할 테스트를 구별하라는 취지다.
파일을 수정하는 방법 역시 작업 비용과 연결된다. 강연자는 한두 줄만 바꾸면 되는 상황에서 파일 전체를 다시 작성하면, 바뀌지 않은 코드까지 출력하느라 시간과 토큰을 더 소비한다고 설명한다. 같은 결과를 얻을 수 있다면 전체 파일을 재작성하지 말고 필요한 부분만 수정하도록 시스템 프롬프트나 첫 사용자 메시지에 명시하라고 권한다. 제공된 리포트에는 특정 편집 도구의 사용법이 제시되어 있지 않으므로, 여기서 확인할 수 있는 원칙은 변경이 필요한 범위에 집중하라는 것이다.
이미 맡긴 일은 끝까지 진행하되 승인 경계는 명확히 둔다
강연자는 이미 요청한 일을 두고 계속 진행 여부를 묻거나, 다음에 하겠다고 말한 뒤 멈추는 행동을 별도의 문제로 다룬다. 특히 사용자가 작업 과정을 계속 지켜볼 수 없는 상황이라면, 이미 요청한 일은 다시 허락을 구하지 않고 진행하도록 시스템 프롬프트에 명시하라고 권한다. 질문이 필요한 사항은 가능하면 작업 초기에 한 번에 모아서 확인하도록 요청하는 방식도 함께 소개한다. 이는 작업 중 반복되는 확인 대기로 인해 실행이 끊기는 상황을 줄이려는 목적이다.
여기에 강연자는 요청한 작업을 일부만 수행하고 끝내지 말라는 지침을 함께 넣으라고 설명한다. 일부가 막히더라도 진행할 수 있는 나머지는 완료하고, 수행하지 못한 부분은 이유를 별도로 보고하도록 하는 방식이다. 이때 완료한 일과 막힌 일을 구분해 전달해야 사용자가 결과를 정확히 파악할 수 있다. 영상이 강조하는 지속성은 모든 문제가 해결된 것처럼 답하는 태도가 아니라, 가능한 작업을 끝까지 수행하고 남은 제약을 드러내는 태도에 가깝다.
동시에 강연자는 복구하기 어려운 삭제나 요청 범위를 바꾸는 행동에는 사전 확인이 필요하다고 말한다. 의견만 물었을 때는 설명만 제공하고 실제 수정으로 넘어가지 않도록 구분해야 한다는 점도 덧붙인다. 사용자가 직접 관리하거나 반드시 승인해야 하는 작업은 별도로 지정할 수 있다. 따라서 영상의 자율 실행 지침은 무조건적인 실행 허용이 아니라, 이미 맡긴 작업과 추가 승인이 필요한 행동 사이의 경계를 분명히 하는 방식이다.
이전 모델에 맞춘 금지 규칙을 다시 점검한다
강연자는 이전 버전에서 사용하던 “굵은 글씨를 쓰지 마”나 “목록을 쓰지 마” 같은 지침을 새 모델에도 그대로 적용하고 있지는 않은지 확인하라고 권한다. 영상에서는 소개 대상 모델이 서식을 덜 사용하는 편이므로, 기존의 금지 문구가 더 이상 필요하지 않을 수 있다고 설명한다. 이런 경우에는 규칙을 삭제하거나 필요한 때 사용 여부를 묻도록 바꾸는 방법을 제안한다. 다만 이는 영상에서 소개한 모델 특성에 관한 설명이므로, 모든 모델이나 모든 문서 작업에 동일하게 적용되는 원칙으로 볼 수는 없다.
강연자는 작업 중 설명이 적어 진행 상태를 알기 어려운 경우에 대한 지침도 소개한다. 시작 전에는 할 일을 한 줄로 알리고, 작업 중에는 진행 상황을 짧게 전달하며, 종료 시에는 완료한 작업과 확인한 내용을 정리하도록 요청하는 방식이다. 이 설명을 앞선 서식 조언과 연결하면, 프롬프트를 관리할 때는 금지 사항뿐 아니라 필요한 소통 방식도 함께 점검해야 한다는 결론에 이른다. 이전 모델의 과도한 설명을 줄이기 위해 넣었던 규칙이 현재 모델에서는 작업 상태를 파악하기 어렵게 만들 수 있기 때문이다.
요약과 직접 인용의 차이를 예시로 보여준다
강연자는 문서를 요약하는 과정에서 원문의 표현을 가져오고도 인용 표시를 생략하는 문제를 지적한다. 영상에서 소개한 가이드에 따르면 해당 모델은 이전 버전보다 이런 행동이 더 자주 나타날 수 있다고 한다. 원문 표현과 모델이 새로 작성한 설명이 구분되지 않으면, 독자는 어떤 문장이 자료에 실제로 쓰였는지 판단하기 어려워진다. 따라서 요약의 정확성을 관리할 때는 내용의 일치 여부뿐 아니라 표현의 출처를 구분하는 방식도 중요해진다.
이에 대해 강연자는 시스템 프롬프트에 올바른 답변 예시를 넣는 방법을 소개한다. 사용자의 요청과 모범 답변뿐 아니라, 그 답변이 왜 올바른지 설명까지 함께 제공하는 구성이다. 적용하려는 규칙은 문서를 요약하되 그대로 가져온 표현에는 따옴표를 붙이고, 요약과 직접 인용을 쉽게 구별하도록 만드는 것이다. 영상에서 언급한 공식 문서 예시의 주제는 STT만으로 명확하게 식별되지 않아 생략했지만, 원하는 인용 방식을 실제 답변 예시로 보여준다는 방법은 분명히 전달된다.
대화 이력을 압축할 때는 Thinking Block 처리도 함께 결정한다
마지막 주제는 API로 에이전트를 구현할 때의 대화 기록 관리다. 강연자는 응답에 사용자에게 보여줄 답변과 별도로 추론 관련 기록을 담는 Thinking Block이 포함될 수 있으며, 그 안에 Signature라는 서명 정보가 들어 있다고 설명한다. 제공된 리포트는 전사의 “출홍 기록”을 문맥상 “추론 기록”으로 교정했다고 명시한다. 다만 실제 응답 필드나 지원 조건, 내부 추론이 어느 범위까지 제공되는지는 제공된 자료만으로 확정할 수 없으므로, 이를 모든 API 응답이 전체 내부 사고 과정을 제공한다는 의미로 읽어서는 안 된다.
강연자가 전달하는 첫 번째 원칙은 이전 기록을 계속 사용할 때 Thinking Block을 받은 그대로 보내고, 그 앞의 대화를 수정하지 말라는 것이다. 이전 대화만 짧게 요약하면서 기존 Thinking Block을 그대로 붙이면 기록 사이에 불일치가 생겨 API 검사에서 오류가 날 수 있다고 설명한다. 즉, 이 대목에서는 사용자에게 읽히는 대화 내용과 API가 검증하는 추론 관련 블록을 서로 독립적으로 편집해도 되는 것으로 취급하지 않는다. 다만 제공된 리포트에는 구체적인 오류 메시지나 재현 코드가 없으므로, 정확한 검증 조건과 적용 범위는 이 리포트에서 확정하지 않는다.
대화가 길어져 애플리케이션이 직접 기록을 압축해야 한다면, 강연자는 다른 구성을 제안한다. 전체 기록을 요약 메시지와 새로운 사용자 요청으로 바꾸고, 이전 Thinking Block은 함께 보내지 않는 방식이다. 그러면 모델이 요약된 내용을 출발점으로 다시 작업하도록 만들 수 있다는 설명이다. 요약에는 사용자가 정한 조건, 완료한 일, 남은 일, 발생한 문제와 처리 방법을 포함하라고 권한다. 이 조언에서 요약은 대화의 길이만 줄이는 작업이 아니라, 다음 실행에 필요한 상태를 전달하는 작업으로 자리 잡는다.
| 구분 | 이전 기록을 이어서 사용하는 경우 | 애플리케이션이 직접 요약하는 경우 |
|---|---|---|
| 대화 이력 | 강연자는 앞선 대화를 수정하지 말라고 설명한다 | 기존 기록을 요약 메시지와 새 요청으로 바꾼다 |
| Thinking Block | 강연자는 받은 형태 그대로 전달하라고 설명한다 | 이전 블록을 함께 보내지 않는 방식을 제안한다 |
| 주의할 조합 | 앞선 대화만 수정하고 기존 블록을 유지하는 조합 | 작업 조건이나 미완료 사항이 빠진 불완전한 요약 |
이 표는 API의 일반 사양을 정리한 것이 아니라, 영상에서 설명한 두 가지 처리 경로를 비교한 것이다. 강연자의 설명에서 오류 가능성과 연결되는 지점은 대화 이력은 변경하면서 기존 추론 블록은 유지하는 혼합 방식이다. 또한 영상은 애플리케이션이 직접 요약하는 상황을 다루므로, 제공자가 지원하는 별도의 압축 기능까지 같은 방식으로 동작한다고 단정할 수 없다. 실제 구현에 필요한 요청 형식과 버전별 조건은 음성 설명만으로 확인되지 않는다.
마무리 / 핵심 정리
영상의 열 가지 조언을 종합하면, AI 활용의 효율은 추론 강도뿐 아니라 입력을 구성하고 작업을 진행시키는 방식에 달려 있다. 강연자는 같은 작업을 여러 추론 설정으로 비교하고, 작은 글자는 실제 이미지 처리 도구로 확대하며, 병렬로 진행할 수 있는 작업에서는 불필요한 대기를 줄이도록 권한다. 코드 수정에서는 요청 범위와 필요한 검증을 명확히 하고, 긴 작업에서는 이미 승인된 일을 끝까지 진행할 수 있도록 지침을 마련하라고 설명한다. 이 조언들은 모두 모델이 해야 할 행동을 구체적으로 정한다는 공통점을 가진다.
한편 작업을 빠르게 끝내는 것만으로 결과의 신뢰성이 확보되지는 않는다. 강연자는 요약과 직접 인용을 구분하고, 작업 종료 시 확인한 내용을 보고하며, 대화 압축 과정에서도 사용자의 조건과 미완료 사항을 보존하도록 강조한다. 이 설명을 종합하면 비용 절감은 필요한 정보를 무조건 줄이는 일이 아니라, 중복 출력과 불필요한 수정, 대기 시간을 줄이면서 작업에 필요한 상태를 유지하는 일에 가깝다. 다만 모델별 성향과 API 동작에 관한 설명은 영상의 주장으로 구분해야 하며, 제공된 자료만으로 확인되지 않는 제품명이나 성능 수치까지 확정해서 받아들여서는 안 된다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | 앤트로픽이 직접 말아주는 Fable 5.1 지리게 잘 사용하는 법 |
| 채널 | 코드팩토리 |
| 제공된 전사 범위 | 00:00–08:04 — 제공 리포트의 기재값이며 원본 대조는 하지 않음 |
| 리포트 작성 | 2026-09-17 |
| 작성 방식 | 제공된 YouTube 영상 STT 기반 리포트의 문맥 및 불확실한 표현 검수 |
| 강연에서 언급한 자료 | Anthropic의 모델 활용 가이드 및 공식 문서. 정확한 문서명과 URL은 제공된 리포트에 포함되지 않음 |
| 확인 범위 | 제공된 리포트와 스크린샷 목록을 검토했으며, 원본 음성·STT 전문·영상 화면·외부 공식 문서는 대조하지 않음 |
| 불확실한 표기 | Fable 5.1[?]: 제품명과 버전 미확인. X High[?]: 설정명과 표기 미확인. 비용·평가 점수·시간 단축·이미지 판독 개선율은 구체적인 수치가 없어 보충하지 않음 |
| 스크린샷 | 목록의 여섯 항목 모두 로컬 경로만 있고 webUrl이 없어 삽입하지 않음 |
본 리포트는 제공된 자료에 담긴 설명을 중심으로 검수했다. 기존 리포트에 명시된 “서버에이전트” → “서브에이전트”, “유약” → “요약”, “출홍 기록” → “추론 기록” 교정은 문맥상 타당하여 유지했으나, 원본 음성과 재대조한 결과는 아니다. 모델명과 일부 영어 문구, 공식 문서 예시의 고유명사는 근거가 부족해 임의로 복원하지 않았다. 본문의 발언 예시 역시 원문과 대조한 직접 인용으로 보장하지 않는다. 정확한 발언과 화면 자료는 원본 영상을 참조해야 한다.
영상 주요 장면
01:20 - 낮은 추론 강도에서 최신 정보 검색을 요구하는 프롬프트를 설명하는 구간. 화면의 실제 문구 확인이 필요한 후보 시점.
02:13 - 이미지를 실제로 자르고 확대하는 도구가 필요하다고 설명하는 구간. 관련 도구나 예시 이미지의 화면 표시 여부 확인.
03:29 - 메인 에이전트가 다른 작업을 진행하고 서브에이전트 결과를 준비되는 대로 받는 방식을 설명하는 구간.
04:08 - 임시 검증 코드와 프로젝트에 남길 테스트 파일을 구분하는 프롬프트 설명 구간.
06:38 - 문서 요약에서 원문 표현에 따옴표를 붙여 직접 인용을 구분하도록 요청하는 예시 설명 구간.
07:33 - 대화 기록을 요약 메시지와 새 요청으로 교체하고 이전 Thinking Block을 제외하는 방법의 설명 구간.