HR매거진 인사기획

실리콘밸리에서 온 소프트웨어 개발 방식인 애자일 기법이 우리 기업 환경과 잘 맞는지 의문을 제기하는 사람도 있지만 제품을 통해 끊임없이 실험하고 소통하자, 일들을 작게 나누어 협동하자, 일정한 속도로 끝이 없이 가자와 같은 애자일 원칙에서 배울 수 있는 모든 분야에 적용할 수 있는 교훈 또한 분명 존재한다. 우리가 주목해야 할 것은 그 부분이다.

애자일은 소프트웨어 개발 원칙이다. 지금까지 모든 제조업은 설계를 마치고 물건을 만들어 시장에 내놓아야 했다. 그리고 한 번 설계를 마친 제품은 대부분 1년 정도의 사이클로 업그레이드를 했다. 스마트폰도, 자동차도, 냉장고도 어떤 해에 만든 모델인지로 업그레이드 버전을 매겼다. 이러한 제조업의 방식을 워터폴 모델이라고 한다.

처음에는 소프트웨어도 그런 식으로 개발했었다. 윈도우 95, 98 등 연도를 딴 이름을 가지고 몇 년에 한 번씩 업그레이드를 했다. 그런데 인터넷이 발달하고 웹과 모바일 앱이 일반화 되면서 업그레이드의 주기가 점점 짧아졌다. 필자가 일하고 있는 에어비앤비의 웹페이지는 하루 150번 정도 업데이트된다. 모든 개발자가 자신이 만든 변화를 수시로 디플로이(Deploy, 서버에 업데이트)할 수 있다. 구글, 페이스북, 인스타그램, 트위터 등의 앱도 각자 차이가 있지만 아무리 늦어도 2주일에 한 번씩은 업데이트가 진행된다. 

이러한 인터넷 혁명으로 소프트웨어는 기존의 제조업의 방식과 다르게 아주 빠르게 제품을 개발하고 시장의 피드백을 수집하는 방법을 만들게 됐다. 이러한 새로운 개발 방식에 대한 필요는 2001년 애자일이라는 소프트웨어 개발 선언으로 이어졌다.

애자일 소프트웨어 개발 선언
 

우리는 소프트웨어를 개발하고,

또 다른 사람의 개발을 도와주면서

소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.

이 작업을 통해 우리는 다음을 가치 있게

여기게 됐다.

공정과 도구보다 개인과 상호작용을

포괄적인 문서보다 작동하는 소프트웨어를

계약 협상보다 고객과의 협력을

계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다.

이 말은, 왼쪽에 있는 것들도 가치가 있지만,

우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

애자일 소프트웨어 방식은 고객과 협상 끝에 계약을 맺고 설계를 해서 데드라인까지 프로젝트를 마쳐서 납품하는 모델을 지양한다. 대신 고객과 협력하고 끊임없이 소통하며 작동하는 프로토타입을 만들어서 끊임없이 진화하고 외부의 변화와 고객에 반응에 따라 끊임없이 진화하도록 만든다.

이러한 애자일은 왜 혁신에 유리할까? 워터폴 모델에서 처음부터 설계를 하고 만드는 제품은 설계를 하는 순간 한계가 명확해진다. '자동차를 만들자'라고 하고 설계를 마치면 결과는 자동차일 수밖에 없다. 반면 애자일 방식은 스펙에 맞는 제품을 만드는 것이 아니라 목적을 이루는 것을 목표로 한다. '인류의 이동을 편하게 하자'와 같은 문제 해결을 목표로 한다. 이러한 경우 처음 스케이트보드부터 만들기 시작하고 시장의 반응을 보면서 킥보드도 만들고 자전거도 만든다. 워터폴 모델보다 훨씬 더 긴 시간이 걸려서 자동차를 완성할 수 있을 것이다. 그렇지만 이들의 진화는 여기서 끝나지 않는다. 인류의 이동을 편하게 하기 위해 고속철도도 만들고 우주선도 만들 것이다. 이렇게 끝이 정해져 있지 않은 애자일은 끝없는 혁신을 만들어 낼 수 있다.

애자일이 우리나라 현실과 맞아?

우리나라 소프트웨어 개발 시장은 고객이 원하는 내용을 자세히 써서 스펙을 주면 데드라인 안에 끝내는 것을 원칙으로 한다. 특히 한정된 예산으로 프로젝트를 진행하는 정부 프로젝트의 경우 더더욱 그러한 모델에 맞추어 일하게 된다. 그러한 프로젝트와 애자일은 맞지 않는다. 고객이 끊임없이 진화하는 소프트웨어가 아닌 스펙에 딱 맞는 가전제품 같은 소프트웨어를 원한다면 애자일 방식으로 개발을 할 수는 없다.

물론 데드라인이 있는 프로젝트에도 애자일 방식에서 활용되는 프로젝트 관리 도구를 사용할 수는 있다. 스크럼, 스프린트, 플래닝 미팅 등 애자일 원칙을 활용한 관리도구들은 매우 편리한 프로젝트 관리 환경을 제공한다. 그렇지만 데드라인까지 설계가 이미 나와 있는 소프트웨어를 개발하는 워터폴 모델에 애자일 도구를 활용한다고 해서 애자일 개발을 하고 있다고 할 수는 없다.

애자일이 우리나라 현실에 적용되기 위해서는 발주 시부터 제품이 아닌 문제 해결을 목표로 소프트웨어 계약이 이루어져야 한다. 식당 관리 소프트웨어를 예로 들면 워터폴 방식의 소프트웨어는 이렇게 발주가 된다.

"고객 관리가 가능하고, 예약 관리가 가능하고, 테이블 관리가 가능하고, 결제 시스템이 갖추어진 태블릿 컴퓨터에서 실행할 수 있는 식당 관리 소프트웨어를 만들어주세요."

애자일 방식에서는 이렇게 발주가 된다.

"우리 식당을 멋지게 관리할 수 있는 소프트웨어를 만들어주세요."

워터폴 방식에서는 누구나 생각할 수 있는 뻔한 소프트웨어가 데드라인에 맞추어 고객에게 인도될 것이다. 그 팀에서 일한 개발자와 디자이너는 늘 하던 제품 개발을 또 하게 될 것이다. 반면 애자일 방식으로 발주한 소프트웨어는 개발자와 디자이너의 역량에 따라 세상에서 하나밖에 없는 소프트웨어가 나올 것이다. 고객의 니즈를 계속 분석하면서 전화가 오면 구글 어시스턴트가 자동으로 예약을 받을 수도 있고 안면 인식으로 손님을 안내하는 시스템을 만들지도 모른다. 테이블마다 비치된 태블릿을 이용해 주문을 할 수도 있고 아니면 입장 시에 자동 주문 시스템에서 주문을 하게 만들 수도 있다. 가능성은 무궁무진하다. 이제 시작이다. 엔지니어와 디자이너와 프로덕트 매니저는 새로운 도전에 신이 날 것이다.
 

고객이 애자일 방식으로 개발된 소프트웨어를 원하지 않는다면 애자일은 의미가 없다. 그렇지만 많은 사람들이 애자일 방식으로 개발한 소프트웨어와 그렇지 않은 소프트웨어의 품질 차이를 알게 되면 금방 애자일 방식으로 만든 소프트웨어를 선호하게 될 것이다. 그리고 애자일 방식으로 만든 소프트웨어는 개발자와 디자이너와 프로덕트 매니저의 역량에 따라 큰 품질과 고객 만족도의 차이가 발생할 것이다. 그래서 개발자와 디자이너, 프로덕트 매니저에게 '몸값'이라는 것이 생기기 시작할 것이다.
 

이러한 차이 때문에 우리나라에서 웹 개발자는 힘들고 존경받지 못하는 직업이 되지만 애자일 방식이 널리 보급된 실리콘밸리에서는 프로 선수와 같이 실력에 따라 몸값이 치솟는, 모두가 선망하는 직업이 된다.

모든 분야에 적용가능한 애자일 원칙

애자일은 소프트웨어 개발 원칙이다. 기본적으로 늘 수정이 가능한 소프트웨어의 특성을 최대한 활용해 고객과 시장의 변화를 수시로 반영하는 것이 애자일의 원칙이자 강점이다. 한번 설계가 정해지면 수정할 수 없는 워터폴 방식과는 달리 계속 진화하는 제품을 만들 수 있으며 데드라인이 없고 항상 일정한 속도로 일을 하기 때문에 번아웃이 생기지 않는다. 모든 분야에 적용할 수 있는 애자일 원칙의 교훈들은 다음과 같다.

제품을 통해 끊임없이 실험하고 소통하자

어떠한 제품이든 실제로 써 보면 느낌이 다르게 마련이다. 아무리 머릿속 생각으로는 유용한 제품도 실제로 손에 쥐어 보면 불편한 경우가 매우 많다. 시장의 반응을 보고, 또는 고객의 반응을 보고 빠르게 대처하면 계속해서 진화하는 프로덕트를 만들 수 있다. 물론 그 과정에서 고객과의 소통은 매우 중요하다. 그리고 개발하는 사람 자신이 설계나 구현만 할 것이 아니라 직접 써 보는 것도 빠르게 제품을 진화시킬 수 있는 방법이다.

제품을 시장에 내 놓는 것은 하나하나가 실험이 될 수 있다. 그래서 제품을 만드는 것만큼이나 고객들의 반응을 수집하고 분석하는 일이 중요하다. 실리콘밸리에서 데이터 과학이 주목을 받는 이유도 제품의 반응을 체계적으로 알게 되기 때문이다. 웬만큼 큰 앱에서는 사용자의 모든 행동이 다 저장된다. 데이터 과학자들은 빅데이터 기술을 통해 그 행동들을 분석하고 제품이 나아갈 방향을 제시할 수 있다.

보험 상품 설계 등에도 이러한 원칙이 적용될 수 있을 것이다. 제품을 만들어 가는 과정에서 꾸준히 고객과 만나서 제품을 설명하고 고객이 필요한 점을 이해하고 나면 어떤 것들에 신경을 쓰는지, 어떤 것들은 없어도 되는지 더 쉽게 이해해 나갈 수 있을 것이다. 책상 앞에서 생각하는 시간보다 고객과 대면하고 제품에 대해 토론하는 시간이 더 값진 시간이 될 것이다.

일들을 작게 나누어 협동하자

식당에서 음식을 주문하는 아이패드 앱을 만든다고 가정해 보자. 워터폴 방식으로 하게 되면 엔지니어 1은 메뉴 구성 화면을 만들고 엔지니어 2는 결제 페이지를 만드는 등 일을 큰 단위로 나누어서 시키게 된다. 그렇게 하면 각자 하는 일에 집중할 수 있지만 두 페이지는 완전히 나누어져 있기 때문에 서로 무슨 일을 하는지 알 수도 없고 알 필요도 없어진다. 그래서 소통도 필요가 없어진다.

애자일 방식은 일을 아주 작게 나눈다. '메뉴 페이지를 만든다'가 아니라 '메뉴 페이지의 버튼을 추가한다' '메뉴 페이지의 버튼을 누르면 선택이 되도록 한다' 등 아주 작은 동작까지 세분화 한다. 그리고 세분화된 일을 하나씩 나누어 한다. 이러한 방식으로 하면 버튼을 추가하는 사람과 버튼을 눌렀을 때 행동을 구현하는 사람은 서로 소통하지 않을 수가 없다.

그리고 서로 소통을 하다보면 각자의 다른 전문적인 시각에서 많은 피드백을 줄 수 있다. 한 사람의 눈으로만 구현하는 것이 아니라 두세 사람의 눈으로 동시에 같은 것을 구현하는 것이다. 이렇게 하면 대충 구현하고 넘어가는 일이 없어지고 높은 품질을 유지할 수 있다.

일정한 속도로 끝이 없이 가자

애자일 프로젝트는 끝이 없다. 데드라인도 없고 완료 시점도 없다. 고객이 완전히 만족할 때까지 계속 프로젝트를 진행한다. 고객이 계속 기능을 추가하고 싶으면 영원히 프로젝트를 계속한다.

그러므로 매우 장기적인 관점에서 생각해야 한다. '이것만 마치고 납품하면 당분간은 끝이다'라는 생각을 할 수가 없다. 1년 후, 2년 후 로드맵도 만들 수 있고 그 로드맵이 수정에 수정을 거쳐 새로운 무언가로 진화하는 과정을 계속 수행한다. 그리고 데드라인이 없으므로 엔지니어도 늘 같은 속도로 일하면서 자신의 삶을 예상 가능하게 만들 수 있다. 그렇게 예상 가능한 삶이 가능해지면 휴가도 갈 수 있고 자유롭게 육아와 가족과의 시간을 계획할 수 있다.

끝을 정하는 것은 데드라인을 정해 놓아서 빠르게 보일 수도 있지만 시작과 끝을 반복하는 비용은 엄청나다. 저 멀리 보이는 빛을 보면서 걸어가는 것과 100미터 마다 전력 질주를 하는 것을 반복 하는 것은 최종적으로 갈 수 있는 거리에서 엄청나게 차이가 날 것이다. 후자의 방식으로 멀리 가려면 선수를 번아웃 시키고 다른 선수로 교체하는 것을 반복하는 방법 밖에는 없다. 그렇지만 그렇게 하면 경험 많은 팀 플레이어는 계속 잃게 된다.

밖에서 보기에는 느려 보이지만 끊임없이 진화하고 방향을 바꾸어 나가는 것. 그것이 애자일이 만드는 혁신들을 제조업 마인드로는 따라올 수 없는 이유이다. 

유호현 에어비앤비 페이먼츠팀 엔지니어