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를 고려중에 있다. 오픈소스를 채택하려면 내부 역량이 꽤 올라가야 할 것으로 판단된다.

끝으로,

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


2/21/2024

엔지니어는 상품이 아니다.

 

엔지니어는 개발팀의 대다수를 차지하며 Project Manager 혹은 아키텍트보다 더 많이 필요하다. 이런 점으로 인해 많은 사람들은 엔지니어를 상품으로 생각할 수 있다. 그러나 이것은 실수이다.

때때로, 일을 할 때 엔지니어링 리소스를 상호 교환 가능한 것처럼 인지한다. 이것은 잘못된 것이다. 사람들은 서로 다른 기술과 능력을 가지고 있다. 현재 이 일을 하고 있는 A가 그 일을 한다면 적은 노력으로 가능하다. 하지만 다른 사람이 그것을 한다면 끝내지 못할 가능성이 높다.

엔지니어가 상호 교환 가능하고 차별화되지 않는다고 생각할 때, 큰 문제들이 발생할 수 있다. 엔지니어링의 상품화는 채용 문제와 결합되기 때문에 채용에서 문제가 발생 할 수 있다. 함께 일하는 구성원들의 역량이 높아지려면 항상 더 뛰어난 사람을 고용해야 한다는 사실을 깊이 이해하지 못할 수 있다.

  • 고성장 회사라면 최고의 시절에는 그 전에 뽑았던 사람보다 항상 뛰어난 사람들이 채용되어야 한다. 미래에 더 큰 회사를 위한 기반을 지속적으로 구축해야 하기에, 현재를 유지하는 기반보다 더 강력한 기반을 구축해야 한다.
  • 현재 팀을 위해 훌륭한 인재를 채용하는 것외에, 내일의 리더도 키우거나 채용해야 한다. 1년 안에 한 팀을 2개로 나누면 각 팀에는 우수한 엔지니어로 구성된 인력이 필요하다.
  • 최고의 엔지니어는 어떤 관리자와 함게 일하는게 좋은지에 대해 분별력이 뛰어나다. 매우 강력한 엔지니어팀이 없으면 훌륭한 엔지니어나 관리자를 고용할 수 없다. 사람들은 자신보다 더 나은 사람들과 함께 일하고 싶어하기 때문에 언제든지 팀의 수준을 높이거나 품질을 조정할 수 있다.

훌륭한 팀을 구성하고 있다면, 좋은 인재를 고용할 수 있다. 이런 일은 다른 조직에 위임할 수 없다. 엔지니어링팀이 판단해야하기 때문이다. 훌륭한 엔지니어를 조직에 영입할 때 그들을 조립 라인의 투입물처럼 취급하지 않아야 한다. 기술 차이가 존재하지 않는 척하기보다는 기술 차이를 인정해야 한다.

“최고의 복지는 좋은 동료이다.”

12/21/2023

PARA가 삶을 더 편하게 만드는 방법

4개로만 이루어진 폴더 시스템은 개인 및 비즈니스에서 지식을 활용하는데 도움이 된다.

“나쁜 아이디어를 저장하기 위한 좋은 시스템이 없다면, 아마도 좋은 아이디어를 저장할 시스템도 없을 것이다.” - 데이비드 앨런

구글드라이브나, 노션, 옵시디언의 폴더 구조를 PARA로 변경하지 않았다면, 내가 원하는 문서를 찾는데 많은 시간을 소비했을 것이다. 지금은 PARA 방법론 덕분에 내가 원하는 것을 찾는데 조금의 시간만 소요된다.

PARA 방법론으로 지식을 정리하여 몇 초 안에 필요한 모든 것을 찾을 수 있는 방법을 설명하고자 한다.

PARA의 작동 원리

PARA는 매우 유연하며 결과 지향적이고 간단하고 빠르게 구현된다. 폴더 및 카테고리가 존재하는 서비스에서 모두 작동된다. 본 글에서는 Google Drive를 예로 설명한다.

효율성은 동작이 단순해야 한다. 나의 구글 드라이브에는 Projects, Areas, Resources, Archive (=PARA)의 4개의 폴더만 존재한다. 


각 폴더를 단계별로 살펴보면 파일이 어느 폴더에 위치해 있는지 쉽게 이해할 수 있다.

Projects

이 폴더에는 진행 중인 프로젝트가 위치한다. “Projects”에 있는 모든 폴더의 공통점은 명확한 시작 날짜와 종료 날짜이다.

프로젝트 폴더 내부의 각 폴더에는 “Completed”라는 명확한 정의가 있다. 시간순으로 폴더를 유지하려면 각 폴더에 시작 날짜와 종료 날짜로 레이블을 지정한다.

날짜 라벨이 어떻게 생겼는지 아래를 살펴보자.


2023-2024는 시작 날짜와 종료 날짜를 의미한다. 요즘IT에 글을 기고하고 있고, 한국생산성본부랑 작업을 하는 것과 Aalto University에서 EMBA 수업을 듣고 있기에, 시작날짜와 종료날짜를 지정해서 관리한다.

프로젝트가 완료되면 폴더를 Projects에서 Archive로 이동하고 유용한 리소스는 Resources로 추출한다.

Areas

“Areas” 폴더는 Projects와 정반대이다. Areas 폴더에는 미리 정의된 날짜 없이 진행 중인 작업에 대해 레이블을 지정한다. 작업이 반복적으로 발생하기 때문에 “Areas”에 있는 것들은 완료가 되지 않는다.


“Areas” 폴더에는 개인적인 것, giljae.com 포스팅 등 계속 유지해야 하는 것들이 위치한다. “Projects”와 다르게 해당 폴더는 시간 레이블을 설정하지 않는다.

Resources

리소스 폴더는 보물 상자이다. 이 폴더는 단편적으로 제공되는 지식이 함께 모이는 곳이다. 완료된 프로젝트를 Archive로 옮겼던 것을 기억하는가?

폴더를 Archive로 이동하기 전에 프로젝트내의 문서, 이미지 및 기타 자료들을 살펴보고 재사용하고 싶은 유용한 리소스가 있다면, Archive대신 Resources로 이동한다.

리소스내의 폴더는 지속적인 관심을 끄는 것들이 위치된다.

예를 들어서 일반적인 리소스 폴더는 프로젝트 관리, 기술 문서, 기타 재사용 가능한 것들이 위치할 수 있다.

프로젝트 폴더와는 다르게 리소스 내의 폴더에는 시작 날짜와 종료 날짜가 없다. 폴더 이름에 라벨을 붙이는 것은 쉽게 찾기 위함이다. 따라서 폴더는 같은 관심사의 것들이 영역별로 구성된다.

리소스 폴더를 생성하면 깔끔하게 자료를 구성하는 효과를 느끼게 된다. 이 폴더는 지금까지 배우거나 경험한 것들을 명확하게 기록해 놓은 것이다.

Archive

아카이브의 컨셉은 꽤 단순하다. 특정 프로젝트가 완료되고 모든 관련 지식을 리소스 폴더로 필터링 하면 프로젝트 폴더를 아카이브로 이동한다. 이게 전부다.

PARA(Projects, Areas, Resources, Archive)는 지식을 정리하는 강력한 도구이다. 폴더와 파일을 구조화함으로써 지식을 잘 활용하고 과거 학습 내용을 다시 볼 수 있다. 이렇게 관리를 하면 시간과 에너지를 많이 절약해준다.

나는 현재까진 만족하며 PARA를 이용하고 있다. 이 글을 읽는 당신의 삶에 PARA를 적용해봤으면 좋겠다.

12/20/2023

리테일 분야 동향 예측

 한해를 마무리 하면서, 몸담고 있는 리테일 업계의 2024년 동향에 대해서 찾아보고 정리를 해봤다.

1. 옴니채널 판매


옴니채널은 쇼핑 생활에 없어서는 안 될 경험이다. 온라인과 오프라인을 결합하여 소비자가 어떤 상황에서든 원활한 쇼핑 경험을 일관되게 제공해야 한다.

2. 개인화


개인화는 고객 경험을 향상 시킬 뿐만 아니라 더 높은 전환율과 고객 충성도를 유도하므로 사업자와 소비자가 모두 Win-Win 하는 셈이다. 방대한 양의 고객 데이터를 수집하고 처리하는 기술이 발전하고 AI 기술도 발전함에 따라 PX(제품 경험) 전략이 지속적으로 성장할 것으로 예상된다.

3. 소비자에게 직접 판매


소비자에게 직접 판매하는 브랜드의 등장은 리테일 업계에 큰 변화를 가져왔다. 이들 브랜드는 전통적인 채널을 우회하여 소비자에게 직접 다가가고 있다. 이런 방식은 브랜드, 가격 및 고객 데이터를 더 잘 제어할 수 있다. DTC(Direct to Consumer)는 중개자를 제거함으로써 보다 경쟁력 있는 가격으로 고품질 제품을 제공하고 있으며, 이는 현대 소비자에게 잘 어울리는 전략이다.

4. 매장 내 경험


이번에 들었던 Retail Management 수업에서 교수님이 오프라인 매장은 다시 부활 할 것으로 언급했다. 단, 오프라인 매장이 단순 거래를 위한 허브 역할이 아니라 독특한 힙한 경험을 제공하는 영역으로 변모해야 한다고 한다. DIY 워크샵을 주최하거나, 자연 친화적인 아늑한 분위기의 카페, 증강 현실 피팅룸을 제공하는 매장 등 체험형 매장은 단순한 제품 그 이상을 제공하여 쇼핑 자체를 이벤트로 바꾸고 있다.

5. 물류


향상된 배송 및 반품 서비스가 새로운 표준으로 자리 잡고 있다. 당일 배송, 매장 밖 수령, 손쉬운 반품 정책에 대한 기대가 높아지고 있으며 소매업체는 혁신적으로 대응하고 있다. 드론 배송 및 자동 픽업 키오스크와 같은 개념은 더 이상 단순한 아이디어가 아니다. 이는 현실이 되어 제품을 받고 반품하는 방식을 바꾸고 있다.

6. 결제 방법


결제 수단이 다양화되고 있다. 구매 후 결제 서비스부터 암호화폐 수용 및 유연한 결제 옵션으로 소비자 선호도에 부응하고 있다. 이러한 유연성을 통해 소비자는 쇼핑 경험을 즐기면서 재정을 보다 효과적으로 관리할 수 있다.

7. 커뮤니티


커뮤니티 구축은 소매업체가 집중하는 분야이다. 이벤트를 하고 온라인 커뮤니티를 만들어 고객과 브랜드를 서로 연결하고, 공유하고, 참여할 수 있는 공간을 조성하고 있다. 이런 행위는 쇼핑 경험을 풍부하게 할 뿐만 아니라 브랜드 충성도를 높여 고객을 브랜드 옹호자로 변화시킨다.

8. 보안 및 개인정보 보호


데이터 보안과 개인 정보 보호는 디지털 시대에서 매우 중요한 요소이다. 소비자가 본인의 디지털 흔적에 대해서 주의를 기울이게 되면서 개인 정보 보호에 대한 관심도 높아졌다. 보안에 투자하고 투명하게 데이터를 처리하는 것이 소비자에게 신뢰를 얻고 서비스를 유지하기 위한 전제 조건이다.

9. 증강 및 가상현실


증강 현실과 가상 현실의 통합은 디지털 세계와 물리적 세계 사이의 격차를 해소하고 있다. 이러한 기술은 온라인 쇼핑 경험을 향상시키고, 가장 체험 및 대화형 형식을 제공하며 상품 탐색 및 구매 방식에 새로운 경험을 제공하고 있다.

10. 순환경제 수요 증가


환경을 생각해서 폐기물을 최소화하고 자원을 최대한 활용하여 제품과 서비스가 환경에 미치는 영향을 줄이는 것을 목표로 하는 경제 모델인 “순환 경제” 개념은 소비자들에게 인기를 얻고 있다. 업사이클링 또는 재활용 프로그램에 투자하면 탄소 배출량을 줄일 수 있을 뿐만 아니라 새로운 수익원을 창출하고 같은 생각을 가진 소비자들에게 함께 제품을 사고 팔 수 있는 저렴한 시장을 제공할 수 있다.

향후, 소매업은 단순히 제품 판매에만 국한되지 않을 것이다. 경험을 창조하고, 커뮤니티를 구축하고, 쇼핑을 더욱 개인화되고 편리하고 즐겁게 만드는 혁신을 수용할 것이다. 기술 발전과 진화하는 고객의 기대는 소매 환경이 엄청난 속도로 변화될 것을 의미한다.

References

  • https://www.akeneo.com/blog/top-retail-trends-for-2024/
  • https://www.inc.com/inc-masters/10-retail-trends-for-2024.html