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

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

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

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

• "그냥 API를 추가하자"

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

• "한 번 더 추상화하자"

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

• "비동기화하자"

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

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

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

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

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

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

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

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

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

• 결론

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

[ndrgrd]

플러그의 경우 필수 동작만을 최대한 걸러내서 인터페이스를 설계하는 것이 가장 중요하죠.
인터페이스를 그냥 현재 코드에서 대강 구조 따와서 만들면 당연히 해당 구현에 얽매이는 불필요한 인터페이스가 되지만 그런 경우가 정말 많죠...

[neo]

Hacker News 의견

• DSLs와 API는 종종 성공적으로 작동함. TensorFlow와 같은 추론 엔진도 DSL이나 DSL을 감싸는 API로 볼 수 있음

  • SQL, Shader 언어, BPF 등도 유사한 예시로 볼 수 있음
  • "그냥 API를 추가하자"는 접근은 성공적이지 않을 수 있음. UI를 구현할 때처럼 신중하고 철저하게 접근해야 함

• DSLs는 때때로 훌륭하게 작동함. jOOQ.org를 참고할 수 있음

• Elastic Load Balancer는 워크로드에 반응하는 제어 루프임. 이는 일종의 상품임

• 대부분의 산업에서 자원 부족이 만연함. 관련 자료로 erikbern.com과 "Goal: Process of Ongoing Improvement"를 참고할 수 있음

• 이상 탐지는 분산 시스템의 문제가 아님. 하지만 문제를 겪은 사람들은 필요하다고 생각할 수 있음

  • Isolation Forest 알고리즘은 때때로 기적적임. 2018년에는 텍스트에 CNN 기반 임베딩을 사용하여 좋은 결과를 얻었음

• "거의"라는 표현은 여기서 효과적이지 않음. 이는 단순한 비관주의와 냉소주의임

• 많은 사람들이 예외에 대한 미묘한 결정 함수를 찾으려 함. 하지만 실제로는 간단함. 내가 하면 잘 되고, 이전 사람이 하면 잘 안 됨

• "Domain Driven Design"은 사업 구조에 맞춰 애플리케이션을 설계하는 것은 재앙의 레시피임

  • 작은 사업에서는 문제가 없을 수 있지만, 성공하거나 성장하는 사업에서는 즉시 후회할 수 있음
  • 대신 기능 계층을 중심으로 설계하고, 가능한 한 비즈니스 로직을 구성, 데이터베이스의 행, 사용자 워크플로에 유지해야 함

• 로드 반응 제어 루프는 기본적이고 필수적인 구성 요소임. 많은 시스템에서 사용됨

• 여러 DSLs, P2P 캐시, 하이브리드 병렬성을 사용하는 프로젝트를 작업했으며, 대부분 성공적이었음

  • P2P 캐시는 필요하지 않아 큰 성과를 내지 못했음
  • 복잡하지만 그 복잡성이 다른 방식으로는 달성하기 어려운 기능을 제공함

• "그냥 데이터를 동기화하자"는 접근은 문제를 일으킬 수 있음

  • 많은 시스템이 "인터넷 규모"를 목표로 설계되었지만, 실제로는 그 범위 이하임
  • 이러한 팀은 순진하거나, 최악의 경우 비엔지니어링 관리자를 이용하여 문제를 해결하는 데 자금을 사용함

• 여러 아이디어를 성공적으로 실행했음. 따라서 약간 이상하게 읽힘