"코딩은 결국 문제 해결을 위한 것입니다. 문제 해결을 위해서는 설계 단계에서 요구사항을 시스템적으로 구현할 수 있는 방법론을 찾아야 합니다. 이는 단순히 개발의 문제가 아니라 프로젝트에 참여하는 모두의 책임입니다. 결국, 진정한 협업이란 무엇인지 다시 한번 생각봐야 할 때입니다."

강희석 아시아나IDT IT프로세스 기획·품질관리자(기술사)는 소프트웨어 전문지 마이크로소프트웨어(마소)가 15일 서울 마포구 상암동 누리꿈스퀘어에서 개최한 ‘마소콘 2018’에서 ‘SW 품질 프로세스로 보는 SI 프로젝트 기술부채'를 주제로 발표하면서 이같이 말했다.

강희석 아시아나IDT IT프로세스 기획·품질관리자(기술사)가 15일 누리꿈스퀘어에서 열린 ‘마소콘 2018’에서 발표하고 있다. / 이신태 PD
강희석 아시아나IDT IT프로세스 기획·품질관리자(기술사)가 15일 누리꿈스퀘어에서 열린 ‘마소콘 2018’에서 발표하고 있다. / 이신태 PD
국내 SI 환경은 프로젝트 기간 대부분을 개발에 치중하는 반면, 정작 기획과 분석·설계 단계에 대해서는 소홀한 경우가 많다. 가뜩이나 시간에 쫓기는 상황인데, 기껏 설계에 신경써봐야 나중에 결국 변경될 것이란 경험이 쌓인 탓이다. 큰 틀에서 프로젝트를 진행할 때 협업의 중요성을 강조하지만, 결국 개발 단계에서야 모든 일이 시작되는 게 현실이다. 이러한 경향은 프로젝트 규모가 커질수록 더욱 도드라진다.

하지만, 강 기술사는 이렇듯 SI 프로젝트에서 기획과 설계 단계를 귀찮고 하찮은 일로 여기는 문화가 곧 기술부채로 이어질 수 있다고 지적했다. 기술부채란 기술 자본, 인력, 시간 등에 여유가 없어 서비스 완성을 위해 미리 가늠해보거나 깊이 들여다보지 못한 채 포기해야 했던 부분에서 유지보수나 업데이트 시 더 큰 이슈가 발생해 추가 자원을 들여야 하는 기술적 개념의 빚을 말한다.

그는 "구체적인 실체가 있는 건설업 등에서는 아무리 사소한 변경사항이 발생하더라도 산출물에 정확히 반영되는데, 소프트웨어 개발쪽에서는 이와 관련한 문제의식이 상대적으로 부족하다"며 "산출물이란 무언가를 이해하고, 그려내고, 써 내려가는 과정에서 처절하게 고민해 나온 결과물로, 그 다음 단계의 인용물로 활용이 될 때 의미가 있지 단순히 작성하기 위한, 보여주기 위한 문서처럼 다뤄져서는 안 된다"고 말했다.

강 기술사는 기술부채를 제거하기 위해서는 요구명세 단계에서부터 요구분석, 요구검증에 이르기까지 주체와 담당을 명확히 하고, 구성원이 다함께 이해하려고 노력하는 과정이 필요하다고 조언했다. 이는 데일리 미팅을 통해 끊임없이 의견을 교환하고, 페어 프로그래밍을 통해 대화하는 애자일 프로세스의 지향점과도 일맥상통한다.

설계 단계에서는 요구사항을 시스템적으로 구현하는 방법론을 구현해야 한다고 강조했다. 이 과정에서 공통정의가 필요한 부분을 사전에 공유할 수 있고, 개발해야 하는 요소의 중요도에 따라 리소스를 효율적으로 분배할 수 있다.

개발 단계에서는 단순히 진척률을 기반으로 성과를 관리하는 것이 과연 올바른 것인지 고민할 필요가 있다고 조언했다. 이는 다시 설계 문제와도 연결되는데, 미진한 설계 위에서 아무리 계획한 진척률을 달성하더라도 정작 개발품질 측면에서는 기준을 충족하지 못하는 경우가 비일비재하기 때문이다. 이는 협업에 대한 고민 없이 개발에만 치중하는 SI 프로젝트의 전형이기도 하다.

강 기술사는 "완벽한 설계를 위한 명확한 가이드나 도구가 있는 것은 아니지만, 모든 소프트웨어 설계가 우주왕복선 설계처럼 사소한 오류 하나라도 허용치 않는 완벽한 수준을 요구하는 것은 아니다"며 "시스템 중요도에 따라 숙련도나 인력 비율을 조정함으로써 개발 효율을 높일 수 있다면 그것만으로도 설계다운 설계를 위해 고민한 의미가 있을 것으로 본다"고 말했다.