이제 어떻게 해야 할까? 설계 변경을 위한 계획 수립

저는 종종 사람들과 시스템 설계, 계획, 아키텍처에 대해 논의하게 됩니다. 그리고 그런 논의가 이미 설계가 구현되었거나 부분적으로 구현된 이후 너무 늦게 이루어지는 경우가 많습니다. 진행 중인 설계가 해당 상황에 이상적이지 않다고 판단될 경우 이는 매우 좌절스러울 수 있습니다.

이러한 상황에서 생기는 좌절감은 충분히 이해할 수 있지만, IT 분야에 있는 우리는 이를 매우 빈번하게 마주치게 되며 이러한 반응을 건설적으로 관리하는 것이 핵심적인 IT 역량입니다. 우리는 기술적으로나 감정적으로나 이 상황의 달인이 되어야 합니다. 이에 의해 무너져서는 안 됩니다. 이는 모든 IT 전문가가 정기적으로 경험하는 자연스러운 상황입니다. 낙담하거나 무너질 일이 아니지만, 그렇게 느껴질 수 있다는 것은 충분히 이해할 수 있습니다.

우리가 이를 자주 경험하는 주요 이유 중 하나는 IT가 모든 상황에서 고려해야 할 수많은 변수가 있는 방대한 분야이기 때문입니다. 또한 어떤 주어진 문제에 대해 수많은 실행 가능한 접근 방식이 존재할 수 있는 매우 창의적인 분야이기도 합니다. 단 하나의 "최선" 옵션이 있는 경우는 거의 없습니다. 보통은 여러 경쟁 옵션들이 존재합니다. 때로는 이러한 옵션들이 매우 밀접하게 관련되어 있고, 때로는 의미 있는 비교를 하기 매우 어려울 정도로 극적으로 다르기도 합니다.

또 다른 주요 이유는 요인들이 변한다는 것입니다. 새로운 기술이나 정보가 밝혀지거나, 새로운 제품이 출시되거나, 제품이 업데이트되거나, 가격이 변하거나, 혹은 의사결정 및 설계 과정 중이나 그 근처에서 비즈니스 요구사항이 변경될 수 있습니다. 이러한 변화의 속도는 IT 전문가로서 우리가 통제하기를 바랄 수 없는 것입니다. 이는 우리가 최선을 다해 받아들이고 대처해야 하는 것입니다.

또한 내가 종종 간과되는 것을 발견하는 것은, 결정이 이루어졌을 때 이상적이었던 솔루션이 오늘날 동일한 결정을 내린다면 이상적이지 않을 수 있다는 점입니다. 이것은 원래 설계의 결함을 전혀 나타내지 않지만, 많은 사람들이 그렇게 반응하는 것을 보았습니다. 제가 사람들이 이런 행동을 보이는 가장 흔한 시나리오는 현대 스토리지 설계에서 RAID 5 사용에 대한 거부감입니다. RAID 6와 RAID 10이 충분한 이유로 인기 있는 대안입니다. 하지만 약 2009년부터 일반화된 이 RAID 5 거부감은 항상 존재했던 것이 아니며, 1990년대 중반부터 2000년대 말까지 RAID 5는 실행 가능할 뿐만 아니라 주어진 비즈니스 및 기술적 요구에 대해 매우 일반적으로 최선의 솔루션이었습니다(이에 대한 거부감 증가는 대부분 갑작스러운 것이 아니라 점진적이었습니다). 그러나 많은 사람들이 오늘날 RAID 5를 옵션으로 당연히 좋지 않다고 보면서, 거의 20년 전에 설계되고 구현된 시스템에 이 새로운 거부감을 적용합니다. 이는 말이 되지 않으며 순전히 감정적인 반응입니다. 2002년의 시나리오에서 RAID 5가 최선의 선택이었다는 것이 2015년에도 여전히 최선의 선택일 것이라는 의미는 아닙니다. 그러나 마찬가지로, 2015년의 시나리오에서 RAID 5가 좋지 않은 선택이라는 것이 몇 년 전에는 훌륭한 선택이었다는 사실을 폄하하거나 부정하지 않습니다.

저는 이상적이지 못한 설계 결정이 이루어진 후 무엇을 해야 하는지에 대한 질문을 여러 번 받았습니다. "이제 어떻게 해야 할까?"

완벽함이 더 이상 선택지가 아닐 때(마치 항상 그랬던 것처럼, 모든 IT는 타협에 관한 것입니다) 무엇을 해야 하는지 배우는 것은 매우 중요한 기술입니다. 우리가 먼저 해결해야 할 것들은 감정적인 문제들로, 이것들이 다른 모든 것을 훼손할 것이기 때문입니다. 우리는 최선을 다해 한 발짝 물러서고, 상황을 받아들이고, 합리적으로 행동해야 합니다. 우리가 원하지 않는 것은 이상적이지 않은 상황을 악화시키는 것입니다. 나쁜 결정을 역으로 정당화하거나 패닉 상태에 빠지려고 시도하는 방식으로 말입니다.

어떤 설계도 완벽하지 않으며, 항상 모든 것을 완전히 올바르게 할 방법은 없고, 이를 다루는 것이 IT 업무의 일부일 뿐이라는 것을 받아들이는 것이 첫 번째 단계입니다. 한 발짝 물러서서 깊게 숨을 쉬세요. 그렇게 나쁜 것이 아닙니다. 이것은 특별한 상황이 아닙니다. 설계를 담당하는 모든 IT 전문가가 항상 이런 일을 겪습니다. 최선의 결정을 내리려고 최선을 다해야 하지만, 그것이 거의 불가능하다는 것도 받아들여야 합니다. 실제로 그렇게 할 수 있을 만큼 충분한 자원에 접근할 수 있는 사람은 아무도 없습니다. 우리는 가진 것으로 일합니다. 그래서 우리는 지금 여기 있습니다. 다음은 무엇인가요?

다음은 상황을 평가하는 것입니다. 지금 우리는 어디에 있나요? 많은 경우 구현이 완료되어 더 이상 할 일이 없습니다. 상황이 이상적이지 않지만, 그것이 나쁜가요? 이미 구현된 설계에 직면한 사람들이 저지르는 가장 큰 실수는 너무 비용이 많이 든다는 것입니다. 일반적으로 "더 나은" 솔루션은 더 빠르거나 더 신뢰할 수 있기 때문이 아니라 더 저렴하거나, 더 쉽거나, 더 빨리 구현할 수 있기 때문에 더 나은 것입니다. 그것은 불행한 상황이지만 결코 치명적인 것은 아닙니다. 소비된 시간이나 돈은 그 당시 허용 가능한 금액이었을 것이고 승인되었을 것입니다. 지금 우리가 할 수 있는 최선은 결정 프로세스에서 배우고 미래에 과잉 지출을 피하려고 노력하는 것입니다. 기존 솔루션이 작동하지 않거나 심지어 놀랍게 잘 작동하지 않을 것이라는 의미가 아닙니다. 단순히 주로 재정적인 비즈니스 요구사항을 고려할 때 완벽한 선택이 아니었을 수 있다는 것뿐입니다.

구현된 설계가 명시된 비즈니스 요구사항을 적절히 충족하지 못하는 상황이 있습니다. 다행히도 제 경험상 이런 경우는 훨씬 더 어려운 상황이기 때문에 덜 일반적입니다. 이 경우 비즈니스 요구사항을 충족하기 위해 일부 수정이 필요합니다. 이것은 비용이 많이 들거나 복잡할 수 있습니다. 하지만 상황이 보이는 것만큼 나쁘지 않을 수 있습니다. 이에 대한 반응은 종종 오해를 불러일으키며 상황은 종종 수습될 수 있습니다.

비즈니스 요구사항을 충족하지 못하는 솔루션을 구현한 상황에서 첫 번째 단계는 비즈니스 요구사항을 재평가하는 것입니다. 이것이 요구사항을 우리 시스템이 충족할 수 있는 것으로 만들기 위해 조작해야 한다는 것을 의미하지 않습니다. 전혀 그렇지 않습니다. 하지만 원래 명시된 요구사항이 진정으로 유효한지, 아니면 단순히 충분히 검토되지 않았는지, 또는 더 가능성 있게는 구현 기간 동안 비즈니스 요구사항이 변경되었는지 확인하러 돌아가 보기에 좋은 시간입니다. 구현된 솔루션이 원래 잘못 명시되었거나 요구사항이 시간이 지남에 따라 변경되었기 때문에 실제 비즈니스 요구사항을 충족할 수도 있습니다. 또는 비즈니스 요구사항이 너무 극적으로 변경되어 완벽한 계획조차도 원래 기존 요구사항에 미치지 못했을 수 있으며, 구현된 솔루션이 예상대로 수행되지 않는다는 사실이 사소한 결과일 수도 있습니다. 저는 비즈니스 요구사항에 대한 이러한 검증이 부적절하다고 여겨지는 솔루션을 실제로 필요한 것보다 더 많은 비용이 든 "과잉 설계" 솔루션으로 바꾸는 경우가 얼마나 자주 있는지에 매우 놀라곤 합니다. 단순히 아무도 비즈니스 요구사항의 과장에 이의를 제기하지 않았거나 특정 기술 투자에 대한 재정적 가치에 의문을 품지 않았기 때문입니다.

두 번째 단계는 새로운 기술 베이스라인을 생성하는 것입니다. 이것은 IT가 매몰 비용 오류의 함정에 빠지는 것을 방지하는 데 도움이 되는 매우 중요한 단계입니다. 어느 분야에서나 공통적으로 (IT에만 특별한 것이 아니라), 프로젝트에 소비된 시간과 돈을 보고 이미 그 경로에 얼마나 많은 자원을 소비했는지에 관계없이 아무리 어리석어도 원래의 경로를 계속 따르는 것이 맞는 방법이라고 가정하는 것은 매우 일반적입니다. 하지만 물론 이것은 말이 되지 않습니다. 어떻게 현재 상태에 이르렀는지는 관련이 없습니다. 관련 있는 것은 부서와 회사의 현재 요구사항을 평가하고 현재 사용 가능한 솔루션, 기술 및 자원을 파악하는 것입니다. 현재 상태가 주어지면 최선의 방향을 결정할 수 있습니다. 현재 상태에 이르기 위해 소비된 노력에 대한 어떤 고려도 오해만 불러일으킬 뿐입니다.

매몰 비용 오류의 좋은 예는 체스 게임입니다. 각 수를 두기 전에 현재 상태로 이어진 수들은 앞으로 어떤 수가 의미 있는지에 아무런 영향을 미치지 않기 때문에, 가능한 모든 수, 위험 및 전략을 다시 평가하는 것이 중요합니다. 세계 최고의 체스 선수나 놀라운 컴퓨터 체스 알고리즘이 게임 중간에 투입된다면 현재 상태가 어떻게 이루어졌는지에 대한 어떤 지식도 필요로 하지 않을 것입니다. 단순히 현재 상태를 평가하고 그에 기반한 전략을 세울 것입니다.

IT에서도 우리가 이렇게 행동해야 합니다. 우리의 현재 상태는 현재 상태입니다. 우리가 그 상태에 이르게 된 것이 전략적 계획에 있어 중요하지 않습니다. 우리는 의사결정이 어디서 실패했는지를 파악하여 그것으로부터 배우기 위한 사후 분석 과정을 할 때만 그 결정과 비용에 관심을 가집니다. 우리 자신과 우리 프로세스에 대해 배우는 것은 매우 중요합니다. 하지만 그것은 현재 이니셔티브를 위한 전략적 계획을 수립하는 것과는 매우 다른 작업입니다.

안타까운 점은 이번에는 더 많은 것을 가지고 작업한다고 가정하지만 계획 프로세스를 다시 시작해야 한다는 것입니다. 하지만 이것은 피할 수 없습니다. 최악의 경우, 예산이 더 이상 없고 결함 있는 설계를 수정하고 필요한 비즈니스 목표를 달성할 자원이 없습니다. 때로는 타협이 필요합니다. 가진 것으로 해결하는 것이 때로는 우리가 할 수 있는 최선입니다. 하지만 대부분의 경우, 추가 예산과 기존 제품의 창의적인 재활용의 조합으로 상황을 해결하기에 충분할 것입니다.

단순히 과잉 지출했음을 인정하거나, 미달이었거나, 필요를 충족하기 위해 조정했음으로써 단점을 해결한 상태에 도달하면, 우리는 의사결정 프로세스를 조사할 기회를 갖게 됩니다. 이를 통해 우리는 개인으로서, 그리고 가능하다면 조직 차원에서 실수로부터 배우거나 실수가 있었는지를 판단함으로써 성장할 수 있기를 바랍니다. 모든 회사와 모든 개인은 실수를 합니다. 우리를 구분하는 것은 그것으로부터 배우고 미래에 같은 실수를 피하는 능력입니다. 성장은 주로 이런 방식으로 고통을 경험하는 것에서 오며, 종종 마주하기 불쾌하지만 여기서 진정하고 지속적인 가치를 창출할 수 있는 최고의 기회가 있습니다. 직접 하는 가혹하고 개인적인 검토이든, 훈련된 사람들이 운영하는 공식적인 조직적 검토이든, 또는 그 중간 어딘가이든 이 검토의 기회를 미루거나 건너뛰지 마세요. 의사결정 프로세스를 더 일찍 평가할수록 기억이 더 신선하고 방향 수정이 더 빨리 효과를 낼 수 있습니다.

우리가 할 수 있는 마지막 단계는 의사결정 프로세스 검토가 완료되는 즉시, 가능한 한 빨리 현재 구현에 대한 대체를 설계하기 위한 의사결정 프로세스를 시작하는 것입니다. 이것이 반드시 가까운 미래에 돈을 쓰거나 설계를 변경하려는 의도가 있어야 한다는 의미는 아닙니다. 전혀 그렇지 않습니다. 하지만 의사결정에 매우 적극적으로 임함으로써 계획에 더 많은 시간, 요구사항 수집 및 문서화에 더 많은 시간, 시간이 지남에 따라 요구사항이 안정적으로 유지되는지 아니면 변경되는지를 정기적으로 재방문하여 요구사항 변화에 대한 더 나은 통찰, 경영진 및 동료의 지지와 결정에 대한 투자를 얻을 더 많은 기회, 그리고 다음 번에 구현하기 전에 의도된 설계를 변경하거나 처음부터 시작해야 할 시기를 알 수 있는 더 나은 능력을 제공할 수 있습니다. 또한 잠재적으로 다음 사이클이 돌아올 때 당신이 의사결정이나 구현 위치에 없더라도 후임자에게 전달될 수 있는 조직적 지식을 성문화할 더 나은 기회를 줄 수 있습니다.

좋은 합리적인 프로세스와 이상적이지 않은 시스템 설계 또는 구현 사례에서 취해야 할 단계에 대한 좋은 이해로, 우리는 실수로부터 회복하고 대부분의 경우 단기적으로 회복할 수 있을 뿐만 아니라 미래에 동일한 실수로부터 조직을 보호할 수 있습니다.