14. 좋은 기술이란 무엇인가

문제 제기: 작동하는 것과 좋은 것은 다르다

지하철 개찰구 앞에서 한 노인이 휴대전화 화면을 몇 번이고 눌러 본다. 앱은 최신 버전이고, 서버 응답 시간도 빠르다. 그러나 글자는 작고, 오류 메시지는 “유효하지 않은 요청”이라고만 말한다. 뒤에서 사람들이 기다리자 그는 결국 직원에게 도움을 청한다. 시스템은 작동했다. 인증도 되었고, 결제도 처리되었으며, 장애율도 목표치 안에 있었다. 그런데 이 장면을 좋은 기술의 사례라고 부르기는 어렵다.

공학에서 “좋다”는 말은 자주 성능, 확장성, 안정성 같은 지표로 번역된다. 물론 중요하다. 느린 시스템과 자주 멈추는 시스템은 사용자에게 폭력적일 수 있다. 하지만 지표에 잡히지 않는 손실도 있다. 사용자가 왜 거절되었는지 알 수 없는 경험, 선택지를 잃는 자동화, 고칠 수 없는 데이터, 담당자를 찾을 수 없는 결정. 좋은 기술은 단순히 요구사항을 만족하는 기술이 아니라, 사람과 조직이 그 결과를 이해하고 감당하고 수정할 수 있게 하는 기술이다.

철학적 논점: 기술의 가치는 결과만으로 결정되지 않는다

기술을 도구로만 보면 평가 기준은 간단해진다. 목적을 얼마나 빠르고 싸게 달성하는가. 그러나 기술은 목적을 수행하는 과정에서 사람의 행동과 관계를 바꾼다. 동일한 결과라도 어떤 경로를 거쳤는지에 따라 경험과 권력의 분배가 달라진다.

대출 심사 모델이 예전보다 정확해졌다고 하자. 전체 승인 예측률은 상승했지만, 신청자는 왜 탈락했는지 알 수 없고 이의를 제기할 창구도 없다면 어떨까. 모델은 통계적으로는 개선되었지만 제도적으로는 퇴행했을 수 있다. 정확성은 결과의 품질을 말하고, 정당성은 결과가 만들어지고 contest될 수 있는 조건을 말한다. 좋은 기술은 둘 중 하나를 선택하지 않는다. 정확도를 높이면서도 설명의 수준, 재심의 절차, 데이터 수정 가능성을 함께 설계한다.

이때 자율성은 “원하면 사용하지 않아도 된다”는 형식적인 선택이 아니다. 사용자가 선택의 결과를 이해할 수 있어야 하고, 거부하거나 되돌릴 수 있어야 하며, 시스템 밖으로 나갈 때 모든 관계를 잃지 않아야 한다. 자동 저장을 끌 수 없는 편집기, 해지 버튼을 숨긴 구독 서비스, 추천을 거부하면 기능 전체가 제한되는 플랫폼은 편리함을 제공하는 듯하지만 실제로는 사용자의 협상력을 줄인다.

공학 사례: 좋은 설계는 실패의 순간에 드러난다

정상 흐름의 데모는 거의 모든 제품을 아름답게 보이게 한다. 이메일을 입력하고, 초록색 버튼을 누르고, 성공 화면을 확인한다. 하지만 실제 사용자는 잘못된 파일을 올리고, 비행기 모드에서 버튼을 누르고, 권한을 잃고, 중간에 전화를 받는다. 좋은 기술은 성공을 매끄럽게 만드는 데서 끝나지 않는다. 실패를 설명 가능하고 복구 가능하게 만든다.

파일 업로드 서비스라면 단순히 “업로드 실패”라고 말하는 대신 무엇이 실패했는지 구분해야 한다. 네트워크가 끊겼는지, 파일 형식이 맞지 않는지, 권한이 만료되었는지 알려 주고, 가능한 경우 중단된 지점부터 재개하게 해야 한다. 사용자가 다시 처음부터 기다리지 않도록 하는 것은 성능 최적화이면서 존중의 표현이다. 삭제 기능도 마찬가지다. 파괴적인 작업에는 명확한 확인과 유예 기간을 두고, 복구 경로를 마련해야 한다. 운영자는 실수하지 않는 사람이 아니라 실수한 뒤 수습할 수 있는 사람이어야 하기 때문이다.

조직의 의사결정에서는 ‘좋은 기술’이 단기 성과와 충돌한다. 관측성에 투자하면 당장 고객에게 보이는 기능은 늘지 않는다. 내부 도구의 접근 권한을 세분화하면 업무 흐름이 조금 느려진다. 오래된 모듈을 교체하지 않고 패치만 이어 가면 이번 분기의 목표는 달성하기 쉬울 수 있다. 그러나 이런 결정은 비용을 없애지 않고 다른 사람과 미래로 이동시킨다. 좋은 조직은 그 이동을 “기술적인 세부사항”으로 감추지 않는다. 온콜 시간, 복구 시간, 이탈률, 지원팀의 반복 업무를 제품 품질의 일부로 센다.

반론 또는 긴장: 좋은 기술은 누구에게 좋은가

좋음은 중립적인 단어가 아니다. 한 사용자에게 편리한 기능이 다른 사용자에게는 감시일 수 있다. 운영팀에 안정적인 강제 업데이트가 현장 노동자에게는 통제일 수 있다. 모든 사람에게 동시에 좋은 설계가 불가능한 경우도 있다.

그러므로 공학자는 “사용자”를 하나의 평균값으로 만들지 말아야 한다. 가장 자주 쓰는 사람뿐 아니라 가장 크게 실패하는 사람, 오류를 감당할 자원이 적은 사람, 시스템의 결정을 거부하기 어려운 사람을 함께 봐야 한다. 우선순위의 충돌을 없애는 대신 드러내고, 누가 이익을 얻고 누가 부담을 지는지 기록해야 한다. 접근성 검토와 위협 모델링, 개인정보 영향 평가, 폐기 계획은 출시를 늦추는 장식이 아니라 좋은 것의 범위를 넓히는 실천이다.

마무리 질문

이 기술은 얼마나 잘 작동하는가만큼, 누가 그것을 이해하고 고칠 수 있는가. 실패했을 때 사용자는 설명을 받을 수 있는가, 되돌릴 수 있는가, 사람에게 호소할 수 있는가. 우리의 지표가 높아질수록 누군가의 선택지는 줄어들고 있지 않은가. 좋은 기술은 편리한 기술보다 더 어려운 기준을 요구한다. 그것은 사람을 시스템에 맞추는 대신, 시스템이 사람의 복잡함을 견디게 하는 일이다.