대형 언어 모델(LLM)과의 대화가 길어질수록 실무자들이 부딪히는 문제는 비슷하다. 앞선 대화가 계속 쌓이면서 정작 지금 필요한 답과 무관한 내용까지 모델의 입력으로 흘러 들어가고, 그 결과 답변의 품질이 미묘하게 어긋난다. 대부분의 채팅형 인터페이스는 이 '무엇이 모델에게 전달되는가'를 사용자에게 숨긴다. 최근 Show HN에 공개된 ThoughtDAG는 바로 이 지점을 정면으로 겨냥한 오픈소스 도구다. 대화를 선형적인 스크롤이 아니라 편집 가능한 방향성 그래프(DAG)로 다루면서, 그래프의 구조 자체가 모델이 보게 될 컨텍스트를 결정하도록 설계했다.
대화를 선이 아니라 그래프로
ThoughtDAG의 핵심 발상은 대화의 흐름을 노드와 엣지로 이뤄진 캔버스 위에 펼쳐 놓는 것이다. 일반적인 챗봇에서는 하나의 질문에 대해 다른 해석을 시도하려면 기존 대화를 덮어쓰거나 새 세션을 열어야 한다. 반면 이 도구에서는 지금까지 도달한 경로를 그대로 둔 채 또 다른 해석을 분기해 탐색할 수 있다. 본론에서 잠시 벗어난 곁가지 논의도 캔버스 위에 남겨 두되, 다음 요청에는 포함되지 않도록 분리할 수 있다. 즉 '기록으로 보존하는 것'과 '이번 입력에 넣는 것'을 별개로 다룬다는 점이 구조적 차별점이다.
반대 방향의 조작도 가능하다. 서로 다른 갈래에서 얻은 근거와 추론 경로를 선택적으로 다시 하나로 모아 한 번의 답변으로 통합할 수 있다. 대화가 트리처럼 갈라지기만 하는 것이 아니라, 필요한 조각들을 골라 합류시키는 방향까지 지원하기 때문에 자료 조사나 여러 가설을 병렬로 검토하는 작업에 어울린다.
'숨은 메모리' 없이 컨텍스트를 미리 본다
실무자 관점에서 가장 의미 있는 특징은 투명성이다. 많은 LLM 제품이 이전 대화 중 어떤 부분을 자동으로 골라 컨텍스트에 넣을지를 내부적으로 판단하는 '메모리 선택' 로직을 갖고 있지만, 사용자는 그 선택 과정을 볼 수 없다. ThoughtDAG는 이런 숨은 메모리 선택기를 두지 않는다고 강조한다. 생성 버튼을 누르기 전에 모델이 실제로 받게 될 내용을 미리 확인할 수 있고, 무엇이 들어가고 무엇이 제외됐는지가 그래프 위에 그대로 드러난다.
공개된 설명에는 이 효과를 보여 주는 구체적 사례가 담겨 있다. 프롬프트 문구는 한 글자도 바꾸지 않고 그래프에서 엣지 하나만 제거했더니 결과가 달라졌다는 것이다. 예컨대 본래 질문과 무관한 저녁 식사 제안 같은 잡음이 컨텍스트에서 사라지자 답변이 바뀌었고, 특정 엣지를 지웠을 때 입력 토큰이 47개 줄어든 사례도 제시됐다. 단어는 동일한데 오직 연결 하나가 달라졌다는 이 대비는, 답변 품질이 프롬프트 표현만이 아니라 '무엇을 함께 넣느냐'에 좌우된다는 사실을 시각적으로 보여 준다.
실무에서의 의미와 한계
이런 방식은 프롬프트 엔지니어링이나 리서치 요약 작업에서 실질적인 이점을 가진다. 오염된 컨텍스트가 답을 어떻게 흔드는지를 눈으로 확인하고, 어떤 조각을 빼야 원하는 결과가 나오는지를 통제할 수 있기 때문이다. 토큰 사용량 역시 그래프 편집만으로 가시적으로 줄일 수 있어, 비용과 컨텍스트 길이를 신경 쓰는 팀에게는 매력적인 접근이다. 또한 로컬 우선(local-first)에 오픈소스로 공개돼, 데이터를 외부로 보내지 않고 자체 환경에서 실험하려는 개발자에게 진입 장벽이 낮다.
다만 공개된 자료만으로는 판단을 유보해야 할 부분도 분명하다. 어떤 모델과 연결되는지, 대규모 대화에서 그래프가 얼마나 다루기 편한지, 팀 단위 협업이나 버전 관리와는 어떻게 맞물리는지 같은 운영 측면은 설명에 드러나 있지 않다. 그래프를 손수 편집한다는 것은 곧 컨텍스트 구성을 사람이 직접 책임진다는 뜻이기도 해서, 자동화가 주는 편의를 일부 포기하는 대가가 따른다. 대화가 복잡해질수록 노드와 엣지를 관리하는 부담이 늘어날 가능성도 있다.
그럼에도 ThoughtDAG가 던지는 질문은 곱씹을 만하다. 지금까지 쌓인 대화 기록 가운데 어떤 부분이 다음 요청에 들어가야 하는가. 이 결정을 모델의 불투명한 내부 로직에 맡길 것인가, 아니면 사용자가 직접 보고 통제할 것인가. LLM을 도구로 진지하게 다루는 실무자라면, 컨텍스트를 편집 가능한 대상으로 끌어올린 이 시도가 자신의 워크플로에 어떤 통제권을 돌려줄 수 있는지 한 번쯤 실험해 볼 가치가 있다.