멀티코어 PC를 제대로 이용하자
우선 , 프로세서 제조업체인 인텔과 AMD가 올해 초 데스크톱 전용 쿼드코어 프로세서를 출시한 것이 그 예이다. 듀얼코어 칩이 장착된 컴퓨터는 이제 흔히 볼 수 있는 제품이 되어 버렸다. 그러나, 사실상 이렇게 방대한 프로세싱 파워를 필요로 하는 사람은 소프트웨어 공급업체를 대신해 우수한 웹 코드를 개발해야 하는 개발자들뿐이다. 대다수의 경우, 멀티코어 칩이 장착돼 있어도, 프로세싱 파워의 상당부분은 사용되지 않는다.
소프트웨어 공급업체들도 드디어 그간의 격차를 좁혀가고 있다: 마이크로소프트, 애플, 기타 써드파티 플랫폼 공급업체들, 소프트웨어 개발자 컨소시엄들은 OS스케줄러에서 API, 언어, 라이브러리에 이르기까지 모든 것을 조정하여 멀티코어 프로세서에 적합한 환경을 만들고 있다. 물론 , 이들의 목표는 소프트웨어 개발자들로 하여금 멀티코어로의 전환에 동참하도록 하는 것이다.
멀티코어로 전환하는 속도가 점점 빨라지고 있고 , 격차도 사라지고 있다는 사실에는 의문의 여지가 없다. 일례로, 이달 초 애플은 곧 출시 예정인 맥 OS 스노우 레오파드에서 최대 8 코어의 프로세싱 파워를 사용할 수 있는 어플리케이션 개발 툴과 함께 멀티코어 프로세서를 지원하는 그랜드 센트럴(Grand Central)이라는 코드명의 새로운 첨단 기술을 선보일 것이라고 발표한 바 있다. 마이크로소프트 역시 이 같은 질문에 대해 답변은 거부했으나, 윈도우 7 OS와 관련하여 유사한 기술을 개발 중일 것으로 추측된다.
개발자들이 그랜드 센트럴 등과 같이 멀티코어를 가능케 하는 새로운 첨단 기술을 혜택을 누리기 위해서는 멀티쓰레딩, 병렬 및 동시 컴퓨팅 등의 분야에 대한 고도의 학습이 요구된다.
멀티플 코어를 활용하기 위한 시도
데스크톱 애플리케이션이 멀티코어 프로세서의 이점을 제대로 활용할 수 있도록 하는 것은 올림픽 경기나 마찬가지다. 이러한 수준의 성능을 구현해 낼 수 있는 엘리트 개발자들은 극히 소수에 불과하기 때문이다. IT 업계의 표준 및 최고의 관행을 조성하고 있는 업계 그룹인 오픈 그룹(Open Group)의 데이브 룬스베리 협력서비스부사장은 “여기서 중점을 두어야 할 부분은 <엘리트>”라고 말했다. 그는 “엘리트 개발자들의 경우 현장에 뛰어들어 스레드 라이브러리 등과 상호 작용을 할 수 있다”며, “XYZ 그래픽 기능을 실행했을 때 이상이 있다면 바로 멀티코어에서 싱글코어로의 전환이 가능하다”고 지적했다.
그러나 대다수의 개발자들은 올림픽에 출전할 정도의 기술을 갖추지 못했기 때문에, 멀티코어를 제대로 다루기 위해서는 관련 개발 툴과 OS를 필요로 한다.
포레스터 리서치의 보고서에 따르면, 소프트웨어 공급업체가 저수준 언어의 확장 및 라이브러리 제공 등을 통해 이 같은 도전에 응수하기 시작한 것으로 나타났다. 예를 들면, 래피드마인드(RapidMind)는 개발자들로 하여금 서버에 주로 이용되는 쿼드코어 AMD 옵테론 (Opteron)과 인텔의 제온(Xeon) 프로세서를 이용할 수 있도록 하는 소프트웨어 개발 플랫폼을 제공하고 있으며, 그래픽 프로세서 개발업체인 엔비디아(Nvidia)는 개발자들의 PC 그래픽 카드 접근을 돕기 위해 Cuda라는 이름의 병행 프로그래밍 언어와 라이브러리를 제공하고 있다. 그러나 두 접근방식 모두 멀티코어를 둘러싼 총체적 난제인 다양한 애플리케이션에 대한 데스크톱 PC및 맥의 멀티코어 프로세서의 잠금 해제(unlock) 문제를 제대로 제시하지 못하고 있다.
그러나, 시중에 판매되고 있는 PC의 멀티코어를 애플리케이션 개발에 사용하기 위한 노력들은 다각도로 진행 중이다. 앞서 언급한 애플의 그랜드 센트럴이 한 예로, 이는 맥 사용자의 애플리케이션 개발을 돕기 위해 고안된 기술이다. 유럽위원회는 ‘병렬 실시간 개발을 위한 자바 엔터테인먼트(Java Entertainment for Parallel Real-time Development)’, 일명 ‘Jeopard’라 불리는 멀티코어 상의 자바를 근거로 실시간 애플리케이션을 위한 프레임워크 설정 - API, OS 확장, 언어 지원 등 -을 위해 500만 유로를 지원하겠다고 밝혔다. (오픈 그룹을 비롯한 다수의 그룹들이 이 프로젝트에 참여하고 있다.)
최근, 업계 컨소시엄인 크로노스 그룹(Khronos Group)은 멀티코어 애플리케이션 개발을 위한 무료 표준을 제정하기 위해 컴퓨트 워킹 그룹(Compute Working Group)을 발족했다. 그간 그래픽 및 미디어 디스플레이 개선을 위한 그래픽 프로세서 이용의 업계 표준 제정에 중점을 두어 왔던 크로노스 그룹은 최근에는 그래픽 프로세서 와 멀티코어 CPU 모두를 모든 목적에 사용될 수 있는 공통 프로세싱 리소스들의 버추얼셋으로 사용하는 방안들을 모색 중이다. 그래픽 프로세서는 멀티코어의 구조를 갖고 있는 경우가 많다. 크로노스 그룹의 회장이자 엔비디아의 모바일 콘텐츠 부사장직을 겸하고 있는 닐 트레베는 이 표준이 향후 “많은 아키텍쳐 관련 결정 및 리소스간 자동 맵핑(mapping)에 영향을 미치게 될 것”이라고 말했다. 이 표준은 이르면 6개월 내 시장에 공표될 것으로 기대된다.
트레베는 컴퓨트 워킹 그룹이 애플의 OpenCL를 채택할 가능성이 높은 것으로 내다봤다. OpenCL은 애플리케이션 개발자들로 하여금 그래픽 프로세서들을 직접 이용할 수 있도록 하는 기술로, 맥 OS X 스노우 레오파드는 C 프로그래밍 언어를 기반으로 한 OpenCL을 지원할 예정이다.
한편, 마이크로소프트는 닷넷 개발자들이 멀티코어를 이해하는데 필수적인 기초적 병행 프로그래밍 기술을 배울 수 있도록 하는 병행 컴퓨팅 이니셔티브(Parallel Computing Initiative)를 개시했다. 이니셔티브에는 동시 실행시간, 닷넷 프레임워크 3.5로의 병행 확장을 위한 기술 미리보기, 도메인별 라이브러리, 풍부한 가상화 경험을 가능케 해주는 패키징 애플리케이션 서비스, 프로파일링 툴 등이 포함되어 있다.
포레스터는 이 외에도 향후 2년 내에 다양한 기술들이 시장에 쏟아져 나올 것으로 기대하고 있다.
개발자들이 어디에 중점을 두어야 할 지는 아직 불확실
버클리 캘리포니아 대학의 크르스테 아사노빅 부교수는 2~3년 내 완전히 막다른 골목에 도달하여 애플리케이션을 처음부터 재작성해야 하는 일이 없도록 하려면 개발자들이 병렬 프로그래밍의 스타일을 선택하는 데 있어 신중을 기해야 한다고 말했다. 그는 “현재까지 제시된 프로그래밍 환경들은 수없이 많지만, 결국 이들 중 어떤 것이 시장에서 채택될 지는 모를 일”이라고 지적했다.
그렇다면, 개발자들은 어디에 베팅을 해야 하는가?
아사노빅은 어도비 포토샵이나 오디오 파일을 위한 필터처럼 간단한 데이터 병렬 구성의 경우, Cuda, OpenCL, 인텔이 CT 등의 언어를 사용할 것을 권장했다. 그는, 이들 대부분이 “GPU을 위해 개발되었지만, 멀티코어 CPU에서도 잘 구동될 것”이라며, “만약 내가 프로그래머라면, 데이터 병렬 프로그램을 선택하고 내 애플리케이션이 이에 맞게 맵핑될 수 있는지를 알아볼 것”이라고 말했다.
이는 비즈니스 데이터를 분석하는 애플리케이션뿐만 아니라 대용량의 이미지, 그래픽, 비디오 등을 처리하는 데이터 병렬 애플리케이션 또한 멀티코어로의 전환에 따른 우선적 수혜자임을 시사하고 있다. 그 이유는 이러한 태스크들이 여러 단위로 분할되어 동시에 프로세싱될 수 있기 때문이다. 분할된 태스크는 각각 사용 가능한 코어에 배분되어 프로세싱된 후, 마지막 단계에서 다시 합쳐진다. 예를 들면, 화소를 삽입하는 일이나 메일링 주소를 삭제하는 일들 역시 이 같은 방법으로 개별 단위로 쪼개진 후, 동시에 처리되는 식이다.
그러나, 문제는 대부분의 태스크들이 이처럼 자연스럽게 병렬식 프로세싱으로 이어지지 않는다는데 있다. 일반적으로 한 코어가 해당 업무를 마칠 때까지 나머지 코어들은 대기 상태에 머무르게 된다. 이러한 경우, 개발자들은 각각의 프로세서(아사노비는 이를 가리켜 “태스크 농장”이라고 부르고 있다)가 별도의 주어진 태스크들을 실행할 수 있도록 자연스럽게 태스크를 분할할 수 있는 방법을 찾아야 한다. 예를 들어, 워드 프로세서에서, 한 코어가 프린트 스풀링을 다루는 동안, 다른 코어는 이와 연관성이 없는 스펠링 체크를 담당할 수 있다. 비결은 각 코어에 태스크를 배분하기에 앞서 태스크들간 상호 의존성이 없음을 확실히 하는데 있다.
이론적으로 각각의 스레드가 사용 가능한 모든 코어에서 처리될 수 있는 만큼, 처음부터 멀티-스레디드로 고안된 애플리케이션이 멀티코어 프로세서의 혜택을 누릴 기회가 많음은 분명한 사실이다. 그러나, 현실에서는 많은 스레드가 상호의존적 성향을 갖고 있어서 코어가 꼼짝 못하게 되는 상황이 발생한다. 이에 따라, 포레스터는 개발자들에게 “스레드별 임무를 조절하고 , 병행 업무를 동시에 진행시키며, 멀티-스레디드 코드와 관련된 문제가 초래되지 않도록 공유 데이터를 관리하고 , 자동적으로 다수의 동시 실행 스레드를 분류할 수 있도록 코드를 작성해야 한다”고 조언하고 있다.
오픈 그룹의 룬스베리 역시 개발자들에게 소프트웨어의 작성법을 단순화할 것을 권고하고 있다. 그는 “손으로 직접 작성한 알고리즘이 많다면, OS나 언어의 개선으로 인한 어떠한 이점도 누릴 수 없게 된다”고 지적하면서, “특정 OS의 기능의 혜택을 누릴 수 있도록 설계된 낡은 코드 혹은 직접 작성한 코드들을 많이 갖고 있다면, 이들을 캡슐화시키는 것을 고려하고 자체적으로 지원되는 부분들로 이동시키기 시작할 필요가 있다”고 말했다.
소프트웨어 아키텍처가 지속적으로 변화하면서 많은 개발자들이 복잡한 애플리케이션을 제작하고 있는데, 이는 결과적으로 애플리케이션의 발달을 어렵게 하고 있다. 이 외에도, 아사노빅은 성능 이슈들이 개발자들로 하여금 “성능 목표에 도달하기 위해 깨끗하지 못한 방식으로라도 많은 것들을 집어넣도록 부담을 주고 있다”고 지적했다. 그는 화이트보드에 소프트웨어의 프로세싱 흐름을 그려보면, 스레드와 태스크가 어떻게 병행 처리되고 있는지를 파악할 수 있을 것이라고 덧붙였다.