숫자를 틀리는 건 당연하다

조회수 2018. 8. 13. 15:02 수정
번역beta Translated by kaka i
번역중 Now in translation
글자크기 설정 파란원을 좌우로 움직이시면 글자크기가 변경 됩니다.

이 글자크기로 변경됩니다.

(예시) 다양한 분야의 재밌고 유익한 콘텐츠를 카카오 플랫폼 곳곳에서 발견하고, 공감하고, 공유해보세요.

실수를 최대한 줄이는 두 가지 방법을 공유합니다.

업무 시간에 톡 하나가 왔습니다. 친한 후배가 다니는 회사에서 숫자를 틀려서 힘든 하루를 보냈다는 이야기였습니다. 기획 업무를 하고 있는 친구인데, 중요한 변수 몇 개를 빼먹고 결과를 발표하다 그 부분에 대한 지적을 받고 많이 위축되었다고 했죠. 그래서 애증의 '숫자'에 대해 오랫동안 이야기했습니다.


첫 회사를 다닐 때 선배들이 모이면 결국 깔때기같이 하는 말이 있었습니다.

걔 부서 옮겼던데. 이번에 다시 경영 기획 파트로 갔다는 거야.
돌고 돌아 또 거기야?
그래… 숫자 하는 사람들은 어떻게 하든 숫자로 가게 되어 있으니..


'숫자 하는 사람'


그건 비단 이야기의 당사자만 말하는 호칭이 아니었습니다. 제가 오랫동안 몸담았던 기획팀이나 최근 파생된 여러 부서에서 어떤 역량을 가진 사람들을 집합처럼 부르는 말이었습니다. 센스가 있고 트렌디한 사람이라면 마케팅이나 기획 부서로, 사람 좋아하면 영업 부서로, 프로세스에 대한 이해와 변형이 필요하면 복잡한 공정을 맡기는 것과 유사한 이야기죠.

대부분은 숫자를 다룹니다. 결국 측정하기 위해 일을 하니까요. 특히 관리회계 베이스의 업무를 담당해 보신 분들은 숫자에 대한 막막한 기준 없음과 엉뚱한 모델링에 대한 빡침을 종종 경험하셨을 것입니다. 저와 톡을 한 그 후배도 표준화된 관리회계 기준이 워낙 모호하다 보니 그때그때 최신 버전의 모델링을 담을 수 없기에 그런 실수를 저지르는지도 모르죠.


이건 숫자 하는 사람의 잘못만은 아닙니다. 늘 새로운 모든 시뮬레이션 방법을 엑셀에 담고 살 수는 없습니다. 오히려 제각각의 다른 기준을 세우고 각자 다른 안드로메다를 그리고 있는 경영진, 혹은 관리자의 몽상이 이런 현상을 부추긴 것에 가깝죠.


재무 회계와 달리 관리회계는 어떤 지점에서 제각각으로 쓰고 있는 게 많습니다. 말발 있는 부서, 말발 있는 사람이 하는 게 법이 되는 경우가 많죠. 최근 익명 게시판 어플에서는 '공통비 배부 기준'에 대해 많은 댓글이 달린 일이 있었습니다. 사업 업태와 이해관계에 따라 제각각이었죠. 매출 기반으로 배부하기도 하고 매출에 인원수를 붙이기도 하고, 신규 사업에 대해서는 배부하지 않는 유예기간을 부여한 회사도 있었습니다. 정말 제각각이었죠. 정해진 룰이 없기에 정하기에 따라 달라지는 것이었습니다.


하물며 관리회계도 이런데, 기획 라인에서 찍어내는 수많은 숫자들은 그런 룰조차 없이 논리 싸움으로 진행되는 게 당연합니다. 그러니 숫자가 나온 기준과 로직은 늘 깨질 수밖에 없는 위험을 달고 있는 것입니다. 당신의 재능이 없거나 적성을 탓하지 마십시오. 기업에서 그 자리에 앉혀 놓았다는 것은, 큰 이변이 없는 한 당신이 그걸 잘할 것 같다는 성향과 역량을 가졌다는 사인을 보내는 것이니까요. 실제 이 일은 그리 어려운 일도 많이 꼼꼼해야 하는 일도 아닙니다.


그럼 이렇게 당하고만 있어야 할까요? 그건 아닙니다. 뭔가 혼나지 않을 대책을 세워야 됩니다. 평가라도 잘 받기 위해서는 이 논리 덩어리를 더 논리스럽게 만들어 줘야죠.



자신만의 도구를 발전시킨다

모두 엑셀 도구 몇 개씩은 상시로 쓰는 게 있을 겁니다. 매출이나 이익을 분석해 놓은 파일, 고객이나 업체별 실적에 대해 대시보드처럼 만든 파일, 관리회계에 따른 시뮬레이션을 건드리면 뒤까지 바뀌는 파일이나 복잡한 배부기준이나 비상 계획 파일,  리스크가 있는 일을 대비한 파일 등 모두 숫자를 정리하고 예측하는 파일을 갖고 있습니다.


이 파일 하나 잘 만들어 두면 루틴한 일 상당 부분은 해결할 수 있습니다. 특히 회사에서 중요하게 보는 지표들은 여기 빠지지 않게 늘 추가와 수정을 거치면서 파일의 버전 관리를 해 둘 필요가 있습니다. 값 검증도 필수입니다. 예측과 실적의 간격이 짧은 도구들은 티도 금방 나고 피드백도 받을 수 있습니다. 그러니 이런 도구는 자주 찾아 고치는 노력이 필요합니다.


아마추어 같아 보이는 엑셀판이지만, 심플한 이론 안에서 관리하면 편한 도구가 될 수 있습니다. 일회성 문서를 만들 시간을 합쳐 상시 활용할 수 있는 엑셀 도구를 만들어 봅시다.



자체 검증 절차를 만들어 본다

귀찮은 일이지만 효과는 가장 좋은 방법입니다. 보고 전 스스로 검증하는 절차를 엑셀 상이든 프로세스 상이든 만들어 보는 것이죠.


엑셀에 아예 값 검증하는 법을 넣어보는 것도 추천합니다. 제가 신입 시절 초우량 인사 평가를 받던 분이 같은 부서에 있었는데, 이 분이 높이 평가받는 이유가 경영기획 부서가 처음 생겼을 당시 실무를 맡으면서 남들이 생각하지 못한 모든 관리 도구를 만들어 지금의 절차와 디테일을 만들었기 때문이라는 주변 분의 평을 들은 적이 있습니다.


이 분이 만든 파일은 역시나 변수 몇 개를 바꾸면 전체가 로직에 의해 쫙 바뀌는 엑셀이 대부분이었습니다. 다만 다른 버전과 차이점이 있다면, 복잡한 논리적 검증 절차를 수식 여기저기에 심어 두었다는 것입니다. 특히 입력 칸에 넣는 숫자가 논리적으로 맞지 않을 때에는 바로 조건부 서식에 의해 잘못된 값이라는 메시지를 크게 출력하여 틀린 값 자체를 많이 줄이고 있었죠.


전체 수보다 더 큰 숫자나 단위 차이가 너무 많이 나는 숫자, 결측인 변수나 수정을 정기적으로 하지 않은 값은 복잡한 숨김 열을 지나 이런 결과를 출력해냈습니다. 물론 앞서 말씀드린 예실 차이 또한 누적으로 함께 제공하고 있었죠.


하루는 야근하며 그분과 함께 파일을 들여다본 적 있습니다. 이 복잡한 파일이 만들어지게 된 계기 또한 들을 수 있었죠. 초반에는 자동화가 잘 진행되지 않아 입력하고 복사하고 붙여넣는 값들이 많았는데, 이 과정에서 뭔가가 틀릴 경우 전체가 틀어지게 되는데 알아채기가 어렵고, 설사 알게 된다 해도 어디가 잘못되었는지 찾는 데 너무 많은 시간을 허비하게 되는 게 문제라 느껴서 만들었다 하셨습니다.


사실 기획이든 재무든 ERP에 있는 값들을 그대로 쓰는 회사는 별로 없습니다. 대부분은 기초 데이터를 보고 대상의 관점에 맞게 변용한 뒤 엑셀 등을 통해 정리하게 됩니다. 이런 과정에서는 늘 이런 고민이 동반될 수밖에 없습니다. 그러니 자체 검증 절차를 로직에 심는 것은 보다 덜 리스크한 선택이 될 것입니다.



아무리 좋은 것도 피드백과 논리 앞에서는 어쩔 수 없다


숫자를 쓰는 일은 결국 어떤 철학이 그 속에 숨어 있는지 알아야 하고, 기존 철학 또한 늘 새로운 경영 철학에 도전받고 있다는 것을 알아야 합니다. 복잡한 모델링을 만들었다 해도 그것의 목적과 효과를 철학의 틀 안에서 설명할 수 없다면 금방 외면받을 가능성이 큽니다.


룰 베이스의 모델링을 하는 사람이라도 자신만의 관점과 논리가 있어야 합니다. 일이 만들어지고 원인이 되는 숫자부터 결과가 되는 숫자까지 돈을 버는 데 어떤 기여를 하는지, 그 로직은 어떤 피드백에 의해 수정되는지 말할 수 있어야 합니다. 분명한 논리와 결과는 이런 숫자 싸움에서 중요한 근거가 됩니다.


사실 보고 받는 사람 또한 마찬가지입니다. 늘 변화에 대해 고민하고 있죠. 대부분은 자신이 실무를 할 때와 별반 다르지 않은 가정, 즉 시장을 바라보는 관점이나 돈을 버는 데 중요하다고 생각하는 지표, 계산 방법이 별로 달라지지 않았다는 막연한 답답함이 있으니까요. 그래서 기존 시뮬레이션을 바꾸는 과정, 통계 모델링을 활용하여 예측력을 올리는 과정은 먼저 길을 만드는 데 도움이 됩니다. 신규로 만들어지는 로직에 대해서는 먼저 길을 만드는 사람이 기준이 될 가능성이 높기 때문이죠.


저도 10년 정도 실무를 봤지만 지금도 숫자를 틀립니다. 앞으로도 많이 틀릴 것 같습니다. 하지만 앞서 말씀드린 자기검열은 제 실수를 파악하는 데 많은 도움을 줄 것입니다. 다른 사람과 커뮤니케이션을 나누기 전에 신뢰를 지키는 데에도 도움이 되겠죠.


가짜 숫자만 만들지 않는다면, 앞으로는 더 잘할 일뿐입니다.


원문: Peter의 브런치


이 콘텐츠에 대해 어떻게 생각하시나요?