'소프트웨어 공학'에 해당되는 글 2건

  1. 2011.09.04 NHN은 이렇게 한다! 소프트웨어 품질관리
  2. 2010.11.28 글로벌 소프트웨어를 꿈꾸다 - 김익환
NHN은 이렇게 한다! 소프트웨어 품질관리 - 8점
유석문 외 지음/위키북스

개인적으로 이 책을 어제 새벽에 다 읽었는 데, 아는 부분이나 관심있는 부분만 집중적으로 보고 나머지는 술렁술렁 넘어갔다. 그런데, 이렇게 읽은 이유는 내가 해당 책안에 기재된 자바나 C/C++ 언어를 사용하지 않았기 때문이다. - 학교 다닐때도 VB만 썼고 회사에서도 그랬다. 그래서 전체적인 흐름위주로 이 책을 읽었는 데, 단순히 NHN의 내부적인 소프트웨어 품질관리 측면이 아니라 소프트웨어의 품질관리를 어떻게 해야하는지에 대한 하나의 좋은 사례로 보아도 무방하지 않을 까 하는 생각이 들었다. 

그런 생각이 들은 이유는 일단 자바/C/C++ 기반한 소프트웨어 환경에 대해서 이야기를 하지만 코드의 소스버전관리, 복잡도 관리, 커버리지관리, 테스트 케이스 및 자동화, 중복코드분석, 지속적인 통합 (CI) 등에 대해서 개론적인 이야기들과 실제 자신들이 2009년부터 내부적으로 개발하고 테스트해온 실제 문제점들에 대해서 정리를 잘 해놓았기 때문이다. 

사실 난 전산 비전공자이고, 이러한 소프트웨어 공학적인 측면에 대해서 공부를 해본적도 없지만 최근에 들어서는 이 것이 개발자들이 반드시 수치해석, 알고리즘, 소프트웨어 공학, OS 공부는 반드시 해야 한다는 생각이 든다. 나처럼 단순히 개발을 혼자 독학으로 익힌 사람은 이런 아키텍쳐와 전체를 관리하는 것에 대해서 이해도가 떨어지는 데, 이 부분은 반드시 필요하다고 생각되어진다. 이 책을 읽게 된 계기는 내가 개발자가 아닌 설계자와 테스터로서 일을 시작하게 되었는 데 , 자바 개발자에게 설계서를 주고 그것을 이력관리할 방법을 찾아야 했기 때문이다. 메일로만 주고 받으면 다른 사람이 변경 사항과 변경사항-소스 연결 부분에 대해서 어떻게 알 수 있지라는 것과 이슈트랙킹(혹은 버그 트래킹)에 대해서 고민을 하게 되었기 때문이다.


실제로 자바를 내가 모르지만 난 설계서를 주고 프로그램 개발이 되면 단순히 사용자 입장에서 테스트를 하고 검증이 되면 개발 서버에서 운영서버로 적용하는 과정을 거치고 있는 데 이 절차에 대해서 다시 한번 생각하고 있는 중이기 때문이다. 이 책에서 나오는 각종 오픈 소스 툴들도 사실 이름은 들어서 알고 있지만 적용에 대해서 개발자와 의견을 나누고 개발서버에 이것을 어떻게 적용할 지에 대해서 사전 검토와 공유가 필요하기 때문이다. 

우리나라 소프트웨어 산업이 위기라고 한다. 개발인력을 많이 늘린다고 한다. 그런데 내가 보기엔 개발인력이 문제가 아니라 우리에게는 소프트웨어를 설계하고 전체를 관장하고 품질을 높이도록 하는 이런 방법론적인 것과 시스템을 갖추는 것에 더 집중해야 한다고 생각한다. 막말로 설계가 완벽하면 개발은 할 수 있지만, UI를 다 만들었는데 고객이 "어, 이거 아닌데요"하면 개발자는 정말 돌아버리게 된다. 

이 책에는 주로 QA쪽에 대해서 집중적으로 다루다 보니 이슈트랙킹에 대해서는 다루지 않았는 데 이 부분에 대해서는 다루었으며 하는 아쉬움이 남는다. 그 부분이 사실 내가 가장 지금 시점에서는 필요로 하는 부분인데 말이다. 지금 나는 이슈 트래킹 시스템을 두 가지를 보고 있다. 많은 분들이 두 가지중에서 쓰시는 거 같아서 고민을 하고 있다. 

Trac(오픈소스 무료) - http://trac.edgewall.org
JiRa(상용) - http://www.atlassian.com/software/jira/





댓글을 달아 주세요

글로벌 소프트웨어를 꿈꾸다10점
김익환 지음/한빛미디어

회사에 처음 입사를 하고 학교에서 교수님 밑에서 프로젝트를 하면서 혼자서 독학한 프로그래밍 경력으로 일을 하게 되었다. 처음 맡은 일은 방화벽/서버/네트워크 관리였는 데, 사실 내가 해본 것은 서버정도였지 학교에서 대규모의 네트워크를 볼 일도 없었고 방화벽을 내가 관리할 일도 없었다. 
아마도 이 부분은 지금의 전산전공자들도 마찬가지일거라고 생각을 한다. 더구나 공학전공자이긴 하지만 비전공자인 내가 더하면 더했지 모르는 것 투성이였다. 때문에 저자가 말한 것과 같은 사수-조수 구조의 한국 기업문화에서 욕도 먹고 밤도 새고 사고도 치고 주말에는 그냥 혼자서 회사에 나와서 문서를 찾아서 읽고 확인하고 스스로 자료 정리를 하고 수집하는 일들의 반복이었다. 

중소규모의 기업들이 그러하듯이 멀티 플레이어를 요구하는 데, 개발일도 병행하는 상황이 되었다. 그런 와중에 또 다시 업무를 정확하게 파악하지 못하고 혼란을 겪게 되었다. 이 과정에서 가장 불만족 스럽게 생각했던 부분이 문서로 정리된 것이 거의 없다는 점이었다. 일반 한국 기업들이 대부분 이러하다는 이야기를 책에서 보면서 과연 우리가 잘하고 있는 것인지 의심스러워졌다. 

저자의 미국 기업의 경험에 따르면 문서로 50%, 프로세스 45%, 선배 5%인데, 문서고 프로세스고 없는 거 같은 느낌이 들었다. 그렇다고 전임자가 그때는 회사를 그만둔거라서 난 결국은 소스를 하나씩 까보면서  디비랑 비교하면서 흐름을 파악하고 유지보수하는 데에 온 신경이 집중되고 결국은 거의 디폴트로 주말 특근이 예정되거나 퇴근시간이 늦어지게 되는 일들이 생겼다. 그런데, 이걸 개선해야지 하고 생각을 했다가 결국은 저자가 지적한 바와 같이 시간이 없어서 문서 작업은 안하고 그냥 막 코딩해버리고 나중에 되면 그것 조차도 정리하지 않으면서 내가 코딩한 것조차도 시간이 오래 흘러서 내가 왜 이렇게 했나 하는 이런 문제가 생기는 것이다.
그렇다고 주석을 제대로 그때는 달지도 않았던 거 같다. 우리도 2-3년전에서야 소스 코드 버전관리를 하고 있지만 과연 커밋할때 주석 내용제대로 입력하고 하는 것인지도 난 의심스럽다.

지금은 내가 책에서 언급한 바와 같이 개발에서 관리쪽으로 이동중인데 과연 이것이 적절한지 스스로에게도 의심이 된다. 그렇다고 내가 신규 기술에 대한 충분한 기술 습득을 하고 있는 것도 아니고 말이다. 난 그냥 코더였던거 같은 생각이 지금 든다. 엔지니어라고 할 수 있을런지.. -트위터의 바이오에서 엔지니어라는 말을 지워버려야겠다. 

이 책에서 언급하는 것은 정말 개발자 자신에게 쿡쿡 찔러대는 말들 뿐이다. 
특히 그 미신들은 정말 아주 가슴을 쑤신다. 개발자 부분에 보면 이런 말들이 나온다. 
- 빨리 코딩을 시작합시다. 그래서 빨리 끝냅시다.
- 제품을 만들 때까지 테스트를 못한다.
- 소프트웨어 공학을 적용할 시간이 없다.

이 말들 사실 비겁한 변명같다. 이슈관리 시스템을 넣고 소스 검증 시스템도 돌리고 해서 쓰자고 이야길 한 적이 있지만 아직도 현실적으로 어렵다는 이유로 우린 미루고 있는 것은 아닌지 고민해봐야 하지 않을까?
정말 우리가 해보고 어렵다고 이야기를 해봤을까? 분석-설계-구현이라는 것을 다 알지만 대충 분석하고 그걸로 설계-구현까지 바로 연결해서 문서작업도 제대로 안하고 그냥 막코딩해내고 있는 것은 아닐까? 하는 생각이 든다. 단지 이게 개발에 국한된 이야기는 아닐 것이다. 운영도 하려면 이런 과정을 거쳐서 해야 하는 데 과연 그렇게 하고 있는 것인지 의문이 든다. 그리고 운영은 이런 방법에 대한 가이드가 소프트웨어보다도 적다.

일단 나는 소프트웨어 공학 책을 한권도 읽어보지 않았는 데, 읽어야하고 고민해야 한다는 생각이 든다. 특히, 이슈관리 시스템은 전에도 생각했지만 반드시 추가로 필요하다는 생각을 하게 되었다. 자료를 좀 더 찾아봐야 겠다는 생각이 들게 되었다. 

마지막으로 이 책을 개발하시는 분들이나 경영진들께서 좀 읽어보시고 개발 일정을 넉넉하게 줘서 생각하고 시스템 전체를 보고 여러가지 고민해서 동료와 같이 검토해서 설계하고 구현하도록 했으면 하는 바램이다.




댓글을 달아 주세요



티스토리 툴바