[시리즈] 작은 팀이 흔들리지 않고 일하는 법: 스크럼으로 작은 팀이 낭비 없이 일하는 법 — 2주 스프린트 실전 사례 3가지

📖 지난 편 요약: 1편에서는 '누가 무엇을 책임지는가(R&R)'를 RACI로 정리하는 법을 다뤘습니다.
역할이 분명해졌다면, 이제 그 역할들을 가지고 어떻게 함께 일할 것인가가 남습니다. 오늘의 주제입니다.

 

1. 들어가며

 

"우리 애자일하게 갑시다!" 이 말, 한 번쯤 들어보셨을 겁니다.

그런데 많은 경우 이 말은 "그냥 빨리빨리 합시다"라는 뜻으로 쓰입니다. 마감을 당기고, 회의를 늘리고, 야근을 하면서 "이게 애자일이지"라고 생각하죠.

 

결론부터 말하면, 그건 애자일이 아닙니다. 

애자일의 핵심은 속도가 아니라 '낭비를 줄이는 것'입니다.

이번 편에서는 애자일이 진짜 무엇인지, 그리고 그 대표적인 방법인 스크럼(Scrum)을 작은 팀에서 어떻게 쓸지 이야기해 보겠습니다.

 

2. 애자일의 진짜 의미

애자일(Agile)은 2001년 소프트웨어 개발자들이 모여 발표한 '애자일 선언(Agile Manifesto)'에서 시작됐습니다.

지금은 IT를 넘어 마케팅, 기획, 디자인 등 다양한 분야에서 쓰이는 일하는 방식이죠.

 

핵심 아이디어는 이렇습니다. 

"한 번에 완벽하게 만들려 하지 말고, 작게 만들어서 자주 점검하며 고쳐나가자."

 

왜 이렇게 할까요? 우리가 처음 세운 계획은 거의 항상 틀리기 때문입니다.

게임을 6개월 동안 혼자 머릿속 계획대로 만든 뒤에야 "재미가 없네"를 깨닫는 것보다, 2주마다 작은 버전을 만들어 친구들에게 보여주고 "여기가 헷갈려"라는 피드백을 빨리 받는 게 훨씬 낭비가 적습니다.

 

그래서 애자일의 본질은 '빠르게'가 아니라 '낭비 없이 핵심부터, 짧게 만들고 자주 점검하기'입니다.

 

여기서 자주 하는 오해 하나. 애자일은 "계획 없이 일단 하는 것"이 아닙니다.

오히려 우선순위가 낮은 일은 과감히 미루고 가장 중요한 핵심부터 만든다는 점에서, 무엇을 안 할지 정하는 매우 전략적인 방식입니다.

 

3. 스크럼 (Scrum): 애자일을 실제로 굴리는 방법

 

애자일이 '철학'이라면, 그걸 실제로 굴러가게 하는 구체적 방법이 여럿 있습니다.

그중 가장 널리 쓰이는 게 스크럼(Scrum)입니다. (이 밖에 칸반Kanban, XP 등도 있습니다.)

 

스크럼은 일정한 주기로 '계획 → 실행 → 점검'을 반복하는 틀이고, 마켓컬리 같은 국내 IT 기업의 개발팀도 실제로 이 방식으로 일합니다.

 

용어가 영어라 어렵게 느껴지지만, 하나씩 풀어보면 전부 상식적인 개념입니다.

 

A. 스프린트(Sprint) 

 

단어 그대로 '전력 질주 구간'입니다.

목표 하나를 정해두고 짧게 집중하는 기간으로, 보통 2주로 잡습니다.

 

왜 하필 짧게 끊을까요?

기간이 길면 늘어지고, 너무 짧으면 의미 있는 결과가 안 나오기 때문입니다.

 

2주는 '집중을 유지하면서도 손에 잡히는 결과가 나오는 적당한 길이'라 가장 많이 쓰입니다.

스프린트 동안엔 다른 일은 잠시 미루고 정한 목표에만 집중하는 게 핵심입니다.

 

B. 백로그(Backlog)

 

'아직 처리 안 한 일들의 대기 목록'입니다. 영어로 '밀린 일'이라는 뜻이죠.

 

해야 할 일을 전부 적되, 중요한 순서대로 위에서부터 줄을 세워둡니다. 

일을 시작할 땐 맨 위(가장 중요한 것)부터 가져가면 되니, "뭐부터 하지?"로 고민할 일이 없어집니다.

 

백로그는 보통 두 종류로 나뉘는데, 프로젝트 전체의 할 일 목록(제품 백로그)과 이번 스프린트에서 할 일만 추린 목록(스프린트 백로그)입니다.

 

C. 데일리 스탠드업(Daily Standup) 

 

매일 짧게 모이는 회의입니다.

'스탠드업'이라는 이름이 붙은 이유는, 서서 할 만큼 짧게(15분 이내) 끝내자는 뜻에서입니다.

 

각자 딱 세 가지만 말합니다.

⑴ 어제 한 일, ⑵ 오늘 할 일, ⑶ 막혀 있는 것.

 

자세한 논의가 필요하면 회의가 끝난 뒤 관련된 사람끼리만 따로 모입니다.

이렇게 하면 전체 진행 상황을 매일 가볍게 공유하면서도 시간 낭비가 없습니다.

 

D. 회고(Retrospective)

 

스프린트가 끝날 때 '이번엔 어땠는지' 함께 돌아보는 시간입니다.

핵심은 사람을 탓하는 자리가 아니라는 점입니다.

 

"누가 못했다"가 아니라 "우리 팀의 일하는 방식에서 무엇이 좋았고, 무엇을 바꿀까"를 이야기합니다.

 

흔히 세 가지로 나눠 정리합니다.

계속할 것(Keep), 그만둘 것(Problem), 새로 시도할 것(Try).

 

실제로 마켓컬리 개발팀은 회고 의견을 익명으로 적게 해서, 직급이나 눈치 없이 솔직한 피드백이 나오게 합니다.

회기동 막걸리에서도 매월 KPT 혹은 4L 방법을 통해 모든 팀이 회고를 진행하고 있습니다.

 

이 네 가지가 돌아가면, "계획을 세우고 → 짧게 집중해서 만들고 → 매일 점검하고 → 끝나면 돌아보며 개선하는" 리듬이 생깁니다. 이 리듬 자체가 애자일입니다.

📌 알아두면 좋은 것
큰 회사들은 스크럼을 더 크게 확장하기도 합니다.
예를 들어 스포티파이(Spotify)는 작은 자율 팀(스쿼드)을 여러 개 묶어 운영하는 모델로 유명하죠.
다만 이건 수백 명 규모를 위한 구조라, 우리는 '작은 팀이 짧은 주기로 점검한다'는 핵심만 가져오면 충분합니다.

 

4. 실제 사례로 보기

스크럼을 작은 팀의 사례로 보면 어떤 모습일까요?

먼저 게임 개발팀 사례를 2주 일정으로 따라가 보겠습니다.

 

① 게임 개발팀 — '전투 시스템 프로토타입' 스프린트 (2주)

• 1일차 (스프린트 계획): 백로그 맨 위의 일들을 보고 "이번 2주 목표는 '캐릭터가 적을 공격해 데미지를 입히는 프로토타입까지'"로 정합니다. 이 목표를 잘게 쪼개 스프린트 백로그를 만듭니다. (예: 공격 모션, 데미지 계산 로직, 적 피격 반응)
• 매일 오전 (데일리 스탠드업, 15분): "어제 공격 모션 절반 했고, 오늘 마저 합니다. 그런데 데미지 계산 공식을 기획팀과 못 정해서 막혔어요." → 회의 후 기획·개발이 따로 5분 만나 해결.
• 약 7일차 (중간 점검): 절반 지점에서 진행 상황을 보고, 목표가 너무 크면 일부를 다음 스프린트로 넘깁니다. (무리한 완성보다 솔직한 조정이 낫습니다.)
• 14일차 (스프린트 리뷰 + 회고): 만든 프로토타입을 팀원들과 직접 플레이해봅니다. "공격은 되는데 타격감이 약하다"는 피드백을 얻고, 회고에서 "다음엔 기획 확정을 스프린트 시작 전에 끝내자(Try)"를 정합니다.

이렇게 한 바퀴 돌고 나면, 6개월 뒤가 아니라 2주 만에 실제로 작동하는 무언가와 구체적인 개선점을 손에 쥐게 됩니다.

 

이번에는 개발 말고 다른 사례를 들어볼까요?

운영팀에서 신입 모집 설명회를 준비한다고 가정해봅시다.

 

② 운영팀 — '신입 모집 설명회' (4주 = 2 스프린트)

 

행사 전 4주를 두 개의 스프린트로 나눕니다.

• 1차 스프린트(1~2주차): '행사 기획 확정 + 장소 섭외'
• 2차 스프린트(3~4주차): '홍보물 배포 + 리허설'

매주 짧게 모여 점검하면, "행사 3일 전에 현수막 발주를 까먹은 걸 발견"하는 식의 사고를 미리 막을 수 있습니다.

1차 스프린트 회고에서 "장소 섭외가 늦어 고생했으니 다음엔 가장 먼저 처리하자"는 교훈을 2차에 바로 반영할 수도 있죠.

 

다음에는 마케팅의 사례를 보여드릴게요.

 

③ 마케팅 — 'SNS 콘텐츠 운영'

 

한 달 치 콘텐츠를 통째로 계획하면, 반응이 나빠도 이미 다 만들어버린 뒤라 수정이 어렵습니다.

 

대신 2주 단위로 끊어, 1차 스프린트엔 '게임 개발 비하인드 4편'을 만들어 올립니다. 2주 뒤 조회수와 댓글 반응을 보니 '개발 비하인드'보다 '멤버 인터뷰'가 반응이 좋았다면, 2차 스프린트는 인터뷰 위주로 방향을 틉니다.

 

이것이 바로 '낭비 없이 자주 점검하기'의 실전입니다.

 

5. 애자일 도입, 이것만 기억하세요

 

1. '빠르게'가 아니라 '핵심부터'. 모든 걸 다 하려 하지 말고, 가장 중요한 것부터 작게 만드세요.
2. 주기를 짧게 고정하세요. 2주처럼 일정한 리듬이 있어야 점검과 개선이 습관이 됩니다.
3. 회의는 짧게, 자주. 긴 회의 한 번보다 15분짜리 잦은 점검이 훨씬 효과적입니다.
4. 완성이 아니라 피드백을 목표로. 스프린트가 끝날 때마다 '보여줄 수 있는 무언가'를 만들고, 거기서 배우세요.

 

6. 마무리

애자일과 스크럼은 거창한 시스템이 아니라, '작게 만들고 자주 점검하며 함께 고쳐나가는 리듬'입니다.

 

글로벌 기업이든 작은 팀이든 통하는 원리는 똑같습니다.

처음부터 완벽하게 도입하려 하지 말고, 다음 프로젝트에서 '2주 스프린트 한 번'만 가볍게 시도해보세요.

 

그런데 막상 이걸 팀에 도입하려고 하면 "그래서 첫 회의에서 뭘 정해야 하지?", "회고는 어떻게 진행하지?" 같은 막막함이 생깁니다. 다음 편에서는 바로 그 실제 셋업 방법을 단계별로 다루겠습니다.

 

 

참고 자료
- Agile Manifesto(2001)
- 마켓컬리 기술블로그 "스크럼 도입기"
- Atlassian Agile Coach(Scrum/Ceremonies)
- Spotify Engineering Culture