For Engineering

[LLM] 프롬프트 캐시 깨는 시계 현재시각 도구로 분리

부제: 시스템 프롬프트에 든 현재 시각 하나가 매 요청 캐시를 깨뜨렸다LLM은 프롬프트 앞부분이 같으면 그 부분을 캐시해 비용과 속도를 아낀다(프롬프트 캐싱).그런데 캐시가 먹으려면 그 앞부분이 요청마다 똑같아야 한다.여기서 우리가 스스로 캐시를 깨고 있었다.캐시되는 자리에 변하는 값시스템 프롬프트에 "현재 시각"을 넣고 있었다."지금은 몇 시"를 모델이 알아야 "오늘"·"이번 주" 같은 말에 제대로 답하니까.문제는 시각이 매 요청 바뀐다는 거다.캐시 대상인 시스템 지시가 요청마다 조금씩 달라지니, 캐시가 매번 깨졌다.정작 나머지는 다 똑같은데, 시계 하나 때문에 앞부분 전체가 캐시 미스가 됐다.시각을 프롬프트에서 빼 도구로처음엔 시각을 프롬프트 뒤쪽(사용자 메시지의 컨텍스트 블록)으로 옮기는 걸 검토했..

[에이전트] 내부 도구 MCP 안 쓴 이유 이식성 재사용성

부제: 모든 도구를 MCP로 감싸지 않고, 내부 전용은 그냥 함수로 둔 기준에이전트에 도구를 붙인다.요즘 표준 중 하나가 MCP(Model Context Protocol)다.도구를 프로토콜로 감싸면 여러 클라이언트(예: 데스크톱 앱·에디터)에서 재사용할 수 있다.다 감싸면 표준적일까처음엔 "이왕이면 다 MCP로 감싸면 표준적이고 깔끔하겠지" 싶었다.그런데 그렇게 하지 않았다.MCP가 주는 가치는 두 가지다.하나는 이식성 — 같은 도구를 여러 클라이언트에서 재사용한다.다른 하나는 재사용성 — 남이 만든 도구를 그대로 가져다 쓴다.문제는, 우리 서비스만 쓰는 내부 전용 도구엔 이 두 가치가 아예 안 붙는다는 거다.다른 클라이언트에서 쓸 일도 없고, 남이 가져다 쓸 일도 없다.그런 도구를 MCP로 감싸면, 프..

[메모리] 챗봇 사용자 기억 Identity Episodic 4계층

부제: 사용자에 대해 무엇을 오래 기억하고, 무엇을 그때그때 기록할지 나눈 기준챗봇이 사용자를 기억하게 하려면 "무엇을" 기억할지부터 정해야 한다.다 기억하면 프롬프트가 노이즈로 가득 차고, 안 하면 매 대화가 처음 만난 사이가 된다.다 기억할 순 없다그래서 기억을 두 종류로 갈랐다.인지과학의 오래된 구분(의미 기억과 일화 기억)을 빌렸다.정체성(Identity) 은 "이 사용자는 누구인가"를 규정하는 안정적인 정보다.직업, 알레르기, 만성질환, 진행 중인 목표 같은 것들이다.반복·누적되는 패턴이고, 그 사람을 이해하고 예측하는 데 계속 쓰인다.일화(Episodic) 는 특정 시점에 묶인 1회성 단편이다.오늘 컨디션, 이번 주 일정, 방금 처한 상황."누구인가"가 아니라 "무엇을 경험했나"의 기록이다.무..

[에이전트] 같은 말 반복, 프롬프트 대신 그래프 제어로 끝낸 턴

부제: LLM이 같은 말을 반복하는 걸, 프롬프트가 아니라 제어 흐름으로 끝낸 이야기에이전트에는 사용자에게 버튼·선택지 같은 UI를 그려주는 도구가 있다.LLM이 이 도구를 호출하면 화면에 UI가 뜬다.문제는 이 도구를 호출한 "다음"에 벌어졌다.같은 말을 두 번 하는 에이전트LLM이 UI 도구를 호출할 때, UI만 만드는 게 아니라 답변 텍스트도 같이 생성한다."아래에서 골라주세요" 같은 말과 함께 버튼을 띄우는 식이다. 여기까진 정상이다.그런데 그래프(LangGraph)가 거기서 끝나지 않았다.도구 실행이 끝나면 에이전트에게 턴이 다시 넘어가, 에이전트가 한 번 더 말을 해야 대화가 마무리됐다.문제는 마지막 턴에서 에이전트가 할 말이 없다는 것이다.방금 UI와 함께 할 말을 다 했으니까.그러니 조금 ..

부제: 학술적으로 가장 강력히 추천되던 "중요도 점수"를 왜 기억 시스템에서 뺐나에이전트가 장기기억을 쌓을 때, 어떤 기억을 더 중요하게 다룰지 정해야 한다.무엇을 항상 꺼내 보고, 무엇을 먼저 잊을지의 기준이다.1순위 추천을 받았지만기억 시스템을 설계하며 학술 조사를 크게 한 번 했다.신경과학·인지심리학·AI 에이전트 시스템·철학을 훑어 "기억의 유의미함"을 여러 축으로 정리했다.그중 학술 근거가 가장 강하고 구현 비용도 낮은 1순위가 "importance score"였다.Stanford Generative Agents가 직접 인용되는 정석 방법이다.LLM이 각 기억에 1~10점을 매기고, 그 점수로 주입·검색 우선순위를 정한다.정석이니 넣으면 될 것 같았다.그런데 변별력이 없다문제는 실제로 LLM에게..

부제: 일어나지 않는 경우를 위한 방어 코드를, 어디까지 짜고 어디서 멈출지에이전트가 사용자에게 버튼이나 선택지 같은 UI를 그리게 하는 도구가 있다.정상이면 LLM이 이 도구를 정식으로 호출하고, 서버는 그 입력(버튼이 제대로 붙었는지 등)을 검증한다.그런데 여기에 드문 실패 하나가 끼어들 여지가 있었다.일어날 법한 실패LLM이 가끔 이 UI를 도구 호출이 아니라 답변 본문에 마크업 텍스트로 흘릴 수 있다. 같은 태그를 그냥 글자로 뱉는 것이다.이게 왜 그럴듯하냐면, 시스템 프롬프트가 XML 스타일 태그를 여럿 쓰기 때문이다.LLM은 주변 스타일을 흉내 내는 경향이 있어서, 그 태그 스타일을 따라 UI를 텍스트로 써 버리는 회귀가 충분히 가능하다.이러면 두 가지가 나쁘다.하나, 그 raw 마크업이 사용..

부제: 무해해 보이던 타임존 값 하나가 엉뚱한 지역 날씨를 부른 이야기사용자 정보에 타임존을 저장해 뒀다. Asia/Seoul 같은 값이다.시각을 사용자 현지 시간으로 계산하려고 넣은 것인데, 이 정보를 다른 사용자 정보와 함께 대화 컨텍스트에 넣고 있었다.별생각 없이. 그냥 사용자 정보 중 하나니까.지역을 안 물어봤는데 서울 날씨어느 날 사용자가 지역을 말하지 않고 "날씨 어때?"라고 물었다.그러면 에이전트가 "어느 지역이요?"라고 되물어야 자연스럽다.그런데 에이전트가 곧바로 서울 날씨를 조회했다.컨텍스트에 있는 타임존 Asia/Seoul을 보고, "이 사용자는 서울에 산다"고 넘겨짚은 것이다.타임존은 시각 계산용으로 넣은 값이지 "거주지"가 아니다.타임존과 사는 곳이 대개 겹치긴 하지만 항상은 아니다..

부제: 전문 지식을 매 턴 프롬프트에 넣지 않고 필요할 때만 펼치기챗봇에 도메인 전문 지식을 넣고 싶었다.러닝 코칭 규칙, 영양 상담 지식 같은 것들이다.가장 단순한 방법은 시스템 프롬프트에 그걸 다 박는 거다.그런데 이 단순함이 비쌌다.다 넣으면 매 턴 낭비시스템 프롬프트는 대화의 매 턴마다 함께 실린다.전문 지식을 거기 박으면, 그 지식 전체가 턴마다 로딩된다."오늘 날씨 어때" 같은 일반 대화에도 러닝 페이스 계산표와 훈련 주기화 규칙이 매번 딸려 온다.쓰지도 않을 지식을 위해 턴마다 수백에서 수천 토큰을 버리는 셈이다.토큰은 돈이고, 컨텍스트 창은 유한하다.필요할 때만 단계적으로 펼친다그래서 지식을 "스킬"로 묶고, 필요할 때만 로드하게 했다.세 단계로 점진적으로 펼치는 방식(progressive..

부제: 프롬프트를 코드에서 빼되, 코드에도 남긴 이유LLM 프롬프트를 어디서 관리하느냐는 은근히 큰 문제다.처음엔 당연하게 코드(파이썬 파일)에 문자열로 박아 뒀다.코드에 박으면 배포에 묶인다프롬프트는 자주, 빠르게 고치고 싶은 물건이다.문구 한 줄만 바꿔도 답의 품질이 달라지니, 여러 번 손보게 된다.그런데 코드에 있으면 그때마다 코드를 고치고 배포해야 한다.프롬프트 한 단어 바꾸자고 배포 사이클을 한 바퀴 도는 셈이다. 느리다.버전을 비교하거나 되돌리기도 번거롭다.중앙 관리로 옮기되, 코드도 남긴다그래서 프롬프트를 관측·프롬프트 관리 도구(Langfuse)로 옮겨 중앙에서 관리하기로 했다.웹 UI에서 고치고 라벨로 배포하면, 앱이 알아서 최신 프롬프트를 가져다 쓴다.배포 없이 프롬프트만 바꿀 수 있다..

부제: 키워드 검색과 벡터 검색을 점수 대신 순위로 합친 이유한국어 문서 검색에 두 방식을 같이 썼다.하나는 키워드 검색이다. 형태소로 자른 단어가 문서에 있는지를 본다.다른 하나는 의미 검색이다. 문장을 벡터로 바꿔 뜻이 비슷한 문서를 찾는다.각각 장단이 있어 둘 다 쓰기로 했다. 각 방식에서 상위 50개씩 뽑는다.그다음이 문제였다.두 결과를 어떻게 합치나처음 떠오른 건 점수를 더하는 거였다.키워드 점수와 벡터 점수를 합쳐서 다시 정렬하면 되지 않을까.안 됐다.두 점수는 스케일이 다르다.벡터 유사도는 0에서 1 사이로 얌전한데, 키워드 점수(BM25)는 위로 열려 있고문서·쿼리마다 분포가 제각각이다.그냥 더하면 한쪽이 다른 쪽을 압도해 버린다. 합치는 의미가 없어진다.가중치 튜닝은 답이 아니었다그럼 가..