[INFCON 2024] 7년 동안 하나 만들었습니다

INFCON 2024에서 '7년 동안 하나 만들었습니다: 프론트엔드 개발의 결정적 순간'이라는 주제로 발표를 하였습니다.

현장 발표를 중심으로 발표 장표를 구성했기에, 발표 스크립트(abit.ly/kfbl36)와 함께 읽는 것을 권장합니다.

Transcript

1. AB180 이찬희 7년 동안 하나 만들었습니다: 프론트엔드 개발의 결정적 순간들
2. 3년 만드는 제품의 뒤?
3. 5년 만드는 제품의 뒤?
4. 7년 만드는 제품의 뒤?
5. 2024년의 에어브릿지
6. 2017년의 에어브릿지
7. 게임 Slay The Spire 중
8. 이벤트 로그인 airbridge.user.signin 레벨업 airbridge.achieveLevel 장바구니 담기 ( . . . ).addedToCart 광고 클릭 airbridge.adClick bridge.achieveLevel 레벨업 첫 번째 순간 처음으로 만든 기능
9. 1 측정할 행동들 가져오기 이벤트 2 메타데이터 생성 3 이벤트 ID와 이름 입력받고 4 API 호출해서 저장 첫 번째 순간 처음으로 만든 기능
10. 매우 큰 고객이 들어오며 문제 발생 → API 서버가 느려지고, 심지어 자주 다운됨 해당 고객의 이벤트 수가 다른 앱들의 1,000배 페이지네이션을 걸면 해결되겠지? 메타데이터가 일부만 존재 불완전한 UI 첫 번째 순간 처음으로 만든 기능
11. 첫 번째 순간 처음으로 만든 기능
12. 교훈 #1 데이터의 양과 변화량 UI = 데이터의 양 * 변화량
13. 데이터의 양과 변화량 교훈 #1 무한 스크롤 UI?
14. 교훈 #1 데이터의 양과 변화량 페이지네이션 렌더링 가상화
15. 교훈 #2 데이터의 참조를 쉽게 📊 데이터 스펙 🔐 IAM 사용자 권한 제어 🌏 I18N 다국어 지원 🏁 피쳐 플래그
16. 교훈 #2 데이터의 참조를 쉽게 📊 데이터 스펙 🔐 IAM 사용자 권한 제어 🌏 I18N 다국어 지원 🏁 피쳐 플래그
17. 교훈 #2 데이터의 참조를 쉽게 📊 데이터 스펙
18. 교훈 #2 데이터의 참조를 쉽게 자주 쓰는 값을 기준으로 묶기: 정규화 Normalization
19. 교훈 #2 데이터의 참조를 쉽게 30,000 + 양도 많고, 참조도 빈번하면? Map 사용하기 빠른 성능 따라오는 가독성
20. 두 번째 순간 캘린더 컴포넌트 데이트 피커
22. 두 번째 순간 캘린더 컴포넌트 데이트 피커 ???: 내가 만들어도 지금 쓰는 라이브러리보다 잘 만들겠다
23. 두 번째 순간 캘린더 컴포넌트 데이트 피커 3일, 7일 단위의 블록 선택 연산자 예. 최근 3일 사용자의 타임존 적용 시간, 날짜 변경시 상태 동기화 예. 자정에 날짜 넘어갈 때
24. 3일, 7일 단위의 블록 선택 두 번째 순간 캘린더 컴포넌트 데이트 피커 3일, 7일 단위의 블록 선택 사용자의 타임존 적용 시간, 날짜 변경시 상태 동기화 연산자 예. 최근 3일
25. 3일, 7일 단위의 블록 선택 두 번째 순간 캘린더 컴포넌트 데이트 피커 3일, 7일 단위의 블록 선택 사용자의 타임존 적용 시간, 날짜 변경시 상태 동기화 연산자? Last N Days의 Last는 오늘을 포함하지 X
26. 3일, 7일 단위의 블록 선택 두 번째 순간 캘린더 컴포넌트 데이트 피커 3일, 7일 단위의 블록 선택 시간, 날짜 변경시 상태 동기화 연산자 예. 최근 3일 고객이 지정한 타임존 적용
27. 두 번째 순간 고객이 지정한 타임존? 최신 버전의 타임존 브라우저마다 구현체 다름 특정 버전의 타임존 1 특정 버전의 타임존 2 DB 백엔드 라이브러리 브라우저
28. 두 번째 순간 예상과는 너무 달랐던 실제 작업들 오늘 포함 이 적용되는 연산자, 커스텀 타임존 플러그인 등 내 코드에 내 발등이 찍혔다 건드릴수록 점점 복잡해지는 코드 이제 아무도 캘린더를 건드리고 싶지 않아함
29. 복잡도를 이해하기 Time Complexity Space Complexity
30. 문제 자체의 복잡도 해결 방법의 복잡도 Time Complexity Space Complexity Problem Complexity Solution Complexity 복잡도를 이해하기
31. 복잡도를 이해하기 가치에 대한 예측이 불확실할수록 바로 구현하는 것보다 옵션이 지닌 가치가 더 커집니다. Kent Beck, 『켄트 벡의 Tidy First?』 중
32. 교훈 #3 오류가 나면 터지게 두자 조건문 과도하게 촘촘히 적기 코드의 양은 많은데 중요한 로직은 아니라면? 왜 돌아가는지 알 수 없다면 시한폭탄과 다를 바 없다 작업을 자주 멈추고 되돌아보자 지금 중요한 부분은 무엇인지, 작업 크기가 충분히 작은지...
33. 교훈 #4 그리고, 고치고, 만들고 결과물을 상상하며 먼저 그려보기 <DatePicker from='YYYY-MM-DD' to='YYYY-MM-DD' option= { { operator: 'last', delta: 7, granularity: 'day', } } column={2} onChange={() = > { } } / >
34. <DatePicker from='YYYY-MM-DD' to='YYYY-MM-DD' option= { { operator: 'last', delta: 7, granularity: 'day', } } column={2} onChange={() = > { } } / > 교훈 #4 그리고, 고치고, 만들고 결과물을 상상하며 먼저 그려보기 스스로 혹은 주변에 물어보기 어려운 느낌을 주는 곳이 있나요? 혹시 제가 빠뜨린 게 있을까요? 어떤 동작을 할 것 같아요?
35. 교훈 #4 그리고, 고치고, 만들고 결과물을 상상하며 먼저 그려보기 스스로 혹은 주변에 물어보기 <DatePicker value={datetime} onChange={() => { }} > <DatePicker.Trigger /> <DatePicker.Popup> <DatePicker.Grid column={2} /> <DatePicker.Controller> <DatePicker.Cancel /> <DatePicker.Submit /> </ DatePicker.Controller> </ DatePicker.Popup> </ DatePicker>
36. 교훈 #4 그리고, 고치고, 만들고 결과물을 상상하며 먼저 그려보기 스스로 혹은 주변에 물어보기 <DatePicker value={datetime} onChange={() => { }} > <DatePicker.Trigger /> <DatePicker.Popup> <DatePicker.Grid column={2} /> <DatePicker.Controller> <DatePicker.Cancel /> <DatePicker.Submit /> </ DatePicker.Controller> </ DatePicker.Popup> </ DatePicker> 한 부분을 구현한 뒤에 테스트하기
37. 세 번째 순간 기술 교체의 순간
38. 액션을 매번 정의하기 번거로워요 상태가 어떻게 업데이트되는지 모르겠어요 기능이 많아서 상태도 너무 많아요 상태를 끌고오기 힘들어요 API 불러오는 타이밍이 안맞아요 요새 이거 안쓴대요 세 번째 순간 기술 교체의 순간
39. 세 번째 순간 기술 교체의 순간
40. 세 번째 순간 Proof Of Concept 도입해도 괜찮을지 테스트해보기로 함 벤치마크 돌려보니 Redux보다 좋은 성능 코드 일부를 바꿔보니 코드도 훨씬 간결해짐 ... 이거 안쓸 이유가 없겠는데?
41. 세 번째 순간 3년이 지난 후... 하지만 지금은 Recoil 도입 결정을 후회함 메인테이닝이 멈춘 라이브러리 상태가 어디서, 어떻게 쓰이는지 파악이 안 됨 디버거 없음 많은 곳에 적용해보니 작성할 코드가 되려 늘어남
42. 가위바위보에서 무엇을 내면 이길 확률이 높을까요?
43. 세 번째 순간 측정의 함정 가위바위보에서 뭘 내면 유리한지 논문만 몇백 편 실험, 정량적인 데이터도 있음 하지만 편향이 있기에 신뢰할 수 없다 기술의 도입 과정도 비슷하다 얻은 벤치마크, 측정한 자료 등이 잘못된 것은 아님 하지만 마음이 너무 앞서면 편향이 일어남 예 유리한 것만 POC, 주장을 뒷받침하는 것만 받아들임...
44. 교훈 #5 적절한 유예 스타일 프레임워크의 변천사 중 일부
45. 교훈 #6 거꾸로 뒤집기 Recoil 도입 상태의 쉬운 선언과 참조
46. 교훈 #6 거꾸로 뒤집기 Recoil 도입 상태의 쉬운 선언과 참조
47. 교훈 #6 거꾸로 뒤집기 Recoil 도입 Slice 적용 상태의 쉬운 선언과 참조
48. 교훈 #6 거꾸로 뒤집기 웹팩 설정이 복잡해서 어떻게 돌아가는지 모르겠어요 빌드 속도가 너무 느려서 답답해요 배포하는 환경마다 빌드 커스텀이 어려워요 기술 도입의 Sweet Spot
49. 7년이 지난 뒤 기능 수 8개 80개 팀원 2명 6명 코드 라인 20배 이상으로 증가
50. 하나만 꼽자면 리팩토링 의 의미가 달라진다 일반적 의미 옛날 코드 욕하면서 갖다버리고 새로 짜기 그런데 제품을 오래 만들게 되면...? 하나의 제품을 오래 만들면?
51. 하나의 제품을 오래 만들면? 끔찍한 코드에 git blame
52. 결국 욕 먹는 건 과거의 나 하나의 제품을 오래 만들면?
53. 하나만 꼽자면 리팩토링 의 의미가 달라진다 일반적 의미 옛날 코드 욕하면서 갖다버리고 새로 짜기 하나의 제품을 오래 만들면? 오래 하면 결국 욕 먹는 건 과거의 나 관찰, 경험을 통한 통찰을 코드에 녹일 수 있음 레거시를 유산 Legacy 으로 쓰기
54. 하나의 제품을 오래 만들면? Maturity Scale Complexity Rebuilding Cost 정해진 바닥 위에 쌓아올리기 바닥부터 만들기
55. 오늘 이야기한 것 뻔하게 예측 불가능을 전제로 움직인다 데이터 양, 변화량 등을 고려하며 사용자 경험을 구현하자 조건, 기능을 이르게 확정짓지 말자 오늘 짠 기능이 내일 버려져도 아쉬워하지 않는다 작고 독립적으로 돌아갈 수 있게 코드의 경계를 만들자 무언가를 했다는 기억과 경험을 자주 남기고 공유하자 이력서, 블로그 글 적절한 유예를 통해 마음이 모였을 때 적절한 결정을 내린다 새로운 기술이 나와도 적절히 유예하자 모두의 임계점을 넘는 순간에는 과감하게 결단하자 열심히 보다 더 잘할 수 있다 는 믿음이 필요하다 주기적으로 재방문하여 차이점을 비교, 기술적으로 개선하자
57. 오늘 이야기한 것 누가 개발자 되려면 이런 경험을 해야된다 고 말하면 도망치기 진짜 개발자 프레임을 씌우는 일부 사람들… 경험을 지나가는 순간에 아무것도 느끼지 못한다면? 같은 경험을 해도 누군가는 다른 의미로 기억할 것임 나의 결정적 순간
58. 무엇이 나의 결정적 순간이 될까?
59. 타이틀 Pretendard Semibold 36pt 감사합니다. hiddenest12 gmail.com hiddenest