🌱 꿈에 그리던 인프콘 당첨
8월 3일, 인프런에서 주최한 개발자 컨퍼런스 인프콘 INFCON 2024에 다녀왔습니다. 작년에 삼성 개발자 컨퍼런스에 이어서 두번째 컨퍼런스다.
지난 3년 동안 계속해서 인프콘 신청을 했으나 떨어졌고, 당첨된건 이번이 처음이다. 경쟁률이 높은 컨퍼런스인데, 운이 좋게 붙은 것 같아 최대한 열심히 들어보고자 했다.
제작년에는 무료로 진행했던 것 같은데, 이번에는 44,000원의 참가비가 있었고, 인프런의 강의를 한번이라도 산 회원한테는 50%의 할인을 해주어서 22,000원에 구매할 수 있었다. 이번 인프콘에가서 알게 된 사실인데, 그럼에도 10000명이 넘는 인원이 인프콘에 신청했다고 한다.
🌱 인프콘 입장
티켓 부스에서 등록을 하고 이름표와 여러 기념품을 받았고, 기념품을 보관할 수 있는 에코백을 받았다.
들어가자마자 사람이 엄청 많았다. 기업 부스가 많이 참여해서 다들 굿즈 받으려고 여러 부스들에 줄 서는 모습이 인상적이었다. 나도 들어가자마자 여러 부스들을 돌면서 굿즈를 많이 받아왔다.
들어가자마자 크게 포토부스가 있어서 혼자 세컷 사진을 찍었다. 사진찍을 때 사용할 소품도 배치되어있었다.
🌱 Session
인상 깊었던 세션을 소개합니다.
💡 주요 발표 및 세션 순서
(1) 달리는 기차의 바퀴 갈아끼우기: 인프런 프론트엔드 마이그레이션 여정(조성륜, 인프랩)
마이그레이션 과정에서 발생한 여러 문제점과 그 해결 방법
(2) 지난 4년간 6번의 무진장 행사를 통해 성장한 DevOps 이야기(정주리, 무신사)무신사 SRE 팀에서 무진장 행사에서 늘어나는 주문량에서 생기는 에러들을 대처하는 방법
(3) 처음으로 기술 리더가 된 개발자를 위한 안내서(박서진, 비바리퍼블리카)팀원이 팀 리더를 믿고 따르는 순간(유능, 소통, 예측, 관심, 안전, 유사)
(4) Next.js 블로그 모범 사례 탐구: Vercel 리더십 블로그 아키텍처 파악하기(하조은, 당근)Next.js를 만든 Vercel의 CEO인 Guillermo Rauch, VP인 Lee Robinson의 블로그를 살펴보기
(5) 실리콘 밸리 개발 문화 및 서바이벌 전략
#Session 1: 달리는 기차의 바퀴 갈아끼우기: 인프런 프론트엔드 마이그레이션 여정
주제
마이그레이션 과정에서 발생한 여러 문제점과 그 해결방법
내용
1. 배경
- 기존상태 : Node.js + Express 를 사용하여 Server Side 구현
- 자체 탬플릿 엔진을 사용하여 서버에서 HTML을 생성하고, 이후 Javascript에서 이벤트를 생성하는 방식으로구현
2. 문제점 :
- 서비스가 점점 커지고 개발자가 많아지면서 개편이 필요하다고 느껴짐
- 하나의 페이지를 만들기 위해 4개의 파일이 필요
Button이라는 문자열 → 분리된 3개의 파일의 연결점이 모호함(template.js, style.css, event.js) ⇒ 정확한 코드 사용처 파악이 불가능
코드의 복잡성이 높아지고, 레거시 코드가 많아지면서 build 하는데 걸리는 시간이 점점 오래걸리는 문제점이 발생함
이러한 문제점 해결을 위해 일부분 코드만 React로 마이그레이션을 결정
3. 해결방법
1) 기능 플래그를 사용
기능 on - 신규 서비스 제공
기능 off - 이전 서비스 제공
기능 플래그를 사용하여 서비스를 점진적으로 공개
QA 담당자만 기능 사용 가능하도록 함
기능플래그로 기존 기능과 신규기능을 분리하여 배포의 안정성을 높임
2) 특정 영역을 JS로 로드하는 방식
기존의 legacy 코드인 header, footer 레이아웃은 유지
내부 content 부분만 개편하고자함
⇒ 빌드된 JS버전의 해시를 확인하고 JSON파일로 content 부분을 불러옴
3) 스타일 침범 이슈 발생
기존의 header, footer 컴포넌트의 스타일들이 react 컴포넌트에 영향을 주게 됨
해결 방법은 shadow DOM 사용하여 스타일 격리
- shadow DOM이란, 웹 컴포넌트의 캡슐화를 도와주는 장치
- 동일한 페이지에 특정 dom을 캡슐화하여 마크업, 스타일등의 간섬이 일어나지 않도록 해줌
4) 기존 운영되는 레거시 서비스의 부하 문제
모든 요청을 레거시 라우트 처리를 하다보니 부하 문제 점이 발생
CloudFront Behavior + Reverse Proxy Server를 사용하여 부하 문제 해결
AWS Cloudfront: 아마존 웹 서비스(AWS)에서 제공하는 CDN 서비스
AWS Cloudfront Behavior: url 경로, http 메서드, 헤더, 쿼리 문자열을 기반으로 특정 오리진에 라우팅
Reverse Proxy: 클라이언트의 요청을 받아 내부 서버로 전달하고 서버 응답을 클라이언트로 반환하는 서버, 기존에 cloud front behavior가 하는 역할 + 쿠키 기반 기능 플래그
결론
매 순간 주어진 문제를 해결해주는 결정이 필요하다. 앞으로 생겨날 여러 문제들에 부딪혀볼 용기, 그 안에서 즐거움을 찾자!
인사이트
- 마이그레이션 할 때 기능 플래그를 사용하여 점진적으로 업데이트하면 안정적으로 서비스를 업데이트 할 수 있는 좋은 방법인 것 같다. 적용해보면 좋을 것 같다.
- 문제 상황이 발생했을 때 당황하지 않고 단계별로 나누어서 지금 단계에서 해결해야하는 문제점에 집중하고 라이브러리, 방법 등을 리처치해서 차근차근 해결해 나가면 무슨 문제든 해결할 수 있을 것이다!(나중에 비슷한 문제에 마주칠 것을 대비하여 shadow dom, ReverseProxy 등의 기술명들을 기억하자)
- 마이그레이션시에 모든 컴포넌트 페이지를 변경할 필요 없이, 업데이트가 필요한 부분들만 업데이트 하는 방법도 있는 것을 깨달았다.
#Session 2: 지난 4년간 6번의 무진장 행사를 통해 성장한 DevOps 이야기
주제
무신사 SRE 팀에서 블랙 프라이데이때 늘어나는 주문량에서 생기는 에러들을 대처하는 방법에 대해서
내용
SRE 팀이란? Service Reliability Engineer의 줄임말로 안정적인 무신사 서비스를 위해서 에러 대응을 하고, 테크 부문 개발자가 더 효율적인 업무를 할 수 있도록 지원해주는 팀
- 문제
- 블랙프라이데이, 무진장행사 등 1년에 2번 정도 할인 판매를 하여 사용자들의 주문량이 과도하게 많아지는 일이 1년에 2번 정도 발생
- 주문량이 가장 늘어나는 시기는 언제? 블랙프라이데이 마감 5분전. 장바구니를 담아두고 고민하다 5분전에 결제
- 해결방식
- 디비에 접근할 때 많은 수를 감당하는 것이 어려움, 서버 용량을 늘리거나 개수를 늘리거나 하는 방식으로 진행
- 하지만, 예측하지 못해서 너무 많은 서버 용량을 구매하면 비용 부담이 되기 때문에 지양해야하고, 너무 적게 구매하면 에러가 나서 사용자가 구매를 하지 못해 불만사항이 생기는 현상이 발생 ⇒ 잘 예측해야하지만 실제 접속 인원보다는 조금더 넉넉하게 하는 것이 좋음
- 장애 발생시에는 1) 장애도 해결해야하고 2) 리더 개발자에게 보고해야하고 3) 사용자 대응팀에게도 보고해야함
- 이렇게 해야할 일들이 많아서 장애 해결을 지연시키는 원인이 됨
- 이를 해결하기 위해서 장애 대응 자동화 진행장애 발생을 위한 연습 진행
- 업무 툴에서 티켓 생성하면 슬랙 장애 대응 채널 생성, SRE 및 관련 이해관계자들이 자동으로 초대, 주요 채널에 알람 메세지 발송을 한번에 하는 시스템 구축
- 실제 상황에서 머뭇거리면 안되기 때문에 실제 에러가 일어나는 것처럼 연습을 하면서 실전에 대비
인사이트
- 사용자가 많은 서버는 고려해야할 점이 많다.
- 장애발생은 모두가 당황스러운 상황이다. 그 상황을 익숙하고 편하게 해결할 수 있도록 환경을 세팅해두자.
#Session 3: 처음으로 기술 리더가 된 개발자를 위한 안내서
주제
팀원이 팀 리더를 믿고 좋아하는 7가지의 순간들
내용
팀원이 나를 신뢰할 때 좋은 리더가 될 수 있다.
신뢰를 하기 위한 요소에는 총 7가지, 유능, 소통, 예측, 관심, 안전, 유사, 이익 공유
- 유능
- 유능할 수록 신뢰를 얻기 쉽다.
- 모든 역량이 유능해야하는 것이 아니라 팀원의 문제를 해결해주는 것이 유능한 것
진통제: 아픈사람에게 진통제를 놔주는 것 (이부분에 집중할 것) - 관심
- 리더가 되면 바쁘기도 하고 나랑 잘 안맞는 팀원들도 있다. 그들에게도 관심을 가져야 하나?
- 🗣️ 예시1) 무릎이 아파서 환자가 의사를 찾아온 상황
- 환자: 선생님 약 먹는데도 무릎이 아파요.
- 의사: 이 병은 원래 다 그래요. 그냥 꾸준이 약 드시고 무리하지 마세요
- 여러분이 환자라면 이 병원에 다시 갈까요? 동감이 아닌 공감이 필요(감정을 이해하는 것)
- 팀원의 감정과 어떤 문제들을 이해(공감)를 해줄 때 팀원이 팀 리더를 믿어준다고 생각한다.
- 이러한 말하기 방식을 가지면 환자는 전 의사 선생님보다 훨씬 더 신뢰할 수 있습니다.
- 🗣️ 예시2) 환자: 선생님 약을 먹는데도 무릎이 계속 아파요.
- 의사: 무릎이 아파서 많이 힘드시죠? 아침에 일어나서 주무실 때까지 어떻게 약을 드세요?
- 환자: 아침에 늦게일어나면 아점먹고 약 한 봉지 먹는데 저녁에 드라마보다 보면은 시간 놓치거나 그래요.
- 의사: 약을 세봉지 먹어야 되는걸 알고 있는데 일과떄문에 못하시는군요. 어떻게 하면 잘 복용할 수 있을까요?
- 말하기 방식에 초점을 맞추면 된다. → 어떻게 이야기하느냐에 따라서 팀원이 느끼는 감정에 많이 달라질수가 있다.
- 관심있다는 티를 낼 것(오고가며 인사하기, 팀원들의 고민에 대해서 의식적으로 관심 가지면서 해결됐는지 물어보기)
- 소통: 팀원에 대한 관심
- 팀원과 깊고 넓게 소통할 수록 팀원이 나를 믿고 따른다.
- 티키타카가 되는지 확인(비슷한 길이의 말을 하는지)
- 유사한점 공유(TMI 방출)
- 안정
- 팀원과 깊고 넓게 소통할 수록 팀원이 나를 믿고 따른다.
- 팀원이 심리적 안정감을 느낄수록 리더를 신뢰한다.
- 매니지먼트의 방법
- [지배] 팀원의 경험이 부족한 경우에는 구체적인 지시 ex) 여기에서 핸들을 이렇게 꺾고, 좌회전을 하고, 브레이크를 밟고…
- [위임] 팀원의 경험이 많고, 결과가 언제나 예측 가능한 단계라면 추상적으로 지시하기 ex) 가봅시다~
- [리드] 팀원의 경험이 많은 경우에는 덜 구체적인 지시 ex) 고속도로 타서 가죠~, 강릉역으로 가시죠
- 매니지먼트의 방법
- 예측:
심리적 안정감은 매니지먼트 방법보다는 예측 가능한지, 투명한지에서 온다. 팀 리더가 어떤 근거로 팀원에게 지배, 리드, 위임하는지 충분하게 공유하는게 심리적 안정감의 핵심
⇒ 토스에서는 팀원한테 업무를 부탁할 때 세가지 방법 중에서 어떤 방법을 선택해서 매니지먼트를 할지, 그리고 그 근거를 팀원한테 전달하려고 노력한다. - 상호간의 공동 목표
팀원의 성공이 리더의 성공 또는 리더의 성공이 팀원의 성공이 되도록 같은 배를 타도록 하는 것
나와 팀원을 아우르는 한 차례의 상위 목표를 세우는 것이 중요
ex1) 우리가 이 회사에 같이 있는데 이 회사에 다닌 경험이 여러분의 이력서에 정말 멋진 이력이 되었으면 좋겠다.
ex2) 토스를 한국에서도 그리고 세계적으로도 프론트엔드 화면을 제일 잘 그리는 조직을 만들고 싶다.
ex3) 우리 회사에서 있었던 것이 뜻깊고 그런 즐거운 경험이면 좋겠다
인사이트
- 좋은 리더가 되는 방법에대해서 구체적으로 설명하고 있어서 이해하기 쉬웠다.
- 업무적으로 일을 잘 처리하면 된다고 생각했는데, 소프트적인 스킬도 중요하다는 것을 느꼈다.
- 같은 말이라도 어떻게 표현하는지에 따라 상대방이 느끼는 방식이 완전히 다르다는것을 깨달았다.
#Session 4: Next.js 블로그 모범 사례 탐구: Vercel 리더십 블로그 아키텍처 파헤치기
주제
Next.js를 만든 Vercel의 CEO인 Guillermo Rauch, VP인 Lee Robinson의 블로그를 살펴보며 Next.js로 만든 좋은 블로그 예시를 살펴보기
목차
- 일반적인 Next.js 블로그 아키텍처
- 컨텐츠 데이터 관리
- 블로그에서 사용되는 콘텐츠, 포스팅 되는 데이터를 어떻게 관리하는지 살펴보기
- 라우팅과 렌더링
- 개인 블로그를 운영하기 위해 어떤 라우팅 방식을 쓸 수 있고, 어떤 렌더링 방식을 쓸 수 있는지 살펴보기
- 메타 데이터
- 블로그는 검색엔진최적화(SEO)가 굉장히 중요함, 콘텐츠를 많은 사람들에게 읽게 만들어야하기 때문, 메타데이터는 SEO의 재료가 됨, 이를 어떻게 관리하고 생성할지 살펴볼 것
- Next.js 변화 따라잡기
- 기본 개념
- Next.js 13 이후
- Vercel 리더십 블로그 아키텍처
- 설정 훑어보기
- 컨텐츠 데이터 관리
- 라우팅과 렌더링
- 메타데이터
버셀의 CEO와 제품 부문 부사장인 리 위빈슨에 대한 이야기
Next.js를 만든 vercel의 리더십인 기르모아와 리의 블로그를 살펴보고자 함
- 일반적인 Next.js 블로그 아키텍처
- 컨텐츠 데이터 관리
- lee: 마크다운 문자열 ⇒ html로 바꿔줌
- 여기에 markdown setric textree 추상화 공간인 중간단계가 존재
- h1에 해당하는 markdown type, this, value 등의 데이터로 치환한 후에 실제 HTML 코드로 바뀜
- 이렇게 만들어진 html 문자열과 메타 데이터등의 값이 getPostData의 결과값으로 변환됨
- 라우팅과 렌더링
- 보통은 동적 라우팅(dynamic routing)을 사용
- 블로그라는 저장소가 있다면 그 안에 페이지, post 폴더가 순차적으로 만들어지고 대괄호로 묶은 페이지 파일을 생성, 이렇게 대괄호에 담긴 아이디가 나중에 게시글을 조회하는 단서로 사용되는 형태
- 렌더링은 SSG(static site generation)을 사용파라미터로 전달된 ID 값을 전달하면 게시글의 데이터를 찾아내고 반환한 값을 UI 컴포넌트에서 활용함
- getStaticProps 함수에서 정적으로 사용할 데이터를 조회
- 메타 데이터
- md파일에서 포트 맥터 영역을 미리 작성한 메타 데이터를 라이브러리(meta)의 도움으로 읽어냄
- 그 값을 <head>라는 Next.js에서 제공하는 컴포넌트에 title meta 태그로 넣으면 Next.js가 메타태그로 인식
복잡한 프론트엔드 생태계에서 서버사이드렌더링(SSR), 정적 사이트 생성(SSG), 클라이언트 사이드 렌더링(CSR)을 손쉽게 구현하고 개발 생산성을 높이기 위해 Vercel에서 만든 React 기반의 프레임워크
Next.js는 리액트의 한계를 극복하고 렌더링 서버를 쉽게 만드는데 의미가 있음 (DX를 개선하고자 나옴)
- Next.js 변화 따라잡기
- 기본 개념
- 등장 배경
- 리액트는 브라우저에서 해석되는 라이브러라서 SEO를 위한 정보를 알아내기가 어려운 단점이 있었음
- 그래서 서버에서 미리 어느정도 데이터를 내려주는 방식으로 구현하려고 하는데 리액트 단에서 제공하는 기능을 사용하기에는 개발자들이 불편한 점이 많음 ⇒ DX가좋지 않다. 개발 경험이 좋지 않음
- Vercel은 이 DX를 개선해서 렌더링 서버를 쉽게 만들 수 있도록 Next.js를 만듦
- 이런 배경 덕분에 서버에서 사전 렌더링(미리 HTML 을 그려주는 기법)이 발달하게 됨
- 사전 렌더링
- Server Side Rendering: 서버에서 렌더링
- Static site Generation: 정적인 사이트 생성
- Incremental static regeneration: 정적으로 만드는 것을 주기적으로 갱신해주는 기법
- 파일 시스템 기반의 라우팅
- index routes: index.js와 같은 파일이름을 지정하면 그 파일은 상위 폴더의 진입점
- Nested routes: 중첩으로 경로를 만들 수 있다는 뜻
- dynamic routes: 대괄호로 묶어서 파일 이름을 지정하면 변수가 생기고, 그 변수를 페이지를 동적으로 그리는 단서로 활용하는 기법
- API 라우팅
- API라는 이름의 폴더 아래 만들어진 파일과 폴더들은 API로 활용될 수 있다는 점
- 등장 배경
- next.js 13 이후
- server component: page 단위로 렌더링 → 컴포넌트 단위로 렌더링 할수 있도록 업데이트, 개발자에게 주는 선택지의 다양화
- route groups: 경로들을 묶어서 관리하게 하는 기법
- server actions: ‘use server’라는 문장이 있으면 해당 스코프에 있는 로직은 서버에서 동작
- Partial PreRender: 정적으로 사전에 렌더링 되는 영역인 shell & 동적으로 만들어지는 hole,
- SSG + SSR의 장점을 섞은 것
- 기본 개념
- Vercel 리더십 블로그 아키텍처
- 설정 훑어보기
- 두명 블로그의 공통점은 조회수 제공 → 이를 위해선 DB 필요 → 어떤식으로 DB를 사용하고 있는지 확인→ 기르모: redis,
- 컨텐츠 데이터 관리lee: 글을 데이터로 관리
- 기르모: 글을 코드로 관리(코드에서 글을 뽑아낸다는 뜻)
- 라우팅과 렌더링lee: dynamic routing 사용, PartialPreRendering 사용,
- 기르모: route groups를 활용, ssg를 활용
- 메타데이터lee: generate metadata라는 동적인 함수로 정의하고 있음 ⇒ 동적인메타데이터 생성,
- 기르모: 동적인 정적으로 메타데이터라는 이름으로객체를 정의, open graph image를 dynamic route와 route handler를 이용해서 생성
인사이트
- 특정 기술을 공부하고 싶다면, 제일 좋은 예시 홈페이지를 뜯어보는 방법이 있다.
- next.js에 기본으로 내장되어있는 기능이 많다.
- 정해진 방법이 없으니 본인의 상황에서 제일 최적의 방법을 찾아서 해결할 것
#Session 5: 실리콘 밸리 개발 문화 및 서바이벌 전략
주제
실리콘 밸리 소프트웨어 개발문화와 키워야 할 역량
내용
실리콘 밸리 소프트웨어 개발 문화
- 좋은 날씨, 여유있는 연봉, 사고를 자극하는 환경, 맛있는 커피, 휴가 문화
서바이벌 전략
- 자기 PR, 새로운 기술 트렌드 습득, 네트워킹, 협업능력, 창의성과 문제 해결 능력(비즈니스 문제까지 해결할 수 있는 능력)
- 기술 & 언어직군 언어 프레임워크/라이브러리
Python을 학습하면 실리콘밸리에서 기회가 많이 열려있을 것Machine Learning Engineer Python, R Tensorflow, pytorch, keras DevOps 및 SRE Python, Bash, Go, Ruby Docker, Kubernetes, Jenkins, AWS, Google Cloud Platform Frontend Engineer Javascript, TypeScript React, Angular, Vue.js Backend Enginner Java, Python, Javascript(Node.js), Ruby, Go, PHP Java - Spring, Spring Boot Python - Django, Flask Javascript - Express.js, NextJS Ruby - Ruby on Rails Go - Gin, Echo PHP - Laravel, Symphony Data Engineer & Scientist Scala, Python, SQL, R Python - Pandas, scikit-Learn, TensorFlow, Pytorch 데이터 처리 - Hadoop, Apache spark, Cassandra, HBase, Flink, Iceberg - 5가지는 반드시 지킬 것
- 영어로 학습하기
- 회사에서만 배울 수 있는 경험을 쌓아 경쟁력 갖추기
- 리눅스나 맥북 사용하기
- 멀리가고 싶다면, 반드시 운동하기
- 도전을 포기하지 말기, “포기하지 않으면 실패는 없다”
실리콘밸리 입성
취업/비자 성공사례: H1B비자를 받는 것을 목표로 할 것
인사이트
- 미국 개발 분야에서 많이 사용되는 언어는 python
- 실리콘 밸리는 개발자가 성장하기 좋은 환경
🌱전체적인 후기
이번 컨퍼런스에서 발표자와 참석자들의 열정을 느끼며, 나도 더 열심히 성장해야겠다는 결심을 하게 되었다. 마이크를 잡고 자신 있게 발표하는 분들이 너무 멋있어 보였는데, 나도 언젠가는 저 자리에서 개발 지식을 공유할 수 있는 기회를 가져보고 싶다.
다른 개발자들이 겪었던 문제점들을 보면서, 모두가 해결 방법을 찾기 위해 고군분투하고 있다는 사실에 동질감을 느꼈다. 앞으로도 이런 세션에 많이 참석하여 문제 상황을 대처하는 다양한 방법들을 배우고, 비슷한 상황에 처했을 때 관련된 키워드를 빠르게 떠올릴 수 있도록 해야겠다.
특히, 실리콘밸리 개발자들의 세션을 들었을 때, 몇 년 전의 내 열정이 다시 떠올랐다. 4년 전만 해도 실리콘밸리의 개발자가 되겠다는 목표로 교환학생을 준비해 실제 캘리포니아 주립대학교에 합격했었지만, 코로나로 인해 포기했던 기억이 있었다. 잊고 있었던 그때의 열정이 다시 살아나면서, 언젠가 다른 나라에서 일해보겠다는 목표도 새롭게 다지게 되었다.
이번 컨퍼런스를 통해 다양한 개발 지식을 얻었고, 무엇보다 얻기 힘든 열정까지 되찾을 수 있어서 매우 뜻깊었다. 앞으로는 정기적으로 컨퍼런스에 참여해 다양한 개발자들과 소통하는 시간을 가져야겠다고 다짐했다!