시스템 디자인 (System design) 인터뷰가 변화하고 있습니다.

“Twitter 디자인하기”, “Uber 디자인하기”, “YouTube 디자인하기”와 같은 전통적인 질문들은 여전히 중요합니다. 이러한 질문들은 여러분이 데이터베이스 (Databases), 캐싱 (Caching), 파티셔닝 (Partitioning), 복제 (Replication), 메시징 (Messaging), 그리고 고가용성 (High availability)을 이해하고 있는지 테스트합니다.

하지만 현대적인 플랫폼에서 근무하는 엔지니어들은 이제 다른 범주의 문제들에 직면하고 있습니다:

• ChatGPT와 같은 대화형 어시스턴트 디자인하기.
• 검색 증강 생성 (RAG, Retrieval-Augmented Generation) 시스템 디자인하기.
• LLM 추론 (Inference) 플랫폼 디자인하기.
• 외부 도구를 호출할 수 있는 AI 에이전트 (Agent) 디자인하기.
• 개인 문서를 위한 기업용 AI 어시스턴트 디자인하기.
• 생성형 AI 애플리케이션을 위한 평가 (Evaluation) 플랫폼 디자인하기.

이러한 질문들은 여전히 고전적인 분산 시스템 (Distributed-systems) 지식을 요구합니다. AI 제품에는 API, 큐 (Queues), 스토리지 (Storage), 인증 (Authentication), 관찰 가능성 (Observability), 속도 제한 (Rate limiting), 그리고 신뢰할 수 있는 배포 (Deployment)가 필요합니다.

차이점은 고가의 가속기 (Accelerators), 확률적 출력 (Probabilistic output), 장시간 실행되는 요청 (Long-running requests), 모델 라우팅 (Model routing), 벡터 검색 (Vector retrieval), 프롬프트 구성 (Prompt construction), 안전 제어 (Safety controls), 그리고 품질 평가 (Quality evaluation)가 추가된다는 점입니다.

이 가이드는 가장 중요한 AI 시스템 디자인 인터뷰 질문들과, 각 질문에 대해 유능한 후보자가 논의해야 할 사항들을 설명합니다.

전통적인 문제와 현대적인 문제를 모두 다루는 더 넓은 준비 로드맵을 보려면, 64 System Design Interview Questions, Ranked From Easiest to Hardest를 참조하세요.

AI 시스템 디자인이 다른 이유

전통적인 서비스는 보통 입력을 결정론적 출력 (Deterministic output)으로 변환합니다.

만약 사용자가 주문 번호 123을 요청하면, 서비스는 주문 123을 조회해야 합니다. 두 개의 동일한 요청은 보통 동일한 기초 정보를 반환해야 합니다.

생성형 AI (Generative AI) 시스템은 다르게 동작합니다.

하나의 모델은 동일한 프롬프트(Prompt)에 대해 서로 다른 응답을 생성할 수 있습니다. 응답은 문법적으로는 설득력이 있지만 사실 관계는 틀릴 수 있습니다. 지연 시간(Latency)은 생성된 토큰(Token)의 수에 따라 달라집니다. 서비스 용량(Serving capacity)은 단순히 CPU 사용량이 아니라 가속기 메모리(Accelerator memory)에 의해 제한됩니다. 제품의 품질은 프롬프트, 검색된 컨텍스트(Retrieved context), 모델 버전, 안전 필터(Safety filters) 및 외부 도구(External tools)에 따라 달라질 수 있습니다.

이는 몇 가지 새로운 설계 차원(Design dimensions)을 만들어냅니다.

1. 품질은 아키텍처의 일부입니다

전통적인 시스템은 흔히 가용성(Availability), 지연 시간(Latency), 처리량(Throughput), 오류율(Error rate)을 사용하여 측정됩니다.

AI 시스템도 이러한 지표가 필요하지만, 다음과 같은 측정 지표도 필요합니다:

• 답변 정확도 (Answer correctness)
• 관련성 (Relevance)
• 근거성 (Groundedness)
• 검색 품질 (Retrieval quality)
• 환각률 (Hallucination rate)
• 도구 사용 성공률 (Tool-use success)
• 안전 정책 준수 (Safety-policy compliance)
• 사용자 만족도 (User satisfaction)

200밀리초(ms) 만에 응답을 반환하는 시스템이라도 그 응답이 틀렸다면 유용하지 않습니다.

2. 요청은 계산 비용이 많이 듭니다

일반적인 API 서버는 초당 수천 개의 가벼운 요청을 처리할 수 있습니다.

LLM 요청은 긴 프롬프트를 처리하고 수백 개의 토큰을 생성하는 동안 값비싼 GPU 메모리를 점유할 수 있습니다. 따라서 아키텍처는 배치(Batching), 메모리 활용(Memory utilization), 모델 배치(Model placement) 및 요청 스케줄링(Request scheduling)을 최적화해야 합니다.

3. 지연 시간은 스트림(Stream) 형태로 경험됩니다

사용자는 보통 아무것도 보지 못한 채 전체 답변이 나올 때까지 기다리지 않습니다. 토큰은 생성되는 대로 스트리밍됩니다.

이는 적어도 두 가지 중요한 지연 시간 측정 항목을 도입합니다:

• 첫 번째 토큰까지의 시간 (Time to first token): 생성이 얼마나 빨리 시작되는가.
• 토큰 간 지연 시간 (Inter-token latency): 후속 토큰들이 얼마나 매끄럽게 도착하는가.

시스템의 전체 지연 시간은 허용 가능한 수준이더라도, 첫 번째 토큰이 나오는 데 너무 오래 걸린다면 여전히 느리게 느껴질 수 있습니다.

4. 데이터는 여러 방식으로 시스템에 유입됩니다

AI 애플리케이션은 다음과 같은 요소에 의존할 수 있습니다:

• 모델 학습 데이터 (Model-training data)
• 사용자 프롬프트 (User prompts)
• 대화 기록 (Conversation history)
• 검색된 문서 (Retrieved documents)
• 도구 결과 (Tool results)
• 피드백 (Feedback)
• 평가 데이터셋 (Evaluation datasets)
• 안전 정책 (Safety policies)

각 데이터 유형은 보존(retention), 개인정보 보호(privacy), 최신성(freshness) 및 일관성(consistency)에 대해 서로 다른 요구 사항을 가집니다.

5. 실패는 항상 이분법적이지 않습니다

전통적인 요청은 성공하거나 실패할 수 있습니다.

AI 요청은 기술적으로는 성공할 수 있지만, 저품질의 답변을 생성하거나, 잘못된 문서를 검색하거나, 잘못된 도구(tool)를 호출하거나, 비용 예산을 초과하거나, 안전 규칙을 위반할 수 있습니다.

아키텍처는 이러한 소프트한 실패 모드(softer failure modes)를 감지하고 대응할 수 있어야 합니다.

모든 AI 시스템 디자인 질문에 답하기 위한 프레임워크

개별 질문을 고려하기 전에, 일관된 인터뷰 구조를 사용하십시오.

1단계: 제품 명확화 (Clarify the product)

시스템이 무엇을 수행해야 하는지 질문하십시오.

예를 들어:

• 어시스턴트가 범용(general-purpose)인가요, 아니면 특정 도메인 특화(domain-specific)인가요?
• 기업의 비공개 데이터(private enterprise data)가 필요한가요?
• 동작(actions)을 수행할 수 있나요, 아니면 답변만 제공하나요?
• 텍스트만 지원하나요, 아니면 이미지, 오디오, 파일도 지원하나요?
• 응답이 실시간(real time)으로 이루어져야 하나요?
• 시스템에 인용(citations)이 필요한가요?
• 어떤 결정에 인간의 승인(human approval)이 필요한가요?

이러한 명확화 과정이 없다면, “AI 어시스턴트를 설계하라”는 질문은 너무 광범위합니다.

2단계: 규모 및 서비스 수준 목표 정의 (Define scale and service-level objectives)

다음 사항을 추정하십시오:

• 일일 및 피크 시간대 요청 수
• 평균 프롬프트(prompt) 크기
• 평균 출력 길이
• 동시 사용자 수
• 첫 번째 토큰 생성에 필요한 시간 (Time to first token)
• 모델 크기
• GPU 메모리 요구 사항
• 가용성 목표 (Availability target)
• 요청당 비용

AI 시스템은 기술적 역량만큼이나 비용에 의해 제약을 받는 경우가 많습니다.

3단계: 애플리케이션 계층과 모델 계층 분리 (Separate the application layer from the model layer)

애플리케이션 계층(application layer)에는 다음이 포함될 수 있습니다:

• 인증 (Authentication)
• 결제 (Billing)
• 대화 기록 (Conversation history)
• 파일 관리 (File management)
• 사용자 설정 (User preferences)
• 속도 제한 (Rate limiting)
• 분석 (Analytics)

AI 계층(AI layer)에는 다음이 포함될 수 있습니다:

• 프롬프트 구성 (Prompt construction)
• 검색 (Retrieval)
• 모델 라우팅 (Model routing)
• 추론 스케줄링 (Inference scheduling)
• 안전 점검 (Safety checks)
• 도구 실행 (Tool execution)
• 평가 (Evaluation)

이러한 관심사들을 분리해 두면 설계를 설명하고 발전시키기가 더 쉬워집니다.

4단계: 전체 요청 경로 추적 (Trace the complete request path)

사용자가 프롬프트 (Prompt)를 제출하는 순간부터 최종 결과가 표시될 때까지 어떤 일이 발생하는지 설명하세요.

전형적인 경로는 다음과 같을 수 있습니다:

1. 요청 인증 (Authenticate the request).
2. 할당량 적용 (Enforce quotas).
3. 대화 상태 로드 (Load conversation state).
4. 관련 컨텍스트 검색 (Retrieve relevant context).
5. 모델 프롬프트 구성 (Construct the model prompt).
6. 입력 안전성 검사 실행 (Run input-safety checks).
7. 모델 선택 (Select a model).
8. 추론 스케줄링 (Schedule inference).
9. 토큰 스트리밍 (Stream tokens).
10. 출력 안전성 검사 실행 (Run output-safety checks).
11. 응답 저장 (Store the response).
12. 메트릭 및 피드백 기록 (Record metrics and feedback).

5단계: 실패, 품질 및 비용 논의 (Discuss failure, quality, and cost)

훌륭한 답변은 다음 사항들을 설명해야 합니다:

• 기본 모델 (Primary model)에 과부하가 걸리면 어떻게 되는가?
• 검색 (Retrieval) 결과 유용한 문서가 반환되지 않으면 어떻게 되는가?
• 중복된 도구 호출 (Tool calls)을 어떻게 방지하는가?
• 시스템이 어떻게 우아하게 성능 저하 (Degrade gracefully)를 처리하는가?
• 모델 변경 사항을 어떻게 평가하는가?
• 테넌트 데이터 (Tenant data)를 어떻게 격리하는가?
• 비용이 많이 드는 요청을 어떻게 제어하는가?

이러한 논의는 데모 (Demo)와 프로덕션 (Production) 설계를 구분 짓는 요소입니다.

질문 1: ChatGPT 설계하기 (Design ChatGPT)

ChatGPT와 유사한 시스템은 가장 포괄적인 AI 시스템 디자인 질문 중 하나입니다.

기능적 요구사항 (Functional requirements)에는 다음이 포함될 수 있습니다:

• 대화 시작
• 프롬프트 전송
• 스트리밍 응답 수신
• 대화 기록 보기
• 답변 재생성
• 파일 업로드
• 모델 간 선택
• 무료 및 유료 사용 제한 적용

유용한 상위 수준 아키텍처 (High-level architecture)는 다음과 같은 구성 요소를 포함합니다.

API 게이트웨이 (API gateway)

게이트웨이는 인증, 요청 라우팅 (Request routing), 속도 제한 (Rate limiting), 할당량 (Quotas) 및 기본 유효성 검사를 처리합니다.

실행 시간이 긴 생성 요청은 Server-Sent Events (SSE) 또는 WebSockets를 사용하여 클라이언트에 토큰을 스트리밍할 수 있습니다.

대화 서비스 (Conversation service)

이 서비스는 다음을 관리합니다:

• 대화 (Conversations)
• 메시지 (Messages)
• 사용자 설정 (User preferences)
• 메시지 순서 (Message ordering)
• 대화 제목 (Conversation titles)
• 보존 및 삭제 (Retention and deletion)

대화 메타데이터 (Metadata)는 트랜잭션 데이터베이스 (Transactional database)에 저장할 수 있으며, 대용량 첨부 파일은 객체 스토리지 (Object storage)에 배치할 수 있습니다.

컨텍스트 빌더 (Context builder)

모델은 유한한 컨텍스트 윈도우 (Context window)를 가집니다. 컨텍스트 빌더 (Context builder)는 다음 요청에 어떤 정보가 포함되어야 하는지를 결정합니다.

다음 항목들을 조합할 수 있습니다:

• 시스템 프롬프트 (System prompt)
• 최근 대화 메시지
• 오래된 메시지의 요약본
• 검색된 문서 (Retrieved documents)
• 사용자 선호도 (User preferences)
• 도구 출력값 (Tool outputs)

전체 대화 내용을 영원히 그대로 보내는 것은 비용이 많이 들며 결국 불가능해집니다. 오래된 콘텐츠는 요약하거나 선택적으로 검색 (Selective retrieval)해야 할 수도 있습니다.

모델 게이트웨이 (Model gateway)

모델 게이트웨이는 여러 모델 백엔드 (Model backends)에 대한 단일 인터페이스를 제공합니다.

다음 기준에 따라 요청을 라우팅 (Route)할 수 있습니다:

• 작업 유형 (Task type)
• 요구되는 품질
• 사용자 구독 정보
• 컨텍스트 길이
• 지연 시간 목표 (Latency target)
• 현재 수용 능력 (Current capacity)
• 비용 예산
• 모델 가용성

단순한 요청은 더 작고 빠른 모델을 사용할 수 있는 반면, 복잡한 추론 (Reasoning)은 더 유능한 모델로 라우팅될 수 있습니다.

추론 스케줄러 (Inference scheduler)

스케줄러는 가속기 (Accelerators)에서 실행되는 모델 복제본 (Model replicas)에 요청을 할당합니다.

다음 사항들을 고려해야 합니다:

• 사용 가능한 GPU 메모리
• 모델 배치 (Model placement)
• 프롬프트 길이
• 출력 토큰 예산 (Output-token budget)
• 우선순위
• 배치 호환성 (Batch compatibility)
• 테넌트 할당량 (Tenant quotas)

단순한 선입선출 (First-in, first-out) 스케줄러는 몇 개의 매우 긴 프롬프트로 인해 많은 수의 짧은 요청이 지연되는 상황을 초래할 수 있습니다.

스트리밍 레이어 (Streaming layer)

생성된 토큰은 사용자에게 점진적으로 전달되어야 합니다.

시스템은 또한 다음 사항들을 처리해야 합니다:

• 클라이언트 연결 끊김
• 사용자 취소
• 부분 응답 (Partial responses)
• 네트워크 재시도
• 생성 중 모더레이션 (Moderation)
• 스트리밍 완료 후 최종 영속화 (Final persistence)

안전 레이어 (Safety layer)

입력 및 출력 정책은 다음을 탐지할 수 있습니다:

• 프롬프트 인젝션 (Prompt injection)
• 민감한 정보
• 허용되지 않는 요청
• 악성 파일
• 안전하지 않은 도구 지침
• 데이터 유출

안전은 마지막에 배치된 하나의 필터로 취급되어서는 안 됩니다. 검색 전, 도구 실행 전, 추론 전, 그리고 최종 응답을 반환하기 전 등 다양한 단계에서 서로 다른 검사가 필요할 수 있습니다.

중요한 심층 질문 (Important deep dives)

면접관은 다음과 같이 질문할 수 있습니다:

• 첫 번째 토큰 생성 시간 (Time to first token)을 어떻게 줄이겠습니까?
• 1억 명의 사용자를 어떻게 지원하겠습니까?
• 한 테넌트 (Tenant)가 모든 GPU 용량을 점유하는 것을 어떻게 방지하겠습니까?
• 긴 대화를 어떻게 요약하겠습니까?
• 여러 모델 사이에서 어떻게 라우팅 (Routing)을 수행하겠습니까?
• GPU 부족 상황에서 가용성 (Availability)을 어떻게 유지하겠습니까?
• 무료 사용자의 비용을 어떻게 제한하겠습니까?

Design ChatGPT walkthrough는 이 문제에 대한 구조화된 예시를 제공합니다.

질문 2: RAG 시스템 설계

검색 증강 생성 (Retrieval-augmented generation, RAG)은 모델이 외부 소스에서 검색된 정보를 사용하여 답변할 수 있도록 합니다.

일반적인 면접 질문은 다음과 같습니다:

내부 문서를 사용하여 직원의 질문에 답하고 인용 (Citations)을 제공하는 기업용 어시스턴트를 설계하십시오.

RAG 시스템에는 두 가지 주요 경로가 있습니다:

1. 인제스션 경로 (The ingestion path)
2. 쿼리 경로 (The query path)

인제스션 경로 (The ingestion path)

문서는 파일 업로드, 내부 위키 (Wikis), 클라우드 드라이브, 데이터베이스 또는 지원 시스템에서 가져올 수 있습니다.

인제스션 파이프라인 (Ingestion pipeline)은 여러 단계를 수행합니다.

문서 추출 (Document extraction)

파일은 사용 가능한 텍스트로 변환되어야 합니다.

시스템에는 다음과 같은 항목을 위한 파서 (Parsers)가 필요할 수 있습니다:

• PDF
• Word 문서
• 프레젠테이션
• HTML 페이지
• 스프레드시트
• 스캔된 이미지

추출 프로세스는 제목, 헤딩 (Headings), 페이지 번호, 소유자 및 액세스 권한과 같은 유용한 메타데이터 (Metadata)를 보존해야 합니다.

청킹 (Chunking)

긴 문서는 더 작은 세그먼트 (Segments)로 나뉩니다.

너무 큰 청크 (Chunks)는 관련 없는 텍스트를 포함할 수 있고 과도한 컨텍스트 (Context)를 소비할 수 있습니다. 너무 작은 청크는 의미를 잃을 수 있습니다.

가능한 전략에는 다음이 포함됩니다:

• 고정 토큰 윈도우 (Fixed token windows)
• 단락 기반 청킹 (Paragraph-based chunking)
• 헤딩 인식 청킹 (Heading-aware chunking)
• 중첩 윈도우 (Overlapping windows)
• 의미론적 청킹 (Semantic chunking)

보편적으로 정답인 청크 크기는 없습니다. 대표적인 질문들을 대상으로 테스트를 거쳐야 합니다.

임베딩 생성 (Embedding generation)

각 청크는 임베딩 모델 (Embedding model)을 사용하여 수치 벡터 (Numerical vector)로 변환됩니다.

모델을 변경하면 전체 코퍼스 (Corpus)를 다시 임베딩 (Re-embedding)해야 할 수도 있으므로, 임베딩 서비스는 버전 관리 (Versioning)가 되어야 합니다.

인덱싱 (Indexing)

시스템은 다음 항목들을 저장합니다:

• 임베딩 (Embeddings)
• 원문 텍스트 (Original text)
• 문서 메타데이터 (Document metadata)
• 접근 제어 정보 (Access-control information)
• 소스 위치 (Source location)
• 임베딩 버전 (Embedding version)
• 업데이트 타임스탬프 (Update timestamp)

벡터 인덱스 (Vector index)는 의미론적 검색 (Semantic retrieval)을 가능하게 합니다. 전통적인 역색인 (Inverted index)은 키워드 검색 (Keyword retrieval)을 지원할 수 있습니다. 많은 프로덕션 시스템 (Production systems)은 이 두 가지를 결합하여 사용합니다.

쿼리 경로 (The query path)

사용자가 질문을 제출하면 다음과 같은 과정을 거칩니다:

1. 사용자 인증 (Authenticate the user).
2. 쿼리에 대한 임베딩 (Embedding) 생성.
3. 후보 청크 (Candidate chunks) 검색.
4. 접근 제어 필터링 (Access-control filtering) 적용.
5. 후보군 재순위화 (Rerank).
6. 최적의 컨텍스트 (Context) 선택.
7. 프롬프트 (Prompt) 구성.
8. 답변 생성.
9. 인용 (Citations) 첨부.
10. 결과 평가 또는 로그 기록.

하이브리드 검색 (Hybrid retrieval)

의미론적 검색 (Semantic retrieval)은 쿼리와 소스가 유사한 의미를 가졌지만 서로 다른 단어를 사용할 때 유용합니다.

키워드 검색 (Keyword retrieval)은 다음과 같은 정확한 용어에 유용합니다:

• 제품 코드 (Product codes)
• 에러 메시지 (Error messages)
• 이름 (Names)
• 날짜 (Dates)
• 식별자 (Identifiers)