Claude와 경쟁 생태계

이 책을 여기까지 읽었다면, 이제 질문은 'Claude가 좋은가?'가 아니다. 더 정확한 질문은 '어떤 일에는 Claude가 맞고, 어떤 일에는 다른 선택지가 더 나은가?'이다.

AI 도구를 고르는 일은 노트북을 고르는 일과 닮았다. 가장 비싼 노트북이 모든 사람에게 가장 좋은 노트북은 아니다. 영상 편집자는 GPU와 화면을 보고, 개발자는 키보드와 메모리를 보고, 회계팀은 보안과 관리 기능을 본다. 대규모 언어 모델도 마찬가지다. 어떤 모델은 범용 생산성에서 강하고, 어떤 모델은 장문맥과 멀티모달에서 강하며, 어떤 모델은 조직이 직접 배포하고 고칠 수 있다는 점에서 강하다.

Claude는 이 생태계 안에서 분명한 성격을 가진다. 이 책이 계속 강조해 온 것처럼 Claude의 강점은 단순히 '말을 잘한다'가 아니다. 문서를 읽고, 지시를 오래 유지하고, 도구를 신중하게 쓰고, 평가와 운영 절차 안에 들어왔을 때 빛난다. Anthropic의 공식 학습 자료가 Messages API, 배치 처리, prompt caching, Admin API, Files API, PDF, MCP, Claude Code, tool use, evals, vision 같은 항목을 하나의 개발 학습 경로 안에 묶어 두는 것도 같은 이유다.¹

마지막 장에서는 Claude를 ChatGPT, Gemini, Llama와 나란히 놓고 본다. 목적은 승자를 뽑는 것이 아니다. 실무에서 가장 위험한 선택은 특정 모델을 신앙처럼 믿는 것이다. 반대로 가장 강한 선택은 업무, 데이터, 비용, 위험, 조직 역량에 맞춰 모델을 고르고, 필요하면 여러 모델을 함께 쓰는 것이다.

비교의 출발점은 모델명이 아니라 작업이다

모델 비교 글을 읽다 보면 늘 비슷한 장면이 나온다. 어떤 모델이 수학 벤치마크에서 이겼고, 어떤 모델이 코딩 테스트에서 앞섰고, 어떤 모델이 멀티모달 점수에서 높다는 식이다. 이런 정보는 쓸모가 있지만, 그것만으로는 부족하다. 벤치마크는 지도이지 목적지가 아니다.

실무에서 모델을 고를 때는 먼저 작업을 정의해야 한다. '우리 회사에 가장 좋은 모델'이라는 질문은 너무 크다. 대신 '고객지원 답변 초안을 만들 때 가장 좋은 모델', '계약서 200쪽을 읽고 위험 조항을 찾을 때 가장 좋은 모델', '사내 서버에서 개인정보를 밖으로 내보내지 않고 분류할 때 가장 좋은 모델'처럼 질문을 좁혀야 한다.

다음 표는 이 장 전체를 읽는 기준점이다.

이 기준을 기억하면 비교가 훨씬 선명해진다. Claude, ChatGPT, Gemini, Llama는 같은 문제를 푸는 네 가지 계산기가 아니다. 서로 다른 철학을 가진 네 가지 작업 환경이다.

ChatGPT와 Claude: 범용 생산성의 넓이와 신중한 작업의 깊이

ChatGPT는 많은 사람에게 생성형 AI의 첫 경험이었다. 그래서 'AI에게 묻는다'는 행동 자체가 ChatGPT의 사용법을 기준으로 형성된 경우가 많다. 일상적인 질문, 아이디어 발상, 초안 작성, 코드 설명, 이미지·음성·도구 연동, 다양한 플러그인과 앱 생태계까지 범용 생산성의 폭이 넓다. 개인 사용자가 이것저것 해 보고 싶은 상황에서는 이 넓이가 큰 장점이다.

Claude는 다른 종류의 편안함을 준다. Claude의 장점은 화려한 기능의 개수보다 긴 작업을 안정적으로 붙잡는 능력에서 드러난다. 문서의 논리 구조를 다듬고, 여러 제약을 동시에 지키며, 문체를 과하게 튀지 않게 유지하고, 불확실한 내용에는 조심스럽게 표시하는 식의 작업에서 특히 좋다. 이 책의 앞 장들이 프롬프트, 컨텍스트, 도구, 평가, 보안, 운영을 계속 강조한 이유도 여기에 있다. Claude는 단발성 재치보다 반복 가능한 업무 품질을 만들 때 가치가 커진다.

가장 중요한 차이 중 하나는 맞춤화의 철학이다. 공개 문서 기준으로 Claude API는 일반적인 self-service fine-tuning을 제공하지 않는다고 안내되어 있다.² 따라서 Claude 중심의 개선 전략은 모델 가중치를 바꾸는 것보다 프롬프트 설계, 예시 제공, RAG, 도구 사용, 구조화 출력, 평가셋, 운영 모니터링에 집중한다. 반면 OpenAI는 지원 모델을 대상으로 supervised fine-tuning 문서를 제공한다.³ 특정 형식, 특정 말투, 특정 분류 작업을 반복적으로 처리해야 하는 팀이라면 이 차이는 실제 아키텍처 선택에 영향을 준다.

그렇다고 fine-tuning이 언제나 우월한 것은 아니다. 많은 팀이 '우리 문서를 학습시켜야 한다'고 말하지만, 사실 지식 주입에는 RAG가 더 적합한 경우가 많다. 문서는 바뀌고, 계약 조항은 개정되고, 제품 정책은 매달 업데이트된다. 이때 모델을 계속 다시 학습시키는 것보다 최신 문서를 검색해 컨텍스트로 넣고, 답변 근거를 남기는 편이 더 안전하고 감사하기 쉽다. Claude가 잘 맞는 환경은 바로 이런 쪽이다. 모델을 개조하기보다, 모델 주변의 업무 흐름을 정교하게 설계하는 쪽이다.

엔터프라이즈 프라이버시에서도 둘은 모두 진지한 선택지다. OpenAI는 ChatGPT Business, ChatGPT Enterprise, API Platform을 대상으로 기업 프라이버시와 보안 약속을 공개하고 있다.⁴ Claude 역시 앞 장에서 본 것처럼 보존 정책, ZDR, Admin API, Compliance API, 데이터 레지던시 같은 주제가 도입 검토의 중심에 놓인다. 어느 쪽이 더 안전하다고 단순 판정하기보다, 실제 계약 조건과 기능별 데이터 흐름을 비교해야 한다.

실무적으로는 이렇게 판단하면 된다.

간단히 말하면 ChatGPT는 '넓게 잘하는 범용 작업실'에 가깝고, Claude는 '문서와 판단을 차분히 다루는 전문 편집실'에 가깝다. 물론 두 작업실 모두 계속 진화한다. 그래서 최종 판단은 모델 브랜드가 아니라 여러분의 평가셋에서 내려야 한다.

Gemini와 Claude: 장문맥과 Google 생태계, 그리고 문서형 판단

Gemini를 이야기할 때 가장 먼저 나오는 단어는 장문맥과 멀티모달이다. Google의 Gemini 문서는 긴 컨텍스트가 단순히 많은 텍스트를 넣는 기능이 아니라, 대규모 텍스트, 코드, 오디오, 영상, 이미지까지 한 번에 다루는 새로운 작업 방식을 열어 준다고 설명한다.⁵ Google Workspace와 Google Cloud에 깊이 들어가 있는 조직이라면 이 장점은 더 커진다. Gmail, Docs, Sheets, Drive, Vertex AI, BigQuery 같은 환경과 모델을 붙이는 일이 자연스럽기 때문이다.

Claude도 긴 문서 처리에 강하지만, Gemini의 강점은 특히 '형식이 섞인 대량 자료'에서 도드라진다. 예를 들어 제품팀이 고객 인터뷰 영상, 회의 녹취, 설문 스프레드시트, 슬라이드 이미지, 제품 로그 설명서를 함께 분석해야 한다고 하자. 이 작업은 단순한 텍스트 요약이 아니다. 말, 표, 장면, 문서가 얽혀 있다. 이런 상황에서는 Gemini의 멀티모달·Google 생태계 결합이 설계 비용을 낮출 수 있다.

또 하나의 실용적 차이는 Batch API다. Google은 Gemini API의 Batch Mode를 통해 지연 시간이 중요하지 않은 대량 작업을 비동기로 처리하고, 표준 동기 API 대비 할인된 비용과 높은 처리량을 제공한다고 설명한다.⁶ 평가셋 수만 개를 돌리거나, 대량 문서를 분류하거나, 영상 광고를 한꺼번에 라벨링하는 작업이라면 이 구조가 매력적이다.

그렇다면 Gemini가 장문맥과 멀티모달에서 강하니 Claude는 불리한가? 꼭 그렇지는 않다. 실무에서 중요한 것은 '많이 넣을 수 있는가'와 '넣은 뒤 무엇을 안정적으로 할 수 있는가'가 다르다는 점이다. 컨텍스트 창이 아무리 커도 답변이 조직의 정책과 맞지 않거나, 근거 표시가 부실하거나, 후속 검토 절차에 들어가지 못하면 운영 시스템으로는 부족하다. Claude는 긴 문서를 바탕으로 조심스럽게 논리를 세우고, 출력 형식을 지키고, 도구·평가·거버넌스 흐름에 들어가는 작업에서 여전히 강한 선택지다.

Gemini와 Claude의 차이는 다음처럼 정리할 수 있다.

예를 들어 학교가 수천 시간의 강의 영상을 분석해 주제별 색인을 만들고 싶다면 Gemini가 더 자연스러울 수 있다. 반대로 법무팀이 계약서 묶음을 읽고 위험 조항, 근거 문장, 수정 제안, 검토 필요 플래그를 일관된 형식으로 남겨야 한다면 Claude가 더 잘 맞을 가능성이 높다. 두 작업 모두 '긴 자료를 읽는다'는 말로 표현되지만, 실제 품질 기준은 전혀 다르다.

Llama와 Claude: 소유하는 모델과 관리형 프런티어 스택

Llama는 ChatGPT나 Claude, Gemini와 결이 다르다. Llama의 핵심은 '내가 모델을 소유하고 배포할 수 있다'는 점이다. Meta는 Llama를 오픈소스 AI 모델 생태계로 소개하며, 배포 용이성, 비용 효율, 성능, 멀티모달, 추론, 긴 컨텍스트 같은 방향을 강조한다.⁷ 공식 Llama Cookbook 역시 Llama 모델군으로 inference, fine-tuning, end-to-end use case를 구축하는 자료를 제공한다.⁸

이 차이는 단순한 취향 문제가 아니다. 어떤 조직에게는 모델 가중치를 내려받아 자체 인프라에서 돌릴 수 있다는 점이 결정적이다. 병원, 금융기관, 공공기관, 방산 관련 조직처럼 데이터가 외부 API로 나가는 것 자체가 어려운 곳이 있다. 이때 Claude의 ZDR이나 계약상 보안 약속이 아무리 강해도, 법무팀의 답이 '물리적으로 밖으로 나가면 안 된다'라면 Llama 같은 오픈웨이트 모델을 검토해야 한다.

또한 Llama는 fine-tuning과 배포 자유도가 강하다. 특정 산업의 용어, 회사 내부 코드 스타일, 반복적인 분류 작업, 엣지 디바이스 추론처럼 모델 자체를 좁은 목적에 맞추고 싶다면 오픈웨이트 모델이 매력적이다. Claude에서는 이런 요구를 프롬프트, RAG, 도구, 평가, 운영 정책으로 해결하는 쪽이 본류다. Llama에서는 모델을 직접 조정하는 전략도 본류가 될 수 있다.

하지만 '오픈소스라서 싸다'는 말은 절반만 맞다. 모델 파일은 무료에 가까울 수 있지만, 프로덕션 운영은 무료가 아니다. GPU를 빌리거나 사야 하고, vLLM 같은 서빙 스택을 운영해야 하고, 장애 대응과 모니터링을 해야 하고, 모델 버전 업데이트 때마다 회귀 테스트를 해야 한다. 보안팀은 접근 제어와 로그를 봐야 하고, MLOps 팀은 지연 시간과 처리량을 잡아야 한다. Claude API를 쓰면 공급자가 맡아 주는 일을, Llama를 쓰면 여러분이 맡는다.

따라서 Claude와 Llama의 차이는 '닫힌 모델 대 열린 모델'보다 '운영 책임을 누구에게 둘 것인가'로 보는 편이 정확하다.

현실적인 결론은 하이브리드다. 민감도가 매우 높은 일부 데이터는 사내 Llama로 처리하고, 품질이 중요한 문서 작성·분석·전략 판단은 Claude로 처리하는 식이다. 모든 것을 한 모델로 해결하려는 순간 비용, 품질, 보안 중 하나가 흔들린다. 반대로 작업별로 모델을 나누면 각 모델의 장점이 살아난다.

Claude가 특히 잘 맞는 시나리오

이제 긍정문으로 정리해 보자. 어떤 경우에 Claude를 먼저 검토해야 할까?

첫째, 문서의 품질이 곧 업무 품질인 경우다. 보고서, 제안서, 정책 문서, 회의록, 계약서 검토 메모, 고객 안내문처럼 문장이 조직의 판단을 대표하는 작업에서는 단순히 빠른 초안보다 논리와 톤이 중요하다. Claude는 이런 작업에서 차분하고 긴 호흡의 답변을 만드는 경향이 강하다. 특히 앞 장에서 배운 XML 구조화, 출력 계약, 반례, 평가 루브릭을 붙이면 더 안정적이다.

둘째, 지시가 복잡하고 예외가 많은 경우다. 'A는 포함하되 B는 제외하고, 불확실한 내용은 추정하지 말고, 표에는 원문 근거를 붙이고, 마지막에는 검토 필요 항목만 따로 모아라' 같은 요청은 단순 생성이 아니라 지시 유지 능력을 요구한다. Claude의 장점은 이런 다중 제약 작업에서 잘 드러난다.

셋째, 도구 사용과 사람 검토가 함께 필요한 경우다. Claude를 계산기, 검색기, 사내 데이터베이스, 티켓 시스템, 코드 실행 환경과 연결하면 모델은 단순한 말상대가 아니라 작업 조정자가 된다. 다만 이때 중요한 것은 자율성이 아니라 통제된 자율성이다. 어떤 도구를 쓸 수 있는지, 어떤 작업은 승인 후 실행해야 하는지, 어떤 로그를 남길지 설계해야 한다. 이 책의 6장과 8장에서 다룬 tool use, MCP, 에이전트 설계가 여기서 다시 살아난다.

넷째, 평가와 회귀 테스트가 중요한 경우다. Claude를 제품에 넣는 순간 '대답이 괜찮아 보인다'로는 부족하다. 평가셋을 만들고, 성공 기준을 정하고, 모델·프롬프트·검색 인덱스·도구 스키마가 바뀔 때마다 회귀 테스트를 돌려야 한다. Claude는 Anthropic의 학습 자료와 운영 자료가 이 방향으로 잘 정리되어 있어, 실전 레퍼런스형 도입에 적합하다.

다섯째, 법무·보안·운영팀이 함께 보는 도입이다. Claude는 안전성, 정렬, 보존 정책, 컴플라이언스, Admin·Compliance API 같은 주제를 기술 도입의 주변부가 아니라 본론으로 끌어들인다. 이 책이 10장과 11장을 길게 둔 이유도 여기에 있다. 기업에서 AI는 기능보다 승인 절차가 먼저 막히는 경우가 많다. Claude는 이 장벽을 정면으로 다루기에 좋은 플랫폼이다.

Claude가 아닌 선택이 맞는 시나리오

좋은 도구를 제대로 이해하려면, 그 도구를 쓰지 말아야 할 때도 알아야 한다.

이미지 생성이나 영상 생성이 제품의 중심이라면 Claude가 1순위가 아닐 수 있다. Claude는 문서와 언어, 분석, 코딩에서 강하지만, 시각 콘텐츠 생성 자체가 핵심인 워크플로우라면 이미지·영상 생성 생태계가 강한 다른 도구가 더 자연스럽다.

Google Workspace와 Google Cloud에 깊게 묶인 조직에서, Gmail·Docs·Sheets·Drive·BigQuery·Vertex AI를 중심으로 AI 업무를 자동화하려 한다면 Gemini가 더 낮은 마찰을 줄 수 있다. 특히 영상, 오디오, 이미지, 긴 텍스트가 섞인 자료를 대량으로 처리해야 한다면 Gemini를 반드시 후보에 넣어야 한다.

모델 자체를 직접 fine-tuning해야 하는 경우에도 Claude만 고집하면 안 된다. 예를 들어 특정 콜센터의 수천만 건 대화를 바탕으로 초저지연 분류기를 만들거나, 사내 코드 스타일에 맞춘 작은 모델을 내부망에서 돌리려는 경우라면 OpenAI의 fine-tuning 지원 모델이나 Llama 계열 오픈웨이트 모델이 더 적합할 수 있다.

데이터가 절대 외부로 나갈 수 없는 경우도 마찬가지다. 계약상 보호나 ZDR이 충분한 조직도 많지만, 어떤 조직은 물리적 반출 금지가 기준이다. 이때는 Llama, Mistral, Qwen 같은 오픈 모델을 내부 인프라에 올리거나, 클라우드의 전용 배포 옵션을 검토해야 한다.

마지막으로 초대량 단순 작업에서 비용이 절대 기준인 경우다. 예를 들어 매일 수억 개의 짧은 텍스트를 분류해야 하고, 오류 비용이 낮으며, 대략적인 분류만 필요하다면 최고급 모델을 호출하는 것은 낭비일 수 있다. 이때는 저가형 모델, 배치 처리, 캐싱, 오픈소스 self-hosting, 규칙 기반 필터를 섞는 편이 더 좋은 설계다.

멀티 모델 전략: 하나를 믿지 말고 라우팅하라

2026년의 성숙한 AI 시스템은 단일 모델 시스템이 아니라 라우팅 시스템에 가깝다. 라우팅이란 요청의 성격에 따라 다른 모델이나 다른 처리 경로로 보내는 것이다. 사람 조직도 그렇게 일한다. 모든 일을 대표 변호사에게 맡기지 않는다. 간단한 서류 정리는 주니어가 하고, 위험한 계약 검토는 파트너가 하고, 숫자 검증은 회계팀이 한다.

AI 시스템도 같은 방식으로 설계할 수 있다.

라우팅의 핵심은 모델을 많이 쓰는 것이 아니라 실패 비용에 맞게 쓰는 것이다. 모든 요청을 가장 비싼 모델로 보내면 비용이 터진다. 모든 요청을 가장 싼 모델로 보내면 품질이 터진다. 좋은 시스템은 쉬운 일은 싸게, 어려운 일은 신중하게, 위험한 일은 사람에게 넘긴다.

이때 필요한 것이 9장에서 다룬 평가셋이다. 라우터가 정말 잘 작동하는지 알려면 '어려운 질문을 제대로 어려운 경로로 보냈는가', '쉬운 질문을 과도하게 비싼 모델로 보내지 않았는가', '민감 데이터가 외부 모델로 나가지 않았는가'를 측정해야 한다. 모델 선택은 구매 결정이 아니라 운영 시스템의 일부다.

2주 파일럿으로 모델을 고르는 법

모델 선택 회의에서 가장 자주 나오는 실수는 시연 영상을 보고 결정하는 것이다. 멋진 데모는 마음을 움직이지만, 여러분의 업무를 대표하지 않는다. 더 좋은 방법은 짧고 단단한 파일럿이다. 2주면 충분히 많은 것을 알 수 있다.

1주 차에는 평가셋을 만든다. 실제 업무에서 나온 문서, 질문, 오류 사례, 고객 요청, 코드 이슈를 모은다. 가능하면 50개에서 200개 정도가 좋다. 너무 적으면 우연에 흔들리고, 너무 많으면 시작이 늦어진다. 각 항목에는 기대 답변, 금지할 답변, 판단 기준, 개인정보 포함 여부, 근거 문서 링크를 붙인다.

그다음 같은 입력을 Claude, ChatGPT, Gemini, 필요한 경우 Llama 계열 모델에 넣어 본다. 이때 프롬프트는 최대한 공정하게 맞춘다. 특정 모델에만 유리한 기능을 쓰기 전에, 먼저 기본 능력을 비교한다. 이후 각 모델의 고유 기능을 켠 2차 비교를 한다. 예를 들어 Claude에는 구조화 출력과 도구 사용 설계를 붙이고, Gemini에는 긴 컨텍스트와 멀티모달 입력을 적극 활용하고, Llama에는 사내 튜닝 또는 내부 배포 조건을 반영한다.

2주 차에는 사람이 블라인드 리뷰를 한다. 답변에서 모델 이름을 가리고 업무 전문가가 점수를 매긴다. 점수 항목은 정확성, 완전성, 근거성, 형식 준수, 톤, 지연 시간, 비용, 보안 적합성으로 나눈다. 특히 '그럴듯하지만 틀린 답변'에는 높은 감점을 줘야 한다. AI 시스템에서 가장 위험한 출력은 어색한 답이 아니라 확신에 찬 오답이다.

마지막에는 '모델별 평균 점수'가 아니라 '작업별 추천 경로'를 만든다. 예를 들어 다음처럼 결론이 나와야 한다.

이런 표가 나오면 모델 선택이 논쟁에서 운영 계획으로 바뀐다. 'Claude가 더 낫다'가 아니라 '이 업무에서는 Claude를 쓰고, 이 업무에서는 Gemini를 쓰며, 이 업무는 내부 모델로 처리한다'가 된다. 이것이 성숙한 도입의 언어다.

모델명이 바뀌는 시대에 책을 읽는 법

이 책은 특정 날짜의 모델 카탈로그가 아니라, Claude와 주변 생태계를 다루는 실전 레퍼런스다. 따라서 마지막으로 중요한 것은 업데이트 방식이다. 모델명, 가격, 컨텍스트 창, 베타 기능, 보존 정책, 지원 리전, SDK 사용법은 바뀐다. 인쇄된 책이 이 변화를 모두 따라잡을 수는 없다.

그래서 이 책을 읽을 때는 세 층을 구분해야 한다.

첫 번째 층은 오래 가는 원리다. 좋은 프롬프트는 목표, 맥락, 제약, 출력 형식을 분리한다. RAG는 지식 주입을 모델 학습이 아니라 검색과 근거 연결의 문제로 바꾼다. 평가셋은 감이 아니라 회귀 테스트로 품질을 관리하게 해 준다. 보안 검토는 '모델이 안전한가'보다 '어떤 데이터가 어디로 가는가'에서 시작한다. 이런 원리는 모델명이 바뀌어도 쉽게 낡지 않는다.

두 번째 층은 바뀌는 기능이다. structured outputs, citations, prompt caching, batch processing, extended thinking, memory, data residency, MCP, Claude Code 기능은 계속 변한다. 이 층은 동반 웹사이트와 실습 노트북에서 최신 상태를 확인해야 한다. 책의 본문은 왜 그런 기능이 필요한지 설명하고, 웹사이트는 현재 어떤 이름과 파라미터로 쓰는지 알려 주는 역할을 맡는다.

세 번째 층은 여러분의 조직별 판단이다. 어떤 모델이 최고인지보다, 여러분의 데이터와 업무에서 어떤 모델이 실패를 덜 하는지가 중요하다. 따라서 책의 예제를 그대로 끝내지 말고, 반드시 사내 평가셋으로 바꿔 돌려야 한다. 실습 노트북도 샘플 데이터를 지우고 여러분의 실제 문서, 실제 질문, 실제 오류 사례를 넣을 때 가치가 생긴다.

동반 웹사이트를 운영한다면 최소한 다음 항목은 계속 갱신해야 한다.

실습 노트북은 더 엄격하게 관리해야 한다. 실행 날짜, 모델 ID, 프롬프트 버전, 검색 인덱스 버전, 도구 스키마, 파라미터, 평가셋 해시를 남겨야 한다. 그래야 6개월 뒤 결과가 달라졌을 때 '모델이 바뀐 것인지, 프롬프트가 바뀐 것인지, 검색 데이터가 바뀐 것인지'를 알 수 있다.

마지막 선택표

이제 이 책의 마지막 선택표를 남기자. 절대적인 답은 아니지만, 첫 의사결정 회의에서 유용한 출발점이 될 것이다.

Claude를 사랑해서 Claude를 쓰는 것은 나쁜 출발은 아니다. 하지만 운영자는 사랑만으로 시스템을 만들 수 없다. 운영자는 실패 비용을 계산하고, 데이터 흐름을 그리고, 평가셋을 만들고, 법무팀의 질문에 답하고, 장애가 났을 때 되돌릴 수 있어야 한다.

이 책의 결론은 단순하다. Claude는 강력한 선택지다. 특히 신뢰성, 문서 작업, 도구 사용, 평가, 거버넌스가 중요한 환경에서 그렇다. 그러나 Claude가 모든 문제의 답은 아니다. 어떤 문제에는 ChatGPT가 더 빠르고 넓다. 어떤 문제에는 Gemini가 더 자연스럽다. 어떤 문제에는 Llama를 직접 운영하는 편이 유일한 답이다.

성숙한 Claude 사용자는 Claude만 쓰는 사람이 아니다. Claude가 빛나는 자리를 알고, Claude가 아닌 선택이 맞는 자리도 인정하며, 그 판단을 평가와 운영 절차로 증명하는 사람이다.

이제 여러분에게 필요한 것은 더 많은 프롬프트가 아니라 더 좋은 판단 체계다. 이 책이 그 판단 체계의 시작점이 되기를 바란다.

참고

¹Anthropic Academy: Claude API Development Guide

²Claude API Docs Glossary

³OpenAI API Supervised fine-tuning

⁴Enterprise privacy at OpenAI

⁵Long context - Gemini API

⁶Batch Mode in the Gemini API

⁷Industry Leading, Open-Source AI - Llama