기본 콘텐츠로 건너뛰기

라벨이 일본it인 게시물 표시

나의 게임 해킹 역사... 해킹 경험이 직업으로...

영상버전 :  https://youtu.be/4yR7YWNr84w 요즘 통 콘텐츠를 올리지 못했는데요..  사람마다 제각각 영상을 만드는 방법이 있는데요.. 전 보통 원고를 먼저 쓰고,  녹음을 하고,  그에 맞는 영상이나 이미지들을 찾아서  편집을 하면서 하나의 영상이 만들어집니다.  원고를 쓰고 있는게 많지만 아직 탈고한 것이 없다보니 계속 영상 제작이 늦어지고 있습니다. 보통 원고는 한 번에 쓰는게 아니라 한 번 가닥을 잡고, 며칠에 거쳐서 읽고 수정하고, 끼워넣고를 반복해서 하나의 원고가 완성이 됩니다. 거기서 부터 녹음 자체는 20분 이내에 끝나는데요..  녹음 된 파일에 맞추어 편집도 며칠이 걸리네요..  게다가 동영상도 많이 찍어서 파일들 정리도 만만찮구요.. 그런데 그거랑 달리  요즘 가장 시간을 잡아먹은게,  요즘 게임의 흐름을 보고자 게임을 몇 개 설치 했는데,  이게 시간을 무지 먹었습니다.  그러다보니 갑자기 생각이 난게..  내가 어릴 떄 게임에 빠져들게 된 게 조금 남다르지 않았나 싶어서 한 번 작성해 봅니다.  제일 처음 컴퓨터를 접한 것은 1982년 금성 FC-30이라는 4bit 컴퓨터였지요.  그 떄 이미 FC-150이라는 8비트 컴퓨터나 애플 2시리즈가 나왔고,  그 즈음에 MSX라는, 게임이 엄청많은 PC도 나왔지요..  그 속에서 초창기 PC 게임을 접하게 되었는데,  게임 속의 나는 너무 약하더랍니다.  실력도 없고, 지식도 없고.. 무작정 맨땅에 헤딩하면서 익히는 것이 너무 비효율적이었지요.. 그래서 게임속에서만큼은 전지전능이고 싶다는 일념하에 처음엔 공략집을 찾아다니고 무작정 공략을 했습니다.  이 때는 게임을 전문적으로 복제를 해주는 가게에서  복제된 게임을 샀는데,  사람을 모으기 위해 은마 상가에 있는 복제 가게에서는...

TiDB의 PoC결과에 태클 걸기

영상버전 :  https://youtu.be/mV7uoGQlm5g 이번엔 기술 vlog입니다.  제 기술 관련 이야기를 기다리시다가 쓸데없는 바이크 이야기 같은거 자주 올리니 구독 취소를 하시는 분들이 급증 했네요 ㅠㅡㅠ 사실 처음부터 자기 미래를 설계하는데 도움되는 정보를 찾으시는 분들이  들어오시는 곳이었으니 그렇겠지요..  그래도 일본에서 IT하는 사람이 이렇게 놀기도 하는 구나 하고  일본에서의 취미 생활에 참고도 해주셨으면 합니다. ^^;;; 아뭏든 기다리시던 이야기를 해드릴께요~ 7월부터 참가했던 SQL Server를 TIDB로 전환하는 프로젝트가  어느덧 많은 준비를 마치고 최종 PoC를 진행하고 있습니다.  제가 초기에는 TiDB가 더 느릴걸요? 등등의 가벼운 반박 정도를 하면서 어짜피 회사의 70명이 넘는 인원이 이 프로젝트에 연관되어 이전이 결정이 된 상태였습니다.  지난 번 DNP(대일본 출판, 일본 최대의 출판회사) 사건도 있었다보니 사실을 이야기하면 안되겠다 싶어서 그냥 시키는대로만 도와주려고 슬렁슬렁 하고 있었습니다.  그렇게 열심히 WBS도 만들어서 많은 부서에서 체크하고 2차 PoC까지 끝내던 어느날 이었습니다.  PoC결과 표를 보면서 리포트를 작성하는 회의를 했는데,  저도 초대 받아서 참여를 했지요.  1TiDB + 3TiKV에서 2TiDB + 6TiKV까지 4가지 패턴으로 테스트를 한 결과를 바탕으로 스파이크에 대한 이유와 해결 방법 등을 적으려고 TiDB쪽 사람이랑 이야기를 하던 중이었습니다.  2TiDB + 6TiKV만 스파이크가 없고 1TiDB + 3TiKV, 1TiDB + 6TiKV나 2TiDB + 3TiKV가 모두 스파이크가 존재했는데요.  TIDB담당자는 이 이유에 대해서는 그 떄 마침 무거운 쿼리가 들어왔을 거라고 몰아가고 있었습니다.  그런데 테스트 한 사람은 그냥 같은 쿼리를 반...

일본 IT 컨설턴트의 어느 하루 (파견직 외노자)

영상버전 :  https://youtu.be/f3IvPlthiFY 9:50 기상..  9시 50분에 기상해도 되냐구요? 침대에서 10걸음이면 일을 시작할 수 있는 재택이니까요!  요즘 몸이 안좋아서 자주 깨는 바람에 늦게 일어나네요..  몸이 괜찮을 때는 일찍 일어나서 여러가지 일을 하는데요..  요즘 어깨가 너무 아파서 1시간 마다 깨기도 하는데 50견이 원래 이렇게 아픈가요? 중간에 진통제를 한 번 더 먹고 어떻게든 잠이 듭니다... 9:55 반쯤 잠긴 눈으로 작업 개시 알람을 slack에 보냄 출근이 없다는게 얼마나 다행인지..  이젠 출근하는 현장은 못갈거 같네요..  저에게 Slack이 필수인 이유는요.. 일본은 보통 프로젝트마다 고객에게서 이메일 어카운트를 받아서 그걸 기준으로 연락 및 공유등을 하는데요, Slack만 유일하게 여러 이메일로 나뉘어진 워크스페이스를 하나의 앱에서 열 수가 있습니다.  보통 LINE이나 MS제품군들을 보면 어카운트 스위칭이 아니고 로그 아웃하고 다른 어카운트로 로그인 해야 하잖아요? Slack만이 한 번에 여러 프로젝트를 동시에 채팅하면서 스위칭할 수 있다는게 장점입니다. 한국 처럼 하나의 카톡으로 모든걸 하게 했으면 프로필을 프로젝트마다 지정할 수 없어서 힘들었을거에요..   게다가 Slack의 큰 장점 중 하나가 workflow를 코딩 가능한 기능입니다.  Slack을 사용한다는 분들을 보면 외부 API를 연결하는건 대부분 하시리라 봅니다만,  특정 웹 API에 맞는 폼을 직접 만들어서 그 폼대로 입력하면 API가 던져진다거나, 알람 채널에 알람이 뜨면 그걸 트리거로 해서 다른 작업이나 메시지를 보낼 수 있다거나 하는 기능들을 사용할 수 있습니다.  이런 워크플로 자동화는 다른 메신저에선 볼 수 없는 기능이지요.. 10:00 오전 DBRE팀의 기술 공부 미팅 참가 원래 참가 안해도 되지만, 무슨 헛소리를...

일본에서 내게 맞는 기업의 정사원이 되는 법(feat. 파견 활용하기)

영상버전 : https://youtu.be/6N43PnaHNqo 원래 이번에는 인덱스 튜닝 관련 이야기를 하려고 했는데,  이걸 먼저 올리고 싶어서 끼어들었습니다.  다들 파견이 안좋다고 많이 하는데 전 파견 관련 이야기를 많이 하고 있잖아요? 그리고 그에 대한 상담도 받고 제 경험에 비추어 안내를 해주고 있습니다.  일본의 비정규직이란 사람들은  보통 두어 군데 파견회사에 등록을 합니다.  그리고 파견회사가 소개해준 곳 중에 마음에 드는 곳으로  비정규직으로 들어갑니다.  외국인 중에 비자가 해결되지 않은 사람들은  비자를 발급해 준 곳에서 일을 해야만 하지요.  비자가 해결된 사람과 해결 안된 사람의 이 정도 현장 선택의 자유도가 차이납니다. 일을 하다가 맘에 안들거나 현장에서 일하는 사람이 마음에 안들어 교체 요구를 하는 등 서로 안맞으면 쉽게  현장을 바꿀 수 있는게 파견의 장점이면서,  회사도 개인도 계속 맞는 사람과 현장을 찾아서 돌아다닐 수 있다는게 매리트가 있지요.  그러다가 서로 잘 맞는 현장이 나타나면 10년이든 20년이든 하는 것 같습니다.  오래 하게 되면 정사원이 나은 경우 원청업체가 파견 알선 회사에 이야기 해서  정사원을 제안하기도 합니다.  이 때 파견 업체는 원청업체에 정사원으로 주는 대신 연봉의 30%를 감사료로 받습니다.  저 역시 자주 원청업체에서 제안이 오는데 제가 거부하고 있지요..  일본에서는 하나의 현장에서 3년 이상 비정규직을 지속할 수 없게 하는 법이 있다보니  3년마다 이동하거나, 약간 우회 방법을 통해 계약을 바꿔가며 한 곳에서 일하기도 합니다.  그렇다보니 괜찮은 인재가 있다면 정사원 영입을 해버리지요.  회사의 입장에서는 개인의 월급의 50%가 부대비용으로 나갑니다. 즉 회사는 한 사람을 고용해서 나가는 비용이 월급의 1.5...

DB튜닝 전문가 망했습니다..ㅠㅡㅠ

영상버전 :  https://youtu.be/iTmkJ2iWJuU 지금 프로젝트에서 개발자들이 프로시저를 만들다보니  개발자의 의식의 흐름대로 데이터 처리를 만들다보니 커서를 이용해서 테이블 변수에 넣고  그걸.  변수로 다른 테이블에서 조회하는 식으로 짜놨네요..  튜닝할 때 항상 하는 이야기 이죠.. Trigger와 커서는 절대 쓰지 말라구요..  이것처럼 속도를 저하시키고 락을 유발 시키는 장치는 없거든요..   트리거는 트리거링 포인트가 되었을 때 대상 테이블을 락을 건 뒤에 트리거 처리를 하고 나서 락을 해제 하기 때문에 아무리 빨리 끝나도 동시에 들어오는 쿼리에 따라서는 데드락에 빠질 가능성도 있습니다.   마찬가지로 커서 역시 테이블을 열고 커서를 만들어 처리하기 때문에 그 모든 처리가 끝날 때까지 락이 걸린 상태가 됩니다. 데이터가 변동하면 안되니까요..  그래서 트리거와 커서를 사용하면 기본 서너배는 느려집니다.  커서랑 트리거만 없어도 50만명 받을 서비스가 15만명도 못받게 되는거죠.. 경우에 따라서는 수백배 느리게 짤 수도 있는게 커서와 트리거 입니다. 그냥 서비스를 떨구든 말든 자기 편한대로 만들겠다는 생각이 있지 않는한 커서는 피하셔야 합니다.   개발자들이 커서를 많이 이용하는 이유는 커서를 이용해서 만들면 복잡한 처리를 할 때 별로 생각하지 않고 개발 코드처럼 만들어도 가능하기 때문이죠  이번 쿼리도 커서를 사용해서 아주 길게 만들어놨네요..   한 줄 읽어서 상태에 따라서 데이터를 매핑해서 테이블 변수에 넣고를 쭈욱 한 뒤에  그 테이블 변수를 다시 읽어서 다른 테이블의 값을 가져오는데..   튜닝을 잘하려면 이 모든 데이터가 머리속에 연결구조를 그려서   하나의 비정규화 된 배열을 만들 수 있어야 합니다.   매번 이야...

롯뽕기... 그리고 쿼리 튜닝

영상버전 : https://youtu.be/S7CDcs0bLJM 고객사에서 환영회를 하자고 해서 관련 사람들 7명이 모인 작은 노미까이에 초대 받아서 롯뽕기에 왔습니다.  롯뽕기는 수도고속도로 아래의 자투리 공간에 바이크 주차장을 운영중이네요..  국가에서 관리하는 곳이라 저렴하니 바이크로 롯뽕기에 오시는 분들은 참고 바랍니다.  30분에 100엔이고 12시간 이내라면 최대 1000엔으로 고정이므로 주차비 걱정을 안해도 될 듯 합니다.  노미까이에서 저를 극찬을 아끼지 않아주셔서 몸둘바를 몰랐는데..  오히려 제가 이 환경에선 담당자분들이 정말 좋은 환경의 튜닝을 경험할 수 있어서 행운이라고 말씀을 드렸지요.  SQL Server라는 RDBMS의 대표격인 제품의 특장점에서, 무료 MySQL엔진의 Aurora에 IOPS가 떨어지는 클라우드 환경에서의 튜닝기법, 그리고 Key Value 베이스인 TiDB환경에서의 튜닝방법까지 제게서 배워간다면,  어떠한 교육기관에서도 배울 수 없는 경험을 할 수 있으니 제가 가진 경험을 받아가실 수 있는 최고의 환경이라고 했지요..  참고로 여기 DB운영 사람이 부족해서 추가로 더 모집한다고 합니다. N1자격이나 동등의 일본어 능력을 가지신 분들 중에 이 프로젝트에서 저와 같이 하고 싶으신 분들은 연락 주세요~ ^^ 회사의 밸류가 구치코미, 즉 유저 평가의 분석을 무기로 한 기업이다 보니 AI에 대한 활용 방법론 등도 관심을 많이 가지고 있어 미래가 기대되는 곳이었습니다… 이런 건전한 이야기를 하면서 두 시간 코스로 식사를 하고 헤어졌는데요.. 2차를 가자고 했는데, 2차는 회사 내부 사람들과 가라고 하고 전 빠졌지요..  그런데 여기 사람들과는 좀 더 오랫동안 좋은 관계를 가지고 싶네요..  담당자 분들도 순수하고 밝고 내부에서도 서로 배려하는 모습이 아주 좋았습니다.  일단, 정치질 하려는 사람이 저랑 엮인 분들 사이에선 ...

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

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

월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의 테이블 두 개를 이동하고,  조금 용량이 큰 데이터를 이동 중에 성능 이슈가...

IT인프라의 기술 테크 트리 공유 합니다.

영상버전 :  https://youtu.be/zDDB-2vxBBQ 제가 이것저것 두서없이 제자랑만 하잖아요?  사람들에게 무언가의 전문가가 되기 위한 방법을 알려주려고 하다보니  이걸 공유하는게 낫지 않을까 하여 정리를 해봅니다.  전 개발쪽 보다는 인프라에 더 가깝지만,  개발하시는 분들도 알고 하는 것과 모르고 개발 하는 것은 천지차이이기 때문에 제가 정리한 내용을 보시면서  빼먹은게 있다면 하나씩 배워 가시는게 좋지 않을까 합니다.  테크 트리는 링크를 달아놓을께요..  https://app.diagrams.net/#G1FWtnOQBwebXVYlOf67iqojIzZod37iwL#%7B%22pageId%22%3A%22F8ncTlO_8FPAOhjwhj1Y%22%7D 지속적으로 추가할 테니 어딘가 즐겨 찾기를 해주시고, 수시로 확인하시면 좋을 것 같습니다.  추가하고 싶은 내용이 있으면 언제든 코멘트 주시면 수시로 추가하겠습니다.  이 기술을 배우고 싶은데 뭘 배우고 배우면 좋을까요?  같이 물어보시면 여기 테크트리에서 화살표만 따라 가면 되도록 만들 예정인데요..  예를 들어,  블록체인 기술을 알고 싶은 경우 암호화 알고리즘과 네트워크 기술, 그리고 파일 시스템 기술을 알면 배우기 쉽다 같은,  이런식으로 만들어가려고 합니다. 물론 이게 다는 아니겠지만 지속적으로 보완해 가면서 누구나 배우고자 하는 기술을 거슬러 올라가서 공부할 수 있게 하고자 합니다.  그리고 각 기술 박스를 클릭하면 링크가 달린 경우가 있는데요,  이 링크를 클릭하면 기본적으로 wikipedia를 연결해 놓겠습니다.  다국어로 하고 싶어서 기본은 영어로 하겠지만, 한글이라도 정말 좋은 문서가 있다면 한글 문서로 링크를 달 예정입니다.  혹시 스스로 만든 블로그 링크를 주시거나 하면  충분히 교육적으로 괜찮겠다 싶은 경우 ...

일본 취업 외국인이 바뀌고 있다! 해외 취업을 추천하는 이유

영상 버전 :  https://youtu.be/vRX40__6x18 일본 외국인 취업 변화표가 있어서 가지고 나와봤습니다.  https://www.mhlw.go.jp/stf/houdou/0000192073.html 2017년 재류자격 등록한 외국인 노동자 표입니다.  IT도 이 외노자 통계에 들어가지요..  그런데 2023년도 자료를 보니까 좀 재밌는 데이터가 있는데요..  https://www.mhlw.go.jp/stf/newpage_30367.html 그 중에서도 베트남 등록자가 갑자기 1위로 올라왔습니다.  전체적으로 숫자는 조금씩 늘었지만 베트남과 필리핀, 네팔 등지에서 두 배가 늘었고,  전체 숫자도 약 128만에서 약 205만명으로 거의 두 배 가까이 많아졌습니다.  단지 한국인은 5만5천명에서 7만1여명으로 20%가까이 올라, 많이 올랐음에도 다른 곳들에 비해 적게 늘어난 형태가 됩니다.  물론 당연한 것이,  일본에 취업했을 때의 메리트에 따른 사람들의 인식이 많이 달라졌다는게 한 몫 하겠죠.  한국 급여가 그만큼 가파르게 올랐기 때문에  굳이 일본이 좋아서 라는 등의 특수한 이유가 아닌 이상 더이상 일본에서 일하는 메리트는 크지 않지요.  하지만 제가 언제나 이야기 하는 것이 있죠.  한국에서만 일하는 사람과  외국어를 메인으로 일하는 사람의 차이가 얼마나 큰지는  경험자들은 말해주고 있습니다.  단지 급여가 높지 않아서 이젠 해외로 안나간다면,  거기서 멈추는 사람이 되겠지요? 모든 것의 가치 기준을 받는 돈 만으로 결정하는 사람들이 많아지는 요즘 세대에  10년 뒤의 자신의 가치를 보지 않고 지금 받는 일반적인 급여만을 보는 사람들이 많아졌다고 해야 할까요? 자신을 특별하게만 만들 수 있다면 급여표는 전혀 상관이 없습니다.  현재 남들이 얼마 받았네 하는 소리에 귀를...

2024년 4월부터 더욱 심화되는 일본 IT 인재 부족 현상

영상 버전 :  https://youtu.be/VpBbxItMpm4 정시스(情シス, 정보시스템)의 인력 부족이 심각해져가고 있네요.  https://www.fgl-ts.co.jp/blog/josys42 여러 분야의 잔업 규제가 심화됨에 따라  많은 산업에서 DX화를 더욱 가속화 하고,  그에 따른 IT인력 부족이 더욱 심화되고 있습니다.  문제의 발단은 2024년 4월 1일부터 시행되는  건설, 운송, 의료 및 기타 여러 분야에서  최대 잔업시간을 지정하여 초과할 수 없게 하는 법이 시행되었는데,  지금까지는 공공연하게 잔업수당을 주고 잔업을 시켜왔던것이  잔업 수당과는 별개로 강제 잔업 시간 상한을 정해버렸습니다.  이로서 각 업계는 부족한 업무를 다른 사람을 뽑아서 해야 하는데 그 동안 사람이 부족해서 잔업을 해왔던 터라  이제 남은 방법은 DX화를 해서 사람 손을 덜 가게 할 수 밖에 없는 상황이 되었습니다.  게다가 수년 전부터 정부 지원하에 지속된 DX현장에 사람은 부족한 상태라서  IT인재 부족은 더욱 가속화 되어가게 되었습니다.  DX란 것은 Digital Transformation이라고 해서  업무를 그 동안 사람이 해왔던 것이 있다면,  이걸 IT의 힘을 빌려 로봇 또는 컴퓨터가 업무를 대신해서 업무 효율화를 좋게 하기 위한 방법론이었는데,  일본은 한참 전 부터 DX를 위한 움직임을 많이 하여 많은 성과를 냈었고,  여전히 DX화를 위해 국가 지원의 많은 기업들이 경쟁력 향상을 꾀하고 있었죠.  많은 DX를 해왔음에도 다른 콘텐츠들을 보면 아시겠지만,  일본이란 나라가 워낙 아날로그다보니 DX의 니즈가 있음에도 DX화가 된게 22% 정도 밖에 안됬다는 자료도 있지요.  그나마 지속된 DX로 인한 결과로 한국보다 저렴한 내수 시장이 형성되었음에도 ...

일본의 솔루션 비즈니스는 한국과는 다르다. 실전 솔루션 비즈니스 경험

영상버전 :  https://youtu.be/z5hrHi-82ZY 얼마전 비즈니스 관련 이야기를 하다가 나온 말이었는데요..  한국에선 솔루션은 반드시 SI업체와 끼거나 솔루션 업체에 SI팀이 있어야 합니다.  이유는 특정 솔루션 영업을 가면  PoC를 하면서 자기네 입맛에 맞춰서 엄청 뒤집어야 하지요.  어떨 때는 완전히 새로운 솔루션이 탄생하기도 합니다.  그래서 한국의 솔루션 업체들 중에 업력이 오래된 곳의 상품을 보면,  정말 많은 커스텀 모듈이나 상품들이 즐비합니다.  그리고 신생 솔루션 업체는 솔루션이라고 만들었지만 대부분 커스터마이징 당할 것이라 생각해서 도큐먼트나 기능이 부족한 상태에서 영업이 들어가는 경우가 많습니다.  어짜피 솔루션 업체에서 아무리 기능을 미리 만들어둬도 거의 새로 커스터마이징 하는게 더 많거든요.. 해외의 모든 나라 통계는 모르겠는데요..  일본의 경우는 솔루션 영업을 가면..  솔루션에 있는 기능을 그대로 사용하고 없는기능은 api 를 찾아가면서 직접 개발 하는 경우가 많습니다.  즉, 솔루션 업체는 솔루션만 안정적으로 공급하면 된다는 것이지요.  때문에 솔루션을 사용하는 기업에서는 기본 기능 이외에도, 커스터마이징을 위한 API 문서가 얼마나 충실한지도 중요합니다.  여기서 일본환경과의 오해와 차이가 생기는데요..  한국 솔루션 기업은 어짜피 고객들이 자기 멋대로 말하면 솔루션 업체가 그 요구에 맞추어 커스터마이징 할게 뻔하다보니,  API를 만들어줘도 고객이 API를 쓸 이유가 없지요. 그냥 솔루션 업체에 시켜서 커스터마이징 된 UI만 쓰겠다고 자기네에 맞춰달라하니 API문서를 만들필요가 없고, API도 고객의 요구에 맞추다보니 새로 만들거나 사양 변경이 빈번하게 일어납니다.  때문에 문서화에 의미가 없어서 문서를 점점 등한시 하게 되었지요.  그걸 일본으로 가져...

일본 취업을 희망하는 대학생을 위한 한국에서 잘못알고 있는 일본 신졸 취업 시장.

영상 버전 :  https://youtu.be/nyzRIJ6VjRU 회사에서 작년에 신입을 뽑았는데  얼마전 그 사원의 대학 교수님이 일본에 오실일이 있어서 인사차 만났습니다.  그러면서 좀 충격적인 사실을 알았는데요..  그 때문에 자료를 정리를 해 보았습니다.  제 콘텐츠를 보시면 이미 일본은 3학년 12월에 100개 이상 지원을 해서 내정을 완료하는 경우가 많다고 합니다.  언제부터 취업활동을 하는지 봅시다.  일본은 대학 3학년의 3월 부터 설명회 엔트리를 시작합니다.  그 때 자신이 가고 싶은 회사들의 설명을 듣기 시작하는 것이지요.  그리고 취업활동의 시작은 5월 부터 인턴십 등 여러 방법으로 신입들을 선별하고 있죠. 그리고 일반적인 취업 종료는 대학교 4학년 6~7월이면 99.8%의 신졸 취업이 끝납니다.  그런데 한국의 대학에서 일본 신졸 취업을 보내는 시기는 바로 4학년 9월 정도 부터라고 하네요.  이 때는 이미 신졸 채용은 끝나고 중고신졸이라 불리는 정시 채용에 붙지 못한 신졸들을 주워가는 기업들이 기다리고 있는 시기이죠.  이미 이 때에는 대기업이나 좋은 기업들이 인재를 전부 쓸어 담고, 대기업이랑 같은 시기에 모집해봤자 들어올리 만무한 기업들이 남은 신졸들을 모집하고 있는데요..  그러니 많은 방송에서 신졸이 일본에서 좋은 기업에 취업할 수 없는 이유가 아닐까요?  실제로 교수님이 주변에 있는 전문대에서 야후 재팬에 신졸 채용 되었다고 현수막을 걸었다는 이야기를 했습니다.  제가 그 전문대는 3년제 아니었냐고 물었더니 3년제였다고 했네요..  제 예상이지만, 그 대학교는 3학년 부터 일본 신졸 취업에 지원을 했고, 늦지 않게 신졸 모집 대열에 들어간 것이 아닐까 합니다.  그러면 일반 대학에서도 3학년 부터 준비해서 보내면 되지 않느냐고 질문을 하자, 이런 지원 자체가 국가 지원을 받아서 ...

감정인식AI의 인프라 제안 - 일본IT컨설턴트의 프로젝트 2회차

영상버전 :  https://youtu.be/mVwIZ1nof8w 지난 번에 고객의 현재 상황 및 요건을 들었습니다.  원래라면 분석에 2주를 잡긴 하지만, 이번은 아주 간단해서 바로 1차 제안을 세 종류 만들어 봤습니다.  현재 개발사가 제안한 scaling에 대한 문제를 제기해야 겠지요..  우선 원래 시스템 중 문제가 있는 서버의 프로세스 구성입니다.  하나의 VM에 Listener, Real time analyzer, Final Analyzer의 세 개가 돌고 모든 IP PBX의 스트리밍 데이터를 받아서 하나의 VM이 처리를 하고 있는 식이죠.  이걸 분산하려고 하고 있습니다. 우선 개발사가 생각한 1안입니다.  하나의 인스턴스에 Thread를 나누어 처리를 하려고 합니다. 하지만 같은 인스턴스다보니 CPU가 터지는 지금 상황에서는 Thread를 분리해봤자 분리된 Thread가 터져서 인스턴스가 뻗을 것 같네요.  개발사가 제안한 2안 입니다.  이건 두 개의 인스턴스로 나누어 왼쪽에 IP PBX에서 데이터를 받아 리얼타임으로 저장하고 CPU부하가 큰 Final analysis는 다른 인스턴스에서 땡겨서 처리하겠다는 발상인데요.. 아마 이번에 테스트한 50세션 동시 처리에는 먹힐 지도 모르겠습니다. 30정도에서 터졌으니까요..  하지만 이건 일시방편이지, 유저를 계속 늘려가는 서비스 입장에서는 오히려 왼쪽 입구에서 받는 트래픽에 그걸 모아서 오른쪽의 VM 복수개에 동시에 파일을 내보내면 트래픽 병목으로 전송 실패가 나겠죠.  아마 700세션 전후에서 터질 것입니다.  그래서 제가 이 내용을 기준으로 일반적인 제안을 했습니다.  1안입니다.  전형적인 Application Gateway에 VMSS설정으로 Application gateway가 알아서 분산하고 VMSS가 알아서 부하도에 따라 증가 시키는 방식이죠.  장점은 Ap...