소프트웨어 개발자들은 이제 신뢰성 따위 신경 쓰지 않는다

게시일: 2025년 11월 23일 | 원문 작성일: 2021년 10월 17일 | 저자: Drew DeVault | 원문 보기

현대의 멍청이들 소프트웨어 개발자들이 가진 “빨리 움직이고 망가뜨려라(move fast and break things)” 사고방식 속에서 완전히 사라져버린 소프트웨어 엔지니어링 원칙들 중에서, 신뢰성(reliability)은 가장 방치된 원칙일 거예요. 견고성(robustness)이라는 유사한 원칙과 함께요. 요즘 사용자들이 마주치는 거의 모든 소프트웨어는 그냥 고장 났어요. 심지어 심하게요.

진짜 창피한 일이에요. 망가진 소프트웨어를 우회하기 위해 여러분이 배워야 했던 온갖 멍청한 작은 방법들을 생각해보세요. 흔히 페이지를 새로고침하거나 프로그램을 재부팅해서 제정신으로 돌려놓는 것 같은 단순한 방법들이요 — 대부분의 사용자들은 그 정도는 할 수 있죠. 하지만 훨씬 더 멍청한 문제들도 있어요. 그리고 그런 문제들은 어디에나 있어요. 매일 아침, 저는 워크스테이션을 부팅한 다음 즉시 강제 재부팅을 해요. 그래야 모니터들이 제대로 깨어나서 자기 일을 하는 것 같거든요. 여러 번, 저는 브라우저 개발자 도구를 사용해서 망가진 웹 페이지를 검사하고 제가 원하는 걸 하게 만드는 방법을 찾아야 했어요. 대개는 폼을 제대로 제출하는 것 같은, 엄청나게 복잡한 작업들이죠 (1993년부터 이미 해결된 문제인데 말이죠).^[1]

평범한 사람들(그러니까 일반인)이 “컴퓨터를 이해 못 하겠다”고 말할 때, 저는 그들을 믿어요. 그들이 배우기에 너무 게을러서가 아니에요. 뒤처지고 구식이어서도 아니고, 시대를 따라가지 못해서도 아니에요. 컴퓨터가 이해하기 어렵기 때문이에요. 컴퓨터는 수수께끼 같고 신뢰할 수 없거든요. 저는 대화 중에 갑자기 제 폰이 SMS 메시지 전송을 멈췄을 때, 친구가 저를 버린 게 아니라 비행기 모드를 껐다 켜서 모뎀을 재부팅해야 한다는 걸 알아요. 저는 링크를 휠 클릭했을 때 “javascript:;“가 새 탭에서 열리면, 어떤 멍청이 개발자가 대신 왼쪽 클릭하기를 원한다는 걸 알아요. 대부분의 사람들은 이걸 이해하지 못해요! 독자 여러분과 저는 망가진 컴퓨터를 다루는 방법에 대한 엄청난 양의 숨은 지식을 쌓아왔어요. 우리가 마주친 소프트웨어의 절반을 사실상 리버스 엔지니어링해야 했죠. 정확히 어디를 찔러야 요청한 일을 하는지 알아내기 위해서요. 이런 배경 지식이 없다면 컴퓨터는 악몽이에요.

지난 10년 정도 동안 소프트웨어 개발자들이 신뢰성을 얼마나 개무시했는지 과장하기 어려워요. 그것도 가장 단순하고 어리석은 이유 때문이에요. 웹 폼 같은 것들 말이죠. 제 웹 브라우저는 지난 28년 동안 HTML 폼을 완벽하게 제출할 수 있었어요. 그런데 어떤 멍청한 이유로 어떤 멍청이 개발자가 모든 폼 시맨틱을 JavaScript로 재구현하기로 결정했고, 이제 저는 개발자 도구를 열지 않고는 전기 요금을 낼 수 없어요. 그렇게 하는 방법을 모르는 사람의 입장을 상상해보세요. 시각 장애인이라면 어떨지 상상해보세요.

여러분, 이건 말도 안 돼요. 우리 업계는 무모함과 사용자에 대한 공감 부족으로 특징지어져요. 이제 정신 차릴 때예요. 이건 우리 잘못이에요. 그리고 네, 독자 여러분도 그 말에 포함돼요. 우리는 이 재앙에 개인적으로 책임이 있고, 이걸 바로잡기 위해 우리 할 일을 해야 해요.

이게 여러분이 해야 할 일이에요.

단순함을 우선시해야 해요. 여러분과 저는 영리할 만큼 똑똑하지 않으니까, 시도하지 마세요. 옛말에 있듯이, 프로그램에는 두 종류가 있어요: 명백하게 버그가 없을 정도로 단순한 것과, 명백한 버그가 없을 정도로 복잡한 것. 더 단순한 종류를 만드는 게 결코 더 쉬운 건 아니에요. 사실 훨씬 더 어렵죠. 하지만 시스템이 단순할수록, 모든 상태와 엣지 케이스에 대해 추론하기가 더 쉬워져요. JavaScript로 구동되는 커스텀 텍스트박스 위젯 같은 건 필요 없어요. JAVASCRIPT로 구동되는 커스텀 텍스트박스 위젯은 필요 없다고요!

상태(state) 얘기가 나왔으니 말인데, 상태는 견고성의 핵심이에요. 뭔가 망가질 때, 그건 여러분이 계획하지 않았던 상태가 발생했기 때문이에요. 프로그램을 이 상태의 관점에서 생각하세요. (합리적인 범위 내에서) 유효하지 않은 상태를 표현할 수 없는 데이터 구조를 설계하고, 각 가능한 상태들을 나열한 다음 그 상황에서 애플리케이션이 합리적인 무언가를 한다는 걸 확인하세요.

에러 케이스를 식별하고, 계획하고, 그 계획을 구현한 다음, 테스트하세요. 때때로 작동하지 않는 일들이 있어요! 대부분의 언어는 에러 케이스를 식별하고 적절하게 처리할 도구를 제공하니까, 사용하세요. 그리고 다시 한번, 제발, 테스트하세요. 여러분이 개인적으로 실행되고 예상대로 작동하는 걸 보지 않은 코드 한 줄을 커밋하고 푸시한다면, 여러분은 제대로 일하지 않은 거예요.

검증된 기술을 사용하는 걸 선호하세요. 검증되지 않은 기술을 사용한다면, 드물게 사용해야 하고 속속들이 이해해야 해요. 2주 전에 HN에서 들은 최신 데이터베이스 엔진의 소스 코드를 읽어보지 않았다면, 프로덕션에 넣어서는 안 돼요.^[2]

마지막으로, 경제성이 여러분이 하는 모든 일을 결정하게 두지 마세요. 네, 개발자의 시간은 한정돼 있고, 그 시간에는 비용이 들어요. 네, 접근성이나 국제화 같은 성가신 요구사항을 가진 사용자들은 그들이 만들어내는 수익보다 지원 비용이 더 비싸요. 그래도 여러분은 그 비용을 지불해야 해요. 그게 옳은 일이에요. 우리는 수익성도 있으면서 공감할 수 있어요. 시장에 먼저 진입하는 것에 대해 생각하지 말고, 대신 사용자의 손에 좋은 제품을 넣는 것을 우선시하세요. 우리 사용자들은 가축이 아니에요. 그들을 희생시켜 관심을 돈으로 바꾸는 게 우리 일이 아니에요. 우리는 사용자를 존중해야 하고, 그건 배포하기 전에 젠장 코드를 테스트하는 걸 의미해요.

저와 함께 연습을 해봐요. 메모장을 잡고 프로덕션에서 소프트웨어 버그를 마주칠 때마다(여러분 것이든 남의 것이든), 또는 비전문가 시스템을 작동시키기 위해 컴퓨터 전문가로서의 지식에 의존해야 할 때마다 메모하세요. 일주일 후에 그 목록을 제게 이메일로 보내세요.

각주

^[1] 저는 종종 개발자 도구를 사용해서 만연한 광고, 스파이웨어, 방해 바(nagbar), 페이월, 뉴스레터 팝업, 스팸도 제거해요. 이런 쓰레기를 여러분 웹사이트에 추가하지 마세요. 그런 코드를 작성할 엄두도 내지 마세요.

^[2] 소스 코드에 접근조차 할 수 없다면, 절대로 사용해서는 안 돼요.