SW공학
- 소프트웨어 공학의 정의와 개발과정
- 소프트웨어 공학은 인류의 이익을 위해서 소프트웨어와 관련된 원리, 지식, 도구등을 활용하여 새로운 제품, 도구등을 만드는 것
- 전통적인 소프트웨어 공학의 개발 과정(폭포수모델)
- 계획, 요구사항 분석, 설계, 구현, 시험 및 유지 보수 과정
- 프로젝트 계획
- 문제정의(무엇을 개발할지)
- 법적, 경제적, 기술적 타당성 조사
- 일정계획
- WBS(Work Breakdwon Structure)가 대표적
- 작업 분할 구조도
- 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업
- 수행사 및 담당자까지 지정
- 요구사항 정의
- 사용자의 요구사항과 시스템의 기능이 문서화되어야 하는 단계
- 고객과 개발 회사의 계약서로서의 가치를 가짐
- 설계
- 시스템 아키텍처 설계
- 소프트웨어 아키텍처 설계
- 컴포넌트 설계
- 클래스 관계 설계
- 데이터 베이스 설계
- 구현
- 실질적인 프로그래밍 단계
- 일반적으로 전체 개발 기간의 20%정도를 차지
- 테스팅
- 요구사항과 설계에 맞는지 점검 과정으로서 전체 개발 기간의 40%가까이를 차지
- 테스트 유형
- 유닛테스트(Unit Testing)
- 프로그램의 기본단위인 모듈에 대한 테스트를 수행하는 단위 시험
- 통합테스트(Integration Testing)
- 단위 시험 후 모듈들을 통합하여 테스트를 수행하는 통합 시험
- 시스템테스트
- 통합 시험 이후 소프트웨어와 다른 시스템 요소(하드웨어, 정보 등)들과 통합하여 시스템의 기능을 만족하는지 확인하는 시스템 시험
- 인수테스트
- 고객이 참여하여 고객 요구사항 만족 여부를 검증하는 인수 시험
- 유지보수
- 사용중 발생하는 여러 변경사항에 대해 적응하는 활동이며 변화에 따른 프로그램 추가/수정을 하는 과정
- 소프트웨어 개발 방법론
- 폭포수모델(waterfall)
- 계획, 요구사항 분석, 설계, 구현(프로그래밍), 시험, 유지보수의 순서로 시스템의 개발되는 전통적인 방법론
- 개념 정립에서 구현까지 하향식 접근방법을 사용하여 높은 추상화 단계에서 낮은 추상화 단계로 이동하는 모델
- 폭포수 방법론의 순차적이고 구조화된 접근 방식은 초기 단계에서의 광범위한 계획과 구조화된 개발 프로세스가 중요한 대규모 모놀리식 시스템의 개발에 적합
- 폭포수 모델의 장점
- 프로젝트 진행과정을 세분화하기 때문에 큰 프로젝트의 진척과 인력 관리가 용이
- 개발방법론의 초기 모델로서 많은 수행과 검증을 거쳐왔고, 대규모 시스템 구축에 있어 경험 축적
- man/month 기반의 비용산정과 일정산정의 용이
- 폭포수 모델의 단점
- 고객이 원하는 요구사항을 초기에 구체화 하기 어려움
- 오류발견과 수정이 순환적으로 발생하므로, 순차적 개발이 현실적으로 어려움
- 시스템 구축이 후반부에 가서야 완료 되는 경우엔, 시스템 문제점 파악 어려움
- 설계한 아키텍처의 문제가 후반부에 가서야 발견되는 경우가 많아, 수정의 어려움
- man/month 기반의 비용산정의 불합리성과 일정산정의 부정확함
- wbs 예시 포맷
- 애자일
- 기존 방법론은 프로젝트의 본질적인 목표보다 계획 수립, 문서화, 품질 관리 등 추가로 수행되는 작업을 위해 오버헤드 비용을 과다하게 요구
- 개발자들이 좋은 것을 빠르고 낭비없이 만들기 위해 경량화된 가벼운 개발방법론이 애자일
- 애자일 방법론의 단계
- 분석, 설계, 구현, 시험이 끊임없이 진행되는 반복 되는 순환적 개발과정
- 각 단계를 짧게 1-2주 정도의 짧은 기간(sprint)을 잡고 특정 기능이 동작하는 데모, 즉 최소 기능 제품(MVP-Minimum Viable Product)를 통해 배포후에 고객에게 시연하고 피드백을 통해 다시 반복적으로 분석,설계,구현,시험
- 요구사항의 변화가 자주 일어나거나 개발자가 소규모인 소형 또는 중간 사이즈의 비즈니스 시스템, 게임 소프트웨어 개발이 적합
- 애자일 방법론 중 하나로 스크럼(SCRUM) 방식이 널리 사용
- 스크럼 개발 방법론이란 특정 이슈를 bottom up방식을 통해 발행하여 문제를 공유하고 문제를 짧은 스탭을 통해 해결해 나가는 과정
- PO, PM(PL), 기획자, 개발자, 디자이너 등이 스크럼의 참여자
- 일반적으로 개발팀에서 scrum회의라 하면 우선순위별로 발행된 이슈에 대해 논의하고, 스프린트 별로 진척 상황을 회고 하는 것.
- 스크럼을 위한 툴로서 아틀라시안사의 JIRA라는 툴을 많이 사용
- JIRA의 활용
- 스프린트 생성 → 스토리 생성 → 작업 생성 등의 분류 과정을 통해 작업 생성
- 이때 작업 생성은 실무에서 이슈발행, 티켓(TICKET)발행, 백로그 생성등의 용어로 사용
- 만들어진 스프린트가 시작되면 보드에서 시각화 되어 보여짐
- TO DO, IN PROGRESS, IN REVIEW, DONE 등의 단계를 거치면서 생명주기 관리
- JIRA는 GITHUB, SLACK 등의 툴과 연계하여 유기적으로 활용
- 애자일 방법론의 작은단위의 기능개발, 팀별 자율성 등의 특징은 모놀리식 아키텍처가 아닌 msa 아키텍처와 적합한 구조
- 모놀리식 아키텍처
- 단일 대규모 애플리케이션
- 모놀리식 아키텍처는 애플리케이션의 모든 기능이 하나의 큰 시스템으로 구축되는 방식
- 통합된 개발 접근
- 애플리케이션의 모든 구성 요소가 하나의 코드베이스에 통합되어 있으며, 이로 인해 소스코드가 서로 영향을 받고 배포 및 테스트가 복잡하고 어려워짐
- 관리 및 유지보수의 복잡성
- 상호 영향도
- 하나의 모듈을 수정할 때, 이를 참조하거나 영향을 받는 모든 모듈들도 영향을 받을 수 밖에 없는 구조
- SW아키텍처의 복잡도와 배포의 어려움
- 소스코드의 영향도로 인해, 배포도 팀마다 불가능하고 전체 배포 시간을 정하여 모든 소스코드를 한꺼번에 반영.
- 일반적으로 새벽시간이나 DB작업 등 복잡한 작업의 경우엔 새벽에 진행. 심지어 변경의 규모가 큰 작업일 경우 명절 등 공휴일을 정해 배포
- 시스템 구성의 복잡성
- 시스템이 복잡해 개발의 영향도 파악이 어려움
- msa
- 폭포수 개발방법론에서 나오는 아키텍처가 모놀리식이라면, 일반적으로 애자일하게 일하는 조직에서 취할수 있는 아키텍처는 msa(micro service architecture)
- MSA
- msa는 독립적이고 작은 서비스들로 구성된 시스템을 의미
- 모놀리식에서 문제의 원인이었던 서비스들간의 의존성이 약화되거나 제거돼 느슨한 결합(loosely coupled) 상태로 구성
- 서비스는 저마다 데이터베이스를 가지며, 각 서비스마다 더 적합한 기술이 사용
- 서비스의 수정이 발생하여도 다른 서비스로의 영향이 없거나 적기 때문에, 독립적인 개발 및 배포가 가능
- 장애가 발생하더라도 장애 범위가 서비스에만 국한
- 특정 이벤트로 대량의 트래픽이 몰릴 경우, 해당 서비스에만 컴퓨팅 리소스를 더 투입하는 스케일 아웃 전략을 적용
- MSA의 통신방식
- API기반 통신
- API는 주로 동기적 처리를 위한 용도
- 주문서비스에서 회원정보가 필요할 때, 회원 ID를 가지고 회원 서비스를 호출하여 정보를 조회
- 이벤트 기반 통신
- 비동기 또는 독립적 처리를 위한 용도
- 주문이 발생하면(신규 주문 이벤트가 발생하면) 주문 정보를 가진 메시지를 발행하고, 재고 서비스나 앱 푸시 서비스에서 해당 메시지를 구독하여 후속 처리
- MSA와 컨테이너 환경구성
- msa는 경량화된 아키텍처로서 분산 아키텍처로 구성
- 경량화된 서버인 docker container와 같은 컨테이너 기반 아키텍처에 적합
- 확장가능성에 염두를 둔 msa 설계사상과 확장에 유연하고 용이한 이미지 기반의 컨테이너 서버구성은 상호 적합한 기술 선택지
- 쿠버네티스(k8s)와 같은 컨테이너 오케스트레이션 기술 덕분에 대규모 컨테이너 시스템을 기존의 legacy보다 효율적으로 관리할수 있는점이 큰 장점
- k8s의 활용과 msa
- 자동화된 배포와 롤아웃 관리를 통해 msa 환경에서의 빈번한 수정과 배포 가능
- 자동 확장과 로드 밸런싱
- 특정 서비스의 고 트래픽 상황시 빠른 자동확장 서비스와 로드밸런싱
- 서비스 검색과 네트워킹를 통한 내부 통신 용이
- 내부 서비스간의 통신 용이와 확장성이 하게 함으로서 msa 컨테이너간의 통신에 최적화
- 자원 관리 및 최적화
- 서비스 health check 자동관리
- 특정 컨테이너가 down된 상황을 자동으로 인지하고 컨테이너 재생성 또는 서비스 자동 재시작 기능
