10X 개발자와 POC 함정

Source: Dev.to

10X 개발자를 만나다

내 웹 개발 경력에서 나는 세 개의 서로 다른 프로젝트에서 세 명의 “10X”(또는 “크랙드”) 개발자를 만났습니다. 그들은 업무에 있어 놀라운 사람들입니다: 스프린트당 팀 전체가 처리한 티켓 수보다 더 많은 티켓을 처리하고, 하루에 12시간 이상 일하며, 주말을 건너뛰고, 거의 휴가를 쓰지 않으며, 가장 중요한 것은 일주일이나 이주일 안에 개념 증명(POC)을 제공할 수 있다는 점입니다—이것은 영원히 저주받은 것처럼 보이기도 합니다.

POC 히어로

10X 개발자와 POC와의 관계는 대개 야심찬 기능 요청에서 시작됩니다. 리드가 POC, 타당성 분석, 사용자 수용 테스트를 제안합니다.

“하지만 우리에게는 시간이 별로 없어요,” 라고 제품 매니저가 말하고 10X 개발자에게 묻습니다: “우리는 이걸 2주 안에 할 수 있죠?”

개발자는 2주 동안 매달려 “충분히 좋은” 프로토타입을 전달합니다. 테스트를 통과하고 메인 프로젝트에 병합되며, 해당 기능은 성공으로 간주됩니다.

새로운 요청이 들어오고 같은 개발자는 또 다른 프로토타입을 만듭니다. 이번에는 테스트에 실패하고, 해당 기능은 비현실적이라고 판단되어 몇 달의 개발 시간을 절약합니다—또 다른 성공입니다.

시간이 지나면서 스프린트마다 10X 개발자는 점점 더 많은 POC 작업을 할당받습니다. 결국 버그 수정, 개선, 업그레이드, 유지보수는 하지 않게 되고, 오직 POC만 만들게 됩니다. 이제 모든 크고 작은 기능마다 POC가 필요하고, 10X 개발자가 이를 담당합니다.

히어로에서 병목으로

POC 작업이 쌓이면서 개발자는 각 프로토타입에 실제로 할애할 시간이 줄어듭니다. 품질은 “충분히 좋음”에서 겨우 동작하는 수준으로 떨어지고, 이해하기 어려운 쓰레기 같은 코드가 등장합니다—유지보수가 악몽이 됩니다. 프로토타입이 병합되면 개발자는 다음 POC로 넘어가 현재 기능은 미완성 상태로 남깁니다. 그 작업은 종종 팀의 다른 사람에게 재배정됩니다(때로는 당신에게).

당신은 “예외 상황을 처리하도록” 만들어졌다고 생각했던 프로토타입이 실제로는 행복한 경로에서도 겨우 동작한다는 것을 깨닫게 됩니다. 제품팀은 프로토타입이 미래 사양을 고려한다고 믿지만, 당신은 현재 사양만 다루고 있다는 것을 알고 있습니다.

개발자는 실제 프로젝트 작업과 점점 멀어지고, 모든 것이 녹색 필드 프로젝트인 영원한 POC 세계에 살게 됩니다. 그들의 시스템은 절대 고장 나지 않으며, 언제나 다른 사람의 잘못된 코드가 문제이고, 10개의 추가 POC가 기다리고 있기 때문에 고칠 시간이 없습니다. 이제 깨진 조각들을 고치는 책임은 당신에게 넘어갑니다.

그들은 한 분기 안에 팀 전체가 1년 동안 만든 것보다 더 많은 기능을 출시합니다. 그 사이에 당신은 프로토타입을 안정화하고 프로덕션에 올릴 시간이 부족합니다. 10X 개발자는 이미 “프로덕션 준비 완료”라고 확신하지만, 그 “천”에는 여러 구멍이 있습니다.

팀 피로와 번아웃

결국 팀 전체가 10X 개발자의 프로토타입에서 조각을 줍는 것에 불만을 품게 됩니다. 더 이상 그들과 함께 일하고 싶어 하는 사람이 없습니다. 한때 예외였던 사람이 기준이 되고, 사람들은 번아웃에 빠지고 프로젝트를 떠나게 됩니다. 떠나는 사람이 늘어날수록 프로젝트는 견딜 수 있는 수준에서 완전히 부서진 상태로 전락합니다.

번성하던 코드베이스와 활기찬 팀은 황량하고 잊혀진 땅이 됩니다.