[회고] 성능 최적화 고민

로선생·2025년 9월 13일

배경

회사에서 지역코드 / 업무 관련된 코드를 CSR api로 가져오고 있었다.
여기에 몇 가지 이슈사항이 발생하여 관련 이슈를 회고해보고자 한다..

CSR

CSR은 클라이언트(브라우저)에서 웹 페이지를 렌더링 하는 것이다. 모든 로직, 데이터, 템플릿, 라우팅 등을 서버가 아닌 클라이언트에서 처리하게 된다.

CSR은 브라우저가 페이지 초기 HTML을 받은 후에 Javascript 파일을 다운로드하고 해석해야 되는데, 번들 크기가 크면 초기 로딩 시간이 길어지고 사용자 인터렉션이 감소해 이탈율이 높아 질 수 있기 때문에 번들 크기를 고려해야 한다.

SSR

클라이언트 측이나 유니버셜 앱(Universal App)을 서버의 HTML로 렌더링하는 방식으로, 웹 애플리케이션의 초기 렌더링을 서버에서 처리하고, 클라이언트에 전달하는 방식 을 의미한다. 이를 통해 클라이언트가 서버로부터 응답을 받기 전에 데이터 패칭 및 템플릿 작성이 처리되므로 클라이언트에서 추가적인 네트워크 왕복이 발생하지 않는다

이슈

클라이언트에서 가져오던 코드 데이터가 너무 느려서 확인해보니, 코드 api size가 8MB씩이나 되었다. 마찬가지로 size가 너무 큰 api가 많아서, 정상적으로 데이터를 가져오지 못하는 상황이 발생하였다.

해결

결론적으로는 전체 데이터를 다 가져오는 방식에서 필요한 스키마만 추출해서 가져오는 방식으로 변경하였다.

관련하여 어떤 방식으로 해결하였는지 이번 기회에 정리해보고자 한다.

인프라적으로 생각하기

서버에서 미리 데이터를 받아오든, 혹은 클라이언트에서 받아오든 문제는 그냥 code api에서 주는 데이터가 엄청 크다는 것이다..

작동방식

실제 사용하는 공고뷰 관련 api에서는 코드를 '9010001000' 뭐 이런 식으로 넘겨주는데,

 "category": {
        "jobClassificationCodes": [
          "0000"
        ],
        "industryCodes": [
          "1111"
        ],

code api에서는 전 직군 관련된 코드를 필요없는 스키마를 포함해서 전~부 넘겨주고 있으니 비효율적일 수 밖에 없었다.

(이건 노출하면 안될 것 같아서 화면공유로 보여드릴게용 ^^,,)

우선 개선 방법을 적어보자면,

  1. 실제 필요한 스키마만 남길 것
  2. 필요한 부분만 스키마만 남겨 저장된 json 파일을 S3에 저장하고, CF에서 캐싱된 데이터만 가져올 것
  3. 이렇게 되면 대용량 데이터에서 필요한 것만 캐싱해서 가져오기 때문에 (비교적) 성능 최적화를 기대해볼 수 있었다.

우선 이슈는 이런 식으로 해결했지만, 사실 우리 서비스는 code api를 여러 서비스에서 공통적으로 사용하고 있기 때문에 이 작업에 대한 공통화 작업이 필요하다.

결과적으로는 npm 패키지로 말아서 공통화시키는 것이 목표이다. 해당 부분을 최근에 진행하고 있다.

getCodeName('1111')

결론..

인프라 공부 성능 최적화 공부 열심히 해야겠다... ..

이번에 인프라 스터디에서 SAA 자격증 공부를 하게 되었는데.. 진짜 열심히 참여해야지... ^~^,,,

profile
이제는 이것저것 먹어요

0개의 댓글