긴 AI 대화가 산으로 갈 때: 문맥을 ‘수정 가능한 지도’로 다루는 법

핵심 요약 (TL;DR)

AI와 오래 일하다 보면 대화가 길어질수록 답이 흐려지는 순간이 옵니다. 처음 정한 목표, 이미 기각한 아이디어, 꼭 지켜야 할 제약이 잡담과 수정 요청 사이에 묻히기 때문입니다. 최근 공개된 오픈소스 ThoughtDAG는 이 문제를 ‘대화창을 더 길게 보관하는 일’이 아니라, 다음 답변에 들어갈 문맥을 사람이 연결선으로 고르는 일로 풀어 보려 합니다. 도구를 당장 쓰지 않더라도 이 관점은 바이브코딩에 바로 적용할 수 있습니다.

대화 기록이 많으면 왜 더 좋은 답이 나오지 않을까요?

기록이 많다는 것은 중요한 정보가 많다는 뜻이 아닙니다. 이전의 임시 가설, 폐기한 디자인, 해결된 오류까지 한꺼번에 들어가면 모델은 무엇이 현재 기준인지 구분하기 어려워집니다. 그 결과 이미 하지 않기로 한 기능을 다시 제안하거나, 예전 코드 구조를 전제로 답하기도 합니다.

ThoughtDAG의 공개 설명에서 핵심은 ‘연결선이 곧 문맥’이라는 생각입니다. 어떤 노드가 다음 질문에 연결되는지가 모델이 볼 재료를 결정합니다. 즉, 모든 기억을 밀어 넣는 대신 지금 필요한 결정·근거·제약만 묶어 전달하려는 방식입니다. 제품의 모든 주장이나 효과를 일반화할 수는 없지만, 문맥을 편집 대상으로 본다는 점은 분명한 힌트입니다.

코딩 에이전트와 일할 때는 어떻게 적용할까요?

프로젝트 루트에 짧은 작업 메모 하나를 두세요. 거기에는 서비스 목표, 이번 작업의 범위, 바꾸면 안 되는 규칙, 확인 방법만 남깁니다. 예를 들어 ‘예약 폼의 모바일 오류 문구를 고친다’, ‘DB 구조와 결제 코드는 건드리지 않는다’, ‘빈 입력과 잘못된 이메일에서 안내가 보이는지 확인한다’ 정도입니다.

새 세션을 시작할 때는 이 메모와 관련 파일만 먼저 읽게 합니다. 이전 대화 전체를 복사하는 것보다 훨씬 낫습니다. 작업 중 결정이 바뀌면 메모를 즉시 고치고, 폐기한 방향은 삭제하거나 ‘하지 않음’으로 분명히 표시하세요. AI가 기억을 잃지 않게 하려는 것이 아니라, 사람이 현재의 정답을 관리하는 방식입니다.

무엇을 남기고 무엇을 버려야 할까요?

남길 것은 다음 행동을 바꾸는 정보입니다. 사용자 대상, 성공 기준, 보안·비용 제약, 현재 결정, 검증 결과가 여기에 해당합니다. 반대로 일회성 오류 메시지, 이미 해결된 시행착오, 감상 수준의 피드백은 짧게 요약하거나 지워도 됩니다.

이 원칙은 긴 문서를 만드는 일이 아닙니다. 매 작업마다 다섯 줄을 최신 상태로 유지하는 일에 가깝습니다. 문맥을 잘 정리한 사람은 더 긴 프롬프트를 가진 사람이 아니라, AI가 보아야 할 현재의 사실을 구분한 사람입니다.

FAQ: 이전 대화를 전부 붙여 넣으면 안 되나요?

필요한 사실이 선명하다면 일부만 요약하는 편이 좋습니다. 전체 기록은 오래된 결정과 현재 결정을 섞을 수 있습니다.

FAQ: 문맥 메모는 누가 갱신해야 하나요?

AI에게 초안을 맡길 수 있지만, 현재 목표와 우선순위는 사람이 확인해 갱신하는 것이 안전합니다.

출처: https://chenxiachan.github.io/thoughtdag/
소스 코드: https://github.com/chenxiachan/thoughtdag
커뮤니티 관찰: https://news.ycombinator.com/item?id=49307700
관찰 시점: 2026-08-16 KST