2021.11.16

마이크로서비스 아키텍처를 사용해야 하는 이유

Lee Atchison | InfoWorld
현재 운영 중인 애플리케이션은 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다. 

단, 문제가 있다. 
 
ⓒ Getty Images Bank

애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라. 

개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다. 

추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다.

많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다.

여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터무니없이 어렵다. 

함정 속에서 오도가도 못하는 상황이다. 

이 함정을 피해갈 방법은 있다. 애플리케이션을 재설계해서 회사의 발목을 잡는 것이 아니라 회사와 함께 확장되도록 하면 된다. 
 

성장하는 애플리케이션 

시작은 한 사람 또는 소규모 개발팀이 쓰고 관리하는 단순한 애플리케이션이었다. <그림 1>과 같이 간단하고 깔끔한 애플리케이션이다. 
 
그림 1. 단순하지만 성장하고 있는 애플리케이션 ⓒ IDG

그러나 시간이 지나면서 애플리케이션은 성장한다. 애플리케이션이 성공하고 트래픽이 급격히 증가한다. 새로운 기능을 추가하고 더 많은 개발자를 채용해 애플리케이션에 투입한다. 곧 <그림 2>와 같은 모습이 된다. 
 
그림 2. 복잡하고 정체된 애플리케이션 ⓒ IDG


이제 문제가 생겼다. 누구도 자신이 애플리케이션의 어느 부분을 소유하는지를 모른다. 팀 1이 변경을 하면 팀 3에 영향을 미친다. 긴장감이 팽배하고 생산성은 낮다. 애플리케이션에 버그가 만연하면서 사이트에서 언뜻 보기에는 무작위로 장애가 일어난다. 장애가 발생하면 여러 팀이 달라붙어 문제를 찾기 위해 고군분투한다. 애플리케이션의 모든 부분을 이해하는 한 사람이 없기 때문이다. 이것이 함정의 전형적인 예다. 



2021.11.16

마이크로서비스 아키텍처를 사용해야 하는 이유

Lee Atchison | InfoWorld
현재 운영 중인 애플리케이션은 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다. 

단, 문제가 있다. 
 
ⓒ Getty Images Bank

애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라. 

개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다. 

추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다.

많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다.

여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터무니없이 어렵다. 

함정 속에서 오도가도 못하는 상황이다. 

이 함정을 피해갈 방법은 있다. 애플리케이션을 재설계해서 회사의 발목을 잡는 것이 아니라 회사와 함께 확장되도록 하면 된다. 
 

성장하는 애플리케이션 

시작은 한 사람 또는 소규모 개발팀이 쓰고 관리하는 단순한 애플리케이션이었다. <그림 1>과 같이 간단하고 깔끔한 애플리케이션이다. 
 
그림 1. 단순하지만 성장하고 있는 애플리케이션 ⓒ IDG

그러나 시간이 지나면서 애플리케이션은 성장한다. 애플리케이션이 성공하고 트래픽이 급격히 증가한다. 새로운 기능을 추가하고 더 많은 개발자를 채용해 애플리케이션에 투입한다. 곧 <그림 2>와 같은 모습이 된다. 
 
그림 2. 복잡하고 정체된 애플리케이션 ⓒ IDG


이제 문제가 생겼다. 누구도 자신이 애플리케이션의 어느 부분을 소유하는지를 모른다. 팀 1이 변경을 하면 팀 3에 영향을 미친다. 긴장감이 팽배하고 생산성은 낮다. 애플리케이션에 버그가 만연하면서 사이트에서 언뜻 보기에는 무작위로 장애가 일어난다. 장애가 발생하면 여러 팀이 달라붙어 문제를 찾기 위해 고군분투한다. 애플리케이션의 모든 부분을 이해하는 한 사람이 없기 때문이다. 이것이 함정의 전형적인 예다. 



X