genoglobe.kr 도메인 만료 기한이 다가오다

오늘은 한글날이다. 요즘 망가지는 국어의 실태를 보고 있노라면 정말 가슴이 아프다.

점심시간이 되어 자주 찾아가던 식당을 일부로 찾아갔는데 낯선 이름의 가게로 업종이 바껴 있었다. 이젠 밥 먹으로 어딜 가지?

요즘 매우 흔히 보이는 잘못된 맞춤법이다. 심지어 뉴스 기사에서도 이렇게 잘못된 맞춤법을 종종 보게된다. 글씨를 틀리게 쓰는 것 말고도 표현법 자체도 번역투를 따라서 많이 변질되었다. 생각해보니 나도 문장 자체를 블로그의 제목으로 쓰는 경우가 제법 많다. 이는 영어 문화권의 논문 제목에서 대단히 흔하게 나타나고, 또 그렇게 쓰기를 권장한다. 인터넷 매체에서는 허핑턴포스트코리아가 대표적이다. 이것을 번역투 문체의 침투로 보아야 하는지는 좀 더 고민해 보아야 되겠지만, 전통적인 우리말의 표현법과는 거리가 있다. 그래서 오늘의 제목도 평소의 버릇대로 문장체인 "genoglobe.kr 도메인 만료 기한이 다가오다"로 정하였다.

'~로부터 자유롭지 못하다'는 표현도 왠지 보기 좋지 않다. 마치 영어의 be free from(of)를 그대로 번역한듯한 어투이다. '~가 전혀 없다' 또는 '~로부터 벗어날 수 없다' 정도가 더욱 자연스럽지 않을까?

나는 개인적인 용도로 사용하기 위해서 genoglobe.com과 genoglobe.kr의 두 개 도메인을 운용하고 있다. 무료 웹사이트 호스팅을 표방하는 외국의 서비스 업체를 통해서 DokuWiki를 설치한 메인 페이지를 돌리는데, 사이트 남용을 이유로 종종 차단되는 일이 생긴다. 많은 트래픽을 유발하지도 않고 정보 업데이트를 위해서 하루에 몇차례 접속을 할뿐인데 어째서 이것이 사이트 남용이라는 것인지... 궁극적인 해결 방법은 유료 서비스로 전환하는 것이었다.

도메인 유지 비용도 부담이 되어서 좀 더 싼 기관으로 옮겨보려고 알아보는 중이다. 어쩌면 일년쯤 후에는 두 개 도메인 중 하나는 해지할지도 모른다. .kr을 살릴 것인가, .com을 살릴 것인가? 만약 genoglobe.kr만을 살리게 되면 이 블로그의 주소도 blog.genoglobe.com에서 blog.genoglobe.kr로 바뀔 것이다.

인터넷 기술 덕분에 개인 저작물을 세상에 널리 알리는 것은 정말 쉬워졌다. 하지만 나는 정말 쓸모가 있는 저작물을 체계적으로 만들고 있는가? 두 개의 도메인으로 나뉘어진 몇 개의 사이트가 정말 잘 돌아가고 있는가? 일부 사이트는 이미 부실해지고 있지 않은가? 2015년이 끝나기 전에 좀더 체계적인 운용 계획을 세운 뒤 필요하다면 정비를 해야 되겠다.

2년째로 접어드는 자작 스피커의 튜닝 - 내부 흡음재 바꾸기

나무로 적당히 상자를 짜서 스피커 유닛을 고정하고 단자를 연결했다고해서 스피커의 제작이 다 끝나는 것이 아니다. 풀레인지 성향의 단일 유닛을 사용했기에 네트워크 튜닝이라는 대단히 어려운 과정을 생략할 수 있었지만 이제는 흡음재 튜닝이라는 고비가 남아 있다.

중음이 다소 과장되고, 마치 동굴 속에서 울려나오는듯한 소리를 흡음재로 잡을 수 있다고 생각해왔다. 설계 자체가 잘못되었는지도 모르지만 말이다. 그동안 다양한 재료를 흡음재로 사용해 보았다. 합성 솜, 헌 옷, 낡은 라텍스 베겟속... 심지어는 인클로저의 내부 용적이 너무 큰 것일지도 모른다는 생각에 부피를 줄여보고자 나무토막을 넣기도 했다.

이론에 바탕한 체계적인 접근은 하나도 없었다. 흡음재를 넣는다는 것은 스피커 인클로저의 실효 용적을 키우는 효과가 있다고 한다. 그런데 용적을 줄이자고 나무토막을 넣고 흡음재를 같이 넣는 것은 말이 되지 않는다.

인터넷으로 자료를 찾아보니 인클로저 내벽에 붙이는 흡음재와 내부에 뭉텅이 솜을 넣는 방식의 흡음재로 나누어서 생각해야 한다는 정보가 있었다. 용적이 작은 인클로저는 내벽에 붙이는 흡음재를 생략하기도 한다는 것이다. 과연 나의 어설픈 풀레인지 스피커통에 어울리는 흡음재 재료와 설치 방식은 무엇일까?

일단은 인클로저 내벽에 일정한 두께의 흡음재를 붙여보기로 하였다. 선택한 재료는 두께 10 mm의 마블 스폰지이다. 이름이 좋아서 마블 스폰지이지 자투리 스폰지를 잘라서 압축하여 붙인 것이다. 가격이 저렴하고 강도가 좋아서 주로 업소 등에 들어가는 소파의 쿠션으로 쓰인다. 아마도 이것을 가지고 스피커 인클로저의 흡음재로 쓰는 사람은 별로 없을 것이다. 단일 재료로 마들어진 판재 모양의 스폰지와 계란판 형태의 스폰지 등 여러가지 형태를 놓고 고민하다가 이것을 택한 것이다.

가위로 재단하여 인클로저 내벽에 고루 붙였다. 접착제로는 목공용 본드에 약간 물을 타서 묽게 만든 것을 사용하였다. 배플면 쪽에는 붙이지 않았다. 

하룻밤 동안 두어서 본드를 말린 뒤 단자를 연결하였다. 사진에는 보이지 않았지만 뒷뚜껑을 닫기 전에 마블 스폰지를 70~80 cm 정도 잘라서 스피커 주변을 감싸듯이 큰 원형으로 둘둘 말아서 넣었다.

자, 그럼 소리는? 약간 좋아진 느낌이 들지만 이것이 흡음재 튜닝 때문인지 혹은 플라시보 효과 때문인지는 모르겠다. 이제 이 자작 스피커 시스템에 대해서 더 이상 정성을 들일 필요가 없다고 생각한다. 만약 귀가 약간 더 고급이 되어 이 스피커가 불만스럽다면, 이제는 기성 제품을 구입하는 것이 나으리라고 본다.

CD 플레이어의 반복 재생 기능을 활용해 보기

베토벤 피아노 협주곡 5번 "황제"의 3악장 중 악 1분 정도의 특정 구간이 반복적으로 재생되는 모습이다. 약 20분 넘게 이 짓을 하고 있었다.

픽업을 직접 교체한지 얼마 되지 않은 CD 플레이어가 CD의 특정 부분(65분쯤)에서만 높은 빈도로 튀는 현상 때문에 늘 고민을 하고 있었다. 이제는 정녕 CD 플레이어를 새로 장만해야 할 것인가? 그런데 이 현상을 반복적으로 관찰해보니 튀는 위치가 1초의 오차도 없이 똑같다. CD 자체는 아무리 눈으로 들여다 보아도 긁히거나 오물이 묻은 흔적이 없다.

그래서 내가 내린 가정은 이러하다. CD의 픽업이 레일을 따라 이동하면서 평소에는 잘 가지 않는 부분, 즉 재생시간이 긴 CD의 끝부분에 이르렀을때 뭔가 움직임이 원활하지 않게 된 이유가 있을 것이다. 만약 기기의 노후로 인하여 픽업의 이동을 제어하는 회로나 메카니즘 자체에 문제가 생겼다면 CD에 상처가 생기지 않고서는 매번 정확히 동일한 위치에서 1초도 틀리지 않고 튄다는 것은 상상하기 어렵다. 어쩌면 픽업이 왕복하는 레일에 미세하게 무엇인가가 들러붙어서 운동을 방해하는 것은 아닐까? 그렇다면 그 부분에서 반복 재생을 하면 들러붙은 그 무엇인가를 제거할 수 있지 않을까?

그래서 반복 재생을 실시하게 된 것이다. 처음 한 두번은 튀더니 그 이후로는 매끄럽게 재생이 되었다. 아침에 출근을 준비하면서 문제의 부분을 다시 들어보았다. 전혀 튐이 없다. 아직은 섣부른 결론일지도 모르나 이렇게 하여 문제를 해결했다고 자화자찬하는 중이다.

나의 낡은 CD 플레이어는 롯데 LCD-7500이다. 아마 1990년대 초반에 제조되었을 것이다.

Roary와 더불어 배운 것

새로운 프로그램의 이름에는 대개 그런 이름을 붙인 이유가 있다. 가장 흔한 것은 acronym이다. 예를 들어 BLAST는 Basic Local Alignment Search Tool에서 각 단어의 앞글자를 딴 것이다. 요즘 내가 감염균의 pan genome 분석을 하면서 아주 많이 빚을 지고 있는 Roary: rapid large-scale prokaryote pan genome analysis(웹사이트)는 어떻게 해서 이런 이름을 갖게 되었을까? 논문이나 웹사이트에는 별다른 설명이 없다. 구글에서 Roary를 치면 가장 위에 나오는 것은 Roary The Racing Car라는 영국에서 제작된 어린이용 애니메이션이 나온다. 실행 속도가 빠르다는 의미에서 재미로 이런 이름을 프로그램에 붙인 것이 아닐까 추축해 본다. 등장 차량(등장 인물?) 중에서 Roary는 영국을 대표한다. Roary 프로그램은 Sanger Institute에서 개발한 것이니 더욱 그럴만도 하겠다.

위키피디아에서 가져온 그림.

올해 중반까지 내가 몰두하고 있었던 것은 (meta)genome 분석용 소프트웨어인 MetAMOS였다. 가장 핵심적인 개발 환경(GCC)와 파이썬 버전이 모두 낮은 CentOS 6.7에서 설치를 하려니 보통 고역이 아니었다. 그러다가 Roary를 알게 되면서 필연적으로 거쳐가야하는 Linuxbrew가 내 리눅스 활용 역사를 발칵 뒤집어 놓았다 해도 과언이 아니다.

만약 내가 CentOS 7.x이나 우분투 16.04를 선택했다면 이 모든 수고가 필요없는 일이 되었을까? 그건 잘 모르겠지만, 아직은 사용자 지원이 이루어지고 있는 리눅스 배포판에 집착하는 것이 더 많은 도전과 공부 기회를 제공하는 것이 분명한 사실이다. 사실 어제 아침(개천절 아침; 출근하여 일을 했다는 이야기)까지는 사용 중인 20 core짜리 리눅스 머신을 우분투로 바꾸는 것을 심각하게 고민하고 있었다. 그러나 한번만 더 삽질을 하자는 신념으로 Roary 재설치 및 실행에 성공하였다. Linuxbrew가 매력적인 이유는 사용자 계정을 하나 더 만들면 아예 처음부터 새로운 환경에서 테스트를 할 수 있다는 것이다. 다만 한가지 주의할 것은 시스템 환경이 복잡해진다는 것. 펄 모듈만 하더라도 시스템 라이브러리 공간에 설치한 것과 사용자 공간에 설치한 것이 뒤죽박죽이 된 상태에서 Linuxbrew까지 한 식구로 들어오게 되어 기억과 기록을 잘 더듬어야 한다는 것이다. R 패키지를 하나 내려받아서 설치하는 일만 예를 들어도 선택 가능한 GCC가 이제는 세 가지나 된다. CentOS 6.x에 원래 있는 것(4.4.7), devtoolset으로 설치한 것, 그리고 linuxbrew가 제공하는 5.3.0까지 있으니 말이다.

Perl의 환경은 어떻게 되는 것일까

brew install perl로 5.10 버전이던 Perl을 업그레이드하면, 설치 맨 마지막 단계에 다음과 같은 메시지가 나온다.

By default non-brewed cpan modules are installed to the Cellar. If you wishfor your modules to persist across updates we recommend using `local::lib`.
You can set that up like this:PERL_MM_OPT="INSTALL_BASE=$HOME/perl5" cpan local::libecho 'eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)"' >> ~/.bash_profile

local::lib은 사용자 홈 디렉토리 하의 공간에 펄 모듈을 설치하고 쓰게 해 주는 것으로 알고있다. 그러면 예전에 관리자 권한으로 설치한 모듈들은 계속해서 사용할 수 있는 것인지? 이제는 펄 인터프리터 바이너리가 ~/.linuxbrew/bin/perl라는 이름으로 존재하는데, 앞으로 만들어질 펄 스크립트 첫줄에는 뭐라고 써야 되는지? 아마도 #!/usr/bin/env perl라고 적는 것이 맞을 것이다. 그러나 여전히 궁금한 것 투성이이다. bp_genbank2gff3.pl를 실행하면 펄 모듈들을 전혀 찾지 못하는 것으로 보아서 Linuxbrew에서 펄을 설치하면 일단은 새로 시작하는 것으로 생각해야 될 것 같다. 펄 자체의 버전이 달라진 상태이니 모듈도 새로 설치하는 것이 맞겠다. 어쩌면 linuxbrew를 이용한 펄 업그레이드는 매우 신중하게 해야 될지도 모르겠다.

소니 헤드폰 MDR-ZX11-AP의 음질을 다시 생각해 본다

국외 출장길에 충동 구매한 소니 헤드폰 MDR-ZX11-AP. 저가형임에도 불구하고 제값을 다 주고도 모자라 비싸게 구입하였다. 비행기와 버스 안에서 대충 들을 때에는 잘 몰랐는데, 사무실로 돌아와서 원래 쓰던 오디오테크니카 TH-380AV 헤드폰(이것도 좋은 것은 아님)과 비교해 보니 한숨만 나온다. 소리도 훨씬 작고, 답답하고, 선명하지 못하고...

내가 도대체 이것을 왜 샀을까. 더군다나 이것은 통화용 마이크로폰이 달려있어서 4극 단자가 달려있다. 이것을 사무실의 헤드폰 앰프에 꽂으면 접촉이 약간 이상하여 더더욱 듣기에 거북한 소리가 난다. 

이제 이 헤드폰의 용도는 확실히 정해졌다. 오직 바깥에서 휴대폰에 연결하여 음악감상과 통화를 겸하는 것. 차라리 와싸다 닷컴에서 5만원 내외의 적당한 제품을 살 것을...

요즘은 더 이상 싸구려 앰프 만들기에 관심을 쏟지는 않는다. 마지막 트랙 가까이 가면 튀는 CD 플레이어가 고민스러울 뿐이다.

연구개발관리사 자격검정 시험평가가 처음으로 실시된다

연구를 잘 한다는 것은 무엇일까? 창의적이고도 인류가 직면한 여러 문제를 해결할 실마리를 제공할 수 있는 성과를 잘 내는 것이라고 정의할 수 있겠다. 여기에는 사람들을 설득하고, 어느 정도 규모의 연구집단을 이끌고, 연구비 관리를 잘 하는 능력까지도 포함되어 있다. 어떤 사람이 연구를 잘 하는가를 가장 쉽게 평가하려면, 즉 우리 사회에 만연하고 있는 줄세우기를 해 본다면 그 사람의 논문과 특허 등 3P 실적을 보면 된다.

연구 자체와 연구개발 관리는 약간 다르다. 연예인과 매니저가 다른 점을 생각하면 쉽게 이해가 될 것이다. 소속사 없이 혼자서 스케쥴을 챙기고 모든 대외 업무까지 도맡는 1인 연예인도 있기는 하다. 그러나 쉬운 노릇이 아니다.

국가과학기술인력개발원(KIRD)에서 오는 11월 19일 제1회 연구개발관리사 자격검정 시험평가를 실시한다고 한다(대덕넷의 관련기사 링크). 연구개발 기획과 수행·관리, 성과확산 등 전주기 분야와 연구실 안전, 윤리, 보안 등 필수 분야에 대해서 일정 수준 이상의 능력을 인정받으면 자격증을 발급하게 된다.

아직은 이 자격증 취득 여부를 가지고 취업이나 각종 평가에 가산점을 준다는 소식은 들리지 않는다. 앞으로 그렇게 하겠다는 것이 KIRD나 미래부의 의지인 것으로 보이기는 하지만 말이다. 2016년 6월 날짜가 찍힌 국가과학기술심의회 "연구개발서비스 활성화 방안(안)" 공개자료에 따르면 다음과 같은 내용이 있다.

연구개발관리사, 연구장비전문가 등 민간자격제도를 활용하여 실무형 전문인력 양성 연계 및 공인자격으로 확대·발전...'16년 자격시험 시범실시 -> '18년 이후 공인인증자격으로 내실화.

그렇다면 이 자격증이 있는 사람은 연구를 잘 하는 사람인가, 연구개발관리를 잘 하는 사람인가? 머니투데이에 실린 다음의 기사 제목은 오해를 불러일으키기 딱 좋다. 

R&D 역량 검증하는 전문 자격증 나온다.

Science와 Nature에 논문을 자주 싣는 사람과 이 자격증 사이에는 무슨 관계가 있을까? 이건 분명히 잘못된 기사 제목이다. 이 자격증이 분명히 내실이 있는 것이라고 가정하면, 어디까지나 연구개발'관리'에 국한된 것이어야 한다.

또 다른 우려는 이 자격증이 어떤 식으로든 필수적인 요건으로 자리잡게 될 경우 발생할 문제점이 보인다는 것이다. 신설된 제도가 유명무실해지는 것을 막기 위해서 이 자격증을 필수로 하는 일들이 신설될 수도 있다. 예를 들어서 정부연구개발사업을 신청하는 연구책임자는 이 자격증이 있어야 한다거나, 기업 부설 연구소에는 반드시 연구개발관리사 자격증을 취득한 사람이 근무하도록 규정을 만든다거나... 그러면 이 자격증 취득을 위해 교육과정을 준비하고 시험을 주관하는 단체는 확고한 수익 모델을 얻는 셈이 된다. 말하자면 요즘 지나치게 남발되는 민간자격증제도의 나쁜 점을 답습할 우려가 있다는 것이다.

이제는 연구개발도 자격증 시대가 오는가? 학위와 경력 및 그동안의 업적으로도 부족하고 특정 자격증이 있어야만 하는 시대가 올지도 모르겠다. 연구개발관리사, 빅데이터분석사, 연구개발성과확산사, 해외네트워크구축사, 연구부정행위감별사...

Python 3.5.2 설치하고 pyani 실행하기

미생물 유전체의 average nucleotide identity와 관련한 계산 및 그림을 그려주는 도구(pyani)를 설치하려고 보니 python 3이 필요하다. 내 리눅스 컴퓨터에는 CentOS 6.7이 제공하는 python 2.6 및 linuxbrew가 제공하는 python 2.7이 공존한다. 이제 python 3.5는 또 어떻게 설치할 것인가?

루트 권한을 가지고서 소스로부터 설치하는 방법이 있는가 하면, pyenv를 쓰는 방법이 있다. 다른 버전을 그대로 둔 상태에서 평화롭게 공존하도록 설치해야 함이 관건이다.

소스로부터 설치하기

GCC는 여전히 4.4.7이다. linuxbrew가 설치된 상태이므로 su 명령으로 관리자 권한을 획득하면 GCC 5.3.0을, su -로 전환하면 GCC 4.4.7을 쓰게 된다. GCC 4.4.7로는 make test를 통과하지 못했다. 따라서 GCC 5.3.0을 쓰기로 한다. 가장 마지막 단계에서 "make altinstall"을 하는 것이 매우 중요하다. 만약 make install을 해 버리면 기존의 python 명령어를 덮어쓸 것이고, 어떤 문제가 생길지 나도 모른다!

# ./configure --prefix=/usr/local
# make
# make test
# make altinstall
...
Installing collected packages: setuptools, pip
Successfully installed pip-8.1.1 setuptools-20.10.1
# ls /usr/local/bin/python*
/usr/local/bin/python2.7         /usr/local/bin/python3.4m         /usr/local/bin/python3.5m
/usr/local/bin/python2.7-config  /usr/local/bin/python3.4m-config  /usr/local/bin/python3.5m-config
/usr/local/bin/python3.4         /usr/local/bin/python3.5

여기서 궁금증이 발생한다. python3이 관여하는 pip-8.1.1이 도대체 어디에 있단 말인가? 테스트를 해 보자.

# pip -V
pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)
# pip2 -V
pip 8.1.2 from /usr/local/lib/python2.7/site-packages (python 2.7)
# pip3 -V
pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)
# exit
$ pip -V
pip 8.1.2 from /home/hyjeong/.linuxbrew/Cellar/python/2.7.12_1/lib/python2.7/site-packages (python 2.7)
$ pip2 -V
pip 8.1.2 from /home/hyjeong/.linuxbrew/Cellar/python/2.7.12_1/lib/python2.7/site-packages (python 2.7)
$ pip3 -V
pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)

정말 복잡한 환경이다!

pyani 설치하기

관리자 권한으로 pip3 install pyani를 실행하니 GCC 5.3.0에서는 에러가 발생한다. GCC 4.4.7에서는 잘 설치가 되었다. 도대체 왜 이렇게 복잡한 것인가...  어쨌든 설치는 했으니 실행을 해 보자. average_nucleotide_identity.py가 핵심 스크립트이다. output directory는 이미 존재하는 디렉토리를 지정하면 안된다. 특별히 지정하지 않으면 mummer를 사용하여 순식간에 nucleotide 간의 identity를 계산한다. 가용한 thread를 다 사용하여 계산을 하니 당연한 결과일지도 모른다.

$ average_nucleotide_identity.py -v -i . -o out -g

결과 그림을 보자. 어쩌면 앞으로는 JSpecies를 쓰지 않게 될지도 모르겠다.

pyani는 NCBI tax ID를 이용하여 한번에 유전체 정보를 내려받을 수 있는 스크립트인 genbank_get_genomes_by_taxon.py도 포함하고 있다. ANI 분석을 할 때 매우 유용하게 쓸 수 있을 것이다. 너무 많은 genome 파일을 내려받지만 않을 수 있다면 말이다.

pyenv는 어떻게 하라고?

홈 디렉토리에 .pyenv라는 디렉토리가 있는 것으로 보아 분명히 pyenv를 설치하여 사용한 경험이 있다! 각 파이썬 버전은 ~/.python/version에 설치하도록 되어있다. 소스로부터 /usr/local에 이미 python 3.x를 설치해 버렸으니 pyenv를 경유하여 쓰도록 다시 설치하는 것은 혼란을 줄 여지가 있다. 우선은 그냥 두자!