[Phase#3] 어느 유지보수팀의 애자일 이야기
--
애자일은 주로 개발에만 맞는 방식이라고 이야기를 하는 경우가 있다. 이는 오해라고 생각한다. 애자일이 결국 현재 상황에서 지속적인 개선을 하자는 것이기에, 어떠한 조직에든 시도할 수 있는 것들이 있다.
달리 말하면 제약이 있기에 애자일이라는 것이 필요하다. 문제가 있으니까 개선이 필요한 것이다.
이러한 맥락으로 지금부터 현실적인 제약이 가장 많은 것으로 이야기 되는 유지보수 팀의 애자일 적용 사례를 설명해보려고 한다.
이 팀은 ‘09년에 만났다. 주로 내 선배이자 동료인 애자일 코치가 6주간 코칭을 진행했고 필자는 관찰했다. 애자일 코치는 이틀에 한 번꼴로 팀을 만났으며 진행한 코칭 시간은 한번에 1~4시간 정도였다.
“A팀은 5명으로 조직되어 있다. 이 팀의 구성은 투입된 지 1년 남짓 된 인력부터 시작해서 15년째 이 팀의 유지보수를 하고 있는 인력도 있다. 사원 1명, 대리 1명, 과장 2명, 차장 1명(A)으로 구성되어 4가지의 시스템의 유지보수를 동시에 하고 있다.
과거에는 담당하는 도메인별 시스템별 업무가 있었으나 3년 전 신규 시스템을 개발하면서, 기존의 도메인 지식을 알고 있던 몇몇 친구가 타 팀으로 전배를 가게 되어, 현재는 도메인 별 구성은 무리한 상황이다. 때문에, 주로 개발의 레이어위주로 일이 분배되어 있다. 예를들면 사원과 대리는 주로 화면 위주 개발을 하고, 과장 2명 중 한명은 서버쪽 개발을 수행한다.
또한 B과장은 인프라에 대한 관리 및 배포를 관리한다. A는 전체의 업무를 총괄한다. 이들은 4개 시스템에 대해 모든 설명을 다른 4명에게 해준다. 5명의 인원 중 4명이 주로 Hands on 일을 한다. 팀웍은 매우 좋다. 더 직급이 높은 선배들이 일을 도맡아 팀원들을 보호해주는 느낌을 주고, 문제에 대해 늘 적극적으로 커뮤니케이션 한다. 혹시나 고객의 험한 말에 상처를 주는 경우라도 있으면, 서로 동기부여해주는 일도 빈번히 일어난다.“
애자일의 시작
이 팀이 애자일을 접하게 된 것은 ‘09년이었다. A가 회사에서 요구한 강제 애자일 교육에 입과하여 교육을 받고 이 교육의 후속과제로 애자일을 현장에 적용하라는 미션을 받으면서 부터였다.
그는 교육을 통해 스크럼과 XP에 대해 배우고 익혔다. 하지만 여전히 이를 현장에 어떻게 적용 할 지 도저히 감이 잡히지 않았다.
1) 제품책임자/스크럼마스터/팀 멤버의 구성 (스크럼)
- 제품책임자는 만들어야 할 기능에 대한 우선순위화를 수행한다. 그리고 기능 목록인 제품 백로그라는 것을 늘 유지해야 한다고 한다. 하지만 현재 팀을 고려하면 과연 누가 이 프로젝트에서 제품 책임자가 될 수 있겠는가? 4개의 시스템을 사용하는 사용자인가? 아니면 예산을 확보해주는 고객 부서인가? 아니면 변경 요구사항을 늘 전달하는 시스템 관리 부서인가? 혼란스러웠다. 시스템별 전체 오너들이 모호했다.
- 스크럼마스터는 더 혼란스러운 역할이었다. 내가 잘 알고 있는 PM의 역할인가? 아니면 팀의 이슈를 관리하는 PMO인가? 팀의 병목을 해결한다고 하니, 회사에 기술리딩을 하는 아키텍트가 이런 역할을 해야 하나? 우리 팀에서 과연 누가 이 역할을 할 수 있을까, 고민스러웠다.
2) 제품 백로그/스프린트 백로그/스프린트의 적용 (스크럼)
- 스크럼에서는, 전체의 업무 목록을 제품 백로그라 하고, 한 달의 한 번 정도씩 스프린트 백로그라는 것을 통해 상세화 한다고 한다. 그리고 스프린트 백로그를 기준으로 팀 멤버들이 일하는 동안 스크럼 마스터가 주변 상황을 방어하며 계속 그 일만 수행할 수 있도록 한다고 하는데, 그런 것은 현실에 일어날 수 없는 일이었다. 하루에도 몇 번씩 다양한 루트를 통해 요구사항이 들어온다.
- 고객들은 직접 찾아오거나 전화를 통해 우리 팀에 찾아와 늘 다음과 같이 이야기 한다. “오늘까지 이 일을 반드시 끝내지 않으면 큰일이 난다” 예전에는 이들의 말이 억지스러웠지만, 오랜 시간 그들과 일하면서 그들이 그럴 수 밖에 없는 이유에 대해서도 이해하기 시작했다. 때문에 최대한 그들과 열려진 자세로 이야기를 하려면 주고 받는게 있어야 한다. 스크럼의 한 달의 타임 프레임을 가져간다는 것은, 내년에는 재계약을 하지 말아달라고 부탁하는 것이나 마찬가지였다.
3) 엔지니어링 프랙티의 적용(XP)
- 테스트 주도개발은 개발자들이 할 수 있는 것이니 먼저 진행해보려고 했으나, 테스트케이스를 먼저 만들고 개발하라니, 현재 테스트케이스가 0인 레거시를 다루는 상황에서 언제부터 어디까지 테스트케이스를 만들어야 할 지 감이 잡히지 않았다. 몇 개의 테스트 케이스를 추가 해보려고 했지만, DB의 값이 바뀌면서 되었다 안되었다 하는 Flaky 테스트가 만들어져 이를 유지보수 하는 것이 더 어려운 상황이 되었다. 또한 화면을 개발하는 인력들과 서버를 개발하는 인력으로 구성되어 있기에 각자의 테스트코드를 짜는 것도 매우 어려웠다.
- 패어 프로그래밍은 개개인의 역량이 미치지 못한다는 생각이었다. 팀 전체적으로 사원과 대리는 서버를 개발하기에는 아직 멀었다는 인식이 있었다. 그리고 무리한 패어로 그들을 가르치다가 심지어 일처리가 미루어질 것이라고 생각되었다.
애자일 코치를 만나다.
무엇을 할 수 있을까? A는 고민하다가 , 결국 사내 전문가를 부르자고 생각했다. 혼자서는 무엇을 어떻게 해야 할 지 고민하다 모양만 낸 과제를 하게 될 것 같았다. 다행히 흔쾌히 사내 전문가 애자일 코치는 팀에 찾아와 주었다.
애자일 코치는 1시간 정도 A의 고민을 듣더니, 스크럼 이라는 말, XP라는 말자체는 크게 의미가 없다고 이야기 했다. 대신에 앞으로 초점을 맞춰야 하는 것은 현재 상태의 일을 어떻게 하면 개선하고 주기적으로 팀이 함께 고민하며 그 개선의 의지를 끊임없이 가져가는 것이라 했다.
A는 이 말을 듣고 여전히 이해가 가지 않았다. “그래서 뭘 하라는 거야..?”
그는 먼저 인터뷰를 시작했다. 팀원당 30분씩 그들이 느끼는 팀에 대해 들었다. 5명에 대한 인터뷰가 모두 끝난 뒤, 사내 애자일 전문가는 A를 불러 다음과 같은 결과를 이야기해 줬다.
발견한 문제점
(1) 팀원간 커뮤니케이션 부족으로 문제점 공유미흡
(2) 업무처리 관리시스템 부재로 인한 비 효율적인 자원분배
(3) 독립적인 업무할당으로 인한 기술수준 편차 발생
(4) 수동배포로 인한 업무공수손실 및 효과적인 테스트수행 미흡
실제 팀원들과 대화를 나누어 보니 A의 생각과는 다르게 가장 먼저, (1) 정보가 팀 내에서 제대로 공유되지 않는다는 피드백이 나왔다. 팀원들은 더 많은 정보를 알고 싶고, 배우고 싶어 하는데 기회가 없다는 이야기도 있었다. 또한 A가 하는 일에 대해서는 “차장님이 늘 팀을 위해 헌신하시는데 업무 내용을 잘 몰라 무엇을 도와야 할 지 잘 모르겠다” 라는 피드백이 있었다.
또한 (2) 관리시스템에 없다는 이야기가 있었는데, 운영 시스템의 특성상 일년 중 늘 주기적으로 진행하는 일들이 있는데, 몰리는 사람에게만 업무가 몰리는 경향이 늘 반복되고 있다고 했다. 이럴 때마다, 무언가 업무 전체를 보는 뷰가 있으면 좋겠다는 고민을 했었다고 한다. 도대체 누가 얼마만큼의 일을 하는지 공유가 안되어 알고 싶다는 피드백 또한 있었다.
(3) 전체 A to Z가 아닌 화면과 서버만 개발하다보니, 늘 숲보다 나무를 보는 느낌이라는 피드백도 있었다. 이 때문에 실제 문제 해결시 마다 느낄 수 있는 성취감이 부족하다고 했다. 과장이 혼자 진행하는 배포 같은 경우는 누구도 공유할 수 없다고 했다. 배포를 담당하는 과장만 이 일을 할 수 있기에 배포가 있는 날인 매주 수요일과 금요일은 과장만 늘 10시가 넘어야 퇴근하게되는 일이 반복되고 있다고 했다.
(4) 배포 과정에서 로컬에 통합환경이 없기 때문에 서버에서 컴파일 하고 운영 서버에서 클래스를 복사하고 서버를 올렸다 내렸다 하는 형태로 배포를 하고 있다고 했다. 이 때문에 테스트를 하려면 운영서버를 잠시 쉴 수 있는 저녁 시간에 활용해야 하는데, 이 때마다 늘 야근을 하고 있다고 했다.
제안
A는 이 이야기를 듣고 약간의 현기증을 느꼈다. 늘 에너지가 넘치는 좋은 팀이라고 생각했었는데, 상황에 대해 부정적으로 대답한 팀원들의 이야기가 좀 섭섭했다.
하지만 다른 편으로는, 모두들 이들 모두 팀을 정말 사랑있다는 것을 알 수 있었다. 이제부터 이 팀이 어떻게 나아질 수 있는지에 대해 고민할 수 있다는 생각이 들었다. 섭섭함은 기대감으로 바뀌었고, 팀원들을 위해 새로운 시도를 해보고자 했다.
애자일 코치는 A와의 대화를 통해 2주씩 3회의 이터레이션을 진행해보자라고 제안했다. 그리고 그 이터레이션의 목표를 다음과 같이 잡았다.
(1) 이터레이션 #1 목표: 팀문화 조직문화의 변화를 통해 사고의 전환을 가져온다
- 스탠드업 미팅, 포스트잇을 이용한 업무내용 공유, 업무량 함께 추정, 회고를 통한 개선항목 도출
(2) 이터레이션 #2 목표: 툴을 사용하여 팀원들이 하고 있는일을 투명화한다
- Kanban 보드 활용
(3) 이터레이션 #3 목표: Engineering 부분을 특화한다.
- 지속적인 통합, 유지가능할 정도로 일하기
그리고 5명의 팀원을 모두 모아 어떻게 애자일 방식을 6주간 진행할 지 사전에 설명했다. 애자일 코치가 퍼실리테이션을 맡았고, 팀원들의 반응들은 매우 호의적이었다. 사전 인터뷰 내용 때문인지 모두들 “나의 문제를 해결할 수 있다”라는 기대감을 보였다.
2주 후 첫번째 회고를 진행했다. 스탠드업 미팅, 포스트잇을 이용한 업무공유, 업무량을 함께 추정하는 것 등을 2주간 진행했다. 다음과 같은 피드백들이 있었다.
<(2주후) 이터레이션 #1 회고 결과>
Plus: 새로운 자극/새로운 만남, 팀원간 의사소통 증가, 백로그 관리를 통해 업무처리 효율성 증가됨, 자원할당, 업무분배의 팀원 참여를 통해 업무 주도적 수행 가능, 초급 개발자의 향상된 능력 확인, 팀원간 소통 증가를 통해 팀 내 신뢰도 향상
Minus: 애자일에 대한 압박이 예상됨, 연말에 일이 몰리고 있어 부담이 될까봐 걱정됨, 업무가 추정했던 것보다 큰 일이 반복되고 있음
그리고 4주후 Tool 을 사용한 후에는 다음과 같은 피드백이 있었다.
<(4주후) 이터레이션 #2 회고 결과>
Plus: 우리팀이 점점 홀팀이 되어가고 있음, 백로그가 잘 분배되어 업무 능률이 향상되었다.
Minus: 일회성 수명업무가 다량 발생하여 업무에 집중하지 못하고 있음, 레드마인 완성도가 떨어져 자유롭게 활용할 수 없음, 여전히 애자일 관련 기법에 많은 시간이 소요됨
마지막 지속적인 통합과 패어 프로그래밍을 해본 6주 후에는 다음과 같은 피드백이 있었다.
<(6주후) 이터레이션 #3 회고 결과>
Plus: 패어 프로그래밍을 실제 적용해보니 예상외의 효과를 느낌, 패어 프로그래밍을 통해 실제 협업을 하고 있다는 느낌 나의 일이 아닌 우리의 일이라는 생각이 들음, Redmine을 통해 작업현황이 효과적으로 공유되고 있음, 초급 인력들의 개발능력이 생각보다 훨씬 나음, 배포를 돌아가면서 진행할 수 있게 됨
Minus: 패어 프로그래밍 시 너무 빠르게 피로해짐, 애자일 코치 부재시 애자일 기법의 꾸준한 실천이 어려움, 수명업무가 발생할 때 패어를 풀어야 함
6주간의 애자일 관련 활동을 하면서 가장 팀이 인사이트를 많이 받은 때는 마지막주 였다. 팀원들은 서로에 대해 다음과 같은 암묵적 가정을 가지고 있었다는 것을 깨달았다.
“직급이 낮은 인력은 서버를 개발하기에 부족한 역량을 가졌기 때문에 화면을 주로 개발한다”
6주차에 진행된 매우 짧은 4시간의 패어프로그래밍 동안 팀원들이 생각이 잘못된 것임을 확인하게 된 계기가 된 이벤트였다. 실제로 같은 업무에 대해 패어로 일해보니, 사원/대리의 개발자들도 업무를 화면부터 서버까지 진행하는데 큰 무리가 없었다.
이를 통해 팀은 진작에 이러한 일을 함께 하고 잘 분배했다면 훨씬 더 자신들이 보다 중요한 일에 시간을 쓸 수 있었을 것이라는 생각이 되었고, 후배들에게 보다 많은 배움의 기회를 줄 수 있었을 것이라는 후회를 했다.
특히 배포를 도맡아하던 B과장이 다음과 같은 고백을 했다.
“수/금요일마다 늘 10시가 넘어야 퇴근하는 일을 맡았던 것이 정말 괴로웠는데, 이제는 같이 할 수 있는 팀원들이 있다.”
6주차 부터 배포를 팀원들이 번갈아가며 진행할 수 있게되었다. 지속적인 통합 체계를 통해 로컬에서 빌드 후 개발서버에서 빌드/테스트 하고 이를 운영서버에 보낼 수 있는 장치가 그동안 배포때마다 온 몸의 신경이 곤두서는 경험을 해야 했던 과장의 고통에서 벗어나는 일을 만들었다. 또한 팀원들은 보다 Cross Functional 하게 일할 수 있는 백업체계를 갖추었다.
짧은 기간이었지만, 팀원들은 더 나아지고 싶은 의지가 있었고, 배우고 싶은 욕구가 있었다. 6주간의 실험은 그들이 성장할 수 있다는 확신을 주었고, 이후로도 계속해서 애자일 관련 실험을 계속해오고 있다.
당시 회고 진행시 필자도 함께 잇었는데, 이때의 케미는 애자일 코칭을 계속해온 필자도 쉽게 잊지 못한다. 그 만큼 팀이 나아지는 그 순간을 즐기고 있었다.
글을 마치기 전, 부가적으로 해당 팀에서 조사한 설문을 함께 공유한다.
우선은 애자일 성숙도를 코칭 전과 후로 조사해봤는데 다음과 같아. 6가지에 대해 조사 했는데, 요구사항 관리 측면(Req Mgmt), 비전 공유 측면(Shared Vision), 이터레이션 개발(Itr Dev), 사용자스토리 개발(USDD), 홀 팀(Whole Team), 애자일 만족도(Agile Sat) 였다. 5명 모두 평균 3점 이하의 점수가 나왔다. (왼쪽 그림)
두 번째로 팀이 생각하는 기술적 스킬에 대한 조사도 진행했다. 팀이 정했고 스스로 설문을 진행했다.
