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

오늘의 (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를 만들 때 치명적인 실수를 줄이게 될 것이다.

위 풋프린트 그림에는 서로 다른 색깔로 표시된 세 층의 레이어가 보인다. 두꺼운 빨간색 도넛으로 표현된 것은 바로 구리로 만들어진 패턴에 해당하는 레이어다. 바로 여기에 부품의 다리가 납땜되는데, 윗면인 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)라이선스로 공개됩니다. 출처를 표시하는 조건으로 누구나 자유롭게 이용·수정·재배포할 수 있습니다. 정확성에 대한 보증이나 법적 책임은 제공되지 않습니다.

KiCad로 그린 첫 회로도

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

KiCad와 같은 종류의 프로그램은 PCB를 설계하여 주문하려면 피할 수 없는 선택이다. LTspice와 Fritzing에 이어서 드디어 오늘을 기하여 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가 너무 길어지면 그림을 넣어도 별 소용이 없다.

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

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

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

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

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

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

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는 완성형 드럼 머신과 경쟁하려는 도구가 아니다. 그러나 입력 방식의 실험이라는 점에서 충분히 의미 있는 시도가 될 것이다.

운영체제가 나의 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에 대한 호기심은 일절 갖지 않았을 것이다. 취미 코딩의 종착역이 어디까지 가게 될지 모두지 알 수가 없다.

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