Talk Lowy(kr)

영상 버전 :  https://youtu.be/KtRKb2Py5xs 아무 생각없이 쉽게 생각해버린 20 년간 축적된 AIX위의 ORACLE 데이터 이전 작업..  AIX가 서비스연한이 다되어 신규 구매를 해야만 하는 상황이다. 신규 구매 18억 + 연간 6억원의 유지 비용. 5년 사용기준으로 연간 약 10억원의 비용이 드는 것을 x86으로 교체함으로 신규 구매비용 5천만원(2대 이중화)으로 퉁치고 오라클 라이선스도 44Core -> 16 Core로 줄이는 것이 이번 프로젝트의 목표이다. 별 준비 없이 오라클이니까 라는 생각만으로 너무 자체 기능을 믿고 진행 한 것이 문제 였다.  서비스 정지 허용 시간은 교섭에 교섭을 해서 단 7시간..  Full backup만으로 40시간이 걸린다. 게다가 센터가 클라우드 센터 내에 있는 물리 서버라 백업 장비 반입 불가, 백업 영역이 500GB도 채 남지 않은 곳에서 NAS 이용 불가, 1Gbps 네트워크에서 알아서 하랜다. 프로젝트를 받고 나서 이런 상황이었다는 사실을 뒤늦게 알았다.. 당연히 이런거 다 지원해주는 곳인줄 알았는데.. ㅠㅡㅠ 나중에 안 얘기로는 SI업체 견적으론 30억이었다고 한다.  이전이 결정되자마자 DBA는 사표를 던지고.. 대타가 없어 내가 들어와서 간단한 인수인계만으로 준비를 시작.. 서버 선택에서부터 이전준비, 이전작업까지 모두 나 혼자 하게 되어버렸는데, 그냥 그 동안의 경험상 문제 없겠지 하고 개시.. 사전에 이건 미션임파서블이기 때문에 일부 데이터의 누락이 발생하거나 하면 수동처리하는 걸로 합의 했다.  병렬 export & import용 스크립트를 만들어서 충분히 테스트 해봤다. 별 문제없이 계산 상으로 7시간정도에 맞출 수 있었다. 이전 당일... 서비스 정지후 복사 작업 진행.. 사전에 변경되지 않을거라 생각되는 2800여개 테이블을 미리 복사해두고 남은 1500여개의 테이블을 복사하는 시간만 40시간인 것이다.  병렬 export 및 import를 스크립트화 하여 10개

요즘은 한국과 일본과의 관계가 안좋아지고 코로나 때문에 왕래도 거의 사라져 버렸지만,  경제라는 것은 흐름이 있기 때문에  알아두면 참고가 되지 않을까 싶습니다.  공공기관의 인터넷화는 한국이 일본보다 확실히 앞서 있습니다.  그리고 연간 해외 수출액도 작년도 기준으로  일본이 800조정도에 한국이 600조 정도로 많이 따라 잡았습니다.  하지만 RPA가 언급되기 이전 부터 자동화의 관점으로 보면 일본의 경우가 많이 진전되어 있었습니다.  RPA이전부터 자동화에 대한 니즈 및 자동화 솔루션이 많이 나와 있었구요..  이제와서 RPA라고 해서 붐이 다시 일어나는 것보다,  RPA 툴이 진화되면서 자동화의 영역이 더 넓어졌기 때문에  더욱 급속도로 확대 되고 있지요.  그런 반면 한국에선 아직도 눈치보기로  어디 대기업이 도입되기를 기대하면서  시범적으로 도입하고 그걸 기사화 하는 정도가 현실 입니다.  치열하게 효율화에 목숨을 걸고 투자를 하는 일본과 잠깐 맹렬하게 이슈화 되었다가 사라지는 것이 반복되는 한국.. 많은 시도를 할 수 있는 테스트베드가 되는 것은 좋으나,  결국 테스트 후에 세계 시장에서 돈을 버는 것은  한국에서 테스트베드를 경험한 사람들이 참여한 해외 기업이 되네요.  이 좋은 테스트베드의 경험을 사업으로 이끌고 일본이나  다른 해외에 진출하는 IT기업이 있다면 큰 성공을 하지 않을까 합니다.  하지만,  예전에도 언급한 경험담이지만,  한국에선 해외 진출을 위해 도와주는 투자자 또는 기업중에 IT기술 자체에 점수를 매기는 경우가 없지요.  그렇기 때문에 솔루션 회사 혼자 해외에서 맨땅에 헤딩하고 우연히 살아남아도 글로벌 기업에 먹히는 정도가 다이지 않나 싶습니다.  일본은 한국이나 해외의 국가 디지털 사업을 벤치마킹하여  2025년까지 개인번호(주민등록번호 같은것)만 있으면 많은 것들이 해결되는 시스템으로 만든다고 하고,  많은 기업들이 연동을 하고 있습니다.  이 얘기를 하다가 재미있는 얘기를 들었는데요... 한국은 여러 은행의 계좌 통합관

오랜만에 들어와서 보니 그렇게 중요하지 않은 내용으로 갑론을박이 한창인 것을 보고 놀랐다.  내가 한국 사람들의 정서와는 많이 달라서 그런 것일 수도 있지만, 많은 사람들이 자기의 입장에 대해서 잘못 알고 있는 것 같아서 가장 중요한 경제활동의 근본 부터 말하고자 한다.  대부분의 문제가 상대방을 이해하지 못하는 상황에서  자기의 불편함 만을 강조하면서 초래되는 이야기인데,  내가 MS Office가 있지만 복잡한 업무처리를 보다 수월하게 하기 위해서 SI 또는 클라우드 서비스에 돈을 지불하고 편리한 시스템을 이용하게 된다.  돈을 내는 나의 입장에서 SIer나 클라우드 서비스 업체에서 나에게 불만을 얘기하면 난 바로 다른 곳을 찾게 된다.  내가 돈을 내는데 왜 불만을 들어야 하지? 게다가 나의 시간을 절약해주기 때문에 서비스를 이용하지 않나? 얼마 전에 올라왔던 이야기를 축약하자면 헤드헌터라는 사람이 자신의 고객이 연락 없다고 매너를 거론하면서 불만을 늘어 놓았다.  내가 소비자라면 그런 불만 많은 헤드헌터를 이용할 이유가 없다.  내가 바쁘기 때문에 챙기지 못하는 만큼 헤드헌터에게 맡기는 것 아닌가? 외국계 헤드헌터 I사의 경험담을 적어본다. I사의 헤드헌터는 회사 담당자와 많은 대화를 하여 어떤 사람을 찾고자 하는지에 대해 아주 구체적으로 찾아낸다.  그리고 개인들을 직접 만나보고 개인의 이상적인 회사에 대해서 오랜 시간을 들여 이야기를 했다. 두어시간 이야기 하고 나서 개인에게 가장 적합해보이는 회사를 10 개정도 추려 왔다.  그리고 이 회사가 왜 이 개인에게 적합한지 자신의 의견을 회사별로 이야기를 했다.  그리고나서 개인이 지원하고 싶다고 생각한 회사가 세 개정도 될 때까지 계속 10개씩 회사를 추려오면서 여러가지 이야기를 해줬다.  결국 세 개의 회사를 지원하게 되었다.  면접 전에도 어떤 사람을 원하기 때문에  어떠한 사람이 되겠다는 포부를 이야기 하라는 등의  회사별 면접의 포인트도 알려주었다.  그리고 모든 지원에 이 담당자와 함께 면접을

SSMS(Sql Server Management Service)툴에서 제공하는 간단한 모니터로 대부분의 성능 이슈를 잡아낼 수 있다.  https://serverfault.com/questions/578533/ms-sql-server-getting-overloading-with-suspended-queries-mostly-reads-any-wa 일단 정리 용... giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

AWS는 IOPS가 굉장히 민감하기 때문에  자기의 Instance가 지원되는 IOPS인지를 체크해야 한다.  Instance의 IO Network Bandwidth와 EBS의 Throughput 과 IOPS 중 하나라도 느리면 그 곳에서 병목이 발생한다.  EBS Specification:  https://aws.amazon.com/jp/ebs/volume-types/   EBS Volume Type :  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html 일단 정리용으로 대충 올려 놓음.. giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

제목이 조금 거창하지만... 스타트업에게 이야기 할 때 많이 하는 얘기가 있습니다. 요즘은 IT서비스를 플랫폼화 하여 성장하는 기업이 주류 입니다. 플랫폼은 다수의 공급자와 다수의 수요자를 연결하는데 의미가 있습니다. 거기서 많은 시행착오를 일으키기도 하는데요.. 선택의 기로에 설 때가 많습니다. 선택이란 양쪽이 좋은 것 보다 선택 받지 못한 다른 한 쪽이 손해 또는 이득이 적어지는 경우가 대부분 입니다. 이 경우 가장 중요한 것은 누가 나에게 이득을 주느냐 입니다. 설계한 서비스를 이용함으로서 한쪽은 재화를 지불 하고 다른 한 쪽은 재화를 얻는 경우가 대부분 일 것입니다. 재화를 지불하는 곳이 재화에 상응하는 편리함을 제공하지 않는다면  이용자가 줄어들어 아무리 많은 공급자를 가지고 있다 하더라도 서비스는 지속되기 어렵습니다. 이걸 가장 잘 알았던 기업이 애플이었죠. 아무리 개발자가 불평이 많아도  이용자가 서비스 이용이 편리하여 돈을 써주기 때문에 구글의 플레이 스토어 보다도  애플의 앱스토에 충실 고객이 늘어납니다. 사이먼씨의 이야기를 빌리자면 마틴 루터 킹 같은 종교 지도자나 애플의 유저를 끌어들이는 정책은 일치하고 돈을 지불하는 것에 안심감 및 프라이드 마저 느낄 수 있도록 해주었기 때문에 일방적으로 개발자에 불친절한 앱 관리 시스템에 개발자는 애플을 욕하면서도 앱스토어 출시를 하게 되는 것이지요. 인재파견 및 소개 회사도 마찬가지 입니다. 다수의 수요자는 기업이고, 다수의 공급자는 취업 희망 개인입니다. 물론 양쪽을 편하게 해주면 좋겠지만, 경제 구조상 수익률을 위해 동일 시간에 최대한 노력을 해야하기 때문에 한 쪽은 신경을 덜 쓰게 됩니다. 이 경우 취업 희망자에게 아무리 신경을 쓴다 하더라도  기업이 불편하면 안쓰게 됩니다. 그럼 돈을 지불할 기업이 사라지니 결국 이 플랫폼은 돈이 돌지 않아 망하게 될 겁니다. 그렇다고 구직자를 대충 대하라는 것이 아닙니다, 최대한의 서비스를 하되, 시간이 부족하다면, 보다 기업의 채용 담당자의 채용까지 걸리는

누군가 요청해서 재미삼아 만들었음.. mongodb를 mysql에서 불러들이는 방법은 몇 가지가 있는데요..  1. mongodb에 mysql 모듈을 설치해서 mysql에서 호출하는 방법..   -> 설정이 많이 필요해서 귀찮음 2. mongodb에 mysql 5.7이후라면 json import를 이용해서 json으로 집어넣는 방식   -> mongodump를 이용해서 json 파일로 넣고 json_import를 이용해서 테이블에 넣으면 되기 때문에 간단한 명령으로 쉽게 정리 됨.    단점은 KVS(Key Value Store)로 저장되기 때문에 쿼리가 살짝 귀찮아짐.. 기존 쿼리를 사용할 수 없다.  SELECT doc->>"$.name" AS name FROM test.my_restaurants WHERE doc->>"$.cuisine" = "Italian"    요런 느낌으로 쿼리를 짜야 함. 3. mongodump로 json으로 떨군 뒤에 jq로 읽어서 쉘로 필드를 뽑은 뒤에 mysql커맨드로 insert처리를 함.       #!/bin/bash      # Useful date text     TodayYYYYMMDDHH24MISS= `date '+%Y%m%d%H%M%S'`     TodayYYYYMMDD= `date '+%Y%m%d'`     TomorrowYYYYMMDD= `date +%Y%m%d --date '1 day'`     YesterdayYYYYMMDD= `date +%Y%m%d --date '1 day ago'`     NextMonthYYYYMMDD= `date +%Y%m%d --date '1 month'`     PrevMonthYYYYMMDD= `date +%Y%m%d --date '1 month ago'`     delete sqldump.sql     j

#계량판매 가 급증하고 있습니다.  #코로나 로 인한  #재택근무 가 많아지면서  #내츄럴로손 에서는 세제 , 모 술집에서는 #크래프트맥주 등 다양한 제품을 기존 방식으로 판매 하는 것보다 필요한 양만큼만 파는 방식이 작년에 비해 1.5배가 늘었다고 합니다. 사람마다 수요가 다르기 때문이랑 점과, 기존에는 마구잡이로 버렸던 쓰레기의 처리가 집에서는 분리를 해야되는 귀찮음, 그리고 경제적 압박에 따른 저렴한 소비문화 등 여러가지 요소가 작용된 것이라고 생각됩니다. 이 방식을 사용하면 자기가 가지고 있는 병을 활용할 수 있어  #프라스틱 용기나  #유리병 응 자연히 재활용하기 때문에  #친환경이 될 수 있고 저렴하게 판매할 수 있습니다. 코로나 사태로 인한 급격한 변화에 빠르게 적응하는 기업만이 살아남지 않을까요? giip :: Free mixed RPA orchestration tool! https://giipasp.azurewebsites.net

스타트업을 해보고,  스타트업들을 지원하면서  늘상 듣는 이야기 이다.  너네의 차별화 전략은 뭐냐? 그냥 어설픈 차별화를 생각하기 위해 얼마나 많은 시간과 노력을 쏟고 있는걸까? 처음부터  성공 = 1등  이란 공식을 전제로 하는 것 자체의 문제가 있는걸까? 주변을 돌아보면 어느 업종 업계에서도  1등은 하나 뿐이지만 수 십, 수 백만의 기업이  지금까지 하던 일을 묵묵히 하면서 잘 살고 있다.  내가 아는 주변 회사들을 보아도 1등을 하고 있는 기업은 거의 없다.  심지어는 그렇게 알려지지 않았지만,  그들은 자신들의 행복에 별로 의구심이 없다.  투자자들이 부추기고 있는 이상한 한국 기업의 이상론.. 투자자들역시 그냥 자기가 투자한 금액이 다른 곳에서 투자한 곳보다 좋으면 되지 않을까? 차별화가 없거나 1등이 될 수가 없으면  아예 거들떠 보지도 않는 현실.. 자신이 잘하는 것을 더욱 잘하도록 노력하는 시간보다 투자자들에게 어필하는데 더욱 집중하고 있는  스타트업들을 보면 안쓰러운 마음마저 든다.  자신의 아이디어로 자신의 힘을 시험하고 자신의 노력을 최대한 기울이고 싶어도 타 기업과 차별화가 없어서  버려지는 사람들.. 내가 봐 왔던 장인들은 그 어떤 차별화도 가지고 있지 않다.  아니, 어거지로 차별화라고 말을 한다면,  그게 좋아서 열심히 하는 정도. 내가 예전에 어떤 투자자 앞에서 난 이 것만을 위해 20년을 보내왔으며 자나깨나 이 것만을 생각하기 때문에 동종업계에서 40년을 한 사람보다 낫다고 평가 받은 적이 있다.  라고 했더니,  자기 자랑하는 것은 좋은데 그걸로는 투자의 평가가 되지 않는다.  라고 못이 박혔다.  실리콘밸리에서 이런 이야기가 있었다.  물구나무서기를 못하는 사람이  일 주일동안 물구나무 서기를 연습한 동영상을 보여주고 자기는 아무리 못하는 것이라도  남들보다 많은 노력을 기울일 자신이 있다면서 어필하자  투자자들이 들어왔다. 이런 이야기를 하면 그건 실리콘밸리 이야기이니까 비교하려면 네가 실리콘밸리 가던가 라는 식으로 바로

만화를 보던 영화를 보던 드라마를 보던 나를 투영시키는 경우가 많다.  특히나 사회에 적응 못하는 부류의 이야기는 더욱 빠져드는 편이다.  계속 사회에서 거부당하는 사람들은  자신은 틀리지 않았는데 왜그런지 이유를 모르는 케이스가 많다.  개중에는 정말로 사람들에게 폐를 끼치면서 그걸 모르는 사람도 있지만,  사람들을 생각해주지만 사람들에게 상처받고 있는 사람들에게 해주고 싶은 말이다.  giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

전 아이디어가 있으면 공개하는 주의 입니다. 제가 이루지 못할 거면 다른 누군가가 해주는게 나으니까요. 전기는 전력의 생산에서 저장, 유통, 사용, 회수(?) 정도로 하나의 에코시스템(생태계)을 이룰 수 있습니다. 이 중에서 생산은 거의 국가에서 만든 발전소를 메인으로 하는데요, 아직 전기 생산성이 투자대비 효율이 적어 국가의 예산으로 진행할 수 밖에 없겠지요. 하지만 점점 집광 패널의 비용이 저렴해지면서 허들은 낮아지고 있습니다. 고효율의 고가격 패널보다는 20%전후의 저스펙 패널이 전기세 보다 투자대비 효율이 나기 시작하는 듯 합니다. 스타트업 중에는 집광 패널의 각도 및 집광 효율, 고장 발생등에 대한 보수 관련 쪽으로 시작한 기업들도 나오고 있네요. 그 다음이 저장입니다. 가장 큰 투자 비용이 들면서 정기적으로 교체를 해야 하므로 사용량 계산을 잘못하면 저장소가 가득차 전기를 버려야 하거나 저장소가 너무 많아 교체시마다 막대한 비용이 나올 수 있습니다. 이를 효율적으로 예측해주는 스타트업은 아직 못봤는데 있지 않을까요? 저장된 전기는 현재는 자가소비가 대부분이지만, 이제는 전기를 배달하는 시대가 올 것입니다. 얼마전 소개 된 전기 자동차 여러대가 전기를 필요로 하는 시설에 가서 전선을 꽂기만 하면 공급을 해주는 시설이 나온 적이 있지요. 전기를 필요로 하는 곳에 직접 전기를 공급해주는 전기의 유통이 시작되려 하고 있습니다. 이 곳에 지금 들어간다면 꽤 좋은 타이밍에 시장의 상승에 올라타지 않을까요? 전기의 사용은 예전부터 지속적으로 있었고 앞으로도 고효율 전기장치를 중심으로 발전은 계속 될 것입니다. 모터 기술로 적은 전기로 강한 힘을 낸다거나 말이죠.. 마지막으로 회수 라는 개념은 아직은 많지 않지만, 이미 모바일 배터리 대여 서비스 등이 나오고 있지요. 빌리는 것은 쉬운데 돌려주는 곳이 한정될 수록 이용자의 불만은 커질 것입니다. 이를 막기 위한 물류연계가 중요하겠지요. 편의점은 사라지지 않을 거란 제 생각을 뒷밭침하는 이야기 이기도 하구요. 전기의

중복 되는 이야기를 자주 쓰긴 하지만,  중간중간 정리하고 통합하겠습니다. ^^ 한국의 IT Outsourcing 시장은  서점에서 파는 모 백서에 따르면 년매출 약 4조원 정도 됩니다.  공교롭게도 94%는 대기업과 공공기관에서 발주하는 물량이구요,  6%인 2400억원 정도가 중견 이하에서 올리는 매출이지요.  물론 중견기업과 중소기업의 많은 부분조차 대기업의 하청으로 생기는 물량이기 때문에 중소기업자체의 매출은 극히 드물다고 생각하시면 됩니다.  IT에 종사하시는 분들은 그냥 실감이 나실 것입니다.  이 글을 읽고 있는 본인 뿐만아니라 많은 동종업계 종사자 분들이 늘상 하는 얘기는 조달청에 어떻게 하면 입찰을 잘하는지 눈여겨 본다거나 국가 예산 따먹기를 위해 얼마나 머리를 굴려야 하는지.. 즉, IT다운 곳에 쓰이는 금액 보다는  얼마나 눈치를 잘보고  제안서를 화려하게 잘 쓰고 화려한 입담으로 담당자를 속여 넘겨야  되는지를 자랑처럼 늘어 놓습니다.  심지어는 국가 예산 통과를 도와주는 전문 기업도 나오고 있지요.  그렇게 국가에서 2억의 예산을 받으면 통과 기업이니 기술료니 비용 계상(計上)을 도와준 기업의 수수료니 하면 반은 빠져 나갑니다.  그리고 나서 나머지 금액으로 국가에 형식적으로 리포팅하면서 버리는 시간과 비용을 생각하면.... 남는게 없지만 현상 유지를 위해선 여기에 매달려 이게 주업이 된 기업들도 많지요.  늘상 비교를 하고 있지만,  일본의 IT Outsourcing 시장만 보더라도 1등 기업이 4조엔(한화 44조여원)이지만,  한국과는 달리 2등 기업이 약 2.5조엔(한화 28조여원)으로 상위 기업들이 엄청난 편차를 가지고 있지 않습니다.  그냥 30세의 독립한 소규모 IT Outsourcing사업을 하는 젋은 사람도 200억엔(한화 2200억여원) 매출을 내기도 하니까요. 한국에서는 상상할 수도 없는 숫자입니다. 시장 자체가 작으니까요..   그리고 이들은 자기네의 이득이 되지 않는다면 출혈경쟁을 하지 않습니다.  즉, 이익을 조금

현대에는 거의 모든 사람이 동일한 조건하에 정보를 손에 얻을 수가 있습니다. 하지만 컨설팅을 나가보면 많은 전문가라 불리는 사람들의 수준이 너무 차이가 많이 나서 고객도 혼란해 하고, 컨설턴트 끼리도 스스로의 애매한 지식을 피력하려 부적절한 방법을 사용하는 경우가 많습니다. 저의 경우는 제가 얻고 있는 지식원을 모두 공개합니다. 주변에서는 그렇게 하다가 그걸 모두 얻은 사람이 고객을 가로채면 어떡하느냐? 라는 근심스런 조언을 주시는 분들도 있습니다. 그럴 때마다 반박하지요. 제가 얻는 지식 역시 누구나 엑세스 가능한 정보이며, 늦냐 빠르냐의 차이이지 언젠가는 도달할 영역입니다. 굳이 이런거 알려주지 않으려 애쓰는 모습을 보면 패스워드를 알려주지 않음으로서 자신의 존재가치를 어필하는 꼰대 상사랑 같다는 생각을 금치 못합니다. 오히려 제 정보원을 공유하고 서로 정보의 넓이를 넓혀갈 수 있는 사람들을 모으는 것이 훨씬 서로에게 이득이 되기 때문에 정리한 정보조차 공유하고 있습니다. 본론으로 들어가서, 제가 가진 정보의 60%정도는 구글 검색에서 얻고 있습니다. 즉, 검색만 잘하면 많은 정보가 들어옵니다. 하지만 왜 서로 다른 정보를 찾을까요? 아마도 찾는 언어가 달라서일 겁니다. 저의 경우는 일본어 > 영어 > 한국어 순으로 검색합니다. 일본어 결과는 경험을 중심을 잘 정리된 블로그가 많기 때문이지요. 논문이나 원리 자체를 알기 위해서는 영문을 검색합니다. 거의 이 정도에서 대부분 필요한 정보가 손에 들어오지만, 간혹 한국어 내용중에 잘 정리한 글도 있기에 검색을 걸어봅니다. 언어 비율은 일본어 : 영어 : 한국어 = 6 : 3.9 : 0.1 정도 일까요? 그 외에도 LDA(Topic modeling)를 역산하여 정확한 구글의 의도를 찾아내는 것도 검색에 들이는 시간을 줄이거나 인간으로서 불가능한 수십 수백만의 구글 결과 문서에서 나에게 필요한 문서만을 추리는 방법론(Ascent Networks의 박대표님 감사합니다!)도 있지만 이건 너무 길어서 나중에

오라클은 sql을 실행하여 DDL SQL을 만든다거나 하는 것들이 가능한데 문제는 파일로 저장하면 애매한 부분에서 줄넘김이 되면서 에러를 발생시킨다.  이번에 이동해야 하는건 테이블만 12만개나 있어서  하나식 보면서 할 수가 없어 찾아보니.. 여러가지 옵션들이 있어  내 나름대로 정리해 봤다.  #get_ddl.sql set  long  100000 set  head  off set  feed  on set  wrap  on set  linesize  3200 set  pagesize  0 set  trimspool  on set  longchunksize  1024 spool insertout.txt select dbms_metadata.get_dll('TABLE', 'MyTablename', 'MyOwner'); exit long : 한 필드에 표시되는 문자 수. 적으면 내용이 중간에 잘린다.  head off : 필드명을 없앤다.  feed on : 한 필드 내의 줄넘김을 표시한다. off면 한줄만 표시되면서 다음 줄 이후는 잘린다.  wrap on : ?? 기억이;; linesize 3200 : 한 줄에 3200글자까지 지원.. 이게 작으면 오른쪽이 잘린다.  pagesize 0 : 한 줄에 표현하는 페이지.. 숫자가 커도 별로 의미 없이 공백만 생기므로 0으로 설정 trimsppo on : 이건 그냥 붙여봤는데 아직 테스트 안함. lognchunksize 1024 : 오른쪽 글자 잘림을 막아줌(linesize가 있어도 잘리는 경우 이것까지 넣으니까 다음줄로 안넘어가고 옆으로 잘 붙어준다.) spool filename.sql : filename.sql 파일로 출력해준다.  이렇게 처리하면 sql만 들어가기 때문에  echo "exit" >> filename.sql  등으로 exit을 넣어줘야 cli로 실행하는 경우 먹통이 되지 않는다.  Procedure, Function을 복사하

코드를 공부하는 글이 아니므로  샘플 코드등은 없으니  코드를 찾으시는 분들은 패스하셔도 됩니다.  개념 적인 접근, 그리고 사용법은 아는데  추가적인 돌파구를 위한  아이디어를 원하시는 분들을 위한 글입니다.  대부분 도큐먼트(글뭉치?)의 의미를  한 눈에 캐치하여  인덱싱하여  도큐먼트를 관리하기 위해  Topic Modeling을 사용하려 하고 있습니다.  하지만 단순히 LDA를 사용해봤자,  사용된 단어의 개수가 많은 글들끼리의 묶음 정도로 밖에 분류가 안됩니다.   https://en.wikipedia.org/wiki/Latent_Dirichlet_allocation LDA : 잠재적 디리클렛 배분법 google스러운  정보의 정리를 위해서는 하나만 사용하는 것이 아니라  다양한 ML모듈을 활용해야 하는데요..  예를 들어 이렇게 합니다.  LDA모듈로 문장을 읽어내면 단어의 기본형과 Document에서 사용된 단어수가 나오고 이를 기반으로 이 document의 topic에 해당할 법한 상위 단어들이 표시됩니다.  여러 document를 던질 수록  각각의 document그룹에서  사용된 빈도가 높은 단어들이 나옵니다.  여기서 topic이 다른 문서가 많이 섞일 수록 topic을 유추하는 확률이 많이 떨어집니다.  그리고 언어가 여러 언어일 수록  서로 모르는 언어가 되버리고 마는 것이지요.  여기서 제가 많이 사용하는 방법은,  모든 언어를 영어로 번역합니다.  google translate API는 무료로 소량의 번역을 해주는데 만약 google sheet의 translate 함수를 사용하면  속도는 조금 느릴 수 있으나 많은 제약이 사라집니다.  뭐, 구글 어카운트를 여러개 만들어서 돌리는 것도 방법이구요.  서비스로 사용할 분이라면 유료로 구입하는 게 당연하겠지만 이렇게 블로그의 글을 보시는 분들이라면 공부 정도의 레벨이겠죠? 이렇게 영어로 번역하면  문장이 어색해도 상관없습니다.  LDA는 자주 쓰인 단어에 대한 카테고라이징을 목적으로 하는

언제부터 테슬러가 무인 자율주행 자동차 회사가 되었나요? 우리나라 기사에서는 무인 자율 주행 자동차가 나오지 않으면 테슬러가 성립되지 않은 듯한 글이 많네요.  물론 모 기업의 주가를 방어하기 위한 사설이겠지만.. 테슬러는 전기 자동차의 구조에 많은 특허를 가지고 있습니다.  그 중에는 자율 주행에 대한 특허는 한 건도 없는 것으로 알고 있습니다.  테슬러를 이루고 있는 많은 기능(function)중에 자율 주행이 있습니다.  만약 현대 자동차가 시트를 메모리 하여 타는 사람에 자동으로 맞춰주는 기능을 개발하겠다 했다가  개발이 실패하면 현대차는 탈 수가 없는 것일까요? 광고가 과대인지 뭔지에 대해서는 전 모르겠습니다.  하지만 실제로 세일즈맨을 통한 설명과 실제 운전을 해본 결과 충분히 다른 차에서 테슬러로 갈아탈 수 있는 매력을 보여 주었습니다.  AI가 뭔지도 모르고 머신러닝이 뭔지도 모르고 어디서 주워들은 지식만을 가지고 이게 AI네 아니네 하고 끼워 맞추는 사람들이 갑자기 생각나네요.  영문 wikipedia에 글이 올라가면,  잘못 된 정보는 수많은 딴지 및 수정이 올라옵니다.  때문에 제 생각에는 실제 사전보다 진화하는 최신의 정보를 올리는 사전으로 신뢰도가 높다고 봅니다. (로컬 wikipedia는 그 언어 사용자에게 특화되어 신뢰도를 보장하긴 어렵지만) 때문에 최소한 서로 대화를 하기 위해서 사용하는 단어에 대해서는  사전이나 wikipedia(네OO 아닙니다!)를 서로 보면서 그 단어에 대해 인지하고 나서 얘기해야 하지 않을까요? 같은 말을 하면서 사용하는 용어의 인식이 달라 결과가 어긋나는 것을 너무 많이 보다보니 답답한 마음을 금치 못하겠네요.  테슬러는 자율 주행 자동차가 아니라 혁신적인 전기 자동차이며 자율 주행 기능을 탑재하며 그 자율 주행 기능이 발전하고 있습니다.  giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

얼마전 aws위에서 mongodb를 올려서 서비스를 구성한 구성표를 보았다.  이 구성표를 만든 팀은 예전에 내가 도와준다고 했을 때 이미 많은 서비스를 mongodb를 이용해서 서비스 했다고 자만하던 팀이라 그냥 지켜보기로 했던 팀이었다.  2Core/4GB의 mongos 2대가 서비스 헤더, 1대가 관리헤더 2Core/4GB의 mongoc 3대가 metadata, 3대가 로그의 metadata.  4Core/16GB VM을 5대를 올려서 3대를 mongod를 올리고 2대를 서비스로그를 저장하도록 구성 했다.  물론 세세한건 보지 않았지만,  당연히 EBS가 30GB이니 30GB모두 하나의 shard로 하여 1 shard 3 replica 이지 않았을까? 안에서 추가로 쪼개기에는 EBS사이즈가 작으니.. 개발 서버 포함 총 15대의 VM으로 구성된 예상비용은 월 약1200달러.  이것을 26대로 늘리고 월 약 1100달러로 줄이는 설계를 보여줬다.  그리고 성능은 기존의 약 6배. 비용으로 환산한다면 월 7200달러 어치의 성능을 1100달러로 보여준 것이다.  AWS HW의 특성상 IOPS성능이 일반 HW보다 1/5 수준으로 떨어지는 것을 어떻게 메꿀 수 있는지가 중요하다. 특히나 EBS가 SSD라고 할지언정 물리적으로 연결되어 있는 디스크가 아닌 이상 Storage Network의 처리 성능이 가장큰 병목이 발생한다. (AWS 및 Storage를 Network로 연결하는 클라우드 아키텍쳐는 모두 같은 문제) 그리고 AWS의 특성상 1vCPU는 1Core가 아니다. 예전에는 1vCPU의 성능 수치가 있었지만 지속적인 하드웨어 추가로 인해 기존 하드웨어와의 CPU모델이 달라져 성능이 다르게 나오고 있어 이 지표는 사라졌다. 1vCPU의 성능이 얼마만큼 나오는지를 이해하여야 한다.  그 다음으로 Virtualization의 성능(Para-virtualization, Full virtualization)에 따른 퍼포먼스 저하가 얼마나 일어나는지, Linux라는

MS의 저주일지도 모르지만,  역시 윈도우에서 발생하는 버그는 상상을 초월한다.  많은 부분을 Exception을 처리해도 알 수 없는 오류가.. 이번에는 Excel을 두 개 열어서 A파일의 S시트를 B파일로 복사해서  데이터를 그 포맷에 Write Range 로 쓰도록 하였다.  A파일의 S시트는 템플릿이 아니고 현재 사용하는 시트이다 보니 데이터가 있다.  그래서 Delete Range를 이용해서 삭제를 하니.. 에러가.. Excel Application Scope를 여러개 열면 뭔가 충돌이 난다.  그래서 이번에는 close workbook을 이용해서 매번 닫도록 해봤다.  그런데도 역시 Delete Range에서 알수없는 오류로 종료... B파일의 Excel Application Scope를 열어서 그 안에서 A파일의 Excel Application Scope를 열고, Copy -> Delete -> Write를 해보았다.  역시 에러.. 이번엔 분기를 해봤다.  Copy하는 경우는 Delete를 하지 않고,  Copy하지 않는 경우는 Delete를 하고..  기존 시트명이 있는 경우만 데이터를 삭제를 하는 방식이다.  이렇게 하니까 Delete Range는 성공 했으나 몇 개 실행하다보니 Excel workbook이 닫히지 않기 시작하면 다음 처리에서 에러가 발생..  두 개이상 workbook이 열리면 Write Range나 Delete Range에서 해당 파일을 찾지 못하는 것 같다.  결국 마지막 부분에 close workbook을 하여 강제로 죽여주니까 성공.. 그냥 놔둬도 닫히지만 안닫힐 때도 있는 경우에 따른 변수가 생겨서 close workbook의 타이밍에 따라서 에러가 나오기도 안나오기도 하네.. 윈도우즈의 버그는 ...  익셉션 처리하는게 코드 짜는 거보다 많은 거 같다.. -------- 추기1.  나중에 해보니 똑같은 에러가 빈도는 줄었지만 또 났다.  그래서 시도한 것이, Excel이 열리지 않은 경우는 workboo

전기차를 전기 생산이 어려운 곳에 여러 대를 가져가서 연결하여 발전기 대신 사용하는 기술이 나왔다.  일본의 전기/하이브리드 자동차는 전체 자동차 시장의 이미 87%를 넘어서고 있다.  전기 자전거는 이제 일반화 되어 일반 자전거와 큰 가격차이가 안나고 있다.  배터리 기술이 발전하면서 전기에 대한 활용도가 점점 높아지고 있는 와중에 캠핑, 여행 등에서 필요한 전력 공급을 살펴보는 도중 태양광 패널에 관심을 가지기 시작했다.  참고로 태양열 발전은 보일러가 있고, 태양광선을 보일러에 집중시켜 보일러를 덥혀서 증기 기관을 돌리는 방식이고, 태양광 발전은 전극소자에 태양광을 집중시켜 발생한 전하의 흐름을 캐치하여 충전하는 방식이다.  즉, 사람들이 태양열.. 이라고 하는 것의 대부분은 태양광 발전을 뜻한다.  태양광 발전을 효율적으로 축전 시키는 컨트롤러가 필요한데 이 컨트롤러(Solar power regulator)는 MPPT방식과 PWM방식이 현재 가장 널리 쓰이고 있다.  그럼 태양광 패널을 직접 배터리에 붙이면 안되냐고? 배터리에 역류 방지 및 과충전 방지 회로(BMS, Battery Management System)가 있으면 문제는 없다. 만약 없는데 직접 연결한다면 리튬이온 배터리의 위험성을 몸소 체험할 수 있다.  충전 컨트롤러 방식을 소개하는 글은 아주 많은데,  초보자도 알기 쉽게 소개하는 글은 하나도 보이지 않고, 그냥 이게 좋다 라던가, 어려운 회로도만 어디서 퍼와서는 내용은 아무것도 없는 글이 많다.  초보자도 알기 쉽게 설명을 하자면 PWM(Pulse Width Modulation)은 충전가능한 전압으로 낮추면서도 전류는 그대로 유지하는 불필요한 전압을 버리는 방식이다. 굳이 단어의 의미를 이용해서 이해하려 하지 말자.. MPPT(Maximum Power Point Tracking)은 DC-DC 인버터가 내장되어 있어 전압을 떨구면 자동으로 전류가 강해지는 변압코일의 특성을 살린 부품이 추가로 들어 있어 가격이 비싼대신에 전압이 떨어져도 전

정리는 시간나면 하고.. 일단 생각나는대로 적어둠. VBS에서는 for each를 이용해서 필드명을 가져오는 방법등이 있었지만 이는 원래 Recordset등의 필드명이 지정되었을 경우에만 해당한다.  datatable을 vbs에서 어떻게 for each로 만들지는 아직 연구하지 않았기 때문에 일단 패스, 아마 csv에서 첫 행을 헤더로 읽거나 xlsx에서 첫 행을 header로 읽으면 가능할 듯 하지만,  쉬운 방법으로 일단 기술해 본다.  ## csv의 경우 파일을 header있음으로 우선 datatable에 저장. 그리고 다시 파일을 text읽기로 하여 첫 로우만 변수로 저장. 저장된 변수를 sFields라고하면 aryFields = split(sFields, ",")  로 assign activity에 집어 넣음 물론 aryFields의 속성은 text속성의 array 타입 그리고 각 필드의 전후에 스페이스를 없애기 위해  Trim을 사용해서 스페이스를 없애줌. replace로 먼저 없애고 split을 하는 것도 가능. 그리고 datatable의 for each row 를 이용하여  매 row마다 for each로 aryFields를 호출(for each에서 row를 가져오면 안됨!) jLine = jLine + """" + item.toString + """:""" + row(item).toString + """" 이렇게 하면 필드 개수를 모르더라도 한 라인을 Json타입으로 가져올 수 있음.  물론 좌우는 {}를 적절히 넣어주고, 콤마도 적절히 if를 이용해서 넣을 것.  row(item).toString이 숫자인 경우의 처리는  Microsoft.VisualBasic.Information.IsNumeric 을 이용하여 판단 가능.  VBScript를 선택하였다 하더라도 MS Visual Basic과는 코드가

Insert into ~ on duplicate key update INSERT   INTO  tableA (sn, cateid, catename)  VALUES     ( 101 ,  'A001' ,  'CateA1' ),     ( 102 ,  'B001' ,  'CateB1' ),     ( 103 ,  'C001' ,  'CateC1' ),     ( 104 ,  'C002' ,  'CateC2C' ), ON  DUPLICATE  KEY   UPDATE  catename = ( CASE   WHEN  catename =  'C002'   THEN  catename  ELSE   values (catename)  END ); replace REPLACE   INTO  tableA (sn, cateid, catename)  VALUES     ( 101 ,  'A001' ,  'CateA1' ),     ( 102 ,  'B001' ,  'CateB1' ),     ( 103 ,  'C001' ,  'CateC1' ),     ( 104 ,  'C002' ,  'CateC2C' ); on duplicate key update의 경우 기존 row에서 update를 하지만,  replace into 는 delete + insert이기 때문에 default 필드 또는 auto_increment 필드는 신규 로우를 추가한 것과 같은 영향을 받음. giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

TodayYYYYMMDDHH24MISS= `date '+%Y%m%d%H%M%S'` TodayYYYYMMDD= `date '+%Y%m%d'` TomorrowYYYYMMDD= `date +%Y%m%d --date '1 day'` YesterdayYYYYMMDD= `date +%Y%m%d --date '1 day ago'` NextMonthYYYYMMDD= `date +%Y%m%d --date '1 month'` PrevMonthYYYYMMDD= `date +%Y%m%d --date '1 month ago'` giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

giip에서는 내가 만든 RPA스크립트로 인해서 얼마나 업무 시간을 줄여 주고 있는지 한 눈에 알 수 있습니다.  한 달 평균 업무 시간은 160시간 전후이지만,  로봇은 여러 대로 무한하게 일을 시킬 수 있기 때문에  내가 로봇들에게 시킨 업무로 인해 800시간을 줄일 수 있었네요!  점점 늘어나는 것을 기대하면서 계속 업무를 자동화 해가고 있습니다. ^^ UiPath를 사용해도 되고 Auto Hot Key를 사용해도 됩니다.  아니면 자신이 직접 만든 스크립트를 사용해도 됩니다.  이 모든 것을 giip에서 통합 관리를 하고, 자신이 만든 자동화가 얼마만큼의 인건비를 줄일 수 있었는지 알 수 있는 지표를 대시보드로 나타냈습니다.  여러분은 얼마나 많은 일을 아직까지 수동으로 하고 계신가요? giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

요즘 텔레워크가 많아지면서 가장 큰 이슈가 보안 이슈이다. 이 중에서 특정 IP에서만 작업이 가능한 환경이 많다. 이 때문에 VPN을 준비해줄 여력이 없는 작은 기업 또는 프리랜서들은 자신만의 고정 IP가 필요한 상황이다.  이 경우 AWS에서 VM을 생성하여 VPN설정을 하는 경우가 많은데,  가장 많이 걸리는 경우가  일반적인 VPN프로토콜을 사용하는 경우  1723 Port외에 GRE Port를 오픈해 주어야 한다.  하지만 AWS에서는 GRE Port를 개방해 주지 않아서 멈춘다.  그렇다고 VPC를 direct connect를 이용하여 무지 비싸지게 구성할 수는 없다.  이 경우 openvpn만을 이용하여 UDP로 빠르게 구성할 수 있다.  우선 AWS에서 ubuntu vm을 small로 작은 것을 만들자.  그리고 openvpn인스톨 $ sudo apt install binutils $ sudo yum -y install openvpn 그 뒤에는 조금 복잡하지만 그냥 아래 커맨드를 복붙으로.. $ wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.6/EasyRSA-unix-v3.0.6.tgz $ tar -xvzf EasyRSA-unix-v3.0.6.tgz $ sudo mv EasyRSA-v3.0.6 /usr/local/EasyRSA $ cd /usr/local/EasyRSA/ $ cp -p vars.example vars $ vi vars set_var EASYRSA_CERT_EXPIRE 3650 $ cd /usr/local/EasyRSA/ $ ./easyrsa init-pki $ ./easyrsa build-ca $ ./easyrsa gen-dh $ ./easyrsa build-server-full server nopass $ ./easyrsa build-client-full client1 nopass 중간에 vi vars는 그 아래의 EASYRSA_CERT_EXPIRE값을 3

UiPath에서 Read CSV를 이용하면 Datatable에 저장이 된다.  이를 tab으로 분리된 text파일로 저장을 하는데는 몇 가지 방법이 있다.  1. write text 액티비티를 사용하는 경우 write text를 하게 되면, 그냥 텍스트로 저장이 되면서 tsv포맷에 맞지 않게 되고,  내용이 없는 경우 필드명도 표시 되지 않는다.  2. write excel을 이용 write excel 액티비티를 이용하여 저장후 이를 excel application scope를 이용해서 연 다음 다른이름으로 저장을 하여 txt파일로 저장. 번거롭지만 가장 편하게 tsv형태로 저장 가능 3. 하드코딩 첫 행에 필드명을 탭으로 나열 for each datarow를 이용하여 행을 읽은 뒤에 for each item으로 각 필드를 변수에 넣으면서 사이에 tab을 추가,  데이터가 없는 경우 필드명을 for each에 넣으면 데이터가 없기 때문에 패스한다.  때문에 첫 행은 하드코딩을 해야 하는 불편함이 있어 확정된 케이스가 아니라면 사용하기 귀찮다. 이걸 할 바엔 차라리 1번의 write text를 사용하는 것을 추천. Automation human works! giip :: Free mix RPA orchestration service! https://giipasp.azurewebsites.net/

남의 것을 모방하는 것이 나쁘다는 이야기도 많다. 남의 아이디어를 훔치는 것이 나쁘다고들 한다. 하지만 100%창조를 하는 사람은 거의 없다.  천재 조차도 어디선가 영감을 얻었다고 이야기를 하며 만드는 새로운 것들.. 이것 역시 자연이나 누군가의 사람에게서 얻게된 모방의 산물이 된다. 한글의 모음 구조는 목의 음성의 위치를 모방 했다. 중국어는 새의 발자국을 모방했다. 즉, 모방이 문제가 되는 것이 아닌 것 같다. 클라우드가 확산 되자마자 클라우드를 분석하여 클라우드를 충실하게 구현한 오피스365는 따라하기 이지만 욕먹는 것이 아니다. MS는  원래부터 마우스를 잡스에게서 따라하고 윈도우를 Packard bell에서 가져왔다. 이 전에 MS-DOS는 PC-DOS에서 가져온 것이다. 이렇게 따라하기를 사업화로 1위를 넘어서 MS가 1위가 된 것이다. 초기에는 나도 욕했다. 따라하기로 1위를 제끼는건 치사하지 않아? 하지만 서두에서도 보였지만, 남을 짓밟기가 아니라 경쟁에서 고객의 선택을 받게 하는 곳에 얼마나 치중하느냐가 중요한 것 같다. 한국에서 스타트업을 할 때 투자자들과 가장 큰 마찰이 여기 있었다. 투자자들은 Lock-on 을 왜 안하느냐, 경쟁자가 올라온다면 어떻게 경쟁자를 물리칠 것이냐를 듣고나서 투자 가치를 판단한다. 투자자들은 경쟁자를 겁내하며 경쟁자 죽이기에 온 힘을 기울일 것을 종용한다. 난 그게 싫어서 우리 서비스가 맘에 안들면 얼마든지 쉽게 나갈 수 있도록 배려했다. 결국 한 푼도 투자는 받지 못했다. LG는  삼성과는 달리 사업분야가 엄청나게 넓다. 그리고 독자 기술은 없다. OLED기술은 처음부터 LG가 개발한 것이 아니라 원래 있는 기술의 상용화를 빨리 한 것이다. LG의 정책은 없는 기술을 만드는 것이 아니라 고객이 필요로 하면 직접 만들자.. 인 것이다. 그러다보니 너무 많은 사업에 손을 댔지만 직접 생산이다 보니 손실이 크지 않고, 매출도 고객의 니즈에 맞추다보니 최소

아마도 UiPath에서 실수한 것 중에 하나가 Switch activity인 것 같다. 다른 것들은 모두 VBS(Visual Basic Script)를 기준으로 만들었는데 switch만은 독자 표현 형식으로 되어 있다. 때문에 많이 헛갈리면서 뭔가 쌩뚱맞는 느낌을 받는다. VB에는 Switch가 없고 Select Case문이 있다. 이 때문에 switch는 C에서 가져오다가 서로 엇갈린게 아닐까 싶다. 가장 유의할 점은 각 case의 조건 부분에 따옴표를 넣으면 안된다. 예를 들어 s가 "K" 일 때, "L"일때를 구분해서 무언가를 하고 싶다. switch이외의 모든 activity는 s는 변수이기 때문에 "K" 등의 식으로 표현한다. if activity를 보면 condition에 s = "K" 라고 입력한다. 하지만 switch는 K 라고 따옴표 없이 입력해야 한다. 이걸로 처음에는 이상이 없는데 그냥 조건을 무시해서 결국 switch를 못쓰고 if로 어떻게든 했는데, 이런 버그아닌 버그가 있다는 사실을 늦게 알아서 나중에 바꾸는라 고생이 많았다. WWF(Windows Workflow Foundation)에서 잘못 만들었을까? 누가 잘못 만들었던간에 통일을 시키고 싶은 activity중 하나이다. Do not login your server any more! giip :: Free server management tool! https://giipasp.azurewebsites.net/

휴대용 단말기가 증가함에 따라 외장형 보조배터리의 수요가 급증하고 있습니다. 2011년 경에 이를 예견하고 사업을 하려 했으나, 그 때는 너무 수요가 없어서 구매가 없었죠;; 그래도 저장장치를 좋아하는 성격에 에너지 저장장치인 외장형 배터리를 다양한 종류로 사보고 개조해보면서 여러가지 용도를 찾고 있었습니다. 그러다가 주변에서 외장형 배터리 구매를 하면서 물어보는 것들이 있어서 참고가 되지 않을까 해서 정리해 봅니다. 요즘은 30000mA 용량의 배터리도 많이 팔리고 있어서 자신에게 맞는 배터리 사이즈도 생각해서 구매를 고려해보시기 바랍니다. * 시작하기 전에... 18650 Li-ion배터리에 대한 고찰 최근 배터리에 관심있는 사람들은 아마 이 모델의 배터리를 알 것입니다. AA전지 사이즈보다 크면서 생긴건 비슷하여 잘못 구입하시는 분들도 있을 수 있지만, 한국에서는 잘 팔지 않는 배터리다보니 쉽게 접하지 않아 잘못 구매는 어렵지요.. 18650배터리가 시장에서 각광받는 이유는 AA전지보다 조금 크면서 3.7V의 고전압을 낼 수 있어 AA전지를 직렬로 3개를 연결한 만큼의 전압을 냅니다. 게다가 Li-ion(리튬이온) 배터리라 메모리 효과가 없어서 좋고, 용량도 굉장히 커서 요즘 저가로 판매되는 많은 외장 배터리가 18650 배터리를 많이 사용합니다. 한때 국내에서 히트 쳤던 샤오미 10000mA배터리도 2500mA짜리 네 개를 연결했는데도 저렴하고 굉장히 작아서 인기를 끌었지요.. 하지만 아직 18650 배터리의 중대한 단점이 있습니다. 바로 안정성 입니다. 리튬이온 배터리 자체의 문제인데요.. 리튬이온 배터리는 폭발이 쉽고 폭발의 영향도 커서 거의 폭발물 취급을 해도 될 정도 입니다. 때문에 안전을 위해 과전류 방지 회로를 배터리마다 탑재하는 것을 의무시 하여 판매하는 국가도 있지만, 국내에는 그런 규정이 아직 없는 것 같습니다. 배터리의 개당 단가가 워낙 저렴해서 회로 비용을 아끼기 위해 중국산은 넣지 않고 판