소프트웨어 엔지니어링이란?
제가 감히 정의를 내릴 수는 없겠지요. :) 대학에서 공부하는 동안 제가 보고, 듣고, 겪었던 내용으로 짤막하게나마 다뤄 보려 합니다. 많은 것을 답변해드릴 순 없지만, 혹시라도 궁금한 점이 있으셔서 댓글로 질문해주신다면, 최선을 다해 답변해드리겠습니다.
본문에 들어가기에 앞서,
제가 가방끈이 아주 긴 것도 아니라서, 특정 용어를 사용해서 글을 전문적으로 쓸 자신은 없습니다. 하지만, 이 쪽 방면 (IT, Software, Hardware, 크게는 컴퓨터 자체)에 있어서 어느 정도의 배경지식을 가지고 계신다는 가정하에 쓰는 글이라는 것을 명심해주셨으면 합니다.
Software Engineering (소프트웨어 공학)
위키피디아에 의하면, 소프트웨어 공학이란 "공학을 소프트웨어에 적용하는 것이다" 라고 정의되어 있네요. 사실 이 정도론 조금 부족할지도 모르겠네요. "수학이란 수를 공부하는 것이다" 라고 답하는 것이랑 비슷하잖아요. 제 생각엔 소프트웨어 공학 (이하 소엔)이란 소프트웨어 개발에 있어서 좀 더 체계적인 절차를 밟는 것이라고 생각합니다. 구체적으로 체계적인 절차라는 것이 도대체 무슨 뜻이냐구요?
토목공학과 소프트웨어 공학
개인적으로 소프트웨어 개발은 토목공학에 빗댈 수가 있다고 생각합니다. 시간을 단축시키기 위해 그리고 비용을 아끼기 위해 서둘러서 공사를 마무리 지으려고 하면, 부실공사의 위험이 증가해서 건물의 수명이 줄어들게 마련입니다. 소프트웨어 개발도 마찬가지에요. 제대로 된 문서하나 없이 (마치 설계도 없는 건물처럼) 개발을 진행하다 보면, 건물 무너지듯 소프트웨어도 아예 작동이 멈출 수가 있습니다.
튼튼한 구조물을 짓기 위해선 수많은 계산 그리고 체계적인 계획이 필요하듯, 제대로된 소프트웨어 개발 또한 비슷한 노력과 시간이 필요하지 않을까요.
설계도 없는 세상이란
청사진 없는 보잉747 비행기 생각해보셨습니까? 다 만들어 놨더니, 비상시에 탈출할 비상구가 마련되어 있지 않다면?
설계도 없는 63빌딩 생각해보셨어요? 건물의 반을 이미 지어 올렸는데, 구조적 결함 때문에 지진에 대한 대비가 제대로 되지 못해서 처음부터 새로 지어야 한다면?
소프트웨어 개발도 마찬가지입니다. 체계적인 절차를 밟지 않는다면 비행기가 날다가 갑자기 떨어질지도, 그리고 고속전차가 달리다가 갑자기 멈출지도 모를 일이지요. 비행기랑 고속전차가 무슨 상관이냐구요? 요즘은 소프트웨어가 들어가지 않는 곳이 없거든요. 하다못해 냉장고에도 소프트웨어가 들어가는 세대니까요. :)
소프트웨어란?
말이 나왔으니, 짤막하게나마 짚고 넘어가는 것이 좋을 것 같습니다. 교과서적인 답변을 드리자면, 소프트웨어는 컴퓨터 프로그램(들) 또는 코드의 집합이라고 말할 수 있겠습니다. 좀 더 단순하게 말씀드리자면, 전자기기를 구성하고 있는 구성원 가운데, 하드웨어 즉 물질적인 것이 아닌 모든 것을 소프트웨어라고 말할 수 있겠네요. 사람의 신체를 예로 들자면, 하드웨어는 육체로 볼 수 있겠고, 소프트웨어는 지식으로 비유할 수 있겠습니다. 소리를 내는 것이 육체가 가진 능력이라면, 특정 언어 (예로 한국어)를 말할 수 있다는 것은 배움을 통한 지식 덕분이겠죠? 소프트웨어는 컴퓨터 (넓은 의미에선 전자기기)가 이해할 수 있는 하나의 지식이라고 생각하시면 될 것 같습니다.
다시 본론으로 돌아와서, 소프트웨어 공학은 컴퓨터에게 가르칠 지식을 개발함에 있어서 체계적인 절차를 밟는 것을 중요시 여깁니다. 요구되는 것 또는 문제가 무엇인지, 그리고 어떤 식으로 해결할 것인지를 분석하고 문서화해서 차후에 (만약 필요하다면) 수정이 용이할 수 있도록 준비해두는 겁니다. 세상에 완벽한 것이란 없듯, 이렇게 만반의 준비를 갖춘다고 해도 문제가 없는 소프트웨어 개발이란 여전히 힘듭니다. 사용자의 행동반경을 완벽하게 예측한다는 것은 불가능하거든요. 호환성 문제가 자주 불거져 나오는 것도, 모든 가능성과 조합을 다룰 수가 없기 때문입니다. "제 컴퓨터에는 제대로 작동하는 데, 이상하게 친구 컴퓨터에선 작동이 안되요" 같은 건 이미 많은 분들이 경험해 보셨으리라 믿습니다.
소프트웨어 공학도에게 요구되는 점
소프트웨어를 개발함에 있어서 첫째도 문서화, 둘째도 문서화라고 귀가 따갑게 들었습니다. "난 나의 코드 자체가 문서야"를 부르짖으며 자신의 천재성을 자랑하시는 분들도 계시지만, 사실 여행에 앞서 계획을 제대로 세우는 것이 도움이 되듯, 소프트웨어 개발에도 마찬가지입니다. 미리 어떤 식으로 만들어질 것인가에 대해 계획을 세워놓지 않으면 차후에 코드 수정을 함에 있어서 너무나 불편하고 힘들어지니 말입니다. 특히나 code reuse나 OO로 개발하시는 분들에겐 모듈디자인 문서화의 중요성이 얼마나 중요한지 아실겁니다.
이미 앞서 밝혔지만, 비행기가 날다 갑자기 떨어진다거나, 고속전차가 달리다가 갑자기 멈춘다거나 해서 사고라도 발생한다면 생각만 해도 끔찍합니다. 기기의 오작동은 하루 이틀 일이 아니에요. 소 잃고 외양간 고치는 일없이, 사전에 미리 방지하는 것이 매우 중요합니다. 특히, 소프트웨어의 장점은 쉽게 수정이 가능하다는 것인데요. 개발된 프로그램을 지속적인 패치를 통해서 버그를 수정하는 사례는 이젠 손쉽게 찾을 수 있습니다. 이를 악용해서 대충 만든 뒤에, 추가 비용을 요구하는 일은 없어야 하겠지요.
Computer Science VS. Software Engineering그럼 컴퓨터 과학 (이하 컴싸)와 소엔의 차이점은 도대체 무엇이냐고 물으실지도 모르겠습니다. 둘 다 소프트웨어관련 직종인지라 어떻게 보면 큰 차이가 없을지도 모릅니다. 다만, 컴싸는 좀 더 실용적인 코딩 자체에 중점을 두는 반면에 (코딩 자체가 바로 디자인이다는 신념), 소엔은 코딩 이전에 준비작업이라 볼 수 있는 Requirement와 Design의 문서화에 큰 중점을 둡니다. 특히 문서화에 있어서 단순히 글로 설명하는 것이 아니라, 수학적인 분석을 더 중요시 여깁니다.
일례로 "사람이 센서로부터 10cm 앞에 서있을 경우 문을 열어라" 하는 요구사항의 경우엔 센서와 사람간의 거리를 수학적으로 정하고, (예를 들어 센서의 위치 - 사람의 위치) 테이블을 통해 이 거리가 10cm미만 일 경우, 10cm일 경우, 10cm가 넘을 경우 등등 상황에 맞게 어떤 식으로 소프트웨어가 대처를 해야하는 지 구분합니다. 이런 식으로 미리 분석해서 요구사항과 디자인을 문서화함으로서, 혹시라도 놓친 경우가 있진 않은지 그리고 겹쳐지는 부분은 없는지 등등을 미리 파악해 둘 수 있습니다.
이런 수학적인 분석이 왜 중요하냐구요? 단순히 글만으로 설명된 문서는 혼동을 불러일으키기 쉽습니다. 읽는 이의 해석에 따라 180도 달라질 수 있거든요. 예를 들어서, "건물안 온도가 30도가 넘으면 자동으로 에어컨을 틀고, 30도 밑으로 내려가면 에어컨을 꺼라" 라는 문장이 있으면, 우선은 이것이 섭씨인지 화씨인지 고민하게 됩니다. 좀 더 확실하게 하기 위해선, "건물안 온도가 섭씨 30도가 넘으면 자동으로 에어컨을 틀고, 섭씨 30도 밑으로 내려가면 에어컨을 꺼라" 라는 한층 더 길어진 문장이 됩니다. 더군다나 건물안이라는 애매모호한 단어를 사용했기에 정확하게 어디에서 (창가인지, 바닥인지, 천장인지, 벽인지) 재어진 온도인지 확실치가 않습니다.
물론 토를 달자면 한도 끝도 없겠지요. 더군다나 제가 확실한 예제를 드린 것도 아니라서, "그게 뭐 어때서" 하실지도 모르겠습니다. 그렇지만, 순간 속도 몇백킬로미터를 달리는 지하철처럼 오차 하나도 큰 사고를 부를 수 있는 시스템의 경우엔 정확도가 얼마나 중요한지 실감하시리라 믿습니다.
마무리,지금까지의 소프트웨어 개발은 대부분 문서화 보다는 코딩 자체를 중요시 여겼기에, 대다수의 경우 개발자가 바뀌었을 때, 시스템활용도가 낮았습니다. 애시당초 제대로된 문서없이 타인이 개발한 프로그램을 하나에서 열까지 100% 이해하기란 쉽지가 않거든요. 영어나 한글은 일부 국가에서 통용되는 하나의 언어임에 불과하지만, 수학은 만인이 이해하는 언어라고 배웠습니다. 항상 글로 설명하던 것을 테이블(들)을 통해 수학적인 설명을 하는 것이 쉬운 일은 아니지만, 완성된 순간에는 자신만이 이해할 수 있는 디자인이 아니라, 글을 읽는 (물론 충분한 배경지식이 있다는 가정하에) 모든 이들이 이해할 수 있는 그런 소프트웨어 디자인이 나오지 않겠어요.
여기까지 끄적이고 나니, 제대로 된 설명은 한참 멀었다는 생각이 드는 군요. 아마 본 글을 읽고 더 헥갈리시는 분들이 계실지도 모르겠습니다. :)
i just can't believe me2day didn't read flickr's terms & conditions.
even i knew this was coming without reading the terms & conditions.
so typical of korean companies.
I understand start-up (or small sized) companies has to rely on some sort of outsourcing per se, be it free or paid. But putting crucial user generated contents in someone else's hands was just a poor decision, imo.
well, it's rather sad... hopefully others (Internet services) realize what they should and shouldn't do.
후 저는 개인 계정에 보내고 있어서 다행이었지요
항상 철저하신 리예님! :D
본 사건 이후로 개인자료 관리는 좀 더 철저하게 해야 될 것 같아요. 백업에 백업! 그리고 또 백업! ;)