애자일 프랙티스: 올바른 결과를 위해 효과적으로 일하는 법
제목에 “4시간 수면법”, “우뇌개발”, “속독법” 같은 단어가 포함된 책을 탐독하던 때가 있었다. 지금 와서 생각하면 그때는 어떤 일을 실제로 해내는 것보다는 그 일을 어떻게 하면 잘 할 수 있을까에 더 관심이 많았던 것 같다. 차라리 그 시간에 무식하게라도 행동을 했더라면 더 많은 걸 배웠겠다는 생각이 든 이후로 방법론에 대한 책은 읽지 않게 됐다. 하지만, 어느 정도 시간이 흐른 뒤에 다시 깨달았다. 방법론이라고 다 같은 방법론이 아니라는 것을. 얄팍한 행동강령이 아니라 내가 하는 일을 더 잘 할 수 있도록 진짜로 도와주는 방법론 책도 있었다. 나에게는 책읽는 방법을 가르쳐준 『생각을 넓혀주는 독서법』이 그랬고, 업무 관련해서는 『애자일 프랙티스』가 그랬다.
프랙티스란 단어에서 유추할 수 있듯이 이 책은 다양한 실용적이고 구체적인 지침을 제공한다. 그럼 애자일이란 무엇인가? 사전적인 의미는 “기민한”이라는 뜻이고, 책을 읽으면 대충 어떤 것인지 감은 잡히지만, 한 마디로 딱 잘라서 설명하기는 쉽지 않다. 처음부터 괜히 용어와 정의에 얽매이느니 그냥 올바른 결과를 내기 위해서 효과적으로 일하는 방법 정도로 생각하고 넘어가도 괜찮을 것 같다. 그렇다면 올바른 결과란 무엇이며, 어떻게 일하는 것이 효과적인가? 왜 이 책에서 나오는 방법론이 소프트웨어 개발에 적용되는가?
두 번째 질문부터 대답하자면, 소프트웨어 개발은 불확실성에 대처하면서 변화를 다루는 일이기 때문이다. 내가 필요해서 만들건 다른 사람의 요청을 받아 만들건 일정한 규모 이상의 소프트웨어를 개발할 때는 우리가 원하는 게 정확히 무엇인지 모른다. 고객이 제품을 어떻게 느낄지도 불확실하고 예상하지 못한 요구사항이 추가될 수도 있다. 겉모습만 그런 것이 아니다. 구체적인 구현에 있어서도 미리 설계한 대로 착착 진행되는 경우는 과거에 했던 걸 똑같이 다시 하는 때 말고는 의외로 잘 없다. 소프트웨어 개발의 속성이 그렇기 때문에 개발하는 과정은 움직이는 과녁을 맞추는 일에 곧잘 비유된다.
따라서 산을 오른 뒤에 이 산이 아닌가봐 하고 머리를 긁적이지 않으려면 끊임없이 “우리가 만들어야 하는 게 이게 맞나요?”라고 물어야 하고, 만일 아니라면 유연하게 방향을 틀 수 있도록 준비하고 있어야 한다. 몇몇 기술 관련 프랙티스는 이런 맥락에서 이해할 수 있다. 자동 단위 테스트는 테스트라는 안전망을 둠으로써 새로운 시도와 변경을 겁내지 않도록 한다. 또, 항상 동작하는, 그래서 언제든 릴리즈 가능한 버전을 유지하는 것은 최종 결과물을 눈으로 보면서 과녁을 조정하는 피드백을 가능케 하고 점진적인 변화를 유도하여 위험의 크기를 줄여준다.
그러나 기술적인 것만으로는 부족하다. “코드가 깔끔하지 않아서 정리가 필요하다”고 하면 개발자는 무슨 말인지 바로 이해하지만 비개발직군에서는 공감하기가 쉽지 않다. 코드가 복잡하면 이해하기 어렵고 작은 수정이 어떤 부작용(side effect)을 가져올지 모르니 그냥 내버려두고픈 유혹에 빠진다. 이런 코드를 가지고는 변화에 유연하게 대응할 수 없다. 동료간 코드 리뷰 및 공유 문화는 우환을 미리미리 제거하는 효과가 있다.
일반적으로 소프트웨어는 팀 단위로 개발을 하기 때문에 일을 잘 하는 법에 좋은 팀 구성원이 되는 법이 빠질 수 없다. 팀으로서 다른 사람과 함께 일하는 법에 대해서도 훌륭한 조언이 많다. 가령,
- 여러분이 겪을 수 있는 최악의 일은 아주 감정적으로 반응하는 사람들과 일하는 것이다. 그런 사람들은 문제 해결에는 관심이 없고 대신 서로에 대해 뒷담화를 즐긴다. (중략) 애자일 팀에서는 상황이 다르다. 여러분이 불만을 얘기하려 애자일 팀 멤버에게 가면 이런 얘기를 들을 것이다. “좋아, 내가 뭘 도와줄까?”, 36 ~ 37p
- 누구의 생각이 더 좋은지를 증명하는 것이 아니라 문제를 해결하는 데 계속 집중해야 한다., 47p
- 스탠드 업 미팅이 시간 낭비처럼 느껴진다면, 하나의 팀으로서 실제 활동하지 않기 때문이다., 229p
- 팀원 누구라도 도움을 요청하기 전에 얼마 동안 문제에 매달려야 하는지 제한 시간을 설정하자. 한 시간 정도가 적당한 목표다., 240p
지침을 제시하되 너무 거기에 매몰되지 않도록 균형을 잡아준다는 점이 이 책의 매력 중 하나다. 예를 들어 “위험을 무릅쓰고, 앞으로 나아가라”에서 (자신이나 다른 사람의) 코드에서 문제를 발견하면 덮어두는 대신 공개하고 제대로 해결하라고 권하면서도 “하늘이 무너질 것 같은 위기 상황인데 팀의 다른 사람들은 동의하지 않는다면, 여러분이 옳다는 근거를 충분히 설명하지 못했다고 생각하라” 이어서 “하늘이 무너질 것 같은 위기 상황인데 팀의 다른 사람들은 동의하지 않는다면, 그 사람들 말이 맞다고 생각하라”며 독선적인 생각을 경계하고 다른 구성원의 의견을 존중해야 함을 상기시킨다.
저자들이 제안하는 내용은 기본적으로 소프트웨어 개발을 위한 것이기는 하나 거기에만 국한되지 않는다. 불확실성이 큰 일을 다른 사람과 협력해서 해결해야 한다면 분야에 상관없이 유용한 조언을 많이 얻을 수 있을 것이다. 미처 생각지 못한 좋은 아이디어를 발견하면 수용하고 내 생각과 행동에 반하는 내용이 있다면 비판적으로 사고한 뒤 거부하거나 혹은 힘들더라도 내 행동을 바꾸는 것이 이런 방법론 책을 가장 잘 활용하는 방법이 아닐까 한다.
노란 형광펜
- 팀에 속한 모든 사람은 프로젝트에서 긍정적인 성과를 원하는 전문가라고 가정한다. 그들이 경험이 풍부한 전문가가 아직 아닐 수도 있지만, 전문가다운 자세를 지닌다는 것이다. 다시 말해 모든 사람이 최선을 다하기를 원한다는 것이다. 무단결근자, 게으름뱅이나 노골적인 훼방꾼 같은 문제가 있다면 애자일 접근 방법은 여러분에게 적당하지 않을 것이다., 21 ~ 22p
- 증상이 아니라 문제를 고쳐라., 43p (디버깅할 때 명심해야 할 조언)
- 오래된 습관은 바꾸기 힘들고 그 습관 자체를 깨닫는 것은 더욱 어렵다. 버리는 일의 첫 단계는 여러분이 구식의 접근 방식을 사용한다는 사실을 깨닫는 것이다., 69p
- 현재 시점에서 따라가는 설계는 요구사항에 대한 현재의 이해해 기초한 것이라는 사실을 명심하라. 일단 코딩을 시작하면 모든 것을 원점에서 다시 시작해야 한다. 설계와 설계를 구현하는 코드는 끊임없이 진화한다., 87p (설계와 코딩을 각각 계획과 행동으로 바꿔서 생각해도 유용하다.)
- 설계의 성격상 가장 좋은 피드백은 코드 자체에서 온다. 요구사항이 조금 변해도 계속 구현하기 쉽다면 그 설계는 좋은 설계다. 만일 요구사항이 조금 변했는데도 큰 혼란, 즉 코드 베이스의 긴 라인에 걸쳐 혼란이 온다면 설계를 개선해야 한다., 90p
- 작업마다 팀원을 순환시키면 팀의 전체적인 지식과 경험 수준이 향상된다는 사실을 깨닫게 될 것이다., 235p
- 뜻하지 않게 여러분의 팀에서 전문가를 잃지 말자. 개발자 한 사람이 어떤 분야에 상당히 노련하다면, 시스템의 다른 부분에 개발자를 지속적으로 노출시키는 한편 그를 해당 분야에 상주하는 전문가로 두는 편이 유리할 것이다., 235p
- 다른 사람이 여러분의 코드에서 작업할 것을 알기 때문에 스스로 더욱 통제가 될 것이다., 235p
- 아는 것을 설명하는 시간을 가지면, 아는 것에 대한 더 나은 이해를 얻는다., 238p (내가 공개된 블로그에 글을 쓰는 이유)