07. 가능한 것과 해야 하는 것은 다르다

문제 제기: 버튼 하나가 열어젖힌 문

새로운 기능이 배포되기 직전의 회의실에는 이상한 정적이 흐른다. 개발자는 성능 그래프를 띄워 놓고 말한다. 이제 실시간으로 처리할 수 있습니다. 기획자는 전환율 예측치를 보여준다. 이 기능이 들어가면 이탈률을 줄일 수 있습니다. 운영 담당자는 이미 배포 시간과 롤백 절차를 정해 두었다. 화면 한쪽에는 초록색 버튼이 있다. 배포하기.

기술적으로는 가능하다. 데이터도 있고, 모델도 있고, 서버도 버틴다. 그런데 그 사실만으로 충분할까. 우리가 만들 수 있다는 사실은 우리가 만들어야 한다는 결론으로 곧장 이어지지 않는다. 공학에서 가장 위험한 문장은 때로 가장 자신 있게 말해지는 문장이다. 할 수 있으니까요.

철학은 이 문장 앞에서 잠시 멈춘다. 가능한 것과 해야 하는 것은 어떤 관계인가. 그 사이에 누가 들어가야 하는가. 사용자, 노동자, 지나치게 늦게 발견될 피해자, 그리고 아직 목소리를 갖지 못한 사람까지 포함해야 하는가.

철학적 논점: 사실에서 당위로 건너뛰는 순간

우리는 자주 사실과 가치를 한 문장 안에서 섞는다. 모델이 사람보다 정확하다는 사실에서 모델이 사람을 대신해야 한다는 당위를 끌어낸다. 자동화로 비용을 줄일 수 있다는 사실에서 자동화해야 한다는 결론을 얻는다. 하지만 정확성은 무엇을 정확히 예측하는가를 말해 주지 않고, 효율은 그 효율의 비용을 누가 부담하는지 설명하지 않는다.

공학은 요구사항을 입력받아 시스템을 출력하는 일처럼 보이지만, 실제로는 선택을 고정하는 일이다. 어떤 오류를 허용할지, 누구의 편의를 우선할지, 실패했을 때 누가 설명할지 결정하고 그것을 데이터베이스의 필드와 권한 체계, 알림 규칙, 인터페이스에 새겨 넣는다. 가치 판단을 하지 않는 시스템은 존재하지 않는다. 다만 자신의 가치 판단을 문서화하지 않은 시스템이 있을 뿐이다.

여기서 중요한 질문은 기능이 선한가 악한가가 아니다. 더 불편하고 더 정확한 질문은 이것이다. 이 기능이 만들어 내는 질서에서 사람들은 어떤 선택을 잃는가. 시스템이 대신 판단하는 순간, 사용자는 단지 시간을 절약하는 것이 아니라 판단할 기회를 넘겨준다.

공학의 장면: 채용 모델의 정확도 뒤에 있는 사람

한 회사가 채용 서류를 자동으로 분류하는 모델을 만들었다고 하자. 과거 합격자들의 이력과 면접 결과를 학습한 모델은 인사 담당자보다 빠르고, 일정한 기준으로 지원자를 정리한다. 초기 검증 결과도 좋다. 담당자들의 업무 시간은 줄었고, 서류 검토의 편차도 감소했다.

하지만 몇 달 뒤 한 개발자가 로그를 살펴보다가 이상한 패턴을 발견한다. 특정 대학의 졸업자와 경력 단절 이후 재취업을 시도하는 지원자들이 유난히 낮은 점수를 받고 있었다. 모델은 차별이라는 규칙을 배운 것이 아니다. 회사가 과거에 누구를 채용했고, 그 결과를 무엇이라 기록했는지를 배웠다. 과거의 편향이 숫자의 표정을 하고 돌아온 것이다.

이때 가능한 선택은 많다. 임계값을 조정할 수도 있고, 특성 일부를 제거할 수도 있고, 공정성 지표를 추가할 수도 있다. 그러나 해야 하는 선택은 기술적 조정만으로 정해지지 않는다. 채용 담당자가 모델의 추천을 반드시 따르지 않도록 할 것인지, 탈락한 지원자가 이의를 제기할 수 있도록 할 것인지, 모델을 당분간 쓰지 않을 것인지 결정해야 한다. 정확도 개선만을 목표로 삼으면 가장 중요한 문제를 놓친다. 누가 왜 탈락했는지 아무도 설명할 수 없는 구조가 남기 때문이다.

반론과 긴장: 모든 것을 멈출 수는 없다

물론 모든 위험을 이유로 기술을 중단할 수는 없다. 의료 영상 판독, 재난 예측, 장애인 보조 기술처럼 자동화가 실제로 사람의 삶을 지키는 경우도 있다. 완벽한 확실성을 기다리다 보면 지금 당장 줄일 수 있는 고통을 방치하게 된다. 아무것도 하지 않는 선택도 선택이며, 그 선택 역시 누군가에게 비용을 떠넘긴다.

그래서 필요한 것은 가능성의 거부가 아니라 가능성에 브레이크와 방향을 함께 다는 일이다. 출시 전에 피해 시나리오를 적어 보고, 제한된 범위에서 시험하고, 사용자가 거부하거나 되돌릴 수 있는 장치를 남겨야 한다. 자동화된 결정을 사람이 검토할 수 있게 하는 것만으로 충분하지 않을 때도 있다. 그 사람에게 실제 권한과 시간, 설명할 책임이 주어졌는지까지 설계해야 한다.

공학자는 미래를 예언하는 사람이 아니라 여러 미래 중 하나를 현실로 밀어 넣는 사람이다. 그러므로 코드 리뷰에는 보안 취약점뿐 아니라 힘의 이동도 올라와야 한다. 이 기능으로 더 강해지는 쪽은 누구인가. 오류가 났을 때 침묵을 강요받는 쪽은 누구인가. 배포 버튼을 누를 수 있다는 사실과, 눌러야 한다는 판단 사이에 이런 질문이 놓인다.

마무리 질문

당신이 만들고 있는 시스템은 무엇을 가능하게 하는가. 그리고 더 중요한 질문, 그 가능성 때문에 누군가가 더 이상 거부할 수 없게 되는 것은 무엇인가. 이번 배포에서 우리가 확인해야 할 것은 기능이 작동하는지가 아니라, 작동한 뒤 사람들이 어떤 선택을 여전히 자기 것으로 가질 수 있는지 아닐까.