2021년부터 프론트엔드 개발자로서 커리어를 쌓아왔다. 당시 프론트엔드 생태계는 엄청나게 빠른 트렌드 변화의 중심에 있었다.2021년 당시 표준 보일러플레이트는 React + Webpack + Babel 기반의 CRA(Create React App)였으며, JavaScript가 주류였다.상태 관리는 MobX도 있었지만, Redux 가 시장을 지배하던 시절이었다.그러다 조금이라도 커스텀 설정이 필요하면 CRA를 eject해야 했는데, 직접 Webpack을 관리하는 것은 매우 까다로운 작업이었다. 앱이 복잡해질수록 안정성 문제가 대두되었고, 정적 분석의 필요성에 대한 논의가 활발해지면서 React에서도 본격적으로 TypeScript를 지원하기 시작했다.한편, 모듈 표준 문제로 진통을 겪던 JS 진영은 Com..
서비스가 성장하다 보면 반드시 마주치는 순간이 있습니다. 어제까지 멀쩡하던 API가 오늘은 유난히 느려지고, 서버 팀에서는 "데이터가 너무 많아서 인덱스를 타도 한계가 있다"거나 "리소스 증설이 필요하다"는 이야기가 들려오기 시작하죠.하지만 모든 문제의 해답이 서버에만 있는 것은 아닙니다. 때로는 프론트엔드에서 사용자의 기다림을 정의하는 방식을 바꾸거나, 서버로 향하는 요청의 성격을 조정하는 것만으로도 시스템 전체의 가용성을 드라마틱하게 높일 수 있습니다. 제가 실무에서 겪었던 두 가지 '프론트엔드에서 시작한 최적화' 사례를 통해, 우리가 어떻게 서버의 압박을 덜어내고 사용자의 경험을 지켜냈는지 공유하고자 합니다.1. "기다리게 하지 말고, 과정을 공유하세요"엑셀 대량 작업 생성의 비동기 전환로봇 물류 ..
자율주행 로봇이 활약하는 물류 현장. 이곳은 겉으로는 첨단을 달리는 듯 보이지만, 개발자에게는 예측 불가능한 네트워크 환경과 싸워야 하는 전쟁터입니다. "로봇은 잘 움직였다고 하는데, 왜 우리는 문제를 재현할 수 없을까?" 이 질문은 현장에서 흔히 마주하는 답답함이자, '재현 안 되는 버그'의 시작점입니다. 로그는 부족하고, 고객의 이야기를 들어도 핵심 맥락을 놓치기 일쑤죠. 이 글은 이런 현장 속에서 저희가 어떻게 문제의 실마리를 찾아내고, 운영의 안정성을 확보했는지에 대한 이야기입니다.1. 답답한 현실: "무엇이 문제인지 아무도 모른다"서비스 초반, 몇 대 안 되는 로봇을 운영할 때도 문제가 생기면 그야말로 '맨땅에 헤딩'이었습니다. 현장에서 "로봇이 이상했어요"라는 제보가 들어와도, 그게 시스템 문..
- Total
- Today
- Yesterday
- css
- frontend
- hooks
- 생활코딩
- project
- Firebase
- NomadCoder
- RUBY
- Python
- redux-toolkit
- Django
- 드림코딩
- nrc
- 트위터 클론
- Class
- 오버라이딩
- html
- 기능추가
- instagram CSS
- JavaScript
- 그림판 만들기
- 프론트엔드
- Build your own React
- 바닐라js
- React
- github
- TypeScirpt
- object
- nodejs
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |