junju404

[Project] AI 직무 추천 서비스, Node.js에서 Spring Boot로의 마이그레이션과 RAG 도입기 (Part 2. 기술 후보군 탐색과 가설 수립)

junju404 — Sun, 25 Jan 2026 16:55:48 +0900

1. 서론 : 기술 스택, 답을 정하기 전에 질문부터

논리적인, 설득력 있는 코드를 작성하자.
항상, "왜"를 생각하자.

Part 1에서는 프로젝트를 다시 시작하게 된 배경과 기존 시스템의 문제점을 회고했다.

이번 Part 2에서는 본격적인 개발에 앞서, 과거에는 어떻게 구현했는지(AS-IS)를 되돌아보고, 새로운 시스템에 도입할 만한 기술 후보군(To-BE s)들을 리서치한 내용을 정리해 보고자 한다.

지금 당장 "이 기술을 쓰겠다!"고 확정하는 것이 아니다. 현재 내 프로젝트의 목표(안정성, 정확성, 성능)에 부합할 것으로 예상되는 기술들을 나열하고, "왜 이 기술을 후보로 올렸는지"에 대한 가설을 수립하는 단계다.

추후 각 파트별(DB, 캐시, 검색 등) 상세 구현 단계에서 직접 성능을 비교/검증하며 최종 스택을 확정해 나가는 과정을 기록할 예정이다.

2. 본론 : 영역별 기술 후보군 탐색

2-1. 데이터 수집 (폐쇄적인 학사 정보 수집)

우리 학교의 강의 계획서는 외부에 공개되지 않고, 학사정보시스템에 로그인해야만 볼 수 있다. 이 폐쇄적인 데이터를 어떻게 가져올지를 생각해봐야된다.

1) 과거의 방식 (Legacy)

- 방식 : 수동 입력 (직접 DB에서 INSERT)

장점
- 개발 비용이 '0'이다. 초기 데이터를 가장 빠르게 구축할 수 있었다.
단점
1. 확장성 Zero : 우리 학과(소프트웨어학과) 외 타 학과로 서비스를 확장하려면, 결국엔 그 학과 강의 계획서를 일일이 타이핑해야 한다.
2. 데이터 최신화 번거로움 : 교수님이 강의 내용을 바꾸거나 강의의 교수님이 바뀐다면 기존 DB를 사람(개발자)이 다시 일일이 수정해야된다.

2) 기술 스택 후보

자동화를 위해 고려 중인 크롤링 기술들은 다음과 같다.

- Jsoup (Java HTML Parser)

브라우저 없이 HTTP 요청만으로 HTML을 가져와 파싱한다.
예상 특징 : 리소스 소모가 가장 적고 빠르다. 하지만 로그인이 필요한 페이지나, JS로 동적 렌더링되는 페이지는 수집이 불가능할 수 있다.

- Selenium WebDriver

실제 브라우저를 띄워 사람처럼 동작하게 한다.
예상 특징 : 로그인, 팝업, 버튼 클릭 등 복잡한 상호작용이 가능하다. 하지만 메모리와 CPU를 많이 점유하여 속도가 느릴 것이다.

- Playwright

MS에서 만든 최신 브라우저 자동화 도구로, Selenium보다 빠르고 안정적이라 알려져 있다.
예상 특징 : Node.js 진영에서 강세지만 Java 생태계에서도 호환성이 좋을지, 레퍼런스가 충분한지 검증이 필요하다.

1차 가설 수립

"로그인 세션 처리는 Selenium으로 뚫고, 이후 세션 쿠키를 활용한 대량 데이터 파싱은 Jsoup으로 처리하는 하이브리드 방식을 사용하면 리소스 효율을 극대화할 수 있지 않을까?"

2-2. Main Database (데이터 저장소의 선택)

1) 과거의 방식 (Legacy)

기술 : MySQL

선택 이유 : 솔직히 말하면 "이전 프로젝트에서 사용했던 DB는 이것뿐이라서", "남들이 다 쓰니까" 였다. 기술적인 비교나 고민은 없었다.

2) 기술 후보군

데이터의 성격(관계형 vs 비정형)과 읽기/쓰기 패턴을 고려해 다양한 DB를 검토한다.

A. RDBMS (관계형 데이터베이스) - 메인 저장소

강의, 학생, 수강 이력 등은 명확한 관계를 가지며 데이터 무결성이 가장 중요한 특징이다.

1. MySQL 8.0

가장 대중적인 오픈소스 DB이며 방대한 레퍼런스를 보유하고 있다.
가설 : 익숙하기에 러닝 커브가 낮다. 국내 IT 기업 표준에 가까워 실무 적응에 유리하다.

2. PostgreSQL

가장 진보된 오픈소스 RDBMS"로 불리며, 복잡한 쿼리와 Vector(pgvector) 확장 기능이 강력하다.
가설 : 벡터 검색 기능이 필요할 때 별도의 벡터 DB 없이 포스트그레스 하나로 해결할 수 있을지도 모른다. MySQL 대비 성능 차이가 관건이다.

3. MariaDB

MySQL의 오픈소스 포크(Fork) 버전으로, MySQL과 호환성이 높다.

B. NoSQL (비관계형 데이터베이스) - 조회 및 캐시용

강의 계획서처럼 수정은 거의 없고 '조회'만 빈번하게 일어나는 데이터나, 로그 데이터 처리를 위해 고려한다.

1. MongoDB

JSON(Document) 형태로 데이터를 저장하며 스키마가 유연하다.
가설 : 강의 계획서 항목이 학과마다 제각각일 때 유연하게 대처 가능하다. 하지만 트랜잭션 관리가 RDBMS보다 까다로울 수 있다.

2. Firebase (Firestore)

구글의 서버리스 DB로 실시간 동기화가 강점이다.
가설 : 프론트엔드와 직접 연동하기 편하지만, 백엔드 로직이 복잡해질 경우 제약이 있을 수 있다.

1차 가설 수립
"기본적인 데이터 무결성을 위해 RDBMS(MySQL or PostgreSQL)를 메인으로 가되, 단순 조회 성능이나 유연성이 필요한 부분은 NoSQL 도입을 검토해 볼 예정이다."

2-3. Caching & Vector (속도와 비용 효율화)

생성형 AI API는 호출당 비용이 발생하고 응답 속도가 느리다. 이를 보완할 기술이 필수적이다.

1) 과거의 방식 (Legacy)

방식 : MySQL을 캐시처럼 사용 (단순 조회)
문제점 : Disk I/O가 발생하므로 아주 빠르지 않고, 오래된 데이터를 자동으로 지우는 로직을 직접 구현해야 해서 번거로웠다.

2) 기술 후보군

1. Redis (Remote Dictionary Server)

Key-Value 구조의 인메모리 저장소이다. RAM에 저장하므로 처리 속도가 압도적으로 빠르다.
가설 (Caching) : 사용자가 동일한 질문을 하면 DB 접근 없이(컨텍스츠 스위칭 X) Redis에서 바로 반환하여 0.1초 내 응답이 가능할 것이다.
가설 (TTL) : "1시간 뒤 삭제" 같은 만료 설정을 통해 데이터 생명주기 관리가 편리할 것이다.
가설 (Vector) : Redis Stack을 활용하면 임베딩 벡터 저장소로도 사용 가능하여, 인프라를 일원화할 수 있을 것이다.

2. Memcached

Redis보다 단순하지만 멀티스레드를 지원해 극강의 처리량을 자랑한다.
가설 : 단순 캐싱만 한다면 좋겠지만, '벡터 검색'이나 '다양한 자료구조'가 필요한 이번 프로젝트에는 Redis보다 범용성이 떨어질 수 있다.

2-4. Application Architecture (코드를 어떻게 짤 것인가?)

1) 과거의 방식 (Legacy)

아키텍처 : Router / Controller / Service / DAO
ORM : 사용 안 함 (Raw SQL)
문제점 : DAO 파일 안에서 SQL 문자열을 직접 + 연산자로 합쳐서 쿼리를 날렸다. 오타가 나면 실행해봐야 알 수 있었고, SQL이 코드에 섞여 있어 유지보수가 매우 힘들었다.

2) 기술 후보군

스프링 부트 환경에서 DB에 접근하는 방식들은 아래와 같다.

1. MyBatis (SQL Mapper)

SQL을 XML 파일로 분리해서 관리한다. 쿼리를 직접 짤 수 있어 튜닝에 유리하다.
가설 : 복잡한 통계 쿼리는 편하겠지만, 단순 CRUD 작업도 일일이 쿼리를 짜야 해서 생산성이 낮을 것 같다.

2. Spring Data JPA (ORM)

Java 객체와 DB 테이블을 자동으로 매핑해준다. 기본적인 쿼리는 메소드 이름만으로 생성된다.
가설 : "SQL 중심"에서 "객체 중심"으로 개발 패러다임을 바꿀 수 있어 생산성이 압도적으로 높을 것으로 기대된다.

3. QueryDSL

Java 코드로 쿼리를 작성하게 해주는 빌더다. 컴파일 시점에 문법 오류를 잡을 수 있다.
가설 : JPA로 해결하기 힘든 동적 쿼리(검색 조건이 많을 때)를 짤 때, 오타 걱정 없이 안전하게 짤 수 있는 최적의 도구로 보인다.

3. 결론 : 꼬리에 꼬리를 무는

바이브 코딩, 하지만 논리적으로 검증하고 학습하는

나는 이번 프로젝트에서 "바이브 코딩"을 지향한다. AI(Copilot, GPT)가 짜주는 코드(코드리뷰 포함)를 적극 활용할 것이다. 하지만, "AI가 짰으니까 맞겠지"라고 맹목적으로 수용하는 일은 과거처럼 "왜?"를 생각하지 않은 것이다.

앞으로 이어질 포스팅에서는 위에서 나열한 후보군들을 하나씩 직접 구현하고 부딪혀보며 내 프로젝트에 최적화된 기술을 찾아가는 과정을 기록할 것이다.

Next Topics

[Data Collection] Selenium vs Jsoup, 폐쇄된 포털을 뚫어라
[Database] MySQL vs PostgreSQL, 벡터 검색은 누가 더 잘할까?
[Cache] Redis 도입 전후 성능 차이 측정 (JMeter)
[Search] 단순 매칭을 넘어선 유사도 검색 구현하기

[Project] AI 직무 추천 서비스, Node.js에서 Spring Boot로의 마이그레이션과 RAG 도입기 (Part 1. 설계와 이유)

junju404 — Mon, 19 Jan 2026 05:08:13 +0900

1. 서론 : 2023년의 QJ, 그 시작과 한계

1) 기획 배경 : "이 과목, 진짜 내 진로에 도움이 될까?"

대학 생활을 하며 매 학기 수강신청 기간마다 겪었던 고질적인 고민이 있었다.

백엔드 개발자가 목표인데,
'시스템 프로그래밍' 과목을 듣는 게 도움이 될까?
아니면 차라리 다른 웹 관련 과목을 듣는 게 나을까?

학과 커리큘럼은 방대했지만, 정작 내가 희망하는 '구체적인 직무'와 연결해 주는 가이드는 부족했다. 선배들에게 물어보거나 강의 계획서를 일일이 찾아보는 것도 한계가 있었고 번거로웠다.

하지만, 2023년에는 마침 "ChatGPT 열풍"이 불고 있었다.

나 역시 GPT에게 조언을 구했지만, 과정은 순탄치 않았다. 매번 전공 과목 강의계획서 텍스트를 복사해서 프롬프트에 붙여넣고, "나 이런 상황인데 이거 들을까?" 라고 물어보는 과정을 반복해야 했다.

귀찮게 계속 내 정보를 입력하고, 전공 설명서를 복사 붙여넣기 해야 하나?
내 관심 직무만 딱 입력하면, 우리 학교 커리큘럼을 싹 분석해서
우선순위를 추천해 주는 서비스가 있다면 어떨까?

이런 지극히 개인적인 니즈와 불편함에서 'QJ(Question Job)' 프로젝트가 시작되었다.

우선 내가 가장 잘 아는 '소프트웨어학과' 커리큘럼을 중심으로 MVP를 구축하고, 점차 타 학과로 확장하려는 목표를 가지고 개발에 착수했다.

2) 기존 서비스(Legacy) 기능 및 아키텍처

당시 팀원들과 나에게 가장 익숙하고 진입 장벽이 낮은 Node.js 생태계를 기반으로 아키텍처를 구성했다.

1) 서비스 아키텍처

2) 기술 스택

- Runtime: Node.js (v18)

- Framework: Express.js

- Database: MySQL

- AI Model: OpenAI GPT-3.5-turbo-16k (Context Stuffing 방식)

- Crawling: Puppeteer (Headless Chrome) + node-schedule

- Infrastructure: AWS EC2 (Ubuntu) + PM2 (무중단 배포 및 프로세스 관리)

3) 기능

로그인/회원가입
- 아이디/닉네임 중복 검사 및 비밀번호 해싱
- JWT(Access Token)와 Cookie를 활용한 인증 구현
취업 게시판
- 학교 대학일자리센터의 채용 공고를 매일 정해진 시간에 수집
- Headless Chrome(Puppeteer)을 띄워 실제 브라우저처럼 페이지를 순회하며 데이터 적재
AI 강의 추천
- 사용자가 '관심 직무(예: 백엔드 개발자)'를 입력하면 서버가 이를 수신
- DB에 저장된 '학교 강의 정보' 전체와 '프롬프트(답변 예시, 상황 설명)'를 조합하여 ChatGPT API로 전송
- Logic
  1. DB에 해당 직무로 조회된 기록이 있는지 확인
  2. 있다면? DB에 저장된 추천 결과(JSON)를 반환 (Cache Hit)
  3. 없다면? GPT API를 호출하여 결과를 생성하고, DB에 저장 후 반환 (Cache Miss)

2. 문제 인식(본론1) : 왜 2년 만에 다시 뜯어고치는가?

잘 돌아갔던 서비스를 굳이 2년 만에 꺼내어 처음부터 다시 만드는 데에는 이유가 있다.

과거의 개발 일지(주간 보고서)를 다시 살펴보니, 당시에는 '기능 구현'에 급급해 놓쳤던 구조적 한계와 엔지니어링의 부재가 명확히 보였기 때문이다.

1) "응답 시간 2분"과 무늬만 캐싱 (Week 13 이슈)

산학 프로젝트 진행 당시, 멘토님께 피드백을 들었다.

GPT API 호출이 2분 정도 걸리면 사용자 입장에서 너무 느리다.

당시 나는 이 문제를 해결하기 위해 RDBMS(MySQL)를 캐시 저장소처럼 사용하는 전략을 택했다.

로직은 단순했다. 누군가 "프론트엔드"를 검색해서 GPT 답변을 받으면, 그 JSON 결과를 MySQL 테이블에 저장해 두는 것이다. 다음 사람이 똑같이 "프론트엔드"를 검색하면 DB에서 꺼내주니 0.1초 만에 응답이 가능했다.

하지만 이 방식은 치명적인 논리적 결함을 안고 있었다.

Cache Miss의 대기 시간 : 누군가 처음 검색하는 직무라면 여전히 2분을 기다려야 한다. 캐싱은 '자주 찾는 데이터'를 빠르게 줄 뿐, 근본적인 생성 속도를 개선해 주진 못했다.
데이터의 최신성(Freshness) 문제 : 만약 학교의 강의 계획서가 업데이트되거나, 추천 로직 프롬프트가 수정되면 어떻게 될까? MySQL에 저장된 과거의 추천 데이터는 상한 데이터(Stale Data)가 된다. 이를 갱신하려면 DB 데이터를 일일이 지우거나 복잡한 업데이트 로직을 짜야 했다. 결국 TTL(유효 기간) 없는 DB 저장은 진정한 의미의 캐싱이라 보기 어려웠다.

2) 토큰 제한과 할루시네이션 (Week 9~10 이슈)

GPT 답변 내용이 중간에 잘리거나, 없는 과목을 추천하는 환각 현상이 발생합니다.

당시에는 'Context Stuffing(문맥 밀어 넣기)' 방식을 사용했다. 쉽게 말해, DB에 있는 170여 개의 과목 정보를 프롬프트 텍스트에 다 때려 넣고 질문하는 방식이었다.

비용 문제 : 과목 데이터가 많아질수록 토큰 사용량이 선형적으로 증가했다.
할루시네이션 : 정보량이 너무 많아지니, GPT가 맥락을 잃고 우리 학교에 없는 과목을 지어내거나, 중요한 필수 과목을 누락하는 현상이 발생했다. 당시엔 프롬프트에 "거짓말하지 마!" 라고 강조 문구를 넣는 것으로 떼웠지만, 이는 공학적인 해결책이 아니었다.

3) 불안정한 데이터 수집 (Stateless Crawling)

Node.js의 node-schedule과 puppeteer를 이용한 무한 루프 방식의 크롤러는 운영 환경에서 매우 불안정했다.

상태 관리 부재 : 100페이지를 크롤링하다가 50페이지에서 네트워크 에러가 나면, 어디서 멈췄는지 알 수 없어 다음 스케줄에 다시 1페이지부터 시작해야 했다.
리소스 누수 : 단순 텍스트 수집에 무거운 Headless Browser(Chrome)를 띄우다 보니 EC2 메모리 점유율이 치솟았고, 종종 서버가 멈추는 원인으로 추측된다.

4) "백엔드"와 "Server Developer"는 다르다? (텍스트 매칭의 한계)

기존 시스템은 DB 조회 시 단순 문자열 일치(=) 방식을 사용했다.

사용자가 "Server Developer"라고 입력하면, 이미 DB에 "백엔드 개발자"에 대한 완벽한 추천 결과가 있어도 이를 활용하지 못하고(Cache Miss), 다시 GPT를 호출해야 했다.

사람에겐 같은 의미지만 컴퓨터에겐 다른 문자열이었기 때문이다. 이 또한 막대한 API 비용 낭비이자 비효율이었다.

5) 운영의 사각지대 (No Monitoring)

가장 큰 문제는 "서버 상태를 알 수 없다"는 것이었다.

EC2가 가끔 멈출 때마다 단순히 재부팅을 했지만, 왜 멈췄는지 알 수 없었다. 크롬(Puppeteer)이 메모리를 얼마나 잡아먹는지, CPU 점유율이 언제 튀는지 측정하는 지표가 전혀 없었다. 눈을 감고 운전하는 것과 다를 바 없었다.

3. 학습 목표 : Java Spring Boot 딥 다이브

단순히 기존 기능을 옮기는 것이 아니다. 이번 마이그레이션의 가장 큰 목적 중 하나는 "Java 생태계로의 깊이 있는 학습"이다.

Single Thread vs Multi Thread: Node.js의 이벤트 루프(Event Loop) 모델과 달리, Spring Boot의 요청 당 스레드(Thread-per-Request) 모델을 직접 경험한다. 스레드 풀(Thread Pool) 설정이 성능에 어떤 영향을 미치는지, 동시성 이슈는 어떻게 제어하는지 학습한다.
객체지향과 디자인 패턴: Java의 강점인 OOP를 활용해, 기존의 절차지향적 코드를 어떻게 유지보수하기 좋은 구조로 개선할 수 있는지 실험한다.
Career Alignment: 내가 목표로 하는 백엔드 엔지니어로서의 커리어 패스에 맞춰, 실무에서 가장 많이 사용되는 기술 스택(Spring Boot, JPA, QueryDSL 등)의 내부 동작 원리를 파고든다.

4. 기술적 해결 전략(본론2) : 가설과 검증

위에서 분석한 기술적 부채들을 청산하기 위해, 나는 Spring Boot 생태계로의 마이그레이션과 아키텍처 재설계를 결정했다.

단순한 언어 변경이 아닌, 시스템의 체질 개선이 목표다.

중요한 점은 특정 기술을 맹목적으로 도입하는 것이 아니라, "가설"을 세우고 "실험"을 통해 최적의 기술 스택을 결정한다는 것이다.

1) Node.js -> Spring Boot (안정성과 배치)

이 부분은 명확한 이유를 가지고 확정했다. 기존의 불안정성을 해결하기 위해 Spring Batch 도입이 필수적이다.

재시작성 : Batch의 JobRepository는 작업의 성공/실패 지점을 DB에 기록한다. 크롤링이 50페이지에서 실패하더라도, 다음 실행 시 정확히 51페이지부터 이어서 수행할 수 있다.
트랜잭션 관리 : 대량의 공고 데이터를 읽고 쓸 때(Chunk Processing), 데이터 정합성을 보장하기 훨씬 유리하다.
Jsoup 도입 : 무거운 브라우저(Puppeteer) 대신 가벼운 HTML 파서인 Jsoup을 사용하여 메모리 사용량을 획기적으로 줄인다.

2) MySQL Cache -> In-Memory Caching Strategy (성능 실험)

"무조건 Redis가 정답인가?"에 대한 물음을 던지고 실험을 진행할 예정이다. RDBMS를 캐시로 쓰던 방식은 버리되, 어떤 캐시 전략이 효율적인지 검증한다.

가설 1 (Local Cache): 단일 서버 환경에서는 네트워크 비용이 없는 HashMap이나 EhCache가 Redis보다 빠를 수 있다.
가설 2 (Global Cache - Redis): 서버 확장성(Scale-out)과 데이터의 영속성, 그리고 TTL(Time To Live) 관리 측면에서는 Redis가 유리할 것이다.
검증 계획 : 두 가지 방식을 모두 구현해 보고, 부하 테스트를 통해 응답 속도와 리소스 효율을 비교하여 최종 스택을 결정한다.

3) Context Stuffing -> RAG & Vector Search (정확도 실험)

모든 정보를 프롬프트에 밀어 넣는 방식을 버리고, RAG(검색 증강 생성) 아키텍처 도입을 시도한다.

Vector Search (유사도 검색): 과목 데이터와 직무 키워드를 임베딩(Embedding)하여 Vector DB에 저장한다. "Server Developer"라고 검색해도 "백엔드 개발자"와 유사함을 인지하고 결과를 찾아내는 의미 기반 검색(Semantic Search)을 구현한다.
Grounding: 전체 과목이 아닌, 유사도가 높은 상위 N개 과목만 추출하여 GPT에게 제공함으로써 할루시네이션을 줄이고 API 비용을 절감한다.

4) 모니터링

더 이상 감으로 운영하지 않는다. 애플리케이션의 상태를 투명하게 볼 수 있는 환경을 구축한다.

Actuator & Prometheus: Spring Boot Actuator를 통해 JVM 메모리, 스레드 상태, HTTP 요청 수 등의 메트릭을 수집한다.
Grafana: 수집된 데이터를 시각화 대시보드로 만들어, CPU 스파이크나 메모리 누수 조짐을 눈으로 확인하고 대응하는 경험을 쌓는다.

5. 향후 계획(결론)

이번 프로젝트는 단순히 "취업 잘 되는 자바 스프링을 써보자"는 차원이 아니다. 2023년의 내가 겪었던 운영상의 한계(속도, 불안정성, 부정확함)를, 2025년의 내가 현대적인 아키텍처 기술(Batch, Redis, RAG)을 통해 논리적으로 해결해 나가는 과정이다.

또한, 나는 아직 RAG나 벡터 검색의 전문가가 아니다. 그렇기에 '바이브 코딩(Vibe Coding)'과 적극적인 AI 활용을 통해 모르는 기술을 빠르게 학습하고, 내 서비스에 맞게 최적화하는 과정을 가감 없이 기록할 것이다.

Future Roadmap

환경 구축: Docker Compose로 MySQL, Redis, Spring Boot, Prometheus, Grafana가 연동된 통합 환경 구축.
배치 구현: Spring Batch + Jsoup을 활용하여 '중단되어도 다시 살아나는' 크롤러 구현.
캐시 전략: Local Cache vs Redis 성능 비교 실험 및 최종 아키텍처 결정.
AI 고도화: Spring AI와 Vector Store를 활용한 RAG 파이프라인 구축 및 할루시네이션 감소율 검증.

"남들이 쓰니까 쓰는 기술"은 없다. 모든 기술 스택의 변경에는 합당한 이유가 있어야 하며, 이번 프로젝트를 통해 그 '이유'를 코드로 증명해 보이고자 한다.

깃허브 : https://github.com/kau-qj/backend

[Java] String은 참조형인데 왜 값이 안 바뀔까? – Pass by Value 와 Immutable

junju404 — Thu, 8 Jan 2026 23:50:47 +0900

1. 왜 이 글을 쓰게 되었는가

1) 글을 쓰게 된 계기

"자바의 신 Vol 1: 기초 문법편 3rd Edition"을 읽던 중에 "Pass by value" 주제에서 시작됐다. String 문자열 객체가 메서드의 매개변수로 전달되어, 해당 메서드에서 객체의 값이 수정될 거라고 생각했다. 하지만, 생각했던 것과 달리 String 문자열 객체가 변경되지 않아서 해당 개념을 바로잡고자 글을 쓰게 됐다.

2) 필자의 배경 수준

- Java : 중
- 기본 문법 이해 (코딩테스트 주력 언어)
- 프로젝트 경험 보유
- 기본형 / 참조형 자료형 구분
- JVM 메모리 구조(T구조 - 스택, 힙, 스태틱) 얕게 이해

2. 문제 상황과 코드

public class ReferencePass {
    public static void main(String[] args) {
        ReferencePass referencePass = new ReferencePass();
        referencePass.callPassByValue();
    }

    public void callPassByValue() {
        int a = 10;
        String b = "b"; // 2-1
        
        passByValue(a, b); // 2-2
        
        System.out.println(a); // 2-4
        System.out.println(b);
    }

    public void passByValue(int a, String b) {
        a = 20;
        b = "z"; // 2-3
    }
}

출력 결과

before passByValue
a = 10
b = b
in passByValue
a = 20
b = z
after passByValue
a = 10
b = b

해당 예제에서 헷갈렸던 점은 String 이 참조 자료형인데,
메서드 내부에서 값을 변경했을 때 호출한 쪽의 값이 변경되지 않는다는 점이다.

기본 자료형의 경우 값이 복사되어 전달되기 때문에 변경되지 않는다는 것은 알고 있었지만,
String 은 객체라서 메서드 내부에서 값을 변경하면 호출한 쪽에서도 변경될 것이라고 예상했다.

하지만, 실제 실행 결과는 예상과 달랐고,
이 차이가 어디에서 발생하는지 JVM 메모리 관점에서 확인해볼 필요가 있었다.

3. JVM 메모리 관점에서의 실행 흐름

1) callPassByValue() 초기 상태

1. callPassByValue 메서드의 스택 프레임이 생성된다.

2. 정수형 자료형(기본 자료형)인 a 변수에는 10을 가리키고, 문자열 객체(참조 자료형)인 b 의 주소값은 String Pool(Heap)에 존재하는 "b" 객체를 가리키는 참조값을 가진다.

2) passByValue() 호출 직후

1. passByValue 메서드의 스택 프레임이 생성된다.

2. 매개변수로 전달받아서, 해당 스택 프레임의 a 라는 정수형 자료형 지역변수가 존재하고, 값은 10으로 초기화한다. b 라는 지역변수도 존재하는데, 문자열 객체로써 주소값은 Heap 의 "b" 를 참조한다.

3) passByValue() 내부에서 재할당

1. passByValue 메서드에서 지역변수 a의 값을 20으로 수정하고, 지역변수 b의 주소값을 "z" 라는 객체로 재할당한다.

4) passByValue() 종료 후

1. passByValue 메서드가 종료되어, 해당 스택 프레임은 소멸된다.

2. 다시 callPassByValue 메서드의 스택 프레임에서 코드를 진행하도록 한다.

4. Mutable 참조 자료형

위의 예제에서는 String 객체를 매개변수로 전달했을 때 값이 변경되지 않는 이유를 확인했다. 하지만, 참조 자료형이지만 배열이나 DTO와 같은 객체를 매개변수로 전달하면 메서드 호출 이후 값이 변경되는 경우가 있었다.

"Java의 Pass by Value 가 지켜지지 않았다"가 아니라, 객체의 가변성 여부에 따른 차이이다.

다음 두 가지 코드를 살펴보자.

첫 번째는 자바 패턴 중 하나인 "DTO"이다.

public class ReferencePass2 {
    public static void main(String[] args) {
        ReferencePass2 referencePass2 = new ReferencePass2();
        referencePass2.callPassByReference();
    }

    public void callPassByReference() {
        MemberDTO MemberDTO = new ReferencePass2("Sangmin");
        System.out.println("before passByReference");;
        System.out.println("member.name : " + MemberDTO.name);
        passByReference(MemberDTO);
        System.out.println("after passByReference");
        System.out.println("memberDTO.name : " + MemberDTO.name);
    }

    public void passByReference(MemberDTO member) {
        member.name = "sungChoon";
        System.out.println("in passByReference");
        System.out.println("memberDTO.name : " + member.name);
    }
}

출력 결과

before passByReference
member.name = Sangmin
in passByReference
member.name = SungChoon
after passByReference
member.name = SungChoon

DTO 객체 역시 내부 필드를 변경할 수 있는 가변 객체일 경우에 가능하다. 메서드 내부에서 member.name = "xxx" 처럼 참조 변수를 재할당하는 것이 아니라, 참조가 가리키는 객체의 필드를 직접 수정하는 연산이다.

이로 인해 메서드 호출 이후에도 호출자 측에서 변경된 필드 값을 확인할 수 있다.

두 번째는 자바의 "정수형 배열"이다.

public class ReferencePass3 {
    public static void main(String[] args) {
        int[] arr = {0, 1, 2};
        ReferencePass3 referencePass3 = new ReferencePass3();
        for (int num : arr) System.out.print(num + " ");
        System.out.println();
        referencePass3.callPassByReference(arr);
        for (int num : arr) System.out.print(num + " ");
        System.out.println();
    }

    public void callPassByReference(int[] arr) {
        System.out.println("method start!!");
        arr[0] = 100;
        System.out.println("method end!!");
    }
}

출력 결과

0 1 2 
method start!!
method end!!
100 1 2

배열 또한 참조 자료형이므로, 메서드 호출 시 배열 객체 자체가 전달되는 것이 아니라 배열을 가리키는 참조값이 복사되어 전달된다.

이 때, arr[0] = 100 과 같은 코드는 참조 변수 arr 를 다른 객체로 재할당하는 것이 아니라, arr 가 가리키는 배열 객체 내부의 상태를 변경하는 연산이다.

따라서, 메서드 호출이 종료된 이후에도 동일한 배열 객체를 참조하고 있는 호출자 측에서는 변경된 결과를 확인할 수 있다.

이처럼 Java 에서는 참조 자료형이더라도 메서드 호출 시 참조 자체가 전달되는 것은 아니다. 전달되는 것은 항상 참조값의 복사본이다. (Pass By Value)
다만, 해당 참조값이 가리키는 객체가 내부 상태를 변경할 수 있는 Mutable 객체라면 메서드 호출 이후에도 결과가 변경될 수 있다.

5. 결론

이번 글에서는 참조 자료형인 String이 메서드 내부에서 값이 변경되지 않는 이유를 Pass by Value 와 JVM 메모리 구조 관점에서 정리했다.

Java는 메서드 호출 시 항상 인자를 값으로 전달하며, 참조 자료형 역시 객체 자체가 아닌 참조값이 복사되어 전달된다.
이로 인해, 메서드 내부에서 참조 변수를 다른 객체로 재할당하더라도 호출한 쪽의 참조에는 영향을 주지 않는다.

반면, 배열이나 DTO처럼 내부 상태를 변경할 수 있는 mutable 객체의 경우,
메서드 내부에서 객체의 필드를 수정하면 동일한 객체를 참조하고 있는 호출자 측에서도 변경된 결과를 확인할 수 있다.

결국, 참조 자료형의 변경 여부는 Pass by Value 규칙의 예외가 아니라,
객체의 가변성 여부에 따른 결과 차이라고 이해할 수 있다.

깃허브 주소 : https://github.com/ParkJunGyu26/TIL/tree/main/Java/java-pass-by-value

[백준] 34204번 가방

junju404 — Sun, 4 Jan 2026 08:18:00 +0900

문제

가방

문제 난이도

골드 4

알고리즘 태그

투포인터, 슬라이딩윈도우, 그리디(정렬)

이 문제를 왜 풀게 됐는가?

문제 지문이 길거나 또는 문제 지문에서 생각을 요구하는 문제를 풀고 싶었다.

이 전에는 문제의 지문이 짧아서, '이 문제의 알고리즘은 무엇일까?'라는 생각을 먼저 했다.
하지만, 2025년부터 기업의 코딩테스트는 문제의 독해력도 요구하는 것 같았다. 기업에서 코딩테스트를 통해 이제는 요구하는 바가 '요구사항을 정확하게 이해하고 있는가?'와 '이 문제의 알고리즘을 알고 있는가?' 인 것 같다.

그리고, 프로그래머스를 풀면서 더 많은 문제를 풀어보고 싶었다. 프로그래머스와 가장 유사하게 "부분 점수"도 있기 때문에 연습하기 가장 좋다고 생각했다.

독해력 연습과 부분 점수를 고려하고자 백준의 한국정보올림피아드 문제 를 풀어보게 됐다.

문제 소개

상훈은 최대한 김기범이 최댓값 가지도록 최선을 다 한다.
기범은 주어진 K 개를 훔치지만, 그 값이 최솟값 가지도록 최선을 다 한다.

상훈이가 가방에 담을 수 있는 물건은 무게 합이 x 이하만 가능하다.
기범이는 훔쳐가는 물건 무게 합 최대값 출력

남겨진 물건의 개수가 K 개 미만인 경우에는 기범이는 모두 훔친다.

문제를 어떻게 접근했는가?

지문을 명확하게 이해해야되고, 예제 케이스 3개가 어떠한 원리로 출력되는지 이해하는 게 가장 중요했다.

도둑 김기범은 가게에서 K개의 물건을 훔쳐갈 것인데, 
물건이 무거울 경우 훔쳐가기 어렵고 경찰한테 걸릴 가능성이 높다. 
고로, 도둑 김기범은 훔쳐가는 물건의 무게의 합을 최소화한다. 
만약 가게에 있는 물건의 개수가 
K개 미만일 경우, 도둑 김기범은 가게에 있는 모든 물건을 훔쳐간다.

상훈이는 도둑 김기범이 가게를 도착하기 전에, 
가방에 상점의 물건들을 몇 개 담아서 들고 갈 것이다. 
이후, 도둑 김기범은 상훈이가 들고 가지 않은 물건들에 대해 위에 설명한 방식으로 범죄를 저지른다. 
상훈이는 가방에 물건을 적당히 담아서 도둑 김기범이 훔쳐가는 물건의 무게 합을 최대화하려고 한다.

주어진 지문에 앞 부분에는 기범의 무게 합을 최소화한다고 나와있고, 지문의 뒷 부분에는 기범의 무게 합을 최대화 한다고 주어졌다.
그래서 이를 각 주체마다 목표점을 정리했다.

기범은 주어진 상황에서 훔칠 물건의 무게를 최소화할 것이다.
상훈은 주어진 상황에서 남겨진 물건의 무게를 최대화할 것이다.

그래서, 결론은 최댓값의 기범의 무게를 각 무게 제한별로 출력하는 것으로 이해했다.

N 개의 물건은 오름차순으로 주어진다는 보장이 없기 때문에 오름차순으로 정렬했다.
투포인터 역할을 하는 left, right 를 설정한다. left 는 기범이가 훔칠 물건의 가장 작은 인덱스를 뜻하고, right 는 기범이가 훔칠 물건의 가장 큰 인덱스를 뜻한다. 그렇다면, 문제 지문에 적용한다면 상훈이는 무게 제한이 x일 때, 물건을 0번 물건부터 left-1번 물건까지 누적해서 가방에 넣을 것이다. 반면에, 기범이는 무조건 k 개를 훔치되, 주어진 물건 중에서 가장 작은 k 개를 훔칠 것이다.
right 가 마지막 물건을 가리키고 있을 때는 더 이상 right 를 증가할 수 없기 때문에, 그 미만인 경우에만 left 와 right 를 수정한다.

여기에서 헷갈렸던 부분은 예제 3의 출력값이었다.

[input]
3 2 3
1 1 7

[output]
8
8
8

x 가 1일 때는, 8인 걸 이해했지만, x 가 2일 때도 왜 8이 출력되는지 이해가 안됐다.
첫 번째 나의 생각은 '1 1 을 가져가면, 7 아닌가?' 이었다.
하지만, 이것은 잘못됐다. 우리가 출력해야되는 건 "상훈"이 입장에서는 "기범"이의 값이 최대한 값이 커야된다. 따라서, 상훈이가 1 1 을 "가져갈 순 있지만, 1만 가져간다면 기범이는 무조건 8을 가져갈 수 밖에 없다"

두 번째 생각은 '그러면, 하나도 안가져가면 9 아닌가?' 이었다.
하지만, 이것도 잘못됐다. 이번에는 "기범"이의 입장에서 무조건 2개를 가져갈 것이고, 그렇다면 기범이는 최선을 다 해서 가장 작은 값 2개를 가져갈 것이다. 그러면, 1 1 을 기범이가 훔쳐서 2가 출력될 것이다.

이러한 고민을 통해서 반례에 대해 조금 더 꼼꼼하게 생각해볼 수 있었다.

한 번에 맞추지 못한 이유는?

주어진 출력의 범위는 C 만큼 출력해야되는데, 그 출력을 루프에서 진행했기 때문이다.

정답 코드(StringBuilder / StringBuffer / BufferedWriter)

import java.io.*;
import java.util.*;

// 상훈이 가방 담을 수 있는 물건 무게 합 x 이하
// 도둑 김기범이 훔쳐가는 물건 무게 합 최대값 출력

// 상훈은 최대한 김기범이 최댓값 가지도록 최선을 다 한다.
// 기범은 최솟값 가지도록 최선을 다 한다.
public class Main {
    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()); // 상점의 물건 개수 (배열) <= 5000
        int k = Integer.parseInt(st.nextToken()); // 도둑 김기범이 훔쳐갈 물건 개수 <= 5000
        int c = Integer.parseInt(st.nextToken()); // 상훈이 가방 무게 최댓값 <= 1_000_000
        int[] A = new int[n];
        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < n; i++) A[i] = Integer.parseInt(st.nextToken());
        Arrays.sort(A); // 오름차순 정렬

        long kibeom = 0L;
        int left = 0;
        int right = k-1;
        for (int i = 0; i < Math.min(k, n); i++) kibeom += A[i];

        StringBuffer sb = new StringBuffer();
        // StringBuffer sb = new StringBuffer();
        // BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
        long sanghoon = 0L;
        for (int x = 1; x <= c; x++) {
            // 상훈이가 먼저 가방 세팅
            if (sanghoon + A[left] <= x) { // 가방에 더 넣을 수 있음(can)
                // 기범이 물건 훔치기
                if (right - left + 1 == k) {
                    if (right < n-1) {
                        sanghoon += A[left];
                        kibeom -= A[left++];
                        kibeom += A[++right];
                    }
                }
            }
            sb.append(kibeom).append("\n");
            // bw.write(String.valueOf(kibeom));
            // bw.write("\n");
        }
        System.out.println(sb);
        // bw.flush();
        // bw.close();
    }
}

오답 코드(루프에서 바로 출력)

import java.io.*;
import java.util.*;

// 상훈이 가방 담을 수 있는 물건 무게 합 x 이하
// 도둑 김기범이 훔쳐가는 물건 무게 합 최대값 출력

// 상훈은 최대한 김기범이 최댓값 가지도록 최선을 다 한다.
// 기범은 최솟값 가지도록 최선을 다 한다.
public class Main {
    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()); // 상점의 물건 개수 (배열) <= 5000
        int k = Integer.parseInt(st.nextToken()); // 도둑 김기범이 훔쳐갈 물건 개수 <= 5000
        int c = Integer.parseInt(st.nextToken()); // 상훈이 가방 무게 최댓값 <= 1_000_000
        int[] A = new int[n];
        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < n; i++) A[i] = Integer.parseInt(st.nextToken());
        Arrays.sort(A); // 오름차순 정렬

        long kibeom = 0L;
        int left = 0;
        int right = k-1;
        for (int i = 0; i < Math.min(k, n); i++) kibeom += A[i];

        long sanghoon = 0L;
        for (int x = 1; x <= c; x++) {
            // 상훈이가 먼저 가방 세팅
            if (sanghoon + A[left] <= x) { // 가방에 더 넣을 수 있음(can)
                // 기범이 물건 훔치기
                if (right - left + 1 == k) {
                    if (right < n-1) {
                        sanghoon += A[left];
                        kibeom -= A[left++];
                        kibeom += A[++right];
                    }
                }
            }
            System.out.println(kibeom);
        }
    }
}

1. StringBuffer 사용 / 2. BufferedWriter 사용 / 3. System.out.println() 사용 (53점) / 4. StringBuilder 사용

주어진 케이스 외의 반례

문제 후기

타입 주의 (long 인가? int 인가?)

누적하는 값이 1_000_000 * 5_000 는 5_000_000_000 가 된다. Java 에서 int 범위는 약 21억까지 가능하므로, int 보다는 long 으로 타입을 설정했다.

문제 중심으로 이해하기 (나의 생각이 맞는데? 보다는 주어진 예시가 어떠한 원리로 나왔고, 그 원리가 모두 동일한지)

풀고나서 보니 현대오토에버 3분기 코테, 싸피 14기 코테에서 나의 독해력의 개선점과 유사했다.
'나의 풀이가 맞는데, 왜 결과가 틀렸지(다르지)?' 라는 식으로 생각하며 시간을 많이 낭비했다. 그래서, 그 이후부터는 주어진 예제 케이스를 중심으로 먼저 이해하도록 노력하고 있다.

[백준] 15900번 나무 탈출

junju404 — Thu, 1 Jan 2026 21:20:15 +0900

문제

백준 15900번 나무 탈출

문제 난이도

실버 1

알고리즘 태그

그래프 탐색, BFS, 트리

문제 소개

성원이와 형석 두 사람이 게임을 진행한다. 게임은 성원이가 먼저 시작한다.
게임 방식은 리프 노드에서 게임말을 한 칸씩 부모 노드(루트 노드는 반드시 1)로 이동한다. 만약, 리프 노드에서 출발한 게임말이 1번 노드를 만나게 되면 해당 게임말은 사라진다. 이러한 방식을 진행 중에, 모든 게임말이 사라졌을 때, 해당 차례의 사람은 게임에서 지는 것이다.
특정 노드에서는 게임말이 여러 개가 될 수 있다.

입력은 처음에 N 을 입력받고(노드 개수),
그 다음 (N-1)개 만큼의 두 숫자를 입력받는다. 이 두 숫자는 노드를 뜻하고, 서로 연결됨을 뜻한다.(엣지 개수 = (N-1))

출력은 성원이가 게임에서 항상 이긴다면 "Yes"를,
성원이가 게임에서 항상 진다면 "No"를 출력한다.
(성원이와 형석이 모두 최선의 결과를 나타내도록 할 것이다)

이 문제를 왜 풀게 됐는가?

프로그래머스 홀짝트리 문제를 못 풀어서, 이와 유사한 문제를 제미나이에게 추천해달라고 했다. 그래서, 유사한 문제 중 백준에서 풀게 됐다.

문제를 어떻게 접근했는가?

리프 노드의 개수와 엣지(경로) 개수의 합이 홀짝인 경우에 Yes/No 인가?

-> 아래에 있는 반례 케이스 때문에 아닌 것을 알게 됐다. 주어진 예제 케이스에는 단순하게 {리프 노드 개수 + 엣지 개수(n-1)} 가 짝수라면 "No", 홀수라면 "Yes"가 출력됐다.

각 리프 노드에서 1번 노드까지의 거리의 합이 홀짝인 경우에 Yes/No 인가?

-> 이 경우가 문제의 정답이다.

각 리프노드에서 1번 노드까지 올라가는 경우 중복되는 경우가 있다. 그렇다면, O(리프노드 수 * N) 은 시간초과가 발생할 수 있을 것 같다.
1번 노드(루트 노드)에서 리프 노드까지 단 한 번만 탐색하는 경우에는 시간복잡도가 O(N) 만 발생할 것이다. 그렇다면, 이렇게 풀면 시간복잡도는 안전하다.
각 노드에는 1번 노드와의 거리를 저장한다.
각 리프 노드의 1번 노드와의 거리를 모두 누적하여, 홀/짝을 판별하여 답을 출력한다.

정답 코드(BFS)

시간복잡도 : O(N)

import java.io.*;
import java.util.*;

public class Main {
    static int n;
    static int[] visited;
    static ArrayList<ArrayList<Integer>> edge;

    // 엣지 수 + 리프 수 가 홀수라면, 성원이가 진다?

    // 루트 노드 : 1번 노드
    // 리프 노드 : 자식 없는 노드
    // 성원이가 먼저 시작
    // 루트 노드의 값이 짝수면 지는거임
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        n = Integer.parseInt(br.readLine());
        visited = new int[n+1];
        Arrays.fill(visited, -1);
        edge = new ArrayList<>();
        for (int i = 0; i <= n; i++) edge.add(new ArrayList<>());

        for (int i = 1; i < n; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            int a = Integer.parseInt(st.nextToken());
            int b = Integer.parseInt(st.nextToken());

            edge.get(a).add(b);
            edge.get(b).add(a);
        }

        ArrayDeque<Integer> q = new ArrayDeque<>();
        q.offer(1);
        visited[1] = 0;
        ArrayList<Integer> leaf = new ArrayList<>();
        while (!q.isEmpty()) {
            int cur = q.poll();
            boolean isLeaf = true;

            for (int next : edge.get(cur)) {
                if (visited[next] != -1) continue;

                isLeaf = false;
                visited[next] = visited[cur]+1;
                q.offer(next);
            }

            if (isLeaf) leaf.add(cur);
        }

        int answer = 0;
        for (int l : leaf) answer += visited[l];
        if (answer % 2 == 0) System.out.println("No");
        else System.out.println("Yes");
    }
}

오답 코드(BFS)

시간복잡도 : O(N * l(리프 노드 수))

import java.io.*;
import java.util.*;

public class Main {
    static int n;
    static ArrayList<ArrayList<Integer>> edge;

    // 엣지 수 + 리프 수 가 홀수라면, 성원이가 진다?

    // 루트 노드 : 1번 노드
    // 리프 노드 : 자식 없는 노드
    // 성원이가 먼저 시작
    // 루트 노드의 값이 짝수면 지는거임
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        n = Integer.parseInt(br.readLine());

        edge = new ArrayList<>();
        for (int i = 0; i <= n; i++) edge.add(new ArrayList<>());

        for (int i = 1; i < n; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            int a = Integer.parseInt(st.nextToken());
            int b = Integer.parseInt(st.nextToken());

            edge.get(a).add(b);
            edge.get(b).add(a);
        }

        int answer = 0;
        for (int i = 2; i <= n; i++) {
            // 리프 노드의 경우
            if (edge.get(i).size() == 1) {
                int[] visited = new int[n+1];
                Arrays.fill(visited, -1);
                ArrayDeque<Integer> q = new ArrayDeque<>();

                q.offer(i);
                visited[i] = 0;
                while (!q.isEmpty()) {
                    int cur = q.poll();

                    if (cur == 1) {
                        answer += visited[cur];
                        break;
                    }

                    for (int next : edge.get(cur)) {
                        if (visited[next] != -1) continue;

                        visited[next] = visited[cur]+1;
                        q.offer(next);
                    }
                }
            }
        }

        if (answer % 2 == 0) System.out.println("No");
        else System.out.println("Yes");
    }
}

시간초과 : 두번째 풀이

주어진 케이스 외의 반례

문제 후기

우연히, 해당 문제는 최근에 풀었던 현대오토에버 4분기 공채의 코테에서 나의 풀이 중 개선점과 유사했다.
자세하게 얘기할 순 없지만, "트리"라는 것은 방향이 정해져있긴 하지만, 루트 노드에서 출발할 지? 또는 리프노드에서 출발할 지? 에 따라 시간복잡도가 달라진다.
해당 문제에서는 루트 노드에서 시작했고, 단 한 번의 탐색만 진행하기 때문에 시간복잡도는 O(N)이다.
하지만, 리프 노드에서 시작할 경우에는 O(N * 리프노드 수) 가 발생한다.

이전에 현대오토에버 코테에서는 시야가 좁았던 것 같다. 조금 더 시야를 넓혀서, 무조건적인 시야 보다는 조금 더 유연하게 접근하자.

[자격증] PCCP Java Lv5 후기

junju404 — Sun, 21 Dec 2025 18:06:11 +0900

1. 결과

필자의 알고리즘 상태는 백준 기준(solved)으로는 플레티넘4이고, 백준 문제 기준으로 평균적으로 골드4까지는 풀 수 있다(?) 고 생각한다.

알고리즘 유형별로 DP, 그리디, 누적합 같은 문제는 골드5...?까지인 것 같고, 그래프(DFS, BFS, 최단경로)는 원래부터 난이도가 높아서 골드3 정도..? 그래서 평균 골드 4까지는 풀 만 하다고 생각했다.

앳코더나 코드포스는 Div4 기준으로는 평균적으로 3문제 정도 푸는 것 같다. (앳코더로는 갈색..? 고점 뜨면 초록..ㅠ)

2. 응시 배경

프로그래머스에서 PCCP(Java) 를 응시한 가장 큰 이유는 "코테 실전 경험"이다.

1. 2025년 하반기 종료

코딩테스트에 대한 무료(?) 실전 경험을 위해서 여러 기업들의 공채에 많이 지원했다.

- 프로그래머스 : 토스, 카카오, 현대캐피탈, 한국자금중개, 현대오토에버

- 잡다 : 마이다스아이티

- YBM COS Pro : 다우기술

내가 응시했던 코딩테스트 플랫폼만 봐도, 대부분 프로그래머스에서 진행하는 것을 알 수 있다. 하지만, 이제 2025년 하반기는 끝이 났고, 더이상 응시할 수 있는 기업은 없다..

어쩔 수 없이 이제는 유료(?) 실전 경험을 위해서 5만원을 결제해서 응시하게 됐다.

2. 코딩테스트 플랫폼 적응

위에서 보듯이, 이제는 코딩테스트 플랫폼은 프로그래머스가 독보적인 것 같다. 실전 감각을 꾸준히 익히기 위해서 응시했다.

그리고 프로그래머스에서 코딩 테스트를 응시해보면 알 수 있지만, 학창 시절의 국어 비문학 독해 느낌이 많이 느껴졌다.

더군다나 필자는 비문학 독해 능력이 부족하다고 생각해서 이제는 프로그래머스에서만 연습하고 있다.

백준도 충분히 문제 은행(양치기)에서는 정말 많은 득을 봤다. 하지만, 이제는 실전 감각과 독해 능력(문제 읽는)을 기르기 위해서 프로그래머스에서 실전 감각을 익히고 있다.

3. 유일한? 코테 역량 자격증

작년까지만 해도 "소프티어"에 꾸준히 도전했었다. 하지만, 올해부터 서비스가 종료되었다.

그래서, 앳코더, 코드포스 등 여러 모의 테스트를 쳐봤지만 영어로 된 걸 다시 한국어로 번역하는 것도 귀찮고, 시간 분배에는 도움이 됐지만 뭔가 모를 아쉬움이 있었다.

그래서, 우연히 프로그래머스의 PCCP 자격증 이라는 걸 알게 됐고, 처음이자 마지막으로 도전해보고 싶었고 현재 나의 알고리즘 레벨 상태도 궁금하기도 했다.

3. 시험 준비 과정

따로 "PCCP 를 위해 준비해야겠다!" 라는 건 없었다.

최근 일주일 동안, 코드트리에서 "DP", "BFS", "DFS" 부분에 대해 특정 유형별(HARD)로 학습 중이긴 했다.

해당 유형들이 다 출제되진 않았지만 어느 정도는 도움이 된 것 같고, 감각도 조금씩 돌아오고 있는 상태인 것 같다.

시험 전날, 프로그래머스에서 보니깐 "PCCP 기출 문제" 로 따로 공개된 것을 발견했다. 만약 준비하시는 분들이 있다면 해당 문제들을 한 번씩 풀어보면 도움이 될 것 같다.

4. 시험 후기

어떤 문제가 나왔는지 구체적으로 얘기할 순 없지만, 위의 공개된 문제처럼 Lv1, Lv2, Lv2, Lv3 으로 배치된 것 같다.

수학적인 계산 및 구현, 자료구조, 그래프 탐색, DP 이 정도로 나온 것 같다.

코테에서는 항상 "DP"는 어렵지만, 요즘은 단골로 출제되는 것 같다. 그래서, DP에도 여러 유형들이 나뉘어지는 것 같은데 여러 DP 를 풀어보는 것도 중요할 것 같다!!

문제를 풀 때는, 종이를 적극적으로 활용하고, 그리고 주석으로 한 번 더 방향성을 잡는 것도 중요한 것 같다.

무작정 문제를 풀기 보다는 문제 지문(요구사항)을 한 번 더 정리하고, 문제를 천천히 이해하는 것이 중요하다.

그리고, 문제에서는 어떠한 알고리즘을 사용할 수 있을지 후보군으로 한 번 필터링한다. (ex) 완전탐색은 안된다 등)

점수는 1000점 만점인데, 910점으로 나름 커트라인에 걸치긴 했다.

아마, 900점 이상인 이유는 시간복잡도나 공간복잡도 등 효율성 및 정확도는 정답인 거 같긴한데.. 감점된 이유는 조금 더 최적화된 방법이 있는 것 같다.

다른 사람들 후기에는 1000점(만점), 945점 등 부분점수를 주는데, Lv5 이상 범위를 적은 것 보니 정답이긴 한데 조금 더 노력해보라 라는 느낌이지 않을까 개인적인 생각이다..!

시험 치기 전에도 느꼈고, 시험이 끝난 후에도 느낀 점은 '이제 문제에 대해 어떻게 접근하고, 이러한 알고리즘을 쓰면 풀릴 거 같다. 근데, 이걸 어떻게 구현해야될까?' 이다. 확실히 "구현력"에 대한 부족함이 있다는 걸 느꼈지만, 조금 더 구체적으로 파고든다면, '해당 알고리즘을 어떻게 구현할까?' 라는 부분도 보완해야된다고 느꼈다.

코드트리(HSAT 기출, 삼성 기출, 유형별 학습)으로 조금 더 보완해나가면 더 괜찮아질 것 같다!

여담이긴 하지만, 최근에 hsat을 검색했다가 "소프티어"에서 "NGV 캠퍼스"로 다시 오픈(?)된 것 같다..! 아마 조만간 소프티어 자격증도 돌아올 거 같다.

[자료구조] 우선순위 큐 삽입 순서 - “소 잃고 외양간 고치지 말자!”

junju404 — Tue, 12 Aug 2025 19:31:10 +0900

문제 상황

백준 1005번 문제를 풀다가 우선순위 큐를 사용해서 위상정렬을 구현했다. 코드를 완성하고 팀원과 비교해보니 둘 다 같은 답을 출력하는데, 우선순위 큐에 값을 넣는 부분의 코드 순서가 다르더라.

처음엔 그냥 스타일 차이라고 생각했는데, 자세히 보니 정렬 기준이 되는 값을 초기화하는 시점이 달랐다. 나의 실수를 기록하고, 이를 파고들어 정리하고자 한다.

코드 비교 : 어디가 다른가

// 내 코드
for (int i = 1; i <= n; i++) {
    if (inDegree[i] == 0) {
        q.offer(i);           // 우선순위 큐에 먼저 삽입
        answer[i] = res[i];   // 나중에 정렬 기준값 초기화
    }
}

// 팀원의 코드
for (int i = 1; i <= n; i++) {
    if (inDegree[i] == 0) {
        answer[i] = res[i];   // 먼저 정렬 기준값 초기화
        q.offer(i);           // 나중에 우선순위 큐에 삽입
    }
}

두 코드 모두 결과적으로 같은 동작을 하는 것처럼 보인다. 하지만 이 순서 차이는 생각보다 중요했다.

근본 원인 : PriorityQueue와 힙의 관계

이 의문을 풀려면 Java의 PriorityQueue가 어떻게 구현되어 있는지 알아야 했다.

1) PriorityQueue의 내부 구조

Java의 PriorityQueue는 내부적으로 이진 힙(binary heap) 자료구조를 사용한다. 우선순위를 효율적으로 관리하기 위해 배열 기반의 완전 이진 트리 형태로 구현된 것인데, 이것이 핵심이다.

힙의 특징

완전 이진 트리 형태: 모든 레벨이 왼쪽부터 차곡차곡 채워짐
Min-heap : 부모 노드 ≤ 자식 노드 (루트가 항상 최솟값)
배열 표현 : 인덱스 i에서
- 왼쪽 자식 : 2*i + 1
- 오른쪽 자식 : 2*i + 2
- 부모 : (i-1) / 2

이 구조 덕분에 최솟값을 O(1)에 찾고, 삽입과 삭제도 O(log n)에 처리할 수 있다.

2) 힙이 우선순위를 유지하는 방식

여기가 핵심이다. 힙이 항상 우선순위 조건을 만족하려면 두 가지 핵심 연산을 수행해야 한다.

삽입할 때(Sift-Up)

새 원소를 배열 끝에 추가
부모와 비교해서 조건을 만족할 때까지 위로 올린다
올바른 위치를 찾을 때까지 반복

삭제할 때(Sift-Down)

루트(최솟값)를 제거
배열 마지막 원소를 루트 자리에 이동
자식들과 비교해서 조건을 만족할 때까지 아래로 내린다
올바른 위치를 찾을 때까지 반복

가장 중요한 포인트는 이것이다

이 연산들은 삽입과 삭제 순간에만 일어난다.

한 번 배치가 끝나면, 외부에서 아무리 값이 바뀌어도 힙은 그 변화를 감지하지 않는다는 뜻이다.

내가 놓친 부분

이제 내 실수가 무엇인지 명확해진다.

나는 무의식적으로 이렇게 가정했다

"인덱스 i를 큐에 넣고, 나중에 answer[i] 값을 업데이트하면 힘이 그 변화를 감지해서 자동으로 재배치하지 않을까?"

하지만 이건 완전한 오해였다.

내 코드의 실행 흐름

[초기 상태]
answer = [0, 0, 0, ...]

[Step 1] q.offer(i) 호출
  ├─ PriorityQueue: "이제 삽입합니다"
  ├─ answer[i]의 현재값 확인: 0
  ├─ Sift-Up 수행: 0 값 기준으로 배치
  └─ 배치 완료 ✓

[Step 2] answer[i] = res[i] 실행
  ├─ answer 배열 값 변경 (0 → 5)
  ├─ PriorityQueue: (감지 안 함)
  └─ 힙 구조 유지 (그대로)

팀원 코드의 실행 흐름

[Step 1] answer[i] = res[i] 실행
  └─ answer 배열 값 세팅: 5

[Step 2] q.offer(i) 호출
  ├─ PriorityQueue: "이제 삽입합니다"
  ├─ answer[i]의 현재값 확인: 5
  ├─ Sift-Up 수행: 5 값 기준으로 배치
  └─ 배치 완료 ✓

차이가 극명하다. 내 코드는 잘못된 기준(0) 으로 배치했고, 팀원 코드는 올바른 기준(5) 으로 배치했다. 나중에 내가 값을 바꿔도, 이미 정해진 힙 구조는 변하지 않는다.

왜 이 차이가 눈에 띄지 않았나

흥미로운 점은 두 코드 모두 같은 정답을 출력했다는 것이다.

이번 문제(ACM Craft)의 특수한 성질 때문인 것 같다. 위상정렬에서 여러 원소가 동시에 처리될 수 있는 상황에서, 초기 배치 순서가 조금 이상해도 최종 결과는 같을 수 있기 때문이다. 즉, 내 코드도 잘못된 배치에도 불구하고 우연히 맞는 답을 도출한 셈이다.

하지만 이건 운이 좋았던 것이지, 근본적인 해결책이 아니다. 다른 문제나 다른 상황에서는 이 순서 차이가 명백한 오류로 드러날 가능성이 높다.

올바른 사용 방식

이제 답은 명확하다.

정렬 기준이 되는 값을 먼저 초기화한 후, 우선순위 큐에 삽입한다.

for (int i = 1; i <= n; i++) {
    if (inDegree[i] == 0) {
        answer[i] = res[i];   // 기준값 준비
        q.offer(i);           // 올바른 값 기준으로 삽입
    }
}

이렇게 하면 Sift-Up이 수행될 때, 정렬 조건이 이미 올바르게 반영된 상태에서 시작된다. 의도한 대로 정확하게 동작한다.

결론 : 자료구조의 동작 원리를 무시하면 안 된다

이번 경험을 통해 얻은 교훈을 정리하면 이렇다.

1. PriorityQueue는 정렬된 리스트가 아니다

완전히 정렬된 상태를 유지하지 않는다
오직 루트가 최솟값이라는 조건만 보장한다

2. 힙의 배치는 삽입/삭제 순간에만 결정된다

외부에서 값이 바뀌어도 자동으로 재배치되지 않는다
한 번 Sift-Up이 끝나면, 그 이후 구조는 변하지 않는다

3. 삽입 시점이 모든 것을 좌우한다

그 순간의 값이 힙 구조 전체를 결정한다
정렬 기준이 되는 값은 반드시 삽입 전에 준비되어야 한다

"대충" 코드를 짜면 우연히 맞을 수도 있다. 하지만 자료구조의 원리를 제대로 이해하지 못하면, 언제든 그 우연이 깨질 수 있다. 이번 발견 덕분에 PriorityQueue를 더 정확하게 사용할 수 있게 되었고, 앞으로 비슷한 함정에 빠지지 않을 것 같다.

[Java] 스프링 입문을 위한 자바 객체 지향의 원리와 이해 2장 - 자바와 절차적/구조적 프로그래밍 - T메모리

junju404 — Mon, 23 Jun 2025 22:38:59 +0900

안녕하세요! 이번 글에서는 자바의 프로그램 실행 구조에서 메모리는 어떻게 사용되는가, 그리고 그 기반이 되는 절차적/구조적 프로그래밍 유산에 대해 살펴보겠습니다.

특히 자바의 실행 환경(JVM)이 어떻게 메모리를 나누고 관리하는지 이해하는 것은,

이후 객체지향과 스프링의 구조를 파악하는 데도 큰 도움이 됩니다.

T메모리란?

T메모리는 JVM이 자바 프로그램을 실행할 때 사용하는 메모리 구조입니다.

이 구조는 크게 세 가지 영역으로 나뉘며, 스레드(Thread) 단위로 생성되기 때문에 T메모리(Thread Memory)라고 부릅니다.

메모리 영역	설명
static 영역	클래스와 static 멤버들이 올라가는 공간
stack 영역	메서드 호출 시 생성되는 지역 변수 공간
heap 영역	new로 생성한 객체들이 저장되는 공간

static 영역 – 클래스의 놀이터

public class Counter {
    static int count = 0;
}

클래스나 static 멤버는 처음 호출될 때 JVM의 static 영역에 로드됩니다.
static 멤버는 프로그램 어디서든 접근 가능하여, 전역 변수처럼 사용됩니다.
단, 이로 인해 스레드 간 공유되어 동시성 문제 발생 가능성이 있습니다.

static 변수는 되도록 사용을 최소화하고,

읽기 전용으로 사용할 경우 final static 상수로 선언하는 것이 좋습니다.

stack 영역 – 메서드의 놀이터

public static void main(String[] args) {
    int a = 10;
    String name = "Java";
}

메서드가 호출되면 스택 프레임이 생성되어, 지역 변수들이 저장됩니다.
메서드가 종료되면 해당 스택 프레임은 자동으로 소멸합니다.
기본형 타입은 값 자체가 저장, 참조형은 주소값이 저장됩니다.

int x = 5;          // 값 저장
String str = "Hi";  // 주소값 저장 → 실제 객체는 heap에 존재

내부 블록(if, for 등)에서 선언된 변수는 해당 블록의 스택 프레임에만 존재합니다.

heap 영역 – 객체의 놀이터

User user = new User("Alice");

new 키워드를 통해 생성된 객체 인스턴스가 저장됩니다.
인스턴스 필드들은 모두 heap 영역에 존재하며, GC(Garbage Collector)가 관리합니다.
더 이상 참조되지 않는 객체는 자동으로 소멸합니다.

상속 관계에 있는 객체는 상위 클래스의 인스턴스도 함께 생성되며,

Object 클래스까지 포함됩니다.

절차적/구조적 프로그래밍, 그리고 Java

자바는 객체지향 언어이지만, 그 뿌리는 절차적/구조적 프로그래밍에서 출발했습니다.

이를 이해하면 객체지향 개념이 왜 필요한지 자연스럽게 와닿습니다.

절차적 프로그래밍

프로그램을 위에서 아래로 순서대로 실행하는 방식
goto 사용은 복잡한 흐름을 만들기 때문에 Java에선 예약어지만 사용 불가

// 이런 식의 흐름이 복잡해지기 때문에 지양
goto line14;

구조적 프로그래밍 = 함수 중심

중복 코드 제거, 유지보수 용이
논리를 함수 단위로 모듈화
Java에서는 이 개념이 메서드(method)로 이어짐

함수는 클래스와 독립적이지만,

메서드는 클래스 내부에 반드시 존재해야 합니다.

⚙️ main() 실행부터 메모리까지

Hello, World!를 출력하는 간단한 코드도, 실제로는 복잡한 실행 구조를 가집니다.

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

실행 순서 요약

JRE가 프로그램 실행 요청
JVM 부팅 및 static 영역 준비
java.lang 등 필수 패키지 static에 적재
클래스 로딩 → static 영역에 등록
main() 메서드 호출 → stack 프레임 생성
지역 변수 확보 → 코드 실행
main() 종료 → 스택 프레임 소멸
JVM 종료 → static, heap 메모리 해제

️ [여기에 JVM 실행 다이어그램 삽입]

변수는 어디에 저장될까?

변수 종류	저장 위치	소멸 시점
전역 변수	static 영역	JVM 종료 시
지역 변수	stack 영역	메서드/블록 종료 시
객체 필드	heap 영역	참조 해제 시 (GC)

스레드와 메모리 구조

구분	멀티 스레드	멀티 프로세스
스택 영역	스레드마다 별도	프로세스마다 별도
static / heap 영역	공유	공유하지 않음
메모리 효율	높음	낮음
안전성	동시성 이슈 가능	상대적으로 안전

서블릿(Servlet)은 요청마다 스레드를 생성 → 멀티 프로세스보다 메모리 효율성 높음

전역 변수보다 전역 상수!

public class Shared {
    static int value = 55;
}

전역 변수는 여러 스레드에서 동시에 수정 가능
→ 데이터 무결성 문제 발생

✅ 올바른 예시

public class Constants {
    public static final int MAX_COUNT = 100;
}

읽기 전용 상수로 사용 → 안전 + 공유 가능

해당 단원을 읽고 배운 점 (TIL)

JVM이 프로그램 실행을 위해 메모리를 static, stack, heap으로 나누어 관리한다는 점을 알게 되었다.
메서드 호출과 블록 스코프의 변수 소멸 타이밍을 이해하면, 예상치 못한 변수 접근 에러를 방지할 수 있다.
멀티 스레드 환경에서는 static 영역과 heap을 공유한다는 점에서 전역 변수 사용 시 동기화 이슈에 주의가 필요하다.
전역 변수는 피하되, 전역 상수는 적극 활용하자!

다음 장에서는 본격적으로 객체지향 개념이 어떻게 자바에 녹아있는지를 살펴보겠습니다.

클래스, 인스턴스, 메서드, 필드 등 객체지향의 핵심 요소들을 차근히 정리해볼게요.

참고 자료: 스프링 입문을 위한 자바 객체 지향의 원리와 이해 (김종민 저)

[Java] 스프링 입문을 위한 자바 객체 지향의 원리와 이해 1장 - 사람을 사랑한 기술 - Java 역사 이야기

junju404 — Wed, 18 Jun 2025 17:06:46 +0900

스프링 입문을 위한 자바 객체 지향의 원리와 이해 1장 - 사람을 사랑한 기술, Java 역사 이야기

안녕하세요! 오늘은 자바의 탄생 배경과 발전 과정에 대해 이야기해보려고 합니다. 프로그래밍 언어의 역사를 통해 자바가 왜 '사람을 사랑한 기술'이라고 불리는지 함께 알아보겠습니다.

️ 기계어에서 객체 지향 프로그래밍 언어로

기계어 - 0과 1의 행진

프로그래밍의 시작은 기계어였습니다. 인류 최초의 프로그래머들은 꺼진 상태와 켜진 상태를 0과 1로 해석할 수 있는 '백열전구'를 이용해 프로그램을 작성했습니다.

역사적 의미

애드삭(EDSAC): 2진법을 적용한 세계 최초의 프로그램 내장 방식 전자 계산기

유니박(UNIVAC): 최초의 상업용 컴퓨터

흥미로운 점은 프로그래밍 언어들이 서로를 모방하고 창조하면서 발전했다는 것입니다:

애드삭: 기계어 ADD
유니박: 기계어 PLUS
Java 진영: System.out.println(), JDBC, ResultSet
Microsoft 진영: Console.WriteLine(), ODBC, RecordSet

용어 정리

JDBC: Java Database Connectivity

ODBC: Open Database Connectivity

어셈블리어 - 인간 지향으로의 첫 걸음

기계어의 0과 1 행진을 벗어나 어셈블리어가 등장했습니다. 이는 기계어의 니모닉(기억하기 쉬운 기호)으로, 인간이 이해하기 쉬운 형태로 발전했습니다.

어셈블러는 어셈블리어를 기계어로 번역해주는 소프트웨어입니다.

컴퓨터의 데이터 저장 방식: 엔디안(Endian)

컴퓨터가 메모리에 데이터를 저장하는 방식에는 두 가지가 있습니다:

1. 빅엔디안 (Big-Endian)

RISC CPU에서 사용
낮은 주소에 데이터의 높은 바이트(MSB)부터 저장
평소 우리가 숫자를 사용하는 선형 방식과 동일 (이해하기 쉬움)

예시: 0x12345678
→ 0x12 / 0x34 / 0x56 / 0x78 (순서대로 저장)

2. 리틀엔디안 (Little-Endian)

인텔 CPU에서 사용
낮은 주소에 데이터의 낮은 바이트(LSB)부터 저장
평소 우리가 사용하는 방식과 반대로 거꾸로 읽음

실무에서의 중요성

인텔 기반 운영체제: 리틀 엔디안 방식 사용

네트워크 데이터 전송: 빅 엔디안 방식 사용

C언어 - 강력한 이식성의 시작

C언어는 "One Source Multi Object Use AnyWhere"라는 철학을 가지고 등장했습니다.

하나의 소스 파일을 각 기계에 맞는 컴파일러로 컴파일하여 다양한 플랫폼에서 실행할 수 있게 했습니다. 다만, 운영체제마다 소스 수정 과정이 필요했다는 한계가 있었습니다.

C++언어 - 객체 지향의 도입

C언어에 객체 지향 개념을 도입한 C++언어가 등장했습니다. 이는 인간적인 사고의 프로그래밍 방식으로, 프로그래밍 패러다임의 큰 전환점이 되었습니다.

☕ Java - 진정한 객체 지향 언어

"Write Once One Object Use AnyWhere"

Java는 "사람을 사랑한 방법"으로 프로그래밍을 더욱 인간적이고 안전하게 만들었습니다.

Java의 혁신적 특징

컴파일러를 기종별로 준비할 필요 없음
- 단, JRE(Java Runtime Environment)만 설치하면 됨
JVM(Java Virtual Machine)
- 플랫폼 독립성 보장
포인터 제거
- 메모리 관리의 복잡성과 위험성 제거

C언어 vs Java 비교

구분	C	Java
소스 파일	One Source	One Source
목적 파일	Multi Object	One Object
실행	Use AnyWhere	Use AnyWhere

️ JDK, JRE, JVM의 관계

chat gpt 가 만들어준 다이어그램

Java 생태계를 이해하기 위해 핵심 구성 요소들의 관계를 알아보겠습니다:

구분	JDK (Java Development Kit)	JRE (Java Runtime Environment)	JVM (Java Virtual Machine)
목적	Java 개발 도구 제공	Java 실행 환경 제공	Java 바이트 코드 실행
구성 요소	JRE + 컴파일러(javac), 디버거 등	JVM + 라이브러리(API 클래스)	클래스 로더, 실행 엔진, 메모리 영역
포함 관계	JDK ⊃ JRE ⊃ JVM	JRE ⊃ JVM	-
예시	Java 코드 컴파일 및 실행	.jar 파일 실행	바이트코드를 기계어로 변환하여 실행

간단 정리

JVM: Java 프로그램이 돌아가는 가상 컴퓨터 (핵심 엔진)

JRE: JVM + 자바 프로그램 실행에 필요한 기본 라이브러리

JDK: JRE + 개발도구 (개발자용 풀 패키지)

Java 프로그램 실행 과정

Java 프로그램이 어떻게 실행되는지 단계별로 살펴보겠습니다:

소스 코드 작성
- Main.java 파일 생성
컴파일 과정
- 컴파일러가 Java 소스 코드를 클래스 파일로 생성
- 컴파일된 클래스 파일은 JVM이 인식 가능한 바이트 코드
실행 과정
- JVM이 클래스 파일의 바이트 코드를 해석
- 바이너리 코드로 변환하여 프로그램 수행

백문이 불여일타 - 실제 확인해보기

Java 소스 코드 작성 (Hello 클래스, main 메서드, System.out.println)

소스 코드 파일을 컴파일 → javac 명령어 사용

생성된 클래스 파일을 JVM으로 실행 → java 명령어 사용

클래스 파일을 바이너리 코드로 변환 → 프로그램 수행

마무리

자바의 역사를 통해 우리는 프로그래밍 언어가 어떻게 '기계 중심'에서 '사람 중심'으로 발전해왔는지 볼 수 있습니다.

기계어의 0과 1에서 시작해 어셈블리어, C언어, C++을 거쳐 Java에 이르기까지, 각 단계마다 프로그래머의 편의성과 안전성을 높이려는 노력이 있었습니다.

특히 Java는 "Write Once, Run Anywhere"라는 철학으로 플랫폼 독립성을 실현했고, 포인터 제거를 통해 메모리 안전성을 확보했습니다. 이러한 특징들이 Java를 '사람을 사랑한 기술'로 만든 핵심 요소라고 할 수 있습니다.

다음 포스트에서는 객체 지향 프로그래밍의 핵심 개념들에 대해 더 자세히 다뤄보겠습니다. 기대해 주세요!

참고 자료: 스프링 입문을 위한 자바 객체 지향의 원리와 이해 (김종민 저)

[Git] git pull 브랜치 충돌 해결 방법

junju404 — Tue, 13 Feb 2024 08:19:10 +0900

팀프로젝트를 진행하다보면 git 에서 여러 에러를 발생할 수 있다.

내가 이번에 만난 에러는 다음과 같다.

상황을 조금 구체적으로 설명하자면,

default 브랜치인 "develop"과 각자 기능을 담당하는 feature/n 브랜치가 존재한다.

나는 feature/8 를 사용 중이었고, commit을 모두 마친 후 PR을 요청했다.

그래서 그동안 팀원들이 바꾼 develop 브랜치의 코드를 업데이트 하기 위해

git pull origin develop을 했다.

그런데

POST git-upload-pack (323 bytes)

POST git-upload-pack (943 bytes)

POST git-upload-pack (gzip 2543 to 1322 bytes) remote: Total 228 (delta 84),

reused 217 (delta 76),

pack-reused 0 From https://github.com/Homeat/Server * branch develop -> FETCH_HEAD 1fe1f65..70c7b21 develop -> origin/develop

hint: You have divergent branches and need to specify how to reconcile them.

hint: You can do so by running one of the following commands sometime before

hint: your next pull: hint: hint: git config pull.rebase false # merge

hint: git config pull.rebase true # rebase

hint: git config pull.ff only # fast-forward only hint:

hint: You can replace "git config" with "git config --global" to set a default hint: preference for all repositories.

You can also pass --rebase, --no-rebase, hint: or --ff-only on the command line to override the configured default per hint: invocation. Need to specify how to reconcile divergent branches.

어후.. 끔찍하다.. 이게 무슨 말인지 이해는 안된다.

사실 이전에 git 충돌 때문에 이 문제를 포기했던 적이 있다.. 같이 공부하던 친구도 pull 을 하려는 브랜치에 굴복(?)당하는 건 싫다고 해서 어째저째 하다가 어영부영 넘어갔던 거 같다.. 그 땐 fetch 진행 후, merge를 rebase로 진행했던 것 같다.

이 때는 git에 대해 조금 더 공부하려고 했으나 프로젝트 진행이 급하기 때문에 잠시 보류해두었다.

근데, 이제 어느 정도 프로젝트 구현은 마무리가 되어가고 깃에 대한 기록을 남기기 위해 작성한다.

위 문제 원인은 로컬 브랜치와 remote 원격 브랜치 사이에 변경 사항 충돌 때문에 발생한다.

그래서 이 문제를 해결하기 위한 방법은 3가지가 있다고 친절히 힌트를 주고 있다.

1. git config pull.rebase false

2. git config pull.rebase true

3. git config pull.ff only

우선, 위 3가지 방법을 알아보기 전에

git pull에 대해서 알아야 한다.

git pull (origin ~~~)은 두 단계를 포함하고 있다.

- git fetch (origin ~~~) 리모트 저장소(origin ~~~)에서 변경사항을 가져온다.

- git merge (origin ~~~) 변경 사항을 현재 작업 중인 브랜치에 병합한다.

그럼 이제, 위의 3가지 방법을 알아보자

git config pull.rebase false

이 옵션은 git pull이 fetch 이후 merge를 실행하도록 설정한다. 즉, git pull을 실행하면 원격(remote) 브랜치의 변경 사항을 가져와서 현재(local) 브랜치에 병합한다.

병합(merge)는 두 브랜치의 변경 사항을 모두 포함하는 새로운 커밋을 생성한다. 이 새로운 커밋에는 병합된 두 브랜치의 커밋이 부모로 설정된다. 이렇게 하면 두 브랜치에서 독립적으로 이루어진 작업을 모두 유지하면서 한 브랜치로 합칠 수 있다.

하지만, 이 방식은 여러 사람이 동시에 작업을 진행할 때 복잡한 커밋 히스토리를 만들 수 있다. 그 이유는 병합 과정에서 새로운 커밋이 생성되기 때문이다. 또한, 병합 과정에서 충돌이 발생할 수 있으며, 이 충돌은 수동으로 해결해야 한다.

따라서, 병합은 작업 내용을 명확하게 구분하고 싶을 때 유용하다. 하지만, 커밋 히스토리를 간결하게 유지하고 싶다면, rebase 옵션을 고려해 보는 것이 좋다.

친구와 함께 팀 프로젝트를 하고 있다고 생각해보세요. 
당신과 친구는 각각 자신의 부분을 작성하고, 이후에 모두 합쳐서 최종 보고서를 만들어야 합니다. 
이 때, 각자가 작성한 부분을 그대로 모아서 하나의 보고서를 만드는 것이 'merge' 방식입니다. 
각자 작성한 부분이 그대로 보존되지만, 적절한 순서나 흐름을 만들기 위해 추가적인 편집이 필요할 수 있습니다.

git config pull.rebase true

이 옵션은 fetch 이후 'rebase'를 실행하도록 git pull 옵션을 설정한다. 따라서, git pull을 실행하면 local(현재) 브랜치의 변경 사항이 임시적으로 "저장"되고, remote(원격) 브랜치의 최신 변경 사항으로 local 브랜치가 업데이트 된다. 그 다음, 앞서 "저장"했던 local 브랜치의 변경 사항이 다시 적용된다.

이 과정을 통해, 여러 사람이 동시에 작업을 진행하더라도 각자의 작업이 순차적으로 이루어진 것처럼 보이게 된다. 이는 커밋 히스토리를 깔끔하게 유지할 수 있게 해주며, 코드 변경 사항 추적에 있어서 혼란을 줄여 준다.

하지만 주의할 점이 있다. rebase는 기본적으로 기존의 커밋 히스토리를 변경한다. 따라서, 이미 원격 저장소에 push한 커밋을 rebase를 통해 변경하는 것은 다른 사람들과의 작업에 혼란을 줄 수 있다. 그러므로, 원격 저장소에 push한 커밋은 가능한 변경하지 않는 것이 좋다.

또한, rebase를 사용하면 병합된 커밋이 생성되지 않는다. 이는 각 브랜치에서의 작업이 병합으로 인해 '섞이지' 않게 되므로, 각 브랜치에서 어떤 작업이 이루어졌는지 더 명확하게 파악할 수 있다는 장점이 있다.

같은 팀 프로젝트 상황에서, 이번에는 당신이 친구의 부분을 먼저 읽고, 그 내용에 맞춰서 자신의 부분을 이어서 작성한다고 생각해보세요. 
이렇게 하면, 친구의 부분이 바뀌더라도 그 변경 사항을 빠르게 반영하고, 자신의 부분을 순차적으로 이어서 작성할 수 있습니다. 
이것이 'rebase' 방식입니다.

git config pull.ff only

이 옵션은 git pull이 Fast-forward 방식만을 사용하도록 설정한다. Fast-forward는 현재(local) 브랜치가 가리키는 커밋이 원격(remote) 브랜치가 가리키는 커밋의 직접적인 선행 커밋일 때만 적용 가능한 방식이다.

Fast-forward 방식을 사용하면, 현재 브랜치의 포인터만 원격 브랜치가 가리키는 커밋으로 이동시키고, 별도의 병합 커밋을 생성하지 않는다. 이렇게 하면 커밋 히스토리가 선형적으로 유지되고, 병합으로 인한 혼란을 방지할 수 있다.

하지만, 현재 브랜치에서 새로운 커밋이 추가되었거나, 원격 브랜치의 커밋이 현재 브랜치의 선행 커밋이 아닌 경우에는 Fast-forward가 불가능하다. 이런 경우에는 병합(merge)나 리베이스(rebase)를 사용해야 한다.

따라서, 'git config pull.ff only' 옵션은 협업 환경에서 커밋 히스토리를 깔끔하게 유지하고 싶을 때 유용하다. 하지만, 이 옵션을 사용할 때는 현재 브랜치의 변경 사항을 자주 원격 저장소에 푸시하거나, 원격 브랜치의 변경 사항을 자주 가져와야 한다는 점을 유의해야 한다.

이렇게 설명만으로는 이해가 되지 않을 수 있다.

이번에는 당신이 친구의 부분을 기다리지 않고 먼저 보고서를 작성했다고 생각해봅시다. 
그리고 친구가 자신의 부분을 완성하면, 그 부분을 당신이 이미 작성한 부분 뒤에 바로 이어붙입니다. 
이 경우, 당신이 작성한 부분을 다시 수정하거나 조정할 필요 없이, 친구의 부분을 그대로 추가할 수 있습니다. 
이것이 'fast-forward' 방식입니다.

위의 방법으로 git 충돌 문제를 해결할 수 있다고 한다.

나는

git fetch origin
git merge origin/develop

이렇게 문제를 해결했다. 그래서 리모트 브랜치와 내 작업 브랜치를 합쳐서 변경 사항을 수동으로 작업한 후에

PR을 해보니 충돌이 해결됐다.