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

이번 글은 일하는 방식에 대한 이야기입니다.

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

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

오늘은 제가 경험한 Best Practice를 찾아가는 이야기를 통해 어떻게 협업을 하면 좋은지에 대한 주관적인 의견을 설명하고자 합니다.

한 번쯤은 들어본 워터폴과 애자일 이야기

어떻게 하면 일을 더 잘할 수 있을까요? 특히 조직과 팀 단위에서 협업을 잘 할 수 있는 방법이 있을까요? 역시나 이미 우리 선배님들이 먼저 연구를 했습니다. 그렇게 만들어낸 개발 방법론들이 바로 지금부터 얘기할 ‘워터폴(Waterfall)과 ‘애자일(Agile)’입니다.

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

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

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

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

또한 하나의 공정이 완료되기 위해서는 각 단계마다 정확한 산출물이 나와야 했습니다. 그래서 이 산출물을 효율적으로 만들고 관리하는 방법이 발전해 왔습니다. 요구사항 명세서, 소프트웨어 아키텍처, 유즈케이스, DataFlow 다이어그램, 테스트케이스 등 이러한 문서 양식 또한 워터폴 방법론을 통해 만들어졌죠.

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

흔한 소프트웨어 개발 과정

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

위 이야기는 여기에서 영감을 얻어 제 맘대로 한번 각색했습니다. 위 사례가 농담인 것 같나요? 실제로도 아주 빈번하게 발생하는 과정이랍니다.

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

이런 일이 반복되면서 특정 누구의 책임이 아니라 이러한 프로세스가 문제라고 판단하는 사람들이 늘어났습니다. 그래서 ‘중간에 조금이라도 만들어진 결과물을 통해 실제로 고객이 원한 것인지 빨리 확인만 했더라도 이러한 참사가 벌어지지 않았을 것’이라는 생각이 늘어났습니다.

사실 고객도 스스로 원하는 것이 무엇인지 잘 모릅니다. 그저 필요만 느끼고 있죠. 요즘 시대처럼 정해진 고객이 없는 상태에서는 이 불확실성이 더 커져만 가죠. 만드는 동안에도 요구사항과 시장의 니즈는 시시각각 변해갑니다. 그 결과 기존과 다른 방식의 방법론인 ‘애자일’ 프로세스가 탄생하게 되었습니다.

애자일과 워터폴은 뭐가 다를까?

앞서 나무 그네 에피소드에서 얻은 결론은 무엇일까요? 약속한 공정을 통해 순서에 따라 한 번에 결과물을 만들었지만, 고객이 원한 것이 아니라면(혹은 시장이 원하는 게 아니라면) 이 노력들이 물거품이 될 수밖에 없습니다. 그뿐만 아니라 구현 과정에서 문제점이나 허점들이 발견이 되어도 이미 되돌리기에는 너무 늦어서 앞선 공정으로 다시 되돌아가는 것이 매우 어렵다는 것입니다.

그렇기에 이러한 공정을 유지하면서도 여러 번에 나눠 조금이라도 동작하는 소프트웨어를 만들어서 검증하고, 확인하고 회고해서 이를 바탕으로 조금씩 더 개발하는 방법으로 결과물을 만들어 내는 방법을 찾아냈습니다. 그것이 바로 ‘애자일’입니다.

하지만 애자일은 호락호락하지 않았습니다. 애자일 역시 기존 폭포수 과정을 거쳐야 했기 때문입니다. 또한 기존 공정의 리드타임을 줄이고 짧게 만든 결과물을 테스트하면서 지속 가능하게 유지해 나가는 일은 것은 워터폴보다 훨씬 더 어려웠습니다. 특히 단순한 개발 방식의 변화를 넘어 조직 문화의 변화까지 필요했습니다.

애자일이 어려운 이유

애자일 등장 이후 이를 잘 적용하기 위한 여러 방법들이 개발되었습니다. 이제는 유명해진 스크럼, 스프린트, 칸반, 회고 등과 같은 방법론입니다. 그렇지만 막상 도입을 하고 실천하기가 쉽지 않았습니다. 여러 가지 이유가 있지만, 대표적인 것을 몇 개 꼽아보겠습니다.

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

결국 어설프게 애자일 방법을 도입을 했다가 효용성을 체감하기도 전에 발생하는 비용들을 감당하지 못하게 됩니다. 전보다 짧아진 마감시간, 정리된 건 없는 불확실한 상황 때문에 회의만 길어지고, 산출물 관리는 엉망이면서, 중간 결과물의 품질은 낮아 불만이 나오는데, 여전히 일정은 맞추기가 버겁습니다. 결국, 이렇게 하는 것이 애자일한 게 맞나?라는 회의감이 커져가게 됩니다.

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

애자일은 그저 Best Practice를 찾기 위한 나침반

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

출처: 애자일 방법론

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

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

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

이 글 역시 그중 하나가 될 수 있습니다. 그렇지만 직접 애자일을 공부하고, 제 나름의 정의를 바탕으로 다시 해석해 보면서 애자일 원칙과 선언, 그리고 가치관에 대해 나름대로의 정의를 내릴 수 있게 되었습니다. 그래서 이를 여러분과 공유하고자 합니다.

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

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

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

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

그래서 저는 아래와 같이 1문장으로 애자일 방법론에 대해 정의했습니다.

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

1문장에 모든 것을 넣으려고 하니 투박하고 말도 조금 이상하네요. 그래서 추구해야 할 가치와 키워드 형태로 다시 한번 정의를 해보았습니다.

1) 지속적인 결과물

2) 업무의 시각화

3) 피드백(간격을 점점 줄여가는 것)

4) 모두가 함께 맞춰가는 방향성

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

애자일의 출발점은 고객에게서 더 빠른 피드백을 받아 잘못된 결과물이 나오지 않는 것이었습니다. 따라서 애자일의 핵심은 빠른 피드백에 있습니다. 실체가 없는 것을 말로 글로 전달을 하는 것은 쉽지 않습니다. 눈에 보이는 것 없이 말로만 주고받게 된다면 서로 같은 것을 보고 있다고 생각했지만 서로 다른 것을 생각할 수가 있게 되죠. 그렇기 때문에 중간중간에 내가 가는 방향이 맞는지 서로가 가고자 했던 방향이 맞는지 계속 확인을 하는 과정이 필요합니다.

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

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

앞서 언급했던 애자일의 키워드를 한번 다시 떠올려주세요.

지속적인 결과물, 업무의 시각화, 짧은 피드백 주기, 함께 맞춰가는 방향성.

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

1) 고객과 회사의 피드백을 넘어 회사 내 조직 간, 조직 내 팀 간, 팀 내 개인 간의 피드백의 주기가 빨라진다면 어떨까요?

2) 고객이나 회사가 생각하고 있는 것을 바로 확인할 수 있는 시스템이 갖춰져 있다면?

3) 결과뿐만 아니라 과정까지 시각화가 된다면 어떨까요?

4) 그래서 함께 일하는 사람이 모두 같은 방향을 보고 일한다면 어떻게 될까요?

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

그리고 이 모든 것은 바로 피드백의 간격을 줄이는 것을 목표로 합니다. 맞습니다. 저의 애자일 방법론의 핵심은 바로 ‘피드백의 간격 줄이기’입니다!

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

피드백이 느리면 그 시간 동안 내 생각과 내 구현물에 대해 애착이 생깁니다. 애착이 생겨버린 생각과 구현물은 곧 나 자신이 되어 부정적인 피드백을 자신과 일치시키게 되어 방어적으로 대하게 됩니다. (@NOTE: 여기서 애착은 자기 생각에 갇혀서 나오지 못하는 것을 의미합니다.)

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

우리가 프로덕트를 위한 작업을 한다고 상상해 보겠습니다. 그리고 팀에서 좋은 아이디어가 나와서 한번 실제로 구현해 보기로 마음을 먹었습니다. 하지만 이것을 구현해서 결과물을 보여주는 데까지 꽤 오랜 시간이 걸리는 상황입니다.

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

자, 시간과 자본을 써서 아이디어를 구현해 결과물이 나왔는데, 좋지 않은 것으로 판단이 되면 어떻게 해야 할까요? 우리는 새로 아이디어를 내거나 수정을 하는 등 새로운 방법을 찾아야만 합니다. 그러나 여기에 매몰비용이 이미 많이 들어갔기에 그러한 결정을 쉽게 할 수가 없게 됩니다.

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

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

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

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

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

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

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

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

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

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

애착을 가진 사람은 상대방의 피드백을 원하면서도 반대 의견을 받기 싫어합니다. 왜냐하면 내가 애써 생각했던 내용에 대해 부정적인 의견을 듣는 걸 반가워하는 사람이 거의 없기 때문입니다. 내 피드백이나 의견이 전달이 되지 않는다는 것을 몇 번만 경험을 하면 그 상황이 아니라 '이 사람은...', '이 회사는...' 하는 식으로 생각이 발전을 합니다. 학습된 무력감은 더욱더 피드백과 상호작용을 하지 않는 식으로 악순환이 이어지고, 나중에 이 문제를 해결을 하겠다고 해도 이미 불신을 가졌기 때문에 개선을 하기가 정말 어렵습니다.

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

저는 이것이 애자일을 가장 쉽게 적용하는 방식이라고 생각합니다.

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

우리의 생각을 키우고 발산하는 과정은 보통 즐겁습니다. 그렇지만 선택과 결정을 해야 하는 순간이 오면 대치되는 의견이 생기고, 서로 간에 입장 차이가 생길 수밖에 없습니다. 사실 대부분의 의견은 자기만의 합리적인 근거와 추론 과정이 존재하기 때문에 옳고 그름의 문제보다는 선택과 취향의 문제인 경우가 많습니다.

어느 정도 논의가 진행되었다면 중간 결과물이 나올 때까지 더 이상 길게 가져가서는 안 됩니다. 결과물이 없는 상황에서의 논의는 결국 일치할 수 없는 각자만의 상상을 가지고 이야기를 하기 마련입니다. 내 생각에 애착이 생기고, 내 생각을 지키기 위해 상상 속의 결과물을 가지고 서로를 공격하는 양상으로 이어질 수 있기 때문입니다.

이것이 애자일에서 결과물을 빨리 선보여야 하는 이유기도 합니다.

기존에는 구현하는데 들어가는 비용, 특히 수정을 하는데 들어가는 비용을 줄이기 위해 사전에 많은 논의를 통해 수정이 필요 없는 좋은 방법을 찾아내는 것을 우선시했습니다. 하지만 현실은 오랜 논의로 최선의 방법을 선택해 결과물이 나오더라도 수정을 해야만 하는 상황이 오기 마련입니다. 무엇보다 한꺼번에 많이 만들게 될 경우, 오히려 수정을 유연하게 대응할 수 없는 문제점을 발견하게 되었습니다.

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

주객이 전도되지 말자

앞에서도 이야기했지만, 최종 결과물이 나오고 수정하는 것은 그전에 수정하는 것에 비해 훨씬 더 비용이 비쌉니다. 한번 출시를 하고 나면 출시하기 전보다 훨씬 더 많은 개발 비용이 발생합니다. 그래서 과거에는 비용을 아끼기 위해 더 많이 예측하고, 더 많이 생각하고, 더 검토를 하고자 노력했습니다. 하지만 시간이 지나면서 기존 방식 과정이 길어질수록 더 실패할 확률이 높았습니다.

예측을 하거나 미리 논의를 하는 것 자체가 나쁘지 않습니다. 다만 일정 이상의 예측과 논의는 무의미하며, 오히려 잘못된 판단과 경직된 팀 문화를 만들어 낸다는 걸 깨닫게 된 것입니다.

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

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

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

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

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

내가 어디까지 일을 했고, 할 일이 얼마나 남았으며, 나 말고 다른 사람들은 지금 어떻게 하고 있는지 알 수 있다면? 우리는 훨씬 더 주도성을 가지고 업무를 할 수 있습니다. 혹시 무언가 떠오르나요? 맞습니다. 이러한 아이디어로 만들어진 애자일 방법론 중 하나가 ‘칸반’입니다.

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

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

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

서로의 결과물이, 서로의 피드백이 되는 시스템

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

이 모든 것들이 적절히 잘 맞물려서 피드백 주기가 빨라진다면 정말 게임과 같은 개발 환경에서 일할 수 있습니다. 내가 생각한 것이 다른 사람의 의견과 합쳐지고, 디자인이 더해져서 중간 결과물이 만들어지고, 다시 이걸 보면서 의견을 모으고, 구현이 되고, 또 고치면서 성장하는 결과물을 다 같이 지켜보는 것은 큰 즐거움 혹은 보상이 될 것입니다.

이를 위해서는 내가 한 일의 결과가 다른 사람의 피드백이 되고, 다른 사람의 피드백이 곧 내 일을 하게 하는 동력이 되도록 해야 합니다.

끝으로

개발은 코딩도 중요하지만, 나중에는 협업이 참 중요해집니다. 결국 함께 일하는 것이 중요하기 때문입니다. 그러나 개발자에게 이러한 협업을 가르쳐주는 것들은 잘 없는 것 같습니다. 처음에는 개발 스킬을 쌓는 것이 당연히 중요하지만, 나중에는 함께 일하는 방식에 대해 고민을 하게 되는 시기가 올 것이라고 생각합니다.

애자일은 변화에 대응하고 고객의 피드백을 받으면서 제대로 된 결과물을 만들기 위해 제품을 조금씩 만들어가면서 빠르게 고쳐 나가는 개발 방법입니다. ‘빠른 피드백을 바탕으로 제대로 된 결과물을 만들자’라는 생각은 단순히 개발 방법을 넘어 애자일한 조직 문화로까지 발전하게 되었습니다.

개인적인 경험이지만, 정말로 잘 된 애자일 방식으로 일하면 일이 너무너무 재밌습니다. 내 의견이 받아들여지고 다 같이 힘을 모아 결과물이 계속 성장해 나가는 걸 보면 뿌듯합니다. 하지만 언제나 이렇게만 되는 것은 아니었습니다. 어렵게 쌓은 시스템은 또 어떠한 이유로 잘 동작하지 않게 되고 아직도 시행착오를 겪고 있습니다. 그렇지만 시행착오에서 겪은 경험 역시 계속 저를 성장시키고 있습니다.

앞으로도 계속 즐겁게 일을 하고 싶기에 어떻게 해보면 좋을지 돌이켜보면서 이번 글을 작성했습니다. 글을 통해 비슷한 고민을 하고 있는 개발자들에게 조금이나마 공감이 되기를 바랍니다.