SW Engineering (SW 개발 방법론)

러셀크로우 주연의 명작, 영화 글래디에이터에 보면 원형 경기장에 갇혀 희생양이 될 뻔했던 야만족 역할 노예들이, 한 때 로마의 장군이었지만 함께 노예가 된 막시무스(러셀크로우)의 제안에 따라 진영을 갖추어 로마군을 격퇴시켜 버리는 통쾌한 명장면이 나옵니다. SW 개발 방법론이란 한정된 자원을 가진 개발팀의 리스크를 최소화하고, 극대화시킨 개발 효율을 통해 시장에서 승리할 확률을 높여주는 일종의.. 개발 진법들이라고 할까요 (너무 문학적인가)

노예(개발자)들이 진형을 통해 로마군대(외부환경)에 맞서는 장면

사실 SW 개발 방법론 자체는 조금 딱딱한 이야기 일 수 있어요. 
"조직이 어떤 개발문화를 가지고, 어떻게 소프트웨어를 만들 것인가"에 대한 이야기거든요.

여기에 대한 경험을 이야기해보면.. 저는 학부시절 두 군데 개발자 양성 프로그램(회사에서 운영하던 SW멤버십, 지식경제부에서 운영하던 SW마에스트로)을 경험해 본 적이 있습니다.
재밌는 건 두 양성 프로그램이 성격이 매우 달랐다는 건데요. 
멤버십에서는 개발 방법론이 정해져있어 고민이 없었던 것 같아요(우리팀만 그랬나) 거의 딱 떨어지는 Water fall 방식이라 회사에서와 비슷하게 팀 구성 → 기획 → 시작발표 → 과제시작 → 중간발표 → 완료발표를 진행했구요. 총괄하시는 부장님과 평가하는 대리급 운영자, 그리고 학생 자치회(회장, 부회장, SW, HW, NW 분과장)가 지켜보고 있었으니 학부 개발자들이라고는 했지만 지금 생각해 보면 좀 군대? 느낌이 있었어요. 운영자 공지에 댓글도 의무적으로 넵! 넵! 달아야 했고 ㅋㅋ

반면 SW마에스트로(소마)에서는 학부생, 고등학생 할 것 없이 개발론 자체에 매우 관심이 많았었는데, 지금 생각해 보면 소마 쪽은 프로그램 수료 후 취업에 대한 보장없이 진행했던 과제가 그대로 론칭, 멤버가 창업 구성원이 될 수 있었던.. 말하자면 홀로서기를 위한 인큐베이팅 프로그램이었기 때문 아니었을까 생각이 듭니다. 지리적으로 그곳이 우리나라 개발 문화 중심인 테헤란로였기도 했고, 또 가르쳐주시는 멘토님들도 모두 현업 프로젝트 리더로 계신 분들이었기도 했구요

이것이 12년 전이니 지금보다 개발 문화가 성숙하기 전이었을텐데도 어린 학생들이 밤새 브레인스토밍을 하고, 멘토와 주변 개발자들에게 피드백을 받으며 애자일을 본인들 프로젝트에 도입하기 위해 참 많은 노력을 했습니다.
만약 벤처나 창업에서 제한된 자원(인력, 돈, 인맥, 아이디어)을 가지고 프로젝트를 진행하게 된다면 개발 방법론은 생존이 걸린 문제가 되는 것 같습니다.

저는 이후 입사를 하게 되었고, 검사 설비 쪽으로 일을 하게 되면서,  관료화된 조직 입장에서는 이상적이기까지 한 그때의 SW 개발 방법론에 다시 관심을 가지게 되었습니다.
언젠가 저도 프로젝트 기획자가 되고,
멋진 과제에 애자일 열심히 도입해 보고 안되면.. 안되면.. 
(작은 목소리로) 따로 하나.. 차..릴까요? ㅋㅋ
 
 
① 소프트웨어 개발 과정
    소프트웨어를 만들기 위해 계획 단계에서 유지보수 단계까지 일련의 과정을 정의한 것. 이를 소프트웨어 개발 생명주기(Software Development Life Cycle, SDLC)라고 함
     - 개발순서 : 요구사항(기능적/비기능적) → 요구명세(기능적/비기능적) → 요구분석 → 설계 → 구현 → 테스트 → 납품/유지보수
 *동일한 의미로 소프트웨어 개발프로세스, 소프트웨어 개발 생명주기 (Software Development Life Cycle, SDLC)라고 함

     - 관련인(등장인물) : 요청고객 (Client), 사용자 (실제 Customer), 프로젝트 관리자 (PM), 개발자 (Developer)
     - 산출물 : 요구사항 정의서 - 요구명세서 (PRD : 기능적 / 비기능적 요구사항) - UML(Unified Modeling Language)
 
 ② 요구사항 (요구사항 정의서)
    : Customer와의 인터뷰를 바탕으로 엔지니어의 언어로 옮긴 뒤 Customer 동의를 받음

 (1) 기능적 요구사항
     - 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항
     - 시스템의 [입력이나 출력]으로 무엇이 포함되어야 하는지에 대한 사항
     - 시스템이 [어떤 데이터를 저장하거나 연산을 수행] 해야 하는지에 대한 사항
     - 시스템이 반드시 [수행해야 하는 기능]
     - 사용자가 시스템을 통해 [제공받기를 원하는 기능]
 
  (2) 비기능적 요구사항 
     - 시스템 장비 구성 요구사항꞉ 하드웨어, 소프트웨어, 네트워크 등의 시스템 장비 구성에 대한 요구사항
     - 성능 요구사항꞉ 처리 속도 및 시간, 처리량, 동적 정적 적용량, 가용성 등 성능에 대한 요구사항
     - 인터페이스 요구사항꞉ 시스템 인터페이스와 사용자 인터페이스에 대한 요구사항으로 다른 소프트웨어,
     - 하드웨어 및 통신 인터페이스, 다른 시스템과의 정보 교환에 사용되는 프로토콜과의 연계도 포함하여 기술
     - 데이터 요구사항꞉ 도입되는 장비의 성능 테스트나 구축된 시스템이 제대로 운영되는지를 테스트하고 점검하기 위한 테스트 요구사항
     - 보안 요구사항꞉ 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항
     - 품질 요구사항꞉ 관리가 필요한 품질 항목, 품질 평가 대상에 대한 요구사항으로 가용성, 정합성, 상호
     - 호환성, 신뢰성, 사용성, 유지 관리성, 이식성, 확장성, 보안성 등으로 구분하여 기술
     - 제약사항꞉ 시스템 설계, 구축, 운영과 관련하여 사전에 파악된 기술, 표준, 업무, 법 제도 등의 제약조건
     - 프로젝트 관리 요구사항꞉ 프로젝트의 원활한 수행을 위한 관리 방법에 대한 요구사항
     - 프로젝트 지원 요구사항꞉ 프로젝트의 원활한 수행을 위한 지원 사항이나 방안에 대한 요구사항
 
  (3) 좋은 요구사항 정의서가 가지고 있는 특징 
    - 요구사항 정의서를 읽는 요구자가 이해하기 쉬워야 함
    - 무엇을 어떻게 구현되어야 하는지 명확하게 작성
    - 하나의 요구사항에 여러 가지(복수) 요구사항을 작성하지 않는다.
    - 다른 요구사항 모순 또는 중복되지 않게 한다.
    - 애매한 단어를 사용하지 않고 명확하게 기재 ( ~ 있으면 좋겠다 → ~ 기능 필요)
    - 동일한 용어 사용 - 댓글, 코멘트, 덧글과 같이 모두 같은 의미를 다르게 표현하지 않아야 함
    - 실제 현업에서 가장 중요한 것은 우선순위
 
 ② 요구사항 명세서 (SRS꞉ Software Requirement Specification)
    : 사용자, 분석가, 개발자 및 테스터 모두에게 공동의 목표를 제시
     시스템이 어떻게 수행될 것인가가 아닌 무엇을 수행할 것인가에 대한 기술
     시스템이 이루어야 할 목표를 기술하지만 목표를 달성하기 위한 해결 방법은 기술하지 않음
     (요구사항 정의서를 바탕으로 개발자들의 포맷으로 재 작성 - 대분류에 요구사항 ID, 중분류에 기능 ID로 넘버링)

 
  (1) 기능적 요구사항 (Functional Requirements)
      수행될 기능과 관련되어 입력과 출력 및 그들 사이의 처리 과정
      목표로 하는 제품의 구현을 위해 소프트웨어가 가져야 하는 기능적 속성
     • 예) 워드프로세서에서 파일 저장 기능, 편집 기능, 보기 기능 등
 
  (2) 비기능적 요구사항 (Non‑Functional Requirements)
      제품의 품질 기준 등을 만족시키기 위해 소프트웨어가 가져야 하는 성능, 사용의 용이성, 안전성과 같은 행위적 특성
      시스템의 기능에 관련되지 않는 사항을 나타냄
     • 예) 성능(응답 시간, 처리량), 사용의 용이성, 신뢰도, 보안성, 운용상의 제약, 안전성 등
 
 ③ 요구사항 분석
   : 실제 개발 착수 전, 요구사항을 분석하여 개발 주요 사안과 리소스, 일정을 산정하는 단계. 명세서를 기반으로 구현이 가능한지 여부를 기술적으로 분석
      특정 요구사항이 과도한 리소스(인력)가 필요하다면, 요구사항 변경/삭제를 논의할 수 있으며 이를 통해 요구사항 명세서는 업데이트될 수 있음
      이 단계가 완료되면 업데이트된 요구사항 명세서와 대략적인 개발 기간, 비용 등이 결정되고, 이를 기반으로 요청 고객에게 확인 도장을 받음
     • 산출물 ) PRD (Product Requirements Document) : Agile 조직에서 주로 많이 사용하지만, 대부분의 소프트웨어 개발에 많이 사용됨. 간결하게 정의하는 것이 핵심
  
 ④ 설계 (Design)
   : 건축물의 설계와 유사한 사고를 기반으로, 전체 소프트웨어의 큰 그림을 그리는 과정
     이론적으로는 미리 최대한 깊게 구현을 그려보면서, 구체적인 일정/리소스/소프트웨어 구조를 세움
 
  (1) UML의 기본 구성요소 
    - 사물(Things)꞉ UML은 기본 요소를 구성
    - 관계(Relationship)꞉ 사물 간의 관계를 나타냄
    - 다이어그램(Diagram)꞉ 사물과 관계를 도형으로 표현
 
  (2) 분류 
    1) 구조 다이어그램 (클래스, 오브젝트, 컴포넌트 다이어그램)
     - Class Diagram(클래스 다이어그램) 
       ⓐ 관계표현
         . Generalization (일반화):일반적으로 상속 관계 표현
         . Realization (실체화):실체화는 interface를 실제로 구현하는 
         . Dependency (의존) : 클래스 간 참조가 일어나는 것을 의미함

       ⓑ 접근 제어자
         . + (Public) : 어떤 클래스의 객체에서든 접근 가능
         . - (Private) : 이 클래스에서 생성된 객체들만 접근 가능
         . # (Protect) : 이 클래스와 동일 패키지에 있거나 상속 관계에 있는 하위 클래스의 객체들만 접근 가능 
         . ~ (Package) : 동일 패키지에 있는 클래서의 객체들만 접근가능

클래스 다이어그램

    - Object Diagram(객체 다이어그램)
    - Component Diagram(컴포넌트 다이어그램)
 
   2) 행위 다이어그램 (활동, 상태, 순서, 커뮤니케이션, 유즈케이스 다이어그램)
    - Activity Diagram(활동 다이어그램) = 순서도
    - State Diagram(상태 다이어그램)
    - Sequence Diagram(순서 다이어그램) = 통신 사양서에 맨날 나오는 시나리오
    - Communication Diagram(커뮤니케이션 다이어그램)
    - Usecase Diagram(유스케이스 다이어그램) 

⑤ 구현 (Implementation)
  (1) 프로젝트 관리의 4가지 활동
      프로젝트시작 → 프로젝트 계획 → 실행과 모니터링 → 종료
 
  (2) 프로젝트 관리의 목표
     - 최종 결과가 고객의 요구를 만족해야 함
     - 프로덕트 및 프로젝트에 대한 속성(품질, 보안, 생산성, 비용 등)이 요청 수준에 맞아야 함
     - 계획된 일정에 맞게 진행되어야 함
     - 팀 구성원이 효과적으로 작업하고 능력을 발휘하여야 함
     - 실행 과정을 모니터링하고 조정하여야 함
     - 프로젝트를 실패로 만들 수 있는 리스크를 미리 예측, 대비하여야 함
     - 요청된 도구와 기타 자원이 사용 가능하고 효과적으로 쓰여야 함
 
  (3) 프로젝트 관리 계획서 작성
     - WBS (Work Breakdown Structure) 기반 작성 - 프로젝트 목표를 달성하고 결과물을 산출하기 위하여 수행해야 할 작업을 계층적으로 분할한 것
     - 소작업들에 대한 소요 일정이 예측되어야 프로젝트의 일정을 계획
     - 작업 단위를 산출물 위주로 작성
     - 최하위 단위 작업은 책임자(팀), 책임져야 할 일이 목표가 되어야 함
     - 작업과 비용을 정의 (보통 일정으로 정의)     

프로젝트 관리 계획서

 ⑥ 테스트 (QA)
    : Software Quality Assurance (SQA)라고 함. 소프트웨어가 기대하는 기능을 수행하는지, 버그가 없는지 확인
     이를 기반으로 소프트웨어의 완성도를 높이고, 품질을 높이는 과정
 
   (1) QA 종류
     - 단위 테스트 (Unit Test)꞉ 개발 단계에서 각 모듈이 개발 완료되었을 때 수행하는 테스트
     - 통합 테스트 (Integration Test)꞉ 모듈을 통합하는 과정에서 모듈 간 호환성의 문제를 찾아내기 위해 수행되는 테스트

Software Quality Assurance (Test Case)

 ⑦ Release
   (1) 소프트웨어 배포 생명 주기(Software Release Life Cycle)
     - Pre‑alpha ꞉ 핵심 기능이 동작하기 시작한 상태
     - Alpha ꞉ 소프트웨어 테스트 단계
     - Beta ꞉ 외부에 테스트 단계로 명시해서 오픈해서 내외부 테스트 단계
     - RC(Release Candidate)꞉ 정식 Release 후보
     - Official Release꞉ 고객이 사용하는 완벽한 버전
     - RTM(Release to Manufacturing), GA(General Availability)라고도 함
 
 ⑧ Maintenance (유지보수)
   : SDLC의 마지막 단계로 소프트웨어의 생명을 연장시키는 작업
    소프트웨어가 개발되어 폐기될 때까지 이루어지는 일련의 소프트웨어 변경과 수정 작업
    소프트웨어 인도 후 결함 제거, 성능 향상, 변화된 환경에 적응하도록 소프트웨어를 변경하는 작업
    개발은 코딩 중심의 작업, 유지보수는 이해 중심의 작업
 
 (1) 소프트웨어 유지보수 유형
     - 수정 유지보수 ꞉ 오류 정정(하자(오류) → 처리 오류, 수행 오류, 구현 오류)
     - 적응 유지보수 ꞉ 환경 변화에 적응(하드웨어 변화, 소프트웨어 변화, DB 적용 등)
     - 완전 유지보수 ꞉ 기능 및 성능 개선(유지보수의 대부분을 차지)
     - 예방 유지보수 ꞉ 기능 예상/예측되는 오류 수정
 
 ⑨ 개발방법론
   (1) 폭포수모델
     - 정통 제조/건설 프로세스와 유사한 기법. 단계별로 완벽하게 진행하는 프로세스를 의미함
     - 완벽한 설계의 모습, Men/Month, 납기 예측가능
 
   (2) 프로토타입 (폭포수 초기에 프로토타입을 적용) 
     - 고객에 실제 원하는 것이 맞는지 핵심 기능만 만들어서 보여줌
     - 고객이 OK 하면 이제 소프트웨어 기본 개발 프로세스를 기반으로 개발

  
   (3) 나선형 모델
     - 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 프로그램을 개발해 나가는 모델
     - 리스트 최소화를 위해 위험 분석 단계 존재
     - 점진적으로 단계를 반복 수행
     - 각 단계 진행 순서는 폭포수 모델과 동일

 
   (4) Agile 프로세스
   : 짧은 주기의 개발단위를 반복하여 하나의 큰 프로젝트를 완성해 나가는 방식. 핵심은 협력과 피드백
     - 계획 → 설계(디자인) → 개발(발전) → 테스트 → 검토(피드백)를 반복적으로 진행 

  
    1) 순서(세부내용)
     - 계획 및 분석꞉ 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 SW 기능과 제약조건을 정의하는 명세서 작성, 
                        대상이 되는 문제 영역과 사용자가 원하는 task를 이해하는 단계
     - 설계(디자인)꞉ 기획의도에 맞는 설계 및 디자인 추가 및 수정하는 단계
     - 개발(발전)꞉ 설계단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합테스트 수행
     - 테스트꞉ 발생 가능한 실행 프로그램 오류를 발견, 수정하는 단계
     - 검토(피드백)꞉ 기획의도를 파악하고 시험결과와 기획의 따라 수정할 부분을 제시하는 단계
 
    2) 팀 구성 (10명 이내)
     - Product Owner(Manager) :제품의 비즈니스적 가치를 이해하고 고객의 요구를 정의하는 역할 수행. 제품의 기획, 우선순위 설정, 요구사항 관리
     - Scrum Master :팀이 스크럼 프로세스를 잘 따르고, 장애 요소를 제거하여 팀의 생산성을 높이는 역할 수행. 팀의 자가조직화를 지원하고 개선을 위한 리틀챕터(작은 개선) 도입 
     - Senior Development Manager : PM / 개발 일정관리
     - Developer (+UX Desinger, +Data Analyst) : 제품을 개발하는데 필요한 모든 업무를 수행하는 개발자, 디자이너, 테스터 등의 역할을 수행하는 팀 멤버들로 구성
  
    3) 순서
     - 팀 구성 → Sprint 만들어 계획 세우고(1달, 또는 2주 등) → Daily Scrum으로 매일같이 진척/변경사항 확인/공유하고 → Sprint 끝나면 그동안 진행한 것 리뷰하고, 반성
 
 ⑩ 소프트웨어 아키텍쳐
    아키텍쳐 패턴 : 주어진 상황에서의 소프트웨어 아키텍쳐에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션
 
  (1) 주요 소프트웨어 아키텍쳐 패턴
    1) 계층화 패턴 (Layered pattern)
     : 각 계층들은 특정한 수준의 추상화를 제공
      각 계층은 다음 상위 계층에 서비스를 제공 (직접 닿은 계층 이외의 계층에 직접 소통 불가)
      시스템을 계층화하고 하위 레이어가 제공하는 기능을 상위 레이어가 이용함으로써 각 레이어의 구조를 단순화한다는 발상
      각 레이어는 해당 레이어와 통신하는 직접적인 상위/하위 레이어만 알면 됨
*저는 설비 내재화 프로젝트에서 이걸 직접 구현 했었어요. 상업용 비전라이브러리 교체가 가능하도록 메소드명과 인아웃풋 자료형까지 맞추고 더이상 레이어 상단에서 호출되지 않도록 처리합니다 (레이어를 건너뛰고 싶은 유혹이 상당함)
 
    2) MVC 패턴 (Model‑view‑controller pattern) 
     : 계층화 패턴과 유사하지만, 계층화 패턴보다 구체적이고, 3 부분이 서로 소통 가능
      - 모델 (model) — 핵심 기능과 데이터를 포함한다
      - 뷰 (view) — 사용자에게 정보를 표시한다 (하나 이상의 뷰가 정의될 수 있음)
      - 컨트롤러 (controller) — 사용자로부터의 입력을 처리한다  

    * MVC 패턴은 제가 랩에서 처음 배웠던 언어 MFC(visual c++)이 대표적 구현 사례였던것 같아요(처음에 뷰외에 어디 무서워서 건드리질 못함) c#도 마찬가지로 폼만드는 디자이너(view)와 컨트롤부가 정확히 나누어져있죠. 내가 맨날 모델과 컨트롤부 구분없이 섞어짜서 그렇지

3) 클라이언트‑서버 패턴 (Client‑server pattern)
     : 기본적으로, 이메일, 문서 공유 및 은행 등의 온라인 애플리케이션에 광범위하게 활용
       클라이언트 요청이 몰릴 경우, 서버 처리 지연 현상 발생 가능
       일정 시간 동안 최대 요청량을 고려하여, 서버 구성 필요. 처리가 필요할 때, 바로 코드 내에서 처리하지 않고, 서버에 요청, 결과를 받는 구조로 경우에 따라서는 간단한 처리를 복잡하게 처리해야 함
 
    4) 마스터‑슬레이브 패턴 (Master‑slave pattern)
     : 마스터 컴포넌트는 동등한 구조를 지닌 슬레이브 컴포넌트들로 작업을 분산하고, 슬레이브가 반환한 결과값으로부터 최종 결과값을 계산
*손오공은 마스터-슬레이브 패턴을 이용해 원기옥을 구현한 뒤 프리저와 마인부우를 제거했다고 합니다. 단점- 우리가 익히 알고 있듯이 슬레이브의 반환 값을 기다리는데 상당한 시간이 소요될 수 있음
 
    5) 파이프‑필터 패턴 (Pipe‑filter pattern)
 데이터 스트림 절차의 각 단계를 필터(Filter) 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장이 용이
필터 컴포넌트들을 재배치해 다양한 파이프라인을 구축하는 것이 가능
데이터 변환, 버퍼링, 동기화 등에 주로 사용
필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드 발생. UNIX의 쉘(Shell)이 대표적임
*이건 인풋과 아웃풋 파라미터만 맞춰주면 마법처럼 동작하겠네요. 교수님! 우리 랩실도 이제 영상처리 필터 라이브러리를 이런식으로 구현해서 가지고 있어야 합니다!하고 말씀 드렸던 기억이 나네요

    6) 브로커 패턴 (Broker pattern)
     : 서버는 자신의 기능들(서비스 및 특성)을 브로커에 넘겨주며(publish), 클라이언트가 브로커에 서비스를 요청하면, 브로커는 적합한 서버로 리다이렉션 하는 구조 
*검색 사이트마다 최저가가 달라졌던건 요놈 때문인건가

 
    7) 피어 투 피어 패턴 (Peer‑to‑peer pattern)
     : 피어는 클라이언트로서 피어에게 서비스를 요청할 수도 있고, 서버로서 각 피어에게 서비스를 제공할 수도 있음
       장 - 탈중앙화된 컴퓨팅을 지원, 리소스 및 컴퓨팅 성능면에서 확장성이 뛰어남, 특정 노드 장애에 매우 강함
       단 - 노드들이 자발적으로 참여하기 때문에 서비스 품질에 대한 보장이 어려움, 보안에 대한 보장이 어려움, 노드의 개수에 따라 성능이 좌우됨
*토렌트뿐아니라 블록체인의 시초가 된 탈중앙화 기술. 패턴이 사회 운동, 문화와 연결된다는 점도 굉장히 멋지죠
 
    8) 이벤트‑버스 패턴 (Event‑bus pattern)
     : 이벤트 소스 (event source), 이벤트 리스너 (event listener), 채널 (channel) 그리고 이벤트 버스 (event bus)의 4가지 주요 컴포넌트로 구성
      소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행(publish), 리스너는 특정 채널에서 메시지를 구독 (subscribe) 
*트위터나 페이스북의 기본개념인 브로드캐스팅과 구독방식이 여기에서 나왔어요. 아~ 이름만 들어도 설레네요 ㅎ

 
    9) 인터프리터 패턴 (Interpreter pattern)
     : SQL과 같은 데이터베이스 쿼리 언어에서 쓰이는 가장 일반적인 구조
      매우 동적인 설계가 가능, 최종 사용자가 프로그래밍하기 좋음, 인터프리터 프로그램을 쉽게 교체할 수 있기 때문에 유연성이 향상 

 
 ⑪ 기타
   (1)  Micro Service Architecture (Agile구조에 적합한 구조)
        각 모듈별로 다른 기술 적용 가능. 특정 기능이 실패해도 전체 소프트웨어는 동작함. 모듈별 의존성이 낮으므로, 기능 업데이트가 빠름
      • 예) 지마켓 내 개별모듈(특가세일, 20대가 많이 찾는..)
       - Micro Service Architecture 단점
         분산 시스템 개발은 일반 개발보다 복잡
         모듈 간의 인터페이스가 필요하고, 모듈별 응답이 안될 경우, 방어코드등을 고려해야 함
         인터넷 기반 서비스에 적합하지만, 모든 소프트웨어에 적합한 구조는 아님
 
   (2) TDD와 Unit Test
       테스트 주도 개발 (Test Driven Development)
       : 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현하는 방법
         짧은 개발 주기의 반복에 의존하는 개발 프로세스에 적합(Agile)
        = 설계 후 검산 프로그램(테스트 코드 / 테스트케이스)부터 개발함
 
   (3) DevOps
       운영 + 운영시스템 효율화/자동화 프로젝트를 목표. 주로 시니어 엔지니어 이상
       (운영팀에 개발자가 들어가서 일하게끔 목표를 부여한 것임)
       주요 역할 : Release System 자동화, 코드 리뷰, 테스트 자동화, 서비스 모니터링 시스템, 이슈 발생 시 커뮤니케이션