과거의 자바가 “어떻게(How) 루프를 돌릴까”에 집중했다면, 현대 자바는 “무엇(What)을 하고 싶은가”에 집중합니다.
과거의 자바가 “어떻게(How) 루프를 돌릴까”에 집중했다면, 현대 자바는 “무엇(What)을 하고 싶은가”에 집중합니다.
명령형: for문을 돌면서 if로 거르고, 새 리스트에 add한다. (코드가 길고 의도가 한눈에 안 들어옴)
선언형(Stream): “필터링하고, 변환해서, 수집해라.” (비즈니스 로직이 한눈에 보임)
람다는 익명 함수를 만드는 방식이지만, 본질은 “행위(Behavior)를 파라미터로 전달하는 것”입니다.
람다를 쓰려면 단 하나의 추상 메서드만 가진 인터페이스가 필요합니다.
@FunctionalInterface 어노테이션을 붙여 컴파일 타임에 체크하는 것이 관례입니다.
자주 쓰는 인터페이스: Predicate
스트림은 데이터 소스(컬렉션, 배열 등)를 추상화하여 연속적으로 처리하는 도구입니다. 원본 데이터를 변경하지 않는다는 점이 가장 중요합니다.
생성 (Source): list.stream()
중간 연산 (Intermediate): filter, map, sorted, distinct (결과가 다시 스트림이므로 연결 가능)
최종 연산 (Terminal): collect, forEach, count, anyMatch (스트림을 닫고 결과를 반환)
상황: 배차 대기 중인 주문 리스트에서 “서울” 지역 주문만 골라 주문 ID 리스트로 변환해야 함.
Java
1
2
3
4
5
6
List<Long> seoulOrderIds = new ArrayList<>();
for (Order order : orders) {
if ("SEOUL".equals(order.getRegion()) && "PENDING".equals(order.getStatus())) {
seoulOrderIds.add(order.getId());
}
} // 결과 수집
1
2
3
4
5
List<Long> seoulOrderIds = orders.stream()
.filter(o -> "SEOUL".equals(o.getRegion())) // 조건 필터링
.filter(o -> "PENDING".equals(o.getStatus())) // 연속 필터링 가능
.map(Order::getId) // ID만 추출 (Method Reference)
.collect(Collectors.toList()); // 결과 수집
NullPointerException(NPE)은 개발자의 영원한 숙제입니다. Optional은 값이 “있을 수도 있고 없을 수도 있음”을 명시적으로 표현하는 컨테이너입니다.
Bad: if (opt.isPresent()) { return opt.get(); } (기존 null 체크와 다를 게 없음)
Good: 함수형 메서드 활용
opt.orElse(“Default”): 없으면 기본값 반환.
opt.orElseThrow(): 없으면 예외 던지기.
opt.ifPresent(v -> …): 있을 때만 로직 실행.
스트림의 중간 연산은 최종 연산이 호출되기 전까지 절대 실행되지 않습니다. * “100만 개 데이터 중 filter 후 findFirst”를 하면, 100만 개를 다 거르는 게 아니라 조건을 만족하는 첫 번째 데이터를 찾는 순간 멈춥니다. 성능 최적화가 자동으로 일어나는 지점입니다.
가독성 vs 복잡성: 스트림이 무조건 좋은 건 아닙니다. 로직이 너무 복잡해지면 오히려 for문보다 읽기 힘들어집니다. “한 줄이 너무 길어지면 끊어가자.”
병렬 스트림(Parallel Stream): parallelStream()은 멀티코어를 쓰지만, 데이터가 적거나 순서가 중요하면 오히려 더 느리고 위험합니다. 신중히 써야 합니다.
Optional은 반환 타입으로만: 필드 값이나 파라미터로 Optional을 쓰는 건 설계 의도에 어긋나며 성능 저하를 유발합니다.
스트림은 원본 리스트의 요소를 정렬하면 원본도 정렬될까? (정답: 아니오)
map과 flatMap의 차이는 무엇인가? (중첩 구조를 펴주는 과정의 이해)
왜 Optional.get()을 바로 호출하는 것을 지양해야 할까?
]]>OS 독립성: 바이트코드(.class)는 JVM 위에서 실행되므로, 윈도우에서 짠 코드가 리눅스 서버에서도 동일하게 작동함.
자동 메모리 관리: C/C++처럼 개발자가 free()를 호출할 필요 없이, JVM이 알아서 가비지(Garbage)를 치움.
Lazy Loading (지연 로딩): 모든 클래스를 한꺼번에 올리지 않고, 실제 코드에서 참조될 때 로드함.
단계: Loading(읽기) → Linking(검증/준비) → Initialization(static 값 초기화).
Interpreter: 바이트코드를 한 줄씩 읽어서 실행. 빠르지만 반복 작업엔 비효율적.
JIT (Just-In-Time) Compiler: 자주 실행되는 ‘Hot Method’를 찾아내서 통째로 기계어로 컴파일한 뒤 캐싱함.
예시: 반복문이 1만 번 돌아가면 인터프리터 대신 JIT가 개입해 실행 속도를 폭발적으로 높임.
실제 코드를 예시로 보면 이해가 빠릅니다.
1
2
3
4
public void study() {
int age = 25; // Stack에 저장 (기본 타입 변수)
String name = new String("Gemini"); // 'name' 레퍼런스는 Stack, "Gemini" 객체는 Heap에 저장
}
클래스 이름, 부모 클래스 이름, 메서드 데이터, static 변수가 저장됨.
프로그램 시작부터 종료까지 메모리에 남아있으므로 과도한 static 사용은 메모리 낭비를 초래함.
Root Set: Stack의 변수, Static 변수 등에서 참조가 시작됨.
Reachable: Root Set으로부터 연결 고리가 있는 객체. (생존)
Unreachable: 연결 고리가 끊긴 객체. (GC 대상)
객체의 90%는 금방 쓰레기가 된다는 통계적 사실에 기반합니다.
새로 만든 객체가 들어감. 꽉 차면 Minor GC 발생.
살아남은 객체는 Survivor 영역으로 이동하며 ‘Age’가 올라감.
일정 Age(보통 15회) 이상 살아남은 ‘장수 객체’가 이동함.
여기가 꽉 차면 Major GC (Full GC) 발생. (이때 Stop-the-world 발생)
현상: GC를 실행하기 위해 JVM이 애플리케이션의 모든 스레드를 일시 정지시키는 것.
해결: 최신 GC(G1, ZGC)는 이 멈춤 시간을 밀리초(ms) 단위로 줄이는 방향으로 발전 중.
정적 컬렉션 사용: static List에 객체를 계속 넣고 비우지 않으면, GC가 “아직 참조 중이네?”라고 판단해 절대 치우지 않음. 결국 OutOfMemoryError(OOM) 발생.
리소스 미폐쇄: DB 연결(Connection)이나 파일 스트림을 열고 close() 하지 않으면 메모리가 점유된 상태로 남음.
객체 지향은 단순히 변수와 함수를 묶는 것이 아니라, 객체 간의 메시지 송수신을 통해 시스템을 구축하는 것입니다.
객체 지향은 단순히 변수와 함수를 묶는 것이 아니라, 객체 간의 메시지 송수신을 통해 시스템을 구축하는 것입니다.
자율적 객체: 객체는 스스로의 상태를 관리하고, 외부의 요청에 어떻게 응답할지 스스로 결정해야 함.
추상화(Abstraction)의 두 얼굴: 1. 구체적인 사물들의 공통점을 뽑아내는 것 (예: 사과, 바나나 → 과일).
판단 기준: “어떤 코드를 변경해야 할 때, 그 영향이 어디까지 미치는가?”
실무 Tip: 클래스 이름이 Manager, Util, Service처럼 너무 포괄적이면 SRP를 위반할 확률이 높습니다. UserValidator, UserPasswordHasher처럼 구체적으로 쪼개세요.
핵심 기술: 인터페이스(Interface)와 상속.
적용 사례: JDBC 드라이버. 자바 애플리케이션은 동일한 DB 접근 코드를 사용하지만, 드라이버만 교체하면 MySQL, Oracle, PostgreSQL 등 어떤 DB와도 연결됩니다. 애플리케이션 코드는 수정(Closed)하지 않고, DB 지원은 확장(Open)된 사례입니다.
주의사항: 단순히 문법적 컴파일 에러가 안 나는 것이 아니라, 부모 클래스의 규약(계약)을 지켜야 합니다.
Bad Example: Bird 클래스에 fly() 메서드가 있는데, 이를 상속받은 Penguin 클래스에서 “저는 못 날아요”라며 예외(Exception)를 던지면 LSP 위반입니다. (날 수 있는 새만 fly()를 가져야 함)
핵심: “덩치 큰 인터페이스 하나보다, 구체적인 인터페이스 여러 개가 낫다.”
실무 Tip: 스프링 프레임워크의 인터페이스들을 보면 Serializable, Cloneable처럼 아주 작게 쪼개져 있는 것을 볼 수 있습니다. 필요한 기능만 골라 조합(Multi Implements)하기 위함입니다.
핵심: “변하기 쉬운 것(구현체)에 의존하지 말고, 변하지 않는 것(인터페이스)에 의존하라.”
비유: 콘센트(인터페이스)에 의존해야지, 특정 브랜드의 가전제품 선에 직접 연결하면 안 되는 것과 같습니다.
많은 초보 개발자가 재사용을 위해 ‘상속(Extends)’을 쓰지만, 실무에서는 ‘합성(Composition)’을 권장합니다.
상속(Inheritance)의 문제점: 부모와 자식 관계가 너무 강하게 결합됨(Strong Coupling). 부모 클래스의 작은 변경이 자식 모두에게 치명적인 버그를 일으킬 수 있음.
합성(Composition)의 장점: 클래스 내부에 다른 객체를 필드로 가지고 있는 방식. 실행 시점에 의존성을 교체할 수 있어 훨씬 유연함.
1
2
3
4
5
6
7
8
// [합성 예시]
public class Robot {
private MoveStrategy moveStrategy; // 인터페이스를 필드로 가짐 (합성)
public void setMoveStrategy(MoveStrategy strategy) {
this.moveStrategy = strategy; // 달리기 모드, 비행 모드 등을 자유롭게 교체
}
}
SOLID 원칙을 잘 지키면 자연스럽게 디자인 패턴으로 이어집니다.
OCP/DIP를 지키면? → 전략 패턴(Strategy Pattern), 템플릿 메서드 패턴.
SRP를 지키면? → 프록시 패턴(Proxy Pattern), 데코레이터 패턴.
인터페이스 없이 개발하면 어떤 일이 벌어지는가? (코드 수정의 지옥)
왜 스프링은 모든 서비스 객체를 주입(DI)받아 사용하는가? (DIP를 지키기 위해)
내가 진행했던 프로젝트에서 SRP를 가장 잘 지킨 클래스는 무엇인가?
멱등 키 기반 결제 생성 (POST /payments)
토스 결제 준비/승인 (POST /payments/prepare, POST /payments/confirm)
주문 기준 결제 상태 조회 및 관리자 목록 조회
결제 생성 이벤트 발행(payment.created)으로 주문 모듈과 연동
payments
주요 컬럼: id, order_id, amount, idempotency_key, payment_key, status, provider_status, approved_at
인덱스: uq_payments_idempotency_key(유니크), ix_payments_order_id
| 내부 상태: PENDING | SUCCEEDED | FAILED |
POST /payments는 학습용 단순 플로우로 즉시 SUCCEEDED 저장
멱등성은 idempotency_key 유니크 + 트랜잭션 + unique_violation(23505) 핸들링으로 보장
토스 승인 시 TOSS_SECRET_KEY 및 TossPayments-Api-Version 헤더를 사용
외부 PG 오류는 PAYMENT_PROVIDER_FAILED로 표준화
GET /payments?order_id= : 결제 목록 조회(관리자)
POST /payments : 결제 생성(멱등 키 필수)
POST /payments/prepare : 토스 결제 준비
POST /payments/confirm : 토스 결제 승인
GET /payments/:orderId : 주문별 결제 상태 조회
POST /payments/webhook/toss : 토스 웹훅 수신(초안)
멱등 충돌: PAYMENT_IDEMPOTENCY_CONFLICT
금액 검증: 주문 금액과 다르면 PAYMENT_AMOUNT_MISMATCH
중복 승인 방지: PAYMENT_ALREADY_CONFIRMED
PG 실패: PAYMENT_PROVIDER_FAILED
서비스 레이어 비즈니스 로직
상태 전이 로직
test/e2e/payment.idempotency.int.spec.ts: 같은 멱등 키로 두 번 요청 시 동일 결제 반환 검증
test/unit/modules/payment/payment.service.spec.ts: 서비스 단위 로직 검증
현재 confirmWithToss는 서킷브레이커/재시도 정책이 없어 PG 장애 시 취약
웹훅은 서명 검증/이벤트 분기가 미구현 상태라 운영 적용 전 보강 필요
부분 취소/부분 환불 API
결제 상태 변경 이력 테이블
웹훅 기반 비동기 상태 동기화 및 정산 도메인 연결
고객사 기준 주문 분할 생성 (order_group_id, orders[])
권한/스코프 기반 주문 목록 조회 (my, company, all)
주문 상세 라인 추가 및 합계 재계산
| 결제 상태를 기반으로 주문 목록 status(PAID | PENDING) 계산 |
| orders.delivery_status: WAITING | SHIPPING | DELIVERED |
| 목록 응답 status: payments 테이블을 조회해 PAID | PENDING으로 계산 |
주문 생성 시 items[]를 client_company_id로 그룹핑해 회사별 주문 분할 생성
결제 생성 이벤트(payment.created)를 수신해 없는 주문이면 최소 주문 레코드를 자동 생성
개인정보(PII) 암호화: 주문자명, 주소, 연락처, 이메일은 AES-256-GCM으로 DB 저장 시 암호화. PII_ENCRYPTION_KEY 환경변수(32바이트 base64) 필수.
GET /orders : 주문 목록 조회(인증 필요, scope/page/limit/order_id/keyword)
POST /orders : 주문 생성(고객사별 분할)
GET /orders/:orderId : 주문 + 상세 조회
POST /orders/:orderId/details : 주문 상세 라인 추가(인증 필요)
PATCH /orders/:orderId : 주문 수정(주소/주문자/배송상태)
결제 모듈 이벤트(payment.created) 수신 훅 구현
주문 목록의 결제 상태는 payments.status=SUCCEEDED 여부로 계산
k6/pay-system.smoke.js: 결제 생성 -> 주문 조회 -> 상세 추가 흐름 스모크
E2E는 현재 Auth/Master/Payment 중심으로 구성되어 있어 OMS 전용 E2E 보강 필요
groupItemsByCompany가 아이템별 상품 조회를 순차 수행해 대량 요청에서 지연 가능
결제 상태는 조회 시 계산 방식이라, 고트래픽에서 조인/서브쿼리 부담 증가 가능
OMS 전용 E2E 테스트 추가
분할 주문/결제 묶음 단위 API(결제 일괄 처리 포함) 확장
키워드 검색 DB 오프로딩(현재 메모리 필터링 구간 개선)
회원가입/로그인/토큰 갱신/로그아웃
역할(Role) 조회 및 사용자 권한 컨텍스트 제공
내 프로필/배송지 CRUD
AuthModule + UsersModule 분리
AuthController/AuthService, UsersService, UserRepository 계층
비밀번호/리프레시 토큰은 bcrypt 해시만 저장(평문 저장 금지)
refresh 토큰은 로그인/refresh 시 회전(rotate) 정책
JWT access/refresh secret 및 만료시간은 환경변수 기반
POST /auth/register : 회원가입
POST /auth/login : 로그인
POST /auth/logout : 로그아웃(인증 필요)
POST /auth/refresh : 토큰 갱신(인증 필요)
GET /auth/me : 내 정보 + 메뉴 조회(인증 필요)
GET /auth/roles : 역할 목록 조회(인증 필요)
GET/POST /auth/me/profile : 내 프로필 조회/저장
GET/POST /auth/me/addresses : 내 배송지 조회/생성
POST /auth/me/addresses/:id : 내 배송지 수정
POST /auth/me/addresses/:id/default : 기본 배송지 설정
유저 ID 기반으로 주문/결제 히스토리 조회
주문 생성/조회 권한 제어 시 JWT payload(role, clientCompanyId) 활용
결제/주문 API 호출 시 Authorization: Bearer 기반 사용자 컨텍스트 전달
비밀번호/토큰 관련 로직
권한(Authorization) 체크 로직
test/e2e/auth.e2e-spec.ts: register + login + me 플로우
test/unit/modules/users/users.service.spec.ts: 유저 서비스 단위 검증
test/unit/modules/auth/auth.service.spec.ts: 인증 서비스 단위 검증
현재 리프레시 토큰은 사용자당 단일 해시 저장 방식이라 다중 디바이스 세션 요구사항과 충돌 가능
계정 잠금/비정상 로그인 탐지/2차 인증 정책은 미구현
소셜 로그인/외부 인증 연동
권한(관리자/일반 유저 등) 세분화
디바이스 단위 세션 관리(다중 refresh 토큰)
개인정보 마스킹/보존/삭제 정책 문서화와 운영 정책 연동
프로젝트 이름: AI 활용 결제·OMS Nest 프로젝트
기간: 2026-03 ~ 미정
목적: 개인 학습과 동시에, 실무에 바로 가져갈 수 있는 결제/OMS 백엔드 아키텍처를 만들고, AI를 “팀원”처럼 활용하는 개발 프로세스를 실험하는 것
현재 회사에서는 Express를 사용하고 있지만, 구조화된 모듈/DI/데코레이터 기반의 NestJS를 직접 써보며 프레임워크 관점을 넓히고 싶었다.
회사 도메인(결제·OMS)을 NestJS 위에서 다시 모델링해 보면서, 도메인 이해도를 한 단계 더 끌어올리고자 했다.
TDD와 테스트 가능한 구조를 실제 도메인(결제/주문/유저)에 적용해 보는 경험
k6 등을 활용해 다양한 트래픽 패턴과 장애/에러 상황을 직접 설계·실행·해석해 보는 경험
AI를 어떻게하면 다른사람과 다르게, 더 효율적으로 사용할 수 있는가에 대한 경험
혼자 하는 사이드 프로젝트라도 결제/주문/유저까지 들어가면 도메인 복잡도가 커져, 설계·문서·테스트를 모두 혼자 챙기기 어렵다.
반복적인 설정/보일러플레이트와 리뷰가 많아, “사고”에 쓸 수 있는 시간이 줄어든다.
설계·리뷰·문서화의 상당 부분을 AI에게 맡기고, 사람은 도메인 정의와 의사결정에 집중한다.
최근 실무에서도 AI 활용 능력을 요구하는 흐름 속에서, “혼자서 여러 명이 하는 것처럼” 프로젝트 전체를 읽고 관리하는 연습을 하고자 했다.
실제 팀 회의처럼 역할(시니어, DB, QA, 보안, 운영, 비즈니스, 노션 등)을 분리하고, 각 역할의 관점에서 끊임없이 질문·리뷰를 받는 개발 프로세스를 만든다.
Backend: NestJS, TypeScript
DB: PostgreSQL
인프라: Local -> Docker(이 후 예정)
성능/테스트: k6, jest
결제
주문(OMS)
유저
가독성 좋은 모듈 구조
테스트 가능성
확장 가능한 결제/주문 플로우
개발·아키텍처 파트: 시니어담당자, 페어담당자(반대의견제시)
데이터·성능 파트: DB담당자, 성능담당자
품질·안정성 파트: QA담당자, 에러담당자, 로그담당자
보안·운영 파트: 보안담당자, 운영담당자
비즈니스·유지보수 파트: 비즈니스담당자, 유지보수담당자
문서화·명세 파트: 비즈니스문서담당자, 노션리뷰담당자, API명세담당자
시니어담당자: 설계, 모듈 구조, 변경 용이성 리뷰
페어담당자: 반대 의견 제시
DB담당자: 스키마, 인덱스, 쿼리 성능
QA담당자: 테스트 전략, 엣지 케이스
보안담당자: 인증/인가, 민감정보 보호, 로그 마스킹
성능담당자: 응답 시간, 병목, k6 기반 성능 관리
에러담당자·로그담당자: 에러 코드/메시지 정책, 추적 가능한 로그 설계
비즈니스·유지보수담당자: MVP 범위 설정, 운영자 관점에서의 가독성과 관리자 기능
노션리뷰담당자·비즈니스문서담당자: 요구사항·정책 정리, docs/notion/*와 Notion 싱크
요구사항 정리 → 아키텍처/ERD 구상 → 모듈별 설계 → 구현 → 테스트 → 회고
각 단계마다 “역할 회의”를 한 번씩 거치고, 중요한 결정은 회의록(docs/meetings/*.md)과 노션에 함께 남긴다.
결제/주문/유저 각각에 대해 유스케이스를 정의하고, API·DB 설계를 점진적으로 다듬기
공통 코드/공통 테이블 전략 정리 (docs/erd.md, docs/schema.sql와 연동)
유닛/통합 테스트
k6를 활용한 부하 테스트 시나리오 작성 및 정기 실행으로, 주요 플로우(주문→결제)의 성능을 숫자로 관리
장애/에러 케이스 정의 및 핸들링 전략을 문서와 테스트 코드로 동시에 관리
운영 관점에서 필요한 관리자 기능/로그/모니터링 정리
로그에 orderId, userId, requestId 등 공통 식별자를 남기는 규칙을 적용
Notion + docs/를 싱크 맞춰 문서화하고, 회의 내용은 docs/meetings/*.md와 노션 회의록에 아카이빙
예: PG 연동/웹훅 처리/정산 시나리오 등, 현실적인 요구사항을 하나씩 끌어와 반영
돈/정산/환불 도메인은 비즈니스·DB·QA 역할이 함께 협의해, 보수적으로 단계별 확장
AI를 “팀처럼” 쓰려면, 도구 성능보다도 역할 정의와 워크플로우 합의가 더 중요하다는 걸 느꼈다.
실제로 역할 회의를 하듯 질문을 던지면, 혼자 개발할 때 보이지 않던 리스크(정합성, 로그, 운영, 비즈니스)가 잘 드러난다.
아직 처음 사용하다 보니 자연스럽게 사용하는 것이 어렵다.
길이 N의 굴다리에 M개의 가로등이 설치되어 있다.
각 가로등은 높이 H만큼 좌우를 비출 수 있다.
굴다리 전체를 밝히기 위한 최소 가로등 높이 H를 구하는 문제이다.
N : 굴다리 길이
M : 가로등 개수
가로등 위치는 오름차순으로 주어짐
모든 구간이 어둡지 않도록 해야 함
구해야 하는 것 → 최소 높이 H
굴다리를 밝히기 위해 고려해야 할 구간은 3가지이다.
굴다리 시작점(0)부터 첫 번째 가로등까지의 거리
1
x[0]
이 값만큼은 비춰야 한다.
두 가로등 사이의 거리:
1
x[i] - x[i-1]
이 구간은 양쪽 가로등이 절반씩 비추므로
필요한 높이는
1
ceil((거리) / 2)
정수 올림 처리를 위해:
1
(x[i]-x[i-1]+1)/2
을 사용한다.
마지막 가로등부터 굴다리 끝까지의 거리
1
N - x[M-1]
위 세 구간 중
가장 큰 값이 최소 가로등 높이 H가 된다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
package boj;
import java.util.*;
import java.io.*;
public class Boj17266 {
public static void main(String[] args) throws IOException {
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
int N = Integer.parseInt(br.readLine());
int M = Integer.parseInt(br.readLine());
int[] x = new int[M];
StringTokenizer st = new StringTokenizer(br.readLine());
for (int i = 0; i < M; i++) {
x[i] = Integer.parseInt(st.nextToken());
}
// 각각의 가로등 위치사이 간격의 최대값을 구하기
int maxDist = x[0];
for (int i = 1; i < M; i++) {
int dist = (x[i] - x[i-1] + 1) / 2;
if (maxDist < (dist)) {
maxDist = dist;
}
}
// 최대값 구한 후 마지막을 비출 수 있는지 구하기
maxDist = Math.max(maxDist, N - x[M-1]);
System.out.println(maxDist);
}
}
시간복잡도: O(M)
공간복잡도: O(M)
가로등 사이 간격은 그대로 사용하면 안 된다.
반드시 2로 나누고 올림 처리해야 한다.
왼쪽 끝, 오른쪽 끝도 따로 비교해야 한다.
최댓값을 구하는 문제로 변환하면 쉽게 해결된다.
현재 랭킹 리스트에 점수들이 내림차순으로 주어져 있다.
새로운 점수를 넣었을 때 몇 등을 할 수 있는지 구하는 문제이다.
단, 랭킹 리스트의 최대 크기 P를 초과하면 점수를 올릴 수 없다.
N : 현재 랭킹에 있는 점수 개수
내 점수
P : 랭킹 리스트 최대 크기
점수는 내림차순으로 주어짐
같은 점수는 같은 등수
리스트가 가득 찼고, 마지막 점수보다 작거나 같으면 등록 불가
출력:
가능한 등수 출력
등록 불가 시 1
핵심은:
🔥 “나보다 높은 점수의 개수 + 1 = 내 등수”
리스트를 앞에서부터 순회하면서:
나보다 높은 점수 → 등수 증가
같은 점수 → 순위 유지, 자리 차지
더 낮은 점수 → 그 위치에 들어감
1
현재 들어갈 수 있는 인원 수 >= P
이면 -1 출력
즉,
1
내 점수 이상인 사람 수 >= P
이면 등록 불가
1
2
N=3, 내 점수=90, P=3
100 90 80
100 > 90 → 등수 증가
90 == 90 → 자리 차지
80 < 90 → 여기서 멈춤
→ 2등 가능
1
2
N=3, 내 점수=70, P=3
100 90 80
나보다 높은 점수 3명
이미 P명 가득
→ -1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
package boj;
import java.io.*;
import java.util.*;
public class Boj1205 {
public static void main(String[] args) throws IOException {
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
StringTokenizer st = new StringTokenizer(br.readLine());
int N = Integer.parseInt(st.nextToken()); // N
int rank = Integer.parseInt(st.nextToken()); // 확인할 랭킹
int P = Integer.parseInt(st.nextToken()); // P
if (N == 0) { // N이 0 일때는 리스트를 받을 필요 없음
if (P == 0) // 0인경우 아예 랭킹에 올릴 수 없음
System.out.println("-1");
else
System.out.println("1");
} else { // 리스트 받아야함
st = new StringTokenizer(br.readLine());
int checkCount = 0; // 지금까지 확인한 랭킹 개수
int myRank = 1; // 나의 순위
int[] rankList = new int[N];
for (int i = 0; i < N; i++) {
rankList[i] = Integer.parseInt(st.nextToken());
}
for (int i = 0; i < N; i++) {
if (rankList[i] > rank) { // 나보다 크면 내가 뒷순번
checkCount++;
myRank++;
} else if (rankList[i] == rank) {// 같으면
checkCount++;
} else { // 내 자리
break;
}
}
if (checkCount >= P) {
System.out.println("-1");
} else {
System.out.println(myRank);
}
}
}
}
시간복잡도: O(N)
공간복잡도: O(N)
순위 문제는 “나보다 높은 점수 개수”로 접근하면 단순해진다.
같은 점수 처리와 리스트 최대 크기 조건이 핵심이다.
예외 케이스(N=0, 리스트 가득 참)를 먼저 정리하는 것이 중요하다.
임스와 함께 미니게임을 하려 한다.
게임 종류에 따라 한 판에 필요한 인원이 다르다.
Y : 1명
F : 2명
O : 3명
신청한 사람들의 이름이 주어질 때,
임스가 총 몇 번 게임을 할 수 있는지 구하는 문제이다.
※ 같은 사람이 여러 번 신청할 수 있다.
신청 인원 수 N (1 ≤ N ≤ 100,000)
게임 종류: Y, F, O 중 하나
같은 사람이 여러 번 신청할 수 있음
중복 신청은 한 번만 인정
출력: 임스가 진행할 수 있는 게임 횟수
핵심은:
🔥 “중복 제거”
같은 사람이 여러 번 신청할 수 있기 때문에
실제로 게임에 참여 가능한 인원은 중복 제거된 인원 수이다.
이를 위해 HashSet을 사용한다.
게임 옵션에 따라 한 판에 필요한 인원이 다르다:
따라서:
1
게임 횟수 = (중복 제거된 인원 수) / (게임에 필요한 인원 수)
입력:
1
2
3
4
5
6
7
8
7 F
a
b
c
a
d
b
e
중복 제거 후:
1
a, b, c, d, e → 총 5명
F는 2명 필요 →
5 / 2 = 2번 가능
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
package boj;
import java.io.*;
import java.util.*;
public class Boj10431 {
public static void main(String[] args) throws IOException {
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
int testCase = Integer.parseInt(br.readLine());
StringBuilder sb = new StringBuilder();
for (int t = 1; t <= testCase; t++) {
StringTokenizer st = new StringTokenizer(br.readLine());
int caseNum = Integer.parseInt(st.nextToken()); // 테스트 번호
int[] arr = new int[20];
int moveCount = 0;
for (int i = 0; i < 20; i++) {
arr[i] = Integer.parseInt(st.nextToken());
// 현재 학생(arr[i])보다 앞에 있으면서 키 큰 학생 수 세기
for (int j = 0; j < i; j++) {
if (arr[j] > arr[i]) {
moveCount++;
}
}
}
sb.append(caseNum).append(" ").append(moveCount).append("\n");
}
System.out.print(sb);
}
}
시간복잡도: O(N)
공간복잡도: O(N)
중복 제거 문제에서는 Set이 가장 간단한 해결 방법이다.
조건 분기는 나누기 연산 하나로 해결 가능하다.
자료구조 선택이 문제 난이도를 크게 낮춘다.