1. FEConf2024 행사 참여 후기
인프콘은 매번 탈락하고 오프라인 행사에 참여하지 못하여 아쉬웠는데, 이번 FEConf는 신청이 끝날 무렵에 취소표가 많이 생겨서 오프라인으로 참여할 수 있는 기회가 생기게 되었다.
모든 세션에 대한 발표 내용을 정리하는 것보다는 가서 몸으로 느꼈던 행사의 느낌과 일부 세션에 기억이 남았던 것을 위주로 작성해보려고 한다.
🔥 분주했던 행사 참여일지
나는 B에서 진행하는 발표 위주로 컨퍼런스를 들었는데, 그중에 모든 세션을 제대로 들었던 것은 '바퀴 대신 로켓 만들기' 와 '7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기'이다. 모든 발표를 제대로 듣지 못했던 이유는 일단 A, B에서 진행하는 발표는 유튜브에 올라오기 때문에 오프라인에서만 느낄 수 있는 것을 참여해보고 싶었던게 컸다.
그래서 굿즈를 나눠주는 부스에서 이벤트에 참여하기도 하고, Lightning Talk은 오프라인에서만 볼 수 있는 것이라 여기에 참여하는 것을 위주로 돌아다녔다. 행사를 진행하는 곳이 지하 2층에 사람도 많아서 그런지 네트워크가 매우 느렸다... 굿즈 이벤트가 대부분 QR로 링크에 들어가 설문을 하거나, 무언가 참여를 해야하는게 많았는데 느리다 보니 시간을 많이 뺏기게 되었던 것 같다.😭
그리고 라이트닝 토크는 오픈된 곳에서 4개의 부스로 운영되어 있었는데, 미리 가있지 않으면 뒤에 서서 들어야 했기에 소리가 잘 안들려서 아쉬웠던 부분 중에 하나였다.
내가 들었던 세션에서 기억에 남았던 부분을 적어보려고 한다.
🧠 기억에 남았던 발표들
'바퀴 대신 로켓 만들기'
프론트엔드 개발자로 일하다 보면 한번쯤은 겪어보는 상황에 대해서 어떻게 풀어나갔는지에 대해 발표를 진행해주었다.
디자인, 서버, 기획자를 기다린 이후에 프론트엔드 개발자가 일을 해야한다는 프로세스를 겪어 시간이 지체되었는데,
이를 해결하기 위해 일하는 방식을 바꾸었던 이야기를 풀어주었다.
1. 디자인과의 병목을 없애보자
토스 디자인 시스템 사용 -> 여러 계열사를 맞춰야하기 때문에 토스페이먼츠 만의 디자인시스템으로는 맞출 수는 없었다.
페이먼츠만의 별도 프로덕트 시스템을 개발(아토믹한 범위를 벗어나 가장 큰영역(스크린)까지 적용)
화면 자체를 컴포넌트로 만들어 반복되는 작업을 제거
2. 백엔드와의 의존성을 끊기
API 보다 인터페이스가 있으면 개발이 가능
-> API 스펙 문서만으로는 한계를 느낌
OpenAPI Code Generator를 사용 -> 원하는 스펙을 충족시키지 못해 직접 구현(토스 페이먼츠 CodeGen)
API 문서를 수정하여 코드를 빠르게 수정할 수 있게 됨 ⭐️⭐️
이 부분은 내가 보았을 때 이게 '진짜' 개발자로 일을 하는 방식이구나라고 느꼈다. 문서를 통해 코드까지 자동화를 붙여서 의존성을 제거한 부분이 인상깊었다.
3. 제품과의 의존성을 끊기
개발 생태계가 풍부해서 비효율이다라고 했는데, 처음에는 무슨 말인지 못알아 들었다.
그러나 여기서 말하는 비효율이란 프론트엔드 기술이 매우 많은데 그걸 사용하는 것이 모두 다르고 활용방식도 다르니 그부분에 있어서 비효율이 나온다는 것을 의미했다.
ex)
어드민을 만들때 반복되는 작업들의 비효율을 제거한 예시이다.
- refetch: 명시적으로 resource를 선언해 API를 추상화하였다.
- 로깅처리: useContext를 사용해서 주입시켰기 때문에 알아서 로깅이 가능
바퀴 대신 로켓 만들기: https://www.youtube.com/watch?v=B7hhxG1qUf8
'7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기'
토스 앱에 웹뷰로 사용되는 서비스에 7가지 서버를 통해 어떻게 효과적으로 관리할 수 있는지에 대한 이야기를 주로 다루었다.
이때 회사에서 작업을 했던 고민과 동일한 내용을 발표해 놀랐다.
바로 오픈그래프에 대한 방식이었는데, 동적으로 이미지를 og 이미지를 보여주고 싶다면 어떻게 처리하는지에 대한 것이었다.
실무에서는 텍스트마다 이미지를 모두 받아서 그려줄때 분기로 처리해서 해야하나? 그럼 점수같은 것들을 공유한다면 100개의 이미지를 가지고 있어야하나..? 이런 고민들을 했었다.
그러나 모든 이미지를 가지고 있는 것이 아닌 배경 이미지 + 아티클 제목을 동적으로 조합해서 그려주는 방식을 사용한 것이었다. 기회가 되면 실무에서도 활용하고 싶은 부분 중에 하나였다.
7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기: https://www.youtube.com/watch?v=C2HCHVXJNPs
마지막으로 오프라인 행사에 참여하면 빠질 수 없는 굿즈들이다.
2. 인프런 퇴근길 밋업 참여 후기
FEConf가 끝나고 난 다음주에 인프런에서 달마다 진행하는 퇴근길 밋업에도 참여할 수 있었다.
테스트 코드 작성에 대한 주제로 발표를 진행하였는데, 평소에 가지고 있던 테스트 코드에 대한 생각과는 새로운 방향의 이야기를 해주었던 것 같다.
1️⃣ 발표 세션
테스트는 단위 테스트, 통합 테스트, E2E 테스트로 나눠볼 수 있는데 이때는 통합 테스트를 적극 활용하는 것으로 이야기 해주었다.
E2E 테스트는 단점이 치명적 → 테스트하는데 드는 비용이 많음, 빠른 피드백이 없음, 효과적이지 않음
단위 테스트는 테스트를 하기에 적절하지만, 프론트엔드 입장에서는 부족한 부분이 존재한다.
왜냐하면 프론트엔드의 view의 복잡도가 많이 올라간 상태이기 때문이다.
스토리북(StoryBook)을 라이브러리라고 생각하지 말자
컴포넌트가 여러 state를 가지고 한페이지 내에 모두 보여주는 것 자체가 storybook이라고 부른다.
⇒ 컴포넌트를 독립적으로 렌더링할 수 있음(의존성이 사라짐)
스토리북을 사용하면 여러 상태를 미리 보고 컴포넌트의 상태를 확인할 수 있는 장점이 있다.
ex) 실제 계정을 삭제하지 않아도 된다.
보다 자세한 내용은 발표자료를 확인해보는게 더 도움이 될 것 같아 링크로 남겼다.
2️⃣ 네트워크 세션
발표 세션이 끝나고 서로의 네트워킹을 진행하는 시간도 가졌는데 내가 속한조는 4명으로 구성된 조였다.
다들 어떤 회사를 다니는지, 회사에서는 어떤 일을 하는지에 대해 짧게 이야기를 나눌 수 있는 시간이었다.
네트워크 시간을 통해 다른 개발자들은 무슨 고민을 가지고 있는지, 나는 무슨 고민을 가지고 있는지 말하면서 시간을 보냈던 것 같다.
네트워킹 세션 2차전(🤫)
여기서 나는 신기하게도 끝나고 발표자 분과 같이 사적인 자리를 갖게 되었다. 🤣🤣
이 자리를 가게 된 사연이 있는데, 일단 지금 진행하고 있는 스터디에 한 분(A)이 밋업에 오셔서 인사를 나눌 수 있었고, 나와 네트워킹 같은 조에 계셨던 한 분이 인프런에서 강의를 찍으시던 분 - B이었다.
근데 B분이 A와 전에 스터디를 했어서 알고 있었던 사이였고 집가는길에 같이 가면서 맥주를 마시러 가게 되었고,,, ㅋㅋㅋ B분이 또 발표자 분(탐정토끼)과 친분이 있었다. (정리하자면, 나 ↔ A, A ↔ B, B ↔ 탐정토끼)
결국 4명이서 사적인 자리를 가지게 되는 신기한 경험을 하게 되었다. 의외로 세상은 너무 좁다는걸 새삼 깨닫게 해주었다 ㅋㅋㅋ
다음 퇴근길 밋업도 올라와서 바로 신청을 한 상태이다.
판교 퇴근길 밋업 with 인프런 #07 오픈소스
