문제이런 코드가 있다.fun String.toSnakeCase(): String = replace(Regex("([a-z0-9])([A-Z])"), "$1_$2").lowercase()이 코드에는 문제점이 몇 가지 있는데, 무엇일까? 이 코드는 사실 내가 회사에서 작업한 코드 중 일부다.이렇게 문자열 확장 함수를 작성해서 PR을 올렸을 때, 한 동료가 이런 리뷰를 달아주었다."정규식 객체가 무겁다던데, 이 함수가 불릴 때마다 매번 새로 만들면 성능에 부담이 되지 않을까요?" 그제야 의문이 들기 시작했다.정규식이 매번 생성하기엔 무거운 객체였구나.그럼 어떻게 관리해야 할까?혹시 확장함수에서는 코틀린이 자동으로 캐싱해서 관리하고 있진 않을까?그렇지 않는다면, 매번 생성하지 않게 할 가장 좋은 방법은 뭘..
1. 문제이번에 기존 모듈에서 관리하던 enum을 별도의 공통 모듈로 분리하게 되었다. 원래는 해당 enum 클래스가 api의 request, response DTO에 들어가게 되는 경우를 고려해 enum이 UPPER_SNAKE_CASE가 아닌, 기존에 정해진 컨벤션대로 snake_case를 준수하게 하기 위해 @JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy::class)를 적용해 사용하고 있었다.@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy::class)enum class Status { ACTIVE, INACTIVE,} 하지만, 공통 모듈로 이 enum class를 이동하면서부터는 보편성을..
몇달 전 회사 팀에서 Spring MVC 대신 WebFlux 도입 검토를 했습니다.그땐 빠른 작업 속도로 정신이 없어서 WebFlux와 MVC가 뭐가 다른지 정확히 모르고 사용했었는데, 시간이 생긴 김에 알아보기로 했습니다.둘의 차이점을 위주로 설명하고, 거기서 더 나아가 mvc에서 webflux로 넘어와야 하는 이유, 그리고 넘어오면 좋은 프로젝트의 특징을 적어보겠습니다. MVC와 WebFlux의 차이점[MVC]Spring MVC는 전통적인 동기식 요청 처리 모델을 사용합니다.클라이언트의 요청이 들어오면 서버가 그 요청을 처리하고, 그 결과를 반환할 때까지 기다립니다.이 방식은 요청이 처리되는 동안 다른 요청은 대기해야 하기 때문에 동시 처리에 한계가 있을 수 있습니다.특히 사용자가 많아질수록 서버의 ..
스프링부트로 개발하다가, 빈을 분명히 등록했는데 실행만 시키면 빈을 찾을 수 없다는 에러가 떠서 한참을 고민하다 보니, 빈 등록 시점의 문제라는 걸 알게 되었습니다.빈을 순차적으로 등록하는 과정 중 아직 등록되기 전의 빈을 사용해야 하는 코드가 먼저 실행되었던 것입니다.빈의 로딩을 사용시점으로 미루는 @Lazy 어노테이션으로 해결했는데, 그래서 이번 글에서는 @Lazy에 대해 적어보았습니다. 일반적으로 Spring은 애플리케이션이 시작될 때 모든 빈을 생성하고 초기화합니다.이때 애플리케이션의 규모가 커지면 빈의 수가 많아지고, 초기화 시간이 길어져 앱의 시작 속도가 느려질 수 있습니다.이러한 문제를 해결하는 방법 중 하나가 바로 @Lazy 어노테이션을 활용하는 것입니다. @Lazy 어노테이션을 사용하면,..
DB Connection Pooling이란?스프링이 워낙 추상화가 잘 되어 있다 보니 스프링을 쓰는 사람들은 DB 그거 그냥 쿼리로 부르면 되는 거 아니야? 라고 생각하겠지만,아무것도 없는 node나 기타 환경에서 개발해본 사람들은 db connection 관련 설정을 한 번쯤은 해 보았을 것이다. 애플리케이션이 DB에 접근하기 위해서는 우선 DB와의 connection을 열고 (우선 가야할 길을 닦고) DB에 접근해야 한다. (건물에 들어가야 한다) 그런데, 이 길을 닦는 일이 꽤나 비싼 처리여서 (집에서 마트에 가려고 매번 새로 아스팔트를 깔아야 하는 기분이려나)DB에 접속할 때마다 커넥션을 맺어주는 건 부하가 크게 생길 수 있다. 그래서 connection pooling이라는 개념이 등장했는데,미..
저는 회사에서 백엔드 개발을 할 때 코틀린 스프링을 씁니다.자바를 썼던 기억은 학부 때 객체지향 수업을 들었을 때와 스프링에 입문하며 김영한 강사님의 스프링 강의를 들을 때뿐이었습니다. 그 이후엔 줄곧 코틀린을 써왔고, 주변 소위 '잘한다'는 한국의 백엔드 개발자들은 대부분 코틀린을 쓰고 있었습니다. 그래서 자바로 개발한다는 얘기를 들으면 저도 모르게 아직 그 팀의 기술스택이 충분히 힙하지 않구나 하고 넘겨 짚어버렸던 것 같습니다.자바 하면 왠지 모르게 이클립스 뷰가 떠오르고 굉장히 오래된 이미지가 연상되기도 했습니다. 그러다 문득 궁금해졌습니다.대체 무엇이 내 머릿속에 자바에 대한 이런 인식을 만들어냈을까.그리고 왜 사람들은 코틀린을 쓸까. 코틀린이 만들어진 이유에서부터 그 힌트를 찾을 수 있었습니다...
2024년을 마무리하며,최근 며칠 간 제 머릿속을 잠식했던 커리어에 대한 고민, 특히 다음 스텝에 대한 고민을 글로 정리해보려 합니다. 제 자신에게 가장 솔직할 수 있도록, 지금부터는 평어체로 적어 내려가겠습니다. - 정리하면 next step에 대한 고민은 크게 몇 가지의 굵직한 갈래들로 표현해 볼 수 있을 것 같다.1. 로봇을 진지하게 공부해보고 싶다.2. 글로벌 사업을 하고 싶다.3. 내가 정말 빅테크를 원하는가? 최근, 이 세 가지에 대한 생각이 갑자기 눈덩이 불어나듯이 커지면서 다른 일들에 집중하기 어려울 정도가 되었다는 것을 느끼고 있었다.그래서 생각 정리도 할 겸, 2024를 마무리하며 2025의 계획, 더 나아가 더 먼 미래의 그림도 그릴 겸, 지금의 내가 생각하는 제 next career..
nest.js 프레임워크에서 prisma라는 ORM을 쓰고 있다가 불편한 점을 하나 발견했습니다.바로 prisma를 다루는 모든 service layer 메서드들에서 각각 prisma exception을 try-catch 하고 있었다는 것입니다.이 과정이 번거롭고 복잡하니 예외처리를 하지 않아 500 에러를 내보내고 있는 케이스도 있을 수 있는 상황이었습니다. 이걸 어떻게 모든 곳에서 간단하게 예외 처리를 할 수 있을까 생각하다가 Nest.js에서 데코레이터도 강력하게 지원하고 있겠다, 데코레이터로 만들어볼까 하고 생각하게 되었습니다. 우선, prisma 문서에서 소개하고 있는 에러 핸들링 방법은 아래와 같습니다.위에서 이야기 한 대로 try-catch로 핸들링 하고 있습니다.import { Prisma..
