많은 서브에이전트를 실행하고 그 결과를 교차 검증하는 스크립트로, 한 번에 조율하기에는 너무 큰 작업용입니다. 한 번의 패스 이상이 필요한 작업용입니다
작업이 소수의 서브에이전트로는 조율할 수 없을 때, 또는 결과를 서로 검증하고 싶을 때: 코드베이스 전체 감사, 500개 파일 마이그레이션, 교차 검증된 연구, 또는 여러 각도에서 작성된 계획
모든 접근 방식에서 작업자는 Claude 세션입니다. 다른 도구를 포함하려면MCP 서버로 Claude에 노출하세요.이 작업을 지원하지만 에이전트를 실행하는 방식이 아닌 두 가지 추가 도구가 있습니다:
Worktrees는 각 세션에 별도의 git 체크아웃을 제공하므로 병렬 세션이 동일한 파일을 편집하지 않습니다. 직접 실행하는 세션에 사용하세요. 에이전트 뷰는 각 디스패치된 세션을 자동으로 자신의 worktree로 이동하고, 생성하는 서브에이전트도 각각 하나씩 얻을 수 있습니다.
/batch는 Claude가 하나의 큰 변경을 5~30개의 worktree 격리 서브에이전트로 분할하여 각각 pull request를 열도록 하는스킬입니다. 이는 서브에이전트와 worktree의 패키지된 사용이지, 별도의 조율 스타일이 아닙니다.
다른 몇 가지 기능은 각 단계를 직접 운영하지 않고 Claude를 실행하지만, 에이전트 간 작업 분할과는 다른 문제를 해결합니다:
백그라운드 bash 명령은 대화를 차단하지 않고 하나의 셸 명령을 실행합니다. 에이전트를 생성하지 않습니다.
포크된 서브에이전트는 처음부터 시작하는 대신 전체 대화 컨텍스트를 상속하는 서브에이전트입니다. 서브에이전트를 생성하는 방식이지, 별도의 표면이 아닙니다.
루틴은 머신에서 병렬로 실행되지 않고 Anthropic의 클라우드에서 일정에 따라 세션을 실행합니다.
주니어가 "AI만 쓰니 실력이 안 쌓여요"라고 말하면 프론티어들은 "AI한테 물어봐라"고 답한다. 이 공감 능력의 부족을 지적한다.
AI 시대의 최대 수혜자를 자처하는 개발자가, AI와만 일한 지 1년이 넘은 시점에 느낀 위화감을 소설 《삼체》의 '지자(智子)' 비유로 풀어낸 에세이 핵심 주장: AI는 일자리를 가져가기 한참 전에, 몰입·소유감·성장의 사다리 같은 "일자리보다 먼저 없어지는 것들"을 조용히 먼저 가져간다 AI 찬반 어느 쪽도 아니며, "무한한 편의가 우리를 천천히 멈춰 세우는 것 아닌가"라는 사고실험
코드 생성의 상품화: 2025년 말 주요 AI 모델(Opus 4.5, GPT-5.2, Gemini 3 등)이 숙련된 엔지니어 수준의 코드를 수 분 만에 작성하게 되면서, 단순히 코드를 타이핑하는 기술의 가치는 급락했습니다.
엔지니어 역량의 재정의: AI가 코드의 대부분을 작성하는 세계에서 엔지니어의 진짜 차별점은 속도가 아니라 문제 분해, 아키텍처 설계, 신뢰성 검증, 트레이드오프 판단을 아우르는 ‘취향(Taste)’으로 이동했습니다.
2. '취향(Taste)'의 3가지 정의
최고의 엔지니어링 팀이 말하는 취향은 결국 '내부 평가 함수의 품질'이 어디로 향하는가에 따라 3가지 형태로 나뉩니다.
인식 (Recognition): 어떤 구현이 왜 더 나은지 논리적으로 설명하기 전에, 직관적·패턴 매칭으로 더 깔끔하고 확장 가능한 코드를 식별하는 능력입니다. (예: 팀의 행동 양식을 유도하기 위해 TypeScript 대신 Rust를 선택하는 결정)
나침반 (Compass): 무언가를 만들기 전에 '옳은 기능인지 아닌지' 방향을 아는 능력입니다. 수많은 프로토타입을 거치며 임의적이지 않고 필연적인 해법으로 수렴해 나가는 기준이 됩니다.
비전 (Vision): 현재가 아니라 2년 뒤에 중요해질 것을 내다보는 능력입니다. 지루한 코드 생성이 아닌, 시스템 설계 및 모델이 소프트웨어의 존재 이유를 이해하도록 만드는 제품 전략에 집중하는 것입니다.
3. 취향이 막대한 가치를 만드는 5가지 영역
영역
핵심 내용
취향이 발휘된 사례
Zone 1: 문제 선택
풀 가치가 있는 올바른 문제를 고르는 능력
에이전트에게 복잡한 권한 체계 대신 가장 단순하고 직관적인 접근법을 적용해 빠르게 출시
Zone 2: 시스템 아키텍처
결정의 반감기가 가장 길고 배당을 주는 구조 설계
"새 모델이 나올 때마다 코드를 삭제한다." 모델 주변의 비즈니스 로직을 최소화하여 얇게 유지
Zone 3: 품질 판단
AI가 알지 못하는 특정 맥락의 '충분함'을 검증
핵심 에이전트 코드는 인간이 리뷰하고, README 같은 비핵심 코드는 AI 리뷰에 위임 (30/70 규칙)
Zone 4: 사용자 공감
상대방(인간)이 실제로 필요로 하는 것을 이해
유저의 실수를 막기 위해 편의성 대신 안전을 택하는 샌드박스 기본값 설정
Zone 5: 커뮤니케이션
만든 결과물을 시장과 대상에 맞게 프레이밍
사람이 아닌 AI 에이전트가 읽고 성공할 수 있도록 코드베이스 구조를 설명한 AGENTS.md 작성
4. 나쁜 취향 vs 좋은 취향 (실제 사례 비교)
기술 스택 선택: 관습이나 유행에 따라 선택하면 '취향 없음', 모델의 강점(예: Claude 모델이 이미 잘 다루는 분포)이나 구체적인 제약 조건에 근거해 선택하면 '취향 있음'입니다.
AI 생성 코드 리뷰: AI가 짠 코드를 테스트만 통과했다고 바로 출시하면 '취향 없음', 전체 시스템 구조와 검증 계층(로컬 CI 등)의 정확성을 인지하고 코드보다 '생성 프롬프트(의도)'를 리뷰하면 '취향 있음'입니다.
5. 취향을 기르기 위한 90일 가이드 & 추천 프로젝트
[ 90일 훈련 계획 ]
1개월차 (인식 구축): 존경받는 개발자 도구 10개와 기술 논문 10편을 분석하며 첫 60초의 느낌과 우아한 방법론의 통찰을 기록합니다.
2개월차 (나침반 구축): 같은 종류의 예시(API 문서, 블로그 등) 두 개를 비교해 왜 하나가 더 나은지 구체적 메커니즘을 밝혀 적는 연습을 합니다.
3개월차 (비전 적용): 기존 프로젝트의 온보딩/README를 재설계하고, 모든 아키텍처 결정을 관습이 아닌 제1원칙(First Principles)으로 설명하는 시스템을 설계합니다.
[ 실행해 볼 수 있는 5가지 프로젝트 ]
AI 코드 평가 프레임워크 구축: AI가 생성한 PR이 프로덕션에 적합한지 채점하는 자체 루브릭 정의 (품질 판단력 향상)
오픈소스 온보딩 재설계: 타 기여자가 첫날 바로 PR을 보낼 수 있도록 개발자 경험(DX)의 첫 5분을 개선 (사용자 공감 능력 향상)
팀 내 '취향 테스트' 만들기: 엔지니어 간의 의견 불일치 지점을 찾아내어 조직의 표준과 아키텍처 기준을 정렬
48시간 제약 내 제품 출시: 극단적인 시간 제약 속에서 기능을 쳐내고 포함하는 필수적 취향 결정 강제 수행
사고를 바꾸는 기술 블로그 작성: 단순 튜토리얼이 아닌, 독자의 관점을 뒤흔드는 독창적인 시각 공유 (스토리텔링 능력 향상)
💡 결론
AI가 타이핑을 대신해 주면서 엔지니어의 전통적인 '손코딩 상실감'은 현실이 되었습니다. 하지만 어떤 코드가 존재해야 하고, 어떻게 구조화되어야 하며, 언제 충분한지를 아는 '취향'은 언제나 엔지니어링의 본질이었습니다. 앞으로 번창할 엔지니어는 이 취향 중심의 판단력에 경력을 최적화하는 사람입니다.
AI시대에 가장 중요한 스킬은 비판적·분석적 사고력이다. 가장 뻔한 질문에 가장 원초적인 답변이다. 그러나 이 진부함에는 그럴만한 이유가 있다.
비판적·분석적 사고력은 다양한 모습으로 나타난다.
첫째는 AI에게 날카롭고 의미 있는 질문을 던지는 능력이다. 좋은 답은 언제나 좋은 질문에서 출발한다. 질문의 수준은 결국 질문자가 가진 주제에 대한 이해도와 감각(Taste), 그리고 '내가 무엇을 원하는가'라는 의도성(Intentionality)과 주체성(Agency)에 비례한다. 그렇기 때문에 경험과 지식이 많은 T형 인재들이 유리할 수밖에 없다. 통찰력 있는 좋은 질문이 결국 모든 AI 워크플로우의 출발점이다.
둘째는 AI가 내놓은 결과를 비판적으로 분석하는 능력이다. AI의 결과물이 기술적, 표면적으로 완벽에 가까워 보일수록, 그 겉치레를 넘어 오류와 빈틈을 꿰뚫어 보는 비판적 판독력이 반드시 필요하다. 내용도 제대로 이해하지 못한 채 결과물만 가져다 쓰다 보면 인지 부채(Cognitive Debt)가 쌓이게 된다. 이 문제가 증폭되는 것을 막기 위해, 내가 만들어낸 AI 결과물을 온전히 이해한 뒤, 책임감을 가지고 타인의 프로세스에 병목을 만들지 않는 것이 매우 중요하다.
셋째는 AI 사용자로서 자기 자신을 성찰하는 능력이다. AI의 진정한 위험은 '사유의 마찰(불편하고 느린 숙고의 과정)'을 제거해버리는 데 있다. 자신도 모르게 이러한 패턴에 빠지고 있지 않은지 끊임없이 돌아보아야 한다. 그와 반대로 AI를 너무 단순한 도구처럼 최소한으로 사용하고 있지는 않은지도 생각해봐야 한다. 이 스펙트럼 위에서 적절한 밸런스를 유지하면서, AI 사용을 언제 멈춰야 할지 아는 것, 즉 사람이 개입하여 마무리 지어야 하는 타이밍을 아는 능력도 중요하다.