(Essay#25) 논문 작성 과정
기말에세이로 어떤 내용을 작성해볼까 고민하다가 내년 2월에 있을 소프트웨어공학학술대회에제출하려고 작성해놓은 논문을 열어놓고, 곰곰이 생각해보니 이 논문을 작성하는 과정을 어떤 식으로 진행했는지를 에세이로 남겨보면 좋을 거 같아서 이번 글쓰기를 시작했다.
우선 논문 제목을 정하는데 가장 많은 시간이 걸렸다. 논문 제목을 정하면서 나는 항상 논문의 모든 내용을 포괄하면서도 어떤 내용인지 궁금하게 호기심을 자극시키는 제목을 짓기 위해 노력한다. 이번에 작성한 논문은 사실 별게 아닌 그 동안 회사에서 업무로 진행하였던 테스트 관리 도구를 도입한 내용을 정리한 것이다. 작년까지 우리 회사에 구축된 테스트 프로세스와 잘 연계할 수 있는 도구를 여기저기서 좀 찾아보고 써보면서 시범 적용을 한 내용이다. 그리고 빌드 자동화와 관련돼서 요즘 많이 쓰이고 있는 자동통합빌드 도구에 대한 내용도 같이 포함을 시켰다. 그러다 보니 논문 제목을 두 가지 도구의 도입을 모두 포함하도록 지으려다 보니 좀 힘들었던 거 같다. 이렇게 고민 끝에 짓게 된 논문 제목은 “효과적인 테스트 관리를 위한 테스트 환경 구축 사례”라고 결정하였다. 소프트웨어공학학술대회에 발표하는 산업체 논문은 일반 논문과는 다르게 업계에서 적용하고 있는 실제 소프트웨어공학 적용 사례를 요구하고 있기 때문에 대부분이 이런 사례 위주로 많이들 발표를 한다.
논문 제목을 정한 다음으로 진행했던 작업은 목차를 정하는 일이었다. 일반적인 논문이 연구배경à관련연구à본론à결론 순으로 작성이 되기 때문에 이 큰 목차를 기반으로 그 하위에 어떤 내용을 작성할지를 구상하였다.
연구 배경은 대부분 기존에 작성되어 있던 자료들을 많이 참조하여 작성을 하였다. 기본적으로 국방SW의 특징, 방위사업청 정책, 회사 내부의 테스트 활동 관련된 요구사항들에 대해서 간단히 설명을 하고 현재 회사에서 당면하고 있는 문제점들이 나타나게 된 배경을 설명하였다. 핵심이 되는 내용은 현재 연구개발 사업의 70%이상이 구현 및 테스트 기간이며, 조사된 데이터에 의해 이 테스트 기간이 프로젝트 별로 그 수준 차이가 크다는 것을 화두로 던졌다. 평균 30~60개월의 사업 기간 중 대부분의 기간을 테스트 활동을 수행하고 있으나 이를 체계적으로 관리하지 못하여 프로젝트 간 편차가 크다는 것을 논문에서 해결하고자 하는 문제점으로 지적하면서 연구 배경을 이끌어내었다.
관련 연구로는 ISO/IEC/IEEE 29119-2에서 다루고 있는 Test Processes를 살펴보고, 어떤 테스트 관리 활동을 표준에서 하도록 하고 있는지를 조사해보았다. 그리고 국내외 테스트 관리 도구를 비교 분석하여 장단점을 기술하고, 테스트 관리 활동에서 어떤 지표들을 관리할지를 관련 논문에 있는 내용으로 정리하였다. 관련 논문은 작년에 작성한 무기체계 SW 테스트 성과 지표 선정을 참조하였다.
본론에는 연구 배경에 화두를 던진 문제점에 대해 관련 연구를 바탕으로 해결방안을 제시하는 논문의 핵심 내용을 다루는 부분이다. 연구 배경에도 언급되었던 프로젝트 별 테스트 기간의 편차가 크게 나타나는 점을 해결하기 위해 테스트 프로세스를 표준화한 관리 시스템을 통해 테스트 관리 활동을 강화하는 해결방안을 제시하였다. ISO 29119나 TMMi에서 중요하게 다루고 있는 Risk base testing을 기반으로 제품 위험à 테스트 컨디션à테스트케이스à테스트프로시저à결함으로 이어지는 각각의 테스트 데이터를 시스템에 등록하고 추적 관리하게 할 수 있는 테스트 관리 도구를 도입하였다. 또한 이렇게 축적된 테스트 데이터를 사내 테스트 성과 지표와 연결시켜서 자동으로 Reporting을 해주는 기능을 별도로 개발하였으며, 향후에는 이런 축적된 테스트 데이터를 자산화하여 재사용을 편리하게 할 수 있도록 시스템을 구성하였다. 또한 무기체계 소프트웨어에 대해 방위사업청에서 의무적으로 적용하고 있는 SW 신뢰성 시험(코딩규칙 검증, 실행시간 오류 검출, 코드실행률 확인)에 대해 코드 변경 시 재시험을 쉽고, 간편하게 할 수 있는 자동통합빌드 시스템을 구축하여 정적 분석 도구를 연동시켰다. 자동통합빌드 시스템을 통해 빌드 및 정적 분석 결과를 웹에서 즉각 확인하고 조치할 수 있으므로 개발 단계에서도 SW 신뢰성 시험을 수시로 수행할 수 있는 시스템을 구축한 것이다. 이 구축된 시스템을 통해 반복적인 시험 환경 설정 시간을 단축할 수 있으며, 여러 가지 분산된 빌드 환경을 통합관리하므로 테스트 모니터링 또한 강화되는 효과를 거둘 수 있었다. 마지막으로 본론의 뒷부분에는 각 시스템의 주요 기능에 대해 화면 정보와 함께 기능을 설명하였다.
결론에서는 본론에 정의된 핵심사항을 정리하고, 본 사례 연구를 통해 구축된 시스템으로부터 향후 어떤 일들을 더 해볼 수 있겠다는 형식으로 향후 계획을 기술하였다. 다양한 테스트 데이터를 분석하여 테스트 성과 지표 간에 상관 관계를 분석하고, 테스트 기간에 어떤 영향을 미치는지 그리고 이들 간에 통계적 관계를 바탕으로 SW 신뢰성 모델을 개발하여 이를 예측하는 연구 등을 앞으로 진행해볼 수 있겠다고 결론을 내렸다.
회사 내부의 SW공학 활동으로 진행했던 일을 논문으로 작성하다 보니 논문 작성 과정에서 그냥 막연하게 진행하던 업무들이 논리적인 연관관계가 있음을 자연스럽게 이해하게 되었고, 앞으로 더 확장하거나 개선해야 되는 일들도 식별할 수 있게 되는 계기가 되었다. 중요한 업무이거나 그렇진 않은 사소한 일들에도 그러한 현상 및 문제점이 나타나게 된 이유가 분명히 있을 것이고, 그것들을 해결하기 위해서 많은 또 다른 일들을 일반적으로 하게 된다. 논문을 작성하는 과정도 마찬가지인 거 같다. 무엇인가 한 주제에 대해서 내가 겪고 있는 문제점들이 있고, 그러한 문제점들은 이미 다른 분들도 겪었으며 또한 해결하려고 노력을 했을 것이고, 그 노력에 내가 조금 더 다른 방법으로 해결하고자 했다면 그러한 것들을 논문에 담으면 되는 것이다.
대학원에 입학하기 전에는 논문 작성이 정말 많은 지식과 노력이 필요하다고만 생각하였는데 이제는 내 주변에 조그마한 일들도 이런 논문 작성 과정과 같이 조금 더 고민해보고 해결하려고 노력을 했다면 아무리 사소한 노력들이라도 남들이 하지 않는 다른 방식의 것이라면 논문의 주제가 될 수 있으며, 또한 연구의 시작(끝은 아님, 반드시 연구의 문제가 실험적으로 해결되거나 효과가 있다고 증명이 되어야 연구의 끝이라고 할 수 있음)이 될 수 있다는 사실을 알게 되었다.