개발팀
Development Team
역할
한 주기에 쓸 수 있는 결과물을 실제로 만들어 내는 구성원 전체를 묶어 부르는 이름입니다.
등장 배경
일을 직군별로 나눠 두던 시절에는 하나의 기능이 여러 팀을 거쳤습니다. 기획이 문서를 쓰면 디자인이 화면을 그리고, 개발이 그것을 코드로 옮기고, 품질 담당이 마지막에 확인했습니다. 각 팀은 자기 구간을 끝내고 다음 팀으로 넘겼습니다.
문제는 넘기는 자리마다 생겼습니다. 화면을 만들다 보면 문서에 없던 경우가 튀어나오는데, 그때 문서를 쓴 사람은 이미 다른 일로 옮겨 가 있었습니다. 코드를 짜다 막혀도 마찬가지였습니다. 기능이 늦어져 회의를 열면 "우리 쪽은 제때 넘겼는데요" 라는 말이 돌아가며 나왔고, 실제로 각자는 자기 구간을 지킨 게 맞았습니다. 아무도 기능 전체를 책임지지 않는 구조였을 뿐입니다.
개발팀이라는 말은 그 경계를 지우려고 다시 그은 선입니다. 직군으로 묶지 않고 하나의 결과물을 내놓는 데 필요한 사람 전부를 한 팀으로 부릅니다. 그래서 이 말에는 개발자만 들어가지 않습니다. 화면을 그리는 사람, 품질을 확인하는 사람까지 같은 팀이고, 주기가 끝났을 때 쓸 수 있는 것이 나왔는지는 그 팀 전체의 결과로 봅니다. 이름에 개발이 들어가 자주 오해를 사는 부분이라, 요즘 문서들은 만드는 사람들이라는 뜻의 다른 이름을 쓰기도 합니다.
하루 업무
하루는 데일리 스크럼 15분으로 열고, 나머지 시간은 스프린트 백로그에 뽑아 둔 항목을 하나씩 끝내는 데 씁니다. 스프린트 백로그는 이번 주기에 하기로 정해 둔 작업 묶음이고, 여기 없는 일이 중간에 끼어들지 않는 것이 원칙입니다.
- 아침 15분. 어제 무엇을 끝냈고 오늘 무엇을 할지, 막힌 것이 있는지를 나눕니다. 보고하는 자리가 아니라 서로 하루를 맞추는 자리입니다. 막힌 것이 나오면 그 자리에서 풀지 않고 누가 언제 따로 볼지만 정하고 넘어갑니다. 15분을 지키는 이유가 여기 있습니다.
- 항목 하나를 잡아 완료 정의까지 끌고 갑니다. 완료 정의는 무엇을 끝난 것으로 볼지 팀이 미리 적어 둔 기준입니다. 보통 코드 리뷰를 통과하고 테스트가 돌고 운영 환경에 올라간 상태까지를 말합니다. 여기에 닿지 못한 작업은 90퍼센트를 해 뒀어도 이번 주기에는 없는 것으로 칩니다.
- 동료의 작업을 봐 줍니다. 자기 작업만 붙들고 있으면 검토를 기다리는 항목이 주기 끝에 몰립니다. 오전에 30분쯤을 남의 것 보는 데 쓰는 팀이 많습니다.
- 막힌 것을 그날 안에 드러냅니다. 다른 팀의 답을 기다리거나 권한이 없어 멈춘 일은 혼자 끌고 있어도 풀리지 않습니다. 이런 것을 걷어 내는 일은 팀이 아니라 규칙을 돌보는 사람의 몫입니다.
- 주기 마지막 날에는 만든 것을 스프린트 리뷰에서 돌려 보이고, 이어지는 회고에서 일하는 방식 중 고칠 것을 한두 개 정합니다.
인원은 대여섯에서 아홉 명 정도를 권합니다. 더 적으면 필요한 기술이 팀 안에 다 모이지 않아 밖에 부탁하는 일이 늘고, 더 많으면 아침 15분 안에 모두가 말할 수 없습니다. 열두 명이 되면 대개 둘로 나눕니다.
함께 일하는 사람
바깥에 맞닿는 자리가 둘 있습니다. 무엇을 먼저 만들지 정하는 사람과, 팀이 규칙대로 돌도록 돌보는 사람입니다.
프로덕트 오너는 백로그의 순서를 최종적으로 정합니다. 무엇을 먼저 할지는 이쪽이 정하고, 그것을 어떻게 만들지와 얼마나 담을 수 있는지는 팀이 정합니다. 이 선이 흐려지면 두 방향으로 고장 납니다. 순서까지 팀이 정하면 기술적으로 편한 것부터 만들게 되고, 방법까지 오너가 정하면 팀은 받아 적는 조직이 됩니다.
스크럼 마스터는 관리자가 아니라 막힌 것을 걷어 내는 자리입니다. 다른 팀의 답이 늦거나 권한이 없어 멈춘 일을 대신 뚫고, 주기 중간에 밖에서 일이 끼어들면 막아 줍니다.
주기 끝에는 만든 것을 보러 오는 사람들을 만납니다. 페이지덱에서는 고객에게 약속한 것이 나왔는지 보려는 세일즈 수아와, 분기 목표에 닿고 있는지 보려는 대표 규원이 리뷰에 들어옵니다. 이 자리에서 나온 의견은 지금 주기를 흔들지 않고 다음 주기의 목록으로 들어갑니다.
실무 용례
"그건 개발팀이 정할 일이에요. 순서는 우리가 정하고요."
무엇을 먼저 할지와 어떻게 만들지의 경계를 다시 긋는 말입니다.
"개발팀에 디자이너가 없어서 화면 확인이 매번 밖에 걸려요."
한 팀 안에 필요한 직군이 다 모이지 않아 기다리는 시간이 생긴다는 뜻입니다.
"이번 주기 개발팀 상황 보면 40은 무리예요."
팀이 실제로 소화해 온 양보다 계획이 많다는 판단입니다.
페이지덱이 서른 명이던 시절에는 개발자 여섯 명이 한 팀이었고 디자인과 품질 확인은 밖에 있었습니다. 화면을 만들다 정해지지 않은 경우가 나올 때마다 민서에게 요청을 남기고 이틀씩 기다렸습니다. 한 주기에 그런 대기가 네댓 번 쌓이면 마지막 이틀은 늘 밀린 것을 몰아 끝내는 데 썼습니다.
태오가 회고에서 이 대기 시간을 세어 왔습니다. 두 주기 동안 사흘 반이 기다림이었습니다. 그래서 민서가 팀 안으로 들어왔고, 품질 확인도 같은 팀이 맡았습니다. 아침 15분에 여섯 명 대신 여덟 명이 서게 됐지만, 화면 하나가 애매할 때 이틀이 아니라 그 자리에서 정해졌습니다.
흔한 오해
이름 때문에 개발자만 가리킨다고 읽는 경우가 가장 많습니다. 실제로 많은 회사에서 개발팀은 개발자들이 모인 조직의 이름이라 더 그렇습니다. 하지만 스크럼에서 이 말은 결과물을 내놓는 데 필요한 사람 전체를 뜻합니다. 디자이너도 품질 담당도 같은 팀입니다. 개발자만 이 팀에 넣으면 방금 지운 넘기는 구조가 그대로 돌아옵니다. 화면 하나를 확인받으려고 다시 밖에 요청을 남기고 이틀을 기다리게 됩니다.
시키는 것을 받아 만드는 조직이라는 오해도 흔합니다. 순서를 정하는 사람이 따로 있으니 그렇게 보입니다. 하지만 정해지는 것은 무엇을 먼저 할지까지이고, 어떻게 만들지와 이번에 얼마나 담을지는 팀이 정합니다. 담는 양까지 밖에서 정해 주면 팀은 못 하겠다고 말할 근거를 잃고, 그 상태로 두세 주기가 지나면 끝내지 못한 일이 매번 다음으로 넘어가는 것이 정상처럼 굳습니다.
같이 보면 좋은 페이지
마지막 업데이트 2026-09-16