며칠 간의 경험, 그리고 교훈

요 며칠 간 블로그의 글이 뜸했던 이유는 내가 게을렀던 것도 있지만, 회사내에 F.E.T 팀에 소속되어 계속 야근을 했었기 때문이다. F.E.T라는 말은 회사와서 처음 들어봤는데, Fully Empowered Tem이란다. 많이 쓰는 용어인가 싶어 구글에서 찾아보니 검색 결과가 얼마 안 보이는 걸로 봐서, 이넘도 그냥 우리 회사에서 만든 용어인 것 같다. 그냥 general term으로 TFT (Task Force Team) 정도가 되지 않을까나.

사실 이제 막 사원으로 들어간 내가 낄 자리는 아니였지만, 어찌어찌 하다 보니 여건 상 .. 지난 주 수요일부터 시작해서 주말에도 내내 나오고, 오늘 대충 정리가 됐으니 한 일주일은 한 것 같다.

몇 가지 답답했던 경험을 적어보면,

1. 문제는 속도. 우리는 어떠한 작업의 시간을 줄이기 위해 모인 팀이다. 속도를 개선하기 위해서는, 상식적으로 작업 별로 들어가는 시간(cost)를 측정한 뒤, 어느 작업에서 퍼포먼스를 많이 잡아 먹나를 분석하고, 많이 잡아 먹는 작업 부터 시간을 줄여 나가는 것이 상식이다. 이건 초등학생도 생각할 수 있는 작업 process다. 여기서 현재 하드웨어 스펙, 소프트웨어 구조, 구현 난이도 등을 고려하여 못하는 것을 빼내고 나면 우리가 줄일 수 있는 최대 한계치가 나온다. 얼마나 심플한 해결책인가.
   
   그런데 다른 팀에서 작업 별로 들어가는 시간 측정이 불가능하댄다. 왜 불가능하냐고 물으니, 개발사에서 못한다고 했단다.
   
   (내가 상용 프로그램 개발을 안해봐서 모르겠지만, 작업별 시간 측정이 그렇게 어렵나? 진짜 단순 무식하게 생각해서 작업 별로 global 변수 두고, context switching이 일어날 때 마다 시간 측정해서 더하면 되는 것 아닌가? 물론 시간 측정에 따른 오버헤드로 실제 실행 시간과는 약간의 괴리가 생기겠지만, 그래도 최소한 비율은 볼 수 있을 것 아닌가. 찾아보면, 멀티 쓰레딩 환경에서 쓰레드별 시간 측정을 위한 방법도 분명히 나올텐데. )
   
   그게 안된다고 우기니 말도 안되는 논리로 최대 한계치를 끄집어 내다 보니 보는 사람마다 한 소리씩 하는 보고 자료 첫 페이지가 되어 버렸다.
   
   
2. 비교를 하기 위해서는 기준을 명확히 해야 된다. 기준이 흔들리는데 지난 번 측정 시간과 지금 측정 시간간의 비교가 무슨 의미가 있나. 명확한 기준을 세워서 테스트를 하자고 말씀 드렸더니, 사장님께서 고객이 체감하시는 속도를 원하시기 때문에 그렇게 했다고 하신다.
   내가 봤을 때, 우리가 시간을 줄이고자 하는 부분이 A 구간이라면, 우리가 control할 수 없는 환경 변수들은 다 빼고, A 구간에 대해서만 시간을 측정하여, 비교를 수행한 후 효과를 검증해야 한다. 그런 다음 사장님께 보고 드릴 때는, 우리가 측정한 시간 + B가 고객이 체감하는 시간으로 적되, B가 대략 어느 범위 안으로 예측되지만, 이 변수는 상황에 따라 바뀔 수 있다고 말씀 드리는게 맞다.
   
   
3. 맨파워. 조금 실망을 많이 했던 부분인데.. 전화로만 일을 하는 분이 계셨다. 뭔가 하나를 물으면 하나에서 열 까지 개발사에 전화를 해서 시킨다. 그리고 답을 주신다. 정말 모르시는 건지, 아니면 확실한 답변을 위해서인지는 모르겠지만, 너무 의존적이라는 느낌을 많이 받았다. 이러니 앞으로 뭘 개선해야 될지에 대한 근본적인 물음에 대한 답이, 개발사에서 들은 대답대로 "더 이상 고칠 곳이 없다"가 되는 것이 아닐까.
   
   
4. 분위기. FET에 처음 끼였을 때, 나도 속도 개선을 위한 여러가지 아이디어를 많이 얘기했다. 학부와 대학원 때, 어떤 문제를 해결함에 있어서, 누군가 아이디어를 던지면 discussion을 하고, 아이디어를 고치고, 검증하고, 같이 찾아보고, 이런 과정이 있었다. 그리고 난 특히나 그런 분위기를 좋아했다.
   FET에서 대부분의 팀원 분들이 나보다 경험과 나이가 많으신 과장, 차장님들이라서 그런지, 어떤 naive한 아이디어를 던졌을 때, 같이 토론하고 검증하기 보다는, "그게 말이 되는 소리냐", "검증은 해 봤냐", "내 생각에 그건 아닌거 같다", "니가 뭘 안다고" 하는 분위기가 좀 아쉬웠음. (물론 아닌 분들도 있었음)
   한 번 (물론 장난스럽게 말씀하셨지만) "쟤 말을 뭘 믿고 그대로 하냐" 라는 말을 듣고 나서는, 도대체 내가 왜 그런 소리까지 들어가며 나서서 아이디어를 내야 하나 하는 생각이 들어서, 그냥 그 뒤로는 조용히 있으면서 시키는 것만 했다. ㅋㅋ-_-
   
   
5. 개발일정. 분명히 말하지만, 아직 개념 조차 제대로 잡히지 않은 아이디어에 대해서, 개발 일정을 요구하는 것은 분명 난센스다. 설사 사장님께서 그런 요구를 하신다고 하더라도, 솔직하게 이건 아직 검토 단계이기 때문에 불가능하다는 대답을 드리는게 맞다.
   분명 상황을 충분히 아시는 분들이고, 아직 우리는 아무런 준비가 되어 있지 않은 상태인데, "rough하게 라도 써야 하지 않겠냐" 라고 요구하시는 건 무리다. 덕분에 우리 팀장님과 과장님은 "어쩔 수 없이" 개발사 담당자가 전화로 5분 동안 고민한 뒤, 말해 준 일정을 바탕으로 진짜 rough한 계획을 세울 수 밖에 없었다. 실제 업체 선정과 프로젝트 검토 과정에서 이 일정을 얼마나 flexible하게 조정할 수 있을지는 모르겠지만, 이미 사장님께 보고된 일정을 뒤집을 수 있을까.
   결국 또 말도 안되는 일정 요구 - 개발자의 과다한 초과 근무 - 낮은 품질의 결과물로 이어지는 전형적인 한국의 대기업/중소 IT기업 사이의 사이클이 반복되지 않을까 하는 걱정이 앞선다.

교훈은 뭐가 있을까?? 아 졸린다. -.- 다음에 적자.