[리더십] 팀 자율 의사결정 기반의 개발 조직 체계 구축

서론

당시 회사의 업무 구조에서는 오퍼레이션팀이 엔지니어팀에 직접 기능 개발을 요청하거나 PM의 요청이 별도의 기획 리뷰 없이 바로 개발로 이어지는 경우가 많았습니다.

이로 인해 어떤 기능이 왜 만들어지는지에 대한 맥락이 공유되지 않았고 제품의 정책이나 방향성과 어긋나는 요구사항도 그대로 제품에 반영되는 문제가 반복되었습니다.

결과적으로 상반된 정책을 가진 기능들이 누적되며 제품의 정체성과 완성도는 점차 훼손되고 있었습니다.

문제는 개인의 판단이 아니라 업무를 결정하고 검증하는 프로세스 자체에 있었습니다.

이러한 한계를 해결하기 위해 회사는 스쿼드 기반 조직으로 전환하며 PM / Product Lead Engineer(이하 PLE) 구조를 도입했고 저는 제품의 방향성과 기술적 실행을 함께 책임지는 PLE 역할을 맡게 되었습니다.

이 글에서는 2025년도에 PLE로서 기존 업무 프로세스를 어떻게 재정의하고 개선했는지 그리고 그 변화가 팀과 제품에 어떤 영향을 주었는지를 공유하고자 합니다.

본론

요청과 의사결정이 분리되지 않은 구조

기존 업무 프로세스의 가장 큰 문제는 업무 요청과 의사결정이 분리되지 않았다는 점이었습니다.

오퍼레이션팀의 요청이 곧바로 개발로 이어졌을 뿐만 아니라 PM의 요청 또한 별도의 기획 리뷰나 제품 관점의 검증 없이 개발이 진행되는 구조였습니다.

이로 인해 해당 기능이 제품의 방향성과 정책에 부합하는지 기존 사용자 경험과 충돌하지는 않는지 검토하는 단계가 존재하지 않았습니다.

이러한 구조에서는 다음과 같은 문제가 발생했습니다.

제품 관점의 의사 결정 부재 PM이 기능 개발을 사전에 검토하지 않다보니 각 요청은 개별적으로 합리적으로 보이나 전체 제품 관점에서는 정체성에 어긋나고 정책이 서로 충돌하는 경우가 종종 발생했습니다.

그 결과 하나의 제품 안에서 서로 다른 사용자 경험이 공존하게 되었고 운영 과정에서 이를 보완하기 위해 데이터를 수정 및 예외 처리 요청이 지속적으로 증가했습니다.

업무 가시성 부족 및 팀 간 단절 어떤 기능이 왜 개발되고 있는지 공유되고 있지 않기 때문에 PM뿐만 아니라 엔지니어 팀 내부에서도 현재 진행 중인 업무의 맥락을 이해하기 어려운 상황이 지속되었습니다.

그 결과 중복 개발, 우선 순위 혼선, 불필요한 커뮤니케이션 비용 증가로 이어지며 팀 전체의 생산성을 점진적으로 저하시켰습니다.

단기 요청 중심 개발 문화 요청을 일정 내에 처리하는 것이 성과로 인식되면서 기능의 확장성, 유지보수, 장기적인 제품 가치에 대한 고민은 자연스럽게 뒤로 밀리게 되었습니다.

그 결과 제품의 복잡도가 증가하여 새로운 기능을 만드는 비용과 유지보수에 필요한 비용이 늘어나는 상태로 변해가고 있었습니다.

책임 주체의 불명확성 기획 리뷰와 명확한 의사결정 과정이 부재하다 보니 어떤 기능이 어떤 판단을 거쳐 만들어졌는지 기록이 남지 않았고 그 결정에 대한 책임 또한 명확하지 않았습니다.

그 결과 문제가 발생했을 때 팀 차원의 개선으로 이어지기보다는 특정 개인에게 책임이 귀속되는 방식으로 대응되는 경우가 반복되었고 이는 조직이 학습하지 못하고 같은 문제가 재발하는 구조적 원인이 되었습니다.

PLE로서 역할 정의

앞서 언급한 문제들은 특정 개인의 역량이나 태도의 문제가 아니라 업무 요청을 판단하고 검증하는 역할이 정의되어 있지 않았던 구조적 한계에서 비롯된 것이었습니다.

저는 이러한 문제를 해결하기 위해 PLE의 역할을 단순히 개발을 리드하는 포지션이 아니라 제품 관점에서 의사결정의 기준을 세우고 이를 실행으로 연결하는 역할로 정의했습니다.

PLE로서 제가 정의한 책임과 역할은 다음과 같습니다.

모든 개발 요청의 검증 지점이 되는 역할오퍼레이션팀이나 PM으로부터 들어오는 모든 기능 요청은 바로 개발로 이어지지 않고 기획 리뷰와 제품 관점 검토를 거쳐 개발 여부와 우선순위를 판단하도록 했습니다.

제품 정책 및 방향성, 정합성
기존 사용자 경혐 충돌 여부
기술적 복잡도와 장기 유지보수 비용

위와 같은 기준으로 판단을 내리는 역할을 맡았습니다.

무엇을 만들지 말지를 결정하는 책임 모든 요청을 수용하는 것이 곧 성과라고 판단하지 않았습니다. 오히려 제품의 방향성과 일관성을 지키는 것이 더 중요한 역할이라고 생각했습니다. 이를 통해 팀은 요청이 왔으니 만든다가 아니라 이 기능이 지금 제품에 필요한가를 먼저 질문하는 방식으로 사고하게 되었습니다.
기획 맥락을 공유하는 역할엔지니어가 단순히 요구사항을 구현하는 역할에 머무르지 않도록 각 기능이 만들어지는 배경, 목적 기대 효과를 명확히 공유했습니다. 이로 인해 엔지니어는 주어진 문제를 해결하는 단계에서 나아가 스스로 문제를 정의할 수 있는 단계로 발전하였습니다. 팀 내부에서는 어떤 의도로 이 방식으로 결정했는지 설명할 수 있는 기준과 공통 언어가 형성되었으며 업무에 대한 이해도와 책임감 또한 자연스럽게 높아졌습니다.
개인의 판단이 아닌 팀의 기준을 만드는 역할특정 개인의 경험이나 직관에 의존하지 않기 위해 의사결정 기준과 리뷰 프로세스를 정리하고 공유했습니다. 기준이 생겼기 때문에 PLE 뿐만 아니라 모든 엔지니어가 공통된 기준으로 판단할 수 있는 환경을 조성했습니다.

업무 프로세스 개선

이에 따라 업무 흐름을 요청 → 리뷰 → 결정 → 공유 → 개발 단계로 재설계하였습니다.

모든 요청은 단일 채널(PM, PLE)로 수집
문제 정의 중심의 기획 리뷰 진행
PM/PLE 공동 의사결정
결정의 맥락을 팀에 공유 후 개발 진행

결과

업무 프로세스 개선 이후 다음과 같은 변화가 있었습니다.

제품 정책과 충돌하는 기능 사전 차단
운영 단계에서 예외 처리 및 데이터 수정 요청 감소
팀 내 업무 가시성과 공통 이해도 향상
요청 처리 속도를 유지하며 의사결정 개선

무엇보다 중요한 변화는 단순 개발에 그치지 않고 이 기능을 왜 만들어야 하는가를 먼저 고민하는 환경이 되었다는 점입니다.

특히 운영 단계에서 발생했던 예외 처리와 데이터 수정 요청이 눈에 띄게 줄어들었고 기능 개발 이후 운영 안정성도 함께 개선되었습니다.

회고

당시에는 문서 없이도 기존 구성원 간의 신뢰를 기반으로 의사결정 구조가 충분히 작동하고 있었습니다.

서로가 어떤 기준으로 판단하는지 암묵적으로 공유하고 있었기 때문에 말로 설명하는 것만으로도 빠른 합의와 실행이 가능했습니다.

그러나 팀이 확장되며 새로운 팀원 두 명이 합류하면서 이러한 방식이 모두에게 동일하게 전달되기는 어렵다는 한계를 느끼게 되었습니다.

기존 구성원에게는 당연한 판단 기준과 결정의 맥락이 신규 구성원에게는 충분히 설명되지 않은 채 결과만 전달되는 상황이 발생했기 때문입니다.

이에 최근에는 문서를 업무를 강제하기 위한 수단이 아니라 의사결정의 판단 근거와 맥락을 공유하기 위한 도구로 재정의하고 있습니다.

이를 통해 개인 간 신뢰에 의존하던 구조를 넘어 새로운 구성원이 합류하더라도 동일한 기준으로 판단하고 논의할 수 있는 확장 가능한 의사결정 구조로 발전시키고자 합니다.

이러한 경험을 통해 저는 리더의 역할에 대해서도 다시 생각하게 되었습니다.

나만의 리더십 원칙

저는 리더의 역할이 사람 위에서 통제하는 것이 아니라 팀이 스스로 판단하고 움직일 수 있는 환경을 만드는 것이라고 생각합니다.

이를 위해 회사가 추구하는 방향을 명확히 이해하고 조직의 목표와 개인의 성장 사이에서 균형을 찾도록 돕는 역할을 중요하게 생각합니다.

또한 리더는 문제를 사람에게 돌리기보다 구조와 기준을 통해 팀이 지속적으로 성장할 수 있는 시스템을 만드는 사람이라고 믿습니다.