2020.06.22

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

Peter Wayner | CIO


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

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

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

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

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

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

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

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

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

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

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

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




2020.06.22

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

Peter Wayner | CIO


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

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

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

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

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

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

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

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

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

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

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

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


X