Claude 를 팀프로젝트에 적용시키기

김영준·2026년 5월 6일

claude code

ClaudeCode

목록 보기

6/8

Claude Code를 팀 프로젝트에 녹이는 방법 — 하네스 엔지니어링부터 자동 리뷰까지

AI 코딩 도구가 쏟아지는 시대, "팀 전체가 일관되게 쓰는 것"이 진짜 경쟁력이다.

들어가기

AI의 발전 속도가 무섭다. 불과 1년 전만 해도 "AI가 코드를 짜준다"는 말이 과장처럼 들렸는데, 지금은 Claude Code, Cursor, Copilot 같은 도구들이 실무 개발 흐름에 깊숙이 파고들었다.

나는 현재 팀 프로젝트에서 여러 Agent, OhMyClaudeCode(OMC), hooks, skills, 그리고 MCP(Model Context Protocol) 기반의 Jira·GitHub 연동을 함께 사용하며 코드를 생성하고 있다.

그런데 어느 순간 이런 생각이 들었다.

"나만 잘 쓴다고 되는 게 아니잖아?"

팀원마다 Claude Code를 제각각으로 쓰면 커밋 컨벤션도, 코드 구조도, 리뷰 방식도 전부 달라진다. 결국 AI를 도입했는데 오히려 유지보수 비용이 늘어나는 역설이 생긴다.

이 글은 그 문제를 어떻게 해결했는지, Claude Code를 팀 단위로 체계화한 경험을 공유하는 글이다. 하네스 엔지니어링, 공유 Skills/Agents/Hooks 설계, GitHub Actions를 통한 자동 리뷰까지 최대한 구체적으로 다룬다.

전체 코드 작성 흐름

팀이 합의한 개발 흐름은 다음과 같다.

요구사항 분석 (전체 팀)
        |
       설계 (하네스 엔지니어링 + TDD 작성)
        |
       구현 (DDD 기반, 공유 Agents/Skills/Hooks)
        |
       검증 (자동 리뷰 + 팀원 코드 리뷰)

각 단계를 하나씩 뜯어보자.

1단계 — 요구사항 분석: 전체 팀이 함께

요구사항 분석은 절대 파트별로 쪼개서 하지 않는다. 백엔드가 따로 분석하고, 프론트가 따로 분석하면 나중에 인터페이스에서 충돌이 생긴다. 전체 팀이 같은 언어로 요구사항을 이해해야 한다.

이 단계에서 Claude Code를 직접 쓰지는 않지만, 분석 결과물은 이후 AI가 읽을 수 있는 형태로 반드시 문서화한다.

우리가 사용하는 형식 예시:

## Feature: 사용자 주문 취소

### 배경
- 주문 후 30분 이내에만 취소 가능
- 결제 취소는 PG사 API를 통해 처리

### 핵심 규칙
1. 주문 상태가 PENDING 또는 CONFIRMED일 때만 취소 가능
2. 취소 요청 시 재고 복구 이벤트가 발행되어야 함
3. 취소 완료 시 사용자에게 이메일 알림 전송

### 예외 케이스
- 이미 배송 시작된 경우 → 400 에러
- PG사 환불 실패 시 → 보상 트랜잭션 롤백

이 문서가 나중에 TDD Agent의 입력값이 된다.

2단계 — 설계: 하네스 엔지니어링

"하네스(Harness)"라는 단어는 말의 안장에서 왔다. 말이 원하는 방향으로 달릴 수 있도록 틀을 잡아주는 것처럼, AI가 올바른 길을 벗어나지 않도록 사전에 구조를 잡아두는 행위를 하네스 엔지니어링이라고 부른다.

AI에게 "주문 취소 기능 만들어줘"라고 던지면 AI는 코드를 만들긴 한다. 하지만 그 코드가 팀의 아키텍처 원칙을 따르는지, 도메인 경계를 침범하지 않는지는 보장할 수 없다. 하네스가 없으면 AI는 점점 방향을 잃고, 코드베이스는 스파게티가 된다.

하네스의 구성 요소

우리 팀은 하네스를 크게 두 층으로 관리한다.

(1) 공통 하네스 — `CLAUDE.md` & `.claude/`

프로젝트 루트의 CLAUDE.md에는 팀 전체가 지켜야 할 공통 규칙을 명시한다.

# CLAUDE.md

## 아키텍처 원칙
- 이 프로젝트는 DDD(Domain-Driven Design) 기반으로 설계되어 있다.
- 도메인 레이어는 인프라 레이어를 절대 직접 참조하지 않는다.
- 모든 외부 I/O는 Port/Adapter 패턴을 통해 추상화한다.

## 코딩 컨벤션
- 언어: Kotlin, Spring Boot 3.x
- 네이밍: 클래스는 PascalCase, 함수/변수는 camelCase
- 함수 길이: 단일 책임 원칙에 따라 20줄을 넘기지 않도록 노력한다
- 예외 처리: CustomException을 상속받아 도메인별 예외를 정의한다

## 금지 사항
- 비즈니스 로직을 Controller 레이어에 절대 작성하지 않는다
- JPA Entity를 DTO로 직접 반환하지 않는다
- 하드코딩된 매직 넘버/문자열 사용 금지

.claude/ 디렉터리에는 기능별 세부 규칙을 파일로 분리해둔다.

.claude/
├── agents/
│   ├── endpoint-creator.md     # REST API 엔드포인트 생성 규칙
│   ├── tdd-writer.md           # TDD 작성 Agent 프롬프트
│   └── domain-designer.md      # 도메인 설계 Agent 프롬프트
├── hooks/
│   ├── pre-commit.md           # 커밋 전 검증 규칙
│   └── post-edit.md            # 코드 수정 후 자동 실행 규칙
└── skills/
    ├── commit.md               # /commit 스킬 정의
    ├── review.md               # /review 스킬 정의
    └── swagger.md              # /swagger 스킬 정의

(2) 개인 하네스 — 전문 영역 강화

공통 하네스 위에 각 팀원이 자신의 전문 영역에 맞게 개인 하네스를 추가한다.

팀원 A (보안 담당)의 개인 하네스 예시:

## 보안 체크리스트 (자동 적용)
- SQL 쿼리 작성 시 반드시 PreparedStatement 또는 JPA를 사용할 것
- 사용자 입력값은 항상 Validation 어노테이션으로 검증할 것
- 민감 정보(비밀번호, 토큰)는 절대 로그에 출력하지 않을 것
- JWT 검증 로직은 SecurityConfig에만 집중시킬 것
- CORS 설정은 화이트리스트 방식으로만 허용할 것

본인 (성능/자원관리 담당)의 개인 하네스 예시:

## 성능 및 자원관리 체크리스트 (자동 적용)
- N+1 문제 방지: 연관 엔티티는 @EntityGraph 또는 fetch join 활용
- 페이지네이션 없는 전체 조회 쿼리 작성 금지
- DB 커넥션은 try-with-resources 패턴으로 반드시 반환
- 캐싱이 가능한 데이터는 @Cacheable 적용 여부를 항상 검토
- 비동기 처리가 가능한 작업은 @Async 또는 이벤트 기반으로 분리

리뷰 시 이 두 개의 하네스가 서로를 보완한다. 내가 성능에 집중하다 놓친 보안 이슈를 팀원이 잡아주고, 반대도 마찬가지다.

TDD 기반 설계

하네스를 잡았다면, 구현 전에 반드시 테스트를 먼저 작성한다. 이를 위해 TDD Writer Agent를 사용한다.

요구사항 분석 문서를 Agent에게 넣으면 다음과 같은 테스트 코드 뼈대가 나온다.

// TDD Writer Agent가 생성한 테스트 뼈대
class OrderCancellationServiceTest {

    @Test
    fun `주문 상태가 PENDING일 때 취소 성공`() {
        // given
        val order = createOrder(status = OrderStatus.PENDING)

        // when
        val result = orderCancellationService.cancel(order.id)

        // then
        assertThat(result.status).isEqualTo(OrderStatus.CANCELLED)
    }

    @Test
    fun `배송 시작된 주문은 취소 불가`() {
        // given
        val order = createOrder(status = OrderStatus.SHIPPING)

        // when & then
        assertThrows<OrderCancellationException> {
            orderCancellationService.cancel(order.id)
        }
    }

    @Test
    fun `취소 완료 시 재고 복구 이벤트가 발행된다`() {
        // given
        val order = createOrder(status = OrderStatus.CONFIRMED)

        // when
        orderCancellationService.cancel(order.id)

        // then
        verify { inventoryEventPublisher.publishRestoreEvent(order.items) }
    }
}

이 테스트들이 구현 Agent의 "목표 지점"이 된다. AI는 이 테스트를 통과시키기 위한 코드를 작성하고, 팀원은 테스트가 통과되면 기능이 올바르게 구현됐음을 확신할 수 있다.

3단계 — 구현: DDD + 공유 Agents/Skills/Hooks

DDD가 AI와 잘 맞는 이유

구현 단계에서는 DDD(Domain-Driven Design) 원칙을 따른다. 도메인이 명확하게 분리되어 있으면, AI도 어느 파일에 어떤 코드를 써야 하는지 헷갈리지 않는다.

src/
├── domain/
│   ├── order/
│   │   ├── Order.kt                   # 도메인 엔티티
│   │   ├── OrderRepository.kt         # 포트 인터페이스
│   │   ├── OrderCancellationService.kt # 도메인 서비스
│   │   └── event/
│   │       └── OrderCancelledEvent.kt
│   └── inventory/
│       ├── Inventory.kt
│       └── InventoryRestorePort.kt
├── application/
│   └── order/
│       └── CancelOrderUseCase.kt      # 유스케이스
├── adapter/
│   ├── in/web/
│   │   └── OrderController.kt         # REST API
│   └── out/persistence/
│       └── OrderJpaRepository.kt      # JPA 구현체

이 구조가 있으면 AI에게 "OrderCancellationService에 취소 로직 추가해줘"라고 하면 AI는 다른 레이어를 침범하지 않고 정확히 그 파일만 수정한다.

공유 Agents

팀에서 공통으로 사용하는 주요 Agent들이다.

엔드포인트 생성 Agent (`endpoint-creator`)

유스케이스가 완성되면 이 Agent를 호출한다. Agent는 Controller, Request/Response DTO, Swagger 문서까지 한 번에 생성한다.

# endpoint-creator Agent 프롬프트 (요약)

주어진 UseCase를 분석하여 다음을 생성하라:
1. REST Controller (적절한 HTTP 메서드와 URL 패턴 준수)
2. RequestDto (Bean Validation 어노테이션 포함)
3. ResponseDto (필드 노출 최소화 원칙)
4. Swagger/OpenAPI 어노테이션

규칙:
- URL은 RESTful 컨벤션을 따른다 (명사형, 복수형)
- 에러 응답은 공통 ErrorResponse 형식을 사용한다
- 모든 API는 @Tag, @Operation 어노테이션으로 문서화한다

도메인 설계 Agent (`domain-designer`)

요구사항 분석 문서를 입력으로 받아 도메인 엔티티, 값 객체, 도메인 이벤트를 설계해준다. 이 Agent가 만든 설계를 팀원 전체가 검토하고 확정하면, 이후 구현은 그 설계를 따른다.

TDD Writer Agent (`tdd-writer`)

앞서 설명한 대로, 요구사항 문서를 받아 테스트 코드 뼈대를 생성하는 Agent다.

공유 Skills

Skills는 Claude Code에서 / 명령어로 호출하는 재사용 가능한 작업 단위다. 팀이 공유하는 주요 스킬들을 소개한다.

`/commit` — 계층별 커밋 분리

이 스킬이 없으면 누군가는 모든 변경사항을 feat(OrderCancellation/order): 주문 취소 기능 추가 하나로 커밋한다. 이 스킬은 변경된 파일을 분석해서 계층별, 기능별로 커밋을 나눠준다.

커밋 메시지 형식은 타입(파일명/도메인): 구조를 따른다.

# /commit 스킬 정의

변경된 파일을 분석하여 다음 순서로 커밋을 분리하라.
커밋 메시지 형식: `타입(파일명/도메인): 변경 내용`

타입 목록:
- feat: 새 기능 추가
- fix: 버그 수정
- refactor: 리팩토링 (기능 변경 없음)
- test: 테스트 추가/수정
- chore: 빌드/설정 변경

커밋 순서:
1. 도메인 레이어 (Entity, Domain Service, Port Interface)
2. 애플리케이션 레이어 (UseCase, ApplicationService)
3. 어댑터 레이어 (Controller, Repository 구현체)
4. 테스트 코드

각 커밋은 독립적으로 리버트 가능해야 한다.

실행 예시:

git commit → feat(OrderCancellationService/order): 주문 취소 도메인 서비스 추가
git commit → feat(CancelOrderUseCase/order): 주문 취소 유스케이스 구현
git commit → feat(OrderController/order): 취소 API 엔드포인트 추가
git commit → test(OrderCancellationServiceTest/order): 주문 취소 단위 테스트 작성

`/review` — 셀프 코드 리뷰

PR을 올리기 전에 스스로 검토하는 스킬이다. CLAUDE.md의 규칙과 개인 하네스를 기준으로 현재 변경사항을 리뷰해준다.

# /review 스킬 정의

현재 스테이징된 변경사항을 다음 기준으로 검토하라:

체크리스트:
- [ ] CLAUDE.md의 아키텍처 원칙 준수 여부
- [ ] 비즈니스 로직이 올바른 레이어에 위치하는지
- [ ] 예외 처리가 누락된 케이스가 없는지
- [ ] 테스트 커버리지가 핵심 분기를 포함하는지
- [ ] N+1 문제 가능성이 있는 쿼리가 없는지
- [ ] 하드코딩된 값이 없는지

문제가 있으면 파일명과 라인 번호와 함께 지적하라.

`/swagger` — API 문서 자동 보완

컨트롤러 파일을 분석해서 Swagger 어노테이션이 빠진 부분을 채워주는 스킬이다.

`/changelog` — 변경 이력 생성

PR에 포함된 커밋 메시지를 분석해서 사람이 읽기 좋은 CHANGELOG 항목을 자동 생성한다.

공유 Hooks

Hooks는 특정 이벤트(파일 저장, 커밋 전 등)에 자동으로 실행되는 작업이다.

`post-edit` Hook — 코드 수정 후 자동 검증

파일이 수정될 때마다 자동으로 실행된다. 단순 포맷 이슈는 자동으로 수정하고, 규칙 위반은 바로 경고를 준다.

# post-edit Hook

코드 파일이 수정된 후 자동으로 실행:

1. 임포트 정리 (사용하지 않는 import 제거)
2. 함수 길이 체크 (20줄 초과 시 분리 권고 메시지 출력)
3. TODO/FIXME 주석 감지 시 Jira 티켓 번호 추가 안내
4. 테스트 파일이 아닌 곳에서 println/console.log 감지 시 경고

`pre-commit` Hook — 커밋 전 게이트

/commit 스킬을 실행하기 전 자동으로 돌아가는 최종 관문이다.

# pre-commit Hook

커밋 직전에 실행:

1. 컴파일 에러 체크 (에러 있으면 커밋 차단)
2. 단위 테스트 실행 (실패 시 커밋 차단)
3. CLAUDE.md 핵심 규칙 위반 감지 시 경고 및 확인 요청
4. 민감 정보(API 키, 비밀번호 패턴) 포함 여부 스캔

4단계 — 검증: GitHub Actions + 자동 리뷰

검증은 전체 흐름에서 가장 중요한 단계다. 개인이 아무리 잘 작성해도 팀 전체의 코드가 합쳐지는 순간이 진짜 시험대다.

Claude 자동 리뷰 (GitHub Actions)

PR이 열리면 GitHub Actions가 자동으로 Claude API를 호출해서 1차 리뷰를 단다.

# .github/workflows/claude-review.yml
name: Claude Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Get PR diff
        id: diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > pr_diff.txt

      - name: Claude Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          python scripts/claude_review.py pr_diff.txt

# scripts/claude_review.py (핵심 로직)
import anthropic

SYSTEM_PROMPT = """
너는 Kotlin/Spring Boot 전문 코드 리뷰어다.
다음 기준으로 PR을 리뷰하라:

1. 아키텍처 원칙 위반 (DDD 레이어 침범 등)
2. 잠재적 버그 및 예외 처리 누락
3. 성능 이슈 (N+1, 불필요한 전체 조회 등)
4. 보안 취약점
5. 테스트 누락

각 이슈는 다음 형식으로 작성:
- 심각도: [CRITICAL / WARNING / INFO]
- 파일: [파일명:라인번호]
- 문제: [구체적인 문제 설명]
- 제안: [개선 방법]

칭찬할 점이 있으면 마지막에 간단히 언급하라.
"""

왜 자동 리뷰가 필요한가?: 여기서 핵심적인 문제가 하나 있다. 내가 짠 코드를 내 Claude Code로 /review 하면, AI도 내가 설정한 하네스와 컨텍스트 위에서 동작하기 때문에 내가 만든 코드를 당연히 맞다고 넘어가는 경향이 생길 수 있다. 일종의 확증 편향이다.

그래서 PR 시점의 자동 리뷰는 아무런 개인 하네스도 없는 순수한 Claude API로 돌린다. 내 맥락을 전혀 모르는 제3자의 시각으로 코드를 바라보는 것이다.

또한 OhMyClaudeCode(OMC) 같은 고도화된 도구를 PR마다 돌리면 API 비용이 기하급수적으로 늘어난다. 우리는 의도적으로 단순 API 호출로 "큼지막한 검증"만 하도록 설계했다.

자동 리뷰 결과는 PR 코멘트로 달린다:

🤖 Claude Auto Review

⚠️ WARNING | OrderController.kt:45
문제: 비즈니스 로직(주문 가능 시간 체크)이 Controller에 위치해 있습니다.
제안: 이 로직은 OrderCancellationService 또는 도메인 서비스로 이동하세요.

❌ CRITICAL | OrderJpaRepository.kt:23
문제: findAll()을 호출한 후 Stream으로 필터링하고 있습니다. N+1 위험 및
      메모리 과부하 가능성이 있습니다.
제안: WHERE 조건을 쿼리 레벨로 내리세요.

✅ 잘된 점: 도메인 이벤트 발행 패턴이 일관성 있게 잘 적용되어 있습니다.

팀원 코드 리뷰 — 개인 하네스가 빛을 발하는 순간

자동 리뷰를 보고 PR 작성자가 수정을 완료하면, 이제 팀원이 직접 리뷰에 들어간다. 이 단계가 바로 각자의 개인 하네스 엔지니어링이 진짜 가치를 드러내는 순간이다.

자동 리뷰는 일반적인 아키텍처 이슈나 명백한 버그를 잡아낸다. 하지만 "보안 관점에서 이 로직이 괜찮은가?", "이 쿼리가 트래픽이 몰릴 때 버텨낼 수 있는가?" 같은 전문 영역의 질문은 사람이 직접 해야 한다.

팀원은 자신의 전문 하네스가 적용된 Claude Code로 PR 코드를 분석한다. 예를 들어 보안 담당 팀원은 자신의 보안 하네스를 활성화하고 변경사항을 분석해서 날카로운 보안 리뷰를 남긴다. 나는 성능 하네스로 쿼리 효율과 자원 관리 측면에서 상대방 코드를 본다.

결과적으로 리뷰 흐름은 이렇게 된다:

[ PR 작성자 ]
  /review 스킬로 셀프 체크 (1차 필터)
        |
        ↓
[ GitHub Actions ]
  순수 Claude API 자동 리뷰 — 개인 편향 없는 객관적 검증 (2차 필터)
        |
  PR 작성자가 지적 사항 수정
        |
        ↓
[ 팀원 리뷰 ]
  보안 하네스 → 취약점 집중 분석
  성능 하네스 → 쿼리·자원 집중 분석
  서로 다른 전문 영역이 교차하며 상호 보완 (3차 필터)

혼자 짠 코드를 혼자 검증하는 구조가 아니라, 3단계의 서로 다른 시각이 겹쳐지는 구조다.

팀 약속 체계화 — 공유 컨벤션 저장소

개인이 각자 설정을 관리하면 시간이 지나면서 어긋난다. 우리는 .claude/ 디렉터리 전체를 Git으로 관리하고, 변경 시 팀 전체 동의를 받는다.

PR 컨벤션

## PR 제목 형식
[타입] 도메인명: 간결한 설명

타입 목록:
- feat: 새 기능
- fix: 버그 수정
- refactor: 리팩토링
- test: 테스트 추가/수정
- docs: 문서 수정
- chore: 빌드/설정 변경

예시: [feat] order: 주문 취소 기능 추가

## PR 본문 필수 항목
- 변경 이유 (Why)
- 주요 변경 내용 (What)
- 테스트 방법
- 관련 Jira 티켓 번호

MCP 연동 (Jira + GitHub)

Claude Code의 MCP를 통해 Jira와 GitHub를 연동해두면, /commit 스킬 실행 시 Jira 티켓 번호가 커밋 메시지에 자동으로 붙는다. PR 생성 시에도 관련 Jira 이슈가 자동으로 링크된다.

feat(OrderCancellationService/order): [PROJECT-142] 주문 취소 도메인 서비스 추가
feat(CancelOrderUseCase/order): [PROJECT-142] 주문 취소 유스케이스 구현

전체 흐름 요약

[ 요구사항 분석 ] ──────────────────────────────────────────
  전체 팀이 함께, 결과물은 마크다운으로 문서화

[ 설계 ]
  TDD Writer Agent → 테스트 뼈대 생성
  Domain Designer Agent → 도메인 설계
  공통 CLAUDE.md + 개인 하네스 적용

[ 구현 ]
  DDD 구조 위에서 Agent/Skills/Hooks 활용
  Endpoint Creator Agent, /swagger 스킬
  post-edit Hook (자동 검증), /commit 스킬 (계층별 커밋)
  MCP (Jira 연동) 으로 티켓 자동 추적

[ 검증 ]
  /review 스킬 → 셀프 체크 (1차: 본인 필터)
  pre-commit Hook → 컴파일/테스트 게이트
  GitHub Actions → 순수 Claude API 자동 리뷰 (2차: 편향 없는 객관적 검증)
  팀원 리뷰 → 개인 하네스 활용, 전문 영역 교차 보완 (3차: 사람 필터)

마치며

AI 코딩 도구를 "개인 생산성 도구"로만 쓰면 절반만 쓰는 것이다. 진짜 가치는 팀 전체가 일관된 방식으로 AI를 활용할 때 나온다.

핵심을 정리하면:

하네스는 AI의 고삐다. 잘 설계된 CLAUDE.md와 개인 하네스가 없으면 AI는 방향을 잃는다.
TDD는 AI의 목표 지점이다. 테스트가 먼저 있으면 AI가 무엇을 만들어야 하는지 명확하다.
공유 Agents/Skills/Hooks는 팀의 코드 문화다. 규칙을 문서로만 남기지 말고 자동화로 강제하라.
자동 리뷰는 팀원의 시간을 지킨다. 기계가 잡을 수 있는 이슈는 기계가 잡게 하고, 사람은 로직과 설계에 집중하라.

AI는 계속 발전하겠지만, 결국 그 AI를 어떻게 팀에 녹이느냐가 팀의 실력을 결정한다고 생각한다.

번외 — git worktree로 도메인 병렬 작업하기

팀 프로젝트를 하다 보면 이런 상황이 종종 생긴다.

"A 도메인 PR 리뷰가 달렸는데, B 도메인 PR 리뷰도 동시에 반영해야 해."

기존 방식이라면 어쩔 수 없이 순차적으로 처리해야 한다. A 도메인 수정 → 커밋 → B 도메인으로 브랜치 전환 → 수정 → 커밋. 시간 흐름에 따라 하나씩 처리하는 구조다.
git worktree를 쓰면 이게 병렬로 바뀐다.

# A 도메인 브랜치를 별도 디렉터리에 체크아웃
git worktree add ../project-order feature/order-cancel

# B 도메인 브랜치를 또 다른 디렉터리에 체크아웃
git worktree add ../project-user feature/user-profile

이제 터미널을 두 개 열어놓고, 각각 다른 디렉터리에서 Claude Code를 실행하면 된다. 두 도메인이 서로 영향을 주지 않는 독립적인 작업이라면, 말 그대로 동시에 진행할 수 있다.

Claude Code — order 리뷰 반영      Claude Code — user 리뷰 반영
            ↓                                   ↓
    feat(Order/order): 수정          feat(UserProfile/user): 수정
            ↓                                   ↓
           PR                                  PR

PR 리뷰가 두 도메인에 동시에 달렸을 때 특히 유용했다. 예전엔 한 도메인을 수정하는 동안 다른 도메인은 그냥 기다렸는데, 이제는 둘 다 동시에 Claude Code가 돌아가고 있다.

물론 도메인 간 의존성이 있는 경우엔 순서를 지켜야 하지만, DDD 기반으로 도메인이 명확하게 분리되어 있다면 대부분의 작업은 충분히 병렬로 처리할 수 있다. 이미 Sub-Agent를 병렬로 돌리는 구조를 갖추고 있다면, git worktree는 그 흐름을 워크스페이스 레벨까지 확장해주는 셈이다.

김영준

개발의 신이 될거다

이전 포스트

클로드 코드를 통한 프로토타입 개발

다음 포스트

Claude 를 팀프로젝트에 적용시키기

ClaudeCode

Claude Code를 팀 프로젝트에 녹이는 방법 — 하네스 엔지니어링부터 자동 리뷰까지

들어가기

전체 코드 작성 흐름

1단계 — 요구사항 분석: 전체 팀이 함께

2단계 — 설계: 하네스 엔지니어링

하네스의 구성 요소

(1) 공통 하네스 — `CLAUDE.md` & `.claude/`

(2) 개인 하네스 — 전문 영역 강화

TDD 기반 설계

3단계 — 구현: DDD + 공유 Agents/Skills/Hooks

DDD가 AI와 잘 맞는 이유

공유 Agents

엔드포인트 생성 Agent (`endpoint-creator`)

도메인 설계 Agent (`domain-designer`)

TDD Writer Agent (`tdd-writer`)

공유 Skills

`/commit` — 계층별 커밋 분리

`/review` — 셀프 코드 리뷰

`/swagger` — API 문서 자동 보완

`/changelog` — 변경 이력 생성

공유 Hooks

`post-edit` Hook — 코드 수정 후 자동 검증

`pre-commit` Hook — 커밋 전 게이트

4단계 — 검증: GitHub Actions + 자동 리뷰

Claude 자동 리뷰 (GitHub Actions)

팀원 코드 리뷰 — 개인 하네스가 빛을 발하는 순간

팀 약속 체계화 — 공유 컨벤션 저장소

PR 컨벤션

MCP 연동 (Jira + GitHub)

전체 흐름 요약

마치며

번외 — git worktree로 도메인 병렬 작업하기

클로드 코드를 통한 프로토타입 개발

하네스 설계 (+ omc)

0개의 댓글

Claude 를 팀프로젝트에 적용시키기

ClaudeCode

Claude Code를 팀 프로젝트에 녹이는 방법 — 하네스 엔지니어링부터 자동 리뷰까지

들어가기

전체 코드 작성 흐름

1단계 — 요구사항 분석: 전체 팀이 함께

2단계 — 설계: 하네스 엔지니어링

하네스의 구성 요소

(1) 공통 하네스 — CLAUDE.md & .claude/

(2) 개인 하네스 — 전문 영역 강화

TDD 기반 설계

3단계 — 구현: DDD + 공유 Agents/Skills/Hooks

DDD가 AI와 잘 맞는 이유

공유 Agents

엔드포인트 생성 Agent (endpoint-creator)

도메인 설계 Agent (domain-designer)

TDD Writer Agent (tdd-writer)

공유 Skills

/commit — 계층별 커밋 분리

/review — 셀프 코드 리뷰

/swagger — API 문서 자동 보완

/changelog — 변경 이력 생성

공유 Hooks

post-edit Hook — 코드 수정 후 자동 검증

pre-commit Hook — 커밋 전 게이트

4단계 — 검증: GitHub Actions + 자동 리뷰

Claude 자동 리뷰 (GitHub Actions)

팀원 코드 리뷰 — 개인 하네스가 빛을 발하는 순간

팀 약속 체계화 — 공유 컨벤션 저장소

PR 컨벤션

MCP 연동 (Jira + GitHub)

전체 흐름 요약

마치며

번외 — git worktree로 도메인 병렬 작업하기

클로드 코드를 통한 프로토타입 개발

하네스 설계 (+ omc)

0개의 댓글

(1) 공통 하네스 — `CLAUDE.md` & `.claude/`

엔드포인트 생성 Agent (`endpoint-creator`)

도메인 설계 Agent (`domain-designer`)

TDD Writer Agent (`tdd-writer`)

`/commit` — 계층별 커밋 분리

`/review` — 셀프 코드 리뷰

`/swagger` — API 문서 자동 보완

`/changelog` — 변경 이력 생성

`post-edit` Hook — 코드 수정 후 자동 검증

`pre-commit` Hook — 커밋 전 게이트