top of page

​홈 >

Technology

Technology

What for DT

What shape of an application should be?

dt_what.png

지금까지의 대부분 기업의 Application의 형상은 Monolith 한 아키텍처였습니다. Application을 이루고 있는 여러 구성요소가 긴밀하게 연결되어 데이터와 서비스를 주고 받는 Tightly-Integrated 된 모습이었습니다.

​

마찬가지로 이런 형상은 시장의 요구사항이 단순하며 변경 가능성이 적은 환경에서는 효율적인 구조였으나 수시로 변화와 혁신이 필요한 시점에 각 구성요소들이 필요에 따라 적응/변화하기에 매우 어려운 구조입니다.

 

따라서 각 구성요소들이 독립적으로 존재하면서 시장의 변화에 맞춰 쉽고 빠르게 적응하면서도 연결이 필요한 최소한의 부분은 표준화된 API을 통해 연동될 수 있는 loosely-Integrated 된 형상의 MSA 가 대세인 방향으로 변화하고 있습니다.

How for DT

How should an application
be built?

과거 수십년 동안 Application을 개발하는 방법론의 주류는 폭포수 모델 (Waterfall)이었습니다. 분석 / 설계 / 개발 / 테스트 후 배포라는 명확한 공정 / 절차와 일정계획에 따라 상대적으로 긴 개발주기로 Application을 만들어 내었습니다.

 

이런 방법은 Digital Transformation 이전의 단계, 즉 시장의 요구사항 단순하며 변경 가능성이 적고 개발의 규모와 난이도가 상대적으로 작은 환경에서는 유효한 방법론이었습니다. 하지만, 시장의 요구사항이 급격하게 변화하고 있고 신속하게 이에 대응해야 하는 Digital Transformation 단계에서는 맞지 않습니다.

 

따라서, 최근에는 상대적으로 짧지만 반복적인 개발주기로 공정과 절차보다는 실질적인 코딩을 통해 적시에 시장의 요구사항에 대응하는 기능을 제공하는 Agile 및 이와 밀접한 관계가 있는 DevOps 스타일로 개발을 진행하는 방향으로 변화하고 있습니다. 

폭포수 기법

  • 대규모 기능 팀

  • 순차적 진행

  • 예측에 기반한 계획

  • ​사전에 정의된 과제 고수

       (변경 불가)

Waterfall02.png

WATERFALL

애자일 기법

  • 소규모 기능 팀

  • 순환적 진행

  • 과제의 모듈화, 우선 순위화

  • ​유연하고 지속적인 진화

AGILE & DEVOPS

Agile02.png
Where in DT

Where should an application be run?

dt_where.png

몇 년 전까지만해도 대부분의 전통적인 기업에서는 Application을 데이터센터에 Bare-Metal 혹은 가상화 환경에서 직접 운영하는 것이 일반적이었습니다. 하지만, 지금은 아주 빠른 속도로 cloud 또 container 환경으로 IT 인프라를 이동해 가는 추세입니다.

 

이는 위에 언급한 Application을 개발하는 방법이나 Application의 형상이 변화에 맞춰 인프라 역시 급변하는 시장의 변화에 맞춰 신속하고 용이하게 Application 을 운영/서비스할 수 있도록 하는 방향으로 변화하고 있습니다.

bottom of page