생산성 향상 - 비기는 없다

들어가기 앞서

생산성에 대해서 더 정확히는 생산성을 위해서 많은 것들을 도입하는데 왜 다 실패하는 것인지에 대해서 이야기해보고 싶다. 나는 2016.05 년부터 사회에 나와서 이제 3년 2개월 정도 프로그래밍 경험이 있다. 이런 짧은 경험으로 생산성과 프로세스에 대해서 논하는 게 조금은 부끄럽지만 내 생각을 한번 글로 정리해보고 싶어 이렇게 포스팅을 하려고 한다. 이 글의 전반적인 내용은 나의 실패의 연대기다. 그래서 지극히 주관적이고 개발자 입장에서 생각한 내용이니 충분히 비판적인 시각으로 글을 읽어줬으면 한다. 뻔한 문구겠지만 그래도 이런 실패를 통해서 나는 프로그래밍 능력은 많이 향상되었다. 거짓말 조금 보태서 한 달 단위로 성장하는 느낌을 받았다. 지난 일들은 추억 보정이 되기 때문인지도 모르겠다.

나의 연대기

3년 2개월 경력 치고는 5번의 이직의 경험이 있다. 작은 스타트업에서부터 조금 큰 규모의 스타트업 등 다양하다. 작은 스타트업을 다닐 때 그때 그 당시의 나에게도 해당 기업의 프로세스는 납득하기 힘들었다. 물론 스타트업 초기에서 제대로 된 프로세스를 갖기는 힘들다고 하지만 그래도 프로세스는 납득하기 어려웠다. 그래서 내가 속한 개발팀부터라도 조금씩 프로세스를 가지려 많이 노력을 했었다. 세상에는 코드 리뷰, 테스 코드 도입, 객체지향 프로그래밍, 도메인 주도 개발, 애자일 등등 세상에는 많은 비기가 있었다.

비기는 없다

하지만 비기는 없었다. 물론 내 개인적인 경험에 국한되는 이야기지만 나에게는 비기는 없었고 여러분에게도 높은 확률로 비기는 없을 것이다. 일단 냉정하게 비기가 왜 필요한지부터 점검해야 한다. 비기가 필요한 시점부터 무언가가 크게 잘못되었다는 것이다. 그것은 대부분 종합적인 문제일 것이다. 프로세스, 개개인의 역량, 해당 분야의 전문성, 커뮤니케이션 등등 이런 것을 다 무시한 체 이 어려운 문제를 구원해줄 구원자를 찾는 것이다. 구원을 찾는 거 자체가 이미 구원자(비기) 말고는 답이 없다는 현 상황을 반증하는 것이다.

그게 싫은 것이다.

냉정하게 지금 우리 팀, 우리 회사에 문제점을 정말 냉철하게 봐야 한다. 하지만 그것은 어렵다. 누군가를 비난해야 할 때도 있고, 누군가가 실력적으로 형편이 없어 프로젝트 딜레이가 되는 문제일 수도 있다. 구성원들 간의 커뮤니케이션이 문제일 수도 있다. 이런 것들은 불편하고 어렵다 보니 냉정하게 진단하기 싫은 것이다. 이런 모든 문제를 일단 가리고 외부에서 구원을 찾는다. 그 비기가 우리의 모든 문제를 해결해 줄 것이라 믿고 이렇게 되면 이런 비기의 유혹은 뿌리치기 힘들다. 그리고 같은 실수를 반복한다.

냉정

냉정해져야 한다. 지금 프로젝트가 엉망인 것은 단순히 프로세스만의 문제가 아니다. 무슨 문제가 있다. 그것을 프로세스 문제로 퉁치고 다른 비기를 찾으려 하면 안 된다. 냉정하게 현상태를 분석하고 판단해야 한다.

예를 들어보자 자바 서블릿을 직접 구현해서 웹 프로젝트를 진행하고 있는 팀은 스프링 부트라는 프레임워크를 알게 되었고 이것을 이용하면 웹 프로그래밍이 더 효율적으로 할 수 있다고 판단해서 스프링 부트를 도입했다. 이것은 맞는 말이다 누가 봐도 자바라는 언어 기반으로 웹 프로젝트를 한다면 스프링 기반으로 프로젝트를 안 할 이유가 없다. 하지만 저 팀이 프로젝트를 성공적으로 마칠 수 있을까? 도입하려는 것이 그렇게 좋은 것이라면 왜 우리는 그동안 그것을 도입하지 않았는지를 점검해봐야 한다.

결국엔 비기는 없다.

저 팀에서는 스프링이라는 것이 비기로 느껴질 것이다. 실제로 스프링은 정말 좋은 프레임워크다. 하지만 단순히 스프링 도입으로 이 문제는 해결되지 않는다. 우선 그들은 서블릿을 직접 구현할 정도로 현지 이 생태계를 이해하지 못한다. 절대적인 실력 부족이다. 이게 이 팀의 냉정한 현주소다.(물론 이게 문제가 아니라 다른 것이 문제일 수도 있다 그만큼 본질적인 문제를 찾기는 힘들다.) 이것을 보려 하지 않고 단순하게 비기(스프링)을 도입하려 해서 이 문제를 해결하겠다는 것 자체가 문제이다. 자신과 현재 자신의 팀의 현주소를 냉정하게 판단해보라 이런 상황에서 스프링을 도입해도 결과는 달라지지 않을 것이다. 스프링이란 것 외에 다른 것들을 대입해봐도 마찬가지다. Jira를 통한 이슈 트래킹, Confluence를 통한 문서화, 코드 리뷰를 통한 코드 품질 향상, 데일리 미팅을 통한 업무 공유, 세부 기획을 통한 일감 상세화 등등 이런 것들을 도입하려고 할 때 왜 그동안에 그것을 도입하지 않았나에 대한 회고부터 해야 한다. 그리고 이런 프로세스의 도입 하나로 현재의 문제를 하려는 태도 자체가 지나치게 비양심적인 것이다.

정답은 이거야

그동안 어렴풋이 느껴왔던 문제들을 어렵게 수면 위로 올리고 정답은 이거야를 외치고 특정 프로세스를 도입하는 경우가 많다. 나 또한 이 실수를 수없이 반복했다. 어렵게 수면 위로 올려진 문제들을 프로세스 도입 하나로 모두 해결될 것이라는 행복 회로를 돌리기 시작한다. 이 이슈들은 Back Log에 남지도 않고 이미 완료됐다고 Done 처리하듯이 우리의 사고 속에서 없어지고 다시 수면 아래로 잠든다. 새로운 무언가의 도입으로 우리들의 문제는 해결되지 않는다. 그저 다시 수면 아래로 내려갈 뿐이다.

패배감...

자꾸 진실을 마주하지 않고 비기를 찾고 비기를 연습해서 도입해보고 그것이 또 실패로 찾아오면 개인은 너무 힘들다… 나 또한 많은 것을 노력했지만 진실을 마주하지 않고 비기만을 찾았고 그 결과 수많은 패배를 했다. 개인의 경험은 개인에게는 절대적이다. 이런 패배감을 반복적으로 느끼면 개인은 더 이상 노력하기 힘들다. 이런 패배감 때문에 프로젝트에서 떠나고 싶어진다.

그럼에도 불과하고...

그럼에도 불과하고 개인은 성장해야 한다. 위 같은 상황일지라도 스프링을 도입하고 패배감을 맛보고 성장해야 한다. 어쩔 수 없다. 포기할 수는 없지 않은가. 해당 조직에 있을 때 최대한 많은 노력을 하고 그것으로 발판 삼아 성장해야 한다. 아이러니하게도 이렇게 패배를 통해서 성장했던 것이 내 프로그래밍 실력을 단기간 안에 많은 것을 향상시키기도 했다.

그대가 속한 조직이 패배감을 느끼고 계속 도전할 가치가 있다면, 함께 일하는 동료와 해당 서비스가 매력적이라면, 그래도 조금씩이라도 성장하고 쟁취한다는 피드백이 있다면 그럼에도 불과하고 개인은 기꺼이 비기에 도전한다. 그리고 쟁취할 수 있다고 믿는다.

이직 고려

그대가 주니어라면 조직을 바꾸는 것은 어렵도 힘든 일이다. 하지만 어렵고 힘들 일이니 하지 도전하지 말라는 소리는 절대 아니다. 냉정하게 내가 그 어려운 도전을 할만한 가치 있는 매력적인 회사, 팀, 동료, 서비스 인가 판단해보라. 그것이 아니라면 이직하는 게 맞는다고 본다.

맺는말

이 글을 쓰기 조심스러운 이유 중 하나는 내가 속했던 회사 중에 위에서 언급한 부분에 해당되지 않은 회사도 있었고 그곳까지 비판하는 거 같아 조심스럽다.

또 다른 하나는 외부에서 나는 무언가를 깨달은 것처럼 통찰력 있는 사람, 혹은 그런 척하는 사람으로 느껴지는 것들이 부담스럽다. 나는 평범한 주니어 개발자고 지금도 똑같은 문제로 고민하고 좌절한다. 그래도 성장한 게 있다면 비기는 없고 구원이라는 것은 외부에서 찾지 말고 내부에서 찾아야 한다. 라는 것이다.

그리고 또 내가 도입하려는 것이 대부분 옳은 것이고 그것을 받아들이지 못한 회사, 팀의 문제인 것처럼 보이는 것도 부담스럽다. 확실히 이야기 하지만 나도 무턱대고 비기를 도입하려 했었고 그래서 실패한 것이다. 일차적으로 내 역량의 문제인 것이다.

반복해서 이야기하는 것이지만 중요한 것은 내가 이런 역경과 고난을 해쳐갈만한 가치 있는 회사, 팀, 서비스 인지가 중요하다.