(1/22 업데이트) 사내정치....관심끄고 하라는대로 하는게 맞을까요?

속상하셨겠어요. 힘내세요.

만약 회사랑 인연이 짧아서 불리한 입장이라고 생각되신다면 주변에 경험많은 조언받을수 있는사람을 찾아보는게 어떨까요? Manager 나 mentor 같은분이 좀 주장을 받아주면 원하는 결과까지는 아니라도 나중에 credit 은 좀더 받으실수 있지 않을까 싶네요.

감사합니다

credit을 원하는게 아니라서 그냥 하고싶은대로 하라고했습니다

말단이라서가 아니라 아무래도 포지션의 특성상 제 목소리를 내기 어렵겠죠. 그런걸 매니저가 잘 해줘야 하는데... 

그렇게 회사에 자기 목소리를 낼 수 있는 권력(?) 을 얻는게 회사에 유용한 인물이 되는 첫걸음이라고 생각합니다. 화나는게 당연한 일이고요, 먼저 팀 매니저랑 잘 이야기해서 구워삶으세요  이번 일이 잘 안되더라도 다음번 기회가 있을 수 있고요, 우선 팀 내에서 active 하게 활동하는 모습을 보여주는게 중요할 듯 합니다.

감사합니다

매니저도 자기 매니저랑 같이 일하는 사람이다보니 아무말도 안하더군요

주어진 일이나 열심히 해야겠습니다

이럴때는 최대한 감정적인 부분과 추측을 앖애시는걸 권장드려요. "인도인들"이라고 언급하신 부분에서 벌써 선입견이 있으신 것 같구요, 팀분들이 하신 말씀(정치인 것 같다)도 추측이신 것 같구요. 어떤 다른 팀이 containerization을 맡았다면, 정치가 아니고 maintenance와 duplication of work은 당연히 concern입니다 - credit의 문제가 아니죠 해당 팀에서 잘 설명을 하지 않고 커뮤니케이션을 잘 못한 느낌이 있지만, 엔지니어간에 흔한 일이지 싶습니다. 커뮤니케이션 문제는 매니저를 통해서 그쪽 매니저랑 풀어줄 수 있으면 윈윈이겠죠. Containerization을 하는 팀 사람이랑 챗을 해보는 것도 방법일 것 같습니다. 화를 가라앉히시고 잘 풀 수 있으시길 바래요.

이글 적은 이후로 팀원들이랑 이거에 대해서 말하지 않았는데

다른 팀원들도 인도인들에게 인종차별 당한거 같다고 하더군요

저만 그렇게 느낀게 아니더군요

저는 new feature를 작성중이고 new feature를 container에 넣어서 release하면 duplication of work가 아니라 추후에 해야할일을 미리 개발단계에서 해주는거기때문에

오히려 효과적인거 아닐까요?

차별이 아니라는 말씀이 아니라 감정적으로 하는게 도움이 안될 것 같아 드린 말씀입니다.^^ 팀원분들이 생각하시는 것과 다른 팀 분들의 의도는 다를 수도 같을 수도 있지만, 어느경우라도 감정적인 느낌 외에는 해결되는게 없기에 드린 말씀입니다. HR에 가셔도 (말씀하신 내용을 바탕으로한 개인덕인 생각에는) 적극적인 대응을 할 뭔가 있는 상황도 아닌 것 같구요.

그리고, 어떤 공통적인 프로세스와 툴들을 만드는 입장이라면, 같은 작업을 하는 다른 코드는 이중작업일 가능성이 높죠. 왜냐하면, 그 다른 코드를 읽어서 어떻게 어답테이션해야할지 봐야하고, 확장성없게 짜 놨거나 리콰이어먼트가 다르면 인티그레이션할때 골치 아플꺼고, 어답테이션을 순탄히했더라도 메인터넌스 입장에서 다른 사람이 짠 코드 버그를 처리하는걸 좋아하는 사람은 많지 않죠. 차라리 다시 짜는게 나을 경우에는 아예 일을 두번(플러스 조사하느라 알파)하게되는거죠. 개인적으로 (양똑 입장에서) 아주 흔하게 겪어본 상황입니다.

글쓴분 잘 생각해보세요 현재 계시는 회사에서 본인 어필할 수 있는 정말 좋은 기회예요.

사내정치가 없는 회사는 없고, 현재 상태에서 안주하시는게 괜찮다면 그냥 하라는대로 넘어가는것도 나쁘지 않지만

제가 보기엔 한단계 올라가기에 정말 좋은 기회같아요.

포지션이 받쳐주지 않는다면 조금 힘들기도 하지만..원래 포지션은 받고 나서 행동하는게 아니라 그 포지션처럼 행동하면 받게되는 경향이 더 크거든요.

본인이 생각하시는게 잘못된 방향이 아닌이상 매니저랑 잘 얘기해서 drive 하시는걸 저는 개인적으로 추천해요. 스트레스 좀 받더라도 좋은 기회예요.

감사합니다

일단 이번에는 제가 멘토처럼 따르는 팀원이 그냥 넘기라고해서

그냥 기존방식대로 하기로한상태입니다...

정치 이외에 굳이 생각해보자면 아키텍쳐팀에서 일을 벌리기 싫어서 그런거 아닐까요? 기존에 사용하던 containerization 방식이 있으면 그걸 기반으로 logging이나 monitoring이나 optimization이나 test나 deployment같은 모든 work flow가 다 짜져있었는데 그 이외의 방식을 가져오면 골치아파져서? 물론 gradle integration을 해놓으셨다고 하지만 그걸 유지보수 하는건 저쪽 일이니까... 예를들어 서비스가 터져서 온콜 불려갔는데 익숙한 vm이 아니라 잘 모르는 도커라 예상치 못한곳에서 머리 싸매는 일은 보고싶지 않은거 아닐까요? 저도 도커 좋아하지만 아키텍쳐 팀이 반대하면 저쪽이 하자는대로 할거같습니다. 실제로 서비스 굴리는건 저쪽 일이니까.

이미 로드맵에 일이벌어져있는 상태입니다

누군가는 해야하는일이고 제가 새로운 feature을 로드맵에 맞게끔 작성한다고해도 반대하는거였습니다

그리고 커스터머 콜이랑 모든 메인터넌스를 저희 팀에서 담당하고 그부분 맡은사람들은 다 동의하였습니다

자세한 기술적인 내용까지 써주셔서 감사합니다. 아직 경력이 짧은 주니어이신가요? 보통 이 때는 확고한(?) 나만의 생각이 있어서 이런 문제에 대해 불필요하게 감정적으로 접근할 때가 있습니다. 직급이 아직 주니어인 상태에서 다른 팀의 방향을 바꾸는 것은 아주 어렵습니다. 이걸 사내 정치로 치부하실 필요는 없습니다. 지금은 그냥 그쪽 팀에서 하라는데로 하고, 먼저 승진을 하시고, 팀 내에서 먼저 자신의 목소를 키우고 팀의 매니저/높은 IC들의 동의를 얻을 수 있다면, 그 때가서 타 팀의 방향을 바꿀 수 있겠죠. 아직은 아니라고 생각해요. 자신의 목소리를 내지 말라는 소리가 아닙니다. 효과적으로 낼 줄 알아야 합니다.

저한테도 너무 도움이 되는 말이네요. 감사합니다. 주니어로 일하면서 이리 치이고 저리 치이면서 회사에서 일하는 법을 배우는 중인 거 같습니다. 왜 이런 시스템으로 되어있는지를 이해하게 되는 것 같아요.

감사합니다

첫직장 가진이 1년정도되는 주니어입니다

조언 감사드립니다

회사에 이런 경우가 있습니다. 저희쪽에서 만든 회로에 문제가 있었는데, 일단 회피하는 방법을 찾았습니다. 회피하는 방식을 SW와 공유해서 그쪽에서는 이미 SW code로 구현이 되어 있는 상태고, 이후에 HW revision을 하면서 고칠 기회가 있었습니다. 그러면 그걸 고치는게 맞을까요? 안 고치는게 맞을까요?

많은 경우에, 안 고치고, 그냥 문제를 내버려 둡니다. 왜냐하면, 그걸 고치면 SW code에서 회피 로직을 다시 들어내야 하고, 그 와중에 어떤 부분은 회피 로직이 들어가고, 어떤 부분은 회피 로직이 빠지고, 나중에 혼란만 가중 되기도 합니다. 이게 몇명 일하는 과제면 상관없는데, 수백명 일하는 과제면, 어떤 결정을 한번 내리고 전파하는데 들어가는 에너지가 너무 과해서, 일단 결정되면, 그냥 갑니다. 이럴때, 호환성을 결여시키는 약간의 개선은 보통 무시되는게 일반적입니다. 왜냐하면 그 개선때문에 발생하는 혼돈과, 검증 단의 노력이 너무 커져서, 오히려 안 하니만 못하다는 거죠. 이런건 정치와 관련 없습니다.

저도 그부분은 동의합니다

지금까지 엄청 많은 코드들이 짜져있고 (10년정도된 프로젝트입니다) 문제있는 부분들도 많습니다 그걸 duct tape로 수리해오고있었습니다

로드맵에 그걸 다 고치자는 로드맵이 있었고 그걸하는 과정에서 containerization을 하자고 했고

제가 new feature에 container를 쓰겠다니 반대하더군요

본인을 위해서나 회사를 위해서나 architecture team 에 그 정도 토론 후 결론이 안 났다면 협조하는게 맞습니다. 일단 이름부터가 architecture team 이면 그런 걸 결정하는데 더 많은 권한이 부여되어 있을 텐데요. Docker 를 쓰던 VM 을 쓰던 Bare Machine 을 쓰던 not the end of the world 입니다. 그런데 사내 팀끼리 사이 안 좋아지면 다 죽는거죠 :)

아마 설명이 조금 부족했던거 같습니다

기업용 소프트웨어를 만드는 팀이고 소프트웨어 배포할때 VM을 만들어서 고객들이 자기 서버에 restore해서 쓸수있도록 배포하고있습니다

원래 VM 에 Centos를 설치해서 systemctl로 코드를 (서비스) 실행했었는데

VM이랑 Centos는 그대로 있으면서 systemctl로 돌아가는 서비스를 docker로 변경하기만 하는거였습니다

그리고 이미 로드맵에 그렇게 하자고 되어있고요

그래서 협조하기로했습니다

Docker 가 뭔가 해서 찾아보고 공부 좀 했네요. 역시 마모는 보면서 공부를 하게끔 만드는.... ㅋㅋㅋ

이거 원 나이를 먹으면서 쳐지고 늙다리가 된다는게 이런건지. 예전에는  그냥 들으면 뭔지 착! 이였는데.

어쨌든!

제 생각에는 이거 사내정치 아닌거 같은데요.

아키텍쳐 팀에서 자기네 해야 하는일 하는 것 같습니다.

딥러닝 주장이 일리가 있으며 저도 동의 합니다. docker로  containerzation을 하는게 롱텀으로 보면 맞다고 생각 합니다.

그런데, 다른 한편으로 아키텍쳐팀에서 주장하는 것도 일리가 있다 생각 합니다.

이건 아마도 보는  입장의 차이에서 오는 부분 이라 생각 합니다.

소프트웨어 엔지니어의 경우에는 본인의 써비스에서 이게 어떻게 implement가 가능하고  어떤식으로 작동을 할테니, 현재 회사의 시스템에 이런식으로 끼워 넣으면 되겠다 라는 bottom to top approach를  하게 됩니다. (틀린거 아닙니다)

그런데, 아키텍쳐의 입장에서는 기존의 아키텍쳐와 새로 나오는 emerging 아키텍쳐를 집어 넣었을때에 시스템 전체의 영향이라던가, maintenance network load,  그에 따른  infrastructure 의 확장등  top to bottom approach를 하게 됩니다. 나아가 회사 business의 방향과 architecture 가 잘 맞아 떨어 지는지 등의

뭔가 다른걸 고려할 입장이 있습니다. 

business 의 가장 큰 목표는  sustainability입니다. 그래서 architecure가 필요 한거구요.

아마도 architecture의 입장에서는  아직은 docker가  현 아키텍쳐에 시기상조 라고 생각 하는 것 같습니다.

그리고 poc가  local level (딥러닝님 팀)에서는 이루어지긴 했지만, 회사 전반의 아키텍쳐레벨에서 poc가  이루어진거 같지 않습니다.

즉, 딥러닝님의 팀 생각 만큼 회사가 못따라 가는거고, 이는 시간이 걸릴겁니다. 회사에서는 이런 일이 비일 비재 합니다.

그러니 천천히 생각 하시면 될 것 같습니다.

회사에서는 이럴경우에는  아키텍쳐가 원하는 방향대로 VM으로 다시 개발해서 release 먼저 하고

아키텍쳐팀의 containerzation poc 로  현재 개발해논  poc를 version 2로 해서 같이 하자 라고 제안 하는 방법이 있습니다.

이런경우, 버젼2가 버젼 1 보다 먼저 나오는 거죠. ㅋㅋㅋ

음.. 그나저나, 오늘 회사 가서 우리팀한테 우리는 왜 docker 같은거 안하니?  라고 지롤 해봐야 겠습니다. ㅎㅎㅎ

architecture team에서 1년내로 지금 프로젝트의 모든 코드를 containerization시키겠다는 로드맵을 들고나왔고

회사내에 공식적으로 발표가 되었습니다

이때까지 저희팀에서 새로운 소프트웨어를 사용할떄 (Spring, Docker, Postgress, ElasticSearch 등등) architecture팀은 이때까지 관심하나도 없었는데

지금와서 이러고 있습니다

일이일어나고 저희팀에서 architecture team에서 spring 버젼업을 할려고하는데 너네 동의 받아야하냐고 하니까 당연하다고 답변왔습니다

아마 저희가 무슨버젼을 쓰고있는지 모를겁니다

제가 볼땐  아키텍쳐팀 의견이나 딥러닝님 의견이나 시스템이 돌아가는데 있어서 획기적인 차이를 두지 않을겁니다.

딥러닝님 쪽 의견이 더 이쁜 구조를 갖을 수 있겠지만 아키텍쳐쪽에서는 안정화된 부분을 들쑤신다고 생각할 수 있습니다.

그리고 그쪽에서 딥러닝님에게 크레딧을 주고 싶지 않아서 그렇다고 한다면.. 참 건강한 회사네요 서로 일 많이 하겠다고 싸우니 ㅎㅎ

그정도 정치는 좋다고 생각합니다.

저는 다른 형태로 어필하는것보다 docker가 얼마나 트랜디한지 전파하는게 좋다고 봅니다. 엔지니어도 인간인지라 마음이 움직여야 결정이 움직이거든요. 마음이 움직이지 않으면 단점 찾아내려면 얼마든지 단점 찾아서 그걸 핑계로 자기 주장 펼칩니다.

그러게요...저는 파이썬 모듈로 작성하면 테스트할것도 줄어들고 엄청 간단합니다

그에비해 micro-service작성하게되면 API작성부터 데이터 관리  까지 모두 제가 다 해야하는데

일이 엄청 많이 줄어들었습니다

micro-service는 서비스간 커플링이 일어나면 안되는데

기존 구조를 따라가게되면서 중간에 Java Spring단계에서 데이터 encrpytion해서 Postgress에 데이터 작성하는 과정을 거치게 되어버렸습니다

엄청난 커플링이죠.....

Docker로는 갈 것인데 아직은 아니다라는 말씀이신가요? 그리고 그 이유가 그 쪽 팀이 아직 준비가 안 되었고 정치적인 이유가 있다?

아니면 지금 VM으로 진행되는 flow에 딥러닝님이 docker라는 monkey wrench를 던져 넣으시려는 걸 막았다는 건가요?

저희 소프트웨어는 어차피 VM으로 릴리즈되고 커스터머 서버에 restore되는 방식으로 deliever됩니다

그냥 코드를 운용하는 방식을 systemctl에서 docker로 변경되는거뿐이였고

현재 그걸 하겠다고 로드맵에도 있습니다

아마 자기들이 뒷감당 하기 두려워서(불편해서)가 아닐까요?. 기존 monolithic을 micro-service 바꾸려면 architecture를 많이 손봐야됩니다. 말씀하신대로 API (REST) 도 바꿔야되고, deployment process도 변경해야 되고 (docker registry, ECR, GCR, .....) 그리고 그와 관련된 툴도 바뀔테고 workload 변경되니 db도 새로 튜닝해야될테고. LB/Proxy도 손봐야 할테고 등등등. 그리고 클라우드 환경이 아니면 이 모든변경을 서포트하기 너무 힘들거든요... 반면 늘어나는 layer에 따른 모니터링하는 부담도 더 커집니다... 

장점이야 아시는대로....

물론 노라고 해서 거기서 멈출수도 있겠지만. 저라면 POC로 한번 모든 프로세스를 대략 만들어보고 보스나 그 윗선에게 demo해보겠습니다. 그리고 긍정적인 반응이나오면 그이후는 윗분들이 정치하던 뭘하든 할일이죠. 내 일은 POC로 크레딧한번 받고 만약 프로젝트 진행된다면 진행되는 과정에서 크레딧 한번 더 받고요