하위 호환성을 지켜주려는 개발자의 마음가짐

대학교 때 C언어를 처음 배우면서 Makefile 을 잠깐 사용해봤던 것 같습니다. 교수님이 신신당부하셨던 기억이 납니다. "꼭 tab 을 사용해야 합니다. space 를 사용하면 안 됩니다." "이 에러는 눈으로 발견하기가 힘들기 때문에 주의해야 합니다." 왜 이렇게 실수하기 좋게 만들었을까? 유닉스의 탄생을 읽어보면서 그 이유를 알 수 있었습니다. 벨 연구소 안에서 동료들 몇 명이 처음 유닉스를 만들어 나가던 시기. 유닉스를 포함해 Make 의 사용자도 겨우 십여 명. 앞으로 유닉스가 성공할지 아닐지도 모르는 상태. 이런 상황에서 나라면 어땠을까? 사용자 겨우 열 명이 있다고 호환성을 지켜주는 선택을 할 수 있었을까? 글쎄요. 저는 호환성을 깨야 하더라도 크게 주저하지 않았을 것 같습니다. ‘겨우 열 명인 걸.’ 사용자보다는 내 불편한 마음을 없애기 위해서. Make 2.0은 더 좋은 프로그램이 됐다는 합리화와 함께. Make의 저자인 스튜어트는 사용자를 존중하는 쪽을 선택했습니다. 설계 결함을 인정하면서도 이런 선택을 했다는 것이 놀랍고 존경스럽습니다. Windows 프로그래밍 세상 속에서 살고 있을 때는 리눅스 해커들이 사용자를 배려하지 않아서 Windows를 이기지 못하는 것이라 생각했습니다. 이런 생각도 다 편견이었습니다. 진짜로 그랬다면 리눅스가 오늘날 이렇게 전 세계 사람들에게 이용되고 있지도 않았겠죠.