늦었지만 써보는 2023 인프콘 후기 정리 - 2. 조직구조와 마이크로 서비스 아키텍처 도입

인프콘 후기 정리 이전 포스트에 이어서 두 번째 포스트입니다.

늦었지만 써보는 2023 인프콘 후기 정리 - 1. API First Design

빠르게 핵심 내용으로 가보도록 하겠습니다.

 

참고 : 아래 링크에서 동영상도 볼 수 있습니다.

 

절반의 성공, 조직 구조와 마이크로 서비스 아키텍처 도입  - 서주은님

처음에는 사내에 아래와 같이 각 역할에 따라 팀을 나누었었는데 처음에는 모든 회사들에서 그렇듯 펑션 조직을 생각했다고 합니다.

조직 구조의 변화

조직 규모가 커지면서 조금 더 Scalable한 팀 구조를 만들 필요를 느꼈다고 합니다.

 

그래서 스포티파이의 매트릭스 조직구조를 참고해서 해보려고 했다고 합니다. (스포티파이의 스쿼드)

매트릭스 조직

한명의 Product Manager (PM)을 두고 각 팀에 다양한 직군의 사람들이 하나의 미션을 가지고 업무를 진행하게 되는것이죠.

이런 방식으로 했을때 여러 직군간의 서로 업무에 대한 공유가 잘 된다는 점이 있죠.

 

반면, 단점으로는 

1. 개인이 여러 조직에 속할 수 있 여러 목표가 생겨 어떤 우선순위로 업무를 진행해야할지 혼란이 있다는 점

2. 엔지니어 리드가 없어진다는 점

을 들었습니다.

 

그래서 목적 조직이라는 것을 만들었다고 합니다.

PM과 EM 1명씩 두고 있는 조직 구조

목적조직에는 한명의 PM과 Engineering Manager (EM)을 두게되었다고 합니다.

 

어려운 점은 EM중에서도 Backend에 전공인 사람이 있고, Frontend에 전공인 사람이 있다는점

그럼에도 불구하고 제품팀의 다른 기술스택의 사람들까지 매니지를 해야했다는 단점이 있지만

제품팀이 하나의 목적으로 일하기 때문에 제품을 만드는데는 유리하다고 생각했다고 합니다.

 

이런 조직구조를 통해서 목표와 자율성을 지킬 수 있다고 합니다.

 

그리고 스포티파이의 예시를 봤을때 팀 간의 종속성을 최소화 하는 방향으로 일을 하는것을 보고 이런게 중요하다고 생각하게 되었다고 합니다.

 

그리고 팀 구성과 관련된 책중에 아래와 같은 내용을 가져와서 설명해주셨습니다.

팀 토폴로지 - 팀의 4가지 타입

Stream-aligned Team : 위의 제품팀과 같다고 생각하면 된다고 합니다. (책에서 권장하는 팀 방식)

Enabling team : Stream-aligned Team이 문제를 해결하는데 있어서 장애가 되는점을 해결할 수 있도록 도와주는 팀이라고 합니다.

Complicated Subsystem Team : 높은 수준의 지식을 다루는 팀 (e.g. 머신러닝을 다루는 팀)

Platform : Stream-aligned Team이 목적을 달성하는데 도구를 잘 제공해주는 팀

 

마이크로 서비스 아키텍처 도입

MSA를 도입한 서비스는 아래와 같은 서비스였습니다.

앱에서 광고를 보여주고 리워드 기능을 제공해주는 서비스인데

앱 자체를 쓸수도 있고 SDK를 통해서 개발할수도 있는 서비스였습니다.

 

MSA의 특징 중 강조 할 점

1. 독립적으로 배포 가능

2. 데이터베이스를 공유하지 않는다.

는 특징을 들 수 있다고 합니다.

 

MSA의 장점과 단점

MSA의 장단점

 

MSA의 도입이 왜 절반의 성공이었는지?

위와 같이 서비스를 너무 잘게 나눠서 개발자의 숫자에 비해서 서비스 숫자가 너무 많았다는점이 있었다고 합니다.

 

그래서 이런 고민들을 하면서 MSA를 도입하는데 어떤 배움이 있었는지 아래와 같이 정리를 해주셨습니다.

 

배움 1. 너무 마이크로하게 서비스를 나누지 않는다.

장점도 있기는 한데, 너무 과하게 나누면 비효율적이라고 생각이 들었다고 합니다.

 

배움 2. 서비스 하나를 운영하는데 심리적 부담감은 생각보다 높다.

같은 일을 하는것이긴한데, 서비스 갯수 숫자가 많으면 더 많은 부담을 느끼게 된다고 합니다.

 

배움3. 서비스는 비즈니스 목적에 따라 나누는 것이 좋다.

 

 

배움 4. 서비스화 대신 라이브러리화 한다.

서비스로 만들기 전에 라이브러리화를 먼저 고민해보라고 합니다.

1. 재사용도 잘되고

2. 서비스 운영에 대한 고민을 할 필요가 없고

3. 특히 DB가 없는 서비스는 더 장점이 크기 때문입니다.

 

배움 5. 만들어둔 플랫폼 서비스는 관리하지 않으면 사용되지 않는다.

API 문서가 관리가 안되면 누구도 쓰기 힘들기 때문입니다.

 

배움 6. 진짜 중복과 거짓된 중복을 구분해야한다.

거짓된 중복이라 함은

코드가 각자의 경로로 각자 다른 속도로 변경된다면 두개는 진짜 중복이 아니라고 합니다.

 

예시로 하루에 5천만건 적립되는 리워드 서비스를 들면

1. 90%는 노출형 광고 (누르면 지급)

2. 10%는 액션형 광고 (회원가입시 지급)

위의 2개의 광고 리워드 서비스가 하나의 동일한 서비스가 아니라 분리되어서 개발된다면 인프라 관점에서도 장점이 있을것 같다고 합니다.

 

배움 7. 서비스의 경계를 처음부터 잘 정하기는 힘들다.

예시로 처음에는 광고서버와 리워드를 분리해야할 것 같아서 분리를 했었는데

나중에 알고보니 광고서버와 리워드 서버를 분리하는게 잘못되었다는 점이 있었다고 합니다. (광고 정보가 리워드에서 필요했다고 합니다.)

 

배움 8. 팀과 서비스의 경계는 완벽하게 일치하지 않음.

여러 팀이 공통적으로 쓰고 있는 서비스가 있을 수 있다고 합니다.

왜냐면 하나의 서비스에 대해 다른 팀이 코드를 수정하고 싶을 수 있다는 점이 있습니다.

 

배움 9. 마이크로 서비스를 도입한다고 소프트웨어의 본질적인 아키텍처가 개선 되지 않는다.

 

배움 10. Contract test는 생각보다 어렵다.

 

결론 : 서비스를 나누는기준

1. 팀당 1,2개의 서비스

2. 각 팀으로 명확하게 서비스 오너십을 가져갈 수 있다면 나눈다.

3. 다른 제품을 만드는 것이라면 나눈다.

라는 결론을 내릴 수 있었다고 합니다.

 

---

세션을 정리 해 보고 생각나는점을 추가로 좀 적어봤습니다.

세션의 내용과 제 개인적인 경험을 되새기면서 아래와 같이 공감되었던 점과 새로 배운점을 정리했습니다.

 

세션에 대한 개인 정리

크게 공감되었던 점

배움 2. 서비스 하나를 운영하는데 심리적 부담감은 생각보다 높다.

배움 5. 만들어둔 플랫폼 서비스는 관리하지 않으면 사용되지 않는다.

배움 9. 마이크로 서비스를 도입한다고 소프트웨어의 본질적인 아키텍처가 개선 되지 않는다.

등이 있었습니다.

 

2의 경우에는 실제 제 회사에서도 적은 수의 인원이 여러개의 서비스를 유지하고 있다는것 자체를 두려워 하는 것을 본 경험이 있었습니다. 

사실은 어차피 다른 팀은 못하고 우리가 해야하는 일이었는데도 말이죠.

 

그리고 배움 5의 경우에는 어찌보면 당연한 내용일 수 있고, 관리에 대한 비용이 늘어날 가능성도 높을것 같구요.

배움 9는 좀 많이 느끼는데 우리 회사의 경우에는 웹 서비스 정도 까지의 MSA 구조를 채택할 필요가 없음에도 불구하고 뭔가 그런 방향의 개발을 하고 싶어서, 유행인것 같아서 해당 방향을 추구하게 되는 경우가 좀 있었던것 같습니다. (물론 저도 이런 마음이 있었습니다.)

 

결국은 제품에 적합한 아키텍처를 선택해야하는것이지 하고싶은 방법을 선택하는것은 좋지 않다는 점을 다시 되새길 수 있었던 내용이었습니다.

 

새로 배운것

우선은 조직 구조를 고민하는 그 자체인데요.

저는 아직은 주니어 엔지니어라서 이런 부분까지 고민을 해 보지는 않았고, 대기업에 있기때문에 위에서 언급한 펑션 조직 밖에 경험 해 보지 못한 상황이라서 더 새롭게 느껴졌던것 같습니다.

회사가 제품에 도움이 되는 방식의 조직을 꾸리면 좋을것 같다는 생각은 자주하는데, 삼성전자라는 제조업 기반의 회사다 보니 각 반도체 기술 자체가 하나하나가 어렵다보니 펑션 조직으로 개발하지 않으면 안될것 같다는 생각이 들기도 합니다.

제조업 기반에서는 매트릭스 조직이나 목적 조직이 어떤식으로 적용될 수 있을지 고민해 봐도 좋을것 같다는 생각이 들었습니다.

 

그리고 MSA 쪽에서의 배움은 첫번째로 배움 6입니다.

"배움 6. 진짜 중복과 거짓된 중복을 구별해야한다는 것."

이거는 이정도 까지 깊게 생각을 해본적은 없었는데, 비슷한 서비스더라도 코드가 각자의 경로와 주기로 개발이 되면 서비스를 분리하는게 낫다는 점은 새롭게 알게된 포인트였습니다.

"배움 7. 서비스의 경계를 처음부터 잘 정하기는 힘들다" 는 점이 좀 흥미로웠고

"배움 8. 팀과 서비스의 경계는 완벽하게 일치하지 않음" 이것도 제가 MSA의 형태로 개발을 하고 있지 않기에 경험할 수 없는 부분이였어서 웹 서비스에는 이런 부분도 있을 수 있겠구나라는 생각이 들어 흥미로웠습니다.