Claude 상담원 팀 최대한 활용하기

I spent my first few weeks with agent teams treating them like a faster version of a single agent. Describe the task, let multiple agents run at it, collect the output. The results were fine. Not bad, not great. Roughly what I’d get from one agent, just more of it. The shift happened when I stopped thinking about agents and started thinking about teams. Not AI teams. Teams. The kind I’ve built and run in organizations for years. The dynamics that make a group of people produce better work than any individual (role clarity, productive tension, structured disagreement, a single decision-maker) apply when the team members are Claude instances running in your terminal. That realization changed how I use Claude Code. Agent teams are the third mode, after the main agent and sub-agents (background processes that work in isolation). Teams are background processes that work collectively, with the main agent relaying messages between you and them. They’re off by default; you enable them with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (the Claude Code docs cover the full setup). They’re the mode that made the difference. Rather than walk through the theory first, I want to show what I’ve landed on and then take it apart. The prompt A recent prompt of mine looked something like this: We're redesigning the notification preferences system. Users can't figure out how to mute specific channels without muting everything, and support tickets on this have tripled. I want you to work on this with an agent team. Outcomes: 1. Users can configure preferences per channel without affecting global settings 2. Fits within existing settings architecture (no new services) 3. Non-breaking migration from current schema Agent team composition: - Lead (you): The only person allowed to build, keep yourself available when you're not building so that you can relay my messages quickly to the team - Principal engineer: conservative on scope, leads with questions, reviews all proposals for hidden complexity - Frontend specialist: UX and interaction patterns for preference management - Platform engineer: data model, API surface, migration strategy - Director of Customer Success: voice of the customer, knows the support patterns and real-world workflows this needs to serve Workflow: 1. Lead does light research on the current notification system 2. Spin up the team and brief them 3. Teammates research independently, propose approaches from their domain 4. PE runs a roundtable: questions each proposal, surfaces trade- offs. If an expert raises a concern, investigate it before moving on. Drive toward consensus 5. Present findings and agreed approach to me for approval 6. Once I greenlight, lead implements. Only the lead writes code 7. Keep the team for review. Teammates evaluate the work against what was agreed. Back to step 4 if concerns arise 8. Present completed work to me before committing The specifics change every time, but the shape stays the same: problem, outcomes, team, workflow. Four blocks. Each one is load-bearing, and it took me a while to understand why. Why ad hoc My first instinct was to design a universal team. One configuration I could point at any task. It didn’t work well. The roles that matter for a frontend redesign are different from the ones that matter for a backend refactor or a strategic analysis. Now I build teams fresh for each task. The roles come from the work, not from a template. Reusable patterns exist for certain categories of work, but starting ad hoc forces you to think about what the task actually needs rather than defaulting to what worked last time. Why problems, not features The top of the prompt doesn’t say “add per-channel notification toggles.” It describes a situation: users can’t figure out how to mute specific channels, and support tickets have tripled. Then it lists outcomes, not specifications. The framing matters. I describe problems to solve, not features to build. “Users are dropping off during onboarding because they don’t understand the value prop before being asked to configure” produces better work than “add a welcome tour with three steps.” Problems give the team room to reason about the right solution. Features constrain them to executing yours. Why one writer In the team composition block, the lead is defined as “the only person allowed to build.” This is the single most important constraint. In every team I set up, only the lead (the main Claude Code process) makes changes to files. Teammates research, analyze, critique, and propose, but the pen stays with one agent. Without this, teammates overwrite each other’s work, and you spend your time untangling conflicts instead of making progress. Why a principal engineer The PE role is modeled as the expert minority in an organization. Part devil’s advocate, part quality bar. They lead with questions, not directives. They can’t make decisions unilaterally, only surface concerns and build consensus through discussion. Depending on the task, I tune thi