달력

7

« 2019/7 »

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
종종 들르곤 하는 Channy님 블로그에서 S/W 공학 이야기를 보곤 나름 버닝하여 쓰고 해당 글에 트랙백 단 글입니다. 저도 어지간히 당했나 봅니다.

말장난일지 모르겠습니다만.... 그래도 1999년 12월 16일부터 개발자로 살았으니 감히 말할 자격은 아주 쬐끔 있다고 생각하고 말씀드리자면... 아직은 S/W 개발에 공학(Engineering)이라는 표현을 함부로 붙여도 되는 것 아닌가 모르겠습니다.

공학이 되려면 무릇 측정 체계(Metrics)가 있어야 합니다. 기존 공학을 돌아보면, 기존 공학에는 만인들이 널리 수용하는 kg(질량), m(길이), 초(시간), V(전압), C(전하량), Ω(저항), cal(열량) 같은 물리량에 대한 기본 단위(Unit) 및 파생 단위(속력을 표현하는 m/sec, 힘을 나타내는 N 같은)가 있습니다. 그리고 그 측정값을 가지고 계산을 수행, 어떤 결론을 이끌어 내고 예상을 하죠. 즉 측정 체계와 수학적 모델, 거기에다 제약 요소를 극복하고 경제성까지 탑재해야(제약 요소에 대한 고려가 없거나 경제성을 고려하지 않는 수학적 모델은 공학이 아닌 과학입니다. 현실적인 문제에 제약이 없을 수가 없고 경제성은 기본으로 담보되어야 하니까요) 자고로 공학이라 할 수 있지 않을까 싶습니다.

그런데 S/W 개발은? 일단 측정 체계까지 갈 필요도 없이 (그 규모를 산정하기 위한) 단위 자체가 딱 부러진 것이 없습니다.

화면 갯수? LoC(Line of Code)? 금방 알아듣지만 좀 그렇습니다. 화면 하나에 별별 것을 다 넣는 것을 선호하는 MIS 시스템은 화면 갯수로 세다가는 한 화면 개발하다 개발자 허천나는 수가 있습니다(고객이 아마 한 화면에 다 때려넣으라고 압력 넣지 않을까요? ㅋㅋ). 더군다나 MVC 모델에 입각하여 Layer로 구분하는 Web 시스템을 만드는 요새는 화면 하나 개발해도 HTML/JSP/JavaScript, Servlet, DAO, SQL 기타 등등등입니다. LoC는 COBOL 같은 것이면 모르되 한 줄에 다 붙여 써도 되고 여러 줄로 나누어도 되는 C, Java 같은 언어에게까지 적용하기는 그렇습니다(특히 돈 줄 고객은 더 말도 안된다고 펄쩍 뛰겠지요). 지금은 없어진 정통부가 밀었던 기능 점수(Funtion Point)? 이건 뭐가 그리 어려운지.. 거짓말 좀 보태면 기능 점수 전문가란 사람 마음대로 산정하는 것 아닌가 싶습니다. 개발자들이 이해하기 어려운 것은 개발자를 돕는 것이 아니죠. 유스 케이스(Use Case)? 사용자 스토리(User Story)? 그것도 결국 같이 모여 회의하면서 정제(라는 이름의 당사자들 간의 합의)하는 과정이 필요합니다. 처음에는 사람마다 다 다르게 잡을 걸요? 특히 유스 케이스 간에 extends, includes라도 표현해 보십시오. 난리가 납니다. 이렇듯 단위부터 헤아리기가 힘든 판국에 계산을 어떻게 수행하고 어떻게 결과를 얻고 수학적 모델을 통해 예측을 하겠습니까?

지금은 URL을 까먹었는데, 회사에서 소위 방법론 전문가로 활동하시는 분의 blog를 우연히 보게 되었습니다. 그 분이 교육을 받게 되었는데, 계급은 소령인 전산 담당 영관 장교(이라는 수퍼 갑)과 교육을 받게 되었답니다. 군대 같이 방대한 물자와 인원을 보유한 조직이면 정보화에 대한 욕구는 상당하죠. 제가 군 시절 보아왔던 게으른 직업 군인과 달리 그 장교 분은 갑으로써 유용한 무언가를 얻어가겠다는 열망이 대단했었나 봅니다('좋은 광고는 고객이 만든다'는 광고 업계의 격언이 이 동네도 맞습니다. 사업의 성패는 결국 갑이 좌우합니다. 감리사로부터 들은 이야기인데, 감리에서 부적격 맞는 프로젝트는 적어도 60% 정도는 갑이 사업 방향 자체를 잘못 잡은 경우가 허다하답니다. 그래서 이렇게 공부하는 갑은 정말 을 이하 입장이 될 수 밖에 없는 저로써도 매우 반갑습니다). 소위 IT로 밥 먹고 산다는 동료 수강생들과 강사에게 이것저것 물어보셨다던데 blog 주인장 분께는 S/W공학이 전문이라 하니 S/W 규모 산정에 대해 물어봤나 봅니다(규모 산정이 결국 Man/Month 결정으로 이어지고 결국 돈이 결정나는 것이니 갑에게는 이것만큼 중요한 일이 없습니다. 덩치는 산만한데 규모를 쥐꼬리로 잘못 잡으면 일이 제대로 되겠습니까? 그 사업 수행하는 을 이하는 물론 갑도 목아지가 간당간당할 겁니다). 그래서 어떤 유명한 S/W공학자 분의 표현을 인용하여 대답했다 합니다. 표현이 거칠지만 요지는 다음과 같습니다. "그 일을 오래 해 본 전문가가 통밥으로 잡는 규모가 제일 정확하다."

즉, 경험이 짱이라는 거죠. 이것은 계산으로 결과가 딱딱 나오는 공학(Engineering)이 아니라 장인(Craftman/Artisan)이 하는 공예(Craftmanship)라는 뜻입니다(그리고 공예는 예술(art)이기도 하지요). 일부 그러한 애매모호성을 조금이라도 줄이기 위한 수학적 모델 티를 내 보려고 도입하는 게 통계 정도? 그나마도 아까 말씀드렸듯 유명한 S/W공학자가 추천한 것이 "경험 많은 개발자의 감"인 것으로 보아 그 통계는 전통적 공학에서 적용하는 통계만큼도 효과가 없어 보입니다. 요사이 실전적이라 환영 받고, 전통적인 소위 S/W공학자들 및 교조적인 방법론자들의 경각심을 일깨운 기민한(Agile) 개발 방법도 종국에 보면 짬밥 많은 "개발자들의 경험"에서 우러나오는 'Agile Manifesto'를 근본 원리로 삼고 있지 않겠습니까? 이러니, S/W 공학(Engineering)보다 S/W Craftmanship이 더 정확한 표현 아닐까요?

그동안 S/W 공학은 말 그대로 공학적 접근이 씨알도 안 먹히는 동네에서 말 그대로 공학적 접근을 시도하다 욕만 바가지로 먹은 것이 아닐까 합니다. 결론! 공학적 접근은 신통찮고, 그래서 S/W 공학이란 말은 난센스다! 되겠습니다. 뭐, Word Perfect를 외국어의 한국어 표기법에 따르면 워드퍼펙트가 맞지만 하도 워드퍼펙 워드퍼펙 해서 관례를 따라 워드퍼펙 하듯, 실제로는 S/W Craftmanship이 더 정확한 표현일지 몰라도 관용적으로 S/W 공학이라고 쓴다면야 할 말 없지만요.

(사족 1)

요새는 Agile이 세를 얻어서인지, 방법론자들도 변경 요청서 작성, 검토하는 식의 형상 관리보다 CVS나 SVN Repository가 더 실용적이라는 것은 인정하는 것 같습니다. 참고로 형상 관리는 CMM Level 2를 따려면 반드시 해야 하는 KPA(Key Process Area) 중 하나입니다. 그런데 CMM 심사원이 CVS나 SVN 잘 쓰고 있으면 일단 그 KPA는 만족했다고 평가할라나는... 모르겠네요.

(사족 2)

CMM 이야기를 더 하겠습니다. CMM Level 2엔 code에 대한 다른 이가 작성한 code에 대한 inspection(남의 code를 들여다 보는 것. '중이 제 머리 못 깎는다'고, 자기 code 오류는 자기는 잘 못 보잖아요)도 KPA입니다. 2002년도에 CMM 사내 전문가가 저 있는 project의 CMM Level 2 인증을 돕기 위해 교육을 했었는데, 그걸 듣다 다 짠 걸 inspection하고, 했다고 기록 남기는 것보다 막바로 Pair Programming을 하는 것이 더 실전적이지 않냐고 질문했더니 '글쎄요'라고 중언부언하던 생각이 납니다. 6년이 지난 지금은 어떻나 참 궁금하네요. 험프리(Humphrey) 아저씨(CMM의 황제 소리 듣는 그 험프리)는 아직 말 없데요?

(사족 3)

CVS, SVN 사용이 많이 일반화되었지만 감리(auditing)나 CMM 심사원 중에서 변경 관리 여부(감리를 하기 보단 받는 쪽이지만, 그래도 2006년에 CISA 시험을 합격한지라 아주 쬐끔 안다고 나불거려 보면, 감리란 위험을 잘 회피하거나 회피 불가능 시 관리는 하고 있는지를 보는 활동입니다. 그 위험 중 일부가 보안이고요. 변경은 기존 개발 산출물을 병신 만들 수도 있는 '피할 수 없는' 위험이므로 관리를 해야 합니다)를 감사하면서 Word, Excel file은 까볼지언정 SVN log 따위를 보려 하는 감리사나 심사원은 아직까지 만나보지를 못해서, 참... 감리 받으려고 문서 또 써야 하나? IT 감리는 S/W 공학을 기반으로 위험 요소를 식별해 내니, 감리 받다 보면 현실적인 이유로는 S/W 공학이 이래서 불만이죠 ㅋㅋ.

그나저나 CISA 합격자답지 못하게 위험(Risk)과 위협(Threat)를 구분 못하고 쓴 감이 없지 않아... (-.-)a

(사족 4)

"아, 문서요? 위키 보세요, URL은..." 감리사나 심사원에게 이러면 어떤 반응이 나올 지 참 궁금합니다(사실 감리사나 심사원들만이 아니라 고객이라는 갑들도 인수 인계 산출물로 워드 파일이 아닌 위키를 주면 어떨지 참 궁금합니다).

(사족 5)

개인적으로 박사를 하고 나왔더라도, 학교 졸업하고 실 프로젝트에서 개발도 안해보고 방법론 전문가, S/W 공학 전문가, 감리, modeler, QA가 된 사람(말도 안된다고요? 실제로 있습니다. 예전 회사의 옆 동네였던 S/W공학센터라는 곳의 센터장이란 분은 '꼭 해 봐야 아느냐'는 말까지 하시더군요)은 좋아하지 않습니다. 비현실적이고 교조적인 경우가 많기 때문이죠. 그래서 개발자들에게 불만을 사게 되는 경우가 많아, 윗사람을 등에 업고 강압적으로 굴던지, 똑똑하고 말 잘하고 입바른 개발자들이라도 있으면 현실감 넘치는 그들의 소리에 발려 찍소리도 못하던지 둘 중 하나입니다. 반면 이 경험이 있는 방법론 전문가, S/W 공학 전문가, 감리, modeler는 유돌이도 있고 의미심장한 말도 곧잘 하고 현실적이면서도 새로운 시각을 곧잘 제공하기도 하여 좋아하는 편입니다. 지금 저랑 같이 일하는 QA(다른 회사 사람입니다)는 본인이 inspection도 하고 test도 할 줄도 아는 사람이라 참 만족스럽습니다(아직 수양이 덜 되어서 배알이 꼴리면 빙글거리며 까대기도 하는 성격인데... 헐~. 그럴 일이 없어 다행입니다). QA라면서 test나 inspection은 하나도 안하고 맨 Office랑 친한 사람들만 징하게 봤는데 말입니다.

(사족 6)

최근 방법론자들은 개발에 대해 머라고 하는 것이 영 예전 같지는 않자, 경영진들 쪽으로 가서 IT Governance라는 이름을 붙여 돈을 벌려 하는 것 같습니다. 그들이 하는 일들은 왜 그렇게 늘 문서 위주고 절차 위주고(문서/절차 중시.... 딱 관료주의죠), 그들의 프리젠테이션 장표 보면 복잡해서 정신사납고, 하는 말은 뭔 소린지 헷갈릴까요?
Posted by 하얀 말