Talk Lowy(kr)

듣기 버전 :  https://youtu.be/llLC6fZhTw0 1페이지 사업계획서 Lean canvas 부의 추월차선이란 책에서도 회사원인 채는 바보라고 하네요.. 음.. 운 좋게 성공한 사람들의 전형을 보는 서적이라 그걸 비판하는 영상이 있어서 플레이 리스트에 넣어 봤습니다. ^^ 저보다 책 소개를 워낙 잘하시는 분들이 많아서.. 제가 직접 소개하는 것보다 다른 분들의 책 소개 중에 좋은 내용을 즐겨찾기 하는게 더 많을 거 같네요.. 많은 분들이 창업에 대해서 여쭈어 보시네요.. 스타트업을 꿈꾸는 분들에게 도움이 되는 재미난 이야기를 해보겠습니다. 이런 이야기를 많이 들어보셨지요? 비젼이 없어서 회사를 관뒀다거나.. 비젼을 안보여줘서 불안하다거나.. 도대체 비젼은 뭘까요? 事業者が近い将来に達成すべき姿。戦略および方針管理が目指すよりどころ。 사업자가 가까운 미래에 달성할 모습. 전략 미 방침관리가 지향하는 곳. 이라네요.. 스타트업을 만들 때 중요한 포인트가 있다고 합니다. 비젼, 미션, 골 Goal은 Mission을 완수하기 위한 구체적인 목표 Mission은 닿지 못할 높은 이상이지만 그렇다고 안될 것은 없는 것 Vision은 지금은 불가능하지만 우리들이 힘을 합치면 가능한 미래 라고 합니다. 이 세가지가 있어야 내가 향해야 할 곳을 가는 도중에 길을 잃지 않는 등대의 역할을 하고, 참여한 멤버들이 나와 같은 목적을 가지고 달릴 수 있게 한다고 합니다. 여러분이 만약 지금 회사를 때려치우고 나가려고 합니다. 최소한 회사에 다닐 때보다 좋은 무언가를 목표로요.. 이미 그 상황에서 아무리 사소해도 자기의 돈, 시간, 노력의 투자가 필요합니다. 이걸 들여서 성공이란 목표를 정확히 가야만 하고, 나 혼자만의 사업은 한계가 있기 때문에 멤버들이 하나 둘 붙기 시작하지요.. 그럼 더욱더 지출은 들어가고 실패할 수 없게 됩니다. 이를 보다 견고히 해줄 수 있는 등대가 비전, 미션, 골 이란 것이지요.. 그럼 이걸 어떻게 설정해야 할까요? 먼저 Vision으로 내 꿈을

듣기 버전 :  https://youtu.be/GVulJC0-P4E 일본 반도체랑 한국을 비교하는 영상이 요즘 많이 올라오네요.. 참 비교 좋아하는 한국인 많아요.. 그것도 결론은 한국이 우월해야 하구요... 뭐, 자국을 자랑스럽게 생각하는건 언제나 환영이래니까요.. 하지만, 사실무근인 이야기로 무턱대고 좋아하면 좀 그렇지 않나요? 일본 반도체에 대한 잘못된 해석들을 짚고 넘어가볼 까 합니다. 우선 가장 큰 포인트 입니다. 미국은 비메모리 반도체 기술이 뛰어나고, 일본은 메모리 반도체와 비메모리 반도체 기술이 뛰어납니다. 하지만 한국은 메모리 반도체 잖아요? 뭐가 다르냐구요? 메모리 반도체는 단지 정보릏 저장하는 nand저장 회로만 들어 있습니다. 하지만, 비메모리 반도체는 cpu나 gpu처럼 연산용 트랜지스터가 들어있는 것이죠. 구조 자체가 다르기 때문에 한국은 아직도 cpu하나 만들지 못하고 있는 겁니다. 아, 비메모리 반도체도 분야가 있기 때문에 공장용 로봇에 쓰이는 80486 정도까진 만들 수 있다네요.. 그 덕에 쉐어가 있긴 합니다. 3%언더죠. 일본은 왜 반도체 시장을 철수 했다고 생각하시나요? 1987년 미일 반도체 협정의 속내를 제대로 말하는 한국 방송이 없는데요.. 일본이 너무 미국에 많은 것을 수출하면서 고속 성장을 하자 미국이 협박을 한 것입니다. 당연히 협정 내용에는 미국이 전 세계를 적으로 돌릴 만한 내용이 들어있지 않죠. 단지 일본국내에 외국 반도체 쉐어를 20%를 넘겨라 라는 등의 우회적인 내용만 적혀 있었는데요.. 그걸 지키기 위해 옆나라 한국에서 쓰지도 않는 반도체를 들여오는 덕에 한국은 엄청난 수출원이 되었지요.. 불량률이 많은 한국 반도체가 이 덕분에 고속 성장이 되었구요.. 하지만 이 정도로 미국을 제낀 세계 최고의 반도체 기술이 하루아침에 멈출리가 있나요? 반도체랑 자동차 중에 하나만 수출해라.. 라는 비공식 압박이 있었답니다. 일본은 미국을 거스르면 나머지 모든 산업에도 피해가 가겠다 생각 했습니다. 그 때 일본의 자동차

음성 버전 :  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을 걸지 않으면 NoSQL처럼 느려터져 죽습니다.  양이 많은 DB에서 양이 적은 테이블을 가져와서 JOIN을 해야겠지요..  이렇게 해서 동접 10만명까지 커버를 했다 칩시다.  여기서 일반적인 동접의 기준도 서비스마

지식은 전부 퍼주는 타입입니다. 주변에 꽤 많은 사람이 그러더라구요. 그거 다 알려줘서 니 자리 뺏기면 어떡하냐구.. 이 생각은 틀린 얘기라고 봅니다. 세상에 배울게 많고 내가 평생 배워도 다 베울수는 없습니다. 즉, 내가 아무리 가르쳐줘도 배운 사람이 그걸 자기걸로 습득하는 시간 동안 내가 더 배울건 무수히 많기 때문에 나도 같이 발전하면 내가 가르친 사람은 내 지식까지는 수렴하지만, 나를 능가할 수는 없지요. 만약 나를 추월 했다면, 그는 천재라서 내가 뭔짓을 해도 넘어설 수 없거나 노력을 게을리한 내가 잘못한 거죠. 엘런이 102개의 전기차 특허를 공개한 이유가 바로 이겁니다. 두 번째는 내가 정보를 주면 줄 수록 정보를 원하는 지식욕이 있는 사람들이 제 주변에 모입니다. 그럼 나의 네트워크가 좋아지겠지요. 게다가 이런 사람들과 여러가지 기회가 만들어지고, 제 지식을 돈으로 사려는 사람들도 나옵니다. 제로투원의 신디케이트를 만들 수 있는 환경이 자연히 만들어집니다. 아주 작게 생각해 봅시다. 네가 상사이고 후배가 들어왔습니다. 지식도 없으면서 아이디 패스워드 안가르쳐주려고 애쓰는 선배들 봤을 겁니다. 그거라도 있어서 자기 자리를 지키려는 사람들.. 보기 좋아 보이시나요? 그럼 반대로 많은 지식을 주고 기회를 주는 선배가 있어 그 밑에서 많은 경험을 했습니다. 이 선배가 나중에 다른 회사에서 부르면 안가실 건가요? 나는 돈을 준 것도 아닙니다. 단지 나의 지식과 경험의 편린을 주었을 뿐인데 많은 재산이 생겼습니다. 사람이라는 재산이.. 여러분은 스스로 연구해서 터득한 유일 무이한 것도 아닌 그냥 인터넷에서 검색 조금 해서 얻은 지식을 꽁꽁 싸매고 있을 건가요? giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

듣기 버전 :  https://youtu.be/LeLRRRO_aNI?si=SEEErrJwRGdQxyp7 개발자 최후의 보루가 집단 사표 공격 아닌가요? 전 왤케 많이 얻어맞을까요? 난 이거밖에 못해요 하는 사람을 기피합니다. 세상의 발전에 따라 한 사람이 해야 할 것은 늘었는데 세상이 복잡해짐에 따라 업무는 더욱 분화 되었죠. 또 예를 들어봐야죠. 옛날에는 비행기를 조종하는 조종사와 무기를 쏘는 공격수 두 명이 한 조로 움직였습니다. 하지만 요즘에는 혼자서 조종도 하고 무기도 쏘지요..  버스도 옛날에는 운전수와 안내원이 있었지만, 지금은 운전수 혼자 운전하고 돈을 받지요..  반대로,  예전에는 개발자가 모든 프론트와 백엔드 개발을 다 했는데,  요즘은 HTML코더, 퍼블리셔, 프론트엔드 개발자, CSS 코더, 백엔드 개발자, DevOps... 등등 참 많이 나뉘어졌죠.  프론트랑 백엔드는 다른가??? 그냥 하면 되는거 아닌가? 하면서 프론트 손댔다가 바로 버렸네요... 왤케 어려워.. 면접때도 일부러 해보지 않은 영역을 질문하곤 합니다.  Java로 어플리케이션 개발만 했던 사람에게 Java언어 할 줄 아니까 Angular로 마켓 웹 서비스를 한 번 만들라고 하면 얼마나 걸릴거냐? 등등..  그러면 대부분 당황하면서도 자기만의 생각을 이야기 합니다.  여기서 하기 싫어하는 느낌이 드는 순간 그 사람은 바이바이죠..  한 회사에 오래 다니더라도 자주 바뀌는 언어 및 프레임웍 속에서 못하는거 시킨다고 투덜대면 주변 사람들까지 힘이 빠지죠.  그런데 이력서에 두 세개 언어로 이것저것 해봤다고 적히면..  거의 합격이겠죠?  왜냐하면 최소한 이거밖에 못해요 하는 사람은 아니고 또 닥치면 새롭게 배워서 할 사람이니까요.  젊어서는 자기가 잘하는 환경만 찾아다니는 것은 스스로 생각과 시장을 좁히는 길입니다.  특히나 레밍스 같은 한국에서는 이게 최고야 하는 식의 이야기가 만연해 있죠? 얼마전에도 모 유투버가 전직 컨설팅을 해주는 거 같은데 vue를 쓰는 회사에 들어간

듣기 버전 :  https://www.youtube.com/watch?v=gTfLIa7rS5I 일본에서는 데이터 사이언티스트도 꽤나 좋은 직업인데요..  한국에도 있다구요? 제가 NIA였던가요? 한국 국가에서 인터넷 기술을 관장하는 기관의 의뢰로 데이터 사이언티스트의 교육 커리큘럼을 위한 지침을 만들어 드린 적이 있는데요..  한국의 대부분의 데이터 사이언티스트 교육과정은 단순히 데이터의 정제 및 분석 뿐이더라구요..  한국과는 달리 실제로 데이터 사이언티스트는 한 두명의 사람으로 이루어지지 않고 하나의 팀으로 이루어지는 사례가 많다고 합니다.  수학과 통계 스킬의 Analyst 그리고 Hacking skill의 엔지니어. 이는 대규모 데이터의 핸들링 스킬을 가진 사람이라고 해야겠지요. 데이터 사이언티스트의 프로젝트는 상식을 벗어난 데이터량으로 처리하게 되거든요.  그리고 실무 경험 전문가. 각 데이터가 가진 속성의 진정한 의미를 모르면 아무리 뛰어난 분석가라 하더라도 의미를 찾기 어렵지요.  상식적으로 생각해도 저 세가지 스킬을 다 가지고 있는 사람 찾기 어렵지 않을까요 ? 실제로 한국의 데이터 사이언티스트를 찾는 프로젝트를 몇 번 본적이 있는데요..  단순히 데이터 주면 정제해 드리겠습니다.. 로 SI업체가 외주를 받으려고 하는데..  고객은 잘은 모르겠고 여기에 데이터가 있으니 알아서 가져가슈.. 하고..  SI업체는 데이터는 엄청 많이 받았는데 어떻게 정제 해야 하는지 몰라서 버벅이다 망한 사례를 많이 봤지요..  어디가 잘못 된 것일까요?  업무 전문가가 프로젝트 팀에 없고 정작 업무를 제일 잘 아는 고객은 알아서 해주쇼 하고, 엔지니어가 없다보니 데이터 분석가가 데이터 수집도 애먹고 전처리도 애먹다가 시간을 다 써버리고.. 결국 데이터의 의미도 모른채 이것저것 추출해보다가 프로젝트가 무산 되는 경우가 대부분이죠. 즉, 데이터 분석 전문가만 가지고 데이어 사이언티스트라고 하면서 생기는 문제 입니다. 그 동안은 수십기가 바이트의 데이터만 처리해보니 피씨

듣기 버전 :  https://www.youtube.com/watch?v=tDWBO2-syek 비전공자가 개발자가 될 때 주의해야 할 점에 대해 이야기 해보려고 합니다.  혹시 쉽게 개발자가 될 수 있다고 말하는 동영상이 있다면, 이 영상을 보고 다시 한 번 생각해 보시기 바랍니다.  제가 1996년에 처음 제 사수였던 분이 스시집에서 일하던 사람이 개발자가 되고 싶어서 개발을 하게 된 사람이었는데요..  그 분을 보면 전공자보다 훨씬 개발을 깔끔하게 잘 하십니다. 이런걸 보면 전공을 했느냐 안했느냐가 중요한 것 같지 않아요.. 제 생각에는 개발자로서의 센스가 있느냐 없느냐가 가장 중요하지 않을까 합니다. 그 때와는 지금의 상황은 아주 달라졌지만  지금도 명심해야 할 한 가지가 있습니다.  개발자는 배움을 멈추면 죽는다.  끝도 없는 자기 계발을 이어나가지 않으면 안되는게 개발자 입니다.  언어 하나 좀 배우면 개발로 돈좀 벌거 같다고 가볍게 생각하시는 분들은 그냥 다른 적성에 맞는 길을 찾는것을 추천 드립니다.  저도 개발을 하다가 포기한 이유를 말씀 드리자면..  보통 하나의 개발 언어를 배우는데 6개월에서 1년, 게다가 그걸 전문가 처럼 쓰려면 최소 4~5년은 걸리잖아요? 가볍게 명령어 조금 기억했다고 저는 개발자라고 부르지 않거든요.. 그건 코더라고 부르지요.. 개발자는 전문가 중의 하나입니다. 개발 언어를 이용하여 업무처리를 컴퓨터에게 넘기기 위한 작업을 해주는 것이지요. 어떠한 분야에서도 업무를 효율적으로 하는 사람과 그냥 무식하게 하는 사람들이 있잖아요? 개발은 그런게 너무 크게 보입니다. 코드 리뷰 한 번만 해보면 그 사람에게 소질이 있는지가 보이지요.. 전공과는 전혀 상관 없습니다.  저는 처음에 Fortran 77을 배웠습니다. 아시는지요? 만약 들어봤다면 연령이 예상이 될 거 같네요.. ^^;; 그리고 Turbo C++을 했는데.. 갑자기 OOP라는 개념이 나오면서 이를 이용해야 해서 MFC를 써야 하는 환경이 오다가,  어떠한 프로젝트는

듣기 버전 :  https://youtu.be/V0BuoRXMWi8?si=Ve8yPoOe0G4jRkIC 일본에서 컴플라이언스 교육을 받았습니다.  한국에서 받은 컴플라이언스 교육은 너무 오래되서 그다지 기억이 나지 않습니다... 그래도 말씀 드릴 수 있던 것은, 한국에서는 당연한 내용을 이야기 했기 때문에 큰 감흥이 없었는데, 이와는 달리 일본에서는 내용이 충격적이었습니다.  교육에서 쓰였던 예를 들어보겠습니다.  항공기 탑승시에는 휠체어는 위험하니 휠체어에 탄채로 탑승은 금지 였습니다. 이러한 내용은 전 세계의 항공사에서 같은 매뉴얼이라고 합니다. 하지만 사건이 하나 났지요. 아프리카에서 모 항공사를 이용하는 휠체어를 탄 채 들어온 승객에게 승무원이 휠체어를 탄 채로 탑승하면 안된다고만 하고 아무 조치도 취하지 않자 화가난 그 승객은 휠체어에서 내려서 팔로 기어서 탑승하는 장면을 사진을 찍어서 신문에 난 적이 있습니다. 여기는 무엇이 잘못 되었을까요? 한국의 컴플라이언스는 어떤 것을 알려주고 있나요? 일본에서는 컴플라이언스는 단지 성희롱을 막고 룰을 지켜라가 아닌, 매뉴얼 대로 기계적인 대응을 하는게 컴플라이언스를 준수하는 것이 아니라, 내가 어떠한 행동을 하는 것이 도덕적으로 바람직한지를 스스로 판단해야 하는게 가장 중요하디고 합니다. 즉, 매뉴얼에선 휠체어를 탄 채 탑승을 금지했다고 하더라도, 승무원이 나서서 탑승을 도와줄 수도 있지 않을까요? 그건 매뉴얼에 없으니까 안해도 된다고 생각하시나요?  한국에서 컴플라이언스 교육을 받아보신 분 또는 컴플라이언스 교육도 받지 못하신 환경의 분들이든 상관이 없습니다. 여러분은 판단의 기로에 서 있을 때 도덕적 판단을 기준으로 선택 하고 계신가요? 아니면 법에 저촉받지 않는 한도 내에서 자신의 이득을 최우선으로 하나요? 아니면 법을 어떻게 피해갈까를 최우선으로 생각하나요?  법대로해 라던가 그런 법 없어 하면서 자기는 법을 준수한다면서 사람을 해하는 것을 당연시 하시는 분들이 한국엔 참 많죠. 자신의 언행으로 상처를

일본 IT는 블랙이다? 듣기 버전 :  https://youtu.be/1U8i7TnjsTE?si=uhe8cZAVCBVekQda 제가 일본에서 많은 프로젝트를 들어갔잖아요..  그래서 느끼는데.. 다른 유투브 방송들을 보면 이렇다더라 또는 자신의 환경이 전부라고 생각하면서 이야기 하시는 분들도 계십니다.  저 처럼 수십개의 일본 최대의 기업에서부터 홋카이도의 작은 채소파는 아주머니의 DX화까지 해주면서의 경험을 알려드려볼까 합니다.  결론부터 말씀드리지요..  일본의 IT기업 뿐만 아니라 모든 기업은 블랙입니다.  하지만 그 블랙이란 것의 입장의 차이가 분명히 있습니다.  정시 퇴근 안시키면 블랙인가요? 자발적으로 정시 이후까지 남아있다 가는 사람들이라면? 잔업 수당을 본봉에 포함 시켜서 처음부터 계약시 이야기 했기 때문에 월 40시간 잔업은 수당도 안주면 블랙인가요? 그렇다면 처음부터 40시간 포함 시키지 않은 금액을 달라고 하셨어야죠.  많은 IT 프로젝트를 들어가서 봤지만,  다들 일을 빨리 끝내는 사람은 칼퇴근 합니다.  그리고 남아있는 사람들은 스케쥴에 쫓기는 사람들이 많습니다.  PM은 정상적인 범주내에서 스케쥴을 만들고 아래로 내보냅니다.  그러면 아래에서는 그 스케쥴 내에서 사람을 할당하고 진행을 합니다.  만약 PL레벨에서 계산을 못해서 직원들이 잔업을 계속하게 되었다 칩시다.  그럼 바로 IT는 블랙.. 이라는 딱지를 붙이게 되는 것인가요?  하루가 다르게 바뀌어가는 IT는 농사와 비교하면 개인의 능력차이가 너무 큽니다. 빠른 정보를 습득하고 스스로 이해를 하여 L4와 L7과 GSLB를 정확하게 구분할 줄 알아서 Application Gateway를 쓸지 아니면 ELB만으로 충분한지를 알려면 열심히 라는 단어 만으로는 부족합니다.  심지어는 저도 당한 것이 ELB와 ALB가 나뉘어 지지 않았을 때에는 ELB는 4000세션에서 터졌거든요.. 그런데 어느나 보니까 ELB로 15000세션을 버티는 것을 보고 다시 AWS도큐먼트를 찾아보니 4000이하

듣기 버전 :  https://youtu.be/pO94VQuZ1Y8?si=F7BqeuolZImx4ueg ECU가 급발진을 하는 근본적인 원인 분석 여기서 하는 이야기는 순전히 회로기판 설계에 대한 지식이 있는 공학도로서의 개인적인 의견이므로 100%맞는다고 보장하지 않지만, 최대한 근거 있는 이야기를 드리려고 합니다.  제어계측 출신으로서 급발진 사고의 대응이 안된다는 것은 좀 말이 안된다는게 제 생각입니다.  지금도 KDDI 본사 등 RPA 교육도 하기도 하면서 workflow automation쪽도 많이 보고 있는데요..  뭐.. 관계가 없다고 보시는 분들도 계시겠지만, 모든 것은 workflow분석 및 unintended accident에 대한 대처는 기본이지 않나요?  그리고 기사들을 보니까 일반인들을 속이기 딱 좋게 편집이 되어 있는게 느껴지는데요..  외국차도 UA가 있더라.. 요 단어는 뒤에 accident가 아니고 acceleration입니다. .  그러면서 BMW를 보여주는 영상이 있어서 봤는데 마지막으로 점검 한게 사제 정비소에서 ECU펌웨어 업그레이드 했다고 하더군요... 대부분 공식은 실제로 업그레이드지만, 사제 정비소는 ECU튜닝이라고 해서 업그레이드가 아닌 자기네가 손댄 튜닝 룰에 의한 프로그램 조작 입니다. .. 뭐 수치 정도만 조작 했겠지만..  문제는 튜닝은 최신 펌웨어를 쓰는 것보다 기존의 펌웨어에 튜닝된 수치를 넣은 파일을 넣는 경우가 대부분 이기 때문에 급발진 가능성이 있는 코드가 심어져 있을 떄 일거란 말이죠..  게다가 오래된 외제차들의 사고를 자꾸 보여주네요..  신형 외제차들 중에 만약 있다면 한국에 들여오면서 ECU를 손대지 않았나 의심을 해 봐야 합니다. 거의 그 원인일 겁니다.  토요타조차 2005년을 마지막으로 급발진 사고가 없었습니다. (있었는데 감췄을... 지도;;) 아마 자기네 결함을 인지하고 방법을 강구 했겠죠..  그렇게 해서 나온게 ICS입니다.  급발진이든 운전자 미숙이든 연료 공급을 차단하고 브레

읽기 싫으신 분들을 위한 음성 설명 :  https://www.youtube.com/watch?v=fO5OchtEcAs PMO이야기가 몇 군데서 나와서 PMO가 뭘 하는지 소개를 해볼까 합니다. 이건 어디까지나 일본에서의 PMO라서 한국에서 PMO는 무슨일을 하는지에 참고가 될 지는 모르겠습니다. 제 코너를 보면 먼저 이것부터 시작해야죠.. PMO는 무엇인가? 어떤 프로젝트나 하나의 단어의 인식이 잘못 되면 결과물이 달라질 수 있어 엄청난 손실을 가져옵니다. 게다가 프로젝트마다 고객 또는 다수의 단어 해석이 표준과 다른 경우도 있기 때문에 확실하게 짚고 넘어가야 합니다. 때로는 세계 표준을 따르기도 하지만 때로는 고객의 의견을 따르기도 해야 하므로 항상 프로젝트 딕셔너리는 만들고 시작해야 합니다. 이제 본론으로 들어가서.. PMO는 Project Management Office라고 합니다. 프로젝트 관리 사무실! 인거에요! 무슨 직업이 사무실이죠? 첨엔 Officer같은 거인줄 알았다니까요.. 그런데 이렇게 이미 쓰이고 있기 때문에 이게 맞다고 하니 이 용어를 쓰고 있습니다. 제가 모르는 Office의 뜻이 있겠지요.. PMO는 프로젝트 지원 부대를 뜻합니다. 대기업에 새로운 기술을 요하는 프로젝트가 나왔습니다. 일본에서 PM은 무조건 발주사의 담당자가 하고 보통 신규 프로젝트는 정사원 중에 젊은 사람에게 많이 맡깁니다. 젊은 PM은 경험이 충분하지 않지요. 이 때 외주로 PMO를 부릅니다. 그러면 PMO는 1명 또는 20명 등 다양한 규모로 고객을 지원하러 들어갑니다. 이들은 먼저 프로젝트를 이해하고 PM에게 부족한 스킬 또는 경험을 파악합니다. 그리고, PM이 이번 프로젝트를 성공적으로 완수하기 위한 거의 모든 IT를 서포트 합니다. 예를 들어, 외주로 발주할 RFP(Request for Proposal)를 만든 적이 없다고 합시다. 그럼 PMO가 고객사의 입장에서 프로젝트를 분석하고 어떤 IT 업무를 요구해야 하는지를 적은 RFP를 직접 작성해주고 PM에