전체 글

전체 글

    늦은 2024년 회고

    나의 20242024년을 되돌아보며 크게 3가지 주제로 정리할 수 있다취준신입 개발자현재취준2023년 프로그래머스 데브코스 4기 과정을 종료하고 2024년 1월까지는 이력서를 정리하고 자신을 돌아보는 시간을 가졌다.어떤 개발자가 되고 싶은지, 어떤 방향으로 성장해나가고 싶은지를 이전에 멘토님과의 식사자리에서 그 당시에는 장난스러운 밸런스게임이었지만(자바 7쓰는데 연봉 7000 vs 자바 17쓰는데 연봉 3000, 사수없이 vs 빡빡한 사수)지금 다시 생각해보면 그때 더 고민을 해보면 어땠을까라는 생각이다.모두가 똑같겠지만 나의 취준기간은 정말 나에게 있어 가장 힘든 시간이었다. 대학 수시면접, 수능, 자격증 등 각종 시험에서도 긴장없이 고민없이 잘 보고 나왔지만수 많은 서류탈락, 계속되는 최종에서의 탈락..

    NHN Cloud Hands on Lab 강의 수강 후기

    NHN Cloud Hands on Lab 강의 수강 후기

    NHN Clound Essentials 강의에 이어 실습 위주의 강의인 Hands on Lab까지 이어 수강을 하게 되었다이전에 들었던 강의가 이론위주의 수업이었다면 이 강의는 실습이 주인 강의이다여러 온라인 강의들도 들어봤지만 하나의 차이점은 먼저 최종 결과물을 알려주고 어떻게 만들어나갈지 어떤 서비스를 사용할지를 함께 고민하고 큰 그림을 그리는 고민을 할 수 있게 해줬다는 점이다 매번 VPC만들고 Subnet만들고 인스턴스 올려서 웹서버를 기계적으로 구축을 해왔었다면 이번 강의를 통해서 같은 과정이라도 고민을 해보고 어떻게 만들건지를 그리는 연습을 통해 좀 더 클라우드에 대해서 이해도가 올라온 것 같다NHN Cloud에서 올해에 자격증도 오픈한다고 하는데 이번에 강의내용 교제도 받았겠다 한번 도전해볼..

    NHN Cloud Essentials 교육 수강 후기

    NHN Cloud Essentials 교육 수강 후기

    사내에서 항상 사용해오던 AWS가 아닌 NHN Cloud를 사용하고 있었고 교육을 신청을 해줘서 교육을 듣고와서 후기를 남겨본다.클라우드에 대한 이론 수업으로 처음 듣는 사람도 충분히 쉽게 이해할 수 있도록 강사님이 잘가르쳐 주시고 가이드 따라서 하면 충분히 모두 따라할 수 있을 정도로 쉽게 작성되어있다. 이미 이전에도 AWS를 사용하면서 기본적인 지식들은 가지고 있었지만 한번 다시 정리한다는 생각으로 열심히 들었고 중간 중간 퀴즈도 내주시면서 강의자체를 재밌게 듣고 왔다 (물론 퀴즈는 1등을 하고 쿠키랑 펜도 받았다 ㅎㅎ) 프리티어를 사용하면서 크게 비용적인 측면을 생각하지 않고 사용해오던 나에게 강의 마지막에 요금 관련 내용이나 사설망 통신을 통해 비용 절감을 하는 방법들은 꽤나 재미있고 가장 흥미있..

    스프링 부트 한무 403 Error

    스프링 부트 한무 403 Error

    배경백엔드 프론트엔드 각자 열심히 개발을 진행하면서 드디어 프론트쪽 UI작업이 어느정도 끝나고 API 연동 시점에서 계속해서 403 에러가 터지기 시작했다.. 분명 로컬에서 잘 작동을 했고 이미 모든 권한에 관련된 것들은 처리를 해둔 상태인데 도데체 왜???문제에러가 발생한 이유는 되게 간단했다develop 환경에서 JPA.ddl-auto 설정 값을 none으로 설정을 해뒀더니 개발을 진행하면서 변경된 엔티티 반영이 되지 않아서 SQLSyntaxErrorException 이 발생하게 되었다그럼 여기서 이해가 되지 않는 점은 예외가 발생하면 아래와 같이 500에러가 터지기를 기대했는데 왠걸? 403????!?무한 403에러가 나는 것은 바로 시큐리티에서 찾을 수 있었다AuthorizationFilterSe..

    RequestBody Runtime시 동적 주입

    RequestBody Runtime시 동적 주입

    배경여러개로 나뉘어있던 이력서 내부 값들을 저장하는 테이블들을 하나로 합치면서 Service, Repository가 하나로 합쳐지게 되었다테이블 구조 변경 관련 이로인해 API들도 Request를 제외한 모든게 동일하게 되었다(기존에는 구조는 같았지만 접근해야 할 Service, Repository도 모두 달랐다)변경 후 Controller@PostMapping("/{resumeId}/activities")public IdResponse createActivity( @PathVariable Long resumeId, @RequestBody ActivityRequestDto request) { return new IdResponse(componentService.create..

    Controller에서 Security 정보 가져오기

    사용자가 크게 멘토와 멘티 두개의 역할 군으로 나뉘어져 있고 두 역할이 하나의 API Endpoint를 공유해서 사용을 하고 있고 하나의 값에 대해서 접근 권한이 다르기 때문에 분기 처리가 필요로 하고 사전에 filter에서 처리된 Role을 가져오고자 한다AnnotationRole을 가져오기 위해서는 SecurityContext에 접근을 해야 하는데 Security에서 제공하는 것으로는 @AuthenticationPrincipal, @CurrentSecurityContext가 있다@AuthenticationPrincipalSecurityContext에 담겨진 Authentication에서 getPrincipal()을 통해 principal 객체를 반환@CurrentSecurityContext추가로 Ex..

    ??? : 어딜 보시는 거죠 그건 제 잔상입니다만?!?

    ??? : 어딜 보시는 거죠 그건 제 잔상입니다만?!?

    배경진행 중인 프로젝트에서 API 문서화를 위해 Spring Rest Docs를 사용하고 있다API 문서를 만드는 과정에서 생긴 html 파일을 함께 서버에 배포를 해서 사용을 하고 있고 https://{백엔드 도메인 주소}/docs/index.html 로 접속을 하면 문서가 나오도록 설정을 해두었고 이를 위해 build.gradle에 copyDocument 라는 Task를 만들어 두었다tasks.register('copyDocument', Copy) { dependsOn asciidoctor doFirst { delete file('src/main/resources/static/docs') } from file("build/docs/asciidoc") into f..

    Redis 사용기

    Redis 사용기

    배경회원가입 시 카카오 인증만 진행하고 필수 정보를 작성하지 않은 사용자는 사용자가 맞을까?? 일단 내 기준에서는 아니다필수로 받아야 한다고 정책으로 정해진 것이고 해당 값들이 있어야 저장을 시켜준다라고 정해진 이상 해당 값들이 없다면 그건 사용자가 아닌 것이고 저장을 해주면 안된다 라는 정책과 그럼 카카오로 부터 받은 값들을 필수 값이 들어오기 전까지 어디에 안전히 가지고 있을 지 문제에서 시작되었다대안1. 서버 내부 메모리에 저장가장 간단한 방법이다 추가로 외부 리소스를 사용할 필요도 없고 내부에서 Map 형태로 우리가 만든 key 값, 사용자 정보 value로 저장을 한 후 해당 key 값을 제공하여 필수 정보 값과 같이 요청에 담아 보내도록 하면 된다하지만 단점으로는 서버가 증가한다면?!?!? (..

    이력서 저장 테이블 구조 재구성

    이력서 저장 테이블 구조 재구성

    배경일단 동작되게 만들어!!!이게 문제였는지 현재는 너무 화면에 치중된 ERD가 나오고 화면이 바뀌면 Controller, Service, Repository, 심지어 Database까지 모두 변경이 이루어지게 된다 (천지개벽!)또 화면에 ERD를 맞추다 보니 API를 찍어내는 것 이외의 작업이 없다 또한 추후 커스텀한 템플릿을 만들어 제공을 해주기 위한 Should 기능이 있는데 이러한 정적으로 구조화된 DB를 가지고서는 유연하게 많은 구조를 저장을 하기 불가능 하다고 생각이 되어 이를 하나의 테이블로 변경을 해보고자 한다현재 화면 상태 및 ERD 구상중인 새로운 Entity이를 해결할 방법으로는 다단계 Table!!하나가 여러개를 계속해서 증식할 수 있고 최고 등급 컬럼이 모든것을 먹을 수 있도록구상..

    Git Branch Linear

    Git Branch Linear

    Git Branch Linear배경기존에는 아무 생각 없이 Branch만들고 Merge를 진행하면서 Branch 관리에 대해서 별 다른 생각과 노력을 하지 않은 채로 개발을 진행해 왔지만 이번에는 Branch를 linear하게 관리를 하고자 한다 처음에는 그냥 rebase하고 squash하면 되는거 아니야? 가장 최신 시점에서만 merge하면 되겠네! 라고 생각을 했지만 시점을 잘못 파악해 몇 번의 문제점이 생기고 Linear하지 못하게 관리가 되게 되어 PR을 다시 올리고 Branch를 다시 만드는 과정을 몇번이나 진행하게 되었다 그리고 또 하나의 고민되었던 부분은 Github PR에서 Rebase And Merge, Squash And Merge 를 하게 되면 Fast Forward 와 같이 계속해서..