BusyBox에는 CGI 지원이 내장되어 있다는 사실을 특히 좋아함. rclone serve webdav도 빼놓기 아쉬움. https://elixir.bootlin.com/busybox/1.37.0/source/networking/....
글의 내용은 전적으로 타당하며, 특히 권한을 제한하기 위한 pledge/chroot 등을 포함한 점이 좋음. 배포 방식에는 극단적으로 다른 두 방향이 있음. 단순한 echo "hello world"를 실행하려고 원격 컴퓨팅의 하이퍼바이저부터 k8s, Proxmox, VM, Docker까지 겹겹이 쌓을 수도 있고, 그냥 bash -c 'echo "hello world"'를 CGI 뒤에서 실행할 수도 있음. https://github.com/Domain/bash.cgi를 보면 좋겠음. BusyBox 위에서 CGI로 Bash를 실행하는 것이 정답이라는 뜻은 아니며, 거의 프레임워크 없이 구현하는 데 필요한 연결 코드는 아주 작고 이해하기 쉬움을 보여주려는 취지임.
업무용 내부 도구는 some-cmd [--json|--markdown] ...yet-more-args... 형태로 만드는 쪽으로 기울고 있음. 프로세스와 셸 환경 자체를 REPL로 활용하면 --cgi-bin도 출력 형식 하나를 추가하는 정도로 접근하게 됨. 명령을 독립적이고 재현 가능하며 입력 인자에만 의존하도록 설계하면, Firecracker VM이나 Lambda 같은 제약된 환경부터 셸·디버거·단위 및 통합 테스트 같은 편한 환경까지 실행하기 쉬워짐.
나도 비슷하게 작업하고 있으며, 최근 현재 디렉터리에 cgi-bin 폴더를 두고 busybox httpd -p 9000 -h . -f -v 로 서비스할 수 있다는 사실을 발견함.
이미 Bottle로 독립 서버와 CGI 스크립트 양쪽에서 동작하는 Python 서비스를 작성하고 있으며, BusyBox의 더 제한적인 CGI 환경에서도 돌아가도록 수정 중임. 핵심은 .htaccess 재작성 규칙 없이 처리할 수 있게 만드는 것임.
일회성·개인용 소프트웨어가 늘어날수록 단순한 배포 도구가 다시 부상할 여지가 있다고 봄. BusyBox + Lua는 시스템 요구 사양이 극히 낮아 DDR4면 충분하다는 요즘 분위기에도 잘 맞음. 오래된 Raspberry Pi 2B에서 실행 중인데, 정기적으로 접속하는 10명 정도를 감당하기에 충분함.
독특한 웹 애플리케이션에 관심 있다면, 내가 작업 중인 C++ 문명 스타일 게임을 살펴보면 좋겠음. 클라이언트는 Emscripten으로 WebAssembly로 컴파일하고, 애플리케이션 서버도 nginx 뒤에서 C++로 구현함.
AI 시대 이전부터 만든 프로젝트로, 3D 처리부터 웹 처리까지 엔진 전체를 직접 구현함. https://statebuilder.com/.
순수 C와 CGI를 생각했던 것은 아니지만, 표준 라이브러리와 Boost만으로 C++ 웹 API 서버를 직접 작성한 과정은 무척 즐거웠음. 안정성이 높고 공급망이나 의존성으로 골치 아플 일도 적음.
사내 업무용 앱이라 아직 운영 준비가 끝나지는 않았지만, 내 기준으로는 여러 현대적인 웹 개발 접근법보다 확실히 낫고 신선한 개념 증명 프로젝트임.
글에서 설명한 것은 옛날 PHP 3와 같음. 초기 PHP 3·4는 C 라이브러리 위에 얹은 얇은 계층이라 꽤 빠르고 간단했음. CGI가 퇴조하던 시기에 등장해 CGI의 문제를 해결해 줌.
첫 문장에는 동의하기 어려움. 1990년대에 내가 처음 알게 된 웹 페이지 제작자들은 cgi-bin에 C 프로그램이 아니라 Perl 스크립트를 넣었음.
그보다 조금 앞선 시기일 수 있음. Perl도 곧 자리 잡았지만, 초기 cgi-bin은 C가 지배적이었고 이후 웹 앱을 컴파일하느라 씨름하는 데 지친 사람들이 다른 선택을 하기 시작함.
기억으로는 명세 자체에도 C 애플리케이션을 위해 만들었다고 적혀 있었던 것 같음. 물론 mod-perl은 정말 큰 도움이 됨.