거의 작동하지 않는 매력적인 Systems 아이디어

거의 작동하지 않는 시스템 아이디어

• "그냥 플러그 가능하게 만들자"

  • 하나의 구현이 작동하지 않을 때, 개발자들이 새로운 구현을 쉽게 추가할 수 있도록 하자는 아이디어임. 하지만 대부분의 경우, API가 제공하는 기능이 기대만큼 쉽게 작동하지 않음. 진정한 플러그 가능성을 위해서는 두 번째 구현이 처음부터 함께 설계되어야 함.

• "그냥 API를 추가하자"

  • 플랫폼을 만들고 개발자들을 끌어들이기 위해 API를 추가하는 경우가 많음. 하지만 API 제공은 호환성과 상호운용성을 위한 지속적인 노력이 필요하며, API를 제공한다고 해서 반드시 사용자가 생기는 것은 아님. 플랫폼 구축은 진지한 사업이며, 단순히 API를 제공하는 것만으로는 경제적 기반을 제공하기 어려움.

• "한 번 더 추상화하자"

  • 컴퓨터 과학의 문제는 또 다른 수준의 간접 참조로 해결할 수 있다는 말이 있음. 하지만 너무 이른 추상화는 유지보수와 보안, 성능 최적화에 어려움을 초래할 수 있음. 계획 없이 추가된 추상화는 코드 유지보수를 어렵게 만듦.

• "비동기화하자"

  • 비동기화는 컴퓨터 과학에서 오랜 연구 주제였음. 웹 프레임워크는 이를 잘 추상화했지만, 프레임워크 밖에서 비동기화를 직접 관리하려고 하면 예측 불가능한 버그가 발생할 가능성이 높음.

• "접근 제어는 나중에 추가하자"

  • 시스템 보안은 처음부터 고려되어야 하지만, 시장 출시 속도 때문에 종종 나중에 추가됨. 고객과 적의 관점에서 접근 제어를 처음부터 고려하지 않으면, 나중에 제품을 다시 설계해야 할 가능성이 높음.

• "데이터를 동기화하자"

  • 데이터 동기화는 매우 어려운 문제로, 경험을 통해서만 해결할 수 있는 도전 과제가 많음. 데이터 동기화를 기반으로 솔루션을 구축하는 것은 거의 바람직하지 않음.

• "크로스 플랫폼으로 만들자"

  • 크로스 플랫폼 개발은 운영 체제나 클라우드 제공자, 브라우저를 구축하는 것과 유사함. 플랫폼이 새롭거나 애플리케이션이 간단할 때는 작동할 수 있지만, 시간이 지남에 따라 점점 더 어려워짐.

• "네이티브로 탈출할 수 있게 하자"

  • 크로스 플랫폼이 제한적일 때, 네이티브 기능으로 탈출할 수 있도록 하는 것이 일반적임. 하지만 이 방법은 프레임워크가 유지하는 상태와 충돌할 수 있어, 9번 중 10번은 실패함.

• 결론

  • 이러한 접근 방식이 항상 실패하는 것은 아니지만, 대부분의 경우 더 나은 방법이 있음. 기본 원칙에 따라 문제를 해결하고 실패 가능성이 높은 소프트웨어 패턴을 피하는 것이 중요함.