단골 중식당에서 느낀 불쾌한 경험(주차 문제)

이걸 주차 문제라고 하는 것이 옳을까. 주차 관리의 문제라고 하는 것이 더욱 정확하겠다. 바로 어제(일요일) 점심의 일이다. 25년 정도 단골로 이용하는 중식당에 차를 세우고 식구들과 함께 맛있는 점심을 먹고 쇼핑을 하러 차를 몰고 이동 중이었다. 갑자기 모르는 번호로부터 전화가 왔다. 기억에 의존한 것이라 100% 정확하게 재구성한 것은 아니다.

(발신자) "여기 주차장인데요. 지금 어디계시죠?"
(나) "네? 주차장이요? 제가 뭘 건드리기라도 했나요?"
(발신자) "지금 어디시냐구요."
(나) "식사 마치고 다른데로 이동 중인데요. 다시 돌아가야 되나요? 무슨 일인데요?"
(발신자) "아, 나가셨어요? 그럼 됐어요. 주차장에 차를 세워놓고 다른 곳에 계신 분들이 많아서 확인하려고 전화드렸어요."

이게 도대체 무슨 일인가? 발신자의 마지막 설명이 있기 전까지 나는 이 상황을 도저히 이해할 수가 없었다. 나는 차를 몰고 이동 중에 있는데, 주차장이라고 하면서 전화가 오면 어떤 생각이 들겠는가? 나도 미처 모르는 사이에 차를 세우거나 빼면서 남의 차나 기물을 건드린 것을 누가 보고 전화를 한 것이 아닐까하는 걱정스런 생각이 드는 것이 당연한 것이다.

나에게 전화를 건 것은 아주 간단한 이유였다. 중식당 주차장이 결코 여유롭지 않은데 여기에 차를 대 놓고 얌체처럼 인근의 카페 등 다른 영업장을 이용하는 사람이 많아서 이를 확인하기 위함이었다. 하지만 나는 이미 주차장에서 차를 몰고 나간 뒤에 전화를 받았다. 즉, 관리자(아마도 중식당 사장님?)은 자기 영업장 주차장에 세워진 차들에 남겨진 전화번호를 죽 적어온 다음, 차들이 이미 나간 것을 확인하지 않은 상태에서 전화를 돌린 것이 자명하다.

그러면 아주 우스운 시나리오를 가정해 보자. 난 일행과 아직 그 식당에서 점심을 먹고 있는데 갑자기 전화가 온다.

(발신자) "여기 주차장인데요. 지금 어디계시죠?"
(나) "네? 지금 OOO에서 식사 중인데요."
(발신자) "정말요? 어느 테이블에 앉아계시죠? 손 한번 들어보세요."

처음 전화를 걸어왔을 때, OOO 주차장이라고 했으면 내 입장에서는 아마 상황 판단이 좀 더 빨랐을 것이다. 그러나 그곳에 차를 대고 다른 볼일을 보는 얌체 손님이라면 그곳에 있는 식당의 이름이 OOO라는 것도 모를 수 있다.  만약 처음에 전화를 걸면서 OOO 라는 영업장 명을 이야기했다면, 눈치빠른 손님은 'OOO에서 밥 먹고 있는데요'라고 둘러댈 수도 있고, 이를 착석한 손님으로부터 일일이 확인하기는 어려우니 그 순간을 슬쩍 넘어갈 수도 있을 것이다. 아마 전화를 건 사람은 이런 것을 제딴에는 다 생각해서 무조건 '주차장인데요'라고 말을 시작했는지도 모른다.

손님이 많이 오는 일요일 낮에 영업주로서 손님을 위한 주차장 확보를 해 주는 것이 옳은 배려라고는 하지만, 그러려면 최소한 현재 세워져 있는 차에 대해서나 확인을 해야 될 것 아닌가. 이미 식사를 마치고(따라서 정당하게 OOO의 주차장을 이용하고) 자리를 떠났는데 이를 확인도 안하고 따지듯 전화를 하다니.

갑자가 화가 치밀었다. 걸려온 전화번호를 이용하여 전화를 해서 따졌다. 최소한 차가 주차장에 세워져 있는 상태에서나 전화를 해야지, 어디라고 말도 안하고 무조건 주차장이라면서 어디 있느냐고 물으면 되겠냐고. 25년 가까이 이용해 온 단골집 목록에서 이제 빼야 되겠다고 쏘아붙이고 전화를 끊었다.

업주 나름대로 고충이 있겠으나 좀 더 합리적인 방법을 고안했어야만 했다.

요즘은 개인적으로 느끼는 불편 사항 - 예: 얌체 주차족 때문에 고생한 경험담 - 을 모두가 보는 게시판에 올려서 같이 분노하는 댓글을 보면서 카타르시스를 느끼는 사람이 많은 것 같다. 이러한 고발이 갖는 자정 효과는 분명히 존재한다. 그런데 때로 이러한 고발은 너무 피곤하다. 너무나 불편 불만이 가득한 사회처럼 보이기 때문이다. 자기 아파트 단지에서 벌어진 분란이라면 그 아파트 커뮤니티에 올려서 해결하면 될 일이지 왜 전혀 상관도 없는 사이트에 개인적인 경험을 끌고 오는가. 그래서 나는 내 블로그에만 글을 올리는 소심한 복수(?)를 하는 것이다.

살다보니 참으로 별 일을 다 겪는다.

성공적인 스피커 개조의 부작용

기존에 사용하던 2-way 스피커 시스템에서 우퍼 드라이버를 제거하고 풀레인지 드라이버를 장착함으로써 예상 외의 만족감을 누리고 있다. 표현력도 풍부해지고 능률이 높아서 소출력 진공관 앰프에도 잘어울린다. 다만 유닛을 매립하지 못했기 때문에 전면 그릴을 제대로 끼우지 못하는 단점은 있다.

예상하지 못한 만족감으로 인해 부작용이 발생하였다. 새로운 앰프와 스피커를 만들거나 장만하고 싶은 호기심이 사라지고 말았다. 어차피 나의 귀는 두 개에 불과하고 더 이상의 오디오 기기를 놓을 공간도 이제는 없다. 매우 바람직한 부작용이라 아니할 수 없다.

자작은 효율을 추구하는 것이 아니다. 가장 기본적인 원동력은 호기심 충족이다. 현재 느끼는 불편을 해소하는 것은 그 다음 문제이다. 내가 즐겨 발문하는 네이버의 어느 오디오 관련 카페는 능률적인 '그린 앰프'를 만들어 즐기는 것을 중요한 목표 중 하나로 삼고 있지만, 요즘은 때아닌 JLH class A amplifier(어느 블로그의 설명 자료) 열풍이 불고 있다. 음질은 최고일지 모르나 발열 문제는 정말 대책이 없다. A급 앰프가 그렇듯이, 소리가 나지 않을 때 가장 열이 많이 나게 되니 말이다. 왜냐하면 이 앰프는 언제나 일정한 전력을 소모하는데, 이는 바로 (발열) + (재생되는 소리 에너지)로 나뉘기 떄문이다. 그러니 소리가 안나면 발열은 최대이다.

에너지 효율 면에서 A급 앰프는 최선은 아니다. 저전력 앰프라면 class D를 따라올 것이 없다. 진공관 앰프 역시 전력 소모, 발열, 제작 비용, 크기와 무게 등의 측면에서는 낙제점이다. 그래도 왜 애호가들은 이러한 앰프에 꾸준히 열정을 쏟는가? Specification 수치만으로는 드러나지 않는 매력이 충분히 있기 떄문이다.

솔직하게 말하자면 요즘은 다음 그림과 같은 OCL amplifier에 약간의 관심을 갖고 있다. 진공관과 IC로 구동되는 앰프는 어느 정도 경험해 보았으니 이제는 고전적인 캔 타입 트랜지스터 앰프를... 키트 가격도 7-8달러 선으로 매우 저렴하다.

http://www.ebay.com/itm/High-Power-25W-2-OCL-Two-Channel-Amplifier-Board-Module-Electronic-DIY-Kits-/111852024830?hash=item1a0ae673fe:g:J7AAAOSwJ7RYTlqJ

스피커 통 개조하기 - 이번에는 성공?

12월에 계획한 오디오 DIY작업은 기존의 2-way 스피커통에서 4인치 우퍼를 들어내고 Toptone F120U73-3(4.5인치급 풀레인지)를 장착하는 것이었다. 기존의 우퍼에 비하여 풀레인지 유닛의 직경이 더 크기에 구멍을 넗히기 위하여 고통스런(!) 톱질이 필요하다. 아래의 사진은 기존의 우퍼를 제거한 모습이다. 희생양이 된 스피커통은 Vertrag라는 제품이다. 원래 액티브 스피커였었는데 앰프 모듈을 제거하여 패시브 스피커로 오랫동안 사용해 왔다.



언제나 그러하듯, 톱질은 정말 어렵다. 힘을 적게 들이면서 미리 그린 선을 따라서 똑바로(이번 경우에는 원의 지름을 따라서 곡선으로) 판재를 자른다는 것은 일 년에 두어번 톱을 잡는 나에게는 쉽지 않은 일이다.아래 사진은 유닛 교체 후 트위터를 연결하지 않은 상태로 시험 재생을 하는 모습이다.



채널 당 4와트 수준의 싱글 엔디드 진공관 앰프를 물렸음에도 불구하고 바로 곁의 플로어스탠딩 스피커(구형 홈 씨어터 시절의 유물인 인켈 SH-950 - 흔히 하는 말로 "톨보이" 스피커)에 못지않은 웅장한 소리가 난다. 정말로 놀라운 일이다. 300x200x200(mm)짜리 ported 인클로저에서는 그렇게 둔탁하고 풀어진 소리를 내던 유닛이 이렇게 바뀔 수가 있는가? 원래 책상 위에서나 들으라고 만들어진 스피커 시스템에서 유닛만을 바꾸었을 뿐인데 큰 방을 가득 채울만한 풍성한 소리가 난다.


나만의 스피커 시스템을 만들겠다고 마음을 먹게 된 계기는 갖고 있었던 스피커가 진공관 앰프의 낮은 출력에 잘 맞지 않았기 때문이었다. 효율이 좋은 풀레인지 스피커를 먼저 구하고, 당연히 인클로저를 따로 제작해야 한다고 믿었었다. 하지만 제대로 된 설계 없이 대충 만든 통과 유닛은 서로 잘 어울리지 못하였다. 내부 보강을 하고, 흡음재를 채우고, 부피를 줄이기 위하여 나무토막을 넣는 등 여러가지 시도를 하였으나 만족스런 소리를 내지 못하였다. 약 2년에 가까운 시도 끝에 통에 비해 유닛이 너무 작다는 결론을 내리고 유닛을 6.5인치 저가형(삼미 HA-165B60)으로 바꾸는 대대적인 개조에 돌입하였다(개조 당시 포스팅). 그 결과는? 개조한 스피커는 사무실로 자리를 옮겨서 아직도 평가를 하는 중이다. 어쩌면 몇 달이 지나도 이 개조 작업에 대한 평가를 내리지 못하게 될지도 모른다. 현재 사무실 책상 앞의 상황은 다음 사진과 같다.

삼미 HA-165B60를 사용한 스피커 시스템, 마음에 드는 소리는 나지 않는다.

테스트를 마친 뒤 새 스피커선을 준비하여 내부 배선을 마치고 기존의 트위터와 필터용 2.2 uF 캐패시터를 병렬로 연결하였다. 유닛을 완전히 고정한 다음 그릴을 씌우기 전의 모습을 아래에 보였다. 기존의 스피커 고정용 볼트가 약간 작아서 와셔를 삽입하였다.

오늘 이러한 시도를 해 보지 않더라면 나는 스피커 자작은 넘기 어려운 산이라 생각하고 더 이상의 경험을 하지 않겠노라고 섣불리 포기를 선언했을지도 모른다. 납땜질 연기를 풀풀 풍기며 주말 아침 방구석에서 개조에 열을 올리고 있는 남편을 보고 묵묵히 인내해 준 아내에게 감사를...





12월을 위한 스피커 개조 작업

간혹 인터넷에서 오디오 취미를 가진 사람이 각종 기기로 탑을 쌓은 사진을 찍어 올린 것을 접하게 된다. 상대적으로 다른 기기에 비해서 좁고 높은 스피커가 탑쌓기에는 더욱 잘 어울린다. 나는 아직 그러한 수준에 이르지 못하였고, 또 그렇게 될 엄두도 나지 않는다.

삼미의 PA 유닛(HA-165B60, 6.5 인치)에게 자리를 빼앗긴 4.5인치급 풀레인지 유닛인 Toptone F120U73-3을 물끄러미 바라보다가 12월을 위한 일거리를 하나 고안하게 되었다. 바로 "passive" Vertrag 스피커의 우퍼와 바꿔치기를 하는 것이다. 이것보다는 당연히 나은 소리를 내지 않겠는가? 비록 내가 처음으로 주문제작한 인클로저와는 잘 어울리지 못했지만 말이다.

나사를 풀고 Vertrag의 4인치급 우퍼 유닛(4 Ohm, Vigoole이라는 상표가 보임)을 처음으로 꺼내보았다. 구멍의 내부 직경은 96 mm, 매립을 위한 외부 직경은 116 mm로 뚫린 상태이다. Toptone 유닛을 넣으려면 내부 직경은 108 mm로 맞추어 넓혀야 한다. 매립을 원하면 바깥쪽 구멍을 직경 119 mm로 파내고 볼트 트 고정을 위해 네 곳을 더 파내면 된다. 트위터쪽에는 2.2 uF 50V 무극성 전해 캐패시터가 직렬로 연결되어 간이 크로스오버 네트워크 역할을 한다.

왜 바꾸려고 하느냐고? 나의 신념은 확실하고도 단순하다. 모델명이 찍혀서 단품으로 팔리는 스피커 유닛은 싸구려 스피커 시스템에 들어있는 그 어떤 '묻지마' 유닛보다는 나을 것이라는...

목공용 둥근줄이 없다는 것이 아쉽다. MDF 재질이 틀림없으니 조각도, 쥐꼬리톱, 칼 등 있는 공구를 가지고 최선을 다 해보자. 여기에서 단 한 번이라도 성공을 해 봐야 나중에 포스텍스든 탕밴드든 욕심을 낼 것이 아니겠는가.

최근 삼미전자에서 고급형 풀레인지 유닛이라 할 수 있는 FS-06A40(6.5 인치)와 FS-08A60(8인치)을 출시한 것은 매우 고무적인 일이라 생각한다. 자작용으로 널리 쓰이던 염가 모델 ME-08B40(8인치)의 아쉬운 점을 달랠 수 있게 되었으니 말이다. 예전에 삼미전자와 오디오 동호회의 합작으로 선보인 "하늘과 바다(8 인치)"에 관한 이야기는 여기에 있다.

Naxos Music Group에서 온 선물

한때 Naxos 웹 라디오 서비스를 일 년 동안 이용한 적이 있다. 서비스를 연장하지는 않았지만 그 이후로 gmail 계정으로 뉴스레터가 오는 것에 대하여 전혀 신경을 쓰지 않고 있다가 엊그제 한번 11월호 내용을 읽어보았다.

공짜 앨범을 다운로드하라고? 클릭을 하여 들어가니 다음의 음반에 대한 FLAC 파일, 즉 무손실 음원이 제공되는 것이었다. 윈도 미디어 플레이어로는 재생이 되지 않아서 Foobar 2000으로 음악을 들어 보았다. 오오.. 이것이 처음 접하는 FLAC 음원이로구나.

낙소스라고 하면 비교적 저렴하게 음반을 판매하는 회사 정도로 알고 있었는데, 이런 예기치 못한 즐거움을 주리라고는 상상하지 못했다. 세상은 넓고 이상한 사람도 많지만... 들을 음악은 더욱 많다! 지금은 집에서 가지고 나온 몇 장의 CD 중에서 기타리스트 박규희의 2012년도 음반(낙소스 발매)을 듣는 중이다. 

COG(clusters of orthologous groups) 2014년 개정판 음미하기

COG란 미국 NCBI의 Eugine V. Koonin 그룹에서 개발한 일종의 단백질 서열 데이터베이스이다. 1997년 Science 논문으로 첫선을 보였을 때에는 시퀀싱이 완료된 유전체의 수준에서 집계한 최초의 근대적(?)인 단백질 서열 데이터베이스였다. 어떤 규칙에 의거하여 단백질 패밀리 혹은 클러스터를 구성한 뒤, 각 클러스터에 대해서 COG 번호와 functional class(알파벳 문자 하나), 그리고 단백질 명칭을 부여해 놓은 것이다.

COG의 핵심은 1) 클러스터를 만드는 방법과 2) 이렇게 만들어진 COG data, 그리고 3) query protein이 주어졌을 때 어느 COG에 들어가는지를 선택하는 방법의 3가지라고 보면 된다. 3)을 통해서 당시 붐을 이루던 미생물 유전체 프로젝트의 중간 결과물(유전자 서열 - 단백질로 번역된)에 대하여 꽤 높은 coverage로 functional annotation을 할 수가 있었으므로 한동안 널리 활용되었다. 지금까지 가장 오랫동은 활용된 것은 2003년에 공개된 개정판으로 66개의 genome에서 산출된 4873개의 클러스터로 이루어졌다. 2014년 버전(Nucl Acids Res 2015 1월에 게재)은 엄밀히 말하면 2003년 개정판을 확장한 것이다. 그래서 COG2003-2014 update라고도 불리는 것이다. 새로 등장한 클러스터는 없고 오히려 242개의 COG가 줄어들어서 전체 클러스터는 4631개가 되었다. 사라진 클러스터는 대부분 효모의 것이다. 큰 차이점은 클러스터를 집계한 유전체의 수가 그동안 축적된 서열데이터를 반영하여 711개로 늘어났고, functional class가 정비되었으며, functional annotation이 새롭게 부여된 COG가 생겼다는 것이다.

공교롭게도 3)번을 위한 프로그램은 마땅한 것이 없었다. COG software가 공개된 것은 꽤 시간이 흐른 뒤였고, 그나마 지금 문서 파일을 읽어봐도 도대체 어떻게 쓰라는 것인지 이해하기가 상당히 어렵다. 당시에는 COGnitor라는 웹 서비스가 있어서 query protein sequence를 넣으면 blast 검색을 거쳐서 COG 번호를 할당해 주었으나 지금은 사라진지 오래이다. 그래서 이런 편법을 쓰기도 하였다. COG protein set에 대해서 blast를 한 뒤, best hit에 해당하는 COG 정보를 단순히 가져오는 것이다. 하지만 1) COG를 생성하는 방법, 즉 genome-specific best hits(BeTs)이 삼각형을 이룰 때 이것을 최초의 클러스터로 간주한다는 원칙이 지켜진 방법이 아니므로 정확성에 약간의 의문을 제기할 수 있다.

따라서 내가 갖고 있는 query protein에 COG number를 할당하는 가장 정통적인 방법은 어떻게 해서든 공개된 COG software를 활용하는 것이다. 이것은 sourceforge("COGsoft")나 NCBI에서 입수할 수 있다. 실은 어제 COG software를 내려받아서 Readme 파일을 막 읽기 시작하였다. 수년 전에는 이해하기가 참 힘들었는데 이제는 조금만 궁리하면 나만의 COG를 만들거나 query protein을 기존의 COG에 할당하는 제대로된 방법을 셋업할 수 있을 것이라는 희망을 갖고 있다. 물론 만들어진 cluster에 annotation을 부여하는 것은 전적으로 사용자의 몫이다. 2015년 논문을 보면 외부에서 만들어진 몇 가지 COG의 확장판에 대해 언급을 하고 있다(예: EggNOG - 완전 자동 프로세스로 만들어짐). 하지만 오리지널 COG가 자랑스럽게 차별화하는 포인트는 cluster membership과 annotation을 일일이 전문가가 점검한다는 것이다. 아마도 cluster membership을 점검한다는 것은 tree 구조나 alignment 현황을 들여다본다는 뜻일게다.

Query protein에 COG를 할당하는 차선책은 CDD database를 구성하는 COG subset을 이용하는 것이다. ftp://ftp.ncbi.nih.gov/pub/mmdb/cdd/cdd.tar.gz 파일을 내려받아 압축을 풀면 총 53841개의 PSSM 데이터(.smp 파일)가 나오는데, 이중에서 4873개는 COG 2003 버전에 해당하는 것이다. 서브셋을 일부러 만들 필요는 없고, rpsblast를 실행하되 "Cog"를 데이터베이스로 택하면 된다. 물론 더욱 간단하게는 NCBI CDD batch search 사이트에서 최대 4천개까지의 query를 제출하면 된다. 결과는 이메일로 제공된다. 그 다음 찾아진 COG 번호에 해당하는 annotation 정보는 cognames2003-2014.tab 파일을 참조하여 연결하면 된다. 다음 그림은 batch CD-search가 끝난 이메일로 제공된 링크를 방문한 모습이다.

좀 더 개방적인 태도를 취하고 싶다면 EMBL의 EggNOG를 활용해 보는 것도 좋다. 웹사이트에서는 한번에 하나의 서열만을 넣어서 검색할 수 있지만, 전체 데이터를 내려받아서 hmmer 프로그램으로 복수의 query에 대한 검색을 하는 방법이 설명되어 있다.

COG가 결코 만능은 아니다. COG 데이터에는 gene symbol이나 EC 번호와 같은 정보를 제공하지는 않으니까 말이다. 하나의 데이터베이스/서비스가 사용자의 모든 욕구를 다 충족시키지는 못할 것이니.

NCBI의 COG software를 활용하는 방법은 여기에 소개해 두었다.

GNU Parallel

대량의 파일에 대한 반복 작업을 어떻게 하여 효율적으로 진행할 수 있을까? HPC cluster니 하둡이니 클라우드 컴퓨팅이니 하는 기술적으로 다소 까다로운 방법 말고 좀 더 간단한 방법은 없을까? 이러한 고민 끝에 발견한 것이 바로 GNU Parallel이다(공식 웹사이트). 이것은 간단히 말하자면 입력을 쪼개서 병렬 실행을 해 주는 shell 수준의 도구이다. 다중 코어를 지닌 한 대의 컴퓨터는 물론, ssh로 접속 가능한 여러 컴퓨터에 작업을 보내는 것도 가능하다. 반복 작업을 위한 기존의 유틸리티인 xargs 또는 cat | bash를 대체할 수 있다는 뜻이다.

만약 현 디렉토리에 있는 수천개 이상의 파일을 전부 압축해야 한다고 가정하자. gzip *이라고 타이프하면 십중팔구는 인수가 너무 많아서 실행을 하지 못한다는 에러 메시지가 나올 것이다. 그러나 Parallel이 설치되었다면 다음과 같이 하면 된다.

$ parallel gzip ::: *

Shell은 *를 확장하여 파일로 만들고, 이를 gzip 명령어에 공급하되 여러 core에서 병렬 작업이 일어나게 한다. 물론 이는 대단히 간단한 사례이다. 입력 파일을 분할하여(기본 가정은 ㄱ각각의 라인이 별도의 레코드라는 것이나, separator를 지정할 수 있다) 각각에 대한 동시 작업을 수행하고, 이를 합치는 것이 가장 전형적인 사례이다. 분할된 입력 파일은 명령어에게 표준 입력으로 전송되게 함으로써 매우 단순한 작업 지시를 할 수 있다. Biostars에 매우 훌륭한 설명 자료가 있다(Parallelize serial command line programs without changing them). 이 자료에서 설명한 사례를 하나 인용해 보겠다. 1GB나 되는 대용량의 fasta file에 대한 blast 검색을 하고 싶다면?

$ cat 1gb.fasta | parallel --block 100k --recstart '>' --pipe blastp -evalue 0.01 -outfmt 6 -db db.fa -query - > results

입력 파일을 100 KB 단위로 자르되 각 레코드는 '>'로 시작하니 미련하게 query sequence 중간을 자르지 못하게 하고, 이를 blastp에 넘겨서 서열 검색을 한 뒤 최종적으로는 results 파일로 합친다. 잘려진 각 데이터에 대한 검색 결과까지 순서대로 저장되는 것은 아니니, 입력물의 순서를 그대로 유지해야 한다면 약간의 변형된 방법이 필요하다.

다음으로는 FASTX toolkit에 들어있는 fastq_to_fastq(-Q33)을 그냥 실행한 것과 GNU parallel을 거쳐서 실행한 것의 소요시간 차이를 비교해 보았다. 중간에 top을 쳐 보면 12개의 job이 동시에 돌아간 것으로 나온다. 블록 사이즈나 jop 수는 따로 지정하지 않았다. 먼저 그냥 실행한 것. 입력한 fastq 파일의 크기는 5.3 GB였다.

real 3m19.405s
user 3m14.986s
sys 0m8.562s

다음은 GNU paralleld을 사용한 것. 상당한 속도 개선이 있다.

real 1m6.266s
user 5m40.297s
sys 1m22.576s

예전에는 fastq 파일을 처리하는 유틸리티를 실행하면서 종료되기는 그저 기다리고만 있었는데, 이제는 그럴 필요가 없겠다. 추가적으로 GNU Parallel을 remote host에 적용하는 방법을 익힌다면 최근에 확보한 중간급의 서버 10대 정도를 묶어서 활용하는데 매우 큰 도움이 될 것이다.

유용한 자료 링크를 몇가지 더 소개한다.

• GNU Parallel tutorial (from official website)
• 짤막한 소개 자료
• [PDF] GNU Parallel: The Command-Line Power Tool
• Parallelising jobs with GNU Parallel(2022년 6월 30일 추가)