레거시 유지보수와 최적화 및 데이터

2025년 1월, 원티드 프리온보딩 챌린지의 프론트엔드 2주차 강의를 간략하게 정리한 내용입니다.

 

유지보수에 쓰이는 시간을 줄이기

내용에 들어가기 전, '리팩토링 원칙'에 대해 알고 있습니까?

리팩토링을 하는 이유는 '성능' 또는 '품질'이다.

 

에릭 에반스는 네 가지의 코드 품질 규칙을 생성했다.

• 인터페이스는 단순하게 구현하고, 함수와 모듈을 추출하기
• 테스트 코드를 짜고 코드 동작을 확인하기
• 가능하면 이름을 명확하게 짓기
• 가능하면 기능은 애매하지 않게 명확한 하나의 기능으로 구현하기

 

최소한의 리팩토링 규칙을 만드는 것이 좋다. 처음부터 빽빽하게 코드를 작성하면 영원히 끝나지 않게 될 것이다.

• 코드 중복 피하기
• 하나의 함수는 하나의 일만 하는 단일 책임 지키기
• 비슷한 기능을 가졌다면 한 곳에 모아두기
• 간단하게 짜기

 

아마 실제 구현을 한다면, 간단한 예시로 아래와 같을 것이다.

1. API 호출하는 모듈 생성
2. User와 관련된 비즈니스 로직을 분리해 Service로 묶기
3. 상황 별로 분리 (에러가 있을 때 / 성공했을 때)

 

프론트엔드 최적화

최적화는 어디서부터 시작해야 할까? 어느 타이밍에 시도해야 할까?

 

여기서 '최적화'는 '성능 향상'과 '사용자 경험 개선' 그리고 '비용 절감'을 도모하는 것이다.

대체로 많이 하는 것은 아래와 같다.

• 코드 분할
• 캐싱
• 이미지 최적화
• 로딩 최적화 (로딩 속도 개선)
• 등등

 

여기서 무엇을 먼저 할 지보다 개선을 왜 해야하는지를 먼저 생각해야 한다.

최적화를 왜 해야 할까? 제대로 돌아가는 프로젝트에 최적화가 필요하다는 것은 잘 돌아가는 것 외로 더 필요한 무언가, 즉 개선점이 생겼다는 의미이다.

 

보통 필요해지는 것은 'SEO', '비용 절감', '사용성 개선'이다.

그러나, 최적화는 필요해서 하지만, 프론트엔드 혼자서 할 수 있는 최적화는 한계가 존재한다.

 

'SEO'의 경우, 마케팅 전략이 짜여지고, 전략에 맞춘 컨텐츠가 나오고, 그 컨텐츠를 잘 읽어갈 수 있도록 최적화를 해야한다.

`비용 절감`의 경우, 인프라부터 시작해 미디어 사이즈를 줄이거나, 요청 수를 줄이거나, 번들 사이즈를 줄여야 한다.

'사용자 개선'의 경우, 기획이나 디자인, PO가 어떤 데이터를 확인하고, 불편을 발견했을 때, 동선을 재설계하고 새로운 동선으로 수정해야 한다.

 

 

그렇다면, 최적화의 작업 종류는 무엇들이 있을까?

 

최적화 작업 종류

최적화 작업을 구분하자면, 두 가지로 나눌 수 있다.

• 돈을 쓰는 것
• 돈을 아끼는 것

 

'비용을 늘릴 수 있는 최적화'는 사용성을 올리거나 장기적인 유지보수 개선을 위해서 하는 작업이다. 초기비용이 발생하지만, 장기적으로 좋거나, DX를 위해 어느정도 비용을 감수해도 괜찮을 때 시도한다.

• 이미지 최적화: 이미지를 webP/AVIF로 변환 | 이미지 리사이징 → 여러 비용 발생
• SSR: SEO에 도움 | 최초 로딩 속도 개선 → 서버 인프라 비용 발생
• 사용성 및 데이터 관련 작업: 애니메이션, 인터렉션, 클라이언트 내 데이터 재검증(Revalidation, Refetch. API 재요청), FWA, 마케팅 툴 삽입

 

'비용을 줄이는 최적화'는 사용성을 올리거나 장기적인 유지보수 개선을 위해서 하는 작업은 비용을 늘릴 수 있기 때문에 이와 반대되어 비용을 줄일 수 있는 방법으로 최적화를 진행하는 것이다.

• 캐싱: 서버 요청 감소 → 서버 비용 절감
• Lazy Loading: 초기 로드에서 불필요한 자원을 로딩하지 않기 → 비용 절감
• 번들 사이즈 줄이기: Tree Shaking, CSS, JavaScript 압축 등 번들 사이즈 줄이기 → 비용 절감

 

무조건 하는 최적화가 있을까? 그렇다면, 무엇일까?

비용을 절감할 수 있고, 프론트엔드 파트만 있어도 할 수 있는 작업이라면 무조건 최적화를 시도해보자.

 

중요한 것은 '사이즈 줄이기'가 가장 중요하다. 프론트엔드 코드는 정적 자원으로 사이즈가 줄면 비용도 줄어들고, 다운로드 속도도 빨라진다. 즉, '비용'을 줄이고, '속도'도 빠르게 만들기 위해 자원의 크기를 줄이는 것을 우선적으로 진행해보자.

 

최적화 방법

'webpagetest'로 최적화를 시작해보자. (부분 유료)

 

이 서비스의 작업 순서는 진단(측정)을 하고, 작업하고, 다시 진단(측정)을 하는 과정을 원하는 수준에 도달할 때까지 무한으로 반복한다.

 

그렇다면, 무엇을 측정할까? 보통 확인하는 지표는 'LCP', 'CLS', 'FID'이다. 그러나, 최근에는 'FID'보다 'INP'를 더 많이 보고 있다.

 

LCP

가장 큰 컨텐츠가 화면에 나타나는 시간을 말한다. 예로 들면, 홈 화면에 큰 배너가 있다.

주요 텍스트나 이미지 렌더링 기준으로 2.5초 이내를 권장하고 있다.

 

CLS

페이지 레이아웃이 얼마나 흔들렸는지 측정한다. 또는 중간 로딩 등으로 컨텐츠 위치가 움직였는지를 확인한다. 예로 들면, 어떤 페이지에 접속했을 때, 먼저 보였던 텍스트가 나중에 나타나는 이미지로 인해 하단으로 갑자기 이동하는 경우가 해당한다.

 

시각적인 안정성을 평가하며, 0.1 이내를 권장한다.

 

INP

사용자 인터렉션 후 컨텐츠 업데이트 시간을 확인하는 측정 단계이다. 예로 들면, 사용자가 어떤 버튼을 눌렀을 때, 반응하는 시간이 해당된다.

 

스크롤, 클릭 등 반응성을 평가하며, 200밀리초 이내를 권장한다. 이 때, 400밀리초가 넘어가면 느리다고 판단한다.

 

FID

사용자가 최초 인터렉션(클릭 등) 후 브라우저가 해당 이벤트 처리를 시작하는 데 걸리는 시간을 측정한다.

 

페이지 로드 중 최초 인터렉션만 측정하며, 100밀리초 이내 권장한다.

 

'FID'는 초기 페이지 반응을 보고, 'INP'는 전체 인터렉션 반응을 본다. 전체적인 사용자 경험을 보는 쪽이 좋은 것이니, 최근에는 'FID'보다 'INP'를 보고 있다. 쉽게 설명하면, 보통 설정하는 캐싱 기능까지 측정에 포함하기 위해서는 'INP'가 적합하다는 이야기이다.

 

확인해보기

로컬 환경에서 개발자 도구를 통해 확인해볼 수 있다. 예를 들면, 'Lighthouse'를 통해서 말이다.

실제로 확인하기 위해서 'webpagetest' 페이지에 접속해서 측정해서 확인해보는 게 좋다. devTool로 보는 대부분의 데이터는 랩 데이터로, 랩 데이터보다 럼 데이터를 보는 게 더 좋다.

 

개선 방법

CLP만을 위한, INP만을 위한 개선은 없다. 하나를 고쳐나가면 다 같이 개선되는 경우가 많기 때문이다.

그렇다면, 어떤 방법을 활용해 개선해 나가는 게 좋을까?

 

1. HTML 마크업 잘 사용하기
2. Skeleton 잘 잡아두기
3. 번들 사이즈 줄이기

 

특히, 'HTML 마크업'을 잘 사용하는 게 중요하다. `div 태그`만 사용했다면, 이를 멈추고, HTML 마크업을 학습하여 수정해보자.

이 때, 각 태그 요소가 브라우저마다 최적화가 잘 되어 있는지 확인하기 위해 아래의 페이지를 활용할 수 있다.

 

Can I use... Support tables for HTML5, CSS3, etc

 

혹시, 본인의 `package`의 라이브러리가 버전만 다르게 중복되어 사용되고 있다면, 그리고 이를 최적화하고 싶다면 아래의 명령어를 실행해보자.

npm dedupe

 

그러나, 위의 명령어를 사용하기 전에 알아두어야 할 점은 라이브러리 충돌이 발생할 수 있어, 프로젝트에 문제가 발생할 수 있다. 그러니, 이를 잘 생각해서 사용해야 한다.

 

다음으로, 만약 '라이브러리'의 사이즈가 궁금하다면, 아래의 사이트에 접속해서 라이브러리를 검색해 사이즈를 확인해보자.

 

Bundlephobia | Size of npm dependencies

 

라이브러리의 사이즈가 낮은 것을 사용하는 것이 좋으며, 많이 알려져 있는 'Material UI'는 좋은 서비스이지만 사이즈가 매우 크기 때문에 잘 사용하지 않는 경우가 많다.

 

SEO

'SEO'는 어떤 키워드를 노출하는 것이 좋은지에 대한 전략이 중요하다. 여기서 컨텐츠가 중요한 요소이다.

그러나, 프론트엔드에서 할 수 있는 영역은 아니다. 그래도 할 수 있는 것은 최대로 하는 것이 좋다.

 

• 마크업만 잘 맞춰도 반은 간다
• Meta data 적용하고, JSON-LD도 적용한다
• 사이트 로드 속도도 중요하다

 

시맨틱 태그

검색 엔진이 웹 페이지 구조와 내용을 잘 이해할 수 있도록 도와야 한다. 이는, 검색 순위에 영향을 생각보다 많이 미치기 때문이다.

시맨틱 태그 사용

 

시맨틱 태그를 사용할 때, 최소한으로 지켜야 할 규칙들이 있다.

1. H1 태그는 전체에서 딱 한 번만!
2. H2, H3... 태그들은 섹션 등에 사용
3. <main> 태그는 문서에서 한 번만!
4. 접근 링크들은 <nav> 태그로 묶어서
5. 관련 컨텐츠는 <section> 태그나 <article> 태그로
6. <header> 태그, <footer> 태그는 하나씩
7. router.push() 보다 <a> 태그, <Link> 태그 사용

 

JSON-LD

검색엔진이 읽어가는 구조화 데이터 마크업을 말한다. 가능한 한 제대로 잘 넣는 것을 추천한다.

 

구조화된 데이터 일반 가이드라인 | Google 검색 센터  |  문서  |  Google for Developers

 

최소한으로 지켜야 할 것들은 다음과 같다.

 

1. 필수 속성 누락하지 않기 (https://schema.org/)
2. 페이지 컨텐츠와 데이터 일치하기
3. 한 페이지에 하나씩 넣기

 

데이터 분석 흐름

데이터 분석은 보통 어떤 순서로 돌아갈까? 어떻게 하면 데이터를 잘 모을 수 있을까?

 

데이터는 무엇일까?

서버와 주고 받는 것도 데이터이고, 센트리로 로깅하는 것도 데이터이다. 모든 게 거의 데이터에 해당한다.

이번에 언급된 데이터는 '사용자 행동 데이터'이다.

 

• 사용자 행동 데이터: 서비스 내 일으킨 모든 행동

 

사용자가 서비스에 들어와서 어떤 요소를 눌렀고, 스크롤을 내렸고 등 모든 행동들이 포함된다.

 

Data Driven

데이터를 기반으로 의사결정을 내리는 것을 의미한다.

데이터를 수집하고 분석하고 예측해 인사이트를 도출하고 전략을 수립한다.

 

그렇다면, 프론트엔드에서는 무엇을 해야 할까?

시각화하는 과정이 때로는 포함되기도 하지만, 이번 시간은 다루지 않는다.

 

프론트엔드에서는 '데이터 수집'에 집중한다. 분석하고 예측할 토대를 세워주는 일을 하며, 원하는 데이터를 모아주는 일을 해야 한다.

 

데이터 수집 단계

1. 수집할 데이터 정의
2. 사용자 속성 정의
3. 이벤트 설계
4. 심기

 

데이터 정의와 설계는 보통 마케팅 또는 데이터 사이언스 파트에서 담당한다. 프론트엔드가 해야할 일은 잘 심는 것이다.

 

데이터 정의와 사용자 속성 정의

프론트엔드는 잘 심기만 하면 되지만, 내용은 알고 있는 게 좋을 것이다.

 

• 데이터 정의: 어떤 행동에 대해 데이터 모으기 → 어떤 페이지에서 일어날 수 있는 행동 정의
  • 예. 팔로우를 했는가? 팔로우를 취소했는가? 팔로우 취소한 친구의 ID 또는 위치
• 사용자 속성 정의: 유저가 어떤 정보를 가지고 있는 확인하기 → 유저 데이터 중 행동에 영향을 끼칠만한 요소 정의
  • 나이대, 알람 받기 동의 유무, 팔로워 수, 팔로잉 수, 관심사 등

 

이벤트 텍소노미(Event Taxonomy)

무엇을 모아서 볼 지 정의했다면, 문서로 남겨두는 것이 좋다.

 

'이벤트 텍소노미'는 데이터 정의에 대한 내용을 모두 볼 수 있게 저장한 문서로 어떤 의도를 가졌고, 어떤 속성(파라미터)를 가졌는 지 확인할 수 있어야 한다. 그리고 최신화가 되어 있어야 한다.

 

문서에 들어갈 내용은 로그에 찍어둘 이벤트 명, 이벤트 설명, 속성값을 필수로 넣는다. 그리고 컨벤션에 대한 내용도 포함하면 좋다.

추가로, 플랫폼(ISO, AOS, WEB 등), 이벤트 활성화 버전(특정 속성만 추가/삭제 됐다면 속성에 대한 버전 기록), 속성에 들어가는 값 타입(String, Int 등), 서로의 이해를 돕기 위한 모든 것들이 들어가도 좋다.

 

많이 쓰는 도구와 GTM 설정 방법

이벤트 추적 도구의 종류는 많이 쓰는 툴을 크게 나눠보면 행동 추적과 획득 분석으로 나눌 수 있다.

 

• 사용자 행동 추적: 사용자가 서비스 안에서 어떻게 움직이는가? (유저 저니 초입부터 퍼널 등 확인)
• 사용자 획득(전환): 사용자가 어떻게 서비스에 들어오게 되었는가? (광고에서 앱 유입까지 어떻게 전환 되었는 지 확인)

 

이 외에, 시각화 툴이나 통합 툴도 존재한다.

 

사용자 행동 추적 도구들

사용자가 어떻게 움직였는지 보고 싶을 때 많이 사용하는 도구들이다.

 

• Google Analytics(GA)
  • 무료
  • 부분 유료
• 믹스 패널
  • 가장 UI가 직관적이고 사용하기 편하다
  • 기능이 적다
• 앰플리튜드
  • 보고자 하는 거의 모든 보고서 생성 가능

 

 

사용자 획득 도구

사용자가 어떻게 움직였는지 보고 싶을 때 많이 사용하는 도구이다.

 

• 앱스플라이어
  • 어트리뷰션 툴을 사용 시, 자주 사용하는 도구
• 에어브릿지
  • 다른 툴과 통합이 쉬움
  • 비교적 높은 가격
  • 통합하지 않아도 최소한의 획득 및 수집 역할 동시 수행

 

그 외 도구들

시각화를 하고 싶거나 여러 툴을 통합하고 싶을 때 등 여러 상황에서 다양한 도구를 사용한다.

 

• 태블로
  • 데이터 시각화 툴
• 클라리티
  • 스크롤, 히트맵 등을 확인할 수 있는 웹 분석 툴

 

많은 도구들이 있으며, 이는 프론트엔드에서 연동해서 사용한다.

 

GTM을 사용하는 이유

몇 개의 도구만 봤지만, 이는 7개나 된다. 굉장히 많은 도구들이 있고 병행해서 사용하는 경우도 많다.

그러나, 너무 많은 툴, 너무 많은 중복 이벤트를 한 번에 관리하고 싶을 때 'GTM'을 사용한다.

 

그렇다면, 어떻게 사용할까?

 

1. GTM 연동 (스크립트 태그 추가)
2. 태그(추적 코드) 심기
3. (변수 생성)
4. (트리거 생성)
5. 태그 생성
6. 확인

 

Logger로 관리

직접 연동할 때에도 편하게 관리하도록 해야 한다. 이는 생각보다 간단하다.

 

1. 이벤트 이름 정의
2. 연동해야 하는 툴 연동 및 로거 생성
3. 모든 툴을 통합 관리하는 메인 로거 생성
4. 메인 로거만 불러서 모든 이벤트 전송

 

위의 각 순서를 예시 코드로 확인해보자.

이벤트 이름 정의

연동할 툴 연동 및 로거

통합 로거 생성

사용