라즈베리파이와 5V I2C 센서를 함께 쓴다면

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

라즈베리파이에 5V 센서 모듈을 바로 꽂았는데 값까지 정상적으로 나오면 안심하기 쉽습니다. 저도 온습도 센서와 LCD 모듈을 연결한 첫날에는 그렇게 판단했습니다. 하지만 며칠 뒤 라즈베리파이가 간헐적으로 센서를 놓치고, 재부팅 후에는 I2C 장치 검색 결과까지 달라지는 현상을 겪었습니다.

원인은 코드가 아니라 3.3V와 5V가 섞인 I2C 통신 전압이었습니다. 이후 양방향 로직 레벨 컨버터를 넣어 여러 센서를 실제로 운용하면서 확인한 장단점과 배선 요령을 정리했습니다. 같은 조합을 계획하고 있다면 ‘통신이 되느냐’보다 ‘오래 연결해도 안전하냐’를 먼저 살펴보는 편이 좋습니다.

직결했을 때 잘 작동한다는 착각부터 생겼습니다

I2C 풀업 전압은 센서 전원과 별개의 문제였습니다

I2C의 SDA와 SCL은 장치가 신호선을 직접 높은 전압으로 밀어 올리는 방식이 아니라, 낮은 상태로 끌어내리는 오픈드레인 구조를 주로 사용합니다. 신호선이 HIGH로 돌아갈 때는 연결된 풀업 저항의 전압을 따릅니다. 센서 모듈에 5V 풀업 저항이 실장돼 있다면 라즈베리파이의 GPIO 쪽에도 5V에 가까운 전압이 걸릴 가능성이 생깁니다.

제가 사용한 센서 모듈도 데이터시트만 보면 3.3V 동작이 가능했지만, 완제품 기판에는 VCC로 연결된 풀업 저항이 붙어 있었습니다. 전원을 5V로 공급한 채 SDA와 SCL을 직결하자 짧은 테스트에서는 측정값이 잘 나왔습니다. 문제는 통신 성공 여부만 보고 전기적 안전성까지 검증했다고 착각한 점이었습니다.

아두이노의 기본 구조와 활용 범위를 보면 센서 실습이 간단해 보이지만, 5V 계열 아두이노에서 쓰던 모듈을 3.3V 라즈베리파이로 옮길 때는 신호 전압을 다시 확인해야 합니다. 특히 ‘아두이노에서 잘 됐던 센서’라는 경험은 라즈베리파이 직결의 안전성을 보장하지 않습니다.

• 멀티미터로 유휴 전압 측정: 통신을 멈춘 상태에서 SDA와 SCL이 몇 V로 올라가는지 확인했습니다. 약 5V가 측정되면 직결하지 않는 쪽이 안전합니다.
• 모듈 회로 확인: 기판의 4.7kΩ, 10kΩ 표기 저항이 VCC와 신호선 사이에 연결됐는지 추적했습니다. 동일한 센서 칩이라도 모듈 제조사에 따라 구성이 달랐습니다.
• 3.3V 구동 시험: 센서 모듈 전체가 3.3V에서 안정적으로 작동한다면 별도 변환기 없이 해결될 수 있습니다. 다만 히터나 백라이트가 있는 모듈은 소비 전류와 밝기가 달라질 수 있습니다.
• 절대최대정격 확인: ‘입력 HIGH로 인식되는 전압’과 ‘핀에 허용되는 최대 전압’은 다른 항목이므로 데이터시트를 구분해 읽었습니다.

사용 팁: I2C 스캐너에 주소가 표시되는 것은 배선과 프로토콜의 일부가 작동한다는 뜻일 뿐입니다. GPIO가 안전한 전압을 받고 있다는 증거는 아닙니다.

BSS138 양방향 변환기를 넣고 달라진 점

HV와 LV를 구분하니 배선은 생각보다 단순했습니다

제가 선택한 것은 BSS138 MOSFET과 풀업 저항이 들어간 4채널 양방향 로직 레벨 컨버터였습니다. 온라인 부품몰에서 흔히 판매되는 저가형 보드라 진입 비용이 낮고, SDA와 SCL 두 채널만 사용하면 됩니다. 별도의 방향 제어 핀이 필요 없다는 점은 I2C 센서 연결에서 확실한 장점이었습니다.

배선은 라즈베리파이의 3.3V를 LV, 센서 전원인 5V를 HV에 연결하고 양쪽 GND를 공통으로 묶었습니다. 라즈베리파이 SDA와 SCL은 LV 측 채널에, 센서 모듈의 SDA와 SCL은 대응하는 HV 측 채널에 연결했습니다. 채널 순서를 잘못 맞추는 것보다 더 자주 한 실수는 공통 접지를 빠뜨리는 것이었습니다.

변환기를 넣은 뒤 유휴 상태에서 LV 측은 약 3.3V, HV 측은 약 5V로 분리됐습니다. 센서 인식 실패도 줄었고 장시간 구동할 때 심리적인 부담도 훨씬 작았습니다. 아두이노 기반 실습 환경이 어떤 역할을 하는지는 아두이노 관련 지식백과 설명에서도 참고할 수 있지만, 보드를 바꿀 때는 기존 예제의 전압 조건까지 그대로 따라가면 안 됩니다.

싼 모듈에도 속도와 배선 길이라는 한계가 있었습니다

장점만 있었던 것은 아닙니다. 브레드보드 점퍼선을 40cm 이상 늘리고 센서 세 개를 병렬로 연결하자 400kHz 설정에서 간헐적인 NACK가 다시 나타났습니다. 변환기 양쪽에 이미 풀업 저항이 있고 각 센서 모듈에도 저항이 달려 있어, 병렬 합성 저항이 지나치게 낮아진 것도 영향을 줬습니다.

처음에는 풀업 저항이 많을수록 상승 파형이 좋아질 것이라 생각했습니다. 그러나 저항값이 너무 낮으면 장치가 LOW를 만들 때 더 큰 전류를 흘려야 하고, 일부 센서는 충분히 낮은 전압까지 끌어내리지 못했습니다. 반대로 저항값이 너무 높거나 배선 용량이 크면 상승 시간이 길어집니다. 결국 부품 수가 아니라 버스 전체의 풀업 구성을 봐야 했습니다.

1. 센서 하나만 연결하고 100kHz로 시작해 I2C 주소를 확인했습니다.
2. 두 번째 센서를 추가할 때마다 10분 이상 연속 읽기를 실행해 오류 횟수를 기록했습니다.
3. 통신이 불안하면 먼저 배선을 20cm 이하로 줄이고 전원 옆에 디커플링 커패시터를 배치했습니다.
4. 센서 모듈의 풀업 저항을 무작정 제거하지 않고 회로도와 실측 저항값을 먼저 확인했습니다.
5. 오실로스코프가 있다면 LV와 HV 양쪽의 상승 시간, LOW 전압, 링잉을 같은 조건에서 비교했습니다.

제 환경에서는 짧은 배선과 100kHz 조합이 가장 안정적이었습니다. 400kHz가 꼭 필요한 프로젝트라면 단순 BSS138 보드만 추가하고 끝낼 것이 아니라 배선 용량과 풀업 저항, 변환기의 속도 특성을 함께 검토해야 합니다. 임베디드 코딩 도구의 역할은 디바이스 드라이버 통합개발환경의 개요처럼 개발 효율과 관련되지만, 소프트웨어 도구가 나쁜 전기 신호까지 고쳐주지는 못합니다.

체감상 가장 효과가 컸던 조치: 통신 속도를 먼저 낮추고 점퍼선을 짧게 만든 다음, 필요할 때만 풀업 저항을 조정했습니다. 처음부터 저항을 떼어내는 방식은 원인 비교가 어려웠습니다.

온습도 센서와 LCD를 사흘 연속 돌려본 과정

첫날의 정상 동작보다 셋째 날의 오류 기록이 유용했습니다

실제 테스트에는 라즈베리파이, 5V 전원에서 사용하는 I2C LCD, 온습도 센서 모듈, BSS138 4채널 변환기를 사용했습니다. LCD 백라이트 때문에 센서 전체를 3.3V로 낮추는 방식은 선택하지 않았습니다. 라즈베리파이 측 전원과 센서 측 전원을 분리하되 접지는 공통으로 연결하고, 5초마다 측정값과 통신 오류를 로그 파일에 저장했습니다.

첫 번째 시도에서는 센서와 LCD를 브레드보드 양쪽 끝에 놓아 점퍼선 길이가 길었습니다. 약 네 시간 뒤 LCD 갱신이 한 번 멈췄고, 로그에는 연속 두 차례의 원격 입출력 오류가 남았습니다. 프로그램에서 무조건 재시도하도록 만들면 화면은 다시 살아났지만, 이것만으로는 하드웨어 원인을 숨기는 임시 처방에 가까웠습니다.

• 오류 전 상황: LCD 백라이트가 켜지고 센서 읽기가 동시에 시작될 때 실패가 집중됐습니다.
• 첫 조치: SDA와 SCL 점퍼선을 약 15cm로 줄이고 전원선과 나란히 길게 묶지 않았습니다.
• 두 번째 조치: 센서 전원 가까이에 0.1μF 세라믹 커패시터를 추가하고 전원 공급 장치의 5V 출력을 다시 측정했습니다.
• 세 번째 조치: 버스 속도를 400kHz에서 100kHz로 낮추고, 읽기 실패 시 50ms 뒤 최대 두 번만 재시도하도록 코드를 바꿨습니다.

두 번째 운용에서는 24시간 동안 센서 주소와 LCD 주소가 모두 유지됐습니다. 둘째 날에는 일부러 LCD를 빠르게 갱신해 버스 사용량을 늘렸지만 통신이 끊기지 않았습니다. CPU 사용률이나 파이썬 라이브러리만 의심하던 때와 달리, 전압·배선·속도를 하나씩 바꾸니 어떤 조치가 효과를 냈는지 분명하게 볼 수 있었습니다.

전원을 다시 넣는 순간까지 기록해 보았습니다

셋째 날에는 실제 사물인터넷 장치에서 흔한 상황을 재현하려고 5V 센서 전원을 잠시 끊었다가 다시 연결했습니다. 라즈베리파이는 계속 켜 둔 상태였습니다. 센서 측 전원이 꺼졌을 때 프로그램은 오류를 기록했고, 전원이 복구된 뒤에는 장치 주소를 다시 검색한 다음 측정을 재개했습니다. 이 과정에서 변환기의 HV 측이 비정상적으로 역급전되는지도 멀티미터로 살폈습니다.

복구 코드는 오류가 발생할 때마다 무한 재시도하지 않도록 구성했습니다. 두 번 실패하면 해당 센서를 3초 동안 대기 상태로 두고, 다시 주소 확인과 초기화 명령을 수행했습니다. 덕분에 LCD 갱신 루프는 계속 움직였고 하나의 센서 장애가 전체 프로젝트를 멈추게 하지 않았습니다. 여러 센서를 운영한다면 이러한 장치별 오류 격리가 단순한 예외 처리보다 실용적이었습니다.

1. 오전 9시, 라즈베리파이와 센서 전원을 동시에 넣고 LV 3.3V와 HV 5V를 확인했습니다.
2. 오전 11시, LCD 갱신 주기를 10초에서 1초로 줄였지만 오류 카운터는 증가하지 않았습니다.
3. 오후 2시, 센서 측 5V만 10초간 차단하자 두 번의 읽기 실패가 기록됐습니다.
4. 전원 복구 3초 뒤 프로그램이 주소를 다시 찾고 온습도 측정을 이어갔습니다.
5. 다음 날 오전까지 누적 로그를 확인한 결과 추가 NACK나 버스 멈춤은 없었습니다.

이 사례에서 가장 만족스러웠던 부분은 값이 한 번 잘 읽힌 것이 아니라, 전원 변화가 생겨도 다른 장치가 함께 멈추지 않았다는 점입니다. 반면 변환기 보드와 배선이 추가되어 공간을 차지하고 접점도 늘어난다는 단점은 남았습니다. 그래서 최종 제작판에서는 모듈을 점퍼선으로 매달지 않고 커넥터와 짧은 패턴으로 고정할 계획입니다.

새벽에 저장된 마지막 로그에는 온도와 습도, LCD 갱신 횟수, 오류 카운터 0이 함께 남아 있었습니다. 저는 그 기록을 확인한 뒤에야 ‘센서가 연결됐다’가 아니라 3.3V 라즈베리파이와 5V I2C 센서가 같은 버스에서 안정적으로 운영된다고 판단했습니다.