AI 연재 1/9 — LLM 호출 하나를 '파이프라인'으로 만든다는 것
LLM API를 처음 붙이면 신기하다. 프롬프트 던지면 그럴듯한 답이 온다. 문제는 그걸 서비스에 넣는 순간부터다. 응답 JSON이 가끔 깨지고, 타임아웃 뒤에 재시도했더니 같은 처리가 두 번 일어나고, 어느…
LLM 호출 하나를 "운영 가능한 시스템"으로 키워가는 과정을 9편으로 나눴다. 평가, 사람 검토, 에이전트 vs 워크플로, RAG, 동적 UI, 상태 머신까지. 뒤의 보강 5편은 "대화형 AI 보상 서비스"라는 하나의 사례를 여러 각도에서 파고든다.
1편부터 순서대로 읽는 걸 권한다. 아래 목록은 1편이 맨 위다.
LLM API를 처음 붙이면 신기하다. 프롬프트 던지면 그럴듯한 답이 온다. 문제는 그걸 서비스에 넣는 순간부터다. 응답 JSON이 가끔 깨지고, 타임아웃 뒤에 재시도했더니 같은 처리가 두 번 일어나고, 어느…
1편에서 파이프라인을 단계로 쪼개고 구조화 출력으로 형식을 고정했다. 그런데 형식이 맞는 것과 판단이 맞는 것은 다르다. 이번 편은 "잘 돌아간다는 걸 어떻게 증명하는가"다. 솔직히 이 주제는 개발자들 사이에서도…
돈이나 권리가 걸린 판단은 평균 정확도 95%로 충분하지 않다. 나머지 5%가 누군가의 청구 거절이 되기 때문이다. 이번 편은 AI가 틀릴 수 있다는 걸 전제로 시스템을 어떻게 설계하는가다. 처음 떠오르는 설계는…
"에이전트"라는 말이 너무 넓게 쓰인다. 도구 하나 붙인 챗봇도, 몇 시간씩 코드를 고치는 시스템도 에이전트라고 부른다. 설계 얘기를 하려면 이 단어부터 좁혀야 한다. Anthropic의 "Building…
RAG를 처음 접하면 "벡터DB에 문서 넣고 유사한 걸 가져와 프롬프트에 붙이는 것"으로 이해하기 쉽다. 틀린 설명은 아니다. 다만 실제로 품질을 가르는 건 생성 모델이 아니라 무엇을 가져오느냐인 경우가 많다.…
데모의 에이전트는 잘 돌아간다. 운영의 에이전트는 중간에 죽고, 사람의 승인을 기다리고, 컨텍스트가 넘치고, 가끔 이상한 지시를 따른다. 이번 편은 그 간극에 관한 이야기다. 길다. 그래도 하나씩 간다. 버전…
여기부터는 화면 이야기다. 1~6편에서 아무리 잘 만든 파이프라인도 사용자가 보는 건 입력창 하나다. 그리고 처리형 서비스(신청하고, 서류 내고, 결과를 받는)에서 입력창 하나는 생각보다 자주 한계에 부딪힌다.…
7편의 결론은 대화와 구조화된 위젯을 섞자는 것이었다. 그럼 이런 질문이 생긴다. 모델이 "지금 날짜 선택기를 보여 줘야겠다"고 판단했을 때, 그걸 어떻게 안전하게 화면에 올리는가. 이 분야는 지금 빠르게 움직이고…
마지막 편이다. 이번 글은 새 사실을 소개하기보다 지금까지의 조각을 하나로 엮는다. 그래서 대부분이 내 설계 제안이다. 출처가 있는 부분은 따로 표시하고, 나머지는 "이렇게 설계해 볼 수 있다"로 읽어 주면…
본편 9편에서는 "보상"을 넓게 잡고 보상 신청 시나리오 하나로 풀었다. 쓰고 나서 다시 보니 이 단어가 꽤 애매하다. 같은 문장을 듣고도 사람마다 떠올리는 시스템이 다르다. 그래서 이 보강 글에서는 해석을 네…
"보상"을 보험 보상으로 읽을 때의 이야기다. 먼저 한 가지. 아래 내용은 공개된 보도, 공식 자료, 소송 기사에서 읽은 것이다. 보험사가 내부에서 어떻게 하는지는 내가 모르고, 도입 성과 수치는 대부분 회사…
"보상"을 불편이나 오류에 대한 환불·배상·쿠폰 같은 고객 보상(CS)으로 읽을 때의 이야기다. 이 해석에서는 기술보다 먼저 책임 문제가 나온다. 챗봇이 "환불해 드릴게요"라고 말했는데 정책은 환불 불가라면, 누구…
"보상"을 로열티·리워드(포인트, 쿠폰, 캐시백)로 읽을 때의 이야기다. 이 해석에서 문제의 중심은 돈의 정확성이다. 한 번만 지급하고, 얼마 나갔는지 맞추고, 속여서 가져가지 못하게 하는 것. 미리 밝혀 둔다.…
마지막 해석이다. "AI 보상"이 서비스가 아니라 모델 학습 이야기일 수 있다. 개발자들이 모인 자리라면 충분히 나올 수 있는 얘기라 따로 준비했다. 이 글은 앞선 글들과 결이 다르게 논문 중심이다. 초록을 직접…