2026년 3월 29일 일요일

[Fluid Ardule] 최소 기능 구현판의 소개용 숏폼 동영상을 올리다

부팅과 더불어 자동으로 Salamander C5 Lite 피아노 사운드폰드가 로드되게 만든 Fluid Ardule 최소 기능 구현판의 소개용 숏폼 동영상을 만들어 올렸다. 사운드폰트의 변경(Salamander C5 ↔ Lite GeneralUser GS ↔ FluidR3_GM)은 키패드에서 수행할 수 있다.  


유튜브에 올린 동영상은 아래에 소개한다. 오디오 인터페이스를 Fluid Ardule의 사운드 출력용으로 연결해 놓았기 때문에 컴퓨터는 쓰지 않고 대신 헤드폰을 휴대폰에 대고 아주 '무성의하게' 녹음하였다. 편집 후 유튜브에 올리고 나니 아쉬움이 많이 남는다.


오디오 출력에는 USB 오디오 인터페이스를 이용하기 때문에 확장성이 좋고 헤드폰 출력도 거저 얻을 수 있으며, 기타나 마이크 등의 외부의 아날로그 오디오 신호를 믹싱하여 앰프로 출력하는 것도 가능하다. 그러나 USB 기기의 특성상 연결 즉시 인식에 약간의 시간이 걸린다. 

만약 다음과 같은 라즈베리 파이 전용 DAC hat("Raspberry Pi DAC Pro")을 이용한다면 장치 인식, 전원 문제, 부팅 속도 등에서 현저한 개선이 이루어질 수는 있겠다. 그러나 내가 지금 쓰는 Mackie Onyx Producer 2.2 오디오 인터페이스가 라즈베리파이 전용 DAC Hat보다 못할 이유는 전혀 없다. 게다가 DIN 5핀 MIDI 입출력 커넥터까지 붙어 있지 않은가. 이 기능을 Fluid Ardule에서 쓰도록 기능을 추가하려면 아직 한참 더 개발을 이어 나가야 하겠지만. 

라즈베리파이 DAC Pro(출처: 디바이스마트). 예전에는 IQaudio DAC Pro로 알려져 있었다. 이런 물건을 꽂으면 SPI TFT-LCD를 그 위에 꽂기가 어려울지도 모른다. TFT-LCD는 보조적인 정보 디스플레이로서 매우 쓸모가 있기 때문에 포기하고 싶지는 않다.

Fluid Ardule의 가장 취약한 점은 바로 라즈베리 파이 3B의 전원 커넥터이다. 케이스를 만들어서 내부에서 확실하게 고정하기 전까지는 계속 나를 불편하게 만들 것이다. 왜 마이크로 USB 커넥터는 이렇게 잘 빠지게 만든 것일까! 이 물건을 개발한 사람은 지옥에 가야 한다는...(링크) 그러나 개인이 집에서 DIY 하기가 좋다는 것은 함정이다.

마이크로USB 방식의 전원 커넥터가 헐거워져서 케이블을 건드리기만 해도 접촉이 나빠지고 잘 빠진다. 접착제로 붙여 버리고 싶다!

Fluid Ardule에는 무려 3 종류의 USB 주변기기가 쓰인다. 조작부에 해당하는 아두이노 우노(1602 LCD 키패드 실드 장착), 가장 핵심이 되는 오디오 인터페이스, 그리고 MIDI 키보드 컨트롤러. 전력 부족이 늘 걱정이 된다. 이따금씩 SSH 연결이 끊어지는 것도 혹시 전력 부족 때문이 아닌가 의심이 된다. 현재는 부팅과 더불어 systemd 서비스를 통해 자동으로 작동이 되는 상태이고, 개발 및 디버깅 목적으로만 SSH 접속을 요구하기 때문에 큰 문제는 없어 보인다. 그러나 보다 안정적인 작동을 위해 뭔가 대책을 세워야 한다. 유전원 USB 허브를 고려 중이지만 성능과 가격 양 측면을 모두 만족시키는 것은 잘 보이지 않는다. 결국은 전력 소모가 적고 라즈베이파이와 잘 붙는 전용 DAC hat을 선택하게 될지도 모른다.



2026년 3월 26일 목요일

[Fluid Ardule] 주변 부품 붙여 나가기

LED와 로터리 인코더를 아두이노 우노에 연결하였다. LED 점등용 전류 제한 저항은 처음에는 270옴을 사용하였으나 너무 밝아서 1K로 바꾸었다. 주변 기기의 인식 상황에 맞추어 적절하게 작동하도록 코드를 고쳤다. 멋진 케이스를 갖추지는 못했으나 제법 상용 사운드 모듈의 기능에 근접하고 있다.

이 DIY 기기의 장점은 '모듈화(modularity)'와 '확장성(expandability)'이다. 예를 들어 오디오 출력 장치는 고정되어 있지 않으며, 보유하고 있는 USB 오디오 인터페이스 중 리눅스에서 안정적으로 동작하는 class-compliant USB 기기를 적당히 골라서 쓰면 된다. 아직 테스트를 하지는 못했으나 오디오 인터페이스에 DIN MIDI 커넥터가 있으면 작동 가능할 것이다. 이러한 유연성은 리눅스 계열의 OS로 구동되는 라즈베리파이, 즉 작은 소형 범용 컴퓨터를 바탕으로 시스템을 구성했기 때문에 가능해졌다고 믿는다.

Fluid Ardule의 현재 시스템 구성. 주황색 점선으로 둘러싸인 영역이 Fluid Ardule의 코어에 해당한다.

코딩을 하면서 두 기기 간에 시리얼 통신을 하는 요령도 익히는 중이다. 예를 들어 정상적으로 연결되어 동작하는지를 주기적으로 확인하는 생존 신호인 heartbeat를 3초 주기로 보내는 것이다. 그러나 로그 파일에 이것까지 기록되면 너무 길어지므로 예외로 취급해야 한다.

다음 단기 목표는 사운드폰트 파일을 자유롭게 교체하는 기능을 넣는 것이다. 지금은 피아노 소리를 내는 사운드폰트가 자동으로 로드되게 만들어 두었다. 사운드폰트 교체, CC 제어, 사용자 프리셋 저장 및 로드 등 사운드 모듈이라면 당연히 추구해야 할 기능을 하나씩 넣어 나갈 것이다. 아두이노 우노와 라즈베리 파이 두 기기에서 각각 돌아가는 코드를 짜야 하고, 이는 시리얼 통신으로 서로의 상태를 정확히 파악하면서 제어할 수 있어야 한다.

코드를 통해 구현할 기능도 아직 많이 남았고, 케이스 제작에 들어가면 더욱 많은 고민을 해야 한다. 안정적으로 작동하게끔 양질의 전원을 사용하여 공급 계통을 확정하고, 각 주요 부품의 배치 또한 6개월에서 1년 정도의 기간에 걸쳐 점진적으로 달성해 나가게 될 것이다.

새로운 장난감인 Fluid Ardule 때문에 Nano Ardule MIDI Controller의 PCB 설계 마무리가 늦어지고 있다. 어차피 단일한 생태계를 즐기기 위해 만든 것이므로, 여러 강이 바다로 흐르듯 결국 한 곳에서 만나게 될 것이다.

이번 프로젝트는 아직 GitHub에 올리지 않았다. 서로 다른 하드웨어에서 돌아가는 한 짝의 프로그램을 짜야 함에도 불구하고 이제는 요령이 생겨서 파일명과 간단한 기록, 그리고 기억에 의존하여 느슨하게 버전을 관리하고 있는 상태이다. 그러나 진행 과정은 별도의 위키 사이트에 계속 기록하는 중이다.

물론 이런 방식이 지속 가능하지는 않으니, 필수 기능이 어느 정도 구현되면 GitHub에 공개할 생각이다.

2026년 3월 24일 화요일

[Fluid Ardule] 처음으로 건반을 연결하여 소리를 내다

Fluid Ardule 프로젝트 개요

Fluid Ardule은 2026년에 새롭게 시작한 DIY 프로젝트이다. 이 기기는 라즈베리파이 3B(소프트웨어 신시사이저 FluidSynth 설치)와 아두이노 우노를 결합한 음원 모듈에 해당한다. 아두이노 우노는 LCD와 버튼을 통해 상태 디스플레이 및 조작을 겸한다.

USB 기반 통신과 초기 구동

두 기기 사이에서 USB 포트를 통한 직렬 통신을 하면서 서로 정보를 주고받도록 하는 것이 첫 번째 목표였다. 기가비트, 스타링크 인터넷 시대에 9600~115200 bps의 직렬 통신이라니! 봉화대나 모르스 부호를 이용한 통신을 연상시킨다. 굳이 따지자면 봉화대도 광통신이다?

오디오 출력을 책임지는 USB 오디오 인터페이스와 USB MIDI 건반을 라즈베리파이에 연결과 동시에 정확히 인식하고, 준비가 갖추어졌을 때 다음 단계로 넘어가게 하는 코드를 짜느라 하루를 소비하였다. 라즈베리파이에서는 파이썬, 아두이노 우노에서는 C++을 사용한다.

USB 건반과 오디오 인터페이스가 연결된 상태에서 전원을 넣은 뒤 건반을 누르면 소리가 난다. 현재는 피아노 사운드인 Salamander C5 Light 사운드폰트(.sf2)를 기본으로 로드하도록 설정하였다.

아직은 테스트 단계이기 때문에 라즈베리파이에 SSH로 접속한 뒤 파이썬 스크립트를 실행하여 기동한다. 라즈베리파이가 시리얼 포트를 열라는 신호를 보내면, 먼저 전원이 들어와 있던 아두이노 우노에서는 리셋이 이루어진다. 최초 전원 투입에 따른 부팅인지, 또는 라즈베리파이의 요청에 의한 리셋인지를 구별하여 LCD에 적절한 메시지가 표시되도록 만드는 것이 향후 과제이다.

또한 라즈베리파이의 GPIO 단자에 USB-to-UART 케이블을 연결하여 PC에서 접속하면 네트워크 관련 서비스를 비활성화하여 시스템을 더욱 경량화할 수 있다.

Python script execution
파이썬 스크립트 실행 화면

아두이노 입력 구조와 설계 인사이트

아두이노 우노에는 1602 LCD 모듈과 키패드가 일체화된 실드(DFR0009 유사품)가 장착되어 있다. 5개의 버튼 스위치를 아날로그 핀 하나(A0)로 제어할 수 있다는 점은 매우 인상적이었다. 기존에는 각각 디지털 핀이 필요하다고 생각했기 때문이다.

물론 이 방식은 동시에 두 버튼을 누르는 입력을 처리할 수 없다는 한계가 있지만, 모드 전환과 같은 단순한 인터페이스에는 매우 적합하다. 이를 미리 알았더라면 이전에 제작한 Nano Ardule MIDI controller 설계 과정에서 훨씬 간결한 회로 구성이 가능했을 것이다. 현재 해당 회로는 KiCad에서 PCB 설계를 절반 정도 진행한 상태이다.

키패드 외에는 A2 핀에 가변저항을 연결하여 볼륨(MIDI CC #7)을 조절할 수 있도록 구성하였다. 향후에는 로터리 인코더와 여러 개의 LED를 추가할 계획이다.

향후 개발 계획

  • 디버깅 로그 기록 기능
  • 다양한 사운드폰트 로드 (예: FluidR3_GM.sf2)
  • 코러스 및 리버브 제어
  • USB MIDI 인터페이스 자동 인식
  • MIDI 라우팅 기능
  • TFT LCD 상태 표시

하드웨어 확장 및 운용 계획

보유 중인 Roland SoundCanvas SC-D70과 Mackie Onyx Producer 2-2는 리눅스에서 별도의 드라이버 없이 동작하는 class-compliant 장치이며 MIDI 인터페이스 기능도 제공한다. 이 장치를 활용하여 FluidSynth 출력과 함께 DIN MIDI 입출력까지 확장 가능한지 확인할 것이다.

현재는 라즈베리파이에서 파이썬 스크립트를 수동 실행하는 방식이지만, 시스템이 안정화되면 systemd 서비스로 등록하여 부팅 시 자동 실행되도록 구성할 예정이다.

2026년 3월 19일 목요일

자작 진공관 앰프의 전원 스위치 교체하기

자작 43 power pentode SE amplifier의 전원 스위치 고장과 관련한 글은 지난주에 쓴 일이 있다(링크). 납땜이 아닌 커넥터 체결 방식으로 바꾸기로 하고 알리익스프레스에서 부품을 주문하여 어제 받았다. 점심 시간을 이용하여 부품 교체를 완료하였다.


사무실 책상 앞에서 조용히 듣기에 이보다 좋은 소출력 앰프가 없다. 요즘 저렴한 블루투스 앰프가 많지만, 빨갛게 달아오른 진공관의 히터를 눈으로 보는 재미를 무엇이 대신할 수 있을까?


커넥터 작업 전용 크림핑 툴을 살 때에는 '자주 쓰지도 않을 공구를 사는게 옳은가'하고 항상 고민을 한다. 수공구 중에서는 가격이 꽤 나가기 때문이다. 그러나 깔끔하게 마무리된 작업 결과를 보면 만족도는 그 이상이다. 확실히 체결되고, 나중에 수리하기에도 좋고. 이는 아두이노 자작에서도 마찬가지.

부서진 식탁용 의자도 고쳐야 하는데... 여러 DIY 중 제일 하기 싫은 것이 목공과 도색이다. 왜? 잘 못하니까! 잘 하지 못하니까 자주 하지 않게 되고, 몸이 기억하지 못한다. 아주 드물게 냄비밥을 지으면서 꽤 잘 되었다고 만족하지만 결코 기억에 남지 않는 것과 비슷하다. 

2026년 3월 18일 수요일

라즈베리파이 3B에서 3.5인치 TFT 터치 LCD 작동시키기

라즈베리파이(이하 Pi로 표기) 3B에서 Volumio를 구동하던 시절, 3.5인치 TFT LCD(480x320)를 달아서 조작용으로 쓰려고 노력하던 때가 있었다. 휴대폰 앱으로 제어하면 되지만 반응이 늦거나 연결이 잘 되지 않는 문제가 종종 발생하기 때문이다. Pi의 공식 디스플레이는 아마 HDMI로 연결되는 7인치 LCD일 것이다. Pi의 GPIO 소켓에 그대로 꽂아서 쓸 수 있는 SPI(Serial Peripheral Interface) 방식의 3.5인치 중국산 TFT LCD는 구동시키기가 매우 까다로운 것으로 유명하다. 작년 여름에 온갖 시도를 다 해 보았으나 터치 좌표를 도저히 맞출 수가 없어서 포기하고 말았다. 관련 기록은 여기에 있다.

음원 파일 재생기로 쓰던 Pi는 2026년에 접어들면서 사운드폰트를 이용하는 소프트웨어 신시사이저인 FluidSynth 구동용 기기, 곧 ‘Fluid Ardule(= Fluidule)’로 변모하고 있다. 처음에는 사운드 캔버스를 본뜬 Fluid Canvas라는 이름도 고안했으나, 지금은 Fluid Ardule 쪽으로 기울고 있다. 

조작은 USB-serial로 연결한 아두이노(우노)에서 버튼과 인코더를 사용하여 실시할 예정이다. 조작을 위한 디스플레이는 아두이노에 연결된 1602 LCD가 될 것이다. 그러나 여기에서 보이는 정보량은 너무나 적다. 그래서 상태 표시용으로 Pi에 3.5인치 LCD를 다시 달아보기로 하였다. 터치 입력 기능은 일절 사용하지 않고, 단지 1초 정도의 간격으로 작동 상태를 보여주는 것으로 기능을 제한하였다.

이것 역시 쉽지 않았다. Raspberry Pi OS는 계속 발전하는 반면, 중국산 3.5인치 TFT LCD에 대한 드라이버 지원은 예전과 같지 않기 때문이다. LCD-show라는 드라이버 스크립트 모음이 꽤 쓸 만한 것으로 알려져 있고 작년에도 이를 사용했었다. 그러나 시스템에 뭔가 ‘침습적’인 흔적을 남기기 때문에 커널 업데이트 등에 대응하기 어렵다고 한다. 이미지나 동영상을 빠르게 재생할 것이 아니기 때문에 LCD-show를 쓰지 않는 단순한 방법을 알아본 끝에 겨우 성공하였다. 다음은 ChatGPT로 만든 부팅용 스플래시 이미지를 표시해 본 것이다. 전체 과정은 별도 위키 문서인 Raspberry Pi OS Installation and Optimization에 정리하였다.

Fluid Ardule boot splash image
액체 방울 속의 MIDI 커넥터. 원본 이미지 링크.

MIDI 주변기기를 Fluid Ardule에 연결하여 사용하거나 오디오 파일을 재생하는 기본 테스트는 전부 마친 상태이다. 아두이노를 이용한 조작반이 완성되면, Fluid Ardule에서 불필요한 기능을 없애야 한다. 그래야 부팅 시간도 빨라지고 FluidSynth 작동도 원활해질 것이기 때문이다. 목표 부팅 시간은 10초. 불가능하지 않다고 하니 시도할 가치는 충분하다.

아직은 Fluid Ardule에 키보드와 HDMI 모니터를 연결하여 직접 명령어를 입력해야 한다. HDMI 기능을 무력화시키면 Wi-Fi를 통한 SSH 접속을 해야 한다. 만약 네트워킹 기능까지 죽인다면 시리얼-USB 통신을 해야 한다(맞는 케이블 필요; 윈도우측의 드라이버 호환성 때문에 FTDI나 CP210x 칩 사용 제품 추천). 시스템 자원 소모를 극도로 줄인 통신 방법이라고 할 수 있다. 그런데 TFT LCD가 모든 GPIO 핀을 가리고 있어서 통신에 필요한 RX(10)/TX(8) 핀에 접근하기가 너무 나쁘다. 실제로 TFT LCD의 구동에 필요한 핀은 몇 개 되지 않지만, 2x13개의 핀 자리를 차지하고 있는 것이다.

GPIO 1-26 pins blocked by TFT LCD header socket
LCD 모듈의 핀헤더 소켓이 GPIO 1~26번 핀을 가리고 있다. 아래 사진에서 맨 오른쪽 핀이 2번이며, 1번은 안쪽에 있다.

다음 이미지와 같은 아이디어 상품도 있지만 가격이 꽤 비싸다. 케이블로 연결하는 GPIO expansion board라는 것도 존재한다.

GPIO extender product
그림 출처: Geekworm

가장 간단한 방법은 Pi 보드 뒷면에서 납땜을 하여 필요한 선 세 가닥을 따는 것이다. 아두이노 우노에서도 이런 짓을 하더니(관련 글 링크), 드디어 라즈베리 파이까지 손을 대게 되었다.


2026년 3월 19일 업데이트

라즈베리파이 3B에서 사운드를 설정하고 FluidSynth를 활용하는 방법을 별도의 위키 문서인 Raspberry Pi OS Installatio and Optimization에서 작성해 나가고 있다. 앞으로 아두이노 우노를 이용한 조작반 제작과 펌웨어 설계, 그리고 라즈베리파이의 부팅 속도 향상 등 할 일이 많다. 케이스는 또 어떻게 할 것인가?

이 작은 부품 하나가 많은 상상력과 영감을 불러 일으킨다.



2026년 3월 15일 일요일

주말 부안 나들이 - 내소사, 슬지네 제빵소, 채석강

능가산 내소사에는 사운드 디렉터가 일하고 있음에 틀림이 없다. 그렇지 않고서야 고요한 산사의 분위기에 이렇게 절묘하게 어우러지는 두 갈래의 소리를 BMG으로 '믹스'해 넣을 수는 없을 것이기 때문이다. 다음 동영상에서 파트 1(지장암)은 고요한 풍경 소리의 하모니, 대략 9초부터 나타나는 파트 2는 소망의 왁자지껄한 아우성에 해당한다.


일주문으로 들어서서 전나무길을 따라 걷다가 길 오른편으로 '지장암'이라 써 있는 안내판을 발견하였다. 초입에는 누군가 멋들어지게 지은 한옥이 있었고, 산으로 오르는 길목에는 작은 대나무 숲이 있었다. 지장암까지 올라가 보기로 하였다. 드물게 찾아주는 이를 반기듯 대나무숲이 끝나는 언덕에는 홍매화 한 그루가 예쁘게 꽃을 피우고 있었다. 

올라가 보니 최근에 지은 건물들이지만 주변에 마치 작은 정원을 꾸민 것 같이 아기자기하고 아름다운 모습이었다. 주 전각은 최근에 지어진 서래선림. 일반적인 사찰 전각이 아니라 수행 공간이다. 찾는 이도 거의 없었고, 아름다운 풍경 소리를 들으며 아내와 나는 산사의 고요함을 마음껏 누렸다.




이곳의 이름은 '소리정'. 바로 곁에서 바람에 흔들리는 청아한 풍경 소리를 들으라는 뜻이렸다.

다시 전나무길로 들어서 내소사 법당을 찾아간다. 천왕문을 지나 봉래루로 접어드려는데 '다다다닥~' 독특한 소리의 집합이 들려온다. 도자기로 만든 작은 풍경 모양의 것에 소원을 적은 나무패를 달아서 나무와 건물 주변에 잔뜩 걸어 놓은 것이었다. 오, 이는 누구의 아이디어란 말인가. 연주회 직전, 자리에 앉은 오케스트라 단원들이 지휘자가 나오기를 기다리는 짧은 시간 동안 저마다 막바지 연습을 하면서 내는 기대감 넘치는 불협화음을 연상시켰다.


봉래루.


내소사 대웅보전은 보물 제291호이다. 내부의 우물천장과 조각은 빛이 많이 바랬지만 무척 화려하다.

 

기록을 찾아보니 대략 2년에 한번 꼴로 부안을 찾았었다. 그럴 때마다 내소사의 새로운 아름다움을 발견하는 것 같다. 



주차장에서 여유롭게 담배를 피우다가 국립공원 관리원에게 적발되는 사람을 보았다. 아무리 전자담배라 해도 흡연구역을 이용해야지! 액상형 전자담배를 포함한 모든 종류의 니코틴 함유 제품을 담배로 규정하는 담배사업법 개정안은 4월 24일부터 시행한다고 하였다. 계도 수준인 건지 실제로 '딱지'를 발급한 것인지는 잘 모르겠으나. 참고로 국립공원은 전 구역이 흡연 금지 구역이다. 주차장도 마찬가지.

다음으로 찾은 곳은 곰소 염전 곁의 슬지네 제빵소. 이 지역의 명소이고 인터넷을 통해서 꽤 많이 알려졌다고 한다. 떡인지 찐빵인지 구별이 어려운 찰진 커다란 빵에 크림이나 콩 종류가 가득한 빵의 질감과 맛이 독특했다. 우리밀을 100% 사용하고 지역에서 나는 천일염을 사용한 가염버터를 사용한다고 하였다. 

인스타그램 게시용으로 잘 어울릴 인테리어와 주변 풍경, 그리고 이야기를 담고 있는 것은 좋으나 내외부 치장과 '서사'가 좀 과대하다는 느낌이 들었다. 전통과 상생을 강조한 것은 좋으나 이 빵집이 원래부터 이 염전 근처에 있었던 것은 아니었고, 이러한 사실은 나중에 인터넷을 검색해 보고서야 알게 되었으니 말이다. 물론 가업을 잇기 위한 현 대표의 전공을 접목한 노력이 들어간 것임은 부인할 수 없겠으나... 잘못하면 지역 빵집과 자본의 콜라보라고 오해하기 쉬울 것 같았다.



이곳이 곰소 염전이다.





부안, 즉 변산반도국립공원에 왔다면 채석강을 들르지 않을 수 없다. 변산반도의 서남쪽 해안을 따라 시계방향으로 달린다. 바다 건너 고창군이 손에 잡힐 듯 보인다. 채석강에 이르러서는 물때를 잘 만난 덕분에 짠 바다 내음을 맡으며 바닷가 층암절벽을 따라 걸으며 주변 풍광을 마음껏 감상할 수 있었다.



마치 수천 권의 책을 쌓아 놓은 것 같은 채석강은 약 7천만년 전 백악기에 쌓인 퇴적 지층이라고 한다. 안동 하회마을을 내려다볼 수 있는 부용대(2025년 3월 여행 기록 링크) 또한 독특한 최적 지층이다.

이번 주말 여행은 아내의 특별한 생일을 기념하기 위함이었다. 낙조를 감상하면서 새만금 방조제를 달려 군산을 거치거나, 혹은 전주에 들러서 저녁식사를 한다면 더욱 완벽한 일일 여행 코스가 되었으리라. 

 

2026년 3월 12일 목요일

방어적 글쓰기(커뮤니케이션)의 몇 가지 기술

방어는 과거에 받은 공격의 기억에서 온다. 그것은 생존 본능이다. 특허 명세서나 법원 판결문처럼 극도로 방어적인 문서들도 결국 같은 원리에서 만들어진다.

글쓰기는 정보나 감정을 전달하는 것이 원래 목적이다. 조직에서 만들어 내는 많은 문서는 겉으로는 정보를 전달하는 것 같지만, 결국은 책임을 관리하기 위한 것이다. 이런 목적에서 안전하게 글을 쓰는 방식을 방어적 글쓰기라고 불러 보자.  '세 시간 내로 보내 주세요'와 같은 갑(甲)의 요청에 대응하는 것은 글쓰기가 아니라 작성된 글을 전달하는 기술에 해당하지만, 이것도 포함하여 논하기로 한다.

첫 번째 기술은 매우 널리 통용되는 것으로, 제출 시한에 임박해서 보내기이다. 표면적으로는 작성에 공을 들이느라 이렇게 되었다고 변명하지만, 대부분의 경우 다 만들어 놓고도 일부러 늦게(그러나 기한 내에) 보내는 것이다. 문서를 너무 일찍 보내면 검토와 질문이 이어질 가능성이 매우 높기 때문이다.

두 번째 기술은 표현을 적절히 모호하게 만드는 것이다. 상세하거나 전문적인 용어가 들어가면 추가 설명을 요청하거나 꼬투리를 잡히기 쉽다. "모든 여건을 감안해 본다면", "일반적으로", "필요하다면"과 같은 표현은 문장도 온건하게 만들고 책임의 범위도 흐려진다.

세 번째 기술은 서론을 길게 만드는 것이다. 본론에 들어가기 전 긴 배경 설명이 들어가면 읽는 사람은 핵심 메시지를 잡아채서 논쟁하기 어려워진다. 결론을 가장 나중에 말하는 우리말의 특성과 가장 잘 어우러지는 글쓰기 기법이다. 이 기술은 글이 아니라 프레젠테이션에서도 써먹을 수 있다. 그러나 너무 노골적으로 서론을 길게 끌면, '결론부터 말해봐요'라는 공격에 직면할 수 있다.

글을 요청하는 갑(甲)은 이런 기술을 구사하기도 한다. 원래 이틀 뒤에 받아도 충분한 글을 일부러 촉박하게 내일까지 달라고 요청한다. 이틀 후에 제출해도 된다는 것은 물론 철저히 숨긴다. 을(乙)이 애를 먹고 있음을 너무나 뻔하다. 이윽고 내일이 되었다. 갑은 마감 직전에 이렇게 알린다. "힘드세요? 그러면 시간 하루 더 드릴께요". 을은 갑이 어렵사리 융통성을 발휘해 준 것으로 착각하고 오히려 고마워한다.

을에게 마감일을 어떻게 통보할까? 금요일 퇴근 전? 월요일 출근 직전? 이를 결정하는 데에도 치열한 눈치작전이 벌어지고, 그 결과에 따라 을의 주말은 평온한 휴식이 될 수도 있고 초과 근무가 될 수도 있다. 주가에 영향을 미칠 만한 좋지 않은 뉴스를 금요일 오후에 내보내는 것('Friday afternoon news dump'), 인사발령을 금요일 오후에 내는 것... 다 이유가 있다. 방어적 글쓰기와 함께 엮어서 방어적 커뮤니케이션 전술이라고 불러도 되겠다.

전형적인 방어적 글쓰기 사례는 뭐가 있을까? 보험 약관, 특허 명세서, 법원 판결문, 감사 대응 보고서, 기업의 리스크 공시, 의료 동의서/임상시험 설명문, 계약서 등.

이러한 기술을 너무나 잘 알고 있으며 업무 중 매우 이를 적절하게 구사하고 있는 당신은? 자랑스러워하지 말라. 조직 혁신의 측면에서는 매우 어두운 곳에 속한 사람일지도 모른다.

2026년 3월 11일 수요일

자작 43 power pentode 진공관 앰프의 망가진 전원 스위치 관련 정보 알아보기

자작 43 power pentode SE amplifier의 망가진 전원 스위치의 작동 현황 동영상을 살펴보자. 매일 작동하지도 않는 조건에서 겨우 5~6년 정도 사용했는데 벌써 망가진다니 몹시 실망스럽다. 



패널에 뚫은 스위치 고정용 구멍은 원형이었나, 혹은 사각형이었나? 상판 설계 당시 LibreCAD로 그렸던 도면을 찾아서 살펴보았다. 직경 20.3mm의 구멍을 그린 것으로 보아 직경 20mm의 스위치를 썼던 것으로 여겨진다. 이런 종류의 램프형 스위치(원형)는 매우 구하기 쉽다. 


2020년에 이맘때에 그린 도면에는 직경 20.3mm의 구멍을 뚫어서 전원 스위치를 고정했었다. 


사실 보다 정확하게는 다음과 같이 가공을 했어야 한다. 원주 양쪽에 사각 홈을 파도록 도면을 그리려면 조금 더 성가시다.

자료 원본 출처는 여기.

교체의 편의성을 생각한다면 전원 스위치의 단자에 전선을 납땜하는 것보다 납작한 모양의 압착형 커넥터를 쓰는 것이 더 나을 것이다. 한국에서는 흔히 PG (암)단자라고 하는데 정식 영문 명칭은 스페이드(spade, 날이 넓적한 삽) 단자라고 하는데, 실제 세계에서는 여기에 물리는 male 단자가 삽 모양에 더 가깝다.

절연체의 색깔은 연결에 사용할 전선의 굵기를 나타낸다.


일반적인 전원 스위치의 단자에 맞는  PG 단자의 규격(폭)은 4.8mm인 것으로 파악되었다. 오늘도 알리익스프레스에서 약간의 쇼핑을 해야 되겠다.

2026년 3월 10일 화요일

시름이 깊어질수록 회로도의 완성도는 높아지고...

오늘의 (Nano Ardule for) FluidCanvas의 회로도는 더욱 완성도가 높아졌다. 이를 가능하게 만드는 추진력은 업무 스트레스! 회로 설계를 마친 뒤 심야 달리기까지 하고 오면 머리가 맑아지고 선한 생각으로 가득 차는 것 같다.


어제까지는 패널용 MIDI IN/OUT 커넥터(DIN-5, female)를 쓸 생각이었다. 그러려면 기판에는 별도의 커넥터가 필요하다. 하지만 PCB에 직접 고정하는 DIN-5(180도) 커넥터를 쓰면 제작이 훨씬 쉽지 않겠는가? 대신 기판 면적은 훨씬 많이 차지하는 부작용은 감수해야 한다. 아두이노 나노의 RX/TX 핀과 MIDI IN/OUT 회로를 잇고 끊을 때에도 스위치가 아니라 3핀 헤더와 점퍼션트를 쓰기로 하였다. 단순한 것이 최고다. 회로도를 수정하고 전기적 연결이 완전한지를 알아보기 위해 Electrical Rules Check를 마쳤다. 

그러나 KiCad 기본 라이브러리에는 PCB용 DIN-5 커넥터(horizontal)의 부품 심벌은 있지만 footprint가 없다. 현재 기본 배포되는 것은 DIN41612 커넥터의 그것만 포함한다. 인터넷에서 검색을 통해 찾은 커스텀 풋프린트는 기판에 수직으로 고정하게 만든 것이 전부라서 별 소용이 없었다. KiCad 포럼에서는 mini DIN-3에서 DIN-8 커넥터의 풋프린트와 3D 모델을 만들어 공개한 사람도 있었다(링크).

검색을 거듭한 결과 DIN5_MIDI.kicad_mod라는 파일을 발견하였다. 정말 고마운 자료이다. 이것을 적절히 수정하면 될 것이다. 풋프린트는 top view임을 잊지 않는다면 custom footprint를 만들 때 치명적인 실수를 줄이게 될 것이다.

어두운 바탕에 찍힌 점들... LibreCAD에서 익숙하게 보던 화면이다.

위 풋프린트 그림에는 서로 다른 색깔로 표시된 세 층의 레이어가 보인다. 두꺼운 빨간색 도넛으로 표현된 것은 바로 구리로 만들어진 패턴에 해당하는 레이어다. 바로 여기에 부품의 다리가 납땜되는데, 윗면인 F.Cu와 아랫면인 B.Cu가 있다. 흰 선은 부품의 외곽선에 해당하는 실크스크린 레이어(F.SilkS)로서 PCB 위에 인쇄된다. 가장 바깥쪽의 보라색 선은 부품 배치 공간을 규정하는 레이어인 F.CrtYd(courtyard)이다. 여기에서는 정확한 부품 외형에 해당하는 패브리케이션 레이어(F.Fab)가 생략되었다.

다음의 사례는 기본 라이브러리에서 고른 직경 3mm LED의 풋프린트이다. 회색으로 표현된 F.Fab이 보인다.



위에서 소개한 DIN5_MIDI.kicad_mod를 그대로 사용할 수는 없다. 부품마다 외형 치수가 조금씩 다르기 때문이다. 따라서 AliExpress에서 실물 부품을 먼저 주문하였다. 이를 버니어 캘리퍼스로 정밀하게 측정한 뒤 DIN5_MIDI.kicad_mod를 수정하면 된다. KiCad 튜토리얼에서 Custom Symbol과 Footprint를 생성하고 수정하는 법을 소개하고 있다. 그것도 번거로우면 부품 도면을 ChatGPT에 밀어 넣은 뒤 파일을 만들어달라고 해 보면 된다.


반신반의하면서 SparkFun Electronics에서 제공하는 데이터시트(PDF)를 업로드해 보았다. 파일에서 필요한 부분만 잘라내어 다각도로 판단하며 해석하는 것도 인공지능의 몫이다. 도면의 레이아웃을 이해하는 데 한참의 시간을 소비하였다. 약 5분 20초 후 생성된 결과물을 확인해 보자.


이 풋프린트는 업로드하신 4UCON 도면의 Recommended P.C.B. Layout (Top View)를 기준으로, 7개 홀 위치를 반영하여 만들었습니다. 핀 좌표는 도면에 제시된 2.8 mm, 12.5 mm, 15 mm, 세로 10 mm / 14.6 mm 치수를 사용했고, 드릴은 7ר1.5 mm로 설정했습니다.

참고로 넣어 둔 항목은 다음과 같습니다.

  • 패드 번호: 1~5, 접지 셸은 E
  • 레이어: F.SilkS, F.Fab, F.CrtYd
  • 외곽선은 도면의 본체 치수를 바탕으로 한 단순화된 외형

주의할 점은 다음과 같습니다.

  • 이 파일은 홀 위치 중심의 실사용 풋프린트로는 바로 써볼 수 있지만,
  • 실크 및 외곽 형상은 도면 해상도 한계로 인해 일부를 단순화했습니다.
  • 실제 구매한 부품과 100% 맞추려면, 부품 실측 후 실크와 courtyard를 한 번 더 다듬는 것이 안전합니다.

원하시면 다음 단계로 바로 이어서 “패널 전면 기준으로 보드 엣지 정렬까지 고려한 버전” 또는 “DIN-5_MIDI_THT_horizontal.kicad_mod” 같은 원하는 파일명 버전
으로 다시 정리해 드릴게요.

ChatGPT가 부품 데이터시트를 이용하여 생성한 KiCad 풋프린트 파일.

정말 놀랍다. 이를 바탕으로 실측을 한 뒤에 '핀 2와 3의 간격을 1mm 더 벌려 줘'라고 지시해도 될 것이다. 

회로도는 마무리하였지만 실제 보드 아웃라인을 만들고 부품을 배치하여 라우팅을 한 뒤 DRC(Design Rule Check)까지 거쳐서 PCB 설계를 완성하려면 더 많은 공을 들여야 한다. 오늘 주문한 커넥터가 어서 배송되어 측정을 거쳐 정확한 수치를 얻은 뒤 PCB 설계를 마치게 되기를 기대해 본다.  

PubMed에서 시작되는 힘 — 데이터 리포지터리의 진짜 교훈

생명과학 데이터 인프라를 이야기할 때 많은 사람은 먼저 데이터의 규모를 떠올린다. 몇 PB의 데이터를 저장하고 있는가, 몇 개의 데이터셋이 등록되어 있는가 같은 지표가 흔히 등장한다. 그러나 세계에서 가장 영향력 있는 생명과학 정보 인프라를 운영하는 NCBI (National Center for Biotechnology Information)의 사례를 보면, 데이터의 양만으로는 그 성공을 설명하기 어렵다.

NCBI의 진짜 힘은 데이터의 규모가 아니라 지식 접근 구조에 있다. 그리고 그 구조의 출발점은 바로 PubMed이다.



생명과학 연구자는 거의 예외 없이 PubMed에서 탐색을 시작한다. 새로운 연구 주제를 찾을 때도, 특정 유전자나 질병에 대한 정보를 확인할 때도, 가장 먼저 찾는 것은 논문이다. PubMed에서 논문을 검색하고, 논문을 읽다가 관련 유전자나 데이터셋을 확인하면 자연스럽게 NCBI의 데이터베이스로 이동하게 된다.

이 과정은 매우 자연스럽게 이루어진다. 논문 페이지에는 관련 데이터로 연결되는 링크가 이미 준비되어 있기 때문이다. 그 결과 연구자는 다음과 같은 흐름을 경험하게 된다.

논문 → 데이터 → 분석

이 단순한 흐름이 바로 NCBI 시스템의 핵심이다. 논문을 읽다가 클릭 몇 번으로 서열 데이터나 발현 데이터로 이동할 수 있고, 다시 분석 도구로 이어질 수 있다. NCBI는 데이터를 단순히 저장하는 것이 아니라 논문과 데이터를 연결하는 지식 네트워크를 설계하였다.

많은 데이터 리포지터리가 간과하는 부분이 바로 이 지점이다. 데이터 플랫폼을 구축할 때 흔히 강조되는 것은 데이터의 수와 저장 용량이다. 그러나 연구자의 실제 행동을 생각해 보면, 연구자는 데이터베이스에서 출발하지 않는다. 연구자는 항상 논문에서 출발한다.

따라서 데이터 리포지터리가 연구 생태계에서 의미를 가지려면 데이터 자체보다 데이터에 도달하는 경로가 중요하다.

K-BDS에 주는 정책적 시사점

이 문제는 국내 바이오 데이터 정책에서도 생각해 볼 만하다. Korea BioData Station (K-BDS) 같은 데이터 플랫폼의 성과는 종종 다음과 같은 지표로 평가된다.

  • 등록된 데이터셋 수
  • 저장 용량
  • 데이터 업로드 건수
  • K-BDS에 데이터를 등록하여 그 accession number를 인용했거나, 또는 K-BDS에 이미 등록된 데이터를 재활용하여 출판한 논문의 수(data announcement 논문도 포함할 수 있으나 임팩트는 다소 낮게 평가된다)

하지만 이러한 지표만으로는 데이터 인프라의 실제 가치를 충분히 설명하기 어렵다.

데이터가 연구 생태계에서 실제로 사용되기 위해서는 다음과 같은 조건이 필요하다.

  • 연구자가 데이터를 쉽게 발견할 수 있어야 한다
  • 데이터가 연구 논문과 연결되어 있어야 한다
  • 데이터가 분석 도구와 연결되어 있어야 한다

즉 데이터 플랫폼의 핵심은 저장 공간이 아니라 지식 접근 구조이다.

NCBI가 보여주는 교훈은 명확하다. 데이터 인프라는 단순한 데이터 저장소가 아니라 연구자가 지식에 접근하는 경로를 설계하는 시스템이다. PubMed는 그 입구 역할을 하며, 다양한 데이터베이스는 그 내부 구조를 구성한다.

결국 NCBI의 성공은 데이터의 양이 아니라 논문을 중심으로 한 지식 인덱스 구조에서 비롯된다.

데이터 정책을 논할 때 종종 잊히는 사실이 하나 있다.

데이터는 모은다고 해서 자동으로 활용되지 않는다.

데이터가 작동하려면 연구자가 그것을 발견할 수 있어야 하고, 논문과 연결되어 있어야 하며, 분석으로 이어질 수 있어야 한다.

NCBI는 그 구조를 만들어 냈다.

그리고 그 모든 것은 PubMed에서 시작된다.

AI 시대가 도래함으로써 연구자가 직접 논문을 찾고 데이터를 (재)분석하는 수고를 덜게 되었고, 모든 리포지토리는 보유 데이터를 얼마나 많이 AI-ready 형태로 가공하여 제공하고 있는가로 평가를 받게 될 것 같다. 특히 정부의 지원으로 운영되는 데이터 인프라의 경우 그러한 압박감은 더욱 심하다. 도대체 언제부터 데이터 인프라의 가장 중요한 목적이 AI에게 먹이를 제공하는 것이 되었는가?

그러나 이 질문에는 신중하게 답변해야 한다. 데이터 리포지터리의 역할은 AI 학습용 데이터 공급자로 축소되어서는 안 되기 때문이다. AI 모델은 데이터를 소비하지만, 데이터의 의미와 맥락은 여전히 연구 공동체 속에서 형성된다. 논문, 실험 설계, 데이터 생성 과정, 데이터 해석의 논리 등은 데이터 파일만으로 대체되기 어렵다.

다시 말해서 AI 시대에도 여전히 중요한 것은 지식 생태계의 구조이다. 'AI 학습에 필요한 데이터와 컴퓨팅 자원을 확보하는 것이 무엇보다도 가장 시급해'  'AI가 이제 연구도 알아서 해 주니까 나는 연구 소비자처럼 이를 이용만 하겠어' 이런 주장과 논리 속에서 중요한 것을 잃어서는 안 된다.

데이터는 AI가 읽을 수 있어야 하지만, 지식은 여전히 연구 공동체 안에서 만들어지기 때문이다.


이 글은 정해영의 아이디어를 바탕으로 AI(ChatGPT)의 도움을 받아 작성되었습니다. 본 텍스트는 Creative Commons Attribution 4.0 International(CC BY 4.0)라이선스로 공개됩니다. 출처를 표시하는 조건으로 누구나 자유롭게 이용·수정·재배포할 수 있습니다. 정확성에 대한 보증이나 법적 책임은 제공되지 않습니다.

2026년 3월 8일 일요일

KiCad로 그린 첫 회로도

KiCAD가 아니라 KiCad라고 쓰는 것이 관행인 것 같다. KiCad는 전자회로 및 PCB 설계에 특화된 오픈소스 EDA(Electronic Design Automation)이다. 공식 웹사이트는 https://www.kicad.org/.

KiCad와 같은 종류의 프로그램은 PCB를 설계하여 주문하려면 피할 수 없는 선택이다. LTspiceFritzing에 이어서 드디어 오늘을 기하여 KiCad에 입문하게 되었다. LibreCAD도 약간은 다룰 줄 안다. 취미 "메이커"가 알아야 하는 필수 소프트웨어를 조금씩은 다 경험하게 된 셈이다. 이러다가 3D 프린팅 도면까지 만들게 되는 것은 아닌지 모르겠다.

페놀 만능기판에 배선 실수와 납땜 불량을 감수하고 얼기설기 만들었던 Nano Ardule을 올해에는 PCB에 옮겨 보고자 ChatGPT에게 step-by-step tutorial을 요청한 뒤 이를 따라서 일단 회로도부터 만들어 보았다. NET LABEL의 개념을 제대로 이해하고 커넥터 배치에 신경을 써야 한다. 특히 아두이노 관련 PCB 설계에서는 커넥터 위치 결정이 절반 이상을 차지한다고 한다. 회로도 설계 단계에서는 일단 Conn_01x05과 같이 1-row의 단순한 것으로 그려 놓았지만, 조만간 어떤 커넥터를 써야 할지 결정을 해야 한다. 이제는 더 이상 프로토타입을 만드는 것이 아니기 때문에, 핀헤더를 납땜해 놓고 듀폰 케이블로 대충 연결할 수는 없다. 작년에 쓴 글 '세상의 모든 커넥터'를 다시 읽으면서 공부를 해야 되겠다. 터미널 압착기(SN-2549 크림핑 툴)를 사 놓기를 잘했다.  

아직 검증되지 않은 회로도. 회로 자체는 작년에 실물로 입증하였으나, KiCad로 옮겨 그리는 과정에서 많은 실수가 숨어있을 것이다.

회로 자체는 대단히 간단(?)하다. 여기까지는 아마도 매우 쉬운 과정이었을 것이다. 실제 부품에 맞는 footprint를 고르는 일이 더 걱정이다. JST냐 Molex냐... 갖고 있는 부품 재고를 되도록 활용하고 싶은데 핀 수가 맞는지 모르겠다. KiCad의 'Assign Footprints'를 둘러 보았지만 Molex 5045 헤더(2.5mm 피치)에 딱 맞는 footprint가 보이지 않는다. 피치가 동일한 SPOX 5267을 써도 되는지? 혹은 무난하게 JST의 것을?



펌웨어는 이미 작년에 오랜 기간에 걸쳐 개발과 검증을 거쳤기에 별 걱정은 하지 않는다. 3월 중에 충분히 검토를 거쳐서 JLCPCB에 거버 파일을 보낼 수만 있다면 더 이상 바랄 것이 없겠다.


저자에서 디렉터로 — AI 시대 글쓰기의 변화

  • 기획: 정해영(director, 국문으로 바꾼다면 구성 감독, 총괄 설계자, 또는 텍스트 연출자?)
  • 텍스트 생성: AI 보조(text produced with AI assistance)


오랫동안 글쓰기는 ‘저자(author)’라는 개념을 중심으로 이해되어 왔다. 저자는 텍스트를 생산하는 사람이며, 글의 의미와 책임의 중심에 있는 존재였다. 책의 표지에는 저자의 이름이 적히고, 학술 논문에서는 저자 순서가 중요한 의미를 가진다. 글은 곧 저자의 창작물이었다.

그러나 디지털 환경과 협업적 지식 생산이 확산되면서 이 전통적인 개념은 조금씩 흔들리기 시작했다. 이미 20세기 후반에 여러 사상가들이 이러한 변화를 지적했다. 예컨대 Roland Barthes는 “저자의 죽음”이라는 유명한 글에서 텍스트의 의미는 저자가 아니라 독자의 해석 속에서 형성된다고 주장했다. 이어 Michel Foucault는 “저자는 하나의 기능(author function)”이라고 말하며, 저자를 절대적 창조자가 아니라 지식 체계 속의 역할로 이해했다.

오늘날 AI 도구가 글쓰기 과정에 깊이 들어오면서 이 변화는 더욱 분명해지고 있다. 이제 많은 글은 한 사람이 처음부터 끝까지 문장을 만들어내는 방식으로 생산되지 않는다. 자료 수집, 초안 작성, 문장 다듬기, 번역, 구조 정리 등 여러 단계에서 다양한 도구와 협업이 개입한다. 때로는 AI가 초안을 만들고 인간이 구조를 수정하며, 다시 AI가 문장을 정제하는 방식으로 글이 완성되기도 한다.

이러한 환경에서는 ‘저자’라는 말이 점점 어색해진다. 글을 직접 타이핑한 사람이 누구인가보다 중요한 것은 글의 방향과 구조를 설계한 사람이 누구인가라는 문제이기 때문이다. 다시 말해 텍스트의 생산 과정에서 중요한 역할은 더 이상 단순한 집필자가 아니라 전체 작업을 기획하고 조율하는 사람에게 있다.

이 역할을 가장 잘 설명하는 말은 아마도 ‘디렉터(director)’일 것이다. 영화에서 감독은 모든 장면을 직접 촬영하지 않는다. 배우가 연기하고 촬영 감독이 카메라를 잡으며 편집자가 영상을 다듬는다. 그러나 영화 전체의 방향과 스타일을 결정하는 사람은 감독이다. AI 시대의 글쓰기도 점점 이와 비슷해지고 있다.

앞으로의 글쓰기에서 중요한 능력은 문장을 얼마나 많이 생산할 수 있는가가 아니라, 어떤 질문을 던지고 어떤 구조를 설계하며 어떤 자료를 결합할 것인가일 가능성이 크다. 글은 점점 더 복합적인 생산 과정의 결과물이 되고, 저자는 그 과정을 지휘하는 역할로 이동한다.

따라서 AI 시대의 글쓰기를 이렇게 표현할 수도 있다.

우리는 더 이상 텍스트의 저자라기보다, 텍스트 생산의 디렉터가 되어가고 있다.

이 변화는 단순히 기술의 문제가 아니라 지식 생산 방식 자체의 변화를 보여준다. 글쓰기는 여전히 인간의 사유에서 출발하지만, 그 사유가 구현되는 방식은 점점 더 협업적이고, 도구 의존적이며, 연출적인 형태로 바뀌고 있다. 저자의 시대가 끝났다고 말하기는 아직 이르다. 그러나 적어도 오늘날의 글쓰기에서 저자의 모습이 과거와 같은 형태로 남아 있지 않다는 것만은 분명해 보인다.


이 글은 정해영의 아이디어를 바탕으로 AI(ChatGPT)의 도움을 받아 작성되었습니다.
본 텍스트는 Creative Commons Attribution 4.0 International (CC BY 4.0) 라이선스로 공개됩니다.
출처를 표시하는 조건으로 누구나 자유롭게 이용·수정·재배포할 수 있습니다.
정확성에 대한 보증이나 법적 책임은 제공되지 않습니다.

[DokuWiki] 문서 폭을 좁게 만드는 TOC, 어떻게 할 것인가?

DokuWiki에서는 문서 안에 자동으로 TOC(table of contents, 목차)를 만들어 준다. TOC는 문서의 내용을 신속하게 파악하고 특정 위치로 빨리 이동하는 데 큰 도움을 준다.

요즘은 ChatGPT를 써서 마크다운 문서를 만든 뒤 Commonmark Plugin을 이용해 DokuWiki에 삽입하는 일이 많다. 마크다운 문서는 GitHub에 올리기 좋고, 웹브라우저에서도 쉽게 열 수 있기 때문이다. DokuWiki에서는 새 문서를 <!DOCTYPE markdown>이라는 줄로 시작한 다음, 마크다운 본문을 복사해 넣으면 된다.

그런데 이렇게 만들어진 문서에서는 TOC가 끝나고 나서야 비로소 본문이 시작된다. 그래서 위쪽에 긴 여백이 생겨 보기가 매우 좋지 않다. 왜 그럴까? Commonmark Plugin의 렌더링 방식 차이 때문이다. DokuWiki 문법으로 작성된 문서는 본문이 먼저 시작되고, TOC는 오른쪽에 float되며, 본문은 그 옆으로 자연스럽게 흐른다. 그러나 내가 사용한 Markdown wrapper div는 CSS 문제로 인해 본문이 아래로 밀려 내려가면서 공백이 크게 생기는 것이다.

다음은 너무 긴 여백이 보기 흉해서 그림을 삽입한 예이다. 하지만 TOC가 너무 길어지면 그림을 넣어도 별 소용이 없다.

DokuWiki CommonMark TOC layout issue
글 원본 링크는 여기. ChatGPT가 당당하게 자기를 '저자'라고 표현하였다.

conf/userstyle.css에서 TOC가 나오지 않게 하면 어떨까? 하지만 이 방법은 위키 사이트 안의 모든 문서에서 TOC가 표시되지 않게 만들기 때문에 바람직한 해결책이 아니다. TOC를 표시하지 않을 문서를 일일이 CSS에 나열하거나, 네임스페이스 단위로 따로 설정할 수도 있겠지만, 그것 역시 번거로운 일이다.

문서마다 개별적으로 자동 TOC를 나오게 하거나 혹은 나오지 않게 하면 가장 좋겠지만, 즉 문서 상단에 위키 매크로인 ~~NOTOC~~를 삽입하면 좋겠지만, 현재 내가 쓰는 플러그인에서는 이것도 잘 먹지 않는다.

DokuWiki 안에서 Markdown을 쓰는 순간 위키 기능의 절반을 잃는다!

적어도 구조화된 기술 문서를 위키 안에서 안정적으로 운영하려면, Markdown보다는 처음부터 DokuWiki 문법으로 작성하는 편이 낫겠다. GitHub와의 호환성은 조금 아쉽더라도, 위키 본연의 기능을 온전히 살리는 쪽이 더 중요해 보인다.

오늘 이 문제를 해결해 보고자 ChatGPT와 더불어 여러 시도를 해 보았으나, 결국은 ‘futile cycle’만 돌고 말았다. 인공지능에 약간 실망하게 된 하루였다.


2026년 3월 15일 업데이트

위키문서에 삽입한 마크다운 문서의 본문이 갑자기 TOC와 서로 조화를 이루기 시작하였다(사례). 특별히 건드린 것이 없는데 왜 그런지 모르겠다. 

2026년 3월 3일 화요일

APS StepSeq 입력 도구의 다변화



Nano Ardule 드럼 패턴학 생태계를 이루고 있는 APS는 기본에 충실한 '스텝 시퀀서' 기능을 내장하고 있다. 16분음표 단위로 세분화된 스텝에 드럼킷을 구성하는 각 악기의 연주 정보를 입력하거나 편집하고, 메인 화면에서는 이를 연결하여 곡 단위의 arrangement 파일(패턴을 이어 붙인 곡 구성표)을 만드는 역할을 한다. 이 생태계를 구성하는 모든 파일 포맷은 ChatGPT와 의논하면서 정의해 나갔다.

스텝 시퀀서, 그러나 실시간에 대한 욕심

스텝 시퀀서라고는 하지만 실시간 입력에 대한 욕심을 충족하지 말라는 법은 없다. 킥 드럼 찍고, 비트마다 하이햇 찍고, 스네어 드럼 소리 찍어 올리고... 이 과정을 실시간으로 오버더빙하듯이 누적하여 입력하면 얼마나 편리하겠는가? 이러한 욕심은 NanoArdule 깃허브 프로젝트에서 메인과 독립한 별도의 브랜치(refactor/stepseq-v3.0a)를 만드는 것으로 이어졌고 마침내 필요한 기능을 모두 구현하게 되었다. 최종 테스트를 거친 뒤 이를 다시 메인 브랜치와 병합하는 일이 남았다.

현재 HEAD는 어디를 가리키는가?

다음은 사무실 PC에서 바라본 각 브랜치의 모습이다. HEAD가 어느 브랜치(또는 커밋)를 가리키는지 확인해 보자. 보다 기술적으로 말하자면, '현재 체크아웃된 브랜치를 확인해 보자'가 되겠다.

PS E:\Projects\NanoArdule\APS> git branch
  main
* refactor/stepseq-v3.0a
PS E:\Projects\NanoArdule\APS> git branch -a
  main
* refactor/stepseq-v3.0a
  remotes/origin/HEAD -> origin/main
  remotes/origin/main
  remotes/origin/refactor/stepseq-v3.0a
PS E:\Projects\NanoArdule\APS> git branch -vv
  main                   5a38227 [origin/main] docs: add Windows 11 KB5077241 compatibility notice
* refactor/stepseq-v3.0a 83625bd [origin/refactor/stepseq-v3.0a] StepSeq: disable REC arm when using GS Wavetable or no MIDI OUT
    

리얼타임 입력 도구

리얼타임 기반의 입력 도구는 컴퓨터 키보드(4×4 keyboard grid)MIDI 키보드 컨트롤러의 두 가지를 선택하여 쓸 수 있다. 전자의 경우 자판의 왼쪽 16개 키를 이용하며, 이 때에는 벨로시티를 조정하지는 못한다. 후자의 경우는 AKAI MPK Mini MKII의 4×2 패드를 사용한다. 사실 어떤 MIDI 키보드 컨트롤러를 써도 상관은 없다. AKAI 미니 키보드에서는 패드 설정을 바꾸어서 원하는 악기 소리가 나도록 해 두었다. 드럼의 각 악기 선택과 패드 배열에 대한 상세한 정보는 별도의 스펙 문서로 정리하였다. PC 키보드 일부를 4×4 패드처럼 쓰는 방식을 나는 4×4 keyboard grid라고 부르기로 했다. 아래 그림에서 알파벳 두 글자로 표기된 드럼계열 악기명 약어의 설명과 실제 GM 드럼킷에서 할당하는 노트번호는 위에서 언급한 스펙문서에 상세히 설명되어 있다.



Microsoft GS Wavetable Synth의 한계

문제는 latency다. PC에 내장된 Microsoft GS Wavetable Synth가 소리를 내는 상태에서는 반응 속도가 느려서 리얼타임 입력 도구를 사용하기 곤란하다. 따라서 MIDI OUT이 외부 음원 모듈로 연결되지 않았다면 Record가 아예 되지 않게 만들었다. 이러한 상태에서 'R'을 누르면 'REC disabled: Microsoft GS Wavetable is high-latency'라는 경고문이 나온다. 녹음은 타이밍 정확도가 중요하므로 차단하고, 미리듣기(Preview)는 학습/확인 목적이므로 허용한 것이다. 그러나 외부 MIDI 음원이 없더라도 녹음 모드가 아니라면 키보드 또는 패드를 누를 때 Microsoft GS Wavetable Synth를 통해서 소리는 난다('Preview').

앞으로 나아갈 방향

ASIO를 사용하는 DAW를 대체하기 위하여 APS/StepSeq을 만든 것은 아니니, 이러한 latency 문제를 적극적으로 해결할 계획은 아직까지는 없다. APS는 완성형 드럼 머신과 경쟁하려는 도구가 아니다. 그러나 입력 방식의 실험이라는 점에서 충분히 의미 있는 시도가 될 것이다.

2026년 3월 1일 일요일

운영체제가 나의 TUI를 부수던 날

오늘은 Nano Ardule의 APS 개발에서 이정표 하나를 세울 수 있는 날이었다. StepSeq 코드를 개선하여 '루퍼'와 유사하게 드럼 연주 정보를 입력하도록 만들었기 때문이다. 16 x 12로 펼쳐진 그리드 위에서 커서를 화살표로 이동하여 엔터키를 눌러 노트를 입력하는 스텝 시퀀서 본연의 기능은 이미 잘 다져진 상태였다. 여기에 외부 장비인 AKAI MPK MINI MkII를 연결하여 패드를 터치하면 드럼 패턴을 실시간으로 자연스럽게 녹음할 수 있다. 메트로놈 소리를 들으면서 베이스 드럼을 먼저 찍고, 다음으로 스네어 드럼, 그 다음에는 하이햇... 스크립트 실행 전 MIDI 기기 연결 상태를 점검하는 환경변수 설정을 먼저 해야 했던 다소 비효율적인 최근의 변경도 훨씬 안전하고 단순한 방식으로 고쳐 놓았다.

StepSeq의 기능을 이렇게 맞추어 나가기 위해 메인에서 독립한 별도의 브랜치(refactor/stepseq-v3.0a)까지 만들어서 몇 시간을 투자한 끝에 원하는 목표까지 달성을 하였다. 마침 Windows update가 있다는 알림이 있어서 설치를 지시해 놓고 아내와 함께 잠시 장을 보고 돌아왔는데...

APS에서 화면이 하나도 나오지 않는 것이다. 말 그대로 까만 터미널 창 그 자체의 '조용한 실패'였다. 챗GPT와 질문을 주고 받으면서 별의별 노력을 다 해 보았지만, TUI(text user interface)를 구현하기 위한 핵심인  ncurses 라이브러리의 작동이 Windows update와 더불어 문제를 일으킨 것 같다는 것이 최종 결론이었다.


오늘 설치한 Windows 11 버전 25H2 및 24H2(KB5077241)에 대한 비보안 업데이트는 KB5077241이다. 원인을 확실하게 알기 위해서 이 업데이트를 제거한 뒤 재설치해 보았다. [설정 > Windows 업데이트 > 업데이트 제거] 순서로 작업하면 된다.

KB5077241은 프리뷰(선택적) 업데이트였다. 설치하지 않아도 Patch Tuesday에 배포되어 자동으로 설치되는 다음 정식 누적 업데이트에 포함될 것이고, 안정성이 중요한 개발 환경에서는 보통 건너뛰는 것이 안전하다고 한다.

그러면 다음번 정식 업데이트가 KB5077241를 그대로 포함할 것이니 또 TUI와 관련한 문제가 재발하지 않겠는가? 꼭 그렇지는 않다. 문제 있는 부분은 수정되거나 제외될 수 있기 때문이다. 프리뷰 업데이트를 기계적으로 설치하는 버릇을 고쳐야 되겠다.

KB5077241를 삭제하였더니 업데이트를 하라는 알림이 트레이에서 다시 뜨기 시작하였다. '최신 업데이트가 제공되는 즉시 받기'를 꺼 두기로 하였다.

업데이트를 제거한 결과는? 언제 그랬느냐는 듯이 멀쩡한 APS 화면으로 돌아왔다. 어째서 이런 일이 벌어진단 말인가... 챗GPT에 의하면, Windows 업데이트 이후 curses/ncurses 계열이 깨지는 일은 꽤 자주 보고된다고 한다. 개발이 쉬울 것이라 생각해서 TUI를 선택하였는데, OS 변화 영향이나 Windows 호환과 관련해서는 nurses TUI보다 GUI가 더 낫다니 이는 미처 예상하지 못했던 일이다.

장기적으로는 curses 의존도를 줄여 나가는 것이 좋을 것이다. 앞으로 개발에 약간의 수고가 더 들더라도 GUI로 갈아타는 것을 오늘 처음으로 고민하기 시작하였다. 간단한 조사를 통해서 다음과 같이 결론을 내려 보았다.

🚩 PySimpleGUI로 전체 GUI 스켈레톤을 먼저 만들고,
StepSeq가 답답하면 그 부분만 Dear PyGui 스타일로 개선

refactor/stepseq-v3.0a 브랜치의 테스트를 완벽히 마친 뒤 main과 병합한 다음, GUI로 넘어가기 위한 탐색을 시작하련다. 만약 오늘의 작은 '사고'가 아니었더라면, GUI에 대한 호기심은 일절 갖지 않았을 것이다. 취미 코딩의 종착역이 어디까지 가게 될지 모두지 알 수가 없다.

오늘의 결론은 이러하다. 코드는 멀쩡했다. 운영체제가 바뀌었을 뿐이다. 이것이 새로운 시도로 이어지는 계기가 될 수도 있겠다.