RTOS에 대한 기본적인 이해와 개요

 

RTOS를 왜 선택해야 하는지 알아봤기 때문에 본격적으로 RTOS 구조에 대해 확장된 얘기를 해보겠습니다. 일반적으로 제공하는 서비스들에 대해서 먼저 알아보고 그러한 서비스들을 어떻게 건설적으로 사용할 수 있는지에 대해서도 고민해볼게요. 아무래도 관심이 있는 사람이라면 더 자세히 검토해 보고 싶을 거라고 생각합니다.

 

우선 전체적인 내용과 관련이 깊은 임베디드 시스템에서 사용하는 용어들이 일괄적으로 통일되지 않았다는 것을 알고 있을겁니다. RTOS에서도 동일합니다. 많은 사람들이 RTOS라 용어를 사용합니다. 어떤이들은 커널, 실시간 커널, 또는 RTK라고 사용하기도 하는데 면밀히 살펴보면 조금 다른 개념입니다. 운영체제는 보통 핵심적인 처리를 하는 커널과 기타 다른 애플리케이션과 통신을 하거나 서비스를 제공하는 부분으로 나뉩니다. 운영체제의 핵심을 커널이라고 부르는 타세 특별히 실시간 운영체제를 커널이라고 부른다면 다른 운영체지의 커널과 혼동될 염려가 있다는 점 주의하셔야 합니다. 개발 현장에서 가장 많이 사용되는 것은 알토스, 실시간 운영 체제 정도입니다. 개인적으로 RTK라는 용어는 거의 들어본 적이 없습니다. 어떤 이들은 이 모든 용어를 같은 뜻으로 사용하기도 하는데 또 다른 사람들은 더 큰 개념인 RTOS에서 가장 기본적인 부분만을 담당하는 부분 집합을 커널이라고 부르기도 합니다. 후자는 네트워크를 지원하는 소프트웨어, 디버깅 툴, 메모리 관리 같은 부분은 RTOS에 속하지만, 커널에는 속하지 않는다고 생각합니다. 어디에서부터 커널이 끝나고 RTOS가 시작하는지에 대한 일반적인 약속이 없는터라 이러한 구분을 무시하고 용어를 차별 없이 사용할 예정입니다.

 

비슷한 이름이라고 생각하기 쉽지만 대부분의 RTOS는 데스크톱의 윈도우나 유닉스 같은 운영체제와는 차이가 있습니다.

 

1) 데스크톱 컴퓨터 운영체제는 전원이 켜질 때 시스템의 제어를 하고 나서 사용자의 응용 프로그램을 실행하도록 합니다. 사용자는 운영체제와는 별도로 응용 프로그램을 컴파일하고 링크할 수 있죠. 임베디드 시스템에서는 일반적으로 응용 프로그램과 RTOS를 결합시킵니다. 시스템이 부팅할 때는 응용 프로그램이 먼저 제어를 하고 나서 RTOS를 실행시킵니다. 따라서 데스크톱에서의 응용 프로그램과 운영체제와는 다르게 임베디드 시스템에서는 응용 프로그램과 RTOS가 서로 밀접하게 결합되어 있습니다. 자세한 내용은 뒤에서 더 알아보도록 하겠습니다. 참고로 요즘 복잡한 임베디드 시스템용 알토스는 윈도 CE나 임베디드 리눅스처럼 데스크톱 운영체제와 가까워지고 있는 추세라서 데스크톱처럼 운영체제가 먼저 시스템의 제어를 장악하고, 응용 프로그램을 실행시키는 형태로 가고 있습니다. 규모가 작은 시스템들은 이 내용처럼 아직도 응용 프로그램에서 RTOS를 결합해서 사용하는 형태를 유지하고 있고요.

 

2) 많은 RTOS들은 데스크톱 운영 체제처럼 사용자의 어플리케이션으로부터 운영체제를 완벽하게 보호하지 못합니다. 가령 대부분의 데스크톱 운영체제들이 시스템 함수로 넘겨주는 포인터들이 유효한 주소를 사용하고 있는지를 검사하는 반면 많은 RTOS들은 나은 성ㄴ능을 내기 위해서 이런 검사를 생략하곤 합니다. 물론 응용 프로그램이 올바르지 않은 주소를 가리키는 포인터를 RTOS에 넘겨 줄 경우에는 어쨌든 응용 프로그램은 망가지게 됩니다. 많은 임베디드 시스템에서 응용 프로그램이 RTOS도 같이 다운시켰는 지는 크게 중요한 부분이 아닙니다. 결과적으로는 전체 시스템을 다시 시작해야 하기 때문이죠.

 

3) RTOS들은 일반적으로 메모리를 절약하기 위해서 임베디드 시스템이 반드시 필요로 하는 서비스만 포함시키고 다른 것들은 추가시키지 않습니다. 대부분의 RTOS들은 응용 프로그램과 결합되기 전에 사용자가 설정을 변경해서 사용하지 않는 기능을 제거할 수 있도록 되어 있습니다. 사용자가 특별히 필요로 하지 않는 한 파일 관리 시스템 I/O 드라이버, 유틸리티, 심지어 메모리 관리 기능까지도 포함하지 않도록 설정할 수 있습니다.

 

소프트웨어 엔지니어는 자신만의 RTOS를 물론 직접 작성할 수 있습니다. 그러나 RTOS를 파는 다양한 제조 회사로부터 돈을주고 살 수도 있습니다. 아마 구입하게 되겠지요. 구입이 가능한 종류는 수십에서 수백 가지나 있습니다. 새로운 것들도 시장에서 계속 나오게 될 것이고요. 요즘은 현재와 차이가 큽니다. 벌써 몇 년 전 얘기지만 윈드리버 사는 pSOS를 인수했습니다. 현재는 더 이상 팔지 않고 기존에 팔았던 제품에 관해서 서비스만 지원하기도 하지요. 많게는 수백 가지의 RTOS가 시중에 나와있기는 합니다만 정말 특별한 분야가 아닌 경우 이제는 임베디드 리눅스, 윈도우 CE로 바뀌는 추세를 보이고 있습니다. 특히 임베디드 리눅스의 경우는 데스크톱 운영체제 시장에서와는 반대로 점유율이 훨씬 큰 것이 사실입니다. 갈수록 임베디드 시스템도 복잡해지고 있고, 이제는 기존의 RTOS로는 시스템을 다루기가 어려워지고 있기 때문일 것 입니다. 반면 임베디드 리눅의 경우는 공짜로 사용할 수 있다는 것에 큰 메리트가 있고 소스가 공개되어 있기 때문에 자신의 시스템에 맞도록 수정할 수 있다는 장점이 있습니다. 공짜인데 변경까지 가능하니 엄청난 메리트죠. 특정한 계약에 의거하긴 하지만, 윈도 CE 역시 소스를 공개하기로 정책을 바꾼 걸 보면 시장에서 사람들이 원하는 니즈가 무엇인지 파악이 가능합니다. 어떤 분야든 똑같은 생각을 하기 마련이죠. 인간의 기본적인 속성이라고 할 수 있겠네요. RTOS에 대해서 공부하는 사람들은 기본 개념을 이해하고 임베디드 리눅스에 대해서 공부하기를 권합니다. 자신만의 RTOS를 작성해야만하는 특별한 상황이 있을 수도 있겠지만, 그러한 일은 거의 없다고 보면 됩니다. 작성하려는 시스템이 속도나 코드 크기 또는 안정성에 대한 극단적인 제한 조건을 가지고 있지 않다면 상용되는 RTOS는 이미 버그에 대해서 검증을 했을 뿐만 아니라 여러 장점과 툴들을 가지고 있기 때문에 사용할 가치가 이미 충분히 있습니다. 아주 먼 과거에는 RTOS 제조 회사들이 상대적으로 덜 복잡한 제품을 제공했었는데 그 정도는 그리 쓸만하다고 평가받지 않았죠. 반면 오늘날 상용 RTOS들은 대부분의 시스템의 조건을 쉽게 만족하는 편입니다.

 

어떤 RTOS를 선택해야 하는 지에 대한 조언을 제공하는 것은 제가 설명하는 내용을 벗어나는 문제입니다. 많은 부분에 있어서 모든 RTOS가 서로 비슷하기 때문입니다. 각각 대부분 또는 모든 서비스들을 제공하고 다양한 마이크로프로세서들을 지원합니다. 몇몇 RTOS는 운영체제 인터페이스 표준인, POSIX 표준을 만족합니다. 다양한 RTOS 제조 회사의 영업 사원으로부터, 왜 다른 경쟁 회사 제품보다 더 빠른지, 메모리를 더 적게 사용하는지, 더 나은 응용 프로그램 인터페이스를 가지는지, 더 좋은 디버깅 툴을 가지는지, 더 많은 프로세서들을 지원하는지, 검증된 네트워크 드라이버를 가지고 있는지 등을 들어봐야 합니다. 뭘 알아야 정확한 판단을 할 수 있겠죠.

 

이어지는 글에서 더 자세한 내용을 살펴보도록 하겠습니다.