'2016/07'에 해당되는 글 10건

남중국해 분쟁에 대한 국제상설중재재판소(PCA)의 중재를 앞두고, 중국이 자국에 불리한 판결을 예상하고 미리 군사적인 움직임을 보인다는 뉴스를 보았는데, 아니나 다를까, 오늘 (2016.07.12) 중국이 주장하는 구단선(nine-dashed line)이 법적 근거가 없다는 판결이 나왔다. 

남중국해를 끼고 있는 여러 국가들(대략 중국, 대만, 베트남, 필리핀, 인도네시아 등)이 각자 서로 다른 해안 국경선을 그리면서 영유권 분쟁을 지속하는 이유는 당연히 남중국해에 돈이 되는 자원이 많기 때문이다. 다만 이들 중에서 중국이 인공섬을 만들고 군사시설을 구축해 가면서까지 적극적으로 영유권을 행사하면서 주변국의 활동(주로 어업일 듯)에 피해를 입혔고, 이를 보다 못한 필리핀이 PCA에 제소를 하면서 지금에 이르렀으며, 결국 필리핀이 승소했다. 하지만 PCA의 판결 자체가 집행 능력을 갖는 것은 아니라서 중국이 이미 실효 지배하는 섬들을 반환하도록 강제할 수는 없다. 필리핀 입장에서는 국제사회의 공감을 얻어 냈기 때문에 중국이 더이상 무분별한 인공섬 건축과 군사적인 위협을 끼치지 못하도록 하는 데 목소리를 키울 수는 있게 됐고, 필리핀과 비슷한 입장을 갖고 있는 다른 국가들도 PCA에 제소를 해서 승소할 가능성도 높아졌다.

남중국해 분쟁의 근본 원인은 매장된 자원이겠고, 파생되는 이유 중에는 각국의 군사적인 목적도 있는 듯 하다. 중국이 남중국해를 온전히 자국의 영해로 만들지 않게 되면, 그 바다에는 세계 어느 나라라도 자유롭게 드나들 수 있게 된다. 그러면 '항행의 자유'를 주장하는 미국이 자국의 항공모함을 이끌고 중국 본토와 더 가까운 곳을 아무 제지 없이 자유롭게 드나들 수 있다는 의미이고, 중국 입장에서는 자국의 바로 아래를 지나다니는 강력한 군사적 존재를 지켜볼 수밖에 없으므로 보통 부담스러운 일이 아닐 것이다.

어쨌든 필리핀은 유엔 해양법협약(UNCLOS; United Nations Convention on the Law of the Sea)을 기준으로 중국이 필리핀의 주권 행사를 방해하는 것으로 간주하여 국제법에 호소를 했고, 반면에 중국은 대략 1948년부터 구단선을 정의한 자국의 지도를 기반으로 하는 역사적인 이유를 들어서 남중국해 대부분의 영유권을 주장했다. 

이번 판결에 영향을 끼친 요소가 여러 가지가 있겠지만, 내가 보기에는 '섬'에 대한 개념이 특히 중요한 영향을 끼친 것 같다. 국제법상 근거가 있고 이미 세계의 수많은 나라들이 합의하고 비준한 UNCLOS (심지어 중국도 비준했다. 황당하게도 미국은 비준에 참여하지 않았다.)의 기준도 모두 대륙 또는 섬의 해안선에서부터 시작하기 때문이다.

UNCLOS에서는 섬, 암초, 간출지, 인공섬은 아래와 같이 간주한다:

• '섬(island)'은 바다 위로 항상 드러나 있는 영역이 존재하고, 그 드러나 있는 땅에서 인간의 삶을 유지시킬 수 있는 경우에 해당된다. 섬은 영해와 배타적 경제 수역을 모두 주장할 수 있다.
• '바위(rock)'는 암초 중에서 물 위로 항상 드러나는 부분이 존재하는 경우에 해당하고, 다만 그 자체로 인간의 삶을 지속시킬 수 있는 능력이 없다. 암초는 영해만 주장할 수 있고, 배타적 경제 수역을 주장할 수 없다. 물속에 잠긴 부분은 해당되지 않는다고 볼 수 있다.
• '간출지(low-tide elevation)'는 땅의 일부가 간조(low-tide)일 때에만 물 위로 드러나는 경우이다. 간출지는 영해로 주장할 수 없고, 당연히 배타적 경제 수역의 기준으로도 쓸 수 없다.
• '인공섬(artificial island)'은 원래 섬이 아닌 부분을 인간이 살 수 있도록 인위적으로 건축해서 만든 경우인데, 국제법상 이것을 '섬'으로 인정하지 않는다. 따라서 영해와 배타적 경제 수역 모두 주장할 수 없다.

중국이 여러 개의 인공섬을 건축하고, 군사시설을 짓고 사람도 살게 하는 등 여러 방법을 동원했지만, 그렇게 만든 곳 모두 PCA로부터 영해라고 주장할 효력을 상실했다고 볼 수 있다. 

사실 중국뿐만 아니라 대만도 스프래틀리 군도 중에서 땅으로 드러난 영역이 가장 큰 이투아바 섬(Itu Aba Island)을 실효 지배하고 있는데, 이마저도 암초에 해당하기 때문에 영해의 기준으로 삼을 수 없다고 한다. 대만은 이 섬에 약 1200미터의 활주로까지 건설해 두었는데 결국 소용 없게 되었다 (지못미) (여전히 실효 지배하고 있는 상태를 다른 국가가 내쫓을 수는 없겠지만).

스프래틀리 군도의 이투아바 섬 (출처: 위키피디아 [4])

대만은 그나마 섬처럼 보이는 가장 큰 이투아바 섬 1개를 실효지배하고 있는데도 효력을 상실했고, 반면에 중국은 스프래틀리 군도에서 그보다 작은 아주 많은 영역과 인공섬들을 가지고 영해를 주장하고 있었는데, 결국 이번 판결을 통해서 스프래틀리 군도에서 섬은 하나도 없다는 것과 당연히 배타적 경제 수역이 하나도 없다는 사실을 공고히 하게 됐다.

이에 따라 앞서 언급했듯이 남중국해의 가운데 영역은 누구나 드나들 수 있는 바다(international sea)가 되었고, 미국이 항행의 자유를 근거로 중국을 더욱 압박할 수 있게 되었다. 우리나라 입장에서 남중국해로부터 얻는 직접적인 이익이나 손해는 없지만, 우리나라에 지대한 영향력을 행사하는 두 강대국의 힘싸움에서 우리는 어떻게 해야 할까?

<참고자료>

[1] Philippines vs. China: Court to rule on South China Sea fight, http://edition.cnn.com/2016/07/11/asia/philippines-china-south-china-sea-hague-ruling/

[2] 남중국해에 인공섬 만드는 중국의 꼼수, http://weekly.donga.com/List/3/all/11/98934/1

[3] 상설중재재판소 "中, 남중국해의 구단선(九段線) 법적 근거 없다", http://news.chosun.com/site/data/html_dir/2016/07/12/2016071202817.html

[4] 이투아바 섬 위성사진, https://en.wikipedia.org/wiki/Taiping_Island#/media/File:Taiping_Island_and_Zhongzhou_Reef_ISS.jpg

무선 메쉬 네트워크에서 멀티홉 라우팅을 하면서, 라우팅을 해야 되는 flow가 아래와 같이 다르면, iptables를 쓸 때에도 필터링을 서로 다른 곳에서 해 주어야 한다:

1) 다른 노드가 source가 되고, 현재의 메쉬 라우터는 중간 노드가 되는 경우

2) (실제로 그럴 일은 별로 없겠지만) 메쉬 라우터 자체에서 패킷이 생성되었을 경우, 즉 메쉬 라우터 자신이 출발지 노드(source)가 돼서 응용 계층으로부터 패킷이 주입되는 경우

특정 포트 또는 목적지로 가는 패킷을 필터링/분류하고 라우팅을 변경하고자 할 때:

- 1번의 경우에는 PREROUTING 단계에서 hook을 걸어야 패킷이 걸린다.

- 2번의 경우는 OUTPUT 단계에 hook을 걸어야 패킷이 걸린다.

<2016.07.17 추가>

내가 하려는 작업은:

• 멀티홉 라우팅 경로에서 중간노드 역할을 수행하는 라우터가 특정 조건의 패킷에 대하여 마킹을 한다. (--set-mark 옵션)
• 특정 번호로 마팅된 패킷에 대응하는 별도의 라우팅 테이블을 만들어서 해당 패킷들만을 위한 라우팅 경로를 설정한다.

이 작업을 수행하려면 iptables에서 mangle 테이블을 써야 하고, 이 때 PREROUTING, OUTPUT 체인이 갖는 의미는 참고자료 [1] 에 잘 설명되어 있다.

<참고자료>

[1] http://marcof.tistory.com/35

링크드인(LinkedIn) 계정은 오래 전부터 만들었지만, 대략 2년여 전부터 프로파일 페이지를 본격적으로 관리하면서 Skill이나 각종 실적들을 업데이트하고 있다. 주로 학교 동료, 교수님들, SNS 친구들, 동종 업계 사람들 위주로 네트워크를 연결하고 있는데, 여기에 예외적으로 네트워크에 추가되는 사람들이 있다면 바로 헤드헌터들이다.

링크드인 자체가 잘 정리되어 있고 검색이 용이한 인력 시장이라서 헤드헌터들이 많이 활동하는 것은 당연한 이치다. 하지만 내 계정에 지인이나 관련 분야 사람이 아닌 헤드헌터들로부터 연결 요청이 들어오면 매번 이들을 인맥에 추가해야 할 지 잠시 고민을 하게 된다. 왜냐하면, 그동안 꽤 많은 헤드헌터들의 연결 요청이 들어왔었고, 초반에는 그 요청을 거의 다 수락했었지만, 그 중에서 실제적으로 채용과 관련된 얘기가 진행된 경우는 손에 꼽을 정도였기 때문이다. 실제로 작년에 딱 두 번 있었다. 다만 작년에는 내가 여전히 박사과정 졸업이 가시적이지 못했기 때문에 채용을 진행할 수가 없었던 기억이 있다.

아마 헤드헌터들 입장에서는 담당 분야의 여러 인력들에 대한 풀(pool)을 형성해 뒀다가, 그때 그때 회사에서 필요로 할 때 인력을 빠르게 제시하기 위한 목적으로 인맥을 추가하는 것으로 예상된다. 문제는 내가 헤드헌터들과 연결이 되고 나서도 그들과 거의 소통할 일이 없고(헤드헌터 쪽에서 채용 정보를 제시하지 않는 이상) 그들의 활동이 링크드인 페이지의 타임라인 상에서 나에게 도움을 주지도 않는다는 것이다. 적어도 나와 관련된 분야의 학생들이나 동료들이 올리는 정보성 글과 그들의 프로파일 변화는 나에게 직/간접적인 도움이 되고 있는 것과 대조적이다. 따라서 이미 내 인맥에 여러 명의 헤드헌터가 들어와 있는 상태에서, 내가 보기에 그들과 유사한 또다른 헤드헌터가 연결을 요청해 오면, 그 새로운 사람을 추가하는 것이 과연 나에게 어떤 효용이 있는지 회의적으로 생각하게 되는 것이다. 게다가 내 인맥이 실제 연구/업무 분야의 사람들이 아닌 헤드헌터들로 구성되는 비중이 자꾸만 커지는 것이 (이러한 구성이 피해를 주는 것은 아니지만) 조금 어색한 기분이 드는 측면도 있다.

물론 헤드헌터들 중에서 어떤 분은 링크드인에서 꾸준히 활동하시면서 채용에 도움이 되는 정보를 직접 포스팅함으로써 내 타임라인에서도 그러한 유용한 정보 글을 볼 수 있어서 도움이 되는 사례도 있으나, 지금껏 내 인맥에 추가된 수십 명의 헤드헌터들 중에서 딱 한 분만 그렇게 하고 계신다. 그리고 그렇게 꾸준히 활동하시는 분이 바로 나에게 채용 정보를 제안하셨던 분이기도 하다. 이 분은 프로파일 페이지도 다른 헤드헌터들과는 달리 예사롭지 않았고, 아주 전문적으로 느껴졌었다. 아마도 내가 헤드헌터에게 먼저 채용 관련 요청을 해야 한다면 이분께 메세지를 보낼 것이다.

그리고 사실 내 링크드인 프로파일은 굳이 나와 연결을 맺지 않더라도 볼 수 있기 때문에, 아마 정말로 나에게 제안할 만한 채용 정보가 있다면 단순한 연결 요청만 하는 것이 아니라 메세지를 남기거나 채용 요청할 때 어떤 구체적인 언급을 할 수 있을 것이다. 하지만 아무 말 없이 연결 요청만 하는 경우에는 당연히 내 입장에서는 그다지 도움이 되지 않을 것이라고 판단할 수밖에 없는 것이다.

조만간 학생 신분을 벗어나서 실제 업무를 시작하면, 아마 나중에 더 많은 사람들과 연결할 수 있고, 그 때가 되어야 헤드헌터들의 실제적인 도움도 받을 수 있으리라 기대한다. 그러므로 일단은 링크드인 네트워크는 지금 정도 수준에서 유지하고 연구실적을 키우는 데 더 노력해야겠다.

OS: Raspbian Jessie

TC는 리눅스에서 트래픽 컨트롤 기능을 제공하는 도구이고, shaping (응용 레벨에서의 data rate 설정), scheduling (패킷 전송 순서를 조절), policing (arriving traffic에 대한 제어인 듯? 자세히는 모르겠음), dropping (들어오고 나가는 패킷에 대한 drop)을 지원한다.

이렇게 여러가지 기능이 있고, traffic shaping만 해도 사용하는 queue의 종류와 옵션 설정에 따라 다양한 목적 달성이 가능한데, 일단 내 실험에서는 말그대로 "특정 어플리케이션에서 내보내는 트래픽(outgoing traffic)을 원하는 대역폭으로 제한"을 거는 것만 필요하기 때문에 이와 관련된 가장 간단한 설정 방법만 정리하게 되었다.

<조건 생성>

1. qdisc 생성하기

어떤 경우에는 qdisc를 나중에 생성하는 경우도 있던데 그냥 먼저 만들어도 상관이 없으므로 먼저 만들어 두기로 했다.

HTB (HIerarchical Token Bucket)이라는 큐를 쓸 경우의 명령어는 다음과 같다.

[IFNAME]은 네트워크 인터페이스 이름, 

[ROOT_HANDLE_NO]는 루트 qdisc에 대한 핸들 번호(아이디) 이다.

default 뒤에 붙는 숫자는 별 의미가 없다. 아무 조건으로도 분류되지 않는 모든 트래픽이 1:12라는 클래스에 할당된다는 의미이고, 아직 tc를 가지고 1:12라는 아이디를 갖는 class를 만들지 않았기 때문에 아무 조건 없이 보통의 트래픽처럼 처리된다.

(예)

무선랜 인터페이스(wlan0)에 대한 qdisc를 1번으로 생성:

2. Class 생성하기

생성된 qdisc를 거쳐 가는 모든 트래픽을 분류하기 위해서, 분류되는 각 클래스와 그 클래스에 대한 조건(이 글에서는 traffic shaping만 설정하므로 bandwidth 제한)을 설정한다.

[CLASS_NO]는 새로이 traffic shaping을 적용할 클래스에 붙이는 번호이고, 원하는 대로 아무 번호나 붙여도 된다. 1부터 시작해서 증가시키면 별 문제가 없을 것이다.

참고로 qdisc 생성할 때 지정한 default 번호를 염두에 두고 설정해야 한다. Default traffic에 제한을 걸고 싶지 않다면 앞서 설정한 default 클래스 번호는(qdisc 예시에서 1:12) 피해야 한다.

[DATA_RATE]는 제한을 걸 bandwidth 표현이다. 만약 100 KB/s (초당 100 킬로바이트)를 허용하는 최대치로 두고 싶다면 100kbps 라고 써야 한다. 보통 우리가 알기로 kbps는 Kilobits per second인데 여기서는 Kilobytes per seconds로 쓰이고 있으므로(왜 그렇게 했는지는 모르겠지만...) 혼동하지 말아야 한다.

(예)

무선랜 인터페이스로 나가는 트래픽 중에서 최대 대역폭 200KB/s의 제한을 갖는 클래스를 5번으로 정의하고 생성:

3. Filter 생성하기

클래스를 먼저 만들고, 그 뒤에 특정 클래스로 패킷을 분류시켜서 traffic shaping 효과를 내기 위한 필터를 만든다. 필터는 source IP, source port, destination IP, destination port, traffic type (TCP, UDP 등), network interface 등의 조건으로 패킷을 분류할 수 있다.

SRC_IP는 source IP주소,

SPORT는 source port number,

DST_IP는 destination IP주소,

DPORT는 destination port 이다.

조건은 모두 match로 시작하고, 조건을 걸고 싶은 경우에만 match를 명시하면 된다. 즉, source port number 조건을 걸 필요가 없으면 match ip sport [SPORT] 부분은 없어도 된다.

(예)

무선랜 인터페이스로 나가는 트래픽 중에서 도착지 IP주소 192.168.4.8, 포트번호 22에 대해서 클래스 1:5로 분류하기:

참고로 다른 조건의 트래픽을 같은 클래스에 추가로 분류시킬 수도 있다. 192.168.4.8에서 포트번호 5001도 추가로 1:5에 분류하고자 하면:

각 명령에 대해서 아무 메세지가 출력되지 않고 쉘이 나오면 성공적으로 적용된 것이다.

<생성된 조건 확인>

생성된 qdisc, class, filter 설정이 올바른지 확인하려면 아래와 같이 입력한다:

실제 생성된 설정 예시:

<조건 삭제>

보통은 filter와 class를 삭제하면 설정한 트래픽 제한이 사라진다. 삭제는 생성의 역순으로 해야 한다. qdisc는 굳이 삭제하지 않아도 트래픽에 대한 조건은 모두 사라지므로, 향후 다시 설정하고자 하는 경우 클래스까지만 삭제하면 된다.

[FILTER_HANDLE]은 위의 생성된 조건을 확인할 때 표시되는 필터 핸들 번호(filter handle)이고, 필자의 경우에는 거의 다 800::800 부터 시작하는 번호가 할당됐다. 필터 핸들을 쓰지 않고, filter를 생성할 때 입력했던 라인을 그대로 가져와서 add만 del로 바꾸게 되면, 놀랍게도 그 외에 설정했던 필터들이 모두 다 같이 삭제되는 현상을 볼 수 있다. 왜 그런지는 모르겠지만, 같은 문제를 호소하는 질문과 그 해결책으로 필터 핸들 번호를 이용한 삭제 방법이 StackOverflow 페이지에 제시되어 있다 [2].

<조건 변경>

add 대신 change를 쓰면 기존에 생성한 조건을 변경할 수 있다.

qdisc는 바꿀 일이 별로 없으므로 넘어가고, 클래스의 경우는 이미 할당된 번호와 parent를 변경할 수는 없고 rate 조정은 가능하다.

(예)

기존에 생성한 1:5 클래스의 bandwidth를 50KB/s로 변경할 경우:

TC가 잘 설정되었는지 확인하는 방법 중 하나로, iperf를 쓰는 방법이 있다. iperf는 받는 쪽에서 -s 옵션으로 받는 패킷에 대한 통계를 내고, 보내는 쪽에서 -c 옵션과 목적지 IP주소를 입력해서 최대 bandwidth를 측정할 수 있다.

iperf의 기본 포트인 5001에 대해서 필터를 걸었더니, 보내는 트래픽이 처음에는 약 1.6Mbps로 전송되다가, 클래스를 수정한 뒤에는 약 400Kbps의 대역폭을 가짐을 볼 수 있다.

받는 쪽 예시:

받는 쪽에서도 보내는 쪽의 tc 설정대로 처음에는 약 1.6Mbps 정도의 incoming traffic을 보이다가, tc 설정을 변경한 이후에는 약 400Kbps 정도의 낮은 속도로 패킷이 도착했음을 확인할 수 있다.

<참고자료>

[1] HTB Linux queuing discipline manual - user guide, http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

[2] TC hashing filters - single rule deletion, http://serverfault.com/questions/330581/tc-hashing-filters-single-rule-deletion

문제의 기사 #1: 

[피치원단독]기상청,550억원짜리 슈퍼컴 4호기,스위스는 20억원에 구입,혈세낭비 유착의혹

http://www.pitchone.co.kr/?p=5746

문제의 기사 #2: 

[피치원뷰]기상청,”스위스가 20억에 구입한 슈퍼컴 550억원 구매사실 철저히 은폐하라”거짓자료배포,충격

http://www.pitchone.co.kr/?p=5954

결론: 두 기사 모두 거짓된 정보를 사실인 양 배포하고 있다. 사실관계가 확인되지 않는 오보이자 왜곡 기사이다.

스위스는 단돈 20억원만으로 우리나라 기상청이 구입한 550억원짜리, 세계 36, 37위 성능의 슈퍼컴퓨터를 구입한 게 아니고, 원래 갖고 있던 구형 CPU 기반 슈퍼컴퓨터 시스템을 CPU와 GPU를 모두 연산에 활용하는 새로운 시스템으로 바꾸는 업그레이드에 3200만 달러(환율 다 무시하고 대충 1000원으로만 계산해도 320억원) 이상 썼다. [1]

그리고 2015년 9월에 스위스가 새로 도입한 슈퍼컴퓨터 캐비닛 2세트의 스펙과 비용을 대충 추측해서 비교하려고 한 것 같은데, 2015년 9월에 새로 도입한 그 시스템만 놓고 보면 전 세계 슈퍼컴퓨터 랭킹 504위 [2], 반면에 대한민국 기상청이 갖고 있는 슈퍼컴퓨터 2개는 각각 36위와 37위 [3]. 슈퍼컴퓨터의 연산 능력을 수치화하는 테라플롭스 기준으로도 거의 8배 차이가 난다.

그런데 어떻게 우리나라 기상청의 슈퍼컴퓨터와 2015년 9월에 도입해 온 조그마한 슈퍼컴퓨터 일부의 성능을 비슷하다고 표현할 수 있는가? 8배는 비슷한 것인가?

스위스의 슈퍼컴퓨터가 그전에 구형 슈퍼컴퓨터에 대대적으로 GPU를 추가하는 업그레이드 과정을 거친 시스템을 보면 세계 8위이다 [4]. 만약 이 세계 8위짜리 스위스의 슈퍼컴퓨터 시스템과 우리나라 기상청이 새로 도입한 4호기를 비교하려고 했다고 가정하면, 기자는 여전히 아주 불공정한 비교를 하고 있다.

비용을 따지려면 스위스가 맨 처음에 구형 CPU 기반 시스템을 구입한 비용 + 구형 시스템의 GPU 업그레이드 비용을 합쳐서 비교를 했어야 한다. 그러면 20억은커녕 GPU 모듈 추가를 통한 업그레이드 비용만 3200만 달러(현재 환율 기준으로 367억원)이 넘고, 초기 도입 비용 또한 백억원 단위는 충분히 찍을 것으로 짐작되는 바, 우리나라의 도입비용과 실제로는 큰 차이가 없게 된다.

참고로 우리나라 기상청의 슈퍼컴퓨터 구입비 550억원은 실제로 슈퍼컴퓨터 전체와 공간 등 부대시설을 통째로 도입하는 비용이다 [5]. 

구형 시스템의 GPU 업그레이드에만 벌써 3200만 달러가 들었고, 구형 시스템만 놓고 봐도 만만찮은 스케일인데 그 규모의 서버가 수백억원 단위로 잡히지 않는다면 그게 이상한 것이다. 그리고 2015년 9월의 신규 캐비닛 2개 도입 비용은 하드웨어 스펙을 대충 살펴봐도 192개의 GPU 가속기가 8억원 이상, 여전히 함께 들어 있는 CPU 총합이 약 13억원, 그외 메인보드, 메모리, 파워 서플라이, 하드디스크, 본체 등등 다 합치면 20억원은 충분히 넘고도 남을 것 같다.

이렇게 놓고 보면 우리나라 기상청의 슈퍼컴퓨터 4호기는 생각하는 것만큼 덤탱이를 쓰고 혈세를 낭비한 것이 아니다. 그런데 기자는 공정한 비교는커녕 27배 덤탱이 썼다는 자극적인 언론 플레이나 하고 있다.

게다가 기자가 "악성 재고"라고 지적하는 것과 같은 Intel Xeon E5-26XX 계열의 CPU가 스위스에서 2015년 9월에 추가 도입한 서버에만 5,568코어 (개수로 보면 12코어짜리니까 464개쯤?), 세계 8위를 찍는 전체 시스템 기준에서는 115,984코어나 된다 [4]. 이것은 세계 36위를 찍는 기상청 슈퍼컴퓨터 중 하나인 "미리"가 69,600코어를 가진 것과 비교하면 오히려 스위스의 슈퍼컴퓨터가 더 많은 CPU를 갖고 있다.

기사에서는 마치 우리나라는 순수 CPU만 쓰고 스위스는 GPU 위주로 쓰는 것처럼 언급했지만, 스위스 슈퍼컴퓨터 역시 세계 여타의 모든 슈퍼컴퓨터와 다를 바 없이 CPU를 많이 쓰면서 GPU도 같이 쓰는 개념으로 봐야 한다. 그리고 기자는 지금껏 CPU 기반으로 돌아가던 대규모 연산 소프트웨어가 GPU를 쓰도록 하기 위해서 하드웨어만 들여 오면 금새 되는 줄 착각하는 것 같다. 스위스도 슈퍼컴퓨터에 GPU 가속기를 업그레이드 하면서, 기존에 CPU 기반으로만 돌아가던 자기네 기상예보 소프트웨어 아키텍처를 전면적으로 뜯어고치는 대규모 재설계를 거쳤다. [6] 참고로 이렇게 소프트웨어를 전체적으로 재설계하는 것은 결코 쉬운 작업이 아니다. 게다가 그 대상이 국가에 지대한 영향을 끼치는 일기예보를 담당하는 한 치의 버그/오류도 허용할 수 없는 아주 중요한 시스템인데 그게 하드웨어 구입하듯이 단번에 될 일이 아니다. 스위스에서도 5년이 넘게 걸렸다.

그러니까 결론적으로, 우리나라 기상청은 기대하는 성능의 슈퍼컴퓨터를 제 값 주고 샀다고 보는 것이 더 타당하다. 슈퍼컴퓨터 구입하는 과정에서 27배 또는 530억원어치를 몽땅 비리로 해먹을 수가 없다는 말이다. 같은 논리로 보면 크레이 사가 우리나라에 판 것과 모델명이 같고 스펙이 조금 다른 제품을 영국 등 다른 여러 국가에도 팔았는데, 그 국가들이 모두 중간에서 수백억원씩 비리를 저질렀다고 봐야 한다.

그보다 기상청이 과연 정말로 550억원에 해당하는 하드웨어 성능을 필요로 하는지, 세계랭킹 36위 급의 성능이 필요한 이유에 대해서 진지하게 생각해 보는 것이 더 가치있을 것이다. 예를 들어, 향후 운용 기간과 현재의 자원 활용 수준, 앞으로 새로운 종류의 일기예보를 추가로 하려는 것인지, 기존의 일기예보 정확도를 개선하기 위해서 더 넓은 영역과 더 많은 데이터를 필요로 하는 것인지 등등을 생각해 보고 550억원 지출의 타당성을 나름대로 생각해 보는 것이 타당하다.

------------------------------

지적을 하고 싶으면 차라리 기상청이 세계 최초로 일기예보 연산 과정에 GPU 자원을 활용하는 새로운 소프트웨어 시스템을 개발하지 못하는 소프트웨어 기술력의 한계를 지적했어야 한다. 앞서 이미 언급했듯이, 이것은 그렇게 쉬운 작업이 아니다.

나는 근거도 없는 슈퍼컴퓨터 구입비용 절감이 부러운 것이 아니고, 스위스처럼 기존에 잘 돌아가고 있는 일기예보 소프트웨어 시스템 전체를 다 뜯어고치자는 제안이 수용되고, 그로 인해 자연스럽게 GPU 기반 연산이 가능해지면서 슈퍼컴퓨터를 추가로 업그레이드할 때 큰 효율을 거둘 수 있는 개방적이고 도전적인 분위기가 정말 부럽다.

우리나라 기상청이었다면 아마 전산실에서 기술 트렌드와 비슷한 필요를 느끼고서 "우리도 지도 위에서 기상 상태를 지금보다 더 상세하게 보여줄 수 있는 높은 해상도의 연산을 더 효율적으로 할 수 있도록 일기예보 연산에 GPU도 활용할 수 있게 소프트웨어를 업그레이드하자"는 제안 정도는 윗선에 할 수 있을 것이다. 다만 대한민국은 여전히 위험을 감수하고서 혁신을 이끌어 낼 만한 문화가 아니기 때문에 윗선에서 묵살될 가능성이 매우 클 것이다. 게다가 실제로 소프트웨어 업그레이드를 해서 돌렸다가 어딘가 문제가 생겨서 시스템이 다운이 되기라도 한다면 기상청, 아니 대한민국 전체가 난리가 날 것이고 일기예보 소프트웨어 시스템 담당 직원과 그 윗선 사람들이 줄줄이 잘려나갈 지도 모른다. 안타깝지만, 우리나라는 아직까지는 이렇게 뒷탈 없이 현상을 유지하고자 하는 문화가 만연해 있다.

기상청이 일기예보를 잘 못해서 미운 마음만큼은 이해를 하겠지만, 기상청이 싫다고 해서 사실관계에 대한 이해와 근거 없이 잘못된 정보를 가져와서 사실인 양 비난하고 선동하는 행태는 정말 화가 난다. 정부를 비난할 수만 있으면 잘못된 정보라도 상관이 없다는 논리인가? 

적당한 논리와 교묘한 왜곡에 자극적인 표현을 거침없이 쓰면서 여론을 몰려는 것이 주 목적인가 의심이 들 지경이다. 이렇게 잘못된 정보와 관련 분야에 대한 무지로부터 만들어진 선동으로 인해서 브렉시트 같은 일도 일어나고, 미국에서도 그러지 않기를 바라는 대선 후보가 득세를 하는 것 아닌가? 정말 어렵다. 몇달 전 알파고 때도 전문가도 아닌 사람들이 인공지능 전문가인 척 하면서 설익은 인터뷰를 하거나 글을 쓰면서 인공지능에 대한 이해 없이 온 국민을 호도하는 잘못된 정보가 확대재생산 되는 과정이 정말 답답했었다. 그런데 이번에도 비슷한 상황이 발생하니 통탄을 금할 수 없다.

해당 기사가 올라온 피X원이라는 미디어는 국민의 신뢰를 받고 싶다면 거짓 선동 기사를 검증 없이 마구잡이로 올리는 행태를 당장 그만두어야 할 것이다.

*덧:

피치원미디어 페이스북 페이지가 있고 해당 기사에 대한 공유 포스팅도 보이길래 이 글과 비슷한 맥락의 내용으로 댓글을 남겼더니 몇 분 후 지워졌다. 자극적으로 작성해서 페이지뷰 무지 올려주는 기사를 인터넷에서 내리기는 싫은데 댓글에 반박은 못하겠고, 그래서 고작 하는 행동이 댓글 삭제라니, 이것만 봐도 저질 언론(언론이라고 부르기에도 민망하다)의 면모가 보인다.

<참고자료>

[1] http://investors.cray.com/phoenix.zhtml?c=98390&p=irol-newsArticle&ID=1797953

[2] Piz Kesch - Cray CS-Storm, Xeon E5-2690v3 12C 2.6GHz, Infiniband FDR, NVIDIA Tesla K80, https://www.top500.org/system/178617

[3] Miri - Cray XC40, Xeon E5-2690v3 12C 2.6GHz, Aries interconnect, https://www.top500.org/system/178612

[4] Piz Daint - Cray XC30, Xeon E5-2670 8C 2.600GHz, Aries interconnect , NVIDIA K20x, https://www.top500.org/system/177824

[5] Hark의 이것저것, "기상청 슈퍼컴퓨터 550억 혈세 낭비? 유사언론의 보도행태에 치가 떨린다 ^^" http://everyhark.tistory.com/196

[6] http://www.meteoswiss.admin.ch/home/measurement-and-forecasting-systems/warning-and-forecasting-systems/cosmo-forecasting-system.html