작은 유닉스 파이프라인도 결합돼 있으면 단순하지 않다는 주장

모듈식 소프트웨어를 만드는 중인데, 지금까지 가장 설계가 어려운 프로젝트임. 단순한 추상화를 찾으려면 3-5번씩 만들고 버리는 일이 생기고, 그래서 바이브 코딩은 작은 고립 스크립트에는 잘 맞아도 큰 시스템에서는 망가진다고 봄.

파이프와 그 위에 쌓는 도구를 좋아함. 오픈소스 관리자는 시간이 적으니 거대한 통합 소프트웨어를 만들 수 없고, 가진 카드 안에서 작은 도구를 조합해야 함.

이 글은 결국 "내가 필요한 기능이 언어에 내장돼 있으면 좋겠다"는 주장처럼 보임. 프로그램이 커지면 언어의 기본 도우미와 무관한 도메인 개념을 직접 만들어야 해서 그 차이가 사라짐.

예시가 저자의 의도를 충분히 구체화하지 못해서 다른 해석도 가능하다고 봄. 원전인 Rich Hickey의 Simple Made Easy는 프로그램이 커져도 결합도를 낮게 유지할 수 있다는 점을 더 정확히 설명함.

여기서 단순은 열등하거나 멍청하다는 뜻이 아님. 더 넓고 많은 일을 해도 단순할 수 있고, Hickey의 강연은 내 프로그래밍 사고를 크게 바꿨음.

글에서 쓰는 단순의 뜻이 잘 안 잡힘. 유닉스 파이프가 복잡해진 이유는 각 조각이 너무 단순해서 표현력이 부족했기 때문이라고 느꼈고, 아마 직교성 같은 뜻인지 강연을 봐야 알 것 같음.

단순에는 작은 것이라는 유용한 뜻도 있음. Solomonov, Levin, Kolmogorov, Chaitin 계열의 귀납 추론은 그 의미를 쓰니, 말장난으로 두 뜻을 섞으면 안 됨.

이 글은 Clojure 찬양글처럼 읽힘. Clojure는 좋지만, 발생 순서대로 단어 빈도를 출력한다는 유닉스 예시는 인위적이고 그걸로 파이프를 단순하지 않다고 재정의하기는 어려움.

모두가 공유하는 정확한 일상어 단순의 정의는 불가능하다고 봄. 1950년대 형식주의자들처럼 공리와 가정을 정한 체계 안에서 관계나 프로그램의 복잡도를 정량화해야 함.

유닉스 파이프 자체가 복잡한 건 아님. Ruby에서 메서드 체인 비슷한 의사 파이프를 만들었는데, awk나 sed처럼 각자 낯선 규칙을 가진 프로그램에 넘기니 어색했던 것뿐이고 더 나은 도구로 설계하면 됨.

파이프는 쉽고 좋은 추상화지만 단순하지는 않음. 동료가 유닉스 파이프에 데이터를 넣으려고 링 버퍼를 직접 구현하는 것도 봤음.

셸 밖에서 파이프를 제대로 쓰려면 자식 프로세스 종료 코드와 waitpid, SIGINT·SIGPIPE 같은 신호, stdio 버퍼링, 부분 write, 파일 디스크립터 닫기까지 처리해야 함. 그래서 사소하지 않은 작업에서는 파이프 구현을 쉽게 신뢰하지 않음.

DRY는 경험과 취향이 필요함. 같은 코드가 95-98% 같아 보여도 남은 2-5% 때문에 헬퍼 추출이 억지 결합을 만들면, 그냥 복사한 채 두는 편이 맞음.