기본 콘텐츠로 건너뛰기

능력있는 당신을 회사에서 가만두지 않는다면 그건 좋은회사일까요?




오늘도 휴일이네요.. 어제가 추분이었나봐요.. 
지난 주에 4일 휴가를 냈으면 앞뒤 3일씩 10일 쉬는 실버위크였지요. 

그 때문에 고객사의 신입 여직원이 지난 주 내내 쉬어서 
그 여직원의 업무를 제가 좀 했습니다. 
다음주엔 남자 직원이 쉬기 때문에 
남자 직원의 일을 도와야 하지요.. 

사실 파견이라고 해도 쉬고 싶으면 쉬면 되는데, 
남들 쉴 때 일해줘야 신뢰도도 올라가고 
일도 널럴 해서 좋잖아요? ^^;;

그건 그렇고.. 
어느 한국인이 SNS에 올린 글을 보다가 생각이 났는데요.. 

한국의 일반적인 기업이라면 
성과급이나 인사고과에 대한 이야기를 많이 들었을 겁니다.

매 분기마다 목표치를 설정하고, 
그 목표를 분기가 끝날 때마다 평가를 하지요.. 
그리고 그 평가에 따라 인센티브가 달라지는 곳들도 있구요, 
기대에 못미치면 좌천 당하기도 하지요..
사람들은 이런 목표 설정과 그 목표를 향해 달리는 것 모두 
많은 스트레스를 느끼고 있는 것 같습니다. 
아마 회사는 개인들의 발전을 위해 라는 정당성으로 
강요를 하고 있는 것이겠지요.. 
저도 정사원일 때 뭘 적어야 할지 고민이었고 스트레스 였거든요.. 
이걸로 나중에 성과에 안넣어도 좋으니 안했으면 하구요.. 

목표에 대한 내용에 대해서 저의 기억을 더듬어 가 보면.. 
연간 회사 목표가 있고 그 목표를 위한 업무에 대한 내용도 있고, 
업무 효율화나 자기 계발 관련 이야기도 적을 수 있던데도 있던 것 같습니다. 

회사는 고능력자의 능력을 어떻게 끌어낼지를 고민하거나
개개인들이 열심히 일해서 성과를 많이 내기를 바라는게 일반적이지요. 
그렇기 때문에 가장 중요한 것이 
개별 목표가 중요하고, 그에 맞는 기대 성과가 중요하고, 
그 결과가 최종적으로 인사고과에 반영이 됩니다. 
고능력자를 놀리면 아깝잖아요?

그런데 일본에서 느낀건 전혀 상반 되네요. 
일본에서 중요한 것은 시스템 입니다. 
정해진 시스템을 얼마나 잘 따르느냐가 
개인의 성과이므로 회사는 
개인이 회사를 위해 특별한 노력을 하기를 바라지 않습니다. 
개인은 정해진 시스템에 100% 따랐다면 성과가 100%가 되는 것이지요. 

그리고 그 시스템은 평균적인 사람의 능력에 따르기 때문에
대부분의 개인들은 시스템을 따르기만 해도 시간에 여유가 생기기 마련이지요
남는 시간을 자신을 위해 쓰든 회사의 발전을 위해 쓰든 
그건 회사로서는 상관이 없는 것입니다.
 
저는 그 시스템을 만드는 쪽으로 기업에게 의뢰를 받아 참여하는 편인데요.. 
이러한 시스템을 얼마나 효율적으로 만들 수 있고, 
모든 멤버들이 그 시스템을 무리 없이 따를 수 있게 쉽게 만들었는지가 중요합니다. 

그리고 그 시스템으로 인해 멤버들의 효율이 향상 되었다면 기업은 좋아합니다.  
멤버 한 두명의 특출난 능력이 회사를 좌우하게 되면, 
그 멤버의 이탈로 회사의 타격이 너무 크거든요.. 
그리고 보통 멤버는 그 시스템에 얼마나 잘 따르느냐만 생각하면 되지요. 
즉, 시스템으로 인해 얼마나 효율이 올라갔느냐가 회사에서 가장 중요한 지표인 것이죠. 

한국에서는 개인의 역량을 회사가 최대한 활용하고 싶어하는 경우가 많습니다. 
하지만 이건
혁신가 2%에게 요구해야 하는 것이지 
평범한 98%에게 요구하는 것은 단지 기업의 또는 리더의 욕심이라고 생각합니다. 

스티브 잡스를 유일하게 고용했던 게임기로 유명한 ATARI의 
Nolan J. Bushnel 씨 역시 잡스는 혁신가인 2%였다고 인정했기 때문에 자유를 최대한 주었고, 
그의 역량으로 회사의 이익을 최대한 뽑아내려 했지만, 
나머지 평범한 98%에게는 회사라는 시스템을 유지하는데 필요한 노력만으로도 
충분하다고 생각한 것이거든요. 

스타트업 같이 몇 명 안되는 회사에서는 
모두의 역량이 회사의 역량에 직결되므로 
이 이야기는 해당사항이 없지만, 
회사가 커지면 커질 수록 전 사원에게 
최대한의 역량을 끌어내려 하는 움직임은 
오히려 거부감이 커질 겁니다. 
그리고 그게 바로 회사의 리스크로 이어지는 것이지요.

예전 회사 기억을 떠올리면.. 
회사의 매출 향상을 위해 전 사원에게 아이디어를 하나씩 쓰게 하는 경우가 종종 있었죠…
애사심을 위해 회사에선 귀찮게 이런저런 행사를 하고 강제 참가를 요구합니다. 
사원들에게 애사심이나 무언가의 발전의 계기를 주는 것은 좋지만, 
이런 식으로는 좋지 않다고 봅니다. 
대부분의 사원들은 그냥 회사에서 시키는 일만 하고 
그 만큼의 급여를 받는 것으로 만족하는 사람들이 더 많거든요. 

차라리 회사를 위해 제안하고 싶은 사람들에게만 자유를 주고 막지 않는다면, 
제안을 하고 싶어하는 사람은 마구 제안을 하고, 
제안하기 싫어하는 사람은 안심하고 시스템에 만족해서 살게 될 것입니다. 

혹시 여러분의 회사에선 어떤가요?
회사가 요구하는 일에 만족하고 있다면 그 회사는 당신에게 딱 맞는 곳입니다. 
하기 싫은 일을 이것저것 시킨다면 당신은 그 회사에 있으면 안되는 것이지요. 
이게 회사가 잘못했다고 말할 수는 없습니다. 

저 역시 사원이 들어오면 전부 시키거든요.. 
일단 경험해보고 하기 싫다면 다시 안시키지만, 
해보지도 않고 싫다는 사람은 전 싫어합니다. 
왠지 모순되어 보이지 않나요?

여기서 가장 중요한 다른 요소가 있지요..
회사의 룰 화를 시켜서 억지로 시키는 것이냐, 
아니면 경험해보고 스스로 판단할 기회를 주느냐 
인 것입니다. 

토요타는 연간 1000만대의 자동차를 팔고 있고, 
35만명의 내부 및 관계 인력이 아침마다 정보를 교류하여 
회사를 이끌어내고 있습니다. 

이 만한 규모의 시스템이 갖춰지지 않았다면
이렇게까지 성장할 수가 없었겠지요. 

현대 자동차는 420만대의 자동차를 팔고 있고, 
그 만큼의 규모를 유지할 수 있는 시스템을 가지고 있습니다. 
https://www.hyundai.com/worldwide/en/newsroom/detail/hyundai-motor-announces-2023-q4-business-results-0000000405

왜 같은 자동차 회사임에도 판매량이 다를까요? 
디자이너 문제인가요? 엔진 성능 문제 일까요? 
기업 조직이란 것은 그렇게 단순한 지표만으로 결정되지 않습니다. 

좋은 디자이너가 활약할 수 있는 시스템
좋은 엔지니어가 연구할 수 있는 시스템
그리고 모든 멤버들이 효율적으로 제품화 하고 판매할 수 있는 시스템을 
얼마나 잘 만들었느냐의 차이라고 저는 생각합니다. 

토요타 경영 연구소라는 별개의 연구소는 
토요타 자동차와는 상관 없는 
조직과 경제를 연구합니다. 

거기서 Lean Startup/Lean Canvas라는 
비즈니스를 시작하는 방법론도 나왔구요.. 
자동차랑 전혀 상관이 없지만, 
이런 연구가 기업의 효율화에 큰 기여를 하고 있다는게 사실이죠.

만약 여러분이 아이디어가 있다고 칩시다. 
그리고 언젠가는 독립해서 회사를 하나 만들려고 하는 사람이라면
반드시 생각해야 합니다. 

거의 모든 멤버는 자기만큼 애사심은 없다구요..
물론 운이 좋아 한 두명은 엄청난 애사심을 가지고
엄청나게 노력하는 사람이 있을 수 있습니다. 
그 사람에게는 그 만큼의 보상을 주어야 하겠지요. 
그리고 그 외의 사람에게는 시스템을 주고, 
시스템에 걸맞는 보상을 주어야 합니다. 

작은 기업일 때부터 이렇게 체계를 잘 잡아나간다면
회사가 커지는 시점에서 진통이 덜해지겠지요.. 

제가 99년 넥슨에 있었을 때 
6개월만에 잘렸습니다. 
이유는 넥슨의 그 때의 기업철학에 있었는데요.. 
지금은 어떤지 모르겠지만, 
40명일 때 사람을 50명을 증원 했습니다. 
그리고 3개월 보고 감축을 시작하죠.
그리고 다시 60명만 남깁니다. 
이렇게 하면 기존 멤버중에서도 불필요한 사람을 제거하고
좋은 사람들만 남길 수 있지요.. 
이렇게 80, 120명 단위로 한 번씩 물갈이를 한다고 들었습니다. 

물론 이젠 수천명을 거느린 회사이기 때문에
전혀 시스템은 다르겠지만, 
90년대의 중소기업은 인턴제를 쓸 여력이 없기 때문에
이런 방법을 취하는 곳들이 있었지요.. 

전 왜 잘렸냐구요?
당연히 능력 부족 아녔을까요?
시키는 일은 안하고 맨날
게임소스나 남의 소스 까보고 분석만 했으니.. 
는 농담이구요.. 

사실, 저를 지인 소개로 뽑아주셨는데, 
공교롭게도 뽑아놓고 보니까 넣을 자리가 없더라…
라는 것이었지요.. 

저를 뽑아주셨던 분도
뽑아놓고 잘라서 미안하다고 했지만, 
제가 스스로 자리를 만들 정도의 능력이 없었기 때문이지 않았을까요?

그 뒤에 죽어라 노력해서 
최소한 필요없어 잘리는 사람은 되지 말자고 생각했구요.. 
개발, 시스템, 디자인, 마케팅까지 전방위로 공부를 했습니다.
그 때 잘리지 않았다면
지금의 저는 없었을거라 생각합니다. 

슬슬 결론을 이야기 해야지요.. 

일을 잘하는데도 놀고있는 당신을 회사는 어떻게든 더 굴리려 한다면
그 회사는 좋은 시스템을 가지고 있는 회사가 아니란 이야기 입니다. 
회사는 시스템으로 사람들에게 업무를 분장하고
사람들은 자기의 능력껏 그 업무를 소화하고 
빨리 소화한 사람은 그 만큼 놀든 자기계발을 하든 자유인 것이지요. 

이제 여러분은 잘 생각해보세요. 
회사가 당신을 못써서 안달이거나
가스라이팅을 하고 있지 않은지요?

다른 사람들은 시간이 없어 죽어나는데
당신만 시간이 남는건
당신의 잘못이 아니라
회사의 시스템이 잘못되었거나 당신이 뛰어난 것일 뿐입니다. 

혼자만 놀고 있다고
스스로 잘못하고 있는지 눈치보이고
위축되지 않았으면 합니다. 


giip :: Control all Robots and Devices! Free inter-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 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만