뭔가 항상 빠진듯한 느낌

kyagrd의 이미지

현재 우리나라 IT 산업의 문제점이랄까요,
아니면 저만의 경험이랄까요,
항상 중요한 단추가 하나 빠져 있습니다.

고객의 요구조건이나 영업의 계약성사가 있고
개발자들은 그것을 충족시키기 위해 일을 합니다.

고객이나 영업은 목표가 분명히 있습니다.
하지만 개발자의 목표는 그 온데간데 없습니다.
아니 처음부터 세우려고 하지도 않습니다.

어떤 스펙이 있고 목표로 하는 기능이 있을 때,
그것을 이루기 위한 기술이 무엇이고 그 기술을
도입하력 했을 때 어떤 조건이 필요한가 하는
개발자들의 목표가 없이 항상 일이 진행되는 듯한
느낌을 받습니다.

예를 들면 이런 식입니다.
P2P 음악서비스 한번 만들어 볼까 하고 기획이 나와서
이리저리 영업적으로 움직여서 무언가 계약들이 성사되고
돌아긴 하는데, 막상 웹에는 어떤 기술을 쓰지 JSP? PHP? IIS?
인증이나 파일 파일 전송 프로토콜은 뭘로 하나? P2P 모델은
어떤 식으로? 하지만 이런 일에는 관심도가 너무 낮습니다.
일정은 언제까지로 하고 무조건 지금 잘되는 데랑 똑같은 모양만
나오면 되는거야. 얼른 하자 ...

이런 식으로 모든 것이 대충대충 흘러가는 느낌.
이렇게 되면 한건은 해결할 수 있어도 그 후에 남는
것은 아무것도 없고 개인은 물론 회사 자체적으로도
기술력 따위는 축적이 전혀 되지 않습니다. 결국은
모양만 처음엔 비슷한데 완성도가 떨어져서 고객에게도
외면당하는 경우도 많겠죠 이렇게 되면.

왜 이런 일들이 반복되는 건지, 그냥 우리나라 IT 의 역사가
짧아서 그런 걸까요 아니면 우리나라 국민성(?)이라기까진
거창하더라도 산업계의 분위기 자체가 나쁜 걸까요?

버그소년의 이미지

우리나라 IT산업과 시장에 문제점이 없는것은 아니지만,

전 별 걱정은 하지 않습니다.

집을 지을때 기초는 몇미터를 파고, 철근은 어떤걸쓰며, 벽 미장을 할때

몇년차 된 숙련공이 얼마만에 하느냐는 그리 중요하지 않습니다.

막말로, 부실공사로 금이가거나 무너지는 일만 없으면 되는것이죠..

이러한 부실공사를 막기위해 건축관련에는 표준이나 법제화 된 것들이 많이 있죠.

당연한것이 건축이라 하는것이 길게보면 인류 발생부터 현재까지의 역사를 가지고 있으니

그 기간동안 체계화가 잘 되어있죠.

IT란 것이 국내뿐만 아니라 그 자체의 역사가 짧다보니 아직 체계화 되지 않은 부분이 상당히 많이 있고,

또 발전 속도가 체계화되는 속도보다 빠르다보니 kyagrd님과같은 걱정이 생기는듯 합니다.

고객이나 판매자(영업)에서 세부 기술에대한 관심이나 이해가 없는건 당연한 겁니다.

핸드폰을 구매하는 사람이나 판매하는 사람이나 CDMA란 기술을 이해해야 하거나

전자기학을 이해하고 공부해야 하진 않는것과 같은것입니다.

어떻게 보면 현재 이렇게 개발되는 이유는 시장에서 요구되는 제품 수준이나,

제품으로서의 가치를 만들기에 적정수준이기때문일 수도 있습니다.

너무 비관만 하지 마시고 IT업계 종사자로서 보다 빠른 체계화에 힘 쓰실때인듯 합니다.

가끔은 밥을 굶어도 살 수 있다.

kyagrd의 이미지

고객이 자신이 원하는 요구조건이 무엇인지 모를 때가 있습니다. 일정만 알고요 ... 대표적인 예가 서울시가 LG CNS 에다가 교통카드 시스템 한 건데, 카드인식이 예전보다 떨어지는 성능에 대해 짜증이 나면서도 이걸 서울시를 욕해야 할지 LG CNS 를 탓해야 할지 난감합니다.

체계화가 절박히 필요한 것은 사실이지만, 체계화된 방법론에 도입에 대해서 그만큼 필요성을 인식하지 못하는 경우가 많아 안타깝습니다. 고객이나 판매자가 세부 기술에 대한 이해는 없어도 되지만 관심은 반드시 가져야 합니다. 일정을 잡을 때 기술적인 부분을 고려햐지 않기 때문에 결과물이 이상하게 나오고 판매자도 고객도 만족하지 못하여 신뢰를 쌓기가 힘들어집니다. IT업체의 경우 신규개발된 제품을 납품하는 경우가 자주 있습니다. 발전속도라기 보다도 소프트웨어의 종류가 매달 많은 곳이 쏟아져 나옵니다. 핸드폰을 납품하는데 새로 원하는 기능이 CDMA 를 꼭 이용해야 한다면 CDMA 칩을 박아서 성능을 시험하고 새로운 기술을 도입하는 시간에 대한 계산이 있어야 하고 이에 대한 관심은 판매자가 먼저 가지고 고객에게 이해를 시켜야 합니다. 하지만 반대로 계약을 먼저 하고 돌아와서 개발자에게 무조건 빨리 만들어 달라고만 합니다. 이렇기 때문에 수준 이하의, 베타판이라고 부르기에 민망한 것이 납품되는 사례가 허다합니다. 너나 할것 없이 이러니 IT 제품 수주에도 확실히 어떤 기능이 제공되고 그것이 구현가능한지 여부보다는 로비 잘하는 게 장땡이 되어 버립니다. 솔직히 그런 제품을 사는 구매자도 문제가 있습니다. 실제로 그런 것을 만들만한 능력이 있는지에 대한 객관적인 검증 없이 어떻게든 만들어 주겠다는 말만 믿고 계약을 맺은 것이니까요. 구매자와 판매자가 기술수준에 대한 관심이 없어서는 절대로 안 된다고 생각합니다. 결국 우리나라 IT 수준을 깎아먹는 것입니다.

특히 IT 의 경우 새로운 기능을 가진 소프트웨어를 만들거나 이러한 문제가 고려되는 경우가 적습니다. 건축자재라면 새로운 건축자재가 나왔다면 그에 대한 안정성 시험이라든지 내구성 시험 같은 일련의 절차들을 분명히 밟겠지만요. 어떤 개발자의 분노 섞인 푸념이 상당히 인상깊습니다. "적자수주는 영업에게 나름대로 실적이지만 적자수주를 메우는 개발자의 밤샘은 무능력일 뿐이다."라고 말입니다.

어쨌든 개발자들이 이러한 측면을 영업이나 관리팀에게 확실히 이해를 시키는 것을 게을리해서는 안 된다는 것만은 사실입니다. 체계화하고 정리하는 데도 일정을 투자해야 하는데 현재는 그런 쪽에 너무 인색하다고 할까요 무관심하다고 할까요. 그렇다는 것입니다.

--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/

ㅡ,.ㅡ;;의 이미지

한마디로 개발자의 능력을 최대한 발휘할수 없는 상태이고
이는 업무의 비효율적인 측면도 발생할뿐아니라 개발자의 불만도 발생하겠지요.
또한 뭔가 제대로되지못한 구조나 설계로 개발자가 수긍하지 못한데서 불만이 발생할거라봅니다.

예를들어 책상을 만드는데 책상을 설계한사람이 책상모양과 구조만을 설계하는것이 아니라
책상만드는과정까지 설계를 하고 있는상태이고 어느부위에 못을 어떻게 박아라고 망치든사람옆에서 참견하고 있는상태여서 망치든사람은 "니가해!"라고 말하고 싶은상태겠지요..
여기서 만일 설계하는사람이 정말 설계를 잘했고 맞는말이라면 목수는 수긍을할것이나 나무못박는것에대해서는 누구보다 자신있는목수가 그런말들을때 속으로 우습겠지요.. 그러니 잘할래야 잘할수도 없고 발전도 없고 시키면시키는데로 하자식이 될수 밖에 없겠지요..


----------------------------------------------------------------------------