2018.04.10

글로벌 칼럼 | 마이크로서비스 아키텍처로 전환하면서 저지르는 3가지 실수

Rob Zuber | InfoWorld
필자가 CTO로 있는 회사 서클CI(CircleCI)는 비난 없는 사후 분석, 즉 프로젝트에 대해 논의할 때 감정을 걷어내면 진정한 배움의 경험을 얻게 된다는 신념을 충실히 따르는 기업이다. 마이크로서비스 아키텍처로 마이그레이션한 이후 서클CI는 잘 한 것과 잘못한 것, 다음 번에는 다르게 해보고 싶은 부분에 대해 서로 비난하지 않는 사후 분석을 실시할 좋은 기회를 잡았다. 마이크로서비스로의 전환을 고려 중인 사람을 위해 더욱 원활한 전환을 위한 조언을 해볼까 한다.



서클CI는 2015년 24시간 동안 운영 중단을 겪으면서 모놀리식 아키텍처에서 벗어나는 일을 시급한 과제로 추진했다. 다만 마이크로서비스로 전면적으로 전환할 때 잘못된 의사 결정으로 인해 발생한 여러 가지 사례를 알고 있었으므로 신중을 기했다. 반면 증분적인 아키텍처 변경으로는 우리에게 필요한 변혁을 실현할 수 없었다.

아키텍처를 해체하면서 초기 몇 가지 성과를 거두자 이것이 올바른 방향임을 확신했고 모두 걸기로 결정했다. 그리고 얼마 지나지 않아 덜컹거리기 시작했다. 엔지니어링 생산성이 곤두박질쳤다. 직원들을 익숙하지 않은 환경으로 내몰고 있음을 인식했다. 이들에게 모놀리식 아키텍처가 작고 편안한 마을이었다면, 마이크로서비스는 미지의 대도시였다.

사후 분석에서 마이크로서비스 마이그레이션을 거치며 겪은 마찰의 원인을 주제로 대화를 나눴고 이를 해결할 방법을 고안했다.

1. 의사 결정
너무 복잡해서 모든 옵션을 고려하느라 아무것도 실행하지 못한 채 오랜 시간을 소비해야 하는 의사 결정은 “분석 장애”에 직면하게 된다. 해결책은 어려운 의사 결정을 조기에 진행해서 앞으로의 의사 결정은 예외에 한해 하는 것으로 줄이는 것이다. 초기 의사 결정이 실패한 경우에만 다른 방향을 선택해야 한다.

서클CI에서는 엔지니어들에게 우리 회사는 클로저(Clojure) 회사임을 명확히 전달했다. 다른 언어나 스택은 선택 가능한 옵션이 아니다. 모두가 클로저를 잘 알고, 클로저를 통해 지금까지 좋은 결과를 얻었다.

gRPC, 포스트그레SQL, 도커, 쿠버네티스를 사용하기로 결정하면서 우리는 프로젝트에 사용할 공통 스택에 합의했다고 생각했지만, 이러한 의사 결정이 가진 의미는 우리가 예상했던 것보다 더 복잡한 것으로 드러났다. 클로저의 버전은? 라이브러리는?

중요한 의사 결정을 미리 내렸다고 생각했지만, 앞으로 닥칠 의사 결정의 깊이에 대해서는 전혀 예상하지 못했다. 그래서 무엇을 배웠는가? 더 많은 시간을 투자해 사전에 지침을 만드는 방법도 있겠지만 애자일 세계에서 효과적인 시간 투자 방법은 아니다. 필요한 것은 어떻게 의사 결정을 내리고 누가 그 결정을 내리며 이러한 의사 결정을 나머지 팀원들과 어떻게 효율적으로 공유할 것인지에 대한 매우 명확한 정의다. 처음부터 모든 의사 결정을 예상할 수는 없으므로 예상치 못한 상황을 매끄럽게 처리할 수 있는 명확한 규약을 마련해야 한다.

2. 새로움
엔지니어는 새로운 것을 좋아한다. 그 이유가 이전 것으로는 문제를 만족스럽게 해결하지 못한 데 있다면 새로운 해결책을 물색하는 것이 타당하다. 그러나 경우에 따라서는 마이크로서비스 프로젝트에서 이전 것이 적절한 선택일 수도 있다. 마이크로서비스로의 전환은 그 자체로 큰 변화이므로 부가적인 변화를 제한하는 것은 현명한 전략이다.

서클CI는 2011년부터 몽고DB(MongoDB)를 사용했다. 그만큼 몽고DB의 좋은 점도, 나쁜 점도 잘 안다. 그러나 마이크로서비스로 전환할 당시 우리는 많은 직원들이 선호하는 포스트그레SQL로 돌아갈 좋은 기회라고 생각했다. 나중에 보니 처음 생각했던 것만큼 직원들이 포스트그레SQL에 대해 깊이 알지는 못했고 결과적으로 마찰과 새로움이 줄어들지 않고 오히려 늘었다.

전적으로 새로움을 이유로(또는 습관을 이유로) 사용되는 툴과 시스템을 확인하려면 팀원간 의사소통을 강화해야 한다. 더 광범위한 사용을 위해(그리고 단순히 새롭다는 것보다 더 타당한 이유로) 각 툴을 구현할 방법을 파악하는 데 시간을 투자해야 한다. 모든 직원이 독립적으로 문제를 해결하려 시도하면서 서로 똑 같은 문제에 직면하는 상황은 피하는 것이 좋다. 공통된 툴로 전환하면 모두가 더 빠르게 움직일 수 있다.

3. 반복
새로움과 마찬가지로 반복은 제대로 해결하지 않으면 마이크로서비스 계획의 진척을 지지부진하게 하는 문제다. 필자 회사의 경우 3명의 엔지니어가 각각 gRPC 통신 프레임워크를 처리하기 위한 자기만의 라이브러리를 작성했다. 엔지니어 두 명 분의 시간이 낭비된 셈이다.

우리가 얻은 교훈은 인프라와 관련된 부분에서 공유 구성 요소를 사용할 수 있다는 점이다. 마이크로서비스의 가치는 이를 통해 드러나는 자율성에 있지만, 자율성과 함께 오버헤드도 증가한다. 핵심은 공유 구성 요소를 통해 창출되는 가치가 오버헤드를 넘어서는 영역을 찾는 것이다. 다만 그러한 타협을 개별 팀에 맡겨서는 안 된다. 반드시 그 일을 전담하는 책임자를 둬서 그 책임자가 팀에 대한 전체적인 혜택을 평가할 수 있도록 해야 한다. 다른 팀의 요구 사항을 해결하지 못하는 공유 구성 요소는 결국 공유 구성 요소로 사용되지 못하기 때문이다.

서클CI의 경우 전문 영역을 중심으로 구성된 크로스팀 그룹인 길드를 만들었다(길드 구성에는 스포티파이 모델 사용). 예를 들어 사이트 안정성 엔지니어링(SRE) 길드는 누구나 참석할 수 있는 주별 회의를 연다. 사람들이 같은 문제(가령 gRPC 라이브러리 또는 데이터베이스 연결)를 해결하기 위해 작업할 때 그 작업을 중앙집중화할 수 있다.

초기 출범 이후 1년 이상이 지난 지금 서클CI는 마이크로서비스의 효과를 체감하고 있다. 이전 플랫폼에 비해 사용률이 5배 더 높고 예전의 운영 문제(느린 빌드, 시스템 중단 등)는 대부분 사라졌다. 우리가 성공한 이유는 이 프로젝트가 고객에게 가치를 제공하는 제품이 아닌 엔지니어링에 대한 투자임을 인식한 데 있다.

시작하기 전에 많은 의사 결정과 투자를 해야 하므로 아키텍처를 마이크로서비스로 해체할 때 이 점에 대해 동의를 얻는 것이 중요하다. 단편적인 접근 방법을 택한다면 그 과정에서 많은 재작업에 직면하게 된다는 점을 알아야 한다. 마이크로서비스를 향한 첫 작은 걸음을 떼기 전에 이 투자에 대해 건전한 대화를 나누는 것이 중요하다.  editor@itworld.co.kr


2018.04.10

글로벌 칼럼 | 마이크로서비스 아키텍처로 전환하면서 저지르는 3가지 실수

Rob Zuber | InfoWorld
필자가 CTO로 있는 회사 서클CI(CircleCI)는 비난 없는 사후 분석, 즉 프로젝트에 대해 논의할 때 감정을 걷어내면 진정한 배움의 경험을 얻게 된다는 신념을 충실히 따르는 기업이다. 마이크로서비스 아키텍처로 마이그레이션한 이후 서클CI는 잘 한 것과 잘못한 것, 다음 번에는 다르게 해보고 싶은 부분에 대해 서로 비난하지 않는 사후 분석을 실시할 좋은 기회를 잡았다. 마이크로서비스로의 전환을 고려 중인 사람을 위해 더욱 원활한 전환을 위한 조언을 해볼까 한다.



서클CI는 2015년 24시간 동안 운영 중단을 겪으면서 모놀리식 아키텍처에서 벗어나는 일을 시급한 과제로 추진했다. 다만 마이크로서비스로 전면적으로 전환할 때 잘못된 의사 결정으로 인해 발생한 여러 가지 사례를 알고 있었으므로 신중을 기했다. 반면 증분적인 아키텍처 변경으로는 우리에게 필요한 변혁을 실현할 수 없었다.

아키텍처를 해체하면서 초기 몇 가지 성과를 거두자 이것이 올바른 방향임을 확신했고 모두 걸기로 결정했다. 그리고 얼마 지나지 않아 덜컹거리기 시작했다. 엔지니어링 생산성이 곤두박질쳤다. 직원들을 익숙하지 않은 환경으로 내몰고 있음을 인식했다. 이들에게 모놀리식 아키텍처가 작고 편안한 마을이었다면, 마이크로서비스는 미지의 대도시였다.

사후 분석에서 마이크로서비스 마이그레이션을 거치며 겪은 마찰의 원인을 주제로 대화를 나눴고 이를 해결할 방법을 고안했다.

1. 의사 결정
너무 복잡해서 모든 옵션을 고려하느라 아무것도 실행하지 못한 채 오랜 시간을 소비해야 하는 의사 결정은 “분석 장애”에 직면하게 된다. 해결책은 어려운 의사 결정을 조기에 진행해서 앞으로의 의사 결정은 예외에 한해 하는 것으로 줄이는 것이다. 초기 의사 결정이 실패한 경우에만 다른 방향을 선택해야 한다.

서클CI에서는 엔지니어들에게 우리 회사는 클로저(Clojure) 회사임을 명확히 전달했다. 다른 언어나 스택은 선택 가능한 옵션이 아니다. 모두가 클로저를 잘 알고, 클로저를 통해 지금까지 좋은 결과를 얻었다.

gRPC, 포스트그레SQL, 도커, 쿠버네티스를 사용하기로 결정하면서 우리는 프로젝트에 사용할 공통 스택에 합의했다고 생각했지만, 이러한 의사 결정이 가진 의미는 우리가 예상했던 것보다 더 복잡한 것으로 드러났다. 클로저의 버전은? 라이브러리는?

중요한 의사 결정을 미리 내렸다고 생각했지만, 앞으로 닥칠 의사 결정의 깊이에 대해서는 전혀 예상하지 못했다. 그래서 무엇을 배웠는가? 더 많은 시간을 투자해 사전에 지침을 만드는 방법도 있겠지만 애자일 세계에서 효과적인 시간 투자 방법은 아니다. 필요한 것은 어떻게 의사 결정을 내리고 누가 그 결정을 내리며 이러한 의사 결정을 나머지 팀원들과 어떻게 효율적으로 공유할 것인지에 대한 매우 명확한 정의다. 처음부터 모든 의사 결정을 예상할 수는 없으므로 예상치 못한 상황을 매끄럽게 처리할 수 있는 명확한 규약을 마련해야 한다.

2. 새로움
엔지니어는 새로운 것을 좋아한다. 그 이유가 이전 것으로는 문제를 만족스럽게 해결하지 못한 데 있다면 새로운 해결책을 물색하는 것이 타당하다. 그러나 경우에 따라서는 마이크로서비스 프로젝트에서 이전 것이 적절한 선택일 수도 있다. 마이크로서비스로의 전환은 그 자체로 큰 변화이므로 부가적인 변화를 제한하는 것은 현명한 전략이다.

서클CI는 2011년부터 몽고DB(MongoDB)를 사용했다. 그만큼 몽고DB의 좋은 점도, 나쁜 점도 잘 안다. 그러나 마이크로서비스로 전환할 당시 우리는 많은 직원들이 선호하는 포스트그레SQL로 돌아갈 좋은 기회라고 생각했다. 나중에 보니 처음 생각했던 것만큼 직원들이 포스트그레SQL에 대해 깊이 알지는 못했고 결과적으로 마찰과 새로움이 줄어들지 않고 오히려 늘었다.

전적으로 새로움을 이유로(또는 습관을 이유로) 사용되는 툴과 시스템을 확인하려면 팀원간 의사소통을 강화해야 한다. 더 광범위한 사용을 위해(그리고 단순히 새롭다는 것보다 더 타당한 이유로) 각 툴을 구현할 방법을 파악하는 데 시간을 투자해야 한다. 모든 직원이 독립적으로 문제를 해결하려 시도하면서 서로 똑 같은 문제에 직면하는 상황은 피하는 것이 좋다. 공통된 툴로 전환하면 모두가 더 빠르게 움직일 수 있다.

3. 반복
새로움과 마찬가지로 반복은 제대로 해결하지 않으면 마이크로서비스 계획의 진척을 지지부진하게 하는 문제다. 필자 회사의 경우 3명의 엔지니어가 각각 gRPC 통신 프레임워크를 처리하기 위한 자기만의 라이브러리를 작성했다. 엔지니어 두 명 분의 시간이 낭비된 셈이다.

우리가 얻은 교훈은 인프라와 관련된 부분에서 공유 구성 요소를 사용할 수 있다는 점이다. 마이크로서비스의 가치는 이를 통해 드러나는 자율성에 있지만, 자율성과 함께 오버헤드도 증가한다. 핵심은 공유 구성 요소를 통해 창출되는 가치가 오버헤드를 넘어서는 영역을 찾는 것이다. 다만 그러한 타협을 개별 팀에 맡겨서는 안 된다. 반드시 그 일을 전담하는 책임자를 둬서 그 책임자가 팀에 대한 전체적인 혜택을 평가할 수 있도록 해야 한다. 다른 팀의 요구 사항을 해결하지 못하는 공유 구성 요소는 결국 공유 구성 요소로 사용되지 못하기 때문이다.

서클CI의 경우 전문 영역을 중심으로 구성된 크로스팀 그룹인 길드를 만들었다(길드 구성에는 스포티파이 모델 사용). 예를 들어 사이트 안정성 엔지니어링(SRE) 길드는 누구나 참석할 수 있는 주별 회의를 연다. 사람들이 같은 문제(가령 gRPC 라이브러리 또는 데이터베이스 연결)를 해결하기 위해 작업할 때 그 작업을 중앙집중화할 수 있다.

초기 출범 이후 1년 이상이 지난 지금 서클CI는 마이크로서비스의 효과를 체감하고 있다. 이전 플랫폼에 비해 사용률이 5배 더 높고 예전의 운영 문제(느린 빌드, 시스템 중단 등)는 대부분 사라졌다. 우리가 성공한 이유는 이 프로젝트가 고객에게 가치를 제공하는 제품이 아닌 엔지니어링에 대한 투자임을 인식한 데 있다.

시작하기 전에 많은 의사 결정과 투자를 해야 하므로 아키텍처를 마이크로서비스로 해체할 때 이 점에 대해 동의를 얻는 것이 중요하다. 단편적인 접근 방법을 택한다면 그 과정에서 많은 재작업에 직면하게 된다는 점을 알아야 한다. 마이크로서비스를 향한 첫 작은 걸음을 떼기 전에 이 투자에 대해 건전한 대화를 나누는 것이 중요하다.  editor@itworld.co.kr


X