Talk Lowy(kr)

듣기 버전 :  https://youtu.be/efaWc-UWT80 팀 리더의 자질..  이 이야기는 2016년에 멘토링을 하면서 작성한 내용 입니다.  멘티와의 이야기 속에 프로젝트 리더 또는 팀 리더의 자질에 대한 질문이 들어왔습니다. 멘티는 자신이 곧 있으면 팀원을 가지게 되는데 정말 자신이 그만한 자질이 있는지, 자신이 팀원을 이끌 수 있는지 불안하다는 이야기였죠.  제가 질문을 했습니다. 나 : "팀의 리더는 어떤 능력을 가지고 있어야 할까요?" 그가 대답했습니다. 멘티 : "팀원을 이끌어 팀원의 능력을 개발하고 이게 회사에 보탬이 되게 해야 하는 것 아닐까요?" 제가 다시 물었습니다. 나 : "그럼 그 얘기하는대로 하는게 뭐가 어렵죠?" 멘티 : "자신이 그들의 기대에 맞춰서 이끌어 줄 수 있을지 걱정이 되고, 나도 일이 많은데 팀원들을 전부 케어할 수 있을지 걱정입니다. 그리고 팀원이라고 들어왔는데 기대하지 않는 일을 하면서 효율이 나지 않을 수도 있을것 같구요" 아마 처음 리더를 맡은 많은 팀 리더들이 가지는 고민일 겁니다.  회사는 직원이 될 사람과의 계약은 서로의 이득을 위해서 하는 것이라고 봅니다.  계약서를 읽어 보면 거의 비슷하겠지만, 우리가 학생 때 배우는게  회사는 이익 집단이고, 이익을 위해서 사람들과 계약을 하여  개인들의 노력이 회사에 이익을 가져다 준다고 하지 않았을까요? 하지만 잘 생각해 보세요.  회사는 이익을 위해서 사람과 계약을 해요.  그 사람의 미래는 회사가 알 수 없죠.  지금 그 사람을 돈을 주고 사는 것은 그 사람의 시간과 그 사람이 현재 가진 능력뿐이죠.  이것을 가지고 회사는 재화를 창출해야 하는 것입니다 .  그리고, 여기에는 어떠한 계약서에도 회사가 개인에게 비전을 주겠다 또는 주어야 한다는 조항은 없습니다.  결국 회사는 개인을 발전 시킬 의무가 없고,  그들이 스스로 발전하지 않으면 다음 해의 연봉 협상에서 연봉을 올릴만한 이유를

듣기 버전 :  https://youtu.be/G7zSPa90kd8 AWS와 Azure중에 무엇을 선택하면 좋을지에 대한 질문이 좀 있어서 올려봅니다. 한국에선 당연히 AWS라고 하고 또 레밍스 하고 있잖아요? 하지만 일본에서는 Azure의 쉐어도 엄청납니다. 이유를 좀 알아봐야겠지요? 일단 세계 클라우드 쉐어 입니다. 다들 아시다 시피 AWS가 1위이지만 거의 성장이 멈추어 있고, 가깝게 추격하면서 싸우는게 Azure지요? 그런데, 일본 총무성에는 이런 자료도 있습니다. Microsoft가 17.2%로 1위네요? 제가 지난 DB선택 코너에도 말씀 드렸듯이 1위 라는 것은 무엇을 기준으로 하느냐에 따라 달라집니다. Microsoft는 클라우드 서비스 전체 매출이 1위입니다. 말이 되냐구요? 역시 한국에서보는 정보 만으로는 그렇게 될 수밖에 없지요.. 다양한 글로벌 정보를 보시면 도움이 될 것입니다. AWS와 Azure의 커스터머 사이즈를 볼까요? 가장 초대규모 커스터머를 AWS는 23%밖에 못쥐고 있는데 비해 Azure는 33%나 가지고 있습니다. 대규모 커스터머 역시 AWS는 23%에 Azure는 33%네요.. 그런데 AWS는 미들 이하 사이즈에서는 압도적입니다. 자, 한국에서도 다시 한 번 주변을 보시겠어요? 스타트업 등의 기업들은 당연히 AWS를 쓰지만 중대형 규모의 기업들은 AWS를 쓰시나요? 여기서 일본과 극명하게 달라지는데요.. 한국의 MS매출을 볼까요? 1조원.. 엄청나죠? 그럼 일본의 MS매출을 볼까요? 1조엔.. 언제나 제가 비교하는 자료는 한국 대비 10배정도 차이나고 있군요.. 제가 예전부터 MS랑 같이 일본에서 많이 일을 해서 듣는 얘기인데요.. MS의 일본 매출은 중국을 제외한 APEC전체 매출보다 높다고 합니다. 불법복제가 만연하는 한국에선 당연히 MS를 선호할리가 없지만, 일본에선 대기업은 당연하게 MS가 엄청난 수익을 내고 있고, 그 때문에 MS는 대기업의 규모에 따라서 담당 컨설턴트를 붙여서 Azure도입을 가이드 해주고 있습니다

듣기 버전 :  https://youtu.be/9ewdp7RAwUw 전 일본 쉐어하우스에서 살면서 재미난 경험도 많았는데, 주인 아줌마랑 친해지면서 재미난 경험이 많았지요. 주인 아줌마가 한국 음식을 좋아해서 제가 가끔 김치찌게 라던가 김치 볶음밥 등을 만들어 주고 같이 정원에서 주인 가족들이랑 먹기도 하면 아주 좋아하더라구요.. 그리고 삼겹살 파티하고 남은 기름을 김치랑 밥을 넣어서 볶음밥으로 해주기도 하고, 김치 국물을 만들어서 일본식 냉라면에 부어서 막국수 처럼 먹는 방법이라던가.. . 참 많이 해먹고 즐겁게 놀았던 것 같습니다. 그러면서 오큘러스가지고 재밌게 사용하는 법이라던가, 드론으로 지붕 점검 하는 방법도 알려주고.. 이런저런 재미난 일들이 많았던 것 같았네요.. 일본은 日曜大工라고 해서 쉬는날 남자들이 목수일을 할 수 있는 도구를 많이 파는데, 아마도 사람 불러서 고치는게 너무 비싸서 사사로운 수리나 정원 꾸미기 등등은 직접할 수 있게 한 장르가 생겨버린 것 같습니다. 그 때문에 도큐핸즈 같은데만 가봐도 가죽, 나무, 돌, 금속 등등의 재료 및 도구가 여러 층에 걸쳐 세분화 되어 있습니다. 목공 경험이 전무한 사람들도 사게 만들 정도로 잘 되어 있더라구요.. 이번에는 주인 아줌마의 이야기 때문에 이번 코너를 만들게 되었습니다. 예전에 한국인이 들어왔었는데, 일본 쉐어하우스는 룰이 한국에 비해서 조금 빡빡하잖아요.. 예를 들어 냉장고에 자기 이름 써서 꼭 넣어라, 11시 넘어서는 술마시고 큰소리 내지 마라, 밤에는 세탁기 돌리지 마라, 쓰레기는 맞춰서 버려라 등등.. 그런데 이 한국인이 그 룰이 맘에 안들었는지 주변 사람들을 선동해서 룰이 너무 심하니까 자기가 룰을 바꾸겠다고 나섰다네요.. 주변을 선동해서 자기가 룰을 어기고 다녔지만 일본 사람들은 아무리 선동해도 남에게 피해를 주는 것은 스스로 꺼려 하잖아요.. 물론 안그런 사람도 있지만;; 결국 그 한국인은 자기에게 동조하는 사람이 없어서 나갔다고 합니다. 그 얘길 들으니까 좀 와닿는게 있었습니

듣기 버전 :  https://youtu.be/_JtfZzISH5g 역시 한국의 유투브 방송에는 NoSQL이랑 RDBMS랑 비교하면서 초심자 분들에게 NoSQL이 좋아 하는 식으로 방송하는게 많이 보이는데요, 이건 잘못하면 RDBMS는 안써도 되 라는 느낌으로 들립니다. 실제로 그런 사례도 몇 번 일어난 것을 보면 제대로 알려드려야 할 것 같아서 이 주제를 가지고 나왔습니다. 넌 뭐가 잘났는데 하시는 분들을 위해 제 자랑을 또 해드려야지요. 전 하둡으로 4000만 dau가 있는 서비스의 1.76PB 짜리를 설계 구축 해봤습니다. 카우치베이스로 32TB 데이터 올리다가 터뜨려 먹은 적도 있습니다. 몽고디비 운영중에 이건뭐지 하고 리밸런싱 커맨드 날렸다가 락걸려서 8시간 서비스 정지도 시켜봤습니다. 저를 nosql의 n자도 모른다고 하시려는 분들! 사실 전 nosql을 제대로 못써봤습니다! Nosql의 진가는 최소 일간 10억 유니크 엑세스 부터가 아닐까요? Nosql을 처음 봤을 때 그 구조에 대해 경악 했지요. NoSQL이 대단한 것은 데이터 저장 구조가 아닙니다. MySQL도 SQL Server도, ORACLE도 JSON Query를 지원하기 때문에 하나의 필드에 다 때려 넣고 표준 SQL에 JSON Query구문만 추가하면 필드처럼 인식 가능합니다. 비정형 데이터를 RDBMS가 못넣는다는 것은 이미 10년 전 이야기지요.. 많은 영상에서 하드웨어 구조 같은것은 설명을 하나도 못봤는데요.. NoSQL은 만약 100개의 노드에 데이터가 뿌려져 있다고 합시다. 그러면 Namenode에 검색용 쿼리를 날립니다. 그러면 Namenode는 100개의 노드에 동일 쿼리를 던집니다. 그리고 그 중에 해당 쿼리에 데이터가 있으면 그 데이터만 Name node에 가져옵니다. 그걸 머지해서 리턴을 해주지요. 어떤 내용이냐면, 만약 100GB의 하드를 가진 서버 100대에 NoSQL을 설치하고 데이터를 마구 넣었습니다. 동일하게 10TB의 하드디스크 한대에 RDBMS를 설치하고

듣기 버전 :  https://youtu.be/NmyiPYYHlNo?si=L-DDsTkBOWJhzNKR 제가 이전에 메모리 DB라고 얘기 한 것들이 있지요. 좀 알기 쉽게 퉁쳐서 불렀는데요, 이들은 크게 두 가지 종류가 있습니다. in-memory database 라고 하는 rdbms이면서 메모리에 일부 데이터를 저장하거나 완전히 메모리만 사용하여 RDBMS의 disk io병목을 해소하고자 만든 제품이죠.. 크게 Cubrid, Oracle In-Memory Option이나, SAP HANA, Altibase 등등 굉장히 많은 종류가 있습니다. 그리고 memory store라고 부르는 제품들이 있지요. memcached, redis 가 이에 해당합니다. 인메모리 데이터베이스는 데이터베이스의 확장 같은거라 기존 RDBMS와 거의 동일하게 설치하고 표준SQL로 운용을 할 수 있습니다. Cubrid 하니까 생각 나는 에피소드가 있네요. 모 신문사에 도입 된 것인데 클라우드 인프라로 옮기고 싶다는 요청에 분석하고 옮기는 준비를 하던 중이었지요.. 2012년 근처로 기억이 됩니다. Cubrid는 다른 RDBMS와는 달리 브로커 라는게 중간에 있어서 RDBMS의 부하를 분산시키는 부분이 있고 메모리 영역과 디스크 영역을 혼합해서 사용하면서 브로커가 엔진 기동시 메모리에 띄워주고 하는 역할을 하는 것 같았습니다. 구조 자체를 보면 상당히 효율적이네 하고 생각을 했습니다. VM에 올린다는 얘기는 에뮬레이트 된 HW에 OS를 올리고 그 위에 올리게 되다보니, 100%호환이 된다고 장담할 수가 없지요. 그래서 미리 환경을 만들고 cubrid를 설치해서 동일하게 구성했는데, 오히려 VM위의 환경이 더 느리더랍니다. 브로커가 무슨일인지 두세배 늦게 반응을 했지요.. 큐브리드 개발사는 한국회사라서 그 회사에 연락해서 공조를 요청해서 한참을 봤는데, 결국 개발사는 두손을 들었습니다. 자기네가 봐서는 브로커가 이유를 모르겠지만 늦게 반응한다는 것이었습니다. 구조가 아무리 좋아도 기술력이