안녕하세요 dawonny 입니다.
얼마전 코엑스에서 2024 인프콘이 열렸습니다!
작년에는 신청했다가 떨어졌었는데, 올해는 운이 좋게 당첨되어 다녀오게 되었어요.
내년에도 갈 수 있을지는 모르겠지만, 짤막하게나마 후기를 남겨보려 포스팅합니다!
데스크에서 기념백이랑 생수, 스티커, 이름표를 받고 안으로 입장했어요.
참가자들이 정말 많았습니다!
여기어때, 무신사, 점핏, 데이터독 등의 다양한 기업에서 부스를 운영하고 있었고,
윗층인 2층에서는 네트워킹 행사와 동아리 부스도 운영되고 있었어요.
이벤트에 열심히 참여하면서 굿즈들을 받아왔습니다!
세션은 4개 정도 들었는데요. 세션을 들으면서 기록했던 내용을 기반으로
간략하게 기억에 남는 키워드를 정리해보려합니다.
11:25 - 12:05 103호
인프런 아키텍처 2024 ~ 2025
이동욱 - 인프랩
- 트래픽 비용 감소
- 이미지 트래픽 최적화
- 요청에 따라 이미지를 AVIF 형식으로 변환, 리사이징, 캐시를 활용해 이미지 트래픽을 최적화.
- 이를 통해 60% 이상의 트래픽 절감을 달성.
- JSON 데이터 호출 최적화
- 매일 150GB의 JSON 데이터를 호출하던 상황.
- ECS EC2에서 RDS DB에 높은 부하 발생.
- 이를 완화하기 위해 ElasticCache를 사용했지만, 외부 캐시로 인한 높은 트래픽이 발생(ECS EC2에 ElasticCache 인스턴스 3개 사용).
- 해결책: 로컬 캐시로 애플리케이션의 캐시 처리. 그러나 여전히 EC2의 트래픽 비용이 높았음(api 조회 때문).
- 개선방안: API 데이터를 JSON 데이터로 취급하여 CDN에 캐시하도록 설정. EC2까지 요청이 오지 않도록 조정.
- 결과: 애플리케이션 로드 70% 감소, 로드 밸런서 로드 50% 감소.
- 일 150GB, 월 4.5TB의 트래픽을 EC2로 처리하지 않아도 됨.
- 이미지 트래픽 최적화
- API 환경 개선
- 인프런 서비스는 Next.js 를 사용중. 그래서 브라우저의 모든 1차적인 요청을 Next.js에서 처리하도록 설정했음.
- 내/외부 서버를 따로 두려고 시도했으나 여러 문제가 발생했음.
- 해결책: 프론트엔드에서 호출하는 모든 API에 '/client'를 추가하여 호출하도록 설정.
- '/client'를 붙이면 세션 체크를 하고, 백엔드에서 호출하는 경우 API 토큰을 체크하도록 함.
- CloudFront
- 인프런 서비스는 CloudFront 를 사용함. CloudFront 는 AWS 의 콘텐츠 전송 네트워크(CDN) 서비스임.
12:20 - 13:00 105호
Next.js 블로그 모범 사례 탐구: Vercel 리더십 블로그 아키텍처 파헤치기
하조은 - 당근
- Next.js 를 만든 Vercel 의 Guillermo Rauch와 Lee (leerob) 의 블로그를 비교하며 Next.js 의 다양한 기능을 탐구하는 세션이었음.
- 블로그 구성
- 보통 블로그는 마크다운으로 작성됨. 이때, 마크 다운 파일은 front matter 와 content 로 구성됨.
- front matter: 메타데이터(제목, 날짜 등)
- content: 실제 콘텐츠
- 보통 블로그는 마크다운으로 작성됨. 이때, 마크 다운 파일은 front matter 와 content 로 구성됨.
- View Count 구현
- Guillermo: Redis 를 사용해 View Count 를 관리함
- Lee: PostgreSQL을 사용함.
- 프론트엔드 개발자도 쿼리문을 작성할 줄 알아야겠다고 느꼈음.
- 콘텐츠 데이터 관리
- MDX: Markdown을 react component 와 함께 사용할 수 있는 format. 동적인 UI와 정적 콘텐츠를 같이 사용가능함.
- 렌더링
- Guillermo: ISR (Incremental Static Regeneration)
- Next.js에서 지원하는 기능. 정적 페이지를 정기적으로 재생성해서 최신 데이터를 반영함.
- Lee: PPR (Partial Prerendering)
- Next.js 의 새로운 렌더링 패턴 중 하나. 정적 사이트 생성(SSG)와 서버 사이드 렌더링(SSR)의 장점을 결합한 것이라고 볼 수 있음.
- Shell과 Holes:
- Shell: 빌드 타임에 정적으로 렌더링. 페이지 기본 구조 등..
- Holes: 런타임에 동적으로 채워짐. suspense 를 이용해서 비동기 데이터를 처리함.
- Guillermo: ISR (Incremental Static Regeneration)
- Open Graphic Image
- 링크를 공유할 때 표시되는 이미지. Next.js 로 생성 가능함.
- https://nextjs.org/docs/app/api-reference/file-conventions/metadata/opengraph-image
- JSON-Ld
- 검색 엔진 최적화를 위한 data format. 구조화된 데이터를 제공해서 검색 결과에 풍부한 정보를 표시할 수 있음.
- 예를 들어 블로그 글의 메타데이터를 구조화해서 검색결과에 노출시키는 등.
14:00 - 14:40 101호
멀티패러다임 프로그래밍 언어의 시대: 객체지향과 함수형을 섞어야할 때!
유인동 - 마플코퍼레이션
함수형, 객체지향 패러다임을 모두 제공하는 멀티패러다임 언어를 효율적으로 사용하는 법에 대한 세션이었음.
타입스크립트로 Tagged Templates 를 만드는 라이브코딩을 보여주셨었는데 뭔가 빠져들게 되는 학교 수업을 듣는 기분이었음.
마지막에 책을 홍보하셨는데 읽어보고싶어짐.
15:00 - 15:40 101호
달리는 기차의 바퀴 갈아끼우기: 인프런 프론트엔드 마이그레이션 여정
조성륜 - 인프랩
- 인프런 서비스의 프론트엔드를 마이그레이션하면서 겪었던 다양한 문제와 해결 방안에 다루는 세션이었음.
- 초기 시스템 및 마이그레이션 필요성
- 초기 시스템
- wordpress를 사용하여 서비스를 시작하였으나, 이후 Node.js 로 마이그레이션.
- Express.js 를 사용하여 서버 사이드를 구현.
- 자체 템플릿 엔진을 사용하여 서버에서 HTML을 생성하고, 렌더링 후 이벤트가 포함된 JS 파일을 로드하는 방식.
- 문제점
- 페이지 수가 많아 빌드 시간이 20분을 초과.
- SEO가 필요한 페이지와 그렇지 않은 페이지를 분리하여 효율적으로 처리할 필요성이 있었음.
- 해결책
- SEO가 필요 없는 페이지: Vite와 React로 구현.
- SEO가 필요한 페이지: Next.js의 SSR(Server Side Rendering)로 구현.
- 초기 시스템
- 마이그레이션 과정
- 배포 후 롤백이 쉽고, 기존 학습 페이지 URL이 그대로 동작해야했음.
- 기능 플래그 기능을 사용하여 특정 사용자에게만 오픈할 수 있도록 설정함.
- 하지만 기능 ON/OFF 에 해당하는 코드를 두개 관리해야하고, 배포 후 기능 플래그를 정리해야한다는 단점이 있었음.
- 하지만 안정적인 배포가 가능하다는 장점이 있었음.
- 레거시 코드가 React 로 작성한 코드에 영향을 미칠 수 있었음
- Shadow DOM을 통해 스타일을 격리하여 레거시 코드가 React 코드에 영향을 미치지 않도록 함
- 배포 후 롤백이 쉽고, 기존 학습 페이지 URL이 그대로 동작해야했음.
- Vite manifest 옵션을 사용하여 manifest.json 파일을 자동 생성함.
- manifest file: 논리정연한 단위의 파일 그룹을 위한 메타데이터를 포함
- Vite manifest option: 빌드 결과물(assets)을 'Record<name, chunk>' 형식으로 작성
- Shadow DOM의 문제점
- 레거시 컴포넌트와 신규 React 컴포넌트 간의 상태 및 이벤트 공유 문제, 그리고 서버 사이드 렌더링 시 Shadow DOM 표현 문제
- 따라서 레거시 코드(예: 헤더, 푸터)도 React로 구현하여 통합
- module federation 적용
- 공용 모듈 라이브러리를 관리하기 위함
- Module Federation을 적용하여 독립적으로 빌드된 JS 모듈들을 런타임에 동적으로 공유 및 사용.
- AWS CloudFront 및 리버스 프록시 서버
- AWS CloudFront: CDN 서비스로, URL 경로, HTTP 메서드, 헤더, 쿼리 문자열을 기반으로 특정 오리진에 라우팅.
- 리버스 프록시 서버: CloudFront 옆에 추가하여 기존 기능 플래그 기능을 대체
인스타그램이나 커리어리 같은 소셜 플랫폼에서 보던 분들을 직접 발표로 만나니까 너무 신기했어요!
네트워킹 행사가 활발하게 이루어지는 것 같았지만 일정 이슈로 인해 가지 못했던게 조금 아쉽네요 🥲
다음에 참가하게 된다면 기획/디자인 관련 세션들도 좀 찾아서 들어보고싶네요.
내년에도 참가할 수 있으면 좋을 것 같습니다!
이상 후기 마치겠습니다. 내용에 오류가 있다면 댓글로 알려주세요 :-)
읽어주셔서 감사합니다!
