← 프리뷰 목록으로

소프트웨어 성능에 관한 생각들

게시일: 2025년 11월 22일 | 원문 작성일: 2020년 2월 3일 | 저자: Nelson Elhage | 원문 보기

요약

  • 속도는 단순히 ‘더 빠른 것’이 아니라 ‘완전히 다른 사용 방식’을 만들어내요 - 빠른 툴은 완전히 새로운 작업을 가능하게 해요
  • Sorbet과 Livegrep 예시를 통해 성능이 어떻게 개발자의 워크플로우를 바꾸는지 보여줘요
  • 왜 “나중에 최적화하면 돼”가 문제인지 - 아키텍처 결정이 성능을 좌우하고, 나중에 바꾸기 어려워요
  • 빠른 기본 성능은 복잡한 캐싱이나 분산 처리 없이도 간단한 아키텍처를 유지할 수 있게 해줘요

기능으로서의 성능

속도는 그냥 기술 스펙이 아니에요. 사용자 경험 자체를 바꿔요. 빠른 툴은 사용자가 작업을 더 빨리 완료할 수 있게 해주는 게 아니라, 완전히 새로운 작업을 할 수 있게 해줘요.

속도가 사용자 행동을 바꾸는 방식

Stripe의 Sorbet

Sorbet의 빠른 타입 체킹(개별 테스트가 도는 10-20초 안에 완료)은 개발자들이 타입 정확도가 완벽하지 않아도 이걸 주요 피드백 도구로 쓰게 만들었어요. 속도가 핵심 개발 루프의 일부가 된 거죠.

Livegrep의 인터랙티브 검색

Livegrep의 100ms 이하 응답 시간은 검색어를 실시간으로 다듬어갈 수 있게 했어요. 사용자들이 결과를 보면서 바로바로 쿼리를 조정할 수 있었죠. 이런 사용 패턴은 느린 검색 툴에서는 거의 나타나지 않아요. 속도 차이가 완전히 다른 워크플로우를 만든 거죠.

”나중에 최적화하면 돼”의 한계

흔히들 이렇게 말하죠: “시기상조 최적화는 모든 악의 근원”이고 “데이터가 생기면 나중에 최적화하면 된다”고요. 하지만 이 접근법엔 큰 문제가 있어요:

1. 아키텍처의 영향

기본적인 디자인 선택이 성능에 큰 영향을 미쳐요. Sorbet이 로컬에서만 타입 추론하는 방식은 속도를 위한 의도적인 아키텍처 결정이었어요. 나중에 아키텍처를 바꾸는 건 엄청 비싸고, 완전 재작성이 필요할 수도 있어요.

2. 분산된 성능 비용

명확한 핫스팟이 있는 시스템과 달리, 성능 개선은 종종 “코드 곳곳을 조금씩 빠르게 만드는 것”에서 나와요. SQLite 3.8.7은 수많은 1% 미만의 개별 개선을 통해 50% 속도 향상을 달성했어요. 프로파일링해서 최적화할 수 있는 은탄환 같은 건 없어요. 시스템 전체를 개선해야 하는 문제죠.

속도를 통한 단순성

빠른 기본 성능은 아키텍처 복잡성을 줄여줘요:

  • 느린 시스템은 정교한 캐싱이 필요해요
  • 느린 시스템을 분산 처리로 해결하려면 운영 오버헤드가 추가돼요
  • 점진적으로 계산하는 레이어는 복잡성을 배가시켜요

Sorbet의 탄탄한 기본 성능은 MyPy 같은 느린 타입 체커에 비해 더 간단한 캐시 포맷과 배포 전략을 가능하게 했어요.

오늘날의 상황

프레임워크, 추상화, 의존성 때문에 시스템이 점점 느려지는 추세지만, 2020년에도 빠른 시스템은 충분히 만들 수 있고 투자할 가치가 있어요.

결론

결국 성능은 단순히 “더 빠른 것”이 아니라 “새로운 사용 방식”이에요. 속도가 가져오는 파급 효과는 사용자 행동, 워크플로우 패턴, 시스템 아키텍처에 영향을 미쳐요. 이런 효과들이 직접적인 속도 개선보다 더 중요할 때가 많아요.

저자 소개: Nelson Elhage는 소프트웨어 엔지니어이자 인프라 전문가로, Stripe에서 개발자 도구와 시스템 설계 작업을 해왔어요.

참고: 이 글은 Nelson Elhage가 자신의 블로그에 게시한 아티클을 번역하고 요약한 것입니다.

원문: Reflections on software performance - Nelson Elhage, blog.nelhage.com (2020년 2월 3일)

생성: Claude (Anthropic)

총괄: (디노이저denoiser)