개발 일을 오래 하다 보면 나도 모르게 모든 일을 코드처럼 보고 싶어질 때가 있다. 화면 안의 세계는 비교적 친절하다. 문법은 정해져 있고, 타입은 선언되어 있고, 같은 입력을 넣으면 같은 결과가 나와야 한다. 어제 재현되던 버그가 오늘 갑자기 재현되지 않는다면, 그건 보통 원인이 없어서가 아니라 내가 아직 못 찾은 것이다. 어딘가에는 이유가 있다.
그래서 개발자는 논리적인 사고에 익숙해진다. 문제를 쪼개고, 원인을 추적하고, 조건을 명시하고, 반례를 확인한다. 이 훈련은 대체로 옳다. 코드를 다루는 일에서는 거의 필수에 가깝다. 문제는 그 감각이 모니터 바깥으로 그대로 넘어올 때 생긴다.
기술을 도입할지 말지, 어느 요구사항을 먼저 처리할지, 지금 이 조직에서 어떤 선택이 장기적으로 더 나을지 같은 문제는 코드처럼 얌전하지 않다. 변수는 너무 많고, 중요한 정보는 늦게 오거나 아예 오지 않는다. 의사결정은 충분한 데이터가 모일 때까지 기다려주지도 않는다. 기다리다 보면 결정하지 않은 것 자체가 결정이 되어버린다.
이런 자리에서 휴리스틱이 나온다. 휴리스틱이라고 하면 괜히 학술적인 말처럼 들리지만, 사실은 복잡한 문제를 빨리 다루기 위한 사고의 지름길에 가깝다. 모든 변수를 다 계산하지 못하는 상황에서 일단 쓸 만한 답에 도달하기 위한 규칙. 대충 찍는다는 말과 비슷해 보이지만, 꼭 그렇지는 않다. 최적화를 포기하는 것이지 사고를 포기하는 것은 아니니까.
여행 계획 하나만 세워도 그렇다. 교통비, 이동 시간, 체력, 날씨, 동선, 감정적 만족감, 동행인의 취향을 전부 계산해 최적해를 구하는 사람은 별로 없다. 그렇게 할 수도 없다. 보통은 이 정도면 괜찮겠다 싶은 안을 고른다. 최선은 아니어도 충분히 괜찮은 답.
개발자도 휴리스틱을 자주 쓴다. 단지 그걸 휴리스틱이라고 부르지 않을 뿐이다. 새로운 기술을 검토할 때 공식 문서도 보고, 벤치마크도 보고, 레퍼런스 아키텍처도 본다. 그런데 마지막에 마음이 기우는 순간에는 과거에 비슷한 도구를 도입했다가 고생했던 기억, 팀이 감당할 수 있는 복잡도, 지금 조직의 운영 성숙도 같은 것들이 끼어든다. 겉으로는 기술 검토인데, 안쪽에서는 경험을 압축한 판단이 꽤 크게 움직인다.
코드 작성이나 디버깅, 비교적 정형화된 설계에서는 논리가 힘을 낸다. 반면 기술 선택, 우선순위 조정, 조직 협업, 제품 방향성 같은 문제에서는 휴리스틱이 자꾸 호출된다. 팀원과 매니저의 일에서도 비슷한 차이를 본다. 팀원은 명확한 제약 안에서 정답에 가까운 해를 찾는 일을 많이 하고, 매니저는 정보가 부족한 상태에서 여러 이해관계와 변수를 안고 결정을 내려야 한다. 물론 이렇게 딱 잘라 말하기도 어렵다. 팀원도 기술 도입 앞에서는 휴리스틱을 쓰고, 매니저도 지표를 해석할 때는 논리를 써야 한다. 현실은 늘 이런 식으로 애매하게 섞인다.
잘 길들여진 휴리스틱은 연장통과 비슷하다. 모든 문제를 해결하는 멋진 기계를 들고 다니는 게 아니라, 자주 마주치는 문제를 빨리 처리할 수 있는 투박한 도구 몇 개를 넣어두는 쪽에 가깝다. 이 도구들은 완벽하지 않다. 대신 빠르다. 그리고 많은 경우에는 그 빠름 자체가 가치가 된다. 정보가 불완전하고 시간이 제한된 상황에서 모든 변수를 붙잡고 있으면, 판단이 정교해지기 전에 기회가 지나가버린다.
물론 휴리스틱을 너무 좋게만 볼 수는 없다. 휴리스틱은 대개 편향을 같이 데려온다. 가용성 휴리스틱은 머릿속에 쉽게 떠오르는 사례를 실제보다 더 큰 위험처럼 느끼게 만든다. 최근에 본 장애 사례 하나가 강하게 남아 있으면, 비슷한 위험을 필요 이상으로 크게 본다. 앵커링 휴리스틱이라 부르는 것도 있다. 처음 접한 숫자나 기준이 이후 판단의 중심축이 되어버리는 일. 대표성 휴리스틱은 어떤 대상이 내가 가진 전형적인 이미지와 닮았다는 이유만으로 성격이나 결과를 성급히 짐작하게 만든다.
감정도 꽤 자주 끼어든다. 어떤 기술이나 팀, 브랜드, 사람에 대해 이미 좋은 감정이나 나쁜 감정이 있으면, 그 감정이 이후 평가를 조용히 밀어버린다. 문제는 내가 밀리고 있다는 사실을 스스로 잘 모른다는 점이다. 통제의 환상이나 사후판단편향도 만만치 않다. 운이 좋았던 결과를 내 실력의 증거로 착각하거나, 결과를 알고 난 뒤에 “원래 그렇게 될 줄 알았다"고 믿는 것. 이런 일이 몇 번 쌓이면 사람은 자기 판단을 의심하지 않게 된다.
그럼 다시 모든 판단을 알고리즘처럼 돌리면 되느냐. 그럴 수 있으면 좋겠지만 현실은 그렇게 생기지 않았다. 완전한 정보도 없고, 충분한 시간도 없고, 내 머리도 그렇게 넉넉하지 않다. 그래서 필요한 것은 휴리스틱을 없애는 일이 아니라, 내가 어떤 휴리스틱을 쓰고 있는지 알아차리는 일에 가까운 것 같다.
좋은 직관을 가진 사람과 이상한 판단을 반복하는 사람의 차이도 여기서 갈리는 것 같다. 휴리스틱을 쓰느냐 마느냐의 문제가 아니다. 어떤 경험을 압축했고, 그 압축이 어떤 상황에서 잘 맞았고, 어디서 자주 빗나갔는지를 알고 있느냐의 문제다. 같은 일을 오래 했다는 사실만으로 직관이 좋아지지는 않는다. 오래 했는데 계속 이상한 방향으로만 배우는 사람도 있다.
그래서 기록과 복기가 필요하다. 어떤 판단을 왜 내렸는지, 그때 중요하게 본 단서는 무엇이었는지, 결과는 어땠는지 남겨두면 나중에 자기 판단의 모양이 조금 보인다. 기록은 사후판단편향을 줄이는 데에도 도움이 된다. 사람은 생각보다 쉽게 과거의 자신을 미화한다. “그때도 나는 알고 있었다” 같은 말은 대개 거짓말이다.
반증을 찾는 습관도 중요하다. 첫 판단은 빠르게 나온다. 빠르게 나온다는 건 장점이지만, 맞는다는 뜻은 아니다. 중요한 결정일수록 내 판단과 반대되는 증거를 일부러 찾아봐야 한다. 혼자서 잘 안 되면 다른 사람을 끌어들이는 게 낫다. 팀의 판단이 항상 옳다는 뜻은 아니다. 다만 한 사람의 확증편향을 조금 누그러뜨릴 가능성은 있다.
카너먼이 말한 시스템 2 도 라는 것도 이 대목에서 떠오른다. 빠르고 자동적인 첫 판단 뒤에 들어오는 느리고 의식적인 검토. 모든 결정에 시스템 2를 들이밀 필요는 없다. 점심 메뉴 고르는데 그렇게까지 하면 피곤해서 못 산다. 그래도 비용이 큰 결정이라면 잠깐 멈춰볼 필요가 있다. 지금 내 판단이 직관인지, 논리인지, 아니면 직관이 논리의 탈을 쓰고 들어온 것인지. 이 구분이 생각보다 어렵다.
휴리스틱을 이야기한다고 해서 논리를 버리자는 말은 아니다. 오히려 반대에 가깝다. 논리는 여전히 중요하다. 다만 논리만으로 모든 문제를 다룰 수 있다는 믿음이 조금 위험하다는 쪽에 가깝다. 어떤 문제는 코드처럼 닫혀 있고, 어떤 문제는 사람과 조직과 시간이 뒤엉켜 있다. 그리고 대부분의 문제는 그 중간 어딘가에 있다.
휴리스틱은 지름길이다. 지름길이라는 말에는 늘 약간의 의심이 따라붙는다. 괜히 돌아가는 길보다 더 위험한 것 아닌가 싶고, 실제로 그럴 때도 많다. 그래도 잘 닦아둔 지름길은 우리를 더 빨리, 더 적은 비용으로 목적지 근처까지 데려다준다. 개발자에게 필요한 건 아마 자기 연장통 안에 어떤 지름길이 들어 있는지, 그 지름길이 어디서 자주 끊기는지 가끔 꺼내보는 일일 것이다. 귀찮지만, 안 보면 또 금방 까먹는다.