프로세스 기반 개발&책임 주도 개발 그리고 애자일

다른 조직에 있는 개발자들에게 물어보면 백이면 백 애자일 기법을 도입하고 있다고 한다. 그런데 한 가지 흥미로운 공통점이 있다. 그 조직들은 시니어가 설계를 하고 주니어는 개발을 하는 형식이었다. 그리고 물어보면 '프로세스 기반은 아닌데... 그렇다고 책임 기반은 아니야. 시니어가 리드해주셔.'라고 답한다. 먼저 프로세스 기반 개발은 사전에 정의한 계획, 프로세스, 효율적인 시간 관리, 경험을 통해 검증된 소프트웨어공학 기법을 적용하는 것이다. 프로세스에 지속적으로 투자&개선해서 더 좋은 결과를 얻어내는 것이다. 여기서 중요한 것은 프로세스 기반 개발을 하다보니 산출물이 따라오는 것이지 산출물을 작성하기 위해 하는 것도 아니고, 산출물을 많이 작성한다고 프로세스 기반 개발을 하는 것도 아니다. (그리고 왜 '프로세스 기반으로 일해?'라고 하면 '난 프로세스 기반 싫어! 공장의 부품이 되고 싶지 않아!'라고 하는지 모르겠다. 프로세스 기반으로 일해도 주도적으로 일 할 수 있는데...) 책임 주도 개발은 최고 인재를 고용하고, 그에게 프로젝트의 전권을 준다. 프로세스가 어떻든 문서를 작성하든 말든 중요하지 않다. 몇 시간을 일 하든 결과만 나오면 된다. 그리고 그만큼 보상한다. 권한과 보상은 그들에게 동기 부여 요소가 된다.(많은 연구 결과에 따르면 개개인에 대한 동기 부여는 생산성에 가장 큰 영향을 미치는 요소라고 한다.) 실리콘 밸리에서 유행한 방법이고 전형적인 상상 속 슈퍼 개발자와 비슷하다. 구축해야하는 시스템은 점점 커지고 복잡해지는 와중에 영웅 중심 개발이 알맞은 방법인가? 그가 나가면 어떡하나? 라고 질문하면 '분명 문제가 있다.'라고 답할 것이다. 담당자가 나가면 문제가 생긴다. 그래서 실리콘 밸리에서 그렇게 고급 개발자에 목숨을 거는게 아닐까? 그리고 MSA, DDD, TDD 같은 기법으로 시스템을 작게 작게 만들고, 영웅을 갈아끼워도 잘 돌아갈 수 있도록 하는게 아닐까 싶다.(개인적인 생각) 단, 분명히 인지해야할 것은, '책임과 권한 그리고 보상'에 집중해야한다. 어떻게 하면 직원들을 좀더 늦게까지 돌릴 수 있는가에 골몰할 게 아니다. 그들은 '책임 주도 개발'을 하는 회사들을 겉으로만 관찰하고서는 '적은 문서', '스톡옵션', '야근' 이 세 가지 요소만 조합하면 되는 줄 안다. 그러나 실제로 '책임 주도 개발'을 하는 회사는 '야근'을 강요하지 않는다. 소프트웨어를 만드는 것을 좋아하는 사람들을 묶어서 팀으로 만들고 '책임,권한,보상'을 줄 뿐이다. 프로세스 기반과 책임 기반 중 더 나은 방법은 없다. 가장 좋은 방법은 아마 두 가지를 적절하게 섞는 것일 것이다.(라고 책과 연구에서는 말한다.) 그리고 내가 보기엔 이미 많은 조직이 이 두 가지를 섞어서 일 하는 것 같다.(대체적으로 안 좋은 방향으로) 시장의 변화와 요구사항을 빠르게 캐치해서 프로덕트에 반영하기 위해 애자일을 도입한 팀이 있다. 리더는 구성원 모두 같이 아이디어를 나누며 프로덕트를 만들기 원한다. 이에 구성원들에게 프로덕트에 대한 주인의식을 갖도록 여러가지로 동기부여를 한다. 슬슬 프로덕트에 요구사항이 들어오기 시작하고 외부에서 정한 일정이 주워진다. 프로덕트의 안전성을 위해 시니어 개발자가 설계를 하고, 주니어 개발자가 개발을 한다.(주니어는 살짝 의문을 품는다. '요구사항 분석해서 솔루션 제시하고 싶은데! 기능 개발만 하나?!') 그리고 다시 시니어 개발자가 리뷰를 한다. 이 과정을 반복하다보니 서서히 시니어가 병목(절대적 할 일이 많다.)이 되기 시작한다. 이에 문제를 느낀 시니어는 몇 가지 프로세스를 추가하고자 한다. 요구사항(유저스토리)을 잘 이해했는지 확인하기 위해 주니어에게 개발하기 전 테스트 케이스와 구체적인 설계서(시퀀스 다이어그램 등)를 작성해달라고 요청한다. 개발 후에는 리뷰 체크리스트를 만들어 셀프 리뷰를 먼저 하도록 한다. 구성원들 간 서로 통합 테스트 혹은 사용자 테스트를 해주는 단계를 추가한다. 이에 슬슬 각 단계의 필요성을 제대로 이해하지 못한 주니어는 불필요한 단계와 산출물 작성이 생겼다며 불만을 갖기 시작한다.'분명, 애자일은 프로세스를 간략화하고 문서화를 최소화하는 방법론인데?(심지어 애자일의 진 의미를 잘못 이해함) 이게 맞나!'라는 생각이 들며 점점 개발 프로세스는 미궁으로 향해 간다.... 지난번 커리어리에 투표를 올렸을 때, 슬픈 결과가 있었다. (https://careerly.co.kr/polls/523?utm_campaign=user-share) 한번쯤은 구성원들과 소프트웨어 개발 생명 주기의 각 단계에 대해 다시 한 번 살펴보고, 현재 일 하는 방식이나 프로세스는 어떤지 회고해보면 좋지 않을까 한다.(실제로 애자일 방법론에서는 매 스프린트마다 그 조직에 최적화된 프로세스를 탐색하는 시간을 갖는다.) 현재 우리 조직이 어떻게 일하고 있는지 관찰하는 것이 시작이 될 것이다. 그리고 가능하다면, 애자일에 대해서도 다같이 논의해봐도 좋을 것 같다. (뭔가 저마다 자기 좋은 방향으로 이해하는 사람들이 많은 것 같다. 구성원들을 더 많이 돌리란 말인가? 문서화를 하지 말란 말인가? 프로세스는 무시하고 개발부터 하란 말인가? 등.) 그러한 시간을 가진다면, 적어도 모두가 애자일을 잘못 이해하더라도 서로 다른 이해도에서 오는 불필요한 문제는 회피할 수 있지 않을까.