클라우드에도 리눅스가 정답일까: FTL을 바라보는 세 가지 기준

핵심 요약

• 일반적인 리눅스 컨테이너는 실행 환경을 나누지만 호스트 커널은 공유합니다.
• 사용자 공간 OS가 얼마나 잘 격리하는지는 구현 위치뿐 아니라 접근 권한과 자원을 통제하는 방식에 달려 있습니다.
• 리눅스 호환성을 확인하려면 프로그램 실행부터 파일·네트워크·오류 처리까지 살펴봐야 합니다.
• 클라우드 OS의 가치는 호환성, 격리, 운영 비용을 함께 놓고 판단해야 합니다.

클라우드에 애플리케이션을 배포하면서 운영체제까지 고민하는 일은 드뭅니다. 하지만 서로 다른 고객의 코드를 같은 서버에서 실행한다면 이야기가 달라집니다. 운영체제가 이들 사이에서 무엇을 공유하게 하는지 살펴봐야 합니다. FTL이라는 클라우드 OS를 평가할 때도 먼저 따져볼 문제입니다.

컨테이너 안에는 별도의 커널이 없습니다

컨테이너에 들어가 보면 작은 서버 한 대를 받은 듯합니다. 파일을 다루고 프로세스를 띄울 수 있으며, 네트워크에도 연결됩니다.

하지만 일반적인 리눅스 컨테이너에는 각자의 커널이 없습니다. 운영체제의 핵심인 커널을 공유하면서 각 컨테이너에서 볼 수 있는 프로세스와 파일 시스템 등을 나눕니다.

이 역할을 맡는 것이 리눅스의 네임스페이스와 cgroup입니다. 네임스페이스는 각 프로세스에 보이는 환경을 구분합니다. cgroup은 프로세스 집단이 CPU·메모리 같은 자원을 얼마나 쓰는지 관리합니다.

이렇게 하면 고객 A의 컨테이너에서 고객 B의 프로세스가 보이지 않게 할 수 있습니다. 다만 두 고객의 프로그램이 요청을 보내는 커널까지 따로 나뉘는 것은 아닙니다.

공유하는 커널에 취약점이 있으면 격리 경계에도 영향을 줄 수 있습니다. 그렇다고 모든 컨테이너가 곧바로 위험한 것은 아닙니다. 실제 위험은 권한을 어떻게 설정했는지, 어떤 기능을 허용했는지에 따라 달라집니다. 보안 패치 상태도 영향을 줍니다.

이 차이를 알아야 “컨테이너를 지원한다”는 설명과 “서로 신뢰하지 않는 코드를 안전하게 실행한다”는 주장을 구분할 수 있습니다.

첫 번째 기준: 리눅스 호환은 어디까지인가

리눅스용 프로그램은 실행 중에 운영체제에 여러 요청을 보냅니다. 파일을 열고 메모리를 확보할 때도 요청을 보내며, 네트워크로 데이터를 전송할 때도 마찬가지입니다. 이런 요청을 보내는 대표적인 통로가 시스템 호출입니다.

사용자 공간 OS는 일반 프로그램이 실행되는 영역에 운영체제 기능 일부를 구현하는 방식입니다. 설계에 따라 애플리케이션의 시스템 호출을 직접 처리하거나 다른 실행 환경에 맞게 바꿀 수 있습니다.

익숙한 명령어가 실행된다고 해서 호환성을 충분히 갖췄다고 보기는 어렵습니다. 프로그램이 기대하는 대로 동작하는지도 확인해야 합니다.

예를 들어 웹 서버가 시작됐더라도 데이터베이스까지 문제없이 돌아간다고 판단하기는 어렵습니다. 데이터베이스는 파일 잠금이나 메모리 매핑이 어떻게 동작하는지에 민감할 수 있습니다. 디스크에 기록을 확정하는 동작도 영향을 줄 수 있습니다.

요청을 정상적으로 처리하는 것만큼 오류를 처리하는 방식도 중요합니다. 같은 요청이 실패했는데 서로 다른 오류를 반환한다면 애플리케이션도 다르게 대응할 수 있습니다.

FTL의 리눅스 호환성을 평가할 때도 “리눅스 앱이 실행된다”는 설명에서 더 나아가, 어떤 앱의 어떤 동작까지 맞는가를 봐야 합니다. 기존 바이너리를 수정 없이 실행할 수 있는지, 다시 빌드해야 하는지에 따라서도 도입 비용이 달라집니다.

두 번째 기준: 사용자 공간이 곧 안전한 경계일까

운영체제 기능을 사용자 공간으로 옮기면 격리 방식을 설계할 때 선택지가 생깁니다. 예를 들어 애플리케이션의 요청을 중간에서 받아 호스트에 전달할 기능을 제한할 수 있습니다.

하지만 사용자 공간에서 실행된다는 사실만으로 격리 수준이 결정되지는 않습니다.

중간에서 요청을 처리하는 프로그램이 호스트 파일을 폭넓게 읽을 수 있다면, 그 프로그램의 취약점도 격리 경계에 영향을 줄 수 있습니다. 자원을 충분히 제한하지 않으면 한 고객이 메모리를 과도하게 써서 다른 고객의 프로그램 실행을 방해할 수도 있습니다.

격리 수준을 판단하려면 다음과 같은 질문에 답할 수 있어야 합니다.

• 애플리케이션은 호스트 커널의 어떤 기능에 접근할 수 있습니까?
• 요청을 처리하는 계층은 어떤 권한을 갖고 있습니까?
• 한 실행 환경의 장애와 자원 고갈을 어디에서 막습니까?

가상머신으로 컨테이너를 실행하는 방식도 있습니다. 사용하는 쪽에서는 컨테이너로 보이지만, 실제 격리 구조는 다를 수 있다는 뜻입니다. 컨테이너나 OS라는 이름만으로는 알 수 없으므로 경계를 어떻게 구현했는지 살펴봐야 합니다.

FTL에도 같은 기준을 적용할 수 있습니다. 격리를 강화한다는 주장을 판단하려면 무엇을 보호하고 어떤 공격을 막으려는지 구체적으로 확인해야 합니다.

세 번째 기준: 빠른 실행 이후의 비용까지 줄어드는가

클라우드에서는 시작 시간이 짧고 메모리를 적게 쓸수록 유리한 경우가 많습니다. 짧은 작업을 자주 실행하는 서비스라면 그 차이가 특히 중요합니다.

다만 사용자 공간에서 요청을 처리하는 계층에도 비용이 들 수 있습니다. 요청을 가로채서 전달하는 작업이 추가되기 때문입니다. 반대로 특정 작업에 맞게 구현하면 불필요한 처리를 줄일 수도 있습니다.

어느 쪽이 유리한지는 실제 작업을 실행해봐야 알 수 있습니다. CPU 계산이 많은 프로그램과 파일에 자주 접근하는 프로그램은 결과가 다를 수 있습니다. 시작 속도만 보고 전체 성능을 판단하기도 어렵습니다.

운영팀이 부담하는 비용도 있습니다. 장애가 났을 때 로그를 충분히 볼 수 있어야 하고, 익숙한 진단 도구가 작동하는지도 확인해야 합니다. 보안 패치를 어떻게 적용하는지도 중요합니다. 서버 자원을 아끼더라도 장애 원인을 찾는 데 시간이 더 걸리면 그만큼 이득이 줄어듭니다.

새 클라우드 OS를 도입할 만한지는 결국 실제 애플리케이션을 운영하는 총비용을 따져봐야 알 수 있습니다. 실행 속도와 메모리 사용량에 더해, 이전 작업에 드는 비용과 이후 진단·업데이트에 드는 비용까지 계산해야 합니다.

FTL을 검토할 때도 호환성과 격리 수준을 확인하고, 운영 비용까지 따져야 합니다. 리눅스가 모든 환경에서 유일한 답일 필요는 없습니다. 다만 다른 설계가 어떤 조건에서 더 적합한지는 구체적으로 보여줘야 합니다. 도입을 검토한다면 실제로 운영할 서비스에서 무엇을 먼저 검증할지 정하는 데서 시작할 수 있습니다.