AI 제품 개발 핵심 개념 지도: 프롬프트에서 평가와 운영까지

데모는 십 분 만에 나오는데 제품이 되지 않는 일이 반복됩니다. 잘 되던 프롬프트가 입력이 조금 달라지면 무너지고, 고쳤더니 다른 경우가 깨지고, 무엇이 나아졌는지 말할 근거가 없습니다. 모델을 다루는 어려움보다는 정답이 하나가 아닌 시스템을 어떻게 판정하고 운영할지의 문제입니다.

이 문서는 AI 제품 개발의 중요한 개념을 한곳에서 찾기 위한 지도입니다. 모델을 학습시키는 연구가 아니라, 이미 있는 모델 위에 제품을 올려 만들고 평가하고 운영하는 쪽을 중심에 뒀습니다. 각 항목은 한두 문장으로 범위를 잡고, 자세한 설명이 필요한 주제는 별도의 심화 글로 연결합니다. 처음부터 끝까지 외울 필요는 없습니다. 결과가 이상할 때 어디를 먼저 볼지 정하는 기준점으로 사용하는 편이 좋습니다.

문제 정의와 적합성
-> 모델 선택
-> 프롬프트와 컨텍스트
-> 지식 연결
-> 도구와 에이전트
-> 평가
-> 안전과 신뢰
-> 비용과 지연
-> 운영과 개선

기본 개념

• 언어 모델: 다음에 올 내용을 확률적으로 이어 붙이도록 학습된 모델입니다. 사실을 조회하는 장치가 아니라 그럴듯한 이어짐을 만드는 장치라는 점이 모든 설계의 출발점입니다.
• 토큰: 모델이 다루는 텍스트의 최소 단위입니다. 비용, 속도, 길이 제한이 모두 이 단위로 계산됩니다.
• 컨텍스트 창: 한 번에 볼 수 있는 토큰의 최대 길이입니다. 넓다고 다 넣으면 되는 것이 아니라 넣을수록 비용과 지연이 오르고 정확도가 흔들립니다.
• 확률적 출력: 같은 입력에도 다른 결과가 나올 수 있습니다. 테스트와 재현, 그리고 버그 판정 방식이 일반 소프트웨어와 달라지는 근본 이유입니다.
• 온도와 샘플링: 출력의 다양성을 조절하는 값입니다. 창작에는 높게, 추출과 분류에는 낮게 두는 것이 기본 방향입니다.
• 환각: 사실이 아닌 내용을 자신 있게 만들어 내는 현상입니다. 없앨 수 있는 버그가 아니라 확률을 낮추고 검증으로 걸러야 하는 성질입니다.
• 지식 마감 시점: 학습에 포함된 정보의 시점입니다. 그 이후의 사실은 알지 못하므로 외부에서 넣어 줘야 합니다.
• 파운데이션 모델: 범용으로 학습된 대형 모델이며 대부분의 제품이 이 위에서 시작합니다. 직접 학습하는 선택은 대개 마지막에 고려할 대안입니다.
• 멀티모달: 텍스트뿐 아니라 이미지, 음성, 문서를 함께 다룹니다. 입력 형태가 늘면 검증해야 할 실패 유형도 함께 늘어납니다.
• 임베딩: 의미를 벡터로 바꾼 표현입니다. 검색, 분류, 중복 제거의 기반이 되며 생성과는 다른 계열의 도구입니다.
• 미세 조정: 특정 형식이나 말투에 맞추도록 모델을 추가 학습시키는 방법입니다. 지식을 넣는 수단으로는 대체로 적합하지 않습니다.
• 비결정성과 계약: 출력이 흔들리므로 형식을 강제하고 검증하는 층이 반드시 필요합니다. 자유 텍스트를 그대로 다음 단계에 넘기면 어딘가에서 깨집니다.
• 모델은 부품이다: 제품의 품질은 모델 성능이 아니라 그 주변 설계가 대부분 결정합니다. 같은 모델로 만든 결과물의 차이가 그 증거입니다.

문제 정의와 적합성

• AI가 맞는 문제: 정답이 여러 개이거나 규칙으로 적기 어려운 일에 어울립니다. 규칙으로 명확한 일에 쓰면 비싸고 불안정해집니다.
• 오류 허용도: 틀렸을 때 비용이 얼마나 큰지가 설계 전체를 정합니다. 되돌릴 수 있는 초안 생성과 되돌릴 수 없는 자동 실행은 다른 제품입니다.
• 사람이 검토하는 구조: 결과를 사람이 확인하고 고치는 흐름입니다. 정확도가 완벽하지 않아도 가치를 낼 수 있게 만드는 가장 실용적인 장치입니다.
• 자동화 수준: 제안만 할지, 초안을 만들지, 스스로 실행할지의 단계입니다. 한 번에 마지막 단계로 가려는 시도가 실패의 흔한 원인입니다.
• 기준선: 규칙 기반이나 기존 방식과 비교합니다. 비교 대상 없이 좋다고 말하면 개선 여부를 알 수 없습니다.
• 성공 정의: 무엇이 좋은 출력인지 먼저 문장으로 적습니다. 이것을 못 적으면 평가도 프롬프트도 만들 수 없습니다.
• 사용자 기대: 완벽할 것이라고 믿게 만들면 한 번의 실수로 신뢰를 잃습니다. 불확실성을 화면에서 정직하게 표현하는 편이 오래갑니다.
• 데이터 가용성: 답을 만들 근거가 실제로 접근 가능한지 먼저 확인합니다. 근거가 없는데 모델에 요구하면 환각을 요청하는 셈입니다.
• 범위 제한: 무엇을 하지 않을지 정하는 것이 품질을 만듭니다. 모든 질문에 답하려는 제품은 어느 질문에도 잘 답하지 못합니다.
• 실패 경험 설계: 모를 때 모른다고 말하고 다음 행동을 안내합니다. 틀린 답보다 모른다는 답이 신뢰를 덜 깎습니다.
• 가치 측정: 시간 절감이나 전환처럼 업무 지표로 연결합니다. 모델 지표만 좋아지고 제품 지표가 그대로인 경우가 흔합니다.
• 점진적 도입: 좁은 업무 하나에서 시작해 넓힙니다. 처음부터 전면 적용하면 실패 원인을 분리할 수 없습니다.
• 폐기 기준: 어느 수준에 도달하지 못하면 접을지 미리 정합니다. 정하지 않으면 계속 조금씩 고치며 시간을 씁니다.

모델 선택과 호출

• 모델 계층: 크고 느리고 비싼 모델과 작고 빠르고 싼 모델이 있습니다. 모든 요청에 최상위 모델을 쓰는 것은 대개 낭비입니다.
• 라우팅: 요청의 난이도에 따라 다른 모델로 보냅니다. 분류와 추출은 작은 모델로 충분한 경우가 많습니다.
• 폴백: 한 제공자가 실패할 때 다른 쪽으로 넘깁니다. 외부 의존이므로 장애를 전제로 설계해야 합니다.
• 버전 고정: 모델 버전을 고정하지 않으면 어느 날 출력이 바뀝니다. 평가 결과의 재현성도 여기에 달려 있습니다.
• 제공자 추상화: 호출 인터페이스를 한 겹 감싸 교체 가능하게 둡니다. 다만 지나친 추상화는 모델별 강점을 못 쓰게 만듭니다.
• 스트리밍: 토큰을 받는 대로 화면에 흘려 체감 지연을 줄입니다. 중간에 취소할 수 있게 만드는 것도 함께 설계합니다.
• 구조화 출력: 스키마를 정해 결과를 형식에 맞춰 받습니다. 파싱 실패를 코드에서 처리하는 것보다 훨씬 안정적입니다.
• 재시도: 일시적 오류와 형식 위반을 나눠 다룹니다. 형식이 틀렸을 때는 같은 요청을 반복하기보다 검증 결과를 알려 다시 만들게 합니다.
• 속도 제한: 제공자마다 한도가 있고 대기가 필요합니다. 사용자 요청과 배치 작업이 같은 한도를 나눠 쓰지 않도록 분리합니다.
• 프롬프트 캐시: 반복되는 앞부분을 재사용해 비용과 지연을 줄입니다. 프롬프트 구조를 안정된 앞쪽과 변하는 뒤쪽으로 나눠야 효과가 납니다.
• 일괄 처리: 즉시성이 필요 없는 작업은 모아서 싸게 처리합니다. 대량 분류와 색인 작업에 적합합니다.
• 자체 호스팅: 데이터 통제와 비용 예측을 얻고 운영 부담을 집니다. 트래픽이 크고 요구가 고정적일 때만 유리해집니다.
• 제공자 정책: 데이터 보존과 학습 사용 여부는 계약과 설정으로 정해집니다. 민감한 데이터를 다루기 전에 반드시 확인할 항목입니다.

프롬프트와 컨텍스트

• 프롬프트: 모델에게 주는 지시와 재료 전체입니다. 코드가 아니지만 제품 동작을 결정하므로 같은 수준으로 관리해야 합니다.
• 역할과 지시: 무엇을 하는 존재이고 무엇을 해야 하는지 명확히 적습니다. 모호한 지시는 모호한 출력으로 돌아옵니다.
• 출력 형식 지정: 원하는 모양을 예시와 스키마로 정합니다. 형식이 정해지면 이후 코드가 단순해집니다.
• 예시 제공: 몇 개의 입출력 예를 넣으면 형식과 기준이 크게 안정됩니다. 예시가 편향되면 그 편향이 그대로 나옵니다.
• 단계적 사고 유도: 복잡한 판단은 과정을 거치게 하면 정확도가 올라갑니다. 다만 최종 사용자에게 그 과정을 그대로 보일 필요는 없습니다.
• 작업 분해: 하나의 큰 프롬프트보다 작은 단계 여럿이 대체로 안정적입니다. 어느 단계에서 틀렸는지 찾을 수 있게 되는 것이 더 큰 이득입니다.
• 컨텍스트 구성: 무엇을 넣을지가 무엇을 지시할지보다 결과를 크게 좌우합니다. 관련 없는 내용은 정확도를 떨어뜨립니다.
• 위치 효과: 긴 컨텍스트에서는 앞과 뒤가 가운데보다 잘 반영됩니다. 중요한 지시를 가운데 묻지 않습니다.
• 컨텍스트 예산: 길이에는 비용, 지연, 정확도의 대가가 따릅니다. 넣을 것을 고르는 규칙이 곧 품질 관리입니다.
• 대화 이력 관리: 길어지는 대화를 요약하거나 잘라내야 합니다. 무엇을 버릴지 정하지 않으면 어느 순간 한도에 부딪힙니다.
• 프롬프트 버전 관리: 코드처럼 이력을 남기고 변경 이유를 적습니다. 평가 결과와 짝지어야 무엇이 개선이었는지 알 수 있습니다.
• 템플릿과 주입: 사용자 입력이 지시로 읽히지 않게 경계를 명확히 둡니다. 문자열을 그냥 이어 붙이는 방식이 프롬프트 주입의 통로가 됩니다.
• 프롬프트 유지 비용: 모델이 바뀌면 최적 프롬프트도 바뀝니다. 프롬프트에 미세하게 의존할수록 이전 비용이 커집니다.

지식 연결

• 검색 증강 생성: 질문과 관련된 문서를 찾아 함께 넣고 답하게 하는 구조입니다. 최신성과 근거 제시를 얻는 가장 일반적인 방법입니다.
• 청킹: 문서를 검색 단위로 쪼갭니다. 너무 작으면 맥락이 끊기고 너무 크면 관련 없는 내용이 섞입니다.
• 임베딩 검색: 의미가 가까운 조각을 찾습니다. 표현이 달라도 찾아내지만 정확한 용어 일치에는 약합니다.
• 키워드 검색: 정확한 단어와 식별자에 강합니다. 제품명과 코드처럼 철자가 중요한 검색에서 필수입니다.
• 하이브리드 검색: 두 방식을 결합하고 점수를 합칩니다. 실무에서는 대개 한쪽만 쓰는 것보다 낫습니다.
• 재순위: 후보를 넉넉히 뽑은 뒤 정밀한 모델로 다시 정렬합니다. 상위 몇 개의 품질이 답의 품질을 결정합니다.
• 메타데이터 필터: 기간, 권한, 문서 종류로 먼저 좁힙니다. 검색 품질과 접근 통제를 동시에 해결하는 지점입니다.
• 권한 반영: 사용자가 볼 수 없는 문서가 답변에 섞이면 유출입니다. 검색 단계에서 권한을 적용해야 하며 사후 필터링은 늦습니다.
• 출처 표시: 근거 문서를 함께 보여 줍니다. 검증 가능해지고 사용자가 신뢰 수준을 스스로 판단할 수 있습니다.
• 근거 기반 답변: 주어진 문서에서만 답하고 없으면 없다고 하게 만듭니다. 환각을 줄이는 가장 실질적인 지시입니다.
• 색인 갱신: 원본이 바뀌면 색인도 바뀌어야 합니다. 삭제된 문서가 계속 답변에 나오는 문제가 흔합니다.
• 지식과 형식의 구분: 지식은 검색으로, 말투와 형식은 프롬프트나 미세 조정으로 다룹니다. 이 둘을 바꿔 쓰면 비용만 늘고 효과는 없습니다.
• 평가 분리: 검색이 잘못됐는지 생성이 잘못됐는지 따로 측정합니다. 합쳐서 보면 어디를 고쳐야 할지 알 수 없습니다.

도구와 에이전트

• 도구 사용: 모델이 외부 기능을 호출해 계산, 조회, 실행을 맡깁니다. 모델이 못하는 일을 정확한 방법으로 넘기는 것이 핵심입니다.
• 도구 정의: 이름, 설명, 매개변수를 명확히 적습니다. 설명이 모호하면 엉뚱한 도구를 부르거나 부르지 않습니다.
• 도구 수: 선택지가 많을수록 오선택이 늘어납니다. 상황에 맞는 도구만 노출하는 편이 정확합니다.
• 에이전트: 목표를 받아 스스로 단계를 정하고 도구를 부르며 진행하는 구조입니다. 유연한 대신 예측 가능성과 비용 통제가 어려워집니다.
• 워크플로와 에이전트: 순서가 정해진 파이프라인과 스스로 정하는 방식의 구분입니다. 대부분의 업무는 정해진 순서로 충분하고 그편이 안정적입니다.
• 반복 한도: 스스로 도는 구조에는 최대 단계와 시간 한도가 필요합니다. 없으면 같은 자리를 맴돌며 비용을 태웁니다.
• 상태 관리: 여러 단계에 걸친 진행 상황을 어디에 둘지 정합니다. 중단과 재개가 가능해야 실제 업무에 쓸 수 있습니다.
• 부작용 통제: 메일 발송이나 결제처럼 되돌릴 수 없는 동작은 확인 단계를 둡니다. 자동 실행 권한은 가장 마지막에 주는 것입니다.
• 샌드박스: 생성된 코드나 명령은 격리된 환경에서 실행합니다. 모델이 만든 것을 그대로 실행하는 것은 외부 입력을 실행하는 것과 같습니다.
• 권한 범위: 에이전트에게 주는 자격 증명도 최소 권한이어야 합니다. 편의를 위해 넓은 권한을 주면 사고 시 범위가 그대로 커집니다.
• 다중 에이전트: 역할을 나눠 협업시키는 구조입니다. 조율 비용이 크므로 단일 흐름으로 안 되는 이유가 분명할 때만 씁니다.
• 관측: 어떤 도구를 왜 불렀는지 기록해야 디버깅이 됩니다. 중간 과정이 없으면 결과만 보고 원인을 추측하게 됩니다.
• 결정성 확보: 가능한 부분은 코드로 고정합니다. 모델에 맡기는 범위가 좁을수록 제품이 안정됩니다.

평가

• 평가 없이는 개선도 없다: 무엇이 나아졌는지 잴 수 없으면 프롬프트 수정은 취향 논쟁이 됩니다. 평가 체계가 이 분야의 실제 진입 장벽입니다.
• 평가 데이터셋: 실제 사용에서 모은 입력과 기대 결과의 묶음입니다. 처음에는 수십 건으로 시작해도 됩니다.
• 황금 데이터: 사람이 검토해 확정한 정답 집합입니다. 만들기 비싸지만 모든 자동 평가의 기준이 됩니다.
• 자동 지표: 형식 준수, 필수 항목 포함, 정확 일치처럼 기계가 판정 가능한 항목입니다. 값싸고 회귀 감지에 효과적입니다.
• 모델 기반 평가: 다른 모델이 출력을 채점하게 합니다. 편향과 한계가 있으므로 사람 판정과 정기적으로 대조해야 합니다.
• 사람 평가: 최종 기준이며 가장 비쌉니다. 기준을 문서로 고정하지 않으면 평가자 간 편차가 결과를 뒤흔듭니다.
• 회귀 검사: 프롬프트나 모델을 바꿀 때마다 기존 사례를 다시 돌립니다. 하나 고치고 셋 깨지는 상황을 막는 유일한 방법입니다.
• 실패 사례 수집: 잘못된 출력을 모아 분류합니다. 유형별로 묶으면 프롬프트를 고칠지 검색을 고칠지가 드러납니다.
• 온라인 평가: 실제 사용자 반응으로 확인합니다. 채택률, 수정률, 재시도율이 오프라인 점수보다 정직합니다.
• A/B 비교: 두 버전을 무작위로 배정해 차이를 봅니다. 확률적 출력이라 표본이 더 많이 필요합니다.
• 비용 지표 포함: 품질만 보면 계속 비싸지는 방향으로 갑니다. 건당 비용과 지연을 같은 표에 둡니다.
• 가드레일 지표: 개선하려는 지표와 함께 나빠지면 안 되는 항목을 정합니다. 정확도를 올리다 응답 시간이 무너지는 경우가 흔합니다.
• 평가의 편향: 만든 사람이 만든 평가는 만든 방식에 유리합니다. 사용자가 실제로 넣는 입력을 그대로 모으는 것이 가장 중요합니다.

안전과 신뢰

• 프롬프트 주입: 입력이나 문서에 담긴 지시가 시스템 지시를 덮어쓰는 공격입니다. 신뢰할 수 없는 텍스트를 읽는 모든 구조에 존재합니다.
• 간접 주입: 검색된 웹페이지나 문서에 숨은 지시가 들어 있는 경우입니다. 사용자가 아니라 데이터가 공격자인 상황입니다.
• 지시와 데이터 분리: 외부 내용은 데이터로만 다루고 지시로 해석하지 않게 경계를 둡니다. 완전한 방어는 없으므로 권한 제한과 함께 씁니다.
• 출력 검증: 모델 출력을 그대로 실행하거나 화면에 넣지 않습니다. 형식 검증과 이스케이프가 필요한 것은 일반 입력과 같습니다.
• 민감 정보 유출: 시스템 프롬프트, 다른 사용자 데이터, 내부 문서가 답변에 섞일 수 있습니다. 검색 권한과 로그 처리에서 대부분 갈립니다.
• 입력 필터: 유해하거나 범위를 벗어난 요청을 앞단에서 걸러 냅니다. 완벽하지 않으므로 여러 층으로 둡니다.
• 출력 필터: 유해 표현과 개인정보를 내보내기 전에 검사합니다. 지연이 늘어나므로 무엇을 검사할지 좁혀야 합니다.
• 거절 설계: 못 하는 일을 명확히 거절하고 대안을 안내합니다. 억지로 답하려다 틀리는 것보다 낫습니다.
• 편향: 학습 데이터의 치우침이 출력에 나타납니다. 사람에 대한 판단이 들어가는 기능에서는 반드시 검토해야 합니다.
• 불확실성 표현: 확신 없는 답을 확신 있게 말하는 것이 가장 큰 신뢰 손실입니다. 출처와 근거를 함께 보여 주는 편이 낫습니다.
• AI 사용 고지: 생성된 내용임을 알립니다. 규제와 별개로 사용자 신뢰에 직접 영향을 줍니다.
• 개인정보 처리: 어떤 데이터가 외부 제공자로 나가는지 명확히 하고 최소화합니다. 로그와 평가 데이터에 남는 사본도 함께 봐야 합니다.
• 규제: 분야에 따라 자동 결정과 설명 의무에 제약이 있습니다. 사람이 최종 판단하는 구조가 요구되는 경우가 많습니다.

비용과 지연

• 건당 비용: 요청 하나에 드는 토큰 비용을 계산해 둡니다. 사용량이 늘면 이 숫자가 사업성을 결정합니다.
• 입력과 출력 비용: 대개 출력이 더 비쌉니다. 장황한 형식을 요구하면 비용이 그대로 올라갑니다.
• 컨텍스트 낭비: 쓰지 않는 문서를 매번 넣는 것이 가장 흔한 낭비입니다. 검색 상위 몇 개로 줄이는 것만으로 크게 절감됩니다.
• 캐시: 같은 질문과 같은 앞부분을 재사용합니다. 비용과 지연을 함께 줄이는 몇 안 되는 수단입니다.
• 모델 하향: 쉬운 작업을 작은 모델로 옮깁니다. 평가 체계가 있어야 안전하게 내릴 수 있습니다.
• 지연 구조: 검색, 생성, 후처리 각 단계의 시간을 나눠 봅니다. 대개 한 단계가 전체를 지배합니다.
• 체감 지연: 스트리밍과 중간 상태 표시로 실제 시간보다 짧게 느끼게 합니다. 첫 응답까지의 시간이 가장 중요합니다.
• 병렬화: 서로 의존하지 않는 호출은 동시에 보냅니다. 순차로 엮인 파이프라인이 지연의 흔한 원인입니다.
• 타임아웃: 응답이 오래 걸릴 때 포기할 기준을 둡니다. 없으면 사용자와 서버 자원이 함께 묶입니다.
• 비동기 처리: 오래 걸리는 작업은 요청과 결과를 분리합니다. 문서 분석과 대량 생성에 적합합니다.
• 사용량 제한: 사용자와 조직 단위로 한도를 둡니다. 없으면 소수의 남용이 전체 비용을 좌우합니다.
• 비용 귀속: 어떤 기능과 어떤 고객이 얼마를 쓰는지 나눠 봅니다. 총액만 보면 줄일 지점을 찾을 수 없습니다.
• 가격 구조: 사용량 기반 원가 위에 어떤 요금제를 올릴지 정합니다. 무제한 요금제는 원가가 사용량에 비례하는 제품과 잘 맞지 않습니다.

운영과 개선

• 추적: 요청 하나의 프롬프트, 검색 결과, 도구 호출, 출력을 한 줄로 이어 봅니다. 이것이 없으면 사후 분석이 불가능합니다.
• 개인정보와 로그: 원문 저장 여부를 정책으로 정합니다. 디버깅 편의와 유출 위험이 정면으로 부딪히는 지점입니다.
• 피드백 수집: 좋아요와 수정 내역을 남깁니다. 사용자가 고친 결과가 가장 값싸고 정확한 학습 자료입니다.
• 채택률: 제안을 실제로 사용한 비율입니다. 만족도 조사보다 정직한 품질 지표입니다.
• 수정률: 결과를 얼마나 손봤는지 봅니다. 절감 시간을 추정하는 실용적인 근거가 됩니다.
• 모델 업데이트: 제공자가 모델을 바꾸면 출력이 달라집니다. 고정과 갱신 사이의 정책을 정하고 갱신 전에 평가를 돌립니다.
• 점진적 출시: 프롬프트 변경도 배포입니다. 일부 사용자에게 먼저 내보내고 지표를 봅니다.
• 되돌리기: 프롬프트와 설정을 즉시 이전 버전으로 되돌릴 수 있어야 합니다. 코드 배포보다 자주 필요해집니다.
• 실패 유형 분류: 검색 실패, 지시 미준수, 형식 오류, 사실 오류를 나눠 셉니다. 한 덩어리로 보면 개선 방향이 안 나옵니다.
• 데이터 축적: 실제 입력과 검토된 출력이 쌓일수록 평가와 개선이 쉬워집니다. 처음부터 모으는 구조를 만들어 두는 것이 가장 큰 자산입니다.
• 사람 검토 큐: 확신이 낮은 결과를 사람에게 보내는 흐름입니다. 자동화 비율을 서서히 올리는 방법이기도 합니다.
• 비상 정지: 이상 동작이 발견되면 기능을 즉시 끄는 스위치를 둡니다. 외부 모델에 의존하므로 우리 손으로 멈출 수 있어야 합니다.
• 문서화: 어떤 프롬프트가 무엇을 하고 어떤 실패가 알려져 있는지 남깁니다. 프롬프트는 코드보다 맥락이 빨리 사라집니다.

개념들은 기능 하나를 만드는 동안 만납니다

사내 문서에 답하는 질문 응답 기능 하나에도 이 지도의 거의 모든 영역이 들어옵니다.

1. 문제를 정합니다. 답을 자동으로 보내 줄지 초안만 만들지에 따라 필요한 정확도가 완전히 달라집니다.
2. 근거를 확보합니다. 답할 문서가 실제로 있는지 확인하지 않으면 모델에게 환각을 요청하는 셈입니다.
3. 검색을 만듭니다. 청킹과 하이브리드 검색, 재순위를 거쳐 상위 몇 개만 넣습니다.
4. 권한을 검색 단계에 넣습니다. 사용자가 볼 수 없는 문서가 답변에 섞이면 그것은 품질 문제가 아니라 유출입니다.
5. 프롬프트를 씁니다. 주어진 문서에서만 답하고 없으면 없다고 하도록 지시하고 출력 형식을 고정합니다.
6. 주입을 막습니다. 문서 안에 숨은 지시가 시스템 지시를 덮지 않도록 경계를 두고 권한을 좁힙니다.
7. 평가를 붙입니다. 실제 질문 수십 개로 검색 적중과 답변 정확도를 따로 측정합니다.
8. 비용과 지연을 봅니다. 넣는 문서 수를 줄이고 앞부분을 캐시하고 스트리밍으로 체감을 낮춥니다.
9. 운영을 준비합니다. 추적을 남기고 피드백을 모으고 즉시 끌 수 있는 스위치를 둡니다.

각 개념을 따로 배우는 이유는 기능 하나를 아홉 단계로 나눠 만들기 위해서가 아닙니다. 답이 이상할 때 원인이 검색인지, 프롬프트인지, 컨텍스트 구성인지, 모델 자체인지 좁혀 가기 위해서입니다. 모델이 멍청하다고 적는 순간 고칠 수 있는 것이 하나도 남지 않습니다.

처음 배운다면 이 순서가 좋습니다

• 평가부터 만듭니다. 사례 스무 개와 기대 결과를 적는 것만으로 이후 모든 작업의 기준이 생깁니다.
• 구조화 출력을 씁니다. 형식을 고정하면 코드가 단순해지고 실패를 자동으로 셀 수 있습니다.
• 작업을 쪼개 봅니다. 큰 프롬프트 하나를 두세 단계로 나누면 어디서 틀렸는지 보이기 시작합니다.
• 검색과 생성을 나눠 측정합니다. 근거를 못 찾은 것인지 근거를 두고 틀린 것인지 구분합니다.
• 실패 사례를 분류합니다. 유형별로 묶으면 무엇을 고쳐야 할지가 스스로 드러납니다.
• 비용과 지연을 함께 기록합니다. 품질만 보면 제품이 계속 비싸지는 방향으로 갑니다.
• 추적을 붙입니다. 프롬프트와 검색 결과와 출력을 한 줄로 이어 보관합니다.

이 순서가 절대적인 것은 아닙니다. 실제로 만들려는 기능 하나를 붙들고 필요한 개념을 앞뒤로 오가는 편이 훨씬 오래 남습니다.

이 문서는 시리즈의 허브입니다

이후의 심화 글은 각 문서만 읽어도 이해되도록 쓰고 ai-product-core-concepts 태그로 연결합니다. 새 글이 발행되면 이 허브의 관련 항목에도 직접 링크를 추가합니다. 번호대로 읽어야 하는 연재물이 아니라, 관심 있는 지점에서 들어와 전체 지도로 돌아올 수 있는 구조입니다.

먼저 확장하기 좋은 주제는 다음과 같습니다.

• 평가 데이터셋 스무 건으로 시작하기
• 검색 실패와 생성 실패를 나눠 재는 법
• 검색 단계에 권한을 넣어야 하는 이유
• 프롬프트 주입과 간접 주입: 데이터가 공격자일 때
• 구조화 출력으로 파싱 코드를 없애기
• 에이전트 대신 정해진 워크플로가 나은 경우
• 컨텍스트 예산: 무엇을 넣지 않을 것인가
• 프롬프트도 배포다: 버전 관리와 되돌리기

모델과 도구는 몇 달 단위로 바뀌지만 물어야 할 질문은 크게 달라지지 않습니다. 이 답의 근거는 어디에 있는가, 틀렸을 때 비용은 누가 치르는가, 무엇을 기준으로 나아졌다고 말하는가, 이 입력을 신뢰할 수 있는가, 그리고 지금 이것을 멈출 수 있는가. 이 다섯 질문을 기준으로 두면 새로 나온 기법도 이미 아는 개념 위에 놓고 이해할 수 있습니다.