미니베리

[Java] 코딩 자율학습 나도코딩의 자바 입문 리뷰

miniberry — Tue, 26 May 2026 15:06:02 +0900

코딩 자율학습 나도코딩의 자바 입문 리뷰

입문자가 따라가기 좋은 자바 학습서

본 리뷰는 출판사로부터 도서를 제공받아 작성한 후기이다.

1. 책을 읽게 된 이유

자바는 백엔드 개발을 준비하는 사람이라면 꼭 한 번은 제대로 공부해야 하는 언어라고 생각한다.
최근 Spring Boot를 공부하거나 객체지향 개념을 이해하려면 자바 문법에 대한 기본기에 대한 보충이 필요했다.

이에 길벗 출판사의 코딩 자율학습 나도코딩의 자바 입문이라는 책을 읽었다.

이번에 읽은 『코딩 자율학습 나도코딩의 자바 입문』은 자바를 처음 배우는 사람도 부담 없이 따라갈 수 있도록 구성된 입문서이다.

평소 나도코딩 강의처럼 친절하고 실습 중심의 설명을 기대하며 읽어보게 되었다.

2. 책의 구성과 특징

이 책은 자바의 기본 문법부터 객체지향 프로그래밍까지 단계적으로 학습할 수 있도록 구성되어 있다.

초반부에서는 변수, 자료형, 조건문, 반복문처럼 프로그래밍의 기초가 되는 내용을 다룬다.
이후 배열, 메서드, 클래스, 상속, 인터페이스 등 자바에서 중요한 개념으로 자연스럽게 확장된다.

가장 좋았던 점은 단순히 개념을 설명하는 데서 끝나지 않고, 직접 코드를 작성하면서 이해할 수 있도록 예제가 많이 제공된다는 점이다.
입문자는 문법 설명만 읽으면 쉽게 지루해질 수 있는데, 이 책은 실습 흐름이 잘 잡혀 있어 따라가기 편하다.

3. 좋았던 점

첫째, 설명이 어렵지 않다.
자바를 처음 배우는 사람도 이해할 수 있도록 용어를 풀어서 설명하고, 코드 예제도 복잡하지 않게 제시한다.

둘째, 실습 중심이라 학습 흐름이 좋다.
개념을 읽고 바로 코드를 작성해볼 수 있어 “이 문법이 실제로 어떻게 쓰이는지” 확인하기 좋다.

셋째, 객체지향 개념을 입문자 눈높이에 맞게 다룬다.
자바에서 클래스, 객체, 상속, 인터페이스는 중요한 개념이지만 처음에는 어렵게 느껴질 수 있다.
이 책은 예제를 통해 개념을 하나씩 연결해 설명하기 때문에 부담이 적다.

필자는 유튜브 강의를 통해 해당 도서의 저자를 접해본 적이 있었다.

또한, 네이버 카페를 통해 코딩자율학습단과 질문게시판 등을 운영하고 있어서 학습에 다양한 편의가 제공된다.

https://www.youtube.com/watch?v=NQq0dOoEPUM

4. 아쉬웠던 점

완전 입문자를 대상으로 한 책이다 보니, 이미 자바 문법을 어느 정도 알고 있는 사람에게는 앞부분이 다소 쉽게 느껴질 수 있다.
또한 심화 문법이나 실무적인 Spring Boot 연계 내용까지 기대한다면 범위가 조금 제한적으로 느껴질 수 있다.

하지만 이 책의 목적이 “자바 입문”이라는 점을 생각하면, 처음 배우는 독자에게는 적절한 난이도라고 판단된다.

해당 도서를 읽은 목적이 Java 복습이었기 때문에 충분히 만족스러웠다.

5. 추천 대상

이 책은 다음과 같은 사람에게 추천하고 싶다.

자바를 처음 공부하는 사람
프로그래밍 입문서를 찾는 사람
Spring Boot 공부 전에 자바 기본기를 다지고 싶은 사람
문법 설명보다 실습을 통해 배우는 방식을 선호하는 사람
나도코딩 스타일의 친절한 설명을 좋아하는 사람

6. 전체 후기

『코딩 자율학습 나도코딩의 자바 입문』은 자바를 처음 시작하는 사람이 기초 문법과 객체지향 개념을 차근차근 익히기에 좋은 책이다.
설명이 친절하고 예제가 많아 혼자 공부하기에도 부담이 적다.

특히 자바를 단순히 암기하는 것이 아니라, 직접 코드를 작성하면서 익히고 싶은 사람에게 잘 맞는 입문서라고 느껴졌다.
백엔드 개발을 준비하는 입장에서 자바 기본기를 다시 정리하는 데에도 도움이 되었다.

자바를 처음 시작하는 사람이라면 이 책을 통해 기본 문법부터 객체지향 개념까지 자연스럽게 익혀볼 수 있을 것이다.

한줄평

자바를 처음 배우는 사람도 부담 없이 따라갈 수 있는 친절한 실습형 입문서이다.

[Codex] 하네스 엔지니어링으로 풀스택 개발 시작하기

miniberry — Fri, 24 Apr 2026 13:05:37 +0900

0. 배경

최근에 React + Spring 기반 풀스택 프로젝트(ChaekList)를 시작하면서 “Codex를 활용한 하네스 엔지니어링 방식으로 개발”을 적용해봤다.

하네스 엔지니어링이란?

https://miniberry-coding.tistory.com/31

계획부터 구현까지 Codex를 통해서 작업이 가능하다

결론부터 말하면,

AI를 팀원처럼 만들어 “명확한 제한과 방향성을 명시하는 과정”이었다.

1. Codex 처음 사용하면서 느낀 점

처음에는 이렇게 생각했다.

“Chat GPT보다 코드 조금 더 잘 짜주는 모델인가?”

실제로 써보니까 완전히 달랐다.

프로젝트 전체 구조를 읽음
실행 방법을 분석
작업을 계획

처음 실행했을 때 나온 결과:

frontend / backend 구조 분석
실행 명령 자동 정리

“Codex는 실제로 프로젝트를 이해하고 상황에 맞는 코드를 제시한다”

2. 첫 기능: Health Check API 구현

Codex가 추천한 첫 작업은 GET /api/health 엔드포인트 만들기

frontend + backend 연결 확인 가능
복잡한 도메인 없이 구조 검증 가능
개발 환경 정상 여부 체크 가능

결과:

/api/health → {"status":"ok"}
실제 서버 실행 후 정상 응답 확인

여기까지는 매우 순조로웠다.

3. 예상 못한 문제: 테스트 깨짐

문제는 여기서 발생했다.

GradleWorkerMain ClassNotFoundException

그냥 넘어갈 수도 있었지만, 하네스 관점에서는 중요했다.

코드 → 테스트 → 검증

이 루프가 깨지면 드의 신뢰도가 떨어지기 때문

4. 문제 해결 과정

Codex에게 문제 해결을 맡겼다.

원인: Windows 사용자 경로의 비ASCII 문자 문제
해결: GRADLE_USER_HOME을 프로젝트 내부 경로로 변경

수정된 부분:

gradlew.bat
gradlew

결과:

BUILD SUCCESSFUL

이 순간이 중요했다.

“나는 지시한 뒤, 확인하고 승인만 하면 된다”

5. 프론트엔드 연결까지 완료

Next.js에서 /api/health 호출

http://localhost:3000/api/health → 정상 응답
rewrite 설정 통해 backend 연결

6. 리뷰에서 발견된 문제

Codex 리뷰 결과는 localhost 하드코딩 문제

http://localhost:8080

배포하면 깨짐
포트 바뀌면 깨짐
환경별 설정 불가능

“AI는 코드만 만드는 게 아니라, 리스크도 찾아준다”

7. 하네스 엔지니어링의 핵심: AGENTS.md

여기서 가장 중요한 작업을 했다.

AGENTS.md 중 일부

AGENTS.md 작성

Codex 행동 규칙 정의
작업 범위 제한
검증 방식 지정
언어 설정 (한국어)

핵심 내용:

frontend / backend 분리
테스트 필수
PR 기반 작업
하드코딩 금지

효과:

AI가 이상한 방향으로 안 감
매번 같은 설명 안 해도 됨
작업 품질 상승

8. Codex 사용 방식 변화

처음에는

codex "Read AGENTS.md first. Act as a backend specialist..."

지금은

codex "AGENTS.md를 먼저 읽고 backend 개발자 역할로 동작해..."

터미널에서 Codex를 사용했기 때문에 영어로 명령하는 것이 편하지만, AGENTS.md에 한글로 명시가 가능하고 CLI에서도 한글로 명령하는것이 가능했다.

생산성을 위해 한글로 전환하였다.

9. 가장 큰 깨달음

이번 경험에서 가장 크게 느낀 점:

에이전트는 도구가 아니다
하네스 엔지니어링을 통해 “환경을 어떻게 설계하느냐에 따라 성능이 결정된다”

10. 앞으로 방향

이제 다음 목표는:

CI/CD 자동화
Codex PR 리뷰 자동화
배포까지 연결

완전한 AI 기반 개발 파이프라인 구축

마무리

이번 경험을 통해 느낀 건 하나다.

“이제 개발자는 코드를 짜는 사람이 아니라
시스템을 설계하는 사람이 되어야 한다”

앞으로는 단순한 코딩보다
하네스 엔지니어링 능력이 더 중요해질 것 같다.

[에이전틱 엔지니어링] 하네스 엔지니어링(Harness Engineering) 이란?

miniberry — Tue, 14 Apr 2026 00:58:12 +0900

1. 하네스 엔지니어링이란 무엇인가

최근 LLM 기반 서비스가 발전하면서, 단순히 모델을 잘 사용하는 것만으로는 실제 제품을 만들 수 없다는 한계가 드러나기 시작했다.

이 과정에서 등장한 개념이 바로 하네스 엔지니어링(Harness Engineering)이다.

하네스 엔지니어링은 다음과 같이 정의할 수 있다.

LLM을 중심으로, 모델을 제외한 나머지 모든 실행·제어·검증·관리 시스템을 설계하는 엔지니어링

조금 더 직관적으로 말하면,

프롬프트 엔지니어링을 넘어, LLM에게 방향성을 제시하는 엔지니어링 기법

이다.

2. 왜 하네스 엔지니어링이 등장했는가

(1) LLM은 완전한 시스템이 아니다

LLM은 다음과 같은 한계를 가진다.

상태를 기억하지 못한다 (stateless)
외부 시스템과 직접 상호작용하지 못한다
실행 흐름을 제어할 수 없다
결과의 신뢰성을 보장하지 못한다

즉, LLM은 CPU에 가까운 존재이지, 완성된 프로그램이 아니다.

(2) Prompt Engineering의 한계

초기에는 “프롬프트를 잘 짜면 된다”는 접근이 주류였다.

하지만 실제 서비스에서는 다음 문제가 발생한다.

동일 입력에도 출력이 달라짐 (비결정성)
복잡한 작업 흐름 처리 불가
외부 데이터/툴 연동 어려움
실패 원인 분석 불가능

결국 프롬프트만으로는 제품 수준의 시스템을 만들 수 없다는 결론에 도달하게 된다.

(3) Agent 시스템의 등장

Agent 구조가 도입되면서 상황은 더 복잡해졌다.

User → Planner → Tool → Memory → LLM → Action

이 구조에서는 단순 응답 생성이 아니라

계획(Planning)
행동(Action)
재계획(Re-planning)
상태 유지(State)

까지 필요해진다.

이때 이를 통제하는 시스템이 필요해지고, 그 역할을 하는 것이 바로 Harness다.

3. 하네스 엔지니어링의 핵심 개념

하네스는 단순한 “테스트 도구”가 아니다.

최신 관점에서는 다음과 같이 이해해야 한다.

Harness = Execution + Control + Memory + Tools + Evaluation + Governance

즉, 모델을 둘러싼 전체 운영 환경이다.

4. 하네스의 주요 구성 요소

4.1 Execution & Orchestration

에이전트의 전체 흐름을 실행하고 제어한다.

Plan → Act → Observe → Re-plan

단일 요청이 아니라 멀티 스텝 프로세스를 관리하는 것이 핵심이다.

4.2 Tool / Environment Interface

LLM이 외부 세계와 상호작용할 수 있도록 한다.

API 호출
데이터베이스 접근
파일 시스템
웹 브라우징

LLM은 혼자 아무것도 할 수 없고, 실제 “행동”은 이 레이어에서 발생한다.

4.3 Memory & State Management

LLM은 상태를 유지하지 못하기 때문에, 이를 보완하는 구조다.

대화 기록
사용자 상태
작업 진행 상황
중간 결과

특히 멀티턴 에이전트에서는 필수 요소다.

4.4 Context Management

LLM에 어떤 정보를 입력할지 결정한다.

어떤 데이터를 포함할지
어떤 부분을 요약할지
어떤 순서로 넣을지

이 영역은 기존의 Context Engineering / Prompt Engineering과 연결된다.

4.5 Control & Constraints (핵심)

하네스에서 가장 중요한 요소 중 하나다.

에이전트의 행동을 제한하고 통제한다.

예:

특정 API 호출 제한
위험 행동 차단
human approval 요구
정책 기반 제어

즉, 하네스는 단순 실행기가 아니라
**“브레이크가 달린 시스템”**이다.

4.6 Verification & Evaluation

결과의 품질을 검증한다.

규칙 기반 검증 (keyword, format)
모델 기반 평가 (LLM-as-judge)
혼합 방식

이 부분이 흔히 말하는 “evaluation harness”이며, 전체 하네스의 일부에 해당한다.

4.7 Lifecycle Management

작업의 전체 생명주기를 관리한다.

시작 / 종료
실패 처리
retry
long-running task 관리

특히 실제 서비스 환경에서 매우 중요하다.

4.8 Persistence

상태를 저장하고 복구할 수 있게 한다.

세션 저장
작업 상태 저장
재실행 가능 구조

4.9 Observability

시스템을 관찰 가능하게 만든다.

로그
실행 trace
디버깅 정보

이게 없으면 Agent 시스템은 사실상 운영이 불가능하다.

4.10 Feedback Loop

실패를 기반으로 시스템을 개선한다.

중요한 점은,

프롬프트를 수정하는 것이 아니라 시스템을 개선한다

는 것이다.

5. 하네스 엔지니어링의 구조

정리하면 다음과 같은 구조가 된다.

  하네스 구조
LLM 위에서 동작하는 것이 아니라, 실제로는 Harness가 LLM을 감싸며 실행 환경을 구성한다.
  LLM
Core Engine
↑
  Harness (Execution System)
⚙️ Execution (흐름 제어)
  Tools (외부 연결)
  Memory (상태 관리)
  Context (입력 구성)
  Control (제약 / 안전)
✅ Verification (검증)
  Lifecycle (작업 관리)
  Persistence (저장)
  Observability (로그)
  Feedback (개선)
  이해를 위한 비유
LLM = CPU
Harness = 운영체제(OS)
즉, Harness가 없으면 LLM은 실제 시스템으로 안정적으로 동작할 수 없다.

6. 핵심 패러다임 변화

과거

LLM 활용 = Prompt Engineering

현재

LLM 활용 = Harness Engineering

이 변화의 본질은 다음과 같다.

“성능은 모델이 아니라 시스템 설계에서 결정된다”

7. 중요한 인사이트

하네스 엔지니어링을 이해할 때 가장 중요한 관점은 이것이다.

Agent = Model + Harness

Model → 추론 능력
Harness → 실행 능력

즉, 실제 서비스 품질은 Harness의 설계 수준에 의해 결정된다.

8. 결론

하네스 엔지니어링은 단순한 도구나 프레임워크가 아니라, LLM 기반 시스템을 제품으로 만들기 위한 핵심 아키텍처 설계 방법론이다.

앞으로의 AI 개발은 다음과 같이 바뀐다.

모델을 잘 쓰는 개발자 → 한계
시스템을 설계하는 개발자 → 경쟁력

9. 한 줄 요약

하네스 엔지니어링은 LLM을 “실험”이 아닌 “제품”으로 만드는 기술이다

10. 마치며

오늘은 최근 굉장히 인기있는 키워드인 하네스 엔지니어링에 대해서 정리해보았다.

국내외에서 프롬프트 엔지니어링에 대한 다양한 자료가 쏟아지고 있는 상황에 가장 많이 등장하는 키워드 중에 하나인 하네스 엔지니어링에는 LLM의 현재 위치와 우리의 역할을 살펴볼 수 있는 개념이다.

[백준] 1781번 - 컵라면

miniberry — Sat, 11 Apr 2026 23:31:12 +0900

1. 문제 요약

https://www.acmicpc.net/problem/1781

각 문제마다

데드라인 (d)
컵라면 수 (c)

가 주어진다.

모든 문제는 1시간씩 걸리고,
각 문제는 데드라인 이전에만 풀 수 있다.

→ 목표:
얻을 수 있는 컵라면의 최대 개수

2. 처음 접근 (틀린 코드)

처음에는 이런 식으로 접근했다.

heapq.heappush(heap, (dead_line, -cup))

데드라인 기준으로 정렬하면서
같은 데드라인이면 컵라면 많은 것 우선 선택

그리고 하나 선택한 뒤

while heap and curr >= heap[0][0]:
	heapq.heappop(heap)

즉,

하나 고르면
같은 데드라인 이하 문제는 다 버리는 방식

3. 왜 틀렸는가?

핵심 문제

같은 데드라인에서도 여러 개 선택할 수 있다

반례

데드라인이 2 → 문제 2개까지 가능

정답은 10 + 9 = 19인 반면, 내 코드는 10을 출력한다.

→ 이유:

10 하나 고르고
나머지 (9, 8) 전부 삭제

4. 핵심 개념 깨달음

이 문제의 해결 전략:

데드라인 d까지는 최대 d개 문제를 풀 수 있다

즉, 데드라인최대 선택 가능 개수

1	1개
2	2개
3	3개

5. 올바른 접근

핵심 아이디어

문제를 데드라인 오름차순 정렬
현재까지 선택한 문제들을 heap에 저장
만약 선택한 문제 개수 > 현재 데드라인: 가장 컵라면 적은 문제 제거

6. 정답 코드

import heapq
import sys
input = sys.stdin.readline

n = int(input())
problems = []

for _ in range(n):
    d, c = map(int, input().split())
    problems.append((d, c))

problems.sort()

heap = []

for d, c in problems:
    heapq.heappush(heap, c)
    
    if len(heap) > d:
        heapq.heappop(heap)

print(sum(heap))

[백준] 1655번 - 가운데를 말해요

miniberry — Thu, 9 Apr 2026 11:22:07 +0900

1. 문제 요약

https://www.acmicpc.net/problem/1655

정수를 하나씩 입력받을 때마다
지금까지 들어온 값들의 중간값을 출력하는 문제

홀수 개 → 정확한 중앙값
짝수 개 → 중앙 두 값 중 작은 값

2. 처음 접근 (실패)

이렇게 생각했다.

힙 두 개 쓰면 되지 않을까?

min_heap (최소 힙)
max_heap (최대 힙처럼 사용, 음수 저장)

두 개를 만들고 입력값을 각각 넣어서 길이를 맞추려고 했다.

if len(min_heap) > (i+1)//2:
	heapq.heapreplace(min_heap, x)
else:
	heapq.heappush(min_heap, x)

max_heap도 처리하고, 중간값은 출력

if i % 2 == 0:
	print(min(min_heap))
else:
	print(-max(max_heap))

2. 문제점

1) 두 힙이 “분할 구조”가 아님

이 방식은

같은 값이 두 힙에 동시에 들어가고
어떤 값은 교체되면서 사라짐

즉,

“작은 값 / 큰 값”으로 나뉜 구조가 아님

2) heapreplace를 잘못 사용

heapreplace는 “루트와 비교해서 교체”할 때 의미가 있는데, 나는 단순히 길이 기준으로 교체했다.

→ 결과: 값의 정렬 정보가 깨짐

3) 힙의 루트를 안 쓰고 전체 탐색

min(min_heap)
max(max_heap)

힙의 장점을 완전히 무시한 코드였다.

힙은 루트만 보장
전체 정렬 아님

→ 무조건 heap[0] 써야 함

4. 핵심 깨달음

이 문제의 핵심은 단순히 힙 2개가 아니라

두 힙이 “값의 범위 기준으로 나뉘어야 한다”

올바른 구조

두 힙의 역할은 이렇게 나뉜다.

max_heap → 작은 값들 (중간값 포함)
min_heap → 큰 값들

그리고 항상 다음 조건 유지:

max_heap의 모든 값 ≤ min_heap의 모든 값

그리고 크기 조건:

len(max_heap) == len(min_heap) 또는
len(max_heap) == len(min_heap) + 1

5. 중요했던 포인트: swap

가장 헷갈렸던 부분

왜 하나만 옮기지 않고, 두 개를 교환하지?

1) 의문

max_heap → min_heap으로 하나만 보내면 안 되나?

2) 안 되는 경우

문제되는 상황:

max_heap: [큰 값이 들어가 있음]
min_heap: [작은 값이 들어가 있음]

즉,

→ 경계가 꼬인 상태

한쪽만 이동하면

순서가 여전히 깨지거나
크기 균형이 깨짐

3) swap 하여 해결

max_value = -heapq.heappop(max_heap)
min_value = heapq.heappop(min_heap)

heapq.heappush(max_heap, -min_value)
heapq.heappush(min_heap, max_value)

효과:

잘못된 값 위치를 서로 교환
순서 + 크기 동시에 복구

4) 직관

두 힙은 다음과 같이 나뉘어야 한다

[작은 값들 -> max_heap
[큰 값들] -> min_heap

잘못되면 [작은 값 + 큰 값] | [작은 값 + 큰 값]과 같이 섞인다

해결 방법:

잘못 들어간 두 값을 서로 교환

6. 최종 코드

import heapq
import sys
input = sys.stdin.readline

min_heap = []
max_heap = []
n = int(input())

for _ in range(n):
    x = int(input())
    if len(max_heap) == len(min_heap):
        heapq.heappush(max_heap, -x)
    else:
        heapq.heappush(min_heap, x)

    if min_heap and -min_heap[0] > max_heap[0]:
        max_value = -heapq.heappop(max_heap)
        min_value = heapq.heappop(min_heap)

        heapq.heappush(max_heap, -min_value)
        heapq.heappush(min_heap, max_value)

    print(-max_heap[0])

7. 시간 복잡도

삽입: O(log N)
총: O(N log N)

→ N = 100,000까지 안정적으로 통과

[백준] 1202번 - 보석 도둑

miniberry — Wed, 8 Apr 2026 17:06:13 +0900

1. 문제 요약

https://www.acmicpc.net/problem/1202

보석 N개 (무게 M, 가격 V)
가방 K개 (각 가방은 하나의 보석만 담을 수 있음)
가방마다 최대 무게 제한 존재

→ 목표: 담을 수 있는 보석 가격 합의 최대값

2. 처음 접근 (실패)

처음에는 이렇게 생각했다.

“가장 비싼 보석부터 넣으면 되지 않을까?”

그래서 구현:

heapq.heappush(jewels, (-v, m)) # 가치 기준 최대힙

그리고:

if bags[0] >= m:
	heapq.heappop(bags)

문제점

이 방식은 보석 중심 사고였다.

가치 높은 보석부터 꺼냄
가장 작은 가방 하나만 보고 넣을지 결정

문제:

뒤에 있는 더 큰 가방에 들어갈 수 있는 보석도 그냥 버려짐

핵심 반례

내 코드 결과:

100 → 가방 2 못 들어감 → 버림
99 → 가방 2에 넣음

결과: 99

정답:

99 → 가방 2
100 → 가방 10

결과: 199

3. 두 번째 접근 (또 실패)

이번엔 반대로 생각했다.

“작은 보석부터 넣으면 되지 않을까?”

heapq.heappush(jewels, (m, -v)) # 무게 기준

문제점

이번에는 작은 보석을 너무 빨리 사용해버림

반례

내 코드:

(1,1) → 가방 2 사용
(2,100) → 가방 3 사용

결과: 101

정답:

(2,100) → 가방 2
(3,99) → 가방 3

결과: 199

4. 깨달음

이 문제는 보석을 고르는 문제가 아니라,

각 가방에 어떤 보석을 넣을지를 결정하는 문제

잘못된 접근

보석 → 가방 찾기

올바른 접근

가방 → 넣을 보석 선택

5. 최종 해결 전략

핵심 아이디어

가방을 작은 순서대로 처리
현재 가방에 들어갈 수 있는 보석들을 모음
그중 가장 가치가 큰 보석 선택

6. 구현 코드

import heapq
import sys
input = sys.stdin.readline

n, k = map(int, input().split())
jewels = list(sorted(tuple(map(int, input().split())) for _ in range(n)))
bags = list(sorted(int(input()) for _ in range(k)))
candidate = []
cost = 0
index = 0

for bag in bags:
    while index < n and jewels[index][0] <= bag:
        heapq.heappush(candidate, -jewels[index][1])
        index += 1
    
    if candidate:
        cost -= heapq.heappop(candidate)

print(cost)

7. 시간복잡도

정렬: O(N log N + K log K)
힙 연산: O((N+K) log N)

총: O((N+K) log N)

[백준] 1715번 - 카드 정렬하기

miniberry — Tue, 7 Apr 2026 15:33:32 +0900

1. 문제를 처음 봤을 때

처음에는 단순히
“카드를 합치면 비용이 든다 → 그냥 순서대로 더하면 되지 않나?”
라고 생각했다.

하지만 예시를 보면

(10 + 20) + (30 + 40) = 100
(10 + 40) + (50 + 20) = 120

합치는 순서에 따라 비용이 달라진다

여기서 핵심은

“어떤 순서로 합쳐야 최소가 되는가?”

2. 처음 접근 (잘못된 방식)

처음에는 이런 식으로 구현했다.

answer += answer + heapq.heappop(heap)

즉,

이전 결과(answer)를 계속 재활용하면서 더하는 방식

하지만 이건 문제의 구조를 잘못 이해한 것이다.

왜 틀렸는가?

answer는 “총 비용”이지
“카드 묶음”이 아니다

나는 answer를 카드 묶음처럼 사용해버림

3. 핵심 깨달음

이 문제에서 중요한 건 딱 하나였다.

“합친 카드 묶음도 다시 하나의 묶음으로 취급해야 한다”

즉,

두 묶음을 합친다
그 결과를 다시 후보에 넣는다
다시 가장 작은 두 개를 선택한다

이 흐름이 반복되어야 한다.

4. 올바른 접근: 최소 힙 (Priority Queue)

그래서 필요한 게 바로 최소 힙이다.

이유는 간단하다.

매번 “가장 작은 두 묶음”을 빠르게 꺼내야 하기 때문

5. 최종 코드

import heapq
import sys
input = sys.stdin.readline

n = int(input())
heap = []
answer = 0

for _ in range(n):
    heapq.heappush(heap, int(input()))

while len(heap) > 1:
    card_sum = heapq.heappop(heap) + heapq.heappop(heap)
    answer += card_sum
    heapq.heappush(heap, card_sum)

print(answer)

6. 왜 최적인가?

이 문제는 사실 구조적으로

“항상 작은 것부터 합치는 것이 전체 비용을 최소화한다”

는 성질을 가진다.

직관적으로 보면

큰 값끼리 먼저 합치면 → 이후 계속 큰 비용이 누적됨
작은 값끼리 먼저 합치면 → 비용 증가를 최소화 가능

이게 바로 그리디 전략이 성립하는 이유다.

7. 시간복잡도

힙 연산: O(log N)
총 반복: N번

→ 전체: O(N log N)

N = 100,000까지 충분히 통과 가능

[백준] 2075번 - N번째 큰 수

miniberry — Mon, 6 Apr 2026 19:16:51 +0900

1. 문제 요약

https://www.acmicpc.net/problem/2075

N × N 크기의 표가 주어지고,
각 열은 위에서 아래로 갈수록 값이 증가하는 특징을 가진다.

→ 목표: 전체 수 중 N번째로 큰 값 찾기

2. 처음 접근 (실패)

처음에는 단순하게 생각했다.

“전체에서 N번째 큰 수니까 다 넣고 뽑으면 되지 않나?”

그래서 아래처럼 구현했다.

import heapq
import sys
input = sys.stdin.readline

heap = []
n = int(input())

for i in range(n):
    row = list(map(int, input().split()))
    for x in row:
        heapq.heappush(heap, -x)

for _ in range(n):
    k = -heapq.heappop(heap)

print(k)

→ 최대 힙처럼 쓰기 위해 -x 사용

3. 결과: 메모리 초과

왜 터졌을까?

핵심 원인:

모든 데이터를 힙에 저장했기 때문

메모리 분석

최대 입력:

N=1500N = 1500
총 데이터 수 = N² = 2,250,000

즉, 힙에 들어가는 데이터:

→ 약 225만 개

파이썬에서 더 치명적인 이유

파이썬 int는 객체라서 메모리를 많이 먹음
리스트 + 힙 구조까지 고려하면

→ 12MB 제한 절대 못 버팀

4. 문제의 핵심 깨달음

중요한 질문:

우리가 진짜 필요한 건 모든 값인가?

→ 답: 아님

N번째 큰 수 하나만 필요

해결 아이디어

“전체를 저장하지 말고, 필요한 것만 유지하자”

전략:

크기가 N인 최소 힙 유지
항상 “큰 값 N개만” 남기기

5. 알고리즘

각 숫자 x에 대해

1. 힙 크기 < N → 그냥 넣기
2. 힙 크기 == N
    → x > heap[0] (현재 N번째 큰 값)
        → heap[0] 제거 후 x 삽입
    → 아니면 버림

개선 코드

import heapq
import sys
input = sys.stdin.readline

n = int(input())
heap = []

for _ in range(n):
    row = map(int, input().split())
    for x in row:
        if len(heap) < n:
            heapq.heappush(heap, x)
        else:
            if x > heap[0]:
                heapq.heapreplace(heap, x)

print(heap[0])

6. 핵심 차이 비교

구분기존 코드개선 코드

힙 크기	N² (최대 225만)	N (최대 1500)
메모리	초과	통과
접근 방식	전체 저장	Top-N 유지

7. 시간 복잡도

전체 데이터: N²
힙 연산: O(logN)

→ 전체: O(N² log N)

(시간은 비슷하지만 메모리가 핵심 차이)

8. 중요한 포인트 정리

1) 힙은 정렬 구조가 아니다

heapq는 최소값만 빠르게 찾기 위한 구조
전체 정렬을 보장하지 않음

2) "전체가 필요하지 않다"는 사고

이 문제의 핵심:

필요한 정보만 유지하는 것

3) Top-K 문제 패턴

이 문제는:

Top-K (K=N) 문제

전체 저장 X
K개만 유지 O

[React] 라이프 사이클 - 단방향 데이터 흐름, 컴포넌트 마운트와 클린업

miniberry — Mon, 6 Apr 2026 18:55:21 +0900

이번에 React 공부하면서 가장 크게 이해가 정리된 부분이 두 가지였다.
하나는 단방향 데이터 흐름, 다른 하나는 컴포넌트의 마운트와 클린업(useEffect)이다.
겉으로 보면 단순한 개념인데, 직접 코드로 부딪혀보니까 생각보다 중요한 포인트들이 많이 숨어 있었다.

1. 단방향 데이터 흐름 – React의 기본 철학

React는 기본적으로 데이터가 위에서 아래로 흐르는 구조를 가진다.
부모 컴포넌트가 state를 가지고 있고, 그걸 자식에게 props로 내려준다.

function Parent() {
	const [count, setCount] = useState(0);

	return <Child count={count} onClick={() => setCount(count + 1)} />;
}

여기서 중요한 점

데이터는 부모 → 자식
이벤트는 자식 → 부모 (콜백 함수 호출)

처음에는 “왜 이렇게 번거롭게 하지?” 싶었는데, 이 구조 덕분에 데이터 흐름이 항상 예측 가능해진다는 걸 느꼈다.
특히 디버깅할 때 “이 값 어디서 바뀌었지?”를 추적하기 쉬워진다.

2. 조건부 렌더링 = 컴포넌트 생명주기

라이프사이클은 다음과 같다

마운트 (Mount, 탄생): 컴포넌트가 페이지에 처음 렌더링될 때
업데이트 (Update, 갱신): State나 Props의 값이 바뀌거나 부모 컴포넌트가 리렌더해 자신도 리렌더될 때
언마운트 (Unmount, 사망): 더 이상 페이지에 컴포넌트가 렌더링되지 않을 때

이번에 가장 크게 깨달은 점

{count % 2 === 0 && <Even />}

이 한 줄이 단순한 조건문이 아니라,

짝수 → 컴포넌트 생성 (마운트)
홀수 → 컴포넌트 제거 (언마운트)

→ 즉, 렌더링 조건 자체가 생명주기를 결정한다

이걸 이해하고 나니까 React가 “컴포넌트 기반 UI”라는 말이 훨씬 와닿았다.

3. useEffect와 클린업 함수의 진짜 의미

처음에는 이 코드가 헷갈렸다.

useEffect(() => {
	return () => {
		console.log("Even 컴포넌트 언마운트");
	};
}, []);

“이게 왜 마운트냐 언마운트냐” 혼란이 왔는데, 핵심은

useEffect 자체는 마운트 시 실행
return 함수는 언마운트 시 실행 (cleanup)

즉,

→ 마운트할 때 “나중에 정리할 함수”를 등록해두는 구조

이걸 이해하고 나니까 흐름이 완전히 정리됐다.

마운트 → effect 실행 → cleanup 등록 
언마운트 → cleanup 실행

4. 클린업 함수는 왜 존재할까

클린업 함수는 단순히 로그 찍는 용도가 아니라,
남아있는 작업을 정리하는 역할이다.

예를 들어:

이벤트 리스너 제거
setInterval 정리
API 요청 취소

이걸 안 하면 실제로 메모리 누수나 버그로 이어진다.

그래서 React는 아예 구조적으로

effect를 만들면 반드시 정리도 같이 생각해라

라는 패턴을 강제하고 있는 느낌이었다.

5. 이번에 느낀 핵심 요소

이번 학습에서 가장 좋았던 건
이 세 개가 따로 노는 개념이 아니라 하나로 연결된다는 것이었다.

단방향 데이터 흐름
조건부 렌더링
useEffect + cleanup

상태(state)가 바뀌면

→ 렌더링 구조 변경
→ 컴포넌트 마운트/언마운트
→ 그에 따라 effect와 cleanup이 실행

6. 한 줄 정리

React는 단순히 UI를 그리는 라이브러리가 아니라,
상태 변화 → 컴포넌트 생명주기 → 부수 효과 관리까지 연결된 구조이다.

[Spring] JWT 로그아웃 기본 코드 분석

miniberry — Fri, 3 Apr 2026 13:24:07 +0900

1. 들어가며

BenePicker 프로젝트를 진행하면서 인증을 JWT 기반으로 설계했다.
로그인, 토큰

발급까지는 비교적 자연스럽게 구현됐지만, 로그아웃 구현에서 예상 밖의 혼란을 겪었다.

"로그아웃인데… 왜 서버에서 아무것도 안 하지?"

로그아웃인데 서버에서 계속 요청해도 정상 응답 처리..

이번 글에서는 단순 구현이 아니라, JWT 로그아웃의 본질과 설계 관점에서의 깨달음을 정리해보려고 한다.

2. 구현한 로그아웃 코드

@PostMapping("/logout")
public ResponseEntity<Void> logout() {
    return ResponseEntity.ok().build();
}

처음 이 코드를 작성하면서 이런 생각이 들었다.

“이게… 로그아웃 맞나?”

로직이 없다.
DB 접근도 없다.
토큰 처리도 없다.

그냥 200 OK 반환 끝이다.

3. 왜 이렇게 구현했을까?

이걸 이해하려면 먼저 JWT의 핵심 개념을 알아야 한다.

1) JWT의 본질: Stateless

JWT 인증은 Stateless(무상태) 구조다.

즉,

서버는 로그인 상태를 저장하지 않는다.

2) 우리가 익숙한 방식 (세션)

로그인 → 서버에 세션 저장
로그아웃 → 서버에서 세션 삭제

서버가 상태를 관리한다

3) JWT 방식

로그인 → 토큰 발급
이후 요청 → 토큰만 검증

서버는 상태를 저장하지 않는다

4) 핵심 깨달음

그래서 결론은

JWT에서 로그아웃 = 서버 작업이 아니다

로그아웃 = 클라이언트에서 토큰 삭제

4. 실제 로그아웃 흐름

JWT 기반 로그아웃은 이렇게 동작한다.

클라이언트 → /logout 요청
서버 → 200 OK 응답
클라이언트 → 토큰 삭제
이후 요청 → 인증 실패 (401)

즉, 서버는 그냥 “응답만 해주는 역할”

5. 진짜 로그아웃은 어디서 일어날까?

정답: 클라이언트

LocalStorage / AsyncStorage에서 토큰 삭제
사용자 상태 초기화
로그인 페이지로 이동

이걸 안 하면?

→ 로그아웃 API를 호출해도 계속 로그인 상태처럼 보인다

6. 설계 관점에서의 인사이트

이번 경험에서 가장 크게 느낀 점

"JWT는 서버를 단순하게 만드는 대신, 클라이언트 책임을 증가시킨다"

7. 현재 구조의 한계

지금 구현은 간단하고 효율적이지만,
실제 서비스에서는 문제가 될 수 있다.

문제점

탈취된 토큰은 만료 전까지 계속 사용 가능
서버에서 강제 로그아웃 불가능

8. 실무에서는 어떻게 해결할까?

실제 서비스에서는 보통 아래 방식들을 추가로 사용한다.

1) Refresh Token 관리

서버(DB)에 저장
로그아웃 시 삭제

2) Redis 블랙리스트

로그아웃된 AccessToken → Redis에 저장

→ 이후 요청 차단

3) 토큰 만료 시간 전략

AccessToken: 짧게
RefreshToken: 길게

9. 회고

이번 로그아웃 구현은 단순한 기능 하나를 넘어서, 인증 구조 자체를 다시 이해하게 되는 계기였다.

처음에는

"왜 동작을 안하지?"

라고 생각했지만, 지금은 오히려 이렇게 느낀다.

"JWT는 설계를 이해하지 않으면 절대 제대로 쓸 수 없다"

한 줄 정리

JWT에서 로그아웃은 서버가 아니라 클라이언트가 수행한다

다음 목표

Refresh Token 기반 인증 구조 개선
Redis 블랙리스트 도입
로그아웃 시 토큰 무효화 처리