2026년 3월 10일 화요일

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

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


2026년 2월 27일 금요일

갈라질 결심(Creating a Git Branch)

갈라진다고 하여 사람이나 조직과 인연을 끊거나 헤어진다는 뜻은 아니고, Git에서 새로운 기능을 넣기 위해 처음으로 메인에서 독립하여 별도의 브랜치를 만들겠다는 뜻이다.


Nano Ardule 드럼 패턴학 생태계에서 PC쪽 패턴 생성 및 편집기, 즉 APS(Ardule Pattern Studio)는 기본적으로 키보드를 두드려서 입력을 하는 데 충실하게 만들었다. 실시간 연주를 받아들이는 것이 아니라 StepSeq, 즉 16분음표 단위의 스텝으로 커서을 이동하여 선정된 악기의 타격 신호를 기록한다. 2차원 그리드 위에 체크 표시를 한다고 생각하면 간단하다. 어제도 코드 효율을 높이기 위한 약간의 수정을 하여 commit를 한 상태이다.

이번 단계의 목표는 AKAI MPK Mini MKII를 입력 장치로 쓰게 만드는 것이다. 그러면 컨트롤러의 4x2 패드를 이용하여 드럼 패턴을 입력할 수 있기 때문이다. 이미 패드를 두드려서 스텝 단위 입력을 할 수 있게 만들어 두었으나, 욕심을 좀 더 부려서 마치 루퍼처럼 오버더빙 형식의 실시간 입력을 가능하게 만들고 싶다.

그러려면 상당한 수준의 코드 수정이 필요하기에 아예 이번 기회에 branch를 새롭게 생성해 보기로 하였다. 브랜치 생성 요령은 별도의 문서('Safe Git Branching Guide for StepSeq Refactoring')로 정리해 두었다. 어제까지 완성하여 안정화된 기능(키보드를 통한 스텝 입력)은 일절 건드리지 않아야 한다.

그리고 한가지 더. GUI나 DAW로 관심이 이동하면 절대로 안 된다! 그건 나의 본분을 잊는 행위이다. 목표를 명확히 하고 개발의 시행착오를 줄이기 위하여 이번 단계의 설계 개념은 문서로 충분히 작성해 두었다. 

레코딩('녹음'이라고 표현하면 오디오 신호 자체의 기록이라는 느낌이 강하게 든다)을 자체 개발 파이썬 스크립트로 소박하게 구현해 보면서 몇 가지 중요한 개념을 공부하게 되어 좋은 기회라고 생각한다.  녹음과 재생에 대한 각종 설정 또는 제어 상태는 다음과 같은 계층 구조로 이해하면 좋다.

  1. Transport layer: 플레이헤드 진행 및 루프 범위 제어
  2. Record arm layer: 입력이 패턴을 수정할 수 있는지 결정
  3. Write policy (overwrite or overdub): 기존 데이터와 새 입력의 병합 방식 정의

만약 이 브랜치에서 성공적으로 개발이 완료된다면, APS의 StepSeq은 아주 쓸모 있는 장난감이 될 것이다. 

그리고... 업무 스트레스를 달리기로 푼 어제의 기록. 기온이 많이 올라서 야간 달리기를 하기에 아주 좋았다. 479kcal를 태웠으니 라면 한 그릇의 열량을 소모한 정도?

만족스럽지 못한 2월의 달리기 기록. 일본 여행과 날씨 탓이 크다. 어제는 오랜만에 7km를 넘게 달렸다.