개발 이슈가 대부분 그렇지만, 기술적인 측면보다 의외로 의사소통 문제 같은 인적 요소가 원인이 될 때가 많습니다. 캐리 플리첼은 "왜 개발자는 잘못된 기술 선택을 밥 먹듯이 하나?"라는 제목의 블로그 게시글에서 그 원인을 다섯 가지로 분류했습니다. 하나씩 알아보겠습니다.

이 글은 왜 개발자는 잘못된 기술 선택을 밥 먹듯이 하나? 와 Optimizing Java 라는 서적을 참고하여 작성하였습니다.

지루함

개발자는 대부분 자기 역할에 지루함을 느끼고 뭔가 새롭고 도전적인 일을 찾아 같은 회사 또는 아예 다른 곳으로 떠날 궁리를 하는 사람도 있습니다. 하지만 사내에 딱히 마땅한 기회가 없거나 다른 회사로 이직하는 게 여의치 않을 때도 있겠죠.

물론, 지루한 일상을 잘 참고 견딜 뿐만 아니라 외려 더 쉽고 편한 삶을 추구하는 개발자도 있습니다. 어쨌든, 개발자의 지루함을 프로젝트에 여러 가지로 해약을 끼칠 수 있습니다. 일례로, Collections.sort() 한 줄이면 될 것을 직접 퀵소트 같은 정렬 알고리즘을 구현해 필요 이상으로 복잡하게 코딩하는 개발자가 있습니다.(제가 그랬습니다..ㅜㅜ) 지금껏 알려지지 않은 기술로 컴포넌트를 제작하거나, 맞지도 않은 유스케이스에 억지로 기술을 욱여넣는 등 여러 가지 방법으로 지루함을 표출하기도 합니다.

실제로 저도 파이썬 관련 개발을 했을 때 sort() 함수를 쓰면 될 걸 괜히 뽐내고 싶어서 퀵정렬이나 계수정렬을 사용한적이 있었습니다. 빅오 표기법 기준으로 퀵정렬보다 파이썬 내장 함수인 sort()가 더 빠르다는 걸 알면서도요.. 반성합니다

이력서 부풀리기

지루함 때문에 기술을 과용하는 개발자가 있는 반면, 본인의 이력서를 과대 포장할 구실을 찾는 개발자도 있습니다. 구직 시장에 다시 뛰어들 즈음, 어떻게 하면 자기 연봉과 몸값을 높일 수 있을까 골몰하는 거죠. 잘 굴러가는 팀치고 이런 생각을 하는 팀원이 한 사람도 없는 경우는 드물겠지만, 어쨌든 프로젝트를 불필요한 방향으로 끌고 가는 선택의 발단이 될 수 있습니다.

개발자의 지루함, 이력서 부풀리기 탓에 불필요한 기술을 자꾸 덧댄 결과는, 기존에 개발자가 더 좋은 회사로 이직한 후 아주 오랫동안 시스템에 지대한 영향을 미치게 될 겁니다.

또래 압박

팀원들이 기술을 결정할 때 관심사를 분명히 밝히지 않고, 서로 충분한 논의 없이 진행하면 쓰디쓴 결과를 맛보기 쉽습니다. 가령, 선배 앞에서 가급적 실수 안 하려는(가면 증후군) 신입 개발자, 특정 주제를 자지가 잘 모른다는 사실을 두려워하는 개발자가 있습니다. 경쟁심이 불타오르는 팀 분위기 속에서 개발이 광속으로 진행되는 듯 보이고자 제대로 사정을 따져보지도 않고 섣불리 중요한 결정을 내리는 것도 또래 압박의 아주 고약한 형태입니다.

이해 부족

지금 사용하는 툴의 기능도 온전히 알지 못하는데 무턱대고 새로운 툴로 문제를 해결하려는 개발자가 있습니다. 새로 나온 멋진 기술이 어떤 태스크를 수행할 때 아주 좋다는 소문이 퍼지면 사람 마음이란 게 기울어지게 마련이죠. 하지만 기술 복잡도를 높이는 것과 현재 툴로도 할 수 있는 것 사이의 균형을 잘 맞추어야 합니다.

예를 들어 하이버네이트는 도메인 객체와 DB 객체 간 변환을 단순화하는 절호의 방법처럼 보입니다. 하이버네이트를 수박 겉핥기 식으로 아는 개발자는 다른 프로젝트에서도 하이버네이트를 쓰더라, 하는 경험담을 들려주며 이 기술이 적합하다고 쉽게 단정합니다. 이처럼 이해가 부족한 상태에서는 하이버네이트를 너무 복잡하게 사용하게 되고 결국 운영 단계에서 회복 불가한 중단 사태를 맞이할 수도 있습니다. 데이터 계층을 전부 간단한 JDBC 호출로 바꾸면 개발자는 자신이 익숙한 분야라서 유연하게 대처할 수 있겠죠. 필자는 하이버네이트를 강의하면서 딱 이런 사례를 경험한 수강생을 만났습니다. 그는 하이버네이트 때문에 결딴난 애플리케이션을 복구하려고 필자의 강의를 들으면서 열심히 하이버네이트를 연구했지만, 결국 하이버네이트를 걷어내느나 고스란히 주말을 바쳐야만 했습니다. 정말 처량하기 그지없죠.

오해와 있지도 않은 문제

문제 자체가 무엇인지 제대로 이해하지 못한 채 오로지 기술을 이용해서 문제를 해결하려는 개발자도 있습니다. 설령 그렇게 해서 성공한들, 성능 수치를 측정도 안 해보고 어떻게 성공을 장담할 수 있을까요? 성능 지표를 수집/분석해야만 비로소 문제의 본질을 정확히 이해할 수 있습니다.

안티패턴을 예방하려면 팀원 모두 참여해서 기술 이슈를 활발히 공유하는 분위기를 적극 장려해야 합니다. 아직도 뭔가 불분명하다 싶으면 먼저 사실에 근거한 증거를 수집하고 프로토타입을 만들어 조사합니다. 그래야 팀이 올바른 방향으로 나아갈 수 있겠죠. 최신 기술이 아무리 좋아 보여도 프로토타입을 만들어 보니 기대에 미치치 못하면 보다 정확한 정보를 근거로 팀이 결정을 내리는 데 도움이 될 것입니다.

맺으며

너무 제 이야기인것 같아서 읽다가도 진짜 뜨끔뜨끔 많이 했네요. 5개중에 5개 다 해당됩니다... 반성합니다.

다른 개발자분들은 어떠신가요? :)

Conference 왜 개발자는 잘못된 기술 선택을 밥 먹듯이 하나?

Optimizing Java(O'REILLY, 한빛미디어)

출처: https://kingofbackend.tistory.com/129 [King of Back-end]