기고 | SW 프로젝트 속도를 높이는 11가지 방법

CIO
전략적 의사결정은 소프트웨어 프로젝트 속도에 박차를 가해 비즈니스 기회를 활용하는 데 도움이 될 수 있다. 하지만 IT리더는 서둘러서 프로젝트를 끝내는 것만이 능사가 아님을 인지하고 주의해야 한다.
 
ⓒGetty Images Bank


IT리더와 고객은 소프트웨어 프로젝트가 신속히 마무리되기를 원한다. 그러나 속성 개발은 오류 코드, 부실한 테스팅, 불완전한 솔루션, 심지어 보안되지 않은 소프트웨어로 이어지기 쉽다. 소프트웨어 프로젝트가 실패하기를 원하는 사람은 없겠지만 때에 따라 특정 상황, 예를 들어 시장 환경, 비즈니스 요구, 기회의 여지로 속도를 우선시하는 선택이 정당화될 수 있다. 

소프트웨어 개발은 단순히 합리적 노력에 그치지 않는다. 이는 요령이기도 하고 여러 조직에서 비즈니스 전략의 불가결한 부분이기도 하다. 이들 요소가 서로 접하는 지점에서 개발 프로세스를 좀더 효율적으로 조정할 가능성이 존재한다. 물론, 이는 효과적이고 적절하며 단순하고 안전해야 한다. 완전한 소프트웨어를 개발한다는 꿈을 접고, 그 대신 취사선택이 필요함을 인지하고 프로젝트를 간소화하는 결정을 내려야 할 것이다.  

IT리더가 소프트웨어 프로젝트에 속도를 내고자 할 때 고려할 수 있는 11가지 전략적 결정을 소개한다. 

이해관계자의 희망 사항을 조율하라 
모두가 의견을 제시하고 싶어 한다. 마케팅팀, 출하 부서, 회계팀의 이해 관계자는 커다란 희망을 안고 회의실로 들어선다. 요령은 성취하기 가장 쉬운 희망을 찾는 것이다. 언젠가 필자의 소프트웨어팀은 회의를 거듭하면서 단순히 한 양식 필드에 미리 채워진 기본값들을 추가함으로써 데이터 작성자의 부담을 크게 덜 수 있음을 발견했다. 하루에도 수없이 처음부터 양식을 작성하는 판매 직원이 수없이 많았다. HTML에 문자를 몇 개 더 집어넣는 것만으로 우리 팀은 마치 천재처럼 대우받았다.  

이해관계자가 현실을 직시하도록 하는 것은 프로젝트의 범위를 제어하는 데 유용하다. 이해관계자가 소소하면서도 매우 가치 있는 기능과 개선에 집중하도록 함으로써 프로젝트 기간을 크게 앞당길 수 있다.  

개발자의 과욕을 억제하라 
그러나 버릴 수 있는 것은 이게 전부가 아니다. 개발자 역시 현실을 직시해야 한다. 프로젝트 목록에 있는 모든 항목이 개발자에게는 똑똑하고 참신하고 믿기 어려울 정도로 시간을 소비하는 일부 전문 용어를 마침내 실현할 기회로 보인다. 화면상에 2개 열이 정렬되지 않았는가? 그렇다면 이제 다중 그라디언트 전력 하강 최적화 퀀텀 머신러닝 알고리즘(multi-gradient power descent optimizing quantum learning algorithms)을 이행하는 수학 함수로 전체 스택을 다시 작성할 시간이다. 

개발자의 열정은 흔히 일정을 가속하는 데 필수적이지만, 그러한 열정이 간소화된 목표를 지향하도록 하는 것이 매우 중요하다. 

기능을 배제하라 
요구 사항을 잘라낸다면 나태하다는 인상을 줄 수 있다. ‘모든 것’을 작은 규모로 재정의한다면 ‘모든 것’을 더 빨리 달성할 수 있다. 

한편 분산보다 집중이 필수적이고 유용한 경우도 있다. 영리한 접근법이란 누락시킨 기능을 다음에 처리하기에 충분할 정도로 기반을 확고히 다져 두는 것이다. 예를 들어 데이터베이스 스키마는 향후 추가될 것으로 예상되는 보강에 대비할 수 있어야 한다. 스키마를 약간 조절하는 것이 전부라면 이번에 누락된 기능을 다루어야 할 때 시간을 절약할 수 있다.  

테스팅을 간소화하라  
코드를 전개할 때 어려운 점 한가지는 실무에 투입하기 전에 테스트해야 한다는 것이다. 최근에는 모든 것을 독립적으로 행할 수 있는 소형 프로젝트로 나누는 것이 유행이다. 이들 프로젝트를 개별적으로 테스트한다면 테스팅이 훨씬 더 많아질 것이다. 수십 개의 소형 프로젝트로 채워진 최신 마이크로서비스 아키텍처라면 수십 번의 테스트를 거쳐야 한다. 

테스트를 건너뛸 수는 없다. 요령은 함께 작용하는 여러 프로젝트를 동시에 테스트하는 것이다. 때에 따라 여러 부분을 한데 묶음으로써 개별 테스트의 필요를 제거할 수 있다. 
 

---------------------------------------------------------------
프로젝트 관리 인기기사
->프로젝트 실패를 경고하는 적신호 5가지
->칼럼 | 솔직히 말하자, 프로젝트 후원자와 관리자가 문제다
->프로젝트 리더가 기억해야 할 '사람 우선' 전략 4가지
->프로젝트 관리·추적은 이렇게 '7가지 체험 팁'
->"기대치 조율은 이렇게" 프로젝트 관리 11가지 팁
->"온라인 협업과 프로젝트 관리에 그만!" 무료 툴 7선
->예산•일정•진척도 관리 도와줄 PM툴 5선
->폭포수 프로젝트 관리에도 민첩성이 필요하다
-> ‘에이스프로젝트 · 베이스캠프 · 조호 프로젝트’··· PM 툴 3종 비교분석
-> PM이 대비해야 할 흔한 프로젝트 문제 7가지
---------------------------------------------------------------

아키텍처를 단순화하라 
기능을 배제하고 일부 작업을 연기할 생각이라면 그와 동시에 아키텍처를 재고할 수 있는 경우가 있을 수 있다. 그렇지 않은 경우 또한 있다. 

기능을 다음 분기, 심지어 다음 해에 처리할 생각이라고 해도 이의 기반을 조성해 두는 것이 좋다. 그러나 이들이 필수적이지 않다면 아키텍처의 큰 부분을 생략하는 것도 나쁘지 않다.

 


성능 보증을 줄이라 
사람들은 즉각적인 답변을 원하고, 그러면서도 태풍과 지진이 동시에 발생할 경우에 대비해 지리적으로 별개인 3곳의 데이터 센터에 데이터를 복제해 두어야 한다. 그런 풍요로운 시절이 있었다. 누가 완벽함을 원치 않겠는가? 

일반적으로, 고성능은 여러 가외의 캐싱, 로드밸런싱, 복제 계층을 의미하고 이러한 가외의 계층은 구축하고, 설정하고, 디버깅하고, 보수하는 데 시간이 걸린다. 개발 시간을 줄이는 가장 간단한 방법은 화면 갱신에 시간이 조금 더 걸린다거나 사소한 고장으로 인해 데이터가 소실되는 것에 대해 이해관계자가 관대해지도록 설득하는 것이다. 모든 프로젝트가 뇌 수술처럼 정밀하거나 확실할 필요는 없다. 

기존의 코드를 활용하라 
시간을 많이 소비하는 가장 간단한 방법은 신기술을 탐구하는 것이다. 장기적 관점에서 다음 세대에 투자하는 것은 중요하다. 그러나 누군가가 신속한 완결을 재촉하는 상황이라면 그런 것에 신경 쓸 겨를이 없다. 과거 수많은 프로젝트에서 쓰였던 언어와 데이터베이스를 다시 사용한다면 더 빠르고 더 간단하게 작업을 마무리할 수 있다. 움직임이 빨라질 것이고, 간혹 재사용할 수 있는 코드 뭉치가 나오기도 한다. 그뿐만이 아니다. 개발자가 프로젝트 사이를 한층 쉽게 오갈 수 있는 일관성도 얻을 수 있다. 

기술 부채를 수용하라 
개발자는 무언가 완수하고 싶은 작업이 있을 때 흔히 ‘기술 부채’를 이야기한다. 제한적 또는 속성 솔루션에 전념하다 보면 교정이나 보강 작업을 뒤로 미룰 수 있다. 기술 부채는 고려해야 할 중요한 개념이긴 하지만, 사람들은 무언가를 합리화하려 할 때 이를 들먹이기도 한다. 

일부 기술 부채는 문제가 없다. 최신 데이터베이스나 최첨단 언어 기술이 항상 필요한 것은 아니다. 때에 따라 일부 경이로운 기술의 3~4세대를 건너뛰어 최신 버전으로 직행하는 것도 가능하다. 건너뛰기는 수많은 두통과 야간작업을 없앨 수 있다.  

여기에는 요령이 필요하고 위험이 없지 않다. 그러나 몇 세대의 업데이트를 건너뛰는 것이 기술 부채라는 부담보다 훨씬 더 나은 경우가 많다.  

오픈소스도 고려해 보라 
소프트웨어 개발 프로젝트에는 커스텀 코드가 지나치게 많은 경우가 빈번하다. 무언가를 달성하려고 시도할 때 누군가 다른 사람도 똑같은 고민을 하고 있을 확률이 상당히 높다. 때때로 그러한 다른 사람이나 조직이 오픈소스 프로젝트를 시작했다면 그곳에 참여하는 것도 나쁘지 않다. 

오픈소스는 만병통치약이 아니다. 공짜 점심 같은 것은 없다. 모든 사람에게 유익한 코드로 수렴하려면 양보도 해야 하고 협력도 해야 한다. 일이 잘 풀린다면 오픈소스 프로젝트에 약간의 시간만 투자하면 될 것이고, 모두가 만족할 것이다. 

기본 툴을 활용하라 
프로젝트는 기성 툴을 이용해 달성할 수 있는 경우가 많다. 드루팔(Drupal), 구글 폼즈(Google Forms), 서베이 몽키(Survey Monkey) 등이 제공하는 표준 웹 양식으로 할 수 있는 일은 경이로울 정도다. 이들 툴은 데이터를 스프레드시트에 투하해 분석한다. 이는 깔끔하지 않다. 이는 프로그래머의 세계에서 ‘코딩’이라고 불리지도 않을 것이다. 그러나 신뢰성 있고 재사용이 가능한 방식으로 답을 도출한다면 이는 대형 개발 프로젝트를 달성하는 가장 빠른 방법일 것이다. 

현실을 직시하라 
우리는 모두 인기 절정의 웹사이트 구축을 꿈꾼다. 따라서 극한의 부하를 처리할 계획을 세운다. 필자는 세심한 아키텍트들이 로드밸런서와 복제 데이터베이스를 갖춘 자신의 3계층 시스템을 설명하는 것을 본 적이 있다. 이는 하루에 100명에게 서비스하는 한 프로젝트를 지원했다. 무난한 확장이 어렵지 않다면 이는 문제가 없다. 그러나 이들 계층을 추가하는 일은 프로젝트를 복잡하게 만들고, 구축 시간을 늘리며, 유지 보수를 어렵게 한다. 새 프로그래머를 영입하는 것은 그만큼 더 어려워지고, 심지어 사소한 문제를 교정하는 데에도 기나긴 팀 회의가 필요할 수 있다. 구글 앱 엔진 같은 최신 서버리스 툴이 확장을 단순하게 해주는 것은 사실이지만 복잡성과 비용에서 희생이 필요하다. 

우수한 엔지니어는 황당한 문제가 나타날 수 있음을 알고 있다. 그러나 비용 측면에서 이의 확률에 대해 현실을 직시해야 하고, 이러한 문제가 나타날 때 성능 저하나 심지어 고장을 감수할 수 있어야 한다. 

* Peter Wayner는 오픈소스 소프트웨어, 자율주행 차량, 개인정보 보호 강화, 디지털 트랜잭션, 스테가노그래피(steganography) 등 다양한 주제에 관한 16권 이상의 책을 저술한 저자다. ciokr@idg.co.kr