"기존의 상황을 더 선호하는 상황으로 바꾸기 위해 행동의 경로를 고안하는 사람은 누구나 디자인을 한다." 허버트 사이먼(Herbert Simon)이 『The Sciences of the Artificial』에서 내린 디자인의 정의에는 색도, 폰트도, 화면도 등장하지 않는다. 디자인의 중심은 산출물이 아니라 행동의 경로를 고안하는 판단에 있다는 것이다. 비즈니스 지표, 사용자 행동 데이터, 과거의 성공과 실패, 이해관계자 간의 합의가 얽힌 의사결정의 연속이 디자인이고, 화면은 그 판단의 최종 출력물일 뿐이다. 프롬프트 한 줄이면 그럴듯한 화면이 나오는 시대, AI가 흔하게 만든 것은 출력물이지 판단이 아니다.
진짜 문제는 디자인 결정의 근거들이 어디에도 온전히 보존되지 않는다는 점이다. 디자인의 결과는 캔버스나 실제 제품으로 남지만, 그 결정의 이유는 담당 디자이너의 머릿속과 공유되지 않은 개인 문서, 혹은 각 채널의 쓰레드 속에서 조용히 파묻힐 것이다. 과거의 의사결정 맥락을 파악하지 못해 조직이 헤매고, AI마저 그럴듯한 할루시네이션 결과를 내뱉는 것은 기록되지 않은 데이터에서 논리를 추론해 낼 수 없기 때문이다.
기록이 남아 있는 경우에도 크게 도움이 되지 않는다. 순수 LLM과 일반적인 RAG pipeline은 디자인 자산을 비정형 텍스트와 이미지로 취급할 수밖에 없기에, 근본적으로 '좋은 디자인'을 뽑기에는 어려운 점들이 많았다. AI를 통해 '적당히 괜찮은' UI 디자인을 손쉽게 쏟아낼 수 있게 된 오늘날, 디자인의 중요성은 폄하되고 있다. 'Design is dead'를 외치는 이들은 대체로 디자인에 대한 이해가 가장 피상적인 수준에 머물러 있다. Claude Design과 Design.md가 이에 대한 방증일 것이다. 디자인 지식을 읽을 수 있는 형태로 외재화하자는 방향 자체에는 동의하지만, 문제는 구조와 입도다. 평문 마크다운 문서는 온톨로지가 아니다. "우리 브랜드는 신뢰감을 준다" 같은 서술로는 에이전트가 왜 이 버튼이 이 색이어야 하는지 추론할 수 없고, 얕은 시각적 일관성만을 추구하는 시스템은 규모가 커질수록 구성 요소가 지닌 진정한 의미를 상실한다.
지식의 구조가 없으니 축적도 쉽게 이루어질 수 없다. 단발적인 대화 세션에 의존하는 Design Agent는 이전 프로젝트의 결정을 학습하지 못한다. 세션이 끝나면 결정의 맥락은 증발하고, 같은 개념이 프로젝트마다 조금씩 다른 의미로 흩어질 수 밖에.
이러한 한계를 넘어서 AI가 진정한 의미의 창조적 디자인을 수행하도록 하기 위해서는, Agent가 판독할 수 있는 디자인 지식의 정형화된 모델링과 온톨로지가 필요하다. Figma와 같은 캔버스에서 생성한 화면 단위의 디자인과 실제 제품의 비즈니스 지표뿐만 아니라, 디자이너의 의사결정 과정과 같은 정성적 판단 기준까지 모두 온톨로지로 구조화하고 지식 그래프로 엮어내는 방안에 대해 고민한다.
돌고돌아 결국 온톨로지
온톨로지는 특정 도메인 내의 Entity, 이들이 지닌 Property, 참여하는 Relation, 그리고 이들이 준수해야 하는 Constraints를 공식적이고 논리적으로 설명하는 명세이다. 철학적으로는 존재의 근본적인 범주를 탐구한다면, 엔지니어링적으로는 기계 시스템이 복잡한 지식 구조를 이해하고 추론할 수 있는 의미론적 상호운용성(Semantic interoperability)을 달성 가능하게 하는 인프라이다.
딱 1년 전쯤, 나는 Palantir의 Ontology Platform과 같은 AX 솔루션을 제공하고자 하는 스타트업의 일을 잠깐 도운 적도, (실제 창업으로 이어지진 못했으나) 사내 SaaS의 데이터를 모두 연결해 검색 가능한 Search Engine & Knowledge Base를 구축해주는 솔루션의 Pitch Deck을 만들기도 했었다. 복직 후 UX Platform 조직에서 디자이너를 위한 도구와 에이전트를 만드는 데 몰두하면서, 결국 우리에게 가장 절실한 것은 흩어진 지식을 검색할 수 있는 Design Knowledge Base와 이를 받쳐줄 Data Pipeline이라는 결론에 닿았다. 이에 단순한 문제 제기를 넘어 구체적인 솔루션과 목표를 담은 One-pager를 발제했고, Head의 전폭적인 공감을 이끌어내며 팀 빌딩과 함께 본격적인 프로젝트를 시작했다.
디자인 온톨로지 (Design Ontology)
디자인이라는 행위를 온톨로지 관점에서 구조화하기 위해서는 Function-Behaviour-Structure(FBS) 프레임워크가 좋은 인지적, 철학적 토대가 될 수 있을 것 같다. FBS 온톨로지는 특정 디자인 분야(건축, 기계, 소프트웨어 등)에 국한되지 않고, 물리적이든 가상적이든 사회적이든 모든 설계된 아티팩트를 묘사할 수 있는 독립적인 스키마를 제공한다. 이는 복잡한 UI/UX 디자인 에셋을 기계가 이해할 수 있는 단위로 분해하고 조립하는 데 필수적인 기준이 된다.
FBS 프레임워크는 디자인 대상을 세 가지 근본적인 구성 요소로 정의한다. 첫째, 기능(Function)은 인공물의 목적론적 측면으로, '이 인공물이 무엇을 위한 것인가'를 의미한다. 이는 인간의 목표와 인공물의 측정 가능한 효과 사이의 연결을 확립함으로써 부여된다. 둘째, 행동(Behaviour)은 인공물의 구조로부터 도출될 수 있는 속성으로, '인공물이 무엇을 하는가'를 나타낸다. 이는 품질, 시간, 비용 등 서로 다른 인공물들을 비교하기 위한 측정 가능한 성능 기준을 제공한다. 셋째, 구조(Structure)는 인공물을 구성하는 요소들과 그들 간의 관계로, '인공물이 무엇으로 구성되는가'를 정의한다.
여기에서 주목해야할 것은 기능(F)과 구조(S) 사이에는 직접적인 연결이 없다는 것이다. 인간은 경험을 통해, 그리고 인공물과의 상호작용을 기반으로 인과적 모델을 개발함으로써 기능, 행동, 구조 사이의 연결 고리를 구성한다. 설계 과정은 본질적으로 이 세 가지 개념 간의 변환 집합으로 표현되고, 가장 기초적인 형태는 기능에서 행동으로($F \rightarrow B$), 그리고 행동에서 구조로($B \rightarrow S$) 변환되는 과정이다. 요구는 기능($F$)으로 진입하고, 에이전트는 과거 데이터베이스에서 전환율을 높였던 행동 지표($B$)를 검색하고, 이를 유발했던 구체적인 UI 패턴과 색상, 여백 등의 구조($S$)를 역추적한다. 이러한 논리적 흐름이 지식 그래프에 체계적으로 편입될 때, AI가 단순한 조합을 넘어 스스로 추론하며 '디자인'을 한다고 할 수 있을 것이다.
디자인 의사결정의 온톨로지화
디자인 시스템이 포함하는 UI 컴포넌트, 컬러 토큰, 타이포그래피, 패턴 등의 기하학적 정보와 제품의 정량적 지표가 온톨로지의 뼈대와 근육을 형성한다면, 이를 움직이는 신경망은 '왜 이런 결정을 내렸는가'에 대한 맥락, 즉 설계 근거(Design Rationale, 이하 DR)이다. 설계는 디자이너뿐 아니라 개발자, 마케터, 기획자, 유저 등 다양한 이해관계자 사이의 수많은 피드백과 타협의 산물이며, 이러한 정성적 판단 기준을 지식화하지 못하는 시스템은 반쪽짜리 지능에 불과할 것이다.
DR은 제품 구성 요소 이면에 존재하는 정당성과 의사결정 과정을 문서화하는 것으로, 창조적 아이데이션을 자극하고 개념 설계 단계에서 새로운 해결책을 촉진하는 필수적인 지식 범주이다. 그러나 전통적인 워크플로우에서 이러한 지식들은 늘 디자이너 개개인의 머릿속에 암묵지(Tacit knowledge) 형태로 머물렀고, 여러 제약으로 제대로 기록되지 못했다.
다행히 DR을 구조화하려는 시도는 이미 오랜 계보가 있다. IBIS(Issue-Based Information System)는 논의를 이슈(Issue)-입장(Position)-논거(Argument)의 그래프로 기록하고, QOC(Questions, Options, Criteria)는 설계 공간을 질문-대안-평가 기준의 매트릭스로 펼쳐놓는다. 이 모델들을 스키마 삼으면 Slack 스레드의 갑론을박이나 critique 세션의 코멘트도 온톨로지에 편입 가능한 형태가 된다. 예컨대 아래와 같은 트리플들로 표현할 수 있을 것이다.
checkout_button --hasVariant--> solid_high_contrast
solid_high_contrast --justifiedBy--> experiment_2412
experiment_2412 --improved--> checkout_cvr
experiment_2412 --rejectedOption--> ghost_button이 지점이 신경망과 심볼릭 체계의 역할 분담이 필요한 곳이기도 하다. 비정형 대화에서 이슈와 논거의 후보를 추출하는 일은 LLM이 잘하는 일이고, 추출된 지식이 스키마와 제약을 준수하는지 검증하고 기존 그래프와의 정합성을 유지하는 일은 심볼릭 계층이 잘하는 일이다. 생성은 신경망이, 검증과 추론의 근거 유지는 온톨로지가 맡는 구조가 가장 합당하다.
실제 조직에서
AI와 지식 그래프를 현실에 적용하는 것은 엔지니어링적으로 적지 않은 비용이 든다. 무엇을 만들어야 하는지 머릿속에 청사진이 명확하더라도, 이를 내가 속한 조직에서 제대로 작동하는 시스템으로 구현해 내는 것은 다르다. 지식 그래프를 만드는 것과 별개로 Figma, Slack, Notion 등 다양한 SaaS 플랫폼에 파편화되어 기록되는 비정형 데이터와 의사결정 내역을 하나의 온톨로지로 통합 수집하는 데이터 파이프라인을 구축하는 것 역시 필요하기 때문이다.
타 도메인의 업무 데이터를 체계적으로 모으고 활용하는 시스템(데이터 마트와 레이크 등)이 잘 갖춰져 있는 반면, 디자인에 있어서는 지표와 정성적 판단 근거를 포괄하여 명확히 온톨로지화한 선례를 찾아보기 어렵다.
현재 업계에서 이와 가장 유사한 역할을 고민하는 곳은 아마 사내 디자인 시스템을 운영하고 최적화하는 Design Platform 조직일 것이다. 다만, (많은 과업들이 있지만) 밖에서 관찰했을 때에는 Design System의 UI Component 배포를 관리하고, design to dev handoff를 자동화하고 팀원 간의 작업을 조율하는 수준에 머물러 있는 경우가 많았다. 디자인 플랫폼 공급자가 실무자들의 실제 작업 방식을 관찰해 귀납적으로 반복적인 패턴을 추출하고, 이것이 자동으로 디자인 시스템의 새로운 규칙으로 쌓이도록 만드는 파이프라인이 부재하다. 여러 군데 흩어진 설계의 근거와 맥락을 뽑아내어 지식 그래프로 연결하는, 진정한 의미의 데이터 파이프라인을 운영하는 사례는 거의 찾아보기 힘들었다.
이러한 파이프라인을 자체적으로 구축하려면 각 SaaS의 API를 사용한 커넥터와 파서가 필요하다. 예컨대, 슬랙의 논의 스레드나 노션 문서와 피그마 에셋 간의 불일치를 자동 감지하려면, 이슈 트래커의 ID 같은 공통 기준을 의무적으로 적용하는 조직 차원의 그라운드룰이 필요하다. 데이터 스크래핑, 텍스트의 벡터화, 그리고 실시간 동기화를 유지하기 위한 클라우드 인프라 비용 등을 총체적으로 판단해야 한다. 따라서 진정으로 디자인 온톨로지를 통한 원대한 목표를 달성하기 위해서는, 큰 초기 투자 비용을 상쇄할 만큼의 확실한 효용을 낼 수 있도록 서포트할 수 있는 Design Intelligence 조직의 데이터 엔지니어링 역량과 리소스가 필수적이다.
디자인 온톨로지가 성공적으로 작동하기 위해서는 이론적 모델을 넘어, 실제 작업 환경에서 생성되는 막대한 양의 디자인 데이터를 실시간으로 추출하고 이를 구조화된 지식으로 매핑하는 엔지니어링 파이프라인이 뒷받침되어야 한다. 그간 내가 만들어왔던 인하우스 디자인 에디터(Deus)가 있었다면 사실 좀 더 수월했을 수 있으나, 안타깝게도 우리는 몇 달 전 Figma 도입과 함께 Deus의 종료를 결정했다. 때문에 밑바닥부터 완벽하게 통제하는 수준의 파이프라인 구축은 불가하다. 애초에 모든 데이터와 워크플로우를 완벽하게 통제할 수 있는 단일 플랫폼을 구축하겠다는 것은 매력적인 '유토피아'에 불과하다. 현실적인 디자인 온톨로지의 완성은 거대한 자체 플랫폼을 구축하는 것이 아닌, Figma를 포함해 이미 각 영역에서 고도화된 3rd-party SaaS를 얼마나 매끄럽고 유기적으로 엮어내느냐에 그 성패가 달려 있을 것이다.
결론
우리는 디자인을 시각적 요소들을 평면적인 화면 위에 배치하는 것이 아닌, 사용자 행동 지표, 복잡한 비즈니스 로직, 그리고 다수의 이해관계자가 얽힌 공학적 협의의 과정으로 이해해야 한다. 화면 단위의 패턴을 학습해 평균 수준의 디자인을 뽑는 Design Agent만으로는 이 맥락을 이해할 수도, 일관성 있는 디자인 생태계를 유지할 수도 없다. 필요한 것은 캔버스의 구조 데이터, 정량적인 A/B 테스트 지표, 그리고 디자이너 간의 critique과 design rationale까지 포괄하는 Design Ontology다. FBS 프레임워크로 인공물을, IBIS와 QOC로 의사결정을 구조화하고, 신경망이 추출한 지식을 기호적 제약이 검증하는 파이프라인이 이를 받친다. 에이전트의 모든 산출물이 지식 그래프 위의 근거로 소급 가능해질 때, "결제 버튼, 왜 이 색이에요?"라는 서두의 질문은 더 이상 침묵으로 끝나지 않는다.
이러한 암묵지들을 모두 명시지로 전환하고, 지속적으로 개선이 되는 지식 베이스를 만들 수 있다면 디자이너의 역할은 급격한 패러다임의 전환을 맞이할 것이다. 픽셀 단위의 시각적 형태를 다듬는 것이 아닌, 디자인 룰과 온톨로지를 정의하고 AI 에이전트의 추론 과정을 검토하고 승인하는 지식 시스템의 큐레이터로 무게중심이 더욱 옮겨갈 것으로 기대한다.
요즘 나는 Data Pipeline을 어떤 기술로 구축할 것인가와 같은 엔지니어 관점의 질문 만큼이나, 더 거시적인 질문들을 던지며 프로젝트를 이끌고 있다. 이 온톨로지를 누가 만들어가고 어떻게 유지보수할 것인가. 비정형 대화에서 DR을 어디까지 자동으로 추출하고 어디부터 사람이 승인해야 하는가. 온톨로지 스키마는 누가, 얼마나 자주 개정할 것인가. 어떤 핵심 시나리오를 기반으로 PoC를 진행하고, 문제를 어떻게 좁혀나가볼 수 있을까.
p.s. 최근 몇 번의 프로젝트를 진행하면서 깊게 느끼는 점이 있다면, 각자의 철학이 부딪히는 상황에서 프로젝트가 무너지거나 표류하는 것은 '가장 완벽한 답'을 찾으려 하기 때문이라는 것이다. 프로젝트를 완성하는 것은 정답 보다도, 자신의 선택을 정답으로 만들어내는 끈질긴 의지다. 아름답고 완벽한 아키텍처나 솔루션을 가져와도, 구성원들에게 공감대를 얻지 못하거나 끝까지 책임지고 완성해 낼 의지가 없다면 그것은 '틀린' 선택이 된다. 이론적인 완벽함이나 논리적 무결성과 같은 단어들은 매혹적이지만, 여기에 매몰되어서는 안된다. 결국 자신이 옳다고 믿는 바를 누가 끝까지 관철해 내는가 하는 싸움일 뿐이다.