mentah
Y's Insight#34

막막한 일을 맡았을 때, 제가 쓰는 3가지 방법

영향도2026.09.29

0에서 일을 정의하는 건, 보이지 않던 걸 눈에 보이게 만드는 작업이에요. 저는 이걸 '숫자를 만들어가는 과정'이라고 생각합니다.

일을 하다 보면, 어떤 일을 0에서부터 정의해야 할 때가 있어요. "이걸 대체 어떻게 접근하지" 싶은, 정의 자체가 없는 일들이요. 저는 주로 운영 조직이 있는 곳에서 운영 비용을 줄이거나 리드타임을 줄이는 일을 맡아왔는데요. 이런 일은 대부분 처음엔 막막합니다. 그래서 오늘은, 그 막막함 앞에서 제가 실제로 쓰는 방법 세 가지를 풀어보려고 해요.

15초 요약

  • 0에서 일을 정의하는 건, 막막함을 '측정 가능한 것'으로 바꾸는 작업이에요. 저는 이걸 숫자를 만들어가는 과정이라고 생각해요.

  • 상황에 따라 세 가지를 써요. 현상이 어렴풋할 땐 포스트잇으로 구조를 찾고, 임팩트를 재야 할 땐 아주 작은 케이스를 측정해 확장하고, 아무도 안 정리한 일은 현장에 직접 갑니다.

알아두면 좋은 용어

  • 어피니티 다이어그램 (Affinity Diagram) — 흩어진 현상을 포스트잇에 적어 성질끼리 묶으며 패턴·주제를 찾는 방법. 첫 번째 방법이 딱 이거예요.

  • 겐바 (現場, Genba) — "실제로 일이 벌어지는 현장"을 뜻하는 린(Lean) 용어. 답은 사무실이 아니라 겐바에 있다는 거죠. 세 번째 방법의 핵심이고요.

Y's Insight

하나, 현상이 어렴풋이 보일 때: 일단 다 붙여봅니다

어느 정도 현상이 보이기 시작할 때 쓰는 방법이에요. 눈에 걸리는 현상을 하나도 빠짐없이 포스트잇에 적어서 화이트보드에 붙여요. 그리고 다시 하나씩 리뷰하면서 패턴이나 주제, 순서가 있는지 곱씹어봅니다. 그래도 전혀 모르겠으면 화이트보드에 축을 하나 그어요. 예를 들어 마크비전에 와서 "왜 고객사에게 받는 돈 대비 운영비가 더 많이 드는 케이스가 생기지?"를 정의해야 했을 때, 일하면서 나온 정황들을 화이트보드에 쭉 나열했어요. 그랬더니 가격 구조, 자동화 부족, 운영의 관성 같은 주제가 떠오르더라고요. 가격 구조 밑에는 '계약서에 고객 서비스 목표나 KPI가 명확히 정의돼 있지 않음', '추가 업무 요청에 대한 비용 청구 방안이 없음' 같은 실제 사례들이 있었어요. 이런 사례를 모으다 보니 그 위의 주제가 보인 거예요.

흩어진 현상을 밖으로 다 꺼내놓고 나서, 공통의 냄새가 나는 것들끼리 포스트잇을 모아서 가만히 바라보고 있으면, 이들을 정의할 수 있는 이름이 생각나고 그 다음에 구조가 보이기 시작해요.


둘, 아주 작은 단위의 임팩트를 계산할 때: 무식하게 재고, 크게 곱합니다

제가 제일 좋아하는 작업이에요. 아주 작은 케이스부터 실제로 측정해보고, 그걸 전체로 확대 적용하는 거예요. 오차 범위를 잡는 건 어렵지만, 이 작은 측정을 전체로 넓혀보는 거죠. 쿠팡에서도, 무신사에서도, 여기 마크비전에서도 똑같은 주제의 일을 했어요. 운영에 들어가는 비용을, 행동 하나하나 단위로 가격을 환산하는 작업이요. 처음엔 진짜 무식하게 시작해요. 실제로 그 일을 하는 사람 뒤에 서서, 그가 하는 행동 하나하나를 초 단위로 측정합니다. 그리고 그 측정법을 가이드로 만들어서, 하루 동안 전체 혹은 일부 직원에게 측정을 지시해요. 물론 그날은 생산량이 좀 떨어질 수 있어요. 근데 회사가 진짜 알고 싶어 하는 본질을 보기 위한, 아주 작은 희생이라고 생각해요. 그렇게 배송에 걸리는 시간, 반품에 걸리는 시간, 저작권 침해를 보호·보장하는 데 걸리는 시간을 재고, 그들의 평균 임금을 구해요. 그다음 이 식을 적용합니다.

행동 1건당 비용 = (시간당 임금 × 그 행동에 걸린 시간)

이렇게 하면 그 행동을 1건 자동화할 때마다 얻는 효과를 숫자로 뽑을 수 있어요. 가장 중요한 건 '반품에 걸리는 시간 전체'를 측정하는 게 아니에요. '반품지 주소를 확인하고 반품을 픽업하는 시간', '픽업해서 캠프에 가져다 두는 시간', '캠프에서 이 반품 상품을 도착했다고 처리하는 시간'부터 '센터에 반품이 입하되는 시간', '입고 처리되는 시간' 등등을 아주 세세하게 나누어야 해요. 사실 이것보다 저는 더 작은 시간을 정의했었어요. 반품의 재고화 과정에서 '포장을 해제하는 시간', '상품의 실물과 바코드를 대조하는 시간', '바코드가 없으면 바코드를 찾는 시간' 이렇게 정의해야 기능 1개를 만들어줄 때마다 임팩트를 계산할 수 있거든요. 예를 들어 자동 바코드 식별 기능을 만든다고 가정해보면, 실제로 바코드 없이 들어오는 반품이 어느 정도 비중을 차지하는지만 알아도 이 시간이 지대한 영향이 있는가 없는가를 알 수 있는 것처럼요.

근데 이 작업은 여기서 끝나면 절대 안 돼요. 앞으로도 계속 필요한 일이라면, 이 숫자가 자동으로 측정되는 데이터 포인트를 개발로든 프로세스로든 반드시 만들어둬야 해요. 안 그러면 매번 사람이 초시계 들고 뒤에 서 있어야 하거든요.

셋, 아무도 정리한 적 없는 일을 정리할 때: 그냥 현장에 갑니다

이것도 제가 좋아하는 작업인데, 의외로 쉬워요. 가서 직접 보고, 인터뷰하고, 정리하면 되거든요. 저는 물류 프로덕트에서 일할 때 현장 가는 걸 좋아했어요. 사무실에서 보면 현장 일은 늘 변수가 생기는 것 같고, 이 센터 저 센터 다 다르고, 유동적으로 보여요. 근데 실제로 가보면 대부분 아주 엄격한 프로세스로 굴러가요. 그리고 같은 회사의 센터가 서로 다른 프로세스를 가진 데는 반드시 이유가 있어요. 납득해야 하는 경우는 보통 비즈니스 형태가 다를 때예요. 예를 들어 A센터는 매입인데 B센터는 위탁이면, 상품을 취급하고 재고화하는 과정을 우리 입맛대로 길들이기 어려운 부분이 있고, 어디까지를 서비스 범위로 보장하고 제공하는지도 달라지거든요. 종이로 하던 일을 시스템으로 만들 때, 이 관찰과 프로세스 정돈은 필수예요. 있으면 안 되는 프로세스는 없애자고 제안하고, 통일 안 된 프로세스는 통일하면서, 가장 큰 줄기의 자동화부터 시작해 세세한 케이스까지 커버하는 제품을 만드는 거죠.

이런 액션을 취해보세요

막막한 일이 떨어졌을 때, 이 세 개 중 하나를 골라서 시작해보세요.

  • 뭐가 문제인지 어렴풋하면 → 일단 다 꺼내서 붙이고, 성질끼리 묶기.

  • 임팩트를 증명해야 하면 → 제일 작은 케이스 하나를 실제로 재서, 전체로 곱하기.

  • 아무도 안 해놨으면 → 사무실 말고 현장으로 가기.

공통점은 하나예요. 머릿속에서 정의하려고 애쓰지 말고, 밖으로 꺼내서 눈에 보이게 만들 것.

근데 말이죠

물론 모든 걸 이렇게 숫자로 만들 수 있는 건 아니에요. 어떤 문제는 아무리 재도 깔끔한 인과가 안 나오고, 측정하는 행위 자체가 비용이라 배보다 배꼽이 커질 때도 있어요. 요즘처럼 변수가 많은 일은, 완벽하게 정의하고 시작하기보다 일단 작게 해보고 결과를 보는 게 더 빠를 때도 있고요.

그래서 이 방법들은 "무조건 다 숫자로 만들자"가 아니에요. 막막해서 아무것도 손대지 못하고 있을 때, 최소한 잡히는 첫 번째 조각을 만드는 도구에 가까워요. 정의가 끝이 아니라 시작이라는 것도 늘 잊지 않으려 하고요.

여러분은 0에서 일을 정의해야 할 때, 어디서부터 손을 대세요?

이 글에 대한 반응

도움이 됐다면 좋아요로 알려주세요.

댓글

로그인하면 댓글을 남길 수 있습니다.

로그인

댓글을 불러오는 중입니다.