소프트웨어 공학에서 '공학' 에 대한 생각해보기

공학 Engineering은 많은 공과대학에서 배우는 여러 학문들의 범위에서 비용과 현실적인 문제들을 ... (생략)

 

뭐 이런 얘기를 하고자 하는 건 아닙니다만,

우리가 흔히 오해하는 부분들을 다루는 내용이 나와서 몇 자 적어봅니다. 

 

동일한 입력이 들어가고, 동일한 출력이 나온다. 

동일한 입력이 들어갔는데, 동일한 출력이 나오지 않으면 그것이 공학인가?

 

현실적으로 네!, Yes! 그럴 수 있습니다. 

 

 

공학은 현실적인 문제를 다루기 때문입니다.

현실적(Real, Fact 등)이지 않은 부분까지 집중해서 다룬다고 하면 학문, 자연과학의 범위에서 더 중점적으로 논의가 되어야 한다고 생각합니다. 

(이런 생각은 어디까지나 개인의 지식과 의견, 가치관, 경험 등에 따라 달라질 수 있습니다. 제 생각이 그렇다는 겁니다.)

 

저는 품질공학, 식시스그마, 품질혁신, 개발 프로세스, CMMI, ASPICE, 기능안전, 등 다양한 부분에서 경험하면서

결국은 사람이 하는 일이다. 라고 생각합니다. 

 

사람이 하는 일이니까

소프트웨어 공학, 소프트웨어 프로세스는 상대적인 부분에서, 접근하고 생각할 수 있어야 합니다.

 

그래서 프로세스, 공학과 같은 범위에서 리딩을 해야 하는 사람, 그리고 이를 고민해야 하는 사람이라면

(결국은 일하는 모든 사람이겠죠?)

 

우리가 하는 일(matter) 그 안에서, 허용할 수 있는 범위에서 오차를 줄이기 위해 기술, 도구, 방법론, 프로세스 등의 다양한 접근을 하는 것이다. 라고 이해하면 좋을 것 같습니다. 

 

 

경험한 유형1.

프로세스 대로 했는데 좋아지는거 맞아?

뭐가 좋아지는 건데?

(뭔가 화가 나 있으심. 답을 정하고서 물어보시는 분들)

 

경험한 유형2.

프로세스 대로 하라잖아!, 그래서 저는 뭐해야 하는데요? 하란대로 했는데요?

(... 네)

 

경험한 유형3.

프로세스 인증 받아와, 고객이 받으라고 하잖아, 인증 따면 우리도 이제...

(네?)

 

기타 경험들.

프로세스 언제 하고 있어!!. 급해 죽겠는데. 네가 책임질거야? 

프로세스 그래서 뭔데? 뭐하라고?

(네 ㅠㅠ)

 

 

물론 위와 같은 경우도 있지만, 그렇지 않은 경우도 있습니다. 같이 고민해보시는 분들, 목적을 이해하시려는 분들..말이죠.

 

오늘은 뭔가 답답해서 오랜만에 이런 글을 적어봅니다. 굿나잇입니다.

남편들 화이팅! & 아빠들 화이팅!!