2021년 4월 30일 금요일

.wgetrc 파일에 CA 인증서 파일 위치를 지정하여 'https://'로 시작하는 URL의 파일 다운로드하기

https://~(443 port)로 시작하는 URL의 파일을 리눅스 명령행(wget 사용)에서 다운로드할 때 에러가 발생하면 '--no-check-certificate' 옵션을 제공하면 된다는 것을 이제는 상식적으로 알고 있다. 하지만 왜 윈도우에서는 문제가 없을까? 집에서 테스트를 하면 왜 잘 될까? 리눅스 환경에서 프로그램이 자체적으로 다운로드를 실시할 때 알아서 진행되게 할 수는 없을까? 

이에 대한 고민을 2018년부터 해 왔고 부분적으로는 해결 방법을 찾았지만 체계적인 지식이 부족하여 늘 애를 먹다가 TORMES pipeline의 업그레이드를 계기로 진지하게 접근해 보기로 하였다.

간단히 설명하면 이러하다. SSL(TLS가 더 정확한 용어일지도 모름)은 서버와 클라이언트 사이에서 패킷을 암호화하여 주고받음으로써 외부에서 이를 가로채도 무슨 의미인지 알 수 없게 만드는 것이 목적이다. 또 다른 목적은 내가 접속하는 웹사이트가 가짜가 아님을 확인해 주는 것이다. 보안 전문가의 견해로는 SSL에 대한 나의 해석이 100% 정확하지 않을 수도 있지만, 일반인 수준에서는 이 정도로 이해하면 된다.

그런데 패킷이 암호화되어서 돌아다니게 되니 기관의 보안 관리 입장에서는 내부의 중요한 정보가 빠져나가도 알 수가 없게 되었다. 그래서 이를 감시하는 SSL 복호화 솔루션을 쓰게 된다. SOMANSA니 SOOSAN INT니 하는 회사가 바로 이런 네트워크 보안 솔루션을 제공하는 곳이다. 이런 보안 솔루션이 적용되는 전산망 내부에서 인터넷을 쓰려면 이들 회사에서 제공하는 CA 인증서를 받아서 웹브라우저에 설치해야 한다. 처음에는 이를 이해하지 못했었다. 왜냐하면 SOMANSA나 SOOSAN INT는 원래 인증서를 발급하는 기관이 아니기 때문이다. 기업에서 2년 동안 근무할 때에는 SOMANSA의 것을, 한 뒤 연구소에 돌아와서 처음으로 인터넷을 연결했더니 SOOSAN INT의 SSLPrisim.crt라는 파일을 웹브라우저에 설치하라고 한다. 이 파일은 일종의 CA(certificate authority 또는 root certificate) 역할을 한다. 연구소 전산망 내의 컴퓨터에서 웹브라우저의 주소창에 sslcert.cc라는 곳을 치면 자동으로 다운로드할 수 있다. 리눅스의 파이어폭스에서도 똑같은 일을 하면 된다.

2021년 5월 18일 업데이트: 내가 근무하는 곳의 전산망을 벗어난 곳에서 sslcert.cc를 웹브라우저의 주소창에 입력하면 SSLPrisim.crt 파일을 받을 수가 없다. 이건 당연한 이야기이다. 화면에 보이는 메시지에는 'ePrism SSL 정식 사용자에게만 제공'함을 밝히고 있다.

만약 모든 인터넷 접속(파일 다운로드 포함) 작업을 웹브라우저에서 한다면 이렇게 하는 것만으로도 문제가 없다. 그런데 리눅스에서는 wget, curl 등을 써서 명령행에서 파일을 가져올 일이 많다. 또한 conda, curl, R, pip 등 자체적으로 https:// 위치에 있는 파일을 가져오는 명령어가 있는데, 웹브라우저(SSLPrism.crt를 이미 알고 있는)는 전혀 경유하지 않으므로 문제가 생긴다.

https:// 위치에 있는 모든 파일을 가져오는데 문제가 생기는 것은 아니다. 테스트를 해 본 결과 자체 인증서를 쓰는 웹사이트만 그러한 것 같다. 예를 들어 보자.

$ wget https://cran.rstudio.com
--2021-04-30 09:28:19--  https://cran.rstudio.com/
cran.rstudio.com (cran.rstudio.com)() 해석하는 중... 52.84.166.5, 52.84.166.79, 52.84.166.102, ...
접속 cran.rstudio.com (cran.rstudio.com)|52.84.166.5|:443... 접속됨.
오류: cran.rstudio.com의 인증서를 확인할 수 없습니다. 발행자는 `CN=ePrism SSL,O=SOOSAN INT,C=KR'입니다:
  자기 자신이 서명한 인증서를 발견했습니다.
cran.rstudio.com에 안전하지 않게 연결하려면 `--no-check-certificate'를 사용하십시오.

OpenSSL 명령어를 사용하여 접속 테스트를 해 보아도 같은 종류의 메시지가 나온다. 

$ echo quit | openssl s_client -showcerts -servername "cran.rstudio.com" -connect cran.rstudion.com:443 > 
test.ca-bundle
depth=1 C = KR, O = SOOSAN INT, CN = ePrism SSL
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 C = KR, O = SOOSAN INT, CN = ePrism SSL
verify return:1
depth=0 CN = cran.rstudio.com
verify return:1
DONE

자체 서명한 인증서를 쓴다는 것이고, 직장 전산망을 보호(?)하는 ePrism SSL VA 장비는 이를 차단하는 것으로 보인다.만약 같은 웹사이트에 대해서 집에서 wget 명령어를 실행하면 어떻게 될까? 아무런 문제가 없이 다운로드가 잘 이루어진다. OpenSSL 명령어에 대한 결과는 이러하다.

$ echo quit | openssl s_client -showcerts -servername "cran.rstudio.com" -connect cran.rstudio.com:443 > test.ca-bundle
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = cran.rstudio.com
verify return:1
DONE

접속한 사이트가 자체 인증서를 쓰는지의 여부는 화면상으로 출력되지는 않는다. 파일로 리다이렉트한 CA bundle에는 혹시 그런 내용이 기록되는지는 아직 확인해보지 않았다.

SSLPrism.crt 파일은 자체 인증서를 쓰는 웹사이트임을 알게 된 경우에 사용하는 대체용 CA 인증서일 것이라는 생각이 들었다. 리눅스 혹은 윈도우 웹브라우저에서 이 사이트를 접속한 뒤 주소창 왼쪽의 잠겨진 자물쇠를 클릭하여 인증서 정보를 확인하여 보라. 발급자는 ePrism SSL로 나타난다.


자, 그러면 리눅스 명령행에서 wget 명령어가 SSLPrism.crt 파일을 이용하게 만들면, 매번 '--no-check-certificate'를 쓸 일이 없을 것이다. ~/.wgetrc 파일을 편집하여 사용자가 원하는 설정 사항을 기록하면 된다고 하여 그대로 따라해 보았다.

$ echo 'ca-certificate=~/SSLPrism.crt' > .wgetrc
$ wget https://cran.rstudio.com
--2021-04-30 09:05:11--  https://cran.rstudio.com/
cran.rstudio.com (cran.rstudio.com)() 해석하는 중... 52.84.166.102, 52.84.166.5, 52.84.166.64, ...
접속 cran.rstudio.com (cran.rstudio.com)|52.84.166.102|:443... 접속됨.
HTTP 요청을 전송했습니다. 응답을 기다리는 중입니다... 200 OK
길이: 850 [text/html]
다음 위치에 저장: `index.html'

index.html                          100%[======================================>]     850  --.-KB/s    / 0s       

2021-04-30 09:05:11 (27.9 MB/s) - `index.html' 저장됨 [850/850]

옳거니! SSLPrism.crt 파일을 이렇게 하여 웹브라우저가 아닌 다른 애플리케이션이 쓰도록 만들어 보았다. 이것으로 만족할 수 있는가? 전혀 그렇지 않다. 겨우 wget 명령어에 대해서만 개별적인 CA 인증서를 적용하게 만들었기 때문이다.

명령행을 위한 인증서 설치 방법

시스템 전체에 적용할 수 있는 인증서 설치 방법을 알아보자. 참고한 웹사이트는 다음과 같다.  우분투의 경우라면 update-ca-certificates 유틸리티를 사용하여 SSLPrism.crt를 설치하는 것이 핵심이다. CentOS는 조금 다르다.


작동이 잘 됨을 확인하기 위해 조금 전에 설정한 .wgetrc 파일을 지웠다.

$ rm .wgetrc index.html
$ sudo mkdir /usr/local/share/ca-certificates/kribb
$ sudo cp SSLPrism.crt /usr/local/share/ca-certificates/kribb
$ sudo update-ca-certificates 
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
$  wget https://cran.rstudio.com
--2021-04-30 09:58:14--  https://cran.rstudio.com/
cran.rstudio.com (cran.rstudio.com)() 해석하는 중... 52.84.166.79, 52.84.166.5, 52.84.166.102, ...
접속 cran.rstudio.com (cran.rstudio.com)|52.84.166.79|:443... 접속됨.
HTTP 요청을 전송했습니다. 응답을 기다리는 중입니다... 200 OK
길이: 850 [text/html]
다음 위치에 저장: `index.html'

index.html                            100%[=============================>]     850  --.-KB/s    / 0s       

2021-04-30 09:58:14 (24.7 MB/s) - `index.html' 저장됨 [850/850]

잘 작동한다!  그러나 아직 안심을 하기는 이르다. Conda, git, pip, R(패키지 업데이트) 등의 명령이 잘 돌아가는지 전부 확인을 해 보지는 못했기 때문이다. TORMES v1.2.1를 지우고 새로 설치해 보니 CA 인증서를 업데이트한 것만으로 모든 명령어(443번 포트에서 파일을 다운로드하는)에 전부 대응하는 것은 아니었다. 이에 대해서는 다시 한번 확인을 한 다음 새 글에서 정리하겠다.

TORMES 1.2.1의 재설치 테스트

SSLPrism.crt를 system-wide하게 설치했다고 해서 https:// 위치의 파일을 가져오는 모든 응용프로그램이 다 정상적으로실행될까? TORMES를 재설치하는 과정에서 알아보았다. 역시나 그렇지는 않았다. 최소한 wget은 오류 없이 실행이 된다. 그러나 파일을 다운로드하는 기능이 포함된 파이썬 스크립트 quast-download-silva와 quast-download-busco는 작동을 하지 않아서 wget으로 직접 다운로드한 뒤 target 위치에 복사를 해야 된다. tormes-setup에서 treeio와 ggtree 및 기타 패키지를 받아오려면 명령행에서 CURL_CA_BUNDLE 환경변수를 선언하거나 ~/.Renviron에서 설정을 해야 된다. 이 변수가 가리킬 CA bundle  파일을 만드는 과정은 여기에 설명하였다.

마지막으로,  git가 SSL 인증 과정을 건너뛰도록 'git config --global http.sslVerify false' 명령을 주거나(~/.gitconfig 파일에 기록) 'export GIT_SSL_NO_VERIFY=0'을 실행해야 한다(참조글 링크). TORMES의 설치 과정에서 나오는 오류 - 아직 이해하기 어려운 - 는 다음과 같다. 실제 데이터를 이용한 tormes 실행에서는 특별한 문제가 발생하지 않았다.

# tormes-1.2.1 환경 셋업 과정에서
...
ClobberError: This transaction has incompatible packages due to a shared path.
  packages: bioconda/noarch::abricate-1.0.1-ha8f3691_1, bioconda/noarch::mlst-2.19.0-hdfd78af_1
  path: 'LICENSE'
...

# tormes-setup 스크립트의 마지막 부분인 RDPToos 설치 과정
...
BUILD SUCCESSFUL
Total time: 4 seconds
(cp Framebot/dist/FrameBot.jar Clustering/dist/Clustering.jar SequenceMatch/dist/SequenceMatch.jar classifier/dist/classifier.jar AbundanceStats/dist/AbundanceStats.jar ReadSeq/dist/ReadSeq.jar SeqFilters/dist/SeqFilters.jar ProbeMatch/dist/ProbeMatch.jar KmerFilter/dist/KmerFilter.jar Xander-HMMgs/dist/hmmgs.jar AlignmentTools/dist/AlignmentTools.jar ./; cp -r */dist/lib/* lib/; rm -r classifier/dist/)
cp: 방금 만든 'lib/ReadSeq.jar''AlignmentTools/dist/lib/ReadSeq.jar'로 덮어쓰지 않음
cp: 방금 만든 'lib/commons-cli-1.2.jar''AlignmentTools/dist/lib/commons-cli-1.2.jar'로 덮어쓰지 않음
cp: 방금 만든 'lib/ReadSeq.jar''Clustering/dist/lib/ReadSeq.jar'로 덮어쓰지 않음
...

도대체 update-ca-certificates로 수동 설치한 인증서를 쓰는 응용프로그램은 wget 말고 뭐가 더 있는지 모르겠다!


2021년 4월 28일 수요일

TORMES의 샘플 수가 오락가락한 이유는 metadata file에 들어간 작은 따옴표 때문이었다

TORMES v1.2.1은 어렵게 설치하고 테스트를 하면서 분석에 투입한 샘플이 제대로 다 결과에 반영되지 않는 현상을 기이하게 생각하면서 원인을 찾고자 며칠을 허비하였다. 텍스트로 구성된 샘플 metadata 파일에 문제가 있을 것이라 생각하면서 이러저러한 조합으로 계속 시험을 해 본 결과 원인은 아주 간단한 곳에 있었다. Description을 적는 컬럼에 따옴표가 들어간 것이 문제였던 것이다. 

ABC company's lead strain

신약 개발에서 lead compound라는 용어가 쓰이듯, 프로바이오틱스 혹은 미생물 치료제 개발 분야에서도 lead strain이라는 용어가 쓰이는 것을 알고 있다. 위에 보인 사례에서는 사실 소유격을 표시하는 특수문자이므로 아포스트로피(apostrophe)가 맞지만, 현재는 키보드 엔터키 왼쪽의 작은 따옴표와 혼용되고 있다.

이것을 R로 읽어 들이면서 문제가 되었던 것이다. 만약 분석에 사용할 metadata 파일이 정상인지 알고 싶다면 R에서 다음과 같이 입력해 보라.

> data=read.table("metadata.txt", header = T, sep = "\t", dec = ".", check.names = FALSE)

아무런 에러가 나오지 말아야 한다. 아포스트로피를 살리고 싶다면 다음과 같이 큰따옴표로 둘러싸서 입력하면 된다.

ABC company"'"s lead strain

실제 사례를 보자.

$ cat metadata.txt 
Samples	Read1	Read2	Description
XYZ01	GENOME	genomes/xyz.fasta	GenoGlobe's lead strain
JCM30893	GENOME	genomes/JCM_30893.fasta	JCM 30893 strain (a Japanese isolate)
ATCC_BAA-835T	GENOME	genomes/ATCC_BAA-835T.fasta	ATCC BAA-835T (type strain, aka Muc)
KGMB02009	GENOME	genomes/test.fasta	SAMN18309827 (a South Korean isoalate)
$ R
> data=read.table("meta.txt", header = T, sep = "\t", dec = ".", check.names = FALSE)
경고메시지(들): 
In read.table("metadata.txt", header = T, sep = "\t", dec = ".", check.names = FALSE) :
  'meta.txt'에서 readTableHeader에 의하여 발견된 완성되지 않은 마지막 라인입니다
> data
        Samples  Read1                       Read2
1 ATCC_BAA-835T GENOME genomes/ATCC_BAA-835T.fasta
2     KGMB02009 GENOME          genomes/test.fasta
                             Description
1   ATCC BAA-835T (type strain, aka Muc)
2 SAMN18309827 (a South Korean isoalate)

Metadata 파일에는 분명히 4개의 샘플을 선언하였지만 data 데이터프레임에는 단 2개가 남았다. 파일에 따라서는 '따옴표로 묶인 문자열내에 EOF가 있습니다'라는 약간 다른 형태의 경고메시지가 나오기도 한다. 그러나 '를 "'"로 바꾸면 경고메시지가 나오지 않는다.

균주에 따라서는 MLST 분석 결과가 나오지 않을 수도 있다. Assembled genome sequence를 입력했다면 Assembly statistic 항목을 리포트에 표시할 필요가 없다. 리포트에서 불필요한 섹션을 제거하려면 결과 파일 report_files.tgz의 압축을 해제하여 나오는 tormes_report.Rmd 파일을 적절히 수정한 다음, render_report.sh 스크립트를 돌리면 된다. 이 스크립트 역시 report_files.tgz에 포함되어 있다.

Bactopia: a flexible pipeline for complete analysis of bacterial genomes(mBio 2020)에도 관심을 가지기 시작하였다. 그러나 아직 설치 문제를 해결하지 못했다. https://로 시작하는 URL에 있는 DB 파일을 가져오는 파이썬 스크립트가 말썽을 부린다. 만익 일반 shell script에서 wget 명령으로 파일을 가져오게 하였다면, '--no-check-certificate' 옵션을 달아서 해결하면 되는데, Bactopia에서는 파이썬 스크립트 내에 아예 심어 놓았기 때문이다.  정확히 말하자면 Bactopia 자체는 아니고, 여기에서 같이 다운로드하게 만드는 Sanger Institute의 ARIBA(Antimicrobial Resistance Identification By Assembly)의 레퍼런스 DB 다운로드 및 설치 과정에서 문제를 겪는 것이다.

https, 443번 포트, SSL 인증서... 보안이 적용된 전산망 안에서 일을 하려니 이런 데에서 장애가 생긴다. wget, conda, R 등 서로 다른 계층에서 문제가 발생하고 있으며, 파이썬 스크립트는 또 어떻게 한담? 만약 집에서 똑같은 환경을 구축하면 아무런 문제가 없을 것 같다. 이걸 그대로 복사하여 들고 출근하여 이식을 하면 어떨까?

2021년 4월 27일 화요일

SSL을 둘러싼 conda의 에러는 CentOS에서 Ubuntu로 바뀌면서 사라지다

Conda의 업데이트를 시도하다가 다음과 같은 에러를 만났다. 

$ conda update conda
Collecting package metadata (repodata.json): failed

CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://conda.anaconda.org/conda-forge/linux-64/repodata.json>
Elapsed: -

An HTTP error occurred when trying to retrieve this URL.
HTTP errors are often intermittent, and a simple retry will get you on your way.
u'https://conda.anaconda.org/conda-forge/linux-64'

워낙 잘 알려진 에러라서 네이버나 구글을 치면 해결책이 나온다. '.condarc' 파일에 'ssl_verify" false'라고 한 줄만 써 넣으면 된다고 한다. 그런데... 위 화면에 나온 메시지는 이미 .condarc를 수정한 다음의 상태이다. OpenSSL을 써서 해당 사이트에 대한 CA bundle을 만들어서 공급해 보기도 하였으나 역시 마찬가지였다.

흠, 나의 CentOS 환경(항상 최신으로 업데이트를 해 왔지만)이 어딘가 꼬였단 말인가. 

같은 전산망에 묶여 있는 다른 서버에서 이 문제가 재현되는지를 알아보기로 하였다. 이 서버에는 우분투 20.04가 설치된 상태이다. Anaconda3-2020.11-Linux-x86_64.sh를 다운로드하여 설치를 시작하였다. 아무런 문제가 없다. Conda base environment에 진입하여 'conda update conda'를 실행하였다. 역시 아무런 문제가 없다. 

이번에는 의존성이 과도한 편에 속하는 응용프로그램인 tormes-1.2.1 환경을 설치해 보았다. 아무런 문제가 없다. QUAST 관련 DB와 utility를 설치하는 스크립트인 quast-download-gridss, quast-download-silva, quast-download-busco를 실행할 때에는 https:// 아래에 있는 일부 파일을 가져오지 못하는 문제가 있었다. 이것은 'wget --no-check-certificate'로 간단히 해결하였다. 설치 마지막 과정에서는 'tormes-setup'을 실행해야 하는데 이게 순탄하지는 않았다. 그 과정은 조금 시간을 두고 정리하고자 한다. 왜냐하면 raw sequencing read가 없이 오직 genome assembly만을 사용하여 tormes를 실행하면 결과가 좀 이상하게 나오기 때문이다. 분명히 4 개의 genome을 투입했는데 결과는 2 개만 나오고 있다. 개발자 사이트 쪽에서 실제 작동하는 샘플 파일을 메타데이터 파일과 같이 제공하면 참 좋을 것이다.

2021년 4월 28일 업데이트

tormes-setup을 실행하면 R 패키지를 설치하는 과정에서 에러가 난다. 메시지를 보면 cran.rstudio.com과 bioconductor.org 사이트를 443번 포트로 접속하여 패키지를 다운받지 못하는 것이다. openssl을 사용하여 다음과 같이 두 사이트에 대한 CA bundle을 만들어 하나의 파일로 저장한 다음, 이를 .Renviron 파일에 지정하는 편법을 동원하였다.

$ echo quit | openssl s_client -showcerts -servername "cran.rstudio.com" -connect cran.rstudio.com:443 > cran.rstudio.com.ca-bundle
depth=1 C = KR, O = SOOSAN INT, CN = ePrism SSL
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 C = KR, O = SOOSAN INT, CN = ePrism SSL
verify return:1
depth=0 CN = cran.rstudio.com
verify return:1
DONE
$ echo quit | openssl s_client -showcerts -servername "bioconductor.org" -connect bioconductor.org:443 > bioconductor.org.ca-bundle
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = *.bioconductor.org
verify return:1
DONE
$ cat cran.rstudio.com.ca-bundle bioconductor.org.ca-bundle > test.ca-bundle
$ cp test.ca-bundle ~/.cert
$ cat ~/.Renviron
CURL_CA_BUNDLE=.cert/test.ca-bundle
이렇게 한 다음, tormes-setup에서 해당되는 부분만 뽑아서 별도의 스크립트를 만들어 실행하였다. $TORMESDIR 변수는 각자 conda 설치 상황에 따라 다를 것이다. 홈 디렉토리에서 실행하지 않을 때를 감안하여 안전하게 'export CURL_CA_BUNDLE=${HOME}/.cert/test.ca-bundle'이라고 선언하는 것이 좋을 것이다.
$ cat R_package_install.sh
export TORMESDIR=/home/hyjeong/anaconda3/envs/tormes-1.2.1/bin
export R_LIBS=$TORMESDIR/../lib/R/library/
Rscript -e 'library(BiocManager); BiocManager::install(version = "3.10", ask = FALSE, lib.loc="$TORMESDIR/../lib/R/library/")'
Rscript -e 'library(BiocManager); BiocManager::install("ggtree", ask = FALSE, lib.loc="$TORMESDIR/../lib/R/library/")'
Rscript -e 'library(BiocManager); BiocManager::install("treeio", ask = FALSE, lib.loc="$TORMESDIR/../lib/R/library/")'
하지만 TORMES-1.2.1의 실행은 아직 완벽하지 않다. 일루미나 read를 이용하여 실행하면 과거와 같이 별 문제가 없는데, 유전체 서열을 넣으면 sample-metadata 파일의 파싱 과정에서 자꾸 에러를 발생한다. 문법적으로 무엇이 틀렸는지 도무지 찾을 길이 없다. 과거에는 잘 되던 것(된다고 믿었던 것?)이 며칠째 속을 썩인다. 메타데이터 파일에서 첫번째 컬럼인 샘플명에는 특수문자를 쓰지 말라고 하는데, 밑줄이나('_') 대시('-') 정도는 허용을 해야 하지 않을까? R에서는 컬럼/로 헤더에는 밑줄을 허용하지 않는 것 같았다. TORMES에서는 (메타)데이터 파일의 처리에 R을 적극적으로 사용하므로 규칙을 잘 따르는 것이 필요하다.

TORMES와 유사한 세균 유전체 분석 파이프라인인 Bactopia라는 것이 눈길을 끈다. 이것도 우분투 최신 환경에 설치해 놓고서 어떻게 쓰는 것인지를 공부하려고 한다.


아, 이것도 설치가 쉽지 않다. Sanger Institute의 ARIBA(Antimicrobial Resistance Identification By Assembly)의 작동을 위해 레퍼런스 DB를 내려받아야 하는데, 역시 https의 문제에 부딛힌다. 이건 또 어떻게 해결한다?


2021년 4월 21일 수요일

티라미수 II(Tiramisu II) 6LQ8 push-pull amplifier의 제작

티라미수 앰프는 나의 수도권 생활 시절에 귀를 즐겁게 하던 6LQ8 푸시풀 앰프이다. 제이앨범에서 구한 PCB 등 핵심 부품을 사용하여 생애 처음으로 만든 진공관 푸시풀 앰프에 해당한다. 6LQ8은 오디오 신호를 다루기 위해 만들어진 진공관은 아니다. 구관이 점점 귀해지면서, TV 수신기에서 다른 목적으로 쓰이던 진공관을 오디오 앰프용으로 재발견하는 동호인들의 노력 덕분에 세상에 알려지게 되었다. 이 앰프가 만들어지도록 부품과 영감을 아낌없이 제공한 제이앨범 한병혁 님에게는 평생 빚을 진 셈이다. 

티라미수 앰프의 초창기 버전은 과거 블로그의 글에 기록이 남아 있다. 이보다 더 앞선 버전에서는 색을 칠하지 않는 대나무 도마를 상판으로 사용하였기에 티라미수를 전혀 닮지 않았다.

[2020년도 6LQ8 푸시풀 앰프 `티라미수` 리모델링] 2. 끝내기

6LQ8 Push-Pull Amplifier "Tiramisu"(2020년 3월 제작). 상판은 MDF에 오일스테인(본덱스)를 칠한 것이다. 아쉽게도 그 뒤에 금속제 케이스를 가공하여 옮겨가면서 이 모습은 남아있지 못하다.

티라미수를 닮은 예전 모습에 향수를 느껴서 이를 다시 만들기로 하였다. 외형은 오리지널 티라미수의 모습을 따르지만 성능은 이보다 더 나아져야 하지 않겠는가? 그래서 몇 가지의 개선을 가해 보기로 했다.

  • 상판은 MDF에서 자작나무 합판으로 바꾼다.
  • OPT는 6J6 PP 앰프에서 적출한 것에서 DHT사운드의 57 코어 제품으로 바꾼다. 이전에 쓰던 OTP는 개인 제작자로부터 유래한 것이라 정확한 사양을 알지 못한다.
  • 저음량 영역에서 좌우 밸런스가 심하게 맞지 않던 중국제 미니 사각 포텐셔미터를 '제대로 된' 직경 16mm 납땜형으로 바꾼다. Alpha사의 것을 구입하고 싶었으나 단가 850원과 6,500원 사이에서 선택할 것은 뻔하지 않은가? 일제 알프스 블루벨벳(18,000원)은 언제나 한번 써 볼 수 있을까? 파나소닉 전동볼륨이 요즘 싼 가격에 많이 나오지만 모터가 달려 있어서 너무 길다. 모터를 탈거하고 쓰는 사람도 있다고 들었다.
개작을 위해 부품을 수급하면서 흰 플라스틱 바구니('다이소 큐브 바구니')를 찾는데 의외로 어려움을 겪었다. 과거에 쓰던 사각구멍 다이소 바구니를 이제는 온라인/오프라인 매장 어디를 찾아도 팔지 않는 것이다. 검색을 하면 사진은 나오지만 구입 가능한 상태가 아니다. 엊그제 다이소 매장을 가 보았으나 이런 스타일은 없었고, 좀 더 부드러운 재질이거나 혹은 라탄 바구니를 흉내낸 것이 전부였다.

고통스런 구글링을 통해서 이전 모습을 가장 많이 닮은 것을 하나 주문해 놓았지만 언제 배송이 될지 잘 모르겠다. 오리지널 티라미수의 베이스로 쓰이던 바구니는 작년에 버렸고, 다른 용도로 쓰던 동일 제품(이 글에서 그 모습을 볼 수 있음)이 하나 남아 있지만 구멍을 너무 많이 뚫어 놓아서 보기에 좋지 않다. 만약 새로 주문한 제품의 모습이 영 아니다 싶으면 이것이라도 쓰지 않을 수가 없다.

'티라미수 II'가 과연 어떤 모습으로 탄생할지 나도 궁금하다.
 

2021년 5월 8일 업데이트

완성된 티라미수 II 앰프의 모습을 사진으로 남겼다. 제작 완료일은 아마도 4월 27일.


그리고 진짜 티라미수는 이렇게 생겼다. 생일을 기념하여 아들이 성심당에서 사 온 것이다.

 

2021년 4월 16일 금요일

수퍼마이크로 X9DRI-F 마더보드 VGA 커넥터 자가 수리(?)

이걸 수리라고 하기는 대단히 쑥스럽다. 씹던 껌을 붙여서 물이 새는 그릇을 임시방편으로 수리한 정도에 불과하기 대문이다. 혹시 미국 드라마 '맥가이버'에서 바리케이드 경진대회 에피소드를 기억하시는 분은 댓글을 달아주시길. 장래가 촉망받던 재능 있는 젊은이가 왜 '빌런'이 되는지를 보여주는 내용이었다. 로보트 태권V의 카프 박사도 그랬고...

2013년에 구입하여 사용해 오던 Supermicro X9DRi-F 주기판의 온보드 VGA 커넥터에 문제가 생겼다. 케이블을 꽂은 상태에서 힘을 가하면 커넥터가 안쪽으로 꺾여 들어가는 것이다. 일정 각도가 넘어가면 모니터에 신호가 가지 않는다. PCB에 붙이는 단자대가 이렇게 쉽게 꺾일 일은 없을텐데?

일반적인 D-sub 커넥터의 구조는 다음의 이미지와 같다. 안쪽으로 꺾일 수 있는 구조는 아니다.

2U 랙 마운트 서버의 뚜껑을 열고 도대체 커넥터 부위가 어떻게 생겼는지를 확인해 보았다. 아래 사진에서 램 소켓의 오른쪽 끝에 커넥터가 접하고 있다. 견고한 지지대 같은 것이 전혀 보이지 않는다. 혹시 핀이나 패턴이 끊어진 상태로 단지 접촉만 하고 있는 것은 아니었을까?
램 소켓과 커넥터 뒤쪽에 적당한 물체를 끼워서 커넥터가 안쪽으로 꺾이지만 않게 하면 쉽게 당장은 문제를 해결할 수 있을 것 같았다. 적당한 물체가 뭐가 있을까? 문구류를 보관하는 수납함에서 만년필 카트리지 하나를 꺼낸 뒤 라벨용 테이프(생물학 전공자라면 누구나 아는)를 감아서 약간 두껍게 만든 다음 빈 틈에 끼웠다.
완벽하다! 커넥터는 더 이상 안쪽으로 꺾이지 않는다. 메모리 고정용 걸쇠의 움직임에도 장애가 없다. 카트리지가 저절로 터져서 잉크가 흘러나오지는 않을까? 그보다는 본체 내부의 발열에 의해 잉크가 조금씩 말라 없어질 가능성이 더 크다. 혹은 카트리지 내부의 공기가 팽창하여 입구 부분에서 잉크가 새어 나온다면? 여름이 오기 전에 확인을 해 봐야 되겠다. 차라리 나무젓가락을 잘라서 끼우는 것이 나을지도 모르겠다.

서버의 덮개를 연 모습 전체를 사진으로 찍어 보았다. RAID 콘틀롤러(Adaptec ASR-6405)에는 6T HDD가 2개 붙어 있다. 컨트롤러에 연결된 커넥터에는 총 4개의 HDD를 달 수 있게 되어 있다. 필요하다면 이것을 다 채워서 스토리지 전용으로 쓸 수도 있을 것이다. 그러나... 그럴 바에는 차라리 시놀로지 같은 회사의 NAS가 더 낫지 않을까? 작고 소음도 적고 관리도 편리하니 말이다.
노란색 타원으로 표시한 곳이 오늘 수리(?)한 부위다.
이 서버는 앞으로 우분투 20.04 전용으로 쓰일 것이다. CentOS가 설치된 서버도 하나, 우분투 스튜디오는 둘. 앞으로 업무용 서버급 혹은 워크스테이션급 컴퓨터를 사게 된다면 조금 비싸더라도 관리가 편리한 소위 '벤더' 제품을 사게 될 가능성이 크다. 조립 서버의 경험은 어쩌면 지금 갖고 있는 것이 마지막이 될 것만 같다.




2021년 4월 14일 수요일

갑자기 USB 드라이브의 용량이 작아졌을 때

값이 싼 것으로 잘 알려진 16GB SanDisk Cruzer Blade에 우분투 스튜디오 20.04 ISO 이미지를 구워서 설치용으로 쓴 다음 윈도우쪽 PC에 꽂아서 다른 용도로 쓰려고 했더니 용량이 터무니없게 적은 것으로 표시된다. 종종 겪는 일이다. 

쌘디스크? 싼디스크? 배경의 줄리안 오피 작품은 이래 봬도 진품이다.
윈도우 7이나 10에서 디스크 관리 유틸리티를 이용해야 제 용량을 되찾을 수 있다. 리눅스 쪽에서 해결을 할 수도 있겠지만 마침 지금 켠 컴퓨터가 윈도우이니 여기에서 해결해 보도록 하자. 다음 웹문서에서는 명령행 환경에서 돌아가는 유틸리티인 diskpart를 사용하는 사례를 소개하였다. 이를 이용하여 제 용량을 되찾을 수 있었다.

USB 메모리(flash drive)가 갑자기 용량이 작아졌을 때

실제 내가 작업한 기록은 다음과 같다. "cmd(명령 프롬프트 앱)"를 관리자 권한으로 실행해야 한다.

Microsoft Windows [Version 10.0.18362.836]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>diskpart

Microsoft DiskPart 버전 10.0.18362.1

Copyright (C) Microsoft Corporation.
컴퓨터: DESKTOP-HA1DTJ2

DISKPART> list disk

  디스크 ###  상태           크기     사용 가능     Dyn  Gpt
  ----------  -------------  -------  ------------  ---  ---
  디스크 0    온라인        931 GB       1024 KB        *
  디스크 1    온라인         14 GB       3572 MB <= 이것이 USB 드라이브!

DISKPART> select disk 1

1 디스크가 선택한 디스크입니다.

DISKPART> list partition

  파티션 ###  종류              크기     오프셋
  ----------  ----------------  -------  -------
  파티션 1    주                 4000 KB  3571 MB
  파티션 2    주                   10 GB  3578 MB

DISKPART> clean

DiskPart에서 디스크를 정리했습니다.

DISKPART> list partition

이 디스크에 표시할 파티션이 없습니다.

DISKPART> create partition primary

DiskPart에서 지정한 파티션을 만들었습니다.

DISKPART> list partition

  파티션 ###  종류              크기     오프셋
  ----------  ----------------  -------  -------
* 파티션 1    주                   14 GB  1024 KB

DISKPART> format fs=fat32 quick

  100 퍼센트 완료

DiskPart가 볼륨을 성공적으로 포맷했습니다.

DISKPART> list partition

  파티션 ###  종류              크기     오프셋
  ----------  ----------------  -------  -------
* 파티션 1    주                   14 GB  1024 KB

DISKPART> exit

DiskPart 마치는 중...

C:\WINDOWS\system32>

예전에 사용하던 친숙한 GUI 도구 "디스크 관리"는 어디로 갔나?

윈도우 10에서 이 유틸리티를 실행하는 방법은 다음과 같이 몇 가지 방법이 있다.

  1. 시작 메뉴에서 마우스 오른쪽 버튼을 클릭하여 나타나는 "디스크 관리"를 선택하여 실행한다. 혹은 "diskmgmt.msc"를 입력하여 실행한다.
  2. [윈도우 키] + X를 누르면 시작 메뉴가 나온다. 그 다음에는 1번과 같다.
  3. 작업표시줄의 검색 창에서 "하드 디스크 파티션 만들기 및 포맷"을 입력하여 실행한다.
한 가지 명령어를 찾아 들어가는 방법이 여럿 존재할 뿐이다.

우분투 스튜디오 20.04로 업그레이드를 하니 에서 화면 잠금 후 패스워드를 넣을 수가 없다!

우분투 스튜디오 18.04를 설치하여 사용하던 컴팩 프리자리오 CQ61-304TU 노트북 컴퓨터에서 계속 업그레이드를 하라는 메시지가 나오는 것을 무시할 수가 없어서 과감하게 판올림을 하였다. 18.04와 20.04를 반복해 설치하면서 어느 것이 나에게 더 맞을까 여러 차례 경험을 하였기에 특별히 불편한 점은 보이지 않았다. 그런데 화면 잠금을 해제할 수 없다는 치명적인 문제를 발견하였다. [암호를 입력하십시오] 칸에 아무리 마우스 포인터를 갖다 대고 클릭을 해도 커서가 찍히질 않는다. 암호를 넣을 수가 없는 것이다.

사무실에서 사용하는 다른 컴퓨터에 우분투 스튜디오 20.04를 '새 설치'했을 때에는 이런 일이 벌어지지 않았다. Ctrl + Alt + F3를 눌러서 다른 가상 콘솔을 켠 다음, lightdm을 재시작하였다.

$ sudo systemctl restart lightdm

그런 다음 화면 잠금을 해제하는 것으로 문제를 마무리하였다. 

디스플레이 매니저를 재시작하는 것과 Xfce session을 다시 시작하는 것은 조금 다른 문제로 알고 있는데, 어쨌든 임시방편이나마 문제를 해결했으니 그것으로 족하다. Ctl + Alt + Backspace키를 동시에 눌러서 X를 다시 시작할 수 있는 것으로 알고 있지만 요즘은 잘 안된다. 검색에 의하면 'pkill -KILL -u username'을 입력해서 로그인 스크린을 다시 띄울 수 있다고 한다. 

두 대의 컴퓨터에서 우분투 스튜디오 20.04가 돌아가고 있지만 하드웨어 환경도 다르고 해당 배포판/버전에 이르게 된 방법도 조금은 다르다. 두 컴퓨터의 행동이 조금 다르게 나타나는 것은을 그러한 차이점에서 원인을 찾아야 할까?

2021년 4월 12일 월요일

우분투의 네트워크 설정 - Netplan? 이건 또 뭐람?

Ubuntu Studio 18.04와 20.04를 설치하여 쓰면서 네트워크 설정을 하는 데에는 별 문제점이 없었다. 그저 패널에 나타난 네트워크 설정 아이콘을 클릭하여 나오는 화면을 채우면 되었고, 그렇게 하면 /etc/network/interfaces 파일에 IP 주소와 넷마스크, 게이트웨이 및 DNS 등의 설정 사항이 기록된다는 사실 정도를 기억하면 되었다.

Ubuntu '순정' 18.04가 설치된 Dell Precision 7920 Tower Workstation의 모니터 연결이 너무 어려워서 전문가를 초빙하여 어렵사리 화면이 나오게 하고 네트워크 설정도 마쳤다. 원래는 2019년에 납품이 되어 잘 쓰던 것이지만 사용자가 퇴직을 하면서 모니터 연결을 위한 젠더 등 액세서리를 제대로 넘겨받지를 못했던 것이다. 컴퓨터 본체에는 미니 디스플레이이포트가 있으나 모니터는 HDMI 단자뿐이고 그동안 사용했던 것으로 여겨지는 젠더는 보이질 않았다. 어쨌든 전문가의 손에 의해 화면을 볼 수 있게 되었으니 이제 내가 직접 점검을 해 볼 시간이라 생각하고 재부팅을 한 다음 다시 웹브라우저를 실행하니 차단 상태이다. 정보보안팀에 전화를 하여 IP 차단 해제를 부탁하고 잠시 기다린 뒤 다시 아무리 노력을 해도 바깥 세상으로 연결이 되지 않는 것이었다.

뭔가 좀 이상하다.

'ip a' 명령을 입력하면 /etc/network/interfaces 파일에 기록해 넣었던 주소와 다른 값이 나온다.  ifup이나 ifdown을 실행해도 낯선 에러 메시지가 나오는 것이다. 왜 네트워크 어댑터가 설정 파일의 내용과 다른 IP 주소를 갖는 것일까? 검색에 검색을 거듭한 결과 우분투 18.04부터는 Netplan이라는 것이 ifupdown을 대체하여 쓰인다는 것을 알았다. 아니, 우분투 '스튜디오' 20.04에서는 여전히 /etc/network/interfaces을 사용하면서, 왜 '순정' 우분투 17.10 Server부터는 /etc/netplan/01-network-manager-all.yaml 파일을 사용하는 Netplan으로 바뀌었단 말인가? 이렇게 일관성이 없다니... 네트워크 설정 사항을 활성화하는 명령어도 'netplan apply'라는 매우 생소한 것으로 바뀌어 있다.

국문으로 Netplan을 설명한 글이 있어서 여기에 소개한다. 

Ubuntu 17.10에서부터 기본으로 사용되는 Netplan 

아마 처음부터 우분투 18.04를 설치하였다면 네트워크 설정을 묻는 메뉴를 만났었을 것이다. 이때 Netplan을 통해서 configuration이 되고, 시스템이 시작과 동시에 서비스가 이루어진다는 것을 느끼지 못했을 것 같다. 이미 사용 중이던 컴퓨터를 건드리려니 이렇게 예상치 못한 일이 벌어진다.

GNOME 패널의 오른쪽 위를 클릭하면 나타나는 톱니바퀴를 통해서 네트워크 설정에 접근할 수 있다. 그러나 이 프로그램은 /etc/network/interfaces 파일을 여전히 사용하는 듯, Netplan을 이용하여 인터넷 접속이 잘 되고 있음에도 불구하고 네트워크 어댑터가 설정되지 않았다는 메시지를 뿌린다.

기억을 더듬어 보자. 주 업무용 서버는 CentOS 7 기반이고, 취미 및 테스트 용도로 사용하는 컴퓨터(노트북 포함)는 전부 우분투 스튜디오가 설치된 상태이다. 데스크탑 환경은 전부 Xfce이다. 마지막으로 GNOME Desktop을 쓴 것이 언제였더라? 아마도 Oralcle VirtualBox에서 '순정' 우분투를 설치하여 사용했기에 네트워크 설정에 별로 신경을 쓸 필요가 없었던 것으로 여겨진다. 그래서 이렇게 익숙하지가 않았었구나!

잠깐, 내가 우분투의 GNOME과 Unity를 구별이나 할 줄 알던가? 갑자기 자신이 없어진다. 우분투 17.10을 기준으로 두 데스크탑을 비교한 친절한 동영상이 있어서 소개해 본다. 왼쪽 위에 파이어폭스 아이콘만 있으면 GNOME, 그 위에 동그라미가 하나 더 있으면 Unity이다. 하지만 이런 힌트에 의존하지 말고 데스크탑의 동작을 통해서 구분할 수 있어야 진정한 고수 아닐까... 


같은 종류의 우분투 식구라고 생각했었는데 우분투와 우분투 스튜디오가 이렇게 다르다니 놀랍고 허탈하기만 하다. 이런 상황을 매번 시행착오를 통해서 익혀야 하니 참으로 쉬운 일이라는 것은 없다.

2021년 4월 16일 업데이트

오늘 다른 랙마운트 서버(별칭 "microbe")에 우분투 20.04 LTS를 설치하는 과정에서 첫 부팅 때 네트워크 설정을 묻는 화면을 접했다. 그러면 그렇지! 이런 화면도 보여주지 않고서 Netplan 설정용 yaml 파일을 텍스트 편집기로 수정한다는 것은 말이 되지 않는다. 아마도 이 글의 첫부분에서 언급한 Dell Precision 워크스테이션에 누군가 우분투를 처음 설치할 때 뭔가 실수가 있었거나, 혹은 그 이후에 잘못 초기화를 했거나 둘 중의 하나일 것이다. 
실은 오늘 우분투를 네 번 정도 다시 깔았던 것 같다. RAID 파티션을 /dev/sda로 잡느냐, 혹은 /dev/sdb로 잡느냐 오락가락을 하면서 어떤 상황에서는 부트 로더가 설치되지 않았기 때문이다. RAID 구성을 내 손으로 직접 한 일이 없으니 늘 두려움이 앞선다. 언젠가는 반드시 해 봐야 할 과제이다. 또한 GRUB을 자유자재로 다룰 정도로 익숙해진다면 얼마나 좋을까? 지금 아는 정도의 지식이란 루트 패스워드를 잊었을 경우 부팅할 때 Shift키를 누르고 있다가 GRUB 화면이 나오면 'e(Edit)'를 눌러서 'linux      /boot/vmlinuz-.... ro'라는 라인을 찾아 들어가 'ro'를 'rw single init=/bin/bash'로 치환한 뒤 부팅을 하면 된다는 것이다. 그 다음에는 루트 패스워드를 원하는 것으로 고치면 된다.

Supermicro X9DRI-F 보드를 쓰는 microbe도 꽤 낡은(?) 장비이다. CPU는 Xeon E5-2640 2개이고 메모리는 64GB가 꽃혀 있다. 물리적 코어는 12개, 동시 가능한 쓰레드는 24개이다. 2013년 11월에 구입했는데 활용 빈도는 그렇게 높지 않았다(현재 내 주력 장비는 2015년에 구입한 것). RAID 콘트롤러가 달려 있으니 스토리지 서버로 쓰면 적당할 것 같다. 

이보다 더 오래된 서버도 있다. 2009년에 구입했던가? 메모리를 한 곳으로 몰아서 쓰면 어떨까 싶기도 하고... 그러려면 또 서버 랙을 열고 먼지와 씨름을 해야 한다. 여름이 오기 전에 생각해 볼 일이다.

2021년 4월 11일 일요일

처음 가 본 단양(2021.4.10.)

충북 단양과 제천은 대전에서 직선거리로 그렇게 먼 곳은 아니지만 전 국토를 격자 모양으로 관통하는 고속도로망이 최근과 같이 뚫리기 전까지는 쉽게 갈 수 있는 곳이 아니었다. 도로 여건도 이미 충분히 좋아진 지금, 경주는 이따금 가면서도 충북의 끝자락을 가려는 시도를 왜 지금까지 못했었을까.


단양군은 충청북도 동북쪽 끝에 위치하였다.
충남과 충북은 거의 같은 위도에서 동서로 위치해 있는데 왜 충청서도·충청동도가 아닐까? 인터넷을 찾아보면 이런 의문은 나만 가진 것이 아니었다. 과거에는 대부분의 도를 좌도와 우도로 나누었다고 한다. 그렇다면 충청남도는 충청좌도였을까? 그렇지 않다. 현재처럼 북쪽을 기준으로 지도를 배치한 것이 아니라, 임금님이 보는 관점에서 좌우를 결정했다고 한다. 따라서 현재의 충청남도는 과거에는 충청우도였던 것이다. 따라서 경상좌수영은 부산에, 경상우수영은 부산에 위치하였다. 한 번 머릿속에 박힌 고정관념(위를 기준으로 시계방향으로 90도씩 돌아가며 북-동-남-서)은 이렇게 깨기가 어렵다.

북대전 나들목을 나와서 호남고속도로 - (회덕분기점) - 경부고속도로 - (남이분기점) - 중부고속도로를 따라 북으로 올라가다가 대소분기점에서 평택제천고속도로에 접어들었다. 중간에 들른 휴게소의 이름은 천등산 휴게소이다. 옛 가요 '울고 넘는 박달재'의 가사는 '천등산 박달재를 울고 넘는 우리님아~' 아니던가? 박달재가 바로 이곳과 관련이 있는 것 같다. 나중에 다음 지도에서 확인해 보니 천등산 정상과 천등산 휴게소(둘 다 충주시 산척면)의 직선거리는 6.9 km 정도로 꽤 떨어져 있고, 박달재(제천시)는 천등산을 가운데 두고 정 반대편에 있다. 그러니 이곳에서 박달재를 연상하는 테마공원을 만들기는 무리였을 것이다. 대신 이곳에는 고구려 테마 공원이 조성되어 있어서 잠시 흥미롭게 둘러 보았다. 예전에 중원 고구려비라고도 불렸던 충주 고구려비를 널리 알리기 위한 것이다. 물론 이 휴게소에는 복제한 고구려비가 있을 뿐이다.

첫 목적지는 도담삼봉. '삼봉'이 정도전의 호라는 것을 여태 몰랐느냐는 아내의 핀잔에 '국사 교과서에 나오는 것 이상은 잘 모른다'고 얼버무려야만 했다. 난 사극에서 그렇게 많이 다루어진 역사 뒷이야기를 거의 알지 못한다. 그다지 자랑스러운 일은 아니지만 말이다.

참 묘하게 생긴 자연의 걸작이다. 가장 높은 봉을 기준으로 물 위로 드러난 부분의 약 1/5까지 물에 잠겼던 흔적이 있다. 과거에는 물이 여기까지 차 올랐던 것일까? 아니면 삼봉이 천천히 솟아 올랐나? 신비롭기만 하다. 지질학자는 이에 대해서 답을 할 수 있어야 한다. 정선에 있던 삼봉이 큰 홍수에 여기까지 떠내려 왔다는 전설이 있지만 이것이 사실일 리는 없다. 그것 때문에 정선에서 단양에 세금을 징수하고, 소년 정도전이 재치 있게 이를 받아쳐서 다시는 세금을 받지 못하게 했다는 이야기가 전해져 온다.



석문으로 오르는 정자에서.

계단을 오르면 '석문'이라는 곳을 갈 수 있다기에 가벼운 마음으로 발길을 향했다. 길지는 않지만 제법 가팔랐다. 여기에도 기묘한 자연의 작품이 있었다. 만약 유람선을 타고 강 쪽에서 접근했다면 어떤 모습을 보였을까?



석문을 다녀 오니 적잖이 허기가 져서 관광단지에 조성된 식당가에서 메밀국수로 점심을 먹고 두 번째 목적지로 향했다. 청풍호를 가 보려다가 기왕이면 인공으로 조성된 호수보다는 사찰이 낫겠다 싶어서 구인사를 가 보기로 했다. 단양IC를 통해 진입한 뒤 도로 표지판에서 '구인사'라 적힌 것을 보고 이름난 절이라고 즉흥적으로 생각을 한 때문이었다. 이에 대해서는 아무런 사전 정보를 갖고 있지 않았었다. 그런데 결과적으로는 썩 잘 한 선택이라고는 할 수 없었다. 왜냐하면 천태종의 총본산인 구인사는 규모로 압도하는 절이지 역사가 오래거나 고풍스런 곳은 아니었기 때문이다. 다만 구인사까지 가는 길에서 만난 남한강변의 풍경이 너무나 아름다웠다. 개발의 흔적이 많이 보이는 북한강변보다는 더욱 한적하고 여유가 있었다.

천태종과 구인사에 대해서는 평소에 아는 바가 없었다. 인터넷에서 산골짜기에 조성된 엄청난 규모의 사찰 사진을 본 적이 있었는데, 그것이 구인사임은 바로 여행날 알게 되었을 정도이니 말이다. 동서울 터미널에서 구인사 입구까지 오는 버스가 있을 정도이니 이곳을 찾는 신도가 얼마나 많은지 짐작할 수 있다.



얼마나 가파르고 높은지 1/4도 오르지 못하고 내려왔다. 운전하면서 졸 수는 없으니 체력을 아껴야 했다. 이 안내도 바로 곁에는 구인사 전용 버스 터미널이 있다.



천태종의 역사가 오래되었다고 하나 그 명맥이 끊어졌던 것을 원각대조사 상월 스님이 1960년대에 개창하였다고 한다. 내가 그 교리에 대해서는 알 도리가 없고, 사실상 새로 만들어진 것이나 다름이 없다고 생각한다. 대한민국의 모든 천태종 신도는 구인사 소속으로 되어 있다고 하니 면적이나 규모 모든 면에서 국내의 모든 종파를 통틀어서 가장 규모가 크다고 해야 할 것이다. 짧은 시간 안에 이렇게 성장을 했다면 사람들의 마음을 끄는 그 무엇인가가 있었을 것이다. 

믿음이란 것이 신도들의 규모를 키워야 더욱 높은 경지로 나아가는 성질의 것은 아닐 것이다. 입구 주차장 앞에 마련된 거대한 박물관을 둘러보면서 사찰의 성장 과정을 너무 강조하고, 일부 소장품에서 다소 자연스럽지 못하다는 느낌을 받은 것은 나 혼자만은 아닐 것이다. 주차장에서 요금을 받고 체온을 체크하는 직원이 퉁명스러웠다는 것도 좋은 기억은 아니다.

기회가 되면 진안에 있다는 광명사를 한 번 찾고 싶다. 주지 송운 스님은 중학교 때 친구였다.

구인사를 내려와서 입구에 있는 농산품 판매점을 들러 철 지난 더덕을 한 봉지 샀다. 조금이라도 양이 많은 것을 사려고 껍질을 까지 않은 것을 달라고 했더니 비닐봉투에 담아서 쌓아 놓은 것 중에 굳이 아래에 있는 것을 꺼내어 팔려고 하는 것이 아닌가? 그것도 싹이 많이 나서 상품성이 떨어지는 것을.. 흠이 있는 것을 군소리 하지 않는 손님에게 먼저 팔아 버리려는 가게 주인의 마음을 이해하지 못하는 바는 아니다 그다지 유쾌하지는 않았다.

온달은 분명히 고구려의 장수인데 단양에 온달 관광지가 조성되어 있다니? 온달이 신라에 의해 빼앗긴 남한강 유역을 되찾기 위해 여기까지 와서 싸웠다고 한다. 전해져 내려오는 이야기와 드라마 세트장을 적당히 버무린 곳이다. 온달 산성이라 불리는 성도 있고 여기에서 온달이 전사했다는 이야기도 있으나, 삼국사기의 기록에 나오는 아단성(阿旦城)이 바로 이곳에 축조된 성과 동일한 것인지는 알 수 없다. 우리 부부는 둘 다 많이 지쳐 있어서 온달관광지와 산성은 들르지 못했다.

고속도로로 나가기 위해 다시 단양군내를 지나면서 성신양회 사업장을 지나게 되었다. 석회암으로 이루어진 산의 봉우리가 보이질 않고 마치 칼로 자른 듯 평평해 보인다. 만약 위에서 내려다본다면 어떤 모양이었을까? 궁금하면 카카오맵에서 스카이뷰를 찾아보면 된다. 

도로에서 올려다보면서 상상했던 모습과는 달리 산을 계단형으로 깎아 나가고 있다. 어쩌면 나선형일지도 모른다.

거대한 공장 설비는 마침 스팀펑크류의 영화에 나오는 모습 같았다. 운전 중이라 사진을 남기지 못한 것이 아쉬웠다. '석회석신소재연구소'는 생명공학을 전공하는 사람에게는 무척 신기한 곳으로 인상이 남는다.

돌아오는 길에는 방송인 이영자에 의해 TV에 소개되어 유명한 금왕 휴게소의 찹쌀 꽈배기를 먹었다. 돌아오고 나니 좀 더 큰 포장으로 구입해서 먹지 못한 것이 너무나 아쉬웠다. 

봄은 빨리 지나고, 인생은 짧다. 건강이 허락하고 마음에 여유가 있을 때 많이 돌아다니자는 것이 아내와의 약속이다.