아르페지오의 속도를 조절하려 했는데, 범인은 에코였다

새벽 네 시에 일어나 앉아서 맛없는 음료를 벌컥벌컥 마신다. 몇 시간 뒤에 있을 대장 내시경 검사를 위해 장을 깨끗이 비우기 위함이다. 어젯밤 7시에 먹었던 1차 복용제는 그런대로 먹을 만했는데, 새벽 네 시에 먹어야 하는 2차 복용제는 정말 고역이다. 잠을 깬 김에 어제 퇴근후 벌어졌던 Fluid Ardule 운영 스크립트 개발기를 쓴다. 어차피 속이 그득하고, 잠시 뒤면 또 화장실을 들락거려야 하니 다시 잠자리에 들기는 틀렸다.

Fluid Ardule에서 요즘 흥미를 느끼는 것은 Yoshimi의 아르페지오 계열 음색(preset)이다. 자주 쓰다 보니 한 가지 아쉬움이 생겼다. 현재는 고정된 속도로만 일정 패턴의 note가 발생한다. 실제 곡의 템포에 따라 아르페지오 속도를 바꾸고 싶었다. Yomishi의 프리셋을 전환할 때 발생하는 잡음을 없애는 것이 가장 최근의 도전 과제였었다. 하나를 해결하면, 그 다음 문제에 몰두하게 된다.

아르페지오를 로드한 뒤 건반 하나를 누르면 음이 일정한 패턴으로 반복된다. 음색을 고르는 것만으로도 꽤 그럴듯한 연주가 된다. 그런데 연주 중에 조금 빠르게, 혹은 조금 느리게 바꾸고 싶다는 생각이 드는 것은 당연하다. Fluid Ardule에는 로터리 인코더가 있다. 이것을 돌려 아르페지오의 속도를 조절하면 좋겠다.

말은 간단하다. 문제는 Yoshimi에서 무엇을 건드려야 하는가였다. 당연히 BPM이라고 생각했다. 

AI(ChatGPT)에게 물었다. Yoshimi에는 명령행 인터페이스가 있으니 실행 중인 프로그램에 명령을 보내어 BPM을 바꿀 수 있지 않겠느냐고. 처음에는 AI도 그렇게 생각했다.

나는 Yoshimi 매뉴얼을 AI에게 주었다. AI는 매뉴얼을 읽고 다음과 같은 명령을 찾아냈다.

BPM <n>    default BPM if none from MIDI

좋다. 답을 찾은 것 같았다.

라즈베리 파이에서 Yoshimi를 인터랙티브 모드로 실행했다.

yoshimi -i

아르페지오 프리셋을 불러왔다.

load instrument /home/pi/sf2/yoshimi_links/Arpeggios__0001-Arpeggio1.xiz

그리고 BPM을 바꾸었다.

set bpm 60
set bpm 180

60과 180이면 세 배 차이다. 건반을 눌러 보았다.

똑같다.

나는 말했다.

이상한데요? bpm 바꾸어도 아르페지에이터 속도는 그대로예요.

AI는 매뉴얼을 다시 뒤졌다. 이번에는 LFO 항목에서 BPM 동기화 기능을 찾아냈다.

Bpm <s>    sync frequency to MIDI clock

아마 LFO가 BPM에 동기화되지 않은 상태라서 global BPM을 바꾸어도 소용이 없는 것 같다는 설명이었다. 그럴듯했다.

문제는 Yoshimi의 CLI가 생각보다 만만하지 않았다는 것이다.

set part 1

여기까지는 좋았다.

add

라고 입력했더니,

add what?

이라고 했다. set add라고 해야 했다. LFO로 들어가려고 lfo라고 입력했더니 또 알아듣지 못했다. set lfo라고 해야 했다.

Frequency context에도 들어갔다.

set frequency

마침내 원하는 장소에 도착했다.

@ p1+, A+, LFO freq+

여기에서,

set bpm on

을 실행했다. 다음과 같이 표시된다. 드디어 정확한 명령어 입력 방법을 알아낸 것이다.

Part 1 Kit 1 AddSynth Freq LFO BPM - on

이번에는 정말 되는 줄 알았다. BPM을 바꾸고 건반을 눌렀다.

똑같다. Rate도 바꾸어 보았다. 그러나 달라지는 것이 없었다.

AI는 또 다른 가능성을 제시했다. ADDsynth의 Voice Delay가 반복을 만드는 것이 아닐까? Voice 1과 Voice 2로 들어갔다. Delay라는 명령도 발견했다. 값을 바꾸었다. 나는 건반을 눌렀다.

전혀 안됩니다.

이날 오전 AI와 나의 대화에서 가장 많이 등장한 문장은 아마 이것이었을 것이다.

안 바뀝니다.

AI는 가설을 제시했다. 나는 라즈베리 파이에 명령을 입력했다. 건반을 눌렀다.

안 달라져요.

다시 가설. 다시 명령. 다시 건반.

빠르기와는 무관합니다!

이쯤 되자 매뉴얼에 나오는 일반적인 기능 설명만으로는 답을 찾기 어려워졌다. 나는 이미 분석을 위해 Yoshimi의 아르페지오 프리셋 파일을 AI에게 올려 둔 상태였다. 그래서 말했다.

아까 업로드했으니 다시 살펴봐요.

이번에는 매뉴얼이 아니라 실제 프리셋 파일 자체를 분석하기 시작했다. 대상은 이것이었다.

Arpeggios__0001-Arpeggio1.xiz

이름은 Arpeggio1이다. 나는 당연히 이 파일 어딘가에 아르페지에이터의 속도를 결정하는 파라미터가 있을 것이라고 생각했다. BPM, LFO, Rate, Clock 같은 것 말이다.

그런데 프리셋의 구조를 따라가던 AI가 다른 것을 지목했다.

Part 1. Effect 2. Echo.

에코?

나는 아르페지오의 속도를 바꾸고 싶은데 갑자기 에코라니. 솔직히 처음에는 이것도 별로 믿음이 가지 않았다. 테스트하는 내내 이미 여러 번 틀렸기 때문이다.

그래도 실험은 간단하다. Yoshimi CLI에서 Part 1로 들어갔다.

/
set part 1

Effect 2를 Echo context로 열었다.

set effect 2 echo

프롬프트가 바뀌었다.

@ p1+ eff 2 ECho-3?

Echo의 파라미터 중에는 Delay가 있었다. 값을 바꾸었다. 건반을 눌렀다.

와, 드디어 연주가 달라졌다.

BPM을 바꾸고, LFO를 뒤지고, Voice Delay를 건드려도 꿈쩍하지 않던 반복 속도가 Echo Delay 값을 바꾸자 확연히 달라졌다.

우리가 찾던 아르페지오의 속도는 에코가 만들고 있었다.

물론 엄밀히 말하면 "아르페지에이터가 에코였다"는 표현은 정확하지 않을 것이다. 그러나 적어도 내가 사용하던 Yoshimi의 Arpeggio1 프리셋에서 귀에 들리는 반복 패턴의 속도를 실질적으로 좌우하는 파라미터는 Part 1 Effect 2의 Echo Delay였다.

이제 원인을 찾았다. 다음 문제는 Fluid Ardule의 화면에 무엇을 표시할 것인가였다.

Echo Delay 42

이렇게 표시할 수는 없다. 연주하는 사람이 알고 싶은 것은 Yoshimi 내부의 이펙트 파라미터 값이 아니다. 대략 얼마나 빠르게 반복되는가이다.

처음에는 BPM과 비슷한 숫자를 만들어 Echo Delay에 대응시키는 간단한 식을 만들었다.

echo_delay = round(6000 / raw_speed)

그리고 작은 Python 테스트 프로그램(test_yoshimi_arp_speed_calibrated.py, GitHub에 공개)을 만들었다. 숫자를 넣고 건반을 연주했다. 메트로놈과 비교하여 실제로 어느 정도의 BPM처럼 들리는지 측정했다.

처음 측정값은 조금 들쭉날쭉했다. 그래서 다시 측정했다.

60  → 52
75  → 66
100 → 83
120 → 100
140 → 126
160 → 133
180 → 140
200 → 162
220 → 181
240 → 200

정밀한 계측 장비를 쓴 것은 아니다. 내 귀와 메트로놈이다. 그래도 관계는 꽤 일정했다.

AI에게 계산을 시켰다. 단순 선형 회귀 결과는 다음과 같았다.

apparent_bpm ≈ 0.797 × raw_speed + 5.13

그러면 역으로 원하는 체감 속도에서 내부 값을 계산할 수 있다.

raw_speed ≈ (display_bpm - 5.13) / 0.797

그리고 이것을 다시 Echo Delay 값으로 변환한다.

echo_delay = round(6000 / raw_speed)

첫 번째 테스트 프로그램은 측정을 위한 것이었다. 측정이 끝난 뒤 AI에게 그 결과를 주고 프로그램을 한 번 고쳤다. 보정된 테스트 프로그램으로 다시 확인했다. 괜찮았다.

그제야 Fluid Ardule 본 프로그램에 넣었다.

이 기능의 이름을 BPM이라고 하지는 않았다. 진짜 BPM이 아니기 때문이다. MIDI clock과 동기화된 값도 아니다. 특정 Yoshimi 프리셋의 반복 속도를 귀로 측정하고 경험식으로 보정한 값이다.

그래서 이름은,

Arpeggio Speed.

인코더를 돌리면 1씩 변한다. 연주 중에도 바로 속도가 달라진다. 화면 오른쪽에는 작은 글씨로 이렇게 표시했다.

Rotate Encoder to adjust

기능 하나를 추가하는 데 오전 한나절이 걸렸다.

처음에는 내가 매뉴얼을 AI에게 주었다. AI가 매뉴얼을 분석하여 BPM을 찾았다. 틀렸다. 다시 매뉴얼에서 LFO BPM sync를 찾았다. 틀렸다. Voice Delay를 의심했다. 또 틀렸다.

결국 내가 이미 올려 둔 실제 프리셋 파일을 AI가 분석했다. 그 안에서 Echo를 찾아냈다. 나는 라즈베리 파이에서 CLI 명령을 하나씩 입력하고 건반을 눌러 검증했다. 마지막에는 테스트 프로그램을 만들고, 메트로놈으로 직접 속도를 재고, 측정값을 AI에게 주어 회귀식을 만들었다. 이를 바탕으로 Fluid Ardule 운영 스크립트를 최종적으로 수정하였다. 상세한 기술적인 내용은 GitHub에 Controlling the Apparent Arpeggio Speed of Yoshimi Presets라는 제목으로 따로 정리하였다.

요즘 AI와 하는 개발은 대략 이런 식이다.

실은 이 글도 첫 단락을 제외하면 AI가 써 준 것을 거의 그대로 옮긴 것이다. Fluid Ardule 운영 스크립트 개발을 위해 ChatGPT와 작업한 대화창은 나의 시행착오를 전부 기억하고 있기 때문에, 블로그 작성용 초안을 달라고 명령만 하면 이렇게 뚝딱 만들어 낸다. 처음에는 이런 방식으로 글을 쓰는 것에 대하여 상당한 거부감을 느꼈었는데, 나 역시 편리함과 효율 앞에서는 최신 기술과 적당히 타협하지 않을 수가 없다.

개발은 마지막 5분에 끝난다?

그림 출처: Yoshimi synth

어제의 퇴근 후 개발은 Yoshimi를 매끄럽게 작동하기 위한 투쟁이었다. Yoshimi에 대한 ChatGPT의 설명을 인용해 보자.

Yoshimi는 Linux 환경을 위한 오픈소스 소프트웨어 신시사이저로, SoundFont를 재생하는 FluidSynth와 달리 실시간 음색 합성을 통해 소리를 만들어 낸다. Additive, Subtractive, PadSynth 등 다양한 합성 방식을 지원하며, 풍부한 패드, 리드, 베이스, 아르페지오와 같은 신디사이저 음색에 특히 강점을 가진다.

Fluid Ardule에서는 SoundFont(FluidSynth)뿐 아니라 Yoshimi도 하나의 음원 엔진으로 사용할 수 있다. 그런데 악기를 바꿀 때마다 Yoshimi를 다시 시작해야 했고, 그때마다 "붕~" 하는 짧은 소리가 났다. 실사용에는 매우 거북한 상황이었다.

처음에는 당연히 Python 코드의 문제라고 생각했다. 운영 스크립트를 이리저리 고쳐 보았고, 실행 중인 Yoshimi에 명령을 보내 악기만 교체하는 방법도 시도했다. 화면은 정상적으로 바뀌었지만 정작 소리는 바뀌지 않았다. 결국 그 방법은 폐기했다.

여기까지였다면 "Yoshimi는 원래 그런가 보다." 하고 끝냈을지도 모른다. 일단 다른 쪽으로 UI를 안정화한 파이썬 운영 스크립트의 최신 버전을 커밋한 다음 5km 야간 달리기를 하고 돌아왔다.

운동을 하고 돌아오니 정신은 더욱 맑아졌다. 이대로 잠자리에 들기에는 아까웠다. 다시 노트북 컴퓨터 앞에 앉아 커맨드 라인에서 Yoshimi의 프리셋 변경 테스트를 실시해 보았다.

놀랍게도 실행 중인 Yoshimi에서도 다음과 같은 명령으로 악기를 바꿀 수 있었다.

load instrument /path/to/file.xiz

그런데 이상한 점이 있었다. 공백이 없는 파일은 잘 바뀌는데, 공백이 들어 있는 파일 이름만 계속 실패하는 것이다.

한참을 테스트한 끝에 원인을 찾았다. Yoshimi의 CLI는 쉘(shell)이 아니다. 따옴표도, 백슬래시도 일반적인 리눅스 셸처럼 해석하지 않는다. 결국 공백이 없는 심볼릭 링크를 만들어 그 경로를 전달하자 실행 중인 Yoshimi의 패치가 즉시 바뀌었다.

아직 Fluid Ardule에 적용한 것은 아니다. 하지만 오늘 얻은 것은 훨씬 더 중요하다.

"실행 중인 Yoshimi의 패치를 바꾸는 것은 가능하다."

그동안은 재시작이 필수라고 생각했지만, 이제는 부드럽게 전환할 수 있는 길이 보이기 시작했다.

개발을 하다 보면 가끔은 몇 시간 동안 한 발짝도 앞으로 나가지 못하는 것처럼 느껴진다. 그런데 하루를 접고 운동을 하고 돌아와 마지막 5분 동안 결정적인 단서를 발견하는 경우가 있다.

그래서 나는 요즘 이런 생각을 한다.

개발은 하루 종일 하는 것이지만, 진짜 해결은 마지막 5분에 이루어지는 경우가 많다.

더불어서 이런 깨달음도 있다. 어제까지 만든 것이야말로 정말 최선의 안정화 버전이라고 생각했는데, 오늘 다시 돌이켜 보면 "이렇게 부끄러운 것을 어떻게 세상에 내어 놓겠는가" 하는 생각이 든다는 것이다. 운영 스크립트에 거는 기대 수준은 나날이 올라가고 있으며, 개선에 드는 시간도 생각보다 점점 짧아지는 느낌이다.

빨리 소개용 동영상을 찍고 싶은데, 내일 아침 일찍 서울에서 열리는 회의에 참석하기 위해 하루 먼저 올라와 서울역 근처의 허름한 호텔에서 밤을 보내는 내가 조금은 처량하게 느껴진다.

2026년 7월 2일 업데이트

공백을 포함한 Yoshimi의 프리셋 위치를 하이픈으로 대체하여 심볼릭 링크를 만든 뒤 Fluid Ardule 운영 스크립트 내에서 변경을 시도하였으나 소리가 바뀌지 않았다. Yoshimi를 커맨드 라인에서 실행하여 자체 프롬프트에서 load instrument를 실행하는 것과, Fluid Ardule에서 제어하는 것은 약간 다른 것 같다. 일단 이 문제는 다른 방식으로 우회하여 해결하였다. Yoshimi에서 볼륨을 줄여서 붕~ 소리가 거의 나지 않게 만든 뒤 다른 프리셋으로 바꾼 다음 다시 음량을 원상복구하는 간접적인 방식이었다. 일종의 편법이지만 한결 나아졌다.

2026년 7월 3일 업데이트

어제 퇴근 후 작업한 26072f 버전에서 드디어 안정적인 Yoshimi 패치 변경에 성공하였다. 악기 변경 전후에 볼륨을 줄였다가 원상복구하는 편법도 더 이상 필요하지 않다. 작동 안정성도 더욱 좋아진 것 같다.

DIYer가 가장 하기 싫은 것은...

사람마다 다르겠지만, 나는 무엇인가를 자르고 뚫는 일이 가장 하기 싫다. 특히 전동 공구를 쓸 때에는 시끄럽고 사고가 나기 쉬우며, 수공구로 톱질이나 줄질을 하다가도 손을 다칠 수 있다. 알루미늄 판에 애써 구멍 위치를 표시하고 타공을 마쳤는데 정작 여기에 고정할 보드의 볼트 구멍 위치가 맞지 않을 때의 그 절망감은 느껴 본 사람만이 안다.

반면 단단하고 창백한 실납이 인두의 열기에 녹으면서 광택과 함께 부드럽게 흐를 때에는 일종의 희열을 느낀다. 하얗게 피어오르는 연기 또한 시각적 즐거움을 더한다. 흡연자의 기분이 이런 것일까? 어쩌면 DIY 작업 중 건강에 가장 해로울 수도 있는 납땜 작업이 나는 가장 즐겁다. 물론 열을 너무 많이 가해서 배선 피복이 녹거나, 만능기판의 동그란 패드가 떨어져 나갈 때 그 난처함은 이루 말할 수 없지만. 간혹 달아오른 인두에 손을 데기도 한다.

드릴 스탠드를 구한 이후로 구멍 뚫기 작업은 한결 수월해졌다. 드릴을 수직으로 움직이는 것이 가능해졌기 때문이다. 작업대에 스탠드를 고정해 두고 작업물까지 물린 바이스까지 있다면 금상첨화일 것이다. 아직은 작업물 + 드릴 방아쇠 + 드릴을 내리누르는 손잡이까지 한꺼번에 붙잡아야 해서 거의 서커스 수준의 요령이 필요하다. 

드릴 작동 및 속도 조절을 발로 할 수 있다면? 조광기를 이용한 드릴 속도 조절기를 만들었던 일이 있다. 이는 R-core 출력트랜스포머(진공관앰프용)의 권선기로 쓰기 위함이었다. 다음은 그 증거 사진(원본 글 링크; 2022년도에 작성)이다. 사진 배경을 보니 광화문 인근 오피스텔에서 파견 근무를 하던 시절 찍은 것이다. 그 좁은 방구석에서도 열심히 납땜을 하고 구멍을 뚫었었다.

혹시 여기에 악기용 익스프레션 페달을 연결하면 발로 속도를 조절하는 것이 가능할까? 조광기는 상용 220V 전기를 사용하는 것이므로, 저전압에서 작동하는 포텐셔미터에 불과한 익스프레션 페달을 그대로 연결할 수는 없다. 안전을 보장할 수 있는 추가 회로를 만들어야 한다.

차라리 드릴 프레스 손잡이에 끈을 달아서 발에 건 뒤 아래로 당기는 것이 더 나을지도 모르겠다. 간단한 것이 최고 아닌가? 

밤 8시가 지난 시각, 아랫집에 미안한 마음을 느끼면서 라즈베리 파이 케이스에 다섯 개의 구멍을 뚫고 줄질을 하였다. RCA 단자를 쇠톱으로 자르는 일은 매우 쉬웠다. 플라스틱이니까.

헤드폰 앰프 만들기. 배선을 완료한 뒤 포맥스 판을 잘라서 위를 덮으면 끝난다. 작업대가 너무 지저분하여 AI로 배경을 약간 정리하였다.

개조한 라즈베리 파이 케이스는 헤드폰 앰프(MAX4410 칩 사용; 데이터시트)의 케이스로 변모하였다. 케이스의 바닥쪽 판은 라즈베리 파이 3B와 함께 Fluid Ardule 안에 영구 장착되었다. 하나의 케이스가 두 개의 작품으로 나뉘어 새 삶을 얻은 셈이다. 

Fluid Ardule의 운영 스크립트가 드디어 1만 줄을 돌파하다

경주 화백컨벤션센터(HICO)에서 열렸던 2026년 한국미생물생명공학회 정기학술대회 및 국제심포지엄을 다녀왔다. 지난 몇년 동안은 홍보를 위한 세션에서 짤막하게 발표를 하고 서둘러 돌아와서 다른 회의 일정을 소화했었지만, 이번에는 정말 오랜만에 여유를 가지고 마지막 plenary lecture(연세대학교 이봉신 교수, Human-Data Interaction for Exploration and Communication)까지 알뜰하게 듣고 돌아왔다.

이봉신 교수가 마이크로소프트 리서치에서 일할 때 개발한 Data Formulator는 AI를 이용해 데이터를 시각화하는 강력한 도구이다. 자연어 입력만으로 원하는 목표를 달성하는 것은 쉽지 않다. UI 상호작용과 자연어 입력을 결합한 방식을 채택하여 복잡한 데이터의 시각화를 할 수 있으며, 이는 새로운 수준의 질문으로 이어진다. Data Formulator는 MIT License로 전환되어 누구나 사용할 수 있게 되었다. 그렇다. 데이터의 시각화는 화려함을 자랑하기 위함이 아닌 것이다. 

• Data Formulator (마이크로소프트의 소개 링크)

이런 수준의 챠트를 그리기 위해 R 패키지를 찾아서 설치하면서 얼마나 열심히 공부를 해야 했던가? 확실히 세상은 달라졌다. AI가 새로운 기회를 주고 있으며 일상 주변에서 의미와 재미를 찾는데 큰 도움을 주고 있다. 오늘은 AI에 대해서 조금은 긍정적인 생각을 해 본다. 

이렇게 경주에서 많은 영감을 얻고 돌아왔다.

주말에는 다시 Fluid Ardule 개발 작업이 이어졌다. 흔한 목공용 나사못이 아니라 thumb screw를 이용하여 아크릴 상판을 고정하도록 만들었다. 거추장스럽게 길었던 GPIO 확장용 리본 케이블도 적당한 길이의 것으로 바꾸었다. M4 thumb screw에 물릴 삽입용 황동 너트는 원래 열을 가해서 플라스틱 재료에 고정하는 용도이다. 많은 힘을 받는 곳이 아니기 때문에 너트의 직경보다 약간 작은 구멍을 6mm 드릴날로 뚫은 뒤 목공본드를 발라서 박아 넣었다.

이 부품을 구입해 놓고서도 과연 잘 장착할 수 있을지 고민이 많았었다. 그냥 하면 된다! 판재 정중앙 위치에 맞추어 박아 넣지는 못하였지만...

생각보다 멋지다. 상판을 언제든지 쉽게 열어서 유지보수를 할 수 있게 되었다. 뿐만 아니라 소개용 비디오를 촬영하기에도 손색이 없는 외관을 갖추었다.

오늘의 개발을 통해 Fluid Ardule 운영 스크립트(launch_fluidardule.py)는 드디어 1만 줄을 넘어서게 되었다. "이 정도면 파일을 분리해야 하는 것 아닌가?"라는 생각이 자연스럽게 든다. 하지만 프로그램의 규모를 줄 수만으로 판단할 문제는 아닌 것 같다.

이 운영 스크립트는 하나의 이벤트 루프를 중심으로 화면, 버튼, MIDI, 오디오 엔진, USB 장치, 인터넷 라디오, Combi, 미디어 플레이어가 서로 긴밀하게 상호작용하는 일종의 펌웨어(firmware)에 가깝다. 오늘만 해도 USB 핫플러그, 볼륨의 Soft Takeover, Combi의 UI 흐름을 함께 다듬었는데, 만약 이 기능들이 여러 개의 작은 파일에 흩어져 있었다면 오히려 전체적인 사용자 경험을 일관성 있게 개선하기 어려웠을 것이다.

물론 언젠가는 독립성이 높은 기능들을 분리해야 할 날이 올 것이다. 그러나 지금은 줄 수보다 결합도(coupling)가 더 중요한 기준이라는 생각이 든다. 아직은 하나의 운영 스크립트 안에서 전체 시스템의 동작을 한눈에 바라보는 편이 Fluid Ardule라는 악기를 다듬는 데 더 적합하다.

50대 후반, 자산 관리를 시작하다

요즘 우리 주변에서는 인공지능과 주식시장을 빼면 이야깃거리가 거의 없는 것 같다. 누군가는 풍족해지겠지만, 세상의 화제가 지나치게 한쪽으로 쏠리는 것은 아닌가 하는 생각도 든다.

연구소 동료인 ㅎ 모 박사가 이르기를 '정 박사까지 주식을 시작했다니 이제 국내 주식도 최고점에 오른 것(= 떨어질 일만 남은 것?)'이라고 하였다. 그러면서 1929년 미국 주식시장의 대폭락 직전의 어느 구두닦이 소년 이야기를 들려 주었다. Joseph P. Kennedy Sr.(미 대통령 John F. 케네디의 아버지)가 구두를 닦고 있는데 구두닦이 소년이 이렇게 말했다고 한다.

"선생님, ○○ 주식을 사세요. 곧 더 오를 겁니다."

그 순간 케네디는 충격을 받았다.

"주식에 대해 아무런 전문지식이 없는 소년까지 주식 이야기를 하고 있다면, 이미 너무 많은 사람이 시장에 뛰어든 것이다."

그는 곧 보유 주식을 대부분 처분했고, 얼마 지나지 않아 1929년 10월 월가 대폭락(Wall Street Crash of 1929)이 일어났다고 한다. 워낙 유명한 이야기라서 많이 거론되지만, 실제로 케네디가 구두닦이 소년의 이야기만을 듣고 이런 판단을 내리지는 않았을 것이다. 투기 열풍이 대중 전체로 퍼져 나갈 때 시장 과열을 경계해야 한다는 교훈을 상징적으로 보여주는 사례라고 하겠다.

지난 4월 22일, 회의를 위하여 서울역 근처를 찾았다가 마침 동호회(록 밴드 KRIBBtonite) 회비 관리용 통장이 필요하여 점심시간을 이용하여 가까운 은행에서 수시입출금용 계좌를 하나 열었다. 이와 동시에 별다른 고민을 하지 않고 은행의 ETF 신탁 상품에 가입한 뒤 미국 ETF를 구입하였다. 종목 선택도 매우 즉흥적이었다. 나는 약간 위험 부담이 있지만 고수익을 추구하고 싶다고 하였다. 국내와 미국 하나씩 선택하여 구입했다고 생각했는데 서류를 다 작성하고 나니 둘 다 미국 ETF였다! 그런데 지금 생각하면 오히려 잘 한 선택이었다.

은행에서 ETF를? 지금이라면 그렇게 하지 않았을 것이다. 이유는 단순하다. 사고 파는 것이 증권사 앱에서처럼 자유롭지도 않고, 수수료도 높은 수준이기 때문이다. 더군다나 약관 상으로는 목표 수익률에 다다르면 자동으로 환매가 된다. 하지만 확인을 해 보니 목표 수익률은 설정하지 않은 상태였다. 다행이다!

이날 그냥 내키는 대로 은행 ETF에 가입하지 않았더라면, 나는 지금도 과학기술인연금(매우 보수적 설정)과 정기예금만 만지작거리며 새로운 생각이나 이에 따른 실행을 하지 않았을 것이고, 자산 관리는 여전히 먼 세상 이야기였을 것이다. 따라서 이날 약간의 수업료를 선취수수료로 낸 것에 대해 불만은 없다. 이것은 그대로 묵혀 둘 생각이다.

나머지의 투자는 미래에셋 MTS(Mobile Trading System)를 통해서 진행하였다. ISA 계좌를 새로 열어서 국내 ETF 세 종목, 아시아권 ETF 한 종목에 투자하여 보았다. 나중에 살펴보니 국내 ETF가 너무 중복이라서 하나를 전량 매도하여 한 종목을 추가 매수하였고, 70만 원 정도의 차익(15%)을 실현하였다. MTS에 나타나는 복잡한 정보 안에서(아직도 익숙하지 않음) 거래가 언제 결제되고, 예수금은 무엇이며, 계좌로 실제 돈이 들어오는 것은 D+2일째이고, 미국 등 해외 증시에만 상장된 ETF와 주식을 매수하려면 ISA 계좌로는 안 되고.... 이런 생기초를 익히기 시작하였다.

[미래에셋] ETF 투자는 처음이라 가이드북

그나마 오래 전에 개설하여 여유자금을 수시로 모으는 용도로 쓰던 CMA_RP 계좌가 있어서 다행이었다. 국내 주식을 거래하고 남은 현금이 이 계좌를 통해 자연스럽게 관리되면서, 해외 투자도 이어갈 수 있었다. 엊그제 국외 ETF에서는 아주 약간이지만 세후 19.68 달러의 현금 배당이 들어오기도 하였다.

사실 요즘 내가 벌이고 있는 일은 투자라고 하기도 부끄러운 수준이다. '자산 관리'를 뒤늦게 시작했다는 고백이 더욱 정확할 것이다. 산업을 분석하여 개별 종목을 고르는 일은 나와 잘 맞지 않는 것 같다. ETF와 채권을 이용한 분산 투자에 만족하며, 앞으로는 금리와 환율 같은 거시경제 지표를 조금 더 관심 있게 살펴보려 한다.

주식으로 돈을 번다는 것은 무슨 뜻일까? 내가 100원에 산 주식을 120원에 사겠다고 나서는 사람이 있어서 거래가 성사되었을 때 비로소 나에게 차익이 생긴다는 뜻이다. 한동안 나는 이것이 공평하지 않은 일이라고 생각했었다. 우리나라, 아니 세계 경제 전체가 성장하여 생겨난 부가가치가 주식시장을 통해 보다 넓게 공유될 수 있다고 이제는 믿고 싶다. 

주식 시장에서 나 같은 개인 투자자가 기관이나 세력을 이길 수는 없다고 생각한다. 하루에도 수십 번씩 바뀌는 시세에 일희일비하기보다는, 분산 투자한 자산을 믿고 꾸준히 보유하다가 필요할 때 가끔씩 리밸런싱을 하는 편이 지금의 나에게는 가장 마음이 편하다.

이 생소하고도 흥미로운 세계에 발을 들이게 해 준 J 선생에게도 감사의 뜻을 전한다.

Fluid Ardule, 케이스를 만들었다고 끝난 것이 아니었다

프로토타입 시절의 불안정하고 엉성한 배선을 정리하여 전용 인클로저 안에 넣었을 때 이제 Fluid Ardule의 개발은 거의 끝났다고 안일하게 생각했다. 그러나 최근 며칠 동안의 성능 개선 작업 내역을 돌이켜 보면 '이제부터 시작이다'라는 생각이 강하게 들기 시작하였다. 실제 악기처럼 매일 연주하고 음원 파일이나 인터넷 라디오를 재생하면서 과거에는 느끼지 못했던 불편함이 비로소 눈에 뜨이기 시작하였고, 그것을 하나씩 개선해 나가는 과정에서 Fluid Ardule은 단순한 DIY 장치를 넘어 '연주할 수 있는 악기'로 성장하기 시작했다.

나도 이제는 MIDI 장비로 탑을 쌓아 본다. 기성품보다 개조품 또는 자작품이 슬슬 많아지고 있다.

그 불편함은 결코 사소한 것이 아니었다. 처음에는 그 심각함을 깨닫지 못했을 뿐이다. 다시 말하여 개선을 하지 않고서는 도저히 다른 사람에게 소개하기 어려운 상태였다는 뜻이다. UI 개선과 같이 '고치면 편리하고, 그렇지 않으면 약간 불편한' 수준의 것이 결코 아니라, 근본적인 설계에 결함이 있음을 깨달은 것이다.

가상 아날로그 신시사이저인 Yoshimi에서  '글리치(glitch)'가 발생하는 원인이 TFT-LCD의 잦은 갱신 때문임을 지금까지 몰랐었다. 운영 스크립트를 통해 Yoshimi로 소리를 내는데 성공한 것에만 만족하고 있었을 뿐이다. 

다음으로는 4개 레이어로 구성된 콤비 음색을 로드한 뒤 키보드 컨트롤러를 연결하여 여러 노트를 동시에 연주했을 때 소리 발생이 돌연 멈추고 수 초 뒤에 저절로 다시 복구되는 현상을 해결해야 했다. 이는 FluidSynth의 폴리포니(polyphony, 동시발음) 수를 96으로 제한함으로써 해결할 수 있었다. 앞으로는 운영 스크립트 안에서 필요에 따라 폴리포니 수를 조정할 수 있도록 개선해 볼 계획이다. 

만약 Fluid Ardule 개발이 양산용 제품을 만들어내기 위한 기업의 프로젝트였다면, 상급자는 이렇게 물었을지도 모른다. 프로토타입을 케이스에 넣고 나서야 왜 중대한 문제를 발견하여 고치기 시작했느냐고. 6개월이 넘는 개발 기간 동안 충분히 파악하고 해결할 수 있었던 것 아니냐고.

“그동안 뭐 했어요?”

요즘 우리가 자주 듣는 말이다.

그러나 나는 이렇게 답하고 싶다.

“프로젝트가 그 단계까지 발전했기 때문에 지금의 문제가 보인 것입니다. 그 단계에 도달했기 때문에 비로소 문제점을 발견할 수 있었고, 그래서 이제야 해결할 수 있게 된 것입니다.”

이것이 바로 연구개발의 참모습이다.

Fluid Ardule, 화면을 새로 그리지 않는 것이 최고의 최적화였다

이 이미지는 TFT-LCD에 표시 중인 이미지를 파일로 저장하게 만드는 유틸리티('capture_fb1.py')를 사용하여 얻은 것이다.

Fluid Ardule의 개발을 하다 보면 예상했던 곳보다 전혀 엉뚱한 곳에서 병목을 만나는 경우가 있다. 최근 Yoshimi를 탑재하면서 이상한 현상이 나타났다. 같은 패치를 커맨드 라인의 Yoshimi에서 직접 실행하면 아무 문제가 없는데, Fluid Ardule 안에서만 간헐적으로 클릭 노이즈가 발생했다. ALSA 연결을 의심했고, aconnect 설정도 살펴봤으며, 실행 옵션도 하나씩 비교했다. 하지만 원인은 좀처럼 드러나지 않았다.

결국 의심을 거듭한 끝에 아주 단순한 실험을 해 보았다. TFT-LCD의 화면 갱신을 시험적으로 완전히 멈추어 보았다.

결과는 예상 밖이었다. Python 프로세스의 CPU 사용률은 약 50~60%에서 2% 수준으로 떨어졌고, Yoshimi의 글리치도 함께 사라졌다. 범인은 오디오 엔진이 아니라 UI였다.

생각해 보면 이는 당연한 결과였다. 일반적인 GUI 프로그램은 초당 수십 번 화면을 다시 그리는 것이 자연스럽지만, 악기는 다르다. 연주자가 버튼을 누르거나 노브를 돌리지 않는 동안에는 화면이 바뀔 이유가 거의 없다. 그렇다면 굳이 계속 프레임버퍼를 갱신할 필요도 없다.

그래서 Fluid Ardule의 UI 설계를 근본적으로 바꾸기로 했다.

이제 화면은 사용자 입력이 있을 때만 갱신한다. 버튼, 인코더, 메뉴 이동, 파라미터 변경과 같은 이벤트가 발생할 때만 TFT를 다시 그린다. CPU 온도나 Load와 같은 시스템 정보도 일정 주기로 갱신하지 않고, 필요할 때만 새로 읽어온다. 현재 예외는 실시간으로 변할 수 있는 MIDI 연결 상태 정도뿐이다.

설계를 변경하여 이벤트가 있을 때에만 화면을 갱신하도록 만들었더니 파이썬의 CPU 점유율이 13% 근처로 떨어졌다. 이는 엄청난 수준의 개선이다.

이러한 변경은 단순한 최적화가 아니다. Fluid Ardule의 설계 철학 자체를 바꾸는 일이다. 앞으로는 일반적인 데스크톱 애플리케이션이 아니라, 전원을 켜면 즉시 연주할 수 있는 전용 하드웨어 악기와 같은 동작을 목표로 하려고 한다.

이번 작업에서는 이와 함께 Media Player의 인터페이스도 다듬었고, 0바이트 yoshimi.config 파일이 시작 실패의 원인이 될 수 있다는 사실도 확인하여 복구 절차를 문서화했다. 또한 동일한 이벤트 기반 렌더링 정책을 앞으로 Combi 기능에도 적용하여, 다중 MIDI 처리에서도 안정성을 높여 나갈 계획이다.

새로운 기능을 하나 추가한 것은 아니다. 하지만 이번 변경은 지금까지의 개발 가운데 6월 17일의 ISR 적용과 더불어 가장 의미 있는 개선 중 하나였다고 생각한다. 화면을 덜 그리는 것이 오히려 더 좋은 악기를 만든다는 사실을 직접 확인했기 때문이다.