팀을 어떻게 운영해야할까?

레벨2의 마지막 날 레벨3, 4를 함께할 팀을 발표했다. 레벨3 주제의 키워드는 찐합 협업이었다. 함께 자라기, 협업의 중요성을 많이 강조했다.

소프트웨어 산업에서 협업이 중요한 이유는 사용자의 니즈가 불확실하기 때문이다. 혼자서 기민하게 대응 하기는 어렵다. 같은 문제를 바라보는 사람의 관점에 따라 달라질 수 있기 때문에 빠르게 대응할 수 있으려면 협업이 잘 이뤄져야 한다.

애자일이라는 단어는 IT 회사 문화 소개할 때 종종 등장하는 말인데, 정확한 의미를 몰랐다. 지금도 뚜렷하지는 않지만 대강 어떤 느낌이라는 것만 파악하고 있는 정도다.

우아한테크코스 포비는 방학식 때 과감하게 서비스가 망해도 상관없다는 말을 했다. 그만큼 팀원과의 신뢰관계를 높이는 것을 강조했다.

팀 문화

팀 문화를 공유하는 것이 첫 데모데이 요구사항 중 하나였다. 방학기간 중 프로젝트 아이디어와 팀 문화에 대해서 각자 고민해오기로 했었다. 첫 회의때 프로젝트 아이디어를 공유하며 이번 프로젝트를 통해 얻어가고 싶은 것들을 공유했다. 나는 대부분 좋은 협업 경험을 많이 이야기할 줄 알았는데, 생각보다 문화에 대한 수요가 많지는 않았다. 내가 얻어가고 싶었던 것은 성공적인 팀 문화였다. 서비스가 그렇게 매력적이지 않아도 좋고, 뛰어난 기술이나 성능도 바라지 않았다.

각자가 프로젝트에서 바라는 점은 크게 3가지 분류로 나눌 수 있었다. 매력적인 서비스, 다양하고 전문적인 기술, 그리고 협업하는 방식. 나는 이 중 협업하는 방식을 얻어가고 싶었기 때문에 스크럼, 익스트림 프로그래밍과 같은 책을 읽으며 애자일 전문가에게 더 나은 팀 운영방식에 대해 듣고 싶었다. 이어서 우리 팀이 시도한 애자일한 협업 방식에 대한 후기들을 적어보도록 하겠다.

시도해본 협업 방식

1. 몹 프로그래밍

백엔드 크루 4명이서 하나의 프로젝트를 작성해야하니 컨벤션을 맞출 필요가 있었다. 초반에는 4명 전원이 같이 코드를 작성하는 몹프로그래밍을 시도했다. 코드 스타일 통일, GitHub 관련 템플릿 작성, 코드 작성 방식 공유 등 각자의 개발 철학을 공유하며 팀간의 컨벤션을 맞추는게 목적이었다. 결론부터 말하면 우리팀에서는 몹 프로그래밍이 적합하지 않았다.

2주 동안 진행했는데 모두가 주도하고 싶어하는 스타일이다 보니 사소한 것도 결정이 잘 내려지지 않았다. 속도가 잘 나질 않았고 불안감을 느끼거나 방식에 대한 회의감을 느끼는 사람도 생겼다. 어찌저찌해 팀 컨벤션을 만들었지만, 그 컨벤션을 마음에 들어하는 사람은 아무도 없었다. 결국 각자의 방식대로 코드를 작성하고 이 때문에 팀에서 갈등이 생겼다.

왜 우리는 몹 프로그래밍에 실패했을까? 나는 신뢰관계의 부재가 컸다고 생각한다. 우리는 같이 코드를 짜본적이 없었고, 서로에 대해 잘 몰랐다. 4명이서 다같이 컨벤션을 맞추기 보다는 우리에겐 익숙한 페어프로그래밍 형식으로 맞춰갔으면 좋지 않았을까 하는 후회가 된다. 프로젝트 초반에 자주 나왔던 말이다 이게 과연 애자일한 방법인가? 하지만 누구도 대답할수가 없었다. 각자가 생각한 애자일 방식이 달랐기 때문이다.

2. 스크럼

팀 전체 회의는 스크럼 기반으로 진행했다. 우아한테크코스는 2주 단위로 스프린트를 구성했지만 우리는 한번더 쪼개어 1주씩 운영했다. 매주 월요일은 스프린트 회의를 진행했고, 백로그를 기반으로 구현하고 싶은 부분을 나눠서 가져갔다. 초반에는 데일리를 오전에 한번만 진행했는데, 기능 구현하는 속도가 빨라지고 파트별 회의가 더 필요하게 되어 나중에는 데일리 스크럼을 오전과 오후 두번 진행했다. 매주 스크럼 마스터는 회의 진행에 필요한 공간대여와 슬랙 공지를 올리는 역할을 수행했다.

스크럼은 성공적으로 이뤄졌다. 스크럼의 핵심은 자신이 개발하는 기능 뿐만 아니라 현재 진행되는 업무의 척도도 판단이 같이 이뤄지는 것이라 생각한다. 스크럼 회의를 2번이나 하게되어 시간 자원은 많이 사용하게 됐지만, 그만큼 모두가 개발중인 기능에 관심을 가지고 임할 수 있었다. 팀원이 맡은 작업이 원활히 수행되지 않을 때 늦어도 12시간안에 체크가 가능했다.

3. 감정 회고

우아한테크코스에서 지정해준 2주 단위의 스프린트가 마칠 때, 우리는 행복회로라고 부르는 감정회고 시간을 가졌다. 초반에 자기의 의견을 피력해야할 경우가 많은데 반려되는 경우에 감정이 상할 수 있기 때문에 꼭 필요한 장치라고 생각했다. KPT 방식을 채용하여 현재 팀에서 지켜지고 있는 좋은 문화와 해가 되는 문화를 파악할 수 있었다. 초반에는 어느정도 효용이 있었지만, 후반부에는 거의 안하다시피 했다.

감정회고의 한계는 솔직해지기 어렵다는 것이다. 감정적으로 상한 일이 있다 하더라도 다같이 모여서 진행하기 때문에 모두가 솔직해지기 어려웠다. KPT 방식으로 아무리 편안한 분위기를 조성해도 선뜻 쉽게 이야기하기는 어려웠을 것이라고 생각한다. 이런 부분들은 오히려 술기운에 도움을 빌려 서로 신뢰관계를 높이는게 나은 방법인가 싶기도 한다.

찐한 협업을 경험했는가?

우아한테크코스에 들어와서 Java, Spring, TDD, CleanCode 등 다양한 프로그래밍 스킬과 방식들을 배웠다. 그때는 단지 프로그래밍을 잘하는 기술을 배운다고 생각했다. 프로그래밍을 잘한다는 것은 무엇을 의미하는가? 성능이 좋고 뛰어난 기술을 사용한다고 해서 좋은 코드라고 말할 수 있을까? 이번에 프로젝트를 진행하면서 애자일 개발 선언문에 적힌 내용이 왜 이렇게 적혀있는지 깨달을 수 있었다.

<사진 출처:https://agilemanifesto.org/iso/ko/manifesto.html>

적어도 지금 내가 배워왔던 개념들의 종착지는 애자일 선언문으로 귀결된다. 클린 코드, TDD, 객체 지향적인 코드를 지향하는 것은 결국 변화에 예민하게 대응하기 위함이다. 프로젝트 기간동안 우리 서비스가 해결하기 위한 문제에 집중하려고 했다. 자연스럽게 객체 지향적인 설계, 클린코드 그리고 테스트 코드가 기반되어 변화에 빠르게 대응할 수 있는 코드를 짜내기 위해 고민했다.

애자일은 팀 문화이자 현재 나와있는 개발 방법론들의 철학을 담고 있다. 팀원들끼리 코드 리뷰를 하면서 더 나은 설계에 대해 고민하고 토론하며 우리는 나름대로의 찐한 협업을 했다. 처음에 계획한대로 흘러가지는 않았지만, 반대로 계획한대로 흘러가지 않았기 때문에 우리는 찐한 협업을 경험했다고 말할 수 있을 것 같다.