Clean Agile

클린 애자일을 읽고나서 책의 내용을 각 장에 대해 리뷰하는 방식이 아닌 책을 읽고 저 스스로의 경험과 책 내용 전반적으로 종합하여 적어보고자 합니다.

애자일은 단순한 의미의 순환 개발의 의미가 아니다.

저는 애자일 방법론이라는 단어를 사용하지만, 애자일 개발론에 적합하지 않는 방법론으로 개발을 진행 한 경험이 있습니다. 그리고 저뿐만 아니라 많은 사람이 여러 다른 방식에서 애자일이라는 감투를 두른 전혀 다른 개발 방식에 대해 부정적인 경험이 꽤나 있었을 것이라고 생각합니다.

제가 생각하는 애자일은 “작은 단위의 개발의 순환 구조” 정도였고 많은 회사들은 애자일을 도입하고 실패했습니다. 이러한 사례들에 대해서 책에서는 애자일이 정상적으로 동작하기 위해서 강한 어휘를 사용하면서 “자신들의 주제”를 파악하라는 느낌을 주고 있습니다.

전체에 비해 짧은 시간을 주기로 보다 적은 단위의 개발을 진행하면서 “내가 어디까지 개발 할 수 있는가?”를 각 주기마다 스스로의 한계를 인지하고 그에 맞는 범위를 잡아나가야 한다고 이야기하며, 동작하고 있는 코드를 리팩토링하는 것이 당연하므로 과거 코드에 손을 올리는 것에 두려움을 가지면 안된다(이게 불가능하면 아키텍쳐가 잘못 된 것이라 꼬집)고 말합니다.

무엇보다 애초에 애자일이라는 의미가 “작은 단위 개발”보다도 “변화를 빠르게 반영”하는 것에 상당히 초점이 맞추어져 있습니다. 변화를 빠르게 반영하기 위해 작은 단위로 개발되는 것이 순서입니다.

애자일을 의미하는 문장은 다음의 4문장입니다.

• 공정과 도구보다 개인과 상호작용
• 포괄적인 문서보다 작동하는 소프트웨어
• 계약 협상보다 고객과의 협업
• 계획에 따르기보다 변화에 대응하기

즉 위의 4가지의 방침에 적합하면 그 어떠한 개발 방식도 애자일 방법론이라고 말 할 수 있습니다.

나는 어떤 소프트웨어 개발 방법론을 따르고 있었나?

애자일 첫 장을 읽고나서 바로 생각한 지점은 “현재 나의 개발 방법”이였습니다. 실제로 4년 전 즈음 애자일이라고 “사칭 된” 러프한 짜여진 개발 방법을 따라 스타트업에서 서비스 개발을 한 적이 있습니다. 이 때의 개발 방법은 “작은 단위의 개발을 끊임없이 수행하고 적용하는” 것을 애자일이라고 칭하며 뚜렷한 목적이 없이 단순히 코드를 짜기만 했었습니다.

여기서 가장 문제는 어떤 서비스인지에 대한 가이드라인은 있지만 “기한”이 없고, “목적”이 명확하지 못한 상태로 개발을 이어가다보니 “추가 요구 사항”이 발생 할 수록 무기한으로 개발이 길어지는 문제가 발생했습니다. 이 문제는 회사의 자금 문제로 이어지고, 저는 그 즈음 회사를 나왔습니다.

그 때 스스로도 이러한 개발 방식이 정상적이지 않다는 것을 알고 있었지만, 만약 이 방식이 애자일에 유사하다면 그 또한 좋은 방법론이 아닐 것 이라고 생각하게 되었습니다. 그리고 오히려 폭포수라고 불리우는 각 단계의 명확한 설계 및 구현이 더 옳은 것이 아닌가 생각하게 되었습니다.

얼마 전까지의 개발은 그 어떠한 명시적인 방법론을 따르고 있지 않았습니다. 하지만 가까운 개념이라고 보면 “폭포수”에 가까운 개발 방식을 채택하고자 하지 않았나 생각하고 있습니다.

그리고 지금의 회사에서 애자일의 방법론 중 하나인 “SCRUM”을 채택하고 있습니다. 매일 아침 SCRUM 시간을 통해 팀원들이 서로 작업 내용을 간략히 공유하며 애자일에서 중요하게 생각하는 개인과 상호작용을 중시하는 원칙을 지키고, 격주/N주 마다 서로 원하는 일감을 가져가서 적은 단위로 업무하고 변화에 즉각 반응하는 애자일 방법론입니다.

저는 지금의 개발 문화에 매우 만족하고있고, 무언가를 해야한다는 느낌이 강제성보다 개인의 성장 욕심으로 이끌려나가는 문화라서 업무를 하는것에 큰 재미를 느끼기까지 하고 있습니다.

XP/SCRUM 방식으로 일하면서 느끼는 점

위에서 우리는 SCRUM 방식을 채택하고 있다고 말했지만, 정정하면 XP와 SCRUM 방식을 동시에 채택하고 있는 것 같습니다. 제가 속한 조직은 N주 마다 회고를 하고 플래닝을 한 뒤 각 업무에 대해 스토리를 만들고 하위 작업을 수시로 추가/변경하면서 목표를 이루기 위해 노력하고 있습니다.

이 책을 읽기 전에는 왜 이런 방식을 채택했는지(순수한 궁금증) 궁금했지만, 책을 읽고나서 저 스스로에게 동기를 부여하고 문제에 접근하고있는 이유가 이러한 개발 문화에 영향을 받은 부분이 있다는 생각이 들었습니다.

무엇보다 “스토리”라는 부분은 크게 와닿습니다. 대부분의 한국 회사에서는 목표 일정을 주고 일정에 맞추지 못하면 무능한 사람이라는 필터를 씌우는데, “스토리” 개념은 스스로 업무를 정하고 그 업무를 빨리 수행하든 조금 늦게 수행하든 “수행 역량을 데이터화”하여 수집하고 “다음 스토리는 역량에 맞도록 수정”하는 프로세스입니다.

즉, 스토리라는 것은 명확한 마감기한이 있는 업무보다 자신 스스로의 역량을 점수로 표현 할 수 있는 자발적 업무 개념으로 만들어줍니다.

스토리

제가 가장 만족하는 부분이라 추가적으로 적어보겠습니다.

스토리라는 개념은 “우리가 해야하는 일의 부분”입니다. 중요한 부분은 “부분”이라는 점 입니다. 개발을 하면 상당히 큰 목표를 가지고 개발을 시작하고 명확하지 못하고 이루기 어려운 목표를 이루지 못했다는 생각에 자괴감을 느끼기까지 합니다. 하지만 그 일을 세분화해서 작은 “부분”으로 만들면 이룰 수 있습니다.

예를 들면 “실시간 서빙이 가능한 인공지능 데이터 파이프라인 개발”이라는 목표를 가진다고 해보겠습니다. 이 목표는 최소 6개월에서 1년을 바라 볼 수 있는 너무나 방대한 목표로 보입니다. 팀원은 각자의 역할(엔지니어, 사이언티스트, 분석가)을 찾기까지도 1개월은 걸릴 것 이라고 생각합니다.

이런 목표를 다음과 같이 찢는다면 어떨까요?

[ “서빙 데이터베이스 개발”, “학습 데이터 웨어하우스 구축”, “사용자 이벤트 로그 전달을 위한 메시지 브로커 구축”, “모델 추론 API 서버 구축” ]

이제 조금은 구도가 잡히는 느낌이 듭니다. 각 구성원들은 이 목표 중 하나를 잡고 수행하면 됩니다. 하지만 이렇게 세부적으로 구분 된 목표도 너무 큰 단위일 수 있습니다. 예를 들면 쿠버네티스 환경에서 각 서비스에 필요한 리소스를 구분하여 서비스를 개발하고 싶다면 러닝커브가 크고, 세부적으로 최적화 할 수 있는 단계가 추가 되면서 리소스는 계속해서 커져나갑니다.

그러면 “서빙 데이터베이스 개발”을 조금 더 세분화해보겠습니다.

[ “RDB 기반 고정 리소스 서버 구축”, “NoSQL 기반 고정 리소스 서버 구축”, “그래프DB/벡터DB 기반 고정 리소스 서버 구축”, “각 데이터베이스 별 모델 서빙 부하 측정”, “QA” ]

이제 각 데이터베이스에 대해 세분화 된 목표로 만들어졌고, 이 정도면 2주 내에 하나의 목표를 이룰 수 있게 된 것 같습니다. 혹시 이루지 못하면 그것대로 괜찮습니다. 실패가 아닌 “스토리 수행 능력”을 알게 되었으니까요, 아니면 그 기간에 수행하기에는 너무나 높은 수준의 목표였을지도 모릅니다. 어느 쪽이 되었건 오차가 발생했으니 우리가 할 것은 역전파를 통해 다시 추정해내면 되는 문제입니다.

이걸 어떻게 적용해나가는게 좋을까?

책에서는 큰 주제 몇 가지를 가지고 이야기를 풀어나갔습니다.

메타포

메타포는 서비스를 협업을 하는 사람들이 더 잘 이해 할 수 있는 용어를 합치시키는 느낌입니다. 이로인해 팀원간의 협업 과정에서 의사소통을 재밌고 간단하게 할 수 있습니다.

DDD

데이터 사전을 통해 사람들이 데이터를 다루는데에 있어서 쉽게 만들어 주는 것에 대한 기술입니다.

지속 가능한 속도

여기서 속도란 프로그램의 응답 속도가 아닌 “사람이 지속 가능한 속도”를 말합니다. 즉, 지나친 야근과 과한 업무량으로 사람이 지쳐버린다면 능률은 오히려 감소하여 좋은 성과를 내지 못하는 상황이 발생한다는 의미입니다.

현재 팀에서 야근을 하려고 하면, 항상 듣는 말이 있습니다.

“어서 퇴근 하세요”와 “정말 그 시간에 못 끝낼까요?”입니다. 저는 이 말이 저를 배려하는 말 정도로만 알고 있었지만, 리더분이 원하는 것은 “이 사람이 지속 가능한 속도로 나아가는지” 그리고 “이 사람의 스토리 포인트(업무 량)의 수준을 정확히 측정하고 싶다”는 의미라는 것을 알게 되었습니다.

앞으로 주의해야 할 것 같습니다.

그리고 잠도 충분히 자야한다고 적혀있습니다. 좋은 책이네요.

지속적 통합

이 부분은 현재 조직에서 잘 이루어지지 않은 점이지 않을까 생각합니다. 최근에 페어에 가깝게 서로의 업무를 보면서 트래킹해나가는 중이지만, Git을 이용한 CI/CD는 이제 막 개발단계라 지켜봐야 할 것 같습니다.

스탠드업 미팅

현재 조직에서 하고있는 SCRUM이 이러한 미팅이지 않을까 생각합니다. SCRUM에 대해 명확하게 표현되어 있는데, 이 부분은 좀 더 알아보겠습니다.

• 미팅 참석은 필수가 아니다.
• 매일 할 필요 없고, 일정에 맞추면 된다.
• 10분이 넘게 걸리면 안된다.
• 단순하게 진행된다.

책에서는 크게 3가지만 말하면 된다고 합니다.

• 지난 스탠드업 미팅 이후 뭘 했는지
• 다음 미팅까지 뭘 할 것인지
• 어떤 장애물이 있는지

이거면 충분하다고 합니다.