박가사탕
2019-04-10 02:32:26
31
5114

인수인계가 왜 불가능한지에 대하여..


"프로그래머 장점"글의 파생 글입니다.

제 경험이 세상 만물의 이치가 아님은 자명합니다.

너무 믿지도 말고 너무 배척하지도 말고 적당한 거리에서 봐주십시요.


프로그래머의 소스코드는 "사실상" 인수인계가 불가능합니다.

지금부터 제 주장을 찬찬히 설명해 드리겠습니다.


일단 양적인 측면입니다.

만약 책을 쓰는 사람과 그 책을 읽는 사람이 있다고 치면

책을 쓰는 속도가 읽는 속도보다 빠르면 어떻게 되겠습니까?

읽는 사람은 결국 쓰는 사람의 생산력을 모두 소비하지 못합니다.


소스코드는 압축된 언어로 쓰여진 일종의 논리적 "글"입니다.

그 소스코드란 글을 쓸 때를 잘 생각해 봅시다.

지금 제가 글을 써내려가듯이 아래쪽으로 주욱 쓰게 되나요? 노노.

마치 찰흙을 빚어 공예품을 만드는 것처럼

점진적으로 여기저기를 붙여서 결과를 완성해 냅니다.


프로그래머는 결국 작고 큰 덩어리를 점진적으로 대상에 붙여

복잡한 단계의 논리의 고리를 완성해가는 기계입니다.

가끔 완성된 설계의 복잡성과 결합도를 보고 깜짝 놀랄 때가 있습니다.

주어진 상황을 따라 감각적으로 어딘가에 붙이고 조이고 병합하고 분리했더니

그러한 촉각에 의한 선택들이 모여서 꽤 그럴싸한 새로운 설계가 도출되는 것.

마치 하나의 프로그래밍 언어가 꼴랑 몇십가지의 명령구문에 의해

구성되는 것처럼, "이럴 때는 이 방식이 더 낮다는" 개발자의 감각적인 선택이

모여 거대한 질서가 만들어지는 겁니다.


그렇게 완성된 결과인 소스코드를 "위에서 아래로" 읽어 나간다구요?

소스코드를 붙여나가는 도중에 보여지는 90%의 노하우가

이미 사라져 버렸습니다. 그러나 원 개발자는 압니다.

자신의 습관과 방식, 선택지들을 잘 알고 있으니까요.


즉, 쓰기속도가 읽기속도보다 빠른것도 문제이고.

제작방식과 읽기방식이 다른 것도 문제이며

진정한 레시피는 최적화 과정에서 사라져 버렸다는 것도 문제입니다.


또 다른 측면,

극단적으로 절대 해석하지 못하는 소스코드를 만들어 내는 방법이 있습니다.

해싱이라는 기법을 아실 겁니다. CRC/MD5/SHA같은 겁니다.

해시값으로는 절대 원본을 알아낼 수 없습니다.

특정 알고리즘의 범위값을 입력하여 결과를 버퍼화합니다.

마치 3D메시의 정점버퍼같은 느낌으로요.

그리고 알고리즘 소스코드를 따로 툴로 개발하구요.

버퍼화된 빌드된 결과를 테이블화하여 소스코드에 붙여 넣습니다.

그럼 같은 알고리즘을 구현해 낼 수 있으며 속도향상도 됩니다.


그리고 나서 진짜 알고리즘이 내장된 툴의 소스코드를

회사에 제출하지 않으면 어떻게 되겠습니까?

정점버퍼만으로는 메시를 복원할 수 없는 것과 같은 이치로써

테이블화된 소스코드로는 알고리즘을 복원해 낼 수 없습니다.


해외 오픈소스에 이런 짓꺼리 종종 있습니다.

지금은 제가 극단적인 예시를 한 것이지만 그런 짓의 50%, 25%에

해당하는 소스코드도 있는 겁니다. 그래서 안된다는 겁니다. 인수인계는.

"제출된 소스코드는 전임 개발자의 모든 것이 아니다."


또 또 다른 측면,

프로그래밍 문법중에 const, final같은 것이 있습니다.

앞으로 쓰기라는 방식의 구현을 내가 "실수로 작성하게" 된다면 컴파일러가

이를 막아주는 기능입니다. 빌드된 결과에는 아무런 차이가 없습니다.

단지 개발자의 행동을 제약함으로써 거꾸로 소스코드를 이해할 때에도

오해의 가능성을 절반으로 줄여줌으로써 획기적으로 이해를 돕게 됩니다.

어마어마한 발견이며, 이 작은 원리와 아이디어가 결국엔 객체지향을 이룩한 겁니다.


그런데 하나의 소스코드는 const, final같은 것으로만 막을 수 있는 만큼

간단한 상황이 아닙니다. 즉, 오용의 가능성이 있는 겁니다.

왜 바둑기사 이세돌이 한 수를 두는데 몇분이나 걸리겠습니까? 바로 이 가능성.

내가 예상하고 있는 질서가 어딘가에서 지켜지지 않을 그 가능성.

그래서 남의 소스코드를 인계받아 개발을 이어가면

속도가 1/10로 떨어지게 됩니다. 살얼음판을 걷게 되는 겁니다.

이 가능성을 모두 확인하지 않고 "에이 여기서 당연히 흑이 백을 잡겠지~"라는

식으로 무쏘의 뿔처럼 코딩하면? 여기서 크래시가 뻥~ 저기서 뻥~


크래시는 말이죠. 하나씩 만나야 해결할 수 있습니다.

동시 크래시의 수량 N은 10의 승수 (N - 1)입니다.

동시 크래시가 두개면 10배, 세개면 상황이 100배쯤 어려워 집니다.

사실상 생산성, 경제성, 채산성이 다 박살나는 겁니다.

그래서 "사실상" 인수인계가 불가능하다는 거죠.


1) 쓰기속도 > 읽기속도

2) 소스코드 제작방식과 읽기방식의 차이

3) 소스코드 제작단계의 소실

4) 테이블화(난독화는 아니고 해싱화) 가능성

5) 무질서 가능성에 따른 생산성의 하락


17년동안 개발하면서 다양한 상황에서

때로는 기형적인 방법까지 동원하여 인수인계 방법을 연구하였습니다.

링크에러를 통한 재구성, 부분적출, 양립화, 리소스IO를 기준으로 해석등

많은 방법론적 결론이 있습니다만, 결국 모든 노선은 점진적인 부분 패치를 통한

궁극적인 전체의 교체를 가르키고 있는 것을 깨닫습니다.

결국 모두 다시 정상화, 떨어진 생산성을 되살릴려면

자기 것을 쓰거나 새로 짜는 수 밖에 없다는 것이 결론입니다.


회사가 바라는 대로 인수인계하면 10배 느려지는 것은 예사입니다만

생산성 3배만 느려져도 프로젝트는 망합니다.

1년 예상한 프로젝트가 3년까지 늘어지면 자본과 기획적 트렌디함을

잃어버리고서 망하는 것입니다.


2
0
  • 댓글 31

  • 니플
    2019-04-10 02:59:00

    인수인계는 글만 남기는 것이 아닌

    후임자에게 자세하게 말로써 설명해주어야합니다.

    완벽한 인수인계는 불가능하지만 중요한 내용의 인수인계는 가능합니다.


    물론 디비와 소스가 개판이거나 주석도 좋지않게 달린 경우는 예외입니다.

    1
  • 전재형
    4k
    2019-04-10 03:57:08

    공감이 가네요.

    가령 제가 계산기 프로그램을 만들었다손 치면 거기서 기능확장을 하는데 저는 1만큼의 시간이 걸린다면 후임자는 10만큼 걸리겠죠.

    저도 몇년이나 남의 코드를 유지보수하는 알바를 했는데... 소스가 잘되어있던 못되어있던 굉장히 날카로워집니다.

    이길로 로직이 달린다면 어느순간 어떤 변수가 어떻게 나타날지 사실은 알수 없죠.

    그렇다고해서 한줄한줄 코드를 분석한다면... 사실 제가 새롭게 개발하는 시간과 별반 다를바 없을테구요.

    그렇긴한데 저의 개발자 경험에서 어떤 개발자에게는 간단한 인수인계 절차만 거치면 기능확장을 굉장히 쉽게하시는 분도 봤어요.

    몇가지 이유가 있겠지만 개인역량을 제외하면 구조적으로 모듈화가 잘된... 책임을 공유하지 않는 소스 구조, 그리고 공통의 이해가 있는 프레임웍을 사용하는걸로 꽤나 많이 커버가 되는 것같습니다.




    0
  • 엡실론
    1k
    2019-04-10 04:41:56

    결국 모든게 비용 문제죠.
    어디까지 인수인계에 비용을 투자할지, 평소에 문서화, 코드리뷰, 리팩토링에 얼마나 투자할지.

    장기적인 관점에서야 평소에 코드/문서 관리를 잘하는게 좋지만,
    단기적인 성과가 급하고, 기한이 촉박하면 지키기 힘들죠.

    0
  • fender
    18k
    2019-04-10 07:04:58 작성 2019-04-10 08:29:07 수정됨

    보통 남이 읽지 못하는 코드를 짜는 건 '고수'가 아니라 코딩 컨벤션, 베스트 프랙티스, 디자인 패턴 등에 무지한 부족한 개발자로 평가합니다.

    이클립스나 스프링 같은 크고 복잡한 코드 베이스도 소스 보면 어렵지 않게 의도와 구조를 짐작할 수 있습니다. 자기 가 짠 코드를 남이 못알아보게 꽁꽁 감추는 게 아니라, 그 정도 프로젝트를 그런 수준으로 설계하고 유지하는게 진짜 실력입니다.

    남이 못 읽는 코드를 짜는게 당연하고 바람직하다는 주장은 해외에선 유머로만 존재합니다. 꽤 유명하고 주옥 같은 글이니 혹시 처음보시는 분들은 한 번 읽어보시기를 추천 드리고 싶습니다:

    How To Write Unmaintainable Code

    2
  • fender
    18k
    2019-04-10 07:24:13 작성 2019-04-10 07:25:28 수정됨

    참고로 다음과 같은 문서만 읽어보아도 구글 같은 회사들이 코드를 어떻게 코드 가독성 및 유지보수 가능성을 높이려고 노력하는지 알 수 있습니다:

    각 언어별 링크를 따라가면 매우 상세하게 이름 규칙부터 파일 구조까지 누가 프로젝트의 어느 부분을 보더라도 마치 자신이 작성한 코드 처럼 읽을 수 있도록 일관성을 확보하기 위한 규칙들을 정의하고 있습니다:

    Google Style Guides

    해당 문서의 첫 단락만 읽어보아도, 말씀하신 코드 리뷰 같은 건 무시하고 남이 짠 모듈은 읽거나 유지보수 하지 않고 사람 바뀌면 통째로 갈아 엎는다는 식이 '실리콘 밸리 방식'이라는 주장은 사실과 다르다는 건 명확하리라 봅니다:

    Every major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style.

    2
  • 산들바람_
    2k
    2019-04-10 08:55:07

    인수인계란

    모든 소스코드를 100% 이해시키는것이라고 생각해본적은 없습니다.

    저또한 살면서 인수인계를 받은적이  없거나 있어도 대략 30분동안 담배피면서, 대충 요건을 들으며 사람들 성향이 어떠한지 , 누구를 조심해야 하는지, 누가 착하고 심성이 좋은지 등등을 파악한것 같습니다. ㅎ

    세상에 풀리지 않는 소스코드가 있을까요

    소스코드 자체가 인수인계라고 생각합니다. 문서는 거짓말 해도 소스는 거짓말을 하지 않으니까요

    물론 자신만의 암호화 알고리즘으로 소스코드를 숨겼다면 모르겠지만요

    하지만 소스를 드럽게 해서 알아보기 힘들게 한다면, 좋은 개발자는 결코 아니라고 생각합니다.

    협업과 open마인드를 가진 훌륭한 개발자분들이 많을수록 한국 it와 회사 모두 질적으로 높은 경쟁력을 갗추고 발전해 나갈것 같습니다.

    한국 IT가 이렇게 폐쇄적이고 발전이 더디고 과거에 머물러 있는것도 OPEN된 마인드의 부재가 한몫하지 않았을까 하는 생각이 듭니다.

    결론 : 인수인계는 100% 완벽하게 안해줘도 된다. 하지만 소스는 깨끗하게 짜놓자 ㅎㅎ 입니다.

    0
  • ercnam
    4k
    2019-04-10 09:02:28

    현실은 주석한줄 없이 스파게티가 되버린 소스로 알아서 인수인계가 끊기는...쿨럭

    해싱이니 뭐니 하는 어려운 기법 필요없어요...

    0
  • crazygun22
    666
    2019-04-10 09:12:04

    코드리뷰가 이래서 필요한 거죠.

    0
  • 조앙마두
    123
    2019-04-10 09:32:50

    어느정도 공감가는 글입니다. 

    현업에서 인수인계를 본 개발자에게 받지 못한 상태에서 개발문서 없이 소스 분석만 하다가 많은 시간을 투자하고도 완전히 이해 못했던 경험이 있어요.   

    그래서 개발문서를 잘 남겨야겠다고 생각하게 되었습니다. 개발산출물을 그저 형식적인 틀에 입각한 난해하기만 하고 후임자가 볼 때 실효성이 떨어지는 형태가 아닌 누가 제 코드를 보더라도 쉽게 바톤을 이어갈 수 있을 문서 말이죠. 

    SW산출물 가이드를 참고하며 필요한 것들 (물론 모든 문서가 유기적으로 연결되어 다 필요하겠지만) 을 추려서 작성하며 개발 하려고는 하는데 개발 시간이 좀 더 걸리네요. 

    제가 꼭 있어야하는 문서라고 생각하는 것은 아래와 같은데요.. 

    1. 컴포넌트 명세서 (컴포넌트 다이어그램)

    2. 데이터 흐름도 (시퀀스 다이어그램)

    3. 클래스 명세서

    필수 문서들이 더 많겠지만 후임자가 위 자료들을 보면 큰 그림을 볼 수 있지 않을까... 기대하는거죠.

    클래스의 주요 변수와 함수까지 명세서로 남겨야 도움이 될 것이라 생각하나 구조가 하나 둘 씩 생겨서 괴물이 되갈수록 세세히 설명하기가 너무 귀찮기도 해요.  

    1
  • linuxer
    2k
    2019-04-10 09:52:58 작성 2019-04-10 12:02:52 수정됨

    와...이분의 글은 진짜 가슴을 벅차게 만드는 ㅎㄷㄷ


    fender님과 박가사탕님 두 분의 글을 읽으면 ㅎㄷㄷ


    0
  • 박가사탕
    2019-04-10 10:12:31

    실행되는 소스코드는 그나마 믿을 수 있지만.

    문서따위는 못믿죠.

    자신이 학교 수업시간에 꾸벅꾸벅 졸다가

    선생님이 이해했냐고 하면 "네~" 하는 상황과..

    내일 당장, 또는 다음달까지 미션을 받아 구동되는 무언가를 제출해야 하는

    프로그래머의 입장은 완전히 다릅니다.


    문서믿고 작업했다가 난관에 봉착하면 증명하기도 어렵습니다.

    그냥 소스코드를 "글"로 보고 디버깅 브레이크걸어놓고 추적해가면서

    이해하는게 가장 완벽하고 기댈만 합니다.


    이 글의 취지는 남의 소스코드를 내가 물려받지 못한다는 것이 아닙니다.

    내가 직접 짠 만큼의 생산성에 비하면 1/10도 안되는

    초라한 현실을 인정해야 한다는 겁니다.


    그게 '사실상' 불가능한 겁니다.

    0
  • choju
    1k
    2019-04-10 10:24:21

    재미있어요!

    0
  • 조앙마두
    123
    2019-04-10 10:25:47

     

    박가사탕 네 사탕님 말씀 이해되요. 뭐랄까.. 생산성 1/10 을 좀 더 끌어올려서 6/10 정도로 끌어올리는 방안은 없는가 라는 생각을 하게 되요.

    문서는 말씀해주신데로 믿을 게 못되는 것이라고 저도 생각합니다. 문서를 최신으로 업데이트 최종 릴리즈 하는 개발자는 정말 부지런하거나 어떤 스마트한 툴을 이용하여 형상관리(맞나요?) 하시는 분들이겠죠?



    다만, 선조들이 그림을 그리고 찍은 직인 같은 가치 있는 문서가 되도록 노력하고 싶어요. 
     
    0
  • 박가사탕
    2019-04-10 10:35:54

    위엣 논리중..

    그렇게 하면 나쁜 놈이지! 성토하는 마음을 알겠지만..

    어쩌겠습니까? 이미 세상이 그런 것을.


    특히 우리나라는 퇴사할때 갖은 수모를 주는 곳에 있는데

    실행되는 소스코드 온전히 남겨두고 온 것만 해도 천사죠~ ㅎㅎ


    -1
  • ty82lee
    4k
    2019-04-10 10:46:16

    재미있는글 잘 읽었습니다.

    0
  • vollfeed
    1k
    2019-04-10 11:03:17

    저도 기본적으로 온전한 인수인계는 사실상 불가능하다 쪽입니다. 

    박가사탕님의 비유도 적절한게 많은데 좀 다른 관점에서 이유를 좀 보태겠습니다.


    우리가 흔히 하는 인수인계는

    "무었을 어떻게 했는가?"가 중심이고 "왜 그렇게 했는가?"가 부수적으로 붙습니다.

    하지만, 동일한 실수를 방지하여, 생산성을 유지하는데 정말 필요한건,

    "왜 B, C라는 다른 방식은 쓰지 않았는가?" 입니다.

    어떻 개발을 해나감에 있어 문제됬던 사례들, 부적절한 기술, 결정등등... 


    현재 우리는 이렇게 구현해놨다. 라는 현 상태보다,

    우리는 A 문제 이렇게 확인하고, B방법으로 검증했다. A라는 선택은 부수적으로 B,C의 문제를 가져오니 선택하지 않는다.

     개발을 진척해 나가는데 있어서는 이런 정보가 더 중요합니다. 

    이 양이 코드로 쓰여진 에센스 보다 너무나 방대하다보니 인수인계가 제대로 되지가 않죠.


    요는 '현재 상태'는 인수인계할수있어도, 지금까지 피해온 폭탄과, 앞으로 피해야할 폭탄을에 대한 많은 판단근거는 그양과 비명시성 때문에 인수인계가 제대로 안된다는 점입니다.

    어쨋든 인수인계는 항상 정보손실을 가져옵니다. 그 업무의 긴박성, 중요도, 참신성에 따라서 인수인계는 사실상 불가능이라는 판단도 신제품개발에서는 얼마든지 생깁니다.


    2
  • 박가사탕
    2019-04-10 11:14:08

    "왜 B, C라는 다른 방식은 쓰지 않았는가"
    ..b


    0
  • 박가사탕
    2019-04-10 11:16:17

    사실 적으려다 이미 글이 너무 길어져서 말았는데.

    책임소재의 문제도 심각합니다.


    문제가 발생할 때마다 "거지같은 이전 소스코드 때문에"를 반복하는 상황이 됩니다.

    기업주입장에서 미쳐버리는 거죠. 책임질 사람은 이미 없는데

    책임은 꾸준하게 퇴사한 직원으로 돌아가면서 사라지는 책임회피의 상황들.


    0
  • flydof
    441
    2019-04-10 11:55:02

    문제는 윗대가리는들은 이런그거 설명해줘도 모른다는 사실이죠

    0
  • fender
    18k
    2019-04-10 12:21:07 작성 2019-04-10 12:24:55 수정됨
    그 소스코드란 글을 쓸 때를 잘 생각해 봅시다.
    지금 제가 글을 써내려가듯이 아래쪽으로 주욱 쓰게 되나요? 노노...
    그렇게 완성된 결과인 소스코드를 "위에서 아래로" 읽어 나간다구요?

    참고로, 적어도 객체지향 언어로 작성된 잘짜여진 코드베이스라면 애초에 내용을 파악하기 위해 그런 식으로 "위에서부터 아래로" 읽어나갈 이유가 없습니다.

    가끔 코딩에 대한 시각이 구문 수준에서 벗어나지 못한 개발자가 그런 객체지향 코드를 이해하기 위해 'main() 메인 함수'부터 찾고 코드를 구문 단위로 따라가려고 덤비는 경우는 있습니다만, 경험 많은 객체지향 개발자라면 그런 식으로 남이 짠 코드를 분석하지 않습니다.

    저는 스프링을 다루어 본지도 한참 지났고 직접 찾아본 스프링 소스는 극히 일부에 불과합니다. 하지만 누가 스프링의 API를 두고 임의로 어느 클래스를 지목한다면 아마도 큰 어려움 없이 어떤 용도로 사용하는 클래스이고 어떤 의도에서 어떤 역할을 하게 설계한 것인지 대략적으로 설명할 수 있다고 생각합니다.

    그리고 그런 식의 탑다운 방식으로 코드를 파악하는 것을 가능하게 하는 필수적인 지식이 바로 다른 글에서 "쓰레기 지식"이라고 폄하하셨던 패러다임, 디자인 패턴, 리팩터링 같은 부류의 내용입니다.

    또한 스프링 같이 규모가 커져도 그런 방식으로 쉽게 파악할 수 있고 유지보수를 할 수 있게 설계를 할 수 있는 것이 능력있는 개발자의 척도이기도 합니다.

    0
  • 박가사탕
    2019-04-10 12:58:52

    비유법입니다-_-)

    0
  • baltasar
    7k
    2019-04-10 13:00:30 작성 2019-04-10 13:01:52 수정됨

    거두절미하고, 세상에 어떤 업종도 자기가 개발하거나 이행한 물건 남에게 어떻게 개발하고 이행했는지 가르쳐주는 업종 없습니다.

    자동차 정비공장에서 정비공 나갈 때 누가 자기 정비기록을 상세하게 전부 후임에게 풀어줍니까?

    영업부장이 회사 나가서 회사 망하게 생겼다고 누가 후배들에게 영업기록을 상세하게 풀어줍니까?

    심지어 사람의 신체를 다루는 병원 수술도 환자 인수인계 할 때 언제 수술했고 왜 수술했는지, 위험한 부위만 알려주고 끝내지 어떻게 수술했는지 안 알려줍니다.


    개발자가 해야 할 인수인계는 뭘 하려고 만든 시스템인지만 알려주고, 패스워드는 어디 있는지, 받은 문서와 물품만 다 반환하고, 기존에 만든 제품에 1개월~6개월 일정 기간 문제가 없게만 해놓고 나가면 되는 겁니다.

    내가 만든 물품 상세하게 전부 전수해주는 것은 '강의', '교육'에 해당되는 것이고, 인수인계란 자기가 받은 거 그대로 물려주고 가는 겁니다.

    0
  • 코딩잘하기
    1k
    2019-04-10 13:19:41 작성 2019-04-11 00:22:41 수정됨

    실리콘 밸리 같은 데서 패턴, 아키텍처나 소스관리 시스템을 괜히 도입한 게 아니죠.

    한 개발자의 역량에 의존하던데서 

    여러 개발자에게 위험을 분산하기 위해 도입했습니다. 

    그 결과 개발자들이 2~3년에 한번씩 이직을 해도 

    다른 개발자가 쉽게 인수인계를 할 수 있게 되었구요. 


    지금도 구글 같은 데서 소스를 오픈소스화 하는 건 

    생태계 발전을 위함도 있지만 

    자신들의 코딩 스탠더드를 널리 알리고, 입사 후 적응을 쉽게 하기 위함이 있죠.


    인수인계가 안 되는 이상한 회사만 다니신 것 같습니다. 



    -2
  • 박가사탕
    2019-04-10 13:36:58

    머.. 누군가에게는 가슴뛰는 글이

    누군가에게는 어이없는 글일 수도 있겠죠^^

    2
  • ㅇㅈㅇ
    3k
    2019-04-10 14:05:38

    이게 진짜 17년 경력 개발자가 쓴 글인가?

    참담하네..

    0
  • vollfeed
    1k
    2019-04-10 16:11:09

    여러 관점들이 있네요.

    그런데 일단 인수인계 대상물의 범위부터가 서로 전부 다른듯 하네요. 

    뭐 어쨋든 좋습니다. 


    저런 의견을 반영하여 제 생각을 다듬어서 표현하며,

    개발환경의 대한 인수인계를 될지언정, 

    의사 결정 구조와 많은 판단 근거는 인수 인계가 안된다 정도로 표현 할 수 있을 듯하네요. 


    물론, 10명의 팀에서, 10% 공헌도를 가진 개발자 1명의 이탈은

    겨우 10%의 의사 결정 구조의 손실 및 판단 근거인데, 중복을 감안하면 3~5퍼의 손실 일 뿐이라 작습니다.

    새로운 멤버가 들어와서 기존 팀에 동화되어가도, 아주 자연스러운 미미한 변경/발전 으로 보일뿐이죠.


    그런데 만약 혼자 거의 30%를 커버하는 핵심개발자라면 그 추정은 전혀 다르겠죠.

    극단적으로 2~3인 구성의 팀에서 핵심 기술자라면 팀의 기능의 연속성이 거의 상실된다고 봐도 됩니다.

    이또한 운영/운용 상황인지, 신규 개발 중 패스트 팔로워인지, 신규개발 중 퍼스트 무버인지에 따라서도 다 다릅니다.


    그리고 혹시나 해서 언급합니다만,

    저는 애초에 100% 인수인계는 불가능하다 쪽,

    정확히는 "사람이 바뀌면 일의 연속성은 깨진다" 쪽입니다.

    개발자가 개발환경과 패스워드, 현상태에 대한 개략적 문서, 소스코드 일체 정도를 남기는 것에 납득합니다. 

    어차피 더 할수도 없으니까요.


    그러나 반대로 인수인계가 100% 가능하다라고 생각하시는 분들은

    만약 그 인수인계라고 생각하는게 "일의 연속성을 보장하는 것" 이라면, 

    인수인계의 범위란 어디까지이며, 어떤 방식으로 인수 인계를 해야 제대로 업무의 연속성을 보장하는 것인가? 를 진지하게 고민하셔야 할겁니다.

    기껏 소스코드나  UML만 남겨놓고 끝내는 것은,

    현재 진행중인 일에 대한 "연속성 없이", 이후는 인수자 맘음대로 하면 된다는 의미일 것입니다. 

    영업직이 거래처와 있었던 수많은 협의 내용을 덮어버린체, 최근 6개월의 거래 내역서만 주는것과 다른바가 없죠.

    사실 인계자는 아무런 상관이 없으나, (어차피 떠났으니까요..)

    인수자와 특히 거래처는 서로 양해한 부분이 있는데, 그걸 재설정하는 상황에서 심한 갈등을 겪죠.


    그러나 유지보수 계열처럼 정해진 매뉴얼이나 절차가 있는 경우, 

    또는 고객 센터의 단순 전화 상담이나 텔레마케팅 같은 경우 스크립트(대사집)을 주면

    "일의 연속성이 확보"됩니다.  김 아무개 씨가 하나 이 아무개 씨가 하나, 업무 굴러가는게 같다는 의미 입니다.


    그런데 프로그래머는 사람이 바뀌면, 이래저래 다 바뀝니다. 

    그 극단적인 예는, 핵심 개발자가 변경될 시, 모조리 갈아엎는 것으로 나타나는 것이구요. 


    사실 이건 음식점에서 찬모 아주머니가 바뀌면 밑반찬이 바뀌는(한번에 바뀌든 서서히 바뀌든) 것과

    미용실에서 헤어 디자이너가 바뀌면 절대 이전과 동일하지 않은 것과 같은 이치입니다.

    개인의 기술과 기능에 의존하는 이상 피할수가 없는 일이죠. 


    그리고 프레임워크를 사용하거나,  디자인 패턴을 따르면 모든 인수인계가 된다고 생각하시는 분들은,

    보편 기술을 사용하는 것과

    "우리 팀의 개발"에 대한 것을 구분해 주시면 좋겠습니다.

    저는 우리 팀의 개발(내지는 사업방향, 기술활용, 설계방침 등)에 대한 연속성이 깨진다는 것을 애기하는 것이니, 반론을 하실려면 구분해주시면 좋겠습니다.



    아울러 인수인계가 매끄럽지 않을수록 사람의 가치가 올라가는 겁니다.

    대체제가 없다는 의미 또는 대체시에 많은 제반 비용이 들어간다는 소리거든요. 

    누구를 써도 업무 연속성이 보장되면,

    굳이 비싼돈에 나(특정한 누군가)를 쓸 필요가 없다 라는 의미가 됩니다.

    완벽한 인수인계 달성 가능을 애기하시는 분들은 

    과연 내자리에 다른 누군가가와서 정말 아무런 문제없이 매끄럽게 업무가 돌아갈만큼, 

    지금 내가 하고 있는 일이 기계적이거나 정형화 되어 있는가를 생각해보시면 답이 나올거라 생각됩니다. 

     

    1
  • vollfeed
    1k
    2019-04-10 16:24:05

    덧붙여, 

    저는

    널리 알려진 기술인 OOP 나 디지인 패턴, 특정 프레임워크의 관례를 존준해서 사용하는 것은

    인수인계가 잘 할수 있다는 전제가 아니라, 

    제대로  할수없다는 것을 전제로 해야하는 것이라 생각합니다.

    제대로 할수는 없지만, 그렇다고 손 놓고 있을수도 없자나요?


    가뜩이나 인수인계가 힘든 프로그래밍이라는 업무에서

    보편성이 없으 커스텀된 구조만 잔뜩이다?

    그럼 경력사원이 들어와도 업무파악에 기존 근무자가 도와줘도 3개월 걸릴겁니다.

    이걸 어떻게든 줄여보려고, 어떻게든 인수인계 부담을 줄여보려고

    개발자 커뮤니티가 공통적으로 동의하는 것을 가져다 씁니다.

    그런걸 쓰면, 그 부분의 입사 교육이 당연하지 않은 것이되며,  모르는 사람이 기술이 부족한 것이 됩니다. (물론 신입/초급은 예외)


    좋은 설계에 정답은 없으며, 얼마든지 디자인패턴등을 따르지 않는

    독창적이면서 좋은 설계가 나올수 있습니다.

    그런데 많은 경우 그 선택을 기각하는 것은 인수인계(내지는 교육) 비용이 너무 커서입니다.


    경제 논리상, 대게의 경우는 독창성보다 보편성이 나은 선택이라는 거죠.

     

    0
  • okjspedi
    152
    2019-04-11 06:49:20

    박가사탕님, baltasar님, vollfeed님

    글에 공감이 많이 가네요

    0
  • 야롱
    816
    2019-04-14 11:27:37

    박가사탕님의 글엔 항상 고수들이 댓글을 답니다.

    박가사탕님 글에 무턱대고 비공을 주는건 자제 부탁드립니다 ㅋㅋ

    하마님 말씀대로 글의 본질을 파악하고 자기 나름(수준)으로 필터링해서 보면 되게 좋은글입니다.

    0
  • 박가사탕
    2019-04-14 11:33:53

    필터링이 좀 필요합니다.. ㅎㅎ

    0
  • 야롱
    816
    2019-04-14 11:50:36 작성 2019-04-14 11:50:43 수정됨

    필터링이란게.. 아직 박가사탕님 글의 모든걸 공감하며 받아들이기엔,

    내공이 부족하여 필터링하는거라고 생각하시면 될 것 같습니다 ㅎㅎ

    그냥 주입했다간.. 주화입마에 빠질수도있으니..

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.