대칭적 signature와 비대칭적 signature

인터페이스 설계에서 오퍼레이션은 그 나름대로 책임을 가지게 된다. 즉, 해당 오퍼레이션을 호출하기 위해 입력받는 정보에 대해서는 호출하는 측(이하 클라이언트)에서 그 데이터가 올바로 들어갔는지를 점검할 책임이 있으며, 입력된 정보를 가지고 출력 정보를 형성하는 측(이하 서버)에서는 반환 정보에 대해서 올바른 값이 들어갔는지를 점검할 책임이 있다. 다시 말해서, 오퍼레이션은 사전 조건(precondition)과 사후 조건(postcondition)에 만족한 상태가 되어야 클라이언트와 서버가 원활하게 정보를 주고 받을 수 있다.

이와 같은 책임성에 기반해서 설계하는 방식을 '계약에 의한 설계(design by contract)'라고도 한다. 메시지를 주고 받는 양측은 서로 조건에 만족시킬 책임(responsibility)과 의무(obligation)를 양측에게 가지며, 이는 계약과 같은 형태로 존재하기 때문에 어느 한쪽이 이를 무시하거나 지키지 않는다면, 응당 그에 대항하는 책임이나 의무를 지을 필요가 없게 된다. 예를 들어, 숫자 1을 입력받고 한글 '하나'를 반환하는 오퍼레이션의 경우, 숫자 1이외의 값이 넘어오는 경우에 당연히 한글 숫자 '하나'를 반환할 의무가 없으며, 그외의 기타 예외나 null과 같은 형태로 계약이 파기되었음을 알릴 필요가 있다. 클라이언트에서는 오퍼레이션을 호출할 때 입력값을 올바르게 넣을 책임이 있으며, 이러한 책임은 서버에서 그에 합당한 올바른 값을 반환할 의무가 발생하는 것이다. 마찬가지로, 서버가 올바른 값을 반환할 것이라고 생각한 클라이언트가 올바른 값을 받지 못할 때에(서버가 올바른 값을 넘겨줄 책임을 다하지 못하는 경우), 클라이언트는 반환된 값에 대해 마찬가지로 계약 파기와 같은 행위(예외 처리와 같은)를 할 수 있다.

Apple Temptation by Lawrence OP

인터페이스 명세는 이러한 'Design by Contract (DbC)'라는 원칙을 준수할 수 있도록 기술(description)되어야 하며, 이는 문서를 만드는 경우에도 마찬가지로 포함되어야 한다. 하지만, 현실 세계에서는 이러한 원칙으로 인터페이스 명세를 작성하는 예를 찾아보기란 힘든게 사실이다.

여기에 한가지 현실적인 팁을 제공하자면, 이러한 DbC에 대한 명세를 제공하지 못한다면, (비)대칭적인 오퍼레이션을 제공하는 것도 방법이 될 수 있다. 즉, 대칭적인 오퍼레이션이란 정보를 저장하는 행위와 조회하는 행위를 일치시키는 방식으로 저장하는 구조 그대로 조회하는 오퍼레이션을 제공하는 것이다. 비대칭은 저장하는 정보의 구조와 조회하는 정보의 구조가 달라지는 형태라고 보면 된다.

이 경우, 정보를 검증하는 책임의 위치가 다소 달라질 수 있을 것이다. 예를 들어, 은행에 돈을 맡기는 경우, 고객이 1만원권 5장을 저금하고, 나중에 이 돈을 출금하는 경우, 은행 입장에서 1만원권 5장을 제공하는 경우와 5만원권 1장을 제공하는 경우로 나누어 볼 수 있다. 1만원권 5장의 경우에는 고객이 이미 1만원권을 알고 있고, 응당 저금시의 형태와 출금시의 형태가 같기 때문에 이는 자신이 받아야 하는 금액으로 인식을 할 것이다. 하지만, 은행이 5만원권을 내어주는 경우에는 고객이 만일 5만원권에 대한 인지를 하지 못한다면, 은행은 고객에게 5만원권 1장이 1만원권 5장과 같음을 증명해야 할 것이다.

결론적으로, 대칭적인 오퍼레이션을 제공하는 경우, 클라이언트 측에서는 저장에 상응하는 조회 오퍼레이션을 서버측이 제공함으로써 자신이 입력한 정보가 저장이 되었는지를 점검할 수 있으나, 비대칭적인 오퍼레이션을 제공하는 경우, 서버측에서 저장된 정보가 조회시 올바로 조회되는지에 대한 책임을 져야 한다.

이러한 (비)대칭 오퍼레이션[기능]에 대한 부분은 테스트를 통해서 충분히 검증이 가능하다. 예를 들어, 돈을 이체하는 기능의 경우, 이체를 요청하는 측(클라이언트)은 입금액을 파라미터로 넘기고, 잔액을 리턴으로 받아서 이체에 대한 검증을 이체를 수행하는 주체(서버)에서 이를 수행하게끔 할 수도 있다.(비대칭 signature) 혹은 이체를 수행하고 나서 그 결과값만을 보내고, 이체를 요청하는 측(클라이언트)에서 잔액을 다시 조회함으로써 이체에 대한 결과를 검증해볼 수 있다.(대칭 signature)

통상 설계나 구현을 할 때에 이러한 검증에 대한 고려를 하지 않는다면, 어느 한쪽에 치우친 기능만이 도출될 우려가 있다. 즉, 검증을 고려하여 기능의 책임을 양측(기능을 호출하는 측과 이를 제공하는 측)에 대한 균형을 유지하는게 좋은 설계라고 볼 수 있다.

기능이 비대칭적으로 혹은 대칭적으로 설계/구현이 되었든 간에 기능 검증의 책임은 서버와 클라이언트 측 어느 한곳에 반드시 있어야 하며, 이를 검증할 수 있는 메커니즘은 반드시 필요하다. 비대칭의 경우, 서버의 상태를 투명하게 보이게 하거나 혹은 외부에서 진입될 수 있는 지점을 열어놓음으로써 이러한 검증을 수행할 수 있고, 대칭의 경우, 클라이언트 측에서 서버가 제공하는 기능을 사용해서 검증할 수 있어야 한다. 전자는 식별된 기능을 중심으로 식별된 내용을 그대로 유지한 채 시스템을 설계하는 방식이 될 것이며, 후자의 경우에는 식별된 기능 이외에 안보이는 기능을 추가로 식별하는 과정으로 볼 수 있을 것이다. 후자는 최초 기능 식별에서 나타나지 않는 기능이라 하더라도 점차 기능 식별이 더 활발하게 진행되고 SW가 완성되어 가는 과정에서 이러한 기능은 재사용될 가능성이 더 높다.

계좌이체 예제에서 잔액을 확인하는 기능은 비대칭으로 구현시 계좌이체 프로세스 내에 섞여있는 형태로 나타나지만, 대칭 형태로 구현시에는 잔액 확인은 다른 기능에서 재사용될 가능성이 높아지고, 결국 현재 식별/구현되는 기능 이외에서 필요한 기능이 될 가능성이 높다.

대칭과 비대칭 signature는 시스템을 설계/구현하는 입장에서 어떤 것이 사용하기에 더 적합한지를 고려하여 선택하게 된다. 하지만, 이 두가지 형태는 모두 책임과 의무를 어느 측에 둘 것인가를 고려하면서 양측에게 이러한 책임과 의무가 균형을 이루도록 설계하는 DbC 원칙을 유지하게끔 하는 방식이라고 보면 된다.