들어가며지난 글에서 선택 정렬을 정리했다. 선택 정렬은 "최솟값을 찾아서 앞으로 보내는" 방식이었고, 교환은 라운드당 한 번이었다.이번 버블 정렬은 정반대다. 옆에 있는 둘을 비교해서 순서가 틀렸으면 그 자리에서 바로 바꾼다.교환이 훨씬 자주 일어나는 대신, 이미 정렬된 입력이면 한 바퀴만 돌고 끝낼 수 있다.이름이 버블인 이유는 큰 값이 라운드마다 뒤로 밀려나는 모양이 거품이 수면으로 떠오르는 것 같아서다.Point : 버블 정렬은 "인접한 두 개 비교 → 틀렸으면 교환"을 반복해서 가장 큰 값을 맨 뒤로 보내는 것, 그게 전부다.1. 버블 정렬이란배열 앞에서부터 인접한 두 원소를 비교해서 앞이 더 크면 교환한다. 이걸 끝까지 한 번 훑으면 가장 큰 값이 맨 뒤에 가 있다. 그 다음 라운드는 마지막 하..

들어가며실무에서는 Arrays.sort()나 Collections.sort() 한 줄이면 끝나서 정렬 알고리즘을 직접 짤 일이 거의 없다.그러다 보니 "정렬이 내부에서 뭘 하는지"는 대충 알고 넘어간 채로 지냈다.정렬이 다른 알고리즘의 전처리로 깔리는 경우가 많아서, 동작 원리를 모르면 시간복잡도 계산부터 꼬인다는 걸 뒤늦게 느꼈다.그래서 복습도 할 겸 정렬을 직접 구현하면서 정리하기로 했다. 첫 번째는 가장 단순한 선택 정렬이다.Point : 선택 정렬은 "남은 것 중 제일 작은 걸 찾아서 앞에 갖다 놓는다"를 반복하는 것, 그게 전부다.1. 선택 정렬이란배열을 정렬된 부분과 아직 안 된 부분으로 나누고, 안 된 부분에서 최솟값을 골라(select) 정렬된 부분 바로 뒤에 붙이는 방식이다. 처음에는 정..

릴리스 PR을 올렸습니다. 리뷰 승인 3개, CI 체크도 전부 통과. 이제 버튼만 누르면 되는데 GitHub가 이렇게 말합니다.This branch cannot be rebased due to conflicts코드끼리 부딪힌 곳은 없었습니다. 로컬에서 같은 rebase를 돌려 보니 충돌 없이 끝났고, 결과물도 원래 브랜치와 똑같았습니다. 그런데도 GitHub는 버튼을 막았습니다.원인을 따라가 보니 머지 방식을 섞어 쓴 것이 문제였습니다. 이 글에서는 GitHub의 머지 방식 세 가지가 어떻게 다른지, 충돌은 왜 생기는지, 그리고 어떤 상황에 어떤 방식을 써야 하는지 정리합니다.먼저: 커밋은 "변경 내용"이다git의 커밋은 파일 전체를 찍은 사진이라기보다 "이 줄을 이렇게 바꿔라"라는 변경 내용에 가깝습니..

코딩테스트에서 문자열 문제는 거의 매번 나온다. 자주 쓰는 String 메서드를 기능별로 정리한다.String은 불변(immutable)이다. replace, toUpperCase 같은 메서드는 원본을 바꾸지 않고 새 문자열을 반환한다. 그래서 반드시 반환값을 받아서 써야 한다.String s = "hello";s.toUpperCase(); // 결과 버려짐 — 원본 그대로s = s.toUpperCase(); // 이렇게 받아야 반영됨1. 길이 / 문자 접근 — length(), charAt()String s = "algorithm";System.out.println(s.length()); // 9System.out.println(s.charAt(0)); // 'a'length..

문자열을 반복해서 이어 붙일 때 String + String을 쓰면 매번 새로운 객체가 만들어져 비효율적이다. 이럴 때 사용하는 것이 StringBuilder다. 내부적으로 하나의 버퍼를 재사용하기 때문에 반복문 안에서 문자열을 조립할 때 특히 유용하다.String은 불변(immutable), StringBuilder는 가변(mutable). 이 차이가 성능 차이의 핵심이다.1. 생성StringBuilder sb1 = new StringBuilder(); // 빈 문자열 (기본 용량 16)StringBuilder sb2 = new StringBuilder("coding"); // 초기 문자열 지정StringBuilder sb3 = new StringBuilder(32); // 초기..

들어가며최근 회사에서 Express로 되어 있던 백오피스 기능 하나를 Spring 배치 프로그램으로 옮기는 작업을 하고 있다. 그 과정에서 ServerEnvContext라는 클래스를 만나게 됐는데, 처음 봤을 때는 "이게 뭐지? 왜 static 메서드에 람다를 넘기지?" 싶었다. 뜯어보니 ThreadLocal 기반 동적 DataSource 라우팅이라는, 알고 나면 꽤 우아한 패턴이었다.배치 특성상 하나의 프로그램이 PROD와 TEST 두 DB를 번갈아 다뤄야 하는 상황이었고, 이 요구사항이 바로 이 패턴이 필요해진 배경이다.이 글에서는 그 코드를 일반화한 예제로, 다음 흐름을 따라가 본다.왜 이런 장치가 필요한가 (문제 상황)ThreadLocal이 뭔가핵심 메서드 call() 뜯어보기RoutingData..

들어가며로컬에서 NestJS 프로젝트를 개발하다 보면 앱 하나만 띄워서 되는 경우가 거의 없습니다. DB도 필요하고, 캐시용 Redis가 붙기도 하고, 경우에 따라 메시지 큐까지 필요할 때도 있습니다.처음에는 저도 docker run으로 하나씩 띄웠습니다.docker run -d --name my-db \ -e SA_PASSWORD=MyP@ssw0rd! \ -e ACCEPT_EULA=Y \ -p 1433:1433 \ -v sqldata:/var/opt/mssql \ mcr.microsoft.com/mssql/server:2022-latest이걸 컨테이너 개수만큼 반복하고, 옵션 하나 틀리면 지우고 다시 띄우고... 게다가 이 긴 명령어는 제 머릿속과 셸 히스토리에만 존재해서, 팀원에게 환경을 공..

들어가며회사에서 NestJS 프로젝트를 하다 보면 npm install은 거의 숨 쉬듯이 치게 됩니다. 저도 1년 넘게 npm만 썼고, 솔직히 패키지 매니저에 대해 깊게 생각해본 적이 없었습니다. "설치되면 그만 아닌가?" 싶었거든요.그런데 사이드 프로젝트를 여러 개 만들다 보니 디스크 용량이 이상하게 빨리 차고, node_modules 폴더 하나가 수백 MB씩 되는 걸 보면서 의문이 생겼습니다. 그러다 pnpm을 알게 됐고, 동작 원리를 파보니 단순히 "빠른 npm"이 아니라 설계 철학 자체가 다른 도구라는 걸 알게 됐습니다.이번 글에서는 npm과 pnpm이 구조적으로 어떻게 다른지, 그리고 실제로 갈아탈 때 뭘 조심해야 하는지 정리해보겠습니다.1. npm의 node_modules는 왜 그렇게 무거울까..