본문 바로가기

개발 일기장106

20240820 TIL: github workflow 최신 배포 반영 안되는 문제 임시로 해결 & 발표 준비 ✅ 오늘의 시간표시간카테고리할 일 상세14:00-16:30SOMA발표 대본 작성16:30-18:00SOMA예상 질문 보완18:30-19:30SOMA발표 피드백 멘토링20:00-21:00SOMA피드백 반영하여 발표 내용 수정 ✅ 오늘 배운 것오늘은 대부분 발표 준비를 하면서 시간을 쓸 예정이다. 개발과 발표 준비는 엄연히 다른 업무라 개발만 하다가 갑자기 또 발표를 위한 준비 모드로 전환하는 것은 개발자 입장에서 엄청 하고 싶은 업무도 아닐뿐더러, context switching 비용도 꽤 드는 것 같다. 다행히 발표가 가장 빠른 목요일(심지어 오전)이니, 조금만 더 발표 준비에 집중해 보자.  원래는 모든 시간을 그렇게 쓰려고 했었는데, 어제 문제였던 이슈를 처리하고 반영하던 과정에서 또 다른 문제가 생.. 2024. 8. 20.
20240819 TIL: 프론트 Api 클래스로 바꿨는데도 발생하는 401 AxiosError 수정 [진행중] ✅ 오늘의 시간표시간카테고리할 일 상세15:00-22:00OneStepSZ-215: 프론트 자잘한 듯 자잘하지 않은 버그 이슈23:00-00:00SOMA발표 대본 작성 ✅ 오늘 배운 것axios 인스턴스에 대해서는 어제 axios interceptor를 사용해서 401 AxiosError가 발생했을 경우 액세스토큰 갱신 API를 호출하고, 해당 리프레시 토큰으로 액세스토큰을 갱신시키는 로직을 추가해 두었었다.  그런데 오늘 다시 로그를 보니 여전히 401 에러(어제는 400 에러도 중간에 섞여 있었는데 오늘은 401 에러만 나온다)가 나왔다. 알고보니 리프레시 토큰이 만료된 경우는 액세스 토큰을 갱신하려고 해도 갱신할 수 없었다. 혹시나 해서 API 서버의 리프레시 토큰의 만료일자를 찾아보니 1일로 되어.. 2024. 8. 19.
20240818 TIL: 프론트 Api 클래스로 바꿨는데도 발생하는 401 AxiosError 수정 [진행중] ✅ 오늘 배운 것저번에 멘토님께 피드백을 받은 대로 Context API에 액세스토큰 값을 넣어두는 대신 Api 클래스를 싱글톤 패턴으로 만들고, 해당 클래스의 메소드를 사용하도록 컴포넌트 내부의 코드들도 수정해주었다. 그런데도 여전히 401 AxiosError가 발생하고 있었다.  해당 에러를 수정해야 무사히 PR을 하고 잘 동작하는 앱 화면을 볼 수 있기에, 여기에 달려있는 dependency가 많다고 느껴져서 이 일을 급하다고 판단했다.  현재 Api 클래스의 일부 코드는 다음과 같다. 여기서 핵심은 request 메소드에서 this.accessToken으로 Api 싱글톤 클래스가 갖고 있는 토큰값을 넣어주고, 에러가 날 경우 Sentry에 로그를 남긴 뒤 해당 에러가 액세스토큰이 만료되어 발생하는.. 2024. 8. 18.
20240817 TIL: 개발 대신 발표 준비 ✅ 오늘의 할 일 계획시간카테고리할 일 상세13:00-15:30SOMA멘토링16:00-19:00SOMA발표 대본 작성22:00-23:00취업이력서 작성하기 계속 할 일이 많으니 심적 여유나 심리적 안전감이 떨어지는 느낌이다. 일을 안 하면 당연히 회복은 될 텐데 그런 방법은 일이 많을 때는 쓸 수가 없다. 이럴 때는 어떻게 해야 할까? 현재 생각나는 방법으로는 취미 활동을 중간에 30분씩이라도 끼워 넣으면서 중간중간 회복을 해 주는 방법인데, 다른 방법이 또 있을지도 찾아봐야겠다.  ✅ 오늘 배운 것오늘은 개발적으로는 이슈 처리를 하지는 않았다. 왜냐하면 발표 대본을 써야 하고, 그 발표 대본이 있어야 다른 팀원이 PPT를 만들 수 있는 모종의 dependency가 걸려있는 상황이었기 때문이다. 오늘까지.. 2024. 8. 17.
20240816 TIL: uvicorn+gunicorn으로 서버 성능 향상시키기 & 액세스토큰 갱신시키는 Api 클래스 싱글톤 패턴으로 만들기 [진행중] ✅ 오늘의 할 일오늘 할 일이 뭔가 매우 많은데 정리되어 있지는 않아서 얼레벌레 그냥 했다가는 일정이 지연될 것 같았다. 그래서 시간별로 할 일을 정리해보았다. 각 일정은 1시간 동안 처리하고, 쉬거나 조금 오버되거나 하는 식으로 시간을 더 쓸 수도 있을 것 같아서 각 일정 사이에는 30분의 쉬는 시간을 두었다. 시간카테고리할 일 상세14:00-15:00BE SZ-243uvicorn, gunicorn으로 서버 성능 향상, mysql 커넥션풀링 후 locust로 테스트하기15:30-16:30FE SZ-215기존 액세스토큰 재발급 로직 Api 클래스로 바꾸기17:00-18:00SOMA중간발표 보고서작성19:00-20:00SOMA중간발표 대본작성20:30-21:30취업이력서 피드백 주신대로 바꾸기23:00-2.. 2024. 8. 16.
20240815 TIL: uvicorn+gunicorn으로 서버 성능 향상시키기 [진행중] ✅ 오늘 배운 것오늘은 멘토님과의 멘토링에서 어제 Locust로 API 서버 부하테스트를 했다는 부분을 말씀드리면서 피드백을 받았다. 당시 RPS(request per second)가 30-40 정도 나오고 있어서 괜찮은지 여쭤봤더니 멘토님께서는 1000 이상은 나오는 것이 안정적이라고 피드백을 주셨다! 그래서 왜 이렇게 RPS가 낮은지를 생각하고 있었는데, 지금 서버는 단일 서버로 돌아가고 있기 때문이었다. 따라서 uvicorn을 사용해서 서버를 여러 대 띄워야 RPS를 늘리고 서버의 부하를 줄일 수 있다고 하셨다.  그래서 장고에서 uvicorn을 사용하는 공식문서를 찾아보았다. uvicorn은 pip로 쉽게 설치할 수 있는 라이브러리였다. uvicorn을 사용하려면 gunicorn도 같이 필요하다고.. 2024. 8. 15.

티스토리툴바