이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제한된 연산 자원에서 알고리즘을 최적화할 때 가장 먼저 한 것은 프로파일링으로 실제 병목을 확인하는 것이었습니다. 추측으로 최적화하면 영향이 적은 곳을 개선하느라 시간을 낭비하기 때문에, 실측 데이터를 먼저 보는 습관이 중요합니다.
알고리즘 복잡도 개선이 가장 효과적이었습니다. O(n²) 연산을 O(n log n)으로 바꾸는 것만으로 입력 크기가 커질수록 차이가 극적으로 커졌습니다. 라이브러리 교체보다 알고리즘 선택이 성능에 더 큰 영향을 준다는 것을 직접 확인했습니다.
메모리 접근 패턴도 성능에 영향을 줬습니다. 캐시 친화적인 순서로 데이터를 접근하도록 구조를 바꾸니 행렬 연산 속도가 눈에 띄게 올랐습니다. 하드웨어 특성을 이해하면 코드 변경 없이도 성능 개선이 가능하다는 것을 배웠습니다.
제한된 연산 자원에서 최적화할 때 정확도와 연산량 사이의 트레이드오프를 명확히 인식해야 한다는 것을 배웠습니다. 처리 속도를 높이기 위해 정밀도를 낮춘 근사 계산을 적용했는데, 대부분의 경우에는 차이가 없었지만 경계 값 근처에서 결과가 달라지는 경우가 있었습니다. 이 트레이드오프를 애플리케이션 요구사항에 맞게 문서화해두지 않으면 나중에 왜 이렇게 구현했는지 설명하기 어려워지는 것을 경험했습니다. 룩업 테이블로 반복 계산을 줄이는 방식도 사용했는데, 테이블이 커지면 오히려 메모리 접근 비용이 연산 비용보다 커지는 역전 현상이 생겼습니다. 특정 하드웨어에서 효과적인 최적화가 다른 환경에서는 효과가 없거나 역효과를 내는 경우도 있었습니다. 최적화 코드는 어떤 하드웨어와 입력 조건에서 테스트했는지를 함께 기록해두지 않으면 다른 환경으로 이식할 때 문제가 생긴다는 것을 이 경험에서 배웠습니다.
제한된 연산 자원 환경에서 부동소수점 연산을 줄이는 것이 성능에 큰 영향을 준다는 것을 배웠습니다. 부동소수점 연산 유닛이 없는 환경에서 소수 계산이 필요한 경우, 정수 연산으로 대체하는 고정소수점 방식을 공부해서 적용해봤습니다. 0.5를 곱하는 연산을 2로 나누는 비트 연산으로 바꾸니 연산 속도가 달라졌습니다. 최적화 효과를 확인하기 위해 내장 타이머를 사용해 최적화 전후 실행 시간을 직접 측정했는데, 추측으로 효과가 있을 것 같다는 것과 실측으로 확인하는 것은 다르다는 것을 이 과정에서 배웠습니다. 반복 계산이 많은 구간에서는 미리 계산된 값을 배열에 저장해두고 조회하는 방식을 적용했는데, 계산 횟수는 줄었지만 배열 크기가 커지면 메모리 한계에 걸리는 것도 경험했습니다. 자원이 제한된 환경에서 최적화는 한 자원을 아끼면 다른 자원이 늘어나는 구조를 의식하면서 진행해야 한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.