JUPETER의 Notebook

Git & GitHub

jupeternotebook — Sun, 17 May 2026 03:43:27 +0900

1. Git과 GitHub의 차이

Git

컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템

GitHub

Git 저장소 호스팅을 지원하는 가장 인기 있는 오픈 소스 웹 서비스

한 줄로 정리하면, Git은 도구이고 GitHub는 그 도구를 활용한 웹 플랫폼입니다.

2. 왜 중요한가?

Git 리포지토리

Git의 역할

코드의 버전 관리를 용이하게 함
여러 사람이 동시에 하나의 프로젝트를 협업할 수 있도록 도움

Git이 필요한 이유

이전 작업 기록 확인 가능
특정 시점으로 되돌아가기 가능
협업 시 코드 충돌 관리 가능

GitHub의 역할

코드 호스팅, 버전 관리 및 협업을 위한 통합 플랫폼 제공

GitHub가 필요한 이유

전 세계 어디서나 프로젝트 공유 가능
여러 개발자가 함께 협업 가능
오픈소스 프로젝트 참여 가능

3. 기존 물리적인 백업 및 공유 방식

Git이 등장하기 전에는 다음과 같은 방식으로 코드를 백업하고 공유했습니다.

기존 방식

컴퓨터에서 직접 파일 이동
USB, 외장하드 사용
메일 및 클라우드 사용

장점

코드 손실 시 복구 가능성이 있음

단점

코드가 변경될 때마다 저장해야 해서 관리가 어려움
컴퓨터가 고장나거나 외장하드를 분실하면 백업 파일이 모두 사라질 수 있음

4. 버전 관리 시스템 (VCS)

어떤 프로그램이 몇 번 수정되어 있는지를 관리하는 프로그램

버전 관리 시스템은 크게 두 가지 방식으로 나뉩니다.

중앙 집중식 버전 관리 시스템 (CVCS)
분산 버전 관리 시스템 (DVCS)

5. 중앙 집중식 버전 관리 시스템 (CVCS)

서버에서만 프로그램의 버전과 변경사항을 관리하는 방식

예시

구글 슬라이드

특징

언제 어떤 사람이 문서를 변경했는지 확인 가능

장점

다른 사람들과 동시에 자료 보기 가능
로컬 컴퓨터 저장공간 절약 가능
작업 순서를 알 수 있음 → 이전 기록으로 돌아가기 쉬움
파일 유실이 덜 생김

단점

인터넷 연결이 안 되면 작업 불가능
서버가 날아가면 복구 어려움
동시에 같은 내용 작업하기 어려움

6. 분산 버전 관리 시스템 (DVCS)

프로젝트의 전체 히스토리와 버전 관리 정보를 각 사용자의 로컬 시스템에 복제하여, 네트워크에 의존하지 않고도 버전 관리를 수행할 수 있도록 하는 시스템

Git이 바로 이 방식에 해당합니다.

장점

작업 순서를 알 수 있음 → 이전 기록으로 돌아가기 쉬움
인터넷 연결이 잠시 안 되어도 작업 가능
서버가 날아가도 복구 가능성 높음
동시에 같은 내용 작업 가능

단점

관리가 어려움

7. Git 동작 방식

Git의 작업 흐름은 크게 6단계로 나뉩니다.

1단계 : Git 저장소 생성

git init

기존 디렉토리를 Git 저장소로 초기화
Working Directory(.git 폴더) 생성

2단계 : 파일 스테이징

git add a.txt

흐름 : Untracked Files → Stage

3단계 : 파일 수정

파일 수정 시 Stage 상태에서 Working Directory 내부의 Tracked Files 중 Unstaged Files 상태로 이동

4단계 : 다시 스테이징

git add

흐름 : Unstaged Files → Stage

5단계 : 커밋

git commit

흐름 : Stage → History

6단계 : 서버 업로드

변경사항을 원격 서버에 업로드 (git push)

전체 흐름을 한눈에 정리하면 다음과 같습니다.

Working Directory → Stage → History → Remote Repository
        (add)         (commit)        (push)

8. 자주 사용하는 Git 명령어

명령어 역할

git init	Working Directory 생성 (저장소 초기화)
git remote add origin "저장소 주소"	로컬 저장소에 원격 저장소 연결
git status	현재 작업 중인 저장소 상태 확인
git add 파일명	파일을 Stage 상태로 변경
git commit -m "메모"	파일의 변경 내용 확정
git push <원격저장소명> <브랜치명>	로컬 저장소 변경 내용을 원격 저장소에 업로드
git clone "원격 저장소 주소"	원격 저장소 레포지토리 복제
git pull	원격 저장소 최신 내용을 로컬 저장소로 가져옴

각 명령어의 상세한 사용 예시도 정리해두면 다음과 같습니다.

저장소 생성

git init

원격 저장소 연결

git remote add origin "저장소 주소"

상태 확인

git status

스테이징

git add 파일명

커밋

git commit -m "메모"

원격 저장소 업로드

git push <원격저장소명> <브랜치명>

저장소 복제

git clone "원격 저장소 주소"

최신 내용 가져오기

git pull

마치며

Git과 GitHub는 협업 개발의 필수 도구입니다. 자주 쓰는 명령어는 다음 5~6개 입니다.

git init → 저장소 초기화
git add → 스테이징
git commit → 변경 확정
git push → 원격 업로드
git pull → 원격 최신 내용 가져오기
git clone → 원격 저장소 복제

참고자료 및 이미지 출처

Java의 메모리 관리

jupeternotebook — Sun, 17 May 2026 02:02:21 +0900

1. 메모리 관리란?

프로그램에 필요한 저장 공간을 할당하고 해제하는 것

목적

프로그램 실행에 필요한 데이터를 저장하기 위해 사용
효율적인 메모리 사용과 안정성 확보

2. C언어 메모리 관리

특징

개발자가 메모리를 직접 다룰 수 있음

대표 함수

malloc() : 메모리 할당
free() : 할당된 메모리 해제

장점

중간 과정 없이 직접 다루므로 속도가 빠름
메모리 사용 효율이 좋음

단점

사람이 직접 관리하므로 실수 발생 가능

대표적인 문제

메모리 누수(Memory Leak) : 사용이 끝난 메모리를 반납하지 않는 문제
해제된 메모리 접근 : 이미 free() 한 메모리를 다시 접근하는 문제

3. Java 메모리 관리

특징

JVM 실행 시 운영체제로부터 메모리를 할당받음
JVM이 메모리를 관리함

즉, Java에서는 개발자가 직접 메모리를 할당하거나 해제할 필요가 없습니다.

대신 JVM은 메모리를 크게 Stack과 Heap 두 영역으로 나누어 관리합니다.

4. 스택(Stack)

실행 흐름을 담는 메모리 공간

비유

개인 작업대

특징

지역변수(Local Variable) 저장
메서드 호출 정보 저장
메서드 실행 종료 시 자동 반납
메모리 관리가 비교적 쉬움

5. 힙(Heap)

공용으로 사용하는 메모리 공간

비유

공유 주방

특징

객체(Object)와 인스턴스 데이터를 저장
메서드 종료 후에도 객체가 바로 사라지지 않음
여러 곳에서 함께 참조 가능

왜 스택과 힙을 나누는가?

메모리 관리 효율성과 실행 성능 향상을 위해

Stack의 특성

빠른 생성 및 제거 가능
실행 흐름 관리에 적합

Heap의 특성

크기가 큰 데이터 및 객체 저장에 적합
여러 객체가 공유 가능

핵심 정리

Stack은 메서드 실행 중심, Heap은 객체 저장 중심

6. GC(Garbage Collector)

힙 메모리 영역에서 더 이상 사용되지 않는 객체를 제거하는 기능

역할

참조되지 않는 객체 제거
사용 가능한 메모리 확보
메모리 누수 방지 도움

동작 기준

객체가 제거되는 경우는 다음과 같습니다.

GC Root를 기준으로 참조 관계를 탐색했을 때
더 이상 참조되지 않는 객체인 경우 제거

GC Root 예시

스택의 지역 변수
static 변수
JNI 참조 등

동작 과정

GC Root를 기준으로 참조 관계 탐색
사용 중인 객체와 사용되지 않는 객체 구분
참조되지 않는 힙 메모리 제거
메모리 정리 수행

Stop-The-World

GC 과정에서 일부 Stop-The-World가 발생할 수 있음
이 과정에서 프로그램 실행이 잠시 멈춤

최신 JVM GC인 G1 GC, ZGC, Shenandoah 등의 저지연 GC는 이 정지 시간을 줄이기 위해 지속적으로 개선되고 있습니다.

메모리 압축(Compaction)

GC는 메모리 압축을 수행하기도 함
흩어진 메모리를 정리하여 메모리 단편화(Fragmentation)를 줄임

7. 전체 흐름 요약

Stack

메서드 실행을 관리하는 공간
지역 변수 저장
자동 생성 및 자동 제거

Heap

객체를 저장하는 공간
여러 곳에서 참조 가능
GC가 관리

마치며

자바의 메모리 관리는 결국 "개발자 대신 JVM이 알아서 해준다"는 한 문장으로 요약할 수 있습니다.

하지만 그 내부에는 다음과 같은 구조가 숨어 있습니다.

Stack : 빠르게 생성되고 제거되는 실행 흐름 공간
Heap : 객체가 살아가는 공유 공간
GC : Heap을 청소하는 자동 관리자

컴퓨터 언어 정리

jupeternotebook — Sun, 17 May 2026 01:55:15 +0900

1. 컴퓨터 언어란?

이진법을 이용하여 논리 연산, 저장을 수행하는 전자 기계와 소통하기 위한 수단

컴퓨터와 사람이 의사소통하기 위한 방법
명령을 전달하고 결과를 받기 위해 사용됨

쉽게 말해, 사람의 말과 컴퓨터의 말이 다르기 때문에 그 둘을 이어주는 번역 도구가 필요하고, 그 역할을 하는 것이 바로 컴퓨터 언어입니다.

2. 이진법 (Binary)

0과 1이라는 두 개의 숫자를 사용해 수를 나타내는 진법

사용하는 이유

컴퓨터는 전기적인 신호를 기반으로 동작함
전기의 상태를 단순하게 두 가지로 구분 가능
- 열림 → 1
- 닫힘 → 0

장점

전자 회로 설계가 단순해짐
신호 처리 속도가 빨라짐
안정성이 높음

단점

사람이 읽고 이해하기 어려움
유지보수가 힘듦

3. 기계어 (Machine Language)

특징

컴퓨터가 직접 이해하는 언어
이진수(0과 1)로 이루어짐

사용하는 이유

CPU가 바로 해석하여 실행 가능하기 때문

한계점

가독성이 매우 낮음
코드 작성이 어려움
수정 및 유지보수가 힘듦

4. 고급 언어 (High-Level Language)

기계어의 불편한 점들을 해결하기 위해 읽고 쓰기 쉬운 고급 언어가 등장했습니다.

특징

사람이 이해하기 쉬움
생산성이 높음
유지보수가 편리함

대표적인 종류

C
C++
Python
Java
JavaScript
Swift
Kotlin
Ruby
R

5. 한 줄 정리

구분 특징

이진법	0과 1로 데이터를 표현
기계어	컴퓨터가 직접 이해하는 언어
고급 언어	사람이 읽기 쉽도록 만든 언어
목적	사람과 컴퓨터의 원활한 의사소통

마치며

결국 우리가 사용하는 Java, Python, C++ 같은 고급 언어는 모두 컴퓨터가 직접 이해할 수 있는 기계어(이진수) 로 번역되어 실행됩니다.

이진법은 컴퓨터가 신호를 표현하는 방식
기계어는 컴퓨터가 직접 이해하는 언어
고급 언어는 사람이 이해하기 쉽게 만든 언어

Java 기초 정리

jupeternotebook — Sun, 17 May 2026 01:33:34 +0900

자바(Java) : 다양한 플랫폼에서 실행될 수 있도록 설계된, 메모리 관리와 강력한 라이브러리 생태계를 갖춘 객체지향 프로그래밍 언어이다.

1. 자바의 탄생 배경

당시 상황

1980년대에는 주로 C와 C++ 을 사용함
특히 C언어는 운영체제 및 시스템 개발의 표준처럼 사용됨

문제점

가전제품과 임베디드 시스템이 발전하면서 다양한 하드웨어 환경이 등장했지만, 다음과 같은 문제들이 존재했습니다.

C언어는 절차지향 언어라 프로젝트 규모가 커질수록 유지보수 및 관리가 어려움
프로젝트 규모가 커질수록 유지보수가 어려움
제조사마다 사용하는 CPU 구조와 기계어 체계가 다름
하드웨어마다 별도로 프로그램을 준비해야 하는 번거로움 존재

해결 시도

썬 마이크로시스템즈(Sun Microsystems) 는 CPU와 운영체제에 상관없이 실행 가능한 언어를 만들고자 Java를 개발했습니다.

"한 번 작성하면 어디서든 실행 가능(Write Once, Run Anywhere)" 을 목표로 개발
초반에는 큰 주목을 받지 못했음
이후 WWW(World Wide Web) 의 발전과 함께 다시 부흥함

2. 자바의 특징

1) 플랫폼 독립성

CPU 및 운영체제에 상관없이 실행 가능
중간 단계인 바이트코드(Bytecode) 를 사용함
JVM이 바이트코드를 각 환경의 기계어로 변환하여 실행

핵심 흐름은 다음과 같습니다.

Java 코드 → 바이트코드(.class) → JVM → 기계어

추가로 알아두면 좋은 점

JVM은 단순히 바이트코드를 기계어로 변환만 하는 것이 아니라,
인터프리터 방식과 JIT(Just-In-Time Compiler) 를 함께 사용합니다.
자주 실행되는 코드는 JIT 컴파일을 통해 기계어로 변환하여 성능을 향상시킵니다.

2) 보안 안정성

JVM 내부에서 프로그램이 실행됨
운영체제에 직접 접근하지 않고 JVM이라는 울타리 안에서 동작

장점으로는 ①안정성이 높고 ②악성 코드 실행 위험이 감소하며 ③메모리 접근 오류도 줄어든다는 점이 있습니다.

3) 메모리 관리

C / C++ 의 경우 개발자가 직접 메모리를 관리해야 하기 때문에 속도는 빠르지만 관리가 어렵습니다.

반면 Java는,

JVM이 메모리를 자동 관리
Garbage Collector(GC) 를 통해 사용하지 않는 메모리 정리
관련 영역: Heap, Stack

4) 객체지향(Object-Oriented)

클래스와 객체 중심으로 개발
현실 세계를 코드로 표현하기 쉬움
장점: 높은 확장성, 높은 코드 재사용성, 유지보수 용이, 높은 유연성

3. JVM (Java Virtual Machine)

자바의 바이트코드를 실행하는 가상 머신

JVM은 다음과 같은 역할을 수행합니다.

바이트코드를 기계어로 변환 및 실행
운영체제로부터 메모리를 할당받음
JVM 내부에서 메모리 관리 수행
플랫폼 독립성을 제공하는 핵심 요소

4. JRE (Java Runtime Environment)

자바 프로그램 실행을 위한 최소 실행 환경

구성 요소

JVM
자바 클래스 라이브러리

특징

자바 프로그램 실행 가능
개발(컴파일)은 불가능
이미 컴파일된 바이트코드를 실행하는 역할

5. JDK (Java Development Kit)

자바 개발을 위한 도구 모음

특징

자바 코드 작성 및 컴파일 가능
바이트코드 생성 가능

구성 요소

JRE
javac (컴파일러)
디버거(Debugger)
개발 도구들

핵심 관계

JDK ⊃ JRE ⊃ JVM

즉, JDK 안에 JRE가 있고, JRE 안에 JVM이 포함되어 있습니다.

6. 전체 구조 정리

[개발 단계]

Java 코드 작성
        ↓
JDK(javac)로 컴파일
        ↓
바이트코드(.class) 생성

[실행 단계]

JRE 실행 환경 제공
        ↓
JVM이 바이트코드를 기계어로 변환
        ↓
운영체제에서 실행

마치며

자바는 "플랫폼 독립적인 언어" 라는 강력한 특징을 가진 프로그래밍 언어이다. 이를 가능하게 해주는 데에는 JVM, JRE, JDK가 큰 역할을 합니다.

JVM → 실행 엔진
JRE → 실행 환경
JDK → 개발 도구 모음

이 세 가지의 관계만 명확히 잡아두면, 앞으로 자바를 공부할 때 훨씬 수월하게 이해할 수 있을 것 같습니다.

프로그래머스 - H Index (Java)

jupeternotebook — Thu, 7 May 2026 09:58:36 +0900

프로그래머스 H-Index 풀이 과정
1트 오답, 2트 정답(수정), 3트 정답(힌트). 조건문의 의미를 이해하는 데 시간이 걸렸다.
총 3번의 제출

H-Index란, n편의 논문 중 h번 이상 인용된 논문이 h편 이상이고, 나머지 논문이 h번 이하 인용되었을 때 가장 큰 h를 의미한다.

1트 (오답)

→ 최대 인용 횟수까지 cnt를 증가시키며 완전탐색
→ 각 cnt에서 cnt번 이상 인용된 논문 수(more)와 이하인 논문 수(less)를 셈
→ more >= cnt && less <= cnt이면 answer를 more로 갱신

import java.util.*;
class Solution {
    public int solution(int[] citations) {
        Arrays.sort(citations);
        int max = citations[citations.length-1];

        int cnt = 0;
        int answer = 0;
        while(cnt<=max) {
            int more = 0;
            int less = 0;
            for(int i=0; i<citations.length; i++) {
                if(citations[i] >= cnt) more++;
                if(citations[i] <= cnt) less++;
            }

            if(more>=cnt && less<=cnt) answer = Math.max(answer, more);
            cnt++;
        }
        return answer;
    }
}

H-Index 정의를 코드로 옮기려 했는데, answer = more로 갱신하는 부분이 잘못됐다.
more는 "h번 이상 인용된 논문의 수"이지, h값 자체가 아니다.
예를 들어 citations = [3, 0, 6, 1, 5]일 때 cnt = 3이면 more = 3이지만, 이 둘이 같은 건 우연이지 항상 성립하지 않는다.
결국 h값이 뭔지 제대로 정의하지 못한 채 코드를 짰다.

1트 수정 (정답)

1트 코드에서 answer = Math.max(answer, more) 한 줄만 answer = cnt로 바꾸면 정답이 된다.

import java.util.*;
class Solution {
    public int solution(int[] citations) {
        Arrays.sort(citations);
        int max = citations[citations.length-1];

        int cnt = 0;
        int answer = 0;
        while(cnt<=max) {
            int more = 0;
            int less = 0;
            for(int i=0; i<citations.length; i++) {
                if(citations[i] >= cnt) more++;
                if(citations[i] <= cnt) less++;
            }

            if(more>=cnt && less<=cnt) answer = cnt;
            cnt++;
        }
        return answer;
    }
}

`answer = cnt`가 맞는 이유

1트에서 answer = more로 쓴 게 왜 틀렸는지를 다시 보면 답이 나온다.

조건 more >= cnt && less <= cnt가 의미하는 건 "cnt번 이상 인용된 논문이 cnt편 이상 존재한다"는 것이다.
이 조건을 만족하는 cnt가 바로 h의 정의를 충족하는 h값이다.
우리가 찾는 건 h값, 즉 cnt이지 논문의 수인 more가 아니다.

while이 cnt를 0부터 max까지 순회하므로, 조건을 만족할 때마다 answer = cnt로 덮어쓰면 자연스럽게 가장 큰 h값이 answer에 남는다.

citations = [3, 0, 6, 1, 5] 기준으로 단계별로 보면:

cnt	more (cnt 이상 인용)	less (cnt 이하 인용)	조건 성립?	answer
0	5	1	✅	0
1	4	2	✅	1
2	4	2	✅	2
3	3	3	✅	3
4	2	4	❌	3
5	2	4	❌	3
6	1	5	❌	3

cnt = 3에서 마지막으로 조건이 성립하고, answer = 3이 된다.

1트에서 more를 담은 건, "more편 이상 인용됐으니 more가 h값 아닌가?"라는 착각 때문이었다.
하지만 h값은 "몇 번 이상 인용"에 해당하는 기준값이고, 그게 바로 cnt다.

2트 (힌트를 받아 정답)

→ 내림차순 정렬
→ 인덱스 i를 순회하면서 list.get(i) >= i+1이면 answer = i+1로 갱신

import java.util.*;
class Solution {
    public int solution(int[] citations) {
        List<Integer> list = new ArrayList<>();
        for(int i : citations) list.add(i);
        Collections.sort(list, Collections.reverseOrder());

        int answer = 0;
        for(int i=0; i<list.size(); i++) {
            if(list.get(i) >= i+1) {
                answer = i+1;
            }
        }

        return answer;
    }
}

`list.get(i) >= i+1` 이 조건이 왜 맞는가

Q1. 내림차순 정렬을 왜 하는가

H-Index를 구하려면 결국 두 가지를 알아야 한다.

지금 기준이 되는 인용 수가 얼마인가
그 인용 수 이상인 논문이 몇 편인가

정렬 없이 이 둘을 알려면 1트처럼 매번 전체를 다 세야 한다.
그런데 내림차순으로 정렬하면 "몇 편인지"를 직접 셀 필요가 없어진다.

[3, 0, 6, 1, 5]를 내림차순 정렬하면 [6, 5, 3, 1, 0].
이제 왼쪽부터 논문을 하나씩 볼 때마다, 지금 보고 있는 논문까지는 전부 현재 값 이상 인용됐다는 게 자동으로 보장된다.
순서가 크기 순이니 당연한 얘기다.

Q2. i+1이 왜 논문 수인가

인덱스는 0부터 시작한다. 그래서 인덱스 i에 있다는 건 앞에 i개가 더 있다는 뜻이고, 지금까지 본 논문 수는 i+1편이다.

그리고 Q1에서 말한 대로, 내림차순이기 때문에 이 i+1편은 전부 list.get(i) 이상 인용됐다는 게 보장된다.

아래 표로 보면 직관적으로 이해가 된다.

[6, 5, 3, 1, 0] 기준:

i	list.get(i)	"이 값 이상 인용된 논문 수"는?
0	6	최소 1편 (인덱스 0만)
1	5	최소 2편 (인덱스 0~1)
2	3	최소 3편 (인덱스 0~2)
3	1	최소 4편 (인덱스 0~3)
4	0	최소 5편 (인덱스 0~4)

"이 값 이상 인용된 논문 수"가 항상 i+1이다. 별도로 세지 않아도 인덱스를 보면 바로 알 수 있다.

Q3. 그러면 조건 list.get(i) >= i+1은 무슨 뜻인가

H-Index 정의: h편 이상의 논문이 h번 이상 인용돼야 한다.

지금까지 정리한 걸 대입하면:

i+1 = 지금까지 본 논문 수
list.get(i) = 그 논문들의 최솟값 (= 이 값 이상 인용됐다는 기준)

list.get(i) >= i+1이면 → i+1편의 논문이 i+1번 이상 인용됐다 → H-Index 정의를 만족한다.

단계별로 보면:

i	list.get(i)	i+1	조건 성립?	해석	answer
0	6	1	✅	1편이 6번 이상 인용됨	1
1	5	2	✅	2편이 5번 이상 인용됨	2
2	3	3	✅	3편이 3번 이상 인용됨	3
3	1	4	❌	4편이 1번 이상 인용? → 조건 미달	3
4	0	5	❌	5편이 0번 이상 인용? → 조건 미달	3

i = 2에서 "3편이 3번 이상 인용됐다"가 성립하는 게 마지막이다. → answer = 3.

내림차순이라 i가 커질수록 list.get(i)는 작아지고 i+1은 커지기 때문에, 한 번 조건이 깨지면 그 뒤로는 다시 성립하지 않는다. 그래서 조건을 만족하는 마지막 i+1이 최댓값이고, 그게 answer에 남는다.

1트 / 1트 수정 / 2트 비교

	1트 (오답)	1트 수정 (정답)	2트 (정답)
접근 방식	완전탐색	완전탐색	정렬 후 한 번 순회
시간복잡도	O(n × max)	O(n × max)	O(n log n)
h값 결정	`more`로 잘못 설정	`cnt`로 정확히 표현	`i+1`로 정확히 표현
핵심 아이디어	h의 정의를 코드로 나열	h의 정의를 코드로 나열	정렬 후 인덱스가 논문 수를 대변

1트와 1트 수정의 차이는 딱 한 줄, more → cnt뿐이다.
로직의 방향은 처음부터 맞았는데, h값이 cnt라는 걸 놓쳤다.
2트는 완전탐색 없이 정렬만으로 같은 결과를 얻는다. 인덱스가 논문 수를 대신하기 때문에 별도의 카운팅이 필요 없다.

조건문 list.get(i) >= i+1 한 줄이 이해가 안 됐던 이유는, 내림차순 정렬 후 인덱스가 무엇을 의미하는지 파악을 못 했기 때문이다.
정렬 후 인덱스가 "지금까지 몇 편"인지를 나타낸다는 걸 이해하고 나면 조건이 자연스럽게 읽힌다.
앞으로 정렬 문제에서 인덱스가 카운터 역할을 할 수 있다는 걸 기억해두면 좋을 것 같다.

프로그래머스 - K번째 수 (JAVA)

jupeternotebook — Fri, 1 May 2026 17:48:23 +0900

프로그래머스 K번째수 풀이 과정
1트 정답. 과거 코드와 비교했을 때 Arrays.copyOfRange() 덕분에 훨씬 간결해졌다.
총 1번의 제출

i번째부터 j번째까지 자르고, 정렬한 뒤 k번째 값을 반환하면 된다.
로직 자체는 단순해서 바로 구현했다.

1트 (정답)

→ commands를 순회하면서 i, j, k를 꺼낸다.
→ Arrays.copyOfRange()로 array의 i-1부터 j까지 잘라 새 배열을 만든다.
→ Arrays.sort()로 정렬한 뒤 k-1 인덱스 값을 answer에 담는다.

import java.util.*;

class Solution {
    public int[] solution(int[] array, int[][] commands) {
        int[] answer = new int[commands.length];

        int idx = 0;
        for(int[] command : commands) {
            int i = command[0];
            int j = command[1];
            int k = command[2];
            int[] copy = Arrays.copyOfRange(array, i-1, j);
            Arrays.sort(copy);
            answer[idx++] = copy[k-1];
        }
        return answer;
    }
}

`Arrays.copyOfRange()` 란

Arrays.copyOfRange(원본 배열, 시작 인덱스, 끝 인덱스)

원본 배열의 특정 범위를 잘라 새로운 배열로 반환하는 메서드다.
시작 인덱스는 포함, 끝 인덱스는 미포함이다.

int[] arr = {1, 2, 3, 4, 5};
int[] copy = Arrays.copyOfRange(arr, 1, 4);
// copy = {2, 3, 4}

원본 배열은 그대로 유지되고, 잘라낸 범위만 담긴 새 배열이 생성된다.
이 문제처럼 배열의 일부를 정렬해야 할 때 원본을 건드리지 않고 쓸 수 있어서 유용하다.

위 풀이의 결과

copyOfRange() 한 줄로 범위 추출과 새 배열 생성을 동시에 처리했다.
int[] 기본 타입 배열이라 Arrays.sort()가 바로 적용된다.
과거 코드와 비교하면 코드가 눈에 띄게 짧아졌다.

과거 코드와 비교

import java.util.ArrayList;
import java.util.Collections;
import java.util.Scanner;
class Solution {
    public int[] solution(int[] array, int[][] commands) {
        int[] answer = new int[commands.length];
        for(int i=0; i<commands.length; i++) {
            ArrayList<Integer> tmp = new ArrayList<>();
            for(int j=commands[i][0]-1; j<commands[i][1]; j++) {
                tmp.add(array[j]);
            }
            Collections.sort(tmp);
            answer[i] = tmp.get(commands[i][2]-1);
        }
        return answer;
    }
}

	현재 코드	과거 코드
범위 추출	`Arrays.copyOfRange()` 한 줄	`for`문으로 직접 순회하며 `add()`
자료구조	`int[]` 기본 배열	`ArrayList<Integer>`
정렬	`Arrays.sort()`	`Collections.sort()`
인덱스 접근	`copy[k-1]`	`tmp.get(commands[i][2]-1)`
불필요한 import	없음	`Scanner` import가 있는데 사용 안 함

과거 코드는 copyOfRange()를 몰랐으니 for문으로 직접 ArrayList에 옮겨 담았다.
로직은 동일하지만 ArrayList를 쓰면 int → Integer 박싱 비용이 발생하고, Collections.sort()까지 써야 해서 현재 코드보다 무겁다.

어떤 코드가 더 나은가 하면 현재 코드다.
copyOfRange()로 기본 타입 배열을 그대로 다루니까 박싱 오버헤드가 없고, 코드도 짧고 읽기 편하다.
과거 코드가 틀린 건 아니지만, Arrays.copyOfRange()를 알고 나면 굳이 ArrayList를 쓸 이유가 없다.

로직 자체는 과거에도 맞게 짰다. 달라진 건 copyOfRange()라는 도구를 하나 알게 된 것뿐이다.
아는 메서드가 늘어날수록 코드가 짧아지고, 불필요한 자료구조 변환도 줄어든다.
앞으로 배열 일부를 다뤄야 할 때 copyOfRange()를 바로 떠올릴 수 있을 것 같다.

프로그래머스 - 가장 큰 수 (JAVA)

jupeternotebook — Fri, 1 May 2026 17:38:51 +0900

프로그래머스 가장 큰 수 풀이 과정
스스로 풀지 못했다. 접근 방향은 두 번 바꿨는데 둘 다 코드로 구현하지 못했다.
과거 코드(남의 코드)를 참고해서 정답을 냈고, 핵심 로직을 이번에 제대로 이해했다.
총 1번의 제출

처음엔 만들 수 있는 모든 숫자를 ArrayList에 넣고 내림차순 정렬하면 가장 큰 수가 맨 앞에 오지 않을까라고 단순하게 접근했다.
근데 모든 경우의 수는 배열 길이에 따라 너무 커지고, 반복문으로 모든 조합을 만드는 방식 자체가 머릿속에서 정리가 안 됐다.

두 번째로 생각한 방법은 정렬 기준 자체를 정의하는 거였다.
길이가 같으면 내림차순, 길이가 다르면 두 자리 수의 일의 자리와 한 자리 수를 비교해서 정렬하는 방식이었는데,
이것도 코드로 구현하기엔 너무 복잡했다.

결국 과거에 참고했던 남의 코드를 다시 꺼냈다. 근데 여전히 핵심 로직이 이해가 안 됐다.
이번 기회에 제대로 뜯어봤다.

1트 (정답, 남의 코드 참고)

→ int[]를 String[]으로 변환한다.
→ 두 문자열 s1, s2를 이어 붙인 결과를 비교해서 정렬 순서를 정한다.
→ (s2+s1).compareTo(s1+s2) — 이게 핵심이다.
→ 모든 값이 "0"이면 "0" 반환, 아니면 정렬된 순서대로 이어 붙인다.

import java.util.*;

class Solution {
    public String solution(int[] numbers) {
        String[] array = new String[numbers.length];

        for(int i=0; i<numbers.length; i++) {
            array[i] = String.valueOf(numbers[i]);
        }

        Arrays.sort(array, new Comparator<String>() {
            @Override
            public int compare(String s1, String s2) {
                return (s2+s1).compareTo(s1+s2);
            }
        });

        if(array[0].equals("0")) return "0";

        String answer = "";
        for(String s : array) answer += s;

        return answer;
    }
}

핵심 로직 이해 — `(s2+s1).compareTo(s1+s2)`

이게 왜 동작하는지가 이 문제의 전부다.

예를 들어 s1 = "3", s2 = "30"이라고 해보자.

s1 + s2 = "330"
s2 + s1 = "303"

둘 중 어떤 순서로 붙여야 더 큰 수가 될까?
"330" > "303" 이니까 s1이 앞에 와야 한다.

compareTo는 (s2+s1)이 (s1+s2)보다 작으면 음수를 반환한다.
Arrays.sort는 음수가 나오면 s1을 앞에 유지한다.
즉, 두 문자열을 이어 붙였을 때 더 큰 쪽이 앞에 오도록 정렬되는 것이다.

s1	s2	s1+s2	s2+s1	앞에 와야 할 것
"3"	"30"	"330"	"303"	s1 ("3")
"9"	"5"	"95"	"59"	s2 ("9")
"34"	"3"	"343"	"334"	s1 ("34")

내가 두 번째로 시도했던 "길이가 다르면 일의 자리를 비교하자"는 방향은 사실 이 로직이 해결하는 문제와 같은 문제를 풀려고 한 거였다. 근데 직접 비교 조건을 나열하려다 보니 케이스가 너무 많아졌던 것이고, 이 코드는 그냥 붙여보고 더 큰 쪽을 앞에 놓는다 는 단순한 아이디어로 모든 케이스를 한 번에 해결한 거다.

위 풀이의 결과

정렬 기준을 직접 정의하는 Comparator를 활용한 풀이다.
array[0].equals("0") 체크는 입력이 [0, 0, 0]처럼 전부 0인 경우 "000" 대신 "0"을 반환하기 위한 처리다.
코드 자체는 짧지만, (s2+s1).compareTo(s1+s2) 라는 발상을 스스로 떠올리기가 쉽지 않다.

이 문제는 솔직히 스스로 못 풀었다.
첫 번째 접근(모든 경우의 수)은 방향 자체가 틀렸고, 두 번째 접근(직접 비교 조건 나열)은 방향은 맞았지만 구현을 못 했다.
핵심 아이디어인 "두 수를 이어 붙여서 더 큰 쪽이 앞에 오도록 정렬한다" 는 발상은 이번에 제대로 이해했다.
다음에 비슷한 문제가 나오면 바로 Comparator에서 두 원소를 조합해서 비교하는 방식을 먼저 떠올릴 수 있을 것 같다.

프로그래머스 - 디스크 컨트롤러 (JAVA)

jupeternotebook — Tue, 28 Apr 2026 01:40:34 +0900

프로그래머스 디스크 컨트롤러 풀이 과정 우선순위 큐를 써야 한다는 건 알았는데, 요청 시각 기준 정렬과 현재 시간 관리를 놓쳤다. NullPointer에 너무 많이 걸려서 어느 지점에서 터지는지는 GPT 도움을 받았고, 나머지는 스스로 풀었다. 총 2번의 제출

1트 (오답) → 요청 시각 무시, 현재 시간 관리 없이 큐에 전부 넣고 순서대로 처리 2트 (정답) → 요청 시각 기준 정렬 후, 현재 시간에 들어온 작업만 큐에 투입

작업 시간이 짧은 것부터 처리하는 SJF(Shortest Job First) 스케줄링 문제라는 걸 파악하고, 소요 시간 기준 최소 힙으로 접근했다. 문제는 "현재 시각에 요청된 작업만 처리 가능하다" 는 조건을 처음엔 제대로 반영하지 못했다.

1트 (오답)

→ 전체 작업을 처음부터 큐에 다 넣어버렸다. → time을 첫 번째 작업의 요청 시각으로 초기화하고, 큐에서 꺼내는 순서대로 처리했다. → 요청 시각과 무관하게 소요 시간이 짧은 것부터 처리되는 구조가 됐다.

import java.util.*;
class Solution {
    public int solution(int[][] jobs) {
        PriorityQueue<int[]> pq = new PriorityQueue<>((int[] a, int[] b) -> {
            if(a[1] == b[1]) return a[0] - b[0];
            else if(a[2] == b[2]) return a[1] - b[1];
            else return a[2] - b[2];
        });
        
        int num = 0;
        for(int[] job : jobs) {
            pq.offer(new int[]{num++, job[0], job[1]});
        }
        
        int time = pq.peek()[1];
        int answer = 0;
        while(!pq.isEmpty()) {
            int[] cur = pq.poll();
            time += cur[2];
            answer += time - cur[1];
        }
        
        return answer/num;
    }
}

위 풀이의 결과

아직 요청되지도 않은 작업이 큐에 들어가 있으니, 현재 시각보다 늦게 들어오는 작업이 먼저 처리되는 경우가 생긴다.
예를 들어 요청 시각이 100인 작업이 소요 시간이 짧다고 time = 0일 때 먼저 처리되면 대기 시간 계산 자체가 어긋난다.
NullPointer도 발생했는데, 큐 비교 로직에서 a[2]가 없는 경우를 처리 못 했기 때문이었다. 이 부분은 GPT에게 어느 지점에서 터지는지 확인했다.

2트 (정답)

→ 먼저 요청 시각 기준으로 jobs를 정렬했다. → 현재 시각 time 이하로 요청된 작업만 큐에 넣고, 그 중 소요 시간이 가장 짧은 것을 처리한다. → 큐가 비어있으면 아직 요청된 작업이 없다는 뜻이므로 time++로 시간을 흘려보낸다.

import java.util.*;
class Solution {
    public int solution(int[][] jobs) {
        Arrays.sort(jobs, (a,b)->{
            if(a[0] == b[0]) return a[1] - b[1];
            else return a[0] - b[0];
        });
        
        PriorityQueue<int[]> pq = new PriorityQueue<>((int[] a, int[] b) -> {
            if(a[1] == b[1]) return a[0] - b[0];
            else if(a[2] == b[2]) return a[1] - b[1];
            else return a[2] - b[2];
        });
        
        int num = 0;
        int time = 0;
        int answer = 0;
        while(num < jobs.length || !pq.isEmpty()) {
            // 현재 시각 이하로 요청된 작업을 큐에 투입
            for(int i=num; i<jobs.length; i++) {
                if(jobs[i][0] <= time) {
                    pq.offer(new int[] {i, jobs[i][0], jobs[i][1]});
                    num++;
                }
            }
            
            if(!pq.isEmpty()) {
                int[] cur = pq.poll();
                time += cur[2];
                answer += time - cur[1];
            }
            else time++; // 아직 요청된 작업 없음 → 시간만 흘림
        }
        
        return answer/num;
    }
}

위 풀이의 결과

요청 시각 기준으로 정렬해두니 time 이하인 작업만 순서대로 큐에 넣을 수 있었다.
else time++이 핵심이다. 큐가 비어있는 구간, 즉 다음 작업이 아직 요청되지 않은 구간을 건너뛰는 역할을 한다.
루프 조건을 num < jobs.length || !pq.isEmpty()로 잡은 덕분에, 모든 작업을 투입한 뒤 큐에 남은 것까지 처리하고 끝난다.

1트에서 요청 시각 조건을 완전히 무시하고 전부 큐에 넣어버린 게 근본적인 실수였다. 스케줄링 문제에서 "현재 시각에 요청된 작업만 처리 가능하다" 는 조건은 단순해 보여도 구현에서 가장 중요한 부분이다. NullPointer 위치는 GPT 도움을 받았지만, 구조 자체는 직접 고쳤다. 그래도 AI 없이 완전히 혼자 풀지 못했다는 게 아쉽다. 다음에 비슷한 구조의 문제가 나오면 정렬 → 현재 시각 기준 투입 → SJF 처리 흐름을 바로 떠올릴 수 있을 것 같다.

[자료구조] Stack, Queue, Deque, PriorityQueue — Java

jupeternotebook — Fri, 24 Apr 2026 17:31:25 +0900

코딩테스트에서 DFS/BFS/시뮬레이션 문제가 나오면 가장 먼저 떠올려야 할 자료구조들을 정리합니다.

1. 스택(Stack)

LIFO(Last In First Out) 구조로, 마지막에 삽입된 데이터가 먼저 나오는 자료구조입니다.
아래 그림처럼 데이터를 위에서 넣고(push), 위에서 꺼냅니다(pop).

연산	설명	시간복잡도
push	top에 데이터 삽입	O(1)
pop	top에서 데이터 삭제 및 반환	O(1)
peek	top 데이터 조회 (삭제 안 함)	O(1)

코딩테스트 활용

DFS (깊이 우선 탐색)
괄호 검사
후위 연산 (역폴란드 표기법)
재귀 알고리즘 대체

⚠️ Stack 클래스 vs ArrayDeque
공식문서에서는 Stack 클래스 대신 Deque 인터페이스 사용을 권장합니다.
Stack은 내부적으로 Vector를 상속받아 불필요한 동기화 오버헤드가 발생합니다.
코딩테스트에서는 ArrayDeque을 스택으로 사용하는 것이 더 빠릅니다.

// ❌ 권장하지 않음
Stack<Integer> stack = new Stack<>();

// ✅ 권장
Deque<Integer> stack = new ArrayDeque<>();

주요 메서드

import java.util.ArrayDeque;
import java.util.Deque;

Deque<Integer> stack = new ArrayDeque<>();

stack.push(1);       // 삽입 (앞에 추가)
stack.push(2);
stack.push(3);

stack.peek();        // 최상단 조회 → 3 (삭제 안 함)
stack.pop();         // 최상단 제거 및 반환 → 3
stack.isEmpty();     // 비어있는지 확인
stack.size();        // 원소 개수

✅ 전체 예제

import java.util.ArrayDeque;
import java.util.Deque;

public class StackExample {
    public static void main(String[] args) {
        Deque<Integer> stack = new ArrayDeque<>();

        stack.push(1);
        stack.push(2);
        stack.push(3);

        System.out.println(stack.peek()); // 3
        System.out.println(stack.pop());  // 3
        System.out.println(stack.pop());  // 2
        System.out.println(stack.size()); // 1
    }
}

2. 큐(Queue)

FIFO(First In First Out) 구조로, 먼저 삽입된 데이터가 먼저 나오는 자료구조입니다.
아래 그림처럼 rear에서 넣고(offer), front에서 꺼냅니다(poll).

연산	설명	시간복잡도
offer	rear에 데이터 삽입	O(1)
poll	front에서 데이터 삭제 및 반환	O(1)
peek	front 데이터 조회 (삭제 안 함)	O(1)

코딩테스트 활용

BFS (너비 우선 탐색)
시뮬레이션 (순서대로 처리)
슬라이딩 윈도우

Java에서 Queue는 인터페이스입니다. 코딩테스트에서는 ArrayDeque이 가장 빠릅니다.

// LinkedList — 가능하지만 느림
Queue<Integer> queue = new LinkedList<>();

// ✅ ArrayDeque — 코딩테스트 권장
Queue<Integer> queue = new ArrayDeque<>();

주요 메서드

import java.util.ArrayDeque;
import java.util.Queue;

Queue<Integer> queue = new ArrayDeque<>();

queue.offer(1);      // 삽입 (rear에 추가)
queue.offer(2);
queue.offer(3);

queue.peek();        // front 조회 → 1 (삭제 안 함)
queue.poll();        // front 제거 및 반환 → 1
queue.isEmpty();     // 비어있는지 확인
queue.size();        // 원소 개수

add() / remove() 도 있지만, 실패 시 예외를 던집니다.
코딩테스트에서는 null 또는 false를 반환하는 offer() / poll()을 사용하세요.

✅ 전체 예제

import java.util.ArrayDeque;
import java.util.Queue;

public class QueueExample {
    public static void main(String[] args) {
        Queue<Integer> queue = new ArrayDeque<>();

        queue.offer(1);
        queue.offer(2);
        queue.offer(3);

        System.out.println(queue.peek()); // 1
        System.out.println(queue.poll()); // 1
        System.out.println(queue.poll()); // 2
        System.out.println(queue.size()); // 1
    }
}

3. 덱(Deque)

Double Ended Queue의 줄임말로, 양쪽 끝에서 삽입/삭제가 모두 가능한 자료구조입니다.
Stack과 Queue의 기능을 모두 포함합니다.

아래 그림처럼 앞/뒤 양쪽에서 삽입과 삭제가 모두 가능합니다.

삽입 메서드

삭제 메서드

코딩테스트 활용

슬라이딩 윈도우 최솟값/최댓값
양방향 BFS
팰린드롬 검사
스택 + 큐를 동시에 필요로 하는 문제

주요 메서드

import java.util.ArrayDeque;
import java.util.Deque;

Deque<Integer> deque = new ArrayDeque<>();

// 앞쪽 삽입/조회/삭제
deque.offerFirst(1);   // 앞에 삽입 (= addFirst)
deque.peekFirst();     // 앞 조회
deque.pollFirst();     // 앞 제거 및 반환 (= removeFirst)

// 뒤쪽 삽입/조회/삭제
deque.offerLast(2);    // 뒤에 삽입 (= addLast, offer, add)
deque.peekLast();      // 뒤 조회
deque.pollLast();      // 뒤 제거 및 반환 (= removeLast)

deque.isEmpty();       // 비어있는지 확인
deque.size();          // 원소 개수

✅ 전체 예제

import java.util.ArrayDeque;
import java.util.Deque;

public class DequeExample {
    public static void main(String[] args) {
        Deque<Integer> deque = new ArrayDeque<>();

        deque.offerLast(1);   // [1]
        deque.offerLast(2);   // [1, 2]
        deque.offerFirst(0);  // [0, 1, 2]

        System.out.println(deque.peekFirst()); // 0
        System.out.println(deque.peekLast());  // 2
        System.out.println(deque.pollFirst()); // 0 → [1, 2]
        System.out.println(deque.pollLast());  // 2 → [1]
    }
}

4. 우선순위 큐(PriorityQueue)

삽입 순서와 관계없이 우선순위가 높은 원소가 먼저 나오는 자료구조입니다.
내부적으로 힙(Heap) 구조로 구현되어 있습니다.

기본값: 최솟값(오름차순)이 먼저 나오는 최소 힙(Min Heap)
Comparator를 활용해 최대 힙(Max Heap)으로 변경 가능

연산	시간복잡도
offer (삽입)	O(log n)
poll (삭제)	O(log n)
peek (조회)	O(1)

코딩테스트 활용

다익스트라(Dijkstra) 알고리즘
그리디 — 항상 최솟값/최댓값 처리
K번째 원소 찾기
작업 스케줄링

주요 메서드

import java.util.PriorityQueue;
import java.util.Collections;

// 최소 힙 (기본)
PriorityQueue<Integer> minHeap = new PriorityQueue<>();

// 최대 힙
PriorityQueue<Integer> maxHeap = new PriorityQueue<>(Collections.reverseOrder());

minHeap.offer(3);    // 삽입
minHeap.offer(1);
minHeap.offer(2);

minHeap.peek();      // 최솟값 조회 → 1 (삭제 안 함)
minHeap.poll();      // 최솟값 제거 및 반환 → 1
minHeap.isEmpty();   // 비어있는지 확인
minHeap.size();      // 원소 개수

✅ 전체 예제 — 최소 힙 / 최대 힙

import java.util.PriorityQueue;
import java.util.Collections;

public class PriorityQueueExample {
    public static void main(String[] args) {
        // 최소 힙
        PriorityQueue<Integer> minHeap = new PriorityQueue<>();
        minHeap.offer(3);
        minHeap.offer(1);
        minHeap.offer(2);
        System.out.println(minHeap.poll()); // 1
        System.out.println(minHeap.poll()); // 2
        System.out.println(minHeap.poll()); // 3

        // 최대 힙
        PriorityQueue<Integer> maxHeap = new PriorityQueue<>(Collections.reverseOrder());
        maxHeap.offer(3);
        maxHeap.offer(1);
        maxHeap.offer(2);
        System.out.println(maxHeap.poll()); // 3
        System.out.println(maxHeap.poll()); // 2
        System.out.println(maxHeap.poll()); // 1
    }
}

✅ 커스텀 정렬 (객체 우선순위 지정)

// [값, 인덱스] 배열을 값 기준 오름차순 정렬
PriorityQueue<int[]> pq = new PriorityQueue<>((a, b) -> a[0] - b[0]);
pq.offer(new int[]{5, 0});
pq.offer(new int[]{1, 1});
pq.offer(new int[]{3, 2});

System.out.println(pq.poll()[0]); // 1
System.out.println(pq.poll()[0]); // 3
System.out.println(pq.poll()[0]); // 5

5. 자료구조 비교 요약

	Stack	Queue	Deque	PriorityQueue
구조	LIFO	FIFO	양방향	우선순위
권장 구현체	`ArrayDeque`	`ArrayDeque`	`ArrayDeque`	`PriorityQueue`
삽입/삭제	O(1)	O(1)	O(1)	O(log n)
주요 사용처	DFS, 괄호검사	BFS, 순서처리	슬라이딩 윈도우	다익스트라, 그리디

ArrayDeque는 Stack보다 빠르고, LinkedList보다 큐로서 빠릅니다. (공식문서)
코딩테스트에서 스택/큐 모두 ArrayDeque를 기본으로 사용하세요.

6. 코딩테스트 자주 쓰는 패턴 모음

패턴 ① 괄호 검사 (Stack)

public boolean isValid(String s) {
    Deque<Character> stack = new ArrayDeque<>();

    for (char c : s.toCharArray()) {
        if (c == '(' || c == '{' || c == '[') {
            stack.push(c);
        } else {
            if (stack.isEmpty()) return false;
            char top = stack.pop();
            if (c == ')' && top != '(') return false;
            if (c == '}' && top != '{') return false;
            if (c == ']' && top != '[') return false;
        }
    }
    return stack.isEmpty();
}

패턴 ② BFS 최단 거리 (Queue)

int[] dx = {0, 0, 1, -1};
int[] dy = {1, -1, 0, 0};

Queue<int[]> queue = new ArrayDeque<>();
queue.offer(new int[]{startX, startY});
visited[startX][startY] = true;

while (!queue.isEmpty()) {
    int[] cur = queue.poll();
    int x = cur[0], y = cur[1];

    for (int d = 0; d < 4; d++) {
        int nx = x + dx[d];
        int ny = y + dy[d];
        if (nx >= 0 && ny >= 0 && nx < N && ny < M && !visited[nx][ny]) {
            visited[nx][ny] = true;
            queue.offer(new int[]{nx, ny});
        }
    }
}

패턴 ③ 슬라이딩 윈도우 최솟값 (Deque)

int[] nums = {1, 3, -1, -3, 5, 3, 6, 7};
int k = 3;
int[] result = new int[nums.length - k + 1];

Deque<Integer> deque = new ArrayDeque<>(); // 인덱스 저장

for (int i = 0; i < nums.length; i++) {
    while (!deque.isEmpty() && deque.peekFirst() < i - k + 1) {
        deque.pollFirst();
    }
    while (!deque.isEmpty() && nums[deque.peekLast()] >= nums[i]) {
        deque.pollLast();
    }
    deque.offerLast(i);

    if (i >= k - 1) {
        result[i - k + 1] = nums[deque.peekFirst()];
    }
}
// result = [-1, -3, -3, -3, 3, 3]

패턴 ④ K번째 최솟값 (PriorityQueue)

int[] nums = {3, 1, 4, 1, 5, 9, 2, 6};
int k = 3;

PriorityQueue<Integer> pq = new PriorityQueue<>();
for (int n : nums) pq.offer(n);

int result = 0;
for (int i = 0; i < k; i++) {
    result = pq.poll();
}
System.out.println(result); // 3번째 최솟값: 3

️ 패턴 ⑤ 다익스트라 (PriorityQueue)

PriorityQueue<int[]> pq = new PriorityQueue<>((a, b) -> a[0] - b[0]);
int[] dist = new int[N + 1];
Arrays.fill(dist, Integer.MAX_VALUE);

dist[start] = 0;
pq.offer(new int[]{0, start});

while (!pq.isEmpty()) {
    int[] cur = pq.poll();
    int cost = cur[0], node = cur[1];

    if (cost > dist[node]) continue;

    for (int[] next : graph[node]) {
        int nextNode = next[0], nextCost = cost + next[1];
        if (nextCost < dist[nextNode]) {
            dist[nextNode] = nextCost;
            pq.offer(new int[]{nextCost, nextNode});
        }
    }
}

정리 요약

자료구조	핵심 특징	코딩테스트 활용
`Stack (ArrayDeque)`	LIFO	DFS, 괄호 검사, 역순 처리
`Queue (ArrayDeque)`	FIFO	BFS, 순서대로 처리
`Deque (ArrayDeque)`	양방향	슬라이딩 윈도우, 팰린드롬
`PriorityQueue`	우선순위(Heap)	다익스트라, 그리디, K번째 값

⚡ 코테 핵심 공식
"DFS → Stack(ArrayDeque)"
"BFS → Queue(ArrayDeque)"
"최솟값/최댓값 반복 → PriorityQueue"
"양쪽 모두 필요 → Deque(ArrayDeque)"

참고 자료

[자료구조] Hash(해시) — Java

jupeternotebook — Fri, 24 Apr 2026 17:13:41 +0900

코딩테스트에서 탐색/카운팅 문제가 나오면 가장 먼저 떠올려야 할 자료구조, 해시(Hash)를 정리합니다.

1. 해시란 무엇인가?

해시는 해시 함수를 사용해 Key를 특정 인덱스로 변환하여, 해당 인덱스에 데이터를 저장하는 자료구조입니다. Key를 통해 값에 O(1)로 직접 접근할 수 있어 탐색 횟수가 많은 문제에 적합합니다.

Key  →  [해시 함수]  →  Hash Value(Index)  →  Bucket(실제 저장 공간)

해시 함수: Key를 정수 인덱스로 변환하는 함수. Java에서는 hashCode()가 담당
버킷(Bucket): 실제 데이터가 저장되는 공간
해시 테이블: 버킷들의 배열

⚡ 시간복잡도

연산	해시	배열	이진탐색트리
탐색	O(1)	O(n)	O(log n)
삽입	O(1)	O(n)	O(log n)
삭제	O(1)	O(n)	O(log n)

충돌이 심하면 최악 O(n)까지 떨어질 수 있지만, 평균적으로 O(1)입니다.

2. 해시 충돌(Collision)과 해결 방법

서로 다른 Key가 동일한 해시 값을 가지는 현상을 충돌(Collision)이라 합니다.

"Lee"  → hashCode() → 5
"Chun" → hashCode() → 5  //   충돌!

해결 방법 ①: 체이닝(Chaining)

충돌 발생 시 해당 버킷에 연결 리스트(Linked List)로 데이터를 이어 붙입니다.
Java의 HashMap이 이 방식을 사용하며, 연결 데이터가 일정 개수를 초과하면 자동으로 이진 탐색 트리로 전환합니다.

index 5: [Lee] → [Chun] → null

해결 방법 ②: 개방 주소법(Open Addressing)

충돌 발생 시 다른 빈 버킷을 찾아서 저장합니다.

선형 탐사: 1칸씩 이동하며 빈 자리 탐색
제곱 탐사: 1, 4, 9... 제곱수만큼 이동하며 탐색

3. HashMap — 키-값 쌍 저장소

Map 인터페이스의 해시 테이블 기반 구현체입니다. Key-Value 쌍으로 데이터를 저장하며, 삽입 순서를 보장하지 않습니다.

import java.util.HashMap;

HashMap<String, Integer> map = new HashMap<>();

주요 메서드

✅ 삽입 / 수정

map.put("apple", 3);         // 키-값 추가
map.put("apple", 5);         // 이미 있는 키면 값 덮어쓰기
map.putIfAbsent("apple", 9); // 키가 없을 때만 삽입 (있으면 무시)

✅ 조회

map.get("apple");                      // 값 반환, 없으면 null
map.getOrDefault("banana", 0);         // 없으면 기본값(0) 반환
map.containsKey("apple");              // 키 존재 여부 → true/false
map.containsValue(3);                  // 값 존재 여부 → true/false

getOrDefault()는 카운팅 문제에서 NPE 방지에 필수입니다!
map.put(ch, map.getOrDefault(ch, 0) + 1);

✅ 삭제

map.remove("apple");          // 키로 삭제
map.clear();                  // 전체 삭제

✅ 상태 확인

map.size();       // 데이터 개수
map.isEmpty();    // 비어있는지 여부

✅ 전체 예제

import java.util.HashMap;

public class HashMapExample {
    public static void main(String[] args) {
        HashMap<String, Integer> map = new HashMap<>();

        map.put("apple", 3);
        map.put("banana", 1);
        map.put("cherry", 5);

        System.out.println(map.get("apple"));               // 3
        System.out.println(map.getOrDefault("grape", 0));   // 0
        System.out.println(map.containsKey("banana"));      // true
        System.out.println(map.size());                      // 3

        map.remove("banana");
        System.out.println(map.size());                      // 2
    }
}

4. HashSet — 중복 없는 집합

Set 인터페이스의 해시 테이블 기반 구현체입니다. 중복을 허용하지 않으며, 내부적으로 HashMap<E, Object>로 구현되어 있습니다. 삽입 순서를 보장하지 않습니다.

import java.util.HashSet;

HashSet<String> set = new HashSet<>();

주요 메서드

set.add("apple");           // 추가 (중복이면 무시, false 반환)
set.remove("apple");        // 삭제
set.contains("apple");      // 존재 여부 → true/false
set.size();                 // 원소 개수
set.isEmpty();              // 비어있는지 여부
set.clear();                // 전체 삭제

✅ 전체 예제

import java.util.HashSet;

public class HashSetExample {
    public static void main(String[] args) {
        HashSet<String> set = new HashSet<>();

        set.add("apple");
        set.add("banana");
        set.add("apple");   // 중복 → 무시됨

        System.out.println(set.size());            // 2
        System.out.println(set.contains("apple")); // true

        set.remove("apple");
        System.out.println(set.contains("apple")); // false
    }
}

5. HashMap vs HashSet 비교

	HashMap	HashSet
저장 방식	Key-Value 쌍	Value만 저장
중복 허용	Key 중복 불가, Value 중복 가능	중복 불가
주요 메서드	put, get, remove, containsKey	add, remove, contains
주요 사용처	빈도 계산, 매핑, 그룹핑	중복 제거, 방문 체크

6. 순회(Iteration)

HashMap 순회

// ① Key만 순회
for (String key : map.keySet()) {
    System.out.println(key);
}

// ② Value만 순회
for (int value : map.values()) {
    System.out.println(value);
}

// ③ Key + Value 함께 순회 (가장 많이 쓰임)
for (Map.Entry<String, Integer> entry : map.entrySet()) {
    System.out.println(entry.getKey() + " : " + entry.getValue());
}

HashSet 순회

for (String s : set) {
    System.out.println(s);
}

⚠️ HashMap과 HashSet 모두 삽입 순서를 보장하지 않습니다.
순서가 필요하다면 LinkedHashMap / LinkedHashSet을 사용하세요.

7. 정렬(Sorting)

HashMap은 기본적으로 정렬을 지원하지 않으므로 아래 방법을 활용합니다.

① Key 기준 정렬

// 오름차순
List<String> keys = new ArrayList<>(map.keySet());
Collections.sort(keys);

// 내림차순
keys.sort(Collections.reverseOrder());

② Value 기준 정렬

// Value 오름차순
List<Map.Entry<String, Integer>> entries = new ArrayList<>(map.entrySet());
entries.sort(Map.Entry.comparingByValue());

// Value 내림차순
entries.sort(Map.Entry.comparingByValue(Comparator.reverseOrder()));

for (Map.Entry<String, Integer> e : entries) {
    System.out.println(e.getKey() + " : " + e.getValue());
}

③ TreeMap — Key 정렬 자동 유지

삽입 시 Key 기준 오름차순 정렬이 자동으로 유지됩니다.

import java.util.TreeMap;

TreeMap<String, Integer> treeMap = new TreeMap<>();
treeMap.put("banana", 1);
treeMap.put("apple", 3);
treeMap.put("cherry", 5);

for (String key : treeMap.keySet()) {
    System.out.println(key); // apple → banana → cherry
}

8. 코딩테스트 자주 쓰는 패턴 모음

패턴 ① 문자/단어 빈도 카운팅

String str = "hello world";
HashMap<Character, Integer> freq = new HashMap<>();

for (char c : str.toCharArray()) {
    freq.put(c, freq.getOrDefault(c, 0) + 1);
}
// {h=1, e=1, l=3, o=2, ' '=1, w=1, r=1, d=1}

✅ 패턴 ② 방문 체크 / 중복 확인

HashSet<Integer> visited = new HashSet<>();

visited.add(1);
visited.add(2);

if (!visited.contains(3)) {
    System.out.println("처음 방문!");
    visited.add(3);
}

패턴 ③ 그룹핑 (같은 키에 여러 값 묶기)

// 알파벳 순서로 그룹핑 (anagram 문제 등)
HashMap<String, List<String>> groups = new HashMap<>();
String[] words = {"eat", "tea", "tan", "ate", "nat", "bat"};

for (String word : words) {
    char[] chars = word.toCharArray();
    Arrays.sort(chars);
    String key = new String(chars);

    groups.computeIfAbsent(key, k -> new ArrayList<>()).add(word);
}
// {aet=[eat, tea, ate], ant=[tan, nat], abt=[bat]}

패턴 ④ Value 기준 최빈값 찾기

HashMap<String, Integer> map = new HashMap<>();
// ... 데이터 삽입 후

String maxKey = "";
int maxVal = 0;

for (Map.Entry<String, Integer> e : map.entrySet()) {
    if (e.getValue() > maxVal) {
        maxVal = e.getValue();
        maxKey = e.getKey();
    }
}
System.out.println("최빈값: " + maxKey + " (" + maxVal + "번)");

패턴 ⑤ Two Sum (인덱스 역추적)

int[] nums = {2, 7, 11, 15};
int target = 9;
HashMap<Integer, Integer> seen = new HashMap<>(); // <값, 인덱스>

for (int i = 0; i < nums.length; i++) {
    int complement = target - nums[i];
    if (seen.containsKey(complement)) {
        System.out.println("[" + seen.get(complement) + ", " + i + "]"); // [0, 1]
        break;
    }
    seen.put(nums[i], i);
}

정리 요약

클래스	특징	사용 상황
`HashMap`	Key-Value, O(1) 탐색	빈도 계산, 매핑
`HashSet`	중복 없는 집합	방문 체크, 중복 제거
`LinkedHashMap`	삽입 순서 유지	순서가 중요한 매핑
`TreeMap`	Key 자동 정렬	정렬된 맵 필요 시

⚡ 코테 핵심 공식
"탐색 횟수가 많다 → 해시 고려"
"중복 제거 필요하다 → HashSet"
"키로 값 카운팅 → HashMap + getOrDefault"

참고 자료

프로그래머스 - 주식 가격 (JAVA)

jupeternotebook — Fri, 24 Apr 2026 15:41:45 +0900

프로그래머스 주식가격 풀이 과정 덱으로 시작했다가 결국 덱을 버리고 이중 for문으로 해결했다. 그리고 나서 스택으로 더 깔끔하게 풀 수 있다는 걸 알았다. 총 4번의 제출

1~3트 (오답) → 덱 안에서 인덱스 계산하려다 계속 꼬임 4트 (정답) → 덱 버리고 이중 for문으로 전환

처음에 스택/큐 카테고리 문제라는 걸 보고 덱을 써야겠다고 먼저 정해버렸다. 전체 가격을 덱에 넣은 뒤, 앞에서 하나씩 꺼내면서 나머지 원소와 비교하는 방식으로 접근했는데, 문제는 덱 안에서의 순서 인덱스(j)와 원래 배열의 절대 인덱스(i)가 기준이 달라서 j - i로 거리를 계산할 수가 없었다.

1트에서 하락 순간을 time에 반영하지 못했고, 2트에서 time == 0만 틀어막다 실패했고, 3트에서 else { time = j - i; break; } 를 넣었지만 인덱스 기준이 달라서 또 오답.

3트에서 인덱스가 계속 꼬이는 게 덱 구조 때문이라는 걸 깨닫고, 덱을 완전히 버렸다.

4트 (정답)

→ prices 배열을 인덱스로 직접 순회하는 이중 for문으로 바꿨다. → 현재 인덱스 i에서 시작해 j를 한 칸씩 앞으로 밀면서 비교한다. → prices[i] <= prices[j]이면 가격 유지, time++. → 하락하는 순간 time = j - i로 실제 거리를 계산하고 break. → 끝까지 하락이 없으면 time이 자연스럽게 남은 칸 수만큼 쌓인다.

import java.util.*;
class Solution {
    public int[] solution(int[] prices) {
        List<Integer> list = new ArrayList<>();

        for(int i=0; i<prices.length; i++) {
            int time = 0;

            // 현재 인덱스 i, 다음 인덱스 j
            for(int j=i+1; j<prices.length; j++) {
                // 뒤에 올 값이 현재보다 클 경우 -> 최소한 현재값 이상 유지 -> 엔비디아
                if(prices[i] <= prices[j]) time++;

                // 작을 경우 -> 현재값보다 하락 -> 오일쇼크
                else {
                    time = j - i; // 유지한 시간
                    break;
                }
            }
            list.add(time);
        }

        int[] answer = new int[list.size()];
        for(int i=0; i<list.size(); i++) {
            answer[i] = list.get(i);
        }

        return answer;
    }
}

위 풀이의 결과

j - i가 이제 같은 배열 기준의 인덱스 차이이므로 정확히 유지 시간이 계산된다.
덱이 오히려 인덱스 추적을 방해하고 있었다. 처음부터 배열로 풀었으면 됐을 문제였다.
시간 복잡도는 O(n²)이라 prices 길이가 최대 10만인 걸 감안하면 찜찜하긴 하다.

그런데 참고 블로그에서 이중 for문 풀이를 보니까 같은 방식인데 훨씬 간결하게 짰다. 이게 더 간결하네..

→ List 없이 ans[] 배열에 바로 결과를 저장한다. → if (prices[i] > prices[j]) break; 한 줄로 하락 처리 끝. → ans[i]++를 루프 안에서 먼저 올리고, 하락이면 그냥 break하면 되니까 별도 계산이 필요 없다.

class Solution {
    public int[] solution(int[] prices) {
        int[] ans = new int[prices.length];

        for (int i = 0; i < prices.length; i++) {
            for (int j = i + 1; j < prices.length; j++) {
                ans[i]++;
                if (prices[i] > prices[j])
                    break;
            }
        }

        return ans;
    }
}

내 풀이는 time 변수 따로 만들고, List 따로 만들고, 마지막에 배열로 변환까지 했는데 이건 그냥 ans[i]++ 하나로 끝냈다. 로직은 똑같은데 군더더기가 없다.

더 나은 풀이 — 스택 활용

정답을 내고 나서 시간복잡도 O(n²) 이 마음에 걸려서 더 나은 방법이 없을까 찾아봤다. 이중반복문 코드를 참고한 참고 블로그를 또 보니 이 문제가 사실 스택으로 O(n)에 풀 수 있는 문제였다.

핵심 아이디어는 이렇다.

→ 스택에 가격이 아니라 인덱스를 저장한다. → 새로운 가격이 들어올 때, 스택 top의 인덱스가 가리키는 가격보다 낮으면 하락한 것이므로 pop하면서 i - stack.peek()으로 유지 시간을 바로 계산한다. → 반복문이 끝난 뒤에도 스택에 남아있는 인덱스들은 끝까지 가격이 떨어지지 않은 것이므로 prices.length - index - 1을 넣어준다.

import java.util.*;
class Solution {
    public int[] solution(int[] prices) {
        int[] ans = new int[prices.length];
        Stack<Integer> stack = new Stack<>();

        for(int i=0; i<prices.length; i++) {
            // 현재 가격이 스택 top 인덱스의 가격보다 낮으면 → 하락 발생
            while(!stack.isEmpty() && prices[i] < prices[stack.peek()]) {
                ans[stack.peek()] = i - stack.peek(); // 유지한 시간 계산
                stack.pop();
            }
            stack.push(i);
        }

        // 스택에 남은 인덱스 = 끝까지 가격이 떨어지지 않은 주식
        while(!stack.isEmpty()) {
            ans[stack.peek()] = prices.length - stack.peek() - 1;
            stack.pop();
        }

        return ans;
    }
}

위 풀이의 결과

시간 복잡도가 O(n)으로 줄어든다. 각 인덱스는 스택에 한 번 들어가고 한 번 나오기 때문이다.
이중 for문 풀이에서 내가 j - i로 계산하던 거리를 스택이 알아서 들고 있다가 하락 시점에 계산해주는 구조다.
카테고리가 스택/큐인 이유가 있었다. 그냥 순서대로 세는 문제가 아니라 하락 시점을 기다리는 구조가 스택과 딱 맞는 문제였다.

자료구조를 먼저 정해두고 시작하는 습관이 오히려 발목을 잡았다. 덱으로 풀겠다고 먼저 정해버리니까 인덱스 관리가 계속 꼬였고, 덱을 버리고 나서야 풀렸다. 그리고 이중 for문으로 정답을 냈을 때 끝낼 게 아니라, 왜 스택/큐 카테고리인지 를 한 번 더 생각해봤어야 했다. 앞으로 카테고리 힌트를 그냥 흘려보내지 말자.

프로그래머스 - 다리를 지나는 트럭 (JAVA)

jupeternotebook — Fri, 24 Apr 2026 15:19:09 +0900

프로그래머스 다리를 지나는 트럭 풀이 과정
과거의 나 자신과 현재의 나, 둘 다 정답을 냈다.
신기하게도 접근법이 완전히 달랐다.
총 2번의 제출

1트 (정답) → 매초 트럭 위치를 직접 갱신하는 시간 기반 시뮬레이션
2트 (정답, 과거의 나) → 빈 슬롯을 0으로 채우는 포화 상태 기반 시뮬레이션

1트 (정답)

→ 매초 다리 위 트럭의 위치를 직접 갱신하는 방식으로 접근했다.
→ 큐에 [무게, 현재 위치]를 함께 저장하면, 위치가 bridge_length를 넘었을 때 자연스럽게 제거할 수 있겠다고 생각했다.
→ 큐가 완전히 비면 모든 트럭이 다리를 건넌 것이니 그걸 종료 조건으로 삼았다.

import java.util.*;

class Solution {
    public int solution(int bridge_length, int weight, int[] truck_weights) {
        Deque<int[]> bridge = new LinkedList<>(); // 다리

        int curWeight = 0;
        int idx = 0;
        int time = 0;

        while(true) {
            time++;
            // 트럭별 다리 위치 갱신
            if(!bridge.isEmpty()) {
                int size = bridge.size();
                for(int i=0; i<size; i++) {
                    int[] cur = bridge.poll();

                    // 다리 다 건넜을 경우
                    if(cur[1] + 1 > bridge_length) {
                        curWeight -= cur[0];
                        continue;
                    }

                    bridge.offer(new int[] {cur[0], ++cur[1]});
                }
            }

            // 다리 무게 검사 후 진행
            if(idx < truck_weights.length && curWeight + truck_weights[idx] <= weight) {
                bridge.offer(new int[] {truck_weights[idx], 1});
                curWeight += truck_weights[idx++];
            }

            if(bridge.isEmpty()) break;
        }

        return time;
    }
}

위 풀이의 결과

정답은 맞지만, 매초 큐 전체를 순회해서 위치를 갱신하는 게 조금 무겁다.
그래도 트럭이 어디 있는지 눈에 보이는 구조라 디버깅하기 편했다.
[무게, 위치] 쌍을 직접 관리하다 보니 코드가 다소 길어졌다.

2트 (정답, 과거의 나)

→ 다리를 고정된 크기의 큐로 모델링했다. 트럭이 없는 빈 자리엔 0을 밀어 넣었다.
→ 큐의 size가 bridge_length에 꽉 차면, 맨 앞 트럭을 무조건 꺼내는 방식이다.
→ 반복문은 마지막 트럭이 큐에 들어가는 순간 탈출한다.
→ 그 시점에 마지막 트럭은 다리 첫 번째 칸에 막 올라선 상태이므로, answer += bridge_length로 나머지 시간을 보정해줬다.

import java.util.*;

class Solution {
    public int solution(int bridge_length, int weight, int[] truck_weights) {
        Deque<Integer> dq = new LinkedList<>();
        dq.offer(truck_weights[0]);
        int cur_weight = truck_weights[0];
        int answer = 1;
        int idx = 1;

        // 현재 인덱스가 트럭배열 길이보다 작을 경우 반복
        while(idx < truck_weights.length) {
            int size = dq.size();

            // 다리 포화상태 x
            if(size < bridge_length) {
                if(cur_weight + truck_weights[idx] <= weight) {
                    dq.offer(truck_weights[idx]);
                    cur_weight += truck_weights[idx++];
                }
                else dq.offer(0);

                answer++;
            }

            // 다리 포화상태 o, 트럭 하나 무조건 나와야함
            else cur_weight -= dq.poll();
        }

        // 마지막 트럭이 다리 첫번째 위치에 있는 상태로 반복문 탈출
        // 다리 위 차가 다 건너려면, 마지막 차량이 빠져나와야 함
        // 즉, 소요시간 = 반복문 탈출 시간 + 마지막 차량 다리 건너는 시간(다리 길이)
        answer += bridge_length;

        return answer;
    }
}

위 풀이의 결과

코드가 훨씬 짧고 깔끔하다. 과거의 내가 더 잘 짠 것 같아서 조금 억울하다.
포화 상태 분기(else)에서 answer++가 없다는 점에 주의해야 한다.
저 else는 시간이 흐르는 게 아니라 앞 트럭을 빼는 전처리 단계이기 때문이다.
반복문 탈출 후 +bridge_length 보정을 빼먹으면 바로 오답이 된다. 과거의 나는 이걸 어떻게 알았을까.

같은 문제를 두 번 풀었는데 접근법이 완전히 달랐다. 1트는 위치를 직접 추적하는 방식이라 코드가 길지만 흐름이 직관적이고, 2트(과거의 나)는 빈 슬롯을 0으로 채워 넣는 방식으로 훨씬 간결하다.
다만 2트 방식은 반복문 탈출 시점과 +bridge_length 보정 두 가지를 정확히 이해하고 짜야 한다. 이 두 가지 중 하나라도 놓치면 경계 조건에서 1~2 차이로 오답이 난다.
앞으로 시뮬레이션 문제에서 "굳이 위치를 추적할 필요가 있나, 슬롯 개념으로 추상화할 수 있지 않나" 를 먼저 생각해보는 습관을 들여야겠다.

프로그래머스 - 프로세스 (JAVA)

jupeternotebook — Fri, 24 Apr 2026 02:24:42 +0900

프로그래머스 프로세스 풀이 과정
3시간을 헤매다 결국 과거에 통과했던 나의 코드를 참고해서 겨우 통과했다.
점수 흐름: 60 → 45 → 40 → 60 → 100
총 5번의 제출

1트 (오답)

이 문제를 처음 봤을 때 떠올린 건 우선순위 큐였다. 우선순위가 높은 것부터 처리한다는 문장만 보고, Comparable을 구현한 Process 클래스를 만들어 우선순위 내림차순으로 정렬해서 꺼내면 되겠다고 판단했다. PriorityQueue에서 꺼내는 순서가 곧 실행 순서라고 본 것이다.

import java.util.*;

class Process implements Comparable<Process> {
    int priority;
    int idx;

    public Process(int priority, int idx) {
        this.priority = priority;
        this.idx = idx;
    }

    public int compareTo(Process p) {
        if(this.priority == p.priority) return this.idx - p.idx;
        else return p.priority - this.priority;
    }
}
class Solution {
    public int solution(int[] priorities, int location) {
        PriorityQueue<Process> pq = new PriorityQueue<>();

        for(int i=0; i<priorities.length; i++) {
            pq.offer(new Process(priorities[i], i));
        }

        int answer = 1;
        while(!pq.isEmpty()) {
            Process cur = pq.poll();

            if(cur.idx == location) break;
            else answer++;
        }

        return answer;
    }
}

60점. 절반 정도는 맞았다. 하지만 이 접근은 문제의 핵심을 놓친 것이었다.

이 문제는 단순히 높은 우선순위부터 전역적으로 꺼내는 구조가 아니다. 동작 방식을 다시 읽으면, 큐의 맨 앞 프로세스를 꺼낸 뒤 현재 큐에 자신보다 우선순위가 높은 것이 있으면 다시 뒤로 보낸다. 없을 때만 실행된다. 즉 원래 순서(큐의 앞뒤 관계)를 유지하면서, 맨 앞 원소가 기준이 되어 조건부로 실행 여부를 판단하는 시뮬레이션이다. PriorityQueue는 전체를 우선순위 기준으로 정렬해서 꺼내는 자료구조라, 이 흐름을 재현할 수 없다.

중간 3번의 북벌

우선순위 큐로는 안 된다는 걸 느끼고 일반 덱으로 방향을 틀었다. 매 라운드마다 덱 전체를 순회해 최대 우선순위를 파악하고, 해당 원소를 꺼내는 구조를 짰다. 4트까지 이 방향으로 이것저것 고쳐봤는데, 계속 엣지 케이스에서 틀렸다. 60점 벽을 넘지 못했다.

나중에 돌아보니 이유가 명확했다. 덱에서 전체 최대값을 찾아 바로 꺼내면, 큐 순서가 사라진다. 예를 들어 [1, 1, 9, 1, 1]에서 location = 0이라면, 맨 앞의 1은 9보다 우선순위가 낮아 뒤로 밀려야 하고, 9가 실행된 뒤 남은 1들이 원래 순서대로 실행되어야 한다. 그런데 내 코드는 그냥 9를 전체에서 꺼내버리니, 그 이후의 순서 보장이 깨졌다. "전체 최대를 찾는다"와 "맨 앞 원소가 기준이다"를 계속 혼동하고 있었던 것이다.

5트 (정답)

3시간을 넘기고 나서 싱싱했던 반년 전 나의 정답 코드를 참고했다. 보는 순간 바로 이해가 됐다.

import java.util.*;

class Process {
    int index;
    int priority;

    public Process(int index, int priority) {
        this.index = index;
        this.priority = priority;
    }
}

class Solution {
    public int solution(int[] priorities, int location) {
        Queue<Process> q = new LinkedList<>();

        for(int i=0; i<priorities.length; i++) {
            q.offer(new Process(i, priorities[i]));
        }

        int answer = 1;
        while(true) {
            int max = 0;
            for(int i=0; i<q.size(); i++) {
                Process tmp = q.poll();
                max = Math.max(max, tmp.priority);
                q.offer(tmp);
            }

            while(true) {
                Process tmp = q.peek();
                if(tmp.priority == max) break;
                else q.offer(q.poll());
            }
            Process cur = q.poll();
            if(cur.index == location) break;
            else answer++;
        }

        return answer;
    }
}

구조는 두 단계다. 먼저 현재 큐 전체를 순회해 최대 우선순위 max를 구한다. 그 다음 큐의 맨 앞부터 확인하며, max와 우선순위가 같은 원소가 나올 때까지 뒤로 보낸다. 맨 앞에 온 순간 꺼내서 실행한다.

내가 계속 놓쳤던 건 이 두 번째 단계였다. 최대값을 찾은 뒤 바로 꺼내는 게 아니라, 큐 순서를 보존하면서 해당 원소가 맨 앞에 올 때까지 기다렸다가 꺼낸다. 이렇게 해야 "대기 중인 프로세스 중 우선순위가 높은 것이 있으면 먼저 처리"한다는 조건이 순서까지 포함해서 정확히 재현된다.

나의 사투가 보이는가... 3시간 동안 헤맨 이유를 한 마디로 정리하면, "맨 앞 원소가 기준"이라는 걸 끝까지 이해하지 못했다. 문제 설명을 읽고 우선순위가 높은 것부터 처리한다는 부분만 보고 우선순위 큐로 먼저 달려들었고, 방향을 바꾼 뒤에도 "전체에서 최대를 찾아 꺼낸다"는 사고에서 벗어나지 못했다. 큐 자료구조의 핵심은 순서인데, 그 순서를 시뮬레이션의 도구로 써야 한다는 감각이 부족했다. 과거의 코드를 참고했다는 게 조금 부끄럽지만, 덕분에 내가 어디서 막혔는지는 명확하게 정리됐다.

프로그래머스 - 올바른 괄호 (JAVA)

jupeternotebook — Fri, 24 Apr 2026 02:01:24 +0900

프로그래머스 올바른 괄호 풀이 과정
어렵지 않게 한 번에 통과했다.
총 1번의 제출

1트 (정답)

→ 문자열을 순회하며 (는 스택에 push, )는 스택에서 pop한다.
→ )를 만났을 때 스택이 비어 있으면 짝이 맞지 않으므로 즉시 false를 반환한다.
→ 순회가 끝난 뒤 스택이 비어 있으면 모든 괄호가 올바르게 닫힌 것이다.

import java.util.*;

class Solution {
    boolean solution(String s) {
        Stack<Character> stack = new Stack<>();

        for(char c : s.toCharArray()) {
            if(c=='(') stack.push(c);
            else {
                if(stack.isEmpty()) return false;
                stack.pop();
            }
        }

        return stack.isEmpty() ? true : false;
    }
}

왜 스택인가

괄호 문제를 보는 순간 스택이 떠오른 건 자연스러운 흐름이었다. (는 "나중에 닫혀야 할 괄호"이고, )는 "가장 최근에 열린 괄호를 닫는다"는 구조가 후입선출(LIFO) 과 정확히 맞아떨어지기 때문이다.

)를 만났을 때의 처리가 핵심이다. 이 시점에 스택이 비어 있다는 건 짝이 없는 닫는 괄호라는 의미이므로 바로 false를 반환한다. 비어 있지 않다면 가장 최근에 push된 (와 짝이 맞는 것이므로 pop한다.

순회가 끝난 뒤에는 스택이 비어 있어야 한다. 스택에 (가 남아 있다는 건 닫히지 않은 괄호가 있다는 의미이기 때문이다.

정리하면 false가 되는 케이스는 딱 두 가지다.

)를 만났는데 스택이 비어 있는 경우 → 짝 없는 닫는 괄호
순회가 끝났는데 스택에 원소가 남아 있는 경우 → 닫히지 않은 여는 괄호

이 두 케이스만 막으면 나머지는 자연스럽게 true가 된다.

괄호 문제는 스택의 LIFO 특성과 구조가 딱 맞아 떨어지는 대표적인 유형이라, 이 문제를 풀면서 "스택을 써야겠다"는 판단은 거의 즉각적으로 나왔다. 앞으로 괄호, 중첩 구조, 뒤에서 검증해야 하는 패턴이 보이면 스택을 가장 먼저 떠올리는 습관을 유지해야겠다.

프로그래머스 - 기능개발 (JAVA)

jupeternotebook — Fri, 24 Apr 2026 01:36:04 +0900

프로그래머스 기능개발 풀이 과정
큐 두 개를 굴리다가 인덱스 동기화 실수로 1차에 틀렸다.
2차에서 큐 하나로 정리하며 통과

1트 (오답)

→ progresses와 speeds를 각각 별도의 Deque에 담는다.
→ 매 라운드마다 전체 순회하며 속도를 더한 뒤, 앞에서부터 100 이상인 항목을 꺼내 카운트한다.

import java.util.*;
class Solution {
    public int[] solution(int[] progresses, int[] speeds) {
        Deque<Integer> pg = new LinkedList<>();
        Deque<Integer> sp = new LinkedList<>();

        for(int i=0; i<speeds.length; i++) {
            pg.offer(progresses[i]);
            sp.offer(speeds[i]);
        }

        List<Integer> list = new ArrayList<>();
        while(!pg.isEmpty()) {
            int size = pg.size();
            int cnt = 0;

            for(int i=0; i<size; i++) {
                int curProg = pg.poll();
                int curSpd = sp.poll();

                pg.offer(curProg+curSpd);
                sp.offer(curSpd);
            }

            for(int i=0; i<size; i++) {
                int cur = pg.peek();

                if(cur >= 100) {
                    pg.poll();
                    cnt++;
                }
                else break;
            }
            if(cnt > 0) list.add(cnt);
        }

        int[] answer = new int[list.size()];
        for(int i=0; i<list.size(); i++) {
            answer[i] = list.get(i);
        }

        return answer;
    }
}

위 풀이의 결과

발상 자체는 맞다. 큐를 라운드 단위로 순회하며 진도를 갱신하고, 앞에서부터 완료된 기능을 꺼내 묶는다는 흐름은 올바르다.
문제는 속도 큐(sp)를 함께 굴리는 과정에서 인덱스 동기화가 어긋난다는 점이다. 진도와 속도를 각각 분리된 덱에 넣고 poll → offer를 반복하면, 라운드가 거듭될수록 pg와 sp의 원소 순서가 뒤섞인다.
- 진도 업데이트 루프에서 pg.poll()과 sp.poll()을 같이 꺼내 더한 뒤 다시 offer한다.
- 이때 완료 판정 루프에서 pg.poll()로 꺼낸 원소에 대응하는 속도가 sp에서도 동시에 빠져야 하는데, 그냥 놔두니 두 덱 사이에 원소 수 불일치가 생긴다.

2트 (정답)

→ 속도 덱을 없앴다.
→ 앞 작업이 100을 넘어야만 뒤 작업도 덱에서 빠져나올 수 있으므로, 덱에서 빠져나간 수만큼 speeds 앞부분을 건너뛰면 현재 덱에 남아 있는 작업의 속도를 정확히 참조할 수 있다.

import java.util.*;
class Solution {
    public int[] solution(int[] progresses, int[] speeds) {
        // 우선 순서대로 큐에 작업진도 삽입
        Deque<Integer> dq = new LinkedList<>();
        for(int pro : progresses) {
            dq.offer(pro);
        }

        // 작업진도 최신화
        List<Integer> list = new ArrayList<>();
        while(!dq.isEmpty()) {
            int size = dq.size();

            for(int i=0; i<size; i++) {
                dq.offer(dq.poll() + speeds[speeds.length - size + i]); // 기존작업의 개수 - 현재 큐 사이즈 + i = 해당 작업의 속도
            }

            // 앞에서부터 검사하며, 100이 넘으면 카운트, 안 넘는 즉시 반복 탈출
            int cnt = 0;
            for(int i=0; i<size; i++) {
                if(dq.peek() >= 100) {
                    dq.poll();
                    cnt++;
                }
                else break;
            }

            // 카운트가 0보다 클 경우 리스트 추가
            if(cnt>0) list.add(cnt);
        }

        int[] answer = new int[list.size()];
        for(int i=0; i<list.size(); i++) {
            answer[i] = list.get(i);
        }

        return answer;
    }
}

위 풀이의 핵심: `speeds[speeds.length - size + i]`

이 문제의 배포 조건은 앞 작업이 100을 넘어야만 뒤 작업도 함께 배포된다는 것이다. 즉 덱에서 빠져나오는 순서는 반드시 앞에서부터이고, 중간이나 뒤에서 먼저 빠져나오는 일은 없다.

이러한 특성을 반영해서, 현재 덱에 size개의 원소가 남아 있다는 건 speeds 배열의 앞에서부터 speeds.length - size개가 이미 완료돼 빠져나갔다는 의미가 된다. 따라서 지금 덱의 i번째 원소에 해당하는 속도는 speeds[speeds.length - size + i]로 정확히 역산할 수 있다. 속도 덱을 따로 굴릴 필요 없이, 빠져나간 수만큼 원배열의 시작점을 밀면 그만이다.

배포 순서의 특성(앞이 완료돼야 뒤도 빠져나옴) 파악 → 덱 이탈 순서가 보장됨을 확인
빠져나간 수 = speeds.length - size 로 시작 인덱스 역산

1트에서 두 덱을 함께 굴리다 꼬인 건, 완료 판정 시점에 속도 덱을 동기화하지 않아서였다. 하지만 진짜 핵심은 그 앞에 있었다. 이 문제는 앞 작업이 100을 넘어야만 뒤 작업도 빠져나올 수 있다는 조건 덕분에, 덱의 이탈 순서가 항상 보장된다. 그걸 파악하고 나면 속도 덱 자체가 필요 없어진다는 게 자연스럽게 따라온다. 문제의 조건을 자료구조 설계에 연결해서 생각하는 연습이 더 필요하다고 느꼈다.

프로그래머스 - 같은 숫자는 싫어 (JAVA)

jupeternotebook — Thu, 23 Apr 2026 02:26:26 +0900

프로그래머스 같은 숫자는 싫어 풀이 과정
스택으로 먼저 풀고, 덱으로 리팩토링하다가 한 번 더 틀렸다.
마지막엔 스택/덱 없이 인덱스 비교만으로 가장 간결하게 정리했다.
총 4번의 제출

1트 (정답, 스택 활용)

→ 스택의 peek()으로 직전 값을 확인하고, 현재 값과 같으면 건너뛴다.
→ 스택과 별도로 List에도 같이 담아서 최종 배열을 구성했다.

import java.util.*;
public class Solution {
    public int[] solution(int []arr) {
        Stack<Integer> stack = new Stack<>();
        List<Integer> list = new ArrayList<>();
        stack.push(arr[0]);
        list.add(arr[0]);

        for(int i=1; i<arr.length; i++) {
            if(stack.peek()==arr[i]) continue;
            else {
                stack.push(arr[i]);
                list.add(arr[i]);
            }
        }
        int[] answer = new int[list.size()];
        for(int i=0; i<list.size(); i++) {
            answer[i] = list.get(i);
        }

        return answer;
    }
}

위 풀이의 결과

정답은 맞지만, 스택과 리스트를 동시에 관리하는 구조가 불필요하게 중복이다.
Stack만으로도 되는데 굳이 List를 따로 유지한 셈이다.
리팩토링 여지가 있어서 덱으로 다시 시도했다.

2트 (오답, 덱 활용)

→ Stack + List 조합 대신, 덱 하나로 처리하도록 변경했다.
→ peekLast()로 직전 값을 확인하고, 다르면 offer()로 뒤에 추가하는 방식.

import java.util.*;
public class Solution {
    public int[] solution(int []arr) {
        Deque<Integer> dq = new LinkedList<>();

        for(int i : arr) {
            if(dq.isEmpty()) {
                dq.offer(i);
                continue;
            }
            if(dq.peekLast() == i) continue;
            else dq.offer(i);
        }

        int[] answer = new int[dq.size()];
        for(int i=0; i<dq.size(); i++) {
            answer[i] = dq.poll();
        }

        return answer;
    }
}

위 풀이의 결과

dq.size()를 반복문 조건식에 직접 쓰면, dq.poll()로 요소를 꺼낼 때마다 size()가 줄어들어 반복이 절반만 돌고 끝나버린다.
결과적으로 배열 뒷부분이 전부 0으로 채워지는 오답이 발생한다.

3트 (정답, 덱 활용)

→ 반복문 진입 전에 dq.size()를 size 변수에 미리 저장해두고 고정값으로 사용했다.

import java.util.*;
public class Solution {
    public int[] solution(int []arr) {
        Deque<Integer> dq = new LinkedList<>();

        for(int i : arr) {
            if(dq.isEmpty()) {
                dq.offer(i);
                continue;
            }

            if(dq.peekLast() == i) continue;
            else dq.offer(i);
        }

        int[] answer = new int[dq.size()];
        int size = dq.size();
        for(int i=0; i<size; i++) {
            answer[i] = dq.pollFirst();
        }

        return answer;
    }
}

위 풀이의 결과

size를 미리 고정해두니 poll()로 꺼내도 반복 횟수가 줄어들지 않아 정상 동작한다.
덱 하나로 깔끔하게 처리 완

4트 (리팩토링, 스택/덱 없이)

→ 스택도, 덱도 필요 없다는 걸 깨달았다.
→ arr[i] != arr[i-1] 인덱스 비교만으로 직전 값을 확인할 수 있으니, 그냥 List에 바로 담으면 된다.

import java.util.*;
public class Solution {
    public int[] solution(int[] arr) {
        List<Integer> list = new ArrayList<>();
        list.add(arr[0]);
        for(int i=1; i<arr.length; i++) {
            if(arr[i] != arr[i-1]) list.add(arr[i]);
        }

        int[] answer = new int[list.size()];
        for(int i=0; i<list.size(); i++) answer[i] = list.get(i);
        return answer;
    }
}

위 풀이의 결과

스택/덱의 peek() 없이도 배열 인덱스로 직전 값 비교가 가능하다는 걸 활용했다.
자료구조 오버헤드가 사라지고 코드가 훨씬 간결해졌다.
isEmpty() 체크도 필요 없고, size 저장 실수도 생길 여지가 없다.

리팩토링하다가 오히려 한 번 더 틀렸다. dq.size()를 반복 조건에 그대로 쓰면 루프 도중에 값이 바뀐다는 게 맹점이었다. 앞으로 컬렉션을 순회하면서 동시에 꺼내는 경우엔 size를 미리 저장하는 습관을 들여야겠다.
그리고 이번 문제처럼 "직전 값과 비교"가 목적이라면 굳이 자료구조를 쓸 필요 없이 인덱스로 해결할 수 있다는 것도 기억해두자.

프로그래머스 - 베스트 앨범 (JAVA)

jupeternotebook — Thu, 23 Apr 2026 02:23:15 +0900

프로그래머스 베스트 앨범 풀이 과정
해시 카테고리 문제인데, 정렬 기준이 여러 개라 꽤 헤맸다.
총 3번의 제출 끝에 통과

1트 (오답)

→ 장르별 총 스트리밍 횟수를 genMap에 저장하고, TreeMap의 Key 기준 역순 정렬로 장르 순서를 정하려 했다.
→ 각 곡의 인덱스는 playIdx에 plays[i] → i 형태로 저장했다.

import java.util.*;
// 음악 클래스
class Music implements Comparable<Music> {
    String genre;
    int play;

    public Music(String genre, int play) {
        this.genre = genre;
        this.play = play;
    }

    @Override
    public int compareTo(Music m) {
        return m.play - this.play;
    }
}
class Solution {
    public int[] solution(String[] genres, int[] plays) {
        Map<String, Integer> genMap = new HashMap<>(); // 장르별 스트리밍 횟수 저장
        Map<Integer, Integer> playIdx = new HashMap<>(); // 스트리밍 횟수 인덱스 저장
        List<Music> playlist = new ArrayList<>(); // 곡별 스트리밍 횟수 저장

        for(int i=0; i<plays.length; i++) {
            genMap.put(genres[i], genMap.getOrDefault(genres[i],0) + plays[i]);
            playIdx.put(plays[i], i);
            playlist.add(new Music(genres[i], plays[i]));
        }

        // 새로 알게 된 개념 -> Key 기준으로 정렬
        Map<String, Integer> genSort = new TreeMap<>(Collections.reverseOrder());
        genSort.putAll(genMap);

        // 리스트에 장르별 베스트 2개 담기
        List<Integer> list = new ArrayList<>();

        for(Map.Entry<String, Integer> gen : genSort.entrySet()) {
            List<Music> tmp = new ArrayList<>();

            for(Music m : playlist) {
                if(gen.getKey().equals(m.genre)) tmp.add(m);
            }

            Collections.sort(tmp);

            if(tmp.size() == 1) {
                list.add(playIdx.get(tmp.get(0).play));
            }
            else {
                list.add(playIdx.get(tmp.get(0).play));
                list.add(playIdx.get(tmp.get(1).play));
            }
        }

        int[] answer = new int[list.size()];
        for(int i=0; i<list.size(); i++) answer[i] = list.get(i);

        return answer;
    }
}

위 풀이의 결과

TreeMap의 역순 정렬은 Key(장르 이름) 알파벳 기준으로 정렬하는 것이라, 총 스트리밍 횟수 기준 정렬과 전혀 관계없다. 장르 순서가 완전히 잘못됐다.
playIdx에 plays[i] → i를 저장하는 방식은 같은 스트리밍 횟수를 가진 곡이 있으면 덮어씌워진다. 인덱스를 제대로 추적할 수 없는 구조다.
히스토리 기준으로 20점 구간에 해당하는 풀이다.

2트 (오답)

→ playIdx의 덮어쓰기 문제를 인식하고, Music 객체에 인덱스(idx)를 직접 포함시켜 playIdx Map을 완전히 제거했다.
→ 덕분에 같은 스트리밍 횟수의 곡이 있어도 인덱스를 잃지 않게 됐다.
→ 그러나 장르 정렬 방식은 그대로 TreeMap(Collections.reverseOrder())를 유지했다. 이 부분이 여전히 문제임을 아직 파악하지 못한 상태였다.

import java.util.*;
// 음악 클래스
class Music implements Comparable<Music> {
    String genre;
    int play;
    int idx; // idx 필드 추가

    public Music(String genre, int play, int idx) {
        this.genre = genre;
        this.play = play;
        this.idx = idx;
    }

    @Override
    public int compareTo(Music m) {
        return m.play - this.play;
    }
}
class Solution {
    public int[] solution(String[] genres, int[] plays) {
        Map<String, Integer> genMap = new HashMap<>(); // 장르별 스트리밍 횟수 저장
        List<Music> playlist = new ArrayList<>(); // 곡별 스트리밍 횟수 저장

        for(int i=0; i<plays.length; i++) {
            genMap.put(genres[i], genMap.getOrDefault(genres[i],0) + plays[i]);
            playlist.add(new Music(genres[i], plays[i], i)); // playIdx 제거, idx를 객체에 직접 포함
        }

        // Key 기준 역순 정렬 (문제 있음 - 아직 미수정)
        Map<String, Integer> genSort = new TreeMap<>(Collections.reverseOrder());
        genSort.putAll(genMap);

        // 리스트에 장르별 베스트 2개 담기
        List<Integer> list = new ArrayList<>();

        for(Map.Entry<String, Integer> gen : genSort.entrySet()) {
            List<Music> tmp = new ArrayList<>();

            for(Music m : playlist) {
                if(gen.getKey().equals(m.genre)) tmp.add(m);
            }

            Collections.sort(tmp);

            if(tmp.size() == 1) {
                list.add(tmp.get(0).idx); // playIdx 대신 객체의 idx 직접 참조
            }
            else {
                list.add(tmp.get(0).idx);
                list.add(tmp.get(1).idx);
            }
        }

        int[] answer = new int[list.size()];
        for(int i=0; i<list.size(); i++) answer[i] = list.get(i);

        return answer;
    }
}

위 풀이의 결과

playIdx 덮어쓰기 문제는 해결됐다. Music 객체에 idx를 포함시킨 덕분에 인덱스 추적은 이제 정확하다.
하지만 TreeMap(Collections.reverseOrder())는 Key인 장르 이름의 알파벳 역순으로 정렬한다. genMap의 Value(총 스트리밍 횟수)와는 아무 관계가 없어서 장르 순서가 여전히 틀렸다.
히스토리 기준 13.3점 구간.

3트 (정답)

→ TreeMap Key 정렬 문제를 마침내 파악했다. 장르 정렬을 Value(총 스트리밍 횟수) 기준으로 바꿨다.
→ keySet을 꺼내 Comparator로 커스텀 정렬하는 방식으로 수정했다.

import java.util.*;
// 음악 클래스
class Music implements Comparable<Music> {
    String genre;
    int play;
    int idx;

    public Music(String genre, int play, int idx) {
        this.genre = genre;
        this.play = play;
        this.idx = idx;
    }

    @Override
    public int compareTo(Music m) {
        return m.play - this.play;
    }
}
class Solution {
    public int[] solution(String[] genres, int[] plays) {
        Map<String, Integer> genMap = new HashMap<>(); // 장르별 스트리밍 횟수 저장
        List<Music> playlist = new ArrayList<>(); // 곡별 스트리밍 횟수 저장

        for(int i=0; i<plays.length; i++) {
            genMap.put(genres[i], genMap.getOrDefault(genres[i],0) + plays[i]);
            playlist.add(new Music(genres[i], plays[i], i));
        }

        // Value 기준으로 정렬
        List<String> keySet = new ArrayList<>(genMap.keySet());
        keySet.sort(new Comparator<String>() {
            @Override
            public int compare(String o1, String o2) {
                return genMap.get(o2) - genMap.get(o1);
            }
        });

        // 리스트에 장르별 베스트 2개 담기
        List<Integer> list = new ArrayList<>();

        for(String gen : keySet) {
            List<Music> tmp = new ArrayList<>();

            for(Music m : playlist) {
                if(gen.equals(m.genre)) tmp.add(m);
            }

            Collections.sort(tmp);

            if(tmp.size() == 1) {
                list.add(tmp.get(0).idx);
            }
            else {
                list.add(tmp.get(0).idx);
                list.add(tmp.get(1).idx);
            }
        }

        int[] answer = new int[list.size()];
        for(int i=0; i<list.size(); i++) answer[i] = list.get(i);

        return answer;
    }
}

위 풀이의 결과

genMap.keySet()을 꺼내 Comparator로 Value 기준 내림차순 정렬 → 장르 순서가 정확히 잡혔다.
Music 객체에 idx를 포함시켜 같은 재생 횟수여도 인덱스를 잃지 않는다.
정확성 테스트 통과

3번의 시도를 돌아보면, 1트에서 2트로 넘어갈 때는 playIdx 덮어쓰기 문제를 잡았고, 2트에서 3트로 넘어갈 때는 TreeMap(reverseOrder())이 Key 알파벳 정렬임을 뒤늦게 깨달았다. 두 문제를 한 번에 잡지 못하고 한 번씩 나눠서 틀린 셈이다.
핵심은 "정렬 기준이 Value일 때는 keySet을 꺼내 Comparator로 직접 정렬" 하는 것, 그리고 "객체에 인덱스를 처음부터 포함시키는 것" 이다. 다음엔 더 빠르게 보이길 바라며.

프로그래머스 - 전화번호 목록 (JAVA)

jupeternotebook — Thu, 23 Apr 2026 02:20:41 +0900

프로그래머스 전화번호 목록 풀이 과정
약 1년 전에도 한 번 풀었던 문제다. 그때도 꽤 헤맸는데... 다시 풀어보니 또 헤맸다.
총 9번의 제출... 여전히 부족하다

1트 (오답)

→ 배열 요소 중 가장 짧은 길이를 기준으로, 슬라이딩 윈도우처럼 모든 부분 문자열을 Map에 저장한다.
→ 동일한 부분 문자열이 2개 이상 등장하면, 접두어 관계가 존재한다고 간주한다.

import java.util.*;

class Solution {
    public boolean solution(String[] phone_book) {
        // 배열 요소 최소 길이 구하기
        int min_len = Integer.MAX_VALUE;
        for(String num : phone_book) min_len = Math.min(min_len, num.length());

        // 최소 길이로 나올 수 있는 모든 경우 맵에 저장
        Map<String, Integer> map = new HashMap<>();
        for(String num : phone_book) {
            for(int i=0; i<=num.length()-min_len; i++) {
                String str = num.substring(i, i+min_len);
                map.put(str, map.getOrDefault(str,0)+1);
            }
        }

        // 1보다 큰 경우 접두어가 있는걸로 간주
        for(Map.Entry<String, Integer> entry : map.entrySet()) {
            if(entry.getValue() > 1) return false;
        }

        return true;
    }
}

위 풀이의 결과

접두어 관계는 반드시 앞에서부터 시작해야 하는데, 중간 인덱스(i)부터 시작하는 부분 문자열까지 전부 비교하고 있어 잘못된 접근이다.
예를 들어 "123"과 "312"가 있다면, 슬라이딩으로 "23", "31", "12" 등이 겹쳐 접두어가 없는데도 false를 리턴하는 오탐이 발생한다.
히스토리 기준으로 0점, 66.7점 구간에 해당하는 풀이다.

2트 (오답)

→ 슬라이딩이 문제였으니, 시작 인덱스를 0으로 고정한다.
→ 각 번호의 앞 min_len 글자만 잘라서 Map에 저장하면, 최소 길이 번호가 다른 번호의 접두어인 경우를 잡을 수 있지 않을까?

import java.util.*;

class Solution {
    public boolean solution(String[] phone_book) {
        // 배열 요소 최소 길이 구하기
        int min_len = Integer.MAX_VALUE;
        for(String num : phone_book) min_len = Math.min(min_len, num.length());

        // 최소 길이로 나올 수 있는 모든 경우 맵에 저장
        Map<String, Integer> map = new HashMap<>();
        for(String num : phone_book) {
            String str = num.substring(0, min_len);
            map.put(str, map.getOrDefault(str,0)+1);
        }

        // 1보다 큰 경우 접두어가 있는걸로 간주
        for(Map.Entry<String, Integer> entry : map.entrySet()) {
            if(entry.getValue() > 1) return false;
        }

        return true;
    }
}

위 풀이의 결과

최소 길이 번호가 접두어인 케이스는 어느 정도 잡히지만, 여전히 길이가 다른 번호들 사이의 접두어 관계를 전부 처리하지 못한다.
예를 들어 "12"와 "123"은 잡히지만, 접두어 관계 없이 앞 두 글자가 우연히 같은 번호들끼리 오탐이 생긴다.
히스토리 기준으로 54.2점, 79.2점, 91.7점 구간을 오가던 풀이의 원인이다.

3트 (정답)

→ 발상을 바꾸자. 모든 번호를 Map에 넣어두고, 각 번호의 모든 접두어(prefix) 를 직접 잘라서 Map에 존재하는지 확인하자.
→ 어떤 번호의 접두어가 Map에 존재한다면, 그게 곧 다른 번호와의 접두어 관계를 의미한다.
(솔직히 이 방향은 AI의 도움을 받아서 풀었던 나의 과거 풀이를 참고했다...)

import java.util.*;

class Solution {
    public boolean solution(String[] phone_book) {
        Map<String, Integer> map = new HashMap<>();
        for(String num : phone_book) {
            map.put(num, map.getOrDefault(num,0)+1);
        }

        for(String num : phone_book) {
            for(int j=0; j<num.length(); j++) {
                if(map.containsKey(num.substring(0,j))) {
                    return false;
                }
            }
        }

        return true;
    }
}

위 풀이의 결과

정확성과 효율성 테스트 드뎌 통과
히스토리상 2025-06-12, 2026-04-21 두 번 모두 이 방향으로 결국 통과했다.
다만 Map<String, Integer>을 쓰고 있는데, 이 풀이에서 Value(Integer)는 전혀 활용되지 않는다.
Key의 존재 여부만 확인하면 되므로, Map보다 Set이 더 적합한 자료구조다.

4트 (리팩토링)

→ Map 대신 Set을 사용해 불필요한 Value 관리를 제거하자.
→ 코드가 더 간결해지고, 의도도 명확해진다.

import java.util.*;

class Solution {
    public boolean solution(String[] phone_book) {
        Set<String> set = new HashSet<>();
        for(String num : phone_book) {
            set.add(num);
        }

        for(String num : phone_book) {
            for(int j=0; j<num.length(); j++) {
                if(set.contains(num.substring(0,j))) {
                    return false;
                }
            }
        }

        return true;
    }
}

위 풀이의 결과

Map → Set으로 교체하면서 코드가 훨씬 간결해졌다.
contains() 하나로 접두어 존재 여부를 O(1)에 확인할 수 있어 가독성과 효율 모두 개선됐다.
최종 제출 겨우 통과~

1년 전에 한 번 풀었던 문제인데도 다시 같은 구간에서 헤맸다. 그때의 나도, 지금의 나도 슬라이딩 윈도우 방향으로 먼저 손이 갔다는 게 신기하면서도 조금 부끄럽다. 핵심은 "모든 접두어를 직접 잘라서 Set에서 탐색한다" 는 단순한 발상이었는데, 앞으로는 이 패턴을 더 빠르게 떠올릴 수 있도록 많이 풀어봐야겠다.

JUPETER의 Notebook

Git & GitHub

1. Git과 GitHub의 차이

2. 왜 중요한가?

3. 기존 물리적인 백업 및 공유 방식

4. 버전 관리 시스템 (VCS)

5. 중앙 집중식 버전 관리 시스템 (CVCS)

6. 분산 버전 관리 시스템 (DVCS)

7. Git 동작 방식

8. 자주 사용하는 Git 명령어

마치며

참고자료 및 이미지 출처

Java의 메모리 관리

1. 메모리 관리란?

2. C언어 메모리 관리

3. Java 메모리 관리

4. 스택(Stack)

5. 힙(Heap)

6. GC(Garbage Collector)

7. 전체 흐름 요약

마치며

컴퓨터 언어 정리

1. 컴퓨터 언어란?

2. 이진법 (Binary)

3. 기계어 (Machine Language)

4. 고급 언어 (High-Level Language)

5. 한 줄 정리

마치며

Java 기초 정리

1. 자바의 탄생 배경

2. 자바의 특징

3. JVM (Java Virtual Machine)

4. JRE (Java Runtime Environment)

5. JDK (Java Development Kit)

6. 전체 구조 정리

마치며

프로그래머스 - H Index (Java)

1트 (오답)

1트 수정 (정답)

answer = cnt가 맞는 이유

2트 (힌트를 받아 정답)

list.get(i) >= i+1 이 조건이 왜 맞는가

1트 / 1트 수정 / 2트 비교

프로그래머스 - K번째 수 (JAVA)

1트 (정답)

Arrays.copyOfRange() 란

위 풀이의 결과

과거 코드와 비교

프로그래머스 - 가장 큰 수 (JAVA)

1트 (정답, 남의 코드 참고)

핵심 로직 이해 — (s2+s1).compareTo(s1+s2)

위 풀이의 결과

프로그래머스 - 디스크 컨트롤러 (JAVA)

1트 (오답)

위 풀이의 결과

2트 (정답)

위 풀이의 결과

[자료구조] Stack, Queue, Deque, PriorityQueue — Java

1. 스택(Stack)

2. 큐(Queue)

3. 덱(Deque)

4. 우선순위 큐(PriorityQueue)

5. 자료구조 비교 요약

6. 코딩테스트 자주 쓰는 패턴 모음

[자료구조] Hash(해시) — Java

1. 해시란 무엇인가?

2. 해시 충돌(Collision)과 해결 방법

3. HashMap — 키-값 쌍 저장소

4. HashSet — 중복 없는 집합

5. HashMap vs HashSet 비교

6. 순회(Iteration)

7. 정렬(Sorting)

8. 코딩테스트 자주 쓰는 패턴 모음

프로그래머스 - 주식 가격 (JAVA)

4트 (정답)

위 풀이의 결과

더 나은 풀이 — 스택 활용

위 풀이의 결과

프로그래머스 - 다리를 지나는 트럭 (JAVA)

1트 (정답)

`answer = cnt`가 맞는 이유

`list.get(i) >= i+1` 이 조건이 왜 맞는가

`Arrays.copyOfRange()` 란

핵심 로직 이해 — `(s2+s1).compareTo(s1+s2)`

위 풀이의 핵심: `speeds[speeds.length - size + i]`