구조가 기능을 결정한다. 형태는 기능을 따른다.

관계를 연결하면 흐름이 생기고 흐름이 생기면 시스템이 된다.

 생물학에서는 '구조가 기능을 결정한다'라는 표현이 있다. 생물체의 구조와 기능 간의 밀접한 관계를 설명하는 핵심 개념이다. 아래 예시는 특유의 구조가 특정 기능을 수행하는데 직접적인 영향을 미치는 것을 보여준다.

단백질과 세포의 구조와 기능

식물의 잎 구조와 광합성

동물의 기관과 기능

 정보산업에서도 구조와 기능이 있다. 정보의 구조는 데이터 스키마이다. 데이터 스키마는 정규화, 비정규화 등을 통해서 인덱스, 파티셔닝 등에 영향을 준다. 그리고 애플리케이션 측면에서 스키마는 애플리케이션의 엔티티를 정의하는데 크게 영향을 주며 이러한 영향은 기능의 한계를 '결정'한다. 

 예를 들어 결제 기능의 엔티티로 '제품(p)', '결제정보(t)', '고객(c)'이 있다고 하자 

p는 { id, customerId, price, name }

t는 { id, productId, customerId }

c는 { id, name }

그런데 단순 결제를 넘어서 구매한 고객의 명단 정보를 '지속적'으로 추출해야 한다고 하자. 그러면 제시한 엔티티로는 

첫 번째: t를 조회

두 번째: t의 customerId를 바탕으로 c를 조회

세 번째: c의 name을 구함

2번 조회해야 한다(혹은 관계형 데이터베이스라면 join을 해야 한다). 하지만 의도적으로 비정규화를 해서 t를 { id, productId, customerId, customerName }로 만들면 t만 조회하면 된다. 조회 2번을 1번으로 줄여서 '조회에 특화된 기능'이 생긴 것이다 (이번 예시는 너무 단순해서 굳이 비정규화가 필요하겠나 싶겠지만 일부러 단순화한 사례라는 걸 염두해 주시면 좋겠다).

 스키마의 구조가 기능을 결정하기에, 구조를 정한다는 건 미래의 기능에도 결정적인 영향을 준다. 때문에 구조를 매우 고심해야 하지만, 현실적으로 (미래의) 기능을 100% 명확히 파악하는 것은 불가능하다. 따라서 구조는 미래의 기능을 위해서라도 '적절히' 유연하도록 고민해야 한다. 물론 너무 유연한 구조는 불필요한 비용을 요구한다; 괜히 경력과 경험이 필요한 게 아니다. 

 산업적 건축을 선도했던 시카고파의 루이스 설리반은 '형태는 기능을 따른다'라고 했다. 이 원칙은 객체나 구조물의 형태가 그 기능에 의해 결정된다는 것을 의미하고, 다양한 분야에서 중요한 설계 원칙으로 자리 잡았다. 아래 예시를 통해 기능에 의해서 형태가 차이 나는 것을 확인할 수 있다.

건축물의 용도에 따른 형태

세단과 SUV의 형태의 차이

커머셜 서비스와 은행 서비스의 UI 차이 

 이를 정보 산업의 서비스로 끌어오면, 서비스 기능의 차이는 UI의 차이를 가져온다. 

커머셜 서비스에서는 상품의 나열, 결제, 검색, 장바구니와 같은 기능이 필요하고 이에 따른 UI가 뒤따라온다. 

은행 서비스는 잔고, 계좌, 인증, 이체 및 송금 등 기능에 맞춘 UI가 필요하다. 

다른 시장의 커머셜 서비스라도 커머셜 도메인이기에 비슷한 기능이 필요해서, 기본적으로 유사한 UI를 공통되게 가지게 된다. 

다른 시장이라고 해도 ERP, 백오피스는 비슷한 UI를 갖는다.

 예시대로 UI는 시장이나 도메인에 따라서 결정되는 게 아니라 기능에 따라서 결정된다. 이러한 과정은 수렴진화와 비슷하게 보인다. 수렴진화는 서로 다른 계통의 생물들이 유사한 환경적 압력으로 비슷한 기능이 요구될 때 비슷한 형태로 진화하는 현상을 의미한다. 

상어는 어류고 돌고래는 포유류지만, 물이라는 유체에서 빠르고 정확하게 이동하기 위해서 둘 모두 유선형의 몸체를 가지고 있고 등 지느러미가 발달했다. 

박쥐는 포유류고 새는 조류지만, 둘 모두 날기 위해서 날개라는 기관이 비슷한 형태로 진화했다. 

이러한 예시들을 살펴보면, UI가 기능에 따라서 결정되는 것은 '자연스럽게' 수렴진화하는 생물과 비슷하게 보인다; 그러니까 우리는 자연스러운 흐름에 '사족'달지 않는 게 좋겠다.

 이렇게 '구조가 기능을 결정한다'와 '형태는 기능을 따른다'에 대해서 고민해 봤다. 그럼 이 두 요소를 결합하면 어떠할까?; 재밌는 고민이다. 기능을 중심으로 '기능은 구조를 따르고 형태를 결정한다'라는 명제를 제시할 수 있을 것이다. 그리고 원래 각각의 문장을 살펴보면 2개의 요소로 되어 있었고 이는 요소의 '관계'를 나타낸다. 그런데 합친 문장은 3개의 요소로 구성되어 있다. 즉, 관계와 관계가 연결되어서 '흐름'을 만든다. 관계를 넘어서 흐름이 생겨나면서 시스템으로 진화하게 된다. 따라서 구조, 기능, 형태는 하나의 시스템을 완성하기에 충분한 구성 요소가 되는 것이다. 그리고 하나의 시스템은 하나의 서비스로 간주할 수 있으니 구조, 기능, 형태는 서비스의 필요조건이 된다.

 자동차의 동력기관을 만든다고 해보자. 동력기관을 개발하는데 필요한 요소로 특성, 연료, 동력기가 있을 것이다. 특성은 기능을, 연료는 구조를, 동력기는 형태를 구현한다.

승용, 가솔린, 카뷰레터 사용 엔진: 승용차용 동력기는 승차감을 위해서 높은 응답성과 정숙성이 요구된다. 이러한 기능을 실현하기 위해서 공학자들은 기화가 잘되는 가솔린을 엔진의 연료로 결정했다. 그리고 기화를 잘 시키고 민감한 반응을 위해서 엔진(동력기)에 카뷰레터를 사용했다.

상용, 디젤, 플런저 사용 엔진: 상용차용 동력기는 무거운 짐을 옮길 만큼 힘이 좋고 연료비용이 싸야 한다. 경유는 가솔린에 비해서 저렴하고 높은 연비를 갖는다. 또한 디젤은 가솔린 보다 열량이 높아 토크가 커서 무거운 짐을 옮기기도 좋기에 디젤을 사용한다. 디젤은 가솔린에 비해서 기화하기 어렵기 때문에 높은 압력으로 기화를 시켜야 했고 이에 고압으로 분사하는 플런저를 엔진(동력기)에 사용했다.

공해감소, 배터리, 모터: 내연기관은 공해를 일으키고 공해를 줄이기 위해서 연소가 필요 없는 에너지원이 필요하다. 이를 위해서 전기배터리가 결정된다. 전기는 내연기관처럼 화학적 에너지가 아니기에 당연히 동력기는 모터가 할당된다.

예시를 통해 하나의 시스템(서비스)을 구조, 기능, 형태로 분해해 보았다. 이러한 예시를 바탕으로 구성 요소 3가지를 정보 산업에 적용해 보자.

서버: 기능(특성)에 해당한다. 정확히 따지면 서버는 기능의 집합체이다. 서버는 가지고 있는 기능으로 목적한 효익을 제공한다.

데이터 스키마: 구조(연료)에 해당한다. 기능을 구현하기 위해서는 알맞은 데이터 스키마가 필요하다. 거래를 위해서는 객체형 스키마가 유리하며, 조회 및 통계를 위해서는 로그형 스키마가 유리할 것이다

UI: 형태(동력기)에 해당한다. 각 서비스 요구 조건에 맞춰서 UI가 영향을 받는다. 같은 게임이라고 해도 전략 시뮬레이션 게임, 롤플레잉 게임, 퍼즐 게임의 UI는 게임 목적에 맞춰 각기 다르다.

 지금까지 3가지 요소를 분석하고 이를 바탕으로 서비스를 계획하고 완성하는 과정을 알아보았다. 정보 산업의 서비스는 인간의 활동(혹은 생각)을 가공하고 제공하는 일련의 흐름이다. 인간의 활동은 원유(Crude Oil)이고, 이를 어떻게 정유(스키마)하는가에 따라 가솔린, 디젤, 항공유 등 다양한 연료(데이터)가 만들어질 것이다. 그리고 살펴봤듯이 연료는 기능을 결정하니까 연료를 잘 아는 건 더 강력한 기능, 더 명확한 기능을 구현할 수 있도록 해준다. 마지막으로 이 연료로 트럭, 승용차, 배, 비행기 등 다양한 형태로 기능을 제공할 수 있다. 정보 산업은 이런 과정을 통해 인간의 문제를 해결한다. 이번 글을 통해서 서비스의 필요조건을 확인하고 이를 바탕으로 독자의 서비스 개발이 조금이라도 더 빨라지고 명확해지는데 도움이 되었으면 좋겠다. 그리고 나아가 독자의 서비스가 인간의 문제를 해결하는데 응원한다 :-)