GS리테일에 입사 후 팀빌딩과 개발 문화를 구축한 경험에 대해서 요즘IT 매거진에 기고했다.
본 글은 요즘IT 매거진에 기고한 글의 일부를 가져왔다.
<출처: https://unsplash.com/photos/Zyx1bK9mqmA>
함께 할 동료가 모였으니 이제 실제 업무를 진행할 차례다. 개발팀은 잘 작동하는 소프트웨어를 구축하는 것부터 기술 변화의 빠른 속도를 따라가는 것과 같은 문제를 해결해야 하는 경우가 많다. 가장 좋은 방법의 하나는 매력적이고 창의적인 팀을 구성하는 것이다.
어떻게 매력적이고 창의적인 팀을 구성할 수 있을까? 답은 간단했다.
(생략)
아래 링크를 통해 원본 글을 볼 수 있다.
프로젝트를 준비하면서 아키텍처에 대한 고민이 많다. 마이크로서비스 아키텍처로 프로젝트를 하였지만, 현 상황에서는 마이크로서비스 아키텍처가 어울리지 않을 수 있다는 판단을 했고 이유는 아래와 같다.
또한, 아래 사항들을 고려해야 한다.
모놀리식은 단일 단위의 애플리케이션이다. 즉, 모든 비즈니스 로직이 한 곳에 있고 애플리케이션에 변경 사항이 적용되면 전체 애플리케이션에 영향을 미치기에 전체가 다시 배포되어야 한다.
또한, 모놀리식은 종종 큰 진흙 덩어리처럼 보이기도 한다. 시간이 지남에 따라 애플리케이션이 발전하기에 비대해지기 때문이다.
<출처: 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>
위 그림의 패키징 체계에서는 비즈니스 로직 및 데이터 엑세스를 구현한 클래스는 보호되고, 해당 패키지의 접근은 유일하게 정의된 인터페이스를 통해서만 이루어지기에 된다.
이렇게 하면, 느슨하게 결합된 모듈을 만들 수 있고 인터페이스를 일관되게 유지 할 수 있고 향후 마이크로서비스 아키텍처로 전환 할 경우에도 유리하게 작용될 수 있다고 생각한다.
좋은 아키텍처는 끊임없이 진화하는 작업이며 올바른 솔루션은 운영 규모에 따라 달라진다.
이번 선택이 올바른 선택이길 바란다.
처음 IT 분야에서 일을 시작했을 때 소프트웨어 설계자라는 직책이 나의 관심을 끌었었다. 소프트웨어 혹은 애플리케이션 아키텍트라는 이름이 아름답고 우아하게 보였다. 그리고 아키텍트가 되기로 마음먹었었다.
아키텍트가 되기 위해서는 코딩, 아키텍처, 패턴, 커뮤니케이션 스킬 등 다양한 주제를 깊이 있게 공부하고 경험해야 했다. 나에게 아키텍트가 된다는 것은 훌륭한 개발자가 되고 아키텍처에 대해서 최대한 아는 것을 의미했기 때문이다.
우리는 일반적으로 수석 개발자나 우수한 개발자가 자신은 아키텍트라고 말하는 것을 본다. “Role of the Software Architect”에서 Simon Brown은 소프트웨어 아키텍트가 되는 것은 간단한 일이 아니라고 말한다. 점진적으로 역할을 수행하는데 필요한 경험과 자신감을 얻게 되는 과정이 필요하다. Simon Brown은 아키텍트를 역할로 간주하므로 한 사람이 수행하거나 팀에서 공유될 수 있다.
이번 글에서는 내가 생각하는 아키텍트의 역할을 정리해 보았다. 프로젝트 수행 시마다 아래의 역할을 잘 수행하려고 노력 중이다.
<이미지 출처: https://unsplash.com/photos/mfB1B1s4sMc>
비즈니스 목표를 이해하고 솔루션을 제공하고 기능 및 비기능적 요구사항과 환경의 제약을 고려하여 아키텍처를 수립해야 했다. 소프트웨어 설계자는 비기능 요구 사항 및 제약 조건이 아키텍처에 큰 영향을 미치기에 이를 고려해야 한다는 점을 인식해야 한다.
소프트웨어 설계는 아키텍트에게는 정말 중요한 역할이다. 아키텍처 드라이버에서 제기하는 문제를 해결하고 시스템의 전체 구조에 대한 비전을 만드는 방법에 관한 것이다. 디자인 패턴과 최상위 디자인 접근 방식에 능숙해야 하고 기술 선택도 잘 해야 한다.
아키텍트는 프로젝트에서 사용할 기술을 선택해야 한다. 이 행위는 위험 관리에 대한 부분이기도 하다. 복잡성이나 불확실성에 대한 리스크를 줄이고 이익이 있는 곳에서는 리스크를 도입해야 한다. 이 과정에서 가장 중요한 것은 성숙된 기술을 사용하는 것이다. 대부분의 경우에 새로운 기술에 대한 경쟁 우위 유혹을 받을 수 있다. 명심할 점은 소프트웨어 세계에서의 얼리어답터는 해당 기술의 버그를 찾아주는 선구자 역할을 수행할 수 있다.
소프트웨어 아키텍처의 결과는 유지 관리 및 확장이 쉬운 소프트웨어야 한다. 아키텍트는 담당한 소프트웨어가 성장하도록 설계해야 한다.
아키텍트도 개발자이다. 이 점을 잊으면 안 된다. 대부분 사람들은 아키텍트가 되면 코딩할 필요가 없다고 생각한다. 이것은 매우 위험한 생각이다. 소프트웨어 아키텍트가 된다는 것은 코딩 작업등에 반드시 참여한다는 의미는 아니지만, 설계 및 구현에 대한 부분을 전달하는데 지속적으로 참여해야 함을 의미한다. 코딩에 대한 기반이 없으면 주도하고 나아갈 수 없다.
버그가 많은 제품을 출시하는 경우에는 아키텍트의 역할에 대한 의미가 퇴색된다. 품질에 대한 보증은 아키텍트 역할의 일부로 간주해야 한다. 코딩 표준, 디자인 원칙 및 도구 그리고 프로젝트의 품질을 보장하기 위한 기준선이 필요하다. 아키텍트가 설계한 것이 프로젝트 전반에 일관되게 구현되고 있는지 상시 확인해야 한다. 이런 행위를 아키텍처 원칙 준수라고 한다.
소프트웨어 아키텍트가 되려면 정말 많은 일을 해서 경험을 쌓아야 한다는 사실을 알아야 한다. 어려운 의사 결정을 내리고 책임을 질 준비가 되어 있어야 한다. 가장 중요한 점은 실패하지 않을 제품을 제공할 것을 보장해야 한다.