AI를 활용한 윈-로스(Win-Loss) 분석 작성법: 단계별 가이드

Powerdrill Bloom·2026년 9월 11일

윈로스(win-loss) 분석은 성사된 딜(deal)과 놓친 딜을 비교하여 그 차이를 설명합니다. 종결된 딜(closed-deals) 내보내기 데이터를 기반으로 분석을 시작하세요. 세그먼트별로 성공과 실패를 집계하고, 이를 나누어 윈레이트(win rate)를 구한 다음, 실패 원인을 몇 가지 그룹으로 분류합니다. 집계하는 데는 몇 분밖에 걸리지 않지만, 분류 단계에서 대부분의 윈로스 분석이 무너지기 마련입니다.

이 가이드에서는 먼저 스프레드시트를 활용하는 방법을 살펴보고 정확히 어느 단계에서 막히는지 보여준 다음, 내보낸 데이터로부터 동일한 분석을 단 3단계 만에 다시 구축하는 방법을 설명합니다.

윈로스 분석이 실제로 말해주는 것

의사 결정에 영향을 미치는 빈도순으로 정리한 세 가지 질문입니다.

우리는 얼마나 자주 이기는가? 윈레이트(win rate)는 특정 기간의 종결된 딜 중 성사된 딜의 비율입니다. 이것 자체만으로는 인사이트가 아닌 단순한 점수판에 불과합니다.

우리는 어디에서 이기는가? 세그먼트, 제품 또는 딜 규모별로 세분화한 동일한 비율은 대개 전체 수치보다 더 큰 변동을 보입니다. 전체 윈레이트가 35%인 기업이라도 미드마켓(mid-market)에서는 41%, 엔터프라이즈(enterprise)에서는 22%일 수 있으며, 이 두 수치는 서로 다른 두 가지 문제를 가리킵니다.

우리는 왜 지는가? 이 부분은 모두가 알고 싶어 하지만 제대로 파악하는 곳은 거의 없습니다. 그 답은 5명의 담당자가 제각각 다른 방식으로 작성한 자유 서식 텍스트 필드에 숨겨져 있기 때문입니다.

첫 번째 질문에만 답하는 윈로스 분석은 단순한 보고서에 불과합니다. 세 가지 질문에 모두 답하는 분석이라야 비로소 의사 결정 문서가 되며, 한 시간 더 투자할 만한 가치가 있습니다.

시작하기 전에 필요한 것

적어도 2개 분기 이상을 포함하며 기회(opportunity)당 한 행으로 구성된 종결된 딜(closed-deals) 내보내기 데이터.
최소 4개의 열: 종결일(close date), 결과(outcome), 세그먼트 또는 제품, 금액(amount).
정리가 안 되어 있더라도 실패 원인(loss-reason) 열이 필요합니다. 이 열이 분석의 유용성 여부를 결정합니다.
기간에 대한 명확한 정의 하나. 종결일 또는 생성일 중 하나를 선택하여 기록해 둡니다.

Microsoft의 피벗 테이블(PivotTable) 가이드에서는 형식 요구 사항을 다음과 같이 명확히 규정하고 있습니다. "데이터는 단일 머리글 행이 있는 열로 구성되어야 합니다." CRM 내보내기 데이터는 머리글 행이 두 개이거나 제목 표시줄이 병합된 상태로 제공되는 경우가 많으므로, 다른 작업을 하기 전에 이 부분부터 먼저 수정하세요.

첫 분석을 시작하기 전에 합의해야 할 사항이 하나 더 있습니다. 바로 실패 원인 필드를 누가 관리할 것인가입니다. 대부분의 팀에서는 영업 담당자가 딜을 종결하고 레이블을 선택합니다. 담당자들은 깔끔한 분류 체계보다는 다음 딜을 성사시키는 데 집중합니다. 이는 성격상의 결함이 아닙니다. 단지 올바른 선택지를 3초 만에 고를 수 있을 만큼 레이블 목록이 짧아야 함을 의미할 뿐입니다. 매 분기 한 사람이 이 목록을 전담하여 관리해야 합니다.

스프레드시트에서 윈로스 분석을 수행하는 방법

옵션 1: COUNTIFS 함수로 성공 및 실패 집계하기

COUNTIFS 함수는 "여러 범위의 셀에 기준을 적용하고 모든 기준이 충족된 횟수를 계산"합니다. 이것이 윈레이트 계산의 전부입니다. 결과가 'Won'이고 세그먼트가 'Mid-Market'인 행의 개수를 세고, 해당 세그먼트의 전체 종결 행 개수를 센 다음 나눕니다.

공식 문서에 언급된 두 가지 세부 사항을 알아두면 나중에 시간을 아낄 수 있습니다. Microsoft는 "추가되는 각 범위는 criteria_range1 인수와 동일한 수의 행 및 열을 가져야 한다"고 명시하고 있습니다. 따라서 선택 범위가 일치하지 않으면 수식이 소리 없이 깨지게 됩니다. 또한 최대 127개의 범위 및 기준 쌍을 사용할 수 있는데, 이는 웬만한 분석에 필요한 것보다 훨씬 넉넉한 수치입니다.

같은 페이지에 한 가지 함정이 더 있습니다. 기준 인수가 빈 셀을 가리키는 경우, COUNTIFS는 "빈 셀을 0 값으로 처리"합니다. 따라서 빈 세그먼트가 없는 것이 아니라 어떤 값으로 계산되어, 아무도 판매하지 않는 세그먼트에 딜이 포함되는 결과가 발생할 수 있습니다.

옵션 2: 피벗 테이블로 요약하기

결과(outcome)를 '행'에, 금액(amount)을 '값'에 드래그하면 세그먼트별로 성사된 파이프라인과 놓친 파이프라인을 확인할 수 있습니다. 윈레이트를 개수가 아닌 비율로 표시하려면 값 필드 설정(Value Field Settings)을 열고 % of Grand Total이 있는 값 표시 형식(Show Values As) 탭을 사용하세요.

값을 계산된 수치와 백분율로 동시에 표시할 수도 있습니다. Microsoft의 지침에 따르면 "항목을 값 영역으로 두 번 드래그"한 다음, 각각에 대해 '값 요약 기준'과 '값 표시 형식'을 설정하면 됩니다. 이렇게 하면 두 번째 피벗 테이블을 만들지 않고도 딜 개수와 전체 대비 비율을 나란히 표시할 수 있습니다.

옵션 3: 실패 원인 추가하기

이제 실패 원인(loss-reason) 열을 피벗 테이블로 드래그하여 어떤 일이 일어나는지 확인해 보세요. Microsoft는 이 동작을 다음과 같이 정확히 설명합니다. "기본적으로 값 영역에 배치된 피벗 테이블 필드는 합계(SUM)로 표시됩니다. Excel에서 데이터를 텍스트로 해석하면 데이터가 개수(COUNT)로 표시됩니다."

이것은 정상적이고 예상된 동작입니다. 원인 열은 텍스트이므로 개수를 세는 것이 맞습니다. 문제는 무엇을 세느냐입니다.

스프레드시트 방식이 지체되는 이유

실패 원인 열에는 아마도 Price, price, Too expensive, Budget, No budget this year, Lost on cost 등이 포함되어 있을 것입니다. 이는 한 가지 원인을 여섯 가지 방식으로 표현한 것에 불과합니다. 고유한 문자열의 개수를 세면 여섯 가지 일이 일어난 것처럼 보이지만, 실제로는 한 가지 일이 여섯 번 일어난 것입니다.

결국 누군가는 이 목록을 붙잡고 앉아 어떤 레이블이 같은 의미인지 판단해야 합니다. 이 판단 과정이 실제 분석에 해당하며, 이는 수작업으로 이루어집니다. 게다가 담당자들이 매번 새로운 표현을 만들어내기 때문에 매 분기마다 이 작업을 반복해야 합니다.

여기에 세 가지 사소한 번거로움이 더해져 문제를 악화시킵니다.

진짜 원인은 대개 노트(notes)에 있습니다. 선택 목록에는 대략적인 분류만 담겨 있고 자유 서식 텍스트 필드에 진짜 사연이 들어 있지만, 자유 서식 텍스트를 수작업으로 취합하는 사람은 아무도 없습니다.

규모가 작은 세그먼트가 트렌드로 오인될 수 있습니다. 특정 세그먼트의 딜이 4개뿐이라면 이는 단순한 일화에 불과하지만, 그 옆에 백분율이 표시되면 마치 유의미한 발견처럼 보입니다.

피벗 테이블이 최신 상태를 유지하지 못합니다. 여기서도 피벗 테이블 공식 문서의 내용이 중요합니다. 새로운 행이 추가되면 "해당 데이터 원본을 기반으로 작성된 모든 피벗 테이블을 새로 고쳐야 합니다." 새로 고침을 한 번만 깜빡해도 지난 분기의 분석이 이번 분기의 분석으로 발표될 수 있습니다.

AI로 윈로스 분석을 만드는 방법

1단계: 종결된 딜 내보내기 데이터 업로드

Powerdrill Bloom을 열고 내보낸 데이터를 업로드합니다. Excel, CSV, PDF, 문서 파일 업로드를 모두 지원하므로, CRM에서 다운로드한 원본 파일을 별도의 정리 작업 없이 바로 사용할 수 있습니다.

정리되지 않은 실패 원인 열과 노트 필드를 삭제하지 마세요. 이 두 열은 파일에서 가장 가치 있는 정보이며, 보통 사람들이 분석을 시작하기 전에 가장 먼저 지워버리는 항목들입니다.

2단계: 하나의 프롬프트로 집계 및 원인 그룹화 요청하기

자연어로 분석 내용을 설명하세요. 지난 2개 분기 동안의 세그먼트별 윈레이트와 성사된 딜 및 놓친 딜의 평균 규모를 요청합니다. 그런 다음 실패 원인을 몇 가지 그룹으로 분류하고, 각 그룹에 어떤 원본 레이블이 포함되었는지 함께 보여달라고 요청하세요.

단순한 합계뿐만 아니라 매핑 관계도 함께 요청하세요. Lost on cost와 No budget this year가 하나로 묶인 것을 확인해야 그 분류가 타당한지 직접 판단할 수 있습니다. 이는 계산이 아닌 주관적 판단의 영역이므로, AI에 완전히 위임하기보다는 직접 검토해야 하는 부분입니다.

이왕 요청하는 김에 최소 기준도 추가하세요. 최소 딜 개수 미만인 세그먼트는 개수만 표시하거나 아예 숨겨달라고 요청합니다. 이렇게 하면 딜이 4개뿐인 세그먼트가 트렌드로 오인되는 것을 방지할 수 있습니다.

각 수치는 해당 수치의 근거가 되는 행 데이터와 함께 제공됩니다. 의심스러운 집계 수치가 있다면 슬라이드에 반영하기 전에 해당 수치를 만들어낸 딜 상세 내용을 열어 확인할 수 있습니다.

3단계: 사람들이 실제로 읽어볼 만한 문서로 변환하기

원하는 레이아웃을 직접 요청하세요. 핵심 윈레이트, 이전 기간 대비 추이, 세그먼트별 윈레이트, 그룹화된 실패 원인, 그리고 가장 큰 변화에 대한 한 줄 요약을 포함하도록 합니다.

윈로스 분석을 사람들이 읽어볼 만한 문서로 변환하기 전에 Powerdrill Bloom에서 슬라이드 테마 선택하기

프롬프트를 저장해 두세요. 다음 분기에는 새 데이터를 업로드하고 동일한 프롬프트를 실행하기만 하면 되므로, 일회성 분석을 반복 가능한 프로세스로 전환할 수 있습니다. 결과물을 정기적으로 발행하는 보고서로 만들어야 한다면 AI report generator 페이지를 참고하세요. 차트 작성이 필요하다면 make graphs from Excel 페이지에서 관련 내용을 확인할 수 있습니다.

윈로스 분석에 포함되어야 할 내용

구성 요소	답변하는 질문	흔히 하는 실수
핵심 윈레이트	이전 기간보다 전환율이 개선되었는가?	분모에 진행 중인(open) 딜을 포함하는 것
세그먼트별 윈레이트	강점이 어디에 집중되어 있는가?	딜이 3개뿐인 세그먼트를 마치 안정적인 데이터인 것처럼 보고하는 것
성사된 딜 vs 놓친 딜의 평균 규모	큰 딜을 놓치고 있는가, 아니면 작은 딜을 놓치고 있는가?	한 행에는 중앙값을 사용하고 다른 행에는 평균값을 사용하는 것
그룹화된 실패 원인	무엇 때문에 계속 실패하는가?	그룹화된 레이블 대신 원본 레이블의 개수를 세는 것
영업 주기(Sales cycle) 길이	실패 결정이 느리게 내려지는가, 빠르게 내려지는가?	한 행은 생성일을 기준으로 측정하고, 다른 행은 종결일을 기준으로 측정하는 것
경쟁으로 인한 실패	실제로 누구에게 지고 있는가?	행의 절반 정도에서 경쟁사 필드를 빈칸으로 남겨두는 것
주요 변화 요약	지난 분기 대비 무엇이 달라졌는가?	중요한 변화 하나 대신 모든 변화를 나열하는 것

완성된 문서는 단 한 페이지로 제한하세요. 9페이지짜리 슬라이드로 작성된 윈로스 분석은 단 한 번만 읽히고 잊힐 뿐입니다.

이 표의 대부분의 버전에서 누락되어 있지만 가장 쉽게 추가할 수 있는 열이 하나 있습니다. 바로 '데이터 내보내기 날짜'입니다. 지난 분기 파일과 이번 분기 파일을 비교하는 두 사람은 결국 당시 어떤 딜이 진행 중이었는지를 두고 의견 대립을 겪게 마련입니다. 데이터를 언제 추출했는지 명시하는 단 한 줄의 문구만 있으면 이러한 불필요한 논쟁을 사전에 방지할 수 있습니다.

실제 적용 예시

예를 들어 한 분기가 180개의 딜(성사 63개, 실패 117개)로 마감되었다고 가정해 보겠습니다. 전체 윈레이트는 35%입니다. 이를 세그먼트별로 나누어 보면, 엔터프라이즈는 27개 딜 중 22%를 기록한 반면 미드마켓은 96개 딜 중 41%를 기록했습니다.

두 수치보다 더 중요한 것은 그룹화된 실패 원인입니다. 117개의 실패 중 44개는 가격(price) 때문이고, 31개는 연동 기능 부재(missing integration) 때문이라고 가정해 봅시다. 이는 서로 다른 두 팀과 나누어야 할 서로 다른 두 가지 주제입니다. 그룹화하지 않은 원본 목록이었다면 11가지 원인이 나열되어 어느 팀과도 제대로 된 대화를 시작하지 못했을 것입니다.

여기에 딜 규모(deal-size) 행을 추가해 보겠습니다. 가격 때문에 놓친 44개 딜의 평균 규모는 $12k이고, 연동 기능 때문에 놓친 31개 딜의 평균 규모는 $58k라고 가정해 봅시다. 그렇다면 연동 기능 문제는 딜 개수는 더 적지만 매출 가치 면에서는 대략 두 배에 달합니다. 이러한 가치의 역전 현상은 개수만 집계하는 분석에서 가장 흔히 놓치는 부분입니다.

누가 얼마나 자주 읽는가

세 부류의 독자가 이 문서를 서로 다른 방식으로 활용하므로, 레이아웃 역시 이를 고려해야 합니다.

영업 리더십은 핵심 윈레이트와 변화 요약을 읽고, 특이 사항이 없는 한 거기서 멈춥니다. 제품 및 마케팅 팀은 그룹화된 실패 원인을 읽는데, 여기서 제품 로드맵과 메시징 전략이 시작되기 때문입니다. 재무 팀은 딜 규모를 확인합니다. 딜 규모가 줄어들면서 윈레이트만 올라가는 것은 겉보기와 달리 진정한 성공이 아니기 때문입니다.

첫 번째 독자층을 기준으로 문서를 작성하되, 나머지 두 독자층을 위한 주석을 추가하세요. 한 페이지 안에 세 가지 관점을 모두 담아내는 것입니다.

유용한 실패 원인 목록 확보하기

위의 모든 분석은 누군가가 그룹화할 수 있는 실패 원인 필드가 존재할 때만 가능합니다. 다음 세 가지 습관을 들이면 원천적인 데이터 혼선을 대부분 해결할 수 있습니다.

선택 목록은 최대 7개로 제한하세요. 목록이 길어지면 일관성 없는 선택이 발생할 수밖에 없습니다. 딜을 놓친 상황에서 드롭다운을 끝까지 스크롤하며 고민하는 사람은 아무도 없기 때문입니다.

원인 분류와 상세 내용을 분리하세요. 카테고리를 선택하는 필수 선택 목록 하나와 상세 내용을 적는 선택 사항인 자유 서식 텍스트 상자 하나를 둡니다. 이 둘을 합쳐버리면 어느 쪽도 제대로 얻지 못합니다.

솔직한 옵션을 하나 마련해 두세요. 명시적인 Unknown 또는 No decision 선택지를 포함합니다. 이것이 없으면 모호하게 놓친 모든 딜이 가격 탓으로 분류되어, 결국 모든 문제의 원인이 가격인 것처럼 보이게 됩니다.

필드 자체가 아니라 매핑 관계를 검토하세요. 입력 단계에서 완벽하게 깨끗한 데이터를 얻기란 불가능합니다. 대신 정리되지 않은 레이블을 7개 그룹으로 연결하는 안정적인 매핑 체계를 구축하고, 매 분기 한 사람이 이를 검토하는 방식을 취하는 것이 현실적입니다.

흔히 하는 실수

분모에 진행 중인(open) 딜을 포함하는 것. 윈레이트는 성사된 딜을 종결된 딜로 나눈 값입니다. 아직 진행 중인 기회를 포함하면 수치가 항상 왜곡되어 좋게 보입니다.

실패 원인 목록이 계속 늘어나게 방치하는 것. 이번 분기의 원인이 11개이고 지난 분기에는 6개였다면, 이는 시장의 변화가 아니라 단어 사용의 변화를 보고 있는 것일 뿐입니다. 먼저 그룹화를 수정한 다음 비교하세요.

규모가 작은 세그먼트를 트렌드로 오인하는 것. 독자가 직접 판단할 수 있도록 모든 비율 옆에 실제 개수를 함께 표시하세요.

오래된 피벗 테이블을 그대로 발표하는 것. 원본 데이터에 새 행이 추가되더라도 피벗 테이블이 자동으로 업데이트되지는 않습니다. 깔끔해 보이지만 옛날 숫자가 담긴 레이아웃은 분석을 전혀 하지 않는 것보다 못합니다.

매핑 관계를 숨기는 것. 보고서를 읽는 사람은 결국 무엇이 "가격"으로 분류되었는지 묻게 마련입니다. 차트 옆에 그룹화 기준을 함께 공개하면 이러한 대화는 10초 만에 끝납니다.

실적이 좋지 않은 분기 뒤에만 분석을 실행하는 것. 수치가 떨어졌을 때 비로소 구축하는 윈로스 분석은 비교할 기준점(baseline)이 없습니다. 실적이 좋을 때를 포함하여 매 분기 정기적으로 실행해야 실적이 나쁠 때 그 원인을 명확히 파악할 수 있습니다.

규모를 제외하고 비율만 보고하는 것. 5개의 딜 중 20%에서 40%로 이동한 세그먼트는 실제로 무언가가 두 배로 늘어난 것이 아닙니다. 모든 백분율 옆에 개수를 함께 표기하여 독자가 스스로 판단할 수 있도록 하세요.

결론

윈로스 분석의 산식은 정말 간단합니다. 집계에는 COUNTIFS, 요약에는 피벗 테이블, 비율 표시에는 % of Grand Total을 사용하면 됩니다. 정작 오후 내내 시간을 잡아먹는 작업은 실패 원인이 실제로 무엇을 의미하는지 판단하는 일입니다.

이 작업을 레이블을 그룹화하고, 매핑 관계를 보여주며, 각 수치 뒤에 숨겨진 딜을 바로 찾아줄 수 있는 도구에 맡겨보세요. 지난 분기의 종결된 딜 내보내기 데이터로 Powerdrill Bloom 사용해 보기를 실행해 보고, 복잡했던 실패 원인 목록이 얼마나 깔끔하게 정리되는지 직접 확인해 보세요.

이보다 앞선 단계의 파이프라인 뷰를 확인하려면 CRM 내보내기 데이터를 파이프라인 보고서로 변환하는 방법 가이드를 참고하세요. 도구 측면의 정보는 영업 파이프라인 분석을 위한 상위 AI 도구 모음에서 다루고 있습니다.

자주 묻는 질문

윈로스 분석이란 무엇인가요?

동일한 기간 동안 성사된 딜과 놓친 딜을 구조적으로 비교하는 분석입니다. 여기에는 윈레이트, 세그먼트별 비율 차이, 그리고 그룹화된 실패 원인이 포함됩니다.

윈레이트는 어떻게 계산하나요?

동일한 기간 동안 성사된 딜의 개수를 전체 종결된 딜의 개수로 나눕니다. 일치하는 범위에서 모든 기준이 충족되는 행의 개수를 세어주는 COUNTIFS 함수를 사용하면 두 가지 집계를 모두 손쉽게 처리할 수 있습니다.

실패 원인 필드가 합계가 아닌 개수로 표시되는 이유는 무엇인가요?

텍스트 데이터이기 때문입니다. Microsoft 문서에 따르면 값 영역의 피벗 테이블 필드는 기본적으로 합계(SUM)로 표시되지만, Excel에서 데이터를 텍스트로 해석하는 경우에는 개수(COUNT)로 표시됩니다.

윈로스 분석에는 몇 개의 실패 원인이 있어야 하나요?

분기별로 비교하기 쉬울 만큼 적어야 하며, 실제로는 약 5개에서 7개 그룹이 적당합니다. 누구나 각 그룹에 어떤 원본 레이블이 포함되었는지 확인할 수 있도록 하위의 원본 레이블을 함께 유지하세요.

윈로스 분석은 얼마나 자주 실행해야 하나요?

대부분의 팀에는 분기별 실행이 가장 적합합니다. 한 달 동안에는 세그먼트별로 안정적인 데이터를 얻을 만큼 충분한 딜이 종결되지 않기 때문입니다. 주기와 상관없이, 지난 기간의 파일을 수정하기보다는 항상 새로 내보낸 데이터를 기반으로 다시 생성하세요.