직렬 포트를 모니터링·스니핑·디버깅·로그 기록하기

이 페이지에서는 장치 간(PC, 컨트롤러, 임베디드 보드) 직렬 통신을 분석하는 세 가지 방법과 왜 SerialTool의 COM 스니퍼가 종종 최적의 해법인지 알아봅니다: 소프트웨어만, 배선 불필요, 투명, 그리고 모니터/스니퍼/디버거/로거 용도로 며칠 동안도 안정적으로 사용 가능.

여기에서 다루는 내용

• 챕터 1: 모니터링이 COM 포트에서 무엇을 의미하는지, 바이트/비트의 구조와 직렬이 이를 전송하는 방식(시작/데이터/패리티/정지), 그리고 TX/RX·보드레이트.
• 챕터 2: 두 개의 USB↔직렬 어댑터로 물리적 스니핑을 하는 고전적 방법: 두 장치의 TX 라인에 RX만 연결하고 GND를 공유합니다. 간단한 모니터/로거에 적합합니다.
• 챕터 3: 동일한 개념을 마스터 PC와 타깃 장치의 통신(USB↔직렬/RS-232/RS-485)을 통해 적용 (같은 프로토콜, 다른 물리 계층). Modbus RTU/ASCII 개요와 산업/CNC/임베디드 활용 사례(디버그, 펌웨어, 리버스 엔지니어링) 포함.
• 챕터 4: 왜 SerialTool의 COM 스니퍼를 쓰는 것이 종종 유리한지: 다른 소프트웨어가 이미 연 포트의 데이터, IOCTL, 신호, 매개변수를 가로채는 Windows 커널 드라이버 기반 직렬 포트 모니터. 케이블 없음, 정밀한 필터, pcap/pcapng로 내보내기 (예: Wireshark), 그리고 장시간 캡처 안정성.

서드파티 소프트웨어를 빠르게 분석하거나 애플리케이션을 지속적으로 모니터링하려면 챕터 4 – COM 스니퍼부터 시작하세요: 테스트 벤치를 만들지 않고도 모니터·스니프·디버그·로그하는 가장 빠른 방법입니다.

챕터 1 – COM 포트에서 데이터 모니터링

1.1 “직렬 포트를 모니터링한다”는 의미

COM(직렬) 포트를 모니터링한다는 것은 PC와 장치 사이의 통신 라인을 오가는 바이트를 실시간으로 관찰하는 것입니다. 보통 두 방향을 구분합니다: TX(PC→장치 전송)와 RX(장치→PC 수신). 좋은 모니터는 데이터를 텍스트(ASCII/UTF-8 해석)와 16진수(HEX, 원시 바이트)로 모두 보여줍니다.

1.2 바이트와 비트: 논리 표현 vs. 직렬 전송

텍스트 Hello를 입력하면 다섯 문자는 다섯 개의 ASCII 바이트, 16진수로 48 65 6C 6C 6F로 변환됩니다. SerialTool의 바이트 뷰어 같은 도구는 각 바이트 내부의 개별 비트 논리 파형을 보여줍니다.

논리 보기에서 바이트를 읽는 법

• 차트는 바이트마다 8개의 데이터 비트(b7…b0)를 표시합니다. 메모리에서는 이를 MSB→LSB(상위→하위 비트)로 나열할 수 있습니다.
• 이 표현에는 아직 직렬 프로토콜 요소(시작, 패리티, 정지)가 포함되지 않으며, 선로 상의 전송 순서를 반영하지 않습니다.

직렬 포트에서 바이트가 전송되는 방식

실제 RS-232/TTL 라인에서 각 바이트는 직렬 프레임 형식으로 캡슐화됩니다:

시작(1비트, 논리 “0”) → 데이터(7/8비트, LSB부터 전송) → 패리티(옵션) → 정지(1비트 이상, 논리 “1”).

• 유휴: TX 라인은 논리 “1”(mark)로 안정. 시작 비트가 올 때까지 1을 유지합니다.
• 시작 비트: “0”(space)로의 전이가 바이트의 시작을 알립니다.
• 데이터 비트: 데이터 비트는 LSB 우선 순서(최하위 비트부터)로 전송됩니다.
• 정지 비트: 1로 1비트 이상 유지하여 유휴 상태를 복원합니다.
• 보드레이트: 각 비트의 길이를 결정합니다(예: 9600baud에서는 비트당 약 104.17 µs).

RS-232 vs. TTL 참고

• TTL(3.3 V/5 V의 UART) 레벨에서는 “1”이 High, “0”이 Low입니다.
• RS-232 레벨에서는 전압이 반전됩니다(논리 “1” ≈ 음전압, “0” ≈ 양전압). 하지만 시작/데이터/정지 순서는 동일합니다.

간단 예: “Hello” 전송 시간

8N1 구성(시작 1, 데이터 8, 정지 1)에서는 바이트당 선로에 10비트가 사용됩니다. 9600baud이면 약 960 바이트/초. 5바이트(“Hello”)에는 약 5.21 ms가 걸립니다.

챕터 2 – 두 개의 USB-직렬 어댑터로 직렬 통신 모니터/스니프·디버그·로그

2.1 목적

장치 1과 장치 2 사이에 오가는 바이트를 통신을 방해하지 않고 관찰·디버그· 로그하기 위한 비침투적 직렬 모니터/스니퍼를 구성합니다.

2.2 전기적 연결(수동 탭핑)

• COM5(USB-직렬 #1): 어댑터의 RX 핀을 장치 1의 TX에 연결(장치 1이 보내는 데이터 스니핑).
• COM6(USB-직렬 #2): 어댑터의 RX 핀을 장치 2의 TX에 연결(장치 2가 보내는 데이터 스니핑).
• 공통 GND: 두 USB-직렬 어댑터의 GND를 두 장치의 GND와 연결(논리 레벨 기준 공유).
• 어댑터의 TX는 버스에 연결하지 마세요: 하이 임피던스 수신 전용 모드로 선로를 방해하지 않습니다.
• 전원 공급 금지: 어댑터의 5V/3.3V로 장치를 구동하지 않습니다(VCC는 탭핑에 사용하지 않음).

레벨 참고: 이 방법은 UART/TTL(3.3/5 V) 또는 호환 드라이버가 있는 버스에 적용됩니다. RS-232(±12 V)의 경우 TTL RX를 직접 연결하지 마세요: RS-232↔USB 컨버터 또는 전용 RS-232 탭/모니터가 필요합니다. 즉 RS-232 라인을 로그하려면 적절한 하드웨어를 사용하세요.

2.3 보드레이트 찾기와 설정

정확히 디코딩하려면 보드레이트와 파라미터가 장치와 일치해야 합니다(예: 9600/8N1). 모를 경우:

• 장치 또는 프로토콜 문서를 확인합니다.
• 가장 흔한 보드레이트(9600, 19200, 38400, 57600, 115200…)를 시도합니다.
• 오실로스코프/로직 애널라이저로 측정: 비트 길이는 Tbit=1/baud (예: 9600baud ≈ 비트당 104.17 µs).

2.4 SerialTool로 두 COM 포트 열기

1. 어댑터를 연결하면 시스템에 두 포트(예: COM5, COM6)가 보입니다.
2. SerialTool에서 두 세션을 엽니다:
   • 세션 A → COM5, 장치와 동일한 보드/패리티/정지 설정(예: 115200/8N1).
   • 세션 B → COM6, 세션 A와 동일한 파라미터.
3. 둘 다 모니터(RX 전용)로 설정: COM5에는 장치 1이 보낸 바이트, COM6에는 장치 2가 보낸 바이트가 보입니다.
4. 디버그에는 HEX 보기와 타임스탬프를, 로깅에는 파일(CSV/pcap/raw)로 저장하여 후분석합니다.

이 시나리오에서 여러분은 수동 물리적 중간자로 동작합니다: 신호를 변경하지 않고 전기적으로 모니터/스니핑합니다.

2.5 이 예에서 제외한 제어 핀

다이어그램은 TX/RX 데이터에 초점을 맞추며 제어 핀(RTS/CTS, DTR/DSR, DCD, RI 등)은 모니터링하지 않습니다. 많은 응용에서는 불필요하지만, 하드웨어 플로우 컨트롤을 사용한다면 전용 프로브로 해당 라인을 “탭”할 수 있습니다.

추가 자료: RS-232 (위키피디아), RS-232 – 신호, 하드웨어 플로우 컨트롤, UART.

2.6 안정적인 모니터/스니퍼를 위한 팁

• 짧은 케이블과 견고한 공통 GND를 사용하고, 그라운드 루프를 피하세요.
• 대부분의 UART 드라이버는 하나의 TX 라인에 두 개의 RX 입력(팬아웃)을 허용하지만, 불필요한 부하를 피하세요.
• 두 세션의 포트 파라미터(보드, 데이터, 패리티, 정지)를 항상 일치시키세요.
• RS-485 같은 차동 버스에는 전용 어댑터와 다른 탭핑 규칙이 필요합니다.

이 기법을 사용하면 두 개의 USB-직렬 어댑터 + SerialTool이라는 일반 장비만으로 장치 간 직렬 통신을 안정적으로 모니터·스니프·디버그·로그할 수 있습니다.

챕터 3 – “마스터 PC”와 “타깃 장치” 사이의 직렬 링크 스니핑/모니터링

3.1 목적과 개념

마스터 PC의 소프트웨어와 타깃 장치 사이를 오가는 바이트를 모니터·스니프하면서도 통신을 방해하지 않으려 합니다. 이는 전형적인 수동 물리적 중간자 방식으로, 두 개의 USB-직렬 어댑터가 RX만 연결되어 양 방향을 각각 “읽습니다”. 디버그, 프로토콜 분석, 로거(감사/리버스 엔지니어링)로 유용합니다.

3.2 연결(단계별)

1. COM5(스니핑 PC) → 어댑터 RX를 장치 TX에 연결(타깃이 보내는 내용 청취).
2. COM6(스니핑 PC) → 어댑터 RX를 PC TX에 연결(마스터 PC 명령 청취).
3. 두 어댑터와 두 장치 간 공통 GND 연결(기준 공유).
4. 스니핑 PC의 어댑터 TX는 연결하지 않음: 수신 전용(고임피던스)으로 선로를 방해하지 않습니다.

SerialTool에서 COM5와 COM6 두 세션을 열고, 둘 다 마스터/장치가 사용하는 것과 동일한 보드레이트/형식(예: 115200-8N1)을 설정합니다. 보드레이트를 모르면 공통 값을 시도하거나 오실로스코프/로직 애널라이저로 비트 시간을 측정하세요.

3.3 동일한 프로토콜, 다른 레벨: UART/TTL, RS-232, RS-485

비동기 직렬 프로토콜(시작, 7/8 데이터 비트 LSB 우선, 선택적 패리티, 1+ 정지)은 동일합니다. 달라지는 것은 비트가 이동하는 물리 레벨입니다:

• UART/TTL(3.3 V/5 V): 단말 신호, “1” High / “0” Low.
• RS-232: 반전되고 ± 전압(일반적으로 ±3…±12 V), 여전히 단말.
• RS-485: A/B 페어의 차동, 종종 하프 듀플렉스 멀티드롭; 공통 기준 접지 권장.

따라서 적합한 어댑터를 사용하세요: UART에는 USB↔TTL, RS-232에는 USB↔RS-232, RS-485에는 USB↔RS-485. 프레임은 동일하지만, 전기 레벨과 토폴로지(차동/종단)는 다릅니다.

3.4 사용처(CNC, 산업 등)

이 구성은 CNC, 산업 기계, PLC/HMI, 로보틱스, 저울, POS, 센서, 계측기, 빌딩 오토메이션 등 PC/PLC가 직렬로 장치를 제어하는 시스템에서 흔합니다. 여기서 설명한 스니핑 방식은 기능 분석, 고장 진단, 명령 추적, 검증을 위해 트래픽을 모니터/스니프/디버그/로그할 수 있게 합니다.

3.5 직렬 위의 Modbus

직렬 포트는 산업에서 널리 쓰이는 마스터/슬레이브(현재는 클라이언트/서버) 프로토콜인 Modbus RTU/ASCII를 자주 운반합니다. 마스터가 요청( 코일·레지스터 읽기/쓰기 )을 보내면 장치가 응답합니다. SerialTool에는 진단/테스트를 위한 Modbus 클라이언트가 포함되어 있으며, 주소/기능/데이터/CRC가 보이는 원시 프레임 확인에 유용한 모니터/HEX 뷰어도 제공합니다.

3.6 펌웨어 업데이트와 파라미터화

임베디드 세계에서는 펌웨어 업데이트나 타깃에 파라미터 전달에 직렬이 널리 사용됩니다. 예: 커스텀 보드의 부트로더, Arduino 같은 생태계, 다양한 MCU. 여기서 개발자는 두 가지 필요가 있을 수 있습니다:

1. 타깃과 통신하는 애플리케이션을 디버그(명령, 타이밍, 오류 확인).
2. 기존 프로토콜의 리버스 엔지니어링(“폐쇄형” 마스터 소프트웨어가 보드와 통신; 메시지를 스니핑해 이해한 뒤 자체 소프트웨어로 재현).

3.7 실무 노트와 도구

• 보통 두 대의 PC(마스터·스니핑)와 양방향 스니핑을 위한 최소 두 개의 USB-직렬 컨버터가 필요합니다.
• RS-232에는 RS-232 탭/컨버터를, RS-485에는 A/B 단자에 수신 전용 인터페이스를 연결 (종단과 극성 준수). 하프 듀플렉스 RS-485에서는 타이밍으로 방향을 유추합니다.
• 제어 핀(RTS/CTS, DTR/DSR, DCD, RI)은 제외했습니다; 시스템이 하드웨어 플로우 컨트롤을 쓰면 전용 프로브를 고려하세요.
• SerialTool에서 HEX 보기, 타임스탬프를 켜고 로거(텍스트/CSV/pcap)로 저장해 후분석할 수 있습니다.

요약: 직렬 프로토콜(비동기 프레임)은 같고, 물리 레벨(TTL/RS-232/RS-485)은 다릅니다. 수동 두 RX 탭핑과 SerialTool 같은 소프트웨어로 마스터 PC와 타깃 장치 간 통신을 신뢰성 있게 모니터·스니프·디버그·로그할 수 있습니다.

챕터 4 – COM 스니퍼: 물리 배선 없이 모니터/스니프/디버그/로그

4.1 COM 스니퍼가 하는 일

COM 스니퍼는 다른 프로그램이 이미 연 COM 포트의 통신을 가로채는 직렬 포트 모니터로, 케이블을 건드리거나 추가 하드웨어 없이, 마스터 PC나 타깃 장치의 동작에 영향을 주지 않고 전체 트래픽(TX/RX)을 모니터·스니프·디버그·로그할 수 있게 합니다.

4.2 동작 방식: 커널 드라이버

핵심은 Windows의 커널 드라이버로, 직렬 포트 스택에 끼어들어 선택적으로 관찰합니다:

• 명확히 방향이 구분된 데이터 버퍼 읽기/쓰기(TX ↔ RX);
• IOCTL(Input/Output Control): 열기/닫기, 보드/패리티/정지 설정, 타임아웃, 제어 신호(RTS/DTR/CTS/DSR/DCD/RI) 등;
• 이벤트/신호와 포트 상태(라인 상태, 모뎀 상태).

드라이버는 강력하지만 인터페이스는 간단합니다: 타입별(데이터만, 구성 IOCTL만, 신호만 등) 필터링하여 필요한 것에 집중할 수 있습니다. 장시간(수시간/수일) 안정적 캡처를 염두에 두고 설계되어 자체 앱이나 서드파티 앱을 모니터링하기 좋습니다. 참고: 커널 모드 드라이버에 의존하므로 Windows에서만 동작합니다.

4.3 물리 배선보다(많은 경우) 더 나은 이유

• 두 PC + 두 USB-직렬의 “랩” 불필요: 시간 절약 및 장애 지점 감소.
• 전기적 영향 제로: 선로 부하 없음, 접지 루프 위험 없음.
• 앱과 드라이버 사이의 모든 것 확인: 데이터, IOCTL, 신호, 다중 포트 동시 관찰 가능.

4.4 프로토콜 분석을 위한 로깅과 내보내기

로거(텍스트/CSV)로 바로 파일에 저장하거나 pcap/pcapng로 내보내 Wireshark에서 분석할 수 있습니다. 이는 Modbus RTU/ASCII 같은 산업용 프로토콜에 매우 유용합니다: 프레임과 타임스탬프로 타이밍, CRC, 기능 시퀀스 등을 검증할 수 있습니다.

4.5 관찰 가능한 항목

• TX/RX 데이터를 분리해 ASCII·HEX로, 타임스탬프와 함께 표시;
• 소프트웨어가 설정한 포트 파라미터(보드, 7/8비트, 패리티, 정지, 타임아웃);
• 제어 신호 및 IOCTL(RTS, DTR, CTS, DSR, DCD, RI)과 상태 변화;
• 열기/닫기 이벤트와 오류(오버런, 프레이밍, 패리티).

4.6 사용 시나리오

• 코드/배선 변경 없이 직렬 애플리케이션 디버그;
• 서드파티 애플리케이션의 장기 모니터링(감사/진단);
• 독점 프로토콜의 리버스 엔지니어링(법률이 허용하는 범위 내)으로 자체 소프트웨어에서 기능 재현;
• 표준 프로토콜(예: Modbus)과 핸드셰이킹 신호 검증.

4.7 비고와 추가 자료

COM 스니퍼는 비동기 직렬 프로토콜(시작/데이터/패리티/정지)의 논리 수준에서 시스템 레벨로 동작합니다. 애플리케이션이 서로 다른 물리 레벨(UART/TTL, RS-232, RS-485)을 사용하더라도, 캡처는 전기 레벨 위의 Windows COM 포트 스택에서 이뤄지므로 동일합니다.

유용한 링크: Serial port · UART · RS-232 · RS-485 · IOCTL · Windows 커널 드라이버 · Wireshark · Modbus.

요컨대, SerialTool의 COM 스니퍼는 다른 프로그램이 연 직렬 포트를 모니터·스니프·디버그·로그하기 위한 “소프트웨어 전용” 솔루션으로, 신뢰할 수 있는 커널 드라이버, 정밀한 필터, 고급 분석을 위한 내보내기를 제공합니다.