[Talk] 객체 지향과 인터페이스 디자인에의 의의

디자이너들에게 '객체지향'이라고 하면 사용자 경험 디자인(UX Design)과 같이 사용자, 손님을 먼저 생각하는 개념으로 오인하는 경우가 있다. 이 '객체(Object)'라는 개념이 낯설어서인데, 객체는 손님 객자를 써서 시스템을 사용하는 누군가를 의미하는 것으로 생각할 수 있지만 사실 주체(Subject)의 반대로서 번역된 용어이며, 오히려 '개체'에 더 가까운 개념이다.

개발에서 이야기하는 '객체'란, 그 자체로 완결성을 가진 프로그램의 블록을 의미한다. 객체와 비교되곤 하는 것이 함수(Function) 또는 프로시저(Procedure)인데, 이들은 입력된 값을 계산해 결과값을 출력하는 단위들이다. 작동을 위한 인자(parameter)가 존재하며, 이를 인수(argument)의 형태로 대입하여 사용한다. 즉, 인수를 대입하는 어떤 주체가 존재하며 이 주체가 없이는 그 자체만으로 독존할 수 없다.

객체는 내부에 이러한 요소들을 내장하고 있는 독립된 단위를 의미하는데, 기본적인 값과 이를 처리하는 메서드(Method)를 모두 가지고 있어 객체 자체만으로도 존재할 수 있다. 단지 객체가 외부에서 전달받는 속성(property)이나 상태(state)에 따라 내부의 메서드를 실행하여 그 표현을 바꿀 뿐이다.

때문에 객체는 이를 정의하는 어떤 '주체'에 해당하는 존재 없이도 스스로 존재할 수 있으며, 단지 객체와 객체 간 또는 외부로부터의 입력, 이벤트를 통해 변화하는 완성된 형태라고 할 수 있다. 다른 프로그래밍 방식이 '페이지(Page)'를 만들고 그 내부에 속한 원소(element)에 필요한 데이터를 외부의 함수를 통해 처리받음으로써 동작한다면 객체지향적인 프로그램은 각각의 객체가 외부의 신호에 따라 움직임으로써 전체의 그림을 만드는 식이라고 할 수 있다. 즉, 전자가 하향식(Top-down)으로 동작한다면, 후자는 상향식(Bottom-up)으로 각 객체가 모여 전체적인 그림(View)을 만든다.

이를 디자인에 적용한다면 어떨까. 어떤 시스템을 기획하고 그 형태를 제안하는 데 있어서 사용자의 작업에 따라 페이지를 부여하고 그 페이지에 맞는 요소들을 세부적으로 결정하던 방식에서, 시스템을 구성하는 객체를 정의하고 그 객체의 상태와 형태를 만든 뒤 이를 조합하는 방식으로 전환할 수 있는 것이다. 이러한 방식은 몇 가지 강점을 가질 수 있다.

먼저, 기존의 기획 방식은 기획자가 예측하는 사용자의 작업과 그에 따른 페이지에 종속되어 버린다는 문제가 있었다. 기획자의 역량과 경험에 많은 부분을 의존하게 되며 예상하지 못했던 분기나 케이스가 발생하는 경우 기획의 많은 부분들이 수정되고 조정되어야 한다. 이러한 일이 몇 번 반복되면, 처음에 깔끔하게 정돈되었던 기획이 어느샌가 이리저리 꼬이고 충돌하는 것을 볼 수 있다. 물론 프로젝트의 기한과 예산은 한정되어있기 때문에 이를 말끔히 고치는 것은 항상 한계가 있다.

둘째로, 결국 페이지 단위로 기획된 장들은 그 개별 요소들에 열심히 역동성을 부여하여도 그 장면 안에서 움직일 수 밖에 없다. 반면 개별 요소의 집합으로서 시스템을 조직하면 각자가 개별적으로 움직이면서 이러한 단조로움을 피할 수 있다. 물론 무조건 피해진다는 것은 아니고 개별 요소가 이벤트에 따라 반응하는 프로그래밍이 필요하지만, 태생적인 한계를 극복할 수는 있다는 것이다.

뭔가 디자인이 단조롭고 열심히 작업해도 갇힌 듯이 움직이는 느낌이 든다면, 객체 지향과 모던 어플리케이션 개발 패턴 등을 참조해보면 좋은 답이 나올 것이라 생각한다. 화면을 이루는 작은 요소들부터 출발하면 어쩌면 그 답답함을 풀어주는 실마리가 잡힐지도 모르겠다.