애자일 워크숍 회고

애자일 워크숍 회고

UNSEEN에서 진행한 온보딩 프로그램 중 가장 첫 번째인 애자일 워크숍에 대한 회고를 작성하려고 한다.

원래는 따로 키워드로 기록만 하거나 리뷰만 진행하지만, 생각 이상으로 값진 경험을 했기 때문에 이를 기록하고, 공유하고 싶어졌다. 거기서 배운 내용을 꼭 회고를 통해 개념을 좀 더 확장하고 내가 알고 있는 내용과 연관 지어 실제로 활용해 보는 것을 목표로 한다. (지식의 전이)

워크숍은 총 2일동안 진행되었고, 1일 차에는 기본적인 애자일의 개념, 원칙들과 그와 연관되어 집중(몰입), 좋은 흐름을 가진 팀 등 2일 차에는 스크럼을 적용해 보는 방법과 왜 어려운지를 이해하는 과정의 연속이었다. 특히 이론과 실습을 동시에 진행하며 몸으로 체감할 수 있었다.

정리할 내용이 매우 많아서 이를 내 생각과 키워드로 정리해 보려고 한다. 빼먹거나 틀린 정보가 있을 수 있다.

사실 가장 필요하다고 생각하는 학습한 이후의 의견교류이다. 내 생각에 맞춰 정리한 내용을 다른 사람과 대화를 통해 더 확장하고 싶다.

• 애자일을 왜 안 할까?
• 요즘 게임 트렌드에 대한 애자일적 관점
• 집중과 흐름의 키워드
• 몰입과 의도적 학습
• 투명하고 솔직한 피드백
• 실패는 빠르고 요란하게
• 객체지향과 애자일
• 일상의 적용

시작하기 앞서 이번 워크숍을 이해하기 되게 도움이 되었던 책인 함께 자라기 책을 읽고 정리한 내용임을 밝힌다.

애자일을 왜 안 할까?

코치님의 강의를 들으며 딱 든 생각은 “그렇다면 왜 애자일을 적용하지 않을까?”였다. 물론 대기업이나 좋은 팀에서는 이미 적용하고 있고 애자일 자체도 오래된 만큼 자신의 팀에 맞게 적용하고 있을 것이다. 하지만 그렇지 않은 팀이나 조직에서는 왜 적용하지 않을까? 그 이유는 무엇일까?

트레이드 오프의 관점으로 본다면 애자일 자체에 대한 러닝커브를 꼽을 수 있을 것 같다. 여기서 말하는 러닝커브란, 애자일 자체의 대한 개념도 있지만 애자일 원칙에 맞게 직접 해보면서 그 과정에서 뭔갈 얻어야 하는데 인간의 특성상 변화와 도전에 대한 저항 때문에 쉽지 않다는 것이다. 내 생각엔 이 벽이 가장 큰 러닝커브가 아닐까 싶다.

또 다른 과점으론 코치님은 에자일 스크럼을 인간이 무엇을 만드는 과정 자체를 타인과 협력할 때 가장 좋은 형태로 나타낸 메타 모델이라고 했다. 이 과정을 우리는 공 옮기기, 발걸음 회사와 같은 매우 단편적인 사례로 체험했다. 좋은 발걸음 품질, 공 옮기기 횟수의 증가

하지만 실제 개발 과정은 그렇게 단순하지 않다. 게임개발을 예로 들면, 게임을 만들기 위해서는 아트, 디자이너, 프로그래머가 모두 협력해서 게임을 만들어야 한다. 그 과정에선 정말 많은 일이 일어나고 불확실성도 제어가 힘들 만큼 커진다. 이를 자기주도적으로 제어하려면 각자의 역할을 이해하고 서로의 역할에 대한 이해도가 높아야 한다. 이것이 애자일이 잘 실천되려면 필요한 것이다. 그렇다면 이것이 애자일의 트레이드 오프라고 볼 수 있을까?

즉, 직무가 달라도 공통된 목표를 모두가 바라봐야 하고 모두의 목표치가 같아야 한다.

조금은 극단적일 수 있지만, 내 생각엔 아트가 프로그래머의 일을 할 수 있고, 기획이 아트의 일을 할 수 있고, 프로그래머가 기획의 일을 할 수 있다면 애자일을 잘 실천할 수 있지 않을까? 하지만 현실은 그렇지 못하기 때문에 (특히 동아리, 사이드 프로젝트의 경우) 어느 정도 관리자가 필요하다는 입장이다. 발걸음 회사의 사례가 아닌 PM과 같은 전체적인 매니징이 필요하다는 것이다.

발걸음 회사도 자기주도형/관리자형으로 양분이 아닌 딱 한 명의 관리자만 존재했다면 자기주도보다 더욱 좋은 결과가 나왔을 것이다. (모두 바깥쪽으로 질서에 맞춰서 알아서 도세요~)

크래프톤 정글은 아마 이런 과정을 이해했기 때문에 게임 개발자라는 명목에 아트, 사운드, 기획, 프로그래밍을 구분하지 않고 사람을 뽑았기 때문에 성공적인 결과가 나온 게 아닐까?

그렇다고 단편적인 사례로 추상화한 공 옮기기, 발걸음 회사가 틀렸다고 볼 수는 없다. 사람이 쉽게 이해하려면 개념 자체가 단순해야 하며 실제 개발 과정도 그렇게 흘러가야 한다. Task를 나누는 과정에서 스스로 쉽다고 느끼는 수준까지 분할해야 하는 것은 정말 중요하다고 느끼고 그것은 애자일에서도 많이 등장한다.

정리하자면 한 가지 개념에 대해서 이렇게 이해하기 쉽게 세분화했다고 해서 이를 실제 프로젝트에 적용하긴 어렵다고 판단하는 것은 도요타의 사례와 똑같은 문제라는 것이다. 공 옮기기, 발걸음 회사에서 얻은 내용은 단순하게 “애자일이 좋다”가 아닌 그 과정에서 어떤 상호작용으로 흘러갔는가에 대한 흐름이라고 할 수 있다.

적용하는 것을 두려워하기 보다 일단 해보고 피드백을 받고 수정하고 또 피드백을 받고 수정하고 이 과정 자체를 회고하고 더 좋은 결과를 내기 위해 노력하는 것이 중요하다. 이것이 애자일의 원칙이기 때문이다.

요즘 게임 트렌드에 대한 애자일적 관점

UNSEEN 면접 질문 중 요즘 게임에 대한 생각을 묻는 질문이 나왔었다. 나는 기본적으로 스토리게임을 좋아하기 때문에 요즘 게임 트렌드에 대해서 굉장히 아쉬움을 느끼고 있었다. 스토리가 전혀 빠진 도파민 짬뽕 같은 게임이 많이 나오고 있었기 때문이다. (팰월드, 버섯커키우기 등)

하지만 그 게임들을 개발한 개발자들은 시대의 흐름을 잘 읽는 리더라는 생각이 든다. 내가 스토리 인디 게임을 좋아한다고 해서 쉽게 말해선 안 된다. 그 게임을 소비하는 소비자가 숫자로 증명되고 어찌 보면 내가 마이너일 수 있기 때문이다.

• 팰월드 개발자의 글
  • 애자일의 관점으로 본다면? 게임 제작자의 관점으로 구조 역학 미학으로 개발 과정을 볼 수 있다. 물론 퍼플리셔와의 마찰도..

이런 게임의 제작 과정을 애자일로 바라본다면? 만약 스토리가 중심인 게임을 개발해야 한다고 하면, 매우 쉽게 폭포수 모델로 빠질 가능성이 있다. (애자일로 시작하더라도) 이유는 스토리를 먼저 짜고 개발이 진행되어야 하는데, 스토리는 기승전결이나 스토리에 맞는 또 다른 프레임워크가 있기 때문이다. 이는 애자일에서 당장 피드백을 받거나 실행 가능한 결과물을 뽑기 어렵기도 하다. (소프트웨어적으로)

만약 어찌해서 애자일형태로 스토리게임이 개발이 진행되더라도 앞서 말한 서로 직무간의 이해가 더 깊어져야 한다. 한 팀이자 덩어리로 잘 굴러가려면..

하지만 팰월드나 버섯커 키우기의 경우 애자일 원칙이나 게임의 본질에 맞게 실행가능하고 재미에 초점을 잘 맞춘 게임이라는 생각이 든다. 영화를 예로 본다면 재밌는 히어로 영화와 좋은 메시지를 던지는 영화? (아이언맨 vs 추락의 해부) 개발 과정을 머리로 스토리가 들어갈수록 기능에 제한적이게 되는 것 같다.

정리하자면, 실제 팰월드의 개발 과정을 알 수 있듯이 어디에 집중했고 빠른 피드백과 수정이 어떻게 일어났는지를 한눈에 알 수 있다. 애자일이 스토리 게임에 제한적이라기 보다 개발과정에 어떻게 적용하면 좋을지 한번 생각해볼 수 있을 것 같다.

집중과 흐름의 키워드

공통된 목표, 타임 박스, Task , 환경, 고정된 팀, 재량권, 투명한 피드백

가장 처음 집중하는 3Keyword로 집중/몰입되는 이유에 대해서 가장 먼저 다뤘었다. 2분간 자신과 상대방을 서로 알아가는 시간을 가졌는데, 이때 어떻게 그 상황에서 상대방에 몰입할 수 있었는지는 다음 키워드로 설명 가능하다.

• 공통된 목표: 주어진 목표가 같았다.
• 타임 박스: 시간이 정해져 있었다.
• 환경: 팀원들과 같은 환경에 있었다. (거리)
• Task: 목표를 수행하기 위한 Task가 있었다.

처음 그 실습에선 칵테일 파티 효과가 생각났는데, 이 원인을 분석해보니 위와 같은 키워드로 정해진다는 사실을 알았다. 나는 주로 문서작업을 많이 해야 할 때 카페에 가서 뽀모도르를 사용하여 작업을 한다. 협력이 아닌 개인의 입장에서 적용한다면 목표를 정리할 문서, 타임박스를 뽀모도르, 환경을 카페,Taks를 세분화한 문서로 볼 수 있을 것 같다.

최근 프로젝트에서도 집중을 위해 공동 작업 시간을 가지는 것을 지키고 있는데 효과적이었다.

그렇다면 애자일의 자기주도적, 경험적인 팀을 만들기 위해선 어떻게 해야 할까? 이것을 위해 앞서 말한 발걸음 회사라는 실습을 진행하였다. 1 대 1 관리자와 개발자 그리고 개발자로만 진행한 실습으로 왜 자기주도적인 팀이 좋은지를 다뤘다. (흐름에 관한)

• 고정된 팀: 팀원이 고정되어 있었다.
• 재량권: 팀원들이 제한된 범위내에서 자유롭게 행동할 수 있었다.
• 투명한 피드백: 피드백을 받고 수정하는 과정이 있었다.
• 공통된 목표: 목표가 공통되었다.

최근에 프로젝트의 기획자가 취업을 하게 되면서 그 자리의 공백이 생겼다. 나는 원래 팀원은 교체 가능하다는 냉소적인 입장이었지만, 그 팀원이 인수인계, 문서화를 잘 해놨다고 해서 새로운 팀원이 들어오기까지 비용이 정말 컸다. 왜 사람 자체가 정리가 잘된 문서라고 하는지 알 수 있었다.. 고정된 팀

최근에 읽은 프로그래밍 심리학에서도 민주적이고 자율적인 팀 일수록 신입에 대해서 냉소적이고, 관리자 주도적인 팀일수록 신입을 잘 받아들인다고 한다.

• 프로그래밍 심리학 2장 일부 발췌

민주적으로 조직된 팀은 승진, 사직, 병, 죽음, 임신, 출가 등 어떤 이유로든 구성원을 잃을 때 받는 충격을 잘 견디는 경향이 있다.

팀원끼리 공유와 의사소통이 활발하기 때문에 업무에 대한 이해도가 높을 수밖에 없다.

하지만 새로운 구성원에 대해서는 받아들이기 힘든 것으로 알려져 있다.

이미 팀원끼리 강한 결합도를 가지고 있었기 때문에 (인간 문서와 같이) 이런 관계를 다시 맺는 것이 어려울 것이다.

반대로 권위적인 팀의 구성원들은 새로 온 사람에게 아주 친절하고 호의적인 반면, 민주적으로 조직된 팀은 다소 냉정하고 비우호적인 모습으로 비춰지곤 한다.

모든 일을 오로지 단 한 사람의 리더가 조직하고 관리할 정도로 권위적인 성향이 강한 팀에서는, 구성원 중 하나가 이탈하여 생긴 구멍이 그대로 방치된다.

오직 리더만이 남은 구성원들에게 일을 다시 분배하는 데 필요한 정보를 쥐고 있다.

이런 부분이 재량권으로 드러나는 것이고 애자일에서 Task에 대해서 스스로 Assignee하는 것으로 생각한다.

투명하고 피드백은 뒤에서 더 자세하게 다루겠지만 실제 투명하다, 솔직하다는 것에 대해서 어디까지 다뤄야 하는지가 예매할 수 있다. 성장에서도 다루지만, 피드백은 정말 중요하다. 그래서 대부분 학습이 협력적으로 일어나야 한다고 하는 것이다. 이것에 관한 내용은 함께 자라기의 학습 파트나 실리콘 밸리의 팀장들(과격한 솔직함)의 솔직함에 대해서 다루는 파트를 참고하면 더 좋을 것 같다.

몰입과 의도적 학습

1일 차 마지막에 몰입과 의도적 학습에 관한 내용을 다루는 데, 개인적으로 이 내용을 더 못 들었던 것이 아쉬웠다. UNSEEN에선 애자일 스크럼으로 프로젝트가 진행되기에 그 과정 자체를 설명하는 것이 먼저였기에 그랬지만, 의도적 학습은 나에게 정말 좋은 효과가 있었기 때문에 더 듣고 싶었다.

• 의도적 학습에 관한 내용

투명하고 솔직한 피드백

정말 유익하다고 생각했던 피드백 파트이다. 피드백은 성장에서도 정말 중요하게 작용하지만, 이를 협력관점에서 본다면 제품에는 정말 큰 영향으로 작용한다. 특히 빠른 피드백

코치님은 피드백을 총 두 가지 단계로 가장 먼저 피드백의 제품을 생명체로 바라보는 것부터 시작해야 한다고 한다. 이것이 첫 번째 존중의 시작이다. 누군가는 그 제품을 최선을 다해서 만들었기 때문에 그 제품에 대한 말은 전부 생산자에게 향하는 말이 된다.

첫 번째는 “~를 계속했으면 좋겠어요”와 같이 해당 제품의 좋은 부분을 먼저 나타내야 한다는 점이다. 두 번째는 “00를 000로 변경하면 00에 더 좋을 것 같아요”와 같이 명확한 피드백을 전달하는 것이 중요하다.

이를 잘 활용하려면 팀의 피드백 컨벤션이나 코드리뷰 컨벤션으로 정해두면 좋을 것 같다. 실제로 팀에 적용해 보려고 이번 팀 회의 때 좀 더 정리해 볼 생각이다. 마치 수술방에 들어가기 전 리스트처럼 좀 더 명확하게 정리해 두면 좋을 것 같다.

이쯤 되면 사실 항상 드는 생각은 더 귀찮을 것 같다는 생각이 들 수 있지만 돌아가는 길이 가장 빠른 길이다.

실패는 빠르고 요란하게

코치님의 대부분 실습에서 지속해서 언급하는 말이 있다. 바로 실패가 나올수록 이 학습에 효과적이라는 것이다.

• 프로그래머의 길, 멘토에게 묻다. 일부 발췌

천재성은 종종 잘못 이해된다. 그것은 탁월한 지적 능력의 문제가 아니라 성격의 문제이다. 천재성은 무엇보다도 기꺼이 실패를 인지하고, 미봉책으로 가리려 하지 않으며, 변화하고자 하는 의지를 필요로 한다.
그것은 실패에 대한 의도적이고 심지어는 강박적인 성찰과, 새로운 해법에 대한 지속적인 탐색에서 비롯된다.

실패를 두려워하지 않으려면 실패에서 오는 배움을 깨닫고 그것이 오히려 좋은 경험이 될 수 있음을 인지해야 한다.

이번 실습으로서도 실패가 왜 더 기억에 잘 남는지 몸으로 잘 체감한 것 같다. tt파이트 게임에서 의견을 조율하는 과정에서 그렇게 성공적이지 못한 게임을 만들었는데, 실패한 원인을 계속해서 생각하게 되는 과정 자체가 내성법으로 이어지는 것 같다.

5명의 의견에서 모두 최선의 결과를 만들고 하고 싶어 하는 마음에서 계속해서 더 좋은 결과가 있지 않을까? 라는 의문이 들었고, 이를 애자일처럼 바로 바로 뭔갈 해보면서 즉각적인 피드백이 필요했지만, 최선의 결과에 대한 욕심과 걱정으로 인한 실패가 있었던 것 같다.

실패를 두려워하지 않으려면 실패에서 오는 배움을 깨닫고 그것이 오히려 좋은 경험이 될 수 있음을 인지해야 한다.

객체지향과 애자일

최근 객체지향의 관련된 책을 많이 읽거나 공부해서 그런지 애자일의 상당 부분과 닮아있다고 느꼈다. 예를 들면 객체지향의 “처음부터 다 만들 생각하지 마라” (처음부터 자동차를 만들지 말고 보드부터 시작하라~)와 같은 설계단계에서 말하는 이론적인 개념과 개발 과정도 객체지향적으로 의존성을 분리하여 이후에 나올 불확실성에 대응하기 위한 코드나 SRP와 같은 세분화 전략 등 개념적이 부분이나 실제 적용되는 사례들도 굉장히 유사하다.

그래서인지 객체지향 개발환경에선 애자일이 유리하고 마찬가지로 애자일이 도입된다면 자동적으로 객체지향 스타일을 따라가게 될 것 같다.

좀 더 깊게 설계 전략에서도 협력, 책임, 역할도 같은 맥락에 속해있다고 생각이 든다.

실제로 이 부분이 궁금해서 저녁 식사 때 코치님에게 물어보니 상당부분이 영향받았다고 한다.

일상의 적용

이러한 애자일 개념을 어떻게 일상에 적용할 수 있을까?

나는 크게 두가지 방법을 내 일상에 적용하고 있는데, TODO의 관리와 스터디 그룹에서의 활동이다.

TODO의 관리

나는 나의 일정을 모두 깃허브에 기록하는 편인데, 모든 일정을 Task로 관리하여 Board에서 관리한다. 각 일정에선 더 depth를 깊이 가져가 세분화 하기도 하고 각 Task에 대한 우선순위를 정하고 이를 하루의 Todo로 가져와서 기록한다.

이런 일정을 정리하거나 불확실성이나 계획오류에 자주 당하지 않게 도움이 된 박종천 개발자님의 GPAM기법을 참고하여 적용하고 있다.

순서로 정리하면 다음과 같다.

• 일정이 생기면 Task로 만들어서 Board에 추가한다. (대부분 2주안에 해야하는 스케줄)
• 하루가 시작하면 자동화해 둔 스크립트를 통해 하루의 Todo를 생성한다.
• 각 Task중 오늘에 처리해야하는 일정을 등록하고 이를 기록한다.
• 종료된 Task는 Close한다.

2주의 추정과 하루의 실행 그리고 가끔의 이런 회고를 통해 수정한다.

이건 내가 계속해서 수정하다가 결국 찾아낸 나만의 애자일 방법으로 볼 수 있다. 안정기까지 약 2년이 걸린 것 같다.

스터디 그룹에서의 활동

내가 진행하는 스터디는 총 5개로 진행되고 있다. 대부분 애자일 스크럼행태로 진행되는데 간단한 몇 가지만 소개하자면 다음과 같다.

아카데미 컨퍼런스

작년부터 꾸준하게 참여중인 개발자 책 읽기 모임으로 정직하게 애자일 스크럼 형태로 진행한다. 2주간 읽을 분량을 정하고 읽은 내용에 대한 정리와 논의 내용을 들고 와 PR을 올리면 그에 대해서 리뷰를 진행한다. 이후 정해진 날짜에 모여 토론을 진행한다.

이 모임의 핵심은 사실 책 읽기가 아닌 정해진 날짜에 모여 책에 대해서 읽은 내용을 공유하는 것에 있다. 사람은 자신의 시선으만 경험하기에 타인의 경험인 생각보다 더 값진 경우가 많다. 실제로 책에 대한 내용보단 책의 내용을 토대로 자신의 경험을 나누는 자리라고 생각하면 된다.

애자일로 풀어서 본다면 2주간의 추정을 통해 직접 Task를 설정해 읽고 PR을 통해 사전에 논의하고 정해진 날짜에 모여서 회고를 진행한다.

그외

그 외에도 모각코, 북클럽, 아카이브 등등의 스터디가 있지만 이는 나의 스터디 회고록에 정리가 되어 있어서 해당 링크로 마무리한다.

• 스터디 회고록

다른 적용 방안

진행 중인 UNSEEN에서 적용을 고려해 본다면 데일리 미팅에 체크인을 도입하여 1기의 노션처럼 단순 일정 공유가 아닌 협력자의 감정을 공유하는 것도 좋을 것 같다. 데일리 미팅을 할 때 자신의 하루 기분을 이모지로 나타낸다거나 글을 적는 방식도 좋다.

현재 내가 팀장으로 있는 팀은 좀 더 정리가 필요하겠지만, 이번 워크숍에 있는 대부분의 내용을 천천히 적용해 볼 예정이다.

정리

나름 키워드나 내 생각을 정리하여 적긴 했지만 조금은 중구난방인 것 같다. 이번 워크숍이 내 상상보다 더 유익했던 탓인지 더 많은 내용을 적고 싶었던 것 같다. 사실 함께 자라기에 등장하는 애자일 특강? 워크숍의 비용이 1인당 몇 백을 넘는 것을 보고 조금은 부정적이었지만 왜 그렇게 투자를 하고 소비자가 있었는지 잘 알 수 있었다.

나도 이렇게 강의를 들은 내용을 다시 회고, 재작성하지만, 이것은 그렇게 중요한 것이 아니다. 개념을 안다고 달라지는 건 크게 없다. 애자일 원칙에 맞게 빠르게 프로젝트에 적용해보고 그 결과물을 회고하는 것이 중요하다.

이제는 좀 감이 잡히니 실패를 두려워하지 않기를 바라며 이번 회고를 마무리한다.