운영 스쿼드의 성과를 ‘얼마나 많은 일을 처리했는가’로만 볼 수 있을까요? 애슬러 Ops & Risk Lead Kuma(쿠마)는 오히려 해야 할 일을 줄여가는 스쿼드를 만들고 싶다고 합니다.
반복해서 처리하던 일은 어떻게 줄이고, 혼자 하던 판단은 어떻게 동료와 나눌까요? 쿠마가 운영을 만들어온 과정과 앞으로 함께할 동료의 이야기를 들어봤습니다.
먼저 소개 부탁드려요. 애슬러에서 Ops & Risk는 어떤 일을 하나요?
🗣️ 안녕하세요! 🙋 애슬러(ATHLER)에서 Ops & Risk Lead를 맡고 있는 쿠마입니다.
처음 입사 당시에는 CX를 중심으로 BPO(고객센터) 운영과 CX 기획 문제를 해결하는 역할로 시작했는데요. 회사와 서비스가 성장하면서 지금은 고객 경험을 넘어 셀러와 상품 운영, 물류 관리, 정산, 계약과 각종 운영 리스크까지 꽤 넓은 영역을 보고 있습니다.
음, 저는 특정 업무 영역에 한정해서 생각하지 않습니다. “CX를 담당한다”, “물류를 담당한다”로 역할에 한계를 만들기보다는 사업이 성장하는 과정에서 운영적으로 막히는 문제를 찾아내고, 그 문제가 반복되지 않도록 기준과 구조를 만드는 Problem Solver 역할에 가깝다고 생각해요.
예를 들면, 어떤 문제를 어디까지 들여다보는 건가요?
🗣️ 예를 들어 고객에게 같은 문제가 반복되고 있다면 상담원의 숙련도만의 문제는 아닐 수 있습니다. 정책이 잘못 설계되어 있을 수도 있고, 상품 정보가 부족할 수도 있고, 물류나 시스템이 원인일 수도 있어요.
그래서 상담 답변을 더 잘하는 것에서 끝내지 않고, 왜 같은 문의가 계속 발생하는지, 앞단에서 개선할 수 있는 부분은 없는지까지 확인합니다. 라이브 서비스 중 발생하는 불편을 줄이고, 회사가 성장하는 과정에서 같은 문제가 반복되지 않는 운영 구조를 만드는 게 제가 책임지는 결과라고 생각해요.
이야기를 듣다 보니, 어떤 경험을 거쳐 이런 시각을 갖게 됐는지도 궁금해지는데요. 쿠마는 지금의 역할까지 어떤 커리어를 거쳐오셨나요?
🗣️ 처음에는 많은 CX 실무자분들과 비슷하게 고객센터 상담사로 시작했습니다. 이후 더블유컨셉, 아이디어스, 팔도감, 퀸잇 등 이커머스 인하우스 조직으로 옮기며 CX와 운영 영역의 경험을 넓혀왔어요.
돌이켜보면 의도적으로 이커머스만 선택했다기보다는, 어쩌다 보니 계속 이커머스와 유통업 안에서 커리어를 쌓아왔던 것 같습니다. 그만큼 이커머스라는 업이 저한테는 꽤 매력적으로 느껴졌던 것 같고요.
특히 고객의 목소리가 상품, 정책, 물류, 시스템 같은 여러 문제와 바로 연결되어 있다는 점이 흥미로웠습니다. 현장에서 반복되는 문제가 단순히 현장만의 문제로 끝나는 경우는 거의 없다는 것도 이 과정에서 많이 배웠어요.
운영 체계가 잘 갖춰진 조직을 떠나 왜 애슬러에 합류했나요?
🗣️ 직전에는 100명 이상의 구성원이 함께하고, 빠른 성장 속도와 안정적인 운영 체계를 모두 갖춘 커머스 기업에서 일했습니다. 동료분들도 각자의 영역에서 전문성이 높은 분들이었고, 저 역시 5명 이상의 팀에서 역할을 나눠 일하고 있었어요.
업무 환경이나 동료, 조직 자체에 대한 만족도는 높았습니다. 다만 일을 하면서 제 안에 계속 갈증이 남더라고요.
만족하면서도 갈증이 남았다는 건, 어떤 의미인가요?
🗣️ 돌이켜보면 이미 대부분의 정책과 운영 방식이 잘 구축된 환경이었고, 각 구성원이 맡은 영역을 안정적으로 잘 수행하면 되는 구조에 가까웠어요.
그런데 저는 그 안에서 맡은 일을 잘하는 것만으로는 채워지지 않는 아쉬움이 있었던 것 같습니다. 그래서 근본적으로 “왜 나는 지금의 환경에서도 계속 아쉬움을 느낄까?”를 고민해봤어요.
당시의 저에게는 안정적인 환경보다 맨땅에서부터 새롭게 만들어가는 경험, 그리고 스스로 더 넓은 문제를 맡아볼 수 있는 도전적인 환경이 필요하다고 판단했습니다.
마침 그 시기에 애슬러와 좋은 기회가 닿아 합류하게 됐습니다.

막상 합류했을 때는 어떤 상황이었고, 무엇부터 시작했나요?
🗣️ 당시에는 이 업무를 전담하던 사람이 없어서 PO가 고객센터 관리까지 대신하고 있었습니다. 지금처럼 Ops & Risk라는 역할이 명확하게 존재했던 것도 아니었고요.
고객 문의는 들어오는데 기본적인 응대 스크립트부터 CS 흐름, 정책 자체가 없는 경우도 많았습니다. 셀러와 고객 사이에서 어떤 기준으로 판단해야 할지 매번 새롭게 정의해야 하는 상황도 있었어요.
그래서 합류하자마자 고객 문의 대응 방안과 BPO 계약 체결, CS 정책을 정리하는 일부터 시작했습니다. 이후 셀러 커뮤니케이션 방식, 물류사 계약과 운영, 재고 관리, 정산 대응, 계약이나 법무 검토가 필요한 이슈까지 회사에 필요한 운영 영역을 하나씩 넓혀가며 맡았어요.
고객 문의를 해결하다 보면 상품 운영 문제가 보였고, 상품 문제를 따라가다 보면 셀러 운영이 보였습니다. 주문 문제를 보다 보면 물류와 재고로 이어졌고, 정산이나 계약, 법적인 리스크까지 연결되는 경우도 있었어요.
그러니까 결국 제가 하는 일은 특정 기능 하나를 운영하는 것보다, 서비스 운영 과정에 존재하는 공백을 발견하고 그 자리에 필요한 기준과 구조를 만드는 일에 가까워졌습니다. 지금의 Ops & Risk도 그렇게 만들어졌다고 생각해요.
혼자 기준을 만들어가면서 가장 어려웠던 건 무엇이었나요?
🗣️ 일이 많아서 힘든 것도 있었겠지만, 더 어려웠던 건 정답이 없는 상태에서 기준을 만들어야 한다는 거에요.
누군가 “이건 어떻게 처리하면 되나요?”라고 물었을 때 참고할 기존 정책도, 비슷한 이전 사례도 없는 경우가 대부분이었어요. 그럴 때마다 지금 눈앞의 한 건을 해결하는 것과, 앞으로 같은 상황이 수백 번 발생해도 일관되게 처리할 수 있는 기준을 만드는 일을 함께 고민해야 했습니다.
당장 처리할 일도 많은데, 무엇부터 해결할지는 어떻게 정했나요?
🗣️ 우선순위는 비교적 단순하게 잡았습니다.
첫 번째는 서비스나 회사에 즉각적으로 큰 문제가 될 수 있는 리스크인지, 두 번째는 같은 문제가 반복되면서 여러 사람의 시간을 계속 쓰게 만드는지, 세 번째는 지금 해결하지 않으면 회사가 커질수록 더 큰 비용과 비효율로 돌아올 문제인지를 봤어요.
서비스는 빠르게 성장하고 있었지만 운영할 수 있는 인원은 많지 않았습니다. 그래서 당시에는 회사 안에 생기는 운영의 공백을 발견하고, 그 공백이 더 커지기 전에 메우는 데 가장 집중했던 것 같습니다.
쿠마는 리스크와 반복되는 비효율을 살피며 우선순위를 정했다고 이야기했습니다. 유사한 고민을 애슬러의 Product 스쿼드에서는 어떻게 풀고 있을까요? 회사의 목표와 연결된 지표를 기준으로 실행 순서를 정하는 프로덕트 헤드 블레어의 우선순위와 실행 이야기도 함께 읽어보세요.
쿠마가 생각하는 좋은 운영 스쿼드와 바쁜 운영 스쿼드의 차이는 무엇인가요?
🗣️ 저는 좋은 운영 스쿼드는 바쁘지 않기 위해 계속 구조를 바꾸는 스쿼드라고 생각합니다.
물론 운영 조직은 기본적으로 일이 많을 수밖에 없어요. 고객 문의도 들어오고, 셀러 이슈도 생기고, 물류나 정산처럼 매일 챙겨야 하는 일도 있습니다. 그런데 같은 문제가 계속 반복되는데도 매번 사람이 더 빨리 처리하는 방식으로만 해결하고 있다면, 그건 일을 잘하고 있다기보다 바쁨을 유지하고 있는 상태에 가깝다고 생각해요.
운영에서는 사람이 조금만 더 신경 쓰면 해결할 수 있는 문제가 굉장히 많습니다. 그런데 그렇게 해결하면 당장은 편하지만, 회사가 두 배, 세 배 커졌을 때 같은 방식으로 버티기는 어렵거든요.
그래서 문제가 발생하면 담당자에게 “다음부터 조심해 주세요”라고 이야기하기 전에 시스템이나 정책, 체크리스트로 줄일 방법이 없는지를 먼저 봅니다.
반복 문의라면 정책이나 화면을 바꿀 수 있는지 보고, 수작업이 계속 생긴다면 자동화할 수 있는지 보고, 검수가 반복적으로 막힌다면 셀러 가이드나 어드민 구조를 손볼 수 있는지 보는 식이에요.
평소 스쿼드에서도 그런 이야기를 자주 하나요?
🗣️ 제가 요즘 많이 이야기하는 말 중 하나가 있어요.
“이걸 계속 사람이 해야 하나요?”
누군가 반복적인 작업을 하고 있으면 일단 왜 하고 있는지부터 같이 봅니다.
개인적으로는 운영 스쿼드가 일을 많이 처리해서 인정받는 스쿼드가 되는 것보다, 해야 할 일을 계속 줄여가는 스쿼드가 되는 게 더 좋은 운영 스쿼드라고 생각해요.
그렇다면 운영 스쿼드의 성과는 무엇으로 보나요?
🗣️ 단순히 ‘몇 건을 처리했는가’로만 보지 않습니다. 오히려 지난달에 사람이 하던 일을 이번 달에는 안 해도 되게 만들었는가, 같은 문제가 다시 발생할 확률을 얼마나 줄였는가를 더 중요하게 생각해요.
결국 좋은 운영 스쿼드는 일이 없는 스쿼드가 아니라, 회사가 커져도 같은 비효율이 같이 커지지 않도록 만드는 스쿼드라고 생각합니다.

반복 업무를 줄이면서도 리스크는 어떻게 관리하나요?
🗣️ 예전에는 반복 업무를 보면 가능한 한 빨리 자동화하거나 없애야 한다고 생각했던 편입니다. 지금도 그 방향 자체는 크게 달라지지 않았지만, 일을 오래 하다 보니 ‘수작업 = 비효율’은 아니라는 생각을 하게 됐어요.
특히 리스크가 크거나 아직 기준이 충분히 쌓이지 않은 업무는 사람이 직접 보는 과정이 필요하다고 생각합니다.
그럼 예를 들어 어떤 문제를 어디까지 들여다보시는지 궁금해요!
🗣️ 예를 들어 상품 검수나 계약, 정책처럼 예외가 많은 업무는 처음부터 완전히 자동화하려고 하면 오히려 중요한 맥락을 놓칠 수 있습니다. 재고나 정산처럼 숫자로 관리되는 영역도 시스템 값만 믿기보다 일정 주기로 사람이 실제 데이터를 대조하는 과정이 필요한 경우가 있어요.
예전에는 이런 작업을 보면 ‘왜 아직 사람이 하고 있지?’부터 생각했다면, 지금은 먼저 이 수작업이 단순 반복인지, 아니면 리스크를 통제하기 위한 의도적인 장치인지를 구분하려고 합니다.
그래서 지금은 자동화의 목표도 ‘사람을 없애는 것’이라기보다 사람이 판단해야 하는 부분과 기계가 처리해야 하는 부분을 분리하는 것에 더 가깝습니다.
기계가 더 잘하는 반복 계산이나 알림, 데이터 취합은 최대한 자동화하되, 예외를 판단하거나 새로운 기준을 만드는 일에는 사람이 시간을 쓸 수 있게 하는 것이 더 좋은 운영이라고 생각해요.
저는 Ops와 Risk를 별개의 기능이라고 생각하지 않습니다. 운영 과정에서 반복되는 문제를 줄이는 것이 Ops라면, 그 과정에서 어떤 위험을 어디까지 감당하고 통제할지 정하는 것이 Risk에 가깝다고 생각해요.
그런데 리스크를 챙기다 보면 새로운 시도에 신중해질 수밖에 없지 않나요?
🗣️ 리스크를 담당하다 보면 하지 말아야 할 이유를 찾는 건 상대적으로 쉽습니다. 하지만 회사는 성장해야 하고 새로운 시도를 해야 해요.
그래서 저는 “위험하니까 하지 맙시다”보다는 이런 질문을 던지는 Ops & Risk가 되어야 한다고 생각합니다.
“어떤 위험이 있고, 어디까지 통제하면 실행할 수 있는가”
안전하게 아무것도 하지 않는 스쿼드가 아니라, 회사가 더 빠르게 실행할 수 있도록 안전장치를 만드는 스쿼드에 가깝게 움직이자는 원칙이 생긴 것 같아요.
반복 업무를 줄이더라도 사람이 판단해야 할 일은 남습니다. 혼자 세워온 판단 기준을 동료들과 나누는 과정은 어땠을까요?
여기서부터는 쿠마 개인의 일을 넘어, 스쿼드를 만드는 이야기를 들어봤습니다.
혼자 하던 운영이 스쿼드가 되면서 쿠마의 역할은 어떻게 달라졌나요?
🗣️ 처음 합류한 뒤 약 1년 정도는 대부분의 운영 업무를 혼자 진행했습니다. 이후 회사가 성장하면서 운영해야 하는 영역도 빠르게 넓어졌어요. 한 사람이 모든 영역을 직접 맡는 방식으로는 지속하기 어렵다고 판단해 함께할 구성원들을 모시기 시작했고, 지금은 Ops Squad라는 형태로 스쿼드 체계를 만들어가는 단계입니다.
그 과정에서 제 역할도 많이 달라졌어요. 예전에는 제가 직접 문제를 발견하고 처리하는 사람에 가까웠다면, 지금은 이런 역할로 조금씩 이동하고 있습니다.
“어떤 문제를 누가, 어떤 기준으로 해결할지를 설계하는 사람”
직접 하던 일을 동료에게 맡겨보니, 어떤 점이 어려웠나요?
🗣️ 먼저 “내가 아니면 안 되는 일”을 오래 들고 있으려고 하지는 않았어요. 처음부터 제가 없어도 같은 기준으로 운영될 수 있는 구조를 만드는 게 목표였습니다.
그런데 막상 일을 넘기는 건 쉽지만은 않았어요. 🤔 제가 오래 직접 해온 업무일수록 머릿속에만 존재하는 기준이 많았거든요. 너무 익숙해서 당연하게 판단하던 것도 막상 다른 사람에게 설명하려고 보면, 왜 그렇게 판단하는지 문서화되어 있지 않은 경우가 많았습니다.
그 경험을 하면서 업무를 나누는 것만으로는 스쿼드가 완성되지 않는다는 걸 많이 배웠어요.
그래서 요즘은 업무를 맡기는 과정 자체도 하나의 운영 설계라고 생각합니다. 단순히 “이 업무를 해 주세요”라고 전달하는 것이 아니라, 왜 이 업무가 필요한지, 어떤 결과를 만들어야 하는지, 어디까지 스스로 판단할 수 있는지, 어떤 상황에서는 반드시 함께 논의해야 하는지를 같이 정의하려고 해요.
지금은 어떤 일을 직접 맡고 있나요?
🗣️ 새로운 문제를 정의하거나, 하나의 스쿼드만으로 해결하기 어려운 문제에 시간을 쏟고 있어요. 특히 회사 안에 명확한 담당자가 없는 영역을 구조화하고 있어요.
그렇게 기준과 구조가 만들어지면, 동료들이 그 기준을 바탕으로 직접 판단하고 업무를 운영할 수 있도록 역할을 나누고 있습니다. 결국 지금 제 역할은 스쿼드가 더 많은 문제를 스스로 해결할 수 있는 구조를 만드는 것에 가까워지고 있는 것 같습니다.

지금 애슬러 Ops & Risk가 더 집중하려는 문제는 무엇인가요?
🗣️ 지금은 운영 스쿼드 내부의 문제를 넘어, 여러 조직이 함께 풀어야 하는 문제까지 해결 범위를 넓히는데 집중하려고 합니다.
초기에는 고객 문의부터 물류, 재고, 정산까지 운영의 기본 체계를 만드는 것이 우선이었어요. 지금은 그 기본기를 계속 높이는 동시에 한 단계 더 나아가야 합니다.
사업이 성장하면서 발생하는 문제들은 특정 조직 하나만으로 해결하기 어려운 경우가 많아요. 예를 들어 물류 문제도 단순히 물류사의 문제가 아니라 상품 운영, 재고, 판매 전략, 프로덕트까지 연결될 수 있습니다.
그래서 여러 조직 사이에 걸쳐 있는 문제를 발견하고, 데이터를 통해 원인을 정의하고, 실제 해결까지 가져가는 일을 잘해야 한다고 생각해요. 최근 제가 업무 범위를 프로덕트와 비즈니스의 문제 해결까지 넓게 보고 있는 것도 같은 이유입니다.
그럼 업무 범위가 넓어지면서 “이걸 왜 Ops가 해요?”라는 질문도 받아봤나요?
🗣️ 꽤 많았습니다. 그런데 저는 업무가 어느 조직의 담당인지보다 문제가 어디에서 반복적으로 발생하고 있는지를 더 중요하게 봐요.
예를 들어 고객 불편의 원인이 물류에 있으면 CX만 잘해서는 해결되지 않습니다. 셀러가 계속 같은 실수를 한다면 문의 대응보다 온보딩이나 어드민 구조를 바꾸는 게 먼저일 수 있어요. 정산 이슈 역시 돈을 지급하는 업무 하나로 좁혀지지 않고 셀러 신뢰와 계약 구조, 시스템 데이터까지 연결될 수 있거든요.
운영 과정에서 회사가 반복적으로 비용을 내고 있는 문제라면 Ops가 먼저 문제를 구조화할 수 있다고 생각합니다. 여러 조직 사이에 끼어 있어서 아무도 전체를 보고 있지 않은 문제들이 특히 그렇습니다.
문제를 먼저 발견하면 끝까지 Ops가 맡게 되나요?
🗣️ 모든 일을 Ops가 가져와야 한다는 뜻은 아닙니다. 문제를 처음부터 끝까지 우리 스쿼드가 소유하는 것보다, 원인을 정의하고 적절한 스쿼드와 함께 해결한 뒤 명확한 담당자와 구조를 만들어 다시 넘기거나 자동화하는 것이 중요해요.
운영에서 많은 문제를 접한다는 건 회사가 어디에서 막히고 있는지를 빠르게 볼 수 있다는 뜻이기도 합니다. 그 정보를 단순히 처리하는 데 쓰지 않고, 사업을 개선하는 데 활용하는 스쿼드를 만드는 것이 목표입니다.
운영에서 살피는 상품과 재고의 문제는 고객의 신뢰와도 이어집니다. 안정적인 재고와 구매 이후의 경험을 강조한 MD Lead CY의 고객 신뢰 이야기에서는 이 연결을 다른 직무의 시선으로 볼 수 있습니다.
애슬러 Ops & Risk에 새로 합류하면 어떤 일부터 시작하게 되나요?
🗣️ 처음 합류하면 비교적 구체적인 운영 업무에서 시작할 가능성이 높습니다. 상품 검수나 셀러 운영, 고객과 주문 과정에서 발생하는 운영 이슈를 직접 경험하면서 애슬러라는 서비스가 실제로 어떻게 돌아가는지를 이해하게 됩니다.
하지만 저희가 기대하는 역할은 정해진 업무를 빠르게 처리하는 것에서 끝나지는 않아요.
같은 상품 검수 업무에서도 어떤 차이를 기대하나요?
🗣️ 반복적으로 같은 반려 사유가 발생한다면 단순히 계속 반려하는 것이 아니라, “왜 셀러가 같은 실수를 반복할까?”, “입점이나 상품 등록 과정에서 미리 막을 수 없을까?”, “어드민이나 시스템을 바꾸면 해결할 수 없을까?”까지 생각해보는 식입니다.
처음에는 운영 업무에서 시작하더라도 본인이 문제를 잘 발견하고 해결해 나간다면, 맡을 수 있는 범위가 빠르게 넓어질 수 있는 스쿼드라고 생각해요.
실제 업무에서는 어떤 도구를 쓰고, 누구와 협업하나요?
🗣️ Google Sheets나 Notion, Slack 같은 도구를 많이 활용하고, 상품, 셀러, CX, 물류 데이터를 비교해서 보는 일이 많습니다. MD와 Product 등 내부 조직뿐 아니라 외부 파트너나 물류사 등과도 자주 협업하게 돼요.
특히 요즘은 Claude Code와 GPT 등 AI 도구를 활용해 반복적인 업무를 줄이거나 자동화를 만드는 것도 적극적으로 시도하고 있어요 🤖.
이 문제를 어떤 동료와 함께 풀고 싶나요?
🗣️ 경력보다 중요하게 보는 건 문제를 자기 일로 받아들이는 태도입니다.
운영에서는 업무 범위가 아주 명확하게 나뉘지 않는 순간이 많아요. “이건 제 담당이 아닌데요”라고 하면 문제는 그대로 남지만, 누군가는 결국 해결해야 합니다.
아! 그렇다고 모든 일을 혼자 떠안으라는 의미는 아닙니다. 오히려 문제를 발견했을 때 적절한 사람에게 빠르게 도움을 요청하고, 필요한 사람들을 연결해서 결과까지 만들어내는 사람이 저희 스쿼드와 잘 맞아요.
저는 솔직하게 이야기하는 사람도 좋아합니다. 모르는데 아는 척하거나 혼자 오래 고민하는 것보다 “이건 모르겠습니다”, “이 부분은 제 판단과 다릅니다”, “도움이 필요합니다”라고 빨리 이야기하는 편이 훨씬 좋습니다.
반대로 이 스쿼드에서 어려움을 느낄 수 있는 사람도 있을까요?
🗣️ 정해진 프로세스와 업무 범위가 완벽하게 준비된 환경을 선호한다면 조금 힘들 수 있습니다. 저희는 여전히 빠르게 성장하고 있고, 어제 없던 문제가 오늘 생기기도 해요. 기존 프로세스가 최선이 아니라면 직접 바꿔야 하는 경우도 많고요.
그래서 “무엇을 하면 되나요?”보다 “이 문제는 이렇게 바꾸면 더 좋아질 것 같습니다”라고 이야기하는 분이라면 굉장히 재미있게 일할 수 있을 것 같습니다.
마지막으로, 합류를 고민하는 분에게 전하고 싶은 말이 있나요?
🗣️ 아직 만들어지지 않은 것을 직접 만들어보고 싶은 분에게 재미있는 환경이라고 생각합니다.
물론 쉽지는 않아요. 정답이 없는 문제도 많고, 스스로 판단해야 할 순간도 많습니다. 대신 “이건 원래 이렇게 하는 거야”라는 이유만으로 멈출 필요도 없습니다.
문제를 발견하고, 근거를 만들고, 더 좋은 방식이 있다고 생각하면 직접 바꿀 수 있어요. 저도 그렇게 지금의 역할을 만들어왔고, 앞으로 합류할 분 역시 자신의 역할을 정해진 JD 안에만 두지 않았으면 좋겠습니다.
함께 운영을 하는 사람보다는, 함께 회사의 문제를 푸는 동료를 만나고 싶습니다. 🙌
