2025년에 노후가 심각한 소프트웨어 아키텍처 결정

Source: Dev.to

Software architecture is a set of bets about the future — about what the system will need to do, at what scale, under what constraints, and with what team.
소프트웨어 아키텍처는 미래에 대한 일련의 베팅이며 — 시스템이 무엇을 해야 할지, 어떤 규모에서, 어떤 제약 하에, 그리고 어떤 팀과 함께 할지를 의미합니다.

Some of those bets age well. Others do not.
그 중 일부 베팅은 시간이 지나도 잘 유지되지만, 다른 것들은 그렇지 않습니다.

The following four architectural decisions were each, in their time, defensible — often enthusiastically adopted as best practices. They are now generating significant operational cost for the organisations that made them, and the organisations that can identify and address them early are recovering delivery velocity that has been silently consumed for years.
다음 네 가지 아키텍처 결정은 각각 당시에는 방어 가능했으며 — 종종 최선의 실천법으로 열정적으로 채택되었습니다. 이제는 이를 만든 조직에게 상당한 운영 비용을 초래하고 있으며, 이를 조기에 식별하고 해결할 수 있는 조직은 수년간 조용히 소모되어 온 전달 속도를 회복하고 있습니다.

1. 잘못된 규모의 마이크로서비스

마이크로서비스 움직임은 분산되고 독립적으로 배포 가능한 서비스가 실제 운영 제약을 해결할 수 있는 규모에서 조직에 진정한 개선을 가져왔습니다. 수백 명의 엔지니어와 복잡하고 이질적인 기술 요구사항을 가진 대규모 조직에게는 마이크로서비스 아키텍처가 독립적인 팀 규모 확장, 격리된 배포, 그리고 실제로 중요한 기술 다양성을 가능하게 했습니다.

하지만 작은 조직—그리고 초기 단계에 있는 대규모 조직—에서는 많은 마이크로서비스 도입이 시기상조된 최적화였습니다. 분산 시스템의 복잡성, 서비스 간 통신 오버헤드, 수십 개의 독립 배포 서비스를 운영하는 운영 부담, 그리고 함수 호출을 대체한 네트워크 호출이 초래하는 지연은 조직이 아직 도달하지 않은 규모에서만 정당화될 수 있는 비용을 초래했습니다.

그 결과, 현재 업계 전반에 걸쳐 분산 모놀리식을 운영하는 상당수의 엔지니어링 팀이 존재합니다—마이크로서비스의 운영 복잡성을 가지고 있지만, 그 복잡성을 정당화할 팀 규모나 기술 이질성이 부족한 시스템입니다.

이제 이러한 팀들이 직면한 결정은 간단하지 않습니다. 아키텍처는 이미 구축되어 있고, 서비스들은 운영 이력을 축적했으며, 서비스 간 의존성 때문에 통합이 쉬운 일은 아닙니다. 그러나 실제 규모와 운영 현실에 비추어 마이크로서비스 아키텍처를 솔직히 평가하는 팀들은, 밀접하게 결합된 서비스를 통합하면 아키텍처가 제공해야 할 유연성을 크게 감소시키지 않으면서도 운영 오버헤드를 감소시킬 수 있다는 점을 일관되게 발견하고 있습니다.

2. MongoDB for Everything

2010년대 초반의 NoSQL 열풍은 문서 데이터베이스, 특히 MongoDB 위에 구축된 세대의 애플리케이션을 낳았습니다. 이들 애플리케이션은 스키마 유연성이 실제로 중요한 제품 개발 단계에서 유연성과 개발자 친화성을 이유로 선택되었습니다.

10년이 지난 지금, 많은 애플리케이션이 스키마가 사실상 고정되고 데이터 관계가 복잡하며 잘 이해되는 수준까지 진화했으며, 문서 모델의 유연성은 더 이상 주요 고려사항이 아닙니다. 이제 애플리케이션이 필요로 하는 것은 트랜잭션 무결성, 복잡한 쿼리 기능, 그리고 관계형 데이터 모델이며, 이는 문서 데이터베이스가 제공하지 않도록 설계된 기능입니다.

마이그레이션 비용은 실제로 존재합니다—문서 데이터베이스가 기술적으로 관계형 데이터베이스보다 열등하기 때문이 아니라, 문서 모델에 수년간 축적된 데이터가 관계형 스키마로 깔끔하게 변환되지 않으며, 문서 의미론을 중심으로 구축된 애플리케이션 로직을 재작업해야 하기 때문입니다.

이 문제를 가장 효과적으로 해결하고 있는 팀들은 전체 데이터베이스 마이그레이션을 시도하고 있지 않습니다. 대신 관계형 의미론이 가장 필요로 하는 데이터 모델 부분에 관계형 스토어를 점진적으로 도입하고, 유연성이 여전히 실질적으로 가치 있는 부분은 문서 저장소를 유지하고 있습니다.

Source: …

3. JWT 토큰이 어디에나

JSON Web Token은 2010년대 중반에 다양한 애플리케이션의 기본 인증 메커니즘이 되었으며, 그 이유는 명확합니다. 무상태 인증은 확장성이 뛰어나고 데이터베이스 부하를 줄이며, 점점 주류가 되고 있던 API‑first 아키텍처와 자연스럽게 맞아떨어졌기 때문입니다.

당시 충분히 고려되지 않았던 설계상의 트레이드‑오프—그리고 현재 상당한 운영 비용을 초래하고 있는 점—은 JWT는 만료되기 전까지는 취소할 수 없다는 것입니다.

수명이 긴 토큰의 경우, 이로 인해 발생하는 운영 현실은 다음과 같습니다. 침해된 자격 증명이 만료될 때까지 유효하게 남아있고, 사용자가 로그아웃해도 전통적인 의미에서 실제 로그아웃되지 않으며, 사용자의 권한 변경이 현재 토큰이 만료될 때까지 적용되지 않습니다. 보안 태세가 중요한 애플리케이션에서는—그리고 실제로 보안이 크게 중요하지 않은 애플리케이션의 수는 많은 팀이 생각하는 것보다 적습니다—이 트레이드‑오프를 정당화하기가 점점 어려워지고 있습니다.

보완책은 매력적이지 않습니다: 토큰 허용 목록을 사용하거나, 토큰을 짧게 발급하고 리프레시 메커니즘을 도입하는 방법인데, 이는 JWT가 도입된 이유였던 무상태 서버‑사이드 조회를 다시 도입하는 결과를 낳습니다. 그러나 이는 장기적인 보안 태세를 포기하고 단기적인 확장성을 추구한 설계 선택에 대한 솔직한 대응이라 할 수 있습니다.

4. 환경 변수에서 임의로 구성하기

Twelve‑factor 앱 방법론은 환경 변수를 애플리케이션 구성의 정규 메커니즘으로 만들었으며, 그 원칙은 타당했습니다: 코드를 외부화하고, 환경 전반에 걸쳐 일관되게 관리한다.

하지만 이 원칙은 수백 개의 환경 변수를 수십 개의 서비스, 여러 배포 환경, 그리고 운영 규율 수준이 동일하지 않은 팀들 사이에서 관리해야 하는 실제 상황을 다루지 못했습니다.

그 결과, 많은 조직에서 구성 관리 환경은 어느 곳에 무엇이 구성되어 있는지 전체 그림을 파악하기 어려울 정도로 복잡해졌습니다. 비밀 정보가 민감하지 않은 구성과 뒤섞이고, 구성 값이 서비스 간에 중복되며 단일 진실 원천이 없습니다. 변경 사항은 여러 배포 구성 간의 조정을 필요로 합니다. 특정 시점에 존재했던 구성을 감사하는 것은 어렵거나 불가능합니다.

점점 채택되고 있는 대응책—전용 비밀 관리 도구, 중앙 집중식 구성 서비스, 비밀과 구성을 명확히 분리하는 방식—은 새로운 아키텍처가 아니라, 규모가 커질 때 환경 변수 접근 방식이 반드시 요구하게 될 운영 성숙도이며, 많은 팀이 비용이 감당할 수 없게 될 때까지 미뤄왔던 것입니다.

이러한 패턴을 일찍 인식하고 점진적이며 실용적인 리팩터링 단계를 밟음으로써, 팀은 잃어버린 속도를 회복하고 기술 부채의 숨은 비용을 줄일 수 있습니다.

공통된 실

이 네 가지 결정은 공통된 특징을 가지고 있습니다. 각각은 특정 단계에서, 특정한 이유로 올바른 선택이었으며, 그 선택이 잘못되었기 때문에 기술 부채가 된 것이 아니라, 그 선택을 정당화하던 상황이 변했음에도 재검토되지 않았기 때문에 기술 부채가 된 것입니다.

제품‑시장 적합성을 찾아가고 있던 10인 팀에 적합했던 아키텍처 결정은 신뢰성과 배포 속도를 최적화하려는 100인 팀에게는 종종 잘못된 아키텍처가 됩니다. 중요한 질문은 그 결정이 당시 옳았는가가 아니라, 그 결정을 옳게 만든 조건이 아직도 적용되는가입니다.

현재 상황에 맞춰 현재의 결정을 평가하는—결정이 이루어진 당시의 상황이 아니라 현재의 상황에 비추어 보는—정기적이고 솔직한 아키텍처 리뷰가 누적되는 기술 부채를 가시화하고 관리 가능하게 만드는 실천입니다.

WiseAccelerate는 모든 참여에 아키텍처 리뷰 규율을 도입합니다 — 팀이 무엇이 잘 작동하고, 무엇이 오래되어 문제가 되었으며, 가장 큰 효과를 낼 수 있는 개선점이 무엇인지 명확히 파악하도록 돕습니다.

→ 여러분의 팀이 경험한 네 가지 아키텍처 결정 중 어느 것이 있었으며, 어떤 해결 방안이 효과적이었나요?