FE 개발자 관점의 인프콘 2024 참관 후기
타이핑은 내가 요약 정리는 GPT가 :)
일정 : 2024.08.02
장소: 코엑스
개인적인 소감
개발/디자인/PMPO 현업/취준생등 타겟팅이 넓었던 만큼 대부분 깊이가 있는 내용을 다루진 않은것 같다.
몇년만에 오프라인 컨퍼런스 및 코엑스를 방문해서 묘한 기분이었다.
강의를 다 들을려니 너무 시간이 촘촘하고 쉬는 시간이 없었다.
발표는 항상 거창한 주제가 아니어도 누군가에게는 도움이 될 수 있겠다는 생각이 들었음
굿즈는 덤 ㅎ아래의 내용은 열심히 현장에서 타이핑 하고 GPT를 시켜 정리해본 내용이다. 나중에 참고 해볼 수 있도록 기록!
0. Keynote
글로벌 사용자 타겟으로 확장 해 갈 예정이라고 함.
ai서비스 인상적 (더빙 자막 등 강연 자료를 손쉽게 다양한 언어로 제공하기 위한 장치), 실제로 외국인이 인프런에서 언어의 장벽을 넘고 수강하고 수강평을 남긴 사례도 있었다고 한다.
CEO보다 PT를 잘하시는 향로님 (?)
1. React Native와 함께 인프런 앱 새로 만들기
인프랩의 RN를 통한 신규앱 개발 , Native App 개발자 + FE 개발자 구성
써드파티와의 호환성 문제로 RN의 신규 아키텍쳐를 쓰지 못하고 개발 했지만 나름 괜찮았다
FE 개발자 입장에서는 아직 RN은 선택하기 어려워 보인다.
인프랩 모바일셀 발표
React Native (RN) Old Architecture 사용 이유
안정성 문제: 새로운 아키텍처는 아직 충분히 안정적이지 않음.
성능 벤치마크: 구 아키텍처와 신 아키텍처 간의 성능 차이가 크지 않음. (직접 비교 자료를 사용하여 설명)
Native Component 협업 구조
협업 구조: 프론트엔드 개발자와 앱 개발자가 협력하여 작업.
이중구현 문제: 네이티브 기능들은 많은 경우 이중구현이 필요.
Player 직접 구현: 미디어 플레이어를 직접 구현.
JS 사이드와 Bridge 통신: 브리지 통신을 통해 JS와 네이티브 간의 상호작용을 관리.
서드파티 라이브러리 의존성 이슈
서드파티 라이브러리 의존성: 새로운 아키텍처 사용 불가 이유.
iOS Orientation 이슈
웹뷰: iOS의 화면 방향 변경 문제.
디버깅 도구
Bridge 통신: 스파이를 통해 디버깅 가능.
GPT-Driven 개발의 미해결 이슈들을 가지고 !
GPT시대에 많은 업무들이 GPT의 도움을 받아 해결 가능하지만 그렇지 않은 이슈들을 가지고 왔다는 내용에서 많은 공감이 ㅎ
Prototype을 통한 디버깅: 네이티브에서 발생하는 비정상 동작을 프로토타입으로 디버깅.
웹뷰 vs 브라우저: 스펙 차이와 서드파티 라이브러리 문제를 해결하기 위한 덕타이핑등을 통한 해결 사례 소개
Patch-package: 서드파티 라이브러리를 패치하여 문제 해결.
Flash List: 리스트를 최적화할 때 고려해볼만한 서드파티 라이브러리. 그외의 다양한 리스트 최적화를 위한 방법을 소개 하였음
디버깅 디바이스 대응의 어려움
다양한 디바이스 환경에서의 디버깅이 매우 까다롭고 어려운 점.
2. 실리콘밸리 개발 문화 및 서바이벌 전략
Apple 본사 근무 엔지니어 SRE
미쿡엔지니어 (youtube)
스타트업 vs 대기업
엔지니어 주도
매니저 역할 중요도 선별 , 스케쥴 관리, 팀간 이슈해결
연봉 정보는 > levels.fyi
소프트웨어 개발 문화
혁신 중심
실패를 학습의 기회로
협업 & 커뮤니티
오픈소스를 적극 주도함 (회사에서 적극 장려 )
최신 기술
스타트업 정신
다양성과 포용
꾸준한 자기개발
Coursera,, OReilly
멘토링과 피드백
Philz Coffee (WWDC 2024에도 나왔다고 함 , 샌프란시스코 3대 커피 )
실리콘 밸리 서바이벌 전략
자기 PR
링크드인, 깃헙
기술블로그 미디엄
새로운 기술 트렌드
가르치면서 배워라 (강의 듣기보다 가르치기가 90%의 효과)
오픈소스 프로젝트 참여
Bytebytego, Wried
네트워킹
밋업, 해커톤
멘토링 관계
협업 능력
매년 리뷰
팀 멤버 동료간 평가
파레토 법칙 (2080법칙) 빠르게 개발하고 피드백 받는 방식
창의적사고
영어, Work Experience > 그 회사에서만 배울수 있는 경험
현상 유지에 안주하지 않고 끊임없이 도전.
3. 디자인시스템의 명과암
원티드랩의 디자인 시스템에 대한 이야기를 디자이너, FE개발자, UX엔지니어의 발표와 패널토론을 통해 알려줌
디자인 시스템을 도입하면서 얻을 수 있는 장단점을 대략적으로 파악 할 수 있었음
단일 프로덕트에서 디자인과 화면 개발의 퀄리티와 효율성 향상을 위해 디자인 시스템은 이제 필수 불가결한 요소 인듯함
세션 3: 디자인 시스템의 명과 암 요약
디자이너 발표
시간 절약: 똑같은 버튼을 만드는 데 시간이 오래 걸림 -> 디자인 시스템 도입으로 작업 속도와 퀄리티 향상.
프로토타입 활용: 디자인 시스템을 이용해 1시간 만에 디자인 초안 작성, 3일 만에 프론트 개발, 10일 후 기획 등으로 세부사항 마련.
원티드 디자인 라이브러리: 다양한 케이스 대응 필요.
디자인-개발 싱크: 피그마 기능 활용.
프론트엔드(FE) 관점에서의 디자인 시스템
디자인 시스템 TF: 단일 프로젝트에서 공통 컴포넌트로 만들기 위한 팀.
장점:
컴포넌트 재사용성과 일관성 증가.
디자이너와 개발자 간의 협업 효율 향상.
단점:
다른 서비스에 사용하기 어려움.
컨벤션, 반응성 대응 등 다양한 문제.
MUI, Chakra-UI, Primer 등 레퍼런스 참고하여 개선. (Box + Sx Props, 반응형 대응: Responsive Props. )
디자인 시스템 개발 시간 증가.
Headless UI: 스타일 없이 컴포넌트 기능 구현 및 접근성 처리 (Radix Primitives).
기술 활용:
Emotion을 활용한 엔진 구현.
Responsive Props, Radix Primitives 구현 -> 개발 시간 단축.
Figma의 코드커넥트 활용으로 지속적 고도화.
DX 개선
개발 관점 결론
지속적인 업데이트 및 개선 필요.
개발자와 디자이너 간 적극적인 커뮤니케이션 필요.
상황에 맞는 시스템 구축 권장, 급하게 다른 시스템을 따라할 필요 없음.
디자인 관점 결론
지속적인 업데이트 필요.
효율성과 퀄리티의 균형 필요: 디자인 시스템은 효율성을 추구하지만 디자이너는 퀄리티 중시 -> 과정 중심 유지.
상황에 맞는 다양한 방식을 고려.
패널 토크
1) 디자인 시스템에서 원칙을 벗어나는 요구사항:
커스텀 속성을 변경해도 커스텀 요구 발생 -> 디자인 시스템 사용 의문.
컴포넌트 별 커스텀 속성 정의 및 피드백 루프 중요.
2)디자인 인력이 없는 경우에도 시스템 필요성:
찬반 갈림, 어느 정도 시도 필요.
디자이너가 툴이나 시스템 개념에 대한 필요성 인정.
간소화된 시스템(컬러, 아이콘 등) 시도 권장.
단일 진실 공급원 상태 마련.
3) 디자인 가이드 vs 디자인 시스템:
일관성 유지.
가이드 준수 체크에 큰 개발 공수 필요.
디자인 시스템은 초기 투자 비용 크고, 지속 관리 및 학습 필요.
4) 디자인 시스템 구축 시기:
MVP 단계 이후, 불필요한 컴포넌트 제거 및 코드 상태 개선 후.
5) 디자인 시스템 전파 방법:
디자인 시스템의 도움 여부 피드백 기회 마련.
세부 스타일 디테일 조정으로 공감대 형성.
개발엔 playground 문서와 GitHub Discussions 활용.
6) 디자인 시스템 구축 보람:
개발자, 디자이너, 마케터 등 다양한 인원들의 긍정적 피드백.
4. 처음으로 기술 리더가 된 개발자를 위한 안내서
토스의 프론트엔드 조직을 이끄는 분의 다양한 생각을 들어 볼 수 있었음
조직원을 케어하기 위한 경험적인 내용을 잘 표현 해주신거 같음
아는것 보다 실천하는것이 중요하지 않을까 언젠가 기술 리더가 된다면 한번쯤 리마인드 해보면 좋을거 같은 내용
프론트엔드 엔지니어링 리더십
조직 규모: 프론트엔드 엔지니어링 팀 80명 이상.
기술 리더 공략:
같은 행동 다른 결과를 초래함.
경량적 지표의 실패 사례.
동료들이 리더를 좋아하고 신뢰하는지 중요.
팀원이 리더를 믿고 신뢰하는 7가지 순간
유능함
팀 역량 자체보다는 팀원의 문제를 해결하는 것이 중요.
팀원의 '진통제' 역할을 하자.
가장 고민하거나 귀찮아하는 일을 도와줌.
잃어버린 물건을 찾는 비유.
모르는 일도 질문을 통해 도울 수 있음.
관심
말하는 방식에 차이가 있음. 동감과 공감이 중요.
관심을 표하며 티 내기.
원활한 소통
티키타카(정확한 주고받기).
리더와 팀원의 유사성
리더의 작은 정보(TMI) 공유.
심리적 안정감
지배와 리드의 차이: 지배는 구체적인 지시, 리드는 덜 구체적인 지시.
예측 가능하고 투명한 리더십.
진실된 칭찬에 익숙해지자. 모든 팀원에게는 칭찬할 부분이 있음.
예측가능성
팀원에게 예측 가능한 피드백 제공.
상호 동의할 수 있는 사실부터 시작.
기대 수준에 대한 명확한 정의와 상호 소통.
공동 목표
리더와 팀원의 목표를 합친 공동의 목표 설정.
5. 난생처음 만드는 Vite 플러그인
이전에 개발바닥에서 봤던 FE개발자 분의 강연이라 들어봄
Vite 플러그인이 어떻게 만들어지는지 살펴보진 않았지만 이번 강연을 통해 대략적인 플로우를 쉽게 알수 있었음 (강의를 하시는 분인가 쉽게 잘 설명 해주심)
대략 플러그인이 이런이런 동작을 통해 만들어진다는 것을 알고 다른 작업을 하기 위한 시간을 아낄 수 있길 바란다는 말씀이 와닿았음.
혼자 공부하는것 보다 동료와 같이 학습하고 나누는 것에서 시너지가 생긴다.
Vite Plugin 요약 및 가이드
Vite Plugin 역할:
Vite 플러그인은 Vite 개발 서버와 빌드 프로세스를 확장하고 사용자 정의 기능을 추가하는 데 사용됩니다.
Rollup 및 Bundler:
Rollup: Vite는 Rollup 기반으로 동작하여 번들링을 처리합니다.
Tree-shaking: 사용되지 않는 코드를 제거하여 최적화.
Avoid next waterfall: 번들링 시 후속 요청을 줄여서 빌드 성능을 향상시킴.
Vite Dev Server:
Vite는 빠른 개발 서버를 제공하여 HMR(Hot Module Replacement)과 빠른 컴파일을 가능케 함.
Vite Build:
Vite 빌드는 Rollup을 사용하여 전체 프로젝트를 번들링합니다.
Rollup/Vite Plugins
호환성과 유사성:
Vite 플러그인은 Rollup 플러그인과 매우 유사하며 호환성이 높습니다.
핵심 Hook:
resolveId
역할: 특정 모듈이나 파일의 ID를 결정.
파일/확장자를 처리할 수 있는 경우, 소스 내용을 반환.
load
역할: 해당 모듈 파일의 내용을 불러와서 반환.
transform
역할: 모듈 파일 내용을 특정 형식(JSX -> JS 등)으로 변환.
전체 파일 내용을 처리.
Virtual Module:
빌드 타임에 가상의 모듈을 만들어 처리 가능.
빌드 타임에 미리 데이터를 처리하여 번들 된 결과물에 비즈니스 로직 없이 처리 결과만 포함.
예시: 무거운 계산, Git 정보 얻기, 로컬 파일 접근, DSL 구현 등.
6. 객체지향은 여전히 유용한가?
오프젝트라는 책으로 유명하신 조영호 님의 강의
객체지향에 대해 어떤 이야기를 할까 궁금해서 강의를 들어 봤는데, 대학 전공 강의를 들은 느낌이었다
객체지향이 필요한 시점과 절차지향이 무조건 나쁜건 아니고 모든 방법에는 트레이드 오프가 있다라는 관점이 좋았다
실제 코드를 통해 요구사항에 따른 변화에 따라 각각의 장단점을 비교해보는 과정이라 재미 있었고 까딱하면 따라가지 못할까 잔뜩 긴장하고 들었던 강의
세션 6 요약: 객체지향은 여전히 유용한가?
절차적 vs 객체지향 프로그래밍
절차적인 설계 (데이터와 로직이 별도로 분리됨.)
객체지향적 설계 (데이터와 로직이 같은 클래스 내에 위치.)
변경 포인트
데이터 변경 시
절차적 설계: 데이터를 바꾸면 무조건 데이터를 사용하는 클래스도 바뀜 (높은 결합도).
객체지향적 설계: 하나의 클래스만 변경하면 되는 캡슐화가 되어 있음.
새로운 타입 추가 시
절차적 설계: 모든 관련 클래스를 수정해야 함.
객체지향적 설계: 다형성을 활용하여 새로운 클래스를 추가해도 기존 코드를 많이 수정할 필요 없음.
객체지향의 강점
일관성 있는 설계: 동일한 구조로 코드가 커질 수 있음.
확장성: 새로운 타입과 기능 추가가 용이.
특정 기능 추가 시 고려사항
장바구니 항목을 이용한 할인 여부 판단 기능 추가
절차적 설계: 메서드 추가는 쉽지만, 새로운 할인 타입이 추가되면 많은 메서드를 수정해야 함.
객체지향적 설계: 인터페이스를 통해 확장을 해두면, 많은 인터페이스를 수정해야 하지만 전체 구조의 큰 변경은 피할 수 있음.
데이터 변환 고려사항
절차적 설계: 데이터 변환 코드를 손쉽게 작성 가능.
객체지향 설계: 타입에 따라 객체를 나눠서 두므로 타입 캐스팅과 데이터 추출이 필요.
객체와 데이터
객체지향 : 행위 중심의 동작 처리. 로직이 행동 중심인 경우 유리.
절차적 : 데이터 중심의 행위 지향 처리.
레이어별 적용
도메인 레이어: 객체지향, 규칙 기반의 상태 변경.
프리젠테이션 레이어: 절차적, 데이터 변환.
서비스 레이어: 절차적, 응용 프로그램 플로우 처리.
퍼시스턴스 레이어: 절차적, 데이터 변환.
객체지향의 유효성 및 트레이드 오프
유효성
상황에 맞는 설계가 중요. 현재 작업하는 영역에 따라 객체지향이 유효하지 않을 수 있음.
트레이드 오프
코딩 목적 및 변경 방향에 따라 절차적 설계와 객체지향 설계 중 선택.
학습을 통해 결정 능력을 길러야 함.
7. OpenAPI Generator 실전편
OpenAPI Generator에 대해 단순 호기심으로 들어 보았음
자동화 적인 측면에서 많은 부분을 투자해야 겠지만 초기 비용으로 어느정도 효과를 뽑아내는지 궁금했는데
실전에서 맞이하는 트러블 슈팅이 주요 내용 이었음. 강연하시는 분은 좋다고 하지만 이걸 정말 써도 되는지 의문이 들었달까..
익숙한 머스테치, 핸들바즈가 중간에 나와서 신기 했음 ㅋㅋ
세션 7 요약: OpenAPI Generator 실전편
텍스트 요약
플다 CTO와 함께하는 OpenAPI Generator 실전편
SLASH 21 - JavaScript Bundle Diet
좋은 코드란 무엇일까요?
읽기 좋은 코드 vs 변경이 쉬운 코드
최고의 코드는 코드가 전혀 없는 코드: 최대한 코드 작성을 자동화하는 것이 최선.
코드는 정적임에도 시간이 가면 녹이 슬기 마련.
서버와의 소통을 위해 매번 코드를 작성하는 시간 낭비를 줄이기 위해 OpenAPI Generator를 활용.
Swagger를 자동화할 수 없을까?
OpenAPI Generator: 에서 명칭이Swagger Codegen 프로젝트에서 포크된 별도의 프로젝트.
OpenAPI Generator의 장점:
Backend 스펙을 변경하지 않고도 적용 가능.
좋은 기술이지만 사용자 풀이 적음.
많은 홍보를 통해 사용자 풀이 늘어나길 바람
OpenAPI Generator 사용기
생성기 선택: 다양한 생성기를 선택 가능 (예: typescript-fetch, typescript-axios 등).
생성기 커스텀 문제: 언어 문제: 한글 인코딩 문제 해결 필요.
별도의 코드 구현 또는 한글 사용을 피해야 함.
템플릿 엔진
Mustache 및 Handlebars: 대부분의 경우 Mustache를 지원.
API 스펙을 통해 프론트엔드 코드를 생성 가능.
템플릿 커스텀 시 주의사항:
템플릿이 지원하는 기능과 변수, 내장함수에 대해 잘 알아야 함.
템플릿 수정을 통해 더 맞춤형 코드를 생성할 수 있음.
생성기 옵션
다양한 옵션이 있는데, 상황에 따라 사용을 피해야 할 경우도 있음.
기타 주요 포인트
숫자 1이 올바른 JSON 타입인가?: JSON 타입 문제에 대한 고려.
서버와 버전 관리: feature PR -> OpenAI Generator -> Beta 버전의 라이브러리 배포.
추가 이점: 자동화
서버와 공통된 이름으로 소통.
특정 API 삭제 시 필드의 영향 범위를 빠르게 알 수 있음 (타입 체크 등에서 미리 확인 가능).
정리
OpenAPI Generator는 코드 자동화와 버전 관리, 서버와의 소통을 크게 개선할 수 있는 도구로,
특히 프런트엔드와 백엔드 간의 원활한 데이터 통신을 위해 중요
템플릿 엔진을 활용한 커스텀 코드 생성, 생성기 옵션의 적절한 사용, 그리고 버전 관리를 통해 더욱 효과적인 협업과 코드 유지보수를 가능하게 합니다.
