워터폴(Waterfall)

Why?

• 옛날에 선 코딩 후 수정 문제를 해결
  • 이제 좀 체계적으로 만들어야 해
  • 대규모 프로젝트에도 잘 동작해야 해

How?

요구분석-설계-구현-테스트-유지보스 단계를 가지며, 앞 단계가 완료되어야 다음 단계로 넘어가는 하향식/순차적으로 진행한다. 모든 단계마다 완료에 대한 명확한 명세가 존재하고 명세(문서)에 기반한 구현을 하게 된다.

• 요구분석
• 설계
• 구현
• 테스트
• 유지보스

장점

• 단계가 명확하고 이해하기 쉬움
  • 무엇을 해야하는지 명확하게 알 수 있고, 얼마나 진행되었는지 파악하기 쉬움
  • 관리자와 개발자 모두에게 쉬운 개발 방법
• 대규모 프로젝트도 관리하기 쉬움
  • 전체 일정이 산출됨
• 단계별 산출물이 존재함
  • 모든 단계마다 문서나 코드, 결과물이 존재하여 협업 개발 및 관리 용이
• 요구사항대로 완성됨
  • 보통 초기에 확정된 요구 사항대로 완성됨(그래야 함)

폭포수 때리기(문제점)

• 요구 사항은 애초에 명확하지 않다.
• 나중 단계에서 앞 단계의 문제가 드러난다.
• 요구 사항은 바뀔 수 있다.
• 그럼에도 피드백 시점이 너무 늦다.

애자일(Agile)

• 공정과 도구보다 개인과 상호작용
• 포괄정인 문서보다 작동하는 소프트웨어
• 계약 협상보다 고객과의 협력
• 계획을 따르기보다 변화에 대응하기
  를 더 가치있게 여긴다.(앞에 것도 중요)

애자일 본질

• 애자일은 방법론이 아니라 정신(핵심 가치)
  • 애자일 = 기민한, 민첩한
  • 비즈니스 요구 변화를 민첩하게 수용해라
  • 실패를 두려와하지 마라
  • 실행하고, 빨리 실패하고, 배우고, 다시 시도하라
• 애자일은 방법론이 아니라 정신이다. 이에 부합한 다양한 실천 방법이 나옴
  • 익스트림 프로그래밍(XP)
  • 스크럼(Scrum)

How?(Scrum)

워터폴과 단계는 동일하나 여러번 반복(각 단계 = Sprint)

1. 모든 할 일은 백로그로 관리(스프린트 진행 시 구체화)
2. 한 스프린트(2~4주)의 할 일만 정해 각 개발 단계를 짧고 빠르게 반복
3. 한 스프린트가 끝나면 제품 출시(매우 짧은 릴리스)
4. 고객에게 받은 피드백은 백로그에 추가하여 다음 스프린트에 반영
5. 1 ~ 4 반복하며 지속적으로 개선

장점

• 변화에 빠르게 대응 가능
  • 계획과 기능에 대한 변경이 쉬움
  • 문제점으 ㄹ조기에 발견할 수 있음
  • 고객이 원하는 기능을 빠르게 출시(항상 출시 가능한 제품 상태)
• 현실적인 목표 수립 가능
  • 비현실적인 1년치 목표가 아닌 예측 가능한 스프린트 단위의 목표만 세우면 됨
• 불필요한 관리 비용 감소
  • 어차피 변할 프로젝트 전체 일정을 무의미하게 관리할 필요가 없음
  • 할 일 목록인 백로그와 예측 가능한 스프린트 일정만 관리하면 됨
• 높은 고객 만족도
  • 고객은 원하는 기능을 자주 받아보고 피드백을 줄 수 있어 최종 결과물 역시 만족하게 됨

Before Agile

• 경영진의 지원 부족
  • 워터폴 모델과 달리 프로젝트에 대한 통제력 상실
• 애자일과 기업 문화가 충돌
• 적용시 초기 적응이 어려움
  • 전통적 방법론 대비 생소함
  • 변화를 이끌 경험자의 부족
  • 변화하려는 구성원들의 의지 부족

After Agile

• 잦은 요구 사항 변경
  • 스펙을 확정할 수 없어 잦은 재설계 발생
  • 애자일의 필수 절차인 리팩토링이 자주 생략됨(당함)
  • 이로 인해 지속적으로 코드 품질이 하락함(나쁜 구조에 계속 기능 추가)
• 빠르기만 한 릴리스
  • 짧은 개발로 완성도가 미흡하거나 충분히 테스트되지 않은 기능이 출시됨
  • 잦은 저질 제품 출시로 기업 이미지 타격
• 이름만 애자일인 막 코딩
  • 개발 단계를 생략한 채 그냥 개발하고 고치는 관행으로 복귀
  • 아무런 계획도 문서도 테스트도 없음

성공하귀 위해

• 애자일 팀 구성원의 역량 강화가 필수
  • 애자일의 방법만 적용한다고 결코 애자일은 달성되지 않음
  • 각자가 장인 정신을 갖고 자기 역량을 발전시켜야 점차 달성 가능
• 달성을 위한 연습
  • 클린 코드
  • 객체 지향 프로그래밍
  • 테스트 주도 개발
  • 리팩토링
  • 짝 프로그래밍
  • 코드 리뷰

배포의 문제

• 민첩하게 개발해도 배포가 안될 수 있음(테스트 팀, 운영 팀과의 문제)
• 개발과 운영은 각자 목적과 시스템이 있다.
• 개발은 속도가 중요하나 운영은 안정성이 중요하다.

데브옵스(DevOps)

Why?

• 개발하고도 빠른 배포가 불가능한 문제 해결
  • 개발, 테스트(QA), 운영 조직을 합쳐(소통/협업/통합) 빠른 릴리스를 달성하자
• 개발(Dev)과 운영(Operations)을 하나처럼
  • 애자일로 빠른 시간에 개발하고, 데브옵스로 빠른 시간에 배포하자
• 패트릭 드보어, 존 앨스퍼, 폴 해먼드
  • 운영은 안정화가 아니라 비즈니스를 가능하게 하는 것이 목표다.
  • 운영을 위한 운영이 아닌 비즈니스를 위한 운영으로 변화가 필요함

How?

• 통합, 빌드, 테스트, 배포, 모니터링 등 개발 사이클의 모든 부분을 신뢰 가능한 수준으로 자동화하면 개발에서 배포까지 빠르게 반복할 수 있다.
• 현실적인 제약을 해결하여 애자일의 이상적인 목표(빠른 리리스) 달성

장점

• 애자일의 문제점 해결
  • 개선-배포-피드백-개선 고리 형성을 발목 잡은 느린 배포 문제 해결
• CI/CD의 결과물
  • CI(Continuos Integration): 지속적 통합(빌드, 테스트, 머지)
  • CD(Continuous Deployment/Delivery): 지속적 배포 및 전달(릴리스)
• 폭풍 릴리스 가능
  • 구현~릴리스까지의 모든 부분이 자동화되어 미친 효율을 보임
  • 원하면 하루에 10번 이상도 릴리스 가능

오해와 비극

• 애자일 잘하기도 힘든데 이것까지?
  • 모든 과정을 신뢰 가능한 수준으로 자동화가 매우 어려움
  • 개발팀에만 애자일 도입하는 것도 힘든데, 테스트, 운영까지?
• 개발자가 테스트, 운영 다하는 거??
  • 관리자: 개발, 테스트, 운영팀 하나로 합치고 인원 줄이면 되겠다.
  • 개발자: 이걸 혼자 다하라고? 구현은 언제 하고?
• 전문성 및 책임 문제
  • 하나의 분야에만 집중할 때 해당하는 전문성이 생김(직무 분리)
    • 개발자 역시 혼자 이것 저것 얇게만 하다 보면 전문성이 결여됨
  • 전문성에 따라 부여됐던 책임 소재에 모호함이 생김

데브섹옵스(DevSecOps)

• 보안을 신경 써야한다.

Why?

• 더 이상 보안을 별개로 두고 개발하면 안 된다.
  • 소프트웨어는 출시 후 수많은 보안 공격에 시달림
  • 보안 문제 하나에 회사가 망할 수 있음
  • 증가한 리리스 만큼 증가한 보안 공격 대응에 한계점
• 개발, 보안, 운영
  • 애자일로 빠른 시간에 개발하고
  • 데브옵스로 빠른 시간에 배포하기 전에 보안을 챙기자

How?

• 기존 데브옵스 과정 전반에 자동화된 보안 취약점 진단 과정 추가
• 특정 한 부분이 아닌 자동화 파이프라인 전체 형성

딜레마

• 팀 전체가 보안에 중점 = 보안은 모든 사람의 책임
  • 개발과 보안을 함께 결정하고 구현
  • 모든 개발 단계마다 보안 개념을 녹여서 조기에 보안 위협 식별
• 모든 개발자가 보안 전문가는 아님
• 자기 분야가 아닌 일에 책임을 지기 어려움