AOP(Aspect Oriented Programming)는

핵심 관심사(Core Concern) 와

횡단 관심사(Cross-cutting Concern) 를 분리하여 프로그램을 구성하는 기법이다.

💡 핵심 로직에 집중하면서, 반복되는 공통 기능(로깅, 보안, 트랜잭션)을 따로 모듈화할 수 있도록 도와주는 기술

즉, 객체 지향이 놓치는 “중복되는 부가 기능을 하나로 모아 관리하는 방법”.

📌 2. 왜 AOP가 필요한가?

서비스 클래스를 여러 개 만들다 보면

모든 클래스에 이런 코드가 흩어져 나타난다:

• 로그 출력
• 인증/인가 체크
• 트랜잭션 시작/종료
• 실행 시간 측정
• 예외 로깅

이런 코드들이 여러 곳(C, D, E…)에 똑같이 흩어져 있으면 문제가 생긴다.

❌ 문제점

• 공통 기능이 여러 클래스에 중복 작성됨
• 공통 기능 수정 시 관련 파일 여러 개를 수정해야 함
• 핵심 비즈니스 로직이 공통 코드 때문에 지저분해짐
• 유지보수성 저하

그래서 공통 기능을 한 곳에 모아서 처리하는 방식이 필요해졌고,

그것이 바로 AOP다.

📌 3. 핵심 관심사 vs 횡단 관심사

✔ 핵심 관심사(Core Concern)

• 각 클래스가 수행해야 할 비즈니스 고유 기능
• 예:
  • 주문 서비스 → 주문 생성
  • DB 강의 → DB 설계
  • 알고리즘 강의 → 알고리즘 풀이

✔ 횡단 관심사(Cross-cutting Concern)

• 모든 클래스에 공통적으로 필요한 기능
• 예:
  • 로그인 체크
  • 로그 출력
  • 예외 처리
  • 트랜잭션 관리
  • 보안 검사

🔥 핵심 포인트

횡단 관심사는 어떤 모듈에도 포함되지만, 실제 핵심 로직과 직접 연관되지 않음

→ 그러나 모든 곳에서 함께 실행됨

→ 그래서 “흩어진 관심사”라고 부름

📌 4. 생활 속 예시로 보는 AOP

✔ 예시 1: 대학 강의 시스템

공통된 프로세스

출석 확인 → 강의 진행 → 중간/기말고사 → 성적 처리

이 흐름은 모든 과목에 동일하게 적용됨.

핵심 관심사는 과목마다 다름

• 알고리즘 강의 → 알고리즘 문제 풀이
• 데이터베이스 강의 → 테이블 설계
• 운영체제 강의 → 프로세스 관리

횡단 관심사는 모든 강의에 동일

• 출석 체크
• 시험 관리
• 성적 계산

바로 이런 공통 로직을 AOP가 묶어서 처리해준다.

✔ 예시 2: 쇼핑 과정

가게가 달라도 다음 과정은 같다:

물건 고르기 → 장바구니 담기 → 결제하기 → 영수증 받기

여기서

• ‘물건 고르기’는 가게마다 다르므로 핵심 관심사
• 장바구니 담기, 결제, 영수증 받기 같은 과정은 모든 가게에서 공통 → 횡단 관심사

AOP는 공통 단계(횡단 관심사)를 하나로 모아 관리한다.

📌 5. AOP가 주는 장점

✔ 유지보수성 향상

• 코드가 더 깔끔하고 핵심 비즈니스 로직만 남음
• 수정해야 할 공통 기능의 위치가 명확해짐

✔ 코드 재사용성 증가

• 로깅, 보안, 트랜잭션 같은 기능을 한 번만 구현하면 여러 클래스에서 재사용 가능

✔ 테스트 용이성

• 핵심 로직을 공통 로직에서 분리하여 독립적으로 테스트 가능

✔ 디버깅 쉬움

• 공통 기능이 중앙 집중되어 있어 추적이 빠름

✔ 시스템 확장성 증가

• 새로운 공통 기능을 추가하더라도 기존 핵심 로직에 영향이 거의 없음

✔ 책임 분리 명확

• 각 모듈이 담당해야 할 역할이 분명해짐

📌 6. AOP 주요 용어

📌 7. AOP 핵심 매커니즘 한 번에 정리

✔ Aspect = 부가 기능을 모듈화한 클래스

예: LoggingAspect, TransactionAspect

✔ Pointcut = 어디에 적용할지 정의

예:

execution(* com.example.service.*.*(..))

✔ Advice = 언제 실행할지 정의

예:

• @Before
• @AfterReturning
• @Around

✔ Join Point = 적용 가능한 모든 지점

스프링에서는 주로 “메서드 실행 시점”

📌 8. 실제 적용 개념 요약

AOP는 아래와 같은 방식으로 동작한다.

핵심 기능 호출 전   → @Before
핵심 기능 실행       → 비즈니스 로직
핵심 기능 실행 후   → @After, @AfterReturning
예외 발생 시         → @AfterThrowing
전체 제어 필요 시     → @Around

공통 관심사를 핵심 로직에 섞지 않고도

필요한 순간에 적절하게 섞어서 실행할 수 있게 해주는 기술이다.

📌 9. AOP 최종 핵심 정리

✔ 핵심 비즈니스 로직과 공통 기능을 분리하는 프로그래밍 방법
✔ 공통 기능(로깅/보안/트랜잭션 등)을 Aspect로 모듈화
✔ 핵심 코드가 깔끔해지고 유지보수성이 좋아짐
✔ 코드 재사용성 크게 증가
✔ 스프링의 대표적인 장점 중 하나

어떤 객체가 작업을 수행하기 위해 다른 객체를 직접 생성하거나 사용해야 할 때 그 관계를 ‘의존한다’고 표현한다.

예를 들어, Roel 객체가 Galaxy 객체를 직접 생성하고 사용한다면,

Roel → Galaxy 로 의존성이 존재한다.

💡 요약
한 객체의 코드에서 다른 객체를 생성하거나 호출하면 의존성이 생긴 것이다.

📌 2. 결합도(Coupling)와 DI의 필요성

의존성의 강도를 ‘결합도(Coupling)’라고 한다.

🔥 강한 결합의 예시

public class Roel {
    private Galaxy phone;

    public Roel() {
        this.phone = new Galaxy();
    }
}

만약 Galaxy 대신 IPhone을 사용하고 싶다면?

→ Roel 내부 전체 코드를 수정해야 한다.

이처럼 구현 클래스에 강하게 묶여 있으면 변경에 취약하다.

📌 3. 느슨한 결합을 위한 방법: 인터페이스 사용

인터페이스를 도입하면 구현(Mobile 기종)이 바뀌어도

Roel 클래스는 Phone 인터페이스만 알고 있으면 된다.

🔽 Phone 인터페이스

public interface Phone {
    void powerOn();
    void payment();
}

🔽 구현 클래스들

public class Galaxy implements Phone { ... }
public class IPhone implements Phone { ... }

🔽 느슨한 결합의 Roel 클래스

public class Roel {
    private final Phone phone;

    public Roel(Phone phone) {
        this.phone = phone;
    }
}

Roel은 더 이상 Galaxy, IPhone이 무엇인지 알 필요가 없다.

→ 유연한 구조, 유지보수성 UP!

📌 4. DI(Dependency Injection)란?

DI는 말 그대로 의존성(Dependency)을 외부에서 주입(Injection)받는 방식이다.

즉, “필요한 객체를 스스로 new 로 만들지 않고, 외부에서 넣어주는 방식이다.”

💡 DI란?
객체가 사용할 객체의 생성 책임을 외부(스프링 컨테이너)에 넘기고
자신은 주입받은 객체만 사용한다.

이는 스프링이 지향하는 IoC(제어의 역전) 개념을 구체화한 것이다.

그래서 스프링을 IoC 컨테이너 혹은 DI 컨테이너라고도 부른다.

📌 5. DI의 장점

✔ 1) 결합도 감소 → 변경에 강한 코드

• 구현체를 교체해도 생성자만 바뀌면 됨
• 유지보수가 쉬움

✔ 2) 테스트 용이성 증가

• Mock 객체를 주입할 수 있어 단위 테스트가 쉬워짐

📌 6. Spring DI 주입 방법 (3가지)

스프링에서는 다음과 같은 방식으로 객체를 주입한다.

✔ (1) 생성자(Constructor) 주입 — ⭐가장 권장

@Component
public class Roel {

    private final Phone phone;

    @Autowired
    public Roel(Phone phone) {
        this.phone = phone;
    }
}

🔍 특징

• 불변(immutable) 의존성에 적합
• 스프링이 객체 만들 때 한 번만 호출되므로 안정적
• final로 선언 가능 → 값 변경 방지
• 필수 의존성 주입에 가장 적합
• 생성자가 하나라면 @Autowired 생략 가능

✔ 스프링 공식 권장 방식
✔ 반드시 필요하고 변경되면 안 되는 의존성에 적합
✔ 순환 참조를 애플리케이션 구동 시점에 잡아줌

✔ (2) Setter(수정자) 주입 — 선택적 의존성에 적합

@Component
public class Roel {

    private Phone phone;

    @Autowired
    public void setPhone(Phone phone) {
        this.phone = phone;
    }
}

🔍 특징

• 나중에 값 변경이 필요한 경우 사용
• 선택적(optional) 의존성에 적합
• 테스트나 일부 동적 상황에서 유용
• 단점: setter가 public 이어야 하고, 외부 변경 위험 존재

✔ (3) 필드(Field) 주입 — ❌ 비권장

@Component
public class Roel {

    @Autowired
    private Phone phone;
}

🔍 특징

• 가장 간편하지만 재사용성과 테스트성이 낮아 비권장
• DI 컨테이너 없이는 절대 동작하지 않음
• 순수 자바 코드로 테스트 불가
• 어떤 객체가 어떻게 주입되는지 코드만 보고 확인 어려움

⚠ 스프링 공식적으로 권장하지 않는 방식
(테스트 불가 + 유지보수 어려움)

📌 7. 왜 생성자 주입을 써야 할까?

✔ 1) 불변성 보장

• 객체 생성 시 단 한 번만 호출
• 이후 변경 불가능 → 안정적

✔ 2) 순환 참조를 구동 시점에 해결

Setter/필드 주입은 객체 생성 이후 주입되므로

순환 참조가 나중에 발생하는 반면,

생성자 주입은 애플리케이션 시작과 함께 에러를 즉시 감지한다.

✔ 3) 객체의 필수 의존성을 강제할 수 있음

필요한 의존성이 없으면 객체 생성 자체가 불가능하기 때문에

설계 오류를 예방할 수 있다.

📌 8. DI의 최종 핵심 정리

✔ 객체 간 의존성을 외부에서 주입받는 구조
✔ 강한 결합을 느슨한 결합으로 전환
✔ 유지보수성과 테스트 용이성 향상
✔ 생성자 주입이 가장 권장됨
✔ 인터페이스 기반 설계로 유연한 구조 가능

DI가 왜 중요한가?

DI는 단순히 “객체를 대신 넣어주는 기술”이 아니라, 스프링이 추구하는 설계 철학 전체를 지탱하는 핵심 원리다.

객체 간 결합을 최소화하면 시스템은 자연스럽게 더 유연해지고, 변경에 강해지고, 테스트가 쉬워진다.

이는 곧 개발 생산성 향상, 유지보수 비용 절감, 안정적인 서비스 운영으로 이어진다.

또한 DI는 인터페이스 기반 설계를 자연스럽게 유도하기 때문에, 애플리케이션 구조를 확장 가능하고 견고하게 만든다.

로직 변경, 기능 추가, 의존성 교체가 잦은 실제 개발 환경에서 DI는 개발자에게 변화에 흔들리지 않는 코드 기반을 제공한다.

결국 DI는 “스프링을 스프링답게 만드는 근본 개념”이며, 스프링을 활용하는 프로젝트에서 핵심 설계 중심축 역할을 한다.

🔹 Java란?

• 객체지향 프로그래밍 언어(OOP).
• “Write Once, Run Anywhere” 철학 → 한 번 작성하면 어떤 플랫폼에서도 실행 가능.
• 플랫폼 독립성(JVM 위에서 동작), 보안성, 자동 메모리 관리가 강점.

🔹 Java의 역사 요약

• 1995: Sun Microsystems에서 발표 (제임스 고슬링 주도 개발)
• 2006: Java 핵심 코드 오픈소스화
• 2010: Oracle이 Sun Microsystems 인수 → Java 관리 주체 변경
• 2018 이후: 6개월 주기의 정기 릴리즈 체계 도입

🔹 Java의 특징 핵심 정리

• 객체지향: 클래스 기반, 객체 중심
• 플랫폼 독립적: JVM 위에서 실행
• 자동 메모리 관리: Garbage Collection 지원
• 보안성 강함: 바이트코드 검증 및 안전한 실행 환경 제공
• 멀티스레드 지원: 효율적인 동시성 처리
• 풍부한 라이브러리: 표준 라이브러리 + 다양한 오픈소스 생태계
• 네트워크 친화적: 네트워크 기반 애플리케이션에 최적화
• 동적 로딩: 필요한 클래스를 동적으로 로딩해 효율 증가

Java 타입

Java의 변수 타입은 크게 기본형(Primitive Type) 과 참조형(Reference Type) 으로 나뉜다.

1) 기본형 타입 (Primitive Type)

🔹 정수형 상세

🔹 실수형 상세

🔹 문자형 / 논리형

2) 참조형 타입 (Reference Type)

종류

• array (배열)
• enum
• class
• interface

특징

• 인스턴스를 생성한 후 Heap 공간에 저장
• Stack에는 주소값(참조값)이 저장됨
• 참조형은 new 키워드를 통해 주로 생성됨

3) Stack 메모리 vs Heap 메모리

🔹 Stack 메모리

• 메서드 내부의 지역 변수 · 매개변수 저장
• 메서드 호출 시 생성, 종료 시 함께 제거
• 메모리 관리가 빠르고 단순함

🔹 Heap 메모리

• 객체 인스턴스 저장 공간
• Garbage Collector가 관리
• 메모리 관리가 복잡함

4) 값 저장 방식 요약

5) 기본 데이터 타입 선언 방식

int x;
int y = 3;

double pi, rate, avg;
double height = 180.5, weight = 75.0;

1. 연산자의 전체 종류

2. 산술 연산자 (Arithmetic Operators)

🔹 종류 및 의미

🔹 산술 연산자 특징

• 정수/정수 → 정수
• 실수 계산 시 주의 (1 / 1000.0 = 0.001)
• 나머지 연산은 정수형에 주로 사용
• 정수형 나눗셈은 소수점 이하 버림

🔹 예시

int intNum = 13;
double number = 1.1;

number + number → 2.2
intNum * 2 → 26

3. 나누기 & 곱하기 주의사항

• 정수 나누기 → 항상 정수
• 실수 나누기 → 실수
• 연산할 때 자료형에 따라 결과 타입이 결정됨
• float 타입 나눗셈 시 소수점 이하 오차 발생 가능
• overflow/underflow 여부 확인 필요

4. 자동 형변환 (Promotion)

🔹 작은 타입 → 큰 타입 자동 변환

byte → short → int → long → float → double

• 연산 시 피연산자 중 큰 자료형으로 자동 변환됨
• Object로 저장 후 .getClass().getName()으로 실제 타입 확인 가능

예:

short → java.lang.Short
long → java.lang.Long
double → java.lang.Double

5. 오버플로우 & 언더플로우

🔹 오버플로우(Overflow)

• 정수 범위를 초과할 때 발생
• 값이 최소값 또는 최대값으로 순환(wrap-around)

예:

int result = Integer.MAX_VALUE + 1;
→ -2147483648

🔹 언더플로우(Underflow)

• 표현 가능한 최소 실수 범위보다 더 작아서 0.0이 되는 현상
• float, double에서 발생

예:

1e-300 * 1e-300 → 0.0

6. 단항 연산자 (Unary Operators)

🔹 종류

🔹 예시

int i = 3;
i++; → 4
++i; → 5
--i; → 4

7. 관계 연산자 (Comparison Operators)

🔹 종류

🔹 예시

firstNumber = 10;
secondNumber = 20;

10 > 20 → false
(10 + 30) <= 20 → false
10 != 20 → true

8. 논리 연산자 (Logical Operators)

🔹 종류 및 설명

🔹 Short-Circuit(단락 평가)

• &&: 왼쪽이 false면 오른쪽 평가 안 함
• ||: 왼쪽이 true면 오른쪽 평가 안 함

예:

(num1 > num2) && (num1 < num2)

🔹 삼항 연산자 형태

조건식 ? 값1 : 값2

9. 비트 연산자 (Bitwise Operators)

🔹 비트란?

• 정수를 2진수 형태로 저장
• 메모리 최소 단위(0 또는 1)

예:

int bTemp = 21
0001 0101

🔹 비트 연산자 종류

10. 비트 연산자 (AND, OR)

비트 단위로 데이터를 처리하는 연산자.

특정 비트 정보를 추출하거나, ON/OFF 처리할 때 자주 사용.

🔹 AND 연산 (&)

• 두 비트 모두 1인 경우에만 1 반환
• 특정 비트만 추출할 때 사용

예)

0x15 & 0x04 → 0x04

🔹 OR 연산 (|)

• 두 비트 중 하나라도 1이면 1 반환
• 특정 비트를 켜고 싶을 때 사용

예)

0x15 | 0x02 → 0x17

11. 비트 연산자 예제 (AND, OR)

권한과 같은 플래그 값을 다룰 때 흔히 사용됨.

권한 정의 (예시)

• read : 1 (0b001)
• write : 2 (0b010)
• exec : 4 (0b100)

🔹 권한 추가 (OR)

userPermission |= readPermission;

🔹 권한 확인 (AND)

userPermission & readPermission

🔹 권한 제거 (AND + NOT)

userPermission &= ~readPermission;

12. 시프트 연산자 (<<, >>, >>>)

정수의 모든 비트를 왼쪽/오른쪽으로 이동시키는 연산자.

예)

0x80000039 << 3 → 0x000001C8

13. 시프트 연산 예제

🔹 암호화에 XOR 사용

encrypted = original ^ key
decrypted = encrypted ^ key

XOR은 (A ^ K) ^ K = A 의 성질을 이용하기 때문.

14. XOR 연산자 (^)

• 두 비트가 같으면 0
• 다르면 1
• 암호화나 비트 토글 등에 흔히 사용됨

예)

0x15 ^ 0x2C → 0x39

15. 비트 연산자 예제 (시프트 + XOR)

>> (부호 유지 시프트)

• 음수 유지됨

>>> (부호 없는 시프트)

• 앞자리를 0으로 채움 → 양수처럼 보임

<< (왼쪽 시프트)

• 4 << 3 = 32

16. 연산자 우선순위

여러 연산자가 함께 쓰이면, 우선순위가 높은 연산자부터 계산됨.

🔹 우선순위 표

🔹 예제 1

c = a + b * d;
// 곱셈이 더하기보다 우선 → b*d 먼저 계산

🔹 예제 2

(condition || false && false) → true

c = e & f ^ d;

• &가 ^보다 먼저 수행

17. 참조형 데이터 타입과 기본값

기본형과 다르게, 참조형 값은 주소를 저장하며 null 가능.

🔹 참조형 종류

• 클래스 (Class)
• 인터페이스 (Interface)
• 배열 (Array)
• 열거형 (Enum)

🔹 메모리 크기와 기본값

🔹 기본형과 참조형의 기본값 비교

LLM(거대 언어 모델) 자체는 '기억'이 없습니다(Stateless). 매번의 API 호출은 완전히 독립적입니다. "안녕"이라고 말한 뒤 "내 이름이 뭐야?"라고 물으면, LLM은 "안녕"이라는 이전 대화를 모르기 때문에 대답할 수 없습니다.

'기억'을 구현한다는 것은 "이전 대화 내용을 현재 프롬프트에 포함시켜서" LLM에게 '문맥(Context)'을 함께 전달하는 것을 의미합니다.

핵심 질문은 "이전 대화 중 어떤 것*을 *어떻게 프롬프트에 넣을 것인가?"입니다.

1. 기본 기억 방법: 프롬프트에 '연결'하기

가장 고전적이고 기본적인 방법입니다.

A. 전체 대화 내역 전달 (ConversationBufferMemory)

• 작동 방식: 사용자와 AI가 나눈 모든 대화 기록을 순서대로 프롬프트에 전부 집어넣습니다.

• 예시 프롬프트:

  Human: 안녕? AI: 안녕하세요! Human: 오늘 날씨 어때? AI: 서울은 맑습니다. Human: 어제 내가 뭐 물어봤는지 기억해? AI: ... (이제 LLM이 '오늘 날씨'를 물어본 것을 보고 대답함)

• 장점: 완벽한 기억력.

• 단점: 대화가 길어지면 프롬프트가 컨텍스트 창(Context Window) 한계 (예: 4K, 32K 토큰)를 초과하고, API 비용이 폭발적으로 증가합니다.

예시 코드

from langchain.chains import ConversationChain
from langchain.memory import ConversationBufferMemory

# 메모리 포함 체인 생성
memory = ConversationBufferMemory()
chain = ConversationChain(llm = llm, memory=memory)

# 대화 시작
print(chain.run("안녕? 나는 기영이야.")) # 기영아 안녕
print(chain.run("내 이름이 뭐라고?")) # 너의 이름은 기영이야.

B. 최근 대화만 전달 (ConversationBufferWindowMemory)

• 작동 방식: A의 단점을 보완. 전체 대화가 아닌, 최근 k개의 대화만 잘라서 프롬프트에 넣습니다. (예: 최근 5번의 턴)
• 장점: 토큰 한계와 비용 문제를 조절할 수 있습니다.
• 단점: k개 이전의 중요한 정보(예: "내 이름은 OOO이야")를 잊어버립니다.

예시 코드

from langchain.memory import ConversationBufferWindowMemory

# 최근 2턴만 기억하는 메모리
memory = ConversationBufferWindowMemory(k=2)
chain = ConversationChain(llm=llm, memory=memory)

# 대화
print(chain.run("나는 기영이야."))
memory.load_memory_variables({})

print(chain.run("내가 좋아하는 색은 파란색이야."))
memory.load_memory_variables({})

print(chain.run("나는 영화보는 것을 좋아해"))
memory.load_memory_variables({})

print(chain.run("지금 배고픈데 뭘 먹을까?"))
memory.load_memory_variables({})

print(chain.run("내가 누구라고?")) # 누군지 기억못함.
memory.load_memory_variables({})

C. 대화 요약본 전달 (ConversationSummaryMemory)

• 작동 방식: 대화가 진행될 때마다, LLM을 이용해 이전 대화 내용을 요약합니다. 그리고 새 질문과 함께 '요약본'을 프롬프트에 넣습니다.
• 장점: 긴 대화도 압축해서 기억할 수 있습니다.
• 단점: 요약 과정에서 세부 정보가 손실될 수 있고, 요약을 위한 추가 LLM 호출 비용이 듭니다.

예시 코드

from langchain.memory import ConversationSummaryMemory

# 요약 메모리 생성 (요약용 LLM 필요)
memory = ConversationSummaryMemory(llm = llm)

# 체인 구성
chain = ConversationChain(llm = llm, memory = memory)

# 대화
print(chain.run("오늘은 운동하고, 친구랑 밥도 먹고, 강의도 들었어."))
print(chain.run("내가 오늘 뭐했는지 기억나?"))
print(chain.run("너는 어떻게 지냈어?"))
# 담긴 메모리 확인하기
memory.chat_memory.messages
# 내용 요약
print(memory.buffer)

요약

2. 고급 기억 방법: RAG (검색) 기반 기억

최근 가장 많이 사용되는 방식이며, RAG(검색 증강 생성)의 원리를 대화 기억에 적용한 것입니다.

RAG 기반 기억 (VectorStore-backed Memory)

• 작동 방식:
  1. 모든 대화(Human/AI)를 Vector DB (예: Chroma)에 실시간으로 저장(임베딩)합니다.
  2. 사용자가 새 질문을 하면, 그 질문과 '가장 관련성 높은' 과거 대화 조각들을 DB에서 검색(Search)합니다.
  3. 프롬프트에 [최근 k개 대화] + [검색된 관련 과거 대화] + [새 질문]을 넣어 LLM에 전달합니다.
• 장점:
  • 장기 기억: 대화가 아무리 길어져도 상관없습니다.
  • 관련성: "3주 전에 말했던 내 프로젝트 이름 뭐야?" 같은 질문에도 3주 전의 관련 기록을 찾아와 대답할 수 있습니다.
  • 효율성: 토큰 한계를 걱정할 필요가 없습니다.
• 단점: 구현이 다소 복잡하고, Vector DB가 필요합니다.

예시 코드

from langchain.vectorstores import Chroma

# split_texts, embedding_model 정의 
...

# ChromaDB를 만들면서 저장
vectorstore = Chroma.from_texts(split_texts, embedding_model, persist_directory="./chroma_db")

query = "농촌 계몽운동에 대한 내용"
retrieved_docs = vectorstore.similarity_search(query, k=3)

# 결과 출력
print("검색 결과:")
for doc in retrieved_docs:
    print(doc.page_content)
    print('-'*200)

💡 Chroma vs. FAISS: 간단 비교

둘 다 벡터를 저장하고 검색하는 핵심 역할을 하지만, 지향점이 약간 다릅니다.

• Chroma (ChromaDB):
  • *"데이터베이스 (Database)"**에 가깝습니다.
  • 벡터뿐만 아니라 메타데이터(문서 출처, 시간 등) 저장 및 필터링 기능을 기본으로 제공합니다.
  • 데이터 저장, 관리, API 제공 등 RAG에 필요한 기능이 잘 갖춰져 있어 개발 및 프로토타이핑이 매우 편리합니다.
  • LangChain, LlamaIndex 등과 통합이 쉽습니다.
• FAISS (Facebook AI Similarity Search):
  • *"검색 라이브러리 (Library)"**에 가깝습니다.
  • Meta(페이스북)에서 개발했으며, 오직 매우 빠르고 효율적인 벡터 검색(유사도 검색) 자체에만 초점을 맞춥니다.
  • 수십억 개 단위의 초대규모 벡터를 처리할 때 최고의 성능을 보입니다.
  • 하지만 FAISS 자체는 데이터를 영구 저장(persistence)하거나 메타데이터를 관리하는 기능을 직접 제공하지 않습니다. (사용자가 직접 파일로 저장/로드하거나, 다른 DB와 조합해서 써야 함)

예시 코드

from langchain.vectorstores import FAISS

# split_docs, embedding_model 정의 
...

vectorstore = FAISS.from_documents(split_docs, embedding_model)
vectorstore.save_local("faiss_index")  # 'faiss_index' 폴더에 저장됨

# 저장된 벡터DB를 로딩하기
new_vectorstore = FAISS.load_local(
    "faiss_index",
    embedding_model,
    allow_dangerous_deserialization=True
)

new_docs = [
    Document(page_content="조선시대의 교육 제도는 성균관 중심이었다.", metadata={"source": "추가"}),
    Document(page_content="한국 전통 사회에서 글을 읽는 능력은 권력의 상징이었다.", metadata={"source": "추가"})
]

# 문서 추가
vectorstore.add_documents(new_docs)

요약

3. 상태 저장소: MemorySaver의 역할

사용자님이 언급하신 from langgraph.checkpoint.memory import MemorySaver는 위 1, 2번과는 약간 다른 차원의 이야기입니다.

MemorySaver는 "기억을 프롬프트로 만드는 방법"이 아니라, "대화의 상태(State)를 어디에 저장(Persistence)할 것인가"에 대한 도구입니다.

• MemorySaver (인메모리): 가장 기본. 대화 기록을 그냥 RAM(메모리)에 저장합니다. 챗봇 서버가 재시작되면 모든 대화 기록이 사라집니다. (테스트용)
• RedisSaver / PostgresSaver 등: 대화 기록을 외부 DB(Redis, Postgres 등)에 저장합니다.

LangGraph 같은 에이전트 프레임워크에서 MemorySaver는 단순히 채팅 기록뿐만 아니라, 에이전트의 현재 작업 상태(State) 전체(예: 'A' 작업 완료, 'B' 작업 대기 중)를 저장하는 '체크포인터(Checkpointer)' 역할을 합니다.

📈 요즘 대세는?

• "RAG 기반 기억 (VectorStore) + 상태 저장소 (DB Checkpointer)"의 조합입니다.

1. 단기 기억 (Window): 최근 3~5개의 대화는 프롬프트에 항상 포함시킵니다. (가장 즉각적인 문맥)
2. 장기 기억 (RAG): 사용자의 질문과 관련성 높은 과거 대화 기록을 Vector DB에서 검색하여 프롬프트에 추가합니다.
3. 대화 저장 (Persistence): 이 모든 대화 기록과 에이전트의 상태는 MemorySaver (혹은 LangChain의 ChatMessageHistory 인터페이스)를 통해 Redis나 Postgres 같은 외부 DB에 영구 저장합니다.

결론

단순한 챗봇은 '최근 대화만 기억(Window)'하는 방식을, 고급 챗봇이나 에이전트는 'RAG(검색)로 장기 기억'을 구현하고, LangGraph를 쓴다면 MemorySaver를 이용해 이 모든 상태를 'DB에 저장'하는 것이 현재의 표준 방식입니다.

1. 데이터 스케일링 (Scaling) 3대장

데이터를 모델에 학습시키기 전, 피처들의 단위를 맞춰주는 전처리 과정입니다. 왜 할까요? 만약 '키(cm)'와 '나이(세)'를 함께 사용한다면, '키'의 숫자 범위가 훨씬 커서 모델이 '키' 피처를 더 중요하다고 잘못 판단할 수 있기 때문입니다.

1) StandardScaler (표준화)

• 개념: 가장 널리 쓰이는 스케일러입니다. 각 피처의 평균(Mean)을 0, 표준편차(Standard Deviation)를 1로 변환합니다. (이를 Z-점수 정규화라고도 합니다.)
• 특징:
  • 데이터가 정규분포(가우시안 분포)를 따른다고 가정할 때 효과가 좋습니다.
  • 아웃라이어(이상치)에 민감하게 반응할 수 있습니다.
• 언제 쓸까?
  • 대부분의 머신러닝 모델(특히 선형 회귀, 로지스틱 회귀, SVM 등)의 기본 스케일러로 사용하기 좋습니다.
  • 데이터가 정규분포에 가까울 때.

from sklearn.preprocessing import StandardScaler

# 1. 스케일러 객체 생성
scaler_std = StandardScaler()

# 2. 데이터에 맞게 '학습(fit)'하고 '변환(transform)'
X_scaled_std = scaler_std.fit_transform(X)

print("StandardScaler 변환 결과:\n", X_scaled_std)

2) MinMaxScaler (정규화)

• 개념: 모든 피처 값을 0과 1 사이의 값으로 압축시킵니다. (최솟값은 0, 최댓값은 1이 됩니다.)
• 특징:
  • StandardScaler와 달리 아웃라이어(이상치)에 매우 민감합니다. 예를 들어 [1, 2, 3, 100]이 있다면, 1, 2, 3은 0에 가깝게, 100은 1에 가깝게 매핑되어 버립니다.
• 언제 쓸까?
  • 이미지 데이터(픽셀 값이 0255 범위일 때)를 01 사이로 변환할 때.
  • 데이터의 범위가 명확하게 정해져 있을 때.
  • 주의: 아웃라이어가 있다면 사용에 유의해야 합니다.

from sklearn.preprocessing import MinMaxScaler

# 1. 스케일러 객체 생성
scaler_mms = MinMaxScaler()

# 2. 데이터에 맞게 '학습(fit)'하고 '변환(transform)'
X_scaled_mms = scaler_mms.fit_transform(X)

print("MinMaxScaler 변환 결과:\n", X_scaled_mms)

3) RobustScaler (로버스트 스케일링)

• 개념: 이름(Robust)처럼 아웃라이어에 강건한 스케일러입니다. 평균/표준편차 대신 중앙값(Median)과 사분위 범위(IQR)를 사용합니다.
• 특징:
  • 아웃라이어의 영향을 거의 받지 않고 데이터의 분포를 스케일링합니다.
• 언제 쓸까?
  • 데이터에 아웃라이어(이상치)가 많다고 판단될 때 가장 우선적으로 고려합니다.

from sklearn.preprocessing import RobustScaler

# 1. 스케일러 객체 생성
scaler_rs = RobustScaler()

# 2. 데이터에 맞게 '학습(fit)'하고 '변환(transform)'
X_scaled_rs = scaler_rs.fit_transform(X)

print("RobustScaler 변환 결과:\n", X_scaled_rs)

정리

2. 예측의 두 갈래: 회귀 vs. 분류

머신러닝(지도학습)은 크게 '회귀'와 '분류'로 나뉩니다.

• 회귀 (Regression): 연속적인 값(숫자)을 예측하는 문제입니다. ◦ 예: 내일의 기온(25.5℃), 3년 뒤 집값(5억 3천만 원), 주가 예측
• 분류 (Classification / 식별): 정해진 카테고리(범주) 중 하나로 예측하는 문제입니다.
  • 예: 이 메일은 스팸인가/아닌가? (이진 분류), 이 사진은 개인가/고양이인가/기타인가? (다중 분류)

3. 주요 회귀(Regression) 모델

1) 선형 회귀 (Linear Regression)

• 개념: 가장 기본적이고 단순한 회귀 모델입니다. 데이터 간의 직선 관계($y = wx + b$)를 찾아내어 값을 예측합니다.

• 언제 쓸까?
  • 데이터가 선형적인 관계(x가 증가할 때 y도 증가/감소)를 보일 때.
  • 모델의 해석이 매우 중요할 때 (어떤 피처가 결과에 얼마나 영향을 주는지 명확히 보임).

from sklearn.linear_model import LinearRegression

model_lr = LinearRegression()

model_lr.fit(X_train, y_train)

2) 로지스틱 회귀 (Logistic Regression)

• 개념: 이름은 '회귀'지만, 실제로는 '분류' 모델입니다.
  • 선형 회귀처럼 직선을 찾지만, 그 결과를 시그모이드(Sigmoid) 함수에 통과시켜 0과 1 사이의 '확률' 값으로 변환합니다.

💡 보통 0.5를 기준으로 0.5보다 크면 1 (True), 작으면 0 (False)으로 분류합니다.

• 언제 쓸까?
  • 이진 분류(Binary Classification) 문제(예: 합격/불합격, 생존/사망)의 기본 모델로 널리 쓰입니다.
  • 성능도 준수하고, 선형 회귀처럼 해석력이 좋습니다.

from sklearn.linear_model import LogisticRegression

model_lr = LogisticRegression()

model_lr.fit(X_train, y_train)

1) DecisionTree (결정 트리)

• 개념: 데이터를 '스무고개' 하듯이 'If-Then' 규칙으로 쪼개나가며 예측하는 모델입니다.

• 특징:

  • 장점: 모델의 예측 과정을 눈으로 쉽게 확인할 수 있어 해석력(Explainability)이 매우 높습니다.
  • 단점: 트리를 너무 깊게 만들면 과적합(Overfitting)되기 매우 쉽습니다. (데이터의 사소한 노이즈까지 다 학습해버림)

from sklearn.tree import DecisionTreeClassifier

model_dt = DecisionTreeClassifier(max_depth=10, random_state=42)

model_dt.fit(X_train_scaled, y_train)

2) RandomForest (랜덤 포레스트)

• 개념: '과적합되기 쉽다'는 결정 트리의 단점을 보완한 모델입니다. 앙상블(Ensemble) 기법 중 배깅(Bagging)을 사용합니다.
  • 작동 방식:
    1. 데이터를 무작위로 샘플링하여(중복 허용) 여러 개의 작은 데이터셋을 만듭니다.
    2. 각 데이터셋으로 여러 개의 결정 트리를 만듭니다. (이때 피처도 무작위로 선택)
    3. 최종 예측 시, 이 모든 트리의 결과를 '다수결 투표'(Voting)하여 결정합니다. (회귀는 '평균')
• 언제 쓸까?
  • 결정 트리보다 훨씬 성능이 좋고 과적합에도 강합니다.
  • 특별한 튜닝 없이도 준수한 성능을 내는 범용적인 모델로 쓰기 좋습니다.

from sklearn.ensemble import RandomForestClassifier

model_rf = RandomForestClassifier(n_estimators=100, random_state=42)

model_rf.fit(X_train_scaled, y_train)

3) XGBoost (eXtreme Gradient Boosting)

• 개념: 캐글(Kaggle) 같은 데이터 경진대회를 휩쓸었던 고성능 모델입니다. 앙상블 기법 중 부스팅(Boosting)을 사용합니다.
• 작동 방식 (vs. 랜덤 포레스트):
  • 랜덤 포레스트는 여러 트리를 '동시에' 만들고 투표합니다. (병렬적)
  • 부스팅은 트리를 '순차적으로' 만듭니다.
    1. 첫 번째 트리를 만듭니다.
    2. 첫 번째 트리가 틀린 문제(오차)에 대해 가중치를 줍니다.
    3. 두 번째 트리는 이 틀린 문제를 더 잘 맞히는 방향으로 학습합니다.
    4. 이 과정을 반복하며 점점 모델을 강력하게 '부스팅'합니다.
• 언제 쓸까?
  • 높은 예측 정확도가 필요할 때. (특히 정형 데이터에서 최고 수준의 성능을 보임)
  • 병렬 처리를 지원하여 학습 속도가 빠릅니다.

from xgboost import XGBClassifier

model_xgb = XGBClassifier(n_estimators=5, random_state=42)

model_xgb.fit(X_train_scaled, y_train)

4) LightGBM (Light Gradient Boosting Machine)

• 개념: XGBoost와 마찬가지로 부스팅(Boosting) 계열의 모델입니다. (MS에서 개발)
• 특징 (vs. XGBoost):
  • XGBoost보다 학습 속도가 더 빠르고 메모리 사용량이 적습니다.
  • 트리를 성장시키는 방식(Leaf-wise)이 달라서 속도 이점을 가집니다.
• 언제 쓸까?
  • 대용량 데이터를 다룰 때 XGBoost보다 유리합니다.
  • 빠른 학습 속도와 높은 정확도를 동시에 잡고 싶을 때.

from lightgbm import LGBMClassifier

model_lgbm = LGBMClassifier(n_estimators=3, random_state=42)

model_lgbm.fit(X_train_scaled, y_train)

이 패턴은 제가 아까 설명드린 모든 트리 기반 모델에 동일하게 적용됩니다:

트리 기반 모델 계보

트리 모델 구조 요약

DecisionTree  →  RandomForest  →       XGBoost       →      LightGBM
  (단일 트리)      (다수 트리 병렬)     (부스팅, 순차적 개선)     (부스팅 + 속도최적화)

마치며

AICE 시험 준비에 이 정리 내용이 도움이 되길 바랍니다!

• 스케일러: 아웃라이어 유무(Robust)와 데이터 범위(MinMax)를 기준으로 선택! (기본은 Standard)
• 회귀/분류: 연속된 값이면 '회귀', 카테고리면 '분류'! (단, 로지스틱 회귀는 분류 모델!)
• 트리 모델:
  • 해석이 필요하면 DecisionTree.
  • 범용적으로 쓰기 좋으면 RandomForest.
  • 최고 성능과 속도가 필요하면 XGBoost 또는 LightGBM.

PhotoCalendar는 Kotlin 기반의 오픈소스 캘린더 라이브러리로, 날짜 및 일정 관리를 위한 다양한 기능을 제공한다. 기존 코드베이스는 java.util.time을 사용하고 있었지만, 특정 버전에서는 호환되지 않는 문제가 발생했기에 kotlinx.datetime으로 마이그레이션하는 작업을 진행했다.

🛠 해결 방안

기존 java.util.time 를 kotlinx.datetime으로 대체하기 위해 주요 변경 사항은 다음과 같다.

1️⃣ LocalDate.now() 대체

java.util.time의 LocalDate.now()를 대체하기 위해 Clock.System.now()와 TimeZone.currentSystemDefault()를 활용하여 현재 날짜를 가져오는 확장 함수를 구현했다.

fun LocalDate.Companion.now(): LocalDate {
    return Clock.System.now()
        .toLocalDateTime(TimeZone.currentSystemDefault())
        .date
}

2️⃣ YearMonth 대체: 커스텀 DateYearMonth 클래스 구현

기존 java.util.time.YearMonth를 kotlinx.datetime에서 제공하지 않기 때문에 커스텀 데이터 클래스 DateYearMonth를 생성하여 연-월을 다룰 수 있도록 했다.

data class DateYearMonth(val year: Int, val month: Int)

이를 통해 YearMonth와 동일한 기능을 제공하며, 연-월 연산을 수행할 수 있도록 확장했다.

3️⃣ 확장 함수 구현

java.util.time에서 제공하던 주요 기능들을 유지하기 위해 확장 함수를 활용하여 대체했다.

예를 들어, 특정 요일을 기준으로 날짜를 계산하는 previousOrSame(target: DayOfWeek) 함수와, DateYearMonth 객체에서 월을 더하는 plusMonths(months: Int) 함수를 직접 구현했다.

internal fun LocalDate.previousOrSame(target: DayOfWeek): LocalDate { ... }
internal fun DateYearMonth.plusMonths(months: Int): DateYearMonth { ... }

해당 PR 링크

🎯 적용 결과

kotlinx.datetime을 사용하여 Kotlin 멀티플랫폼 지원 강화 java.util.time 종속성을 제거하고, 보다 가볍고 효율적인 날짜 처리 가능 기존 기능을 유지하면서, Kotlin 스타일에 맞는 API로 개선

🔗 마무리

앞으로도 Kotlin 생태계에 맞춰 개선을 진행할 계획이며, PhotoCalendar 오픈소스에 기여할 수 있어 뜻깊은 경험이었다.

참고

PhotoCalendar Repo

Preview가 길어진 이유

버튼 컴포넌트를 만들고, 피그마 디자인에 있는 모든 버튼 스타일을 Preview로 확인할 수 있도록 코드를 작성하다 보니 Preview 코드가 점점 길어지기 시작했습니다.

PR을 올릴 때는 리뷰어분들께 "버튼 컴포넌트에 Preview가 많아 코드가 길 수 있다" 는 메시지를 남겨야 할 정도였죠.

하지만 코드 리뷰 중 한 리뷰어분께서 PreviewParameter라는 유용한 기능을 알려주셨고, 이를 활용해 코드 길이를 획기적으로 줄일 수 있었습니다.

PreviewParameter를 활용한 코드 간소화

Compose의 PreviewParameter는 Preview를 위한 매개변수를 제공하는 기능입니다. 이를 활용하면 같은 컴포넌트를 다양한 상태로 Preview할 때 반복되는 코드를 줄일 수 있습니다.

컴포저블 미리보기로 UI 미리보기  |  Jetpack Compose  |  Android Developers

PreviewParameterProvider 정의

먼저, Preview에 사용될 버튼 스타일을 정의하는 PreviewParameterProvider를 생성합니다.

여기서 각 버튼 스타일을 제공하는 ButtonStyleProvider를 작성했어요.

private class ButtonStyleProvider : PreviewParameterProvider<ButtonStyle> {
    override val values: Sequence<ButtonStyle> = sequenceOf(
        ButtonStyle.Primary,
        ButtonStyle.Secondary,
        ButtonStyle.Tertiary
    )
}

제가 작성한 예시 코드를 보며 설명할게요!

1. PreviewParameterProvider 를 통한 ButtonStyleProvider 클래스 정의

먼저, ButtonStyleProvider는 Preview에 전달할 값을 관리하는 클래스입니다. 이 클래스는 PreviewParameterProvider<T>를 상속받아 values 속성을 통해 Preview에서 사용할 매개변수의 목록을 제공합니다.

private class ButtonStyleProvider : PreviewParameterProvider<ButtonStyle> {
    override val values: Sequence<ButtonStyle> = sequenceOf(
        ButtonStyle.Primary,
        ButtonStyle.Secondary,
        ButtonStyle.Tertiary
    )
}

• PreviewParameterProvider<T>: Preview에 전달할 데이터 타입 T를 명시합니다. 여기서는 ButtonStyle 타입을 사용합니다.
• values: Sequence 타입으로 Preview에서 사용할 여러 값을 정의합니다.
  • sequenceOf()를 사용해 필요한 버튼 스타일들을 나열했습니다.
  • 여기서는 ButtonStyle.Primary, ButtonStyle.Secondary, ButtonStyle.Tertiary 세 가지 스타일을 제공합니다.

2. PreviewParameter 애노테이션 사용

이제 ButtonStyleProvider를 활용해 Preview 함수에서 다양한 스타일을 미리 볼 수 있습니다.

기본 사용법

@PreviewParameter 애노테이션을 사용해, Preview 함수의 매개변수로 데이터를 전달받을 수 있습니다.

@Preview
@Composable
fun SpoonyButtonEnabledPreview(
    @PreviewParameter(ButtonStyleProvider::class) style: ButtonStyle
) {
    SpoonyAndroidTheme {
        Column(
            modifier = Modifier.fillMaxWidth(),
            verticalArrangement = Arrangement.spacedBy(16.dp)
        ) {
            // 여기서 전달받은 style을 사용
            ButtonSize.entries.forEach { size ->
                SpoonyButton(
                    text = "버튼",
                    style = style, // 전달받은 style
                    size = size,   // 반복문으로 모든 크기 처리
                    onClick = { }
                )
            }
        }
    }
}

동작 방식

1. 매개변수 style에 값 전달:
   • @PreviewParameter(ButtonStyleProvider::class)는 ButtonStyleProvider에서 정의한 values를 순회하면서 Preview를 생성합니다.
   • values에서 제공된 각 ButtonStyle(Primary, Secondary, Tertiary)에 대해 별도의 Preview 화면이 렌더링됩니다.
2. Preview 생성:
   • Compose는 각 ButtonStyle에 대해 한 번씩 Preview를 생성하여, 동일한 UI를 다양한 스타일로 확인할 수 있도록 합니다.

Preview의 결과

위 코드를 사용하면 버튼 스타일(Primary, Secondary, Tertiary) 각각에 대해 Preview 화면이 따로 생성됩니다. 결과적으로, 스타일별 Preview를 작성할 때 중복된 코드를 작성할 필요가 없어집니다.

코드 변경 전

기존에는 버튼 스타일과 크기별로 Preview를 모두 작성했기 때문에 코드가 아래처럼 길어졌습니다.

@Preview
@Composable
private fun SpoonyButtonPrimaryEnabledPreview() {
    SpoonyAndroidTheme {
        Column(
            modifier = Modifier.fillMaxWidth(),
            verticalArrangement = Arrangement.spacedBy(16.dp)
        ) {
            SpoonyButton(
                text = "버튼",
                onClick = {},
                style = ButtonStyle.Primary,
                size = ButtonSize.Xlarge
            )
            SpoonyButton(
                text = "버튼",
                onClick = {},
                style = ButtonStyle.Primary,
                size = ButtonSize.Large
            )
            SpoonyButton(
                text = "버튼",
                onClick = {},
                style = ButtonStyle.Primary,
                size = ButtonSize.Medium
            )
            SpoonyButton(
                text = "버튼",
                onClick = {},
                style = ButtonStyle.Primary,
                size = ButtonSize.Small
            )
            SpoonyButton(
                text = "버튼",
                onClick = {},
                style = ButtonStyle.Primary,
                size = ButtonSize.Xsmall
            )
        }
    }
}

@Preview
@Composable
private fun SpoonyButtonPrimaryDisabledPreview() {
    SpoonyAndroidTheme {
        Column(
            modifier = Modifier.fillMaxWidth(),
            verticalArrangement = Arrangement.spacedBy(16.dp)
        ) {
            SpoonyButton(
                text = "버튼",
                style = ButtonStyle.Primary,
                size = ButtonSize.Xlarge,
                enabled = false
            )
            SpoonyButton(
                text = "버튼",
                style = ButtonStyle.Primary,
                size = ButtonSize.Large,
                enabled = false
            )
            SpoonyButton(
                text = "버튼",
                style = ButtonStyle.Primary,
                size = ButtonSize.Medium,
                enabled = false
            )
            SpoonyButton(
                text = "버튼",
                style = ButtonStyle.Primary,
                size = ButtonSize.Small,
                enabled = false
            )
            SpoonyButton(
                text = "버튼",
                style = ButtonStyle.Primary,
                size = ButtonSize.Xsmall,
                enabled = false
            )
        }
    }
}
...

코드 변경 후

PreviewParameter를 사용해 스타일을 매개변수로 전달받도록 개선했습니다.

버튼 크기별로도 반복문을 활용해 코드의 중복을 줄였어요.

@Preview
@Composable
fun SpoonyButtonEnabledPreview(
    @PreviewParameter(ButtonStyleProvider::class) style: ButtonStyle
) {
    SpoonyAndroidTheme {
        Column(
            modifier = Modifier,
            verticalArrangement = Arrangement.spacedBy(16.dp)
        ) {
            ButtonSize.entries.forEach { size ->
                SpoonyButton(
                    text = "버튼",
                    style = style,
                    size = size,
                    onClick = { }
                )
            }
        }
    }
}

코드 커밋 후 코드 줄 수 변화

위와 같이 코드를 수정하니 Preview가 훨씬 간결해졌습니다. 버튼 스타일과 크기별 Preview를 하나의 함수로 처리할 수 있어 유지보수도 편리해졌고, 코드 가독성도 크게 향상되었죠.

저는 해당 리뷰를 통해 PreviewParameter라는 기능을 알게 된 것도 큰 수확이었습니다.

Preview가 너무 길어져 고민 중이라면, 저처럼 PreviewParameter를 활용해보는 건 어떨까요? 코드가 훨씬 깔끔해질 거예요! 😊

문제 상황

기존 코드는 다음과 같은 방식으로, 기기에 런처 아이콘이 있는 앱들을 전부 조회(queryIntentActivities)한 뒤, 결과 목록이 비어 있으면 “네이버 지도 설치 필요”로 판단하여 마켓으로 이동하고, 그렇지 않으면 “네이버 지도 실행”을 시도했습니다.

val installCheck = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
    context.packageManager.queryIntentActivities(
        Intent(Intent.ACTION_MAIN, null).addCategory(Intent.CATEGORY_LAUNCHER),
        PackageManager.ResolveInfoFlags.of(PackageManager.MATCH_DEFAULT_ONLY.toLong())
    )
} else {
    context.packageManager.queryIntentActivities(
        Intent(Intent.ACTION_MAIN, null).addCategory(Intent.CATEGORY_LAUNCHER),
        PackageManager.GET_META_DATA
    )
}

if (installCheck.isEmpty()) {
    // 네이버 지도 없다고 판단 → 플레이스토어
} else {
    // 네이버 지도 있다고 판단 → 인텐트 실행
}

문제는 실제로 네이버 지도 앱이 삭제되었는데도 installCheck 결과가 비어 있지 않은 경우가 발생한다는 점이었습니다. 예를 들어, 런처에 존재하는 다른 앱들(카메라, 갤러리 등)이 목록에 남아서 “목록이 비어 있지 않다”고 판단되어, 실제로는 네이버 지도가 없는데도 네이버 지도 인텐트를 실행하려고 시도하면서 앱이 강제 종료되는 이슈가 생겼습니다.

해결 방법

문제를 근본적으로 해결하기 위해, 특정 패키지(네이버 지도)가 존재하는지를 직접 확인하도록 코드를 수정했습니다.

안드로이드에서는 특정 패키지가 설치되어 있는지 판단하려면 PackageManager.getPackageInfo (또는 안드로이드 13 이상의 getPackageInfo(packageName, PackageManager.PackageInfoFlags))를 사용하는 것이 가장 간단하다고하여 사용했습니다.

수정된 코드

private fun openPlaceNaverMap(
    latitude: Double,
    longitude: Double,
    placeName: String,
    context: Context
) {
    val url = "nmap://place?lat=$latitude&lng=$longitude&name=$placeName&appname=${context.packageName}"
    val intent = Intent(Intent.ACTION_VIEW, Uri.parse(url)).apply {
        addCategory(Intent.CATEGORY_BROWSABLE)
    }

    // 1) "com.nhn.android.nmap" 패키지 존재 여부 확인
    val isInstalled = try {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            context.packageManager.getPackageInfo(
                "com.nhn.android.nmap",
                PackageManager.PackageInfoFlags.of(0)
            )
        } else {
            @Suppress("DEPRECATION")
            context.packageManager.getPackageInfo("com.nhn.android.nmap", 0)
        }
        true
    } catch (e: PackageManager.NameNotFoundException) {
        false
    }

    // 2) 설치되어 있지 않다면 → Play 스토어로 이동
    if (!isInstalled) {
        val marketIntent = Intent(Intent.ACTION_VIEW).apply {
            data = Uri.parse("market://details?id=com.nhn.android.nmap")
        }
        context.startActivity(marketIntent)
    } else {
        // 3) 설치되어 있다면 → 네이버 지도 앱 실행
        context.startActivity(intent)
    }
}

try 구문 안에서 getPackageInfo("com.nhn.android.nmap", 0)를 호출했을 때 NameNotFoundException이 발생하지 않으면(= 앱이 존재) true, 예외가 발생하면(= 앱이 설치되지 않음) false를 반환합니다. 그 결과에 따라 Play 스토어로 이동할지, 네이버 지도 앱을 실행할지를 나눠 처리할 수 있습니다.

핵심 흐름

네이버 지도 스킴(nmap://place)으로 장소 정보를 담은 Intent를 준비한다. getPackageInfo로 네이버 지도 패키지(com.nhn.android.nmap)의 설치 여부를 판단한다. 설치되어 있다면 → 해당 Intent를 통해 네이버 지도 앱을 실행한다. 설치되어 있지 않다면 → Play 스토어(또는 마켓)으로 이동하여 앱 설치를 유도한다.

요약

문제 원인

queryIntentActivities는 런처 아이콘이 있는 모든 앱을 가져오는 로직이므로, 앱이 “삭제”되었음에도 다른 앱들로 인해 리스트가 비어있지 않아 오탐 발생.

해결 방법

특정 패키지명(com.nhn.android.nmap)을 직접 getPackageInfo로 조회하여, 앱 설치 여부를 정확히 판단.

핵심 포인트

“런처 아이콘 조회” 대신 “패키지명 조회” 를 통해, 네이버 지도 존재 여부를 명확히 체크해야 한다. 이렇게 코드를 바꾸면, 실제로 네이버 지도 앱이 삭제된 경우에는 즉시 예외가 발생해 “앱이 없다”고 올바르게 판단하며, 강제 종료 없이 플레이스토어로 안전하게 이동할 수 있습니다.

이 방법은 네이버 지도뿐 아니라 특정 패키지가 설치되어 있는지 확인할 때도 동일하게 사용할 수 있어, 스킴 호출 전에 반드시 앱 설치 여부를 체크해야 하는 로직에 유용합니다.

abstract class에는 @Binds 어노테이션이,

object에는 @Provides 키워드가 붙게 되는데 어떤 이유에서인지 알아보겠습니다.

작성한 예시 코드를 보여드리며 설명하겠습니다.

1. DataModule (@Binds 사용)

@Module
@InstallIn(SingletonComponent::class)
abstract class DataModule {

    @Binds
    abstract fun bindsDataStoreDataSource(
        dataStoreDataSource: DataStoreDataSourceImpl
    ): DataStoreDataSource

    @Binds
    abstract fun bindsDataStoreRepository(
        dataStoreRepository: DataStoreRepositoryImpl
    ): DataStoreRepository

    @Binds
    abstract fun bindsUserDataSource(
        authDataSource: UserDataSourceImpl
    ): UserDataSource

    @Binds
    abstract fun bindsUserRepository(
        authRepository: UserRepositoryImpl
    ): UserRepository
    ...
}

설명

• @Binds는 인터페이스와 구현체 간의 관계를 바인딩하기 위해 사용됩니다.
• 위 코드에서 DataStoreDataSource, DataStoreRepository, UserDataSource, UserRepository는 인터페이스, 그리고 DataStoreDataSourceImpl, DataStoreRepositoryImpl, UserDataSourceImpl, UserRepositoryImpl는 구현체입니다.
• 추상 메서드를 통해, Hilt는 자동으로 인터페이스의 구현체를 의존성 주입에 사용할 수 있도록 설정합니다.

특징

1. 단순한 인터페이스-구현체 바인딩:
   • 인터페이스와 구현체만 연결하면 되므로 객체 생성 로직이 필요하지 않습니다.
   • Hilt가 직접 생성자를 호출해 필요한 객체를 생성합니다.
2. 효율적:
   • 구현체의 기본 생성자가 있거나, 생성자 주입(@Inject)을 이미 정의한 경우 사용할 수 있습니다.
3. 추상 클래스만 허용:
   • @Binds를 사용하는 모듈은 반드시 abstract 키워드를 사용해야 합니다.

장점

• 코드가 간결하며, 불필요한 생성 로직이 없습니다.
• 성능적으로 더 효율적입니다.

2. NetworkModule (@Provides 사용)

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

    @Provides
    @Singleton
    fun providesOkHttpClient(
        @ApplicationContext context: Context,
        tokenProvider: () -> String
    ): OkHttpClient {
        val builder = OkHttpClient.Builder()
            .addInterceptor(AuthInterceptor(tokenProvider))
            .addNetworkInterceptor(
                HttpLoggingInterceptor().apply {
                    if (BuildConfig.DEBUG) {
                        level = HttpLoggingInterceptor.Level.BODY
                    }
                }
            )

        if (BuildConfig.DEBUG) {
            builder.addNetworkInterceptor(ChuckerInterceptor(context))
        }

        return builder.build()
    }

    @Provides
    @Singleton
    fun providesRetrofit(okHttpClient: OkHttpClient): Retrofit =
        Retrofit.Builder()
            .client(okHttpClient)
            .baseUrl(BuildConfig.BASE_URL)
            .addCallAdapterFactory(ApiResultCallAdapterFactory())
            .addConverterFactory(GsonConverterFactory.create())
            .build()

    @Provides
    @Singleton
    fun providesUserService(retrofit: Retrofit): UserService =
        retrofit.create(UserService::class.java)
    ...
}

설명

• @Provides는 복잡한 로직을 포함한 객체를 생성하거나, 외부 라이브러리에서 제공하는 객체를 의존성으로 주입해야 할 때 사용됩니다.
• 예를 들어, OkHttpClient, Retrofit, 그리고 UserService 는 간단한 생성자 호출만으로 생성되지 않으며, 추가 설정이나 생성 과정이 필요합니다.

특징

1. 구체적인 생성 로직 포함 가능:
   • OkHttpClient의 경우, Interceptor, Logging 등을 추가로 설정하며 객체를 생성합니다.
   • Retrofit은 OkHttpClient와 함께 특정 설정을 추가해 객체를 만듭니다.
2. 외부 라이브러리와 연동:
   • Retrofit, OkHttp 등 외부 라이브러리 객체를 의존성 주입에 사용할 때 활용됩니다.
3. 구현된 메서드 사용:
   • 반드시 객체를 반환하는 구체적인 메서드로 작성되어야 합니다.

장점

• 복잡한 객체 생성 과정이 포함된 경우 적합합니다.
• 외부 의존성이나 동적으로 값을 가져와야 하는 경우에 유연합니다.

3. 두 예제의 차이점 비교

4. 언제 어떤 것을 사용할까?

• @Binds:
  • 좀 더 정확히 말하면 인터페이스는 생성자를 정의할 수 없기 때문에 DataStoreRepository를 상속받는 구현체(DataStoreRepositoryImpl)를 Hilt에게 제공합니다. (Hilt 에게 DataStoreRepository 만 알려줘도 DataStoreRepositoryImpl 에서 override한 메소드를 쓸 수 있는 이유는 Module에서 정의되고 있었기 때문입니다.)
  • 예: Repository, DataSource 같은 내부 객체 간의 바인딩.
• @Provides:
  • @Provides는 Hilt에 의존성을 주입하려는 인스턴스 클래스가 외부 라이브러리(Retrofit, OkHttp, Room, DataStore 등)를 사용하는 경우 혹은 빌더 패턴으로 인스턴스를 생성하는 경우에 사용합니다.
  • 예: Retrofit, OkHttpClient 같은 네트워크 관련 객체 생성.

참고

https://develop-oj.tistory.com/69

이제 4학년 1학기.. 마지막으로 연합동아리를 할 수 있는 기회.. 공고가 올라오자마자 바로 넣어야겠다 생각했다.

여러 연합동아리가 있었지만 SOPT라는 동아리가 유명하다는 것도 주변 사람들을 통해 알고 있었고 졸업 프로젝트를 SOPT OB분과 같이 했었는데 잘하셔서 꼭 한번 활동 해보고 싶었다.

서류를 지원하려고 보니 일단 내용이 빡셌다. 여러 문항의 글자수를 합치면 총 5600자에 + 포트폴리오 or Github 였다 😮.. 그리고 나는 웹 개발을 하다가 최근 안드로이드로 기술 스택을 변경했다. 이번 솝트에도 안드로이드로 지원하는 것이었기 때문에 질문에 대한 답변에 어려움이 있었다.

그래도 핵심 가치를 알려줬기 때문에 이를 잘 연결지어서 열심히 작성했다.

아무튼 서류 붙음!

근데 면접 날짜가 얼마 남지 않았기 때문에 빠르게 준비했다. 공통 질문, 예시 질문 등을 면접 후기 블로그나 주변 솝트 경험이 있는분들에게 조언을 구해가며 준비했다. 이것도 파트별 커리큘럼도 참고해서 면접 질문 준비를 했다.

아래와 같이 노션으로 대부분의 질문과 답변을 정리해서 준비를 했었다..

면접은 건대에서 진행되었는데 11시에 주변에 가서 준비하다가 5시쯤 면접 시작이었다. 면접 전 솝트 분들과 아이스브레이킹이라고 해서 긴장을 푸는 시간을 갖고, 회장단 분들과 공통적인 면접을 진행하고 그 다음으로 파트장분과 기술쪽? 면접을 진행하는 방식으로 면접이 이루어졌다.

먼저 회장단 부터 들어가자마자 자기소개를 시키고 회장단에서는 지원서를 바탕으로 면접 질문을 해주셨다.

끝나자마자 노션에 정리한 내용인데 일단 회장단 질문은 이정도였던거같다. 3명에서 봤는데 공통질문으로는 자기소개 마지막으로 할말이었고 중간 질문은 이력서의 기반으로 한명씩 질문하고 답변하는 방식이었다.

그 다음으로 파트장 분과 면접이었는데 이건 1대1로 이루어졌다.

웹쪽 프로젝트가 많았고 안드로이드 경험이 많지 않았기 때문에 기술적인 질문은 안드로이드 4대 컴포넌트에 대한 질문이 많았다. 내 생각엔 파트장과 회장단 면접 모두 협업에 대해 어떤 생각을 갖고 있는지 궁금해하는 질문들이 많았던것 같다.

면접에 대한 답변은 대부분 핵심가치 ( 용기 몰입 화합 ) 을 강조하며 프로젝트 협업 경험을 통해 이러한 상황에서는 ~식으로 행동할 것 같다라고 답변을 했다.

합격 결과를 받았을 때 너무 좋았다. 😆

이번 서류 작성과 면접 준비를 하면서 내가 해왔던 활동들을 정리하고 글로 써보는 경험을 하면서 부족한 점도 느끼고 그 동안 했던 활동들을 통해 많이 성장한 것을 느꼈다.

세미나도 기대되고 스터디도 기대된다. 사실 4주차 때 후기를 작성하는거라 지금 스터디도 8개 들어가져 있다. 스터디랑 세미나 잘 마무리 지어야겠다.

AND SOPT 화이팅 !!

멀티 모듈 구조의 기본 개념

멀티 모듈 구조란 하나의 안드로이드 앱 프로젝트를 여러 개의 모듈로 나누어 개발하는 구조에요. 각 모듈은 독립적으로 기능을 수행하며, 필요에 따라 서로 간에 데이터나 기능을 공유할 수 있어요.

일반적으로 멀티 모듈 구조는 도메인 모듈, 데이터 모듈, 프레젠테이션 모듈 등으로 나누어 개발해요. 도메인 모듈은 앱의 비즈니스 로직을 담당하며, 데이터 모듈은 데이터 관리와 네트워크 통신을 담당해요. 프레젠테이션 모듈은 사용자 인터페이스(UI)와 사용자 경험(UX)을 담당해요.

장점

1. 관심사의 분리

멀티 모듈 아키텍처에서 각 모듈은 독립적인 기능 단위로 구성돼요. 이러한 분리는 코드의 가독성을 향상시키고, 유지 보수를 용이하게 해요. 예를 들어, 도메인 모듈, 데이터 모듈, 프레젠테이션 모듈 등등 각각의 기능을 별도의 모듈로 분리함으로써, 개발자는 특정 기능에 집중할 수 있고, 모듈 간의 상호 의존성을 최소화할 수 있어요.

2. 빌드 속도의 향상

멀티 모듈 구조에서는 변경이 발생한 모듈만 재빌드 하면 되기 때문에, 전체 프로젝트의 빌드 시간이 크게 줄어들어요. 이는 큰 규모의 프로젝트나, 빠른 이터레이션을 필요로 하는 개발 환경에서 특히 유용해요.

3. 낮은 결합도와 높은 응집력

각 모듈이 고유의 기능만을 담당하므로, 모듈 간 결합도는 낮아지고, 모듈 내 응집력은 높아져요. 이는 소프트웨어 GRASP 원칙 중 낮은 결합도(Low Coupling)와 높은 응집력(High Cohesion)의 원칙에 부합해요. 결과적으로, 각 모듈은 독립적으로 기능을 수행할 수 있으며, 시스템 전체의 안정성과 확장성이 향상돼요.

4. 협업의 효율성 증대

멀티 모듈 구조에서는 여러 개발자가 동시에 다른 모듈에서 작업할 수 있어요. 이는 코드 베이스의 충돌을 최소화하고, 팀 간의 협업을 용이하게 만들어요. 각 팀은 자신의 모듈에만 집중할 수 있으므로, 전체 프로젝트의 진행에 있어 효율성이 증가해요.

5. Dynamic Feature 모듈의 활용

Dynamic Feature 모듈을 사용하면, 사용자가 실제로 필요로 할 때만 특정 기능을 다운로드할 수 있어요. 이는 앱의 초기 다운로드 크기를 줄이는 데 큰 도움이 되며, 필요에 따라 기능을 추가하거나 제거할 수 있는 유연성을 제공해요. 직접 사용해보진 않았지만 이러한 기능이 있다고 하네요..!

단점

1. 초기 환경 구축에 많은 시간 소요

멀티 모듈 아키텍처를 처음 설정할 때는 각 모듈의 역할과 경계를 정의하고, 모듈 간의 의존성을 관리하는 구조를 설계하는 데 상당한 시간과 비용이 들어갈 수 있어요.

특히, 대규모 프로젝트나 복잡한 시스템에서는 이 과정이 더욱 복잡하고 시간이 많이 걸릴 수 있어요.

2. 모듈을 무분별하게 생성하면 오히려 복잡해질 수 있음

멀티 모듈 아키텍처의 또 다른 주요 단점은 모듈을 너무 많이 또는 무분별하게 생성할 경우 시스템이 오히려 더 복잡해질 수 있다는 점이에요.

모듈을 너무 세분화하면, 각 모듈 간의 인터페이스 관리와 조정이 복잡해지며(유지보수성이 오히려 안좋아짐), 전체 시스템의 통합과 테스트 과정이 더 어려워져요.

참고

https://developer.android.com/guide/navigation/integrations/multi-module?hl=ko https://velog.io/@paulus0617/Android-Refactoring-Multi-Modularizing

사실 이해가 잘 되지 않았습니다.. (그래서 공부하면서 정리하겠다고 했습니다..)

그렇다면 의존성 주입이란 무엇일까..?

한 클래스는 종종 다른 클래스를 참조합니다. 예를 들면, Car라는 클래스는 Engine이라는 클래스를 참조하고 있습니다. 이렇게 클래스를 필요로하는 것을 의존성(dependency)이라고 합니다. (저도 이해할 수 있는) 좋은 예제가 있어서 들고 와봤습니다!

class Car {
    private val engine = Engine()
    fun start() {
        engine.start()
    }
}
fun main(args: Array) {
    val car = Car()
    car.start()
}

위처럼 코드를 작성하면 Car 와 Engine 의 결합이 강해지고 재사용성이 떨어지게 됩니다. 아래는 의존성 주입을 이용해서 수정한 코드입니다.

class Car(private val engine: Engine) {
    fun start() {
        engine.start()
    }
}
fun main(args: Array) {
    val engine = Engine()
    val car = Car(engine)
    car.start()
}

위 코드는 Engine 객체를 main 에서 생성하고 Car 생성자에게 전달하게 됩니다.

이를 통해 재사용성이 좋아지고 테스트 작성이 용이해집니다.

간단하게 의존성 주입에 대해서 이해했으니

여기서 Hilt 란 무엇인가?

Hilt는 Android 앱 개발에 사용되는 의존성 주입(Dependency Injection, DI) 라이브러리입니다. 의존성 주입을 통해 객체 간의 결합도를 낮추고, 코드의 재사용성 및 유지보수성을 향상시킬 수 있습니다. Hilt는 Google에서 제공하며, Dagger를 기반으로 하고 있어서 Dagger의 강력한 기능을 좀 더 쉽게 사용할 수 있도록 도와줍니다.

주요 특징

1. 자동화된 의존성 관리: Hilt는 컴파일 타임에 의존성을 처리하여, 실행 시간에 발생할 수 있는 오류를 최소화합니다.
2. 표준화된 설정: Hilt를 사용하면 Android 애플리케이션의 표준적인 구조에 맞게 의존성을 설정할 수 있으며, 이는 앱 전체에서 일관된 방식으로 의존성을 관리할 수 있게 해줍니다.
3. 쉬운 통합: Hilt는 Android Jetpack과 긴밀하게 통합되어 있어서, 생명주기나 다른 Jetpack 기능들과의 호환성을 자연스럽게 제공합니다.

사용 방법

Hilt를 사용하기 위해서는 먼저 의존성을 Gradle 파일에 추가하고, 애플리케이션 클래스에 @HiltAndroidApp 어노테이션을 적용해야 합니다. 이 어노테이션은 Hilt의 의존성 주입 기능을 앱 전체에 적용합니다. 그 다음으로, 필요한 곳에 @Inject 어노테이션을 사용하여 의존성을 주입받을 수 있습니다.

예를 들어, 액티비티, 프래그먼트, 뷰모델, 서비스 등에서 필요한 객체를 Hilt가 자동으로 주입해주도록 설정할 수 있습니다. 이 과정에서 개발자는 의존성을 생성하고 관리하는 복잡한 작업에서 벗어날 수 있어, 더욱 집중해서 애플리케이션의 비즈니스 로직을 개발할 수 있습니다.

종속 항목 추가

build.gradle.kts(Module.app)

plugins {
    ...
    alias(libs.plugins.kotlin.kapt)
    alias(libs.plugins.hilt)
}

android {
  ...
}

dependencies {
  // Hilt 의존성
  implementation(libs.hilt)
  kapt(libs.hiltCompiler)
}
kapt {
  correctErrorTypes = true
}

libs.versions.toml

[versions]
...
hilt = "2.48"
...

[plugins]
...
kotlin-kapt = { id = "org.jetbrains.kotlin.kapt" }
hilt = { id = "com.google.dagger.hilt.android", version = "2.48" }

Hilt 애플리케이션 클래스

AndSopt.kt

@HiltAndroidApp
class AndSopt : Application()

Android 클래스에 종속 항목 삽입

MainActivity.kt

@AndroidEntryPoint
class MainActivity : ComponentActivity() { ... }

예시 사용

PreferencesManager.kt

class PreferencesManager @Inject constructor(@ApplicationContext context: Context) {
    private val sharedPreferences: SharedPreferences =

SignUpViewModel.kt

@HiltViewModel
class SignUpViewModel @Inject constructor(
    private val userManager: UserManager,
    @ApplicationContext private val context: Context
) : ViewModel() { 
        ...
        private fun validateEmail() {
        isEmailValid = userIdInput.isNotEmpty() && isValidEmail(userIdInput)
        signUpEmailDescription = when {
            userIdInput.isEmpty() -> context.getString(R.string.sign_up_email_default)
            userIdInput.length < 5 -> context.getString(R.string.sign_up_email_error1)
            !isEmailValid -> context.getString(R.string.sign_up_email_error2)
            else -> context.getString(R.string.sign_up_email_default)
        }
    } 
    ...
}

SignUpScreen.kt

@Composable
fun SignUpScreen(
    onNavigateToSignIn: () -> Unit,
    modifier: Modifier,
    viewModel: SignUpViewModel = hiltViewModel()
) { ... }

위의 SignUpViewModel 에서는 @Inject 생성자를 통해 UserManager 인스턴스와 애플리케이션 컨텍스트Context가 자동으로 주입됩니다. 이를 통해 SignUpViewModel 내에서는 userManager와 context를 직접 생성하거나 초기화할 필요 없이 바로 사용할 수 있습니다.

결론..

Hilt를 사용하여 PreferencesManager 클래스에서 @ApplicationContext 어노테이션을 통해 Context 를 주입받는 방법은 추가적인 모듈 설정 없이도 애플리케이션 전반의 Context를 자동으로 제공받을 수 있기 때문에 효율적입니다. 이로 인해 PreferencesManager와 같은 클래스에서 Context를 관리하기 위해 별도의 모듈을 제공할 필요가 없습니다. 이는 코드의 간결성을 높이며, 의존성 관리를 더욱 명확하게 해줍니다.

출처

https://developer.android.com/training/dependency-injection/hilt-android https://developer.android.com/codelabs/android-hilt https://lovestudycom.tistory.com/entry/Android-Hilt를-이용한-의존성-주입

MySQL과 MongoDB의 주요 차이점

데이터 구조

먼저, MySQL과 MongoDB의 가장 큰 차이점은 데이터 구조입니다.

• MySQL은 관계형 데이터베이스로, 데이터를 테이블 형태로 저장합니다. 스키마가 엄격하며, 데이터 무결성을 보장하기 위해 제약 조건이 많습니다. 각 테이블은 서로 관계를 맺고, 이 관계를 통해 데이터를 관리하죠.
• MongoDB는 비관계형 데이터베이스로, 데이터를 JSON과 유사한 문서(document) 형식으로 저장합니다. 이 방식 덕분에 스키마가 유연하여 데이터 구조를 쉽게 수정할 수 있습니다. 말하자면, 변화에 빠르게 대응할 수 있는 장점이 있습니다.

데이터 모델링

데이터를 어떻게 모델링하는지도 두 데이터베이스 간의 큰 차이 중 하나입니다.

• MySQL에서는 데이터를 여러 테이블로 나누고, 각 테이블 간의 관계를 정의합니다. 이를 통해 데이터 중복을 최소화하고 무결성을 유지합니다.
• MongoDB는 데이터를 중복 저장하는 방식으로, 하나의 문서에 관련된 데이터를 함께 저장하여 읽기 성능을 최적화합니다. 이 덕분에 특정 데이터를 조회할 때 여러 테이블을 참조할 필요가 없습니다.

JOIN 기능

이 부분에서 많은 차이가 있는데요, 바로 JOIN 기능입니다.

• MySQL에서는 여러 테이블을 연결할 때 JOIN 기능을 사용합니다. 예를 들어, 사용자의 주문 정보와 해당 사용자의 정보를 한 번에 가져올 수 있죠.
• MongoDB는 기본적으로 JOIN 연산을 지원하지 않지만, aggregation 파이프라인의 $lookup을 사용하면 제한적으로 조인 기능을 구현할 수 있습니다. 하지만 이는 MySQL의 JOIN만큼 최적화되어 있지는 않아서 대량의 데이터를 다루는 경우 성능 문제가 발생할 수 있습니다.

NoSQL, MongoDB를 선택하게 된 이유

저희 팀이 MongoDB를 선택하게 된 이유는 두 가지였습니다.

• 첫째, 유연한 데이터 구조였습니다. 변화하는 요구사항에 맞게 데이터 스키마를 쉽게 수정할 수 있었기 때문에, 빠르게 개발해야 하는 상황에서 큰 도움이 되었습니다.
• 둘째, 수평적 확장성 덕분이었습니다. 데이터가 급격히 늘어나는 프로젝트였기 때문에, 여러 서버로 데이터를 쉽게 분산시킬 수 있는 MongoDB의 장점이 크게 작용했습니다.

그렇지만 많은 데이터를 참조해야되는 인사관리 프로그래밍 특성상 맞지 않았고 이로 인해 직접적으로 문제와 그때 당시 해결했던 방법에 대해서 작성해볼까 합니다.

MongoDB를 사용하면서 가장 고생했던 순간 중 하나는 JOIN 기능의 부재였습니다.

당시 제가 맡았던 작업은 한 달 동안의 근무 기록을 가져와서 각 조직 내 근로자들의 하루 근무 데이터를 바탕으로 연장근무, 야간근무, 휴일근무를 계산해 보여주는 기능을 구현하는 것이었어요. 문제는 MongoDB에서 JOIN이 없기 때문에 각 데이터를 일일이 접근해야 했다는 점이었죠.

예를 들어, 한 조직에 대해서 user_id + company_id를 사용해서 userCompanyRecord(인사정보)를 가져오고, 다시 company_id 와 userCompanyRecord_id를 가지고 근태 기록을 가져와야 했죠. 이걸 매달 30일치(대략 한 달의 일수) 데이터를 조회하고, 이를 통해 연장근무, 야간근무, 휴일근무를 하나씩 계산해야 했습니다. 게다가 가장큰 조직은 회사 전체 조직으로 약 1000명의 근로자에 대한 데이터를 다루면서 각 인원의 근무 정보를 그래프로 시각화하는 기능도 포함되어 있었습니다.

이렇게 많은 데이터를 반복적으로 조회하다 보니, 개발 서버에서 테스트할 때 리소스 사용량이 급격히 증가했고, 속도도 매우 느려졌습니다. 결국 대량의 데이터를 실시간으로 처리하기에는 한계가 있었습니다. 외주 회사에서는 실시간성이 필요하지 않다고 했기 때문에, 이를 빠르게 해결하기 위해 자정에 하루 단위로 데이터를 미리 계산해 저장하고, 이를 조회하는 데이터 캐싱 방식으로 변경했습니다.

이 경험을 통해 대량의 데이터를 다루는 상황에서는 관계형 데이터베이스의 JOIN이 얼마나 효율적인지 다시 한 번 깨닫게 되었고, MongoDB를 사용할 때는 처음부터 데이터 조회 구조를 잘 설계하는 것이 얼마나 중요한지를 절실히 느꼈습니다.

추가적으로 그 당시에는 $lookup 기능을 사용하진 않았습니다. 아마 사용했으면 조금 더 좋아질 수는 있었겠지만 JOIN 과 완벽하게 동일하진 않기 때문에 여전히 문제가 지속될 가능성이 있습니다. (다음엔 기회가 된다면 $lookup 을 사용해 봐야겠습니다!)

이 부분에 대해서는 다음 기회에 더 자세히 다뤄보려 합니다!

MySQL JOIN 문서 MongoDB $lookup 문서

MySQL과 MongoDB의 적합한 사용 사례

그렇다면 MySQL과 MongoDB는 어떤 경우에 적합할까요?

• MySQL은 데이터 무결성이 중요하고, 복잡한 관계를 관리해야 하는 금융 시스템이나 전자 상거래 시스템에 적합합니다.
• 반면, MongoDB는 유연한 데이터 구조가 필요하고, 빠른 개발 및 수평적 확장이 중요한 소셜 미디어 플랫폼이나 로그 데이터 저장에 적합합니다.

결론

결국, 적절한 데이터베이스를 선택하는 것이 중요합니다. MongoDB와 MySQL은 각기 다른 장점과 단점을 가지고 있으며, 프로젝트의 요구사항에 따라 알맞은 데이터베이스를 선택하는 것이 성공의 열쇠입니다. 저 역시 이번 경험을 통해 JOIN 없이도 효율적으로 데이터를 다루기 위해 데이터 모델링 방식에 대해 깊이 고민하는 것이 얼마나 중요한지 깨달았습니다.

마무리 질문

여러분은 어떠신가요? MongoDB나 MySQL을 사용하면서 겪었던 어려움이나 배운 점이 있다면 댓글로 공유해 주세요! 여러분의 경험을 통해 서로 배울 수 있기를 기대합니다.

그 중 가장 첫번째 필수과제 스터디 내용을 공유해보려고 합니다.

Work Description ✏️

• SignInActivity

1. Hide, Show 에 따라 비밀번호 visible 구현
2. putExtra로 MyActivity 에 이메일, 정보 넘겨줌
3. SharedPreference 사용해서 로그인 구현
4. 로그인 실패하면 Dialog 띄우기
5. 로그인 성공하면 Toast 메세지 사용
6. 로그인 성공 시 SignInActivity finish 처리
7. 회원가입 클릭시 SignUpActivity 로 이동

• SignUpActivity

1. Hide, Show 에 따라 비밀번호 visible 구현
2. 이메일, 비밀번호 정규식처리
3. 이메일, 비밀번호 정규식이 올바를 때만 회원가입 하기 버튼 활성화
4. 회원가입 성공시에 Toast 메세지 처리

• MyActivity

1. getExtra 로 처리하거나 자동로그인 경우에는 SharedPreferences 사용하여 저장된 getUsername 값 가져오기 val email = intent.getStringExtra("email") ?: (preferencesManager.getUsername() ?: "프로필1")

• 기타

1. utils/Validator.kt 사용해서 이메일, 비밀번호 정규식 따로 뺌
2. Topbar, TextField 컴포넌트화

Screenshot 📸

SignUpActivity

MyActivity

SOPT에서 배우고 싶은 부분이 깃과 깃허브 및 협업 방식이었기 때문에 달려갔습니다.

초기 내용을 요약하자면 Git 과 GitHub 에 대한 설명을 간단하게 해주셨습니다. 일단 분산형 버전 관리 시스템 이며 예시를 들어가며 중요한 점을 강조해 주셨습니다.

예시를 들어가며 Git과 Github 사용법에 대해서 설명해주셨습니다. 덕분에 더욱 쉽게 이해한것 같아요.

공부한 것들을 바탕으로 제 생각대로 정리했습니다.

1. git init 을 통해 Git 이 를 추적할 수 있도록 한다.(Untracked 상태)

2. 변화가 있을 시에 git add '파일명' 을 통해 Working Director 에 있던 것을 ⇒ Staging Area 로 보냅니다.(Tracked 상태)

3. Staging Area ⇒ Local Repository 로 보내기 위해 git commit -m “[Feat] 어쩌고 UI 구현” 명령어를 작성해줍니다! 만약 추적하고 있는 파일들에서 수정사항이 생긴다면 Modified 상태가 되고 아니면 Unmodified 상태가 됩니다. 수정 사항 같은 경우에는 git status 로 확인하시면 됩니다.

   git commit -m 에서 -m 은 message 입니다.

4. 내 변경 사항들을 원격 저장소(origin or remote) 로 저장하기 위해서 git push origin “브랜치명" 명령어를 작성해줍니다.

5. 현재 브랜치에 있는 것에 다른 브랜치에서 개발한 것을 합치기 위해서는 git merge 를 사용하시면 됩니다.

6. 현재 브랜치를 최신화하기 위해서는 git fetch 를 하시면 됩니다!

이외에 다른 명령어들(rebase, branch, checkout...)도 많은데 나중에 다시 공부해서 정리하도록 할게요.

그리고 마지막에 Git 명령어 공부하기 좋은 사이트 추천해주셔서 풀어봤는데 재밌더라구요!

아래 링크는 Learn Git Branching 라는 사이트입니다.

https://learngitbranching.js.org/?locale=ko

후기

제가 Git 과 Github 에 대해서는 자세히 공부한 건 아니었기 때문에 간단한 예시를 들어가며 기본적인 부분부터 잡아주는 강의 방식이 너무 좋았어요.

탐욕 알고리즘 또는 그리디 알고리즘(greedy algorithm)은 문제를 해결할 때 매 순간 가장 최적이라고 생각되는 선택을 하는 알고리즘 설계 기법입니다. 이러한 선택은 그 순간에 대해서는 지역적으로는 최적이지만, 그 선택들을 계속 수집하여 최종적(전역적)인 해답을 만들었다고 해서, 그것이 최적이라는 보장은 없습니다. 하지만 탐욕알고리즘을 적용할 수 있는 문제들은 지역적으로 최적이면서 전역적으로 최적인 문제들입니다.

그리디(greedy) 알고리즘은 말그대로 탐욕스럽게 미래를 생각하지 않고

현재에서 매 순간 최선의 선택을 하면서 답을 구하는 알고리즘입니다.

특징

• 단순성: 구현이 비교적 간단하며 이해하기 쉽습니다.
• 빠른 실행 속도: 복잡한 연산이 필요하지 않아 실행 속도가 빠릅니다.
• 최적해 보장 여부: 모든 문제에서 최적해를 보장하지는 않으므로 적용 가능 여부를 판단해야 합니다.

💡 예시 : 거스름돈 문제

문제 설명:

어떤 가게에서 거스름돈으로 줄 수 있는 동전의 종류는 500원, 100원, 50원, 10원입니다. 손님에게 거슬러줘야 할 금액이 N원일 때, 동전의 최소 개수를 구하는 프로그램을 작성하세요.

그리디 알고리즘 적용 방법:

1. 가장 큰 단위의 동전부터 사용합니다.
2. 현재 동전으로 거슬러줄 수 있는 만큼 최대한 거슬러 줍니다.
3. 남은 금액에 대해 다음으로 큰 단위의 동전으로 반복합니다.

예시 코드 (Python):

def get_min_coin_count(n, coin_types):
    count = 0
    for coin in coin_types:
        count += n // coin  # 해당 동전으로 거슬러 줄 수 있는 개수
        n %= coin  # 거슬러 주고 남은 금액
    return count

n = 1260
coin_types = [500, 100, 50, 10]

print(get_min_coin_count(n, coin_types))  # 출력: 6

실행 결과 설명:

• 500원 동전 2개: 1000원
• 100원 동전 2개: 200원
• 50원 동전 1개: 50원
• 10원 동전 1개: 10원
• 총 동전 개수: 6개

주의사항

그리디 알고리즘이 항상 최적해를 보장하지 않는 경우

동전 단위가 서로 배수 관계가 아닐 때는 그리디 알고리즘이 최적해를 보장하지 않습니다.

최적해란? 주어진 문제에서 가장 최소 또는 최대 값을 구하는 것

예시 문제:

동전의 종류가 500원, 400원, 100원이고, 거스름돈이 800원이라면?

그리디 알고리즘 적용 결과:

• 500원 1개 사용 → 남은 금액 300원
• 100원 3개 사용 → 남은 금액 0원
• 총 동전 개수: 4개

최적해:

• 400원 동전 2개 사용 → 남은 금액 0원
• 총 동전 개수: 2개

그리디 알고리즘을 적용했을 때보다 동전 개수가 적으므로, 이 경우 그리디 알고리즘은 최적해를 구하지 못합니다.

그리디 알고리즘 적용 가능한 문제 유형

• 활동 선택 문제: 일정 시간에 가장 많은 활동을 선택하는 문제.
• 최소 신장 트리: Kruskal 알고리즘, Prim 알고리즘.
• 허프만 코딩: 데이터 압축에 사용하는 알고리즘.

결론

그리디 알고리즘은 매 순간 가장 좋아 보이는 선택을 하는 방법으로, 문제에 따라 매우 효율적이고 간단한 해결책을 제공합니다. 하지만 항상 최적해를 보장하지는 않으므로, 해당 알고리즘이 문제에 적합한지 판단하는 것이 중요합니다.

참고

https://night-knight.tistory.com/entry/그리디Greedy-알고리즘-예시와-문제 https://ko.wikipedia.org/wiki/탐욕_알고리즘

객체 지향 프로그래밍 설계 시 자주 발생하는 문제를 해결하기 위해 디자인 패턴을 사용합니다. 특히 여러 사람이 협업하는 개발 환경에서, 다른 사람이 작성한 코드나 기존 코드를 이해하고 수정하는 것은 매우 어려운 작업입니다. 코드를 변경하거나 새로은 기능을 추가할 때 의도하지 않은 결과나 버그를 발생할 수 있으며, 성능 최적화도 까다롭습니다. 이러한 문제를 방지하고 개발 시간 및 비용을 절약하기 위해 디자인 패턴을 활용합니다. 디자인 패턴은 공통 문제에 대한 검증된 해결책을 제공함으로써, 코드의 가독성과 재사용성을 높이고, 팀 내의 기술적 의사소통을 원활하게 합니다.

MVC, MVP, MVVM 패턴 https://velog.io/@roel_dev/디자인-패턴MVC-MVP-MVVM-패턴

MVC, MVP, MVVM 같은 패턴들은 관심사의 분리를 통해 테스트 코드의 작성을 용이하게 해주는 등, 대규모 개발에 있어서 필수 불가결한 요소가 되었습니다.

MVC 패턴의 View와 Model 사이의 높은 결합도는 MVP, MVVM 패턴을 파생시켰고, 데이터와 뷰를 분리함으로써 얻는 장점으로 인해 현재는 많은 프로젝트에 MVP, MVVM 패턴을 사용하고 있습니다. 패턴의 View와 Model 사이의 높은 결합도는 MVP, MVVM 패턴을 파생시켰고, 데이터와 뷰를 분리함으로써 얻는 장점으로 인해 현재는 많은 프로젝트에 MVP, MVVM 패턴을 사용하고 있습니다.

하지만, 이들도 마냥 장점만 있는 것은 아니었습니다.

MVP, MVVM 패턴을 적용하면서 직면하는 문제로 두 가지가 발생하였습니다

상태 문제

• 안드로이드는 어떻게 보면 상태의 집합입니다. 화면에 나타나는 모든 정보나, 버튼 활성화 등 상태들로 구성되어 있습니다.
• 상태들을 관리하기 힘들어지고, 의도하지 않는 방향으로 제어가 된다면 상태 문제가 됩니다.

상태 문제의 좋은 예시로, 로그인이 실패했을 때 지속적으로 다음 화면이 보여 지는 상황이 발생합니다.

부수 효과

• 네트워크 통신, 데이터베이스 접근 등의 부수 효과들로 인해 발생합니다.
• 다이얼로그, 토스트 메시지, 액티비티의 이동도 이에 포함됩니다.
• 여러 비동기 작업들이 섞여서 어떤 결과를 얻을 지 예상할 수 없고 이에 따라 상태변화에 어려움을 겪습니다. 위 문제들을 MVI에서 어떻게 풀어나가는지 확인해 보면서, MVI에 대해 알아보겠습니다.

MVI

MVI ⇒ Model + View + Intent 를 합친 용어

MVI는 Model, View, Intent로 이루어져 있으며, 데이터베이스, 네트워크 통신등의 작업을 진행하기 위해 SideEffect를 포함합니다.

• 사용자 또는 시스템의 Action을 포함하는 Intent가 발생합니다.
• Intent를 통해 Model이 reducing되고, Model을 Observing 하고 있던 View는 Rendering을 통해 View를 업데이트 합니다.

Intent

• 사용자 또는 앱 내의 상태를 바꾸려는 의도
• 모델은 인텐트를 통해서, 새로운 상태로 변화할 수 있다.
  • MVI의 단점 중 하나로, 가벼운 변경 사항도 이를 적용해야 합니다.

기존의 MVC나 MVVM 같은 디자인 패턴은, 어떠한 형식에 따라 개발자가 직접 설계하는 방식이었습니다. MVI 패턴 같은 경우에도 직접 작성할 수 있으나, MVI 패턴은 제공되는 프레임워크를 통해 설계 하는것이 좋습니다.

참고

https://small-stepping.tistory.com/1137 https://medium.com/@kimdohun0104/mvi-패턴에-대한-고찰-이유와-방법-그리고-한계-767cc9973c98 https://dev.to/kaleidot725/implementaing-jetpack-compose-orbit-mvi-3gea

1. Activity (액티비티)

• 설명: 하나의 화면을 나타내는 컴포넌트로, 사용자와 상호작용할 수 있는 UI 요소입니다.

• 역할: 사용자 인터페이스를 구성하고, 사용자의 입력을 처리하며, 화면 간 전환을 관리합니다.

• 예시: 로그인 화면, 홈 화면, 설정 화면 등 각각의 화면이 액티비티로 구현됩니다.

• 중요한 메서드

  onCreate(): 액티비티가 처음 생성될 때 호출됩니다. onStart(): 액티비티가 화면에 표시될 때 호출됩니다. onResume(): 액티비티가 상호작용 상태로 돌아올 때 호출됩니다 onPause(): 액티비티가 일시 중지되거나 다른 액티비티가 화면을 가리는 등 포그라운드에서 벗어나기 전에 호출됩니다. onStop(): 액티비티가 더 이상 사용자에게 보여지지 않고 화면에서 완전히 가려질 때 호출됩니다. onRestart(): 액티비티가 onStop() 상태에서 다시 시작되기 전에 호출됩니다. onDestroy(): 액티비티가 소멸될 때 호출됩니다.

2. Service (서비스)

• 설명: UI 없이 백그라운드에서 실행되는 작업을 처리하는 컴포넌트입니다. 사용자가 직접 상호작용하지 않지만, 긴 시간 동안 실행되는 작업을 수행하는 데 적합합니다.
• 역할: 백그라운드에서 작업을 처리하며, 음악 재생, 데이터 동기화, 파일 다운로드 등의 작업을 할 수 있습니다.
• 예시: 음악 앱에서 음악 재생을 백그라운드에서 계속 실행하는 것, 다운로드 매니저가 파일을 다운로드하는 과정.
• 중요한 메서드

  onStartCommand(): 서비스가 시작될 때 호출됩니다. onBind(): 바인딩된 서비스의 클라이언트와 통신할 때 사용됩니다. onDestroy(): 서비스가 종료될 때 호출됩니다.

3. Broadcast Receiver (브로드캐스트 리시버)

• 설명: 시스템 또는 다른 애플리케이션에서 발생하는 이벤트를 감지하고, 이에 대해 반응하는 컴포넌트입니다.
• 역할: 시스템 전체에서 발생하는 이벤트(예: 배터리 부족, 네트워크 상태 변경 등)에 반응하여 적절한 작업을 수행합니다.
• 예시: 배터리 상태 변경, 네트워크 연결 상태 변경, 알람 시간 도달 시 알림.
• 중요한 메서드

  onReceive(): 브로드캐스트 메시지가 전달될 때 호출됩니다.

4. Content Provider( 콘텐트 제공자)

• 설명: 애플리케이션 간의 데이터 공유를 관리하는 컴포넌트로, 데이터를 제공하고 저장할 수 있는 인터페이스를 제공합니다.
• 역할: 애플리케이션 간에 데이터를 저장하고 불러오며, 이를 통해 다른 애플리케이션이 데이터에 접근할 수 있도록 합니다. 주로 데이터베이스나 파일 시스템의 데이터를 관리합니다.
• 예시: 연락처, 캘린더, 사진 갤러리 등의 데이터를 다른 앱에서 조회하거나 수정할 수 있습니다.
• 중요한 메서드

  query(): 데이터를 조회할 때 사용됩니다. insert(): 데이터를 삽입할 때 사용됩니다. update(): 데이터를 수정할 때 사용됩니다. delete(): 데이터를 삭제할 때 사용됩니다. getType(): 제공하는 데이터의 형식을 클라이언트에게 알려줄 때 사용됩니다.

Referring to the Current Object’s Members with the this Reference

• 모든 객체는 this 라는 키워드로 자신에 대한 참조를 엑세스할 수 있습니다.

• 특정 객체에 대해 인스턴스 메서드가 호출될 때 메서드의 본문은 this 키워드를 암시적으로 사용하여 객채의 인스턴스 변수 및 기타 메서드를 참조합니다.

  • 클래스의 코드를 사용하여 어떤 개체를 조작해야 하는지 알 수 있습니다.
  • 인스턴스 메서드의 본문에서 this 키워드를 명시적으로 사용할 수 있습니다.

• this 참조를 암묵적으로 명시적으로 사용할 수 있습니다.

• 두 개 이상의 클래스가 포함된 .java 파일을 컴파일할 때 그 컴파일러는 모든 클래스에 대해 .class 확장자가 있는 별도의 클래스 파일을 생성합니다.

• 하나의 소스 코드(.java) 파일에 여러 클래스 선언이 포함된 경우 컴파일러는 해당 클래스의 두 클래스 파일을 같은 디렉토리에 배치합니다.

• 소스 코드 파일에는 private 클래스를 하나만 포함할 수 있으며, 그렇지 않으면 컴파일 오류가 발생합니다.

• non-public 클래스들은 동일한 패키지에 있는 다른 클래스에서만 사용할 수 있습니다.

// Fig. 8.4: ThisTest.java
// this used implicitly and explicitly to refer to members of an object

public class ThisTest
{
    public static void main(String[] args)
    {
        SimpleTime time = new SimpleTime(15, 30, 19);
        System.out.println(time.buildString());
    }
} // end class ThisTest

// class SimpleTime demonstrates the "this" reference
class SimpleTime
{
    private int hour; // 0~23
    private int minute; // 0~59
    private int second; // 0~59

    // if the constructur uses parameter names identical to
    // instance variable names the "this" reference is
    // required to distingish between the names

    public SimpleTime(int hour, int minute, int second)
    {
        this.hour = hour; // set "this" object's hour
        this.minute = minute; // set "this" object's minute
        this.second = second; // set "this" object's second
    }

    // use explicit and implicit "this" to call toUniversalString
    public String buildString()
    {
        return String.format("%24s: %s%n%24s: %s",
            "this.toUniversalString()", this.toUniversalString(),
            "toUniversalString()", toUniversalString());
    }
    // convert to String in universal-time format (HH:MM:SS)
    public String toUniversalString()
    {
        // "this" is not required here to access instance variables
        // because method does not have local variables with smae
        // name as instance variables
        return String.format("%02d:%02d:%02d",
            this.hour, this.minute, this.second);
    }
} // end class SimpleTime

• SimpleTime 은 시간, 분, 초 private 인스턴스 변수를 선언합니다.
• 클래스의 인스턴스 변수 이름들과 동일한 생성자의 매개 변수 이름인 경우
• 우리는 이 this 를 사용하여 인스턴스 변수를 참조합니다. ****

대부분의 IDE들은 this.x = x 대신 x = x라고 말하면 경고를 발행하며, 이 문장은 종종 작동 금지라고 불립니다.

• Java는 클래스의 모든 개체에서 이 메서드가 호출되는 클래스당 각 메서드의 사본을 하나만 유지하여 저장소를 보존합니다.
• 반면에 각 개체에는 클래스의 인스턴스 변수에 대한 고유한 사본이 있습니다.
• 클래스의 각 메서드는 이를 암시적으로 사용하여 유지 관리할 클래스의 특정 개체를 결정합니다.

Time Class Case Study: Overloaded Constructors

• 오버로드된 생성자를 사용하면 클래스의 개체를 다양한 방식으로 초기화할 수 있습니다.

• 생성자에 과부하를 걸려면 서명이 다른 여러 생성자 선언을 제공하기만 하면 됩니다.

• 컴파일러는 각 서명의 매개 변수 수, 매개 변수 유형 및 매개 변수 유형 순서에 따라 서명을 차별화한다는 점을 기억하세요.

• Class Time2 에는 객체를 초기화하는 편리한 방법을 제공하는 5개의 오버로드된 생성자가 포함되어 있습니다.

• 컴파일러는 생성자 호출에 지정된 인수 유형의 수, 유형 및 순서를 각 컨스트럭터 선언에 지정된 매개변수 유형의 수, 유형 및 순서와 일치시켜 적절한 생성자를 호출합니다.

• 클래스 구축, 클래스 멤버에 대한 엑세스 제어, 생성자 생성에 대해 자세히 알아보기
• 문제가 발생했음을 나타내기 위해 예외를 throw 하는 방법을 보여줍니다.
• 구성(Composition) - 클래스가 다른 클래스의 객체에 대한 참조를 멤버로 가질 수 있게 해주는 기능입니다.
• 열거형(enum) 유형에 대한 자세한 내용들
• 정적인 클래스 구성원과 최종 인스턴스 변수에 대해 자세히 논의합니다.
• 대규모 어플리케이션을 관리하고 재사용을 촉진하기 위해 패키지로 클래스를 구성하는 방법 보여주기

Time Class Case Study

• Class Time1 은 하루 중 시간을 나타냅니다.
• private int 인스턴스 변수 hour, minute, 그리고 second 는 보편적 시간의 형식을 나타냅니다. (시간은 0 ~ 23, 분 및 초는 각각 0 ~ 59의 범위인 24시간 시계 형식)
• public methods 는 시간을 toUniversalString, toString 으로 설정합니다.
  • 클래스가 클라이언트에게 제공하는 공공 서비스 및 공공 인터페이스를 호출합니다.

// Fig. 8.1: Time1.java
// Time1 class declaration maintains the time in 24-hour format.

public class Time1 
{
    private int hour; // 0 ~ 23
    private int minute; // 0 ~ 59
    private int second; // 0 ~ 59

    // set a new time value using universal time: throw an
    // exception if the hour, minute or second is invalid
    public void setTime(int hour, int minute, int second)
    {
        if (hour < 0 || hour >= 24 || minute < 0 || minute >= 60 || second < 0 || second >= 60)
        {
            throw new IllegalArgumentException("hour, minute and/or second was out of range");
        }
        this.hour = hour;
        this.minute = minute;
        this.second = second;
    }

    // convert to String in universal-time format (HH:MM:SS)
    public String toUniversalString()
    {
        return String.format("%02d:%02d:%02d", hour, minute, second);
    }

    // convert to String in standard-time format (H:MM:SS AM or PM)
    public String toString()
    {
        return String.format("%d:%02d:%02d %s", 
            ((hour == 0 || hour == 12) ? 12 : hour % 12),
            minute, second, (hour < 12 ? "AM" : "PM"));
    }
} // end class Time1

위 코드의 setTime 과 같은 방법의 경우, 인스턴스 변수 값을 설정하는 데 사용하기 전에 방법의 모든 인수를 검증하여 모든 인수가 유효한 경우에만 개체의 데이터가 수정되는지 확인합니다.

Chapter 3 에서 액세스 수정자로 선언된 방법은 비공개 방법이 선언된 클래스의 다른 방법으로만 호출할 수 있다는 점을 기억하세요. 이러한 방법은 일반적으로 클래스의 다른 방법의 작동을 지원하는 데 사용되기 때문에 utility methods 또는 helper methods 이라고도 합니다.

// Fig. 8.2: TimeTest.java
// Time1 object used in an app

public class TimeTest
{
    public static void main(String[] args) 
    {
        // create and initialize a Time1 object
        Time1 time = new Time1(); // invokes Time1 constructor

        // output string representations of the time
        displayTime("After time object is created", time);
        System.out.println();

        // change time and output updated time
        time.setTime(13, 27, 6);
        displayTime("After calling setTime", time);
        System.out.println();
        // attempt to set time with invalid values
        try
        {
            time.setTime(99, 99, 99); // all values out of range
        }
        catch(IllegalArgumentException e)
        {
            System.out.printf("Exception: %s%n%n", e.getMessage());
        }

        // display time after attempt to set invalid values
        displayTime("After calling setTime with invalid values", time);
    }

    // displays a Time1 object in 24-hour and 12-hour formats
    private static void displayTime(String header, Time1 t)
    {
        System.out.printf("%s%nUniversal time: %s%nStandard time: %s%n",
            header, t.toUniversalString(), t.toString());
    }
} // end Class TimeTest

• Class Time1 는 생성자를 선언하지 않았으므로 컴파일러가 기본 생성자(default)를 제공합니다.
• 각 인스턴스 변수는 암묵적으로 기본값을 받습니다. int value.
• 인스턴스 변수는 클래스 본문에 선언될 때 로컬 변수와 동일한 초기화 구문을 사용하여 초기화할 수도 있습니다.

Method setTime 그리고 Throwing Exceptions

• Method setTime 은 시간을 설정할 때 쓰일 정수 파라미터들을 선언합니다.
• 각 인수를 테스트하여 값이 적절한 범위를 벗어나는지 확인합니다.

잘못된 값의 경우, setTime 은 IllegalArgumentException 유형의 예외를 throw 합니다.

• 잘못된 인수가 메서드에 전달되었음을 클라이언트 코드에 알립니다.
• try…catch 문을 사용하여 예외를 잡고 복구를 시도할 수 있습니다.
• throw statement 의 클래스 인스턴스 생성 표현을 IllegalArgumentException 라는 새로운 개체를 생성합니다. 이 경우 사용자가 지정 오류 메세지를 지정할 수 있는 생성자를 호출합니다.
• 예외 개체가 생성된 후 throw statement 은 setTime 을 즉시 종료하고 예외는 시간을 설정하려고 시도한 호출 메서드로 돌아갑니다.

Class Time1 선언의 소프트웨어 엔지니어링

• 인스턴수 변수 hour, minute, second 는 각각 private 로 선언됩니다.
• 클래스 내에서 사용되는 실제 데이터 표현은 클래스의 클라이언트에게 아무런 문제가 되지 않습니다.
• Time1 이 내부적으로 시간을 자정 이후의 초수 또는 자정 이후의 분 및 초수로 표현하는 것은 합리적입니다.
• 클라이언트는 이것을 인식하지 못한 채 public methods 을 사용하여 동일한 결과를 얻을 수 있습니다.

클래스는 프로그래밍을 단순화합니다.

클라이언트는 클래스의 public methods 만 사용할 수 있기 때문입니다.

이러한 방법은 일반적으로 구현 지향적이라기보다는 클라이언트 지향적입니다.

클라이언트는 클래스의 구현을 인식하지도, 관여하지도 않습니다.

클라이언트는 일반적으로 클래스가 하는 일에는 관심이 있지만 클래스가 하는 방식에는 관심이 없습니다.

인터페이스는 구현보다 덜 자주 변경됩니다.

구현이 변경되면 구현 종속 코드가 그에 따라 변경되어야 합니다.

구현을 숨기면 다른 프로그램 부분이 클래스 구현 세부 정보에 의존하게 될 가능성이 줄어듭니다.

Java SE 8 - 날짜/시간 API

• 일반적으로 나만의 날짜 및 시간 클래스를 구축하는 대신 Java API에서 제공하는 클래스를 재사용합니다.
• Java SE 8은 java.time 패키지의 클래스로 정의되는 새로운 날짜/시간 API를 도입했습니다.
• 는 이전 클래스의 다양한 문제를 수정하고 날짜, 시간대, 시간대, 캘린더 등을 조작할 수 있는 보다 강력하고 사용하기 쉬운 기능을 제공합니다.
  • 이전 클래스의 다양한 문제를 수정하고 날짜, 시간대, 시간대, 캘린더 등을 조작할 수 있는 보다 강력하고 사용하기 쉬운 기능을 제공합니다.

Controlling Access to Members

• 엑세스 수정자를 public 및 private 로 제어하여 클래스의 변수 및 방법에 대한 엑세스 권한을 부여합니다.
• 클래스의 클라이언트에 제시되는 public methods 는 클래스가 제공하는 서비스의 한 뷰입니다.(클래스의 public 인터페이스)
• 클라이언트는 클래스가 작업을 수행하는 방식에 대해서 걱정할 필요가 없습니다.
  • 이러한 이유로 클래스의 private 변수와 private methods 은 그것의 클라이언트에 액세스 할 수 없습니다.
• private 클래스 구성원은 외부 클래스에 접근할 수 없습니다.

// Fig. 8.3: MemberAccessTest.java
// Private members of class Time1 are not accessible.
public class MemberAccessTest
{
    public static void main(String[] args)
    {
        Time1 time = new Time1(); // create and initialize Time1 object

        time.hour = 7; // error: hour has private access in Time1
        time.minute = 15; // error: hour has private access in Time1
        time.second = 30; // error: hour has private access in Time1
    }
} // and class MemberAccessTest

클래스의 멤버가 아닌 방법으로 해당 클래스의 private 멤버에 액세스하려고 하면 컴파일 오류가 발생합니다.