나는 약 2년 4개월 가량 다녔던 회사를 그만두었다.
공장에서 생산된 제품을 검사하는, 머신비전(a.k.a 영상처리) 기업이였다.
왜 퇴사를?
한마디로 정리하자면 '개발 문화'의 부재였다.
1. 문서화
어떠한 문제가 발생하거나 새로운 시도를 할 때 그 과정을 정리해 둔다면 다른 사람이 유사한 문제에 봉착했을때 해결에 들이는 수고를 효과적으로 줄일 수 있을 것이다. 기술 블로그가 이러한 맥락이지 아니한가?
트러블슈팅뿐 아니라 라이브러리에서 어떤 기능들을 제공하는지 혹은 인수-인계 시에 작성할만한 최소한의 문서 등.. 무엇 하나 관련 문서는 관리되지 않았고 오로지 인적자원만으로 관리되는 상황이였다.
2. 레거시 코드
함수 하나가 1천 라인이 넘고 1만에 가까운 클래스도 있더라.
10년이 넘는 기간동안 축적된 코드 베이스였는데
좋게 말하면 검증된 코드겠지만 이를 유지보수해야하는 입장에서는 리팩토링의 중요성을 체감할 수 있었다.
3. 형상관리 및 유지보수
일단 git과 같은 VCS를 사용하지 않았다.
프로젝트를 폴더째로 압축해서 넘버링하고 보관하다 문제가 발생하면 compare 프로그램으로 라인 단위로 비교하면서 문제 발생지를 추론한 뒤 부분롤백하는 식이였다.
심지어는 최신버전의 관리조차 제대로 되지 않아서 구버전에서 일부 코드만 업데이트된 채 현장에 적용되는 식의 문제도 경험했다.
4. 개발 프로세스 및 통합
코드에서 문제가 발생해도 이를 해결하기 위한 비용(=시간)이 과도하게 소모되었으며 재발방지대책 또한 없었으며 이는 여타 개발팀 또한 동일했다.
무엇보다 가장 큰 문제라고 여겼던 부분은, 개발팀이 총 3팀인데 각 개발팀의 상부 라이브러리와 하부 프로젝트 구조부터 프레임워크까지 달랐기 때문에 팀 간 개발자 인력 지원 역시 제한되었다. (필요성에 의한 것이 아닌 단순히 익숙함에 의한 파편화였다.)
지금까지 상술한 것과 같이 적지 않은 기술부채를 부담하고 있었는데 이를 해결하려는 자구적 노력이 희박한 것으로 보여졌으며 이에 따라 SW기업인 만큼 지속 가능하지 않다는 결론을 내렸다.
해결하기 위한 개인적인 노력
프로젝트의 구조를 이해하기 위해 프로젝트의 클래스 다이어그램을 시작으로 객체 관계와 메시지 통신 프로세스등을 정리하며 배운 것이 많았다. 퇴사할 시점에도 인수&인계를 위해 그동안 작업했던 내용을 최대한 문서화하여 전달하였다.
직접 담당했던 프로젝트의 경우에는 기존 프로젝트 소스를 참고하되, 여러 전역변수와, 그와 관계된 함수를 필요에 따라 클래스화하거나 추상화 및 상속 등 중복 코드를 줄이면서 객체 간 관계를 맺어주었다. 또한 언어 표준으로 지원하는 기능은 대체하기도 하였다.
그리고 git을 사용하며 배운것을 정리하고 가이드로 작성하여 사내에 배포하였다. 이는 개발팀의 구성원들이 VCS 에 관심을 갖고 실제 프로젝트에 사용하는 성과를 거두기도 했다.
재직 기간 중 배운 것
이슈 트래커, 코드 리뷰, 문서화, VCS, 리팩토링 등 당연하다고 생각한 것들의 부재가 어떠한 문제로 이어지는지 그 필요성을 절감하였고 이러한 환경이 구축되고 문화화되는것의 중요성을 배웠다.
퇴사 이후의 방향성
나는 내가 생각했던 것보다 개발 환경과 문화를 신경쓴다는 사실을 깨달았다.
이후 재취업을 할 때는 구인 시점에 코드 테스트 혹은 과제 테스트를 진행하며 git과 같은 vcs를 사용하는 것을 당연하게 여기는, 개발 환경 및 문화를 보유하는 기업에 합류하고자 한다.
환경을 스스로 조성하는 첫걸음으로써 개발 블로그를 만들었고 첫글로는 계기가 된 회고록을 작성하였다.
