좋은 AI 기능을 설계하는 법

모델을 붙이기 전에 먼저 물어야 할 질문

LLM을 제품에 넣고 싶을 때 가장 먼저 떠오르는 질문은 보통 이것입니다. "어떤 모델을 써야 하지?"

하지만 좋은 AI 기능을 만드는 팀은 조금 다른 질문에서 출발합니다. "사용자는 지금 어떤 일을 끝내고 싶어 하지?"

이 차이는 작아 보이지만 결과는 크게 달라집니다. 모델부터 고르면 기능은 금세 화려해집니다. 채팅창이 생기고, 자동 생성 버튼이 생기고, 요약 기능이 들어갑니다. 그러나 사용자의 실제 업무 흐름과 맞지 않으면 그 기능은 한두 번 신기해서 눌러 보는 장식이 됩니다. 반대로 문제부터 정확히 잡으면 작은 모델, 간단한 검색, 심지어 규칙 기반 코드만으로도 사용자가 매일 쓰는 기능이 될 수 있습니다.

LLM은 강력하지만 만능 도구는 아닙니다. 자연어를 이해하고 생성하는 데 뛰어나지만, 모든 문제를 LLM으로 풀어야 하는 것은 아닙니다. 사용자가 "지난달 매출 합계가 얼마야?"라고 물었을 때 필요한 것은 창의적인 문장 생성이 아니라 정확한 데이터 조회입니다. 이 경우 LLM은 질문을 해석하는 입구로는 쓸 수 있지만, 답은 데이터베이스 쿼리와 계산으로 만들어야 합니다.

반대로 사용자가 "이 고객 불만 내용을 정중한 답변으로 바꿔 줘"라고 요청한다면 LLM이 잘 맞습니다. 정해진 규칙만으로는 어조, 맥락, 표현의 미묘한 차이를 다루기 어렵기 때문입니다. 결국 좋은 설계란 LLM을 많이 쓰는 설계가 아니라, LLM이 잘하는 일과 다른 기술이 잘하는 일을 나누는 설계입니다.

LLM을 써야 하는 문제와 쓰지 않아도 되는 문제

AI 기능을 설계할 때는 먼저 문제의 성격을 구분해야 합니다. LLM이 필요한 문제는 대체로 입력과 출력이 유연합니다. 사용자의 말이 매번 다르고, 원하는 결과도 하나로 고정되지 않습니다. 요약, 초안 작성, 분류, 질의응답, 문체 변환, 아이디어 확장 같은 작업이 여기에 속합니다.

반면 규칙 기반이나 검색 기반으로 충분한 문제도 많습니다. 가격 계산, 권한 확인, 주문 상태 조회, 날짜 비교, 재고 확인처럼 정답이 명확한 작업은 LLM에게 맡길수록 오히려 위험해질 수 있습니다. LLM은 그럴듯한 말을 잘하지만, 계산기나 데이터베이스처럼 항상 같은 방식으로 검증 가능한 결과를 내는 도구는 아닙니다.

아래 표는 기능을 설계할 때 사용할 수 있는 간단한 판단 기준입니다.

중요한 것은 하나의 기능 안에서도 여러 방식이 함께 쓰일 수 있다는 점입니다. 예를 들어 고객지원 챗봇을 만든다고 해 봅시다. 사용자의 질문을 이해하고 자연스럽게 응답하는 부분에는 LLM이 필요합니다. 하지만 환불 가능 여부는 주문일, 상품 상태, 정책 문서를 확인해야 합니다. 최종 환불 처리에는 권한 확인과 사용자 승인이 필요합니다. 이 모든 일을 LLM 하나에 맡기면 위험합니다. 좋은 설계는 LLM을 "말 잘하는 판단자"로 과신하지 않고, "자연어 인터페이스와 추론 보조자"로 적절히 배치합니다.

AI 기능은 마법 버튼이 아니라 작업 흐름이다

많은 AI 기능이 실패하는 이유는 버튼 하나로 모든 것을 끝내려 하기 때문입니다. "AI로 작성하기", "AI로 요약하기", "AI에게 맡기기" 같은 버튼은 처음에는 매력적으로 보입니다. 하지만 사용자는 결과가 마음에 들지 않을 때 무엇을 해야 할지 모릅니다. 다시 생성해야 할까요? 직접 고쳐야 할까요? 어떤 부분이 근거 있는 내용이고 어떤 부분이 모델의 추측일까요?

AI 기능은 결과 하나를 던져 주는 장치가 아니라 사용자의 작업을 앞뒤로 이어 주는 흐름이어야 합니다. 사용자가 어떤 정보를 입력하고, AI가 무엇을 만들고, 사용자가 어디를 검토하고, 최종적으로 어떤 행동을 승인하는지가 화면 안에서 자연스럽게 이어져야 합니다.

예를 들어 "고객 답변 자동 생성" 기능을 만든다면 나쁜 흐름은 이렇습니다. 상담원이 고객 문의를 열면 AI가 곧바로 답변을 생성하고, 전송 버튼이 옆에 붙어 있습니다. 이 구조에서는 상담원이 AI 답변을 제대로 검토하지 않은 채 전송할 위험이 큽니다.

더 나은 흐름은 상담원이 고객 문의를 선택하면 AI가 먼저 핵심 이슈를 요약해 줍니다. 그다음 관련 정책 문서와 주문 정보를 함께 보여 줍니다. AI 답변 초안은 편집 가능한 입력창에 들어가고, 상담원은 문장을 고친 뒤 직접 전송합니다. 이때 "환불 가능 여부는 정책 문서 3번 조항을 기준으로 판단했습니다"처럼 근거가 함께 표시되면 더 좋습니다.

이 차이는 단순한 UI 차이가 아닙니다. 책임의 위치를 명확히 하는 설계입니다. AI는 초안을 만들고, 사용자는 판단하고 승인합니다. 특히 고객 응대, 의료, 법률, 금융, 채용처럼 결과의 책임이 큰 영역에서는 이 원칙이 더욱 중요합니다.

사용자가 검토하고 수정하고 승인할 수 있어야 한다

LLM을 제품에 넣을 때 가장 안정적인 기본 자세는 "human-in-the-loop"입니다. 사람이 루프 안에 있다는 뜻입니다. 모델이 모든 것을 자동으로 처리하는 것이 아니라, 중요한 지점에서 사용자가 결과를 확인하고 수정하고 승인하도록 만드는 방식입니다.

이 구조는 사용자를 귀찮게 하려는 것이 아닙니다. 오히려 사용자가 AI를 신뢰하게 만드는 장치입니다. 사용자가 AI의 결과를 직접 고칠 수 있으면, AI는 불안한 자동화가 아니라 빠른 조수처럼 느껴집니다. 반대로 수정할 수 없는 자동화는 한 번 실수했을 때 신뢰를 크게 잃습니다.

검토 가능한 AI 기능에는 몇 가지 공통점이 있습니다.

• AI가 만든 결과와 사용자가 입력한 원본을 나란히 볼 수 있다.

• 사용자가 일부 문장만 선택해 다시 생성하거나 수정할 수 있다.

• 최종 저장, 전송, 게시, 결제, 삭제 같은 행동은 사용자가 승인한다.

• AI가 참고한 근거, 문서, 데이터, 검색 결과가 함께 표시된다.

• 사용자가 "마음에 들지 않음", "틀림", "근거 부족" 같은 피드백을 쉽게 남길 수 있다.

이런 흐름은 앞에서 만든 AI 글쓰기 도우미와도 연결됩니다. 좋은 글쓰기 도우미는 사용자의 글 전체를 멋대로 바꾸지 않습니다. 사용자가 선택한 문장만 다듬고, 변경 전후를 보여 주고, 되돌리기를 제공합니다. 사용자가 주도권을 잃지 않을 때 AI 기능은 오래 쓰입니다.

불확실성을 숨기지 않는 인터페이스

LLM 제품에서 가장 위험한 순간은 모델이 틀렸을 때가 아닙니다. 틀렸는데도 맞는 것처럼 보일 때입니다. 우리는 앞에서 환각과 프롬프트 인젝션을 다루며, LLM이 그럴듯하지만 사실이 아닌 답을 만들 수 있다는 점을 살펴보았습니다. 제품 설계에서는 이 한계를 화면과 흐름에 반영해야 합니다.

나쁜 인터페이스는 불확실성을 감춥니다. 답변만 크게 보여 주고, 근거는 숨기고, 실패 상황에서도 자연스럽게 말을 이어 갑니다. 사용자는 AI가 확신한다고 느끼지만, 실제로는 검색 결과가 부족하거나 문서에 답이 없거나 도구 호출이 실패했을 수 있습니다.

좋은 인터페이스는 불확실성을 드러냅니다. "관련 문서를 찾지 못했습니다", "이 답변은 업로드된 문서가 아니라 일반적인 설명을 바탕으로 작성되었습니다", "정확한 처리를 위해 담당자 확인이 필요합니다"처럼 상태를 분명히 알려 줍니다. 이것은 약점 고백이 아니라 신뢰 설계입니다.

특히 RAG 기반 Q&A에서는 답변 자체만큼이나 "근거가 있었는가"가 중요합니다. 검색된 문서가 없으면 답변하지 않는 편이 나을 수 있습니다. 검색된 문서가 있지만 관련성이 낮으면 낮다고 말해야 합니다. 서로 충돌하는 근거가 있으면 하나를 억지로 고르기보다 충돌을 보여 주는 것이 더 안전합니다.

실패 상황도 제품 경험의 일부로 설계해야 합니다. 사용자는 AI가 실패할 수 있다는 사실 자체보다, 실패했을 때 어디로 가야 하는지 모르는 상황을 더 답답해합니다. 따라서 실패 메시지는 친절해야 하며 다음 행동을 제안해야 합니다.

예를 들어 "답변을 생성하지 못했습니다"보다 "업로드된 문서에서 질문과 관련된 내용을 찾지 못했습니다. 다른 표현으로 질문하거나, 문서를 추가로 업로드해 주세요"가 낫습니다. "오류가 발생했습니다"보다 "요약할 수 있는 텍스트를 찾지 못했습니다. 스캔 PDF라면 OCR 처리가 필요할 수 있습니다"가 낫습니다.

AI 기능의 세 가지 형태: 보조, 제안, 자동화

제품 안에서 AI가 맡는 역할은 크게 세 단계로 나눌 수 있습니다. 이 구분을 해 두면 기능의 위험도와 사용자 경험을 설계하기 쉬워집니다.

첫 번째는 보조입니다. 사용자가 하던 일을 더 쉽게 하도록 옆에서 돕는 형태입니다. 문장을 다듬거나, 긴 문서를 요약하거나, 고객 문의의 핵심을 정리하는 기능이 여기에 속합니다. 보조 기능은 위험이 낮고 도입이 쉽습니다. 결과가 완벽하지 않아도 사용자가 검토하고 고칠 수 있기 때문입니다.

두 번째는 제안입니다. AI가 다음 행동을 추천하지만, 실행은 사용자가 선택합니다. 예를 들어 "이 고객에게는 환불 안내 답변을 보내는 것이 적절합니다", "이 문서는 법무팀 검토가 필요해 보입니다", "이 이슈는 긴급 티켓으로 분류하는 것이 좋습니다" 같은 방식입니다. 제안 기능은 사용자의 판단 시간을 줄여 주지만, 최종 책임은 여전히 사용자에게 둡니다.

세 번째는 자동화입니다. AI가 판단하고 행동까지 실행합니다. 예를 들어 특정 조건의 이메일을 자동으로 분류하고, 답변을 보내고, CRM에 기록하는 기능입니다. 자동화는 강력하지만 위험도도 큽니다. 따라서 충분한 로그, 권한 제한, 되돌리기, 승인 조건, 예외 처리, 모니터링이 필요합니다.

처음부터 자동화를 목표로 삼을 필요는 없습니다. 대부분의 제품에서는 보조 기능으로 시작해 사용자의 피드백을 모으고, 자주 반복되는 패턴을 찾은 뒤, 일부 제안 기능으로 확장하는 편이 안전합니다. 자동화는 마지막 단계에 가깝습니다.

MVP에서 측정해야 할 것들

AI 기능을 출시한 뒤 "모델 답변이 좋아 보인다"는 느낌만으로 성공을 판단하면 안 됩니다. 제품 기능으로서의 AI는 사용자가 실제로 일을 끝내는 데 도움이 되는지로 평가해야 합니다. 초기 MVP에서는 거창한 지표보다 작고 직접적인 지표가 더 중요합니다.

MVP에서 특히 봐야 할 지표는 활성화, 재사용, 작업 완료율입니다.

활성화는 사용자가 AI 기능의 가치를 처음 경험했는지를 보여 줍니다. 예를 들어 PDF 요약기라면 "파일 업로드 후 첫 요약을 생성한 사용자 비율"이 될 수 있습니다. 블로그 글 생성기라면 "주제 입력 후 초안을 생성하고 편집 화면까지 도달한 비율"이 될 수 있습니다. 가입자 수보다 중요한 것은 사용자가 실제로 첫 성공 경험에 도달했는가입니다.

재사용은 그 기능이 신기함을 넘어 습관이 되었는지를 보여 줍니다. 한 번 써 보고 끝나는 기능은 데모로는 좋아도 제품의 핵심 가치가 되기 어렵습니다. 사용자가 다음 날, 다음 주에도 다시 돌아오는지 봐야 합니다. AI 기능은 처음에는 놀랍지만, 반복 사용에서 진짜 가치가 드러납니다.

작업 완료율은 사용자가 AI 도움을 받아 실제 목표를 끝냈는지를 보여 줍니다. 요약을 생성했는지보다 요약을 저장했는지가 중요할 수 있습니다. 답변 초안을 만들었는지보다 상담원이 수정 후 고객에게 보냈는지가 중요할 수 있습니다. 코드를 생성했는지보다 테스트를 통과하고 병합했는지가 중요할 수 있습니다.

이 세 지표에 더해 품질 피드백도 함께 봐야 합니다. 사용자가 AI 결과를 얼마나 수정했는지, 다시 생성 버튼을 몇 번 눌렀는지, "도움 됨"과 "도움 안 됨" 중 무엇을 선택했는지, 근거 부족으로 실패한 비율이 얼마인지 기록하면 개선 방향이 보입니다.

좋은 AI 제품 팀은 "모델을 더 좋은 것으로 바꾸면 해결될 것"이라고만 생각하지 않습니다. 사용자 입력을 더 잘 받게 만들고, 문서 검색 품질을 높이고, 결과 편집 흐름을 개선하고, 실패 메시지를 고칩니다. 실제 제품에서는 모델 교체보다 이런 작은 설계 개선이 더 큰 효과를 내는 경우가 많습니다.

작은 AI 기능으로 시장을 검증하는 법

1인 개발자나 스타트업이라면 처음부터 거대한 AI 서비스를 만들 필요가 없습니다. 오히려 작게 시작하는 편이 훨씬 유리합니다. AI 제품은 만들 수 있는 것이 너무 많기 때문에, 범위를 좁히지 않으면 금세 "무엇이든 해 주는 애매한 챗봇"이 됩니다.

시장 검증을 위한 좋은 출발점은 특정 사용자, 특정 상황, 특정 결과를 고르는 것입니다. "문서 요약 서비스"보다 "투자 검토 보고서를 5분 안에 1페이지 요약으로 바꿔 주는 도구"가 더 선명합니다. "AI 글쓰기 서비스"보다 "쇼핑몰 운영자가 상품 상세 설명을 빠르게 고치는 도우미"가 더 검증하기 쉽습니다. "고객지원 챗봇"보다 "환불 정책 질문에만 답하는 쇼핑몰 FAQ 챗봇"이 더 안전하고 빠릅니다.

작은 AI 기능의 장점은 학습 속도입니다. 범위가 좁으면 어떤 입력이 들어오는지, 사용자가 어디서 막히는지, 어떤 결과를 신뢰하지 않는지 빠르게 관찰할 수 있습니다. 또한 보안과 비용 관리도 쉬워집니다. 처음부터 모든 문서, 모든 고객, 모든 업무를 다루려 하면 데이터 권한, 개인정보, 품질 평가, 비용 문제가 동시에 터집니다.

초기 시장 검증에서는 다음 순서가 실용적입니다.

1. 사용자가 반복해서 하는 귀찮은 작업을 찾는다.

2. 그 작업 중 LLM이 잘할 수 있는 작은 구간만 고른다.

3. 결과를 자동 실행하지 말고 초안이나 제안으로 제공한다.

4. 사용자가 수정하고 승인하는 흐름을 만든다.

5. 활성화, 재사용, 작업 완료율을 측정한다.

6. 반복 사용자가 생기면 범위를 조금씩 넓힌다.

이 방식은 화려하지 않지만 강합니다. 시장은 "AI가 들어갔는가"보다 "내 일이 쉬워졌는가"에 반응합니다.

사용자의 기대를 정확히 맞추기

AI 기능에서 기대 관리는 매우 중요합니다. 사용자가 기능 이름만 보고 무엇을 기대해야 하는지 알 수 있어야 합니다. "AI 비서"라는 이름은 넓고 멋있지만, 너무 많은 기대를 부릅니다. 사용자는 일정 관리, 문서 작성, 검색, 이메일 전송, 파일 정리까지 모두 해 줄 것이라 생각할 수 있습니다. 실제 기능이 그 기대를 따라가지 못하면 실망이 커집니다.

반대로 "회의록에서 할 일 추출하기"는 좁지만 명확합니다. 사용자는 무엇을 입력해야 하고 무엇을 얻을 수 있는지 바로 이해합니다. 좋은 AI 기능은 이름부터 범위를 정직하게 드러냅니다.

기대 관리는 안내 문구에서도 중요합니다. "무엇이든 물어보세요"는 편하지만 위험합니다. 사용자가 제품 범위를 벗어난 질문을 던지기 쉽기 때문입니다. 사내 문서 Q&A라면 "업로드된 사내 문서를 기준으로 질문해 주세요"가 낫습니다. 고객지원 챗봇이라면 "배송, 환불, 계정 문제에 대해 도와드릴 수 있습니다"처럼 가능한 범위를 보여 주는 편이 좋습니다.

한계 고지는 겁을 주는 문구가 아닙니다. 사용자가 기능을 올바르게 쓰도록 돕는 내비게이션입니다. "AI 답변은 참고용이며 중요한 결정 전 담당자 확인이 필요합니다"라는 문구도 상황에 따라 필요합니다. 다만 모든 화면에 형식적인 면책 문구만 붙이는 것은 충분하지 않습니다. 사용자가 실제로 위험한 행동을 하려는 순간에 검토와 승인을 요구해야 합니다.

좋은 AI 기능 명세서 만들기

AI 기능을 만들기 전에 짧은 명세서를 써 보면 설계가 훨씬 선명해집니다. 거창한 문서일 필요는 없습니다. 핵심 질문에 답하는 한 페이지면 충분합니다.

좋은 AI 기능 명세서에는 다음 내용이 들어갑니다.

• 사용자: 누가 이 기능을 쓰는가?

• 상황: 사용자는 어떤 순간에 이 기능을 찾는가?

• 문제: 사용자가 끝내고 싶은 일은 무엇인가?

• 입력: 사용자가 제공해야 하는 정보는 무엇인가?

• 출력: AI는 어떤 형태의 결과를 제공하는가?

• 근거: 답변은 어떤 데이터나 문서를 바탕으로 하는가?

• 검토: 사용자는 어디서 수정하고 승인하는가?

• 실패: 근거가 없거나 오류가 나면 어떻게 안내하는가?

• 지표: 성공 여부를 무엇으로 측정하는가?

예를 들어 "PDF 요약기"를 만든다면 명세는 이렇게 구체화할 수 있습니다. 사용자는 긴 보고서를 읽을 시간이 부족한 직장인입니다. 사용 상황은 회의 전 10분입니다. 문제는 핵심 주장, 숫자, 결론을 빠르게 파악하는 것입니다. 입력은 PDF 파일이고, 출력은 1페이지 요약과 페이지별 근거입니다. 사용자는 요약을 복사하기 전에 원문 페이지를 확인할 수 있어야 합니다. 스캔 PDF라서 텍스트를 추출하지 못하면 OCR 필요성을 안내해야 합니다. 성공 지표는 첫 요약 생성률, 요약 저장률, 같은 사용자의 재업로드율입니다.

이 정도만 써도 "그냥 PDF를 넣으면 AI가 알아서 요약해 준다"보다 훨씬 나은 제품이 됩니다.

채팅창이 항상 정답은 아니다

LLM이 등장한 뒤 많은 제품이 채팅창을 기본 인터페이스로 선택했습니다. 채팅은 자연스럽고 유연합니다. 사용자가 원하는 것을 문장으로 말할 수 있기 때문입니다. 그러나 모든 AI 기능에 채팅창이 필요한 것은 아닙니다.

사용자의 목표가 분명한 작업에서는 버튼, 폼, 편집기, 체크리스트가 더 나을 수 있습니다. 블로그 글 생성기라면 빈 채팅창보다 주제, 독자, 톤, 길이, 포함할 키워드를 입력하는 폼이 더 편할 수 있습니다. 고객지원 답변 생성이라면 채팅창보다 문의 내용, 주문 정보, 관련 정책, 답변 초안이 한 화면에 보이는 편이 더 실용적입니다. 문서 요약기라면 "짧게", "상세하게", "표로", "회의용으로" 같은 옵션 버튼이 채팅보다 빠를 수 있습니다.

채팅은 탐색에는 좋지만 반복 업무에는 느릴 수 있습니다. 사용자가 매번 같은 설명을 입력해야 한다면 제품 설계가 부족한 것입니다. 자주 쓰는 의도는 버튼과 템플릿으로 빼고, 예외적인 요청만 채팅으로 처리하는 혼합형 인터페이스가 좋은 선택이 될 때가 많습니다.

신뢰는 정확도만으로 만들어지지 않는다

AI 기능의 신뢰는 모델 정확도만으로 결정되지 않습니다. 사용자는 결과가 조금 부족해도 고칠 수 있고, 근거를 확인할 수 있고, 되돌릴 수 있으면 계속 사용합니다. 반대로 결과가 대체로 좋아도 가끔 위험한 실수를 하고, 그 실수를 사용자가 알아차리기 어렵다면 신뢰는 무너집니다.

신뢰를 만드는 요소는 여러 가지입니다.

• 결과의 근거를 확인할 수 있어야 한다.

• 중요한 행동에는 사용자 승인이 있어야 한다.

• 실패와 불확실성을 숨기지 않아야 한다.

• 사용자가 쉽게 수정하고 되돌릴 수 있어야 한다.

• 개인정보와 민감한 데이터 처리 범위가 명확해야 한다.

• 로그와 피드백을 바탕으로 계속 개선되어야 한다.

이 요소들은 앞 장들에서 다룬 비용, 속도, 품질 평가, 보안, 프롬프트 인젝션 대응과 모두 연결됩니다. 좋은 AI 기능은 모델 호출 코드 하나로 완성되지 않습니다. 입력을 안전하게 받고, 필요한 근거를 찾고, 결과를 검증하고, 사용자에게 적절한 선택권을 주고, 운영 중에 계속 관찰하는 전체 시스템입니다.

제품 안에서 LLM의 자리를 정한다

이제 책의 거의 끝에 왔습니다. 우리는 토큰화와 임베딩에서 시작해 Attention과 Transformer를 지나, 작은 GPT를 직접 만들고, API와 RAG와 Tool Use를 제품에 붙이는 방법까지 살펴보았습니다. 이 여정을 지나오면 한 가지 사실이 분명해집니다. LLM은 마법 상자가 아니라 확률적으로 다음 토큰을 생성하는 모델입니다. 동시에 잘 설계된 시스템 안에서는 매우 강력한 사용자 경험을 만들 수 있는 부품입니다.

따라서 마지막으로 기억해야 할 원칙은 단순합니다. AI 기능의 성공은 모델 성능보다 사용자의 문제를 정확히 푸는 설계에서 결정됩니다.

좋은 AI 기능은 사용자의 일을 대신 빼앗지 않습니다. 사용자가 더 빨리 이해하고, 더 쉽게 작성하고, 더 안전하게 결정하고, 더 적은 반복으로 원하는 결과에 도달하게 돕습니다. 좋은 AI 기능은 자신의 한계를 숨기지 않습니다. 근거가 부족하면 부족하다고 말하고, 확신할 수 없으면 확인을 요청하고, 중요한 행동 앞에서는 사용자의 승인을 받습니다.

1인 개발자라면 작은 반복 업무 하나를 고르세요. 스타트업이라면 특정 고객군의 비싼 문제 하나를 고르세요. 그리고 LLM을 그 문제의 전부가 아니라 가장 답답한 한 구간에 배치해 보세요. 사용자가 다시 돌아와 쓰고, 결과를 저장하고, 주변 사람에게 추천한다면 그때 기능을 넓혀도 늦지 않습니다.

LLM을 제품에 넣는 일은 이제 특별한 연구소만의 일이 아닙니다. 하지만 좋은 AI 제품을 만드는 일은 여전히 깊은 이해와 섬세한 설계를 요구합니다. 이 책에서 배운 원리와 구현 경험은 그 설계를 위한 기반입니다. 모델이 무엇을 잘하고 무엇을 못하는지 아는 사람은 더 정직한 인터페이스를 만들 수 있습니다. 작은 GPT를 직접 만들어 본 사람은 거대한 모델도 더 차분하게 다룰 수 있습니다. RAG와 도구 호출을 이해한 사람은 AI를 말만 잘하는 챗봇이 아니라 실제 문제를 해결하는 시스템으로 연결할 수 있습니다.

이제 남은 질문은 하나입니다. LLM을 이해한다는 것은 결국 무엇을 의미할까요? 마지막 장에서 그 질문으로 돌아가 보겠습니다.