레이블이 Agile인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Agile인 게시물을 표시합니다. 모든 게시물 표시

2/20/2026

유연함 vs 규칙, 애자일을 하는 순간, 애자일은 멀어집니다.


애자일은 규칙을 지키는 스포츠가 아니라, 불확실성을 다루는 일의 방식입니다. "스크럽에 없으니 못해요"라는 말이 나오기 시작하면, 우리는 애자일을 도입한 게 아니라 새로운 관료주의를 추가한 것일지도 모릅니다.

규칙은 편합니다.
규칙은 대답이 빠릅니다. "이건 스크럼에 없어", "가이드는 이렇게 얘기해".
규칙은 불안을 줄여줍니다. 일단 외우면, 생각하지 않아도 됩니다.

하지만 프로젝트는 특히 소프트웨어 프로젝트는 계속 변합니다. 고객이 변하고, 기술이 변하고, 조직이 변한다. 그 세계에서 "한 번 정한 방식"을 고집하는 순간, 우리는 "안정"이 아니라 지연을 얻습니다.

본 글은 애자일을 찬양하지 않지만, 애자일이 "종교"가 되는 순간을 관찰하고, 다시 유연함으로 되돌리는 방법을 언급합니다.

예시를 하나 들어볼까요?

아침 9시가 되면, 멤버들이 하나둘 모입니다.

"어제 한 일 말씀드릴게요."
"오늘 할 일 말씀드릴게요."
"이슈는... 없습니다."

위 문장이 문제는 아닙니다. 문제는 이 말이 "안전한 말"이 되어버리는 순간입니다.

이슈가 없어서 없습니다.라고 말하는 게 아니라, 이슈를 말하면 일이 커질까 봐 "없습니다."가 나오는 날들이 있습니다.
"경직"은 대개 이런 장면에서 시작됩니다. 애자일이 팀을 돕는 도구가 아니라, 팀을 작게 만드는 규칙이 되는 순간이죠.


애자일이 원래 하려던 것

애자일 선언문은 "계획을 따르는 것"보다 변화에 대응하는 것을 더 가치 있게 둔다고 합니다. 또한 "지속가능한 개발"을 강조합니다. 스폰서, 개발자, 사용자 모두가 무기한 일정한 속도를 유지할 수 있어야 한다고요.

그러니까 애자일은 원래,

  • 빨리 달리자고 만든 것도 아니고
  • 회의를 많이 하자고 만든 것도 아니고
  • 용어를 통일하자고 만든 것도 아닙니다.

불확실한 상황에서, 가치와 학습을 더 빨리 얻어내기 위한 방식에 가깝습니다.

그런데 현장에서는 가끔 반대로 됩니다.
불확실성이 무서우니, 규칙을 더 만들고, 절차를 더 붙이고, 승인 라인을 더 늘립니다.
그러다보면 애자일은 어느새 "유연함"이 아니라 "교리"가 됩니다.


스크럼에 없어요.

"그건 스크럼에 없어요."

이 말은 보통 나쁜 의도로 나오지 않습니다.
대개는 혼란을 막으려는 마음에서 나옵니다.

그런데 아이러니하게도, 스크럼 가이드는 스크럼을 이렇게 소개합니다.
스크럼은 가볍고, 의도적으로 불환전하다고요. 즉, 필요한 것만 정의하고, 나머지는 사용하는 사람들의 집단지성으로 쌓아 올리라고 말합니다.

스크럼에 없으니 안됩니다.가 아니라 스크럼에 없으니 우리 상황에 맞게 지혜롭게 완성해봅시다. 쪽이 더 가깝습니다.


경직의 얼굴

"경직"이 현장에서 어떻게 나타나는지 얘기해보죠.


프레임워크가 도구가 아니라 레시피가 될 때,

레시피는 정량을 요구합니다. 한 스푼, 두 스푼... 순서도 바꾸면 안됩니다.
하지만 프로젝트는 요리가 아닙니다. 재료가 매주 바뀌고, 손님도 바뀌고, 오븐 온도도 바뀝니다.
애자일은 유연함을 구조 안에 넣어서, 상황이 바뀌어도 가치 중심의 일관성을 유지하는 쪽입니다.

현장에서 발생하는 미묘한 상황은 이런 것입니다.

  • "이걸 하면 도움이 될까요?"가 아니라
  • "이걸 해야 스크럼이 맞나요?"가 선행됩니다.

이러면 목적은 사라지고 형식만 남겨됩니다.


범위, 일정, 예산이 움직이면 안 되는 것이 될 때

일반적으로 범위, 일정, 예산은 고정된 것처럼 다루게 됩니다. 이게 현실이지요.

그런데 실제 현장에서는 바뀌지 않는 건 범위가 아니라 환경입니다.

  • 고객이 바뀌고
  • 경쟁이 바뀌고
  • 법규가 바뀌고
  • 팀의 역량도 바뀝니다.

이런 상황에서 "계획대로"는 이상하게도, "이미 낡아진 요구사항을 정시에 납품"하는 뜻이 되기도 합니다.

그래서 애자일 원칙은 변화 대응을 전면에 둡니다. 그리고 스크럼은 "목표" 중심으로 팀이 움직이도록 설계되어 있습니다.
스프린트 목표가 있으면, 세부 작업은 목표에 맞춰 조정될 수 있습니다.


거버넌스가 가이드가 아니라 문지기가 될 때

회의는 늘어납니다. 그런데 결정은 줄어듭니다.

"이건 결재가 필요합니다."
"이건 협의체에서 확인해야 합니다."
"이건 다음 주에 다시 논의하겠습니다."

거버넌스가 팀을 돕는 대신 문지기가 되면, 전달이 느려지고 팀의 소유감이 약해지게 됩니다.

이때 팀은 두 가지를 동시에 잃게 됩니다.

  • 속도 (결정이 멀어서)
  • 책임감 (결정이 내 것이 아니라서)

신기하게도, 그 결과로 통제는 더 강해집니다.
통제가 강해지면 더 느려지고, 느려지면 더 통제합니다.
경직의 루프입니다.

해소하는 방법은 매우 단순합니다.
무거운 승인 체인 대신, 가벼운 마일스톤.
그리고 산출물이 아니라 성과 중심으로.


심리적 안점감이 사라질 때

심리적 안전감은 어렵게 들리지만, 정의는 간단합니다.
맥킨지는 심리적 안점감을 "대인관계 두려움의 부재"라고 설명합니다.
즉, 말해도 안전하다고 느끼는 상태입니다.

구글의 프로젝트 아리스토텔레스에서는, 팀 교화성에 중요하게 연결된 다섯 가지 중 심리적 안점감이 가장 중요했다고 알려져 있습니다. 현장에서는 이렇게 보입니다.

  • 회고에서 "좋았던 점"만 나옵니다.
  • 질문이 줄고, 대신 개인 메시지가 늘어납니다.
  • "그냥 하시죠."가 자주 나옵니다.

팀이 조용해지는 것은, 보통 좋은 신호가 아닙니다.


대면 근무를 해야 애자일일까?

애자일 원칙에는 "정보 전달의 가장 효율적이고 효과적인 방법은 대면 대화라는 문장이 있습니다."
하지만 이것이 곧 "같은 사무실에 앉아야 한다"는 뜻은 아닙니다.

즉, 핵심은 "같은 공간"이 아니라 "같은 정보"입니다.
대면은 강력한 수단이지만, 팀이 성숙되면 다른 방식도 가능합니다.


계획은 "돌에 새기는 것"이 아니라 "업데이트되는 지도"

가까운 미래는 상세하게 펼치고, 프로젝트가 진전되면 완료 날짜와 비용을 주기적으로 재평가 하는 방식이 롤링 웨이브입니다.

이 방식은 보고서용으로 보면 딱딱해보이지만,
현장에서는 굉장히 현실감이 있습니다.

  • 당장 필요한 건 구체적으로
  • 나중에 바뀔 건 가설로
  • 바뀌면 바뀐 걸 부끄러워하지 않고 업데이트

이것이 "유연함"의 정체입니다.


유연함은 어떻게 "시스템"이 되나요?

어떻게 시스템화할 수 있을까요?


회의 질문을 바꾸면, 팀의 공기가 바뀝니다.

스탠드업에서 이런 질문을 해보세요.

"어제 뭐하셨어요?" 대신에 "오늘 목표를 가장 늦추는 건 뭐죠?"

질문이 바뀌면, 회의의 성격이 바뀝니다. 보고가 아니라 장애물 제거가 됩니다.

애자일 원칙이 강조하는 "지속가능한 속도"는 사람을 조이기보다, 막히는 구조를 덜어내는 쪽에 더 가깝습니다.


승인보다 "가드레일"

거버넌스가 필요한 이유는 있습니다.
보안, 규제, 예산, 품질 등 이런 것들은 "나중에"가 아니라 "처음에" 정리해야 합니다.

문제는 거버넌스가 문지기가 되는 순간입니다.
승인 라인을 늘리기보다 "우리가 절대 어기면 안되는 것(가드레일)을 짧게 합의하는 편이 더 낫습니다."

상세 지침보다 관계와 상호작용을 "가이드" 하는 것이 스크럼의 철학입니다. 그래서 가드레일은 스크럼 스럽습니다.


성과로 말하면, 통제와 자율이 같이 살아납니다.

산출물은 "만들었다."를 말하고, 성과는 "의미가 생겼다."를 말하지요.

예를 들면,

  • 산출물: 온보딩 화면 개편 완료
  • 성과: 첫날 이탈률 15% 감소

성과로 말하면, 의사결정권자 입장에서도 마음이 놓입니다. 그리고 팀은 "어떻게"를 더 자유롭게 설계할 수 있습니다.
통제와 자율이 싸우지 않고 공존하는 방식이 보통 이런 형태입니다.


심리적 안전감은 "착한 문화"가 아니라 "생산적 구조"입니다.

심리적 안전감은 "분위기 좋게 지내자."가 아닙니다.
말이 막히면, 정보가 막힙니다.
정보가 막히면, 리스크를 늦게 인지합니다.
리스크를 늦게 인지하면, 결국 비용이 커집니다.

맥킨지는 심리적 안전감을 "반대 의견을 말하고, 우려를 드러내고, 불이익 및 두려움 없이 말할 수 있는 환경"과 관련된다고 설명합니다.
그래서 회고에서 가장 먼저 해야 할 말은 이것입니다.

"이건 사람의 문제가 아니라, 시스템의 문제로 다루겠습니다."

이 한 문장이 있어야, 다음 문장이 나옵니다.

"사실... 지금 이 승인 과정 때문에..."


마무리

애자일은 원래, 유연함을 위한 언어였습니다.
그런데 현장에서는 자주, 규칙의 언어가 됩니다.

하루에 한 번 서서 말하는 것.
2주에 한 번 계획하는 것.
회고를 하는 것.

그 자체가 나쁜 것은 아닙니다.
문제는 그것이 목적이 되는 순간입니다.

우리는 "잘하고 있다."는 증거를 남기느라,
정작 "잘하기 위한 움직임"을 잃어버리기도 합니다.

프레임워크는 지도입니다.
하지만 지도는 여행을 대신해주지 않습니다.

애자일이 살아있다는 신호는 의외로 단순합니다.

회의가 늘었는지가 아니라, 결정이 가까워졌는지입니다.
프로세스가 촘촘해졌는지가 아니라, 학습이 빨라졌는지입니다.
속도가 빨라졌는지가 아니라, 지속가능해졌는지입니다.

조직은 불확실성을 두려워합니다.
그래서 교리를 찾습니다.

하지만 불확실한 시대에 필요한 건 교리가 아니라,
가드레일을 가진 유연함입니다.

우리가 지켜야 할 것은 절차가 아니라 가치입니다.
애자일은 "하는 것"이 아니라, "쓰는 것"입니다.

그리고 그 차이는,
스탠드업의 첫 질문 하나에서 시작될 수 있습니다.

이제까지 나온 이야기를 다섯가지로 정리를 해보면,
첫째, 애자일 도입이 아니라 의사결정 구조 개편이 먼저입니다.
애자일이 실패하는 이유는 문화가 아니라 구조입니다. 결정이 멀면, 팀은 회의를 늘리고 문서를 늘립니다. 그건 애자일이 아니라 생존 전략입니다. 권한을 일과 가까운 곳으로 옮길수록, 애자일은 자연스럽게 작동합니다.

둘째, 통제는 승인으로 하지 말고, 가드레일로 해야 합니다.
승인은 속도를 줄이고, 책임감을 약하게 합니다. 반면 가드레일은 속도를 지키면서도 위험을 막습니다. 보안, 규재, 품질처럼 "절대선"은 명확히 고정하고, 그 외는 팀이 학습하며 바꾸도록 두는 편이 장기적으로 좋습니다.

셋째, 산출물 중심 관리에서 성과 중심 관리로 이동해야 합니다.
산출물은 "만들었다"를 말합니다. 성과는 "가치가 생겼다"를 말합니다. 성과로 말하면, 경영진은 불안을 덜고 팀은 방법을 더 유연하게 설계할 수 있습니다. 성과는 통제와 자율을 동시에 살리는 언어입니다.

넷째, 지속가능한 속도가 진짜 KPI가 되어야 합니다.
속도를 올리는 방법은 두 가지 입니다.
사람을 더 쥐어짜거나, 재작업을 줄이거나.
장기적으로 남는 건 후자입니다. 번아웃 없이 유지되는 속도는 채찍이 아니라 구조에서 나옵니다.

다섯째, 원격/하이브리드 시대의 애자일은 공간이 아니라 정보의 문제입니다.
같은 공간에 있어도 정보가 분절되면 애자일은 죽습니다.
다른 공간에 있어도 정보가 투명하면 애자일은 살아납니다.
코로케이션은 수단일 뿐, 정의가 아닙니다.
공유된 정보와 빠른 피드백 루프가 본질입니다.

끝으로,
애자일은 규칙을 늘리기 위해 존재하지 않습니다.
불확실성을 견디기 위해 존재합니다.

그렇다면 우리가 지켜야 할 것은 절차가 아니라,
가치와 학습의 속도일 것입니다.

애자일은 "하는 것"이 아니라, "쓰는 것"입니다.

12/08/2021

스토리 포인트 바르게 사용하기

 

스토리 포인트는 팀이 특정 기능을 개발하는데 필요한 노력의 양을 추정하기 위한 편리하고 효율적인 측정 기술이다.

스토리 포인트는 추정치이다. 추정은 예측을 하는 것이고 실제 사실과는 다를 수 있다. 애자일 및 스토리 포인트의 제작자도 정기적인 스프린트 기대치를 충족시키지 못했다고 한다. 경영진은 숫자, 약속, 속도등을 원하기에 스토리 포인트를 이용해 그들을 즐겁게 한거라고 한다. 결국 스토리 포인트를 추가함으로써 경영진을 행복하게 만드는 방법을 찾은 것이다. (믿거나~ 말거나~)

일반적으로 사용자 스토리가 주어지면 스토리의 복잡성을 숫자로 추정한다. 1-5 혹은 1-10 범위로 제한되며 때로는 큰 추정치로 작성한다.

예전부터 스토리 포인트를 사용했었다. 스토리 포인트가 팀의 작업 능력을 식별하는 데 도움이 된다고 생각했다. 그러나 이번에 진행을 하면서 스토리 포인트와 퍼포먼스 측정을 내가 잘 사용하고 있는가에 대한 의문이 들었다.

몇 가지 가정을 해보자. 모든 개발자가 동등한 역량을 지니고 있고, 유사한 스킬을 가지고 있고, 전체 스프린트에 걸쳐 있고, 다른 스프린트에 속하지 않는다면, 예측 가능한 시간으로 작업할 수 있기에 추정치와 비슷하게 나올 것이다. 하지만 현실에서는 거의 불가능하다고 생각한다. 그 이유는 아래에 언급한 것들을 세세하게 고려하기가 어렵기 때문이다.

  • Lamp-up 타임 (문제를 이해하고 그 문제를 해결하는 시간) - 사람마다 다르기에 이 부분이 고려되어 있지 않다.
  • 방해 타임 (회의, 1:1 미팅, 비즈니스 우선 순위 변경, 개인 사유등)
  • 숨겨진 작업

스토리 포인트는 무엇을 추정하는데 사용되는 것일까? 고정된 크기의 스프린트와 정확한 포인트 추정치가 존재한다면, 예측 가능한 번다운 비율이 있어야 한다. 이를 통해 고정된 시간 내에 수행될 작업을 매우 정확하게 예측할 수 있게된다. 그러나 현실에서는 정확한 포인트 추정을 할 수 없다. 그래서 번다운 비율을 예측하기가 어렵다. 그렇다고 해서 스토리 포인트가 가치가 없는 것은 아니다.

스토리 포인트의 역할은 복잡성을 측정하는 것이다.우리팀이 스프린트당 얼마나 많은 복잡성을 처리 할 수 있는지에 대한 추정해 볼 수 있는 것인데, 단순히 시간과 같은 것으로 생각했던 것 같다. 일반적으로 포인트1당 = 하루로 계산했던 것 같다. 물론 이렇게 계산하는게 내부적으로도 편하고 경영진과 의사소통하기에도 무난했지만, 이는 잘못된 방식인 것을 깨달았다. 스토리 포인트는 관리를 위한 것이라기보다는, 팀을 위한 것인데… 이 부분을 놓쳤던 것 같다.

우리 인간의 두뇌는 하루에도 많은 일을 처리하고 있다. 팀원들은 시간을 기능으로 바꾸는 기계가 아니다. 즉, “8시간이 하나의 기능을 의미한다면 16시간에는 2개의 기능을 의미한다.” 처럼 잘못된 것으로 인지 될 수 있다. 이것은 사실이 아니기 때문이다. 인간이 하루에 집중할 수 있는 시간은 생각보다 많지 않다고 생각한다. 스토리 포인트가 5점이라고 해서 1점보다 5배의 시간이 걸린다는 의미는 아니고 1점보다 5배 더 복잡하다는 의미로 생각해야했다. 일반적으로 5점짜리가 1점짜리보다 더 많은 시간이 걸릴 가능성이 매우 높기에 이를 시간으로 환산 하려 했던 점이 잘못되었던 것 같다.

이번에 Jira를 세팅하면서 제품 백로그를 추정하기 위해 스토리 포인트를 사용했다. 하지만 스프린트 백로그는 포인트 단위가 아닌 시간 단위로 추정하도록 했다. 즉, 스토리 포인트는 복잡도/장기적 관점에서 활용하고 스토리 포인트는 스프린트 시간으로 나누는 방식이다.

앞으로 스토리 포인트는 팀이 현재 스프린트의 복잡성 추정하는 용도로만 사용할 것이다.

References

  • https://rigidity.medium.com/agile-waste-story-points-pt-1-a9df2572d0a3
  • https://www.leadingagile.com/2018/12/the-problem-with-story-points/