Engineering & Tech

LED 스트립 50미터를 깔다가 분산 시스템 아키텍처를 배웠습니다

LED 스트립 50미터 설치 과정에서 겪은 전압 강하 현상을 통해 로드 밸런싱, 프로토콜 효율화, 데이터 무결성 등 분산 시스템 아키텍처의 핵심 원리를 설명합니다.

김영태

테크리드

안녕하세요. 풀링포레스트 테크리드 김영태입니다.

최근 사내 휴게 공간을 리뉴얼하면서 "분위기 있게 간접 조명 좀 넣어볼까?" 하는 가벼운 아이디어를 냈다가, 지난 주말 내내 전기 테이프와 테스터기를 들고 씨름했습니다. 고작 LED 줄 하나 까는 게 대수겠냐 싶었죠. "전원 꽂으면 불 들어오는 거 아니야?"라는 제 생각은, 백엔드 개발자로 치면 "트래픽 늘어나면 그냥 서버 대수 늘리면 되는 거 아니야?"라고 말하는 것만큼이나 순진한 생각이었습니다.

오늘은 제가 20미터가 넘는 장거리 LED 스트립을 설치하며 겪은 '전압 강하'라는 물리적 현상과, 이를 해결하기 위해 찾아본 엔지니어링 패턴들이 어떻게 우리가 다루는 대규모 트래픽 처리 구조와 닮아있는지 이야기해 보려고 합니다.

화려한 시작, 그리고 희미해진 끝

상황은 이랬습니다. 천장 테두리를 따라 약 30미터 정도의 LED 스트립을 둘러야 했습니다. 저는 호기롭게 5V 주소 지정형(Addressable) 스트립을 구매했고, 시작점에 거대한 PSU(전원 공급 장치)를 연결했습니다. 불을 켜는 순간, 시작점은 눈부시게 하얀색(White)으로 빛났습니다.

그런데 끝부분으로 갈수록 색이 점점 누렇게 변하더니, 마지막 5미터는 거의 붉은색에 가까운 주황색이 되더군요. 심지어 에어컨이 돌아갈 때마다 LED가 미세하게 깜빡거리는 '플리커(Flicker)' 현상까지 발생했습니다.

전형적인 전압 강하(Voltage Drop) 현상이었습니다. 구리선도 저항이 있다는 걸 간과한 거죠. 전선이 길어질수록 저항이 쌓이고, 전류가 흐르면서 전압이 떨어집니다. 5V로 시작한 전압이 끝에 도달하니 3V 언저리가 되어버린 겁니다. 마치 데이터 센터가 멀어질수록 레이턴시가 늘어나고 패킷 로스가 발생하는 상황과 똑같았습니다.

하드웨어 해커들에게 묻다

혼자 끙끙 앓다가 해커 뉴스(Hacker News)에 올라온 "장거리 LED 설치 시 깜빡임을 피하는 모범 사례"라는 스레드를 정독하게 되었습니다. 거기서 오가는 대화들은 단순한 DIY 팁이 아니라, 시스템 엔지니어링 그 자체였습니다.

제가 찾은 해결책들과 그에 대응하는 우리 백엔드 시스템의 개념을 정리해 봤습니다.

1. 분산 전원 주입 (Power Injection) = 로드 밸런싱 & 엣지 컴퓨팅

스레드의 많은 전문가들이 "시작점에만 전원을 넣지 마라"고 조언합니다. 중간중간, 혹은 양 끝에서 전원을 추가로 공급해 줘야 한다는 것이죠. 이를 'Power Injection'이라고 부릅니다.

저희가 트래픽이 몰릴 때 단일 데이터베이스나 단일 서버에 모든 부하를 걸지 않고, 로드 밸런서를 통해 트래픽을 분산시키거나 CDN을 통해 컨텐츠를 사용자와 가까운 곳(Edge)에서 뿌려주는 것과 정확히 같은 원리입니다. 저는 결국 5미터 간격으로 별도의 전원선을 따서 중간중간 전력을 보충해 주는 방식으로 배선을 수정했습니다.

2. 고전압 백본 (24V vs 5V) = 프로토콜 효율화

"왜 굳이 손실이 큰 5V를 쓰냐, 24V를 써라"는 조언도 뼈저렸습니다. 전압(V)이 높으면 같은 전력(P)을 낼 때 전류(I)가 적게 흐릅니다(P=VI). 전류가 적으면 저항에 의한 손실도 줄어듭니다.

이는 마치 우리가 JSON 대신 gRPC나 Protobuf를 사용하여 페이로드 크기를 줄이고 통신 효율을 높이는 것과 같습니다. 데이터 파이프라인을 설계할 때, 무거운 원본 데이터를 그대로 흘려보내기보다 압축하거나 효율적인 포맷으로 변환해 대역폭을 아끼는 전략과 일맥상통합니다.

3. 차동 신호 (Differential Signaling, RS-485) = 데이터 무결성 보장

단순 전원 문제를 넘어, 데이터 신호(제어 신호)가 20미터를 넘어가니 노이즈를 타기 시작했습니다. 댓글 중 한 분이 "RS-485 같은 차동 신호 방식을 써라"고 하더군요. 노이즈가 발생해도 두 신호선의 차이(Difference)를 이용해 원래 신호를 복원하는 방식입니다.

네트워크 프로그래밍에서 UDP 대신 신뢰성 있는 TCP를 쓰거나, 메시지 큐 시스템에서 ACK 메커니즘을 두어 데이터 유실을 방지하는 것과 같은 맥락입니다. 신호가 물리적으로 먼 거리를 이동할 때는 반드시 '무결성'을 지킬 수 있는 프로토콜이 필요하다는 걸 다시금 깨달았습니다.

엔지니어링은 결국, 병목을 관리하는 것

결국 저는 12V 정전압(Constant Voltage) 스트립으로 교체하고, 굵은 게이지(AWG)의 전선을 사용해 10미터마다 전원을 주입하는 방식으로 문제를 해결했습니다.

다음은 제가 이 문제를 해결하기 위해 저항을 계산했던 간단한 파이썬 스크립트입니다. 하드웨어 문제라도 결국 수학으로 모델링해야 풀리더군요.

def calculate_voltage_drop(length_m, current_amp, wire_resistance_per_m):
    # 왕복 거리(전류가 갔다 돌아와야 하므로 2배)
    total_wire_length = length_m * 2
    total_resistance = total_wire_length * wire_resistance_per_m
    voltage_drop = current_amp * total_resistance
    return voltage_drop

# 예: 20미터, 5A 소모, 일반적인 18AWG 전선 저항(약 0.021옴/m)
drop = calculate_voltage_drop(20, 5, 0.021)
print(f"예상 전압 강하: {drop:.2f}V")

이 간단한 코드를 돌려보고 나서야, 왜 제 LED가 끝부분에서 붉은색이었는지 이해했습니다. 5V에서 4V가 빠져나가면 남는 게 없으니까요.

이번 '삽질'을 통해 얻은 교훈은 명확합니다. 인프라가 되었든, 코드가 되었든, 물리적인 전기 배선이 되었든 "규모가 커지면 반드시 병목이 생긴다"는 점입니다. 로컬 환경(책상 위 1미터 테스트)에서는 완벽하게 돌아가던 코드가 프로덕션 환경(30미터 실제 설치)에서 터지는 이유는, 우리가 이 '규모에 따른 손실'을 계산에 넣지 않았기 때문일 겁니다.

개발자 여러분, 혹시 지금 설계하고 있는 시스템이 "책상 위 테스트" 수준의 가정에 머물러 있지는 않나요? 트래픽이 10배, 100배 늘어나고 데이터가 물리적으로 멀어졌을 때도 여러분의 '빛'이 끝까지 밝기를 유지할 수 있을지, 한 번쯤 계산기를 두드려 보시길 권합니다.

오늘도 트래픽의 전압 강하를 막기 위해 고군분투하는 모든 동료들을 응원합니다.