이 이야기는 2016년 7~9월에 겪은 일입니다.

---

난 멘토링을 해주던 분의 회사로 취업을 했다. 인턴, 계약직이었다. 워낙 멘토링을 해줄 때 잘 대해주던 분이라, 게임 산업이 힘들다는 이야기에도 불구하고 가기로 했다. 사실 1년 전 취업을 준비할 때 최종면접에서 4군데 떨어지고 나니 자신이 별로 없었다. 일단 불러주는 데라도 가서 일해야겠다는 생각이 강했다. 

회사에 들어가서는 후회의 연속이었다. 맡겨진 업무도 내 역량에 적절치 않았다. 

내가 했던 업무는 파이썬으로 짜여진 서버를 스트레스 테스트를 하는 것이었다. 스트레스 테스트에 활용한 툴은 네이버에서 공개한 엔그라인더(nGrinder)였다. 엔그라인더는 자이썬과 그루비를 지원했는데, 회사 서버는 파이썬 기반이었다. 

파이썬을 자바 위에서 쓰기 위해 자이썬을 쓰기로 했는데, 그러다보니 여러 문제가 발생했다. 내가 했던 이 업무의 문제는 3가지였다.  

  • 자이썬 사용
  • 파이썬 토네이도 사용
  • 내부 프로토콜 및 서버 구조 이해


자이썬의 경우 파이썬 2.5까지 밖에 지원을 하지 않았다. 파이썬 2.5은 2006년에 나왔고, 지금과는 문법이 달랐다. 파이썬 2.7로 작성된 코드를 파이썬 2.5로 바꿔야 되었다. 

또한 파이썬  서버 코드는 ctype을 많이 활용 하였는데, 리틀 앤디언 방식이었다.  반면 자이썬은 JVM 기반이기에 빅 앤디언 방식이었기에 전혀 다른 값이 떴다. 이 또한 변환을 해줘야했다. 

자이썬으로 인한 문제는 더 있었다. 사용자가 적은 언어다 보니 구글링해도 나오는 자료가 없었으며, jython으로 검색하면 python으로 검색결과가 자동으로 바뀌었다.  (…. )

에러가 생기면 파이썬과 자바 에러가 섞여 나왔다. 편하게 포팅하세요가 컨셉이었지만 실제는 두 언어의 단점만 섞인 끔찍한 혼종이었다. 

“단순히 파이썬으로 된 코드를 자이썬에 올려서 돌리면 되는 작업”이라고 들었는데 실상은 전혀 달랐던 셈이다.  

자이썬만 이해하면 되는 문제였으면 모르겠는데, 스트레스 테스트를 제대로 하려면 서버 코드를 제대로 이해해야했다. 그래야 어느 부분이 서버의 병목 구간인지 확인하고 개선할 수 있으니깐. 당시 서버는 파이썬 토네이도로 짜여져 있었는데 많이 쓰는 프레임워크가 아니다 보니 참고 자료가 거의 없었다. 구글을 뒤져도 쓸만한 튜토리얼이 없었다.

결국 2가지 방식으로 문제를 해결하게 되는데, 둘 다 개발 방식의 변화와 관련이 있다. 

첫번째는 내부 코드 (프레임 워크 코드 분석)을 보는 방식을 쓰기 시작했다. 

기존에 난 코드를 짤 때 남이 만든 2차 가공자료를 많이 참고 했다. 책, 블로그 등의 튜토리얼의 도움을 많이 받았다. 

하지만 당시엔 참고할 자료가 없었기에 프레임워크 내부를 확인하면서 개발을 했다. Command + M (메소드 선언을 확인하는 단축키)를 계속 쓰다보면   더 들어갈 데가 없기 마련이다. 나는 거기서 부터 확인을 했다. 

다행히도 토네이도 코드 구현은 깔끔했고, 서버팀이 만들어 놓은 코드도 수준이 있었다. 프레임 워크를 세부 구조를 이해하는 건 확실히 실력에 도움이 되었다. 그렇지만 진전이 빠르지는 않았다. 아침마다 하던 개발 회의에서 속도가 느리다고 지적을 당하기 일쑤였다. 

CTO, 서버 팀장에게 도움을 청 하였는데, 역량이 모자라서 그런 것이니 더 노력 하라는 이야기만 들었다. 

두번째는 회사내 뛰어난 개발자의 방식을 카피한 것이다. 
회사에는 5년차 개발자 분이 있었는데, 두루 인정을 받았다. C++, 파이썬 모두에 능하고, 서버 팀의 실질적인 에이스였다. 

내가 진전이 느리자 그 분의 도움을 받아보라는 이야기를 들었다. 

그 분은 내가 일주일동안 끙끙 거리던걸 하룻밤에 해결 하였다. 

나는 놀라서 어떤 식으로 작업 했는지, 관찰하고 물었다. 

그 분은 큰 문제를 작게 쪼개서 해결했다. 병합 정렬을 업무에 적용했다고 할까?

서버 코드는 12~13만줄 정도 되었는데, 나는 그 코드를 전부 다 포팅을 시도했는데, 그러다보니 중간에 에러가 나면 하나도 돌아가지 않았다. 

반면 그 분은 필요한 코드 200줄을 일단 다른 IDE로 옮겨서 테스트하고, 검증된 코드를 본래 코드에 넣었다. 그러니 작업 속도도 빠르고, 에러가 생기는 일이 없었다. 

나는 A -> F로 바로 가려고 했다면, 그 분은 A,B,C,D,E,F로 나눠서 한 것이다. (난 A에서 F로 가려고 했다는 것도 몰랐고,  A와 F 사이에 그 많은 단계가 있다는 것도 몰랐다)

난 그 분의 방식을 따라해 보았다. 그러자 생산성이 대단히 좋아졌다. 

그 뒤에 안드로이드 개발을 할 때도, UI를 제외한 로직은 다른 IDE에서 테스트하고, 안드로이드로 옮겼다. 안드로이드 개발할 때 가장 많이 소요되는 시간은 빌드 시간인데, 분리하는 방식을 통해 이 낭비를 줄일 수 있었다. 

평일에는 10시 ~ 23시까지 개발하고 , 주말에도 개발하였다. 결국 어느정도 진전이 보이기는 했지만 스트레스가 너무 심하였다. 인정 받지 못하는 상황과 답이 없는 자이썬 사용은 고통이었다. 스트레스 테스트 업무는 5주 조금 넘게 진행하고, 웹 파트로 넘어갔다. 회사 내부에서 쓰이는 관리 페이지를 만드는 일이었다. 

기존의 스트레스 테스트 업무는 위메이드 출신 13년차 개발자에게 넘겼다. 나에게 노력이 부족하니 네트워크를 더 공부하라고 했던 사람이다. 결과는?
매일 아침 회의마다 “이거 생각보다 쉽지 않네요”를 연신 이야기하였다. (내가 속으로 고소해 하지 않았다면 거짓말일 거다)

관리 페이지 만드는 업무는 정말 쉬웠고, 매일매일 진전을 회사 아침 회의때 보여주니 인정도 받았다. 다만 회사에 대한 회의감은 갈수록 커져갔다. 

이 회사는 좀 더 일할 수 있었지만 초기 계약 기간(2개월)이 끝나고 떠났다. 

<!--?xml version="1.0" encoding="UTF-8"?-->

잠깐이었지만 이 회사를 다니며, 개발자에게 어떻게 업무 배정을 해야 좋은지, 사람을 볼 때 무엇을 주의해야 되는지 배웠다. 사회 생활을 하며 만난 사람이 자신에게 이득이 되지 않는 걸 제안할 리 없다는 걸 몰랐다. 그 뒤 사람들이 먼저 제안을 하면, 저의가 무엇일까 한번 더 생각해보고는 한다.  프레임워크를 가져다 쓰는 방식에서 이해하고 응용하는 방식으로 바뀐 건 수확이었다. 다만 이 회사에서의 경험은 다시 하고 싶지 않은 경험이었다.