⚡ 3줄 요약
- AI 기능이 서비스로 넘어가는 순간 모델 선택은 7단계 중 5번째다 — 앞의 네 단계를 건너뛰면 어떤 모델을 붙여도 무너진다.
- RAG도 모델 라우팅도 공짜 정확도가 아니다 — 숫자로 홍보되는 개선폭은 ‘측정 환경의 결과’일 뿐이다.
- 설계의 절반은 정상 흐름이 아니라 실패 흐름이다 — 장애·오답·권한 사고를 어디서 잡을지가 진짜 아키텍처다.
AI 서비스 설계에서 모델 선택은 7단계 중 5번째일 뿐, 앞의 네 단계가 비면 어떤 모델을 붙여도 같은 곳에서 무너진다. AI 기능 하나를 붙이는 코드는 반나절이면 짠다. 문제는 그게 서비스가 되는 순간이다. 응답이 느려지고, 비용이 새고, 그럴듯한 오답이 나가고, 남의 개인정보가 답변에 섞인다. 그런데 대부분은 이 문제를 “더 좋은 모델로 바꾸면 되지 않나”로 해결하려 한다. 순서가 틀렸다. AI 시스템 설계에서 모델을 고르는 건 일곱 단계 중 다섯 번째다. 앞의 네 단계가 비어 있으면 최신 모델을 붙여도 같은 곳에서 터진다.
모델부터 고르는 게 첫 실수다
AI 서비스 설계 면접에서 면접관이 보는 건 “어떤 모델을 부르는가”가 아니라 “그 모델 주변을 어떻게 감쌌는가”다. 실무도 똑같다. kdnuggets가 정리한 7단계 프레임워크는 이 순서를 명확히 못박는다 — 모델 선택은 한참 뒤에 온다.
| 단계 | 무엇을 정하나 | 없으면 깨지는 것 |
|---|---|---|
| 1. 요구사항 확정 | 자료 출처·개인정보 규칙·허용 응답시간·오답 허용범위·최신성 | 비교 기준 자체가 없어 좋아졌는지 판단 불가 |
| 2. 규모 추정 | 요청량(QPS)·컨텍스트·임베딩 양·호출당 비용 | 운영 첫날 비용·지연이 예산을 초과 |
| 3. 아키텍처 스케치 | 입력→안전→오케스트레이터→검색→라우팅→가드레일→스트리밍→관측 | 실패 지점이 어디인지 아무도 모름 |
| 4. 딥다이브 | RAG 전략·프롬프트·캐싱·모델 티어링 중 핵심 하나 | 병목이 방치되어 품질·비용이 요동 |
| 5. 모델·트레이드오프 | 속도 vs 품질, RAG vs 파인튜닝, 비용 상한, 폴백 | 선택의 ‘대가’를 설명 못 함 |
| 6. 실패 모드·관측 | 환각·프롬프트 인젝션·장애·임베딩 드리프트 탐지 | 사고가 나도 감지 못 하고 원인 추적 불가 |
| 7. 진화 | A/B·평가 게이트·피드백 루프·점진적 모델 교체 | 모델을 바꿀 때마다 도박이 됨 |
이 표에서 눈여겨볼 건 모델이 5번째라는 사실이다. 1~4단계는 모델 이름이 한 번도 안 나온다. 여기가 무너지면 GPT든 Claude든 붙여봐야 소용없다.
RAG는 근거를 붙일 뿐, 정확도를 파는 게 아니다
RAG(검색 결합 생성)는 질문에 곧장 답하지 않는다. 먼저 관련 자료를 검색하고, 그 자료를 근거로 답을 만든다. 모델의 기억에만 의존하지 않는다는 게 핵심이다. 구조는 세 부분 — 질문을 검색용 벡터로 바꾸는 인코더, 저장소에서 관련 자료를 뽑는 리트리버, 질문과 검색 결과를 함께 보고 답을 쓰는 제너레이터다. 실제로는 여기에 청킹, 임베딩, 재정렬(rerank), 접근 권한 확인이 더 붙는다.
⚠️ “RAG 하면 환각 40~71% 감소”의 함정
kdnuggets는 “RAG만으로도 환각이 대략 40~71% 줄어든다”고 적는다. 숫자 폭이 40에서 71까지 벌어진다는 것 자체가 측정 환경에 따라 결과가 요동친다는 뜻이다. 어떤 데이터, 어떤 모델, 어떤 업무에서 잰 수치인지 명시되지 않았다. RAG는 ‘근거를 붙이는’ 구조지 ‘정답을 보장하는’ 구조가 아니다. 검색된 자료가 낡았거나, 권한 없는 문서거나, 답변이 그 자료를 제대로 반영 안 했으면 환각은 그대로 남는다.
모델 라우팅 — 비용은 아끼지만 품질을 흔든다
모든 질문에 같은(그리고 대개 비싼) 모델을 쓰는 건 편하지만, 비용과 응답시간의 선택을 숨긴다. 모델 라우팅은 질문 난이도에 따라 싼 모델과 강한 모델을 갈라 보낸다. 반복적인 좁은 질문이라면 굳이 큰 모델이 아니라 작은 전용 모델을 저비용 티어로 두는 편이 낫다. kdnuggets 기준으로 에이전트 요청의 60~80%가 반복적이라, 라우팅으로 40~70%를 절약할 수 있다고 한다. 다만 이 절약률이 모든 서비스에서 재현된다고 일반화하면 안 된다.
싼 모델은 비용을 낮추지만 답변 품질과 응답 형식이 달라질 수 있다. 그래서 라우팅에는 두 가지가 반드시 딸려야 한다 — 난이도를 어떻게 분류할지의 기준, 그리고 분류가 틀렸을 때 더 강한 모델로 넘기는 폴백. 외부 모델 업체의 장애나 용량 부족도 라우팅 설계에 미리 반영해야 한다. 비용을 계산할 때도 모델 사용료만 보면 안 된다. 저장·검색·임베딩 생성·관측·오류 처리까지 다 비용이다.
가드레일은 입력용과 출력용이 따로 있다
가드레일은 입력과 출력이 규칙에 맞는지 검사하는 통제 장치인데, 하나가 아니라 두 겹이다. 이 둘은 하는 일이 완전히 다르다.
| 위치 | 하는 일 | 막는 사고 |
|---|---|---|
| Pre-LLM (입력 전) | 형식 검증, PII(개인식별정보) 마스킹, 프롬프트 인젝션 방어 | 개인정보 유출, 숨겨진 지시로 규칙 우회 |
| Post-LLM (출력 후) | 응답 형식 강제, 거부 정책, 검색 자료와의 사실 대조 | 깨진 형식, 위험 답변, 근거 없는 오답 |
프롬프트 인젝션은 “앞의 지시는 무시해”처럼 시스템 규칙을 벗어나게 유도하는 입력이다. 이건 입력 단계에서 잡아야 한다. 반대로 답변이 검색 자료와 어긋나는지는 출력 단계에서만 확인할 수 있다. 특히 멀티 테넌트 서비스라면 고객별 자료가 섞이지 않는지가 최우선 점검 항목이다 — 검색 권한을 통과한 자료만 제너레이터에 넘겨야 한다. 가드레일을 나열하는 것보다, 실패했을 때 무엇을 차단하고 무엇을 로그로 남길지를 정하는 게 설계다.
좋은 아키텍처는 정상 흐름이 아니라 실패 흐름으로 판별된다
구조도를 그릴 때 대부분 “요청 → 검색 → 모델 → 응답”의 행복한 경로만 그린다. 그건 절반짜리다. 진짜 설계는 어디서 문제가 잡히는가까지 그려야 한다. 기본 처리 흐름은 이렇게 짠다.
| 순서 | 단계 | 실패하면? |
|---|---|---|
| 1 | 요구사항·성공 기준 확인 | — |
| 2 | 요청량·응답시간·저장량·비용 추정 | — |
| 3 | 입력 검증 + 개인정보·안전 처리 | 위험 입력 차단, 로그 기록 |
| 4 | 작업 조정 + 자료 검색 | 검색 실패 시 답변 중단 여부 결정 |
| 5 | 난이도에 맞는 모델 호출 | 모델 장애 시 대체 모델로 폴백 |
| 6 | 응답 형식·근거 자료 확인 | 근거 불일치 시 응답 보류 |
| 7 | 스트리밍 전송 + 상태 기록 | 관측 로그로 사후 추적 |
여기서 관측(observability)은 사치가 아니라 필수다. 엉뚱한 답변, 자료 접근 오류, 외부 업체 장애, 임베딩 드리프트(임베딩 모델이 바뀌며 검색 품질이 조용히 나빠지는 현상), 고객별 자료 혼합 — 이 다섯 가지는 로그가 없으면 사고가 나도 원인을 못 찾는다. 장애 대응도 미리 정해둔다. 모델 호출이 실패하면 대체 모델을 쓸지, 검색이 실패하면 답을 멈출지, 오래된 자료는 어떻게 표시할지를 코드가 아니라 설계 단계에서 결정해야 한다.
선택은 대가로 설명해야 한다 — RAG vs 파인튜닝, 속도 vs 품질
구성요소를 나열하는 것과 “왜 이걸 골랐고 무엇을 포기했는가”를 설명하는 것은 다르다. 대표적인 두 갈림길이 있다.
RAG vs 파인튜닝. RAG는 최신 자료와 접근 권한을 반영하기 쉽지만, 검색 결과와 답변의 연결을 매번 확인해야 한다. 파인튜닝은 특정 업무 방식에 딱 맞출 수 있지만, 자료가 바뀔 때 이를 반영하는 방법을 따로 마련해야 한다. 둘은 우열이 아니라 다른 대가를 치르는 선택이다.
속도 vs 품질. 복잡한 검색과 강한 모델은 품질을 올리지만 지연과 비용을 늘린다. 빠르고 싼 모델은 그 반대다. 정답은 없고, “우리 서비스가 어느 쪽을 더 못 참는가”만 있다. 특히 긴 컨텍스트를 밀어넣을수록 지연이 커지는데, 어텐션이 128K에서 추론 시간의 대부분을 잡아먹는 구조를 알면 이 대가가 왜 생기는지 보인다.
코딩 도구는 이 트레이드오프를 잘 보여준다. 커서 앞뒤의 코드, 열린 파일, 임포트한 모듈, 언어 정보까지 함께 모델에 넘기는 FIM(fill-in-the-middle) 방식은, 앞부분만 보내는 방식보다 수용률이 대략 10% 상대적으로 높다(kdnuggets 기준). 넓은 문맥을 넘기는 대가로 처리량이 늘지만, 그만큼 제안이 더 자주 채택된다는 얘기다. 이렇게 긴 입력을 다루는 밑바탕에는 Transformer가 긴 입력을 우회하도록 설계된 방식이 깔려 있다. 이 역시 특정 제품·환경의 결과로 봐야 한다.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
모델 벤치마크 표를 먼저 여는 팀치고 오래 가는 곳을 못 봤다. 우리라면 순서를 뒤집는다 — 요구사항 한 장 → 규모 추정 → 실패 흐름 → 그다음에야 모델. 모델은 언제든 갈아끼울 수 있는 부품이고, 앞의 세 장이 진짜 자산이다.
숫자 홍보는 전부 ‘조건부’로 읽는다. RAG 40~71%, 라우팅 40~70%, FIM 10% — 전부 누군가의 측정 환경 결과지 우리 서비스의 약속이 아니다. 도입 전 우리 데이터로 다시 재는 평가 게이트를 세우고, 그걸 통과해야만 프로덕션에 올린다. “모델이 좋아졌다”는 한 문장으로 교체하지 않는다.
모델 바꾸기 전, 이 8개 질문에 먼저 답하라
- 답변 근거가 될 자료는 무엇이고, 최신성은 어떻게 확인하나
- 사용자 개인정보를 어디서 마스킹하고 어디서 저장하지 않나
- 쉬운 질문과 어려운 질문을 나누는 기준은 무엇인가
- 허용 응답시간과 예상 요청량을 함께 계산했나
- RAG와 파인튜닝 중 무엇을, 왜 골랐나
- 오답·프롬프트 인젝션·권한 오류를 어디서 탐지하나
- 외부 업체 장애와 검색 실패 때의 폴백 경로가 있나
- 출시 전 평가·프롬프트 비교 실험·점진적 모델 교체 계획이 있나
이 체크리스트는 새 모델을 도입할 때 그대로 재사용한다. 7단계가 모든 AI 시스템의 유일한 정답 순서라고 검증된 건 아니다. 하지만 요구사항을 건너뛰고 해결책부터 고르는 실수를 막는 재사용 가능한 틀로는 충분하다.
출처: kdnuggets 「How to Answer AI System Design Interview Questions」 · 인용 수치는 원문 측정 환경 기준이며 서비스마다 달라질 수 있음
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
