HR 시스템의 범위는 어디까지인가

몇 년 전, HR 시스템 구축 프로젝트의 과업 목록에서 이런 항목을 봤다.

시즌별 콘도 사용 접수 및 추첨 기능.

처음엔 잘못 본 줄 알았다. 콘도 추첨이 왜 인사 시스템에 들어오지.

그때의 판단

사연은 이랬다. 복리후생으로 제공되는 콘도를 성수기마다 임직원들이 신청하는데, 신청자가 정원을 넘으니 추첨이 필요했다. 그런데 추첨 방식이 단순 무작위가 아니었다. 지난 당첨 이력이며 신청 횟수 같은 것이 얽혀 있었다. 수기로 돌리자니 형평성 시비가 붙었고, 그래서 시스템으로 넘기자는 요청이 올라온 것이다.

이유는 납득이 됐다. 그런데도 계속 걸렸다. 이건 HR이 할 일이 아닌 것 같은데. 총무 시스템이나 그룹웨어에 있어야 하는 것 아닌가.

과업 범위 안에 있었으니 만들기는 만들었다. 다만 만드는 내내 그 생각이 사라지지 않았다.

나는 무엇을 기준으로 판단했나

한참 시간이 지나 그때의 판단을 돌아보다가, 내가 무의식적으로 쓰고 있던 기준을 발견했다.

발령, 급여, 근태, 평가. 내가 HR이라고 여겼던 것들에는 공통점이 있었다. 전부 처리해야 하는 일이라는 점이다. 발령은 문서가 남아야 하고, 급여는 계산해서 지급하고 신고해야 하고, 근태는 법이 기록을 요구하고, 평가는 보상으로 이어진다. 하지 않으면 문제가 생기는 일들이다.

콘도 추첨은 그렇지 않았다. 안 해도 법에 걸리지 않고, 돈이 어긋나지도 않고, 문서가 남지 않아도 그만이다. 그래서 내 머릿속 기준에서 미끄러졌다.

그 기준은 어디서 왔는가

이건 나만의 기준이 아니었다. HR 시스템의 범위는 오랫동안 그렇게 그어져 왔다.

인사, 조직, 근태, 채용, 평가, 보상, 복리후생. 익숙한 목록이다. 그런데 이 목록이 왜 이렇게 생겼는지 따져보면 상당 부분이 법과 회계가 요구한 결과다. 근로기준법이 근태 기록을 요구했고, 소득세법이 원천징수를 요구했고, 4대보험이 자격 관리를 요구했다. 여기에 인사팀의 업무 분장이 겹쳐지면서 지금의 구조가 만들어졌다.

즉 HR 시스템의 범위는 ‘사람에 관한 것’이 아니었다. ‘사람에 관한 것 중에서 처리해야 하는 것’이었다.

처리 의무가 없는 일은 자연스럽게 밖으로 밀려났다. 콘도 추첨처럼.

생각이 바뀐 지점

지금은 그때의 판단이 틀렸다고 생각한다.

콘도 신청은 임직원이 스스로 시스템에 무언가를 남기는 몇 안 되는 순간이었다. 언제 쉬고 싶어 하는지, 누구와 함께 가는지, 몇 년째 신청만 하고 못 갔는지. 신청서 한 장에 그런 것들이 담긴다.

그리고 이 기록은 다른 데이터와 곧바로 이어진다. 콘도 당첨과 휴가 신청이 연결되면 임직원은 같은 내용을 두 번 입력할 필요가 없고, 인사팀은 성수기 휴가 집중도를 미리 안다. 복리후생 사용 이력이 쌓이면 어떤 제도가 실제로 쓰이고 어떤 제도가 이름만 남았는지도 보인다.

지난 글에서 임직원이 소비만 하는 시스템을 이야기했다. 요청하고, 조회하고, 제출한다고. 콘도 신청은 그중 ‘요청’에 속하지만 남는 것이 있다는 점에서 결이 다르다. 사소해 보이던 접점이 실은 몇 안 되는 생산의 순간이었던 것이다.

내가 그때 들이댔던 기준으로 보면 이건 여전히 HR이 아니다. 처리할 의무가 없으니까. 하지만 사람이 조직에서 겪는 일을 기준으로 보면 명백히 HR이다.

수기가 더 편하다는 말

이직한 회사에서도 같은 일을 하고 있었다. 다만 오프라인으로.

운영을 맡은 입장에서 시스템화를 제안했다. 돌아온 답은 수기가 더 편하다는 것이었다.

이 말은 곱씹어 볼 만하다. 수기가 편하다는 건 대개 예외가 많다는 뜻이다. 규칙으로 정리되지 않는 경우가 계속 생기니 사람이 그때그때 판단하는 편이 빠른 것이다. 그리고 예외가 많다는 건 조직이 그 예외를 허용해 왔다는 뜻이기도 하다.

시스템화가 막힌 이유는 기술이 아니라 문화였다. 범위를 넓히는 일이 늘 기능 개발의 문제만은 아니라는 걸 그때 알았다.

그래서, 허브

여기까지 오면 결론이 하나 나온다. HR 시스템의 범위를 처리 의무가 아니라 사람의 경험을 기준으로 다시 긋자는 것.

다만 이건 HR 시스템이 모든 것을 직접 만들어야 한다는 뜻이 아니다. 그럴 필요도 없고 가능하지도 않다.

임직원이 일하면서 남기는 기록은 이미 여기저기 흩어져 있다. 협업 도구에 대화가 있고, 이슈 트래커에 완료한 업무가 있고, 문서 도구에 산출물이 있고, 학습 플랫폼에 이수 이력이 있다. 데이터는 이미 존재한다. HR 시스템이 그것을 모르고 있을 뿐이다.

그렇다면 HR이 할 일은 생산이 아니라 연결이다. 흩어진 기록을 가져와 한 사람의 시간축 위에 올려놓는 것. 직접 데이터를 만들지 않아도 된다. 허브 역할이면 충분하다.

그런데, 미끼

여기서 멈추면 이 글은 순진한 글이 된다.

다른 사례를 하나 꺼내야겠다. 어느 회사에서 시스템 운영을 하던 시절, 현업으로부터 기능 요청을 받았다. 임직원이 본인의 현재 퇴직금을 조회할 수 있게 해달라는 것이었다.

좋은 기능처럼 보였다. 인터넷 계산기로도 대략은 나오지만 HR 시스템은 실제 임금 데이터를 갖고 있으니 훨씬 정확하다. 임직원 편의를 위한 기능. 그렇게 이해했다.

나중에 알게 된 요청의 배경은 달랐다. 이 기능의 사용 현황을 뽑아 누가 얼마나 자주 자기 퇴직금을 확인했는지 보려는 것이었다. 퇴직금을 자주 계산해 보는 사람은 퇴사를 고민하는 사람일 확률이 높으니까.

기능 자체에는 아무 문제가 없었다. 문제는 그 기능이 무엇을 위해 존재하는지 임직원만 몰랐다는 점이다.

허브와 감시를 가르는 선

이 사례가 말해주는 건 명확하다. 데이터를 모으는 행위 자체는 중립이 아니다.

임직원의 활동 기록을 HR로 모으자는 주장은 방향을 잘못 잡으면 그대로 감시 시스템의 설계도가 된다. 첫 글에서 이야기했던 ‘자원으로서의 인간’이 훨씬 정교한 모습으로 돌아오는 것이다. 자원을 잘 관리하려면 자원의 상태를 잘 알아야 하니까.

그래서 조건이 필요하다. 세 가지라고 생각한다.

본인이 볼 수 있는가. 모인 데이터를 정작 본인은 못 보고 인사팀만 본다면 그건 허브가 아니라 저장소다.

무엇이 왜 모이는지 아는가. 퇴직금 사례가 걸린 지점이 여기다. 데이터가 모인다는 사실보다 그 목적이 감춰졌다는 것이 문제였다.

본인에게도 쓸모가 있는가. 회사만 쓰는 데이터라면 임직원 입장에서는 입력 노동이 하나 늘어난 것에 지나지 않는다.

지난 글에서 임직원이 남긴 기록의 소유가 어느 방향을 향하는지를 기준으로 삼았다. 같은 칼날이 여기서도 쓰인다. 범위를 넓히는 일은 더 많이 모으는 일이 아니라, 모인 것이 누구에게 돌아가는지를 정하는 일이다.

다시, 범위

콘도 추첨 기능을 만들던 그때의 나에게 지금의 내가 답을 준다면 이렇게 말할 것 같다.

그 기능이 HR에 있어야 하느냐는 질문은 틀렸다. 물어야 할 것은 그 기록이 누구의 것으로 남느냐다. 임직원에게 돌아간다면 HR이고, 회사에만 쌓인다면 어디에 두든 상관없다.

범위를 넓히자는 말은 더 많은 모듈을 붙이자는 뜻이 아니다. 선을 다시 긋자는 뜻이다. 처리해야 할 것과 그렇지 않은 것 사이가 아니라, 사람에게 돌아가는 것과 그렇지 않은 것 사이로.