메뉴는 콘텐츠 노출과 그에 따른 사용자 트리거 도구이다

감히 시도하는 설계의 정석

Oct 13. 2025

제로 클릭과 같은 '인공지능 발 UI 혁명' 따위에 대해 생각하고 있다가 문득 메뉴와 UI 그리고 명령어 사이의 근본적인 혹은 개념적인 관계가 궁금해졌습니다.

메뉴와 UI 그리고 명령어 사이의 관계

그래서, 퍼플렉시티에게 물었습니다. 그 결과를 훑어보다가 개념도를 다시 UML로 변환해 달라고 요구했습니다. 동시에 클로드에게도 그림으로 그려 달라고 요청했습니다. 아래 그림 중에서 우측이 클로드가 그린 관계도입니다. 둘 다 부정확하지만, 아무것도 없는 상태에서 생각을 이어가는 것보다는 이들이 그려준 것에서부터 시작하는 것에 분명한 이점이 느껴집니다.[1]

전통적인 의미에서 프로그램은 사전에 지정된 작업을 수행합니다. 인공지능 때문에 이런 고정관념이 깨지고 있기 때문에 '전통적인 의미'라는 말을 붙였습니다. 아무튼 종전의 프로그램을 중심으로 한 맥락이라면 명령어는 프로그램된 어떤 작업에 사용자가 개입하는 것을 의미합니다.

메뉴는 명령어 실행의 트리거로 작동한다

이와 같은 맥락에서 퍼플렉시티가 포착한 '실행 트리거'라는 연관 관계는 매우 직관적입니다. 그런데, 다음과 같이 질문하면 유용해 보이던 관계에 대한 평가가 달라질 수도 있습니다.

메뉴만 명령어 실행을 트러거 하나요?

버튼을 눌러도 명령어가 실행된다 할 수 있습니다. 그럼 버튼은 메뉴인가요? 웹 브라우저를 쓰는 상황이면 주소 창에 주소를 입력해도 명령어가 실행된다고 할 수 있습니다. 비슷하게 하이퍼 링크가 걸린 글자나 이미지를 클릭해도 변화가 생기는데, 이건 명령어 실행이 아닌가요?

개념적인 정리는 빈틈이 생기는 순간 무용한 듯이 느껴지기도 합니다. 그래서 엄밀함을 요구하는 이론이나 학문의 영역에 가면 딱딱함이 느껴지고, 분류가 중요한 이유도 이와 관련이 있지 않을까 싶습니다.

그래서, 일단 맥락을 메뉴로 제한하기로 합니다. 다양한 명령 실행 방식에 대한 부분은 생각 범위 밖으로 보내는 것이죠. 흔히 관심사의 분리(SoC)[2]라고 하는 사고법이죠.

메뉴는 주방(공급자)에 사용자 선택을 전달하는 수단

이렇게 범위를 제한하고 나니 세 가지 생각이 남습니다. 첫 번째로 아무리 제로 클릭이라고 해도 메뉴는 필요하다는 점입니다. 예를 들어 시리 같은 음성 비서로 말을 하더라도 '시리야' 하고 호출을 해야 합니다. 이는 메뉴의 변형이라고 보는 편이 유리할 것 같습니다.[3] 또한, 스마트 안경에 적용한다고 해도 원하지 않는 상호작용이 일어나는 것을 막으려면 '메뉴'에 해당하는 어떤 장치는 반드시 필요할 듯합니다. 설사 그걸 메뉴라고 부르지 않는다고 하더라도 말이죠.

이쯤 되니 메뉴라는 말의 뜻을 찾아보고 싶어 집니다. 콜린스 사전의 뜻은 세 가지로 나뉘네요.[4]

In a restaurant or café, or at a formal meal, the menu is a list of the food and drinks that are available.

A menu is the food that you serve at a meal.

On a computer screen, a menu is a list of choices. Each choice represents something that you can do using the computer.

두 번째로 남겨진 생각은 클로드가 그려 준 그림 때문에 생겨난 것입니다. 흔히 메뉴는 화면에 따라 달라지거나 계층 형태로 묶여서 나타난다는 현상을 확인합니다.

여기서 세 번째 생각이 파생되는데요. 화면에 딸린 메뉴와 맥락에 딸린 메뉴로 나눌 수 있다는 생각이 들었습니다. 이는 적당한 가르마일까요?

콘텐츠의 노출과 그에 따른 사용자 트리거 도구

지금까지 묻고 따진 내용으로 메뉴가 크게 둘로 나뉠 수 있다는 생각이 들었습니다. 하나는 다른 콘텐츠로 이동하고 싶은 메뉴입니다. 식당의 메뉴처럼 다른 것을 고르는 것이죠. 선택의 결과로 돌아오는 것이 콘텐츠인 이유는 웹의 영향입니다. 브라우저가 기본적으로는 웹 콘텐츠를 다루는 것인 이유겠죠. 다른 종류의 메뉴는 콘텐츠를 보고 사용자가 주문하는 다양한 기능을 작동시키는 것입니다. 기능의 범주는 다양한데, '좋아요'를 누르는 것일 수도 있고, 댓글을 올리는 것일 수도 있고, 혹은 구매 버튼을 누르는 것일 수도 있겠죠.

이렇게 UML 형태로 구조를 만들어 그려 놓고 보니 소프트웨어 설계 경험 때문인지 Command와 Query를 구분하는 CQRS 패턴이 떠올랐습니다. 두 종류의 메뉴 구분이 Command와 Query 이분법과 꽤 닮아 있다는 생각이 들었습니다.

다만, 두 생각의 맥락이 다르다는 점을 떠올릴 수 있었습니다. 메뉴를 떠올릴 때는 브라우저에 바탕을 두고 있었죠. 그러니 콘텐츠 노출과 그에 따른 사용자의 반응을 트리거하는 도구가 메뉴란 사실을 깨닫습니다. 그에 반해 Command와 Query 구분은 Entity 기반의 웹 프로그래밍을 처리(Operation)를 정렬하기 위한 사고와 설계의 틀이라고 하겠습니다.

모든 메뉴가 아니라 콘텐츠 브라우징 메뉴

브라우저에 대한 새삼스러운 인식이 메뉴의 역할을 좁혀서 인식하게 도왔습니다. 제가 다루고 있는 대상은 모든 메뉴가 아니라 콘텐츠를 기반으로 하는 메뉴란 사실을 드러내기 위해 UML 클래스도를 다시 그렸습니다.

그렇게 자꾸 따져 보니 콘텐츠를 주로 조회하거나 즐기는 소비자용 앱과 다르게 흔히 어드민(Admin) 또는 인트라넷이라고 부르는 업무용(혹은 백엔드) 화면으로 나눠야 서로 다른 맥락을 섞는 오류를 줄일 듯합니다.

주석

[1] <인공지능을 공동지능으로 길들이는 네 가지 원칙> 중에서 '원칙 1. 작업할 때 항상 AI를 초대한다'를 다시 떠올립니다.

[2] Separation of Concerns의 소통 효과 참조

In computer science, separation of concerns (sometimes abbreviated as SoC) is a design principle for separating a computer program into distinct sections.