스트림 정렬 팀

스트림 정렬 팀은 제품이나 서비스 하나를 맡아 처음부터 끝까지 직접 만들고 내보내는 팀입니다. 기능 하나를 낼 때 다른 팀의 손을 거의 거치지 않습니다. 그래서 바뀐 것을 사용자에게 빠르고 자주 내놓을 수 있습니다.

쉽고 빠른 이해

스트림 정렬 팀은 일의 줄기 하나를 통째로 맡는 팀입니다. 쇼핑몰이라면 주문 기능 하나를 화면부터 서버, 데이터, 배포와 운영까지 한 팀이 다 맡습니다.

팀을 화면 팀, 서버 팀, 데이터베이스 팀, 운영 팀으로 나눠 두면 기능 하나가 네 팀을 차례로 거칩니다. 팀을 건널 때마다 기다리는 시간이 쌓입니다. 한 팀이 끝까지 맡으면 그 기다림이 사라집니다.

굴러가는 순서는 이렇습니다.

1. 팀이 맡을 일의 줄기 하나를 고릅니다
2. 그 줄기에 필요한 사람을 한 팀에 모읍니다
3. 여러 팀이 같이 쓰는 기반(배포 도구 · 서버 환경 같은 것)은 다른 팀이 서비스처럼 내줍니다

대가가 있습니다. 한 팀이 알아야 할 것이 많아집니다. 받쳐 주는 팀이 없으면 그 짐에 눌립니다.

개발자가 대여섯뿐인 조직에는 쓸 일이 없습니다. 이미 팀 하나가 전부를 맡고 있기 때문입니다.

상세

이 절은 먼저 「스트림」이 무엇을 가리키는지 정합니다. 그다음 기술별로 나눈 팀에서 무엇이 막히는지 보고, 한 팀이 줄기 하나를 끝까지 맡으면 그것이 어떻게 풀리는지 따라갑니다. 끝으로 이 팀을 받치는 다른 팀들과 이 구성이 치르는 값을 짚습니다.

예로는 쇼핑몰 하나를 끝까지 씁니다. 이 쇼핑몰에는 상품 검색, 주문, 회원 관리 같은 기능이 있습니다. 개발자는 서른 명 남짓입니다.

스트림이라는 말

스트림은 일이 흘러가는 줄기입니다. 변경 하나가 아이디어에서 출발해 사용자 손에 닿기까지 지나는 길을 말합니다. 이 길을 가치 흐름이라고도 부릅니다.

줄기를 무엇으로 자를지는 조직마다 다릅니다. 제품 하나일 수도 있고 서비스 하나일 수도 있습니다. 회원 가입부터 첫 주문까지처럼 사용자가 겪는 과정 하나로 자르기도 합니다. 이런 과정을 사용자 여정이라고 부릅니다.

쇼핑몰에서는 「주문」이 줄기 하나가 됩니다. 장바구니에 담고, 결제하고, 주문 내역을 보는 데까지가 그 줄기입니다. 「정렬」은 팀의 경계를 이 줄기에 맞춘다는 뜻입니다.

기술별로 나눈 팀에서 생기는 일

흔한 팀 구성은 기술별입니다. 화면을 만드는 팀, 서버를 만드는 팀, 데이터베이스를 맡는 팀, 서버를 띄우고 지키는 운영 팀이 따로 있습니다. 같은 기술을 쓰는 사람끼리 모여 있으니 서로 배우기 쉽습니다.

문제는 기능 하나가 이 팀들을 차례로 지나야 한다는 점입니다. 주문 화면에 「배송 예정일」 하나를 더한다고 해 봅시다. 데이터베이스 팀이 칸을 만듭니다. 서버 팀이 그 값을 내줍니다. 화면 팀이 그 값을 화면에 그립니다. 마지막으로 운영 팀이 배포합니다.

한 팀이 맡은 일을 다음 팀에 넘기는 것을 인계라고 부릅니다. 인계마다 기다림이 생깁니다. 받는 팀에는 이미 다른 일이 줄 서 있기 때문입니다.

flowchart TD
    subgraph A["기술별로 나눈 팀"]
        A1["데이터베이스 팀"] -->|인계| A2["서버 팀"]
        A2 -->|인계| A3["화면 팀"]
        A3 -->|인계| A4["운영 팀"]
    end
    subgraph B["스트림 정렬 팀"]
        B1["주문 팀 · 화면 · 서버 · 데이터 · 운영"]
    end
    A4 --> U["사용자"]
    B1 --> U

위쪽은 배송 예정일 하나가 사용자에게 닿기까지 인계를 세 번 거칩니다. 아래쪽은 한 팀 안에서 끝나므로 인계가 없습니다. 손으로 하는 일은 하루면 끝나도 기다림이 쌓이면 몇 주가 걸리기도 합니다.

기다림만 문제가 아닙니다. 팀마다 자기 몫만 보게 되면 기능 전체를 책임지는 사람이 없어집니다. 이렇게 팀끼리 벽을 쌓고 서로 안 보이는 상태를 사일로라고 부릅니다.

한 줄기를 한 팀이 끝까지

스트림 정렬 팀은 줄기 하나에 필요한 사람을 한 팀에 모읍니다. 주문 팀에는 화면 개발자, 서버 개발자, 데이터를 다루는 사람, 테스트를 맡는 사람이 함께 있습니다. 여러 기술을 가진 사람이 한 팀에 섞인 구성을 교차 기능 팀이라고 부릅니다.

이 팀은 만드는 데서 멈추지 않습니다. 자기가 만든 것을 직접 배포하고 운영합니다. 밤에 장애가 나면 그 기능을 만든 팀이 받습니다. 장애 연락을 돌아가며 받는 당번을 온콜이라고 부릅니다.

만든 팀이 운영까지 하면 고칠 곳을 가장 잘 아는 사람이 장애를 받습니다. 운영하면서 겪은 불편이 다음 개발에 곧바로 들어갑니다. 남이 짠 코드를 밤새 들여다보는 일이 줄어듭니다.

이 팀은 오래갑니다. 프로젝트가 끝나면 흩어지는 팀이 아니라 그 줄기가 살아 있는 동안 계속 그 줄기를 맡습니다. 그래서 그 영역의 코드와 사용자를 깊이 알게 됩니다.

이 이름은 팀을 어떻게 짜고 어떻게 잇는지를 다루는 방법론인 팀 토폴로지에서 나왔습니다. 거기서 스트림 정렬 팀은 네 가지 기본 팀 유형 가운데 중심이 되는 유형입니다. 나머지 셋은 아래에서 봅니다.

인지 부하라는 상한

한 팀이 줄기 하나를 다 맡으려면 알아야 할 것이 많습니다. 사람이 한꺼번에 머릿속에 쥐고 있어야 하는 것의 양을 인지 부하라고 부릅니다. 팀에도 인지 부하가 있습니다.

팀이 감당할 수 있는 복잡함에는 한계가 있습니다. 그 한계를 넘으면 결정이 거칠어지고 일이 느려집니다. 그래서 줄기의 크기는 팀 하나가 쥘 수 있는 만큼으로 잡습니다.

쇼핑몰의 주문 줄기가 너무 커졌다고 해 봅시다. 결제만 해도 수단이 여럿이고, 환불과 교환까지 붙었습니다. 이럴 때는 줄기를 「주문하기」와 「환불·교환」으로 나눠 팀 둘에 맡깁니다.

스트림 정렬 팀을 받치는 세 팀

스트림 정렬 팀이 모든 것을 혼자 짊어지면 인지 부하가 금방 넘칩니다. 그래서 나머지 팀 유형 셋은 모두 스트림 정렬 팀의 짐을 덜어 주려고 존재합니다. 아래 표가 그 셋입니다.

플랫폼 팀이 내준 기반은 스트림 정렬 팀이 남에게 묻지 않고 스스로 가져다 씁니다. 이렇게 스스로 꺼내 쓰는 방식을 셀프서비스라고 부릅니다. 배포 한 번에 다른 팀의 손을 빌리면 인계가 다시 생기기 때문입니다.

이런 플랫폼을 만드는 일이 플랫폼 엔지니어링입니다. 플랫폼이 잘 됐는지는 스트림 정렬 팀의 짐이 얼마나 줄었는지로 잽니다.

활성화 팀은 일을 대신 해 주지 않습니다. 기술을 옮겨 심고 나면 빠집니다. 스트림 정렬 팀이 남에게 기대지 않고 스스로 굴러가게 하는 것이 목적이기 때문입니다.

팀끼리 만나는 세 방식

팀 사이의 관계도 이름을 붙여 고릅니다. 관계가 흐릿하면 누가 누구를 기다리는지 안 보이기 때문입니다. 방식은 셋입니다.

스트림 정렬 팀이 상대 팀에 가장 덜 묶이는 방식은 서비스 제공 모드입니다. 상대 팀과 일정을 맞출 필요 없이 쓰기만 하면 됩니다. 협업 모드는 배우는 것이 많습니다. 대신 서로의 시간을 먹으므로 기한을 두고 끝냅니다.

콘웨이의 법칙과 맞물리는 지점

시스템의 구조는 그것을 만든 조직의 소통 구조를 닮아 갑니다. 이 관찰을 콘웨이의 법칙이라고 부릅니다. 팀 넷이 나눠 만들면 시스템도 네 덩어리로 갈라집니다.

기술별 팀은 시스템을 화면, 서버, 데이터베이스라는 층으로 가릅니다. 스트림 정렬 팀은 시스템을 주문, 검색, 회원이라는 줄기로 가릅니다. 줄기로 갈라진 시스템에서는 주문 팀이 주문 코드만 고쳐 혼자 배포할 수 있습니다.

원하는 시스템 구조를 먼저 정하고 거기에 맞춰 팀을 짜는 방법도 있습니다. 이것을 역 콘웨이 전략이라고 부릅니다. 스트림 정렬 팀은 이 전략을 쓸 때 가장 흔히 고르는 팀 모양입니다.

팀 경계에 맞춰 시스템을 자르는 생각은 서비스를 기능마다 잘게 나누는 마이크로서비스와 잘 맞습니다. 서비스 하나를 한 팀이 맡으면 그 팀은 다른 팀을 기다리지 않고 배포할 수 있습니다. 이렇게 서비스마다 따로 내보내는 것이 독립 배포입니다.

앱과 웹처럼 화면 종류마다 전용 서버를 두는 구성도 있습니다. 이것을 BFF(Backend for Frontend, 프론트엔드를 위한 백엔드)라고 부릅니다. 그 서버는 그 화면을 만드는 팀이 맡습니다. BFF 도 팀 경계에 맞춰 서버를 자르는 생각에서 나왔습니다.

치르는 값

팀 하나가 알아야 할 것이 늘어납니다. 화면과 서버와 데이터와 운영을 한 팀이 다 다뤄야 합니다. 받쳐 주는 플랫폼이 약하면 팀이 기반을 손보느라 정작 기능을 못 만듭니다.

전문가가 여러 팀에 흩어집니다. 데이터베이스를 깊이 아는 사람이 둘뿐인데 스트림 정렬 팀이 다섯이면 모든 팀에 한 명씩 둘 수 없습니다. 같은 기술을 쓰는 사람끼리 배우던 기회도 줄어듭니다.

같은 문제를 여러 팀이 따로 풉니다. 주문 팀과 회원 팀이 각자 로그 남기는 방식을 만들면 비슷한 코드가 두 벌 생깁니다. 이 중복이 쌓이면 그것을 걷어 플랫폼으로 올리는 일이 따로 듭니다.

어느 줄기에도 딱 속하지 않는 부분은 주인이 흐려집니다. 주문과 회원이 같이 쓰는 「주소」 데이터를 누가 맡는지 정해 두지 않으면 아무도 안 고칩니다.

팀을 다시 짜는 일 자체도 사람과 일정이 드는 큰 변화입니다. 맡던 코드와 온콜 당번이 다른 팀으로 옮겨 갑니다. 새 팀이 그 영역을 익히는 동안은 일이 오히려 느려집니다.

쓰지 않을 때

개발자가 대여섯뿐인 조직은 이미 팀 하나가 전부를 맡고 있습니다. 이때는 줄기를 따로 자를 것도 없습니다. 이름만 붙인다고 달라지는 것이 없습니다.

전문 지식이 아주 깊게 드는 부분은 스트림 정렬 팀에 섞지 않습니다. 영상 압축이나 추천 모델처럼 소수만 다룰 수 있는 영역은 복잡한 하위 시스템 팀이 따로 맡습니다. 스트림 정렬 팀은 그 결과를 가져다 씁니다.

코드가 한 덩어리로 얽혀 있으면 팀만 나눠서는 소용이 없습니다. 주문 코드를 고쳤는데 회원 기능이 깨지는 식으로 코드 사이에 경계가 없기 때문입니다. 이럴 때는 코드의 경계를 먼저 가르거나 팀과 코드 경계를 함께 옮겨 갑니다.

얽힌 코드와 모놀리스는 같은 말이 아닙니다. 모놀리스는 한 번에 빌드하고 배포하는 단일 덩어리를 가리킵니다. 안에서 경계를 잘 갈라 두면 팀끼리 서로의 코드를 덜 건드립니다. 그래도 배포는 여전히 한 번에 같이 나갑니다.

그래서 주문 팀이 혼자 배포하려면 주문 부분을 따로 배포되는 서비스로 떼어 내야 합니다. 경계를 먼저 갈라 두면 이렇게 떼어 내기가 쉬워집니다.

관련 항목

스트림 정렬 팀이 속하는 팀 구성 방법론

팀 토폴로지 · 콘웨이의 법칙 · 역 콘웨이 전략 · 팀 경계 · 조직 설계 · 팀 상호작용 모드

스트림 정렬 팀을 받치는 다른 팀 유형

플랫폼 팀 · 활성화 팀 · 복잡한 하위 시스템 팀 · 플랫폼 엔지니어링 · 내부 개발자 플랫폼 · 셀프서비스

팀 사이를 잇는 상호작용 방식

협업 모드 · 서비스 제공 모드 · 촉진 모드 · 제품으로서의 플랫폼

스트림 정렬 팀과 겨루는 팀 구성

기능 팀 · 컴포넌트 팀 · 교차 기능 팀 · 제품 팀 · 프로젝트 팀 · 조직 사일로

스트림 정렬 팀이 맡는 일의 단위

가치 흐름 · 사용자 여정 · 비즈니스 역량 · 도메인 주도 설계 · 경계 컨텍스트 · 페르소나

스트림 정렬 팀이 기대는 엔지니어링 관행

데브옵스 · 마이크로서비스 · 독립 배포 · BFF · 지속적 배포 · 온콜

스트림 정렬 팀의 흐름을 재는 지표

인지 부하 · 배포 빈도 · 변경 리드 타임 · 변경 실패율 · 서비스 복구 시간 · DORA

스트림 정렬 팀에서 자주 나는 문제

인계 · 대기 시간 · 팀 간 의존성 · 모놀리스 · 분산 모놀리스 · 코드 중복