지금껏 칸반과 스크럼, 스크럼과 XP과 같은 책들을 통해 애자일 방법론을 접해왔다. 지금까지 다니던 회사에서는 JIRA의 칸반 보드를 활용하고, 약식이지만 매주 스크럼을 진행하며 작업을 정리했다. 그 과정을 통해 ‘애자일’에 대한 대략적인 인상 정도는 받을 수 있었다. 짝 프로그래밍을 하고, CI를 활용하고, 매일 작업을 사람들과 공유하는 정도?
하지만 새로 진행하는 프로젝트에서 직접 애자일 방법론을 도입하려고 보니, 사실 막막함이 앞섰다. 약식으로나마 칸반 보드를 만들고 매주 회고를 목적으로 한 미팅을 계획했지만, 막상 이런 방식이 실제로 생산성에 얼마만큼의 이점을 주는지 체감하기가 힘들었다. 세팅하는 데에 긴 시간을 투자했지만, 팀원들은 CI 결과를 확인하지 않고 merge를 하곤 했다. 무엇이 잘못됐는지 생각해 볼 차례였다. 마침 개발자 한 달에 책 한 권 읽기 모임에서 1월에 읽을 책이 김창준 님의 함께 자라기였다. 비록 신청하려고 보니 인원이 가득 차서 막상 모임에는 참석 못 했지만.. 덕분에 이 책을 접할 기회가 생겼고, 읽는 동안 많이 깨닫고, 반성할 수 있었던 것 같다.
지금껏 회사라는 조직 안에서의 ‘애자일’만을 생각해왔는데, 이 책의 특별함은 애자일의 적용 범위를 삶 전체로 확장시켜 이야기한다는 점이었다. ‘성장’, ’협동’이라는 키워드에서 마지막 ’애자일’까지 3부의 주제가 이어지는데, 지루할 틈 없이 흥미로운 사례들로 채워져 있다. 무의식적으로 내가 갖고 있던 ‘잘못된 직관’을 깨닫고, 성장의 방향을 찾게 해 준다.
책을 읽으면서 밑줄 치고 싶었던 부분을 골라 짧은 생각과 함께 정리해 보려고 한다. (다만 이 글은 책의 요약본이 아니고, 비교적 쉽게 읽히는 내용과 분량인만큼 한 번쯤 책을 읽어보는 것을 권한다)
야생 학습
학교라는 공간을 벗어나 내가 처음 접한 조직은 어느 반도체 대기업의 테스팅 부서였다. 4주 인턴십으로 살짝 들여다보고만 온 게 다지만, 회사라는 공간에서 처음으로 삶에서 학습이 목표가 아닌 도구가 되는 것을 경험했기 때문이다. 대기업의 특성상 주어진 업무는 꽤 명확했지만, 경험이 부족한 사원들이 스스로 진행해야 하는 학습의 과정은 그렇지 않았다. 여러 부류의 사람들을 봤다. 정말로 인상적이었던 건, 그런 곳에서 두각을 나타내는 사람들은 결코 내가 익숙해져 있던 ‘모범생’의 모습이 아니었다는 거다. 자리에 잘 안 앉아있고, 사람들과 잘 어울리는 사람들이 결과적으로는 좋은 성과를 내는 모습을 목격했다. (나중에서야 자리에 잘 안 앉아있는 이유가 다른 사람들의 업무를 도와주거나 도움을 구하러 가는 것을 알았다) 그렇지만 나는 도구로써의 학습에 길들어 있지 않았다. 무딘 날을 들고 초원에 던져진 초식동물이 된 기분이었다. (…) 사실 그 기분은 이후 1년 동안 함께했던 스타트업에서도 계속 이어졌다.
처음 내게 주어진 업무는 요구 사항이 확정되지 않은 웹 개발이었다. 프레임워크 선정에서부터 서버, 프론트엔드 스크립트를 혼자서 작성해야 했다. 그 때에 ‘혼자 공부하고, 혼자 개발하는 것’이 당연하다고 생각했던 것이 아쉽다. 웹 상에 돌아다니는 자료들로 기본적인 웹 개발 프로세스를 익히고, 결과물을 만들어내기는 했지만, 이상하게도 나 스스로 성장했다고 말하기에는 너무나 부족하다는 생각이 들었다. 새로운 라이브러리를 학습하고, 단순히 더 많은 함수들을 쓸 줄 안다고 내가 개발을 ‘잘 하게 되는 것’은 아닌 것 같았다.
자라고 싶었던 것이 아니라 잘 하고 싶었기 때문이다
책을 읽고, 그때의 나를 돌아보면서 진단한 문제점이었다. 당장 그럴듯한 결과물을 보여주고 싶어서, 코드의 품질이나 설계에 대한 고민은 뒷전이 되었다. 끝난 작업에는 더이상 손을 대고 싶지 않은(?) 기분에 사로잡혀 다시 보지 않았던 것도 성장의 큰 저해 요인이었다. 그 결과 같은 실수를 반복하고, ‘아 어디서 본 것 같은데..’ 하지만 정작 바로 쓸 수는 없는 코드가 늘어갔다.
수십 년 동안 한 가지 일을 하면서 전문가가 안 되는 비결이 있다면 타당성과 피드백이 부족한 환경에서 일하는 것입니다.
실수를 조기에 발견할 수 있는 환경을 만들고, 같은 동작을 하는 코드도 더 우아하게 쓸 수 있는 방법을 고민한다면 조금 더 괜찮은 개발자가 될 수 있을 것 같다. 그리고, 만들어진 어플리케이션의 버그를 찾거나 사용성을 개선하기 위해 노력하는 것도 정말, 정말로 중요하다.
몰입 경험하기
우리는 실력과 난이도가 적절히 맞추어진 일에 대해 강한 몰입감을 느낀다고 한다. 내 실력보다 낮은 난이도의 일에는 쉽게 지루함을 느끼고, 내 실력보다 지나치게 높은 난이도의 일에는 불안감 때문에 쉽게 집중이 안 되는 경우가 많다. 그런 경우에 대처하는 방법을 저자가 귀띔해주었는데, 요즘 내가 조금씩 시도하고 있는 것들도 포함되어 있어서 꽤 뿌듯했다. 이렇게 정리해두면 의식적으로 더 많이 시도해 볼 수 있을 것 같다.
-
지루함을 느끼는 경우 (1) 실력 낮추기: 고레벨 게임 캐릭터라면 초급 던전을 다시 깨야 하는 일이 생길 때가 가끔 생길 것이다. (노가다 퀘스트!) 귀찮다고 하품만 할 게 아니라 입고 있던 장비를 벗고 맨몸으로 달려가면, 한 방 실수로 맞고 피가 쭉 닳는 것을 보며 즐거운 스릴을 맛보게 될 것이다. 아, 그리고 요즘 Mac을 사용할 때에는 의식적으로 단축키를 외워서 사용한다. 글을 쓰거나 개발을 할 때 최대한 손의 동선을 줄이려는 노력인데, 확실히 간단한 작업을 할 때에도 단축키로 흐름이 빨라지거나 하면 소소한 즐거움이 느껴져 일을 더 재밌게 할 수 있었다.
-
지루함을 느끼는 경우 (2) 난이도 높이기: 같은 작업을 할 때에도 난이도를 높일 수 있는 방법은 수도 없이 존재한다. 실험의 prototype으로 사용하는 간단한 어플리케이션을 만들 때에도, 익숙한 jquery를 사용해서 기계적으로 찍어내는 방법도 있지만, 새로운 프론트 프레임워크를 활용해본다던지, webpack을 붙여서 개발 중 hot reloading을 사용할 수 있도록 세팅한다던지 하는 선택도 있을 수 있다. 앞으로의 목표는 남들보다 일을 좀더 효율적으로 하기 위해 내가 직접 만들어 쓰는 나만의 도구를 여러 개 만들어 보는 것이다. 어떤 작업에 반복적이고 지루한 요소가 들어있다고 생각되거나, 패턴이 있다고 생각되면 바로 프로그램을 작성해 보는 습관을 길러야겠다.
-
불안함을 느끼는 경우 (1) 실력 높이기: 이전의 내가 가장 어려워하던 게, 내가 모르는 것을 남에게 물어보고 도움을 구하는 것이었다. 책을 보거나 검색을 통해 답을 구하는 게 심리적으로는 내게 더 쉬운 선택이었다. 그렇지만 짝 프로그래밍을 하는 습관이 생기면 그런 것에 대한 두려움이 조금은 옅어지는 것 같다. 분명히 부족하고 고칠 것이 많겠지만, 그렇기 때문에 다른 이들에게 내 코드를 공개하고 도움을 받아야 하는 것 같다. 그리고 요즘은 좋은 코드 분석 툴(Code Climate 같은)이나 linter도 사용할 수 있고, REPL 환경도 있으니 당장 속한 팀이 없을 때도 충분히 피드백 받을 수 있는 도구나 사회망은 열려 있어서 안심이다.
-
불안함을 느끼는 경우 (2) 난이도 낮추기: 작업이 너무 어렵게 느껴진다면, 이것을 핵심만 남기고 단순화시켜서 먼저 쉬운 버전을 완성하는 방법이 있다. 최근에 trie 데이터 구조를 golang으로 작성하면서 내가 마주했던 상황이다. OOP로 자료구조를 작성하는 데에 익숙하지 않았던 나는 계속 코드를 미궁 속으로 끌고 가고 있었는데(…) 사수님의 조언으로 python으로 단순화한 버전의 trie를 먼저 구현해 보기로 했다. 포인터 같은 것들에 신경을 덜 쓰면서 구현해야 하는 스펙에 집중하다 보니, 확실히 패턴을 잡아낼 수 있었고 그 다음에 작성한 golang 버전의 코드 품질이 올라갔다. 책에도 비슷한 내용의 사례가 있어서 나로서는 굉장히 신기했다.
적극적 읽기
짧은 사회 경험이었지만 꽤 다양한 개발자 분들을 만날 기회가 있었다. 그 중 내가 굉장히 좋은 인상을 받고 ‘닮고 싶다는’ 생각을 한 분들의 공통점이, 항상 만들고 싶은 것이 있다는 것이다. 이 책에서 ‘적극적 읽기’라는 개념을 보자 그분들의 생각이 났다. 무언가를 읽을 때 구체적인 질문이나 목적을 갖고 있는 방법이 바로 적극적으로 읽는 것이다. 문법 하나를 배워도 이걸 활용해서 작성할 수 있는 간단한 프로그램을 머릿속에서 띄워 가며 읽는 것, 그렇게 살아있는 공부를 한다면 새로운 언어나 프레임워크를 습득하는 게 훨씬 가뿐해질 것이다. 음.. 나는 그런 사고에 아직 익숙하지는 않지만, 의식적인 훈련이 많은 것을 바꿀 수 있다고 생각한다 :)
인지적 과정
잘 하고 싶다면, 이미 잘 하는 사람을 관찰하라
사실 이 말은 당연한데, 뒤에 나오는 질문에 쉽사리 답하기가 힘들다. ‘어떻게 관찰하나요?’ 그를 하루종일 따라다니면서 대체 뭘 먹고, 뭘 하고, 언제 자고 일어나는지를 관찰해야 할까? 가능하다면 그래도 되지만, 그만큼 친해지기 전에 몇 마디 대화만으로 그들의 ‘비결’을 뽑아낼 수 있는 방법이 있다고 한다. 바로 구체적인 사례를 그들 스스로 이야기하도록 유도하면서, 인지적 과정을 분석하는 것이다. 한번도 접해 보지 않은 프레임워크를 빠르게 익힌 친구에게 “대체 너는 어떻게 그렇게 빨리 배우냐” 는 영양가 없는 물음 대신, 처음 배울 때 무슨 문서부터 봤는지, 참고한 프로젝트는 있는지, 그 과정을 순차적으로 짚어가며 그가 무엇을 더 ‘효율적’이라고 판단했는지를 유추해낼 수 있을 것이다. 이렇게 좋은 비결을 알려줘서 고맙다, 하고 커피 한 잔 사주면 그는 내가 뭘 알려준 거지, 하고 의아해하겠지만.
사회적 자본
이론에서 현실로 옮겨오는 순간, 가장 먼저 부딪히는 게 인간에 관한 것 같다. 완벽해 보이는 프로젝트도 사람들 사이의 불화로 인해 백지로 돌아가기도 한다. 결국에는 결정권을 가지고 있는 사람들의 ‘마음’에 들어야 하는 것이다. 혼자서 모든 것을 할 수 없는 규모의 일에 직면하는 순간(사실 거의 모든 일들이 이제 그렇다), 팀원들 간, 그리고 팀과 고객 간의 소통이 프로젝트의 성공 여부를 결정하는 가장 큰 요인이 된다.
단순히 일을 ‘같이’ 한다는 점에서뿐만 아니라, 그들과 좋은 관계를 유지하는 것이 중요하다고 이야기한다. 사실 외향적이지 않은 이들에게는 그런 것들이 ‘피곤하다’고 느껴질 수도 있겠다. (나도 그렇고) 회식에 참석하고 일부러 친한 척을 해야 한다는 걸까? 하지만 이 책에서는, 조금 더 세련된 방식으로 ‘신뢰’를 얻을 수 있는 법에 대해 이야기한다. 좋은 동료가 되는 법은 특별한 것은 아니었다.
어쩌면 ‘성격’에 대한 부분은 타고나거나, 유년기를 거치면서 성립된 모습이 거의 정해져 있다는 생각은 든다. 주위를 둘러보면 정말 자연스럽게 상대방에게 다가가고, 그들의 문제에 공감하고, 도와주려는 사람들이 있다. 그들이 동료로서 호감과 지지를 얻는 것은 당연해 보인다. 하지만 그런 것이 마냥 어려운 사람들도 있을 것이다. 내가 알고 있는 것을 남과 공유하지 않으려는 이기적인 성격(…) 탓일 수도 있겠지만, 그저 서툴거나 어떻게 다가가야 할지 몰라 어색한 사람도 있다는 걸 주장하고 싶었다- 그런 사람들이 조금씩 좋은 동료로 바뀌어가기 위해 훈련할 수 있는 가이드라인이 있다면 좋을 것이다.
- 공감하고 이해하려는 대화: 상대방의 사고 흐름을 엿보면서, 이 사람이 왜 이런 선택을 했는지를 깊이 이해하고 조언한다.
- 행동을 유도하려는 대화
이상적인 팀?
모든 사람들이 동시에 좋은 동료가 되려는 노력을 하지 않더라도, 내부에서 조성되는 분위기에 따라 자연스럽게 팀원들의 행동이 달라지는 경우도 있는 것 같다. 바로 ‘심리적 안전감’의 정도가 높아지게 되면서다. 실수를 남들에게 들킬까 하는 불안감과, 내 생각이 바보같아 보일 것 같다는 생각이 줄어드는 팀일수록 심리적 안전감이 높다고 할 수 있다.
속도가 빠른 팀은 심리적으로 보호가 되고 있었습니다. 새로운 것을 제안하고 시도하는 데에 열려 있었고 실패에 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았습니다.
… (중략) 속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했습니다. 학습을 팀의 중대한 목표로 받아들였습니다. 리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했습니다.
불확실성에 대처하는 법: 애자일
애자일을 한 단어로 표현한다면 불확실성에 대처할 수 있는 지침이라고 해야겠다. 불확실성이란, 모든 것이 0과 1이 아닌 확률료 표현되는 (실제) 세상이다. 책에서는 간단한 확률 법칙을 사용해서 학습과 협력이 어떻게 애자일의 근본이 되는지를 증명(?)하고 있다. 계속해서 현재의 방향을 체크하고 서로에게 피드백을 줄 수 있는 환경, 좋은 일의 확률은 증가시키고 나쁜 일의 확률은 감소시키는 시스템을 만들어 나가는 것이다. 무언가 수학적이라서 마음이 편안해지는 설명이다!
개인의 관점에서는 삶의 불확실성을, 업무의 입장에서는 프로젝트 진행의 불확실성을 제거할 수 있는 방법은 없다. 그걸 인정하는 데에서부터 애자일 방법론이 왜 필요한지를 명확하게 깨달을 수 있을 것이다.
작게는 내 스스로의 행동에 피드백을 주는 주기를 줄임으로써, 크게는 내가 속한 조직의 분위기가 학습과 협력에 초점을 맞출 수 있도록 적극적으로 다가가고 변화하는 사람이 되자.
책 정보
함께 자라기 - 애자일로 가는 길 김창준 (지은이) | 인사이트 | 2018-11-30