애자일 선언이 나온지는 정말 오래되었지만 현재도 많은 기업들이 ‘애자일(Agile)’을 도입하고자 고민하고 있습니다. 애자일은 빠르게 변화하는 시장 속에서 민첩하게 대응하고, 고객 중심의 제품을 빠르게 출시할 수 있도록 돕는 개발 방법론이죠. 때문에 애자일을 도입하면 개발속도가 빨라지고 효율이 올라갈 것이라고 기대하고 도입하게 됩니다. 스탠드업 미팅을 하고, 칸반보드를 쓰고, 스프린트를 나누고, 회고를 합니다. 그런데 왜 속도는 그대로일까요? 현실은 이상과 다릅니다.
“애자일을 도입했는데 왜 작업 속도는 그대로일까?”
“우린 매일 스탠드업 미팅도 하는데, 왜 애자일처럼 안 돌아가지?”
왜 제품 방향은 여전히 바꾸기 어렵고, 결정은 위에서만 이루어지며, 현장의 피드백은 흘러가지 않을까요? 이는 어쩌면 당연한 결과입니다. 많은 조직이 애자일이라는 단어만 도입했을 뿐, 문화와 원칙은 도입하지 않았기 때문입니다. 애자일은 "프로세스"가 아니라 "문화"이기 때문입니다. 단순히 개발하는 프로세스를 바꾸기만 한다고 해서 애자일 조직이 되는 것은 아닙니다. 애자일의 이름만 빌려 쓰고, 실제로는 기존 관료적·통제 중심 문화를 그대로 유지한다면 아무리 절차를 따라도 결과는 달라지지 않습니다.
그렇다면 ‘우리 조직’은 애자일에 맞는 조직일까요? 애자일의 12가지 원칙을 기준으로 하나씩 점검해 보고자 합니다.
“고객을 만족시키기 위해 초기부터 지속적으로 가치 있는 소프트웨어를 빠르고 자주 전달한다.”
우리는 고객 피드백을 자주 듣는가?
그 피드백이 제품에 얼마나 자주 반영되는가?
위에 질문에 자신있게 대답할 수 있는 조직인가요? 애자일의 본질은 고객의 가치를 빠르게 확인하고, 방향을 조정하는 것입니다. 불필요한 기능을 줄이고, 고객에게 의미 있는 핵심 기능을 빠르게 전달해야 합니다. 고객을 자주 만나지 않고, 고객 피드백을 듣지 않고 내부 논리로만 제품을 만드는 조직은 애자일이 아닙니다. 우리는 생산자 입장에서 제품을 개발하고 있지 않는 지 항상 점검해봐야 합니다.
“요구사항의 변경은 언제라도 환영한다. 심지어 개발 후반에도.”
우리는 의사결정이 바뀌는 것을 자연스럽게 받아들일 수 있는가?
전략이나 우선순위를 바꾸는 데 얼마나 복잡한 절차가 필요한가?
애자일 조직은 변화에 강합니다. 시장의 요구, 고객의 반응에 따라 결정이 바뀌는 걸 "실패"가 아닌 "조정"으로 받아들입니다. 하지만 많은 조직은 한 번 정해진 방향을 바꾸기 어렵고, "번복 = 무능"이라는 낙인이 찍히는 문화를 가집니다. 그런 문화는 애자일과 어울리지 않습니다.
“작동하는 소프트웨어를 몇 주 간격으로 자주 제공한다.”
우리는 몇 주 간격으로 실제 사용자에게 기능을 전달하는가?
배포 프로세스는 얼마나 간소화되어 있는가?
빠른 배포를 위해서는 기능이 모듈화되어 있어야 하고, 배포 과정이 자동화 혹은 단순화되어 있어야 합니다. 하지만 여전히 각 절차가 길다면 속도는 나올 수 없습니다.
“비즈니스 담당자와 개발자는 매일 함께 일해야 한다.”
비즈니스와 개발이 얼마나 자주 이야기하는가?
비즈니스 목표가 제품 목표와 분리되어 있진 않은가?
애자일은 제품을 중심으로 움직입니다. 매출이나 전략보다 더 중요한 건 "고객 문제 해결"입니다.
이해관계가 다른 부서가 서로 다른 방향을 보고 있다면, 그 조직은 애자일이 아니라 사일로입니다.
“프로젝트를 성공시키는 데 필요한 환경을 제공하고, 그들을 신뢰하여 일을 맡긴다.”
우리는 구성원에게 권한을 주고 있는가?
책임은 지게 하면서 결정권은 주지 않는 구조는 아닌가?
애자일은 소규모 팀이 자율적으로 빠르게 움직이는 방식입니다. 보고를 위한 문서가 많고, 결정을 위해 다단계 승인을 받아야 한다면 그 팀은 이미 "애자일이 불가능한 구조"입니다. 개개인에게 오너십을 줄 수 없는 조직 환경, 상하관계가 분명한 환경은 애자일에 적합하지 않습니다.
“정보 전달의 가장 효과적인 방법은 직접적인 대면 대화이다.”
중요한 논의가 슬랙과 메일로만 오가지 않는가?
기획, 디자인, 개발자가 함께 같은 방에서 대화할 수 있는가?
기술보다 중요한 건 커뮤니케이션입니다. 의미는 컨텍스트 속에 있고, 말투, 표정, 상황 속에 숨어 있습니다. 애자일은 빠른 의사소통을 위한 ‘물리적 거리 제거’가 핵심입니다.
“작동하는 소프트웨어가 프로젝트 진척을 나타내는 주된 척도다.”
우리는 실제로 작동하는 결과물을 기준으로 진척도를 측정하는가?
스펙 문서, 피그마 화면, 로드맵을 진척도로 착각하고 있진 않은가?
"100% 스펙의 80% 구현"은 애자일에서는 의미가 없습니다. "80% 스펙의 100% 구현"이 진짜입니다. 애자일은 고객이 "써볼 수 있는" 제품을 기준으로 판단합니다. 이게 되야 고객 피드백을 사전에 확인할 수 있게 됩니다.
“스폰서, 개발자, 사용자는 지속 가능한 개발 속도를 유지해야 한다.”
우리는 번아웃 없이 지속 가능한 리듬으로 일하고 있는가?
한 번 잘하는 게 중요한 게 아닙니다. 지속 가능하게 잘하는 게 중요합니다. 야근과 주말근무가 반복되는 조직은, 애자일이 아니라 ‘압축 성장 조직’입니다. 애자일 조직은 시장에 반응할 수 있도록 지속가능한 업무 형태를 지향합니다. 때문에 이를 위한 생산성 측정 (스토리 포인트, 번다운 차트 등)을 중요시 합니다.
“지속적인 기술적 탁월성과 좋은 설계가 민첩성을 향상시킨다.”
기술 부채를 얼마나 관리하고 있는가?
리팩토링이나 설계 개선에 얼마만큼 투자하고 있는가?
애자일은 눈앞의 속도보다, 유지 가능한 속도를 중시합니다. 간혹 일단 시장반응을 "빠르게"봐야하니 "빠르게" 구현하기 위해 작동하게만 구현하자! 라는 생각으로 접근하는 조직도 있습니다. 하지만 이러한 구조는 결국 기술 부채로 쌓입니다. 결국 리팩토링을 할 수밖에 없는 상태에 이르면 속도를 낼 수 없는 조직이 됩니다.
“하지 않아도 될 일을 최대한 줄이는 것이 핵심이다.”
우리는 제품에 꼭 필요한 기능만 만들고 있는가?
보고와 관리, 문서화가 일 자체보다 많진 않은가?
업무를 위한 업무는 줄여야 합니다. 운영, 관리, 반복 업무가 자동화되어 있지 않다면 그 조직은 여전히 "일이 많은 조직"일 뿐입니다. 애자일은 "복잡한 조직"이 아니라 "똑똑한 조직"을 지향합니다. 보고를 위해 보고서를 만든다거나 관련성이 없는 다수의 일을 병렬로 진행한다거나 내부를 설득하기 위해 에너지를 너무 많이 쏟는 조직은 애자일과 어울리지 않습니다.
“최고의 설계, 요구사항, 아키텍처는 자기 조직화된 팀에서 나온다.”
우리는 팀이 스스로 의사결정할 수 있는 구조인가?
항상 윗선의 허락을 받아야 하는 구조는 아닌가?
누군가가 시키는 대로만 일하는 팀은 절대 최고의 결과를 낼 수 없습니다. 책임과 권한이 함께 있어야 합니다. 실패에 인색하여 추긍하는 조직은 그 누구도 시도하지 않습니다.
“팀은 정기적으로 어떻게 더 효과적으로 일할지 성찰하고 개선한다.”
우리는 ‘회고’를 정기적으로 하고 있는가?
그 회고가 ‘변화’로 이어지고 있는가?
애자일은 매번 개선하는 팀을 지향합니다. 고장이 나기 전에 미리 점검하고, 더 좋은 방법을 실험해봅니다. 회고가 없다면, 개선도 없습니다. 회고가 잦아야 오늘보다 1mm만큼이라도 더 나은 내일을 만들고 이게 반복되어야 생산성이 향상되게 됩니다.
이 글을 통해 애자일에 대한 오해를 바로 잡고 싶었습니다. 그렇다고 애자일이 무조건 좋다고 이야기하고 싶었던 것도 아닙니다. 각 조직이 처한 환경이 다르기 때문에 각자 조직에 맞는 문화를 더 잘 찾기 바라는 마음이었고, 무엇보다 애자일을 도입하고자 하는 여러 조직들이 스스로를 진단하며 신중하게 접근하길 바라는 마음이었습니다. 애자일은 "빠르게 일하는 방법"이 아닙니다. "더 나은 가치를, 더 유연하게, 더 고객 중심적으로 일하는 문화"이자 "철학"입니다. 프로세스를 따라 한다고 애자일이 되는 것이 아닙니다. 이 원칙들이 조직문화에 녹아 있지 않다면, 그 애자일은 껍데기에 불과합니다.
이 글을 읽는 지금 당신의 조직은 얼마나 애자일한가요?
애자일과 관련된 좋은 글들이 있어 같이 읽어보시면 도움이 될 것 같아 추천드려봅니다!
- https://yozm.wishket.com/magazine/detail/917/
- https://yozm.wishket.com/magazine/detail/2474/