기술블로그를 만들려고 했습니다. WordPress를 Docker로 올리고, 테마를 고르고, 플러그인을 세팅하고… 혼자서 하면 일주일은 걸릴 조사 작업이었습니다.
그런데 Claude Agent Teams를 사용하면 어떻게 달라질까요? AI 3명이 동시에 각자의 전문 영역을 조사해주는 것입니다.
이 글은 Claude Code의 Claude Agent Teams 기능으로 3인 AI 팀을 꾸려서, 기술블로그 구축에 필요한 조사를 병렬로 수행한 과정을 기록한 것입니다. 그리고 이 과정 자체가 바로 이 블로그의 첫 번째 콘텐츠가 됩니다.
왜 AI 에이전트로 블로그를 만드나요?
기술블로그를 처음부터 세팅하려면 결정해야 할 것이 산더미입니다.
– 테마는 뭘 쓸까? TT5 자식 테마? GeneratePress? – 코드 하이라이팅은? Prismatic? Enlightener? – SEO 플러그인은? Yoast? Rank Math? – Docker 설정은 최적화되어 있나? – 보안 취약점은 없나?
이런 조사를 하나씩 순차적으로 하면 시간이 오래 걸리고, 한 가지 관점에 매몰되기 쉽습니다. UI/UX를 고민하다 보면 보안을 놓치고, 아키텍처를 설계하다 보면 사용자 경험을 잊게 됩니다.
Claude Agent Teams는 이 문제를 해결합니다. 서로 다른 전문성을 가진 AI 에이전트 여러 명이 동시에 작업하고, 서로의 결과를 교차 검증합니다. 마치 실제 개발 팀처럼요.
그리고 무엇보다, 블로그를 만드는 과정 자체를 블로그의 첫 번째 콘텐츠로 쓸 수 있습니다. 메타 콘텐츠 전략이죠.
Claude Agent Teams란?
Claude Code의 Claude Agent Teams는 여러 Claude 인스턴스가 하나의 팀으로 협업하는 기능입니다. 현재 Research Preview 단계로 제공되고 있습니다.
기존의 Subagent와 핵심적으로 다른 점은 두 가지입니다.
1. Teammate끼리 직접 메시지를 주고받을 수 있다 — 결과만 보고하는 게 아니라, 서로 토론하고 피드백할 수 있습니다. 2. 사용자가 개별 Teammate와 직접 상호작용할 수 있다 — 특정 에이전트에게 추가 지시를 내리거나, 방향을 수정할 수 있습니다.
구성 요소를 정리하면 이렇습니다.
| 구성 요소 | 역할 |
|---|---|
| Team Lead | 메인 Claude Code 세션. 팀 생성, 작업 분배, 결과 종합 |
| Teammates | 독립된 Claude Code 인스턴스. 각자의 컨텍스트 윈도우에서 작업 수행 |
| Task List | 공유 작업 목록. Teammate가 claim하고 완료 처리 |
| Mailbox | 에이전트 간 메시징 시스템 |
Subagent와의 차이를 좀 더 구체적으로 비교하면 이렇습니다.
| Subagent | Agent Teams | |
|---|---|---|
| 통신 | 메인 에이전트에게만 결과 보고 | Teammate끼리 직접 메시징 |
| 조율 | 메인 에이전트가 모든 작업 관리 | 공유 태스크 목록으로 자가 조율 |
| 적합한 작업 | 결과만 필요한 집중 작업 | 토론과 협업이 필요한 복잡한 작업 |
| 토큰 비용 | 낮음 | 높음 (각 Teammate가 별도 인스턴스) |
한 줄 요약: 결과만 필요하면 Subagent, 서로 소통하며 협업해야 하면 Agent Teams.
설정 방법
Claude Agent Teams를 사용하려면 딱 한 가지 설정이 필요합니다.
settings.json 설정
~/.claude/settings.json에 다음을 추가합니다.
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}또는 셸 환경변수로도 설정할 수 있습니다.
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1설정 후 Claude Code를 재시작하면 Agent Teams가 활성화됩니다.
디스플레이 모드 선택
Teammate가 작업하는 모습을 어떻게 볼지 선택할 수 있습니다.
– In-process (기본): 모든 Teammate가 메인 터미널 안에서 실행. Shift+Up/Down으로 Teammate 간 이동.
– Split Panes: 각 Teammate가 별도의 터미널 pane에 표시. tmux 또는 iTerm2 필요.
저는 기본값인 In-process를 사용했습니다. Shift+Down으로 각 Teammate가 뭘 하고 있는지 들여다볼 수 있어서 꽤 재미있습니다.
Claude Agent Teams로 3인 AI 팀 설계하기
블로그 구축에 필요한 조사를 세 가지 관점으로 나눴습니다.
| 역할 | 담당 영역 | 작업 디렉토리 |
|---|---|---|
| UI/UX 담당 | 테마, 코드 하이라이팅, 타이포그래피, 다크 모드, SEO | `wp_content/themes/` |
| 기술 아키텍처 담당 | Docker 최적화, Redis, 플러그인 스택, CI/CD, 보안 | `docker-compose.yml`, `config/` |
| 코드 리뷰 담당 | 현재 설정의 보안/품질 리뷰, 다른 에이전트 결과 교차 검증 | 읽기 전용 (결과를 `docs/`에 작성) |
이 역할 분배에서 신경 쓴 것은 파일 충돌 방지입니다. Agent Teams에서 두 Teammate가 같은 파일을 동시에 수정하면 덮어쓰기가 발생할 수 있거든요. 각자 다른 파일을 담당하도록 명확히 분리했습니다.
실제 실행: 팀 생성 프롬프트
Agent Teams는 자연어로 팀을 만들 수 있습니다. 저는 다음 프롬프트를 사용했습니다.
yndl.dev 기술블로그를 구축하려고 해. 에이전트 팀을 만들어줘.
현재 상태:
- WordPress 6.9.1, Docker 기반 (MariaDB + PostgreSQL + Redis + Caddy)
- Twenty Twenty-Five 기본 테마, 플러그인 미설정, 콘텐츠 없음
- 프로젝트 경로: /Users/yoon/Projects/yndl.dev
3명의 teammate를 생성해줘:
1. UI/UX 담당: 기술블로그에 최적화된 테마 커스터마이징, 코드 블록 가독성,
다크 모드, SEO 구조, 네비게이션 UX를 설계해줘.
wp_content/themes/ 디렉토리를 중심으로 작업해.
2. 기술 아키텍처 담당: Docker 구성 최적화, Redis 캐시 전략,
플러그인 스택 선정, CI/CD 파이프라인, 보안 강화 방안을 설계해줘.
docker-compose.yml과 인프라 설정을 중심으로 작업해.
3. 코드 리뷰 담당: 다른 두 teammate의 제안을 교차 검증하고,
현재 설정 파일들의 보안/품질을 리뷰해줘.
보안 취약점, 설정 오류, 모범 사례 위반을 찾아줘.
각자 조사한 내용을 서로 공유하고,
최종적으로 구현 우선순위가 포함된 통합 로드맵을 만들어줘.이 프롬프트를 입력하면 Claude가 자동으로:
1. 팀을 생성하고 2. 공유 태스크 목록을 만들고 3. 3명의 Teammate를 spawn하고 4. 각자에게 작업을 분배합니다.
팁: 프롬프트에 “현재 상태”를 구체적으로 적어주는 게 중요합니다. Teammate는 Lead의 대화 이력을 상속받지 않기 때문에, spawn 시점에 필요한 컨텍스트를 모두 포함해야 합니다.
각 에이전트가 한 일
Agent 1: UI/UX 담당
UI/UX 담당 에이전트는 wp_content/themes/ 디렉토리를 중심으로 현재 테마를 분석하고, 기술블로그에 필요한 UX 요소를 조사했습니다.
주요 조사 결과:
테마 전략 — Twenty Twenty-Five(TT5)의 theme.json을 분석한 결과, 이미 Fira Code가 코드 블록 전용 폰트로 번들되어 있고 core/code 블록에 대한 스타일이 사전 정의되어 있었습니다. 기술블로그 출발점으로 상당히 유리한 조건이었죠. 4가지 테마 옵션을 비교한 끝에 TT5 자식 테마를 최종 권장했습니다.
코드 하이라이팅 — Prismatic, Code Syntax Block, Enlightener, SyntaxHighlighter Evolved 4가지 플러그인을 비교 분석했습니다.
| 플러그인 | 언어 수 | 줄 번호 | 복사 버튼 | 번들 크기 |
|---|---|---|---|---|
| Prismatic | 290+ | O | X | 소 |
| Code Syntax Block | 40+ | O | X | 최소 |
| Enlightener | 30+ | O | O | 중 |
| SH Evolved | 20+ | O | X | 중 |
최종 권장: Prismatic (Prism.js 모드) — 290+개 언어 지원, 사용 언어만 선택적 로드하여 성능 최적.
타이포그래피 — 한국어 기술블로그에서 한글, 영문 기술 용어, 코드 블록이 자연스럽게 어우러지려면 폰트 선택이 매우 중요합니다. Pretendard, Noto Sans KR, Spoqa Han Sans Neo를 비교한 결과 Pretendard를 권장했습니다. toss.tech, velog 등 국내 기술블로그에서 이미 검증된 조합이기도 하고요.
본문: Pretendard, -apple-system, BlinkMacSystemFont, system-ui, sans-serif
코드: "Fira Code", "JetBrains Mono", "Cascadia Code", monospace다크 모드 — CSS Custom Properties + JavaScript 토글 방식을 권장했습니다. TT5가 이미 --wp--preset--color--base, --wp--preset--color--contrast 등의 CSS 변수를 사용하고 있어서, 다크 모드에서 이 변수들의 값만 교체하면 전체 테마가 반응하는 구조입니다.
핵심 원칙 하나: 코드 블록은 라이트 모드에서도 항상 다크 배경. VS Code, GitHub, Stack Overflow 등 개발자들이 익숙한 패턴을 따르는 것이죠.
SEO — Yoast SEO와 Rank Math를 비교 분석한 결과 Rank Math 무료 버전을 권장했습니다. Yoast 유료에 포함된 리다이렉트 관리, 내부 링크 제안이 Rank Math에서는 무료로 제공되고, HowTo/FAQ 스키마도 무료로 지원합니다.
Agent 2: 기술 아키텍처 담당
아키텍처 담당 에이전트는 docker-compose.yml과 인프라 설정을 중심으로 분석했습니다.
Docker 최적화 — 현재 docker-compose.yml의 문제점을 7개 항목으로 정리하고 개선안을 제시했습니다. 가장 큰 것은:
– wordpress:latest 대신 wordpress:6.9.1-php8.3-apache로 버전 고정
– 모든 서비스에 헬스체크 추가
– 리소스 제한(memory, CPU) 설정
– PostgreSQL 제거 권장 (WordPress가 사용하지 않는 불필요한 서비스)
개선된 docker-compose.yml에서 Redis 설정 부분을 보면:
redis:
image: redis:7-alpine
restart: unless-stopped
command: >
redis-server
--maxmemory 128mb
--maxmemory-policy allkeys-lru
--appendonly yes
--appendfsync everysec
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 15s
timeout: 5s
retries: 3단순히 redis:alpine으로 띄우던 것에서 메모리 제한, LRU 정책, AOF 영속성까지 설정한 것을 볼 수 있습니다.
Redis 캐시 전략 — 3단계 캐시 레이어를 설계했습니다.
[사용자] -> [Caddy (정적 파일 캐시)] -> [WordPress + PHP]
|
[Redis Object Cache]
|
[MariaDB]플러그인 스택 — 카테고리별로 최적의 플러그인을 선정했습니다.
| 카테고리 | 추천 플러그인 | 우선순위 |
|---|---|---|
| SEO | Rank Math (Free) | P0 |
| Object Cache | Redis Object Cache | P0 |
| 코드 하이라이팅 | Prismatic (Prism.js) | P0 |
| 보안 | Wordfence (Free) | P1 |
| 마크다운 | WP Githuber MD | P1 |
| 이미지 최적화 | ShortPixel | P1 |
CI/CD 파이프라인 — GitHub Actions 기반의 배포 자동화와, 마크다운 파일을 WordPress REST API로 자동 발행하는 파이프라인까지 설계했습니다.
백업 전략 — 매일 DB 백업, 매주 wp-content 백업, 매 배포 전 전체 백업하는 스크립트를 작성했습니다.
Agent 3: 코드 리뷰 담당
코드 리뷰 담당 에이전트는 기존 설정 파일들을 꼼꼼히 검토하고, 다른 두 에이전트의 제안까지 교차 검증했습니다.
결과: 총 22개 이슈 발견
| 등급 | 건수 |
|---|---|
| Critical | 7 |
| Warning | 9 |
| Info | 6 |
Critical 이슈 중 핵심적인 것들:
Critical-01: PostgreSQL 포트가 외부에 노출됨
# 현재 상태 -- 위험!
postgres:
ports:
- "5432:5432" # 0.0.0.0:5432에 바인딩, 인터넷에서 직접 접속 가능WordPress가 사용하지도 않는 PostgreSQL이 인터넷에 포트가 열려 있었습니다. 방화벽이 없으면 DB에 직접 공격이 가능한 상태였죠.
Critical-04: WordPress DB 비밀번호와 MariaDB 비밀번호 불일치
.env 파일에서 MARIADB_PASSWORD와 WORDPRESS_DB_PASSWORD가 서로 다른 값으로 설정되어 있었습니다. MariaDB가 하나의 비밀번호로 사용자를 만들고 WordPress가 다른 비밀번호로 접속을 시도하면 인증 실패가 발생합니다. 이 두 값은 반드시 동일해야 합니다.
Critical-06: WordPress Salt/Key가 기본값 사용
// Docker 이미지의 기본 생성값이 그대로 사용 중
define('AUTH_KEY', getenv_docker('WORDPRESS_AUTH_KEY',
'ebe9df86132e4bef46fbc0cfa0f3869f7e23bc1f'));이 값들은 공개 리포지토리에 노출되어 있는 기본값이어서, 세션 하이재킹이나 인증 토큰 위조가 가능한 상태였습니다.
Critical-07: 필수 보안 상수 미설정
DISALLOW_FILE_EDIT, FORCE_SSL_ADMIN 등 WordPress의 기본적인 보안 상수가 하나도 설정되어 있지 않았습니다.
에이전트 간 교차 검증
Agent Teams의 가장 흥미로운 부분은 에이전트들의 결론이 독립적으로 수렴한다는 것입니다.
3명이 모두 동의한 것들
| 주제 | UI/UX | 아키텍처 | 코드 리뷰 |
|---|---|---|---|
| Prismatic 채택 | 290+ 언어, 경량 | Prism.js 업계 표준 | — |
| Rank Math 채택 | 무료로 Schema 지원 | 한국어 UI, 경량 | — |
| PostgreSQL 제거 | — | 불필요한 리소스 | 보안 위험 (포트 노출) |
| WordPress 이미지 버전 고정 | — | 재현 가능한 배포 | `latest` 태그는 위험 |
| Caddy에서 `http://` 제거 | — | 자동 HTTPS 활성화 | HTTPS 미설정 지적 |
3명의 에이전트가 각자 독립적으로 분석했는데, 주요 결정에서 완전히 일치하는 결론에 도달했습니다. 이건 단순히 “AI가 같은 답을 낸 것”이 아니라, 각자 다른 관점(사용성, 아키텍처, 보안)에서 출발해 같은 결론에 도달한 것이라 신뢰도가 높습니다.
관점이 겹치면서 보완된 것들
Redis 관련: 아키텍처 담당은 Redis 캐시 전략(메모리 제한, LRU 정책, AOF 영속성)을 설계했고, 코드 리뷰 담당은 Redis에 비밀번호가 없다는 보안 이슈를 찾았습니다. 두 관점이 합쳐져서 “기능적으로 최적화된 + 보안이 강화된” Redis 설정이 완성되었습니다.
코드 블록 관련: UI/UX 담당은 “코드 블록은 항상 다크 배경”이라는 디자인 원칙을 세우고 Prismatic의 테마 호환성을 분석했고, 아키텍처 담당은 Prismatic의 기술 사양(번들 크기, 선택적 로딩)을 분석했습니다. 같은 플러그인을 서로 다른 각도에서 검증한 셈이죠.
최종 결정 사항 요약
Phase 1 조사를 통해 다음과 같은 핵심 결정이 내려졌습니다.
| 항목 | 결정 | 근거 |
|---|---|---|
| 테마 | TT5 자식 테마 (`yndl-dev`) | Fira Code 번들, FSE 지원, 비용 제로 |
| 본문 폰트 | Pretendard | 한영 조화 우수, toss.tech/velog 검증 |
| 코드 폰트 | Fira Code (TT5 번들 유지) | 추가 로드 불필요, 리거처 지원 |
| 코드 하이라이팅 | Prismatic (Prism.js) | 290+ 언어, 경량, 업계 표준 |
| SEO | Rank Math (무료) | Schema 무료 지원, 한국어 UI |
| 캐시 | Redis Object Cache | Docker 환경 최적, Object Cache 필수 |
| 보안 | Wordfence + Caddy 하드닝 | 무료 방화벽 + 2FA + HTTP 보안 헤더 |
| 다크 모드 | CSS Custom Properties + JS 토글 | 플러그인 의존성 없음, TT5 CSS 변수 활용 |
| 콘텐츠 폭 | 645px -> 720px | 코드 블록 가로 폭 확보 |
| 본문 행간 | 1.4 -> 1.8 | 한글 가독성 최적화 |
비용과 토큰 사용량
Agent Teams의 가장 큰 단점은 비용입니다. 각 Teammate가 독립된 Claude 인스턴스이므로, 비용이 팀원 수에 비례해서 증가합니다.
이번 Phase 1 (조사 단계)의 경우:
– 총 인스턴스: 4개 (Lead 1 + Teammate 3) – 작업 유형: 읽기 중심의 조사/분석 – 산출물: 3개의 상세 보고서 (UI/UX 1,000줄, 아키텍처 1,430줄, 코드 리뷰 760줄)
비용 절감 팁
조사 단계에서는 Teammate에 Sonnet 모델을 지정하면 비용을 절감할 수 있습니다.
teammate들은 Sonnet을 사용해. Lead만 Opus로.코드 리뷰 Teammate는 읽기 중심이라 Sonnet으로도 충분한 품질이 나옵니다. 핵심 설계 결정이 필요한 작업만 Opus를 사용하는 전략이 효율적입니다.
비용 대비 가치
솔직히 토큰 비용만 보면 Claude Agent Teams는 비쌉니다. 하지만 3명의 에이전트가 동시에 작업해서 나온 결과물의 폭과 깊이를 생각하면 이야기가 달라집니다.
– UI/UX 보고서: 8개 섹션, 플러그인 4종 비교, 폰트 6종 비교, 다크 모드 3가지 방식 비교 – 아키텍처 보고서: 8개 섹션, 개선된 docker-compose.yml, CI/CD 파이프라인, 백업 스크립트 – 코드 리뷰 보고서: 22개 이슈 발견, 우선순위별 수정 체크리스트
이걸 혼자서 하려면? 최소 2~3일은 걸렸을 겁니다.
잘된 점과 아쉬운 점
잘된 점
병렬 조사의 효과가 확실합니다. 3가지 관점에서 동시에 분석하니 놓치는 것이 줄었습니다. 특히 코드 리뷰 담당이 다른 두 에이전트가 미처 생각하지 못한 보안 이슈(PostgreSQL 포트 노출, 비밀번호 불일치)를 잡아낸 것이 인상적이었습니다.
결론의 수렴이 신뢰를 줍니다. 서로 다른 관점에서 출발한 에이전트들이 같은 결론(Prismatic, Rank Math 등)에 도달하면, 그 결정에 대한 확신이 높아집니다.
조사 결과가 체계적입니다. 각 에이전트가 우선순위(P0/P1/P2)를 매겨서 보고서를 작성하니, 바로 실행 가능한 로드맵이 나왔습니다.
아쉬운 점
Teammate 간 실시간 토론이 기대보다 적었습니다. 이론적으로는 Teammate끼리 메시지를 주고받으며 토론할 수 있지만, 실제로는 각자 독립적으로 조사하고 결과를 보고하는 형태에 가까웠습니다. “경쟁 가설” 스타일의 토론을 유도하려면 프롬프트에서 더 명시적으로 요청해야 할 것 같습니다.
컨텍스트 전달의 한계가 있습니다. Teammate는 Lead의 대화 이력을 상속받지 않습니다. 그래서 spawn 프롬프트에 충분한 컨텍스트를 넣어줘야 하는데, 이게 누락되면 에이전트가 엉뚱한 방향으로 갈 수 있습니다.
모니터링이 필요합니다. 공식 Best Practices에서도 “팀을 방치하지 말고 진행 상황을 확인하라”고 합니다. 실제로 가끔 Teammate가 과도하게 넓은 범위를 조사하거나, 요청하지 않은 부분까지 파고드는 경우가 있었습니다.
다음은? Phase 2 구현
Phase 1에서 조사와 설계가 끝났으니, Phase 2에서는 실제로 구현을 시작합니다.
에이전트 팀을 만들어서 기술블로그 기반을 구축해줘.
1. UI/UX 담당: TT5 자식 테마(yndl-dev)를 생성하고
기술블로그용 블록 패턴을 설정해줘.
작업 파일: wp_content/themes/yndl-dev/
2. 아키텍처 담당: docker-compose.yml에 Redis Object Cache 연동을 추가하고,
wp-config.php 보안 설정을 강화해줘.
작업 파일: docker-compose.yml, config/
3. 코드 리뷰 담당: 두 teammate의 변경사항을 실시간으로 리뷰하고,
보안/호환성 이슈를 즉시 피드백해줘.Phase 2의 과정은 다음 에피소드에서 다룰 예정입니다.
정리
Claude Agent Teams로 기술블로그 구축을 시작하면서 배운 것들을 정리합니다.
1. Claude Agent Teams는 조사/리뷰 단계에서 가장 빛납니다. 공식 문서에서도 “코드 작성보다 PR 리뷰, 라이브러리 조사 같은 읽기 중심 작업부터 시작하라”고 권장합니다. 실제로 Phase 1에서 가장 효과적이었습니다.
2. 역할 분배가 핵심입니다. 단순히 “3명을 만들어줘”가 아니라, 각 에이전트의 전문 영역과 작업 디렉토리를 명확히 지정해야 합니다. 파일 충돌 방지도 미리 설계해야 합니다.
3. 교차 검증의 가치가 큽니다. 서로 다른 관점에서 같은 결론에 도달하면 신뢰도가 높아지고, 한 에이전트가 놓친 것을 다른 에이전트가 잡아냅니다.
4. 프롬프트에 충분한 컨텍스트를 넣어야 합니다. Teammate는 Lead의 대화 이력을 상속받지 않으므로, “현재 상태”를 구체적으로 설명해야 합니다.
5. 비용은 높지만 가성비는 있습니다. 토큰 비용이 팀원 수에 비례하지만, 조사의 폭과 깊이, 교차 검증의 품질을 고려하면 충분히 값어치가 있습니다.
블로그를 만드는 과정 자체가 블로그의 콘텐츠가 되는 구조. 이 메타적인 재미가 시리즈를 계속 이어갈 동력이 됩니다.
시리즈 안내: AI 팀과 함께 기술블로그 만들기
이 시리즈는 Claude Code Agent Teams로 기술블로그를 구축하는 전 과정을 기록합니다. 블로그를 만드는 과정 자체가 블로그의 콘텐츠가 되는 메타 콘텐츠 전략입니다.
| 회차 | 제목 | 내용 | 상태 |
|---|---|---|---|
| 1 | Agent Teams란? 3인 AI 팀 구성기 | Agent Teams 설정, 팀 역할 설계, 첫 실행 경험 | 현재 글 |
| 2 | AI 3인이 내 블로그를 진단했다 | UI/UX, 아키텍처, 코드 리뷰 각각의 조사 결과와 상호 피드백 | 발행 |
| 3 | Caddy와 싸운 하루: 리다이렉트 루프 3연전 | Caddy 리버스 프록시 설정 중 마주친 리다이렉트 루프 트러블슈팅 | 발행 |
| 4 | Docker + WordPress + Redis: AI가 설계한 인프라 적용기 | 아키텍처 Teammate의 분석 결과, 최적화 적용 과정 | 발행 |
| 5 | 기술블로그 UX: 코드가 읽히는 블로그 만들기 | 테마 커스터마이징, 코드 하이라이팅, 다크모드 적용기 | 발행 |
| 6 | AI 코드 리뷰어가 찾아낸 22개 이슈 | 보안 이슈, 설정 오류, 모범 사례 적용기 | 발행 |
| 7 | 마크다운으로 글 쓰고 자동 발행하기 | GitHub -> WordPress 파이프라인 구축기 | 예정 |
| 8 | AI 팀 vs 혼자 코딩: 비용 대비 효과 분석 | 토큰 사용량, 작업 시간, 품질 비교 회고 | 예정 |
각 포스트에는 실제 프롬프트, AI 간 대화 발췌, Before/After 비교, 비용 데이터가 포함됩니다.
*이 글은 Claude Code Agent Teams (Research Preview)를 사용하여 작성되었습니다.* *프로젝트: yndl.dev*