이 글을 쓴 계기
개발과 관련된 콘텐츠를 주로 올리는 포프TV 라는 유투브 채널에서 클린코드 때문에 취업 실패한 썰 이란 제목의 영상을 보게되었다.
어그로성 제목으로 인해 거부감이 들 순 있지만, 개인적으로 정리해 본 영상의 요지는 무조건적인 기술의 수용에 대한 부작용에 대하여 말하고 있는 것 같았다.
개인적으로 영상을 보면서 불편한 감정을 느끼면서도, 공감가는 내용도 있어서 이를 잘 순화시켜서 정리해보려고 한다.
비판적인 자세로 기술 수용하기
클린코드, 객체지향, TDD, DDD 간혹 이런 단어를 보면 치를 떨고 비난하는 사람들을 종종 볼 수 있다.
반대로 위와 같은 도구나 개발 방법에 대해 굉장히 긍정적으로 찬양하며 좋은 개발자라면 반드시 익혀둬야 하는 기술로 보는 사람도 있다.
무조건적으로 비난하는 것도, 반대로 무조건적인 찬양도 협업을 위한 건설적인 토론에는 아무런 도움이 안된다고 생각한다.
나는 기술 서적을 고를 때, 극한의 효율을 위해 이미 잘 알려진 기술 서적(클린코드, TDD By Example, Effective Java …) 을 위주로 보는 편이다.
책을 피기도 전에 그 책이 유명하다는 사실에 지배되어 반사적으로 긍정적인 평가를 하며 책을 읽어나가곤 한다.
그래서 종종 책을 읽고나서 그 책에 나오는 내용이 진리인 양 생각하는 경향이 있는데, 나중에 되돌아보면 날카롭게 비판하는 것을 보면
무조건 진리로 받아들였던 내가 부끄러워지는 경우가 있다.
클린코드로 예를 들면, 책의 내용에는 협업을 위해 실제 경험을 바탕으로 깨끗한 코드를 작성하는 것이 얼마나 중요한지에 대해
그리고 그 방법에 대해 자세하게 설명하고 있고, 개인적으로 매우 흥미롭게 읽었다.
GoodBye, Clean Code - Dan Abramov를 보면 클린코드에 얽매여있을 때 오는 부작용에 대해 경험한 바를 잘 설명하고 있다.
위 글의 내용을 좀 정리하자면
“클린코드에 나오는 내용에 따라 중복제거를 했지만, 동료 개발자들과 논의 없이, 리팩토링을 고려하지 않고 반사적으로 적용했다”는 것이 잘못된 적용이었다고 말하고 있다.
클린코드를 보다 보면 ‘프로그래밍은 사회 활동이다.’ 라는 구절이 있다. 클린코드의 저자인 로버트 C. 마틴도 협업을 전제로
서로 읽기 좋은 코드(이름 잘 짓기, 함수 쪼개기 등등 …)가 가져다주는 긍정적인 면에 대해 이야기 하고 있는 것이다.
클린코드를 비롯한 많은 기술들을 나의 업무에 적용시키기 전엔 반드시 비판적인 자세로 수용해야 한다.
새로운 기술에 대해 학습한 후, 이를 나의 실제 업무에 적용시키기 전에
그 기술을 적용함으로써 얻게되는 장점과 단점에 대해 반드시 생각해봐야 한다.
‘적용했을 때 오는 장점이 훨씬 많다’라고 판단이 되면,
동료 개발자들을 잘 설득시키기 위해 그 기술에 대해 제대로 알아야 한다.
이런 과정이 없다면, 단순히 입 터는 개발자가 될 수 밖에 없다.
생각해보자
최근에 이직을 하게 되면서
- ‘어떻게 팀에 자연스럽게 녹아들 수 있을까?’
- ‘빠르게 팀의 개발 업무에 적응하여 도움이 되고싶다.’
위와 같은 생각이 들었다.
이번 글을 작성하면서, 내가 진리로 받아들였던 많은 기술들에 대한 좋은 비판글을 많이 찾아보게 되었는데,
가장 중요하게 생각하는 바는 ‘협업’이었다.물론 아무 논리적 근거 없이 비난하는 사람도 많았다.
앞으로 회사에서 동료들과 같이 일하면서 항상 ‘협업’이란 키워드를 염두해 두고 개발해야겠다는 생각이 들었다.