삼익 일렉트릭 기타의 수리가 끝나다

대전 뮤직마스터(페이스북, 네이버 블로그)에서 기타의 수리가 끝났음을 알리면서 작업 사진 수십 장을 카카오톡으로 보내왔다. 구글 포토로 임포트하여 앨범으로 만든 뒤 다음의 링크로 공개한다. 처음 네 장의 사진은 수리 전에 내가 찍은 것이고 나머지 사진은 뮤직마스터에서 보내온 것이다. 뮤직마스터에서 보낸 사진의 배열 순서는 가장 최근 것이 먼저 오도록 되어 있다.

https://photos.app.goo.gl/pMxdUv96i2UTLST2A

작업 완료 후의 사진

내가 흉하게 붙인 헤드스톡의 앞면을 보기 좋게 만드는 것과 셀렉터 교체가 가장 품이 많이 드는 일이었고 프렛 관리 등 기본적인 관리 작업을 부탁하였었다. 세미 할로 바디의 기타는 F-홀을 통해서 배선 작업을 해야 하므로 부품을 갈려면 일반적인 일렉기타에 비하여 손이 많이 간다고 하였다.

수리를 결심하면서 블로그에 쓴 글은 여기에 있다. 큰 기대를 안고서 이름이 꽤 알려진 분당의 기타 수리점에 갔다가 수리는커녕 거의 퇴짜를 맞고 돌아왔다. 마치 고칠 필요가 없는 기타라고 여긴 듯 일반적인 컨디셔닝 작업에 대한 제안도 하나도 해 주지 않았다. 만약 이 일에 대해 논쟁이 벌어진다면 '당신이 특별히 더 부탁한 게 없었는데?'라고 항변을 할 것이다. 그건 틀린 말은 아니지만, 수리점 업주의 태도가 너무 불친절하여 물을 엄두가 나지 않았었다는 것이 나의 솔직한 의견이다. 말 한마디 하기가 무섭게 작업대로 돌아가 사포질만 하고 있는 업주에게 무엇을 기대하겠는가? 가격 흥정과 같은 무리한 요구를 한 것도 없고, 직접 대면했을 때에는 논쟁이 오가지도 않았으며, 판매용 기타를 쳐 보겠다고 한 것도 아니었다. 도대체 어떤 태도를 가져야 이 업주의 마음에 들게 될까? 지금도 그 수리점에 갔던 생각만 하면 기분이 몹시 불쾌하다. Mule에 올라왔던 글을 하나 링크해 놓겠다. Google 리뷰를 찾아 보아도 평이 갈리는 것은 마찬가지. 들여다보면 자꾸 짜증스러운 기억만 떠오른다.

수리를 포기하려다가 내 본래 거주지인 대전에서 해결 방안을 찾게 되었다. 외관 수리에 대한 상담을 마친 후 특별히 요청하지 않았지만 앰프를 연결한 상태로 점검을 하여 리어 픽업에서 소리가 거의 나지 않음을 확인해 주었다. 셀렉터에 문제가 있는 것으로 진단하고 교체를 하기로 했다. 기억을 더듬어 보니 구입 후 얼마 되지 않아 기타를 넘어뜨리면서 셀렉터에 충격이 가해져 플라스틱 손잡이가 떨어져 나갔던 일이 있었는데, 그 이후로 전기적 접촉도 매우 좋지 않은 상태가 되었던 것 같다.

원래 상태는 이랬었다. 헤드는 유광 검정색으로 붉은색 바디와 다른 모습이다. 아마도 폴리우레탄 피니쉬가 아니었을까?

사진 제공: 뮤직마스터

도장을 벗겨내고...

사진 제공: 뮤직마스터

무늬목을 붙여서 마무리를 하였다. 원래의 모습처럼 유광 검정색으로 마무리를 하면 더 좋았을지도 모른다는 아쉬움이 있었지만 그렇게 되면 심각한 목공 및 도장의 영역으로 넘어가게 될 것이다. 수리를 의뢰하고 기다리는 동안 개인적인 관심이 생겨서 옻칠에 관해 조사를 해 보기도 하였다. 네크 뒷면의 접합부는 그대로 두었다. 깨진 도장의 일부만 벗겨내고 흔적이 남지 않게 칠을 새로 한다는 것은 보통 일이 아니기 때문이다.

사진 제공: 뮤직마스터

뒷부분은 그대로 두기로 하였다.

이것으로도 충분히 아름답지 않은가? 작은 헤드스톡 - 삼익에서 제조한 그렉 베넷(Greg Bennett)의 일렉기타 디자인에서는 헤드스톡을 작게 만드는 것이 기본 철학임 - 에 대하여 장식적인 요소를 강조할 이유는 없다고 생각한다. 기타줄을 전부 걷어낸 모습을 보니 로우 포지션쪽의 프렛이 상당히 많이 닳아 있었다. 만약 수년이 지나 다음에 다시 관리를 맡기게 된다면 프렛을 교체하는 것도 생각해 볼 수 있다. 새 기타를 사지 않는다면 말이다.

2000년, 그러니까 21년 전 아마도 2월,  대전 둔산동 타임월드 근처의 비바체 악기(지금은 없어짐)에서 이 일렉기타를 구입하였었다. 시리얼 번호에 의하면 1999년도 제조품인 것 같다. 이 기타에는'Made in Korea'라는 표식을 제외하면 제조사나 모델을 알 수 있는 근거는 없다. 삼익에서 그렉 베넷 설계의 세미 할로 바디 일렉기타인 Royale 시리즈를 본격 출시하기 전에 만든 시험 제작품이 흘러 나온 것을 내가 구입한 것으로 알고 있다. 흥미롭게도 구입 당시에는 네트쪽의 스트랩핀이 붙어 있지 않아서 삼익악기 본사에 편지를 보냈더니 부품을 무료로 보내주어 내가 직접 구멍을 뚫고 고정하였다.

우연히 유튜브에서 그렉 베넷이 직접 Royale RL3 모델을 설명하는 동영상(아래에 게시)을 보았다. 이 모델이 어떤 개념에 의해 설계되었고 어떤 장점이 있는지 찬찬히 설명하는 모습이 참 보기에 좋다. 기타의 현을 지지하는 두 곳, 즉 브리지와 너트에서 현을 당기는 각도에 의해서 소리가 달라진다는 설명을 이 동영상에서 기타 설계자를 통해 들으니 귀에 쏙쏙 들어온다.

일반적인 세미 할로 바디 기타라면 본체를 네크와 같은 방향으로 가로지르는 블록은 통짜 나무를 쓰지만 옆면은 어쿠스틱 기타를 만드는 것과 유사하게 얇은 판(보통 3/16 인치 두께)을 구부려서 붙여 만든다. 그런데 5분 15초부터 그가 특별히 자랑스럽게 생각하는 바디 디자인에 관한 이야기가 나온다. 이 기타는 특이하게도 옆면까지도 통판을 갈아내어 만들었다고 한다. 아래쪽의 날카로운 컷어웨이 부분을 만들려면 측판을 구부리는 방법으로는 곤란했기 때문이다. 그래서 판 하나를 CNC로 라우팅하여 챔버 부분을 깎아내어 이런 모습이 된 것인데, 처음부터 그렇게 설계된 것은 아니었고 우연히 그렇게 되었다고 한다. Royale 모델 특유의 monoframe construction을 다음의 사진에서 보였다.

그림 출처 링크

즉 센터블록과 옆판은 원래 하나의 나무판이었던 것이다. 이것이 오히려 강도와 서스테인, 공명 등 모든 면에서 좋은 효과를 가져왔다고 한다. 핀터레스트에 남겨진 'RL 3 AM' 모델의 광고 이미지도 인용해 본다.

이 기타를 살 때에는 세미 할로 방식의 기타 제작 방식에 대해서 별 생각이 없었다. 그런데 측면에 나타나는 마호가니의 무늬를 보고서 전체를 하나의 나무에서 깎아낸 것이라는 생각이 들었다. 삼익악기에 스트랩핀을 부탁하기 위해 편지를 쓰면서 이에 대한 궁금증을 같이 적었고, 내 추측이 맞다는 답장을 받았던 것 같다.

사진 제공: 뮤직 마스터. 옆면의 나무 무늬를보라. 

삼익의 Royale 시리즈는 볼트-온-넥을 채용한 가장 저가의 RL-1부터 화려한 RL-5와 RL-40까지 몇 가지의 모델이 나왔었다. 내가 소유한 기타는 이것 중에서 RL-4와 가장 가깝다. 그러나 바인딩의 색상이 다르고 결정적으로 헤드스톡에 아무런 표식이 없다. 정식으로 출시된 제품이 아니니 그럴 수밖에. 사다리꼴의 지판 인레이는 RL-3의 것을 닮았다. 커스텀 기타는 절대 아니지만 어쩌다 보니 세상에 하나밖에 없는 물건을 갖게 되었다.

이번에 기타 수리와 조사 작업을 거치면서 내 기타에 대하여 더욱 애착을 갖게 되었다. 최근에 스쿨뮤직 웹사이트를 들락거리면서 '무엇이 내 다음번 기타가 될까?'하는 헛된 생각으로 시간 낭비를 많이 했던 것을 반성한다. 주기적으로 관리만 잘 한다면 계속 쓸 수 있는 것이 기타 아니겠는가? 다음에는 사무실에 방치된 2008년에 구입한 인도네시아 제조 스콰이어 텔레캐스터를 들고 뮤직마스터를 찾아야 되겠다. 시리얼 넘버에 의하면 이 기타의 제조연도는 2007년이다. Affinity와 Standard Telecaster에 대한 정보는 SquireWiki를 참조하라.

나의 스콰이어 텔레캐스터(Squier Telecaster Standard Series). 네이버 블로그(현재 없음) 백업본에서 찾아낸 구입 직후의 사진이다. 

2023년 1월 30일 업데이트

수리한 기타의 헤드스톡에 붙인 무늬목이 군데군데 부풀어 올랐다. 줄을 교체하게 되면 헤드머신을 제거하고 다리미로 눌러서 어떻게 해서든 자가 수리를 해 보련다. 

2023년 1월에 인천의 '악기플러스'를 찾아가서 DBZ Cavallo AB 플라잉-V 형 기타를 구입하였다(링크).

Greg Bennett은 2020년 6월 22일 69세를 일기로 사망하였다(링크). 'Made in Korea' 시절의 삼익 일렉트릭 기타에 대한 좋은 기억을 갖고 있는 사람들이 많은 것으로 알고 있다. 고인도 여기에 큰 기여를 했고, 음악 애호가들에게 값진 유산을 남겼다. 삼가 고인의 명복을 빈다.

[우분투의 사운드와 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 공부도 해야 하고, 일렉기타 연습도 필요하고... 할 것이 너무 많다!