알고리즘, 과연 사용할 일이 없을까요?
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
웹 개발
대상자
- *프론트엔드 개발자 (캔버스 기반 텍스트 에디터 성능 최적화 필요자) / 초보 알고리즘 학습자** (실무 적용 사례 이해)
핵심 요약
canvas.measureText()
API를 활용한 텍스트 너비 측정 로직에서 선형 탐색(O(n)) → 파라메트릭 서치(O(log n))으로 성능 최적화- 50%의 응답 시간 개선(102.53ms → 56.41ms)을 달성한 실무 성능 향상 사례
- 캐싱 복잡성과 동적 스타일 변경으로 인한 캐싱 비용 > 계산 성능 향상의 이점으로 직접 계산이 유리한 결정
섹션별 세부 요약
1. 초기 선형 탐색 방식의 문제점
canvas.measureText()
API를 통해 텍스트 너비 계산- 한 글자씩 탐색 → O(n) 시간복잡도로 긴 텍스트 입력 시 성능 저하
- 사용자 VOC: 스타일 변경 시 버벅거림, 긴 텍스트 입력 지연
2. 파라메트릭 서치 도입
- 이분 탐색과 파라메트릭 서치의 차이점
- "주어진 너비 내 최대 텍스트 길이" 찾기 → 조건 충족 시 오른쪽 절반 탐색, 초과 시 왼쪽 절반 탐색
findLineBreakPoint()
함수 구현 예시:
```javascript
function findLineBreakPoint(text, maxWidth) {
let left = 0, right = text.length, result = 0;
while (left <= right) {
const mid = Math.floor((left + right)/2);
const width = canvas.measureText(text.substring(0, mid)).width;
if (width <= maxWidth) {
result = mid;
left = mid + 1;
} else {
right = mid - 1;
}
}
return result;
}
```
3. 성능 측정 결과
- 50%의 응답 시간 개선 (102.53ms → 56.41ms)
- 시간복잡도 O(n) → O(log n) 개선
- 긴 텍스트일수록 성능 차이 극명
4. 캐싱의 한계
- 다양한 변수(폰트 스타일, 회전 각도, 레이아웃 등)로 인한 캐시 키 관리 복잡성
- 캐시 무효화 타이밍 관리 및 메모리 누수 위험성
- 직접 계산이 캐싱 로직 구현 비용보다 유리
결론
- 알고리즘은 코딩테스트 용도가 아닌 실무 성능 최적화에 핵심적 → 파라메트릭 서치 적용으로 50% 성능 향상
- 동적 환경에서는 캐싱 대신 O(log n) 계산이 더 효과적
- "작은 최적화"라도 사용자 경험에 직접적 영향을 미침