# [[Agile Software Development in Small Teams]]

## 📌 Brief Summary
소규모 팀(예: 2~5인)에서의 애자일 소프트웨어 개발은 프로세스 오버헤드를 최소화하고 빠른 피드백 루프를 유지하는 것을 핵심으로 합니다 [1, 2]. 복잡한 워크플로우(예: Git-Flow) 대신 가벼운 기능 브랜치(Feature-Branch)나 트렁크 기반(Trunk-Based) 개발을 채택하여 충돌을 방지합니다 [3, 4]. 또한, YAGNI(You Aren't Gonna Need It) 원칙과 기능 기반의 구조(Feature-Based Structure)를 적용하여 오버엔지니어링을 피하고 코드의 확장성과 유지보수성을 확보합니다 [5, 6].

## 📖 Core Content

*   **가벼운 브랜칭 워크플로우 (Lightweight Branching Workflows)**
    *   소규모 팀의 경우, 무겁고 복잡한 Git-Flow보다는 '단순 기능 브랜치 워크플로우(Simple Feature-Branch Workflow)'나 '짧은 수명의 기능 브랜치를 활용한 트렁크 기반 개발(Trunk-Based Development)'이 가장 적합합니다 [1-3].
    *   이를 통해 과도한 프로세스 부담 없이 코드 안정성을 지키고, 긴 브랜치 유지로 인한 대규모 병합 충돌을 피할 수 있습니다 [4, 7, 8].

*   **소규모 애자일 팀을 위한 핵심 규칙 (Key Rules for Collaboration)**
    *   **안정적인 메인 브랜치 유지:** `main` (또는 `master`) 브랜치는 항상 배포 가능하고 안정적인 상태를 유지해야 하며, 직접 푸시(Direct push)를 금지하는 보호 정책(Branch protection)을 적용해야 합니다 [1-3, 9].
    *   **단일 작업 브랜치와 원자적 커밋:** 모든 새로운 기능이나 버그 수정은 `main`에서 분기된 짧은 수명의 브랜치에서 진행하며(예: `feature/login-page`), 하나의 커밋에는 하나의 논리적 변경(Atomic Commits)만 담아야 합니다 [2, 3, 10, 11].
    *   **코드 리뷰와 병합 (PR & Merge):** 작업이 완료되면 Pull Request(PR)를 생성하고, 최소 1명 이상의 동료 리뷰와 CI 테스트 통과를 거쳐야만 병합할 수 있습니다 [9-12]. 병합 시에는 커밋 히스토리를 깔끔하게 유지하기 위해 Squash Merge를 권장하며, 병합된 브랜치는 자동으로 삭제합니다 [9, 10, 12, 13].

*   **애자일 환경의 소프트웨어 설계 원칙과 구조**
    *   **YAGNI 원칙:** 애자일 환경에서는 "You Aren't Gonna Need It(당장 필요하지 않은 기능은 만들지 말라)" 원칙이 필수적입니다. 실현되지 않을 수 있는 미래의 사용 사례를 위해 복잡한 기능을 미리 개발하는 것을 지양하여 불필요한 코드와 유지보수 부담을 줄여야 합니다 [5, 14].
    *   **기능 기반 구조 (Feature-Based Structure):** 기술적인 파일 유형이 아닌 비즈니스 기능(Feature)을 중심으로 코드를 폴더화하는 접근 방식은 애자일 개발 방법론과 매우 잘 맞습니다 [6, 15]. 기능들이 독립적으로 생성 및 구현될 수 있어 팀이 코드를 확장할 때 마찰이 적습니다 [6].

## ⚖️ Trade-offs & Caveats
*   **단순성 vs. 구조적 한계:** 가벼운 기능 브랜치 전략이나 트렁크 기반 개발은 소규모 팀(2~5명)에게 배우기 쉽고 프로세스 오버헤드가 적다는 강력한 장점이 있지만 [4, 8], 팀 규모가 크게 성장하거나 엄격히 예정된 릴리스 일정을 관리해야 하는 대규모 프로젝트에서는 한계가 있을 수 있습니다. 이 경우 무겁더라도 Git-Flow와 같은 릴리스/개발 브랜치가 분리된 전략이 필요할 수 있습니다 [4, 16].
*   **Trunk-Based Development의 높은 요구사항:** 트렁크 기반 개발은 빠른 통합을 가능하게 하지만, 팀원 간의 긴밀한 조율과 강력한 지속적 통합(CI) 환경 구축이 필수적입니다 [4, 8]. 강력한 CI 파이프라인 없이 빈번한 병합만 시도할 경우, 오히려 `main` 브랜치의 안정성이 위협받을 수 있습니다.
*   **YAGNI의 부작용:** YAGNI 원칙은 낭비되는 노력을 줄여주지만, 시스템의 전반적인 밑그림이나 미래의 확장성을 너무 고려하지 않고 개발할 경우(Oversimplify) 나중에 대대적인 아키텍처 수정이 필요해질 위험(Trade-off)도 존재합니다 [17].

## 🔗 Knowledge Connections

### Related Concepts

#### [Workflow & Version Control (버전 관리 및 협업 방식)]
- [[Feature-Branch Workflow]]
  - 연결 이유: 2~5인 규모의 소규모 팀에서 충돌을 최소화하고 가벼운 프로세스를 유지하기 위해 가장 널리 권장되는 핵심 Git 브랜치 전략이기 때문입니다 [2, 3].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 짧은 수명의 브랜치 관리와 Pull Request를 통한 비동기 코드 리뷰가 팀의 민첩성에 미치는 영향.
- [[Trunk-Based Development]]
  - 연결 이유: 숙련된 소규모 팀이 빠른 피드백과 CI/CD의 효율을 극대화하기 위해 선택할 수 있는 대안적 애자일 워크플로우입니다 [1, 4].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치 분리를 최소화하고 빈번하게 코드를 병합하는 것이 통합 문제를 어떻게 예방하는지.

#### [Software Engineering Principles (소프트웨어 공학 원칙)]
- [[YAGNI (You Aren't Gonna Need It)]]
  - 연결 이유: 애자일 환경에서 낭비를 줄이고 현재의 요구사항에만 집중하게 함으로써, 빠르고 가벼운 개발 주기를 유지하도록 돕는 핵심 설계 원칙입니다 [5, 17].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 과도한 사전 설계(Over-engineering)를 방지하여 개발 속도를 높이는 철학적 배경.
- [[Feature-Based Structure]]
  - 연결 이유: 컴포넌트를 기술적 역할이 아닌 비즈니스 기능(Feature) 단위로 묶어 독립성을 부여하는 구조로, 기능 단위로 개발과 배포를 반복하는 애자일 방법론과 직결됩니다 [6, 15].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스의 응집도(Cohesion)를 높이고 독립적인 기능 확장을 가능하게 하는 폴더 구조 설계법.

### Deeper Research Questions

- 소규모 애자일 팀이 성장하여 대형 팀(예: 10명 이상)이 될 때, 경량화된 Feature-Branch 워크플로우에서 Git-Flow와 같은 복잡한 워크플로우로 전환해야 하는 구체적인 임계점과 징후는 무엇인가?
- 소규모 팀이 Trunk-Based Development를 도입하기 위해 필수적으로 갖춰야 하는 CI/CD 파이프라인의 성숙도와 자동화 테스트의 커버리지 수준은 어느 정도인가?
- 프론트엔드 환경에서 Feature-Based Structure(혹은 Feature-Sliced Design)를 도입할 때, 공통 로직(Shared concerns)의 경계를 어떻게 정의해야 애자일 팀의 개발 속도 저하를 막을 수 있는가?
- YAGNI 원칙을 엄격하게 적용하면서 발생하는 기술 부채(Technical Debt)를 애자일 스프린트 내에서 안전하게 관리하고 리팩토링하는 체계적인 방법은 무엇인가?
- Pull Request 기반의 협업에서, 병합 지연을 방지하고 빠른 피드백을 유도하기 위한 이상적인 PR 크기 제한(예: 코드 라인 수)과 Atomic Commit 강제 방법은 무엇인가?

### Practical Application Contexts

- **Implementation:** 개발자는 작업을 시작할 때 `main` 브랜치에서 짧은 수명의 브랜치를 생성하고, 기능을 구현한 뒤 작고 논리적인 단위(Atomic Commits)로 쪼개어 자주 커밋합니다 [10, 13].
- **System Design:** 애플리케이션의 폴더 구조를 도메인이나 기능(Feature) 기준으로 설계하여, 소규모 팀원이 각자 다른 기능을 동시에 개발하더라도 서로의 코드 영역을 침범하지 않도록 합니다 [6].
- **Operation / Maintenance:** GitHub 등 저장소 설정에서 `main` 브랜치 보호(Branch Protection) 기능을 활성화하고, 최소 1명의 코드 리뷰 승인과 자동화 테스트(CI) 통과를 필수 병합 조건으로 강제하여 프로덕션 안정성을 확보합니다 [9].
- **Learning Path:** 소규모 프로젝트 팀을 구성할 때, 처음부터 무거운 룰을 강요하기보다 단일 기능 브랜치 생성, Pull Request를 통한 리뷰, Squash Merge를 이용한 깔끔한 히스토리 관리 등 핵심 워크플로우부터 학습시킵니다 [1, 13, 18].
- **My Project Relevance:** 현재 진행 중인 2-5인 규모 프로젝트에 불필요한 미래 확장을 대비한 코드를 작성하지 않는 YAGNI 원칙과, `feat/*`, `fix/*` 형태의 단순한 브랜치 전략을 도입하면 병합 충돌을 줄이고 빠르게 결과물을 낼 수 있습니다 [2, 4, 16].

### Adjacent Topics

- [[Continuous Integration (CI)]]
  - 확장 방향: 소규모 팀이 짧은 주기의 코드 병합(Merge)을 안전하게 수행할 수 있도록 뒷받침하는 자동화된 빌드 및 테스트 환경 구축 가이드로 확장.
- [[Conventional Commits]]
  - 확장 방향: 팀원 간의 변경 사항 커뮤니케이션을 일관되게 만들고 (`feat:`, `fix:` 등), 향후 릴리스 노트를 자동화하는 데 도움이 되는 커밋 작성 표준 규칙 탐구.

---
*Last updated: 2026-04-30*