에이븐스튜디오

Claude Code로 큰 작업을 시키다 보면 컨텍스트가 금방 지저분해진다. 코드베이스를 뒤지느라 읽어들인 파일 수십 개가 대화에 쌓이면, 정작 구현 단계에서 중요한 내용이 밀려나고 품질이 떨어진다. 이 문제를 구조적으로 푸는 기능이 서브에이전트(subagent) 다. 이번 글에서는 서브에이전트가 뭔지, 어떻게 만드는지, 그리고 조사→구현→검증으로 역할을 나누는 실전 구성을 실제 사용 순서대로 정리한다. 서브에이전트가 뭔가 — 작업 위임 개념 서브에이전트는 메인 대화와 분리된 별도 컨텍스트 에서 도는 보조 에이전트다. 메인 에이전트가 "이 조사를 해 와라"고 위임하면, 서브에이전트는 자기만의 깨끗한 컨텍스트에서 파일을 뒤지고 작업한 뒤 결과 요약만 메인에 보고한다. 중간에 읽은 파일 내용 수만 토큰은 서브에이전트 컨텍스트에서 소비되고 버려진다. 메인 대화는 결론만 받으니 깨끗하게 유지된다. 포인트는 세 가지다. 첫째, 컨텍스트가 독립이라 메인 대화가 오염되지 않는다. 둘째, 에이전트마다 시스템 프롬프트·허용 도구·모델을 다르게 지정할 수 있어 역할을 강제할 수 있다. 셋째, 독립적인 작업이라면 여러 서브에이전트를 병렬로 돌릴 수 있다. 만드는 법 — 파일 하나가 에이전트 하나 서브에이전트는 마크다운 파일로 정의한다. 프로젝트 전용이면 .claude/agents/ 폴더에, 모든 프로젝트에서 쓰려면 홈 디렉터리의 ~/.claude/agents/ 에 둔다. Claude Code 안에서 /agents 명령을 쓰면 대화형으로 만들 수도 있는데, 구조를 이해하려면 한 번은 손으로 써 보는 것이 좋다. 파일 형식은 YAML 프런트매터 + 본문이다. 예를 들어 코드 리뷰 담당은 이렇게 만든다. .claude/agents/code-reviewer.md : --- name: code-reviewer description: 코드 변경 직후 품질·버그·보안 관점 리뷰를 수행한다. 코드를 수정한 뒤에는 반드시 이 에이전트를 사용할...

로컬 LLM을 터미널에서 ollama run 으로만 쓰다 보면 아쉬워지는 순간이 온다. 직접 만드는 앱에서 부르고 싶고, 같은 집 안의 노트북에서도 데스크톱의 GPU를 빌려 쓰고 싶어진다. 다행히 Ollama는 설치하는 순간부터 이미 API 서버다. 별도 프레임워크 없이 로컬 모델을 OpenAI 호환 엔드포인트로 노출해서 여러 앱이 공용으로 쓰는 구성을, 실제로 세팅한 순서대로 정리한다. 1. 왜 API 서버로 띄우나 이유는 세 가지다. 첫째, 모델과 앱의 분리 다. 무거운 모델은 GPU가 있는 데스크톱 한 대에만 두고, 앱·스크립트·노트북은 가볍게 API만 호출하면 된다. 둘째, 코드 재사용 이다. OpenAI 호환 형식을 쓰면 이미 세상에 널린 OpenAI SDK 기반 코드, 각종 코딩 도구, 챗 UI를 주소만 바꿔 그대로 물릴 수 있다. 셋째, 모델 교체가 앱에 영향을 주지 않는다 . 서버 쪽에서 모델을 바꿔도 클라이언트 코드는 모델명 문자열 하나만 다르다. 2. 이미 떠 있는 서버 — 11434 포트 확인 Ollama를 설치하면 백그라운드에서 http://localhost:11434 에 HTTP 서버가 항상 떠 있다. 브라우저나 curl로 바로 확인할 수 있다. curl http://localhost:11434 # Ollama is running Ollama 고유 API는 /api/chat 같은 경로를 쓰지만, 이 글의 주인공은 공식 문서 기준으로 제공되는 OpenAI 호환 경로다. 베이스 URL이 http://localhost:11434/v1 이고, 채팅은 /v1/chat/completions 로 받는다. curl http://localhost:11434/v1/chat/completions ` -H "Content-Type: application/json" ` -d '{ "model": "gemma3:4b", "messages": ...

"Gemini와 Claude 중 코딩에는 뭐가 낫나"는 질문을 자주 받는다. 그런데 인터넷의 비교 글 대부분은 남의 벤치마크 숫자를 옮긴 것이라, 정작 내 프로젝트·내 언어·내 코드 스타일에서는 결과가 다르게 나오는 경우가 많다. 벤치마크 점수는 모델이 업데이트될 때마다 뒤집히지만, 비교하는 방법 은 오래 간다. 이번 글에서는 두 모델을 내 작업 기준으로 직접 실측 비교하는 절차를 정리하고, 공개 자료로 알려진 각 모델의 경향을 함께 짚는다. 이 글에는 지어낸 점수표가 없다. 대신 따라 하면 내 점수표가 나오는 절차를 적는다. 비교 방법 — 같은 프롬프트, 같은 작업, 같은 채점 기준 공정한 비교의 조건은 세 가지다. 프롬프트를 고정하고, 작업을 고정하고, 채점 기준을 실행 전에 정하는 것이다. 하나라도 흔들리면 "내가 더 정 들인 쪽"이 이기는 비교가 된다. 프롬프트 고정 : 지시문을 텍스트 파일로 저장해 두고 두 모델에 그대로 복사해 넣는다. 한쪽이 잘못 이해해도 추가 힌트를 주지 않는다. 힌트를 주는 순간 조건이 달라진다. 작업 3~4종 준비 : 유형이 다른 작업을 섞는다. 아래에서 설명한다. 채점 기준 고정 : "테스트 통과 여부"처럼 기계적으로 판정할 수 있는 기준을 우선한다. 결과 기록 : 소요 시간, 토큰 사용량, 시도 횟수를 표로 남긴다. 작업 3종 설계 — 버그 수정 / 리팩터링 / 신규 구현 실무 코딩은 성격이 다른 작업의 묶음이라서, 한 종류만 테스트하면 반쪽짜리 비교가 된다. 내가 쓰는 구성은 이렇다. ① 버그 수정 실제로 겪었던 버그를 재현한 코드를 준비한다. 실패하는 테스트 케이스를 함께 만들어 두면 채점이 자동화된다. "이 테스트가 통과하도록 고쳐라"라고만 지시하고, 몇 번 만에 통과시키는지, 버그의 원인을 정확히 짚는지, 관계없는 코드까지 건드리는지를 본다. ② 리팩터링 동작은 하지만 지저분한 함수 하나를 골라 "동작을...

Vertex AI로 LLM을 쓰기 시작하면 매달 "이번 달 AI에 얼마 썼지?"를 확인하는 일이 은근히 번거로워진다. 결제 콘솔을 열고 기간을 바꾸고 필터를 거는 일을 매번 반복하게 되기 때문이다. 결제 데이터를 BigQuery로 내보내 두면 이 과정을 SQL 한 번으로 끝낼 수 있고, 예약 쿼리를 걸면 월별 리포트가 자동으로 쌓인다. 실제로 세팅한 순서 그대로 정리한다. 1단계 — 결제 데이터 BigQuery 내보내기 설정 먼저 결제 데이터가 흘러 들어올 자리를 만들고 내보내기를 켠다. BigQuery 콘솔에서 데이터셋을 하나 만든다(예: billing_export ). 위치(리전)는 한번 정하면 바꾸기 어려우니 신중히 고른다. 결제 콘솔에서 결제(Billing) → 결제 데이터 내보내기(Billing export) 메뉴로 이동한다. 결제 계정 관리 권한이 필요하다. 표준 사용량 비용(Standard usage cost) 항목에서 설정 수정을 눌러 프로젝트와 방금 만든 데이터셋을 지정하고 저장한다. 몇 시간 뒤 데이터셋에 테이블이 생겼는지 확인한다. 한 가지를 꼭 기억해야 한다. 내보내기는 설정한 시점 이후의 데이터만 쌓인다. 과거 청구 내역은 소급 적재되지 않으므로(공식 문서 기준), 리포트가 당장 필요 없더라도 내보내기만큼은 지금 바로 켜 두는 것이 좋다. 첫 데이터가 보이기까지는 몇 시간 정도 걸릴 수 있다. 내보내기 종류는 세 가지다. 표준 내보내기는 gcp_billing_export_v1_결제계정ID 이름의 테이블로 서비스·SKU 단위 비용이 쌓이고, 상세 내보내기( gcp_billing_export_resource_v1_... )는 리소스 단위까지 내려가는 대신 용량이 크다. 가격 내보내기( cloud_pricing_export )는 단가표라서 비용 집계와는 용도가 다르다. 월별 AI 비용 리포트 목적이라면 표준 내보내기로 충분하다. 2단계 — 모델별 비용 집계 쿼리 테이블에서 주로 쓰는 필드는...

로컬 LLM은 인터넷 없이도 돌아가는 대신, 내 컴퓨터에 있는 문서의 내용은 전혀 모른다. 회사 매뉴얼, 개인 메모, 프로젝트 문서를 근거로 답하게 만들려면 RAG(Retrieval-Augmented Generation)를 붙여야 한다. 이전에 쓴 "로컬 LLM 제대로 활용하는 법" 글에서 RAG를 개념으로만 소개했는데, 이 글은 그 심화 실전편으로 실제 코드를 한 줄씩 따라가며 로컬 RAG 파이프라인을 완성한다. 필요한 것은 Ollama가 설치된 PC와 파이썬뿐이고, 전 과정이 내 컴퓨터 안에서만 돌기 때문에 문서가 외부로 나가지 않는다. 1. RAG 개념 — 검색해서 건네주고, 읽고 답하게 한다 RAG의 원리는 생각보다 단순하다. 모델에게 문서 전체를 통째로 외우게 하는 게 아니라, 질문이 들어올 때마다 관련 문서 조각을 검색해서 프롬프트에 끼워 넣는 것 이다. 흐름은 두 단계로 나뉜다. 인덱싱(한 번만) : 문서를 적당한 크기로 자르고(청킹), 각 조각을 숫자 벡터로 바꿔(임베딩) 벡터DB에 저장한다. 질의(질문할 때마다) : 질문도 같은 방식으로 벡터로 바꾼 뒤, 벡터DB에서 가장 비슷한 조각을 찾아 질문과 함께 모델에 넘긴다. 2. 준비물 — 임베딩 모델과 벡터DB 생성 모델(Gemma)은 이미 있다고 치고, 추가로 두 가지가 필요하다. 첫째는 텍스트를 벡터로 바꿔 주는 임베딩 전용 모델, 둘째는 벡터를 저장하고 유사도 검색을 해 주는 벡터DB다. 임베딩 모델은 Ollama에서 바로 받을 수 있다. ollama pull embeddinggemma pip install ollama chromadb 임베딩 모델로 가장 널리 쓰이는 것은 nomic-embed-text지만, 한국어 문서가 많다면 다국어를 지원하는 embeddinggemma나 bge-m3가 결과가 낫다. 하나 주의할 점은 인덱싱할 때 쓴 임베딩 모델과 질문을 벡터로 바꿀 때 쓰는 모델이 반드시 같아야 한다 는 것이다. 모델마다 벡터 공간이 다르...

Claude를 쓰다 보면 "내 컴퓨터의 파일을 읽게 하고 싶다", "우리 회사 DB를 조회하게 하고 싶다"는 순간이 온다. 이걸 표준 방식으로 해결하는 것이 MCP(Model Context Protocol)다. 이번 글에서는 도구 1개짜리 최소 MCP 서버를 파이썬으로 직접 만들고, Claude Desktop과 Claude Code에 연결해 실제로 동작시키는 과정을 순서대로 정리한다. 전체 코드는 15줄이 안 된다. MCP가 뭔가 — 모델과 도구를 잇는 프로토콜 MCP는 AI 모델(정확히는 Claude 같은 클라이언트 앱)과 외부 도구·데이터를 연결하는 표준 규격이다. 예전에는 앱마다 플러그인 방식이 제각각이라 같은 기능을 여러 번 만들어야 했는데, MCP는 "도구 목록을 알려주는 방법"과 "도구를 호출하고 결과를 돌려받는 방법"을 표준으로 정해 두었다. 그래서 MCP 서버를 하나 만들면 Claude Desktop, Claude Code 등 MCP를 지원하는 여러 클라이언트에 같은 서버를 꽂아 쓸 수 있다. 구조는 단순하다. Claude가 클라이언트 , 내가 만드는 프로그램이 서버 다. 서버는 "나는 이런 도구를 갖고 있다"고 목록을 알려주고, 모델이 대화 중 필요하다고 판단하면 도구를 호출한다. 서버는 요청을 실행해 결과를 돌려주고, 모델은 그 결과를 바탕으로 답을 이어간다. 준비물과 최소 서버 골격 파이썬 공식 SDK를 쓴다. SDK에 포함된 FastMCP 클래스를 쓰면 데코레이터 하나로 도구를 등록할 수 있다. 파이썬 3.10 이상이 필요하다. 작업 폴더를 하나 만든다. 예: C:\work\mcp-memo 터미널에서 SDK를 설치한다. pip install "mcp[cli]" 그리고 server.py 파일을 만든다. 아래가 전체 코드다. "메모를 파일에 저장하는" 도구 하나만 가진 서버다. from ...

Flutter 앱에 AI 채팅 기능을 넣고 싶어서 Claude API를 연동해 봤다. 처음에는 "그냥 http로 API 호출하면 되겠지" 하고 가볍게 시작했는데, 막상 해보니 API 키를 어디에 둘 것인가 라는 보안 문제와 스트리밍 응답 처리 라는 두 개의 산이 있었다. 이 글에서는 실제로 구현한 순서 그대로, 아키텍처 설계부터 기본 요청, 채팅 UI, SSE 스트리밍, 에러 처리까지 정리한다. 1. 아키텍처 — 앱이 API 키를 직접 들면 안 되는 이유 코드를 한 줄 쓰기 전에 이것부터 짚고 가야 한다. 가장 흔한 실수가 Anthropic API 키를 Dart 코드에 상수로 박아 넣고 앱에서 직접 API를 호출하는 구조다. 이 구조는 절대 배포하면 안 된다. 이유는 명확하다. APK/AAB는 누구나 다운로드해서 디컴파일할 수 있다. 문자열 상수로 들어간 API 키는 strings 명령 한 번이면 그대로 노출된다. --dart-define 이나 .env 파일로 주입해도 마찬가지다. 빌드 결과물 안에 키가 들어가는 순간 "숨긴 것"이지 "보호한 것"이 아니다. 키가 유출되면 내 계정으로 과금이 발생한다. 종량제 API 특성상 피해 상한이 없다. 그래서 정석은 프록시 서버 경유 다. 앱은 내 서버에만 요청을 보내고, API 키는 서버 환경변수에만 존재한다. 서버는 Cloud Run이나 Cloud Functions 같은 서버리스로 띄우면 요청이 없을 때 비용이 거의 들지 않는다. 프록시 서버에는 최소한 다음을 넣는다. 앱 사용자 인증 확인 (Firebase Auth 토큰 검증 등) 사용량 제한 (사용자당 하루 N회 같은 상한) Claude API 호출 후 응답 중계 이 글의 코드 예제는 개발 단계에서 구조를 이해하기 위한 것이고, 실제 배포 시에는 요청 URL만 내 프록시 서버 주소로 바꾸면 되도록 짜 두는 것이 좋다. 2. 기본 요청/응답 —...

Ollama로 로컬 LLM을 쓰기 시작하면 모델이 하나로 끝나지 않는다. 코딩 질문용으로 하나, 요약용으로 하나, RAG를 해보겠다고 임베딩 모델까지 받다 보면 어느새 대여섯 개가 쌓인다. 문제는 이때부터다. 디스크가 수십 GB씩 사라지고, 모델을 바꿔 부를 때마다 그래픽 메모리(VRAM)에서 로드와 언로드가 반복되면서 응답이 느려진다. 이 글에서는 모델을 여러 개 굴리면서 실제로 겪은 문제와, 그걸 정리하는 명령·설정을 순서대로 짚는다. 1. 모델을 여러 개 받으면 생기는 문제 먼저 무엇이 문제인지부터 분명히 해두자. 두 가지다. 디스크 : 모델 파일은 한 개당 수 GB에서 수십 GB다. 4B급 양자화 모델도 3GB 안팎, 27B급이면 15GB를 훌쩍 넘는다. 서너 개만 받아도 SSD가 순식간에 줄어든다. VRAM : 추론을 하려면 모델이 그래픽 메모리에 올라와야 한다. VRAM 8GB 환경에서 4B급 모델 하나를 올리면 여유가 많지 않다. 다른 모델을 부르면 기존 모델을 내리고 새로 올리는 스와핑이 일어나는데, 이때 수 초에서 수십 초의 로딩 지연이 생긴다. 즉 관리의 핵심은 "디스크에 뭐가 있는지"와 "메모리에 뭐가 올라와 있는지"를 구분해서 보는 것이다. Ollama는 이 둘을 각각 다른 명령으로 보여준다. 2. ollama list와 ollama ps — 뭐가 있고 뭐가 올라와 있나 디스크에 받아 둔 모델 목록은 ollama list 로 본다. ollama list NAME SIZE MODIFIED gemma3:4b 3.3 GB 2 weeks ago qwen2.5-coder:7b 4.7 GB 5 days ago embeddinggemma:latest 621 MB 3 days ago 반면 지금 이 순간 메모리에 올라와 있는 모델은 ollama ps 로 확인한다. 출력에는 모델이 언제까지 메...

Claude를 쓰는 방법은 Anthropic에 직접 API 키를 발급받는 것만 있는 게 아니다. 이미 GCP를 쓰고 있다면 Vertex AI를 통해 같은 모델을 호출할 수 있다. 결제가 GCP로 통합되고 인증도 IAM으로 처리되기 때문에, 프로젝트가 GCP 위에 있다면 오히려 이쪽이 관리가 깔끔하다. 이 글에서는 Model Garden에서 Claude 모델을 활성화하고 Python으로 첫 응답을 받아보기까지의 과정을 실제 셋업 순서 그대로 정리한다. 왜 Vertex를 거쳐 Claude를 쓰나 — 직접 API와의 차이 기능적으로 모델 자체는 같다. 차이는 호출 경로와 운영 방식에 있다. 직접 API는 Anthropic 콘솔에서 키를 발급받아 별도 결제 수단으로 쓰는 구조이고, Vertex AI 경유는 GCP 프로젝트의 IAM 권한으로 인증하고 비용도 GCP 청구서에 합산되는 구조다. 공식 문서 기준 토큰 단가는 양쪽이 동일하다. 정리하면 이렇다. API 키를 코드나 서버에 심지 않고 서비스 계정 권한으로 처리하고 싶을 때, 비용을 GCP 결제 하나로 모아 보고 싶을 때, 감사 로그나 조직 정책 같은 GCP 거버넌스를 그대로 적용하고 싶을 때 Vertex 경유가 유리하다. 반대로 최신 기능이 가장 먼저 열리는 곳은 보통 직접 API 쪽이라는 점은 감안해야 한다. Model Garden에서 Claude 모델 활성화 사전 준비부터 첫 활성화까지의 순서다. 결제 계정이 연결된 GCP 프로젝트를 준비한다. Vertex AI API를 활성화한다. 콘솔에서 해도 되고 아래처럼 명령으로 해도 된다. 콘솔에서 Vertex AI → Model Garden 으로 이동해 검색창에 "Claude"를 입력한다. 쓰려는 모델 카드(예: Claude Sonnet)를 열고 사용 설정(Enable) 버튼을 누른다. Anthropic 이용약관 동의 화면이 나오면 확인 후 동의한다. 이 절차는 모델별로 한 번씩만 하면 된다. gcloud servi...

Claude API로 챗봇이나 에이전트를 돌리다 보면 청구서에서 가장 큰 비중을 차지하는 항목이 입력 토큰이라는 사실을 알게 된다. 시스템 프롬프트, 도구 정의, 참고 문서를 매 요청마다 통째로 다시 보내기 때문이다. 프롬프트 캐싱(Prompt Caching)을 적용하면 이 반복 전송분의 입력 단가를 최대 90%까지 줄일 수 있다. 이 글에서는 캐싱의 동작 원리부터 cache_control 을 붙이는 위치, 캐시 수명 관리, 공식 단가 기반 비용 계산까지 실제 적용해 본 순서 그대로 정리한다. 프롬프트 캐싱이란 — 입력 최대 90% 절감 원리 프롬프트 캐싱은 프롬프트의 앞부분(프리픽스)을 Anthropic 서버에 잠시 저장해 두고, 같은 프리픽스로 다시 요청이 오면 그 구간을 처음부터 다시 처리하지 않는 기능이다. 과금 구조는 단순하다. 캐시에 처음 쓸 때는 일반 입력 단가의 1.25배를 내고, 이후 캐시를 읽을 때는 0.1배만 낸다. 즉 두 번째 요청부터는 반복 구간의 입력 비용이 90% 할인되는 셈이다. 비용뿐 아니라 응답 지연(latency)도 눈에 띄게 줄어든다. 공식 문서 기준 단가 배율을 표로 정리하면 다음과 같다. 출력 토큰 가격에는 영향이 없다. 구분 단가 배율 설명 일반 입력 ×1.0 캐싱 미사용 시 기본 단가 캐시 쓰기 (5분 TTL) ×1.25 첫 요청에서 캐시 생성 시 캐시 쓰기 (1시간 TTL) ×2.0 긴 수명 옵션 선택 시 캐시 읽기 (히트) ×0.1 90% 절감 구간 출력 토큰 변동 없음 캐싱과 무관 캐싱이 유리한 경우 / 무의미한 경우 캐싱이 이득이 되려면 세 가지 조건이 맞아야 한다. 같은 프리픽스가 반복되고, 재호출이 캐시 수명(기본 5분) 안에 일어나고, 프리픽스가 최소 캐시 길이를 넘어야 한다. 공식 문서 기준으로 모델별 최소 캐시 가능 길이가 정해져 있는데 Sonnet 계열은 1,024토큰 수준이다. 이보다 짧은 프롬프트는 cache_control 을 붙여도 캐시되지 않는다. 반대로 매 요...

GitHub README에 데모 GIF 하나가 있고 없고의 차이는 크다. 글로 열 줄 설명하는 것보다 3초짜리 GIF 한 장이 프로젝트를 훨씬 잘 팔아 준다. 문제는 만드는 과정이 귀찮다는 것이다. 녹화하고, 변환하고, 용량 줄이고… 이걸 릴리스마다 반복하다 보니 결국 명령어 한 줄로 끝나는 파이프라인 을 만들게 됐다. 그 과정을 순서대로 정리한다. 1. GIF가 필요한 곳 개발하면서 GIF를 쓰게 되는 지점은 생각보다 많다. README 상단 데모 : 프로젝트 첫인상. 핵심 기능 하나를 5초 이내로. 이슈 리포트 : "이런 버그가 있다"는 말보다 재현 GIF 한 장이 정확하다. PR 설명 : UI 변경 전/후를 GIF로 붙이면 리뷰가 빨라진다. 블로그·문서 : 튜토리얼 중간의 동작 확인용. 동영상(mp4)이 화질도 용량도 유리하지만, GIF는 클릭 없이 자동 재생되고 마크다운에 이미지처럼 박히는 것이 강점이다. GitHub 이슈·PR에는 mp4 첨부도 되지만 README 안에서의 자동 재생은 여전히 GIF가 편하다. 2. 녹화 도구 선택 녹화 자체는 어떤 도구든 mp4만 나오면 된다. 실제로 써 본 조합은 이렇다. 도구 용도 비고 Windows 캡처 도구·게임 바 일반 화면 녹화 추가 설치 없음, mp4 저장 OBS Studio 정밀한 영역·장시간 녹화 설정 자유도 최고 ScreenToGif 바로 GIF가 필요할 때 프레임 단위 편집 가능 asciinema + agg 터미널 데모 텍스트 기반 녹화 후 GIF 렌더 나는 "일단 mp4로 녹화하고 변환은 스크립트에 맡긴다"로 통일했다. 편집 없이 빠르게 찍을 때는 Windows 기본 녹화(Win+Alt+R), 영역을 정확히 잡을 때는 OBS를 쓴다. GIF 편집 기능이 있는 ScreenToGif도 좋은 도구지만, 매번 GUI에서 수동 저장하는 흐름이라 자동화와는 결이 달랐다. 3. ffmpe...

윈도우에서 화면을 녹화할 일은 생각보다 자주 생긴다. 강의 정리, 버그 제보, 게임 클립, 유튜브 콘텐츠까지. 문제는 방법이 여러 가지라 뭘 써야 할지 헷갈리고, 막상 녹화하면 소리가 빠져 있는 경우가 많다는 것. 윈도우 11 기준으로 음성이 포함되는 화면녹화 방법 4가지를 정리한다. 1. Xbox Game Bar — 기본 내장, 가장 간단 Win + G 로 게임바를 열고 녹화 위젯에서 녹화 버튼을 누르거나, 바로 Win + Alt + R 로 시작/종료할 수 있다. 별도 설치가 전혀 필요 없다. 음성 설정: 게임바의 마이크 아이콘을 켜면 내 목소리가 함께 녹음된다. 시스템 소리(PC에서 나는 소리)는 기본으로 녹음된다. 저장 위치: 동영상 → 캡처 폴더 단점: 전체 화면이나 특정 앱 창만 가능하고, 바탕화면·파일 탐색기는 녹화되지 않는다. 2. 캡처 도구 — 화면 일부만 녹화할 때 윈도우 11의 캡처 도구(Snipping Tool)는 스크린샷만 되는 게 아니다. 캡처 도구를 열고 상단의 동영상(카메라) 아이콘 을 선택한 뒤 영역을 지정하면 그 부분만 녹화된다. 최신 버전은 마이크·시스템 오디오 켜기 옵션 이 툴바에 있다. 화면 전체가 아니라 일부 영역만 필요할 때 가장 편하다. 3. PowerPoint — 의외의 선택지 PowerPoint가 설치돼 있다면 삽입 → 화면 녹화 기능이 있다. 영역을 지정해 오디오 포함 녹화가 되고, 녹화한 영상을 파일로 따로 저장할 수도 있다. 4. OBS Studio — 무료, 전문가용 자유도가 가장 높다. 마이크와 시스템 소리를 각각 별도 트랙 으로 잡을 수 있고, 화질·영역을 세밀하게 조절할 수 있어 유튜브·강의 영상 제작에 많이 쓴다. 다만 초기 설정이 조금 복잡하다. 설치와 설정 방법은 별도 글에서 단계별로 다룬다. 소리가 안 녹음될 때 화면녹화에서 가장 흔한 문제는 녹화는 됐는데 소리가 빠진 경우 다. 십중팔구 앱의 마이크 접근 권한 문제다. 설정 → 개인정보 보호 →...

화면녹화 도구 중 자유도가 가장 높은 것이 무료 프로그램 OBS Studio 다. 마이크와 시스템 소리를 따로 조절하고, 화질과 녹화 영역을 세밀하게 지정할 수 있어 유튜브·강의 영상 제작의 표준처럼 쓰인다. 설치부터 첫 녹화까지 순서대로 정리한다. 1. 설치 — 반드시 공식 사이트에서 공식 사이트 obsproject.com 에 접속해 Windows 버튼을 클릭하고 설치 파일을 실행하면 된다. 주의할 점 하나 — 검색하면 광고로 뜨는 사칭 사이트 가 있으니 반드시 공식 주소로 들어가자. 2. 첫 실행 — 자동 구성 마법사 처음 켜면 자동 구성 마법사가 뜬다. 녹화만 할 거라면 "녹화 최적화(스트리밍 안 함)" 를 선택하고, 해상도는 모니터 해상도(보통 1920x1080), FPS 30으로 적용하면 알아서 기본 설정을 잡아준다. 일단 이대로 시작해도 충분하다. 3. 화면(소스) 추가 하단 '소스' 패널에서 + 를 클릭한다. 디스플레이 캡처: 모니터 화면 전체 녹화 (가장 무난) 창 캡처: 특정 프로그램 창만 녹화 게임 캡처: 게임 녹화 전용 4. 오디오 설정 — 음성 포함의 핵심 하단 '오디오 믹서' 에 보통 두 개가 보인다. 데스크톱 오디오 = PC에서 나는 소리 (유튜브, 게임 소리 등) 마이크/보조 = 내 목소리 둘 다 소리 막대가 움직이면 정상이다. 안 잡히면 설정 → 오디오 에서 장치를 직접 지정한다. 마이크 소리가 너무 작으면 믹서의 슬라이더로 조절한다. 5. 녹화 품질 설정 설정 → 출력 탭에서 출력 모드를 '고급' 으로 바꾸면 세밀한 조절이 가능하다. 특히 인코더 가 중요한데, 그래픽카드가 있다면 하드웨어 인코더(NVENC/AMD/QuickSync)를 선택해야 녹화 중 렉이 안 걸린다. 저장 폴더는 설정 → 출력 → 녹화 경로 에서 바꿀 수 있다. 6. 녹화하기 오른쪽 아래 '녹화 시작' 을 누르고, 끝나...

클로드(Claude)를 쓰다 보면 비용 이야기가 두 갈래로 나뉜다. 하나는 API 토큰 단가 , 다른 하나는 claude.ai 구독 플랜의 사용량 한도 다. 둘은 완전히 다른 체계인데 자주 혼동된다. 이 글은 모델별 API 단가와 작업 유형별 예상 비용을 먼저 정리하고, 이어서 Free·Pro·Max 구독의 한도 구조를 비교한다. 모델별 API 단가 비교 중요한 전제 하나. 클로드는 모델 자체가 토큰을 더 쓰거나 덜 쓰는 게 아니라, 토큰당 단가 와 같은 텍스트를 토큰으로 쪼개는 방식 이 모델별로 다르다. 그래서 "모델별 단가 × 작업별 토큰량 = 실제 비용"으로 비교하는 것이 가장 실용적이다. 모델 입력 ($/100만 토큰) 출력 ($/100만 토큰) 컨텍스트 비고 Opus 4.8 (플래그십) $5 $25 1M Fast mode는 $10/$50 Opus 4.7 / 4.6 $5 $25 1M 1M 컨텍스트 표준가 Sonnet 4.6 $3 $15 1M 속도·지능·비용 균형, 최대 출력 128K Haiku 4.5 $1 $5 200K 분류·라우팅·추출 등 고볼륨 작업용 공통 패턴이 하나 있다. 모든 현재 등급이 출력:입력 = 5:1 비율 을 유지한다. 즉 비용을 결정하는 것은 프롬프트 길이보다 응답(출력) 길이 다. 프롬프트 캐싱(캐시된 입력 최대 90% 절감)과 배치 API(전체 50% 절감)를 조합하면 절감폭이 더 커진다. 작업 유형별 예상 토큰 사용량과 비용 대표적인 작업 유형에 전형적인 토큰량을 가정하고 위 단가로 계산한, 1회 요청당 비용이다. 작업 유형 입력 / 출력 (토큰) Haiku 4.5 Sonnet 4.6 Opus 4.8 짧은 챗·Q&A 1K / 0.5K $0.0035 $0.011 $0.018 분류·추출 2K / 0.2K $0.003 $0.009 $0.015 긴 문서 요약 20K / 1K $0.025 $0.075 $0.125 코딩 태스크 15K / 3K $0.030 $0.090 $0....

2026년 6월 9일, Anthropic이 5세대 모델 가족의 첫 주자인 Claude Fable 5 를 공개했다. 기존 최상위 모델이던 Opus 4.8과 무엇이 다른지, 구독 플랜에서는 어떻게 제공되는지, 그리고 출시 직후 벌어진 접근 중단 사태까지, 실제 사용 과정에서 확인한 내용을 정리한다. 새 모델을 써볼지 고민 중이거나 갑자기 모델 접근 오류를 만난 사람에게 도움이 될 것이다. Fable 5란 어떤 모델인가 Fable 5는 Anthropic의 모델 계층에서 가장 위에 있는 Mythos급(Mythos-class) 모델이다. 기존 계층이 Haiku → Sonnet → Opus 순서였다면, 이제 그 위에 Mythos 등급이 추가된 셈이다. 배경을 보면 Anthropic은 같은 해 4월에 Mythos를 먼저 공개했지만, 고급 사이버보안 능력 때문에 일부 승인된 고객에게만 제한적으로 배포했다. Fable 5는 그 Mythos 기술에 안전장치를 더해 일반 사용자도 쓸 수 있게 만든 버전이다. 함께 발표된 Claude Mythos 5는 여전히 일반 출시되지 않았으며, 두 모델은 본질적으로 같은 기반 모델이다. Fable 5 vs Opus 4.8 - 핵심은 용도의 차이 두 모델의 가장 중요한 차이는 성능 수치가 아니라 용도 다. Fable 5는 모델이 스스로 작업을 분해하고 조사하고 만들고 검증하는 장기 비동기 프로젝트 에 적합하고, Opus 4.8은 복잡한 작업을 사람과 주고받으며 처리하는 빠른 동기적(실시간) 협업 에 적합하다. Fable 5의 강점으로 알려진 내용은 다음과 같다. Claude Code 같은 에이전트 환경에서 며칠 동안 작업을 지속 하며, 단계별로 계획하고 하위 에이전트에 위임하고 자기 작업을 검증한다. 5천만 줄 규모의 Ruby 코드베이스에서, 팀이 수작업으로 2개월 넘게 걸릴 전체 마이그레이션을 하루 만에 수행한 사례가 소개됐다. 파일과 PDF 안에 중첩된 다이어그램·차트·표를 이해하는 비전 능력이 강화되어 금융·법률...

안드로이드 스튜디오에서 Claude를 코딩 에이전트로 쓰고 싶을 때 가장 먼저 부딪히는 질문이 있다. "API 키를 발급받아야 하나, 아니면 이미 쓰고 있는 Claude Pro/Max 구독으로 되나?" 결론부터 말하면 연동 방식이 두 가지 이고, 어느 쪽을 고르느냐에 따라 결제 체계가 완전히 달라진다. 이 글에서는 두 방식의 차이, API 키 없이 구독만으로 연동하는 절차, 그리고 사용량 제한까지 실제로 필요한 내용을 정리한다. 두 가지 연동 방식: 무엇이 다른가 안드로이드 스튜디오에 Claude를 연결하는 경로는 크게 두 가지다. 방법 1: 내장 AI Agent에 모델 추가 (Remote Model Provider) 안드로이드 스튜디오의 공식 기능인 Remote Model Provider 를 이용해 내장 AI Agent(Agent Mode)에 Claude를 모델 제공자로 등록하는 방법이다. 절차는 다음과 같다. Anthropic Console(console.anthropic.com)에서 API 키를 발급하고 결제수단을 등록한다. File > Settings (macOS는 Android Studio > Settings ) → Tools > AI > Model Providers 로 이동한다. Add → Third-Party Remote Provider 를 선택하고, URL에 https://api.anthropic.com , API key에 발급받은 키를 입력한다. Refresh 를 누르면 Claude Sonnet, Opus, Haiku 등 모델 목록이 표시되고, 선택 후 저장하면 채팅창의 모델 선택기에서 Claude를 고를 수 있다. 이 방식은 BYOK(Bring Your Own Key) 구조라 API 키가 반드시 필요하고 토큰 사용량에 따라 별도 과금 된다. Claude Pro/Max 구독은 여기에 적용되지 않는다. 또한 외부 모델을 연결하면 코드와 프롬프트가 해당 제공자 서버로 전송되므로 데...

Ollama로 로컬 LLM을 설치하고 나면 곧바로 다음 질문이 따라온다. "그래서 이걸로 뭘 하지?" 로컬 모델을 유료 클라우드 AI의 싼 대체품으로 보면 항상 아쉽다. 성능만 비교하면 프런티어급 클라우드 모델이 앞서기 때문이다. 관점을 바꿔 로컬 모델만의 무기가 무엇인지 이해하면 활용도가 완전히 달라진다. 이 글은 로컬 Gemma와 클라우드 AI의 차이, 에이전트 도구에 대한 흔한 오해, 그리고 파인튜닝까지 로컬 LLM 활용 전략을 정리한 것이다. 로컬 모델과 클라우드 AI, 무엇이 다른가 둘 다 트랜스포머 기반 대규모 언어 모델이라 본질은 같다. 텍스트 이해·생성, 추론, 코딩, 요약을 하고 이미지 입력 같은 멀티모달과 함수 호출(에이전트 워크플로)도 지원한다. 하지만 갈림길은 뚜렷하다. 항목 로컬 모델 (Gemma 4) 클라우드 AI (Claude 등) 공개 방식 오픈웨이트 (Apache 2.0) 비공개·독점 실행 위치 내 PC, 오프라인 가능 클라우드, 인터넷 필수 비용 무료 (전기요금만) 구독 또는 API 종량제 개인정보 100% 로컬, 외부 전송 없음 데이터가 클라우드로 전송 성능 로컬급, 최상위 난도엔 한계 프런티어급, 어려운 작업에 강함 커스터마이징 파인튜닝·수정·재배포 자유 가중치 수정 불가 핵심 트레이드오프는 한 문장으로 요약된다. 로컬 모델은 프라이버시·비용·오프라인·통제권에서 이기고, 클라우드 AI는 어려운 작업의 순수 성능에서 이긴다. 둘은 경쟁 관계가 아니라 역할 분담 관계다. '도구'와 '두뇌'는 분리된다 — ollama launch의 정체 Ollama 앱에는 Claude Code, Codex, OpenCode 같은 에이전트 도구를 바로 띄워 주는 Launch 기능이 있다(v0.15부터 추가). 여기서 개념 하나를 정확히 잡아야 한다. 이런 에이전트 도구는 사실 분리된 두 개의 부품 으로 이루어져 있다. 도구(손과 눈) — 터미널에서 돌면서 파일을...

ChatGPT나 Claude 같은 AI를 매달 구독료 없이 내 컴퓨터에서 직접 돌릴 수 있을까? 결론부터 말하면 가능하다. VRAM 12~16GB급 그래픽카드가 달린 Windows PC라면, 오픈소스 실행 도구 Ollama 와 구글의 오픈 모델 Gemma 4 를 조합해 비용 0원으로 로컬 LLM을 구축할 수 있다. 이 글은 어떤 모델을 고를지부터 설치 명령어, 모델 저장 위치를 D드라이브로 옮길 때 흔히 빠지는 함정까지, 실제 설치 과정에서 부딪히는 순서 그대로 정리한 가이드다. 로컬에서 돌릴 수 있는 모델, 회사별 현황 주요 AI 3사의 입장은 뚜렷하게 갈린다. 구글이 가장 적극적 이다. Gemma 시리즈가 로컬용 오픈 모델이고, 2026년 4월 출시된 Gemma 4가 최신이다. Apache 2.0 라이선스라 상업 사용·파인튜닝·재배포가 모두 자유롭고, E2B·E4B·26B(MoE)·31B 등 여러 크기에 더해 6월에는 16GB 메모리 환경을 노린 중간 크기 12B 모델이 추가됐다. 작은 E2B·E4B 모델은 온디바이스 음성 인식까지 지원한다. 오픈AI도 있다. 2025년 8월 공개된 gpt-oss(20b/120b)가 GPT-2 이후 처음 나온 오픈웨이트 언어 모델이다. 역시 Apache 2.0이고, 20b 버전은 16GB 메모리 기기에서 돌아가도록 설계됐다. 음성을 텍스트로 바꿔 주는 Whisper도 오픈소스라 자막·전사 작업을 로컬에서 무료로 처리할 수 있다. 반면 앤트로픽은 로컬 모델이 없다. Claude는 API와 클라우드 전용이라 가중치를 내려받아 실행할 수 없다. MCP 같은 오픈 표준을 공개하긴 하지만 그것은 도구 연결 프로토콜이지 모델이 아니다. 한 가지 미리 짚어 둘 경계선이 있다. 이들 로컬 모델은 전부 텍스트를 다루는 LLM 이다. 음성 파일의 잡음 제거나 음질 보정처럼 오디오 자체를 손보는 작업은 LLM 학습으로 해결하는 영역이 아니라 DeepFilterNet 같은 전용 오디오 AI와 신호처리 도구의 영역이다. 로컬 L...

Vertex AI에서 Claude, Gemini 같은 모델을 섞어 쓰다 보면 모델마다 토큰 단가가 달라서 "어느 모델이 비용을 얼마나 쓰고 있는지"가 궁금해진다. 그런데 GCP의 Cloud Monitoring에는 비용 메트릭 자체가 없다 . 토큰 사용량 메트릭은 있어도 달러로 환산된 값은 제공되지 않는다. 이 글에서는 측정항목 탐색기에서 만든 PromQL 쿼리를 맞춤 대시보드로 저장하는 방법과, 모델별 비용을 추적하는 두 가지 방법(PromQL 직접 계산, BigQuery 결제 내보내기)을 정리한다. 쿼리를 맞춤 대시보드로 저장하기 측정항목 탐색기에서 매번 쿼리를 다시 입력할 필요는 없다. GCP의 맞춤 대시보드에 저장해두면 언제든 한 화면에서 모니터링할 수 있다. 방법 1: 측정항목 탐색기에서 바로 저장 쿼리 작성 후 차트가 잘 나오는지 확인하고 우측 상단의 차트 저장 버튼을 클릭한다. 새 대시보드 만들기 를 선택하거나 기존 대시보드를 고른다. 대시보드 이름(예: Vertex AI 토큰 사용량)과 위젯 제목을 입력하고 저장한다. 쿼리마다 이 과정을 반복하면 한 대시보드에 차트가 여러 개 쌓인다. 방법 2: 대시보드부터 만들기 모니터링 → 대시보드 → 대시보드 만들기 로 빈 대시보드를 생성한 뒤, 위젯 추가 에서 선 차트·스코어카드·원형 차트 등을 고르고 위젯 편집기의 PromQL 탭에 쿼리를 붙여넣으면 된다. 여러 차트를 한 번에 구성할 때 편하다. 추천 구성은 다음과 같다. 위젯 차트 유형 쿼리 형태 모델별 총 토큰 (7일) 스코어카드/막대 sum by (model_user_id) (increase(...[7d])) 시간별 사용 추이 선 차트 sum by (model_user_id) (rate(...[5m])) * 60 입력 vs 출력 비중 원형 차트 sum by (type) (increase(...[7d])) 누적 곡선 (30일) 선 차트 sum by (model_user_id) (increase(....