십억(B, billion)이라는 말을 일상적으로 하게 된 유전체 분야

유전체 분야에서는 billion(십억, 10⁹, SI 접두어로는 giga)과 peta('천조', 10¹⁵)가 낯설지 않은 단위다. 인간 유전체 한 세트가 약 3 빌리언 염기쌍이고, 대규모 유전체 데이터 저장소와 국가 단위 데이터 생산량은 이제 페타바이트(PB) 규모로 이야기된다. 유전체학은 생명과학 가운데 거대한 수의 단위를 일상적으로 사용하는 대표적인 분야다.

정확히 따지자면 기가와 페타는 무려 1백만 배의 차이가 난다. 중간에 '테라'(1조, 10¹²)가 놓인다.

다음의 사진은 내가 (주)제노텍에 근무하던 시절 촬영한 DNA 시퀀싱 룸의 모습이다. 아마 2002년쯤이 아니었나 생각된다. 당시 제노텍은 국내에서 모든 연구소와 기업을 통틀어서 가장 많은 대용량 시퀀싱 장비 (ABI Prism 3700 Genetic Analyzer 다섯 대)를 보유한 곳이기도 했다. 경쟁 제품으로는 MegaBACE와 RISA-384가 있었던 것으로 기억한다. 당시에는 오늘날의 일루미나 장비에서 보이는 flow cell이라는 개념도 없었고, 96-well plate 단위로 모든 처리가 이루어졌다.

ABI Prism 3700. 기계장치가 많아서 종종 말썽을 일으키고는 했다.

일루미나의 NovaSeq X 시리즈에 들어가는 25B flow cell에서는 single-end read로 환산하여 약 26-35 '빌리언' 리드(read)를 생산한다. 2 × 150 bp로 맞추었을 때 생산되는 분량은 약 8-10.5 Tb(테라베이스)이다. ChatGPT에게 물어보니 30× human genome whole genome sequencing(WGS)의 경우 플로우 셀 하나에서 약 64명 분량을 처리할 수 있다. 다음 사진은 마크로젠 송도글로벌지놈센터를 방문했을 때 얻어 온 25B 플로우 셀이다. 물론 시퀀싱이 다 끝난 뒤 폐기를 기다리던 것이다. 이거 하나의 가격이 얼마라고 했더라? 시약을 포함한 한 세트의 가격은 list price로서 16,000달러라고 한다.

이처럼 현대적인 DNA 시퀀싱 장비는 실험실이 아니라 첨단 반도체 제조 공장에 어울릴 모습을 하고 있다. 다음 사진에는 약 25년 전, 그러니까 거의 한 세대 전에 '대규모 시퀀싱 센터'에서 일상적으로 하던 일이 담겨 있다. 엄밀하게 말하면 이 사진은 DNA 시퀀싱 장비에 들어갈 template DNA를 뽑는 단계만을 소개하였다. PCR 머신에서 'BigDye'를 이용한 시퀀싱 반응을 하고, 반응물을 정제하는 등 몇 번의 단계를 더 거쳐야 비로소 ABI 3700에 로드할 수 있는 상태가 되었다. Capillary를 잘못 관리하여 마르게 하면? 누군가에게 혼난다!

한때 직장 동료였던 차선호 박사님의 젊을 때 모습.

Ultima Genomics라는 회사에서는 산업계에서 실제로 사용하는 원형 실리콘 웨이퍼를 sequencing surface로 이용한다. 다음은 Ultima Genomics의 장비에서 실제로 쓰이는 6인치 웨이퍼의 실물과 일루미나 25B 플로우 셀을 같이 놓고 촬영해 보았다.

웨이퍼 표면은 마치 거울과 같아서 천장에 설치한 에어컨이 그대로 보인다.

기술이 발전하면서 시퀀싱 장비 내에서는 움직이는 부품이 줄어들고 따라서 유지보수도 쉬워졌을 것이다. 마치 레이저 프린터의 토너를 교체하듯이 쉽게 수리가 이루어진다. 그러나 이것은 고객의 입장에서 그렇다는 것이고, 많은 비용이 드는 것은 어쩔 수 없다. 즉, 대규모 시퀀싱 장비가 등장하면서 고가의 유지보수 계약이 유전체 정보 생산비의 일상적인 일이 된 것이다.

25년 전에는 96개의 capillary를 동시에 돌리는 ABI 3700 다섯 대를 놓고도 '대규모 시퀀싱 센터'라고 불렀다. 이제는 손바닥만 한 플로우 셀 하나에서 수십 빌리언 개의 read와 수조 개의 염기가 쏟아진다. 한때 megabase가 큰 숫자였고 gigabase가 놀라운 숫자였지만, 이제 우리는 billion을 일상적으로 말하고 국가 단위의 데이터는 petabyte로 센다. 지난 한 세대 동안 유전체학에서 커진 것은 데이터의 양만이 아니라, 우리가 '크다'고 느끼는 숫자의 기준 자체였는지도 모른다.

4년 만에 해결한 iCON iKeyboard 5 NANO의 Code 10 오류 — 답은 이미 2020년에 있었다

2022년 9월, ThinkPad E14 Gen3를 구입한 뒤 이해하기 어려운 문제 하나를 만났다. 오래 사용하던 USB MIDI 키보드 컨트롤러인 iCON iKeyboard 5 NANO가 도무지 제대로 인식되지 않는 것이었다.

당시의 '삽질'은 다음 글에 기록해 두었다.

OneDrive 생태계의 일원이 되어 보기로 하다 - 조직 이름 바꾸기에는 성공하였지만... 그리고 iCON MIDI 키보드 인식 문제!

장치 관리자에 나타난 메시지는 다음과 같았다.

This device cannot start. (Code 10)

Insufficient system resources exist to complete the API.

처음에는 Windows 11의 문제라고 생각했다. Windows를 다시 설치해 보기도 하고 나중에는 Windows 10으로 내려서 시험하기도 했지만 문제는 해결되지 않았다. 더 이상했던 것은 같은 iKeyboard 5 NANO가 다른 환경에서는 작동한다는 점이었다. Linux에서는 정상적으로 인식되었고 FluidSynth를 이용한 연주도 가능했다. 예전 Windows 컴퓨터에서도 작동한 적이 있었다.

그러니 장치가 완전히 고장 난 것도 아니었다. 그렇다고 ThinkPad의 USB 자체가 망가진 것도 아니었다. 몇 년 뒤 구입한 iCON iKeyboard 8 Nano는 바로 그 ThinkPad에 연결해도 정상적으로 작동했다.

대체 무엇이 문제였을까?

2026년, 다시 시작한 삽질

2026년 8월 마지막 날, 이 문제를 다시 파보기로 했다. 이번에는 장치 관리자에서 노란 느낌표를 바라보는 수준에서 그치지 않고, Windows의 USB ETW(Event Tracing for Windows)를 이용하여 USB stack의 어느 단계에서 장치 초기화가 실패하는지를 추적했다.

문제가 발생하던 iKeyboard 5 NANO의 firmware는 V1.05였다. V1.05 장치를 ThinkPad에 연결하면 USB device descriptor와 configuration descriptor는 정상적으로 읽혔다. Windows UCX(USB Host Controller Extension)도 MIDI endpoint를 생성하려 했다.

문제는 그 다음 단계였다.

USB descriptor read
        ↓
UCX endpoint creation
        ↓
xHCI Configure Endpoint Command
        ↓
Completion Code 17: Parameter Error
        ↓
endpoint deletion and retry
        ↓
USB Composite Device start failure
        ↓
Code 10

즉 드라이버 파일이 없거나 잘못 설치된 문제가 아니었다. iKeyboard 5 NANO는 USB class-compliant 장치이고, Windows에서는 Microsoft의 표준 USB composite driver가 정상적으로 선택되고 있었다. 문제는 훨씬 아래쪽, USB host controller가 endpoint를 실제로 구성하는 단계에서 발생하고 있었다.

수상한 숫자 하나: 4

USB descriptor를 자세히 비교하다가 흥미로운 차이를 발견했다. iKeyboard 5 NANO V1.05의 MIDI OUT bulk endpoint descriptor는 다음과 같았다.

09 05 02 02 04 00 00
            ^^
       wMaxPacketSize = 4

반면 같은 ThinkPad에서 정상 작동하는 iKeyboard 8 Nano V1.06의 MIDI OUT endpoint는 wMaxPacketSize = 8이었다.

USB-MIDI 1.0의 MIDI Event Packet 자체는 4 byte이므로 wMaxPacketSize=4라는 값이 얼핏 보아 터무니없는 것은 아니다. 실제로 Linux와 일부 Windows 컴퓨터는 이 설정을 받아들였고 장치도 정상 작동했다. 그러나 문제의 ThinkPad에서는 이 endpoint를 xHCI controller에 설정하는 과정에서 Parameter Error가 발생했다.

펌웨어를 직접 고쳐야 하나?

공식 iKeyboard 5 NANO V1.05 firmware binary도 열어 보았다. 그 안에서 실제 USB endpoint descriptor를 그대로 찾을 수 있었다.

V1.05 @ 0x4044

09 05 02 02 04 00 00
            ^^

04를 08로 바꾼 실험용 firmware까지 만들어 두었다. 하지만 firmware를 직접 수정해서 장치에 쓰는 것은 이야기가 다르다. 잘못하면 멀쩡한 MIDI keyboard를 '벽돌'로 만들 수도 있다. 그래서 실제 flashing은 하지 않고 조금 더 조사하기로 했다.

그 판단은 옳았다.

그런데 V1.06 Beta가 있었다

iCON의 현재 firmware update 프로그램을 다시 살펴보다가 뜻밖의 항목을 발견했다.

iKeyboard 5Nano v1.05
iKeyboard 5Nano v1.06 (Beta)

내가 오랫동안 마지막 firmware라고 알고 있던 것은 V1.05였다. 제품 지원 페이지에서도 V1.05가 눈에 띄었기 때문에 그 이후 버전이 존재한다는 사실을 알지 못했다. 그러나 firmware updater가 읽어 오는 서버의 firmware.xml에는 V1.05와 함께 V1.06 (Beta)가 등록되어 있었다.

사무실의 정상 작동하는 PC에서 5 NANO를 V1.06 Beta로 업데이트했다. 그 뒤 문제의 ThinkPad에 다시 연결했다.

정상 작동했다.

USB Composite Device
Status  : OK
Problem : CM_PROB_NONE

iCON iKeyboard 5 Nano V1.06
Status  : OK
Problem : CM_PROB_NONE

같은 iKeyboard 5 NANO, 같은 ThinkPad E14 Gen3, 같은 Windows, 같은 USB hub였다.

바뀐 것은 firmware뿐이었다.

V1.05  → Code 10
V1.06  → 정상 작동

2022년에 처음 기록했던 문제가 4년 만에 해결되었다. 어이가 없네!

그리고 정말 4가 8로 바뀌어 있었다

V1.06을 설치한 뒤 Microsoft USBView를 이용하여 5 NANO의 USB descriptor를 다시 확인했다.

                         V1.05     V1.06 Beta
------------------------------------------------
MIDI IN  wMaxPacketSize     8          8
MIDI OUT wMaxPacketSize     4          8

공식 V1.06 Beta firmware binary도 직접 내려받아 조사했다.

V1.06에서는 firmware 내부 구조가 달라져 descriptor의 위치가 이동해 있었지만, 동일한 MIDI OUT endpoint descriptor를 찾아 비교해 보니 다음과 같았다.

V1.05 @ 0x4044
09 05 02 02 04 00 00

V1.06 @ 0x420C
09 05 02 02 08 00 00

더 흥미로운 점은 이 부분 앞뒤의 USB MIDI descriptor가 거의 동일하다는 것이다.

즉 내가 V1.05 실험용 firmware에서 바꾸려고 했던 바로 그 값, MIDI OUT endpoint의 wMaxPacketSize 4 → 8 변경이 공식 V1.06에도 실제로 들어 있었다.

물론 V1.05와 V1.06 사이에는 다른 firmware 변경도 존재할 수 있다. 따라서 이 한 바이트 변경만이 유일한 해결 원인이었다고 단정할 수는 없다. 그러나 다음 세 가지 사실은 서로 매우 잘 맞아떨어진다.

• V1.05에서는 xHCI Configure Endpoint 명령이 Parameter Error로 실패한다.
• V1.06에서는 같은 ThinkPad에서 장치가 정상적으로 시작된다.
• V1.06에서는 MIDI OUT endpoint의 wMaxPacketSize가 4에서 8로 변경되었다.

따라서 이 값의 변경이 USB host controller 호환성 문제 해결과 직접 관련되어 있을 가능성은 매우 높다고 생각한다.

그런데 왜 V1.05도 어떤 컴퓨터에서는 잘 작동했을까?

이것이 이 문제에서 가장 흥미로운 부분이다.

wMaxPacketSize=4가 USB 규격상 완전히 잘못된 값이었다면 모든 컴퓨터에서 실패했어야 한다. 실제로는 그렇지 않았다. V1.05는 Linux에서 작동했고, 다른 Windows PC에서도 작동했다. 이번 조사에서도 Intel USB controller를 사용하는 사무실 PC에서는 같은 V1.05 장치가 아무 문제 없이 인식되었다.

따라서 V1.05를 단순히 '고장 난 firmware'라고 부르는 것보다는 특정 USB host controller와의 compatibility problem을 가진 firmware라고 표현하는 것이 더 적절할 것 같다.

어떤 USB host/controller stack에서는 OUT endpoint의 wMaxPacketSize=4를 받아들였지만, 내 ThinkPad의 AMD xHCI 환경에서는 endpoint configuration 단계에서 이를 받아들이지 않고 Parameter Error를 반환했다. V1.06에서 이 값이 8로 변경되자 같은 ThinkPad에서도 정상 작동했다.

결국 이것은 단순한 Windows 11 문제도, MIDI driver 문제도, 하드웨어 고장도 아니었다.

오래된 device firmware와 특정 USB host controller 구현 사이의 호환성 문제였던 것으로 보인다.

그런데 답은 2020년부터 서버에 있었다

마지막으로 V1.06 Beta firmware가 언제부터 존재했는지도 궁금해졌다.

iCON firmware distribution server에서 현재 제공되는 iKeyboard_5Nano_V1.06.bin의 HTTP header를 확인해 보았다.

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 19376

Last-Modified: Mon, 27 Apr 2020 08:18:30 GMT
ETag: "b61ed912b107fc7af1a8de0873a6c2d2"

현재 제공되는 V1.06 Beta 객체의 Last-Modified timestamp는 2020년 4월 27일이었다. 물론 이것을 V1.06의 공식 발표일이라고 단정할 수는 없다. 해당 객체가 그날 재업로드된 것일 가능성도 있기 때문이다. 정확하게 표현하면, 현재 서버에서 배포되는 V1.06 Beta binary의 S3 객체 수정 시각이 2020년 4월 27일이다.

어쨌든 내가 이 문제를 처음 블로그에 기록한 것은 2022년이었다. 내가 문제를 기록하기 전부터 해결 firmware가 서버에 있었을 가능성이 매우 높은 셈이다. 그런데 일반적인 제품 지원 페이지에서는 V1.05만 눈에 띄었고, V1.06 Beta는 firmware updater가 읽어 오는 목록 속에 조용히 들어 있었다.

이걸 지금까지 몰랐다니.

기록을 위한 V1.06 Beta 정보

다운로드 URL은 언젠가 바뀌거나 사라질 수 있다. 따라서 URL뿐 아니라 파일의 식별 정보를 함께 남겨 둔다.

Product:
iCON iKeyboard 5 NANO

Firmware:
V1.06 (Beta)

Filename:
iKeyboard_5Nano_V1.06.bin

File size:
19,376 bytes

SHA-256:
7F4423D2EB2FBCF47584DAB4AF07B97968EA3A5AF7C74D56ADB89C510F2E96A9

Current firmware feed:
https://d2ff5pmy2hzqo1.cloudfront.net/firmware.xml

Current binary URL:
https://d2ff5pmy2hzqo1.cloudfront.net/iKeyboard_5Nano_V1.06.bin

S3/CloudFront Last-Modified:
2020-04-27 08:18:30 GMT

BIN 파일 자체도 별도로 보관해 두었다. URL은 언제든 바뀔 수 있지만 SHA-256 값은 나중에 파일의 동일성을 확인할 수 있는 좋은 기록이 된다.

또 한 가지 주의할 점이 있다. 예전에 배포된 firmware update 설명서에서는 사용자가 로컬의 .bin 파일을 직접 지정하는 방식이 소개되어 있었지만, 현재 사용한 iMap의 firmware update 인터페이스는 그 설명서와 달랐다.

현재 프로그램은 서버의 firmware.xml을 읽어 해당 장치에 사용 가능한 firmware version을 목록으로 제시하고, 사용자가 그중 하나를 선택하는 방식으로 보인다.

따라서 미래에 iCON의 firmware server가 없어졌을 때 보관해 둔 BIN 파일만으로 쉽게 복구할 수 있는지는 아직 확인하지 못했다.

결론

돌고 돌아 결론은 놀라울 정도로 간단했다.

고장 난 MIDI keyboard가 아니었다.
Windows 11만의 문제도 아니었다.
해결책은 공식 V1.06 Beta firmware였다.

그리고 현재 서버에서 배포되는 그 firmware의 timestamp는 내가 이 문제를 처음 기록하기도 전인 2020년이었다. 2022년에 시작한 문제를 2026년에야 해결했다. 그 과정에서 Windows USB stack의 ETW trace를 뜨고, xHCI Configure Endpoint command의 실패까지 추적하고, firmware binary에서 USB endpoint descriptor를 직접 찾아 비교하게 될 줄은 몰랐다.

처음에는 단순히 낡은 MIDI keyboard 하나가 작동하지 않는 문제였다.

그런데 끝까지 파고 들어가니 USB descriptor, host controller compatibility, firmware binary와 CloudFront의 오래된 파일까지 이어지는 작은 디지털 고고학이 되어 버렸다.

이래서 오래된 디지털 기기를 쉽게 버리면 안 된다. 가끔은 기계보다 해결책을 찾아내는 사람이 더 늦게 업데이트된다.

아직 남은 약간의 찜찜함

문제는 해결되었지만 한 가지는 아직 깔끔하게 설명되지 않는다.

사무실 PC에서 iMap V1.18을 이용하여 firmware update mode로 들어가면 iCON firmware upgrade v1.00이라는 장치가 정상적으로 나타나고, 그 다음 단계에서 firmware version을 선택하여 업데이트를 진행할 수 있었다.

그런데 같은 5 NANO를 ThinkPad에서 firmware update mode로 전환해 보니 해당 단계의 장치 목록이 비어 있었다. 현재 설치된 V1.06 Beta에서는 5 NANO 자체가 ThinkPad에서 정상적으로 작동하는데도 firmware update 과정에서는 다시 PC에 따른 차이가 나타난 셈이다.

이 현상의 원인은 더 이상 추적하지 않았다. Firmware update mode에서는 일반 동작 때와 다른 bootloader 또는 USB/MIDI configuration을 사용할 가능성이 있고, 그것이 ThinkPad의 USB 환경과 또 다른 호환성 문제를 일으키는 것일 수도 있다. 그러나 이것은 확인된 사실이 아니라 추측이다.

따라서 이번 조사에서 확실하게 말할 수 있는 것은 여기까지다. V1.05에서는 특정 host controller 환경에서 USB endpoint configuration이 실패했고, 공식 V1.06 Beta로 업데이트한 뒤에는 같은 ThinkPad에서 정상적으로 사용할 수 있게 되었다.

다만 이 오래된 장치의 USB 구현에는 host controller에 따라 행동이 달라지는 부분이 적어도 하나 더 남아 있는 듯하다.

어차피 이 모델에 새로운 firmware가 다시 나올 가능성은 매우 낮다. V1.06 Beta로 정상 작동하는 지금, 여기서 더 파고들 이유도 별로 없다. 해결은 되었지만 모든 의문이 해결된 것은 아니다. 그 정도의 찜찜함은 기록으로 남겨 두기로 한다.