유연의 대가

다양한 평가표

평가 시스템을 구축하면서 알게 된 사실이 하나 있다. 평가표는 하나가 아니다.

솔루션에 기본으로 들어 있는 평가 모듈은 대체로 하나의 평가표를 전제한다. 그런데 현실은 그렇지 않았다. 영업직과 생산직이 같은 항목으로 평가받을 수 없고, 계열사마다 보는 기준이 다르고, 직군이 다르면 쓰는 말부터 달랐다.

이 간극을 어떻게 메울 것인가. 그게 이 글의 출발점이다.

그때까지의 두 가지 방법

방법은 둘 중 하나였다.

하나는 통일하도록 설득하는 것이다. 전사가 같은 평가표를 쓰도록 가이드하고, 예외는 받지 않는다. 깔끔하지만 현업이 받아들이지 않는다. 영업 조직에 생산 조직의 평가 항목을 들이밀면 당연히 반발이 나온다.

다른 하나는 필요한 만큼 만들어두는 것이다. 요구받은 레이아웃을 각각 화면으로 구현해서 직군별로 다른 화면을 띄운다. 현업은 만족하지만 뒷감당이 생긴다.

쓰이지 않는 화면이 쌓이기 때문이다.

제도가 바뀌면 그중 몇 개는 더 이상 쓰이지 않는다. 그런데 안 쓴다고 해서 지우지는 않는다. 혹시 모르니까, 나중에 다시 쓸지 모르니까. 그렇게 죽은 메뉴가 시스템에 남는다.

실제로 겪은 일이 있다. 예전에는 인사팀이 직급별로 성과와 역량 요소를 미리 세팅해주는 방식을 썼다. 목표 등록 단계부터 인사팀의 작업이 필요한 구조였다. 이후 MBO로 바뀌면서 목표 등록 방식이 두 가지가 됐고, 한동안은 둘을 같이 운영하기도 했다.

지금은 MBO만 쓴다. 그런데 예전 메뉴가 그대로 열려 있다. 그래서 가끔 누군가 엉뚱한 곳에 들어가 작업을 한다.

죽은 기능은 조용히 사라지지 않는다. 남아서 가끔 사람을 잘못된 곳으로 데려간다.

그래서 유연하게 만들었다

세 번째 방법을 택했다.

평가표를 화면으로 고정하는 대신, 설정으로 구성할 수 있게 바꾼 것이다. 어떤 항목을 넣을지, 몇 단계로 진행할지, 누가 무엇을 보고 쓸지를 미리 정해진 화면이 아니라 데이터로 정의하는 방식이다.

결과는 좋았다. 직군별로, 부서별로 서로 다른 평가표를 보여줄 수 있게 됐다. 현업이 원하는 구성을 대부분 맞출 수 있었고 만족도도 높았다. 새 요구사항이 와도 개발 없이 설정만 바꾸면 됐다.

여기까지는 성공이었다.

청구서는 나중에 왔다

설계가 복잡해졌다. 유연해진 만큼 설정할 것이 늘었고, 설정끼리 서로 영향을 주기 시작했다. 어디를 건드리면 어디가 달라지는지를 알아야 설정을 할 수 있는 상태가 됐다.

원래 의도가 뒤집혔다. 처음 목표는 개발 지식이 없는 현업도 직접 설정할 수 있게 하는 것이었다. 그런데 설정이 너무 복잡해져서 결국 개발을 아는 사람이 붙어야 했다. 자율화하려다 의존을 만든 셈이다. 그리고 그 부담은 운영 쪽으로 갔다.

매번 처음부터 다시 해야 했다. 평가를 시작할 때마다 설정 작업이 필요했다. 작년과 거의 같은 방식으로 진행하는 해에도 마찬가지였다. 유연함이 반복 노동으로 돌아왔다.

그리고 잊어버린다. 평가는 1년에 한 번이다. 아무리 교육해도 다음 해에는 기억이 남아 있지 않다. 이건 쓰는 사람을 탓할 일이 아니다. 1년에 한 번 쓰는 도구의 숙명이다.

편의를 위해 만든 것이 폭탄이 되다

반복 작업이 부담이니 당연히 개선을 생각했다. 지난 평가의 설정을 이번 평가로 복사하는 기능을 만들었다.

효과는 분명했다. 작년과 거의 같은 평가라면 현업이 복사 한 번으로 설정을 끝낼 수 있었다. 운영이 개입하지 않아도 평가가 돌아가기 시작했다. 바라던 그림이었다.

그런데 사고가 났다.

복사의 방향을 반대로 설정한 것이다. 이번 평가의 설정을 지난 평가 쪽으로 덮어씌운 셈인데, 문제는 그 지난 평가가 이미 마감된 평가였다는 점이다.

한 번은 설정만 날아갔다. 다행히 그해 설정이 이전 평가와 거의 같아서, 다른 평가의 설정을 참고해 복원할 수 있었다.

다른 한 번은 평가 내역 전체가 날아갔다. 이건 복원할 방법이 없어서 DB 백업본을 꺼내야 했다. 타 부서의 도움이 필요했고, 적지 않은 공수가 들었다.

이후 검증 로직을 넣었다. 그런데 그 검증을 우회하는 경우가 또 있어서, 지금도 이 기능은 조마조마한 마음으로 쓰고 있다.

편의를 위해 만든 기능이 사고 요소를 품은 폭탄이 된 것이다.

그런데 현업도 완전히 만족하지는 않았다

여기까지가 만든 쪽이 치른 비용이다. 그렇다면 그 비용을 치르고 현업은 원하는 것을 다 얻었을까.

그렇지 않았다.

설정으로 구성한다고 해도 표현에는 한계가 있다. 미리 정해둔 틀 안에서 조합하는 것이지, 무엇이든 만들 수 있는 게 아니다. 그래서 현업은 여전히 “이건 왜 안 되냐”고 물었다.

양쪽 모두 손해를 본 구조다. 운영은 복잡도와 사고 위험을 떠안았고, 현업의 불만은 줄었을 뿐 사라지지 않았다.

바꾸기 쉬워지면 더 자주 바꾼다

지난 글에서 평가 제도가 매년 조금씩 바뀐다는 이야기를 하면서, 바꾸기 쉬워지면 더 자주 바꾸게 된다고 썼다. 유연한 시스템이 변경의 문턱을 낮췄다는 뜻이었다.

여기에 한 가지를 덧붙여야겠다. 유연성을 요구하는 쪽과 그 비용을 치르는 쪽이 다르다. 요구는 현업이 하고, 설계는 개발이 하고, 비용은 운영이 치른다. 결정하는 자리와 부담지는 자리가 떨어져 있으면 요구는 계속 늘어난다.

그리고 이 글에서 이야기한 비용들은 전부 뒤늦게 나타난다. 설정이 복잡해지는 것도, 매년 다시 배워야 하는 것도, 편의 기능이 사고를 부르는 것도 요구사항을 받던 그 자리에서는 보이지 않는다.

그래서 고정이 답인가

여기까지 쓰고 보니 결론이 하나로 기우는 것 같다. 현업이 혼자서도 설정할 수 있고 요구사항도 전부 충족하는 프레임워크를 만들 수 없다면, 차라리 솔루션에서 프로세스를 고정하는 편이 나을 수 있다는 것.

실제로 그렇게 생각한다. 다만 고정이 언제나 옳다고 말하고 싶지는 않다. 어디까지 열어두고 어디부터 닫을지는 조직과 제도에 따라 달라진다.

확실한 건 하나다. 유연성은 공짜가 아니다. 열어둔 만큼 누군가는 그 복잡도를 감당해야 하고, 그 사람은 대개 설계를 결정한 사람이 아니다.

알려진 리스크는 리스크가 아니다

지금 그 설계를 하던 시점으로 돌아간다면, 나는 다르게 하지 않을 것 같다. 아마 같은 선택을 할 것이다.

다만 한 가지는 다르게 하겠다. 요구사항을 받을 때 운영상의 리스크를 함께 이야기하겠다.

이렇게 유연하게 만들면 설정이 복잡해진다. 복잡해지면 현업 혼자 하기 어려워진다. 1년에 한 번 쓰는 기능은 매년 다시 배워야 한다. 편의 기능을 더하면 사고 가능성도 같이 늘어난다.

그때의 나는 이걸 예상하지 못했다. 역량이 부족해서였다. 요구사항을 어떻게 구현할지는 고민했지만, 그 구현이 몇 년 뒤 어떤 부담으로 돌아올지는 생각하지 못했다.

리스크를 알고 선택하는 것과 모르고 선택하는 것은 전혀 다르다. 알고 선택하면 대비할 수 있고, 적어도 나중에 누구를 탓하지 않는다.

컨설턴트가 필요한 이유가 여기에 있다고 생각한다. 요구사항을 정리해주는 사람이 아니라, 그 요구사항이 몇 년 뒤 무엇으로 돌아오는지를 말해주는 사람. 좋은 설계를 그려주는 사람보다, 이 설계의 청구서가 언제 누구에게 날아갈지 알려주는 사람이 더 필요할 때가 있다.