디버깅 인터페이스, 시제품 단계에서 결정해야 할 양산 후 진단 경로

양산 후의 진단 가능성은 시제품 PCB에 어떤 인터페이스를 남겨두는지로 결정됩니다.

하드웨어 제품이 출시되고 사용자로부터 동작 이상 클레임이 들어오는 순간, 가장 먼저 부딪히는 질문은 무엇이 문제인지 어떻게 확인할 것인가입니다. 시제품 단계에서 개발자가 PCB에 직접 디버거를 연결해 펌웨어 상태를 들여다보던 그 경로가, 양산 PCB에서는 사라져 있는 경우가 많습니다. 양산 단가를 낮추기 위해, 또는 외관 깔끔함을 위해 디버깅 인터페이스를 제거하고 출하했기 때문입니다.

디버깅 인터페이스가 사라진 양산품은 동작 이상이 발생했을 때 원인 추적이 거의 불가능합니다. 사용자에게 받은 보드를 다시 개발 단계의 상태로 되돌릴 수 없고, 펌웨어를 재기록하거나 메모리 값을 확인하는 일도 어려워집니다. 결과적으로 A/S 처리가 단순 교환으로만 이루어지고, 같은 문제가 반복되어도 원인이 끝까지 밝혀지지 않습니다. 이 문제의 출발점은 시제품 단계의 디버깅 인터페이스 설계 결정입니다.

디버깅 인터페이스의 세 가지 종류

1. JTAG·SWD - MCU의 가장 깊은 진단 경로

MCU 내부의 메모리, 레지스터, 펌웨어 실행 흐름까지 직접 들여다볼 수 있는 인터페이스입니다. JTAG은 표준 디버깅 프로토콜이고, SWD는 ARM Cortex 계열에서 핀 수를 줄인 변형입니다. 펌웨어 다운로드, 단계별 실행, 변수 확인 같은 작업이 가능해 시제품 단계에서는 필수적입니다. 양산 후에는 보안과 단가 측면에서 제거 후보가 됩니다.

2. UART 콘솔 - 가장 가벼운 진단 출력

펌웨어가 자신의 동작 상태를 텍스트로 출력하는 인터페이스입니다. 부팅 로그, 오류 메시지, 센서 값을 외부로 내보낼 수 있어 동작 이상 진단에 매우 유용합니다. 두 개의 핀만으로 구성되어 양산 PCB에 남겨두기에도 부담이 적습니다. JTAG보다 깊이는 얕지만 양산 후 진단 경로로는 가장 실용적입니다.

3. 테스트 포인트 - 회로 신호 직접 측정

PCB에 별도의 패드나 핀을 두어 회로 신호를 오실로스코프나 멀티미터로 직접 측정할 수 있게 하는 인터페이스입니다. 전원 전압, 클럭 신호, 통신 라인의 파형을 점검할 수 있어 회로 자체의 동작 이상 진단에 필요합니다. 양산에서 제거해도 다시 만들기 어렵지 않아 보이지만, 실제로는 일단 양산이 시작되면 다시 추가하기 어렵습니다.

테스트 포인트는 양산 PCB의 진단 가능성을 보존하는 가장 단순한 장치입니다.

양산 단계에서 자주 일어나는 잘못된 제거

• JTAG·SWD 핀 완전 제거: 보안과 단가를 이유로 PCB에서 패드까지 모두 제거하는 경우. 양산 후 동작 이상이 발생했을 때 펌웨어 진단이 불가능해집니다.
• UART 콘솔 미연결: 펌웨어에는 콘솔 출력 코드가 있지만 PCB에 외부 연결 패드가 없는 경우. 펌웨어를 다시 빌드해서 굽기 전에는 로그를 볼 수 없습니다.
• 테스트 포인트 누락: 회로 신호를 측정할 수 있는 패드가 시제품에는 있었지만 양산 도면에서 정리되어 사라진 경우. 양산 PCB로 회로 측정이 어려워집니다.
• 부트 모드 진입 불가: 펌웨어가 비정상 상태에 빠졌을 때 외부에서 부트 모드로 강제 진입시키는 핀이 없는 경우. 펌웨어 복구가 불가능해집니다.
• 로그 저장 영역 부재: 동작 중의 오류를 디바이스 내부에 저장해두는 영역이 없어, A/S 단계에서 과거 오류를 추적할 수 없는 경우.

제거 vs 보존의 판단 기준

모든 디버깅 인터페이스를 양산 PCB에 그대로 남겨야 한다는 의미는 아닙니다. 보안 측면에서 외부에 노출된 JTAG은 펌웨어 유출의 경로가 될 수 있고, 외관 측면에서 노출된 커넥터는 디자인을 해칠 수 있으며, 단가 측면에서 커넥터 부품은 비용이 됩니다. 그래서 제거가 정당화되는 경우도 있습니다. 문제는 일률적으로 제거하는 흐름이지, 선택적으로 보존하는 전략입니다.

가장 균형 잡힌 흐름은 외부 커넥터는 제거하되 PCB 패드는 남겨두는 방식입니다. 커넥터가 없으니 사용자가 접근할 수 없지만, A/S 센터에서 보드를 열고 패드에 핀을 대면 진단이 가능합니다. 보안과 외관, 단가를 모두 살리면서 진단 경로를 보존하는 절충입니다. 또한 펌웨어 차원에서 JTAG 보안 잠금을 적용하면 패드가 있어도 외부에서 펌웨어를 읽어갈 수 없게 됩니다.

펌웨어 진단 로그 설계

하드웨어 인터페이스만큼 중요한 것이 펌웨어 차원의 진단 로그 설계입니다. 디바이스가 동작 중에 만난 오류, 재부팅 이력, 통신 실패, 배터리 상태 변화 같은 정보를 내부 메모리에 누적해두면, A/S 시점에 그 로그를 꺼내 원인을 추적할 수 있습니다.

• 오류 코드와 발생 시점: 어떤 오류가 언제 발생했는지. 시간 정보가 함께 있어야 사용자 환경과 연결됩니다.
• 재부팅 이력: 의도된 재부팅인지, 예상치 못한 다운 후 재시작인지를 구분.
• 외부 상태 변화: 통신 연결 상태, 배터리 잔량, 충전 시작·종료 시점.
• 사용자 동작 흔적: 사용자 입력이 어떤 시점에 들어왔는지. 사용자 시나리오와 오류를 연결하는 단서가 됩니다.
• 로그 추출 경로: 이 로그를 어떻게 외부로 꺼낼 것인가. 앱을 통한 동기화, A/S 센터의 직접 추출, 클라우드 자동 전송 중 한 가지 경로가 결정되어 있어야 합니다.

시제품 단계에서 결정해야 할 항목

1. 인터페이스별 보존 여부: JTAG/SWD, UART 콘솔, 테스트 포인트, 부트 모드 핀 각각에 대해 양산에서 완전 제거할지, 패드만 남길지, 외부 커넥터로 보존할지를 결정합니다.
2. 보안 잠금 설계: 외부에서 펌웨어를 읽어가지 못하도록 MCU의 보안 비트 설정을 펌웨어 출하 절차에 포함시킵니다.
3. 진단 로그 구조: 어떤 정보를 어디에 어떻게 누적할지, 그 로그를 어떻게 꺼낼지를 시제품 단계에서 결정합니다.
4. A/S 절차와 연결: A/S 센터에서 디바이스를 받았을 때 어떤 절차로 진단할지를 시제품 단계에서 그려두면 인터페이스 보존 범위가 자연스럽게 결정됩니다.
5. 양산 PCB 도면 분리: 시제품 PCB와 양산 PCB의 차이를 도면에 명확히 정의하고, 그 변형 시점을 일정에 반영합니다.

양산 후 진단 가능성은 시제품 단계의 도면 결정에서 정해집니다.

제언: 디버깅 인터페이스는 비용이 아니라 사후 운영의 자산이다