호기심 많은 솔이의 개발 노트

OUTBOX 패턴이란?

호기심 많은 솔이 — Thu, 21 May 2026 00:03:56 +0900

OUTBOX 패턴이란?

OUTBOX 패턴은 외부 시스템으로 처리해야 할 작업을 바로 실행하지 않고, 먼저 DB 테이블에 "해야 할 작업"으로 저장해두고, 별도 워커가 그 테이블 또는 큐를 기준으로 처리하는 방식이다. 특히, 이벤트 기반 아키텍처에서 메시지 유실을 방지하고, 데이터 정합성을 보장하는 데 활용한다.

예를 들면, 특정 이벤트에 대한 알림톡을 보내야 하는 경우, 바로 알림톡 API를 호출하는 게 아니라, 먼저 DB에 데이터를 남기고, 프로듀서가 SQS에 메시지를 넣고, 워커가 SQS 메시지를 받아서 해당 outboxId를 기준으로 OUTBOX를 선점한 뒤 알림톡을 발송할 수 있다.

사용하는 이유?

[중복 처리 방지, 장애 복구, 처리 상태 추적]

알림톡 같은 외부 API 호출은 언제든 실패할 수 있는데, 이런 상황에서 OUTBOX가 없으면 보냈는지 안 보냈는지, 다시 보내도 되는지, 누가 처리 중인지 추적이 어려워진다.

반면, OUTBOX가 있다면, DB에 상태가 남기 때문에 안전하게 제어할 수 있다.

하지만, OUTBOX 패턴을 사용했을 때, 아웃박스 테이블을 따로 둬야 하므로 DB 사용량이 증가하고, 아웃박스를 다루는 로직이 추가로 필요하다는 단점도 존재한다.

OUTBOX 처리 흐름 예시

1. OUTBOX로 특정 이벤트를 선점(CLAIM)하여 다른 워커 등이 같은 이벤트를 중복 처리하지 않도록 방지.

2. 해당 이벤트 처리 성공 시 선점 상태를 풀고 성공 처리로 변경

3. 처리 실패 시 선점 상태를 풀고 실패 처리로 변경

SQS 기반 알림톡 워커 구현

호기심 많은 솔이 — Wed, 20 May 2026 22:48:30 +0900

- 문제 상황 : 특정 비즈니스 이벤트가 발생했을 때, 담당자에게 정해진 시간 안에 알림 전달 필요.

- 해결 방향 : 이벤트와 관련된 사용자에게 외부 알림톡 API를 통해 안내 메시지를 발송하도록 설계 및 구현

<설계>

[흐름 정리]

1. 비즈니스 이벤트 발생

2. Producer가 알림 발송 작업을 Outbox에 저장

3. Producer가 메시지 큐에 작업 ID 전송

4. Worker가 큐 메시지 수신

5. Worker가 Outbox 작업을 선점

6. Worker가 알림 템플릿 조회

7. Worker가 발송에 필요한 데이터를 조회하는 SP 실행

- 테이블들을 상황에 맞게 조회, 조인하여, 필요한 데이터들을 가져옴

8. Worker가 템플릿 파라미터 구성

- 위에서 가져온 필드들을 Java에서 파싱하여 템플릿에 맞게 templateParam을 구성.

9. 구성한 templateParam으로 외부 알림톡 API 호출

10. 발송 성공 시 OUTBOX 성공 처리

11. 발송 실패 시 OUTBOX 실패 처리

[링크] OUTBOX 패턴이란?

[링크] AWS SQS란?

[테이블 및 SP]

1. OUTBOX 테이블 : 발송 작업 단위 저장, 선점 및 성공/실패 결과 저장용

(**워커가 죽었을 때 PROCESSING 상태가 너무 오래 묶이지 않도록 하기 위해 LOCK_UNTIL 컬럼을 두고, LOCK 만료 시간을 설정)

2. 알림톡 발송 이력 테이블 : 실제 알림톡 발송 결과 저장용

3. 알림톡 템플릿 관리 테이블 : 케이스 별 템플릿 관리용

a. OUTBOX 선점 SP

b. OUTBOX 성공 처리 SP

c. OUTBOX 실패 처리 SP

d. 첫 번째 템플릿(특정 이벤트 발생 알림)발송 데이터 조회 SP

[템플릿 구성]

전제 :

- 추후 여러 템플릿이 추가될 수 있어 확장성 고려

- 템플릿 별로 필요한 데이터가 달라 templateId 기준으로 조회 로직 분리

- Worker가 templateId에 맞는 조회 로직 실행 후 templateParam 구성

- 템플릿 코드는 고정값 (템플릿 별로 정해져 있음)

- 플랫폼 별로 서로 다른 큐 사용 예정 -> 플랫폼 별 코드로 구분할 필요 X

공통 모듈 분리(모듈화) 정리 (+간단 예시, 핵심 요약)

호기심 많은 솔이 — Fri, 16 Jan 2026 01:18:06 +0900

오늘 공통 모듈 분리에 대한 설명을 들었다.

내용을 요약하면, 어떤 프로젝트에서는 쓰이고, 또 어떤 프로젝트에서는 쓰이지 않는 것들이 아니라, 대부분의 프로젝트에서 쓰이는 것들, 예를 들면 db 설정, 해싱, jwt 관련 로직, 전역 예외처리, 공통 응답/에러 포맷, 검증(Validation), 로깅과 같은 것들은 따로 분리해서 뽑아 놓으면 새로운 프로젝트에서도 그대로 쓸 수 있고, 이를 잘 활용하면 개발 효율이 많이 올라간다는 것이었다.

위에 나오는 것들 외에도 알림톡 모듈을 개발한 후에 메일 전송 모듈을 만든다고 하면 공통되는 로직이 많을 것이다. 알림톡 모듈을 개발할 때, 그런 공통 로직들을 잘 뽑아서 정리해 놓으면 메일 전송 모듈을 개발할 때에는 개발 시간이 많이 단축될 것이다.

위의 내용들을 바탕으로 실습을 해보면서 감을 익혀보자는 생각으로 간단한 CRUD를 만들고, 공통된 부분을 분리해보기로 했다.

목표 : 2개의 테이블(학교, 학생)을 만들고, 학교, 학생 CRUD를 간단하게 구현한 후, 공통된 로직 추출해보기.

- 학교 CRUD : 학교 생성, 학교 목록 조회, 학교 단건 조회, 학교 수정, 학교 삭제

- 학생 CRUD : 학생 생성, 학생 목록 조회, 학생 단건 조회, 학생 이름 수정, 학생 삭제

이 실습을 하면서 뽑아낸 공통된 로직들 중 학습하기 좋은 예시를 하나 가져와서 설명해보겠다.

<공통 부분 추출 전 StudentRepository>

<공통 부분 추출 전 SchoolRepository>

위 두 코드를 보면, 공통된 부분을 찾을 수 있다. 초록색으로 표시된 부분들이 두 레포지토리의 공통된 부분이고, 노란색으로 표시된 부분이 차이가 나는 부분이다. 사진에서 보이는 것처럼 파라미터의 개수만 다른 경우도 차이가 나는 부분임에 주의해야 한다.

초록색 부분(공통 부분) 요약

1. GeneratedKeyHolder()로 PK 생성

2. jdbcTemplate.update(...) 호출

3. con.prepareStatement(...)로 생성된 PK 반환 설정

4. keyHolder.getKey()로 방금 INSERT 된 id 꺼내서 Long으로 반환

노란색 부분(차이 부분) 요약

A. INSERT INTO ... (파라미터 다름)

B. ps.setString(...) ... (null 유무 다름)

<공통 부분 추출 후>

이렇게 공통된 부분을 추출한 후 이제 이를 하나의 메서드로 만들었다. -> JdbcHelpers.insertAndReturnId(...)

위 사진의 코드를 보면, 공통된 부분은 JdbcHelper라는 클래스에 insertAndReturnId(...)라는 메서드로 만든 후, StudentRepository에서 메서드 호출만으로 사용하고 있는 것을 볼 수 있다.

이런 식으로 공통 부분을 뽑아내서 코드를 작성하면 얻을 수 있는 장점은 많기 때문에, 직관적으로 가장 이해하기 쉬운 예시를 들자면,

기존 구조에서는 StudentRepo 내용이 1,2,3,4,A,B이고, SchoolRepo 내용이 1,2,3,4,a,b 였다면,

공통 부분을 뽑아낸 후의 StudentRepo 내용은 @,A,B가 됐고, SchoolRepo 내용은 @,a,b가 되었다.

이렇게 공통 부분을 뽑아냄으로써 중복을 제거하고, 코드의 가독성도 향상시킬 수 있었다. 또한, 이후 프로젝트에서 이 로직을 재사용하는 경우가 생긴다면 개발 시간도 단축할 수 있다는 효과가 있는 것이다.

저장 프로시저(SP: Stored Procedure)란?

호기심 많은 솔이 — Wed, 14 Jan 2026 22:39:05 +0900

프로시저란?

프로시저(Procedure)는 특정 작업을 수행하기 위해 미리 정의된 일련의 명령어 집합으로, 데이터베이스에서 데이터의 추가, 수정, 삭제, 조회 등 복잡한 작업을 자동화하고 효율적으로 처리하기 위해 사용된다. 프로시저는 함수와 달리 값을 반환하지 않고 여러 동작을 묶어 하나의 논리적 단위로 실행한다는 특징을 가지고 있다. 프로시저를 사용하면 반복적인 업무를 줄이고 데이터베이스 성능을 향상시킬 수 있다.

미리 만들어서 DB에 저장해두고, 필요할 때 이름으로 호출하면, 프로시저 내에 들어있는 여러 SQL(조회/수정/삽입/삭제, 계산, 조건문 등)이 한 번에 실행된다.

프로시저를 사용하는 이유

1. 같은 로직을 여러 시스템에서 재사용 할 수 있다. ㅡ> 추후 비슷한 시스템 개발 시 시간 단축 가능

- 예를 들어, 쇼핑몰에서 주문이 완료되면 주문 금액의 1%만큼 포인트를 적립하고, 적립 후 히스토리를 남긴다는 규칙이 있다고 할 때, 이를 프로시저로 DB에 만들어두면 웹, 앱, 관리자 등 여러 곳에서 같은 프로시저만 호출하면 된다.

2. 로직을 DB에 모아 일관성을 유지할 수 있다.

- 적립 규칙이 바뀌면 프로시저만 수정하면 전 채널에 동일하게 적용된다.

3. 네트워크 왕복을 줄여 성능 개선이 가능하다.

- 앱이 회원조회 -> 포인트 계산 -> 포인트 업데이트 -> 히스토리 INSERT를 각각 따로 보내면 DB를 여러 번 왕복해야 하지만, 프로시저는 한 번의 호출로 DB 안에서 전부 처리가 가능하다.

4. 소스 코드에서 SQL을 길게 직접 쓰는 대신 DB에 만들어둔 프로시저를 호출하면 소스 코드가 단순해질 수 있다.

프로시저를 사용하는 경우와 SQL로 앱에서 처리하는 경우 비교 예시

SQL 예시

결제 시 DB에서 해야 할 일은 일반적으로 여러 단계로 구성되어 있다.

1. 사용자 잔액이 충분한지 확인

2. 잔액 차감

3. 주문(결제) 기록 생성

4. 실패하면 전체 롤백

이런 경우에 프로시저를 사용하지 않고 SQL로 앱에서 처리한다면 위 사진에 나오는 것과 같이 DB 왕복이 3번이나 필요하다. 또한, 중간에 장애/예외가 생기면 잔액을 줄었는데 주문이 없는 경우도 발생할 수 있다.

하지만 프로시저를 사용하면 아래 사진의 내용과 같이 앱에서 그냥 한 번의 호출만 하면 위의 로직이 모두 실행된다.

이렇게 프로시저를 이용했을 때, 체감되는 장점을 정리해 보면

- 네트워크 왕복이 3번에서 1번으로 줄었다.

- 잔액 차감, 주문 생성이 항상 같이 성공/실패한다.(원자성)

- 규칙이 DB에 고정돼서 모든 곳에서 동일하게 동작한다.(일관성)

이외에도, 복잡한 SQL을 자바 코드에서 분리할 수 있어서 애플리케이션 단의 역할 및 책임의 일부를 DB쪽으로 이전한다는 느낌이 들었다. 이렇게 하면 DB를 잘 다루는 사람의 경우, 애플리케이션 코드에서 SQL 처리 복잡도를 줄일 수 있을 것 같다는 생각이 들었다.

하지만 외부 시스템 연동 흐름까지 DB에서 처리하는 것은 좋지 않을 것 같다는 생각이 들었다.

관련 내용을 찾아보니,

데이터 조회, 변경, 상태관리, 트랜잭션, 동시성 제어와 같은 작업들은 DB에 맡기기 적합하지만,

외부 API 호출, SQS 처리, JSON 파싱, 예외 분기, 비즈니스 흐름 제어와 같은 작업들은 DB가 아니라 애플리케이션에서 맡아서 처리하는 것이 좋은 것 같다.

프로시저를 사용하면 좋은 케이스

1. 여러 테이블을 한 번에 처리해야 하는 작업 ex) 회원가입(여러 테이블 insert), 주문 생성(주문/결제/재고 테이블 update)

2. 트랜잭션(원자성)이 중요한 작업 ex) 중간에 실패하면 안 되는 한 덩어리 업무를 DB에서 묶어두는 게 안정적일 때

3. 여러 서비스에서 동일하게 재사용되는 핵심 쿼리

프로시저를 사용하면 나쁜 케이스

1. 단순 CRUD 한두 줄인데 자주 바뀌는 비즈니스 로직

2. DB 벤더 종속을 피하고 싶을 때(이식성)

AWS SQS를 이용한 알림톡 모듈 - Enqueue/Dequeue 구현 및 로직 정리

호기심 많은 솔이 — Tue, 13 Jan 2026 23:56:15 +0900

기본 흐름 구성

우리 서비스에서는 특정 이벤트 발생 -> Producer가 SQS에 메시지를 Enqueue -> Consumer가 Polling으로 Dequeue 후 알림톡 발송 -> 성공 시 메시지 삭제 흐름으로 알림톡 모듈을 구성하였다.

과금 방식

그리고 과금(잔액 차감)은 "큐에 들어간 순간 바로 차감"이 아니라, Enqueue 시점에는 예약 차감 & 임시 과금 상태를 저장하고 Dequeue 후 발송 성공 시점에 확정 차감 & 실제 잔액을 차감하는 식으로 구성하였다.

Enqueue 단계에서 잔액을 바로 차감하지 않는 이유를 설명하자면,

SQS는 기본적으로 적어도 한 번 전달될 수 있고, 네트워크/타임아웃/컨슈머 장애로 인해 같은 메시지가 중복 처리될 가능성이 있다. 또한, 외부 알림톡 벤더 API는 언제든 일시 장애가 날 수 있고, 그러면 발송은 지연되거나 재시도될 수 있다. 만약 Enqueue 순간에 바로 잔액을 차감해 버리면 발송 실패/지연이 발생했을 때, 차감은 됐는데 발송은 안 되는 불일치가 생길 수 있고, 중복 메시지 처리 시, 동일 요청에 대해 잔액이 2번 차감될 위험이 있다. 이때 실패 케이스를 복구하려면 이미 차감된 돈을 다시 돌려주는 복잡한 보상 트랜잭션이 필요해진다. 그래서 우리는 Enqueue에서는 예약 차감만 하고, Consumer가 실제 발송을 끝낸 뒤에만 확정 차감 하도록 분리하였다.

추가로, 상태 전이(RESERVED -> CONFIRMED)를 둔 이유를 설명하자면,

1. 멱등성(idempotency)을 확보하기 위해

- SQS 메시지는 같은 요청이 중복으로 들어오거나(프로듀서 재전송), 컨슈머가 처리 중 장애가 나서 다시 처리될 수 있다. 이때, 임시 과금 테이블의 STATUS가 이미 CONFIRMED라면, 이 요청은 이미 확정 처리된 것으로 간주하고 성공 처리(재차감 방지) 하도록 만들 수 있다.

2. 장애 복구 시 재처리 기준점을 확보하기 위해

- RESERVED 상태와 CONFIRMED 상태의 구분이 있으면 장애가 났을 때에도 판단이 명확해진다.

- RESERVED만 남아있으면 발송 실패 or 미처리된 상황이므로 재시도 or 보상(예약 해제) 대상

- CONFIRMED면 이미 끝났으므로 중복 처리 X

3. 운영 관점에서 추적/감사(Audit) 가능

- 사용자의 "돈은 차감됐는데 왜 알림톡이 안 왔나요?"와 같은 질문에 답하려면 상태 전이가 있어야 추적이 가능하다.

가용 잔액 체크

Enqueue 시에는 가용 잔액을 체크하는데, 이때 예약 차감이 있는 경우까지 고려하기 위해, 예약 차감액을 위한 컬럼을 두었다.

이렇게 계산하는 이유를 간단한 예시로 설명하자면,

고객 A에게 잔액이 1000원이 있고, 알림톡 1건당 100원이 차감된다고 하자. 이때, 고객 A에게 알림톡을 발송해야 하는 이벤트가 5번 발생했고, 해당 알림톡이 Enqueue까지만 된 상황이라면, 예약 차감액(HOLD)이 500원이고, 잔액은 아직 차감되지 않았기 때문에 1000원이 그대로 남아있다. 하지만, 예약 차감액 500원이 있기 때문에, 추가 알림톡 발송은 최대 5건만 가능하다. 즉, 잔액은 1000원이지만 실제로 사용 가능한 금액은 500원인 것이다. 이 상황에서 알림톡을 추가로 6건 발송하려고 한다면 그 6번째 요청은 처리되지 않아야 한다.

AWS SQS를 이용한 알림톡 모듈 개발 - SQS의 개념 및 작동 방식 (+SQS를 선택한 이유)

호기심 많은 솔이 — Mon, 12 Jan 2026 18:36:36 +0900

SQS란?

SQS(Simple Queue Service)는 AWS에서 제공하는 완전 관리형 메시지 큐 서비스로, 분산 시스템과 애플리케이션 간의 메시지(작업)를 안정적으로 주고받도록 하여 서비스들을 분리(Decoupling)하고 확장성을 높여주는 역할을 한다. SQS는 생산자(Producer)가 보낸 메시지를 Enqueue를 통해 큐에 저장하고, 소비자(Consumer)가 필요할 때 큐에서 그 메시지를 가져가(Dequeue) 처리하는 비동기 방식으로 작업이 이루어진다.

SQS의 작동 방식

위 그림은 AWS SQS의 작동 방식이다. 맨 왼쪽의 Producer는 메시지를 제공하는 쪽이다. 즉, 메시지를 큐에 넣는 쪽을 producer라고 한다. 이렇게 큐에 들어간 메시지는 설정에 따라 서버사이드 암호화(SSE-SQS 또는 SSE-KMS)로 안전하게 저장되며, Consumer가 폴링(Polling)을 통해 메시지를 가져가는 방식으로 처리된다.

Consumer가 메시지를 가져가면 SQS는 일정 시간 동안 해당 메시지를 다른 Consumer에게 보이지 않게 숨기는데, 이를 Visibility Timeout이라고 한다. Consumer가 Visibility Timeout 안에 처리를 끝내고 DeleteMessage를 호출하면 메시지는 큐에서 제거되어 ‘처리 완료’로 확정된다. 반대로 시간 안에 삭제되지 않으면 메시지는 다시 보이게 되어 재시도 흐름으로 들어가며, 이 특성 때문에 컨슈머는 중복 처리 가능성을 전제로 설계해야 한다.

SQS의 특징과 장단점

<특징>

- DLQ(Dead Letter Queue): 여러 번 실패한 메시지를 별도로 모아 원인 분석 및 재처리에 활용할 수 있다.
- Long Polling 및 Batch 처리를 지원하여 비용/성능 최적화에 유리하다.
- 메시지 보관 기간(retention)은 기본 4일이며, 최대 14일까지 설정할 수 있다.
- 요청-응답을 분리하는 비동기 처리 구조에 적합하다.

<장점>

- 내구성/신뢰성 : 메시지는 높은 내구성으로 저장되어 유실 위험이 낮고, 처리 실패 메시지는 DLQ로 분리할 수 있다. 다만(Standard Queue 기준) 중복 수신이 발생할 수 있어 멱등성(Idempotency) 처리가 필요하다.

- 보안성 : SQS는 서버사이드 암호화(SSE)를 지원하며, 옵션에 따라 SSE-SQS 또는 SSE-KMS를 선택할 수 있다.
또한 IAM 정책으로 생산자/소비자 권한을 세밀하게 제어할 수 있어 접근 통제가 용이하다.

<단점>

- 메시지의 최대 크기가 256KB로 제한되어 있다.

- 메시지의 보관 기한은 최대 14일로 제한이 있다.

- 폴링 기반이라 비용/지연 튜닝이 필요하다.

- ReceiveMessage(롱폴링), 배치 사이즈/주기, Visibility Timeout을 잘못 잡으면 불필요한 비용이 증가하고, 지연이 생길 수 있다. 특히, Visibility Timeout을 너무 짧게 잡으면 처리 중인 메시지가 다시 나타나 중복 처리/재시도가 늘고, 너무 길게 잡으면 장애 시 복구가 늦어져 지연이 커질 수 있다.

그럼 언제 sqs가 잘 맞나?

이메일/알림/배치 작업/로그 처리/비동기 결제 후처리/크롤링 작업 등에 적합하다. 이 중에서 우리 서비스에서는 알림톡을 구현하는 데에 sqs를 이용하기로 하였다.

왜 알림톡에 sqs가 좋은가?

- 알림톡은 "요청-응답" 흐름이 아니라 이벤트가 생긴 후에 전달되어도 되는 작업이고, 외부 알림 시스템이 불안정하더라도 우리 서비스에 문제가 생기는 경우가 적기 때문이다. 예시로 쉽게 설명하자면, 이메일 smtp나 카카오 알림톡 벤더 api 등에 문제가 있더라도, sqs와 외부 알림 시스템은 비동기적으로 처리되기 때문에 메시지는 안전하게 큐에 저장되어 있고, 컨슈머가 재시도하면서 외부 알림 시스템이 회복될 때 정상적으로 처리된다.

- 트래픽 스파이크를 흡수하기 좋다. 우리 서비스는 특정 시간에 알림이 몰릴 것으로 예상되기때문에 sqs의 이런 특징과 잘 맞다. 동기 구조에서는 피크 때 요청이 다 같이 몰려서 서버/DB/외부 API가 터지기 쉬운데, SQS는 일단 큐에 쌓아두고 컨슈머 수를 늘려서 처리량을 맞출 수 있다.

- 재시도/실패 분리(DLQ)가 알림이랑 잘 맞다. 알림 하나가 실패했다고 해서 전체 서비스를 실패로 만들 필요 없이 실패한 것들은 DLQ로 분리해 두고 추후에 원인 분석 및 재처리가 가능하다.

이런 이유들로 우리 서비스에서는 특정 이벤트 발생 시에 고객들에게 해당 내용을 알림톡으로 발송해 주기 위한 모듈을 개발하는 데에 AWS SQS를 사용하기로 하였다.

sqs를 안 쓰면 뭘 쓸 수 있나? 그중에서 sqs를 선택한 이유?

- sqs를 대체할만한 방법으로는 DB Outbox 패턴, Amazon MQ, Redis 기반 큐 등이 있는데,

이 중 대표적인 예시인 DB Outbox 패턴과 sqs를 비교해 보자면, DB Outbox 패턴은 인프라 추가 없이 DB만으로 "큐/보관/재시도"를 구현할 수 있지만, 이는 큐를 직접 운영하는 것과 같기 때문에 락/폴링/성능 설계를 직접 해야 한다는 단점이 있다. 따라서 우리 서비스에서는 구현 및 운영 비용을 절감할 수 있고 안정성이 높은 SQS를 선택하였다.

SMS가 아니라 알림톡을 선택한 이유 : 알림톡 / SMS 비용 차이

※ 단가는 대행사, 월 발송량 구간, 부가세 포함 여부에 따라 달라질 수 있으며 아래는 일반적인 경향을 설명하기 위한 예시이다.

- 대행사마다 다르지만 일반적으로 알림톡은 건당 약 7원 정도, SMS(단문)은 10원 이상이고, 긴 내용을 보내기 위해 LMS를 이용해야 한다면 건당 30원 이상 드는 경우가 많다. 따라서 우리 서비스에서는 SMS가 아니라 알림톡을 이용하면 비용 절감을 이룰 수 있다고 판단하여 AWS SQS를 이용한 알림톡 모듈을 개발하기로 하였다.

부트캠프 26주차 회고

호기심 많은 솔이 — Mon, 22 Sep 2025 01:02:48 +0900

이번 주에는 JWT 기반 로그인/회원가입을 구현하기 위해 관련 개념을 학습하고 실제 적용을 준비하였다. JWT는 토큰 기반 인증 방식으로, 세션을 서버에서 관리하지 않아도 되기 때문에 확장성과 유지보수 측면에서 장점이 많았다.

학습 과정에서 Access Token과 Refresh Token의 역할을 명확히 구분하는 것이 중요하다는 점을 알게 되었고, 특히 보안성을 높이기 위해 Refresh Token을 Redis에 저장하고 관리하는 방식을 적용하려고 했다. 이를 통해 토큰 만료 시점과 블랙리스트 처리, 강제 로그아웃 같은 시나리오를 더 유연하게 처리할 수 있다는 점을 이해할 수 있었다.

또한 Redis를 단순 캐시로만 생각했었는데, 이번 학습을 통해 분산 환경에서의 세션 관리 대체재로 활용할 수 있다는 점이 인상 깊었다. JWT와 Redis를 결합하면 서버 확장이 용이하고, 중앙 집중적으로 토큰 상태를 관리할 수 있어 운영 환경에서도 안정성을 보장할 수 있다는 점을 배웠다.

이번 경험을 통해 단순한 로그인/회원가입 기능도 실제 서비스 환경에서는 보안, 확장성, 안정성을 모두 고려해야 함을 체감할 수 있었다. 특히 토큰 저장소로서 Redis를 활용하는 방식은 앞으로 다른 기능을 설계할 때도 큰 도움이 될 것 같다.

부트캠프 25주차 회고

호기심 많은 솔이 — Mon, 15 Sep 2025 11:09:48 +0900

이번 주에는 파이널 프로젝트에서 공통 기능인 로깅과 예외 처리를 직접 구현해 보았다. 실제 서비스에 필수적인 기능이지만 처음으로 구조를 잡고 적용하다 보니 생각보다 신경 써야 할 부분이 많았다.

로깅에서는 에러 상황뿐만 아니라 정상적인 흐름도 잘 기록될 수 있도록 로그 레벨을 분리하고, 운영 환경에서의 모니터링을 고려한 구조를 학습할 수 있었다. 예외 처리에서는 전역 예외 처리기를 통해 서비스 전반에서 일관된 응답을 제공하는 방법을 적용하면서, 에러 코드 관리와 응답 DTO 설계의 중요성을 느꼈다.

이번 작업을 통해 단순히 코드를 작성하는 것 이상의, 서비스의 안정성과 유지보수성에 직결되는 공통 기능이 얼마나 중요한지 체감할 수 있었다. 커스텀 예외 같은 것들은 처음 해보는 내용이라 생소해서 어렵긴 했지만 새로운 내용을 배울 수 있다는 점에서 의미 있었다. 앞으로도 새로운 것들을 계속 도전해보면서 경험을 쌓아 가야겠다.

부트캠프 24주차 회고

호기심 많은 솔이 — Mon, 8 Sep 2025 04:32:49 +0900

이번 주에는 팀 프로젝트에서 처음으로 CI/CD 환경을 직접 구성해보았다. 처음 해보는 작업이라 생소한 개념도 많았고, 설정 과정에서 예상치 못한 오류도 자주 발생했지만, 그만큼 배우는 것도 많았다.

CI/CD를 구성하는 과정에서 GitHub Actions, Docker, AWS ECR, EC2, Nginx 등 다양한 기술 스택을 다뤄보았고, 코드를 작성하는 건 별로 없지만 과정을 이해해 보면서 알게 된 게 많은 것 같다.

특히, React, Spring Boot, FastAPI를 모두 포함한 멀티 모듈 환경을 배포하면서 서비스 간 연동 구조를 이해하는 데 많은 도움이 됐다. 처음에는 Nginx 설정 문제와 ECR 푸시 과정에서 어려움을 겪었지만, 로그를 보면서 원인을 분석하고 해결책을 찾는 과정을 통해 문제 해결 능력도 향상됐다.

이제 남은 기간 동안은 파이널 프로젝트에서 코드를 많이 써볼 수 있도록 열심히 해야겠다.

부트캠프 23주차 회고 - 블레이버스 해커톤 대상

호기심 많은 솔이 — Mon, 1 Sep 2025 02:29:37 +0900

처음 참가한 해커톤에서 대상이라는 예상치 못한 결과를 받았다.

사실 해커톤을 준비하면서도 부족한 점을 많이 느꼈고, 대회 도중에도 문제 해결 과정에서 어려움을 겪을 때가 많았다. 그래서 상을 받겠다는 생각은 못했었는데, 막상 대상을 받게 되니 놀랍고 감사하다는 생각을 했던 것 같다.

이번 해커톤에서 배운 점이 많은데,

우선, 해커톤을 준비하고 진행하는 과정에서 단순한 개발 실력뿐만 아니라 팀워크와 문제 해결 능력의 중요성을 크게 체감했다. 짧은 시간 안에 아이디어를 구체화하고, 팀원들과 역할을 분담하며 빠르게 개발을 진행하는 과정에서 애자일 프로세스의 중요성에 대해서도 배울 수 있었다.

우리팀에 PM이 없어서 얼떨결에 PM 역할 까지 맡게 됐는데, 이 과정에서 우선순위를 설정하고, 논의 사항에 대해 결정하는 능력이 얼마나 중요한지도 깨달을 수 있었고, 발표를 준비하면서 일주일간 진행했던 프로젝트에 대한 이해도도 높일 수 있어서 좋았다.

처음에는 완성도 높은 결과물을 내는 것보다 배움과 다양한 경험에 초점을 두고 참가했다. "상을 못 받아도 경험만으로 충분히 의미가 있다”라고 생각했는데, 큰 상을 받게 되어 더 의미가 있는 시간이었다.

이번 주부터 파이널 프로젝트가 시작됐는데, 해커톤에서의 경험을 밑거름 삼아, 파이널 프로젝트에서도 좋은 결과를 낼 수 있도록 열심히 해야겠다.

부트캠프 22주차 회고

호기심 많은 솔이 — Mon, 25 Aug 2025 02:49:31 +0900

이번 주는 해커톤을 준비하고 진행하느라 정신없이 지나갔다.

짧은 시간 안에 MVP를 구현해야 해서 쉽지 않았지만, 그 과정에서 내가 부족한 점을 알 수 있었고, 앞으로 보완해야 할 점들을 정리할 수 있었다.

이번 해커톤에서 다양한 직군과의 협업을 통해 개발 과정 전반에 대한 프로세스 이해도를 높일 수 있었던 것이 가장 큰 수확이었다. 디자이너, 기획자, 개발자 각자의 관점을 배울 수 있었고, 커뮤니케이션의 중요성을 확실하게 체감할 수 있었다.

이번 해커톤을 통해 아직 많이 부족하다는 걸 깨달았지만, 동시에 새로운 기술을 빠르게 익히고 적용하는 능력을 키울 수 있었던 값진 시간이었다.

이 경험을 바탕으로 앞으로 어떤 프로젝트를 진행하든 더 효율적이고 체계적으로 접근할 수 있을 것 같다.

해커톤이 끝나면 파이널 프로젝트를 본격적으로 시작하게 될 텐데, 이번 경험에서 배운 점을 최대한 활용해서, 더 큰 성장을 이루기 위해 열심히 해야겠다.

부트캠프 21주차 회고 - 2025 블레이버스 MVP 개발 해커톤 시즌2 참여

호기심 많은 솔이 — Sun, 17 Aug 2025 19:55:36 +0900

이번 주 수요일에는 블레이버스 해커톤 킥오프가 있었고, 이후 본격적으로 협업을 시작했다.

해커톤 규칙에 따라 디자이너, PM, 개발자가 반드시 팀에 포함되어야 하는데, 우리 팀은 PM을 구하지 못한 상황이었다. 처음에는 경험이 많고 프론트 개발도 가능한 팀원이 PM을 맡아주면 좋겠다고 생각해 부탁드렸지만, 본인은 자신이 없다고 하셔서 결국 PM을 맡을 팀원이 없는 상태가 되었다.

그때 팀장인 내가 PM을 맡아볼까 라는 생각도 했지만, 한편으로는 디자인이나 프론트에 대한 지식이 거의 없었기 때문에 부담스러운 자리였다. 하지만, 오히려 이번 기회를 통해 다른 직군들과 협업할 때 필요한 프로세스에 대한 이해도를 높일 수 있지 않을까 하는 생각이 들었고 결국 내가 PM을 맡기로 결정했다.

협업이 시작된 후, 다른 팀원분들이 많이 도와주고 계시지만, 전반적인 기획, 일정 관리, 의사 결정은 내가 주도적으로 맡아 진행하게 되었다. 단순히 백엔드만 고려하는 것이 아니라 디자인과 프론트까지 종합적으로 조율해야 해서 쉽지는 않았다. 하지만 새로운 도전을 통해 배울 점이 많을 것이라는 생각에 동기부여가 되었다.

아직은 부족한 점이 많지만, 이번 경험을 통해 개발 과정의 전체적인 프로세스에 대한 이해와 협업 능력을 크게 키울 수 있을 것 같다. 단순히 개발자의 시각에서만 머무르지 않고, 프로젝트 전체를 바라보는 경험을 할 수 있다는 점에서 의미가 크다고 생각한다.

부트캠프 20주차 회고

호기심 많은 솔이 — Mon, 11 Aug 2025 12:25:30 +0900

지난주에 토이프로젝트 4가 끝나고 첫 주를 보냈다.

이제 1주 뒤면 기업 연계 파이널 프로젝트가 시작된다.

파이널 프로젝트를 시작하기 전까지 주어진 2주라는 시간을 어떻게 활용할지 고민해 봤는데, 자바 복습을 해야겠다는 생각이 들었다. 그래서 이번 주에는 자바 복습에 집중했고, 자바의 정석 4판 기준으로 7장까지 내용을 정리하고 복습을 완료했다. 이를 통해 자바의 기본 문법과 객체지향 개념을 다시 한번 점검할 수 있었다.

다음 주부터는 학원 내에서는 수업이 진행될 예정이고, 학원 외부에서는 따로 해커톤을 진행할 예정이라서 자바 복습까지 병행하려면 일정이 상당히 빠듯할 것 같다. 주어진 시간을 밀도 있게 활용하여 세 가지 모두에서 성과를 낼 수 있도록 계획을 세우고 집중력을 높여야 할 것 같다. 이번 기간을 통해 한 단계 더 성장할 수 있도록 열심히 해야겠다.

부트캠프 19주차 회고 - Langchain을 이용한 비트코인 정보 제공 챗봇 구현

호기심 많은 솔이 — Sun, 3 Aug 2025 19:47:22 +0900

토이프로젝트4가 마무리되었다.

<프로젝트 개요>

이번 프로젝트에서 우리 7팀은 SpringBoot, Langchain, RAG, PostgreSQL, Redis를 이용하여 암호화폐 정보를 제공하는 챗봇을 구현하였다.

<주제 선정 배경 : 문제 인식>

우리 팀에서 주제를 선정하기 위해 가장 먼저 생각했던 부분은 ChatGPT와 같은 범용 LLM 모델들의 한계점이 무엇인지였다. 이번 프로젝트에 주어진 기간이 3주였는데, 이 기간과 팀원들의 지식을 고려했을 때, ChatGPT보다 어느 한 부분이라도 강점을 보일 수 있다 성공이라고 생각했기 때문이다. 이 생각에 따라 우리 팀은 ChatGPT의 한계점이 무엇일까에 대해 분석하기 시작했고, ChatGPT는 과거의 데이터를 기반으로 사용자에게 답변을 하기 때문에 실시간성이 다소 부족하다는 점을 발견하였다.

위 사진을 보면 ChatGPT 4o 모델은 유료 모델임에도 불구하고, 현재 시각(UTC) 기준, 8분 이상 뒤쳐진 정보를 바탕으로 사용자에게 답변을 해주고 있음을 알 수 있다.

이 결과에 따라 실시간성을 보완했을 때, 강점이 있을 만한 주제에 대해 생각해 보았고, 비트코인이라는 주제를 선정하게 되었다.

<주요 기능 소개 : 해결 방안>

ChatGPT에 대한 분석을 통해 알게 된 문제점인 실시간성을 개선하여 '비트코인'이라는 주제에 적용시킬 방법에 대해 우리 팀이 떠올린 방법은 Upbit에서 제공하는 비트코인의 실시간 가격 정보를 Websocket을 통해 실시간으로 받아오고, 해당 데이터를 Redis에 캐싱하여 사용자의 질문이 들어왔을 때, 해당 데이터를 바탕으로 답변을 해주는 것이었다.

위 정보를 바탕으로 사용자에게 답변을 해줄 때, 비트코인 현재 가격, 기본 차트, RSI, MACD와 같은 차트 등을 plotly 라이브러리를 통해 시각화하여 사용자에게 제공한다.

하지만, 이 기능 하나만으로는 RAG를 구성하기에 부족하다는 생각이 들었고, 추가 기능으로는 비트코인 관련 뉴스 기사를 바탕으로 사용자의 질문에 적합한 답변을 해주는 것을 생각하였다.

<기능 구현>

비트코인 관련 뉴스 기사 정보는 Newdata.io의 API를 통해 받아왔고, 이 데이터에 포함된 기사의 URL 정보로 Newspaper3k라는 라이브러리를 이용하여 크롤링을 진행하였다. Newsdata.io에서 기사 정보를 받아올 수 있는데도 Newspaper3k 라이브러리를 이용한 이유는 API를 통해 받아온 데이터에는 기사 본문의 일부만 포함되어 있었기 때문이다. 또한, newspaper3k 라이브러리는 beautifulsoup, selenium이 광고, 해시태그 등의 불필요한 정보까지 받아오는 것과 달리, HTML을 분석하여 기사의 본문 내용만 받아오기 때문에 해당 라이브러리를 사용하기로 결정하였다.

위 과정을 통해 수집한 뉴스 기사 데이터는 ada-002 모델을 통해 임베딩한 후 pgvector라는 벡터DB에 저장하였다.

<시스템 동작 흐름>

사용자가 챗봇에 질문을 하면, 사용자의 질문이 임베딩되고, 이 질문 벡터와 유사한 벡터값을 가지는 기사를 pgvector에서 찾는다. 이후 해당 기사의 내용과 DB, Redis에 저장된 코인 정보들을 바탕으로 사용자에게 답변을 해주는 방식으로 시스템을 구현하였다.

<회고>

이번 프로젝트를 진행하면서 아직 배울 게 많다는 것을 느꼈다. 특히, RAG 구성에 대한 이해가 부족해 초기 설계 단계에서 많은 시행착오를 겪었고, 제한된 기간 때문에 검색 정확도 개선 등 아직 해결하지 못한 문제들을 남겨둔 채로 프로젝트를 마무리해야 했던 점이 아쉬웠다.

하지만, 팀원들과 협업하여 실시간 데이터 수집, 캐싱, 임베딩 기반 검색 구조를 직접 구현해 보는 등 좋은 경험이 되었다.

이번 프로젝트에서 가장 의미 있다고 생각하는 부분 중 하나는, 실제로 존재하는 문제점을 발견하고, 그 문제점을 해결하기 위한 방안에 대해 많은 생각을 해봤다는 점이다. 내 아이디어를 통해 세상에 존재하는 문제를 해결할 수 있다는 점이 개발자라는 직업의 가장 매력적인 부분이라고 생각한다.

앞으로도 많이 배우고, 많이 생각하며, 세상의 문제들을 해결하는 개발자로 성장하고 싶다.

부트캠프 18주차 회고

호기심 많은 솔이 — Sun, 27 Jul 2025 22:09:54 +0900

토이 프로젝트4 2주차가 끝났다.

전체적인 아이디어와 구현 방향, 사용 기술에 대한 설계는 구체화되었지만, 설계한 대로 실제로 구현하는 과정은 쉽지 않았다.

프로젝트 마감까지 약 일주일 정도 남은 상황에서, 현재 발생한 문제들을 해결하고 설계한 기능들을 구현하기 위해 시간을 효율적으로 활용해야겠다는 생각이 들었다.

처음에 구상했던 모든 기능을 완벽하게 구현하지는 못하더라도, 과제 요구사항에서 제시된 기본 요건은 충족할 수 있도록 남은 기간 동안 팀원들과 함께 집중하여 마무리를 잘할 수 있도록 열심히 해봐야겠다.

부트캠프 17주차 회고

호기심 많은 솔이 — Sun, 20 Jul 2025 19:23:50 +0900

이번 주부터 토이프로젝트4가 시작 됐다.

우리 팀에서는 저번 주까지 강의해주신 랭체인을 바탕으로 rag를 구성하여 비트코인과 관련된 질문에 답변, 요약을 해주고 차트를 띄워주는 챗봇을 만드는 것을 목표로 하고 있다.

과거의 정보만을 바탕으로 답변을 해주는 chat gpt와 달리, 우리 팀의 챗봇에서는 Upbit에서 실시간 코인 정보를 받아오고, 크립토 뉴스에서 최근 기사를 받아와서, 실시간성이 있는 답변을 해준다는 것이다.

아직 시작 단계이고, 생각한 기능들을 모두 구현할 수 있을지는 모르겠지만 목표를 최대한 달성할 수 있도록 열심히 해봐야겠다.

부트캠프 16주차 회고 - Langchain 학습

호기심 많은 솔이 — Sat, 12 Jul 2025 21:10:57 +0900

이번 주에는 황후순 강사님께서 AI 기본 지식과 랭체인(LangChain)에 대해 강의를 해주셨다.

랭체인은 LLM(Large Language Model) 기반 애플리케이션을 쉽게 개발할 수 있도록 도와주는 오픈소스 프레임워크이다.

강사님이 공유해 주신 예제 코드를 바탕으로, 함수나 툴을 만들고 수정해 보면서 입력에 따라 출력이 어떻게 달라지는지 간단하게 실습을 해보았다.

<실습 사진>

재밌는 결과가 나왔다.

다음 주부터는 이 LangChain을 활용한 프로젝트를 본격적으로 진행하게 되는데, 아직은 AI나 랭체인에 대해 모르는 게 많아서 조금 걱정이 된다.
하지만 실습과 강사님의 피드백을 통해 차근차근 배워가며 이해도를 높일 계획이다.

이번 프로젝트를 통해 AI 기반 애플리케이션 개발에 대한 감각을 익히고, 랭체인을 어떻게 실무에 적용할 수 있을지 구체적으로 탐색해보고 싶다.

부트캠프 15주차 회고

호기심 많은 솔이 — Sun, 6 Jul 2025 22:45:31 +0900

이번 주에는 파이썬 기본 문법과 AI에 대한 기초적인 내용을 학습했다.

이전에 파이썬을 사용해 본 적이 있어서 조금 익숙하긴 했지만, 기억이 나지 않거나 헷갈리는 내용이 많았고, 목요일에 봤던 시험에서도 쓰지 못한 문제가 꽤 있었다.

다음 주에는 본격적으로 AI 실습을 진행하게 될텐데, 실습을 진행하면서 파이썬이 나올 때마다 부족한 부분을 찾아서 채워가는 식으로 해야겠다.

다음 주는 해야할 일이 지금까지 중에 가장 많은 것 같다. 다 끝낼 수 있도록 집중해 보자 화이팅!

부트캠프 14주차 회고

호기심 많은 솔이 — Mon, 30 Jun 2025 15:31:01 +0900

토이 프로젝트가 마무리 됐다.

토이 프로젝트를 진행하면서 많은 것을 배웠다.
특히, 협업 시 팀원들과 소통하는 법, 의사 표현 및 의사 결정 방법에 대해 많이 배웠다.

아쉬웠던 점은 피그마, 지라와 같은 협업 툴들을 적극적으로 활용해보지 못했다는 것이다. 또다른 아쉬운 점은 더 많은 연습과 경험을 해보지 못했다는 것이다.

다음 프로젝트 진행 시에는 다양한 협업 툴들을 활용하여 효율적으로 협업을 진행할 수 있도록 미리 협업 툴들을 다뤄봐야겠다. 또, 다음 프로젝트 진행 시에는 내가 맡은 부분이 일찍 끝나더라도 다른 부분을 더 시도해보거나, 추가 기능, 개선 방향 등에 대해서도 고민해보는 시간을 가져봐야겠다.

부트캠프 13주차 회고 - 토이프로젝트2

호기심 많은 솔이 — Sun, 22 Jun 2025 20:05:29 +0900

<토이 프로젝트2 진행 후 팀 회고>

- github 이슈 관리

앞으로 진행해야 할 이슈들

현재까지 완료한 이슈들

- Pull Requests

팀 PR 목록

- PR 예시

- github 프로젝트 관리

- 팀 회고 표

<토이 프로젝트2 진행 후 개인 회고>

- 구현 내용 정리

Keep

- 적극적으로 의견 제시하기

- 효율적인 스케줄 관리

- 구체적인 역할 분배 및 본인이 맡은 도메인에 대해 책임 다하기

Problem

- 구현한 기능들에 대해 이해가 덜 된 부분이 있음

- git, vim 사용에 익숙하지 않음

- 협업 시 발생 가능한 이슈들(머지 시 충돌, 코드 스타일 불일치, 패키지 충돌 등)에 대해 익숙하지 않음

Try

- 보충 학습을 통해 이해도 높이기

- 브랜치, 명령어 등에서 실수가 난 경우 노션에 정리해 두기

- 프로젝트를 진행하면서 발생했던 이슈들과 해결 방법들을 기록해 두기

부트캠프 12주차 회고 - 토이 프로젝트1 : 쇼핑몰 ERD 설계

호기심 많은 솔이 — Sun, 15 Jun 2025 18:11:44 +0900

<토이 프로젝트1 진행 후 팀 회고>

토이 프로젝트1, 9팀 ERD

팀 회고 내용

<토이 프로젝트1 진행 후 개인 회고>

Keep

- 적극적으로 의견 제시하기

- 효율적인 스케줄 관리

- 구체적인 역할 분배 및 본인이 맡은 도메인에 대해 책임 다하기

Problem

- 단호한 말투로 말하기

- 업무 우선 순위 기준 불명확

- 일별 시간 분배에서의 아쉬움

Try

- 부드러운 말투로 말하기

- 업무 우선 순위 구체적으로 정하기

- 제출 기한에 대한 여유를 가질 수 있도록 미리 더 해두기

부트캠프 11주차 회고 - ERD 스터디

호기심 많은 솔이 — Sat, 7 Jun 2025 18:29:08 +0900

이번 주는 스프링 부트를 공부하고, 프로젝트의 방향성과 시도해 볼 기술들에 대해 많은 생각을 했던 한 주였다. 게다가 이번 주에는 그룹 스터디로 진행하고 있었던 쇼핑몰 ERD 설계도 거의 완성했다. ERD 스터디를 진행하면서 어려운 것들이 많았지만 서로 도와가며 열심히 해 준 덕분에 ERD 설계에 대해 많이 배웠고, 기대 이상의 결과도 나온 것 같다.

우리 그룹 스터디의 쇼핑몰 ERD

목요일에는 앞으로 3주간 토이 프로젝트를 함께할 팀원들이 정해졌다. 대부분 처음 뵙는 분들이었지만, 실무에서도 익숙한 환경이 아닌 상황에서 협업하는 경우가 많을 것이기에 오히려 좋다고 생각했다. 정해진 팀원 분들과 모여서 이야기를 나눠보니 다들 성실하고 실력도 있으신 것 같아서 같이 열심히 하면 좋은 결과를 낼 수 있겠다는 생각이 들었다. 나도 열심히 참여해서 팀원들에게 도움이 되고 자극이 되는 사람이 되어야겠다.

교육을 다니면서 배운 것들을 바탕으로 실제로 뭔가를 만들어 보고 싶다는 생각을 항상 하고 있었는데, 드디어 월요일이 오면 진짜 시작이다. 아직 지식적으로도 부족하고 경험이 적어서 걱정도 되지만 팀원들과 서로 도와가며 열심히 한다면 많이 성장할 수 있을 것이라 생각한다. 처음부터 너무 많은 것을 하려고 하기보다는 하나하나 정확하고 깊게 이해하고 배우는 것이 이번 프로젝트에서의 가장 큰 목표이다.

부트캠프 10주차 회고

호기심 많은 솔이 — Sun, 1 Jun 2025 18:53:33 +0900

이번 주부터는 스프링을 본격적으로 배우기 시작했다. 예전에 스프링부트를 사용해 본 적은 있지만, 제대로 된 이해 없이 기능 구현에만 집중했었기 때문에 머릿속에 남아있는 게 별로 없었다. 이번에 수업을 들으면서 처음 접하는 개념들도 있었고, 이전에는 알았던 개념들도 새롭게 느껴지는 것들이 많았다. 그래도 수업을 듣다 보면 중요했던 개념들이나, 관련된 개념들이 조금씩 떠올라서 검색도 해보고 GPT에게 물어보는 식으로 학습을 진행하고 있다.

6월 9일부터는 토이 프로젝트를 시작하게 되어 기대가 되지만, 이번에 스프링을 공부하면서 부족한 점이 많이 보여서 걱정도 된다. 특히, 아직 자바가 부족하다는 생각이 들었다. 자바 복습을 일주일 만에 끝낼 수는 없기때문에 다음 주에는 자바의 핵심 개념과 이전에 공부하면서 어려웠던 개념들만이라도 다시 보는 것을 목표로 해야겠다.

이번 프로젝트에서는 이전처럼 기능 구현에만 급급하지 않고, 내부 동작 원리와 구조를 제대로 이해해보고 싶다. 단순히 작동하도록 만드는 것에 그치는 것이 아니라, 왜 이렇게 동작하는지, 이 방식이 어떤 장단점을 가지는지, 어떤 방식이 더 효율적 일지와 같은 고민들을 하며 진행하고 싶다. 이를 통해 나중에 문제가 발생했을 때 스스로 원인을 분석하고 개선 방향을 제시할 수 있는 실력을 키우는 것이 가장 큰 목표이다.

[이번 주에 공부한 것]

[다음 주 목표]

- 자바 핵심 개념 및 어려웠던 개념들 복습

- 스프링(부트) 주요 개념 및 큰 틀을 이해할 수 있도록 학습

- 프로젝트 진행 시 뭘 해보고 싶은지 미리 생각해두기

부트캠프 9주차 회고

호기심 많은 솔이 — Sat, 24 May 2025 16:30:27 +0900

[저번 주 회고 때 작성한 이번 주 목표 및 달성 여부]

~~- 평일 4일 이상 남아서 공부하기~~

- 블로그 꾸준히 작성하기

~~- 주말에 나와서 공부하기~~

- 매일 12시 취침

- 꾸준히 운동하기

이번 주는 계획대로 해낸 것도 있지만, 예상치 못한 변수가 생기면서 완전히 만족스러운 한 주는 아니었다. 특히, 손목 부상을 당하면서 매일 하던 운동 루틴을 갑작스럽게 중단하게 된 것이 가장 아쉬운 부분이었다. 운동은 내 일상의 활력소 같은 존재였기에 하루가 조금 허전하게 느껴졌다.

하지만, '어쩔 수 없다면 그 시간을 더 의미 있게 쓰자'는 생각이 들었다. 이왕 이렇게 된 김에 다음 주에 있을 진로 상담에 대한 준비도 좀 하고, 그동안 밀려 있던 할 일들도 조금씩 따라잡고, 6월 초에 시작될 프로젝트에 대한 준비도 미리 해둬야겠다.

이번 주에는 스프링을 배우기 시작했다. 생각보다 어려웠다. 예전에 스프링 부트를 사용해본 적이 있어서 기억이 나는 부분도 조금 있긴 했지만 아직 갈 길이 멀고, 더 열심히 해야겠다는 생각이 들었다. 다음 주에는 원래 운동을 하던 시간을 공부 시간으로 바꾸고 집중력 더 끌어올려야겠다.

[다음 주 목표]

- 평일 4일 이상 남아서 공부하기

- 블로그 꾸준히 작성하기

- 주말에 나와서 공부하기

- 매일 12시 취침

부트캠프 8주차 회고 - 내 페이스대로 살기

호기심 많은 솔이 — Sun, 18 May 2025 17:47:51 +0900

[저번 주 회고 때 작성한 이번 주 목표 및 달성 여부]

~~- 평일 4일 이상 남아서 공부하기~~

- 블로그 꾸준히 작성하기

~~- 주말에 나와서 공부하기~~

- 플래너 작성

- 매일 12시 취침

- 매일 아침 일찍 운동하기

이번 주부터는 플랜을 바꿨다. 저번주까지는 매일 아침 등원 전에 운동을 하려고 했었는데, 시도해 보니 운동을 못 하는 날이 많아져서 마치고 운동을 하는 게 맞다고 생각했다. 마침 학원과 같은 건물에 짐박스가 생겨서 당분간 여기서 운동을 하기로 결정했다. 운동을 마치고는 다시 학원으로 와서 10시까지 부족한 공부를 보충하고 일과를 마쳤다. 이 루틴으로 바꾸고 나서 공부 시간은 조금 줄었지만 매일 활력이 생겨서 공부를 할 때 집중이 더 잘 됐던 것 같다. 다음 주에도 해야 할 일이 많으니까 이번 주보다 조금만 더 열심히 해보자!

뭘 하든, 다른 사람들이 뭐가 좋다고 하든 나한테 맞는 방식을 찾는 것이 가장 좋은 것 같다.

[다음 주 목표]

- 평일 4일 이상 남아서 공부하기

- 블로그 꾸준히 작성하기

- 주말에 나와서 공부하기

- 매일 12시 취침

- 꾸준히 운동하기

부트캠프 7주차 회고 - 매일 1%씩 발전하는 사람 되기

호기심 많은 솔이 — Sat, 10 May 2025 16:14:53 +0900

[저번 주 회고 때 작성한 이번 주 목표 및 달성 여부]

- 평일 4일 이상 남아서 공부하기

- 블로그 꾸준히 작성하기

~~- 주말에도 하루 이상 나와서 공부하기~~

- 플래너 작성

- 매일 12시 취침

- 매일 아침 일찍 일어나서 운동하기

이번 주는 연휴가 포함되어 있어서 첫 번째 목표는 지키지 못했고, 블로그도 쓰지 못했다. 학원에 나오기 전날에는 피로가 쌓여서 그런지 딱 12시는 아니더라도 평소보다는 일찍 잠에 들었다. 하지만 플래너를 쓰지 못했고 아침 운동도 빠진 날이 많았다.

매주 회고를 쓰고 "다음주는 더 잘해야지"라고 마음을 먹어도, 바로 실천하기가 쉽지는 않은 것 같다. '"사람은 쉽게 바뀌지 않는다.'"라는 말이 떠올랐다. 매일 아침 일찍 나오시고 주말에도 빠짐없이 나오시는 분들이 새삼 대단해 보인다. 그렇다고 해서 '나는 원래 잠이 많으니까'라고 나를 한정 짓고 싶지는 않다. 습관을 하루아침에 고치기는 쉽지 않겠지만 나의 나쁜 습관을 인지하고 있는 한 적어도 노력은 해보는 게 맞다고 생각한다.

완벽한 사람이 될 순 없겠지만 매일, 매주 조금씩이라도 내 단점들을 개선하며 발전하는 사람이 되기 위해 노력해야겠다.

[다음 주 목표]

- 평일 4일 이상 남아서 공부하기

- 블로그 꾸준히 작성하기

- 주말에 나와서 공부하기

- 플래너 작성

- 매일 12시 취침

- 매일 아침 일찍 운동하기

목표를 전부 지키진 못하더라도 이번 주보다는 나은 사람이 되자.

부트캠프 6주차 회고 - 하고 싶은 것보다 해야 하는 것이 먼저

호기심 많은 솔이 — Mon, 5 May 2025 18:04:31 +0900

[저번 주 회고 때 작성한 이번 주 목표 및 달성 여부]

~~- 평일 4일 이상 남아서 공부하기~~

~~- 블로그 꾸준히 작성하기~~

- 주말에도 하루 이상 나와서 공부하기

~~- 플래너 작성~~

- 매일 12시 전에 잠들기

- 매일 아침 일찍 일어나서 운동하기

이번 주를 한 문장으로 정리하면,

좋게 말하면 "놀 땐 놀고 할 땐 하자"였지만 객관적으로 보면 만족스러운 한 주는 아니었다.

딴짓, 잡생각을 평소보다 많이 했던 것 같다.

[이번 주 문제점]

딴짓, 잡생각을 평소보다 많이 했다.

플래너를 써보고 이번 주를 돌아보며 낭비한 시간을 생각해 보니 평소보다 조금 더 많았던 것 같다.

매일 갇혀서 공부만 하다 보면 쉬고 싶기도 하고 놀고 싶기도 한 건 당연한 것이겠지만, 지금은 조금 자제할 필요가 있다는 생각이 들었다. 저절로 드는 생각까지 제어할 수는 없지만, 그 생각이 항상 행동으로 가는 건 내 잘못이다.

매일 루틴을 지키지 못하고 있다.

2주 전 회고에서 공부, 운동을 다 잡겠다고 자신 있게 썼던 것과 달리, 계획했던 기상 시간도 못 지킬 때가 많았다. 다음 주에는 매일 루틴 지키기에 더 신경을 써서 말만 앞서는 사람이 되지 않도록 하자.

[어떻게 해결할까?]

하고 싶은 것보다 해야 하는 것이 먼저이다. 본분을 잊지 말자.

현재의 내 상황과 목표를 항상 생각하고, 지금 나에게 가장 중요한 게 무엇인지 생각하고 행동하자. "너무 급해지지 말자", "너무 집착하지 말자"는 핑계로 나를 너무 풀어놓았던 것 같다. 틀린 말은 아니지만, 여유 부릴 때는 아니다.

[다음 주 목표]

- 평일 4일 이상 남아서 공부하기

- 블로그 꾸준히 작성하기

- 주말에도 하루 이상 나와서 공부하기

- 플래너 작성

- 매일 12시 취침

- 매일 아침 일찍 일어나서 운동하기

-> 이번 주는 지난주보다는 일찍 잠에 들었던 것 같다. 아침에 운동도 세 번은 갔으니 저번 주보다는 나아졌다.

매주 목표를 세우고 실행해 보니 다음 주 목표를 완벽하게 지키기는 어렵지만 조금씩은 나아지고 있는 것 같다.

다음 주에는 이번 주보다 조금 더 나아지는 것을 목표로 해보자.

[Java] 최종 과제

호기심 많은 솔이 — Wed, 30 Apr 2025 18:59:16 +0900

<설계>

순서도

-> 검토하면서 발견했는데 "Score 같은가?"에서 "예"일 때 "special비교"로 가야 하고 "아니오"일 때 1등에게 승+1, 돈+100, 나머지 패+1로 가야 함!

Game 클래스

Card 클래스

CardDeck 클래스

Dealer 클래스

HandRankEvaluator 클래스

Player 클래스

2025-05-05 18:27 1차 완성

<Card 클래스>

Card 클래스

<CardDeck 클래스>

CardDeck 클래스

<Dealer 클래스>

Dealer1

Dealer2

<HandRankEvaluator 클래스>

HandRankEvaluator1

HandRankEvaluator 2

HandRankEvaluator 3

HandRankEvaluator 4

HandRankEvaluator 5

HandRankEvaluator 6

HandRankEvaluator 7

<Player 클래스>

Player 1

Player2

Player3

Player4

<Game 클래스>

Game 1

Game2

Game3

Game4

<출력 결과>

출력 결과

-> 출력 결과를 보면, 플레이어 수를 입력받는 부분은 의도했던 방향대로 출력되고 있음을 볼 수 있고, 플레이어 닉네임을 입력 받는 경우, 나머지는 잘 됐지만, 1, 2번 플레이어 닉네임의 입력을 한 번에 받고 있음을 볼 수 있다. 또한, 플레이어 닉네임 목록을 출력할 때, 닉네임이 출력되지 않고 해시값이 출력되는 것을 볼 수 있다. 마지막으로 최종 결과 출력부를 보면, 100번의 게임을 모두 출력하고 있는 것을 볼 수 있다.

-> 수정해야 하는 부분

1. 1,2번 플레이어의 닉네임을 나눠서 받도록 수정해야 함.

2. 닉네임 목록을 출력할 때 해시값이 아니라 닉네임이 출력되도록 해야 함 -> Player클래스에 toString을 오버라이드 해야 할 듯.

3. 최종 결과가 매 게임마다 총 100번 출력됨 -> 매 게임마다 승자만 출력하고, 100게임 이후 최종 결과는 한 번만 출력하도록 해야 함.

[디자인 패턴] 전략 패턴 (Strategy Pattern)

호기심 많은 솔이 — Mon, 28 Apr 2025 21:25:06 +0900

전략 패턴이란?

전략패턴은 "변하지 않는 부분"과 "변하는 부분"을 분리해서, "변하는 부분(전략)"을 객체로 캡슐화하여 따로 분리하고, 필요할 때 "전략"을 갈아 끼울 수 있도록 만드는 디자인 패턴이다.

예를 들어, 게임 캐릭터가 공격할 때, 어떤 캐릭터는 칼로 공격하고, 어떤 캐릭터는 활을 쏴서 공격한다. 하지만, "공격"이라는 행동 자체는 공통이다. 이때 "공격 방법"만 다르게 하고 싶어서 사용하는 것이 Strategy Pattern이다.

이 경우, 각각의 공격 방식들이 전략에 해당한다.

ex) 전략1 : 칼을 이용하여 공격, 전략2 : 활을 쏴서 공격, 전략3 : 표창을 던져서 공격

위의 예시를 코드로 작성하려면, "공격"은 인터페이스로 만들고, 각 공격 방법(전략)을 클래스로 만든 후, 각 클래스에서 "공격" 인터페이스를 구현하면 된다.

전략 패턴의 기본 구조

Strategy Pattern 기본 구조

- Context : Strategy 인터페이스를 참조하여 실제 전략 객체와 통신한다. Context는 구체적인 전략이 어떤 것인지 알 필요 없이, 전략 인터페이스만을 통해 행동을 수행한다.

- Strategy 인터페이스 : 모든 구체 전략(Concrete Strategy)들이 반드시 구현해야 할 공통 메서드를 정의한다.

- ConcreteStrategies : 다양한 전략(알고리즘/로직)의 구체적인 구현체이다. 각 클래스는 Strategy 인터페이스를 구현하여 서로 다른 동작을 제공한다.

- Client : 필요한 구체 전략 객체를 생성한 후, Context에 주입한다. 이 과정을 통해 Context는 런타임에 동적으로 전략을 변경할 수 있다.

전략 패턴을 사용하지 않은 경우와 사용한 경우의 코드 예시 및 비교

<전략 패턴을 사용하지 않은 경우>

전략 패턴을 사용하지 않은 경우 예시 코드

<전략 패턴을 사용한 경우>

위의 전략 패턴 기본 구조에서 Context, Strategy, ConcreteStrategy, Client에 대응하는 인터페이스와 클래스들

Context : 전략을 사용하는 캐릭터

Strategy : 공격 전략

ConcreteStrategy 1 : 칼로 공격하는 전략

Concrete Starategy 2 : 마법으로 공격하는 전략

Concrete Strategy 3 : 주먹으로 공격하는 전략

Client : 전략 패턴 메인 메서드

<비교>

이제 위의 예시 코드를 바탕으로 전략 패턴을 사용하지 않은 경우와 전략 패턴을 사용한 경우를 비교해 보자면,

전략 패턴을 사용하지 않은 경우는 하드 코딩 방식으로 되어 있어 공격 방법이 코드 내부에 고정되어 있으며, 공격 방식을 변경하거나 새로운 공격 방식을 추가하려면 attack() 메서드를 직접 수정해야 한다. 따라서 유연성이 낮고, 전략이 하나씩 추가될 때마다 else-if 문을 추가해야 하기 때문에 유지보수가 어렵다. 또한, 기존 코드를 수정해야만 기능을 확장할 수 있기 때문에 SOLID 원칙 중 OCP를 위반하게 된다.

반면, 전략 패턴을 사용한 경우에는 변경/확장 시 새로운 전략 클래스를 추가하기만 하면 되기 때문에, 유연성이 높고, 유지보수가 쉬우며, OCP를 준수할 수 있다.

*OCP (Open-Closed Principle, 개방-폐쇄 원칙) : 소프트웨어 요소는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다는 원칙이다. 즉, 기존 코드를 변경하지 않고 기능을 추가할 수 있어야 한다.

<전략 패턴을 사용했을 때의 장단점>

- 장점

1. OCP 원칙 준수 : 새로운 공격 방법(전략)을 추가할 때, 기존 코드를 전혀 고칠 필요 없이 새 클래스만 추가하면 된다.

2. 코드 유연성 증가 : 실행 도중에(런타임에) 다른 전략으로 쉽게 바꿀 수 있다. setAttackStrategy()만 호출하면 다른 공격 전략을 사용할 수 있다.

3. 중복 제거, 코드 정리 : attack() 메서드 안에 복잡한 if-else 문이 없어지고, 전략별로 코드가 깔끔하게 분리된다.

4. 테스트 용이성 : "칼로 공격"과 같은 특정 전략만 따로 테스트할 수 있다. (Unit Test 용이)

5. 유지보수 편리 : 전략 클래스 별로 수정할 수 있어, 다른 코드에 영향 없이 수정이 가능하다.

6. 클래스 재사용성 향상 : "칼로 공격"과 같은 하나의 전략을 여러 다른 객체가 공유할 수 있다.

- 단점

1. 클래스 수 증가 : 전략마다 별도 클래스를 만들어야 하므로 프로젝트가 크면 클래스가 너무 많아져서 복잡해질 수 있다.

2. 조립 복잡성 : 전략이 많아지면 전략 객체를 생성하고 주입하는 과정이 번거로울 수 있다.

3. 오버스펙 : 간단한 로직인데도 억지로 전략 패턴을 쓰면 오히려 코드가 복잡하고 불편해질 수 있다.

-> 위의 예시 코드도 사실 이 경우에 해당한다. 위의 예시는 단지 전략 패턴을 쉽게 이해하기 위한 것. 위의 예시처럼 전략이 2~3개밖에 안 되고 절대 바뀌지 않는 경우에는 전략 패턴을 쓰면 오히려 오버스펙이 될 수 있음.

4. 의존성 관리 필요 : 위의 예시로 치면 캐릭터가 공격 전략에 의존하게 되므로, 객체를 잘 관리해야 한다.

->전략 패턴을 사용하면 복잡한 if-else 문을 없애고 유연성과 확장성을 얻을 수 있지만, 클래스가 많아져서 복잡해질 수 있으니 상황에 따라 적절히 사용하자!

<위의 예시 코드 클래스 다이어그램>

클래스 다이어그램

*참고) 디자인 패턴을 이해하기 위한 클래스 다이어그램 기본 개념 - https://curiousjung1997.tistory.com/26

디자인 패턴을 이해하기 위한 클래스 다이어그램 기본 개념

*본 게시글은 추후 디자인 패턴에 대한 글을 작성할 때 도입할 클래스 다이어그램과, 클래스 다이어그램에서의 연관 관계에 대한 이해를 돕기 위해 작성하였습니다. 클래스 다이어그램이란?시

curiousjung1997.tistory.com

<실무 사례>

- 결제 방식 선택 시스템 (카카오페이, 카드결제, 계좌결제, 휴대폰결제 등)

- 로그인 인증 방식 선택 시스템 (소셜 로그인, 토큰 기반 로그인, 세션 기반 로그인 등)

디자인 패턴을 이해하기 위한 클래스 다이어그램 기본 개념

*본 게시물은 refactoring.guru 사이트를 참고하여 작성하였음을 밝힙니다.

일부 사진 출처 :

https://refactoring.guru/design-patterns/behavioral-patterns

부트캠프 5주차 회고 - 규칙적으로 생활하기

호기심 많은 솔이 — Sun, 27 Apr 2025 15:49:49 +0900

[저번 주 회고 때 작성한 이번 주 목표 및 달성 여부]

~~- 평일 4일 이상 남아서 공부하기~~

~~- 블로그 꾸준히 작성하기~~

~~- 주말에도 하루 이상 나와서 공부하기~~

- 플래너 작성

- 매일 12시 전에 잠들기

- 매일 아침 일찍 일어나서 운동하기

이번 주에도 나름 열심히 공부했지만, 저번 주에 설정했던 목표들 중 절반밖에 달성하지 못했다. 그래도 주말에도 나와서 공부하는 습관을 조금씩 들여가고 있다는 점은 긍정적이었다.

[이번 주 문제점]

첫 번째 문제는 플래너를 준비해놓고도 제대로 활용하지 못했다는 점이다.

저번 주 회고 때, 시간을 효율적으로 쓰지 못하고 있는 것 같다는 생각이 들어서 플래너를 써보려고 가져왔지만 사물함에 넣어둔 채 까맣게 잊고 있었다. 하루하루 흐름에 맡기는 식으로 시간을 쓰게 되었고, 결국 이번 주도 시간을 효율적으로 관리하지 못했던 것 같다.

두 번째 문제는 수면 패턴이 불규칙했다는 것이다.

원래는 11시에 잠자리에 들고, 12시에 취침하는 것을 목표로 했지만, 매일 10시까지 학원에 남아 공부하다 보니 계획한 시간에 잠에 들기가 어려웠다. 이런 패턴이 계속되면서 빨래, 설거지도 밀리게 되고 생활 전반에 여유가 사라진 느낌이 들었다.

세 번째 문제는 아침 운동을 꾸준히 이어가지 못했다는 점이다.

매일 아침 운동하는 루틴을 짜고 시도했지만, 매일 아침 6시에 일어나는 게 생각보다 어려웠다.

[어떻게 해결할까?]

다음 주에는 플래너를 적극적으로 활용해서 하루를 더 구체적으로 계획하고 관리해보려고 한다.

매일 아침마다 그날 해야 할 일과 목표를 정리하고, 하루가 끝날 때는 어떤 시간대에 시간을 낭비했는지를 체크해서 시간을 효율적으로 관리할 수 있도록 노력해 봐야겠다. 특히 주 단위로 해야 할 공부량을 미리 구체적으로 정해놓고, 이를 일별로 나누어 매일 해야 할 분량을 채워가는 식으로 관리해 보면 좋을 것 같다.

또한, 공부 시간에만 너무 집착하기보다는, 학원에 있는 동안은 최대한 집중하되, 생활 패턴을 지키는 데에도 더 신경을 써야겠다.

아침 운동 루틴은 다음 주까지 다시 도전해볼 예정이다.

만약 다음 주에도 잘 안 된다면, 무리하게 아침 운동을 고집하지 않고 이전처럼 저녁에 하는 것도 좋을 것 같다.

취준은 결국 장거리 달리기라는 말도 있듯이, 지금 당장의 성과에 집착하기보다는, 작은 습관을 꾸준히 이어가는 것이 더 중요하지 않을까?

[다음 주 목표]

- 평일 4일 이상 남아서 공부하기

- 블로그 꾸준히 작성하기

- 주말에도 하루 이상 나와서 공부하기

-> 이 3개는 그대로 가져가고,

- 플래너 작성 -> 이번 주에는 까먹지 말고 꼭 써서 다음 주 회고 때 업로드 하자!

- 매일 12시 취침

- 매일 아침 일찍 일어나서 운동하기 -> 다음 주에도 잘 안되면 그냥 저녁에 해야겠다.

-> 이 3개는 이번 주에는 더 신경써서 꼭 지켜보자.

디자인 패턴을 이해하기 위한 클래스 다이어그램 기본 개념

호기심 많은 솔이 — Fri, 25 Apr 2025 12:36:57 +0900

*본 게시글은 추후 디자인 패턴에 대한 글을 작성할 때 도입할 클래스 다이어그램과, 클래스 다이어그램에서의 연관 관계에 대한 이해를 돕기 위해 작성하였습니다.

클래스 다이어그램이란?

시스템의 구조를 클래스 단위로 표현한 UML(Unified Modeling Language)으로, 클래스들 간의 속성, 메서드, 그리고 관계(상속, 연관 등)를 시각적으로 보여주는 다이어그램이다. 클래스 다이어그램에서 클래스는 클래스명, 변수, 메서드 순으로 나열한다.

<예시>

클래스 다이어그램 예시1

위의 예시를 통해 클래스 다이어그램에 대해 간단히 설명하자면,

각 사각형의 맨 윗부분에 적혀있는 "ChessPiece"와 같은 것들은 클래스명, 그 아랫 부분에 "- color : String", "+ get_color"와 같은 것들은 각 클래스의 멤버(변수 및 메서드)이다. 각 멤버의 맨 앞에 붙어있는 +, - 와 같은 것들은 접근 제어자를 의미하고, +는 public, -는 private, #은 protected를 의미한다. 마지막으로, 형광펜으로 표시한 1, 2, 3번과 같은 화살표들은 각 클래스들 간의 연관 관계를 나타내는 기호인데, 이 기호들은 아래에 간단히 정리해 보겠다.

클래스 간의 연관 관계를 나타내는 기호

1. Association (연관)

두 클래스 간에 어떤 관계가 있다는 것을 나타낸다. 한 객체가 다른 객체를 참조하거나 사용하는 관계이다.

예를 들어, "학생-강의"는 학생은 강의를 듣고, 강의는 여러 학생과 관련이 있다는 것을 나타낸다.

2. Inheritance (상속)

한 클래스가 다른 클래스의 속성과 기능을 물려받는 관계이다. 자식 클래스가 부모 클래스의 기능을 재사용하면서 확장이 가능하다. 예를 들어, "동물 <- 강아지"는 강아지가 동물의 속성과 행동을 물려받는다는 것을 의미한다. 표기는 빈 삼각형 화살표로 한다.

3. Realization / Implementation (구현)

클래스가 인터페이스의 기능을 실제로 구현하는 관계임을 나타낸다. 인터페이슨느 "무엇을 해야 하는지", 클래스는 "어떻게 할지"를 정의한다. 예를 들어, "Bird < - - Flyable"은 Bird가 Flyable 인터페이스를 구현한다는 것을 의미한다. 표기는 빈 삼각형 화살표와 점선으로 한다.

4. Dependency (의존)

한 클래스가 다른 클래스의 기능을 일시적으로 사용하는 관계이다. 이 연관 관계는 메서드 파라미터나 지역 변수로 다른 클래스를 참조할 때 생긴다. 예를 들어, "주문" 클래스가 "결제" 클래스를 사용하는 경우에 의존 관계가 생긴다. 표기는 점선 화살표로 하고 일시적인 관계를 나타낸다.

5. Aggregation (집합)

전체와 부분의 관계를 나타내지만, 독립적으로 존재할 수 있다. 즉, 전체가 사라져도 부분은 살아있을 수 있다. 예를 들어, 팀-선수의 관계에서 팀이 사라져도 선수는 존재할 수 있다. 표기는 빈 마름모로 하고 마름모가 있는 쪽이 전체, 나머지 한쪽이 부분을 나타낸다. 화살표가 있는 경우 전체 -> 부분 방향으로 한다.

6. Composition (합성)

전체와 부분의 관계를 나타내지만, 강한 소유관계로, Aggregation(집합) 관계와 달리, 전체가 사라지면 부분도 같이 사라진다. 즉, 생명주기를 함께하는 강한 결합을 나타낸다. 예를 들어, "집-방"에서 집이 사라지면 방도 사라진다. 표기는 채워진 마름모로 하고, Aggregation과 동일하게 마름모 쪽이 전체, 반대쪽이 부분을 나타낸다.

<클래스 다이어그램 예시>

클래스 다이어그램 예시2

위 클래스다이어그램 예시를 보면,

Person클래스는 Creature인터페이스를 Implementation(구현) 하고 있고, Address클래스를 참조하고 있다.

Student클래스와 Professor클래스는 이 Person클래스를 Extends(상속) 받고 있다.

이 중 Student클래스와 Transcript는 Composition(합성) 관계이므로 Transcript클래스는 Student클래스가 사라지면 함께 사라진다. 또한, SoonInJung이라는 학생은 Student클래스를 Extends(상속) 받고 있다.

SeongNamKung클래스는 Professor클래스를 Extends(상속) 받고 있고, Professor클래스와 Course클래스는 Aggregation(집합) 관계이다. 집합 관계는 합성 관계와 달리 전체가 사라지더라도 부분이 사라지지는 않는다.

**참고한 사이트**

https://adacomputerscience.org/questions/oop_04_v2

[Java] 인터페이스에도 완성된 메서드를 쓴다고?

호기심 많은 솔이 — Wed, 23 Apr 2025 17:32:51 +0900

*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

지금까지 인터페이스는 상수와 추상 메서드만 선언할 수 있는, 말 그대로 '껍데기'라고만 알고 있었다. 그런데 오늘 인터페이스에도 구현된 메서드, 즉 static과 default 메서드를 정의할 수 있다는 사실을 처음 알게 되었다.

처음 알게 된 개념이어서 궁금한 점이 많았고, 여러 자료를 찾아보며 공부한 내용을 이 글에 정리해 보았다.

결과부터 말하자면, 이전에는 내가 알던 대로 인터페이스에는 무조건 추상 메서드만 쓸 수 있었다. 하지만, 자바 8부터는 완성된 default 메서드와 static 메서드를 쓸 수 있게 된 것이다.

우선 인터페이스에서의 default 메서드와 static 메서드에 대해

1. 호출 방법

2. 오버라이딩 가능 여부

3. 사용하는 이유

에 대해 간단히 설명한 후,

인터페이스에서 default 메서드와 static 메서드를 어떻게 사용하고 있는지 예시 코드를 보면서 설명해 보겠다.

1. 호출 방법

- default 메서드의 경우 car.turnOnLights()와 같이 인스턴스로 메서드를 호출한다.

- static 메서드의 경우 Car.companyInfo()와 같이 인터페이스명으로 메서드를 호출한다.

2. 오버라이딩 가능 여부

- default 메서드는 오버라이딩이 가능하다.

- static 메서드는 오버라이딩이 불가능하다.

--> 아래 예시 코드 설명할 때 자세히 설명 예정.

3. 사용하는 이유

- 인터페이스 구현 클래스에 기본 동작 제공

- 도구성, 유틸리티 메서드 제공

<예시 코드>

Car Interface

위의 Car 인터페이스를 보면 추상 메서드, default 메서드, static 메서드가 정의되어 있다.

여기서 추상 메서드는 상속받은 클래스에서 반드시 구현해야 하는 메서드이고, default 메서드는 이미 구현이 되어 있어 Car의 공통 동작을 제공하지만, 원한다면 Override 하여 구현 내용을 바꿀 수 있다. 마지막으로, static 메서드는 클래스처럼 공통으로 사용하는 유틸성 메서드로써, 모든 Car의 기본 틀 정도로 이해할 수 있고, default 메서드와 달리 오버라이딩을 할 수 없다.

이제 이 Car 인터페이스를 구현한 HyundaeCar클래스와 KiaCar클래스를 보면서 추가 설명을 해보겠다.

Car Interface를 구현한 HyundaeCar 클래스

Car 인터페이스를 구현한 HyundaeCar 클래스를 보면, 추상 메서드인 drive의 내용을 구현한 것을 볼 수 있고, Car 인터페이스의 default 메서드 turnOnLights를 오버라이딩하여 구현 내용을 바꾼 것을 볼 수 있다. 하지만, 이 클래스에는 Car 인터페이스에는 있었던 static 메서드인 companyInfo()는 없는 것을 확인할 수 있는데, 이는 인터페이스에서 만든 static 메서드는 그 인터페이스 자체에 귀속되기 때문이다. 호출 시에도 HyundaeCar의 객체가 아닌 인터페이스 이름(Car)으로만 호출이 가능하다.

이번에는 Car 인터페이스를 구현한 KiaCar 클래스를 보면,

Car Interface를 구현한 KiaCar 클래스

추상 메서드인 drive()는 직접 구현하였고, HyundaeCar클래스와 달리, default 메서드는 보이지 않는다. default 메서드는 직접 오버라이딩 하지 않아도 기본적으로 제공되기 때문이다.

마지막으로 CarMain클래스를 보면,

CarMain 클래스

출력값

각 메서드에 구현된 내용이 출력되는 것을 볼 수 있다. 여기서 주의할 점은 static 메서드인 companyInfo()는 인터페이스의 추상 메서드 drive, default 메서드 turnOnLights()를 객체를 통해 호출하는 것과 달리, 인터페이스명으로 호출한다는 것이다.

[Java] 컬렉션 프레임워크와 Big O 표기법을 통한 간단한 성능 비교 : 개발자는 소프트웨어의 성능을 향상시키기 위해 존재한다.

호기심 많은 솔이 — Tue, 22 Apr 2025 21:56:25 +0900

*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

컬렉션 프레임워크란?

컬렉션 : 여러 객체를 모아 놓은 것.

프레임워크 : 표준화, 정형화된 체계적인 프로그래밍 방식

-> 컬렉션 프레임워크 : 데이터를 효율적으로 저장하고 처리하기 위한 자료구조와 알고리즘을 제공하는 Java의 표준 라이브러리.

<Collection 인터페이스 상속 계층도>

Collection 인터페이스 상속 계층도

위 그림은 Collection 인터페이스 상속 계층도이고, 여기서 검은색 박스는 인터페이스, 파란색 박스는 각 인터페이스를 상속받아 구현한 클래스들이다.

각 인터페이스들에 대해 간단하게 설명하자면,

List는 순서 O, 중복 O

Set은 순서 X, 중복 X

Map은 Key, Value쌍으로 데이터를 저장하는 자료구조이며, key는 중복 X, value는 중복O

Q) 돌발 퀴즈

아래의 3문장 중 어떤 문장이 틀린 문장일까요? 이유는? - 정답은 맨 아래에

1. Stack st = new Stack();

2. Queue q = new Queue();

3. Queue q = new LinkedList();

<Collection 인터페이스들을 구현한 클래스들 간단한 설명>

ArrayList

- 배열 기반 리스트

- 접근(탐색)이 빠르다.(인덱스)

- 삽입/삭제는 느리다.

- Vector와 달리 동기화X -> 락(lock)을 걸 필요가 없어서 빠르게 작동하고, 코드가 가벼워짐. But 멀티스레드 환경에서 위험할 수 있음.

LinkedList

- 접근(탐색)이 느리다.

- 삽입/삭제는 빠르다.

Stack

- LIFO 자료구조

PriorityQueue

- 일반적인 Queue가 먼저 들어온 순서대로 나가는 것과 달리, 정해진 우선순위가 높은 값이 먼저 나가는 큐, 우선순위 큐에 저장할 객체는 필수적으로 Comparable 인터페이스를 구현해야함.

-> 최단거리를 구할 경우, 작업 스케줄링 등에 사용

Deque

- 양쪽 끝에서 삽입과 삭제가 가능한 자료구조.

HashSet

- 데이터의 중복X 순서X, null값도 하나만 저장 가능.

- 가장 빠르고 기본적인 Set.- 내부적으로 HashMap 사용.- 삽입/삭제/탐색 속도 빠름 : O(1) //대신 순서를 전혀 예측할 수 없다.

--> 빠른 중복 제거 필요시 사용

Linked HashSet

- 입력한 순서를 유지하는 Set.- 속도는 HashSet보다 느림 (O(1)이지만 링크 관리 비용 존재)

--> 순서를 유지하면서 중복 제거 할 때 사용

TreeSet

- 정렬된 상태를 유지하는 Set. (자동 정렬)- Comparable, Comparator 필요- 속도는 O(log n)

--> 정렬된 상태로 데이터를 저장하고 싶을 때 사용

HashMap

- 일반적인 Map 구현체.- 순서 X, key중복 X, value중복 O- null key 1개, null value 여러 개 가능.- 동기화 X -> 스레드 안전 X but 빠름. (여러 스레드가 동시에 접근하면 문제가 생길 수 있으나 단일 스레드 환경에서는 불필요한 lock이 없어서 훨씬 빠르다.)

Linked HashMap

- 입력 순서를 유지하는 HashMap (입력 순서 그대로 키가 유지됨)- 성능은 HashMap보다 약간 떨어짐.

--> 입력 순서를 기억해야 할 때 사용

TreeMap

- Key를 기준으로 정렬된 Map (기본은 오름차순) ex) 입력 순서에 관계없이 {1=A, 2=B, 3=C...}- 속도는 O(log n)으로 Map 중 가장 느림.- null key 불가, null value는 가능.

--> 정렬이 필요할 때 사용

<간단한 성능 비교>

컬렉션 프레임워크의 대표적인 자료 구조인 ArrayList와 LinkedList를 성능(실행시간) 측면에서 비교해 보겠다.

(사실 성능은 시간복잡도+공간복잡도를 모두 고려해야 하지만 여기서는 시간적인 측면만 고려해서 작성하겠다.)

- Big O Notation

그전에 성능을 객관적인 수치로 비교하기 위해 필요한 개념인 Big O Notation에 대해 간단히 설명하자면, Big O Notation은 알고리즘이나 연산이 입력 크기 n에 따라 실행시간이 얼마나 빠른지를 표현하는 수학적 도구이다.

예를 들어, for문으로 i=1~10까지 반복한다면 10번의 연산이 필요하다. 이때 입력값의 크기 n=10이고, 연산도 총 10번이 필요하다. 즉, 입력값 n번만큼의 연산이 필요하므로 이를 Big O Notation으로 O(n)으로 표기한다.

그럼 for문 안에 for문이 중첩되어 있는 경우에는 어떨까? 위의 예시와 동일하게 입력값의 크기를 n=10이라고 하자. 즉, i가 1~10인 for문을 중첩하여 쓴 경우를 생각해 보자. 첫 번째 for문의 각 i마다 두 번째 for문의 i는 1~10까지 순회한다. 첫 번째 for문도 i값이 10개이므로 총 연산 수는 10의 제곱인 100이 된다. 즉, 입력값이 n일 때, n^2번만큼의 연산이 필요하므로 Big O Notation으로 O(n^2)으로 표기한다.

Big O Notation에는 주의해야 할 점이 있다.

첫 번째로는 O(?)의 ?에 들어갈 식은 최고차항만 표기하고, 계수는 항상 1로 한다는 것이다. 예를 들어, 어떤 알고리즘의 입력값의 크기가 n일 때, 연산 수가 2n^2 + 3n + 1이라고 하면, 최고차항인 2차항의 계수가 1이라는 점만 ?에 쓴다는 것이다. 따라서 이 경우에 Big O Notation은 O(2n^2)이 아닌 O(n^2)이 된다.

두 번째는 Big O Notation에서는 "최악의 경우 시간복잡도"를 기준으로 쓴다는 것이다. 예를 들어, ArrayList에 데이터를 삽입할 때, 최선의 경우는 마지막 인덱스에 데이터를 삽입하는 경우이고, 이때 단 한 번의 연산만이 필요하다. 평균적인 경우는 정중앙에 데이터를 삽입하는 경우인데, 이 경우 오른쪽 절반의 데이터들을 모두 한 칸씩 오른쪽으로 옮겨야 하므로 ArrayList의 크기가 n인 경우, (1/2)n번의 연산이 필요하다. 최악의 경우는 인덱스 0번에 데이터를 삽입하는 경우이고, 모든 데이터를 오른쪽으로 옮겨야 한다. 즉, ArrayList의 크기가 n인 경우, n번의 연산이 필요하다. 따라서 ArrayList에서 데이터를 삽입하는 경우의 시간 복잡도를 Big O Notation으로 표기하면 O(n)이 된다.

Big O Notation을 왜 알아야 하는가?

-> 개발자는 소프트웨어의 성능을 향상하기 위해 존재한다. 여기서 말하는 SW의 성능 향상이란 프로그램의 실행시간 즉, 시간복잡도를 의미하고 이를 수학적으로 표현하는 방법이 바로 Big O Notation이다. 컬렉션 프레임워크의 존재 이유는 데이터를 얼마나 효율적으로 관리하고 처리하느냐에 있는데, 이를 Big O Notation을 통해 객관적으로 파악할 수 있기 때문이다. 컬렉션 프레임워크의 다양한 클래스들을 상황에 맞게 사용하면 SW의 성능을 향상시켜 비용을 줄일 수 있다는 것이다.

따라서 우리는 주어진 문제 상황에서 어떤 자료구조를 사용하는 것이 효율적 일지에 대해 반드시 이해하고 있어야 한다.

이제 이 Big O Notation을 도입하여 ArrayList와 LinkedList에서 상황 별로 어떤 자료구조가 왜 효율적인지에 대해 설명해 보겠다.

<ArrayList>

크기가 n인 ArrayList에서 데이터를 탐색하는 경우는 인덱스를 통해 단 한 번의 연산으로 가능하다. -> O(1)

같은 ArrayList에서 데이터를 2번 인덱스에 삽입하려는 경우, 그림의 파란색 화살표와 같이 2번부터 n번까지의 모든 데이터를 오른쪽으로 한 칸씩 밀어야 한다. 따라서 (n-2)+1번의 연산이 필요하다. 인덱스 0번에 데이터를 삽입해야 하는 최악의 경우에는 총 n+1번의 연산이 필요하다.-> O(n)

<LinkedList>

크기가 n인 LinkedList에서 데이터를 탐색하는 경우는 순차적으로 모든 노드를 순회해야 하므로 마지막 인덱스에 있는 데이터를 찾아야 하는 최악의 경우 총 n번의 연산이 필요하다. -> O(n)

같은 LinkedList에서 데이터를 0번과 1번 인덱스에 삽입하려는 경우, 그림의 빨간색 화살표와 같이 노드 0번의 next를 Data로 바꾸고, 노드 1번의 prev를 Data로 바꾸면 된다. 따라서 총 2번의 연산만이 필요하고, 어떤 위치에 삽입하든 항상 동일하다. -> O(1)

결과를 정리하면, 데이터를 탐색하는 경우는 ArrayList가 유리하고, 데이터를 삽입, 삭제하는 경우는 LinkedList가 유리하다.

이처럼 어떤 자료구조를 쓰느냐에 따라 상황에 따른 효율이 크게 달라질 수 있다.

돌발퀴즈 정답 : 2번 - 인터페이스는 객체를 생성할 수 없다. 3번은 타입은 Queue이지만 LinkedList 클래스의 객체.

[Java] 두 변수가 같은 값을 가지는데 왜 다르다고 나올까?

호기심 많은 솔이 — Tue, 22 Apr 2025 17:25:02 +0900

*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

제목에 대한 답을 얻기 위해서는 우선, 자바에서의 "동등성"과 "동일성"에 대해 이해해야 한다.

우리는 자바를 공부하면서 "동등성"과 "동일성", 그리고 "equals 메서드"와 "=="에 대해 들어본 적이 있을 것이다.

자바에서 동등하다는 것은 "값"이 같다는 것을 의미하고, 동일하다는 것은 "주소"가 같다 즉, 같은 객체를 가리킨다는 것을 의미한다.

또한, equals 메서드는 기본적으로는 주소비교지만, 오버라이딩 시 내용 비교가 가능하고, String, Integer, List, Set, Map 등은 기본적으로 내용 비교로 오버라이딩 되어 있다.

반면, 연산자 "=="은 기본형인 경우에만 "값"을 비교하고, 이외에는 항상 "주소"를 비교하여 결과값을 반환한다. 기본형은 변수에 값 자체가 저장되고, 객체이면 참조형 변수에 주소가 저장되기 때문이다.

이제 코드 예시를 통해 위 내용을 자세히 설명해볼텐데, 그전에 위의 내용을 잘 이해했는지 돌발 퀴즈! (답변은 제일 아래에)

Q) int a = 10, int b = 10일 때, a.equals(b)를 하면 어떻게 될까요?

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

<equals() 메서드>

우선, 본문에서 equals 메서드는 기본적으로 주소비교(동일 비교)라고 했었는데, 그와 관련된 예시 코드를 먼저 보여주자면

equals 메서드는 기본적으로 동일성을 따진다.

위 코드의 출력값

위 코드와 출력값을 보면, 직접 생성한 Val 클래스의 객체 v1, v2의 값을 동일하게 10으로 초기화하였음에도 불구하고 v1.equals(v2)의 값은 false가 나온다. 이는 equals 메서드가 기본적으로 "값"이 아닌 "객체가 가리키는 주소"를 의미한다는 것이다. 하지만, 코드의 11번째 줄에서 v2 = v1을 실행하고 나면 v1.equals(v2)의 값이 true로 바뀐다. 이 11번째 줄에서 v2가 가리키는 객체가 v1이 가리키는 객체와 같아졌기 때문이다.

하지만, equals 메서드가 항상 주소 비교(동일 비교)만 하는 것은 아니다!

본문에서 언급했듯이 오버라이딩 시에는 내용 비교(동등 비교)도 가능하고, String, Integer, List, Set, Map과 같이 기본적으로 내용 비교(동등 비교)를 하도록 오버라이딩 된 경우도 있다.

그와 관련된 예시 코드를 보여주자면

이 코드에서 s1과 s2는 별개의 객체이다. 즉, s1과 s2이 가리키고 있는 주소는 다르다.

그런데도 왜 s1.equals(s2)는 true일까?

-> String 클래스는 equals 메서드를 내용 비교로 오버라이딩 해놓았기 때문!

<연산자 "==">

이번에는 연산자 "=="에 대한 예시 코드를 보여주면서 상황에 따른 차이를 비교해 보겠다.

본문에서 "연산자 "=="은 기본형인 경우에만 "값"을 비교하고, 이외에는 항상 "주소"를 비교하여 결과값을 반환한다."라고 하였는데 이 설명에 대한 예시 코드를 보여주자면

위 코드를 보면 기본형 int형으로 초기화한 변수 a와 b는 "값"이 10으로 같으므로 "a==b"의 결과값이 true가 나왔다. 반면, Val클래스의 객체로 생성한 변수 v1과 v2는 "v1==v2"의 결과값이 false가 나왔다. 이 결과를 보면 본문에서 언급한 내용과 같다는 것을 알 수 있다.

정리하자면, equals() 메서드와 연산자 "=="은 모두 상황에 따라 "값"을 비교하는지, "주소"를 비교하는지가 달라지므로 어떤 상황에 어떤 식으로 비교하는지를 정확하게 알고 사용하는 것이 필수적이다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

<돌발퀴즈 정답>

컴파일 오류가 나온다.

->기본형 변수는 객체의 참조형 변수와 달리 메서드를 사용할 수 없기 때문.

+추가)

이 경우 참조형 변수 s1과 s2가 가리키는 주소가 다를까?

-> 같다. (String Constant Pool 때문)

s1, s2는 new로 각각의 새로운 객체를 생성한 것이 아니다. 따라서 참조형 변수 s1이 선언될 때, 문자열 리터럴 "Hello"는 힙의 객체가 있는 공간이 아니라, 힙 내부의 String Pool이라는 특별한 메모리 공간에 저장된다. 이후, String s2 = "Hello"와 같이 같은 리터럴이 다시 등장하는 경우, "Hello"라는 리터럴을 String Pool에 새로 추가하는 것이 아니라 기존 풀에 있던 객체를 재사용한다. 즉, s2도 원래 있던 "Hello"를 가리키게 되는 것이다. 결국 s1과 s2는 같은 주소를 갖게 된다.

이는 int i1 = 10. int i2 = 10인 경우와는 다른 경우임에 주의해야한다. 기본형인 int는 주소가 아니라 값을 저장하기 때문에 i1, i2는 주소 자체가 존재하지 않는다.

[Java] 메서드에 값을 넘겼는데 값이 왜 안 바뀔까?

호기심 많은 솔이 — Sat, 19 Apr 2025 18:33:29 +0900

*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

*본 게시물은 남궁성 강사님의 자바의 정석 교재를 참고하여 작성하였습니다.

Q) 첫 번째 코드와 두 번째 코드의 출력값이 각각 어떻게 나올까? 이유는 뭘까?

스크롤을 내려 글을 읽으시기 전에 먼저 스스로 답을 생각해 보시길 바랍니다.

<첫 번째 코드의 출력값>

<두 번째 코드의 출력값>

두 코드의 출력값이 다르게 나오는 이유는 change 메서드의 매개변수 타입이 다르기 때문이다.

-> 매개변수의 타입이 기본형일 때와 참조형일 때의 차이를 이해해야한다.

자바에서는 메서드를 호출할 때 매개변수로 지정한 값을 메서드의 매개변수에 복사하여 전달한다. 매개변수가 기본형이면 값 자체가 복사되어 전달되므로, 메서드 내에서 변경해도 원본 변수(인스턴스 변수 'd.x')에는 영향이 없다. 반면, 참조형의 경우에는 '값'이 아니라 '객체의 주소'가 복사되어 전달되기 때문에, 메서드 내에서 객체의 상태를 변경하면 원본 객체에도 반영된다.

기본형 매개변수를 가지는 change메서드가 포함된 첫 번째 예시 코드

1. 우선 코드를 실행하면 main 메서드를 읽는다. main 메서드 내에서 Data 타입의 Data 객체를 생성하고 참조변수 d가 그 객체를 가리키게 된다.

2. d.x = 10에서는 위에서 생성한 객체의 x값을 10으로 초기화한다.

3. change(d.x)에서 change메서드가 호출되면 d.x가 change메서드의 매개변수 x에 복사된다.

4. change메서드 내에서 x=1000을 읽으면 change메서드 내에서 x의 값을 1000으로 변경한다.

5. 다음 메서드인 println이 실행되면, change메서드가 종료되면서 매개변수 x(로컬 변수)는 스택에서 제거된다.

-> 이 경우에 인스턴스 변수 d.x의 값이 변경된 것이 아니라, change메서드 내에서만 존재하는 로컬 변수 x값이 변경된 것이다.

6. 따라서 d.x값을 출력하면 변경 전과 동일한 10이 나오게 된다.

참조형 매개변수를 가지는 change메서드가 포함된 두 번째 예시 코드

1. main 메서드를 읽고, Data 타입의 Data 객체 d를 생성한 후 인스턴스 변수 d.x를 10으로 초기화한다.

2. change(d)를 호출한다.

3. 이 코드에서의 change메서드는 매개변수가 기본형이 아니라 참조형이기 때문에 '값'이 아니라 '값이 저장된 주소'를 change메서드에 넘겨준 것이다.

-> 매개변수 d에 저장된 주소값으로 인스턴스 변수인 x에 접근이 가능해졌다!

4. change메서드 내에서 d.x=1000을 읽어서 인스턴스 변수 값을 10에서 1000으로 변경하였다.

5. 첫 번째 예시에서 change메서드 내의 로컬 변수만 변경한 것과 달리, 인스턴스 변수값을 변경하였으므로 change메서드가 종료되어 매개변수 d의 값이 스택에서 제거된 후에도 change메서드에서 변경한 값이 유효하다.

-> 첫 번째 예시 코드에서는 change메서드의 매개변수가 기본형이었기 때문에 변수 x에 '값 자체'를 복사만 해왔던 것과 달리, 이 두 번째 예시 코드에서는 change메서드의 매개변수가 참조형이기 때문에 변수 d에 '객체의 주소'가 저장되어 있다. 즉, main메서드의 참조변수 d와 change메서드의 참조변수 d는 같은 객체를 가리키게 된다. 따라서 change메서드의 매개변수 d로 그 객체를 참조하여 객체의 인스턴스 변수값을 변경할 수 있는 것이다.

부트캠프 4주차 회고

호기심 많은 솔이 — Fri, 18 Apr 2025 21:02:49 +0900

저번 주 회고 때 작성한 이번 주 목표 및 달성 여부

~~- 평일 3일 이상 남아서 공부하기~~

~~- 블로그 꾸준히 작성하기~~

- 자바의 정석 배운 데까지 1회독

- 주말 중 하루 이상 나와서 공부하기

- 목표 구체화 시키기

4월 18일 금요일 20:41 기준 2개는 달성했고 3개는 아직 달성하지 못했다.

저번 주까지는 강사님 설명이 이해는 됐었는데 이번 주부터는 이해가 안 되는 부분이 생기기 시작했고 1주일 동안 꽤 많이 쌓인 것 같다. 특히, 지네릭스 부분은 너무 어려웠다. 저번 주 회고 때는 이번 주말에 일단 하루는 나와보자고 생각했었는데 나와야만 하는 상황이 돼 버렸다. 일단 내일은 꼭 학원에 나와서 지금까지 나간 진도에서 이해가 잘 안 됐던 부분들을 중점으로 책을 쭉 읽어보면서 어느 정도는 이해를 해놔야 다음 주가 있을 것 같다.

이번 주를 돌아보면 저번 주보다는 낫지만 아직 문제점이 많이 보인다.

우선, 시간을 효율적으로 못 쓰는 것 같다. 다음 주부터는 플래너를 작성하면서 시간을 효율적으로 쓸 수 있도록 해봐야겠다.

또, 이번 주부터는 원래 저녁에 마치고 했던 운동을 아침 일찍 일어나서 하고, 저녁에는 남아서 공부를 하려고 했었는데 아침 일찍 일어나는 게 힘들어서 운동을 이틀밖에 하지 못 했다. 늦어도 6시 30분에는 일어나야 운동을 하고 올 수 있는데 자기 전에 딴짓도 좀 하고 폰도 좀 보고 하다 보면 보통 1시쯤은 돼서야 잠에 들었던 것 같다. 다음 주부터는 늦어도 12시 전에는 잠에 들 수 있도록 해봐야겠다.

다음 주 목표

- 평일 4일 이상 남아서 공부하기

- 블로그 꾸준히 작성하기

- 주말에도 하루 이상 나와서 공부하기

- 플래너 작성

- 매일 12시 전에 잠들기

- 매일 아침 일찍 일어나서 운동하기

[Java] p는 Child 객체인데, 왜 p.x는 Child의 변수가 아닐까?

호기심 많은 솔이 — Wed, 16 Apr 2025 21:19:57 +0900

오늘 아래의 연습 문제를 풀다가 이해가 되지 않는 부분이 생겨서 그 부분에 대해 공부한 후 이 글을 쓰게 되었다.

Q) 다음의 코드를 실행한 결과를 적으시오.

내가 했던 생각을 적어보자면, Parent p = new Child();에서 p가 가리키는 객체는 Parent타입이지만 Child의 객체이다. 따라서 p.x는 Child 객체의 x값이 출력돼야 하고, p.method()를 호출하면 Child 클래스의 메서드 내용이 출력돼야 한다.

~~따라서 이 코드를 실행한 결과는~~

~~p.x = 200~~

~~child Method~~

~~c.x = 200~~

~~child Method~~

~~이다.~~

하지만 실제 출력 결과는 달랐다.

실제 출력 결과

출력의 첫 줄에서 p.x = 200이 아니라 p.x = 100이 출력되었다.

이 출력 결과를 보고 이해가 가지 않아서 내가 뭘 모르고 있었는지, 올바른 개념은 무엇인지 궁금해져서 검색을 통해 찾아보고 GPT한테도 물어보았다.

여기서 얻은 결과를 정리해 보자면,

p.method()는 내가 생각했던 대로 실제 객체가 Child이므로 child Method가 출력되는데, 그 이유는 메서드는 기본적으로 동적 바인딩(Dynamic Binding) 대상이므로 런타임 시점에 어떤 메서드를 호출할지가 결정된다. 즉, 참조 변수가 가리키고 있는 메모리 주소를 통해 실행되는 것이다.

이와 달리, p.x에서 x는 변수(필드)인데, 변수(필드)는 항상 정적 바인딩(Static Binding) 대상이다. 즉, 컴파일 시점에 어떤 멤버를 사용할지가 결정되므로 Parent 타입을 기준으로 결정되는 것이다. 따라서 p.x의 값은 Child 객체의 x값인 200이 아니라, Parent 객체의 x값인 100이 출력된 것이다.

Q) 여기서 컴파일 시점에 결정되면 왜 Parent타입 기준으로 결정되는 거고, 런타임 시점에 결정되면 왜 Child타입 기준으로 결정되는 거지?

-> (일반) 메서드는 자식 클래스에서 오버라이딩이 가능하기 때문에, 자바는 method()를 실행할 때까지 기다렸다가 실제 객체가 누구인지 보고 결정한다. 이것이 동적 바인딩이고, 동적 바인딩은 다형성의 핵심 개념이다.

하지만, 변수는 바뀌지 않기 때문에 ★타입만 보고 결정★ 해도 된다. 이것이 정적 바인딩이다.

여기서 컴파일 시점, 런타임 시점이라는 용어의 의미와 정적 바인딩, 동적 바인딩이라는 용어의 의미를 간단히 설명해 보자면,

컴파일 시점이란?

- 자바 코드를 .java로 작성하고 컴파일러가 .class 파일로 바꾸는 시점.

- 오타, 타입 오류 등을 잡아내는 시점.

--> 예를 들어, 인텔리제이에서 우리가 코드를 작성 중인 시점. 실행시키기 전에 느낌표나 빨간 줄이 뜨는 그 시점으로 이해하면 된다.

런타임 시점이란?

- 코드를 실제로 실행한 다음, JVM이 돌아가는 시점.

- 예외가 발생하거나 실제 객체가 메서드를 실행하는 시점.

- main() 실행 후 코드들이 동작하는 그 순간 정도로 이해하면 된다.

바인딩이란?

-> 어떤 메서드나 변수에 연결되는 것. 쉽게 말해, 어떤 메서드나 변수를 쓸 건지 결정하는 것.

정적 바인딩이란?

- 바인딩이 컴파일 시점에 일어나는 것. 컴파일러가 "이 변수는 얘 거다!" 하고 고정해버림

- 적용 대상 : 필드(변수), static 메서드, final 메서드, private 메서드.

동적 바인딩이란?

- 바인딩이 런타임 시점에 일어나는 것. 즉, 코드 실행 중에 "이 메서드는 실제로 어떤 객체의 것을 호출해야 하지?"를 판단함.

- 적용 대상 : 인스턴스 메서드(일반 메서드)

2025-04-15 Java 문제풀이

호기심 많은 솔이 — Tue, 15 Apr 2025 15:39:25 +0900

*코드 개선을 위한 훈수 언제든 환영입니다.

기존에 작성한 클래스에서 이전 채널의 값을 저장할 멤버변수 prevChannel을 정의하고, setChannel 메서드에서 입력받은 매개변수로 채널을 변경하기 전에 현재 채널을 prevChannel에 저장하도록 하면 gotoPrevChannel 메서드를 실행하였을 때, 이전 채널로 돌아갈 것이라 생각해서 아래와 같이 코드를 작성하였다.

이렇게 코드를 작성하고 아래의 main문을 실행해 보니 원하는 출력이 나오지 않았다.

위 코드를 보면 처음에 gotoPrevChannel()을 실행했을 때는 이전 채널인 Ch10으로 잘 돌아갔지만, 한 번 더 gotoPrevChannel() 메서드를 실행하니 이전 채널로 돌아가지 않고 현재 채널이 그대로 출력되었다.

로직이 어디서 잘못됐는지 고민해보고 해결한 후 본 게시물 하단에 추가로 업로드하겠다.

<추가> 해결 완료. 25-04-15 16:20

- 기존 gotoPrevChannel() 메서드 (오류)

- 수정 후 gotoPrevChannel() 메서드

기존의 원하는 값이 출력되지 않았을 때의 gotoPrevChannel() 메서드를 보면, 메서드를 호출하는 순간 채널 값이 prevChannel에 저장되어 있던 이전 채널값으로 업데이트는 되지만, 다음에 또 이 메서드를 실행했을 때 돌아갈 채널값을 저장하는 로직이 빠져있었다. 따라서 임시로 저장할 변수 temp를 정의하여 현재 채널과 이 메서드를 실행한 후의 채널을 모두 저장할 수 있도록 코드를 수정하였다.

특정 메서드를 한 번만 실행했을 때의 상황만 생각하면 안 된다. 연속으로 실행하거나 다른 메서드들과 이어서 사용하는 경우 등 가능한 모든 케이스를 고려해서 메서드를 작성하자!

2025-04-14 Java 문제 풀이

호기심 많은 솔이 — Mon, 14 Apr 2025 15:29:07 +0900

*코드 개선을 위한 훈수 언제나 환영입니다.

우선 문제를 읽고 CARD_NUM만큼 for문을 돌면서 cards배열에 차례대로 카드 번호와 광 여부를 넣어야겠다. 1~10이 두 번 반복되는데 그중 한 번만 num이 1, 3, 8일 때 광이여야 한다고 생각했습니다.

따라서 i < 10인 동안 num이 1, 3, 8이면 isKwang = true가 되도록 while문을 작성했고, 그 이후에는 i가 10~19일 때, num이 1~10이 돼야 하고 isKwang은 false가 되도록 코드를 작성하였습니다.

위의 내용을 바탕으로 작성한 코드는 아래와 같습니다.

SutdaDeck 클래스

SutdaCard 클래스

SutdaMain 클래스

출력창

**실행 순서 : SutdaDeck deck = new SutdaDeck();으로 객체를 생성하려고 할 때, 생성자 SutdaDeck()이 호출되고, 메서드를 사용하려고 하면 이때 생성된 객체 deck을 바탕으로 메서드가 호출된다.

ex) deck.shuffle();

이렇게 작성했더니 출력창에 아무것도 출력되지 않았습니다.

코드에 뭔가 오류가 있는 것 같은데 고민해 보고 해결해서 해당 게시물에 추가로 업로드하겠습니다.

<추가> 해결 완료 25-04-14 16:45

잘못 생각했었던 부분 : SutdaDeck클래스의 SutdaDeck() 생성자 부분에서 for문을 반복해서 돌면서 i값이 하나씩 증가한다고 생각하고 while문을 작성했는데, while문 안에 i++가 없어서 i가 0에서 증가할 수 없고, 따라서 while문을 빠져나올 수 없는 상황이 발생했었습니다.

<수정한 SutdaDeck 클래스>

생성자 SutdaDeck() 수정 완료

for문이 있다고 해서 무작정 한 바퀴 돌고 i값이 증가하겠지라고 생각하면 안된다. for문 내부에서 한 바퀴를 돌 수 있는지, 즉, for문의 종료시점까지 도달할 수 있는지를 따져보고 판단하자!

부트캠프 3주차 회고 - 무심(無心)하듯 성의(誠意)있게

호기심 많은 솔이 — Sun, 13 Apr 2025 22:13:05 +0900

다낭 바나힐 프랑스 마을

지난 주말부터 이번주 화요일까지 여행을 다녀왔다. 일상으로 돌아와서는 나름 열심히 했기도 하고, 처음으로 야간에 남아서 공부도 해봤다. 이번 주부터는 그룹 스터디를 시작해서 발표 주제를 정해서 발표도 했다.

그룹 스터디 발표

학원에 있는 시간에는 나름 열심히 했는데도 공부 시간이 아직은 조금 부족하다는 게 느껴졌고, 이번 주에 내가 뭘 했는지 돌아보니, 한 게 별로 없는 것 같다는 느낌이 들었다. 왜 그런지 생각해보니, 목표가 너무 막연해서 동기부여가 덜 됐었고 내가 뭘 하고 있는지도 모른 채 무작정 공부만 하고 있었던 것 같다. 그래서 구체적인 목표를 설정해야겠다고 생각했다. 우선, 장기 목표를 세우고 이를 중기(월간), 단기(주간) 목표로 나눠서 매 주 달성해나가려 한다.

- 최종 목표 : 매 순간을 즐기며 재미있게, 행복하게 살기

- 장기 목표 : 내년 상반기 안에 취업하기

- 중기 목표 : 가고 싶은 기업 구체적으로 정하고 미리 준비 하기

- 단기 목표(이번 주) : 자바의 정석 배운 데까지 1회독 하기, 3일 이상 남아서 공부하기, 주말 중 하루 이상 나와서 공부하기, 블로그 꾸준히 작성하기, 여기 쓴 목표들 더 구체화 시키기

내일 학원에 가서 이번 주 자바의 정석 1회독을 위해 매일 얼마나 해야하는지 구체적으로 나누고 매일 꼭 지킬 수 있도록 하자.

이번 주에는 동기부여가 되도록 목표를 좀 더 구체적으로 생각해보자.

회고를 작성하면서 지금 내 상황을 생각하다보니 영화 <승부>의 마지막 장면이 떠올랐다. 그 장면에 나오는 무심(無心)과 성의(誠意)가 지금 취준생인 내가 가져야할 자세를 말해주는 것 같다. 너무 집착하지 말되, 진심을 다해 준비하자.

부트캠프 2주차 회고

호기심 많은 솔이 — Fri, 4 Apr 2025 16:32:57 +0900

오늘 남궁성 강사님과 과제 피드백을 진행했다. 강사님께서는 내가 제출했던 과제 프린트를 바탕으로 피드백을 해주셨고, 쓴소리도 많이 들었다. 정신이 번쩍 들었다. 아직 기초 개념 암기가 부족하고, 공부 시간 자체도 충분하지 않았던 것 같다.

피어 세션에서도 많은 걸 느꼈다. 이미 실력이 뛰어난 학우들도 있었고, 정규 시간 이후에도 늦게까지 남아서 공부하는 분들이 생각보다 많았다. 나는 그동안 수업이 끝나면 항상 운동을 하러 가느라 남아서 공부한 적이 한 번도 없었다. 지금 생각해 보면 조금 안일했던 것 같다. 다음 주부터는 아침 시간에 운동을 하고, 야간에는 남아서 공부 시간을 더 확보할 수 있도록 노력해 봐야겠다.

살면서 '그 시기에만 할 수 있는 것'들이 있었고, 그걸 하지 못 해서 후회했던 적이 많았는데 지금이 딱 그 시기인 것 같다.

이번에는 후회 없이 해보자.

다음 주 목표 : 이틀 이상 아침에 운동하고, 야간에 남아서 공부하기

[Java] 멤버 변수(클래스 변수, 인스턴스 변수)와 지역 변수

호기심 많은 솔이 — Thu, 3 Apr 2025 15:37:17 +0900

*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

변수(Variable)의 분류

변수는 선언하는 위치에 따라 멤버 변수와 지역 변수로 나뉜다. 멤버 변수는 선언 위치가 클래스 영역이고, 지역 변수는 선언 위치가 메서드나 생성자 내부이다. 멤버 변수는 다시 클래스 변수와 인스턴스 변수로 나눌 수 있는데, 클래스 변수는 모든 객체가 공통적으로 같은 속성을 가질 때 사용한다. 또한, 클래스 변수는 static 키워드를 사용하고, 객체를 생성하지 않아도 사용할 수 있다. 인스턴스 변수는 각각의 객체마다 개별적인 속성을 가질 때 사용하고, 클래스 변수와 달리 객체를 생성해야 사용할 수 있다. 지역 변수는 메서드 내에 선언되어 메서드 내에서만 사용할 수 있는 변수이며, 메서드가 종료될 때 자동으로 소멸된다.

위 내용을 표로 정리하면 다음과 같다.

인스턴스 변수 (Instance Variable) 코드 예제

위 코드에 나오는 것처럼 인스턴스 변수 각 객체(인스턴스)마다 각각의 값을 가지는 변수이고, 인스턴스마다 따로 저장되므로, 하나의 객체에서 값을 바꿔도 다른 객체에는 영향을 주지 않는다.

클래스 변수 (Class Variable) 코드 예제

위 코드와 출력값을 보면 알 수 있듯이, 클래스 변수인 count 앞에는 static 키워드가 붙어있고, 이 변수는 모든 인스턴스가 공유한다. 위 코드에서는 생성자가 실행될 때마다 count 값이 1씩 증가하므로 출력값은 2가 나온다.

※이 코드를 보다가 갑자기 궁금한 점이 생겼다.

Q) count++ 같은 실행문은 main 메서드 안에 써야하는거 아닌가? 메인 메서드 밖에서는 선언만 가능한 거 아닌가? 왜 main문 밖에 써도 오류 없이 실행이 되는 거지?

-> 실행문 count++는 현재 생성자 안에 쓰여있다. 생성자도 메서드의 한 종류이므로, 그 안에서는 실행문을 자유롭게 쓸 수 있다.

지역 변수 (Local Variable) 코드 예제

위 코드와 출력값을 보면 add라는 메서드 내에서 사용되는 result라는 지역 변수가 있다. 이 메서드를 main문 내에서 실행시키면 add 메서드 내에서 계산된 결과인 8이 출력된다는 것을 알 수 있다. 이 지역 변수는 메서드나 블록 내부에서 선언되는 변수이므로 해당 블록을 벗어나면 소멸된다. 위 코드를 보면 add 메서드를 호출한 이후의 result값은 add 메서드의 result와 별개라는 것을 알 수 있다. 이러한 특징들 때문에 지역 변수는 보통 일시적인 계산, 임시 저장, 반복 변수 등에 사용된다.

[Java] 자바 메서드 선언 (접근자, static, 반환 타입)

호기심 많은 솔이 — Wed, 2 Apr 2025 17:10:02 +0900

*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

메서드 (Method)

메서드는 객체의 기능을 구현하기 위해 클래스 내부에 작성하는 함수이다. 즉, 특정한 기능을 수행하는 코드들을 하나로 묶은 것이라고 할 수 있다. 메서드는 크게 선언부(Head)와 구현부(Body)로 나뉘고, 호출하여 사용한다. 메서드는 입력값, 출력값이 있을 수도 있고 없을 수도 있다.

자바에서는 메서드를 선언할 때, public static void 메서드 명 { 메서드 내용 }, void 메서드 명 { 메서드 내용 }과 같이 선언한다. 여기서 선언부의 메서드 명 앞에 붙어 있는 public, static, void와 같은 것들이 무엇인지 대충은 알고 있었지만, 이 개념에 대해 누가 물어봤을 때 설명할 수 있을 정도로 정확히 아는 정도는 아니었기에, 지금부터라 정확히 알고 써야겠다는 생각으로 메서드에 대해 학습한 후 정리하였다.

메서드 형식

(접근자) + (static 여부) + 반환 타입 + 메서드 명(매개 변수) { 메서드 내용 }

예를 들어, protected static void volumeUp() { ~ } 과 같은 메서드가 있다면 접근자는 protected, static여부 (O), 아무것도 반환하지 않음, 메서드 명 : volumeUp, 매개 변수 없음.으로 이해할 수 있다. 이어지는 내용에서는 접근자, static, 반환 타입에 대해 자세히 정리해 보겠다.

접근자

접근자에는 접근 가능 범위가 넓은 순으로 public, protected, (default), private이 있고, 접근자 생략하면 default에 해당한다.

각 접근자의 접근 가능 범위를 표로 정리하면

위와 같이 나타낼 수 있다. 예를 들어, 접근자를 쓰지 않은 경우, 다른 패키지에 있는 클래스에서는 메서드가 정의된 클래스를 상속받았더라도 해당 메서드에 접근할 수 없다는 의미이다.

static 여부

먼저, static이 있는 경우에는 해당 메서드를 호출할 때, 객체 생성 없이 호출이 가능하다.

<예시 코드>

public class Utils {
    public static void printHello() {
        System.out.println("Hello!");
    }
}

// 호출
Utils.printHello(); // O (객체 생성 없이 호출 가능)

반면, static이 없는 경우에는 해당 메서드를 호출할 때, 객체를 생성해야만 호출이 가능하다.

<예시 코드>

public class Person {
    public void sayName() {
        System.out.println("My name is Jung.");
    }
}

// 호출
Person p = new Person();
p.sayName(); // O (객체 생성 필요)

**참고) main 메서드는 객체가 생성되기도 전에 먼저 실행돼야하므로 main 메서드 내에서는 static 메서드만 호출 가능하다!

반환 타입

반환 타입으로는 아무것도 반환하지 않는 void, int, String, boolean와 같은 기본형도 있고, 배열이나 객체도 반환이 가능하다.

<예시 코드>

1. void

public void printHello() {
    System.out.println("Hello");
}

2. int

public int add(int a, int b) {
    return a + b;
}

이 경우처럼 반환값이 있는 경우에는 그 반환값을 담을 변수를 선언하여 변수 안에 반환값을 담거나 바로 써도 된다.

- 반환값을 담을 변수를 선언한 경우

// add 메서드가 static이 아닌 경우 (인스턴스 생성 후 호출)
Calculator calculator = new Calculator();
int result = calculator.add(3, 5);
System.out.println("결과: " + result);

- 바로 쓴 경우

System.out.println(calculator.add(3, 5));

2025-04-01 Java 문제 풀이

호기심 많은 솔이 — Tue, 1 Apr 2025 17:02:11 +0900

*코드 개선을 위한 훈수 언제나 환영 입니다.

배열이 주어진 상황에서 배열 내의 값들을 정렬하고, 중복까지 제거해 보는 문제를 풀어보았습니다.

2025-04-01 Java 문제 풀이

호기심 많은 솔이 — Tue, 1 Apr 2025 16:51:23 +0900

*코드 개선을 위한 훈수 언제나 환영입니다!

저는 우선 이렇게 코드를 짰는데 이 코드는 랜덤으로 수를 뽑을 때, 두 번 이상 같은 수가 나오는 경우를 처리하지 못하고 있습니다.

예를 들어, 첫 번째로 2를 뽑고 두 번째로 2를 뽑았다면 if문에 걸려서 랜덤한 수를 다시 뽑게 되지만, 여기서 한 번 더 2를 뽑았다면 어쩔 수 없이 중복이 생기게 됩니다.

이 오류는 고민해보고 늦어도 내일까지는 해결해서 아래에 추가하도록 하겠습니다.

<추가>

이렇게 코드를 수정했는데 아까 발생한 바로 이전 요소와 중복되는 문제는 해결됐지만, 여러 번 돌려보니 모든 요소에서의 중복은 해결되지 않았다. -> 바로 이전 요소와의 비교만 할 게 아니라 모든 요소와 비교해서 중복 체크를 해야함.

<추가> (해결 완료) 25-04-01 18:47

for문을 이용하여 랜덤으로 뽑은 수가 배열 내의 모든 수와 같은지를 비교하는 로직을 추가하여 이전에 발생한 중복 문제를 해결하였습니다.

부트캠프 1주차 회고

호기심 많은 솔이 — Sun, 30 Mar 2025 23:58:16 +0900

수능을 준비 할 때는 매일 플래너를 작성하고 하루하루를 돌아보며 공부했던 적이 있지만, 개발 관련해서는 회고를 처음 작성해 보는 거라 어떤 내용을 어떤 식으로 작성하는 것이 좋을지 아직은 잘 모르겠다. 하지만 회고의 목적이 '나의 발전'이라는 것은 분명 알고 있다. 수능 공부를 했을 때도 무작정 공부만 했을 때보다 나의 부족한 점을 파악하고, 어떻게 해야 그 부분을 보완할 수 있을까에 대해 고민하는 시간을 가졌을 때가 성적이 훨씬 많이 올랐었고 이때 회고의 중요성을 깨달았었다.

이전에 과외를 하면서도 학생들에게 무작정 문제를 많이 풀기만 한다고 되는 것이 아니다. 문제를 풀었으면 반드시 피드백을 해야한다고 지도를 했었는데 이제는 내가 학생의 입장이 되어 배우고 익히고 돌아봐야 하는 상황이 되었다.

회고를 어떤 식으로 작성할지는 아직 고민중이지만 학생들에게 효율적이라 생각해서 시켰던 방식을 사용해 보면 어떨까 하는 생각이 든다. 적을 알고 나를 알면 백 번 싸워도 위태롭지 않다는 말이 있듯이, 내가 그 주에 해결하지 못 한 문제나 이해하지 못 한 개념이 생길 때마다 회고에 써놓고, 그 문제나 개념을 이해하기 위해 앞으로 내가 어떤 부분을 보충해야 하는지, 해결했다면 어떻게 했고 그 문제나 개념이 왜 어려웠는지에 대해 한 주를 마무리하며 쓰는 방식이다. 정리하자면, 각 주마다 공부를 하면서 겪은 어려움과 내가 부족했던 점에 대해 분석하고, 어떻게 하면 내가 발전할 수 있을까에 대해 고민해서 글로 써본다 정도로 생각하면 될 것 같다.

교육 첫 주라 매일 일찍 일어나고 일찍 자는 게 조금 힘들긴 했지만 나름 재미도 있고 보람찬 한 주 였다. 다음 주에는 공부도 운동도 이번 주보다 더 발전할 수 있도록 더 열심히 해야겠다.

+ 다음 주에는 더 정량적이고 구체적인 목표를 써보면 좋을 것 같다.

Git 헷갈리는 명령어 (reset, revert, rebase)

호기심 많은 솔이 — Sat, 29 Mar 2025 14:47:18 +0900

*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

git reset

- git reset은 변경 사항을 취소하는 데 사용한다. 즉, 이전 커밋으로 되돌릴 수 있다.

- 사용 형식 : git reset --(모드) (돌아갈 커밋)

- 모드 인자로는 soft, mixed, hard를 사용한다. (디폴트로 mixed를 사용)

- 차이 :

--soft : 커밋은 취소되지만, 스테이징 상태는 유지한다.

--mixed : 커밋과 스테이징이 모두 취소되지만, 로컬 변경 상태는 유지한다.

--hard : 커밋, 스테이징, 로컬 변경 상태를 모두 취소한다.

- 사용 예시 :

git reset --hard HEAD~1 (최근 커밋 하나를 삭제하고 변경 내용도 함께 제거)

git reset --hard HEAD~2 (최근 커밋 2개를 삭제하고 변경 내용도 함께 제거)

git revert

- git revert도 변경을 되돌릴 때 사용한다. reset 명령어와의 차이점은 revert 명령어는 특정 커밋으로 돌아가는 역할을 수행한다는 것이다.

- 사용 형식 : git revert (돌아갈 커밋)

- 사용 예시 :

git revert HEAD (가장 최근 커밋을 무효화하는 새 커밋을 만든다. 원본 커밋은 그대로 남고, 변경사항만 되돌려진다.)

git revert a1b2c3d (a1b2c3d는 되돌리고 싶은 커밋의 해시값. 해당 커밋 내용만 취소하는 새 커밋이 만들어진다.)

git revert HEAD~3..HEAD (최근 3개의 커밋 HEAD~3부터 HEAD까지)을 한 번에 revert 하고 커밋마다 되돌리는 커밋이 따로 만들어진다. (reset 명령어와 달리 HEAD~2..HEAD처럼 범위 지정을 지원한다.)

git rebase

- 이 명령어는 단어 뜻 그대로 base를 재설정하는 명령어이다. 이 명령어는 이해하기 조금 어려웠기에 예시를 들어 충돌이 일어나는 경우까지 설명해보겠다.

예를 들어, sports라는 브랜치에서 s1, s2, s3이라는 커밋을 한 후, 이 s3 커밋을 base로 하여 football이라는 브랜치로 작업을 진행한다고 할 때, football 브랜치에서 f1, f2, f3 커밋을 하였고, sports 브랜치에서는 s3에 이어서 s4, s5, s6 커밋을 한 상황을 생각해 보자.

커밋 f1~f3은 커밋 s3을 base로 하여 자신의 브랜치에서만 작업을 한 것이므로 충돌이 일어나지 않지만, 만약 football 브랜치에서 rebase를 사용하여 커밋 s6을 base로 재설정하는 경우, 커밋 f1~f3과 s4~s6에서 같은 줄을 수정하면 충돌이 일어날 수 있다. 이 경우에는 우선 충돌 파일을 열고 원하는 코드로 수정하여 충돌을 해결한 후,

-> git add <해결한 파일>

-> git rebase --continue

이 두 명령어를 실행하면 football 브랜치의 커밋들이 s6 위에 재배치된다.

이해하기 쉽도록 모식도를 그려보면 다음과 같다.

<rebase 전>

<rebase 후>

rebase 실행 순서 및 명령어

-> git checkout sports (sports 브랜치로 이동)

-> git pull origin sports (최신 sports 받기)

-> git checkout football (football 브랜치로 이동)

-> git rebase sports (sports를 base로 rebase 명령어 실행)

자주 쓰는 GitHub 명령어 및 리눅스 명령어

호기심 많은 솔이 — Fri, 28 Mar 2025 15:20:51 +0900

*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

GitHub 명령어

git status : 현재 브랜치의 변경사항 확인.

git log : 현재 브랜치의 버전 내역을 확인.

git clone [URL] : 원격 저장소 복제.

git diff : 아직 스테이징 되지 않은 변경 내용을 비교해서 보여줌. 어떤 라인을 바꿨는지 확인할 수 있음.

git add . : 모든 파일 추적 및 스테이징.

git commit -m "메시지 내용" : 커밋 및 커밋 메시지 생성.

git push origin [브랜치명] : 로컬 저장소의 '브랜치명'에 해당하는 브랜치의 커밋 내용을 원격 저장소(origin)로 푸시.

git pull : 원격 저장소에서 브랜치 가져오기.

git init : 새로운 Git 저장소를 초기화하는 명령어 → 현재 디렉터리에 .git/ 폴더가 생기고, 이 폴더 안에 Git이 관리할 모든 정보가 담김. 이제부터 이 폴더는 Git으로 버전 관리가 가능해짐.

git remote add origin [URL] : 원격 저장소의 위치를 내 로컬 저장소에 연결해 주는 명령어 → origin은 원격 저장소의 별명. 이후에 git push origin main 같은 식으로 이 별명을 사용해 푸시할 수 있음.

git fetch : 원격 저장소(origin)에서 최신 브랜치와 커밋 기록을 가져오는 것(코드를 바로 병합하거나 변경하지는 않음). fetch는 가져오기만 하고 내 현재 작업 디렉터리는 그대로 유지됨. 원격 저장소에 어떤 브랜치가 있는지, 최신 상태는 어떤지 확인할 때 유용함.

git branch : 현재 로컬 브랜치 목록을 보여줌.

git branch [브랜치명] : 새로운 로컬 브랜치 생성.

git checkout -b [브랜치명] : 새 브랜치를 만들고 동시에 그 브랜치로 이동.

git checkout [브랜치명] : 기존에 있던 브랜치로 이동.

git branch -d [브랜치명] : 로컬 브랜치 삭제.

리눅스 명령어

mkdir 폴더명 : 새 폴더 만들기

cd 경로 : 폴더 이동

cd .. : 상위 폴더로 이동. 현재 위치에서 한 단계 위로 감

cd ~ : 홈 디렉터리로 이동. 내 계정의 기본 위치.

ls : 현재 폴더 안에 뭐가 있는지 보여줌

ls -l : 파일/폴더 리스트를 자세히 보여줌 (권한, 날짜, 용량 등)

ls -a : 숨겨진 파일도 포함해서 보여줌

pwd : 현재 내가 있는 경로를 보여줌

touch 파일명 : 새 빈 파일 만들기 ex) touch aaa.txt

rm 파일명 : 파일 삭제

rm -r 폴더명 : 폴더와 그 안의 내용까지 삭

[Java] 추상 클래스와 인터페이스

호기심 많은 솔이 — Thu, 27 Mar 2025 12:28:53 +0900

*본 게시물은 마이자몽님의 블로그를 참고하여 작성하였으며, 글 하단에 출처를 기록해 두었음을 밝힙니다.
*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

본인은 지금까지 추상 클래스와 인터페이스에 대해 대충은 알고있었지만 정확히 언제, 왜 사용하는지를 알지 못했었다. 오늘 공부를 하다가 관련 내용이 나왔는데, 이제라도 정확히 공부해 두자라는 생각으로 GPT와 구글 검색을 통해 공부를 한 후 이 글을 작성하였다.

추상 클래스란?

추상 클래스는 클래스 선언 시 앞에 예약어 'abstract'를 붙여 선언한다. 또한, 클래스 내에 추상 메서드를 선언하여 상속을 통해 자손 클래스에서 완성하도록 유도하는 클래스이다. 추상 클래스 내의 일반 메서드는 그대로 상속받아서 사용해도 되지만, 내용이 없는 추상 메서드는 자식 클래스에서 반드시 구현을 직접 해줘야 한다. 클래스 내에 추상 메서드가 하나라도 있으면 추상 클래스이다.

인터페이스란?

인터페이스도 추상 클래스와 유사하게 일반 클래스를 작성하는데 도움을 주는 목적으로 작성한다. 다만, 추상 클래스와 달리 다중상속이 가능하다.

추상 클래스와 인터페이스의 차이

1. 추상 클래스는 단일 상속만 가능하지만, 인터페이스는 다중 구현이 가능하다.

2. 추상 클래스는 생성자가 있지만 인터페이스는 생성자가 없다. (객체는 추상 클래스와 인터페이스 모두 생성할 수 없다.)

3. 추상 클래스에서는 private, protected 등의 접근 제어자를 자유롭게 사용 가능하지만 인터페이스에서는 모든 메서드는 기본적으로 public을 사용한다.

추상 클래스를 사용하는 이유

추상 클래스는 공통 기능을 구현해놓고 하위 클래스에서 재사용하고 싶을 때 사용하여 중복 코드를 줄일 수 있다. 예를 들어 Vehicle이라는 추상 클래스에서 가속 기능과 감속 기능을 구현해 놓고 하위 클래스인 Car 클래스, Ship 클래스에서 Vehicle 클래스를 상속받아 재사용하면 Car 클래스, Ship 클래스 각각에서 가속 기능, 감속 기능을 구현하지 않아도 되므로 중복 코드를 줄일 수 있다. 또한, 상위 클래스에서는 어떻게 동작할지 알 수 없는 부분을 추상 메서드로 남겨두고, 자식 클래스가 구체적으로 구현하게 할 때 사용한다. 즉, 상위 클래스는 공통된 전체 로직의 틀만 제공하고 구체적인 동작은 하위 클래스에게 맡기는 것이다.

인터페이스를 사용하는 이유

인터페이스는 추상 클래스와 달리 다중상속이 가능하다. 따라서 다중 기능을 조합하고 싶을 때는 추상 클래스가 아니라 인터페이스를 사용한다. 예를 들어 Bmw라는 클래스는 SportMode라는 기능과 Movable이라는 기능을 모두 필요하므로 public class Bmw extends Car implements SportMode, Movable { ... }에서 처럼 Car라는 추상 클래스를 상속받고, SportMode, Movable라는 2개의 인터페이스를 콤마(,)로 연결하여 다중 상속한 것을 볼 수 있다.

또한, 서로 다른 클래스에 공통 기능을 강제하고 싶을 때에도 인터페이스를 사용한다.

**참고한 블로그**
마이자몽, 2020년 2월 8일, https://myjamong.tistory.com/150

[Java] 절차지향과 객체지향의 비교

호기심 많은 솔이 — Thu, 6 Mar 2025 18:43:17 +0900

*본 게시물은 인프런 김영한 강사님의 자바 강의를 참고하여 작성하였습니다.
*본 게시물은 불곰님의 블로그를 참고하여 작성하였으며, 글 하단에 출처를 기록해두었음을 밝힙니다.
*본 게시물은 개인 공부를 기록하기 위해 작성하였으며, 내용에 오류가 있을 수 있음을 밝힙니다.

절차지향 프로그래밍(Procedural Programming)이란?

절차지향 프로그래밍이란 프로그램이 위에서부터 아래로 순차적으로 실행되도록 하는 프로그래밍 기법이다. 절차 지향 프로그래밍에서는 데이터와 기능(함수)이 따로 존재하고, 함수가 데이터를 처리하는 방식이다. 절차지향 프로그래밍은 코드가 직관적이므로 초보자가 이해하기 쉽고, 일반적으로 실행 속도가 빠른 편이다. 하지만 코드가 커지면 유지보수가 어려워질 수 있다. 정리하자면, 절차지향 프로그래밍은 "어떻게"를 중심으로 프로그래밍을 했다고 볼 수 있다. 대표적인 절차지향 언어로는 C언어가 있다.

객체지향이 왜 유지보수 하기에 유리한지를 보여주기 위해, 속성과 데이터가 각각의 클래스로 존재하는 경우를 보여주자면

음악 플레이어의 데이터는 첫 번째 사진의 MusicPlayerData에 있는데, 그 데이터를 사용하는 기능은 MusicPlayerMain3 클래스에 있는 각각의 메서드에 분리되어 있다. 따라서 음악 플레이어와 관련된 데이터는 MusicPlayerData를 사용해야 하고, 음악 플레이어와 관련된 기능은 MusicPlayerMain3의 각 메서드를 사용해야 한다. 데이터와 그 데이터를 사용하는 기능은 매우 밀접하게 연관되어 있다. 이후에 MusicPlayerData에서 관련 데이터가 변경되면 MusicPlayerMain3 부분의 메서드들도 함께 변경해야 한다. 즉, 이렇게 데이터와 기능이 분리되어 있으면 유지보수 시에 관리 포인트가 2곳으로 늘어나게 되므로 유지보수가 어려워진다.

객체지향 프로그래밍(Object Oriented Programming)이란?

객체지향 프로그래밍이란 데이터와 기능을 하나로 묶어서 하나의 객체에 대한 개념을 온전히 하나의 클래스에 담아, 객체 단위로 프로그래밍하는 기법이다. 객체지향 프로그래밍에서는 프로그램의 실행 순서보다는 객체 클래스를 만드는 것 자체에 집중해야 한다. 객체가 어떤 속성(데이터)을 가지고 어떤 기능(메서드)을 제공하는지에 초점을 맞추어야 한다는 것이다. 객체지향 프로그래밍은 절차지향 프로그래밍에 비해 유지보수가 쉽고 코드의 재활용성이 높지만, 처리 속도가 느리고 설계에 많은 시간이 들어간다. 절차지향 프로그래밍이 "어떻게"를 중심으로 프로그래밍을 한 것이라면, 객체지향 프로그래밍은 "무엇을"을 중심으로 프로그래밍을 했다고 볼 수 있다. 대표적인 객체지향 언어로는 Java가 있다.

절차지향 프로그래밍은 데이터와 기능이 따로 존재한다는 것을 위에서 보여주었는데, 객체지향 프로그래밍은 데이터와 기능이 하나의 객체 안에 함께 존재한다는 것을 예시 코드로 보여주자면

이 MusicPlayer라는 하나의 클래스 안에 음악 플레이어에 필요한 속성과 기능을 모두 정의하였다. 속성은 이 MusicPlayer클래스의 멤버 변수인 volume, isOn으로 정의하였고, 기능은 MusicPlayer를 사용하기 위한 기능을 구현한 메서드 on, off, volumeUp, volumeDown, showStatus로 정의하였다. 이제 음악 플레이어가 필요한 곳에서 이 클래스만 있으면 온전한 음악 플레이어를 생성하여 사용할 수 있다.

이제 MusicPlayer라는 하나의 객체 내에 구현된 기능들을 직접 사용한 코드를 보여주자면

이 코드를 보면 실세계와 유사하게 이미 만들어져있는 음악 플레이어를 사용자가 기능만 호출해서 사용하고 있다는 것을 알 수 있다. 즉, 뮤직 플레이어를 사용하는 입장에서는 뮤직 플레이어 안의 내용이 어떤지는 알 필요가 없고 단순히 기능을 호출하여 사용하면 된다는 것이다.

이해를 돕기 위해 비유를 통해 몇 가지 예시를 더 들어보겠다.

비유 : 세상의 모든 사물을 단순하게 추상화해보면 속성(데이터)과 기능(메서드)으로 설명할 수 있다.

1. 자동차

- 속성 : 색상, 현재 속도

- 기능 : 액셀, 브레이크, 문 열기, 문 닫기

2. 동물

- 속성 : 색상, 키, 온도

- 기능 : 먹는다, 걷는다

3. 게임 캐릭터

- 속성 : 레벨, 경험치, 소유한 아이템

- 기능 : 이동, 공격, 아이템 획득

-> 여기서 속성은 멤버 변수, 기능은 메서드로 각각의 '객체' 내에 포함되어 있는 것이다.

위의 내용들을 통해 절차지향과 객체지향의 개념에 대해 이해했다면, 이제 마지막으로 객체지향 프로그래밍의 주요 특징에 대해서 알아보자.

1. 캡슐화

캡슐화(Encapsulation)는 데이터와 이를 처리하는 기능을 하나의 객체로 묶고, 외부에서 직접 접근하지 못하도록 제한하는 객체지향 프로래밍(OOP)의 핵심 개념이다. 즉, 데이터를 감추고 외부 세계와의 상호작용은 메서드를 통해 하는 방법이다. 위의 MusicPlayer를 보면 음악 플레이어를 구성하기 위한 속성과 기능이 마치 하나의 캡슐에 쌓여있는 것 같다. 이렇게 속성과 기능을 하나로 묶어서 필요한 기능을 메서드를 통해 외부에 제공하는 것을 캡슐화라 한다. 캡슐화의 장점으로는 데이터 보호, 코드의 유지보수성 향상, 객체 간 결합도 감소, 보안 강화 등이 있다.

2.상속

상속(Inheritance)은 기존 클래스(부모 클래스)의 속성(필드)과 기능(메서드)을 새로운 클래스(자식 클래스)가 물려받아 확장하는 객체지향 프로그래밍(OOP) 개념이다. 상속을 통해 중복 코드를 제거하여 코드의 재사용성을 증가시킬 수 있고, 기존 기능을 쉽게 추가 및 수정할 수 있도록 한다.

3.다형성
다형성(Polymorphism)은 같은 메서드나 객체가 다른 형태로 동작할 수 있도록 하는 객체지향 프로그래밍(OOP)의 개념이다. 즉, 하나의 인터페이스로 여러 개의 구현을 가질 수 있는 것을 의미한다. 이를 통해 코드를 유연하게 작성하고, 유지보수를 쉽게 할 수 있도록 한다.

4.추상화

추상화(Abstraction)는 클래스들 사이에서 공통된 속성과 기능을 도출해내는 것을 말한다. 공통된 부분을 포함하는 클래스라고 해서 꼭 상위 클래스로 만들어야 하는 것은 아니고, 상황에 따라 공통 요소를 가진 하위 클래스를 정의할 수도 있다. 추상화를 활용하면 코드 중복을 줄이고, 클래스 간의 관계를 명확하게 만들며, 유지보수도 수월해진다. 자바에서는 추상 클래스나 인터페이스를 통해 추상화를 구현할 수 있다.

**참고한 블로그**
불곰, 2018년 12월 22일, https://brownbears.tistory.com/407