들어가며 회사 서비스 리뉴얼을 진행하면서 데이터베이스 변경 이력을 더 잘 관리할 필요가 생겼습니다. 스타트업에서는 요구사항이 자주 바뀝니다.저희 회사도 예외는 아니었습니다.기능이 바뀔 때마다 테이블과 컬럼도 계속 수정해야 했습니다. 처음에는 직접 SQL을 관리하며 대응했습니다.하지만 변경이 쌓일수록 한계가 분명해졌습니다.무엇을 언제 왜 바꿨는지 다시 찾는 일이 점점 어려워졌습니다. 그래서 데이터베이스 변경 이력을 더 체계적으로 관리하기 위해 Flyway를 도입하게 되었습니다.이 글에서는 데이터베이스 마이그레이션의 기본 개념과 Flyway를 선택한 이유, 그리고 우리 프로젝트에어떻게 적용하려고 했는지를 정리해보겠습니다. DB 마이그레이션이 필요한 이유 왜 DB 마이그레이션 관리가 필요했는가?처음에는 수..

이번 글에서는 이전에 노션 블로그에 작성했던 내용을 바탕으로, SDK Manager인 SDKMAN을 활용해 Java 버전을 관리하는 방법을 정리해보겠습니다. Installation - SDKMAN! the Software Development Kit Manager Installation | SDKMAN! the Software Development Kit ManagerInstalling SDKMAN! on UNIX is a breeze. It effortlessly sets up on macOS, Linuxsdkman.io LG유플러스 유레카 교육 과정에서 Java를 학습하던 중, 여러 Java 버전을 더 효율적으로관리할 수 있는 방법을 고민하게 되었습니다. 그 과정에서 알게 된 도구가 바로 SDKMAN..

스프링을 공부하다 보면 @Component, @Service, @Controller, @Repository를 자주 보게됩니다. 처음 보면 비슷합니다.모두 스프링이 관리하는 Bean으로 등록되기 때문입니다. 하지만 이들은 완전히 같은 의미가 아닙니다.공통점은 Bean 등록이고, 차이점은 역할과 사용 위치입니다. 이번 글에서는 네 어노테이션의 공통점과 차이점, 그리고 왜 구분해서 사용하는지를 간단하고 명확하게정리해보겠습니다.공통점@Component, @Service, @Controller, @Repository는 모두 스프링 빈으로 등록됩니다. 또한 @Service, @Controller, @Repository는 내부적으로 @Component를 기반으로 합니다.즉, 네 어노테이션의 공통점은 다음과 같습니다...

자바스크립트를 공부하며 가장 먼저 이해해야 하는 변수 선언 방식 자바스크립트를 처음 공부하다 보면 가장 먼저 마주치게 되는 것이 var, let, const입니다.문법 자체만 보면 셋 다 변수를 선언하는 키워드처럼 보이기 때문에, 처음에는 “어차피 변수 만드는 거아닌가?”라는 생각이 들기 쉽습니다. 저 역시 강의를 듣다가, 자바스크립트를 깊게 파고들 계획은 아니더라도 이런 가장 기본이 되는 차이는알고 넘어가야겠다고 느꼈습니다.특히 프런트엔드를 학습하거나, 기존 코드를 읽거나, 간단한 기능을 구현할 때도 var, let, const의 차이를 모르면 코드가 왜 그렇게 작성되어 있는지 이해하기 어려워질 수 있습니다. 그래서 이번 글에서는 자바스크립트에서 변수를 선언할 때 사용하는 var, let, const가..

https://codingtips.tistory.com/21 날짜, 시간, 시간대(Time Zone) 개념 정리개발에서 시간은 익숙한 값처럼 보이지만, 실제로 다뤄보면 생각보다 까다롭습니다.같은 `2026-03-18 18:00` 이더라도 어떤 시스템에서는 한국 시간일 수 있고, 어떤 시스템에서는 UTC일 수 있습니다.codingtips.tistory.com 이전 글에서는 날짜, 시간, 시간대(Time Zone)가 각각 무엇을 의미하는지,그리고 왜 같은 2026-03-18 18:00:00 같은 값이라도 해석 기준에 따라 전혀 다른 의미가 될 수 있는지를 정리했습니다. 특히 시간 데이터는 단순한 숫자나 문자열이아니라, 절대 시각인지, 지역 시각인지, 그리고 어떤 시간대 규칙 위에서해석되어야 하는지까지 함께 ..

최근 매일 아침 면접 질문을 보내주는 'meail-mail' 서비스를 통해 흥미로운 질문 하나를 받았습니다."Java에서 Record를 Dto로 사용하는 이유가 무엇인가?" 평소 프로젝트를 진행하면서 저는 Java Record를 DTO로 아주 자연스럽게 활용해 왔습니다.불변성을 바탕으로 데이터의 신뢰성을 높일 수 있었고, 값 기반 비교와 간결한 구조 역시 큰 장점이라고생각했습니다. 물론 모든 상황에서 Record를 고집한 것은 아닙니다.하지만 DTO처럼 데이터를 전달하는 객체를 설계할 때만큼은, Record가 꽤 좋은 선택지라고 느껴왔습니다. 그런데 이 질문을 마주한 순간, 익숙하게 사용해 왔던 선택을 다시 돌아보게 되었습니다. 나는 왜 Record를 DTO로 사용해 왔을까?그리고 그 이유를 단순한 취향..