복's

펫과 함께하는 나만의 To-Do 리스트 프로젝트 Do-With 이 드디어 끝을 맺었다.짧은 시간 개발했지만 시간에 비해서는 결과물이 어느정도 나온 것 같다.[ 📌 주제에 대해서 ]우리팀은 5명중에서 3명이 To-Do를 사용하지 않는데도 불구하고 To-Do 앱을 만들게 되었다.주제에 대해서는 아쉬운 부분이 많았고, 차라리 반려된 프로젝트를 끌고 가는게 어떨까 싶은 생각도 프로젝트 중간 중간에 이따금씩 들곤 했다. 특히나 To-Do 리스트 작성은 개발자들이 처음 공부를 시작하면서 가볍게 다루는 CRUD밖에 없었고, 그 안에서 기술적인 와우함을 찾을 수 있을까 하는 걱정이 제일 많이 들었다. 어찌 되었든 주제가 정해지고 나서는 왈가왈부 하지 않고 목표를 위해서 앞만 보고 뛰어가기로 생각했고, 나름 잘 달렸다..

데이터를 조회할 때 많은 데이터를 한 번에 많이 가져오면서 혹은 정적 리소스도 같이 받아 오면서 화면을 렌더링 하는데 시간이 오래 걸리는 상황이 발생했고, 제일 먼저 생각난 방법은 페이징 처리를 하는 것이였다. 과거에도 몇 번 페이징 처리를 해본 경험은 있었지만 Nest JS는 한 번도 다뤄본적 없기 때문에 어떻게 처리할지에 대한 고민을 했었다. 밑에서 하는 페이징 처리는 내가 임의로 한 페이징 처리이기 때문에 다른 사람이 어떻게 하는지는 모르겠다. 다만 스프링에서 myBatis를 사용해서 페이징 하던 기억을 더듬어서 만들었기 때문에 페이징 처리에 대한 정석은 아니고 그저 주니어 개발자의 기록일 뿐이다. [ 📌 PagingOption.ts ] 먼저 여러 조회 API에서 공통적으로 사용할 수 있는 페이징 ..

[ 📌 수료식을 앞두고... ]크래프톤 본사에서 마지막 발표까지 끝났다.아직도 얼떨떨하지만 끝이 아니라 새로운 시작이라는 사실에 다시금 놀라게 된다.당연한 이야기지만 정글 과정은 개발자로서 마침표가 아니라 이정표의 시작이라는 사실을 새삼 느끼게 된다.길다면 길고, 짧다면 짧은 기간 동안의 배움이 단 두 글자 '시작'을 위해서 였다. 이제 이력서와 자기소개서를 작성하고 취업을 위해서 면접을 위한 cs지식과 코딩 테스트를 위한 문제를 풀면서 다시 준비해야 하는 시간이 다가왔다. 다만 이번 주말은 펜은 손에 잡히지 않고, 노트북을 열어 공부에 집중하기에는 힘든 주가 될 것 같아서 일지부터 작성하게 되었다.[ 📌 마지막 발표... ]다른팀들과 마찬가지로 우리 팀도 발표를 위해서 시연 연습을 정말 많이 했다...

[ 📌 한 주를 마무리 하면서... ]사실상 마지막 주 라고 생각하면 될 것 같다.수료식과 별개로 마지막 발표가 이번 주 토요일 이니까...멘토링과 리허설이 있었지만 다른 주와는 다르게 개발만 진행하지는 않았다.포스터도 만들고 발표 자료, 동영상 그리고 시연 준비까지 개발 이외에도 바쁜 주였다. [ 📌 멘토링... ]멘토님도 계속해서 도와주고 계시는데, 나름 디테일하게 봐주셔서 많은 도움을 받고 있다.리허설 발표하기 전 까지도 발표랑 자료에 대한 피드백을 주셨다. 사실 이번 멘토링이 처음이자 마지막으로 우리가 만든 프로덕트를 보여드린 멘토링이 아닌가 싶다.지금까지 보여드린게 없었고, 멘토님도 이제와서 솔직히 말씀해주신게 지금까지 제대로 본게 없어서 이 팀 열심히 해야겠다 싶었다고 하실 정도였으니 저번..

DB를 공부하다가 보면은 한 번은 마주하는 단어 Deadlock... 하지만 일 & 공부 하면서 한 번도 마주한적 없어서 적잖게 당황했다. 사실 Deadlock 자체의 문제라기 보다는 저번 주에 포스팅했던 메모리 누수로부터 파생된 오류였다. [ 📌 Deadlock Error Tracing ] 먼저 Get 방식으로 요청이 들어왔고 실행된 DML은 select 문이였다. 첫 번째 의문은 왜 select 에서 데드락이 발생되었는가 였다. 나는 Dirty Read가 허용된 상황에서만 작업을 해와서 당연하게도 항상 허용되는줄 알았다. 두 번째 의문은 어디서 트랜잭션상에 해당 테이블을 올리고 커밋하거나 롤백하지 않는가였다. (나중에서 알았지만 DB에서 실행중인 세션 및 쿼리 확인하는 테이블이 있어서 확인할 수 있었..

어느 시점 이 후 계속해서 서버가 터지는 현상이 일어났다...정확히는 서버거 죽는게 아니라 Request만 받고 Response를 뱉지 않는 상황이 생겼다. 그럴 때 마다 서버를 재 부팅 했는데 너무 잦아서 문제를 식별하기 위해서 로그를 뒤져봤다.Http Method 종류 상관 없이 혹은 파라미터, agent도 변경해서 보내봤지만 특정한 에러가 발생하는게 아니라서 문제를 몰랐다.정상적인 플로우대로 흘렀다면 핸들러를 통해서 DB Access까지 이루어져 작성 해두었던 DML 실행 후 결과를 요청한 클라이언트에 반환 해줘야 하는데 Request에서 서버가 응답을 하지 않았다.도대체 문제가 무얼까 생각 하다가... 정확히 어디까지 도달하는지 확인 해보았지만 DB Access할 시점부터 코드가 아래처럼 멈춰버렸..

[ 📌 한 주를 마무리 하면서... ]마무리 발표, 멘토링 그리고 최종 발표를 위한 준비...개발과 서버오류... [ 📌 마무리 발표... ]마무리 발표가 지나갔다.우리조는 진짜 피드백 내내 깨졌다. 준비 안되면 발표 안시킨다는 말까지 들었으니 아마도 들을 수 있는 평중에서 가장 낮은 평이 아닐까 싶다.안좋은 피드백에 팀원 몇명은 시무룩해진거 같아서 안타까웠지만, 내 생각에는 적절한 시기에 정확한 피드백을 하신거 같아서 오히려 다행이라고 생각이 들었고, 더 다행인점은 피드백이 수용가능하며 충분히 커버 범위 내에 있다고 생각이 들었기 때문이다. 먼저 완성도가 너무 낮았다.진짜 만들다 말았다는 말 그대로였고, 역시나 피드백 하시는 분들이 경험이 많으니 바로 캐치 하시는거 같다.실제로 개발 속도 자체도 매..

DB 데이터 조작(DML)시 유효하지 않은 ID를 가지고 하게 되면 HTTP Status code로 200 OK를 받게 되었다.근데 우리는 이게 DB에 대한 조작이 없으니 에러를 발생 시키고, 사용자에게 혹은 우리가 알 수 있도록 제어할 수 있어야 한다고 생각 했다. 그래서 조작이 없을 경우 Wrapping해서 예외 처리 하도록 했다.[ 📌 목표 ]Inteceptor를 만들어서 Response되기 전에 조작할 수 있도록 세팅DB조작이 없는 경우 HTTP Method에 따라서 다르게 동작 하도록 세팅[ 📌 Interceptor 세팅하기 ]Docs & GPT (GPT의 도움이 컸지만..)의 힘으로 세팅했다.근데 사실 세팅 자체는 Docs만 봐도 할 수 있을 정도로 어렵지 않다. 1) NestInterce..

[ 📌 한 주를 마무리 하면서... ]중간 발표가 지나갔다.아니 사실은 많은 일들이 지나갔다.중간 발표와 지금까지 여러 협력 회사의 설명회들이 지나갔고, 사실상 이 글을 작성하는 지금 기준으로 최종 발표까지 3주 남았다 ㅎ....지금까지는 나쁘지 않게 진행되고 있다고 생각하면서 앞으로 나아가고 있다.팀원들이 협력하고 의견을 포용하는 능력이 상당해서 지금까지 순항하고 있는 것 같다. [ 📌 중간 발표... ]중간 발표에서 나름의 좋은 평가를 받았다고 생각한다. 발표 준비는 엉망이었다.발표 준비 거의 하지 못했고, 발표 1시간 전까지도 코드와 ppt 수정 하느라 준비는 거의 못했다.자랑은 아니지만 흠을 안잡을 수 없는 발표라고 평가 받았다.프로젝트 방향성은 On Track!초안 발표대로(사실 초안 발표 ..

이미지 파일들을 서버로 업로드할 일이 생겼다.당장은 큰 용량의 이미지들이 올라가지 않기 때문에 S3 같은 스토리지 사용 대신에 서버 폴더에 업로드 하기로 했다.[ 📌 목표 ]이미지 업로드를 한 곳에서만 하지 않기 때문에 공통적으로 사용할 수 있도록 모듈화 하기이미지 압축하기이미지 관련한 예외 케이스 처리하기파일 사이즈 제한하기[ 📌 파일 업로드 하기 & 모듈화 ]다행히도 좋은 자료가 많았지만 맨 처음으로 접한건 역시 Docs다.기본적인 예시는 제공되기 때문에 먼저 파일을 전송 했을 때 파일이 받아지는지 확인 해본다.$ npm i -D @types/multerMulter를 사용하기 때문에 라이브러리 다운로드를 받고 시작한다. @UseInterceptors(FileInterceptor('file')) ..