Separation of mechanism and policy
정책과 메카니즘의 분리는 CS 분야의 중요한 설계 원칙이다. 메카니즘은 여러 결정들에 따라 정책을 지시하거나 지나치게 제한해서는 안된다. 리소스 할당과 오퍼레이션을 승인하는 시스템을 구현하는 것이 메카니즘이고, 어떤 오퍼레이션을 인가할 것인지, 어떤 리소스를 할당해줄건지를 결정하는 것이 정책이다.
가장 많이 이 주제에서 논의되는 분야는 바로 보안 메커니즘이다. CPU 스케줄링, 메모리 할당, QoS와 같이 다양한 SW 추상화에서 "정책과 메카니즘의 분리"가 실천되고 있다.
Pen Brinch Hansen이 RC4000 multiprogramming system 에서 이 개념을 처음 도입했으며, Artsy와 Livny는 1987년도 논문에서 "극도로 분리된 메카니즘과 정책"에 대한 접근을 논의했다. 2000년도에는 Chervenak은 "메카니즘 중립성과 정책 중립성"에 대해 언급했다.
근거와 결과 Rationale and Implications#
모놀리식 커널과 구분되는 마이크로커널에 대한 근본적인 접근이 바로 이 정책과 메카니즘의 분리에서 왔다. 마이크로커널은 유저 레벨 서버 프로세스들과 프로세스들의 실행들에 대한 권한을 부여하는 보안 정책으로 분리되어있다. 운영체제가 현실에서의 다양한 보안 정책을 지원하기 위해 적절한 메카니즘을 사용하는 것은 운영체제에 유연성을 부여한다고 한다.
하드코딩된 정책은 여러 유저의 요구에 맞추기 매우 부적절하다. 소프트웨어 시스템이 생애주기에 걸쳐 여러 종류의 유저에 의해 사용되기 위해선 어떻게 해야할까? 정책 명세서로부터 구체적인 메카니즘 구현을 분리(Decouple)하게되면 같은 메카니즘이라도 여러 정책들을 수용할 수 있는 유연성을 갖게될 것이다. 이 말은 곧 더 긴 생애주기동안 더 많은 유저들의 요구를 수용할 수 있다는 의미이기도 하다.
구현을 변경하지 않고도 다양한 정책을 수용할 수 있다면, 정책 변경에 대한 위험부담과 비용이 굉장히 줄어들게 될 것이다. 보안정책 외적으로도 "코드를 작성하지 않아도" 시스템의 행동방식을 변경하고 정책을 수정하는 일이 가능해지는 것이다. 어디서 익숙하지 않은가? 바로 설정창에서 보던 것들이다. 시스템을 하나의 커다란 함수로 보고 설정을 일종의 매개변수로 본다면 정책과 메카니즘의 분리가 조금 더 쉽게 느껴질 것이다. 설정이라는 측면은 시스템에 있어서 late binding이 가능해지며, 심지어 런타임 도중에, API를 통하여 원격으로 정책을 갈아끼울 수도 있게된다.