2026년에 C와 CGI로 웹앱을 만든다면, 보안도 단순해질까요?

핵심 요약

• C·CGI·SQLite 조합을 쓰면 별도 애플리케이션 서버와 데이터베이스 서버를 운영하는 부담을 줄일 수 있습니다.
• 일반적인 CGI는 요청마다 프로그램을 실행하므로 구조는 단순하지만, 실행 비용이 매번 듭니다.
• 의존성이 적어도 C의 메모리 오류나 웹앱의 인증 취약점이 사라지지는 않습니다.
• 유지보수 비용을 따질 때는 외부 패키지뿐 아니라 직접 관리할 코드가 얼마나 되는지도 봐야 합니다.

2026년에 웹앱을 만들면서 C와 CGI부터 떠올리는 사람은 많지 않을 겁니다. 그래도 작은 서비스 하나를 운영하는 데 관리할 구성 요소가 얼마나 필요한지 생각해보면, 이 조합을 검토할 이유는 있습니다. 오래된 기술을 쓰면 단순해지는 부분도 있지만, 그만큼 개발자가 직접 맡아야 할 일도 생깁니다.

C와 CGI로 줄일 수 있는 것

가령 개인용 링크 저장 도구를 만든다고 해보겠습니다. 링크를 입력하고 목록을 보다가 필요 없는 항목을 삭제할 수 있으면 됩니다. 브라우저가 요청을 보내면 웹 서버가 C 프로그램을 실행하고, 프로그램은 SQLite에서 데이터를 읽어 HTML을 돌려주는 식으로 구성할 수 있습니다.

여기서 CGI는 웹 서버가 외부 프로그램과 요청·응답을 주고받는 약속입니다. 프로그래밍 언어나 프레임워크의 이름은 아닙니다. C로 만든 실행 파일도 이 약속에 맞춰 입력을 받고 결과를 출력하면 웹 요청을 처리할 수 있습니다.

일반적인 CGI 구성에서는 요청마다 프로그램을 실행합니다. 애플리케이션 프로세스를 계속 띄워두고 관리할 부담은 줄어듭니다. 대신 프로그램을 시작하고 초기화하는 비용이 매번 듭니다. 방문자가 드문 도구라면 감수할 만하지만, 요청이 몰리는 서비스에서는 실제 부하를 걸어 확인해야 합니다.

구조가 단순하다고 처리 효율까지 좋은 것은 아닙니다. 실행 파일이 작다는 이유만으로 웹앱 전체가 빠르다고 할 수는 없습니다.

SQLite와 OpenBSD가 덜어주는 부담

SQLite는 애플리케이션 안에서 동작하는 데이터베이스입니다. 별도 데이터베이스 서버를 운영하지 않아도 SQL과 트랜잭션을 사용할 수 있습니다. 작은 웹앱이라면 설치하고 운영할 구성 요소를 줄이는 데 도움이 됩니다.

그렇다고 데이터까지 알아서 관리되는 것은 아닙니다. 백업과 복구는 여전히 챙겨야 하고, 테이블 구조를 바꿀 일도 있습니다. SQLite는 여러 읽기 작업을 처리할 수 있지만, 쓰기 작업은 한 번에 하나씩 진행합니다. 우리 서비스에 맞는지 판단하려면 이용자 수와 함께 동시에 얼마나 자주 쓰는지도 봐야 합니다.

OpenBSD에서는 프로그램의 권한을 제한하는 장치도 쓸 수 있습니다. pledge는 사용할 수 있는 시스템 기능을 제한하고, unveil은 접근할 수 있는 파일 경로와 권한을 제한합니다. 링크 저장 도구에 필요한 파일과 기능만 허용해두면, 취약점이 생겼을 때 피해 범위를 줄이는 데 도움이 됩니다.

다만 이런 제한은 프로그램이 어떻게 동작하는지에 맞춰 적용해야 합니다. OpenBSD 위에서 실행한다고 해서 애플리케이션의 모든 동작이 자동으로 제한되지는 않습니다.

의존성이 적어도 메모리는 안전해지지 않습니다

외부 패키지를 줄이면 업데이트를 챙길 대상도 줄어듭니다. 하지만 여기서 곧바로 “그러므로 더 안전하다”라고 판단하면 따져야 할 비용을 놓칩니다.

C는 메모리 접근이 안전한지 자동으로 보장하지 않습니다. 입력 길이를 잘못 계산하면 할당된 공간 밖에 데이터를 쓸 수 있고, 이미 해제한 메모리를 다시 사용하는 오류도 생길 수 있습니다. 외부 입력을 받는 웹앱에서는 이런 실수가 보안 문제로 이어질 수 있습니다.

프레임워크를 빼면 그동안 프레임워크가 해주던 일을 직접 처리해야 합니다. 요청을 해석하고 입력 크기를 제한하는 일부터 오류 처리와 세션 관리까지 챙겨야 합니다. 보안 검토를 거친 라이브러리까지 없애고 직접 구현한다면, 패키지 목록은 짧아져도 검토할 자체 코드는 늘어납니다.

웹 보안도 따로 챙겨야 합니다. SQL에 사용자 입력을 문자열로 이어 붙이면 SQL 삽입 공격을 받을 위험이 생깁니다. 저장한 링크 제목을 HTML에 그대로 출력하면 스크립트가 실행되는 문제가 생길 수 있습니다. 전자에는 매개변수 바인딩이, 후자에는 출력 위치에 맞는 이스케이프 처리가 필요합니다.

의존성 최소화, 메모리 안전성, 권한 제한은 저마다 다루는 문제가 다릅니다. 하나를 잘 챙겼다고 다른 문제까지 해결되지는 않습니다.

유지보수는 패키지 관리만으로 끝나지 않습니다

기능이 적고 변경할 일도 드문 데다 운영자가 C와 운영체제에 익숙하다면 이 조합을 검토해볼 만합니다. 개인용 도구나 제한된 사용자가 쓰는 서비스에서는 적은 구성 요소로 오래 운영하겠다는 목표에 잘 맞을 수 있습니다.

반대로 로그인 방식과 외부 연동이 계속 늘어나는 서비스라면 계산이 달라집니다. 프레임워크가 제공하던 기능을 직접 만들고 검증하는 데 더 많은 시간이 들기 때문입니다. 다음 담당자가 코드를 이해하고 수정하는 데 드는 비용도 함께 따져야 합니다.

배포 파일이 하나여도 업데이트할 책임은 남습니다. 예를 들어 SQLite를 실행 파일에 포함했다면, 수정 버전을 반영하려고 다시 빌드하고 배포해야 합니다. 눈에 보이는 설치 절차가 줄었어도 내부 구성 요소를 계속 관리할 필요까지 없어지는 것은 아닙니다.

제가 이 선택에서 중요하게 보는 것은 직접 책임질 범위입니다. 오래 운영하려면 패키지가 몇 개인지보다 문제가 생겼을 때 원인을 찾고 안전하게 고칠 수 있는지가 더 중요합니다.

C와 CGI를 쓰면 작은 웹앱의 운영 구조를 단순하게 만들 수 있습니다. 보안과 유지보수까지 쉬워지려면 덜어낸 도구가 하던 일을 누가 맡을지도 정해야 합니다. 선택할 때는 의존성 목록이 얼마나 짧아지는지뿐 아니라, 앞으로 직접 감당할 일이 얼마나 줄어드는지까지 따져봐야 합니다.