LLM은 똑똑한데, 왜 우리 회사 일은 모를까

요즘 LLM은 공개된 지식에 관한 질문에는 꽤 능숙하게 답해요. 코드를 작성하고, 긴 문서를 요약하고, 복잡한 요청을 여러 단계로 나눠 처리하기도 하죠. 하지만 회사 안으로 들어오면 이야기가 달라져요.“이 기능의 현재 정책은 무엇인가요?” “문서에 적힌 내용이 실제 코드에도 반영되어 있나요?” “지난번 논의에서 결론이 바뀌지 않았나요?”이런 질문에는 모델의 추론 능력만으로 답할 수 없어요. 답을 만드는 데 필요한 정보가 문서, 코드, 미팅 로그와 사내 메신저 등에 흩어져 있고, 각 정보가 여전히 유효한지 알기도 어렵기 때문이에요.처음에는 이 문제를 검색의 문제로 생각했어요. LLM이 필요한 사내 정보를 더 잘 찾게 만들면 된다고 봤죠. 하지만 검색 결과가 좋아져도 중요한 문제가 남았어요. 찾은 문서가 최신인지, 사내 메신저에서의 논의가 최종 결정인지, 문서의 설명과 실제 코드가 일치하는지는 검색만으로 판단하기 어려웠어요.결국 문제를 다시 정의했어요.LLM이 사내 정보를 잘 찾게 하는 것이 아니라, LLM과 사람이 함께 사용할 수 있는 신뢰 가능한 컨텍스트를 관리해야 한다.이 문제를 해결하기 위해 만들고 있는 시스템이 Topic이에요. 이 글에서는 문서 · 코드 · 사내 메신저의 원본 데이터를 Topic이 어떤 단위로 추출하고, 어떻게 서로 연결하며, 신뢰할 수 있는 상태로 관리하는지 소개할게요.검색만으로는 신뢰를 만들 수 없었어요사내 검색 시스템은 일반적으로 질문과 가까운 텍스트 조각을 찾아줘요. 이 조각은 답변을 만드는 재료로는 유용하지만, 그 자체로 신뢰할 수 있는 컨텍스트는 아니에요.예를 들어 주문 타임아웃의 재시도 정책을 묻는다고 해볼게요.세 정보는 모두 질문과 관련이 있어요. 따라서 일반적인 검색 결과에는 모두 나타날 수 있죠. 하지만 LLM이 답하려면 검색 이후에 더 많은 판단을 해야 해요.각 에이전트가 원본 데이터를 직접 검색하면 이런 판단도 에이전트마다 반복돼요. 같은 질문에도 에이전트가 어떤 자료를 찾았는지, 충돌을 어떻게 해석했는지에 따라 답이 달라질 수 있고요.Topic은 이 반복되는 작업을 정보의 출처와 소비자 사이의 공통 계층으로 옮겨요. 원문을 수집하는 데서 끝나지 않고, 컨텍스트의 출처와 관계, 최신성, 충돌 상태까지 함께 관리해요. LLM 클라이언트와 토스 팀원은 Topic을 통해 같은 근거와 같은 검증 상태를 공유할 수 있어요.신뢰의 여섯 가지 축처음에는 컨텍스트마다 하나의 신뢰도...