“생각에 관한 생각”이라는 책을 보면 손실 회피라는 개념이 나온다. 인간은 이득보다 손실에서 더 큰 심리적 고통을 느끼기 때문에 손실을 피하다가 오히려 비합리적인 선택을 하곤 한다는 것이다.
실험의 예시는 이렇다. 도박 실험이라는 것이 있는데, 참가자는 “확실히 900달러를 잃는 것”과 “90% 확률로 1000달러를 잃고, 10% 확률로 아무것도 잃지 않는 것” 중 하나를 선택한다. 두 선택 모두 같은 기댓값이라는 것을 쉽게 알 수 있지만, 실험 결과를 보면 후자를 선택하는 사람들이 더 많았다고 한다. 이 실험 외에도 보험 실험과 같이 오히려 기댓값이 더 낮은 선택을 하는 결과를 보인 실험들도 볼 수 있다.
나는 이러한 손실 회피 개념이 개발에도 적용된다고 생각한다.
대표적인 예시로 간단한 백오피스 개발과 같은 자동화를 생각해 볼 수 있다. 자동화를 하고 나면 매번 요청을 받아서 손으로 직접 작업해 주던 것을 하지 않아도 되므로 생산성에 큰 도움이 된다. 요청의 처리 자체는 간단하더라도 요청을 하는 사람과 받는 사람의 커뮤니케이션 비용이나 컨텍스트 스위칭 비용을 생각하면 효용이 작지 않다.
근데 곰곰이 생각해 보면 자동화를 선뜻 하지 않는 경우가 많은데, 그 이유가 뭘까? 나는 대표적인 이유 2가지가 있다고 생각한다. 첫 번째는 자동화를 위한 코드를 작성하는 투자 비용과 요청을 손으로 직접 처리해 주는 비용의 임계점에 대한 고려다. 코드를 작성하는 데에는 일정 시간이 들기 때문에 간단한 요청이면 직접 처리하는 게 더 싸다고 생각하기 때문이다. 두 번째는 유지보수 과정에서 자동화 코드에서 버그가 발생할 가능성이다. 서비스를 계속 개발하다 보면 내부 구조를 변경하는 일들도 종종 생기는데 중요한 변경 사항을 프로덕션에는 적용했지만 자동화 코드에는 반영하지 않았다면 추후 버그가 발생할 수 있다.
자동화를 잘 하지 않는 이유는 위 두 가지 이유에 의한 것이라고 생각한다. 자동화를 위한 코드를 작성하느라 시간을 썼는데 나중에는 별로 활용되지 않는다거나, 혹은 자동화를 위해 코드를 작성해 뒀는데 나중에 미처 챙기지 못해서 버그가 발생하는 손실을 회피하려다 보니 자동화 덕분에 얻을 수 있는 생산성 향상을 얻질 못한다.
더 나아가서는 개발뿐만 아니라 프로덕트 측면에서도 비슷한 생각을 해볼 수 있다.
프로덕트 개발 초기를 생각해 보면 기능 추가 혹은 변경 시 더 과감하다. 잘 몰라서 그런 것일 수도 있지만 아마 손실이 크지 않다고 생각해서 그런 것도 클 것이다. 프로덕트 초기에는 기존 사용자가 별로 없기 때문에 기능 추가 혹은 변경으로 인해 기존 유저의 불만족 혹은 이탈과 같은 손실도 작다고 생각한다.
하지만 점점 프로덕트가 성숙해지면서 기존 사용자가 많아지면 그들의 불만족과 이탈도 더 커진다. 똑같이 1%의 사용자가 불편하게 느끼더라도 모수가 100명이면 1명만 불편하지만 10000명이면 100명이 불편한 것이니 불편한 사람 수는 훨씬 많아지는 게 맞다.
그 변경으로 인해 편해지거나 오히려 더 프로덕트를 좋아하게 될 사람도 분명 있을 것이다. 다만 이 이득과 손실을 따지기는 쉽지 않다. 그러다 보니 점점 더 변화를 조심하게 된다.
나는 어떤 판단에 있어 객관적으로 잘 판단하는 게 중요하다고 생각한다. 그리고 손실 회피 때문에 이득과 손실의 총합을 따졌을 때 손실이 있다는 이유로 이득을 포기하는 것은 지양해야 한다고 생각한다.
물론 이득이 손실보다 조금만 더 높아도 취해야 한다는 것은 절대 아니다. 항상 이득과 손실을 1:1의 비율로 봐야 한다고 생각하진 않는다. 하지만 일을 하다 보면 손실을 매우 크게 느껴서 어지간히 크게 이득이 아니면 아예 하지 않아 버리는 경우를 자주 볼 수 있다. 그러다 보면 결국 정체하고 어떤 것도 하지 못하고 만다. 그래서 나는 의사 결정을 할 때 의도적으로 내가 손실 회피를 하고 있는 것은 아닌지에 대한 생각을 해보곤 한다.
역시 객관적으로 잘 판단하는 것은 어려운 일이다. 하지만 그럴만한 가치는 분명 있다.