SW 프로젝트 속도를 높이는 방법

 

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

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

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

개발자의 과욕을 억제하라
개발자 역시 현실을 직시해야 한다. 프로젝트 목록에 있는 모든 항목이 개발자에게는 똑똑하고 참신하고 믿기 어려울 정도로 시간을 소비하는 일부 전문 용어를 마침내 실현할 기회로 보인다.

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

현실을 직시하라
우리는 모두 인기 절정의 웹사이트 구축을 꿈꾼다. 따라서 극한의 부하를 처리할 계획을 세운다. 우수한 엔지니어는 황당한 문제가 나타날 수 있음을 알고 있다. 그러나 비용 측면에서 이의 확률에 대해 현실을 직시해야 하고, 이러한 문제가 나타날 때 성능 저하나 심지어 고장을 감수할 수 있어야 한다.

 

 

출처

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