정책은 코드에 종속되어선 안 된다. (Policies should not be subordinate to the code.)

정책은 코드에 종속되어선 안 된다. (Policies should not be subordinate to the code.)

예전에 실용주의 프로그래머의 서평을 쓴 적이 있다. 거기에서 가장 깊게 와닿았던 부분이 정책과 코드에 대한 부분이었는데 사실 서평에도 써있다시피 실제 책에 나온 표현은 그냥

 

정책은 수시로 바뀐다

 

가 전부였다. 하지만 너무 포괄적인 문장이지 않은가. 해서 정책은 코드에 종속되어선 안 된다라는 의미로 혼자 받아들였고 또 실제 구현에 있어서도 굉장히 도움이 되는 말인지라 스스로에게 상기시키기 위해 포스트잇에 써서 모니터에 붙여놨는데 동료분도 굉장히 좋은 말인 것 같다고 말씀해주셨다. 그래서 많은 사람들이 보면 좋을 것 같아 조금 더 공개된 장소에 적어두는 것이다.

 

실용주의 프로그래머에 나온 예를 그대로 적용하자면 이런 시나리오를 그릴 수 있다. ERP시스템을 구축할 때 인사관리에 대한 요구사항에 ※해당 직원의 관리자와 인사부에서만 그의 기록을 열람할 수 있다. 라는 항목이 있을 때 이것을 과연 코드에 종속되게 만들어야 할까? 예를 들어 직원이라는 클래스가 있고 거기에 소속과 직함이라는 속성이 있는데 소속이 꼭 인사부이거나, 혹은 소속이 같고 직함이 관리자일 때만 다른 직원의 기록을 열람할 수 있게 말이다. 나는 이것이 틀린 방법이라고 단호히 말할 수 있다.

 위에서도 말했다시피 정책은 수시로 바뀐다. 따라서 코드에 정책을 종속시키는 건 좋지 않은 방법이다. 해당 직원 관리자와 인사부에서만 그의 기록을 열람할 수 있게 만들어야할 게 아니라 이런저런 정책에 대응할 수 있는 방향으로 만들어야 한다. 그러니까 결국 애초에 요구사항은 정책을 제외한 채 기능을 명세할 수 있을 정도의 일반적 진술로 만들어야 할 뿐더러 나머지 구현은 엔지니어에게 역임해야 한다. 그리고 엔지니어도 저런 요구사항을 받았을 때 그냥 납득하지 않고 되물어야 한다. "이 정책은 회사가 망할 때까지 변경이 없습니까?" 이렇게 물었을 때 담당자가 그렇다고 하더라도 유연하게 대응할 수 있게 만들어야 한다. 말 그대로 software는 soft해야하기 때문이다.

 애초에 devops나 CI(지속적 통합 : Continuous Integration)가 각광받게 된 배경에도 클라이언트의 잦은 변덕과 변경, 혹은 정책의 수정에 대해서 개발자들이 납득하고 포기했기 때문이라는 말이 있지 않은가. 아무쪼록 이 글이 많은 개발자들에게 도움이 됐으면 하는 바람이다.