brunch

라이킷 11 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 신황규 Hubert Mar 12. 2021

8장. 애자일팀의 지속적인 개선#3

#8-3 프로젝트 형태에 따른 애자일 개발

#8-3 프로젝트 형태에 따른 애자일 개발

필자의 회사는 대부분의 국내 대기업이 그렇듯이 '관리'라는 것을 매우 중요하게 생각해 왔다. 회사는 지난 30년간 국내 SI사업을 하는 IT기업 중 한 번도 1위를 놓치지 않았다. 이 배경에는 만드는 것보다 지키는 것을 잘하는 관리를 잘하는 문화가 있었다. 때문에, 회사의 가장 높은 순위에 있는 문화는 통제였다.

'통제'라는 단어가 독자들에게 부정적으로 와 닿을 수 있다. 하지만 획기적인 변화가 필요할 때 조직 문화 측면에서 보면 '통제'는 긍정적인 면도 존재한다. 통제는 계층 조직을 기반으로 동작하므로 통제 조직 안에서는 리더가 조직의 문화를 제한할 수도 있지만, 만들어 갈 수도 있다. 조직의 변화를 위해서 가장 상위의 리러의 스폰서십을 받으면 조직 전체를 변화시킬 수 있다는 의미가 된다.

스위스의 철학자 에드가 쉐인은 그의 책 '조직문화와 리더십'에서 다음과 같이 말했다.

"조직 문화는 리더들에 의해 만들어진다. 그리고 리더십에서 가장 중요한 의사결정 기능은 문화를 만들고 관리하는 것이고, 정말 필요한 순간에 파괴하는 것이다"

[에드가 쉐인]

우리는 7장에서 다룬 애자일 팀을 만드는 과정을 통해 가장 상위 리더에게 스폰서십을 받는 데 성공했다. 그 리더는 후배들의 이야기에 늘 귀를 기울이는 사람이었다. 애자일의 방식과 조직 문화의 개선 방안에 대해 이야기할 때, 후배들의 힘든 점을 듣고, 개선하고자 하는 의지를 긍정적으로 평가해 주었다.

이 강력한 스폰서십을 기반으로 우리는 앞 절에서 설명한 문화, 기법, 시스템의 세 가지 측면에서 접근했다. 이 시도는 회사 내에서 커다란 변화들을 만들기 시작했다. 가장 먼저, 처음으로 회사 전체에 ‘애자일'이라는 용어가 전면에 붙여졌다. ACT라는 조직처럼 나머지 조직들도 변화해야 한다는 이야기가 전사에 퍼졌다.

강력한 스폰서십 덕분으로 많은 조직들이 ACT와의 협업을 수행했다. 가장 상위의 리더가 하자고 하니, 그 하위의 리더들도 애자일 관련 활동들을 하겠다고 나섰다. 첫 해 1년간 20개 이상의 협업 프로젝트가 만들어졌다. 이러한 수요를 감당하기 위해 3개월에 한 번씩 ACT의 인원을 조금씩 늘려나가며 애자일 핵심 멤버들을 내부/외부에서 채용하며 모았다.

20개의 프로젝트를 수행하면서 P사에서 해왔던 것처럼 늘 12명 이하의 작은 팀 중심으로 짝으로 일했다. 애자일 문화의 확산이라는 목표가 이 짝으로 일하는 것을 쉽게 합리화해주었다. 과거 존재했던 '애자일은 대형 프로젝트에서 안돼'라고 이야기되었던 내용들은 스폰서십에 가려 들리지 않았다. 작게 자르면 된다고 논리가 만들어졌다. ACT와의 협업 전에 협업 후 자신의 부서에 돌아가서 동일한 형태로 일하고 이를 확산한다는 내용의 다짐을 받고 협업 프로젝트를 시작했다.

기본적으로 기획자 1, 디자이너 1, 개발자 3의 5명의 P 사의 애자일 방식에 익숙한 코치들과 각 프로젝트의 오너들 중 이들과 짝으로 일할 또 다른 기획자 1, 디자이너 1, 개발자 3명을 데려왔다. T사와의 전문가들의 조언을 듣고, 늘 코치들이 개발하러 온 인력들과 동수 이거나 더 많은 수가 참여할 수 있도록 했다. 또한 마치 P사처럼 대부분의 프로젝트에서 새로 꾸민 사무실에 와서 일해야 한다는 원칙을 지켰다.

[린스타트업 + 디자인 싱킹 + 애자일]

20개의 협업 프로젝트는 대부분 솔루션과 관련된 개발이었다. 빠르게 시장검증을 수행하면서 MVP(Minimum Viable Product)를 만들어야 하거나 고객과 계약이 된 후 기존 솔루션에 기능을 추가하는 형태의 일들이었다. 아주 일부 SI 구축형, 운영 유지보수 프로젝트가 있었으나, 이는 1~2개밖에 안 되는 소수였다. 최초에는 모든 협업 프로젝트에 P사의 일하는 방법을 가능하면 그대로 도입해보려고 했다.

수파리(앞절에서 설명)의 ‘수’ 단계처럼, 프로젝트의 오너로 온 인력들에게는 철저하게 ACT가 수행하는 기법들을 따라야 한다고 말했다. 이 기법은 린스타트업 + 디자인 싱킹 + 애자일 프로세스에서 온 것이었으며, 적절한 툴들과 함께 사용했다. 이를 통해 사용자에게 친숙한 화면을 만들고 언제나 배포 가능한 소프트웨어를 만들면서 시장에 다가가려 했다.

[ACT의 확장]

60% 정도의 프로젝트로부터의 반응은 긍정적이었다. 협업에 참여했던 기획자, 디자이너, 그리고 개발자들은 이러한 협업 방식에 대해 행복했고 좋은 제품을 만든 경험을 했다고 말했고, 그들은 현장에 가서도 동일한 방법으로 이 일을 계속하고 싶다고 말했다. 마치 ACT의 초기 멤버들이 미국에서 P사와의 협업을 통해 경험했던 그것과 비슷한 반응이었다.

MVP를 만들 때는 사용자를 만나고, 테스트 코드로 보호된 코드를 통해 사용자의 피드백을 언제든 두려움 없이 수정할 수 있었다. 팀이 함께 고민하고 ‘홀팀(Whole team)’으로 소프트웨어를 만들었다.

MVP의 경우 SaaS 형태이든 온프라미스 형태이든 B2B 개발에서도 아래 표에서 볼 수 있는 것처럼 다양한 린스타트업 + 디자인 싱킹 관련 프랙티스들이 가능했다. 잠재 사용자를 만나고 이들을 통해 가정을 테스트하고, 경험하고 버리고, 수정하고, 만들고 하는 것들을 계속해서 해나갈 수 있었다. 이때 가장 중요한 목표는 고객의 확보이기 때문에 영업, 마케팅, 기획은 3위 일체로 협업하며 고객을 확보하기 위해 노력했다. 그리고 잠재 고객 대상으로 끊임없이 데모를 수행했다. 잠재 고객을 만나 설명하고 해당 솔루션을 통해 고객의 힘든 점을 어떻게 극복할 수 있는지 또는 현재 상황을 더 개선할 수 있는지 이야기했다.

MVP개발 시 무엇보다 좋았던 것은 개발팀의 속도를 존중해 줄 수 있다는 것이었다. 기획자, 디자이너, 개발자가 노력하여 제품을 만드는 속도를 최대라고 생각하고 일을 수행했다. 칸반을 통해 속도를 유지하면서, 병목을 찾아내 없애 나가고 이를 통해 지속적인 개선을 했다.

[B2B MVP 개발 vs. 솔루션 제품 개발]

하지만 이외 40% 정도의 프로젝트에서는 파열음이 날 정도로 일하면서 마찰이 생겼다. 주로 기획자들과 프로덕트 오너들과의 마찰이었다. 프로덕트 오너 또는 이들 바로 위에 있는 중간 관리자들은 이 기법들이 현실을 반영하지 못한다고 말했다. ACT의 일하는 방법은 너무 유연함이 없고 이상적이라 말했다. 사실 당시 ACT에게 유연함이 없는 것은 사실이었다.

ACT의 구성원들은 모든 경우에 동일한 방법으로 프로젝트를 성공시키고 좋은 소프트웨어를 만들 수 있다고 굳게 믿고 있었다. 모든 소프트웨어의 사용자의 경험이 중요하다고 생각했고, 소스코드의 품질은 반드시 지키고, 테스트 코드도 만들어야 한다고 했다. 그리고 짝으로 개발하면 더 좋은 퍼포먼스가 날 수 있다고 주장했다

먼저, 어느 주요 특정 고객과 솔루션 딜리버리 계약을 하는 순간 P사의 방식을 그대로 적용하기에는 다양한 측면에서 문제가 있었다. 예를 들어 만약에 온프라미스 형태로 고객과의 계약이 완료되면, 이때부터는 서비스 딜리버리 형태로 일하는 방법의 변화가 필요했다. 현실 속에서 일반적으로 기능을 다 갖추고 고객과 계약을 하는 경우는 별로 없기 때문에 사업적 의사결정으로 갑자기 판매를 위한 기능 개발을 완료하는 것이 무엇보다도 중요해졌다. 즉, 빠르게 특정 고객이 원하는 기능 위주의 개발을 하게 됐다.

이 때는 이전에 중요시하던 사용자에 대한 고민을 줄이고, 제품 오너가 가진 제품에 대한 철학을 버리지 않되, 고객이 원하는 기능 개발에 집중하게 됐다. 그러다 보면 린스타트업 + 디자인 싱킹의 기법들의 일부를 이전처럼 수행할 수 없는 상황이 벌어졌다. 예를 들어 사용자의 경험을 확인하기 위해 일주일에 2~3회씩 사용자 리서치와 검증이 크게 필요하지 않았다.

대신에 좀 더 적은 빈도로 확실한 사용자를 만나 리서치와 검증했다. 코드의 경우는 늘 튼튼하게 테스트 코드를 먼저 짜고 코드의 품질을 지키던 방식에서, 일부 기능을 먼저 만들고 나중에 테스트 코드와 함께 리팩터링을 해야 하는 경우들이 생겨나기 시작했다. 특히, 타 팀과 협업을 해야 하는 경우는 서로 간의 의존성 때문에 일부 기법을 더 많이 포기할 수밖에 없었다.

또한 개발팀의 속도보다 언제나 더 빨리 기능을 만들어야 하는 일이 일어났다. 때문에 칸반보다 스크럼을 선호했다. 칸반은 개발팀의 속도가 기준이 되는 관리 방식이나, 스크럼은 한 달 단위로 목표를 세울 수 있었다. 스크럼이라는 말은 팀에게 보다 스트레스를 주는 용어였다. 특히나 여러 고객과의 계약이 되는 경우는 이보다 훨씬 더 큰 압박이 되었다.

솔루션 개발이 아닌 SI 구축형 사업에서는 이 문제가 더 강하게 발생했다. SI 구축형 사업에서는 코드의 품질보다 고객과의 약속 즉, 온타임 딜리버리를 지키는 것이 가장 중요했다. 가장 다른 점은 외주 직원들과 일하는 것이었다. 이들에게 사용자를 계속 만나며 테스트 코드를 짜 달라고 하더라도 이러한 역량을 가진 이들을 찾기가 매우 어려웠다. 이들과는 현장관리자를 통해 커뮤니케이션하면서, 마일스톤 별로 목표를 명확히 하여 진척 관리하고, 팀이 자율과 책임을 가지고 일하기보다는 관리 중심으로 제품을 만들게 되었다. 초기에 구축한 아키텍처 표준을 크게 존중해야 하는 것도 달랐다.

[B2B 솔루션 제품 개발 vs SI 구 축형 개발]

타입별 프로젝트 수행에 대한 방법이 조금씩 달라야 한다는 것은 해보지 않고서는 알기 어려운 일이었다.

최초 P사 방식으로 모든 프로젝트에 접근했던 ACT 구성원들에게는 모든 것이 생소했다. 상황을 이해하고, 유연하게 방안을 만드는 것이 쉽지 않았다. ‘수파리’에서 ‘파’로 가는 일은 생각보다 어려웠다. 애자일 조직을 천명하며 유연한 조직이라 스스로 이야기했지만, ACT도 조직 내 다른 사람들처럼 유연하지 않았던 것이다.

그러면서 ACT가 일하는 방법에 대해 비난하는 사람들이 생겨나기 시작했다. 기존 조직과 달라도 너무 다른 조직문화의 차이가 문제였다. ACT는 현실을 무시하고 이상만 추구한다는 이야기가 들렸다. 이를 패턴으로 고민하여 마이클 사호타의 그림으로 설명하면 아래와 같다.

첫 번째 그림은 ACT는 “애자일 정말 좋으니 우리와 함께 하자”라는 말로 다른 조직들에 제안하는 상황을 말한다. 다른 조직과 매우 성격이 다른 형태의 조직이 생겨난다. 다른 조직이 이곳과 협업하면서 ACT의 문화와 일하는 방법을 체득하려고 했으나, 현실적인 문제를 해결하지 못하는 것을 발견했다.