이건 내가 반면교사 시리즈에 넣어야 할지 말지를 좀 고민하고 있다가… 일단은 넣기로 했다. 오씨 까는 시즌 1때에도 오씨 까는 것보다 전반적인 이해 부족으로 인한 문제점을 적은 내용도 조금 있었으니깐…..
당연하게도, 해외 개발회사랑도 일을 많이 한다. 그러다 보면 당연히 영미, 유럽 회사들도 만나게 되는데…
이 글을 읽는 분들도 잘 알겠지만, 일본인들 영어 실력 진짜 극과 극이다. 잘하는 사람들은 잘 대화되고(그래도 일본인인 거 티가 확 난다.) 못하는 사람은 진짜로 못한다. 심각하다. 회사 공식문서를 영어 일본어 동시 작성한다 하면 일본어를 그냥 구글 번역으로 돌리고 끝인 경우도 많다. (내 계약서 관련해서, 그리고 내 퇴직 관련 문서에서 그렇게 그냥 구글 번역 돌려서 작성해준 문서 많다.) 그러다 보니, 미국 회사에서 3년 일하고 온 내 경력은 이들에게 있어서 중요한 거다. 가끔 기술 관련 영어 번역이나 통역에 쓰이니깐.
그리고 이번 케이스에서의 스토리처럼, 외국 회사들 관련해서 미팅 있으면 통역해야 하니깐…
….뭐, 잠시 딴 이야기로 좀 샜습니다만…
그래서 외국 회사들은 자기네 시스템, 솔루션을 가져다가 쓰고 그러면 보통 여러모로 물어보는 것이 참 많습니다. 한국 회사들 물어보는 건 쨉도 안될 수준으로요. (한국 대기업들은 좀 다르려나… 제 경험에는 순수 자기들 기술 가진 중견기업에서는 사전에 엄청 묻는 경우는 얼마 없더군요.) 그러다보니 여러모로 대답을 해줘야 할 경우가 많은데, 거의 항상 마지막에 나오는 이야기는 다음과 같습니다.
“귀사의 솔루션의 보안적인 측면은 어떻습니까?”
라고 물을 때, 제일 힘드네요. 왜냐….
결론부터 말하면,
“저희 회사 시스템은 외부 네트워크와 연결되지 않는 분리된 시스템으로 동작하기 때문에 외부 보안적인 측면에서는 전혀 문제가 없습니다.”
…뭐, 틀린 말은 아닙니다. 실제로 시큐리티 엄청 신경쓰는 연구소라던가 그런 곳들은 격리된 네트워크를 쓰고, 필요한 repo 같은 것들은 전용 서버 만들어서 거기서 받아서 하죠. 미러 서버를 만들어서 외부 업데이트와 내부 망을 나눠서 처리하기도 하고요.
그래서 솔직히 저 대답에 뭐 잘못된 건 없다고 봅니다. 실제로 회사 팜플렛에서 회사 솔루션의 전체 구성도를 보여주고 있고, 그게 어떻게 전체적인 구조 안에서 동작하는지를 파악하는 전체적인 설명을 들으면 충분히 납득이 되는 상황이 많이 일어나곤 합니다.
뭐, 실제로 제조된 기계의 입장으로 봐도 그렇게 단독으로 구성된 시스템에서 뭐 건드릴 거 없습니다 진짜로… 그런 임베디드 기계들 뭐 한둘도 아니고요.
근데 이걸 생각보다 다른 곳에서 악용하는 케이스를 보게 될 줄은 몰랐습니다. 누가요? 바로 그분입니다. (욕쓰기도 아깝습니다 이젠…) 그리고 팀장도, 주임도 생각 외로 그렇게 생각합니다. 그 백그라운드를 설명하겠습니다. 설명 들으면 진짜로 뒷목 잡을 껍니다.
일전에 게임이라는 단어가 들어있다는 이유로 개발 관련된 사이트도 차단했다고 했죠? 뭐 프로그램 다운로드 사이트들도 마찬가지입니다. 일본에서는 다운로드 사이트를 공식 홈페이지가 아니라 옛날 옛적에 한국처럼 서드파티로 다운로드 하는 곳에서 받아서 쓰는 그런 습관들이 여전히 남아있는 거 같습니다. 실제로 일본 내에도 그런 사이트들 판을 치고(한국은 거의 죽었죠. 개인 수준의 사이트들밖에 안남았습니다. 그리고 그들마저도 공문으로 시달리고요.) 한국으로 치면 옛날 네이버 다운로드 같이 프로그램 모아서 다운로드 하도록 되어있는 그런 사이트들이요. 요즘은 그런 사이트들 가면 이상한 프로그램 설치하고 해서 여러모로 말이 많아서 잘 안가게 되지만…
뭐, 저런 것들이 여전히 남아있어서 그런지 지금도 보면 그런 다운로드 사이트 같은 곳들에 대해서는 여러모로 차단을 다 걸어두고 있습니다. 그리고 다운로드 관련으로도 여러모로 제약을 걸어두고 있습니다.
그럼 대체 궁금하죠? 아니, 필요한 프로그램들은 어떻게 쓰라는 거냐? 그냥 메모장, 그림판 뭐 이런것만 쓰라는 거냐??? 할 수 있겠죠?
바로 저 ㅆㄴ의 부서인 정보관리과에 사용 신청을 하면, 자기들이 다운로드 받아서 백신도 돌려보고, 문제 없는지 보고, 보안 관련해서 문제 없는지 보고 그렇게 해서 다 통과 되면 인스톨러를 제공해 주겠다고 합니다. 반대로 당신들이 멋대로 접근하면 바이러스나 악성 프로그램을 받을 수 있다는 기적의 논리로요.
……….
자, 전에 글에서 저 기적의 논리에 대응해서 제가 지금 회사의 보안이라는 것을 설명한 적이 있습니다. 백신에 안걸리면 장땡인 논리입니다. 저들은 오픈소스라서 소스코드를 제공해도 코드 분석은 커녕 돌릴 수 있는 프로그램을 가져와라라고 저한테 역으로 협박을 합니다. 그러면서 저런 내용에 대한 대안이 저딴 보안입니다.
그럼 그냥 저런 거 지켜가면서 회사 생활 하면 되는 거 아닌가요? 라고 물을 수 있는 분들께….
그런 곳에서 쓰는 프로그램의 최종 만능 툴이 일본 SI 시장의 최고 대명사인 사쿠라 에디터입니다. SI 현장에서 다른 건 다 안되는데 저 에디터는 무조건 OK라는 소리의 그 주인공…
저딴 걸로 스스로 갈라파고스 되는 케이스를 보고 있습니다. 그나마 다행인 것이 북미, 유럽권 외국인들도 있는 회사라서 저런 에디터만 쓰는 환경은 아니라서 여러 프로그램들을 쓰긴 합니다만…
저 이상한 주장이 이상하다는 걸 못느끼는 팀장급, 주임급들이 넘쳐난다고 생각해보세요…. 라고 하고 전 일단 이번 글은 마칠께요. 머리아파요…..
“그리고 저 환경으로 급할 때 요긴하게 쓴 파이썬 스크립트도 장난아니게 많습니다. 근데 정작 사내에서 파이썬 쓰는데 문제가 또 있는데…(이건 다음 편에서)”
네, 그 다음편입니다.
요즘 뭐 개발하는 데 있어서 패키지 관리자의 소중함은 다들 아실 껍니다. 누가 완전 추가 패키지 없이 기본 패키지만으로 자기네 전용 패키지 만들어서 쓰고, 그걸로 갖고 그냥 순수하게만 씁니까….
라고 하면 저렇게 해야 하는 특수 분야 분들이 어떻게 받을 지 모르겠지만(진짜 STL도 버거워서 쌩개발 해야 하는 그런 분야 분들은 어쩔 수 없는 거 압니다. ㅠㅠ), 일반적인 개발에서는 있는 라이브러리 잘 쓰는 거 다들 아실꺼라 봅니다.
ㅎ 근데…..
와. 패키기 관리자를 다 막았네요. 심지어 일부 개발 언어나 환경은 사이트 자체를 막았습니다.
구라같죠? 진짜입니다.
근데 이게 막은 이유가 뭐 있나 싶으면…있습니다.
바로 “Game”, “게임”, “ゲーム”라는 단어가 들어가 있기 때문입니다.
…………….
…………..
무슨 개소리냐 싶겠지만, 일단 들어보세요. 저 개소리가 이해만 되고 납득이 안되는 상황을 보여드립니다.
당연하겠지만, 회사에서 일하는 컴으로 게임하는 건 안되는 겁니다. 회사 컴은 일하라고 주는 거니 놀라고 주는 게 아니니깐요. 그러니깐 직장인들 좀 놀고 할 수 있는 것이 정보 공유를 통한 커뮤니티 사이트가 되기도 하고 그런 거죠 뭐….
근데 이걸 무식하게 생각해서…..
“아예 그냥 게임 관련 모든 사이트를 다 막아버리면 되는 거 아냐?”
라는 특정한 마인드의 분들이 다수 모여있는 곳에서 정해진 것이 바로 키워드에 따른 접속 차단입니다. 그럼 이걸 키워드로 막게 되니깐,
게임 사이트들 다 막고, 게임 뉴스나 게임 정보 관련된 사이트 다 막고, 게임 개발에 관련되어있는 사이트를 다 막습니다. 그러니 게임 개발에 필요한 것들은 그냥 다 막아요. 스크립트 언어 관련해서 루아도 막고, 파이썬도 막고… 게임 서버 관련된 것도 막습니다. 뭐 여러모로 막습니다.
그러나, 유일하게 피해가는 곳이 있으니! 그것은 마이크로소프트입니다.
근데 왜 마소는 안막아? 엑스박스 게이밍 있잖아? 다이렉트 X 게임 개발에 쓰잖아? 라고 생각하실 분들… 마소는 어차피 여기서 윈도우 개발도 하고 해야 하니 당연히 예외처리 했습니다. 그분들이 거기까지 멍청하진(??) 않습니다.
자, 이렇게 쳐막았으니 당연히 파이썬 안됩니다. js 관련된 거 다 안됩니다.
…..왜 이꼴이 났는지 이해가 되시죠?
그리고 그 중심에는 그 썅년이 또 껴있습니다. 그 썅년 아이디어입니다.
이걸 회사 입장에서 이해하는 분들이 있을 수 있지만… 개발에 특정 언어 하나만 가지고 모두 다 할 수 있는 경우 있나요? 이것저것 필요하면 쓰는 거고, 빠르게 개발할 수 있는, 빠르게 처리할 수 있는 거면 그냥 쓰면 되는 겁니다. 그런 거에 이것저것 따지거나 하는 건 없다고 보는데….
이렇게 이것저것 다 막아놓은 관계로 개발한 거 빠르게 테스트 할 테스트 프로그램 외부에 널려있는 것도 파이썬 없어서 못돌리고 그래서 C#으로 테스트 프로그램 싹 다 개발해서 테스트 합니다. 그렇게 힘들게 테스트 프로그램까지 짜서 돌려서 문제 없이 싹 다 만들고 했는데 나중에 개발에 시간 많이 걸렸다, 다음에 이 공수 어떻게 줄일꺼냐 하는 소리나 들어야 했습니다.
이전 편의 좀 연장으로 쓸께요. 원래 쓰고 싶었던 내용은 그 다음에 쓰기로…. 왜냐, 저딴 개소리를 하는데 있어서 뭔가 이상하다 싶으면 이걸 보면 됩니다.
저딴 일이 있고나서 저한테 안내라면서 저를 회의실로 불렀습니다. 회사 보안에 맞는 소프트웨어를 써야 한다고 말이죠. 그래서 제가 물었습니다.
“회사 보안에 맞는 소프트웨어는 어떤 것이냐. 지금 보면 라이센스 만료되고, 개발 중단되어서 끊긴 그런 소프트웨어들 엄청 보이는데 이런 프로그램들이 더 문제지 않느냐?”
하니깐 하는 소리가
“사내에서만 쓰니깐 문제 없다.”
……
그래서 다시 묻습니다.
“그럼 프로그램들이 보안이 취약한지, 내가 쓰고 있는 오픈소스나 재단, 비영리 프로그램들이 보안이 취약한지 어떻게 아느냐?”
“백신 돌려본다.”
……………………..
미치겠습니다. 또 묻습니다.
“그럼 백신이 안잡아내는 프로그램이면 전부 OK인거냐?”
“우리가 돌렸을 때 문제 없고, 업무에 꼭 필요하면 된다.”
……………..
그래서 제가 그자리에서 3분만에 프로그램 하나 짰습니다. 백신에 당연히 걸리는 프로그램니다. (이정도 단순한 바이러스는 다들 교양으로 하나 짤 수 있잖아요.) 근데 웃긴데 짜고 돌리는데도 바이러스로 인식 안합니다.
“그럼 이거 돌려봐라.”
근데 회사 백신이 못잡습니다. 바이러스 아니랍니다.
“이 프로그램 백신에 걸려야 정상이다. 근데 왜 안잡냐.”
“프로그램 정보가 없어서 안걸린 거 같다.”
“프로그램 정보가 없으면 오히려 예외 처리를 해줘야 할 만큼 잘 잡아야 정상 아니냐?”
입 쳐 다뭅니다. 그리고 저 이야기가 틀린 소리냐면 그것도 아닙니다. 개발 처음 하시거나 회사에서 처음 프로그램 내보고 하면 아실 껍니다. 프로그램 정보가 없어서 백신 프로그램들이 차단하고 난리인거… 백신은 그게 당연한 겁니다.
…………진짜 썅년입니다.
뭐 그러고는 할 말 있나 지켜보는데 결국 말하는 거라고는
“회사에서 인정 못하는 프로그램은 안됩니다.”
라고 해서 또 질문 합니다.
“이 소프트웨어는 여러 파트너 맺어져 있고, 실제로 마소나 몇몇 유명한 회사 직원들도 컨트리뷰터로 참여하고 있는 프로그램이다. 그리고 이걸 각종 백신회사에서도 검증하고 배포하는 곳에서도 안전한 프로그램으로 이미 다 인식하고 있는 프로그램이다. 이건 왜 안되는 거냐.?”
입 다뭅니다.
“파이참 개발한 젯브레인스는 지금 여기 회사 개발보다 몇십배는 많고 몇배는 똑똑한 사람들 모여서 만드는 상용 프로그램의 커뮤니티 버전이다. 당신이 지금 이 프로그램의 보안 문제를 검증할 수 있는 실력이라면 이 프로그램에서 어떤 문제 때문에 안되는지 나한테 설명해라.”
“파이썬 언어 자체를 사용 금지하도록 해뒀는데, 이걸 왜 사용하면 안되는지에 대해서 나한테 설명해라. 내가 이 정보 그대로 번역해서 파이썬 재단에 파이썬 언어의 중대한 결함 시스템으로 해서 당신 이름하고 같이 공유하겠다.”
입 다뭅니다. 짜증납니다. 그래서 짜증 좀 냅니다.
“당신이 말하는 보안이라는 수준이면, 당신은 지금 이 프로그램이 컴퓨터에서 돌면 바이러스나 각종 유해 프로그램처럼 돌 것이라는 것을 전부 다 알고 있다는 소리인데, 그러면 그런 해안이 없어서 전 세계 사람들에게 검증받고, 수많은 회사들이 써보고 문제 없다고들 이야기하는 소프트웨어를 개발한, 이용하는 전 세계의 모든 사람들이 당신보다 멍청한 사람들이라서 이걸 쓰는거냐?”
당연히 대답도 안합니다.
“그래서, 내가 이런 툴을 쓰려면 어떻게 해야 하냐.”
그러니 이제서야 답할 내용 튀어나오니 바로 답합니다.
“정보보안과에 신고해 주시기 바랍니다. 신고 후에 검증하고 결과 통보까지 4주 걸립니다.”
………………………
제정신 아닌 년입니다.
참고로 그 뒤에 어떻게 되었냐면요….
저 년은 제 근처에 얼씬도 안하고, 정보 보안 관련해서 저한테 단 한톨도 말 안합니다. 대신 제 위에 있는 사람 통해서 간접적으로 들어오는데, 그분들도 뭣도 모르고 다 털립니다. 이게 회사 입사 4일만에 있던 이야기입니다.
그리고 지금까지도 그때 금지한 프로그램들은 여전히 금지입니다. 저 빼고요. 이러고도 미친년 소리 안나오면 이상한 겁니다.
이게 뭔 제목인가 싶겠지만… 사실입니다. 그리고 지금 이 회사 정보보안과 주임이라는 년이 꺼든 협박입니다. (순화된 표현을 쓰기도 아까운 년입니다. 그래서 년으로 씁니다.)
개발을 하기 시작하면 당연하게도 개발 환경을 구축합니다. 그리고 개발환경 구축하면서 원하는 개발 툴이나 확장 프로그램들을 설치해서 쓰는 경우가 허다합니다. 이건 누구나 다 그럴 껍니다. 요즘 오픈소스로 나온 것들도 많고 그냥 프리웨어 환경으로도 여러모로 구축하고 시작하니깐요.
그러나, 보안이라는 이유로 프로그램 다운로드를 금지하고, 공식 사이트를 못들어가게 하는 미친 환경이 실존할 거라고는 생각 못했습니다. 진짜로요….
….ㅎ 진짜.
일본에 넘어오기 전에 구현한 회사 프로그램이 있는데, 그건 패키지 관리자를 통해서 몇몇 라이브러리를 이용하여 만든 프로그램입니다. 그래서 이걸 인수인계 하는 과정에서도 이 개발 환경을 보여주는데 패키지 관리자에 접속이 안됩니다. 회사 네트워크에서 블락했습니다. 마이크로소프트의 패키지 관리자를 블락하는 사상 초유의 미친 환경을 봤습니다. 개지랄을 하니깐 풀어줍니다.
그리고 다서 얼마 안 지나서는 회사 서버 접속이 이상하게 안되는 일이 있어서 정보관리과를 불렀더니, 그들이 제 노트북을 뺏어갑니다. 원인을 모르겠다고요.
그리고는 고치라는 서버 접속문제는 안고치고는 제 노트북에 깔린 프로그램에 대해서 문제시합니다.
그때 깔린 프로그램들이 뭐냐면요..
visual studio
visual studio code
jetbrain
sourcetree
winmerge
vim
WSL2로 깔린 ubuntu
wireshark
nmap
putty
sqlite browser
python
nodejs
이 중에 비주얼 스튜디오와 비주얼 스튜디오 코드를 제외하고는 뭔지 모른다는 이유만으로 전부 삭제할 것을 저한테 명령하였습니다. 진짜로요. 근데 이걸 개발을 관장하는 과장도 이 이외의 프로그램들을 왜 썼는지 알려줘도 어찌해야 할 지 모릅니다.
그러면서 저 정보보안과 주임년이 날린 개소리가 가관입니다.
“나는 (회사에서 검증하지 않은 소프트웨어를 쓴) 너를 자를 수 있어! 말 안들으면 인사과에 퇴사 조치 시키겠다.”
무슨 이런 대사도 아니고 진짜…
그때 퇴사 결심을 했었는데 그게 입사 3일만의 일이었습니다. 진심으로 저걸 지금 여기 입사를 위해서 멀리에서 찾아온 외국인한테 하는 소리라고 지껄이는 건가 싶습니다. 그러고는 사내 툴이라면서 보여주는 몇몇 것들은 이미 라이센스 만료된 소프트, 개발 끊긴지 몇십년 된 소프트, 윈도우 xp 환경 권장 소프트… 전부 안돌아간다면서 거부했습니다. 노트북은 최신껄 줬으면서 대체 왜…?
그리고 저 환경으로 급할 때 요긴하게 쓴 파이썬 스크립트도 장난아니게 많습니다. 근데 정작 사내에서 파이썬 쓰는데 문제가 또 있는데…(이건 다음 편에서)
p.s. 이런 것들이 진짜 바글바글한게 일본이란 나라라면, 일본은 희망이 없습니다. 일본에서 사쿠라 에디터 쓰는 이유가 있습니다. 메이드 인 재팬 뽕 채우는 정신승리용 에디터입니다.
되게 간단한 유틸리티 개발 요구가 있었다. 그래서 회의를 잡고 요구사항 히어링 하면서 기능에 대해서 정의를 싹 했다. 그리고 정의된 내용에 대해서 다시 회의를 잡고 이게 맞는지 최종 컨펌을 또 잡는다. (이게 일본회사 스타일이고, 이딴 짓 땜에 피로감이 장난 아니다.)
그렇게 해서 최종으로 정해진 내용을 가지고 유틸리티를 하나 개발해줬다. 그렇게 어려운 것도 아니었기 때문에 금방 끝났다. 그리고 그날 테스트까지 다 마치고는 넘겨줬다. 이게 그냥 단 하루만에 될 정도였다.
근데 퇴근시간에 돌아가려고 할 때, 나한테 이거 아닌데? 하는 소리가 전해졌다.
ㅎ 진짜…..
그래서 다음날 회의를 잡으려고 했다. 근데 출장갔단다.
……………
그러고 다음주가 되었다.
그리고 나서 회의하는데, 원래 이게 아니란다. 이 유틸리티로 정리할 파일의 포맷이 잘못되었다고 한다.
그래서 뭔가 했더니, 원래 이 유틸리티의 결과물을 또 받아다가 처리할 프로그램이 또 있다고 한다. (…????) 그러니 그 프로그램에서 읽을 수 있도록 파일 포맷을 맞춰야 한다는 것이다.
그래서 난 그자리에서 지난번에 결정된 내용을 싹 다 말했다. 그러면서 저 말을 끼워맞추니
나: 그 다른 처리 프로그램이 요구하는 내용이 원래 더 있어야 하는 거네요? X: 응. 나: 그 프로그램은 왜 저한테 이야기가 안되었죠? X: 이미 전에 이야기 했잖아? 나: 언제요? X: OO일에. 나: 저 이거 관련해서 첫 회의 진행한 날이 ㅁㅁ일인데요? (ㅁㅁ = ㅇㅇ + 3일)
그제서야 내가 참가하지도 않은 자기네 내부 회의 내용을 이제서야 말한 것이다.
ㅎ ㅅㅂ….
그러고는 출장 가있는 동안 사내 정보 공유하면서 내가 그 유틸 한거 어찌되었냐? 아직도 못했냐? 그러면서 부서란 부서에 죄다 쪼고 있었다고 한다. 그래서 위에 팀장들한테 졸라 까인 건 덤이다.
일단 그 연동해야 하는 소프트 관련해서 정보 얻고 뭐 하고 해서 이틀 걸렸서 완성 다 하고 깔끔하게 끝났는데, 일 끝나면서도 하는 소리가 또 가관이었다.
“앞으로는 사양 제대로 확인하고 해요.”
…..이래서 이 회사는 발전이 없는 곳이라도 본다. 그냥 하루빨리 퇴사일이 와야지 별 수 있냐….
내가 이 시리즈를 다시 쓸 일은 없을 거라고 생각했다. 왜냐, 오씨의 그 쓰레기짓 같은 일을 설마 더 겪겠어 했거든….
근데 다른 형태로도 겪는다. 개발 아닌 곳에서도 겪는다… 그래서 시즌 2를 적기 시작한다. 진심 최악이다.
이번에는 진짜 회사 it 자원에 대한 이야기를 좀 하려고 한다.
회사에 it 자원은 우리가 개발하는 데 필요한 자원이다. 그러니깐 꼭 있어야 하고, 꼭 잘 되어야 하는 자원이다. 그건 당연히 일의 효율과도 직관된다. 반대로 이런 자원이 제대로 되지 않은 곳에서는 될 일도 안된다.
그 대표적인 것이 바로 똥컴 주는 회사랑 인터넷 느린 회사다. 이건 말도 안되는 거다. 미친거다 진짜로….
컴 느린 거 주는 건 진짜 컴에 대한 개념이 없는 거다. 사무직들 쓰는 컴 주면서 개발하라고 하는 거 진짜… ㅎ 그냥 할 말 없다. 개발용 컴퓨터를 따로 주면서 사무용으로 컴퓨터를 나눠 쓰면 뭐 다행인데…. 그건 나 포함 일부 사람들 뿐이었다. ㅡㅅㅡ
그리고 네트워크 느린거…. 느리다 못해 도중에 끊기는 것도 진짜 미친 거다. 요즘 인터넷 안되는 곳에서 일 어떻게 하냐. 협업 툴도 인터넷 되어야지 되는 세상에! 네트워크 끊기는 것도 절대로 있을 수 없는 일인데 그걸 별 수 없다면서 여기는 놈들이 진짜….
그러면서 어이없는 네트워크 점검한답시고 공지 띄우고 하는꼴 보면서 드는 생각이… 그냥 미쳤다는 생각밖에 없네요.
지금 여긴 네트워크를 그냥 첨부터 싹 다 뜯어내고 다 갈아엎어야 하는 상황인데, ap도 그 낡아빠진 거 다 갈아 버리고 다시 새로 사서 하고, 망 중계기도 100mbps 레벨인 거 아는데 이거 kddi 불러서 죄신껄로 바꾸고 회선망도 다 갈아서 유선으로던 무선으로던 엄청 여유로운 걸로 바꾸면 네트워크 안끊긴다 그런 소리 몇번을 해도 개소리 취급이나 하고…
오랜만입니다. ;ㅅ; 대체 이넘의 오랜만이라는 소릴 좀 그만했으면 좋겠군요. (근데 뭐, 금방 그만 할 겁니다. 앞으로 될 수 있으면 계속 글을 쓸 껍니다. ;ㅅ;
오랜만의 글이 반면교사인 것에 대해서도 여러모로 좀 고민이 있던 것이지만… 이건 좀 제가 고민에 고민을 거쳐서 쓰는 글이군요. 근데 좀 글의 구성이 거칠거나 할 수 있으니 일단 양해 먼저 부탁드립니다.
개발을 하는 환경이 자기 혼자서 모든 것을 다 해야 하는 것이 아닌 이상, 개발자와 관리자(프로젝트 매니저)의 관계는 항상 존재하게 되어있습니다. 거기에 더 해도 같은 개발자가 더 있거나 디자이너, QA 등 여럿이 있지만 해당 프로젝트를 개발하는 개발자와 그 프로젝트를 책임지고 확인하고 관리하는 관리자는 항상 존재하게 되죠.
개발자와 관리자는… 서로 협력하거나 서로 싸우거나입니다만…. 여러모로 학 떼는 일들 많이 보는 관계가 됩니다. 그러면서 신뢰가 쌓이는 것도 있고 그렇습니다만….
관리자의 입장에서 개발자를 어떻게 대하느냐에 따라서도 여러모로 차이가 나는 일들이 생기기도 합니다. 관리자도 일단 기본적으로 프로그래밍을 어느 정도 해본 사람일 것이고(아예 안해본 경우도 있긴 합니다만… 그건 걍 답이 없습니다.), 그러다 보면 이 개발자가 어떤 수준의 개발자이고 어떤 성격의 개발자인지도 파악이 되는데, 여기서 이제 문제점이 생길 수 있는 길이 열립니다.
관리를 너무 빡빡하게 할 경우에는 개발자들이 숨쉬기 힘들어집니다. 관리자의 명령대로 움직여줘야 하는데 그러한 것에서 여러모로 문제가 생기게 되면 그땐 그냥 싸움의 연속이 될 수 있기 때문이죠. 팀 깨지는 거 쉽습니다. 게다가 개발 경험따윈 하나도 없는 녀석이 관리자일 경우…. 진짜 머리 아픕니다. 개발에 대해서 쥐뿔도 모르고 그냥 키보드 다닥거리면 그냥 완성되는 줄만 아니깐 그냥 일을 막 내리고 왜 안되었냐고 매일매일 갈구고 체크당하고 그러면 개발자들 스트레스 장난 아니게 받습니다. 진짜 회사 때려치고 싶어지게 되죠. 그러다가 도중에 문제 생기면 그냥 책임론으로 싸우기 쉽습니다.
그러다 보니 개발자 출신의 관리자들 사이에서는 개발자들을 믿고 그냥 맡기는 걸 최고라고 생각하는 관리자급이 많이 존재합니다. 특히 개발 좀 해봐서 안다는 그런 사람들 중에서(아마 한국에는 지금의 40 중반대~50 초반대의 팀장님들 중에 생길 가능성 높습니다.) 자기 팀의 개발자 또한 어느 정도 실력있어 보인다고 생각할 경우에 이런 경우가 상당히 생기는데… 이때 생각 잘못하면 진짜 피봅니다. 차라리 관리를 빡빡하게 해달라고 하는 게 더 좋을 정도입니다.
좋은 예를 들면 바로 저와 오씨의 경우입니다. 저도 좀 여러모로 많~~이 방치되어 있었고, 아마 오씨의 경우에도 엄청나게 방치되어 있었을 것입니다. (이 회사가 여러머로 사람 놀리는 일을 다방면으로 하다보니 회사에 개발자 혼자 덜렁 남는 경우가 좀 생기는 그런 회사입니다.) 개발자가 방치가 되어 있을 때, 좋은 점과 나쁜 점이 있습니다. 좋은 점은 자신이 해야 할 일이 명확하게 있을 경우에는 아무 방해 없이 자기 업무 스타일대로 개발을 할 수 있다는 점입니다. 이건 여러모로 좋은 점이죠. 개발하는 분들 잘 아실 겁니다. 나쁜 점은 해당하는 일이 다 끝났을 때입니다. 이때에 자기 권한 밖의 일을 끌어와서 일을 하느냐 마느냐의 기로에 설 수 있습니다. 아니 설껍니다.
이때, 저와 오씨의 일 처리 차이가 발생하였습니다. 전 무조건 제 위에 팀장을 불러서 일을 만들어냈습니다. 제 밑에 사람들을 이용해서 제가 만든 프로그램에 대한 테스트 또한 부탁을 하였죠. 이렇게 해서 제 권한과 제 위에 팀장의 권한을 잘 이용하여 여러모로 일을 진행할 수 있게 했습니다. 가끔 바빠서 이분들이 안계실 경우에는 좀 놀고 그랬습니다만 워낙 TODO 리스트를 미친듯 받아놓고 시작했기 때문에 여분의 공백이 있더라도 다음 일을 할 수 있도록 스스로에 대한 관리를 진행하였죠.
문제는 오씨의 경우였습니다. 이분은 팀장이 자리에 없거나 팀장이 있더라도 일을 진행할 생각이 별로 없었습니다. 초반에는 저처럼 했다고들 하더군요. 근데 도중부터는 그냥 사람들 없으면 일을 안했다고 하네요. 그러다보니 진행사항에 대한 것도 제대로 확인도 안되고, 일도 얼마나 했는지도 모르고, 그냥 개발자가 보고해야 하는대로만 알 수 있었다고… 회사가 좀 특이한 경우가 있어서 개발자 오씨를 제외하고는 전부 사람들이 나가있을 경우가 있으면 그냥 그분은 걍 회사에서 열심히 놀았다고 하는군요. 당연히 그분은 칼퇴란 칼퇴는 다 했습니다. 그러니 진행은 제대로 안되고… (근데 코드는 그따구로 짜고…)
그런 놀고먹는 환경에서 오씨는 코드는 그따구로 짜놓고 나중에 수정해야 할 꺼리 있으면 여러모로 꼬여서 맨날 이따구 이야기나 하고 말이지….
근데 이건 팀을 관리하는 관리자의 입장에서는 정말 잘못한 실수입니다. 오씨가 방치되어있을 때에, 오씨와 해야 할 일에 대해서 체크를 하고 오씨를 놀리지 않도록 해야 할 일에 대해서 어느 정도의 관리를 한 다음에 오씨를 가만 두었어야 했습니다. 그럼 최소한 일이 진행되지 않는 그런 사태에 대해서는 미연에 방지할 수 있었습니다. 근데 오씨가 알아서 하겠지라고 그냥 믿고 있던 것이…. 엄청난 실수입니다. 그 사이에 일어났던 일들은….(이저 ㄴ시리즈들 참조)
근데 관리자들이 왜 이렇게 그냥 놔두는 선택을 하게 될까요..? 전 여러모로 그냥 추측만 해보고 있습니다만 가장 좋은 이유가 개발자한테 책임 물리기를 할 수 있기 때문이라고 봅니다. 관리자를 통해서 일을 처리하지 않고 있다가 지금까지 뭐했냐는 그런 식이죠. 그리고 관리자는 복잡한 것에 대해선 생각하지 않아도 되는 장점이 생깁니다. 복잡한 생각은 전부 프로그래머의 몫이 되고 관리자는 그냥 그런 기능이 사양서대로 구현되어 있는지만 체크하면 되는 간단한 수준으로 업무 내용이 줄어들게 됩니다.
개발자가 기획부터 설계, 개발, 테스트, 배포까지 모든 걸 해야 하는 경우가 아닌 이상 개발자는 어느 정도 선을 긋고 일을 해야 합니다. 안그러면 끝도 없는 일이 만들어지게 됩니다. 사양서에 없는 일까지 아주 완벽하게 가려고 하다보면 산으로 가는 코드 짜는 거 일도 아닙니다. 진짜로.. 그러다보면 커뮤니케이션 미스 나는 케이스도 금방 쉽게 발생하게 됩니다. 당연하죠. 개발자가 완벽한 사람도 아니고…. 맨날 컴퓨터랑 이야기해서 결과물 내는 데만 집중하는 사람들이 다른 일들까지 다 완벽하게 할 수 있을거라고 생각한다면 그것이야 말로 뭔가 잘못된 것이죠. 설계때부터 참여했다 해도 마찬가지입니다. 해당 설계가 완벽하다는 보장도 없는 이상 설계는 바뀔 수 있고, 바뀌는 것에 대해서 유연하게 대처하는 것 또한 필요한데 그런 것에 완벽함따위가 있겠습니까…
이런 상태에서 길도 모르는 채로 방치된다…?
프로젝트 진행 느리게 하는 가장 좋은 방법 중 하나라고 생각합니다.
그러다가 이제 사양서랑도 또 다른 고객의 의견을 들어보면 또 다른 멘붕하게 되고 그동안 방치되었을 때 뭐했냐 이런 소리 나오면서… 또 싸우게 되는 거죠.
개발자 믿고 방치하는 거 나쁘다는 거 아닙니다. 최소한의 컨트롤은 할 수 있는 선에서 방치해야지 그냥 개발자 믿고 맡기는 건 아닙니다. 그러다가 나중에 망하는 건 결국은 회사고….
그러면 그 와중에도 방치된 개발자가 방치된 상태를 꿀빠는 상태라고 오인하게 되는 겁니다. 개발자도 오인하고, 관리자도 오인하고, 사장도 오인하고, 그리고 그걸 지켜보는 다른 사업팀(개발 이외의 팀)들에서도 오인하는 거죠.
오씨 욕의 종착점 중 하나인 꿀빨았다는 것에 대해서 좀 써보려고 했는데… 돌아가던 상황 보면 오씨가 그러고 싶어서 그러던 것만이 아니라는 걸 생각외로 쉽게 깨달을 수 있었기에 일단 이런 글을 좀 써봅니다. 개발 진짜 나 혼자서만 해야 한다는 그런 상황 아니면 제발 유용하게 할 수 있는 건 다 유용하게 써먹어야 합니다. 특히 사람은 중요합니다.
개발자가 오류 만들 수 있다. 당연한 거다. 사람이 만드는 건데 오류 안생기면 그게 이상한거지…. 정말로 오류가 없다면 그건 진짜로 오류가 없거나 아니면 오류가 숨는 경우인 거다. 근데 대부분은 후자의 경우이다. 전자의 경우대로라면은 사용자의 요구 조건에 따라 전부 다 진행되었다는 것을 표현하는 것이지 그게 오류 없는 완벽한 코드라는 것이 아니다.
근데 이넘의 오류가….
수정 불가능한 오류일 경우가 허다하다. 그 덕에 진짜 많은 코드를 새로 짰다.
그런 코드를 매번 볼 때마다의 내 심정이 어떻겠냐 ㅆㅂ….
수정 불가능한 코드… 만들기 쉽다. 대게는 설계 미스상에서 생기는 꼼수 부리다가 더 이상 어떻게 할 수 없는 경우에서 많이 일어난다. 이 외에는 아예 처음부터 특정 패턴, 특정 설계 방식에만 맞춰서 이용하려다가 나중에 알고보니 이렇게 짜면 안되는 거였다. 그래서 수정하려면 전부 다 고쳐야 한다 이런 식인데…. 뭐, 오씨의 코드는 양쪽 다 가지고 있었다.
앞에껀 뭐 누구나 할 수 있는 거다. 시간에 쫓기고 진행상황 체크하고 하는 거에 쫓기고 하다 보면 개발자가 그때그때 잠깐 넘기기 위해서 여러모로 구상하여 짤 때가 있다. 이게 나중에 리펙토링이 되어서 어느 정도 여유가 있는 코드로 바뀌고 그러면 좋은데 문제는 그게 안쉽다는 거…ㅡㅅㅡ 그런 코드들이야 뭐 여러모로 나중 가서 더 깊게 생각해서 해결하고 하는 경우도 있겠지만 보통은 왜 이럴 수 밖에 없었다는 것이 개발 기록이나 코드에 많이 남는다. 특수한 상황에 대한 해결을 못해서 하는 경우가 은근히 많기 때문이다. 이런 건 나중에 QA에서도 나타날 수 있고, 나중에 프로그램 사용 도중에도 터질 수 있는 것들이라 항상 경계해야 한다.
문제는 뒤에꺼다.
이건 좀…. 이런 걸 했을 경우에 다시는 이런 걸 하면 안된다는 걸 배워야 한다. 실제로 회사 입사할 때에나 대학교 3,4학년들한테서 여럿 보이는 증상 중 하나가 이제 본인이 좀 공부 좀 해서 여러모로 짤 수 있으니 이러면 좀 더 좋겠다 저러면 좀 더 좋겠다는 것이 보이는 건 좋은데…. 그걸 했을 때에 대해서 깊은 사고가 덜 미치는 경우가 있다. 그래서 실제로 구현하고자 하는 내용대로 초반에는 되었는데 나중에 가면 갈수록 요구사항이나 수정사항이 생기고, 그에 따라서 변경해야 할 때에 더 이상 변경되지 않는 설계 구조를 가진 경우… 그로 인해서 사용자의 데이터까지 침해할 수 있는 심각한 오류…. 거기다가 이게 돈 계산 문제라고 생각해봐라. 엄청나게 심각한 거다.
자 이런 문제를 일으킨 거에 대해서는 좋다. 그렇다 쳐. 이제 해결을 해야 하는데… 두 가지 반응을 보인다. 하나는 이거에 대해서 반성을 하는 사람이고, 다른 하나는 그냥 오류 중 하나 터진 거니깐 그냥 수정하고 말면 되는 거 아니냐는 반응이다.
여기서부터 감이 좀 오는가…? 내가 왜 이 글 쓰는지…?
전자는 그냥 자기 혐오에만 안 빠지면 충분히 자기 개발이 될 사람이다만… 후잔 절대 반성 안한다. 이 문제가 나중에 여기저기서 말 나오면 그때에는 적반하장이 뭔지 보여줄 정도로 이야기 꺼내는 사람마다 죄다 시비걸고 싸울 꺼다. 이런 식으로 가는 개발자가 그냥 기술만 익히고 자기 기교만 부린다고..? 그러면서 무슨놈의 개발을….
이런 자기 반성도 안되는 개발자들은 익스퍼트 비기너가 되면서 이런 비슷한 실수를 계속 반복할 것이다. 그러면서 자기가 짜는 구조대로만 돌아가는 코드를 만들어놓고는 이 대로 사용자들이 써야만 하는 걸 왜 이해 못하냐고 지랄하겠지…. 이렇게 개발 년수가 몇 년 단위로 쌓인다고 해서 뭐 제대로 만족스러운 프로그램 개발을 할 수 있을까?
ㅇㅇ. 오씨는 구제할 수 없는 바보임.
그래서 많은 사람들이 설계를 어렵다고 하는 거다. 그냥 쉽죠 하고 덤볐다가 나중에 사양 변경을 위해 여러 검토를 해야 되는데 설계 단계에서 문제가 터진다..? 이러면 그냥 못하는 거다. 설계부터 다시 해야 하는 거다…. 아니면 코드를 밑바닥부터 다 드러내서 싹 다 고쳐야 되는데.. 이 고치는 과정 중에 데이터베이스까지 건드리고 하는 사태가 벌어져서 사용자 데이터가 훼손되고 그러면…. 그것도 라이브 서비스 중에….
정말 옛날 옛적에 보면 시디 엄청 쌈마이로 막 구워서 팔아넘기고 뭐 그러던 시절에 돌고돌던 시디들은 솔직히 수명 오래 안가는 거 안다. 시디 제조하는 거에 따라서 품질하고 수명 좀 확확 갔으니깐… 그리고 보관방법도…
근데 구매한지 3개월밖에 안된 하드웨어의 박스 안에 같이 들어있던 밀봉된 장치 드라이버 시디가 열화되었다고? 그래서 더 내용을 못해본다고? 그렇게 그때 당시의 상사들한테 보고를 했다고!?
그렇게 해서 개발이 안되었던 특수한 하드웨어가 있었는데….
내가 입사하고 나서 소스코드 분석하면서 같이 했던 것이 바로 개발실에 굴러다니는 시디들 죄다 읽어서 내용들 죄다 서버랑 내 컴퓨터 하드에 백업하는 거였다.
근데 그때 안읽히던 시디 하나도 없었다.
이건 대체 뭔 부조리냐…?
내가 직접 이 장치 개발해야 한다고 할 때, 개발 하루만에 끝내고 보고했다. 어떻게 했냐고 물어서 굴러다니는 드라이버 연동시키고 그냥 시리얼 통신해서 끝냈다고… 이거 드라이버 시디 읽었다고 했을 때 내가 이 글 제목에 적은 변명을 듣고는 개발 못하고 있던 거라고 윗사람이 말하는데 그걸 들은 내 표정이 저랬다 진짜….
그냥 하기 싫었던 거였어 오씨 이녀석……
구라를 칠꺼면 그냥 이렇게 치던가… 그러면 다들 일 안할 수 있잖아!
시디의 수명에 대해서 물어보는 사람들이 있을 거 같기도 한데….
제대로 만들어진 시디는 솔직히 수명 오래갑니다. 직접 오븐에 굽고 물에 삶은 걸로도 쉽게 안망가집니다. 레이저로 직접 써낸 저 은색 부분을 어떻게 해야 하는데… 요즘 시디들은 저거 쓰는 곳을 좀 더 깊숙한 곳에 두고 위에 라벨은 얕은 곳에 둬서 층을 조금 나눠두는 시디들도 많은지라….
메인보드나 그래픽 카드 사면 종이로 싸주죠? 그걸로 직사광선 맞지만 않으면 오래가요. 스크래치 보정하는 기술도 있어서 엄청나게 심한 스크래치 아닌 이상 시도해 볼 만 합니다.
