[우분투의 사운드와 MIDI] 상당히 쓸만한 CLI용 녹음 유틸리티, parec

PulseAudio는 마치 개미지옥처럼 우분투 사용자, 특히 명령행 인터페이스(CLI) 애호가를 빠져들게 하는 재미가 있다. 그 끝은 '파멸'이 아닌 것이 다행이지만 말이다. 새로 설치한 위키 사이트에 음악 작업 관련 문서를 옮기고 고쳐쓰면서 PulseAudio의 다양한 기능을 탐색하는 즐거움에 빠져들고 있다. CLI의 명령어를 잘만 이용하면 PulseAudio Volume Control을 열지 않고도 웬만한 작업을 다 할 수 있을 것만 같다.

PulseAudio 설정 및 활용

특히 parec 명령어의 단순명료함에 감탄하고 있다. parec, parecord, pacat, paplay 등 용도에 맞게 다양한 이름으로 실행을 하지만 전부 pacat을 향하는 심볼릭 링크이다. 이 글에서는 녹음이라는 용도에 관하여 논하고 있으므로 parec이라고 부르기로 했다. 

명령행에서 'parec -d'를 입력하고 탭 키를 몇 번 'alsa_'로 시작하는 디바이스 이름이 나온다. 다음은 USB 오디오 인터페이스를 하나도 꽂지 않은 상태에서의 실행 사례이다.

$ parec -d # 이 상태에서 탭을 쳐 보라. 
alsa_input.pci-0000_00_1b.0.analog-stereo
alsa_output.pci-0000_00_1b.0.analog-stereo
alsa_output.pci-0000_00_1b.0.analog-stereo.monitor

첫 번째는 내장 마이크로폰이고, 세 번째는 내장 스피커이다. 마이크로폰 녹음을 하려면 첫 번째 것을, 응용 프로그램의 재생음을 녹음하려면 세 번째 것을 고르면 된다. 나는 첫 번째 것을 골랐다. parec은 표준 출력을 사용하므로, 이를 인코딩하여 파일로 저장하면 된다. 

$ parec -d alsa_input.pci-0000_00_1b.0.analog-stereo | twolame -r - out.mp3

MP3로 엔코딩하려면 lame 또는 twolame을, OGG로 인코딩하려면 oggenc를 쓰면 된다. 샘플링 레이트, 비트 레이트 등을 조절하는 파라미터는 따로 익혀야 한다. twolame의 경우 아무것도 지정하지 않으면 44.1 kHz, 16 bit, stereo가 된다. 인코딩 프로그램의 입력 및 출력 파라미터는 분명히 다른데 나는 아직 이를 잘 구별하지 못한다.

인코딩과 관련하여 건드릴 수 있는 파라미터까지는 도저히 이해하여 건드릴 수준이 아니니 그대로 두기로 하자, 다만 PCM 샘플 포맷에서 s16ne(signed 16-bit native endian)가 무엇인지, 헤더가 없는 raw format은 무엇인지 등을 알아야 한다. 왜 parec의 출력을 인코더 프로그램에서 --raw로 받는지 정도는 이해를 해야 하지 않을까?

한 쪽에서는 오디오 파일의 포맷에 대해 공부를 하고, 다른 한 쪽에서는 수리 중인 악기(기타)의 마감칠에 관한 공부를 하고 있다. 음악은 어디로 갔지? 기술은 예술을 하는데 필요한 것이지만, 거기에 너무 빠져들면 본질을 잃게 될 수도 있다.

wiki.GenoGlobe.com 웹사이트 정리 - 네임스페이스를 활용한 체계적 글 작성

GenoGlobe.kr 위키 사이트에 있던 음악 관련 개인적인 글들을 wiki.GenoGlobe.com으로 이전하였다. 위키 사이트의 체계를 새로 구성하는 것과 맞물려 있어서 단순한 복사로 끝나지는 않았다. 몇몇 오류도 바로잡았고, 필요없는 정보는 제거하였다. 가장 큰 변화는 네임스페이스를 적극적으로 활용하게 된 것이다. 이전에는 접근 제어 목록(Access Control List, ACL)의 관리를 통해서 외부인의 접근을 차단할 사적인 페이지만을 특정 네임스페이스 밑에 두는 정도로 관리를 했었다. 사적인 페이지라고 해서 야릇한(?) 그림이나 글이 저장된 것은 아니다. 시스템 관리 및 설정과 관련해서 기억해야 할 정보가 있을 뿐이다.

도쿠위키를 통해서 네임스페이스라는 용어를 처음 접했기 때문에 이것은 위키 시스템에서만 쓰는 용어로 생각했었다(링크). 하지만 이것은 잘못된 기억이었다. Mastering Perl for Bioinformatics라는 책의 앞부분에서 package 선언과 함께 분명히 네임스페이스라는 용어를 보았던 것을 지금 막 기억해 냈다. https://flylib.com/books/en/3.329.1.17/1/에서 책 내용을 조금 인용해 보자.

1.3 Namespaces

A namespace is implemented as a table containing the names of the variables and subroutines in a program.

(중략)

The package declaration described in the next section is one way to assign separate namespaces to different parts of your code.

www.GenoGlobe.com의 글 배치 상황은 다음 그림과 같다.

왼편 사이드바 Topic 하위에 보이는 항목들은 전부 루트 네임스페이스에 있는 개별적인 위키 페이지에다. 빨간 네모로 표시한 Music on Linux는 말 그대로 [[Music on Linux]]로 표시된다. 대문자는 전부 소문자로 환원되고, 공백은 '_'로 바뀐다는 것은 상식이다. 이제 Music on Linux 위키 페이지를 작성한다고 가정하자. 이미지를 삽입한다고 해도 이는 전부 루트 네임스페이스에 존재한다. 글을 쓰다가 다소 분량이 길어질 것 같은 섹션을 하위 카테고리에 넣는 것이 좋겠다는 생각이 들었다. 그러면 비로소 문서 내에 [[music_on_linux:audacity를_이용한_녹음|Audacity를 이용한 녹음]]을 삽입하면 된다. 이제야 비로소 Music on Linux라는 네임스페이스가 생긴 것이다. Music on Linux는 루트 네임스페이스에 존재하는 독립 위키 문서이기도 하고, 같은 이름을 갖는 네임스페이스가 별도로 존재하는 것이다.

처음에는 Music on Linux라는 위키 문서 자체도 네임스페이스 하위에 존재해야 한다고 생각했었다. 그래서 사이드바의 항목을 [[Music on Linux:idx]]로 선언하고 글 작성을 시작했었다. 기술적으로는 아무런 문제가 없다. 그러나 위키 사이트 상단 부분의 이전 방문 페이지 목록에는 토픽의 구체적인 항목과 무관하게 전부 'Trace: • idx'로 표시되는 것이 아닌가? 도쿠위키로서는 당연한 행동이지만, 별로 효율적이지는 못하다. 그래서 도쿠위키의 원본 웹사이트를 관찰하면서 어떻게 구조를 짜는 것이 좋은지 고민하다가 지금과 같은 방식을 쓰기로 한 것이다. 정답인지는 모르겠으나 최소한 'local optimum'은 된다고 생각한다.

다음으로 생각해 볼 것은 위키 페이지 중간의 헤드라인을 링크로 이용하는 문제이다. '='의 수가 많을수록 상위 헤드라인다. 이것은 얄궂게도 '#'를 사용하는 마크다운 문법과는 정반대이다. 

출처: https://www.dokuwiki.org/wiki:syntax

헤드라인은 https://mydomain.com/thisPage#thisHeadeline과 같은 양식으로서 URL의 일부로 쓰일 수 있다. 이것은 참 좋은 기능인데, 나중에 헤드라인을 고쳐쓰게 되면 이 URL은 더 이상 유효하지 않게 된다. 페이지 타이틀처럼 실제 URL(혹은 위키의 파일 시스템 내부)에서 쓰이는 제목과 겉으로 드러나는 정보를 다르게 표현할 수는 없기 때문이다. 즉, [[thisPageTitle|실제로는 이렇게 보여주세요]]를 헤드라인에 대해서는 적용하지 못한다. 최소한 내가 알기로는 그렇다. 따라서 나중에 헤드라인을 수정하게 되면 이를 인용하는 다른 웹문서에서 접근 문제가 생길 수 있음을 알아야 한다. 어쩌면 헤드라인(또는 웹문서 내의 서브섹션)을 외부에서 링크하게 만드는 것은 바람직하지 않은 버릇일 수도 있다.

헤드라인에 대한 링크는 그 문서 자체에서 TOC(목차)를 통해 빠른 접근을 하는 경우에만 활용을 하는 것이 좋은 습관일 것이다. 외부 방문자가 내 위키문서의 헤드라인에 대한 URL을 북마크하였거나 자신의 웹문서에 넣었다면 나도 어쩔 도리는 없다. 내 위키 사이트 내에서는 되도록 헤드라인 레벨의 링크는 하지 말고, 그 섹션이 포함된 위키 페이지 자체를 내부적으로 링크하는 것이 좋을 것 같다. 

나이 들어서 프로그래밍을 익히고 개발자로 취업한 사람들의 이야기

내가 보유한 웹사이트를 정비하느라 며칠 동안 .htaccess를 가지고 씨름을 하다가 기왕이면 처음부터 제대로 공부를 하는게 낫겠다는 생각을 하게 되었다. 리눅스를 다룬지는 정말 오래 되었고, 업무를 위해 미생물 유래 시퀀싱 데이터(고전적인 *.ab1 파일에서 NGS까지)를 늘상 매만지고 있다. 프로그래밍 스킬은 Perl/shell 스크립트를 어느 정도는 하는 편이고 파이썬 애플리케이션은 설치하여 활용하는 정도. 아, R도 어느 정도는 쓴다.

FreeSSL.org에서 무료로 발급받은 90일짜리 인증서를 서브도메인(wiki.GenoGlobe.com)에 설치하다가 CA, 인증서 체인, 프라이빗키 등 2년 전 보안 솔루션에 의하여 보호중인(?) 사내 전산망에서 프로그램 설치가 잘 되지 않아서 고생하면서 익혔던 용어들이 다시 생각이 났다. 당시에 작성했던 글을 다시 찾아 읽으며 글 속에 링크를 걸어 놓았던 생활코딩의 강좌 동영상을 몇 개 다시 보기도 하였다.

• SSL과 관련한 conda 설치 에러 - anaconda 3 [해결] 이것은 내가 쓴 블로그의 글.
• [생활코딩] HTTPS와 SSL 인증서

웹(web)은 세상과 소통하는 창구로서 중요한 역할을 한다. 앞서 이야기한 주제는 웹을 안전하게 쓰기 위하여 갖추어야 할 장치이다. 이를 통해서 '창구'는 정보를 안전하게 주고받는 최소한의 기능을 마련하게 된다. 그러나 아무리 맛있는 음식이라 해도 예쁜 그릇에 담아서 밥상에 잘 올려놔야 하지 않겠는가? 디자인적 요소를 무시해서는 안된다. 또한 좋은 디자인은 보기에만 좋은 것이 아니라 기능을 위한 것이기도 하다. 특히 딸아이가 조형 대학('College of Design')에 입학하면서 디자인에 대한 나름대로의 철학을 갖게 된 것도 나에게는 중요한 계기이다.

현재 내 웹사이트는 도쿠위키를 기반으로 돌아간다. 이보다 더욱 화려하고 인기있는 CMS(content management system)도 있을 것이다. 이를 더욱 잘 다루려면 웹프로그래밍의 기본을 익혀야 한다. HTML, CSS, 자바스크립트 등 필수 3종 세트가 있고, jQuery라는 것도 알아야 한다. 도쿠위키의 속내를 이해하고 나만의 템플릿을 만들고자 한다면, PHP도 알아야 된다.

자, 이런 것을 지금부터 공부하기에 나의 뇌는 너무 굳어진 것은 아닐까? 나는 그저 흥미 차원에서 시도를 하려는 것인데, 나와 비슷한 나이에 프로그래밍을 처음부터 배워서 취업까지 성공한 사례가 있을까? 궁금해서 웹을 뒤적거리다가 다음과 같은 글을 발견하였다.

[Kris Hwang] 30대, 40대, 그리고 50대에 개발자가 된 300명의 이야기(번역) - 원작자인 Quincy Larson은 무료 코딩 교육을 위한 단체인 freeCodeCamp의 창립자라고 한다.

인생에서 무엇을 하기에 너무 늦은 나이는 없다. 가능성이 가장 높은 순간은 바로 지금! MOOC 강좌를 하나 등록해 보았다.

[edwith] 문제해결을 통한 웹프로그래밍 입문 - 전체 공개강좌 목록은 여기에 있다.

PulseAudio 공부도 해야 하고, 일렉기타 연습도 필요하고... 할 것이 너무 많다!

GenoGlobe.kr 하위의 위치 자료를 GenoGlobe.com으로 옮기고 .htaccess REDIRECT를 써서 이전 주소로도 접속이 되게 만들기

GenoGlobe.kr/kribb에서 돌아가던 위키 사이트를 GenoGlobe.com/kribb으로 옮겼다. 이를 보통 '마이그레이션(migration)'이라 부른다. '.kr'이 '.com'로 바뀌는 것을 제외하면 웹문서 주소(URL)의 모든 부분은 똑같다. 따라서 GenoGlobe.kr의 .htaccess 파일에서 리다이렉트를 선언하면 이전 주소를 웹브라우저 주소창에 입력해도 알아서 새 주로소 변환되어 찾아가게 된다.

.htaccess 파일의 편집 작업을 호스팅어의 파일매니저에서 시도하다가 접속이 너무 자주 끊겨서 ssh로 접속하여 vi 편집기로 직접 수정하였다. 별다른 것은 없고 다음의 한 줄이 내가 원하는 리다이렉트 기능을 충실하게 수행하게 만든다.

Redirect 301 /kribb/ https://genoglobe.com/kribb/

도쿠위키 문서라서 /kribb 하위에 다른 문자열이 계속 붙는 복잡한 구조를 하고 있지만 리다이렉션에 의해서 충실하게 연결이 됨을 확인하였다.

해법은 이렇게 단순하지만 몇 시간에 걸친 시행착오를 겪었다. 왜냐하면 GenoGlobe.kr의 DocumentRoot에 또 다른 위키가 설치된 상태였기 때문이다. 도쿠위키를 기본 설명대로 설치하면 mydomain.com/dokuwiki/doku.php를 입력하여 연결하게 된다. 중간의 dokuwiki는 DocumentRoot 하위에 실제로 존재하는 서브디렉토리이다. 이번에 마이그레이션한 위키의 경우 'kribb'이 이에 해당한다. 이와는 별도로 개인적인 용도의 글을 쓰기 위한 또 다른 위키를 GenoGlobe.kr의 DocumentRoot에 서브디렉토리 없이 설치를 한 뒤, Nice URL을 쓰기 위해서 .htaccess에 다소 복잡한 코드를 심어 놓았었다.

개인 용도의 위키는 글이 많이 않아서 일부 페이지만 수작업으로 옮기고 지워도 된다. 따라서 .htaccess 파일을 위에서 소개한 Redirect 문 등 필요한 것만 남기고는 다 지웠다. 그리고 doku.php로 자동으로 연결되게 만드는 index.php도 무력화하였다. 만약 개인 용도의 위키를 접속할 일이 있으면 GenoGlobe.kr/doku.php를 주소창에 직접 입력하면 된다. 예전에는 GenoGlobe.kr이라고만 치면 개인 위키로 연결되었었다.

이제부터는 GenoGlobe.kr에는 별도의 웹문서를 두지 않되, 만약 외부 사용자가 하위폴더 없이 이 도메인명만 입력하면 GenoGlobe.com으로 5초 뒤에 연결되도록 만들었다. 다음과 같은 짤막한 index.html을 하나 만드는 것으로 원하는 바를 이룰 수 있다. CSS(cascading style sheet)를 조금이라도 알면 이렇게 보기 흉한 재전송 알림 html 문서를 만들지는 않았을 것이다.

<html>
<head>
<meta http-equiv="refresh" content="5; URL=https://genoglobe.com">
</head>
<body>
You will be automatically redirected to <a href>https://genoglobe.com</a></a> within 5 seconds...
</body>
</html>

도메인 관리 기관에서 서비스하는 '도메인 포워딩'으로는 아마 이런 상세한 수준의 리다이렉트를 하기 어려울 것이다. GenoGlobe.kr에서 제공할 웹문서 자료 등의 서비스가 이제는 남아있지 않게 되었으니 호스팅어보다 더 가격이 싼 웹호스팅업체로 이전을 하는 것이 나을 것이다. 호스팅어에서는 비용이 낮은 서비스로 다운그레이드를 하는 것이 불가능하기 때문이다. 금주 월요일에 호스팅어에서 GenoGlobe.kr 웹호스팅 비용 1년치를 결제하였으나 아마 30일 이내에 환불이 가능할 것으로 보인다. Lifetime SSL certificate는 좀 아깝지만 어쩔 도리가 없다.

000webhost라는 이름의 호스팅어 자회사(?)에서는 정말 싼 가격의 웹 호스팅 서비스를 실시한다고 하니 여기를 알아보아야 되겠다.

이틀 정도를 거친 삽질의 연속이었다. 언제나 초보 수준에 머무는 웹 관리자는 모든 것이 어렵다. HTML, CSS, 자바스크립트 및 JQuery 정도는 어느 수준으로 알아야 할 것이다. 아직 이런 준비가 덜 된 초보자를 위해서 웹 호스팅 서비스라는 산업이 있다는 것이 얼마나 다행인지 모르겠다. 

3월 19일 업데이트 - Redirect를 현명하게 쓰기

만약 .htaccess 파일을 다음과 같이 작성한다면, 'GenoGlobe.kr/블라블라'는 자동적으로 'GenoGlobe.com/블라블라'로 리다이렉트된다. '블라블라'는 빈 문자열일 수도 있고, 몇개의 서브 폴더를 거치는 복잡한 하위 주소일 수도 있다.

Redirect 301 / https://genoglobe.com

그러나 나는 왜 GenoGlobe.kr을 하위 주소 없이 입력한 경우에만 GenoGlobe.com으로 가게 만드는 index.html 파일을 만들어야만 했는가? 그것은 GenoGlobe.kr을 시험적 용도로 계속 사용할 수 있게 만들기 위함이다. 이 업데이트에서 소개한 한 줄의 명령어는 GenoGlobe.kr로 들어오는 모든 접속자를 예외없이 GenoGlobe.com으로 보내버리는 단점이 있다. GenoGlobe.kr 도메인의 웹사이트를 호스팅하는 서버에서 PHP 공부를 하려고 해도 시작도 하기 전에 전부 GenoGlobe.com으로 리다이렉트가 될 것이기 때문이다.

RewriteCond 명령을 잘 이용하여 요청된 URL을 잘 판별한 다음 다른 사이트로 보낼 것은 보내고 그렇지 않은 것은 원래 요청된 곳으로 그대로 가게 만드는 현명한 .htaccess 파일을 만드는 것이 다음의 목표이다.

서브도메인에 도쿠위키(DokuWiki)와 90일간 유효한 FreeSSL.org의 무료 SSL 인증서를 설치하다

처음부터 철저히 계획을 세워서 도메인(genoglobe.com, genoglobe.kr)과 웹사이트를 운영하는 것이 아니라서 마치 물 새는 그릇을 땜질하듯 조금씩 수정을 가하면서 지금까지 오게 되었다. 생각보다 비용도 많이 드는 편이고 왠지 체계도 없어 보여서 이번 기회에 대대적인 개편을 감행하기로 하였다. 도메인 등록을 대행하는 업체에 따라서 연간 유지비용에도 꽤 큰 차이가 난다. 

.com과 .kr 도메인을 같이 유지하는 것은 어쩔 도리가 없다. 만약에 어느 하나만 선택한다면 당연히 .kr을 고를 것이다. 그러나 지금까지 blog.genoglobe.com에 가장 많은 저작물을 쌓아 왔으니 쉽게 바꾸지를 못한다. genoglobe.kr 도메인 하위에 있는 위키 사이트는 그렇게 활발하게 이용을 하지 않았고 생명정보학 작업에 관련한 글들은 이미 낡은(?) 것이 되고 말았다. 이는 전부 genoglobe.com으로 백업해 놓은 뒤, 과거에 퍼진 글 때문에 genoglobe.kr로 유입되는 방문자가 있다면 genoglobe.com으로 찾아오로록 리다이렉트를 할 생각이다.

현재는 hostinger에서 두 도메인의 웹사이트를 각기 다른 '플랜'으로 호스팅하고 있다. SSL 인증서도 전부 받아 놓은 상태이다. Hostinger가 제공하는 SSL 인증서는 만 몇천원만 내면 평생 쓸 수 있어서 매우 저렴하지만, 서브도메인까지는 커버하지 않음을 명시하고 있다. 안내문에는 잘 나타나지 않으나 로그인하여 기존에 올라온 문의사항을 찾아보면 이러한 내용이 분명히 있었다.

블로그의 웹주소가 blog.genoglobe.com이므로, 위키사이트는 wiki.genoglobe.com의 형태로 접속할 수 있도록 만드는 것이 대단히 자연스럽고 일관성도 있다. 그런데 도쿠위치는 보통 genoglobe.com/dokuwiki/doku.php?id=start와 같은 형식으로 접근해야 하는 것이 문제다. .htaccess 파일을 수정하여 이른바 Nice URL(링크 내 참조)을 사용하도록 만들면 genoglobe.com/dokuwiki/start 형식으로 단순하게 만들 수 있고, .htaccess 파일을 더욱 건드려서 RewriteBase를 고치면 genoglobe.com/start까지도 가능한 것으로 알고 있다. 하지만 wiki.genoglobe.com을 URL로 하여 접근하게 하려면 서브도메인을 설치해야 한다. 즉, document root에 wiki(다른 이름도 가능)이라는 서브디렉토리를 만들어서 도쿠위키를 설치한 뒤, wiki.genoglobe.com이라는 서브도메인을 생성하는 것이다. 이것은 웹호스팅 업체에서 제공해 주는 기능이다.

그래도 해결이 되지 않는 문제가 있다. genoglobe.com에서 받은 lifetime SSL certificate는 서브도메인에는 적용이 되지 않는다! 그래서 FreeSSL.org에서 무료(라고 주장하는) 인증서를 발급받아 설치하였다. 세상에 공짜가 어디 있는가? 90일마다 갱신을 해 줘야 한다. 일단은 이것으로 대충 연명해 보고자 한다. 투명 이미지를 써서 파비콘과 로고도 만들어 넣고, inc/init.php 코드를 고쳐서 GMT로 표시되는 시간을 한국 시간에 맞도록 만들었다. 이렇게 만들어진 썰렁한 위키 사이트의 모습은 이러하다. https://wiki.genoglobe.com이라고만 웹 브라우저에 넣으면 된다. 설정을 매만지다가 갑자기 빈 화면이 나와서 무척 당황했었는데, 그 이유는 시간대를 바꾸기 위해 php 코드를 수정하다가 오타가 난 때문이었다.

여기까지 오기 위하여 세시간 반 정도 삽질을 하였다!

서브도메인은 무한정 만들 수 있는 것이 아니다. 내가 사용하는 hostinger의 shared web hosting/single plan에서는 최대 2개까지만 허용한다. DNS도 같은 업체를 사용하고 있으므로 웹 페이지 형식의 제어판에서 비교적 쉽게 설정이 가능한 것이다.

만약 고전적 방법으로 도쿠위키를 설치하여 genoglobe.com/dokuwiki를 통해 접근하게 하였다면, 역시 SSL 인증서는 genoglobe.com 도메인 하나에 대하여 받은 것으로 충분하다.

이렇게까지 될 줄 알았더라면 genoglobe.kr의 웹호스팅 기간을 연장하지 않고 버텨볼 것을! 안타깝게도 3월 15일에 비자 카드로 결제를 하였다. 수업료를 냈다고 생각하고 앞으로 1년 동안 더 공부를 해 보자. 아니면 환불 규정을 잘 찾아보고 취소를 하는 것도 가능한 방법이다.

앞으로는 genoglobe.com 도메인을 주요 활동의 본거지로 여겨야 되겠다.

아마존웹서비스(AWS), 왜 현대카드를 통한 결제가 되지 않는가?

파견지에서 근무하는 동안 아마존웹서비스의 EC2 서비스를 잘 활용하였다. 2019년 12월부터 지난 1월까지의 사용 요금은 파견 기업의 법인카드(현대카드/VISA)를 이용하여 순조롭게 처리를 해 왔는데, 3월 초순부터 Problems with your AWS Account라는 긴급 이메일이 날아오기 시작하였다.

해결 방법은 대금을 청구할 카드를 바꾸는 것뿐이다. 현대카드측에 전화를 하여 물어보니 아마존웹서비스의 대금 청구와 관련한 문제가 발생한 것은 알고 있는데, 4월에 해결이 될 수도 있고(그렇다면 연체된 대금을 한번에 청구하게 될 것이다) 그렇지 않을 수도 있다고 한다. 어떠한 기술적인 장애인지, 혹은 현대카드와 아마존웹서비스간의 계약(?)과 관련한 문제 혹은 마찰인지는 잘 모르겠다. 

카드의 도용 또는 불법적인 국외 사용의 정황을 파악하고 카드사에서 대금이 빠져나가는 것을 막을 수도 있지만, 상당히 많은 국내인이 사용하는 것으로 알려진 아마존웹서비스의 이용 요금 결제가 알 수 없는 이유로 차단되어 불편을 초래하는 이유가 무엇일까? 이에 대하여 현대카드측이 아마존웹서비스 사용자에게 서비스 장애 사실을 미리 알려줄 수는 없었던 것일까? 아마 현대카드 서비스 센터에서도 꽤 많은 아마존웹서비스 사용자로부터 문의 전화를 받았을 것이기 때문이다. 

문화의 차이 때문인지도 모르겠지만, 비록 아마존웹서비스에서 한글로 된 정보 페이지를 점점 더 많이 제공하는 추세라 하더라도 계약이나 대금 지불에 관련한 글을 읽고서 요지를 재빨리 파악하기가 쉽지 않다. 이를 가리켜서 한국인의 일반적인 문해 능력이 떨어진다고 섣부른 판단을 내려서는 곤란하겠지만 말이다.

계약과 관련한 글에서는 불리한 상황에서 최대한 자신이 책임을 지지 않게 빠져나갈 구석을 만들고, 되도록 많은 이익을 얻게 만드는 것이 당연할 것이다. 계약서 문구를 만들어 오는 사람은 따라서 점점 더 복잡한 내용을 넣어서 깨알같이 작은 글씨로 가득 채워진 문서를 들이밀게 되고, 상세한 검토 없이 사인만 하게 되면 나중에 불리한 일을 당하게 될지도 모른다. 계약은 양자간의 약속인데 '기울어진 운동장'에서 사인을 해야 하는 경우가 많은 것 같다. 

업데이트: 국내 아마존웹서비스 사용자가 같은 문제점을 알리다

기글하드웨어 커뮤니티 게시판에 나와 같은 불편함을 겪은 사용자의 글이 꼭 일주일 전에 올라왔기에 이를 소개한다.

현대카드와 아마존 웹 서비스 사이에 도다체 무슨 일이 있는가(2021년 3월 8일)

We are currently experiencing difficulties with processing payments for AWS Korea with cards issued by our payment partner. We are working with our payment partner to address the challenges at hand. In the interim, we recommend that you update your default payment method to either a Visa, Mastercard, American Express, China Union Pay, or Japanese Credit Card...(중략)... issued by a South Korean bank other than Hyundai Card on the Payment Methods page 

나도 이것과 똑같은 메일 메시지를 받았었다. 이 글을 올린 사람은 결제 수단을 체크카드로 바꾼 다음 곧바로 대금이 빠져나갔다고 한다.

부러진 전기 기타의 헤드-네크 재수리는 하지 않기로 하다. 내가 붙인 그대로~

기타의 수리에서 가장 시간과 노력이 많이 들고 수리비도 비싼 것은 도장과 관련된 작업이다. 기타를 새로 만드는 것과 크게 다르지 않은 일이라는 것을 이번에 알게 되었다. 예를 들어 부러진 네크를 붙이고 접합 부분을 갈아낸 뒤 재도장을 하는 비용은 기타의 원래 가격과는 상관이 없이 공평하다. 따라서 수리 비용이 기타의 구입 가격을 훌쩍 뛰어넘는다면 수리를 하는 것을 주저하지 않을 수가 없다. 공장에서 양산하는 기타라면 규모의 경제를 이용하여 제조 비용을 낮추는 것이 가능하지만, 개별적으로 이루어지는 작업인 수리는 그와 다르다.

수리가 불가능한 고장이나 손상은 없다고 한다. 다만 악기의 소유자가 그 비용을 감당할 의사가 있는지가 중요한 것이다. 사전에 전화 상담을 하여 내가 원하는 수리, 즉 온전하게 도색을 하여 마무리하는 유형의 비싼 수리는 하지 않는 것으로 결론을 내렸다. 하지만 웹사이트의 정보를 보고 대전에서 기타를 들고 온 수고를 생각하여 직접 매장을 찾아가 보기로 하였다. 예를 들어 내가 직접 붙이느라 크게 단차(별로 좋아하는 낱말이 아님)가 난 헤드 전면부만 대충 갈아내고 부분 도색만 하는 등의 다른 가능성도 있는 것 아니겠는가?

문을 열고 들어간지 채 10분이나 걸렸을까? 나는 연습용 기타줄과 피크만 사 들고서 멋적게 매장을 나와야만 했다. 마감의 범위를 좀 줄인다든지 하여 좀 더 저렴한 수준의 수리 방법을 제안할 것으로 기대했지만, 매장 주인의 반응은 너무나 무뚝뚝하였다. 말 몇 마디 주고받고는 다시 작업대로 가서 연신 사포질을 할 뿐이었다. 

"셋업이나 좀 봐 주세요."

"최근에 기타 치시면서 불편하신 거 없으셨나요? 손이 아프게 줄이 너무 높거나 하지 않으면 됩니다."

줄자 비슷한 것으로 현 높이를 재 보고는 손을 볼 필요가 없다고 하였다. 

내가 10을 이야기하면, 3이나 4 정도의 반응이 돌아온다고 느꼈다. 몇 만원을 들여서라도 줄도 새로 갈고, 광도 좀 내고, 녹도 좀 닦아내고 싶었다. 그러나 반응이 너무 냉랭하여 말을 붙일 엄두가 나질 않았다. 아니, 이러한 제안은 상점 주인이 먼저 할 수도 있는 것 아닌가? 먼지도 꽤 달라붙었고 금속 부품의 광택도 죽었으니 오랫동안 관리를 잘 하지 않은 기타임은 누가 보아도 명백하다. 삼익에서 만든 중저가 기타라서 그런가?

기억을 더듬어 보자면 상점 주인이 바가지를 씌운 것도 아니고, 폭언을 한 것도 아니며, 불필요한 수리를 유도하거나 비싼 부품을 사게 한 것도 아니다. 그런데 나는 상점에 머무는 짧은 시간 내내 몹시 불편하였다. 내가 지금까지 경험한 상점의 친절도 순위에서 잘 해 보아야 하위 20% 정도 혹은 그 이하라고 평가를 하겠다.

프로페셔널 연주자, 이제 막 기타에 관심을 갖고 처음 사려는 사람, 학창 시절에 밴드에서 활동했던 추억을 되살리고자 그동안 방치해 둔 녹슨 기타를 들고 정비 차원에서 온 사람... 저마다 사연은 다를 것이다. 노련한 악기점 주인이라면 처렇게 몇 일 기타를 쳐 보려고 하다가 또 스탠드에 세워두고 말 고객을 미리 알아 볼 수는 있을 것이다. 그렇다고 해서 어차피 며칠 치다가 말 사람이 뻔하니 난 상대하지 않겠소..가 되어서는 아니된다. 상점 주인은 하루에도 수십 명의 손님을 대하게 되고, 그중에는 까다롭고 유별난 손님도 있을 것이다. 하지만 고객에게는 그것이 첫 경험이 될 가능성이 크며, 그때 경험한 것에서 재방문 여부가 결정될 것이다.

구글에서 해당 수리점의 리뷰를 찾아 보았다. 기술력이나 철저한 서비스 정신에 대해서는 평이 좋지만, 너무 무뚝뚝하고 불친절하다는 평이 제법 많았다. 싸구려 기타 하나를 사는데 20분이 넘게 세팅을 해 주는 모습에 감동했다는 리뷰도 있었다. 그럼 난 뭐지? 그 싸구려 기타는 최소한 에피폰 수준은 되는가? 최소한 70만원짜리 기타라도 하나 사야 서로 감정도 좀 트이고 진심이 오고 가게 되는가?

구글의 리뷰에는 기타 관리를 받고 새 기타가 된 것 같아서 기분이 정말 좋았다는 글도 있었다. 관리 상태가 엉망인 내 기타에 대해서는 왜 '줄도 갈고 광택 좀 내 드릴까요?'라는 말 한마디 없었을까? 내가 요청을 하지 않았기에? 혹은 그럴 가치가 없는 기타 혹은 손님처럼 보여서? 혹은 바가지 씌운다는 소리 듣기 싫어서 손님이 요청한 것이 아니면 절대로 먼저 제안하지 않는 방어적인 성미이신지?

허탈하고 속이 좀 상해서 집에 돌아온 뒤에도 기분이 쉬 가라앉지 않았다. 나야 다시 가지 않으면 그만이다. 이런 기분을 느낀 고객이 나 혼자만은 아니라고 하니 그것으로 위안을 삼겠다. 수리점 이름을 이 글에서 언급할까 잠시 생각했지만 그만 두기로 했다.