즐겁게 협업하는 방법! - 애자일과 피드백 그리고 게임

테오가 생각하는 잘하는 개발자라는 것은 어떤 건가요?
ㄴ 음... 저는 코딩 수준이 일정이상이 되고나면 결국 그 뒤에는 좋은 제품을 잘 만드려면 협업이 제일 중요한것 같아요. 연차가 올라갈수록 협업이나 팀 문화에 더 관심이 생기네요. 특히 스프린트를 진행해보면서 더더욱 그렇게 느끼고 있어요!

이번 글은 일하는 방식에 대한 이야기입니다. 소프트웨어 사업은 거대하기에 혼자서 다 할 수 있는게 아니기에 언젠가는 함께 일해야만 합니다.

어쩌다 보니 1인개발부터 시작해서 소규모 협업, 외주, 파견, 대규모 팀, 사이드 프로젝트 등 다양한 형태의 협업형태와 근무환경, 그리고 굉장히 수직적인 구조와 굉장히 수평적인 구조를 모두 겪어보면서 팀의 분위기나 조직의 문화 그리고 일하는 방식이 개개인의 능력보다 훨씬 중요하다는 것을 알게되었습니다.

그러던 중 애자일과 구글 스프린트 라는 것을 알게되면서 그 동안 겪었던 경험을 바탕으로 협업방식을 바꿔보기 위한 시도를 많이 해 보았습니다. 일부는 성과가 있었고 일부는 맞지 않는 방법들도 있었습니다. 현실은 책이나 글에 적힌대로 흘러가지만은 않았으며 경험도 실체도 없는 방식이었기에 여러가지 시행착오를 겪으며 지금도 계속 Best Practice를 찾아가는 중입니다.

평소에 협업에 잘 될때 혹은 그러지 않았을때 느끼고 이렇게 해야지 이렇게 하지 말아야지 하면서 적어뒀던 저만의 개똥철학 메모들을 하나씩 꺼내보면서 어떻게 하면 협업을 잘 할 수 있는지 에 대해서 제 가치관이나 현재 실제로 시도해보고 있는 방법론 등을 글로 정리해보면 좋겠다는 생각이 들었습니다.

그 첫번째로 '애자일과 피드백' 에 대해 한번 이야기해볼까 합니다.

애자일이라는 용어가 이 글의 전반에 걸쳐 나오긴 하지만 이 글은 애자일에 대한 설명글이 아니라 어떻게 협업을 하면 좋은지에 대한 개인적인 주관을 담고 있는 글입니다.

프롤로그

어떻게 하면 일을 더 잘할 수 있고 특히 조직와 팀 단위에서 협업을 잘 할 수 있는지 이미 우리 선배님들이 먼저 연구를 했습니다. 그렇게 만들어낸 개발 방법론들이 바로 지금 얘기드릴 Waterfall, 그리고 Agile입니다.

이제는 한번쯤은 들어본 Waterfall과 Agile 이야기

무작정 소프트웨어 개발을 하려고 하면 무엇을 만들어야 할지 어떻게 만들어야 할지 막막한 상황이 되면서 요구사항은 계속 늘어나고 일정은 예측 할 수가 없고 소프트웨어 결과물의 퀄리티는 점점 형편없어지게 됩니다.

그러다보니 어떻게 하면 효율적으로 개발을 할 수 있을지 이러한 공정을 고민하게 되면서 개발 방법론이라는게 정립이 되게 됩니다.

그러면서 소프트웨어를 만들기 위해서는 요구사항 → 분석 → 설계 → 디자인 → 구현 → 테스트 → 유지보수 와 같은 공정을 가지면 좋다는 것을 알게 됩니다. 각각의 공정에는 해야할 일과 만들어야 할 결과물을 명확히 규정하고 그에 맞는 전문가를 배치하고 각자의 역할을 수행 하고 다음 과정을 진행할 수 있도록 결과물을 만들어내고 또 그 결과물을 통해 다음 결과물을 만들어 최종적인 산출물을 만드는 방식을 찾아내게 됩니다.

이렇게 순서대로 결과물을 만들어 아래로 하달되는 방식이 마치 물이 떨어지는 방식을 연상시키기에 폭포수방법(waterfall) 이라고 불리고 오랫동안 소프트웨어 방법론으로 자리매김을 합니다.

이는 대량생산체제의 성공방식이었던 컨베이어 벨트에서 기인한 공정을 적절히 분할하고 하나의 공정이 끝나면 다음 공정으로 잘 넘어 갈 수 있게 연결하여 최종 결과물을 만들어내던 방식이었습니다. 그리고 각 공정의 효율을 높이기 위해서 잘 계획하고 잘 분석하고 잘 설계하고 잘 구현하고 잘 테스트 하는 방법들이 각자의 직군에서 발전해 왔습니다.

또한 하나의 공정이 완료되고 다음 공정을 진행할 수 있게 하기 위해서는 이 공정마다 정확한 산출물이 나와야 했고 이 산출물을 어떻게 만들어내고 관리해야하는지 발전해왔습니다. 요구사항 명세서, 소프트웨어 아키텍쳐, 유즈케이스, DataFlow 다이어그램, 테스트케이스 등 이러한 문서양식 또한 역시 이러한 방법론을 통해 만들어졌죠.

하지만 최근에 와서는 이러한 방식만으로는 많은 어려움과 실패를 겪게 되면서 소프트웨어 개발에는 새로운 방식이 필요하다는 것을 깨닫게 됩니다.

흔한 소프트웨어 개발 과정

이제는 고전이 된 A Swing Tree meme입니다. 🤣

백분이 불여일견이죠. 과연 어떤 일이 벌어진 걸까요? 한번 이 프로젝트가 어떻게 흘러갔을지 상상을 하면서 다시 살펴봅시다. 그림과 매칭을 하면서 아래 글을 읽어주시면 더 재밌을 거에요!

요구사항
"나무에 그네를 달면 정말 좋을 것 같아요! 아시죠? (어쩌고 저쩌고) 아! 생각해보니 그네로 3단으로 만들면 진짜 재밌을 것 같아요! (행복한 상상 중...)" - 고객

분석
"아니? 3단이면 어떻게 그네를 타라는거지? 뭘 모르고 하는 소리겠지. 무난하게 1단으로 가자. 그런데 가지 한쪽에만 그네를 두면 분명 부러질것 같아 불안한데... 아! 양 옆으로 묶으면 되겠네! 이래야 안정적이지! 안전하게 가자." - 프로젝트 리더

설계
"아니? 양쪽으로 묶으면 나무에 막혀 그네를 앞 뒤로 탈 수가 없는데...? 아! 그러면 일단 먼저 문제되는 나무 가운데를 없애고 ... 가운데를 없애면 쓰러지니까.. 음.. 그럼 좌우에 기둥을 받치면..? 오오! 이제는 설계상 문제 없어 보이네요!" - SW 아키텍쳐

구현
"... 아니? 이걸 어떻게 구현하라는 거죠? 딱 봐도 말이 안되잖아요.... 아! ... 그러니까 나무에 그네를 일단 묶으면 된다는 거죠? 이해했어요... 음.. 일정이요? 아이고 그때까지는 안되죠! 시간은 더 필요할 것 같아요." - 프로그래머

영업
"네.. 네! 저희 잘 만들고 있죠. (저도 아직 보지는 않았지만) 네! 걱정마세요 :) 게다가 그네에 이번에 새로나올 푹신한 소파까지 추가해서 고객님이 만족할만한 멋진 결과물이 나올겁니다. 네..네!" - 영업

문서화
...?

실제 설치된 결과물
버그로 그네가 보이지 않습니다. 아무튼 버그입니다.

정말 고객이 원했던 것
"아니? 그냥 재밌는 그네를 만들어 주는거 아니었어요?" - 고객

위 이야기는 여기에서 영감을 얻어 제 맘대로 한번 각색해보았답니다.
https://prezi.com/p/uxtqx3sgq9re/presentation/

농담인거 같죠? 실제로도 아주 빈번하게 발생하는 과정이랍니다. 😭

과연 누가 잘못한 것일까요? 요구사항을 제대로 알려주지 않은 고객? 요구사항을 잘못 이해하고 설계한 리더? 잘못된 분석을 내놓은 애널리스트? 이상하게 구현한 개발자? 확인없이 과대광고를 하고 일단 계약을 따온 영업? 어떻게 했다면 이런 문제가 발생하지 않을 수 있었을까요?

이러한 문제가 발생하게 된 원인은 특정 누구의 책임이 아니라 이러한 프로세스의 문제라고 보았습니다. 중간에 조금이라도 만들어진 결과물을 통해서 실제로 고객이 원해던 것인지 빨리 확인만 했더라도 이러한 참사가 벌어지지 않았을 거라고 생각을 했습니다.

사실 고객도 스스로 원하는 것이 무엇인지 잘 모릅니다. 그저 필요만 느끼고 있죠. 요즘 시대처럼 정해진 고객이 없는 상태에서는 이 불확실성이 더 커져만 가죠. 만드는 동안에도 요구사항과 시장의 니즈는 시시각각 변해갑니다.

그 결과 기존과는 다른 방식의 방법론인 애자일이라는 프로세스가 탄생하게 되었습니다.

Agile은 Waterfall과 뭐가 다를까?

위 나무 그네 에피소드에서 얻은 결론은 무엇일까요? 한번에 고객의 요구사항을 파악에서 효율적인 공정을 통해서 한번에 결과물을 만들었지만 그 결과가 결국 고객이 원한게 아니었다면, 시장에서 원하는게 아니었다면 이 노력들이 물거품이 되버린다는 것이었습니다.

뿐만 아니라 구현과정에서 문제점이나 허점들이 발견이 되어도 이미 되돌리기에는 너무 늦어버렸고 앞선 공정으로 다시 되돌아가는 것이 매우 어렵다는 것입니다.

그렇기에 이러한 모든 공정을 유지하면서도 여러번에 나눠서 작게라도 동작하는 소프트웨어를 만들고 나서 검증하고 확인하고 회고하고 다시 조금 더 개선해나가면서 이러한 개발 주기를 작게 자주 여러번 가지면서 결과물을 만들어 내는 것이 훨씬 더 효과적이다는 것을 알게 되었습니다.

하지만 애자일을 한다는 것은 호락호락하지는 않았습니다. 애자일이라고 해서 기존 폭포수 모델의 과정을 거치지 않는 것이 아닙니다. 기존의 공정의 리드타임을 줄이고 짧게 결과물을 만들어가면서 만들 결과물을 또 테스트하고 지속가능하게 유지해나간다는 것은 기존의 방식보다 훨씬 더 어려운 일이며 단순한 개발 방식의 변화를 넘어 조직 문화의 변화까지 필요한 사실이라는 점입니다.

애자일이 어려운 이유

이러한 애자일을 하기 위한 여러가지 방법들이 개발이 되었습니다. 이제는 유명해진 스크럼, 스프린트, 칸반, 회고와 같은 방법론등이죠. 하지만 애자일의 방향성이 좋다는 것은 알지만 막상 도입을 하고 실천하기는 쉽지 않습니다.

여러가지 이유가 있지만 대표적인 것들을 꼽아보자면,

1. 애자일이라고 하는 방식을 경험해본적이 없다. (사실 정해진 애자일 방식이라는 것도 없다.)
2. 한번 만들고 나서 수정을 하는 것은 처음부터 그렇게 만드는 것보다 훨씬 더 비싼 비용이 들어간다.
3. 기존보다 더 짧은 일정 주기로 일을 해야하면서도 덜 완성된 문서와 불확실한 상태로 일을 해야한다.
4. 그래서 다른 직군과 공정사이에서 기존보다 훨씬 더 많은 소통 비용을 요구한다.
5. 그렇기에 조직내의 합의가 필요하고 혁신과 개선이 필요하다.
6. 예전에 비해서 더 어렵고 불편하기만한 방법을 해야하는 의구심이 들면서 과거의 익숙한 방식으로 회귀하려 한다.

(괜히 폭포수방법이 고전적인 방법론으로 자리잡힌게 아니죠.)

결국 어설프게 애자일 방법을 도입을 했다가는 애자일의 호용체감을 하기도 전에 발생하는 비용들을 감당하지 못한채로 전보다 짧아진 마감시간, 불확실한채로 정리된 건 없는데 회의만 길어지고, 산출물 관리는 엉망이되면서, 중간 결과물의 퀄리티가 낮은 관계로 불만이 나오는데, 여전히 일정 맞추기에 쫓겨가면서 이렇게 하는게 애자일한게 맞나? 라는 회의감이 커져가게 됩니다.

그렇다면 도대체 어떻게 애자일을 해야 하는걸까요?

애자일은 그저 가치관과 방향성일뿐 Best Practice는 계속 찾아가는 것!

애자일은 신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 소프트웨어 개발 방식입니다. ... 애자일은 정확히 말하자면 소프트웨어 개발에 필요한 작업을 알려주는 일련의 규정이 아닙니다. 그보다는 협업과 워크플로우를 바라보는 하나의 관점이며, 우리가 무엇을 어떻게 만들지에 관한 선택을 안내하는 가치 체계입니다.
출처: https://www.redhat.com/ko/devops/what-is-agile-methodology

그래서 애자일에 대해 공부를 하면 맨 처음 다음과 같은 선언과 원칙을 만날 수 있게 됩니다.

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

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

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

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

12가지 애자일 원칙

1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이
   되게 한다.
3. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
7. 작동하는 소프트웨어가 진척의 주된 척도이다.
8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.
9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
10. 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.
11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

애자일을 다시 정의해보자.

애자일이 만들어진지 오래되었고 여기저기에서 애자일의 가치와 성공사례를 접하곤 하지만 지금도 우리에게 애자일이 모호하게 느껴지는 것은 결국 애자일은 '짧은 주기로 실제로 작동가능한 소프트웨어를 만들고 보여주면서 지속적으로 고쳐나가는 모든 협업과정' 이기에 회사마다 팀마다 조직마다 개인마다 다 다른 관점과 상황으로 해석을 할 수 있고 또 프로젝트의 성격과 구성에 따라 맞춰나가는 것이 애자일이라고 하니 사실상 굉장히 범위가 넓고 모호한 말이 되었습니다. 더욱이 애자일이라는 용어가 소프트웨어를 넘어 다른 분야에까지 퍼지고 있는 상황이기에 해석하기 나름의 키워드가 되어 버렸습니다.

또한 애자일에 대한 방법론 자체가 이러한 선언과 가치를 필두로 현재 상황에 맞는 방식을 찾아내는 과정이라고 하기때문에 더더욱 정답도 없고 해석이나 적용하는 방법론 또한 말하는 사람마다 다들 비슷하면서도 조금씩은 다른 이야기를 하고 있는 것도 이 때문입니다.

저 역시 그 중 하나가 되겠지만 제가 애자일을 공부하고 제 나름의 정의를 가지고 다시 해석해본 관점에서의 이야기이며 여러가지 애자일 원칙과 선언 그리고 애자일 방법론등을 적용하면서 생각해본 협업과 애자일의 가치관에 대해 제 나름대로의 해석과 정의를 다시 공유 해보고자 합니다.

---

애자일의 핵심가치는 무엇일까?

애자일의 핵심은 1) 만들고 → 2) 보여주고 → 3)피드백을 받고 → 4) 방향성을 맞추고 → 1) 만들고 ... 를 반복하는 이 주기를 모두가 함께 참여하면서 이 피드백 주기를 점점 짧게 만들고자 노력하는 것입니다.

우선 만들고 보여주고 평가를 받고 고쳐나간다.

애자일의 선언과 원칙 그리고 여러가지 방법론을 읽어보면서 수없이 많은 자기들만의 애자일 정의와 해석을 만났습니다. 그리고 저 역시 애자일을 가장 잘 설명할 수 있는 본질과 핵심이 되는 키워드는 무엇인지 고민해보기 시작했습니다.

그리고 애자일 방법론인 스프린트, 스크럼, 칸반, XP, 린을 아우를 수 있는 가장 단순한 정의가 필요했습니다. 그래야 나중에 상황에 맞게 변화를 하고 생각의 확장을 위해서 제 나름의 정의가 필요했기 때문입니다.

그래서 1문장으로 정의한 제가 내린 애자일 방법론에 대한 정의입니다.

애자일이란 우선 만들고 보여주고 평가를 받고 고쳐나가는 것을 반복하며 제품을 개발하고 이 과정을 모두가 함께 참여하며 누구나 볼 수 있게 시각화하면서 피드백 주기를 점점 짧게 만들고자 노력하는 것이다.

아직은 모든 것을 욱여넣으려니 좀 투박하네요. 😅

그래서 추구해야할 가치와 키워드 형태로 다시 한번 정의를 해보았습니다.

1. 지속적인 결과물
2. 업무의 시각화
3. 피드백(간격을 점점 줄여가는 것)
4. 모두가 함께 맞춰가는 방향성

---

애자일은 결국 빠른 피드백 시스템 만들기!

애자일의 출발은 고객으로부터 더 빨리 피드백을 받기 위해 시작되었다.

피드백의 간격을 줄이자!

에자일의 핵심은 빠른 피드백에 있습니다. 애자일의 출발점은 고객에게서 더 빠른 피드백을 받기 위해서였죠. 실체가 없는 것을 말로 글로 전달을 하는 것은 쉽지 않습니다. 눈에 보여지는 것 없이 말로만 주고받게 된다면 서로 같은 것을 보고 있다고 생각했지만 서로 다른 것을 생각할 수가 있게 되죠.

이렇게 방향성에 대한 주파수를 맞추지 않은 상태에서 서로 열심히 일을 하면 열심히 한 만큼 오히려 더 멀어지는 결과를 가지고 오게 됩니다. 그렇기 때문에 중간중간에 내가 가는 방향이 맞는지 서로가 가고자 했던 방향이 맞는지 계속 확인을 하는 과정이 필요합니다.

하지만 처음으로 돌아가 실체가 없는 상태에서 말과 글을 통해서 방향을 맞춘다는 것은 어려운 일입니다. 우리가 반응을 하기 위해서는 눈으로 볼 수 있는 결과물이 필요합니다. 이렇게 만들어진 결과물은 새로운 시각과 목표를 상상하게 해주고 서로의 방향성을 가늠하면서 새로운 피드백을 할 수 있는 기회가 만들어지게 됩니다.

이렇게 업무의 결과를 눈으로 볼 수 있으면 피드백을 받을 수 있고 피드백을 통해 방향성을 맞출 수 있게 됩니다. 이렇게 새롭게 조정된 방향성을 가지고 우리는 조금 더 성장한 다음 업무의 결과를 만들어 낼 수 있습니다.

앞서 언급했던 애자일의 키워드를 한번 다시 떠올려주세요. 지속적인 결과물, 업무의 시각화, 짧은 피드백 주기, 함께 맞춰가는 방향성.

이 관점을 조금만 더 확대를 해보면 어떨까요?

궁극적인 애자일한 협업을 상상해보기

1. 고객과 회사의 피드백을 넘어 회사내 조직간, 조직내 팀간, 팀내의 개인간의 피드백의 주기가 빨라진다면 어떨까요?
2. 고객이나 회사가 생각하고 있는 것을 바로 확인 할 수 있는 시스템이 갖춰져 있다면?
3. 눈으로 보이는 것이 결과뿐만이 아니라 과정까지 시각화가 된다면 어떨까요?
4. 그래서 같이 일하는 사람이 다 지속적으로 방향성을 맞춰가며 일을 한다면 어떻게 될까요?

이렇게 고객에게 빠른 피드백을 받아 조금씩 방향성을 맞춰 고쳐나가면서 제품을 생산한다는 방법론은 모든 조직이 같은 방향성을 가지고 피드백이 활발하며 업무의 과정과 결과를 눈으로 확인할 수 있는 조직문화를 구성하는 방법 까지 확장이 됩니다.

그리고 이 모든 것은 바로 피드백의 간격을 줄이는 것을 목표로 합니다.

피드백이 느리면 어떤 문제가 발생할까?

피드백이 느리면 그 시간동안 내 생각과 내 구현물에 대해 애착이 생깁니다.
애착이 생겨버린 생각과 구현물은 곧 나 자신이 되어 부정적인 피드백을 자신과 일치시키게 되어 방어적으로 대하게 됩니다.

@NOTE: 여기서 애착은 자기 생각에 갇혀서 나오지 못하는 것을 의미합니다.

피드백의 간격을 줄이는 것이 왜 중요한지 반대로 피드백이 느리면 어떤 문제가 발생하는 지 한번 상상해봅시다.

우리가 기획을 한거나 디자인을 한다거나 설계를 하거나 개발을 한다고 한번 상상을 해봅시다. 그리고 팀에서 좋은 아이디어가 나와서 한번 실제로 구현해보기로 마음을 먹었습니다. 하지만 이것을 구현해서 결과물을 보여주는데까지 꽤 오랜 시간이 걸렸다고 생각을 해봅시다.

아이디어를 낸 사람은 당시 생각으로는 정말 이게 좋았다고 생각을 했지만 실제로 눈으로 보기 전까지는 정말로 이게 좋을지 안 좋을지는 판단을 할 수 있는 근거는 없습니다. 그저 자기 기준에 좋을 거라고 추측을 하는 거죠. 우리가 아이디어를 떠올릴때에는 항상 좋은것만 생각하기 때문입니다.

그리고 나서 그 구현의 결과물을 보여줬을때 실제로 그 결과물이 좋지 않은 것으로 판단이 되었다면 어떻게 해야할까요? 우리는 이 결정을 빨리 번복을 하거나 수정을 하거나 새로운 방법을 찾아야만 합니다.

그러나 여기에 매몰비용이 이미 많이 들어갔기에 그러한 결정을 쉽게 할 수가 없게 됩니다.

여기에는 이 아이디어를 만드는 데 들어갔던 비용도 있겠지만 이 아이디어를 피드백없이 머리속으로 생각을 하고 있던 기간마저도 매몰비용에 포함이 됩니다. 그러면서 나도 모르게 이 아이디어에 애착이 생겨 버립니다. 그러면서 이 이상의 아이디어에서 벗어나지 못하고 갇혀버리고 말죠.

이후에는 그 아이디어에 대한 정당한 반박마저도 어떤 공격을 받는 것처럼 느껴집니다. 애착이 깊을수록 곧 자기를 공격하는 것처럼 느껴지게 되죠. 그래서 굉장히 방어적인 태도를 취하거나 보수적인 형태를 취할 수밖에 없습니다. 왜냐하면 나의 시간과 노력이 배신당하는 기분을 받는 거거든요. 나는 여기에 이만큼이나 시간을 들였고 이미 그 생각을 안해본게 아니라는 식으로 반응을 하게 됩니다.

이러한 편견이 생겨버리는 것은 그 아이디어에 대한 애착없이 피드백을 받을 시간은 넘겨버렸기 때문입니다.

이런 상태에서는 제대로 된 토의나 합의 혹은 발전적인 얘기를 할 수가 없게 됩니다. 오히려 내 의견을 관철시키기 위해서 더 노력을 하게 되죠. 그러다보면 회의는 지지부진해지고 어느 한쪽이 포기하기 전까지는 의미없는 논쟁만 이어지게 됩니다.

이러한 과정은 일반적인 회사나 조직에서 엄청 자주 발생하는 익숙한 광경입니다.

애착을 가지기 전에 빨리 공유하고 빨리 피드백 하자.

구체화되기 전에 공유를 하면 내 것이 아니라 우리의 것이 됩니다.
찬반이 아니라 생각과 결과물을 키워가는 과정이기에 얼마든지 서로 피드백을 할 수 있어요.

이렇게 각자의 생각에 애착을 가진채로 의견을 나누는 것은 소모적인 양상을 띄게 되므로 지양해야하는 방식입니다. 특히 변화가 빠른 소프트웨어에서는 더더욱 그렇게 하지 말아야합니다. 언제나 유연하게 마음의 대응을 변화를 할 수 있고 언제나 더 좋은 방법을 찾을 수 있도록 해야겠죠. 그러기 위해서는 이 피드백 간격의 리드 타임을 줄이는 것이 굉장히 중요합니다.

그래야만 지금 내가 하는 생각이나 의견이 반박당하더라도 혹은 버려지더라도 큰 타격없이 의견을 수용할 수 있게 됩니다. 또한 그렇게 해야만 서로가 자유롭고 편하게 의사소통을 할 수 있게 됩니다. 위에서처럼 서로 자신들의 의견에 애착을 가진 상태로 의견을 주고 받게 되면 더 이상 피드백을 할 수가 없게 됩니다.

이러한 문제는 팀이나 조직의 고질적인 문제로 변하기 쉽습니다.

애착을 가진 사람은 상대방의 피드백을 원하면서도 반대의견을 받기 싫어해요. 왜냐하면 내가 애써 생각했던 내용에 대해서 부정적인 의견을 듣는 거를 반가워할 리가 없겠죠.

내 피드백이나 의견이 전달이 되지 않는다는 것을 몇 번만 경험을 하면 그 상황이 아니라 '이 사람은...', '이 회사는...' 하는 식으로 생각으로 발전을 하게 되고 학습된 무력감은 더욱 더 피드백과 상호작용을 하지 않는 식으로 악순환이 이어지게 됩니다. 나중에 이 문제를 해결을 하겠다고 해도 이미 불신을 가졌기 때문에 개선을 하기가 정말 어렵습니다.

그러니 내가 어떤 생각이나 의견이 있을 때에는 애착이 생기기 전에 빨리 누군가에게 공유를 하기 바랍니다. 구체화되지 않을수록 더 좋습니다. 그러면 이 아이디어는 내 아이디어가 아니라 우리의 아이디어가 됩니다. 이렇게 우리의 아이디어나 결과물이라는 생각이 든다면 얼마든지 자유롭게 피드백을 주고 받고 적극적으로 키워 나갈 수 있게 됩니다.

빠른 피드백은 프로젝트와 사람을 성장시킨다.

아이디어의 가장 좋은 피드백은 눈으로 볼 수 있는 결과물이며 이 결과물은 새로운 피드백을 받기 가장 좋은 형태입니다.
열려있는 마음으로 받는 피드백은 새로운 관점과 방향성을 떠올리게 하고 새로운 생각과 더 나은 결과물을 만들 수 있는 성장동력이 됩니다.

내가 만든 결과물에 애착이 생기기전에 공유를 하고 빠른 피드백을 받게 되면 훨씬 더 통제권, 주도권과 몰입감을 유지하면서 업무를 진행 할 수 있습니다. 이렇게 주도성을 가지고 열린 마음 일때에는 여러가지 의견들을 받아들이고 내것으로 충분히 소화해 낼 수 있는 능력이 생기게 됩니다.

사람은 혼자서 상상을 할 수 있는 인식의 범위는 정해져있다고 합니다. 주로 사용하는 사고의 방향으로 뇌는 점점 구조화되고 그런 것들이 전문성이기도 하니만 고정관념이 되기도 합니다. 이러한 생각의 구조들은 내가 생각해보지 못한 시선과 관점을 만나게 되면 기존의 구조를 부수고 다시 재구성을 하게 되는 과정에서 사람은 창조적인 생각과 함께 성장을 할 수 있다고 합니다.

그래서 혼자서는 할 수 없었던 것들이 사소한 피드백을 통해서 새로운 곳을 바라볼 수 있게 되면서 더 나은 결과를 만들게 되면 또 그에 대한 피드백이 또 새로운 피드백을 만들어가며 성장하는 선순환효과를 가져오게 됩니다.

혼자서 하는 시간이 길어질수록 애착이 생겨서 고집이되고 닫힌 생각을 하게 되는 것도 문제지만 그러한 시간이 길어질 수록 선택과 결정을 하는데에 훨씬 더 많은 에너지가 필요하다고 합니다. 짜장면이나 짬뽕이냐를 고민하기 시작할때 그 고민을 오래할수록 결정을 하기 힘들어진 경험을 떠올려보세요. 이럴때 누가 "야~ 그냥 짬뽕먹어!" 라고 한마디 하는 순간 "그래~ 짬뽕먹자!" "아냐 짜장면 먹을래" 하고 쉽게 결정이 되는 경우를 경험해본 적이 있을 거에요.

피드백 주기를 줄인다는 것은 이러한 데에 드는 에너지를 상대방은 정말 적은 에너지로 도와줄수 있고 이러한 빠른 결정과 진행은 대부분의 경우 프로젝트를 더 좋은방향으로 빨리 성장하도록 도와줍니다.

단, 만들지 않고서 논의를 길게 이어가지 말자.

출처: 피드백의 피드백의 피드백 https://publy.co/content/5064?fr=chapter-text
눈으로 결과를 보기 전에 논의가 길어지면 그 과정에서 애착이 생겨버립니다.

처음에는 즐겁게 우리의 생각을 키우고 발산하는 과정에서 선택과 결정을 해야하는 순간이 오면 대치되는 의견에 대해서는 입장을 가져야하는 순간이 오게 됩니다. 대부분의 의견은 자기만의 합리적인 근거와 추론과정이 존재하고 옳고 그름의 문제라기 보다는 선택과 취향의 문제인 경우가 많습니다.

이 정도의 논의가 진행이 되었다면 구체화를 시켜서 만들지 않고서 논의를 길게 이어가서는 안됩니다. 이러한 논의는 결국 일치할 수 없는 각자만의 상상의 결과물을 가지고 이야기를 하게 되고 있고 내 생각에 애착이 생기면 내 생각을 지키기 위해서 서로 자신의 생각대로 상대방의 결과물을 만들어서 공격을 하는 양상으로 이어지게 됩니다.

이것이 애자일에서 만들어진 결과물을 빨리 내어야 하는 이유이기도 합니다.

어떠한 의견이든 그 맥락과 배경이 존재합니다. 그 중에서는 실제 현상인 Fact도 존재하고 공감대도 있고 추론을 하는 과정에서 합리적인 부분들도 존재합니다. 그러나 해결방법에 대해서만 동의하기 힘들 수가 있습니다.

기존에는 구현하는데 들어가는 비용과 특히 수정을 하는데 들어가는 비용을 줄여보기 위해서 사전에 많은 논의를 통해서 수정하지 않을 정말 좋은 방법을 찾아내는 것이 좋다고 생각을 했습니다. 하지만 현실은 그렇게 만든다 하더라도 수정을 하지 않을 수가 없고 한꺼번에 많이 만들게 될 경우 오히려 수정에 대한 문제점에 대해 유연하게 대응할 수 없다는 것을 알게 되었습니다.

우리가 만들어내는 논의와 피드백은 결국 만들기 위한 것이라는 사실을 잊지 말아야 하고 만들 수 있는 적당한 재료가 모인다면 더 이상 논의를 중단하고 일단 눈으로 볼 수 있는 결과물을 만들어 내는 것이 중요합니다.

만들기 위해서 이 모든 과정이 존재하는 것. 주객이 전도되지 말자.

우리의 목적은 같습니다. 효율적으로 좋은 제품을 만들어 내는 것이죠.

이미 한번 만들고 나서 수정을 하는 것은 만들기 전에 수정을 하는 것에 비해 훨씬 더 비용이 비쌉니다. 한번 출시를 하고 나면 출시하기 전보다 앞으로의 개발에 훨씬 더 많은 비용이 발생하는 것은 사실입니다. 그렇기에 과거에는 수정비용을 아끼기 위해서 많이 예측하고 많이 미리 생각하고 검토를 하고자 노력을 했었습니다. 그리고 이러한 방향이 올바르다고 생각했습니다.

하지만 시간이 지나 알게된 사실은 그렇게 미리 예측하고 준비하고 만들기 전 많은 논의를 하는 행위들이 길어질 수록 더 더 잘못된 예측을 하고 실패할 확률이 높다는 것이었습니다.

예측을 하거나 미리 논의를 하는 것 자체가 나쁘지 않습니다. 주먹구구식으로 시작하거나 무계획이 좋을리가 없지요. 하지만 일정이상의 예측과 논의는 무의미하며 오히려 잘못된 판단과 경직된 팀문화를 만들어 냅니다.

우리의 목적은 같습니다. 효율적으로 좋은 제품을 만들어 내는 것이죠. 그렇다면 모든 논의의 방향성과 내부의 피드백은 어떻게 제품을 만들어 낼 수 있는지로 수렴이 되어야 하고 어떻게든 눈으로 볼 수 있는 결과를 만들기 위한 방향이 되어야 한다는 사실을 기억해야 합니다.

---

피드백의 주기가 짧아질수록 노동은 게임이 된다

게임과 현실의 주된 차이점이 뭘까요? 가장 큰 차이점은 게임에서는 내 행동에 대한 즉각적인 피드백과 보상이 있고 언제나 그것을 확인 할 수 있는 수단이 존재합니다. 그렇기에 우리는 뭘 해야할지 어떻게 해야할지에 대한 설명이 없어도 스스로 이것 저것을 해보면서 성장할 수 있는 방법을 배워가며 그 안에서 몰입감과 함께 즐거움을 찾게 됩니다.

동기부여를 하기 위한 수단을 찾기위해서 사람들은 많은 수단을 찾아보았습니다. 그 중에서 가장 강렬한 경험은 바로 게임입니다. 게임은 현재 내 상태를 수치로 보여주고 내가 무엇을 해야할지 목표를 알려주고 내가 어떻게 하면 더 성장할 수 있는지 가이드를 제시합니다. 무엇보다 내가 한 행동에 대해서 즉각적인 피드백을 주어서 내가 제대로 하고 있는지 그러지 않았는지 알려줍니다. 이러한 피드백은 나를 움직이는 동기부여의 수단이 되고 우리는 게임안에서 원하는 대로 성장을 하면서 그안에서 몰입감과 즐거움을 찾게 됩니다.

이러한 게임의 특성을 연구하여 게임에서 적용되는 것들을 다른 세계에 접목해보려는 시도가 바로 게임이론입니다. 게임이론에서는 이러한 현재 상태를 보여주고 행동에 따라 그 상태가 변화하는 즉각적인 피드백이 사람을 움직이게 하는 큰 자극이 된다고 말하고 있습니다.

내가 어디까지 일을 했고 얼만큼 해야할게 남았으며 나 말고 다른 사람들은 지금 어떻게 하고 있는지 알 수 있다면 우리는 훨씬 더 주도성을 가지고 업무를 할 수 있습니다.

혹시 무언가가 떠오르나요? 이러한 맥락으로 만들어진 것이 바로 애자일 방법론중 하나인 칸반입니다.

애자일에서 업무시각화를 대표하는 칸반! 업무 시각화가 중요한 이유는 이 역시 피드백 시스템이기 때문이다!

우리가 피드백을 원하는 이유는 우리는 모두 나를 중심으로 하여 내가 통제권을 가지고 있기를 원합니다. 나에게 통제권이 없다고 느껴지는 순간 우리는 무기력해집니다.

PM이 개발자에게 "언제까지 가능하나요?" 를 항상 물어보는 이유도 여기에 있습니다. 우리가 다른 사람에게 업무를 전달하거나 만들 결과물을 전달하고 나서 나아가 문자나 메일을 보내고 한참동안 답이 없을때 우리가 힘들어하는 것은 더 이상의 통제권이 나에게 없다고 느껴지기 때문입니다.

꼭 칸반이 아니어도 좋습니다. 우리가 추구해야할 것은 어떠한 방식으로든 이러한 피드백 주기가 짧아 질 수 있도록 해야하며 그중에서 가장 좋은 것은 눈으로 볼 수 있고 즉각적으로 반응이 되는 시스템이라면 더 좋습니다.

피드백의 정의를 확장하기. 게임과 같은 피드백이 되자

현실이 게임과 다른 점은 내 상태와 행동에 피드백이 느리고 내 상태를 수치화 할 수 없다는 점이다.

현실에는 내 경험치가 보이지 않고 내 행동과 결과가 수치화 되지 않고 내가 하는 행동이 목적에 부합하는 것이지 그 전에 목표가 무엇인지 조치 보이지 않습니다. 반면 우리가 게임에 몰입하게 되는 것은 분명한 목표, 목표에 맞게 행동을 하는 자율성, 그 안에서 내가 행동을 할때마다 제대로 하고 있는 지 못하고 있는지 알려주는 여러가지 피드백 장치 그리고 달성했을 때 주어지는 보상과 적절한 난이도들로 하여금 사람들에게 몰입감과 주도성을 부여하고 즐거움을 주어 스스로 게임을 계속 할 수 있도록 만들어줍니다.

그렇다면 현실은 게임이 될 수 없는 걸까요? 현실에서도 게임처럼 분명한 목표와 함께 내 행동에 대해 빠른 피드백이 오고 시각적으로 보여지고 내가 무슨 행동을 할때마다 실시간으로 변화하고 적절한 난이도를 만들어주고 해결했을때의 보상을 줄 수는 없는 걸까요?**

🔥 그래서 서로의 결과물이 서로의 피드백이 되는 시스템을 만들자!

내가 한 일의 결과가 다른 사람의 피드백이 되고 다른 사람의 피드백이 곧 내 일을 하게 하는 동력이 되도록 하자!

느린 피드백은 조직문화를 맞고 틀림을 논하는 정치화를 야기하고 빠른 피드백은 게임과 같이 만들어 줄 수 있다고 하였습니다. 그러나 만들어낸 결과물이 없는 빠른 피드백은 결국 느린 피드백과 다르지 않습니다. 시각화가 되지 않으면 피드백은 의미가 퇴색되기 시작합니다. 시각화된 결과물은 계속 변하지 않으면 피드백이 되지 않습니다.

이 모든 것들이 적절히 잘 맞물려 돌아가서 피드백 주기가 빨라진다면 정말 게임과 같은 개발환경을 만들어 줄 수 있습니다. 내가 생각한 것이 다른 사람의 의견과 합쳐지고 만들어서 보여주고 디자인을 만들어지고 구현이 되고 또 고쳐나가고 성장해가는 결과물을 다같이 지켜보면서 키워나가는 것은 큰 즐거움이나 보상이 됩니다.

---

끝으로..

개발은 코딩도 중요하면 결국 함께 일하게 될 것이기에 나중에는 협업이 참 중요해집니다. 그러나 이러한 협업을 가르쳐주는 것들은 없는 것 같아요. 처음에는 스킬을 쌓는 것이 당연히 중요하고 나중에는 이 함께 일하는 방식에 대해서 고민을 하게 되는 시기가 생길거라고 생각을 합니다.

여러가지 시행착오를 겪으면서 적어갔던 메모들을 이제는 정리하면서 그리고 지금 배우고 실천해보고 있는 스프린트와 애자일을 함께 접목하면서 알게되었던 생각들이나 저만의 방법들 방향성 등을 공유 하고 싶었습니다.

애자일은 변화에 대응하고 고객의 피드백을 빨리 받기 위해서 조금씩이라도 만들어가면서 고쳐나가는 것이 더 좋다는 개발 방법입니다.

이렇게 피드백을 받아가며 만들면서 고쳐나가자는 이 생각은 단순히 개발방법을 넘어서 만들기 -> 시각화 -> 피드백 -> 방향성 이라고 하는 보편적인 가치를 확장시켜서 애자일한 조직문화로까지 발전을 하게 되었습니다.

나아가 이러한 시각화와 피드백 주기를 줄여나가다보면 우리는 게임처럼 일을 주도적으로 몰입감있게 동기부여가 되면서 할 수 있지 않을까 생각을 해봅니다.

실제로 이렇게 만들기 위해서 필요한 구체적인 방법론들이나 장치, 마인드 셋들에 대해서는 앞으로 시리즈 형식으로 계속 이어나가 볼 생각입니다.

우리가 애자일하게 일해야 하는 이유 = 재미와 행복! 😎

정말로 잘된 애자일 방식으로 일하면 일이 너무너무 재밌습니다. 내 의견이 받아들여지고 다 같이 함께하는 것 같고 진행도와 결과물이 계속 성장해나가는 것을 보면 뿌듯합니다.

내가 이 모든 공정을 다 알고 있으니 누가 시켜서 하는 일이 아니라 주도성을 가지고 일을 하게 되고 커뮤니케이션 비용이 결과론적으로 엄청 줄어들게 됩니다.

모여서 회의를 하는 것은 남의 시간을 뺏는 게 아니라 그냥 그 시간에 다 같이 일을 하게 되는 거예요. 다른 사람이 작업한 결과물을 보고 막 만들어 보고 싶다는 생각을 하게 되고 또 내가 만든 결과물들에 반응하고 즐거워하고 개선과제가 나오면서 다같이 성장을 하고 있는 것을 느끼는 것은 큰 즐거움입니다. 또한 이러한 유대감에서 오는 안정감은 행복으로 이어지기도 합니다.

하지만 언제나 이렇게만 되는 것은 아니었습니다. 어렵게 쌓아올린 시스템은 또 어떠한 이유로 잘 동작하지 않게 되고 아직도 시행착오를 겪고 있습니다.

앞으로도 계속 즐겁게 일을 하고 싶기에 어떻게 해보면 좋을지 돌이켜보면서 해당 시리즈를 작성해보기로 하였습니다. 저 역시 실무에서 겪고 헤쳐나가야할 과제들이 많고 시행착오를 겪는 중입니다.

지금 이 글과 앞으로 쓸 이야기들이 비슷한 고민을 하고 있는 사람들에게 공감이나 인사이트가 되길 바랍니다.

---

다음 이야기 예고

아직 못 다한 이야기... 조금씩 완성도 있게 정리해서 또 새로운 이야기로 찾아올게요!

피드백 시스템을 갖추기 위한 장치와 마인드셋
수평스러운 문화와 호칭
커뮤니케이션 주기를 가능한 짧게 만들어야 한다! - 스크럼과 스프린트
회의를 많이 하는게 독이 되는 건 아닐까?
회의가 아니라 실시간 협업이다!
재택근무를 하면 스크럼이 가능할까?
온라인 세상에서는 오히려 한계가 더 없다
업무의 시각화가 중요하다.
정해진 루틴을 만들어 주자.
태스트 관리는 모두가 함께 하자.
작게 생각하고 모두가 같은 곳을 같은 범위를 생각하자.
일정을 정확하게 예측하려고 하지 말자.
나는 여유있다고 너무 빨리 앞서나가지 말자.
스프린트의 목적은 다같이 조금씩 앞으로 가는 것이다.
주도성을 가지고 모든 일을 내 일처럼 하는것 = 몰입 = 즐거움!
기분좋게 의견 합의에 이르는 방법
...
...