스택 선택의 질문을 잘못 세우고 있지는 않은가
제품 요구사항 단계에서 기술 스택을 논의할 때, 대부분의 팀은 "어느 프레임워크가 더 좋은가"를 먼저 따진다. Next.js냐 FastAPI냐, Django냐 Go Fiber냐. 그런데 이 질문에는 전제가 숨어 있다. 모던 웹앱에는 모던 프레임워크가 필요하다는 것이다.
그 전제가 항상 맞지는 않는다. 2026년 현재, 사용자 계정·결제·이메일 발송·검색 대시보드를 갖춘 상용 SaaS 제품이 C 언어와 CGI(Common Gateway Interface, 웹 서버가 외부 프로그램을 호출하는 표준 인터페이스)로 실제 서비스되고 있다. 이 사실 자체가 논쟁거리는 아니다. 중요한 것은, 그 선택이 어떤 조건에서 합리적이고 어떤 조건에서 위험한가다.
이 글은 Node·Python·Go 기반 프레임워크와 C+CGI를 네 가지 축으로 비교하고, 각각의 선택이 적합한 팀 구조와 제품 복잡도를 정리한다.
비교의 전제: CGI는 왜 사라졌고, 왜 다시 꺼낼 수 있는가
CGI가 2000년대 초에 퇴출된 이유는 크게 두 가지였다. 요청마다 새 프로세스를 포크(fork)하는 비용이 컸고, 공통 기능(세션·라우팅·입력 검증 등)을 매번 직접 구현해야 했다.
2026년에는 두 조건이 모두 달라졌다. 현대 운영체제 커널은 프로세스 포크 비용을 크게 줄였다. 그리고 CGI의 진짜 단점, 즉 공통 유틸리티 부재는 2000년대에도 CGI 자체의 문제가 아니라 생태계 부재의 문제였다. 지금도 그 공백은 남아 있지만, 팀이 감당할 수 있는 범위냐 아니냐는 팀마다 다르다.
네 가지 비교 축
1. 의존성 관리: 몇 개나 제어할 수 있는가
Node.js나 Python 기반 프로젝트에서 직접 의존성이 5개라도, 해당 패키지들이 끌어오는 간접 의존성은 수십에서 수백 개에 달한다. 이 체인 어딘가에서 공급망 공격(supply chain attack)이 발생할 경우, 팀이 그 사실을 인지하고 대응하기까지 시간이 걸린다. npm·PyPI·Crates.io의 패키지 저장소 공격 사례는 꾸준히 늘고 있다.
C+CGI 스택에서 의존성을 세 개로 제한하는 것이 가능한 이유는, 추상화 계층 없이 직접 HTTP 개념을 다루기 때문이다. 개발자가 직접 제어하는 범위가 넓어지는 대신, 각 의존성이 어떤 코드를 실행하는지 검토할 수 있는 범위도 넓어진다.
다만 이것은 "의존성이 적으면 안전하다"는 단순한 등식이 아니다. 의존성이 적더라도 C 코드의 메모리 오류(버퍼 오버플로, 해제 후 접근 등)는 프레임워크가 자동으로 막아주지 않는다. 의존성 위험을 줄이는 대신, 직접 코드 품질 관리 부담을 전적으로 팀이 진다.
적합한 조건: 보안 감사 요건이 높고, 의존성 체인을 직접 통제하고 싶은 팀. 혹은 외부 패키지 업데이트 주기에 따른 리그레션이 반복적으로 문제를 일으킨 경험이 있는 팀.
적합하지 않은 조건: 개발 속도가 최우선이고, 생태계 라이브러리(OAuth, ORM, 큐 처리 등)를 폭넓게 써야 하는 팀.
2. 배포와 운영 복잡도: 얼마나 많은 구성 요소가 움직이는가
Node나 Python 기반 SaaS의 일반적인 운영 스택을 떠올리면, 리버스 프록시(nginx 또는 Caddy), 앱 서버(uvicorn, pm2 등), 데이터베이스 서버(PostgreSQL), 경우에 따라 캐시 레이어(Redis)가 각각 프로세스로 뜬다. 배포 파이프라인은 컨테이너 이미지를 빌드하고 오케스트레이션 도구가 교체 순서를 관리한다.
각 구성 요소가 독립적으로 실패할 수 있고, 로그가 분산된다. 팀이 클수록 이 복잡도는 역할 분리로 감당되지만, 팀이 작을수록 운영 부담이 개발자 개인에게 쌓인다.
C+CGI+SQLite 조합은 실행 파일 하나와 파일 하나로 상태를 관리한다. 버전 배포는 파일 교체로 완료된다. 새 요청은 새 바이너리를 자동으로 사용한다. 서버 재시작이 없으므로 배포 중 다운타임이 없다.
SQLite는 서버 프로세스 없이 파일을 직접 열어 쓰는 구조다. Postgres에 비해 운영 부담이 현저히 낮다. 그러나 쓰기 동시성이 높은 워크로드에는 SQLite가 적합하지 않다. 읽기 중심이거나 쓰기 요청이 분산되지 않는 구조에서 의미 있는 선택이다.
적합한 조건: 1~3명 규모의 팀이 풀스택을 직접 운영하며, 운영 복잡도를 최소화해야 하는 경우. 수평 확장보다 단일 인스턴스 안정성이 우선인 제품.
적합하지 않은 조건: 초당 쓰기 요청이 많거나, 여러 인스턴스가 동일 데이터베이스에 동시에 접근해야 하는 구조.
3. 보안 격리: 샌드박스를 누가 구성하는가
OpenBSD 기반의 C+CGI 구성은 운영체제 수준의 보안 도구(pledge, unveil)를 활용해 프로세스가 접근할 수 있는 시스템 콜과 파일 경로를 화이트리스트로 제한한다. httpd는 기본적으로 chroot(격리된 파일 시스템 루트) 안에서 CGI 프로세스를 실행한다.
이 방식의 의미는, 보안 격리가 인프라 구성 레이어(Docker, Kubernetes 네임스페이스, AWS Lambda 등)에 의존하지 않고 운영체제 수준에서 직접 적용된다는 것이다. 공격자가 취약점을 통해 프로세스를 탈취하더라도, 그 프로세스가 접근할 수 있는 범위가 명시적으로 제한된다.
반면 Node나 Python 기반 앱에서 동등한 격리 수준을 달성하려면 컨테이너 런타임의 seccomp 프로파일, AppArmor/SELinux 정책, 또는 별도 샌드박스 도구를 추가로 구성해야 한다. 격리 수준 자체가 낮은 것이 아니라, 달성 경로가 다르고 검증 방식이 다르다.
보안 격리 요건이 요구사항에 명시되어 있다면, "어느 스택이 더 안전한가"보다 "어느 스택의 격리 모델이 우리 팀이 검증하고 유지할 수 있는 구조인가"를 따지는 것이 더 생산적이다.
적합한 조건: OS 레벨 샌드박스 통제가 필요하고, 운영체제를 직접 선택할 수 있는 환경(예: 전용 서버, VPS)에서 운영하는 팀.
적합하지 않은 조건: 클라우드 관리형 런타임(App Engine, Lambda, Cloud Run 등)을 써야 하거나, OpenBSD 외의 환경에서 동일한 수준의 OS 샌드박스를 구성하기 어려운 팀.
4. 개발 속도와 채용 가능성: 무엇을 나중에 사는가
C+CGI 스택의 가장 명확한 비용은 초기 구현 속도와 채용이다. 쿠키 파싱, 쿼리 파라미터 검증, 입력 이스케이프 같은 기능을 프레임워크가 제공하지 않으므로 직접 구현하거나 별도 라이브러리를 선택해야 한다. 표준화된 kcgi 같은 라이브러리가 존재하지만, 해당 라이브러리의 API와 보안 모델을 별도로 검토해야 한다.
Node나 Python 생태계는 OAuth 연동, 이메일 템플릿, 큐 처리, 어드민 UI 등을 며칠 안에 붙일 수 있는 라이브러리를 제공한다. 이 속도 차이는 MVP 단계에서 특히 크다.
채용 측면에서는 더 직접적이다. C를 사용할 수 있는 웹 개발자는 Python이나 Node 개발자보다 희소하다. 팀 규모가 커질수록 이 제약이 병목이 된다.
반대로, C+CGI 스택이 "나중에 사는" 비용도 있다. 프레임워크 메이저 버전 업그레이드 비용이 없다. 런타임 deprecation에 따른 마이그레이션이 없다. CGI 1.1 스펙은 2004년에 마지막으로 발행됐고 이후 변경이 없었다. HTTP를 이해하면 지금 익힌 지식이 5년 후에도 유효하다.
적합한 조건: 창업 초기 1~2인 팀이 장기 유지보수 부담을 줄이는 것을 첫 번째 목표로 둔 경우. 또는 특정 도메인의 C 전문가가 팀에 있고 채용 확장 계획이 없는 경우.
적합하지 않은 조건: 빠른 기능 추가와 팀 확장이 예정된 스타트업, 혹은 C 개발자를 채용할 수 없는 구조의 팀.
결국 프레임워크 선택이 아니라 비용의 타이밍 선택이다
모던 프레임워크는 초기 개발 속도를 사고, 장기적으로 의존성 관리·프레임워크 진화 비용을 지불하는 구조다. C+CGI는 초기 구현 비용과 채용 풀 제약을 받는 대신, 의존성 체인·운영 복잡도·프레임워크 업그레이드에서 벗어나는 구조다.
어느 쪽이 더 합리적인가는 팀의 현재 규모, 앞으로 1~2년의 성장 계획, 그리고 보안 격리 요건이 요구사항에 얼마나 명확히 적혀 있는가에 따라 달라진다. "우리 팀에 C 개발자가 있고, 채용 확장 계획이 없으며, 의존성 감사 요건이 까다롭다"면 C+CGI는 낯선 선택이 아니라 조건에 맞는 선택이다. 반대로 팀을 빠르게 키워야 한다면, 그 시점에서 C+CGI의 비용은 재계산된다.
요구사항 단계에서 이 비용 구조를 명시하지 않으면, 기술 스택 논의는 트렌드 투표로 끝난다. 먼저 정해야 할 것은 "어느 스택이 더 모던한가"가 아니라 "우리 팀이 어느 비용을 나중에 치를 수 있는가"다.
