본문 바로가기
Development

개발자에게 필요한 문학적 센스.

by 돈가방 2007. 2. 27.

요즘 회사에서 새로운 제품의 요구스펙( 엄밀히 말하면 제품을 구성하는 소프트웨어)을 기술한 문서를 작성하고 있다. 벌써 꽤 긴 시간을, 문서 작성에 소비하고 있다.

소프트웨어 엔지니어는 문서 작성에도 능통해야 된다는 것을 최근에 느끼고 있다. 제목에도 썼지만, 소프트웨어 개발 관련 문서를 작성할때 "문학적 센스"의 필요성을 절실히 느낀다.

 

여기서 말하는 문학적 센스란, 흔히 떠올리는 사전적 의미의 문학과는 약간 동떨어진, 개발자에 의한, 개발자를 위한 문학적 센스를 뜻한다. 이 센스가 잘 반영된 문서는, 흔히들 말하는 "공돌이"들이 반기는 문서로 통하게 되는데, 문제는 이 문서가 유효기간이 있어서 제품 개발 당시에는 그렇게 간결하고 군더더기 없이 보이던 것이 세월이 흘러 - 그래, 1년이라고 치자 - 다시 꺼내보면 이게 도대체 무슨 내용인지 알 수가 없는것이다. 심지어 자기가 작성한 문서도 이해가 안된다!!

절대 돈가방만의 의견이 아니다. 솔직히 모든 개발자들이 어느정도 수긍할 것이라고 감히 장담한다.

근데, 왜 이런 현상이 발생하는 것일까?

일본어라서?

쓰여진 문장과 설명은 간결하기 그지 없는데...

돈가방이 생각하건데, 그건 일종의 집단최면(납기에 ㅤㅉㅗㅈ기는 동료들이 똑같은 상황에서 똑같은 생각을 하게되는...)에 걸린 상태에서 인스펙션이 이루어지기 때문이 아닐까.

제품 개발이 끝나고 팀이 공중분해 되면, 자연히 집단최면에서 깨어나 또다른 최면에 걸리게 되는거고...


- 소프트웨어 설계 문서 유효기한의 법칙 by 돈가방-

모든 소프트웨어 설계 문서( UML이라고 예외는 아니다 )의 해석가능한
유효기한은, 작성한 날, 그러니까 인스펙션이 종료된 어느정도의
퀄리티를 가지는 상태가 된 날부터 6개월이내 이다. 믿거나 말거나.


가장 흔히 경험하는 일이, 문서 작성자가 다른 부서로 이동하거나 회사를 그만둔 경우인데, 이럴 경우에는 그 작성자의 설계문서가 일종의

추리소설로 곧잘 변신하기도 한다.

X: "여기, 어.. 이부분이야.. 여기서 왜 이 모듈로 메세지를 보내지?"
돈: "설계문서에 그렇게 적혀 있쟎아요. 메세지를 보낸다 라고"
X: "누가 몰라? 이유를 묻고 있쟎아 이유를..이건 분명 음모야. "
돈: "아 몰라요. 내가 안썼다니까요. 급하면 소스코드 까보시던지."

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

오늘 회사에서 신변정리 중 "공학인을 위한 문서작성법"이란 책을 발견했다. 내용을 읽어보니 아주 서늘한 기운이 들었다. 이제껏 말한 "문학적 센스"를 기르는 방법이 아주 치밀하게, 상세하게 적혀 있었다.

허나... 지금 나에겐, 일반인을 위한, 글쓰는 법에 대한 책이 필요하다.

흠. 그렇다고 문서의 간결함과 깔끔함에 반대 하는것은 아니다. 단지 소프트웨어 개발자들에게 일반적인 문학적 소양도 필요하다는 것을 말하고 싶을뿐. (코딩 지저분하게 하라는게 아니고)

코딩 룰 세뇌교육의 부작용으로 인해, 지금 이 글을 쓰면서도 왠지 인덴트가 불량한것 같아 안절부절 하는 돈가방.




"공돌이를 위한 문학적 센스", "일반인을 위한 그것"...

황금비를 아는 방랑자는 제발 리플 좀 달아 주시라.