주소 하나를 수익성으로 바꾸는 방법: Helios가 보여준 plug-in solar 예측 서비스의 진짜 난제

출처: Hacker News — https://helios.southlondonscientific.com/

영국에서 plug-in solar가 합법화되자마자 바로 등장한 Helios의 흥미로운 지점은, 새로운 에너지 상품을 소개했다는 사실보다 규제 변화와 공개 데이터를 결합해 개인의 주소를 즉시 의사결정 입력값으로 바꿨다는 데 있다. 사용자는 기술 문서를 읽지 않는다. 대신 내 집에서 얼마 나오나, 내 요금제 기준으로 이게 돈이 되나, 설치가 쉬워도 실제로 햇빛은 들어오나를 묻는다. Helios는 바로 그 질문에 답하려는 도구다. 실무적으로 보면 이것은 단순한 계산기가 아니라, 지리정보 시스템, 물리 모델, 가격 모델, UX, 법·제도 제약, 그리고 불확실성 표현이 한 화면 안에서 만나는 작은 decision engine이다.

이 사례를 태양광 뉴스로만 읽으면 놓치는 것

기사 본문과 공개된 서비스 설명을 합치면 Helios는 대략 이런 흐름으로 이해할 수 있다.

1. 주소를 좌표로 바꾼다.
2. 주변 지형과 건물의 시야 차폐를 LIDAR 기반으로 반영한다.
3. 그 차폐 정보를 바탕으로 연간 발전량을 추정한다.
4. 사용자의 tariff, self-consumption, kit cost를 넣어 경제성을 보여준다.

표면적으로는 간단하다. 하지만 실제 서비스 설계에서는 이 네 단계가 각각 다른 종류의 실패를 만든다. 그리고 대부분의 문제는 계산식보다 입력 데이터의 품질과 결과를 설명하는 방식에서 터진다.

Helios가 공개적으로 적어둔 caveat도 그 점을 잘 보여준다. LIDAR coverage 밖에서는 synthetic horizon으로 대체하고, 나무나 최근 개발된 건물은 데이터에 없을 수 있으며, OSM 기반 geocoding 때문에 주소 위치가 어긋날 수 있다고 명시한다. 이 문장은 짧지만, 실무적으로는 매우 큰 의미가 있다. 이 서비스의 가치가 곧바로 무너지는 지점들을 스스로 먼저 선언한 것이다.

즉, 이 서비스의 본질은 “정확한 값 제공”이 아니라 불완전한 공간 데이터를 가지고도 사용자가 행동 가능한 수준의 근사 판단을 하게 만드는 일이다. 이 차이를 이해하지 못하면 제품도, 콘텐츠도, 투자 판단도 다 엇나간다.

주소 단위 에너지 추정은 왜 생각보다 어려운가

건물 단위 예측 서비스는 늘 숫자 하나를 보여주고 싶어 한다. 하지만 주소 단위 태양광 추정에서는 숫자 하나가 가장 위험하다. 이유는 다음과 같다.

여기서 특히 중요한 것은 오차의 방향이 대체로 낙관적으로 흐르기 쉽다는 점이다. 사용자는 설치를 고민할 때 좋은 숫자를 더 믿고 싶어 하고, 제품은 단순한 입력으로 빠른 답을 주고 싶어 한다. 이 둘이 만나면 false precision이 생긴다. Hacker News 댓글에서도 비슷한 우려가 나왔다. 집 footprint를 정확히 못 잡고 postcode centroid로 내려앉았는데도, 결과는 너무 정밀해 보인다는 지적이다. 이 문제는 거의 모든 geospatial estimation 서비스가 겪는다.

실무에서 이걸 피하려면 단일 추정치보다 아래 세 가지가 더 중요하다.

1. 추정치의 근거 수준을 함께 보여줄 것
2. fallback이 작동한 구간을 사용자에게 숨기지 말 것
3. 가능하면 point estimate가 아니라 range 또는 confidence band를 제공할 것

Helios 공개 설명상 현재는 결과와 함께 상세 building data가 없으면 clear horizon 가정을 알려준다. 이 방향은 맞다. 다만 서비스가 커질수록 더 중요한 것은 “정확도가 낮은 이유”를 텍스트로만 쓰지 않고 계산 결과의 형식 자체에 반영하는 것이다. 예를 들어 payback을 7.1 years라고 보여주는 대신, 입력 품질이 낮은 주소에서는 6.5~9.3 years 같은 범위를 주는 편이 더 정직하다.

Helios가 실무자에게 던지는 가장 큰 힌트: 지도보다 horizon이 중요하다

많은 팀이 에너지·부동산·입지 추천 서비스를 만들 때 먼저 지도를 만든다. 하지만 이 사례의 핵심은 map UI가 아니라 sun obstruction model, 즉 태양이 실제로 어느 시간대에 가려지는지에 대한 horizon 추정이다.

공개된 설명에 따르면 Helios는 Environment Agency LIDAR를 이용해 주변 건물과 지형을 반영하고, PVGIS를 이용해 연간 yield를 추정한다. 이 조합은 꽤 실용적이다.

• LIDAR는 현실 공간의 높이 정보를 준다.
• PV yield 모델은 복사량과 패널 조건을 바탕으로 발전량을 계산한다.
• 둘을 연결하면 “햇빛이 있느냐”와 “그 햇빛이 얼마나 전기로 바뀌느냐”를 분리해 다룰 수 있다.

이 구조가 좋은 이유는 도메인 책임이 분리되기 때문이다.

• 지형/차폐 문제는 geospatial layer가 맡는다.
• 태양광 산출 문제는 irradiance/PV model이 맡는다.
• 경제성 문제는 tariff/self-consumption layer가 맡는다.

이렇게 분리하면 나중에 한 층씩 개선하기가 쉽다. 예를 들어 tree canopy를 더 잘 반영하고 싶다면 geospatial layer를 바꾸면 되고, battery를 포함한 경제성 분석을 추가하려면 financial layer를 확장하면 된다.

반대로 많은 초기 제품이 실패하는 이유는 이 레이어들을 한꺼번에 섞기 때문이다. 그러면 결과가 틀렸을 때 어디가 원인인지 설명할 수 없고, 운영팀도 수정 우선순위를 정하지 못한다.

공개 데이터 기반 제품에서 가장 현실적인 경쟁력은 ‘정확도’가 아니라 ‘설명 가능성’이다

기사와 댓글을 보면 사용자 반응이 꽤 흥미롭다. 어떤 사람은 발코니 대신 정원이나 다른 지점도 보고 싶다고 했고, 어떤 사람은 house number가 잘 안 먹는다고 말했고, 어떤 사람은 아예 rooftop solar로 확장 가능하냐고 물었다. 이 피드백은 기능 요청처럼 보이지만, 실은 서비스의 본질을 드러낸다.

사용자가 원하는 것은 단순한 수치가 아니다. 그들은 다음을 원한다.

• 내가 어디에 설치해야 가장 나은지
• 이 값이 왜 이렇게 나왔는지
• 내가 이미 알고 있는 현실과 계산이 왜 다른지
• 이 도구를 믿어도 되는지

즉, 경쟁력은 “우리 모델 MAE가 몇 % 더 낮다”보다 사용자가 반박 가능한 형태로 결과를 설명하는 능력에서 나온다. 특히 공간 예측 서비스에서는 사용자가 현장을 알고 있다. 그 집 앞 큰 나무, 최근 신축된 건물, 남향처럼 보이지만 실제론 살짝 남동인 배치, 난간 높이 같은 것은 현장을 모르는 모델이 자주 놓친다.

그래서 실무적으로는 다음 UX가 중요하다.

1. 위치를 사용자가 미세 조정할 수 있게 할 것
2. 패널 방향과 높이를 더 세밀하게 바꿀 수 있게 할 것
3. 추정 결과에 영향을 준 차폐 요소를 시각적으로 보여줄 것
4. 데이터 freshness와 coverage를 명시할 것
5. 결과를 반박하거나 피드백할 입력 경로를 열어둘 것

Helios가 “shading model feedback welcome”이라고 적어둔 것도 좋은 신호다. 이런 종류의 모델은 closed-box로 운영할수록 불신이 쌓인다. 반면 사용자 피드백을 데이터 품질 개선 루프로 연결하면, 제품이 커질수록 모델이 함께 좋아진다.

경제성 계산에서 가장 많이 빠지는 함정은 발전량이 아니라 self-consumption이다

태양광 계산기에서 사용자는 보통 연간 발전량 숫자에 시선을 빼앗긴다. 하지만 실무적으로 돈을 좌우하는 것은 얼마나 생산하느냐 못지않게 생산한 전기를 내가 그때 쓰느냐다.

공개된 Helios 설명에서도 기본 논리는 분명하다. 대부분의 plug-in kit는 exported power에서 큰 수익을 기대하기 어렵고, 가치의 중심은 self-consumption에 있다고 본다. 이것은 매우 현실적인 가정이다. 특히 소규모 분산형 설비에서 배터리 없이 운영한다면, 낮 시간대에 집이 비는 가구는 체감 절감액이 생각보다 낮아질 수 있다.

여기서 실무자가 꼭 구분해야 할 것이 있다.

• 연간 발전량은 물리 추정치다.
• 절감액은 행동 추정치다.

물리 추정치는 주소, 방향, 경사, 차폐, 기후로 어느 정도 잡을 수 있다. 하지만 행동 추정치는 가구의 생활 패턴, 재택 여부, 전기차 충전 습관, heat pump 사용 시간, 세탁기 예약, 요금제 구조에 따라 크게 바뀐다. 즉, 후자가 전자보다 더 불확실할 때도 많다.

그래서 현업에서 절감 계산기를 만들 때는 다음이 중요하다.

• 연간 사용량 band만 받는 것으로 충분한지 검토할 것
• 최소한 주간 재실 정도 같은 추가 프록시를 받을지 고민할 것
• time-of-use tariff라면 typical day model의 한계를 명시할 것
• export assumption이 0인지, 일부 반영하는지, 왜 그런지 설명할 것

여기서 과하게 복잡한 폼을 만들 필요는 없다. 다만 입력을 단순화했다면, 그만큼 출력의 확신도도 낮춰야 한다. 실무에서는 이 균형을 자주 놓친다. 입력은 10초 만에 받으면서, 출력은 소수점 둘째 자리까지 보여준다. 이 조합이 가장 위험하다.

엔지니어링 관점에서 보면 Helios는 작은 GIS 플랫폼에 가깝다

서비스 화면은 간단하지만, 백엔드 시선으로 보면 꽤 많은 하위 시스템이 숨어 있다.

• 주소 해석과 좌표화
• 건물 또는 관측점 선택
• LIDAR tile 조회와 차폐 계산
• horizon 생성
• 외부 또는 내부 발전량 모델 호출
• tariff 적용과 절감 계산
• 결과 시각화
• 데이터 coverage/fallback 판정
• 개인정보 최소화

이런 서비스는 CRUD 애플리케이션과 실패 패턴이 다르다. 가장 까다로운 부분은 보통 business logic보다 geo/data pipeline 운영이다.

예를 들어 성능을 보자.

• 주소 입력마다 원시 raster를 직접 읽으면 latency가 길어진다.
• ray tracing 또는 skyline 계산은 관측점 변경에 민감하다.
• 같은 postcode 주변 요청이 반복되면 tile cache가 큰 효과를 낸다.
• 지도와 그래프를 한 번에 만들면 API 응답 시간이 늘어난다.

실무에서는 아래와 같은 분리를 고려할 만하다.

이 분리가 중요한 이유는 장애 대응 때문이다. 예를 들어 계산이 이상하게 높게 나오면, 무작정 “모델이 틀렸다”가 아니라 아래처럼 잘라서 볼 수 있어야 한다.

• 주소가 잘못 찍혔나?
• 관측 높이가 과하게 잡혔나?
• LIDAR coverage 밖이라 synthetic horizon을 썼나?
• 나무 차폐가 누락됐나?
• tariff 매핑이 틀렸나?
• self-consumption 기본값이 사용자 상황과 안 맞나?

이런 분해가 안 되면 운영팀은 사용자 문의를 처리할수록 더 혼란스러워진다.

보안과 프라이버시에서 오히려 배울 점이 있다

서비스 설명에서 눈에 띄는 부분 중 하나는 We have no database — your address isn't stored.라는 문장이다. 이것이 실제 구현 세부를 모두 보장하는 것은 아니지만, 적어도 제품 철학은 분명하다. 주소는 에너지 계산에는 필요하지만, 굳이 장기 저장해야 하는 데이터는 아니라는 판단이다.

이 접근은 특히 location-based consumer service에서 중요하다. 주소는 단독으로도 민감한 데이터일 수 있고, 여기에 전기 사용량 band, 주거 형태, 설치 의향, 이메일 구독이 붙으면 profiling 강도가 꽤 높아진다. 따라서 비슷한 제품을 만들 때는 다음 원칙이 실무적으로 유효하다.

1. 계산에 필요한 최소 입력만 받을 것
2. 주소 원문 저장이 꼭 필요한지 먼저 의심할 것
3. 로그, analytics, error reporting에 주소가 흘러들어가지 않게 할 것
4. 마케팅 구독과 계산 요청 데이터를 분리할 것
5. 데이터 보존 기간과 제3자 위탁 구간을 명확히 둘 것

프라이버시는 법무 이슈라기보다 제품 신뢰 이슈다. 특히 “내 집에 이걸 달면 얼마 버나”를 계산하는 서비스는 사용자의 경제적 취향과 주거 정보를 함께 다룬다. 개인정보 최소화 설계가 되어 있지 않으면 기능이 좋아도 확산이 느리다.

이 서비스를 바로 도입하거나 비슷하게 만들고 싶다면, 먼저 숫자보다 운영 질문을 던져야 한다

이런 류의 서비스는 데모 단계에서는 매우 매력적이다. 하지만 현업 도입 판단은 다른 질문으로 해야 한다.

체크포인트 1. 결과가 틀렸을 때, 사용자가 납득할 경로가 있는가

정답률 100%는 불가능하다. 대신 다음이 있어야 한다.

• 왜 이 결과가 나왔는지 설명하는 근거
• 어떤 데이터가 부족했는지 알려주는 경고
• 사용자가 위치·방향·높이를 조정할 인터랙션
• 피드백 접수 후 모델 개선 루프

체크포인트 2. coverage gap을 기능으로 숨기지 않았는가

기사 본문에도 나오듯 LIDAR coverage 바깥은 synthetic horizon fallback을 쓴다. 이건 나쁜 선택이 아니다. 문제는 그 fallback을 결과 화면에서 사실상 숨기는 경우다. coverage gap은 기능의 부끄러운 뒷면이 아니라, 사용자가 알아야 하는 품질 메타데이터다.

체크포인트 3. 경제성 계산이 사용 패턴을 과도하게 단순화하지 않았는가

연간 kWh + tariff만으로도 빠른 추정은 가능하다. 하지만 그 숫자를 의사결정 수준으로 올리려면 self-consumption 가정이 핵심이다. 재택이 많은 집과 낮에 비는 집의 체감 절감액은 꽤 다를 수 있다.

체크포인트 4. 제품이 규제 문구를 기능 문구보다 늦게 다루지 않는가

plug-in solar 같은 영역은 규제와 인증, 설치 방식, export eligibility가 기능만큼 중요하다. 공개 설명에서도 “안전 표준이 자리 잡기 전에는 electrician hardwire가 필요할 수 있다”는 취지의 안내가 보인다. 이런 문구는 conversion을 방해하는 불편한 설명이 아니라, 나중 분쟁을 줄이는 핵심 기능이다.

실무에서 특히 유용한 비교 기준

비슷한 서비스를 비교하거나 직접 만들 때, 아래 기준으로 보면 본질이 잘 보인다.

이 기준이 중요한 이유는, 사용자가 결국 묻는 질문이 단순하기 때문이다. “이거 우리 집에 해도 되나?” 이 단순한 질문 뒤에는 공간 모델, 행동 모델, 정책 모델, 소비자 보호가 모두 숨어 있다. 그래서 비교도 기능 개수보다 판단의 책임을 어떻게 나눴는가로 해야 한다.

실패 패턴은 대체로 세 가지로 모인다

1. 지나치게 매끈한 숫자

소수점 둘째 자리 payback, 연간 절감액 확정치, 지도 핀 하나. 보기에는 아름답지만, 현장성은 낮다. 공간 데이터 불확실성이 있는 순간 이런 표현은 독이 된다.

2. ‘발전량’과 ‘절감액’을 같은 신뢰도로 다루는 것

발전량은 물리 모델에 가깝고, 절감액은 생활 패턴 모델에 가깝다. 후자가 더 불안정한데도 같은 톤으로 보여주면 사용자가 오판한다.

3. fallback을 제품 내부 구현 디테일로 취급하는 것

사용자에게는 구현 디테일이 아니다. synthetic horizon인지 실제 LIDAR 기반인지에 따라 판단 신뢰도가 달라진다. 이는 결과 카드의 일부여야 한다.

이 사례가 Energy Tech, PropTech, Civic Data에 동시에 의미 있는 이유

Helios는 단지 한 개의 solar estimator가 아니다. 더 크게 보면 공개 인프라 데이터가 소비자 의사결정 제품으로 바로 연결될 수 있다는 사례다. 그리고 이 패턴은 태양광에만 갇히지 않는다.

• 주택 선택 시 채광·소음·공기질 평가
• 소규모 설비 투자 회수 기간 추정
• 지역 단위 climate adaptation 도구
• 설치 위치 추천형 energy advisor

Hacker News 댓글에 나온 것처럼, 어떤 사용자는 이 데이터를 집 비교 서비스에 붙이고 싶어 했고, 어떤 사용자는 전체 지역의 plug-in solar potential을 계산할 수 있느냐고 물었다. 이것은 자연스러운 확장 방향이다. 다만 범위를 넓힐수록 한 주소 단위 추정보다 더 어려운 문제가 생긴다. “설치 가능한 표면이 실제로 어디 있느냐”를 추정해야 하기 때문이다. 여기서부터는 단순 LIDAR 활용을 넘어, building morphology, accessible surface, 규제 가능 구역, 구조적 제약까지 고려해야 한다.

즉, 주소 단위 계산기가 성공했다고 해서 곧바로 도시 단위 잠재량 분석으로 점프할 수는 없다. 둘은 비슷해 보이지만 요구하는 데이터 책임 수준이 다르다.

제품팀과 엔지니어팀이 각각 가져가야 할 메시지

제품팀에게

• 숫자를 더 정밀하게 보이게 하는 것보다, 신뢰도 메타데이터를 잘 드러내는 것이 중요하다.
• 사용자가 알고 있는 현실과 모델 출력이 충돌할 때 설명할 인터랙션이 필요하다.
• 입력을 단순화할수록 출력은 범위형 또는 조건부 문장으로 바뀌어야 한다.

엔지니어팀에게

• 이 문제의 핵심은 알고리즘 멋짐보다 데이터 경계 관리다.
• geocoding, LIDAR, PV model, tariff model을 분리해 장애 원인을 추적 가능하게 만들어야 한다.
• 캐싱, coverage metadata, 비동기 계산, 결과 재현성을 처음부터 설계해야 한다.

사업팀에게

• 소형 분산 에너지 상품은 하드웨어 마진보다도 신뢰할 수 있는 사전 평가 경험이 전환율에 큰 영향을 줄 수 있다.
• 다만 과장된 ROI 메시지는 초기 전환보다 후기 불만을 더 크게 만든다.
• 국가별 가격, 인증, export 제도 차이는 쉽게 일반화하면 안 된다.

마지막으로, 이 사례를 ‘정확한 계산기’가 아니라 ‘불확실성을 잘 다루는 인터페이스’로 봐야 한다

Helios의 진짜 성과는 어떤 절대적인 정답을 냈다는 데 있지 않다. 공개된 설명만 놓고 봐도 이 서비스는 스스로의 한계를 분명히 알고 있다. coverage 밖에서는 덜 정확한 fallback을 쓰고, tree와 recent development를 놓칠 수 있으며, address placement가 어긋날 수 있다고 밝힌다. 이 태도는 단점 공개가 아니라 설계 성숙도에 가깝다.

실무에서 좋은 예측 서비스는 오차가 없는 서비스가 아니다. 어디까지 믿어도 되는지, 어디서부터는 현장 확인이 필요한지, 그 경계를 사용자에게 숨기지 않는 서비스다. 규제가 바뀌고 시장이 막 열릴 때는 특히 그렇다. 새로운 시장의 첫 번째 승자는 가장 공격적인 숫자를 주는 팀이 아니라, 사용자가 잘못된 확신에 빠지지 않게 만드는 팀일 가능성이 크다.

그래서 이 사례를 보고 배워야 할 포인트는 하나로 수렴한다. 주소 하나를 숫자로 바꾸는 일은 쉽다. 하지만 그 숫자를 판단 가능한 정보로 만드는 일은 전혀 다른 수준의 제품 설계와 데이터 윤리를 요구한다. 앞으로 이런 도구가 늘어날수록, 우리가 평가해야 할 것은 계산기의 화려함이 아니라 그 계산기가 얼마나 정직하게 자신의 한계를 드러내는지일 것이다.

의견

댓글/토론에서 나온 의견을 참고용으로 정리했습니다. (사실로 단정하지 말고 맥락 확인 권장)

• Hacker News · @toomuchtodo: Depends on your energy requirements and future technology and energy costs. At the moment, one should value this outlay as a fixed income equivalent investment [1]. The panels have a ~25 year warranty though [2] (at which point, they should still produce ~80% of rated output), so it’s entirely possible to just leave t…
  • 링크: https://news.ycombinator.com/item?id=48337279
• Hacker News · @redfloatplane: Indeed. Taillte Ireland's (Ordnance Survey Ireland's) detailed cartographic data is also not open (including historic data - maps from the 1820s and 1920s!) and it's really a huge pain in the ass. On the other hand, OSM is in pretty good shape at least for topographic information. I've used it to m…
  • 링크: https://news.ycombinator.com/item?id=48339900
• Hacker News · @brk: These calculations often fail to account for present vs future value of money. If you’re financing the system you have no big cash outlay, but returns are further out, possibly never when accounting for the useful like of the system. With cash up front all the returns are yours, but they are much lower than what that …
  • 링크: https://news.ycombinator.com/item?id=48338686
• Hacker News · @ltrg: Really cool stuff. Nitpick: it failed to grab an OSM ID for my house and fell back to postcode centroid, but then still reported LIDAR-derived shading at quite high precision. I'm wondering if it should fall back to a more general shading approach when no OSM building footprint is available, to avoid false precis…
  • 링크: https://news.ycombinator.com/item?id=48335897
• Hacker News · @pjc50: Why would you replace it if doing so is uneconomic? Panel lifetime is very high. The scope for efficiency improvement is not huge (unless there is a cost breakthrough in multi band photon capture). It's not a car, phone, or computer. It's more like the rest of the house electric infrastructure. I had my roof…
  • 링크: https://news.ycombinator.com/item?id=48338048
• Hacker News · @ErroneousBosh: I got the exact same values. I'd like it if it would actually show me how much sun it thinks I'd get at the postcode I put in. I've got about a third of an acre of garden in a 6 acre field to play with, before I start having to dig up roads. I can afford to be quite free and easy with placement ;-)
  • 링크: https://news.ycombinator.com/item?id=48338852

댓글

댓글을 읽어오는 중입니다.