Back to the Basics Back to the Basics

사내 상담 도우미의 답변 품질은 좋아졌는데, 월말 청구서와 고객 대기 시간이 예상보다 크게 늘었다. 팀은 곧바로 더 싼 모델로 바꾸자고 한다. 그러나 어떤 요청이 길어졌는지, 검색과 모델 호출 중 어디서 기다렸는지 모르면 가격표만 바꿔도 같은 문제가 반복된다. 모델 선택은 단가 비교가 아니라 품질·비용·지연시간을 함께 지키는 운영 결정이다.이 글은 모델 API를 쓰는 서비스에서 요청 유형별 예산과 응답 시간을 정하고, 실제 사용량을 관측해 조정하는 방법을 다룬다. 공급자의 요금과 제한은 모델·계정·시점마다 달라지므로 고정된 단가 대신 측정 절차를 제안한다.1. 한 번의 답변이 아니라 전체 경로를 계산한다사용자가 느끼는 시간에는 인증, 검색, 도구 호출, 모델 응답, 후처리, 화면 표시가 모두 들어간다. ..

결제 서비스의 오류 메시지를 고쳐 달라고 AI 코딩 에이전트에 맡겼다. 에이전트는 문구뿐 아니라 공통 예외 처리기와 로깅 설정도 바꾼 풀 리퀘스트를 올렸다. 테스트는 초록색이다. 그렇다면 바로 병합해도 될까? 변경을 만든 주체보다 중요한 것은 무엇이 바뀌었고 누가 그 위험을 이해한 채 승인했는가다.AI 코딩 에이전트는 저장소를 읽고 파일을 수정하며 테스트를 실행할 수 있다. GitHub의 Copilot cloud agent 설명도 계획·코드 변경·브랜치 작업과 풀 리퀘스트로 이어지는 흐름을 소개한다. 하지만 자동으로 만들어진 변경은 자동으로 정당화되지 않는다. 이 글은 작업 범위, 검토 증거, 승인 책임을 분리하는 실무 설계에 초점을 맞춘다.1. 요청과 변경 범위를 먼저 고정한다“오류 메시지를 개선해 줘..

팀원이 고객 불만 메일을 AI에 붙여 넣어 요약을 요청했다. 이름과 연락처, 주문번호를 지우지 않았고, 메일 아래에는 아직 공개되지 않은 가격 정책도 있었다. 요약 자체가 유용하더라도 질문은 남는다. 이 자료를 이 서비스에 입력해도 되는가? 출력의 정확성을 검토하기 전에 입력의 경계를 정해야 한다.AI 입력은 채팅창의 문장만이 아니다. 첨부 파일, 검색 증강(RAG)으로 가져온 문서, 도구 호출 결과, 대화 기록과 로그까지 포함한다. 이 글은 모든 AI 사용을 막자는 주장이 아니라, 업무 목적에 필요한 데이터만 승인된 경로로 전달하기 위한 설계 원칙이다.1. 데이터의 민감도와 사용 목적을 먼저 분리한다개인정보보호위원회의 생성형 AI 개발·활용을 위한 개인정보 처리 안내서는 목적 설정부터 적용·관리까지 단..

핵심 답: AI 자동화 과제를 고를 때는 “가장 화려한 아이디어”가 아니라 반복 빈도·절감 시간·데이터 준비도·변경 난이도·위험을 같은 기준으로 점수화해 비교해야 합니다. 아래 5개 지표를 1~5점으로 매기고, (효과 + 실행성) - 위험 구조로 정렬하면 첫 파일럿 대상을 설명 가능하게 고를 수 있습니다.이 글이 해결하는 문제“AI를 어디부터 적용해야 하나요?”라는 질문에 회의마다 후보만 쌓이고 결정이 나지 않는 경우를 위한 방법입니다. 고객 문의 요약, 문서 분류, 보고서 초안, 수요 예측처럼 서로 다른 업무를 같은 판정표에 올려 작게 검증할 1순위 과제를 정합니다. 이 방법은 도입 승인을 보장하거나 AI의 정확도를 미리 약속하지 않습니다. 대신 가설과 위험을 드러내고, 파일럿의 성공 기준을 먼저 정하..

같은 저장소를 열 때마다 테스트 명령, 코드 리뷰 기준, 릴리스 절차를 다시 설명하고 있지는 않은가? 한 번은 잘 전달해도, 다음 대화에서는 일부가 빠지거나 표현이 달라진다. 이런 반복 업무를 에이전트가 필요할 때 읽어 실행할 수 있도록 묶은 것이 스킬(skill)이다.Claude Code와 Codex는 모두 스킬을 재사용 가능한 작업 흐름으로 다루며, 중심에는 SKILL.md가 있다. 하지만 스킬은 모델을 새로 학습시키거나 권한을 자동으로 부여하는 기능이 아니다. 무엇을 언제 어떻게 할지 안내하고, 필요한 경우 보조 자료와 스크립트를 함께 제공하는 작은 워크플로 패키지에 가깝다.먼저 보는 시리즈 목차스킬이란 무엇인가: Claude Code와 Codex의 공통 구조Claude Code에서 스킬 만들기: ..

사내 고객지원 챗봇에 “배송 중인 주문을 취소할 수 있나요?”라고 물었다. 답은 단정적이고 출처 링크도 붙었다. 그런데 링크를 열어 보니 작년 정책의 일반 취소 규정이었다. 현행 문서에는 배송 중 주문은 담당자 확인이 필요하다고 적혀 있다. 모델이 문장을 매끄럽게 썼는지보다 먼저, 어떤 문서를 찾아 답의 근거로 삼았는지를 확인해야 하는 상황이다.RAG(Retrieval-Augmented Generation)는 질문에 맞는 외부 자료를 검색해 모델의 답변 맥락으로 제공하는 방식이다. 검색이 틀리면 그럴듯한 답변도 틀릴 수 있다. 반대로 올바른 문서를 찾아도 모델이 조건을 빠뜨릴 수 있다. 따라서 검색 품질, 답변의 근거 충실도, 질문에 대한 유용성을 분리해 다뤄야 한다.1. 검색과 답변을 한 점수로 합치지..

고객 문의를 요약해 담당자에게 전달하는 AI 기능을 출시했다고 해보자. 처음에는 보기 좋은 요약이 나왔다. 그런데 프롬프트를 조금 고친 뒤, 환불 기한이 지난 문의에서 “환불 가능”이라고 단정하는 답이 생겼다. 데모에서 잘 보였던 몇 건만 다시 확인해서는 이런 변화를 잡기 어렵다.AI 결과물은 같은 입력에도 표현이 달라질 수 있다. 따라서 모든 문장을 정답 문자열과 비교하기보다, 지켜야 할 조건과 허용 가능한 변동을 분리한 평가셋을 만들고 변경 전후를 비교해야 한다. 이번 글은 특정 평가 서비스의 사용법보다, 제품에 남길 회귀 테스트의 설계를 다룬다.1. 평가셋은 예쁜 질문 모음이 아니라 업무 계약이다평가셋의 한 행에는 입력만이 아니라 당시의 정책, 기대 행동, 금지 행동, 판단 근거가 있어야 한다. 고..

고객 문의를 읽고 답장을 작성하는 AI 에이전트를 만든다고 해보자. FAQ를 찾아 답변 초안을 만드는 일까지는 유용하다. 그런데 같은 에이전트에 고객 DB 수정 권한과 메일 발송 권한까지 한꺼번에 주면 어떻게 될까? 잘못 읽은 문서 한 줄이 실제 고객에게 전송되거나, 의도하지 않은 데이터 변경으로 이어질 수 있다.기존의 챗봇이 주로 “무엇을 말할까”를 고민했다면, 도구를 사용하는 에이전트는 “무엇을 실행할 수 있는가”까지 설계해야 한다. 핵심은 모델을 무조건 신뢰하거나 불신하는 것이 아니다. 읽기, 제안, 실행의 경계를 시스템으로 구분하는 것이다.1. 답변 생성과 행동 실행은 다른 문제다LLM이 “환불해 드리겠습니다”라고 답하는 것과 실제 환불 API를 호출하는 것은 전혀 다른 사건이다. 전자는 검토 가..