소프트웨어 개발을 하다가 부딪히는 거지 같은 상황들

소프트웨어 개발이 아닌 다른 분야도 비슷하겠지만, 아래 사항들은 소프트웨어 공학을 완전히 무시하는 사항들이다.

컴퓨터 공학과를 나오건, 안 나오건 관리자라면 알아야 하는데 왜 모를까?

 

소프트웨어 개발자가 아니라 일을 시키는 고객의 입장에서도 본인에게 손해가 되는 것들이니 알았으면 좋겠다.

 

1. 혹시 필요할 지도 모르니까 만들어 달라고 할 때

2. 자기가 뭘 원하는지 모르면서 혹은 자기가 어떤 일을 하는지 정확히 알지 못하고 요구할 때 

3. 업무 절차(특히 소프트웨어 생명주기)를 무시할 때

4. 더 좋게 만들어줘도 싫다고 할 때

5. 대전제를 지키지 않을 때

혹시 필요할 지도 모르니까 만들어 달라고 할 때

이건 한국이 심하거나 한국에만(혹은 일본도) 있을 것 같다.

갑을관계가 없이 계약을 정상적으로 준수하는 국가에서 이런게 있을 수 없다.

 

필요하건 필요하지 않건 어떤 것을 만들 때에는 정당한 대가를 지불해야 하는데, 한국은 갑을관계에서 나오는 업무상 지위를 이용해 정당한 대가를 지불하지 않는 것이 당연한 나라라서 이런 문제가 발생한다. 

 

이 경우는 2, 3, 4, 5의 문제가 복합적으로 발생하기 때문에 더더욱 문제가 심각하다.

하기 싫은건 덤.

자기가 뭘 원하는지 모르면서 혹은 자기가 어떤 일을 하는지 정확히 알지 못하고 요구할 때 

컴퓨터는 인간의 정신노동을 자동화시키는 도구다. 자기가 뭘 해야할지 모르는 상황에서는 업무를 자동화 할 수 없다.

 

자기가 어떤 일을 하는지 정확히 알지 못하는 것은 그나마 이해가 간다. 이미 구축된 전산 시스템이 인간을 바보로 만드는 것은 당연하니까.

 

그런데 자기가 뭘 원하는지 모르면서 뭘 만들어 달라고 할 때에는 도대체 뭘 어떻게 해야할 지 모르겠다. B2C라면 그래도 이해를 하겠는데 B2B에서 이런 상황이 발생하면 '나는 무능력자에요. 나는 멍청이에요.' 라고 광고하는 것과 다를게 없는데 왜 당당할까.

업무 절차(특히 소프트웨어 생명주기)를 무시할 때

업무 절차를 무시하는 사람들은 대부분 일을 못한다.

일을 잘 하면 업무 절차를 지키건 안 지키건 상관 없다. 업무 절차는 일 못하는 사람들에게는 업무를 어떻게 하라는 가이드 라인 역할을 하지만, 일 잘하는 사람들에게는 귀찮기만한 작업일 뿐이다.

 

업무 절차를 안 지키기만 하면 다행이다. 일 못하는 사람들은 업무 절차를 안 지켜서 발생하는 문제들을 해결하기 위해 다른 이상한 절차를 만들어낸다.

예를들어 회의를 하고 나서 업무를 진행해야 하는데, 업무를 진행하다가 자기가 어떤 부분에서 막히면 그 부분에 관련이 있는지 여부와는 상관 없이 관련이 있을 것 같은 사람들을 모두 회의에 참석시키고 30분도 안되서 회의를 마친다.

 

이런 사람들이 조직에 얼마나 민폐고, 비효율을 만들어내는지 알 수가 없다.

 

소프트웨어 생명주기는

1. 요구 분석

2. 설계

3. 구현

4. 테스트

5. 유지보수

의 5단계로 이루어진다.(단계를 더 나누기도 하는데 크게 보면)

 

소프트웨어 생명주기가 만들어지게 된 계기는 3단계에 해당하는 구현만 중요시 여겼더니 프로젝트의 성공률이 낮아져서 돈과 시간만 날리는 프로젝트가 많았기 때문이다. 1960년대 말에 이미 미국에서 이 문제를 해결하기 위해 소프트웨어 공학을 연구하기 시작했고, 대부분의 한국 소프트웨어 분야 종사자들은 1970년 이후에 태어났을 텐데 왜 이런 기본적인 것도 모르는지 알 수가 없다.(이걸 알고도 무시하는 것이 아니라 모른다. 억지 부리는게 아니라 정말로 모른다.)

 

소프트웨어 생명주기를 무시하는 것은 1, 2, 4 단계를 무시하고 3, 5단계만 개발자에게 떠맡기는 것이다. 다르게 얘기하면 자기가 맡아야 하는 책임을 개발자에게 떠맡기는 것이다.

더 좋게 만들어줘도 싫다고 할 때

내가 영업직도 아니고, 나를 희생해서 다른 사람들이 편하도록 만들었는데도 싫다고, 원래대로 해달라고 하면 정말 어떻게 해야할 지 모르겠다.

인지 과학의 연구 결과를 반영하고, 논리적으로 더 이치에 맞는 소프트웨어를 만들어줘도 싫다고 하면 어떻게 해야하나.

 

원래 요구 사항의 구현 난이도가 낮으면 그나마 괜찮은데, 하나의 업무를 논리적으로 여러 개의 업무로 나누지 않았을 때 구현 난이도가 우주 끝으로 가는 경우가 많은데, 이런 경우 정말 때려치고 싶다.

대전제를 지키지 않을 때

소프트웨어는

수학적, 공학적으로는 튜링머신, 폰 노이만 구조라는 공리 위에서 작동하고,

논리적, 철학적으로는 법률, 규정, 사회 구조 등 대전제 위에서 만들어진다.

 

법적으로 해서는 안되는 소프트웨어 개발을 시키면 해야 하는가?

회사 규정, 지침을 어기는 소프트웨어 개발을 시키면 해야 하는가?

 

이걸 했을 때 생기는 문제는 누가 책임지는가?

책임 지지도 못 할 업무를 왜 시키는가? 아니지 책임을 안 질 자신이 있으니까 시키는거겠지.