VIVA LA VIDA

MyBatis vs JPA

해로몬 — Thu, 26 Jun 2025 19:20:23 +0900

MyBatis

XML이나 annotaion을 통하여 SQL문을 작성하고 객체들을 연결시키는 프레임워크이다.

// ✅ MyBatis 예시 (XML Mapper)
<select id="findUserById" parameterType="int" resultType="User">
    SELECT * FROM users WHERE id = #{id}
</select>

MyBatis 특징

SQL을 개발자가 직접 작성
복잡한 쿼리 로직에 유리
XML 또는 어노테이션 기반 매핑
DB에 최적화된 쿼리 튜닝 가능

장점

복잡한 SQL, JOIN, 서브쿼리, Stored Procedure 활용에 강함
SQL이 명시적이라 로직 추적 및 디버깅 용이
특정 DB에 맞는 최적화 쿼리 작성 가능

단점

SQL 작성 및 관리 부담
코드와 SQL이 분리돼 있어 유지보수 어려움
객체 지향적 개발에서 한계

JPA

Java 진영에서 ORM(Object-Relational Mapping) 기술 표준으로 사용하는 인터페이스 모음

// ✅ JPA 예시
User user = userRepository.findById(1L).orElse(null);

JPA 특징

객체 중심으로 데이터베이스 접근
SQL을 자동 생성 및 실행
ORM을 통한 객체-테이블 매핑
트랜잭션, 캐시, 지연로딩, 더티 체킹 등 풍부한 기능 제공

장점

생산성 높음 (SQL 작성 최소화)
유지보수 쉬움 (도메인 중심 개발 가능)
DB 벤더 독립성 확보
1차 캐시, 지연로딩 등으로 성능 최적화

단점

복잡한 SQL 튜닝 어렵거나 비효율적일 수 있음
JPA 동작 원리 학습 필요
잘못 쓰면 N+1 문제, 예상치 못한 쿼리 발생 가능

상황에 따른 프레임워크 추천

*상황/요구사항*	*추천 프레임워크*
CRUD 중심, 생산성 우선	JPA
도메인 모델 중심 아키텍처 필요	JPA
복잡한 SQL, 다이나믹 쿼리	MyBatis
특정 DB에 최적화 필요	MyBatis

선택 기준 정리

초기 개발 속도 중요 → JPA
SQL 주도 개발 선호 → MyBatis
복잡한 쿼리 비중 높음 → MyBatis
도메인 중심, 객체지향 아키텍처 중요 → JPA

MyBatis vs JPA 핵심 정리

MyBatis
- SQL을 직접 작성하고 세밀하게 제어 가능
- 복잡한 쿼리나 DB 성능 최적화에 강점
- SQL 관리와 유지보수 부담 존재
JPA
- 객체 지향적 개발과 생산성 향상
- SQL 자동 생성, 코드와 DB 매핑 자동화
- 내부 동작 원리 숙지 필요, 예상치 못한 쿼리 발생 가능

결론적으로, 프로젝트 특성에 맞는 선택이 중요합니다.
단순한 CRUD 위주라면 JPA가 생산성을 높여주고,
복잡한 쿼리나 DB 최적화가 필요한 경우 MyBatis가 더 적합합니다.

RDBMS에서 정규화란?

해로몬 — Thu, 26 Jun 2025 19:03:22 +0900

정규화란?

관계형 데이터베이스에서 데이터 중복을 최소화하고, 데이터 구조를 체계적으로 설계하기 위해 테이블을 분해하고 재구성하는 과정입니다.

[정규화의 목표]

데이터 중복 최소화
데이터 무결성 유지
삽입(Insert), 수정(Update), 삭제(Delete) 이상(Anomaly) 방지
데이터 구조의 일관성 확보

제1정규형 (1NF)

테이블은 모든 속성이 원자값을 가져야 한다.
중첩 데이터, 반복 그룹 제거

학생 ID	이름	연락처
1	홍길동	010-1234, 010-5678

→ 1NF 적용 후

학생ID	이름	연락처
1	홍길동	010-1234
1	홍길동	010-5678

제2정규형 (2NF)

부분 함수 종속 제거
기본키의 일부에만 종속되는 속성을 분리한다.
복합키 사용 시 해당된다.

| 학번 | 과목코드 | 교수명|성적 |

(학번,과목코드) →성적
과목코드 →교수명(부분 종속)

→ 2NF 적용 후 분리
학생-성적 테이블
| 학번 | 과목코드 | 성적 |

과목 테이블
| 과목코드 | 교수명 |

제3정규형 (3NF)

이행적 함수 종속 제거
기본키가 아닌 다른 속성에 종속되는 속성을 분리한다.

| 직원ID | 부서ID | 부서명 |

직원ID → 부서ID
부서ID → 부서명 (이행적 종속)

→ 3NF 적용 후 분리
직원 테이블
| 직원ID | 부서ID |

부서 테이블
| 부서ID | 부서명 |

BCNF

모든 결정자가 후보키일 것
(예시) 복합키가 여러 개 존재하거나 후보키가 여러 개인 경우 추가 분해 필요하다.

학번(StudentID)	강의실(Room)	교수(Professor)
1001	101호	김교수
1002	102호	이교수
1003	101호	김교수

→ BCNF 적용 후 분리

학번(StudentID)	강의실(Room)
1001	101호
1002	102호
1003	101호

강의실(Room)	교수(Professor)
101호	김교수
102호	이교수

제4정규형 (4NF)

다치 종속 제거
한 테이블에 여러 독립적인 다중 값이 존재하면 분리한다.

제5정규형 (5NF)

조인 종속 제거
테이블을 분해했다가 조인할 때 정보 손실이 없는 상태

정규화의 장점과 단점

장점

데이터 중복 감소
데이터 무결성 향상
테이블 구조의 논리적 설계

단점

테이블 수 증가 → JOIN 연산 많아져 성능 저하 가능성
시스템 규모나 상황에 따라 반정규화(Denormalization) 를 고려하기도 함

따라서 정규화는 안정적이고 일관성 있는 데이터베이스를 구축하고, 시스템의 확장성과 유지보수를 용이하게 만드는 핵심 설계 원칙이다.

RESTful API 설계의 핵심 원칙

해로몬 — Thu, 26 Jun 2025 18:38:12 +0900

RESTful API란 무엇인가

RESTful API는 **Representational State Transfer(표현 상태 전달)**라는 아키텍처 스타일을 따르는 웹 API 설계 방식이다.
주로 HTTP 프로토콜을 기반으로 하며, **자원(Resource)**을 중심으로 데이터를 주고받는다.

단순한 데이터 전송이 아닌, 명확한 설계 원칙과 구조를 갖춘 통신 방식이다.

RESTful API의 핵심 개념

REST의 철학은 다음과 같다:

자원의 표현(Representation)을 전송(Transfer) 하여, 클라이언트와 서버가 상태를 주고받는다.
서버는 상태를 저장하지 않는 Stateless 구조를 따른다.
HTTP URI로 자원을 식별하고, HTTP 메서드를 통해 행위를 정의한다.

이러한 원칙을 따르는 API를 RESTful API라고 부른다.

RESTful API의 6가지 핵심 원칙

1. 자원 지향 아키텍처

REST API는 모든 것을 자원(Resource) 중심으로 설계한다. 각 자원은 고유한 URI(Uniform Resource Identifier) 로 식별되며, URL을 통해 자원의 위치를 명확히 표현해야 한다.

- URL 설계 규칙
  - 명사 사용 및 복수형 표현
    - 자원 이름은 명사로 표현하고, 복수형을 사용한다.
    - 예시:
      /users → 사용자 목록
      /products → 상품 목록
      /orders → 주문 목록
  - HTTP 메서드로 행위 구분 (CRUD 매핑)
    - GET /users → 사용자 목록 조회
    - POST /users → 사용자 생성
    - GET /users/{id} → 특정 사용자 조회
    - PUT /users/{id} → 사용자 정보 수정
    - DELETE /users/{id} → 사용자 삭제
  - 경로 변수 최소화 및 계층 구조 표현
    - 필요한 최소한의 경로 변수만 사용
    - 계층적 관계는 URL로 표현
    - 예시:
      /users/{userId}/orders → 특정 사용자의 주문 목록 조회
  - 쿼리 매개변수로 필터링, 정렬, 페이징 지원
    - 예시:
      /products?category=electronics&sort=price&page=2&size=10
  - 버전 관리 필수
    - API의 안정성을 위해 버전을 URI에 명시
    - 예시:
      /api/v1/users

2. 무상태성 (Stateless)

서버는 클라이언트의 상태 정보를 저장하지 않는다.
각 요청은 완전 독립적으로 동작하며, 필요한 모든 정보는 요청에 포함되어야 한다.

장점:

서버 확장성 향상
요청 간 간섭 최소화
시스템 복잡도 감소

3. 캐시 가능 (Cacheable)

캐시 사용은 네트워크 지연을 줄이고, 서버의 부하를 경감시키며, 전반적인 성능을 향상시킨다. 따라서 API 응답에는 캐싱 정책을 명시해야 하고, 클라이언트가 응답을 적절히 캐시할 수 있도록 해야한다.

4. 클라이언트 - 서버 구조 분리

REST는 클라이언트와 서버가 독립적으로 동작할 수 있도록 분리된 구조를 강조한다.

각 부분의 독립적인 진화를 가능하게 하여, 서버의 기능 개선이 클라이언트의 업데이트 없이 이루어질 수 있도록 지원한다.

5. 계층화 시스템 (Layered System)

클라이언트는 요청이 직접 서버에 도달하는지, 중간에 프록시나 게이트웨이가 있는지 알 수 없다.
이 계층 구조 덕분에 로드 밸런싱, 보안, 암호화 등을 투명하게 적용할 수 있다.

6. 코드 온 디맨드 (선택 사항)

서버가 실행 가능한 코드를 클라이언트에 전송하여 클라이언트의 기능을 일시적으로 확장할 수 있음을 의미한다. 이 원칙은 클라이언트의 유연성을 높이지만, 필수는 아니다.

HTTP 상태코드

해로몬 — Wed, 25 Jun 2025 22:49:55 +0900

HTTP 상태 코드란?

HTTP 상태 코드는 클라이언트의 요청에 대한 서버의 응답 상태를 나타내는 숫자 코드이다.
총 5가지 범주(1xx~5xx)로 나뉘며, 각 코드의 앞자리 숫자가 의미하는 범주는 다음과 같다.

상태 코드 분류

범위	이름	설명
1xx	정보 응답	요청을 받았으며 처리를 계속함
2xx	성공 응답	요청이 정상적으로 처리됨
3xx	리다이렉션	추가 조치가 필요함 (다른 위치로 이동 등)
4xx	클라이언트 오류	클라이언트의 잘못된 요청
5xx	서버 오류	서버 내부 문제로 요청 실패

✅ 대표 상태 코드 상세 설명

1xx - 정보

100 Continue
요청의 일부가 전송되었으며 나머지를 계속 보내도 됨.

2xx - 성공

200 OK
가장 일반적인 성공 응답. GET, POST, PUT 등 다양한 요청에 사용된다.
201 Created
리소스가 성공적으로 생성됨. 주로 POST 요청 시 사용.
204 No Content
요청은 성공했지만 응답 본문은 없음. DELETE 요청 후 자주 사용됨.

→ "성공 응답"이라고 할 때, 가장 대표적인 코드는 200 OK이다.

3xx - 리다이렉션

301 Moved Permanently
요청한 리소스가 영구적으로 이동함.
302 Found
일시적으로 다른 위치에서 응답함.
304 Not Modified
캐시된 리소스가 그대로 사용 가능함.

4xx - 클라이언트 오류

400 Bad Request
잘못된 문법으로 인해 서버가 요청을 이해할 수 없음.
401 Unauthorized
인증이 필요함. (예: 로그인하지 않은 상태로 접근 시)
403 Forbidden
서버가 요청을 이해했지만 거부함. 권한 부족.
404 Not Found
요청한 리소스를 찾을 수 없음. (가장 자주 마주치는 오류 중 하나)

5xx - 서버 오류

500 Internal Server Error
서버 내부에서 처리 중 알 수 없는 에러 발생.
502 Bad Gateway
게이트웨이 또는 프록시 서버가 잘못된 응답을 받음.
503 Service Unavailable
서버가 일시적으로 요청을 처리할 수 없음. (예: 서버 점검 중)

자주 묻는 질문 (FAQ)

Q. 200 OK는 언제 사용하나요?

→ 요청이 성공적으로 처리된 경우 대부분의 HTTP 메서드에서 사용된다.
예:

GET 요청에 대한 정상 응답
PUT 요청으로 데이터 업데이트 완료 시
POST 요청이지만, 새로 생성된 리소스 정보가 응답에 포함되지 않을 때

Q. POST 요청 시 꼭 201을 써야 하나요?

→ 반드시 그런 것은 아니다.
201은 리소스가 생성된 경우에 사용하는 것이 명확하지만, 일부 API에서는 200으로 응답하기도 한다.

RESTful API 설계 지침에서는 보통 201 사용을 권장한다.

MVC 패턴

해로몬 — Wed, 25 Jun 2025 22:40:44 +0900

MVC 패턴이란?

MVC는 Model-View-Controller의 약자로, 애플리케이션을 세 가지 주요 구성 요소로 분리하는 소프트웨어 설계 패턴이다.
주로 웹 애플리케이션에서 사용되며, 코드의 역할을 명확히 나누고 유지보수와 확장성을 높이는 데 유리하다.

Model(모델):
애플리케이션의 핵심 데이터와 비즈니스 로직을 담당한다. 예를 들어 게시판이라면, 게시글 데이터를 조회·저장·수정하는 로직이 모델에 속한다.
View(뷰):
사용자에게 보이는 UI 화면을 담당한다. HTML, JSP, Thymeleaf 같은 템플릿 엔진이 여기에 해당하며, 데이터를 시각적으로 보여주는 역할을 한다.
Controller(컨트롤러):
사용자의 요청을 받아 Model에게 전달하고, 처리 결과를 View로 연결해주는 중간 조율자 역할을 한다. 예를 들어 로그인 요청을 받으면, Controller는 Model에게 인증을 요청하고 결과에 따라 알맞은 화면(View)을 반환한다.

MVC 패턴의 흐름

[User] 
   ↓
[Controller] → [Model] → DB
   ↓
[View] → 사용자에게 결과 표시

사용자가 브라우저에서 요청을 보낸다. (예: /login)
Controller가 요청을 받아 적절한 Model에게 작업을 요청한다.
Model은 로직을 수행하고 결과를 Controller에게 반환한다.
Controller는 결과를 View에 전달하고, View는 사용자에게 화면을 출력한다.

MVC 패턴의 장점

역할의 명확한 분리
구성 요소의 책임이 명확하게 구분되어 있어 코드의 가독성이 높고, 유지보수가 쉬워진다.
화면(View)을 수정해도 핵심 로직(Model)은 영향을 받지 않고, 그 반대도 마찬가지이다.
낮은 결합도와 높은 응집도
각 구성 요소는 서로 강하게 의존하지 않기 때문에, 독립적으로 개발·수정·테스트가 가능하다.
코드 재사용성과 유연성이 높아진다.
모델 재사용 가능
하나의 Model을 여러 View에서 사용할 수 있어, 웹, 모바일, 관리자 페이지 등 다양한 환경에 적용 가능하다.
협업에 유리함
프론트엔드는 View 중심으로, 백엔드는 Controller와 Model 중심으로 개발할 수 있어 업무 분담과 협업이 효율적이다.

MVC 패턴의 한계점

간단한 프로젝트에선 과한 구조가 될 수 있다
작은 규모의 기능이라도 Model, View, Controller로 나누어야 하므로
오히려 코드가 복잡해지고 초기 개발 속도를 떨어뜨릴 수 있다.
Controller 비대화 현상 (Massive Controller)
설계가 잘못되면 Controller에 여러 책임이 몰려서, 로직이 복잡해지고 유지보수가 어려워질 수 있다.
→ 일반적으로 Service 계층을 도입해 책임을 분산시킨다.
완전한 역할 분리가 어려운 경우가 있다
현실적인 코드에서는 View에 일부 로직이 들어가거나,
Controller가 Model에 과하게 의존하는 등 구조가 흐트러질 수 있다.
테스트 코드 작성의 어려움
Controller가 여러 책임을 가지면 단위 테스트가 어려워지고,
의존성 주입이나 계층 분리가 되어 있지 않으면 테스트 코드 작성이 번거로워진다.
Model과 View의 의존성을 완전히 분리하기 어렵다
실무에서는 View에서 Model 객체를 직접 참조하는 일이 많으며,
이로 인해 설계 원칙에서 말하는 '완전한 분리'가 잘 지켜지지 않을 수 있다.

MVC 패턴의 설계 원칙

MVC 패턴을 올바르게 사용하기 위해서는 다음과 같은 구조적 원칙을 지켜야 한다:

Model은 Controller와 View에 의존하지 않아야 한다.
Model은 순수하게 데이터와 로직만 처리하는 계층이어야 하며, 다른 구성 요소에 의존하면 안 된다.
View는 Controller에 의존하면 안 되고, Model만 참조해야 한다.
View는 Model에서 데이터를 받아 표현하는 데 집중해야 하며, 로직은 Controller나 Model에 맡겨야 한다.
Controller는 Model과 View에 의존할 수 있다.
사용자의 입력을 처리하고, 로직을 호출하고, 그 결과를 View에 전달하는 책임을 가지므로, 양쪽에 접근이 가능해야 한다.
View가 데이터를 필요로 할 때는 Controller를 통해 Model에서 받아야 한다.
View는 직접 Model을 호출하지 않고, Controller가 필요한 데이터를 준비해 전달해야 한다. (→ 실무에서는 View가 Model을 직접 참조하는 경우도 있지만, 이상적인 구조는 Controller가 중간 다리 역할을 하는 것)

Kotlin과 같은 등급은 Java인가 Spring인가?

해로몬 — Wed, 25 Jun 2025 20:14:48 +0900

Kotlin과 같은 등급은 Java인가 Spring인가?

Kotlin과 같은 프로그래밍 언어는 Java 입니다.
Spring은 프레임워크로 웹 애플리케이션을 개발하기 쉽게 도와주는 도구입니다.

항목	성격/역할	예
Java	프로그래밍 언어	C++, Python 같은 언어
Kotlin	프로그래밍 언어	Java의 대안 또는 JVM 기반 언어
Spring	프레임워크	언어(Java 또는 Kotlin) 위에 올라가는 웹 개발 도구

Java와 Kotlin의 공통점

JVM 기반 언어
강력한 도구와 라이브러리 공유
- 같은 개발 도구(IDE) 사용 가능
  - 예: IntelliJ IDEA, Android Studio 등
- 동일한 Java 라이브러리 사용 가능
  - Kotlin에서도 Java의 라이브러리나 프레임워크(Spring 등)를 그대로 사용할 수 있음
상호운용성 (Interoperability)
- Kotlin과 Java 코드를 서로 호출하고 혼용할 수 있음
- 예: Kotlin 클래스에서 Java 클래스를 불러오거나, 그 반대도 가능

Java와 Kotlin의 차이점

항목 Java Kotlin

문법	길고 반복적인 코드가 많음	간결하고 현대적인 문법
Null 처리	NullPointerException(NPE)에 취약	컴파일 타임에서 null 안전성 보장 (?, !! 등)
함수형 프로그래밍	제한적 지원	고차 함수, 람다 등 함수형 완전 지원
데이터 클래스	직접 모든 메서드 구현해야 함	data class 한 줄로 자동 생성
코루틴(비동기)	기본 지원 없음 (Thread 위주)	코루틴(Coroutines)으로 간단하고 가벼운 비동기 처리 가능
확장 함수	없음	fun 클래스명.함수명()으로 확장 가능

Java와 Kotlin의 장단점

	Java	Kotlin
장점	오랜 역사와 안정성 방대한 커뮤니티와 문서 라이브러리/프레임워크 다양함 기업용 시스템에 적합	문법이 간결해 생산성 ↑ Null 안정성으로 오류 ↓ 함수형/확장 함수 지원 코루틴으로 간단한 비동기 처리
단점	코드가 장황하고 반복적 NullPointerException 위험 최신 기능 도입이 느림	러닝 커브(Java 대비) 일부 빌드/컴파일 속도 느릴 수 있음 레거시 Java 프로젝트와 100% 호환은 아님(경우에 따라)

Spring - 의존성 주입(DI)의 종류

해로몬 — Wed, 25 Jun 2025 19:54:20 +0900

의존성 주입(Dependency Injection, DI)

스프링 컨테이너에서 객체 Bean을 먼저 생성해두고 생성한 객체를 지정한 객체에 주입하는 방식

의존성 주입의 종류로는

생성자 주입
필드주입
세터 주입

3가지 방법이 있다.

1.생성자 주입(Constructor Injection)

생성자를 통해 의존 객체를 주입받는 방식

*단일 생성자에 한해 @Autowired를 생략 가능

✅ 장점

불변성 보장 → final 사용 가능
필수 의존성 보장 → 의존 객체 없으면 객체 생성 자체가 안 됨
순환 의존을 조기에 발견 가능 → 애플리케이션 시작 시점에 오류 발생
테스트 코드 작성 용이 → 생성자 인자로 직접 주입 가능

❌ 단점

의존성이 많아지면 생성자가 길어질 수 있음 → 리팩터링 필요

@Component
public class OrderService {
    private final PaymentService paymentService;

    @Autowired
    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

2.필드 주입(Field Injection)

필드에 직접 @Autowired를 붙여서 주입받는 방식

✅ 장점

구현이 가장 간단하고 빠름
테스트용/프로토타입용 코드에 유용

❌ 단점

테스트 어려움 → 필드에 직접 접근 불가 (리플렉션 사용해야 함)
불변성 깨짐 → final 불가
Spring이 관리하는 환경에서만 동작 가능

@Component
public class AlertService {

    @Autowired
    private SmsSender smsSender;
}

3.세터 주입(Setter Injection)

setter 메서드를 통해 의존객체를 주입받는 방식

생성자 주입과는 다르게 주입받는 객체가 변경될 가능성이 있는 경우에 사용한다.

✅ 장점

의존성을 나중에 바꾸거나 설정 가능
필요할 때만 의존성 주입 가능

❌ 단점

객체 생성 시점에 완전한 초기화가 안 될 수도 있음
불변성 보장 안 됨

@Component
public class NotificationService {
    private MessageSender sender;

    @Autowired
    public void setSender(MessageSender sender) {
        this.sender = sender;
    }
}

@Autowired로 주입할 대상이 없는 경우에는 오류가 발생한다.

주입할 대상이 없어도 동작하도록 하려면 @Autowired(required = false)를 통해 설정할 수 있다.

[정리]

생성자 주입	필드 주입	세터 주입
가독성이 좋고, 테스트코드 작성에 용이하며, 런타임 시점에 유연성이 높다. *권장하는 방법	가독성이 가장 떨어지기 때문에 유지보수가 어려우며, 의존성 변경이 어려워 유연성이 떨어진다. *최대한 안쓰는 것이 좋다	생성자 주입에 비해 코드 가독성이 떨어지기 때문에 코드의 양이 많을 때 사용한다. 생성자를 통해 객체를 생성하고, Setter 메서드를 통해 의존성을 주입하는 것이 좋다.

Spring - 의존성 주입(DI)

해로몬 — Wed, 25 Jun 2025 19:04:34 +0900

의존성 주입(Dependency Injection, DI)

스프링 컨테이너에서 객체 Bean을 먼저 생성해두고 생성한 객체를 지정한 객체에 주입하는 방식

외부에서 두 객체 간의 관계를 결정해주는 디자인 패턴,

인터페이스를 사이에 둿 클래스 레벨에서는 의존관계가 고정되지 않도록 런타임 시에 관계를 동적으로 주입하여 유연성을 확보하고 결합도를 낮출 수 있게 합니다.

두 객체 간의 관계라는 관심사의 분리
두 객체 간의 결합도를 낮춤
객체의 유연성을 높임.
테스트 작성을 용이하게 함.

의존성 주입을 왜 사용하는가?

public class Store{
	private Coke coke;
    
    public Store(){
    	this.coke = new Coke();
    }
}

<문제점>

1. 두 클래스가 강하게 결합되어 있다

만약 Store에서 Coke가 아닌 Milk로 변경하고자 한다면 Store 클래스의 생성자에 변경이 필요 -> 유연성이 떨어진다.

2. 객체들 간의 관계가 아니라 클래스 간의 관계가 맺어진다. -> 객체 지향 위배

올바른 객체지향적 설계라면 객체들 간에 관계가 맺어져야 한다.

객체들 간의 관계가 맺어졌다면 다른 객체의 구체 클래스(coke or milk)를 전혀 알지 못하더라도, 인터페이스의 타입(Drinks)으로 사용할 수 있다.

즉, 객체간의 관심이 분리 되지 않았다.

[의존성 주입으로 해결되는 점]

문제점	적용 후 해결 방식
강한 결합	Store는 더 이상 Coke, Milk 같은 구체 클래스에 의존하지 않고 Drinks 인터페이스에만 의존함. 따라서 다른 음료로 교체 시 Store를 수정할 필요가 없음
클래스 간의 관계	이제 클래스 간 관계가 아닌 객체 간의 관계로 구성됨. 외부에서 어떤 객체를 넣느냐에 따라 동작이 바뀌므로 유연성이 생김
관심사 분리	Store는 어떤 음료를 파는지에 대한 책임이 없음 → 책임이 분리되고 관심사가 명확해짐
확장성	새로운 음료 (Juice, Water 등) 추가 시 Store 수정 없이 사용 가능

요약

의존성 주입은 객체 간의 결합을 낮추고, 추상화된 타입을 통해 더 유연하고 테스트 가능한 구조를 만들어준다.
이로 인해 객체 지향 설계 원칙을 잘 따르게 되고, 유지보수와 확장이 쉬워진다.

AJAX를 사용하는 이유

해로몬 — Tue, 24 Jun 2025 23:26:51 +0900

Ajax란?

Ajax는 Asynchronous JavaScript and XML

자바스크립트를 이용해 웹 페이지를 새로고침하지 않고 서버와 통신할 수 있게 해주는 기술.

어떻게 동작할까?

사용자가 동작 실행
➡️ JavaScript가 서버에 요청
➡️ 서버가 응답 반환
➡️ 받은 데이터를 이용해 웹페이지 일부만 업데이트

Ajax의 주요 구성요소

HTML / CSS	웹 페이지의 구조와 스타일을 구성한다.
DOM (Document Object Model)	자바스크립트가 HTML 요소를 동적으로 조작할 수 있도록 도와준다.
JavaScript	Ajax의 중심. 서버 요청을 보내고, 받은 데이터를 처리한다.
XMLHttpRequest	브라우저에서 서버와 데이터를 주고받는 API이다.
JSON / XML / 텍스트 등	서버와 주고받는 데이터 형식. 요즘은 대부분 JSON 사용한다.
이벤트 (Event)	버튼 클릭, 스크롤 등 사용자 동작을 트리거로 Ajax 요청을 보낸다.

AJAX를 사용하는 이유

장점	설명
전체 페이지 새로고침 없이 일부만 업데이트	필요한 부분만 바꿔서 빠르고 부드러운 사용자 경험 제공
페이지 로드 후에도 서버와 통신 가능	동적으로 데이터를 가져오고, 업데이트 가능
백그라운드 통신 가능	사용자가 인식하지 못하는 사이에 서버 요청 처리
비동기 처리로 속도 향상	응답을 기다리지 않고 다음 작업 수행 가능
서버 자원과 트래픽 절약	전체 페이지가 아니라 필요한 데이터만 요청

⚠️ Ajax의 한계

히스토리 관리가 되지 않고, 페이지간 이동 없는 통신 방법으로 보안 상의 문제가 생길 수 있음.
연속으로 데이터 요청 -> 서버 부하 증가
디버깅 어려움
서버 푸시가 불가 => 클라이언트가 요청해야 함.

클라이언트 풀링 방식: 사용자가 직접 원하는 정보를 서버에게 요청하여 얻는 방식
서버 푸시 방식 : 사용자가 요청하지 않아도 서버가 알아서 특정 정보를 제공하는 것을 의미.
대표적으로 앱에서 자동으로 보내는 푸시 알림이 있음.

요약

AJAX는 HTML, DOM, JavaScript, 서버 통신 API(XMLHttpRequest 등)를 함께 활용해 새로고침 없이 동적으로 웹 페이지를 갱신하는 기술 방식입니다.

동기(Synchronous)와 비동기(Asynchronous)의 차이점

해로몬 — Tue, 24 Jun 2025 21:49:03 +0900

✅ 동기(Synchronous)란?

작업이 순차적으로 진행되며, 하나의 작업이 완료되기 전에는 다음 작업으로 넘어가지 않습니다.

예시

A 작업이 끝나야만 B 작업을 시작할 수 있는 구조입니다.

주요 특징

순차적 실행: 하나의 작업이 끝나야 다음 작업으로 진행됨
직관적인 흐름: 코드 흐름이 간단하고 이해하기 쉬움
성능 저하 가능성: 시간이 오래 걸리는 작업이 전체 흐름을 지연시킬 수 있음

언제 사용하면 좋을까?

작업의 순서가 중요한 경우
이전 작업의 결과가 바로 다음 작업에 필요할 때
간단한 스크립트나 소규모 프로그램에 적합

✅ 비동기(Asynchronous)란?

작업이 서로 독립적으로 실행되며, 하나의 작업이 끝나기를 기다리지 않고 다음 작업을 수행할 수 있는 방식입니다.

예시

A 작업이 완료되기를 기다리는 동안 B 작업도 같이 수행됩니다.

주요 특징

병렬적인 작업 처리 가능
대기 시간 최소화: 사용자가 느끼는 응답 속도가 빨라짐
복잡한 구조: 콜백, 프로미스, 예외 처리 등으로 코드가 복잡해질 수 있음

언제 사용하면 좋을까?

네트워크 요청, 파일 읽기/쓰기 등 시간이 오래 걸리는 작업
여러 작업을 동시에 처리해야 할 때
UI 응답성을 유지해야 할 때
대규모 트래픽을 처리하는 서버 애플리케이션

주요 비동기 프로그래밍 패턴

1. Callback

작업 완료 시 특정 함수를 호출하는 방식

장점: 간단한 구조
단점: 콜백 지옥(Callback Hell) 발생 가능

function getData(callback) {
  setTimeout(() => {
    const data = "데이터";
    console.log("1. 데이터를 가져왔습니다.");
    callback(data);
  }, 1000);
}

function processData(data, callback) {
  setTimeout(() => {
    const processed = data + " → 처리됨";
    console.log("2. 데이터를 처리했습니다.");
    callback(processed);
  }, 1000);
}

function displayResult(result) {
  console.log("3. 결과:", result);
}

// 실행
getData(function(data) {
  processData(data, function(result) {
    displayResult(result);
  });
});

--------------------------------
(1초 후) 1. 데이터를 가져왔습니다.  
(1초 후) 2. 데이터를 처리했습니다.  
        3. 결과: 데이터 → 처리됨

설명

getData() → 1초 후 "데이터" 반환
반환된 데이터를 processData()로 넘김
처리된 결과를 displayResult()에서 출력

2. Promise / Future

작업의 성공/실패 결과를 약속하는 객체를 사용하여 흐름 제어

장점: 체이닝(Chaining) 으로 가독성 향상
단점: 예외 처리가 복잡할 수 있음

function getData() {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            resolve("데이터");
        }, 1000);
    });
}

getData()
    .then(data => console.log(data))
    .catch(error => console.error(error));

설명

getData()는 1초 후 "데이터"를 반환하는 비동기 함수
.then() 안의 콜백은 작업이 성공(resolve) 되었을 때 실행됩니다.
.catch()는 작업이 실패(reject) 했을 때 에러를 처리합니다.

3. Async / Await

비동기 코드를 동기 코드처럼 작성할 수 있게 해주는 문법

장점: 가독성 좋고 직관적
단점: 구형 환경이나 일부 언어에서는 지원하지 않을 수 있음

async function main() {
  try {
    const data = await getData();
    const processed = await processData(data);
    displayResult(processed);
  } catch (error) {
    console.error("에러 발생:", error);
  }
}

main();

⚠️ 비동기 프로그래밍 시 주의할 점

동시성 문제(Concurrency)
- 여러 작업이 동시에 실행되면서 예상치 못한 결과가 발생할 수 있음
복잡한 흐름 제어
- 예외 처리, 상태 관리가 까다로울 수 있음
과도한 사용은 오히려 성능 저하
- 필요하지 않은 곳에 비동기를 사용하면 오히려 디버깅이 어려워지고 CPU 리소스 낭비
블로킹 코드 주의
- 비동기 흐름 중 동기 함수가 전체 흐름을 막는 경우 있음

항목	동기(Synchronous)	비동기(Asynchronous)
실행 방식	순차적	병렬 가능
코드 흐름	단순, 직관적	복잡하지만 유연
성능	작업 지연 시 전체 지연	작업 병렬 처리로 성능 향상
적합한 상황	작업 순서 중요, 단순한 로직	I/O, 대기 많은 작업, 대규모 처리 필요