GNU Coreutils — 거절된 기능 요청 목록

본문

GNU coreutils 관리자들은 이 문서 서두에서 'coreutils 작업에서 가장 어려운 부분 중 하나는 무엇을 거절할지 아는 것이며, 기여자에게 적절한 정당성을 설명하는 것'이라고 밝힙니다. 나열된 제안들은 모두 좋은 아이디어였지만, 링크된 메일링 리스트 토론에서 상세히 다뤄진 여러 이유로 채택되지 않았습니다. 이 목록은 단순한 거절 기록이 아니라, 수십 년간 이어진 유닉스 도구 설계 철학의 실제 적용 사례집이라고 볼 수 있습니다.

'기존 도구로 충분하다'는 판단의 반복

목록 전체를 관통하는 가장 강력한 거절 논리는 '이미 존재하는 도구의 조합으로 해결 가능하다'는 것입니다. 예를 들어 cat의 --timestamp 옵션은 'awk나 perl로 충분하다', --header 옵션은 'tail -n+1이 이미 같은 일을 한다'는 이유로 거절되었습니다. cp --resume은 'rsync를 쓰라', cp/mv --bwlimit은 'rsync에 있는 기능이며 상위 수준 도구에 더 적합하다'는 답이 돌아왔습니다. cut --csv는 별도의 전용 유틸리티가 복잡한 작업을 다루는 편이 낫다는 판단이었고, dd의 속도 제한 옵션들은 pv나 trickle 같은 도구에 맡기는 것이 낫다고 정리되었습니다. uniq -c --total은 awk '{t+=$1}END{print t,"total"}1' 파이프로 충분하다는 식으로, 거절 사유마다 대안이 되는 실제 명령어 조합이 함께 제시되는 것이 이 문서의 특징입니다.

복잡도와 범용성의 기준

두 번째 패턴은 '너무 특수하다' 또는 '복잡도를 정당화할 만큼 범용적이지 않다'는 판단입니다. date +%J의 천문학적 율리우스일 지원은 '충분히 흔한 용도가 아니다', OCFS2 리플링크 파일에 대한 정확한 du 결과는 'du에 넣기엔 너무 복잡하고 특수하다'고 평가되었습니다. join이 둘 이상의 파일을 다루는 것은 '복잡성을 추가하면서 확장 가능하지 않다', csplit --output=N은 '명시적으로 지원하기엔 너무 특수하다'는 이유로 탈락했습니다.

표준과 보안의 경계

POSIX 같은 표준과 보안 정책이 거절 이유가 되는 경우도 있습니다. echo -- -e로 옵션 해석을 끝내는 제안은 'POSIX를 위반하므로 printf를 쓰라'고 거절되었고, rm이 unlink() 대신 remove()를 쓰게 하자는 제안은 '표준화된 기능을 바꿀 수 없다'는 답을 받았습니다. chmod가 world-writable 파일 생성을 금지하게 하자는 제안은 '범용적으로 만들 수 없고, 만들더라도 쉽게 우회된다'며 보안 기능이 유틸리티 수준에서 강제되기 어렵다는 점을 보여줍니다. rm --parents는 '트리를 거꾸로 올라가며 삭제하는 것이 너무 위험하다'는 사용자 안전 관점의 거절이었습니다.

설정보다 래퍼를 권장

환경 변수와 전역 설정 파일에 대한 요구는 일관되게 기각되었습니다. 문서는 '새로운 환경 변수는 권장되지 않으며 래퍼 셸 스크립트와 셸 alias가 선호된다'고 명시하고, /etc/gnu.conf 같은 전역 설정 파일 제안에도 'alias, 셸 함수, 래퍼 스크립트가 coreutils 기본 동작을 바꾸는 권장 방법'이라고 답합니다. 새 명령어 추가 제안들 — rename, errno 유틸리티, tableize, sparse 명령 등 — 도 대부분 '기존 도구가 충분히 풍부하다'는 이유로 거절되었습니다. 이 목록은 '작은 도구를 조합한다'는 유닉스 철학이 추상적 슬로건이 아니라, 수십 년간 실제 패치 기각 결정으로 유지되어 온 운영 원칙임을 보여주는 기록입니다.

원문: GNU coreutils (gnu.org) / 번역·요약: Trawling