아두이노 I2C 센서 주소 미검출 원인과 복구

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

I2C 스캐너가 빈 화면을 보여줄 때의 첫 판단

센서 고장보다 배선과 전원부터 의심합니다

I2C 스캐너를 올렸는데 주소가 하나도 나오지 않으면 센서가 망가졌다고 생각하기 쉽습니다. 하지만 실제 현장에서는 센서 불량보다 전원, GND 공통, SDA/SCL 뒤바뀜이 훨씬 자주 원인입니다. 특히 아두이노와 센서 모듈을 점퍼선으로 연결한 실습 환경에서는 접촉 불량 하나만으로도 스캐너가 조용히 실패합니다.

먼저 확인할 것은 코드가 아니라 회로입니다. 아두이노는 입문용 보드로 널리 쓰이지만, 보드 종류에 따라 I2C 핀 위치가 다릅니다. 기본 개념이 필요하다면 아두이노의 개요를 참고하면 보드 기반 실습 흐름을 잡는 데 도움이 됩니다.

• UNO 계열: SDA는 A4, SCL은 A5 또는 보드에 따로 표시된 SDA/SCL 핀을 사용합니다.
• Mega 계열: SDA와 SCL 위치가 UNO와 다르므로 핀맵을 다시 확인해야 합니다.
• ESP32 계열: 기본 핀이 보드 패키지와 코드 설정에 따라 달라질 수 있어 Wire.begin(SDA, SCL) 지정이 중요합니다.
• 라즈베리파이: I2C 인터페이스 활성화 여부와 3.3V 전압 기준을 먼저 점검합니다.

스캐너가 아무 주소도 찾지 못한다면 센서를 빼고 배선만 다시 잡아보세요. 전원과 GND를 검증하지 않은 상태에서 라이브러리를 바꾸는 것은 시간을 가장 빨리 잃는 방식입니다.

주소가 안 뜨는 증상에도 종류가 있습니다

주소 미검출은 모두 같은 문제가 아닙니다. 시리얼 모니터가 멈추는 경우, 계속 "No I2C devices found"만 나오는 경우, 특정 보드에서는 보이는데 다른 보드에서는 안 보이는 경우가 각각 다릅니다. 이 차이를 기록하면 문제 해결 속도가 크게 빨라집니다.

1. 스캐너 출력 자체가 없다면 보드 업로드, 포트, 통신 속도를 확인합니다.
2. 스캐너는 돌지만 주소가 없다면 배선, 전원, 풀업 저항을 봅니다.
3. 주소가 간헐적으로 보이면 접촉 불량, 버스 길이, 노이즈 가능성이 높습니다.
4. 특정 센서만 사라지면 주소 충돌, 초기화 지연, 센서 전압 호환성을 확인합니다.

전원 전압과 GND 공통 문제의 실제 증상

전압이 맞아도 기준점이 없으면 통신은 실패합니다

I2C 통신은 SDA와 SCL 두 신호선만 보면 단순해 보이지만, 실제로는 전원 기준이 맞아야 정상 동작합니다. 센서 VCC를 3.3V에 연결하고 아두이노는 USB로 켰더라도, 두 회로의 GND가 이어져 있지 않으면 신호의 높고 낮음이 서로에게 의미가 없습니다. 이때 스캐너는 아무 주소도 찾지 못하거나 엉뚱하게 멈춥니다.

전압 문제도 흔합니다. 5V 아두이노에 3.3V 전용 센서를 직접 연결하면 처음에는 동작하는 것처럼 보이다가 반복 테스트 중 사라지는 일이 있습니다. 반대로 5V가 필요한 모듈을 3.3V에 물리면 센서 내부 회로가 켜지지 않아 주소가 나오지 않습니다. 모듈에 레귤레이터와 레벨 변환 회로가 들어 있는지, 센서 칩 자체가 어떤 전압을 요구하는지 구분해야 합니다.

• VCC 전압 측정: 멀티미터로 센서 VCC와 GND 사이를 직접 재야 합니다. 보드 핀에 표시된 전압만 믿으면 중간 접촉 불량을 놓칠 수 있습니다.
• GND 공통 확인: 컨트롤러 GND와 센서 GND가 실제로 연결되어 있는지 연속성 모드로 확인합니다.
• 전류 여유 확인: OLED, 환경 센서, ADC 모듈을 여러 개 붙이면 USB 전원만으로 부족할 수 있습니다.
• 역삽입 흔적 확인: 센서가 뜨거워졌거나 전원 LED가 비정상적으로 흐리면 바로 분리해야 합니다.

라즈베리파이에서는 전압 기준이 더 엄격합니다

라즈베리파이의 GPIO는 기본적으로 3.3V 기준입니다. 5V 센서 모듈의 SDA/SCL에 강한 풀업이 5V로 걸려 있으면 보드에 부담을 줄 수 있습니다. 라즈베리파이 I2C 센서 연결에서는 센서가 인식되는지만 볼 것이 아니라, 신호선이 어느 전압으로 끌어올려지는지까지 확인해야 합니다.

사물인터넷 장비처럼 장시간 켜둘 시스템이라면 더 보수적으로 접근하는 편이 좋습니다. 하루짜리 테스트에서는 통과해도, 온도 변화와 전원 재부팅이 반복되면 전압 여유가 작은 회로가 먼저 흔들립니다. 개발 단계에서 안정적인 기준 전압과 접지 배선을 만들어두면 배포 후 원인 모를 끊김을 줄일 수 있습니다.

전원 LED가 켜졌다는 사실은 센서가 통신 준비를 마쳤다는 뜻이 아닙니다. I2C 주소가 보여야 최소한 버스에 응답하고 있다고 판단할 수 있습니다.

풀업 저항과 버스 길이가 만드는 미검출

풀업은 많아도 문제, 없어도 문제입니다

I2C 버스의 SDA와 SCL은 오픈드레인 방식으로 동작하므로 풀업 저항이 필요합니다. 센서 모듈 하나만 연결하면 보통 모듈 내부의 4.7kΩ 또는 10kΩ 풀업으로 충분합니다. 하지만 센서 모듈을 여러 개 꽂으면 각 모듈의 풀업이 병렬로 겹쳐 전체 저항값이 지나치게 낮아질 수 있습니다. 이 경우 신호가 무겁게 동작하거나 컨트롤러가 라인을 제대로 당기지 못합니다.

반대로 브레이크아웃 보드가 아니라 센서 칩만 직접 연결했거나, 긴 케이블 끝에 모듈을 달았다면 풀업이 부족할 수 있습니다. 스캐너에서 주소가 가끔 보였다가 사라지는 증상은 이 구간에서 자주 나옵니다. 특히 브레드보드, 점퍼선, 납땜 없는 커넥터는 신호 품질을 더 나쁘게 만듭니다.

• 센서 하나만 연결: 가장 단순한 구성으로 주소가 잡히는지 먼저 봅니다.
• 풀업 저항 확인: 모듈 회로도나 실물의 R 표기를 보고 SDA/SCL 풀업 존재를 확인합니다.
• 전체 저항 계산: 4.7kΩ 풀업 모듈 네 개는 대략 1.2kΩ 수준으로 낮아집니다.
• 버스 길이 단축: 처음 테스트는 10~20cm 이내 점퍼선으로 줄여 원인을 좁힙니다.

속도를 낮추면 보이는 고장이 있습니다

기본 Wire 라이브러리는 흔히 100kHz 또는 보드 설정에 따른 속도로 동작합니다. 배선이 길거나 노이즈가 많은 환경에서는 400kHz 빠른 모드가 오히려 문제를 키웁니다. 스캐너 코드에 Wire.setClock(50000)처럼 낮은 속도를 넣었을 때 주소가 잡힌다면 센서 고장보다는 물리 계층 문제가 의심됩니다.

임베디드 개발에서는 소프트웨어와 하드웨어가 서로 핑계를 주고받는 순간이 많습니다. 이때 속도 낮추기, 센서 단독 연결, 짧은 배선 테스트는 원인을 분리하는 좋은 방법입니다. 관련 개발 환경의 개념을 넓게 보고 싶다면 디바이스 드라이버 통합개발환경의 개요처럼 하드웨어 제어와 소프트웨어 도구가 만나는 지점을 살펴보는 것도 도움이 됩니다.

1. 스캐너 코드에 I2C 클럭을 낮춰 넣습니다.
2. 센서 하나만 남기고 나머지 모듈을 모두 분리합니다.
3. 주소가 보이면 배선 길이와 풀업 중 하나가 원인일 가능성이 큽니다.
4. 주소가 여전히 안 보이면 전원, 핀맵, 센서 초기화 조건으로 범위를 옮깁니다.

주소 충돌과 라이브러리 설정을 분리하는 순서

스캐너 주소와 예제 코드 주소가 다를 수 있습니다

I2C 센서는 같은 칩이라도 모듈 제조사에 따라 주소 선택 핀이 다르게 고정되어 있을 수 있습니다. 예제 코드에는 0x76으로 되어 있는데 실제 스캐너에서는 0x77이 뜨는 식입니다. 이때 라이브러리가 나쁘다고 판단하기 전에, 스캐너가 읽은 주소를 예제 코드의 생성자나 begin 함수에 정확히 넣어야 합니다.

주소가 전혀 안 보이는 문제와 주소는 보이는데 데이터가 이상한 문제도 분리해야 합니다. 전자는 배선과 버스 문제에 가깝고, 후자는 라이브러리 설정, 레지스터 맵, 센서 모델 차이일 가능성이 큽니다. 같은 온습도 센서처럼 보여도 DHT, SHT, BME, AHT 계열은 통신 방식과 초기화 순서가 다릅니다.

• 주소 미검출: I2C 버스, 전원, 핀 연결부터 확인합니다.
• 주소 검출 후 초기화 실패: 라이브러리의 센서 모델과 주소 인자를 확인합니다.
• 값이 0 또는 고정값: 레지스터 설정, 변환 대기 시간, 센서 손상 가능성을 봅니다.
• 두 센서 중 하나만 인식: 주소 충돌 또는 모듈별 주소 점퍼 설정을 확인합니다.

주소 충돌은 멀티플렉서나 대체 센서로 풀어야 합니다

같은 주소를 가진 센서 두 개를 한 버스에 올리면 컨트롤러 입장에서는 둘을 구분할 수 없습니다. 주소 선택 핀이 있는 센서라면 납땜 점퍼를 바꾸거나 ADDR 핀을 전원 또는 GND에 연결해 다른 주소로 설정합니다. 주소 선택이 불가능하다면 TCA9548A 같은 I2C 멀티플렉서를 사용해 채널을 나누는 방식이 현실적입니다.

센서 연결 단계에서는 스캐너 결과를 작업 노트에 남겨두는 습관이 좋습니다. 예를 들어 OLED는 0x3C, 기압 센서는 0x76, 조도 센서는 0x23처럼 정리하면 나중에 새 모듈을 추가할 때 충돌을 바로 발견할 수 있습니다. 사물인터넷 프로젝트가 커질수록 이런 작은 기록이 디버깅 시간을 줄여줍니다.

스캐너가 주소를 찾았다는 것은 출발선에 선 것입니다. 실제 데이터가 맞는지는 센서 모델, 라이브러리, 샘플링 주기까지 확인해야 합니다.

스캐너 실패를 줄이는 현장 점검 루틴

한 번에 하나씩 바꿔야 원인이 남습니다

문제가 생겼을 때 점퍼선도 바꾸고 코드도 바꾸고 라이브러리도 다시 설치하면, 운 좋게 성공하더라도 무엇이 원인이었는지 알 수 없습니다. 실무형 디버깅은 변수를 하나씩 줄이는 순서가 핵심입니다. 특히 아두이노, 라즈베리파이, ESP32처럼 보드가 바뀌는 환경에서는 핀맵과 전압 기준이 함께 바뀌므로 기록 없이 움직이면 같은 실수를 반복하기 쉽습니다.

아래 순서는 책상 위 실습부터 소형 사물인터넷 장비 제작까지 그대로 적용할 수 있습니다. 센서 가격은 모듈 종류에 따라 몇천 원대부터 몇만 원대까지 차이가 있지만, 디버깅 시간은 부품값보다 훨씬 비쌀 때가 많습니다. 처음 10분을 점검 루틴에 쓰면 이후 몇 시간을 아낄 수 있습니다.

1. 보드 단독 확인: 시리얼 출력과 업로드가 정상인지 확인합니다.
2. 센서 하나 연결: VCC, GND, SDA, SCL 네 선만 짧게 연결합니다.
3. 전압 직접 측정: 센서 모듈 단자에서 실제 전압을 잽니다.
4. 스캐너 실행: 주소가 뜨면 주소값과 보드명을 기록합니다.
5. 예제 코드 적용: 스캐너 주소를 라이브러리 설정에 반영합니다.
6. 장치 추가: 새 센서는 하나씩만 더하고 매번 스캐너를 다시 돌립니다.

로그를 남기면 재현성이 생깁니다

라이프로그라는 말은 개인의 활동 기록을 데이터로 남기는 맥락에서 쓰이지만, 개발자에게도 비슷한 태도가 필요합니다. 프로젝트 상태를 짧게 남겨두면 나중에 같은 증상이 나타났을 때 빠르게 비교할 수 있습니다. 개념적 배경은 라이프로그 서비스 설명에서도 확인할 수 있으며, 임베디드 개발에서는 이 기록 습관이 디버깅 품질로 이어집니다.

로그는 거창할 필요가 없습니다. 날짜, 보드명, 센서명, VCC 전압, I2C 주소, 배선 길이, 사용 라이브러리 버전 정도면 충분합니다. 팀 작업이라면 사진 한 장과 함께 남기는 편이 좋습니다. 브레드보드 위치나 점퍼선 색상까지 보이면 다른 사람이 재현하기 쉽습니다.

• 성공 로그: 정상 주소, 정상 출력값, 사용한 핀 번호를 적습니다.
• 실패 로그: 실패한 구성도 남겨야 다음에 같은 길로 가지 않습니다.
• 변경 로그: 풀업 저항 추가, 배선 단축, 클럭 변경 같은 조치를 기록합니다.
• 사진 기록: 말보다 빠르게 배선 실수를 찾게 해줍니다.

주소는 잡히는데 값이 이상할 때의 깊은 답

통신 성공과 측정 성공은 같은 말이 아닙니다

독자들이 자주 묻는 질문 중 하나가 "스캐너에는 주소가 뜨는데 왜 값은 계속 이상하나요?"입니다. 이 상황은 I2C 통신의 주소 응답은 성공했지만 센서 데이터 읽기 과정이 실패한 경우입니다. 즉, 버스에 누군가 있다는 사실은 확인했지만 그 장치와 올바른 언어로 대화하고 있는지는 아직 모르는 상태입니다.

가장 흔한 원인은 라이브러리와 실제 센서 칩의 불일치입니다. 쇼핑몰에는 같은 이름으로 올라왔지만 내부 칩이 바뀐 모듈이 적지 않습니다. 예를 들어 온습도 모듈이라고만 보고 예제 코드를 넣었는데, 실제 칩은 다른 초기화 명령을 요구할 수 있습니다. 이때 스캐너 주소는 정상으로 나오지만 온도 값이 -40도, 0, 65535처럼 비현실적으로 고정됩니다.

• 데이터시트의 ID 레지스터: 지원된다면 칩 식별 레지스터를 읽어 실제 모델을 확인합니다.
• 변환 대기 시간: 센서가 측정을 끝내기 전에 값을 읽으면 이전 값이나 오류값이 나올 수 있습니다.
• 주소만 같은 다른 장치: EEPROM, ADC, 센서가 같은 대역 주소를 쓸 수 있으니 모듈명을 다시 봅니다.
• 전원 안정성: 측정 순간 전류가 늘어 전압이 흔들리면 통신은 되지만 값이 튈 수 있습니다.

값 검증은 기준 환경을 만들어서 합니다

센서 값이 의심될 때는 바로 보정값을 넣기보다 기준 상황을 만들어야 합니다. 온도 센서는 실내 온도계 옆에 두고 10분 이상 안정화한 뒤 비교하고, 조도 센서는 손으로 가렸을 때와 스마트폰 플래시를 비췄을 때 변화 방향을 봅니다. 압력, 가스, 거리 센서는 주변 조건의 영향을 크게 받으므로 단일 숫자보다 변화 추세를 먼저 봐야 합니다.

코드에서는 원시값과 변환값을 함께 출력해보는 것이 좋습니다. 라이브러리가 계산한 섭씨 온도만 보면 어디서 틀렸는지 찾기 어렵지만, 원시 레지스터 값이 변하는지 보면 통신과 계산 문제를 분리할 수 있습니다. 주소 확인, 원시값 확인, 변환값 확인, 기준 환경 비교 순서로 보면 센서 연결 문제와 알고리즘 문제를 차분하게 나눌 수 있습니다.

주소 스캔은 "문이 열리는지" 확인하는 단계이고, 센서 검증은 "방 안의 사람이 맞는 말을 하는지" 확인하는 단계입니다. 두 단계를 섞지 않으면 디버깅이 훨씬 단단해집니다.

실제 프로젝트에서는 정상 범위를 코드에 넣어두면 운영 중 문제를 빨리 잡을 수 있습니다. 예를 들어 실내 온습도 장비라면 온도 -10도 이하나 60도 이상은 오류 후보로 표시하고, 연속으로 같은 값이 오래 유지되면 센서 고착 가능성을 로그에 남깁니다. 이렇게 하면 스캐너로 시작한 단순 점검이 임베디드 개발 전체의 신뢰성 관리로 이어집니다.