기본 콘텐츠로 건너뛰기

홈IoT 서버의 승자는?





AI가 성장함에 따라 데이터센터의 고밀도화 및 그에 대한 전력 소비, 발열등에 대한 이야기가 눈에 들어옵니다. 이런 이야기를 하신 분들은 이미 그 다음 단계를 알고 있다고 봐야겠지요.. 

시장은 유기물처럼 변화하고 움직입니다. 
지금 AI에 진입한다면 늦지 않았나 조심스럽게 생각이 되네요.. 

그럼 AI시장이 확산되면서 나올 주제중 하나를 한 번 언급해 볼께요.. 

사실은 이 제안은 제가 2016년 경 한국의 유명 제조사에 제안을 했지만, 제가 직접 제안한 것이 아니고 SI업체를 통해 제안을 했다보니 많이 희석되버린 내용인데요.. 

이제라도 이 내용을 참고로 또 한 번 도약하는 한국의 기업들이 생기면 좋겠습니다. 

IoT 시장은 나날이 확장되어 가고 있습니다. 
그 속에서 한 집당 많은 IoT디바이스들이 자리를 잡겠지요.. 
AI스피커에서부터 전화, 커튼, 인터폰, 냉장고, 세탁기, 각 방의 전등이나 보일러 등등.. 
최소 집안의 IoT디바이스는 50개 정도는 봐야 할 것 입니다. 

각각이 서로 IP를 가지고 있고, 그들이 MCU나 어떤 디바이스는 AI반도체가 들어있겠지요.
때문에 모든 디바이스를 인터넷 상으로 보내서 서버통신을 하기에는 너무나도 비효율적이 될 겁니다. 
10만가구에 팔았는데 집당 50개의 디바이스라면 동시 500만대가 수시 서버랑 통신하는 개념이 되겠지요..

그래서 GE는 생각을 했지요.. 
앞으로 이많은 디바이스가 각각 서버랑 통신하지 말고, 집집마다 홈IoT서버가 있고 그 서버가 데이터를 모아 꼭 필요한 데이터만 서버에 던져야 겠다구요.. 
그러면 1/50만큼 통신량이 줄어들어 서버 비용이 획기적으로 줄겠지요.. 
24시간 전원이 꺼져있지 않고 냉각에도 걱정없는 서버는 바로 냉장고가 아닐까?
라고 생각을 했더랍니다. 지금은 어떻게 되었는지 모르겠네요..

이 시기에 삼성도 비슷한 생각을 했습니다. 
삼성TV야 말로 24시간 전원이 들어가 있고, 실제로 내부에 칩도 들어 있으니 서버로 사용되기 좋지 않을까? 

하지만 그 시기에 IoT의 가장 큰 적은 주부들이었지요.. 
잔류 전류를 막기 위해 TV플러그를 뽑거나 플러그 스위치를 꺼버리는 것이었습니다. 

이 때 제가 제안 한 것이, 
인터폰이라면 24시간 꺼질 걱정이 없으니 서버로 쓰기 좋지 않을까?

이렇게 제안하여 사실 한국의 모 회사가 전 세계 8만개의 인터폰을 서버화 하는 프로젝트의 1차 테스트베드에 참여 한 적이 있었으나, 
개발 설계는 제가 하지 않아서 산으로 가다가 실패한 프로젝트가 있었지요.. 

휴대폰에 AI반도체를 넣어서 처리를 하려고 하는 움직임은 휴대폰 사업자라면 모두 하려고 하고 있지요. 
하지만 휴대폰은 자꾸 집에서 나갔다 들어갔다 합니다. 홈 서버로 쓰기에는 적절하지 않지요.. 
만약 휴대폰을 서버로 두고 홈IoT를 모두 컨트롤 한다면 휴대폰이 너무 힘들어할게 뻔하죠.. 디바이스 제어용 휴대폰을 따로 구입하는 문제가 생기지 않을까요? 
그리고 가족 각각의 휴대폰이 서버가 되어 각자 컨트롤 하게 된다면 IoT디바이스들을 얼마나 힘들어할까요?

이걸 홈 서버가 중계 역할을 한다면 정리가 깔끔해지는 것이지요. 
게다가 홈IoT서버를 점령한 기업은 API를 통일하여 타 IoT디바이스들을 줄세우겠지요.. 
자기네 홈IoT서버의 표준에 안맞추면 사람들이 사지 않을테니까요.. 

홈IoT시장이 아직도 왜 전쟁터가 되어 있지 않은지 전 잘 모르겠습니다. 
제가 시장을 읽는 타이밍에는 자신이 없거든요.. 
아니, 이미 전쟁터인데 제가 잘 모르는 것일까요?

삼성은 휴대폰으로 연동하여 집에 없어도 누군가 오면 대답도 하고 문도 열어주는 인터폰도 만들어서 판매하고 있습니다. 
하지만 홈IoT서버는 아니네요.. 

홈IoT서버에 AI칩을 넣고 LLM을 지원하는 API를 열어주면 많은 홈IoT 디바이스들은 각각 LLM을 위한 반도체니 기술이니 넣느라 가격을 올릴 필요가 없습니다 
그냥 홈IoT서버에 접속해서 API만 호출하면 AI칩을 내장한 것과 같은 역할을 하게 됩니다. 
누군가는 이미 이런 준비가 되어있지 않았을까요?

한국의 인터폰은 생각보다 품질이 좋다고 합니다. 
그래서 해외에서도 꽤 판매가 되고 있다고 합니다. 
인터폰에서 나온 다양한 화상정보가 보안용으로도 쓰입니다. 
녹화 내용을 보관하고 클라우드 스토리지 비용으로 월비용도 받을 수 있습니다. 

많은 미래가 있는 이 시장을 누가 선점해 갈까요?
꼭 인터폰만이 홈IoT서버가 되라는 이야기는 아닙니다.
단지 지금 누군가 이 시장을 장악해버린다면 아마 휴대폰 못지 않은 시장이 되지 않을까요?

혹자는 AI스피커면 되지 않느냐 하고 말하기도 하지요. 
실제로 AI스피커도 홈IoT서버가 되려고 노력은 하고 있지만, 이역시 디바이스라서 서버겸 디바이스가 되기에는 리스크가 큽니다. 
움직이는 청소 로봇에 의해 코드가 뽑힐 수도 있구요, 여러 방에 두면 누구는 서버 누구는 디바이스로 쓰되 가격이 같아지게 되는거죠.. 물론 서버용과 디바이스용 가격차이를 둘 수도 있겠지만요.. 
안된다는 게 아니고 리스크가 있다는 것 뿐이니까요.. 

중국에서도 그 많은 IoT디바이스가 나오지만 중앙에서 관리를 해주지는 못하고 기껏해야 스마트폰 한 대에서만 제어가 되더라구요.. 
이걸 보면 홈IoT시장도 굉장히 크고 아직 블루오션 같습니다. 

이 내용으로 누군가는 인사이트를 가져갈 수 있으면 좋겠습니다. 


giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...