fork() + exec()의 시대착오적 문제점 지적
fork() + exec() 모델은 1970년대 설계로, 현대 시스템에서는 비효율적이고 복잡한 추상화라는 비판이 제기됨
프로세스 복제 비용(Process Duplication Cost)과 이후 exec() 호출 시 불필요한 메모리 복사 문제가 지적됨
Copy-on-Write 최적화에도 불구하고 fork()는 여전히 O(N) 비용을 가지며, 파일 디스크립터 관리 등 복잡성을 야기함
대안 모델의 필요성이 제기되나, 기존 API의 유연성을 대체하기 어렵다는 반론도 존재함
fork()의 역사적 배경과 현대적 비효율성
커뮤니티에서는 fork()와 exec()의 조합이 1970년대 시스템 환경에 맞춰진 설계이며, 현대적인 관점에서는 시대착오적이고 비효율적인 추상화라고 지적합니다. 특히, Microsoft Research의 논문('A fork() in the road')을 인용하며 fork()가 더 이상 유용하지 않고 오히려 시스템 구현에 부담을 준다고 분석합니다. 이는 운영체제(Operating System) 설계의 제약으로 작용하며, 연구 및 교육 현장에서 fork()를 역사적 유물로 다뤄야 한다는 주장입니다.
fork()의 성능 비용과 Copy-on-Write의 한계
많은 논의에서 fork() 시스템 호출의 비용이 과소평가되고 있음을 지적합니다. 프로세스 상태 전체를 복사해야 하므로 본질적으로 비용이 많이 드는(Expensive) 연산이며, O(N)의 복잡도를 가집니다. Copy-on-Write(COW) 최적화가 메모리 복사를 줄여주지만, 페이지 테이블 항목 관리 등 여전히 선형적인 비용이 발생한다고 설명합니다. 특히, fork() 직후 exec()를 호출하여 복사된 메모리를 즉시 폐기하는 경우, 이러한 비용이 더욱 부각됩니다.
파일 디스크립터 관리의 복잡성
사용자 sanderjd는 fork() 이후 불필요한 파일 디스크립터(File Descriptor)를 닫아야 하는 번거로움 때문에 발생하는 버그를 경험했다고 공유합니다. '현재 프로세스를 복제한다'는 fork()의 동작 방식이 '완전히 새로운 프로세스를 시작한다'는 일반적인 요구사항과 다르다는 점을 강조합니다. 이를 직접적으로 표현할 수 있는 API 부재로 인해, 클로닝(Cloning) 후 후처리(Post-processing)하는 방식으로 근사해야 하는 불편함이 있다고 지적합니다.
fork() + exec() 모델의 유연성과 대안의 어려움
반면, ucker와 같은 사용자는 fork() + exec() 모델의 핵심적인 우아함(Elegance)은 fork() 이후 모든 설정을 표준 API를 통해 유연하게 구성할 수 있다는 점이라고 반박합니다. 지금까지 제시된 통합 호출 방식의 대안들은 모든 설정 옵션을 파라미터로 전달해야 하므로 복잡해지고 확장성이 떨어져 결국 지저분해지는 경향이 있다고 분석합니다. 이는 fork() 모델이 가진 설정의 자유도(Configuration Freedom)가 대체하기 어려운 장점임을 시사합니다.
