잘못 들여온 애자일이 R&D를 망치는 이유

18개월 후의 시장은 우리를 기다려 주지 않는다. 기획부터 출시까지 26개월이 걸리는 제품 개발 사이클로는, 정작 출시 시점에 이미 경쟁사가 같은 기능을 기본으로 탑재하고 있는 상황을 피할 길이 없다. 워터폴 방식이 만들어낸 가장 큰 비극은 좋은 제품을 늦게 만드는 일이었다. 애자일은 결국 그 시계를 다시 짜는 일이다.

애자일은 방법론이 아니다

애자일은 단순한 방법론이 아니다. 빠르게 틀리고 빠르게 배우는 조직 DNA에 가깝다. 이 표현이 중요한 이유는, 많은 회사가 애자일을 도구나 절차로 도입하고는 본질을 놓치기 때문이다. 매주 회고 미팅을 하고 칸반 보드를 쓴다고 애자일한 조직이 되는 것은 아니다. 가설이 틀렸을 때 빠르게 인정하고 방향을 바꿀 수 있는 문화가 진짜 애자일이다.

워터폴 방식의 네 가지 한계

전통적인 워터폴 방식의 한계는 분명하다.¹

문제가 후반부에 한꺼번에 드러난다. 기획·설계·개발·테스트·출시가 순차적으로 진행되는 워터폴에서 문제는 보통 후반부 테스트 단계에 한꺼번에 발견된다. 이 시점에는 이미 너무 많은 자원이 투입된 상태라 근본적 수정이 불가능하다.

긴 기간 동안 시장은 이미 바뀌어 있다. 18개월에서 26개월이 걸리는 개발 사이클 동안 시장의 요구는 빠르게 변한다. 처음에 기획한 기능이 출시 시점에는 이미 시장의 우선순위에서 밀려나 있는 경우가 많다.

완성될 때까지 고객의 진짜 반응을 확인할 수 없다. 모든 기능이 완성된 뒤에야 고객 앞에 내놓을 수 있는 구조에서는 가설을 빠르게 검증할 수 없다. 가설이 틀렸다는 사실을 출시 후에 알게 되는 일이 반복된다.

부서 간 단절이 구조화된다. R&D가 제품을 만들어 영업에 던지는 구조는 부서 간 협업을 어렵게 한다. 고객의 목소리가 R&D에 흐르지 못하고, R&D의 제품 의도가 영업에 충분히 전달되지 못한다.

애자일이 뒤집는 네 가지

애자일은 이 네 가지 한계를 정반대로 뒤집는다. 2~4주 단위 스프린트로 빠르게 만들고, 매번 고객과 이해관계자의 검증을 받고, 그 피드백을 바로 다음 스프린트에 반영한다. 애자일 선언문(Manifesto for Agile Software Development)은 이를 네 가지 가치로 정리했다.²

공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를

오른쪽 항목들도 가치가 있지만, 왼쪽 항목들에 더 가치를 둔다는 뜻이다. 이 네 가지가 애자일의 본질이다.

스포티파이 모델의 신화와 진실

애자일을 도입하려는 회사가 가장 흔히 빠지는 함정은 스포티파이 모델을 그대로 가져오려는 시도다. 스쿼드, 트라이브, 챕터, 길드로 구성된 스포티파이의 조직 모델은 한때 애자일의 정답처럼 여겨졌다. 그러나 실상은 다르다.

스포티파이의 모델을 처음 소개했던 헨릭 크니버그(Henrik Kniberg) 자신이 그 모델이 항상 작동했던 것은 아니라고 인정했다.³ 그가 설명한 모델은 스포티파이가 한 시점에 시도하던 실험에 가까웠고, 스포티파이도 이후 그 모델을 지속적으로 수정해왔다.

후속 분석에서는 "스포티파이 모델을 그대로 복사하지 말라(Don't Copy the Spotify Model)"는 경고가 거의 정설처럼 자리잡았다.⁴ 다른 회사의 모델을 그대로 옮기면 거의 예외 없이 실패한다. 애자일의 본질은 자기 조직에 맞게 끊임없이 진화시켜 나가는 데 있다. 스포티파이가 그 모델로 성공한 것이 아니라, 자기 조직에 맞게 끊임없이 진화시킨 자세로 성공한 것이다.

애자일 도입의 세 가지 전제

애자일이 진짜 자리잡으려면 세 가지 전제가 갖춰져야 한다.

협업의 인프라. Slack, Jira, Notion 같은 도구가 없으면 빠른 의사소통 자체가 불가능하다. 도구 자체가 애자일을 만들지는 않지만, 도구가 없으면 애자일은 아예 시작할 수 없다. 인프라는 필요조건이지 충분조건은 아니다.

리더십의 의지. 권한 위임을 입으로만 외치는 게 아니라 진심으로 받아들여야 한다. 스프린트 리뷰에서 팀이 결정한 우선순위를 리더가 자기 권한으로 뒤집기 시작하면, 팀은 곧 자율적으로 결정하기를 멈춘다. 애자일은 리더가 통제를 일부 내려놓을 때만 작동한다.

고객의 목소리. 매 스프린트마다 진짜 고객의 피드백을 확보할 수 있어야 한다. 가짜 고객(내부 직원, 친한 파트너)의 피드백만 모이면 애자일은 자기만족적 사이클로 변한다. 진짜 고객, 진짜 사용자에게 매 2~4주 단위로 닿을 수 있는 채널이 핵심이다.

가짜 애자일의 신호

이 셋이 모두 갖춰지지 않으면 애자일은 외형만 남는다. 매주 회고 미팅을 하지만 회의가 끝나도 결정되는 것이 없는 가짜 애자일이 된다. 칸반 보드는 있지만 모든 카드가 항상 'In Progress' 단계에 있는 회사, 스프린트 계획은 세우지만 매번 50%만 완료하는 팀, 데일리 스탠드업이 30분짜리 보고 회의가 된 조직. 이런 신호들이 보이면 애자일이 형식만 남고 본질은 사라진 상태다.

진짜 변화는 속도가 아니다

애자일이 진짜 자리잡은 조직에서 가장 크게 달라지는 것은 사실 속도가 아니다. 모두가 당당하게 "모른다"고 말할 수 있게 된다는 점이다. 우리 가설이 틀렸을 수도 있다고 빠르게 인정할 수 있게 된다. 그 솔직한 인정과 용기가 결국 그 조직이 빠르게 달릴 수 있는 진짜 이유가 된다.

경력이 가장 많은 선임연구원에게 늘 정답을 구하던 팀이, 이제는 거꾸로 그로부터 날카로운 질문을 받고 스스로 답을 찾아야 하는 구조로 바뀐다. 처음에는 어색하지만, 그 질문과 답들이 쌓이면서 회고 미팅의 성격이 달라진다. 과거처럼 지난 2주의 성과를 변명하듯 보고하는 자리가 아니라, 다음 2주를 더 효율적으로 설계하는 자리가 된다.

속도는 애자일의 결과지 본질은 아니다. 본질은 빠르게 틀릴 수 있는 용기에 있다. 모르는 것을 모른다고 말하고, 가설이 틀렸다는 데이터가 나오면 빠르게 방향을 바꾸는 문화. 이 문화가 자리잡은 조직이 결국 가장 빠르게 좋은 제품을 만든다.

우리 회사 진단해보기

협업 인프라, 리더십 의지, 고객 피드백 채널, 회고 문화의 성숙도를 16문항으로 점검할 수 있다.

→ 애자일 도입 준비도 진단 (16문항, 무료) — /diagnose/agile-readiness

참고문헌

¹ Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, 1-9. ² Beck, K. et al. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org/ ³ Kniberg, H. (2014). Spotify Engineering Culture - Part 1. Spotify Engineering [Video]. ⁴ Linders, B. (2016). Don't Copy the Spotify Model. InfoQ.