Happy Collin

Builder 와 Record 비교

Collin — Sun, 29 Mar 2026 08:00:19 +0900

자바에서 객체를 생성하고 데이터를 다루는 방식은 크게 Builder 패턴과 **Record(레코드)**로 나뉩니다. 두 기능은 목적과 사용 사례가 다르기 때문에 상황에 맞춰 선택하는 것이 중요합니다.

1. Builder 패턴 (Lombok @Builder)

Builder 패턴은 복잡한 객체를 안전하고 편리하게 생성하기 위해 사용됩니다. 주로 계층이 있고 필드가 많은 클래스에 적합합니다.

특징

가독성: 필드가 많을 때 어떤 값이 어떤 필드에 들어가는지 명확히 알 수 있습니다.
선택적 매개변수: 모든 필드를 채울 필요 없이 필요한 값만 세팅할 수 있습니다.
불변성 유지: 객체 생성 후 값을 바꿀 수 없도록(Setter 없음) 설계하기 좋습니다.

코드 예시

Java

@Builder
@Getter
public class User {
private final String name;
private final int age;
private final String email;
}

// 사용 예시
User user = User.builder()
.name("홍길동")
.age(30)
// email은 생략 가능
.build();

2. Record (자바 14 이상)

Record는 **"순수하게 데이터 전달만을 위한 객체(DTO)"**를 위해 도입된 새로운 클래스 타입입니다.

특징

간결함: 클래스 선언 한 줄로 Constructor, Getter, equals, hashCode, toString이 자동 생성됩니다.
불변 객체: 모든 필드가 private final로 선언되며, 수정이 불가능합니다.
상속 불가: 다른 클래스를 상속받을 수 없습니다. (인터페이스 구현은 가능)

코드 예시

Java

public record UserRecord(String name, int age, String email) {}

// 사용 예시
UserRecord user = new UserRecord("이순신", 40, "lee@test.com");
System.out.println(user.name()); // get이 아닌 필드명으로 호출

3. Builder vs Record 핵심 비교

구분	Builder 패턴 (Lombok)	Record (Java Standard)
주요 목적	객체 생성의 편의성 및 가독성	데이터 전달용(DTO) 객체의 간결함
가변성	가변/불변 선택 가능	무조건 불변 (Immutable)
생성 방식	체이닝 방식 (.name().age())	생성자 방식 (new Record(...))
코드 양	@Builder 등 어노테이션 필요	키워드 하나로 모든 메서드 자동 생성
필드 개수	필드가 많을수록 유리함	필드가 많으면 생성자 파라미터가 길어짐

4. 언제 무엇을 써야 할까요?

Builder를 써야 할 때

생성자 파라미터가 5개 이상으로 많을 때
객체 생성 시 필수 값과 선택 값이 나뉘어 있을 때
이미 정의된 클래스(Entity 등)를 불변으로 만들고 싶을 때

Record를 써야 할 때

API 응답/요청을 위한 DTO를 만들 때
단순히 데이터를 담아서 전달하는 목적일 때
자바 표준 기능만 사용하여 코드를 간결하게 유지하고 싶을 때

꿀팁: Record와 Builder 함께 쓰기

최근에는 Record에 @Builder를 붙여서 사용하는 방식이 가장 인기가 많습니다. Record의 간결함과 Builder의 생성 편의성을 모두 챙길 수 있기 때문입니다.

Java

@Builder
public record UserDto(String name, int age, String email) {}

// 사용 시
UserDto dto = UserDto.builder().name("김철수").build();

Filter ,Interceptor , AOP

Collin — Sat, 28 Mar 2026 07:00:39 +0900

Spring Boot에서 클라이언트의 요청이 비즈니스 로직(Service)에 도달하기까지의 흐름은 계층별로 명확히 구분됩니다. 요청은 외곽(Servlet Container)에서 시작하여 중심(AOP)으로 들어가는 구조입니다.

1. 요청 처리 흐름 도식화

클라이언트의 요청이 들어오고 나가는 전체적인 흐름은 아래와 같습니다.

순서	구성 요소	소속 레이어	특징
1	Filter (필터)	Web Container	DispatcherServlet 도달 전/후 동작
2	Interceptor (인터셉터)	Spring Context	DispatcherServlet과 Controller 사이 동작
3	AOP (Aspect)	Spring Context	Proxy를 통해 비즈니스 로직 전/후 동작

2. 단계별 상세 비교 표

각 기술이 실행되는 시점과 주요 목적을 정리한 표입니다.

구분	Filter (필터)	Interceptor (인터셉터)	AOP (Aspect)
관리 주체	서블릿 컨테이너 (Tomcat 등)	스프링 컨테이너	스프링 컨테이너
실행 시점	HTTP 요청 최전방 / 최후방	컨트롤러 호출 전/후	메서드 호출 전/후 (주로 Service 레이어)
접근 정보	Request, Response (Low-level)	HttpServletRequest, Handler 등	메서드 파라미터, 반환값 등
주요 역할	인코딩, 보안(XSS), 로깅, 인증	로그인 체크, 권한 관리, 컨트롤러 공통 데이터	로깅, 트랜잭션(@Transactional), 성능 측정
예외 처리	서블릿 내에서 처리 불가	컨트롤러 예외 처리 가능	비즈니스 로직 예외 처리 최적화

3. 요약 및 흐름 이해

Filter: 스프링 프레임워크와는 무관한 웹 애플리케이션의 공통 기능입니다. 주로 전역적인 보안이나 데이터 압축을 처리합니다.
Interceptor: 스프링 내부로 들어온 후, 컨트롤러가 실행되기 전후에 처리됩니다. Spring MVC 구조에 특화되어 있으며, 로그인 여부 확인 등에 주로 쓰입니다.
AOP: 객체 지향 프로그래밍(OOP)을 보완하기 위해 만들어졌습니다. 주로 비즈니스 로직(Service) 단위에서 중복되는 코드(트랜잭션 관리 등)를 분리하는 데 최적화되어 있습니다.

산소미포함 씨근풀 냉각 정리

Collin — Fri, 20 Feb 2026 08:00:57 +0900

산소 미포함(Oxygen Not Included)에서 씨근풀 냉각 효율

산소 미포함에서 초중반 온도 관리는 생존에 직결되는 중요한 요소입니다.

그중 **씨근풀(Weezewort)**은 전력 없이 작동하는 식물형 냉각 장치로, 많은 플레이어들이 애용합니다.

그런데 왜 씨근풀은 수소 환경에서 가장 효율적일까요? 그 이유는 바로 **비열(Specific Heat Capacity)**에 있습니다.

씨근풀의 냉각 메커니즘

씨근풀은 아래 칸의 기체 1000g을 흡입한 뒤,
그 기체를 정확히 5℃ 낮춰서 위 칸으로 배출합니다.
따라서 어떤 기체를 흡입하느냐에 따라 **냉각되는 열량(Heat Deletion)**이 달라집니다.

️ 비열(Specific Heat Capacity)란?

비열은 물질 1kg의 온도를 1℃ 올리는 데 필요한 열량을 의미합니다.
공식:
[ Q = m \cdot c \cdot \Delta T ]
- (Q): 제거된 열량 (J)
- (m): 질량 (kg)
- (c): 비열 (J/(kg·K))
- (\Delta T): 온도 변화 (K 또는 ℃)

비열이 클수록 같은 온도 변화를 줄 때 더 많은 열을 제거할 수 있습니다.

기체별 비열과 씨근풀 냉각량 비교

기체 비열 (J/kg·K) 5℃ 냉각 시 제거 열량 (J) 특징

수소 (H₂)	≈ 2400	12,000	가장 효율적, 냉각실에 최적
산소 (O₂)	≈ 1000	5,000	기본 환경에서 무난
오염된 산소 (Polluted O₂)	≈ 1010	5,050	산소와 거의 동일
이산화탄소 (CO₂)	≈ 850	4,250	효율 낮음
염소 (Cl₂)	≈ 480	2,400	냉각 효율 거의 없음
증기 (Steam)	≈ 2000	10,000	효율 좋지만 관리 어려움

왜 수소가 최적일까?

씨근풀은 온도를 5℃ 낮추는 고정 효과를 가지므로,
비열이 큰 기체일수록 냉각되는 총 열량이 많아집니다.
수소는 비열이 가장 크기 때문에, 같은 씨근풀로도 2~5배 더 많은 열을 제거할 수 있습니다.

⚙️ 씨근풀 냉각 조건 & 활용 팁

밀폐된 방을 만들고 내부를 수소로 채운 뒤 씨근풀을 심기 → 최대 효율 달성
인광석(Phosphorite) 자동 공급 → 관리 부담 최소화
작물 보호: 끼니나무(Mealwood) 같은 작물의 생장 온도를 안정적으로 유지 가능
한계: 액체 냉각에는 비효율적 → 후반에는 액체조화기 + 증기터빈 같은 고급 장치로 대체

✅ 결론

씨근풀은 초중반 온도 관리에 매우 유용한 식물형 냉각 장치입니다.
특히 수소 환경에서 비열이 크기 때문에 같은 5℃ 냉각으로 더 많은 열을 제거할 수 있어 최적의 효율을 발휘합니다.

[JPA/Hibernate] IN 절 파라미터 패딩(Parameter Padding)

Collin — Fri, 6 Feb 2026 07:00:11 +0900

JPA를 사용하다 보면 로그에 실제 전달한 리스트는 152개인데, SQL 바인딩 시점에는 255개(혹은 256개)까지 늘어나 마지막 값이 반복해서 들어가는 현상을 볼 수 있습니다. 이는 `type.descriptor.sql.BasicBinder`가 수행하는 IN Clause Parameter Padding 때문입니다.

이 현상의 원인과 해결 방법을 정리합니다.

---

1. 왜 255개까지 늘어나는 걸까? (원인)

Hibernate는 성능 최적화를 위해 IN 절에 전달된 인자의 개수를 2의 거듭제곱(2, 4, 8, 16 ... 256) 단위로 맞추는 패딩 전략을 사용합니다.

* 이유: DB의 Execution Plan(실행 계획) 재사용성 때문입니다.
* 상세: 인자 개수가 152개일 때와 153개일 때 각각 다른 SQL로 인식되면 DB는 매번 새로운 실행 계획을 짜야 합니다. 패딩을 통해 둘 다 256개짜리 쿼리로 통일하면, DB는 이미 캐싱된 실행 계획을 재사용하여 CPU 소모를 줄일 수 있습니다.

---

2. 패딩을 방지하거나 조절하는 방법

상황에 따라 아래 세 가지 방법 중 하나를 선택할 수 있습니다.

# 방법 1: 패딩 기능 완전 비활성화

파라미터 개수가 늘어나는 것 자체가 싫고, 쿼리 종류가 많지 않아 실행 계획 재사용의 이점이 적다면 설정을 통해 끌 수 있습니다.

* application.yml 설정:

```yaml
spring:
  jpa:
    properties:
      hibernate.query.in_clause_parameter_padding: false

```

> 주의: 이 설정을 끄면 `IN (1, 2, 3)`과 `IN (1, 2, 3, 4)`가 서로 다른 쿼리로 취급되어 DB 부하가 소폭 증가할 수 있습니다.

# 방법 2: 배치 사이즈(Batch Size) 제한

특정 연관 관계 조회에서 발생하는 문제라면 `@BatchSize`를 사용하여 한 번에 넘길 파라미터의 최대치를 강제로 고정할 수 있습니다.

```java
@BatchSize(size = 100) // 152개라면 100개, 52개로 나누어 실행됨
@OneToMany(mappedBy = "parent")
private List<Child> children;

```

# 방법 3: 애플리케이션 레벨에서 리스트 분할 (Partitioning)

가장 확실하게 제어하는 방법은 대량의 리스트를 직접 일정한 크기로 나누어 쿼리를 여러 번 호출하는 것입니다.

```java
// Google Guava 라이브러리 활용 예시
List<List<Long>> partitionedIds = Lists.partition(originalIds, 100);

for (List<Long> batch : partitionedIds) {
    repository.findAllByIdIn(batch);
}

```

이 방식은 DB에 전달되는 파라미터 개수를 100개 이하로 엄격하게 관리할 수 있어 성능 예측이 쉬워집니다.

---

3. 요약 및 권장 사항

* 성능 중심: 패딩 기능을 켜두는 것이 좋습니다. (DB CPU 효율 증대)
* 로그 가독성 및 정밀 제어 중심: `in_clause_parameter_padding: false`로 설정하세요.
* 대량 데이터 처리: 설정과 무관하게 `Lists.partition` 등을 이용해 애플리케이션에서 100~500 단위로 끊어서 요청하는 것이 메모리와 성능 면에서 가장 안전합니다.
---

@Transactional의 동작

Collin — Sat, 13 Dec 2025 08:10:21 +0900

@Transactional(rollbackFor = Exception.class)

기본 동작

@Transactional은 기본적으로 RuntimeException과 Error가 발생하면 롤백합니다.
즉, 체크 예외(Exception의 하위 클래스지만 RuntimeException이 아닌 것들)는 기본적으로 롤백 대상이 아닙니다.

rollbackFor 옵션의 의미

rollbackFor = Exception.class라고 지정하면, 체크 예외까지 포함해서 모든 예외가 발생하면 롤백하도록 강제합니다.
기본값이 "모든 예외 롤백"이 아니라 "런타임 예외만 롤백"이기 때문에, 위처럼 명시적으로 지정하는 경우가 많습니다.

왜 이렇게 쓰는가?

비즈니스 로직에서 IOException, SQLException 같은 체크 예외가 발생했을 때도 트랜잭션을 롤백하고 싶을 수 있습니다.
기본 설정만 쓰면 이런 체크 예외는 롤백되지 않고 커밋될 수 있어, 데이터 정합성 문제가 생길 수 있습니다.
그래서 rollbackFor = Exception.class를 붙여 모든 예외 상황에서 안전하게 롤백되도록 하는 거죠.

✅ 정리하면:
rollbackFor가 기본 true가 아니라, 기본은 런타임 예외만 롤백입니다.
체크 예외까지 롤백하려고 rollbackFor = Exception.class를 명시하는 거예요.

대규모 트래픽을 효율적으로 처리하기 위해 어떤 접근과 기술을 사용할 수 있나요?

Collin — Wed, 10 Dec 2025 08:50:13 +0900

면접 질문

"Java 웹 애플리케이션에서 대규모 트래픽을 효율적으로 처리하기 위해 어떤 아키텍처적 접근과 기술을 사용할 수 있나요?"

모범 답변

스케일 아웃(Scale-out) 구조
- 단일 서버 성능 향상보다 로드 밸런싱을 통한 서버 확장 방식을 선호합니다.
- Nginx, HAProxy 같은 로드 밸런서를 활용해 트래픽을 분산합니다.
비동기 처리와 메시지 큐
- 대량 요청을 동기적으로 처리하면 병목이 발생합니다.
- Kafka, RabbitMQ 같은 메시지 큐를 사용해 비동기 이벤트 기반 아키텍처를 구축합니다.
캐싱 전략
- DB 부하를 줄이기 위해 Redis, Memcached 같은 인메모리 캐시를 적극 활용합니다.
- 정적 리소스는 CDN을 통해 제공하여 서버 부담을 줄입니다.
데이터베이스 최적화
- 읽기/쓰기 분리(Replication), 샤딩(Sharding)으로 확장성을 확보합니다.
- JPA/Hibernate 사용 시 N+1 문제를 피하기 위해 Fetch 전략을 신중히 선택합니다.
비즈니스 로직 분리 (마이크로서비스)
- 모놀리식 구조 대신 **마이크로서비스 아키텍처(MSA)**를 적용해 서비스별 독립적 확장성을 확보합니다.
- Spring Cloud, Kubernetes 같은 오케스트레이션 도구를 활용합니다.
모니터링과 자동화
- Prometheus, Grafana로 성능 모니터링을 하고, 장애 발생 시 빠르게 대응합니다.
- CI/CD 파이프라인을 통해 자동 배포 및 롤백을 지원합니다.

1. 스케일 아웃 (Scale-out) 구조

Q1: "로드 밸런싱 시 세션 관리 문제를 어떻게 해결하나요?"
A1: 세션 스티키(sticky session)를 사용할 수도 있지만, 확장성 문제 때문에 Redis 같은 외부 세션 저장소를 활용해 서버 간 세션을 공유합니다.
Q2: "스케일 업과 스케일 아웃 중 어떤 상황에서 각각 적합하다고 보나요?"
A2: 단기적으로 성능 향상이 필요할 때는 스케일 업이 빠르지만, 장기적으로 트래픽 증가에 대응하려면 스케일 아웃이 더 유연합니다.

2. 비동기 처리와 메시지 큐

Q1: "메시지 큐를 도입했을 때 장애 상황을 어떻게 대비하나요?"
A1: 메시지 큐 장애 시 재시도 로직을 구현하고, DLQ(Dead Letter Queue)를 활용해 실패 메시지를 별도로 관리합니다.
Q2: "Kafka와 RabbitMQ를 선택할 때 기준은 무엇인가요?"
A2: Kafka는 대규모 스트리밍 데이터 처리에 강점이 있고, RabbitMQ는 라우팅과 복잡한 메시지 패턴에 적합합니다.

3. 캐싱 전략

Q1: "캐시 갱신 정책은 어떻게 설정하나요?"
A1: TTL(Time To Live)을 설정하거나, Write-through/Write-behind 전략을 사용해 데이터 일관성을 유지합니다.
Q2: "캐시로 인한 데이터 불일치 문제를 어떻게 해결하나요?"
A2: 캐시 무효화 정책을 명확히 하고, 중요한 데이터는 DB와 캐시를 동시에 검증하는 방식을 적용합니다.

4. 데이터베이스 최적화

Q1: "읽기/쓰기 분리 시 발생할 수 있는 문제는 무엇인가요?"
A1: 데이터 동기화 지연으로 인해 읽기 노드에서 최신 데이터가 반영되지 않을 수 있습니다. 이를 보완하기 위해 읽기 요청을 특정 상황에서는 마스터 DB로 보내도록 합니다.
Q2: "JPA에서 N+1 문제를 어떻게 해결하나요?"
A2: Fetch Join을 사용하거나, @EntityGraph를 활용해 필요한 데이터를 한 번에 가져오도록 합니다.

5. 마이크로서비스 아키텍처 (MSA)

Q1: "MSA 도입 시 가장 큰 어려움은 무엇인가요?"
A1: 서비스 간 통신 복잡성과 데이터 일관성 관리가 가장 큰 도전 과제입니다. 이를 위해 API Gateway와 Saga 패턴을 활용합니다.
Q2: "모놀리식에서 MSA로 전환할 때 어떤 기준으로 서비스를 분리하나요?"
A2: 비즈니스 도메인 중심으로 분리하고, 각 서비스가 독립적으로 배포 및 확장 가능해야 합니다.

6. 모니터링과 자동화

Q1: "모니터링 지표 중 가장 중요하게 보는 것은 무엇인가요?"
A1: 응답 시간(latency), 에러율, CPU/메모리 사용량 같은 지표를 우선적으로 모니터링합니다.
Q2: "CI/CD 파이프라인에서 롤백 전략은 어떻게 구성하나요?"
A2: 블루-그린 배포나 카나리 배포를 활용해 문제가 발생하면 이전 버전으로 빠르게 전환할 수 있도록 합니다.

SLOW SQL 수정할 때 고려사항

Collin — Sat, 22 Nov 2025 08:00:03 +0900

SLOW SQL 튜닝 시 가장 중요한 고려사항은 실행계획 분석, 인덱스 활용, SELECT 범위 최소화입니다. 이 세 가지가 성능 개선의 핵심이며, 그 외에도 조인 방식, 정렬/집계 처리, 통계 정보 최신화 등이 중요합니다.

SLOW SQL 튜닝 핵심 고려사항 (중요도 순)

1️⃣ 실행계획(Execution Plan) 분석

가장 중요한 첫 단계: DB가 쿼리를 어떻게 수행하는지 확인
확인 항목: 인덱스 사용 여부, 테이블 스캔 방식, 조인 순서, 예상 비용(Cost)
도구: EXPLAIN, AUTOTRACE, SQL PLAN 등

2️⃣ 인덱스 활용 여부

WHERE 절, JOIN 조건에 인덱스 컬럼 사용 여부 확인
주의: 함수 사용, 형 변환, OR 조건 등은 인덱스를 무효화할 수 있음
대응: 인덱스 설계 최적화, 조건절 단순화

3️⃣ SELECT 컬럼 범위 최소화

SELECT * 사용 지양: 불필요한 I/O 증가
정확히 필요한 컬럼만 명시: 실행 계획 재사용 가능성 증가

4️⃣ 조인 방식 및 순서 최적화

Nested Loop vs Hash Join 등 조인 방식 선택
큰 테이블을 먼저 읽는 구조는 피해야 함
불필요한 FULL SCAN 조인 제거

5️⃣ GROUP BY, ORDER BY 처리 방식

정렬/집계 비용이 높은 경우 성능 저하
인덱스를 활용한 정렬 대체 가능 여부 확인

6️⃣ 서브쿼리 vs JOIN 구조 개선

서브쿼리는 중첩 실행으로 성능 저하 가능
JOIN으로 구조 변경 시 성능 향상 가능

7️⃣ 통계 정보 및 옵티마이저 최신화

DB가 잘못된 실행계획을 선택할 수 있음
통계 정보 최신화로 정확한 계획 수립 유도

8️⃣ 페이징 처리 (LIMIT, OFFSET 등)

대량 데이터 조회 시 반드시 페이징 처리
불필요한 전체 데이터 로딩 방지

실무 팁 요약

EXPLAIN으로 실행계획부터 확인
인덱스가 무효화되지 않도록 조건절 점검
SELECT * 대신 필요한 컬럼만 명시
JOIN 구조와 순서 최적화
정렬/집계는 인덱스로 대체 가능 여부 확인
통계 정보 최신화는 튜닝의 기본

java Call by Value와 Call by Reference

Collin — Fri, 21 Nov 2025 08:00:49 +0900

자바에서 Call by Value(값에 의한 호출)와 Call by Reference(참조에 의한 호출)의 차이는 '무엇이 전달되는가'에 있습니다. 자바는 기본적으로 Call by Value만 지원합니다.

핵심 차이 요약

항목 Call by Value (값에 의한 호출) Call by Reference (참조에 의한 호출)

전달 방식	변수의 값을 복사해서 전달	변수의 주소(참조)를 전달
원본 데이터 영향	메서드 내에서 변경해도 원본에 영향 없음	메서드 내에서 변경 시 원본 데이터도 변경됨
자바에서의 지원	✅ 기본형(primitive type)에 적용됨	❌ 자바는 엄밀히 말해 Call by Reference를 지원하지 않음
객체 전달 시	객체의 참조값이 복사되어 전달됨 → 객체 내부는 변경 가능	참조 자체를 바꾸는 건 불가능 (새 객체 할당 시 원본 영향 없음)

예시로 이해하기

class Dog {
    String name;
}

public class Test {
    public static void changeName(Dog d) {
        d.name = "Max"; // 객체 내부 값 변경 → 원본 영향 O
        d = new Dog();  // 새로운 객체 할당 → 원본 영향 X
        d.name = "Charlie";
    }

    public static void main(String[] args) {
        Dog dog = new Dog();
        dog.name = "Buddy";
        changeName(dog);
        System.out.println(dog.name); // 결과: "Max"
    }
}

d.name = "Max"는 원본 객체의 필드를 변경 → 영향 있음
d = new Dog()는 참조 자체를 바꿈 → 원본 객체에는 영향 없음

정리

자바는 모든 메서드 호출을 Call by Value로 처리합니다.
객체를 전달할 때도 *참조값(reference)*을 복사해서 전달하므로, 객체의 내부 상태는 변경 가능하지만, 참조 자체를 바꾸면 원본에는 영향 없음입니다.
C++ 같은 언어는 진짜 Call by Reference를 지원하지만, 자바는 그렇지 않습니다

웹 서버 취약점 목록 및 요약

Collin — Fri, 21 Nov 2025 07:00:42 +0900

웹 서버 취약점은 해커가 시스템을 침해하거나 정보를 탈취할 수 있는 보안상의 약점입니다. 주요 취약점은 OWASP Top 10과 일반적인 서버 취약점으로 나뉘며, 각각에 대한 이해와 대응이 필수입니다.

대표적인 웹 서버 취약점 목록 및 요약

✅ OWASP Top 10 기반 주요 취약점

OWASP(Open Web Application Security Project)는 웹 보안의 표준 가이드라인을 제공합니다:

Broken Access Control (접근 제어 실패)
- 권한 없는 사용자가 관리자 기능에 접근 가능
- 대응: 역할 기반 접근 제어(RBAC), 서버 측 권한 검증
Cryptographic Failures (암호화 실패)
- 민감 정보가 평문으로 저장되거나 전송됨
- 대응: HTTPS 사용, 강력한 암호화 알고리즘 적용
Injection (SQL, OS, LDAP 등)
- 악의적 명령어 삽입으로 DB나 시스템 제어
- 대응: 입력값 검증, Prepared Statement 사용
Insecure Design (불안전한 설계)
- 보안을 고려하지 않은 시스템 구조
- 대응: 보안 설계 원칙 적용, 위협 모델링 수행
Security Misconfiguration (보안 설정 오류)
- 디폴트 설정, 불필요한 기능 활성화 등
- 대응: 최소 권한 원칙, 보안 설정 점검 자동화
Vulnerable and Outdated Components
- 패치되지 않은 라이브러리나 프레임워크 사용
- 대응: 정기적 업데이트, 취약점 관리 도구 활용
Identification and Authentication Failures
- 인증 우회, 약한 비밀번호 정책
- 대응: 다중 인증(MFA), 강력한 패스워드 정책
Software and Data Integrity Failures
- 무결성 검증 없는 자동 업데이트 등
- 대응: 서명된 코드 사용, CI/CD 보안 강화
Security Logging and Monitoring Failures
- 침해 탐지 실패, 로그 미수집
- 대응: 실시간 모니터링, 로그 분석 시스템 구축
Server-Side Request Forgery (SSRF)
- 서버가 외부 요청을 대신 수행하게 유도
- 대응: 외부 요청 제한, URL 화이트리스트 적용

기타 일반적인 웹 서버 취약점

취약점 유형 설명 대응 방법

XSS (크로스사이트 스크립팅)	악성 스크립트를 사용자 브라우저에 삽입	입력값 필터링, Content Security Policy 적용
Directory Traversal	상위 디렉토리 접근을 통한 파일 노출	경로 필터링, 파일 접근 제한
Buffer Overflow	과도한 입력으로 메모리 침범	입력 길이 제한, 예외 처리
Command Injection	시스템 명령어 실행 유도	입력값 검증, 쉘 명령어 사용 제한
File Upload 취약점	악성 파일 업로드로 서버 제어	확장자 및 MIME 타입 검증, 실행 권한 제한

핵심 요약

입력값 검증은 거의 모든 취약점 대응의 기본입니다.
최신 보안 패치 적용과 불필요한 기능 제거는 서버 보안의 핵심입니다.
보안 로그와 모니터링은 침해 사고 탐지에 필수입니다.
OWASP Top 10은 웹 보안 점검의 출발점으로 삼아야 합니다.

웹 서버 보안은 단순한 기술 문제가 아니라 기업 신뢰와 직결되는 중요한 요소입니다. 보안 점검 자동화 도구나 전문가의 정기 점검도 고려해보세요.

java Overloading과 Overriding

Collin — Thu, 20 Nov 2025 20:00:28 +0900

자바에서 오버로딩과 오버라이딩은 모두 메서드를 다형적으로 사용하는 방식이지만, 목적과 사용 방식이 다릅니다.

오버로딩 (Overloading)

같은 이름의 메서드를 매개변수만 다르게 정의하는 것

정의 위치: 같은 클래스 내에서 사용
조건:
- 메서드 이름은 같음
- 매개변수의 개수, 타입, 순서 중 하나 이상이 달라야 함
- 리턴 타입만 다르면 오버로딩 불가능
예시:
void print() {} void print(String s) {} void print(int x, int y) {}
용도: 다양한 입력에 대해 같은 기능을 수행하고 싶을 때

오버라이딩 (Overriding)

상위 클래스의 메서드를 하위 클래스에서 재정의하는 것

정의 위치: 상속 관계에서 하위 클래스에서 사용
조건:
- 메서드 이름, 매개변수, 리턴 타입 모두 동일해야 함
- 접근 제어자는 상위 클래스보다 좁으면 안 됨
- @Override 어노테이션 사용 권장
예시:
class Animal { void sound() { System.out.println("Animal sound"); } } class Dog extends Animal { @Override void sound() { System.out.println("Bark"); } }
용도: 상속받은 기능을 자식 클래스에서 변경하고 싶을 때

핵심 차이 요약

항목 오버로딩 오버라이딩

관계	같은 클래스 내	상속 관계 (부모 → 자식)
메서드 이름	같음	같음
매개변수	다름	같음
리턴 타입	상관 없음	같아야 함
목적	다양한 입력 처리	부모 메서드 기능 재정의