어쩌다보니 2024 FECONF 티켓이 생겼다.
태어나서 처음으로 가는 컨퍼런스... 기대 반, 두려움 반...
그렇게 첫 컨퍼런스 참여 후기를 적도록 하겠다.
먼저 Lightning Talk를 제외한 트랙 A, B는 FEConf 공식 유튜브 채널에 실시간 라이브 영상이 올라와있으니 세션에 대해서는 자세히 설명하지 않도록 하겠다. 물론 인상깊었던, 그리고 재밌었던 점은 다 말할 거다.
FECONF는 크게 3개의 트랙으로 이루어졌다.
Track A, Track B, Lightning Talk
컨퍼런스를 가기 전, 어떤 세션을 들을 지 먼저 타임 테이블을 참고하였다.
각 트랙 별 시간표는 아래 사진처럼 되어 있었는데 (출처: 2024 FECONF 공식 사이트)
내 시선을 끌었던 것은 Speaker B였다.
Three.js, 렌더링 엔진 테스트 자동화, WebRTC? 일단 타이틀만 봐도 맛도리 예약.
그래서 가기 전부터 B 쪽에서 죽치고 앉아있을 생각을 했다. 물론 Speaker A도 재밌어보이긴 했다. 웹 어셈블리 안내서... 한글 유니코드... 못잃어... 하지만 B가 더 재밌어보였어...
아무튼 FE CONF 행사장에 12시에 도착했다. 세션 시작은 12시 50분이라 시간이 남아 일단 커피 한 잔 빨면서 기업 부스를 돌아다녔다. 위에서도 말했지만 컨퍼런스가 처음이라 일단 모든 부스를 전부 돌았다. 진짜 전부 돌았다. 그래서 이걸 쓰는 지금, 집에 스티커가 짱 많아졌다. 필요한 사람들은 말을 하도록.
그러다보니 시간이 다 되어가므로, 장소로 가 앉았다. 12시 50분 시작이라했지만 좀 딜레이되어 1시 좀 넘어서 시작했던 것 같다.
후원 세션
제일 처음에는 후원 세션이었다. 단순 후원 기업 등을 얘기해주는 자리일 줄 알았는데 갑자기 AI 관련 이야기를 해주셨다.
구글의 AI 연구에 대해 훑어보는 느낌으로 이야기 해주셨는데, 이번 컨퍼런스에서 가장 고민을 해볼 말이 처음부터 나왔다.
AI가 개발자를 대체한다는 말이 나오지만, AI가 개발자를 대체할 수 없다고 생각한다.
하지만 AI를 아는 개발자와 모르는 개발자는 차이가 클 것이다.그냥 후원 세션인 줄 알고 기록할 준비를 안해서 기록이 안되어 있어 기억 속에 있는 말을 끄집어 냈다. 뉘앙스만 좀 다를 뿐 저런 말이었다.
과연 AI가 개발자를 대체할 수 없을 것인가? 시작부터 고민에 빠졌다.
바퀴 대신 로켓 만들기
사실 제목과 공식 페이지의 설명만 보고는 어떤 걸 설명할 지 몰라서 전혀 감이 안잡혔고, 기대를 안하고 있던 세션이었다. 하지만 내용은? 매우 알찼다. 솔직히 개인적으로 트랙 B에서 가장 취향이었던 세션이었다.
전반적인 내용은 FE 개발에 병목이 되는 디자인, 백엔드, 프로덕트와의 연관성을 끊어 빠르게 개발할 수 있는 방법에 대해 설명하셨다.
그 중에 백엔드와의 병목을 제거하기 위해 선택한 방법이 매우 내 취향이었다.
FE는 BE에서 제공하는 데이터 자체보단 그 데이터의 인터페이스를 원하며, 이를 쉽게 만들기 위해 OpenAPI Code Generator(OpenAPI CodeGen)를 만들었다. 즉, OpenAPI Spec(JSON)을 집어넣으면 TypeScript & Zod의 형식으로 타입을 정의해준다. 이는 Swagger를 보고 하나하나 인터페이스를 정의할 필요가 없다는 것을 말한다.
최근에 회사에서 제3자 서비스를 이용하면서, 그 서비스에서 제공하는 API의 타입을 적을 일이 있었다. 하지만 필드가 스크롤을 내려도 내려도 끝이 안보여 울고싶었던 적이 한두번이 아니었는데, 이걸 보고 더 울고싶어졌다. 하지만 이걸 알고 있었다고 해서 회사에서 저 CodeGen을 만들 시간을 주었을까? 그건 아닐 거라고 생각하니 마음이 좀 편해졌다.
아무튼 저 파트를 들으면서 회사에서 있었던 일이 생각나서 정말로 인상깊었다. 속으로 '이게 DX지!'라고 생각하며 저런 거 한 번 쯤은 만들어봐야 하지 않을까? 싶었다.
솔직히 어떻게 만들어야 할 지 지금 감도 안잡히는데, 같이 고민할 사람을 모집하고 있다. 연락 주세요.
백엔드 설명이 너무 길어졌으니, 디자인과 프로덕트와의 연관성 끊는 것은 유튜브에서 직접 보길 바란다.
10만 글로벌 유저 ... Three.js ... ShaderGradient ... (feat. 프레이머)
제목이 너무 길어 좀만 생략하자.
이 세션은 ShaderGradient 사이드 프로젝트를 만드는 과정을 보여주며, 기술 스택에 대해 공유하는 것보단 사이드 프로젝트가 유지되기 위해 어떠한 과정을 거쳤는가?가 더 중점이라고 여겨졌다.
솔직히 사이드 프로젝트 시작해놓고 던져둔 경험, 개발자라면 다들 한 번쯤은 있다고 생각한다. 나는 일단 한 손으로 셀 수도 없다. 반성하자.
결론은 딱 세 가지이다.
1. 루틴
2. 재미
3. 도전
나도 전적으로 위 세 가지에 동의한다. 물론 난 저것들을 지키지 못해 실패했다. 반성하자.
그리고 마지막으로 자본주의 세상에서 무엇을 만들어야 돈을 버는가?에 대해 고민하셨던 것을 말씀해 주셨다.
아무리 좋고 특별한 것을 만들어도, 그것을 좋아해줄 사람이 필요하다.맞는 말이다. 나는 여태까지 내가 재밌어 보이는 것들만 찾고 있었다. 물론 내가 지금은 일을 하고 있지만, 아직은 (휴)학생 신분이고, 금전을 크게 바라지 않아서일 수도 있다. 하지만 내가 무언가를 만들었을 때, 아무도 그걸 사용해주지 않는다면? 그건 정말 슬픈 일일 것 같다. 상상했더니 슬퍼졌다. 좀만 울고 오자.
모던 웹 기술로 C++ 기반 렌더링 엔진 테스트 자동화하기
하마터면 이것도 줄일 뻔 했다.
이것도 알찼다. 아주 좋았다. 내 취향이다.
강연자 분은 thorvg라는 C++ 기반의 애니메이션 런타임 소프트웨어를 개발하고 계셨다.
물론 완벽한 것은 없기에 애니메이션이 제대로 렌더링이 안되는 문제가 생길 수도 있었다. 그래서 이 또한 테스트가 필요한데, 만약 나한테 100개의 애니메이션을 주고 테스트 해주세요! 라고 말을 한다면? 아마 머리에서는 퇴사 생각이 끊임없이 날 것이며, 내 눈은 빠질 것이다.
그래서 이를 테스트할 자동화 도구를 만들기 위해 웹에 만들어진 애니메이션과 원하는 애니메이션을 올리면 이를 비교하는 것을 만드셨으며, 이를 CLI로 실행시키시는 것마저도 만드셨다.
하지만 위에서 썼듯이 C++ 기반의 소프트웨어를 어떻게 웹이랑 접목할까?
그런 당신에게 WASM을 드리겠습니다.
이 이후부터는 웹 어셈블리 접목기 및 CLI 생성기였다.
이것도 재밌어서 설명하고 싶긴 한데... 너무 길어질 것 같아 유튜브를 직접 보시는 걸로 결정하기로 했다.
참고로 puppeteer를 이용한 Headless Browser를 이용해 CLI로 만드는 것은 정말 좋았던 것 같다. 내가 이걸 이용할 날이 올 지는 모르겠지만, 개인적으로 만들어볼 날이 오면 좋을 것 같다. 지금은 이걸 사용해서 뭘 만들어야 할 지 모르겠다.
결론은 WASM 짱이라는 것이다.
그리고 매 쉬는 시간마다 복도에서 개발자들끼리의 토론 및 친목 도모가 이루어지고 있었는데, 요즘 친한 사람들이랑만 놀아서 파워 I라는 것을 망각하고 있었던 나는 다시금 이 사실을 깨닫는 시간이었다.
그냥 정처없이 떠돌아다니다가 용기를 내 다가갔더니, 네이버에서 프론트 리드를 하시는 분이랑 얘기를 하게 되었다. 그 분께서 Angular보단 Angular에서 제공하는 구조? 그 비스무리한 것을 굉장히 열심히 설명해주셨다. pipe로 데이터를 가공하고 guard로 분기를 처리하는, 그런 식으로 파일을 분리하여 프로젝트를 관리하는 걸로 설명을 들었는데 Angular는 한 번도 안해봐서 처음엔 뭐지? 싶다가 점점 빠져들었다. 일단 한 번 해보고 싶어졌다.
만약 Angular를 영업하신 거라면 대성공하신게 아닐까 싶다.
메타버스 서비스(ZEP)에서 WebRTC를 함께 적용하기
메타버스. 참 오랜만에 듣는 단어이다.
WebRTC. 참 재밌을 것 같은데, 쉽게 접근하지 못하는 단어이다. 나만 그런가.
아무튼 WebRTC라는 단어에 이 세션을 좀 기대했는데, WebRTC보단 아래 2개에 초점이 맞추어져 있었다. 물론 재미없었다는 소리는 아니다. 재밌었다. 진짜 재밌었다.
- Angular React 로의 마이그레이션
- RxJS와 함께 리팩토링하기
솔직히 머리로는 이해했는데, 정말 머리로만 이해했다.
난 저 내용을 도저히 글로 설명할 자신이 없다. 솔직히 캔버스, WebRTC, 상태 관리, 이 셋은 그냥 이해하라해도 이해 못하겠는데 한 번에 들어오니까 머리 터질 뻔했다. 저걸 만든게 내가 아니라 다행이다.
정말 미안하지만 내 실력이 미천하여 유튜브를 보시는 것을 추천한다.
7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기
토스에서 플랫폼 서버를 이용해 아래 7개를 해결 및 개선한 얘기를 해주셨다.
- 이미지 최적화
- 비디오 썸네일
- 폴리필
- 스켈레톤
- 에셋
- 오픈그래프
- 웹모듈
일단 먼저 내가 이 세션을 듣고 들었던 생각은 '개선한 방식은 정말로 좋다. 이런 생각을 하신게 정말 대단하다는 생각이 든다. 하지만 역시 돈이 최고다'였다. 솔직히 문제 해결 및 개선을 위해 서버를 띄운다. 무려 7개나. 보통이라면 하지 못할 것 같다...
위 7개 중 가장 재미있었던 부분은 폴리필 및 웹모듈 부분이었다.
UserAgent를 이용하여 필요한 폴리필을 제공하는 CDN은 정말 좋은 생각이다. 물론 이를 이미 제공하는 polyfill.io가 있었다고 하셨다. (왜 있었다인지는 좀 가슴아프긴 하다)
또한 웹모듈을 이용하여 ESModule만 받는 프레이머를, CommonJS를 사용하는 Toss Design System에 도입한 사례도 정말 좋게 들었다.
나머지 5개 및 트러블 슈팅까지도 다 설명하면 너무 길다. 이 또한 유튜브로 가자.
유튜브 신은 모든 걸 알고 계시다.
이제부터는 진지한 이야기
모든 세션이 끝나고 집까지 가는 길에 많은 생각을 했다.
내가 물리적 이슈로 모든 것들을 들을 순 없었지만, 내가 들었던 것들만 해도 다들 재미있는 것들을 만드셨으며, 만드시고 계시는구나라는 생각이 들었다.
솔직히 지금 회사에서 하는 FE는 재미가 없다. 왤까.
개발은 재밌다. 오늘 들은 강연만 봐도 FE에 재밌는 부분은 차고 넘친다. 그러면 왜 회사에서 하는 일이 재미가 없는가? 생각해보면 도전이 없어서 그런 것 같다. 퀄리티는 중요하지 않은 채로 결과만 뽑아내면 되는 곳에서 나는 도전정신을 잃어가고 있는게 아닐까 한다.
이 생각을 하며 사이드 프로젝트 관련하여 강연을 하셨던 분의 결론을 마음에 되새겼다.
사이드 프로젝트를 지속하기 위해서는 도전또한 필요하다. 이는 사이드 프로젝트 뿐만 아니라 본 프로젝트 또한 마찬가지인 것 같다. 도전하지 않으니 프로젝트에 애정이 안가고, 애정이 안가니 더더욱 도전하지 않게되는 것 같다. 그러니 프로젝트 코드는 엉망이 되어가는데, 그것조차 신경을 안쓰는 나를 합리화하는 나 자신이 싫어질 때도 있었다.
뭐, 솔직히 내가 지금 회사에 병역특례로 일하고 있고 1년도 안남았는데, 여기서 마음을 고쳐먹고 열심히 하고 싶지는 않다. 그냥 내 마음이 그렇다. 대신 여기서 열심히 안하는 만큼 다른 곳에 열정을 쏟아보자. 일단은 이번에 다시 들어간 GDSC부터 열심히 해보도록 하자.
