잘못된 방법론 선택부터 최신 트렌드에 지나치게 집착하는 것까지, 훌륭한 앱 개발팀의 결과물도 때때로 우리 스스로가 되돌릴 수 없는 경향, 유혹, 습관으로 인해 어려움을 겪을 수 있다.
소프트웨어 개발은 수백만 개의 매개변수, 변수, 라이브러리 등을 기반으로 하는 까다로운 분야다. 모든 것이 정확히 맞아야 한다. 한 글자라도 잘못되면 스택 전체가 무너질 수 있다. 그리고 이것은 기술적인 부분일 뿐이다. 의견이 다른 프로그래머, 까다로운 이해관계자, 회의를 좋아하는 관리자가 어우러져 소프트웨어 개발 작업의 참사를 만들어낼 수 있다.
하지만 소프트웨어만으로 가능했던 수많은 혁신도 있다. 그리고 그 대부분은 코더와 코더를 관리하는 사람들의 노력에 달려 있다. 수십 년에 걸쳐 소프트웨어 전문가들은 작업을 완료하기 위한 몇 가지 규칙을 알아냈다. 정교한 방법론부터 새로운 분야와 철학에 이르기까지 소프트웨어 개발의 규칙은 모두가 협업하여 제대로 작동하는 결과물을 완성할 수 있도록 도와준다.
안타깝게도 모든 혁신에도 불구하고 소프트웨어 개발자와 관리자의 각종 실수가 여전히 존재한다. 때때로 방법론이 잘못 적용되기도 한다. 또는 좋은 아이디어를 너무 멀리 가져가기도 한다. 때때로 개발자는 자신이 해야 할 일을 잊어버리기도 하고, 때로는 의도적으로 잊어버리기도 한다.
이러한 소프트웨어 개발의 죄악은 거의 모든 프로젝트를 망칠 수 있다. 팀이 훌륭한 결과물을 만들 수 있는 유일한 방법은 이러한 실수와 유혹에 빠졌을 때 불량한 코드 생산을 잠시 멈추고 신중하게 검토하는 것 뿐이다.
잘못된 방법론 선택
모든 소프트웨어 개발 방법론에는 자신이 좋아하는 규칙에 열정적으로 헌신하는 팬들이 있다. 문제는 종종 팀에 적합한 것을 선택하는 데 있다.
한 가지 큰 실수는 이러한 규칙을 위에서부터 강요하는 것이다. 다른 접근 방식을 신봉하는 코더는 다른 접근 방식의 사용을 강요 받을 때 불평하고 냉소적이 된다. 안타깝게도 또 다른 실수는 팀 전체에 무엇이 최선인지 모르기 때문에 후방에 있는 프로그래머가 자신이 좋아하는 것을 선택하도록 내버려두는 것이다.
올바른 방법론을 선택한다고 해서 모든 문제가 해결되는 것은 아니다. 하지만 워크플로우를 구성할 때 발생하는 마찰을 줄이게 될 것이다. 팀은 자신의 역할을 알고 그 안에서 코딩하는 방법을 이해하게 될 것이다.
확장성 무시
일부 소프트웨어 개발 문제는 나중에 수정할 수 있다. 하지만 수백만 또는 수십억 개의 이벤트를 처리할 수 있도록 확장되어야 하는 애플리케이션을 구축하는 것은 그렇지 않다. 앱이 최대 규모로 실행되었을 때 병목 현상 없이 효과적인 코드를 생성하려면 충분한 사전 작업과 높은 수준의 리더십이 필요하다. 이는 약간의 타깃 코딩과 가상의 덕트 테이프로 나중에 고칠 수 있는 문제가 아니다.
특히 알고리즘과 데이터 구조는 처음부터 계획해야 한다. 즉, 설계자와 관리자는 각 사용자에 대해 저장되고 처리될 데이터에 대해 신중하게 생각해야 한다. 사용자가 100만 명 또는 10억 명에 달할 때 정보의 홍수가 어느 계층을 압도할까? 이러한 순간을 대비해 어떻게 미리 계획할 수 있을까?
때로는 이러한 아키텍처적 고려가 훌륭한 아이디어를 죽이는 것을 의미하기도 한다. 또 관리진은 기능을 대규모로 제공하는 데 드는 비용과 이점을 비교해야 한다. 데이터 분석이 대규모에서는 잘 작동하지 않고, 어떤 자원은 사용자가 늘어날수록 기하급수적으로 증가한다. 통신이 막히는 경우도 있다.
개발자가 항상 큰 그림을 염두에 두는 것은 아니다. 그냥 뛰어들어 만들어내는 것이 너무 쉽기 때문이다. 하지만 현명한 개발팀과 관리자는 이러한 문제를 예측하는 데 시간을 할애한다. 예측하지 못하면 나중에 실패할 수 있기 때문이다.
최신 트렌드에 함몰
소프트웨어 개발자는 새롭고 화려한 아이디어에 끌리는 것으로 악명이 높다. 더 복잡한 쿼리를 제공하는 새로운 종류의 데이터베이스일 수도 있다. 기존 프로그래밍 언어의 모든 버그를 수정할 수 있는 새로운 프로그래밍 언어일 수도 있다.
물론 이러한 아이디어에 장점이 있을 수 있다. 하지만 많은 경우, 모두가 새로운 기술을 배우려고 애쓰다 보니 결국 개발 속도가 느려진다. 때로는 새로운 아이디어에 숨겨진 결함이 있다. 이러한 결함이 프로젝트 납품 직전에 모든 사람이 진흙탕에 빠진 후에야 드러나서는 안될 것이다.
새로운 기술을 채택할 때는 신중함이 최고의 원칙이다. 크고 오래된 회사 몇몇이 아직도 코볼로 작성된 소프트웨어를 계속 실행하는 데에는 이유가 있다. 트렌드는 왔다가 사라지지만 실행 코드의 작동 논리는 닳아 없어지지 않는다.
너무 많은 데이터 보유
프로그래머들은 천성적으로 정보를 저장해 둔다. 나중에 필요할 때를 대비해 정보를 저장하기를 좋아한다. 하지만 ‘언제 필요할지 모르기 때문에’ 정보를 계속 보관하는 것은 보안 유출이나 사용자 개인정보 침해의 원인이 될 수 있다.
생년월일이나 기타 세부 정보와 같은 개인 정보의 경우 문제가 더 커질 수 있다. 재무 기록이나 건강 기록과 같은 일부 영역은 규제가 엄격하여 규정을 위반하기 쉽다.
좋은 소프트웨어 아키텍처는 저장되는 데이터의 양을 최소화하기 위해 미리 계획하는 것을 포함한다. 이는 모든 사용자를 보호하고 스토리지 요금을 절약하는 동시에 이동 중인 데이터의 양을 줄여 시스템 속도를 높일 수 있다.
잘못된 업무 아웃소싱
비교적 명확한 답이 있는 상황에서도 소프트웨어 개발자들은 종종 잘못된 선택을 하곤 한다. 좋은 가격에 완벽하게 좋은 솔루션이 있는데도 자존심이 너무 강해서 값비싼 사내 팀과 함께 커스텀 스택을 따로 마련하는 것이다. 그 반대도 마찬가지이다. 일부 관리자는 외부 공급업체의 제품군을 구매했다가 종속이 완료된 후 공급업체가 가격을 대폭 인상하는 것을 지켜만 볼 뿐이다.
안타깝게도 이 문제는 개발자와 관리진이 계속 다뤄야 할 과제다. 올바른 외부 소스를 고용하는 것은 바람직한 일이지만, 잘못된 공급업체를 채택하는 것은 값비싼 감옥으로 가는 티켓과도 같다.
테스트 회피
유능한 소프트웨어 개발자와 관리자는 테스트가 우아한 데이터 구조를 설계하는 것만큼이나 끊임없는 도전이며 업무의 일부라는 것을 알고 있다. 단위 테스트와 통합 테스트는 개발 프로세스 전반에 걸쳐 코드의 실행 가능성을 보장하는 데 필수적이므로 처음부터 테스트를 포함해야 한다.
특히 대규모 부하를 처리하는 데에 중요하다. 혼자만 사용할 때 책상 위에서 원활하게 실행되는 코드를 작성하는 것은 너무 쉽다. 해당 애플리케이션이 수백, 수천, 수십만 명의 사용자를 보유하게 될 경우 코드가 효율적이고 배포가 대규모를 처리할 수 있는지 확인해야 한다.
많은 팀에서 프로그래머의 실수를 관찰하는 품질 보증 테스터를 고용한다. 예를 들어 0으로 나누기 오류가 발생하는지 확인하기 위해 매개변수를 0으로 설정하는 방법을 알고 있다. 코드가 깨지는지 확인하기 위해 3.14159개의 셔츠나 -4,000개의 양말을 구매하는 방법도 알고 있다. 테스트에 대한 이러한 주의는 한 사람이 모든 변수를 생각하고 모든 변수를 예상하는 깔끔한 코드를 작성하기 어려울 때 필수적이다.
기획의 힘을 과소평가
대부분의 코드는 기획에 어느 정도 공을 들여야 한다. 하지만 안타깝게도 대부분의 코더는 바로 코딩에 뛰어들어 기계적으로 코드를 작성하는 경우가 많다.
계획을 세우고, 계획을 테스트하고, 추가적인 계획을 세우는 것이 가장 좋은 단계라는 것을 깨닫기까지는 몇 년의 시행착오가 필요할 수 있다. 계획을 세우는 것은 지루해 보일 수 있지만 추상적으로 생각할 때 아이디어를 시험해 보는 것이 10배 더 빠를 수 있다. 이러한 교훈을 얻을 때 성공적인 관리자가 될 수 있기도 하다.
기획은 다른 팀과 이해관계자의 의견을 포함한다는 의미이기도 하다. 이들은 앞으로 코드를 사용하게 될 사람들이므로 프로젝트에 대해 논의하고 그들의 요구사항을 파악하는 데 시간을 투자하면 나중에 많은 좌절감을 줄일 수 있다. 이것이 여기에서 나열한 많은 죄를 피할 수 있는 최선의 방법이다.
* Peter Wayner는 오픈소스 소프트웨어, 자율주행 차량, 개인정보 보호 강화, 디지털 트랜잭션, 스테가노그래피(steganography) 등 다양한 주제에 관한 16권 이상의 책을 저술한 저자다. dl-ciokorea@foundryco.com
