이번 학기까지 학교를 다니게 되었고 오후에는 학교에서 재택을 하게 되었다. 일과 학업을 병행하는 과정에서 생기는 부담은 둘째치더라도, 의사소통이 이전보다 어려워진다는 점에서 많은 문제가 예상되었다. 슬랙과 줌이 있잖아요! 할 수도 있겠지만 애자일적으로 확실한 것은 역시 면대면 소통 아니겠는가? 일목요연하게 정리된 문서 열 줄을 쓰는데 걸리는 510분의 시간보다 23분의 구두 대화가 더 효율적이라는 걸 실시간으로 체감하고 있다.
이런 면대면 소통이 줄어든다는 것은 이전보다 애자일하기 어려워진다는 것을 의미한다. 예전에는 정책적인 부분이나 특정한 기능 구현 방법을 논의해야 하면 바로 옆자리 팀원 아니면 그 반대편 프론트 섹션에서 담당자와 바로바로 소통하면 되지만 이제는 '필요한 내용을 글로 정리한다' -> '슬랙으로 정리한 내용을 보낸다' -> '슬랙을 읽을 때까지 기다린다' -> '담당자가 해당 내용을 이해한다' -> '담당자가 답변 내용을 고민한다' -> '답변 내용을 글로 만든다' -> '슬랙으로 정리한 내용을 보낸다' 라는 미친 오버헤드가 생기게 되었으니까... 심지어 저 과정에서 뭔가 소통 에러가 터지면 다시 처음부터 돌아가서 반복해야 한다!
아무튼 이런 비효율적인 프로세스를 최대한 단축시킬 필요가 있었고 고민을 하다가 흔히 애자일 프로세스 하면 나오는 스프린트를 우리 팀에 도입하기로 했다.
나는 개인적으로 애자일 정신은 좋아하지만 애자일의 구현체로 나오는 '스프린트' '스크럼' '스크럼 마스터' '백로그' '회고' 같은 것들을 썩 좋아하지는 않는다. 오늘도 누군가가 보내준 긱뉴스 링크에서 모 25년차 개발자가 '스크럼 무한까기' 라는 주제로 수많은 PM의 마음을 긁었다는 썰을 봤고 공감가는 바도 있어서 생각보다 재밌게 봤던 기억이 있다.
구현에 의존하는 것은 소프트웨어 개발이라는 맥락에서든 장기적으로는 지양해야 하는 대상이다. 애자일은 '어떤 가치'에 대한 지향이지 '스프린트, 스크럼'에 대한 지향이 아니다. 어쨌든 그런 점에서 나를 비롯한 우리 팀은 스프린트, 스크럼, PM 이딴 말 하나 없이도 충분히 애자일하게 일하는 사람들이었고 그래서 사실 그런 체계의 필요성을 크게 못 느끼지는 못했다.
하지만 상황이 달라지지 않았는가? 사실 예전에도 그런 프로세스가 '전혀 필요없어!'였던 것은 아니었다. 팀의 규모가 작기도 하고, 서비스 규모가 작기도 하고, 그래서 모든 팀원이 같은 목표를 동기화해서 가져갈 수 있었다. 문제가 발생하더라도 JIT 컴파일러 같은 느낌으로 그때그때 최적화를 할 수 있었다는 말이다. 하지만 이제는 그때그때 처리하기에는 이런저런 문제가 존재하기 때문에 '예상되는 문제'를 미리미리 만들어둔 뒤에 적절한 대응방침을 정해둘 필요가 있었다.
거창하게 말하긴 했는데 그냥 정기 회의 하고 싶었다고.
누군가는 이 정기 회의를 스프린트라고 부르길래 나도 스프린트라고 부르기로 했다. 내가 여기서 작금의 애자일을 겉멋만 든 프로세스라고 하면 수많은 애자일 사랑단들에게서 지탄받을 것 같지만 오해는 마시라. 겉멋이라는 것은 생각보다 중요하다.
만약 지금의 애자일 프로세스에 대한 이름을 아래와 같이 바꾼다면 어떨까?
- 스크럼 -> 일간 회의
- 스프린트 -> 주간 회의 또는 정기 회의
- 스크럼 마스터 -> 회의 진행자
혹은 팀원들에게 '오늘 정기회의 날이에요!' 하는 것보다는 '오늘 스프린트 회고하는 날이에요!' 하는 편이 더 동기부여될 것이고 아무튼 뭐 그렇다.
아니면 이것도 내가 더 좋은 환경에 있어봤던 적이 없어서 그런 건가?
'너가 진짜 맛있는 (애자일) 집을 안가봐서 그래' 같은 말처럼 스크럼과 스프린트는 정말로 애자일의 허상인 것일까. 가령 내가 네카라쿠배를 간다면 그곳의 애자일 프로세스를 경험하고 '진짜 애자일 맛집'이라고 부를 수는 있겠지. 하지만 그곳의 프로세스에서 애자일이라는 이름을 떼고 스크럼 마스터라는 이름을 떼고 스프린트라는 이름을 뗀 뒤 그것을 우리에게 익숙한 '회의'라는 이름으로 대체했을 때 과연 그 생산성이 눈에 띌 정도로 변할까? 그 '애자일, 스프린트, 스크럼'이 없어진다면 그 네카라쿠배 빅테크는 무너져내릴까? 그렇지는 않을 것이다.
그럼 반대로 이야기해보자. 만약 우리가 일반적으로 생각하는 열악한 SI 환경에서 진행하는 일간 회의, 정기 회의에 스크럼과 스프린트라는 이름을 붙이고 팀장의 이름을 '스크럼 마스터'로 바꾼다면 갑자기 팀의 작업속도가 수직상승해서 네카라쿠배급이 되어버릴까?
아닐 것이다. 나는 네카라쿠배가 어떻게 일하는지도 모르고 그곳이 진짜 애자일 맛집인지도 모르고 그곳에서의 스크럼과 스프린트가 어떻게 돌아가는지도 모르지만 그걸 모른다고 해서 내가 이런 말을 할 자격이 없는 것은 아니다.
보여지는 것에 너무 마음쓰는 것은 외부와의 종속성을 높인다.
어쨌든 나는 이런저런 필요성 때문에 팀원들에게 스프린트를 하자고 제안했고 그건 잘 받아들여졌다. 첫번째 스프린트는 곳곳에 방치되어있는 레거시를 리팩토링하는 작업이었고 그 전에 회귀 방지를 위해서 전체 서비스를 통합 테스트로 감싸는 작업이 필요했다. 겸사겸사 Spring REST Docs로 문서화를 하거나 Jacoco를 사용해서 테스트 커버리지도 측정할 수 있으면 좋겠지.
레거시가 불안정할수록 더 빡세게 테스트를 걸어야 한다. 지금 잘못된 도메인 설계로 기능 확장이 어려운 상황이다. 방문일정의 참여결과를 방문일정이 아니라 센터에서 관리하고 있기 때문에 다른 서비스 개발할 대도 번거로운 점들이 너무너무 많이 발생한다. 사실 스키마는 만들어놨다. 마이그레이션을 어떻게 할 지가 문제지. ERD는 열심히 만들어놓고 손만 빨고 있으니 쉽지 않다. 리팩토링된 DB 스키마도 이렇게 시간이 흐르다보면 다시 또 레거시가 될 것이고 그러면 또또다시 리팩토링을 해야 할 것이다.
리팩토링이란 어떻게 해야할까? 고민은 많아지고 있고 많은 레퍼런스도 찾아봤지만 우리에게는 이런 고민을 털어놓을 CTO도 없고 테크 리드도 없으며 백엔드 주니어급도 없다. 나도 어딜가서 주니어급이라고 말할 수 있을까? 테스트 코드를 감싸고 나서 도메인 리팩토링을 진행하기로 했다. 전자는 반복 작업이니 그렇다 치더라도 후자는 상당히 두렵다.
리팩토링에 대해서 찾아보면 많은 사례들이 나온다. 우테코 수료자들이 남긴 자료들을 보면서 방향성을 고쳐나가고 있다.
작년부터 했던 생각이 있다. 나보다 잘하는 사람이 그득그득한 곳에서 원하는 키워드를 던져주고 내가 깨달은 것들을 검증하고 확장시킬 수 있는 곳에서 뭔가를 해보고 싶다. 우테코를 해보고 싶다는 생각이 점점 강해지고 있다.