정확도와 비용과 지연 사이 — 모델·프롬프트·컨텍스트 설계

2.1 모델 선택 — 정확도·비용·지연의 균형점

Claude 모델은 성능·속도·단가가 다른 여러 계층으로 나뉩니다 — 흔히 최고 성능(Opus 계열), 균형(Sonnet 계열), 경량·저지연(Haiku 계열)입니다. 아키텍트의 일은 '가장 똑똑한 모델'을 고르는 것이 아니라 요건을 만족하는 최소 비용의 모델을 고르는 것입니다. 판단 축은 정확도, 지연시간(latency, 요청에서 응답까지 걸리는 시간), 처리량(throughput, 단위 시간당 처리 건수), 그리고 단가입니다. 하나의 흐름 안에서도 단계마다 다른 모델을 배정하는 설계가 흔합니다.

2.2 시스템 프롬프트와 가드레일 — 제품의 규칙을 고정하다

시스템 프롬프트(system prompt, 모델의 역할·규칙·말투를 고정하는 최상위 지시문)는 제품의 성격을 규정합니다. 요청마다 지시를 새로 쓰는 대신, 변하지 않는 규칙은 시스템 프롬프트에 두고 매번 달라지는 값만 템플릿의 빈칸으로 분리하는 것이 설계 기본입니다. 가드레일(guardrail, 모델이 넘지 말아야 할 경계)은 두 층위로 둡니다 — 프롬프트 안의 규칙과, 응답이 나온 뒤의 검증·필터입니다. 프롬프트만으로 안전을 장담하지 않고 출력단에서 형식·정책 위반을 다시 점검하는 이중 설계가 원칙입니다.

2.3 프롬프트 기법 — 제로샷·퓨샷·사고 사슬의 쓰임

같은 모델도 지시 방식에 따라 결과 품질이 크게 갈립니다. 제로샷(zero-shot, 예시 없이 지시만 주는 방식)은 과제가 명확할 때 가장 간결합니다. 퓨샷(few-shot, 원하는 입출력 예시를 몇 개 함께 주는 방식)은 형식이나 분류 기준을 말로 설명하기 어려울 때 정확도를 끌어올립니다. 사고 사슬(chain-of-thought, 결론 전에 중간 추론 단계를 밟게 하는 방식)은 계산이나 다단계 판단에서 오류를 줄입니다. 다만 예시가 늘면 토큰과 비용도 함께 늘어, 아키텍트는 정확도 이득과 비용을 견주어 기법을 고릅니다.

2.4 컨텍스트 윈도우와 토큰 — 유한한 예산의 운영

컨텍스트 윈도우(context window, 모델이 한 번에 참고할 수 있는 입력·출력 정보의 총량)는 유한한 예산입니다. 넣을 수 있다고 다 넣으면 비용과 지연이 커지고, 정작 중요한 정보가 긴 문맥에 묻혀 정확도가 떨어지기도 합니다. 아키텍트는 검색 증강(RAG, 질문과 관련된 문서 조각만 골라 붙이는 방식)으로 필요한 부분만 선별하고, 길어진 대화는 요약으로 압축하며, 토큰(token, 모델이 글을 처리하는 최소 단위) 사용량을 단계마다 추적합니다. 컨텍스트의 목표는 '많이'가 아니라 '알맞게'입니다.

2.5 재사용 설계 — 캐싱·모듈형 프롬프트·Skills

같은 시스템 프롬프트와 참조 문서를 매 요청마다 새로 보내면 동일한 내용을 반복해서 처리하게 됩니다. 프롬프트 캐싱(prompt caching, 반복되는 앞부분을 다시 쓰도록 저장해 두는 방식)은 이 반복분의 비용과 지연을 줄입니다. 모듈형 프롬프트는 규칙·예시·컨텍스트를 조각으로 나눠 조합하는 설계로, 한 조각만 고치면 그것을 쓰는 곳이 함께 갱신됩니다. Skills(스킬, 반복 절차와 지식을 재사용 가능한 단위로 묶어 필요할 때 불러오는 방식)는 이 재사용을 한 단계 위에서 조직화합니다. 재사용 설계는 비용만이 아니라 응답 품질의 일관성도 지킵니다.

! 흔한 함정

• 성능이 가장 높은 모델이 늘 정답이라는 오해 — 실무의 상당수는 균형·경량 계층으로 충분하며, 상위 모델을 습관적으로 쓰면 비용과 지연만 커집니다.
• 가드레일을 프롬프트 안 지시만으로 끝내려는 오해 — 프롬프트 규칙은 우회될 수 있어, 응답 이후의 검증 층이 없으면 안전 설계라 부를 수 없습니다.
• 예시나 컨텍스트는 많이 넣을수록 좋다는 오해 — 예시와 문맥이 늘면 토큰·비용·지연이 함께 늘고, 중요한 정보가 긴 문맥에 묻혀 정확도가 오히려 떨어질 수 있습니다.
• 프롬프트 캐싱을 한 번 켜면 알아서 된다고 여기는 오해 — 반복되는 부분을 앞쪽에 안정적으로 배치해야 재사용되며, 매 요청 바뀌는 값을 앞에 두면 캐시 이점이 사라집니다.