Spotify engineering culture (part 1) from Spotify Labs
이미 잘 알려진 서비스인 Spotify는 2008년에 창업해 2010년에 어느 정도 규모의 서비스 (1000만 사용자)에 도달, 2013년 연간 활성 사용자가 2400만명인 서비스이고, 현재 회사의 규모는 1200명 수준의 조직으로, 이제는 어느 정도 성숙해져가고 있는 엔지니어링 조직을 가지고 있는 회사라고 말할 수 있을 것 같습니다.
현재 몸을 담고 있는 회사의 문화와도 닮은 부분이 많이 있어서 공감도 되고, 두고두고 엔지니어링 문화의 지향점에 대해서 생각할 수 있는 기회가 되는 듯 해서 정리를 한번 해둡니다. 불과 10분 남짓한 비디오이므로, 엔지니어링 문화에 관심이 있다면 비디오를 반드시 한번 쯤은 시청해두면 좋을 듯 합니다.
1. Make Rules Optional
초기에는 Scrum을 사용하는 팀 문화를 가지고 있었다고 하나, 어느 순간 이러한 프랙티스들이 오히려 방해가 되었다고 합니다.
그래서, 규칙을 강제하지 않고, 프랙티스 보다는 원칙, Process Master보다는 Servant Leader를 강조하는 문화를 도입했다고 합니다.
2. Autonomous Squad
Scrum Team이었던 조직을 Squad라고 이름을 바꾸었다고 하는데요. (이름이 참 마음에 드네요!) Squad의 핵심은 자율성(autonomy)입니다. Squad는 보통 8명 이하의 작은 조직이지만, cross-functional한 조직으로 디자인, 개발, 디플로이, 유지보수, 운영에 이르기까지 end-to-end responsibility를 가지고 있다고 합니다.
Squad는 미션이나 관련된 제품에 대한 전략 등의 장기적인 미션을 가지고 있으면서도, 무엇을 어떻게 개발할 지(what to build, how to build)에 대한 단기적인 목표도 분기별로 정해진다고 합니다.
사무실은 협력을 최대한 도와줄 수 있도록 최적화되어있다고 합니다. Squad 내에서 팀원들은 서로의 모니터를 쉽게 볼 수 있도록 배치되어있으며, 계획 등을 할 수 있는 라운지가 있고, 모든 벽은 화이트보드로 되어있다고 하네요.
3. Autonomy vs. Alignment
자율성이 중요한 이유로 2가지 이유를 들고 있습니다. 하나는 동기부여(motivating)이고 다른 하나는, 결정이 내부에서 이루어지고, 의존 관계나 조율 등을 위해 다른 조직을 기다릴 필요가 없기 때문에 빠르다(fast)는 것입니다.
그렇다고 해서 회사와는 아무런 상관도 없이 흘러가는 조직이 아니라, Loosely coupled, Tightly aligned squads를 지향합니다. (Aligned autonomy!)
Autonomy와 Alignment가 서로 반대 극에 있는 개념이 아니라, 아래와 같이 다른 차원의 문제로 해석하고 있고, 오히려 Alignment로 인해 Autonomy가 가능해진다고 얘기하고 있습니다.
리더의 책임은 무엇이 해결해야할 문제이고, 왜 해결해야하는지에 대해 커뮤니케이션하는 것, Squad의 책임은 가장 좋은 해결책을 찾기 위해 서로 협력하는 것이라고 얘기하고 있습니다.
4. Cross-pollination over Standardization
pollination이란 식물의 (생식 수단으로서의) 수분을 말하는 것인데요. 어떠한 프랙티스나 도구를 전체 조직으로 표준화해버리기 보다는 하나의 조직에서 좋은 프랙티스를 도입하거나 도구를 개발하고, 이를 다른 조직에서도 채용하기 시작하고, 그것을 지원하고, 결국 de facto 표준이 되는 문화를 얘기하고 있습니다. 일관성(consistency)와 유연성(flexibility) 사이의 좋은 trade-off를 찾는다고 하네요.
5. Internal Open-source Model
Spotify 내의 각각의 시스템들은 가능한한 작고 서로 decouple되도록 유지하려고 한다고 합니다. 각 시스템들은 하나 또는 몇몇 squad가 담당하고 있다고 하는데요.
만약 어떤 squad가 다른 squad가 담당하고 있는 시스템의 개선이 필요하다면 그 squad에 부탁하면 되지만, 만약 그 squad가 너무 바쁘다면 이를 기다릴 필요가 없다고 합니다. 오픈 소스 모델로 직접 수정을 하고 peer review를 받으면 되는 것 같습니다.
6. People over *
동기부여(motivation)에 집중을 한 이후에 만족도 조사가 상승했다는 결과를 얘기하고 있습니다.
7. Community over Structure
Squard들은 위에서 얘기한대로 cross-functional 팀이지만, 역량 분야 (competency area)에 따른 Chapter라는 조직이 있는 매트릭스 조직 (matrix organization)으로, 자신의 팀장을 바꾸지 않고도 Squad를 바꿀 수가 있다고 합니다.
그리고, Squad나 Chapter와는 상관없이 서로 관심사를 공유하는 사람들은 Guild라는 가벼운 레벨의 interest group을 구성한다고 합니다.
계층적인 조직 구조(structure)보다는 좀 더 커뮤너티(community)와 같은 문화를 지향하는 것을 다음과 같은 말로 요약하고 있습니다.
“If you need to know exactly who is making decisions, you are in the wrong place.”
8. Small, Frequent, Decoupled Release
릴리즈가 정말로 힘들었다라고 하는 경험을 돌아보면 많은 경우 장기간에 걸친 커다란 릴리즈였던 경우였기 때문에, 저도 작은 릴리즈를 굉장히 선호하는 편인데요. 이제는 이러한 방식이 여러 회사들에서 자리잡고 있는 것 같습니다.
여러 squad의 결과물이 하나의 제품 화면을 구성하는 경우에도, 이를 별도로 릴리즈할 수 있도록 하고 있다고 합니다. UI 또는 시스템적으로 먼저 의존 관계를 제거화고 이를 유지할 수 있어야만 가능한 이야기라고 생각하기 때문에 굉장히 놀라운 이야기로 들리네요.
9. Self-service model
하나의 조직에서 다른 조직으로 서비스를 제공하는 방식으로 다른 조직으로 책임을 완전히 넘기는 것이 아니라, 방법을 마련해주고 실제로 실행은 그 조직에서 하는 방식입니다. 커다란 회사에서는 오히려 생존을 위해서 내부 제품을 개발하는 조직도 내부 서비스 조직으로 탈바꿈하는 경우가 있었는데, 다시 생각해볼 문제인 것 같네요. 조직이 커져가는 과정에서 어떤 형태로든 내부 서비스에 대한 concern의 분리는, 그 품질에 나쁜 영향을 준다고 생각하고 있는데, Self-service model도 그 대안 중 하나가 될 수는 있겠네요.
10. Release trains + Feature toggles
개발 완료되지 않은 기능들을 릴리즈에 포함하지만 이를 서비스에 나타나지 않도록 기능을 on/off할 수 있다고 합니다. 완료되지 않은 기능을 릴리즈하는 것이 조금 이상하게 생각될 수 있겠지만, 이를 통해 좀 더 일찍 통합 문제 (integration problems)를 발견할 수 있고, 적지 않은 개발 비용이 발생하는 code branch를 최소화할 수 있다고 얘기합니다.
11. Trust > Control
최근 수년간 ‘Agile at scale’이 유행하고 있었는데, 이를 위해서는 ‘Trust at scale’이 필요하다고 얘기하고 있습니다. 두려움은 단지 신뢰를 없애는 것이 아니라, 혁신도 불가능하게 만든다고 얘기하고 있습니다. (fear doesn’t just kill trust, it kills innovation.)
