AI 시스템에서 사용자의 의도와 컨텍스트를 다루는 방식, 그리고 이를 위해 필요한 ‘컨텍스트 배관 공사’에 대한 논의
지난 몇 주 동안 나는 코드 속에 깊이 파묻혀서 내가 **컨텍스트 배관 공사(context plumbing)**라고 부르는 일을 하고 있다.
AI 시스템을 만들고 있는데, 딱 그런 느낌이다.
풀어서 이야기해 보자.
의도(Intent)
대략적으로 말하면 AI 인터페이스란 의도와 컨텍스트에 관한 것이다.
의도는 사용자의 목표다. 크든 작든, 명시적이든 암묵적이든.
컴퓨터 세계에서 독특한 점은, AI가 이 의도를 이해하고 매우 인간적인 방식으로 응답할 수 있다는 것이다. 이것은 새로운 능력이다! 예를 들어 사용자가 I want to buy a camera 라고 타이핑하거나, 키라이트를 가리키며 속삭이듯 I’ve got a call in 20 minutes 라고 말하거나, remove clouds라는 버튼을 누르면 끝.
기업들이 여기에 관심을 갖는 이유는, 사용자의 의도에 더 가까운 컴퓨터가 이기기 마련이기 때문이다.
e.g. 스마트폰이 데스크톱을 밀어낸 이유도 그렇다. 휴대폰에서는 무언가를 보고 바로 손가락으로 그걸 터치한다. 데스크톱에서는 그 의도가 포인터를 통해 매개된다. 화면에서 어떤 것을 보더라도, 상호작용을 하려면 팔을 움직여 마우스를 움직이고, 그 마우스가 포인터를 움직이게 해야 한다. 별거 아닌 것처럼 보여도, 당신의 원숭이 뇌는 그걸 좋아하지 않는다.
그래서 똑같은 논리가 전반적인 사용자 인터페이스에도 적용된다. 메뉴에서 명령을 고르는 것, 휴가를 계획하려고 웹페이지를 이리저리 돌아다니며 정리하는 것, 집 HVAC(냉난방) 컨트롤 패널을 어떻게 조작해야 하는지 기억해 내는 것… 이런 것들은 전부 관료제다. 원하는 결과까지의 순서를 스스로 찾아내야 하는 것은, 의도와 결과 사이에 끼어 있는 _행정적 부담(administrative burden)_이다.
이제 AI 회사 입장에서는 그 부담을 없앨 수 있다. 그리고 사용자의 의도 – 욕구 –가 솟아오르는 바로 그 1밀리초 순간, 바로 그 위치에 존재하고 싶어 한다. 사용자가 굳이 주머니에서 휴대폰을 꺼내는 수고조차 하게 만들고 싶지 않고, 무의식적인 의도를 말로 정식화하도록 만들고 싶지도 않다. 의도가 처음 생겨나는 지점에 가장 가까이 있는 쪽이 경쟁사를 밀어낼 것이다.
그래서 AI 기능이 들어간 안경, 목걸이형 기기, 마이크, 몸짓을 읽는 카메라 같은 장치들이 그렇게 밀어붙여지는 것이다.
이게 내가 인터페이스의 미래는 "내 말 뜻대로 해(Do What I Mean)"라고 생각하는 이유다. 단지 AI가 가능하게 한 새로운 능력일 뿐 아니라, 여기에 전체적인 ‘주의(attention) 경제학’의 동인이 붙어 있기 때문이다.
컨텍스트(Context)
AI가 의도를 정말, 정말 잘 다루게 만드는 것은 컨텍스트다.
물론 대규모 언어 모델 자체 안에 세계 지식이 있다. 거대한 양의 학습 데이터에서 얻은 것이다.
하지만, 어떤 AI 에이전트가 사용자 의도를 받아서 일련의 도구 호출(sequence of tool calls)을 통해(에이전트란 이런 식으로 동작한다) 목표를 향해 힐클라이밍(hill-climbing)을 한다고 해보자. 이때 프롬프트가 온갖 유용한 컨텍스트로 채워져 있으면 훨씬 더 잘 작동한다.
예를 들면 이런 것들이다:
이런 배경에서 컨텍스트 엔지니어링(context engineering)이라는 아이디어가 나왔다 (LangChain 블로그).
컨텍스트 엔지니어링은 LLM이 과업을 그럴듯하게 완수할 수 있도록, 올바른 정보와 도구를 올바른 형식으로 제공하는 동적 시스템을 구축하는 일이다.
그리고, 컨텍스트에 대한 접근 가능성은 대형 AI 회사들의 몇 가지 행동도 설명해 준다.
사용자 의도에 가장 잘 답하려면, 사용자의 컨텍스트가 있는 곳에 있어야 한다. 그래서 항상 켜져 있는 카메라가 달린 목걸이형 기기가, 그때그때 켜는 일반 카메라보다 선호되는 거고, 이메일 아카이브 속에 사는 AI 에이전트가 그렇지 않은 에이전트보다 훨씬 효율적인 것이다. 그러니 이들은 정말로 그 안에 들어가서, 아주 가깝게 들러붙고 싶어 한다.
(그리고 추론 시점의 컨텍스트는 기록만 된다면 매우 귀한 학습 데이터이기도 하다.)
배관 공사(Plumbing)?
컨텍스트 엔지니어링이라는 개념에서 빠져 있는 것은, 컨텍스트가 동적이라는 점이다. 컨텍스트는 변한다. 시의성을 가진다.
컨텍스트는 사용자 활동이나 사용자를 둘러싼 환경 변화에 따라 여기저기서 나타난다. 사용자가 하고 있는 일이 바뀌고, 이메일이 도착하고, 문서가 수정되고, 더 이상 밖이 맑지 않고, 이용 가능한 도구들이 업데이트된다.
이 컨텍스트는 AI가 실제로 실행되는 곳에 항상 있는 게 아니다(그리고 AI는 가능한 한 사용자의 의도 지점에 가깝게 실행된다).
그래서 에이전트를 정말 잘 돌아가게 만드는 일은, 컨텍스트를 필요한 곳으로 옮기는 일이 된다.
본질적으로 말하면, 한 데이터베이스에서 데이터를 복사해서 다른 데이터베이스에 넣는 일이다. 다만 이걸 연속적으로 수행하는 것이다.
AI 에이전트가 매번 사용자의 의도에 답할 때마다, 그때그때 컨텍스트를 조회하게 만들고 싶지 않을 때가 많다. 느리기 때문이다. 에이전트가 빠르게 행동하길 원한다면, 미리 계획해야 한다. 컨텍스트가 생성되는 곳에서 사용될 곳으로, 잠재적인 컨텍스트가 흐르도록 파이프를 미리 깔아 둬야 한다.
그렇다면 이 작업을 어떻게 백그라운드에서 끊임없이, 그러면서도 대역폭이나 연산 자원을 낭비하지 않고, 데이터가 낡지 않게 유지하면서 수행할 수 있을까?
그래서 나는 AI 시스템의 기술 아키텍처를, 컨텍스트의 소스와 싱크를 잇는 배관(plumbing) 작업으로 생각하고 있다.
예전 Web 2.0 시절, 기본적인 기술 아키텍처는 “CRUD” 앱이었다. 데이터베이스를 감싼 웹앱이고, 그 안에서 엔티티들이 있고, 이들에 대해 create, read, update, delete 연산을 하는 구조(이것들은 HTTP 메서드이기도 하다).
이것은 동시에 사용자 경험이기도 했다. 사용자라는 엔티티에는 웹페이지(프로필)가 있고, 사진 같은 객체 엔티티에도 웹페이지가 있었으며, 동적인 웹페이지가 스트림이나 피드 같은 여러 방식으로 이 엔티티들을 인덱싱했다. 그리고 웹앱을 이런 방식으로 분해할 수 있었다. 기술 구조와 사용자 이해가 정렬돼 있었던 셈이다.
AI 시스템에서는, 사용자가 어떤 컨텍스트가 AI에게 제공되는지에 대해 직관을 갖게 만들고 싶다. 컨텍스트 흐름에 대한 배관은 단지 기술적으로 가능하거나 효율적인 것에 그치지 않고, 사용자 기대와도 맞아떨어져야 한다.
아무튼.
이제 슬슬 – 당신에게, 독자인 당신에게 – 너무나 추상적으로 들리리란 걸 알고 있다.
하지만 내 입장에서는, 지난 2년 동안 만들려고 애써 온 플랫폼을 지금 드디어 만들고 있다. 이번에는 실제로 돌아간다.
나는 Cloudflare 위에 이걸 구축하고 있고, 온갖 엔티티와 AI 에이전트, 서브 에이전트 사이에 컨텍스트가 필요한 곳으로 흐르고 있다. 그런데 전혀 꼬이거나 헷갈리지 않는다. 배관 공사가 딱 맞게 되어 있기 때문이다.
그리고 아직 이게 정확히 무엇인지 구체적으로 말할 수 있는 단계는 아니지만, 적어도 이 점만큼은 적어 두고 싶었다.
