작은 도구를 연결하라는 네 가지 원칙
Doug McIlroy가 정리한 Unix 설계 원칙은 프로그램을 작게 나누고 출력과 입력으로 연결하라는 생각을 강조해.
- 각 프로그램은 한 가지 일을 잘하게 만들어.
- 한 프로그램의 출력은 아직 만들어지지 않은 다른 프로그램의 입력이 될 수 있다고 가정해.
- 소프트웨어는 가능한 한 이른 시점에 시험할 수 있게 설계해.
- 반복 작업을 줄이는 도구를 먼저 만들고, 일회성 도구라도 필요하면 과감히 사용해.
문구를 그대로 숭배하기보다 책임, 데이터 경계와 피드백 주기를 분명히 하라는 설계 조언으로 읽는 편이 좋아.
오늘의 개발에서도 같은 생각이 보여
작은 서비스, 조합 가능한 CLI, 지속적 배포와 빌드 자동화는 모두 책임을 나누고 경계를 드러내려는 시도야. 그렇다고 프로세스를 잘게 쪼개기만 하면 좋은 설계가 되는 것은 아니야. 각 단계의 입력, 출력, 오류와 소유권을 설명할 수 있어야 교체와 검증이 쉬워져.
터미널에서 적용할 습관
- 데이터와 진단을 분리해. 결과 데이터는 stdout, 경고와 오류는 stderr로 보내면 파이프가 안정돼.
- 출력을 계약으로 다뤄. 사람이 보는 표와 기계가 읽는 형식을 구분하고, 자동화용 형식은 예고 없이 바꾸지 마.
- 경계를 보존해. 공백과 줄바꿈이 데이터에 들어올 수 있다면 NUL, JSON처럼 모호하지 않은 표현을 선택해.
- 작은 책임으로 나눠. 한 단계의 실패를 독립적으로 관찰하고 다시 실행할 수 있을 정도가 좋은 기준이야.
구조화 데이터에는 구조를 아는 도구를 써
줄 중심 텍스트 도구만으로 중첩 JSON을 다루면 따옴표, 배열과 줄바꿈 때문에 데이터 구조를 잃기 쉬워. jq, yq, dasel처럼 형식을 이해하는 도구를 파이프 안에 넣으면 구조를 보존하면서 필요한 값만 고를 수 있어. 철학은 여전히 조합이지만, 조합 단위가 단순한 한 줄에서 명시적인 데이터 형식으로 넓어진 거야.
작은 도구에도 비용이 있어
단계를 나누면 테스트와 교체가 쉬워지지만 프로세스 시작, 직렬화, 인용 규칙과 실패 전파라는 비용이 늘어. 세 줄짜리 파이프라인이 읽기 어렵거나 반복 실행되고 외부 입력을 받기 시작하면 이름 붙인 스크립트나 프로그램으로 옮겨. 짧은 코드보다 입력 계약과 오류 처리가 분명한 코드가 유지하기 쉬워.
텍스트 스트림이라는 전제를 확인해
고전적인 Unix 예시는 줄 하나를 레코드 하나로 다루는 경우가 많아. 하지만 NUL이 든 파일명, 여러 줄 레코드, 바이너리와 중첩 데이터에는 그 전제가 맞지 않아. 변환 전에 레코드 경계를 정하고, 단계마다 항목 수와 표본을 확인해. 모든 데이터를 공백과 줄바꿈으로 평탄화하면 원래 구조가 조용히 사라질 수 있어.