감히 시도하는 설계의 정석
노트북LM 덕분에 몇 달 사이에 습관으로 자리 잡은 '기사 요약 듣기'와 페벗 님의 글 덕분에 생겨난 아이디어를 상태(State) 표현 맥락에서 쓰는 글입니다.
먼저 ByteByteGo의 기사 <The Memory Problem: Why LLMs Sometimes Forget Your Conversation>을 구글 노트북LM에 넣고 음성 요약을 생성해서 들었습니다. 전체적인 내용보다는 초반에 앞선 대화를 기억하지 못하는 LLM의 근본적인 특성을 설명하는 부분에 꽂혔습니다.
그때 제 머릿속에서는 이런 말이 흘러나왔습니다.
아, LLM도 Stateless로 구현했군!
그리고 머릿속에서는 Stateless가 유리한 상황에 대해 과거에 배웠던 내용들이 함께 연상되고, 사실상 혼자서 컴퓨팅 자원을 점유해야 했기에 메인프레임 사용자 대기열 이미지가 반대 상황으로 떠올랐습니다. 하지만, 그저 혼자 생각할 뿐 아직 글을 쓰겠다고 결심하기에는 동기가 부족했습니다.
글을 쓰게 만드는 트리거는 페북에 있었습니다. 이민석 교수님의 글이 방아쇠를 당겼죠. 앞선 팟캐스트 때문인지 'AI 응용 제품의 윤리'를 다루는 이 글을 보면서 '상태State'와 연관 지어서 보게 되었습니다.
대략 이런 식이죠.
(유사 생명체로 인식한 소비자를 속이지 않으려면)
Stateless가 되면 안 되고, 단일 상태를 유지하는 Stateful
혹은 Singleton이어야 하네!
자, 이제 상태를 둘러싼 서로 다른 접근과 이들이 주는 효용에 대해 차분히 글을 써 보겠습니다. 먼저, 퍼플렉시티(이하 '퍼플')에게 ByteByteGo 기사를 주고 LLM이 무상태(Stateless)로 구현한 이유를 물었습니다.
서버 어느 하나가 대화를 담당하더라도 이전 상태를 기억하지 않고, 모든 요청이 독립적으로 처리되면서도 어느 서버나 쉽게 요청을 처리해 부하 분산과 확장성이 좋아집니다.
서버 장애가 발생해도 다른 서버가 대화 중단 없이 이어받을 수 있어 안정성이 강화됩니다.
사용자의 대화 기록이 서버에 저장되지 않아 개인정보 보호 측면에서 유리합니다.
자바 웹 서비스에 익숙한 분이라면 LLM을 전혀 몰라도 낯이 익은 내용이 아닐까 싶습니다. 다시 말해서 LLM에 특화된 설계 노하우가 아니란 것이죠. 다수 사용자를 위한 분산 프로그래밍을 위한 대단히 상식적이고 보편적인 노하우라 하겠습니다.
계속해서 퍼플에게 Stateless가 아키텍처 패턴으로 볼 수 있는지 묻고, 쓰임새를 물었더니 이렇게 제시합니다.
RESTful 웹 서비스: 클라이언트의 상태 정보를 서버가 저장하지 않으며, 각 요청이 독립적으로 처리됩니다. 이 덕분에 서버 확장과 부하 분산이 쉽습니다.
서버리스 컴퓨팅 (예: AWS Lambda, Azure Functions): 함수 호출 시 상태를 저장하지 않고 독립적으로 실행되어 빠른 확장과 비용 효율성을 제공합니다.
마이크로서비스 아키텍처: 각 서비스가 자체 상태를 저장하지 않고, 필요한 데이터는 클라이언트나 데이터베이스에서 가져와 처리합니다.
CDN(Content Delivery Network): 사용자 요청을 처리할 때 캐시된 정적 콘텐츠를 제공하며, 각 요청이 독립적입니다.
이번에는 정반대에 가까운 싱글톤(Singleton) 패턴을 보겠습니다. 단 하나의 인스턴스만 존재하게 하는 객체지향 프로그래밍 패턴입니다.
객체지향 프로그래밍 맥락은 AI 제품의 윤리와는 맥락이 멀다고 할 수 있는데도 위키피디아 내용에서 관련 있는 문장들을 찾을 수 있습니다.
로깅 은 싱글톤의 일반적인 실제 사용 사례입니다. 메시지를 로깅하려는 모든 객체는 균일한 액세스 지점을 필요로 하며 개념적으로 단일 소스에 쓰기 때문입니다.
로깅은 한 곳에서 해야 신뢰도를 줄 수 있습니다. 반려 로봇도 생명체와 유사하려면 기록이 단일하게 그리고 누적적으로 유지되어야 합니다. 마치 인간의 '기억'처럼요.
1. 옵션: 공동의 가치에 대한 믿음에 기초한 안내와 제안
2. 바보야 문제는 콘텐츠야
4. Perspective와 Viewpoint는 무엇인가?
5. 하나의 시스템을 보는 다양한 생각을 담는 조감도鳥瞰圖