by
Jan 14. 2023
개발자 교체로 해결된다?
개발자의 생각 #25
개발자가 초급이래요
이젠 고급 개발자가
투입되었으니
금방 해결될 겁니다
- 고객의 꿈같은 이야기 -
솔직히 2차개발 때문에 찾아온 외주용역상담을 험담하고 싶지않다. 내게는 좋은 만남의 기회이고 그들이 실패 경험을 들어보면 안스러울 때가 많기 때문이다. 그러나 1년에 분기마다 "이전 개발자가 망쳤어요.."라는 본질을 파악하지 못한 의뢰를 들을 때는 한숨만 나온다.
사건의 본질은
개발자가 아니라 "고객"이기 때문이다.
"개발공정"을 무시하고 "관리"조차 없던
프로젝트에서 개발자는 아무것도 할 수 없다.
자신이 무엇을 했다고 말하는 고객들의 대부분은 "개발공정"과 "관리"를 말로만 했다. 관리시스템을 사용하기 않고(소프트웨어로 공정을 관리한다)도 자기는 말을 했으니 문제가 없다는 식인데, 이럴 경우 개발자를 교체해도 그 이력관리(요구사항, 발생문제, 처리과정)를 파악할 수 없기에 똑같은 시행착오가 답습될 수 밖에 없다.
그리고 막판에 망가진 프로젝트에서 "개발자 교체"가 결코 해결방안이 아니라는 것도 알아야 한다. 실제로는 개발자 교체가 아니라 "개발자 투입"이 되어야 소소한 것이나마 해결이 가능하기 때문이다.
그럼에도 불구하고 교체를 하려고 한다. 다음은 아무리 고객이 개발자(사) 교체를 원해도 만족스럽지 못한 이유를 정리한 것이다.
프로그래밍 스킬과 요구분석은 별 개의 영역
1.
대부분의 고객들이 프로그래밍을 잘하면 "내가 원하는 것"을 잘 만들어 줄 것이라고 믿는다. 이런 식의 대화가 나올 경우, 나는 "동심파괴" 수준의 불쾌한 현실을 말한다.
대표님이 지금 말씀하신 간단한 요구(?)라는 것의 문제점을 비유하자면 "조선시대 화가들에게 코끼리를 그려달라는 것과 같아요" 털도 밋밋하고 튼튼한 발 4개, 긴 코 1개만 바꾸면 된다고 말하면 화가는 아마도 불교신화에 나오는 전설 속의 동물을 그릴 겁니다.
프로그래밍 스킬은 프로그래밍 스킬일 뿐이다. 고객이 요구하는 것은 그것과 무관한 "업무기능"이다. 고객의 요구하는 업무는 어디서 배울 수 있는 것이 아니라 "프로젝트 경험을 통해 학습"하는 것이고, 그 경험 또한 "고객"이 원하는 기능과 100% 일치하지 않는다. 결국, 고객의 요구사항을 파악하기 위해 적지않은 시간이 소요되며 그것을 기준으로 "설계", "고객이 요구사항 인증(confirm)", "할 일", "프로그래밍" 순으로 진행이 되어야 한다.
그 기간은 아무리 오랜경력의 고급 개발자라도 한 순간에 업무를 파악할 수 없다. 기존 개발자의 조력이 없이는 불가능하며 적지않은 시간 "업무를 같이하며" 파악해야 한다. 만약, 교체를 한다면 "처음부터 다시"하는 수순을 밟을 수도 있다.
이전 개발자의 작업을 받을 수 있는 사람이 따로 있다
2.
개발자도 전문 분야가 있다.
이전 개발자가 했던 [업무분야]의 개발자를 대려와야 한다.
아무 개발자나 대려온다고 대체가 되는 것은 아니다.
박피수술을 해야 하는 데
외과 의사를 대려올 수는 없는 것 아닌가?
대체할 개발자가 쉽게 구해지면 좋겠지만, 현실에서는 블랙 프라이데이의 오픈런 하는 느낌이다. 다들 우리 프로젝트를 구원해줄 개발자를 구한다고 울부짖지만 정작 그런 개발자는 눈에 띄지도 않고 눈에 보인다고 한 들 함부로 움직이지도 않는다.
이유는 단순하다.
한 번 망가진 프로젝트에 재투입된다는 것이 얼마나 힘들고 스트레스인지 알기 때문이다. 왠만한 좋은 조건이 아니라면 맡고 싶어하지 않는다.
대체된 순간, 그 때부터 모두가 고생이다
3.
우여곡절 끝에 개발자(사)가 교체된다 치자.
고객의 의도와는 다르게, 또다른 고생이 시작되는 것이다. 바로 "이전에 만든 프로그램을 뼈대부터 바꾸지 않으면 해결불가능합니다!"라던지 "이전에 만든 개발자 환경이 지금은 재대로 돌아갈 수 없는 상황이에요!"와 같은 legacy system과의 충돌문제이다.
소프트웨어가 완벽했다면 카카오같은 거대 회사가 비싼 돈 들여 개발자를 꾸준히 뽑을 필요가 있겠는가? 개발자를 꾸준히 뽑는 이유는 소프트웨어는 시간이 지남에 따라 문제가 발생하고 그로인해 기능과 구조를 수정, 개발해야 유지되기 때문이다.
문제는 초창기부터 만들었던 개발자가 있다면 "만들어왔던 히스토리"를 알기에 "문제파악"을 쉽게 할 수 있고 올바른 방향성을 잡아 줄 수 있다. 그러나 대체된 개발자의 경우, "히스토리, 문제"에 대한 개념이 있을 수가 없다. 결국, 똑같은 시행착오를 경험하게 된다.
개발자가 필요한 회사에서
오래된 개발자의 힘이 막강한 이유는
바로 "히스토리"를 알고
"문제를 바라보는 시각"이 있기 때문이다.
Programing 기술은 너무 빨리 변한다
4.
