1 · 오프닝 — Rule No.161 · Opening — Rule No.16

15강에서는 품질과 신뢰를 설계하는 법을 배웠죠. 검증 게이트를 어디에 놓을지, 언제 사람이 개입할지를 미리 정해 두는 거였어요. 그런데 오늘은 조금 다른 질문을 던집니다. 나 혼자 쓸 때는 몰랐던 문제들이, 팀원이 늘면 어떻게 터지는가. 비용은 누가 내고, 누가 어디까지 쓸 수 있고, 무슨 일이 일어났는지 어떻게 기록하는가. 오늘은 룰 넘버 식스틴, "개인 도구가 팀 인프라가 되려면"을 다룹니다. 비용과 거버넌스예요.Last time we learned how to design quality and trust — pinning down where to put verification gates and when a human steps in. But today we ask a different question. What problems, invisible when you use it alone, blow up when the team grows? Who pays the cost, who can access what, and how do you record what happened? Today is Rule Number Sixteen: from personal tool to team infrastructure. Cost and governance.

2 · 한 명이 쓸 때는 몰랐던 문제들2 · What you didn't know when using it alone

한 가지 장면을 볼게요. 팀원 다섯 명이 클로드를 쓰기로 했습니다. 가장 빠른 방법은 API 키를 공유하는 거였어요. 처음엔 잘 굴러가는 것 같았죠. 한 달 뒤 청구서가 왔는데, 생각보다 훨씬 컸습니다. 누가 뭘 얼마나 썼는지 전혀 알 수 없어요. 그리고 어느 날 고객 데이터가 프롬프트 안에 들어간 사실을 뒤늦게 발견했는데, 언제 어떤 요청이었는지 로그가 없습니다.Let's look at one scene. A team of five decided to use Claude. The fastest path was sharing an API key. At first it seemed to work fine. A month later the invoice arrived — far larger than expected. No idea who used what, or how much. And one day they discovered customer data had ended up in a prompt, but there were no logs of when or what the request was.

이 세 가지, 그러니까 비용·접근·감사 로그는 혼자 쓸 때는 무시해도 되는 것들이에요. 내 카드에서 나가고, 내가 쓰고, 기억하면 되니까요. 그런데 팀이 되는 순간, 이 셋은 전부 필수 설계 항목이 됩니다. 오늘은 이 세 가지를 어떻게 설계하는지를 순서대로 다룹니다.These three — cost, access, and audit logs — are things you can ignore when using it alone. It comes out of your card, you use it, you remember. But the moment it becomes a team tool, all three become mandatory design items. Today we'll cover how to design each of them, in order.

3 · 비용 구조 — 토큰 가격표3 · Cost structure — token price table

비용부터 정확히 알아야 설계가 가능합니다. 클로드 API 비용은 토큰 수에 따라 청구돼요. 이천이십육년 육월 기준으로 소넷 사점 육의 경우, 입력 토큰이 백만 개당 달러 삼, 출력 토큰이 백만 개당 달러 십오입니다. 출력이 입력의 다섯 배예요. 그러니까 짧은 답이 나오게 설계하는 게 유리합니다.You need to know the costs precisely before you can design anything. Claude API costs are billed by token count. As of June twenty twenty-six, for Sonnet four point six: input tokens are three dollars per million, output tokens are fifteen dollars per million. Output is five times the input price. So designing for shorter responses pays off.

거기다 두 가지 최적화 옵션이 있어요. 첫째, 프롬프트 캐싱입니다. 긴 시스템 프롬프트나 문서를 처음 저장할 때는 이십오 퍼센트가 추가되지만, 이후 같은 내용을 다시 읽을 때는 구십 퍼센트가 할인됩니다. 반복 호출이 많은 팀에서는 이게 아주 큰 차이를 만들어요. 둘째, 배치 API. 결과를 즉시 받을 필요 없는 작업은 비동기로 처리해서 최대 오십 퍼센트까지 절감할 수 있습니다.On top of that, there are two optimization options. First: prompt caching. Storing a long system prompt or document for the first time costs twenty-five percent extra — but reading the same content again afterwards gets a ninety percent discount. For teams with lots of repeated calls, this makes a huge difference. Second: Batch API. Tasks that don't need an immediate result can be processed asynchronously, cutting cost by up to fifty percent.

4 · 플랜 선택 — Pro vs Max vs API4 · Plan selection — Pro vs Max vs API

그러면 어떤 플랜을 써야 할까요. 이천이십육년 육월 기준으로 클로드 코드 프로는 월 달러 이십, 맥스는 월 백 달러부터 시작합니다. 이 둘은 개인 사용에 최적화된 정액 플랜이에요. 나 혼자 쓴다면, 그리고 반복 작업이 많다면 프로가 가장 경제적입니다.So which plan should you use? As of June twenty twenty-six, Claude Code Pro is twenty dollars a month, Max starts at one hundred dollars a month. These two are flat-rate plans optimized for personal use. If you're using it alone and have lots of repeated tasks, Pro is the most economical.

그런데 팀이 되면 달라져요. 공유 플랜은 거버넌스가 없습니다. 누가 얼마나 썼는지 분리할 수 없고, 접근 제어도 할 수 없어요. 그래서 팀이 되는 순간, 또는 자동화 파이프라인을 만드는 순간, API 종량제로 넘어가는 걸 권장합니다. API를 쓰면 키를 역할별로 발급하고, 사용량을 팀원별로 분리하고, 로그를 남길 수 있어요. 이게 바로 거버넌스의 출발점입니다.But when it becomes a team, things change. Shared plans have no governance. You can't separate who used how much, and you can't control access. So the moment it becomes a team — or the moment you build an automation pipeline — I recommend moving to the API pay-as-you-go model. With the API you can issue keys per role, separate usage per team member, and keep logs. That's where governance starts.

5 · API 키 관리 — 팀 거버넌스의 출발5 · API key management — where team governance starts

API 키 관리가 거버넌스의 시작점입니다. 가장 흔한 실수는 하나의 키를 팀 전체가 공유하는 거예요. 이렇게 하면 세 가지 문제가 생깁니다. 첫째, 누가 무엇을 얼마나 썼는지 알 수 없어요. 비용 분석도 안 되고 책임 추적도 안 됩니다. 둘째, 키가 유출되면 팀 전체 접근이 한 번에 끊깁니다. 셋째, 퇴사자나 프로젝트가 끝난 팀원의 접근을 선택적으로 회수할 수 없어요.API key management is where governance starts. The most common mistake is sharing one key across the whole team. This creates three problems. One: no way to know who used what, or how much. No cost analysis, no accountability tracking. Two: if the key leaks, the entire team's access gets cut at once. Three: you can't selectively revoke access for someone who left or whose project ended.

그래서 역할별로 키를 분리 발급해야 합니다. 개발팀 키, 운영팀 키, 자동화 파이프라인 키. 이렇게 나누면 사용량을 팀 단위로 추적하고, 문제가 생긴 키만 골라서 비활성화하고, 각 역할에 필요한 최소한의 권한만 줄 수 있어요. 이게 최소 권한 원칙입니다. 처음에 설정하기가 번거로워 보여도, 나중에 사고가 났을 때 이걸 안 해 둔 걸 후회하게 됩니다.So you need to issue separate keys per role. A key for the dev team, one for operations, one for the automation pipeline. With this split, you can track usage per team, selectively deactivate only the problem key, and give each role only the minimum permissions it needs. That's the least-privilege principle. It may feel like extra setup up front, but when an incident happens, you'll regret not having done it.

6 · 비용 최적화 전략 — 3단계6 · Cost optimization — three steps

비용을 줄이려면 세 가지 레버를 순서대로 당기면 됩니다. 첫 번째는 모델 선택이에요. 모든 작업에 소넷을 쓸 필요는 없습니다. 단순한 분류나 정리 작업은 더 저렴한 모델로도 충분해요. 작업 난이도에 맞는 모델을 선택하는 것만으로도 비용이 크게 달라집니다. 모델별 단가는 공식 가격표를 확인하세요.To cut cost, pull three levers in order. First is model selection. You don't need Sonnet for every task. Simple classification or organizing work is fine with a cheaper model. Just choosing the right model for the task difficulty makes a big cost difference. Check the official pricing page for per-model rates.

두 번째는 프롬프트 캐싱입니다. 팀 도구에는 보통 길고 반복적인 시스템 프롬프트가 있어요. 이걸 처음에 한 번 저장하면 추가 비용이 이십오 퍼센트 붙지만, 이후 매번 다시 읽을 때는 구십 퍼센트가 할인됩니다. 반복 호출이 많은 팀 워크플로우에서는 이게 가장 빠른 절감 방법이에요. 세 번째는 배치 처리입니다. 보고서 생성, 데이터 요약처럼 즉시 받지 않아도 되는 작업은 배치 API로 묶으면 최대 오십 퍼센트까지 절감됩니다.Second is prompt caching. Team tools usually have long, repeated system prompts. Storing one for the first time adds twenty-five percent, but every subsequent read gets a ninety percent discount. For team workflows with lots of repeated calls, this is the fastest savings lever. Third is batch processing. Tasks where you don't need an immediate response — report generation, data summarization — can be grouped with the Batch API for up to fifty percent savings.

7 · 비용 계산법 — 실제 추정7 · Cost calculation — actual estimation

자, 실제로 얼마가 나올지 추정해 봅시다. 공식은 간단합니다. 평균 입력 토큰 수에 백만 토큰당 달러 삼을 곱하고, 평균 출력 토큰 수에 달러 십오를 곱하고, 하루 요청 수에 삼십 일을 곱하면 월 예상 비용이 나옵니다. 예를 들어, 팀원 열 명이 하루에 각각 요청을 열 번 하고, 요청당 입력 이천 토큰과 출력 오백 토큰이 나온다면 — 월에 어느 정도가 나오는지 이 공식으로 미리 계산해 두세요.Let's estimate what the actual cost will be. The formula is simple. Multiply average input token count by three dollars per million tokens, multiply average output token count by fifteen dollars, multiply daily request count by thirty days — that gives your monthly estimate. For example, if ten team members each make ten requests a day, with two thousand input tokens and five hundred output tokens per request — use this formula to calculate upfront what the monthly cost will be.

캐싱을 적용하면 반복 입력의 구십 퍼센트가 절감되니까, 시스템 프롬프트가 길수록 효과가 커집니다. 추정 후에는 꼭 spending limit, 그러니까 사용량 상한을 보수적으로 설정해 두세요. 처음에는 예상보다 많이 나올 수 있거든요. 상한을 낮게 걸어 두고 한 주 동안 관찰하면서 올리는 방식이 안전합니다. 이게 비용 설계의 핵심, 미리 추정하고, 상한을 걸고, 관찰하면서 조정하는 거예요.With caching, ninety percent of repeated input is saved — the longer the system prompt, the bigger the effect. After estimating, always set a spending limit conservatively. At first, things may cost more than expected. The safe approach is to set a low limit, observe for a week, and raise it from there. That's the core of cost design: estimate in advance, set a ceiling, observe, and adjust.

8 · 캐싱·배치·모델 선택의 원리8 · The logic behind caching, batching, and model selection

왜 이 순서가 중요할까요. 모델 선택이 가장 먼저인 이유는, 단가 자체를 바꾸기 때문입니다. 하이쿠와 소넷은 같은 작업을 수행해도 단가가 크게 달라요. 단순 작업에 비싼 모델을 쓰는 건, 택배 하나 보내는데 특급 항공편을 쓰는 것과 같습니다. 그러니까 "이 작업에 정말 소넷이 필요한가"를 먼저 물어보는 게 가장 빠른 절감입니다.Why does order matter? Model selection comes first because it changes the unit price itself. Haiku and Sonnet have very different unit prices even for the same task. Using an expensive model for a simple task is like sending a single package by express air freight. So the fastest savings is asking first: "does this task really need Sonnet?"

캐싱은 두 번째입니다. 시스템 프롬프트처럼 반복 사용하는 콘텐츠에 적용하면 장기적으로 가장 지속적인 효과를 냅니다. 구현도 어렵지 않아요. 배치는 세 번째인데, 이건 즉시성을 포기해야 한다는 조건이 있습니다. 실시간 응답이 필요 없는 작업에만 쓸 수 있어요. 순서를 지키면 복잡성 없이 단계적으로 비용을 줄일 수 있습니다.Caching is second. Apply it to repeatedly used content like system prompts, and you get the most sustained long-term effect. It's also not hard to implement. Batching is third — it comes with the condition that you give up immediacy. Only applicable to tasks that don't need a real-time response. Follow the order and you can reduce costs step by step without added complexity.

9 · 접근 제어 설계 — 역할 기반9 · Access control design — role-based

이제 접근 제어를 설계해 봅시다. 원칙은 하나예요. 각 역할에 필요한 최소한의 권한만 줍니다. 리테일 조직을 예로 들면, MD팀은 상품 분석이 목적이니까 전체 접근 키를 발급하고 사용량을 추적합니다. 매장 운영 담당은 결과를 읽고 조회하는 것만 필요하니까 조회 전용 키를 씁니다. 외부 마케팅 대행사는 협업 기간에만 쓸 수 있도록 기간 한정 임시 키를 발급하고요.Now let's design access control. There's one principle: give each role only the minimum permissions it needs. Take a retail organization as an example. The MD team needs full access for product analysis, so issue them a team key and track usage. Store operations staff only need to read and query results, so they get a read-only key. External marketing agencies get a time-limited temporary key valid only during the collaboration period.

외부 파트너나 일시적인 협업이라면 기간이 설정된 임시 키를 씁니다. 만료일을 미리 정해 두면, 협업이 끝나도 키를 잊고 방치할 일이 없어요. 이렇게 역할별로 키를 나누는 게 번거로워 보일 수 있지만, 사고가 났을 때 해당 키 하나만 비활성화하면 된다는 게 얼마나 큰 이점인지 실감하게 됩니다. 최소 권한은 번거로운 게 아니라, 사고를 작게 만드는 설계입니다.For external partners or temporary collaboration, use a time-limited temporary key. Set an expiry date upfront, and you won't forget to revoke it after the collaboration ends. Setting up per-role keys may seem tedious, but the moment an incident happens, you'll understand how valuable it is to just deactivate one key. Minimum privilege isn't a hassle — it's a design that makes incidents small.

10 · 감사 로그 설계10 · Audit log design

세 번째 설계 요소는 감사 로그입니다. 로그를 보면 무서워서 다들 복잡하게 생각하는데, 사실 네 가지 필드만 기록해도 충분합니다. 첫째, 요청 시각. 둘째, 어느 키를 썼는지, 그러니까 어떤 역할이었는지. 셋째, 어떤 모델을 사용했는지. 넷째, 입출력 토큰 수. 이 네 가지만 있어도 사고가 났을 때 언제, 누가, 무엇을, 얼마나 썼는지를 추적할 수 있어요.The third design element is the audit log. People tend to overcomplicate logs, but in practice four fields are enough to start. One: request timestamp. Two: which key was used — meaning which role. Three: which model was used. Four: input and output token counts. With just these four, when an incident happens you can trace when, who, what, and how much.

중요한 주의사항이 하나 있어요. 프롬프트 내용 자체를 로그에 포함하면 개인정보나 고객 데이터가 로그에 남을 수 있습니다. 무엇을 기록하고 무엇을 빼야 하는지를 사전에 정책으로 정해 두세요. 비용 분석에는 토큰 수만 있어도 충분하고, 내용 자체는 필요할 때만, 그리고 별도의 보안 통제를 거쳐 저장하는 게 원칙입니다.One important caution: if you include the prompt content itself in logs, personal or customer data may end up in the log. Decide in advance, as a policy, what to record and what to leave out. For cost analysis, token counts alone are sufficient. The content itself should only be stored when necessary and with separate security controls in place. That's the principle.

11 · 팀 정책 수립 체크리스트11 · Team policy checklist

자, 오늘의 핵심 정리입니다. 팀 도구로 전환하기 전에 다섯 가지를 점검하세요. 첫째, 비용 예산을 추정했나요? 토큰 수에 단가를 곱해 월 예산을 계산하고, spending limit를 설정합니다. 둘째, API 키를 역할별로 나눴나요? 최소 권한 원칙으로, 팀원과 역할별로 키를 분리합니다. 셋째, 모델 선택 정책을 정했나요? 작업마다 적정 모델을 지정하고, 무조건 소넷을 쓰는 기본값을 피합니다.Alright, here's the core checklist. Before switching to a team tool, check five things. One: did you estimate the cost budget? Calculate the monthly budget from token count times unit price, and set a spending limit. Two: did you split API keys by role? Apply the least-privilege principle and separate keys by team member and role. Three: did you set a model selection policy? Assign the appropriate model for each task, and avoid defaulting everything to Sonnet.

넷째, 감사 로그의 네 개 필드를 켰나요? 시각, 키, 모델, 토큰. 이 네 가지 최소 기록은 사고 추적의 기본입니다. 다섯째, 비용 이상 알림을 설정했나요? spending limit와 함께, 비용이 갑자기 급증하면 알림이 오도록 설정해 두세요. 이 다섯 가지를 전환 전에 완료하면, 팀 도구 도입 초기에 생기는 사고 대부분을 예방할 수 있습니다.Four: did you turn on the four audit log fields? Timestamp, key, model, tokens. These four minimal records are the foundation of incident tracing. Five: did you set cost anomaly alerts? Along with the spending limit, set up alerts for sudden cost spikes. Complete these five before the switch, and you'll prevent most of the incidents that happen in the early days of a team tool rollout.

12 · 비용 대시보드 설계12 · Cost dashboard design

로그를 쌓는 것만으로는 부족합니다. 보이지 않으면 제어할 수 없어요. 그래서 대시보드가 필요합니다. 좋은 비용 대시보드는 네 가지를 보여줍니다. 역할별 사용량, 날짜별 추이, 모델별 비중, 그리고 이상 급증 알림이에요. 역할별 사용량은 누가 얼마나 쓰는지를 보여줘서 팀 안에서 책임을 배분하게 해줍니다. 날짜별 추이는 갑자기 비용이 뛰는 시점을 발견하게 해 주고요.Just accumulating logs isn't enough. If you can't see it, you can't control it. That's why you need a dashboard. A good cost dashboard shows four things: usage by role, trend by date, share by model, and spike alerts. Usage by role shows who uses how much, enabling accountability distribution within the team. Trend by date helps you catch moments when cost suddenly jumps.

모델별 비중은 최적화 여지를 찾아줍니다. 단순 작업에 비싼 모델이 많이 쓰이고 있다면, 그게 바로 줄일 수 있는 부분이에요. 이상 급증 알림은 사고가 커지기 전에 잡아내는 용도입니다. Anthropic 콘솔에서 기본 지표 일부를 제공하지만, 더 세밀한 분석은 앞에서 설계한 감사 로그를 기반으로 직접 구현하는 게 필요해요. 대시보드는 팀 거버넌스의 눈입니다.Share by model reveals optimization headroom. If expensive models are doing a lot of simple tasks, that's exactly where you can cut. Spike alerts are for catching incidents before they grow. The Anthropic console provides some basic metrics, but finer analysis requires building on top of the audit logs you designed earlier. The dashboard is the eye of team governance.

13 · 개인→팀 전환 플레이북13 · Personal-to-team transition playbook

처음 콜드 오픈에서 봤던 그 장면, 기억나시죠. API 키를 공유했고, 청구서가 컸고, 로그가 없었어요. 이제 결론으로 돌려받아 봅시다. 개인 도구로 쓸 때는 단일 키, 비용은 감각적으로, 로그는 없어도 됩니다. 내가 다 기억하니까요. 그런데 팀 인프라가 되는 순간 이 모든 게 바뀝니다. 역할별 키, 예산 추정과 상한, 감사 로그, 그리고 대시보드.Remember that scene from the cold open? Shared API key, bigger-than-expected invoice, no logs. Let's bring it back as our conclusion. As a personal tool: single key, intuitive cost sense, no logs needed. You remember everything yourself. But the moment it becomes team infrastructure, all of this changes. Per-role keys, budget estimate and ceiling, audit logs, and a dashboard.

도구는 같습니다. 클로드는 같고, API는 같아요. 바뀌는 건 운영 방식이에요. 그리고 이 운영 방식의 변화는 팀이 커지기 전에, 그러니까 사고가 나기 전에 미리 설계해 둬야 합니다. 키 분리와 로그 설정에 드는 반나절이, 청구서 사고 한 번보다 쌉니다. 미리 하는 거버넌스가 가장 저렴한 거버넌스입니다.The tool is the same. Same Claude, same API. What changes is how you operate it. And this change in operation needs to be designed before the team grows — before an incident happens. Half a day spent separating keys and setting up logs costs less than a single billing incident. Governance done in advance is the cheapest governance.

14 · 마무리 · 다음 강 예고14 · Wrap-up · next lesson

오늘 네 단어만 가져가신다면 이겁니다. 추정, 분리, 기록, 그리고 관찰. 사용 전에 비용을 추정하고 상한을 걸고, 키를 역할별로 분리하고, 최소한의 로그를 기록하고, 대시보드로 관찰하면서 조정한다. 이 네 가지가 개인 도구를 팀 인프라로 바꾸는 거버넌스 설계입니다.If you take four words from today, they're these: estimate, separate, record, and observe. Estimate cost before use and set a ceiling, separate keys by role, record minimal logs, and adjust while observing through a dashboard. These four are the governance design that turns a personal tool into team infrastructure.

거버넌스는 사고가 난 다음에 하는 게 아니라, 도구를 도입하면서 함께 설계하는 겁니다. 혼자 쓰던 에이전트를 팀으로 묶고, 품질을 설계했으니, 이제 그 팀을 여럿이 안전하게 나눠 쓰는 단계까지 왔습니다. 클로드 코드 프로와 맥스는 개인 사용에 최적화됐고, 팀과 자동화에는 API 종량제로 전환해서 거버넌스를 갖추는 게 권장 경로예요. 다음 시간에는 클로드가 텍스트를 넘어서 이미지와 문서, 시각 정보를 다루는 능력, 룰 넘버 세븐틴, 멀티모달을 다룹니다. 텍스트만으로는 부족했던 순간들이 어떻게 달라지는지 보여드리겠습니다.Governance isn't something you do after an incident — it's something you design alongside the tool when you first introduce it. You started with a solo agent, built it into a team, designed quality into it — and now you've reached the stage of sharing that team safely with others. Claude Code Pro and Max are optimized for personal use; for teams and automation, moving to the API pay-as-you-go model to establish governance is the recommended path. Next time, we'll cover Claude's ability to handle not just text but also images, documents, and visual information: Rule Number Seventeen, multimodal. I'll show you how the moments where text alone wasn't enough start to look different.