[번역] 최악의 개발자

Alexander Mikhailian의 글 "The Worst Kind of Programmer"를 번역한 글입니다.

지난 25년 간 개발자로 일하며 업계에서 발생하는 많은 문제가 특정 개발자 유형으로부터 발생한다는 것을 알게 됐다. 지금부터 두 명의 개발자로 인해 붕괴될 뻔한 프로젝트 이야기를 해보겠다. 둘 중 한 명은 프론트엔드 리드 개발자였고, 다른 한 명은 백엔드의 리드 개발자였다. 이 둘은 비지니스 요구조건이 구체화되기 전부터 각자 일로 바쁜 상태였다.

프론트엔드 리드 개발자는 NX와 RX를 비롯한 트렌디한 테크 스택을 사용하는 앵귤러 모노레포를 구성했는데, 사내 개발 스택으로는 NX를 활용하기 어려웠고, 그래서 더 열심히 인프라 문제를 해결해 나갔다. 최종적으로 구성된 환경은 일반적인 앵귤러 프로젝트와는 전혀 다른 모습이 되었다.

백엔드 리드는 사내 가이드라인에 맞춰 스프링부트 프로젝트를 구성하긴 했으나 Vavr 라이브러리와 복잡한 관계의 JPA 엔티티 를 함께 추가했다. 거기에 스프링빈/써드파티 validation 라이브러리 그리고 최신 테스팅 프레임워크를 추가했다.

나머지 팀원들은 이 둘을 바라보기만 할 뿐이었다.

몇 달이 지나고, 비지니스 요구조건이 밀려들기 시작했다. 빈 껍데기 상태인 프로젝트만으로 이미 너무 복잡해 팀원들이 비지니스 요구조건을 쳐낼 수 없었기 때문에 개발 리드 두 명이 복잡한 작업 대부분을 처리하며 작은 작업 티켓만 팀원들에게 분배하였다. 두 명의 작업량이 다른 팀원 모두의 작업량을 합친 것보다 더 많았다. 주니어 개발자들이 다음 태스크를 물어보면 API 디자인 혹은 테스트와 같은 "덜 중요한 일"만 주어졌다.

그리고 돌연 프론트엔드 리드가 새로운 프로젝트를 찾아 퇴사했다. 그 뒤로 시니어 프론트엔드 개발자 몇 명이 프로젝트를 맡았지만 오래 가지 못했다. 주니어 개발자들은 제대로 일을 할 수 없었다.

백엔드 리드 개발자의 작업량은 더 크게 늘었다. 간단한 CRUD 작업처럼 보이는 작업에도 주말까지 긴 시간 작업이 이어졌다. 하지만 복잡한 프로젝트 구조로 인해 작업량은 줄지 않고 늘어만 갔다. 몇 달이 지나 백엔드 리드 개발자도 퇴사를 했고, 팀은 비지니스의 압박 속에 지속적으로 낮은 생산성으로 고통 받았다.

어느덧 Vavr 객체가 null 비교에 쓰이고, 타입스크립트 프로젝트에 일반 JS 코드를 섞을 정도로 코드 쿼리티가 떨어져 버그 투성이 프로덕트를 배포하는 것도 겨우 해낼 지경이 되었다. 그럼에도 아무도 프로젝트를 처음부터 다시 작성할 수는 없었다. 코드 작성 비용과 퇴사율이 높아만갔다.

이 이야기가 익숙하게 들리는가?

적어도 나한테는 그렇다. 온라인 미디어부터 공공 서비스 프로젝트에 이르기까지 아마 수십개의 프로젝트에서 비슷한 일이 벌어질 것이다. 내가 묘사한 개발자들은 업계에서 최고의 개발자로 불리곤 하지만 나는 그들을 최악의 개발자로 생각한다. 그들의 특징은 다음과 같다:

1. 추상적인 문제 해결에서 만족감을 얻는다

뛰어난 수학 실력, 엄청난 리트코드 문제 풀이 실력, 십자말풀이나 퍼즐을 즐기는 사람들은 실생활에 유용하지 않은 추상적인 문제 해결을 더 즐긴다. 그들은 보통 결과보다 과정에 더 집중한다.

2. 긴 시간을 코딩에 사용할 수 있다

젋고 건강해야 오랜 시간을 코딩에 사용할 수 있다. 집과 가정이 있거나 손목 터널 증후군에 시달린다면 이런 부류와는 거리가 멀다.

3. 소프트웨어 엔지니어링에 대한 열정

똑똑한 개발자는 회사 프로젝트에 자신이 좋아하는 기술을 엮을 방법을 고민한다. 비지니스 요구조건을 구현하는 것은 지루하다. 그러니 모두가 열광하는 최신 개발 기술을 조금 접목하면 어떤가? 최신 기술은 이력서에도 도움이 된다.

4. 나르시시즘과 자만심

이 분류의 개발자는 20대 후반에서 30대 초반의 젋은 개발자들이 많다보니 큰 성취를 이루며 많은 칭찬을 받아왔고, 비판에 직면한 적이 적다.

그래서 아직 더닝 크루거 효과를 경험할 일이 적을 것이다.

이들을 대하는 효과적이지 않은 방법

매니저에게 호소하는 일은 큰 도움이 되지 않는다. 매니저는 일반적으로 개발 직군이 아니고, 이들 부류는 고성과자인 경우가 많기 때문이다. 이들의 성과는 크게 눈에 띄지만 팀에 미치는 영향은 그렇지 않다.

이들에게 직접 말하는 것 또한 효과적이지 않다. 이들의 개발적인 결정에 대해 비판하면 경청하는 것처럼 보이지만 소 귀에 경읽기일 뿐이다. 경력이 짧은 팀원들의 지적으로는 이들의 개발 결정을 바꿀 수 없다.

우리가 할 수 있는 것

문제를 해결하는 첫 단계는 문제가 있다는 것을 인식하는 것이다. 두 번째는 모든 소프트웨어가 팀 작업을 통해서만 작성될 수 있고, 모든 팀원이 쉽게 작성할 수 있어야 한다는 것이다. 놀랍게도 아래 나열할 최신 엔지니어링 기술은 자칭 "최고의 개발자들"로 인한 문제를 해결하기 위한 것들이다:

1. Golang이나 Lua 또는 이와 유사한 단순한 프로그래밍 언어

고 언어는 모든 것을 최대한 단순하게 유지하려고 하며,수단보다는 목적 그 자체에 더 집중한다. 이는 Rust 언어와는 상반되는 특징이다. 지금 고 언어는 날로 번성하고, Rust는 그렇지 않다. 이는 Rust 언어가 언어의 기능 그 자체에 집중하고 이를 기반으로 작성되는 결과물에 집중하지 않기 때문으로 볼 수 있다.

2. 스크럼

스크럼을 통해 각 팀원이 서로를 교체할 수 있는 상태로 유지할 수 있다. 어떤 영역에 대해서는 좀 더 전문성을 가지겠지만 팀원 모두가 프로젝트 전반의 태스크를 처리할 수 있어야된다. 스크럼을 활용하는 환경에서는 일부 팀원에 의해 도출되는 복잡한 솔루션보다는 모든 팀원이 이해할 수 있는 단순한 솔루션을 사용하는 경우가 많다.

3. 데브옵스

똑똑한 개발자들은 보통 한정적인 환경에서 일하는 경우가 많다. 복잡한 C++ 혹은 스프링부트 개발자가 되기는 쉽지만 데브옵스 환경 아래에서는 모두가 제너럴리스트가 되기 마련이다.

서버나 클라우드 설정을 변경하고, 모니터링 환경을 구축하고, 배포하고, 파이프라인을 만지다보면 너무 많은 기술을 알아야하기 때문에 가장 똑똑한 개발자조차 처음보는 기술을 다루게 된다. 그런 환경 아래에서는 실력이 조금 부족한 팀원을 더 잘 이해할 수 있다.

마치며

최고의 개발자는 최악의 개발자가 될 수 있다.