Intro..
얼마전 인터뷰 기회가 생겨서 스타트업의 프론트엔드 개발자 포지션에 인터뷰를 다녀왔습니다. 인터뷰의 후미에 회사에 궁금한 것이 있다면 물어보라고 하셨고, 개발팀의 일하는 방식에 대해서 여쭤봤습니다. 해당 질문을 한 이유는 스프린트를 진행하면서 일의 순서가 잘 지켜지고 있나 궁금했기 때문입니다.
개인적으로 궁금했던 내용은 기획, 디자인, 서버 개발과 API 개발, 프론트엔드 개발 의 순서가 잘 지켜지고 있는지가 궁금했던 것이고 해당 질문을 한 요지가 이런 부분이 잘 지켜지고 있는지 궁금했다고 말씀드렸습니다.
프론트엔드를 리드 하시는 분에게 요즘 하고 계신 고민이 있냐고 여쭤봤을때 똑같은 고민을 하고 있다고 말씀하셨습니다. 인터뷰에 면접관으로 참여하신 분은 가장 이상적인 개발 프로세스는 맞지만 이상이 잘 지켜지지 않는다고 하셨습니다. 덧붙여서 해당 프로세스를 잘 지키려지는 건 애자일이 아니라 고전적인 워터풀 방식이 지키기 쉽다고 말씀하셨습니다.
반은 공감은 갔지만 반은 아리송한 부분이 있었습니다. 이 내용에 대해서 이번 포스팅을 통해서 고민해 보겠습니다!
프론트엔드 개발자의 고민
보통 가장 이상적인 개발 프로세스는 기획, 디자인이 완료된 이후 서버 API 개발이 완료되고 화면 작업을 들어가서 데이터를 붙이는 것 입니다. 하지만 실제로 현업에서 일을 했을때 이 과정이 지켜지는것이 쉽지 않았습니다. 100% 완벽한 기획이 있기 힘들뿐만 아니라 빠르게 출시해야 한다는 압박감으로 인해 디자인이 나오지 않은 상태에서 이전의 화면을 바탕으로 상상하며 화면을 구현하고, 화면 그대로 DTO 의 형태를 만들어 API 협의 문서를 미리 만들지만 이 또한 서버 개발자 분에 의해서 수정될 확률이 정말 높습니다. 이 과정에서 프론트엔드 개발자는 엄청난 리워크를 경험하게 됩니다.
하여 이전 회사의 프론트엔드 리더분께서는 기획과 디자인이 완료된 건에 한해서만 개발이 들어간다고 말씀을 하셨습니다. 서버 API 스펙에 대한 문제는 스프린트가 시작된 첫 날 개발되는 화면에 대해서 백앤드, 프론트엔드 개발자끼리 협의 회의를 거쳐 도출하는 방향으로 진행했습니다.
이상적인 프로세스가 지켜지지 않는다면 (서버 API 개발 이후 화면단 작업) 위 방법과 같이 기획, 디자인 된 건에 의해서만 협의를 통해 진행할 수 있겠습니다. 하지만 애자일을 채택한 개발 조직이 이 조차 지켜지기 쉽지 않다면 무엇이 문제일까요?
애자일 한다면 이를 지킬수 없다?
소규모 조직과 생존을 택해야 하는 스타트업에서는 빠르게 변화하는 시장에 대응하기 위해서 애자일 방법론을 채택하고, 빠르게 변화하는 시장에 대응하기 위해서 결과물을 빠르게 출시해야 합니다. 개발 프로세스에서 결과물을 빠르게 출시하기 위해선 앞단부터 뒷단까지 거의 동시적으로 작업할 수 밖에 없습니다. 하여 이 과정을 지킬수 없는 조직들이 생기고 조직의 구성원은 자주 발생하는 리워크에 스트레스를 받고 지치게 됩니다.
과연 애자일 한다면 이를 지킬 수 없을까요? 먼저 고전적 개발방식인 워터풀 방식에 대해서 살펴보겠습니다.
워터풀은 다음과 같이 작업의 파이프라인을 거쳐 제품을 개발하고 배포하게 됩니다. 가장 이상적인 개발 프로세스라고 할 수 있겠지만 해당 방법론에는 다음과 같은 문제점이 있습니다.
테스트가 완료되어 출시된 제품의 고객 반응을 살피기 까지 너무 오랜 시간이 소요된다는 점이 있습니다. 모든 작업이 완료되어 시장에 출시된다면 예상했던 고객의 반응이 변했을 수도, 만약 변했다면 이 반응에 대응하는데 또 다시 오랜 시간을 기다려야 합니다.
반대로 애자일 방법론은 특정한 기간 동안 약속한 스프린트를 반복을 하면서 빠르게 개발한 제품과 기능을 출시를 합니다. 빠르게 출시하여 시장 반응을 살필 수 있고 이를 토대로 기능을 보완하거나 새로운 기능을 개발할 수 있습니다.
위 그림을 보면 알다시피 애자일 방법론이 빠르게 여러 스프린트를 반복한다고 하지만 개발 프로세스를 무시하지는 않습니다. 개발의 앞단인 기획과 디자인이 완료된 건을 개발하고 개발이 완료된 건에 대해서 테스트가 진행됩니다. 이런 프로세스가 지켜져야 안정적인 제품이 개발되고 구성원이 리워크로 인한 스트레스에서 벗어날 수 있습니다.
애자일 하면서 이를 지키는 방법
애자일 하면서 개발 프로세스를 정확히 지키는 방법은 정말 간단합니다. 말 그대로 프로세스를 지키기만 하면 됩니다. 말장난 같지만 조직에 속한 모든 구성원이 프로세스를 정확하게 이해하고 이를 지키려고 노력만 한다면 어느정도 프로세스에 맞게 일을 할 수 있습니다. 결국 조직의 그라운드 룰을 마련하고 약속한 룰을 모든 구성원이 지켜 나간다면 해당 조직은 애자일 하고 있는 어떤 조직보다 생산적인 조직이 될 것 입니다.
덧붙여서 조직원이 약속을 지키는 것 만큼 중요한 것이 있다고 생각합니다. 바로 조직의 가장 윗분들이 애자일 방법론에 대해서 정확하게 이해하고 계셔야 한다는 것 입니다. 개인적으로 프로세스가 잘 지켜지지 않고 있는 조직은 조직의 윗분들이 애자일에 대해서 오해를 하기 때문이라고 생각합니다. 많은 기업들이 애자일 하기 때문에 우리 회사에 애자일을 도입했다던지, 애자일 방법론을 단순히 빠른 결과를 생산하기 위한 수단으로 여기는 듯 합니다. 애자일 방법론이 빠른 변화에 민첩하게 대응하기 좋은 개발 방법론이란것은 맞습니다. 하지만 애자일 방법론은 결과물에 집중하는 것 보다는 일하는 과정과 사람, 함께 일하는 조직을 강조합니다. 결국은 결정권을 가진 C레벨 임원분들 또한 애자일을 이해하고 개발 프로세스 과정을 지켜준다면 조금 더 견고한 제품과 기능과 오히려 더욱 빠르게 출시되는 결과물을 확인할 수 있을것 같습니다.
게임 체인저가 있다면 게임 브레이커도 있다
영화를 보다보면 상황을 극적으로 변화시키는 게임 체인저가 나옵니다. 반면에 잘 돌아가는 게임을 완전히 부셔버리는 게임 브레이커도 존재합니다. 조직이 성장해 나가면 구성원 또한 늘어나게 됩니다. 이 과정에서 조직의 룰을 지키지 않고 조직에 금을 가게 하는 조직원이 등장할 수 있습니다. 이를 게임 브레이커라고 부르겠습니다.
그라운드 룰을 잘 지키고 있는 조직일지라도 약속한 출근 시간을 제대로 지키지 않는다던지, 미팅 시간을 지키지 않고 타 조직원을 기다리게 한다던지, 업무 시간에 개인 시간을 장시간 보낸다던지 하는 인원이 등장하면 어수선해지기 마련입니다. 좋은 팀 문화를 만드는데 오랜 시간이 걸린다면, 좋았던 팀 문화를 깨부수는 것은 단 한 달이면 충분합니다.
조직을 감시하는 리더나 해당 조직의 상위 조직의 조직장은 이런 게임 브레이커의 등장을 잘 감시할 의무가 있습니다. 그래야 팀의 생산성을 깨뜨리지 않으니까요.
결국 하고싶은 이야기는 게임 브레이커의 등장을 경계해야 하지만 나 자신이 게임 브레이커가 될 수 있다는 생각을 항상 가지고 조직에 임해야 한다는 것 입니다. 결국은 책임감을 가지고 그라운드 룰을 지켜야 개발 프로세스를 잘 지킬수 있는 건강한 애자일 조직이 될 수 있습니다.
결론
좋은 인터뷰를 통해서 애자일 방법론에 대해서 다시 한번 고민할 수 있게 되었습니다. 최근 참여중인 프로젝트에서도 스프린트를 도입해 애자일하게 일을 하고자 고민을 했고 팀 워크플로우를 재정립하게 되었는데, 해당 과정에서 이런 저런 고민을 하면서 팀 문화에 대해 많은 관심이 생겼습니다.
현재는 무직인 상태에서 앞으로 어떤 조직에 들어가 어떤 팀 문화를 맞이하게 될지 기대가 됩니다. 아직 조직의 팀 문화가 갖춰지지 않는 조직에 조직원으로 참여하게 된다면 이런 저런 고민을 바탕으로 좋은 팀 문화를 조직원들과 함께 만들어가는 경험을 해봤으면 좋겠습니다.
읽어봐주셔서 감사합니다.
워터풀, 애자일 이미지 출처: 코드스테이츠
