지속적 통합(Continuous Integration, CI)
초기에 발견하고 문제를 빠르게 해결하여 안정적인 코드 상태를 유지
지속적 배포(Continuous Deplotment, CD)
- CI로 통합된 코드를 실제 운영 환경에 자동으로 배포하는 프로세스
- 모든 변경사항이 자동으로 운영환경에 배포
- 사용자에게 최신 기능을 빠르게 배포
CI/CD 장점 및 툴
- 자동화로 인한 효율성 향상
- 빠른 피드백 루프
- 품질 개선
- 배포 속도 증가
- jenkins, Github Actions 등등
RAD(Rapid Application Development)
매우 짧은 개발주기 동안에 소프트웨어를 개발하기 위한 선형순차적 프로세스 모델
- 폭포수 모델보다 더 빠르고 유연하게 소프트웨어를 만들 수 있도록 설계
RAD 순서
- 요구사항 정의
- 프로토타입 개발
- 사용자 피드백
- 반복 및 개선
RAD 특징
- 요구 조건 수집, 프토로타입 및 설계를 일찍부터 반복적으로 테스트
- 3개월이내에 개발할 수 있을 정도의 주요 기능 모듈화 시 효과적
- 컴포넌트 재사용
RAD 주요 단계
- 비지니스 모델링
- 사용자와 함깨 비지니스 모델 작성/검토를 반복하고 분석
- 데이터 모델링
- 시스템에서 처리해야 할 데이터 객체에 대해 각 객체의 속성 및 객체 간의 관계를 정의
- 프로세스 모델링
- 사용자와 함께 프로토타입 개발/수정/보완 반복을 통해 시스템 설계
- 애플리케이션 생성
- 컴포넌트 관련 기술을 이용해 시스템 구축/운영
RAD 구성도
JRP(비지니스 모델링, 데이터 모델링, 프로세스 모델링)
요구사항 문석 & 모델링
JAD(Prototype 개발, 수정/보완 => 반복)
프로토타이핑 & 반복적 개선
프로토타입을 반복해서 수정&개선(Agile방식과 유사)
Cutover
실제 운영&배포
사용자에게 배포&운영 환경으로 전환
RAD 특성 및 장단점
특성
- 각 주요기능을 분리해서 개발
- 재사용 라이브러리 활용
- 프로토타이핑의 사용 및 사용자 참여 적극 유도
- 객체 기술을 효과적으로 활용
장점
- 신속한 개발 및 완전한 기능 구현 가능
- 재사용 가능한 컴포넌트 활용으로 시스템 시험기간이 짧아짐
- 프로토타입을 통해 초기 문제를 미리 발견 가능
- 유연한 요구사항 변경
단점
- 책임감을 가진 구성원이 없을 경우 실패함
- 적절한 모듈화, 가능성 전제해야 함
Agile
에자일(Agile) 방법론은 기민한, 좋은 것을 빠르고 낭비 없게 만드는 개발을 가능하게 해주는 방법론 전체를 의미
대뵤적인 애자일 방법론들
1. 익스트림 프로그래밍(XP)
2. 스크럽(Scrum)
3. 린 소프트웨어 개발(Lean Software Development)
Lean StartUp
린 스타트업은 낭비를 최소화하면서 신속하게 제품을 개발
시장과 고객의 피드백을 통해 지속적으로 개선
- 빠른 제품 개발과 시장 검증
- 고객 피드백 중심의 개선
- 불확실성 높은 환경에서의 효율적 접근
Lean StartUp의 핵심개념
- 최소기능제품(MVP)
- 지속적 배포(CD)
- 낭비 제거
- 고객 개발
- BML(Build-Measure-Lean)루프
BML
제품을 만들고 고객의 사용 데이터를 측정하며 다시 제품에 반영하는 반복적인 개선 사이클
아이디어 도출 및 가설 설정
Lean StartUp: 이 기능이 시장에서 성공할까?를 검증하는 것이 목적
RAD: 빠르게 제품을 만들어 개선하는 것
최소 기능 제품(MVP) 개발
Lean StartUp: 최초한의 기능(MVP)만 만들어 실제 고객이 필요로 하는지 검토 후 개발
RAD: AI추천 기능까지 빠르게 프로토타입으로 구현
시장 검증 단계
Lean StartUp: AI추천이 정말 필요한지 데이터를 보고 확신을 가진 후 개발 설정
RAD: AI추천 기능을 개발한 후 피드백을 받았을 것
학습 및 방향 수정
Lean StartUP: 시장 검증을 거친 후, 필요성이 확인된 기능만 추가
RAD: 처음부터 AI추천 기능을 포함하여 개발했을 것
지속적 개선 및 확장
Lean StartUp: 정말 필요한 기능인지 확인
RAD: 빠르게 새로운 기능을 추가하는 데 집중
Lean StartUp 장점 및 단점
장점
1. 초기 비용 절감
2. 고객 중심 개발
3. 유연한 사업 전략단점
1. 장기 비전 결여
2. 품질 저하 우려
3. 방향성과 거시적 전략의 부재
4. 수익성 문제
5. 시장 위험 분산의 어려움
RAD와 Lean StartUp의 다른점
Lean StartUp의 의사결정 방식: 데이터 기반
RAD의 의사결정 방식: 사용자 피드백 기반
XP프로세스
애자일 방법론 중 하나로, 빠르게 변화하는 요구사항에 대응하기 위해 등장한 개발 프로세스
XP프로레스 특징
- 테스트 주도 개발(TDD) -> 코드 작성 전에 테스트 먼저 설계
- 반복적 개발 -> 짧은 개발 주기(1~2주)로 기능 추가
- 페어 프로그래밍 -> 두명이 한 컴퓨터에서 코딩
- 지속적인 고객 협업 -> 고객의 요구사항을 자주 반영
의사소통, 단순성, 피드백, 용기, 존중
XP프로레스 실천사항
증분계획
- 사용자 요구사항을 스토리 카드에 기록
작은배포
- 최소한의 유용한 기능을 먼저 개발하여 배포
단순 설계
- 현재의 요구사항을 충족시키도록 설계를 수행
테스트 우선 개발
- 자동화된 단위 테스트 프레임워크를 사용
재구조화
- 코드개선이 가능한 부분을 발견하는 즉시 코드를 재구조화해야 함
XP, RAD, Lean StartUp 차이
사용자 스토리 작성
XP: 고객과 함께 사용자 스토리를 작성하고 작은기능단위로 개발
RAD: 개발자가 빠르게 프로토타입을 만들고 피드백 반영
Lean StartUp: MVP(최소 기능)부터 출시한 후 시장 검증
반복적 개발 및 테스트
XP: 개발 전에 테스트 먼저 작성(TDD), 작은 단위로 기능 반복 개발
RAD: 테스트보다는 빠른 프로토타이핑을 우선
Lean StartUp: 최소기능만 먼저 만들고 시장 검증
지속적인 고객 피드백 반영
XP: 고객과 긴밀히 협업하여 요구사항을 바로 반영
RAD: 프로토타입을 보고 사용자 피드백 반영
Lean StartUp: 데이터기반으로 기능을 설정
지속적인 개선 & 배포
XP: 코드 품질 유지 + 자동화된 배포(CI/CD)
RAD: 프로토타입 우선
Lean StartUp: 시장 반응을 보고 필요한 기능만 배포
Scrum 프로세스
반복적인 개발의 관리 관점을 강조
- 스프린트
- 제품 백로그 -> 개발할 제품에 대한 요구사항 목록
- 스프린트 백로그 -> 스프린트 목표에 도달하기 위해 필요한 작업 목록
- 제품 증분 -> 스프린트 결과로 나오는 실행가능한 제품
- 번다운 차트 -> 스프린트 백로그에 남아있는 작업 목록
- 번업 차트 -> 진행 사항을 보여주는 차트
- 제품 책임자
- 스크럼 마스터
DevOps
소프트웨어 개발과 IT운영을 통합하여 빠르고 안정적인 소프트웨어 배포를 가능하게 하는 문화
- CI/CD -> 지속적인 코드 통합&자동배포
- IaC -> 인프라 환경을 코드로 관리
- 모니터링 및 로깅 -> 성능 및 오류 실시간 감지
- 자동화된 테스트 -> 코드 변경 시 자동으로 테스트 수행
배포 주기는 하루에도 여러 번 가능하다.
RAD, Agile, DevOps 공통점
-
반복적 접근 및 지속적 개선
개발 주기를 반복하면서 사용자 및 고객의 피드백을 반영해 제품을 개선 -
협업과 소통 강조
-
빠른 대응
정리/요약
RAD : 빠른 프로토타이핑과 짧은 개발 주기를 통해 초기 사용자 피드백을 반영, 빠른 개발에 집중, 개발 초기의 신속함에 중점
Agile: 지속적인 협업, 유연하게 대응하는 개발 방법론, 유연한 반복 개발에 중점
DevOps: 개발과 운영을 통합 및 자동화에 중점
3주차 퀴즈나왔던 것들
페어 프로그래밍 장점 => 틀린 문제
1. 코드 품질 향상 및 버그 감소
2. 문서화 작업 최소화
3. 개발 속도 단축
CD(Continuos Deployment와 Continuos Delivery) 차이점
Continuos Deployment
모든 코드 변경 사항을 자동으로 배포
클라우드 기반 CI/CD 플랫폼 => Circle
CI/CD 장점
Iac이점
DevOps 목적 => 틀린 문제
대량 배포 목적은 아니다.
Lean StartUp과 RAD의 차이점
MVP 주된 목적
Scrum에서 PO의 역할
=> 제품의 백로그를 관리하고 우선순위를 정하는 역할
Agile의 목표
문서화를 철저히 수행하진 않는다. => 폭포수 모델
Agile은 문서화를 중요하게 여기진 않는다.
Scrum에서 Sprint Review의 주요 역할
Scrum 백로그의 정의
Scrum Master의 역할 => 틀린 문제
개발 프로세스를 관리하고 장애물을 해결하는 것
Scrum 번다운 차트의 역할
남은 작업량을 시각적으로 보여줌
Lean Startup은 시장 검증이 중요
WaterFall의 단점
고객의 피드백을 초기 개발 단계에서 반영하기 어렵다.
테스트단계가 후반부에 몰려있다.
XP에서 강조하는 핵심 원칙이 아닌 것 => 틀린 문제
긴 개발 주기
테스트 주도 개발, 페어 프로그래밍, 지속적인 고객 협업이 원칙
XP에서 강조하는 개발 방식이 아닌 것
문서화 중심의 개발
Agile방법론에서 Time-boxing이 의미하는 것
특정 작업이나 개발 단계에 고정된 시간 제한을 두는 기법
Agile원칙에 해당하지 않는 것
처음부터 완벽하게 모든 요구사항을 문서화해야한다.
Agile방법론이 더 적합한 경우
요구사항이 자주 변경되는 프로젝트
Agile 개발 방법론에서 가장 중요한 원칙
고객과의 지속적인 협업
