brunch

You can make anything
by writing

C.S.Lewis

by Vintage appMaker Sep 26. 2023

인수인계의 중요성

생존형 개발자의 생각 #85


자주 경험하는 2차 개발요청에 대한 시나리오가 있다.


대표가 기존업체나 담당자를 만족하지 못한다.

이미 만들어졌으니 몇 개만 고치면 된다고 말한다.

잘들어보면 대표는 IT에 대한 경험이 전무하다.


문제는 완성(??)된 소프트웨어의 이력관리 따위는 없다는 것이다. 그러면서 하는 말이 “내가 업체 또는 담당자에게 확답을 받았으니 인수인계 문제없다”라고 말한다. 이런 업체는 2차 외주에도 실패할 확률이 매우높다. 대표의 아날로그 의지만 강하고 디지털 시스템이 없는 회사 시스템에서 소프트웨어 개발은 성공할 수 없다. 그래서 되도록이면 말을 짧게 단도직입으로 말한다.


이 상황에서는
개발업체 바꾸어도 소용없다.
"내부관리 시스템"부터 구축해라.
그 다음에
사람을 바꾸던 업체를 바꾸던 결정해라.


인수인계에 필요한 것   


#1 - 기획문서, 소스, 데이터 백업

#2 - 개발환경 세팅 및 시연(문서) - 검증

#3 - 운영에 필요한 담당자 교육

#4 - 장애응대 방안 및 관리시스템 구축(git, jira 등등)


기획문서, 소스, 데이터 백업

소프트웨어 개발은 "팀웍"이 생명이다.

똘똘한 개발자만 있다면 "소프트웨어는 황금알을 낳는 거위가 된다"라고 생각하면 안된다. 적지않은 대표들이 소프트웨어를 “재수좋으면(좋은 개발자를 싼 값에 쓰는) 횡재”하는 일 정도로 여기고 있다. 그럴 때마다 씁슬해진다. 소프트웨어는 “황금알을 낳는 거위”가 아니라 "돈먹는 하마"이다. 개발자 혼자 만들 수 있는 것이 아니다. 서비스 설계, 구조설계, 프로그래밍(코딩), 그리고 데이터 백업까지 여러 공정단계를 거쳐야 한다. 그러다보니 개발자 외에 “기획자”, “디자이너”, “검수자”, “운영자”들이 협업을 해야 한다. 적어도 3명이상의 다른 직종군이 협업을 해야 하는데 “문서가 한 두개 정도로 끝날까?


답변은 "아니다".

기획문서를 시작으로 디자인가이드, 프로그래밍 소스, 개발환경 문서 등등 나열하면 할 수록 생소한 문서들이 “규격”대로 작성되어 있어야 한다. 소프트웨어는 “공학”이다. 공학답게 체계화된 문서가 없다면 “담당자가 사라지는 순간” 소프트웨어도 사라지게 된다.


개발환경 세팅 및 시연(문서) - 검증


소프트웨어 개발에서 가장 중요한 것은 “구조”와 “사용성”이겠지만 개발자 입장에서 가장 중요한 것은 “소스대로 돌아가?”이다. 무슨 말인가 하면 “프로그래밍은 남이 된다고 내가 되지 않는다”라는 것이다. 옆자리에 A가 만들어놓은 소스를 A 노트북에서는 실행이 될 지 몰라도 B 노트북에서는 실행되지 않을 확률이 높다. 바로 소프트웨어를 만드는 개발환경을 구축하지 않았기 때문이다.


그렇기에 인수인계를 받는 과정에서 (1)문서를 검토하고 담당자가 (2)개발환경을 세팅 및 결과물을 내놓아야 (3) “인수인계 확인서”에 날인을 한다. 이런 과정이 없다? 그러면 그 회사는 재대로 돌아가고 있지 않다는 것을 증명하고 있는 것이다.


운영에 필요한 담당자 교육


소프트웨어는 혼자서 돌아가지 않는다. 빌딩에 관리인이 필요하듯, 소프트웨어도 사람의 관리가 필요하게 된다. 그러므로 프로그램이 죽었을 때, 또는 정기적으로 데이터를 백업받아야 할 때, 장애대응에 관련된 매뉴얼이 존재해야 고객서비스가 가능해진다. 이런 내용을 매뉴얼화 하여 운영자 교육을 시켜야 한다. 만약 운영자 매뉴얼이 없다면 “문제발생시” 누가 무엇을 해야 할 지 알지 못하면서 당황하는 경우가 발생한다.


장애응대 방안 및 관리시스템 구축(git, wiki, jira 등등)


서비스는 이력관리가 생명이다. 이력관리는 전산화되어 있어야 하며 이를 통해 장애발생시 심도있는 분석이 가능하다. 결국은 서비스 회사 내에는 이력관리 시스템이 구축되어 있어야 한다.  대부분 2차 외주를 요청하는 회사에는 이런 시스템이 없는 경우가 많다. 담당자의 머리 속에만 있거나 워드 몇 장에 쓴 의미없는 기록들이 존재할 뿐이다. 더 암담한 경우는 대표가 그것을 시스템으로 여기고 자랑할 때이다.




마지막으로 개발회사 입장에서는 “이런 고객”은 처음부터 만나지 않는 것이 상책이다. 상황을 이해시키느라 시간도 오래걸릴 뿐더라 견적을 협의하러 갔다가 컨설팅 및 강의를 하다 오는 경우가 대부분이다. 모든 면에서 좋지 못하다. 심지어 컨설팅 및 강의에 대한 인건비가 고려될 수도 없다. 그래서 지인들의 부탁(자신들과 친한업체 상담)에도 “IT 알못” 업체는 미팅을 하지 않게 된다.


비지니스에서 시간은 돈이다.


배려차원으로 미팅을 하다보면 “기회비용”을 잃어버리며 서서히 망가지게 된다(사소한 시간낭비는 생각보다 치명적이다). 그래서 대형업체는 미팅비용(컨설팅 및 교육)까지 고려해서 고객에게 대략치의 견적을 준다. 인건비 상승 및 견적가 상승은 피할 수 없다. 반면 소규모 업체는 아예 그런 고객을 상대하지 않게 된다. 대부분 손해이기 때문이다.

매거진의 이전글 개발자가 알아서 못해주는 이유
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari