8/09/2024

린스타트업

Business Design 수업을 듣고 있다. 2번째 모듈 수업에서는 Lean startup method에 대해서 배우고 있다.

린 스타트업 방법론은 2000년대 초반 Steve Blank가 고객 개발 방법론을 도입하면서 시작되었다. 고객 중심 접근 방식을 강조한 Blank는 스타트업 초기 단계에서 잠재 고객을 참여시키는 행위가 매우 중요하다고 얘기한다.

소비자 중심 접근 방식은 제품을 출시할 때 많이 사용되는 방법이다. 새롭거나 파괴적인 혁신을 창출하는 것이 아니라 소비자가 원하는 것을 제공하고 기존 요구 사항을 충족시키는 것에 더 가깝다고 언급한다.

새로운 제품이나 서비스를 만들때, 과거에는 “우리가 만들면 그들이 사용할 것이다.” 라는 접근 방식으로 리소스를 많이 소비하면서 운영되었다는 점을 Blank는 깨달았다. 그래서 초기 가설을 검증하고 고객 요구에 맞는 제품을 만들 확률을 높이는 것을 목표로 하는 방식을 제안했다.

스타트업은 자금이 고갈되기 전에 결함을 식별하고 빨리 수정하지 않으면 성공할 수 없다. Blank의 아이디어는 Lean Startup 기반을 구축했다.

Eric Ries는 Steve Blank의 아이디어에 큰 영향을 받았다. 그는 스타트업 창업에 대한 새로운 접근 방식을 만들었다. 그가 벤처 투자사에 재직하는 동안 스타트업 컨설팅을 하면서 실무에 적용할 기회를 얻었다. 그리고 이런 경험을 기반으로 “Lean Startup”을 기술했다.

Ries는 “린 스타트업은 빠른 반복과 고객 통찰력, 거대한 비전, 큰 야망을 강조하는 제품 개발을 바라보는 새로운 방식”이라고 얘기한다. 그의 책에서는 스타트업은 극도의 불확실성 속에서 새로운 것을 창조하도록 설계된 기관이라고 언급한다. 벤처를 시작하고 자신이 무엇을 하고 있는지 모른다면 어떤 아이템인지는 의미없다고 한다.

핵심 원칙

스타트업이라는 불확실성이 있는 상황에서는 전체 사업 계획 작성을 생략하는 것이 좋다. 대신 린 스타트업은 사업 계획의 핵심 사항들을 일련의 가설로 나눌 것을 제안한다. 그리고 이런 가설을 과학적으로 테스트할 수 있는 조치를 취하도록 조언한다. 예를 들어서 MVP(Minimal Viable Product)를 만들고 잠재 고객 그룹에게 제공하여 사업 아이템을 검토하는 것이 중요하다.

이런 행위는 가설이 “참”인지 “거짓”인지 밝히기 위한 실험이다. “참”이라면 스타트업은 인내심을 갖고 제품이 빛날때까지 지켜보면 된다. 그러나 “거짓”이라면 “피벗”을 해야 한다.

이것이 린스타트업의 핵심 개념이다. 린 스타트업의 핵심은 “빌드-측정-학습” 에 대한 피드백 루프로 동작된다.

<source: https://productmantra.net/2013/11/09/lean-startup-loop-scattered-versus-progressive-learning/>

스타트업은 아이디어를 제품으로 변환한다. 고객과 상호 작용하면서 정성/정량 관점에서 피드백과 데이터를 수집한다. 스타트업에 만드는 초기 제품은 실험이다. 지속 가능한 비즈니스를 구축하는 것에 대한 학습이다. 빌드부터 측정 그리고 학습까지 마무리되는 루프이다.

학습

가설을 테스트하는 과학적 접근 방식을 ‘검증된 학습”이라고 한다. 비즈니스 가설을 테스트하고, 테스트 결과를 학습하고, 수집된 데이터를 사용하여 의사 결정을 하고 제품을 개선하여 Needs를 충족시키는 민첩한 프로세스로 동작된다. 이런 과정을 통해 가설이 타당한지 아이디어가 가치가 있는지를 알 수 있다. 가능성이 아이디어는 빠르게 실패할 수 있도록 도와준다.

빠른 실패

낭비를 최소화하는 것이 목표인 린스타트업은 “빠른 실패”를 적극 권장한다. 아무도 원하지 않는 제품이나 서비스에 낭비되는 시간과 자원을 줄이는 것이 중요하기 때문이다. 빠르게 실패하면서 배우고, 다시 아이디어를 생각하고, 전환할 수 있는 충분한 시간을 확보할 수 있다.

MVP

MVP(최소 실행 가능 제품)는 “최소한의 노력과 최소한의 개발 시간으로 빌드-측정-학습” 루프를 돌릴 수 있는 개념이다.

최소라는 개념은 유동적이고 상황에 따라 다르다. 관점에 따라 최소로 보이거나 과도하게 보일 수 있기 때문이다. 따라서 최소 표준을 신중하게 정의해야 한다.

MVP는 품질이 낮거나 저렴하게 만드는 것을 의미하지 않는다. 핵심 기능을 제공하는 것을 목표로 두고 가능한 최소 비용으로 개발해야 한다. 그리고 고객 검증 단계로 전환해야 한다.

고객 검증

항상 고객과 함께 기능을 검증하는 린 스타트업의 목표는 효율성과 낭비를 감소하는 것이다. 매우 모순적으로 보일 수 있다. MVP가 준비되면 실제 사용자를 대상으로 테스트를 진행한다.

개발 중인 제품이 시장의 니즈를 만족하는지 판단하고, 자원 소모를 최소화하며, 추가하거나 제거해야 할 기능을 결정하는데 도움을 준다.

피벗

고객 검증 과정이 끝나면, 전략적 가설이 옳았는가? 에 대한 결과를 알 수 있다. 테스트를 통해 긍정적인 면을 확인할 수 있다.

피벗을 통해 스타트업은 계획을 고수하기보다 실 피드백과 데이터를 기반으로 접근 방식을 조정하거나 개선할 수 있다.

위에서 언급한 것들이 린스타트업의 핵심이다. 빌드-측정-학습 루프를 통해 현재 전략을 유지할지 혹은 전환할지를 결정하는 것이다.

한계

“사람들은 제품을 보여주기 전까지는 자신이 원하는 것이 무엇인지 알지 못한다.” 라고 스티브 잡스가 말했다. 이 말에는 많은 의미가 있다. 모든 스타트업이 린 방식을 따른다면 파괴적 혁신이 나올 수 없을지도 모른다.

계획적이지 않다.

린 방식에서는 스타트업 초기에 자세하고 복잡한 사업계획을 수립하는데 너무 많은 시간을 소비하는 것은 역효과를 낳는다고 얘기한다. 어느정도는 동의한다. 그리고 비즈니스 모델 캔버스 사용을 장려한다.

그러나 캔버스가 포착하지 못하는 것들도 존재한다. 그리고 대부분의 사람들은 실패를 예상하면서 행위를 하지 않는다. 그들의 꿈, 비전에 대한 밝은 미래를 상상한다.

린스타트업에서는 계획을 적게 수립하라고 얘기하지만, 다시 해석하면 가설 기반으로 수립하라는 의미이기도 하다.

빠른 실패

MVP 기반으로 제품을 검증하지만, MVP는 최종 제품의 모습을 표현하지 않는다. 그래서 초기 기능 표준을 잘 수립해야 한다. MVP는 매우 유용하다. 하지만, 최종 모습으로 보면 안되고 가설을 검증하는 목적으로 사용되어야 한다.

결론

린스타트업도 전통적인 방법과 비슷하게 시작된다. 시장 조사, 법률 및 규제 준수 조사, 사업 계획 수립등 다만, 린스타트업은 MVP로 시작되기에 기존 방식에서 시간과 리소스를 절약해준다고 볼 수 있다.

고객 검증에 중점을 둔다는 것은 혁신적이고 파괴적으로 이어지지 않지만, 고객 요구에 맞는 제품을 만드는데 도움이 된다. 신속하게 작업하고, 빠르게 가설을 검증하여 고객이 원하는 제품을 만들 가능성이 높아진다.

현재 진행하고 있는 프로젝트도 회사에서 진행한 방식과 다르게 MVP부터 만들어서 진행을 했었다. 베이스가 되는 프로젝트는 전통적인 방식으로 시작되었지만, 2개의 MVP를 sub로 만들었고, main으로 합류를 눈앞에 두고 있다.

비용과 시간을 줄일 수 있었지만, 고객 검증을 위한 피드백 수집부터 반영까지는 보이지 않는 참여 멤버들의 노고가 상당하다는 점을 인지해야 한다. 결국 일은 사람이 하는 것이기에…


7/13/2024

당신은 받는 사람인가요. 아니면, 주는 사람인가요?

 


일반적인 사람들은 세 가지 입장 중 하나를 기본으로 삼으면서 일을 한다.

“받는 사람”, “맞추는 사람” 그리고 “주는 사람”.

받는 사람은 항상 다른 사람보다 자신의 이익을 우선시하고 줄 때는 그 이익을 증진시키려는 의도를 지니고 있다.

맞추는 사람은 상호성을 믿기에 누군가 가려운 곳을 긁어주면, 본인도 그 사람의 등을 긁어준다.

반면에 주는 사람은 다른 사람에 초점을 맞추기 때문에 도와주면 보답할 것이라고 믿는다.

프로젝트를 진행할 때, 이런 입장차가 눈에 보이게 된다. 중요한 것은 문제보다는 태도와 동기이다.

주는 사람과 맞추는 사람은 최상의 결과에 중점을 둔 협업 작업에 적합하다. 반면, 받는 사람은 다른 사람과 협업하지만 자신에게 도움이 되는 경우에만 한다.

주는 사람은 함께 일하는 동료에게 도움이 필요할 때 가장 먼저 자원하여 돕는 사람이 될 가능성이 매우 높다.

주는 사람과 맞추는 사람의 차이점은 맞추는 사람은 호의를 베풀었으니 언젠가는 도움을 받을 것을 기대한다는 점이다.

받는 사람은 도움을 줄 수 있지만 본인이 불리하지 않은 상황에서만 도울 수 있다. 동료를 돕는 것이 자신의 작업이 지연되어 자신에게 부정적인 영향을 끼친다면 돕지 않을 것이다.

프로젝트가 잘 마무리되어 축하할 시점에는 받는 사람은 가능한 한 많은 영광을 얻으려 할 것이다. 주는 사람은 다른 사람의 기여를 감사하게 여기고, 맞추는 사람은 서로 인정을 해줄 것이다.

프로젝트는 서로 직접 일한 적이 없는 사람들이 자주 배치되고 협업한다.

리드의 대부분은 함께 일하는 팀원이 어떤 범주에 속하는지 알 수 없는 입장에서 일을 시작하게 된다. 그리고 어떤 타입인지 파악을 하게된다.

이는 일부 위험을 줄이는데 매우 중요한 것이기에., 리드는 항상 이런 상황을 이해하고 관찰해야 한다.

7/09/2024

DevOps로의 전환을 앞두고

레거시 시스템은 오랫동안 존재해 왔고, 조직은 수년간 이를 사용하였다. 중간중간 어려움은 있었겠지만 익숙해졌다.

대부분 이런 시스템들은 수십년 전에 개발되었으며 현재 상황에 부응하도록 설계되지 않았다. 그 결과 현 시스템을 유지관리하려면 레거시 버전과 OS를 사용해야 했다. 이런 작업들은 현 시대에 개발을 하는 개발팀에게 큰 부담이 될 수 있다.

우선 DevOps에 대해서 모르시는 분도 계실테니, 개념부터 정리한다.

DevOps란 무엇인가?

DevOps는 배포를 더 자주 빈번하게, 신뢰 가능하도록, 시간 소모를 줄이는 것을 목표로 하는 업무의 집합이다. DevOps는 코드 변경과 배포 사이의 시간을 줄여준다.

기존 방식처럼 개발(Dev)팀과 운영(Ops)팀을 나누는 것이 아닌, 팀 간의 경계를 없애기에 이 조직에 소속된 사람은 개발과 운영을 모두 알고 있어야 한다.


기존 방식과 차이점은 라이프사이클을 더 자주 빠르게 진행할 수 있게 해주는 부분에 있다. 더 빠르게 피드백을 받고 더 유연해진다는 장점이 있다.

일반적인 DevOps pipeline을 구현하는 방식은 아래와 같다.

  • 코드는 소스 리포지토리에서 관리된다.
  • 모든 코드 변경 사항은 자동 빌드, 자동 테스트 등과 같은 자동화된 품질 검사와 코드 검토를 통과해야 한다.
  • 다양한 환경에 대한 배포는 자동으로 수행되어야 한다. (수동 또는 로컬에서 수행되지 않음)
  • 환경은 지속적으로 모니터링되며 장애 발생 시 회복성이 뛰어나야하고, 자체 복구 기능을 제공해야 하며, 수동 개입이 필요한 경우 개입할 수 있어야 한다.

이런 업무를 수행하려면 아래와 같은 지식을 지니고 있어야 한다.

  • 애플리케이션 개발
  • 스크립팅
  • 네트워킹
  • CI/CD에 대한 경험 혹은 최소 하나의 플랫폼을 사용할 수 있어야 함
  • 다양한 클라우드 경험

DevOps는 조직내 프로세스의 문화적 변화를 요구한다. 개발자와 IT 운영을 단일 구조로 통합해야 하며, 서로 긴밀하게 협력해야 한다. 거의 모든 것을 자동화되는 DevOps 사고 방식으로 생각을 바꿔야 한다.

DevOps는 개발팀과 운영팀을 결합하여 원활한 소프트웨어 개발 프로세스를 만드는 방법론이다. 이는 계획 및 개발에서 테스트 및 배포까지 전체 라이프사이클을 함께 작업하는 것이다.

현재의 고민

현재 진행하는 프로젝트가 막바지에 다가왔기에, 오픈 이후 운용 모습에 대해서 DevOps를 고려하고 있다. 현재 진행하는 프로젝트는 모든 영역에 대해서 현대화를 하지 않았기에 Batch, 인터페이스 일부는 레거시가 공존하는 구조기에 직면하는 문제들이 존재한다.

내가 경험한 것중 가장 큰 문제는 “마인드셋”을 바꾸는 것이다. 현재 조직은 현대화를 하려고 모인 동료들이기에 큰 문제는 없다. 다만, 기존 시스템을 사용하는 사람들의 마음을 바꾸는게 어렵다는 것을 그동안의 경험으로 많이 느꼈다.

사람들은 레거시 시스템이 비효율적인 부분이 있고, 비즈니스 상황에 맞춰 대응하려고 할때 지연과 비용을 초래함에도 불구하고 변화를 좋아하지 않는다. 이러한 저항은 현재 현상 유지에 대한 집착보다는 미지의 것에 대한 두려움에서 비롯된다고 느껴진다. 그러나 행동하지 않았을 때 비용은 훨씬 더 클 수 있다.

레거시에 어떤 문제가 발생했을때, 문제가 발생한 부분만 들여다보고 해결한다면, 사일로화된 작업 방식일 것이다. 전체적인 관점에서 어떤 해결 방법이 좋을지, 중장기적으로 이 방법이 적절한지 등을 고려해야 한다.

레거시 시스템은 정말 오래된 기술 스택으로 만들어졌다. 현 시점에 관련 개발자를 구하려고 해도 쉽지않다. 아무래도 다들 치킨집 사장을 하고 있을 가능성이 높다. 코드야 그렇다쳐도 그 당시 도입된 솔루션들은 대부분 EOL(End Of Life)된 상황이다. 이런 시스템은 분해하고 리모델링을 하기가 정말 쉽지 않다.

그럼에도

DevOps팀과 레거시 팀 간의 러브스토리를 상상해본다.

DevOps팀이 진행하는 업무는 아마도 레거시팀이 관심을 가지고 지켜볼 것이다. 변화하고 싶은 사람들에게는 매력적이고 설득력 있는 파트너처럼 보일 수 있다.

레거시 팀은 설득이 필요한 완고한 파트너와 비슷하고, 설득이 필요하다. 이런 관점에서 DevOps는 협업과 지속적인 개선이라는 원칙 기반하에 이점을 보여주고 비즈니스의 요구를 충족하는 제품을 만들어 낼 수 있는 방법을 계속 보여줘야 한다.

레거시 시스템과의 결별은 어려울 수 있지만 DevOps의 도움으로 유익한 경험을 제공할 수 있지 않을까? 그래야 레거시 시스템을 현대화하고 개발 프로세스를 개선하는 문화를 만들 수 있을 것이다.

가장 중요한 점은 레거시 시스템의 해체를 두려워하면 안된다.

이제 하나를 현대화 하였으니, DevOps 문화를 만들어가며 언젠가는 남아있는 레거시 시스템에 작별 인사를 하는 날을 상상해본다.

5/18/2024

스포티파이 스쿼드 모델

우연히 스포티파이의 팀 스쿼드 모델 글(https://hybridhacker.email/p/the-spotify-squad-model-explained?ref=dailydev)을 읽게되었다. 예전에 모 회사에서 매킨지 컨설팅을 받아서 진행했던 구조랑 똑같다.

관련해서 내용을 정리한다.

팀 스쿼드는 애자일 개발에 대한 색다른 접근 방식이고 스포티파이에서 대중화한 개념이다.

본 내용에 대해서는 2014년 스포티파이 엔지니어링 블로그에 게시된 비디오에 소개되었다.

이 아이디어는 각 분대가 독립적인 스타트업인 것처럼 각각 자신의 프로젝트를 관리할 자율성을 갖춘 미니 팀을 만드는 것이다.

Squad

스쿼드는 소규모 스타트업 팀과 유사한 가장 기본 단위이다.


스쿼드는 하나의 공통 목표를 가진 임무 중심의 다기능 팀이다. 상호간 의존성을 줄이고 가능한 한 빨리 움직일 수 있는 자율성과 자유를 최대한 제공한다.

스쿼드는 아래의 특징을 가지고 있다.

  • 최적화된 규모: 8명 미만으로 구성되기에 관리가 어렵지 않고 민첩함과 효과적인 협업이 가능한 규모다.
  • 집중된 업무: 각 팀은 명확한 골을 가지고 운영된다.
  • 교차 가능: 팀은 개발, 디자인, 관리, QA 등 다양한 분야의 구성원으로 구성되기에 독립적으로 운영할 수 있다.
  • Agile Practices: 스쿼드는 일반적으로 Scrum과 같은 애자일 방법론을 사용하여 관리하고 유연성과 지속적인 개선을 보장한다.
  • 자율성: 스쿼드는 작업 방식, 사용 기술 및 골을 가장 잘 달성하는 방법을 결정할 자율성을 갖는다.
  • 성과: 각 팀은 업무 결과를 소유하여 탐여 구성원 간의 책임감과 의무감을 함양시킨다.
  • 빠른 실행: 빠른 의사결정과 신속한 업무 실행이 가능하다.

수년에 걸쳐 스포티파이의 팀 수는 지속적으로 증가하였다. 추가로 더 많은 구조가 도입되었다.

Tribe

부족은 동일한 비즈니스 도메인 또는 기능 영역에서 작업하는 팀의 모임이다.

부족의 역할은 자원을 제공하고 분대 간의 협력을 촉진하는 것이다.


부족은 분대 전체의 정렬을 유지하여 각 스쿼드가 독립적으로 작동해도 충돌하거나 표류하지 않도록 돕는다.

프로젝트의 세부 사항을 관리하기보다는 스쿼드가 성공할 수 있는 최상의 환경을 제공하는데 중점을 둔다.

Chapter

부족내에서 유사한 역할을 수행하는 구성원들은 챕터로 그룹화된다. (e.g. 프론트개발자, 백엔드개발자, QA, 관리자 등)

챕터는 스쿼드 전체의 역량 영역을 구성하는 방법이다.


각 챕터에는 특정 분야의 경험이 풍부한 리더가 있으며, 이들은 서로 다른 스쿼드에서 일하더라도 구성원의 성장과 발전을 담당해야 한다.

Guild

길드는 트라이브나 스쿼드 등 소속에 관계없이 회사 내 누구나 가입할 수 있는 집단이다.

길드는 회사 전체에 걸쳐 개발, UX 또는 데이터 분석과 같은 주제를 중심으로 구성된다.


지식, 경험, 툴등에 대한 정보를 공유하고 광범위한 토론을 하는 비공식 커뮤니티이다.

위 구조가 잘 동작이 되려면., 많은 것들이 필요하다.

  • 리더십에 대한 지원
    • 권한 부여: 리더는 팀에게 결정을 내릴 수 있는 권한을 부여하고 그들의 능력에 대한 자신감이 있어야 한다.
    • 투명성: 팀 활동을 조직 목표에 맞게 조정하기 위해 열린 소통 채널이 필요하다.
    • 자율성 지원: 팀이 프로젝트에 대한 소유권을 갖도록 장려하고 책임감을 키워야 한다.
  • 문화
    • 실험 장려: 시행착오를 학습 과정의 일부로 볼 수 있는 환경 조성이 필요하다.
    • 실패에 대한 관점: 실패를 성장과 배움의 기회로 보는 태도를 키워야 한다.
    • 개방적인 소통: 프로세스를 개선하고 문제를 신속하게 해결하기 위해 팀 내 및 팀 간 정기적인 피드백 루프를 장려한다.
  • 성장
    • 지식 공유: 조직 전체에 지식과 기술을 전파하여 집단 능력을 향상 시킨다.
    • 기술 개선: 개인의 성장이 조직의 변화 요구사항에 맞춰지도록 조정
  • 기술 변경 사항
    • 분리된 릴리즈: 각 팀은 독립된 릴리즈 기능을 구현하여 더 빠르고 자주 업데이트
    • 모듈형 아키텍처: 느슨하게 결합된 구조를 채택하여 다른 영역에 영향을 적게 주고 변경할 수 있는 능력을 향상
    • CI/CD: 원활하고 안정적인 코드 통합 및 배포를 보장

스포티파이는 스쿼드 모델을 채택하면서 가장 큰 이점을 팀이 올바른 결정을 내리는데 필요한 정보와 권한을 모두 갖고 있다는 점을 강조한다. 속도와 에너지가 강하다는 이유이다.

하지만, 일부 단점도 존재했다.

  • 자율성에 대한 과도한 의존: 과도한 자율성은 결속력을 약하게 만들고 조직 목표에 어긋나는 결과를 가져올 수 있다.
  • 강력한 리더십에 대한 의존: 이 모델이 올바르게 동작되려면 팀을 세세하게 관리하지 않고도 팀을 효과적으로 안내하고 코칭할 수 있는 리더가 필요하다.
  • 리소스 집약도: 자율적인 다기능 팀을 효과적으로 관리하려면 상당한 리소스가 필요하다.
  • 적용의 어려움: 좋은 모델이지만, 전통적인 회사의 경우 적용이 어려울 수 있다.
  • 혼합된 결과: 일부 조직은 모델의 혜택을 받는 반면 다른 조직은 생산성과 효율성에 영향을 받는다.

해당 모델을 적용하는 방법

스쿼드 모델을 실험을 시작하려면 어떻게 해야 할까?

최소 요건

팀 구조에 대해 생각하기 전에 더 넓은 범위의 팀이나 부서가 몇 가지 최소 요구 사항을 충족해야 한다.

  • 문화적으로 결정을 내리고 자율성을 보장하며 변화에 적응할 준비가 되어 있어야 한다.
  • 팀 내의 리더는 권한을 부여하고 새로운 아이디어에 개방적이어야 한다. 그리고 마이크로매니징을 피해야 한다.
  • 독립적인 서비스 개발 및 배포를 위한 유연한 기술 환경이 준비되어 있어야 한다.

올인은 위험

한번에 이 모델을 도입하는 것은 피하는 것이 좋다. 모든일에 적합하지 않기 때문이다. 전통적인 구조와 공존이 가능하기에 하이브리드 모델로 접근할 수 있다. 전통적인 팀 구조와 프로세스를 유지하면서 신규 프로젝트나 특정 기능을 개발할 경우 팀을 만들 수 있다.

Action Item:

  • 모델 적용으로 이익을 얻을 수 있는 적합한 프로젝트를 선택해야 한다.
  • 프로젝트에 적합한 역량을 갖춘 구성원을 선택해야 한다.

임무 부여

스쿼드 모델의 중요한 개념 중 하나는 모든 스쿼드에는 임무가 있다는 것이다.

스포티파이의 경우 응용 분야가 주된 영역이지만, 스쿼드 임무는 무엇이든 될 수 있다. 예를 들어서 “이 기능을 구현하세요.” “지표를 개선하여 90%에 도달하게 하세요.” “고객 유지율을 향상시키려면 이 부분을 개선하세요.” 와 같은 것들이다.

리더십 관점에서 가장 중요한 것은 사명을 명확히 하는 것이다.

스쿼드 스스로 규칙 설정

모든 스쿼드 팀은 자체 규칙과 프로세스를 설정해야 한다. 그리고 이 규칙을 문서화해야 한다. 작성된 문서는 공유되면서 아래의 효과를 얻는다.

  • 미래 스쿼드는 다른 스쿼드가 한 일에서 영감을 얻을 수 있다.
  • 팀 자체는 프로젝트가 완료된 후 이 문서를 이용하여 회고할 수 있다.

유의 사항

이 모델을 도입하기 전에 아래 사항을 유의해야 한다.

  • 구성원들이 소소한 관리 없이 업무를 스스로 할 수 있어야 한다.
  • 외부 영향을 피해야 한다. 집중력과 자율성을 유지하기 위해 팀 외부의 간섭을 최소화하려고 노력해야 한다. (외부에 있는 사람들은 스쿼드와 같은 목표가 아니다.)
  • 실패에 대비해야 한다. 실패도 학습 과정의 일부이기에 성공을 위해 필요하다는 점을 인식해야 한다.
  • 스쿼드가 최선을 다해 작전을 수행하는데 필요한 모든 정보를 갖고 있어야 한다.

4/18/2024

레딧(Reddit)의 아키텍처 진화의 여정

본 포스팅은 https://blog.bytebytego.com/p/reddits-architecture-the-evolutionary?ref=dailydev 의 글을 읽고 관심 가는 내용만 정리한 글이다.

레딧은 “인터넷 첫 페이지”가 되고자 하는 비전을 가지고 2005년에 설립되었다. 오래 시간동안 세계에서 가장 인기있는 큰 규모의 커뮤니티로 발전했고, 월간 사용자 수가 약 10억명이 넘는 큰 규모의 서비스로 성장했다.

최근 IPO도 성공적으로 진행하였고, 많은 사용자들의 콘텐츠가 성공의 주된 요인이겠지만, 사용자가 증가함에 따라 아키텍처도 진화한 점도 기술적 요인이라 볼 수 있다.

초기

초기 레딧은 Lisp으로 만들어졌다가 2005년 12월 Python으로 재작성되었다.

Lisp도 훌륭한 언어이지만, 사용자층이 많지 않다보니 라이브러리가 부족한 단점이 존재했다. 레딧 창업자 중 한명인 Steve Huffman은 이 문제를 아래와 같이 표현했다.

“우리는 다른 사람들의 어깨위에서 서비스를 구축하고 있는데, 상황이 어렵다. 기댈 어깨가 많지 않다.”

아키텍처의 핵심 구성 요소

아래 그림은 레딧의 상위 아키텍처의 구성 요소를 보여준다.

  1. CDN은 Fatly의 CDN을 진입 대문으로 사용한다.
  2. Frontend은 2009년 초기에는 jQuery를 사용하다가 나중에 Node.js와 Typescript로 전환하였다.
  3. R2는 모놀리스 애플리케이션이다. Python을 이용하여 구축한 모놀리식 애플리케이션이다.

인프라 관점에서 레딧은 2009년에 베어메탈 서버를 없애고 모두 AWS로 이전했다. S3를 사용해서 썸네일을 호스팅하고 로그를 저장했다. 애플리케이션 서버들은 모두 EC2로 전환했다.

현재 우리 레거시 시스템도 비슷한 구조다.

R2

R2는 레딧의 핵심이다. 거대한 모놀리식 애플리케이션이며 아래 그림과 같이 구성되어 있다.


사용자 트래픽을 견디기위해 동일한 애플리케이션을 여러 서버에 배포하여 운영한다.

로드 밸런서는 앞에 위치하여 적절한 애플리케이션에 라우팅 작업을 수행한다.

사용자 투표와 같은 작업은 리소스를 많이 사용하기에 RabbitMQ를 통해 비동기 대기열로 작업한다.

데이터 저장 관점에서는 Postgres를 사용한다. 로드를 줄이기 위해 DB앞에 Memcache를 배치하여 부하를 줄인다.

이런 변화는 기존 아키텍처를 유지 할 수 없다라는 결론에 다다랐다.

Golang 마이크로서비스와 GraphQL

레딧은 2017년에 GraphQL을 도입하는 여정을 시작했다. GraphQL은 클라이언트가 원하는 데이터만 요청할 수 있도록 하는 Spec이다. 각 클라이언트마다 조금씩 다른 데이터를 요청하는 경우에 탁월한 선택이다.

2021년 초에 몇 가지 주요 목표를 가지고 GraphQL로의 전환을 시작했다.

  • 모놀리식 폐기
  • 동시성 향상
  • 유연한 구조

GraphQL Federation은 여러 개의 작은 GraphQL API(하위그래프)를 하나의 커다란 GraphQL API(수퍼그래프)로 결합하는 방법이다. 수퍼 그래프는 클라이언트 애플리케이션이 쿼리를 보내고 응답하는 대문 역할을 수행한다.

수퍼그래프는 클라이언트가 수퍼그래프에 쿼리를 보내면 해당 쿼리를 응답하는데 필요한 데이터가 있는 하위 그래프를 파악한다. 관련 부분을 하위 그래프로 라우팅하고, 응답을 수집하여 결합한 응답을 클라이언트에 전달한다.

2022년 레딧의 GraphQL팀은 Subreddit, Comments와 같은 기능에 몇 가지 새로운 하위 그래프를 추가했다. 전환 단계에서 파이썬 모놀리스와 새로운 Go 하위 그래프가 함께 동작하여 쿼리를 수행한다. 더 많은 기능들이 Go 하위 그래프로 이관됨에따라 모놀리스는 결국 폐기될 수 있다.

아래의 그림은 점진적인 전환을 보여준다.


래딧의 주요 요구사항은 모놀리스에서 새로운 Go 하위 그래프로의 기능 마이그레이션을 점진적으로 처리하는 것이다.

문제가 발생할 경우 모놀리스로 다시 전환할 수 있는 기능을 갖추면서 오류율과 대기 시간을 평가하면서 트래픽을 새로운 곳으로 점점 늘리기를 원했다.

하지만, 불행하게도 GraphQL Federation은 점진적 트래픽 마이그레이션을 지원하는 방법을 제공하지 않는다. 그래서 레딧은 아래와 같이 Blue/Green 하위 그래프 배포를 선택했다.


위 접근 방식에서는 파이썬 모놀리스와 Go 하위 그래프가 스키마의 소유권을 공유하게 된다. 로드 밸런서는 게이트웨이와 하위 그래프 사이에 위치하여 구성에 따라 새로운 하위 그래포 또는 모놀리스로 라우팅한다.

위 설정을 사용하면 모놀리스 또는 새로운 하위 그래프에서 처리하는 트래픽 비율을 제어할 수 있기에 마이그레이션 과정에서 레딧의 안정성이 향상되게 된다.

현재도 레딧은 중단을 최소화하면서 마이그레이션을 계속 진행중이다.

CDC 및 Debezium을 사용한 데이터 복재

처음에는 레딧은 기본 데이터베이스에서 생성된 WAL 세그먼트를 사용하여 데이터 복제를 지원했다. WAL은 커밋되기전 DB에 대한 모든 변경사항을 기록하는 파일이다. 쓰기 작업중 오류가 발생하면 로그에서 변경 사항을 복구할 수 있다.

레딧은 복제본 데이터를 읽을 수 있는 S3에 WAL 파일을 지속적으로 보관했다. 그러나 이 방식에는 문제가 있었다.

  • 일일 스냅샷을 밤에 실행했기에 낮 시간대의 데이터와 불일치가 발생
  • DB의 스키마 변경이 빈번하였기에 스냅샷 생성 및 복제에 문제가 발생
  • 복제 프로세스 취약성 및 백업 실패 발생

데이터 복제 안정성을 높이기 위해 레딧은 Debezium 및 Kafka Connect를 사용하는 CDC(Change Data Capture)을 사용하기로 결정했다.

Debezium은 지연 시간이 짧은 데이터 스트리밍 플랫폼을 제공하는 오픈소스 프로젝트이다.

해당 프로젝트 한국어 설명이 없어서, 작성해서 기여했다. (https://github.com/debezium/debezium/blob/main/README_KO.md)

Postgres에서 행이 추가, 삭제 또는 수정될 때마다 Debezium은 변경사항을 수신하고 Kafka Topic에 Produce한다. Connect는 Topic에서 변경사항을 읽고 대상 테이블을 업데이트한다.

아래는 위에서 설명한 프로세스이다.


Debezium을 이용한 것은 여러 대상 시스템에 실시간 데이터 복제를 가능하게 했기 때문에 큰 변화가 생겼다.

우리도 Modernization 작업 시 CDC를 고려중에 있다. 오픈소스를 채택하려면 내부 역량이 꽤 올라가야 할 것으로 판단된다.

끝으로,

레딧의 아키텍처 여정은 수년에 걸쳐 시장의 변화에 따라 지속적인 발전을 거듭해왔다. 당장은 와닿지 않지만, 사용자가 폭발적으로 증가할 것으로 판단되는 서비스를 운영하고 있다면 레딧처럼 진화를 해야 한다.