아키텍처는 비즈니스와 함께 성장한다

중국 최대 규모의 인터넷 기업들에서 일할 때, 회의에서 거창한 표현을 자주 들었다. “이 기술의 모범 사례”, “최적의 아키텍처”, “차세대 인프라 플랫폼” 같은 말이었다.

당시 클라우드 서비스가 인기를 얻고 있었지만, 내가 일하던 회사들은 여전히 인프라의 상당 부분을 직접 구축했다. 전담 인프라 부서를 두고 대규모 팀이 내부 시스템을 개발하고 유지보수했다.

대형 인터넷 기업마다 그 안에 작은 AWS가 하나씩 있다고 상상해 보자.

그 시스템 중 일부는 실제 문제를 해결했다. 반면 어떤 시스템은 만든 사람들이 회사를 떠난 뒤에도 훨씬 오래 남는 부담을 만들어 냈다.

직원들은 들어오고 나갔다. 사내 정치, 성과 평가, 승진 요건이 기술적 의사결정에 영향을 미쳤다. 프레임워크를 만들면 인정과 영향력을 얻을 수 있었지만, 몇 년 뒤 그것을 유지보수하는 일은 훨씬 덜 주목받았다.

한 회사에서 우리 부서의 리더 한 명이 나를 따로 불러, 내 아키텍처가 비즈니스를 지원하는 데 너무 치중한다고 말한 적이 있다. 그는 자신의 기술 플랫폼에서는 서로 다른 팀의 비즈니스 기능을 기반 인프라에 의도적으로 결합한다고 설명했다. 그러면 각 부분을 분리하기 어려워지고, 팀들이 그에게 더 의존하게 된다는 것이었다.

그는 의도적인 설계 선택을 설명하고 있었다. 그 의존 관계는 그의 입지를 강화했지만, 그로 인해 생기는 복잡성은 회사가 책임지게 했다.

그 대화는 내 기억에 오래 남았다. 업계 전체는 고사하고, 그 부서 안에서도 그것이 유일한 사례였을 것 같지는 않다.

누군가의 지위를 지키기 위해 만들어진 아키텍처는 비즈니스가 방향을 바꾸기 어렵게 만들 수 있다. 회사가 서비스를 분리하거나, 구성 요소를 교체하거나, 플랫폼 사용을 중단해야 할 때, 의도적으로 만들어 둔 의존 관계가 장애물이 된다.

이것이 내가 내부 프레임워크 구축에 쏟는 열정에 의문을 품는 이유 중 하나다.

성숙한 오픈 소스 대안이 이미 존재하고 널리 쓰이고 있는데도, 어떤 부서는 자체 프레임워크를 개발할 수 있다. 왜 우리 버전이 더 나을 것이라고 기대해야 할까? 더 중요한 것은, 시간이 흘러도 계속 더 나을 것이라고 왜 기대해야 하느냐는 점이다.

내부 버전이 처음 나왔을 때 우위에 있더라도, 그 우위를 유지하려면 지속적인 투자가 필요하다. 널리 채택된 오픈 소스 프로젝트는 수많은 기업과 실제 상황에서 검증된다. 활발한 커뮤니티는 버그를 찾고, 수정 사항을 기여하고, 문서를 개선하며, 새로운 요구사항에 소프트웨어를 맞춰 갈 수 있다.

한편, 처음 개발했던 내부 개발자들은 떠날 수 있다. 후임자들은 시스템을 배우고, 제대로 기록되지 않은 결정들을 이해해야 한다. 다른 팀들은 그 시스템에 대한 의존을 쌓아 간다. 결국 업그레이드하거나 교체하려면 상당한 작업과 위험을 감수해야 할 수 있다.

기술적 성과로 시작한 것이 기술 부채가 될 수 있다.

나는 불필요한 프레임워크가 만들어지고, 도입되고, 이후 충분히 유지보수되지 않는 사례를 너무 많이 봤다. “오픈 소스 솔루션은 우리 요구에 맞지 않는다”는 익숙한 설명이었다. 때로는 사실이었다. 때로는 설정 변경, 작은 확장, 또는 업스트림 프로젝트에 대한 기여로 해결할 수 있는 문제였다.

내부 대안을 만드는 데 본격적으로 나서기 전에, 세 가지 질문에 답할 수 있어야 한다. 어떤 제약이 비즈니스를 가로막고 있는가? 자체 솔루션은 어떤 실질적인 이점을 제공하는가? 원래 팀이 떠난 뒤에도 회사가 그 책임을 계속 감당할 수 있는가?

자체 기술을 만드는 일이 필요한 때도 있다.

새로운 비즈니스 모델, 진정으로 새로운 기술 제품, 또는 독특한 운영 환경은 기존 도구가 제공할 수 없는 역량을 요구할 수 있다. 그런 상황에서 비즈니스를 사용 가능한 도구에 억지로 맞추면 회사의 발전을 가로막을 수 있다. 부족한 역량을 개발하는 일이 성장에 필수적일 수도 있다.

그 일을 거부하는 것은 불필요한 무언가를 만드는 것만큼 해로울 수 있다.

그 차이를 알아보려면 판단력과 스스로에 대한 정직함이 필요하다. 비즈니스가 진정으로 필요로 하는 역량과 우리가 소유하고 싶어 하는 플랫폼을 구분해야 한다. 그리고 비즈니스와 사용 가능한 도구가 달라지면 그 판단도 다시 검토해야 한다.

이는 더 넓은 질문으로 이어진다. 좋은 아키텍처란 무엇인가?

모든 회사가 따라야 하는 하나의 표준 아키텍처가 있다고 생각하지 않는다. 우리가 오늘 공부하는 아키텍처는 사람들이 특정 비즈니스, 제약, 도구에 대응하는 과정에서 생겨났다. 그들의 답을 채택하기 전에 그런 조건부터 이해해야 한다.

초기의 YouTube는 내가 자주 떠올리는 사례다. 인프라에는 미흡한 부분이 있었고, 소규모 엔지니어링 팀이 서비스 성장에 맞춰 병목을 계속 해결해 나갔다. 아키텍처가 여전히 진화하는 동안 비즈니스는 가치를 갖게 되었다. 성공하기 전에 미래의 모든 문제에 대한 완성된 답을 갖출 필요는 없었다.

내 경력을 거치며 나는 단순한 믿음에 도달했다. 좋은 아키텍처는 비즈니스와 함께 진화할 수 있다.

논문을 읽거나 다른 엔지니어에게 배우는 일을 그만두라는 뜻은 아니다. 그들의 경험은 더 나은 결정을 내리는 데 도움이 된다. 하지만 다른 사람의 아키텍처를 공부한다고 해서 우리 비즈니스를 이해할 책임이 사라지는 것은 아니다.

오늘의 비즈니스를 지원하고 내일 개선할 여지를 남겨 준다면, 나는 60점짜리 솔루션으로도 만족한다. 만드는 데 너무 오래 걸리거나 변경 비용이 지나치게 비싸지는, 소위 완벽한 아키텍처보다 그런 솔루션을 선택하겠다.

나머지 40점은 나중에 필요해질 수도 있다. 그중 일부는 끝내 중요하지 않을 수도 있다. 비즈니스가 발전하면서, 애초에 잘못된 요구사항을 기준으로 완벽함을 평가하고 있었다는 사실을 깨달을 수도 있다.

실제로 작동하는 시스템은 배울 수 있는 현실의 근거를 제공한다. 사용자가 어디서 어려움을 겪는지, 어디서 비용이 늘어나는지, 어떤 제약이 실제로 비즈니스를 가로막는지 볼 수 있다. 그 경험은 다음 투자를 어디에 해야 할지 판단하는 데 도움이 된다.

진화할 수 있는 능력에는 기능 추가 이상의 것이 포함된다. 의존성 업그레이드, 불필요한 구성 요소 제거, 내부 시스템 교체, 또는 특정 책임을 외부 서비스에 넘기는 일도 포함된다.

때로는 임시 시스템만으로 충분하다. 오늘의 비즈니스를 지원하고 나중에 교체하는 비용을 감당할 수 있다면, 이미 제 역할을 하고 있는 것일 수 있다. 모든 시스템이 영원히 존속할 필요는 없다.

오늘날 클라우드 플랫폼과 성숙한 오픈 소스 프로젝트는 기업이 과거에 직접 만들어야 했던 많은 역량을 제공한다. 이는 아키텍처의 경제성을 바꾼다.

인프라를 판매하는 회사라면 더 나은 인프라를 개발하는 일이 비즈니스 그 자체일 수 있다. 다른 회사라면 같은 투자라도 그것이 가능하게 하는 비즈니스 성과를 통해 그 가치를 입증해야 한다.

그 계산은 개발을 시작하기 전부터 시작해 시스템의 전체 수명에 걸쳐 계속된다. 구축과 테스트, 사용하는 팀의 교육, 통합, 유지보수, 디버깅, 업그레이드, 그리고 결국 마이그레이션이나 폐기까지 포함한다. 서버 비용 절감은 그중 일부일 뿐이다. 그 인력이 다른 일에 투입되었다면 무엇을 이룰 수 있었을지도 고려해야 한다.

프로세스를 최적화하기 전에, 비즈니스에 그 프로세스 자체가 여전히 필요한지부터 물어야 한다.

모든 대기업에 아직도 대규모 인프라 부서가 필요할까? 나는 그렇게 생각하지 않는다. 그 규모는 비즈니스의 필요, 외부에서 구할 수 있는 역량, 그리고 회사가 지속적으로 감당할 수 있는 책임에 따라 정해져야 한다.

아키텍처는 진화한다. 미리 모든 것을 설계해 둘 수는 없다. 앞으로 3년, 5년, 심지어 10년의 계획을 세울 수는 있지만, 아키텍처에는 비즈니스의 변화에 적응할 여지가 있어야 한다.

자신의 아키텍처가 앞으로 10년 동안의 모든 요구를 충족할 것이라고 주장하는 사람은, 사실상 미래를 예측할 수 있다고 주장하는 것이다. 그리고 정말 앞으로의 10년을 예측할 수 있다면, 그 재능으로 소프트웨어 아키텍처를 설계하는 것보다 더 나은 일을 할 수 있지 않겠는가.