교차 기능 팀

예전에는 회사를 직군별로 갈랐습니다. 기획팀, 디자인팀, 개발팀, 품질팀이 각각 있었고 사람은 자기 직군 팀에 소속됐습니다. 같은 일을 하는 사람끼리 모여 있으니 서로 배우기 좋고, 팀장이 그 직군의 전문가라 평가도 공정해 보였습니다.

문제는 일이 직군을 따라 흐르지 않는다는 데 있었습니다. 검색 결과에 필터를 하나 붙이는 작업 하나가 기획팀에서 시작해 디자인팀으로 넘어가고 개발팀을 거쳐 품질팀에서 끝났습니다. 팀을 넘을 때마다 일은 서류가 되어 건너갔고, 받는 쪽은 자기 팀의 대기 줄 맨 뒤에 그것을 세웠습니다.

그래서 일정 회의는 늘 이렇게 흘러갔습니다. "디자인은 다음 주에 나오고요, 개발은 그다음 달 주기에 잡혀 있어요." 실제로 손을 댄 시간은 열흘인데 달력으로는 두 달이 지나 있었습니다. 남은 시간은 전부 기다림이었고, 기다리는 동안 처음 정한 요구사항은 낡아 갔습니다.

스프린트를 2주로 잡고 그 안에 쓸 수 있는 것을 내보내기로 한 팀은 이 구조에서 한 발짝도 움직일 수 없었습니다. 2주 안에 세 팀의 일정이 맞아떨어질 확률이 없기 때문입니다. 교차 기능 팀은 그 대기 줄을 없애려고 팀의 경계를 직군이 아니라 목표에 맞춰 다시 그은 결과입니다.

하나를 내보내는 데 필요한 사람을 처음부터 같은 팀에 넣고, 일이 팀 밖으로 나갔다 돌아오는 구간을 없앱니다. 팀 안에서 시작하고 팀 안에서 끝나는 상태를 만드는 것이 전부입니다.

구성은 맡은 영역에 따라 달라지지만 대체로 이렇게 짭니다.

1. 프로덕트 매니저 한 명 — 무엇을 왜 만들지 정하고 순서를 세웁니다.
2. 프로덕트 디자이너 한 명 — 문제를 화면으로 옮깁니다.
3. 개발자 서너 명 — 화면과 서버를 함께 맡습니다. 한쪽이 없으면 결국 다른 팀을 기다리게 됩니다.
4. 품질 보증 담당 한 명 — 내보내기 전 점검을 팀 안에서 끝냅니다. 전담 인원 대신 팀이 나눠 맡기도 합니다.

소속을 옮기는 것이 핵심이라 자리만 붙여 앉히는 것과 다릅니다. 디자이너가 디자인팀 소속인 채 이 팀의 일을 도와주는 형태면, 두 곳의 우선순위가 부딪칠 때 디자이너는 원래 소속의 순서를 따릅니다. 그 순간 대기 줄이 되살아납니다.

인원은 보통 다섯에서 아홉 사이로 잡습니다. 더 줄이면 빠진 직군이 생기고, 더 늘리면 팀 안에서 다시 소통 비용이 붙어 나눈 의미가 사라집니다.

이 구조가 제대로 섰는지는 한 가지로 확인합니다. 팀이 맡은 영역 안의 작업을 골라 처음부터 끝까지 따라가 보고, 중간에 다른 팀의 승인이나 일정을 기다리는 구간이 몇 번 나오는지 셉니다. 영 번이면 교차 기능 팀이고, 한 번이라도 나오면 그 지점이 이 팀의 속도를 정하는 병목입니다.

짧은 주기로 반복해서 내보내려는 조직이면 어디든 전제로 깔립니다. 반복적 개발처럼 같은 화면을 여러 번 돌며 고쳐 나가는 방식은 한 주기 안에 기획과 디자인과 구현이 다 들어와야 성립하기 때문입니다.

조직도를 다시 그리는 자리에서 가장 자주 나옵니다. 직군별 팀을 목표별 팀으로 바꾸는 개편이 여기에 해당하고, 스쿼드라는 이름으로 부르는 회사도 많습니다. 개편 문서에는 "검색 스쿼드에 디자이너 한 명을 전배" 같은 문장으로 나타납니다.

나눌 기준은 대체로 사용자가 겪는 흐름입니다. 검색, 문서 편집, 결제처럼 사용자가 하나의 일로 느끼는 덩어리마다 팀을 하나씩 둡니다. 화면 담당과 서버 담당으로 가르면 기능 하나마다 두 팀이 붙어야 해서 대기 줄이 되살아납니다.

채용 공고에도 흔적이 남습니다. "교차 기능 팀에서 일하게 됩니다" 라는 줄은 기획과 디자인이 정해 준 것을 받아 구현만 하는 자리가 아니라는 뜻입니다. 무엇을 만들지 정하는 대화에 처음부터 들어간다는 신호로 읽힙니다.

"이건 교차 기능 팀 안에서 끝낼 수 있는 일인가요, 아니면 다른 팀에 요청해야 하나요?"

팀 밖으로 나가는 순간 일정이 몇 주 밀리니 그 여부부터 확인하자는 말입니다.

"지금 구조는 이름만 교차 기능 팀이에요. 디자이너가 세 팀을 겸하고 있잖아요."

한 사람이 여러 팀에 걸쳐 있으면 대기 줄이 그대로 남아 있다는 지적입니다.

"결제 쪽을 교차 기능 팀으로 묶으려면 서버 개발자가 한 명 더 필요합니다."

팀 안에서 끝내려면 빠진 직군을 채워야 한다는 요청입니다.

페이지덱은 시리즈 A를 받은 뒤 직군별 팀을 목표별 팀으로 바꿨습니다. 지현과 민서와 태오가 한 팀이 되어 문서 편집 화면을 맡았고, 예전 같으면 디자인 요청서를 써서 넘겼을 일을 지현이 민서에게 바로 물어봅니다. 화면을 고치기로 한 날 오후에 태오가 "이 구조면 저장이 느려집니다" 라고 말해 안이 바뀌는 일도 같은 자리에서 일어납니다.

대신 팀 밖의 일은 여전히 느립니다. 결제 서버는 다른 팀이 맡고 있어서, 결제와 얽힌 작업이 들어오면 지현은 그 팀의 일정을 기다립니다. 어디까지를 한 팀에 넣을지가 이 구조의 유일한 설계 선택입니다.

여러 직군이 한 회의에 들어오면 교차 기능 팀이라고 생각하는 경우가 많습니다. 회의실 풍경이 똑같아 보이니 그럴 만합니다. 하지만 기준은 회의가 아니라 소속과 우선순위입니다. 디자이너가 디자인팀에 남아 있고 그 팀의 순서를 따른다면, 회의에 매일 들어와도 급한 일이 겹치는 날 그 사람은 다른 팀 일을 먼저 합니다. 그런 팀은 개편 6개월 뒤에 "이름만 바뀌었고 기다리는 건 똑같다" 는 말이 나옵니다.

한 사람이 여러 직군을 다 해야 한다는 오해도 흔합니다. 교차 기능이라는 말이 개인의 능력을 가리키는 것처럼 들리기 때문입니다. 실제로는 팀의 구성에 붙는 말입니다. 디자이너는 디자인을 하고 개발자는 개발을 하되, 그 둘이 같은 팀에 있는 상태를 뜻합니다. 개인에게 전부를 요구하면 사람은 넓고 얕게 일하게 되고 결과물의 수준이 함께 내려갑니다.