장애를 바라보는 프로덕트 매니저 회고글
나는 현재 '주문'과 '결제' 파트를 맡고 있다. 내가 맡은 기능이 정상적으로 작동하지 않을 때, 즉 장애가 발생하면 이는 곧 비즈니스 전체의 심각한 리스크로 이어진다. 장애는 유저에게 직접적인 불편을 주며, 제품 조직뿐만 아니라 모든 구성원이 빠른 대응을 요구받게 된다.
기업 유형에 따른 특이성도 존재한다. 지금 근무하는 회사는 B2B2C 구조이며 유저는 기업 사용자와 최종 사용자로 이어지는 이중 구조다. 이로 인해 장애는 단순한 기술적 문제를 넘어, 여러 층위의 복잡한 커뮤니케이션과 운영 이슈로 확장된다.
이 글을 쓰는 이유는 명확하다. 장애는 반복적으로 발생하고 있고, 이를 쉽게 해결할 수 있는 구조가 아니기 때문이다. 그리고 이 상황을 당장 해소할 ‘명쾌한 해답’이 존재하지 않는다는 점이 더 큰 현실이다.
가파르게 성장한 기업의 내부 구조가 안정성을 갖기 어렵고, 기업은 레거시 구조를 개선하는 제품 조직 내의 과제를 우선순위를 높게 평가하기 어렵다. 제품 내부의 변화를 시도하는 어떤 작은 프로젝트라도 이런 불안정성은 내포되어 있을 수 밖에 없다. 합의된 배포 절차나 코드 리뷰같은 개발 문화는 개인의 역량에 대체되는 일 또한 잦다.
아마도 많은 기업들이 이와 비슷한 어려움을 겪고 있을 것이다. 특히 ‘스타트업’, ‘O2O’, ‘자영업자 대상 서비스’라는 키워드를 갖는 제품 조직이라면 더더욱. 하지만 내가 진짜 이야기하고 싶은 건, 장애와 같은 문제 상황이 아니라 그 문제 상황을 바라보는 전체 조직의 태도, 즉 ‘삐걱거림’에 대한 우리의 관점이다.
우리가 겪는 많은 장애를 단순한 시스템 오류가 아니라, 하나의 '작은 실패' 혹은 '어려움'으로 바라보면 어떨까.
나는 한때 초기 신사업의 서비스 기획자로 여러 프로젝트에 참여했다. 하지만 솔직히 말하자면, 내가 담당했던 신사업의 대부분은 끝이 좋지 않았다. 당시에는 기업의 미래 먹거리로 주목받으며 전사의 집중을 받았지만, 지금은 내 이력서나 오래된 보도자료 속에서만 그 흔적을 찾아볼 수 있다. 그럼에도 불구하고, 제품 조직은 물론 회사 전체적으로도 그 실패에 대해 누군가에게 책임을 묻거나 추궁하는 일은 없었다.
물론, 기업이 성장의 모멘텀이 절실했던 시기였기 때문에 새로운 시도를 멈출 수는 없었다. 반복되는 실패와 방향 전환에 지친 동료들은 하나둘씩 회사를 떠났다.
그럼에도 회사는 스타트업에서 상장 기업으로 성공했다. 그리고 내가 맡은 프로젝트는 아니었지만 회사에서 신사업으로 출시했던 서비스는 유의미한 성공을 평가받아 지금은 별도 법인으로 독립하기도 했다.
나는 그 회사에서 7년 동안 여러 차례의 신사업과 비즈니스 제품을 맡아 일할 수 있었다. 나 역시 내가 역할에 구애받지 않고 가장 깊이 사업과 제품을 바라보고 일할 수 있었다. 돌이켜 보면, 실패나 문제 상황을 받아들이는 문화가 있었기에 가능했던 일이다. 만약 그런 문화가 없었다면, 입사 1년차에 신사업을 종료하고 반복된 서비스 종료 공지를 올려야 했던 내가 과연 그곳에서 7년을 일할 수 있었을까?
장애도 본질적으로 크게 다르지 않다. 장애가 발생했다는 것은 의도와 다르게 일이 흘러갔다는 뜻이다. 그 안에는 반드시 우리가 개선해야 할 문제들이 숨어 있다. 문제 상황을 해소한다면 장애의 빈도는 줄어들 것이고, 우리는 더 큰 비즈니스를 다루는 문제에 집중할 수 있을 것이다.
그래서 장애를 겪은 뒤 우리가 반드시 해야 할 일은, ‘다음엔 반복하지 않으려면 무엇을 해야 할까’를 묻는 분석과 회고다. 기술적인 원인을 밝히고, 수치를 통해 문제 상황을 실체화해 다루는 과정이 필요하다.
그렇지 않으면 장애는 반복되고, 제품의 변화와 시도는 점점 줄어든다. 배포는 불안을 동반한 일이 되고, 팀은 점점 새로운 시도를 두려워하게 된다. 결국 모두가 ‘성장’을 말하지만, 그 누구도 앞으로 나아가지 못하는 상황에 머물게 될 것이다.