Bluetooth UART가 부팅 직후 간헐적으로 올라오지 않거나 hci0가 생성된 뒤에도 명령 timeout이 난다면, 5.15 계열에서는 HCI UART 초기화 순서와 H4 수신 이벤트 처리의 race를 먼저 의심해야 합니다.

먼저 결론

Linux 5.15.71 기반 제품에서 이 문제가 반복된다면 두 가지를 함께 확인해야 합니다. 첫째는 HCI UART protocol ready(PROTO_READY) 설정 시점이 늦어 초기 수신을 놓치는 문제입니다. 둘째는 H4 장치 등록이 완료되기 전에 들어온 event가 버려져 command 0x1003 tx timeout으로 이어지는 문제입니다.

따라서 PROTO_READY 시점을 앞당기는 패치 하나만 적용하면 불완전할 수 있습니다. 등록 전 event 유실까지 막는 후속 수정을 함께 검토해야 합니다.

현장에서 보이는 증상

대표 로그는 다음과 같습니다.

Bluetooth: hci0: command 0x1003 tx timeout
Bluetooth: hci0: HCI reset during shutdown failed

hciattach가 성공한 것처럼 보여도 이후 bluetoothd가 hci0를 사용하지 못할 수 있습니다. 전원 시퀀스, UART RTS/CTS, firmware download가 정상인데도 재현된다면 소프트웨어 초기화 race의 가능성이 큽니다.

HCI UART와 H4의 역할

HCI UART는 Bluetooth Host와 Controller를 UART로 연결하는 커널 계층입니다. H4는 command, event, ACL 패킷을 1바이트 type으로 구분합니다. 초기화 중 Controller는 예상보다 빠르게 event를 보낼 수 있지만, Host는 아직 protocol state나 hci_dev 등록을 끝내지 못했을 수 있습니다.

핵심은 UART 바이트가 들어오지 않은 것이 아니라, 들어온 바이트를 처리할 준비가 안 된 경로가 버릴 수 있다는 점입니다. logic analyzer에서 traffic이 보인다고 해도 이 race를 배제할 수 없습니다.

race가 생기는 순서

1. UART가 열리고 H4 protocol이 설정됩니다.
2. Controller가 초기화 event를 보내기 시작합니다.
3. 커널은 protocol ready와 hci device 등록을 순차적으로 진행합니다.
4. 이 사이에 도착한 event가 버려지면 다음 command가 응답을 기다리다 timeout이 납니다.

확인해야 할 두 종류의 수정

1. PROTO_READY 설정 시점

첫 번째 수정은 HCI UART protocol ready 상태를 더 이르게 설정해, 초기 수신이 준비 전으로 분류되어 폐기되는 창을 줄입니다. 적용 전후에는 hci_uart_set_proto() 주변의 상태 전환과 수신 처리 조건을 비교하세요. vendor BSP에는 같은 함수 주변에 별도 변경이 있을 수 있으므로 commit 전체를 기계적으로 적용하지 않는 편이 안전합니다.

2. 등록 완료 전 event 유실 방지

후속 수정은 hci device 등록이 끝나기 전에 H4 event가 들어오는 경우를 다룹니다. 이 경로가 남아 있으면 PROTO_READY를 앞당긴 뒤에도 command 0x1003 tx timeout이 남을 수 있습니다. 초기 event를 언제부터 유효한 event로 전달할지, 그리고 수신 경로가 등록 전 event를 잃지 않는지를 함께 봐야 합니다.

5.15.71 제품의 선택지

2026년 8월 28일 기준 5.15 LTS 최신 버전은 5.15.219입니다. 5.15.71은 보안·안정성 수정 누적량이 큰 지점이므로 장기적으로는 LTS 전체 업그레이드를 별도 과제로 잡는 편이 맞습니다.

출시 일정이나 vendor BSP 제약 때문에 즉시 업그레이드하기 어렵다면 필요한 commit만 백포트할 수 있습니다. 이때는 현재 tree의 hci_uart·hci_h4 vendor 변경점을 먼저 비교하고, PROTO_READY 관련 수정과 등록 전 event 유실 방지 수정을 함께 가져오세요. 이후 cold boot 반복 시험으로 재현률과 개선률을 비교해야 합니다.

부분 백포트는 빠르지만 다른 안정성 수정은 남습니다. 반대로 5.15.219 업그레이드는 검증 범위가 넓습니다. 단기 장애 대응은 백포트, 다음 유지보수 계획은 LTS 업그레이드로 분리하는 방식이 현실적입니다.

재현과 검증 방법

warm reboot만으로 판단하지 말고 전원 완전 차단 뒤 cold boot를 수십 회 반복하세요. hci0 생성, HCI Reset 완료, bluetoothd 기동, 실제 pairing까지 기록하면 좋습니다.

dmesg -w
btmgmt info
hciconfig -a

UART 레벨에서는 RX/TX와 flow control을 확인하고, 커널 레벨에서는 event 수신 시점과 hci device 등록 시점의 관계를 보세요. 패치 후 timeout만 사라졌는지와 초기화 성공률이 올라갔는지를 모두 확인해야 합니다.

정리

5.15.71 제품이라면 PROTO_READY 관련 수정 하나만 보지 말고, 등록 완료 전 event 유실을 막는 후속 수정까지 한 세트로 검토하세요.

부팅 전체 흐름은 https://donggrri.tistory.com/62 에서, CAN 수신 누락과 FIFO overflow 점검은 https://donggrri.tistory.com/55 에서 이어서 볼 수 있습니다.

참고: Linux Kernel Archives https://www.kernel.org/

에이전트를 여러 개 쓸 때 tmux가 유용한 이유

여러 코딩 에이전트를 동시에 돌릴 때 tmux가 유용한 이유는, SSH가 끊겨도 세션이 서버에 남고 패인마다 작업을 나눠 로그를 유지한 채 다시 붙을 수 있기 때문입니다.

이 글은 공식 위키와 매뉴얼을 기준으로 한 일반 사용 안내이며, 배포판 패키지와 키 바인딩 설정에 따라 세부 동작은 달라질 수 있습니다.

SSH가 끊기면 왜 긴 에이전트 실행이 죽나?

한 줄 답: SSH 터미널에서 바로 시작한 전경 실행은 그 연결에 묶이지만, 세션 관리자는 연결 시간 초과나 의도적 분리 뒤에도 서버에서 실행을 유지합니다.

터미널 멀티플렉서는 하나의 터미널에서 여러 프로그램을 다루는 도구입니다. 화면에서 분리해도 프로그램이 백그라운드에서 계속 실행되고, 나중에 다른 터미널에서 같은 세션에 다시 연결할 수 있습니다.

공식 시작 안내는 원격 서버의 프로그램을 연결 끊김으로부터 보호하는 용도를 제시합니다. 여러 로컬 컴퓨터에서 원격 프로그램에 접근하고, 한 터미널에서 여러 프로그램과 셸을 함께 다루는 용도도 포함합니다.

SSH 터미널에서 Cursor, Claude Code, Codex 같은 코딩 에이전트를 직접 시작하면 그 전경 실행은 해당 연결에 묶입니다. SSH 연결이 끝나면 그 실행도 함께 끝나므로, 긴 작업은 세션 안에서 시작하는 방식이 적합합니다.

매뉴얼은 세션이 ssh(1) 연결 시간 초과나 C-b d에 의한 의도적 분리 뒤에도 살아남는다고 설명합니다. 연결을 다시 맺은 뒤 같은 세션에 붙으면 실행 화면과 로그를 이어서 확인할 수 있습니다.

세션은 어떻게 만들고 분리하고 다시 붙이나?

한 줄 답: 새 세션을 만들고 기본 접두사 뒤 d로 분리한 다음, 목록에서 확인해 다시 연결합니다.

인수 없이 새 세션 명령인 new-session을 실행하면 새 세션을 만들고 그 세션에 연결합니다. 첫 세션의 기본 이름은 0입니다.

tmux new

기본 접두사는 C-b입니다. 세션 안에서 C-b d를 입력하면 클라이언트가 분리되며, 실행 중인 프로그램은 세션에서 계속 유지됩니다. 공식 위키의 메시지 예시는 [detached (from session mysession)]입니다.

다시 연결할 때는 attach-session 명령의 별칭인 attach를 사용합니다. 인수 없이 실행하면 이미 연결되지 않은 세션 가운데 가장 최근에 사용한 세션을 우선합니다.

세션이 여러 개이면 목록 명령으로 서버가 관리하는 세션을 확인할 수 있습니다. 대상이 분명할 때는 -t로 세션 이름을 지정해 연결합니다.

tmux attach
tmux attach -t mysession
tmux ls

이름 있는 세션은 에이전트를 나눌 때 왜 쓰나?

한 줄 답: 고유한 이름을 붙이면 여러 장기 실행을 기본 숫자 이름 대신 식별해 대상 세션에 다시 연결할 수 있습니다.

세션 이름은 -s로 정합니다. 세션 이름은 서로 달라야 하므로, 같은 이름을 여러 세션에 사용할 수 없습니다.

Cursor, Claude Code, Codex 같은 코딩 에이전트의 장기 실행을 각각 cursor, claude, codex라는 세션 이름으로 구분할 수 있습니다. 아래 명령은 제품 설정이 아니라 이름 있는 세션을 만드는 일반적인 예입니다.

tmux new -s cursor
tmux new -s claude
tmux new -s codex

새 세션 명령에 -d를 쓰면 세션을 만들되 바로 연결하지 않습니다. -A를 쓰면 지정한 이름이 이미 있을 때 새 세션 대신 해당 세션에 연결하는 동작을 합니다.

tmux new -smysession
tmux new -Asmysession

대상 세션에 다시 붙을 때는 대상 지정 옵션 -t로 이름을 지정합니다. 연결 명령의 -d는 같은 세션에 붙어 있는 다른 클라이언트를 분리한 뒤 대상 세션에 연결하는 옵션입니다.

tmux attach -t mysession
tmux attach -d -t mysession

에이전트마다 한 작업을 이름 있는 세션 또는 패인에 두면 재접속 때 어떤 실행인지 확인하기 쉽습니다. 기본 숫자 이름에 의존하지 않고 이름으로 대상을 정할 수 있어 여러 장기 실행을 구분하는 데 도움이 됩니다.

윈도와 패인은 여러 에이전트에 무엇을 하나?

한 줄 답: 세션 안의 윈도는 화면을 차지하고 패인으로 나뉘며, 입력은 한 번에 활성 패인 하나로만 갑니다.

세션은 의사 터미널의 모음입니다. 클라이언트는 세션을 화면에 표시하고, 하나의 서버가 /tmp의 소켓을 통해 세션을 관리합니다.

윈도는 화면을 차지하는 단위이며 직사각형 패인으로 나뉠 수 있습니다. 프로그램은 패인에서 실행되고, 패인은 윈도에 속하며, 윈도는 세션에 연결됩니다.

한 윈도에는 한 번에 하나의 활성 패인만 있습니다. 입력은 활성 패인으로만 전달됩니다.

기본 조작은 기본 접두사인 C-b를 먼저 누른 뒤 다음 키를 입력하는 방식입니다. 필요한 화면 구성을 만들 때는 다음 세 가지 조작을 사용합니다.

따라서 여러 코딩 에이전트를 동시에 사용할 때는 작업 하나당 패인 하나를 두면 입력 대상이 분명해집니다. Cursor, Claude Code, Codex를 각각 별도 패인이나 세션에 두면 실행을 식별하기 쉽고, 분리한 동안에도 해당 패인의 로그가 유지되어 다시 연결한 뒤 각 작업의 진행 화면을 확인할 수 있습니다.

Ubuntu·Debian에는 어떻게 설치하나?

한 줄 답: 공식 설치 표의 Debian 또는 Ubuntu 항목은 다음 명령을 제시합니다.

Ubuntu와 Debian에서는 배포판 패키지를 설치한 뒤 앞서 설명한 새 세션, 분리, 재접속 순서로 사용할 수 있습니다. 설치 명령은 다음과 같습니다.

apt install tmux

공식 위키는 사전 빌드 패키지가 최신이 아닐 수 있다고 안내합니다. 이 글의 설치 예시는 해당 표에 기재된 기본 명령만 다룹니다.

FAQ는 무엇을 확인하나?

한 줄 답: 연결이 끊긴 뒤 세션 목록, 대상 이름, 활성 패인, 설치 명령을 차례로 확인합니다.

다음 표는 일반적인 확인 순서입니다. 특정 에이전트의 명령이나 개인 실행 사례를 전제로 하지 않습니다.

| 확인 항목 | 일반적인 답 |

| --- | --- |
| SSH 끊김 후에는 어떻게 확인하나? | tmux ls로 남은 세션을 확인한 뒤 tmux attach -t 이름으로 대상에 다시 붙습니다. |
| 이름 있는 세션은 어떻게 구분하나? | -s로 고유 이름을 만들고 -t로 대상 세션을 지정합니다. |
| 입력은 어느 패인으로 가나? | 한 윈도의 활성 패인 하나로만 전달됩니다. |
| Ubuntu·Debian에는 어떻게 설치하나? | apt install tmux 명령으로 설치합니다. |

관련 글은 Claude Code에 Ollama Cloud를 붙여 쓰는 후기입니다.

출처는 어디를 보면 되나?

한 줄 답: 생성·분리·재접속과 화면 구성은 공식 위키와 매뉴얼의 해당 항목에서 확인할 수 있습니다.

아래 네 문서는 이 글에서 다룬 기본 동작과 구조를 설명합니다. 설치 명령과 세션·윈도·패인의 정의도 각 공식 문서에서 확인할 수 있습니다.

공식 위키 홈

시작 안내

설치 표

매뉴얼 페이지

도구 구독이 부담되면 할인 경로만 보시면 됩니다.