조용한 개발 노트

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

4편에서 Claude의 프롬프트는 명령이 아니라 역할 정의에 가깝다고 정리했다.그렇다면 자연스럽게 이런 질문이 따라온다.“외부 도구는 어디까지 맡길 수 있는가?”이 질문에 대한 Claude의 답은 Tool Use 설계에서 드러난다.1. Claude의 Tool Use는 실행이 아니라 요청이다많은 사람이 Tool Use를 이렇게 이해한다.“모델이 도구를 실행한다”하지만 Claude의 구조는 조금 다르다.Claude는 도구를 실행하지 않는다.도구를 호출하겠다는 의도를 표현할 뿐이다.모델은 “이 도구를 이런 인자로 호출하라”고 제안한다실제 실행은 시스템이 담당한다결과를 다시 모델에게 전달한다이 분리는 사소해 보이지만, 설계상 매우 중요한 차이다.2. Claude는 왜 직접 실행하지 않도록 설계되었는가Claude..

Claude를 쓰다 보면 이런 느낌을 받는다.강하게 지시할수록 결과가 오히려 흔들린다명령문을 늘리면 방어적인 답이 늘어난다“반드시 이렇게 해라”가 잘 통하지 않는다이 현상을 “프롬프트가 까다롭다”로 해석하면 곧 한계에 부딪힌다. 문제는 프롬프트 기술이 아니라 설계 전제의 불일치다.1. Claude는 명령을 실행하는 주체가 아니다Claude는 처음부터 “명령을 정확히 수행하는 엔진”으로 설계되지 않았다.Claude의 전제는 이거다.모델은 언제나 틀릴 수 있으므로, 강한 명령을 그대로 실행하게 두면 위험하다.그래서 Claude는 명령을 규칙으로 받아들이지 않는다. 명령은 어디까지나 의도 신호다.2. 강한 지시는 Claude에게 경고 신호다Claude에게 이런 문장은 종종 역효과를 낸다.“반드시 정확한 정보만..

Claude를 실제로 써보면 곧 이런 질문이 생긴다.“가장 성능 좋은 모델 하나만 쓰면 되는 거 아닌가?”Claude의 모델 구성(Opus, Sonnet, Haiku)은 이 질문에 대한 명확한 반박이다.Claude는 처음부터 “최고 성능 모델 하나로 모든 문제를 해결한다”는 접근을 하지 않는다.1. Claude 모델 구분의 출발점은 성능이 아니다많은 LLM은 모델 라인업을 이렇게 설명한다.이건 빠른 모델이건 똑똑한 모델이건 비싼 모델Claude의 모델 구분은 조금 다르다.핵심 질문은 이거다.“이 요청은 어디까지 틀려도 되는가?”Claude의 모델 라인업은 이 질문에 대한 서로 다른 답이다.2. Opus - 깊이 있는 판단을 맡길 수 있는 상한선Opus는 Claude 라인업의 상한선이다.하지만 Opus는 ..

1편에서 Claude를 “조심스러운 모델”이 아니라 처음부터 선을 긋고 설계된 LLM이라고 정리했다.이제 그 주장이 맞는지 확인해볼 차례다. 말이 아니라 API 구조를 보면 된다.API는 의도를 숨기지 않는다. 어떤 전제를 깔고 있는지는 코드 형태로 그대로 드러난다.1. Claude API는 왜 단순 completion API가 아닌가Claude API를 처음 보면 “completion 하나 던지고 문자열 받는 구조”가 아니다.대신 중심에는 항상 messages가 있다.이 선택 하나만으로도 Claude의 관점은 분명해진다.출력은 단일 결과가 아니다대화 맥락 전체가 판단 대상이다프롬프트는 명령이 아니라 상태다Claude는 처음부터 “한 번의 요청으로 정답을 뽑아내는 모델”을 상정하지 않는다.2. syste..

7편까지 오면 한 가지 사실이 분명해진다.LLM 시스템은 “모델 하나 붙이면 끝”이 아니다. 검색, 컨텍스트 구성, 검증, 가드레일이 겹겹이 쌓인다.그리고 이 순간부터 현실적인 질문이 튀어나온다.“이걸 감당할 수 있는가?”1. LLM 비용은 모델 호출에서 끝나지 않는다비용을 이야기하면 보통 이렇게 계산한다.“요청 1회당 토큰 비용 × 호출 수”운영에 들어가면 이 계산은 즉시 깨진다.검색 쿼리 비용컨텍스트 확장으로 늘어난 입력 토큰재시도, 폴백, 검증용 추가 호출실제 비용은 대부분 “LLM 주변부”에서 발생한다.그래서 비용 최적화의 첫 질문은 이거다.“정말 매번 LLM을 불러야 하는가?”2. 지연(latency)은 구조에서 결정된다응답이 느릴 때 흔히 드는 생각은 이거다.“모델이 느리다”하지만 대부분의 지..

6편까지의 결론은 명확하다.LLM은 언제든 틀릴 수 있고, RAG를 붙여도 그 가능성은 사라지지 않는다.이 지점에서 다음 질문이 나온다.“그럼 이걸 어떻게 운영에 넣을 수 있는가?”1. LLM 출력은 항상 실패할 수 있다는 전제부터 깔아야 한다LLM 기반 시스템에서 가장 위험한 가정은 이거다.“대부분은 맞을 것이다”운영 관점에서는 이 문장이 이렇게 번역된다.“언젠가는 반드시 사고가 난다”그래서 LLM 출력은 처음부터 이렇게 다뤄야 한다.항상 틀릴 수 있다틀렸을 때 감지할 수 있어야 한다감지했을 때 피해가 제한돼야 한다이게 가드레일의 출발점이다.2. 출력 검증은 “맞는지 확인”이 아니라 “위험한지 감지”다많은 팀이 출력 검증을 이렇게 접근한다.“정답인지 확인하자”대부분 실패한다. 정답 여부를 자동으로 판단..

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

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

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