우리가 애자일 프로세스를 재설계한 이유: 번아웃을 넘어 자율성과 집중으로

우리 팀은 딜리버리에 문제가 있었던 건 아니었다. 문제는 에너지였다. 스프린트는 끝없이 이어졌고, 플래닝은 점점 피로해졌고, 인터럽트는 조용히 흐름을 무너뜨리고 있었다.

애자일을 잘 운영하는 팀도 봤고, 반복만 남은 껍데기 같은 프로세스로 변질된 사례도 많이 봤다. 이 글은 우리가 자율성, 집중, 그리고 지속 가능한 리듬을 되찾기 위해 어떤 선택을 해왔는지 기록한 내용이다.

문제: 애자일인데 애자일하지 않은 상태

데일리 스탠드업, 2주 스프린트, 회고. 표면적으로는 애자일 프로세스가 굴러가고 있었지만, 팀은 점점 정체되고 있었다.

• 플래닝은 팀원 대부분에게 가장 피곤한 시간이 됐다.
• 인터럽트가 많아졌고, 미리 정한 업무가 점점 흔들렸다.
• 개발자들은 문제를 해결하는 사람이 아니라, 티켓을 쳐내는 사람처럼 느껴지기 시작했다.

동료들과 이야기하면서, 단순히 일이 많아서 생긴 문제가 아니라는 걸 느꼈다. 우리가 따르던 애자일이 오히려 피로를 만드는 구조가 되어가고 있었다.

대화의 시작: 우리가 바라는 모습은?

그래서 물어봤다.

"매일 아래 다섯 가지 가치를 느낄 수 있는 팀을 만든다면, 해볼 만하지 않을까?"

1. 존중 (Honor) – 서로의 강점을 인정하고 존중할 수 있을까?
2. 개방성 (Open) – 정보와 커뮤니케이션이 막힘없이 흐를 수 있을까?
3. 책임감 (Commitment) – 함께 목표를 향해 나아가고 있다고 느낄 수 있을까?
4. 집중력 (Focus) – 방해받지 않고 일에 몰입할 수 있을까?
5. 용기 (Courage) – 문제가 생겼을 때 피하지 않고 함께 해결하려 할 수 있을까?

모두 고개를 끄덕였다. 지금 상태가 아니라 우리가 어떤 팀이 되고 싶은지에 대한 합의가 생겼다. 그걸 계기로 프로세스를 다시 설계해보기로 했다.

우리가 정의한 세 가지 원칙

애자일의 핵심 원칙, 투명성(Transparency), 점검(Inspection), 적응(Adaptation) 으로 다시 돌아가기로 했다. 그리고 아래 세 가지 구조를 만들기 시작했다.

1. 버퍼가 있는 4주 스프린트

AgileLite에서 아이디어를 얻었다. 기존의 2주 스프린트 대신 4주 단위 스프린트를 구성했다.

• 3주간 집중 개발
• 1주간 여유 있는 조율 기간: "Lite Week"

4주 구조:

• 1~3주차: 기능 개발, 코드 리뷰, QA, 데일리 스탠드업
• 4주차 (Lite Week):
  • 월: 리뷰 및 회고
  • 화~수: 백로그 정리 및 스토리 구조화
  • 목: 스프린트 플래닝
  • 금: 릴리즈 조율 및 자율 시간

Lite Week은 문서화, 회고, 기술 부채 정리, 동료 챙김 등 ‘미뤄두기 쉬운 일’들을 위한 주간이다. 일부러 여유를 만들어서 팀이 숨 쉴 수 있도록 했다.

또 역할도 분명히 나눴다:

• PO는 우선순위를 정한다.
• 스크럼 마스터는 프로세스와 생산성을 지킨다.
• 개발자는 집중할 수 있는 환경에서 설계와 추정에 참여한다.

간단한 규칙도 만들었다:

• 백로그는 플래닝 이틀 전까지 마감
• 3일 이상 걸릴 작업은 무조건 쪼개기
• 스프린트 용량의 20%는 인터럽트 대응용으로 확보

2. Support Budget: 예측 불가 업무를 위한 여유

예측이 어려운 업무들을 위해 개발자의 용량 중 20%를 인터럽트 대응용 예산으로 설정했다. 갑작스러운 이슈 때문에 계획된 일이 흔들리지 않도록 하기 위한 장치다.

3. 가치 기반 체크인

앞서 말한 다섯 가지 가치 기반으로 분기마다 팀 건강도를 체크하고 있다. 누군가를 평가하기 위한 게 아니라, 지금 우리가 어떤 환경에서 일하고 있는지 감지하려는 시도다.

스프린트 리뷰는 이렇게 바꿨다

데모만 보여주는 자리로 끝내지 않기로 했다. 리뷰는 팀이 크레딧을 얻고, 우선순위를 조정하는 시간으로 만들었다.

1. 작업 완료에 대한 인정 – 해낸 것 자체를 확인하고 인정한다.
2. 제품 관점의 피드백 수집 – 개인이 아닌, 결과물에 대한 피드백을 통해 PO와 우선순위를 정렬한다.

회고는 전일 워크숍으로 운영한다

1시간 회고로는 부족했다. 그래서 하루를 통째로 써서 회고, 리셋, 팀빌딩을 한 번에 할 수 있는 전일 회고 워크숍으로 만들었다.

• Best Contributor 투표 (팀빌딩) – 익명 투표 + 가중 제비뽑기. 재미와 인정 모두 챙긴다.
• 스프린트 지표 리뷰 (리뷰) – 완료율, 벨로시티, 결함 수, 팀 건강도는 추이만 본다.
• 추정 정확도 확인 (리뷰) – Story Point 추정 정확도를 돌아본다.
• KPT 회고 (리셋) – Keep-Problem-Try 형식. 액션 아이템은 최대 3개까지만.
• Tech Talk (팀빌딩) – 팀원이 자율적으로 발표하는 세션.

이 시간은 반성하거나 따지는 시간이 아니라, 팀이 리듬을 정리하고 회복하고 성장하는 시간이다.

우리는 지금도 계속 바꾸고 있다

우리의 애자일은 아직 완성형이 아니다. 지금도 분기마다 점검하고, 팀 상황에 따라 바꿔나가고 있다.

예를 들어, 인터럽트가 많아지면서 20% 버짓만으로는 감당이 안 됐다. 그래서 인터럽트성 업무도 티켓화해서 수치로 측정하기 시작했다. 그 비중을 보면서 플래닝에 반영해보려는 중이다.

또, 스프린트 목표가 점점 모호해지고 있다는 것도 알게 됐다. 팀 전체가 하나의 Sprint Goal을 갖는 게 이상적이지만, 현실적으로는 각자 명확한 개인 목표 하나씩은 반드시 가져가자는 방식으로 바꿨다.

이건 이상을 포기한 게 아니라, 그 방향으로 가기 위한 현실적인 과정이라고 생각한다.

• 자율성은 계속 진화 중이다 – 개발자가 직접 구조를 바꾸고 있다.
• 집중은 회복되고 있다 – 인터럽트를 인정하고, 추적하고, 관리할 수 있게 됐다.
• 명확성은 올라가고 있다 – 각자의 목표를 또렷하게 설정하고 책임감을 갖게 됐다.

우리는 애자일을 더 잘하고 있는 게 아니다. 우리 팀에 맞게 애자일을 다시 정의하고 있을 뿐이다.

마무리하며

팀이 번아웃 상태라면, 정답은 더 복잡한 도구도 아니고, 더 세밀한 벨로시티 관리도 아니다.

나는 우리 팀의 Staff Engineer다. 매니저도 아니고, 애자일 전문가도 아니다. 예전에 Engineering Manager 역할을 해본 적은 있지만, 꼭 그런 타이틀이 있어야 일하는 방식을 제안할 수 있다고 생각하지 않는다.

애자일 선언문이 말하듯, 최고의 설계와 아키텍처는 자율적인 팀에서 나온다.

좋은 프로세스와 문화는 누가 시켜서 만들어지는 게 아니다. 맥락, 실험, 의지에서 나온다.

우리는 아직 멀었다. 하지만 시도하고 있다. 바꿔보고 있다.

그리고 그 중심엔 늘 이 세 가지가 있었다: 투명성(Transparency), 점검(Inspection), 적응(Adaptation)

문제 없는 팀이 되는 게 아니라, 문제를 다룰 수 있는 팀이 되는 것. 그게 우리가 원하는 방향이다.