1/13/2023

기술 능력이 엔지니어에게 가장 중요한 항목이 아닌 이유

일반적으로 엔지니어라고 하면 테크 스킬이 가장 중요한 것이라고 생각을 한다. 물론 엔지니어가 되기 위해서는 기술적 지식이 당연히 필요하고 기술 숙련도에 중점을 둘 가능성이 매우 높다. 하지만 효과적으로 의사소통을 하는 능력은 간과되는 경향이 있다.


엔지니어에게 커뮤니케이션 기술이 필요한 이유는 무엇일까? 우리가 진행하는 과제들은 개인이 혼자서 해결할 수 있는 것이 매우 적다. 기술 지식을 가진 사람들로 구성된 사람들 혹은 팀 간의 협업이 필요하다. 어떤 과제를 하기 위해서는 기술 베이스의 사람도 있지만 기획, 비즈니스 등 다양한 배경을 가진 사람들이 모여서 협업을 하기에 의사소통을 잘하면 더 효율적으로 진행할 수 있다.

어떻게 이해관계자의 기여를 받고 중복되거나 낭비되는 작업을 방지할 수 있을까? 아래 사항들을 고려해서 진행해야 한다.

  • 모든 사람이 공동의 목표를 보고 있는지 확인
  • 결과물의 모습과 이를 달성하기 위한 로드맵 공유
  • 개발 전반에 걸쳐 지속적인 테스트를 통해 불확실성을 해소 및 수용

위에 언급된 항목에는 기술 지식에 대한 언급은 없다.

훌륭한 엔지니어는 이론 및 경험에 대한 지식을 지니고 있다. 코드 수준에서만 작업할 수 있는 사람은 다른 사람이 수행한 기존 구현내에서만 작업할 수 있고, 새로운 로직을 만들려면 수학적 관점에서 로직을 수립하는 것을 이해해야 한다. 그렇지 않으면 항상 다른 사람의 작업물 내에서 진행할 수 밖에 없다.

최고의 엔지니어는 비즈니스와 외부에서 무슨 일이 일어나고 있는지 알고 있어야 한다. 남들이 하는 일을 따라가지 못한다면 결국 뒤처지기 때문이다.

뛰어난 엔지니어는 전체 스택을 이해한다. 아는 범위 내에서 생각하고 결과물을 낼 수밖에 없기 때문에 전체를 이해하려고 노력한다.

신급 엔지니어는 사람들과 대화하는 방법을 알고 있다. 사람들은 자신이 알고 있는 것을 상대방도 알고 있다고 오해하여 불필요한 오버헤드를 만들기도 한다. 동료 엔지니어와 대화하는 경우에는 히스토리를 포함해 단순화하여 커뮤니케이션을 해야 한다. 좋은 일과 위대한 일의 차이는 얼마나 그것이 잘 설명되어 있느냐이다.

커뮤니케이션 기술을 향상시키고 엔지니어링 능력을 향상시키기 위한 단계를 아래와 같다.

1. 다른 사람의 말을 듣는 법을 배우자

다른 사람들은 나와 다르게 의사소통한다는 것을 이해해야 한다. 기술적인 부분을 사업 쪽에 설명할 때, 같은 내용을 전달하는 것도 다양한 방법이 있다는 것을 이해해야 한다. 그리고 그들과 상호 작용할 때는 “그들의 언어”로 소통해야 한다. Mirroring이라는 기술을 이용하게 되면 효과적인 언어 및 비언어적 의사소통 방법을 알 수 있고, 실험해 볼 수 있다. 나도 사업 쪽과 상호 작용을 하면서 이렇게 하려고 많은 노력을 기울이고 있다.

2. 더 많은 대화 시작

서로의 생각을 맞추려면 더 많이 이야기를 해야 한다. 그리고 대화가 끝나면 아쉬웠던 부분을 기억하고 더 나아질 수 있도록 해야 한다.

3. 공감

가장 어려운 것은 공감 능력을 키우는 것이다. 누군가가 당신의 하루를 망치는 무언가를 전달한다면 그들이 어떤 제약을 받고 있는지 생각해야 한다. 물론 이 관점은 사람들이 좋은 의도를 가지고 있다는 가정이다. “왜 이렇게까지 해야 했지?”라고 생각하고 직설적으로 물어 볼 필요도 있다. 누군가를 이해하기 위해 질문하는 것은 경험에서 배울 수 있는 최고의 엔지니어링 기술과 자질 중 하나이다. 이런 부분들을 무서워하거나 두려워하면 안된다.

끝으로, 우리는 종종 기술 숙련도를 엔지니어가 개발해야 할 핵심 기술로 본다. 물론 코딩 및 설계를 할 수 있다는 것은 매우 중요하다. 하지만 코딩하는 내용을 간결하게 전달할 수 없다면 성과를 잘 설명할 수 없을 것이다. 의사소통은 엔지니어가 배워야 할 필수 기술이다. 그 이유는 이해관계자들이 다른 전문가보다 더 잘 소통된다고 느끼기 때문이다.

12/05/2022

모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까?

모놀리식과 마이크로서비스 아키텍처중 어떤 아키텍처를 선택해야 하는지에 대해서 요즘IT에 기고했다. 아래는 기고한 글 일부이다.


애플리케이션의 아키텍처 스타일(모놀리식 vs 마이크로서비스)에 대한 선택은 트렌드나 경쟁사의 특징을 따르기보다, 애플리케이션의 목표와 비즈니스 요구 사항에 따라 달라진다. (생략) 모놀리식 애플리케이션은 소프트웨어 개발을 위한 기본 접근 방식이다. 그렇다면 마이크로서비스가 대세가 된 현재 모놀리식 접근 방식을 버려야 할까? 만약 모놀리식 애플리케이션에서 마이크로서비스로 전환하면 어떤 이점이 있을까? 마이크로서비스로 애플리케이션을 만들면 비즈니스의 이점은 무엇일까? 이번 글에서는 모놀리식과 마이크로서비스 아키텍처를 비교하여 장단점을 살펴보고, 비즈니스에 적합한 소프트웨어 아키텍처를 선택하는 방법에 대해서 알아보자.

(생략)

개발자라면 누구나 내가 설계하고 작성한 코드가 비즈니스에 큰 가치를 줄 때 성취감을 느낄 것이다. 이것은 우리가 기술을 다루지만, 항상 비지니스를 염두해 두고 고민해야 함을 뜻한다. 이번 글을 참고하여, 현 비즈니스 상황에 최적화된 아키텍처를 선택할 수 있길 바란다.

아래 링크를 통해 원본 글을 볼 수 있다.

기고글 보러 가기

10/16/2022

좋은 팀 구성 및 개발 문화 조성의 중요성

 GS리테일에 입사 후 팀빌딩과 개발 문화를 구축한 경험에 대해서 요즘IT 매거진에 기고했다.

본 글은 요즘IT 매거진에 기고한 글의 일부를 가져왔다.

<출처: https://unsplash.com/photos/Zyx1bK9mqmA>

함께 할 동료가 모였으니 이제 실제 업무를 진행할 차례다. 개발팀은 잘 작동하는 소프트웨어를 구축하는 것부터 기술 변화의 빠른 속도를 따라가는 것과 같은 문제를 해결해야 하는 경우가 많다. 가장 좋은 방법의 하나는 매력적이고 창의적인 팀을 구성하는 것이다.

어떻게 매력적이고 창의적인 팀을 구성할 수 있을까? 답은 간단했다.

“즐기게 놔두는 것이다.”

(생략)

아래 링크를 통해 원본 글을 볼 수 있다.

기고글 보러 가기


10/13/2022

Moduler Monolithic 아키텍처

프로젝트를 준비하면서 아키텍처에 대한 고민이 많다. 마이크로서비스 아키텍처로 프로젝트를 하였지만, 현 상황에서는 마이크로서비스 아키텍처가 어울리지 않을 수 있다는 판단을 했고 이유는 아래와 같다.

  1. B2C라고 볼 순 있지만 사용자 수가 정해져 있다.
  2. 트래픽이 증가하는 시간이 정해져 있다.
  3. 리소스 비용을 절약해야 함 (비용 감축을 위해서 트래픽이 몰리는 시간대외에는 인스턴스를 축소할 계획 있음)
  4. 데이터베이스가 통합되어 있음 (미니서비스로 고려가 가능)
  5. 각 서비스마다 다른 기술을 사용하진 않을 것 같음
  6. 레거시가 존재하기에 리팩토링이 우선되어야 함 (이 부분이 가장 중요!)

또한, 아래 사항들을 고려해야 한다.

  1. 글로벌 진출 시 로컬라이제이션을 고려해야 함
  2. 확장 가능하고 재사용 가능하며 유지보수가 쉽도록 만들어야 함
  3. 새로운 사람이 참여하게 되면 비즈니스 기능 및 시스템 기능을 쉽게 이해할 수 있어야 함
  4. Actor별 UI가 각각 존재해야 함
  5. 외부로 연계되는 부분이 많음
  6. 마이크로서비스 아키텍처 전환에 대한 기틀 마련

모놀리식은 단일 단위의 애플리케이션이다. 즉, 모든 비즈니스 로직이 한 곳에 있고 애플리케이션에 변경 사항이 적용되면 전체 애플리케이션에 영향을 미치기에 전체가 다시 배포되어야 한다.

또한, 모놀리식은 종종 큰 진흙 덩어리처럼 보이기도 한다. 시간이 지남에 따라 애플리케이션이 발전하기에 비대해지기 때문이다.

<출처: https://lewiseason.co.uk/2019/11/05/large-application-architectures>

위 그림은 큰 진흙 덩어리인지 분산된 진흙 덩어리인지에 따라 모듈러 모놀리식과 마이크로서비스 아키텍처를 선택하는 것에 대한 아이디어를 준다. 초반에는 모듈식 모놀리식으로 시작하고 제품이 충분히 성공적이면 마이크로서비스로의 이동을 고려해 볼 수 있다.

모놀리식 아키텍처

기존의 모놀리식 애플리케이션은 빌드할 때 코드 개발 및 유지 관리를 쉽게 하기 위해 로직을 여러 계층으로 나눈다.


<출처: https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/>

위의 구조는 효율적으로 애플리케이션을 구축하기 위한 방법이지만, 코드를 변경하면 전체에 영향을 미치기 때문에 유연하지 않다. 이런 상황으로 인해 순수한 모놀리식은 사용할 수 없다.

모듈식 모놀리식 아키텍처

모듈식 모놀리식 아키텍처는 먼저 로직을 모듈로 나누는 방식으로 구성되며, 각 모듈은 독립적이고 격리된다. 각 모듈에는 고유한 비즈니스 로직이 있어야 한다. 이렇게 다른 모듈에는 최대한 영향을 주지 않고 레이어를 만들고 수정할 수 있어야 한다.

<출처: https://www.fullstacklabs.co/blog/modular-monolithic-vs-microservices>

마이크로서비스 아키텍처가 모든 것을 해결하는 솔루션이 아니다. 더 적합한 다른 접근 방식이 존재할 수 있다. 결국 진화에 의해 향후에는 마이크로서비스 아키텍처로 끝나더라도 거기까지 도달하기 위한 다른 중간 단계가 존재하는 것이다.

모듈식 모놀리식은 아래의 특징을 지니고 있다.

  • 모듈은 완전히 독립적이지 않다. 다른 모듈과의 종속성이 있지만 최소화해야 한다.
  • 모듈은 상호 교환이 가능하다.
  • 코드를 재사용할 수 있다.
  • 기존의 모놀리식에 비해 종속성을 더 잘 구성할 수 있다.
  • 기존의 모놀리식보다 유지 관리하고 개발하기가 더 쉽다.
  • 배포를 위해 다른 서버가 필요 없이 전체 프로젝트를 단일 단위로 유지할 수 있다.
  • 기존의 모놀리식보다 확장성이 뛰어나다.
  • 마이크로서비스 아키텍처보다 덜 복잡하다.

일반적인 Java 패키징 체계는 아래 왼쪽 그림처럼 웹 항목, 비즈니스 로직, 데이터베이스 엑세스을 별도의 레이어 패키지로 그룹화 한다.

<출처: https://medium.com/design-and-tech-co/modular-monoliths-a-gateway-to-microservices-946f2cbdf382>

문제는 시간이 지나면 위 오른쪽 그림처럼 스파게티 코드가 만들어진다는 것이다. 이런 상황이 발생하는 것은 일반적으로 Java에서 대부분 클래스를 Public으로 선언 하기에 캡슐화하는 것이 아니기에 어디서든 접근 할 수 있게 된다.

결국, Jigsaw(자바 모듈 관리)를 이용해서 패키지를 관리해야 한다. (참고: https://openjdk.org/projects/jigsaw/)


<출처: https://medium.com/design-and-tech-co/modular-monoliths-a-gateway-to-microservices-946f2cbdf382>

위 그림의 패키징 체계에서는 비즈니스 로직 및 데이터 엑세스를 구현한 클래스는 보호되고, 해당 패키지의 접근은 유일하게 정의된 인터페이스를 통해서만 이루어지기에 된다.

이렇게 하면, 느슨하게 결합된 모듈을 만들 수 있고 인터페이스를 일관되게 유지 할 수 있고 향후 마이크로서비스 아키텍처로 전환 할 경우에도 유리하게 작용될 수 있다고 생각한다.

좋은 아키텍처는 끊임없이 진화하는 작업이며 올바른 솔루션은 운영 규모에 따라 달라진다.

이번 선택이 올바른 선택이길 바란다.


10/05/2022

소프트웨어 아키텍트의 역할

처음 IT 분야에서 일을 시작했을 때 소프트웨어 설계자라는 직책이 나의 관심을 끌었었다. 소프트웨어 혹은 애플리케이션 아키텍트라는 이름이 아름답고 우아하게 보였다. 그리고 아키텍트가 되기로 마음먹었었다.

아키텍트가 되기 위해서는 코딩, 아키텍처, 패턴, 커뮤니케이션 스킬 등 다양한 주제를 깊이 있게 공부하고 경험해야 했다. 나에게 아키텍트가 된다는 것은 훌륭한 개발자가 되고 아키텍처에 대해서 최대한 아는 것을 의미했기 때문이다.

우리는 일반적으로 수석 개발자나 우수한 개발자가 자신은 아키텍트라고 말하는 것을 본다. “Role of the Software Architect”에서 Simon Brown은 소프트웨어 아키텍트가 되는 것은 간단한 일이 아니라고 말한다. 점진적으로 역할을 수행하는데 필요한 경험과 자신감을 얻게 되는 과정이 필요하다. Simon Brown은 아키텍트를 역할로 간주하므로 한 사람이 수행하거나 팀에서 공유될 수 있다.

이번 글에서는 내가 생각하는 아키텍트의 역할을 정리해 보았다. 프로젝트 수행 시마다 아래의 역할을 잘 수행하려고 노력 중이다.


<이미지 출처: https://unsplash.com/photos/mfB1B1s4sMc>

아키텍트의 역할

Architectural Drivers

비즈니스 목표를 이해하고 솔루션을 제공하고 기능 및 비기능적 요구사항과 환경의 제약을 고려하여 아키텍처를 수립해야 했다. 소프트웨어 설계자는 비기능 요구 사항 및 제약 조건이 아키텍처에 큰 영향을 미치기에 이를 고려해야 한다는 점을 인식해야 한다.

소프트웨어 설계

소프트웨어 설계는 아키텍트에게는 정말 중요한 역할이다. 아키텍처 드라이버에서 제기하는 문제를 해결하고 시스템의 전체 구조에 대한 비전을 만드는 방법에 관한 것이다. 디자인 패턴과 최상위 디자인 접근 방식에 능숙해야 하고 기술 선택도 잘 해야 한다.

기술적 위험

아키텍트는 프로젝트에서 사용할 기술을 선택해야 한다. 이 행위는 위험 관리에 대한 부분이기도 하다. 복잡성이나 불확실성에 대한 리스크를 줄이고 이익이 있는 곳에서는 리스크를 도입해야 한다. 이 과정에서 가장 중요한 것은 성숙된 기술을 사용하는 것이다. 대부분의 경우에 새로운 기술에 대한 경쟁 우위 유혹을 받을 수 있다. 명심할 점은 소프트웨어 세계에서의 얼리어답터는 해당 기술의 버그를 찾아주는 선구자 역할을 수행할 수 있다.

아키텍처 진화

소프트웨어 아키텍처의 결과는 유지 관리 및 확장이 쉬운 소프트웨어야 한다. 아키텍트는 담당한 소프트웨어가 성장하도록 설계해야 한다.

코딩

아키텍트도 개발자이다. 이 점을 잊으면 안 된다. 대부분 사람들은 아키텍트가 되면 코딩할 필요가 없다고 생각한다. 이것은 매우 위험한 생각이다. 소프트웨어 아키텍트가 된다는 것은 코딩 작업등에 반드시 참여한다는 의미는 아니지만, 설계 및 구현에 대한 부분을 전달하는데 지속적으로 참여해야 함을 의미한다. 코딩에 대한 기반이 없으면 주도하고 나아갈 수 없다.

품질 보증

버그가 많은 제품을 출시하는 경우에는 아키텍트의 역할에 대한 의미가 퇴색된다. 품질에 대한 보증은 아키텍트 역할의 일부로 간주해야 한다. 코딩 표준, 디자인 원칙 및 도구 그리고 프로젝트의 품질을 보장하기 위한 기준선이 필요하다. 아키텍트가 설계한 것이 프로젝트 전반에 일관되게 구현되고 있는지 상시 확인해야 한다. 이런 행위를 아키텍처 원칙 준수라고 한다.

결론

소프트웨어 아키텍트가 되려면 정말 많은 일을 해서 경험을 쌓아야 한다는 사실을 알아야 한다. 어려운 의사 결정을 내리고 책임을 질 준비가 되어 있어야 한다. 가장 중요한 점은 실패하지 않을 제품을 제공할 것을 보장해야 한다.

8/18/2022

애플리케이션 현대화로 가는 길

 

오래된 기술

어느 회사나 오래된 기술로 만들어진 시스템을 가지고 있을 것이다. 이것과 관련해서 흔히들 “잘 작동하면 만지지 마세요.”라고 얘기한다. 변경 사항이 없을 경우에는 맞는 말이다. 잘 동작되고 있는데 굳이 변경할 필요는 없기 때문이다. 하지만, 문제가 발생하거나 변경을 해야 할 경우에는 어떻게 해야 할까? 오래된 기술을 알고 있는 사람을 고용하기는 매우 어려울 것이다. 10~20년전에 이 코드를 작성한 사람들은 아마 은퇴를 했을 것이고, 젊은 개발자들은 이 기술을 배우고 싶어하지 않을 것이다. 억지로 하라고 하면 이탈로 이어질 것이고, 좋은 개발자는 그 조직에 있지 않게 될 것이다.

새로운 기술 채택 및 비즈니스 상황 대응

새로운 기술과 패턴들은 놀라운 속도로 등장하고 있다. 과거에 존재했던 것들보다 현대에는 관련 기술이 풍부하고 더 최적화되어 있는 것들이 많다. 이런 기술들을 적용하는 것은 디지털 세계에서 생존하는데 매우 중요하지만, 레거시 시스템으로 운용하는 기업은 경쟁의 속도를 따라 갈 수 없다. 비즈니스를 지원하는데 많은 비용과 시간이 소요되기에 필요 시점에 고객이 원하는 기능을 제공할 수 없기 때문이다.

애플리케이션은 언제 구식이 되는가?

빌게이츠는 “성공한 기업은 다른 기업보다 먼저 자신의 제품을 구식으로 만든 기업이다.”라는 말을 했다. 이 분야에서 일하면서 매년 새롭게 기술이 탄생하는 것을 지켜보게된다. 하지만, 새로운 기술이 나왔다고 바로 적용하진 않는다. 일반적으로 10-15년 정도가 애플리케이션의 수명이라고 생각한다. 시스템을 “구식”이라고 정의할 수 있는 기준은 무엇일까?

  1. 도입한 솔루션이 있을 경우, 벤더사의 지원을 더이상 받을 수 없을때에 해당된다.
  2. 새로운 비즈니스 요구사항을 반영하기 어려운 상황이 발생한 경우에 해당된다. (억지로 반영하다가는 부채만 쌓이게 된다.)
  3. 현재는 사용되지 않는 하드웨어 혹은 특정 상황에서만 작동되는 경우에 해당된다.

어떻게 현대화를 해야 할까?

애플리케이션을 현대화하기 위해서는 다음 사항이 고려되야 한다.

  • 현대화를 해서 어떤 결과를 얻고자 하는가?
  • 어떤 자원을 가지고 있는가?
  • 직접 코드를 수정하거나 제어할 수 있는가?
  • 변경되거나 새롭게 만들어야 하는 항목에 대해 위험 평가를 수행해야 한다.

현대화에 대한 비용 옵션은 어떤 것들이 있을까?

  1. 다음 세대로 미루고 아무것도 하지 않음
    • 가장 쉬운 방법이다. 현대화를 통해 비즈니스 가치를 찾지 못한다면 올바른 선택이 될 수 있다.
    • 어떤 시스템을 현대화하려고 하는데, 연관된 시스템들이 많아서 전부 건들 수 없는 경우에도 해당된다. 모두 완료되어야 현대화가 되기 때문에 불가한 상황이라고 판단
  2. 재호스팅 또는 리프트 앤 시프트
    • 클라우드로 아무 수정없이 옮기는 방법이다.
  3. 재구축
    • 재호스팅을 하면서 코드를 약간 변경하는 방식이다. 예를 들어서 데이터베이스, 검색 기능등은 클라우드 리소스를 활용한다.
  4. 애플리케이션 프론트엔드 현대화
    • 백엔드에서 제공하는 API를 이용해 프론트엔드만 현대화하는 방식이다.
    • UX는 시대에 따라 자주 변하기에 레거시 애플리케이션의 일반적인 문제 중 하나를 제거할 수 있다.
    • 단, API가 잘 만들어져 있어야 한다.
  5. 리팩토링
    • 간혹 애플리케이션이 현재 상황에 맞게 구축되지 않았거나 진화가 안되었을 경우에 해당된다.
    • 비즈니스 로직은 변화하지 않으며, 코드가 새롭게 작성되는 방식이다.
  6. 완전 재구축
    • 이 경우, 레거시 시스템을 완전 새로운 애플리케이션으로 대체한다.
    • “빅뱅”으로 재구축하기에 철저한 분석, 설계, 테스트 및 데이터 마이그레이션 전략이 필요하다.
    • 또한, 이전 애플리케이션으로 롤백하는 전략이 필요하다.

끝으로

현대화를 하기 위해서는 위험도, 예산, 시간, 리소스, 애플리케이션 종속성과 같은 제약 조건을 고려해야 한다. 가장 좋은 방법은 기존 애플리케이션을 분석하고 평가하여 TO-BE 방향성을 식별하는 것이다. 각 옵션에 대해 비용 및 위험 대비 효과와 같은 ROI를 추정해야 한다. 백데이터가 있어야 현대화 진행에 대한 의사결정을 할 수 있을 것이다.

8/17/2022

레거시 시스템 구조개선 고민

하나의 거대한 모놀리스로 되어 있는 오래된 시스템을 구조 개선을 하기 위해 분석중이다. 분석을 시작하기 전에는 마이크로서비스에 대한 언급이 많았다. 마이크로서비스는 훌륭한 방법이긴 하다. 모듈식이며 확장 가능하고 내결함성도 좋다. 이름만 들어도 익히 알고 있는 유명한 곳에서 이 모델을 사용하여 큰 성공을 거두었기에 마이크로서비스로 아키텍처를 잡는 것이 훌륭하게 보일 수 있다.

그러나 마이크로서비스로 성공한 대부분의 기업은 처음부터 마이크로서비스로 시작하진 않았다. 트위터나 에어비앤비 같은 경우는 마이크로서비스로 전환을 했지만, 현재 복잡성과 대면을 하고 있다. 마이크로서비스를 사용해서 성공한 회사도 최선의 방법을 계속 찾고 있는 것이다.

모놀리스에서 마이크로서비스로 개선하는 것은 간단한 작업도 아니고… 더군다나 PL/SQL, DB Custom Function, Trigger, EAI로 도배되어 있는 현 시스템을 바로 전환하기에는 무리가 있다. 궁극적으로는 향후에는 마이크로서비스로 갈 것이지만, 기술 부채를 먼저 해결하는 Goal을 설정했다. 그 이유는 아래와 같다.

마이크로서비스는 성숙한 제품이어야 가능

마틴파울러가 작성한 MonolithFirst(https://martinfowler.com/bliki/MonolithFirst.html) 에는 마이크로서비스로 시작하는 경우에 대한 케이스가 있다.

  1. 성공적인 마이크로서비스는 너무 거대해서 부서지게된 모놀리스에서 시작한 경우
  2. 처음부터 마이크로서비스로 구축된 시스템이 실패로 끝나는 경우

초기 설계를 제대로 하지 못한다면 모놀리스보다 마이크로서비스를 리팩토링하는 것이 훨씬 어렵기에 초기 설계를 잘해야 한다. 현재는 마이크로서비스로 전환한다라고 얘기할 단계가 아니고, 더욱 성숙되게 만드는 작업이 우선시되어야 한다.

내가 일하고 있는 회사는?

스타트업에서 처음 서비스를 만든다고 가정하면 초반에는 확장성이 필요하지 않을 것 같다. 아마도 필요한 시점은 서비스 런칭 후 몇 년내에 발생할 것이다. (잘 된다는 가정) 따라서, 처음부터 복잡한 아키텍처를 선택할 이유는 없을 것이다.

반면, 이미 운영되고 있는 서비스는 얘기가 달라진다. 확장성과 유연성이 필요할 것이다. (현재 내 상황이 이렇다.) 그래서 DB에 집중되어 있는 비즈니스 로직을 애플리케이션으로 이동시키면서 Miniservice 형태의 서비스 분리를 고려중이다. (서비스별 DB 분리는 어려운 상황이다.)

어르신 시스템 생명 주기

모든 애플리케이션은 생명 주기가 존재한다. 레거시 시스템은 오래되고 복잡한 부분이 많고, 현재 사용되고 있지 않은 기술들도 많이 적용되어 있다. 이런 시스템을 마이크로서비스로 전환한다면 기존 코드를 버리는 것이 효과적일 것이다. 하지만, 작동을 하고 있는 제품을 버리기는 쉽지 않다. 비용을 고려해야 하기 때문이다. 우선 모듈화를 선행해야 한다.

모듈화에도 많은 공수가 들어가지만, 개발을 보다 간단하게 만들기 때문에 가치는 충분하다. 모듈화라는 것은 큰 모놀리스를 작게 만들기 때문이다. 모듈화는 마이크로서비스로 전환하기 전에 꼭! 필요한 단계이다. 모듈식 모놀리스로 만들면 코드는 독립적인 모듈로 분할하여 얽혀있는 코드 문제를 해결해야 한다. 모듈식 모놀리스는 마이크로서비스와는 달리 네트워크 통신이 아닌 내부 API 호출로 통신하게 된다. 기존 소스를 활용하진 않지만, 모듈형태로 구성이 되어 있는지 확인해야 하고, 되어 있지 않다면 모듈화를 설계상 고려해야 한다.

준비가 안되거나 견고한 설계 없이 마이크로서비스로 여정을 시작한다면 매우 힘든 시간을 겪을 것이다. 결국 바꾸고 싶은 모습으로 가기 위한 선행 작업들을 진행해야 한다. 최종 Goal로 가기위한 선행 조건을 만족시키는 것이 이번 프로젝트의 목표이다.(기반이 튼튼해야 하기에…)