소프트웨어 설계를 구성하는 방법에는 두 가지가 있습니다. 한 가지 방법은 결함이 전혀 없을 정도로 단순하게 만드는 것이고, 다른 한 가지 방법은 결함이 전혀 없을 정도로 복잡하게 만드는 것입니다.
- C.A.R. Hoare, The 1980 ACM Turing Award Lecture
저는 개발 접근 방식에 대한 저의 신조로 인해 종종 비판을 받곤 합니다. 당신의 코드는 우아할지 몰라도 제 코드는 X나게 작동합니다. 이에 대답으로 “모범 사례를 이해하지 못한다.” 부터 “테스트를 싫어한다!”에 이르기까지 다양한 말을 듣습니다. 정기적으로 같은 말을 반복하지 않기 위해 이 주제에 대한 제 관점을 적어보기로 했습니다. 이 관점을 고수할지 말지는 여러분의 선택입니다.
먼저, “프로젝트는 늦어질 수 있지만 코드는 [더 보기 좋고/유지 관리가 더 쉬우며/더 깔끔하다]” (해당되는 것을 골라보세요) 라는 분장은 본질적으로 결함이 있습니다. 프로젝트가 늦어지면 완료된 것이 아닙니다. 끝입니다. 코드 품질/완성도 등을 핑계로 늦는 것을 정당화할 수 있는 방법은 없습니다. 고객에게 크리스마스 프로모션이 필요한데 12월 29일에 프로모션 역사상 최고의 제품을 제공한다면 그것은 아무 소용이 없습니다.
이제 유지 관리가 더 쉬운 코드를 만들려면 더 많은 시간이 필요하다는 의미의 “모범 사례” 논거에 대해 살펴봅시다. “모범 사례”라는 문구를 계속 따옴표로 묶어 사용하는 이유는 모든 프로그래머가 첫 번째 “Hello World”를 작성하기 전에 머릿속에 각인해야 하는 매우 일반적인 모범 사례 101을 제외하고는 표준이 전반적으로 다양하기 때문입니다.(몇 가지 일반적인 오해에도 불구하고) 즉, “모범 사례”는 어떻게 정의하든 괜찮은 개발자라면 누구나 자연스럽게 코딩 표준으로 삼아야 합니다. 프로젝트 타임라인에 여러분의 코드를 준수하게 만들기 위해 더 많은 시간이 필요하다면 기껏해야 프로그래밍을 처음 접하는 사람일 뿐입니다. 사소한 예를 들자면, 숙련된 프로그래머라면 본능적으로 $a, $b, $c 등의 변수를 호출하지 않아야 하고 코드 줄을 적절하게 들여쓰기해야 한다는 것을 알고 있을 것입니다. 물론 더 발전된 “모범 사례” 표준도 있지만, 요점은 “모범 사례”가 개발 일정을 초과하는 좋은 핑계가 될 수 없다는 것입니다. 한 걸음 더 나아가, 베테랑 프로그래머는 마감일을 맞추기 위해 필요한 경우 언제, 그리고 가장 중요한 것은 어떻게 시간을 단축해야 하는지를 알아야 합니다. 이것이 다음 주제로 이어집니다: 오버 엔지니어링입니다.
다른 숙련된 엔지니어와 마찬가지로 저도 모든 프로젝트에 가장 유연하고 강력한 최고의 시스템을 구축하고자 하는 열망을 잘 알고 있습니다. 물론이죠. 하지만 모든 프로젝트의 공통적인 비즈니스 제약 조건인 시간과 비용에 대해서도 잘 알고 있습니다. 대부분의 프로젝트에는 기한이 정해져 있고/또는 특정 예산이 정해져 있으며, 종종 그 안에서 거창한 것을 구축하는 것은 불가능합니다. 이때 개발자는 목표를 달성하기 위해 창의성을 제한하는 의식적인 결정을 내려야 합니다. 게시자 세 명만 관리 패널에서 사용하는 20행 테이블에 데이터베이스 쿼리를 위한 ‘적절한’ 캐싱 계층을 설정하는 데 일주일을 소비하는 것은 변명의 여지가 없습니다. 사용 사례를 이해하세요. 다양한 동시 요청을 지원하기 위해 유연하고 확장 가능한 XHR 프레임워크를 구축하는 것은 멋지지만, 한 페이지의 방문자 카운터 업데이트만 사용하는 기능이라면 굳이 투자할 필요가 없습니다. 범위를 이해하세요. 아무리 강조해도 지나치지 않습니다. 훌륭한 엔지니어는 최첨단 시스템을 구축하는 방법을 아는 사람이 아니라 시스템을 구축하지 말아야 할 때를 아는 사람입니다.
소프트웨어 개발의 세계에서 시장 출시 기간은 비즈니스의 원동력입니다. 인터넷 애플리케이션 개발의 세계에서는 웹의 역동성 때문에 그 중요성이 더욱 분명해집니다. 시간이 가장 중요한 상황에서는 가장 간단한 솔루션은 종종 최선의 해결책이 아닙니다. 항상 최선의 해결책입니다. 그리고 이로 인해 우리는 논쟁의 마지막 주제로 이어집니다. 기술부채
개발 과정에서 비용을 절감하면 장기적으로 확실한 기술 부채가 쌓이게 될 것이라는 주장을 자주 듣습니다. 그리고 그 부채의 비용은 프로세스에서 어떠한 결정을 내릴 때 크게 고려되어야 한다고 합니다. 실제로 이 주장은 제 관점을 뒷바침합니다. 마감에 쫓기는 프로젝트를 진행할 때 언제 어떻게 비용을 절감해야 하는지 평가할 수 있는 능력이 중요한 이유가 바로 여기에 있습니다. “기술 부채”에는 다양한 유형이 있으며, 조금만 생각하면 가장 빠른 해결책이 반드시 기술 부채를 늘리지 않을 것입니다. 마찬가지로 오버엔지니어링을 한다고 해서 부채가 없어지는 것은 아닙니다. 프로젝트 중간에 이러한 결정을 내릴 수 있는 능력은 베테랑과 신인을 구분하는 요소입니다.
또한 기술 부채의 위험성에 대해 이야기하는 사람들은 비즈니스에 미치는 영향을 고려하지 않는 경우가 많습니다. 많은 경우 조기 출시가 더 비용 효율적이기 때문에 기술 부채는 실제 ROI와 비교하여 가중치를 두어야 합니다. 이렇게 하면 기술 부채가 발생하더라도 즉시 수익이 발생하고 시간이 지남에 따라 부채를 조정할 수 있습니다. 이는 시장 출시 시기를 늦춰 기술 부채는 없지만 시간이 지남에 따라 기술 부채 자체의 비용보다 훨씬 더 큰 시장 기회 및/또는 즉각적인 수익 기회를 잃는 것보다 더 나은 방법일 수 있습니다.
소프트웨어 개발자로서 우리는 종종 우리의 임무가 소프트웨어를 개발하는 것이라고 생각하지만, 실제로는 소프트웨어를 개발하는 것이 목적의 수단일 뿐이며, 최종 목적은 비즈니스가 목표를 달성할 수 있도록 지원하는 것입니다. 코드가 아무리 훌륭해도 목표(시간 또는 비즈니스)를 달성하지 못하면 아무 소용이 없습니다.