AI 엔지니어링 트렌드

이 편의 결론

• ·프롬프트를 다듬어도 답변이 안 좋아진다면, 문제는 문장이 아니라 컨텍스트 구성일 가능성이 큽니다.
• ·컨텍스트 윈도는 용량이 아니라 예산입니다. 시스템 프롬프트·도구 정의·대화 히스토리·검색 결과가 같은 지갑을 씁니다.

이 편의 결론

• ·모델을 바꿔서 해결되는 문제보다, 하네스를 고쳐서 해결되는 문제가 훨씬 많았습니다.
• ·도구는 많을수록 좋지 않습니다. 개수가 늘면 오선택이 같이 늘어납니다.

이 편의 결론

• ·도구를 직접 붙이면 연동 비용이 에이전트 수 × 시스템 수로 늘어납니다. MCP는 이걸 합으로 바꾸려는 시도입니다.
• ·이득은 "한 번 만들면 여러 곳에서 쓴다"가 아니라 "같은 규약을 쓰니 갈아끼울 수 있다" 쪽이 큽니다.

이 편의 결론

• ·벤치마크 점수는 우리 코드베이스에서의 성능을 예측하지 못했습니다. 갈리는 건 모델이 아니라 루프였습니다.
• ·판단 축은 셋입니다 — 탐색 범위 · 실행 루프 · 운영 적합성.

이 편의 결론

• ·LLM 기능에 테스트를 안 붙이면, 프롬프트 한 줄 고칠 때마다 무엇이 깨졌는지 모릅니다.
• ·정확 일치는 쓸 수 없습니다. 출력이 만족해야 할 성질을 검사합니다.

이 편의 결론

• ·구조화 출력에는 강제 수준이 네 단계 있고, 단계마다 보장하는 게 다릅니다.
• ·가장 흔한 오해: "스키마를 줬으니 타입이 맞을 것" → 형식은 맞아도 값이 틀립니다.

이 편의 결론

• ·프롬프트 캐싱은 접두사(prefix) 단위로 걸립니다. 앞에서 한 글자만 달라져도 뒤 전체가 캐시를 못 씁니다.
• ·그래서 고정된 것을 앞에, 변하는 것을 뒤에 두는 배치만으로 비용이 크게 달라집니다.

이 편의 결론

• ·문서가 적고 자주 안 바뀌면 RAG보다 롱컨텍스트가 정확하고 단순합니다. 청킹 손실이 없기 때문입니다.
• ·RAG가 자주 실패하는 지점은 검색이 아니라 청킹입니다. 답이 두 청크에 걸쳐 있으면 못 찾습니다.

이 편의 결론

• ·에이전트 장애는 재현이 안 되는 게 본질입니다. 그 순간의 입력을 남기지 않으면 영영 모릅니다.
• ·스팬은 요청 → 모델 호출 → 도구 호출 → 판정 네 층으로 나눕니다. 한 덩어리로 두면 어디서 샜는지 안 보입니다.

이 편의 결론

• ·분류·추출·정규화는 소형 모델로 충분했습니다. 여기에 최고 모델을 쓰는 건 낭비입니다.
• ·소형 모델의 이득은 비용만이 아닙니다. 지연이 줄어드는 게 체감상 더 컸습니다.

이 편의 결론

• ·자동 리뷰의 실패는 못 찾아서가 아니라 너무 많이 찾아서였습니다. 오탐이 섞이면 전부 무시됩니다.
• ·해법은 더 좋은 모델이 아니라 찾은 뒤 걸러내는 단계를 붙이는 것이었습니다.

이 편의 결론

• ·11편을 쓰는 동안 "모델을 바꾸기 전에 주변 구조를 먼저 본다"는 말을 계속 반복하고 있었습니다.
• ·실제로 효과가 컸던 조치는 대부분 모델과 무관한 것이었습니다 — 순서 바꾸기, 개수 줄이기, 검증 단계 붙이기.