엔지니어는 어떻게 비즈니스 구축의 한 플레이어가 되어야 하는가
프로젝트 관리에서 자주 언급되는 개념 중 하나가 바로 '삼각 제약(Triangle of Constraints)'이다. 일정(Schedule), 자원(Resources), 그리고 범위(Scope)라는 세 가지 요소가 서로 밀접하게 연결되어 있으며, 세 요소를 모두 최적화 할 수는 없고, 셋 중 두 가지 요소만 최적화 할 수 있다는 개념이다. 흔히 '철의 삼각형(Iron Triangle)'이라고도 불릴만큼 이 세 가지 요소는 서로에게 강한 영향을 미친다.
하지만 흥미로운 점은, 오늘날 여러 조직들이 이 제약을 다루는 방식이 내가 처음 개발자의 길을 걷기 시작한 시절과 크게 다르지 않다는 것이다. (아마 본질적으로 해결되기 어려운 속성이라 철의 삼각형이라는 이름이 붙은 측면도 있으리라). 한정된 자원과 시간 안에 최대의 결과를 얻기 위해 인간은 본능적으로 모든 것을 극대화하려는 성향이 있고, 그로 인해 오히려 상황을 더 어렵게 만드는 결정을 하곤 한다. 심지어 이따금 불안을 회피하기 위한 수단으로서 이렇게 모든 것을 다 얻겠다는 결정을 선택하기도 한다. 그러나 이 경우, 원하는 것 중 어느 것도 얻지 못하는 결과가 발생할 가능성이 훨씬 높다.
대부분의 경우, 범위를 조정하는 것이 가장 현명한 방법으로 여겨진다. 리소스는 유연성이 매우 나쁘다. 개발이 늦어지고 있다고 사람을 바로 투입할 수 있지 않고, 투입된 사람은 오히려 기존 인력의 도움이 필요해서 단기적으로는 생산성을 갉아먹기 때문에 기대한 결과(시간과 범위를 사수하는)를 얻기 매우 어려운 방법이다. 따라서 남는 건 시간과 범위인데, 둘 중에는 범위를 조정하는 편이 대체로 더 나은 선택이다.
많은 경우 개발은 우리가 얻을 것으로 예상되는 가치가 실제로 얻어지는지를 탐색 또는 확증하기 위한 수단이다. 따라서 얻고자 하는 것을 분명하게 정의할 수만 있다면 범위는 상당히 폭넓게 조정할 수 있다. 이러한 목적을 분명히 할 수 있다면 Quick & Dirty 로 빠르게 목표에 접근해보는 것은 거의 항상 좋은 접근법이다.
하지만 아무런 기술 전략 없이 Quick & Dirty 방식만을 고수하게 되면, 빠르게 기술적 부채가 누적될 위험이 크다. 초기에는 빠르고 간단한 방식으로 문제를 해결할 수 있을지 몰라도, 이러한 방식으로 축적된 거친 코드와 불안정한 구조는 시간이 지남에 따라 유지보수와 확장이 점점 어려워진다. 결국 이로 인해 생산성이 급격히 하락하고, 프로젝트의 전체적인 효율성도 크게 떨어지게 된다. 그렇다고 처음부터 거대한 시스템을 높은 품질로 구현해 나가는 것 역시 비즈니스가 성립할지조차 확실치 않은 상황에서 합리적인 접근이 되기는 어렵다.
그래서 기술 조직은 단기적인 이득과 장기적인 부채 상환 가능성을 고려하여 유연한 아키텍처를 설계할 필요가 있다. 가령 여기서 자주 인용되는 접근법 중 하나는 바로 "전역적으로 깨끗하게, 지역적으로 더럽게"라는 접근법이다. 더러운 코드를 지역적으로 고립시키고, 이 코드를 점차적으로 마이그레이션할 전략을 수립할 수 있으면 초기에 저렴한 비용으로 빠르게 여러 실험을 해볼 수 있다. 그러나 이 전략을 사용하려면 전역적으로 깨끗한 상태를 알고 있어야 하고, 지역적으로 더러운 상태를 조금씩 고도화 시켜 나갈 전략을 세울 수 있어야 한다.
경력이라는 것은 단순히 특정 기술을 깊이 있게 다루는 경험에 국한되지 않는다. 오히려 경력은 이러한 기술적 유연성을 제시하는 데서 빛을 발한다, 개발 조직의 고객은 궁극적으로는 제품을 사용하는 사용자이지만, 가깝게는 비개발조직 (통상적으로 비즈니스 조직이라 말하는)이다. 이 가까운 고객을 위해 지불 가능한 비용 범위 내에서 합리적인 대안을 찾아주되, 이것의 한계와 장기적인 대안까지 함께 제시하고 선택하도록 돕는 것이야 말로 기술조직이 전체 조직에 가장 합리적으로 공헌하는 방법일 것이다.
그러기 위해서는 비즈니스적 목표를 일방적으로 수용하기보다는, 그 목표의 기반에 깔린 가설을 이해하려는 노력과 그 가설을 검증하는 최적의 방법을 함께 찾아나가는 접근이 필요하다. 그래야만 가설의 각 시나리오에 따른 다양한 기술적 대안을 제시할 수 있다. 결국, 기술 조직 역시 비즈니스를 영위하기 위한 한 플레이어로서 적극적으로 참여해야 한다.