필자가 프로그램이라는 세계에 처음 발을 들여 놓았을 때만 해도 PC는 존재하지 않았고 프로세스를 이용해 제품을 만들고 있었는데, 그런 것을 따로 임베디드라는 분야로 나누어 부르지 않았다. 개발 제품에 프로세스를 이용하여 처리하는 것은 매우 고급스러운 것이었고 관련 기술자도 별로 없었다.
그 당시 시스템들은 단순히 하드웨어 로직으로 처리하는 경우가 많았고 개발을 의뢰하는 고객 역시 프로세스를 이용하여 개발하는 것이 있는지 모르는 사람도 많았다. 막연히 컴퓨터라면 공상과학적인 이야기를 하게 되는 그런 세상이었다. 지금 그 시절을 되돌아보면 그 당시에 임베디드 분야가 이렇게까지 바뀌리라 그 누가 상상할 수 있었을까?
개발 패러다임의 변화
어느 날 PC라는 것이 등장하면서 우리의 세상은 많이 바뀌게 되었다. 많은 사람들이 PC에 열광했고 PC에서 동작하는 소프트웨어와 운영체제는 끊임없는 발전을 이뤘다. 많은 개발자들은 PC에 관련된 개발 직종으로 이동했고 새로 개발자의 길에 들어서는 사람들 역시 PC와 관련된 정보를 많이 접하게 됐다. 덕분에 임베디드 분야의 개발자들은 잊혀져갔다.
그렇다고 해서 임베디드 분야가 없어진 것은 아니다. 요란스럽지는 않지만 끊임없이 사용되는 것이 임베디드이고 그에 관련된 개발자들은 조용히 임베디드 분야의 변화에 적응하고 있었다.
PC 시스템은 향상된 프로세스가 나오면 그에 맞는 시스템이 구성되고 예전의 프로세스는 잊혀져버린다. 그러나 임베디드 분야는 전혀 다른 길을 걷는다. 새로운 프로세스가 나왔다고 해서 이전의 프로세스가 사용되지 않는 경우가 적다. 오히려 새로운 프로세스는 새로운 제품 분야를 만들어낸다.
아직도 임베디드 분야에서는 8비트 CPU가 사용되고 PC에서는 사용되지도 않는 8086 프로세스가 당당하게 사용된다. 가장 최신의 프로세스인 펜티엄 프로세스도 임베디드에서 사용되고 있으며 그 분야만의 독특한 영역을 갖는다.
이런 특성은 임베디드 개발자에게 많은 어려움을 가져다준다. 낮은 사양의 프로세스를 다루던 방식으로 높은 사양의 프로세스를 접근하기는 어렵다. 낮은 사양의 프로세스는 낮은 사양에 맞는 접근 방식과 개발 방식이 있고 고 사양의 프로세스들은 그에 맞는 접근 방식과 개발 방식이 있다.
문제는 이런 개발 방식의 차이점이 단순한 차이가 아니라는 것이다. 8비트 프로세스를 다룰 때 많은 개발자들은 개발 언어로 어셈블러를 선택한다. 그 주된 이유는 8비트 프로세스가 다루는 기능이 32비트 프로세스가 다룰 수 있는 기능들에 비해 상당히 단순하며 프로세스 자체의 속도가 느리고 장착할 수 있는 메모리가 작기 때문에 효율과 용량이 우선시되기 때문이다.
그래서 설령 타겟 프로세스용 C 언어 컴파일러가 있더라도 사용을 주저하게 된다. 이런 개발 습관에 적응했던 개발자라면 32비트 프로세스를 다루게 되면 무척 당황하게 된다.
32비트 프로세스를 사용하는 이유는 고객의 요구가 고기능을 요구하기 때문이다. 고속의 데이터 처리, 대량의 데이터 처리, 네트워크 지원, 그래픽 인터페이스의 지원이 그 대표적인 것이다. 만약에 이러한 처리를 요구하는 임베디드 시스템을 개발하는 개발자들이 8비트 프로세스를 개발하는 방식으로 프로그램을 개발하려고 마음먹었다면 그것은 프로젝트의 포기를 선언하는 것과 같다. 어셈블러로 TCP/IP 네트워크 스택을 어떻게 만들 것이며 그래픽 루틴을 어떻게 만들 것인가?
지금 임베디드 분야는 32비트 프로세스로 흘러가고 있다. 여전히 8비트 프로세스를 사용하여 개발하는 영역이 존재하기는 하지만 프로세스 단가의 차이도 적어지고 있고 고객이 요구하는 기능을 충족하기 위해서 많은 임베디드 시스템이 32비트 프로세스를 채택하고 있다.
이런 시스템에는 단순한 펌웨어로 시스템을 구성하기보다는 운영체제를 임베디드 시스템에 적용하고 응용 프로그램을 개발하는 것이 여러 가지 장점이 있기 때문에 유리하다. 그래서 지금의 임베디드 프로그램 개발자들의 개발 패러다임은 바뀌어야 한다. 어셈블러로 프로그램의 로직을 생각하던 것을 C나 C++ 또는 자바와 같은 상위 언어로 프로그램을 작성하는 방식으로 바꿔야 하고 단순히 펌웨어만 존재하는 구성보다는 운영체제를 지원하도록 하고 운영체제에서 동작하는 응용 프로그램을 작성하는 방식으로 바꿔야 한다.
그리 쉬운 변화는 아니더라도 이제 늦출 수 없는 대세이고 적응해야 한다. 만약 이런 패러다임의 변화에 적응하지 못한다면 32비트 프로세스로 바뀌어가는 세상에 영원히 적응할 수 없을지도 모른다.
무정전 시스템과 로그 시스템
만약에 이 글을 읽는 독자가 아침에 프로그램을 동작시키고 저녁쯤에 종료할 수 있는 그런 프로그램을 작성하고 있다면 필자는 무척 행복한 프로그램을 하고 있다고 생각할 것이다. 꼭 이 정도가 아니더라도 3일 정도 동작시키다가 프로그램을 종료만 할 수 있어도 고민할 것이 별로 없는 프로그램이라고 생각할 것이다.
필자가 이런 생각을 하게 된 것은 1년 365일 24시간 연중무휴로 시스템이 종료되지 않고 끊임없이 동작하는 프로그램을 작성하면서 무척 많은 고생을 했기 때문이다. 의외로 임베디드 계통의 프로그램은 무정전을 요구하는 시스템이 많다. 멀리 찾아 볼 것도 없다. 여러분이 들고 다니는 핸드폰도 이런 무정전 시스템 중 하나이다.
핸드폰을 아침에 켜고 저녁에 꺼주는 착한 사용자는 없다. 덕분에 핸드폰에서 동작하는 프로그램은 지속적으로 동작해야 한다. 만약에 전화하는 도중에 프로그램이 멈추어 버리는 경우가 발생하고 그 소문이 고객들에게 퍼지면 그 핸드폰을 만든 회사는 망할 수도 있다. 그래서 이런 시스템에서 동작하는 프로그램을 작성하는 프로그래머가 받는 스트레스의 양은 상상할 수도 없다.
많은 프로그래머가 프로그램을 작성할 경우에 여러 가지 모듈로 작성해서 만들어가는 것이 유리하다. 각 모듈을 작성하고 각 모듈의 이상 유무는 코딩시에 대부분 잡아나간다. 그러나 프로그래머가 신이 아닌 이상 프로그램에는 항상 숨은 버그가 존재하기 마련이고 이 버그들이 천천히 시간을 드러내고 발견되는 경우가 많다. 더구나 개발 시간에 쫓기는 경우라면 거의 반드시라고 할 정도로 발생된다.
예전에 필자가 개발했던 제품 중에 빌딩이나 건물에서 화재를 감시하는 수신반이라는 시스템이 있었다. 이 시스템은 화재 관련 법에 의해서 반드시 인증기관에서 검사를 받아야 한다. 이 검사 자체가 매우 깐깐하고 한번 검사에 통과하지 못한다면 프로젝트의 연장이나 실패를 의미하기 때문에 검사받기 전에 연구실 자체적으로 매우 다양한 검사를 수행하고, 문제가 될 수 있는 것들은 여러 가지 보완조치를 하게 된다. 이런 과정 역시 전체 프로젝트 스케줄에 의해서 지정된 시간에 마쳐야 하는 것은 당연하다.
당시 필자가 속한 팀은 긴 시간 동안 여러 가지 시험을 하고 안정성에 집중을 했기 때문에 자체적인 검증에 자신이 있었다. 기능 시험과 각종 전자적인 시험은 어느 정도 마무리되어 검사를 받기에 무리가 없었다. 시스템이 장기간 동작하는 무정전 시스템이기 때문에 검사 전까지 시스템을 지속적으로 동작시켜 안정성에 문제가 없는가를 확인하는 절차만 남겨두었다.
당연히 개발팀은 문제가 없을 거라 생각했고 일단 철수했다. 대부분의 경우 시스템이 장시간 동작하다 죽는 경우에는 메모리 누수에 의한 경우나 아니면 파일시스템에 기록되는 과정에서 나타나는데 그에 관련된 검사를 무난히 통과했기 때문이다. 그러나 시스템을 동작시킨 후 3일 뒤 연락이 왔다. 동작 중이던 시스템이 나란히 죽었다는 것이다.
문제는 그 시간이었다. 죽은 시간이 일정하지 않았다. 더구나 바로 죽지도 않았다. 어떤 경우에는 3일, 어떤 경우에는 하루 등 다양했다. 그 중 한 대는 죽지 않고 버티고 있었는데 일주일이나 버티고 있었다. 이런 결과를 통보받고 보니 개발팀들은 기능 구현에 주력하느라 장시간 동작시키는 시험을 하지 않았다는 것을 깨달았다.
시스템 디버깅에서 가장 쉬운 조건은 에러 상태가 바로바로 재연되는 경우이다. 이런 경우에는 문제를 일으키는 위치를 추적하기 쉽고 수정도 가능하다. 그런데 이 시스템의 경우에는 에러 재현이 무척 어려웠다. 검사 날짜는 다가오고 어디서 죽는지, 왜 죽는지 원인조차 파악되지 않았다.
에러 위치를 추적하기 위해서 이것저것 검사를 하는 과정에서는 그런 현상이 나타나지 않았다. 그냥 멀거니 쳐다보다가 죽은 시스템들의 상태를 조사해야 하는데 시간이 지날수록 검사 날짜가 다가올수록 점점 개발팀들의 피는 말라갔다.
시간과의 싸움에서 개발팀이 가장 먼저 선택한 것은 로그 시스템을 만드는 것이었다. 언제 어떤 동작을 하다가 죽었는가를 파악하기 위해서 시스템 상태를 주기적으로 기록하는 것이다. 물론 이것은 현장 설치시에는 제거되어야 하는 것이다. 그 양이 적지 않기 때문에 그대로 두었다가는 그 누적되는 데이터 양 때문에 문제가 되기 때문이다.
로그 기록 데이터에는 메모리 상태, 동작 중이던 프로세스 상태 통과한 함수들에 대한 기록을 남기도록 했고 일부 정보는 백업 램에, 일부는 플래시 메모리 파일시스템에 기록되도록 했다.
이런 로그 정보에 의해 문제의 원인에 대한 부분적인 단서를 알 수 있기 때문에 무정전 시스템이라면 반드시 만들어 놓는 것이 좋다. 로그 데이터를 분석하면서 가장 우려하던 메모리 누수나 프로세스의 이상 동작과 스택 파괴와 같은 부분은 아니라는 결론이 나왔다. 로그 데이터를 검토하면서 동일한 특성은 발견했는데 각 시스템들이 주었던 시점은 LCD 화면에 그래픽 처리를 하는 동안에 멈추었다는 것이다.
단순히 커널에서 동작 중이던 응용 프로그램이 작동을 하지 않는 것이 아니라 프로세서가 멈춘다는 것이었다. 이런 경우라면 두 가지 중 하나로 결론을 내릴 수밖에 없다. 하드웨어 문제이거나 하드웨어 관련된 장치 드라이버 문제였다. 그래서 이 두 부분에 관련된 집중적인 검토 결과 황당하게도 시스템에 장착된 그래픽 칩의 버그였다.
그래픽 칩이 프로세스 상태에 따라서 시스템 버스를 잡고서 멈추었고 덕분에 시스템은 정지했던 것이다. 결국은 장치 드라이버에서 이런 문제점을 우회하도록 수정했고 검사를 할 수 있게 되었다.
만약 이런 우회 방법을 찾지 못했다면 프로젝트는 실패할 수도 있었다. 필자는 여러 가지 무정전 임베디드 시스템을 만들어가면서 시스템적으로 다음과 같은 항목을 적용한다.
하드웨어적인 워치독
가장 원초적인 시스템 보안 장치로 프로세서가 정지되면 워치독에 의해서 시스템이 재동작하도록 한다. 워치독은 전기적인 요인과 같은 하드웨어적인 요인에 의해서 시스템이 정지되는 것을 막는다. 이때 프로그램적으로 고려해야 하는 것은 대부분의 경우 신속한 복구가 필요하므로 시스템의 기본적인 검사를 수행한 후 정상적이라면 최후의 상태에서 시작하도록 구성해야 하는 것이다.
소프트웨어적인 워치독
최근의 임베디드 장비들은 커널을 탑재하고 응용 프로그램은 프로세스 레벨에서 동작하도록 한다. 각 프로세스들은 미처 발견하지 못한 버그로 인하여 죽는 수가 있다. 이때는 하드웨어 워치독은 아무 쓸모가 없다. 커널과 다른 프로세스는 쌩쌩 돌아가고 있기 때문이다. 그러나 시스템은 분명히 동작하지 않는 상태가 되어버린다.
그래서 이런 경우에는 매우 안정적이고 단순하여 절대로 죽지 않을 것이라고 장담하는 프로세스를 하나 만들고 이 프로세스를 이용하여 다른 응용 프로그램들의 동작 상태를 감시하도록 한다. 만약 감시 중인 프로세스가 죽어버리면 바로 재시작시키도록 하고 로그 기록을 남겨서 나중에 프로그래머가 조치 가능하도록 해야 한다(리눅스에서는 init라는 프로세스가 있는데 이것을 이용하지는 않기를 바란다).
최소한의 로그 시스템을 탑재하라
앞에서도 필자의 경험을 이야기했지만 무정전 시스템에서 로그 시스템은 무척 유용하다. 특히 초기 제품에서는 개발 중에 미처 발견하지 못한 원인에 의해서 시스템이 정지될 수 있다. 그래서 시스템에 부하를 주지 않을 정도로 아주 작은 로그 시스템을 탑재하고 옵션에 의해서 활성화와 비활성화를 할 수 있도록 하면 차후에 문제가 발생하더라도 신속하게 문제점을 추적할 수가 있다.
프로그램의 버그라는 것은 어디서 어떤 상황에 발생하고 있는가를 파악만 해도 고칠 수 있는 것이 대부분이기 때문에 로그 시스템을 탑재하는 것을 강추한다.
하드웨어 검토 리스크를 줄이려면
임베디드 시스템 개발자들의 고민 중 하나는 기획된 상품에 대한 초기 검토 과정에서 적합한 하드웨어를 선별하고 선택하는 것이다. 회사에서 기획한 제품이나 외부 용역에 의해서 정해진 제품을 만들기 위해서 어떤 프로세스를 선택해야 하고 어떤 주변 장치를 선택해야 하는가에 대한 고민은 그리 쉽지 않은 일이다.
단순하게 가격에 대한 고려뿐만 아니라 부품 수급과 관련한 문제부터 기간 대비 장치 드라이버를 작성하거나 응용 프로그램을 작성하기 위해서 소요되는 일정들과 같은 것들을 모두 고려해야 하기 때문이다. 어느 하나라도 삐끗하면 그 프로젝트는 실패할 가능성이 농후하다. 충분한 검토가 없는 상태에서 시작하면 기껏 선택한 하드웨어가 결정적인 문제를 일으킬 수 있기 때문이다.
필자는 현재 리눅스를 이용해서 임베디드 시스템을 만들고 관련된 컨트롤러를 판매하고 있는 회사에 근무하고 있다. 이런 특성 때문에 회사는 필자에게 다양한 임베디드 시스템을 접하게 했고 리눅스 커널과 장치 드라이버에 대하여 많은 지식을 쌓게 했다.
필자가 근무하는 회사가 시스템 개발 용역 서비스를 주로 하고 있기 때문에 의뢰인이 계획하고 있는 시스템에 대한 가능성 검토를 용역 수주 전에 항상 하게 된다. 이때 필자 역시 앞에서 이야기한 개발자와 동일한 고민을 하게 된다. 잘못된 검토는 단순한 돈 문제뿐만 아니라 회사의 신용이라는 부분까지 먹칠하는 치명적인 결과를 초래할 수 있다. 이 바닥이 좁기 때문에 항상 최선을 다하고 조심해야 한다. 신용을 잃으면 금새 소문이 나기 때문이다.
문제는 개발 의뢰를 요구하는 고객들은 자체적인 기술 검토를 하지 않고 의뢰인에게 의존하여 가능한 제품인가에 대해 판단하는 경우가 많고 더불어서 무척 단기간 안에 결정할 것을 요구한다. 독자들도 알다시피 우리나라 커스터머들은 무척 급하다. 어떠어떠한 시스템을 만들고 싶은데 가능한가에 대한 대답을 거의 즉시적으로 요구하고 개발 단가부터 생산 단가까지도 알아보려 한다. 아마도 이런 류의 일들은 내부적인 개발 시스템을 가지고 있는 회사의 개발자들에게도 동일하게 발생할 것이다.
일을 수주하기 위해서는 가장 먼저 개발과 관련된 리스크가 있는가에 대한 검토부터 살펴보아야 한다. 그런데 개발자가 만능은 아니다. 만약 자신이 알고 있는 분야에 한정되어 일만 받기로 마음먹는다면 리스크가 적으므로 생존 문제를 해결할 수도 있겠지만 실제로는 굶어죽기 딱 좋거나 회사에서는 무능력자로 찍히기 좋다. 그렇다고 무조건 된다고 말할 수도 없는 것이다. 만약 이런 검토를 영업부서에서 한다면 개발자는 죽어날 것이다. 그들은 무조건 된다는 신념을 가지고 덤비는 사람들이기 때문이다.
의외로 많은 개발부에서 이렇게 적은 검토 시간에 문제가 없는 시스템을 만들기 위해서 시스템(하드웨어)을 검토하는 일을 소프트웨어 개발자가 담당한다. 일반적인 상식으로는 하드웨어를 설계하는 사람이 이런 류의 일을 할 것 같지만 주위에서는 프로그래머 중에서 하드웨어 지식이 약간 있는 사람들이 검토하는 것을 더 많이 보았다.
임베디드 기술 세계에서 떠도는 속설 중에는 하드웨어 개발자로 시작한 사람들이 프로그래머로 전향하기는 정말 어렵지만 프로그램 개발자로 시작한 사람들은 하드웨어 개발자로 전향하기 쉽다는 말이 있다. 필자가 보기에는 이 속설이 사실인 것 같다. 지금의 하드웨어들은 컴포넌트화되어 있고 매우 디지털적이기 때문에 몇몇 아날로그 영역이나 무선 통신을 제외한다면 결국은 프로그래머가 오랜 시간 뚝딱거리게 된다. 아마도 이런 영향이 크지 않을까 한다.
시스템에 적합한 하드웨어를 검토할 때 단가 문제와 수급 문제 및 시스템에 적합한가를 따지는 방법은 각각의 분야에 따라서 달라질 것이다. 또한 기술적으로 가능한가, 아니면 시간 안에 처리가 가능한가를 따지는 부분 역시 달라질 것이다. 그러나 최근의 임베디드 시스템은 고급 프로세스를 사용하고 복잡한 컴포넌트를 사용한다. 이런 시스템 구성을 적용할 수 있는 시스템이라면 임베디드 리눅스를 적용하는 것을 업으로 삼고 있는 필자의 경우에는 다음과 같은 방법을 이용하여 검토한다.
주변에 아는 사람들에게 물어 본다
“뭐야? 당연한 거 아냐?”라고 반문하는 독자들이 있을지 모르지만 필자 경험상 가장 현명한 방법이고 최선의 방법이다. 현대는 노후(Know who)의 세상이다. 주변에 기술적인 도움을 줄 수 있는 사람을 많이 알고 있는 사람들은 대부분의 문제도 쉽게 해결해버린다. 주변에 기술적인 도움을 받을 수 없는 사람은 외로운 사람이고 문제 해결도 어렵게 해나가는 사람이다.
리눅스 커널을 뒤진다
이 세상에 나온 공개된 소스 중에서 가장 다양한 하드웨어용 장치 드라이버를 가지고 있는 소스를 든다면 리눅스 커널만한 것이 없다. 임베디드 시스템에서 동작하는 소프트웨어를 작성하는 프로그래머라면 가장 힘들고 골치 아픈 부분이 하드웨어를 제어하기 위한 장치 드라이버를 작성하는 부분일 것이다. 매번 접하던 하드웨어라면 문제가 없지만 새로운 하드웨어는 기본적인 동작을 시키기도 버겁다.
이런 경우 리눅스 커널에 포함된 장치 드라이버는 거의 보물섬에 가깝다. 필자는 리눅스 커널에 있는 장치 드라이버의 동작을 살펴보고 굳이 커널을 쓰지 않는 상황이라도 보고 베낀다. 만약 리눅스 커널을 쓸 수 있는 시스템이라면 커널을 이용하여 개발할 때 개발 시간을 엄청나게 단축시켜 버린다.
물론 리눅스 장치 드라이버를 어느 정도 이해해야 하는 단점도 있지만 그 시간을 투자한 것이 절대로 아깝지 않을 정도로 다양한 소스가 존재한다. 또한 리눅스 커널에 사용된 하드웨어 칩들은 매우 대중적인 것들이다. 그래서 수급이 쉬운 장치가 많다. 그래서 필자는 리눅스 커널에서 지원하지 않는 하드웨어를 사용할 수밖에 없는 경우에는 조금 심각하게 고려한다.
소스포지와 같은 오픈소스 프로젝트 커뮤니티를 뒤진다
이 세상에는 임베디드 엔지니어뿐만 아니라 다양한 프로그래머들이 소스포지(www.sourceforge.org)에 수많은 프로그램을 공개하고 있다. 아마도 독자들이 하고 싶은 프로그램 중 상당 부분이 이 소스포지와 같은 커뮤니티에서 구할 수 있을 것이다.
물론 이런 커뮤니티에서 만든 프로그램들이 자신의 입맛에 맞지 않을 수 있다. 그러나 참고할 수 있는 소스가 존재하는 것 자체만으로 개발에 대한 부담을 훨씬 가볍게 하고 개발해야 하는 프로그램의 리스크를 대충이나마 계산할 수 있다.
인터넷을 검색한다
지금은 인터넷이라는 거대한 매체를 통하여 세상의 모든 정보가 공유되는 세상이다. 필자는 인터넷을 이용하여 개발해야 하는 제품에 대한 하드웨어를 검토하고 문제점에 대한 것이 존재하는가를 검토한다. 가장 중점을 두는 것은 관심을 갖는 하드웨어의 자료 빈도수이다. 빈도수가 적을수록 사용을 한번 더 검토해야 하는 하드웨어이다.
그런 하드웨어는 소프트웨어적인 문제가 발생했을 때 찾아볼 자료도 부족하기 때문에 나중에 문제가 발생할 확률이 높고 문제가 발생해도 해결할 방법이 없을 수가 있다. 또 한가지는 관련 자료에 대한 질답이 존재하는 자료를 중점적으로 검토한다. 그 중 답이 있는가를 항상 확인해 본다. 이런 검색은 어떤 리스크가 존재하는지를 사전에 알아 볼 수 있다.
검색도 기술이다
지금까지 소개한 필자의 방법은 어쩌면 독자들도 많이 사용하는 방법일 것이다. 여기서 한가지 덧붙이면, 검색하는 방법도 기술이라는 것이다. 필자와 다른 팀원들간에 동일한 자료를 검색할 때 똑같은 인터넷을 사용함에도 불구하고 필자가 더 빨리 정확한 정보를 찾는 경우가 많다. 이것은 경험의 문제이기 때문에 자신만의 노하우가 되는데 문서적으로 어떤 방식으로 찾아 가는가에 대한 답을 해줄 수는 없을 것이다. 하지만 검색툴을 사용하고 질의어를 선택하는 것도 하나의 기술임에는 분명하다.
그러나 최근 정부 일각에서 소리소문 없이 준비하여 입법을 예고하고 있는 ‘첨단기술유출의방지및보호에관한법률(안)’(이하 기술유출방지법이라 함)은 과학기술인들의 믿음에 큰 균열을 일으키고 희망적인 분위기에 찬물을 끼얹었으며 정부에 대한 기대를 일거에 허물어뜨렸다. 국가경쟁력을 보호, 증진하기 위해 핵심 기술을 특별 관리하는 조치가 필요하다는 현상적 요구는 인정할 수 있으나, 이 법안에 함축된 여러 독소조항과 과학기술 연구개발 인력에 대한 악의적 시각은 현장 과학기술인들에게 실망을 넘어 공분을 느끼도록 하고 있는 것이다.
임베디드 리눅스의 진입점
“도를 아십니까?”라는 질문을 길거리에서 받았다면? 아마도 여러분은 무시하고 지나갈 것이다. 그러나 이 질문은 농담 형식으로 가끔 후배들에게 던지는 질문이다. 그 이유는 필자가 오랜 시간 동안 프로그램을 작성해오면서 깨달은 것이 있기 때문이다.
필자가 프로그램이라는 것을 작성하기 시작한 지 어느덧 20년이 넘어가고 있다. 그 세월 동안 작성한 프로그램들의 숫자도 꽤 되고 여러 가지 분야를 섭렵해 왔다. 임베디드 펌웨어 프로그램, PC 유틸리티 프로그램, 네트워크 프로그램, 그래픽 편집 프로그램, 데이터베이스 프로그램, 제어 계측 프로그램 등등 기억해 보니 해보지 않은 분야가 별로 없는 것 같다.
그럼 깊이가 없을 것 같다고? 물론 그럴 수 있다. 그러나 매번 최선을 다해서 작성했고 프로그램을 대충 작성했다는 기억은 별로 없다.
예전에 필자가 직장을 구할 때 면접 담당자가 “어떤 언어를 사용하셨습니까?”라는 질문을 한 적이 있다. 그때 필자는 “언어가 왜 중요합니까?”라는 반어적 질문을 한 적이 있다. 여러 분야의 프로그램을 하면서 필자 나름대로 결론을 얻은 것은 모든 프로그램은 본질적으로 같다는 것이고 이것을 후배들에게 농담조로 “나는 프로그램의 도를 깨달았다”라고 말한다.
왜 이런 이야기를 하는가 하면, 필자가 커뮤니티에서 활동을 하면서 기존의 분야에서 임베디드 분야로 전환을 하려는 사람들로부터 ‘임베디드 리눅스 분야로 전환하려면 어떤 것을 해야 하는가’에 대한 질문을 많이 받기 때문이다. 그들의 질문 속에는 자신이 이전에 하던 분야와 어떻게 다르고 무엇을 해야 하는가를 궁금해 한다. 그리고 막연히 어려워한다.
만약 이 질문을 하는 분들이 프로그래머의 도를 깨달았다면 프로그램이라는 것은 본질적으로 다른 것이 없으며 단순히 사용하는 툴이나 알아야 하는 정보가 달라질 뿐이라는 것을 굳이 질문하지 않아도 알고 있을 것이다. 사람마다 다르겠지만 언어나 분야는 크게 문제가 되지 않는다. 단지 전환하려고 하는 분야에 대한 이해도와 관련된 툴의 사용법을 알아야 하는 것이다.
임베디드 리눅스 시스템이라고 해서 PC 프로그램과 별반 다를 것이 없다. 단지 컴파일하는 툴이 다르고 임베디드 시스템에 리눅스라는 운영체제가 올라갈 뿐이다. 도리어 임베디드 리눅스는 PC에서 사용되는 리눅스와 거의 유사하다(사실은 같다). 그래서 PC 시스템에서 프로그램을 작성하던 사람이 도리어 유리하다. 문제는 진입점이다. 오랜 경륜을 가진 개발자들은 다른 기술적인 분야로 전환하는 것을 어려워하지 않는다. 단지 단시간 내에 전환해야 하는 상황을 무서워할 뿐이다.
필자 경험으로는 임베디드 리눅스로 전환하는 데 어느 정도 구력이 있는 분들이 자유자재로 사용하기 위해서 걸리는 시간은 대략 1년으로 보고 있다. 물론 경우에 따라서 3개월 만에 적응하는 분들도 있을 것이고 1년 이상이 걸리는 분들도 있을 것이다. 하지만 3개월만에 적응하는 분들은 전세계에 몇 되지 않는 천재이거나 거짓말쟁이거나 아니면 심각한 기술적 장벽을 아직까지 못 만난 분들이다.
임베디드 리눅스로 전환하기 위해서는 가장 먼저 리눅스와 친해져야 한다. 그리고 하드웨어에 친해져야 한다. 이런 것들을 단시간 내에 적응할 수는 없는 것이다. 이때 도움이 되는 것들이 관련 학원들이다. 이곳에서 모든 것을 배우기를 원한다면 일찌감치 포기하기를 권한다.
그 강사들이 가르치는 것은 여러분에게 임베디드 리눅스를 완전히 이해시키기 위한 내용들이 아니다. 단지 임베디드 리눅스를 하기 위해서는 이러이러한 내용들을 알아야 한다고 알려주는 역할들이다. 일종의 진입점에 어떤 것들이 존재하는 것이 있는지를 수학여행처럼 소개하는 것이다. 겨우 2주 코스나 6개월 코스로 모든 것을 이해시켜 준다면 필자는 바보라는 이야기가 되기 때문이다.
결론적으로 임베디드 리눅스 분야도 결국 기존에 알고 있었던 분야와 별반 다를 것이 없지만 익숙해지는 데에는 시간이 필요하고 관련 진입점은 주변을 통해서 터득하겠지만 결실은 자신이 노력하기에 따라 달라진다는 것이다.
모든 것은 같다
다른 프로그래머들의 분야와 마찬가지로 임베디드 분야도 부단히 변화하고 기술적으로 발달하고 있다. 하지만 그 기본적인 바탕은 다른 분야와 똑같은 법칙이 적용된다. 언어를 사용하는 것이나 시스템을 설계하는 방법이나 디버깅까지 기본 법칙까지도 동일하다. 단지 다루어야 할 정보만 다를 뿐이다. 결국은 프로그램이라는 것은 모두 같은 것이다. 그래서 나는 여러분에게 질문하고 싶다. “도를 아십니까?” @
* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.
