조용한 개발 노트

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..

Claude를 처음 접하면 흔히 이런 인상을 받는다.답변이 조심스럽다확신 없는 표현을 자주 쓴다“모르겠다”고 말하는 빈도가 높다이 특징 때문에 Claude는 종종 이렇게 평가된다.“보수적이다”“덜 똑똑한 것 같다”하지만 이 평가는 대부분 잘못된 기대에서 나온다. Claude는 성능이 낮아서 조심스러운 게 아니라, 처음부터 다른 전제를 깔고 설계된 모델이기 때문이다.1. Claude를 이해하려면 먼저 질문을 바꿔야 한다Claude를 볼 때 많은 사람이 이런 질문을 던진다.ChatGPT보다 정확한가?코드를 더 잘 짜는가?프롬프트를 어떻게 써야 하는가?하지만 Claude를 이해하려면 질문을 이렇게 바꿔야 한다.“Claude는 무엇을 하지 않도록 설계되었는가?”이 질문이 Claude의 모든 특징을 설명해준다.2..

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

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은 “중요한 문서”를 알지 못한다사람은 검색..