09. 완벽한 시스템은 없다

문제 제기: 장애가 없는 날의 착각

서비스가 몇 달째 안정적으로 돌아간다. 모니터링 화면은 초록색이고, 장애 알림은 조용하다. 팀은 회고에서 말한다. 이제 꽤 완벽해진 것 같습니다. 그 말이 나온 지 일주일 뒤, 한 지역의 통신 장애로 결제 서비스가 멈춘다. 재해 복구 환경은 있었지만, 마지막으로 점검한 지 오래되었다. 자동 전환은 작동했지만 오래된 인증서 하나가 연결을 거부했다. 복구 과정에서 고객 데이터의 중복 결제가 발생했고, 상담센터에는 같은 질문이 쏟아졌다.

장애는 갑자기 나타난 것처럼 보이지만, 대부분은 갑자기 만들어지지 않는다. 작은 예외들이 쌓이고, 아무도 소유하지 않는 수동 절차가 남고, 성공한 날들의 통계가 실패할 수 있는 조건을 가린다. 시스템이 완벽해졌다는 믿음은 결함보다 위험하다. 그것은 더 이상 의심하고 시험할 이유가 없다고 말하기 때문이다.

철학적 논점: 완벽함이 아니라 취약성의 인식

우리는 시스템을 닫힌 기계처럼 상상한다. 입력이 들어오고, 정해진 규칙에 따라 출력이 나오며, 충분히 좋은 설계를 하면 예측 가능한 상태를 유지할 것이라고 믿는다. 그러나 실제 시스템은 사람과 조직, 외부 서비스, 법과 시장, 날씨와 우연이 얽힌 열린 구조다. 경계 밖에서 일어난 사건이 언제든 안으로 들어온다.

철학은 완벽한 통제라는 환상을 멈춰 세운다. 중요한 것은 실패를 없애는 것이 아니라 실패가 어떤 모양으로 나타날지 상상하고, 실패 뒤에도 사람들이 회복할 수 있게 하는 것이다. 여기에는 기술적 의미의 회복탄력성만 있는 것이 아니다. 누가 결정을 되돌릴 수 있는가, 누가 오류를 설명받는가, 누가 보상받는가, 누가 다시 시도할 기회를 얻는가라는 질문이 함께 있다.

완벽함을 추구하는 조직에서는 나쁜 소식이 늦게 올라온다. 지표가 깨끗해야 하고, 계획은 예정대로 진행되어야 하며, 실수는 개인의 부주의로 정리된다. 반대로 취약성을 인정하는 조직에서는 이상한 로그와 불편한 사용자 제보가 귀찮은 방해가 아니라 시스템을 배우는 입력이 된다. 안전은 결함이 없는 상태가 아니라 결함을 숨기지 않아도 되는 상태에 더 가깝다.

공학의 장면: 추천 시스템의 조용한 편향

동영상 플랫폼의 추천팀은 이용자 체류 시간을 높이는 모델을 운영하고 있었다. 모델은 사용자가 오래 머무는 영상을 더 자주 보여 주었고, 전체 지표는 꾸준히 올랐다. 어느 날 운영자는 특정 주제의 과격한 영상이 일부 이용자에게 반복 노출되고 있다는 신고를 받았다. 모델은 규정을 직접 위반하지 않는 영상들을 연결했을 뿐이었다. 각각의 추천은 작은 관심의 연장이었지만, 긴 사슬 끝에서 사용자는 처음 예상하지 못한 정보 환경 안에 갇혔다.

팀은 즉시 모델을 폐기하지 않았다. 그렇게 하면 유용한 추천까지 사라지고, 이용자들이 스스로 원하는 콘텐츠를 찾는 비용이 커질 수 있었다. 대신 추천 이유를 일부 노출하고, 관심사 초기화와 피드 전환 기능을 눈에 띄게 배치했으며, 체류 시간 외에 반복 노출과 주제 편중을 감시하는 지표를 추가했다. 특정 유형의 콘텐츠가 급격히 연쇄 추천될 때는 자동으로 속도를 늦추고 사람의 검토를 거치게 했다.

이 조치들은 완벽한 해결책이 아니다. 악용될 수 있고, 새로운 편향을 만들 수 있으며, 모든 이용자의 경험을 설명하지도 못한다. 하지만 시스템이 자신의 한계를 드러내고 사용자가 개입할 통로를 갖는다는 점에서 이전과 다르다. 완벽한 추천을 약속하는 대신, 추천이 틀릴 수 있다는 사실을 제품의 일부로 만든 것이다.

반론과 긴장: 불확실성을 핑계로 삼지 않기

완벽하지 않다는 말은 두 방향으로 사용된다. 하나는 겸손한 설계의 출발점이다. 다른 하나는 책임을 피하는 방패다. 어차피 완벽할 수 없으니 출시하자는 말, 모든 시스템에는 오류가 있으니 어쩔 수 없다는 말은 실패의 비용을 사용자에게 넘길 때 자주 등장한다.

불완전함을 인정한다는 것은 기준을 낮추는 일이 아니다. 오히려 어떤 실패를 허용하지 않을지 더 선명하게 정하는 일이다. 결제 오류가 발생해도 자동 환불이 되도록 하고, 의료 조언 시스템은 확신이 낮을 때 사람에게 넘기며, 계정 정지는 즉시 영구 처분이 아니라 재검토 가능한 임시 상태로 두는 식이다. 모든 것을 막을 수 없다면, 적어도 되돌릴 수 없는 피해를 줄이고 잘못된 판단을 수정할 시간을 확보해야 한다.

이를 위해서는 장애 훈련, 카오스 테스트, 감사 로그, 롤백 버튼 같은 기술이 필요하다. 그러나 도구만으로는 충분하지 않다. 누군가 알림을 보고 실제로 멈출 수 있는 권한을 갖고 있는지, 운영자가 새벽에 판단할 수 있는 문서와 연락망이 있는지, 장애를 보고한 사람이 처벌받지 않는지까지 시스템의 일부로 보아야 한다. 견고한 구조는 강철처럼 단단한 구조가 아니라, 압력을 받았을 때 어디가 휘는지 알고 있는 구조다.

마무리 질문

당신의 시스템이 실패한다면 첫 번째로 흔들리는 것은 무엇인가. 데이터인가, 신뢰인가, 특정 사용자의 삶인가. 그리고 그 실패를 숨기지 않고 드러내며, 사람이 다시 선택할 수 있게 하는 장치는 어디에 있는가. 완벽해 보이는 시스템을 만드는 대신, 불완전한 세계에서도 회복할 수 있는 시스템을 만들고 있는지 물어야 한다.