스펙, 일정, 그리고 제품 퀄리티 사이에서
요즘 저희 팀은 다소 무거운 공기를 안고 일하고 있습니다.
각자의 자리에서 최선을 다하고 있음에도 불구하고, 스펙, 일정, 제품 퀄리티라는 세 요소 사이에서 균형을 잡는 일이 좀처럼 쉽지 않습니다.
기획자는 반복되는 수정에 지쳐가고,
디자이너는 구현된 결과물과의 괴리에서 좌절감을 느끼며,
개발자는 병렬적으로 쌓이는 업무에 압박을 받고 있습니다.
결국 세 역할 모두가 피로감을 느끼고 있으며, 그 누구도 이 상황에서 자유롭지 않습니다.
돌이켜보면, 모두가 각자의 자리에서 최선을 다했지만 전체적인 구조와 흐름 속에서 몇 가지 중요한 점들이 놓쳐졌던 것 같습니다.
기획 단계에서 과도한 스펙이 포함되었습니다.
저희 기획팀에서는 '최소 기능'이라는 기준 없이 다양한 기능들을 포함한 PRD를 작성했습니다.
“있으면 좋지 않을까”라는 판단들이 누적되면서, 결과적으로 MVP라고 보기 어려운 범위까지 확장되었습니다.
출시 일정이 기능 범위에 비해 너무 촉박했습니다.
외부와의 계약이나 영업 활동이 먼저 진행되었고, 이에 맞춰 일정이 고정된 상태로 개발팀에 전달되었습니다.
내부에서 충분한 기술 검토나 일정 조율이 이루어지기 어려운 구조였습니다.
개발팀의 기술 검토가 충분히 이뤄지지 않았습니다.
PRD는 사전에 공유되었으나, 회의에서 검토보다는 전달 위주로 진행되었습니다.
이후 기술 리스크나 예외 케이스가 개발 중 발견되었고, 이를 보완하는 과정에서 스펙이 더욱 늘어나게 되었습니다.
개발 일정과 QA가 병렬적으로 겹치며 부담이 가중됐습니다.
테스트 결과 수많은 오류와 디자인 불일치가 발견되었고, QA 티켓은 200건을 넘기기 시작했습니다.
QA와 신규 기능 개발이 동시에 진행되면서 개발팀의 업무 부담이 급격히 커졌습니다.
이러한 흐름은 누구의 잘못이라기보다는, 절차와 문화의 부재에서 비롯된 것이 아닐까 조심스럽게 생각해 보게 됩니다.
제가 이전에 일하던 조직에서는 MVP와 애자일 프로세스를 기반으로 한 운영 방식이 어느 정도 자리잡고 있었습니다.
모든 것이 완벽하진 않았지만, 반복적인 개선과 회고가 가능했기 때문에 팀 전체가 좀 더 유연하고 안정적으로 일할 수 있었습니다.
MVP(Minimum Viable Product)는 말 그대로 ‘고객에게 가치를 전달할 수 있는 최소한의 제품’을 의미합니다. 먼저 단순한 버전을 빠르게 만들어보고, 피드백을 통해 점차 확장하는 방식입니다.
애자일(Agile)은 짧은 주기로 계획, 개발, 검토, 회고를 반복하며 개선을 추구하는 방법론입니다.
한 번에 모든 것을 완성하려 하지 않고, 작게 나눠서 확인하고 조정하는 문화를 전제로 합니다.
지금 저희 팀에도 이런 개념과 방식이 필요하지 않을까 조심스럽게 제안드렸습니다.
사실 이 이야기를 팀에 공유하면서, 저는 이전 회사에서 참고했던 애자일 관련 서적들을 소개해드리고, 같이 공부해보자고 제안드린 적이 있습니다.
그때 모두들 공감은 해주셨지만, 현실은 바빴고, 그 어떤 책도 실제로 읽히지 않았습니다.
프로세스를 바꾸고자 하는 시도는 중요하지만, 그 전에 회고할 여유조차 없는 현실을 먼저 직시하게 되었습니다.
지금의 상태는 단순히 힘든 것을 넘어서 팀 전체의 사기와 효율에 직접적인 영향을 주고 있다고 생각합니다.
피로감이 누적되고 있고, 반복적인 병목이 발생하고 있으며, 무엇보다 '일을 잘 해내고 있다'는 자신감을 갖기 어려운 상태입니다. 그래서 저는 지금이라도 작은 개선부터 시작해야 한다고 믿습니다. 변화를 위한 완벽한 조건은 오지 않기 때문에, 불완전한 상황 속에서도 의미 있는 움직임이 필요합니다.
PRD 리뷰 방식 개선
PRD는 회의 전에 반드시 공유하고, 개발팀은 주요 리스크나 의문점을 정리한 상태에서 참여하는 구조로 바꿔야 합니다. 단순한 전달이 아니라, 함께 논의하며 다듬어가는 시간이 되었으면 합니다.
MVP 기준을 내부에서 명확히 정의
반드시 필요한 기능이 무엇인지 팀 내에서 일관된 기준을 세우고, 이에 따라 스펙을 선별해야 합니다.
정기적인 회고 시간 확보
2주에 한 번, 단 1시간이라도 돌아보는 시간을 확보한다면 팀 전체의 맥락을 회복하는 데 큰 도움이 될 것입니다.
외부 일정과 내부 계획의 조율 원칙 마련
물론 사업을 진행하다 보면 외부 일정이 먼저 정해지고, 내부 팀이 그에 맞춰 대응해야 하는 상황은 불가피하게 발생합니다. 이런 압박이 오히려 작업 속도를 높이는 요인으로 작용하기도 합니다. 다만, 이러한 구조 속에서도 사업부는 개발 현황을 충분히 이해하고, 개발팀은 사업적 기회를 공감하며 함께 방향을 맞춰나간다면, 단순한 속도보다 더 중요한 성과와 지속가능성을 만들어낼 수 있을 것입니다.
따라서 외부 일정이 선제적으로 확정되기보다는, 내부에서 일정과 스펙을 먼저 정리한 뒤 외부에 일정을 제시할 수 있는 프로세스를 마련하고, 그 과정에서 상호 이해와 협업의 문화가 자리잡는 것이 바람직하다고 생각합니다.
이 글은 누군가를 비판하거나 특정 부서를 지적하기 위한 것이 아닙니다. 오히려 지금 저희 팀이 안고 있는 어려움을 조금 더 정직하게 마주해보고, 앞으로 더 나아질 수 있는 방법을 함께 고민해보고자 하는 마음으로 작성하였습니다.
완벽한 팀은 없지만, 조금씩 나아지는 팀은 분명히 존재한다고 믿습니다. 지금의 작은 시도가 앞으로 우리 팀의 더 나은 일상을 만드는 데 도움이 되기를 바랍니다.