기본 콘텐츠로 건너뛰기

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




9:50 기상.. 

9시 50분에 기상해도 되냐구요?
침대에서 10걸음이면 일을 시작할 수 있는 재택이니까요! 
요즘 몸이 안좋아서 자주 깨는 바람에 늦게 일어나네요.. 
몸이 괜찮을 때는 일찍 일어나서 여러가지 일을 하는데요.. 
요즘 어깨가 너무 아파서 1시간 마다 깨기도 하는데 50견이 원래 이렇게 아픈가요?
중간에 진통제를 한 번 더 먹고 어떻게든 잠이 듭니다...

9:55 반쯤 잠긴 눈으로 작업 개시 알람을 slack에 보냄

출근이 없다는게 얼마나 다행인지.. 
이젠 출근하는 현장은 못갈거 같네요.. 
저에게 Slack이 필수인 이유는요.. 일본은 보통 프로젝트마다 고객에게서 이메일 어카운트를 받아서 그걸 기준으로 연락 및 공유등을 하는데요, Slack만 유일하게 여러 이메일로 나뉘어진 워크스페이스를 하나의 앱에서 열 수가 있습니다. 
보통 LINE이나 MS제품군들을 보면 어카운트 스위칭이 아니고 로그 아웃하고 다른 어카운트로 로그인 해야 하잖아요? Slack만이 한 번에 여러 프로젝트를 동시에 채팅하면서 스위칭할 수 있다는게 장점입니다.
한국 처럼 하나의 카톡으로 모든걸 하게 했으면 프로필을 프로젝트마다 지정할 수 없어서 힘들었을거에요..  
게다가 Slack의 큰 장점 중 하나가 workflow를 코딩 가능한 기능입니다. 
Slack을 사용한다는 분들을 보면 외부 API를 연결하는건 대부분 하시리라 봅니다만, 
특정 웹 API에 맞는 폼을 직접 만들어서 그 폼대로 입력하면 API가 던져진다거나, 알람 채널에 알람이 뜨면 그걸 트리거로 해서 다른 작업이나 메시지를 보낼 수 있다거나 하는 기능들을 사용할 수 있습니다. 
이런 워크플로 자동화는 다른 메신저에선 볼 수 없는 기능이지요..

10:00 오전 DBRE팀의 기술 공부 미팅 참가

원래 참가 안해도 되지만, 무슨 헛소리를 하는지 들어야 하므로 참가를 해서 듣고 있습니다. 
농담이구요.. 
전 멤버가 나가면서 회사와 0.2MM계약을 해서 자기의 노우하우를 알려주는 공부 모임인데요.. 
회사가 급격하게 커지면서 신인들이 들어왔는데 기존 멤버들 중에 DB멤버가 한 명인데 나가는 바람에 이렇게 한 거 같습니다. 실력은 둘 째치고 기존 구성을 잘 알기 때문에 공짜로 물어보지 못하는 일본 사회에서는 정당하게 물어보기 위해서 이런 계약을 만들고 있는데요.. 
가끔 비효율적인 방법을 가르쳐주려고 할 때가 있는데, 그걸 나중에 지적하기 위해서 참여해서 그냥 듣고 있습니다. 들어보면 열심히 연구했구나 싶은 느낌이 들 정도이지만 약간 경험적으로 아쉬운 부분이 종종 보이네요.. 그래도 대단하다 싶습니다. 

11:00 아침을 먹으면서 전날 정리

전날 했던 것, 오늘 해야 할 것 등을 정리해 놓지 않으면 까먹다보니 매일 정리를 하고 있지요. 
왜 이시간에 아침 먹냐구요? 리모트이기 때문에 미팅과 미팅 사이에 일하는 척 하면서 밥먹을 수 있잖아요!
게다가 전 하나의 프로젝트에만 참여한 게 아니기 떄문에 참여한 곳들의 진척 상황도 매일 체크하지 않으면 어딘가 하나씩 꼭 빠지더랍니다. 아니.. 이렇게라도 적어놓으니까 한 두개 정도만 잊어먹는걸까요;;; 기억력이 나쁜 저로서는 여러번 체크해도 꼭 뺴먹는게 생긴답니다. 그걸 뭐라하는 사람이랑은 스트레스로 일 못하겠어요. 서로 단점이 있는건데 상대의 장점을 이해하고 단점을 커버해주는 환경이 시너지가 나는 환경인거죠.. 
해결 방법 없이 지적질만 하는건 가스라이팅이라고 하죠. 

그러고 보니 얼마 전 일본인 지인에게 연락이 왔는데요, 
이번에 새로 들어간 프로젝트가 너를 위해서야 하면서 토일 없이 공부를 시키더랍니다. 
그런데 숙제를 내주고 검사를 하는게 스트레스라고 하는데.. 
제가 말했죠. 너를 위해서 라고 말하는 대부분의 사람은 자기를 위해서 상대를 강요하는 경우가 많다구요. 
너를 위해서 라고 말하지 않아도 할 사람은 하고 안할 사람은 안하는 겁니다. 
그걸 억지로 시켜봤자 효율도 안나오고 돌아오는건 욕이죠.. 
뭐, 널 위해서야 하고 억지로 시켜서 좋은 결과도 있겠지만, 
전 하려하지 않는 사람에게 자신의 스타일을 주입시키는 것은 서로에게 도움이 되지 않는다고 생각합니다. 


11:30 아침 조회 참가
일본에선 매일 조례를 하는데가 많습니다. 각 팀 별로 조례를 하는데, 리더가 멤버들의 어제 한 것, 오늘 할 것들을 체크하면서 진척관리를 하기 위해서이지요. 저 역시 제가 했던 것들을 여기서 보고를 합니다. 
그래도 정사원이었다면 분기별 성과 관리나 목표 관리, 인사고과 등등 업무외에 할 게 엄청난데.. 그런걸 듣고 있으면서 난 안해서 다행이라고 늘 생각하게 되네요..
13:00 집중작업 참가
13시부터는 DBRE팀이 전체 미팅을 열고 각자 누군가 봐줬으면 하는 작업을 요청하고 작업을 하게 됩니다. 
보통 일본에서는 서버 작업이나 민감한 작업을 할 때 2인 1조로 작업을 하지요. 작업자와 재감자 라고 불리는 사람이 체크를 해주게 되는데, 작업자는 작업전 작업 매뉴얼과 체크시트를 만듭니다. 그리고 재감자에게 제공해서 재감자가 문제 없다고 판단되면 작업 신청을 하지요. 작업 허가가 내려오면 작업을 하고, 재감자는 매번 커맨드를 날리거나 마우스 클릭할 때마다 체크시트에서 시간을 적고 확인을 합니다. 
14:00 클라우드 센터 전체 미팅 참가(주1회)
매 주 1회 클라우드 센터 멤버들이 모여서 진행상황 공유를 하는데요.. 주관은 CTO가 하고 각 리더들이 발표 하는 방식인데요.. 새로운 멤버들이 들어올 때마다 자기 소개도 하면서 친목을 다집니다. 
CTO도 바이크를 좋아해서 이번에 트랙을 처음으로 타본다고 하고 바이크 모임을 준비하고 있다고 하네요.. 사내에도 은근히 바이크가 취미인 사람들이 많은가 봅니다. 
15:30 파견회사 1on1
저는 갑을병정에서 정 위치로 들어와서 중간 기업은 그냥 토스만 시켜주는데 을이 되는 일본제철 솔루션즈가 파견 멤버들의 멘탈케어를 해주는 듯 해요. 매주 한 번 업무중의 불편한 점이나 말하기 힘든게 없는지 물어보는데.. 여기 현장은 별로 힘든게 없어서 그냥 가볍게 수다만 떨고 끝나네요.. 

17:00 DBRE팀 추가 미팅
각자 자기 업무를 하다가도 시스템을 만져야 할 일이 있으면 다시 호출을 합니다. 
비디오 회의를 켜놓고 작업자의 화면을 공유하고, 재감자는 그 화면을 보면서 체크를 합니다. 
저의 경우도 요청이 오면 참여해서 재감을 하는데요.. 
제 경험상 효율이 떨어지는 것은 수순서를 재조정 해주거나 
자동화 할 수 있는 부분이 있으면 자동화 후에 매뉴얼을 공유해주고 있습니다. 
이렇게 해서 하나씩 효율화를 해나가고 있지요.

19:00 업무 종료 메시지 보냄
19시가 되면 업무 종료 메시지를 Slack으로 보냅니다. 
그럼 하루 일과가 끝나는데요.. 
여기 현장의 특성 때문에 일 주일에 하루는 야간 작업을 하게 되어 있습니다. 
낮에는 매출에 영향이 있어서 야간에 서비스 정지가 필요한 작업을 하고 있는데요.. 
처음에 면담시에 매주 야간 작업이 있는데 괜찮냐는 질문에, 
전 한 달에 한 번은 오케이 지만 매주는 싫다고 딱 잘라 말해서 저는 참여 안합니다. 
고객사 정사원 둘이서 매주 참여 하고 있네요… 왠지 불쌍하지만 그래도 나이가 나이이므로 이젠 철야는 힘들어요 … ㅠㅡㅠ

19:20 저녁식사
종료 연락을 하고 저녁 식사를 합니다. 
매일 이렇게 하면 전혀 움직이지 않게 되니까 저녁을 먹고서는 일부러라도 산책을 나가지요.. 

20:30 바람 쐴 겸 내일 찬거리 사러 나감..
여기가 조금 외곽이라 그런지 웬만한 수퍼나 약국은 9시에서 9시반이면 문을 닫습니다. 
그래서 23시까지 하는 co-op를 산책로에 넣어두는데요.. 
Co-op는 협동조합의 개념의 수퍼라서 회원 가입이 아니라 조합원 가입이구요, 
매년 매출의 일부가 조합원에게 돌아옵니다. 조합원이 너무 많아서 그 금액은 미비한데요.. 
포인트로 들어와서 물건을 살 때 그 포인트를 현금처럼 쓸 수 있습니다. 
제품 가격은 낮은 편은 아니지만, 
산지 co-op회원들의 제품을 직송해서 파는거라 제품은 품질이 좋아서 
꼭 비싸다고 보긴 어려운 좋은 품질이에요.. 
약간 비싸고 그만큼 좋은걸 판다는 주의인거 같네요. 

이렇게 매일 같은 루틴을 반복하고 있습니다. 
매일 10시 전에만 일어나서 의자에 앉으면 되므로 이게 익숙해져버려
이젠 회사에 출근하는 일은 못할 거 같구요.. 
어느정도 경험이 있다보니 
제가 작업하는 것보다는 
타인의 작업을 보고 효율화 시켜주는 것이 주된 업무가 되어 있습니다. 

저의 경우 미팅이 하루에 3에서 5회 정도 있는데
미팅 사이사이에는 쉬기도 하면서 문서 정리나 효율화 작업을 하고 있습니다. 
이게 재택 근무의 장점이지요. 두 시간 이상 비어있으면 잠깐 나갔다 오기도 하구요.. 
고객사 멤버들은 업무 시간 내내 미팅을 하고 
업무 시간이 끝나고 작업하는거 같더라구요.. 
그래서 작업들은 제가 많이 도와주면서 효율화를 시켜주고 있습니다. 
자주 느끼지만 제가 갔던 현장의 일본인 엔드유저 정사원들은 
언제나 미팅에 쫒겨서 업무를 늦게까지 하는 경우가 많은데 
불만 없이 잘 하는 거 같더라구요.. 

제가 참여했던 현장 중에 한국인 현장에서는 
미팅은 똑같이 많은데, 
불만이 많고 효율이 안나는 경우가 많았는데.. 
의식의 차이인 거 같습니다. 

물론 한국에서 잔업은 상사가 시키는 형식이라서 가스라이팅같은 경우가 많지만, 
일본의 경우는 일이 많으면 공론화 해서 재스케쥴 걸면 배를 쨀 수가 있지요. 
그렇게 해서 느긋하게 하는 분위기냐
아니면 자신이 좀더 노력해서 어떻게든 떙기느냐의 차이 같습니다. 

한국에 있었을 때는 D Day를 위에서 정해버려서 
어떻게든 맞추어야 하고, 
그러니 야근하고 밤샘하고.. 
끝나면 다음게 이미 D Day가 잡혀 있고.. 
를 반복했던 거 같네요..

뭐, 지금도 그러겠나요?
워낙 워라벨 외치는 한국이 되었는데.. 
이젠 많이 좋아졌겠죠?

이렇게 설렁설렁 일하고 고객사에서 받는 금액은 이번 프로젝트는 월 99만엔이구요.. 
동업으로 만든 회사의 수입으로 잡고 저는 거기서 급여를 받고 있지요.. 
급여는 매출보단 적게 설정 되어 있지만, 
주택지원 차량지원, 핸드폰지원 등 많은 지출을 회사 비용으로 쓰고 있다보니 
다른 분들의 같은 급여보다 여유가 있지요. 
제 다른 동업자 분은 온라인 서비스를 만들어 키우려고 열심히 하고 계시는데
거기가 대박나면 저도 콩고물이 떨어지는 구조랍니다. 

IT 스페셜리스트 스럽기 보다는
말 그대로 컨설팅 업무라고 불릴 법한 누군가의 IT업무를 
내가 가진 경험과 지식으로 더 좋은 방향을 컨설팅 해주고 있는 것이지요. 

많은 분들이 개발자로 들어가서 개발일을 하시다보니 
이런 식의 업무를 경험해보지 못하신 것 같아서 
저의 하루를 정리해 봤습니다. 

저는 이게 좋은게, 
개발할 때는 뭔가 정해져 있는 분량을 처리하지 않으면 안되는게 부담이 컸는데요.. 
지금은 설렁설렁 놀면서 상황을 보다가 
개고생하는 모습을 보면 그걸 효율화 시켜주면서 단발성 일을 도와주는 것이 메인이라 그런지
남은 분량에 쫓기지 않아도 되어서 제게는 이게 맞네요. 
뭔가 남아있는게 싫다보니 갑자기 두세개 일이 들어오면 바로 처리해줘 버렸다가 
며칠동안 할일이 없어서 난감할 떄가 있어서 
요즘은 미리 처리하고 나서 하루나 이틀에 하나씩 공개를 해주고 있습니다. 
어짜피 제가 공유해주면 담당자의 업무가 1주일 분을 한 순간에 처리한다거나 하는게 되다보니
하루나 이틀에 하나씩 해결해주어도 앞으로 계속 효율화 된 작업이 가능하므로 
무한 감사를 받고 있어 좋네요.. 

이런 프로젝트 파견 일도 하고 있지만, 
또다른 제 일을 설명 드리자면

일본에서 비즈니스화 시키고 싶은게 있는 분들에게서 연락이 오면
제가 가진 네트워크 연결 또는 투자자 소개, 일본 시장 준비나 인프라 제공 등을
도와드리고 있습니다. 혹시 필요하신 분이 계시면 언제든 연락 주세요~
수익구조는 저를 통해 인프라를 제공해주면서 인프라 효율화로 
경쟁력을 갖추게 해주고, 서비스 전개로 수익이 발생할 때 나눠갖는 구조로 도와주고 있지요. 

제 영상을 보시면 아시겠지만, 
아이디어의 구체화 단계에서 투자받기 쉽게 비즈니스를 정형화 하는 법을 알려드리고, 
투자자의 소개나 네트워크의 확장을 도와드리고 있습니다. 
그리고 일본에서 일어난 법률, 세금 관련 도움도 드리구요.. 
일본 오피스를 만들 필요가 있을 때 오피스 설립도 도와드리고 있네요… 
그냥 올인원으로 비즈니스가 안착할 때까지 필요한 거의 모든 잡일을 도와드린다고 보시면 되요..

갑자기 제 광고를 하게 되었지만, 
일본에서 IT 관련으로 일을 하고 싶어하시는 분들 중에
이런 삶을 사는 사람도 있구나 하는 참고가 되시길 바랍니다.

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