신뢰성

버그 목록에는 절대 올라오지 않는 불만이 있었습니다. "왠지 못 믿겠어요", "여기에 카드번호를 넣기가 좀 그래요" 같은 말입니다. 화면은 설계대로 동작하고 오류도 나지 않으니 개발자가 고칠 것이 없고, 기능이 빠진 것도 아니니 기획자가 잡을 것도 없었습니다. 그래서 이런 의견은 취향 이야기로 분류돼 회의록 맨 아래에 한 줄로 남았다가 사라졌습니다.

협업 문서 제품에서 이 불편은 이런 모양으로 나타났습니다. 사용자가 긴 문서를 쓰고 저장 버튼을 눌렀는데 화면에 아무 변화가 없습니다. 정말 저장됐는지 확인하려고 새로고침을 한 번 하고, 그러고도 마음이 놓이지 않아 내용을 전부 복사해 메모장에 한 벌 더 붙여 둡니다. 고객센터에는 "저장이 됐는지 모르겠어요" 라는 문의가 매주 쌓이지만, 서버 기록에는 저장이 전부 성공으로 찍혀 있어서 문의는 재현 불가로 닫힙니다. 제품은 멀쩡하고 사용자만 불안한 상태가 몇 달씩 이어집니다.

신뢰성은 이 불안에 이름을 붙여 고칠 수 있는 대상으로 만든 축입니다. 재는 것이 코드의 상태가 아니라 사용자가 받아 본 신호라는 점이 다릅니다. 목적을 쉽게 이룰 수 있느냐를 보는 사용성과는 질문이 갈립니다. 사용성은 저장 버튼을 몇 초 만에 찾았느냐를 묻고, 신뢰성은 누른 뒤에 안심했느냐를 묻습니다.

신뢰는 제품이 보낸 신호를 사용자가 자기가 겪은 결과와 맞춰 보면서 오르내립니다. 맞으면 조금 오르고 어긋나면 크게 내려갑니다. 신호는 대체로 네 종류입니다.

1. 예고 — 다음에 무슨 일이 일어날지 먼저 알려 줍니다. 결제 버튼 옆에 오늘 얼마가 빠져나가고 다음 청구가 언제인지 적어 두는 것이 여기에 해당합니다.
2. 확인 — 사용자가 한 일의 결과를 바로 보여 줍니다. 저장 뒤에 잠깐 떴다 사라지는 알림인 토스트로 "오후 3시 12분 저장됨" 을 띄우면, 앞 절의 새로고침과 메모장 복사는 그 자리에서 없어집니다.
3. 복구 — 잘못됐을 때 되돌릴 길을 함께 줍니다. 오류 메시지가 "문제가 발생했습니다" 에서 끝나면 사용자는 자기 데이터가 어떻게 됐는지 알 수 없습니다. 무엇이 왜 실패했고 지금 무엇을 누르면 되는지까지 적혀 있어야 합니다.
4. 일관성 — 같은 조작에 같은 결과를 줍니다. 어제는 3초 만에 열린 문서가 오늘은 20초째 빈 화면이면 사용자는 고장을 의심합니다. 오래 걸리는 작업에 로딩 상태를 두는 이유가 여기 있습니다. 시간을 줄이지 못하면 지금 무슨 일이 벌어지는 중인지라도 보여 줍니다.

이 축이 다른 축과 크게 다른 점은 오르내리는 속도가 비대칭이라는 것입니다. 신뢰는 통장 잔고처럼 한 번에 한 번씩 쌓이는데, 빠져나갈 때는 사고 한 건에 절반이 사라집니다. 문서 하나가 날아간 경험이 있는 사용자는 그 뒤로 몇 백 번 저장에 성공해도 중요한 문서는 계속 따로 복사해 둡니다. 그래서 이 축은 나빠진 뒤에 고치는 비용이 유독 큽니다.

가장 먼저 시험받는 자리는 사용자가 무언가를 내주는 화면입니다. 돈, 개인 정보, 회사 데이터를 넘기는 순간마다 이 축이 걸립니다.

결제 화면이 대표적입니다. 앞 단계를 다 통과한 사람이 카드번호 칸에서 멈추는 일이 흔한데, 이유는 기능이 아니라 확신이 없어서입니다. 환불 조건과 해지 방법을 결제 버튼 옆에 적어 두는 것만으로 이 단계 이탈이 눈에 띄게 줄어듭니다.

기업 고객을 상대하는 자리에서는 이 축이 문서로 요구됩니다. 서비스가 정상 동작한 시간의 비율인 가동률을 최근 열두 달치로 내놓으라거나, 보안 통제를 외부 감사로 검증받은 SOC 2 보고서를 달라는 식입니다. 제품을 써 본 적 없는 법무 담당자가 이 자료만 보고 도입 여부를 판단하는 일도 있습니다.

제품을 쓰기 전 단계인 홈페이지에서는 다른 사람의 사용 기록이 그 역할을 합니다. 이미 쓰고 있는 회사의 이름이나 사용자 수처럼 남들도 쓴다는 신호로 결정을 돕는 장치를 사회적 증거라고 합니다. 처음 온 사람은 제품을 직접 검증할 방법이 없으니 이런 신호로 대신 판단합니다.

"이 화면 신뢰성이 약해요. 결제 직전인데 언제 얼마가 빠져나가는지 어디에도 안 적혀 있어요."

기능은 다 있지만 사용자가 확신할 근거가 화면에 없다는 지적입니다.

"버그는 아닌데 신뢰성에서 잃고 있어요. 저장은 되는데 저장됐다는 표시가 없어요."

동작과 표시를 나눠서 보자는 말입니다. 고칠 곳이 서버가 아니라 화면이라는 뜻이기도 합니다.

"엔터프라이즈 검토가 신뢰성에서 막혔어요. 가동률 이력이랑 보안 보고서를 달라고 합니다."

제품 기능 심사는 끝났고 남은 관문이 이 축이라는 보고입니다.

페이지덱에서는 결제 화면을 다시 만들면서 이 말이 오갔습니다. 민서가 초안을 들고 와 결제 버튼 위에 청구 금액과 다음 청구일, 해지 방법을 한 줄씩 넣자고 했습니다. 지현은 화면이 복잡해 보인다며 망설였지만, 수아가 상담 중에 가장 많이 받는 질문이 정확히 그 세 가지라고 말하면서 정리됐습니다. 궁금한 것을 묻지 않고 그냥 창을 닫는 사람이 훨씬 많다는 이야기였습니다.

태오는 여기에 저장 시각 표시를 얹었습니다. 편집할 때마다 문서 상단에 마지막 저장 시각을 남기는 작은 변경이었는데, 두 주 뒤 저장 관련 문의가 절반 아래로 떨어졌습니다. 저장 로직은 한 줄도 바뀌지 않았습니다.

화면을 고급스럽게 다듬으면 신뢰성이 올라간다고 보는 경우가 가장 많습니다. 실제로 허술해 보이는 화면이 의심을 사는 건 맞으니 그렇게 생각하기 쉽습니다. 하지만 이 축이 재는 것은 겉모습이 아니라 약속과 결과의 일치입니다. 잘 다듬은 화면은 오히려 기대를 높여 놓기 때문에, 그 상태에서 저장이 한 번 실패하면 처음부터 투박했던 제품보다 더 크게 무너집니다.

버그만 없으면 신뢰성은 저절로 확보된다고 보는 오해도 흔합니다. 문제가 없으면 의심할 이유도 없다는 생각인데, 사용자는 서버 기록을 볼 수 없다는 점이 빠져 있습니다. 성공했는데 성공했다고 보여 주지 않으면 사용자에게는 실패한 것과 구분되지 않습니다. 이 상태를 오래 두면 앞에서 본 장면이 반복됩니다. 문의는 쌓이는데 기록상 문제가 없으니 팀은 계속 재현 불가로 닫고, 사용자는 조용히 다른 제품으로 옮겨 갑니다.