개인적인 경험에의한 개발용어 사전정의로 몇가지 서적을 참고한

일반적이지 않는 정의입니다.

IT 용어

IT용어는 모든이가 동의하는 전문용어가 없음으로, 그것을 정의를 내리는 능력을 통해

상대의 수준을 가늠해서는 안된다. 진정한 프로는  인지하는 차이를 이해하고

적어도 같이 일하는 기간에는 상대방에게 서로 같은 의미로 동의를 구하기위해 노력을 한다.

예를 들어 지금당장 '서버' 란 무엇인가란 정의를 동료개발자와 같이 내려보길 바란다.

이것은 실제 사례이며,  실제 어플리케이션 서버를 오랫동안 개발해온 개발자의 입장에서는

물리적인 서버를 구분하기 위해 박스라고 불렀으며 , 내부 존재하는 인스턴스를 노드라고

불러왔다. 

어떠한 상위 개발자에게 물리적인 서버 단위를 박스라고 표현했다가 마치 IT용어에 문제가 있는

초급개발자로 취급당하는 황당한 일을 겪은적이 있다.  서버를 직접개발하지 않거나 물리적인 서버단위에 노드를

분산해서 뛰워본적이 없는 개발자들은 대부분  물리장치와 논리장치가 같기때문에 구분할 필요가 없었으며 구체적으로

IIS 서버 ,FTP서버  이러한게 서버라고 한정을 지으며 그이외의 정의는 용납하지 않았다.

유사하게 API호출을 통해 Json을 수집하는 크롤링에 대해 언급을 하였는데, 갑자기 크롤링이란 정의를 다음과 같이 내리는것이다.

html을 수집하는것만이 크롤링이며 다른것은 아니니, 그렇게 부르지 말고 크롤링에대해 올바른 인지를 하라는것이다.

그리고 구체적으로 크롤 디버그를 뛰워주며 html 소스코드를 보여주기 까지 했다. 

맞고 틀리고의 문제가 아니라, IT용어 정의의 문제는 이렇게 정의하는것이 맞으며 당신이 틀렸다라고 하는데서 시작하며

어떠한 용어에 대해 굳은 믿음을 가지거나 범위 한정을 짓는 개발자의 스택을 살펴보면 그 이외의 다른 경험은 없어 보였고

타협할 생각은 없어보였다. 참을성 있는  프로는 그 사람과 이야기할때 그 사람이 이해하는 수준으로 같이 맞추어 주면서

일을 진행하기도 한다.

신기술

오래된 기술은  소프트웨어 위기를 가져오는 죄악으로 생각하며, 신기술 도입만이 해법으로

여기지만, 기술만으로 사실 큰 차이가 없으며 다음과 같음 끔찍한 결과를 낸다

  • 소프트웨어 계약 가운데 50퍼센트는 비용을 초과함
  • 60%는 스케쥴을 넘김
  • 45%는 사용할수 없음
  • 29%는 인도되지 않음
  • 사용하려면 19% 재작업해야함
  • 사용하려면 3%수정해야함
  • 인도된 2%만이 사용할수 있으나, 문제가 해결된것은 없고 운영비용만 증가됨

은탄환

운영중인 소프트웨어가 괴물로 변할때, 은탄환을 장전해서 쏘면 그것이 해결되는것으로 보인다.

하지만 소프트웨어 공학의 본질을 겨냥 하는 경우가 아닌, 우연히 발생하는 사건들을 겨냥하며

은탄환으로 얻는 생산성의 효과는 없다. 소프트웨어를 처음부터 만드는것이 아니라 어떻게 성장을

시킬것이냐가 중요하며. 때로는 그 은탄환은  소프트웨어가 아닌 사람을 겨냥하는것이 목적일때도 있다.

프로

  • 아마추어는 리뷰를 귀찮게 여기지만, 프로는 환영
  • 아마추어는 문서를 마지막에 작성하거나 안하거나하지만, 프로는 처음부터 작성
  • 프로에게 개발주기는 잘 정의된 단계와 기준이 있다.
  • 아마추어는 컴퓨터를 위한 프로그래밍을 하지만, 프로는 사람을 위해한다.

애자일

폭포수 모델의 한계를 언급하면서, 애자일 개발방법론을 이야기하는것이 보통이다.

하지만 이것을 이야기하는 사람은 폭포수 모델을 제대로 경험하지 못하거나, 그것을 개선하기위해

변형을 해본적이 없는 사람들이 대부분이다. 적어도 폭포수는 위에서 흘러서 아래로 내려가며

운영에대한 경험없는 전문가의 이론을 따라 프로세스를 개선하면 물조자 흐르지 않아 막히는 경우가 대부분이다.

물론 간접적으로 배우는것이 항상 틀리다란 말은 아니며 , 경험이 있다고 항상 올바른 방향을 제시하는것도 아니다.

문제는 경험없는 사람의 입담으로인해 구세주인것처럼 여기는 문화가 되어서는 안된다란 것이다.

해결책

레거시한 시스템을 교체하는것은 모두 일회성작업이다. 왜냐하면 시행착오를 통해 배울 기회가없다.

모든 시도가 실패하면 안되는 해결책이 되어야함과 동시에 정확하게 특정 날짜이전까지 교체를 완료하고

평가를 받아야하기때문이다.  한가지 더 심각한 문제는  신규시스템적용에 대부분 실패를 한다는것이며

실패에 대한 인정없이 자연스럽게 되돌리려한다는점이다. 이 모든것은 가장 강력한 결정권자가 승인을 하였으며,

그것을 진행한 몇몇은 조용히 있을뿐이며 책임자는 찾아볼수가 없다. 그래서 시행착오를 통해 배울기회가

없다란말이다. 이 실패를 인정하고 계속 이어간다고하면 중요한 한가지를 배우게된것이다. 하지만 

실패에 대한 후속 대책은 조용하게 폐기절차로 이루어지며...

괴물 시스템을 만든 기존 레거시개발자들이 아직도 남아있다고 하면 그동안 묶힌 개발을 함과 동시에

신규시스템에서 하려고 했던것들도 같이 하게되는 이상한 현상이 발생한다.

플랫폼이 오래되어서 못했던것이 아니였던것이며 사실 최근 5년이내에 모던한 플랫폼들은 큰차이가 없다.  








  • No labels