MSA (micro service architechure)

서비스의 내부 기능을 작은단위로 나눠서 구현하는 방법입니다.

MSA 에는 여러가지 패턴이 있고 각각의 장단점이 있기 때문에 상황에 따라 다른 패턴을 사용할 수 있습니다.

여러가지 MSA 패턴에 대한 요약 글

예전 서비스는 큰 덩어리 내부에 기능을 같이 넣어 서로를 호출하며 트레픽이나 오류가 연쇄적으로 이어집니다.

하나의 기능에서 에러가 발생하면 같이 묶여있는 나머지 기능, 전체 시스템이 전부 영향을 받습니다.

MSA는 일정 단위로 나누어 연결시켰기 때문에 하나의 기능이 고장나도 전체시스템이 다운되지 않습니다.

MSA는 여러패턴으로 구현할 수 있는데 CQRS 패턴을 예시로 보면 쿼리와 명령을 나누어 관리하는 형식입니다.

유저 사용량의 90%를 차지하는 조회기능을 개선하려면?

모놀리식이라면 하나의 큰 덩어리이므로 서비스의 전체적 업그레이드가 필요하지만

msa라면 조회기능만 따로 업그레이드 가능합니다.

조회 내부에서도 각각의 이벤트(업무)를 AWS의 SQS(비동기작업 큐) + SNS(작업관리)를 이용해 관리하여 한 작업이 다른 작업의 속도나 트레픽에 영향을 주지 않도록 설계합니다.

MSA 장점

• 단일 모듈의 장애에 대해 전체 어플리케이션은 크게 영향을 받지 않습니다.
• 의존 관계가 기존 Monolithic 아키텍처보다 적고 유연합니다.
• 개발자가 기능을 더 쉽게 이해 할 수 있습니다.

MSA 약점

• 분산 시스템 개발은 일반 개발보다 복잡합니다. 모든 것이 독립적인 서비스이기 때문에 각 모듈간의 인터페이스를 신중하게 처리 해야 합니다. 서비스중 하나가 응답하지 않게 될 경우에 대한 방어코드도 작성해야 합니다. 호출 대기 시간이 발생하게 되면 복잡한 상황이 발생할 수 있습니다.
• Multiple Databases 및 트랜젝션 관리가 어려울 수 있습니다.
• 마이크로 서비스 기반의 어플리케이션을 테스트하는 것은 번거로울 수 있습니다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 합니다.
• 마이크로 서비스의 배포는 복잡 할 수 있습니다. 각 서비스 간의 조정이 필요 할 수 있습니다.

마이크로 서비스의 배포 및 가상화

마이크로 서비스기반의 어플리케이션을 배포하는 가장 좋은 방법은 컨테이너 가상화를 이용하는 것입니다. (Docker)

AWS와 같은 IaaS업체의 VM을 이용하여 마이크로 서비스를 배포할 수 있지만 작은 단위의 마이크로 서비스는 VM의 리소스를 전부 활용 하지 못해 비용 효율성을 저하 시킬 수 있습니다. 따라서 컨테이너 기반으로 배포를 하는 것이 유리합니다.

참고자료

• MSA 간단설명 영상
• 배민의 마이크로서비스
• 가비아 MSA
• Microsoft MSA
• 구글 MSA
• 삼성 MSA
• MSA 자세히 설명한 미디엄 글
• 최범균님의 MSA
• 네이버클라우드 MSA
• 파이콘 MSA 발표영상

UML(Unified Modeling Language)

프로그램의 설계를 그림으로 표현하는 것으로 객체지향 언어와 밀접한 관련이 있어서 객체지향 모델링 언어 라고도 불린다.

단, UML은 모델링 언어일뿐 프로그래밍 언어가 아니고 방법론 또한 아니다.

건물을 짓기 전 청사진을 그리는것 처럼 소프트웨어 시스템을 구축하기전에 모델을 설계하는것이 필수인데, 이때 복잡한 설계상황을 가독성이 좋은 시각화 모델링을 할 수 있도록 돕는것이 UML의 가장 큰 역활이다.

한마디로 UML은 분석하고, 디자인하고, 프로그래밍하는 3단계 과정이다.

1. OOA : Object Oriented Analysis
   • 서비스가 무슨 작업을 해야하는지
2. OOD : Object Oriented Design
   • 어떻게 그 작업이 수행되는지
3. OOP : Object Oriented Programming
   • 이 모든것을 구현하는지

UML의 다이어그램은 구성요소간의 형태를 표현하기 위한 `구조적 다이어그램` 과 구성요소가 어떤 행위를 하는지 표현하기위한 `행위 다이어그램`으로 나눌 수 있다.

• 구조적 다이어그램은 클래스다이어그램, 객체다이어그램, 컴포넌트 다이어그램 등이 있다.
• 행위 다이어그램은 시퀀스 다이어그램, 유케이스 다이어그램 등이 있다.

클래스 다이어그램

가장 일반적으로 사용되는 클래스다이어그램의 예시다.

시스템의 구조를 나타내며 클래스끼리 연결시켜 그 내부에 변수,데이터 타입함수를 정의할 수 있으며 한눈에 보기에도 편하다.

시퀀스 다이어그램

이 시퀀스 다이어그램은 Batch 인스턴스에서 DB로 사진의 아이디값을 전달하면 DB에서 해당 아이디를가진 사진을 return 해주는 흐름을 보여준다.

PlantUML

PlantUML은 텍스트로 UML 다이어그램을 생성하는 오픈소스 프로젝트다.

PlantUML Docs

PlantUML GitHub

특이한 점은 UML 외에도 JSON data, 네트워크 다이어그램, Archimate diagram 등의 여러가지 다이어그램을 지원한다.

PlantUML로 시퀀스다이어그램을 그린 예시이다.

Mermaid

마크다운 문법을 사용해서 UML을 그릴 수 있는 자바스크립트 기반의 라이브러리다. (IDE에서 플러그인을 설치하면 mermaid를 바로 사용할 수 있다)

Mermaid

Mermaid 라이브에디터

플로우차트, 시퀀스다이어그램, 간트차트, 클래스다이그럼, User Journey diagram 를 사용가능하다.

mermaid를 이용해서 클래스다이어그램을 그리는 코드예시이며, 심지어 Notion 노트 앱에서 임배디드형식으로 입력이 가능하다.

프로세스와 프로세서

컴퓨터에는 여러 프로그램이 있고 사용자가 그걸 실행할 수 있다.

이떄 이 프로그램이 돌아가고 있는 상태(컴퓨터가 어떤 일을 하고 있는상태)를 프로세스 라고 한다.

그리고 CPU(프로세서)는 여러개의 프로세스를 함께 진행할때 동시성, 병렬성 방식을 이용한다.

동시성과 병렬성

동시성(Concurrency)
동시성은 하나의 프로세서가 여러개의 프로세스를 조금씩 번갈아가면서 실행하여 결국 모든 작업을 마치는 방식이다.
이렇게 번갈아가는 방식이 Context-swiching 이고 내부적으로 다양한 방식과 알고리즘이 사용된다.
이때 사용자는 번갈아가는 속도가 너무 빠르기 때문에 마치 모든 프로세스가 동시에 진행되는것 처럼 느낀다.
하지만 프로세스가 독립적인 메모리를 가지기 때문에 이떄 프로세스간의 데이터공유가 힘들고 무엇보다 하나의 프로세서가 이 작업을 진행하기 때문에 부하가 걸리기 쉽다는 큰 단점이 있다.

병렬성(Parallelism)
병렬성은 하나의 프로세서(CPU)에 여러개의 코어가 달려있고, 이 여러개의 코어가 각각 다른 프로세스를 진행하여 실제로 동시에 작업을 진행한다.
(CPU 사양이 6코어 12스레드 => CPU안에 6개의 코어가 있고, 각각의 코어에 쓰레드를 두개씩 가지고 있다)

쓰레드

쓰레느는 하나의 코어에서 진행했던 작업을 여러개의 코어로 작업효율적으로 처리하기위해 등장했다.

프로세스는 한개 이상의 스레드를 가질 수 있고, 예전에는 프로세스가 CPU에서 실행되는 단위였지만 지금은 스레드가 그 의미를 가진다.

이떄 다운로드받는 작업, 영상을 재생하는 작업 같은 작은 갈래들을 Thread 라고 하며,
이렇게 하나의 프로세스가 동시에 여러 작업을 실행하는것이 멀티스레딩 이다.

즉 물리적으로는 하나인 코어가 실행하는 프로세스를 여러개의 쓰레드로 나누고, 마치 여러개의 코어가 일하는것처럼 작업을 처리할 수 있는것이다.

각각의 프로세스는 독립된 메모리공간을 할당받지만, 각 프로세스 내부의 쓰레드들은 자신이 포함된 프로세스가 메모리를 공유해서 사용한다.
(이는 프로세스간의 컨텍스트 스위칭은 어려웠지만, 스레드끼리는 매우 편리함을 의미한다)

하지만 만약 두개 이상의 Thread가 공유중인 자원에 동시에 손을대면 에러가 발생하는 큰 단점이 있다.

동기와 비동기

프로세스 내부에서 쓰레드가 진행되는 방식은 크게 동기와 비동기가 있다.

비동기(Async)
비동기는 여러개의 작업을 여러개의 쓰레드로 나누어 진행한다.
만약 작업이 세개 있다면 하나의 쓰레드에 일렬로 준비중이던 세개의 작업을 다른 쓰레드로 보내서 거기서 시작하도록 명령한다.

여기서 중요한건 작업을 다른쓰레드로 보내는순간 기존 쓰레드에서는 그 작업이 끝나던지 말던지 기다리지않고 바로 다른 작업을 시작한다.한마디로 작업이 여러개있으면 일단 다른쓰레드로 작업을 던져두고 바로 다음작업을 바로 시작해버리므로 비 동기적으로 일을 처리한다.

동기(Sync)
동기는 작업을 다른 쓰레드에서 하도록 시킨 후, 그 작업이 다른 쓰레드에서 끝나길 기다렸다가 다음작업을 진행한다.

직렬처리와 동시처리

동기/비동기는 쓰레드가 연산을 처리하는 방식이고
직렬/동시처리는 그럼 그 방식을 몇개의 쓰레드로 보낼지를 선택하는 것이다.

쓰레드에서 다른 쓰레드로 작업을 넘기는 방식에도 두가지가 있다.

직렬(Serial)처리는 메인 쓰레드에서 분산처리 시킨 작업을 한개의 쓰레드로 넘겨준다.

동시(Cocurrent)처리는 여러개의 쓰레드로 작업을 나누어 넘긴다.

이렇게보면 굳이 직렬처리를 사용할 필요가 있나? 싶을 수 있지만, 작업간의 순서가 중요할 때는 직렬처리를 사용하고 각각의 독립적인 작업을 빠르게 처리하려면 동시처리가 유리하다.

프로그램에서의 동기와 비동기

어떤 함수를 실행했을때, 해당 함수가 끝날때까지 기다렸다가 다른 작업을 진행하면 동기식이며 주로 한 함수의 결과값이 다음함수에 중요한 역할을 할 때 동기식 프로그래밍을 한다.

비동기식 프로그램은 한 함수가 끝나기도전에 다른 함수를 실행하는 형태인데, 이때는 먼저 실행한 기존의 함수가 끝났는지 여부를 알 수 없기때문에 콜백함수라는것을 이용해서 종료여부를 확인한다.

콜백함수도 어려운 개념이기 때문에 따로 정리해보겠지만, 아주 간단히 말하자면 어떤 함수안에 "끝낫습니다!" 라는 프린트를하는 함수를 만든다.

그럼 비동기로 진행중이더라도 중간에 끝났습니다! 라는 프린트가뜨면 '아 아까 2번쓰레드로 던져둔 함수가 끝났구나' 하고 알아차릴 수 있는것이다.

TDD(Test-Driven Development)는 테스트 코드를 먼저 만들고, 실제 프로덕션 코드를 만드는것이다.

(기존에는 실제 코드를 만들고, 오류가 생기면 테스트코드를 만들어 수정해나갔다)

파이썬은 컴파일 단계의 체크가 약한 동적언어라서 TDD에 적합하다.

크게 세 단계로 나눠지며 이 과정을 반복한다.

1. 원하는 기능을 점검할 테스트코드를 작성한다.
2. 테스트코드를 만족할 수 있는 기능구현 코드를 작성한다.
3. 완성된 코드를 리팩토링한다. 이 과정을 반복해서 리팩토링까지 완료된 여러개의 기능들을 모두 합치면 실제 프로덕션 코드가 된다.

파이썬의 TDD

• unittest 모듈 : 내장된 모듈이지만 구식이다
• nose : 일반적으로 많이 사용된다
• pytest : 최신기능이 많고 장고에서 자주 사용한다
  • https://pytest-django.readthedocs.io/en/latest/index.html
• coverage : 코드 커버리지 분석에좋다

리팩토링

리팩토링은 새로운 기능을 추가하거나 버그를 고치는게 아니다.

이미 작동하는 코드를 결과의 변경없이 구조를 재조정하는 것이다.

기본적으로 소프트웨어의 설계,구조 및 구현을 개선하여 가독성을 높이고 유지보수를 편하게 한다.

리팩토링 기본

1. 변수의 이름을 검색가능하도록 만들어야 한다.
2. 함수명은 반드시 동사를 쓰고 하나의 함수는 하나의 역할을 해야한다.
3. 함수의 파라미터는 3개 이하로 하는것이 좋다.
4. boolean 값을 인수로 갖지 않아야 한다.
5. 네이밍에서 지나친 축약은 피해야 한다.
6. 등등 리팩토링에는 수많은 방법과 이론이 존재한다 ....

CI/ CD

지속적 통합(Continuous Integration)/지속적 배포(Continuous Deployment)

(TDD, CI/CD, 애자일 이라는 키워드가 반복적으로 같이 등장하여 간단하게 조사해보았다.)

CI란?

빌드/테스트 자동화 과정 과정이다. CI는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.

CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작한다.

커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장한다. 지속적 통합은 그 자체로 유익하지만 CI/CD 파이프라인을 구현하기 위한 첫 번째 단계이기도 하다.

CD란?

배포 자동화 과정이다. CD는 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다.

두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어 올린다.

코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포된다.

지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다.

지속적 배포는 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포된다.

자동화 테스트와 CI/CD

CI/CD 파이프라인 안에서 여러번의 테스트를 진행하기 때문에, 테스트도 자동화가 된다.(?)

RDBMS (관계형데이터베이스 관리시스템)

가장 많이 사용되는 데이터베이스 종류로 2차원 테이블 형식을 이용해 데이터를 정의한다.
외래키를 이용해 테이블간 관계를 정의할 수 있는 장점이 있다.
사용자와 관계형 데이터베이스 사이에서 사용자의 요구에따라 데이터베이스를 관리한다.
RDBMS 중 하나인 MySQL은 주로 MariaDB 와 연동하여 많이 쓰인다.

트랜잭션(Transaction)

데이터베이스 상태를 변환시키는 작업이나 연산의 작은 단위를 트랜잭션이라 한다.
DB에 접근해서 자료를 읽고 수정하고 저장하는 작업을 하나의 단위로 묶은것이 트랜잭션이다.
트랜잭션 시작 -> 여러개의 쿼리 실행 -> 완료되면 커밋 , 오류뜨면 롤백
(SELECT, UPDATE, INSERT, DELETE 등등)

일반적으로 여러개의 트랜잭션을 병렬로 처리하는데, 트랜잭션간의 영향을 없도록 설계하는것이 중요하고 트랜잭션의 특징 덕분에 작업의 완정성을 보장할 수 있다.

쉽게 말해 작업을 진행하던 중 오류가 발생하면 진행하던 상태에서 끝나느게아니라 그 트랜잭션을 수행하기 전의 원래상태로 DB를 유지시키는 것이다.

트랜잭션이 잘 설계된 계좌이체를 예로 이해해보자.

A -> B 로 10만원을 계좌이체 한다.
1. A에서 10만원을 출금한다 (트랜잭션1)
2. 10만원을 중간지점에 저장한다 (트랜잭션2)
3. B에게 중간지점의 10만원을 보낸다 (트랜잭션3)
* 주기적으로 빈 계좌를 정리한다 (트랜잭션4)

이때 2번에서 문제가 생긴다면? 실생활에서는 A,B 계좌 모두 변한게없다.

하지만 완정성이 보장되지 않는다면?
B는 10만원을 못받았는데 10만원은 A는 이미 10만원을 출금했고 중간지점에서 10만원이 증발해버린다.

트랜잭션간의 독립성까지없다면 ? 빈계좌를 정리하는 트랜잭션이 A에서 10만원을 출금해서 0원이 되는순가 A를 삭제해버린다.

B는 돈을 못받고 A의 돈은 중간에 증발해버렸는데 A계좌가 삭제된다?....

ACID

완정성을 부여하는 트랜잭션의 특성 4가지가 ACID다.
(all or nothing)

• Atomicity (원자성)
  트랜잭션이 데이터베이스에 전부 반영되던지, 전혀 반영되지 않던지 둘중 하나여야한다.
  트랜잭션의 명령은 반드시 완벽하게 수행되야하고, 하나라도 오류가 발생하면 전부 취소해야한다.

• Consistency (일관성)
  트랜잭션이 정상적으로 완료되면 결과값은 일관성이 있어야한다.
  예를들어 사용자가 가진 계좌번호는 이체 전,후에도 변하지 않아야한다.

• Isolation (독립성)
  여러개의 트랜잭션을 동시에 수행시 트랜잭션간에 끼어들지 않아야한다.
  수행중인 트랜잭션은 완전히 종료될 때 까지 다른 트랜잭션의 수행결과를 참조할 수 없다.

• Durability (영구성)
  트랜잭션이 성공정으로 완료되면, 결과가 데이터베이스에 영구적으로 반영되어야 한다.

참고자료

트랜잭션 이해하기 좋은 유튭

AWS (Amazone Web Service)

아마존에서 제공하는 클라우드 컴퓨팅 서비스다.

클라우드 컴퓨팅은 인터넷을 통해 서버, 스토리지, 데이터베이스 등 다양한 IT 리소스를 온디멘드로 제공한다.

온디맨드란 수요에 반응한다는 의미로 사용자가 사용량에따라 제공하는 자원도 유동적으로 조절해서 비용적인 측면도 탄력적으로 조절할 수 있다.

사용자는 자신의 컴퓨터가 아닌 아마존이 소유한 컴퓨터에 원격으로 접속하여 다양한 기능을 사용할 수 있다.

인프라기술부터 인공지능, 빅테이터, 사물인터넷, 보안 등등 190가지 이상의 서비스가 있다.

어디서든 인터넷만 있다면 접속 가능하고 비용만 지불한다면 이미 완성된 인프라를 쓸 수 있기 때문에 비용절감 효과가 크다.

클라우드 컴퓨팅 유형은 크게 세가지가 있다.

IaaS (Infrastructure as a Service)

가장 기본적인 클라우드 서비스로 스토리지,네트워크,운영체제같은 IT인프라를 제공한다.
하드웨어 자원 일부를 제공하면 사용자는 그 하드웨어를 사용해 가상서버를 하나 만들어 관리한다.

PaaS (Platform as a Service)

Iass 에서 추가로 가상 서버까지 합쳐진 플랫폼을 제공한다. 사용자가 인프라를 직접 관리할 필요없이 API 개발에 집중할 수 있도록 해준다.
쉽게 이야기하면 내가 코드를 만들어서 올리면 클라우드에서 알아서 서버에 올리고 배포까지 해준다.

SaaS (Software as a Service)

서비스 공급자가 인프라부터 서비스 유지관리까지 모든 부분을 관리한다. 한마디로 Paas에 완성된 소프트웨어까지 포함된 완전한 제품을 제공한다. 사용자는 이미 완성된 이 애플리케이션을 사용만하면 된다.
이메일, sns, 온라인페이, 유튜브 같은 완전한 서비스다.

웹 프레임워크

• 웹 페이지나 웹 애플리케이션, 웹 서비스 개발을 돕는 도구
• 개발에 필요한 기능 제공 (DB연동, 필수 프로세스 자동화, 표준화, 라이브러리 ...)
• 사용하는 언어마다 다양한 프레임워크가 존재
  • (파이썬-장고, 자바-스프링, 자바스크립트-노드 등등)

• 라이브러리와 프레임워크 모두 만들어진것을 가져다쓰기 때문에 헷갈릴 수 있음
  • 라이브러리는 이미 구현된 기능을 가져다 쓰는것(기능을 커스텀하기 힘듦)
  • 프레임워크는 큰 틀은 정해져있지만 프레임워크 내부에서는 원하는대로 커스텀해서 쓰는것

MVC(Model View Controller)

• 웹 프레임워크의 기본구조
  • Model : 데이터를 포함한 다양한 정보
  • View : 실제 웹에 보여지는부분(데이터의 입출력)
  • Controller : 사용자가 view에서 model에 접근할 수 있게 도움

파이썬의 프레임워크

1. 장고

• 웹 개발에 필요한 기능들을 가지고 있음 (풀스택 개발에 유리)
• MVC를 기반으로한 MVT(Model View Template) 패턴 사용
• ORM 지원
• DB를 파이썬으로 운영가능
• 안정성, 유연성을 모두 갖춰 크고 복잡한 프로젝트에 적합

1. 플라스크

• 핵심적인 최소한의 기능을 가짐 (마이크로 프레임워크)
• 기능이 적은만큼 공부하기 쉽고 사용도 간편
• 주로 SQLAlchemy 를 같이 사용해 DB를 제어
• 작고 단순한 프로젝트에 적합

1. FastAPI

• 가장 빠르고 배우고 쓰고 운영하는것이 쉬움
• 공식문서는 완벽하지만(영어) 커뮤니티에 정보가 거의없음
• WSGI가 아닌 ASGI(비동기작업)으로 트레픽이 적고 유지보수가 쉬움
  • 장고,플라스트 모두 WSGI 사용
  • 간단하게 비교하자면 WSGI는 트레픽이 많을수록 처리하기 힘들고 느려짐
  • ASGI는 한번에 많은트레픽을 빠르게 처리

선택은?

• 장고
  • 파이썬이 처음인데 뭔가를 만들어보고싶다
  • 한글로된 정보가 많아야한다
  • 프론트앤드도 해보고싶다
  • ORM을 사용하기 편하고 보안이 탄탄하면 좋겠다
  • NOoSQL을 사용하지 않을것이다
• 플라스크
  • 장고는 공부할내용이 너무많다
  • 빠르고 가벼운 프로젝트를 연습해보고싶다
  • 정보가 많고 웹프레임워크에 대해서 잘 모른다
• FastAPI
  • 정보가 없어도 트렌드를 앞서가고싶다
  • 웹 프레임워크에대해 잘 안다
  • ASGI, Uvicorn을 사용해서 비동기서버를 만들어보고 싶다

애자일(Agile)

애자일은 사람에 대한 신뢰, 빠른적응력이 생존에 유리하다는 전제를 가진 철학이자 문화다.

틀이 정해져있는 방법이 아니라 기업, 문화, 분야에따라 다르게 적용될 수 있는 유동적인 방법이다.

다양한 분야에서 애자일이 적용되고 있지만 이번에는 소프트웨어 개발분야의 애자일에 대해 정리해보자.

개발 방법론

소프트웨어 분야에서는 어떤 방식으로 개발할 것인지 정해야하는데 이를 ‘개발방법론’ 이라 하며

자주 등장하는것이 애자일과 waterfall 이다.

Waterfall (워터폴)

waterfall 방식은 소프트웨어 개발의 모든 단계(분석, 설계, 개발)를 순서대로 진행 후 마지막에 성능에 대한 통합 테스트 및 피드백을 받는 방식이다.

워터폴 방식은 체계적이지만 개발 마무리 후 테스트 및 피드백을 진행하기 때문에 변경사항, 추가요구사항을 적용시키기 어렵다.

애자일

애자일은 개발단계부터 마무리 테스트까지 정해진 순서를 따르기보다

업무과정을 작은 단위로 나누고 중요한 핵심기능을 우선적으로 개발함으로써 초기에 리스크를 식별하고 대응할 수 있다.

최소한의 핵심기능을 만들어 피드백을 받고 재설계하는 과정을 반복하여 최종 결과물을 만들어내는 것이다.

최근 애자일이 각광받는 이유는 변동성이 큰 현대시장의 변화에 적응하며 개발 할 수 있기때문이다.

(워터폴은 초기에 정해둔 단계에따라 일단 개발을 완료하기 때문에 개발과정 중 발생하는 시장변화를 적용시키기 어렵다)

하지만 기업 입장에서는 매 단계마다 소비자와 시장에 적응하며 제품을 변경하는것 또한 경제적, 현실적으로 쉽지않다.

각각의 업무를 작게 나누기 때문에 개인의 능력, 성향, 책임감이 전체 개발에 미치는 영향도 크다.

애자일이 모든 기업에서 성공하지 못하는 이유는 회사나 상품의 규모가 커질수록 팀원 개개인의 능력과 책임감을 유지,관리하는것이 어렵기 때문이다.

물론 모든 팀원이 각자의 업무에 100% 헌신하여 책임감과 능력을 발휘해준다면 애자일은 최고의 방법론이 되겠지만 현실적으로 어렵다.

애자일이 사람간 신뢰를 전제로 하는것도 이런 이유에서다.

무조건 애자일이 옳은것이 아니다

워터폴과 애자일의 장단점을 고려해 상황에 맞는 개발방법론을 적용시켜야 한다.

국내에서도 스타트업과 소수의 대기업을 제외하면 대부분 워터폴방식 기반의 업무방식으로 잘 운영되고 있다.