내가 정의한 휴리스틱이란 텍스트나 이미지 자체만으로는 의미(Semantic)가 잘 드러나지 않거나 맥락을 추론하기 어려운 것들을 의미한다. DDD의 언어를 빌려 오자면 ‘비즈니스 규칙’같은 것들이 상당부 휴리스틱이다. 일반상식을 가진 LLM이 쉽게 추론해내기 어려운 것을 의미한다.

예를 들어, 당신이 합주와 공연을 돕는 서비스를 운영하는 사람이라고 할 때, “합주팀은 멤버들을 포함한다.” 같은 내용은 당신과 함께 서비스를 구축한 사람이 아니더라도 쉽게 추론해낼 수 있다. 하지만 비즈니스와 연관이 없는 모든 사람들은 물론 LLM이 아래와 같은 비즈니스 규칙을 추가적인 설명 없이 추론해내는 것은 불가능에 가깝다.

“서비스에서 합주팀을 구성하는 멤버는 내부적으로 '임시 멤버'와 '고정 멤버'로 구분된다. 일반적으로 도메인에서 '팀 멤버'라고 하면 '임시 멤버'(이번 공연에만 특수히 참여하는 용병같은 멤버도 여기 포함됨) + '고정 멤버' 모두를 의미한다. 즉, '공연'이란 개념과 밀접히 연관되어 있다. 이런 팀이 만들어지는 방식은 총 두 가지이다. 첫 번째는 '선곡 기반의 암시적 팀 빌딩'이다. 선곡 시트에서 자신이 하고 싶은 곡 단위로 뭉쳤는데, 그 곡이 운영진 등에 의해 연주하기로 결정('선곡 확정')된 경우 '가상 팀'이 만들어진다. 이렇게 뭉친 사람들은 기본적으로 '임시 멤버' 자격을 가진다. 이 '임시 멤버'들로 구성된 사람들은 실제 공연일에 연주가 이루어진 이후 '고정 멤버'가 되면서 '정식 팀'이 된다. 두 번째는 '명시적 팀 빌딩': 팀 모집 공고를 올려서 팀이 만들어졌거나, 운영진이 팀으로 강제로 묶어 주는 방식으로 만들어진 팀이다.”

LLM은 일반적인 맥락과 의미를 이해하고 판단할 수 있는 역량을 가지고 있어 의미적(Semantic) 맥락에 기반한 판단을 내리는 시스템을 만들 수 있다. 여기에 데이터 그 자체만으로도 상식적으로 드러나는 의미(마치 “당연히” 합주팀은 멤버들을 포함하겠지)가 아님에도 데이터 사이의 관계에 의미를 담아 유연하게 연결지어줄 수만 있다면 LLM이 우리의 비즈니스를 정확히 이해하고 우리의 비즈니스에 맞게 데이터를 자유자재로 다룰 수 있을 것이다. 그럼 어떻게 휴리스틱이라고 불리던 데이터 사이의 관계에 의미를 붙여 저장할 것인가? 최근 그래프 DB의 hype은 이런 상황에 스키마 제약이 적고, 관계를 맺고 끊는 것이 쉬우며, 관계를 정의하기 쉬운 그래프 DB를 활용하면 좋겠다는 아이디어에서 왔다. 실제로 그래프 DB라는 도구와 LLM과의 시너지가 상당히 좋을 것이라는 기대를 만들고 있어, 온톨로지라는 키워드에서 단골처럼 묶여 튀어나오고 있다.


parse me : 언젠가 이 메모에 쓰이면 좋을 것 같은 재료들입니다.

  1. 3_3_8.1.1. title: 클린 아키텍처는 소프트웨어가 풀고자 하는 문제를 기술 스택의 변화로부터 보호하기 위해 고안된 계층(layered) 아키텍처이다. 이 아키텍처는 도메인 주도 설계(DDD)라는 또다른 개념과 호환성이 좋다.
  2. a0. [entry] title: 제텔카스텐을 하면서 드는 의문들

from : 이 메모에 쓰인 생각을 만든 과거의 생각들과 연관관계를 설명합니다.

  1. 너무 휴리스틱을 미워하지는 말자
  2. Agent Engineering

supplementary : 이 메모에 작성된 생각을 뒷받침하는 새로운 메모입니다.

  1. None

opposite : 이 메모에 작성된 생각과 대조되는 새로운 메모입니다.

  1. None