DEVOCEAN

앱 실행부터 LLM까지, 에이닷 v4.0 성능 측정과 SLO 수립 리얼 스토리

🤔 "이 앱 빠른가요?" - 대답하기 참 어려운 질문

새 앱 버전을 출시하기 전, 가장 많이 받는 질문입니다.

"이번 버전 성능은 어때요?""빠른가요?""앱이 너무 느린 것 같은데요."

음... 🤷‍♀️

앱이 "빠르다"는 게 정확히 뭘까요? 앱이 켜지는 속도? 화면이 바뀌는 속도? AI가 답변하는 속도? 그리고 어느 정도 빨라야 "빠른 앱"이라고 할 수 있을까요?

그리고 똑같은 2초라도 상황에 따라 체감이 완전히 달라요. 화면이 전환되는 2초와 콘텐츠가 로딩되는 2초는 사용자가 느끼는 답답함의 정도가 다르잖아요.

그렇다면 앱의 빠르기는 어떻게 답하면 좋을까요.

이번에 에이닷 v4.0 성능 검증을 진행하며 앱의 "빠르다" 기준을 한번 만들어보기로 했습니다. 🚀

🗣️ '성능 언어' 만들기

모든 걸 "빠르다/느리다"로 뭉뚱그리지 않기로 했습니다. 에이닷 앱은 다양한 기능이 있어서 하나의 잣대로 논하기엔 무리가 있죠.

사용자가 체감하는 "빠름"의 기준을 바탕으로 유형을 정의하고, 같은 유형이라도 기술적 특성이 달라 성능 차이가 발생할 수밖에 없는 경우를 따로 반영했습니다.

📚 성능 용어 사전

🤖 LLM/AI 전용 지표 (스트리밍 UX용)

스트리밍으로 답변이 조금씩 나타나는 AI 기능은 "시작-진행-완료"의 3단계로 나누었습니다.

이렇게 쪼개니까 "빨리 시작해서, 제대로 끝내는" 기능의 성능을 구분해서 파악할 수 있게 되었습니다! 🎉

📊 성능 '기준' 정의하기: 근거 있는 목표 설정

성능을 숫자로 기준을 정한다는 건 참 어려운 일입니다.

앱 성능은 결국 사용자 체감이 기준인데, 사람마다 성능에 대한 생각도 빠르기 체감 기준도 모두 다르거든요.

게다가 기술이 발전하면서 사용자의 성능 기대 수준도 점점 올라가고 있어서 과거의 기준이 지금도 적용될 수 있다고 말하기 어렵기도 합니다.

그래도 최대한 객관성을 확보하기 위해 UX 성능 연구 자료와 업계 가이드라인, 유사 앱 벤치마킹을 통해 각 유형별 성능 기준을 정의했습니다.

🎯 성능 등급 기준표

🛠️ 현장에서 마주친 리얼 이슈들

🤯 이슈 1: WebView는 다른 생명체다

처음엔 모든 화면 전환을 NAV 1초 기준으로 잡았어요. 그런데...

❌ WebView 전환: 평균 2.8초 → "느려요!" 😱
✅ 네이티브 전환: 평균 0.6초 → "빨라요!" 😊

WebView는 HTML/CSS/JS를 다운로드하고 렌더링해야 해서 구조적으로 시간이 더 필요해요. 같은 잣대를 들이대면 개발팀이 "달성 불가능한 목표"와 싸우게 됩니다.

WebView가 적용된 다른 앱들의 성능을 벤치마킹한 결과, NAV.W = NAV + 2초 기준을 도입하기로 했습니다. 🎯

📏 NAV (네이티브): ≤ 1초
📏 NAV.W (WebView): ≤ 3초 (NAV + 2초 조정)

결과: 숏컷 → 검색 화면 전환이 Issue에서 Good으로 재평가!

💡 핵심: "같은 UX 목표"를 포기하는 게 아니라, 기술 특성을 반영한 공정한 목표를 세우는 일

⏰ 이슈 2: 1시간 반짜리 측정의 딜레마

노트 생성 기능 중에 1회 측정에 1시간 30분이 걸리는 항목이 있었습니다.

⏰ 10회 반복 측정시: 15시간 소요 예상
🧪 측정 중 이슈가 있다면 + 5시간 더 고려 필요
👨‍💼 "기능 하나에 2일+a이면 앱 전체 검증 기간이..."😅

측정 비용 vs 효용을 고려해서 이런 초장시간 작업은 이번 검증에서 제외하고, 노트 심층 성능 개선이 필요할 때 별도로 상세 검증을 진행하기로 결정했습니다.

🎭 이슈 3: 백그라운드 작업도 기준이 필요할까?

"오래 걸리는 작업은 백그라운드에서 처리하니까 성능 기준이 필요 없지 않을까?"

🔄 앱: 백그라운드에서 처리중...
😰 사용자: 내 요청이 처리되고 있는 거야? 오류인가? 불안해...

🙅‍♀️비동기 작업이더라도 작업이 지연되면 사용자가 "요청이 제대로 처리되고 있는 건가?"하는 불안감을 느낄 수 있습니다.

비동기 작업도 일정 시간 안에 결과가 와야 "정상 동작"으로 인식한다고 하죠.

그래서 작업 크기별 성능 기준을 분리하고, 비동기 작업도 적절한 완료 시간과 진행 상태를 사용자가 인지할 수 있도록 기준을 마련했습니다.

🧪 성능 측정 현장 체크리스트

⚙️ 사전 준비 (실패 방지용)

• PRD 스토어 빌드 사용 (실제 사용자 환경과 동일)

• LTE 고정 (WiFi 속도 변동 방지)

• 절전/배터리 최적화 해제 (성능 제한 방지)

• 화면 밝기·테마·글자 크기 고정 (GPU/렌더링 부하 일정화)

• 캐시 클리어 후 Cold Start 준비 (정확한 최초 실행 시간 확보)

🏃‍♀️ 진행 중 (신뢰성 확보용)

• 기기 온도 모니터링 (과열로 인한 성능 저하 방지)

• 네트워크 안정성 체크 (일시적 지연 방지)

• 측정자 고정 (동작 숙련도 영향 최소화)

📊 데이터 품질 관리

• 10회 반복 측정 (통계적 신뢰성 확보)

• 아웃라이어 처리 (GC, 백그라운드 간섭 등 제거)

• 측정 구간 재검토 (외부 변동 요인 배제)

🎯 이상치(Outlier) 처리 정책

• 📏 기본: 산출값에서 제외

• ⚠️ 30% 이상 발생시: 환경 리셋 → 재측정

• 🔄 재측정에도 재현 불가: 일시적 요인으로 분류

💡 실제 사례: 앱 실행에서 4.51초, 2.59초 아웃라이어 2건 발생 → 재측정 10회에서 재현 안됨 → "GC나 백그라운드 간섭" 추정하고 제외

🎓 성능 검증을 통해 배운 것들

1️⃣ "정의가 성능을 만든다"

측정 대상을 분류하고 구간을 명확히 정의하니까 "빠르다/느리다"를 객관적으로 판단할 수 있게 되었어요. 무엇을 어떻게 측정할지가 결과를 좌우합니다.

2️⃣ "하나의 잣대로 모든 걸 재면 안 된다"

네이티브와 WebView, 스트리밍 UX, 비동기 작업은 각각 다른 특성과 기준이 필요합니다.

3️⃣ "숫자보다 중요한 건 맥락"

22초 걸리는 작업도 사용자에게 "진행 중"이라는 신호를 0.3초에 준다면 기다릴 수 있습니다.

4️⃣ "필요하다면 기다릴 수 있다"

기능 특성상 고품질 결과를 위해 시간이 더 필요하다면, 해당 특성에 맞춘 별도 품질 목표 설정이 필요합니다.

5️⃣ "일시적으로 느려질 수도 있다"

평소엔 빠르더라도 시스템 자원이나 환경적 요인(GC, 백그라운드 앱, 네트워크 지연, 디스크 I/O 등)으로 일시적 성능 저하가 발생할 수 있습니다. 이런 경우 잠시 후 재시도하거나 기기 상태 점검이 필요하다고 안내하는 방법도 고려해봅니다.

📈 최종 성과: 숫자로 보는 앱 성능

🏆 성과 요약

81.5%가 목표 달성! 🎉 핵심 흐름의 UX는 건강한 상태예요.

🔮 다음 라운드: 더 현실적인 성능 측정으로

🌍 실사용자 데이터 수집 (RUM)

Firebase 기반으로 실제 사용자 환경에서의 성능 트레이스를 수집해서 "실험실 vs 현실"의 간극을 좁힐 예정이에요.

🔍 세밀한 병목 분석

PathFinder, Spectra 등을 활용해서 대화방 레이턴시를 단계별로 분석하여 정확한 개선 포인트를 찾을 계획입니다.

🎬 마무리: 성능은 결국 사용자 경험이다

성능 검증은 단순히 "얼마나 빨리"의 문제가 아니에요. 사용자가 언제 안심하고, 언제까지 기다릴 수 있는지를 이해하는 일이죠.

이번에 구축한 유형별 기준 + 체계적 측정 절차 + 근거 있는 기준 조정 프레임워크는 앞으로도 계속 발전시켜 나갈 예정이에요.

💝 마지막 한마디: "무조건 빠른 앱"보다는 **"기다릴 만한 가치가 있는 앱"**을 만들고 싶어요.

📚 참고 자료

UX 성능 연구

• Jakob Nielsen의 반응 속도 3단계 이론

• Google UX Playbook

• Material Design: Performance

플랫폼 가이드라인

• Google Android Performance Guidance

• Apple App Performance Metrics

• Android Performance Measuring

성능 측정 리포트

• Firebase Performance Monitoring

• MoldStud Hybrid App Development