업무 요청 유형별 설계 판단
3줄 요약
- AI 업무 요청은 “챗봇 만들어 주세요”처럼 들어와도 실제로는 QA, 요약, 분류, 검색, 자동화, 생성, 검토 중 하나로 나눠야 한다.
- 요청 유형을 나누면 필요한 데이터, latency, 정확도 기준, 실패 처리, 권한, 비용 구조가 보인다.
- 백엔드 개발자는 모델 선택보다 먼저 업무 위험과 사용자 경험을 분류해야 한다.
핵심 정리
- 문서 기반 QA는 RAG, 권한 필터, source 표시, 근거 없음 처리가 핵심이다.
- 상담/회의/로그 요약은 민감정보 마스킹, 긴 입력 처리, 요약 품질 eval이 중요하다.
- 사용자 입력 분류는 structured output, 결정성, 회귀 테스트가 중요하다.
- DB 데이터 기반 답변은 SQL 생성보다 권한, 쿼리 제한, read-only 경계가 먼저다.
- 사내 업무 자동화 agent는 tool 권한, approval, idempotency, audit log가 핵심이다.
헷갈리는 지점
- 모든 요청을 챗봇으로 풀려고 하기 쉽다. 사용자가 자연어 UI를 원한다고 말하기 때문이다.
- 핵심은 자연어 UI와 문제 유형을 분리하는 것이다.
- 분류, 요약, 검색, 자동화는 서로 다른 설계가 필요하다.
- 모델 품질이 높으면 설계가 단순해진다고 생각하기 쉽다. 최신 모델 성능이 좋아 보이기 때문이다.
- 핵심은 권한, 비용, 실패 처리, 감사 로그는 모델 성능과 별개의 백엔드 책임이라는 점이다.
확인 질문
- AI 업무 요청을 받으면 가장 먼저 해야 할 일은 무엇인가?
- 요청을 QA, 요약, 분류, 검색, 자동화, 생성, 검토 같은 유형으로 나누고 위험도를 판단하는 것이다.
- agent 자동화 요청에서 모델보다 먼저 봐야 할 것은 무엇인가?
- tool 권한, side effect, 승인 흐름, idempotency, audit log다.
장애 상황별 대응 런북
3줄 요약
- AI 장애는 답변 지연, 비용 폭증, JSON 파싱 실패, RAG 품질 저하, tool 중복 실행처럼 증상 중심으로 온다.
- 증상만 보지 말고 입력, retrieval, 모델 호출, validation, 후처리, 저장 단계를 분리해 원인을 찾는다.
- 런북에는 즉시 완화, 원인 분석, 재발 방지, 관측 지표가 함께 있어야 한다.
핵심 정리
- 답변이 느리면 token 길이, provider latency, retry, queue depth, vector DB latency를 본다.
- 비용이 증가하면 prompt version, input/output token, retry count, batch/eval, cache hit rate를 본다.
- JSON이 깨지면 schema 변경, prompt 변경, refusal, partial output, 모델 변경을 본다.
- RAG가 틀리면 index freshness, chunking, metadata filter, 권한 필터, reranker, query rewrite를 본다.
- tool 중복 실행은 retry, queue 중복 전달, agent loop, idempotency 부재를 본다.
헷갈리는 지점
- 모델이 이상하다고 한 덩어리로 묶기 쉽다. 사용자 입장에서는 답이 이상하다는 증상만 보이기 때문이다.
- 핵심은 AI 기능도 파이프라인이라는 점이다.
- 검색 실패와 생성 실패, schema 실패, 후처리 실패를 분리해야 한다.
- 장애가 나면 프롬프트부터 고치고 싶어지기 쉽다. 가장 눈에 잘 보이는 부분이기 때문이다.
- 핵심은 프롬프트 변경이 새 회귀를 만들 수 있다는 점이다.
- 먼저 trace와 eval로 원인을 좁힌다.
확인 질문
- RAG 답변이 틀렸을 때 먼저 분리해야 할 두 단계는 무엇인가?
- 검색 결과가 틀렸는지, 검색 결과는 맞는데 생성이 틀렸는지 분리해야 한다.
- 비용 폭증 장애에서 확인할 핵심 지표는 무엇인가?
- input/output token, retry count, prompt version, tenant, batch/eval 실행, cache hit rate다.
비용 지연 품질 트레이드오프
3줄 요약
- AI 기능은 비용, 지연시간, 품질을 동시에 최적화하기 어렵다.
- 좋은 설계는 모든 요청에 최고 모델을 쓰는 것이 아니라 요청 위험도에 따라 모델, context, retry, fallback을 다르게 적용한다.
- 개인 프로젝트도 token budget과 max output, 기업 운영은 tenant quota와 SLO가 필요하다.
핵심 정리
- 빠른 응답이 중요한 기능은 작은 모델, 짧은 context, streaming, 캐시를 우선 검토한다.
- 정확성이 중요한 기능은 RAG 품질, eval, human review, source 표시를 우선 검토한다.
- 비용이 중요한 기능은 model routing, token budget, prompt caching, batch 처리, output 제한을 본다.
- 품질을 올리려고 context를 많이 넣으면 latency와 비용이 증가하고, 오히려 오래된 정보 때문에 품질이 떨어질 수 있다.
- fallback은 가용성을 올리지만 품질 차이와 schema 차이를 미리 eval해야 한다.
헷갈리는 지점
- 가장 좋은 모델을 쓰면 품질 문제가 해결된다고 생각하기 쉽다. 모델 성능이 높기 때문이다.
- 핵심은 잘못된 context와 권한 문제는 좋은 모델도 해결하지 못한다는 점이다.
- 모델보다 retrieval과 harness가 먼저일 때가 많다.
- 비용 최적화는 나중에 해도 된다고 생각하기 쉽다. 처음에는 트래픽이 작기 때문이다.
- 핵심은 프롬프트와 로그 구조를 나중에 바꾸면 회귀 비용이 크다는 점이다.
- 최소한 usage 기록은 처음부터 둔다.
확인 질문
- 비용, 지연, 품질을 모두 만족시키기 어려울 때 필요한 전략은 무엇인가?
- 요청 유형과 위험도별로 모델, context, retry, fallback, 비동기 처리를 다르게 라우팅하는 것이다.
- 품질을 올리기 위해 context를 무조건 늘리면 생기는 문제는 무엇인가?
- 비용과 latency가 증가하고, 오래되거나 충돌하는 정보가 섞여 품질이 오히려 떨어질 수 있다.
개인 프로젝트를 프로덕션 수준으로 끌어올리기
3줄 요약
- 개인 프로젝트도 timeout, retry, structured output, usage log, prompt version, 작은 eval set 정도는 갖추면 결과물이 달라진다.
- 모든 기업 수준 장치를 붙일 필요는 없지만, 실패와 비용을 관찰할 수 있어야 한다.
- 데모를 넘어서려면 “잘 되는 케이스”보다 “망가지는 케이스”를 보여줄 수 있어야 한다.
핵심 정리
- API key와 prompt/context 로그를 안전하게 관리한다.
- 모델 호출을 client wrapper로 감싼다.
- JSON 응답은 schema validation을 거친다.
- 대표 질문 10개에서 30개 정도의 eval set을 둔다.
- RAG를 쓴다면 문서 삭제, 재색인, source 표시를 구현한다.
- 배포 후 usage와 error를 볼 수 있는 로그를 남긴다.
헷갈리는 지점
- 개인 프로젝트는 빠르게 보여주는 게 전부라고 생각하기 쉽다. 포트폴리오에서는 화면이 먼저 보이기 때문이다.
- 핵심은 AI 기능은 운영 감각이 차별점이라는 점이다.
- 작은 프로젝트에서도 timeout, 검증, 비용 제한을 보여주면 수준이 달라진다.
- 기업 수준 아키텍처를 그대로 따라야 한다고 생각하기 쉽다. 좋은 사례를 보면 복잡해 보이기 때문이다.
- 핵심은 성숙도에 맞게 줄이는 것이다.
- 개인 프로젝트는 작은 eval과 명확한 실패 처리만으로도 충분히 좋아진다.
확인 질문
- 개인 AI 프로젝트의 최소 운영 장치는 무엇인가?
- timeout, 제한적 retry, structured output validation, usage log, prompt version, 작은 eval set이다.
- 포트폴리오에서 AI 기능의 수준을 보여주는 방법은 무엇인가?
- 성공 화면뿐 아니라 실패 처리, 비용 제한, source 표시, eval 결과, 장애 대응 기준을 보여주는 것이다.
기업 운영 수준 체크리스트와 인프라 협업
3줄 요약
- 기업 운영에서는 AI 기능도 SLO, 장애 런북, 비용 예산, 보안, 감사 로그, 배포 관리가 필요하다.
- 인프라팀은 예측 어려운 latency, token 비용, 외부 provider 의존성, vector DB, worker, 로그 비용을 걱정한다.
- 백엔드 개발자는 AI 기능의 traffic, token, queue, provider, data flow를 설명할 수 있어야 한다.
핵심 정리
- SLO는 성공률뿐 아니라 latency, validation failure, fallback rate, retrieval empty rate도 포함할 수 있다.
- provider 장애 대응은 fallback, degrade mode, queue 전환, 기능 일시 중단 중 선택해야 한다.
- 보안팀과는 개인정보, prompt injection, tool 권한, MCP server, audit log를 논의한다.
- 인프라팀과는 outbound, secret, rate limit, worker scaling, vector DB, observability 비용을 논의한다.
- 제품팀과는 AI 실패 메시지, 품질 저하 표시, human handoff를 논의한다.
헷갈리는 지점
- AI 기능은 애플리케이션 레벨이므로 인프라팀과 크게 상관없다고 생각하기 쉽다. SDK 호출처럼 보이기 때문이다.
- 핵심은 AI 기능이 외부 API, queue, vector DB, worker, secret, 로그 비용을 만든다는 점이다.
- 인프라 협업 없이는 운영 품질을 보장하기 어렵다.
- 보안은 나중에 붙이면 된다고 생각하기 쉽다. 초기 기능 검증이 급하기 때문이다.
- 핵심은 AI는 데이터 흐름이 복잡해 뒤늦게 보안을 붙이기 어렵다는 점이다.
- 데이터와 권한 경계는 초기에 잡아야 한다.
확인 질문
- 인프라팀이 AI 기능에서 걱정하는 대표 지점은 무엇인가?
- 외부 provider 의존성, latency 변동, rate limit, worker scaling, vector DB, secret, 로그 비용이다.
- 기업 운영에서 AI 기능의 SLO에 포함할 수 있는 AI 특화 지표는 무엇인가?
- validation failure rate, fallback rate, refusal rate, retrieval empty rate, tool error rate다.
드물지만 치명적인 AI 장애 사례
3줄 요약
- AI 장애는 흔한 timeout뿐 아니라 embedding 모델 변경, index 잔존 chunk, prompt cache 붕괴, agent loop 같은 드문 사고도 있다.
- 드문 사고는 한 번 나면 개인정보, 비용, 중복 실행, 권한 사고로 이어질 수 있다.
- 실무자는 가능성이 낮아도 blast radius가 큰 문제를 설계 체크리스트에 넣어야 한다.
핵심 정리
- embedding 모델을 바꾸면 기존 vector index와 의미 공간이 달라져 검색 품질이 무너질 수 있다.
- 문서를 삭제해도 vector index에 chunk가 남으면 권한과 개인정보 사고가 난다.
- retry가 tool calling의 결제, 메일, DB 변경을 중복 실행할 수 있다.
- prompt cache는 프롬프트 앞부분에 동적 값이 섞이면 hit rate가 무너질 수 있다.
- observability 필드가 고카디널리티가 되면 로그와 trace 비용이 폭증한다.
- agent loop에 종료 조건이 없으면 비용과 tool 호출이 계속 증가한다.
헷갈리는 지점
- 드문 문제는 나중에 봐도 된다고 생각하기 쉽다. 당장 재현이 어렵기 때문이다.
- 핵심은 빈도보다 피해 규모를 봐야 한다는 점이다.
- 개인정보와 결제, 권한, 비용 문제는 낮은 확률이어도 초기 설계에 반영한다.
- RAG와 agent는 데모가 잘 되면 운영도 비슷할 것이라고 생각하기 쉽다. 몇 번의 테스트에서는 문제가 안 보이기 때문이다.
- 핵심은 운영 데이터와 사용자 행동은 훨씬 지저분하다는 점이다.
- 삭제, 권한 변경, 오래된 문서, 중복 요청, 중단 상황을 테스트해야 한다.
확인 질문
- embedding 모델 변경이 위험한 이유는 무엇인가?
- 기존 vector와 새 embedding이 같은 의미 공간에 있지 않아 검색 품질이 무너질 수 있기 때문이다.
- 문서 삭제 후 vector index 정리가 중요한 이유는 무엇인가?
- 삭제된 문서 chunk가 남아 권한과 개인정보 유출 사고를 만들 수 있기 때문이다.
AI 기능 리뷰 체크리스트
3줄 요약
- AI 기능 리뷰는 프롬프트만 보는 리뷰가 아니라 데이터, 권한, 비용, 장애, eval, 관측성까지 보는 리뷰다.
- 코드 리뷰에서는 모델 호출 경계, context 조립, output validation, tool side effect, 로그 마스킹을 확인한다.
- 출시 전에는 개인 프로젝트 최소 기준과 기업 운영 기준을 나눠 체크한다.
핵심 정리
- 입력 데이터와 context에 민감정보가 있는지 확인한다.
- 권한 필터가 모델이 아니라 서버에서 강제되는지 확인한다.
- output schema validation과 실패 응답이 있는지 확인한다.
- timeout, retry, rate limit, circuit breaker가 요청 유형에 맞는지 확인한다.
- usage log와 비용 제한이 있는지 확인한다.
- eval dataset과 회귀 기준이 있는지 확인한다.
- tool calling이 있다면 idempotency와 audit log를 확인한다.
헷갈리는 지점
- AI 리뷰는 답변 품질만 보면 된다고 생각하기 쉽다. 사용자가 보는 것이 답변이기 때문이다.
- 핵심은 답변은 파이프라인의 마지막 결과라는 점이다.
- 데이터 흐름과 실패 처리를 함께 봐야 한다.
- 보안 리뷰는 고객-facing 기능에만 필요하다고 생각하기 쉽다. 사내 도구는 내부용이기 때문이다.
- 핵심은 사내 도구가 더 민감한 데이터와 강한 권한을 가질 수 있다는 점이다.
확인 질문
- AI 기능 코드 리뷰에서 반드시 봐야 할 경계는 무엇인가?
- 모델 호출 경계, context 조립 경계, 권한 경계, tool 실행 경계, 로그 경계다.
- tool calling 기능 리뷰에서 가장 중요한 두 가지는 무엇인가?