[용어] 애자일? 그리고 애자일 실패, 짧은 후기

 최근 너무 게을러진 탓인지, 아니면 너무 업무가 많았던 탓인지 몇년간 글을 쓰지 않다가 너무 생각이 많아져서 몇자 적어보려 한다.

 

---

1. 실패한 애자일

 

 얼마전. 이직을 하고 들어온 회사에서 재미있는 화두가 있었다.
 이 회사가 진행하고 있는 것은 '애자일 방법론'... 뭐 일단은 두고 보기로 했다.

 애자일의 본질을 안다면, 몇가지 반드시 적용이 되어야할 내용이 있음을 알 수 있다.

 그래서 나는 회사 대표님에게 오류가 나더라도 동작하는 것을 손에 쥐어 보는게 사업성은 있을지, 실 기기(운용장비)에서 표현은 어떻게 나는지 확인하시는 게 좋을 것 같다고 이야기하였다. 애자일하게 개발을 한다기에 당연히 그런 플로우가 되리라 생각했고, 처음부터 완벽하게 개발한다는 여지는 존재할 수 없었다고 본다. (애초에 나는 개발에 완벽이 있다는 입장도 아닐뿐더러 애자일을 선택한다면 요청자/고객이 당연히 개발의 결과물을 다른 방법보다 더 빨리 보게 될 것이기 때문이다.)

 그러나 이는 지켜지지 않았고, 대표님은 어떤 화면이 나올지 디자인만 보고서 한달의 기간이 지났다.
 회의에 개발자는 빠지고 기획자와 대표님만 들어가는 일이 늘어나고 스프린터의 일정은 고무줄처럼 늘어났다.
 개발자들은 WBS를 지키지 않았고, 몇번의 수정도 했으나 역시 지켜지지 않았다.
 일부는 완벽하게 개발이 되지 않으면 진행상황을 보여줄 수 없다는 입장도 생겨났다.
 트렐로의 칸반 카드들은 초기에 몇 개 작성되는 듯 하였으나 아무도 이를 작성하는 이도 없었으며 확인도 하지 않게 되었다.
 애초에 어떤 이슈를 어떤 내용을 적을지도 몰라서 아무도 적지 않은 듯 하다.

 결국 대표님이 원하는 결과물의 수준은 되지않아 상호 신뢰를 잃게 되었다.

 

---

2. 무엇이 문제였을까?

 사실 따지고 보면 나는 고객(요청자)의 불신이 큰 역할을 했다고 보고 있지만, 불신이라고 하는 먹이를 던져준 개발팀도 결백하다고는 이야기 할 수 없다고 생각한다.

 과연 우리는 '애자일'한 개발을 하고 있었을까?
 아니, 애초에 '애자일' 그 본질은 무엇일까?
 나는 개발을 시작하는, 혹은 '애자일' 개발 프로세스를 도입하는 모든 이가 본질을 알고 도입하고 사용하며 이를 논의하는지 궁금하게 되었다.
 

 애초에 나조차 잘 알지는 못하기 때문이었을지도 모르겠다.

2.1. '애자일'

'애자일', '애자일 방법론', '애자일 프로세스', 등 다양한 표현이 존재하는데 애자일 그 뜻부터 살펴보자.

 

내가 학부생일때, 말씀을 재밌게 해서 좋아하던 교수님이 수업시간 도중 말씀하셨던 일화가 있다.

'CPU 가 뭐냐, 꼭 어디서 약자를 풀어서 Central Processing Unit 이렇게 가져오는 놈 있어. 그래서 더 물어보면 중앙 처리 장치요 이러는데 CPU가 메인보드 중앙에 있냐? 어?'

나는 이 말이 다각도로 받아들여졌다.

- 단순히 영문을 번역할 경우, 중앙 처리 장치는 맞다.
- CPU 라고 하는 것의 정의가 명확히 무엇인지 고민해 보았느냐
- 문헌들이 정의하는 CPU는 무엇이라고 하냐
- 그래서 쭉 둘러보고 난 후, 네가 알게 된 CPU는 뭐냐

그 뒤로 나는 모든 학습을 할 때, 위와 같은 복잡하고 불필요한 고민을 하고 나만의 정의가 내리긴 했다. 
그리곤 남들이 물어볼때 타당하거나 실제로 입증이 가능한 경우에는 '~같다', '~같습니다'라는 불확실성이 포함된 표현없이 말을 하게 되었다.

각설하고 '애자일'은 기민한, 민첩한 이라는 뜻이라고 한다.
민첩하다는 표현은 대체 왜, 게임에서 익히 사용된 '덱스 (dex, dexterous)'를 사용하지 않은 걸까?
매우 빠른, 갑자기, 돌연히라는 표현인 '서든 (sudden)', '서든리 (suddenly)' 로 쓰일 수도 있지 않았을까?
기민하다는 표현으로는 '어스튜드 (astute)'라는 표현도 있던데...

우선 개발 표현으로 '애자일'이 채택된 이유는 사실 알지 못한다.
우연히 최초에 사용한 사람이 입밖으로 내민 말일 수도 있고, 아니면 최초에는 전혀 다른 표현이었다가 특정 시점에서 애자일이라고 불리기 시작했을 수도 있다. MS나 ie 개발을 하면서 진행하던 프로세스 명칭을 누군가 물었을 때 적당히 답변한 것일지 엄청난 고심끝에 결정한 명칭일지는 모르겠다.

'덱스 (dex, dexterous)'는 능숙한, 솜씨좋은 이라는 의미가 있다고 한다.
따라서 다른 개발 프로세스에 비해 짧은 기간, 지속적으로 고객에게 표현되는 내용을 공유하는 '애자일'의 프로세스상 그 의미는 완전히 다르다고 볼 수 있다.

'서든 (sudden)', '서든리 (suddenly)'는 이런 곳에 사용하는 표현보다는 앞선 내용들에 변화가 생길 때 사용되는 것 같다.
행동이나 심경의 변화가 생길때 사용한다는데, 개발을 하면서 수정사항도 있고 프로젝트가 엎어지는 경우는 있어도 모든 프로세스가 매번 엎어지는 것은 아니니(아니여야 한다..) 이 표현은 아닌 것 같다.

'어스튜드 (astute)'는 기민하다는 표현도 되지만 '영악한', '약삭빠른'의 의미로 많이 쓰이나 보다.
개발자들도 직원이라 사내 정치도 하고 라인도 타고, 일머리보다 잔머리를 굴리면 승진도 빠르고 급여도 많이 받고... 여튼 그런 영악한 일면도 있는 것이 사실이겠지만 개발 프로세스를 논하는 자리에서 '어스튜드 (astute)'는 조금 맞지 않는 표현인 것 같다.

아마 상기의 표현들을 선택하지 않고 결정된 단어가 '애자일 (agile)'인 것 같다.
돌려서 말하면, 상기 단어들로 대체가 가능하면 안된다.

'애자일 (agile)'은 능숙함('덱스')이 부족할 수 있다.
'애자일 (agile)'은 갑작스러운('서든') 변화가 아닐 수 있다.
'애자일 (agile)'은 영리하거나 약삭빠른('어스튜드') 것은 아닐 수 있다.

'애자일 (agile)'은 어쩌면 능숙해질 수 없고.. 어쩌면 갑작스러운 변화가 없는, 어쩌면 조금은 '왜 이렇게 하지?' 싶은 어리숙한 것일 수 있다.

나는 '애자일 (agile)'은 방법론으로 보고 있지 않는다.

- 내가 살펴본 '애자일 (agile)'은 그 목적이 기존의 [틀]에서 벗어난 새로운 개발 패러다임으로 보여진다.
- 여기에 추후 몇가지 원칙이 더해졌다. (애자일 소프트웨어 개발 선언과 원칙)
- 소속되는 프로그래밍 절차/방법론이 대두되게 되었다고 보여진다.
 -> 예를 들면 스크럼, XP나 ASD같은 것들이 개발 방법들이라고 생각을 한다.

나는 '애자일'은 방법론 보다는 패러다임으로 보고 있고, '애자일'은 여러가지 방법론을 취사 선택하거나 융합 적용할 수 있는 보다 상위의 개념같은 것으로 여겨진다.
솔직히.. 방법론이 방법론을 가지고 있다는 말은 앞뒤가 안맞는 이치이기 때문이다.

2.2. 애자일 소프트웨어 개발 선언과 원칙

애자일 소프트웨어 개발 선언이라고 하기 내용을 먼저 확인하자.

'''

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

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
'''

[애자일 소프트웨어 개발 선언] 을 보면 왼쪽에 내용을 무시한다는 것이 아니다.
또한 가볍게 여기겠다는 내용도 아니다. 이렇게 이해했다면 완벽한 흑백논리에 잡힌 것이다.

'애자일'을 선택한다는 것이 곧 문서를 작성하지 않겠다는 이야기도 아니며, 개발 공정을 무시하겠다는 이야기도 아니다. 또한 계획을 지키지 않아도 되는 것이 '애자일'인 것은 더더욱 아니다.
이들을 모두 지켜야 한다. 반드시는 아니지만 최대한.
물론 그보다 중요한 것은 동작하는 소프트웨어를 빠르게 만들고 이를 공유해서 새로운 상호작용을 얻어야 한다.
수정/개선 사항, 오류사항을 고객/요청자(여기서는 대표님)가, 그들이 보아야 하고 그들이 선택할 수 있도록 제공할 때에 '애자일'은 신뢰 받을 수 있게 될 것이다.

그들에게 선택을 주고 우리는 시간을 얻는 것이다.
빠르게 개발한다는 것이 무조건 무리한 업무를 하는 것이 아니다.
사업적 가능성을 확인할 때에는 완벽한 개발 결과를 제공할 이유가 없다.

IR용인지, 지원사업용인지, 주주들에게 보여주는 샘플링인지, 대외 고객들에게 시연할 상품인지, 납품될 물품인지, 대고객 오픈 서비스의 론칭일지는 모르겠으나 
모든 것은 때에 맞는 일정과 인력, 비용을 계산해서 계획을 하고 투자를 하게 된다. 요즘은 옛날과 달라서 없었던 사업을 신규 오픈하는데 중간 점검(클로즈 베타)없이 시간과 돈을 내버리지 않는다.
작업의 일정을 필요한 만큼 적절히 배분하여 사업부나 대표가 사업성을 가진 프로그램인지 재검토할 수 있는 기회를 제공해야한다고 생각한다.
마찬가지로 특정 기능에 오류가 없는지, 특정 UX/UI 화면이 적합한지에 대한 평가는 많이 배운 지식의 양으로 승부하는 것이 아니라 시장에 물건을 시제품으로 던져보는게 가장 알기 쉽다.
모집단을 뽑아 테스트군을 형성하고 표본을 추출하는 일련의 일반화 추론방식은 인문통계학에서 이미 많이 사용되는 방식이다.
나는 개발자가 이러한 기회를 보다 자주 사용자 집단에게 제공하는, 또한 제공할 수 있도록 개발 일정을 설계하는 것 또한 '애자일'의 상호작용, 고객과의 협력으로 보고 있다.

마찬가지로 계획을 무시하고 딜레이하면서까지 변화에 대응하고 새로운 기능이나 내용을 추구하는 것은 '애자일'하지 못하다고 생각한다.
왼쪽의 내용인 '계획을 따르기'를 무시하자는 말은 없다고 생각한다.
그러나 우측의 내용인 '변화에 대응하기'에 너무 심취되어 계획된 내용을 무시한다면 함께 업무하는 사람들에게 다소 에너지 소비를 강요하는 것일 수 있다.

반면 시시각각 변하는 미래의 투자가치에 따라 계획은 수정될 수 있다고 본다.
나는 계획이 지켜지는 선에서 변화에 대응은 가능하다고 본다. 시장 상황이나 요구조건의 변경에 따라 계획도 변경될 수는 있다고 생각한다.
이는 애자일의 내용중 '계획을 따르기보다 변화에 대응하기'에 대응 될 수 있을 것이다.

 

 

---

 

3. 애자일 선언 이면의 원칙과 우리 회사 애자일 실패의 원인

'''
애자일 선언 이면의 원칙

우리는 다음 원칙을 따른다:
우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

비록 개발의 후반부일지라도 요구사항 변경을 환영하라.
애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

동기가 부여된 개인들 중심으로 프로젝트를 구성하라.
그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

작동하는 소프트웨어가 진척의 주된 척도이다.

애자일 프로세스들은 지속 가능한 개발을 장려한다. 
스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.

기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.

최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
'''

현재 회사가 이번에 '애자일'에 실패한 이유는 상기 원칙이 지켜지지 않았기 때문일 것이다.

[1] 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
 - 일찍 주지 못했다.
 - 지속적으로 전달하지 못했다.
 - 요구사항과 달라 만족하지 못했다.

[2] 비록 개발의 후반부일지라도 요구사항 변경을 환영하라.
 - 이 부분은 잘 되었으나, 계획된 기간에 대한 딜레이가 너무 발생하여 1번에 대해 지켜지지 못하는 사유가 되었다.

[3] 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
 - 작업하는 총 3달의 기간중 한달동안 단 한번도 공유가 안되어 기획자 필두로 주간 1회 테스트 기기 배포를 진행하였다.
 - 이 마저도 나중에 지켜지지 못했다.

[4] 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
 - 개발팀이 비즈니스쪽 실무자(편집팀)에 대한 타깃이 오롯이 대표님 뿐이라고 오해한 점.
 - 함께 일하고 있었으면서 함께 일하지 않았다고 오판했다.

[5] 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
 - 이 부분은 대표님께서 개발팀에 아낌없는 지원이나 신뢰를 제공하였으면 했지만 그것이 어려웠다.
 - 불신... 이 때문에 프로젝트는 결단코 성공할 수 없었다.

[6] 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
 - 면대면 대화의 기회는 많았다
 - 다만 기록으로 남겨지지 않아 일부 오해가 되는 여지가 발생했다.
 - 이 부분을 해소하고자 한 개발자가 노션에 내용을 모으자는 괜찮은 제안을 했다.

[7] 작동하는 소프트웨어가 진척의 주된 척도이다.
 - 이 부분은 잘 되었다. 문제는 일정이 준수되지 않아 힘들었다.
 - 업무가 많은 것이 아니라 욕심이 너무 많았고 방향이 너무 모호했다.

[8] 단순성이 필수적이다.
 - 이 부분은 일부 개발자는 지켜지지 않았다.
 - 단위 개발을 최대화하고, 현재 개발하지 않아도 괜찮을 내용과 아직 아이덴셜이 필요한 내용들은 [백로그]에 이슈로 등록하여 관리하는 습관이 필요해 보였다.
 - XP 에서는, -보다 공부가 필요하지만- 스펙에 없는 내용을 작업에 추가하지 않는다는 원칙이 있다.

[9] 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다. / 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
 - 이 부분은 초기에는 좋았다.
 - 상호 신뢰가 깨진 이후에는 이 점이 퇴색되어 아쉬웠다.

[10] 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
 - 프로젝트 작업을 에픽이나 특정 단위로 분리하지 못해 조율/조정의 단계를 가질 수 없었다.
 - 이상하게 일정이 늘어나거나 추가 기능을 계속 만들어 7번과 8번이 지켜지지 않는 총체적 난국 발생
 - 이런 개발팀 이슈를 기획자가 일정조율을 통해 해결해 보려 하였으나 실패함
 - 소스 리뷰 없음
 - 프로젝트 리뷰 없음

 내가 하는 딴지를 듣는 사람이 없어서 그냥 내 할일이나 하기로 했던 것도 애자일 실패의 이유에 있지 않았을까 싶지만, 반면에 내 이야기를 듣지 않아서 실패하는 사실이 잘되었다고 생각한 못된 생각에 반성도 한다.

이번 실패를 딛고 대표님도 상처를 받았을 것이고, 내부 개발팀도 모두 퇴사를 하는 등... 좋지 못한 방향으로 흘러갔다.
개발팀의 안타까움도 잘 알고 있고, 그들의 노력도 인정되지 않는 듯 하여 마음이 아팠으며 
대표님의 입장에서도 투자 비용에 대한 포기가 얼마나 힘든 선택이었을까 고민해본다.

누가 잘못했고, 누가 문제였는가를 살피기 보다 나는 앞으로 얼마나 더 전문적으로 업무에 다가설 수 있는가 고민해보는 것이 내게 주어진 숙제가 아닐까.

 

---

 

참고

- dexter, dexterous, dexterity : m.blog.naver.com/eternity9us/221134667195

dexter, dexterous, dexterity

- "완전 갑자기"를 영어로는? : m.blog.naver.com/PostView.nhn?blogId=bluemetal412&logNo=30142912692&proxyReferer=https:%2F%2Fwww.google.com%2F

"완전 갑자기"를 영어로는?

- Week 9 Day 3: astute : m.blog.naver.com/wordwarrior/221700139749

Week 9 Day 3: astute

- 애자일 소프트웨어 개발 선언 : agilemanifesto.org/iso/ko/manifesto.html

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

- 애자일 선언 이면의 원칙 : agilemanifesto.org/iso/ko/principles.html

애자일 선언 이면의 원칙

- XP : namu.wiki/w/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

익스트림 프로그래밍 - 나무위키

- 익스트림_프로그래밍 : itwiki.kr/w/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

익스트림 프로그래밍 - IT위키

- 애자일(Agile)이란 무엇인가 : m.post.naver.com/viewer/postView.nhn?volumeNo=18903174&memberNo=36647560

애자일(Agile)이란 무엇인가