NBT가 일하는 방식

제품 개발 조직의 구조
칸반이 진화해 온 과정

이번에는 NBT의 간판(看板)인 칸반(看板)이 변화해온 모습을 공유하려고 한다. 지난 2년여 동안, NBT의 제품 개발 프로세스는 상황에 맞게 계속 바뀌어왔고, 칸반 보드 역시 거기에 맞추어 함께 진화해왔다.

내가 합류했을 때 캐시슬라이드는 서비스를 출시한지 이미 1년 정도가 지난 상황이었고, 그래서 (물론 신규 기능 개발도 여전히 활발히 일어나고 있긴 하지만) 어느 정도 유지보수 모드에 들어간 상태라고 판단했기 때문에 칸반을 선택했다. 만약 새로운 서비스를 개발하는 팀이고 인원이 더 적었더라면 아마도 스크럼을 선택했을 것이다. 하지만, 지금은 칸반을 기반으로 스크럼으로부터도 다양한 원칙과 실천법을 가져와 적시적소에 활용하고 있다.

1세대 (2014년 2월 ~ )

NBT에서 첫 번째로 사용했던 칸반 보드다. 구조가 매우 단순해서 “To-Do”, “Development”, “Done”의 세 단계로 구성했고, WIP 제한은 엄격하게 적용하지 않았다. To-Do 다음에 “Planning” 단계를 그려놓긴 했지만 실제로 사용하지는 않았는데, 당시 개발팀과 별도 조직이던 서비스기획팀 구성원들에게 함께 참여할 수 있음을 간접적으로 알리는 단순한 용도였다.

그리고, Development 하위에 다시 단계를 세분화해서 2-tier 로 구성하였다. 관리자의 관점에서 보았을 때 그다지 중요하지 않지만, 칸반을 처음 사용하는 개발자에게는 이런 구성이 도움이 될 수 있다. 이렇게 하면, 프로젝트를 시작할 때 어떤 세부 작업이 필요한지 미리 고민하는 습관을 키울 수 있고, 포스트잇을 다음 단계로 옮기는 손맛(?)을 더 자주 느낄 수 있다.

가장 중요한 것은, 당시 개발 프로세스를 그대로 보드에 옮겨놓고, 가장 기본적인 몇 가지 운영 규칙만 정했다는 점이다. 칸반을 처음 적용할 때에는 단순하게, 현재 상태 그대로 시작하는 것이 좋다.

2세대 (2014년 3월 ~ )

1세대를 한 달 남짓 사용한 이후 개선한 버전이다. 크게 바뀐 것은 없다. 좀 더 양이 늘어난 백로그를 관리하기 위해 구글 스프레드시트를 사용하기 시작했고, 칸반 보드의 시각화 측면을 강화하기 위해 고무 자석을 활용한 것도 이때부터다.

또한, (전담 테스트 인력이 있었던 것은 아니지만) “Test” 단계와 “Release Ready” 단계를 명시적으로 활용하기 시작했다.

3세대 (2014년 6월 ~ )

서비스기획팀도 칸반 보드를 함께 활용해보기로 하면서 개발 프로세스 이전 단계까지 포함하기 시작했다. 서비스 기획 단계를 명시적으로 표현하기가 쉽진 않았고, 결과적으로 활용도 그렇게 원활하지는 못했지만, 하나의 아이디어가 사용자의 손에 들어가기 전까지 모든 단계를 볼 수 있게 되었다는 점이 3세대 칸반 보드에서 가장 중요한 부분이다.

왼쪽 상단 “서비스 기획 INBOX” 단계에서 출발해서, 왼쪽 하단의 “출시 완료” 단계에서 끝나는 구조로 되어있다. 좁은 공간에 많은 정보를 표현하려다보니 상당히 복잡했다.

4세대 (2014년 7월 ~ )

새로운 사무실로 이전하면서 훨씬 넓은 보드를 벽에 부착하여, 4세대 칸반 보드를 구성해서 활용하였다. 공간이 넓어 3세대를 넓게 펼쳐놓았고 크게 달라진 것은 없다.

4세대 칸반 보드를 상대적으로 가장 오랫동안 사용했었는데, 칸반을 사용하면서 이 때가 가장 어려웠던 시기였다. 뭔가 복잡하고 있어보이지만 제대로 활용되지 못한 부분이 많았고, 인원이 늘어나면서 일일 스탠드업 회의 참여 인원이 한 번에 30명이 넘는 등 개인적으로도 대단히 혼란스러운 상황이었다.

시행착오를 겪으면서 큰 개선 없이 오랫동안 유지했던 4세대 칸반은, 혼자 설계하고 구성하고 관리했던 마지막 세대다.

5세대 (2015년 4월 ~ )

4세대 보드의 가장 큰 단점은 크기가 작은 소규모 유지보수 과제와 굵직한 주요 과제(“핵심 과제”라고 불렀다)가 칸반 보드 상에 뒤섞여 있어, 핵심 과제의 진행 상황만 별도로 보기 어려웠다는 점이다. 핵심 과제는 경영 목표 달성을 위해 그 주목도가 훨씬 더 높을 필요가 있었다. 그래서, 5세대 칸반에서는 각 핵심 과제를 빼내서 별도로 진행 상황을 알아볼 수 있도록 구성하였다. 이 시기에 서비스 기획은 칸반을 거의 활용하지 않는 상태로 다시 돌아갔다.

이때부터 EC(Engineering Cultrue) 클래스 구성원들과 함께 칸반 보드를 설계하고 구성하기 시작했다. 고무 자석을 활용하여 다양한 시각화 장치가 본격적으로 등장하기 시작한 것도 이때부터다.

6세대 (2015년 9월 ~ )

또 다시 사무실이 이전하면서, 새롭게 6세대 칸반을 구성하였다. 크게 두 부분으로 나누었는데, 왼쪽은 캐시슬라이드를 개발하는 두 파티가, 오른쪽은 DevOps, Data, Engineering Cultrure 클래스와 같은 전문가 팀이 활용하는 형태였다.

이 시기에 가장 중요한 것은, 나는 큰 틀만 구성하고 세부적인 사항들은 각 파티와 클래스가 아이디어를 내고 개선하면서 칸반 보드를 직접 바꾸기 시작했다는 점이다.

7세대 (2016년 1월 ~ )

6세대 보드에서 각 클래스의 칸반 보드 활용도가 다소 떨어진다는 피드백이 있었고 파티도 2개에서 3개로 늘었기 때문에, 캐시슬라이드를 직접 개발하는 파티들이 좀 더 넓은 공간을 활용할 수 있도록 단순하게 구성했다. 이 때부터 AD, User, Cash의 세 파티가 칸반 보드를 자발적으로 활용하고 개선하면서 개인적으로는 관리 부담이 많이 줄어들었다.

8세대 (2016년 3월 ~ 현재)

현재의 모습이다. 중요한 변화가 몇 가지 있는데, 윗 부분에 개발 프로세스 정책이나 완료 기준을 (현실적이며 복잡하지 않은 선에서) 명시화 하였고, 아랫 부분에는 각 단계의 사이클 타임의 추세를 참고할 수 있도록 했다. “출시 완료” 단계 이후에 성과를 분석하고 게시할 수 있는 자리도 마련해서, 프로젝트 완료 이후 그 결과가 어땠는지도 모두가 알 수 있도록 했다.

2014년 2월부터 지금까지 약 26개월 동안 NBT의 칸반 보드에는 큼직한 변화가 8번 정도 (대략 세 달에 한 번 꼴) 있었지만, 작은 변화와 실험은 꾸준히 이루어져왔고, 칸반 보드는 지금도 지속적으로 바뀌고 있다.

변화하지 않는 칸반 보드는 죽은 보드다.

앞으로도 NBT 칸반 보드의 모습은 계속 바뀌어갈 것이다. 앞서 이야기했던 바와 같이 조직 구성도 마찬가지지만, 우리를 둘러싼 환경과 해결해야 하는 문제가 계속 달라지기 때문이다. 지금 최선이라고 생각하는 방법이 영원히 최선일 수 없기 때문에, 우리에게 맞는 더 나은 개발 프로세스를 만들기 위해 모든 구성원이 끊임 없이 노력하고 있다.

그 밖의 보드들

아래 사례들은 제품 개발 조직 캐시슬라이드를 개발하면서 사용하고 있는 칸반 보드와는 별개로, NBT 곳곳에서 자발적으로 등장한 보드들이다. 엄밀히 따지면 칸반 보드라고 보기 어려운 것들이지만, 별다른 장치나 정책이 없더라도, 업무를 시각화하는 것만으로도 성과를 크게 개선할 수 있다.

운영팀에서 목격한 개인 칸반 보드다. 구성은 무척 단순하지만, 제품 개발 조직에서 활용하고 있는 칸반을 보고 조직 외부에서 자발적으로 업무를 시각화한 첫 번째 사례다.

그 이후 운영팀은 팀 차원에서 칸반을 활용하기 시작했다.

캐시슬라이드와는 별개의 제품을 개발하는 TF에서 업무를 시각화 해놓은 모습이다. 구체적으로 어떻게 활용하고 있는지는 잘 모르지만, 매일 이 앞에 모여 스탠드업 회의를 진행하고 있고, 팀 외부에서도 진행 상황을 알 수 있도록 팀 공간 내부가 아니라 외부를 활용한 모습이 인상적이었다.