기본 콘텐츠로 건너뛰기

7월, 2024의 게시물 표시

급발진 사고대책이 페달블랙박스라구요? 근본적으로 틀리지 않아요?

영상버전 :  https://youtu.be/3oFR1TK6qoU 전에도 다뤘던 급발진 이야기 입니다만…  뭔가 좀 이상해서 가지고 나와 봤습니다.   요즘 급발진의심 사고가 갑자기 많아지면서 페달 블랙박스를 달아야 한다느니 하는 이야기가 늘고있는데,  누군가 그냥 여론을 몰고가는 느낌이 강하다고 느끼는 건 저 뿐인가요?  근본적인 해결은 사고가 나지 않아야 하는데  시비를 가리는게 최우선이 된 느낌은 저만 드는 생각일까요?  한국의 ecu는 자체 개발이 아니라 오래전 독일에서 사온 것을 지금까지 수정하면서 쓴 것이라고 합니다.  뭐, 제 정보가 오래되서 지금은 직접 개발헐 능력이 되는지 모르겠지만, 그렇다면 더욱 큰일이겠죠?  2007년경의 토요타의 급발진의심 사고 시점에 토요타에서 쓰던 ecu외 코드와 현재 국내 제조사의 ecu코드가 같은지 모르겠으나,  그 때 당시 독일의 제 삼업체가 토요타의 ecu소스를 분석하다가  행이 걸렸을 때 쓰로틀 값을 1(전체개방)으로 설정한다는 결과를 찾았습니다.  엑셀의 압력을 감지해 쓰로틀의 각도를 0에서 1사이값으로 주는데 그에 맞추어 쓰로틀의 각도가 바뀌는 구조입니다.  즉 정전기든 충격이든 뭔가의 이유에 의해  Ecu가 먹통이 되었을 때 엑셀을 밟은 것과 같은 상태로 하고 죽어버린다는 것이죠.  이 조사결과로 토요타는 피해자와 30억엔으로 합의를 했다고 합니다.  대신 합의하고 고소 취하되어 현재도 토요타는 급발진사고 없음으로 포장하고 있죠.  자동차 업체야 이미지 관리를 위해 그렇게 한다 칩시다.  그럼 한국의 제조사는 피해자들에게 뭐라도 해준 것이 있나요?  갤럭시를 수 천만대 팔았는데 그 중에서 내꺼가 우연히 먹통이 되었습니다.  계속 써야해서 재기동 해서 해결 후   서비스센터에 가져갔더니 문제가 없고,  먹통은 재현이 안되더랍니다.  그런 상태에서 먹통 상태가 재현이 안되는데 전수 리콜할 리가 없죠.  이런 상황을 겪어보신분 은근히 계실겁니다.  자동차 역시 그런 os가 깔린 스마트폰같은 마이크로 컴퓨터인

월99만엔 TiDB SES 파견 프로젝트.. 이지만 운영 효율화... 일본IT

영상버전 :  https://youtu.be/F-KO_D694pQ 벌써 3주차가 끝났네요..  하루에 5시간 이상을 이야기하면서 진행하는건 체력을 너무 소모시키는 것 같습니다.  하지만, 기존 멤버들이 경험이 너무 없어서 제가 알려주면서 해야 하다보니 거의 상시 미팅 모드로 이것저것 알려주게 되네요..  새로 들어온 두 명중 한 명은 0.2 MM이니 미팅만 하고 일도 시킬 수 없는 상태이고,  또 다른 한 명은 열심히 마이그레이션 프로젝트를 분석하면서 문서화를 하고 있는 것 같습니다.  정작 신규 멤버 중 실무에 투입가능한 사람이 저 뿐이라  제가 풀 가동 되는 느낌이네요..  그래서 미팅 사이에 작업시간이나 다음 미팅 준비 시간에는 거의 누워서 쉬고 있습니다.  리모트 프로젝트의 메리트랄까요..  눈치 안보고 틈틈히 드러누워 쉴 수 있다는.. ----------------------- 얼마전 고객사와 파견회사와의 중간 평가가 있었고,  그 결과를  제게 공유를 해주더라구요..  내용을 해석하자면..  - 처음 면담시 기대했던 만큼 스페셜리스트로서 기술적인 지식이 너무나 풍부 - 참가 멤버들로부터의 평가도 좋음 - 엄청나게 우수한 분이라서 이후 멤버 쪽에서 따라지 못할까봐 걱정 (불만이라는 뜻은 전혀 아니고 [도와주면 아주 고맙다]라는 늬앙스 입니다. 라고 피드백을 받았다네요..  이제 2주차 보여준건 거의 없는데..  하면서 제자랑도 한 번 해주구요..  ------------------------------------------------------ 아뭏든..  3주차에 했던 것 들 중에는  눈에 띄는 것들이 운영 효율화 입니다.  꽤 오래전 내용 중에  대기업은 Azure를 많이 쓰고 스타트업은 AWS를 많이 쓴다고 하였죠? 한국에선 AWS만 생각하시는 분들이 많아서  이 내용을 모르시는 분들을 위해 다시 한 번 말씀 드리자면,  일본 뿐 아니라 전 세계적으로 대기업은 Azure를,  스타트업은 AWS를 많이 씁니다.  스타트업의 문화를 좋아하

월99만엔 TiDB프로젝트 2주째. 기존 디비의 튜닝

영상버전 :  https://youtu.be/VO7eNgFAGDA 2주 째에 들어왔습니다.  업무시간 8시간 중에 거의 5~6시간은 화상회의를 켜놓고 하게 되네요.  너무 지치는군요..  지난 번 프로젝트가 너무 널럴해서 그랬나봐요..^^;;;  한국과 조금 다른 것은  모두들 발언을 신중히 하기 때문에 말은 많지 않으나,  그 사람들의 말이 정말 이런 이유인지 아니면 다른 원인으로 인한 것인지를 찾는데 신경을 쓰다보니  더 빨리 피곤해지는데요..  지금은 TiDB 잘한다는 사람이 앞단의 교통정리를 헤주고 있으니 잘 하겠죠.  정말 잘할지는 모르겠으나 월권은 귀찮으니.. 하다가 폭탄 만들면 프로젝트를 뜨는 걸로..  SES는 SI와는 달리 프로젝트가 맘에 안들면 언제든 뜰 수 있는게 부담 없어 좋습니다.  리더를 해도 내가 합당한 이유를 우리쪽 영업에게 이야기 하면 빼주거든요..  요즘처럼 사람이 부족한 시기는 고를게 많아서  아무리 비수기라 해도 사람이 부족해 뒤늦게 가격 올려서 구인 하는 경우도 있어요.    첫주엔 27분기 총회가 있어서 참여를…  잊어먹고, 나중에 녹화방송을 봤습니다.  사원은 지금 마구 뽑아서 200명이 되었는데.. 3년 전에 수십억엔 매출이 2년전에 850억, 작년에 1850억엔이었네요..  레드오션이라는 화장품 시장에서 스타트업이 이 정도 수직상승이 가능…하네요..  여기 정사원들은 나중에 스톡 받겠네요…좋겠다…^^;;;  그건 그렇고..  이번주에 기억나는게 두 가지 있었는데요..  하나는 sql server의 리플리케이션이 끊어져 다시 걸어달라는 내용이었습니다.  얘네들은 부하가 너무 커져서 8대의 리플리케이션용 디스트리뷰터 조차 따로 두어서 마스터의 부하를 최소한으로 운영한건 좋었는데.. 마스터의 HA구성으로 대기용 마스터에서 가져오면 될 걸 액티브 마스터에서 가져가는 방식이네요.   레플리카는 보통 5대가 최적이고 그 이상 늘리면 데이터 동기 타이밍에 지연이 생기기 시적합니다. 그렇다고 8대는 안되요가 아니고, 영점 몇 초

월99만엔 파견 현장(SES) 신규 프로젝트 참여한 이야기. TiDB Migration

영상버전 :  https://youtu.be/OaDuZvE1ViQ 7월 1일부터 참여한 젊은 화장품 판매 기업의 DB이전 프로젝트 입니다.  연매출 2000억엔에  오프라인 제휴 매장 포함 26개 라던가요? 사원은 200명..  온라인 구치코미를 분석해서 잘팔리는 제품의 순환이  이 기업의 핵심가치 같네요.  때문에 가장 중요한 것은 구치코미 데이터인 듯 합니다.  여기서  구치 는 입이고  코미는 코뮤니티의 앞글자 입니다.  그래서  사람들의 말을 모아놓은 커뮤니티를 말하는 것이지요.  우리말로 하면 평점 같은 느낌이려나요? 일본의 구치코미는 한국만큼 오염되진 않아서 돈으로 매수한 것도 좀 있긴 하지만,  지나치지 않게 하는 것 같습니다.  때문에 구치코미에 대한 신뢰는 아주 크구요.  이 프로젝트의 가장 큰 문제는  회의가 너무 많다!  그냥 하루에 세 번 미팅은 기본이고,  전 서너번이 보통인데,  정사원들은 작업 시간이 하루에 한 두시간이고  나머진 전부 미팅인 거 같네요..  그리고 티켓 시스템이 다섯 종류..  각 부서마다 자기네 티켓 시스템을 따로 쓰기 때문에  레드마인에서 처음보는 시스템까지 골고루 사용 중입니다.  가장 크리티컬한 것은..  SQL 서버를 사용하고 TiDB 이관을 하기로 했는데,  모든 멤버가 SQL 서버와 TiDB를 잘 모르는 것입니다.  유저의 급증으로 인해 SQL서버가 자주 뻗는대요..  그래서 TiDB로 변경하면 대규모 OLSP랑 OLAP 처리가 가능하다는 영업(?)에 넘어가서  TiDB TF팀을 결성해서 순차적으로 이동 중이라고 합니다.  현재 가장 부하가 적은 MySQL의 테이블 두 개를 이동하고,  조금 용량이 큰 데이터를 이동 중에 성능 이슈가 있어서 해결 중이라고 하네요.  DBRE팀이라고 하여 DB관련 이슈를 해결하는 팀에  기존 정사원 2 명중 한 명은 DB를 잘 아는 편은 아니지만 그나마 알고 있고,  또 한명은 작년에 입사한 신입사원입니다.  그리고 저 포함 세 명이 외부에서 들어왔는데 한 명은 TiDB전