메이커 에반MORNING DIGEST · 2026-08-23 · 메이커 에반🎬 영상

클로드 모델 선택 기준 — 평소엔 오퍼스 5 중간 추론, 거부당하면 오퍼스 4.6, 결제는 울트라씽크+페이블

01핵심 개요

항목내용
형식메이커 에반이 자신의 클로드 모델·추론 강도 세팅을 작업 유형별로 분류해 설명하는 실무 노하우 공유 영상
화자메이커 에반 (AI 도구 활용/스킬 제작·판매 크리에이터)
핵심 문제의식"제일 센 모델을 왜 안 쓰냐"는 질문에 답하기 위해, 모델을 먼저 고르지 말고 지금 하는 작업의 종류를 먼저 판단해야 한다는 원칙을 제시
핵심 내용(1) 평소 기본값은 오퍼스 5 + 추론 강도 중간, 페이블은 평소 미사용, (2) 추론 강도는 루틴 작업·브라우저 컨트롤·쉬운 작업에서는 무의미, (3) 복잡한 코드와 리팩토링 두 가지에서만 추론 강도를 올림, (4) 모델보다 스킬(작업 지침 문서)이 결과 품질을 더 크게 좌우, (5) 글쓰기는 소넷으로 충분, 근거 기반 논증 글만 오퍼스 사용, (6) 결제·정산 작업만 울트라씽크+페이블을 아낌없이 사용, (7) 크롤링 등에서 거부당하면 오퍼스 5 대신 오퍼스 4.6으로 전환, (8) 예외 3가지: 처음 만지는 코드베이스, 원인 불명 버그, 사실관계 많은 글

02핵심 기능/내용 구조

  1. 기본 세팅 — 오퍼스 5 + 추론 강도 중간: 코딩·작업 시 거의 전부 오퍼스 5를 사용하며 추론 강도는 중간에 고정해두고 건드리지 않는다. 페이블(Fable)은 평소 작업에서 아예 쓰지 않는다. 이유는 일일 업무 대부분이 "모델의 한계를 시험하는 일"이 아니라 파일 열어 고치고 테스트 돌리고 브라우저로 버튼 누르는 수준이라, 이 구간에서는 오퍼스 5가 이미 성능 천장에 도달해 있고 더 센 모델을 써도 결과가 안 바뀌며 대기 시간만 늘어나기 때문이라고 설명한다.
  2. 추론 강도가 무의미한 3가지 작업 유형: 첫째 루틴 작업(매일 하는 것, 방법이 정해진 것)은 추론을 올려도 같은 답을 더 오래 걸려 받을 뿐이다. 둘째 브라우저 컨트롤(페이지 열고 요소 찾고 클릭)은 판단이 아니라 관찰·실행의 문제라 추론 강도와 무관하다. 셋째 파일 정리·이름 변경·포맷 맞추기 같은 쉬운 반복 작업은 추론을 올리면 "계산기로 될 일을 슈퍼컴퓨터에 맡기는" 격으로 토큰값만 더 나간다고 지적한다.
  3. 추론 강도를 올리는 유일한 2가지 경우: 복잡한 코드(조건이 여러 겹 얽혀 한 곳을 고치면 다른 곳이 깨지고, 왜 이렇게 짰는지 코드에 이유가 안 적힌 경우)와 리팩토링(함수 호출 위치·값의 흐름·연쇄 영향을 전체적으로 파악해야 하는 작업)에서만 추론 강도를 올리며, 올릴 때는 "확실히" 올리고 어중간하게 올릴 거면 아예 안 올리는 게 낫다고 강조한다.
  4. 모델보다 스킬이 우선: 스킬은 작업 순서·규칙·함정·검증 방법을 문서로 적어둔 것으로, 스킬 없이 시키면 매번 처음부터 설명해야 하고 같은 실수가 반복된다. 모델이 헤매는 이유의 대부분은 지능 부족이 아니라 "이 프로젝트에서 뭐가 정답인지 몰라서"이며, 이는 더 센 모델로는 해결되지 않고 스킬로 적어줘야 해결된다. 같은 작업을 두 번 이상 시켰다면 스킬로 만들 자격이 있다고 판단 기준을 제시한다.
  5. 글쓰기 작업 — 소넷으로 충분: 블로그 초안, 설명 문서, 이메일, 정리글 등은 전부 소넷을 사용하며 불편했던 적이 없다고 밝힌다. 코드는 논리가 한 곳만 어긋나도 작동이 멈추지만 글은 톤·리듬·군더더기 제거가 관건이고 결국 사람이 최종 결정하므로, 초안을 빠르게 여러 번 받는 쪽(빠른 모델로 세 번)이 느린 모델로 한 번 잘 받는 것보다 유리하다고 설명한다. 단, 여러 근거를 엮어 논증을 세워야 하는 글은 "사실상 추론 작업"이라 오퍼스를 사용한다.
  6. 결제·정산 — 울트라씽크 + 페이블을 아낌없이 사용: 유일하게 최고 사양 조합(울트라씽크 + 페이블)을 아끼지 않고 쓰는 영역은 결제와 정산이다. 이유는 틀렸을 때 되돌릴 수 없기 때문(화면 오류는 다시 그리면 되고 글 오류는 고치면 되지만 돈이 잘못 나가면 코드 수정으로 끝나지 않음)이며, 환불·취소·재결제·중복 요청·통화단위 반올림·세금·수수료·정산 주기·실패 시 롤백 범위 등 경우의 수가 곱셈적으로 늘어나 한 번에 다 고려해야 하는 영역이라, 여러 관점에서 동시에 검증하는 울트라씽크가 빠진 경우를 잡아내는 데 유리하다고 설명한다.
  7. 거부당하면 오퍼스 4.6으로 전환: 크롤링 작업 등에서 로봇 배제 규칙(robots.txt)을 이유로 수집이 막혀 있다거나 "곤란하다"며 거부당하는 경우, 프롬프트를 고치는 대신 오퍼스 5에서 오퍼스 4.6으로 모델만 바꾸면 대부분 뚫린다고 밝힌다. 오퍼스 4.6은 판단이 정확하고 속도가 좋으며 거부가 덜한 "진짜 잘 만든 모델"이고, 평소 페이블을 쓰는 이유는 4.6이 성능이 부족해서가 아니라 최신이기 때문이라고 구분한다.
  8. 예외 3가지 (기준이 안 맞는 경우): (1) 처음 만지는 코드베이스는 스킬도 맥락도 없어 중간 추론으로는 자꾸 헤매므로 추론 강도를 올리는 것이 맞고, 이는 스킬이 만들어지기 전까지의 임시 처방이라 며칠 뒤 구조가 파악되면 다시 낮추고 스킬로 옮긴다. (2) 원인을 모르는 버그는 겉보기엔 루틴해 보여도 실제로는 여러 가설을 세워 하나씩 제거해야 하는 전형적 추론 작업이다. (3) 사실관계가 많이 들어가는 글은 빠른 모델일수록 확인을 덜 하는 경향이 있어 숫자·고유명사는 직접 검증해야 한다.

03기술적 맥락

이 영상의 핵심 기술적 통찰은 "모델 선택은 성능 문제가 아니라 작업 유형 분류 문제"라는 점이다. 오퍼스 5는 일반적인 코딩·조작 작업에서 이미 성능 천장(ceiling)에 도달해 있어, 더 상위 모델이나 더 높은 추론 강도를 투입해도 출력 품질은 그대로이고 지연 시간과 토큰 비용만 증가하는 구간이 존재한다는 것이 화자의 반복적 관찰이다. 반면 복잡한 코드·리팩토링처럼 코드 전체의 인과 관계를 넓게 조망해야 하는 작업에서는 추론 강도가 실제로 값을 하며, 이는 추론 모델의 이점이 "탐색 공간이 넓고 초기 판단 오류의 되돌림 비용이 큰" 문제에서 극대화된다는 일반 원칙과 일치한다. 또한 "스킬"(작업별 지침 문서, 순서·규칙·함정·검증 방법을 사전 기술)을 모델 업그레이드보다 우선시하는 접근은, LLM의 실패 원인이 지능 부족보다 프로젝트 고유 맥락 결여에 있다는 관찰에 근거하며, 이는 프롬프트 엔지니어링/컨텍스트 엔지니어링이 모델 크기보다 실무 성과에 더 큰 영향을 미친다는 최근 업계 담론과 맞닿아 있다. 거부(refusal) 대응에서는 프롬프트 수정 대신 모델 교체(오퍼스 5 → 오퍼스 4.6)를 택하는데, 이는 동일 계열 내에서도 모델 버전별로 거부 임계값과 안전 정책 튜닝이 다르게 적용되어 있음을 시사한다.

04전략적 의미

이 영상은 개인/소규모 팀 단위의 AI 도구 운영에서 "모델 그레이드 최적화"가 비용·속도·품질 삼각형에서 실질적 레버리지를 갖는다는 점을 보여준다. 특히 결제·정산처럼 되돌릴 수 없는(irreversible) 고위험 도메인에만 최고 사양(울트라씽크+페이블)을 배정하고, 나머지 대부분의 작업은 중간 사양으로 처리하는 "티어링 전략"은 AI 에이전트를 프로덕션에 투입하는 조직이 참고할 수 있는 리스크 기반 자원 배분 원칙이다. 또한 "모델보다 스킬"이라는 주장은, 반복 작업을 스킬(재사용 가능한 지침 문서)로 형식화하는 것이 모델 자체의 업그레이드보다 ROI가 높다는 것으로, 이는 AI 활용 성숙도가 높아질수록 조직의 경쟁력이 "어떤 모델을 쓰는가"보다 "얼마나 잘 정리된 작업 지침(스킬/프롬프트 라이브러리)을 보유했는가"로 이동한다는 흐름을 뒷받침한다. 거부당했을 때 프롬프트를 재작성하지 않고 모델을 교체하는 전략은, 동일 회사의 여러 모델 버전을 도구함처럼 병행 보유하는 것 자체가 실무 생산성 자산이 될 수 있음을 시사하며, 화자가 스킬을 직접 만들어 스킬샵에서 판매한다는 언급은 "작업 지침의 상품화"라는 새로운 수익 모델의 등장을 보여준다.

05핵심 워크플로우 또는 비교표

작업 유형사용 모델추론 강도근거
일반 코딩/파일 조작/브라우저 작업 (기본값)오퍼스 5중간 (고정)이미 성능 천장 도달, 더 올려도 결과 불변·시간만 증가
복잡한 코드 (조건 다중 얽힘, 수정 시 연쇄 파손)오퍼스 5높음빠른 오답의 되돌림 비용이 더 큼
리팩토링 (구조 전체 재파악 필요)오퍼스 5높음함수 호출 관계·값 흐름을 넓게 봐야 함
글쓰기 (블로그, 이메일, 정리글)소넷-톤·리듬이 관건, 빠른 초안 다회 생성이 유리
근거 기반 논증형 글오퍼스-사실상 추론 작업으로 분류
결제/정산울트라씽크 + 페이블최고오류 시 되돌릴 수 없음, 경우의 수 곱셈적 증가
크롤링 등에서 거부당한 경우오퍼스 4.6 (전환)-판단 정확·속도 좋고 거부가 적음
처음 만지는 코드베이스 (임시)오퍼스 5높음스킬·맥락 부재로 인한 임시 처방, 이후 낮춤
원인 불명 버그오퍼스 5높음가설 다수 수립 후 소거하는 추론 작업

06활용 시나리오

  1. 1인 개발자/바이브 코더: 평소 작업은 오퍼스 5 + 중간 추론으로 고정해두고, 복잡한 리팩토링이나 다중 조건 버그 수정 같은 특정 상황에서만 추론 강도를 상향해, 매번 모델을 고민하는 시간 낭비를 없애고 반복 작업에서 토큰 비용을 절감할 수 있다.
  2. 크롤링/자동화 스크립트 운영자: 특정 사이트에서 로봇 배제 규칙 등을 이유로 작업이 거부될 때, 프롬프트를 반복 수정하기보다 먼저 오퍼스 4.6 같은 다른 모델 버전으로 전환해보는 것을 1차 대응으로 시도할 수 있다.
  3. 결제/정산 시스템을 다루는 개발팀: 환불·중복 요청·통화 반올림·정산 주기처럼 되돌릴 수 없는 고위험 로직에는 예외적으로 최고 사양 모델·최고 추론 강도를 배정하는 티어링 정책을 명문화해, 팀 전체의 AI 자원 배분 기준으로 삼을 수 있다.
  4. 콘텐츠 제작자/블로거: 초안 작성은 소넷급 빠른 모델로 여러 번 반복 생성하고, 사실 검증이 중요한 숫자·고유명사만 별도로 사람이 직접 확인하는 프로세스를 도입해 속도와 정확성의 균형을 잡을 수 있다.

07현황 및 전망

화자는 자신이 제시한 기준을 "정답"이 아닌 "본인이 실제로 쓰면서 정한 기준"이라 명시하며, 처음 만지는 코드베이스나 원인 불명 버그처럼 기준이 들어맞지 않는 예외 상황에서는 기본값에서 벗어나 유연하게 대응해야 한다고 강조한다. 전체 메시지의 핵심은 "모델 선택보다 스킬(작업 지침 문서화)이 결과에 훨씬 크게 작용한다"는 것으로, 화자는 본인이 사용하는 스킬들(영상 제작, 광고 운영, 글쓰기, 업로드 자동화)을 직접 만들어 스킬샵에서 판매 중이라고 밝혔다. 이는 향후 개인 크리에이터·개발자 사이에서 모델 그레이드 선택보다 "재사용 가능한 작업 지침(스킬) 라이브러리 구축"이 생산성 격차를 가르는 더 중요한 변수로 부상할 가능성을 시사한다.

08용어 사전

용어한줄설명비유
스킬 (Skill)특정 작업의 순서·규칙·함정·검증 방법을 미리 문서화해 모델에 제공하는 지침 파일신입에게 매번 구두 설명하는 대신 건네는 업무 매뉴얼
추론 강도 (Reasoning effort)모델이 답을 내기 전 내부적으로 얼마나 깊이/오래 생각하는지를 조절하는 설정값문제를 풀 때 암산으로 빨리 끝낼지, 종이에 풀이 과정을 다 적어가며 풀지 정하는 것
오퍼스 4.6 / 오퍼스 5같은 오퍼스 계열이지만 버전이 다른 모델로, 최신 버전(5)이 항상 모든 면에서 우월한 것은 아니며 거부 성향 등에서 차이가 남같은 차종의 구형·신형 모델처럼 신형이 최신이지만 특정 상황(오프로드 등)엔 구형이 더 잘 맞는 경우
페이블 (Fable)영상에서 언급되는 최상위/특수 목적 모델 티어로, 평소엔 안 쓰고 결제·정산처럼 고위험 작업에만 투입평소엔 안 꺼내는 비상용 최고급 장비
로봇 배제 규칙 (robots.txt)웹사이트가 크롤러(자동 수집 프로그램)에게 수집 허용/차단 범위를 알리는 규약 파일건물 입구에 붙은 "관계자 외 출입금지" 안내판
메이커 에반 · 2026-08-23
← 목록으로