03. 상식은 누구의 상식인가
문제 제기: 아무도 이상하다고 말하지 않는 화면
회의실의 프로젝터가 켜지고, 제품 디자이너가 새 결제 화면을 띄운다. 버튼은 오른쪽 아래에 있고, 주소 입력란은 한 줄로 정리되어 있으며, 오류가 나면 빨간 문장이 나타난다. 참석자들은 고개를 끄덕인다. “상식적인 흐름이네요.” 개발자는 이미 비슷한 화면을 여러 번 만들었다. 기획서에도 “일반적인 사용자 경험”이라고 적혀 있다.
그런데 출시 뒤 문의가 쏟아진다. 어떤 사용자는 인증번호를 어디에 입력해야 하는지 찾지 못하고, 어떤 사용자는 주소를 입력할 때 건물명과 도로명을 구분하지 못한다. 저시력 사용자는 오류 메시지를 읽지 못하고, 외국에서 접속한 사용자는 날짜와 이름의 순서가 뒤섞여 결제를 포기한다. 회의실에서 상식이었던 것이 누군가에게는 장애물이었다.
상식은 대개 설명되지 않는다. 설명하지 않아도 모두가 안다고 믿는 지식이기 때문이다. 바로 그래서 상식은 가장 강한 설계 규칙이 된다. 명시적인 요구사항은 검토할 수 있지만, 상식은 검토되지 않은 채 코드와 화면과 운영 절차 속으로 스며든다.
철학적 논점: 상식은 중립적인가
철학은 “당연하다”는 말의 출처를 묻는다. 상식은 자연에서 솟아난 순수한 감각이라기보다 특정한 생활환경, 언어, 제도, 기술을 오래 경험한 사람들이 공유하게 된 기대의 묶음이다. 현상학이 일상의 경험을 중요하게 다룬 이유도 여기에 있다. 우리는 세계를 매번 처음부터 분석하지 않고, 이미 익숙한 배경을 통해 이해한다. 문 손잡이를 볼 때마다 사용 설명서를 찾지 않는 것처럼 말이다.
문제는 그 배경이 모든 사람에게 동일하지 않다는 데 있다. 한 조직의 상식은 다른 조직의 낯섦일 수 있고, 다수의 편의는 소수의 추가 노동 위에 세워질 수 있다. “사용자는 로그인할 때 이메일을 입력한다”는 문장은 이메일에 안정적으로 접근할 수 있고, 하나의 계정을 지속적으로 사용하는 사람을 기본값으로 삼는다. “관리자는 데이터를 자유롭게 다운로드할 수 있다”는 문장은 데이터 주체의 권리나 내부 통제보다 운영자의 편의를 앞세운다.
상식을 의심한다고 해서 모든 관습을 폐기해야 하는 것은 아니다. 상식은 협업을 가능하게 하는 압축된 지식이기도 하다. 매번 버튼의 위치와 로그의 의미를 처음부터 합의한다면 어떤 팀도 움직일 수 없다. 핵심은 상식을 없애는 것이 아니라, 상식이 상식이 되기까지 누가 배제되었는지를 드러내는 데 있다. 묵시적인 전제를 문장으로 꺼내면 비로소 검토와 수정이 가능해진다.
공학 사례: 기본값 하나가 사용자 집단을 만든다
회원가입 시스템을 설계한다고 하자. 이름 필드를 성과 이름 두 칸으로 나누고, 휴대전화 번호를 필수로 지정하며, 비밀번호는 특수문자를 포함해야 한다고 안내한다. 대부분의 테스트 계정은 문제없이 통과한다. 하지만 이 설계는 이름 체계가 다른 사람, 전화번호를 제공할 수 없는 사람, 비밀번호 관리자를 사용하는 사람의 현실을 충분히 상상하지 않는다.
또 다른 예로, 채용 AI가 있다. 과거 채용 데이터를 학습한 모델이 특정 대학, 특정 경력 형식, 특정 자기소개서 문체를 높은 점수로 평가한다고 하자. 모델은 편견을 ‘발명’하지 않았다고 말할 수 있다. 데이터에 있던 패턴을 학습했을 뿐이다. 그러나 과거의 상식이 미래의 기준으로 자동 복제되는 순간, 시스템은 상식을 판정하는 기계가 된다. 무엇을 능력으로 볼 것인지, 어떤 경력의 공백을 설명할 기회로 인정할 것인지가 코드 속에서 결정된다.
여기서 공학적 대응은 단순히 “편향을 조심하자”는 선언에 그치지 않는다. 입력값을 왜 필수로 두었는지 기록하고, 기본값이 누구를 편하게 하고 누구에게 비용을 전가하는지 점검하며, 오류와 예외를 실제 사용자의 목소리로 테스트해야 한다. 테스트 케이스에 ‘평균적인 사용자’만 넣지 말고, 시스템이 상정하지 않은 방식으로 살아가는 사람을 넣어야 한다. 접근성은 마지막에 붙이는 기능이 아니라, 상식을 설계 사양으로 바꾸는 과정이다.
AI 비서가 사용자의 요청을 해석하는 장면도 마찬가지다. “회의를 잡아 줘”라는 말에서 모델은 근무시간, 시간대, 참석자의 관계, 이동 시간을 추정한다. 이 추정이 빠를수록 편리해 보이지만, 잘못된 상식을 자신 있게 실행할 위험도 커진다. 좋은 시스템은 모든 것을 묻는 시스템이 아니라, 결과의 비용이 큰 가정 앞에서 멈출 줄 아는 시스템이다. 그리고 무엇을 가정했는지 사용자가 알아볼 수 있게 보여준다.
반론과 긴장: 모든 차이를 고려하면 설계할 수 있는가
현실적인 반론이 있다. 모든 문화와 신체 조건과 생활방식을 고려하려 하면 제품은 복잡해지고, 개발 일정은 늘어나며, 인터페이스는 누구에게도 직관적이지 않게 될 수 있다. 소수의 사례를 위해 다수의 사용성을 희생하는 것이 공정한가라는 질문도 남는다.
이 긴장은 실제다. 하지만 ‘다수를 위한 단순함’이 언제나 중립적인 것은 아니다. 어떤 사람에게는 작은 불편인 추가 입력이 다른 사람에게는 서비스 이용 자체를 막는 벽이 된다. 또한 포용적 설계가 반드시 복잡성을 증가시키는 것도 아니다. 명확한 오류 메시지, 키보드 접근성, 충분한 시간 제한, 되돌리기 기능은 다양한 사용자에게 유용하면서 전체 사용성도 높인다. 중요한 것은 예외를 무작정 늘리는 일이 아니라, 하나의 기본값을 자연법처럼 취급하지 않는 일이다.
상식은 출발점일 수 있지만 종착점이어서는 안 된다. 팀이 “다들 이렇게 하니까”라고 말하는 순간, 설계자는 잠시 멈춰야 한다. 다들 누구인지, 그 ‘이렇게’가 누구의 시간을 절약하고 누구의 시간을 소모하는지 묻는 짧은 멈춤이 필요하다.
마무리 질문
당신이 오늘 작성한 요구사항과 테스트 코드는 어떤 사람을 너무 당연하게 상정하고 있는가. 지금 편리한 기본값은 누구의 경험을 표준으로 만들며, 그 표준 바깥에 있는 사람에게 어떤 설명과 선택권을 남겨 두는가. 상식을 지키는 것이 아니라 상식을 볼 수 있게 만드는 것, 어쩌면 그것이 공학의 첫 번째 책임일지도 모른다.