Show Cover Slide

우리의 애자일, 정말 ‘애자일’한가요?

스프린트는 돌고, 회의는 정기적으로 열립니다.

백로그도 깔끔하게 정리되어 있죠.

하지만 매번 스프린트의 목표를 잡지 못해 난항을 겪습니다.

만들겠다는 제품은 있지만, 무엇을 먼저 시작해야 할지 모르겠고
그보다 더 근본적으로, 우리는 왜 만들어야 하는지조차 모르고 있었습니다.

만드는 이유인 고객은 어디에 있을까요?

회의에도, 백로그에도, 그리고 PM의 설명 속에도
‘고객’은 없었습니다.

그 순간, 저는 스스로에게 물었습니다.

“우리의 애자일, 정말 ‘애자일’한가요?”

애자일은 일정을 쪼개는 기술이 아니다

많은 팀이 애자일을 도입하면서, 그 형식을 갖추는 데 집중합니다.
데일리 스크럼, 스프린트 회고, 칸반보드, 백로그 관리…

하지만 이 과정에서 “무엇을 만들 것인가“보다
“일정대로 만들 수 있는가“가 우선이 되면,
애자일은 단지 업무 통제 도구가 되어버립니다.

“이 제품의 고객은 누구이며, 어떤 문제를 겪고 있는가?”

고객 정의는 리더의 책임이다

그래서 저는 리더로서 가장 단순한 질문부터 다시 꺼내기로 했습니다.

“개발자인 내가 직접 쓴다면, 어떤 기능이 필요할까?”

이 질문을 출발점 삼아, 팀원들과 함께 내부 사용자의 관점으로 접근해보기 시작했습니다.
실제 제품이 사용될 맥락과 상황을 상상하며 고연령대 부모님, 프랜차이즈 점주 등 현실에 존재하는 사용자 기반의 페르소나를 정의했죠.

그리고 이 페르소나를 바탕으로 시나리오를 만들고 작동 가능한 프로토타입을 만들어 내부 사용자에게 공유했습니다.

“우리 엄마는 이거 못 써요.”
“점주는 이 화면 넘기기 어려울 것 같은데요?”

이건 단순한 UI 피드백이 아니었습니다.
고객의 맥락이 팀 내부로 처음 들어온 순간이었죠.

그때부터 우리는 ‘어떤 기능을 만들까?’보다 ‘누구를 위한가?’를 먼저 묻는 팀으로 바뀌었습니다.

2주 스프린트 대신, 2일짜리 실험

더 빠른 검증을 위해 저는
2주 스프린트 대신, 2일마다 작동 가능한 프로토타입을 공유하는 구조를 제안했습니다.

목표는 ‘완성’이 아니라, 확인할 수 있는 작은 러닝 가능한 코드를 만드는 것이었습니다.

우리가 고객에게 의미 있는 방향으로 가고 있는가?

팀원들의 반응은 다양했습니다.
어떤 사람은 매 2일마다 결과물을 공유했고,
어떤 사람은 “다음 주기에 공유하겠다”고 했습니다.

저는 이 차이를 문제 삼지 않았습니다.
익숙하지 않은 방식에는 적응 시간이 필요하고, 그 과정도 애자일의 일부이기 때문입니다.

그렇게 실험을 반복하면서 실행력이 높은 인원들이 중심이 되는 흐름이 생겼고, 모든 구성원이 고객 관점으로 기능을 보기 시작했습니다.

애자일은 결국, 리더십의 철학이다

저는 지금도 애자일을 좋은 방법론이라고 생각합니다.
하지만 애자일이 진짜로 작동하려면 문화와 철학이 함께 따라와야 한다고 믿습니다.

특히 한국의 조직문화에서는 애자일이 종종 ‘일정을 통제하는 시스템’으로만 쓰이고 고객은 회의, 기능 정의, 피드백 루프 어디에서도 지워져 있는 경우가 많습니다.

애자일은 조직이 학습하고, 검증하고, 방향을 수정할 수 있도록 돕는 구조여야 합니다.

그리고 그 구조는 리더의 질문에서 시작됩니다.

“지금 우리가 만드는 이 기능, 누군가에게 정말 의미가 있을까?”

이 질문을 포기하지 않는 한, 애자일은 언제든 다시 살아날 수 있다고 믿습니다.