03리더 역할 전환Y-BAR 9주 변화 사례
팀원의 주도성을 탓하지 않고, 개발팀 전체가 스스로 판단할 수 있도록 기술 판단의 기준과 권한 범위를 함께 맞추는 과정을 보여줍니다.
현재 역할
중견 B2C 콘텐츠 플랫폼에서 처음 팀을 맡은 9년 차 개발 팀장
기대정렬 상대
함께 일하는 개발팀 전체
고민 상황
이 고민을 겪은 사람
중견 B2C 콘텐츠 플랫폼에서 처음 팀을 맡은 9년 차 개발 팀장
개발자 70여 명이 구독·콘텐츠·회원 등 여러 제품 조직으로 나뉜 중견 B2C 콘텐츠 플랫폼에서 백엔드 개발자로 일하다, 회원 경험을 담당하는 7명 개발팀의 팀장이 됐습니다. 공통 기능과 다른 제품팀에 영향을 주는 결정이 많고, 여전히 설계와 코드 리뷰에서 가장 자주 답을 요청받는 개발자이기도 합니다.
팀원들에게 각자 판단해 개발해달라고 말하지만, 구현이 조금만 애매해도 질문과 리뷰가 몰립니다. 일정이 급하면 핵심 기능을 직접 맡고, 설계가 기대와 다르면 수정 방향을 다시 적습니다. 팀은 점점 팀장의 답을 기다리고 팀장은 개발 실무에서 빠져나오지 못합니다.
구현 방법이 조금만 애매해도 팀 채널에 ‘어느 쪽으로 할까요?’라는 질문이 올라온다.
“이 정도는 담당자가 결정해도 되는데 왜 전부 나를 기다리지?”
코드 리뷰에서 빠진 위험이 보이면 이유를 설명하기보다 직접 수정 방향을 다시 적는다.
“길게 설명하는 것보다 내가 고치는 편이 빠르다.”
출시 일정이 급해지면 팀장이 핵심 기능을 직접 맡고 팀원은 주변 작업만 처리한다.
“이번만 넘기고 다음에는 제대로 역할을 나눠야겠다.”
회고에서 팀원들이 ‘어디까지 스스로 결정해도 되는지 모르겠다’고 말한다.
“각자 판단하라고 했는데 무엇을 더 알려줘야 하지?”
그래서 Y-BAR를 찾았습니다
최근 회고에서 한 팀원이 ‘어차피 리뷰에서 설계가 바뀔 것 같아, 시작 전에 팀장님 답부터 확인하게 된다’고 말했습니다. 팀장은 팀원의 소극성보다 자신의 판단 기준이 뒤늦게 등장하는 방식부터 봐야 한다는 사실을 확인했습니다.
문제 진단
문제 진단이 바뀐 과정
팀원들이 더 주도적으로 생각하고 기술적 책임감을 가지면 내가 확인하지 않아도 개발이 진행될 것이다.
현업 적용
기대정렬 준비
최근 설계가 크게 바뀐 가족 계정 기능을 놓고 각자가 당시 무엇을 기준으로 판단했는지 비교했습니다. 반복해서 필요한 기준만 남기고, 담당자가 결정할 범위와 구현 전에 반드시 함께 볼 조건을 정했습니다.
“팀원의 태도가 아니라, 리더의 머릿속에만 있던 판단 기준이 문제였습니다”
담당자가 직접 결정할 범위
“한 기능 안에서 영향이 끝나고 되돌릴 수 있는 구현 방식”
팀이 함께 리뷰할 조건
“여러 기능이나 데이터 구조·보안·출시 일정에 영향을 주는 선택”
말로만 맡겼던 결정이 팀이 실제로 사용할 수 있는 권한 범위와 리뷰 조건으로 바뀌었습니다.
팀 기준 정렬 회의 · 개발팀 전체
팀장이 뒤늦게 설계를 바꿨던 가족 계정 기능을 회의에 가져왔습니다. 정답을 먼저 설명하지 않고, 당시 담당자가 어떤 정보를 갖고 결정했는지와 팀장이 나중에 무엇을 위험으로 봤는지를 나란히 놓았습니다.
팀이 팀장에게 필요로 한 것
각자 판단하라는 말보다 어떤 결정은 존중되고, 어떤 영향이 생길 때만 함께 리뷰하는지 예측할 수 있는 기준이 필요했습니다.
팀장이 꺼내놓은 실제 장면
팀장이 사후에 설계를 바꿨던 기능을 가져와, 처음부터 공유하지 않았던 재사용 범위와 되돌리기 어려운 변경이라는 판단 기준을 팀 앞에 공개했습니다.
실행 후 변화
막연했던 권한 위임이 담당자가 직접 결정할 범위와 팀이 함께 리뷰할 조건으로 바뀌었습니다.
다음 기능 개발 회고 · 개발팀 전체
다음 콘텐츠 알림 설정 기능에서 담당자는 사용자 영향과 출시 일정을 근거로 구현 방식을 선택했습니다. 다른 기능에 미치는 영향은 없다고 판단해 세부 구현은 직접 결정했고, 기존 사용자 설정 데이터에 영향을 주는 부분만 구현 전에 팀 리뷰에 올렸습니다.
팀이 계속 직접 판단할 수 있는 조건
합의한 범위 안의 기술 선택은 팀장의 첫 생각과 달라도 존중되고, 여러 기능이나 고객에게 영향을 주는 위험만 함께 논의해야 했습니다.
실제 개발에서 달라진 팀장의 행동
담당자가 선택한 세부 구현을 다시 쓰지 않았고, 데이터 구조 변경이 다른 기능에 미칠 영향만 질문해 팀이 결론을 내리도록 했습니다.
실행 뒤 보완한 리뷰 조건
팀장은 구현 방법을 대신 정하지 않고 영향 범위와 되돌릴 수 있는지만 질문합니다. 새로운 위험은 개인 지시로 남기지 않고 다음 회고에서 팀의 공통 리뷰 조건에 반영하기로 했습니다.
실행 후 변화
팀은 ‘어떻게 할까요?’라고 묻는 대신 판단 근거와 추천안을 먼저 공유하기 시작했고, 팀장은 모든 설계의 최종 승인자에서 중요한 위험과 기준을 관리하는 역할로 이동했습니다.
결과 변화
팀의 실제 행동
콘텐츠 알림 설정 기능에서 담당자는 사용자 영향·출시 일정·되돌릴 수 있는지를 근거로 추천안을 냈고, 팀장은 세부 구현을 다시 쓰지 않았습니다.
팀장 역할의 변화
팀원의 선택이 자신의 첫 생각과 달라도 합의한 범위 안이면 다시 가져오지 않았습니다. 구현 답을 대신 주는 대신, 영향 범위와 되돌릴 수 있는지, 팀 전체에 남길 기준이 무엇인지만 확인했습니다.
팀에 남은 운영 방식
팀은 결정 이유를 공통 기준으로 설명하고, 기준이 부족했던 장면만 함께 학습합니다. 기술 판단이 다시 팀장 한 사람에게 몰리는지도 다음 회고에서 계속 확인합니다.
Y-BAR가 결과를 대신 만들어주지는 않습니다. 원하는 변화를 구체적인 책임과 행동으로 바꾸고, 중요한 상대와 기대를 맞춘 뒤 실제 반응으로 다음 행동을 정하는 방법을 훈련합니다.
Y-BAR 과정 자세히 보기다른 변화 경로
승진·평가
이직·직무 전환
사례 구성 안내 · 개인정보 보호를 위해 여러 Y-BAR 사례에서 반복해 나타난 문제 상황과 변화 과정을 하나의 경로로 재구성했습니다.