Close

팀 토폴로지

4가지 기본 토폴로지가 DevOps 전환에 미치는 영향

Ian Buchanan

수석 솔루션 엔지니어

편집 기고자: Shana Vu

스트림 정렬 팀의 이점과 플랫폼 팀, 하위 시스템 팀과 협력하고 팀이 고객에게 가치를 제공하도록 지원하는 방법에 대해 알아보세요.

팀 토폴로지 소개


엔지니어링 팀은 고객에게 가치를 제공하기 위해 그 어느 때보다 빠르게 움직여야 합니다. 클라우드, SaaS 및 상시 서비스가 등장하면서 고객은 새로운 기능, 더 적은 버그 및 99.99% 이상의 가동 시간을 기대합니다.

이러한 요구에 부응하기 위해, 조직은 애자일 관행 및 최근에는 출시 시간 및 리드 타임 단축, 배포 빈도 개선, 팀 문화 개선, 팀 및 부서 간 협업 증대를 제공하는 DevOps 관행을 채택했습니다.

DevOps 관행을 채택하는 것은 말처럼 쉽지는 않지만, Team Topologies 책은 조직이 DevOps를 회사에 구축할 수 있는 통찰력 있는 방법을 비롯하여 어떤 유형의 팀이 가장 효과적일 수 있는지 보여줍니다. 이 책은 Atlassian이 팀에 대해 생각하는 방법의 시작점을 제공합니다. 연구 결과를 반복해서 말하기보다는, 팀 유형에 대한 Atlassian만의 관점을 공유하려고 합니다.

DevOps 혁신을 향한 첫 번째 단계는 적절한 조직 구조를 파악하는 것입니다. 그러나 오늘날에는 어떤 회사든 다양한 팀 유형이 있으며, 경우에 따라 하나의 팀이 여러 역할과 책임을 맡을 수도 있습니다. 이러한 무분별한 확산은 리더십이 전체 조직 환경을 시각화하고 다음과 같은 중요한 질문에 답하기 어렵게 만듭니다.

솔루션 보기

팀 전체를 위한 DevOps 도구

관련 자료

DevOps 문화 구축

  • 알맞은 팀이 마련되어 있습니까?
  • 어떤 팀에서도 다루지 않는 일부 영역에서의 역량이 부족합니까?
  • 팀이 자율성과 다른 팀에게 받는 지원 사이에서 필요한 균형을 유지하고 있습니까?

개발 및 운영 리더는 팀 토폴로지의 관점에서 조직을 살펴보고 알맞은 팀이 마련되어 있는지 더 잘 이해할 수 있습니다. 경영진과 실제 팀원 모두가 쉽게 이해할 수 있도록, 팀 변형의 개수를 4가지 기본 팀 토폴로지로 줄이는 것이 좋습니다.

  • 스트림 정렬 팀
  • 플랫폼 팀
  • 난해한 하위 시스템 팀
  • 권한 부여 팀

팀 유형은 회사의 규모와 성숙도에 따라 다른 형태를 취합니다. 실제로는 두 개 이상의 팀 유형을 조합하거나 한 팀에서 다른 팀으로 바꾸는 것이 가장 좋은 방법인 경우가 많습니다.

스트림 정렬 팀

스트림 정렬 팀은 영향력 있는 단일 작업 흐름에 집중합니다. 단일 제품 또는 서비스, 단일 기능 집합, 단일 사용자 여정 또는 단일 사용자 고객 특성이 될 수 있습니다. 팀은 다른 팀에게 작업의 일부를 전다할 필요 없이 최대한 빠르고 안전하며 독립적으로 고객 또는 사용자 가치를 구축하고 제공할 수 있습니다.

스트림 정렬 팀은 제공의 모든 범위에서 작업하기 때문에, 필요에 따라 고객과 더 가까울 수 있으며 일반적으로 이미 민첩성을 가지고 있습니다. 이 팀은 프로덕션 단계에서 소프트웨어를 유지하면서 개발 주기에 고객 피드백을 통합합니다.

많은 소프트웨어 회사에서는 스트림 정렬 팀이 흔하지만, 다른 조직에서는 제공 흐름보다 기능별로 구성된 팀 구조(예: 엔지니어링, 설계, QA를 위한 별도의 팀)가 더 익숙할 수 있습니다.

스트림 정렬 팀은 조직에서 가장 일반적인 팀 유형이므로 스트림 정렬 팀과 관련하여 다른 팀의 역할이 정의됩니다. 스트림 정렬 팀은 제품 및 서비스의 제공 속도와 품질을 지속적으로 개선하기 위해 다음과 같은 지원 팀(난해한 하위 시스템, 지원 및 플랫폼)과 정기적으로 커뮤니케이션해야 합니다.


Stream-aligned teams focus on a single, impactful stream of work. It can be a single product or service, a single set of features, a single user journey, or a single user persona. The team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work.

Because stream-aligned teams work on the full spectrum of delivery, they are, by necessity, closer to the customer and usually already agile. This team incorporates customer feedback in development cycles, while maintaining software in production. 

While stream-aligned teams are common at many software companies, other organizations may be more familiar with team structures organized by function (i.e. separate teams for engineering, design, QA), rather than the delivery stream. 

Since the stream-aligned team is the most common team type in organizations, the role of other teams is defined relative to stream-aligned teams. Stream-aligned teams should regularly reach out to the following supporting teams (complicated subsystem, enabling, and platform) to continuously improve the speed of delivery and quality of their products and services.

플랫폼 팀

플랫폼 팀은 스트림 정렬 팀이 상당한 자율성을 갖추고 작업을 제공하도록 지원합니다. 스트림 정렬 팀은 프로덕션 환경에서 애플리케이션을 구축, 실행 및 수정하는 데 대한 완전한 소유권을 유지하는 한편, 플랫폼 팀은 스트림 정렬 팀에서 사용할 수 있는 내부 서비스를 제공합니다.

플랫폼 팀은 수많은 스트림 정렬 팀에서 적은 수준의 오버헤드로 사용할 수 있는 기능을 만듭니다. 플랫폼 팀은 제품을 최적화하여 스트림 정렬 팀의 리소스와 인지 부하를 최소화합니다. 플랫폼 팀은 다양한 사용자 경험 또는 제품에 걸쳐 일관된 경험을 만들 수 있으므로 최종 사용자에게도 이점을 제공합니다.

Atlassian의 플랫폼 팀은 ID 관리와 같이 Atlassian의 모든 제품에서 사용하는 서비스를 구축하며 스트림 정렬 팀에 문서, 지원 및 컨설팅을 제공해야 합니다.


Platform teams enable stream-aligned teams to deliver work with substantial autonomy. While the stream-aligned team maintains full ownership of building, running, and fixing an application in production, the platform team provides internal services that the stream-aligned team can use.

Platform teams create capabilities that can be used by numerous stream-aligned teams, with little overhead. By optimizing a product, platform teams minimize resources and cognitive loads of the stream-aligned team. This also benefits end-users too, since platform teams can create a cohesive experience that spans across different user experiences or products.

Here at Atlassian, platform teams build services used by all of our products (like identity management) and are expected to provide documentation, support, and consultation for stream-aligned teams.

난해한 하위 시스템 팀

난해한 하위 시스템 팀은 특정 기술과 지식에 따라 시스템의 일부를 구축하고 유지 관리하는 일을 담당합니다. 대부분의 팀원은 특정 지식 영역의 전문가여야 하위 시스템을 이해하고 변경할 수 있습니다.

이 팀의 목표는 하위 시스템을 포함하거나 사용하는 시스템에서 작업하는 스트림 정렬 팀의 부하를 줄이는 것입니다. 스트림 정렬 팀이 난해한 하위 시스템 팀의 전문 지식과 역량을 갖추고 있으면 일상 업무에 너무 복잡한 영역에서 기능을 구축할 필요가 없습니다. 이 팀의 팀원은 특정 마이크로서비스(예: 청구 서비스), 알고리즘 또는 인공 지능에 대한 전문 지식을 보유할 수 있습니다.

일반적인 위험은 하위 시스템을 사용하는 모든 스트림 정렬 팀에 전문가를 포함시키는 것입니다. 이 방법은 효율적인 것처럼 보일 수도 있지만 궁극적으로 비용 효율적이지는 않으며, 스트림 정렬 팀의 범위를 벗어납니다.


A complicated-subsystem team is responsible for building and maintaining a part of the system that depends on specific skills and knowledge. Most team members must be specialists in a particular area of knowledge to understand and make changes to the subsystem.

The goal of this team is to reduce the load of stream-aligned teams who work on systems that include or use the subsystem. With the complicated-subsystem team’s expertise and capabilities, stream-aligned teams don’t have to build capabilities in areas too complicated for their daily work. Team members from this team may have specialized knowledge in certain microservices (i.e. a billing service), algorithms, or even artificial intelligence. 

A common pitfall is to embed specialists in every stream-aligned team who uses the subsystem. While this may seem efficient, it’s ultimately not cost-effective and out of scope for a stream-aligned team. 

권한 부여 팀

스트림 정렬 팀은 변화를 신속하게 전달하고 이에 대응해야 하는 끊임없는 압박을 받고 있기 때문에 새로운 기술을 연구, 학습 및 연습할 시간을 내기가 어렵습니다.

특정 기술(또는 제품) 분야의 전문가로 구성된 권한 부여팀은 이러한 기능 격차를 해소하는 데 도움이 됩니다. 이러한 팀은 연구 및 실험에 집중하여 도구 스택에 영향을 미치는 도구 선택, 프레임워크 및 에코시스템 선택을 내리는 데 합리적 제안을 제공합니다.

이를 통해 스트림 정렬 팀은 기본 목표를 위한 시간을 빼앗기지 않고도 기능을 습득하고 발전시킬 수 있습니다. 권한 부여 팀은 해결책이 아닌 문제에 중점을 두고 역량을 강화하여 주로 스트림 정렬 팀의 자율성을 높이고자 합니다.

권한 부여 팀이 이 업무를 잘 수행하는 경우 지원을 받는 팀은 몇 주 정도 지나면 더 이상 도움이 필요하지 않습니다. 권한 부여 팀은 영구적인 종속성에 대해 작업해서는 안 됩니다.


Stream-aligned teams are under constant pressure to deliver and respond to change quickly, making it challenging to find time for researching, learning, and practicing new skills.

An enabling team composed of specialists in a given technical (or product) domain help bridge this capability gap. These teams focus on research and experimentation to make informed suggestions about tooling, frameworks, and ecosystem choices that affect the tool stack.

This gives stream-aligned teams time to acquire and evolve capabilities without taking time away from their primary goals. The enabling team seeks to primarily increase the autonomy of stream-aligned teams by growing their capabilities with a focus on problems, rather than solutions.

If an enabling team does its job well, the team it assists should no longer need help after a few weeks or so. The enabling team should never work on a permanent dependency.

Are you a stream-aligned team?


The following questions should be asked to determine if you have a stream-aligned team:

Does your team aim to produce a steady flow of features?
Mature teams release multiple times per week, and in some cases, multiple times per day. In pursuit of this goal, mature teams should use continuous integration and continuous delivery (CI/CD) to ship features frequently.

Is your team quick to change direction based on feedback (customer or internal) from the latest changes?
It’s often best to use an experimental approach to product evolution. Mature DevOps processes include automated testing to ensure quality code shipments. Yet experimentation goes beyond simple unit or acceptance tests. You can ensure that your products deliver the most value to customers by using feature flags to automate roll-outs to a subset of users, alpha and beta releases to solicit and measure user feedback and behavior, and qualitative continuous feedback via comments, support tickets, and community forums.

Does your team have minimal hand-offs of work to other teams?
This should be true in two ways. Your team should be self-contained and work should happen with immediate teammates to ensure fast delivery. Beyond work scope, minimal hand-offs can also take the form of automated processes. Automating your development cycle ensures that moving things along is a seamless process, regardless if the next step is an action like an automated test or merge to main, or an actual human.

Bonus points if….
Does your team have time to address code quality changes (a.k.a. “tech debt”) to ensure changes are safe and easy? 
Mature teams rely on trunk-based development and CI/CD practices to maintain their codebase. Capacity planning should include dedicated time to address tech debt. Plus, large-scale projects that address underlying infrastructure or platform issues should receive as much attention as feature development.

Is your team evaluated by the right metrics?
Beyond how fast your team ships, it should also consider team-health and technical quality metrics in their measures of success.

Regarding the last question around measurement, DevOps teams have traditionally considered the four key DevOps Research and Assessment (DORA) metrics in their definition of “success”:

  • Deployment frequency - How often an organization successfully releases to production
  • Lead time for changes - The amount of time it takes a commit to get into production
  • Change failure rate - The percentage of deployments that cause a failure in production
  • Time to restore service - How long it takes an organization to recover from a failure in production

In addition to these metrics specified by DORA, Atlassian found that high-performing, stream-aligned teams also monitor these attributes

  • Balanced team -  Your team has a diverse set of skills and perspectives 
  • Full-time owner - A full-time owner ensures that the nuclear team and cross-functional participants know who to ask questions to and how to make decisions related to projects owned by the team 
  • Shared understanding - There is a shared understanding of the requirements, along with the definition for values and metrics for success
  • A focus on value and metrics -  Your team has north stars that guide which tasks to tackle in order to move projects to release  
  • Proof-of-concept - Having a real artifact to spar and test assumptions with helps a team constantly iterate and improve 
  • Managed dependencies to maintain velocity - Understanding managed dependencies keeps blockers at bay and helps the team maintain velocity

 

결론...

DevOps는 하나의 목적지가 아닌 도구, 팀 문화 및 관행을 지속적으로 개선하는 여정입니다. DevOps를 처음 사용하는 경우 고객에게 가치를 제공하기 위한 목표를 세우는 것부터 시작하세요. 성숙도를 쌓아감에 따라 도구와 프로세스에 자동화를 추가하세요. 마지막으로, 팀이 실무에 능숙해지면 적절한 항목을 모니터링, 측정 및 개선하기 위해 관찰 기능을 통합하세요.


DevOps is not a destination, but a journey of constant improvement of tools, team culture, and practices. If you’re new to DevOps, start by orienting your goals to deliver value to customers. As you mature, add automation to your tools and processes. And finally, when your team becomes advanced practitioners, incorporate observability to ensure you’re monitoring, measuring, and improving on the right things.

Ian Buchanan
Ian Buchanan

Ian Buchanan은 Atlassian 의 DevOps 수석 솔루션 엔지니어로, 보다 향상된 지속적 통합 및 지속적 배포를 위해 새롭게 부상하는 DevOps 커뮤니티를 비롯해 Jira, Bitbucket 및 Bamboo 애플리케이션에 중점을 두고 있습니다. Ian은 Java와 .NET 모두에 대한 폭넓은 경험을 보유하고 있으며 대규모 엔터프라이즈에서 린 및 애자일 관행의 챔피언으로 알려져 있습니다.

경력 기간 동안 그는 수명 주기의 모든 단계에서 엔터프라이즈 소프트웨어 개발 도구를 성공적으로 관리했습니다. Ian은 생산성 개선과 탁월한 품질, 향상된 고객 만족으로 조직 차원의 프로세스를 개선했습니다. 그는 스스로 방향을 지정하고 체계화하는 조직을 중시하는 다국적 애자일 팀을 구성했습니다. 강연하거나 코딩을 하지 않을 때에 Ian은 파서, 메타 프로그래밍 및 도메인 지정 언어에 대한 열정에 빠져 있을 것입니다.


이 기사 공유
다음 주제

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

시뮬레이션 워크샵

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up