회로는 맞는데 왜 안 되지? 전자·반도체·의료장비 개발자가 자주 만나는 황당한 문제들

전자제품 개발에서 가장 무서운 문장은 가끔 이것입니다.

"회로도상으로는 아무 문제가 없습니다."

맞습니다. 회로도는 맞을 수 있습니다. 그런데 제품은 안 켜집니다. MCU는 살아 있는데 통신이 안 되고, PCB는 정상처럼 보이는데 특정 버튼을 누르면 리셋됩니다. 반도체 부품은 데이터시트상 완벽한데 실제 시스템에서는 이상하게 동작하기도 합니다.

전자·반도체·의료장비 개발에서는 이런 문제가 꽤 흔합니다.

회로도가 맞아도 PCB가 틀릴 수 있다

회로도는 논리적인 연결 관계를 보여줍니다. 반면 PCB는 실제 공간에서 전류와 신호를 전달합니다.

패턴 길이, GND 리턴 경로, 전원층, 비아, 부품 배치 등이 달라지면 실제 동작 특성이 달라질 수 있습니다.

전자회로 기판의 실제 모습

특히 전원부와 고속 신호는 회로도만 보고 판단하기 어렵습니다. 같은 네트 이름을 가지고 있어도 실제 경로가 길거나 노이즈가 많은 영역을 지나가면 문제가 발생할 수 있습니다.

전원은 멀티미터 하나로 끝나지 않는다

3.3V가 측정된다고 해서 전원이 완벽한 것은 아닙니다. 모터나 밸브가 동작하는 순간 전압이 흔들릴 수 있고, DC/DC 컨버터의 리플이 예상보다 클 수도 있습니다.

문제가 특정 동작에서만 발생한다면 부하가 변하는 순간을 오실로스코프로 확인하는 것이 도움이 됩니다.

전자부품이 실장된 PCB

전자제품 디버깅에서는 정상 상태보다 오류가 발생하는 순간이 더 중요합니다. '전압이 있다'가 아니라 '오류 순간에도 전압이 유지되는가'를 봐야 합니다.

MCU가 멀쩡한데 제품이 멈추는 이유

MCU가 프로그램을 실행하고 있어도 제품은 멈출 수 있습니다. 통신 대기 코드가 빠져나오지 못하거나, 인터럽트가 폭주하거나, 센서가 잘못된 값을 전달하거나, 상태 머신이 특정 상태에 갇힐 수 있기 때문입니다.

이때는 CPU가 살아 있는지와 시스템이 정상인지 구분해야 합니다.

반도체 부품은 데이터시트만 보면 끝일까

데이터시트는 중요한 출발점이지만 실제 시스템 조건까지 대신 검증해주지는 않습니다.

입력 전압, 부하, 온도, PCB 패턴, 주변 부품, startup sequence 등이 함께 영향을 줄 수 있습니다. 대체 부품을 사용할 때도 '핀 위치가 같다'는 이유만으로 동일한 동작을 기대하면 안 됩니다.

디지털 장비 내부의 PCB

특히 전원 IC와 아날로그 부품은 작은 전기적 차이가 시스템 성능에 영향을 줄 수 있습니다.

의료장비는 여기에 안전과 추적성이 더해진다

의료장비는 단순히 기능이 작동하는지 확인하는 것에서 끝나지 않습니다. 오류가 발생했을 때 어떤 상태로 전환되는지, 사용자가 잘못 조작했을 때 어떤 보호 동작을 하는지, 변경사항을 어떻게 검증했는지도 중요합니다.

버튼 하나를 바꾸더라도 관련 요구사항과 시험 항목의 영향 범위를 확인해야 할 수 있습니다.

전자회로용 PCB

이 때문에 의료장비 개발은 일반 소비자 전자제품보다 변경관리와 문서화가 중요한 경우가 많습니다.

오실로스코프가 알려주는 진짜 이야기

멀티미터는 평균적인 상태를 보는 데 매우 유용합니다. 하지만 순간적인 drop, spike, ringing, 노이즈 같은 현상은 오실로스코프가 훨씬 잘 보여줍니다.

예를 들어 MCU가 리셋되는 순간 전원 rail이 100mV 정도 내려갔다면 멀티미터에서는 아무 문제가 없는 것처럼 보일 수 있습니다.

오실로스코프와 전자계측 개념

따라서 전자 개발에서는 측정 장비의 특성을 이해하는 것도 중요합니다. 무엇을 측정할지뿐 아니라 어떤 장비로 측정할지를 결정해야 합니다.

가장 어려운 문제는 재현이 안 되는 문제

'한 번 발생했는데 다시 안 나타나는 오류'는 개발자를 가장 힘들게 합니다.

이런 경우에는 발생 조건을 최대한 기록해야 합니다. 온도, 전원 상태, 입력 조건, 펌웨어 버전, PCB revision, 통신 상태 등을 남기면 정상과 오류의 차이를 찾을 수 있습니다.

의료장비에서 특히 중요한 변경관리

의료장비는 제품 변경이 발생하면 영향을 받는 요구사항과 검증 항목을 찾아야 합니다. 소프트웨어 버전과 하드웨어 revision을 함께 관리하면 문제가 발생했을 때 원인을 추적하기 쉬워집니다.

개발 문서는 귀찮은 기록이 아니라 미래의 디버깅 도구입니다.

개발자가 가장 먼저 만들어야 하는 것은 재현 조건

문제를 해결하는 사람에게 가장 중요한 자료는 '증상'보다 '재현 조건'입니다. 어떤 버튼을 눌렀는지, 몇 초 뒤 발생했는지, 전원은 어떤 상태였는지, 주변 장치가 연결됐는지, 펌웨어 버전은 무엇인지 기록합니다.

하드웨어 revision과 BOM 버전까지 함께 기록하면 같은 문제가 다시 발생했을 때 훨씬 빠르게 원인을 좁힐 수 있습니다.

HW와 FW 사이의 경계에서 문제가 많이 생긴다

센서가 값을 잘못 주는지, ADC가 잘못 읽는지, 펌웨어가 값을 잘못 해석하는지 판단하려면 경계 지점의 실제 데이터를 확인해야 합니다.

UART 로그, GPIO 토글, ADC raw data, 통신 패킷, 전원 파형 등을 남기면 문제를 논리적으로 나눌 수 있습니다. 'HW냐 FW냐'를 먼저 결정하기보다 데이터가 어디에서 예상과 달라지는지 찾는 것이 효율적입니다.

의료장비라면 변경의 영향까지 기록한다

의료장비에서는 기능이 정상이라는 것 외에도 변경사항이 어떤 요구사항과 시험에 영향을 주는지 확인하는 것이 중요합니다. 작은 수정이라도 영향 분석을 남겨두면 나중에 검증 범위를 결정하기가 쉬워집니다.

결론: '회로는 맞다' 다음 질문이 중요하다

전자·반도체·의료장비 개발에서 문제를 해결하는 가장 좋은 방법은 추측을 줄이고 측정을 늘리는 것입니다.

전원은 실제 부하에서 확인하고, PCB는 신호의 리턴 경로까지 살펴보고, 반도체 부품은 시스템 조건에서 검증하며, 의료장비는 안전과 변경 영향까지 함께 봐야 합니다.

결국 회로가 맞다는 것은 출발점이지 결승선이 아닙니다. 제품은 현실에서 동작해야 하기 때문입니다.

관련 글

• MCU는 멀쩡한데 왜 제품은 멈출까? 임베디드 펌웨어 디버깅
• 의료기기는 왜 버튼 하나 바꾸기도 힘들까?