조용한 개발 노트

Claude를 설명할 때 자주 등장하는 표현이 있다.“Claude는 긴 컨텍스트에 강하다”이 말은 사실이다. 하지만 이 문장을 그대로 믿으면 곧 설계에서 실수하게 된다.중요한 질문은 이거다.“길게 넣으면 정말 더 잘 이해하는가?”1. 긴 컨텍스트는 능력이 아니라 한계의 확장이다Claude는 다른 많은 LLM보다 긴 입력을 처리할 수 있다.하지만 이 능력은모든 정보를 완벽히 기억한다는 뜻도 아니고문서를 구조적으로 이해한다는 뜻도 아니다긴 컨텍스트는 모델이 고려할 수 있는 토큰의 범위가 넓다는 의미일 뿐이다.고려 가능성과 이해는 다르다.2. Claude가 긴 입력에 상대적으로 안정적인 이유Claude는 보수적인 설계 철학을 갖고 있다.확신이 약하면 단정을 피하고충돌하는 정보가 있으면 조심스럽게 표현하며불명확..

1편부터 8편까지의 이야기를 한 문장으로 줄이면 이렇다.LLM은 똑똑한 존재가 아니라, 잘 설계된 시스템 안에서만 쓸 수 있는 컴포넌트다.이 마지막 편에서는 지금까지 쌓아온 모든 논의를 “그래서 실무에서는 어떻게 배치해야 하는가”라는 질문으로 수렴시킨다.1. LLM이 맡아도 되는 역할LLM이 가장 잘하는 일은 명확하다.주어진 정보 안에서 텍스트를 재구성한다여러 후보를 빠르게 생성한다사람이 읽기 좋은 형태로 정리한다이 역할에는 공통점이 있다.틀려도 즉시 치명적이지 않다그래서 LLM은 이런 위치에 잘 어울린다.초안 생성기요약기후보 추천기인터페이스용 자연어 변환기이 영역에서는 완벽함보다 속도와 생산성이 중요하다.2. LLM에게 맡기면 안 되는 역할반대로, LLM이 절대 맡아서는 안 되는 역할도 명확하다.사실의..

5편에서 RAG가 필연이라는 이야기를 했다. 하지만 많은 팀이 같은 말을 덧붙인다.“RAG를 붙였는데도 여전히 답이 이상하다”이때 가장 흔한 오해는 이거다.“검색 품질이 안 좋다”물론 검색도 중요하다. 하지만 실제로는 검색보다 더 자주 문제를 만드는 지점이 있다.검색 결과를 어떻게 컨텍스트로 구성했는가다.1. RAG의 실패는 대부분 ‘전달 실패’다RAG 파이프라인을 단순화하면 이렇게 보인다.질문을 벡터로 변환한다관련 문서를 검색한다검색 결과를 컨텍스트로 넣는다LLM이 답을 생성한다문제는 이 중 3번이다.검색 결과를 “넣는다”는 표현이 마치 아무 문서나 던져주면 되는 것처럼 느끼게 만든다.하지만 LLM 입장에서 컨텍스트는 동등한 토큰들의 나열일 뿐이다.2. LLM은 “중요한 문서”를 알지 못한다사람은 검색..

프롬프트를 인터페이스로 보기 시작하면, LLM이 절대 책임질 수 없는 영역이 명확해진다.그중 가장 치명적인 게 사실성이다.이 지점에서 대부분의 시스템은 같은 결론에 도달한다.“모델에게 기억을 맡기면 안 된다”1. LLM은 왜 사실을 틀릴 수밖에 없는가LLM이 사실을 틀리는 이유는 단순하다.사실 여부를 판단하는 단계가 없다모델의 목표는 “맞는 답”이 아니라 “그럴듯한 다음 토큰”이다여기서 중요한 건, 이 문제가 데이터를 더 학습시키면 해결될 성질이 아니라는 점이다.학습 데이터가 아무리 많아져도, 모델은 여전히 “검증”이 아니라 “생성”을 한다.2. 그래서 LLM에 지식을 넣으려는 시도는 항상 실패한다처음 LLM을 붙이면 이런 시도를 한다.프롬프트에 배경 설명을 길게 넣는다도메인 규칙을 텍스트로 주입한다“아..

3편까지의 내용을 받아들이면, 프롬프트에 대한 기대부터 바뀌어야 한다.프롬프트는 모델에게 “잘 설명하면 알아서 이해하는 글”이 아니다. 확률 분포를 유도하기 위한 입력 인터페이스다.이 관점을 놓치면, 프롬프트를 계속 고치는데도 시스템은 안정되지 않는다.1. 왜 프롬프트는 항상 기대를 배신하는가프롬프트를 작성하다 보면 이런 경험을 한다.어제까지 잘 되던 프롬프트가 오늘은 흔들린다설명을 더 붙였는데 오히려 결과가 나빠진다사소한 표현 변경으로 출력 성격이 바뀐다이건 프롬프트를 잘못 써서가 아니다. 프롬프트에 지나친 책임을 맡기고 있기 때문이다.2. 자연어는 계약이 될 수 없다사람끼리는 자연어로도 계약을 맺을 수 있다. 맥락, 상식, 책임이 공유되기 때문이다.하지만 LLM과는 그렇지 않다.자연어 프롬프트에는 다..

LLM을 실제로 써본 사람이라면 비슷한 경험이 있을 것이다. 어떤 날은 결과가 너무 잘 나와서 “이제 이 정도는 자동화해도 되겠다” 싶다가도, 조금만 조건이 바뀌면 갑자기 말이 안 되는 답을 내놓는다.이 글은 LLM을 처음 소개하는 글이 아니다. 이미 API를 붙여봤고, 프롬프트도 여러 번 고쳐봤지만 여전히 어디까지 믿어도 되는지 판단 기준이 없는 상태인 사람을 위한 글이다.1. LLM을 둘러싼 가장 흔한 오해LLM을 쓰다 보면 자연스럽게 이런 식으로 생각하게 된다.“이 정도면 문맥을 이해한 것 같은데?”“설명까지 그럴듯하니 내부적으로 추론을 하고 있겠지”“조금만 더 프롬프트를 잘 쓰면 정확해질 거야”이 오해는 위험하다. 왜냐하면 이 전제를 깔고 가는 순간, 모델 출력의 실패를 설계 문제가 아니라 운이 ..