Huawei 면접 질문

Huawei 면접의 초점

일반적인 Huawei 면접 질문

• 반복 문자 없이 가장 긴 부분 문자열을 찾는 함수를 구현하세요.
  좋은 답변이 다루는 것

  • 슬라이딩 윈도우 기법을 사용해 O(n) 시간 복잡도 달성
  • 해시맵(또는 배열)으로 각 문자의 마지막 위치 저장
  • 윈도우 시작점을 중복 문자 발견 시 해당 문자 다음 위치로 이동
  • 최대 길이는 윈도우의 크기로 갱신

  샘플 답변 보기

  이 문제는 'Longest Substring Without Repeating Characters'로 유명하며, 슬라이딩 윈도우와 해시맵을 조합해 O(n) 시간에 해결할 수 있습니다. 먼저 left 포인터가 윈도우의 시작, right 포인터가 끝을 가리키며, 해시맵에 각 문자의 최근 인덱스를 저장합니다. right를 이동하면서 현재 문자가 이미 해시맵에 있고, 그 인덱스가 left보다 크거나 같으면 left를 그 인덱스+1로 이동시켜 중복을 제거합니다. 이후 현재 윈도우 길이(right - left + 1)로 최대 길이를 갱신합니다. 주의할 점은 해시맵의 갱신 시점과 left 이동 조건을 정확히 처리해야 합니다. 이 알고리즘은 입력 문자열의 길이에 선형적으로 동작하며, 사용된 문자 집합이 제한적일 경우 배열을 사용해 더 빠르게 구현할 수 있습니다.

  def length_of_longest_substring(s: str) -> int:
      # 해시맵: 문자 -> 마지막 인덱스
      char_map = {}
      left = 0
      max_len = 0
  
      for right, ch in enumerate(s):
          # 중복 문자가 윈도우 안에 있으면 left 이동
          if ch in char_map and char_map[ch] >= left:
              left = char_map[ch] + 1
          # 현재 문자 위치 저장
          char_map[ch] = right
          # 최대 길이 갱신
          max_len = max(max_len, right - left + 1)
  
      return max_len
  
  # 시간 복잡도: O(n), 공간 복잡도: O(min(n, m)) (m은 문자 집합 크기)

• TCP와 UDP의 차이점을 설명하세요. 각각을 언제 사용하시겠습니까?
  좋은 답변이 다루는 것

  • TCP는 연결 지향적이며 신뢰성 있는 전송을 보장하고, UDP는 비연결형으로 빠르지만 신뢰성이 낮음
  • TCP는 흐름 제어, 혼잡 제어, 오류 검출 및 재전송을 제공하지만 UDP는 이러한 기능이 없음
  • TCP는 순서 보장, UDP는 순서 보장하지 않음 (패킷 손실 가능)
  • TCP는 파일 전송, 웹 브라우징처럼 신뢰성이 중요한 경우; UDP는 실시간 스트리밍, DNS, 게임처럼 지연에 민감한 경우 사용

  샘플 답변 보기

  TCP(Transmission Control Protocol)는 연결 설정(3-way handshake) 후 데이터를 전송하며, 패킷 손실 시 재전송하고 순서를 보장합니다. 반면 UDP(User Datagram Protocol)는 연결 없이 데이터를 바로 보내고, 수신 확인이나 재전송을 하지 않으므로 빠르지만 신뢰성이 낮습니다. 예를 들어 파일 다운로드나 이메일처럼 데이터 정확성이 필수인 경우 TCP를 사용하고, 화상 통화나 온라인 게임처럼 지연이 큰 영향을 미치는 경우 UDP가 적합합니다. 다만 최근 QUIC 같은 프로토콜이 UDP 위에서 신뢰성을 제공하기도 합니다. 선택 시 트레이드오프를 고려해야 합니다: TCP는 오버헤드가 크고 지연이 발생하기 쉬우며, UDP는 패킷 손실이나 순서 뒤바뀜이 발생할 수 있습니다.

• HDFS와 같은 분산 파일 스토리지 시스템을 어떻게 설계하시겠습니까?
  좋은 답변이 다루는 것

  • 분산 파일 스토리지는 네임노드(마스터)와 데이터노드(워커)로 구성된 마스터-슬레이브 아키텍처 채택
  • 파일을 블록(기본 64MB 또는 128MB)으로 나누고 복제 팩터(기본 3)만큼 데이터노드에 분산 저장
  • 네임노드는 메타데이터(파일-블록 매핑)를 관리하고, 데이터노드는 실제 데이터 저장 및 읽기/쓰기 처리
  • 내고장성(Fault-tolerance)을 위해 블록 복제와 하트비트를 사용하며, 장애 시 자동 복구

  샘플 답변 보기

  HDFS와 같은 시스템을 설계할 때 주요 요구사항은 대용량 파일 저장, 높은 처리량, 내고장성, 확장성입니다. 기본 아키텍처는 단일 네임노드(마스터)와 여러 데이터노드(슬레이브)로 구성됩니다. 파일은 고정 크기 블록으로 분할되며, 각 블록은 여러 데이터노드에 복제됩니다(기본 3개). 네임노드는 파일 시스템 네임스페이스와 블록 위치 정보를 메모리에 유지하고, 데이터노드는 주기적으로 하트비트와 블록 리포트를 보냅니다. 읽기 요청 시 클라이언트는 네임노드에서 블록 위치를 받아 가장 가까운 데이터노드에서 직접 읽습니다. 쓰기 요청 시 네임노드는 블록을 할당하고, 클라이언트는 파이프라인 방식으로 데이터를 복제합니다. 확장을 위해 네임노드에 페더레이션(여러 네임노드)을 도입하거나, 데이터노드를 수평 확장합니다. 성능 최적화를 위해 데이터 지역성(data locality)을 활용해 계산을 데이터가 있는 곳에서 처리합니다. (예: MapReduce) 주의할 점은 네임노드가 단일 장애점(SPOF)이므로 고가용성(HA) 구성을 위해 액티브-스탠바이 네임노드와 저널 노드를 사용합니다.

• 팀원과 갈등이 있었던 경험에 대해 말씀해 주세요. 어떻게 해결했습니까?
  좋은 답변이 다루는 것

  • STAR 기법: 상황(Situation), 과제(Task), 행동(Action), 결과(Result)로 구조화
  • 갈등의 원인을 객관적으로 파악하고 감정을 배제
  • 적극적 경청과 공감을 통해 상대방의 입장을 이해
  • 데이터와 사실에 기반해 해결 방안을 제시하고 합의 도출

  샘플 답변 보기

  저는 이전 프로젝트에서 한 팀원과 API 설계 방식을 두고 갈등을 겪은 경험이 있습니다. 당시 저는 RESTful 규칙을 따라 엔드포인트를 여러 개로 나누자는 의견이었고, 상대방은 단일 엔드포인트에 동작을 파라미터로 전달하는 방식을 주장했습니다. 저는 먼저 상대방의 의견을 경청하며 그의 접근 방식이 명확성은 떨어지지만 구현이 빠르다는 장점을 인정했습니다. 그 후 각 방식의 장단점을 비교한 간단한 문서를 작성해 팀 리뷰를 요청했습니다. 결국 팀 회의에서 두 방식의 트레이드오프를 논의한 후, 확장성과 유지보수를 고려해 RESTful 방식을 채택했지만, 상대방의 의견을 반영해 일부 엔드포인트에서 단축 경로를 제공했습니다. 결과적으로 갈등은 해결되었고, 이후에도 서로를 존중하며 협업할 수 있었습니다. 이 경험을 통해 갈등 해결의 핵심은 승패가 아닌 최선의 결과를 향한 협력임을 배웠습니다.

• 연결 리스트를 반복 및 재귀 방식으로 뒤집는 코드를 작성하세요.
  좋은 답변이 다루는 것

  • 반복 방식: 세 개의 포인터(prev, current, next)를 사용해 링크 방향을 바꾸며 순회
  • 재귀 방식: base case는 null 또는 단일 노드, 그 외에는 재귀 호출 후 현재 노드의 next를 이전 노드로 변경
  • 반복은 O(n) 시간, O(1) 공간; 재귀는 O(n) 시간, O(n) 공간(콜 스택)
  • 재귀 구현 시 스택 오버플로우 가능성 주의

  샘플 답변 보기

  연결 리스트를 뒤집는 작업은 기본적인 포인터 조작 문제입니다. 반복 방식은 prev, curr, next 세 포인터를 사용합니다. 처음에 prev를 None, curr를 head로 설정하고, curr가 None이 될 때까지 next에 curr.next를 저장한 후 curr.next를 prev로 변경, prev를 curr로, curr를 next로 이동합니다. 재귀 방식은 먼저 base case로 head가 None이거나 head.next가 None이면 head를 반환합니다. 그 외에는 head.next를 재귀 호출한 결과를 new_head에 저장한 후, head.next.next를 head로 설정하고 head.next를 None으로 만든 후 new_head를 반환합니다. 반복 방식은 공간 효율이 좋고, 재귀 방식은 코드가 간결하지만 노드 수가 많을 경우 스택 오버플로우 위험이 있습니다. 실제 환경에서는 반복 방식을 선호합니다.

  class ListNode:
      def __init__(self, val=0, next=None):
          self.val = val
          self.next = next
  
  # 반복 방식
  def reverse_list_iterative(head: ListNode) -> ListNode:
      prev, curr = None, head
      while curr:
          next_temp = curr.next
          curr.next = prev
          prev = curr
          curr = next_temp
      return prev
  
  # 재귀 방식
  def reverse_list_recursive(head: ListNode) -> ListNode:
      if not head or not head.next:
          return head
      new_head = reverse_list_recursive(head.next)
      head.next.next = head
      head.next = None
      return new_head
  
  # 시간 복잡도: O(n), 공간 복잡도: 반복 O(1), 재귀 O(n)

• 관계형 데이터베이스 인덱스는 어떻게 작동합니까? B-트리와 해시 인덱스를 설명하세요.
  좋은 답변이 다루는 것

  • 인덱스는 테이블의 컬럼 값과 해당 레코드의 물리적 위치를 매핑하는 자료 구조
  • B-트리 인덱스는 균형 잡힌 트리로, 범위 검색, 정렬, LIKE 패턴 등에 효율적
  • 해시 인덱스는 키-값 쌍으로 저장되어 동등 비교(=, IN)에 빠르지만 범위 검색에는 부적합
  • B-트리는 디스크 기반 시스템에 최적화되어 한 노드가 여러 키를 저장하고 페이지 단위로 접근

  샘플 답변 보기

  관계형 데이터베이스에서 인덱스는 검색 성능을 높이기 위한 별도의 저장 구조입니다. B-트리 인덱스는 가장 널리 사용되며, 루트에서 리프까지의 깊이가 동일한 균형 트리입니다. 각 노드는 여러 키와 자식 포인터를 가지며, 리프 노드는 실제 데이터의 위치(행 ID)를 가리킵니다. B-트리는 범위 검색(BETWEEN, >, <), 정렬(ORDER BY), 접두사 LIKE 패턴에서 뛰어난 성능을 보입니다. 반면 해시 인덱스는 해시 함수로 계산한 버킷에 키-값 쌍을 저장합니다. 동등 조건(=, IN)에서는 O(1)에 가까운 매우 빠른 속도를 제공하지만, 범위 검색이나 정렬에는 사용할 수 없습니다. 또한 해시 충돌이 발생할 수 있습니다. 일반적으로 InnoDB는 B+트리(리프 노드가 연결 리스트)를 사용하며, 메모리 기반 시스템에서는 해시 인덱스가 유용합니다. 인덱스 선택 시 쿼리 패턴을 고려해야 하며, 쓰기 성능 저하와 저장 공간 증가를 트레이드오프해야 합니다.

• WhatsApp과 같은 실시간 채팅 시스템을 설계하세요. 아키텍처, 데이터 저장소, 확장을 논의하세요.
  좋은 답변이 다루는 것

  • 실시간 채팅 시스템은 메시지 전달을 위해 WebSocket 같은 지속적 연결 사용
  • 아키텍처: 로드 밸런서 -> 채팅 서버(수평 확장) -> 메시지 큐(Kafka) -> 분산 DB(Cassandra) + 캐시(Redis)
  • 메시지 저장은 시계열 데이터로 파티셔닝하고, 읽기/쓰기 최적화를 위해 별도 DB 사용
  • 확장성: 서버는 stateless하게 설계하고, 상태 정보(세션)는 Redis에 저장; 채팅방 단위로 샤딩

  샘플 답변 보기

  WhatsApp 같은 실시간 채팅 시스템을 설계할 때 핵심 요구사항은 낮은 지연, 높은 가용성, 확장성입니다. 먼저 클라이언트는 WebSocket을 통해 채팅 서버와 지속적인 연결을 유지합니다. 로드 밸런서가 여러 채팅 서버로 트래픽을 분산하고, 각 서버는 메모리에 사용자 세션을 관리하지만, 장애를 대비해 Redis에 세션 정보를 저장해 stateless하게 만듭니다. 메시지 전송 시 발신자의 서버가 메시지를 Kafka 같은 메시지 큐에 발행하고, Kafka Consumer가 메시지를 수신자에게 푸시하고 동시에 DB에 저장합니다. 데이터 저장소는 Cassandra 같은 시계열 친화적인 NoSQL을 사용해 메시지를 채팅방별, 시간순으로 저장합니다. (Partition key: chat_id, Clustering key: timestamp) 또한 사용자 온라인 상태는 Redis를 사용해 빠르게 조회합니다. 확장성을 위해 채팅 서버는 무상태로 설계해 수평 확장이 쉽고, Kafka는 파티션을 늘려 처리량을 높입니다. 채팅방이 극도로 인기가 많을 경우 샤딩을 고려합니다. (예: 채팅방 ID의 해시로 서버 분산) 또한 메시지 전달 보장을 위해 at-least-once 전달과 중복 제거가 필요합니다. 전체적으로 지연 최소화를 위해 캐싱과 비동기 처리를 적극 활용합니다.

• 주도했던 도전적인 프로젝트에 대해 설명하세요. 당신의 역할과 결과는 무엇이었습니까?
  좋은 답변이 다루는 것

  • STAR 기법 사용: 프로젝트 배경, 나의 역할, 구체적 행동, 측정 가능한 결과
  • 주도적인 태도와 문제 해결 능력을 강조
  • 팀워크와 커뮤니케이션을 통해 어려움 극복
  • 결과가 비즈니스나 팀에 미친 긍정적 영향 제시

  샘플 답변 보기

  제가 주도했던 가장 도전적인 프로젝트는 대규모 레거시 시스템을 마이크로서비스 아키텍처로 전환하는 것이었습니다. 상황은 5년 된 모놀리틱 애플리케이션이었으며, 배포 주기가 느리고 장애 전파가 심각했습니다. 저는 프로젝트 리더로서 전체 마이그레이션 로드맵을 수립하고, 도메인 주도 설계(DDD)를 적용해 서비스 경계를 정의했습니다. 가장 큰 도전은 기존 데이터베이스를 서비스별로 분할하는 작업이었는데, 저는 점진적 마이그레이션 전략(Strangler Fig 패턴)을 제안해 리스크를 최소화했습니다. 또한 이벤트 소싱과 CQRS를 도입해 데이터 일관성을 유지했습니다. 팀원들과 주간 스프린트를 진행하며 지속적으로 피드백을 반영했고, 기술 부채를 해소하기 위해 리팩토링을 병행했습니다. 결과적으로 배포 주기를 2주에서 하루로 단축했고, 장애 발생 시 영향 범위가 70% 감소했습니다. 또한 서비스별 독립적 확장이 가능해져 트래픽 증가에도 안정적으로 대응할 수 있었습니다. 이 프로젝트를 통해 변화 관리와 기술적 의사 결정의 중요성을 깊이 이해하게 되었습니다.

준비 팁

• 자료 구조, 알고리즘, OS, 네트워킹 등 컴퓨터 과학 기초 주제를 철저히 복습하세요.
• 구문 강조 없이 화이트보드나 일반 텍스트 편집기에서 코딩 연습을 하세요.
• 시스템 설계의 경우 분산 데이터베이스, 로드 밸런서, 캐싱과 같은 대규모 시스템을 공부하세요.
• 역경 극복이나 빡빡한 마감 기한 아래에서 일한 구체적인 예를 준비하여 회복력을 보여주세요.
• Huawei의 기업 문화와 가치, 특히 '늑대 정신'과 고객 성공에 대한 헌신을 연구하세요.

자주 묻는 질문