오늘 공부한 내용
오늘 공부한 내용:
- --- ## 🏗️ 소프트웨어 개발의 뼈대: 개발 프로세스와 관리 프로세스 개발은 단순히 코드를 치는 행위가 아닙니다. **개발 프로세스**가 '무엇을, 어떻게 만들 것인가'라는 기술적 경로를 제시한다면, **관리 프로세스**는 그 과정이 정해진 자원 내에서 원활히 진행되도록 돕는 공통의 룰입니다. ### 1. 개발 프로세스의 4단계 (Core) 모든 방법론의 기초가 되는 4단계입니다. 추상적인 아이디어가 물리적인 실체로 변하는 과정입니다. | 단계 | 핵심 질문 | 주요 활동 | | --- | --- | --- | | **분석 (Analysis)** | 무엇을(What) 만들지? | 요구사항 정의, 사용자 시나리오 작성 | | **설계 (Design)** | 어떻게(How) 만들지? | 아키텍처 정의, DB 설계(ERD), API 설계, UI/UX | | **개발 (Development)** | 실제 구현 | 코딩, 환경 구축, 코드 컨벤션 준수 | | **테스트 (Test)** | 제대로 작동하나? | 단위/통합 테스트, 버그 수정, 성능 검증 | --- ## 🌊 전통적 방식(Waterfall) vs 🏃 애자일 방식(Agile/Scrum) 가장 많이 비교되는 두 패러다임입니다. 어떤 것이 더 좋다기보다 **프로젝트의 성격**에 따라 선택해야 합니다. ### 비교 요약 * **워터폴 (Waterfall):** 순차적 진행. 계획이 철저하고 문서화가 중요합니다. 요구사항이 명확한 대규모 프로젝트에 적합합니다. * **애자일 (Agile):** 반복과 점진. 작동하는 소프트웨어를 빠르게 내놓고 피드백을 받습니다. 변화가 잦은 스타트업이나 신규 서비스에 적합합니다. > **관리의 철십자 (Iron Cross):** 범위, 일정, 비용, 품질은 서로 트레이드 오프 관계에 있습니다. 애자일은 이 중 '범위'를 유연하게 조정하여 '품질'과 '일정'을 지키는 전략을 취합니다. --- ## 🔄 스크럼(Scrum) 프로세스 깊이 보기 스크럼은 애자일을 실천하는 가장 대표적인 프레임워크입니다. 단순히 보드를 쓰는 것이 아니라 **반복(Iteration), 협업(Collaboration), 적응(Adapt)**의 철학을 실천하는 것이 본질입니다. ### 스크럼의 주요 이벤트 (5단계) 1. **제품 백로그 (Product Backlog):** 해야 할 일들의 우선순위 목록. 2. **스프린트 계획 (Sprint Planning):** 이번 주기(보통 2주)에 할 일을 결정. 3. **데일리 스크럼 (Daily Scrum):** 매일 15분간 진행 상황 및 장애물 공유. 4. **스프린트 리뷰 (Sprint Review):** 결과물 시연 및 피드백 수렴. 5. **스프린트 회고 (Retrospective):** 팀의 일하는 방식 개선 (KPT: Keep, Problem, Try). --- ## 🛠️ 엔지니어링 실천법 (Engineering Practices) 프로세스(절차)만 도입한다고 애자일해지지 않습니다. 코드가 썩지 않도록 뒷받침하는 **엔지니어링 기술**이 필수입니다. * **TDD (테스트 주도 개발):** 테스트 코드를 먼저 작성하여 설계의 결함을 줄임. * **CI/CD (지속적 통합/배포):** 빌드와 배포를 자동화하여 언제든 배포 가능한 상태 유지. * **리팩토링:** 외부 동작은 유지하되 코드 구조를 개선하여 기술 부채 방지. * **아키텍처 스타일:** 모노리스, 마이크로서비스(MSA), 헥사고널 아키텍처 등 서비스 규모에 맞는 구조 선택. --- ## 🔧 협업 도구 및 마음가짐 ### 도구보다 사람 (ALM Tools) * **Jira/Trello:** 칸반 보드 및 번다운 차트를 통한 시각적 진척 관리. * **Notion:** 기술 위키, 회의록, 요구사항 명세서 통합 관리. * **중요:** 도구가 사람을 조종하게 하지 마세요. 팀의 규칙(Ground Rule)이 먼저입니다. ### 소프트웨어 장인정신 (Software Craftsmanship) 단순히 '작동하는' 코드를 넘어 **'잘 만들어진'** 코드를 추구해야 합니다. 고객과의 협업은 단순한 계약 관계가 아닌 생산적인 동반 관계여야 하며, 전문가는 자신의 일에서 의미를 찾아야 합니다. ---