Culture

우리 스쿼드에서 같이 일하실래요?

올리브영에서 스쿼드로 일하기

2025.07.30

반갑습니다! 오늘도 올리브영입니다!

반갑습니다! 올리브영 백엔드 개발자 유롱롱입니다! 🐶

개발 조직의 스쿼드 운영 방식, 어떻게 돌아가나요?

요즘 개발 조직에서는 빠르게 변화하는 요구에 유연하게 대응하기 위해 다양한 방식의 조직 구조를 도입하고 있습니다.

그 중 하나가 바로 '스쿼드(Squad)'라는 형태입니다.

이번 글에서는 스쿼드란 무엇인지부터 업무를 실제로 어떻게 운영하는지까지, 올리브영의 일하는 방식을 정리해보려 합니다.

1. 스쿼드란 무엇인가요?

스쿼드는 다양한 역할의 팀원이 모여 하나의 기능이나 서비스를 중심으로 자율적으로 운영되는 작은 단위 조직입니다.

기획자, 디자이너, 프론트엔드/백엔드 개발자, QA 등이 모두 한 팀 안에 포함되어 있어 빠른 의사결정과 협업이 가능하죠.

이 개념을 쉽게 게임에 빗대어 보자면, 하나의 게임 파티와 유사합니다.

파티는 보통 특정 레이드를 공략하거나 목표를 위해 각기 다른 직업의 캐릭터들이 모여 협력합니다.

전사, 힐러, 마법사처럼 역할은 다르지만, 같은 목표를 향해 함께 움직입니다. 스쿼드도 마찬가지입니다.

📌 예시 그림 설명:

스쿼드 이해하기

2. 기능 조직 vs 목적 조직

전통적인 개발 조직은 기능 조직(Function-based)입니다. (예: 프론트엔드 팀, 백엔드 팀, QA 팀.)

스쿼드는 목적 조직(Purpose-based)이며, 하나의 기능을 중심으로 다양한 역할이 모여 있는 형태입니다.

구분	기능 조직	목적 조직(스쿼드)
구성 기준	기술/역할 기반	목적/기능 기반
커뮤니케이션	팀 간 협업 필요	팀 내 협업으로 신속함
장점	기술 전문성 강화	빠른 실행, 책임 분산
단점	병목/지연 발생 가능	기술 중복/일관성 문제 가능

3. MSA와 스쿼드 운영, 왜 잘 어울릴까요?

올리브영은 지금 MSA(마이크로서비스 아키텍처) 라는 구조로 서비스를 만들고 있습니다.

이 방식은 서비스 하나를 여러 개의 작고 독립적인 단위로 나누어 관리하는 구조로, 빠르게 바뀌는 시장에 잘 대응할 수 있는 장점이 있습니다.

여기에 스쿼드(Squad) 조직을 더하면 더 큰 효과를 낼 수 있습니다.

MSA와 스쿼드는 아주 잘 맞는 조합입니다

올리브영은 이미 MSA 구조를 쓰고 있기 때문에, 스쿼드 운영 방식은 자연스럽게 어울립니다.

각각의 스쿼드가 하나의 마이크로서비스를 맡아서 책임지고 운영할 수 있기 때문입니다.

이렇게 되면 좋은 점이 많습니다

빠르게 일할 수 있어요 : 각 스쿼드가 독립적으로 일하고, 직접 배포도 할 수 있어서 속도가 빨라집니다.
자율성이 커져요 : 스쿼드가 자기 서비스에 필요한 기술이나 도구를 자유롭게 선택할 수 있어, 더 효율적으로 일할 수 있습니다.
책임이 명확해요 : 어떤 서비스에 문제가 생기면 누가 담당인지 명확하니, 빠르게 대응할 수 있습니다.

단점도 있지만, 해결할 수 있어요

물론 단점도 있어요. 스쿼드마다 사용하는 기술이나 방식이 다르면 추후 관리가 어려울 수 있습니다.

상품 조회 기능을 구현하는 경우를 예로 들어볼게요.

A팀은 빠른 응답 속도를 위해 Redis 캐시를 적극적으로 활용하고, 일부 데이터는 메모리에도 상주시키는 구조로 만들었습니다.

반면 B팀은 실시간성을 중요하게 여겨, 상품 정보를 매 요청마다 데이터베이스에서 직접 조회하도록 구현했습니다.

“상품 조회”라는 같은 기능임에도 두 팀의 구현 방식이 다르다 보니, 사용자 경험이나 성능 면에서 차이가 발생할 수 있습니다. 다시 말해, 통합적으로 성능 개선이나 공통 API 설계가 필요할 때 큰 어려움이 생길 수 있죠.

하지만 이런 문제는 공통 가이드라인이나 기술 리뷰 등을 통해 충분히 조정할 수 있습니다. 자율성을 유지하면서도 기본적인 원칙은 함께 지키는 것이 중요합니다.

📌 예시 그림 설명:

[MSA와 스쿼드 연결도]
┌──────────────┐
│  스쿼드 A     │ → 마이크로서비스 A
├──────────────┤
│  스쿼드 B     │ → 마이크로서비스 B
├──────────────┤
│  스쿼드 C     │ → 마이크로서비스 C
└──────────────┘
→ 각 서비스는 API, 배포까지 독립적으로 운영

4. 2주 스프린트 & Jira로 스토리포인트 산정

스쿼드는 보통 2주 단위의 스프린트로 업무를 계획하고 실행합니다.

이 방식은 정해진 시간 안에 해야 할 일을 명확히 정리하고, 팀원 모두가 같은 목표를 바라보며 일할 수 있게 도와줍니다. 업무는 각각 예상되는 작업량과 난이도를 기준으로 스토리 포인트(Story Point) 를 부여해 관리합니다.

올리브영에서는 각 스쿼드마다 기준이 있는데 제가 소속되어있는 스쿼드는 다음과 같은 기준을 사용하고 있습니다:

기준: 1포인트 = 1일 작업량 (1명이 하루 동안 할 수 있는 일)
도구: Jira

📌 예시 그림 설명:

[Jira에서 스프린트 구성]
┌────────────────────────────┐
│ Sprint: 2025-07-01 ~ 07-14 │
├────────────────────────────┤
│ ▢ [3pt] 로그인 API 리팩터링    │
│ ▢ [2pt] UI 오류 수정         │
│ ▢ [5pt] 새로운 결제 모듈       │
└────────────────────────────┘
→ 총 10포인트 = 10일 분량

이렇게 하면 좋은 이유

일정 예측이 쉬워요 : 각 스프린트가 10포인트라면, 2주 동안 어느 정도 양의 일을 할 수 있는지 감이 생깁니다.
업무 우선순위가 명확해요 : 중요한 일부터 포인트를 할당하고 계획하므로, 어디에 집중해야 할지가 분명해집니다.
업무 부담 조절이 쉬워요 : 지나치게 많은 업무가 쌓이지 않도록 조정할 수 있습니다.

각 업무 항목에 포인트를 미리 정해두면, 스프린트가 끝날 때 실제 진행 상황과 비교하여 예측 정확도를 점검할 수도 있습니다.

이를 바탕으로 다음 스프린트 계획이 더 정교해집니다.

5. 회고 → 플래닝: 돌아보고, 다음을 준비하기

스프린트가 끝나면 팀은 회고(Retrospective) 시간을 가집니다.

이 시간은 지난 2주 동안 어떤 점이 잘 됐고, 어떤 점은 개선이 필요했는지를 함께 돌아보는 중요한 과정입니다.

하지만 회고가 아쉬운 점 중심으로만 흐르면, 팀 분위기가 무거워질 수 있습니다.

그래서 올리브영에서 저의 스쿼드는 긍정적인 피드백과 개선점이 균형 있게 나올 수 있도록 다음과 같은 방식을 사용합니다:
“좋았던 점 하나 + 아쉬운 점 하나”를 함께 말하기

모든 팀원이 돌아가며 각자 한 가지씩
자연스럽게 서로를 격려하고
놓치기 쉬운 피드백까지 챙기고

회고를 통해 얻은 인사이트는 곧바로 다음 단계인 플래닝(Planning) 으로 이어집니다.

플래닝에서는 다음 스프린트 동안 어떤 일을 할지 정리하고, 스프린트 목표와 우선순위를 명확히 합니다.

이 과정을 통해 팀은 매 스프린트마다 작게라도 더 나아지고, 협업 방식도 지속적으로 개선해 나갈 수 있습니다.

스쿼드 운영 방식은 자율성과 책임, 빠른 실행력과 피드백 사이의 균형을 잘 유지해야 효과를 발휘합니다.

단순히 팀을 나누는 것 이상의 조직 문화와 협업 방식이 필요하기 때문에, 그 안에서의 경험과 학습이 굉장히 중요합니다.

혹시 스쿼드를 운영 중이거나 준비하고 계시다면, 이 글이 조금이나마 도움이 되었으면 좋겠습니다! 🚀

🙏

유롱롱 |

Back-end Engineer

모두 다 개발하고 싶은 개발자입니다.