Post

알고리즘·자료구조: 시스템 설계에서의 최소 요구선

DS/Algo를 설계 선택의 언어로 쓰는 법과 색인·랭킹에 필요한 최소 개념 정리

알고리즘·자료구조: 시스템 설계에서의 최소 요구선

왜 시스템 설계에서 DS/Algo가 점수로 연결되는가

결론: 면접에서 알고리즘은 ‘정답을 맞히는 기술’이 아니라 ‘설계 선택을 정당화하는 언어’다.

  • 왜(문제): 대규모 시스템의 병목은 대부분 데이터 접근 방식에서 발생한다.
  • 무엇(개념): 자료구조는 성능 특성(시간/공간/갱신 비용)을 고정하는 설계 부품이다.
  • 어떻게(설계/선택): 인덱스, 캐시, 검색, 랭킹, 그래프 모델링의 지점에서 최소한으로 호출한다.
  • 트레이드오프: 범용성·정확성·구현 단순성 중 일부를 포기한다.
  • 인터뷰 문장: “이 문제는 알고리즘 문제가 아니라 데이터 접근 패턴 문제입니다.”

Linked List / Hash / Tree / Graph가 등장하는 지점

결론: 자료구조는 ‘그 자체’가 아니라 ‘역할’로 등장한다.

DS설계에서의 역할대표 상황
Linked List순서 유지/연결LRU 캐시
HashO(1) 접근캐시 키, 중복 제거
Tree범위/정렬인덱스, 타임라인
Graph관계 탐색소셜, 추천
  • 함정: “이 문제는 Hash로 풀립니다” 식의 코테 언어.
  • 체크리스트:

    • 접근 패턴은 단건인가, 범위인가, 탐색인가?
  • 인터뷰 문장: “접근 패턴상 해시가 가장 단순합니다.”

검색 vs 전문 검색

결론: ‘검색’은 LIKE가 아니라 색인 전략의 문제다.

  • 왜: 텍스트 검색은 전체 스캔이 불가능하다.
  • 무엇: Inverted Index는 단어→문서 매핑이다.
  • 어떻게: 토큰화 → 색인 → 스코어링 → 랭킹.
  • 트레이드오프: 색인 비용 vs 쿼리 속도.
  • 인터뷰 문장: “전문 검색은 RDB 인덱스로 대체할 수 없습니다.”

랭킹/스코어링 직관

  • 빈도(TF), 희소성(IDF), 최신성 가중치
  • 수식 설명 최소, “어떤 신호를 쓰는가”만 말한다.

Top-K / 랭킹 도구 선택

결론: Top-K는 정확도보다 ‘언제 근사해도 되는가’의 문제다.

도구언제 쓰나버리는 것
Heap정확 Top-K메모리
Sort소량 데이터시간
Count-Min Sketch대규모 스트림정확성
Redis ZSET실시간 랭킹비용
  • 인터뷰 문장: “정확도가 덜 중요해 근사치를 허용합니다.”

“라이브러리로 대체 가능”의 안전선

결론: 라이브러리를 쓰겠다는 말은 ‘문제 분해’를 한 뒤에만 안전하다.

  • 허용 기준:
    1. 내부 원리를 한 문장으로 설명 가능
    2. 성능 특성(시간/공간) 언급 가능
    3. 대안 1개 제시 가능
  • 금지: “Redis가 다 해줍니다.”
  • 인터뷰 문장: “내부적으로는 해시+트리 구조입니다.”

예시 1: URL Shortener 키 생성(토이)

결론: 충돌은 알고리즘 문제가 아니라 확률·운영 문제다.

  • 선택: 랜덤 키 + Hash 저장
  • 충돌 대응: 재시도
  • 버린 것: 순차성
  • 인터뷰 문장: “충돌 확률은 낮고, 재시도로 흡수합니다.”

예시 2: 검색 엔진 색인/쿼리(실무형)

결론: 검색 성능은 쿼리 이전에 색인에서 결정된다.

  • 색인: Inverted Index
  • 쿼리: 토큰 병합 → 스코어링 → Top-K
  • 버린 것: 실시간 정확성
  • 인터뷰 문장: “색인 비용을 감수해 조회를 빠르게 합니다.”

설계 요소별 DS/Algo 연결 맵

결론: 자주 나오는 연결만 기억하면 충분하다.

설계 요소DS/Algo
캐시Hash + List
인덱스B-Tree
랭킹Heap/ZSET
피드Tree/Heap
관계Graph

흔한 실수 5개 + 교정

  1. 코테식 설명 → 설계 맥락으로 전환
  2. 수식 과다 → 신호 설명으로 대체
  3. DS 나열 → 선택 이유 강조
  4. 라이브러리 남발 → 내부 원리 언급
  5. 정확도 집착 → 근사 허용 조건 설명

면접에서 바로 쓰는 답변 문장 템플릿 8개

  1. “접근 패턴이 핵심입니다.”
  2. “이 지점에서 O(1)이 필요합니다.”
  3. “범위 조회 때문에 트리를 씁니다.”
  4. “정확도보다 속도를 택합니다.”
  5. “근사 알고리즘을 허용합니다.”
  6. “색인 비용을 감수합니다.”
  7. “라이브러리 내부는 이 구조입니다.”
  8. “이 선택으로 메모리를 포기합니다.”

핵심 체크리스트 12개

  1. 접근 패턴 정의
  2. 읽기/쓰기 비율
  3. 정렬/범위 여부
  4. 정확도 요구
  5. 근사 허용 여부
  6. 메모리 한계
  7. 색인 비용
  8. 업데이트 빈도
  9. 랭킹 필요성
  10. 관계 탐색
  11. 라이브러리 대체 가능성
  12. 버린 선택 언급

면접에서 DS/Algo 질문이 나왔을 때 답변 구조

결론: 구조를 고정하면 코테 질문도 설계 점수로 바뀐다.

  1. 문제를 설계 요소로 재정의
  2. 접근 패턴 설명
  3. DS/Algo 선택
  4. 성능 특성 언급
  5. 버린 대안 말하기

30분 복기 플랜(타이머 기준)

  • 0–5분: DS 역할 표
  • 5–10분: 검색 vs 전문 검색
  • 10–15분: Top-K 도구 선택
  • 15–20분: 라이브러리 안전선
  • 20–25분: URL Shortener 설명
  • 25–30분: 검색 엔진 흐름 말하기

한 줄 요약

시스템 설계에서 알고리즘은 문제를 푸는 기술이 아니라, 선택을 설명하는 최소 언어다.


This post is licensed under CC BY 4.0 by the author.