Files
2nd/10_Wiki/Topics/Architecture/Performance Optimization.md
T

5.1 KiB

Performance Optimization

📌 Brief Summary

성능 최적화(Performance Optimization)는 소프트웨어의 기능적 동작을 동일하게 유지하면서 시간이나 메모리와 같은 자원 사용량을 개선하기 위해 내부 구조를 변경하는 과정입니다 [1-3]. 코드를 더 이해하고 수정하기 쉽게 만드는 리팩토링(Refactoring)과 유사하게 기능은 유지하지만, 구조 개선이 아닌 속도 향상이나 자원 효율성을 주된 목적으로 삼는다는 점에서 구별됩니다 [1, 2, 4]. 성공적인 성능 최적화를 위해서는 이해하기 쉬운 코드로 먼저 리팩토링하여 튜닝하기 좋은 상태를 만드는 것이 필수적인 선행 조건으로 간주됩니다 [5-7].

📖 Core Content

  • 리팩토링과 최적화의 관계: 소프트웨어 개발에서 기능 추가나 버그 수정과 달리, 리팩토링과 최적화는 모두 기존 기능을 불변으로 유지하면서 다른 속성을 변경한다는 공통점을 가집니다 [4]. 리팩토링은 프로그램의 구조(Structure)를 변경하는 반면, 최적화는 자원 사용량(Resource Usage)을 변경합니다 [2, 3].

  • 성능 개선을 위한 3가지 접근 방식 [8-11]:

    1. 시간 예산 할당 (Time Budgeting): 심박조율기처럼 지연된 데이터가 치명적인 하드 실시간(Hard real-time) 시스템에서 주로 사용되며, 각 컴포넌트에 엄격한 시간과 자원 예산을 할당하는 방식입니다 [8].
    2. 지속적 주의 (Constant Attention): 모든 프로그래머가 항상 성능을 높게 유지하기 위해 노력하는 방식이지만, 실제로는 프로그램을 이해하고 수정하기 어렵게 만들어 개발 속도를 늦추기 때문에 효과적이지 않습니다 [9].
    3. 프로파일러 기반 튜닝 (Profiler-Driven Tuning): 대부분의 프로그램은 아주 작은 일부 코드에서 대부분의 시간을 낭비한다는 통계에 기반한 접근입니다 [10]. 성능에 신경 쓰지 않고 구조가 잘 짜인(Well-factored) 프로그램을 먼저 만든 후, 프로파일러를 사용해 시간과 공간을 소비하는 '핫스팟(Hot spots)'을 찾아 집중적으로 최적화합니다 [10, 11].
  • 잘 리팩토링된 코드가 최적화에 미치는 이점: 잘 구조화된 프로그램은 기능 추가 속도를 높여주어 성능 튜닝에 투자할 시간을 더 많이 확보해 줍니다 [6]. 또한, 코드의 의도가 명확하고 구조가 잘게 나누어져 있어 성능 분석 시 더 세밀한 단위(Finer granularity)로 프로파일링하고 튜닝할 수 있는 이점을 제공합니다 [6].

  • 성능 최적화 관련 기법: 기존 알고리즘이 유지보수할 수 없는 성능 병목 지점이 되었을 때 전체 구현을 교체하는 '알고리즘 전환(Substitute Algorithm)' 기법이 사용될 수 있습니다 [12]. 또한, 임시 변수를 질의 함수로 바꾸는 기법(Replace Temp with Query)은 데이터 흐름을 명확히 하여 향후 최적화, 메모이제이션(Memoization) 또는 병렬 실행을 지원하는 토대가 됩니다 [13]. 하드웨어 측면에서는 소프트웨어가 병렬 프로세서나 벡터 유닛의 이점을 취할 수 있도록 조정하는 작업도 포함됩니다 [14].

⚖️ Trade-offs & Caveats

  • 단기적 성능 저하와 장기적 튜닝 용이성의 상충 (Trade-off): 코드를 이해하기 쉽게 만드는 리팩토링 과정은 종종 단기적으로 프로그램의 실행 속도를 느리게 만들 수 있습니다 [5, 7]. 예를 들어, 임시 변수를 제거하는 리팩토링 과정에서 루프가 여러 번 실행되거나 계산이 중복되어 성능 비용을 지불해야 할 수 있습니다 [15, 16]. 그러나 이러한 단기적인 성능 저하를 감수하면 오히려 강력한 최적화 옵션을 발견하기 쉬워지므로 최종적으로는 더 빠른 소프트웨어를 만들 수 있습니다 [7, 17].

  • 최적화로 인한 코드 가독성 저하: 성능을 개선하기 위한 코드 변경은 대개 프로그램의 복잡도를 높이고 코드를 이해하기 어렵게 만듭니다 [1, 9]. 이것이 '지속적 주의' 방식이 오히려 개발을 느리게 만들고 낭비를 초래하는 주된 이유입니다 [9].

  • 추측에 기반한 최적화의 위험성 (Caveat): 성능 최적화 시 가장 주의해야 할 점은 시스템을 잘 안다고 생각하여 병목 지점을 함부로 추측(Speculate)해서는 안 된다는 것입니다 [5, 18]. 경험 많은 개발자의 좋은 아이디어조차 실제 측정 결과와 다를 때가 많으므로, 반드시 프로파일러 도구로 실제 성능을 측정(Measure)한 후 최적화를 진행해야 합니다 [5, 11, 19].

  • AI 도구 활용 시 제약 사항: 성능이 중요한 최적화(Performance-critical optimization) 작업은 복잡성이 매우 높은 작업이므로, AI 코딩 도구를 사용할 경우 오히려 작업 속도를 지연시키거나 방해가 될 수 있습니다 [20, 21]. 따라서 이러한 맥락에서는 AI 지원 없이 전문가의 판단에 의존하는 것이 권장됩니다 [21].


Last updated: 2026-05-03