10X 개발자와 POC 함정

Source: Dev.to

10X 개발자를 만나다

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

POC 영웅

10X 개발자와 POC의 관계는 보통 야심찬 기능 요청에서 시작된다. 리드가 POC, 타당성 분석, 사용자 수용 테스트를 제안한다. “하지만 시간이 별로 없어요,” 라고 제품 매니저가 말하고 10X 개발자에게 기대한다: “우리는 이걸 2주 안에 할 수 있죠, 맞죠?”

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

새로운 요청이 들어오고 같은 개발자가 또 다른 프로토타입을 만든다. 이번에는 테스트에 실패하고 해당 기능은 실현 불가능하다고 표시되어 수개월의 개발 시간을 절약한다—또 다른 성공이다.

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

영웅에서 병목으로

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

당신은 “예외 상황을 처리하도록” 만들어졌다고 주장되는 프로토타입이 실제로는 행복한 경로에서도 겨우 동작한다는 것을 깨닫는다. 제품 팀은 프로토타입이 미래 사양을 고려한다고 믿지만, 당신은 현재 사양만을 다룬다는 것을 안다.

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

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

팀 피로와 번아웃

결국 팀 전체가 10X 개발자의 프로토타입에서 남은 조각들을 주워야 한다는 사실에 불만을 품게 된다. 아무도 더 이상 그와 함께 일하고 싶어 하지 않는다. 한때 이례적이던 상황이 기준이 되고, 사람들은 번아웃에 빠지고 프로젝트를 떠나며, 떠날 때마다 프로젝트는 견딜 수 있는 수준에서 완전히 부서진 상태로 전락한다.

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