메모리 안전한 C에서 점프와 코루틴은 어떻게 가능할까: Fil-C의 setjmp/longjmp

C를 안전하게 만들겠다는 도전

C 언어는 빠르고 강력하지만, 그만큼 위험해요. 포인터로 메모리를 직접 주무르다 보니 잘못 건드리면 보안 구멍(버퍼 오버플로 같은)이 생기기 쉽거든요. 세상의 심각한 보안 취약점 상당수가 이런 C/C++의 메모리 문제에서 나와요. 그래서 요즘 러스트(Rust)처럼 메모리 안전을 보장하는 언어가 뜨는 거고요.

그런데 기존 C 코드를 전부 러스트로 다시 쓰는 건 현실적으로 거의 불가능하죠. 그래서 등장한 게 Fil-C예요. 'C 문법은 그대로 쓰되, 컴파일러가 메모리 안전을 강제로 지켜주는' 변종 C라고 보면 돼요.

setjmp와 longjmp, 그게 뭔데

이번 글의 주제는 그 Fil-C에서 setjmp와 longjmp를 안전하게 구현한 이야기예요.

이게 뭐냐면, C에는 함수 호출의 정상적인 흐름을 건너뛰고 특정 지점으로 한 번에 점프하는 기능이 있어요. setjmp로 '여기 위치를 저장해둬'라고 표시해두고, 나중에 한참 깊숙한 함수 안에서 longjmp를 호출하면 저장해둔 그 지점으로 단번에 되돌아가는 거예요. 마치 게임의 세이브 포인트 같은 거죠.

이건 예외 처리(에러가 나면 한 번에 위로 탈출), 그리고 코루틴이나 협력형 멀티태스킹(여러 작업을 번갈아 실행하는 것)을 구현할 때 쓰여요.

왜 어려운 문제일까

문제는 이 점프가 메모리 안전과 정면으로 충돌한다는 거예요. longjmp를 하면 스택(함수 호출 정보가 차곡차곡 쌓이는 메모리)을 통째로 되감거든요. 이때 중간에 있던 변수나 포인터 상태가 엉키면, 안전을 보장하려고 만든 Fil-C의 약속이 깨질 수 있어요.

특히 컨텍스트 스위칭, 즉 실행 중인 작업을 멈추고 다른 작업으로 갈아타는 동작은 스택을 통째로 바꿔치기하는 거라 더 까다로워요. 일반 C라면 그냥 레지스터와 스택 포인터를 저장/복원하면 끝이지만, 모든 포인터에 안전 정보(어디까지 접근해도 되는지)를 붙여 관리하는 Fil-C에서는 이 정보까지 한 치의 어긋남 없이 보존해야 하거든요.

Fil-C는 이걸 풀기 위해 점프 지점의 상태를 안전하게 캡처하고, 되돌아갈 때 메모리 접근 권한 정보가 깨지지 않도록 관리하는 방식을 설계했어요. 핵심은 '성능은 최대한 살리면서도, 점프 전후로 단 한 순간도 안전 보장이 뚫리지 않게 한다'는 거예요.

업계 맥락

메모리 안전은 지금 시스템 프로그래밍에서 가장 뜨거운 주제예요. 러스트가 대표 주자고, 구글·MS·미국 정부까지 '메모리 안전 언어로 옮기자'고 권고할 정도죠. 하지만 러스트는 새 언어를 배워야 하는 비용이 크고, 기존 C 자산과 섞어 쓰기도 번거로워요.

Fil-C의 접근은 달라요. '코드는 그대로 두고 안전만 입히자'는 거니까요. 대신 그 대가로 실행 속도가 조금 느려지는데, 이번 setjmp/longjmp 같은 까다로운 기능까지 안전하게 지원한다는 건 '장난감이 아니라 진짜 실무 C 코드를 돌릴 수 있는 수준'으로 가고 있다는 신호예요.

한국 개발자에게

당장 회사 코드를 Fil-C로 바꾸라는 얘기는 아니에요. 하지만 임베디드, 보안, 시스템 분야에서 일하거나 관심 있는 분이라면 이 흐름은 꼭 알아둘 가치가 있어요. 앞으로 '기존 C 코드를 어떻게 안전하게 만들 것인가'가 큰 화두가 될 거고, Fil-C 같은 시도가 그 해법의 한 갈래거든요.

setjmp/longjmp의 동작 원리 자체도 코루틴과 비동기 프로그래밍의 밑바탕을 이해하는 데 좋은 공부가 되고요.

마무리

'안전과 성능, 그리고 기존 코드 호환성'이라는 세 마리 토끼는 원래 같이 잡기 어렵다고들 했어요. Fil-C는 그 어려운 길을 조금씩 뚫어가는 중이에요.

여러분은 어떻게 생각하세요? 기존 C를 안전하게 감싸는 Fil-C 방식과, 아예 러스트로 새로 쓰는 방식. 둘 중 어느 쪽이 더 현실적인 미래라고 보시나요?