코공기(코딩 공부 기록) 코공기(코딩 공부 기록)

프로젝트를 진행하다 보면 회의 일정이나 정기 미팅을 생성할 때 Google Calendar와 연동해야 하는 경우가 많다. 이번 프로젝트에서도 사용자가 등록한 회의 정보를 Google Calendar에 자동으로 등록하는 기능이 필요했고,서비스 계정을 이용하여 캘린더에 일정을 생성하는 방식으로 구현했다. 비슷한 작업을 진행할 일이 종종 있어 연동 방법과 일정 생성 로직을 정리해 두려고 한다. 1. Google Calendar API 설정Google Calendar API를 사용하기 위해서는 먼저 Google Cloud Console에서 API를 활성화하고 서비스 계정을 생성해야 한다. (1) Google Calendar API 활성화Google Cloud Console 접속프로젝트 선택 (없다면 새 프로젝트..

프론트엔드 개발을 하다 보면 서버와 데이터를 주고받는 작업을 끊임없이 하게 된다.예전에는 다음과 같이 useEffect와 useState를 이용하여 직접 API를 호출하는 방식이 일반적이었다.const [posts, setPosts] = useState([]);useEffect(() => { apiClient.get("/posts").then((res) => { setPosts(res.data); });}, []); 하지만 프로젝트 규모가 커질수록 다음과 같은 문제가 발생한다.로딩 상태 관리에러 상태 관리중복 API 호출캐싱데이터 최신화데이터 동기화이를 해결하기 위해 등장한 라이브러리가 바로 TanStack Query(구 React Query)이다.이번 글에서는 실무에서 가장 많이 사용하는 개념..

어떻게든 프론트엔드 개발자로 직무 전환을 성공해 입사한 지 3주 정도가 지났다.기술적으로나 심적으로나 새로운 환경에 적응하는 중인데, 생각보다 코드 자체보다도 어떻게 생각해야 하는가에 대한 고민이 많아졌다. 1. AI를 쓰면서 생긴 변화이전 회사에서 진행했던 프로젝트는 보안 환경 때문에 AI를 사용할 수 없었다.그래서 기능 하나를 만들더라도 직접 찾아보고, 구조를 고민하고, 시행착오를 겪으면서 구현할 수밖에 없었다.시간은 더 걸렸지만 자연스럽게 깊게 생각하는 습관이 만들어졌다. 사실 프론트엔드를 꿈꾸던 4년 전만 하더라도 AI가 지금처럼 발전할 것이라고는 생각하지 못했다.그 당시 내가 기대했던 개발자의 모습은 직접 고민하고, 직접 코드를 작성하고, 문제를 해결해 나가는 사람이었다.그래서 퍼블리셔로 일할 ..

최근 들어 회사 생활을 하면서 많은 생각이 들었다. 처음 일을 시작했을 때는 내가 맡은 업무를 잘 해내는 것이 가장 중요했고, 실제로 빠르게 작업을 처리하고 다양한 이슈를 해결하면서 팀에서 “에이스”라는 말을 듣기도 했다. 그 말이 처음에는 뿌듯하게 느껴졌다.하지만 시간이 지나면서 그 말이 꼭 좋은 의미로만 다가오지는 않았다.업무를 잘 처리한다는 이유로 점점 더 일정이 촉박하거나 난이도가 높은 작업들이 배정되기 시작했다. 특히 기획이나 디자인이 완전히 정리되지 않은 상태에서 퍼블리싱을 시작해야 하는 경우가 많았고, 작업을 진행하다 보면 뒤늦게 변경 사항이 생겨 다시 수정해야 하는 일이 반복되었다.문제는 이런 상황에서도 전체 일정은 그대로 유지된다는 점이었다. 기획이나 디자인 단계에서 지연된 시간은 줄어..

요즘 들어 유독 현타가 잦다.단순히 힘들어서라기보다는, 여기서 이렇게까지 열심히 일해야 할 이유를 더 이상 찾기 어려워졌기 때문이다. 나는 일을 싫어하는 사람이 아니다.야근도, 바쁜 일정도 마찬가지다.오히려 보람이 있다면 좋아하고 얼마든지 버틸 수 있고, 기꺼이 더 몰입할 수도 있다. 문제는 지금의 일이 보람과는 점점 멀어지고 있다는 점이다. 1. “우리가 다 해주고 있다”는 말 앞에서 드는 허탈감요즘 프로젝트를 진행하면서 가장 크게 현타가 오는 순간은 이런 상황이다. 개발자가 퍼블리셔인 우리에게 개발 관련 질문을 할 때 그 개발자들은 대부분 수석이거나 책임급이고그러므로 연차도, 연봉도 우리보다 높을 가능성이 크다.그런데 실질적인 구현과 정리는 우리가 다 해준다.심지어 작년에는 “퍼블에서 거의 다 해줘서..

Nuxt2에서 작업했던 페이지 중 Lottie 애니메이션을 무한으로 순차 재생하는 로직을 Nuxt3로 옮기는 중이었다.- 로띠 A → 완료- 로띠 B → 완료- 로띠 C → 완료- 다시 A로 돌아가 반복 각 로띠는 아래와 같이 동작하도록 구현했는데JSON을 fetch해서 animationData로 사용complete 또는 enterFrame 이벤트를 기준으로 다음 로띠 실행하나의 div를 ref로 잡아 destroy → loadAnimation 방식으로 관리Nuxt2에서는 이상없던 자식이 Nuxt3에서 이슈가 생겼다ㅜ1. 이상 현상포그라운드 상태에서는 정상다른 탭으로 이동했다가 다시 돌아오면:애니메이션이 멈추거나콘솔 로그가 무한히 찍히면서 페이지가 뻗음 2. 의심의 과정처음에 헛다리를 짚으면서 그 누구도..

0. 시작하며어느새 항해의 마지막 주차가 되었습니다ㅜ자세한 회고는 발표 자료에 첨부해두었지만 WIL로서의 회고 정도만 여기에 적어보겠습니다! 저번 주차 과제는 너무 어려워서 BP를 못받을 줄 알았는데 받아서 너무 기뻤습니다! 그리고 마지막 주차 과제는 저번 주차를 겪고 나니 너무 선녀였고 행복했습니다.. 하지만 뭔가 생각해보지 못했던 주제들에 대해 사고가 확장되는 좋은 과제였습니다.단순히 최적화만 해야지!가 아닌, 왜 해야 하고 어떤 걸 기준으로 할지 명확히 생각해볼 수 있는 시간이었습니다! 1. 과제10주차의 주제는 "코드 관점의 성능 최적화"였습니다. (1) 기본 과제(2) 심화 과제마지막 주차의 과제는 기본과 심화과 포함된 과제로, 성능 최적화를 진행하는 것이었습니다.## 과제 요구사항- 배포 후 ..

1. 최적화에 대하여"일단 돌아가게 만들고, 나중에 최적화하자"너무 익숙한 마인드인데 대부분의 개발자가 이렇게 진행하고 있지 않을까 싶다ㅎㅎ 약간의 변명을 하자면, 너무나 잦은 수정과 변경이 있지만 개발 일정은 조정되지 않아 돌아가게 만드는 게 최우선이 될 수밖에 없는 때가 많은 것 같다. 문제는 그 나중이 영영 오지 않는다! 그러므로 중요한 건 성능 최적화를 나중에 할 일이 아니라 개발 과정의 일부로 생각하는 것이다.물론 모든 걸 완벽하게 최적화할 순 없겠지만 이런 마인드 셋은 장기적으로 큰 차이를 만들어낸다. 단, premature optimization은 조심해야 한다.premature은 시기상조라는 뜻으로, 너무 성급한 최적화를 진행해 코드의 복잡도만 가중시키는 것을 의미한다. (1) 자기 점검-..