기본 콘텐츠로 건너뛰기

컨설팅을 위한 지식을 모으는 팁

현대에는 거의 모든 사람이 동일한 조건하에 정보를 손에 얻을 수가 있습니다.

하지만 컨설팅을 나가보면 많은 전문가라 불리는 사람들의 수준이 너무 차이가 많이 나서 고객도 혼란해 하고, 컨설턴트 끼리도 스스로의 애매한 지식을 피력하려 부적절한 방법을 사용하는 경우가 많습니다.

저의 경우는 제가 얻고 있는 지식원을 모두 공개합니다. 주변에서는 그렇게 하다가 그걸 모두 얻은 사람이 고객을 가로채면 어떡하느냐? 라는 근심스런 조언을 주시는 분들도 있습니다.

그럴 때마다 반박하지요.

제가 얻는 지식 역시 누구나 엑세스 가능한 정보이며, 늦냐 빠르냐의 차이이지 언젠가는 도달할 영역입니다. 굳이 이런거 알려주지 않으려 애쓰는 모습을 보면 패스워드를 알려주지 않음으로서 자신의 존재가치를 어필하는 꼰대 상사랑 같다는 생각을 금치 못합니다.

오히려 제 정보원을 공유하고 서로 정보의 넓이를 넓혀갈 수 있는 사람들을 모으는 것이 훨씬 서로에게 이득이 되기 때문에 정리한 정보조차 공유하고 있습니다.

본론으로 들어가서,

제가 가진 정보의 60%정도는 구글 검색에서 얻고 있습니다. 즉, 검색만 잘하면 많은 정보가 들어옵니다.
하지만 왜 서로 다른 정보를 찾을까요?

아마도 찾는 언어가 달라서일 겁니다.
저의 경우는 일본어 > 영어 > 한국어 순으로 검색합니다.
일본어 결과는 경험을 중심을 잘 정리된 블로그가 많기 때문이지요.
논문이나 원리 자체를 알기 위해서는 영문을 검색합니다.
거의 이 정도에서 대부분 필요한 정보가 손에 들어오지만, 간혹 한국어 내용중에 잘 정리한 글도 있기에 검색을 걸어봅니다.
언어 비율은 일본어 : 영어 : 한국어 = 6 : 3.9 : 0.1 정도 일까요?
그 외에도 LDA(Topic modeling)를 역산하여 정확한 구글의 의도를 찾아내는 것도 검색에 들이는 시간을 줄이거나 인간으로서 불가능한 수십 수백만의 구글 결과 문서에서 나에게 필요한 문서만을 추리는 방법론(Ascent Networks의 박대표님 감사합니다!)도 있지만 이건 너무 길어서 나중에 기회가 되면 정리해보겠습니다.
이런 식으로 최대한의 효율로 많은 정보를 정리하는 것 또한 실력이 되겠지요..

그리고 업계지도 라는 일본 서적을 많이 참고 합니다. 수십개의 출판사가 각자 자기의 견해와 자신의 루트로 모은 정보를 기반으로 업계를 분석하고 예측하는 서적입니다.

한국이라면 수백만원을 줘야 얻을 수 있는 정보가 여기는 단돈 만원 정도면 손에 들어옵니다. 심지어는 일본에서 경계하는 기업이 한국에 있다면 아주 자세한 정보가 손에 들어옵니다.

한국에서는 매주 또는 틈만 나면 대형서점의 경제 코너에서 많은 서적이나 잡지를 보면서 나름 추리도 많이 했네요.. 요즘들어 미래를 분석하는 서적이 많이 나오긴 했지만, 정보량에 비해 알짜가 너무 적어서 그냥 훑어만 봅니다.

정보를 찾을 때 가장 중요한 것은
고객의 요구사항을 그대로 듣지 않고 고객이 정말 원하는 질문은 숨겨져 있다는 사실을 기반으로 정보를 찾습니다.

예를 들어,

이번에 오픈하는 블록체인 서비스에 가장 적합한 서비스 구조를 제안해줘.

등의 굉장히 애매한 질문에서,
요즘들어 NVIDIA제품들이 늘고 있는데 우리가 사용하는 머신러닝 코드에 잘 맞을까? 라는 아주 구체적인 질문을 합니다.

이 모두 자기는 HW를 모르니 전문가인 네가 나에게 맞는 HW를 선택하고 왜 그걸 선택해야 하는지를 알기 쉽게 설명해줘!

라는 얘기죠.
그런데, 요즘은 이런게 잘나가요.. 라는 식의 숫자도 근거도 없는 인터넷 기사만 캡쳐해온 컨설턴트와,

당신의 서비스 코드를 보니 opengl로 처리하는 것이 좋은데 opengl을 사용하게 되면 cuda에 효율이 있는 NVIDIA 제품에 비해 같은 코드에서 가성비가 82%가 좋아지는 AMD의 모델을 추천합니다. 전력면에서도 동일 프로세스 당 40% 전력으로 동일 처리가 가능하니 전체적인 코스트는 월 평균 35% 절감됩니다.

라는 설명을 하는 컨설턴트 중에 누구를 선택할까요?

내가 컨설팅을 하는 분야가 만약 온라인 게임이라면 

온라인 게임 서비스의 코딩 방식,
 OS사용 빈도에 따른 코어 특성, 
데이터의 분포 및 예측 데이터의 용량 증가 계획(capacity planning)에서 
클라우드 사용시 및 데이터 센터 직접 계약에 따른 비용 플랜까지, 
더 나아간다면 OS아키텍쳐 및 CPU 아키텍쳐, 
그리고 클라우드 서비스의 hypervisor의 virtualization 방식에 따른 OS의 효율 저하율 뿐만이 아니라 
OS에서 받아들이는 connection수가 일으키는 hypervisor의 물리 NIC의 부하 정도까지 알 수 있다면, 
실패 확률을 극한으로 줄이는 컨설팅이 될 수 있습니다.

이런걸 누가 아냐구요?

모든 내용은 구글 검색에 나와 있고, 
실제 내가 고객에게 컨설팅해 준 내용입니다.

한국에서 컨설턴트의 입지가 좋지 않고 영업실적에 비례한 급여 체계 때문에 이런 기술력 습득보다는 접대로 인한 영업 실적을 최우선으로 하는 컨설턴트가 늘 수 밖에 없다는 환경은 인정합니다. 
때문에 저도 한국에선 컨설팅을 하고 있지 않지요.

한국에서는 컨설팅 하면 솔루션 또는 프로덕트 회사에 소속하면서 기술 영업을 하는 경우가 대부분입니다.

하지만 제대로 된 컨설팅을 하려면 다양한 정보를 이용한 비교로 고객이 정보수집에서 판단까지 소요될 시간을 줄여주고 전문가의 평가로 안심감을 주고 그 시간과 전문성만큼의 비용을 받아야 합니다.

여기서 한국 컨설팅 시장의 문제가 드러나는데요..

우선, 고객이 그렇게 자세히 아는 것 자체를 귀찮아 하기 때문에 알아서 좋은것을 제안해 주세요 라고 요구를 합니다.

두 번째가, 프로덕트 또는 솔루션의 비용 경쟁이 치열하여 컨설팅까지 들어올 여유 이익이 없거나 오히려 마이너스인 경우도 있습니다.

마지막으로, 지적 재산에 대한 가치를 인정 받지 못합니다.

개발자가 또는 개발 회사가 자신들이 만든 프로덕트는 팔고 싶어하면서 개발에 사용된 지적 재산은 어떻게든 돈을 들이려 하지 않습니다.

그렇다고 환경만 탓하면서 접대에만 의존하면서 컨설턴트라는 명함을 자랑스럽게 들이밀기는 좀 그렇지 않을까요?

자꾸 아니꼬운 이야기를 자주 올려서 죄송하지만,
제가 이 글을 올리는 이유는 
적더라도 이 글에 공감하여 세계적인 지식인이 나오기를 바라는 마음에서 입니다.



giip :: Free mixed RPA orchestration tool! https://giipasp.azurewebsites.net/

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  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만명까지 커버를 했다 칩시다.  여기서 일반적인 동접의 기준도 서비스마

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만