스프링 부트 핵심 원리와 활용

Java-Ecosystem · 2025-03-31

자바 애노테이션

애노테이션 (Annotation) 프로그램 실행 중에 읽어서 사용할 수 있는 특별한 주석 내부에서 리플렉션 같은 기술 등을 활용 e.g. Class ,Method ,Field ,Constructor 클래스는 getAnnotation() 제공 참고: 본래 주석은 코드가 아니므로 컴파일 시점에 모두 제거됨 코드에 메모를 달아 놓는 것처럼 코드에 대한 메타데이터를 표현 프로그램 코드가 아니어서 애노테이션이 달린 메서드를 호출해도 영향을 주지 않음 애노테이션 정의 규칙 @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) @Documented public @interface AnnoElement { String value(); int count() default 0; String[] tags() default {}; Class<? extends MyLogger> annoData() default MyLogger.class; //MyLogger data(); // 다른 타입은 적용X } 정의: @interface 키워드 속성: 애노테이션은 속성을 가질 수 있음 요소 이름 메서드 형태로 정의 괄호()를 포함하되 매개변수는 없어야 함 데이터 타입 기본 타입 (int, float, boolean 등) String Class (메타데이터) 또는 인터페이스 (직접 정의한 것이 아닌 Class에 대한 정보) enum 다른 애노테이션 타입 위의 타입들의 배열 앞서 설명한 타입 외에는 정의 불가 (즉, 일반적인 클래스를 사용할 수 없음) 예) Member , User , MyLogger default 값 요소에 default 값을 지정 가능 예: String value() default "기본 값을 적용합니다."; 반환 값 void 반환 타입 사용 불가 예외 예외 선언 불가 메타 애노테이션: 애노테이션을 정의하는데 사용하는 특별한 애노테이션 @Retention 애노테이션의 생존 기간을 지정 종류: RetentionPolicy enum RetentionPolicy.SOURCE (특별한 경우 사용) 소스코드에서만 생존 -> 컴파일 시점에 제거 RetentionPolicy.CLASS (기본값, 그러나 거의 사용 X) 컴파일 후 .class 파일까지 생존 -> 자바 실행 시점에 제거 RetentionPolicy.RUNTIME (대부분 사용) 자바 실행 중에도 생존 런타임에 리플렉션으로 읽을 수 있어 자주 사용됨 @Target 애노테이션을 적용할 수 있는 위치 지정 지정하지 않은 곳에 애노테이션을 적용하면 컴파일 오류 발생 종류: ElementType enum 주로 TYPE, FIELD, METHOD 사용 e.g. 배열로 여러 위치도 적용 가능 @Target({ElementType.METHOD, ElementType.TYPE}) @Documented (보통 함께 사용) 자바 API 문서를 만들 때, 해당 애노테이션이 문서에 포함되어 표현되도록 지정 @Inherited 자식 클래스가 애노테이션을 상속 받을 수 있게 함 애노테이션 사용법 기본 @AnnoElement(value = "data", count = 10, tags = {"t1", "t2"}) public class ElementData1 { } 배열 항목이 하나인 경우 {} 생략 가능 & default 항목은 생략 가능 @AnnoElement(value = "data", tags = "t1") public class ElementData2 { } 입력 요소가 하나인 경우 value 키 생략 가능 (value = "data" 와 동일) @AnnoElement("data") public class ElementData3 { } 애노테이션과 상속 public interface Annotation { boolean equals(Object obj); int hashCode(); String toString(); Class<? extends Annotation> annotationType(); //애노테이션 타입 반환 } 자바에서 애노테이션은 특별한 형태의 인터페이스로 간주 모든 애노테이션은 java.lang.annotation.Annotation 인터페이스를 묵시적으로 상속 받음 @interface로 정의하면 자바 컴파일러가 자동으로 Annotation 인터페이스를 확장 애노테이션 정의 public @interface MyCustomAnnotation {} 자바가 자동으로 처리 public interface MyCustomAnnotation extends java.lang.annotation.Annotation {} 다만, 애노테이션 사이에는 상속이라는 개념이 존재 X 애노테이션은 오직 Annotation 인터페이스만 상속 애노테이션은 다른 애노테이션이나 인터페이스를 직접 상속할 수 없음 @Inherited 애노테이션을 적용한 클래스의 자식 클래스도 해당 애노테이션을 부여 받을 수 있음 클래스 상속에서만 작동 (인터페이스 구현에는 적용 X) 자바 기본 애노테이션 @Override 메서드 재정의가 정확하게 잘 되었는지 컴파일러가 체크하는데 사용 @Deprecated 더 이상 사용되지 않는다는 뜻을 표현하며, 적용된 기능은 사용을 권장하지 않음 컴파일 시점에 경고를 나타내지만, 프로그램은 작동 옵션 since : 더 이상 사용하지 않게된 버전 정보 forRemoval : 미래 버전에 코드가 제거될 예정 (더더욱 강력한 경고) 예제 @Deprecated -> 진짜 쓰지마 @Deprecated(since = "2.4", forRemoval = true) -> 진짜진짜 쓰지마 @SuppressWarnings 자바 컴파일러가 문제를 경고하지만, 개발자가 문제를 잘 알고 있으니 경고하지 말라고 지시 왠만하면 사용 X (제네릭 쓰다보면 개발자가 책임지겠다고 쓸 때 정도 있음) 옵션 all: 모든 경고 억제 deprecation: deprecated 코드를 사용할 때 발생하는 경고 억제 unchecked: 제네릭 타입과 관련된 unchecked 경고 억제 serial: Serializable 인터페이스를 구현할 때 serialVersionUID 필드를 선언하지 않은 경우 발생하는 경고 억제 rawtypes: 제네릭 타입이 명시되지 않은(raw) 타입을 사용할 때 발생하는 경고 억제 unused: 사용되지 않는 변수, 메서드, 필드 등을 선언했을 때 발생하는 경고 억제 참고: 애노테이션 기반 검증기 활용 예제 public class Validator { public static void validate(Object obj) throws Exception { Field[] fields = obj.getClass().getDeclaredFields(); for (Field field : fields) { field.setAccessible(true); // @NotEmpty 어노테이션 검사 if (field.isAnnotationPresent(NotEmpty.class)) { String value = (String) field.get(obj); NotEmpty annotation = field.getAnnotation(NotEmpty.class); if (value == null || value.isEmpty()) { throw new RuntimeException(annotation.message()); } } // @Range 어노테이션 검사 if (field.isAnnotationPresent(Range.class)) { long value = field.getLong(obj); Range annotation = field.getAnnotation(Range.class); if (value < annotation.min() || value > annotation.max()) { throw new RuntimeException(annotation.message()); } } } } } Reference 김영한의 실전 자바 - 고급 2편, I/O, 네트워크, 리플렉션

Java-Ecosystem · 2025-03-25

자바 리플렉션

리플렉션 클래스가 제공하는 다양한 정보(메타 데이터)를 런타임에 동적으로 분석하고 사용하는 기능 e.g. 스프링 프레임워크가 내가 만든 클래스를 대신 생성해주는 경우 메타데이터 종류 클래스 e.g. 클래스 이름, 접근 제어자, 부모 클래스, 구현한 인터페이스 필드 e.g. 필드 이름, 타입, 접근 제어자 런타임에 동적으로 해당 필드 값을 읽거나 수정 가능 메서드 e.g. 메서드 이름, 반환 타입, 매개변수 정보 런타임에 동적으로 메서드 조회 및 호출 가능 생성자 e.g. 매개변수 타입 및 개수 런타임에 동적으로 생성자 조회 및 객체 생성 가능 주의점 리플렉션 코드는 특별한 상황에서 사용 공통 문제를 해결하는 유틸리티, 프레임워크, 라이브러리 개발 테스트 등 일반적인 애플리케이션은 권장 X 무분별한 리플렉션 사용은 코드의 가독성과 안정성이 크게 저하 e.g. private 직접 접근은 객체 지향 원칙을 위반 (캡슐화 및 유지보수성 저하) 클래스 내부 구조나 구현 세부사항이 변경되면 쉽게 깨지거나 버그를 초래 리플렉션은 문자를 활용하므로, 필드 및 메서드 이름 변경 시 컴파일러가 놓침 클래스 메타데이터 클래스의 메타데이터는 Class 클래스로 표현 Class 조회 방법 클래스에서 찾기 클래스명.class e.g. Class<BasicData> basicDataClass1 = BasicData.class; 인스턴스에서 찾기 인스턴스.getClass() e.g. BasicData basicInstance = new BasicData(); Class<? extends BasicData> basicDataClass2 = basicInstance.getClass(); 문자로 찾기 Class.forName(패키지명문자열) e.g. String className = "reflection.data.BasicData"; Class<?> basicDataClass3 = Class.forName(className); 기본 정보 탐색 클래스 이름 경로 포함 이름: basicData.getName() //reflection.data.BasicData 클래스 이름: basicData.getSimpleName() //BasicData 패키지 basicData.getPackage() //package reflection.data 부모 클래스 basicData.getSuperclass() //class java.lang.Object 구현한 인터페이스 basicData.getInterfaces() //[] 조건 판별 basicData.isInterface() //false basicData.isEnum() //false basicData.isAnnotation() //false 수정자 정보 (규칙있는 숫자로 리턴) basicData.getModifiers() //1 참고: 수정자는 접근제어자와 비접근제어자(기타 수정자)로 분류 접근 제어자: public , protected , default ( package-private ), private 비 접근 제어자: static , final , abstract , synchronized , volatile 등 메서드 메타데이터 Method 클래스로 표현 (클래스 메타데이터를 통해 획득 가능) 메서드 메타데이터 조회 getMethod(메서드이름, 매개변수타입) 해당 클래스와 상위 클래스에서 상속된 모든 public 메서드 중 지정 메서드 조회 e.g. String methodName = "hello"; Method method = helloClass.getMethod(methodName, String.class); getDeclaredMethod(메서드이름, 매개변수타입) 해당 클래스에서 선언된 모든 메서드 중 지정 메서드 조회 e.g. String methodName = "hello"; Method method = helloClass.getMethod(methodName, String.class); getMethods() 해당 클래스와 상위 클래스에서 상속된 모든 public 메서드를 반환 e.g. Class<BasicData> helloClass = BasicData.class; Method[] methods = helloClass.getMethods(); getDeclaredMethods() 해당 클래스에서 선언된 모든 메서드를 반환 접근 제어자에 관계 X, 상속된 메서드 포함 X e.g. Class<BasicData> helloClass = BasicData.class; Method[] declaredMethods = helloClass.getDeclaredMethods(); 동적 메서드 호출 메서드 이름을 입력 받으면, 호출 대상 메서드를 동적으로 조회해 호출 가능 getMethod(), getDeclaredMethod()로 메서드 동적 조회 Method 객체의 invoke(인스턴스, 인자1, ...) 로 메서드 호출 e.g. Class<? extends BasicData> helloClass = helloInstance.getClass(); String methodName = "hello"; Method method = helloClass.getDeclaredMethod(methodName, String.class); Object returnValue = method.invoke(helloInstance, "hi"); 필드 메타데이터 Field 클래스로 표현 (클래스 메타데이터를 통해 획득 가능) 필드 조회 getField(필드이름) 해당 클래스와 상위 클래스에서 상속된 모든 public 필드 중 지정 필드 조회 e.g. Field nameField = aClass.getField("name"); getDeclaredField(필드이름) 해당 클래스에서 선언된 모든 필드 중 지정 필드 조회 e.g. Field nameField = aClass.getDeclaredField("name"); getFields() 해당 클래스와 상위 클래스에서 상속된 모든 public 필드를 반환 e.g. Class<BasicData> helloClass = BasicData.class; Field[] fields = helloClass.getFields(); getDeclaredFields() 해당 클래스에서 선언된 모든 필드를 반환 접근 제어자에 관계 X, 상속된 필드 포함 X e.g. Class<BasicData> helloClass = BasicData.class; Field[] declaredFields = helloClass.getDeclaredFields(); 필드 값 변경 setAccessible(true) private 필드에 직접 접근해 변경할 수 있는 기능 e.g. nameField.setAccessible(true) 참고: private 메서드, 생성자에서도 사용 가능 (Method, Constructor) set(인스턴스, 변경값) 필드 값 변경 메서드 e.g. nameField.set(user, "userB") 생성자 메타데이터 Constructor 클래스로 표현 (클래스 메타데이터를 통해 획득 가능) 생성자 조회 getConstructor(매개변수타입) 해당 클래스와 상위 클래스에서 상속된 모든 public 생성자 중 지정 생성자 조회 e.g. Constructor<?> constructor = aClass.getConstructor(String.class); getDeclaredConstructor(매개변수타입) 해당 클래스에서 선언된 모든 생성자 중 지정 생성자 조회 e.g. Constructor<?> constructor = aClass.getDeclaredConstructor(String.class); getConstructors() 해당 클래스와 상위 클래스에서 상속된 모든 public 생성자를 반환 e.g. helloClass.getConstructors(); getDeclaredConstructors() 해당 클래스에서 선언된 모든 생성자를 반환 접근 제어자에 관계 X, 상속된 생성자 포함 X e.g. helloClass.getDeclaredConstructors(); 동적 인스턴스 생성 setAccessible(true) private 생성자에 직접 접근해 호출할 수 있는 기능 e.g. constructor.setAccessible(true) newInstance(인자) 생성자를 호출해 동적으로 객체 생성 e.g. Object instance = constructor.newInstance("hello") Reference 김영한의 실전 자바 - 고급 2편, I/O, 네트워크, 리플렉션

Java-Ecosystem · 2025-03-15

자바 I/O & 네트워크

Java-Ecosystem · 2025-02-28

도커(Docker)Dive - 주요 명령어와 지시어

도커 명령어 기본 양식: docker (Management Command) Command Management Command는 생략 가능 (생략이 가능하면 생략을 권장) 정보 docker version : Client, Server의 버전 및 상태 확인 docker info : 플러그인, 호스트 OS의 시스템 상세 정보 확인 docker --help : 메뉴얼 확인 e.g. docker --help docker container --help docker container run --help docker ps : 실행 중인 컨테이너 리스트 조회 -a : 종료된 컨테이너 포함 모든 컨테이너 조회 docker logs (컨테이너 명) : 실행 중인 컨테이너의 로그 조회 -f : 실시간 로그 조회 이미지 레지스트리 docker pull 이미지명 : 로컬 스토리지로 이미지 다운로드 (이미지 네이밍 규칙 준수) docker tag 기존이미지명 추가할이미지명 : 로컬 스토리지에 이미지명 추가 실제 파일은 하나 (즉, 하나에 이미지에 여러 개의 이름 추가 가능) 같은 파일이어도 이름에 따라 어디에 업로드 될 지가 달라짐 e.g. docker tag devwikirepo/simple-web:1.0 veluga29/my-simple-web:0.1 docker push 이미지명 : 이미지 레지스트리에 이미지 업로드 docker login : 로컬 스토리지 특정 공간에 이미지 레지스트리 인증 정보 생성 생성 디렉터리: ~/.docker/config.json docker logout : 이미지 레지스트리 인증 정보 삭제 Management Command - container docker run (실행 옵션) 이미지명 (실행명령) : 컨테이너 실행 -d : 백그라운드 실행 (데몬 프로그램 실행에 적합) --name {컨테이너명} : 컨테이너의 이름 지정 -it : 커맨드 창을 통해 실행할 컨테이너와 직접 상호작용 shell 명령 bin/bash 추가 필요 --network 네트워크명 : 원하는 네트워크 지정 -p HostOS의포트:컨테이너의포트 : 포트포워딩 옵션 -v 도커의볼륨명:컨테이너의내부경로 : 볼륨 마운트 e.g. -v volume1:/var/lib/postgresql/data -v volume1:/etc/postgresql -v volume2:/var/lib/postgresql/data -v 사용자지정HostOS디렉토리:컨테이너의내부경로 : 볼륨 바인드 마운트 (디버깅용) e.g. -v volume1:/var/lib/postgresql/data --cpus={CPUcore수} : 컨테이너가 사용할 최대 CPU 코어 수 (소수점도 가능) --memory={메모리용량} : 컨테이너가 사용할 최대 메모리 정의 (b, k, m, g 단위) e.g. docker run --cpus=1 --memory=8g e.g. docker run 이미지명 (실행명령) : 컨테이너 실행 시 메타데이터의 cmd 덮어쓰기 docker run --env KEY=VALUE 이미지명 : 컨테이너 실행 시 메타데이터의 env 덮어쓰기 docker run -it --name 컨테이너명 이미지명 bin/bash : 컨테이너 실행과 동시에 터미널 접속 (shell) - 이미지 내부 파일 시스템 확인 혹은 디버깅 용도 docker run -it --network second-bridge --name ubuntuC devwikirepo/pingbuntu bin/bash : 원하는 네트워크 지정해 컨테이너 실행 docker run -d --name my-postgres -e POSTGRES_PASSWORD=password -v mydata:/var/lib/postgresql/data postgres:13 : 볼륨 지정해 DB 실행 docker rm 컨테이너명/ID : 컨테이너 삭제 -f : 실행 중인 컨테이너 삭제 (단순 rm은 실행 중인 컨테이너 삭제 불가) e.g. docker rm -f multi1 multi2 multi3 : 여러 컨테이너 한번에 삭제 docker cp 원본위치 복사위치 : 컨테이너와 호스트 머신 간 파일 복사 docker cp 컨테이너명:원본위치 복사위치 : 컨테이너 -> 호스트머신으로 파일 복사 docker cp 원본위치 컨테이너명:복사위치 : 호스트머신 -> 컨테이너로 파일 복사 docer container inspect 컨테이너명 : 컨테이너의 메타 데이터 조회 결과 예시 [{ { ... "NetworkSettings": { ... "Networks": { "bridge": { //브릿지 네트워크명 ... "Gateway": "172.17.0.1", //도커브릿지 가상 IP "IPAddress": "172.17.0.2", //컨테이너 가상 IP ... } } } } }] docker stats (컨테이너명/ID) : 컨테이너의 리소스 사용량 조회 docker events : Host OS에서 발생하는 컨테이너 관련 이벤트 로그 조회 Management Command - image docker image ls (이미지명) : 다운로드된 이미지 조회 docker image inspect 이미지명 : 이미지의 메타 데이터 조회 docker image rm 이미지명 : 로컬 스토리지의 이미지 삭제 docker image history 이미지명 : 이미지의 레이어 이력 조회 도커 커밋 docker commit -m 커밋명 실행중인컨테이너명 생성할이미지명 : 실행 중인 컨테이너를 이미지로 생성 도커 빌드 docker build -t 이미지명 Dockerfile경로 : 도커파일을 통해 이미지 빌드 Dockfile경로 = 빌드 컨텍스트 지정 도커 파일이 있는 경로로 가서 실행하자! (Dockerfile경로=.) 옵션 -t 이미지명 : 결과 이미지의 이름 지정 -f 도커파일명 도커파일명이 Dockerfile이 아닌 경우 별도 지정 케이스 별로 다른 도커파일이 필요한 경우 --no-cache : 캐시를 사용하지 않고 빌드 e.g. docker build -t leafy:2.0.0 . --no-cache Management Command - network docker network ls : 네트워크 리스트 조회 docker network inspect 네트워크명 : 네트워크 상세 정보 조회 docker network create 네트워크명 : 네트워크 생성 e.g. docker network create --driver bridge --subnet 10.0.0.0/24 --gateway 10.0.0.1 second-bridge docker network rm 네트워크명 : 네트워크 삭제 Management Command - volume docker volume ls : 볼륨 리스트 조회 docker volume inspect 볼륨명 : 볼륨 상세 정보 조회 e.g. [ { "CreatedAt": "2025-02-05T04:38:44Z", "Driver": "local", //local = 실제 데이터가 호스트 OS에 저장됨 "Labels": {}, //경로는 리눅스에서 관찰 가능, MacOS 등은 관찰 불가 //도커가 가상 머신 형태로 실행되기 때문 "Mountpoint": "/var/lib/docker/volumes/mydata/_data", "Name": "mydata", "Options": {}, "Scope": "local" } ] docker volume create 볼륨명 : 볼륨 생성 docker volume rm 볼륨명 : 볼륨 삭제 Management Command - compose docker compose up -d : YAML 파일에 정의된 서비스 생성 및 시작 --build : 로컬에 동일 이름 이미지가 있으면 제거하고 새 이미지로 다시 빌드 소스코드 변경이 있어야 적용됨 docker compose ps : 현재 실행 중인 서비스 상태 표시 docker compose build : 현재 실행 중인 서비스의 이미지만 빌드 docker compose logs : 실행 중인 서비스의 로그 표시 docker compose down : YAML 파일에 정의된 서비스 종료 및 제거 -v : 볼륨까지 함께 제거 (옵션이 없으면 기본적으로 볼륨은 남아있음) Dockerfile 지시어 기본 양식: 지시어 지시어의옵션 유의사항 일반적으로 파일 시스템 변 경이 있는 명령어는 레이어 추가 O 메타데이터에만 영향 주는 명령어는 레이어 추가 X 기본 지시어 FROM 이미지명 : 베이스 이미지를 지정 (필수) COPY 빌드컨텍스트내파일경로 복사할레이어경로 : 파일을 레이어에 복사 (새로운 레이어 추가) --from : 파일을 가져올 다른 스테이지 지정 (멀티 스테이지 빌드) 즉, 빌드 컨텍스트가 아니라 다른 스테이지 이미지에서 파일을 가져옴 e.g. --from=build 시스템 관련 지시어 WORKDIR 디렉터리명 : 작업 디렉터리를 지정 (새로운 레이어 추가, cd) 다음에 나오는 지시어들은 지정된 디렉터리 기준으로 수행됨 가능한 초반에 FROM 다음 바로 작성하는 것이 좋음 USER 유저명 : 명령을 실행할 사용자 변경 (새로운 레이어 추가, su) 기본은 루트 사용자로 실행 보안을 위해 컨테이너가 필요 이상의 권한을 가지지 않도록 조절 EXPOSE 포트번호 : 컨테이너가 사용할 포트를 명시 보통은 소스 코드안에 애플리케이션이 사용할 포트가 지정되어 있음 따라서, 필수는 아니지만 공유 문서 기재 용도 큼 (도커파일만 보고도 포트 확인 가능) 환경변수 설정 ARG 변수명 변수값 : 이미지 빌드 시점에만 사용할 환경 변수 설정 docker build --build-arg 변수명=변수값 : 덮어쓰기 ENV 변수명 변수값 (권장) : 이미지 빌드 및 컨테이너 실행 시점까지 계속 유지될 환경 변수 설정 docker run -e 변수명=변수값 : 덮어쓰기 프로세스 실행 ENTRYPOINT ["명령어"] : 자주 쓰이는 고정된 명령어를 지정 의도치 않은 명령어 접근 1차적 방지 (완벽 X) e.g. ENTRYPOINT ["npm"] CMD ["명령어"] : 컨테이너 실행 시 실행 명령어 지정 (메타 데이터 CMD 필드에 저장됨) e.g. CMD ["start"] RUN 명령어 : 명령어 실행 (새로운 레이어 추가) Docker Compose 지시어 예시 1 - 애플리케이션 & Redis version: '3' services: hitchecker: build: ./app image: hitchecker:1.0.0 ports: - "8080:5000" redis: image: "redis:alpine" 예시 2 - 이중화 DB version: '3' x-environment: &common_environment POSTGRESQL_POSTGRES_PASSWORD: adminpassword POSTGRESQL_USERNAME: myuser POSTGRESQL_PASSWORD: mypassword POSTGRESQL_DATABASE: mydb REPMGR_PASSWORD: repmgrpassword REPMGR_PRIMARY_HOST: postgres-primary-0 REPMGR_PRIMARY_PORT: 5432 REPMGR_PORT_NUMBER: 5432 services: postgres-primary-0: image: bitnami/postgresql-repmgr:15 volumes: - postgres_primary_data:/bitnami/postgresql environment: <<: *common_environment REPMGR_PARTNER_NODES: postgres-primary-0,postgres-standby-1:5432 REPMGR_NODE_NAME: postgres-primary-0 REPMGR_NODE_NETWORK_NAME: postgres-primary-0 postgres-standby-1: image: bitnami/postgresql-repmgr:15 volumes: - postgres_standby_data:/bitnami/postgresql environment: <<: *common_environment REPMGR_PARTNER_NODES: postgres-primary-0,postgres-standby-1:5432 REPMGR_NODE_NAME: postgres-standby-1 REPMGR_NODE_NETWORK_NAME: postgres-standby-1 volumes: postgres_primary_data: postgres_standby_data: 예시 3 - Leafy version: '3' services: leafy-postgres: build: ./leafy-postgresql image: leafy-postgres:5.0.0-compose volumes: - mydata:/var/lib/postgresql/data deploy: resources: limits: cpus: '1' memory: 256M restart: always leafy-backend: build: ./leafy-backend image: leafy-backend:5.0.0-compose environment: - DB_URL=leafy-postgres depends_on: - leafy-postgres deploy: resources: limits: cpus: '1.5' memory: 512M restart: on-failure leafy-front: build: ./leafy-frontend image: leafy-front:5.0.0-compose environment: - BACKEND_HOST=leafy-backend ports: - 80:80 depends_on: - leafy-backend deploy: resources: limits: cpus: '0.5' memory: 64M restart: on-failure volumes: mydata: version : 도커 컴포즈의 버전 정의 services : 실제로 실행할 컨테이너들의 리스트 컨테이너 이름 build : 이미지 빌드가 필요한 경우 지정 (도커파일 경로 지정) image : 원하는 이미지 지정 기존 이미지가 있는 경우 그대로 사용 (e.g. hitchecker:1.0.0) 없거나 --build 옵션 적용할 땐 build 경로의 Dockerfile 사용해 이미지 빌드 e.g. docker build -t hitchecker:1.0.0 ./app 이미지 재빌드 : 이미지 태그를 바꾸기 or --build 옵션 사용 기존 이미지도 없고 build 경로도 없는 경우, 외부 이미지 다운 ports : -p 옵션과 동일 (포트 포워딩) volumes : 마운트할 볼륨 지정 볼륨명 : 컨테이너내부경로 environment : 환경변수 지정 키 : 밸류 : 기본방식 <<: *common_environment : x-environment의 공통 환경변수 주입 depends-on : 특정 컨테이너가 실행될 때까지 컨테이너 실행 보류 없으면 모든 컨테이너가 병렬 실행 다만, 이렇게 지정해도 프로세스 실행 속도 차이로 문제 발생 가능 -> 대신 물리적으로 일정 시간을 정해두는 방법이 좋을 수도 있음 volumes : 생성할 볼륨의 리스트 x-environment: &common_environment : 공통 환경변수 지정 (도커 컴포즈 버전 3 이상) Reference 개발자를 위한 쉬운 도커

Infrastructure · 2025-02-04

도커(Docker)Dive - 실무 적용 팁

레이어 관리 이미지의 크기를 줄이면 네트워크 비용을 감소시키고 빌드 속도를 향상시킬 수 있음 RUN 지시어 관리 (불필요한 레이어를 줄이기) 레이어 쌓는 지시어 하나 당 레이어가 추가됨 &&를 활용해 최대한 레이어 하나로 처리하자 -> 불필요한 레이어 감소 e.g. RUN을 5번 사용하면 레이어가 5개 쌓이는데 비해, 레이어를 1개만 쌓이게 할 수 있음 RUN apt-get update && \ apt-get install -y curl && \ apt-get install -y xz-utils && \ apt-get install -y git && \ apt-get clean 애플리케이션의 크기를 작게 관리하기 불필요한 기능 줄이기 큰 모듈을 여러 모듈로 분리하기 가능한 작은 크기의 베이스 이미지 사용하기 가능한 alpine OS 사용 (e.g. 우분투 이미지 70MB, 알파인 이미지 8MB) FROM alpine:latest RUN apk update && \ apk add --no-cache curl && \ apk add --no-cache xz && \ apk add --no-cache git 극단적으로 줄이고 싶다면 스크래치 이미지 활용 (FROM scratch) 스크래치 이미지 모든 이미지의 뿌리가 되는 이미지 이미지 빌드를 위한 최소한의 파일만 포함 스크래치 이미지 위에서 필요한 것만 패키징 -> 보안 향상, 이미지 크기 감소 e.g. # 빌드 스테이지 FROM golang:alpine AS builder WORKDIR /app COPY main.go . RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o helloworld main.go # 운영 스테이지 FROM scratch COPY --from=builder /app/helloworld . EXPOSE 8080 ENTRYPOINT ["./helloworld"] 빌드한 GO 언어 프로그램은 아무것도 없는 스크래치 이미지에서도 실행 가능 -> 정적 바이너리 파일 (리눅스용 바이너리 파일) GO 언어는 이미지 크기를 작게 구성하는데 매우 좋은 방법! MSA에서 하나의 컨테이너 크기를 줄이는 것이 중요한 미션 -> GO 언어의 장점 .dockerignore 로 이미지에 불필요한 파일이 섞이지 않게 관리하기 빌드 컨텍스트로 이동할 파일을 관리 e.g. COPY . . 명령어 등으로 디렉터리 전체 복사할 경우 유용 캐싱을 활용한 빌드 도커는 Dockerfile 각 지시어 단계의 결과 레이어마다 캐시 처리 다음 빌드에서 동일한 지시어 및 처리 내용을 사용하면, 캐시된 레이어 그대로 사용 (새 레이어 생성 X) e.g. 동일한 지시어인데 처리 내용이 다른 경우 동일한 지시어 COPY . . -> 빌드 컨텍스트의 소스코드 변경 O -> 새로 레이어 생성 레이어 변경이 있다면 해당 레이어와 그 이후의 모든 레이어는 새로 레이어 생성 (캐시 사용 X) 전략: 변경되지 않는 레이어들을 아래에 배치해 캐시 빈도 높이자 (e.g. 라이브러리 설치 레이어) 3-Tier 아키텍처 구성 문제: 백엔드 API는 프론트만 접근하고 클라이언트에 노출되면 안됨 해결책: Nginx 프록시 기술을 활용해 보안이 뛰어난 3-Tier 아키텍처 구성 가능 즉, 클라이언트는 웹서버만 접근 가능하고 백엔드 애플리케이션 접근은 불가능 Nginx 프록시는 특정 경로로 온 요청을 지정한 서버로 전달 (by Nginx 서버 설정) 보안 향상, 부하 관리, API 응답 캐시 등 가능 e.g. /api/ 경로로 온 요청을 애플리케이션 서버로 전달하도록 Nginx 서버 설정한 경우 http://localhost/index.html -> 웹서버의 정적 파일을 응답 http://localhost/api/~ -> 애플리케이션으로 요청 전달 (데이터 접근) DB 이중화 DB 서버의 고가용성을 위해 적용 방법 동시에 같은 볼륨 사용하기 구성이 간단하지만 불륨의 문제가 생기면 대처하기 어려움 볼륨 성능에 부하가 발생할 수 있음 컨테이너마다 별도의 볼륨 사용하기 데이터 동기화 처리를 별도로 해야 함 동기화 방법 (DB 서버가 제공) Primary-Standby Replication 하나의 Primary 서버에 여러 Standby 서버를 연결 Primary 서버는 읽기/쓰기, Standby 서버는 읽기만 가능 쓰기가 실행되면 데이터는 즉시 Standby 서버로 복제됨 Primary-Primary Replication 모든 DB 서버는 Primary 서버 모든 서버가 읽기/쓰기 가능 여러 서버에서 쓰기가 일어나므로, 동기화 구성 작업이 조금 더 복잡 컨테이너 애플리케이션 리소스 최적화 도커는 가상화 기술이므로 컨테이너마다 사용 가능 리소스를 제한 가능 적정 리소스량은 운영 경험과 테스트를 통해 결정 사용량 초과 시 CPU limit 초과 -> CPU 스로틀링 발생 -> 애플리케이션의 성능 저하 발생 CPU 스로틀링: 시스템이 애플리케이션의 CPU 사용을 제한 Memory limit 초과 -> OOM(Out of Memory) Killer 프로세스 실행 -> 컨테이너 강제 종료 자바 가상 머신 (JVM) 튜닝 JVM의 메모리 중 힙 메모리는 애플리케이션 사용량 증감에 가장 큰 영향을 받음 보통 전체 서버 메모리의 50~80%로 설정 (자바 실행시 설정) e.g. java -jar -Xmx=4G app.jar (힙 메모리 최대값을 4G로 지정) 자바 힙 메모리 자동 설정 # JVM 튜닝을 위한 환경변수 추가 ENV JAVA_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap" 컨테이너 메모리 변경에 맞게 애플리케이션 실행 시 자바 최대 힙 메모리를 자동 조정 자바 기능 자바 10버전 이상은 기본 활성화 애플리케이션 시작 시 -Xmx 옵션을 지정하면 자동조정은 없음 자바 10버전 미만일 경우 도커파일에 해당 옵션 지정 컨테이너 내 IDE 개발환경 구성하기 컨테이너 내부에 IDE 개발환경을 구성하는 것의 장점 로컬 PC에 라이브러리나 런타임 설치 없이 깔끔하게 유지 가능 개발자 한 명이 여러 프로젝트에 참여할 때, 개발 PC를 도커만 설치된 상태로 깔끔하게 관리 개발자들의 개발 환경을 일관적으로 유지하고 표준화 가능 같은 프로젝트를 개발하는 팀원끼리 설정 차이로 발생하는 문제를 예방 VSCode 컨테이너 내부에서 VSCode를 실행해 사용 가능 개발용 컨테이너 내 소스코드는 볼륨을 사용해 Host OS의 실제 소스코드를 마운트 방법 익스텐션 설치하기 Docker (MicroSoft) Dev Containers (MicroSoft) .devcontainer 디렉터리 생성 devcontainer.json : VSCode가 새로운 개발환경을 만들 때 사용하는 파일 name : 개발 환경의 이름 dockerFile : 개발 환경 구성에 필요한 도커 파일 이름 forwardPorts : docker run 의 -p 옵션과 동일 customizations : 개발 환경 내 VSCode 실행 시 적용할 extension, 세팅 정보 등을 설정 postCreateCommand : 컨테이너 생성 후 실행할 커맨드 입력 (도커파일 CMD) remoteUser : 컨테이너 안에서 사용할 기본 사용자 지정 Dockerfile : 개발을 수행할 컨테이너 정의 명령어 팔레트에서 Dev Containers: Open Folder in Container 실행 IntelliJ (유료 버전만 가능) VSCode와 달리 로컬 PC에서 IntelliJ를 실행 (애플리케이션 실행 및 디버깅에만 컨테이너 활용) 소스코드와 도커파일을 사용해 자바 실행 이미지를 빌드하고 실행 JDK 버전 별 사용이 편리하기 때문에, 완전한 컨테이너 환경 내 개발이 아니어도 보완이 됨 로컬 PC가 완전히 클린하진 않지만, 개발자들의 개발 환경 일관성 유지가 가능 Run/Debug Configuration 을 생성해서 컨테이너 내 개발환경 구성 실행 버튼 자동으로 docker build로 이미지를 빌드하고 docker run으로 컨테이너를 실행 디버그 모드 JDK는 기본적으로 디버깅 기능을 제공하나 컨테이너에서 실행중인 애플리케이션을 디버깅하려면 원격 디버깅 기능 사용해야 함 방법 IntelliJ IDEA - Settings - Plugins -> 검색으로 Docker 확장 설치 상단 Edit configurations - Run/Debug Configurations 진입 실행 환경 추가 Add New Configurations -> Dockerfile 선택해 설정 생성 IntelliJ와 연동할 도커 데몬 선택 : Server 옆 ... -> Name 및 Docker for Mac 지정 Dockerfile : 이미지 빌드에 사용할 도커 파일 경로 지정 (기본값으로 두기) Image tag : 빌드될 이미지의 태그 지정 (e.g. dev) Container name : 빌드된 이미지를 사용해 실행할 컨테이너의 이름 지정 Add Run Options로 옵션 추가 가능 e.g. Port Binding = -p -> 8080:8080 e.g. Environment variables = -e -> DB_URL=postgres e.g. Run Options -> --network leafy-network Debug 환경 추가 (기본 5005번 포트로 자바가 원격 디버깅) Add New Configurations -> Remote JVM Debug 선택해 설정 생성 Name 지정 (e.g. LocalDevContainerDebug) Before Launch - + - Run Another Configuration - 앞서 만든 컨테이너 실행 환경 지정 앞서 만든 컨테이너 실행 환경에 Add Run Options 추가 포트 포워딩 5005:5005 추가 Command - -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 -jar leafy.jar 추가 (자바 애플리케이션을 디버깅 용으로 시작하는 옵션) DevOps & CI/CD & Github Actions DevOps의 목표는 개발 환경과 운영 환경의 차이를 줄여 서비스의 퀄리티를 높이고자 함 컨테이너, CI/CD, 자동화, MSA, IaC 등이 DevOps가 지향하는 기술 CI/CD 파이프라인 소스코드에서 배포 환경 관리까지의 모든 프로세스를 자동화하는 것 (소스코드가 물처럼 흘러감) 파이프라인이 없을 경우의 단점 사람이 직접 빌드 및 배포 수행하여 휴먼 에러 및 표준화의 어려움이 발생 자동화 이전에는 각각의 단계를 개발자, 운영자, QA, 테스터가 따로 진행했음 배포 시간이 매우 길어지고 복잡 CI(Continuous Integration): 지속적 통합, 배포가능한 아티팩트(Jar/Image)를 빌드하는 단계 e.g. 컨테이너 환경이라면 이미지를 빌드하고 푸시하는 단계의 자동화 CD(Continuous Deployment) : 지속적 배포, 실제 환경에 아티팩트를 배포하는 단계 GitHub Actions 파이프라인을 구성하고 자동화할 수 있는 GitHub 제공 기술 빌드용 서버를 빌려주므로 별도의 서버 없이 쉽게 파이프라인을 실행할 수 있음 방법 GitHub에 소스코드를 푸시하면 GitHub Actions에서 CI/CD 자동 실행 .github/workflows의 yml 파일을 GitHub이 자동으로 인식해서 파이프라인 실행 용어 러너(Runner) : 파이프라인(워크플로우)이 실제로 실행되는 서버 워크플로우(Workflow) 서버에서 실행되는 파이프라인의 실제 작업들 워크플로우 = 파이프라인 = .github/workflows 내 파일 1개 관계 하나의 워크플로우는 여러 개의 작업(Jobs)으로 이루어짐 하나의 작업은 여러 개의 스탭(Steps=Action)으로 이루어짐 트리거를 통해 워크플로우 자동 실행 가능 트리거(Trigger) : 조건을 설정해 충족하면 워크플로우를 자동 실행 e.g. 소스코드 푸시, 특정 시간(매일 8시)… 기본 문법 (YAML 형식) 기본 템플릿 runs-on : Runner 지정 특별한 경우가 아니면 ubuntu-latest 지정 작업마다 러너를 다르게 지정 가능 트리거 문법 스텝 문법 러너에 소스코드를 다운하기 (소스코드가 필요한 작업의 경우 사용) 도커 buildx 활성화 (도커 제공 스탭) 기본 러너에는 도커는 설치되어 있지만, buildx 기능은 비활성화되어 있음 buildx를 활성화하면 멀티플랫폼 빌드, 캐싱 등의 기능 제공 도커 로그인 정보 생성 스탭 러너에 도커 허브에 접속할 수 있는 로그인 정보 파일 생성 깃허브 시크릿에 키와 값 형태로 저장해 적용 Github의 프로필의 Settings - Developer Settings - Personal access tokens - Tokens (classic) - Generate new token (classic) - scope (repo, workflow 선택) - Generate token Repo의 Settings - Secrets and variables - Actions - New Repository Secret에 키-밸류 쌍 지정 DockerHub의 Account Settings - Personal access tokens - New Access Token - permission 선택 (Read, Write, Delete 혹은 적합한 것) - Generate Token - 토큰을 복사해 도커 허브에 로그인하기 위한 토큰으로 사용 도커 빌드 푸시 액션스 (소스코드를 사용해 이미지를 빌드하고 레지스트리에 푸시) 이미지는 CPU 아키텍처가 다르면 실행 불가능 buildx를 통해 멀티플랫폼 빌드를 활성화하면, MacOS 이미지도 리눅스에서 사용 가능 Reference 개발자를 위한 쉬운 도커

Infrastructure · 2025-02-03

도커(Docker)Dive - 멀티 컨테이너 관리

클라우드 네이티브 애플리케이션 (Cloud Native Application) 클라우드 다른 회사의 서버를 빌려서 운영 퍼블릭 클라우드: 누구나 사용할 수 있는 클라우드 서비스 (e.g. Azure, AWS, GCP) 프라이빗 클라우드: 특정 조직만 사용할 수 있는 클라우드 서비스 (e.g. 조직 내 계열사) 보안과 비용이 보다 효율적 특징 요청 즉시 서버를 생성 (Provisioning) 스토리지 저장소에 가상화 기술을 활용 사용자가 서버를 구매할 때마다 스펙에 맞는 VM을 만들어 제공 사용 시간만 비용 지불 (직접 서버를 운영음 비용이 매우 큼) 현대 애플리케이션의 다양한 문제를 해결 확장성 (Scalability) : 트래픽 증가에 유연하고 빠르게 대처 복원력 (Resilience) : 장애 발생 시 빠르게 복구 e.g. 서울 데이터 센터에 장애가 났을 때 부산 데이터 센터의 서버로 트래픽 전환 (Disaster Recovery, 복구에 사용하는 서버) 효율적인 운영 비용 처리 : 전문 아키텍트의 적절한 서버 구성과 끊임없는 최적화 필요 -> 클라우드는 시작점이고 애플리케이션이 클라우드에 적합하지 않으면 큰 의미 없을 수 있음 클라우드 네이티브 애플리케이션 클라우드 환경을 더 잘 활용할 수 있는 애플리케이션 구조 필요 사항 MSA: 트래픽 증가에 빠르게 대처하기 위해선 애플리케이션이 MSA 구조로 개발되어야 함 컨테이너: 컨테이너를 활용해 실행 환경에 종속되지 않는 동작을 보장해야 함 무상태 (Stateless): 상태를 가지지 않는 애플리케이션 서버는 어디에나 즉시 배포 가능 DevOps 및 CI/CD: 배포가 자동화되어야 하고 릴리즈가 빠르게 수행되어야 함 모놀리식과 MSA 잘 활용하면 클라우드 네이티브 애플리케이션으로서의 장점이 커서 MSA로 많이 전환하는 추세 모놀리식 모든 기능을 하나의 애플리케이션에 구성 수직 확장(Scale-Up) 주로 사용 장점 초반 개발 속도가 빠르다가 코드 베이스가 커질수록 느려짐 복잡성이 낮음 단점 트래픽 대처 능력 감소 하나의 애플리케이션 크기가 큼 애플리케이션 실행 시간이 오래 걸림 개발에 들어가는 빌드 시간 및 배포 시간도 오래 걸림 서버 확장 시 비효율적인 리소스 사용 실제 트래픽은 주문 기능에서만 나는데 상품관리, 회원관리도 함께 확장됨 MSA 도메인이나 기능별로 모듈을 분리해 서버 배포 수평 확장(Scale-Out) 주로 사용 장점 각각의 모듈의 크기가 감소해 서버 스케일 아웃 시간 빠름 스케일 아웃 시 효율적인 리소스 사용 트래픽이 늘어난 모듈만 서버 스케일 아웃 가능 모듈별로 완전히 독립됨 각각 다른 언어로 개발 가능 기능 장애 발생해도 다른 모듈에 영향 방지 가능 단점 초기 구성이 복잡하고 오래 걸림 복잡성이 높음 네트워크 기본 전세계가 물리적 케이블을 통해 전기 신호로 정보를 주고 받음 (먼 해외는 해저 케이블 사용) IP 전 세계 인터넷상에서 유일한 주소 (동적 IP는 시간에 따라 변하지만 여전히 유일) 회선 당 하나 배정하므로 한 회선(공인 IP)을 사설 IP로 나눠 여러 기기가 동시에 IP 사용 가능 공인 IP: 집주소, 전세계에서 유일 사설 IP: 방번호, 소속된 네트워크 장비(공유기) 내에서 유일 사설 IP 주소 대역 (아래 범위 해당하는 주소는 모두 사설 IP) 10.0.0.0 — 10.255.255.255 (Class A) 172.16.0.0 - 172.31.255.255 (Class B) 192.168.0.0 — 192.168.255.255 (Class C) 공유기: 공인 IP를 사설 IP로 분리하는 장치 e.g. IP Time WAN 포트: 공인 IP를 받는 인터넷 선을 꽂는 부분 LAN 포트: 각각의 기기를 연결해서 사설 IP를 분배하는 곳 기업 네트워크 (아래보다 더 복잡) 공인망: 공인 IP 끼리 사용하는 네트워크 통신망 사설망: 라우터를 사용해 만들어진 내부 네트워크 통신망 (사설 IP 사용, 실제 서버에게 할당) 라우터: 공유기와 비슷한 역할 네트워크 인터페이스 인터넷에 연결하기 위해 컴퓨터에 장착하는 부품 중 하나 네트워크 인터페이스마다 IP를 할당 (사설 IP) 하나의 기기에는 한 개 이상의 네트워크 인터페이스 장착 가능 e.g. 노트북 (유선 인터페이스, 무선 인터페이스) 포트 서버에 있는 프로세스들 중 어떤 프로세스에 데이터를 전달할지 지정 IP 뒤에 : 붙여 지정 (e.g. 192.168.0.5:8080) 물리적 존재 X, 서버 안에서 정의해 사용 네트워크를 사용하는 프로그램은 실행될 때 자신이 사용할 포트를 지정 Well-Known 포트: 사전에 약속되어 있는 포트 e.g. 웹서버 통신(80, 443), SSH(22), FTP(21) 네트워크 통신 아웃바운드 : 자신의 서버에서 출발하는 통신 인바운드 : 외부 서버에서 자신의 서버로 오는 통신 NAT (Network Address Translation) - 아웃바운드 통신에 사용 매핑 테이블 활용해 공인 IP와 사설 IP를 매핑해주는 기술 공인 IP의 랜덤한 포트를 여러 개 지정해두고 각각의 포트에 사설 IP 정보 매칭 사설망을 구성하는 라우터가 항상 가지는 기능 (자동 설정) 동적으로 정보를 관리하므로 외부에서 서버로 접근할 때는 혼란이 생김 (인바운드 통신) NAT 테이블 예시 아웃바운드 통신 발생 시 해당 사설 IP 주소 및 포트와 공인 IP 주소 및 포트를 저장 공인포트번호는 랜덤 지정 외부 서버는 공인 IP 주소 124.111.46.91:10001을 출발지로 알고 응답을 보냄 라우터는 돌아온 정보를 NAT 테이블에서 192.168.0.4:80으로 응답을 보냄 포트 포워딩 (Port Forwarding) - 인바운드 통신에 사용 외부에서 사설망으로 접근할 때 사용하는 NAT 테이블 같은 매핑 정보 관리 기술 외부에서 공인 IP에 접근하면 포트 포워딩 룰에 맞는 사설 IP로 변환해 트래픽 전달 사용자가 직접 지정 포트포워딩 예시 외부 서버에서 공인 IP 주소 124.111.46.91:80으로 요청 보냄 포트 포워딩 룰에 따라 요청은 사설 IP 192.168.0.4:80으로 보내짐 DNS (Domain Name System) 도메인 주소와 공인 IP를 매핑해주는 기술 (도메인명 <-> IP 주소) 일반적인 엔터프라이즈 환경에서는 사내망에서 별도로 DNS 서버를 운영하기도 함 사내 서버들끼리 도메인으로 통신할 수 있도록 정보 제공 DNS 서버 주소도 내부 DNS 서버의 IP로 지정 DNS 예시 devwiki-docker.com으로 요청을 보냄 IP 주소가 8.8.8.8인 DNS 서버에 질문을 던져 도메인 주소에 해당하는 IP 주소 받음 요청은 124.111.46.91로 전달됨 도커 가상 네트워크 가상 네트워크: 한 대의 서버 내에서 논리적으로 여러 네트워크를 구성하는 기술 물리적 네트워크 망에는 네트워크 인터페이스로 공인 IP 혹은 사설 IP가 할당된 PC(서버)가 존재 해당 서버 내에 가상 네트워크 구성 SDN(Software Defined Network)라고도 함 도커는 가상 네트워크 기술을 활용해 컨테이너 네트워크를 구성 e.g. 외부와 컨테이너의 통신, 컨테이너와 컨테이너의 통신 가상 네트워크 생성 과정 도커 설치 및 실행 시 다음 2가지 생성 브릿지(docker0): 가상 공유기 가상의 IP 주소를 할당 받음 (일반적으로 172.17.0.1) 가상의 IP 주소: 서버 내 논리적으로 정의된 IP (실제 존재 X) 브릿지 네트워크: 가상 네트워크 컨테이너 실행 시 브릿지 네트워크의 IP 주소 범위 내에서 가상의 IP 주소 할당 e.g. 172.17.0.2, 172.17.0.3, 172.17.0.4, 172.17.0.5 마치 공유기를 통해 사설 IP 할당되는 것과 비슷 같은 브릿지에서 생성된 컨테이너는 브릿지를 통해 서로 통신 가능 도커는 여러개의 브릿지 네트워크 구성도 가능 네트워크 신호 전달 과정 서버(PC)는 물리 네트워크 인터페이스에 인터넷 선을 연결해 공인 IP 혹은 사설 IP를 할당받음 해당 서버 내 도커 설치 후 실행 시 도커는 호스트 OS에 가상 인터페이스 1개 생성 (docker0) 컨테이너 실행 시 호스트 OS에 각각 컨테이너에 해당하는 가상 인터페이스들 생성 (Veth고유번호) 전달: 물리 인터페이스 -> 호스트 OS -> 컨테이너 가상 인터페이스 -> 컨테이너 가상 인터페이스 간 통신은 iptables를 활용해 규칙을 정의하고 소프트웨어적으로 패킷 전달 iptables Linux OS의 패킷 필터링 시스템 내부 네트워크 트래픽 제어 및 라우팅 규칙 정의 특정 IP 주소로 네트워크를 보냈을 때 어떤 인터페이스로 전달할지에 대한 규칙 설정 e.g. 규칙: 172.17.0.3으로 향하는 요청은 Veth2 인터페이스로 전달하자 물리 네트워크 였다면, 네트워크 장치들이 알아서 해줌 참고: 호스트 OS -> 물리적 인터페이스 1개 : 가상 인터페이스 여러개 = 하드웨어 : 소프트웨어 가상 네트워크와 외부 통신 (포트포워딩) 아웃바운드 통신은 가상 네트워크가 알아서 NAT 사용 인바운드 통신은 요청이 원하는 컨테이너의 포트로 전달되도록 직접 포트포워딩 옵션 지정 HOST OS의 포트는 아무거나 지정해도 상관 X 이미 등록된 포트는 중복 불가 의도적으로 포트포워딩을 하지 않으면, 컨테이너 간 통신만 허용 e.g. DB 서버는 포트포워딩 없이 컨테이너 간 통신만 허용하여 외부 통신을 막음 도커 DNS 직접 생성한 브릿지 내 컨테이너가 사용할 수 있는 기본 DNS 서버 제공 (기본 브릿지 제외) 컨테이너 이름이 도메인으로 자동 저장됨 e.g. containerA - 10.0.02, containerB - 10.0.03 컨테이너 간의 통신에 중요! -> 컨테이너 IP는 컨테이너 재시작 시 계속 바뀔 수 있어 불편 외부 DNS 서버와 연동되어 있어, 컨테이너 외부 도메인으로도 접근 가능 (e.g. 구글) 도커 네트워크 드라이버 브릿지 네트워크 (Bridge) 도커 브릿지를 활용해 컨테이너 간 통신 지원 NAT 및 포트포워딩 기술을 활용해 외부 통신 지원 호스트 네트워크 (Host) 호스트 네트워크를 공유해 모든 컨테이너가 호스트 머신과 동일한 IP 사용하도록 지원 호스트 네트워크와 포트 중복 불가능 오버레이 네트워크 (Overlay) 호스트 머신이 다수일 때 하나의 네트워크처럼 사용하도록 지원 (Kubernetes에서 사용) Macvlan 네트워크 컨테이너에 MAC 주소를 할당해, 물리 네트워크 인터페이스에 직접 연결 스토리지와 볼륨 컨테이너의 중요한 속성: Stateless (무상태) 컨테이너는 상태가 없음 컨테이너 실행 후 모든 변경 사항은 컨테이너 레이어에만 존재 불변성: 모든 상태는 이미지에 기록되고 이미지는 한 번 지정된 후 변경되지 않음 컨테이너 상태 변경(e.g. 소프트웨어 버전 변경)이 필요하면 새 버전의 이미지 제작 후 배포 장점 여러 컨테이너를 다른 여러 환경에서 빠르게 배포 가능 트래픽이나 장애에도 컨테이너를 쉽게 생성해 빠르게 대처 제약 상태가 없으므로 데이터는 무조건 외부에 저장해야 함 데이터 영구 저장을 위해서는 DB 서버 사용이 필수 사용자 세션 정보나 캐시 같은 정보는 캐시 서버나 쿠키를 통해 관리 e.g. 사용자 로그인 정보, 장바구니 상품 리스트 동일한 요청은 항상 동일한 결과를 제공해야 함 같은 이미지로 생성한 모든 서버에서 같은 응답을 제공해야 함 컨테이너 실행 시점에 설정을 외부에서 주입할 수 있어야 함 환경 변수나 구성 파일을 통해 다양한 환경에서 컨테이너 이미지를 활용 가능 도커 볼륨 (Docker Volume) 데이터를 보관하기 위해 도커가 관리하는 외부 공유 저장소 호스트 OS의 서버 특정 공간에 저장 (e.g. /volumes/volume1) 볼륨 저장 경로에 사용자가 직접 접근하기는 어려움 경로는 리눅스에서는 관찰 가능, MacOS 등은 관찰 불가 도커가 가상머신 형태로 실행되어 경로를 자동 관리하고 가상머신 안에 저장하기 때문 컨테이너가 삭제되도 볼륨은 남아있음 볼륨 마운트 컨테이너들은 컨테이너의 특정 경로를 도커 볼륨에 마운트해서 사용 즉, 컨테이너의 특정 폴더는 공유용 폴더 e.g. PostgreSQL PostgreSQL은 /var/lib/postgresql/data 경로에 실제 DB 데이터 저장 해당 경로를 도커 볼륨에 마운트 해당 경로에 저장하는 파일들은 컨테이너 레이어가 아니라 외부 볼륨에 저장 여러 컨테이너는 1개의 볼륨을 공유해 동일한 데이터를 제공할 수 있음 컨테이너가 삭제되거나 새 컨테이너가 생성되어도 데이터 영속성 보장 볼륨과 컨테이너의 관계 여러 컨테이너에 하나의 볼륨 마운트 가능 하나의 컨테이너에 여러 개의 볼륨 마운트 가능 바인드 마운트 (Bind Mount) 도커가 자동 관리에서 벗어나 Host OS에서 데이터를 직접 관찰 가능 (볼륨 X) 방법: -v 옵션에서 볼륨 이름 대신 사용자 지정 경로를 전달 디버깅에 유용 볼륨은 마운트한 컨테이너가 없을 때만 삭제 가능 컨테이너의 무상태와 서버 관리 방법론 Pet 방식 (전통적 서버 방법론) 서버 한 대 한 대를 소중히 직접 관리하는 방식 서버 에러 및 종료를 서비스 장애로 간주 서버가 상태를 가져서 교체가 어려움 e.g. Monolithic, OnPremise Cattle 방식 컨테이너를 활용한 서버 방법론 (서버는 소모품) 서버 에러 및 종료가 충분히 일어난다고 가정 문제 서버 삭제 후 빠르게 새 서버를 생성해 대체하는 방식으로 해결 서버의 상태를 최대한 제거해 빠르게 교체 가능하도록 함 e.g. MSA, WEBAPP 마운트 컴퓨터의 특정 디렉토리를 외부 저장소와 연결하는 것을 말한다. NFS(Network File System)는 PC의 특정 폴더 혹은 드라이브 단위를 NFS에 마운트 시킬 수 있고, 여러 컴퓨터가 접근할 수 있습니다. 도커 컴포즈 (Docker Compose) 여러 개의 도커 컨테이너를 편리하게 관리하는 도구 여러 개의 컨테이너를 하나의 파일에 정의해 복잡한 애플리케이션 구조를 관리 e.g. 서비스 간 의존성, 도커 네트워크 특징 YAML 문법으로 IaC 적용 (docker-compose.yml) 도커 데스크탑 설치 시 기본 제공 도커 컴포즈의 서비스 = 컨테이너 디폴트로 네트워크를 생성해 컴포즈 파일 내 컨테이너들을 포함시킴 e.g. --network leafy-network 장점 여러 개의 컨테이너를 한 번의 명령어로 실행 혹은 종료 가능 (docker compose up) 로컬 개발 환경에서 활용이 편리 (실제 운영과 비슷한 환경을 빠르게 구성 가능) YAML 문법 (YAML Ain’t Markup Language, YAML은 마크업 언어가 아니다) JSON 같은 데이터 표현 형식 중 하나다. 상대적으로 최근에 나온 포멧으로 가독성에 더 초점을 맞춰 간결하다. JSON이 {} 와 "" 와 , 등이 필수인 반면, YAML은 띄어쓰기 기반으로 정보를 구분한다. 예시로, 띄어쓰기와 -로 리스트와 객체를 표현할 수 있다. 정의서 작성과 같은 사용자가 직접 파일을 작성하는 방식에 많이 쓰인다. (Docker, Kubernetes) Reference 개발자를 위한 쉬운 도커

Infrastructure · 2025-01-24

2024년 회고록

머리말: 2024년 1월 20일 1월 20일. JVM 생태계로 옮겨가자고 마음 먹었던 날이다. 2년차 개발자로서 그에 맞는 기본기를 갖추길 강하게 바라서 정했다. 더 알고 싶다. 프로페셔널하게 잘하고 싶다는 열망이 강했다. 선배 개발자들이 쌓아 놓은 길이 풍부하니, 차근차근 밟아 가다보면 많은 것이 채워지리라 생각했다. 이에 더해, 전체적인 삶도 더 건강하게 채워보기로 노력했다. 언제나처럼 한 해가 빠르게 지나갔다. 지난 시간의 결과들을 되돌아보고 올 해 목표를 새로 설정한다. 정형화된 것보단 내가 쓰기 편한 형태의 1년 회고를 남긴다. 생활 습관 2024년을 시작할 때 꼭 지켰으면 했던 몇 가지를 정했다. 어떤 것은 초과 달성했고 어떤 것은 조금 더 잘했으면 하는 아쉬움이 있다. 책 21권 24년 목표: 20권 24년 결과: 21권 25년 목표: 30권 1권 초과 달성으로 마무리했다. 아주 많다고 할 수는 없지만 달성한 보람이 크다. 접근성을 최대한 높여 한 번이라도 책을 더보게끔 유도했다. 독서용으로 구매한 아이패드 미니가 충분한 역할을 했다. 휴대성 덕분에 버스나 지하철안에서 한 번이라도 더 보게 되고, 자기전에도 한 번 더 손을 뻗고 읽게 된다. 먼지 타면 손이 잘안가서 최대한 전자책을 지향했는데 이것도 나한텐 효과적이었던 것 같다. 그리고 노션으로 서재를 만들어 정리하는 습관을 들였다. 시각적으로 내 서재를 볼 수 있으니 달성감이 생기고 짧게라도 정리하니 기억에 더 남는다. 내 서재 상반기에 비해 하반기에 독서 속도가 많이 느려졌던게 아쉬웠다. 특히, 기술 서적 읽을 때는 아무래도 시간이 걸리면서 상대적으로 텐션이 떨어지는데, 25년에는 더 전략적으로 시간을 분배해봐야겠다. C-Level 분들의 연평균 독서량이 30권 이상이라는 기사가 있었다. 1달에 2권만 읽어도 24권인데 대단하다고 생각이 든다. 2025년에는 30권을 목표로 한다. 물론 단순 물량보다 실질적인 것이 중요하다. 잘 모르는 영역이 많은데, 25년에는 생활 법률이나 우주 카테고리에 대해서도 좀 더 관심을 가지려 한다. 특히, 투자 쪽은 작년보다 조금 더 깊게 공부할 계획이다. 주 3~4회 운동 24년 목표: 체지방률 15% 24년 결과: 체지방률 18.8% 25년 목표: 체지방률 15% 운동을 시작한지 1년 6개월이 지났다. 체지방률 26%에서 시작했고 근육량 2kg 증가, 체지방 5.5kg 감소시켜 체지방률 18%대에 진입했다. 주 3~4회씩 꾸준히 운동했던 점은 뿌듯한데, 목표에 3%가량 못미친 결과는 아쉬움이 남는다. 좋았던 기억은 애정하는 몇 가지 운동들의 최대 기록들이다. 턱걸이 횟수는 10개를 넘어갔다. 최대 16개를 했는데, 한 번도 못했던 옛날을 생각하면 정말 큰 발전이다. 벤치프레스 70kg을 찍은 것도 정말 기뻤다. 1RM이어서 아슬아슬했지만, 큰 성취감을 느꼈다. 기록을 위해 몇가지 최대 기록을 남겨둔다. 운동 최대 무게(횟수) 벤치프레스 70kg 풀업 16회 레그프레스 160kg 스쿼트 70kg 밀리터리 숄더프레스 40kg 어려웠던 점은 정체기다. 처음 3개월 PT로 배운 후 혼자 운동해나갔다. 1년 정도 철저한 식단과 함께 주 3~5회 운동을 했는데, 벌크업과 살찜 사이(?)의 균형을 찾는게 어려웠다. 지금은 무리한 섭취보다 체지방 조절을 가장 우선하고 있고, 체지방률이 감소하는 걸 보며 보다 건강한 느낌을 받고 있다. 사이사이 어깨 부상도 힘들었다. 잘못된 숄더프레스 및 벤치프레스 자세로 오른쪽 어깨가 반복적으로 문제가 생겼다. 처음엔 원인도 몰라서 관련될 법한 운동 영상, 의학 영상을 모조리 찾아본 기억이 난다. 시행착오 끝에 올바른 운동 자세를 찾으니 부상이 더이상 없더라. 신기한 경험이었는데, 운동은 자세가 정말 중요함을 체감했다. 어느덧 2년차도 넘어가니 여러 생각이 든다. 무리하지 않는 건강하고 꾸준한 운동이 제일인 것 같다. 25년 목표는 한번 더 체지방률 15% 달성이다. 다시 온 정체기를 뚫는게 올 해 목표가 될 것이다. 새벽 기상과 공부 패턴 새벽 기상이 일상에 많이 스며 들었다. 최소 7시간 수면 확보를 기준으로 일찍자고 일어났다. 요즘은 5시 50분으로 정착했다. 4시 50분 / 5시 50분 / 6시 30분 등 몇 가지 기상 패턴들이 다양하게 있었는데, 결과적으로 일찍 일어났을 때 조용한 환경으로 인해 집중도와 작업 진척도가 더 늘어나는 효과가 있었다. 모든 날을 완벽히 보내진 못했다. 4달은 새벽기상, 2달은 보다 늦은 기상, 3달은 다시 새벽기상 식의 반복이 있었다. 이런 부분은 크게 스트레스 받지 않으려 한다. 몸이 피곤하다는 신호가 있을 때는 충분히 자는게 건강에 이로운 것 같다. 올 해 기상 패턴도 5시 50분으로 늦춤 없이 그대로 유지해보려 한다. 추가로 습관 추적을 위해 하루 공부량을 측정하는데, 나무 심기가 재미를 준다. 개인적으로 Forest 앱을 좋아하는데, 매일 집중한 시간만큼 자신이 좋아하는 나무를 심을 수 있다. 나도 몰랐던 나무 취향(?)도 알게 됐다. 습관 추적은 많은 자기계발서에서 추천하는 방법이다. 습관 추적을 지원하는 다양한 앱 중 성숙한 서비스를 제공해서 추천한다. 포레스트 (Forest) 개발 공부 사실 한 해 동안 공부했던 모든 것들이 너무 유익했다. FastAPI 생태계에 있을 때는 어려웠던 레퍼런스 천국을 자바 생태계에서 경험했다. 선별한 강의와 책을 보면서 예제 코드를 백문이 불여일타하고 이론은 옵시디언을 활용해 학습기록용 블로그에 정리하고 있다. 회독법으로 접근하고 있다. 결국 4~5회독은 해야 장기 기억으로 완전히 남을 것이다. 지금까지 봤던 강의와 책은 최소 2회독한 상태이고, 새로운 것들을 계속 공부하면서 회독도 지속적으로 병행할 계획이다. 한 해 공부했던 책, 강의, 자격증 기록을 남겨본다. 기술 서적 24년에 읽은 기술 서적들이다. 사실 읽고 싶은 책이 더 많았는데 시간이 참 빠르게 지나간다. 기술 서적은 확실히 읽는 속도가 오래 걸린다. 두께가 있는 책들은 3~4주는 잡아야 2회독하는 패턴을 겪었다. 물론 충분히 필요한 절대적 시간량들이라 생각한다. 다만, 오래걸려서 텐션이 떨어지는 구간들을 좀 더 리듬감 있게 가져가도록 신경쓰려고 한다. 올 해는 아래 책들은 반드시 읽기로 계획했고 다른 책들은 상황에 맞게 필요를 조정하려 한다. “Real MySQL” / “개발자를 위한 레디스” / “아파치 카프카 애플리케이션 프로그래밍 with 자바” 강의 영한님 강의는 최대한 다 듣고 싶었는데 2개 강의가 아직 남았다 (실전 자바 고급 2편, 스프링 부트 핵심 원리) 솔직히 정말 좋았다. 실무를 한 번 겪고 왔기 때문에 그동안 풀리지 않았던 고민들과 가려웠던 부분들이 많이 해소됐다. 교육 비용은 아끼지 말자. 해야할 것들이 많으니 우선순위를 잘 지정해서 남은 강의도 올 해 적절한 시점에 마무리해야겠다. 돌아보면 한 해 동안 인프런 이용을 참 많이했다. 큰돌님 CS는 분량이 정말 어마어마했는데, 그만큼 CS 대비를 풍부하게 할 수 있어 좋았다. 아직 내재화해야할게 많아서 핵심을 다시 한 번 추려서 회독해야겠다. 동시성 강의들도 좋았다. 멀티스레드 디자인패턴이나 레디스 분산 락 등 이론과 더불어 다양한 동시성 제어 전략을 알 수 있어 폭을 넓힐 수 있었다. DB 설계 강의도 테이블 설계 전략을 머릿속에 일관성 있게 정립할 수 있어 도움이 많이 됐다. 자격증 24년에는 SQLD와 정보처리기사 2개를 합격했다. 시간이 길어지는만큼 기본적인 것들은 이럴 때 최소한의 시간으로 그냥 가져가자고 목표했다. 정보처리기사는 실기 90점으로 나름 고득점 합격했던게 소소한 즐거움이었다. 점수는 의미가 없지만 잠깐의 기쁨은 동기부여에 도움이 된다. 올 해는 AWS Associate 솔루션 아키텍트를 치를 계획이다. 하다보면 또 보이는 것이 있을거라 생각해 자격증 관련해서도 유도리 있게 한 해 목표를 수정해야겠다. 맺음말 생산성에 대한 생각을 많이 한다. 방대한 세상을 어떻게 체계적으로 정리하며 살아갈까에 대한 고민이다. 한 해 동안 개발에 관해서도 삶에 관해서도 건강해지기 위해 노력했다. 그리고 향상된 부분을 가시화하기 위해 신경썼다. 지난 1년을 거치며 보다 건강한 상태가 됐다는 점에 칭찬한다. 새로운 동기부여가 되는 지점이다. 2024년은 혼자의 시간이지만 프로페셔널함을 생각하며 보냈다. 엔지니어로서는 직업 윤리로서 기술적 탁월함을 추구했고 한 개인으로서는 삶의 전반적인 토대를 다시 다졌다. 2025년 회고 때는 과정을 발판 삼아 가치 있는 결과물을 남기고 기록하길 기도한다.

Blog · 2025-01-20

도커(Docker)Dive - 기본 개념

서버 운영 서버 하드웨어에서 실행 중인 소프트웨어 (문맥에 따라 하드웨어 지칭할 수도 있음) 어떤 소프트웨어가 실행 중인지에 따라 다양한 서버로 분류 e.g. 파일 서버 (파일 업로드/다운로드), DB 서버, 웹서버, 웹애플리케이션서버 엔터프라이즈 환경에서는 아주 많은 양의 서버를 운영해야 함 서버 운영 방법 베어메탈(Baremetal)- 비효율적 서버를 하나 구입하고 OS 설치 후 여러 개의 소프트웨어 실행 단점 하나의 소프트웨어에 문제가 생기면 다른 소프트웨어에게 영향을 미침 (에러, 사용량 급증) 하이퍼바이저(Hypervisor) - 전통적 가상화 기술 컨테이너(Container) - 최신 가상화 기술 큰 서버를 효율적으로 나눠서 사용하기 위해 가상화 기술이 필요 가상화 기술 물리적 컴퓨팅 환경 내부에서 논리적 컴퓨팅 환경을 만들 수 있는 기술 실제로 존재하는 컴퓨터가 아니지만, 마치 존재하는 것처럼 만듦 e.g. 하나의 OS안에서 4개의 추가 OS 만듦 8 Core/64 GB RAM -> OS(1 Core/8GB RAM) + 프로그램(1 Core/8GB RAM) X 4 장점 마치 여러 대의 컴퓨터를 사용하는 것처럼, 안전하게 소프트웨어 운영 가능 가상 컴퓨터에는 사용자가 직접 리소스를 분배할 수 있음 (리소스 최대값 지정) OS가 많아져 총 리소스 사용량은 증가하겠지만, 논리적으로 격리되어 한 프로그램의 문제가 다른 프로그램에 영향을 미치지 않음 물리적 컴퓨터 한 대만 사용할 수 있어 경제적 기업 입장에서는 낮은 사양 컴퓨터 여러대보다 높은 사양의 컴퓨터 한 대가 효율적 하이퍼바이저 가상화 (전통적 가상화 기술) 가상 환경 운영 프로그램을 설치해 관리하는 방식 e.g. VMWare, VirtualBox, Red Hat의 하이퍼바이저 제품 과정 호스트 OS(물리, 기본 OS)에 하이퍼바이저를 설치 격리된 환경으로 게스트 OS(논리, 가상머신) 실행하고 프로세스 운영 게스트 OS 커널의 시스템 콜을 호스트 OS 커널에게 전달할 때 중간에서 번역 시스템 콜: 커널에 하드웨어 자원을 요청하기 위한 표준 서버가 한 대라서 게스트 OS가 물리적 자원을 쓰려면 호스트 OS를 거쳐야만 함 각 OS 커널의 언어가 다르므로 번역 필요 핵심 특징 각각의 게스트 OS가 독립적인 커널을 가질 수 있음 장점 커널을 독립적으로 가지고 있어 보안면에서는 더 나을 수도 있음 단점: 무겁고 느림 하나의 게스트 OS가 차지하는 오버헤드가 큼 독립적인 커널로 인해 부팅 시간이 매우 느림 컨테이너 가상화 커널의 자체 기능(LXC)을 활용한 가상화 방식 e.g. Docker LXC(Linux Containers) 리눅스 커널이 제공하는 자체 격리 기술 커널 자체 기능만 사용해 격리된 공간(컨테이너) 생성 가능 네임스페이스: 리소스를 나누는 기준 역할 e.g. 프로세스, HDD, Network, 사용자, 호스트네임… Cgroups: 리소스의 사용량을 배분하는 기술 e.g. 프로세스가 사용하는 메모리, CPU, HDD, Network, BandWidth 컨테이너 LXC 기술을 사용해 만들어진 격리된 공간 컨테이너를 생성하면 완전히 격리된 CPU, Disk, Network, Memory 공간을 차지 내부에서 프로세스를 띄우면 완전히 격리된 공간에서 띄우는 것 여러 개의 컨테이너를 실행시키면 각각의 컨테이너는 격리된 공간에서 안전하게 운영됨 핵심 특징 모든 컨테이너는 HostOS의 커널을 공유해 사용 장점: 가볍고 빠르다!!! 오버헤드가 적어 빠름 하이퍼바이저와 달리 번역을 거치는 중간 단계가 없어 빠름 부팅이 매우 빠름 자체적인 커널 없이 호스트 OS의 커널을 공유하므로 커널 실행 시간 자체가 없음 -> 모던 애플리케이션 요구사항에 적합 빠르게 변화하는 사용자 니즈에 맞춰 변경 사항을 빠르게 적용 가능 e.g. 가벼운 웹서버 올리기 하이퍼바이저: 60초 컨테이너: 3초 단점: 호스트 OS의 커널을 공유하므로, 호스트 OS와 다른 종류의 OS는 실행할 수 없음 유의: 어떤 컨테이너 플랫폼 사용할지 어떤 컨테이너 런타임을 사용할지 선택 가능 도커 (오픈소스, 2013~) 커널의 컨테이너 가상화 기술을 쉽게 사용하기 위한 소프트웨어 (컨테이너 플랫폼) 하이퍼바이저와 달리 실제 격리 수행 주체는 커널 자체 목적: 컨테이너 내에서 소프트웨어(서버)를 빠르고 가볍게 운영하기 위해 사용 가장 점유율이 높은 컨테이너 플랫폼 컨테이너 플랫폼 예시 - Docker, Podman, Containerd… 컨테이너 플랫폼 구조 컨테이너 엔진 사용자의 요청을 받아 컨테이너를 관리해주는 역할 도커 아키텍처 (클라이언트-서버 모델) Docker CLI - 클라이언트 사용자가 입력한 명령어를 서버 API 양식에 맞게 변환해 대신 전달 덕분에 사용자는 도커 데몬의 API와 쉽게 통신 가능 Docker Daemon (=dockerd) - 서버 호스트 OS에서 지속적으로 실행되면서 클라이언트 요청에 따라 컨테이너 관리 클라이언트를 위한 API 제공 컨테이너 런타임을 통해서 컨테이너를 조작하고 결과를 CLI에게 전달 컨테이너 런타임 직접 커널과 통신하면서 실제로 격리된 공간을 만드는 역할 인터페이스: CRI(Container Runtime Interface) - OCI가 규정한 표준 구현: RUNC (도커 지원 기본 컨테이너 런타임) 이미지와 컨테이너 서버에서 소프트웨어 실행을위해 필요한 것들 하드웨어 OS 프로그램 실행 위한 구성 요소 (패키지, 라이브러리, 런타임 언어) 소프트웨어 (실행 시킬 프로그램) 이미지 = 실제 압축 파일 + 메타 데이터 컨테이너 실행 시 실제 압축 파일과 메타 데이터가 격리된 공간에 복사되어 프로세스로 실행 이미지 (Image) 특정 시점의 파일시스템(디렉터리)을 저장한 압축 파일 이미지 = OS + 구성 요소 + 소프트웨어 => 실행 준비가 완료된 상태 자체를 압축해 공유 Windows 백업 기능, 가상 머신의 스냅샷과 비슷 백업이나 스냅샷보다 압축 사이즈가 매우 작아 인터넷을 통한 저장과 공유가 수월함 이미지는 다른 사람이 만든 것을 사용하거나 직접 만들 수 있음 이미지 : 컨테이너 = 프로그램 : 프로세스 (1개의 이미지로 여러 컨테이너 실행 가능) 이미지는 파일 시스템 (압축 파일 형태로 호스트 머신 특정 경로에 위치) 컨테이너는 실행 상태의 이미지 이미지 메타데이터 (Metadata) 이미지에 대한 정보를 기술하는 데이터 이미지 이름, 사이즈 Env: 소프트웨어가 실행 시 참조할 환경설정 정보 (키-값 쌍) 소프트웨어 버전, 실행을 위해 필요한 파일 경로 등이 있음 (바뀌면 동작도 달라짐) e.g. VERSION=1.23.2,PATH=/usr/.. Cmd: 컨테이너 실행 시 프로세스 실행 명령어 지정 (리눅스 명령어) e.g. nginx -g daemon off; 컨테이너 실행 시 다른 값으로 덮어쓰기도 가능 (e.g. CMD 명령어 변경 등) 같은 이미지도 전혀 다른 역할을 수행하는 컨테이너로 만들 수 있음 보통 이미지를 디버깅할 때 주로 사용 컨테이너 라이프사이클 생성 단계 (Created) - docker create 컨테이너를 실행하기 위한 격리된 공간이 만들어지는 상태 네트워크, 스토리지, 환경 변수 등 모든 리소스를 격리 실행 단계 (Running) - docker start 컨테이너의 메타 데이터 CMD 값을 사용해 컨테이너를 실행 실제 프로세스가 실행되어 CPU와 메모리 사용 일시정지 단계 (Paused) - docker pause, docker unpause 컨테이너에서 실행 중인 모든 프로세스가 일시 중지된 상태 현재 상태를 모두 메모리에 저장 (CPU X, 메모리 O) 저장된 상태에서부터 재시작 정지 단계 (Stopped = Exited) - docker stop, docker start 컨테이너에서 실행 중인 프로세스를 완전히 중단 CPU와 메모리 사용 모두 중단 (재시작시 프로세스를 처음부터 다시 실행) 삭제 단계 (Deleted) - docker rm, docker rm -f 컨테이너가 삭제된 상태 (격리된 공간 삭제) 참고 컨테이너의 상태는 대부분 컨테이너 내에서 실행되는 프로세스 상태와 일치 프로세스를 잘 설계하고 다루는 것 => 컨테이너를 잘 사용하는 것 docker run = docker create + docker start docker restart: 프로세스를 재시작 실행 중 프로세스에 종료나 재시작 신호를 보내면 10초 뒤 반응 이미지 레지스트리 도커 이미지를 저장하기 위한 저장소 e.g. Docker Hub (대표적) 개인 및 팀이 필요한 이미지를 서로 공유하고 다운로드 (GitHub과 유사) GitHub이 소스 코드만 보관 <-> Docker Hub는 이미지 보관 (소스 코드 + 실행 환경) 이미지명만 서로 알면 실행 환경이 일치하는 애플리케이션 공유 가능 새 서버 구성 시간 및 서버 운영 비용 크게 감소 공통 제공 기능 이미지 공유, 이미지 검색, 이미지 버전 관리, 보안, 파이프라인 (DevOps 배포) 이미지 저장 공간 종류 호스트 머신의 로컬 스토리지 (특정 디렉터리) 온라인 저장소 퍼블릭 레지스트리 (e.g. Docker Hub) 프라이빗 레지스트리 보안 상 사내망, 내부망에서만 사용 가능한 레지스트리 방법 설치형 레지스트리 로컬 서버에 직접 설치 e.g. Harbor, Docker 프라이빗 레지스트리 퍼블릭 클라우드 서비스 시간 당 사용 요금 지불 e.g. Amazon ECR, Azure Container Registry (ACR) => docker run 실행 시 이미지가 로컬 스토리지에 있으면 바로 실행 없으면 온라인 레지스트리에서 로컬 스토리지로 이미지를 다운 후 실행 이미지 네이밍 규칙 이미지 네이밍: 레지스트리주소/프로젝트명/이미지명:이미지태그 레지스트리주소 (기본값: 도커에서는 Docker Hub 주소 docker.io) 어떤 레지스트리에서 이미지를 다운로드/업로드할 지 지정 프로젝트명 (기본값: library) 이미지를 보관하는 폴더 같은 개념 (Docker Hub에서는 사용자의 계정명) library: 도커사가 직접 검증한 오피셜 이미지를 관리하는 프로젝트 이미지명: 다운로드 받을 이미지의 이름 이미지태그 (기본값: 최신 버전을 의미하는 latest) 이미지의 버전 (숫자, 영문 모두 사용 가능) stable: 안정적 버전 alpine, perl…: 베이스 이미지로 사용했던 OS 버전 slim: 프로그램 실행에 정말 필요한 것들만 남겨놓음 이미지 전송 시간은 크게 단축하나 디버깅이나 사용이 불편할 수 있음 e.g. devwiki.com/myProject/myNginx:2.1.0-alpine nginx -> docker.io/library/nginx:latest (오피셜 이미지) 참고: 이미지 : 이미지 명 = 실제파일 : 참조 링크 이미지 빌드 이미지 레이어 이미지는 레이어드 파일 시스템으로 구성됨 레이어가 모여 하나의 이미지 구성 e.g. 이미지 다운 시, pull이 여러차례 걸쳐 일어남 한 줄이 하나의 레이어 레이어(Layer) 이전 레이어에서 변경된 내용을 저장 (소스코드 커밋, 푸시와 유사) 특징 레이어는 순차적으로 쌓임 여러 이미지 간 공유 가능 (재사용) Copy-on-Write 전략 사용 다음 레이어에서 이전 레이어의 특정 파일을 수정할 때, 해당 파일의 복사본을 만들어 변경 사항을 적용 e.g. 컨테이너 레이어는 파일수정 시 이전 레이어의 파일을 복사해와 수정 원래 레이어는 수정되지 않고 그대로 유지됨 불변 레이어 (Immutable Layer): 레이어는 한 번 생성되면 변경되지 않음 이미지의 일관성을 유지 동일한 이미지를 사용하는 컨테이너는 동일한 파일 시스템 상태 사용을 보장 캐싱 레이어를 캐시해두고 이미 빌드된 레이어를 재사용할 수 있음 이미지 빌드 시간이 크게 향상 (같은 레이어 사용하는 여러 이미지에서 효율적) 장점 중복 데이터를 최소화해 효율적인 저장소 사용 가능 재사용에 유리한 구조 (각 레이어가 서로 영향 X) => 이미지 저장 및 전송 시 스토리지와 네트워크 사용량 절약 빌드 속도 상승 e.g. 레이어 1: OS 파일 시스템 레이어 2: Nginx 설치 파일 (추가 파일만 저장) 레이어 3: Nginx 설정 파일 (추가 파일만 저장) 레이어 4: index.html 파일 수정 레이어 구분 이미지 레이어 : 컨테이너 레이어 = 건축 도면 : 실제 건물 이미지 레이어 읽기 전용 레이어 컨테이너 실행을 위한 세이브 포인트 역할 각각의 레이어는 고유한 해시값을 가짐 컨테이너 레이어 모든 컨테이너가 가지는 자신만의 읽기/쓰기 레이어 컨테이너 실행 시, 이미지 레이어 위에 새로 추가 컨테이너 실행 후 프로세스가 변경하는 내용을 기록 장점: 같은 이미지로 여러 컨테이너를 만들어도 하나의 이미지 레이어를 공유 => 컨테이너 생성 속도 향상 및 공간 절약 이미지를 만드는 방법 이미지 커밋 실행 중인 컨테이너의 상태를 그대로 이미지로 저장 새로운 이미지 = 기존 이미지 레이어 + 컨테이너 레이어 단점 휴먼 에러 가능성이 높음 이미지를 만들 때마다 컨테이너를 실행해 직접 커밋 명령을 수행해야 함 레이어 쌓을 때마다 컨테이너 실행 및 커밋 반복이 번거로움 이미지 빌드 (주로 사용) IaC 방식을 활용해 이미지를 저장 (Dockerfile) 원하는 이미지 상태를 소스 코드로 작성하면 컨테이너 생성 및 커밋 작업을 도커가 대신 수행 Dockerfile 지시어마다 레이어를 쌓는지 여부가 다름 레이어를 쌓는 지시어 하나 당 레이어 1개 추가 예를 들어, CMD는 레이어를 쌓지 않음 과정 (docker build) -> 커밋 과정을 자동 반복 임시 컨테이너 생성 변경 사항 적용 후 커밋 (새로운 레이어 생성) 임시 컨테이너 삭제 빌드 컨텍스트 (Build Context) 도커 데몬이 이미지를 빌드할 때 전달되는 폴더 도커 데몬은 빌드 컨텍스트에 있는 파일만 카피 명령으로 복사할 수 있음 폴더 내에 도커 파일과 빌드에 사용되는 파일들이 담겨야 함 빌드 컨텍스트가 너무 크면 전송 시간이 길어지거나 문제 발생 C 드라이브 전체 사용 등은 절대 안되고, 따로 폴더로 관리할 것! .dockerignore : 빌드 컨텍스트로 전달될 파일 관리 멀티 스테이지 빌드 (Multi-Stage Build) 빌드 스테이지와 실행 스테이지 2개로 나누어 빌드하는 방식 장점: 애플리케이션 실행용 이미지의 크기가 크게 감소 문제 빌드 과정에서 사용하는 파일들은 용량을 많이 차지 (e.g. 메이븐 빌드 도구) 실행용 이미지의 사이즈가 커지면 이미지 전송 및 다운로드 시간이 더 걸림 해결책: 빌드에 사용하는 이미지와 실행에 사용하는 이미지 나누기 e.g. 빌드 이미지: 메이븐 도구, 소스코드 실행 이미지: 자바 런타임 및 빌드된 jar 파일 참고: 두 개의 FROM -> 도커가 두 개의 컨테이너를 동시 실행 (메이븐 컨테이너, JDK 컨테이너) IaC(Infrastructure as Code) 인프라를 코드를 통해서 관리하는 것을 말한다. 사람이 화면이나 CLI를 통해 관리하는 기존 방식은 인수인계도 어렵고 휴먼 에러를 일으킬 확률이 높다. 반면에, IaC는 사람이 코드로 인프라 상세 작업을 기재한다. 그러면 프로그램이 코드를 읽어 대신 인프라 관리를 수행하므로, 더 빠르고 안전하다. 또한, 이러한 코드 명세서를 GitHub에 올리면 인프라 상태도 소스코드처럼 버전 관리를 할 수 있다. 애플리케이션 빌드 애플리케이션 빌드는 필요한 라이브러리들을 설치하고 소스코드를 실행 가능한 프로그램으로 만드는 것을 말한다. (소스코드 -> 애플리케이션) 빌드의 결과물은 애플리케이션 프로그램(Program) 혹은 아티팩트(Artifact)라고 부른다. 예를 들어, 자바로 개발한 소프트웨어는 소스 코드를 실행 가능한 아티팩트로 빌드할 수 있다. (소스코드 + OS, Java Runtime, 빌드 도구(mvn), 라이브러리 -> jar 혹은 war 파일) 개발한 소스 코드를 이미지로 빌드하는 과정에는 일반적으로 이러한 애플리케이션 빌드 과정을 직접 포함시켜야 한다. Reference 개발자를 위한 쉬운 도커

Infrastructure · 2025-01-16

DB 설계 규칙 정리

DB 네이밍 규칙 테이블명, 컬럼명은 소문자로 작성하고 snake_case를 사용한다. 테이블명은 복수형을 사용하자. (선택사항) 여러 개 데이터를 가지고 있음을 표현 회사마다 규칙이 갈리므로, 복수형이든 단수형이든 일관성 있게만 사용하면 됨 축약어를 사용하지 않는다. SQL문은 예약어만 대문자로 작성하자. (SELECT, FROM, WHERE…) DB 설계 핵심 원칙 핵심 원칙: 중복 없애기 (정규화) 데이터 간 모순(이상 현상)의 근본적 원인은 데이터 중복이고, 정규화는 데이터 중복을 제거 e.g. 두 테이블에 작성자 컬럼이 있는데, 모두 수정하다가 한 데이터를 빼먹으면 갱신 이상 발생 DB 설계 과정 저장해야 하는 데이터 파악하기 대략적인 UI 디자인 기획을 보고 필요한 데이터 파악 가끔 글로만 정리된 요구사항이 있을 수 있지만, 놓치는 부분이 생길 수 있어 좋지 않은 방식 기준: 나중에 조회해서 쓸 일이 있겠다 싶은 데이터를 전부 저장 그룹핑해서 분류하기 관련 있는 것들끼리 묶어 상위 개념을 찾음 (= 엔터티 = 테이블) 따로 법칙이 있다기보다 인간이 모두 가지고 있는 보편적인 분류 능력을 따르자 e.g. 아이디, 패스워드, 이름, 이메일 → 사용자 (엔터티) 영화 이름, 영화에 출연한 배우, 영화 상영 시간 → 영화 (엔터티) 게시글 제목, 게시글 내용, 게시글 생성 시간 → 게시글 (엔터티) 6가지 규칙을 적용하며 테이블 분리해나가기 유의점 데이터 예시를 입력하며 파악하자 규칙 1 + 규칙 2의 결과는 규칙 3의 결과 동일 (무얼 선택해도 괜찮음!) 처음에 완벽한 설계가 안돼도 추후 데이터 중복을 발견해 수정 가능하니 불안해하지 말자 연관 관계 파악 관련 규칙 규칙 1: 한 칸에 한 가지 정보만 들어가야 한다 (제1정규형) 한 칸에 두 가지 정보가 있을 시, 테이블을 분리하고 FK를 적용 FK 적용이 규칙 1을 어길 경우, 반대쪽 테이블에도 FK를 적용해보자 ‘한 가지 정보’의 기준은 절대적이지 않아서, 자신의 서비스에 맞게 판단해야 함 e.g. 손/흥민 or 손흥민, 01012341234 or 010/1234/1234 규칙 2: 어떤 테이블에 FK를 넣어도 ‘규칙 1’을 못 지킬 때는 중간 테이블을 하나 더 만들자 양쪽 테이블의 FK를 중간 테이블로 옮기기 중간 테이블의 이름은 동사를활용하면 좋음 (직관성, 가독성 상승) e.g. students & courses -> course_registrations {id(PK), student_id(FK), course_id(FK)} movies & actors -> casting {id(PK), movie_id(FK), actor_id(FK)} 규칙 3: 헷갈릴 땐 연관 관계를 파악해보자 (1:1, 1:N, N:M) 판단 방법 엔터티 간에 어울리는 동사를 찾기 (A가 B를 ___.) e.g. 사용자가 이메일을 소유한다. 이메일은 사용자에 의해 소유되어진다. 적절한 단어 찾기 (하나의 or 여러개의) e.g. ‘하나의’를 고정해서 따져보기 하나의 사용자는 ___ 이메일을 소유한다. 하나의 이메일은 ___ 사용자에 의해 소유되어진다. 관계 파악하기 (1:1, 1:N, N:M) e.g. 사용자와 이메일은 1: N 관계 1:N 관계 N 쪽 테이블에 FK 들어가야 함 N:M 관계 중간 테이블이 있어야 하고, 중간 테이블에 두 테이블의 FK가 들어가야 함 (1:N으로 해소) 1:1 관계 아무 테이블에 FK를 넣어도 됨 합쳐도 되는지 고려해보자 (왠만하면 1:1 관계로 분리하지 않는 걸 추천) 통쨰로 조회하는 일이 많다면 합치는게 좋음 만약 각각 따로 조회할 일이 많다면 분리하는게 좋음 중복 없애기 관련 규칙 규칙 4: 데이터 중복이 발생하는 컬럼이 있는지 확인하자 임의의 데이터를 넣고 시뮬레이션해서 데이터 중복 발생 여부 파악 e.g. 게시물 테이블의 작성자 데이터가 중복됨 중복이 있다면 테이블 분리하고 FK 적용 수정 포인트가 하나가 되므로, 갱신 이상 여지가 사라짐 규칙 5: 가짜 중복과 진짜 중복 구별하기 실제 서비스에서 A 데이터 값을 수정하면, B 데이터 값도 같이 수정되어야 하는가? e.g. id 1 게시물의 작성자를 수정하면, id 2 게시물의 작성자도 수정해야 하나? 같이 수정되어야 하면 진짜 중복, 아니라면 가짜 중복 진짜 중복인 경우 테이블 분리해야 함 규칙 6: 숨어있는 중복을 찾아라 숨어 있는 중복 겉으로는 중복이 아닌 것 같지만, 무언가 수정해야할 때 같이 수정해야 하는 경우 e.g. users & posts -> likes (중간 테이블) 좋아요를 제거할 때, 게시글의 좋아요 수도 같이 수정해야 함 주로 통계치(합계, 평균, 최대값 등)를 낼 때 발생 해결 방법: 테이블에서 통계치 칼럼을 없애야 함 e.g. 좋아요 수 없애기 좋아요 수를 알고 싶다면, 좋아요 테이블에서 필터링하여 개수 카운팅하자 DB 설계 반영 지침 최대한 정규화를 지켜서 DB 설계하자 정규화 적용하지 않은 케이스의 의견들 정규화를 지키면 테이블 개수가 많아져서 관리가 불편해요. → 데이터 중복으로 인해 발생하는 단점들이 훨씬 크고 관리하기가 더 어렵다. JOIN을 많이 하면 할수록 성능이 안 좋아져서 정규화를 안 했어요. → 실제로 JOIN을 많이 했을 때 성능이 안 좋아지는 경우도 존재한다. 하지만 이렇게 얘기하는 사람치고 실제로 성능 측정해본 사람이 아무도 없다. (추측만 했을 뿐) 즉, 이상 현상 방지에 가장 초점을 두자 데이터 중복으로 인해 실수로 데이터가 잘못 관리되는 문제가 더 큼 성능 개선은 느려지기 전까지 최대한 안 건드리는 게 Best! 필요성을 느낀다면 반드시 ‘측정’을 기반으로 해야 함 역정규화는 정말 구조로 인한 성능 문제가 클 때만 사용하라 ERD 표기 지침 DB 설계 시 ERD 그리는 게 필수가 아니어서, 보고 해석하는 방법 정도만 알아도 충분 홀로할 때는 편하고 빠른 방법으로 진행 (엑셀, A4지…) 협업할 때는 툴 사용 (ERD Clould, dbdiagram…) 1:1 관계인지 1:N 관계인지만 파악할 수 있으면 됨 (그 외 표기는 잘 안쓰임) 데이터 타입 실전 활용 지침 (MySQL 기준) 주요 사용 타입 정수를 저장해야 하는 경우 : INT 10억이 넘어가는 정수를 저장해야 될 수도 있는 경우 : BIGINT 실수를 저장하고 싶은 경우 : DECIMAL 문자를 저장해야 하는 경우 : VARCHAR(글자수) 6만이 넘어가는 문자를 저장해야 하는 경우 : LONGTEXT TimeZone을 고려하지 않고 날짜/시간 데이터만 저장하면 되는 경우 : DATETIME ex) 국내 서비스 TimeZone을 고려하면서 날짜/시간 데이터를 저장해야 하는 경우 : TIMESTAMP ex) 글로벌 서비스 True, False의 형태를 저장하고 싶은 경우 : TINYINT(1) 참고: 숫자는 숫자로 저장할 수도 있고 문자로 저장할 수도 있음 DB 관점에서는 “계산에서 쓰는 값인지 안 쓰는 값인지”를 기준으로 선택 휴대폰 번호는 문자로 저장 (숫자를 더해서 사용하지 않고 단순히 고유의 값으로 사용할 뿐) 주민등록번호도 마찬가지로 문자로 저장 현업에서 잘 사용하지 않는 데이터 타입 : CHAR, FLOAT, DOUBLE, TEXT 등 Reference 비전공자도 이해할 수 있는 DB 설계 입문/실전

Computer Science · 2025-01-15

QueryDSL Dive

Java-Ecosystem · 2025-01-13

Spring Data JPA Dive

Java-Ecosystem · 2025-01-09

선착순 이벤트 시스템 개발하기

선착순 이벤트 시스템 개발하기 발생할 수 있는 문제 쿠폰을 100개만 발급해야 하는데, 쿠폰이 100개보다 많이 발급되었다 트래픽이 급증해 이벤트 페이지 접속이 안된다 이벤트랑 전혀 상관없는 페이지들도 느려졌다 해결책 트래픽이 몰렸을 때 대처하는 방법 적용 Redis를 사용해 쿠폰 발급 개수를 보장하기 Kafka를 활용해 다른 페이지에 미치는 영향을 줄이기 Redis로 Race Condition 해결하기 기존 락 활용의 문제 선착순 쿠폰 발행은 쿠폰 개수에 대한 정합성을 요구함 락 활용은 요구사항의 임계영역이 길어서 성능 불이익 발생 발급된 쿠폰 개수를 가져오는 것부터 쿠폰 생성까지 락을 걸면 임계영역이 길어져서 성능 불이익 해결책: 레디스는 싱글 스레드로 동작해 Race Condition 해결 애플리케이션의 모든 스레드는 언제나 최신 값을 가지게 됨 레디스 incr 명령어 활용 key의 value를 1씩 증가시킴 성능이 매우 빠른 명령어 남은 문제점 쿠폰 발급 개수가 많아질수록 RDB에 부담을 주어 서비스 지연 및 오류 발생 짧은 시간 내 많은 요청 -> DB 서버 리소스 과부하 쿠폰 전용 DB가 아니라면 다른 서비스에도 영향 e.g. MySQL이 1분에 100개 Insert가 가능하다고 가정 10:00 쿠폰 생성 10000개 요청 10:01 주문 생성 요청 10:02 회원가입 요청 -> 쿠폰 생성으로 인해 100분 이후에 주문 및 회원가입 요청이 처리됨 -> 심지어 보통은 타임아웃이 있으므로, 쿠폰 생성 일부분과 주문 및 회원가입 처리 실패 Kafka로 처리량 조절하기 데이터 정합성은 Redis로 이미 확인했으므로, 쿠폰 생성만 처리 Kafka 분산 이벤트 스트리밍 플랫폼 이벤트 스트리밍: 소스에서 목적지까지 이벤트를 실시간으로 스트리밍하는 것 Producer(소스) - Topic(큐) - Consumer(목적지) 장점 API에서 직접 생성하는 것에 비해 처리량 조절이 가능 -> DB 부하 감소 큐를 사용하므로 이벤트가 하나가 끝난 후 다음 이벤트가 처리되어 DB에 한 번에 쏠리지 않음 단점 이벤트 생산과 이벤트 처리는 약간의 텀이 발생 Producer의 이벤트 생산은 매우 빠르지만, Consumer는 이벤트를 처리하느라 시간차 발생 부록: 쿠폰 1인당 1개로 제한하기 DB 레벨 제한: Unique key 사용하기 userId, couponType에 유니크 제약 조건 걸기 문제점: 보통 서비스는 한 유저가 같은 타입의 쿠폰을 여러개 가질 수 있으므로, 실용적이지 않음 락 범위 넓혀서 쿠폰 발급 여부 조회해 판단하는 로직 추가하기 쿠폰 발급 여부 판단 로직 쿠폰 발급 여부 조회: select * from coupon where userId = ? 쿠폰이 이미 있다면 발급하지않고, 미지급일 때만 발급 락 범위: 쿠폰 발급 여부 조회 ~ Redis 동시성 체크 ~ 카프카 이벤트 생산 문제점 생산자와 소비자의 시간차 때문에 쿠폰이 여러 개 발급될 수 있음 소비자에서 아직 발급 중인데 유저의 쿠폰 발급 요청이 한 번 더 온다면? API에서 쿠폰 생성까지 하더라도 락 범위가 너무 넓어 성능 저하 발생 Set 자료구조 사용하기 (권장) userId를 Set에 저장하면 쿠폰 발급 여부를 바로 알 수 있음 Redis도 Set을 지원하므로 활용 부록: Consumer 예외 처리하기 문제: Consumer에서 예외가 발생하면, 발급된 쿠폰 개수는 올라갔는데 쿠폰은 발급되지 않은 상황 발생 즉, 100개보다 적은 쿠폰이 발생하는 상황 발생 가능 해결책: Consumer에서 예외 발생 시, 백업 데이터(FailedEvent 테이블)와 로그 남기기 추후 배치 프로그램으로 주기적으로 실패한 이벤트를 다시 처리해 쿠폰 발급

General · 2025-01-06

동시성 문제 해결 방법

동시성 문제 해결방법 멀티스레드 작업을 하다보면, 공유 자원에 대한 Race Condition으로 인해 동시성 이슈가 발생한다 이에 대한 다양한 해결방법을 정리해보자 최종 선택 기준 synchronized는 사용 X 비용적 여유가 없고 적정한 트래픽이라면, MySQL로 처리 비용적 여유가 있고 트래픽이 많다면 Redis로 처리 MySQL VS Redis MySQL 이미 사용 중이라면 별도 비용 없이 사용 가능 Redis 보다 성능이 떨어짐 (어느정도 트래픽까지는 문제 없이 사용 가능) Redis 사용 중인 Redis가 없다면, 인프라 구축 및 관리 비용 발생 MySQL보다 성능이 좋음 Synchronized (거의 사용 X) 데이터에 1개의 스레드만 접근 가능하도록 하기 문제점 여러 프로세스 동작 시, 여전히 Race Condition 발생 synchronized는 하나의 프로세스 안에서만 1개의 스레드 접근 보장 다른 프로세스의 스레드가 접근하면, 여전히 여러 스레드가 접근 가능해짐 서버가 1대일 때는 괜찮지만, 2~3대부터는 데이터 접근을 여러 곳에서 할 수 있음 실제 운영 중인 서비스는 대부분 2대 이상의 서버를 사용 -> synchronized는 거의 사용 X 추가로, @Transactional 사용 시 synchronized 적용이 어려움 @Transactional은 스프링 AOP 사용으로 트랜잭션 프록시 객체를 생성 내부 동작 startTransaction(); stockService.decrease(id, quantity); (target 객체 호출) endTransaction(); 실제 DB 업데이트(endTransaction()) 전에 다른 스레드가 decrease() 메서드 호출할 수 있음 이렇게 되면, 다른 스레드는 갱신되기 전 값을 가져가 여전히 동시성 문제 발생 즉, 서비스 객체 메서드가 아닌, AOP 객체 메서드에 synchronized를 걸어야 하는데 어려움 MySQL이 지원해주는 방법 선택 기준 충돌이 빈번하게 일어날 것 같다면 Pessimistic Lock 충돌이 별로 없을 것 같다면 Optimistic Lock Pessimistic Lock 실제 데이터에 락을 걸어서 정합성을 맞추는 방법 (for update) Exclusive Lock을 걸게되며, 다른 트랜잭션에서는 락이 해제되기전에 데이터를 가져갈 수 없음 e.g. 서버 1이 락을 가져가면, 다른 서버(2, 3, 4…)는 락 획득 대기 데드락을 주의해야 함 장점 충돌이 빈번하게 발생한다면, Optimistic Lock 보다 성능이 좋을 수 있음 락 덕분에 데이터 정합성 보장 단점 락 자체로 인한 성능 감소 발생 Optimistic Lock 버전을 이용해 정합성을 맞추는 방법 데이터를 읽은 후 update 쿼리를 수행할 때, 현재도 내가 읽은 버전이 맞는지 확인하며 업데이트 e.g. 서버 1과 2가 버전 1인 데이터를 읽고, 업데이트 쿼리를 날림 서버 1이 업데이트 쿼리를 수행하면 해당 데이터의 버전이 2가 됨 서버 2는 읽은 버전이 1이므로, 현재 데이터와 버전(버전 2)이 달라 쿼리 실패 내가 읽은 버전에서 수정사항이 생겼을 경우, application에서 다시 읽은 후에 작업을 수행 장점 별도의 락을 걸지 않으므로Pessimistic Lock 보다 성능이 좋음 단점 업데이트가 실패했을 때 재시도 로직을 개발자가 직접 작성해야 함 Named Lock 이름을 가진 Metadata Locking 이름을 가진 락을 획득한 후 해제할 때까지 다른 세션은 이 락을 획득할 수 없음 MySQL: select get_lock('1', 1000), select release_lock(‘1’) 락 해제는 별도의 명령어로 수행하거나 선점시간이 끝나야됨 트랙잭션이 종료될 때 락이 자동으로 해제되지 않음 장점 분산 락 구현에 적합 Pessimistic Lock 보다 타임아웃을 쉽게 구현할 수 있음 삽입 시 데이터 정합성 맞출 때도 좋음 단점 트랜잭션 종료 시 락 해제, 세션 관리를 잘해주어야 함 실제 사용 시 구현 방법이 복잡 참고: 실무에서는 데이터 소스를 분리해서 사용할 것 (커넥션 풀 고갈 예방) Pessimistic Lock과의 차이점 Pessimistic Lock은 행, 테이블 단위로 락을 걸음 (e.g. Stock에 락을 걸음) Named Lock은 메타 데이터에 락을 걸음 (e.g. Stock이 아닌 별도의 공간에 락을 걸음) Redis를 이용한 방법 선택 기준 재시도가 필요하지 않은 락은 Lettuce 활용 재시도가 필요한 락은 Redisson 활용 Lettuce setnx 명령어(set if not exist)를 활용해 분산 락 구현 데이터 set (=락 획득), 데이터 del (=락 해제) MySQL의 Named Lock과 유사 스핀락(Spin Lock) 방식 장점 구현이 간단 세션 관리도 신경쓸 필요 X 별도 라이브러리 필요 X spring-data-redis를 사용하면 Lettuce가 기본 단점 재시도 로직을 개발자가 직접 작성 스핀 락이므로 충돌이 잦으면 Redis 부하 상승 -> 실패 시 재시도 시간에 텀을 두어 보완 (Thread.sleep(100)) Redisson Pub-Sub 기반으로 분산 락 제공 채널을 하나 만들어 락 점유 중인 스레드가 해제를 알리면 락 획득 대기 스레드는 락 획득 시도 장점 락 획득 재시도를 기본으로 제공 Pub-Sub 기반이므로 Lettuce에 비해 Redis 부하 적음 락 해제 후 알림으로 락 획득 시도는 1번 혹은 몇 번 정도만 진행함 단점 구현이 조금 복잡함 별도의 라이브러리 필요 O

General · 2025-01-05

소프트웨어 장인

Software Engineering · 2024-12-30

도메인 주도 개발 시작하기

Software Engineering · 2024-12-16

만들면서 배우는 클린 아키텍처

Software Engineering · 2024-12-03

JPA 활용 팁 2

Java-Ecosystem · 2024-11-26

단위 테스트 (Unit Testing) - 가치 있는 테스트 작성하기

Software Engineering · 2024-11-22

단위 테스트 (Unit Testing) - 가치 있는 테스트 식별하기

좋은 단위 테스트의 4대 요소 좋은 단위 테스트의 4가지 특성 회귀 방지 (=소프트웨어 버그 방지) 중요 지표: 테스트로 실행되는 코드의 양, 코드 복잡도, 코드의 도메인 유의성 복잡도와 도메인 유의성이 높은 코드에 대한 테스트가 많을수록 회귀 방지가 탁월 리팩터링 내성 테스트 실패없이 애플리케이션 코드 리펙토링 가능한지에 대한 척도 중요지표: 거짓 양성 발생량 (적을수록 좋음) 거짓 양성: 리팩토링 후 기능이 의도대로 작동해도 테스트가 실패하는 상황 (허위 경보) 회귀 발생 시 조기 경고를 제공 X (잘못된 것이므로 개발자가 무시) 리팩토링에 대한 능력과 의지 감소 (테스트 스위트에 대한 신뢰가 부족) 거짓 양성의 원인: SUT의 구현 세부 사항과 결합된 테스트 (분리 필요) 해결책: 테스트에서 구현 세부사항이 아닌 최종 결과를검증하기 결합도를 낮추면 리팩토링 내성 상승 거짓 양성 발생량이 크게 감소 거짓 양성에 대한 올바른 대응은 테스트 스위트의 안정성을 높이는 것 빠른 피드백 중요 지표: 테스트 실행 속도 빠른 테스트는 버그 수정 비용이 대폭 감소 (더 많은 테스트를 자주 실행할 수 있음) 느린 테스트는 버그 수정 비용이 상승 (뒤늦게 버그를 발견, 시간 낭비) 유지 보수성 중요 지표: 유지비 (테스트 이해 난이도, 테스트 실행 난이도) 테스트 이해 난이도: 테스트의 크기를 의미 (코드라인이 적을수록 읽기 쉬움) 테스트 실행 난이도: 테스트가 프로세스 외부 종속성으로 작동하면, 의존성 운영 비용 고려 필요 회귀 방지 & 리팩터링 내성 간 관계 올바른 추론: 올바르게 작동해 테스트가 통과 & 기능이 고장나 테스트가 실패 회귀 방지와 리팩터링 내성은 테스트 스위트의 정확도 극대화를 목표로하는 특성 테스트 정확도 = 신호(발견된 버그 수) / 소음(허위 경보 발생 수) 거짓 양성, 거짓 음성 발생 확률 줄이기 -> 테스트 정확도 상승 회귀 방지가 훌륭한 테스트는 거짓 음성 수를 최소화 리팩터링 내성이 훌륭한 테스트는 거짓 양성 수를 최소화 중대형 프로젝트는 거짓 음성과 거짓 양성에 똑같이 주의를 기울여야 함 프로젝트 초반은 리팩토링이 많지 않아 거짓 양성은 무시할만 함 프로젝트 중후반으로 갈수록 리팩토링이 중요한데, 거짓 양성이 잦으면 문제가 커짐 테스트 전략 테스트의 가치 = 회귀 방지 X 리팩터링 내성 X 빠른 피드백 X 유지 보수성 하나라도 0이면 전체가 0 (모두 1도 불가능) 유지보수성은 다른 특성과 독립적 (엔드 투 엔드 테스트에서만 회귀 방지와 연관됨) 회귀 방지, 리팩토링 내성, 빠른 피드백은 상호 배타적 -> 하나를 희생해야 둘이 최대 가능 회귀 방지 희생 -> 너무 간단한 테스트 리팩토링 내성 희생 -> 구현에 결합된 깨지기 쉬운 테스트 빠른 피드백 희생 -> 엔드 투 엔드 테스트 각 요소에 높은 임계치를 두고 이를 충족하는 테스트만 테스트 스위트에 남기기 소수의 매우 가치 있는 테스트가 프로젝트의 지속적 성장에 효과적 전략적 절충 리팩토링 내성은 최대화 필요 (리팩토링 내성은 대부분 있거나 없거나 둘 중 하나이므로…) 회귀 방지와 빠른 피드백 사이에서 조절하자 테스트 피라미드 관점 전략 테스트 유형 간 비율은 피라미드 형태를 유지할 것 (팀, 프로젝트 마다 비율 차이 O) 모든 테스트 계층은 가능한 거짓 양성 최소화 목표 (리팩토링 내성 최대화) 피라미드 내 테스트 유형에 따라 회귀 방지와 빠른 피드백 사이에서 선택함 엔드 투 엔드 테스트는 매우 중요한 기능에만 적용 빠른 피드백과 유지보수성 결여 -> 숫자가 가장 적은 이유 예외 케이스 복잡도가 거의 없는 기본 CRUD 프로젝트 통합 테스트 수가 단위 테스트 수와 같거나 많고 엔드 투 엔드 테스트가 없음 단위 테스트는 복잡도 없는 환경에서 유용성 감소 통합 테스트는 여전히 시스템 간 통합 동작 확인에 가치 있음 프로세스 외부 의존성 하나만 연결하는 API (e.g. DB) 엔드 투 엔드 테스트를 더 많이 두는 것이 적합 (환경 상 통합 테스트와 구분 불가) 속도가 상당히 빠를 것이고 유지비도 적음 블랙 박스 테스트 & 화이트 박스 테스트 전략 둘을 조합하되 테스트 작성 시 블랙 박스 테스트 선택하자 화이트 박스 테스트는 구현에 결합 -> 리팩토링 내성 포기할 수는 없음! 테스트 분석 시 화이트 박스 테스트 사용! (e.g. 코드 커버리지 도구) 목과 테스트 취약성 테스트 대역(test double) 모든 유형의 비운영용 가짜 의존성 e.g. 더미, 스텁, 스파이, 목, 페이크 사용 의도에 따라 목과 스텁으로 나뉨 (Mock 프레임워크로 똑같이 인스턴스를 생성) 목(mock) - 목, 스파이 외부로 나가는 상호 작용을 모방하고 검사 상태 변경을 위해 의존성을 호출하는 것 (사이드 이펙트 O) e.g. SMTP 서버로 이메일 발송 작업 CQS 관점에서 명령을 대체 (보통 반환값 X) 구현 목: 목 프레임워크의 도움 받아 생성 스파이: 수동으로 작성한 목 스텁(stub) - 스텁, 더미, 페이크 내부로 들어오는 상호 작용을 모방만 함 입력 데이터를 얻기 위해 의존성을 호출하는 것 (사이드 이펙트 X) e.g. DB로 부터 데이터 검색 CQS 관점에서 조회를 대체 (보통 반환값 O) 구현 더미: 단순 하드코딩 값 (null, 가짜 문자열) 스텁: 더 정교하게 시나리오마다 다른 값 반환하는 의존성 페이크: 스텁과 같지만, 아직 존재하지 않는 의존성을 대체하고자 구현 무분별한 목 사용 지양하기 (feat. 리팩토링 내성 감소) API를 잘 설계하면 단위테스트도 자동으로 좋아짐 식별할 수 있는 동작만 공개하고 구현 세부사항을 비공개함으로써 리팩토링 내성 상승 스텁의 상호작용은 검증하지 말자! (안티패턴) 입력을 제공할 뿐이지 SUT의 최종 결과가 아님 스텁의 상호작용 검증은 내부 구현 세부사항과 결합(overspecifiation) -> 리팩토링 내성 감소 목의 상호작용 검증은 최종 결과 검증 e.g. mock.Verify(x => x.SendGreetingsEmail("user@email.com")) -> O stub.Verify(x => x.GetNumberOfUsers(), Times.Once) -> X 사이드 이펙트가 있는 시스템 간 통신은 목으로 테스트하자! (외부 애플리케이션 통신) 클래스 간 통신에도 목을 쓰는 것은 런던파의 단점 가치 있는 목 테스트 var mock = new Mock<IEmailGateway>() mock.Verify(x => x.SendReceipt("..@x.com","egg",5), Times.Once) 클라이언트 목표 달성에 도움이 되는 연산 잘못된 목 테스트 var storeMock = new Mock<IStore>() storeMock.Verify(x => x.RemoveInventory("egg", 5), Time.Once) 시스템 내 통신(도메인 간 통신)은 클라이언트 목표로 가는 중간 단계 (구현 세부 사항) 애플리케이션을 통해서만 접근할 수 있는 프로세스 외부 의존성은 목 대체 X 모든 공유 의존성을 목으로 대체하는 것은 고전파의 단점 외부 클라이언트 관점에서 접근 불가한 시스템은 구현 세부 사항 e.g. 데이터베이스 식별할 수 있는 동작과 공개 API 모든 제품 코드는 2차원으로 분류할 수 있다. 공개 API (public) & 비공개 API (private) 식별할 수 있는 동작과 구현 세부 사항 식별할 수 있는 동작은 클라이언트가 목표를 달성하는데 도움이 되는 연산(Operation)과 상태(State)를 최소한으로 노출한다. (연산은 계산 수행 혹은 사이드 이펙트를 초래하는 메서드를 의미) 구현 세부사항은 두 가지 중 어떤 것도 하지 않는다. 잘 설계된 API는 식별할 수 있는 동작은 공개 API와 일치하고, 모든 구현 세부 사항은 비공개 API 뒤에 숨어 있다. 만일, 식별할 수 있는 동작을 달성하고자 할 때 클래스에서 호출해야 하는 연산 수가 1보다 크면 해당 클래스는 구현 세부 사항을 유출했을 가능성이 크다. 또한, API를 잘 설계하면 단위테스트도 자동으로 좋아진다. (리팩토링 내성 상승) 장기적으로 캡슐화는 증가하는 복잡성에 대응하고 소프트웨어의 지속적 성장을 가능하게 하는 유일한 방법이다. 헥사고날 아키텍처(Hexagonal Architecture, Alistair Cockburn) - 애플리케이션 서비스 + 도메인 - 도메인 계층 (도메인 지식) - 비즈니스 로직 책임 - 애플리케이션 서비스 계층 (유스케이스) - 외부 환경과의 통신을 조정 (SMTP, 메시지 버스, 서드파티…) - 잘 설계된 API는 프랙탈 특성 존재 - 서로 다른 계층의 테스트도 동일한 동작을 서로 다른 수준으로 검증하는 프랙탈 특성 존재 - 목표(유스 케이스) - 하위 목표 - … Reference 단위 테스트 (생산성과 품질을 위한 단위 테스트 원칙과 패턴)

Software Engineering · 2024-11-13

단위 테스트 (Unit Testing) - 단위 테스트의 목표와 구조

Software Engineering · 2024-11-11

스프링 핵심 원리 - 고급편

Java-Ecosystem · 2024-11-08

정보처리기사 92점 합격수기 - 인프런

주말 코딩님 덕분에 정말 “효율적”으로 실기 합격했습니다! 가채점 점수 92점, 발표일에 합격인증까지 올리겠습니다~😀 10월 20일에 있었던 3회차 정보처리기사 실기를 막 마치고 얻은 점수입니다. 약 1주일 간 주말코딩님 인프런 강의와 함께하며 정보처리기사를 준비했구요 (대략 10일) 가장 큰 목표인 “최소비용”, “효율” 중시로 시험을 준비했던 과정을 공유해보려고 합니다. 우리 모두 바쁘자나요~ 고득점 목표는 정말 전혀 없었는데 주말코딩님과 핵심만 집중하다보니 덤으로 얻었다고 생각해요 1. 학습 목표 저한테 가장 중요했던 것은 “최소비용 및 시간으로 안정적인 합격하기” 였어요. 시중 책들이나 강의가 불필요하게 깊게 파고 비싸서 시간과 비용이 아깝다고 느꼈어요 (몇 백페이지 어떻게 다보나요… 필기도 CBT로 기출만 풀고 넘어왔습니다) 자격증 공부는 실질적인 개발 공부와 다른 측면이 있으니 자격증 준비는 정말 최소한의 비용으로 해야겠다고 마음 먹었습니다. 부가적으로 C언어 메모리 관련 지식과 CS 큰그림 정리만 얻자는 마음으로 준비했어요 그런 점에서 주말코딩 님 강의는 저의 목표와 매우 적합했습니다! 주말코딩 님도 수강생들에게 핵심만 집중적으로 공략해서 빠르게 합격하길 원하셨거든요. 모두 다른 할 일들이 많으니까요!! (주말코딩 정처기 인프런 강의: https://u.inf.run/3Bu7c2O) 2. 강사님 성향 & 실제 체감한 시험 경향 강사님 기본 전제는 100점 중 60점 넘으면 통과이므로 전체 5~60% 비중인 코딩 영역은 최대한 다 맞추자 (1개정도의 킬러문제는 그냥 틀리자) 이론 영역은 찍기도 가능하니 1~2개만 맞추자 를 강조하십니다. 납득이 되고 매우 합리적인 전략이에요. 이론 영역에 대해 조금 더 생각해볼 부분은 강사님께서 조금 보수적으로 잡고 말씀하신 부분이 있고, 실제 공부하다보면 이론은 1~2개보다 충분히 더 맞출 수 있습니다. 강사님이 중요한 부분만 정리한 총 1~2시간 정도 강의와 20페이지 정도되는 이론 요약집 제공해주세요. 항상 빈출되는 5~10가지 유형만 확실히 정리하고 가도 안정적으로 점수 추가 가능하다고 느꼈어요. 이외 나머지는 대차게 틀리면 됩니다! 다 맞출 필요가 없으니까요 🤣 사람이니까 코딩영역 실수해서 조금 더 틀려도 합격권 넉넉할거라고 느껴요. 코딩 영역은 주말 코딩님 이전 명성도 있고 실제로 강의를 워낙 잘해주셔서 정말 킬러 문항 1개만 틀리고 다 맞을 수 있습니다! 비전공자지만 독학한 베이스가 있긴해서 운좋게 킬러 문제도 건졌어요 실제로 시험을 봐보니 최근 시험 경향이 코딩 난이도를 높이고 이론은 너무 어렵게 안내는 느낌이 들었습니다. 이론이 최근 기출 포함해 항상 나오는 문제 주제로 5~10개 풀 정해놓고 돌려서 나오는 경향이라 그 부분만 확실해도 얘기했던 기존 목표인 이론 1~2개 맞추기보다 더 맞출 수 있을 것 같습니다. 결과적으로 코딩 문제는 다 맞추고, 이론에서 8점 깎였어요 (한 문제 틀리고, 한 문제 부분점수) “코딩만은 확실히”를 지향하는 주말 코딩님의 방식은 매우 타당했습니다 3. 공부 방법 당시 10일 정도 남았었고 2~3일 보통 숨고르기 시간으로 날리잖아요~ 하하하 그래서 저는 공부 전략을 다음과 같이 잡았습니다. [강의 중요 부분 수강 + 강사님 이론 요약집 외우기 + 이론만 잽싸게 기출 보기] [강의 중요 부분 수강] 강의는시간 관계상 부가적인 부분만 제끼고 최대한 들었습니다. (75프로 수강했네요) 비전공자지만 개발경험은 있어서 앞에 언어 공통 문법 부분이랑 뒤에 고난도 코드영역의 정렬만 제꼈습니다. (정렬 문제는 개념몰라도 주요 강의 내용만으로 코드 풀 수 있어요) 코딩 기출문제 풀이 강의는 무조건 하루 한개씩 들었고 다만 시간 관계상 강사님 C, Java, Python 변형문제 강의는 못들었어요 (기출 강의 중간중간에도 변형 문제는 소개해주셔서 다행히 괜찮았던 것 같아요) 고난도 코드영역에 SQL 기출문제는 꼭 챙겨봤습니다. 이렇게만 공부해도 코딩 + DB 영역 50점은 먹고 가요 (주말코딩 님 그는 정말…) 시험 3~4일전 강사님 이론 강의를 살살 듣기 시작했는데요 운영체제 페이지 교체 부분부터 정리했어요 기출보니 요즘 자주 나오더라구요! 요 영역이 조금 빡세보여도 강의듣고 하면 풀만해서 5점 가져가는 것 같아요 그리고 결국 시험 기간 이틀 전에서야 빡세게 이론 강의 완강하고 그 후 이론 요약집만 달렸어요 (머릿 속 이상적 계획과의 괴리…) [강사님 이론 요약집 외우기] 이론은 강사님 강조해주시는 영역 몇가지 있어요 주요 포인트 결합도/응집도, 테스트 스텁 및 드라이버, 테스트 종류와 방식 (블랙/화이트), 라우팅 프로토콜(RIP, OSPF…), 데이터베이스 이론(로킹, 상호배제 조건 등)… 시간 날 때 나머지 보안용어와 암호화 기법, OSI 7계층 주요 포인트만 확실히 하고 간다 생각했고 (결합도/응집도, 테스트 종류 방식 진짜 맨날 나와요) 추가로 디자인 패턴만 설명보고 용어 쓸 수 있게 준비했습니다. (+위에서 강의로 봤던 페이지 교체 부분도요!) 시간 날 때 나머지 부분도 요약집 내에서만 준비했어요 OSI 7계층에 용어들만 키워드 위주 암기 미리했고 (계층 이름, ARP, RARP, ICMP, IGMP 정도), 보안용어 암호화 기법은 시험가기 전 30분정도만 봤습니다. (운에 맞기고 틀려요 그냥~) 그래도 필기 때 한번 봤던 내용들이라 익숙함은 있더라구요 [이론만 잽싸게 기출 보기] 코딩 영역은 강의 기출 풀이로 거의 충분해서 이론 공부 병행하면서 이론 기출만 23년~24년도 빠르게 확인해봤습니다. 강의나 요약집에서 이미 봤던 기출도 있고 해서 이쯤이면 금방 빠르게 볼 수 있어요. 뉴비티 사이트가 필기 공부할 때 썼던 CBT 처럼 잘되어 있어서 공부하는 동안 잘 활용했어요. (뉴비티, https://newbt.kr/%EC%8B%9C%ED%97%98/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC+%EC%8B%A4%EA%B8%B0)) 4. 마무리 처음에는 실기 준비 어떻게 공부할지 고민했습니다. 아는 지인은 시중에 수제X 책 사서 했다더라구요. 제 성향에는 비효율적인 방법이었어요 컴팩트한 시간을 매우 중요시하는데 핵심을 벗어나 너무 폭넓게 공부해야 하니까요. 유튜브 검색을 통해 어쩌다 주말 코딩 님을 알게 되었는데, 강사님의 효율적인 학습 지향점을 듣고 바로 납득하고 강의 수강을 정했습니다. 플랫폼도 개발 컨텐츠에 친화적인 인프런이니까 수강기간 걱정없이 들을 수 있는 점이 신뢰와 안정감을 줬구요. 덕분에 처음 목표인 안정적 합격도 이뤘지만 보다 과하게 93점을 받았는데, 주말 코딩님 지향점의 장점 덕분이라 생각합니다. 언제나 느끼지만 핵심이 중요하다고 생각해요. 제 시험 준비 기록이 정보처리기사 준비하시는 다른 분들의 시간 절약 및 정신적 건강에 조금이나마 도움이 되었으면 좋겠습니다. (기록에는 시간을 아끼지 않았거든요 하핳) 준비하시는 모든 분들 파이팅하시고 쾌속 합격하시길 바랍니다! Reference [인프런 주말코딩] 일주일만에 합격하는 정보처리기사 실기 [뉴비티] 실기 기출 풀이 플랫폼

Blog · 2024-10-22

정보처리기사 실기 요점 정리

이론 준비 체크리스트 필수 - 모르면 시험 들어가면 안됨 테스트 종류와 방식 (블랙/화이트) 라우팅 프로토콜 데이터베이스 이론 중 약술형 나올만한 것 (로킹, 상호배제 조건 등) 결합도/응집도 테스트 스텁, 드라이버 나머지 보안용어와 암호화 기법, OSI 7계층 운영체제 메모리 관리 배치 전략: 프로세스를 통으로 메모리에 넣음 최초 적합(First-fit): 가장 앞부분부터 탐색하다가 처음 만난 곳에 넣음 최적 적합(Best-fit): 최대한 낭비 없이 넣음 (남는 공간이 가장 적은 공간에 할당) 최악 적합(Worst-fit): 제일 낭비되는 곳에 넣음 (가장 큰 공간에 할당) 가상 메모리 관리 (페이징 기법): 프로세스를 페이지로 나누어 가상 메모리로 올리고 교체 페이징 교체 알고리즘 OPT(Optimal): 향후에 가장 안쓰는 것을 빼기(미래를 알고있다 가정) FIFO(First-in First-out): 가장 먼저 온 것을 먼저 빼기 LRU(Least Recently Used): 사용한지 가장 오래된 것 빼기 LFU(Least Frequently Used): 참조 횟수가 가장 적은 페이지 교체 (참조횟수 같을 때는 가장 오래된것 빼는걸 기본으로 하자) MFU(Most Frequently Used): 참조 횟수가 가장 많은 페이지 교체 (참조횟수 같을 때는 가장 오래된것 빼는걸 기본으로 하자) NUR(Not Used Recently): 최근에 사용되지 않은 페이지 교체 CPU 스케줄링 알고리즘: 여러 프로세스를 CPU가 수행할 수 있게 연산 시간을 분배하는 것 선점형: 프로세스가 CPU 사용 중일 때, 더 높은 우선순위의 프로세스가 CPU 연산 빼앗아갈 수 있음 라운드로빈(Round-Robin): 모든 프로세스에 공평하게 시간 할당, 할당시간 실행 후 가장 뒤로 세움 SRT(Shortest Remaining Time First): 남은 시간이 가장 적은 프로세스를 우선 순위로 연산, 실행 중에 남은 시간이 더 적은 프로세스가 들어오면 그 프로세스를 먼저 해결 비선점형: 한 프로세스가 CPU를 차지하면, 끝날 때까지 다른 프로세스가 점유 불가 FCFS(First come, First Served): 먼저 온 프로세스 순으로 처리 (선착순) SJF(Shortest Job First): 실행 시간이 가장 짧은 프로세스를 먼저 처리 우선순위(Priority): 프로세스가 가지고 있는 우선순위 별로 먼저 처리 운영체제 목적 처리능력(Throughput) 향상 반환시간 단축 사용 가능도 향상 신뢰도 향상 페이지 VS 프레임 페이지: 프로세스를 자른 것 프레임: 물리 메모리를 자른 것 페이지 폴트(page fault): 프로그램이 참조하려는 페이지가 현재 메모리에 없는 상황 스레싱(Thrashing): 프로세스 처리 시간보다 페이지 교체 시간이 더 많아지는 현상 e.g. 프로세스 처리시간 1초, 페이지 교체 시간 2초 프로세스 상태 종류: 생성, 준비, 실행, 대기, 완료, 끝 교착상태: 여러 개의 프로세스가 특정 자원 할당을 계속 대기하면서 서로 소비 못하는 상황 조건: 상호배제, 점유와 대기, 비선점, 환형대기 해결방법: 예방, 회피, 발견, 복구 뮤텍스: 하나의 프로세스가 공유자원에 접근하는 동안, 다른 프로세스가 해당 자원에 접근 못하게 막는 도구 (락을 걸어줌) 세마포어: 운영체제에서 여러 프로세스가 공유 자원을 사용할 때 문제를 해결하는 동기화 도구 (보통 정수값으로 관리) 데이터 입출력 구현 데이터 모델링 순서 데이터베이스 계획 -> 요구사항 분석 -> 개념적 데이터 모델링: 개체타입, 속성 등 명시해서 현실 세계 반영 -> 논리적 데이터 모델링: 개념적 구조를 정규화하고 규칙과 관계 완성 (엔터티, 속성, 관계 구조적 정의) -> 물리적 데이터 모델링: 레코드 양식 순서, 경로 인덱싱, 클러스터링, 해싱 이상(Anomaly): DB 조작 시 비정상적으로 동작하는 현상 (삽입 이상, 갱신 이상, 삭제 이상) 정규화 제1 정규형 (1NF): 모든 속성이 원자값 제2 정규형 (2NF): 복합키일 때, 부분 함수 종속성 없어야 함 제3 정규형 (3NF): 이행 함수 종속성 없어야 함 보이스-코드 정규형 (BCNF): 모든 결정자가 후보키 되도록 해, 모든 함수적 종속성이 후보키에 의해 결정 제4 정규형 (4NF): 다치 종속성 없어야 함 (다치종속: 1개 속성에 여러 속성이 매핑) 제5 정규형 (5NF): 조인 종속성이 없어야 함 (조인종속: 여러 테이블 조합했을 때, 현재 결과 구성 가능) 샤딩: 대규모 데이터베이스 시스템에서 여러 개 독립적인 부분으로 분할하여 성능을 향상시키는 기술 인덱스: 추가적인 저장 공간을 활용해, 테이블의 검색 속도를 향상시키기 위한 자료구조 시스템 카탈로그: 데이터베이스에 저장되어 있는 데이터 개체들에 대한 정보가 수록되어 있는 시스템 분산 데이터베이스의 목표: 위치 투명성, 중복 투명성, 병행 투명성, 장애 투명성 데이터베이스 회복기법: 즉시갱신, 지연갱신, 검사시점, 그림자 페이징, 미디어 회복기법 서버 프로그램/인터페이스 구현 서버의 종류: 웹 서버, 웹 애플리케이션 서버, 데이터베이스 서버, 파일 서버 웹 서버: 정적 컨텐츠 처리, HTTP 요청 및 응답 처리 웹 애플리케이션 서버(WAS): 동적 컨텐츠, DB 연결 처리 응집도와 결합도 (매우 중요) 응집도 (강할수록 좋음) - 모듈 내부 코드들 간 기순교절시논우 (강한순서대로) 결합도 (강할수록 안좋음) - 모듈 간 내공외제스자 (강한순서대로) 공통 모듈 구현 절차 DTO/VO -> SQL -> DAO -> Service -> Controller -> View 매우 큰 소프트웨어의 분석 FAN-IN: 특정 모듈이 호출하는 모듈 (내가 부르는 것, 기준 모듈의 하위 모듈) FAN-OUT: 특정 모듈을 호출하는 모듈 (나를 부르는 것, 기준 모듈의 상위 모듈) 미들웨어: 서로 다른 소프트웨어 사이를 연결하는 중간다리 소프트웨어 e.g. JDBC, RabbitMQ, Apache Tomcat 인터페이스 설계: 데이터 주고 받을 때 노드 구성 방법 EAI(Enterprise Application Integration) - 큰 규모 회사 Point-to-Point Hub-and-Spoke Message Bus Hybrid ESB(Enterprise Service Bus) 서비스 지향 아키텍처(SOA)를 지원하는 기업 애플리케이션 통합을 위한 아키텍처 패턴 EAI 보완 화면설계/애플리케이션 테스트 UI 유형: CLI, GUI, NUI(Natural, 말이나 행동), OUI (Organic, 모든 사물) UI 설계원칙: 직관성, 유효성, 학습성, 유연성 UML 다이어그램 종류 구조적 다이어그램 (대표: 클래스 다이어그램, 객체 다이어그램) 행위적 다이어그램 (대표: 유스케이스 다이어그램, 순차 다이어그램, 상태 다이어그램) 애플리케이션 테스트 정적 테스트 동적 테스트 (중요) 화이트 박스 테스트: 코드를 오픈한 상태에서 논리적인 모든 경로 테스트 기초 경로 검사(Base Path Test): 모든 독립적인 실행 경로를 테스트하는 방법 제어 구조 검사: 조건 검사, 루프 검사, 데이터 흐름 검사 블랙 박스 테스트: 사용자 요구사항 명세서 보면서 동작 원리는 모르고 기능 작동해보며 테스트 동등 분할 검사 (Equivalence Partitioning) 입력 데이터를 유사한 특성을 가진 그룹으로 나누고, 각 그룹에서 대표값 선택해 테스트 경계값 분석 (Boundary Value Analysis) 입력 값의 경계 영역을 집중적으로 테스트 결정 테이블 테스트 (Decision Table Testing) 도표, 테이블을 만들어 입력에 따라 상태 변화 체크 상태 전이 테스트 (State Transition Testing) 입력에 따라 상태가 어떻게 변하는지 테스트 유스 케이스 테스트 (Use Case Testing) 사용자의 특정 행위 (유스 케이스) 따른 시스템 동작 테스트 오류 추정 (Error Guessing) 테스터의 경험과 직관을 바탕으로 오류 추정 및 테스트 테스트 평가 지표 구문 커버리지: 프로그램의 모든 구문이 한 번씩 실행될 수 있게 테스트 데이터 선정 결정 커버리지: 전체 결정문(조건문)을 테스트 하는 방법 조건 커버리지: 조건문 내에 참, 거짓을 적어도 한 번씩 결과가 나오도록 수행 조건/결정 커버리지: 전체 조건식과 개별 조건식이 참/거짓 한 번씩 나오게 (모든 결과 테스트) 변경조건/결정 커버리지: 각 개별 조건식이 독립적으로 영향주도록 테스트 다중조건/결정 커버리지: 모든 개별 조건식 모든 조합 다 커버리지 애플리케이션 테스트 기본원리 파레토 법칙: 애플리케이션의 20% 코드에서 전체 80% 결함이 발견됨 살충제 패러독스: 동일한 테스트 케이스 반복은 더이상 다른 결함 발견 못함 오류-부재의 궤변: 오류와 결함이 없더라도 요구사항을 만족하지 않으면 소프트웨어 품질은 낮은 것 완벽한 테스트 불가능: 테스트는 결함을 완전히 없애는 것이 아니라, 결함을 발견하는데 의의가 있음 테스트 하네스: 테스트 환경의 일부분으로 테스트를 지원하기 위해 생성된 코드나 데이터 테스트 드라이버 테스트 대상 모듈을 호출하는 더미 프로그램 (상향식 테스트 시, 임시로 만든 상위 모듈) 테스트 스텁 테스트 대상 모듈이 호출하는 프로그램 (하향식 테스트 시, 임시로 만든 하위 모듈) 관계대수 관계대수는 수학적 이론이고 이것을 구현해낸 것이 현재 컴퓨터과학의 데이터베이스 (RDBMS, SQL) 주로 나올 SQL SELECT, UPDATE, DELETE, INSERT INTO CREATE, ALTER, DROP CREATE INDEX, DROP INDEX 관계 대수 기호 프로젝션은 중복값을 제거하고 릴레이션 만듦 합집합도 중복값 제거하고 릴레이션 만듦 합집합: SQL의 UNION 교집합: SQL의 INTERSECT 제약조건 키워드 PRIMARY KEY, FOREIGN KEY(+REFERENCES) UNIQUE, NOT NULL, DEFAULT, CHECK, AUTOINCREMENT ON DELETE CASCADE, ON UPDATE CASCADE DCL GRANT 권한 ON 테이블 TO 유저 REVOKE 권한 ON 테이블 FROM 유저 조인 세타조인 조인에 참여하는 두 릴레이션의 속성 값을 비교하고, 조건을 만족하는 튜플만 반환 조건의 종류: =, ≠, ≤, ≥, ＜, ＞ 동등조인 세타조인에서 = (는) 연산자를 사용한 조인 가장 일반적으로 통용되는 “조인연산” 자연조인 동등 조인에서 조인에 참여한 속성이 두 번 나오지 않도록, 두 번째 속성을 제거한 결과를 반환 즉, 중복된 속성을 제거 세미조인 자연조인을 한 후에, 두 릴레이션 중에 한쪽 릴레이션의 결과만 반환 왼쪽과 오른쪽 중에 제거할 속성 쪽을 열어두는 형식으로 기호 작성 프로그래밍 코드 영역 외울 것 아스키 코드 A - 65 a- 97 문자 “0” - 48 완전수 (1~100 사이) 6, 28 문자열 상수풀 리터럴을 사용했을 때는 상수풀에 넣고 재사용 (같은 리터럴은 같은 참조객체를 쓴다) new String()은 참조값이 다른 아얘 새로운 객체 생성, 힙 영역에 저장 Integer 캐싱 (Double 같은 자료형은 캐싱이 없음) 자바는 -128~127 범위안에 정수는 캐싱해 재사용 (참조값 동일) e.g. Integer num = 100 만일, int와 Integer를 == 비교하면, 언박싱으로 인해 true 나옴 new Integer(100)은 역시 참조값이 아얘 다른 새로운 객체 생성, 힙 영역 저장 (Boolean 등등…도 new 하면 참조값 아얘 다른 새로운 객체) 비트 연산자 종류 &(and), |(or), ^(xor), ~(not) 비트연산 XOR XOR은 비트가 서로 다르면 1, 같으면 0 같은 XOR 연산을 3번하면 두 변수 값이 SWAP됨 e.g. a = a ^ b; b = a ^ b; a = a ^ b 비트연산 ~ 양수에 not을 취하는 경우 결과값: -(해당 양수 + 1) Reference (2024) 일주일만에 합격하는 정보처리기사 실기

General · 2024-10-18

2024 당근 테크 밋업 후기

2024 당근 테크 밋업 후기 올 해 운은 2024 당근 테크 밋업 당첨에 몰아서 다 쓴 모양이다. 당첨이 정말 어렵다고들 하는데 운 좋게도 생애 첫 밋업의 기회를 얻었다. 덕분에 기다리는 순간부터 오늘까지 설레고 유쾌한 시간의 연속이었다. 나이스한 당근 엔지니어 분들과의 만남, 만족스러운 럭키 드로우 등 흥미로운 일들에 대한 경험담을 살짝 남긴다. Frontend, Server, Data/ML, Platform 4가지로 파트가 나누어져 있었는데, 나는 서버 파트로 참여했다. 코엑스 컨퍼런스룸 3층으로 가니 예쁜 서체와 함께 행사장이 꾸며져 있었다. 입구부터 당근의 느낌(?)이 물씬 풍기는게 맘에 들었다. 입장할 때는 스태프분들이 팔에 당당한 밋업 참가자의 징표를 휘감아주었다. 뿌듯한 한 컷이다. 여담이지만, 행사장의 당근 관계자 분들은 다들 매우 친절하고 단합력이 좋았다. 서버 파트 강연 진행은 308호 공간에서 진행했는데, 도착하자마자 자리 잡고 강연을 듣는 형태였다. 다만, 이번 당근 밋업의 조금 특별한 점으로 당근 엔지니어가 주도하는 네트워킹 모임이 있었다. 규모는 4~8명으로 모임마다 다양하다. 밋업 몇 주 전부터 선착순으로 약 70개 넘는 주제로 네트워킹 참여 모집을 했는데, 실제로 행사 당일에 관련 주제를 가지고 서로의 경험과 대화를 나누는 네트워킹을 진행했다. (덕분에 당근 어플 모임 기능과 익숙해졌다.) 나는 주문 서비스에서 일한 경험이 있어, 당근페이 머니서비스 팀 네트워킹에 참여했다. 주문 서비스는 안정성과 데이터 정합성이 매우 중요한데, 당근페이 같은 큰 규모에서는 어떻게 관리하고 있는지 궁금했다. 모임을 주도하는 머니서비스팀 엔지니어 윈터, 윌리엄은 매우 나이스한 분들이었다. 당근페이에서 일했던 경험들을 자연스럽게 나누며 어떻게 생각하는지 참여자들과 서로 묻고 답했다. 함께 모인 다양한 개발자 및 기획자 분들도 유익한 질문들을 많이 던져주시더라. 이런 형태의 네트워킹이 처음이라 긴장을 많이 했는데, 화기애애한 분위기 속에서 머니서비스 팀이 극복했던 이슈와 앞으로의 목표를 진솔하게 들을 수 있었다. 잠시지만 좋은 분들과의 만남에 감사함을 가졌다. 첫 밋업이어서 이후에는 강연에 집중했다. 아직은 이해가 잘 되지 않는 내용도 많았지만 이런 이런 키워드들이 있구나를 알게된 것도 도움이 되었다. “빠르게 변하는 도메인에서 살아남는 코드”라는 주제도 재밌었다. 당근 운영개발팀은 루비 레거시의 압박 속에서 확장성과 설정 가능성을 목표로 최대한 OCP를 지키는 리팩터링을 했는데, 과정 속에서 메타 프로그래밍으로 접근한 점이 흥미로웠다. 리플렉션 같은 느낌으로 런타임에 코드 자체를 동적으로 변경하며 기능을 확장했는데, ‘현업에서 이렇게 적용할 수도 있겠구나’ 고민해보며 생각을 확장할 수 있었다. 마지막 세션인 “당근의 회원 시스템을 마이크로서비스로 분리하기”에서는 당근 Identity Service 팀이 회원 서비스를 안전하게 분리하기 위해 진행한 디테일한 테스트와 도구들을 소개했다. 안정성을 위해 굉장히 디테일한 부분까지 신경쓰는 점이 인상 깊었고, 덕분에 대규모 서비스에서는 얼마나 신중하고 단계적으로 접근해야하는지 느끼는 시간이었다. 큰 규모에서는 생각하는 각도가 더욱 중요하겠구나 싶다. 기쁘게도 젯브레인 에코백이 내게 왔다. 강연 중간중간마다도 이벤트가 있었는데, 마지막에는 설문조사에 참여한 모든 참여자에게 럭키 드로우 찬스가 주어졌다. 품목으로는 젯브레인 배지, 키캡, 스티커, 에코백 등의 경품이 있었다. 키캡이 매우 인기 있었지만, 개인적으로 개발자스러운 패션 굿즈로서 에코백이 가장 갖고 싶었다. 신기하게도 단번에 뽑았는데, 돌아봐도 당첨 운이 참 좋은 밋업 기간이었다. 밋업과 연관은 없지만 마지막엔 코엑스 내 클로리스 티 룸에 들려 밀크티 프로즌을 마셨다. 예전부터 좋아하는 곳인데 밀크티 음료 조합이 독특하고 맛이 참 좋다. 코엑스에 갈 일이 있다면 강력 추천한다. 2024 당근 밋업은 생애 첫 밋업이어서 더욱 기억에 남는다. 약 1000명에 가까운 IT 업계 종사자들이 한데 모이는 모습이 신기하면서 기분 좋은 자극이 되었다. 또한, 당근 엔지니어 분들의 기술에 대한 열정, 동료들과의 화목함을 보며 당근의 분위기가 참 좋다고 느꼈다. 앞으로 어떤 곳에서 일할지 모르지만, 당근 같은 건강한 분위기에서 또 다시 개발하길 다짐한다.

Blog · 2024-10-08

자바 멀티스레드와 동시성

Java-Ecosystem · 2024-10-02

멀티 스레드와 디자인 패턴

Process & Thread 차이 Thread는 서로 메모리 공유 O 문제 모든 Thread가 하나의 자료구조(e.g. queue)를 공유하면 자료구조가 망가질 것 해결책: 배타제어 (=동기화) Concurrent Class (동시성 컬렉션) Lock 특정 코드 구간을 반드시 한 Thread만 실행하도록 막음 (크리티컬 섹션) Lock을 건 코드 구간의 실행시간이 길수록 성능저하가 발생 최악의 경우 Single Thread가 차라리 나음 One Process, One Thread Architecture가 나온 이유 Redis도 처음에 이 아키텍처를 따름에도 매우 빨라서 인기 얻음 Lock Free Lock을 사용하지 않고 배타제어 관련 키워드: interlocked.increment(), Atomic Operation, Lock-Free 알고리즘, Non-Blocking 알고리즘, CAS(compare and set) Thread Safe하게 일반 Class 사용하기 Write는 한 Thread에서만, Read는 여러 Thread에서 진행하면 유용 Process는 서로 메모리 공유 X 문제 Process끼리는 메모리 공유가 안되기 때문에, 통신이 필요 (HTTP, TCP…) MSA를 지향하는 현대 사회에서는 Process간 통신 필수 MSA = Multi Process Multi Process 필요성 서버 머신 한 대 성능에는 한계, Scale Out 필수! 서버 Architecture 구상하는 입장에서는 Process 하나가 작은 기능을 담는 것이 훨씬 유리 (One Process, One Thread가 설득력 얻는 부분) 언어가 다른 Process끼리는 서로 패킷 주고 받는게 스트레스 해결책: Multi Process 간 통신 방법 서버 간 통신 방법 Google Protobuf, Apache Avro (Good) IDL 파일에 모델을 정의해두면 Java, C++, JS, C# 등 여러 언어에서 사용 가능 JSON (Bad) 필드 추가시 상대방에게 알려주기 어려움 오타로 인한 디버깅 Cost 데이터를 어딘가에 올려놓고 필요한 서버가 알아서 가져가게 하는 방법 Redis Pub/Sub 특정 key에 데이터를 넣고 Pub/Sub Queue 이용하기 (AWS SQS) Queue에 넣고 데이터가 추가됐을 때, 특정 Topic으로 Event 받기 제 3 스토리지를 이용하는 것이므로 상대적으로 느림 빠르게 통신할 필요가 없는 경우 이용 웹서비스는 느리다는 느낌은 안듦 TCP 실시간 통신 서비스는 느리다 느낄 수 있음 Thread Thread란? 흐르는 시냇물 위에 띄워놓은 돛단배 스레드 스타트 이후 계속 원하는 작업들이 진행될 것이고 내 손을 떠나도 계속 돌아감 Entrypoint (진입점) public static void Main(String[] args) {} Process가 맨 처음 실행하는 함수, 함수가 종료되면 Process도 종료 Main Thread에서 실행 쓰레드 사용하기 var thread = new Thread(Func); 스레드 생성 thread.Start(); Thread 생성자에 넣어준 함수를 별도의 스레드에서 실행 thread.Join(); 스레드가 종료될 때까지 대기함 (Blocking) Blocking & Non-Blocking Blocking 함수를 실행하고 모든 코드가 완료된 후 리턴 Non-Blocking 실행한 함수의 코드가 완료되지 않고 리턴 Non-Blocking 함수의 실행과 완료를 아는 방법 Polling 주기적으로 확인하기 어떤 스레드에서 isFinish에 true 값을 넣으면 스레드 실행의 완료를 파악 while(true) { if (isFinish == true) { Break; } sleep(1000); //CPU 100%되지 않게 } e.g. HTTP 통신 Event Event가 발생했을 때 내가 원하는 함수를 호출해줌 setTimeout(callback, 1000); //1초 후 callback 함수 실행 콜백 지옥 유의 (요즘은 async & await 사용) async & await 장점은 무엇인가요? 멀티스레드 프로그래밍(비동기 실행)을 하지만 Blocking 방식으로 진행해서 편함 **콜백지옥 피할 수 있음 ** public async function Task<string> GetString() { ... } string result = await GetString(); Console.Write(result); getString() 함수는 다른 스레드에서 실행되지만 Blocking 방식으로 호출 = 비동기로 실행하지만 Blocking 방식 Server Thread Model 웹 서버, TCP 서버 등 서버 구현에 일반적으로 사용되는 스레드 모델 생산자 소비자 문제와 일치 생산자: I/O 스레드 (혹은 Worker 스레드라 부르기도 함) 네트워크 카드가 요청 데이터를 읽으면, I/O 스레드에서 해당 데이터를 Job Queue로 넘김 네트워크 카드 메모리가 매우 작으므로, 패킷이 가득차지 않게 작업만 빠르게 넘김 웹 서버나 프레임워크가 생산을 처리해 줌 Buffer: Job Queue Job Queue는 메인 메모리에 위치 e.g. 웹이라면 request들이 담김 소비자: Worker Thread (혹은 Logic 스레드라 부르기도 함) Worker Thread가 Job Queue에 작업들을 읽어서 처리 무거운 작업들 실행 (DB 접속, Redis 통신) 무거운 작업이라 오래 걸리지만, 최대한 빨리 실행되도록 해야 함 빨리 동작하지 않으면 Job Queue에 데이터가 차서 서비스 응답이 느려짐 일반적으로 개발자가 짠 로직은 Worker 스레드에서 돌아가는 코드를 짠 것 IOCP, EPoll OS에서 제공하는 비동기 I/O 작업을 하기 위한 기술이다. 즉, I/O 요청을 하면 비동기로 처리해주고 결과도 비동기로 받게 된다. Windows에는 IOCP, Linux에는 Epoll이라는 기능이 이에 해당한다. Guarded Suspension 패턴 할 일이 없는 Thread는 대기열에 넣고 할 일이 생기면 대기열에서 빼서 실행해주는 패턴 작업이 있으면 깨우고 없으면 쉼 Balking 패턴 내가 해야될 작업이 있는지 주기적으로 확인 (반복문) 작업이 있으면 하고 없으면 무시 (RUNNABLE) 스레드가 계속 동작하므로 작업이 없을 때 해야할 동작을 지정할 수도 있음 Read-Write Lock 패턴 Read 락과 Write 락을 따로 두는 락 메커니즘 한 스레드가 Write할 때는 다른 스레드가 Read 및 Write 모두 불가능 한 스레드가 Read할 때는 다른 스레드도 Read 가능 Read 스레드가 많고 Write 스레드가 좀 적다면, Read 성능 효율이 향상 Read 할 때는 Write를 하는지 안하는지만 판단 Read를 더 편하고 자유롭게 할 수 있음 만일, 사용한다면 각 언어에 구현된 클래스 찾아 사용할 것 Thread-Per-Message 패턴 하나의 작업 당 하나의 Thread가 실행하도록 위임 스레드 개수가 너무 많아지면 컨텍스트 스위칭 오버헤드가 높아져 성능 저하 Future 패턴 Main 스레드가 다른 스레드에 작업을 위임하고 본인 스스로도 다른 작업을 할 수 있게 하는 패턴 Thread-Specific Storage 패턴 스레드 마다 별도의 저장 공간을 가지게 하는 패턴 = 스레드 로컬: 각 스레드 별로 사용할 수 있는 변수 Reference Backend 멀티쓰레드 이해하고 통찰력 키우기

Computer Science · 2024-09-29

자바 Collection Framework

Java-Ecosystem · 2024-09-05

자바 제네릭

Java-Ecosystem · 2024-09-04

자바 예외 기본

예외 계층 Object: 모든 객체의 최상위 부모 Throwable: 최상위 예외, 잡으면 안됨 (Error까지 잡히므로) Error 애플리케이션에서 복구 불가능한 시스템 예외 (메모리 부족, 심각한 시스템 오류…) 애플리케이션 개발자는 이 예외를 잡지 않아야 함 언체크 예외 Exception: 체크 예외 (런타임 예외 제외), 애플리케이션에서 개발자가 잡아야 할 실질적최상위 예외 RuntimeException: 언체크 예외 (=런타임 예외) 체크예외 VS 언체크 예외 핵심 언체크 예외는 throws 선언하지 않고 생략 가능 (자동 예외 던지기) 나머지는 동일 체크 예외 컴파일러가 체크하는 예외 체크 예외의 장단점 예외를 누락하지 않도록 컴파일러가 안전 장치 역할 (누락 시 컴파일 오류) 크게 신경쓰지 않고 싶은 예외까지 모두 반드시 잡거나 던져야 함 언체크 예외 컴파일러가 체크하지 않는 예외 중요 예외의 경우 throws를 선언해두면 IDE를 통해 개발자가 편리하게 인지 가능 (보통은 생략) 언체크 예외의 장단점 신경쓰고 싶지 않은 언체크 예외 무시 가능 개발자가 실수로 예외 누락 가능 예외 처리 기본 기본 규칙 예외는 잡아서 처리하거나 던져야 한다 예외를 잡는 코드: catch 예외를 던지는 코드: throws 예외를 잡거나 던질 때 지정한 예외 뿐만 아니라 그 예외의 자식들도 함께 처리된다 기본적으로 언체크(런타임) 예외를 사용하자 체크 예외들은 바깥으로 던져야 하는데 이 과정에서 의존 관계 문제 발생 실무에서 발생하는 대부분의 예외는 복구 불가능한 시스템 예외 (애플리케이션 단에서 처리 불가) 의존 관계 문제 컨트롤러, 서비스는 본인이 처리할 수 없어도 throws를 선언해 예외를 던져야 함 컨트롤러, 서비스가 해당 체크 예외에 의존하게 되어 구현 기술 변경 시 OCP 위반 예를 들어, DB 접근 기술을 변경한다면 예외를 포함한 컨트롤러, 서비스 코드를 수정 수 많은 체크 예외를 일일이 명시해 던지는 것도 부담 런타임 예외를 사용하면 처리할 수 없는 예외를 별도 선언 없이 그냥 두면 됨 의존성 발생 X -> 기술 변경이 있어도 컨트롤러, 서비스 코드 변경 X -> OCP 준수 대부분의 최근 라이브러리는 런타임 예외를 기본으로 제공 (스프링, JPA…) 런타임 예외는 놓칠 수 있기 때문에 문서화가 중요 (혹은 명시적으로 코드에 throws 남기기) 처리할 수 없는 예외들은 한 곳에서 공통처리 서블릿 오류 페이지, 스프링 MVC ControllerAdvice 예외 공통 처리 고객: 오류 페이지 내부 개발자: 별도 로그, 슬랙, 문자, 메일을 통해 개발자가 빠르게 인지 API는 상태코드 500 응답 예시 코드 public class Main { public static void main(String[] args) { NetworkService networkService = new NetworkService(); try { networkService.sendMessage(); } catch (Exception e) { // 모든 예외를 잡아서 처리 exceptionHandler(e); } } //공통 예외 처리 private static void exceptionHandler(Exception e) { //공통 처리 System.out.println("사용자 메시지: 죄송합니다. 알 수 없는 문제가 발생했습니다."); System.out.println("==개발자용 디버깅 메시지=="); e.printStackTrace(System.out); // 스택 트레이스 출력 //e.printStackTrace(); // System.err에 스택 트레이스 출력 //실무에서는 보통 Slf4j 사용해 로그를 콘솔 출력 + 파일로 저장 //e.printStackTrace는 콘솔에만 출력하므로 사용 X //필요하면 예외 별로 별도의 추가 처리 가능 if (e instanceof SendException sendEx) { System.out.println("[전송 오류] 전송 데이터: " + sendEx.getSendData()); } } } 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용 매우 심각한 문제는 개발자가 실수로 예외를 놓치면 안된다고 판단할 수 있음 체크 예외 예시 (무조건 해야하는 건 아님) 계좌 이체 실패 예외 결제시 포인트 부족 예외 로그인 ID, PW 불일치 예외 Exception을 던지지 말자 코드가 깔끔해지는 것 같지만, 모든 체크 예외를 다 던져 버려서 중요한 체크 예외를 놓침 꼭 필요한 경우가 아니면 Exception 자체를 밖으로 던지는 것은 좋은 방법이 아님 스택 트레이스를 남기자 로그 남기기 log.info("예외 처리, message={}", e.getMessage(), e); 로그의 마지막 인수에 예외 객체 전달하면 로그에 스택 트레이스를 출력 예외를 전환할 때는 반드시 기존 예외를 포함하자 throw new RuntimeSQLException(e); - 기존 예외 e 포함 덕분에 기존 예외와 스택 트레이스까지 확인 가능 포함하지 않으면 실제 DB에서 발생한 근본적인 원인을 확인할 수 없는 심각한 문제 발생 예외를 계속 던지면 벌어지는 상황 자바 main() 쓰레드의 경우 예외 로그를 출력하면서 시스템이 종료 웹 애플리케이션의 경우 WAS가 예외를 받아 처리하고 개발자가 지정한 오류 페이지 보여줌 (예외 하나로 시스템이 종료되면 안됨) 사용자 예외 만들기 Exception을 상속 받으면 체크 예외 RuntimeException을 상속 받으면 언체크 예외 오류 메시지 보관하기 생성자를 통해 오류 메시지를 보관할 것 (예외가 제공하는 기본 기능) super(message)로 전달한 메시지는 Throwable의 detailMessage에 보관됨 getMessage()로 조회 가능 public class MyCheckedException extends Exception { public MyCheckedException(String message) { super(message); } } 적당한 예외 계층화하기 (너무 많아도 문제) 상속을 사용해 예외를 계층화하면 보다 세밀한 예외 처리 가능 e.g. NetworkClientException (부모) ConnectException (자식, 내부 연결 시도 address 보관) SendException (자식, 내부 전송 시도 데이터 sendData 보관) 각각의 하위 예외에 고유 기능을 만들어 활용 가능 e.g. e.getAddress(), e.getSendData() 부모 예외를 잡아 자식까지 한 번에 처리하거나 특정 하위 예외만 잡아 처리 가능 중요한 특정 하위 예외만 메시지를 명확히 남기고 나머지는 공통 처리 가능 e.g. [연결 오류] 주소: ... (하위 예외) [네트워크 오류] 메시지: ... (부모 예외) [알 수 없는 오류] 메시지: ... (그 외 예외 공통 처리) 예외 처리 발전 과정 예시 (e.g. NetworkClient) 반환 값(문자열)으로 예외 처리 분기 처리 및 return으로 네트워크 연결 및 해제, 데이터 전송 관리 등이 가능 가장 중요한 정상 흐름이 한눈에 들어오지 않음 (정상 흐름과 예외 흐름 분리 X, 가독성 감소) 예외 처리 메커니즘 사용 (try ~ catch ~ finally) 성공 여부를 반환값이 아닌 메서드 정상 종료 여부로 판단 정상 흐름과 예외 흐름을 명확히 분리해 가독성 상승 (try 블록, catch 블록) 반드시 실행되어야 하는 코드를 안전하게 호출하도록 보장 (finally) finally가 없으면 catch에서 잡지 못한 예외가 발생할 때 문제가 생김 외부 자원 해제 등에 편리 finally finally 블록은 어떤 경우라도 반드시 호출된다. 주로 try에서 사용한 자원을 해제할 때 사용한다. 예외를 직접 잡을 일이 없다면, try ~ finally만 사용하는 것도 가능하다. 정상 흐름 (try) -> finally 예외 잡음 (catch) -> finally 예외 던짐 -> finally (finally 블록 끝난 이후 예외가 밖으로 던져짐) 자원 해제 외부 리소스는 사용 후 반드시 연결을 해제하고 자원을 반납해야 메모리 고갈을 피할 수 있다. (네트워크 연결 자원, DB 연결 자원…) 자바는 GC로 JVM 메모리 상 인스턴스들을 자동으로 해제하지만, 외부 연결 같은 자바 외부 자원은 자동으로 해제되지 않는다. 여러 예외 한 번에 잡는 Syntax catch 블록에서 | 키워드를 사용해 예외를 나열할 수 있다. 다만, 이 경우 각 예외들의 공통 부모 기능만 사용할 수 있다. e.g. catch (ConnectException | SendException e) {...} // 이 경우 공통 부모인 NetworkClientException의 기능만 사용 가능 try-with-resources 구문 finally 없이 편리한 외부 자원 해제 지원 사용 방법 외부 자원 클래스에 AutoCloseable 인터페이스를 구현 (implements AutoCloseable) close() 메서드를 오버라이드해 자원 반납 방법 정의 메서드가 예외를 던지지 않으면 인터페이스의 throws Exception은 생략 try-with-resources 구문 사용 try (Resource resource = new Resource()) { // 리소스를 사용하는 코드 } try 괄호 안에 사용할 자원을 명시 e.g. try (NetworkClient client = new NetworkClient(address)) {...} try 블록이 끝나면 자동으로 AutoCloseable.close() 호출해 자원 해제 try 블록만 단독으로도 사용 가능 (catch, finally 없이 사용 가능) 장점 리소스 누수 방지 실수로 finally 블록 혹은 그 내부에 자원 해제 코드를 누락하는 문제 예방 코드 간결성 및 가독성 향상 리소스 스코프 범위 한정 리소스 객체 변수의 스코프를 try 블록으로 한정해 코드 유지보수성 향상 조금 더 빠른 자원 해제 기존에는 catch 이후에 자원을 반납 (try -> catch -> finally) try with resources는 try 블록이 끝나면 즉시 close() 호출 Reference 김영한의 실전 자바 - 중급 1편

Java-Ecosystem · 2024-08-24

자바 중첩 클래스

Java-Ecosystem · 2024-08-17

자바 날짜 시간 라이브러리

날짜 시간 라이브러리의 필요성 날짜 라이브러리는 복잡한 계산을 추상화해 제공하므로, 안정적이고 정확한 개발 가능 자바 8에서 java.time 패키지(JSR-310)를 표준 API(기능의 모음)로 도입 외부 라이브러리였던 Joda-Time의 개발자를 데려와 새로운 자바 표준 API를 함께 정의 이전 문제가 많던 API를 크게 개선 (사용성, 성능, 스레드 안정성, 타임존 처리, 불변 객체 설계 등) 날짜 계산이 어려운 이유 각 달은 28~31일로 다르게 분포 윤년 (Leap Year) 지구가 태양을 한 바퀴 도는 평균 시간은 약 365.2425일 (약 365일 5시간 48분 45초) 우리가 사용하는 그레고리력은 1년이 365일 윤년은 둘의 간극을 매우기 위한 해결책으로 4년마다 하루를 추가 (2월 29일) 100년 단위는 윤년이 아니며 400년 단위는 다시 윤년 일광 절약 시간 (Daylight Saving Time, DST) - 썸머타임 보통 3월 중순~11월 초 태양이 일찍 뜨는 것에 맞춰 1시간 앞당기는 제도 국가나 지역에 따라 적용 여부 및 시작 종료 날짜가 다름 타임존 계산 각각의 타임존은 UTC(세계 협정시)로부터의 시간 차이로 정의 London / UTC / GMT는 세계 시간의 기준이 되는 00:00 시간대 GMT (그리니치 평균시, Greenwich Mean Time) 처음 세계 시간은 영국 런던 그리니치 천문대를 기준으로 만듦 UTC (협정 세계시, Universal Time Coordinated) GMT를 대체하기 위해 도입 (둘은 실질적으로 같은 시간대) 다만, UTC는 원자 시계를 사용해 측정해 보다 정확한 시간 유지 타임존 예시 Europe/London GMT UTC America/New_York -05:00 Asia/Seoul +09:00 자바 날짜 시간 라이브러리 (time) - 클래스 분류표 유의점 모든 날짜 클래스는 불변 -> 변경이 발생하는 경우 새로운 객체를 생성해 반환 초는 나노초 정밀도로 캡처 가능 Year, Month, YearMonth, MonthDay: 자주 사용 X DayOfWeek: 월, 화, 수, 목, 금, 토, 일을 나타내는 Enum (ChronoField) 날짜와 시간 핵심 인터페이스 TemporalAccessor 인터페이스 날짜와 시간을 읽기 위한 기본 인터페이스 날짜와 시간의 2가지 개념 (특정 시점의 시간 & 시간의 간격) Temporal 인터페이스 - 특정시점의 시간 날짜와 시간을 조작하기 위한 기능 추가 제공 상위 인터페이스 덕분에 읽기와 쓰기 모두 지원 구현체 LocalDateTime, LocalDate, LocalTime ZonedDateTime, OffsetDateTime Instant TemporalAmount 인터페이스 - 시간의 간격 특정 날짜 시간 객체에 일정 기간을 더하거나 빼는데 사용 구현체 Period , Duration 시간의 단위와 필드 - 단독 사용 X, 날짜 시간 조회나 조작에 사용 TemporalUnit 인터페이스 - 시간의 단위 날짜와 시간을 측정하는 단위 구현체(Enum): ChronoUnit 시간: NANOS, MICROS, MILLIS, SECONDS, MINUTES, HOURS 날짜: DAYS, WEEKS, MONTHS, YEARS, DECADES, CENTURIES, MILLENNIA 기타: ERAS, FOREVER 주요 메서드 between(Temporal, Temporal) 두 Temporal 객체 사이의 시간을 현재 ChronoUnit 단위로 측정하여 반환 e.g. LocalTime lt1 = LocalTime.of(1, 10, 0); LocalTime lt2 = LocalTime.of(1, 20, 0); long secondsBetween = ChronoUnit.SECONDS.between(lt1, lt2); long minutesBetween = ChronoUnit.MINUTES.between(lt1, lt2); getDuration() 현재 ChronoUnit의 기간을 Duration 객체로 반환 e.g. ChronoUnit.HOURS.getDuration().getSeconds() //3600 ChronoUnit.DAYS.getDuration().getSeconds() //86400 TemporalField 인터페이스 - 시간의 각 필드 날짜와 시간의 특정 부분을 나타냄 (연도, 월, 일, 시간, 분) 예를 들어, 일(day)은 31보다 클 수 없는 것처럼 범위가 생김 구현체(Enum): ChronoField 연도: ERA, YEAR_OF_ERA, YEAR, EPOCH_DAY 월 MONTH_OF_YEAR: 월 (1월 = 1) 주 및 일 DAY_OF_MONTH: 월의 일 (1일 = 1) DAY_OF_WEEK: 요일 (월요일 = 1) DAY_OF_YEAR: 연의 일 (1월 1일 = 1) 시간 HOUR_OF_DAY: 시간 (0-23) HOUR_OF_AMPM: 오전/오후 시간 (0-11) CLOCK_HOUR_OF_DAY: 시계 시간 (1-24) CLOCK_HOUR_OF_AMPM: 오전/오후 시계 시간 (1-12) MINUTE_OF_HOUR: 분 (0-59) SECOND_OF_MINUTE: 초 (0-59) MILLI_OF_SECOND: 초의 밀리초 (0-999) MICRO_OF_SECOND: 초의 마이크로초 (0-999,999) NANO_OF_SECOND: 초의 나노초 (0-999,999,999) 기타 AMPM_OF_DAY: 하루의 AM/PM 부분 주요 메서드 range() 필드 값의 유효 범위를 ValueRange 객체로 반환 (최소값과 최대값을 제공) e.g. ChronoField.MONTH_OF_YEAR.range() //1 - 12 ChronoField.DAY_OF_MONTH.range() //1 - 28/31 Temporal - 특정 시점의 시간 기본 날짜 시간 표현 (LocalXxx) 특정 지역의 날짜와 시간만 고려할 때 사용 (타임존 적용 X, 시간대 고려 X) 국내 서비스만 고려할 때 권장 종류 LocalDate: 날짜만 표현 (년, 월, 일) 예) 2013-11-21 LocalTime: 시간만 표현 (시, 분, 초) 예) 08:20:30.213 밀리초, 나노초 단위도 포함 가능 LocalDateTime: LocalDate + LocalTime 예) 2013-11-21T08:20:30.213 클래스 내부에 LocalDate와 LocalTime을 필드로 가지고 있음 public class LocalDateTime { private final LocalDate date; private final LocalTime time; ... } 주요 메서드 공통 메서드 생성 now(): 현재 시간 기준으로 생성 of(...): 특정 날짜를 기준으로 생성 계산 dt.plusXxx(): 특정 날짜 시간 단위를 더함 e.g. plusYears(1), plusDays(10), plusSeconds(30) LocalDatetime 날짜와 시간 분리 dt.toLocalDate(): 주어진 LocalDateTime에서 날짜만 반환 dt.toLocalTime(): 주어진 LocalDateTime에서 시간만 반환 날짜와 시간 합체 of(...): 날짜와 시간을 묶어서 LocalDateTime으로 만들기 e.g. LocalDateTime.of(localDate, localTime) 비교 dt.isBefore(): 현재 날짜시간이 지정 날짜시간보다 이전이라면 true 를 반환 dt.isAfter(): 현재 날짜시간이 지정 날짜시간보다 이후라면 true 를 반환 dt.isEqual(): 현재 날짜시간과 지정 날짜시간 시간적으로 동일하면 true 를 반환 isEqual() 객체가 다르고 타임존이 달라도 시간적으로 같으면 true e.g. 서울의 9시와 UTC의 0시는 시간적으로 동일 equals() 객체 타입, 타임존 등등 내부 데이터의 모든 구성요소가 같아야 true e.g. 서울의 9시와 UTC의 0시는 타임존이 다르므로 false 시간대 적용 날짜 시간 표현 (ZonedDateTime, OffsetDateTime) 글로벌 서비스 개발 시에만 사용 (그러지 않으면 거의 사용 X) 용어 타임존(Time Zone) 오프셋과 일광 절약 시간제에 대한 정보 담김 -> 타임존을 알면 일광 절약 시간제를 알 수 있음 예) Asia/Seoul 오프셋(Offset) UTC로 부터의 시간대 차이 예) +9:00 종류 ZoneId 자바가 제공하는 타임존 클래스 내부에 오프셋과 일광 절약 시간제 정보 포함 ZonedDateTime 시간대를 표현하는 타임존이 포함 (LocalDateTime + ZoneId) 일광 절약 시간제 적용 실제 사용 날짜와 시간 정보 표현에 적합 (비행기 시간, 회의 시간, 일상 시간 표현…) 예) 2013-11-21T08:20:30.213+9:00[Asia/Seoul] 클래스 내부에 LocalDatetime, ZoneId, ZoneOffset을 필드로 가지고 있음 public class ZonedDateTime { private final LocalDateTime dateTime; private final ZoneOffset offset; private final ZoneId zone; ... } OffsetDateTime 타임존은 없고, 고정된 오프셋만 포함 (LocalDateTime + ZoneOffset) 일광 절약 시간제 적용 X 시간대 변환 없이 로그를 기록하고 처리할 때 적합 로그는 순차적으로 쌓여야 함, 썸머타임 적용으로 1시간 당겨지는 상황 있으면 안됨 예) 2013-11-21T08:20:30.213+9:00 클래스 내부에 LocalDatetime, ZoneOffset을 필드로 가지고 있음 public class OffsetDateTime { private final LocalDateTime dateTime; private final ZoneOffset offset; ... } 주요 메서드 공통 메서드 생성 now(): 현재 시간 기준으로 생성 (ZoneId는 현재 시스템을 따름) of(...): 특정 날짜를 기준으로 생성 ZonedDatetime of(...) 사용법 단순 생성 ZonedDateTime zdt = ZonedDateTime.of(2030, 1, 1, 13, 30, 50, 0, ZoneId.of("Asia/Seoul")); LocalDatetime + ZoneId로 생성하기 LocalDateTime ldt = LocalDateTime.of(2030, 1, 1, 13, 30, 50); ZonedDateTime zdt = ZonedDateTime.of(ldt, ZoneId.of("Asia/Seoul")); 타임존 변경하기 zdt.withZoneSameInstant(): 입력한 타임존으로 변경 e.g. zdt.withZoneSameInstant(ZoneId.of("UTC")) OffsetDatetime of(...) 사용법 LocalDatetime + ZoneOffset로 생성하기 LocalDateTime ldt = LocalDateTime.of(2030, 1, 1, 13, 30, 50); OffsetDateTime odt = OffsetDateTime.of(ldt, ZoneOffset.of("+01:00")); 이외 ZoneId getAvailableZoneIds(): 이용 가능한 모든 ZoneId 반환 systemDefault(): 시스템이 사용하는 기본 ZoneId 반환 of(...): 타임존을 직접 제공해서 ZoneId로 변환 e.g. ZoneId.of("Asia/Seoul") 기계 중심의 시간 (Instant) UTC를 기준으로 하는 시간의 한 지점 1970년 1월 1일 0시 0분 0초(UTC)를 기준으로 경과한 시간으로 계산 (초 데이터) 클래스 내부에 초 데이터를 필드로 가짐 (나노초 정밀도) public class Instant { private final long seconds; private final int nanos; ... } 일반적으로 LocalDateTime , ZonedDateTime를 사용하고 Instant는 특별한 경우에 사용 기준점이 명확하나(UTC), 사람이 읽기 어렵고 초 단위 간단한 연산만 가능 사용 예 로그 기록, 트랜잭션 타임스탬프, 서버 간 시간 동기화 등 전 세계적으로 일관된 시점 표현 시 지속 시간 계산 등 시간대 변화 없는 순수한 시간 흐름만을 다룰 때 DB에 날짜 시간 저장하거나 다른 시스템과 날짜 시간 정보를 교환할 때 주요 메서드 생성 now() UTC를 기준 현재 시간의 Instant 를 생성 from() 다른 타입의 날짜와 시간을 기준으로 Instant 를 생성 LocalDateTime 사용 불가 (Instant 는 UTC 기준이어서 시간대 정보가 필요) e.g. ZonedDateTime zdt = ZonedDateTime.now(); Instant from = Instant.from(zdt); ofEpochSecond() 에포크 시간을 기준으로 Instant 를 생성 ofEpochSecond(0) -> 에포크 시간인 1970년 1월 1일 0시 0분 0초로 생성 ofEpochSecond(30) -> 1970/1/1/0/0/30 계산 plusSeconds() : 초, 밀리초, 나노초 정도만 더하는 간단한 메서드 조회 getEpochSecond() : UTC 1970년 1월 1일 0시 0분 0초를 기준으로 흐른 초를 반환 Epoch 시간 Epoch time(에포크 시간) 또는 Unix timestamp는 컴퓨터 시스템에서 시간을 나타내는 방법 중 하나이다. 1970년 1월 1일 00:00:00 UTC부터 현재까지 경과된 시간을 초 단위로 표현한 것이다. 즉, 시간대에 영향을 받지 않는 절대적인 시간 표현 방식이다. Instant는 Epoch 시간을 다루는 클래스이다. TemporalAmount - 시간의 간격 (기간, 시간의 양, amount of time) 년, 월, 일 단위 표현 (Period) 클래스 내부에 년, 월, 일을 필드로 가짐 public class Period { private final int years; private final int months; private final int days; } 주요 메서드 생성 of() : 특정 기간을 지정해서 Period 를 생성 of(년, 월, 일) ofDays() ofMonths() ofYears() 계산 더하기 특정 날짜 인스턴스의 plus() 메서드를 사용해 기간을 더할 수 있음 e.g. LocalDate currentDate = LocalDate.of(2030, 1, 1); Period period = Period.ofDays(10); LocalDate plusDate = currentDate.plus(period); between(): 기간 차이 구하기 (Period 반환) LocalDate startDate = LocalDate.of(2023, 1, 1); LocalDate endDate = LocalDate.of(2023, 4, 2); Period between = Period.between(startDate, endDate); //Period 반환 조회 getYears(), getMonths(), getDays() 시, 분, 초(나노초) 단위 표현 (Duration) 클래스 내부에 초 데이터만 필드로 가짐 내부에서 초를 기반으로 시, 분, 초를 계산해서 사용 public class Duration { private final long seconds; private final int nanos; } 주요 메서드 생성 of() : 특정 시간을 지정해서 Duration 를 생성 of(지정) ofSeconds() ofMinutes() ofHours() 계산 더하기 특정 시간 인스턴스의 plus() 메서드를 사용해 시간을 더할 수 있음 e.g. LocalTime lt = LocalTime.of(1, 0); Duration duration = Duration.ofMinutes(30); LocalTime plusTime = lt.plus(duration); between(): 시간 차이 구하기 (Duration 반환) LocalTime start = LocalTime.of(9, 0); LocalTime end = LocalTime.of(10, 0); Duration between = Duration.between(start, end); //Duration 반환 조회 get은 바로 가져오는 느낌, to는 계산을 하는 느낌 (Duration은 내부에 초 데이터만 보유) toHours(), toMinutes() getSeconds(), getNano() 일반적인 x시간 x분을 출력할 때는 toHoursPart() + toMinutesPart() 조합 사용 toHoursPart(), toMinutesPart(), toSecondsPart() 날짜와 시간 조회 및 조작 일관성 있는 시간 조회 및 조작 기능 제공 (인터페이스 설계가 잘되어 있음) 불변 객체이므로 메서드 체이닝 가능 기본 규칙 조회 방법 편의 메서드 사용 (가독성을 위해 권장) 자주 사용하는 조회 필드는 간단한 편의 메서드 제공 getYear(), getMonthValue(), getDayOfMonth(), getHour(), getMinute(), getSecond(), getDayOfWeek() TemporalAccessor.get(TemporalField field) ChronoField 인수로 전달해, 날짜 시간 객체에서 원하는 단위로 조회 가능 get(ChronoField.YEAR), get(ChronoField.MONTH_OF_YEAR), get(ChronoField.DAY_OF_MONTH), get(ChronoField.HOUR_OF_DAY), get(ChronoField.MINUTE_OF_HOUR), get(ChronoField.SECOND_OF_MINUTE), get(ChronoField.DAY_OF_WEEK) 편의 메서드에 없는 경우 사용 조작 방법 편의 메서드 사용 자주 사용하는 메서드는 간단한 편의 메서드 제공 plus -> plusXxx, minus -> minusXxx Temporal plus(TemporalAmount amount) Period, Duration 인수로 전달해 조작 가능 Temporal plus(long amountToAdd, TemporalUnit unit) 시간의 양과 ChronoUnit 인수로 전달해, 특정 시점의 시간을 조작 가능 isSupported() - TemporalAccessor & Temporal 인터페이스 현재 타입에서 특정 시간 단위나 필드를 사용할 수 있는지 확인 e.g. LocalDate에는 시, 분, 초 단위 관련 조회 및 조작을 할 수 없음 LocalDate now = LocalDate.now(); boolean supported = now.isSupported(ChronoField.SECOND_OF_MINUTE);//false if (supported) { int minute = now.get(ChronoField.SECOND_OF_MINUTE); } 기간 차이 구하기 남은 기간 Period, Duration의 between() e.g. Period period = Period.between(startDate, endDate); 년: period.getYears() / 월: period.getMonths() / 일: period.getDays() 디데이 ChronoUnit의 between(Temporal, Temporal) e.g. long daysBetween = ChronoUnit.DAYS.between(startDate, endDate); with() 복잡한 날짜 계산에 적합 날짜와 시간의 특정 필드 값만 변경하는 것이 가능 방법 편의 메서드 자주 사용하는 메서드는 간단한 편의 메서드 제공 dt.with(ChronoField.YEAR, 2020) -> dt.withYear(2020) TemporalAdjusters 사용 TemporalAdjuster 인터페이스의 구현체 묶음 (자바가 만들어 둠) 더욱 복잡한 날짜 계산 가능 e.g dt.with(TemporalAdjusters.next(DayOfWeek.FRIDAY)) 다음주 금요일 구하기 dt.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY)) 이번 달의 마지막 일요일 구하기 Temporal with(TemporalField field, long newValue) 단순한 날짜만 변경 가능 e.g. dt.with(ChronoField.YEAR, 2020) 날짜와 시간 문자열 파싱과 포멧팅 포멧팅과 파싱 포멧팅: Date -> String 파싱: String -> Date DateTimeFormatter 날짜와 시간 포멧팅 및 파싱에 사용 포멧팅: ofPattern() LocalDate date = LocalDate.of(2024, 12, 31); DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy년 MM월 dd 일"); String formattedDate = date.format(formatter); //2024년 12월 31일 파싱: 특정 날짜 객체의 parse() LocalDate date = LocalDate.of(2024, 12, 31); String input = "2030년 01월 01일"; DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy년 MM월 dd 일"); LocalDate parsedDate = LocalDate.parse(input, formatter); 자주 쓰이는 패턴 y: 연대의 연도 M: 연중 월 d: 월의 일수 H: 24시간제 시(0-23) m: 분 s: 초 패턴 예시 “yyyy년 MM월 dd 일” “yyyy-MM-dd HH:mm:ss” ISO 8601 날짜와 시간의 표준 출력. Reference 김영한의 실전 자바 - 중급 1편

Java-Ecosystem · 2024-08-06

자바 lang 패키지

Java-Ecosystem · 2024-08-01

스프링 파일 업로드

HTML Form 전송 방식 차이 application/x-www-form-urlencoded HTML 폼 기본 전송 방식 폼 태그에 enctype 옵션을 주지 않을 시 자동 지정 multipart/form-data 여러 데이터 형식을 함께 보내기 위한 Form 데이터 전송 방식 (HTTP 제공) 파일은 문자가 아닌 바이너리 타입으로 전송 필요 각각의 항목을 구분해 한번에 전송 e.g. 폼 데이터 전송 시 문자와 바이너리를 동시 전송 문자: 이름, 나이… 파일: 첨부파일 폼 태그 -> enctype="multipart/form-data" 서블릿 파일 업로드 HttpServletRequest request.getParameter(...) 요청 파라미터 접근 request.getParts() multipart/form-data 전송 방식에서 각각 나누어진 부분을 받아서 확인 개별 Part 메서드 part.getSubmittedFileName() : 클라이언트가 전달한 파일명 part.getInputStream(): Part의 전송 데이터를 읽기 (Body) part.write(fullPath): Part를 통해 전송된 데이터를 지정 경로에 저장 스프링 파일 업로드 업로드하는 HTML Form의 name에 맞추어 @RequestParam 을 적용하면 됨 @RequestParam String itemName @RequestParam MultipartFile file MultipartFile 인터페이스 제공 메서드 file.getOriginalFilename() : 업로드 파일 명 file.transferTo(...) : 파일 저장 서블릿에 비해 HttpServletRequest를 사용 X 파일 부분만 구분하기도 편리 예시 코드 @Slf4j @Controller @RequestMapping("/spring") public class SpringUploadController { @Value("${file.dir}") private String fileDir; @GetMapping("/upload") public String newFile() { return "upload-form"; } @PostMapping("/upload") public String saveFile(@RequestParam String itemName, @RequestParam MultipartFile file, HttpServletRequest request) throws IOException { log.info("request={}", request); log.info("itemName={}", itemName); log.info("multipartFile={}", file); if (!file.isEmpty()) { String fullPath = fileDir + file.getOriginalFilename(); log.info("파일 저장 fullPath={}", fullPath); file.transferTo(new File(fullPath)); } return "upload-form"; } } 멀티파트 관련 사용 옵션 (application.properties) 실제 파일 저장 경로 지정 file.dir=파일 업로드 경로 e.g. /Users/lucian/study/file/ 해당 경로에 반드시 실제 폴더 만들어두기 지정 파일 경로는 컨트롤러의 멤버 변수에 주입해 사용 가능 //application.properties에서 설정한 파일 경로 주입 @Value("${file.dir}") private String fileDir; 업로드 사이즈 제한 //파일 하나의 최대 사이즈 (기본 1MB) spring.servlet.multipart.max-file-size=1MB //멀티 파트 요청 하나의 여러 파일 전체 합 (기본 10MB) spring.servlet.multipart.max-request-size=10MB 큰 파일 무제한 업로드를 예방하고 업로드 사이즈 제한 가능 사이즈를 넘길 시 예외 발생 (SizeLimitExceededException) 서블릿 컨테이너 멀티파트 관련 처리 옵션 spring.servlet.multipart.enabled (기본 true) false: 멀티파트 처리 안하기 결과 request=org.apache.catalina.connector.RequestFacade@xxx itemName=null parts=[] true: 멀티파트 처리하기 결과 request=org.springframework.web.multipart.support.StandardMultipartHttpServletRequest itemName=Spring parts=[ApplicationPart1, ApplicationPart2] true일 시, 스프링 DispatcherServlet의 MultipartResolver를 실행 MultipartResolver는 멀티파트 요청이 온 경우 HttpServletRequest -> MultipartHttpServletRequest 변환 스프링 기본 멀티파트 리졸버는 StandardMultipartHttpServletRequest 반환 MultipartHttpServletRequest HttpServletRequest의 자식 인터페이스 멀티파트 관련 추가 기능 제공 StandardMultipartHttpServletRequest MultipartHttpServletRequest 인터페이스 구현체 실제 파일 업로드 구현 시 주의사항 고객이 업로드한 파일명과 서버 내부 관리 파일명은 다르게 할 것 서로 다른 고객이 같은 파일 이름을 업로드하면 기존 파일과 충돌 발생 예시 구현 업로드 파일 정보 @Data public class UploadFile { private String uploadFileName; private String storeFileName; public UploadFile(String uploadFileName, String storeFileName) { this.uploadFileName = uploadFileName; this.storeFileName = storeFileName; } } 상품 도메인 객체 @Data public class Item { private Long id; private String itemName; private UploadFile attachFile; private List<UploadFile> imageFiles; } 파일 저장 객체 구현하기 멀티파트 파일을 서버에 저장하는 역할 파일은 보통 로컬 스토리지나 S3에 저장하고 DB에는 해당 경로만 저장 (DB에 파일 자체 저장 X) 예시 구현 @Component public class FileStore { @Value("${file.dir}") private String fileDir; public String getFullPath(String filename) { return fileDir + filename; } public List<UploadFile> storeFiles(List<MultipartFile> multipartFiles) throws IOException { List<UploadFile> storeFileResult = new ArrayList<>(); for (MultipartFile multipartFile : multipartFiles) { if (!multipartFile.isEmpty()) { storeFileResult.add(storeFile(multipartFile)); } } return storeFileResult; } public UploadFile storeFile(MultipartFile multipartFile) throws IOException { if (multipartFile.isEmpty()) { return null; } String originalFilename = multipartFile.getOriginalFilename(); String storeFileName = createStoreFileName(originalFilename); multipartFile.transferTo(new File(getFullPath(storeFileName))); return new UploadFile(originalFilename, storeFileName); } //서버 내부 관리 파일명 생성 (UUID 사용해 충돌 방지) private String createStoreFileName(String originalFilename) { String ext = extractExt(originalFilename); String uuid = UUID.randomUUID().toString(); return uuid + "." + ext; } //확장자 추출 함수 private String extractExt(String originalFilename) { int pos = originalFilename.lastIndexOf("."); return originalFilename.substring(pos + 1); } } 파일 저장 폼 전송 객체 예시 @Data public class ItemForm { private Long itemId; private String itemName; private List<MultipartFile> imageFiles; //이미지 다중 업로드 private MultipartFile attachFile; } 파일 저장 뷰 예시 다중 파일 업로드는 <input> 태그에 multiple="multiple" 옵션 지정 ItemForm의 List<MultipartFile> imageFiles을 통해 여러 이미지 파일 받을 수 있음 <!DOCTYPE HTML> <html xmlns:th="http://www.thymeleaf.org"> <head> <meta charset="utf-8"> </head> <body> <div class="container"> <div class="py-5 text-center"> <h2>상품 등록</h2> </div> <form th:action method="post" enctype="multipart/form-data"> <ul> <li>상품명 <input type="text" name="itemName"></li> <li>첨부파일<input type="file" name="attachFile" ></li> <li>이미지 파일들<input type="file" multiple="multiple" name="imageFiles" ></li> </ul> <input type="submit"/> </form> </div>  </body> </html> 파일 조회 및 다운로드 예시 이미지 조회 UrlResource로 이미지 파일을 읽어서 @ResponseBody로 이미지 바이너리 반환 파일 다운로드 Content-Disposition 헤더에 attachment; filename="업로드 파일명" 주기 파일 다운로드 시에는 고객이 업로드한 파일명으로 다운로드하는게 좋음 (UTF_8 인코딩) UrlResource로 파일을 읽어서 헤더와 바디를 ResponseEntity<Resource> 반환 예시 구현 @Slf4j @Controller @RequiredArgsConstructor public class ItemController { private final ItemRepository itemRepository; private final FileStore fileStore; @GetMapping("/items/new") public String newItem(@ModelAttribute ItemForm form) { return "item-form"; } @PostMapping("/items/new") public String saveItem(@ModelAttribute ItemForm form, RedirectAttributes redirectAttributes) throws IOException { UploadFile attachFile = fileStore.storeFile(form.getAttachFile()); List<UploadFile> storeImageFiles = fileStore.storeFiles(form.getImageFiles()); //데이터베이스에 저장 Item item = new Item(); item.setItemName(form.getItemName()); item.setAttachFile(attachFile); item.setImageFiles(storeImageFiles); itemRepository.save(item); redirectAttributes.addAttribute("itemId", item.getId()); return "redirect:/items/{itemId}"; } @GetMapping("/items/{id}") public String items(@PathVariable Long id, Model model) { Item item = itemRepository.findById(id); model.addAttribute("item", item); return "item-view"; } @ResponseBody @GetMapping("/images/{filename}") public Resource downloadImage(@PathVariable String filename) throws MalformedURLException { return new UrlResource("file:" + fileStore.getFullPath(filename)); } @GetMapping("/attach/{itemId}") public ResponseEntity<Resource> downloadAttach(@PathVariable Long itemId) throws MalformedURLException { Item item = itemRepository.findById(itemId); String storeFileName = item.getAttachFile().getStoreFileName(); String uploadFileName = item.getAttachFile().getUploadFileName(); UrlResource resource = new UrlResource("file:" + fileStore.getFullPath(storeFileName)); log.info("uploadFileName={}", uploadFileName); String encodedUploadFileName = UriUtils.encode(uploadFileName, StandardCharsets.UTF_8); String contentDisposition = "attachment; filename=\"" + encodedUploadFileName + "\""; return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, contentDisposition) .body(resource); } } Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

Java-Ecosystem · 2024-07-28

스프링 타입 컨버터

스프링 Converter HTTP 요청 데이터는 문자로 처리됨 다만, 파라미터를 원하는 타입으로 지정하면 스프링이 자동으로 타입 변환 개발자는 직접 타입 변환할 필요 없이 원하는 타입으로 편리하게 전달 받아 사용 예시 @RequestParam, @ModelAttribute, @PathVariable … (스프링 MVC 요청 파라미터) @Value 등으로 YML 정보 읽기 XML에 넣은 스프링 빈 정보 변환 뷰 렌더링 시 컨버터 인터페이스 package org.springframework.core.convert.converter; public interface Converter<S, T> { T convert(S source); } 스프링은 확장 가능한 컨버터 인터페이스 지원 org.springframework.core.convert.converter.Converter 개발자는 스프링에 추가적인 타입 변환이 필요하면 인터페이스를 구현해 등록 Converter와 PropertyEditor 과거에는 PropertyEditor로 타입 변환했으나 동시성 문제가 있어서 잘 사용하지 않는다. 지금은 기능 확장 시 Converter를 사용한다. 스프링이 제공하는 다양한 컨버터 Converter: 기본 타입 컨버터 ConverterFactory: 전체 클래스 계층 구조가 필요할 때 GenericConverter: 정교한 구현, 대상 필드의 애노테이션 정보 사용 가능 ConditionalGenericConverter: 특정 조건이 참인 경우에만 실행 스프링은 문자, 숫자, 불린, Enum 등 일반적인 타입에 대한 대부분의 인터페이스 구현체들을 제공한다. ConversionService 스프링은 개별 컨버터를 모아서 묶어두고 편리하게 사용할 수 있도록 제공 스프링 내부에서도 ConversionService를 사용해 타입 변환 e.g @RequestParam RequestParamMethodArgumentResolver에서 ConversionService 사용해 타입 변환 뷰 템플릿도 컨버젼 서비스 적용 가능 (타임 리프 문법: ${{...}}) ConversionService 인터페이스 public interface ConversionService { boolean canConvert(@Nullable Class<?> sourceType, Class<?> targetType); boolean canConvert(@Nullable TypeDescriptor sourceType, TypeDescriptor targetType); <T> T convert(@Nullable Object source, Class<T> targetType); Object convert(@Nullable Object source, @Nullable TypeDescriptor sourceType, TypeDescriptor targetType); } canConvert: 컨버팅이 가능한지 체크 convert: 실제 컨버팅 수행 ConversionService는 2가지 이점 제공 등록과 사용 분리 컨버터 등록 입장: 타입 컨버터를 명확히 알아야 함 컨버터 사용 입장: 컨버전 서비스 인터페이스만 의존, 구체적인 타입 컨버터 몰라도 됨 인터페이스 분리 원칙 적용 (ISP) DefaultConversionService 구현체는 두 인터페이스를 구현 ConversionService: 컨버터 사용에 초점 ConverterRegistry: 컨버터 등록에 초점 ConversionService 인터페이스를 사용하는 클라이언트는 꼭 필요한 메서드만 알게 됨 메시지 컨버터와 컨버전 서비스 HttpMessageConverter에는 컨버전 서비스가 적용되지 않는다. 메시지 컨버터는 Jackson 라이브러리를 사용해 HTTP 메시지 바디 내용을 객체로 변환하거나 객체를 HTTP 메시지 바디에 입력한다. 따라서, JSON 결과로 만들어지는 숫자나 날짜 포멧을 변경하고 싶으면, Jackson 라이브러리가 제공하는 설정을 통해 지정해야 한다. (Jackson Data Format 같은 키워드로 검색 필요) 참고로, 컨버전 서비스는 @RequestParam , @ModelAttribute , @PathVariable , 뷰 템플릿 등에서 사용할 수 있다. Formatter 일반적인 웹 애플리케이션 환경에서의 타입 변환 (개발자) 문자 -> 객체 (다른 타입) 객체 (다른 타입) -> 문자 Formatter는 문자에 특화한 Converter의 특별한 버전 Formatter: 문자 특화 + 현지화(Locale) Converter: 범용 (객체 -> 객체) Formatter 인터페이스 public interface Printer<T> { String print(T object, Locale locale); } public interface Parser<T> { T parse(String text, Locale locale) throws ParseException; } public interface Formatter<T> extends Printer<T>, Parser<T> { } String print(T object, Locale locale) : 객체를 문자로 변경 T parse(String text, Locale locale) : 문자를 객체로 변경 스프링 Formatter 스프링은 용도에 따라 다양한 방식의 포멧터를 제공한다. Formatter: 포멧터 AnnotationFormatterFactory: 필드 타입 혹은 애노테이션 정보를 활용할 수 있는 포멧터 FormattingConversionService 포멧터를 지원하는 컨버전 서비스 포멧터도 특별한 컨버터일 뿐 내부에서 어댑터 패턴을 사용해 Formatter가 Converter처럼 동작하도록 지원 컨버터 & 포멧터를 모두 등록 가능 FormattingConversionService 는 ConversionService 관련 기능을 상속 받음 DefaultFormattingConversionService 구현체: 기본적인 통화, 숫자 기본 포멧터를 추가해 제공 커스텀Converter 및 Formatter 등록 @Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addFormatters(FormatterRegistry registry) { //컨버터 추가 registry.addConverter(new StringToIpPortConverter()); registry.addConverter(new IpPortToStringConverter()); //포멧터 추가 registry.addFormatter(new MyNumberFormatter()); } } 등록 방법은 다르지만 컨버전 서비스를 통해 컨버터와 포멧터를 일관성 있게 사용 가능 addFormatters() 오버라이딩 -> 스프링 내부 ConversionService에 컨버터 자동 등록 addConverter(): 컨버터 추가 addFormatter(): 포멧터 추가 우선 순위 스프링 기본 컨버터보다 추가한 컨버터가 높은 우선순위 포멧터보다 컨버터가 높은 우선 순위 스프링 기본 포멧터 스프링은 자바 기본 타입들에 대한 수많은 포멧터를 기본 제공 애노테이션 기반 포멧터도 제공 덕분에 객체에 각 필드마다 다른 형식으로 포멧 지정 가능 종류 @NumberFormat 숫자 관련 형식 지정 NumberFormatAnnotationFormatterFactory @DateTimeFormat 날짜 관련 형식 지정 Jsr310DateTimeFormatAnnotationFormatterFactory 예시 코드 @Controller public class FormatterController { @GetMapping("/formatter/edit") public String formatterForm(Model model) { Form form = new Form(); form.setNumber(10000); form.setLocalDateTime(LocalDateTime.now()); model.addAttribute("form", form); return "formatter-form"; } @PostMapping("/formatter/edit") public String formatterEdit(@ModelAttribute Form form) { return "formatter-view"; } @Data static class Form { @NumberFormat(pattern = "###,###") private Integer number; @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss") private LocalDateTime localDateTime; } } Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

Java-Ecosystem · 2024-07-27

스프링 예외 처리

Java-Ecosystem · 2024-07-20

스프링 쿠키, 세션 로그인 기본

Java-Ecosystem · 2024-07-10

스프링 Validation

Validation HTTP 요청이 정상인지 검증하는 것은 컨트롤러의 중요한 역할 스프링 제공 방법 Bean Validation (Bean Validation 2.0 (JSR-380)) + BindingResult 검증 로직을 공통화 및 표준화해 객체에 애노테이션으로 검증 적용 객체에 검증 애노테이션 적용 (e.g. @NotNull, @Range…) 파라미터에 @Valid, @Validated 적용하면 검증 실행 기술 표준으로서 검증 애노테이션 및 여러 인터페이스의 모음 구현체는 일반적으로 하이버네이트 Validator를 사용 (ORM과 관련 없음) 스프링 MVC가 Bean Validator를 사용하는 과정 spring-boot-starter-validation를 라이브러리로 등록 스프링 부트가 자동으로 Bean Validator를 인지하고 스프링에 통합 스프링 부트는 LocalValidatorFactoryBean을 글로벌 Validator로 등록 애노테이션을 보고 검증을 수행하는 검증기 (e.g. @NotNull) @Valid, @Validated 적용으로 파라미터 검증 실행 검증 오류 발생 시 FieldError, ObjectError 생성해 BindingResult 담음 검증 순서 타입에 맞춰 각각의 필드 바인딩 시도 실패시 typeMismatch로 FieldError 추가 바인딩에 성공한 필드만 Bean Validation 적용 비즈니스 로직 적용 방법 컨트롤러 용도에 따라 검증 전용 객체 분리하기 (도메인 객체는 순수하게 유지) 장점: 검증 중복이 없고 복잡도 낮음 단점: 컨트롤러에서 전송 받은 데이터를 도메인 객체 생성 및 변환 과정 추가 검증 전용 객체 이름은 일관성만 있게자유로이 명명 ItemSave, ItemSaveForm , ItemSaveRequest ,ItemSaveDto… 동일한 도메인 객체 사용 + Bean Validation의 groups 속성으로 분류 - 권장 X 장점: 중간에 도메인 객체 생성 과정 없이 컨트롤러부터 리포지토리까지 전달 가능 단점: 간단한 경우에만 가능 검증할 기능을 등록 및 수정 등 각각의 그룹으로 나누어 적용 가능 저장용 groups 생성 package hello.itemservice.domain.item; public interface SaveCheck { } 수정용 groups 생성 package hello.itemservice.domain.item; public interface UpdateCheck { } groups 적용 @Data public class Item { @NotNull(groups = UpdateCheck.class) //수정시에만 적용 private Long id; @NotBlank(groups = {SaveCheck.class, UpdateCheck.class}) private String itemName; @NotNull(groups = {SaveCheck.class, UpdateCheck.class}) @Range(min = 1000, max = 1000000, groups = {SaveCheck.class, UpdateCheck.class}) private Integer price; @NotNull(groups = {SaveCheck.class, UpdateCheck.class}) @Max(value = 9999, groups = SaveCheck.class) //등록시에만 적용 private Integer quantity; public Item() { } public Item(String itemName, Integer price, Integer quantity) { this.itemName = itemName; this.price = price; this.quantity = quantity; } } @Validated에 groups 적용 (@Valid는 groups 기능이 없음) @Validated(SaveCheck.class) @Validated(UpdateCheck.class) ObjectError 처리 방법 글로벌 오류는 자바 코드로 직접 작성해 처리 권장 (메서드 추출) public String addItem(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes) { //특정 필드 예외가 아닌 전체 예외 if (item.getPrice() != null && item.getQuantity() != null) { int resultPrice = item.getPrice() * item.getQuantity(); if (resultPrice < 10000) { bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null); } } ... } @ScriptAssert() - 권장 X @ScriptAssert(lang = "javascript", script = "_this.price * _this.quantity >= 10000") public class Item { //... } 생성되는 메시지 코드 ScriptAssert.item ScriptAssert 제약이 많고 복잡하여 권장하지 않음 API 적용 시 고려할 점 (HTTP 메시지 컨버터) @Valid, @Validated -> HttpMessageConverter(@RequestBody)에 적용 가능 public Object addItem(@RequestBody @Validated ItemSaveForm form, BindingResult bindingResult) API는 3가지 경우 고려 필요 성공 요청 실패 요청 HttpMessageConverter 에서 요청 JSON을 객체로 생성하는데 실패 컨트롤러 자체가 호출되지 않고 예외가 발생 검증 적용(Validator) X 검증 오류 요청 JSON 객체 생성은 성공했으나 이후 검증 실패 HttpMessageConverter 는 성공하지만 검증(Validator)에서 오류가 발생 필요한 의존관계 패키지 implementation 'org.springframework.boot:spring-boot-starter-validation jakarta.validation-api: Bean Validation 인터페이스 hibernate-validator: 구현체 검증 애노테이션 @NotBlank: null 과 "" 과 " " 모두 허용하지 않음 @NotEmpty: null 과 ""을 허용하지 않음 @NotNull: null을 허용하지 않음 @Range(min = 1000, max = 1000000): 범위 안의 값만 허용 @Max(9999): 최대 지정 값까지만 허용 테스트에서 Bean Validation 사용하기 ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); Set<ConstraintViolation<Item>> violations = validator.validate(item); Bean Validation 오류 코드 Bean Validation이 오류 메시지를 찾는 순서 MessageResolver 생성 메시지 코드대로 messageSource 찾기 (errors.properties) 애노테이션의 message 속성 사용 @NotBlank(message = "공백! {0}") 라이브러리가 제공하는 기본 값 사용 기본은 애노테이션 이름으로 오류코드를 등록 e.g. @NotBlank NotBlank.item.itemName NotBlank.itemName NotBlank.java.lang.String NotBlank 생성이 예상되는 적절한 오류 코드로 errors.properties에 원하는 메시지 등록 가능 BindingResult 스프링이 제공하는 검증 오류를 보관하는 객체 (Model에 자동 포함) 실제로는 인터페이스이고 Errors 인터페이스를 상속받고 있음 실제 넘어오는 구현체는 BeanPropertyBindingResult 타입으로 Errors를 사용해도 되지만 BindingResult는 더 추가적인 기능 제공 관례상으로도 Errors보다 BindingResult 많이 사용 반드시 @ModelAttribute 파라미터의 바로 뒤에 위치해야 함 e.g. @ModelAttribute Item item, BindingResult bindingResult 타임리프가 통합 기능도 제공 (#fields, th:errors, th:errorclass) 검증 오류 적용 방법 스프링 자동 적용 @ModelAttribute에 데이터 바인딩 오류가 발생 시 자동 처리 e.g. 주로 타입 오류 BindingResult가 없으면 컨트롤러 호출 X, 400 오류 페이지 이동 BindingResult가 있으면 스프링이 new FieldError() 실행 생성한 필드 에러 객체를 BindingResult에 자동으로 담음 이후 컨트롤러 정상 호출 개발자가 직접 넣기 rejectValue(), reject()를 호출하는 방법 target(검증 대상 모델)을 BindingResult가 이미 앎 (깔끔한 코드) 내부에서 MessageCodesResolver를 사용 FieldError, ObjectError 생성 후 오류 코드들을 보관 즉, MessageCodesResolver가 생성한 오류들을 가지고 처리 필드 에러 처리 (rejectValue()) bindingResult.rejectValue("quantity", "max", new Object[]{9999}, null); rejectValue() 파라미터 field: 오류 필드명 errorCode messageCodesResolver를 위한 오류 코드 필드명, 오브젝트명, 오류코드를 조합한 키로 메시지 가져옴 errorArgs: 메시지에서 사용하는 인자 defaultMessage: 오류 메시지 찾을 수 없을 때 기본 메시지 글로벌 에러 처리 (reject()) bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null); reject() 파라미터 errorCode errorArgs defaultMessage 참고 ValidationUtils: Empty, 공백 등의 조건까지 한 줄로 처리 가능 ValidationUtils.rejectIfEmptyOrWhitespace(bindingResult, "itemName", "required"); FieldError, ObjectError 직접 생성을 통한 방법 (addError()) 필드 에러 처리 (FieldError) FieldError 객체를 생성해 bindingResult에 담음 FieldError는 ObjectError의 자식 bindingResult.addError(new FieldError("item", "itemName", "상품 이름은 필수입니다.")); FieldError 파라미터 (생성자 2개) objectName: @ModelAttribute 이름 field: 오류가 발생한 필드 이름 rejectedValue: 사용자가 입력한 값 (거절된 값) bindingFailure: 바인딩 실패인지, 검증 실패인지 구분 값 codes: 메시지 코드 지정 (errors.properties) 배열로 여러 값을 전달 가능 순서대로 매칭해 처음 매칭되는 메시지 사용 (없으면 예외 발생) e.g. new String[] {"max.item.quantity"} arguments: 메시지에서 사용하는 인자 {0}, {1}… 순서대로 치환 값 전달 e.g. new Object[] {9999} defaultMessage: 오류 기본 메시지 글로벌 에러 처리 (ObjectError - 특정 필드를 넘어서는 오류) ObjectError 객체를 생성해 bindingResult에 담음 bindingResult.addError(new ObjectError("item", "가격 * 수량의 합은 10,000원 이상이어야 합니다. 현재 값 = " + resultPrice)); ObjectError 파라미터 (생성자 2개) objectName: @ModelAttribute 이름 codes: 메시지 코드 arguments: 메시지에서 사용하는 인자 defaultMessage: 오류 기본 메시지 Validator 사용하기 스프링이 제공하는 Validator 인터페이스를 상속해 검증 로직을 담기 가능 컨트롤러에서 검증 로직을 분리하고 재사용할 수 있음 구현할 메서드 supports 해당 검증기 지원 여부 확인 @Override public boolean supports(Class<?> clazz) { return Item.class.isAssignableFrom(clazz); } validate(Object target, Errors errors) 검증 대상 객체와 BindingResult 전달 적용 방법 WebDataBinder 에 검증기 추가 + @Validated 파라미터 적용 @InitBinder public void init(WebDataBinder dataBinder) { log.info("init binder {}", dataBinder); dataBinder.addValidators(itemValidator); } WebDataBinder (컨트롤러에 추가) 스프링 파라미터 바인딩 역할 및 검증 기능 수행 해당 컨트롤러가 호출될 때마다 검증기 적용 즉, 요청이 올 때마다 새로 생성해 검증 글로벌 설정도 가능하지만 사용할 일 거의 없음 (권장 X) @SpringBootApplication public class ItemServiceApplication implements WebMvcConfigurer { public static void main(String[] args) { SpringApplication.run(ItemServiceApplication.class, args); } @Override public Validator getValidator() { return new ItemValidator(); } } 글로벌 설정 시 BeanValidator가 자동 등록되지 않음 @Validated 검증 실행을 원하는 파라미터에 적용 supports를 통해 등록된 검증기들 중 실행해야 할 것을 구분 검증기 직접 호출도 가능하지만 불편 개발자 직접 처리 중복 처리가 많아짐 타입 오류 처리가 안됨 Integer 타입 파라미터에 문자가 들어오면 오류 스프링 MVC에서 컨트롤러 호출되기 전부터 400 예외 발생 특히, 타입 오류의 경우 검증 전 고객의 입력 데이터를 보존하지 못함 (UX에 중요한 부분) 클라이언트 검증 & 서버 검증 클라이언트 검증만 사용하면 조작이 가능해 보안에 취약하고, 서버 검증만 있다면 즉각적인 고객 사용성이 부족해진다. 따라서, 클라이언트 검증과 서버 검증은 둘 다 적절히 섞어 사용하되, 최종적으로 서버 검증을 필수로 진행한다. @Validated와 @Valid 검증 시 @Validated, @Valid 둘 다 사용 가능하다. @Validated 는 스프링 전용 검증 애노테이션이고, @Valid 는 자바 표준 검증 애노테이션이다. 다만, @Valid는 다음 의존관계 추가가 필요하다. `implementation ‘org.springframework.boot:spring-boot-starter-validation’ javax.validation VS org.hibernate.validator javax.validation으로 시작하면 표준 인터페이스, org.hibernate.validator로 시작하면 하이버네이트 validator 구현체를 사용할 때만 제공되는 검증이다. 다만, 실무에서 대부분 하이버네이트 validator를 사용하므로 자유롭게 사용해도 된다. BeanValidation - @ModelAttribute VS @RequestBody @ModelAttribute 는 필드 단위로 정교하게 바인딩이 적용된다. 특정 필드가 바인딩 되지 않아도(타입이 맞지 않는 오류) 나머지 필드는 정상 바인딩 되고, Validator를 사용한 검증도 적용할 수 있다. @RequestBody 는 객체 단위로 바인딩이 적용된다. HttpMessageConverter 단계에서 JSON 데이터를 객체로 변경하지 못하면 이후 단계 자체가 진행되지 않고 예외가 발생한다. 컨트롤러도 호출되지 않고, Validator도 적용할 수 없다. MessageCodesResolver 검증 오류 코드로 메시지 코드 후보들을 생성 MessageCodesResolver는 인터페이스이고 DefaultMessageCodesResolver가 기본 구현체 보통 이렇게 생성된 메시지 코드를 기반으로 MessageSource에서 메시지를 찾음 기본 메시지 코드 생성 규칙 객체 오류 규칙 code + “.” + object name code e.g. 오류 코드: required, object name: item required.item required 필드 오류 규칙 code + “.” + object name + “.” + field code + “.” + field code + “.” + field type code 예) 오류 코드: typeMismatch, object name: "user", field: "age", field type: int typeMismatch.user.age typeMismatch.age typeMismatch.int typeMismatch 메시지 처리 전략 예시 (errors.properties) #==ObjectError== #Level1 totalPriceMin.item=상품의 가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1} #Level2 totalPriceMin=전체 가격은 {0}원 이상이어야 합니다. 현재 값 = {1} #==FieldError== #Level1 required.item.itemName=상품 이름은 필수입니다. range.item.price=가격은 {0} ~ {1} 까지 허용합니다. max.item.quantity=수량은 최대 {0} 까지 허용합니다. #Level2 - 생략 #Level3 required.java.lang.String = 필수 문자입니다. required.java.lang.Integer = 필수 숫자입니다. min.java.lang.String = {0} 이상의 문자를 입력해주세요. min.java.lang.Integer = {0} 이상의 숫자를 입력해주세요. range.java.lang.String = {0} ~ {1} 까지의 문자를 입력해주세요. range.java.lang.Integer = {0} ~ {1} 까지의 숫자를 입력해주세요. max.java.lang.String = {0} 까지의 문자를 허용합니다. max.java.lang.Integer = {0} 까지의 숫자를 허용합니다. #Level4 required = 필수 값 입니다. min= {0} 이상이어야 합니다. range= {0} ~ {1} 범위를 허용합니다. max= {0} 까지 허용합니다. 메시지 처리 기본 범용 메시지를 두고, 세밀하게 작성해야 하는 경우에 세밀한 메시지를 적용하도록 메시지 단계를 두자 세밀한 메시지가 범용 메시지보다 우선순위 가진다. 예를 들어, required라는 메시지만 있으면 해당 메시지를 기본으로 사용하고, required.item.itemName 같이 세밀한 메시지 코드가 있으면 이 메시지를 높은 우선순위로 사용한다. MessageCodesResolver는 메시지 관련 공통 전략을 편리하게 적용할 수 있게 지원한다. 스프링 타입 오류 스프링은 타입 오류가 발생하면 typeMismatch라는 오류 코드를 자동으로 사용한다. 이 경우 MessageCodesResolver를 통해 4가지 메시지 코드가 발생할텐데, errors.properties에 해당 코드가 없다면 스프링이 생성한 기본 메시지가 출력된다. Failed to convert property value of type java.lang.String to required type java.lang.Integer for property price; nested exception is java.lang.NumberFormatException: For input string: "A" 기본 출력을 임의로 바꾸고 싶다면, errors.properties에 다음과 같은 코드를 적절하게 추가하면 된다. typeMismatch.java.lang.Integer=숫자를 입력해주세요. typeMismatch=타입 오류입니다. Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 @NotNull, @NotEmpty, @NotBlank 의 차이점 및 사용법

Java-Ecosystem · 2024-06-30

스프링 MVC 메시지와 국제화

메시지 다양한 메시지를 한 곳에서 관리하도록 하는 기능 스프링 부트는 messages.properties를 기본 메시지 파일로 인식하고 관리 경로: /resources/messages.properties 국제화 메시지 파일을 각 나라 언어별로 별도 관리해 서비스를 국제화 베이스파일명_언어 형식으로 메시지 파일을 만들어두면 자동으로 인식 e.g. messages_en.properties, messages_ok.properties 기본은 HTTP accept-language 헤더 값을 보고 판단 스프링 부트 기본 LocaleResolver: AcceptHeaderLocaleResolver 혹은 사용자가 직접 언어를 선택하도록 하고, 쿠키나 세션 기반 처리도 가능 LocaleResolver 인터페이스의 구현체 변경 public interface LocaleResolver { Locale resolveLocale(HttpServletRequest request); void setLocale(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable Locale locale); } 찾을 수 있는 국제화 파일이 없는 경우, 언어정보 없는 디폴트 파일 기본 사용 (messages.properties) MessageSource 인터페이스 public interface MessageSource { String getMessage(String code, @Nullable Object[] args, @Nullable String defaultMessage, Locale locale); String getMessage(String code, @Nullable Object[] args, Locale locale) throws NoSuchMessageException; 스프링은 메시지 관리 기능을 MessageSource 인터페이스를 통해 제공 getMessage: 파라미터만 다르고 메시지를 읽어오는 기능 수행 메시지가 없는 경우 NoSuchMessageException 발생 code: 메시지 파일에서 지정한 키 args: 매개변수를 전달하는 배열 메시지 파일의 {0} 부분 치환 hello.name=안녕 {0} Object[] 배열로 넘겨야 함 ms.getMessage("hello.name", new Object[]{"Spring"}, null); defaultMessage: 메시지가 없을 때 기본 메시지 지정 (예외 발생 예방) locale: 국제화 파일 선택 e.g. Locale.KOREA, Locale.ENGLISH 정보가 없을 시 (null) Locale.getDefault() 호출해, 시스템 기본 로케일 사용 시스템 기본 로케일 조회 실패 시 기본 이름 메시지 파일 조회 (message.properties) Locale이 en_US인 경우 messages_en_US / messages_en / messages 순서로 찾음 스프링 부트는 자동으로 ResourceBundleMessageSource 구현체를 스프링 빈으로 등록 메시지 파일 임의 지정 방법 (application.properties) e.g. spring.messages.basename=messages,config.i18n.messages 기본값: spring.messages.basename=messages 직접 등록 방법 @Bean public MessageSource messageSource() { ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource(); messageSource.setBasenames("messages", "errors"); messageSource.setDefaultEncoding("utf-8"); return messageSource; basenames: 설정 파일 이름 지정 여러 파일을 한 번에 지정 가능 (messages, errors) messages.properties, errors.properties 파일을 읽음 defaultEncoding: 인코딩 정보 지정 (utf-8 사용하면 됨) Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

Java-Ecosystem · 2024-06-21

스프링 데이터 접근 활용 기술

Java-Ecosystem · 2024-06-16

JPQL Dive

JPQL 개요 단순한 조회 방법 EntityManager.find() 객체 그래프 탐색 - a.getB(), b.getC() 검색조건이 포함된 SQL의 필요성 단순 조회는 문제 없지만 애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 SQL이 필요 (모든 DB 데이터를 객체로 변환해 검색하는 것은 불가능) JPQL 엔터티 객체를 대상으로 검색하는 객체 지향 SQL (JPA 제공) 반면에, SQL은 데이터베이스 테이블을 대상으로 쿼리 SQL을 추상화해서 특정 DB SQL에 의존 X JPQL은 현재 설정 Dialect와 합쳐져 현재 DB에 맞는 적절한 SQL을 생성하고 전달 DB를 바꿔서 Dialect가 바뀌었더라도 JPQL 자체를 바꿀 필요는 없음 JPQL 빌더 - QueryDSL 권장 문자가 아닌 자바코드로 JPQL을 작성할 수 있음 Criteria JPA 공식 기능 너무 복잡하고 실용성이 없음 QueryDSL 컴파일 시점에 문법 오류를 찾을 수 있음 편리한 동적쿼리 작성 단순하고 쉬움 네이티브 쿼리 - 네이티브 쿼리가 필요할 때는 JdbcTemplate을 사용하는게 낫다 JPQL로 해결할 수 없는 특정 DB 의존적인 기능 해결 e.g. 오라클 CONNECT BY, … 네이티브 SQL JPA에서 SQL을 직접 사용하는 기능 em.createNativeQuery(sql, 클래스) JDBC, JdbcTemplate, MyBatis 사용 주의점: 영속성 컨텍스트를 적절한 시점에 강제로 플러시 필요 JPA로 Persist만 해둔 데이터는 JdbcTemplate으로 커넥션을 얻어 SQL 조회시 조회 X 조회 직전 flush() 호출 필요 기본 조회 select m from Member as m where m.age > 18 테이블 이름이 아닌 엔터티 이름 사용 (Member) 별칭은 필수 (m, as는 생략 가능) 엔터티와 속성은 대소문자 구분 O JPQL 키워드는 대소문자 구분 X em.createQuery 반환 타입 TypedQuery 반환 타입이 명확할 때 사용 보통 엔터티 클래스를 넘김 TypedQuery<Member> query = em.createQuery("SELECT m FROM Member m", Member.class); Query 반환 타입이 명확하지 않을 때 사용 Query query = em.createQuery("SELECT m.username, m.age from Member m"); 결과 조회 API query.getResultList() 결과가 하나 이상일 때, 리스트 반환 결과가 없으면 빈 리스트 반환 query.getSingleResult() 결과가 정확히 하나, 단일 객체 반환 이외의 결과는 예외 일으킴 결과가 없으면 javax.persistence.NoResultException 둘 이상이면 javax.persistence.NonUniqueResultException 파라미터 바인딩 이름 기준 SELECT m FROM Member m where m.username=:username query.setParameter("username", usernameParam); 위치 기준 - 버그나기 쉬우므로 사용하지 말 것! SELECT m FROM Member m where m.username=?1 query.setParameter(1, usernameParam); 프로젝션 SELECT 절에 조회할 대상을 지정하는 것 DISTINCT로 중복 제거 엔터티 프로젝션 SELECT m FROM Member m 조회된 엔터티는 영속성 컨텍스트가 관리 SELECT m.team FROM Member m 이 경우 조인 쿼리가 나가는데 예측이 어려우므로 이 형태로 사용하지 말 것 조인쿼리는 직접 조인 쿼리로 작성하자 임베디드 타입 프로젝션 SELECT m.address FROM Member m 스칼라 타입 프로젝션 SELECT m.username, m.age FROM Member m 위와 같이 여러 값을 조회할 시 3가지 방법 존재 Query 타입으로 조회 TypedQuery에서 Object[] 타입으로 조회 DTO로 바로 조회 SELECT new jpabook.jpql.UserDTO(m.username, m.age) FROM Member m TypedQuery에서 UserDTO 타입으로 조회 패키지 명을 포함한 전체 클래스 명 입력 (문자 SQL이라 적어줘야 함) 순서와 타입이 일치하는 생성자 필요 페이징 API 각각의 DB Dialect에 맞게 JPA가 추상화 setFirstResult(int startPosition): 조회 시작 위치 (0부터 시작) setMaxResults(int maxResult): 조회할 데이터 수 //페이징 쿼리 String jpql = "select m from Member m order by m.name desc"; List<Member> resultList = em.createQuery(jpql, Member.class) .setFirstResult(10) .setMaxResults(20) .getResultList(); 조인 내부 조인 SELECT m FROM Member m [INNER] JOIN m.team t 외부 조인 SELECT m FROM Member m LEFT [OUTER] JOIN m.team t 세타 조인 연관 관계가 없는 테이블끼리 조인 (카테시안 곱 발생) select count(m) from Member m, Team t where m.username = t.name ON 절 (JPA 2.1부터 지원) 조인 대상 필터링 JPQL SELECT m, t FROM Member m LEFT JOIN m.team t on t.name = 'A' SQL SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.TEAM_ID=t.id and t.name='A' 연관관계 없는 엔터티 외부 조인 JPQL SELECT m, t FROM Member m LEFT JOIN Team t on m.username = t.name SQL SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.username = t.name 서브 쿼리 JPA는 WHERE, HAVING 절에서만 서브 쿼리 사용 가능 하이버네이트는 SELECT, FROM 절에서 서브 쿼리 가능하도록 지원 (FROM은 6부터 지원) 서브 쿼리 지원 함수 EXISTS (subquery): 서브쿼리에 결과가 존재하면 참 ALL (subquery): 모두 만족하면 참 ANY, SOME (subquery): 하나라도 만족하면 참 IN (subquery): 하나라도 같은 것이 있으면 참 JPQL 타입 표현 문자: ‘HELLO’, ‘She’’s’ 숫자: 10L(Long), 10D(Double), 10F(Float) Boolean: TRUE, FALSE ENUM: jpabook.MemberType.Admin (패키지명 포함) 파라미터 바인딩으로 풀면 패키지명 안 쓸 수 있음 엔티티 타입: TYPE(m) = Member (상속 관계에서 사용) em.createQuery(“select i from Item i where type(i) = Book”, Item.class) where 절에 DTYPE = ‘Book’ 으로 쿼리가 나감 조건식 CASE 식 기본 CASE 식 select case when m.age <= 10 then '학생요금' when m.age >= 60 then '경로요금' else '일반요금' end from Member m 단순 CASE 식 select case t.name when '팀A' then '인센티브110%' when '팀B' then '인센티브120%' else '인센티브105%' end from Team t COALESCE 조건식을 하나씩 차례로 조회해서 null이 아닌 조건식 반환 select coalesce(m.username,'이름 없는 회원') from Member m NULLIF 두 값이 같으면 null 반환, 다르면 첫 번째 값 반환 select NULLIF(m.username, '관리자') from Member m JPQL 기본 함수 및 사용자 정의 함수 JPQL 기본 함수 CONCAT SUBSTRING TRIM LOWER, UPPER LENGTH LOCATE: 문자 위치 찾기 (locate('de', 'abcdegf')) ABS, SQRT, MOD SIZE (JPA 용도): 컬렉션의 크기를 리턴 (select size(t.members) from Team t) 사용자 정의 함수 호출 등록 방법 Hibernate 6는 FunctionContributer 구현체를 만들어야 함 Hibernate 6 이전에는 방언을 상속받고 사용자 정의 함수 등록했음 src/main/resources/META-INF/services/org.hibernate.boot.model.FunctionContributor 위 파일을 생성해 구현체 등록 (custom.CustomFunctionContributor) package custom; import org.hibernate.boot.model.FunctionContributions; import org.hibernate.boot.model.FunctionContributor; import org.hibernate.dialect.function.StandardSQLFunction; import org.hibernate.type.StandardBasicTypes; public class CustomFunctionContributor implements FunctionContributor { @Override public void contributeFunctions(FunctionContributions functionContributions) { functionContributions.getFunctionRegistry() .register("group_concat", new StandardSQLFunction("group_concat", StandardBasicTypes.STRING)); } } 호출 방법 select function('group_concat', i.name) from Item i 경로표현식 .을 찍어 객체 그래프를 탐색하는 것 경로표현식에 의한 묵시적 조인은 쓰지 말자 최대한 JPQL과 실제 SQL의 모양을 맞춰 예측가능하게 만들어야 함 조인은 쿼리 튜닝에 중요 포인트이기 때문 유의사항: 묵시적 조인은 항상 내부 조인 명시적 조인 사용하자! (별칭으로 상세 탐색 가능) select m.username from Team t join t.members m 용어 상태 필드 (state field) 단순히 값을 저장하기 위한 필드 경로 탐색의 끝 (탐색 X) m.username 연관 필드 (association field) 연관 관계를 위한 필드 단일 값 연관 필드 대상이 엔터티 (@ManyToOne, @OneToOne) 묵시적 내부 조인 발생 (탐색 O) select m.team from Member m (e.g.m.team) 컬렉션 값 연관 필드 대상이 컬렉션 (@OneToMany, @ManyToMany) 묵시적 내부 조인 발생 (탐색 X) select t.members from Team t (e.g. t.members) 페치 조인 (fetch join) - join fetch JPQL에서 성능 최적화를 위해 연관된 엔터티나 컬렉션을 SQL 한 번에 함께 조회하는 기능 페치 조인으로 가져온 연관 엔터티는 프록시가 아닌 실제 엔터티 지정한 엔터티를 즉시 로딩으로 가져오므로, N + 1 문제를 해결 사용 전략 글로벌 로딩 전략은 모두 지연로딩으로 가져가고 최적화가 필요한 곳에 페치 조인 적용 조인 사용 전략 페치 조인으로 가져오기 (객체 그래프를 유지할 때 사용하면 효과적) 페치 조인으로 가져오고 애플리케이션 단에서 알맞는 DTO로 전환해 사용 일반 조인으로 필요한 데이터들만 조회해 DTO로 프로젝션 반환 여러 테이블을 조인해 원래의 엔터티 모양과 전혀 다른 결과를 내야 한다면 일반조인 사용 페치 조인과 일반 조인과의 차이 페치 조인은 회원을 조회하면 연관된 팀도 함께 조회 (SELECT T.*, M.*) [JPQL] select t from Team t join fetch t.members [SQL] SELECT T.*, M.* FROM TEAM T INNER JOIN MEMBER M ON T.ID=M.TEAM_ID 일반 조인은 연관된 엔터티를 함께 조회 X (SELECT T.*) [JPQL] select t from Team t join t.members m [SQL] SELECT T.* FROM TEAM T INNER JOIN MEMBER M ON T.ID=M.TEAM_ID 컬렉션 페치 조인 일대다 관계에서 실행하는 페치 조인 하이버네이트 6 이후 JPQL DISTINCT 없이도 애플리케이션에서 자동으로 중복 제거 적용 하이버네이트 6 이전 조인 시 데이터 중복 발생 DB와 객체의 차이 때문에 같은 엔터티 중복 발생 실제 팀은 1개인데 멤버와의 조인으로 발생한 행 수에 의해 2개의 팀이 반환 teamname = 팀A, team = Team@0x100 -> username = 회원1, member = Member@0x200 -> username = 회원2, member = Member@0x300 teamname = 팀A, team = Team@0x100 -> username = 회원1, member = Member@0x200 -> username = 회원2, member = Member@0x300 JPQL DISTINCT 컬렉션 페치 조인 데이터 중복 방지를 위해 적용 JPQL DISTINCT는 2가지 기능을 제공 SQL에 DISTINCT 추가 실제 SQL에 적용되지만, SQL 결과에서는 중복 제거할 것이 없음 애플리케이션에서 엔터티 중복 제거 애플리케이션 단에서 같은 식별자를 가진 엔터티 제거 DISTINCT 적용시 결과 teamname = 팀A, team = Team@0x100 -> username = 회원1, member = Member@0x200 -> username = 회원2, member = Member@0x300 유의 사항 여러 엔터티 다중 페치 조인 시에만 대상에 별칭을 쓰자 하이버네이트에서는 페치 조인 대상에 별칭 사용 가능 (가급적 사용 X) 페치 조인은 연관된 엔터티를 몇 개 걸러서 가져와서는 안됨 (정합성 이슈) 페치 조인은 연관된 엔터티를 항상 모두 가져와야 함 e.g. 팀 조회 시, 팀에 연관된 멤버가 5명일 때 멤버 3명만 가져와서는 안됨 이는 누락을 동반하는 매우 위험한 조작 (Cascade etc…) JPA 설계 사상은 연관된 모든 것을 다 조회하는 것을 전제하므로 위반 조심 둘 이상의 컬렉션은 페치 조인하지 말자 페치 조인은 컬렉션을 딱 하나만 지정하자 예상치 못하게 데이터 중복이 늘어날 수 있음 e.g Team.members, Team.orders를 한꺼번에 페치 조인해서는 안됨 컬렉션을 페치 조인하면 페이징 API 사용 불가 (메모리 페이징 문제로 매우 위험) 페이징 API: setFIrstResult, setMaxResults 문제 데이터 중복 1:M 컬렉션 페치 조인은 단순히 DB 상 조인 쿼리를 생성 DB에서 조인된 테이블의 로우는 M개 (1 기준으로는 중복된 row가 많은 상황) 따라서, 생성된 DB 쿼리 상 1 기준 페이징이 불가능 데이터 누락 문제가 JPA의 객체 그래프 사상을 위반 e.g. 팀 A에 멤버가 2명 있을 때, 이를 페치 조인해 pageSize를 1로 페이징 페이징은 철저히 DB 중심 -> 팀 & 멤버 조인 테이블에서 1개 row를 가져옴 (멤버1) DB 결과에 따라 JPA는 팀 A에 멤버가 1명 있다고 생각해 문제 발생 (멤버2 누락) 데이터 중복 및 누락을 피하기 위해 메모리 페이징 발생 (장애 유발 가능성 높음) 하이버네이트는 경고 로그를 남기고 강제로 메모리에서 페이징 (매우 위험) 실제로 조인 쿼리만 날리고 DB에서 페이징하지 않고 메모리에서 페이징 e.g. 100만 건 데이터를 모두 메모리에 올리고 메모리에서 페이징… 해결 방법 일대다 쿼리를 다대일 쿼리로 바꿔 실행 (권장) 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 당연히 페이징 가능 쿼리 한 번으로 해결되므로 일반적으로 성능이 좋음 팀과 멤버 (OneToMany)에서 멤버 테이블로 페이징 쿼리 후 팀 기준 group by batchSize 적용 페치 조인을 하지 않고 지연 로딩 활용 (팀에 페이징 쿼리하고 멤버를지연로딩) 배치 사이즈는 N + 1 쿼리를 막고 설정한 단위 기준으로 in-query 진행 기본적으로 글로벌 배치 사이즈 깔고 모든 작업 진행 1000 이하의 적절한 수 지정 (보통 DB의 in 절 개수의 한계가 1000) persistence.xml <property name="hibernate.default_batch_fetch_size" value="100" /> application.properties spring: jpa: properties: hibernate: default_batch_fetch_size: 100 e.g. 팀이 150개고 멤버가 레이지 로딩될 때, batchSize가 100개인 상황 원래는 150개의 N + 1 쿼리가 발생하지만 이를 예방 100개 & 50개 뭉치로 총 2번 in-query해 가져옴 DTO 쿼리 다형성 쿼리 상속 관계 매핑에서 사용 type 조회 대상을 특정 자식으로 한정 (=DTYPE where 절 자동 적용) e.g. Item 중 Book, Movie 조회하기 [JPQL] select i from Item i where type(i) IN (Book, Movie) [SQL] select i from i where i.DTYPE in (‘B’, ‘M’) treat (JPA 2.1) 부모 타입을 특정 자식 타입으로 다룸 타입 캐스팅과 유사 FROM, WHERE, SELECT(하이버네이트) 절에서 사용 가능 e.g. 부모인 Item과 자식 Book이 있을 때, 자식 속성으로 where절 걸고 싶은 경우 [JPQL] select i from Item i where treat(i as Book).author = ‘kim’ [SQL] select i.* from Item i where i.DTYPE = ‘B’ and i.author = ‘kim’ 엔터티 직접 사용 JPQL에서 엔터티를 직접 사용하면 SQL에서 해당 엔터티의 기본키 값 사용 [JPQL] select count(m.id) from Member m - 엔티티의 아이디를 사용 select count(m) from Member m - 엔티티를 직접 사용 [SQL] select count(m.id) as cnt from Member m - JPQL 둘 다 같은 SQL 실행 연관된 엔터티를 직접 사용하면 외래키 값 사용 [JPQL] select m from Member m where m.team = :team select m from Member m where m.team.id = :teamId [SQL] select m.* from Member m where m.team_id=? - JPQL 둘 다 같은 SQL 실행 Named 쿼리 미리 정의해서 이름을 부여해두고 사용하는 JPQL (=정적 쿼리) 에노테이션, XML에 정의 XML 정의가 항상 우선권을 가짐 애플리케이션 운영 환경에 따라 다른 XML 배포 가능 애플리케이션 로딩 시점에 초기화 후 재사용 - JPQL을 SQL로 미리 파싱 후 캐싱 약간의 속도 이점 애플리케이션 로딩 시점에 미리 쿼리의 예외를 검증하는 이점 에노테이션 정의 사용 예 @Entity @NamedQuery( name = "Member.findByUsername", query="select m from Member m where m.username = :username") public class Member { ... } List<Member> resultList = em.createNamedQuery("Member.findByUsername", Member.class) .setParameter("username", "회원1") .getResultList(); XML 정의 사용 예 [META-INF/persistence.xml] <persistence-unit name="jpabook" > <mapping-file>META-INF/ormMember.xml</mapping-file> [META-INF/ormMember.xml] <?xml version="1.0" encoding="UTF-8"?> <entity-mappings xmlns="http://xmlns.jcp.org/xml/ns/persistence/orm" version="2.1"> ... <named-query name="Member.findByUsername"> <query><![CDATA[ select m from Member m where m.username = :username ]]></query> </named-query> <named-query name="Member.count"> <query>select count(m) from Member m</query> </named-query> </entity-mappings> 벌크 연산 여러 개의 데이터에 대한 갱신 쿼리 벌크연산은 주로 JPQL로 진행 JPA 자체는 실시간 단건성 작업에 적합 JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL 실행 e.g. 100건의 엔터티라면 100번의 UPDATE SQL 실행 executeUpdate() 영향 받은 엔터티 수 반환 쿼리 한 번으로 여러 테이블 로우 변경 UPDATE, DELETE 지원 String qlString = "update Product p " + "set p.price = p.price * 1.1 " + "where p.stockAmount < :stockAmount"; int resultCount = em.createQuery(qlString) .setParameter("stockAmount", 10) .executeUpdate(); insert into .. select 하이버네이트가 INSERT 지원 벌크 연산 사용 전략 JPQL은 영속성 컨텍스트를 무시하고 DB에 직접 쿼리하므로 벌크 연산 사용 맥락이 중요 사용 전략 1: 벌크 연산을 먼저 실행 영속성 컨텍스트에 아무 것도 하지 않고 벌크 연산만 실행 영속성 컨텍스트가 비어 있으니 벌크 연산으로 새로 조회가 발생해도 문제 없음 DB에서 최신 데이터 가져와 1차캐시에 반영할 것이므로 사용 전략 2: 벌크 연산 수행 후 영속성 컨텍스트 초기화 (em.clear()) 어떤 엔터티가 미리 조회되어 있는 상황에서 벌크 연산을 진행 JPQL 호출로 플러시 자동 발생 벌크 연산 후 영속성 컨텍스트는 DB에 비해 Old한 상태가 됨 e.g. 처음 조회한 회원 엔터티의 연봉이 5000만원 이후 수행한 벌크 연산에서 연봉이 6000만원이 되어 DB에 플러시됨 이 경우 애플리케이션에서는 여전히 회원 연봉이 5000만원임 따라서, 영속성 컨텍스트를 비워주어 깨끗한 상태에서 다시 조회될 수 있도록 해야 함 Reference 자바 ORM 표준 JPA 프로그래밍 - 기본편

Java-Ecosystem · 2024-06-08

JPA Dive

Java-Ecosystem · 2024-06-02

비동기 SQLAlchemy 기본

비동기 SQLAlchemy SQLAlchmey 1.4 이상부터 비동기 문법 지원 시작 비교적 최근에 나와 문법이 불안정한 느낌이지만, DB 비동기 처리는 FastAPI의 성능을 크게 향상 시킬 지점 주요 비동기 지원 모듈: sqlalchemy.ext.asyncio create_async_engine (비동기 데이터베이스 엔진) AsyncSession (비동기 세션) sessionmaker(class_=AsyncSession) (비동기 세션 팩토리) 기존 sessionmaker에 class_만 추가 비동기 Session 사용법 AsyncSessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine, class_=AsyncSession) async def get_db(): async with AsyncSessionLocal() as session: yield session 테이블 초기 생성 async with engine.begin() as conn: await conn.run_sync(Base.metadata.create_all) 조회 Syntax (2.0 스타일 코드) 조회 실행 await db.execute(...) select 객체로 SQL 쿼리를 조합해 execute 에 넣어 실행 모든 컬럼 조회 sqlalchemy.future 패키지에서 select를 import e.g. select(User) 특정 컬럼 조회 e.g. select(User.email) WHERE절 filter e.g. filter(User.nickname == 'veluga') 정렬 오름차순 정렬 order_by(User.id) 조회 방법 단건 조회 scalar() 복수 리스트 조회 scalars().all() 조회 결과의 개수 반환 from sqlalchemy import func result = await db.execute(select(func.count()).select_from(select(User))) count = result.scalars().one() 그룹화 및 집계 함수 사용 패턴 func에서 원하는 집계함수 사용 (count, sum, max, min…) from sqlalchemy import func result = await db.execute(select(func.count(User.id)).group_by(User.id)) result.scalars().all() 삭제 Syntax await db.delete("조회한 모델 객체") await db.commit()

Python-Ecosystem · 2024-05-28

FastAPI와 비동기

FastAPI와 비동기 FastAPI는 비동기 처리에 최적화 (비동기 코드를 사용한다면 성능 이점) 비동기 작업 CPU와 RAM 간의 작업이 1이라고 한다면, CPU에서 IO 작업은 1000, 10000이 걸린다고 생각할 수 있음 IO 작업시 쉬고 있는 CPU가 다른 작업을 할 수 있다면, 성능이 대폭 상승 비동기 처리를 사용하면 단일 스레드에서 여러 작업을 효율적으로 수행 가능 데이터베이스 쿼리나 HTTP 요청 같이 I/O bound 작업의 성능을 크게 향상시킴 이점을 볼 수 있는 상황 비동기 작업은 프로그램에서 지원해주어야 사용 가능 내부적 관점 프레임워크 내부적인 처리에서 IO 작업들을 비동기로 처리할 것이므로 성능 향상 IO 작업은 따로 없더라도 비동기 코드를 작성했다면 내부적으로도 성능 이점을 얻을 수 있음 프로그램적 관점 CPU 작업만하는 코드로 이루어진 프로그램은 성능상 크게 이점을 보기 어려움 작성한 코드가 IO 작업을 필요로 한다면 성능 향상 조건 코드를 비동기적으로 짜야 함(async, await) 사용하는 IO 라이브러리 자체가 비동기를 지원해야 함 프레임워크가 비동기를 지원해야 함 (FastAPI) 웹서비스 시나리오 쿼리가 3초 걸리는 API 경로로 10개 요청이 동시에 온다면, 동기적 처리 상황 시 첫 사람은 3초가 걸리지만, 10번째 사람은 30초 걸림 비동기적으로 처리할 시, 뒷사람들의 대기시간도 기존 최대 30초보다 훨씬 줄어들 것 async/await async def 비동기 함수를 정의 Future 객체 반환 await 비동기 함수 내에서 사용 특정 비동기 연산이 완료될 때까지 함수의 실행을 일시적으로 중단하고 해당 연산의 완료를 기다림 이벤트 루프 프로그램 진입점에서 실행 asyncio.run(main()) 같이 사용해 주어진 코루틴을 실행하고 완료될 때까지 이벤트 루프를 유지 어떤 이벤트를 등록해두고 특정 이벤트가 발생했는지 여부를 지속적으로 체크 (내부 반복문) 실행되던 비동기 함수가 종료되면서 이벤트를 발생시키고, 그 후 await 뒷 부분의 코드가 이어서 실행됨 asyncio.gather 여러 코루틴을 동시에 실행 모든 코루틴이 완료될 때까지 기다린 후, 코루틴 결과를 포함하는 리스트 반환

Python-Ecosystem · 2024-05-28

스프링 데이터 접근 핵심 원리

Java-Ecosystem · 2024-05-12

데이터베이스 첫걸음

Computer Science · 2024-04-29

스프링 MVC 원리

Web Server & Web Application Server Web Server (HTTP) 정적 리소스 제공 + 기타 부가기능 동적인 처리(애플리케이션 로직 등)가 필요하면 WAS에 요청 위임 예시) NGINX, APACHE Web Application Server (HTTP) 애플리케이션 로직 수행 (프로그램 코드 실행) + 웹 서버 기능 (정적 리소스 제공) 동적 HTML, HTTP API(JSON), 서블릿, JSP, Spring MVC API 서버만 제공할 경우 WAS만으로 서버 구축해도 괜찮음 (회사끼리 데이터 주고 받을 때) 예시) Tomcat, Jetty, Undertow WAS는 애플리케이션 코드 실행에 더 특화되어 있다! 웹서버와 WAS는 서로가 서로의 기능을 가지고 있긴 해서 경계가 모호 서블릿 컨테이너 기능 제공하면 WAS라 보기도 함 (서블릿 사용안하는 프레임워크도 있지만…) 공존 이유 효율적인 리소스 관리 WAS가 너무 많은 역할을 담당하여 서버 과부하 우려 애플리케이션 로직은 값어치가 높으므로 값이 낮은 정적 리소스 때문에 과부하되면 안됨 역할 분리 정적 리소스 사용이 많을 때는 Web Server 증설 애플리케이션 리소스 사용이 많을 때는 WAS 증설 지속적인 오류 화면 제공 WAS는 잘 죽는 반면, Web Server는 잘 안 죽음 WAS 및 DB 장애시 Web Server가 오류화면 제공 가능 Servlet 메시지 수신, 파싱, 응답 메시지 생성 및 송신 등 HTTP 스펙의편리한 사용을 지원하는 자바 클래스 서블릿을 지원하는 WAS를 사용하면, 의미있는 비즈니스 로직에만 집중 가능 사용 방법 메인 함수가 실행되는 클래스에 @ServletComponentScan 추가 HttpServlet을 상속받고 @WebServlet 애노테이션에 name과 urlPatterns를 지정 protected의 service 코드를 오버라이딩해 비즈니스 로직 작성 HttpServletRequest와 HttpServletResponse 타입 파라미터로 요청 및 응답 정보 사용 가능 부가 기능 임시 저장소 기능: HTTP 요청의 시작과 끝까지 유지, View에 데이터 전달하는 Model 역할도 수행 세션 관리 기능: request.getSession(create: true) 흐름 HTTP 요청시 WAS가 Request, Response 객체를 생성해서 서블릿 객체 호출 서비스 로직에서 Request 객체의 HTTP 요청 정보를 이용하고 Response 객체에 응답 정보 입력 WAS는 Response 객체에 담긴 내용으로 HTTP 응답 정보 생성 Servlet Container(서블릿 컨테이너) 서블릿을 지원하는 WAS (톰캣) 서블릿 객체의 생명주기 관리 (생성, 초기화, 호출, 종료) 서블릿 객체를 싱글톤으로 관리 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용 공유 변수 사용에는 주의해야 함 동시 요청을 위한 멀티 쓰레드 처리 지원 덕분에 개발자가 멀티 쓰레드를 신경쓰지 않고 마치 싱글 쓰레드 프로그래밍 하듯이 편리하게 개발 (WAS가 개발 생산성을 가장 높여주는 부분) 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용 (공유변수, 멤버변수 조심) 동시요청 (멀티 쓰레드) 쓰레드 애플리케이션 코드를 하나하나 순차적으로 실행하는 것 (한번에 하나의 코드 라인만 수행) 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행 동시 처리가 필요하면 쓰레드를 추가로 생성 서블릿 객체는 쓰레드가 호출 멀티 쓰레드는 동시요청 처리 가능 (단일 쓰레드로는 처리가 어려움) 요청마다 쓰레드 생성 장점 동시 요청 처리 가능 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작 단점 쓰레드 생성 비용은 매우 비쌈 (요청마다 쓰레드 생성하면 응답 속도도 늦어짐) 컨텍스트 스위칭 비용 발생 (하나의 CPU 코어에 2개 이상의 쓰레드를 돌리면 발생) 쓰레드 생성에 제한 없음 (요청이 너무 많으면, CPU와 메모리 임계점을 넘어 서버가 죽음) 쓰레드 풀 설정한 최대치 만큼 쓰레드를 미리 생성해 풀에 보관하고 관리 (톰캣 기본설정: 최대 200개) 요청이 들어오면 쓰레드 풀에서 쓰레드를 할당하고 다 쓰면 반납 (재사용) 풀에 남은 쓰레드가 부족하면 대기 중인 요청은 거절하거나 특정 숫자만큼만 대기하도록 설정 가능 장점 쓰레드를 미리 생성하므로, 쓰레드 생성 비용(CPU)이 절약되고 응답이 빠름 쓰레드 풀 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리 가능 WAS의 주요 튜닝 포인트는 최대 쓰레드 수(max thread) 동시 요청이 많은 상황에서 너무 낮게 설정 시: 서버 리소스는 여유롭지만, 금방 클라이언트 응답 지연이 발생 100개 요청이 왔는데 최대 쓰레드가 10개면 동시에 10개 요청만 처리 그런데 사실 CPU는 5% 밖에 사용안함 너무 높게 설정 시: CPU, 메모리 임계점 초과로 서버 다운 발생 10000개의 요청이 오면 10000개를 모두 받아들이다가 서버가 죽음 장애 발생시 클라우드면 일단 서버부터 늘리고 이후 튜닝 클라우드가 아니면 바로 튜닝 적정 쓰레드 풀 숫자는 성능 테스트를 통해 찾아야 함 애플리케이션 로직 복잡도, CPU & 메모리 & IO 리소스 상황에 따라 모두 다름 최대한 실제 서비스와 유사하게 성능 테스트 시도 아파치 ab, 제이미터, nGrinder 백엔드가 고려할 3가지 HTTP 통신 정적 리소스 어떻게 제공할지 동적 HTML 페이지 어떻게 제공할지 (View Template) API 어떻게 제공할지 (JSON) MVC 패턴 배경 비즈니스 로직과 뷰는 변경의 라이프 사이클이 다르므로, 분리하는 것이 좋은 설계 역할을 나누면 유지보수성이 향상되고 각각의 기능을 특화할 수 있음 컨트롤러 (Controller) HTTP 요청을 받아서 파라미터를 검증하고 비즈니스 로직 및 오케스트레이션 작업 실행 오케스트레이션: 데이터 접근 및 모델 담기 등의 작업 지금은 더 고도화 되어서 다음 두 가지 패턴을 띔 서비스 계층: 비즈니스 로직 + 오케스트레이션 서비스 계층: 오케스트레이션 / 도메인 모델: 비즈니스 로직 모델 (Model) 뷰에 출력할 데이터를 담아둠 뷰 (View) 화면을 렌더링하는 일에 집중 HTML 생성에 더하여 XML, Excel, JSON 생성 등도 포괄 SSR & CSR 서버 사이드 렌더링 (SSR) HTML 최종 결과를 서버에서 만들어서 웹브라우저에 전달 JSP, Thymeleaf (백엔드 기술) 클라이언트 사이드 렌더링 (CSR) HTML 최종 결과를 JS를 이용해 웹 브라우저에서 동적으로 생성해 적용 필요한 부분만 부분부분 변경 React, Vue.js (프론트엔드 기술) CSR + SSR 동시 지원하는 프론트 기술도 존재하므로 칼같이 나눌 필요 X (Next.js) SSR도 JS 이용해 화면 일부를 동적으로 변경 가능 자바 웹기술 역사 Servlet(1997) HTML 생성이 어려움 (동적 HTML을 생성할 수 있으나 자바코드로 일일히 HTML 만들어야 해서 불편) JSP(1999) HTML 생성이 편리해 JSP로 모두 개발 비즈니스 로직과 뷰 로직이 결합되어 코드라인이 너무 많아지고 유지보수 저하 Servlet + JSP MVC 패턴 모델, 뷰, 컨트롤러로 역할을 나눠 비즈니스 로직과 화면 렌더링 부분을 나눔 한계점: 공통 기능 처리가 어려움 dispatcher.forward() 같은 View로 이동하는 코드 중복 /WEB-INF/views 와 .jsp 같은 ViewPath 중복 (JSP 의존성도 증가) HttpServletResponse response는 파라미터로 항상 존재하지만 사용 X 공통 기능을 메서드로 뽑는 방안도 여전히 호출 중복이 존재하며 호출을 강제하지는 못함 프론트 컨트롤러 패턴의 등장 배경 MVC 프레임워크 춘추 전국 시대 (2000년 초 ~ 2010년 초) 반복되는 MVC 패턴을 자동화하기 위해 여러 프레임워크 등장 스트럿츠, 웹워크, 스프링 MVC(과거 버전) 당시에는 스트럿츠 + 스프링 코어(MVC 제외한 service, DAO, repository) 형태를 주로 사용 FrontController 패턴 적용 프론트 컨트롤러 서블릿 하나로 클라이언트 요청을 받음 (나머지 컨트롤러는 서블릿 사용 X) 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아 호출 공통 처리 담당 스프링 MVC 핵심도 프론트 컨트롤러 패턴 애노테이션 기반의 스프링 MVC MVC 프레임워크 혼돈 시대 정리 @RequestMapping 기반의 애노테이션 컨트롤러 등장으로, 스프링은 MVC 부분에서도 완승 스프링 부트 (Spring Boot) 빌드 결과(Jar)에 WAS 서버(Tomcat)를 포함하여 빌드 배포를 단순화 빌드된 Jar 파일을 아무 서버에 넣고 말아서 실행하면 됨 과거에는 서버에 WAS(Tomcat)를 직접 설치하고 Jar 파일을 모아 War 파일을 만들어서 배포를 위한 특정 폴더에 집어 넣어 배포해야 했음 최신 기술 - 스프링 웹 기술의 분화 Web Servlet - Spring MVC 서블릿 위에 Spring MVC를 올려서 동작 Web Reactive - Spring WebFlux 비동기 Non-Blocking 처리 최소 쓰레드로 최대 성능 (컨텍스트 스위칭 비용 효율화) CPU 코어가 4개 있으면 쓰레드 개수를 4 혹은 +1(5개) 정도로 맞춤 고효율로 CPU 개수에 딱 맞췄기 때문에 쓰레드가 계속 돌아가고 컨텍스트 스위칭 비용이 거의 안듦 함수형 스타일로 개발 - 동시처리 코드 효율화 WAS에서 상품 조회, 주문 서버 조회 등 여러 개의 서버에 여러 개 API를 동시에 찔러서 데이터를 가져와 조합해야 할 때 매우 효율적 Java 코드는 깔끔하지 않지만 함수형 스타일 코드는 매우 깔끔 (Netty) 서블릿 사용 X 단점 기술적 난이도 매우 높음 RDB 지원 부족 NoSQL(Redis, Elastic Search, DynamoDB, MongoDB)은 지원 잘 됨 일반 MVC 쓰레드 모델도 충분히 빠름 좋은 장비 띄워서 쓰레드 1000개 넣고 돌려도 잘 돌아감 실무에서 아직 많이 사용 X 자바 뷰 템플릿 역사 JSP 느린 속도, 부족한 기능 Freemarker, Velocity 빠른 속도 (Thymeleaf 보다 빠름) Thymeleaf (권장) 네추럴 템플릿 HTML 태그 속성을 이용하므로 HTML의 모양을 유지하면서 뷰 템플릿 적용 가능 스프링 MVC와 강한 기능 통합 스프링 MVC 핵심 구조와 원리 구조 DispatcherServlet 프론트 컨트롤러 (스프링 MVC의 핵심) 부모 클래스로부터 HttpServlet을 상속 받아, 서블릿으로서 동작 스프링 부트는 DispatcherServlet을 서블릿으로 자동 등록하면서, 모든 경로(urlPatterns="/")에 대해서 매핑 흐름 서블릿이 호출되면 DispatcherServlet의 부모인 FrameworkServlet에서 오버라이드한 HttpServlet에서 제공하는 service() 메서드가 호출됨 이후 여러 메서드가 호출되다가 DispatcherServlet.doDispatch()를 호출 HandlerMapping 요청 URL과 핸들러(컨트롤러)의 매핑 핸들러 (Handler) 컨트롤러를 포괄 꼭 컨트롤러 개념이 아니더라도 어떠한 것이든 어댑터가 지원하면 처리 가능 HandlerAdapter (in 핸들러 어댑터 목록) 다양한 버전의 규격이 다른 핸들러들을 호환 가능하게 도움 프레임워크를 유연하고 확장성 있게 설계 가능 어댑터 패턴 덕분에 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리 가능 핵심 메서드 boolean supports(Object handler) 어댑터가 해당 컨트롤러를 처리할 수 있는지 판단 ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) 실제 컨트롤러를 호출하고 ModelAndView 반환 컨트롤러가 ModelAndView를 반환하지 못하면, 어댑터가 직접 생성해서라도 반환 ModelAndView 논리 뷰 이름을 가짐 뷰 렌더링에 필요한 모델 객체 포함 ViewResolver (물리 뷰 경로 반환기) 논리 뷰 이름을 실제 물리 뷰 경로로 변경 e.g. return new View("/WEB-INF/views/" + viewName + ".jsp"); View 물리 뷰 경로를 가짐 모델 정보와 함께 render() 메서드를 호출 (해당 물리명 주소로 servlet의 forward 함수 호출) 동작 순서 핸들러 조회: 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회 자동 등록된 HandlerMapping들을 순서대로 실행해 핸들러 탐색 스프링 부트가 자동 등록하는 핸들러 매핑 종류 (우선순위 내림차순) RequestMappingHandlerMapping: 애노테이션 기반 컨트롤러에 사용 (@RequestMapping) BeanNameUrlHandlerMapping: 스프링 빈의 이름으로 핸들러 탐색 (@Component("...")) 핸들러 어댑터 조회: 핸들러를 실행할 수 있는 핸들러 어댑터 조회 자동 등록된 HandlerAdapter들의 supports()를 순서대로 호출 스프링 부트가 자동 등록하는 핸들러 어댑터 종류 (우선순위 내림차순) RequestMappingHandlerAdapter: 애노테이션 기반 컨트롤러에 사용 (@RequestMapping) HttpRequestHandlerAdapter: HttpRequestHandler 인터페이스 처리 (서블릿 유사) SimpleControllerHandlerAdapter: Controller 인터페이스 처리 (과거) 핸들러 어댑터 실행 핸들러 실행: 핸들러 어댑터가 실제 핸들러 실행 ModelAndView 반환: 핸들러 어댑터는 핸들러의 반환 결과를 ModelAndView로 변환해 반환 @ResponseBody, HttpEntity(ResponseEntity) 있는 경우 ViewResolver 호출하지 않고 이대로 종료 ViewResolver 호출: 뷰 리졸버를 찾고 실행 주어진 논리 뷰 이름으로 자동 등록된 viewResolver들을 순서대로 호출 스프링 부트가 자동 등록하는 뷰 리졸버 BeanNameViewResolver: 빈 이름으로 뷰를 찾아서 반환 (엑셀 파일 생성에 사용) InternalResourceViewResolver: JSP를 처리할 수 있는 뷰를 반환 application.properties 파일에 prefix와 suffix 등록 (권장) spring.mvc.view.prefix=/WEB-INF/views/ spring.mvc.view.suffix=.jsp View 반환: 뷰 리졸버는 뷰의 논리 이름을 물리 이름으로 바꾸고, 뷰 객체 반환 JSP의 경우 InternalResourceView(JstlView)를 반환 (내부에 forward() 로직 존재) 다른 뷰 템플릿들은 forward() 과정 없이 바로 렌더링 뷰 렌더링: 뷰 객체의 render() 메서드 호출 스프링 MVC 기본 기능 Controller 관련 기능 컨트롤러 애노테이션 @Controller 스프링이 자동으로 컨트롤러로 인식해 스프링 빈으로 등록 반환 값이 String이면 뷰 이름으로 인식하여, 뷰를 찾고 렌더링 @RestController 스프링이 자동으로 컨트롤러로 인식해 스프링 빈으로 등록 반환 값으로 HTTP 메시지 바디에 바로 입력 (@Controller + @ResponseBody) @RequestMapping 요청 정보 URL 매핑 대부분의 속성을 배열로 제공하므로 다중 설정 가능 {"/hello-basic", "/hello-go"} HTTP 메서드를 설정하지 않으면 메서드 모두 허용 설정하려면 아래와 같이 적용해야 해서 불편함 @RequestMapping(value = "/", method = RequestMethod.GET) HTTP 메서드 축약 애노테이션 제공 @GetMapping/@PostMapping/@PutMapping/@PatchMapping/@DeleteMapping @RequestMapping 내포 클래스 레벨 + 메서드 레벨 조합 적용 (효율적 URL 매핑 적용) @Controller @RequestMapping("/springmvc/members") public class SpringMemberController { @GetMapping("/new-form") // @RequestMapping도 가능 public ModelAndView newForm() { ... } @PostMapping("/save") // @RequestMapping도 가능 public ModelAndView save() { ... } @GetMapping // @RequestMapping도 가능 public ModelAndView members() { ... } } 경로 변수 조회 기본 사용법 @PathVariable("userId") String userId 경로변수 이름과 변수명이 같으면 생략 가능 @PathVariable String userId HTTP 헤더 조회 모든 헤더 조회 @RequestHeader MultiValueMap<String, String> headerMap 하나의 키에 여러 값을 받는 HTTP header, 쿼리 파라미터를 처리 가능 특정 헤더 조회 @RequestHeader("host") String host 속성: required (필수 값 여부), defaultValue (기본값) 특정 쿠키 조회 @CookieValue(value = "myCookie", required = false) 속성: required (필수 값 여부), defaultValue (기본값) 서블릿 조회 HttpServletRequest request HttpServletResponse response 특수 조회 Locale locale HttpMethod httpMethod … HTTP 요청 파라미터 조회 (GET 쿼리 파라미터, POST HTML Form) @RequestParam("요청 파라미터 이름") request.getParameter("파라미터 이름")와 유사 요청 파라미터와 변수명이 같으면 생략 가능 Primitive 타입이면 @RequestParam도 생략가능 required=false 자동 적용 완전 생략은 과한 측면도 있으니 유의 속성: required (필수 값 여부), defaultValue (기본값) Map으로 조회하기 @RequestParam Map<String, Object> paramMap @RequestParam MultiValueMap<String, Object> paramMap 파라미터의 값이 1개가 확실하다면 Map을 사용하지만, 아니라면 MultiValueMap을 사용 서블릿 조회 HttpServletRequest의 request.getParameter() HTTP 요청 메시지 바디 조회 @RequestBody HttpMessageConverter 사용 (요청이 content-type: application/json일 때) 헤더 정보가 필요할 땐, HttpEntity 혹은 @RequestHeader 사용할 것 생략 불가능 단순 Text (StringHttpMessageConverter) @RequestBody String messageBody JSON (MappingJackson2HttpMessageConverter) @RequestBody HelloData data 직접 만든 객체 지정 HttpEntity 조회 HttpMessageConverter 사용 (요청이 content-type: application/json일 때) 단순 Text (StringHttpMessageConverter) HttpEntity<String> httpEntity String messageBody = httpEntity.getBody(); JSON (MappingJackson2HttpMessageConverter) HttpEntity<HelloData> httpEntity RequestEntity HttpEntity를 상속 받음 HttpMethod, URL 정보 추가 가능 서블릿 조회 단순 Text HttpServletRequest request ServletInputStream inputStream = request.getInputStream(); String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8); InputStream inputStream String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8); JSON 단순 Text와 유사하나 다음 코드가 추가됨 private ObjectMapper objectMapper = new ObjectMapper(); Jackson 라이브러리 ObjectMapper를 사용 (JSON to 자바 객체) MappingJackson2HttpMessageConverter가 하는 작업을 수동으로 진행 HelloData data = objectMapper.readValue(messageBody, HelloData.class); 조건 매핑 파라미터 특정 파라미터 조건 매핑 (params) @GetMapping(value = "/mapping-param", params = "mode=debug") 특정 요청 파라미터 포함한 요청만 받음 http://localhost:8080/mapping-param?mode=debug 특정 헤더 조건 매핑 (headers) @GetMapping(value = "/mapping-header", headers = "mode=debug") 미디어 타입 조건 매핑 HTTP 요청 헤더 Content-Type (consume) @PostMapping(value = "/mapping-consume", consumes = "application/json") 만약 맞지 않으면 상태코드 415 Unsupported Media Type 반환 사용 예시 consumes = "text/plain" consumes = {"text/plain", "application/*"} consumes = MediaType.TEXT_PLAIN_VALUE HTTP 요청 헤더 Accept (produce) @PostMapping(value = "/mapping-produce", produces = "text/html") 만약 맞지 않으면 상태코드 406 Not Acceptable 반환 사용예시 produces = "text/plain" produces = {"text/plain", "application/*"} produces = MediaType.TEXT_PLAIN_VALUE produces = "text/plain;charset=UTF-8" required & defaultValue 속성 required 속성 required의 기본값은 true 주의사항 파라미터 이름만 사용하는 요청의 경우 @RequestParam(required = true) String username 요청: /request-param-required?username= -> 빈 문자열로 통과 요청: /request-param-required -> 400 예외 발생 Primitive 타입에 null 입력하는 경우 @RequestParam(required = false) int age 요청: /request-param -> 500 예외 발생 (null을 int에 입력 불가능) 해결 방법 @RequestParam(required = false) Integer age 요청: /request-param -> null 입력 통과 @RequestParam(required = false, defaultValue = "-1") int age 요청: /request-param -> 기본값이 있으므로 required가 무의미 defaultValue 속성 파라미터에 값이 없는 경우 지정한 기본값 적용 기본 값이 있기 때문에 required는 의미 없어짐 빈 문자의 경우도 기본값 적용 (요청: /request-param-default?username=) 클라이언트 to 서버 데이터 전달 방법 3가지 쿼리 파라미터 (GET) HTML Form (POST, 메시지 바디에 쿼리 파라미터 형식으로 전달) HTTP message body (POST, PUT, PATCH) 요청 파라미터 VS HTTP 메시지 바디 요청 파라미터 조회: @RequestParam, @ModelAttribute (생략 가능) HTTP 메시지 바디 조회: @RequestBody (생략 불가능, 생략하면 @ModelAttribute로 기능) 스프링 부트 3.2: 파라미터 이름 생략시 발생하는 예외 (@PathVariable, @RequestParam) java.lang.IllegalArgumentException: Name for argument of type [java.lang.String] not specified, and parameter name information not found in class file either. 해결방법 1. 파라미터 이름을 생략하지 않고 항상 적기 해결방법 2. 컴파일 시점에 -parameters 옵션 추가 (File -> Settings -> Build, Execution, Deployment → Compiler → Java Compiler -> Additional command line parameters) 해결방법 3. Gradle을 사용해서 빌드하고 실행 (권장) View 관련 기능 정적 리소스 (HTML, CSS, JS 제공) 스프링 부트는 기본 정적 리소스 경로 제공 src/main/resources/static 실제 서비스에서도 공개되기 때문에 공개할 필요없는 HTML을 두는 것을 조심할 것! 접근 요청: http://localhost:8080/basic/hello-form.html 제공: src/main/resources/static/basic/hello-form.html 뷰 템플릿 (동적 HTML 제공) 스프링 부트는 기본 뷰 템플릿 경로 제공 src/main/resources/templates 사용 방법 String 반환 ViewName 직접 반환 (뷰의 논리 이름을 리턴) @ResponseBody가 없으면 뷰 리졸버를 실행 String 반환: 리다이렉트 지원 (RedirectView) redirect:/ return "redirect:/basic/items/{itemId}"; RedirectAttributes 함께 사용 권장 URL에 ID 값을 넣을 때 URL 인코딩이 안되어 위험 URL 인코딩 + 경로변수, 쿼리 파라미터 처리 @PostMapping("/add") public String addItem(Item item, RedirectAttributes redirectAttributes) { Item savedItem = itemRepository.save(item); redirectAttributes.addAttribute("itemId", savedItem.getId()); redirectAttributes.addAttribute("status", true); return "redirect:/basic/items/{itemId}"; } ModelAndView 생성 및 반환 (권장 X) ModelAndView mv = new ModelAndView("뷰 논리경로") mv.addObject("객체 이름", 실제 객체): 모델에 데이터 추가 void 반환 (권장 X) 요청 URL을 참고해 논리 뷰 이름으로 사용 /response/hello(요청) -> templates/response/hello.html (실행) 실행 조건 @Controller O HTTP 메시지 바디 처리 파라미터 X (HttpServletResponse, OutputStream) 접근 반환: response/hello 실행: templates/response/hello.html HTTP 응답 메시지 바디 직접 입력 (API 방식, 정적 리소스나 뷰 템플릿 거치치 않음) @ResponseBody HttpMessageConverter 사용 단순 Text (StringHttpMessageConverter) -> String 리턴 JSON (MappingJackson2HttpMessageConverter) -> Java 객체 리턴 상태코드 입력: @ResponseStatus @ResponseStatus(HttpStatus.OK) 클레스 레벨 및 메서드 레벨 모두 적용 가능 HttpEntity HttpMessageConverter 사용 단순 Text (StringHttpMessageConverter) -> String 리턴 JSON (MappingJackson2HttpMessageConverter) -> Java 객체 리턴 return new HttpEntity<>("ok"); ResponseEntity HttpEntity를 상속 받음 HTTP Status Code 추가 가능 단순 Text 반환 타입 선언: ResponseEntity<String> return new ResponseEntity<>("Hello World", responseHeaders, HttpStatus.CREATED) JSON 반환 타입 선언: ResponseEntity<HelloData> return new ResponseEntity<>(helloData, HttpStatus.OK) 서블릿 응답 HttpServletResponse response response.getWriter().write("ok"); Writer responseWriter responseWriter.write("ok"); Model 관련 기능 @Controller @RequestMapping("/springmvc/v3/members") public class SpringMemberControllerV3 { private MemberRepository memberRepository = MemberRepository.getInstance(); @GetMapping("/new-form") public String newForm() { return "new-form"; } @PostMapping("/save") public String save( @RequestParam("username") String username, @RequestParam("age") int age, Model model) { Member member = new Member(username, age); memberRepository.save(member); model.addAttribute("member", member); return "save-result"; } @GetMapping public String members(Model model) { List<Member> members = memberRepository.findAll(); model.addAttribute("members", members); return "members"; } } Model model 파라미터 선언으로 편리하게 모델 사용 가능 model.addAttribute("객체 이름", 실제 객체): 모델에 데이터 추가 @ModelAttribute 요청 파라미터를 받아 객체에 바인딩하는 과정을 자동화 Primitive 이외 타입은 @ModelAttribute 생략가능 (argument resolver 지정타입 외) 이름을 생략하면 클래스 명의 첫글자만 소문자로 바꿔서 모델에 등록 (HelloData -> helloData) @ModelAttribute HelloData helloData 실행 과정 HelloData 객체 생성 요청 파라미터 이름으로 HelloData 객체의 프로퍼티 찾고 setter를 호출해 바인딩 @Data public class HelloData { private String username; private int age; } // 롬복 @Data = @Getter + @Setter + @ToString + // @EqualsAndHashCode + @RequiredArgsConstructor // 위험하기 때문에 사용 주의! DTO는 괜찮지만 핵심 도메인 모델엔 사용 X @ModelAttribute - 컨트롤러 레벨 적용 @ModelAttribute("regions") public Map<String, String> regions() { Map<String, String> regions = new LinkedHashMap<>(); regions.put("SEOUL", "서울"); regions.put("BUSAN", "부산"); regions.put("JEJU", "제주"); return regions; } 컨트롤러 클래스 내에 별도의 메서드로서 @ModelAttribute를 적용 가능 해당 클래스 내 모든 컨트롤러는 호출 시 미리 정의한 모델이 자동으로 담김 (반복 데이터 처리에 유리) HTTP 메시지 컨버터 @ResponseBody 사용시 반환값을 HTTP Body에 직접 입력 viewResolver 대신 HttpMessaveConverter 동작 HTTP Accept 헤더와 컨트롤러의 반환 타입 정보를 조합해 적절한 HttpMessageConverter 선택 HttpMessageConverter 인터페이스로서 HTTP 요청 및 응답에 모두 사용 주요 메서드 canRead(), canWrite(): 메시지 컨버터가 해당 클래스, 미디어타입을 지원하는지 체크 read(), write(): 메시지 컨버터를 통해 메시지를 읽고 쓰는 기능 동작 클래스 타입을 먼저 바라보고 컨버터 종류 채택 후, 미디어 타입 지원 확인 HTTP 요청 데이터 읽기 요청이 오고 컨트롤러는 @RequestBody, HttpEntity(RequestEntity) 사용 canRead() 호출 (메시지 컨버터가 메시지 읽을 수 있는 지 확인) 대상 클래스 타입을 지원하는가 (@RequestBody의 대상 클래스) HTTP 요청의 Content-Type 헤더의 미디어 타입을 지원하는가 조건을 만족하면 read() 호출해, 객체 생성 및 반환 HTTP 응답 데이터 생성 컨트롤러에서 @ResponseBody, HttpEntity(ResponseEntity)로 값을 반환 canWrite() 호출 (메시지 컨버터가 메시지를 쓸 수 있는지 확인) 대상 클래스 타입을 지원하는가 (return의 대상 클래스) 미디어 타입을 지원하는가 @RequestMapping의 produces가 세팅되어 있으면 이 값을 기준으로 처리 아니라면 HTTP 요청의 Accept 헤더의 미디어 타입을 지원하는지 여부 확인 조건을 만족하면 write() 호출해, HTTP 응답 메시지 바디에 데이터 생성 스프링 부트 기본 메시지 컨버터 (우선순위 순서로) ByteArrayHttpMessageConverter 기본이 바이트 배열로 오므로 변환 없이 그대로 받이들이는 것 클래스 타입: byte[], 미디어 타입: */* 요청 예 @RequestBody byte[] data 응답 예 @ResponseBody return byte[] 쓰기 미디어 타입: application/octet-stream StringHttpMessageConverter 바이트로 오는 데이터를 문자열로 처리 클래스 타입: String, 미디어타입: */* 요청 예 @RequestBody String data 응답 예 @ResponseBody return "ok" 쓰기 미디어타입: text/plain MappingJackson2HttpMessageConverter 바이트로 오는 데이터를 객체 또는 HashMap으로 처리 클래스 타입: 객체 또는 HashMap, 미디어 타입: application/json 요청 예 @RequestBody HelloData data 응답 예 @ResponseBody return helloData 쓰기 미디어타입: application/json HTTP 메시지 컨버터의 위치 HTTP 메시지 컨버터는 RequestMappingHandlerAdapter에서 실제로 사용 (애노테이션 기반) RequestMappingHandlerAdapter 동작 방식 ArgumentResolver 호출 정확히는 HandlerMethodArgumentResolver 핸들러의 파라미터, 애노테이션 정보를 기반으로 핸들러가 필요로 하는 요청 데이터 생성 (HttpServletRequest, Model, @RequestParam, @ModelAttribute, @RequestBody, HttpEntity) 과정 ArgumentResolver 구현체들을 탐색하며 (InvocableHandlerMethod) supportsParameter() 호출 (해당 파라미터 지원 여부 체크) 지원 가능하면 resolveArgument() 호출 (실제 객체 생성) HTTP 메시지 컨버터 사용해 데이터 처리 후 리턴 (canRead(), read()) 핸들러 호출 (with 생성된 요청 데이터) ReturnValueHandler 정확히는 HandlerMethodReturnValueHandler 컨트롤러의 반환 값을 변환해 응답 데이터 생성 (ModelAndView, @ResponseBody, HttpEntity) 과정 ReturnValueHandler 구현체들을 탐색하며 (ServletInvocableHandlerMethod) supportsReturnType() 호출 (해당 리턴 타입 지원 여부 체크) 지원 가능하면 handleReturnValue() 호출 HTTP 메시지 컨버터 사용해 데이터 처리 (canWrite(), write()) HTTP 메시지 컨버터 적용 경우 스프링 MVC는 다음 상황에서 HTTP 메시지 컨버터를 적용한다. HTTP 요청: @RequestBody, HttpEntity(RequestEntity) HTTP 응답: @ResponseBody, HttpEntity(ResponseEntity) 스프링 MVC 주요 ArgumentResolver & ReturnValueHandler @RequestBody, @ResponseBody 존재: RequestResponseBodyMethodProcessor() 사용 HttpEntity 존재: HttpEntityMethodProcessor() 사용 기능 확장 기능 확장은 WebMvcConfigurer 상속 및 스프링 빈 등록을 통해 구현한다. 스프링은 다음을 모두 인터페이스로 제공하므로, 언제든 커스터마이징 기능 확장이 가능하다. HandlerMethodArgumentResolver HandlerMethodReturnValueHandler HttpMessageConverter @Bean public WebMvcConfigurer webMvcConfigurer() { return new WebMvcConfigurer() { @Override public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) { //... } @Override public void extendMessageConverters(List<HttpMessageConverter<?>> converters) { //... } }; } Reference 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 View, ViewResolver (SERVLET) @RequestBody는 어떻게 동작할까?

Java-Ecosystem · 2024-04-21

스프링 로깅 기본

로깅 (Logging) 스프링 부트 로깅 라이브러리(spring-boot-starter-logging)에서 다음 로깅 라이브러리 사용 SLF4J 라이브러리: 로그 라이브러리를 통합해서 인터페이스로 제공 (Logback, Log4J, Log4J2…) Logback 라이브러리: 실무에서 구현체 로그 라이브러리로 주로 사용 (스프링 부트 기본 제공) 로그 선언 기본 사용법 private static final Logger log = LoggerFactory.getLogger(getClass()); 롬복 사용 @Slf4j 다음 코드를 자동 생성 private static final Logger log = LoggerFactory.getLogger(Xxx.class); 올바른 로그 사용법 올바른 사용법: log.debug("data={}", data) 잘못된 사용법: log.debug("String concat log=" + name) 로그 출력 레벨을 info로 설정하면 로그 남지 않으나, 더하기 연산은 무조건 수행되어 비효율 로그 출력 포멧 시간 / 로그 레벨 / 프로세스 ID / 쓰레드 명 / 클래스명 / 로그 메시지 로그 레벨 수준 (정보가 많은 순서로) TRACE > DEBUG > INFO > WARN > ERROR DEBUG: 개발 서버 적합 INFO: 운영 서버 적합 로그 레벨별 호출 방법 //@Slf4j @RestController public class LogTestController { private final Logger log = LoggerFactory.getLogger(getClass()); @RequestMapping("/log-test") public String logTest() { String name = "Spring"; log.trace("trace log={}", name); log.debug("debug log={}", name); log.info(" info log={}", name); log.warn(" warn log={}", name); log.error("error log={}", name); return "ok"; } } 로그 레벨 전역 설정 (application.properties) 전체 로그 레벨 설정 (디폴트: info) logging.level.root=info 특정 패키지 및 하위 패키지 로그 레벨 설정 logging.level.hello.springmvc=debug 장점 쓰레드 정보, 클래스 이름 같은 부가 정보 확인 가능 출력 포멧 조절 가능 로그 레벨 설정으로 상황에 맞게 조절 가능 파일, 네트워크 등 콘솔 뿐만 아니라 별도의 위치에 남길 수 있음 (파일의 경우 일별, 용량별 분할 가능) System.out 보다 성능도 좋음 Reference 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

Java-Ecosystem · 2024-04-14

MySQL 주요 명령

MySQL 주요 관리명령 show status MySQL의 상태에 대한 여러 정보 확인 Threads_connected 커넥션의 상태 및 수 Uptime 서버 가동 후 경과 시간 Queries 실행한 SQL의 수 show databases 데이터베이스 목록 보기 show tables 테이블 목록 보기 show table status 통계정보 보기 show create table 테이블명\G 테이블 정의 보기 explain SQL문 해당 SQL문의 실행계획 취득 show index from 테이블명 인덱스를 표시 desc 테이블명 테이블 열 정보 보기 use 데이터베이스 이름 특정 데이터베이스 사용하기 quit 로그오프 MySQL 주요 SQL CREATE TABLE 테이블명 1 LIKE 테이블 2; 테이블 구조만 복제해 생성하기 INSERT INTO 테이블명 VALUES (..., ..., ...), (..., ..., ...), (..., ..., ...); 복수 행 입력 (Multi row insert) INSERT 문 처리를 1번으로 정리해서 기존 INSERT 문 복수 회 실행 보다 처리시간이 더 짧음 다른 DBMS도 구현되어 있는 경우가 있음 (PostgreSQL, SQLServer, DB2…)

Computer Science · 2024-04-13

JPA 활용 팁 1

JPA 테이블 설계 Tips 주문 테이블은 orders로 주로 사용 (예약어 order by 때문에) 테이블 이름은 소문자 + _ 스타일 사용 실무에서 @ManyToMany는 사용하지 말자 중간 테이블에 컬럼을 추가할 수 없고 세밀한 쿼리가 어려움 @ManyToOne, @OneToMany로 풀어내서 사용 연관 관계에서 외래 키가 있는 곳을 연관 관계의 주인으로 정하기 (One-to-Many에서는 Many가 주인) Getter, Setter는 모두 제공하지 않고, 꼭 필요한 별도 메서드만 제공하는게 가장 이상적이지만 실무는 다름 Getter는 모두 열어놓으면 실무상 편리 엔티티 변경은 Setter를 모두 열어두기 보다 비즈니스 메서드를 별도 제공해 변경 지점이 명확하도록 함 엔티티의 식별자는 id로 쓰더라도 PK 컬럼명은 테이블명_id로 사용하자 Foreign key와 이름을 맞출 수 있는 장점 DBA들도 선호 Cascade=ALL 엔티티를 persist하면 다른 연관관계 엔티티까지 persist를 전파 Delete할 때는 모두 같이 지워짐 값 타입(임베디드 타입)은 변경 불가능하게 설계 @Setter를 제거하고 생성자에서 초기화 강제 기본 생성자를 protected로 두어 안전 향상 JPA 스펙 상 엔티티 및 임베디드 타입은 기본 생성자를 public 혹은 protected로 두어야 함 JPA가 객체 생성시 리플랙션 같은 기술을 사용할 수 있도록 지원해야 하기 때문 실무에서는 검증 로직이 있어도 멀티 쓰레드 상황을 고려해 변경 컬럼에 유니크 제약 조건 추가하는 것이 안전 엔티티 설계 시 주의점 모든 연관관계는 지연로딩(Lazy)으로 설정 즉시로딩(Eager)은 예측이 어렵고 N + 1 문제가 자주 발생 연관 관계 엔티티 로딩 시 fetch join 혹은 엔티티 그래프 기능 사용 @XToOne 관계는 기본이 즉시로딩이므로 직접 지연로딩 설정을 해야 함 컬렉션은 필드에서 초기화 null 문제에서 안전 Hibernate은 엔티티 영속화 시 컬렉션을 감싸서 Hibernate이 제공하는 내장 컬렉션으로 변경 (PersistentBag) - 필드 초기화가 내부 매커니즘을 안전하게 지켜줌 테이블, 컬럼명 생성 전략 기본 전략 하이버네이트 기존 구현 엔티티의 필드명을 그대로 테이블 컬럼명으로 사용 SpringPhysicalNamingStrategy 스프링 부트 신규 설정 Camel case -> Snake case . -> _ 추가 전략 명시적으로 컬럼, 테이블명을 적으면 실제 테이블에 물리명 적용 (physical-strategy) 적지 않은 경우 논리명 적용 (implicit-strategy) 애노테이션 Tips @PersistenceContext 엔티티 매니저(EntityManger) 주입 Lombok 생성자 주입 사용시 애노테이션 생략 가능 @Transactional readOnly=true 플러시를 하지 않으므로 약간의 성능 향상 디폴트는 readOnly=false이므로, 큰 스코프에서 readOnly=true를 설정하고 커맨드성 작업에 @Transactional을 붙이는 방식으로 사용하면 편리 테스트에 붙으면, 테스트 종료 후 자동으로 트랜잭션 롤백 테스트를 환경을 위한 설정 파일 테스트 케이스에는 메모리 DB 사용이 효율적 데이터 소스나 JPA 관련 별도 추가 설정을 하지 않아도 됨 스프링 부트는 datasource 설정이 없으면 기본적으로 메모리 DB 사용 스프링 부트는 jpa 설정이 없으면 ddl-auto: create-drop 모드로 동작 설정 파일 읽기 전략 테스트에서 스프링을 실행하면, test/resources/application.yml을 읽음 해당 위치에 없을 경우, src/resources/application.yml 읽음 도메인 모델 패턴 VS 트랜잭션 스크립트 패턴 도메인 모델 패턴 엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 패턴 (서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할) 트랜잭션 스크립트 패턴 엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 패턴 변경 감지(Dirty Checking) & 병합(merge) 준영속 엔티티 영속성 컨텍스트가 더이상 관리하지 않는 엔티티 이전에 DB에 한 번 저장되어서 식별자가 존재하나 JPA가 현재 추적하고 있지 않는 객체 준영속 엔티티를 수정하는 2가지 방법 변경 감지(Dirty Checking) - Recommendation 동작 식별자로 엔티티를 조회(find)한 후 데이터 수정 컨텍스트가 종료되면서 트랜잭션 커밋 시점에 변경 감지가 동작하고, 데이터베이스에 UPDATE SQL 실행 병합(merge) 동작 준영속 엔티티의 식별자 값으로 영속 엔티티를 조회 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체 (병합) 트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 데이터 베이스에 UPDATE SQL 실행 병합은 모든 필드를 변경해버리고 데이터가 없으면 null로 업데이트하므로 위험 Best Practice: 엔티티 변경시 항상 변경 감지 사용하기 컨트롤러에서 엔티티 생성하지 말기 서비스 계층에 식별자(id)와 변경할 데이터를 명확히 전달 (파라미터 or DTO) 서비스 계층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경 트랜잭션 커밋 시점에 변경 감지 자동 실행

Java-Ecosystem · 2024-03-26

스프링 부트 프로젝트 세팅

스프링 프로젝트 세팅 방법 프로젝트 GENERATE: https://start.spring.io Spring Boot Version은 SNAPSHOT, M2가 들어가지 않은 것이 정식 버전 Package name은 -가 안들어가도록 주의 ADD DEPENDENCIES: Spring WEB, Thymeleaf, Lombok, Validation, JPA, H2… Settings Lombok Plugins - Lombok 설치 Annotation Processing - Enable annotation processing Gradle - Build and run using, Run tests using - IntelliJ IDEA 변경 Main 함수 실행 - White label page 확인 H2 Database 세팅 방법 설치 - H2 Database 데이터베이스 파일 생성 (첫 진입) jdbc:h2:~/jpashop 다음 파일 생성 확인: ~/jpashop.mv.db 이후부터 TCP 연결 jdbc:h2:tcp://localhost/~/jpashop JPA 및 DB 설정 main/resources/application.yml spring: datasource: url: jdbc:h2:tcp://localhost/~/jpashop username: sa password: driver-class-name: org.h2.Driver jpa: hibernate: ddl-auto: create properties: hibernate: # show_sql: true # System.out을 통해 SQL 남김 (지양) format_sql: true logging.level: org.hibernate.SQL: debug org.hibernate.orm.jdbc.bind: trace ddl-auto create: 애플리케이션 실행 시점에 테이블을 drop하고 다시 생성 none: 테이블을 생성하지 않음 format_sql SQL이 포멧팅되어 조금 더 보기 좋게 나오게 함 org.hibernate.SQL (권장, 로그로 남기는게 좋음) logger를 통해 SQL 남김 org.hibernate.orm.jdbc.bind: trace SQL 실행 파라미터(쿼리 파라미터)를 로그로 남김 외부 라이브러리 (가독성 높은 쿼리 파라미터 로그) implementation 'com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.9.0' 커넥션 정보, 가독성 높은 쿼리 파라미터 등 상세 정보 제공 시스템 자원을 잡아 먹으므로 운영 시스템에 적용하려면 반드시 성능 테스트 필요 (개발 단계 자유 사용) QueryDSL 설정 방법 (스프링 부트 3.0 이상) JDK 17 이상, 빌드 옵션으로는 Gradle 선택하기 (IntelliJ X) Preferences - Annotation Processors - Enable annotation processing 체크 build.gradle에 아래 설정 추가 //Querydsl 추가 implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta' annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta" annotationProcessor "jakarta.annotation:jakarta.annotation-api" annotationProcessor "jakarta.persistence:jakarta.persistence-api" 예제 엔터티(@Entity) 만들기 (Hello.class) Gradle - Tasks - build: build 작업 진행 생성된 build 폴더를 삭제하고 다시 하고 싶을 때는 clean 작업 진행 build - generated - sources - annotationProcessor - … - Q파일 생성 확인 (디렉토리) Test 설정 파일 spring: logging.level: org.hibernate.SQL: debug 경로: test/resources/application.yml 유용한 명령어 의존관계 확인 (Tree view) 프로젝트 디렉토리 - ./gradlew dependencies -configuration compileClasspath 서버 재시작 없이 View 파일 변경하기 spring-boot-devtools 라이브러리 추가 html 파일만 컴파일 (build - Recompile) 초기 데이터 생성 @Slf4j @RequiredArgsConstructor public class TestDataInit { private final ItemRepository itemRepository; /** * 확인용 초기 데이터 추가 */ @EventListener(ApplicationReadyEvent.class) public void initData() { log.info("test data init"); itemRepository.save(new Item("itemA", 10000, 10)); itemRepository.save(new Item("itemB", 20000, 20)); } } @EventListener(ApplicationReadyEvent.class) 스프링 컨테이너가 완전히 초기화를 끝내고, 실행 준비가 되었을 때 발생하는 이벤트 스프링 컨테이너가 AOP를 포함해 완전히 초기화된 시점 @PostConstruct의 경우, AOP 같은 부분이 다 처리되지 않은 시점에 호출될 수 있음 예를 들어, @Transactional 관련 AOP가 적용되지 않고 호출될 수 있어 문제 스프링은 이 시점에, initData()를 호출 프로필 (Profile) 프로필은 로컬, 운영 환경, 테스트 실행 등 다양한 환경에 따라 다른 설정을 할 때 사용하는 정보 로컬에서는 로컬 DB, 운영 환경에서는 운영 DB에 접근 환경에 따라 다른 스프링 빈 등록 스프링은 로딩 시점에 spring.profiles.active 사용 (spring.profiles.active=local) main 프로필: src/main/resources 하위 application.properties test 프로필: src/test/resources 하위 **`application.properties 프로필을 지정하지 않으면 "default" 프로필로 동작 설정파일(Config) 및 프로필 적용하기 @Import(MemoryConfig.class) @SpringBootApplication(scanBasePackages = "hello.itemservice.web") public class ItemServiceApplication { public static void main(String[] args) { SpringApplication.run(ItemServiceApplication.class, args); } @Bean @Profile("local") public TestDataInit testDataInit(ItemRepository itemRepository) { return new TestDataInit(itemRepository); } } @Import(MemoryConfig.class) 원하는 설정파일 적용 @Profile("local") 특정 프로필의 경우에만 해당 스프링 빈 등록 주요한application.properties 설정 트랜잭션 프록시가 호출하는 트랜잭션의 시작 및 종료 로그 확인 가능 logging.level.org.springframework.transaction.interceptor=TRACE logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=DEBUG JPA 커밋 롤백 로그 확인 logging.level.org.springframework.orm.jpa.JpaTransactionManager=DEBUG logging.level.org.hibernate.resource.transaction=DEBUG JPA SQL 로그 확인 logging.level.org.hibernate.SQL=DEBUG logging.level.org.hibernate.orm.jdbc.bind=TRACE HTTP 요청 메시지 확인하기 logging.level.org.apache.coyote.http11=trace

Java-Ecosystem · 2024-03-15

스프링 핵심원리 - 기본편

Java-Ecosystem · 2024-03-11

HTTP URI 및 Status Code 설계 방법

HTTP 통신 유스 케이스 데이터 전송 방식 분류 쿼리 파라미터 전송 (검색어를 포함한 정렬 필터) GET 메시지 바디 전송 POST, PUT, PATCH 유스케이스 정적 데이터 조회 이미지, 정적 텍스트 문서 리소스 경로로 단순 조회 동적 데이터 조회 검색어 포함 필터 및 정렬 적용 쿼리 파라미터 조회 HTML Form을 통한 데이터 전송 GET, POST만 지원 GET 전송 form 내용을 쿼리 파라미터 형식으로 전달 POST 전송 Content-Type: application/x-www-form-urlencoded (default) form 내용을 메시지 바디 통해서 전송 (key=value 형태) 전송 데이터를 url encoding 처리 한글 같은 것이 들어오면 자동으로 인코딩 됨 abc김 -> abc%EA%B9%80 Content-Type: multipart/form-data form 내용 및 다른 종류의 여러 파일을 메시지 바디 통해서 전송 (boundary로 타입마다 나눔) 파일 업로드 같은 바이너리 데이터 전송시 사용 API를 통한 데이터 전송 AJAX, Axios 등을 통한 자바스크립트 통신 Content-Type: application/json (JSON 데이터로 소통) 서버 to 서버, 웹 혹은 앱 클라이언트 URI 설계 단위 문서(Document) 단일 개념 (파일 하나, 객체 인스턴스, 데이터베이스 row) members/1, /files/star.jpg 컬렉션(Collection) 서버가 관리하는 리소스 디렉토리 POST 기반 등록 서버가 리소스 URI를 결정 /members 스토어(Store) 클라이언트가 관리하는 리소스 디렉토리 PUT 기반 등록 (없으면 생성, 있으면 수정) 클라이언트가 리소스 URI를 결정 파일 시스템, 게시판 등에 적용 /files 컨트롤러(Controller), 컨트롤 URI 일반적인 HTTP 메서드만으로 해결하기 애매한 경우 사용 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행 동사로 된 리소스 경로 사용 /members/{id}/delete HTTP API 설계 예시 HTTP API - 컬렉션 회원 관리 시스템 예시 회원 목록: GET /members 회원 등록: POST /members 회원 조회: GET /members/{id} 회원 수정: PATCH, PUT, POST /members/{id} 실무에서는 엔터티의 속성이 매우 많으므로 PATCH를 쓰는게 제일 좋음 PUT은 하나라도 누락되면 데이터가 날아가버릴 위험 (게시판 게시글 수정 정도 OK) 둘 다 애매한 경우는 POST 사용 회원 삭제: DELETE /members/{id} HTTP API - 스토어 파일 관리 시스템 예시 파일 목록: GET /files 파일 조회: GET /files/{filename} 파일 등록: PUT /files/{filename} 파일 삭제: DELETE /files/{filename} 파일 대량 등록: POST /files HTML Form 순수 HTML, HTML Form만을 사용해야 할 때의 시나리오 GET, POST만 지원 메서드 제약을 컨트롤 URI로 해결 회원 관리 시스템 예시 회원 목록: GET /members 회원 등록 폼: GET /members/new 회원 등록: POST /members/new (혹은 /members) 회원 조회: GET /members/{id} 회원 수정 폼: GET /members/{id}/edit 회원 수정: POST /members/{id}/edit (혹은 /members/{id}) 회원 삭제: POST /members/{id}/delete List 형식의 쿼리 파라미터 쿼리 파라미터에서 같은 키 값에 대해 복수의 value를 보낼 수도 있음 id=1&id=2&id=3&id=4 HTTP 상태코드 클라이언트는 상위 상태코드로 해석해 처리하므로 미래에 새 상태코드가 추가되어도 클라이언트는 변경 X 2xx (Successful) 200 OK 201 Created 요청 성공해서 새로운 리소스가 생성됨 응답의 Location 헤더 필드로 생성된 리소스 식별 (Location: /members/1) 혹은 응답 메시지 바디에 id를 리턴해 생성된 리소스 식별 202 Accepted 요청이 접수되었으나 처리가 완료되지 않았음 배치 처리 (요청 접수 1시간 후 배치 프로세스 시작) 204 No Content 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 웹 문서 편집기 save 버튼 3xx (Redirection) 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요 웹브라우저는 3xx 응답 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 영구 리다이렉션 (거의 사용 X) 리소스 URI가 영구적으로 이동 원래의 URL을 사용하지 않고 검색엔진에서도 변경을 인지 301 Moved Permanently 리다이렉트시 요청 메서드가 GET으로 변하고, 본문(메시지 바디)이 제거될 수 있음 308 Permanent Redirect 301과 같은 기능 리다이렉트시 요청 메서드와 본문 유지 (POST로 보내면 리다이렉트도 POST) 일시 리다이렉션 리소스 URI가 일시적으로 변경 검색엔진에서 기존 URI 유지 처음 302의 의도는 메서드 유지였으나 애매한 스펙 기재로 웹브라우저들이 GET으로 변경하도록 구현되었고 결국 명확한 스펙의 307, 303이 등장 함 (301 대응의 308도 마찬가지) 302 Found (현실적으로 이미 많은 라이브러리가 디폴트로 사용하므로 302만 써도 무방) 리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 307 Temporary Redirect 302와 같은 기능 리다이렉트시 요청 메서드와 본문 유지 (POST로 보내면 리다이렉트도 POST) 303 See Other 302와 같은 기능 리다이렉트시 요청 메서드가 GET으로 변경 PRG (Post/Redirect/Get) (자주 사용) POST 주문 후 새로고침하면 재요청으로 인해 중복 주문이 될 수 있음 따라서, POST 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트 특수 리다이렉션 304 Not Modified 클라이언트에게 서버 리소스가 수정되지 않았음을 알려줌 클라이언트는 로컬 캐시로 리다이렉트 (캐시 재사용) 응답 메시지 바디 X 조건부 GET, HEAD 요청시 사용 4xx (Client Error) - 오류의 원인이 클라이언트에 있으므로, 재시도가 항상 실패 400 Bad Request 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 (백엔드는 철저히 validation해야 함) 401 Unauthorized 클라이언트가 해당 리소스에 대한 인증이 필요함 (인증 실패) 응답에 WWW-Authenticate 헤더와 함께 인증 방법 설명 403 Forbidden 서버가 요청을 이해했지만 승인을 거부함 (인가 실패, 접근 권한 불충분) 로그인한 어드민 등급이 아닌 사용자가, 어드민 등급 리소스에 접근하는 경우 404 Not Found 요청 리소스가 서버에 없음 혹은 권한이 부족한 클라이언트에게 해당 리소스를 완전히 숨기고 싶을 때 (403도 안내고 완전히 숨기고 싶을 때) 5xx (Server Error) - 오류의 원인 서버에 있으므로, 재시도가 성공할 수도 있음 500 Internal Server Error 서버 내부 문제로 오류 발생 애매하면 500 503 Service Unavailable 서비스 이용 불가 서버가 일시적인 과부하 혹은 예정된 작업으로 잠시 요청을 처리할 수 없음 Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수 있음 서버는 왠만하면 500대 에러를 내서는 안됨. 항상 200대 혹은 400대 에러로 해결할 것 Reference 모든 개발자를 위한 HTTP 웹 기본 지식

Computer Science · 2024-02-28

HTTP 헤더 종류

HTTP header HTTP 전송에 필요한 모든 부가정보 History RFC2616 (폐기) Header를 General header, Request header, Response header, Entity header로 분류 Entity body(실제 데이터)는 Message body에 담음 Entity header는 Entity body 해석을 위한 정보 제공 (Content-Type, Content-Length) RFC723x Entity => Representation(표현) 회원이라는 리소스를 특정 데이터 형식(HTML, JSON, XML)으로 표현해 전달하겠다는 의미 Representation = Representation Metadata + Representation Data Representation Data는 Payload(=Message body)에 담음 일반 HTTP 헤더 표현 헤더 Content-Type 미디어 타입, 문자 인코딩 text/html; charset=utf-8, application/json (디폴트 인코딩: utf-8), image/png Content-Encoding 표현 데이터의 압축 정보 (전달자가 헤더 추가) gzip, deflate, identity(=압축 X) Content-Language 자연 언어 ko, en, en-US Content-Length 바이트 단위 Transfer-Encoding 사용 시에는 필요 없음 협상 헤더 (Content Negotiation) 클라이언트가 선호하는 표현을 서버에 요청하고 서버는 최대한 클라이언트 선호에 맞춰 응답 요청시에만 사용하는 헤더 종류 Accept (미디어 타입) Accept-Charset (문자 인코딩) Accept-Encoding (압축 정보) Accept-Language (자연 언어) 협상 우선순위 Quality Values(q) 0~1: 클수록 높은 우선순위 생략 시 1 Accpet-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7 구체적인 것이 우선 Accept: text/*, text/plain, text/plain;format=flowed, */* text/plain;format=flowed > text/plain > text/* > */* 전송방식 관련 헤더 단순 전송 Content-Length 헤더와 함께 한번에 데이터 전송 압축 전송 Content-Length + Content-Encoding 헤더와 함께 압축된 데이터를 전송 분할 전송 Transfer-Encoding: chunked 헤더와 함께 데이터를 일정한 단위로 쪼개어 보냄 Content-Length 헤더는 보내면 안됨 큰 용량의 데이터를 한 번에 보내느라 기다리는 상황이 생기지 않도록, 분할된 데이터가 오는대로 바로바로 보여주는 방식 서버에서 5byte가 만들어지면 클라이언트에 먼저 보내고, 또 만들어지면 또 보내서 마지막에 0바이트 \r\n을 보내고 끝을 표현 범위 전송 Range(요청 헤더), Content-Range(응답 헤더)와 함께 범위를 지정해 데이터를 전송 데이터를 절반정도 받다가 연결이 끊겼을 때, 못받은 범위만큼만 재요청하면 효율적 일반 정보 헤더 요청 헤더 From 유저 에이전트의 이메일 정보 거의 사용되지 않지만 검색 엔진 같은 곳에서 주로 사용 (크롤링 그만해달라는 요청을 할 수 있는 연락 수단) Referer 이전 웹 페이지 주소 유입 경로 분석에 사용 User-Agent 클라이언트의 애플리케이션 정보 (웹브라우저 정보) user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36 통계 정보 혹은 특정 브라우저의 장애에 대한 파악에 이용 응답 헤더 Server ORIGIN 서버의 소프트웨어 정보 ORIGIN 서버: 여러 프록시 서버, 캐시 서버를 제외하고 정말로 요청을 처리해 응답하는 서버 Server: Apache/2.2.22 (Debian) server: nginx Date 메시지가 발생한 날짜와 시간 최신 스펙에서 응답에만 사용하도록 명시 특별 정보 헤더 요청 헤더 Host (필수) 요청한 호스트 정보 (도메인) 클라이언트가 DNS를 거쳐 얻은 IP로 가상호스팅 중인 서버에 패킷을 보냈을 때, 어떤 도메인으로 전달해야 할지 판단하는 것에 구분점이 됨 가상호스팅: 하나의 IP 주소에 여러 도메인이 적용되어 있는 상황 (도메인이 다른 여러 애플리케이션 구동) 응답 헤더 Location 페이지 리다이렉션 201: 요청에 의해 생성된 리소스 URI 3xx: 요청을 자동으로 리다이렉션할 리소스 URI Allow 해당 Path에서 허용 가능한 HTTP 메서드를 확인해 서버에서 보냄 405 (Method Not Allowed)에는 반드시 포함 실제로 구현되어 있는 곳은 별로 없음 Retry-After 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간 503 (Service Unavailable) 응답 시 서비스가 언제까지 불능인지 알려줌 날짜표기 혹은 초단위 표기 인증 헤더 Authorization (요청 헤더) 클라이언트 인증 정보를 서버에 전달 Authorization: Basic xxxxxxxxx Authorization: Bearer xxxxxxxxx WWW-Authenticate (응답 헤더) 리소스 접근시 필요한 인증 방법 정의 정의해준 방법으로 다시 제대로 인증 정보를 생성해서 인증하라는 의미 401 (Unauthorized)와 함께 사용 WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple" 쿠키 헤더 특징 HTTP는 Stateless 프로토콜이므로 상태가 요구되는 상황에서는 쿠키로 저장 사용자 로그인 세션 관리 광고 정보 트래킹 GDPR(General Data Protection Regulation, EU 개인정보보호 법령)로 인해 EU 회원국의 웹사이트들은 유저들로부터 쿠키 수집 동의를 받아야 함 (필수쿠키, 기능쿠키, 성능쿠키, 마케팅쿠키 등에 대해 각각 선택도 가능) 쿠키는 항상 서버에 전송되므로 네트워크 트래픽이 유발되기 때문에, 최소한의 정보만 사용해야 함 (세션 id, 인증 토큰) 보안에 민감한 데이터는 저장하면 안됨 (주민번호, 신용카드 번호) 생명주기 세션 쿠키: 만료 날짜가 생략된 쿠키는 브라우저 종료시까지만 유지 영속 쿠키: 만료 날짜가 입력된 쿠키는 해당 날짜까지 유지 Cookie (요청 헤더) 서버에서 받은 쿠키를 클라이언트가 HTTP 요청시 전달 Set-Cookie (응답 헤더) 서버에서 클라이언트로 쿠키 전달 Field Value expires 만료일이 되면 쿠키 삭제 max-age 0이나 음수를 지정하면 쿠키 삭제 domain 쿠키를 전송받는 서버 도메인의 범위 제한 예시) domain=example.com 명시 기준 도메인 + 서브 도메인 적용 example.com&dev.example.com까지 쿠키 접근 가능(=쿠키 전송) 생략 기준 도메인만 적용 example.com만 쿠키 접근 가능 path 해당 경로를 포함해 하위 경로 페이지까지만 쿠키 접근 가능 일반적으로 path=/ 루트로 지정 Secure https인 경우에만 쿠키 전송 HttpOnly 자바스크립트로 쿠키 접근 불가, http 전송에만 사용 가능 XSS 공격 방지 SameSite 쿠키를 전송하는 요청 도메인(=현재 접속해 있는 페이지)의 범위 제한 요청 도메인이 쿠키에 설정된 도메인과 같은 경우에만 쿠키 전송 XSRF 공격 방지 속성 Strict: 같은 도메인에서만 접근 가능 퍼스트 파티 쿠키 only Lax: <a>, <link>, <form method="GET">통한 이동은 다른 도메인이어도 cookie 전송 Chrome 80 default 퍼스트 파티 쿠키 + 일부 서드 파티 쿠키 None: cross-site에서도 쿠키 전송 가능 (단, Secure 옵션 추가필수) 퍼스트 파티 쿠키 + 모든 서드 파티 쿠키 캐시와 조건부 요청 HTTP 헤더 (캐시 제어 헤더) + (검증 헤더 & 조건부 요청 헤더 한 쌍) 캐시 조합 권장 cache-control: max-age=... + Last-Modified cache-control: max-age=... + ETag (Recommendation) 캐시 기본 동작 첫 번째 요청시응답에서 특정 캐시 헤더 및 바디 데이터를 브라우저 캐시에 저장 cache-control: max-age=60 Last-Modified: 2023-04-23... ETag: "aaaaaaaaa" 두 번째 요청시 캐시 유효시간(max-age 값) 검증 유효: 캐시에서 조회 유효 X 서버로 요청 조건부 요청 헤더 추가 검증 헤더에 따라 If-Modified-Since 혹은 If-None-Match 서버 검증 기존 데이터 변경 X 304 Not Modified (HTTP Body X) 응답 캐시에서 조회 (재사용) 브라우저 캐시갱신 (응답 캐시 헤더) 기존 데이터 변경 200 OK, 변경된 데이터 응답 브라우저 캐시 갱신 (응답 캐시 헤더 + 바디) 헤더 종류 캐시 제어 헤더 Cache-Control (캐시 제어) max-age 캐시 유효 시간, 초 단위 no-cache 데이터를 캐시해도 되지만, 항상 원 서버(Origin Server)에 검증하고 사용 no-store 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제) Pragma (캐시 제어, HTTP 1.0 하위호환) no-cache (위와 동일) Expires (Cache-Control: max-age 하위호환, 함께 사용시 Expires는 무시됨) 캐시 만료일을 정확한 날짜로 지정 검증 헤더 (Validator) 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터 Last-Modified 데이터가 마지막으로 수정된 시간 1초 미만 단위의 캐시 조정이 불가능 ETag (Entity Tag) 캐시용 데이터에 임의의 고유한 버전 이름(Hash)을 붙이고 데이터 변경시 Hash 재생성 ETag가 같으면 캐시유지, 다르면 변경된 데이터 전송 서버에서 별도 캐시 로직을 관리하고 싶은 경우 사용 데이터 수정 날짜가 다르지만 A -> B -> A로 수정해 데이터 결과가 똑같은 경우 스페이스나 주석 같이 크게 영향 없는 변경 무시 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신 조건부 요청 헤더 검증 헤더를 통해 브라우저 캐시에 저장된 값으로 조건에 따른 분기 요청 If-Modified-Since: Last-modified 값 사용 If-Unmodified-Since: Last-modified 값 사용 If-None-Match: ETag 값 사용 If-Match: ETag 값 사용 장점 비싼 네트워크 사용량을 줄일 수 있음 (캐시 유효시간동안 네트워크 이용은 용량이 적은 헤더 전달뿐) 브라우저 로딩 속도가 매우 빨라져서 사용자 경험이 좋아짐 프록시 캐시 원 서버가 멀리 있는 경우 중간에 프록시 캐시 서버(CDN 서비스)를 두어 속도적 이점을 얻음 클라이언트(한국) - (0.5초) - 원 서버(미국) 클라이언트(한국) - (0.1초) - 프록시 캐시 서버(한국 어딘가) - (0.4초) - 원 서버(미국) 보편적 캐시 방법 첫 번째 접근이 오래걸리고 두 번째 이후부터는 다운이 이미 받아져 빨라짐 유튜브의 인기 있는 영상은 로딩이 빠르고 인기 없는 영상은 로딩이 느림 원 서버에서 캐시 서버로 데이터를 밀어 넣는 경우도 있음 관련 캐시 응답 헤더 Cache-Control: public 응답이 public 캐시에 저장되어도 됨 (=중간 프록시 캐시 서버에 저장되어도 됨) Cache-Control: private 응답이 private 캐시에 저장되어야 함 (기본값) Cache-Control: s-maxage 프록시 캐시에 적용되는 max-age Cache-Control: must-revalidate 캐시 만료 후 최초 조회시 원 서버에 검증해야 함 원 서버 접근 실패시 반드시 오류가 발생해야 함 (504 Gateway Timeout) 캐시 시간이 유효하다면 캐시 사용 Age: 60 원 서버에서 응답 후 프록시 캐시 내에 머문 시간(초) 확실한 캐시 무효화 응답 Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache 기본적으로 웹브라우저 임의로 캐시를 할 수 있기 때문에 완전한 캐시 무효를 위해 사용 네트워크 단절 등으로 인한 원 서버 접근 불가 시 must-revalidate이 필요 no-cache의 경우 캐시 서버 설정에 따라 원 서버에 접근할 수 없는 경우, 캐시 데이터를 반환할 수 있음 (오류보다는 오래된 데이터라도 보여주기, 200 OK) must-revalidate은 원서버에 접근할 수 없는 경우, 항상 오류 발생시킴 (매우 중요한 돈과 관련된 결과들에 필수, 504 Gateway Timeout) 용어 원 서버 (Origin Server): 실제 요청을 처리하는 서버 public 캐시: 프록시 캐시 서버 private 캐시: 각각의 브라우저의 로컬 캐시 Reference 모든 개발자를 위한 HTTP 웹 기본 지식 마케터를 위한 웹사이트 쿠키 동의 환경의 이해 What are the security differences between cookies with Domain vs SameSite strict? SameSite란? None, Lax, Stricts

Computer Science · 2024-02-22

HTTP 기본 구조

기본 용어 IP (Internet Protocol) 패킷(Packet)을 단위로 특정 주소(IP Address)에 데이터를 전달할 수 있는 프로토콜 IP 패킷 (보내려는 메시지 + 출발지 IP, 도착지 IP…) 한계 비연결성 패킷을 받을 대상이 없거나 상대 서버가 불능 상태여도 전송 비신뢰성 중간에 패킷이 누락되거나 순서대로 오지 않는 경우 존재 프로그램 구분 같은 IP인데 통신하는 애플리케이션이 2개 이상인 경우 구분 불가 전송계층(Transport Layer) 네트워크 4계층에서 TCP 혹은 UDP 추가 정보로 IP 패킷을 보완하는 단계 TCP (Transmission Control Protocol) 앞선 IP의 문제점을 해결 (전송제어 정보를 패킷에 추가) TCP/IP 패킷 (IP 패킷 + 출발지 PORT, 목적지 PORT, 전송제어, 순서, 검증정보…) 특징 연결지향 (3 way handshake) SYN, SYN+ACK, ACK 3단계로 연결을 확인하고 그 후 데이터를 보냄 최근엔 최적화되어 세 번째 단계 ACK에서 데이터를 함께 보내는 것이 가능 데이터 전달 보증 서버는 데이터를 잘 받았다는 응답을 클라이언트에게 줌 순서 보장 기본적으로는 패킷 1, 3, 2 순서로 왔다면 2부터 다시 보낼 것을 클라이언트에 요청 서버 최적화에 따라 다시 보내달라는 요청 없이 내부적으로 처리하기도 할 것 UDP (User Datagram Protocol) IP와 비슷할 정도로 기능이 거의 없음 (하얀 도화지) PORT, 체크섬 정도만 추가 TCP의 연결지향, 데이터 전달 보증, 순서 보장 등이 없다. 덕분에 단순하고 빠름 TCP는 3 way handshake와 패킷의 추가정보들로 인해 데이터가 크고 속도가 느림 따라서, 속도 최적화는 UDP 이용 HTTP3 스펙에서도 UDP를 활용하며 최근 각광 PORT 같은 IP(내 서버) 내에 여러 프로세스가 통신 중일 때, 응답 패킷이 어느 애플리케이션의 패킷인지 구분 IP가 아파트면 PORT는 동호수를 표현 0~65535 할당 가능 0~1023은 잘 알려진 포트로 사용하지 않는 것이 좋음 HTTP - 80 HTTPS - 443 DNS (Domain Name System) 전화번호부 같은 서버를 제공하여 도메인명을 IP 주소로 변환하는 역할 수행 IP는 기억하기 어렵고 가변적이어서 DNS가 이를 해결 URI (Uniform Resource Identifier) 자원을 식별하는 방법을 총칭 URL(Uniform Resource Locator) + URN(Uniform Resource Name) URL: https://www.inflearn.com/course/lecture URN: urn:isbn:01270712 URN은 보편화 되지 않아서 URI = URL로 생각해도 무방하다. URL 문법 Syntax: scheme://[userinfo@]host[:port][/path][?query][#fragment] 예시: https://www.google.com:443/search?q=hello&hl=ko scheme 주로 프로토콜 사용 (어떤 방식으로 자원에 접근할 것인가에 대한 약속) http, https, ftp port http 80 포트, https 443 포트 등 보편적인 경우 생략 가능 userinfo URL에 사용자 정보를 포함해서 인증하는 경우 사용하지만 거의 쓰이지 않음 host 도메인명 또는 IP 주소를 직접 사용 가능 path 계층적 구조의 리소스 경로 query key-value 형태 ?로 시작, &로 추가 서버로 요청시 모두 문자로 넘어감 = query parameter = query string fragment html 내부 북마크에 사용 서버 전송 정보가 아님 브라우저 요청 흐름 클라이언트 애플리케이션 계층 웹 브라우저에 요청: https://www.google.com:443/search?q=hello&hl=ko 웹 브라우저가 DNS 조회 및 PORT 정보 파악 웹 브라우저가 HTTP 요청 메시지 생성 SOCKET 라이브러리 파악한 IP 및 PORT 정보로 구글 서버와 3 way handshake로 연결 맺기 OS로 데이터 전달 OS 계층 (TCP/UDP & IP 계층) TCP/IP 패킷 생성 (HTTP 메시지 포함) 네트워크 인터페이스 패킷에 이더넷 프레임을 씌워 인터넷망으로 던짐 인터넷 망 수많은 인터넷 노드를 거쳐 목적지 구글 서버에 패킷 전달 구글 서버 구글 서버는 반대 과정으로 tcp/ip 패킷을 까서 http 메시지를 해석 구글 서버는 요청에 맞는 http 응답 메시지를 생성하고 TCP/IP 패킷을 씌워 클라이언트에 다시 보냄 인터넷 망 수많은 인터넷 노드를 거쳐 클라이언트 웹브라우저에 응답 패킷 전달 클라이언트 클라이언트는 응답 패킷을 까서 http 메시지를 해석 메시지 내 데이터를 웹 브라우저가 렌더링하여 화면에 출력 HTTP (HyperText Transfer Protocol) 모든 형태의 데이터를 HTTP 메시지로 전송 가능 처음엔 HTML 같은 HyperText 문서 전송 용도로 시작 HTTP/1.1 (1997) 가장 많이 사용되는 중요한 버전 주요 기능이 이미 모두 포함됨 RFC7230~7235(2014)이 최신 개정판 HTTP/2, HTTP/3은 성능 개선에 초점 TCP 이용 HTTP/1.1, HTTP/2 UDP 이용 HTTP/3 특징 클라이언트-서버 구조 클라이언트(UI, 사용성) & 서버(비즈니스 로직, 데이터) 분리로 각각이 독립적 진화 가능 무상태 프로토콜(Stateless) 서버가 클라이언트의 상태를 보존하지 않음 서버 Scale Out(수평 확장)에 유리 무상태는 응답 서버를 쉽게 바꿀 수 있으므로 무한한 서버 증설 가능 갑자기 클라이언트 요청(고객)이 증가해도 서버(점원)를 대거 투입할 수 있음 한계 무상태로 설계할 수 없는 경우도 있음 쿠키 세션 로그인 요청 데이터가 많음 최대한 무상태로 설계하고 어쩔 수 없는 경우에만 상태 유지 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 감당을 위한 필수 설계 선착순 1000명 이벤트는 수만명 동시 요청 발생 첫 페이지에 로그인도 필요 없는 정적 페이지 하나를 두면 조금 분산이 됨 비연결성(Connectionless) 요청 및 응답할 때만 연결하고 바로 끊음 서버의 자원을 매우 효율적으로 사용할 수 있음 HTTP는 초 단위 이하의 빠른 속도로 응답 1시간 동안 수천명이 서비스를 이용해도 서버에서 실제 동시에 처리하는 요청은 수십개 이하로 작음 (1초에 몇 명 되지도 않을 것) HTTP 지속 연결(Persistent Connections) 기본으로 사용해 연결 시간을 어느정도 최적화 TCP/IP 연결(3 way handshake) 시간이 사용자에게 매번 추가되는 상황이 비효율적 js파일, html 파일, css 파일을 각각 다운 받을 때마다 연결을 맺음 (0.9초) HTTP 지속 연결로 해결 HTML 페이지 하나가 전부 다운 받아질 때까지 TCP 연결을 유지하고 해제함 (0.5초) HTTP 메시지 구조 구조 시작 라인(start-line) 요청과 응답 기본 형태는 start-line만 다름 request-line (요청 메시지 경우) (HTTP 메서드) (SP=공백) (request-target=absolute path) (SP) (HTTP version) (CRLF=엔터) ex) GET /search?q=hello&hl=ko HTTP/1.1 status-line (응답 메시지 경우) (HTTP version) (SP) (status-code) (SP) (reason-phrase) (CRLF) ex) HTTP/1.1 200 OK 헤더(header) HTTP 전송에 필요한 모든 메타 정보 담김 수많은 표준 헤더가 존재 & 임의의 헤더 추가 가능 구조 (header-field) (field-name) (:) (OWS=띄어쓰기 허용) (field-value) (OWS) field-name은 대소문자 구분 X, field-value는 대소문자 구분 O request example Host: www.google.com response example Content-Type: text/html;charset=UTF-8 Content-Length: 3432 공백 라인(empty line) - Required 메시지 바디(message body) - Optional 실제 전송할 데이터 담김 byte로 표현할 수 있는 모든 데이터 가능 HTML, 이미지, 영상, JSON etc… HTTP 메서드 API URI 설계 표준 리소스 식별 (명사) 리소스: 회원 계층 구조 상 상위 => 컬렉션 => 복수 명사(/members) 계층 구조 상 하위 => 도큐먼트 => 식별자 구분 (/members/{id}) 행위는 HTTP 메서드로 분리 (동사) 행위: 조회, 등록, 삭제, 변경 주요 HTTP 메서드 종류 GET 리소스 조회 쿼리 파라미터로 데이터 전달 최신 스펙에서 메시지 바디로 데이터 전달이 가능하지만, 지원하지 않는 곳이 있어 권장 X POST 요청 데이터 처리 리소스마다 요청 데이터를 어떻게 처리할지 따로 정해야 함 신규 리소스 등록 회원가입, 게시판 글쓰기… 프로세스 처리 단순한 데이터 생성 및 변경을 넘어서 엮여있는 프로세스들을 처리해야 하는 경우 POST의 결과로 새 리소스가 생성되지 않을 수 있음 주문에서 결제완료 -> 배달시작 -> 배달완료 같은 큰 작업들이 엮인 상태변경 POST /orders/{orderId}/start-delivery (보통 POST에서 컨트롤 URI 사용) 다른 메서드로 처리하기 애매한 경우 JSON으로 조회 데이터 넘겨야 하는데, GET 메서드 사용하기 어려운 경우 한 문서 끝에 내용 추가 즉, 서버에서 큰 변화가 일어나는 것은 POST 사용 PUT 리소스 대체 & 해당 리소스가 없을시 생성 (=덮어쓰기) 요청에서 데이터가 누락되면 그대로 삭제됨 (위험성 존재) 클라이언트가 리소스를 식별 (URI) PATCH 리소스 부분 변경 실무 엔터티들은 데이터가 많기 때문에 변경에 주로 PATCH를 사용 PATCH를 못받아들이는 서버가 있다면 POST를 부분 변경에 사용한다. DELETE 리소스 삭제 HTTP 메서드의 속성 안전(Safe Methods) 호출해도 리소스를 변경하지 않음 안전한 메서드: GET 멱등(Idempotent Methods) 여러 번 호출해도 결과가 똑같음 서버에 문제가 있을 때, 클라이언트가 같은 요청을 다시 해도 되는가의 판단 근거 멱등하지 않은 메서드: POST, PATCH 캐시가능(Cacheable Methods) 응답 결과 리소스를 캐시해서 사용 가능 큰 용량의 데이터를 로컬 PC 웹 브라우저 내부에 저장하고 있을 수 있는지 여부 캐시 가능 메서드: GET, POST, PATCH POST, PATCH는 메시지 바디까지 캐시 키로 고려해야 해서 구현이 어려움 실제로 GET 정도만 캐시로 사용 Reference 모든 개발자를 위한 HTTP 웹 기본 지식

Computer Science · 2024-02-20

스프링 시작하기

빌드 및 실행 방법 ./gradlew build cd build/libs java -jar hello-spring-0.0.1-SNAPSHOT.jar 빌드가 잘 안될 때는 ./gradlew clean build 후 다시 빌드 (빌드 폴더 삭제) 주요 라이브러리 의존관계 스프링 부트 라이브러리 spring-boot-starter-web spring-boot-starter-tomcat: 톰캣 (웹서버) spring-webmvc: 스프링 웹 MVC spring-boot-starter-thymeleaf: 타임리프 템플릿 엔진(View) spring-boot-starter(공통): 스프링 부트 + 스프링 코어 + 로깅 spring-boot spring-core spring-boot-starter-logging logback, slf4j 테스트 라이브러리 spring-boot-starter-test junit: 테스트 프레임워크 mockito: 목 라이브러리 assertj: 테스트 코드를 좀 더 편하게 작성하게 도와주는 라이브러리 spring-test: 스프링 통합 테스트 지원 웹 개발 유형 변화 정적 컨텐츠 서버가 HTML 파일을 브라우저에게 그대로 넘겨주는 방식 과거에는 뷰와 컨트롤러 분리 없이 뷰로 모든 것을 다 하는 모델 원 방식을 사용 static/index.html 해당 경로로 index.html을 생성해두면 Welcome page가 된다. 예시 요청: localhost:8080/hello-static.html 톰켓 서버가 스프링 컨테이너에 요청 전달 요청에 대한 컨트롤러가 없다면, resources/static/hello-static.html을 찾아 브라우저에 반환 MVC와 템플릿 엔진 컨트롤러에서 리턴 값으로 문자를 반환하면 뷰 리졸버(viewResolver)가 화면을 찾아 처리한다. 템플릿 엔진 viewName 매핑 resources/templates 하위에 있는 {viewName}.html 파일을 찾아 템플릿 엔진 처리 후 브라우저에 반환 예시 요청: localhost:8080/hello-mvc 톰켓 서버가 스프링 컨테이너에 요청 전달 요청에 대한 컨트롤러를 찾음 컨트롤러는 hello-template이라는 문자열을 반환 viewResolver는 viewName 매핑으로 resources/templates/hello-template.html을 찾음 viewResolver가 Thymeleaf 템플릿 엔진에게 처리를 넘김 템플릿 엔진이 렌더링해서 변환한 HTML을 브라우저에게 반환 API @ResponseBody를 붙인 컨트롤러는 viewResolver를 사용하지 않는다. 결과 값을 JSON 형태로 HTTP Body에 담아 반환한다. viewResolver 대신 HttpMessageConverter가 동작 HTTP Accept 헤더와 컨트롤러 반환 타입 정보를 조합해 HttpMessageConverter가 선택됨 StringHttpMessageConverter (기본 문자처리) MappingJackson2HttpMessageConverter (기본 객체처리) xmlHttpMessageConverter (accept header에 xml로 요청) 예시 요청: localhost:8080/hello-api 톰켓 서버가 스프링 컨테이너에 요청 전달 요청에 대한 컨트롤러를 찾음 @ResponseBody가 붙은 컨트롤러이므로 반환값이 HttpMessageConverter에 전달됨 HttpMessageConverter가 데이터를 직렬화 후 HTTP Body에 담아 반환 Spring Bean 스프링 빈은 각 객체들 간의 의존관계를 저장하여 사용하기 편리하게 지원한다. 의존관계 등록방법 자동 의존관계 설정 (Component Scan) 정형화된 컨트롤러, 서비스, 레포지토리 같은 코드에 컴포넌트 스캔을 사용한다. 컴포넌트 등록 @Component 애노테이션이 있으면 스프링 빈으로 자동 등록된다. 다음 어노테이션들은 @Component를 포함하고 있어 역시 자동 등록된다. @Controller @Service @Repository @Autowired 해당 어노테이션이 붙은 메소드에게 스프링이 자동으로 연관 객체를 DI(의존성 주입)한다. 생성자에 사용시 객체 생성시점에 의존성 주입한다. 생성자가 하나라면 @Autowired 생략 가능 수동 의존관계 설정 (SpringConfig.java) 정형화되지 않거나 상황에 따라 구현 클래스를 변경해야 한다면 직접 설정으로 등록한다. 레포지토리를 다양하게 변경해야 하는 상황이라면 관리 포인트가 하나가 되어 편리 등록 방법 @Service, @Repository, @Autowired 등 현 상황에 불필요한 어노테이션은 제거 현재 앱 디렉토리에 SpringConfig.java 클래스 생성 클래스에 @Configuration, 메서드에 @Bean 어노테이션을 설정 메서드마다 필요한 인스턴스를 반환 @Configuration public class SpringConfig { @Bean public MemberService memberService() { return new MemberService(memberRepository()); } @Bean public MemberRepository memberRepository() { return new MemoryMemberRepository(); } } 특징 스프링은 스프링 빈에 등록할 때, 객체를 싱글톤으로 등록한다. 즉, 같은 스프링 빈이면 모두 같은 인스턴스여서 메모리가 절약된다. (설정으로 변경은 가능) 예시 주문 컨트롤러에서 멤버 서비스, 멤버 레포지토리를 요청하면 똑같은 인스턴스를 넣어 줌 스프링 통합 테스트 테스트 클래스에 다음 어노테이션을 추가한다. @SpringBootTest 스프링 컨테이너와 테스트를 함께 실행한다. @Transactional 테스트 케이스에 해당 어노테이션을 추가하면, 테스트 시작 전에 트랜잭션을 시작하고 테스트 완료 후 항상 롤백한다. 덕분에 DB에 데이터가 남지 않아 각각의 테스트가 서로 영향을 주지 않는다. 스프링 DB 접근 기술 순수 JDBC 관련 코드들이 매우 장황하고 반복이 많다. JdbcTemplate SQL은 여전히 직접 작성하지만, JDBC의 반복 코드를 대부분 제거해준다. JPA ORM의 개념으로 넘어왔다. 데이터 중심 설계에서 객체 중심 설계 패러다임으로 전환할 수 있고 생산성을 크게 높인다. jdbc 관련 라이브러리가 포함되어 있다. 항상 @Transactional을 사용해서 데이터 변경을 트랜잭션 안에서 실행 시켜야 한다. 스프링 데이터 JPA 인터페이스만으로 개발 가능 메서드 이름만으로 조회 기능 제공 페이징 기능 자동 제공 단순 반복 코드가 크게 줄어드는 덕분에 개발자는 비즈니스 로직에 집중할 수 있다. Querydsl 복잡한 동적 쿼리 작업 AOP Aspect of Programming 관점 지향 프로그래밍 어떤 로직을 핵심 관심 사항, 공통 관심 사항으로 나누고 그 관점을 바탕으로 각각 모듈화 핵심 관심 사항 (core concern) 비즈니스 로직 공통 관심 사항 (cross-cutting concern) DB 연결, 로깅, 파일 입출력, API 계층별 응답 시간 측정 etc… @Aspect, @Around AOP in Spring 스프링은 프록시 방식의 AOP를 사용 스프링은 AOP가 있으면 서버가 올라올 때 컨테이너에서 스프링 빈에 등록하면서 가짜 스프링 빈을 앞에 세우고 그것이 끝나면 진짜 스프링 빈을 호출하도록 동작한다. (가짜 서비스 후 진짜 서비스 호출) 컨트롤러에서 서비스를 호출하면 서비스 코드는 스프링 빈을 통해 가짜 프록시 서비스를 의존성 주입 받고 해당 프록시 서비스가 끝나면 다시 실제 서비스 코드가 의존성 주입을 받아 실행된다. 이 방식은 스프링이 DI가 가능하기 떄문에 할 수 있는 기술 Reference 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술

Java-Ecosystem · 2024-02-08

EC2 서버 시작하기 - 기본

EC2 서버 시작 시작 전 우측 상단 리전(Region) 확인 - 반드시 서울 설정 즉, 물리적 하드웨어의 사용 위치를 서울로 설정 EC2 서버 생성하기 작업 순서 큰 카테고리의 인스턴스 - 인스턴스 우측 상단 인스턴스 시작 서버 이름 지정 Appication & OS images - Ubuntu Server 22.04 LTS (HVM), SSD Volume Type (64bit, 프리 티어 사용 가능 확인 / 버전은 언제나 변할 수 있음) 인스턴스 유형 - t2.micro (프리 티어 사용 가능 확인) 키 페어 연결 (없을 시 새 키페어 생성 - 이름, RSA, .pem 생성) 스토리지 구성 (알림 보고 한도 확인 가능하면 올려서 지정, 현재는 프리티어면 30GiB 지정 가능) 설정 완료되면 인스턴스 시작 탄력적 IP 설정하기 탄력적 IP(Elastic IP, 고정 IP) IP는 동적으로 계속 바뀌기에 외부에서 접속할 수 있도록 고정 IP를 부여하는 것 IP: 각각의 컴퓨터 마다 그 컴퓨터를 접속할 수 있는 주소 퍼블릭 IPv4 주소는 인스턴스가 중지되고 재시작될 때마다 새로 부여되어서 외부 접속은 고정 IP 필요 작업 순서 탄력적 IP 할당 큰 카테고리의 네트워크 및 보안 - 탄력적 IP 우측 상단 탄력적 IP 주소 할당 (다음페이지도 바로 할당) 탄력적 IP 주소 연결 할당 IP 주소를 체크 후 우측 상단 작업 - 탄력적 IP 주소 연결 원하는 인스턴스 선택 후 연결 인스턴스 중지와 종료 중지(stop)는 서버를 잠시 중단하는 개념으로 재시작이 가능하다. 반면에, 종료(terminate)는 서버 삭제의 개념이므로 복구가 불가능한 점을 유의하자. EC2 서버 접속하기 터미널에서 프라이빗 키(pem key) 있는 경로로 이동 프라이빗 키 권한 변경 chmod  400  awstest.pem 서버 접속 ssh -i {pem key} ubuntu@{public IPv4 address} ssh  -i  awstest.pem  ubuntu@13.209.45.243 첫 접속시 continue to connecting?이 나오면 yes 입력 접속 종료 exit

Infrastructure · 2024-02-07

자바 객체 지향 설계

클래스가 필요한 이유 String[] studentNames = {"학생1", "학생3", "학생4", "학생5"}; int[] studentAges = {15, 17, 10, 16}; int[] studentGrades = {90, 100, 80, 50}; 학생이라는 개념을 다룰 때, 배열과 반복문으로 데이터를 처리해야 하므로 데이터 변경 시 실수할 가능성이 높다. 따라서 사람이 관리하기 좋은 코드를 만들기 위해 학생이라는 개념을 하나의 클래스로 묶어야 한다. 클래스 특징 클래스를 통해 마음껏 사용자 정의 타입을 만들 수 있다. (설계도) 클래스에 정의한 변수들 = 멤버 변수(Member variable) = 필드(Field) 실제 메모리에 만들어진 실체를 객체 혹은 인스턴스라 한다. 클래스 타입 변수는 객체를 생성하면 해당 객체의 참조값을 담는다. System.out.println(student); // 출력값 // (패키지 + 클래스 정보 @ 16진수 참조값) class1.Student@7a81197d 클래스 & 인스턴스 & 객체 클래스 객체 생성을 위한 ‘틀’ 또는 ‘설계도’ 객체가 가져야 할 속성(변수)과 기능(메서드)를 정의한다. 인스턴스 클래스로부터 생성된 객체 인스턴스 = 객체 어떤 클래스에 속해 있는지 강조 (관계에 초점) 객체 클래스의 속성과 기능을 가진 실체 세상 모든 사물을 단순하게 추상화해보면 속성과 기능 2가지만 남는다. 변수의 값 초기화 멤버 변수: 자동 초기화 인스턴스 생성시 자동 초기화 (new로 만드는 객체들의 멤버 변수들은 모두 자동 초기화된다.) int = 0, boolean = fasle, 참조형 = null 직접 초기화 지정 가능 지역 변수: 수동 초기화 null 참조형 변수에서 아직 가리키는 대상이 없다면 null을 넣어둘 수 있다. Data data = null; 아무도 참조하지 않는 인스턴스 (feat. GC) 참조형 변수에 null을 할당하면 해당 참조 데이터가 메모리에 남아 있다가 GC(Garbage Collector)에 의해 제거된다. 메소드가 종료되어 지역변수가 사라질 때, 지역변수가 참조하고 있던 인스턴스 역시 메모리에 남아 있다가 GC에 의해 제거된다. NullPointerException null에 .을 찍을 때 발생하는 에러이므로 디버깅시 유의하자. this 인스턴스 자신의 참조값을 가리킨다. 생성자에서 지역변수 이름이 겹친다면 this를 통해 멤버변수에 접근할 수 있다. this는 생략이 가능하다. 과거에는 명시적으로 보이지 않아 멤버 변수 접근시 항상 this를 사용하는 코딩 스타일이 존재했다. 그러나 최근엔 IDE의 발달 덕분에 멤버변수와 지역변수 구분이 잘되기 때문에, 꼭 필요한 경우에만 사용하고 생략하는게 권장된다. 변수 탐색 변수를 찾을 때 가까운 지역변수(매개변수 포함)를 먼저 찾고 없으면 그 다음으로 멤버변수를 찾는다. 멤버변수도 없으면 오류가 발생한다. 생성자 규칙 생성자의 이름은 클래스 이름과 같아야 한다. 반환타입이 없으므로 비워둬야 한다. 나머지는 메서드와 동일 인스턴스 생성 후 즉시 호출된다. new 키워드 이후 ()는 생성자 호출을 의미한다. 생성자 덕분에 자동 초기화로 인한 더미 데이터 생성을 방지하여 초기화를 강제할 수 있다. 기본 생성자 public class MemberInit { // 기본 생성자 public MemberInit() { } } 매개 변수가 없는 생성자 따로 정의한 생성자가 없는 경우 자바 컴파일러가 매개변수와 코드가 없는 기본생성자를 자동으로 만들어 준다. 생성자 오버로딩 생성자도 메서드 오버로딩처럼 여러 생성자 제공 가능 public class MemberConstruct { String name; int age; int grade; //추가 MemberConstruct(String name, int age) { this.name = name; this.age = age; this.grade = 50; } MemberConstruct(String name, int age, int grade) { this.name = name; this.age = age; this.grade = grade; } } this() 생성자 내부에서 자신의 생성자를 호출할 수 있다. (중복 제거를 위해) 단, this()는 생성자 코드 첫줄에만 작성할 수 있다. (아니면 컴파일 오류 발생) public class MemberConstruct { String name; int age; int grade; MemberConstruct(String name, int age) { this(name, age, 50); //변경 } MemberConstruct(String name, int age, int grade) { this.name = name; this.age = age; this.grade = grade; } } 절차 지향 프로그래밍 VS 객체 지향 프로그래밍 절차 지향 프로그래밍 프로그램의 흐름을 순차적으로 따르며 처리하는 방식 데이터와 기능이 분리되어 있다. 데이터와 기능의 분리는 유지보수 관점에서 관리 포인트가 2곳으로 늘어난다. 객체 지향 프로그래밍 객체들 간의 상호작용을 중심으로 프로그래밍하는 방식 (실제 세계의 사물이나 사건을 단순하게 추상화) 속성과 기능(메서드)이 객체 안에 함께 포함되어 있다. (캡슐화) 장점 객체 사용자의 입장에서 코드가 보다 친숙하고 가독성이 높다. 유연하고 변경이 용이하다. (OCP 원칙을 지키는 확장 가능한 설계) 실세계를 역할(인터페이스)과 구현(구현한 클래스 혹은 객체)으로 구분 (다형성) 클라이언트 코드를 변경하지 않고 서버의 구현 기능을 변경할 수 있다. (= 클라이언트는 인터페이스만 알면 내부 구조를 몰라도 되고 내부 구조를 변경해도 영향을 받지 않는다.) 한계 인터페이스가 변하면 클라이언트, 서버 모두 큰 변경이 발생한다. 따라서 인터페이스를 안정적으로 잘 설계하는 것이 중요하다. 캡슐화(Encapsulation) 속성과 기능을 하나로 묶어서 꼭 필요한 기능만 메서드를 통해 외부에 제공하고 나머지는 모두 내부로 숨기는 것 속성과 기능 묶기 + 접근 제어자를 통해 실현 좋은 캡슐화 속성은 반드시 숨기자. 객체의 데이터는 객체가 제공하는 기능인 메서드를 통해서 접근해야 한다. 데이터를 외부에 열어두면 클래스 내 데이터를 다루는 로직을 무시하고 데이터를 변경할 수 있음 꼭 필요한 기능만 노출하자. 클래스 내부에서만 사용하는 기능들은 모두 감추는 것 좋다. 사용하는 개발자 입장에서 필요한 기능만 정리되어 복잡도가 낮아진다. 음악 플레이어 예제 메소드 추출 팁 자신이 가진 데이터로 계산한다면, 일반적으로 자기자신이 메서드로 계산하는게 좋다. 나중에 수정이 생기거나 변경이 생길 때 본인만 바꾸면 되므로 관리가 편하다. 접근 제어자 해당 클래스 외부에서 특정 필드나 메서드에 접근하는 것을 허용하거나 제한할 수 있다. 필드, 메서드, 생성자에 사용된다. 지역변수는 스코프 내에서만 사용하므로 접근제어자를 사용하는 의미가 없고 사용할 수도 없다. 클래스에는 일부만 사용가능하다. (public, default) public 클래스는 반드시 파일명과 이름이 같아야 한다. 하나의 자바 파일에 public 클래스는 하나만, default 클래스는 무한정 만들 수 있다. 종류 private: 모든 외부 호출을 막는다. default(package-private): 같은 패키지안에서 호출은 허용한다. protected: default + 다른 패키지여도 상속 관계의 호출은 허용한다. public: 모든 외부 호출을 허용한다. 상속(Inheritance) extends 기존 부모 클래스의 필드와 메서드를 새로운 자식 클래스에서 재사용하는 것 중복을 줄이고 편리하게 확장할 수 있음 단일 상속만 할 수 있다. (다중 상속은 불가능) 만일, 두 부모를 상속받았는데 둘 다 move()라는 메서드를 가지고 있다면 어떤 메서드를 실행해야할지 애매하다. (다이아몬드 문제) 클래스 계층구조가 매우 복잡해질 수 있다. 메서드 오버라이딩 상속 받은 기능을 자식이 재정의하는 것 멤버변수는 오버라이딩되지 않는다. @Override 메모리 구조 상속관계 객체 생성 시 그 내부에 부모와 자식이 모두 생성된다. (하나의 참조값에 두 클래스 정보가 공존) 상속관계 호출시 대원칙 (3개) 상속관계 객체 호출 시, 호출자의 타입을 기준으로 먼저 찾는다. 현재 타입에서 기능을 찾지 못하면 상위 부모 타입으로 기능을 찾아서 실행한다. (끝까지 올라가도 없으면 컴파일 오류 발생) 자식 클래스에 오버라이딩된 메서드가 있다면 항상 우선하여 호출된다. Car와 ElectricCar 예제 super 상속관계에서 부모와 자식의 필드 이름과 메서드 이름이 같은 경우, 부모를 참조하고 싶을 때 super를 통해 부모 클래스로 접근한다. 생성자 상속관계를 사용하면 자식 클래스의 생성자와 부모 클래스의 생성자를 반드시 호출해야 한다. 상속 시 생성자 첫 줄에 super()를 사용해 부모 클래스 생성자를 호출해야 한다. 예외로 첫 줄에 this()(=나말고 다른 생성자를 호출해줘)를 사용할 수 있다. 그러나 자식 생성자 내에서 언젠간 super()가 호출되어야 한다. 부모 클래스의 생성자가 기본생성자라면 super()를 생략할 수 있다. 결과적으로 상속관계 생성자 호출은 부모에서 자식 순으로 실행된다. 다형성(Polymorphism) 다른 타입의 객체를 하나인 것처럼 처리해 주는 것 (아래 두가지 특성 덕분에 실현됨) (= 한 객체가 여러 타입의 객체로 취급될 수 있는 것) 다형성의 본질은 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다는 것 다형적 참조 부모는 자식을 품을 수 있다. (부모 타입의 변수가 다양한 자식 인스턴스를 참조할 수 있다.) Parent poly = new Child() = 업캐스팅 (업캐스팅은 생략이 가능하고 권장된다.) 업캐스팅은 메모리상에 인스턴스가 항상 존재하므로 안전하다. 반면에, 자식은 부모를 품을 수 없다. Child child = poly // 컴파일 에러 만약 부모 클래스에서 자식 클래스의 메서드를 호출하고 싶다면 다운캐스팅 해야한다. Child child = (Child) poly ((Child) poly).childMehtod() (일시적 다운 캐스팅도 가능) 다만, 다운캐스팅은 자식 타입이 메모리상에 존재하지 않을 경우 ClassCastException 런타임 에러를 발생시키므로 매우 주의가 필요하다. 다운 캐스팅 시 instance of를 사용하면 안전하다. 오른쪽에 있는 타입에 왼쪽에 있는 인스턴스 타입이 들어갈 수 있으면 true, 아니면 false new Parent() instanceof Parent // true new Child() instanceof Parent // true new Parent() instanceof Child // false 자바 16부터는 instanceof와 동시에 변수 선언도 가능하다. if (parent instanceof Child child) {...} 다형적 참조 덕분에 자식 인스턴스들을 함수의 부모 타입 매개변수로 참조하거나, 배열의 타입을 부모 타입으로 가져가 자식 인스턴스들을 참조할 수 있다. (중복 제거 및 반복 가능) 메서드 오버라이딩 오버라이딩된 메서드는 항상 우선권을 가진다. 자식에서도 오버라이딩하고 손자에서도 오버라이딩했다면, 손자의 오버라이딩 메서드가 우선권을 가진다. 만일 메서드 오버라이딩이 없다면 항상 부모 타입의 메서드를 호출했을 것이다. 다형성 덕분에 IoC, OCP, DIP, 전략 패턴 등이 가능해짐 다형성이 매우 중요하다. OCP 원칙 좋은 객체 지향 설계 원칙 중 하나 Open for extension, Closed for modification (확장에는 열려있고 변경에는 닫혀 있다) 기존의 코드 수정 없이 새로운 기능을 추가할 수 있다는 의미 다형성을 보완하는 추상 클래스 추상 클래스는 다형성만으로 생기는 두 가지 문제를 해결한다. 부모 클래스를 인스턴스로 생성할 수 있는 문제 (추상적인 개념이 실제로 존재하는 것은 이상함) 부모 클래스를 상속 받는 자식 클래스가 메서드 오버라이딩을 하지 않을 가능성 (개발자의 실수) 추상 클래스 부모 클래스는 제공하지만 실제 생성되면 안되는 클래스 추상적인 개념을 제공하며 부모 클래스 역할로서 상속 목적으로 사용 인스턴스를 생성할 수 없음 (제약 1) abstract class AbstractAnimal {...} 추상 메서드 자식 클래스가 반드시 오버라이딩해야 하는 메서드 (제약 2) 메서드 바디가 없음 추상 메서드가 하나라도 있는 클래스는 추상 클래스로 선언해야 한다. public abstract void sound() 인터페이스 - 순수 추상 클래스를 지원 인터페이스 등장 배경 추상 클래스는 여전히 자신의 메서드를 가질 수 있다. 반면에, 순수 추상 클래스는 추상 클래스를 실행 로직이 전혀 없는 추상 메서드로만 구성한 것을 의미한다. 이는 다형성을 위한 규격, 마치 USB 인터페이스 같은 느낌을 준다. 자바는 이러한 순수 추상 클래스를 편리하게 사용할 수 있도록 인터페이스를 지원한다. 특징 interface 키워드, 구현시 implements 키워드 사용 인터페이스의 메서드는 모두 public abstract이다. (직접 쓸 수도 있지만 생략 권장) 인터페이스의 멤버 변수는 public static final이다. (마찬가지로 생략 권장) 구현이라는 용어 사용 상속은 부모의 기능을 물려 받는 것이지만, 인터페이스는 모든 메서드가 추상 메서드이므로 물려받을 기능이 없고 오히려 자식이 오버라이딩해서 메서드를 구현해야 한다. 다만, 자바 입장에서는 상속이나 구현이나 동일하게 동작한다. 클래스 & 추상 클래스 & 인터페이스는 코드와 메모리 구조상 모두 동일하다. 다중 구현을 지원 유용한 이유 제약 인터페이스의 메서드를 반드시 구현하라는 규약을 준다. 순수 추상 클래스를 지향해도 추상 클래스는 다른 개발자가 미래에 메서드를 추가할 수 있기 때문에, 인터페이스는 이를 예방한다. 다중 구현 클래스의 상속이 하나의 부모만 지정할 수 있는 것과 달리, 인터페이스는 여러 부모를 둘 수 있다. 인터페이스는 자신이 구현을 가지지 않고, 자식이 메서드를 구현한다. 또한 어차피 오버라이딩으로 인해 자식의 메서드가 호출된다. 따라서, 다이아몬드 문제가 발생하지 않는다. 실무적 장단점 인터페이스는 기획이나 사용 기술이 구체화되지 않았을 때, 구현을 미룰 수 있다. (장점) 어떤 DB를 사용할지 미정이라면, 인터페이스만 구현 후 메모리 레포지토리를 사용 할인 정책이 미정이라면, 인터페이스만 구현 후 0원 할인으로 미리 개발 가능 인터페이스는 추상화라는 비용을 발생시킨다. (단점) 개발자가 코드를 읽을 때 인터페이스를 항상 본 후 구현체를 보게 되어 읽는 시간이 증가한다. 대부분 모든 곳에 인터페이스를 먼저 구현하는 것이 이상적이지만, 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고 향후 꼭 필요할 때 리팩토링해서 인터페이스를 도입하는 것도 좋다. 의존 관련 용어 정리 A -> B (UML) = A가 B를 안다. = A가 B를 의존한다. = A가 B를 상속받았다. (A가 자식이고 B가 부모다) = A가 B를 사용한다. 좋은 객체 지향 설계의 5가지 원칙 (SOLID) 클린 코드 저자 Robert Martin(로버트 마틴)은 좋은 객체 지향 설계의 5가지 원칙을 제시한다. 단일 책임 원칙(SRP, Single responsibility principle) 한 클래스는 하나의 책임만 가져야 한다. 책임의 추상적인 표현이지만, 변경을 기준으로 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것 개방-폐쇄 원칙(OCP, Open/closed principle) 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 다형성을 활용해 기존 코드는 변경하지 않고 새로운 기능들을 추가할 수 있다. 리스코프 치환 원칙(LSP, Liskov substitution principle) 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 다형성의 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것 다형성에 신뢰성을 부여하고 지원하는 원칙 예시 자동차 인터페이스의 엑셀은 앞으로 가야하는 기능인데, 뒤로 가게 구현하면 LSP 원칙 위반 느리게 가더라도 앞으로 가야한다. 인터페이스 분리 원칙(ISP, Interface segregation principle) 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 인터페이스가 명확해지고 대체 가능성이 높아진다. 예시 자동차 인터페이스 -> 운전 인터페이스 & 정비 인터페이스로 분리 사용자 클라이언트 -> 운전자 클라이언트 & 정비사 클라이언트로 분리 정비 인터페이스가 변해도 운전자 클라이언트에 영향을 주지 않음 의존 관계 역전 원칙(DIP, Dependency inversion principle) 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 즉, 클라이언트 코드가 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 의미 다만, 다형성만으로는 OCP, DIP 원칙을 지킬 수 없다. OCP, DIP를 지키려고 하다보면 결국 스프링 프레임워크를 만들게 된다. Reference 김영한의 실전 자바 - 기본편 스프링 핵심 원리 - 기본편

Java-Ecosystem · 2024-02-06

자바 메모리 구조와 변수, 메서드 종류

자바 메모리 구조 메서드 영역 프로그램을 실행하는데 필요한 공통 데이터를 관리 프로그램의 모든 영역에서 공유됨 구성 클래스 정보: 클래스 실행 코드 (바이트 코드) - 필드, 메서드, 생성자 코드 등 static 영역: static 변수, 메서드, 클래스들을 보관 (프로그램 시작부터 끝까지 메모리 할당) 런타임 상수 풀: 프로그램을 최적화하기 위해 공통 리터럴 상수를 보관 스택 영역 실제 프로그램이 실행되는 영역 실행 스택을 생성하고 메서드가 호출될 때마다 스택에 스택 프레임을 쌓는다. 메서드가 종료되면 스택프레임을 제거한다. 지역변수, 중간 연산 결과, 메서드 호출 정보 등이 스택 프레임에 포함된다. 처음 자바를 실행하면 main()을 실행하기 위해 실행 스택에 main() 스택 프레임을 하나 생성한다. 힙 영역 인스턴스가 생성되는 영역 (new 명령어를 사용하면 여기를 사용) 가비지 컬렉션이 이루어지는 영역이며, 더 이상 참조되지 않는 객체는 GC에 의해 제거된다. 메서드 코드의 위치 객체가 생성될 때, 인스턴스 내부 변수 값은 각각 힙 영역에 할당되어 독립적으로 존재하지만, 메서드는 새로운 메모리 할당없이 공통된 코드를 공유한다. 따라서, 인스턴스 메서드를 호출하면 실제로는 메서드 영역에 있는 코드를 힙 영역으로 불러와서 수행한다. 단, static 메서드는 메서드 영역의 클래스 정보 코드를 사용하겠지만, 실행도 메서드 영역의 클래스 정보에서 한다. 멤버 변수의 종류 인스턴스 변수 (static이 붙지 않음) 각각의 인스턴스에 독립적으로 소속되어 있는 변수 static 변수 (static이 붙음) 클래스 자체에 소속되어 공용으로 함께 사용할 수 있는 변수 static 변수 = 정적 변수 = 클래스 변수 메서드 영역 (static 영역)에서 관리 클래스명 + . 으로 접근 (자신의 클래스에 있는 정적 변수라면 클래스명 생략 가능) 처음 자바가 로딩될 때 하나만 생성 일반적으로 자바 프로그램이 실행되고 JVM이 처음 뜰 때, 클래스 정보를 메소드 영역에 모두 불러 들이고, static이 붙은 변수들은 메모리(static 영역)에 할당해버린다. 이런 static 변수들은 이 때 딱 하나 만들어지고 Java가 끝날 때까지 계속 쓸 수 있다. 변수의 생명주기 지역변수(매개변수 포함): 스택 영역의 스택 프레임에 존재 (메서드 종료 시 소멸) 인스턴스 변수: 힙 영역에 존재 (GC 발동 시 소멸) 클래스 변수: 메서드 영역의 static 영역에 존재 (JVM 종료 시 소멸) 지역변수 < 인스턴스 변수 < 클래스 변수 지역 변수가 제일 짧고, 클래스 변수가 제일 길다. static이 정적인 이유 힙 영역에 생성되는 인스턴스 변수는 런타임에서 동적으로 생성되고 제거되지만, static 변수는 프로그램 시작 시점에 만들어지고 프로그램 종료 시점에 제거되므로 상대적으로 매우 정적이다. 멤버 메서드의 종류 인스턴스 메서드 (static이 붙지 않음) 인스턴스에 소속되어 인스턴스를 생성해야 사용할 수 있는 메서드 static 메서드 (static이 붙음) 클래스에 소속되어 클래스에 바로 접근해 사용할 수 있는 메서드 static 메서드 = 정적 메서드 = 클래스 메서드 인스턴스 변수를 필요로 하지 않는 단순 기능만 제공하는 경우 사용 (유틸리티성 메서드) static 메서드는 static만 사용할 수 있다.(정적변수나 정적 메서드) main()가 대표적 정적 메서드 (main()이 같은 클래스에서 호출하는 메서드도 정적 메서드) 자주 호출해야 한다면 static import를 통해 클래스 명을 생략하고 메서드를 호출할 수 있다. final 변수에 final 키워드가 붙으면 더는 값을 변경할 수 없다. 특정 변수의 값을 할당한 이후 변경하지 않아야 한다면 사용하자. (고객 id 같은 부분) 의미 있는 경우 static final 필드(클래스 멤버 변수)를 필드 초기화 하는 것 (메모리 중복 없음) 상수도 static final을 지정한다. 생성자를 이용해서 final 필드(인스턴스 멤버 변수)를 초기화 하는 것 의미 없는 경우 final 필드(인스턴스 멤버 변수)를 필드 초기화 하는 것 (인스턴스마다 값이 중복되어 메모리 낭비) 클래스 final 상속의 끝을 의미, final로 선언된 클래스는 상속할 수 없다. 메서드 final 오버라이딩의 끝을 의미, final로 선언된 메서드는 오버라이드 될 수 없다. Reference 김영한의 실전 자바 - 기본편

Java-Ecosystem · 2024-02-06

Pyenv setting 방법 (VS Code)

Pyenv setting 방법 (VS Code) brew install pyenv code ~/.zshrc .zshrc 안에 export PYENV_ROOT="$HOME/.pyenv" export PATH="$PYENV_ROOT/bin:$PATH" eval "$(pyenv init --path)" eval "$(pyenv init -)" # 설치 가능한 Python 버전 $ pyenv install --list # 특정한 버전 Python 설치 $ pyenv install 3.9.0 # 특정한 버전 Python 삭제 $ pyenv uninstall 3.9.0 # 설치된 Python list $ pyenv versions # 해당 Python 버전을 기본으로 설정 $ pyenv global 3.9.0

Python-Ecosystem · 2024-02-05

IntelliJ 단축키 정리

자동완성 계열 iter For Each Syntax sout println soutv println + 원하는 변수 soutm 현재 클래스와 메소드 이름을 출력한다. 리팩토링 계열 command + shift + T 클래스 지정하면 그에 대한 테스트 틀 생성 command + shift + 위/아래 위/아래 메서드와 위치 변경 (메서드에 커서 선택 후 진행) command + shift + 8 Column Selection Mode (여러 라인 동시 수정 가능) command + n 파일 혹은 코드 생성 command + option + N Inline variable로 리팩토링 command + option + V 변수 추출 및 추천 (Introduce variable) command + option + M 메소드 추출 및 추천 command + option + shift + L 파일 코드 재정렬 option + Enter Context에 따른 가능 액션 종류를 보여줌 (create method, create class 등) 자동 import, static import(Add on-demand static import) 지원 option + option + 위/아래 Multi-line select option + shift + click Specific line select ctrl + T 리팩토링 ctrl + O 오버라이드 shift + F6 클래스, 변수, 파라미터 이름을 일괄적으로 변경 유틸 계열 command + B 코드가 사용된 모든 곳들을 추적 command + option + B 해당 인터페이스의 모든 구현체들 추적 command + P 파라미터 정보 제공 command + E 과거 행동 이력 및 이전 파일 이동 command + O Navigate shift X 2 Search (Navigate과 유사) ctrl + R 바로 이전 것 실행 ctrl + shift + R 클래스 레벨 실행 option + ↑ 범위 블록 설정 F2 오류가 발생한 곳으로 커서 이동 command + 숫자 0 Commit 1 프로젝트 디렉토리 영역 혹은 코드 작업 영역 선택 4 Run window 5 Debug window 6 Problems 9 Git log command + F_number F12 해당 클래스의 멤버 변수, 메서드, 상속 클래스 등의 전체 정보 보기

Java-Ecosystem · 2024-02-05

자바 주요 syntax 정리

Java-Ecosystem · 2024-01-28

Java 기본 특징

자바 표준 스펙 자바는 표준 스펙이 존재하고 여러 회사가 자신에 입맞에 맞게 이를 구현한다. 자바 표준 스펙 자바의 설계도 문서 자바 커뮤니티 프로세스(JCP)를 통해 관리 구현 자바 표준 스펙에 맞춰 여러 회사가 각자에 최적화된 자바 프로그램을 개발 오라클 Open JDK, Adoptium Eclipse Temurin, Amazon Corretto etc… 오라클 Open JDK 사용하다가 Amazon Corretto 사용해도 대부분 큰 문제 없음 각 회사들은 다양한 OS(Mac, Windows, 리눅스)에 맞는 자바도 함께 제공 컴파일과 실행 소스코드(Source code) 개발자가 .java 확장자의 자바 소스코드를 작성한다. 컴파일(Compile) 단계 자바가 제공하는 javac 를 사용해, .java -> .class 파일 생성 command: javac Hello.java 즉, 자바 컴파일러가 소스코드를 바이트 코드로 변환 자바 가상 머신에서 더 빠르게 실행될 수 있게 최적화하고 syntax error 검출 실행(Runtime) 단계 java 프로그램을 사용해 자바를 띄우고 바이트코드인 .class 파일을 실행하면, JVM(실제 자바 프로그램 = 자바 가상 머신)이 띄워지면서 바이트코드를 읽고 프로그램을 실행한다. command: java Hello (Hello.class 의 .class 확장자를 빼고 입력) 운영체제 독립성 일반적인 프로그램은 다른 운영체제에서 실행할 수 없다. Windows 프로그램은 Windows OS가 사용하는 명령어들로 구성되어 있어서, 다른 OS와 호환되지 않음. 반면에, 자바 프로그램은 자바가 설치된 모든 OS에서 실행 가능 (호환성) 각 OS에 맞게 설치된 자바는 해당 OS의 명령어들로 컴파일된 .class 바이트코드를 실행 덕분에 개발할 때와 서버 실행 시 환경에 맞춰 다른 자바를 사용할 수 있다. 개발: Mac, Windows 서버: AWS Linux (Amazon Corretto 자바 설치) Reference 김영한의 자바 입문 - 코드로 시작하는 자바 첫걸음

Java-Ecosystem · 2024-01-28

관계형 데이터베이스 모델 개념

Relational Data Model & Relational Database Relation in Mathematics Set 서로 다른 elements를 가지는 collection elements의 순서는 중요하지 않음 Cartesian Product Set A & Set B의 element로 만들 수 있는 모든 pair의 조합 Relation Cartesian product의 부분 집합 (subset of Cartesian product) n-ary relation: n개의 Set에 대한 cartesian product의 부분집합 tuple들의 집합 (set of tuples) tuple은 하나의 pair를 의미 Relational Data Model Relation이 Relational Data Model에서는 Table로 표시 Relation = Table = Set of Tuples tuple(행) & attribute(열) Relation Schema Relation의 구조를 나타냄 (constraints 포함) e.g. Student(id, name, grade, major, phone_num, emer_phone_num) Degree of Relation Relation schema에서 attributes의 수 Relational Database Relational data model에 기반하여 구조화된 database (여러개의 relations로 구성) Relational Database Schema relation schemas set + integrity constraints set Constraints Implicit constraints Relational Data Model 자체가 가지는 제약 Explicit constraints (Schema-based Constraints) 주로 DDL을 통해 schema에 직접 명시 종류 Domain Constraints Attribute value는 해당 attribute가 가질 수 있는 value여야 함 Key Constraints 서로 다른 tuple은 같은 key 값을 가질 수 없음 Null value Constraints Attribute가 NOT NULL로 명시 됐다면, NULL을 값으로 가질 수 없음 Entity Integrity Constraints Primary key는 NULL을 가질 수 없음 Referential Integrity Constraints FK는 PK에 없는 value를 값으로 가질 수 없음

Computer Science · 2023-10-03

데이터베이스 기본 용어

Database 전자적으로 저장되고 사용되는 관련있는 데이터들의 조직화된 집합 Electronically, Related, Organized collection DBMS (Database Management System) 사용자에게 DB를 정의 및 관리하는 기능을 제공하는 소프트웨어 시스템 PostgreSQL, MySQL, Oracle Database, SQL Server Metadata(=Catalog, Data about Data) DB를 설명하는 데이터 (Descriptive) DBMS를 통해 관리됨 e.g. 데이터 유형, 구조, 제약 조건, 보안, 저장, 인덱스, 사용자 그룹 etc… Database System Database + DBMS + 연관된 applications 포괄적으로 database라고 부르기도 함 Data Model DB의 구조를 추상화해 설명하는 모형 (DB 구조: 데이터 유형, 데이터 관계, 제약 사항 etc…) DB 기본 Operations(CRUD)를 포함 종류 Conceptual Data Model (=high-level) 일반 사용자들이 쉽게 이해할 수 있게 DB를 구조화 (추상화 수준이 가장 높음) 비즈니스 요구사항 기술에 사용 Logical Data Model (=representational) 특정 DBMS에 종속되지 않는 수준에서 디테일하고 이해하기 쉽게 DB를 구조화 실제 DB 설계를 할 수 있는 수준 종류 (DBMS가 채택) relational data model (MySQL, Oracle DB, SQL Server) object data model object-relational data model (PostgreSQL) Physical Data Model (=low-level) 컴퓨터에 데이터가 어떻게 파일 형태로 저장되는지를 기술 data format, data orderings, access path(e.g. index…) Database Schema Data Model을 바탕으로 database의 구조를 기술한 것 Database State (=Snapshot =현재 instances의 집합) 특정 시점에 database에 있는 실제 데이터 Three-Schema Architecture User Application으로 부터 물리적인 database를 분리 각 레벨을 독립시켜 어느 레벨의 변화가 상위 레벨에 영향을 주지 않게 함 (안정적인 데이터베이스 운영) Database system을 구축하는 architecture 중 하나로 가장 많이 사용됨 대부분의 DBMS가 어느정도 따르나 three level을 완벽하게 나누지는 않음 Conceptual 변화는 External Level에 영향을 안 미치는 것이 상대적으로 힘들기 때문 각각의 Schema는 DB 구조를 표현만 함. 데이터가 실제 존재하는 곳은 internal level 분류 external schemas at external level (user view) 특정 유저들이 필요로 하는 데이터만 표현 (그 외 데이터는 숨김) logical data model을 통해 표현 conceptual schemas at conceptual level internal schema를 추상화해서 물리적인 저장 구조 내용은 숨기고 전체 DB 구조를 기술 entities, data types, relationships, user operations, constraints에 집중 logical data model을 통해 표현 internal schemas at internal level 물리적으로 데이터가 어떻게 저장되는지 physical data model을 통해 표현 data storage, data structure, access path 등 실체가 있는 내용 기술 Database Language 오늘날 DBMS는 DML, VDL, DDL이 따로 존재하기 보다는 통합된 언어로 존재 (e.g. SQL) 언어 종류 DDL (Data Definition Language) Conceptual Schema를 정의하기 위해 사용하는 언어 SDL (Storage Definition Language) Internal Schema를 정의하기 위해 사용하는 언어 최근엔 파라미터 설정으로 대체 (SDL은 거의 없음) VDL (View Definition Language) External Schema를 정의하기 위해 사용하는 언어 대부분의 DBMS에서 DDL이 VDL 역할까지 수행 DML (Data Manipulation Language) Database에 있는 실제 data를 활용하기 위한 언어 (CRUD)

Computer Science · 2023-10-01

파이썬으로 살펴보는 아키텍처 패턴: TDD, DDD, EDM 적용하기

Part 1 목표 아키텍처 Chapter 0 Big Ball of Mud에 대한 접근 Big Ball of Mud 안티패턴 처음에 깔끔한 작성을 목표로 시작한 소프트웨어 시스템도 시간이 지나면서 모든 요소 (도메인 지식, 비즈니스 로직, 로깅, 이메일 보내기 etc…)들이 서로 Coupling(결합)되어 시스템의 일부를 바꾸는 것도 힘들어지는 상황 Big Ball of Mud를 피하기 위한 일반적인 접근 1. Abstraction(추상화) & Encapsulation(캡슐화) 행동을 캡슐화하여 추상화로 사용하는 것은 코드의 표현력을 높이고 테스트와 유지보수를 더 쉽게 만든다. 2. Layering(계층화) Layering Architecture는 복잡한 의존성들을 해결한다. 코드의 역할을 구분하고 범주(category)를 나눠 어떤 코드 범주가 특정 코드 범주를 호출할 수 있는지 규칙을 정한다. 도메인 모델(Domain Model)로 비즈니스 계층을 만들고, 모든 비즈니스 로직을 이곳에 모아야 한다. 3-Layer Architecture: 표현 계층 (UI or API or CLI…) ————|———— 비즈니스 로직 (Business Rules & Workflows) ————|———— 데이터베이스 계층 (Data Read & Write) 3. DIP (Dependency Inversion Principle, 의존성 역전 원칙) 비즈니스 코드는 기술적인 세부 사항에 의존해서는 안된다. 서로 추상화를 사용해 강한 의존성을 해소하여 각자가 독립적으로 변경될 수 있는 환경을 만들어야 한다. 예를 들어, 인프라를 바꿔야 하는 필요성이 있을 때 비즈니스 계층을 변경하지 않고도 인프라 세부 사항을 바꿀 수 있어야 한다. DIP의 정의 고수준 모듈은 저수준 모듈에 의존해서는 안된다. 두 모듈 모두 추상화에 의존해야 한다. 추상화는 세부 사항에 의존해서는 안된다. 반대로 세부 사항은 추상화에 의존해야 한다. Chapter 1. 도메인 모델링 도메인 모델 Domain(도메인): 해결해야 할 문제 Model(모델): 어떤 프로세스나 현상을 설명하기 위해 그것의 특성을 관찰하고 정리한 일종의 Mind Map DDD(Domain-Driven Design)는 도메인 모델링의 개념을 널리 알렸고, 소프트웨어에서 가장 중요한 요소는 문제에 대해 유용한 모델을 제공하는 것이라고 주장한다. 도메인 모델링 자체는 DDD보다도 일찍 시작된 개념 (1980~) 비즈니스 전문가는 이미 그들의 도메인의 비즈니스 용어가 있으므로 개발자는 이를 공부하고 소프트웨어에 녹여내야 한다. 도메인 모델의 용어와 규칙은 비즈니스 전문가와 Ubiquitous Language(유비쿼터스 언어=비즈니스 전문용어)로 표현해야 한다. Value Object, Entity Value Object 데이터는 있지만 유일한 식별자가 없는 비즈니스 개념, 내부 데이터에 의해 개체 식별 값이 같으면 동일하다. (Structural Equality,구조적 동등성) 10파운드를 말할 때 10파운드라는 값(가치)이 중요하지, 어떤 지폐인지는 중요하지 않다. 수명이 없고 항상 Entity에 속한다. 불변(immutable) 속성 dataclass의 @frozen=True 로 해시 설정 Entity 고유한 식별자로 구분되는 개념 식별자가 같으면 동일하다. (Identifier Equality) 같은 이름, 같은 성별의 군인도 다른 군번(id)을 가진 동명이인일 수 있다. 수명이 있다. 가변(mutable) 속성 __eq__를 식별자로 비교하도록 구현 __hash__를 None으로 설정해서 집합등에 사용할 수 없게 구현 엔티티(entity)와 값객체(value-object)에 대해서 __hash__는 객체를 집합에 추가하거나 딕셔너리의 키로 사용할 때 동작을 제어하는 magic method Domain Service Function 동사로 표현되는 부분은 (도메인과 관련된 비즈니스 로직)을 함수로 구현한다. Domain Exception(예외)을 통해서도 도메인 개념을 표현할 수 있다 Ex) OutOfStock 이러한 동사 하나하나가 단위 테스트가 된다. Chapter 2. 저장소 패턴 앱과 도메인이 복잡한 경우 Repository Pattern을 통해 저장소 계층을 하나 추가하는 방향을 생각해 볼 수 있다. 영속성과 분리된 모델(Persistence-Igorant Model) - 도메인 모델과 ORM의 분리 도메인 모델은 그 어떤 의존성도 없어야 한다. 즉, 인프라와 관련된 문제가 도메인 모델에 영향을 끼쳐 단위테스트를 느리게 하고 도메인 모델 변경을 어렵게 해서는 안된다. 따라서, 모델(비즈니스 로직)을 내부에 있도록 하여 의존성이 내부로 들어오게 해야 한다. (Onion Architecture) 이를 위해 도메인 모델과 ORM을 분리하여 도메인 모델이 항상 순수한 상태를 유지하고 인프라에 신경쓰지 않도록 한다. SQLAlchemy의 Classical Mapper를 사용하면 이를 구현할 수 있다. 이러한 구조에서는 비즈니스 로직에 영향을 주지 않고 SQLAlchemy를 제거하여 다른 ORM 혹은 전혀 다른 영속화 시스템을 채택해 갈아 끼울 수 있다. Repository Pattern (저장소 패턴) 데이터 저장소를 간단히 추상화하는 것으로 데이터 계층을 분리할 수 있다. 추상화한 Repository는 마치 모든 데이터가 메모리 상에 존재하는 것처럼 가정해 데이터 접근과 관련된 세부 사항을 감춘다. 일반적으로 get(), add()를 통해 데이터를 가져오고 조작한다. 저장소에 대한 테스트는 모든 모델이 할 필요는 없다. 한 모델 클래스에 대해 생성/변경/저장을 모두 테스트했다면, 새로 추가되는 비슷한 패턴의 클래스는 최소한의 호출 응답만 확인하거나 테스트를 전혀 진행하지 않을 수도 있다. Pros & Cons 장점 Repository와 Domain Model사이의 인터페이스를 간단하게 유지할 수 있다. 모델과 인프라를 완전히 분리했기 때문에 도메인이 복잡해도 비즈니스 로직 변경과 인프라 변경이 쉽다. 영속성을 생각하기 전에 도메인 모델을 작성하면, 처리해야 할 비즈니스 문제에 더 잘 집중할 수 있다. Fake Repository를 만드는 식으로 단위 테스트를 위한 가짜 저장소를 쉽게 만들 수 있다. 단점 ORM mapping 변경 및 유지 보수 작업에 공수가 더 든다. (모델, ORM 둘 다 손봐야 하기 때문에) 저장소 계층에 대한 러닝커브가 발생한다. Chapter 3. 결합과 추상화 Cohesion(응집)과 Coupling(결합) 응집: 한 컴포넌트가 다른 컴포넌트를 지원하며 서로 맞물려 잘 돌아가는 상황 (지역적인 결합) 결합: B 컴포넌트가 깨지는게 두려워서 A 컴포넌트를 변경할 수 없는 경우 (전역적인 결합) Abstraction(추상화) 추상화를 통해 세부사항을 감추면 시스템 내 결합 정도를 줄일 수 있다. 또한, 추상화는 테스트를 더 쉽게 해준다. Fake Object VS Mock Fake Object 대치하려는 대상을 동작할 수 있게 구현한 존재, 테스트를 위한 구현만 제공 (고전 스타일 TDD) 의존성 주입을 하는 함수를 만들면 Test 시 Fake Object를 만들어 주입하기 쉬움 I/O의 경우 의존성 주입해 Fake를 뜨면 편함 def synchronise_dirs(reader, **filesystem**, source_root, dest_root): Mock 대상이 어떻게 쓰이는지 검증할 때 사용 (런던 학파 TDD) 목을 너무 많이 사용하는 테스트는 설정 코드가 많아서 정작 신경을 써야 하는 이야기가 드러나지 않는 단점이 있다. Chapter 4. 서비스 계층 (유스 케이스) Use Case(유스 케이스) 사용자의 행동 요청 시나리오에 따라 시스템이 수행하는 작업 과정 Orchestration(오케스트레이션) 저장소에서 여러 데이터를 가져오고, 데이터베이스 상태에 따라 입력을 검증하며 오류 처리하고, 성공적인 경우 데이터를 데이터베이스에 커밋하는 일련의 작업들을 의미한다. 이러한 로직은 웹 API 엔드포인트와 관련이 없고 엔드포인트를 무겁고 장황하게 만드므로, 따로 서비스 계층에 분리하는 것이 타당하다. Service Layer 유스 케이스를 정의하고 워크 플로를 조정하는 Orchestration(오케스트레이션) 로직을 담는다. (서비스 계층=오케스트레이션 계층=유스 케이스 계층) 전형적인 서비스 계층 함수들은 다음과 비슷한 단계를 거친다. 저장소에서 어떤 객체들을 가져온다. 현재 세계를 바탕으로 요청을 검사하거나 어서션으로 검증한다. 도메인 서비스(비즈니스 로직)를 호출한다. 모든 단계가 정상적으로 실행됐다면 변경한 상태를 저장하거나 업데이트한다. 서비스 계층 추가 시 다음과 같은 장점이 있다. 엔드포인트가 아주 얇아지고 작성하기 쉬워진다. 엔드포인트는 JSON 파싱이나 웹 기능만 담당한다. 테스트의 상당 부분을 빠른 단위 테스트와 최소화된 E2E 및 통합 테스트로 만들어, 테스트 피라미드를 높은 기어비(High Gear)로 적절히 구성할 수 있다. Chapter 5. 높은 기어비와 낮은 기어비의 TDD 결합과 설계 피드백 사이의 트레이드 오프 API 테스트(High Gear)로 갈수록 세부 설계 피드백은 적어지지만, 더 넓은 커버리지의 테스트를 제공하므로 데이터베이스 스키마 변경 등의 대규모 변경에 대하여 코드가 망가지지 않는다는 자신감을 제공한다. 반대로, 도메인 모델 테스트(Low Gear)는 도메인 언어로 작성되므로 모델의 살아있는 문서 역할을 한다. 다만, 특정 구현과 긴밀하게 결합되어 있어서 전체가 깨질 수 있는 불안함을 포함해 로직 변경시 Cost가 크다 Service Layer 추가 후 지향할 테스트 방향 도메인 모델에 집중되어 있던 단위 테스트를 모두 서비스 계층 함수에 대해 테스트하도록 리팩토링할 필요가 있다. 즉, E2E 테스트는 호출과 응답에 관련한 Happy Path, Unhappy Path만 테스트하고 비즈니스 로직 관련 테스트는 Service Layer 함수들에 대한 단위테스트로 진행한다. 도메인 모델에 대한 테스트가 너무 많으면 코드베이스를 바꿀 때마다 수십 개에서 수백 개의 테스트를 변경해야 하는 문제가 생긴다. 서비스 계층 테스트는 더 낮은 결합(Coupling)을 제공하고 커버리지, 실행 시간, 효율 사이를 잘 절충할 수 있게 도와줘서 도메인 모델 테스트 보다 이점이 있다. 또한, 서비스 계층 테스트에 집중하면 커버리지가 더 높으므로, 도메인 모델을 리팩토링할 때 변경해야 하는 코드의 양을 크게 줄일 수 있다. 서비스 계층 테스트를 도메인으로부터 완전히 분리하기 서비스 함수 파라미터는 도메인 객체를 받지 않고 원시 타입으로 받도록 선언하자. def allocate(line: OrderLine, repo: AbstractRepository, session) -> str 보다는 def allocate(orderid: str, sku: str, qty: int, repo: abstractRepository, session) -> str: 으로 사용하자. 서비스 테스트의 모든 도메인 의존성을 한 곳에 모으자. 픽스처 함수에 팩토리 함수를 넣어 도메인 의존성을 모으는 방법이 있다. 개인적으로 가장 좋은 것은 모델 객체를 추가하는 서비스 함수를 하나 작성해두면, 도메인 의존성 없이 테스트에 지속적으로 사용할 수 있어 편리하다. 덕분에 서비스 계층이 오직 서비스 계층에만 의존한다. def test_add_batch(): repo, session = FakeRepository([]), FakeSession() services.add_batch("b1", "CRUNCHY-ARMCHAIR", 100, None, repo, session) assert repo.get("b1") is not None assert session.committed 다만, 단순히 테스트 의존성 제거 만을 위해 새 서비스를 작성할 필요는 없다. 미래에 필요성을 고려해 도입한다. 엔드 투 엔드 테스트 API 테스트 역시 API 테스트에만 의존하도록 하는 것은 괜찮은 방법이다. 또한, Happy Path를 위한 하나의 E2E & 모든 Unhappy Path를 위한 하나의 E2E를 작성해 관리하자. 정리 Chapter 6. 작업 단위 패턴 (Unit of Work) 작업 단위 패턴은 원자적 연산(Atomic Operation)에 대한 추상화다. 어떤 객체가 메모리에 적재됐고 어떤 객체가 최종 상태인지를 기억한다. 장점 UoW는 영속적 저장소에 대한 단일 진입점으로 기능하여 엔드포인트와 서비스 계층을 데이터 계층과 완전히 분리할 수 있다. (서비스 함수 자체와 엔드포인트(Flask, FastAPI)가 데이터베이스와 직접 대화하지 않는다.) 데이터베이스에 접근하는 코드가 여기저기 흩어지지 않게 하나로 모으고, 각 컴포넌트가 자신에게 반드시 필요한 것들만 갖게 하는 것이 좋다. 원자적 연산을 표현하는 좋은 추상화가 생기고, 파이썬 콘텍스트 관리자를 사용하면 원자적 한 그룹으로 묶여야 하는 코드 블록을 시각적으로 쉽게 알아볼 수 있다. 트랜잭션 시작과 끝을 명시적으로 제어할 수 있고, 애플리케이션이 실패하면 기본적으로 안전한 방식의 트랜잭션 처리를 할 수 있다. UoW는 세션을 단순화해 핵심 부분만 사용하도록 해준다. 세션 API는 풍부한 기능과 도메인에 불필요한 연산을 제공하므로, 코드를 Session 인터페이스와 결합하는 것은 SQLAlchemy의 모든 복잡성을 결합하기로 결정하는 것이다. 단점 ORM이 이미 원자적 연산에 대한 좋은 추상화를 제공할 수 있다. (롤백, 다중 스레딩이 담긴) 복잡한 트랜잭션을 처리하는 코드의 경우 매우 신중하게 생각해야 한다.

Software Engineering · 2022-09-20

Empty 자료형의 type annotation에 관하여

Intro Mypy와 친하게(?) 지내다보면 문득 어떤 type annotation를 줘야할지 모호한 경우가 왕왕 발생합니다. (안 발생한다면 mypy랑 베프인 분들 :thumbsup:) 그 중 재밌었던 부분은 빈 리스트 []는 어떤 typing을 주어야할지에 대한 고민입니다. 보통 비어있다고 생각하면 typing 모듈의 Optional을 생각하게 되는데, 사실 약간 불편한 느낌이 있습니다. 예를 들어, Optional[str]은 Union[str, None]과 동일하며 그 의미는 “None을 허용한다”이므로, list[Optional[str]]는 리스트의 element로 str이 오거나 None이 올 수 있다는 말이 됩니다. 즉, [None]도 허용한다는 의미가 포함되게 됩니다. 그렇다면 [None]은 제외하고 순수하게 empty list []만 허용하고 싶을 때는 어떻게 해야 할까요? 결론만 이야기하면, list[str]으로 충분합니다. 굳이 Optional을 사용해 [None]의 경우까지 허용시킬 필요가 없습니다. 실제로 이것이 맞는지 PEP와 Mypy로 함께 확인해봅시다 :smiley: Empty list의 타입 기본적인 list 타입은 위와 같이 선언할 수 있습니다. list[str]는 str 타입의 element로 구성된 리스트를 허용한다는 의미죠. Mypy로 체킹해봐도 dogs: list[str] = ["Welsh Corgi", "Golden Retriever", "Bulldog"]가 문제없이 허용됩니다. []도 허용하고 싶을 때는 어떻게 해야할까요? list[Optional[str]]은 ["Welsh Corgi", "Golden Retriever", "Bulldog"], [None], [] 3가지 경우를 허용합니다. 보통 우리는 [None]에 대한 허용을 필요로 하지 않죠. 따라서, 통상적인 의미의 빈 리스트를 허용 type annotation은 단순히 list[str]을 사용하면 됩니다. list[str]은 ["Welsh Corgi", "Golden Retriever", "Bulldog"], [] 2가지 경우를 허용합니다. list[int], list[float], list[bool] 역시 동일하게 []를 허용합니다. Data type에 따른 분류 기본 자료형 기본 자료형의 경우는 Optional을 사용해주는 것이 본래 의도와 맞을 것입니다. Optional[int] example: 2, None Optional[float] example: 3.14, None Optional[bool] example: True, None 컬렉션 자료형 컬렉션 자료형의 경우, Optional 없이 본래의 타입을 사용하는 것이 의도에 맞을 것입니다. list[str] example: [Welsh Corgi, 'Poodle'], [] dict[int, str] example: {1: "Barking", 2: "Running"}, {} set[int] example: {1, 2}, set() 다만 튜플은 길이가 고정되는 자료형이기 때문에, 빈 튜플을 표현하거나 튜플의 길이를 가변적으로 표현하고 싶다면 다른 방법을 사용해야합니다. tuple[int] example: (4,) tuple[()] example: () (=empty tuple) Union[tuple[()], tuple[int]] example: (), (4,) tuple[int, ...] example: (), (4,), (3, 4, 5) (=Arbitrary-length homogeneous tuple) PEP 484 & Mypy docs 빈 자료형을 어떤 타입으로 표현해야 하는지만을 따로 설명한 챕터는 없습니다. 다만, 이에 대해 신빙성있게 명시된 부분들은 PEP 484 – Type Hints와 Mypy docs - Type inference and type annotations에서 직간접적으로 찾아볼 수 있습니다. PEP 484의 type comments 설명을 보면, empty list를 어떤 타입으로 명시할 수 있는지가 간접적으로 드러나 있습니다. PEP 484의 The typing Module 챕터에서는 empty tuple은 tuple[()], arbitrary-length homogeneous tuple은 tuple[int, ...]를 사용하라고 명확히 설명해주었네요. Mypy docs에서도 collection 자료형의 타입에 관하여 명시된 부분이 있습니다. 이에 따르면, empty list는 list[int], empty dict는 dict[str, int], empty set은 set[int] 등으로 표현 가능합니다. Outro Empty 자료형에 대해 온전히 설명하는 PEP가 있다면 좀 더 좋았을텐데라는 생각이 들지만, 한편으로는 여러 reference에서 이에 대한 증거들을 찾아가는 과정도 꽤 흥미로웠습니다. Empty 자료형은 type annotation을 조금 헷갈리게 할 수 있습니다. 하지만 충분히 직관적으로 타입을 표현할 수 있으니, 이를 염두해서 type annotation을 사용하면 좋을 것 같습니다 :) P.S. Tuple의 type annotation은 직관적인가…? 자료형에 특성에 따른 예외이니까 kindly하게 받아들여야겠다…! Reference PEP 484 - Type hinting #type-comments PEP 484 - Type hinting #the-typing-module Mypy docs - Explicit types for collections

Python-Ecosystem · 2022-05-30

안전한 JWT 발급에 유의해야할 점들

Intro 현재 회사 프로젝트에서 JWT를 사용하면서, JWT를 쿠키로 안전하게 보내기 위해 겪었던 혼란들을 기록해보고자 합니다. HttpOnly 옵션 기본적으로, access token과 refresh token은 서버에서 HttpOnly 옵션을 사용해 쿠키로 발급해주는 것이 바람직합니다. 이는 클라이언트에서 JS를 통해 쿠키로 접근하는 것을 막아주는 옵션이며, JS 코드를 심어 악의적인 명령을 실행하는 XSS(Cross Site Scripting) 공격을 예방할 수 있습니다. (글로벌 변수인 document를 사용해 document.cookie로 접근하는 것을 막아줍니다.) Secure 옵션 서버에서 Secure 옵션을 사용해 JWT를 보냅시다. Secure는 쿠키가 HTTPS 프로토콜에서만 보내지도록 합니다. HTTP에서는 전송 중간에 쿠키가 탈취될 위험이 있기 때문에, 안전하게 HTTPS에서만 보내질 수 있도록 설정합니다. SameSite 옵션 무언가 JWT가 잘 발급되지 않는다 싶으면, SameSite 옵션을 꼭 의심해봅니다. 서버에서 SameSite=None을 설정해 JWT를 보냅시다. 특히, Chrome 브라우저는 SameSite의 default 값이 lax로 되어 있는데 이로인해 cross-site 간의 request에 cookie가 보내지지 않을 수 있습니다. allow-origins, allow-credentials 서버에서 CORS관련 설정들을 잘 세팅합시다. allow-origins에는 CORS를 허락할 클라이언트의 주소를 꼭 입력해줍니다. allow-credentials 옵션도 True로 설정해, 쿠키가 잘 보내질 수 있도록 합니다. 클라이언트가 HttpOnly 쿠키를 사용하는 방법 클라이언트가 HttpOnly 쿠키를 서버로부터 전달 받았다면, 이후 해당 HttpOnly 쿠키는 클라이언트가 어떠한 request를 보낼 때마다 자동으로 쿠키에 담겨 보내집니다. 이 때, 클라이언트에서 withCredentials=True를 설정하고 request를 보내야 쿠키가 올바르게 전송 됩니다. Access token과 refresh token이 자동으로 담겨지는 점이 편리하죠! Outro 직접 주어진 실무 문제는 아니었지만, 문제 해결에 함께 참여하고 개인 프로젝트에서 잘 되지 않았던 점들을 되짚어 보면서 많은 공부가 되었습니다. HttpOnly 쿠키로 JWT를 보낼 때, 여러가지 조건이 갖춰져야 비로소 올바르게 전송됩니다. 생각보다 장애물이 많은데, 잘 기록해둬야 나중에 같은 문제를 마주했을 때 덜 헤맬 것 같습니다 :)

Blog · 2022-05-30

Poetry typed package를 mypy가 인식하려면? feat. py.typed

Intro 최근 몇 주간은 회사 업무 중 트러블 슈팅이 특히 많았습니다. 그 중 가장 기억에 남았던 것은 import한 poetry 패키지의 타입을 mypy가 제대로 인식하지 못하는 문제였습니다. 해당 문제는 MSA로 개발 중인 프로젝트에서 발생했는데, 각 서비스에서 공통으로 쓰이는 class들을 하나의 패키지에 담는 과정에서 나타났습니다. 이는 py.typed 파일을 추가함으로써 생각보다 간단히(?) 해결할 수 있었는데, 그 과정을 남겨보고자 합니다. Problem Poetry로 빌드된 패키지를 개발 중인 서비스로 import 하고 mypy로 type checking하니, 위와 같이 무수한 type error가 발생했습니다. :( 우선, 관련 error는 mypy extension package 중 하나인 sqlalchemy2-stubs의 적용이 제대로 이루어지지 않아 발생한 에러였습니다. 서비스 내에는 잘 install 되어 있었기 때문에, 처음엔 패키지 내에서도 sqlalchemy2-stubs를 설치해야 하나 고민했습니다. 하지만, 패키지 내의 dependecy 설정으로도 에러는 해결되지 않았습니다. 결국 sqlalchemy2-stubs 자체보다는 타입 인식 자체가 잘 안되는 이유를 찾아야 했습니다. Solution 실제로 문제의 해결은 py.typed 파일의 존재 유무에 있었습니다. 문제가 되었던 패키지의 디렉토리 구조는 다음과 같았습니다. |- project-core |- dist |- project_core |- __init__.py |- package_content... |- __init__.py |- pyproject.toml 그리고 실제 패키지 내용에 해당하는 디렉토리 내의 최상단에 내용이 비어있는 py.typed 파일을 수동으로 생성해주면, mypy가 패키지 코드의 type annotation을 인식하기 시작합니다. |- project-core |- dist |- project_core |- py.typed |- __init__.py |- package_content... |- __init__.py |- pyproject.toml 패키지와 관련된 type checking 수단을 제안하는 PEP-561에도 py.typed에 대한 내용이 명시되어 있습니다. (poetry 뿐만 아니라 범용적으로 적용됩니다.) 우선 지금 문제 상황은 3번에 해당할 것입니다. 즉, package maintainer(패키지 관리자)가 자신의 패키지 코드에 외부의 stub file이 적용되길 원하는 경우입니다. (여기서 stub은 type information만이 담긴 파일을 의미합니다.) 이에 따라, 현재 서비스의 sqlalchemy2-stubs가 패키지에도 적용되길 원합니다. PEP-581은 이를 위해 패키지 관리자가 package의 top-level에 py.typed라는 marker file을 생성해야 함을 전달합니다. (MUST) 사실 문제를 해결하는 다른 방법도 존재하겠지만(MYPYPATH에 site-packages를 추가하는 방법 등…), 간단하고 편한 방법이 있으니 굳이 사용하지 않을 이유가 없을 것 같습니다. Outro 아직 package를 만들어 본 경험이 없었는데, 덕분에 package 빌드 방법에 조금 더 익숙해진 것 같습니다. 이와 더불어 package를 올바르게 배포하기 위해 다양한 요소들이 필요함을 느꼈습니다. 익숙함이 쌓이다보면 언젠가 작은 오픈소스를 배포하는 날도 오지 않을까 기대되네요 :) 결론입니다. Typed package에는 항상 py.typed를 추가해주세요!! Reference Don’t forget py.typed for your typed Python package PEP-581 Packaging Type Information

Blog · 2022-05-16

NFT overview

NFT란? Non-Fungible Token의 약자로 다른 것과 대체 불가능한 토큰을 뜻합니다. 예를 들어, 돈의 경우 내가 가진 1000원은 다른 사람이 가진 1000원과 동일한 가치를 지니므로 대체 가능합니다. 반면, 나의 강아지와 다른 사람의 강아지는 동일한 경제적, 정서적 가치를 가지고 대체될 수 없습니다. 즉, NFT는 디지털 컨텐츠의 고유성 및 원본임을 증명해주는데 주 목적을 둡니다. 또한, NFT는 블록체인에 저장되어 있어서 누가 언제 해당 토큰을 소유했는지 전부 기록됩니다. 따라서, 이전에는 불가능했던 디지털 자산의 소유권을 입증하는 것도 가능해집니다. NFT의 특징 NFT를 사는 것은 컨텐츠를 사는 것이 아니라 컨텐츠로 연결된 데이터를 사는 것입니다. NFT는 소유자가 아니더라도 누구나 열람 가능합니다. NFT는 소유자가 아니더라도 누구나 저장할 수 있습니다. 구매한 NFT는 재판매할 수 있습니다. NFT의 장점과 단점 Pros 자신의 명망과 취향을 자랑하고 싶은 사람들의 Ego를 충족시킬 수 있습니다. 트위터 역시 NFT를 자랑할 수 있는 탭을 만들 예정입니다. 프로필 이미지도 NFT로 만들고 블록체인 검증 체크 마크를 보여줘서, 절대 유일한 프로필 사진을 가질 수 있게 해줄 계획입니다. Provenance(프로비넌스) 해당 예술작품을 소장한 오너들의 기록을 말합니다. 명망있는 사람이 소유한 적이 있다면, 그 사실 자체가 예술작품의 가치 상승에 반영되기도 합니다. NFT 덕분에 소유자의 기록이 모두 기록되어 누구나 확인이 가능합니다. Cons 가치가 크게 변동되는 시장으로 인해, 투기꾼들이 몰리다보니 이미지 자체도 하락합니다. 막대한 전기를 소모하여 환경 오염을 촉발시킵니다. NFT에 Contents를 삽입하는 방법 NFT 토큰을 만드는 큰 그림 두 가지 기능을 가진 Smart contract 만들기 돈을 받는 기능 (이더나 달러를 받으면) 토큰을 전송하는 기능 (1개의 토큰을 줄게) 해당 토큰은 1개의 유일한 토큰이 됩니다. 그리고 1개의 유일한 토큰에 이미지, 영상, 전세 계약 등을 심으면 NFT가 됩니다. 용어 ERC721: NFT의 스탠다드. ERC 20에 토큰 ID, 메타데이터 JSON 파일이 추가된 형태 토큰 ID: NFT에 붙는 개별 식별 번호 메타데이터 JSON: NFT에 넣을 정보 및 컨텐츠가 담기는 그릇 IPFS: 위변조가 불가능한 어찌보면 블록체인과 비슷한 분산 저장소 (모든 정보를 블록체인에 담기는 비싸므로 IPFS를 항상 함께 사용함) 실제 과정 원하는 컨텐츠(이미지, 영상 등)을 IPFS 올리고 hash 값을 받습니다. 메타데이터 JSON에 hash 값을 삽입합니다. 해당 메타데이터 JSON을 IPFS에 올리고 hash 값을 받습니다. ERC721 민터 코드를 디플로이합니다. (코인을 내고 블록체인에 올립니다) NFT를 민트합니다. (코인을 내고 NFT를 발행합니다, json hash값 주소와 wallet 주소도 적용) NFT 전송 과정 NFT를 manually하게 구매 및 판매할 때 지갑을 설치합니다. (Ethereum 기준으로 MetaMask wallet을 설치합니다.) MetaMask Mobile app을 엽니다. (NFT 거래는 아직 모바일에서만 가능합니다.) NFT 탭에서 보내길 원하는 NFT를 고릅니다. 상대방의 Ethereum 주소를 입력합니다. Transaction (gas) fee를 지불합니다. Etherscan을 통해 Ethereum 블록체인에서 해당 transaction을 등록합니다. NFT를 manually하게 구매할 때 판매자에게 MetaMask wallet 주소를 보냅니다. 판매자가 NFT를 전송했다면, transaction ID 전달도 함께 요청합니다. Etherscan과 transaction ID를 통해 해당 transaction이 정상적으로 확인되면, 정식적으로 구매한 NFT의 소유주가 됩니다. 다만, NFT 마켓플레이스를 이용하는 것이 보다 안전하게 구매하는 방법일 것입니다. Opensea에서 판매자는 입력폼에 컨텐츠를 첨부하고 가격을 정한 후, 트랜잭션 수수료를 내면 해당 컨텐츠를 NFT로 만들어 판매할 수 있습니다. OpenSea에서 구매자는 원하는 NFT를 골라 MetaMask로 NFT 가격과 gas fee 지불하면 해당 NFT를 구매할 수 있습니다. Reference How to Transfer an NFT: Step by Step Guide to Do it Right NFT 광풍? 혁신일까, 마케팅일까? 개발자가 정리해드림.

General · 2022-01-31

서버에서 JWT를 안전하게 발급하는 방법은 무엇일까?

Intro 이전 개인 프로젝트에서 JWT로 로그인을 구현할 때, access token을 response body에 담아 보낸 기억이 있습니다. 사실 httpOnly 쿠키로 보내려고 했지만, 그 때는 서버에서 전달받은 쿠키를 프론트에서 어떻게 사용해야 할지 방법을 찾지 못해 불가피하게 이용한 방법이었습니다. (여러 JWT 인증 예제에서 request body로 access token을 보내는 경우가 심심치 않게 보인 점도 한 몫했습니다.) JWT의 access token은 서버에서 httpOnly로 보내는게 무조건 옳은 것일까? 프론트에서는 httpOnly로 받은 access token을 어떻게 처리할까? Response body로 보냈을 때 생기는 문제는 무엇일까? 해결하지 못한 고민들은 계속 남아 맴돌기에, 이번 기회에 가볍게 정리해보고자 합니다. XSS(=CSS), CSRF(=XSRF) 먼저, JWT에서 주요하게 이슈가되는 기본적인 보안 문제는 XSS와 CSRF 공격입니다. 따라서, 단순하게는 XSS와 CSRF를 막는 방식으로 접근하는 편이 바람직해보입니다. XSS(=Cross Site Scripting) 해커가 JS같은 스크립트 코드를 URL 혹은 Input에 악의적으로 삽입해 피해자의 웹브라우저에서 실행시키는 공격을 말합니다. 피해자의 브라우저에 저장된 중요한 정보들을 빼내올 수 있습니다. CSS가 이미 약자로 있기 때문에, XSS라고 더 많이 불리는 것 같습니다. 보통 중요한 데이터를 전송할 때 httpOnly 쿠키를 사용하면, XSS 공격을 막을 수 있습니다. CSRF(=Cross Site Request Forgery) 해커가 정상적인 request를 가로채 피해자인척하고 변조된 request를 서버에 보내, 서버에서 악의적인 동작을 수행하도록 만드는 공격을 말합니다. 피해자의 개인정보가 수정 및 유출, 원치 않는 광고성 포스팅 작성 등의 피해가 있을 수 있습니다. 프론트와 httpOnly 쿠키 옵션 서버에서 쿠키를 설정할 때 (set_cookie) httpOnly 옵션을 줄 수 있습니다. 서버에서 httpOnly를 적용해 쿠키로 보낸 값들은 클라이언트에서 직접 접근이 불가능합니다. (document.cookie로 접근 불가능) 다만, 이후 request를 할 때마다 해당 쿠키가 자동으로 쿠키 헤더에 담겨 request와 함께 보내집니다. httpOnly는 JS로 쿠키에 접근할 수 없으므로, XSS 공격을 막을 수 있습니다. 반면에, 매 request마다 자동으로 쿠키 헤더에 담겨 보내지는 특징 때문에 CSRF 공격에 취약점을 가질 수 있습니다. Secure 쿠키 옵션 Secure은 클라이언트 혹은 서버에서 https에서만 쿠키를 전송할 수 있도록 허용하는 옵션입니다. httpOnly는 클라이언트에서 JS를 통한 탈취 문제는 해결할 수 있지만, 네트워크를 직접 감청하여 쿠키를 가로채는 공격을 막을 수 없습니다. 특히, http에서는 데이터가 암호화되지 않고 전달되기 때문에, request나 response가 중간에 탈취당하면 그대로 데이터를 노출하게 됩니다. 따라서, 데이터가 암호화되어 보내지는 https에서만 통신 가능하도록 secure 옵션을 설정할 필요가 있습니다. JWT를 발급하는 경우의 수 경우의 수는 refresh token과 access token을 모두 사용하는 것을 기준으로 고려합니다. Case 1 - refresh token, access token을 모두 httpOnly 쿠키로 보내기 access token을 httpOnly 쿠키 헤더로 보내면, XSS 공격을 충분히 막을 수 있습니다. httpOnly이기 때문에, 프론트에서 JS를 통해 쿠키에 접근할 수 없고 해커도 이를 이용할 수 없습니다. refresh token도 마찬가지입니다. 반면 CSRF에 취약합니다. Request에 access token이 항상 자동으로 담겨 보내지므로, request를 위조하는 CSRF를 막기 어렵습니다. refresh token도 마찬가지입니다. Case 2 - refresh token은 httpOnly 쿠키로, access token은 response body로 보내기 access token은 프론트에서 클로저 등을 통해 private variable로 저장하고 관리합니다. 이 때, XSS, CSRF 문제는 없어집니다. 혹시나 https 이외의 통신이라면 response body의 중간 탈취 위험은 있을 수 있지만, refresh token은 탈취되지 않기 때문에 유효 기간이 짧은 access token만 탈취되고 이후 갱신은 어려울 것입니다. 다만, 새로고침이 일어날 때마다 access token이 휘발성으로 사라지기 때문에, refresh token으로 새로운 access token을 발급받아야 합니다. (access token 유효기간의 의미가 사라지는 것 같기도…) refresh token의 경우 httpOnly이므로 XSS 공격 문제가 없습니다. Request에 refresh token이 항상 자동으로 담겨 보내지지만, CSRF를 시도해도 해커는 access token을 알 수 없습니다. 해커가 refresh token을 사용해 새로운 access token을 서버에 요청할 수는 있어도, response body로 날라오는 access token은 해커가 아닌 사용자에게로 갈 뿐입니다. Case 3 - refresh token, access token을 모두 response body로 보내기 access token과 refresh token을 프론트에서 클로저 등을 통해 private variable로 저장하고 관리합니다. 새로고침이 일어날 때마다 refresh token과 access token이 사라지므로, 로그인 유지가 되지 않습니다. 즉, XSS, CSRF 공격 위험과 멀어지지만 로그인 기능과도 멀어(?)집니다. 만일 https 이외의 통신이라면, access token 뿐만 아니라 refresh token까지 탈취당하여 더 오랜 기간동안 위험할 수 있습니다. Outro 결론적으로 위 Case 중에서는 Case 2가 보안상으로 가장 best한 방법으로 생각됩니다. 다만, 새로고침 시 access token이 유지되지 않는 점에서 다시 cookie의 필요성이 생각나는 무언가 아쉬운 부분이 느껴집니다. 이 포스팅은 더 좋은 방법을 알게될 때마다 계속 업데이트해 나가야 할 것 같습니다 :) Reference JWT는 어디에 저장해야할까? - localStorage vs cookie 프론트에서 안전하게 로그인 처리하기 (ft. React) 01. 시큐리티 - HTTP Only 와 Secure Cookie

Blog · 2022-01-31

WSL2로 Windows에서 Linux 사용하기

Intro Windows는 멋진 OS입니다. Windows 덕분에 개발의 첫 발자국을 뗄 수 있던 사람은 아주 많을 것입니다! 다만, Windows 환경에서 개발을 진행하다보면, 생각치 못한 에러를 마주칠 때가 참 많습니다. 특히 Mac OS 환경에서는 자연스럽게 넘어가던 일들이 왕왕 막힐 때는, 고구마 5개가 식도에 함께하는 기분을 느끼게 됩니다(?) 이러한 참사를 막기 위해, Windows 위에서 리눅스를 매끄럽게 사용할 수 있게 도와주는 WSL2가 존재합니다. WSL2란? WSL은 Windows Subsystem for Linux 2의 줄임말로, 윈도우의 가상화 기능을 활용해서 윈도우 위에서 리눅스를 사용할 수 있게해줍니다. 단순히 가상머신으로 리눅스를 사용할 수 있는 것이 아니라, 윈도우 시스템과 통합되어 마치 하나의 머신처럼 자연스럽게 리눅스를 활용하는 것이 가능합니다. - LainyZine: 프로그래머 가이드 Requirements Windows 10 버전 요구사항: 20H1 이상 Windows 사양 확인 Windows + S 키로 검색 탭을 열어 PC 정보를 검색합니다. PC 정보의 아래 쪽에 Windows 사양 부분에서 버전을 확인합니다. 현재 20H1, 20H2, 21H1 등에서 WSL 사용이 지원됩니다. WSL2 활성화 및 Ubuntu 설치 WSL2 설치를 위해 가상 터미널을 이용합니다. 이 때, 가상 터미널로 Windows Terminal을 설치해 사용하면 이후 WSL 사용도 편리해집니다. 없을 시엔 Windows PowerShell을 사용합시다. Windows + S 키로 Windows Terminal이나 PowerShell을 검색한 후, 우 클릭하여 ‘관리자 권한으로 실행’을 클릭합니다. 다음 명령어를 실행해 WSL 기능을 활성화합니다. dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart Microsoft Store에 들어가 원하는 버전의 Ubuntu를 설치합니다. 활성화 적용을 위해 컴퓨터를 재시작합니다. 다운받은 Ubuntu를 실행하고 설치 완료 메시지까지 약간 기다립니다. 계정 정보 입력 메시지가 뜨면, 새로운 Ubuntu OS에 대한 새로운 계정을 만듭니다. (기존 Windows 정보와 전혀 상관없이 새 계정을 만들면 됩니다.) 이후, 다음 명령어를 사용해 활성화 되어 있는 WSL을 WSL2로 업데이트합니다. (관리자 권한 실행) dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart 컴퓨터를 재시작합니다. 다음 명령어를 사용해 WSL2를 기본 버전으로 설정합니다. (관리자 권한 실행) wsl --set-default-version 2 만일 커널 구성요소를 다운로드하라는 메시지가 나오면, 해당 링크로 가서 커널 업데이트 패키지를 다운로드 받아 install하고 다시 wsl --set-default-version 2 명령어를 실행합니다. 다음 명령어를 사용해, WSL에게 Ubuntu에 WSL2를 사용할 것이라는 것을 알려줍니다. wsl --list --verbose를 통해 현재 설치된 ubuntu의 버전을 확인할 수 있습니다. wsl -l -v로 현재 설치된 리눅스를 확인해볼 수 있습니다. wsl --set-version Ubuntu-18.04 2식으로 명령을 실행합니다. 혹시 BIOS에서 가상화가 사용가능하도록 설정하라는 메시지가 뜨면, 구글 검색을 통해 가상화 설정을 진행하고 다시 명령어를 실행합시다. Customizing Linux Shell WSL2을 통한 Ubuntu의 초기 리눅스 쉘 상태는 굉장히 ugly합니다. 따라서, 몇 가지 기본세팅이나 UI 적용을 통해 보다 깔끔한 터미널을 만드는 것도 매우 좋을 것입니다. 다음 링크에서 원하는 customizing을 참고하시길 바랍니다. Nomad Coder WSL Setup Outro Windows 환경에서 개발함에 있어 WSL2는 단비 같은 툴입니다. 개발에만 집중하기도 모자른 시간을 환경적 에러에서 소모할 필요는 없습니다. 그렇지만 Windows라고 개발에서 배제(?)될 필요도 없습니다. 다만, Windows를 쓰시는 개발자라면 WSL2로 초기 환경을 세팅하고 개발하시길 권합니다 :) Reference Nomad Coder WSL Setup LainyZine: 프로그래머 가이드

Blog · 2022-01-31

SQLAlchemy 기본

SQLAlchemy 동기 지원 모듈: sqlalchemy create_engine (데이터베이스 엔진) Session (세션) sessionmaker (세션 팩토리) ORM Setting 기본 단계 DB engine 생성 및 접속 세션 정의 및 생성 테이블 초기 생성 Session을 만드는 2가지 방법 Session 객체를 직접 생성 사용 코드 def get_db(): db = Session(bind=engine) try: yield db finally: db.close() FastAPI의 Depends(get_db)를 통해 의존성 주입하면 편리 Session 팩토리 사용 코드 SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine) db = SessionLocal() db.close() - 사용 후에는 직접 끊어줘야 함 sessionmaker 옵션 autocommit 세션 작업 후 자동으로 커밋되도록 활성화 False로 두고 명시적으로 커밋하는게 좋음 autoflush 트랜잭션 안에서 바로바로 데이터 반영 시킬지 여부 예를 들어, DB에 100개의 데이터가 있는데 현재 트랜잭션 내에서 insert 쿼리 후 count 쿼리를 날리면, autoflush가 true일 때 101개 결과를 반환 과거 방식이기도 하고, False가 바람직 테이블 초기 생성 Base.metadata.create_all(bind=engine) 조회 Syntax 모든 컬럼 조회 db.query("TableObjectName") = SELECT * FROM TableName e.g. db.query(User) 특정 컬럼 조회 db.query("TableObjectName.columnname") = SELECT columnname FROM TableName e.g. db.query(User.email) WHERE절 filter e.g. filter(User.nickname == 'veluga') filter_by e.g. filter_by(nickname="john") AND & OR AND e.g. filter("조건").filter("조건") e.g. filter("조건", "조건") OR or_을 임포트해 사용 from sqlalchemy import or_ e.g. filter(or_(User.username == "veluga", User.id == 1)) 정렬 오름차순 정렬 order_by(User.id) 내림차순 정렬 from sqlalchemy import desc order_by(desc(User.id)) 조회 실행 (쿼리 실행) 단건 조회 first() 결과가 여러 개면 그 중 첫 번째 리턴 없을 경우 None 반환 one() 결과가 여러 개거나 없을 경우 에러 scalar() 결과가 여러 개일 경우 에러 없을 경우 None 반환 복수 리스트 조회 all() scalars() 조회 결과의 개수 반환 count() 그룹화 및 집계 함수 사용 패턴 func에서 원하는 집계함수 사용 (count, sum, max, min…) from sqlalchemy import func db.query(func.count(User.id).label('total')).group_by(User.id).all() 삭제 Syntax db.delete("조회한 모델 객체") db.commit() Reference 2.0 style query 결과 가져오기 총 정리 (한 개 또는 여러 개) SQLAlchemy 1.x 와 2.0의 Query 스타일 비교

Python-Ecosystem · 2022-01-28

Python zoneinfo - UTC 시간대를 더욱 쉽게 적용합시다!

이전에 python에서 UTC 시간대를 적용할 때는 pytz 라이브러리가 주로 사용되었습니다. 특히 aware 타입과 naive 타입을 비교하기 어렵기 때문에, pytz를 사용해 datetime 객체를 aware 타입으로 바꾸고 비교하는 것은 매우 유용했습니다. (aware 타입은 timezone 정보가 포함된 datetime이고 naive 타입은 timezone 정보가 포함되지 않은 datetime입니다.) 그러나 pytz는 2018년 서울과 평양시간을 UTC+9 시간이 아닌 UTC+08:30으로 표현하는 버그, 실수를 유발할 수 있는 사용 방법 등 이슈도 공존했습니다. 이를 보완하기 위해, Python은 3.9 버전부터 표준 라이브러리로 zoneinfo 모듈을 제공합니다. 덕분에, 따로 pytz를 인스톨하지 않고도 datetime에 쉽게 원하는 시간대를 적용할 수 있습니다. Python official document - zoneinfo https://docs.python.org/ko/3/library/zoneinfo.html ZoneInfo 클래스 ZoneInfo(key: str) ZoneInfo는 key를 생성자의 인자로 받는 클래스입니다. 예를 들어, “America/New_York”, “Europe/London”를 key로 던지면, 해당 시간대 정보를 가지는 인스턴스를 생성합니다. 시간대 적용은 이 인스턴스를 활용합니다. 현재 시간에 ZoneInfo 적용하기 from zoneinfo import ZoneInfo from datetime import datetime dt = datetime.now(ZoneInfo('UTC')) # datetime.now(tz=ZoneInfo('UTC'))와 동일 print(dt) # 2022-01-09 11:05:40.133971+00:00 zoneinfo는 기존 datetime 객체에 그대로 적용할 수 있습니다. UTC 시간대를 적용한 현재 시간을 알고 싶다면, datetime.now(ZoneInfo('UTC'))을 사용합니다.(datetime.now(tz=ZoneInfo('UTC'))와 동일합니다.) 반환된 dt는 aware 타입 객체가 될 것입니다. dt = datetime.now(ZoneInfo('Asia/Seoul')) print(dt) # 2022-01-09 20:05:40.133971+09:00 서울의 시간대로 현재 시간을 알고 싶다면, ZoneInfo의 인자로 ‘Asia/Seoul’ key를 적용합니다. 임의의 datetime에 ZoneInfo 적용하기 from zoneinfo import ZoneInfo from datetime import datetime, timedelta dt = datetime(2020, 10, 31, 12, tzinfo=ZoneInfo("America/Los_Angeles")) print(dt) # 2020-10-31 12:00:00-07:00 원하는 시간에 ZoneInfo를 적용하고 싶다면, datetime의 tzinfo에 ZoneInfo 정보를 줍시다. dt_add = dt + timedelta(days=1) print(dt_add) # 2020-11-01 12:00:00-08:00 datetime끼리의 연산 역시 summer time을 고려해 알아서 계산됩니다. Windows와 tzdata zoneinfo는 Python의 표준 라이브러리에 포함되기 때문에, 따로 인스톨없이 사용할 수 있습니다. 다만, 윈도우의 경우 zoneinfo 모듈을 사용할 때 다음과 같은 에러가 발생할 수 있습니다. ModuleNotFoundError: No module named ‘tzdata’ zoneinfo는 기본적으로 시스템의 시간대 데이터를 사용합니다. 하지만, 윈도우는 시간대를 다루는 시스템이 다른 OS와 조금 달라서, zoneinfo와 호환되지 않는다고 합니다. (PEP 615) However, not all systems ship a publicly accessible time zone database — notably Windows uses a different system for managing time zones — and so if available zoneinfo falls back to an installable first-party package, tzdata, available on PyPI. [d] If no system zoneinfo files are found but tzdata is installed, the primary ZoneInfo constructor will use tzdata as the time zone source. - Sources for time zone data (PEP 615) 이 때는, CPython 핵심 개발자가 유지 보수하는 first-party 패키지인 tzdata를 인스톨합시다. (pip install tzdata) zoneinfo는 참고할 수 있는 시간대 데이터가 없을 시 자동으로 tzdata를 시간대 데이터로 사용하므로, 인스톨 시 문제가 해결됩니다. 개발 시 최대한 신뢰할 수 있는 라이브러리를 사용하고 이외의 라이브러리에 대한 의존성을 줄일 필요가 있습니다. 고마웠던 pytz지만, 가능하다면 표준 라이브러리에 포함된 zoneinfo 사용을 지향해봐야겠습니다. Reference Python 3.10 document - zoneinfo PEP 615 - Support for the IANA Time Zone Database in the Standard Library PYTHON 3.9에 등장한 상큼한 8가지 FEATURES 평양 및 서울의 timezone관련 pytz 이슈

Python-Ecosystem · 2022-01-09

TypeScript basic - Advanced Object

Interface 타입스크립트에서 타입을 정의하는 방법은 다양합니다. type Mail = { postagePrice: number; address: string; } const catalog: Mail = ... 기존처럼 type을 사용해 정의할 수도 있습니다. interface Mail { postagePrice: number; address: string; } const catalog: Mail = ... 그런데 타입스크립트에서 객체의 타입을 정의하는데 자주 사용되는 또 하나의 방법은 interface를 사용하는 것입니다. type과 interface는 문법적인 측면에서 = 사용의 차이가 있지만, 타입을 강제하는 기능은 동일합니다. 그렇다면 interface는 어디에 사용하는 것일까요? type은 object 뿐만 아니라 primitive 타입을 포함한 모든 타입을 정의하는데 사용할 수 있는 반면, interface는 object 타입 정의에만 사용할 수 있습니다. 마치 설계도와 같은 느낌이 녹아 있는 interface는 제약이 있다는 점에서 코드를 일관성 있게 작성하도록 도와주기 때문에, 객체 지향 프로그램을 작성할 때는 interface를 주로 사용합니다. Interfaces and class Interface와 class는 궁합이 잘 맞습니다. Interface는 object의 타입을 정의하는 키워드이고 class는 object로 프로그래밍하는 방법이기 때문입니다. interface Robot { identify: (id: number) => void; } class OneSeries implements Robot { identify(id: number) { console.log(`beep! I'm ${id.toFixed(2)}.`); } answerQuestion() { console.log('42!'); } } interface는 class / object에 타입을 적용할 수 있습니다. 특히, class에 타입을 적용할 때에는 implements 키워드를 사용합니다. 위 코드는 OneSeries 클래스에 implements 키워드를 사용해 Robot 타입을 적용하는 과정입니다. Robot 타입이 적용된 OneSeries는 인터페이스에 명시된 대로 identify 메서드를 가져야 하며, 명시된 것만 지켰다면 이외로 추가적인 answerQuestion 메서드를 가지는 것도 가능합니다. Deep nested type class OneSeries implements Robot { about; constructor(props: { general: { id: number; name: string; } }) { this.about = props; } getRobotId() { return `ID: ${this.about.general.id}`; } } Class OneSeries는 nested된 object 타입을 가지는 about 프로퍼티와 getRobotId 메서드를 가집니다. 이러한 nested된 object 타입을 표현하고 싶다면, interface Robot은 다음과 같이 작성하면 됩니다. interface Robot { about: { general: { id: number; name: string; }; }; getRobotId: () => string; } 타입스크립트는 무한히 nested된 object 타입을 표현할 수 있습니다! 타입 구성 분리하기 interface About { general: { id: number; name: string; version: { versionNumber: number; } } } 위와 같이 더욱 깊게 nested되는 object 타입일수록 가독성은 떨어집니다. 또한, About 타입에서도 version만 필요한 상황이 있을 수 있습니다. 따라서, 일정한 정도로 각각 따로 interface를 만들어 함께 사용하는 것이 효과적일 수 있습니다. interface About { general: General; } interface General { id: number; name: string; version: Version; } interface Version { versionNumber: number; } 앞선 복잡했던 interface 코드를 가독성 높은 재사용가능한 코드로 변형했습니다. 코드는 조금 길어졌지만, 더욱 큰 프로그램에서는 이러한 형태로 코드를 작성하는 것이 훨씬 유리합니다. Extending interface 때때로 어떤 타입의 모든 프로퍼티와 메서드들을 복사해서 다른 타입에 가져와야 할 때도 있습니다. 이 때 extends가 유용합니다. interface Shape { color: string; } interface Square extends Shape { sideLength: number; } const mySquare: Square = { sideLength: 10, color: 'blue' }; Square는 extends 키워드를 사용해 Shape의 모든 프로퍼티를 복사해서 가져옵니다. 실제로 mySquare에서는 sideLength 프로퍼티 뿐만 아니라 color 프로퍼티를 가져도 에러가 나지 않습니다. Index signature 외부의 API나 소스로부터 데이터를 받아오는 경우, 특정 객체의 프로퍼티 이름이 정확히 무엇인지 알 수 없는 상황이 생깁니다. 이 때, 해당 프로퍼티들을 받는 변수를 임의의 이름으로 하나 설정해 처리할 수 있습니다. 이를 index signature라고 합니다. { '40.712776': true; '41.203323': true; '40.417286': false; } 예를 들어, 위와 같은 데이터를 map API query에 대한 response로 받았다고 가정해봅시다. String 타입으로 이루어진 각각의 프로퍼티들은 위도를 나타냅니다. 다만, 이러한 프로퍼티들은 개발자 입장에서 정확히 이름을 알기가 어렵습니다. interface SolarEclipse { [latitude: string]: boolean; } 따라서, 위와 같이 [latitude: string]라는 index signature를 정의해주면, response로 받는 데이터에 존재하는 모든 프로퍼티들의 타입을 하나로 정의할 수 있습니다. 위의 경우 모든 프로퍼티의 이름은 string 타입으로, 그 값은 boolean 타입으로 정의됩니다. latitude는 개발자가 임의로 설정한 이름임을 유의합니다. Optional type member 어떤 함수나 클래스를 만들 때, optional argument 설정은 자유롭습니다. 이는 interface로 타입을 정의할 때도 마찬가지입니다. interface에서도 타입 멤버들에 대해 optional 속성을 설정해 줄 수 있습니다. interface OptionsType { name: string; size?: string; } function listFile(options: OptionsType) { let fileName = options.name; if (options.size) { fileName = `${fileName}: ${options.size}`; } return fileName; } 위의 size 프로퍼티는 optional한 프로퍼티입니다. 프로퍼티 이름과 :사이에 ?가 존재한다면, 해당 프로퍼티는 optional 프로퍼티로 간주됩니다. 따라서, 위 코드에서는 size 프로퍼티를 사용하기 전에 if (options.size) 조건문을 사용해 size 프로퍼티의 존재 여부를 먼저 확인하고 사용해야 합니다. listFile({ name: 'readme.txt' }) size 프로퍼티가 optional하기 때문에, 위와 같이 size 프로퍼티가 없는 객체를 인자로 사용해도 에러를 일으키지 않습니다. Reference Codecademy - TypeScript

JavaScript-Ecosystem · 2021-10-16

TypeScript basic - Type Narrowing

Type narrowing 타입스크립트는 자신의 소스코드를 자바스크립트 코드로 컴파일하는 단계에서, 타입 체크를 하여 개발자에게 알림을 줍니다. 이러한 컴파일 단계에서의 타입 체크는 매우 유용합니다. 그러나 타입스크립트는 더 많은 것을 제공해줄 능력이 있습니다. 타입스크립트는 코드의 주변 맥락을 확인하여 런타임시 어떻게 동작할지 파악하고, 이에 따라 변수의 구체적인 타입을 추론하여 알려줍니다! 이를 type narrowing이라고 합니다. 특히, 변수가 union을 통해 다양한 타입의 가능성을 내재하고 있을 때, type narrowing은 빛을 발합니다. function formatDate(date: string | number) { // date can be a number or string here if (typeof date === 'string') { // date must be a string here } } 위와 같은 코드에서 date 인자는 string 타입도 number 타입도 가능합니다. 이 때, if (typeof date === 'string')같은 type guard를 사용해 각각의 타입마다 따로 로직을 만들어 type narrowing 할 수 있습니다. 이는 타입스크립트의 런타임 코드 실행 맥락 파악을 통한 타입 추론 능력 덕분입니다! Type guard function formatDate(date: string | number) { // date can be a number or string here if (typeof date === 'string') { // date must be a string type } } 타입스크립트의 type narrowing은 type guard를 통해 진행됩니다. Type guard는 변수의 구체적인 타입을 체크하는 표현식을 가리킵니다. 일반적으로 typeof가 많이 활용됩니다. 위에서 if (typeof date === 'string') 부분이 type guard에 해당됩니다. in as type guard 때때로 특정 프로퍼티 혹은 메서드가 해당 타입에 존재하는지 확인하고 싶은 경우가 있습니다. 이 때, in operator를 사용할 수 있습니다. in은 특정 프로퍼티가 객체 자체에 혹은 해당 객체의 프로토타입 체인 내에 존재하는지 확인해줍니다. type Tennis = { serve: () => void; } type Soccer = { kick: () => void; } function play(sport: Tennis | Soccer) { if ('serve' in sport) { return sport.serve(); } if ('kick' in sport) { return sport.kick(); } } 그리고 in은 type guard로서 사용할 수 있습니다. 위의 if ('serve' in sport)에서는 특정 프로퍼티에 존재 여부가 타입스크립트에게 단서를 주어 type narrowing이 이루어집니다. 위 코드의 경우, 만일 'serve'가 sport에 존재한다면, sport는 Tennis 타입일 것이 확정되기 때문에 if ('serve' in sport) 구문 내에서는 sport를 Tennis 타입 변수로 간주하고 코드를 짜도 무방합니다. 즉, 타입스크립트가 에러를 띄우지 않습니다. Narrowing with else 만일 if 조건문이 type guard로 쓰였다면, 이에 대응하는 else 문은 if 문과 정확히 반대되는 type guard로서 기능합니다. 즉, if 문에서 체크한 타입 이외의 가능한 타입들은 모두 else 문에서 고려하게 됩니다. function formatPadding(padding: string | number) { if (typeof padding === 'string') { return padding.toLowerCase(); } else { return `${padding}px`; } } 예를 들어, 위 if 문에서 string 타입에 대한 로직을 작성했기 때문에, else 문은 number 타입에 대한 로직을 자동으로 담당하게 됩니다. Narrowing After a Type Guard 사실 else 문을 사용하지 않아도 else 문과 똑같은 type narrowing을 사용할 수 있습니다. Type guard인 if 문이 끝난 이후 나오는 코드들은 나머지 가능한 타입들에 대한 코드로 자동으로 상정됩니다. type Tea = { steep: () => string; } type Coffee = { pourOver: () => string; } function brew(beverage: Coffee | Tea) { if ('steep' in beverage) { return beverage.steep(); } return beverage.pourOver(); } 예를 들어, 위의 if 문 내에서는 beverage가 Tea 타입을 가질 것입니다. 반면, if 문이 끝나고 나온 return beverage.pourOver(); 코드에서는 beverage가 당연히 Coffee 타입일 것이기 때문에, 타입스크립트는 오류를 내지 않습니다. Reference Codecademy - TypeScript

JavaScript-Ecosystem · 2021-10-15

TypeScript basic - Union

Union 타입스크립트는 변수마다 다른 단계의 타입 구체성을 부여할 수 있습니다. 예를 들어, 변수에 string 타입을 강제하면 해당 변수는 string 타입으로 매우 제한적인 타이핑을 가지게 됩니다. 반면에, any를 부여하면 해당 변수는 특정 타입에 제한되지 않는 매우 자유로운 타이핑을 가지게 됩니다. Union 타입은 이러한 두 극단의 타이핑에서 중간을 찾아가는 방법입니다. union은 서로 다른 타입들을 원하는대로 조합하여 만든 것을 의미합니다. 예를 들어, 회사원의 ID를 저장할 때, ID는 string 혹은 number가 모두 올 수 있습니다. 다만, 이를 any로 받기에는 너무 광범위하기 때문에, union을 사용해 원하는 타이핑 범위를 조절하는 것이 효과적입니다. Union 정의 Union은 |을 사용해 원하는 type 멤버들을 하나하나 함께 정의합니다. let ID: string | number; // number ID = 1; // or string ID = '001'; console.log(`The ID is ${ID}.`); 위 코드에서 ID는 string 혹은 number 값의 할당이 모두 허용됩니다. 이러한 union 타입은 함수의 파라미터를 포함해 어디서든 사용할 수 있습니다. function getMarginLeft(margin: string | number) { return { 'marginLeft': margin }; } 예를 들어, 함수의 파라미터에서는 위와 같이 union을 정의해주면 됩니다. Type narrowing with type guard Union을 사용하다보면, 코드의 특정 지점에서 union으로 type annotation된 변수의 타입이 모호해지는 경우가 발생합니다. function getMarginLeft(margin: string | number) { // ... } 예를 들어, 함수 내에서 margin은 string과 number를 동시에 가지기 때문에, string의 메서드를 분별없이 사용하면 타입스크립트 트랜스파일러가 오류를 띄웁니다. 따라서, 다음과 같이 type guard를 사용하여, 해당 지점에서 변수가 string인지 number인지 명확히 표시해주어야 합니다. function getMarginLeft(margin: string | number) { // margin may be a string or number here if (typeof margin === 'string') { // margin must be a string here return margin.toLowerCase(); } } 위의 if 조건문은 type guard라고 부릅니다. 조건문 내에서라면 margin은 반드시 string 타입임이 보장되므로, toLowerCase()와 같은 string 메서드를 써도 에러가 나지 않습니다. 이렇게 type guard를 사용하여 코드 내에서 type을 명확히 하는 것을 type narrowing이라고 합니다. Union을 사용할 때는 type narrowing으로 각각의 타입에 맞는 로직을 분리해 사용하는 것이 필요합니다. Inffered union return type 만일 경우마다 다양한 타입의 값을 리턴하는 함수가 있다면, 타입스크립트는 해당 함수의 return type을 union으로서 판단합니다. function getBook() { try { return getBookFromServer(); } catch (error) { return `Something went wrong: ${error}`; } } 예를 들어, 위 코드에서 getBookFromServer()의 리턴 값의 타입이 Book이라고 합시다. 그러면 함수 getBook은 Book 혹은 string 타입의 값을 리턴할 것입니다. 따라서, 타입스크립트는 getBook의 리턴 타입을 union Book | string으로 추론합니다. Union with array Union 타입은 array와 함께 할 때 더욱 강력해집니다. const dateNumber = new Date().getTime(); // returns a number const dateString = new Date().toString(); // returns a string const timesList: (string | number)[] = [dateNumber, dateString]; 예를 들어, 날짜의 타입으로 number 혹은 string이 올 수있습니다. 이러한 날짜 데이터를 array에 담고 싶다면, 위와 같이 union을 사용해 const timesList: (string | number)[] = [dateNumber, dateString];로 type annotation 해주면 됩니다. 이를 활용하면, 다양한 multiple type을 annotation하여 유연하게 배열을 사용할 수 있습니다. Union with literal type type Color = 'green' | 'yellow' | 'red'; function changeLight(color: Color) { // ... } 프로그램에서 어떠한 구체적으로 구별되는 상태를 만들길 원할 때, literal type을 union을 사용해 만들 수 있습니다. 위와 같이 'green', 'yellow', 'red'라는 리터럴을 사용해 union 타입을 만들면, 'purple'과 같은 인자는 타입스크립트에 의해 validation 됩니다. Reference Codecademy - TypeScript

JavaScript-Ecosystem · 2021-10-14

Next.js basic - 개념 조각 모음

Next.js 주요한 특징들 Static Generation VS Sever-side Rendering VS Client-side Rendering Static Generation HTML이 build time에 pre-rendering되는 방식입니다. 즉, 외부에서 가져오는 데이터들도 build time에 요청하기 때문에 최신 데이터보다는 잘 변하지 않는 데이터들을 처리하기에 적합합니다. 미리 HTML을 생성하기 때문에 SEO에 강점이 있습니다. 또한 미리 한 번 생성된 HTML을 재사용하는 것과 더불어 Sever-side Rendering과 달리 CDN에 캐시되는 덕분에 셋 중에 속도가 가장 빠르며, Next.js에서 가장 권장되는 방법입니다. Sever-side Rendering HTML이 유저로부터 request가 있을 때마다 pre-rendering되는 방식입니다. 즉, 외부에서 가져오는 데이터들이 request 시점에 요청된 데이터들이기 때문에, 최신 데이터들을 사용하기 용이하다는 장점이 있습니다. HTML이 pre-rendering되기 때문에, SEO에 강점이 있으며, Static Generation보다는 느리지만 Client-side Rendering 보다는 빠릅니다. 다만, 사용자 측면에서는 페이지 이동마다 화면이 깜빡거리며 새로고침이 발생하게 됩니다. Client-side Rendering HTML의 pre-rendering 및 외부 데이터 API 요청을 하지 않고, 클라이언트 측에서 자바스크립트 코드로 모든 것을 처리하는 방식입니다. 사용자가 요청한 페이지만 불러온 후, 사용자의 행동에 따라 필요한 부분만 다시 읽어 들이는 single page application 방식으로 동작하게 됩니다. 따라서, 사용자 측면에서 리로딩없이 필요한 부분만 빠르게 인터랙션할 수 있습니다. 다만, 초기 구동 속도가 느리고 SEO가 어렵다는 단점이 있습니다. (구글에서는 Client-side Rendering도 SEO를 잘 할 수 있다고 이야기하지만, Client-side Rendering은 SEO가 잘 안된다는 것이 정설입니다.) 위의 렌더링 방식들은 페이지마다 다르게 적용할 수 있고, 한 페이지 안에서도 부분마다 다르게 적용할 수 있습니다. 예를 들어, 보통 SEO가 가장 잘되어야 하는 부분은 상품 정보 페이지이므로 해당 페이지는 Static Generation이나 Sever-side Rendering으로 처리하는 것이 좋습니다. 또한, 상품 정보 페이지 내에서 title 같은 정보는 잘 변하지 않으므로 Static Generation을 사용하는 것이 좋습니다. 반면에, description이나 keyword 같은 부분들은 A/B Test 등으로 자주 변화를 시도해 볼 수 있기 때문에, Sever-side Rendering을 사용하는 것이 적합합니다. 이외의 데이터와 상관없는 navigation bar나 메뉴 같은 부분들은 Client-side Rendering을 적용해 보다 나은 인터랙션을 제공할 수 있습니다. Static file serving Next.js는 static 파일을 public 디렉토리에서 처리합니다. 그리고 public 폴더 안에 있는 static file들은 base URL을 /로 사용할 수 있습니다. 예를 들어, /public/me.jpg는 /me.jpg로 사용하면 됩니다. Public 디렉토리에 있는 파일들은 빌드 타임에만 서빙되므로, 런타임에 저장되는 파일들은 AWS S3 같은 다른 서드 파티 서비스를 사용해 처리하길 권장합니다. Reference Next.js Document

JavaScript-Ecosystem · 2021-10-14

TypeScript basic - Complex Types

JavaScript-Ecosystem · 2021-10-13

Next.js basic - Pre-rendering

Pre-rendering Pre-rendering은 Next.js의 중요한 특징 중 하나입니다. Next.js는 클라이언트에서 HTML 생성을 모두 처리하기 보다는, 처음에 모든 페이지에 대한 HTML을 미리 생성하는데, 이것을 pre-rendering이라고 합니다. Pre-rendering 덕분에 Next.js는 SEO와 더불어 좋은 성능을 보입니다. Pre-rendering 이후에는 hydration이라는 과정을 거칩니다. Hydration이란 브라우저가 페이지를 로딩할 때, 해당 페이지를 로딩하기 위해 필요한 최소한의 자바스크립트 코드만을 가져와 실행시켜서 미리 생성되어 있는 HTML을 interactive하게 만드는 과정을 말합니다. 만일 순수 리액트 코드로 작성된 애플리케이션의 경우, pre-rendering이 없기 때문에 페이지들의 HTML을 미리 생성하지 않습니다. 그래서 만일 순수 리액트 코드로 이루어진 애플리케이션의 자바스크립트 코드를 disabled 상태로 만든다면, 페이지 자체가 보이지 않게 됩니다. 반면, Next.js가 적용된 애플리케이션은 static HTML이 미리 생성된 덕분에 자바스크립트 기능을 제외한 페이지 자체는 보이게 됩니다. Two forms of pre-rendering Next.js의 pre-rendering은 Static Generation과 Server-side Rendering이라는 두 가지 형태가 존재합니다. 두 형태의 차이점은 언제 페이지에 대한 HTML이 생성되는가에 있습니다. 먼저, Static Generation은 build-time에 HTML을 생성하는 pre-rendering method입니다. 즉, 클라이언트의 request 이전에 HTML이 생성됩니다. 이렇게 pre-rendering된 HTML은 각각의 request에 요청될 때마다 재사용됩니다. Static Generation은 request에 상관없이 내용이 자주 바뀌지 않는 marketing page, blog post, E-commerce product listing, documentation 등에 유용합니다 이와 달리, Server-side Rendering은 각각의 request가 올 때마다 HTML을 생성하는 pre-rendering method입니다. 즉, 클라이언트의 request 후에 HTML이 생성되며, 생성된 HTML은 재사용되지 않습니다. Server-side Rendering은 빈번히 update되는 데이터 혹은 request마다 content가 바뀜으로 인해, request 이전에 pre-render하기 어려운 상황에서 유용합니다. 참고로, 개발자 모드로 서버를 실행했을 때는 모든 페이지가 Server-side Rendering으로 pre-rendering됩니다. 심지어 Static Generation을 사용하는 페이지라고 하더라도 마찬가지입니다. Next.js는 각각의 페이지마다 위의 두 가지 형태 중 어떤 pre-rendering을 사용할지 선택할 수 있습니다. 따라서, Static Generation과 Server-side Rendering 방식이 혼합된 Next.js 애플리케이션을 만들 수 있습니다. 다만, 대부분의 경우에서는 Static Generation이 권장됩니다. 매 request 마다 HTML을 생성해야 하는 Server-side rendering에 비해, 한 번 HTML을 생성하고 재사용하는 Static Generation이 훨씬 빠르기 때문입니다. 만일 항상 최신 상태를 유지해야 하는 데이터를 처리할 경우, 느림을 감안하고서라도 Server-side Rendering을 사용하거나 pre-rendering을 생략하고 Client-side Rendering을 사용하는 것이 적합합니다. Static Generation with and without data Static Generation은 외부 데이터가 필요할 때 혹은 필요하지 않을 때 모두 사용할 수 있습니다. 외부적으로 데이터를 가져오지 않아도 되는 페이지들은 자동으로 Static Generation될 것입니다. 이와 달리, 처음에 반드시 데이터를 가져와야 하는 페이지의 경우, 빌드 시간에 파일 시스템에 접근하거나 외부 API 혹은 데이터베이스 등에 request를 해야만 합니다. 이러한 요청은 getStaticProps을 사용해 진행합니다. export default function Home(props) { ... } export async function getStaticProps() { // Get external data from the file system, API, DB, etc. const data = ... // The value of the `props` key will be // passed to the `Home` component return { props: ... } } 비동기 함수 getStaticProps 안에서 실행하는 모든 것들은 빌드 타임에 진행되고, 요청을 통해 응답받은 데이터는 props의 형태로 데이터가 필요한 페이지 컴포넌트에 전달할 수 있습니다. 또한, getStaticProps 함수 내에 원하는 로직을 완성했다면, 페이지 컴포넌트를 export한 것과 마찬가지로 getStaticProps 함수도 export해주는 것을 유의해야 합니다. getStaticProps에 대한 몇 가지 유의할 점 getStaticProps 함수는 항상 server-side에서 실행됩니다. 즉, 브라우저에서 실행될 염려가 없기 때문에, 필요한 데이터를 가져오기 위해 데이터베이스에 쿼리를 날리는 것 역시 문제가 되지 않습니다. 개발자 모드로 서버를 실행했다면, getStaticProps는 request가 있을 때마다 실행되는 Sever-side Rendering 방식으로 동작합니다. (npm run dev, yarn dev) 반면에, production용으로 서버가 실행되었다면, getStaticProps 함수는 원래 의도대로 빌드 시간에 실행됩니다. getStaticProps 함수는 항상 page 파일에서 export되어야 합니다. Non-page 파일에서 export 되어서는 안됩니다. Server-side Rendering 만일 Server-side Rendering을 하고 싶다면, getServerProps를 사용합니다. CDN에 캐시되지 않아 getStaticProps보다는 느리겠지만, 최신의 정보를 request 때마다 가져올 수 있습니다. export async function getServerSideProps(context) { return { props: { // props for your component } } } context 매개변수를 사용하면, request와 관련된 매개변수들을 다룰 수 있습니다. Client-side Rendering 만일 데이터 pre-rendering을 생략하고 싶다면, Client-side Rendering을 사용합니다. 페이지에서 외부적으로 데이터를 필요로하지 않는 부분만 Static Generation하고, 페이지의 나머지 부분은 client에서 자바스크립트를 사용해 데이터를 가져오면서 로딩할 수 있습니다. (Static Generation without data + Fetch data on the Client-Side) 만일 client-side에서 데이터를 fetching하고 싶다면, Next.js에서 제공하는 리액트 훅 SWR을 사용할 것을 권장합니다. 다음은 SWR의 예시입니다. import useSWR from 'swr' function Profile() { const { data, error } = useSWR('/api/user', fetch) if (error) return <div>failed to load</div> if (!data) return <div>loading...</div> return <div>hello {data.name}!</div> } Reference Next.js Document

JavaScript-Ecosystem · 2021-10-13

TypeScript basic - Function

Parameter type annotation 변수에 type annotation을 했던 것처럼, 타입스크립트는 함수의 파라미터에 type annotation을 하여 파라미터가 원하는 데이터 타입을 가지도록 할 수 있습니다. 물론, 기존 자바스크립트에서도 파라미터의 타입을 validation할 수 있는 방법이 있습니다. function printLengthOfText(text) { if (typeof text !== 'string') { throw new Error('Argument is not a string!'); } console.log(text.length); } printLengthOfText(3); // Error: Argument is not a string! 다만 조건문을 만들고 error를 일으키는 작업이 조금 번거롭습니다. 타입스크립트는 이러한 불편함을 type annotation을 사용해 다음과 같이 간단히 해결합니다. function printKeyValue(key: string, value) { console.log(`${key}: ${value}`); } printKeyValue('Courage', 1337); // Prints: Courage: 1337 printKeyValue('Mood', 'scared'); // Prints: Mood: scared 이로 인해, key는 string 타입을 가져야 하며, annotation이 없는 value는 any 타입을 부여받게 됩니다. Optional parameter function greet(name: string) { console.log(`Hello, ${name || 'Anonymous'}!`); } greet('Anders'); // Prints: Hello, Anders! greet(); // TypeScript Error: Expected 1 arguments, but got 0. JavaScript는 인자 없이 greet()을 실행했을 때, name은 undefined가 되고 이는 falsy value로 인식되어 결국 ‘Hello, Anonymous`가 콘솔에 출력될 것입니다. 그러나 타입스크립트는 optional을 따로 지정해주지 않으면 이에 대하여 오류를 일으킵니다. 따라서 optional 파라미터를 사용하고 싶다면, 다음과 같이 파라미터 뒤에 ?를 사용해 해당 파라미터가 optional 함을 선언해줍니다. function greet(name?: string) { console.log(`Hello, ${name|| 'Anonymous'}!`); } greet(); // Prints: Hello, Anonymous! Default parameter 파리미터의 기본값을 지정해주면 해당 파리미터는 optional해지며 동시에 기본값의 타입과 동일한 타입의 데이터가 인자로 올 것이 전제됩니다. function greet(name = 'Anonymous') { console.log(`Hello, ${name}!`); } 위 코드에 대해 인자없이 greet()을 실행하면, ‘Hello, Anonymous!’를 출력합니다. 반면에, greet(3)과 같이 number 값을 인자로 전달하면 타입 에러를 야기합니다. 이는 name의 인자로 string 혹은 undefined 값이 올 것이라고 파라미터의 default 값으로 인해 설정되었기 때문입니다. Inferring return type 타입스크립트는 함수의 리턴 값의 타입 역시 추론합니다. function ouncesToCups(ounces: number) { return `${ounces / 16} cups`; } const liquidAmount: number = ouncesToCups(3); // Type 'string' is not assignable to type 'number'. 예를 들어, ouncesToCups 함수는 return statement의 값이 string이므로, string 값을 반환할 것이 분명히 예측됩니다. 따라서 liquidAmount 역시 string 값이 되어야 하는데 number로 변수를 선언했으므로 타입 에러가 나타납니다. Return type annotation 또한, type annotation을 사용하면 함수의 리턴 값에 대해서도 더 분명하게 타입 선언을 해줄 수 있습니다. function createGreeting(name?: string): string { if (name) { return `Hello, ${name}!`; } return undefined; //Typescript Error: Type 'undefined' is not assignable to type 'string'. }; 함수의 () 바로 뒤에 : type을 설정하면, 함수의 반환 값의 타입을 지정해줄 수 있습니다. 뿐만 아니라 Arrow function에도 마찬가지로 리턴 값에 대한 타입을 지정해줄 수 있습니다. const createArrowGreeting = (name?: string): string => { if (name) { return `Hello, ${name}!`; } return undefined; // Typescript Error: Type 'undefined' is not assignable to type 'string'. }; Void return type 함수에 특별한 이유가 없는 한, return type을 type annotation으로 명시해주는 것이 좋은 습관입니다. 다만, 따로 리턴하는 것이 없는 함수에 대해서는 void를 사용해 type annotation을 해주는 것이 적절합니다. function logGreeting(name:string): void{ console.log(`Hello, ${name}!`) } Documentation comments /** * This is a documentation comment */ 함수에 대한 설명을 등록하고 마우스 호버 등을 통해 이를 확인하고 싶다면 documentation comments 기능을 활용합니다. /** * Returns the sum of two numbers. * * @param x - The first input number * @param y - The second input number * @returns The sum of `x` and `y` * */ function getSum(x: number, y: number): number { return x + y; } } 위와 같이, 원하는 함수 위에 documentation comment를 등록하면 함수에 대한 설명을 입력할 수 있습니다. 또한, @param, @returns 등의 special tags를 활용하면, 함수의 특정 요소를 강조하는 comment를 입력할 수 있습니다. Reference Codecademy - TypeScript

JavaScript-Ecosystem · 2021-10-12

Next.js basic - Asset, Metadata and CSS

CSS, assets and metadata Next.js에서는 CSS를 어떻게 적용하여 스타일링할 수 있을까요? 그리고 이미지와 같은 정적 파일들과 <title>과 같은 페이지 내 메타 데이터들은 Next.js에서 어떻게 다뤄야 할까요? Asset with <Image> and image optimization 이미지와 같은 정적 파일들은 public 디렉토리에 위치시킵니다. Next.js는 public에 있는 파일들을 자동으로 참조합니다. 이미지를 저장하기 위해 public 디렉토리에 images 디렉토리를 생성하고, 그 안에 원하는 이미지를 저장하세요. (예를 들어, 프로필 사진을 사용하기 위해 profile.jpg를 저장해보세요.) import Image from 'next/image' const YourComponent = () => ( <Image src="/images/profile.jpg" // Route of the image file height={144} // Desired size with correct aspect ratio width={144} // Desired size with correct aspect ratio alt="Your Name" /> ) 저장한 이미지는 Image 컴포넌트를 next/image에서 임포트해 사용합니다. height와 width 속성을 사용해 이미지의 렌더링 사이즈를 지정해주고, src로 이미지의 위치를 설정해줍니다. 기존 HTML <img> 태그는 브라우저의 화면 크기가 바뀔 때마다 변화에 대한 이미지의 resizing을 지원하지 않습니다. 반면에, Next.js의 <Image> 컴포넌트를 사용하면, 해당 이미지의 resizing을 자동으로 지원해줍니다. 또한, <Image> 컴포넌트는 이미지의 포멧도 브라우저에서 WepP와 더 나은 이미지 포멧을 지원한다면, 자동으로 포멧을 변환해서 이미지 파일을 optimization해줍니다. 뿐만 아니라, 애플리케이션의 빌드 타임에서 이미지를 로딩하는 대신, 이미지가 viewport에 나올 때 비로소 lazy-loading하여, 페이지 전체 로딩 시간을 원활히 합니다. Metadata 페이지의 메타 데이터를 변경하고 싶다면, Next.js의 <Head> 컴포넌트를 사용합니다. HTML <head>와는 달리, <Head>는 리액트 컴포넌트입니다. import Head from 'next/head' <Head> 컴포넌트는 'next/head'에서 임포트합니다. export default function FirstPost() { return ( <> <Head> <title>First Post</title> </Head> <h1>First Post</h1> <h2> <Link href="/"> <a>Back to home</a> </Link> </h2> </> ) } 그리고 원하는 메타 데이터를 <Head> 컴포넌트 안에서 설정해줍니다. 위 코드는 페이지의 <title> 속성을 변경했습니다. 개발자 도구에서 해당 페이지의 HTML 문서를 확인해보면, 실제로 <head>에 <title> 태그가 추가되어 있는 것을 볼 수 있습니다. CSS styling <style jsx>{` … `}</style> Next.js에서 CSS는 <style jsx> 태그에 작성하면 됩니다. <style jsx>는 styled-jsx 라이브러리를 사용해 지원되는 것이며, Next.js는 built-in으로 제공됩니다. CSS와 Sass 역시 마찬가지로 built-in으로 지원됩니다. Layout component & CSS module CSS 스타일을 적용하기 위해, Layout 컴포넌트와 CSS module을 사용해봅시다. 먼저 최상위 디렉토리에 components 디렉토리를 하나 생성합니다. export default function Layout({ children }) { return <div>{children}</div> } 그리고 components/layout.js를 생성하여 위와 같은 Layout 컴포넌트를 작성합니다. 이 Layout 컴포넌트는 모든 페이지에 걸쳐 사용될 것입니다. import Head from 'next/head' import Link from 'next/link' import Layout from '../../components/layout' export default function FirstPost() { return ( <Layout> <Head> <title>First Post</title> </Head> <h1>First Post</h1> <h2> <Link href="/"> <a>Back to home</a> </Link> </h2> </Layout> ) } 그리고 CSS를 추가하고 싶은 페이지에 <Layout> 컴포넌트를 감싸서 적용해줍니다. .container { max-width: 36rem; padding: 0 1rem; margin: 3rem auto 6rem; } <Layout>에 적용해줄 CSS는 CSS Module을 사용해 생성합니다. CSS Module은 CSS 파일을 임포트해 리액트 컴포넌트에서 사용하는 것을 도와줄 것입니다. components/layout.module.css 파일을 생성하여, 위와 같이 원하는 CSS 코드를 작성합니다. 특히, CSS Modules를 사용하기 위해서는 생성한 CSS 파일의 이름이 반드시 .module.css로 끝나야함을 유의합니다. import styles from './layout.module.css' export default function Layout({ children }) { return <div className={styles.container}>{children}</div> } 끝으로, Layout 컴포넌트에 CSS를 적용합니다. layout.module.css 파일을 임의의 이름에 임포트해 사용합니다. 여기서는 styles를 사용합니다. 그리고 Layout 내에서 className 속성을 사용해 styles.container를 적용합니다. 이 후, http://localhost:3000/posts/first-post 페이지에 들어가보면, CSS가 잘 적용된 것을 확인할 수 있습니다. Unique class name의 자동 생성 CSS가 적용된 해당 페이지에서 개발자 도구를 열어 HTML 문서를 확인해보면, Layout 컴포넌트로 인해 렌더링된 다음과 같은 class name으로 새로운 <div>가 생성되어 있는 것을 볼 수 있습니다. <div class="layout_container__2t4v2"> 이는 CSS Module이 자동으로 생성한 고유한 class name입니다. 뒷 부분의 고유 문자열 덕분에 class name이 충돌할 여지는 없습니다. 또한, Next.js의 code splitting은 CSS Module에서도 적용되어, 현재 페이지가 로딩될 때 필요한 최소한의 CSS만 함께 로딩되게 됩니다. Global CSS 만일 모든 페이지에서 항상 적용 및 로딩되는 CSS를 원한다면, pages/_app.js 파일을 생성하고 _app.js 파일 내부에서 해당 CSS 파일을 임포트하면 됩니다. export default function App({ Component, pageProps }) { return <Component {...pageProps} /> } 먼저, pages/_app.js 파일을 생성하고 파일 내부에 위 컴포넌트를 작성합니다. App 컴포넌트는 가장 최상위 컴포넌트로서 모든 페이지에 영향을 줍니다. 특히, 페이지들 간의 이동이 있을 때, App 컴포넌트에 state을 저장해두면 유용합니다. 그리고 npm run dev로 서버를 다시 실행해줍니다. _app.js를 추가했을 때는 항상 서버를 다시 실행해줘야 변경사항이 저장됨을 유의합니다! html, body { padding: 0; margin: 0; font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen, Ubuntu, Cantarell, Fira Sans, Droid Sans, Helvetica Neue, sans-serif; line-height: 1.6; font-size: 18px; } * { box-sizing: border-box; } a { color: #0070f3; text-decoration: none; } a:hover { text-decoration: underline; } img { max-width: 100%; display: block; } 그리고 최상위 디렉토리 밑에 styles 디렉토리를 하나 만들어, 위와 같이 원하는 CSS 코드를 styles/global.css로 파일을 생성해 저장합니다. import '../styles/global.css' export default function App({ Component, pageProps }) { return <Component {...pageProps} /> } 그리고 pages/_app.js에서 global.css를 임포트해주면, 페이지를 이동해도 global.css의 내용이 항상 적용되는 것을 확인할 수 있습니다. 여기서 주의할 점은 global.css는 항상 _app.js 내에서 임포트해줘야 한다는 것입니다. global.css는 항상 모든 페이지에 영향을 주어야 하기 때문입니다. Reference Next.js Document

JavaScript-Ecosystem · 2021-10-12

TypeScript basic - Type

TypeScript 타입스크립트는 2012년 마이크로소프트가 발표한 기존 자바스크립트에 정적 타입 문법을 추가한 프로그래밍 언어입니다. 자바스크립트의 슈퍼셋(Superset)이기 때문에 타입스크립트 컴파일러 혹은 바벨(Babel)을 이용해 자바스크립트 코드로 변환되어 실행됩니다. 동적 타입의 인터프리터 언어인 자바스크립트와 달리, 타입스크립트는 정적 타입의 컴파일 언어이며 미리 타입을 결정하기 때문에 실행 속도가 매우 빠릅니다. 다만, 매 코드 작성시 타입을 설정하는 번거로움과 더불어, 늘어가는 코드량으로 인해 컴파일 속도는 오래걸린다는 단점이 함께 합니다. 그러나 타입스크립트의 가장 큰 장점은 코드 작성단계에서 타입을 체크해 에러를 사전에 방지할 수 있다는 점입니다. 또한, IDE의 코드 자동 완성을 지원하기 때문에 개발 생산성을 크게 향상시키는 이점도 있습니다. 타입 추론(Type inference) 타입 추론(Type inference)은 타입스크립트가 변수의 데이터 타입을 정할 때 처음 정의할 때 할당한 값을 분석하여 타입을 추론해 지정하는 방식입니다. let order = 'first'; order = 1; 따라서 위와 같이 처음 order를 정의할 때 String 값으로 정의했다면, order에는 1과 같은 Number 타입의 값이 재할당될 수 없습니다. "MY".toLowercase(); // Property 'toLowercase' does not exist on type '"MY"'. // Did you mean 'toLowerCase'? 또한, 타입스크립트는 유추한 해당 타입의 shape 역시 확인하여 위와 같이 메서드 이름 오타로 인한 버그도 쉽게 잡아낼 수 있습니다. Any 만일 변수에 값을 할당하지 않고 선언만 한다면, 해당 변수는 any 타입을 가집니다. let onOrOff; onOrOff = 1; onOrOff = false; 위의 onOrOff는 선언만 되었기 때문에, any 타입을 가집니다. 이 경우, 변수의 값이 기존과 다른 타입의 값으로 재할당되어도 타입스크립트는 오류를 일으키지 않습니다. Type annotation 변수에 값을 할당하지 않고 선언만 했을 때, 해당 변수가 any 타입이 아니라 특정 타입을 명확히 가지길 원할 수 있습니다. 이 때, type annotation을 사용합니다. let mustBeAString : string; mustBeAString = 'Catdog'; mustBeAString = 1337; // Error: Type 'number' is not assignable to type 'string' 위와 같이, let mustBeAString : string;으로 String 타입을 명확히 지정해두면, String 이외 타입의 원치 않는 데이터 할당을 막을 수 있습니다. Reference Codecademy - TypeScript 타입스크립트 핸드북 활용도가 높아지는 웹 프론트엔드 언어, 타입스크립트(TypeScript)

JavaScript-Ecosystem · 2021-10-11

Next.js basic - Pages

페이지 이동 구현 방법 Next.js를 사용해 여러 개의 페이지를 만들고 이동하는 방법을 소개합니다. Next.js는 code splitting, client-side navigation, prefetching 등을 통해, 자동으로 애플리케이션의 성능을 best performance로 최적화합니다. 페이지 만들기 먼저 새로운 페이지를 만들어봅시다. Next.js에는 pages 디렉토리가 존재합니다. 해당 디렉토리에 원하는 URL로 js 파일을 생성하면, 쉽게 새로운 페이지를 만들 수 있습니다. 예를 들어, pages/posts/first-post.js라는 경로로 새로운 페이지를 만들었다면, 해당 페이지의 URL은 /posts/first-post이 됩니다. export default function FirstPost() { return <h1>First Post</h1> } 그리고 위와 같이 컴포넌트를 만들고 서버를 실행하면, http://localhost:3000/posts/first-post에 해당 페이지가 뜨게 됩니다. 이 때, 컴포넌트는 항상 default export가 되어야 함을 유의합니다. 이러한 방식은 HTML과 PHP를 사용하여 웹사이트를 구축하는 방식과 비슷하지만, HTML 대신에 JSX와 React component를 사용했다는 점이 다릅니다. 이제 남은 것은 홈페이지에 새로운 페이지로 가는 링크만 걸어주는 것입니다! Link component Next.js에서 페이지의 링크를 걸어주는 것은 <Link> 컴포넌트를 사용해서 수행합니다. import Link from 'next/link' 이를 위해, 먼저 'next/link'로부터 Link 컴포넌트를 import합니다. <h1 className="title"> Read{' '} <Link href="/posts/first-post"> <a>this page!</a> </Link> </h1> 그리고 index.js에서 위와 같이 코드를 작성하면, 새로 만든 페이지의 URL /posts/first-post로 이동하는 링크를 만들 수 있습니다. 여기서 <Link>가 <a> 태그를 감쌌다는 점, href 속성은 <Link> 태그에 주었다는 점을 유의합니다. 참고로, {' '}은 multiple line text를 나누기 위해 사용됩니다. import Link from 'next/link' export default function FirstPost() { return ( <> <h1>First Post</h1> <h2> <Link href="/"> <a>Back to home</a> </Link> </h2> </> ) } 앞선 pages/posts/first-post.js에도 위와 같이 홈으로 돌아가는 링크를 만들면, 페이지끼리 서로 이동할 수 있게 됩니다. Link and client-side navigation <Link>의 사용은 client-side navigation을 가능하게 합니다. 즉, 페이지 전환이 클라이언트 측에서 자바스크립트를 이용해 일어나기 때문에, 페이지의 모든 부분을 서버에서부터 새로 가져와 로딩하는 브라우저 기본 navigation 방식보다 훨씬 빠르게 동작합니다. 만일 <Link>가 아닌 <a> 태그를 사용했다면, 브라우저는 해당 링크에 접근할 때마다 페이지 전체를 refresh할 것입니다. Code splitting Next.js에서는 code splitting이 자동적으로 일어나므로, 페이지의 로딩도 해당 페이지에 반드시 필요한 것들만 로딩됩니다. 예를 들어, 홈페이지가 렌더링될 때는 다른 페이지들은 로딩되지 않습니다. 특히, 애플리케이션에 수 많은 페이지가 있을 때, 유저는 자신이 요청한 페이지를 보다 빠르게 볼 수 있게 됩니다. 즉, 페이지들의 코드는 각각 분리되어 있고, 어떤 특정 페이지가 오류를 일으켜도 애플리케이션의 나머지 부분은 문제없이 동작합니다. Prefetching 브라우저의 viewport(메뉴 바, 탭 영역을 제외한 브라우저의 순수 화면 영역)에 <Link> 컴포넌트가 있을 때마다, Next.js는 <Link>에 연결된 페이지들을 자동으로 미리 로딩해둡니다. 이를 prefetching이라고 하며, 이러한 페이지들은 유저가 링크를 누를 때 background에서 이미 로딩되어 있어서 매우 빠르게 페이지가 전환됩니다. Reference Next.js Document

JavaScript-Ecosystem · 2021-10-11

React - Advanced tips

Programming patterns 리액트는 자주 사용되는 프로그래밍 패턴이 존재합니다. Scene 1 - Stateful components to stateless components Stateful component가 자신의 state setter 함수를 props로 child component에 전달하면, child component의 어떠한 event에 의해 해당 함수가 호출되어 parent component의 state를 변경합니다. 그리고 parent component는 변경된 state를 props로 또 다른 child component(=sibling component)에게 전달해 해당 child component에서 화면에 표시합니다. Scene 2 - Separating container components from presentational components State를 가지거나 calculation 등의 functional part를 담당하는 component는 container component로, 렌더링을 담당하는 component는 presentational component로 분리해야 합니다. 분리된 presentational component는 항상 container component에 의해서 렌더링되어야 합니다. Style Name Syntax 일반적인 JavaScript에서 style의 name은 hyphenated-lowercase로 이루어져 있습니다. const styles = { 'margin-top': '20px', 'background-color': 'green' }; 반면에, 리액트는 style name이 camelCase로 이루어져 있습니다. const styles = { marginTop: '20px', backgroundColor: 'green' }; Style Value Syntax 일반적인 JavaScript에서는 "450px", "20%" 처럼 숫자와 단위를 함께 적어 string 형태로 style value를 사용해야 합니다. 하지만, 리액트에서는 px에 한해서 생략이 가능하고, 이 경우 숫자도 string이 아닌 number 그대로 사용하는 것이 가능합니다. 물론 기존의 string 형태도 그대로 사용 가능합니다. { fontSize: 30 } 다만, 다른 단위를 사용하고 싶을 때는 기존의 string 형태로 사용합니다. { fontSize: "2em" } propTypes propTypes는 리액트에서 자주 사용되는 특징입니다. Prop이 전달될 것이 예상되는 component에 올바른 prop이 전달되었는지에 대한 validation을 도와주고, documentation을 통해 component의 상황을 한눈에 파악할 수 있도록 도와줍니다. import PropTypes from 'prop-types'; propTypes를 사용하기 위해선 'prop-types' 라이브러리를 import해야 합니다. import React from 'react'; import PropTypes from 'prop-types'; export class MessageDisplayer extends React.Component { render() { return <h1>{this.props.message}</h1>; } } // This propTypes object should have // one property for each expected prop: MessageDisplayer.propTypes = { message: PropTypes.string }; 그리고 미리 정의된 component에 위와 같이 property를 추가하는 방식으로 propTypes를 정의할 수 있습니다. 이 때, propTypes의 value는 object 형태여야 함을 유의합니다. 그리고 해당 object의 각각의 property는 component에 전달될 것이 기대되는 prop의 이름으로 설정합니다. Runner.propTypes = { message: PropTypes.string.isRequired, style: PropTypes.object.isRequired, isMetric: PropTypes.bool.isRequired, miles: PropTypes.number.isRequired, milesToKM: PropTypes.func.isRequired, races: PropTypes.array.isRequired }; PropTypes를 통해 설정할 수 있는 data type의 이름은 위와 같습니다. isRequired의 경우, prop이 잘 전달되는지 확인해서 만일 잘 전달되지 않으면 console에 warning을 띄어주는 역할을 합니다. const Example = (props) => { return <h1>{props.message}</h1>; } Example.propTypes = { message: PropTypes.string.isRequired }; 만일 function component에 propTypes를 추가하고 싶다면, 위와 같이 function component 자체의 property로 propTypes를 지정합니다. React forms import React from 'react'; import ReactDOM from 'react-dom'; export class Input extends React.Component { constructor(props) { super(props); this.state = { userInput: '' }; this.handleUserInput = this.handleUserInput.bind(this); } handleUserInput(e) { this.setState({userInput: e.target.value}); } render() { return ( <div> <input type="text" value={this.state.userInput} onChange={this.handleUserInput} /> <h1>{this.state.userInput}</h1> </div> ); } } ReactDOM.render( <Input />, document.getElementById('app') ); 일반적인 form은 유저가 input field에 계속 타이핑하더라도 submit 버튼을 누르기전까지는 서버에서 그 사실을 알지 못합니다. 즉, submit 이전까지 프론트가 알고 있는 input 정보와 서버가 알고 있는 input 정보 사이에 불일치가 존재합니다. 그러나 이러한 불일치는 웹사이트의 third part에서 해당 정보를 필요로 할 때, 프론트냐 서버냐에 따라 다른 결과를 내어 문제가 발생할 수 있습니다. 이를 해결하기 위해, 리액트 form은 모든 new character와 deletion에 대한 프론트 및 서버의 동기화를 지원하여 application의 모든 요소가 일관성 있게 동작하도록 합니다. 특히, 일반적인 <form> tag를 굳이 사용하지 않고 위 코드처럼 <input> tag만으로 이를 구현할 수 있습니다. Uncontrolled vs Controlled component Uncontrolled component란 스스로 state를 가지고 그 값을 기억하는 component를 말합니다. 반면에 controlled component는 스스로 state를 가지지 않고 다른 component에 의해 관리되어지는 component를 말합니다. 리액트에는 주로 controlled component가 많고 이러한 component는 스스로에 대한 정보를 props를 통해 얻게 됩니다. Reference Learn React - Codecademy

JavaScript-Ecosystem · 2021-08-30

React - Hook

Functional components 지금까지 JavaScript의 클래스를 사용해서 정의한 리액트의 component들은 함수를 사용해서 정의할 수도 있습니다. 이를 function component라고 합니다. Function component는 간단하고 직관적이라는 장점이 있습니다. // A component class written in the usual way: class MyComponentClass extends React.Component { render() { return <h1>Hello world</h1>; } } // The same component class, written as a stateless functional component: const MyComponentClass = () => { return <h1>Hello world</h1>; } // Works the same either way: ReactDOM.render( <MyComponentClass />, document.getElementById('app') ); Function component는 위와 같이 함수 형태로 작성하며, render() 메서드를 사용하지 않고 JSX expression을 바로 리턴하는 방식으로 작성합니다. Function component는 props 역시 전달받을 수 있습니다. function WelshCorgi (props) { return ( <div> <p>{props.prompt}</p> </div> ); } ReactDOM.render( <WelshCorgi feed="High quality dog feed" />, document.getElementById('app'); ); props는 parameter로 정의해 전달받고, props.propertyName 형식으로 접근합니다. Hook Hook은 function component에서 component의 state와 이후의 렌더링 관련 side effects를 관리하도록 도와주는 함수들입니다. 클래스에서는 작동되지 않지만, function component에서 lifecycle적인 특징들도 관리할 수 있도록 도와줍니다. State hook - useState import React, { useState } from "react"; function Toggle() { const [toggle, setToggle] = useState('off'); return ( <div> <p>The toggle is {toggle}</p> <button onClick={() => setToggle("On")}>On</button> <button onClick={() => setToggle("Off")}>Off</button> </div> ); } useState는 리액트 라이브러리에서 제공하는 JavaScript 함수로, 호출 시 두 가지 value가 담긴 array를 리턴합니다. current state - the current value of this state state setter - a function that we can use to update the value of this state State에 대한 초깃값은 useState에 인자로 넣어진 값으로 설정할 수 있습니다. 초깃값이 중요하지 않은 경우, 인자를 넣지 않고 초깃값을 undefined 상태로 두어도 상관없으나 null 값이라도 넘겨주는 것이 가독성을 높이는 방법이 될 수 있습니다. useState를 사용해서 임의의 value를 인자로 state setter 함수를 호출하면, 현재 state를 새로운 state로 update할 수 있습니다. 특히 state setter 함수가 호출되면 리액트는 자동으로 해당 component를 다시 렌더링하므로 변경한 새로운 state value가 바로 반영됩니다. import React, { useState } from 'react'; export default function Counter() { const [count, setCount] = useState(0); const increment = () => setCount(prevCount => prevCount + 1); return ( <div> <p>Wow, you've clicked that button: {count} times</p> <button onClick={increment}>Click here!</button> </div> ); } 만일 기존의 state를 활용해 계산한 값으로 state를 update하고 싶다면, state setter 함수에 콜백 함수를 인자로 전달하면 됩니다. 위와 같이 기존 state count를 활용해 prevCount + 1 값으로 state를 update하고 싶다면, setCount(prevCount => prevCount + 1)처럼 콜백 함수를 state setter 함수의 인자로 넣어줍니다. 특정한 상황에서는 setCount(count +1) 같이 바로 값을 update할 수도 있지만, 콜백 함수를 사용하는 방법이 모든 상황에서 더 안전하다는 점을 유의합니다. import React, { useState } from "react"; const options = ["Bell Pepper", "Sausage", "Pepperoni", "Pineapple"]; export default function PersonalPizza() { const [selected, setSelected] = useState([]); const toggleTopping = ({target}) => { const clickedTopping = target.value; setSelected((prev) => { // check if clicked topping is already selected if (prev.includes(clickedTopping)) { // filter the clicked topping out of state return prev.filter(t => t !== clickedTopping); } else { // add the clicked topping to our state return [clickedTopping, ...prev]; } }); }; return ( <div> {options.map(option => ( <button value={option} onClick={toggleTopping} key={option}> {selected.includes(option) ? "Remove " : "Add "} {option} </button> ))} <p>Order a {selected.join(", ")} pizza</p> </div> ); } 만일 state의 값이 Array 타입인 경우, state를 update할 때 이전 state의 Array를 그대로 변경하지말고 새로운 Array로 변경 내역을 copy해서 state에 할당해야 함을 유의합니다. 위에서도 return prev.filter(t => t !== clickedTopping); 혹은 return [clickedTopping, ...prev];으로 새로운 Array를 만들어 리턴합니다. export default function Login() { const [formState, setFormState] = useState({}); const handleChange = ({ target }) => { const { name, value } = target; setFormState((prev) => ({ ...prev, [name]: value })); }; return ( <form> <input value={formState.firstName} onChange={handleChange} name="firstName" type="text" /> <input value={formState.password} onChange={handleChange} type="password" name="password" /> </form> ); } State의 타입이 Object인 경우에도 update할 state 값은 변경된 내역을 새로 copy한 Object가 되어야 합니다. 또 Object를 arrow function에서 return할 때는 {}가 겹치는 문제가 발생할 수 있기 때문에, 반환할 Object를 ()로 감싸줄 필요가 있습니다. Separate Hooks for Separate States function Subject() { const [state, setState] = useState({ currentGrade: 'B', classmates: ['Hasan', 'Sam', 'Emma'], classDetails: {topic: 'Math', teacher: 'Ms. Barry', room: 201}; exams: [{unit: 1, score: 91}, {unit: 2, score: 88}]); }); State와 같은 dynamic data를 다루기 위해서는 state 변수마다 각각 hook을 지정해 관리하는 것이 편합니다. 위와 같이 하나의 복잡한 Object를 state로 하여 하나의 hook으로 관리한다면, 복잡한 state들을 각각 copy할 때 매우 불편해집니다. function Subject() { const [currentGrade, setGrade] = useState('B'); const [classmates, setClassmates] = useState(['Hasan', 'Sam', 'Emma']); const [classDetails, setClassDetails] = useState({topic: 'Math', teacher: 'Ms. Barry', room: 201}); const [exams, setExams] = useState([{unit: 1, score: 91}, {unit: 2, score: 88}]); // ... } 따라서, 위와 같이 state 변수마다 hook을 만들어 관리한다면 훨씬 간단하고 쉽게 state를 관리할 수 있습니다. Effect hook Effect hook은 렌더링 이후의 side effects를 관리하는 함수입니다. fetch API를 통해 백엔드로부터 데이터를 받아오거나 DOM을 읽고 변화를 주는 등의 side effect를 발생시키는 작업들을 관리하며, 보통 다음 3가지 상황에서 사용합니다. Component가 DOM에 mount되어 렌더링될 때 State 혹은 props가 변화하여 component가 다시 렌더링 될 때 Component가 DOM에서 unmount되어 렌더링될 때 Effect hook - useEffect import React, { useState, useEffect } from 'react'; function PageTitle() { const [name, setName] = useState(''); useEffect(() => { document.title = `Hi, ${name}`; }); return ( <div> <p>Use the input field below to rename this page!</p> <input onChange={({target}) => setName(target.value)} value={name} type='text' /> </div> ); } useEffect는 component를 렌더링할 때마다 다른 함수를 호출하기 위해 사용합니다. 이로 인해, useEffect는 첫 번째 인자로 렌더링 후 호출할 목적의 콜백 함수를 받습니다. 그리고 이러한 콜백 함수를 effect라고도 부릅니다. 예를 들어, 위 코드에서는 () => { document.title = name; }가 effect입니다. Effect는 현재 state에도 접근할 수 있습니다. 다만 component 렌더링이 일어난 다음 DOM이 update되면 그 후 effect가 호출되므로, state도 update가 완료된 상태에서 접근하게 됩니다. Clean Up Effects 어떠한 effect들은 메모리 누수를 피하기 위하여 항상 제거하는 작업을 동반해주어야 합니다. 예를 들어, effect를 사용해 직접 DOM 내의 element에 event listener를 추가하는 경우, 원하는 작업이 끝나면 해당 event listener를 반드시 다시 제거해주어야 합니다. 그렇지 않으면 렌더링될 때마다 호출되는 effect hook의 특성으로 인해, 이후 발생하는 수많은 렌더링 상황마다 event listener가 의도치 않게 끊임없이 추가되어 메모리가 터지는 상황이 생길 수 있습니다. 따라서 다음과 같이 useEffect의 effect 내에서 event listener를 제거하는 함수를 반환하여, 추가했던 event listener를 제거해줍니다. useEffect(()=>{ document.addEventListener('keydown', handleKeyPress); return () => { document.removeEventListener('keydown', handleKeyPress); }; }) Effect가 반환하는 함수는 useEffect가 항상 clean up 함수로 간주하므로, 리액트는 effect 작업이 끝나면 자동적으로 이를 호출합니다. Dependency array Effect는 기본적으로 매 렌더링이 일어나는 상황마다 호출됩니다. 그러나 dependency array를 사용하면, effect를 원하는 때에만 호출하도록 설정할 수 있습니다. Dependency array는 useEffect의 두 번째 인자로 넣는 array를 말합니다. 만일 component가 mount되어 첫 번째 렌더링을 할 때만 effect hook을 호출하고 최종 렌더링에서 clean up하고 싶다면, 빈 array []를 useEffect()의 두 번째 인자로 넣어줍니다. 반면에, dependency array에 특정 변수를 요소로 넣는다면, 해당 변수의 값이 변할 때만 effect가 호출됩니다. useEffect(() => { document.title = `You clicked ${count} times`; }, [count]); // Only re-run the effect if the value stored by count changes Hook을 사용하는 규칙 더욱 복잡한 React 앱에서 혼란을 피하기 위해, hook은 다음과 같은 규칙을 지키며 사용합시다. Hook을 항상 top level에서만 사용합시다. 리액트는 function component 내에서 정의한 순서에 따라 hook과 함께 관리되는 data와 function들을 인식합니다. 따라서, conditions, loops, nested functions 안에서 hook을 사용하지 말아야 합니다. if (userName !== '') { useEffect(() => { localStorage.setItem('savedUserName', userName); }); } 조건문을 쓰고 싶다면 위와 같이 쓰지 말고, 다음과 같이 effect 내에서 사용해 동일한 결과를 얻을 수 있습니다. useEffect(() => { if (userName !== '') { localStorage.setItem('savedUserName', userName); } }); Hook은 react function component 내에서만 사용합시다. Function component이외에 hook을 사용할 수 있는 곳은 custom hook을 제외하고 존재하지 않습니다. Class component나 일반적인 JavaScript 함수 내에서 hook을 사용하지 맙시다. Separate Hooks for Separate States // Handle menuItems with one useEffect hook. const [menuItems, setMenuItems] = useState(null); useEffect(() => { get('/menu').then((response) => setMenuItems(response.data)); }, []); // Handle position with a separate useEffect hook. const [position, setPosition] = useState({ x: 0, y: 0 }); useEffect(() => { const handleMove = (event) => setPosition({ x: event.clientX, y: event.clientY }); window.addEventListener('mousemove', handleMove); return () => window.removeEventListener('mousemove', handleMove); }, []); Effect hook 역시 모든 로직을 한 곳에 모아두면 가독성이 떨어지고 복잡해집니다. 따라서 위와 같이 effect 마다 따로 hook을 만드는 것을 지향합니다. Reference Learn React - Codecademy

JavaScript-Ecosystem · 2021-08-29

React - Component Lifecycle Methods

Component lifecycle methods 리액트의 수많은 component들은 각각 자신의 lifecycle을 가집니다. 보통 component의 lifecycle 다음과 같이 구성됩니다. Mounting, when the component is being initialized and put into the DOM for the first time Updating, when the component updates as a result of changed state or changed props Unmounting, when the component is being removed from the DOM 그리고 이러한 lifecycle 각각을 제어하기 위해 개발자들이 사용할 수 있는 lifecycle method들이 존재합니다. 대표적으로 constructor()와 render() 역시 lifecycle method에 해당됩니다! constructor()는 mounting phase에 첫 번째로 호출되는 메서드로, render()는 mounting과 updating phase에 자주 등장하는 메서드로 분류할 수 있습니다. componentDidMount() componentDidMount() 메서드는 mounting phase에서 마지막으로 호출되는 메서드입니다. Mounting phase 안에서 메서드들은 다음과 같은 순서로 호출됩니다. The constructor render() componentDidMount() componentDidMount()를 활용하면 1초씩 현 시각을 계속 알려주는 시계를 만들 수 있습니다. import React from 'react'; import ReactDOM from 'react-dom'; class Clock extends React.Component { constructor(props) { super(props); this.state = { date: new Date() }; } render() { return <div>{this.state.date.toLocaleTimeString()}</div>; } componentDidMount() { // Paste your code here. const oneSecond = 1000; setInterval(() => { this.setState({ date: new Date() }); }, oneSecond); } } ReactDOM.render(<Clock />, document.getElementById('app')); componentWillUnmount import React from 'react'; export class Clock extends React.Component { constructor(props) { super(props); this.state = { date: new Date() }; } render() { return <div>{this.state.date.toLocaleTimeString()}</div>; } componentDidMount() { const oneSecond = 1000; this.intervalID = setInterval(() => { this.setState({ date: new Date() }); }, oneSecond); } componentWillUnmount() { clearInterval(this.intervalID); } } componentWillUnmount 메서드는 unmounting phase에서 사용됩니다. Component가 완전히 없어지기 전에 호출되기 때문에, side-effect를 발생시키는 불필요한 비동기 함수를 종료하기 적합한 시기입니다. 위와 같이 시간을 지속적으로 업데이트하는 시계의 setInterval() 함수를 멈추려면, componentWillUnmount() 메서드에서 clearInterval()을 사용합니다. intervalID를 clearInterval()의 인자로 전달해주면 해당 setInterval() 함수를 종료시킵니다. componentDidUpdate Updating phase에서 주로 사용하는 메서드는 render(), componentDidUpdate입니다. Update는 props와 state의 변화가 일어날 때 발생하는 작업으로, update 관련한 로직은 componentDidUpdate에서 사용하는 것이 유용합니다. Reference Learn React - Codecademy this interactive diagram

JavaScript-Ecosystem · 2021-08-28

React - Component Interacting

JavaScript-Ecosystem · 2021-08-27

React - Component

Component of React Component란 하나의 작업을 수행하는 재사용할 수 있는 작은 코드 뭉치를 의미합니다. 여기서 하나의 작업이란 대체로 HTML 코드를 렌더링하는 것을 말합니다. Necessary import Component를 사용하기 위해서는 React 객체를 import 해두어야 합니다. React 객체에는 리액트 라이브러리를 사용하기 위한 필수적인 메서드들이 담겨있습니다. JSX expression을 사용하는데도 React 객체가 반드시 필요하므로, 첫 줄은 항상 다음 코드로 시작하도록 합니다! import React from 'react'; 또한, component 사용을 위해 ReactDOM 객체도 import합니다. ReactDOM 객체는 React 객체와 마찬가지로 React와 관련된 메서드들을 가지고 있습니다. 그러나 React에는 순수하게 React만을 위한 메서드가 담겨있는 반면, ReactDOM은 React와 DOM의 상호작용을 돕는 메서드들이 담겨 있다는 차이점이 있습니다. 따라서, 다음 코드 역시 함께 사용합니다. import ReactDOM from 'react-dom'; 클래스를 활용한 Component 생성 리액트 component는 자바스크립트의 클래스 혹은 함수를 통해 생성할 수 있습니다. 여기서는 클래스 component에 초점을 맞추겠습니다. 클래스 component는 리액트 라이브러리의 Component 클래스를 상속받아서 정의합니다. 클래스를 사용하면 원하는 만큼 인스턴스로 component를 만들어 렌더링할 수 있다는 이점이 생깁니다. import React from 'react'; import ReactDOM from 'react-dom'; class MyComponentClass extends React.Component { render() { return <h1>Hello component</h1>; } } ReactDOM.render( <MyComponentClass />, document.getElementById('app') ); 위와 같이 React.Component를 상속받으면 새로운 component 클래스를 만들어 customizing할 수 있습니다. 여기서 React.Component는 React 객체의 property이며, Component는 클래스입니다. 여기서 또 하나 유의할 점은 새로 정의한 component 클래스 body에는 반드시 render() 메서드를, render() 메서드 내에는 주로 JSX expression을 반환하는 return statement를 정의해야 한다는 부분입니다. 해당 클래스에는 어떤 component를 만들 것인지 instruction을 제시해줘야 하기 때문에, 이를 위한 render() 메서드와 return statement를 필수적으로 정의합니다. 그리고 이렇게 만들어진 클래스를 활용해 component를 자유롭게 생성할 수 있습니다. 앞서 JSX element를 사용했듯이, 클래스의 이름을 사용해 <MyComponentClass /> 코드를 쓰면 component 인스턴스가 생성됩니다! 이렇게 생성한 component 인스턴스를 ReactDOM.render()에 인자로 던져주면, 해당 component를 화면에 렌더링할 수 있습니다. Component는 클래스에서 정의한 render() 메서드를 가지고 있기 때문에, ReactDOM.render()는 인자로 받은 component의 render() 메서드를 자동으로 호출하게끔 하여 JSX expression을 반환받고 화면에 렌더링합니다. Class component의 naming convention 새로 정의한 클래스 component의 이름은 첫 글자부터 대문자를 사용하는 UpperCamelCase를 따릅니다. 이것은 Java의 naming convention에서 차용되었으며, 원래의 JavaScript 클래스를 만들 때도 마찬가지의 convention을 따릅니다. UpperCamelCase를 사용하는 또 다른 이유는 리액트 자체적으로도 찾을 수 있습니다. JSX element는 HTML-like인 경우와 component인 경우로 나뉩니다. 이 때, UpperCamelCase로 쓰인 JSX element가 있다면, 해당 element가 component instance임을 쉽게 파악할 수 있습니다. ex) ShinyBrownHairOfWelshCorgi ex) <WelshCorgiLegComponent /> render() 메서드에 정의할 수 있는 것 class Random extends React.Component { render() { // First, some logic that must happen // before rendering: const n = Math.floor(Math.random() * 10 + 1); // Next, a return statement // using that logic: return <h1>The number of Welsh Corgi is {n}!</h1>; } } Component의 render() 메서드에는 항상 return statement가 와야 합니다. 다만 이에 더하여, 렌더링 직전의 간단한 계산 역시 둘 수 있는 위치입니다. class Random extends React.Component { // This should be in the render function: const n = Math.floor(Math.random() * 10 + 1); render() { return <h1>The number of Welsh Corgi is {n}!</h1>; } }; 그러나 위와 같이 render() 메서드 바깥에 변수를 정의하는 것은 syntax error를 유발하니, 메서드 안쪽에서 정의할 것을 유의해야 합니다. Event listener in a component class MyClass extends React.Component { myFunc() { alert('Stop it. Stop hovering my Welsh Corgi.'); } render() { return ( <div onHover={this.myFunc}> </div> ); } } 위와 같이 component 클래스의 메서드로 정의한 event handler 함수를 사용하여, event listener를 component에 정의할 수 있습니다. Event listener 속성에 this를 사용해 메서드를 부여하는 것으로 적용 가능합니다. Reference Learn React - Codecademy

JavaScript-Ecosystem · 2021-08-26

React - JSX

React basic React.js는 Facebook 엔지니어들이 개발한 UI 개발 목적의 JavaScript 라이브러리입니다. 리액트의 컴포넌트 기반 개발은 Single Page Application을 비롯한 프론트 개발에 큰 변화를 이끌었으며, 근 5~6년간 자바스크립트 생태계의 가장 중요한 존재 중 하나로 자리해 왔습니다. 최근에는 더 효율적인 프론트 개발 라이브러리들이 많이 등장했지만, 리액트의 영향력은 여전히 직간접적으로 느껴집니다. JSX const h1 = <h1>Welsh Corgi!!</h1>; JSX는 리액트에 사용되기 위해 쓰여진 JavaScript의 syntax extension입니다. 보통 JavaScript 파일 속에 JavaScript 코드와 HTML 코드들이 혼용되어 쓰여진 것들로 통용되므로, JSX 코드에는 HTML같은 코드가 포함되지만 실제로 HTML은 아닙니다. 특히, JSX는 웹 브라우저가 바로 읽을 수 없습니다. 그러므로 JSX가 포함된 JavaScript 파일을 통상적으로 사용하려면, JSX compiler를 통해 일반적인 JavaScript 코드로 컴파일해야 합니다. JSX element <h1>Hello world</h1> 또한, JavaScript 파일 속에 HTML과 똑같이 생긴 위와 같은 코드들을 JSX element라고 부릅니다. JSX element는 JavaScript 코드로 간주되어, 변수에 저장되거나 함수의 인자로 입력되는 등 일반적인 모든 프로그래밍에 문제 없이 사용됩니다. const welshCorgi = <img src='images/welsh.jpg' alt='welsh corgi' width='600px' height='600px' />; JSX element에는 HTML 때와 마찬가지로 attribute 역시 적용할 수 있습니다. const welshCorgi = ( <a href="https://www.shinybrownhair.com"> <h1> Bow wow! </h1> </a> ); Nested한 형태도 기존 HTML처럼 사용할 수 있습니다. 다만, multi-line이 될 경우 ()로 감싸주어야 오류 없이 프로그래밍할 수 있음을 유의합시다. const dogs = ( <p>I am a Poodle.</p> <p>I am a Welsh Corgi. Nice to meet you!</p> ); 다만, JSX expression은 하나의 같은 element 단위가 되어야 하기 때문에, 위와 같이 두 개의 element를 한 번에 사용하는 것은 불가능합니다. 만일 위와 같이 쓰고 싶다면, 위 코드를 하나의 <div></div> 태그로 감싸서 코드가 올바르게 동작하도록 만드는 방법을 권장합니다. Rendering 렌더링(Rendering)이란 코드를 해석해서 화면에 띄우는 작업을 의미합니다. 렌더링은 보통 리액트와 관련된 메서드들을 모아둔 ReactDom 라이브러리의 ReactDOM.render() 메서드를 사용해 진행합니다. import React from 'react'; import ReactDOM from 'react-dom'; ReactDOM.render(<h1>Hello world</h1>, document.getElementById('app')); ReactDOM.render() 메서드에는 첫 번째 인자로 화면에 띄울 JSX expression을 사용합니다. 그리고 두 번째 인자로 해당 JSX expression을 띄울 container가 될 HTML 태그를 찾아 넘깁니다. <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <link rel="stylesheet" href="/styles.css"> <title>Learn ReactJS</title> </head> <body> <main id="app"></main> </body> </html> 예를 들어 위와 같은 index.html 문서가 있다면, <main id="app"></main> 태그 속에 첫 번째 인자로 넘긴 JSX expression이 위치해 화면에 렌더링됩니다. Virtual DOM const dog = <h1>Welsh Corgi</h1>; // This will add "Welsh Corgi" to the screen: ReactDOM.render(dog, document.getElementById('app')); // This won't do anything at all: ReactDOM.render(dog, document.getElementById('app')); ReactDOM.render()의 장점은 변경이 있는 DOM elements만 update한다는 점입니다. 수많은 DOM elements가 있을 때, 변경된 것들만 update하는 것은 React의 큰 이점입니다. React는 virtual DOM을 통해 이를 실현합니다. Virtual DOM이란 리액트에서 실제 DOM object와 대응되는 가벼운 카피 버전의 가상 DOM object를 말합니다. Virtual DOM은 실제 DOM과 같은 property들을 가지지만, DOM의 변화를 화면에 직접 띄우는 기능은 없기 때문에, 일반 DOM 조작보다 빠르다는 장점이 있습니다. 따라서, 리액트는 다음과 같은 방식으로 DOM을 update합니다. 전체 virtual DOM을 업데이트합니다. Update한 virtual DOM과 이전 virtual DOM의 snapshot을 비교하여 변화된 부분들을 확인합니다. 변화된 부분만 실제 DOM object에서 update합니다. 실제 DOM의 변화가 화면에 반영됩니다. DOM manipulation의 단점 과거 일반적인 자바스크립트 라이브러리들은 DOM manipulation을 할 때, DOM element 하나가 변경되면 모든 element들을 다시 update해야 해서 비효율적이었습니다. 덕분에 DOM이 커질수록 cost가 더욱 늘어났는데, 리액트의 virtual DOM 도입은 cost 문제를 혁신적으로 해결했습니다. 변경된 특정 DOM element만 update하는 virtual DOM의 특징이 DOM manipulation 속도를 혁신적으로 향상 됐습니다. Advanced syntax of JSX JSX의 문법은 대게 HTML과 동일하지만 미묘하게 다른 부분들이 존재하므로 유의해야 합니다. className <h1 className="dog">Welsh Corgi</h1> HTML에서 사용되는 class 속성은 JSX에서 className으로 사용합니다. 이는 JavaScript가 class를 예약어로 갖고 있어서 JSX를 JavaScript로 변압할 때 키워드가 겹치는 문제가 발생하기 때문입니다. 대신 className은 JSX가 렌더링될 때, class 속성으로서 자동으로 인식됩니다. self-closing tag Fine in HTML with a slash: <br /> Also fine, without the slash: <br> HTML에서는 <img> 태그나 <input> 태그 같은 요소들의 끝 부분 > 앞에 /를 쓰는 것이 선택적입니다. Fine in JSX: <br /> NOT FINE AT ALL in JSX: <br> 하지만, JSX에서는 self-closing tag에 /를 반드시 써줘야 합니다. (그렇지 않으면, 에러가 발생합니다.) JavaScript in JSX in JavaScript import React from 'react'; import ReactDOM from 'react-dom'; ReactDOM.render( <h1>{2 + 3}</h1>, document.getElementById('app') ); // Output on monitor: 5 JSX expression 안에 일반적인 JavaScript 코드를 사용하고 싶다면, {}를 사용합니다. {} 안에 위치한 코드들은 JSX expression 안쪽이라도 JavaScript 코드로 인식됩니다. 여기서 {}는 JSX나 JavaScript가 아니라, JavaScript injection into JSX의 시작과 끝을 나타내는 marker입니다. Event Listener function myFunc() { alert('Welsh Corgi!!!!'); } <img onClick={myFunc} /> JSX에서도 HTML과 같이 event listener를 사용할 수 있습니다. on을 접두어로 하는 속성들을 사용하면 event listener를 적용할 수 있는데, 해당 속성들의 값은 반드시 함수가 되어야 합니다. 또한, HTML에서 event listener의 이름들은 모두 소문자로 쓰이지만, JSX에서는 camelCase로 사용해야 합니다. Conditional statement JSX에는 if 구문을 삽입할 수 없습니다. 하지만, 이를 해결할 몇 가지 방법도 존재합니다. const sound = 'Bow wow!'; if (sound === 'Bow wow!') { message = ( <h1> Hey, good dog! </h1> ); } else { message = ( <h1> I like a lot of animal! </h1> ); } 먼저, JSX 바깥에서 if를 사용해 원하는 조건문을 만들 수 있습니다. const sound = 'Bow wow!'; const message = ( <h1> { sound === 'Bow wow!' ? 'Hey, good dog!' : 'I like a lot of animal!' } </h1> ); 혹은 삼항연산자(ternary operator)를 사용하면 JSX 내부에서도 조건문을 사용할 수 있습니다. React에서는 상당히 자주 사용되는 방법입니다. const tasty = ( <ul> <li>Dog feed</li> { !puppy && <li>Dog gum</li> } { age > 1 && <li>bone</li> } { age > 5 && <li>Dog ade</li> } { age > 7 && <li>Dog cookie</li> } </ul> ); 만일 어떤 조건에서만 action을 취하고 다른 때는 아무 것도 하지 않는 경우라면, && 연산자를 활용하는 것도 적합합니다. 즉, && 연산자의 왼쪽 expression이 true일 경우에만, && 연산자의 오른쪽 expression이 렌더링될 것입니다. 이러한 형태의 조건문도 React에서 자주 쓰이는 방식입니다. map() const dogs = ['Welsh Corgi', 'Poodle', 'Dachshund']; const listDogs = dogs.map(dog => <li>{dog}</li>); <ul>{listDogs}</ul> 만일 JSX element의 array를 만들고 싶다면, .map()을 사용하는 것이 유용합니다. React에서 자주 사용되는 방식이므로 기억해두면 좋습니다. // This is fine in JSX, not in an explicit array: <ul> <li>dog 1</li> <li>dog 2</li> <li>dog 3</li> </ul> // This is also fine! const liArray = [ <li>dog 1</li>, <li>dog 2</li>, <li>dog 3</li> ]; <ul>{liArray}</ul> 또한, <li> JSX element들이 담긴 array는 위의 {liArray} 같이 곧바로 <ul>과 함께 사용하는 것이 가능합니다. key 속성 <ul> <li key="li-01">Dog 1</li> <li key="li-02">Dog 2</li> <li key="li-03">Dog 3</li> </ul> <li> 태그들은 때때로 key 속성을 필요로 할 때가 있습니다. 특정 상황에서 key를 설정해두지 않으면 잘못된 순서로 list-item들이 나타날 수 있으므로, 다음과 같은 상황에서는 key 속성을 설정합니다. 각각의 list-item이 memory를 가질 경우 (to-do list와 같이 항목의 체크 여부를 기억해야 할 때) list-item이 섞일 가능성이 있을 때 key 속성을 설정할 때, key 속성의 값은 unique해야 합니다. React.createElement() React 코드를 JSX expression을 쓰지 않고도 사용할 수 있는 방법이 있습니다. const h1 = <h1>Welsh Corgi</h1>; 위의 JSX expression으로 표현하던 기존의 코드는 다음과 같이 새로 쓰일 수 있습니다. const h1 = React.createElement( "h1", null, "Welsh Corgi" ); React.createElement()을 사용하면 JSX expression을 쓰지 않고도 같은 기능을 하는 React 코드를 만들 수 있습니다. 사실 JSX element가 컴파일 될 때, 컴파일러는 내부적으로 해당 JSX element를 React.createElement() 메서드로 변형하여 호출합니다. 즉, JSX expression을 사용하기 전에는 항상 import React from 'react';로 React 객체를 import해야 하는데, 그 이유는 내부적으로 항상 React.createElement() 메서드가 사용 가능해야 하기 때문입니다. Reference Learn React - Codecademy Event Listener List - React.js

JavaScript-Ecosystem · 2021-08-25

JavaScript - Async/Await

Async-Await async, await을 사용하는 구문은 ES8에서 소개된 JavaScript의 비동기 처리를 위한 syntactic sugar입니다. 비동기 처리하는 과정이나 결과는 이전 callback 함수를 통해 구현하는 방식이나 혹은 ES6에서부터 사용하는 promise 객체를 사용해 구현하는 방식과 동일하지만, 문법적으로 조금 더 편리하게 비동기 처리를 할 수 있도록 제공됩니다. async keyword async function myFunc() { // Function body here }; myFunc(); 비동기 함수를 만들기 위해 사용하는 키워드입니다. 구현한 비동기 처리 로직은 위와 같이 async로 선언된 함수로 감싸서 의도대로 실행할 수 있습니다. const myFunc = async () => { // Function body here }; myFunc(); 또한, async 함수는 함수 선언식 뿐만 아니라 함수 표현식으로도 사용할 수 있습니다. async 함수의 리턴 값 async 함수는 항상 promise 객체를 리턴합니다. 덕분에, 원래의 promise 비동기 처리 방식대로 .then(), .catch() 등을 그대로 사용할 수 있습니다. 다만, 리턴할 때 3가지 상황에 따라 다른 promise 객체를 내어줍니다. 명시적으로 리턴하는 값이 없을 때: undefined를 resolved value로 사용하는 promise 객체를 리턴합니다. 명시적으로 promise 객체가 아닌 값을 리턴할 때: 해당 리턴 값을 resolved value로 사용하는 promise 객체를 리턴합니다. 명시적으로 promise 객체를 리턴할 때: 해당 promise 객체를 그대로 리턴합니다. await keyword async 키워드 만으로는 비동기 처리를 제대로 할 수 없기 때문에, async 함수 안에서는 보통 await을 함께 사용합니다. await은 지정한 함수에서 promise 객체가 리턴 및 resolve될 때까지 async 함수 실행 자체를 멈추었다가, promise의 resolved value를 받으면 해당 값을 리턴하고 async 함수의 남은 코드를 다시 실행하는 키워드입니다. 즉, promise를 객체를 받아 해당 promise 객체를 pending 상태에서 resolved 상태까지 실행하여 resolved value를 리턴하는 전 과정을 포괄합니다. 이러한 특이성으로 인해, await은 주로 라이브러리에서 가져온 promise를 리턴하는 함수와 함께 사용하는 것이 일반적입니다. async function asyncFuncExample(){ let resolvedValue = await myPromise(); console.log(resolvedValue); } asyncFuncExample(); // Prints: I am resolved now! 위 코드에서 myPromise()는 "I am resolved now!"라는 string을 resolve할 promise를 리턴하는 함수입니다. 이렇게 promise의 로직을 인지하며 await을 사용하면, 비동기적인 코드가 순차적인 코드 흐름으로 읽히도록 구현할 수 있습니다. Error handling with try... catch async function usingTryCatch() { try { let resolveValue = await asyncFunction('thing that will fail'); let secondValue = await secondAsyncFunction(resolveValue); } catch (err) { // Catches any errors in the try block console.log(err); } } usingTryCatch(); 기존의 promise 객체 비동기 처리 방식에서 chain이 길어질 때, .catch를 사용해도 어떤 순서에서 error가 발생한 것인지 파악하기 어려웠습니다. 반면에, async... await에서는 try... catch를 사용해 쉽게 error handling을 진행할 수 있습니다. async 함수에서 try... catch는 동기적인 코드와 같은 방식으로 error handling을 할 수 있으면서 동시에, 동기 및 비동기 error 모두를 잡아낼 수 있기 때문에, 쉬운 디버깅을 가능하게 한다는 큰 이점이 있습니다. async function usingPromiseCatch() { let resolveValue = await asyncFunction('thing that will fail'); } let rejectedPromise = usingPromiseCatch(); rejectedPromise.catch((rejectValue) => { console.log(rejectValue); }) 물론 async 함수도 promise 객체의 .catch 메서드를 종종 사용할 때가 있습니다. 위와 같이, 복잡한 코드의 마지막 에러만 잡아내고 싶을 경우 global scope에서 사용하는 것이 하나의 예입니다. 독립적인 promise들을 다루는 방법 다수의 promise 객체들이 서로 의존하고 있을 때는 promise마다 await을 사용하여 명확한 순서로 비동기 처리를 하는 것이 효율적입니다. 반면에, promise 객체들이 서로 독립적일 때는 순서에 상관없이 모든 promise가 동시에 실행되는 것이 보다 효율적입니다. async 함수에서 앞서 이야기한 concurrent 실행을 진행하는 방법을 크게 2가지 소개하겠습니다. await in one line /* 원래의 모습 async function waiting() { const firstValue = await firstAsyncThing(); const secondValue = await secondAsyncThing(); console.log(firstValue, secondValue); } */ // concurrent 실행 async function concurrent() { const firstPromise = firstAsyncThing(); const secondPromise = secondAsyncThing(); console.log(await firstPromise, await secondPromise); } use Promise.all async function asyncPromAll() { const resultArray = await Promise.all([asyncTask1(), asyncTask2(), asyncTask3(), asyncTask4()]); for (let i = 0; i<resultArray.length; i++){ console.log(resultArray[i]); } } Reference Codecademy - introduction to javascript

JavaScript-Ecosystem · 2021-08-09

JavaScript - Browser compatibility and transpilation

Browser Compatibility & Transpilation 우리는 정기적으로 web browser의 update 알림을 받습니다. 주기적인 update가 필요한 이유는 보통 보안상 취약점을 처리하고 HTML, CSS 혹은 JavaScript의 새로운 syntax 버전을 지원하기 위해서입니다. 특히, JavaScript의 표준을 관리하는 기관, Ecma International이 2015년에 발표한 ECMAScript2015(흔히, ES6로 불리우는)가 등장했을 때, 많은 개발자들은 장점이 많은 ES6를 바로 채택하고 사용했지만 대부분의 브라우저에서 ES6가 지원되지 않아 브라우저 호환성(browser compatibility) 문제가 발생했습니다. 이 챕터에서는 새로운 syntax 버전과의 gap으로 인해 발생하는 이러한 브라우저 호환성 이슈를 개발자들이 어떤식으로 처리하는지에 초점을 맞추려고 합니다. caniuse.com caniuser.com은 브라우저 호환성 정보를 쉽게 찾아볼 수 있는 사이트입니다. 어떤 브라우저의 몇 번째 버전이 특정 라이브러리를 지원하는지 여부를 간단히 체크할 수 있습니다. 이 곳에서 검색해보면, ES5는 여전히 대다수의 브라우저에서 지원됩니다. 이와 달리, ES6는 점진적인 적용을 감안해야 합니다. 그 결과 대부분의 최신 버전 브라우저에서는 ES6가 원활히 지원되는 반면, ES6 module과 같은 ES6의 특정 feature들은 지원되지 않는 브라우저가 아직 대다수입니다. ES6의 장점과 Transpilation의 필요성 ES6는 이전 버전인 ES5에 비해 상당한 이점들이 있습니다. Readability and economy of code Addresses sources of ES5 bugs A similarity to other programming languages 이러한 장점들은 많은 web developer들이 ES6를 곧바로 채택하도록 만들었습니다. 다만, ECMA는 이로 인해 발생할 호환성 문제를 미리 예상해, ES6가 ES5 코드로 mapping될 수 있게끔 만들었습니다. 예를 들어, const나 let 키워드를 var로 mapping하거나, interpolation을 concatenation으로 mapping하는 방식입니다. 이러한 mapping은 충분히 규칙적이기 때문에, 개발자들은 ES6가 자동으로 ES5으로 변환되도록 하는 Babel이라는 JS library를 만들었습니다. 즉, 하나의 프로그래밍 언어를 다른 언어로 변환하는 과정을 transpilation이라고 하며, Babel은 ES6를 ES5로 transpile합니다. Babel Babel은 ES6를 ES5로 손쉽게 transpile해주는 library입니다. 먼저, Babel을 사용하기 위해 ES6의 파일(main.js)의 위치를 ./src/main.js에 둡니다. project |_ src |___ main.js // ES6 file 그리고 Babel을 설치하기 전에 npm을 사용할 수 있게끔 프로젝트를 setup해야 합니다. npm은 node project manager의 약자로 node package에 대한 접근과 관리를 위해 사용됩니다. npm을 사용하면 작업의 반복과 버그를 줄일 수 있습니다. 터미널에서 npm을 init합니다. (Node가 설치되어 있어야 합니다!) npm init 이 때, metadata에 관한 사항을 적어달라는 prompt가 나오는데, title과 description정도만 입력하고 전부 무시해도 좋습니다. (title, description 역시 선택사항입니다.) Init 이후에, root 디렉토리에는 package.json 파일이 생성됩니다. package.json 파일은 해당 프로젝트의 metadata와 프로젝트를 실행하기 위해 필요한 node package 목록, command line scripts에 해당하는 key-value pair 등을 저장합니다. Babel은 터미널 창에서 다음과 같이 사용합니다. Babel package 설치하기 (2개 모두) for CLI tool npm install babel-cli -D for mapping information npm install babel-preset-env -D 실행이 완료되면 Babel 패키지 및 관련된 모든 dependency들이 node_modules 디렉토리에 저장되어 있는 것을 확인할 수 있습니다. -D 옵션 -D는 해당 패키지를 package.json의 devDependencies라는 property에 추가하는 옵션입니다. 일단 devDependencies에 추가된 패키지들은 다른 개발자들이 현재 프로젝트를 실행할 때 각각의 패키지를 install할 필요없이 npm install 커맨드 한 번으로 모두 설치되는 이점을 가집니다. Source가 되는 JS version 설정하기 Root 디렉토리에서 .babelrc 파일을 생성합니다. touch .babelrc .babelrc 내에 source가 될 js 파일의 버전을 명시합니다. 아래와 같은 object를 파일에 저장하면, Babel은 ES6+에 대한 코드들을 목표 언어로 변환할 것입니다. ``` { “presets”: [“env”] } package.json에 Babel 실행을 위한 script 기재하기 package.json에 script property에 가보면 다음과 같은 객체가 존재함을 확인할 수 있습니다. ... "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, ... 이 객체의 "test" property 밑에, 다음과 같이 Babel을 실행하기 위한 script를 하나 추가합니다. ... "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "build": "babel src -d lib" } 추가한 코드는 각각 다음과 같은 의미를 가지고 있습니다. babel — The Babel command call responsible for transpiling code. src — Instructs Babel to transpile all JavaScript code inside the src directory. -d — Instructs Babel to write the transpiled code to a directory. lib — Babel writes the transpiled code to a directory called lib. Babel 실행하기 (root directory) npm run build 작업이 완료되면 ./lib 디렉토리에 변환된 ES5 코드가 담긴 파일을 확인할 수 있습니다. 파일명은 본래의 ES6 파일명과 동일하게 생성됩니다. 최종적인 디렉토리 구조는 다음과 같습니다. project |_ lib |___ main.js |_ node_modules |___ .bin |___ ... |_ src |___ main.js |_ .babelrc |_ package.json Reference Codecademy - introduction to javascript

JavaScript-Ecosystem · 2021-08-08

JavaScript - Class

Class Javascript는 OOP(object-oriented programming) language입니다. 따라서, 실제 세계를 모델로 class와 instance를 만들어 object들을 사용할 수 있습니다. Syntax example class Dog { constructor(name) { this._name = name; this._behavior = 0; } get name() { return this._name; } get behavior() { return this._behavior; } incrementBehavior() { this._behavior ++; } } const halley = new Dog('Halley'); console.log(halley.name); // Print name value to console console.log(halley.behavior); // Print behavior value to console halley.incrementBehavior(); // Add one to behavior console.log(halley.name); // Print name value to console console.log(halley.behavior); // Print behavior value to console class Class를 생성하기 위해 필요한 키워드 입니다. constructor Class가 object와 가장 구분되는 지점은 constructor 메서드의 유무입니다. constructor는 새로운 instance가 만들어질 때마다 호출되는 class의 중요한 메서드이며, instance를 초기화하는 역할을 합니다. this Class의 맥락에서 this는 해당 class의 instance를 의미합니다. new Class의 instance를 생성하기 위해 사용하는 키워드입니다. new는 class 내의 constructor() 메서드를 호출하고 새로운 instance를 반환합니다. 상속(Inheritance) class Cat { constructor(name, usesLitter) { this._name = name; this._usesLitter = usesLitter; this._behavior = 0; } get name() { return this._name; } get behavior() { return this._behavior; } get usesLitter() { return this._usesLitter; } incrementBehavior() { this._behavior++; } } 앞선 class의 예제에서 Dog class를 만들었던 것처럼, Cat class도 이와 유사하게 만들 수 있습니다. 여기선 Cat의 경우 모든 것이 Dog와 동일하지만 배변기 사용 가능 여부를 나타내는 usesLitter property만 하나 더 가집니다. 이렇게 여러 class가 동일한 부분을 가질 경우, 코드의 반복을 피하기 위해 부모 class를 만들어 자식 class가 이를 상속(inheritance)받게끔 설계하는 것이 효율적입니다. 상속은 부모 class가 가지는 property와 method를 동일하게 사용할 수 있게끔 물려받는 것을 의미합니다. 상속을 사용하면 코드의 가독성이 높아지고 유지보수가 매우 쉬워집니다. class Animal { constructor(name) { this._name = name; this._behavior = 0; } get name() { return this._name; } get behavior() { return this._behavior; } incrementBehavior() { this._behavior++; } } 따라서, 위와 같이 Animal class를 만들어 Dog와 Cat의 공통된 부분을 모은 후, 이를 각자 상속받도록 설계하는 것이 보다 나은 코드를 만드는 방향이 될 것입니다. Animal을 상속받은 Cat의 코드는 다음과 같습니다. class Cat extends Animal { constructor(name, usesLitter) { super(name); this._usesLitter = usesLitter; } get usesLitter() { return this._usesLitter; } } extends Class를 다른 class의 자식 class로 만들기 위해 사용하는 키워드입니다. 부모 class의 method들을 자식 class가 사용할 수 있게 됩니다. super 부모 class의 constructor 메서드를 호출하는 키워드입니다. 부모 class의 property 상속과 관련이 깊습니다. 또한, 자식 class에서 this를 사용하기 위해, 자식 class 내의 constructor 메서드 첫 번째 줄에 반드시 호출해주어야 합니다. (그렇지 않으면, reference error가 발생합니다!) const bryceCat = new Cat('Bryce', false); console.log(bryceCat._name); // output: Bryce console.log(bryceCat.name); // output: Bryce 끝으로, Animal class를 상속받은 Cat은 위와 같이 instance를 만들어 사용할 수 있습니다. Static method Static method는 class에 직접적으로 접근해 사용하는 메서드를 말합니다. 해당 class의 instance를 통해서는 사용할 수 없다는 특징이 있습니다. 예를 들어, Date class는 instance를 만들 수 있으면서 .now() 같은 static method를 사용할 수 있습니다. 다음은 Animal class에 static method generateName을 추가한 코드입니다. class Animal { constructor(name) { this._name = name; this._behavior = 0; } static generateName() { const names = ['Angel', 'Spike', 'Buffy', 'Willow', 'Tara']; const randomNumber = Math.floor(Math.random()*5); return names[randomNumber]; } } console.log(Animal.generateName()); // returns a name static Static method를 선언하는 키워드입니다. static이 사용된 메서드는 instance를 통해 사용할 수 없고, class에서 직접적으로 접근해야 호출 가능합니다. Instance를 통해 호출할 경우, error를 일으킵니다. Reference Codecademy - introduction to javascript

JavaScript-Ecosystem · 2021-08-07

JavaScript - Object

Object Javascript의 data type은 6개의 primitive data type(string, number, boolean, null, undefined, symbol)과 1개의 object data type으로 구성되어 있습니다. Javascript는 객체지향 언어이고 6개의 primitive data type도 객체와 같이 동작하는 특징이 있습니다. 또한, object는 mutable(변경가능한) 속성을 가집니다. Syntax Object는 {}를 통해 구현됩니다. {} 안에는 unordered data를 key-value pair로 삽입합니다. value의 경우 어떤 data type이 와도 괜찮습니다. 반면에, key의 타입은 string이어야 합니다. 다만, key의 경우 특별한 특수문자를 집어넣는 것이 아니라면 quotation mark 없이 사용해도 string으로 자동 인식됩니다. // An object literal with two key-value pairs let spaceship = { 'Fuel Type': 'diesel', color: 'silver' }; Property Object에 저장된 함수가 아닌 data는 property라고 부릅니다. Property에 접근할 때는 .이 사용됩니다. 만일 object 내에 없는 property에 접근한 경우에는 undefined가 반환됩니다. let spaceship = { homePlanet: 'Earth', color: 'silver' }; spaceship.homePlanet; // Returns 'Earth', spaceship.color; // Returns 'silver', 또 다른 방법은 []을 사용하는 것입니다. 원하는 key를 []안에 넣으면 object에서 해당하는 property에 접근합니다. []는 특수문자가 포함된 key string에 특히 유용합니다. let spaceship = { 'Fuel Type': 'Turbo Fuel', 'Active Duty': true, homePlanet: 'Earth', numCrew: 5 }; spaceship['Active Duty']; // Returns true spaceship['Fuel Type']; // Returns 'Turbo Fuel' spaceship['numCrew']; // Returns 5 spaceship['!!!!!!!!!!!!!!!']; // Returns undefined Add, update and delete [], .와 =를 사용하면, object에 새로운 property를 추가하거나 기존 property를 수정할 수 있습니다. 또한, const 변수에 담긴 object여도 해당 object 안의 property를 추가하거나 수정할 수 있습니다. const spaceship = {type: 'shuttle'}; spaceship = {type: 'alien'}; // TypeError: Assignment to constant variable. spaceship.type = 'alien'; // Changes the value of the type property spaceship.speed = 'Mach 5'; // Creates a new key of 'speed' with a value of 'Mach 5' Object 내의 property를 삭제하는 방법은 delete 키워드를 사용하는 것입니다. 역시 const 변수에 담긴 object여도 내부의 property 삭제가 가능합니다. const spaceship = { 'Fuel Type': 'Turbo Fuel', homePlanet: 'Earth', mission: 'Explore the universe' }; delete spaceship.mission; // Removes the mission property Method Object 내에 저장된 데이터가 함수라면, 해당 데이터는 method라고 부릅니다. Method는 key에 method 이름을, value에 익명 함수를 저장함으로써 구현합니다. const alienShip = { invade: function () { console.log('Hello! We have come to dominate your planet. Instead of Earth, it shall be called New Xaculon.') } }; ES6에서 새로이 소개된 method 문법에서는 :과 function 키워드 없이도 정의할 수 있습니다. const alienShip = { invade () { console.log('Hello! We have come to dominate your planet. Instead of Earth, it shall be called New Xaculon.') } }; Method는 ., ()를 사용해 호출합니다. alienShip.invade(); // Prints 'Hello! We have come to dominate your planet. Instead of Earth, it shall be called New Xaculon.' Pass by reference Javascript에서 object는 pass by reference로 동작합니다. Object를 담는 변수는 실제로는 해당 객체가 담겨 있는 메모리 주소를 담기 때문에, object가 함수에 인자로 전달되어 변형이 일어나면 함수 밖의 실제 object도 영향을 받아 변형됩니다. const spaceship = { homePlanet : 'Earth', color : 'silver' }; let paintIt = obj => { obj.color = 'glorious gold' }; paintIt(spaceship); spaceship.color // Returns 'glorious gold' 함수 내에서 object를 재할당하는 경우 let spaceship = { homePlanet : 'Earth', color : 'red' }; let tryReassignment = obj => { obj = { identified : false, 'transport type' : 'flying' } console.log(obj) // Prints {'identified': false, 'transport type': 'flying'} }; tryReassignment(spaceship) // The attempt at reassignment does not work. spaceship // Still returns {homePlanet : 'Earth', color : 'red'}; spaceship = { identified : false, 'transport type': 'flying' }; // Regular reassignment still works. 함수의 인자로 object를 받을 때, 함수 내에서 새로운 object를 재할당을 하는 것은 기존 object에 영향을 미치지 않습니다. 위 예에서 obj 파라미터는 함수내에 생성되는 로컬 변수입니다. tryReassignment 함수의 흐름은 파라미터 obj에 인자로 들어온 object의 메모리 주소가 담기고, 이에 대해 새로운 object를 할당하여 새 object의 메모리 주소가 다시 obj에 담기게끔 이어집니다. 하지만, 함수가 종료되면 로컬 변수였던 obj 역시 사라지기 때문에, 기존 spaceship에 담긴 object는 변형 없이 그대로 남아 있게 됩니다. for … in Array의 경우 index를 통해 looping할 수 있지만, object는 key를 사용하기 때문에 다른 looping 수단이 필요합니다. 따라서, object looping에 대해서는 for ... in 구문을 사용합니다. let spaceship = { crew: { captain: { name: 'Lily', degree: 'Computer Engineering', cheerTeam() { console.log('You got this!') } }, 'chief officer': { name: 'Dan', degree: 'Aerospace Engineering', agree() { console.log('I agree, captain!') } }, medic: { name: 'Clementine', degree: 'Physics', announce() { console.log(`Jets on!`) } }, translator: { name: 'Shauna', degree: 'Conservation Science', powerFuel() { console.log('The tank is full!') } } } }; // for...in for (let crewMember in spaceship.crew) { console.log(`${crewMember}: ${spaceship.crew[crewMember].name}`); } this keyword this 키워드는 calling object를 나타내며, object의 method 내에서 property에 접근할 때는 this 키워드를 사용합니다. 여기서 calling object란 해당 method를 호출하는 객체를 말합니다. const goat = { dietType: 'herbivore', makeSound() { console.log('baaa'); }, diet() { console.log(this.dietType); } }; goat.diet(); // Output: herbivore 예를 들어, diet() method에서 dietType property에 접근하기 위해서는 반드시 this 키워드가 필요합니다. diet() 내에서 dietType에 접근할 경우 scope가 diet() 안쪽으로 설정되기 때문에 reference error가 발생합니다. 따라서, dietype property에 접근하려면 this 키워드로 calling object인 goat를 불러와 접근해야 합니다. Arrow function과 this const goat = { dietType: 'herbivore', makeSound() { console.log('baaa'); }, diet: () => { console.log(this.dietType); } }; goat.diet(); // Prints undefined 객체에 method를 정의할 때, arrow function 사용은 지양해야 합니다. 위와 같은 경우 this가 가리키는 calling object는 global object입니다. this가 diet scope에 존재하지 않기 때문에, 상위 스코프를 탐색하게 되고 global object가 this가 됩니다. 따라서, global object에는 dietType property가 없기 때문에, this.dietType은 undefined를 가집니다. Privacy of object Product를 만들다보면, 어떠한 object 내 property에 아무나 접근하지 못하게끔 막아야 하는 상황이 발생합니다. 특정 프로그래밍 언어들에서는 이러한 경우를 제어할 수 있는 privacy와 관련된 built-in 키워드를 제공합니다. 하지만 Javascript의 경우 이러한 제어 방법이 없기 때문에, 네이밍 컨벤션을 통해 다른 개발자들에게 해당 property를 어떻게 써야할 지 알려줍니다. 대표적으로 property의 식별자 앞에 _를 붙이는 것은 해당 property가 변형되어서는 안된다는 의미입니다. const robot = { _energyLevel: 100, recharge(){ this._energyLevel += 30; console.log(`Recharged! Energy is currently at ${this._energyLevel}%.`) } }; robot['_energyLevel'] = 'high'; robot.recharge(); // Output: Recharged! Energy is currently at high30%. 예를 들어, 위 코드의 경우 _energyLevel은 robot['_energyLevel'] = 'high';과 같이 실제로 변형이 가능합니다. 하지만, 개발자의 의도에 맞지 않게 string 값으로 변형함으로 인해 high30%와 같은 어색한 결과가 발생했습니다. 이처럼 _가 붙은 property는 원치않는 결과가 나올 수 있으니 직접적으로 접근하여 변형시키면 안된다는 의미를 내포합니다. Getters & Setters Getters method const person = { _firstName: 'John', _lastName: 'Doe', get fullName() { if (this._firstName && this._lastName){ return `${this._firstName} ${this._lastName}`; } else { return 'Missing a first name or a last name.'; } } } // To call the getter method: person.fullName; // 'John Doe' Getters는 객체 내부에서 property를 가져와 반환해주는 method입니다. Method 앞에 get를 사용해 구현하며, this를 통해 객체 내의 property를 조작합니다. Getters를 호출할 때는 마치 property에 접근하는 것 같이, () 없이 .만으로 호출합니다. Getters를 사용하면, property에 접근할 때 원하는 action을 임의로 추가할 수 있고, 다른 개발자들이 이해하기 쉽도록 코드를 짤 수 있습니다. Setters method const person = { _age: 37, set age(newAge){ if (typeof newAge === 'number'){ this._age = newAge; } else { console.log('You must assign a number to age'); } } }; person.age = 40; console.log(person._age); // Logs: 40 person.age = '40'; // Logs: You must assign a number to age 객체 내 property에 대한 접근을 도와주는 getters와 달리, setters는 객체 내 존재하는 property의 value를 재할당할 수 있게 도와주는 method입니다. Method 앞에 set을 사용해 구현하며, 마찬가지로 this를 사용해 객체 내 property를 조작합니다. Setters를 호출할 때도 마치 property에 값을 할당하는 것 같이 .만 사용하여 호출합니다. Setters도 input checking, easier readability 등의 이점을 가집니다. Naming of getters, setters Getters와 setters의 이름은 객체 내의 property들의 이름과 겹쳐서는 안됩니다. 만일 겹칠 경우, 끝없는 call stack error에 빠지게 됩니다. 이를 피하기 위해, property 이름 앞에 _를 붙여주는 것은 좋은 방법이 됩니다. Factory function const monsterFactory = (name, age, energySource, catchPhrase) => { return { name: name, age: age, energySource: energySource, scare() { console.log(catchPhrase); } } }; const ghost = monsterFactory('Ghouly', 251, 'ectoplasm', 'BOO!'); ghost.scare(); // 'BOO!' 하나하나의 object를 직접 만드는 것은 손이 많이 가고 비효율적입니다. 따라서, 몇 가지 parameter를 받아서 customized된 object를 반환하는 함수를 만들면 다수의 object를 효율적으로 생성할 수 있습니다. 이러한 함수를 factory function이라고 합니다. Property value shorthand const monsterFactory = (name, age) => { return { name: name, age: age } }; 기존에는 객체에 property를 저장하기 위해 위 코드와 같이 key-value pair 방식을 사용했습니다. 다만, ES6에서는 factory function을 사용할 때와 같이 parameter의 이름과 property의 이름이 같은 경우에 대해 코드 중복을 줄일 수 있도록 property value shorthand 문법을 제공합니다. 따라서 위 코드는 다음과 같이 수정될 수 있습니다. const monsterFactory = (name, age) => { return { name, age } }; Destructured assignment 객체의 key를 통해 value를 가져와 변수에 저장하던 일반적인 방식에 대해, 조금 더 간략한 destructured assignment 방식이 존재합니다. const vampire = { name: 'Dracula', residence: 'Transylvania', preferences: { day: 'stay inside', night: 'satisfy appetite' } }; 위와 같은 vampire 객체에서 residence property를 가져와 변수에 저장하고 싶다면, 두 가지 방식을 사용할 수 있습니다. const residence = vampire.residence; console.log(residence); // Prints 'Transylvania' 먼저 일반적인 방식으로 key를 통해 가져올 수 있습니다. const { residence } = vampire; console.log(residence); // Prints 'Transylvania' 그런데 만일 key의 이름과 같은 이름으로 변수를 생성한다면, 위와 같이 {}를 통해 보다 간결히 property를 가져와 변수에 저장할 수 있습니다. Reference Codecademy - introduction to javascript

JavaScript-Ecosystem · 2021-08-06

JavaScript - Iterator

Iterator Looping을 더욱 쉽게 만들어주는 JavaScript의 built-in array methods를 iteration method(=iterator)라고 합니다. Iterator는 array가 element들을 조작하고 value를 반환하기 위해 호출하는 메서드로서 도움을 줍니다. forEach() forEach()는 특정 함수를 array 각각의 element들에 적용하는 iterator입니다. 보통 iterator의 인자로 함수를 받은 후, element들 각각을 인자로 사용해 해당 함수를 호출합니다. (이렇게 다른 함수의 인자로 사용되는 함수를 callback 함수라고 부릅니다.) forEach()는 기존의 array를 변경하지 않으며, undefined를 return합니다. groceries.forEach(groceryItem => console.log(groceryItem)); 또한, arrow function을 인자로 사용해 iterator를 호출할 수도 있습니다. 이처럼, iterator의 인자로 사용되는 함수의 syntax는 임의로 자유롭게 사용할 수 있습니다. map() const numbers = [1, 2, 3, 4, 5]; const bigNumbers = numbers.map(number => { return number * 10; }); console.log(numbers); // Output: [1, 2, 3, 4, 5] console.log(bigNumbers); // Output: [10, 20, 30, 40, 50] map() 역시 forEach()와 비슷하게 동작합니다. 인자로 callback 함수를 받아, array 각각의 element를 callback 함수의 인자로 사용합니다. 다만, map()은 함수를 적용한 새로운 값들을 array에 담아서 반환한다는 점이 특징입니다. filter() const words = ['chair', 'music', 'pillow', 'brick', 'pen', 'door']; const shortWords = words.filter(word => { return word.length < 6; }); console.log(words); // Output: ['chair', 'music', 'pillow', 'brick', 'pen', 'door']; console.log(shortWords); // Output: ['chair', 'music', 'brick', 'pen', 'door'] filter()는 원래의 array에서 특정 조건에 만족하는 element들만 골라내어 새로운 array에 담아 반환합니다. 따라서, filter()에 인자로 사용되는 callback 함수는 반드시 boolean 값을 리턴하는 함수여야 합니다. 이 때, callback 함수가 true를 반환하게 하는 element들이 새로운 array에 담깁니다. findIndex() const jumbledNums = [123, 25, 78, 5, 9]; const lessThanTen = jumbledNums.findIndex(num => { return num < 10; }); console.log(lessThanTen); // Output: 3 console.log(jumbledNums[3]); // Output: 5 findIndex()는 특정 element의 위치를 알고 싶을 때 사용하는 iterator입니다. Callback 함수가 true를 반환하는 첫 번째 element의 index를 return합니다. 만일, callback 함수의 조건을 충족하는 element가 없다면 findIndex()는 -1을 반환합니다. reduce() const numbers = [1, 2, 4, 10]; const summedNums = numbers.reduce((accumulator, currentValue) => { return accumulator + currentValue }) console.log(summedNums) // Output: 17 Iteration accumulator currentValue return value First 1 2 3 Second 3 4 7 Third 7 10 17 reduce()는 말그대로 array을 감소시켜 하나의 값으로 만드는 iterator입니다. Callback 함수에 따라 array의 각 element를 accumulator에 대해 계산해, 최종적으로 하나의 계산 값을 반환합니다. const numbers = [1, 2, 4, 10]; const summedNums = numbers.reduce((accumulator, currentValue) => { return accumulator + currentValue }, 100) // <- Second argument for .reduce() console.log(summedNums); // Output: 117 Iteration # accumulator currentValue return value First 100 1 101 Second 101 2 103 Third 103 4 107 Fourth 107 10 117 또한, reduce()는 optional한 두 번째 parameter를 받을 수 있으며, 이 때 해당 parameter는 accumulator로서 사용됩니다. Reference Codecademy - introduction to javascript

JavaScript-Ecosystem · 2021-08-04

JavaScript - Array

Array Javascript의 array는 어떤 data type도 저장할 수 있으며, 저장된 data마다 순서(index)를 지닙니다. Syntax 기본적인 문법은 []을 중심으로 이뤄지며, array 내부에 다양한 type의 data들이 함께 저장될 수 있습니다. Indexing Array는 []에 index를 사용하여 원하는 element에 접근할 수 있습니다. Indexing의 시작은 0부터 진행되며, 만일 element의 총 개수를 넘어가는 index로 접근할 경우 undefined가 반환됩니다. Indexing to String const hello = 'Hello World'; console.log(hello[6]); // Output: W 또한, Indexing은 String type의 data에도 적용됨을 유의합니다. Update with index let seasons = ['Winter', 'Spring', 'Summer', 'Fall']; seasons[3] = 'Autumn'; console.log(seasons); //Output: ['Winter', 'Spring', 'Summer', 'Autumn'] Indexing을 사용하면 접근한 data를 원하는 값으로 update하는 것도 가능합니다. let & const in array let condiments = ['Ketchup', 'Mustard', 'Soy Sauce', 'Sriracha']; const utensils = ['Fork', 'Knife', 'Chopsticks', 'Spork']; condiments[0] = 'Mayo'; console.log(condiments); // [ 'Mayo', 'Mustard', 'Soy Sauce', 'Sriracha' ] condiments = ['Mayo']; console.log(condiments); // [ 'Mayo' ] utensils[3] = 'Spoon'; console.log(utensils); // [ 'Fork', 'Knife', 'Chopsticks', 'Spoon' ] const 변수에 저장한 array라도 해당 array 내부의 요소는 여전히 변경가능(mutable)합니다. 다만, 새로운 array 혹은 값을 변수에 재할당할 수는 없습니다. Useful property & method length: array 내의 존재하는 element의 개수를 반환합니다. push(): array의 맨 끝에 element를 추가합니다. (이 때, 인자를 여러 개 받을 수 있습니다.) const itemTracker = ['item 0', 'item 1', 'item 2']; itemTracker.push('item 3', 'item 4'); console.log(itemTracker); // Output: ['item 0', 'item 1', 'item 2', 'item 3', 'item 4']; pop(): array의 맨 끝의 element를 제거하고 그 값을 반환합니다. (인자를 받지 않습니다.) shift(): array 맨 앞의 element를 제거하고 반환합니다. (인자를 받지 않습니다.) unshift(): array의 맨 앞에 element를 추가합니다. (이 때, 인자를 여러 개 받을 수 있습니다.) slice(): 설정한 index대로 slicing한 결과를 반환합니다. const animals = ['ant', 'bison', 'camel', 'duck', 'elephant']; console.log(animals.slice(2)); // expected output: Array ["camel", "duck", "elephant"] console.log(animals.slice(2, 4)); // expected output: Array ["camel", "duck"] console.log(animals.slice(1, 5)); // expected output: Array ["bison", "camel", "duck", "elephant"] console.log(animals.slice(-2)); // expected output: Array ["duck", "elephant"] console.log(animals.slice(2, -1)); // expected output: Array ["camel", "duck"] indexOf(): 인자로 오는 값이 array에서 몇 번째 index인지 찾아 반환합니다. Reference Codecademy - introduction to javascript

JavaScript-Ecosystem · 2021-07-24

JavaScript - Function

Function of Javascript Syntax Syntax of declaring parameter and calling with argument Parameter를 함수에 선언하는 문법은 다음과 같습니다. 그리고 다음과 같이 인자를 전달해 해당 함수를 호출합니다. Default parameter Javascript에서 default parameter는 ES6 버전에서 소개되었습니다. 함수에 default parameter를 설정해두면, 인자가 전달되지 않거나 data type이 undefined인 인자가 전달될 때 argument의 값으로 default parameter에 설정된 값이 오게 됩니다. function greeting (dog = 'stranger dog') { console.log(`Hello, ${dog}!`) } greeting('Welsh Corgi') // Output: Hello, Welsh Corgi! greeting() // Output: Hello, stranger dog! Return 보통의 언어들처럼 return 키워드를 사용해 함수의 결과를 반환합니다. 만일 어떤 값을 리턴하지 않으면, 기본적으로 undefined 값이 반환됩니다. function greeting(name) { let text = 'Bow wow, hello ' + name + '!'; } console.log(greeting('lucian')) // Prints undefined function greeting(name) { let text = 'Bow wow, hello ' + name + '!'; return; } console.log(greeting('lucian')) // Prints undefined Hoisting Javascript는 함수가 선언된 곳 이전에서도 해당 함수를 호출할 수 있습니다. 이러한 Javascript의 특징을 hoisting이라고 부릅니다. 다만, 함수 선언 이전에 호출하는 것은 일반적으로 좋은 방법이 아니기 때문에, hoisting의 사용은 지양하는 것이 좋습니다. greeting(); // Output: Hello, World! function greeting() { console.log('Hello, bow wow!'); } 함수 표현식 (Function Expression) 함수를 정의하는 또 다른 방법으로 함수 표현식이 있습니다. 보통의 함수 선언식과 달리 함수 표현식은 익명함수를 변수에 저장하는 방식으로 구현합니다.(ES6부터 보통 const 변수에 담습니다.) 익명함수는 식별자(이름)가 없는 함수를 말합니다. 함수 표현식의 기본 문법 예제는 다음과 같습니다. 함수 표현식으로 만든 함수는 변수의 이름을 사용해서 호출합니다. variableName(argument1, argument2) 함수 표현식에서 또 한 가지 유의할 점은 hoisting이 적용되지 않는다는 것입니다. 함수 표현식은 항상 함수를 호출하기 전에 위치해야 합니다. Arrow function 함수를 짧게 정의하도록 돕는 또 하나의 방법입니다. function 키워드를 쓰는 대신 =>를 써서 함수를 선언합니다. 다음은 arrow function의 syntax 예제입니다. const greeting = (name) => { let text = `Hi, ${name}. Bow wow!` return text; }; console.log(greeting('Lucian')); // Hi, Lucian. Bow wow! Concise arrow function Arrow function은 몇 가지 조건 하에서 더욱 간결해질 수 있습니다. 먼저, 함수의 parameter가 한 개라면, () 없이 parameter를 선언할 수 있습니다. 함수의 body가 single-line block일 경우, {}은 생략할 수 있습니다. {}이 없는 경우, 해당 body의 결과는 return 키워드에 상관없이 자동으로 반환됩니다. Reference Codecademy - introduction to javascript 함수 표현식 VS 함수 선언식

JavaScript-Ecosystem · 2021-07-23

JavaScript - First step

First step of Javascript 출력 console 객체의 log 메서드를 사용해 콘솔에 출력합니다. console.log("print out something"); 주석 처리 Single line comment // something comment Multi-line comment /* something comment */ Fundamental data types Number: Any number, including numbers with decimals: 4, 8, 1516, 23.42. String: Any grouping of characters on your keyboard (letters, numbers, spaces, symbols, etc.) surrounded by single quotes: ' ... ' or double quotes " ... ". Though we prefer single quotes. Some people like to think of string as a fancy word for text. Boolean: This data type only has two possible values— either true or false (without quotes). It’s helpful to think of booleans as on and off switches or as the answers to a “yes” or “no” question. Null: This data type represents the intentional absence of a value, and is represented by the keyword null (without quotes). Undefined: This data type is denoted by the keyword undefined (without quotes). It also represents the absence of a value though it has a different use than null. Symbol: A newer feature to the language, symbols are unique identifiers, useful in more complex coding. No need to worry about these for now. Object: Collections of related data. Object를 제외한 나머지 6개의 data types는 Primitive data type이라고 부릅니다. Operator Javascript에는 다음과 같은 산술 연산자들이 존재합니다. Add: + (복합 대입 연산자는 +=) Minus: - (복합 대입 연산자는 -=) Multiply: * (복합 대입 연산자는 *=) Divide: / (복합 대입 연산자는 /=) Modulo: % (복합 대입 연산자는 %=) Increment operator: ++ (+1을 함과 동시에 할당까지 진행) Decrement operator: -- (-1을 함과 동시에 할당까지 진행) 비교 연산자는 ===를 제외하고는 다른 언어들과 비슷한 양상을 보입니다. 비교 대상은 Number 뿐만 아니라 String도 포함됩니다. Less than: < Greater than: > Less than or equal to: <= Greater than or equal to: >= Is equal to: === Is not equal to: !== 논리 연산자는 다음과 같이 사용합니다. And: && Or: || Not: ! 변수 (Variable) Javascript에서는 camel case가 변수명 convention으로 사용됩니다. favoriteFood, numOfSlices, etc… 또한, 변수는 값을 꼭 할당할 필요 없이 선언만 할 수도 있습니다. 이렇게 선언만 한 경우, 해당 변수에는 자동적으로 undefined 값이 정의됩니다. let price; console.log(price); // Output: undefined price = 350; console.log(price); // Output: 350 Javascript에서는 변수를 선언하는 키워드의 종류로 var, let, const가 있습니다. var: 새로운 변수를 생성할 수 있게 해주는 기본 키워드입니다. 2015년 등장한 ES6 버전 이전에 가장 많이 쓰였습니다. let: 변수에 다른 값이 재할당될 수 있음을 의미하는 키워드입니다. ES6 버전에서 처음 등장했습니다. let dog = 'Welsh Corgi'; console.log(dog); // Output: Welsh Corgi dog = 'Poodle'; console.log(dog); // Output: Poodle const: 변수에 다른 값이 재할당될 수 없음을 의마하는 키워드입니다. 실제로 다른 값을 재할당하면 TypeError가 발생합니다. 또한, 변수는 선언함과 동시에 값이 할당되어야 합니다. 선언만 할 경우 SyntaxError가 발생합니다. let과 마찬가지로 ES6 버전에서 처음 등장했습니다. String concatenation Javascript에서도 +를 사용해 string 간의 concatenation을 수행할 수 있습니다. const favoriteAnimal = 'Welsh Corgi'; console.log('My favorite animal: ' + favoriteAnimal); // My favorite animal: Welsh Corgi 만일 data type이 String이 아닌 data와 concatenation을 할 경우, String type으로 auto converting 되어 정상적으로 concatenation됩니다. const count = 3; console.log('There are ' + count + ' Welsh Corgies!'); // There are 3 Welsh Corgies! String interpolation ES6 버전에서는 template literal을 사용해 변수를 string에 삽입하는 interpolation을 수행할 수 있습니다. Interpolation은 `` 를 사용해 표현하며, placeholder ${변수명}`를 사용해 변수를 삽입합니다. 이렇게 만든 template literal은 문자열로서 취급됩니다. const myPet = 'Welsh Corgi'; console.log(`I own a pet ${myPet}.`); // I own a pet Welsh Corgi. Interpolation은 코드의 가독성을 높이므로, 만들어질 string의 모습을 누구나 쉽게 알 수 있다는 장점이 있습니다. Conditional statement 다음은 Javascript에 존재하는 몇 가지 조건문들의 문법입니다. Syntax of If statement if (condtion) { codeblock } else if (condition) { codeblock } else if (condition) { codeblock } else { codeblock } Syntax of ternary operator (condition) ? (codeblock when true) : (codeblock when false); Syntax example of switch statement let dog = 'Welsh Corgi'; switch (dog) { case 'Golden Retriever': console.log('Golden Retriever, bow wow!'); break; case 'Dachshund': console.log('Dachshund, bow wow!'); break; case 'Welsh Corgi': console.log('Welsh Corgi, bow wow!'); break; default: console.log('No correct dog but bow wow!'); break; } Reference Codecademy - introduction to javascript

JavaScript-Ecosystem · 2021-07-22

Secret key를 숨기는 통상적 방법

Github 같은 public한 장소에 프로젝트를 배포할 때, secret key같은 private한 정보들은 숨겨서 배포해야 합니다. 이를 위한 통상적인 방법은 환경변수를 이용하는 것입니다. 하나의 파일에 private한 정보들을 몰아놓으면, 프로젝트를 실행하기 전마다 해당 파일을 사용해 환경변수를 등록해둘 수 있고 아무일 없었듯이 프로젝트를 실행할 수 있습니다. 대표적으로 secret key를 숨기기 위해서는 secret key를 담을 secret_bash 파일, 등록된 secret key 환경변수를 가져올 settings.py파일, .gitignore 파일 총 3가지가 필요합니다. (secret_bash와 settings.py의 이름은 임의로 변경 가능합니다.) 아래는 임의의 Python 프로젝트 구조의 예시입니다. my_super_project - app - main.py | |_ settings.py |_ .gitignore |_ secret_bash 과정 해당 과정은 리눅스 기반에서 진행합니다. 사용되는 secret key는 PostgreSQL과 관련있는 예시입니다. 1. secret_bash 생성 및 설정 프로젝트의 최상위 디렉토리 밑에 secret_bash 파일을 생성하고 secret key 정보를 담습니다. 파일 내에 export 명령어를 사용하는 이유는 프로젝트를 실행하기 전마다 해당 파일을 실행해 secret key를 환경 변수로 등록할 수 있도록 하기 위함입니다. 2. settings.py 생성 및 설정 secret_bash에서 환경 변수를 export하면, 해당 환경 변수를 프로젝트로 가져올 수 있게 설정합니다. 이 과정에서 Python의 표준 라이브러리인 os 모듈을 사용합니다. os는 개발자가 간편하게 시스템적 접근을 할 수 있도록 도와주는 라이브러리로, os 라이브러리의 getenv를 사용해 등록된 환경변수를 가져옵니다. 이 때 해당 환경 변수가 존재하지 않는다면 getenv는 None을 반환하므로, 혹시나 오류가 나지 않게끔 ''(빈 문자열)을 기본값으로 지정해 반환하도록 만듭니다. 3. main,py에서 환경 변수 사용하기 현재 디렉토리에 존재하는 settings.py에서 환경 변수 값을 담았던 변수들을 import해 secret key가 필요한 곳에 사용합니다. 여기서는 PostgreSQL의 URL을 구성하기 위해 username이나 password 등을 환경 변수를 사용했습니다. 4. secret_bash 파일을 활용해 환경 변수 등록하기 앞 과정을 다 수행했다면 secret key가 잘 동작하는지 프로젝트를 실행해봐야 합니다. 프로젝트 실행 전, 터미널에서 source 명령을 사용해 secret_bash 파일의 설정 내용을 시스템에 적용합니다. source secret_bash 5. .gitignore에 secret_bash를 등록하고 github에 배포하기 .gitignore는 github에 올리지 않고 싶은 것들을 설정해두는 파일입니다. .gitignore에 secret_bash를 등록해서 프로젝트를 배포할 때 secret_bash가 무시되도록 만듭니다. (.gitignore의 상세한 문법이 존재하나 여기서는 생략하겠습니다.) 그리고 Github에 프로젝트를 배포하면, secret key가 숨겨진 상태로 프로젝트가 배포됨을 확인할 수 있습니다.

Blog · 2021-06-29

1일 1커밋 후일담

자기개발에 강렬한 욕망을 가진 개발자들이라면 ‘어떻게 하면 좋은 학습 습관을 가질 수 있을까’를 항상 고민할 것 같습니다. 그리고 이 영역에서 기초 체력을 기르기 위해 자주 언급되는 대표적인 홈트레이닝(?)으로서 1일 1커밋이 떠오릅니다. 사실 정말 많은 선배, 또래 개발자들이 1일 1커밋을 지키며 성실한 모습을 보여주셔서, 1일 1커밋의 장점과 단점은 많이 알려져 있습니다. (특히, 이동욱 개발자님 정말 존경합니다!) 부자가 되려면 부자의 습관을 따라하라는 말이 있죠? 좋은 개발자들의 성실한 모습을 닮고 싶어서, 마음 속 작은 다짐으로 (신입 입사를 위한 생존 문제라고!!!) 시작한 1일 1커밋 후기를 남깁니다 :) 사실 쓰고 싶었던 포스팅이 많이 밀려서 1일 1커밋 후기도 조금 늦었습니다. 실제 1일 1커밋을 지켰던 기간은 2020년 9월 21일부터 2021년 5월 2일까지입니다. 7개월하고 반이 조금 안되는 기간동안 ‘이건 꼭 지킬거야’라는 마음으로 잔디를 심었습니다. 연속 잔디심기의 마무리는 수업 후 밤 늦게 돌아오다 미리 작성해둔 공부 내용 커밋을 깜빡한 웃픈 헤프닝이었습니다. (ㅋㅋㅋㅋ) 사실 1일 1커밋의 장단점은 명확한 것 같습니다. 언제나 질 좋은 잔디를 심을 수는 없습니다. 밝은 초록색도 아쉬울 잔디가 종종 심어지게 됩니다. 그럼에도 조금이라도 알찬 잔디를 심어보고자 매일 다짐하고 실천하게 됩니다. 학습을 제대로 수행하지 못한 날에는 알고리즘 문제라도 하나 더 풀어서 정리했습니다. 놀랐던 점은 알고리즘 문제 같이 하나는 굉장히 작은 것들도 하루하루 잊지않고 쌓아나가면 어느새 목표했던 분량까지 성취하게 된다는 부분입니다. 덕분에 ‘꾸준히’의 힘과 중요성을 체감했습니다. 또한, 1일 1커밋이 끝난 후에도 능동적인 커밋 습관을 얻는 계기가 됩니다. 커밋하는 것이 일상이 되니 이전보다 빈도는 조금 줄어도 학습한 것을 잊지않고 기록하려고 합니다. 최근 잔디는 과거에 비해 더 자유분방(?)해졌습니다. 커밋에 대한 강박관념을 지우고 이전보다 조금 더 자유롭게 학습을 기록하는데 중점을 두고 있습니다. 잔디가 비었다고 공부를 안하는 것은 아니니까요! 사실 처음에는 성실함을 어필하자는 마음으로 시작했는데, 결과적으로는 기초체력을 끌어올리는 흥미로운 도전이었습니다. 개인적으로 Phase 1이 끝나고 Phase 2에 돌입했다고 생각합니다. 앞으로의 잔디 심기는 비울 곳은 비우고 채울 곳은 더 진한 잔디들로 채우려고 합니다 :)

Blog · 2021-06-22

데이터베이스

Computer Science · 2021-06-21

블록체인 Overview

블록체인(Blockchain)의 개념 공식적 정의 Blockchain Security Technology라고 하며, 데이터를 담은 블록을 체인 형태로 연결한 다음 동시에 수많은 컴퓨터에 복제와 저장을 하는 분산형 데이터 저장 기술을 말합니다. 중앙 서버에 거래 내역을 저장하지 않고 거래를 할 때마다 수많은 거래 참여자들에게 거래 내역을 공유하기 때문에 위조, 변조가 거의 불가능합니다. 특징 Append(추가): 블록체인에서 블록은 오직 추가만 할 수 있습니다. Decentralization(탈중앙화): 특정 개인이 블록체인 DB를 관리할 수 없습니다. 쉬운 개념 설명 블록체인은 일종의 데이터베이스로, 각각의 블록은 데이터로 생각할 수 있습니다. 특별한 점은 데이터를 추가(Append)만 할 수 있다는 것입니다. 블록체인 DB에 연결된 블록 데이터는 편집 및 삭제가 불가능합니다. 대학교 학위, 정부 단위에서 운전면허증, 지원금 사용 내역, 혹은 개인의 전세 계약서 등 안전한 보관이 필요한 영역에서 데이터를 기록하는데 활용될 수 있습니다. 또한, 블록체인 참여자 모두가 DB의 복제본을 가지고 있어서(Decentralization) 특정 개인이 DB를 관리할 수 없습니다. 특정 개인이 갑자기 100억원어치 비트코인을 가지고 있다고 DB를 조작해도 다른 사람들의 블록체인 사본과 비교하면 쉽게 거짓이 감별됩니다. 이로 인해, 나아가 정부의 독단적인 감시나 통제에도 공동으로 대응할 수 있습니다. 이 검증이 확실한 동작하는 이유는 너무나 많은 사람들이 비트코인 노드를 돌리고 있어 모든 컴퓨터가 일제히 종료되어 있지 않는한 공동의 감시를 벗어나기 어렵기 때문입니다. 현실적으로 모두의 컴퓨터가 동시에 종료되는 일은 불가능합니다. 블록체인 생성 과정 블록의 형태 블록은 정보를 DB에 추가하는 방법입니다. 그리고 하나의 블록은 block hash, 이전 블록의 block hash, block data로 구성됩니다. 먼저 block data에는 해당 영역의 data가 담깁니다. 비트코인의 경우 거래 내역(transaction) 데이터가 해당됩니다. 그리고 현재 블록의 block hash에는 이전 block의 hash 값과 지금의 데이터를 함께 해시한 값이 담깁니다. 이렇게 해시를 통해 블록을 쌓아가면, 블록체인에 어떤 작은 조작만 가해도 결과로 나올 해시값이 크게 달라지기 때문에 보안이 안전하게 유지됩니다. 해시(Hash)란? 어떤 데이터를 특정 알고리즘을 사용해 고정된 길이를 가진 기묘한 모습의 데이터로 변환시킨 값을 말합니다. 해시를 사용하면 Input 데이터로 Output 데이터를 만들 수 있지만, 만들어진 Output data를 Input data로 되돌릴 수는 없습니다. 채굴자(Miner)의 역할 비트코인의 경우에는 10분마다 블록이 생성되어 블록체인에 추가됩니다. 그렇다면 블록에는 어떠한 데이터가 담겨야 하고, 이 블록을 생성하는 사람은 누구일까요? 우선 블록체인에 추가될 데이터는 상황에 따라 누구든지 올릴 수 있게 하기도, 아무나 올릴 수 없게 하기도 합니다. 아무나 올릴 수 없게 하는 경우는 안전과 정확함이 중요한 금융 관련 데이터, 정부 관련 데이터 등이 해당될 것입니다. 이러한 경우, 데이터에게 요구되는 속성은 진실성(Truth)입니다. 블록체인에 추가될 데이터는 거짓 없는 진실이어야 합니다. 그리고 데이터의 진실성 검증은 작업 증명(Proof of Work)을 통해 이뤄집니다. 작업 증명은 전 세계 채굴자(Miner)들에 의해 진행됩니다. 채굴(Mining)이란 주어진 데이터를 작업 증명하여 블록을 생성 및 추가한 후, 이에 대한 보상으로 해당 거래에 대한 수수료와 암호화폐(Cryptocurrency)를 받아가는 작업을 말합니다. 조금 더 자세히 얘기하면, 작업 증명이란 네트워크가 내는 어떠한 문제를 해결하는 것이고 이를 완료하면 이에 대한 보상이 지급됩니다. 채굴 작업은 전 세계 누구든지 참여할 수 있으나 해결해야 할 문제의 난이도는 시간이 지날수록 더욱 높아집니다. 채굴자의 작업은 단순합니다. 채굴자는 오직 Nonce라는 파라미터만 조작할 수 있고, 문제에서 원하는 해시값을 생성해내는 Nonce를 찾아 네트워크에게 알려주면 됩니다. 예를 들어, 해시값이 3개의 0으로 시작하기 위해서 어떠한 Nonce를 사용해야 하는지가 문제로 제시되면, 채굴자는 Nonce 값을 일일이 넣어보면서 해시값을 생성하고 비교해 완전 탐색으로 Nonce 값을 찾아냅니다. 문제를 푼 채굴자들은 블록을 생성해 해당 블록체인에 추가하고, 작업 증명에 대한 보상으로 해당 거래에 대한 수수료와 코인을 받아갑니다. 암호화폐(Cryptocurrency) 암호화폐는 채굴자들의 작업 증명 보상으로서 주어집니다. 이 때, 암호화폐는 채굴자의 작업 증명과 함께 새로 생성됩니다. 예를 들어 비트코인은 채굴자가 작업 증명을 함과 동시에 생성되어 채굴자의 지갑으로 지급됩니다. 암호화폐들은 생산량이 제한 되어 있는 경우에 가치가 상승합니다. 비트코인의 경우, 2100만개로 생산량이 한정되어 있어 희소성을 가집니다. 다만, 한정된 생산량에 너무 빨리 도달하지 않게끔 하기 위해 생산이 너무 빨리 진행되면 문제의 난이도를 올리는 등의 조정을 취합니다. (현재 난이도는 19이며, 생성하는 해시값이 19개의 0으로 시작해야 합니다.) 특히, 4년마다 한 번씩 반감기라는 것을 가지면서, 처음엔 작업 증명으로 50개씩 발급되었던 비트코인이 25, 12.5를 거쳐 현재는 6.25개씩 지급되고 있습니다. 그래픽카드(Graphic Card) 최근 그래픽 카드의 값이 급등하는 이유는 채굴 작업과 관련이 깊습니다. 그래픽 카드는 Nonce 탐색을 매우 빠르게 진행하기 때문입니다. 대략 6천만 Nonce를 1초만에 계산한다고 하니, 채굴자들은 그래픽 카드를 가능한한 총동원해 코인 채굴에 사용하길 원합니다. Smart Contract 블록체인의 공유 네트워크를 활용해서 개인의 코드를 모두가 공유, 검증, 실행하지만 수정은 할 수 없는 백엔드에 올리는 작업을 말합니다. 예를 들어, Airbnb같이 집을 중개해주는 서비스 도움 없이 개인이 직접 도어록 같은 센서에 기반한 코드(봇)를 만들고, 이 코드를 통해 서로 금액을 교환할 수 있습니다. 덕분에 개인과 개인 사이에 중개인이 필요없어지고 정부와 단체에 조종당할 염려가 사라집니다. 다만, 네트워크 외부의 IoT 센서 혹은 무언가에게 의존해야하는 신뢰기반 거래가 형성되어 버려서, 센서가 해킹당했을 때의 위험성이 단점으로 존재합니다. 스마트 컨트랙트를 지원하는 블록체인은 Ethereum, Polcadot, Cardano, Kusama 등 다양합니다. 대체 불가능한 토큰 (NFT, Non Fungible Token) Non Fungible이란 땅, 포켓몬 카드, 한정판 신발 등 대체 불가능한 것들을 말합니다. 즉, NFT는 어떠한 블록체인 기술을 기반으로 이미지, 영상 등의 콘텐츠에 고유한 표식을 부여하는 디지털 자산입니다. 이러한 표식은 해당 자산이 원본임을 증명해줍니다. 이로 인해, 디지털 재산권 개념과 함께 디지털 자산에 대한 소유권 주장이 가능해집니다. DeFi 탈중앙화된 금융 서비스를 의미하며, 중간 거래자나 서드파티없이 스마트 컨트랙트로 모든 거래가 오고 가는 형태를 띕니다. 사람의 손을 전혀 거치지 않고 100% 코드로 돌아가기 때문에, 중간에서 중개 수수료가 지불되거나 관리자에 의해 계좌가 동결될 일이 없습니다. Reference 블록체인. 개발자가 쉽게 설명해드림. - 노마드 코더 BlockChain 기초 개념 - 블록, 채굴, 작업증명, 난이도, 보상 미국 기자들 ‘교과서’ “암호화폐 ‘크립토’로 줄이지 말라”

General · 2021-06-16

9-2. 가상 메모리

Page replacement - 다양한 캐싱 환경 캐싱 기법 한정된 빠른 공간(=캐쉬)에 요청된 데이터를 저장해 두었다가 후속 요청시 캐쉬로부터 직접 서비스하는 방식이다. 즉, 한 번 썼던 데이터는 빠른 접근이 가능한 캐쉬 메모리에 저장해두었다가 가까운 시기에 해당 데이터에 대한 접근이 요청되면 빠르게 제공해준다. Paging system과 더불어 cache memory, buffer caching, Web caching 등 다양한 분야에서 사용되는 방식이다. 캐싱 기법의 운영상 시간 제약 다만, 이러한 캐싱 기법은 운영상 시간 제약이 존재한다. 교체 알고리즘이 삭제할 항목을 결정하는 일에 지나치게 많은 시간을 소요하지 않아야 한다. 예를 들어, Buffer caching이나 Web caching의 경우 시간 복잡도가 O(1) ~ O(logN) 정도까지 허용한다. 반면, Paging system에서는 기존의 LRU, LFU 등의 삭제 항목 결정 알고리즘이 실제로 사용되기는 어렵다. Paging system의 경우 page fault가 생길 때만 OS가 관여하기 때문에, 페이지가 이미 메모리에 존재하는 상황에서의 참조 시각 정보는 OS가 알 수 없다. 즉, 특정 상황의 참조 시각과 참조 빈도 등을 알 수 없으므로, 앞에서 살펴봤던 LRU, LFU 등의 알고리즘은 실제 시스템에서는 사용되기 어렵다. Clock Algorithm (=Second Chance Algorithm) 캐싱 제약을 극복하기 위해, paging system에서는 일반적으로 Clock Algorithm이 쓰인다. 이 알고리즘에서는 각각의 page table entry에 최근에 참조함을 나타내는 reference bit을 둔다. 그리고 이미 메모리에 올라와 있는 페이지에 대해 참조가 일어날 경우, 하드웨어가 reference bit을 1로 바꿔 최근에 참조함을 기록한다. 그리고 메모리에 새로운 page를 올려할 상황이라 OS가 내쫒을 page를 결정할 때에는 위와 같은 과정으로 reference bit을 참고해 오래된 page를 내쫒는다. 또한, 조금 더 개선된 성능을 위해 modified bit을 둬서 page에 write가 일어났는지 여부를 기록한다. 만일, modified bit이 1인 page가 있다면 해당 페이지는 메모리에 올라와서 최근에 내용이 변경된 것이기 때문에, backing storage로 쫒아낼 때 변경된 내용을 반영하고 쫒아내야 한다. Page Frame의 Allocation 지금까지는 페이지가 어떤 프로세스에 속하느냐를 구체적으로 고려하지 않고 작업을 수행했다. 하지만, 각 프로세스마다 얼마만큼의 page frame을 할당한 것인가는 중요한 문제이다. 메모리 참조 명령어 수행시 명령어, 데이터 등 여러 페이지를 동시에 참조하게 되는데, 이 명령어 수행을 위해 최소한 할당되어야 하는 frame 수가 있기 때문이다. 예를 들어, 반복문을 구성하는 page가 3개라고 한다면, 3개가 한번에 할당되는 것이 좋다. 2개가 할당된다면, 매 loop마다 page fault가 일어나 원활한 수행에 방해가 된다. 3가지 Allocation 방법 (∝ Local repacement) Equal Allocation: 모든 프로세스에 똑같은 갯수 할당 Proportional Allocation: 프로세스 크기에 비례하여 할당 Priority Allocation: 프로세스의 priority에 따라 다르게 할당 Global replacement VS Local replacement Global replacement는 따로 프로세스마다 할당되어야할 frame 개수를 정해놓지 않더라도 알고리즘을 수행하다보면 알아서 필요한 프로세스에 page가 더 많이 할당되는 것을 말한다. 반면에, Local replacement는 프로세스마다 할당할 page 개수를 정해둔 것을 말한다. Thrashing 프로세스의 원활한 수행에 필요한 최소한의 page frame 수를 할당받지 못한 경우 발생한다. 위 그래프와 같이, 메모리에 동시에 올라온 프로세스 개수가 많아질수록, 특정 순간에 CPU 이용률이 급감해버리는 thrashing 현상이 발생한다. 보통 위와 같은 과정을 거쳐 thrashing으로 이어진다. 이를 해결하기 위해 두 가지 알고리즘을 소개한다. Working-Set Algorithm VS PFF (Page-Fault Frequency) Scheme (∝ Global repacement) Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-06-11

9-1. 가상 메모리

이번 챕터부터는 메모리 관리 기법 중 paging 기법을 사용하는 것을 가정한다. 실제로도 대부분의 시스템은 paging 기법을 채택하고 있다. Demand Paging 실제로 특정 page에 대한 요청이 있을 때 해당 page를 메모리에 올리는 것을 말한다. 프로그램에는 안정적인 실행을 위해 방어적으로 넣은 자주 쓰이지 않는 코드 영역들이 매우 많이 존재한다. 그렇기에 실제로 쓰이는 코드들만 메모리에 올리면, I/O 양과 메모리 사용량을 크게 감소시킬 수 있고 더 많은 사용자들이 멀티 프로세싱할 수 있는 환경이 만들어진다. Demand Paging에서 페이지 테이블의 entry에 존재하는 valid/invalid bit의 역할을 살펴보자. Invalid는 주소 영역에서 사용되지 않는 부분이나 페이지가 물리적 메모리에 올라와 있지 않은 상황을 의미한다. 처음에는 모든 page entry가 invalid로 초기화되어 있다. 그리고 주소 변환시 해당 페이지가 invalid로 세팅되어 있다면, page fault를 일으킴과 동시에 trap을 걸어 운영체제에게 CPU를 넘기고 page fault가 난 페이지를 메모리에 올리게끔 한다. Page fault에 대한 처리 루틴은 운영체제에 정의되어 있으며, 구체적으로는 위 그림과 같은 과정을 거친다. Backing storage에서 메모리에 페이지를 올리는 디스크 I/O는 시간이 오래걸리기 때문에, page fault가 얼마나 나느냐에 따라 메모리 접근 시간에 차이가 날 수 있다. 위의 Effective Access Time에서 p는 보통 굉장히 작아서 대부분의 경우 page fault가 나지 않는다. 하지만, 적은 확률로 page fault가 나는 상황에서는 위의 붉은 글씨의 요인들처럼 큰 시간적 오버헤드가 발생함을 유의한다. Page replacement 메모리에 여유 공간이 필요할 때, 운영체제가 어떤 frame을 빼앗아서 page를 쫒아낼지 결정하는 것을 Page replacement라고 한다. 이것을 구현하는 알고리즘을 Replacement Algorithm이라고 하는데, page fault rate을 최소화하는 방향으로 page를 쫒아내도록 알고리즘을 잘 설정해야 한다. Optimal Algorithm (실제로 쓰이진 않음) Optimal Algorithm은 가장 먼 미래에 참조되는 page를 replace하는 방식으로 Page fault를 최소화하는 알고리즘이다. 위 예시처럼, 미래의 page 참조를 전부 안다고 가정하고 진행하기 때문에 실제로 시스템에서 쓰이진 않지만, 가장 최고의 성능을 나타내는 지표로서 다른 알고리즘들의 성능에 대한 upper bound를 제공한다. FIFO Algorithm (실제로 쓰임) 간단하게 먼저 올라온 page를 먼저 쫒아내는 방식이다. 특이한 점은 frame 수를 늘리면 성능이 좋아져야 할 것 같지만, FIFO 알고리즘에서는 오히려 성능이 떨어지는 현상이 발생하는데, 이를 FIFO Anomaly 혹은 Belady’s Anomaly라고 부른다. LRU (Least Recently Used) Algorithm (실제로 쓰임) LRU(Least Recently Used) 알고리즘은 참조의 측면에서 가장 오래 전에 참조된 page를 쫒아내는 방법이다. 얼핏보면 FIFO와 비슷하지만, FIFO보다 효율적으로 동작하여 더 많이 쓰이는 알고리즘이다. LFU (Least Frequently Used) Algorithm (실제로 쓰임) LFU(Least Frequently Used) 알고리즘은 참조 횟수가 가장 적은 page를 쫒아내는 방법이다. 동일한 참조 횟수를 기록 중인 page가 여럿 있을 때는 일반적으로 큰 의미를 두지 않고 알고리즘이 임의로 쫒아낸다. 다만, 그 중에서도 가장 오래 전에 참조된 page를 쫒아내도록 알고리즘을 설계하는 것이 성능 향상에 이로울 수 있다. LRU VS LFU LRU는 참조 시점의 최근성을 반영한다. 반면에 LFU는 장기적인 측면에서 page의 인기도를 더 정확히 반영하는 장점이 있다. 다만, LFU는 LRU보다 구현이 복잡하다. LRU의 경우는 시간에 따라 일렬로 줄 세우고 가장 최근에 참조했던 페이지를 내쫒으면 된다. 따라서, Linked List 자료구조로 구현하여, 페이지를 내쫒는 작업을 O(1) 시간 복잡도로 수행하게끔 한다. 반면에, LFU는 페이지의 참조 빈도가 계속 바뀌기 때문에, heap 자료구조를 사용하여 지속적으로 정렬하는 방법을 사용한다. 이 경우 페이지를 내쫒는 작업은 O(log n)의 시간 복잡도로 수행된다. Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-06-10

8-2. 메모리 관리

Allocation of Physical Memory 메모리는 일반적으로 Interrupt vector와 함께 낮은 주소 영역을 사용하는 OS 상주 영역과 높은 주소 영역을 사용하는 사용자 프로세스 영역 둘로 나뉜다. 사용자 프로세스 영역의 할당 방법 1. Contiguous allocation (연속 할당) 각각의 프로세스가 메모리의 연속적인 공간에 적재되도록 하는 것이다. 연속 할당 방식은 두 가지가 존재한다. 고정 분할 방식 프로그램이 들어갈 사용자 메모리 영역을 미리 파티션(partition)으로 나눠놓는 것을 말한다. 이 경우, 동시에 메모리에 load되는 프로그램의 수가 제한되고 최대 수행 가능 프로그램 크기도 제한된다. 위 그림을 예시로 보면 메모리 영역은 이미 고정되어 나뉘어져 있고 프로그램 A와 B는 각각 자신의 크기에 맞는 파티션을 찾아 그 위에서 실행된다. 이 과정에서 프로그램을 담을만큼 충분한 용량을 가지지 못해 남겨진 메모리 영역을 의미하는 외부 조각과 파티션에서 프로그램이 실행되고 남은 메모리 영역을 의미하는 내부 조각이 발생한다. 가변 분할 방식 사용자 메모리 영역을 미리 나눠놓지 않는 방법을 말한다. 가변 분할 방식은 프로그램의 크기를 고려해 프로그램들을 차곡차곡 메모리 영역에 할당한다. 이 때, 앞서 실행된 프로그램이 종료되거나 새로운 프로그램이 실행됨에 따라 남겨져버는 메모리 영역, 즉 외부조각이 발생할 수 있다. 이 가용 메모리 공간을 Hole이라고 하는데, 운영체제는 할당 공간과 흩어져 있는 가용 공간(hole)을 잘 고려해서 프로그램의 실행을 매끄럽게 도와야 한다. 한편, 가변 분할 방식에서는 미리 정해진 파티션이 없기 때문에 내부 조각은 발생하지 않는다. Dynamic Storage Allocation Problem 가변 분할 방식에서 size n인 요청을 만족하는 가장 적절한 hole을 찾는 문제를 말한다. First-fit과 Best-fit이 Worst-fit보다 속도와 공간 이용률 측면에서 더 효과적인 것으로 알려져 있다. First-fit Size가 n이상인 것 중에 최초로 찾아지는 hole에 할당하는 방법이다. Best-fit Size가 n이상인 가장 작은 hole을 찾아서 할당하는 방법이다. 많은 수의 아주 작은 hole들이 생성되며, hole들의 리스트가 크기순으로 정렬되지 않은 경우 모든 hole의 리스트를 탐색해야 한다. Worst-fit 가장 큰 hole에 할당하는 방법이다. 이 역시 hole들의 리스트가 크기순으로 정렬되어 있지 않으면, 모든 리스트를 탐색해야 하고, Best-fit과는 달리 상대적으로 아주 큰 hole들이 생성된다. Compaction 사용 중인 메모리 영역을 한 군데로 몰고 hole들을 다른 한 곳으로 몰아 큰 block을 만듦으로써 외부조각 문제를 해결하는 방법이다. 다만, Run time binding이 지원되어야 수행 가능하고, 최소한의 메모리 이동을 고려하는 복잡한 문제를 해결해야 하기 때문에 비용이 매우 많이 든다는 단점이 있다. 2. Noncontiguous allocation 하나의 프로세스가 메모리의 여러 영역에 분산되어 올라갈 수 있는 방법을 말한다. Paging 기법 프로세스의 virtual memory를 동일한 사이즈의 page로 나누는 방법이다. 따라서 virtual memory의 내용이 page 단위로 비연속적으로 저장되며, 일부는 backing storage에, 일부는 physical memory에 저장된다. Paging 기법을 사용하기 위해서 physical memory를 동일한 크기의 frame으로, logical memory를 동일한 크기의 page로(frame과 같은 크기) 나눠야 한다. 그리고 기존과 달리 page table을 사용해서 logical address를 physical address로 주소 변환한다. 이 기법을 사용하면 가장 마지막 페이지로 인해 발생하는 내부 조각은 존재할 수 있지만, 마지막 page를 제외한 모든 page와 frame의 크기가 동일하기 때문에 외부 조각은 발생하지 않는다. 위 그림으로 조금 더 자세히 살펴보자. CPU가 어떤 논리적 주소를 주면, 논리적 주소의 앞 부분 p는 페이지 번호가 되고, 뒷 부분 d는 페이지 번호의 주소에서 얼마나 떨어져 있는지 알려주는 offset이 된다. 따라서, p를 page table의 entry(=index)로 사용하면, 페이지 번호에 해당하는 frame 번호 f를 구할 수 있고 논리적 주소를 물리적 주소로 변환할 수 있게 된다. 그렇다면 위의 page table의 구현은 어떻게 이루어질까? 앞서 살펴본 기존의 연속 할당 방식에서는 MMU를 이용한 2개의 레지스터(base register, limit register)만으로 주소변환을 충분히 할 수 있었다. 하지만 불연속 할당 방식을 사용하는 paging 기법에서는 page table을 따로 두고 기존과 다르게 처리한다. 일단, Paging 기법에서 프로세스는 주로 4KB의 크기의 수많은 페이지로 나뉘어진다. 그래서 상당히 많은 entry 정보를 저장해야 하는 page table은 그 용량을 감당하기 위해 physical memory에 상주하게 된다. 즉, CPU의 논리적 주소를 주소 변환하기 위해서는 총 2번(page table 접근 한 번, 실제 data/instruction 접근 한 번) physical memory에 접근하게 된다. Page table 운용에 사용되는 Register의 경우에는 page table을 가리키는 Page-table base register(PTBR)과 테이블 크기를 보관하는 Page-table length register(PTLR)이라는 2개의 register를 사용한다. 또한, 속도를 높이기 위한 하드웨어 측면의 방책으로 associative register나 translation look-aside buffer(TLB)라는 고속 lookup hardware cache를 사용한다. TLB에 대하여 그림으로 살펴보자. 위 그림처럼 paging 기법에서 주소 변환을 수행하려면 두 번의 메모리 접근을 해야 하기 때문에, TLB라는 하드웨어의 지원을 통해 속도를 더 빠르게 가져갈 필요가 있다. TLB는 실제 캐쉬 메모리와는 다르지만 주소 변환만을 위한 일종의 캐쉬 메모리 역할을 하는데, page table에서 자주 쓰이는 일부 entry들을 TLB에 저장해두고 메모리보다 조금 윗단에서 entry를 빠르게 가져다 쓸 수 있게 해주는 역할을 한다. 즉, CPU가 주는 논리적 주소를 주소 변환할 때 먼저 TLB를 살펴보고, 만약에 TLB에 해당 entry가 있다면 한 번의 메모리 접근을, TLB에 entry가 없다면 원래대로 두 번의 메모리 접근을 한다. 유의할 점은 page table의 경우 page number를 index로 바로 frame number를 알 수 있는 반면, TLB는 page number와 frame number가 쌍으로 이루어져 있어서 frame number를 알고 싶다면 전체 TLB의 원소를 모두 다 검색해봐야 검색 유무를 판단할 수 있다는 것이다. 따라서, 이 검색을 원활히 진행시키기 위해 associative register들로 parallel search가 가능하도록 해 단번에 frame number를 알 수 있도록 만든다. 또한, page table은 각 프로세스마다 다르게 존재하므로, 이에 대응하기 위해 context switch가 일어날 때마다 TLB는 flush되어야 한다. 앞서 살펴본 것을 토대로 메모리 접근 시간을 파악해보면 위와 같다. 결론적으로 1보다 작은 값 입실론과 1에 아주 가까운 알파 값으로 인해 EAT(Effective Access Time)는 2보다 작아지게 되어, 적어도 메모리에 두 번 접근하는 것보다 나은 방법이 된다는 것이 증명된다. Two-Level Page Table (2단계 페이지 테이블) Two-Level Page Table은 위와 같이 바깥 page table과 안쪽 page table 두 개를 활용하는 방법이다. 본래의 Page Table에서는 공간적 낭비가 발생하기 때문에, 이를 막고자 나타난 것이 Two-Level Page Table이다. 현대 컴퓨터는 address space가 매우 큰 프로그램도 잘 지원할 수 있는데, 용량이 큰 프로세스라고 할지라도 대부분의 프로그램은 자신의 주소 공간의 매우 일부분만 사용한다. 이 경우, 기존의 page table은 배열이기 때문에 논리적 주소의 일부분만 사용되어 빈공간이 생기더라도 전체의 주소 공간을 저장할 수 있게끔 생성된다. 즉, 이 과정에서 생기는 빈공간들이 공간적 비효율성을 야기한다. 사실 바깥 page table과 안쪽 page table 두 가지를 사용하니까 시간적으로나 공간적으로나 더 낭비가 클 것 같지만 실제로는 충분한 이점이 있다. 앞서 말햇듯이 프로세스의 주소 공간 중 거의 쓰이지 않는 부분이 훨씬 많기 때문에, 바깥 page table에서 해당 부분들을 Null로 처리해버리면 Null로 처리된 곳에는 안쪽 page table이 생성되지 않아 공간적인 낭비가 감소하는 효과가 있다. Two-Level Page Table은 위와 같이 바깥 page table 속의 entry마다 안쪽 page table을 둬서 이 page table들을 두 번 거친 후에 물리적 메모리 주소에 도달하게 한다. 이 때, 안쪽 page table 각각의 크기는 4KB로 본래의 page의 크기와 동일하게 된다. Two-Level Page Table의 주소 공간에 대한 bit 수 분배는 위의 예시와 같으니 참고하도록 하자. Multi-Level Paging 프로세스의 주소 공간이 더 커지면, 다단계 페이지 테이블이 효율적이다. 페이지 테이블이 더 많아져 메모리 접근 횟수 역시 더 많아질 수 있지만, 공간 낭비를 더욱 줄일 수 있다. 또한, TLB를 사용하면 메모리 접근 횟수 및 총 소요 시간도 크게 줄일 수 있다. 예를 들어, 4단계 페이지 테이블을 이용하는 경우만 해도 위와 같이 메모리 접근 시간이 크게 소요되지 않음을 알 수 있다. Paging 기법에 관한 몇 가지 Issue 페이지 테이블의 Valid / Invalid bit 페이지 테이블에는 해당 페이지가 실제로 사용되느냐 안되느냐를 표현하는 valid-invaild bit이 존재한다. Valid는 해당 주소의 frame에 프로세스를 구성하는 유효한 내용이 있어 접근을 허용함을 뜻하고, invalid는 해당 주소의 frame에 유효한 내용이 없어 접근을 허용하지 않음을 뜻한다. Invalid에서 해당 주소 frame에 유효한 내용이 없다는 것은 프로세스가 해당 주소 부분을 사용하지 않는 경우 혹은 해당 페이지가 메모리에 올라와 있지 않고 swap area에 있는 경우를 말한다. 만일 프로세스의 주소 공간에서 거의 쓰이지 않는 영역에 해당하는 페이지라면 invalid임을 표시해 구분하는 것이 유용하다. Frame number를 0으로 두는 것만으로는 그것이 0번 frame을 의미하는 것인지 메모리에 올라와 있지 않다는 것을 말하는지 분별할 수 없기 때문이다. 페이지 테이블의 Protection bit 페이지 테이블에는 또 하나의 bit이 존재한다. Protection bit이라고 불리는 이 bit은 해당 page의 연산(read/write/read-only)에 대한 권한을 부여한다. 프로세스에는 code, stack, data 영역이 있는데, code 부분에 해당하는 page의 경우 내용이 바뀌면 안되기 때문에 read only 연산만 가능하게 설정하고 다른 영역은 read, write 모두 가능하게 설정한다. Inverted Page Table 기존 page table의 큰 공간 낭비 문제를 해결하기 위한 또 하나의 방법이다. 기존 page table이 page number에 따라 page table entry를 만드는 것과 달리, inverted page table은 frame number에 따라 page table entry를 만든다. 그렇기에 page table도 프로세스마다 존재하는 것이 아니라 시스템에 단 하나 존재한다. 그리고 이를 보완하기 위해 page table 각각의 entry에 프로세스 ID를 추가로 넣어줘 어떤 프로세스의 page인지 구분할 수 있도록 한다. Inverted 방식의 page table은 한 개만 존재함으로써 공간 낭비를 극적으로 줄일 수 있다. 다만, 주소 변환을 하기 위한 시간적 overhead는 커지기 때문에, associative register를 활용해 병렬적으로 page table 검색을 하게끔하는 방식을 보완해 사용한다. Shared Page Shared page는 shared code가 page로 나뉠 때 사용되는 용어이다. Shared Code(=Re-entrant Code =Pure code)는 프로세스마다 동일한 프로그램을 실행함으로 인해 같은 코드가 쓰이는 경우에 read-only 상태로 공유하고 메모리에 올리는 하나의 코드를 말한다. 예를 들어, Text editor나 compiler, window systems 같은 프로그램들은 굳이 코드를 여러번 중복할 필요가 없기 때문에, shared code로 공유한다. 이러한 shared code는 모든 프로세스의 논리적 주소 공간에서 동일한 위치에 있어야 하며, 각 프로세스의 독립적인 private code와 data는 프로세스의 논리적 주소 공간 어디에 위치해도 상관없다. Segmentation 기법 이제 또 다른 대표적인 불연속 할당 방식으로 Segmentation 기법을 알아보자. Segmentation은 프로그램을 의미 단위로 구성된 여러개의 segment로 나누어 할당하는 방식이다. Segment는 크게는 프로그램 전체, 작게는 함수 하나하나로 정의 될 수 있는데, 일반적으로 code, data, stack 영역이 하나씩 segment로 분류된다. Segmentation에서 논리적 주소는 segment-number와 offset으로 구성된다. 또한 Paging 기법과 비슷하지만 다르게 사용되는 segment table이 존재하며, 테이블 내 각각의 entry에는 segment의 물리적 주소 시작점을 담는 base와 segment의 길이를 담는 limit이 존재한다. 또한, 물리적 메모리에서 segment table의 위치를 담는 Segment-table base register(STBR)와 프로그램이 사용하는 segment의 수를 기록하는 Segment-table length register(STLR)가 존재한다. 위의 그림에서 CPU가 논리적 주소를 주게 되면, segment table에서 논리적 주소의 segment 번호 s에 해당하는 entry를 찾게 된다. 그리고 entry에서의 base 값과 논리적 주소의 offset d를 이용해 물리적 주소에 접근한다. 또한, 물리적 메모리에 접근하기 전에 해당 entry에서 limit 값을 확인하여, 논리적 주소의 offset 값이 프로그램의 주소 범위를 벗어나지 않았는지 파악한다. Paging 기법과 달리 각각의 Segement는 길이가 다르기 때문에, entry에 존재하는 limit 값을 통해 segment의 길이를 결정짓는 것이 중요하고, 이를 활용해 프로그램의 범위를 벗어나는 악의적인 접근에 대해 trap을 건다. Segmentation은 segment 각각의 길이가 동일하지 않으므로 외부조각이 발생하는 문제가 있다. 하지만, read/write/execution 등의 권한을 부여하는 protection 작업이나 각각의 프로세스가 동일한 코드를 공유하는 sharing 작업에서는 의미 단위를 강조하는 Segmentation이 매우 효과적이라는 장점도 있다. 위 그림은 Segmentation의 한 예시인데, paging 기법의 크기가 4KB인 수많은 page 개수에 비하면 segment의 개수는 현저히 적음을 알 수 있다. 프로그램이 의미 단위로 큼직큼직하게 쪼개지기 때문에 위 예시에서는 segment의 개수가 5개밖에 되지 않는다. 대신 segment의 용량은 4KB로 크기가 고정되어 있는 page에 비하면 매우 커질 수 있다. 또한, segment의 개수가 적어짐에 따라 segment table의 entry 개수도 적어지므로, page table과 달리 table로 인한 공간 낭비가 현저하게 감소한다. Paged Segmentation (=Segmentation with Paging) Paged Segmentation은 Paging 기법과 Segmentation 기법을 혼합하여 Segmentation된 각각의 segment에 paging을 적용하는 방법이다. 이렇게 혼합 방식을 사용하면 Segmentation에서 발생하는 외부 조각 문제를 해결하고 protection과 sharing은 본래의 의미 단위대로 처리할 수 있어 유용하다. 실제로도 순수한 Segmentation만을 사용하는 컴퓨터는 없으며 Segmentation을 사용한다면 이렇게 Paging과 혼합적으로 운용한다. Paged Segmentation의 과정을 살펴보자. 위 그림에서 CPU가 논리적 주소를 주면 segment 번호 s를 사용해 segment table의 해당 entry에 접근한다. 그리고 offset d가 해당 entry의 limit 값을 넘어가지 않는다면, d에 존재하는 페이지 번호 p를 사용해 해당 segment에 mapping된 page table의 entry에 접근한다.(offset d가 limit 값을 넘어간다면, trap을 건다.) 그 후, entry에 해당하는 프레임 번호 f와 d에 존재하는 offset d’을 더해 물리적 주소로 변환을 완료한다. Memory Management 챕터에 관하여 메모리 관리 챕터는 물리적 메모리에 관하여 다뤘다. 이 메모리 접근 과정에서 운영체제의 역할은 없었고, 오직 하드웨어의 역할만 있었음을 유의하자. Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-06-09

8-1. 메모리 관리

Symbolic Address VS Logical Address VS Physical Address 1. Symbolic Address 프로그래머 입장에서 메모리를 다룰 때, 숫자가 아닌 변수명, 함수명 등으로 메모리를 조작하는 상징적 주소 Symbolic Address가 compile되면 숫자로 된 Logical Address가 됨 2. Logical Address (=Virtual Address) 프로세스마다 독립적으로 가지는 주소 공간 각 프로세스마다 0번지부터 시작 CPU가 보는 주소 3. Physical Address 실제 메모리에 올라가는 위치 프로그램이 실행될 때, Logical Address를 Physical Address로 주소 변환 (주소 바인딩) 주소 바인딩 (Address Binding) 어떤 프로그램이 실행되기 위해서는 물리적 주소에 올라가야 하는데, 물리적인 주소 어디로 올라갈지 결정하는 것을 의미한다. 현대 컴퓨터는 어떤 프로그램을 실행할 시 프로그램 내 instruction들을 산발적으로 여러 메모리 상 위치에 나눠 실행하지만, 여기서는 하나의 프로그램을 통째로 메모리 상 균일한 위치에 올린다고 가정하고 진행한다. 1. 주소 바인딩이 실현되는 3가지 시점 Compile time binding Physical Address가 컴파일 시에 정해져서 Logical Address와 Physical Address와 같음 이 때, 컴파일러가 생성한 코드를 절대 코드(absolute code)라고 지칭 메모리가 많이 비어있을 때도 특정 위치부터 주소를 바인딩하기 때문에 비효율적 시작 위치 변경시 재컴파일해야 함 과거에 쓰이던 방식 Load time binding 프로그램이 실행되는 타이밍에 Loader가 Physical Address를 부여함 정해진 위치가 아닌 비어 있는 메모리 위치에 주소를 바인딩 이 때, 컴파일러가 생성한 코드는 재배치가능 코드(relocatable code)라고 지칭 Execution time binding (=Run time binding) Physical Address를 부여하는 타이밍과 방식은 Load time binding과 동일 프로그램 실행 중에도 프로세스의 메모리 상 위치가 바뀔 수 있다는 점이 특징 CPU가 주소를 참조할 때마다 binding을 점검 이를 위해서 하드웨어적인 지원이 필요 (ex. MMU) 주소 바인딩이 되더라도 Logical Address는 코드상에 남아 있으므로, CPU는 Physical Address가 아닌 이 Logical Address를 참조하고 요청해 연산을 수행한다. 2. MMU (Memory-Management Unit) Logical Address를 Physical Address로 mapping해 주는 Hardware device Execution time binding을 지원 2개의 register를 이용해 주소 변환 지원 (relocation register, limit register) Relocation register(=base register): 접근할 수 있는 물리적 메모리 주소의 최소값 Limit register: 논리적 주소의 범위 user program은 logical address만 다루며, 실제 physical address는 볼 수 없고 알 필요도 없음 MMU scheme 사용자 프로세스가 CPU에서 수행되며 생성해내는 모든 주소값에 대해 base register 값을 더한다. 아래에 예시를 살펴보자. 위 그림은 process p1이 실행되어 있는 상황에서 CPU가 p1의 한 instruction을 요청하는 과정을 담고 있다. 먼저 왼쪽 하단의 p1 그림은 p1의 논리적 주소를 보여준다. p1은 0~3000번지까지의 논리적 주소를 가진다. 이 때, limit register는 p1의 가장 끝 주소인 3000을 기억한다. 또한, 현재 CPU는 0~3000까지의 논리적 주소 중 346번지에 있는 instruction을 요청한 상황이다. 물리적 주소 입장에서 보면, p1은 실행될 때 14000~17000번지까지의 주소를 부여 받았다. 논리적 주소의 범위인 3000만큼을 물리적 주소도 동일하게 받았다. 이 때, relocation register는 p1의 물리적 주소 시작위치인 14000을 기억한다. 그렇다면 CPU가 요청한 instruction의 물리적 메모리 상 위치는 어떻게 될까? CPU가 요청한 논리적 주소 346번지 instruction은 relocation register에 저장된 물리적 위치 시작 주소 14000에 346을 그대로 더한 14346번지 물리적 주소에 존재한다. 즉, 논리적 주소는 상대적으로 표현한 것이기 때문에 실제 위치에서 상대적으로 계산하면 원하는 instruction의 물리적 주소를 알 수 있다. 한편, limit register는 어떤 프로그램이 악의적으로 프로세스의 메모리 범위를 벗어나는 주소를 요청하는 경우를 막기 위해 존재한다. 예를 들어, 위 그림에서 CPU가 요청한 논리적 주소가 4000이라고 하면 p1의 물리적 주소 범위인 14000~17000을 벗어나 18000의 주소를 요청한 것이기 때문에 limit register가 이를 막는다. MMU의 지원을 받아 주소 변환을 하는 과정을 일반화하면 위와 같이 도식화할 수 있다. CPU가 어떤 instruction의 logical address를 요청하면 그 주소가 limit register에 저장된 값을 넘지 않는지(논리 주소가 프로그램의 크기를 넘어가지 않는지) 확인한다. 만약에 값을 넘어가면, trap이 걸려 운영체제가 해당 프로그램의 CPU 제어권을 앗아가고 범위를 벗어난 악의적인 시도에 대해 프로그램을 종료시키는 등의 제제를 가한다. 값이 벗어나지 않는다면, 요청한 logical address 값에 relocation register에 저장된 값을 더해 physical address로 주소 변환을 하고, 해당 주소에 존재하는 내용을 CPU에게 전달한다. Dynamic Loading 프로세스 전체를 메모리에 미리 다 올리는 것이 아니라 해당 루틴이 불려질 때 메모리에 load하는 것을 말한다. 프로그램의 코드는 모든 코드가 항상 일정하게 쓰이는 것이 아니라 오류 처리 루틴같은 상대적으로 덜 쓰이는 부분이 존재한다. Dynamic Loading은 이렇게 가끔씩 사용되는 많은 양의 코드를 다루는 경우에서 메모리의 효율성을 크게 증대시킨다. 다만, 이 개념은 운영체제가 제공하는 라이브러리로 프로그래머가 직접 구현하는 것을 의미하며, 운영체제가 스스로 메모리에 올리고 쫒아내는 것을 관리하는 paging system과는 다른 개념임을 유의해야 한다. Overlays 메모리에 프로세스의 부분 중 실제 필요한 정보만을 올리는 것을 말한다. Dynamic Loading과 그 의미가 거의 동일하나 초창기 컴퓨터 시스템에서 사용되던 말이다. 작은 공간의 메모리에 큰 프로그램을 실행시키기 위해 프로그래머가 직접 수작업으로 프로그램을 분할해 메모리에 올리던 방법으로, 운영체제의 지원없이 구현했기 때문에 프로그래밍이 매우 복잡했다. Swapping Swapping 프로세스를 일시적으로 메모리에서 backing store로 쫒아내는 것을 의미한다. 메모리에서 쫒았다가 다시 올리는 작업이므로, 프로세스가 특정 위치에 반드시 복귀해야 하는 Compile time binding, Load time binding보다는 빈 메모리 영역 아무곳에나 프로세스를 올릴 수 있는 Execution time binding에서 더 적합하다. Swap time은 대부분 transfer time(swap되는 양에 비례하는 시간)에 해당한다. Backing store (=swap area) 하드 디스크의 일부분으로, 많은 사용자의 프로세스 이미지를 담을 만큼 충분히 빠르고 큰 저장 공간을 말한다. Swap in / Swap out 프로세스가 메모리에서 쫒겨나 backing store로 내려가는 것을 Swap out이라고 하고, backing store에서 다시 메모리로 올라가는 것을 Swap in이라고 한다. 일반적으로 중기 스케줄러가 메모리에 올라와 있는 프로세스들의 CPU priority를 고려하여 swap out시킬 프로세스를 선정한다. Dynamic Linking Linking을 실행 시간(execute time)까지 미루는 기법이다. 본래의 Linking(=Static Linking)은 실행 파일을 만들 때, 라이브러리 실행 코드가 실행 파일 코드에 포함되어 실행 파일의 크기가 커진다. 즉, 같은 라이브러리를 쓰는 프로세스라고 하더라도 각각의 프로세스 주소 공간에 라이브러리 코드가 매 번 들어 있는 실행파일이 생성된다. 반면에, Dynamic Linking은 만들어진 실행 파일 속에 라이브러리 루틴의 위치를 찾기 위한 포인터(stub라고 하는 작은 코드)만 넣어 두고 라이브러리 코드 전체는 포함시키지 않는다. 그리고 실행 파일에서 해당 라이브러리를 호출할 시, 포인터로 라이브러리 파일의 위치를 찾아 해당 라이브러리 코드를 메모리에 올리고 실행한다. 만일, 다른 프로세스가 라이브러리를 호출해 이미 메모리에 올라와 있는 경우, 실행만 한다. 본래의 Linking에 비해 메모리 공간을 덜 잡아먹고 실행 파일의 크기가 줄어든다는 점에서 효율적이다. Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-06-08

Fast API tutorial - Validation

각각의 Parameters는 인자로 받을 데이터에 대해 여러가지 조건을 걸어 validations(유효성 검사)를 수행할 수 있습니다. 만일 incorrect한 데이터가 감지될 경우 validation에 의해 error가 응답됩니다. Parameter의 종류를 선언하는 함수 앞에서 살펴봤듯이 parameter는 path parameter, query parameter, request body parameter 등 여러가지 형태의 종류가 존재합니다. 이외에도 cookie parameter, header parameter등 더 다양한 형태가 존재하는데, 이러한 parameter를 조금 더 명시적으로 선언할 수 있게 도와주는 함수가 각각 존재합니다. from typing import Optional from fastapi import FastAPI, Path, Query app = FastAPI() @app.get("/items/{item_id}") async def read_items(item_id: Path(...), q: Query(None): results = {"items": [{"item_id": "Foo"}, {"item_id": "Bar"}]} if q: results.update({"q": q}) return results 만일 parameter의 default 값으로 Path(...)를 설정해주면, 해당 parameter는 required한 path parameter가 됩니다. 혹은 Default 값으로 Query(None)를 사용한다면 해당 parameter는 not required한 query parameter가 됩니다. 이러한 함수들은 함수의 첫 번째 parameter로 default 값을 받습니다. Path([default 값]) Query([default 값]) etc… 이렇게 각각의 parameters는 자신의 이름을 딴 함수를 갖고 있습니다. fastapi에서 import해오는 Path, Query 등이 그 예입니다. 사실 각각의 함수들은 해당 이름의 클래스에서 인스턴스를 만들어 return하는 기능을 하므로, default parameter로 설정하는 것은 해당 이름의 객체가 됩니다. Parameter에 대한 validation은 이러한 함수들을 사용해 적용합니다. 이러한 클래스들이 비슷한 느낌을 띄는 이유가 있습니다. 해당 클래스들은 모두 Param 클래스의 subclass들입니다. 그래서 이들은 validation과 metadata의 추가를 모두 똑같은 방식으로 적용할 수 있습니다. Path(), Query(), Body() 함수로 required parameter 만들기 앞에서 Query 함수의 첫번째 parameter로 None을 사용해 optional parameter를 만들었는데, 만일 Query 함수를 사용해 required parameter를 만들고 싶다면 Query의 첫 번째 argument로 ... (Ellipsis)를 사용하면 됩니다. 이는 나중에 사용할 Path, Body 함수와 더불어 같은 맥락의 함수들에 똑같이 적용됩니다. Query(…) Path(…) Body(…) etc… String Validations Additional Information Fast API는 type hinting과 default parameter를 통해 이에 대한 추가 정보를 인식하고 활용합니다. from typing import Optional from fastapi import FastAPI app = FastAPI() @app.get("/items/") async def read_items(q: Optional[str] = None): results = {"items": [{"item_id": "Foo"}, {"item_id": "Bar"}]} if q: results.update({"q": q}) return results 위 코드는 async def read_items(q: Optional[str] = None): 부분에 query parameter q에 대한 타입을 명시했습니다. q는 str타입이 단서가 되어 query parameter로 인식됩니다. 또한, = None을 통해 not required한 optional parameter로 인지됩니다. Additional validation Parameter에 인자로 받을 데이터에 대한 validation을 걸어줄 수 있습니다. 일례로, query parameter q에 대해 인자로 들어올 str 데이터의 최대 길이가 50이 넘지 않게끔 검사를 수행하는 validation을 만들겠습니다. from typing import Optional from fastapi import FastAPI, Query app = FastAPI() @app.get("/items/") async def read_items(q: Optional[str] = Query(None, max_length=50)): results = {"items": [{"item_id": "Foo"}, {"item_id": "Bar"}]} if q: results.update({"q": q}) return results 우선 fastapi에서 Query 함수를 import합니다. from fastapi import FastAPI, Query 그리고 Query 함수를 다음과 같은 형태로 default parameter 자리에 사용합니다. Query([default 값], [조건식]) q: Optional[str] = Query(None, max_length=50)는 default 값으로 None을 유지한 상태에서 q의 최대 길이를 50으로 지정합니다. 그리고 실제로 전달된 데이터의 길이가 50을 넘어가면, error를 응답합니다. 또한, Query 함수는 다음과 같이 parameter를 더 추가해 여러 개의 validation을 지정할 수 있으며, 정규표현식을 validation으로 지정할 수도 있습니다. Query(None, min_length=3, max_length=50) Query(None, min_length=3, max_length=50, regex="^fixedquery$") 이러한 validation 정보들은 Interactive Documentation에도 업데이트됩니다. Parameter에 Multiple values 받기 from typing import List, Optional from fastapi import FastAPI, Query app = FastAPI() @app.get("/items/") async def read_items(q: Optional[List[str]] = Query(None)): query_items = {"q": q} return query_items Parameter를 특정 parameter를 만드는 함수를 사용해 선언한다면, multiple values를 받는 parameter로 만들 수 있습니다. 만일 query parameter를 Query 함수를 사용해 만든다면, multiple values를 받는 query parameter를 만드는 식입니다. 이 경우 query parameter는 반드시 Query 함수와 함께 정의되어야 하는데, 그렇지 않으면 Fast API가 해당 parameter를 request body로 간주할 수 있기 때문입니다. (Singular type이 아닌 type으로 parameter를 선언할 때 나타나는 현상입니다!) q: Optional[List[str]] = Query(None) 위와 같이 List 타입으로 q를 선언하면, http://localhost:8000/items/?q=foo&q=bar 요청과 같이 URL에 여러 개의 query 값이 전달되어도 리스트로 한 번에 받아 처리할 수 있습니다. Fast API는 자동으로 multiple query를 인식해 리스트에 담아줍니다. 위 URL 요청에 대한 response은 다음과 같습니다. { "q": [ "foo", "bar" ] } 만일 리스트로 받을 내부 요소들의 타입까지 체크하고 싶진 않다면, 다음과 같이 list로만 타입을 선언하면 됩니다. q: list = Query([]) Parameter에 metadata 넣기 Parameter의 종류를 선언하는 함수에 인자를 설정해주면, 함수를 적용한 parameter에 metadata를 추가할 수 있습니다. 예를 들어, Query 함수의 parameter를 사용하면 다음과 같이 query parameter에 또 다른 metadata들을 추가할 수 있습니다. async def read_items( q: Optional[str] = Query( None, title="Query string", description="Query string for the items to search in the database that have a good match", min_length=3, ) ): 여기선 title과 description parameter를 추가했는데, 이렇게 추가된 query parameter 정보들은 Interactive Document에도 반영됩니다. Parameter에 Alias 설정하기 REST하게 URL을 만들고 싶다면, _보다 -를 사용하는 것이 좋습니다. 언더스코어 _는 밑줄이 그어지면 가독성이 떨어지기 때문입니다. 그러나 parameter 이름을 item-query처럼 사용하는 것은 Python 문법에 어긋납니다. 따라서, 이러한 경우에는 parameter에 alias를 item-query로 설정해줍니다. 아래는 query parameter의 예입니다. q: Optional[str] = Query(None, alias="item-query") Parameter Deprecating하기 Deprecated는 특정 기능이 아직까지 사용되고는 있지만, 중요도가 떨어져 조만간 사라지게 될 상태를 말합니다. 만일 특정 parameter를 언젠가 제거할 계획이지만 이를 계속 사용하는 클라이언트 개발자들을 위해 한 동안 남겨두려는 상황이라면, 해당 parameter를 deprecating하여 Interactive API Documentation에 해당 parameter가 deprecated 상태임을 명확히 알려줄 수 있습니다. (Documentation은 클라이언트 개발자들과의 소통 창구 역할을 합니다!) 예를 들어, 다음과 같이 Query 함수의 parameter로 deprecated=True를 설정해줍니다. q: Optional[str] = Query(None, deprecated=True) Deprecated 상태에서는 parameter의 이용이 여전히 가능하지만, Interactive Documentation에는 해당 parameter의 deprecated 상태가 명확히 반영됩니다. Numeric Validations 앞에선 String과 관련된 validation을 많이 살펴봤지만, Numeric 형태의 데이터를 다룰 때도 물론 validation을 수행하거나 metadata를 추가해줄 수 있습니다. 이 경우는 Numeric value를 자주 사용하는 path parameter를 주로 사용해서 살펴보겠습니다. Path 함수는 다음과 같이 import해 사용합니다. from fastapi import Path Path Parameter에 metadata 넣기 from typing import Optional from fastapi import FastAPI, Path, Query app = FastAPI() @app.get("/items/{item_id}") async def read_items( item_id: int = Path(..., title="The ID of the item to get"), q: Optional[str] = Query(None, alias="item-query"), ): results = {"item_id": item_id} if q: results.update({"q": q}) return results Path 함수에 metadata를 넣을 때도, Query와 똑같은 방식으로 사용합니다. item_id path parameter에 title 정보를 넣고 싶다면 다음과 같이 Path 함수에 parameter로 삽입하여 적용합니다. item_id: int = Path(..., title="The ID of the item to get") 이 때, path parameter는 path의 일부분이기 때문에, 인자가 반드시 존재해야 하는 parameter입니다. 따라서, 첫 번째 파라미터로 ...을 사용해 Fast API에게 required parameter임을 알려줍니다. 사실 ...이외의 None이나 다른 default 값을 사용하더라도 문제 없이 실행되지만 큰 의미는 없으며, 해당 path parameter는 여전히 required parameter로 기능합니다. Number validations Parameter에 대하여 몇몇 숫자에 대한 validation을 추가할 수 있습니다. from fastapi import FastAPI, Path app = FastAPI() @app.get("/items/{item_id}") async def read_items( *, item_id: int = Path(..., title="The ID of the item to get", gt=0, le=1000), q: str, ): results = {"item_id": item_id} if q: results.update({"q": q}) return results 위 코드의 Path 함수에 들어간 gt, le 같은 validation parameter들의 의미는 다음과 같습니다. gt: greater than ge: greater than or equal lt: less than le: less than or equal Reference Fast API 공식 문서 튜토리얼

Python-Ecosystem · 2021-06-06

Fast API tutorial - Params

Fast API 튜토리얼 - Parameters of Path, Query, Request body Path Parameters Path Parameters의 정의와 형태 Path parameter는 path 내에 들어있는 variable의 value를 전달받은 parameter를 말합니다. @app.get("/items/{item_id}") def read_item(item_id): return {"item_id": item_id} 위의 코드에서, item_id는 path parameter에 해당합니다. HTTP 요청이 들어오면 해당 URL에서 {item_id}에 해당하는 value를 획득하고, 이 value는 read_item함수의 item_id에 인자로 전달됩니다. 위의 코드를 main.py에 추가해 저장한 후, http://127.0.0.1:8000/items/foo에 들어가면 response로 {"item_id":"foo"}이 확인됩니다. Data conversion and validation @app.get("/items/{item_id}") def read_item(item_id: int): return {"item_id": item_id} 또한, path operation function에서 인자로 사용한 path parameter에 타입 힌트를 줄 수 있습니다. (다른 parameter도 마찬가지로 적용됩니다.) 그리고 이렇게 자료형을 annotate한 parameter는 들어온 인자 값을 annotated된 자료형대로 형 변환해서 parameter에 담습니다. 만일 http://127.0.0.1:8000/items/3으로 요청이 들어온 경우, 원래는 path parameter를 str 타입으로 받아 item_id 값이 ‘3’이 되지만 위 코드에서는 타입 힌트를 보고 int로 형 변환된 3이 담깁니다. 즉, Fast API는 타입 힌트를 통해 자동으로 parsing을 통한 data conversion을 제공합니다. 만일 path parameter에 annotated된 타입과 다른 타입의 값이 요청된다면, 해당 HTTP 요청은 에러를 일으킵니다. 이는 Fast API가 데이터 유효성 검사까지 수행함을 보여줍니다. 실제로 http://127.0.0.1:8000/items/foo에 들어가면 응답에 오류가 발생합니다. Annotated된 int 타입으로 형 변환이 이뤄질 수 없는 foo가 값으로 들어왔기 때문입니다. http://127.0.0.1:8000/items/4.2의 경우도 마찬가지입니다. 타입 힌트로 annotated된 변수는 Interactive API documentation에도 적용됩니다. http://127.0.0.1:8000/docs에 들어가면 path parameter item_id가 integer로 선언되어 있음을 확인할 수 있습니다. Fast API에서 이러한 data conversion 및 validation이 가능한 이유는 내부적으로 Pydantic 라이브러리의 도움 덕분입니다. Pydantic이란? 파이썬 타입 힌트를 사용해 데이터 유효성 검사를 해주는 라이브러리입니다. 만일 어노테이션된 타입과 다른 데이터를 만나면 에러를 띄웁니다. Fast API에서는 Pydantic을 활용하여 간편하게 데이터 유효성 검사를 수행합니다. Path Operation 정의 순서의 중요성 어떤 path operation들은 정의하는 순서에 따라 예상치 못한 처리를 일으킬 수 있습니다. 예를 들어, 고정된 path를 가진 path operation과 path parameter를 가진 path operation이 모두 정의된 경우를 살펴봅시다. from fastapi import FastAPI app = FastAPI() @app.get("/users/me") async def read_user_me(): return {"user_id": "the current user"} @app.get("/users/{user_id}") async def read_user(user_id: str): return {"user_id": user_id} /users/me 코드는 /users/{user_id}보다 앞에 쓰여져야 합니다. 만일 순서가 바뀌면, Fast API는 me를 user_id의 value로 오해하여 본래 의도와 다르게 read_user 함수를 호출할 것입니다. Path Parameter의 값으로 Path를 받는 경우 때로는 path parameter의 값으로 home/dogs/wealsh와 같은 path가 올 수 있습니다. 만일 path operation의 path가 기존처럼 /files/{file_path}이라면, file_path는 /files/home/dogs/wealsh 요청이 들어왔을 때 이를 온전히 인식하지 못하고 {"detail":"Not Found"}를 응답합니다. 하지만, Starlette에서 제공하는 Path convertor를 사용하면 path parameter의 인자가 path 형태로 들어와도 이를 온전히 인식하게 됩니다. Fast API는 Starlette을 기반으로 만들어졌기 때문에, 특별한 import 없이 다음과 같이 써주면 path convertor가 동작합니다. /files/{file_path:path} 이를 활용하면 다음과 같이 path operation에 http://127.0.0.1:8000/files/home/dogs/wealsh 형태로 요청을 보내도 온전히 동작합니다. from fastapi import FastAPI app = FastAPI() @app.get("/files/{file_path:path}") async def read_file(file_path: str): return {"file_path": file_path} 위의 요청의 경우 files/home/dogs/wealsh 값이 file_path에 담겨 응답됩니다. 만일 /files/home/dogs/wealsh 형태로 앞에 /를 추가하여 file_path에 담고 싶다면 http://127.0.0.1:8000/files//home/dogs/wealsh 형태로 요청을 보내면 됩니다. Query Parameters Query Parameters의 정의와 형태 Path operation function에 path parameter가 아닌 다른 parameter를 선언했다면, 해당 parameter들은 자동으로 query parameter로 인식됩니다. Query parameter는 request로 들어오는 query의 값이 담기는 parameter입니다. Query는 URL의 ?뒤에 오는 key-value pair를 의미하며 각각의 query는 &로 구분됩니다. 다음은 request에 담긴 query의 예시입니다. http://127.0.0.1:8000/items/?skip=0&limit=10 또한, 다음과 같은 path operation은 이러한 request에 대해 query parameter를 받습니다. from fastapi import FastAPI app = FastAPI() fake_items_db = [{"item_name": "Foo"}, {"item_name": "Bar"}, {"item_name": "Baz"}] @app.get("/items/") async def read_item(skip: int = 0, limit: int = 10): return fake_items_db[skip : skip + limit] 이 경우, query parameter는 skip과 limit이고 각각 0과 10을 인자로 받습니다. 원래대로라면 URL로부터 들어온 str타입의 ‘0’과 ‘10’으로 값을 받았겠지만, skip과 limit의 타입을 int로 선언했기 때문에 형 변환하여 값을 받습니다. 즉, query parameter에도 path parameter에서 적용되던 다음과 같은 프로세스들이 그대로 적용됩니다. Editor Support (Auto completion, Error check, etc…) Data conversion Data validation Automatic Documentation Default value & Optional Parameters from fastapi import FastAPI app = FastAPI() fake_items_db = [{"item_name": "Foo"}, {"item_name": "Bar"}, {"item_name": "Baz"}] @app.get("/items/") async def read_item(skip: int = 0, limit: int = 10): return fake_items_db[skip : skip + limit] Query parameter는 default parameter를 설정할 수 있습니다. 이 경우 skip과 limit의 default 값은 각각 0과 10입니다. from typing import Optional from fastapi import FastAPI app = FastAPI() @app.get("/items/{item_id}") async def read_item(item_id: str, q: Optional[str] = None): if q: return {"item_id": item_id, "q": q} return {"item_id": item_id} 또한, query parameter에는 typing 모듈을 활용해서 Optional 타입을 선언할 수 있습니다. q: Optional[str] = None은 query parameter q가 str 타입의 value를 인자로 받거나 혹은 인자가 없을 때는 None을 default value로 가진다는 의미입니다. 즉, Fast API는 q를 required하지 않은 parameter로 인식합니다. 이 때, Fast API는 = None부분을 인식해 query parameter q의 required 여부를 구분합니다. 또한, : Optional[str] 부분에서 Fast API는 str 부분만 인식해 data conversion 및 data validation에 사용합니다. 그리고 나머지 Optional 부분은 Fast API가 아닌 Editor의 Auto completion과 Error check를 support하기 위해 사용됩니다. Required parameter란? Parameter가 Required하다는 것은 특정 parameter가 필수적으로 인자를 받아야만 함을 말합니다. 보통 특정 parameter에 default값을 설정해두면 not required, default 값을 설정하지 않으면 required 상태로 인식됩니다. 만일 not required한 parameter를 굳이 특정 값이 있지 않아도 되는 Optional parameter로 만들고 싶다면, default 값으로 None을 설정하면 됩니다. Request Body Request Body의 정의와 형태 Request body는 클라이언트에서 API로 보내는 data를 의미합니다. 반면에, API가 클라이언트에게 보내는 data는 response body라고 합니다. Response body는 API가 항상 보내야 하는 반면, request body는 클라이언트가 필수적으로 보낼 필요는 없습니다. from typing import Optional from fastapi import FastAPI from pydantic import BaseModel class Item(BaseModel): name: str description: Optional[str] = None price: float tax: Optional[float] = None app = FastAPI() @app.post("/items/") async def create_item(item: Item): return item Request body는 Pydantic model을 통해 선언합니다. pydantic 라이브러리에서 BaseModel을 import하고, BaseModel을 상속하는 클래스를 생성해 Pydantic 모델을 만듭니다. Model의 attribute들은 query parameter와 같은 방식으로 required 여부를 정할 수 있습니다. 위 경우, name, price는 required한 attribute이고 description, tax는 not required하면서 optional한 attribute입니다. 따라서, 위 모델은 다음과 같은 JSON 객체(혹은 Python dict 객체)를 선언한 것과 같습니다. { "name": "Foo", "description": "An optional description", "price": 45.2, "tax": 3.5 } description과 tax는 optional하기 때문에 다음과 같은 JSON 객체도 request body로 유효하게 전달 받을 수 있습니다. { "name": "Foo", "description": "An optional description", "price": 45.2, "tax": 3.5 } 그리고 path operation fucntion의 parameter에 원하는 pydantic model을 타입 선언 해주면, 해당 파라미터는 request body를 전달받는 parameter로 인식됩니다. 위 코드에서는 async def create_item(item: Item):에서 Item pydantic model을 타입으로 선언해 item을 request body parameter로 만들었습니다. 이렇게 선언된 request body parameter는 다음과 같은 특징을 가집니다. Request body로 들어온 data를 JSON 형식으로 읽어들입니다. 필요할 경우 들어온 data를 선언된 타입에 일치하도록 data conversion합니다. 선언된 타입으로 Data validation을 수행합니다. (Incorrect data에는 error를 띄웁니다!) Editor support를 지원합니다. 해당 model에 대한 JSON schema를 생성해, Automatic Documentation에 적용합니다. Request Body로 전달받은 Model 사용법 from typing import Optional from fastapi import FastAPI from pydantic import BaseModel class Item(BaseModel): name: str description: Optional[str] = None price: float tax: Optional[float] = None app = FastAPI() @app.post("/items/") async def create_item(item: Item): item_dict = item.dict() if item.tax: price_with_tax = item.price + item.tax item_dict.update({"price_with_tax": price_with_tax}) return item_dict Request body를 전달받은 item은 클래스의 attribute를 사용하는 것과 똑같은 방식으로 자유롭게 사용할 수 있습니다. 예를 들어, item.tax처럼 tax 속성에 접근해 value를 사용할 수 있습니다. 또한, pydantic model의 .dict() 메서드를 사용해 item.dict()로 해당 model의 데이터를 python dict 형태로 사용할 수도 있습니다. 위 코드는 tax 속성에 인자가 들어왔다면, price_with_tax = item.price + item.tax로 새로운 value를 만들고 item에서 추출한 item_dict에 item_dict.update({"price_with_tax": price_with_tax})로 새로운 key-value를 추가하여 item_dict를 return합니다. Path + Query + Request Body Parameters Path, query, request body parameter는 모두 동시에 사용할 수 있습니다. Fast API는 각각의 parameters를 자동으로 구분해냅니다 from typing import Optional from fastapi import FastAPI from pydantic import BaseModel class Item(BaseModel): name: str description: Optional[str] = None price: float tax: Optional[float] = None app = FastAPI() @app.put("/items/{item_id}") async def create_item(item_id: int, item: Item, q: Optional[str] = None): result = {"item_id": item_id, **item.dict()} if q: result.update({"q": q}) return result 위 경우 item_id는 path parameter, item은 request body parameter, q는 query parameter로 자동 인식됩니다. 기본적으로 parameter 자동 인식은 다음과 같은 기준으로 진행됩니다. Path 안에도 선언되어 있는 parameter는 path parameter로 인식합니다. (혹은 Path(...)가 선언되어 있는 parameter) int, float, str, bool 등의 singular type으로 선언된 parameter는 query parameter로 인식합니다. (혹은 Query(...)가 선언되어 있는 parameter) Pydantic model로 type이 선언된 parameter는 request body parameter로 인식합니다. (혹은 Body(...)가 선언되어 있는 parameter) Path, Query, Request body Parameters의 순서 문제 Query parameter를 default 값이 없는 required parameter로 만들고, path parameter는 default 값으로 Path 인스턴스를 넣어 not required한 parameter로 만드는 다음과 같은 상황을 가정해보겠습니다. async def read_items( item_id: int = Path(..., title="The ID of the item to get"), q: str ): 이 때, Python 문법으로 인해 default 값이 있는 parameter는 default 값이 없는 parameter의 앞에 위치하지 못합니다. 따라서, 위 코드는 오류를 일으킵니다. 하지만, 다음과 같이 순서를 정리하면 오류를 피할 수 있습니다. async def read_items( q: str, item_id: int = Path(..., title="The ID of the item to get") ): Fast API는 parameter의 이름, 타입, default parameter 등의 단서를 통해 parameter의 종류를 인식하므로, 순서에 대한 문제는 Python 문법에서만 고려하면 됩니다. 만일 다음과 같은 약간의 트릭을 사용한다면, default 값 여부에 상관 없이 자유로운 parameter 배열이 가능합니다. async def read_items( *, item_id: int = Path(..., title="The ID of the item to get"), q: str ): *를 함수의 첫 번째 parameter로 사용하면 위와 같이 default 값이 없는 parameter가 뒷 순서로 와도 상관 없습니다. *는 Python 함수의 special parameter 중 하나로, * 뒤에 위치한 parameter들은 모두 키워드 인자만 받도록 강제합니다. Special parameter에 대해 더 자세히 알고 싶다면, Python 공식 튜토리얼 문서의 Special parameters 부분을 읽어 보시길 바랍니다. Reference Fast API 공식 문서 튜토리얼

Python-Ecosystem · 2021-06-04

7. Deadlock

Computer Science · 2021-06-03

비동기 프로그래밍을 돕는 asyncio 라이브러리

Python-Ecosystem · 2021-05-28

6-2. Process Synchronization 문제

Computer Science · 2021-05-27

6-1. Process Synchronization 문제

Computer Science · 2021-05-27

5-2. CPU 스케줄링

Multi-level queue 우선도가 다른 ready queue Ready queue를 foreground(interactive)와 background(batch - no human interaction)으로 분리한다. 그리고 foreground에는 RR, background에는 FCFS 등으로 각 큐에 독립적인 스케줄링 알고리즘을 설계한다. 또한 어떤 큐에게 CPU를 줄 지 (그 이후에는 큐에 있는 어떤 프로세스에게 CPU를 줄 지)결정하는 작업이 필요한데, 이를 큐에 대한 스케줄링으로 해결한다. Fixed priority scheduling은 우선도를 최우선으로 하여 우선도가 높은 foreground에게 먼저 scheduling하고 그 다음 background에게 주는 방식이다. 이 방식에서는 starvation이 단점이 될 수 있다. 이에 대한 대안으로 Time Slice가 있는데, 이 스케줄링은 각 큐에 CPU time을 적절한 비율로 할당한다. (ex. foreground에 80% background에 20% CPU time 분배) Multi-level feedback queue 우선도가 높은 queue여도 상황에 따라 낮은 우선도 queue가 높은 우선도 queue보다 우선될 수 있다. Multi-level queue의 고정된 우선도라는 단점을 극복하기 위한 대안이다. 예를 들어, 들어오는 프로세스를 우선도가 가장 높은 queue에 줄 세우고 RR 방식을 사용하되, 우선도가 낮은 queue일수록 time quantum을 길게 준다. 그래서 time quantum 내에 프로세스가 완료되면 큐에서 내보내고, 완료되지 않았으면 다음으로 우선도가 높은 큐에 해당 프로세스를 줄 세운다. 이렇게 하면 CPU burst가 짧은 프로세스에 우선 순위를 더 많이 주고, CPU burst가 긴 프로세스의 우선도는 더 낮출 수 있다. 특수한 상황에서의 CPU Scheduling 1. Multiple-Processor Scheduling (간략히 다룸) Homogeneous Processor라면 Queue에 한 줄로 세워서 각 프로세서가 알아서 꺼내가게 할 수 있는가하면 어떤 프로세스는 특정 프로세서에서만 수행되어야 하는 경우가 존재하므로 이를 고려해야 한다. Load sharing 일부 프로세서에 job이 몰리지 않게 하는 적절한 메커니즘이 필요하다. 모든 CPU가 공동 큐를 사용하는 방법 혹은 각각의 CPU마다 별개의 큐를 사용하는 방법이 있다. Symmetric Multiprocessing (SMP) 각 프로세스가 각자 알아서 스케줄링을 결정한다. Asymmetric Multiprocessing 하나의 프로세서가 시스템 데이터의 접근과 공유를 책임지고 나머지 프로세서는 그것에 따른다. 2. Real-Time Scheduling Time sharing과 달리 미리 스케줄링을 계획하고 데드라인이 보장되도록하는 방식 Hard real-time systems 정해진 시간안에 반드시 끝내도록 스케줄링하는 것 Soft real-time computing (많이 쓰임) 영화 스트리밍과 같이 time sharing 시스템에서 다른 일반적인 프로세스들과 섞여서 실행되지만, 일반 프로세스에 비해 높은 priority를 갖게해 데드라인을 지키도록 지향하는 스케줄링. (조금은 데드라인을 어기는 것이 허용됨) 3. Thread Scheduling Local Scheduling User level thread의 경우 운영체제가 thread의 존재를 모르기 때문에, 사용자 수준의 thread library에 의해 어떤 thread를 스케줄할지 결정한다. (운영체제는 CPU를 프로세스에게 전달만 하고 어떤 스레드에 CPU를 줄지는 해당 프로세스 내부에서 결정한다.) Global Scheduling Kernel level thread의 경우 운영체제가 thread의 존재를 알고 있기 때문에, 일반적인 프로세스와 마찬가지로 커널의 단기 스케줄러가 어떤 thread를 스케줄할지 결정한다. Algorithm Evaluation 1. Queueing models (Server를 CPU로 보자.) 확률분포로 주어지는 arrival rate와 service rate 등을 통해 각종 performance index 값을 계산한다. (이론적 측면에서 많이 사용하는 방법) 2. Implementation (구현) & Mesurement (성능 측정) 실제 시스템에 알고리즘을 구현하여 실제 작업에 대해서 성능을 측정 및 비교한다. ex) 리눅스 커널에 나의 CPU 스케줄링 알고리즘을 구현해보고, 실제 프로그램을 돌려서 원래의 리눅스 환경과 나의 알고리즘이 적용되어 있는 리눅스 커널의 성능을 비교해본다.) 3. Simulation (모의 실험) 알고리즘을 모의 프로그램으로 작성 후 trace(실제 프로그램으로부터 추출한 input data)를 입력으로 하여 결과를 비교한다. Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-05-26

5-1. CPU 스케줄링

CPU Burst & I/O Burst 어떤 프로그램이 실행된다는 것은 CPU Burst와 I/O Burst가 번갈아 가며 일어나는 것을 의미한다. 프로그램의 종류에 따라 두 Burst의 빈번함이 다를 수 있는데, ① 사용자 관여가 많은 (키보드 입력, 모니터 출력 등이 잦은) 프로그램(interactive job)은 CPU Burst 시간이 짧아지면서 두 Burst가 번갈아 빈번히 나타나고, ② 과학 계산용 프로그램 같은 연산 시간이 긴 프로그램은 CPU Burst 시간이 길어지면서 I/O 비중이 크게 줄어든다. 위 그래프는 CPU Burst 시간과 그 빈도에 따라 프로그램들을 분류한 것인데, CPU Burst 시간이 짧을수록 프로그램의 CPU Burst 빈도가 잦음을 알 수 있다. 이 같이 CPU를 잡고 계산하는 것보다 I/O에 더 많은 시간을 사용하는 프로그램들을 I/O bound job이라고 하며, 반대로 계산 위주로 구성된 프로세스는 CPU bound job이라고 부른다. 여러 종류의 job(=process)이 섞여 있기 때문에, 그들을 적절한 CPU Scheduling이 필요하다. → CPU bound job이 CPU를 너무 오래 사용하면 효율성이 떨어지므로, I/O bound job(=Interactive한 job)에게 우선적으로 CPU를 주도록 지향하는 것이 CPU Scheduling의 주요한 목표이다. CPU Scheduler & Dispatcher 1. CPU Scheduler 운영체제의 여러 코드 중 CPU schedule 기능을 담당하는 코드를 지칭하는 용어다. Ready 상태의 프로세스 중 어떤 프로세스에게 CPU를 줄 지 결정한다. 2. Dispatcher 역시 운영체제의 여러 코드 중 특정 코드를 지칭하는 용어다. CPU 제어권을 CPU scheduler에 의해 선택된 프로세스에게 넘긴다. 이 과정을 문맥 교환(Context Switch)이라고 한다. CPU Scheduling이 필요한 경우 1, 4의 스케줄링은 nonpreemptive(=자진 반납, 비선점형), 나머지 모든 스케줄링은 preemptive(=강제로 뺏음, 선점형, 대부분의 현대적인 CPU 스케줄링에서 사용) 3의 경우 일반적으로 원래 CPU를 점유하던 프로세스에게 timer가 끝날 때까지 CPU를 다시 쓰게 하지만, 만약 우선순위가 가장 높은 프로세스의 I/O가 완료된 것이었다면 해당 프로세스에게 CPU를 바로 넘기게 된다. Scheduling Criteria (CPU 스케줄링 성능 척도) 1. 시스템 입장에서의 성능 척도 : CPU 하나로 최대한 일을 많이 시키자! CPU utilization (이용률) : 전체 시간 중 CPU가 놀지 않고 일한 시간의 비율 Throughput (처리량) : 주어진 시간 동안 완료한 작업(process)의 수 2. 프로그램 입장에서의 성능 척도 : 내가 CPU를 빨리 얻어서 내가 빨리 끝나는 게 중요! Turnaround Time (소요시간, 반환시간) : CPU를 사용하기 위한 대기시간을 포함해 CPU를 사용완료하고 빠져나갈 때까지 걸린 총 시간 (다른 프로세스와 번갈아 CPU를 사용하게 되어도 그 모든 시간을 합하여 계산한다.) 프로세스가 CPU를 쓰러 대기열에 들어와서 CPU를 사용하고 I/O하러 나갈 때까지의 시간 ex) 중국집 손님이 코스요리를 시켰을 때, 중국집에 들어와서 요리를 기다리고 먹고를 반복하다가 다 먹고 나갈 때까지의 모든 시간 Waiting Time (대기시간) : Ready queue에서 대기하며 걸린 순수한 시간 CPU Burst와 I/O Burst가 번갈아 반복된다면, 그동안 생긴 여러 번의 대기 시간을 모두 합하여 계산하는 것이 아래의 Response Time과의 차이점이다. ex) 손님이 코스요리 음식을 기다린 모든 시간 Response Time (응답시간) : Ready queue에 들어와서 처음 CPU를 얻기까지 걸린 시간 (∝ time sharing) ex) 첫 번째 음식이 나올 때까지 기다린 시간 CPU Scheduling Algorithm 1. FCFS (First-Come First-Served) - nonpreemptive (비선점형) 먼저 들어온 프로세스를 먼저 처리한다. 먼저 들어온 프로세스가 CPU bound job일 경우 처리 시간이 길어지므로, 효율적인 스케줄링은 아니다. ex 1) 0초 대에서 프로세스들이 간발의 차이로 P1, P2, P3 순으로 들어왔을 때 ex 2) 0초 대에서 프로세스들이 간발의 차이로 P2, P3, P1 순으로 들어왔을 때 FCFS는 ex 1과 ex 2의 waiting time 같이 들어온 작업의 순서에 따라 결과 차이가 크게 나타나는 비효율성이 있다. 이처럼 작업 시간이 긴 프로세스에 의해 작업 시간이 짧은 프로세스들이 실행되지 못하는 상황을 Convoy effect(호위 효과)라고 한다. 2. SJF (Shortest-Job-First) CPU Burst가 짧은 프로세스에게 CPU 제어권을 제일 먼저 스케줄한다. 이 때, 각 프로세스의 다음 번 CPU Burst time을 고려하여 스케줄링에 활용한다. Nonpreemptive SJF 일단 CPU를 잡으면 해당 프로세스의 CPU Burst가 완료될 때까지 CPU를 선점(preemption)당하지 않는다. → 프로세스가 CPU를 다 사용하고 나가는 시점에 CPU 스케줄링을 결정 ex) Preemptive SJF (SRTF = Shortest-Remaining-Time-First) 현재 수행 중인 프로세스의 남은 burst time보다 더 짧은 CPU burst time을 가지는 새로운 프로세스가 도착하면 CPU를 빼앗는다. 주어진 프로세스들에 대하여 minimum average waiting time을 보장한다. (어떤 알고리즘도 이 waiting time 보다 빠를 수 없다.) → 새로운 프로세스가 들어올 때와 프로세스가 빠져 나갈 때, 두 가지 시점에서 CPU 스케줄링이 이뤄진다. ex) SJF의 문제점 Starvation (기아 현상) : 우선도가 낮은 프로세스(=CPU burst time이 긴 프로세스)는 영원히 실행되지 못할 수 있다. CPU burst time의 추정 : CPU burst time은 추정만 가능하기에 실제 정확한 시간을 알고 SJF를 수행하기는 어렵다. CPU burst time 추정은 과거의 CPU 사용 흔적을 바탕으로 exponetial averaging 기법을 사용해 이뤄진다. 이 기법은 과거의 흔적일수록 덜 반영하고 최근 흔적일수록 많이 반영하는 흐름을 가진다. 3. Priority Scheduling 높은 우선 순위를 가지는 프로세스에게 CPU를 할당한다. 작은 정수가 high priority를 나타낸다. (SJF도 일종의 Priority Scheduling → priority = predicted next CPU burst time) Nonpreemptive : CPU를 선점한 프로세스에게서 CPU를 빼앗지 않는다. Preemptive : 우선도에 따라 CPU를 빼앗긴다. (SJF 설명과 유사) Problem : Starvation (기아 현상)!!! → Solution) Aging : 시간이 지남에 따라 우선도가 낮은 프로세스의 우선도를 높인다. 4. Round Robin (RR) - Preemptive (선점형), 현대적 CPU Scheduling 각 프로세스는 동일한 크기의 할당 시간(time quantum)을 가지며 이 할당 시간이 지나면 CPU를 선점당하고 ready queue의 제일 뒤로 가서 다시 줄을 선다. n개의 프로세스가 ready queue에 있고 할당 시간이 q time unit인 경우 각 프로세스는 최대 q time unit 단위로 CPU 시간의 1/n을 얻는다. (어떤 프로세스도 (n-1)q time unit 이상 기다리지 않는다.) RR의 특징 Response Time 빨라지는 장점 Waiting Time은 CPU burst time이 긴 프로세스일수록 길고 반대의 경우 짧음 Performance q large → FCFS q small → context switch 오버헤드가 커진다. ex) Time quantum이 20일 때 → 일반적으로 SJF보다 average turnaround time이나 waiting time은 길어질 수 있지만 response time은 더 짧다. 또한, CPU 실행 시간이 동일한 프로세스들일 경우 RR이 비효율적일 수 있지만, 일반적으로는 CPU 실행 시간이 다르기 때문에 대부분에서 효율적이다. Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-05-26

4-2. 프로세스 관리

프로세스의 생성, 실행 및 종료에 관한 시스템 콜 프로세스 관리 시스템 콜 정리 1. fork() 시스템콜 위 그림의 두 코드는 부모 프로세스(좌), 자녀 프로세스(우)이다. 처음 부모 프로세스가 코드를 수행하다가 fork 시스템 콜을 만나면, 부모 프로세스를 똑같이 복사해 자녀 프로세스를 만들고 이후 명령을 계속 실행한다. 자녀 프로세스는 부모 프로세스의 Program Counter를 그대로 복제했기 때문에, 부모 프로세스와 마찬가지로 fork의 바로 밑 코드부터 실행한다. 또한, 부모 프로세스는 fork의 return 값으로 양수, 자녀 프로세스는 0을 pid에 취해 서로를 구분한다. 2. exec() 시스템콜 fork로 복사한 프로세스를 다른 프로그램으로 다시 덮어쓰기 위해 exec 시스템콜을 사용한다. 위와 같은 경우는 execlp 함수를 만나면, exec 시스템 콜이 발생해 복사한 자녀 프로세스에 새로 date 파일을 덮어써 실행하게 된다. 따라서, date가 실행되면 위 그림에 보이는 원래의 자녀 프로세스의 코드로는 다시 돌아갈 수 없다. 3. wait() 시스템콜 부모 프로세스가 wait 시스템 콜을 걸면, 부모 프로세스는 자식 프로세스가 종료될 때까지 blocked 상태가 된다. 자식 프로세스가 종료되면 부모 프로세스는 위 그림 처럼 wait 뒤에 있는 S2 코드를 계속 실행한다. (자식이 종료될 때까지 부모가 기다리는 모델에 해당) ex) 쉘 프롬프트의 커서가 깜빡이는 상태에서 프로그램을 실행 시 자식 프로세스 형태로 실행되고, 쉘 프롬프트 프로그램은 부모 프로세스로서 자식 프로세스가 종료될 때까지 기다렸다가(blocked 상태) 다시 실행된다. 4. exit() 시스템콜 자발적 종료 마지막 statement 수행 후 exit() 시스템 콜을 통해 이루어진다. 프로그램에 명시적으로 적어주지 않아도 main 함수가 리턴되는 위치로 컴파일러가 넣어준다. 비자발적 종료 부모 프로세스가 자식 프로세스를 강제 종료 시킬 때 ex) 자식 프로세스가 한계치를 넘어서는 자원을 요청할 때, 자식에게 할당된 태스크가 더 이상 필요하지 않을 때 부모가 종료될 때 (프로세스는 항상 자식이 먼저 종료되고 부모가 종료됨) 키보드로 kill, break 등을 칠 때 프로세스 간 협력 독립적 프로세스 프로세스는 각자의 주소 공간을 가지고 수행되므로 원칙적으로 하나의 프로세스는 다른 프로세스의 수행에 영향을 미치지 못한다. 협력 프로세스 어떤 경우에는 프로세스 협력 메커니즘을 통해 하나의 프로세스가 다른 프로세스의 수행에 영향을 미치며 서로 정보를 교환하는 것이 효율적일 수 있다. 프로세스 간 협력 메커니즘 (IPC: Interprocess Communication) massage passing : 커널을 통해 메시지를 전달한다. (프로세스들끼리 직접은 불가능하다.) Message system : 프로세스 사이에 공유 변수를 일체 사용하지 않고 통신하는 시스템 Direct Communication : 통신하려는 프로세스의 이름을 명시적으로 표시 Indirect Communication : mailbox(혹은 port)를 통해 메시지를 간접 전달 (프로세스 이름을 명시하지 않으므로 다른 프로세스가 열어볼 수 도 있음) shared memory : (원칙적으로는 안되지만) 서로 다른 프로세스 간에도 일부 주소 공간을 공유하게 하는 메커니즘 Thread는 하나의 프로세스이므로 프로세스 간 협력으로 보기에는 어렵다! Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-05-26

4-1. 프로세스 생성과 종료

프로세스의 생성 부모 프로세스가 자식 프로세스를 Copy-on-write(COW) 기법으로 생성한다. COW는 무언가의 변경(write)이 있을 때, 부모의 주소 공간 중 변화가 있는 부분을 copy해 자식의 주소 공간을 만드는 기법이다. 또한, 자식이 자식을 생성하고 그 수가 많아지면 프로세스는 트리를 형성한다. 자식은 부모 프로세스의 ① 주소 공간(binary & OS data)을 복사해 ② 그 공간에 새로운 프로그램을 올린다. ex) 유닉스에서는 fork() 시스템 콜이 주소 공간을 복사하고 exec() 시스템 콜이 새로운 프로그램을 메모리에 올린다. 생성된 프로세스는 자원을 운영체제로부터 받거나 부모 프로세스와 공유한다. (부모와 공유하지 않는 것이 일반적) 수행 : 부모와 자식이 공존하며 수행되는 모델 / 자식이 종료될 때까지 부모가 기다리는 모델 프로세스의 종료 프로세스는 마지막 명령을 수행한 후 exit이라는 시스템콜을 통해 운영체제에게 이를 알려준다. 프로세스 종료는 항상 자식이 먼저 종료되고 그것을 부모 프로세스가 정리하는 원칙이 있다. 그리고 wait 시스템콜을 사용해 자식 프로세스는 자신이 종료될 때 부모 프로세스에게 output data를 보내며 각종 자원들을 운영체제에 반납한다. 부모 프로세스가 자식의 수행을 abort 시스템콜로 강제 종료시키는 경우도 있다. 자식이 할당 자원의 한계치를 넘어설 때 (비유: 자식이 돈을 펑펑 쓸 때) 자식에게 할당된 태스크가 더 이상 필요하지 않을 때 (비유: 자식에게 시키던 일이 전부 끝나서 자식이 필요 없을 때) 부모가 종료될 때, 여러 개의 자식 프로세스들을 차례차례 단계적으로 죽이고 부모가 죽는다. 프로세스의 세계는 꽤 잔인하다! Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-05-26

Fast API tutorial - Installation

Fast API 공식 문서의 튜토리얼을 살펴보고 정리합니다. 본 글은 윈도우 환경을 기준으로 작성되었습니다. Fast API 설치하기 앞에서는 간단히 Fast API와 uvicorn만 설치하여 진행했지만, 이번엔 튜토리얼을 편하게 진행하기 위해 Fast API와 이에 따른 의존 관계가 있는 모듈들을 한꺼번에 설치하겠습니다. 가상환경을 사용한다면 활성화시켜주시고, [all] 옵션을 사용해 Fast API와 관련 모듈들을 한번에 설치합니다. > pip install fastapi[all] 이 때 uvicorn 서버도 함께 설치되기 때문에, 따로 uvicorn을 설치할 필요없이 프로젝트 디렉토리에 main.py 파일만 만들고 바로 서버를 구동할 수 있습니다. 가장 simplest한 형태의 Fast API 코드를 main.py에 작성해 실행해봅시다. main.py 파일을 프로젝트 폴더에 생성하고 다음 코드를 입력해 저장합니다. # main.py from fastapi import FastAPI app = FastAPI() @app.get("/") def root(): return {"message": "Hello World"} 코드 분석 from fastapi import FastAPI: fastapi 모듈에서 파이썬 클래스 FastAPI를 import합니다. app = FastAPI(): app 변수에 FastAPI 인스턴스를 만들어 담습니다. 해당 변수에 이름에 따라 바로 이어 나올 uvicorn 명령어를 다르게 사용합니다. uvicorn main:[변수이름] --reload처럼 말이죠! @app.get("/"): path operation decorator를 만듭니다. path란 //를 제외하고 url에서 첫 번째로 만나는 /로부터 시작되는 url의 뒷 부분을 말하며, operation은 HTTP method를 말합니다. 이 코드의 경우, decorator가 장식하는 함수가 ‘GET operation을 사용해 / path로 가라는 요청’을 처리하는 역할을 한다고 FastAPI에게 알려줍니다. def root():: path operation function을 정의합니다. 이 코드의 경우, FastAPI는 GET operation으로 URL /에 대한 요청이 들어오면 이 함수를 호출합니다. return {"message": "Hello World"}: content를 리턴합니다. 리턴할 수 있는 객체는 dict, list, int, str, Pydantic model 등 다양합니다. 그리고 Uvicorn 서버를 구동합니다. > uvicorn main:app --reload uvicorn main:app --reload의 의미 uvicorn: uvicorn 서버를 실행합니다 main: main.py 파일(모듈)을 의미합니다. app: main.py 내에서 생성한 FastAPI 클래스의 객체를 의미합니다. --reload: 코드를 수정한 후 자동으로 서버를 재시작해주는 옵션입니다. 현재 개발 중일 때 사용합니다. 이제 브라우저로 로컬머신에서 작동 중인 앱을 확인해봅시다. http://127.0.0.1:8000 주소에 들어가면, JSON 형태의 응답으로 다음과 같이 새로이 마주하는 Fast API 세상과 인사를 나눌 수 있습니다! Uvicorn이란? uvloop와 httptools를 사용하는 초고속 ASGI(Asynchronous Server Gateway Interface) web server입니다. 최근까지 파이썬은 asyncio 프레임 워크를 위한 저수준 서버 / 애플리케이션 인터페이스가 없었는데, uvicorn의 등장으로 Fast API같은 프레임워크의 비동기 처리 성능이 크게 향상됐습니다. Starlette이란? Uvicorn 위에서 실행되는 비동기적으로 실행할 수 있는 web application server입니다. FastAPI는 Starlette 위에서 동작하고, Starlette 클래스를 상속받았기 때문에, Starlette의 모든 기능을 사용할 수 있습니다. Reference Fast API 공식 문서 튜토리얼 Uvicorn이란? 비동기 Micro API server로 좋은 FastAPI

Python-Ecosystem · 2021-05-24

파이썬 데코레이터 (Decorator)

파이썬의 함수는 일급 시민이자 일급 객체 일급 객체(First-class object)란 다음과 같은 몇 가지 조건을 갖춤으로 인해서, 해당 객체를 사용할 때 다른 요소들과 아무런 차별이 없는 객체를 의미합니다. 다음은 Robin Popplestone이 정의한 일급 객체의 일반적인 조건입니다. 모든 일급 객체는 함수의 실질적인 매개변수가 될 수 있다. 모든 일급 객체는 함수의 반환값이 될 수 있다. 모든 일급 객체는 할당의 대상이 될 수 있다. (변수 대입) 모든 일급 객체는 비교 연산(==, equal)을 적용할 수 있다. 일급 객체는 자바스크립트에서 파생된 개념이지만 지금은 대다수 프로그래밍 언어에 적용되는 개념입니다. 파이썬에서는 모든 것이 객체이자 일급객체여서, 함수 역시 위 조건을 만족하는 일급 객체에 해당합니다. 데코레이터란? 데코레이터란 기존 함수를 수정하지 않은 상태에서 새로운 기능을 추가할 때 사용하는 장식자입니다. 함수 위에 @를 붙인 것들이 모두 데코레이터에 해당됩니다. def basic_latte(func): def wrapper(): print('Milk') func() print('Espresso') return wrapper def vanilla(): print('Vanilla Syrup') def caramel(): print('Caramel Syrup') vanilla_latte = basic_latte(vanilla) vanilla_latte() print() caramel_latte = basic_latte(caramel) caramel_latte() # 출력 결과 # Milk # Vanilla Syrup # Espresso # # Milk # Caramel Syrup # Espresso 데코레이터의 이해를 위해 다양한 시럽을 베이스로 라떼를 제조해보는 예제로 데코레이터의 기본 구조를 살펴보겠습니다. 위의 basic_latte 함수는 우유와 에스프레소를 추가해주는 함수입니다. 특이한 점은 함수를 인자로 받고 내부에서 새로 정의한 함수 wrapper를 리턴하는 부분인데, 이렇게 하면 기존 함수 func을 매개변수로 사용해 추가 기능을 자유롭게 덧입힐 수 있습니다. 위와 같은 경우 vanilla 함수, caramel 함수에 각각 에스프레소와 우유를 덧입혀 출력한 것이죠! 파이썬의 closure의 개념을 알고 있다면, 이 예제 역시 closure의 일종으로 이해할 수 있습니다. 이 같은 구현이 가능한 이유는 파이썬의 함수가 일급 객체이기 때문입니다. 함수를 인자로 받고 리턴하고 변수에 할당하는 것이 가능함으로 인해 앞으로 강력하게 사용될 데코레이터가 탄생할 수 있었던 것이죠. def basic_latte(func): def wrapper(): print('Milk') func() print('Espresso') return wrapper @basic_latte def vanilla(): print('Vanilla Syrup') @basic_latte def caramel(): print('Caramel Syrup') vanilla() print() caramel() # 출력 결과 # Milk # Vanilla Syrup # Espresso # # Milk # Caramel Syrup # Espresso 데코레이터를 사용하면 위에서 살펴본 라떼 제조를 간단히 실행할 수 있습니다. 단순히 원하는 함수 위에 @추가기능함수이름을 달아주면, 굳이 basic_latte(vanilla)를 하지 않고 vanilla()만 실행해도 원하는 결과를 확인할 수 있습니다. 만일 여러개의 데코레이터를 지정하고 싶다면 다음과 같이 호출하면 됩니다. def espresso(func): def wrapper(): func() print('Espresso') return wrapper def milk(func): def wrapper(): func() print('Milk') return wrapper @espresso @milk def vanilla(): print('Vanilla Syrup') vanilla() # 출력 결과 # Vanilla Syrup # Milk # Espresso 에스프레소와 우유를 각각 덧입혀 바닐라 라떼 제조에 성공했습니다! @를 쓰지 않았을 때의 코드 동작은 espresso(milk(vanilla))() 와 동일합니다. 데코레이터에서 매개변수와 반환값을 처리하기 이번에는 매개변수와 반환값을 처리하는 데코레이터를 만들어 보겠습니다. def make_latte(func): def wrapper(espresso, milk): latte = func(espresso, milk) print(f'{func.__name__}(espresso={espresso}ml, milk={milk}ml) -> latte={latte}ml') return latte return wrapper @make_latte def mix(espresso, milk): return espresso + milk print(mix(60, 200)) # 출력 결과 # mix(espresso=60ml, milk=200ml) -> latte=260ml # 260 데코레이터가 매개변수를 처리할 수 있게끔 만드려면, 안쪽 wrapper 함수를 mix와 똑같은 형태로 매개변수를 받을 수 있게 만들어줘야 합니다. (결국 wrapper 함수가 인자를 받아 실행될 것이기 때문이죠!) 그리고 wrapper 함수 안에서 추가하고 싶은 기능을 만들어 줍니다. 여기서는 mix 함수를 실행한 리턴값을 변수로 저장하고 라떼 레시피와 제조 과정을 출력했습니다. 마지막으로 mix 함수는 에스프레소와 우유의 용량을 합친 수를 리턴해야 하므로, wrapper 함수에서 mix 함수의 반환값을 리턴해주도록 합니다. 만일 이를 잊어버리면, mix 함수를 호출해도 리턴값이 나오지 않으므로 유의해야 합니다. 이로써 매개변수와 반환값을 잘 처리하는 라떼 제조 데코레이터 구현에 성공했습니다. 만일 가변 인수 함수에 기능을 추가하고 싶은 상황이라면 데코레이터 안쪽 wrapper 함수에 *arg, **kwarg를 사용해주면 됩니다. 이렇게 만든 가변 인수 데코레이터는 고정 인수를 사용하는 일반적인 함수에도 사용할 수 있습니다. 매개 변수가 있는 데코레이터 만들기 데코레이터의 또 하나 강력한 점은 인자를 받아 동적으로 적용되는 추가 기능을 덧입힐 수 있다는 것입니다. def make_variation(syrup_name): # 데코레이터의 인자를 추가하는 부분 def make_latte(func): # 실제 데코레이터 부분 def wrapper(espresso, milk): latte = func(espresso, milk) print(f'{func.__name__}(espresso={espresso}ml, milk={milk}ml) with {syrup_name} syrup') print(f'-> {syrup_name}_latte={latte}ml') return latte return wrapper return make_latte # 실제 데코레이터 함수 반환 @make_variation('green_tea') def mix(espresso, milk): return espresso + milk print(mix(60, 200)) # 출력 결과 # mix(espresso=60ml, milk=200ml) with green_tea syrup # -> green_tea_latte=260ml # 260 보통 기본 베이직 커피에 무언가를 더 가미해 다양한 맛을 낸 커피를 베리에이션(variation)이라고 하는데, 여기선 데코레이터의 인자로 시럽의 이름을 받아 기본 라떼의 베리에이션을 만들어 보겠습니다. 코드를 보면 기존에 만들었던 데코레이터와 큰 차이 없이, 단순히 데코레이터의 인자를 받을 함수를 하나 더 덧입혀 삼중으로 처리하고 wrapper 함수의 출력문을 조금 바꿨습니다. 그리고 mix 함수 위에는 새로 덧입힌 함수를 데코레이터로 사용하고 인자로 녹차시럽(green_tea)을 받았습니다. 이렇게 하면, 녹차시럽을 가미한 베리에이션으로 녹차 라떼가 완성됩니다. 데코레이터의 인자를 바닐라 시럽이나 카라멜 시럽으로 바꾸면 동적으로 다른 베리에이션을 만드는 것도 가능합니다. 여러 개의 데코레이터를 지정하다가 원래 함수의 이름이 나오지 않을 때 여러 베리에이션을 만들면 다음과 같이 원래 함수의 이름이 나오지 않을 수 있습니다. # 실제 동작: make_variation('green_tea')(make_variation('vanilla')(mix))(60, 200) @make_variation('green_tea') @make_variation('vanilla') def mix(espresso, milk): return espresso + milk print(mix(60, 200)) # 결과 출력 # mix(espresso=60ml, milk=200ml) with vanilla syrup # -> vanilla_latte=260ml # wrapper(espresso=60ml, milk=200ml) with green_tea syrup # -> green_tea_latte=260ml # 260 참고로 위 함수의 실제 동작은 make_variation('green_tea')(make_variation('vanilla')(mix))(60, 200)으로 실행됩니다. 이 때 원하지 않는 출력 결과로 wrapper 함수의 이름이 나타났는데, 이를 개선하려면 wrapper 함수 위에 functools 모듈의 wraps 데코레이터를 사용해야 합니다. import functools def make_variation(syrup_name): def make_latte(func): @functools.wraps(func) # @functools.wraps에 func을 인자로 넣은 뒤 wrapper 함수 위에 지정 def wrapper(espresso, milk): latte = func(espresso, milk) print(f'{func.__name__}(espresso={espresso}ml, milk={milk}ml) with {syrup_name} syrup') print(f'-> {syrup_name}_latte={latte}ml') return latte return wrapper return make_latte @make_variation('green_tea') @make_variation('vanilla') def mix(espresso, milk): return espresso + milk print(mix(60, 200)) # 결과 출력 # mix(espresso=60ml, milk=200ml) with vanilla syrup # -> vanilla_latte=260ml # mix(espresso=60ml, milk=200ml) with green_tea syrup # -> green_tea_latte=260ml # 260 @functools.wraps 데코레이터를 사용하면 출력 결과가 원하는대로 나오는 것을 확인할 수 있습니다. @functools.wraps 데코레이터는 원래 함수의 정보를 유지시켜 디버깅을 용이하게 합니다. 따라서 데코레이터를 만들 때 함께 사용하는 것이 유용합니다. 클래스로 데코레이터 만들기 기존에 함수로 만들던 데코레이터는 클래스로도 만들 수 있습니다. 다만, 클래스로 데코레이터를 만들 때는 인스턴스를 함수처럼 호출하게 도와주는 __call__ 매직 메서드를 사용해야 합니다. class basic_latte: def __init__(self, func): self.func = func def __call__(self): print('Milk') self.func() print('Espresso') @basic_latte def vanilla(): print('Vanilla Syrup') vanilla() # basic_latte(vanilla)() 형태로 동작해 인스턴스가 생성되고, ()로 인해 __call__ 메서드가 호출됨 # 출력 결과 # Milk # Vanilla Syrup # Espresso 이렇게 코드를 짜면 기존의 함수로 만든 데코레이터와 동일한 결과를 얻을 수 있습니다. 데코레이터로 인해 basic_latte(vanilla)가 먼저 동작해 basic_latte 클래스의 인스턴스가 생성되고 해당 인스턴스에 ()가 붙어 __call__ 메서드가 수행되어 추가로 구현한 기능이 동작하게 됩니다. 클래스로 만든 데코레이터로 매개변수와 반환값도 처리할 수 있습니다. class make_latte: def __init__(self, func): self.func = func def __call__(self, *args, **kwargs): latte = self.func(*args, **kwargs) print('{}(espresso={}ml, milk={}ml) -> latte={}ml'.format(self.func.__name__, *args, latte)) return latte @make_latte def mix(espresso, milk): return espresso + milk print(mix(60, 200)) # 출력 결과 # mix(espresso=60ml, milk=200ml) -> latte=260ml # 260 __call__ 메서드에 mix 함수가 받을 인자를 똑같이 받도록 만들고 mix 함수의 리턴 값을 __call__메서드에서 반환해주면, 기존의 함수 데코레이터와 동일한 결과를 얻는 데코레이터를 클래스로 만들 수 있습니다. 매개 변수가 있는 데코레이터도 클래스로 구현해보겠습니다. class make_variation: def __init__(self, syrup_name): self.syrup_name = syrup_name def __call__(self, func): def wrapper(*args, **kwargs): latte = func(*args, **kwargs) print('{}(espresso={}ml, milk={}ml) with {} syrup'.format(func.__name__ , *args, self.syrup_name)) print(f'-> {self.syrup_name}_latte={latte}ml') return latte return wrapper @make_variation('green_tea') def mix(espresso, milk): return espresso + milk print(mix(60, 200)) # 출력 결과 # mix(espresso=60ml, milk=200ml) with green_tea syrup # -> green_tea_latte=260ml # 260 __init__ 메서드에서 데코레이터의 인자를 초깃값으로 받으면서, 인스턴스 속성으로 저장합니다. 그리고 __call__ 메서드에서 함수를 인자로 받도록 하고, 메서드 내부에 wrapper 함수를 새로 만들어 호출할 함수와 똑같은 형태로 매개변수를 받을 수 있도록 만들어 줍니다. 추가할 기능 역시 wrapper 함수에 구현하고 __call__ 메서드가 wrapper 함수를 리턴하도록 합니다. 그리고 mix 함수의 반환 값을 wrapper 함수가 리턴하도록 만들면 인자를 받는 데코레이터 구현이 완료됩니다. 똑같이 녹차 라떼가 제조됨을 확인할 수 있죠! 데코레이터의 의의 이로써 파이썬에서 데코레이터를 만드는 다양한 형태와 방법을 살펴봤습니다. 클로저 개념에서 발전되어 등장한 데코레이터는 기존 함수를 변형하지 않고 새로운 기능을 추가하는 목적으로 사용하지만, 디버깅에서도 훌륭한 수단이 됩니다. 함수의 성능 측정이나 함수 실행 전 데이터 확인 같은 다양한 목적으로도 사용되므로, 데코레이터에 익숙해지는 것은 효과적인 프로그래밍에 큰 도움이 될 것입니다. Reference python의 함수 decorators 가이드 파이썬 코딩 도장 - 데코레이터 1급 객체(first-class object)란?

Python-Ecosystem · 2021-05-18

3-2. 스레드

Thread (= lightweight process) (↔ heavyweight process, 전통적인 개념의 프로세스) 하나의 프로세스 내부에 CPU 수행 단위를 여러 개 두는 것을 말한다. 각각의 스레드는 CPU 수행과 관련된 정보만 제외하고 프로세스의 모든 것을 공유한다. 동일한 일을 수행하는 프로세스를 여러 개 띄워 놓고 싶다면, 하나의 주소 공간에 여러 개의 스레드를 사용하는 것이 효율적이다. 따라서, Program Counter를 여러 개 두고 register의 값들을 별도로 기억해두어 각각의 스레드가 스스로에게 필요한 code를 실행하게끔 한다. 함수 호출 및 return과 관련해서 stack도 스레드마다 따로 둔다. 스레드의 구성 1. Thread의 구성 program counter register set stack space 2. Thread가 동료 thread와 공유하는 부분 (=task) code section data section OS resources 3. Thread의 장점 Responsiveness(=빠른 응답성) 다중 스레드 태스크 구조에서는 하나의 서버 스레드가 blocked(waiting) 상태인 동안에도 동일한 태스크 내의 다른 스레드가 실행(running)되어 빠른 처리가 가능하다. ex) 웹페이지를 읽어오는 작업(I/O)이 오래걸리면 웹브라우저는 아무것도 못하는 blocked 상태가 된다. 반면에, 여러 개의 스레드로 웹브라우저를 만들면, 그림을 불러오는 작업이 오래 걸리더라도 다른 빠른 작업들을 먼저 화면에 보여줄 수 있다. (일종의 비동기식 입출력) Resource Sharing 메모리 자원을 효율적으로 사용할 수 있다. (자원 절약) Economy Thread를 Creating & CPU switching(문맥교환)하는 것은 process의 그것보다 훨씬 overhead가 작다. 동일한 일을 수행하는 다중 스레드가 협력하여 높은 처리율(throughput)과 성능 향상을 얻을 수 있다. Utilization of MP Architectures (CPU가 여러 개 달린 컴퓨터(Multi-Processor)에서만 해당) 병렬성을 높일 수 있다. ex) 행렬 곱셈 작업을 각 스레드가 다른 CPU에서 서로 다른 행과 열을 병렬로 계산 가능 4. Thread 구현 방법 Kernel Threads Kernel에 의해 지원된다. 스레드가 여러 개 있다는 사실을 운영체제가 알고 있어서 하나의 스레드가 다른 스레드에게 CPU를 넘기는 작업도 운영체제가 CPU 스케줄링하듯 진행한다. User Threads Library에 의해 지원된다. 프로세스 안에 여러 개의 스레드가 있다는 사실을 운영체제가 모르고 유저 프로그램 스스로 여러 개의 스레드를 관리한다. 따라서, 구현 상의 제약이 더 있을 수 있다. 몇몇의 real-time threads Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-05-18

FastAPI - Simple Start

간단한 fast api 설치 및 앱 실행 원하는 가상 환경과 디렉토리에서 fast api 설치 pip install fastapi uvicorn 설치 pip install uvicorn[standard] main.py 파일 생성하기 아래의 코드를 임시로 사용해서 진행하겠습니다. from typing import Optional from fastapi import FastAPI app = FastAPI() @app.get("/") def read_root(): return {"Hello": "World"} @app.get("/items/{item_id}") def read_item(item_id: int, q: Optional[str] = None): return {"item_id": item_id, "q": q} 서버 실행 uvicorn main:app --reload 서버를 실행하면 다음과 같은 api가 생성되어 사용할 수 있습니다. http://127.0.0.1:8000 에서 api 접근합니다. /items/{item_id} 로 접근 가능합니다. (GET method 적용) 쿼리를 날려 JSON 형식으로 응답받을 수 있습니다. 쿼리 요청: http://127.0.0.1:8000/items/5?q=somequery 응답: {"item_id": 5, "q": "somequery"} 다음 주소에서 Swagger UI에서 제공하는 Interactive API docs를 확인할 수 있습니다. http://127.0.0.1:8000/docs 혹은 다음 주소에서 ReDoc에서 제공하는 또 다른 Interactive API docs를 확인할 수 있습니다.

Python-Ecosystem · 2021-05-17

Fast API - Intro

FastAPI 마이크로 프레임워크 마이크로 프레임워크: 필수 기능만 제공하는 경량화된 프레임워크 꼭 필요한 기능만 사용해 빠르고 가볍게 개발 가능 풀스택 프레임워크(장고)가 항공 모함이라고 한다면, 마이크로 프레임워크는 돛단배 추가적으로 필요한 기능은 라이브러리를 붙여 해결 빠른 속도 비동기 프로그래밍으로 I/O 작업(DB 쿼리, 네트워크 통신)이 많은 애플리케이션에 높은 성능 즉, 한 요청이 끝나야 다음 요청을 처리(동기 처리)하는 Django, Flask와 달리, 한 요청이 끝나기 전에 다른 요청을 함께 처리 가능 (비동기 처리) Node.js, Go와 대등할 정도의 높은 성능 (Starlette을 상속 받아 강화시킴) 생산성 간결한 코드로 쉽게 API 개발 빠른 러닝 커브 자동 문서화 Swagger UI, ReDoc 유효성 검사 Pydantic과의 integration으로 강력한 데이터 유효성 검사 (type hint로 지원) 강력한 IDE Auto Completion FastAPI with Open API Specification Open API Specification API schema를 구상할 때 따르길 권장하는 표준 Linux 재단에서 운영하는 공동 프로젝트 모든 HTTP API 스타일을 담진 않지만, 표준을 지켰을 때 RESTful API를 지향할 수 있도록 도움 송수신하는 데이터 타입: JSON schema FastAPI & Open API Specification FastAPI는 Open API Specification을 따름 Open API schema를 통해 Swagger UI와 ReDoc 문서 자동 생성 Starlette FastAPI가 상속하고 있는 경량화된 ASGI 프레임워크 파이썬 프레임워크 중 가장 빠르며 고성능 async 서비스를 만들기 적합 FastAPI는 속도가 빠른 Starlette에 몇가지 기능을 추가한 것 타입 힌트를 통한 데이터 유효성 검사 직렬화 문서 자동화 의존성 주입 및 보안 유틸리티 등 Uvicorn uvloop과 httptools를 사용하는 초고속 ASGI 서버 FastAPI와 Starlette은 Uvicorn 서버 위에서 동작 FastAPI와 Starlette의 속도가 빠른 이유 Pydantic 파이썬 타입 힌트를 사용하여 데이터 유효성 검사를 수행하는 라이브러리 핵심 validation logic이 Rust로 작성되어서 매우 빠름 확장성이 높고 IDE 지원이 잘됨 FastAPI에서는 데이터 유효성 검사와 더불어 직렬화 및 API 문서 정의에 사용

Python-Ecosystem · 2021-05-16

pipenv로 가상환경 설정하기

가상환경이란? 가상 환경은 특정 버전 파이썬 설치와 여러 추가적인 패키지를 포함하는 독립된 디렉토리 트리입니다. 파이썬 공식 문서 설명: https://docs.python.org/ko/3/tutorial/venv.html 여러가지 프로젝트를 진행하다보면 프로젝트마다 라이브러리와 파이썬의 버전이 달라지는데, 이를 각각 관리하기 위해 필요합니다. 협업에 있어서도 동일한 파이썬 환경을 공유하는데 도움이 됩니다. pipenv란? 패키지를 프로젝트 단위로 관리할 수 있도록 도와주는 고급 패키지 관리 도구입니다. 프로젝트 별로 격리된 가상 환경(virtual environment)과 프로젝트 단위의 패키지 관리 매커니즘을 제공합니다. Request 모듈로 잘 알려진 Kenneth Reitz(케네스 레이츠)가 만들었습니다. pipenv의 주요 특징 파이썬 패키지 라이브러리를 관리하는 pip와 가상환경 구축을 지원하는 virtualenv를 동시에 사용할 수 있습니다. Pipfile을 찾으면서 자동으로 프로젝트의 흠을 찾아줍니다. Pipfile과 Pipfile.lock을 통해 자동으로 최신 업데이트할 모듈 및 패키지와 버전을 고정할 모듈 및 패키지를 분류해 관리합니다. 패키지를 설치/삭제하면, 자동으로 Pipfile에서 추가/삭제합니다. 가상환경을 생성할 때, 필요한 python도 자동으로 설치합니다. pipenv 설치 과정 (Window) 내 필요에 맞는 로컬의 파이썬 버전을 업데이트합니다. pip 버전 확인하기 pip --version 이 때 나오는 파이썬 버전이 python3인지(구체적으로는 내 필요에 맞는 파이썬 버전인지) 확인하고 진행합니다. pipenv 설치하기 pip install --user pipenv pipenv 환경변수 설정하기 pip install --user pipenv 코드 실행하면 어떤 주소를 환경변수에 추가하라는 메시지가 나오므로, 그대로 수행합니다. 윈도우 시작메뉴 - 설정 - 검색 - ‘시스템 환경 변수 편집’ - 환경 변수 - ‘<username>에 대한 사용자 변수’ 카테고리의 Path를 누르고 편집 버튼 누르기 - 새로만들기 - 주소 입력 입력하는 주소는 아래의 2개와 같은 모습일 것입니다. (환경 변수를 추가하지 않은 상태에서 pipenv를 cmd에 입력하면 다음 주소를 환경변수에 추가하라는 메시지가 뜹니다.) C:\Users\<username>\AppData\Roaming\Python\Python38\Scripts C:\Users\<username>\AppData\Roaming\Python\Python38\site-packages 터미널을 종료시키고 다시 실행합니다. pipenv --version 코드로 버전을 확인하며, pipenv가 무사히 다운로드되었는지 체크합니다. pipenv 사용법 원하는 파이썬 버전으로 가상환경 만들기 pipenv --python 3.7.5 프로젝트를 진행할 디렉토리에서 실행할 것을 유의합니다! 가상환경 활성화하기 pipenv shell 가상 환경을 생성한 디렉토리에서 실행합니다. 특정한 패키지 다운로드 하기 pipenv install <패키지이름> - 최신 버전으로 다운로드 pipenv install <패키지이름>==<버전> - 지정된 버전으로 다운로드 다운로드 후, Pipfile.lock 파일이 생성되거나 수정됩니다. 해당 프로젝트의 디렉토리에서 실행합니다. (가상환경은 활성화되어도 안되어도 괜찮습니다.) 프로젝트에 사용되는 모든 패키지 다운 받기 pipenv install Pipfile과 Pipfile.lock 파일이 있으면, 여기에 명시되어 있는 모든 패키지를 지정된 버전대로 한 번에 다운 받습니다. 가상환경 비활성화하기 exit 가상환경 삭제하기 pipenv --rm 해당 가상환경이 활성화 되어있는 상태에서 실행합니다. 해당 프로젝트에서 사용하는 가상환경의 실제 위치 확인하기 pipenv --venv 해당 프로젝트의 디렉토리에서 실행합니다. (가상환경은 활성화되어도 안되어도 괜찮습니다.) 해당 프로젝트에서 사용하는 파이썬 인터프리터의 실제 위치 확인하기 pipenv --py 해당 프로젝트의 디렉토리에서 실행합니다. (가상환경은 활성화되어도 안되어도 괜찮습니다.) Pipfile과 Pipfile.lock Pipfile: 해당 프로젝트에서 1차적으로 필요한 패키지들만 포함합니다. 개발자는 새로운 패키지를 추가하거나 삭제할 때, Pipfile만 편집하면 됩니다. Pipfile.lock: 각각의 하위 패키지가 요구하는 패키지를 전부 포함합니다. 프로그램의 정상 동작을 보장하는 만큼의 상세한 패키지 정보는 Pipfile.lock 파일이 자동으로 관리합니다. Reference Pipenv 로 파이썬 가상환경 설정 pipenv 란 무엇인가 pipenv로 패키지 관리하기 좌충우돌 pipenv 도입기

Python-Ecosystem · 2021-05-13

파이썬 클래스 개념 조각 모음

클래스(Class)를 사용하는 이유 관련 있는 데이터를 묶기 위해 배열이, 데이터 묶음 요소마다 의미를 부여하기 위해 딕셔너리가, 의미를 확장해 다양한 정보와 동작들을 한데 묶어 표현하기 위해 클래스가 탄생했다. 보안상의 이슈를 다루기 위해 코드들을 바깥과 분리하여 감싸는 encapsulation 기능이 필요했다. __main__을 사용하는 이유 C, C++ 같은 언어의 main 함수 영향을 받았다. 프로그램의 중심이 되는 코드들을 한 곳에 정리하기 위한 관리상 요인이 작용했다. (덕분에 프로그래밍의 시작점 파악이 용이) 속성(Attribute)의 종류 인스턴스 속성 인스턴스를 통해 접근할 수 있는 속성 (클래스 바깥에서는 인스턴스.속성, 클래스 내부에서는 self.속성으로 접근) __init__ 메서드 안에 정의한 속성 인스턴스 별로 독립되어 있는 속성이며, 각 인스턴스가 값을 따로 저장해야 할 때 사용 인스턴스를 생성한 후에도 자유롭게 속성을 추가할 수 있음 인스턴스.속성 = something (방법 1) 클래스 내 메서드에 속성을 정의하고, 인스턴스 생성 후 호출 (방법 2) __slots__ 메서드로 특정 속성만 추가를 허용하도록 지정 가능 __slots__ = ['속성이름1, '속성이름2'] (속성 이름은 문자열로 지정) >>> class Person: ... __slots__ = ['name', 'age'] # name, age만 허용(다른 속성은 생성 제한) ... >>> maria = Person() >>> maria.name = '마리아' # 허용된 속성 >>> maria.age = 20 # 허용된 속성 >>> maria.address = '서울시 서초구 반포동' # 허용되지 않은 속성은 추가할 때 에러가 발생함 Traceback (most recent call last): File "<pyshell#32>", line 1, in <module> maria.address = '서울시 서초구 반포동' AttributeError: 'Person' object has no attribute 'address' 클래스 속성 클래스에 바로 만든 속성 클래스 내부, 클래스 바깥 모두에서 접근 가능하다. (언더스코어 2개를 사용해 비공개 속성으로도 만들 수 있음) 모든 인스턴스가 공유하는 속성이며, 인스턴스 전체가 사용해야 하는 값을 저장할 때 사용 class Person: bag = [] def put_bag(self, stuff): Person.bag.append(stuff) # self.bag.append(stuff)라고 써도 되지만, 클래스 이름을 쓰는 것이 명확 james = Person() james.put_bag('책') maria = Person() maria.put_bag('열쇠') print(james.bag) # ['책', '열쇠'] print(maria.bag) # ['책', '열쇠'] 속성과 메서드 이름을 찾는 순서 파이썬에서 속성, 메서드 이름을 찾을 때, 인스턴스, 클래스 순으로 찾는다. 위 예에서도 마치 인스턴스 속성을 사용한 것 같지만, 인스턴스 속성이 없으면 클래스 속성을 찾게 되므로 실제로 클래스 속성을 리턴한 것이다. 인스턴스나 클래스에서 __dict__ 속성을 출력해보면 현재 인스턴스와 클래스의 속성을 딕셔너리로 확인할 수 있다. >>> james.__dict__ {} >>> Person.__dict__ mappingproxy({'__module__': '__main__', 'bag': ['책', '열쇠'], 'put_bag': <function Person.put_bag at 0x028A32B8>, '__dict__': <attribute '__dict__' of 'Person' objects>, '__weakref__': <attribute '__weakref__' of 'Person' objects>, '__doc__': None}) 메서드(Method)의 종류 인스턴스 메서드 인스턴스를 통해 접근할 수 있는 메서드 대부분의 일반적인 메서드에 해당되며 첫 번째 파라미터로 self를 지정하는 메서드 (self는 instance 그 자체를 받음) 정적 메서드 인스턴스를 통하지 않고 클래스에서 바로 호출 가능 메서드 위에 @staticmethod를 붙이고 파라미터로 self를 지정하지 않는 메서드 self를 받지 않기 때문에 인스턴스 속성에 접근할 수 없음 그래서 보통 인스턴스 속성, 인스턴스 메서드가 필요없는 메서드, 인스턴스의 상태를 변화시키지 않는 순수함수를 만들 때 사용 class Calc: @staticmethod def add(a, b): print(a + b) @staticmethod def mul(a, b): print(a * b) Calc.add(10, 20) # 클래스에서 바로 메서드 호출 / 30 Calc.mul(10, 20) # 클래스에서 바로 메서드 호출 / 200 클래스 메서드 인스턴스를 통하지 않고 클래스에서 바로 호출 가능 메서드 위에 @classmethod를 붙이고 첫번째 파라미터로 cls를 지정하는 메서드 (cls는 class 그 자체를 받음) cls를 받기 때문에 클래스 속성, 클래스 메서드에 접근할 수 있음 메서드 안에서 클래스 속성, 클래스 메서드에 접근하거나 메서드 안에서 현재 클래스의 인스턴스를 만들 때 사용 class Person: count = 0 # 클래스 속성 def __init__(self): Person.count += 1 # 인스턴스가 만들어질 때 # 클래스 속성 count에 1을 더함 @classmethod def print_count(cls): print('{0}명 생성되었습니다.'.format(cls.count)) # cls로 클래스 속성에 접근 james = Person() maria = Person() Person.print_count() # 2명 생성되었습니다. 비공개 속성과 비공개 메서드 비공개 속성 (Private Attribute) 클래스 바깥에서는 접근할 수 없고 클래스 안에서만 사용할 수 있는 속성 클래스 바깥에 드러내고 싶지 않은 값에 사용한다. __속성으로 사용 class Person: def __init__(self, name, age, address, wallet): self.name = name self.age = age self.address = address self.__wallet = wallet # 변수 앞에 __를 붙여서 비공개 속성으로 만듦 maria = Person('마리아', 20, '서울시 서초구 반포동', 10000) maria.__wallet -= 10000 # 클래스 바깥에서 비공개 속성에 접근하면 에러가 발생함 클래스 내 메서드에서는 접근 가능 class Person: def __init__(self, name, age, address, wallet): self.name = name self.age = age self.address = address self.__wallet = wallet # 변수 앞에 __를 붙여서 비공개 속성으로 만듦 def pay(self, amount): self.__wallet -= amount # 비공개 속성은 클래스 안의 메서드에서만 접근할 수 있음 print('이제 {0}원 남았네요.'.format(self.__wallet)) maria = Person('마리아', 20, '서울시 서초구 반포동', 10000) maria.pay(3000) 비공개 메서드 (Private Method) 클래스 바깥에서는 접근할 수 없고 클래스 안에서만 사용할 수 있는 메서드 클래스 바깥에 드러내고 싶지 않고 보통 내부에서만 호출되어야 할 때 사용한다. __메서드로 사용 class Person: def __greeting(self): print('Hello') def hello(self): self.__greeting() # 클래스 안에서는 비공개 메서드를 호출할 수 있음 james = Person() james.__greeting() # 에러: 클래스 바깥에서는 비공개 메서드를 호출할 수 없음 파이썬 접근 제어 다른 언어와 달리 파이썬은 접근제어자 키워드가 따로 존재하지 않기 때문에 네이밍(naming)을 통해 접근 제어를 수행한다. 다만, 파이썬에서는 네이밍을 사용해 접근을 제어해도 완벽하게 차단할 수는 없다. public, protected, private은 상황별로 다음과 같은 양상을 보인다. public 언더스코어(_)없이 시작하는 속성, 메서드 어디서나 접근 가능 protected 언더스코어 1개로 시작하는 속성, 메서드 어디서나 접근 가능하지만, 암묵적 규칙에 의해 해당 클래스 내부와 파생 클래스에서만 접근해야 함 (파이썬은 protect 기능이 X) private 언더스코어 2개로 시작하는 속성, 메서드 해당 클래스 내부에서만 접근 가능 주요 Dunder Method (=Magic method) __repr__ 해당 class의 string representation을 설정 객체를 출력하면 미리 설정된 사용자가 이해할 수 있는 문자열을 반환 self 파라미터 하나만 받고, 반드시 문자열을 리턴해야 한다. class Employee(): def __init__(self, name): self.name = name def __repr__(self): return self.name argus = Employee("Argus Filch") print(argus) # prints "Argus Filch" __add__ + 기호에 대응하는 메서드 더하는 메서드로서 self 파라미터와 여기에 더할 인자 하나를 받는다. class Color: def __init__(self, red, green, blue): self.red = red self.green = green self.blue = blue def __repr__(self): return "Color with RGB = ({red}, {green}, {blue})".format(red=self.red, green=self.green, blue=self.blue) def __add__(self, other): """ Adds two RGB colors together Maximum value is 255 """ new_red = min(self.red + other.red, 255) new_green = min(self.green + other.green, 255) new_blue = min(self.blue + other.blue, 255) return Color(new_red, new_green, new_blue) red = Color(255, 0, 0) green = Color(0, 255, 0) blue = Color(0, 0, 255) # Color with RGB: (255, 0, 255) magenta = red + blue # Color with RGB: (0, 255, 255) cyan = green + blue # Color with RGB: (255, 255, 0) yellow = red + green # Color with RGB: (255, 255, 255) white = red + green + blue __len__ len() 함수를 호출했을 때의 결과 값을 임의로 설정해 리턴할 수 있는 메서드 __iter__ iterator 객체를 반환해 반복가능한 객체로 만들어 주는 메서드 __contains__ 멤버 연산자 in을 사용할 수 있게 해주는 메서드 클래스 관련 메서드 특정 클래스의 인스턴스인지 확인하기 isinstance(인스턴스, 클래스) True, False 반환 해당 객체가 특정 속성을 가지고 있는지 여부 확인하기 hasattr(객체, '속성') True, False 반환 hasattr(attributeless, "fake_attribute") # returns False 해당 객체에서 특정 속성의 값을 가져오기 getattr(객체, '속성', default) 속성이 있으면 속성의 값 반환, 없으면 디폴트 값 반환 getattr(attributeless, "other_fake_attribute", 800) # returns 800, the default value 특정 클래스 A가 클래스 B의 subclass인지 확인하기 issubclass(클래스 A, 클래스 B) True, False 반환 Reference 파이썬 코딩 도장 Codecademy - learning python 3 private, proteted, public 의 차이 인스턴스 메소드의 종류와 용법 (Instance methods): Public, Protected, Private 접근제어자 (Access Modifiers)

Python-Ecosystem · 2021-05-10

REST API 이해하기

REST API의 정의 Representational State Transfer의 약자 정보들을 주고 받는 HTTP 요청을 보낼 때, 어떤 URI에 어떤 메서드를 사용할지 개발자들 사이에 널리 지켜지는 약속 (Software Architecture) REST를 지켰을 때 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체만 봐도 추론 가능해짐 과거의 복잡했던 SOAP 방식을 대체하여 최근에 가장 널리 쓰이는 양식 REST API의 구성 자원(Resource) - URI를 통해 식별 (네트워크 상에 존재하는 자원을 구분하는 식별자) 행위(Verb) - HTTP Method에 따라 자원에 접근 표현(Representations) 혹은 정보(Message) - HTTP 헤더와 바디, 응답 코드를 활용 REST의 특징 Uniform 리소스에 대한 조작이 통일되고 한정적인 인터페이스로 구성된 아키텍처 스타일 (Uniform Interface) Stateless 작업을 위한 상태정보를 따로 저장, 관리하지 않고 단순히 들어오는 요청만 처리 덕분에 구현이 단순해짐 Cacheable 기존 웹표준을 사용하므로 웹의 기존 인프라를 이용해 캐싱 기능 적용 가능 Self-descriptiveness REST API 메시지만으로도 무슨 의미인지 쉽게 이해할 수 있는 자체 표현 구조를 가짐 Client - Server 구조 서버와 클라이언트의 구분이 명확 계층형 구조 REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있음 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 함 REST API 디자인 가이드 요약 REST API 중심 규칙 URI는 정보의 자원을 표현해야 합니다. 리소스 명은 동사보다는 명사를 사용 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현합니다. POST: 해당 URI를 요청하면 리소스를 생성합니다. GET: 해당 리소스를 조회합니다. PUT: 해당 리소스를 수정합니다. DELETE: 해당 리소스를 삭제합니다. URI 설계 시 주의할 점 슬래시 구분자는 계층관계를 나타낼 때 사용합니다. 마지막 문자로 슬래시를 포함하지 않습니다. 하이픈(-)은 URI 가독성을 높이는데 사용합니다. 언더스코어(_)는 가독성을 해치므로 URI에 사용하지 않습니다. URI 경로에는 소문자가 적합합니다. 파일 확장자(.jpg, .png 등)는 URI에 포함시키지 않습니다. 리소스 간의 관계를 표현하는 방법 REST 간의 연관 관계는 다음과 같이 표현합니다. /리소스명/리소스 ID/관계가 있는 다른 리소스명 GET : /users/{userid}/books (일반적으로 소유 ‘has’의 관계를 표현할 때) 관계명이 복잡하다면 서브 리소스에 명시적으로 포함할 수 있습니다. GET : /users/{userid}/likes/books (관계명이 애매하거나 구체적 표현이 필요할 때) Collection과 Document 개념을 활용한 리소스 표현 Collection: 문서들의 집합, 객체들의 집합 Document: 하나의 문서, 하나의 객체 Collection과 Document로 표현하면 URI 설계가 더욱 용이해집니다. http://restapi.com/sports/soccer/players/7 sports, players라는 Collection과 soccer, 7이라는 document로 표현 Collection은 복수로 Document는 단수로 표현해주는 것이 좋습니다. REST API의 정보 HTTP 바디 자원에 대한 정보를 HTTP 바디에 데이터로 담아 전달합니다. 데이터 포멧으로는 최근 JSON이 가장 많이 쓰입니다. HTTP 헤더 HTTP 바디의 컨텐츠 종류를 명시할 수 있고 인증 권한 정보를 담습니다. 요청 HTTP 헤더는 ‘Accept’ 항목을, 응답 HTTP 헤더는 ‘Content-type’을 담습니다. 다음은 ‘Content-type’의 몇 가지 예입니다. application/json application/xml text/plain image/jpeg image/png HTTP 응답 상태 코드 잘 설계된 REST API는 URI 뿐만 아니라 요청에 대한 응답까지 잘 내어주어야 합니다. 200: 클라이언트의 요청을 정확히 수행함 201: 클라이언트가 어떤 리소스 생성을 요청했고, 해당 리소스가 성공적으로 생성됨 (POST로 리소스 생성 시) 400: 클라이언트의 요청이 부적절함 401: 인증 받지 않은 클라이언트가 인증이 필요한 리소스를 요청함 403: 인증 유무와 관계없이, 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용 리소스의 존재를 인정하는 것이므로 403 사용을 지양하고 401, 404 사용을 권고 404: 클라이언트가 요청하는 리소스를 찾을 수 없음 405: 클라이언트가 요청한 리소스에서는 사용 불가능한 메서드를 이용함 301: 클라이언트가 요청한 리소스에 대한 URI가 변경됨 Location header에 변경된 URI 적어줄 것 500: 서버에 문제가 있음 Reference REST API 제대로 알고 사용하기 REST API 이해하기

Computer Science · 2021-05-07

순간 놓치기 쉬운 파이썬 개념들 정리

2진수, 8진수, 16진수로 정수 표현하기 >>> 0b110 # 2진수 6 >>> 0o10 # 8진수 8 >>> 0xF # 16진수 15 보다 정교한 계산으로 부동소수점 오류를 피하는 자료형 Decimal from decimal import Decimal cost_of_gum = Deciaml('0.10') cost_of_gumdrop = Decimal('0.35') cost_of_transaction = cost_of_gum + cost_of_gumdrop print(cost_of_transaction) # Returns 0.45 instead of 0.44999999999999996 빈 변수 만들기 >>> x = None # 다른 언어의 null 값 >>> print(x) None del 키워드가 사용되는 경우 변수 삭제, 리스트 요소 삭제, 딕셔너리 요소 삭제 언더스코어 변수( _ ) 파이썬 셸에서 코드를 실행했을 때 결과는 _(밑줄 문자) 변수에 저장됩니다. 따라서 _를 사용하면 직전에 실행된 결과를 다시 가져올 수 있습니다. 단락 평가(short-circuit evalution) 단락 평가란 첫 번째 값만으로 결과가 확실할 때 두 번째 값은 확인(평가)하지 않는 방법을 말합니다. 논리 연산에서 단락 평가는 중요합니다. 예를 들어, Fasle and True는 and 앞이 False이기 때문에 뒷 부분을 고려할 필요없이 결과가 False가 됩니다. 실제 연산에서도 False and True는 단락 평가를 진행해 앞 부분만 확인하여 결과를 리턴합니다. 따라서, 복잡한 논리 연산일수록, 전체 결과를 빠르게 판단할 수 있는 식이 있다면 최대한 앞으로 빼서 효율적으로 연산이 동작하게끔 작성해야 합니다. 또한, 파이썬에서 논리 연산자는 마지막으로 단락 평가를 실시한 값을 그대로 반환하는 점을 유의해야 합니다. 논리 연산자는 무조건 불을 반환하지 않습니다. True and 'Welsh Corgi' # 'Welsh Corgi' 리턴 'Welsh Corgi' and True # True 리턴 'Welsh Corgi' and False # False 리턴 False and 'Welsh Corgi' # False 리턴 0 and 'Welsh Corgi' # 0 리턴 자료형(객체) 구분 1. 시퀀스 자료형 리스트, 튜플, range, 문자열처럼 값이 연속적으로 이어진 자료형을 시퀀스 자료형(sequence types)라고 부릅니다. 수행 가능 연산: in 연산자 +, * 연산 (range 제외) len() 함수 인덱싱([] ∝ getitem 메서드) & 슬라이싱(∝ 슬라이스 객체 생성 후 [] 또는 getitem 메서드에 삽입) 인덱스로 값 할당 및 del 삭제 (list만 가능, 다만 범위를 벗어나면 안됨) 슬라이싱으로 값 할당 및 del 삭제 (list만 가능) 슬라이싱으로 값 할당 및 del 삭제 슬라이싱으로 범위를 지정해 값 할당 및 삭제를 진행할 때, 새 리스트를 생성하지 않고 기존 리스트를 변경합니다. 범위와 요소의 개수가 정확히 일치하지 않아도 됩니다. 예 1) a = [0, 10, 20, 30, 40, 50, 60, 70, 80, 90] a[2:5] = ['a'] # 인덱스 2부터 4까지에 값 1개를 할당하여 요소의 개수가 줄어듦 a [0, 10, 'a', 50, 60, 70, 80, 90] 예 2) a = [0, 10, 20, 30, 40, 50, 60, 70, 80, 90] a[2:5] = ['a', 'b', 'c', 'd', 'e'] # 인덱스 2부터 4까지 값 5개를 할당하여 요소의 개수가 늘어남 a [0, 10, 'a', 'b', 'c', 'd', 'e', 50, 60, 70, 80, 90] 예 3) a = [0, 10, 20, 30, 40, 50, 60, 70, 80, 90] a[2:5] = ['a', 'b', 'c'] # 인덱스 2부터 4까지 값 할당 a [0, 10, 'a', 'b', 'c', 50, 60, 70, 80, 90] 범위에 인덱스 증가폭을 설정해서 값을 할당할 수도 있습니다. (다만, 이 때는 범위에 해당하는 요소 개수와 할당할 요소의 개수가 일치해야 합니다.) 예) a = [0, 10, 20, 30, 40, 50, 60, 70, 80, 90] a[2:8:2] = ['a', 'b', 'c'] # 인덱스 2부터 2씩 증가시키면서 인덱스 7까지 값 할당 a [0, 10, 'a', 30, 'b', 50, 'c', 70, 80, 90] del을 사용해 일반적으로 값을 삭제할 수 있지만, 인덱스 증가폭을 사용해서 값을 삭제할 수도 있습니다. 예) a = [0, 10, 20, 30, 40, 50, 60, 70, 80, 90] del a[2:8:2] # 인덱스 2부터 2씩 증가시키면서 인덱스 6까지 삭제 a [0, 10, 30, 50, 70, 80, 90] 2. 반복 가능한(iterable) 객체 문자열, 리스트, 딕셔너리, 세트 같이, 요소가 여러 개 들어있고, 한 번에 하나씩 꺼낼 수 있는 객체입니다. 반복 가능한 객체는 iter 메서드를 포함하고 있으며, 이 메서드를 호출해 이터레이터(iterator)를 생성할 수 있습니다. 3. 변경 가능한(Mutable) 객체 객체의 값이나 요소가 변경 가능한지 아닌지에 따라 나뉘는 기준이다. Mutable한 객체 list, dict, set을 외워두는게 기억하기 편리하다. 참고하기 좋은 표 얕은 복사와 깊은 복사 얕은 복사 (=주소값 복사) 파이썬은 모든 변수에 주소값이 담기므로, 단순히 변수에 할당하는 방식으로는 새로운 객체를 복사하는 것이 아니라 동일한 객체를 가리키게 된다. a = [0, 0, 0, 0, 0] b = a a is b True 깊은 복사 (1차원) 파이썬 내장함수 copy() 슬라이싱을 통한 복사 ex) a[:] 깊은 복사 (다차원) copy 모듈의 deepcopy() 메서드 사용 튜플을 사용하는 이유 리스트가 언제든 요소를 추가할 수 있게 하기 위해 실제 데이터보다 큰 메모리를 사용하는데 반해, 튜플은 요소 변경이 없어 고정된 메모리를 사용합니다. 또한, 튜플의 구조는 간단해서 리스트보다 빠른 성능을 보여줍니다. 따라서, 요소 변경이 없는 상황에서는 튜플을 사용하는 것이 메모리를 아끼고 성능을 높이는 방법입니다. defaultdict를 사용해 기본값이 빈 리스트인 딕셔너리 생성하기 from collections import defaultdict a = defaultdict(list) a['x'] a['y'] print(a) defaultdict(<class 'list'>, {'x': [], 'y': []}) 딕셔너리에서 요소를 삭제하는 방법 딕셔너리에서 요소를 삭제하는 방법은 제한적이기 때문에 보통 다음과 같은 방법을 사용한다. 1. 키를 통해 삭제하기 del 예약어, pop(‘키’, 기본값) 메서드 사용합니다. popitem() 메서드를 사용하면, 파이썬 3.6 이상에서는 딕셔너리의 가장 마지막에 있는 키, 값 쌍을 삭제하여 튜플로 반환하고, 3.6 미만에서는 임의의 키, 값 쌍을 삭제하여 튜플로 반환합니다. 2. 값을 통해 삭제하기 (특정 값을 제외하여 새로 딕셔너리를 생성) 딕셔너리 표현식을 사용합니다. x = {'a': 10, 'b': 20, 'c': 30, 'd': 40} x = {key: value for key, value in x.items() if value != 20} x {'a': 10, 'c': 30, 'd': 40} 파일 객체는 이터레이터입니다! open을 통해서 가져오는 파일 객체는 이터레이기 때문에, for문에서 반복하거나 언패킹할 수 있습니다. file = open('welsh.txt', 'r') a, b, c = file a, b, c ('안녕하세요.\n', '멍멍!\n', '저는 웰시 코기입니다.\n') random 모듈에서 자주 사용되는 메서드들 import random # 0이상 1미만 범위의 난수 생성 random.random() # return: 0 <= x < 1에 해당하는 x 값 # 지정한 범위에 해당하는 정수 하나를 랜덤하게 가져오기 random.randint(1, 16) # return: 1 <= x <= 16에 해당하는 int 타입 x 값 # 지정한 범위에 해당하는 실수 하나를 랜덤하게 가져오기 random.uniform(1, 20) # return: 1.0 <= x < 20.0에 해당하는 float 타입 x 값 # range(start, stop, step) 함수로 만들어지는 정수들 중 랜덤하게 하나를 가져오기 random.randrange(1, 9, 2) # return: 1, 3, 5, 7 중 하나의 값 seq = ['a', 'b', 'c', 'd'] # 시퀀스 객체 내 요소 순서를 무작위로 변경하기 random.shuffle(seq) # seq: ['c', 'b', 'a', 'd'] # 시퀀스 객체에서 요소 하나를 랜덤하게 가져오기 random.choice(seq) # return: 'c', 'b', 'a', 'd' 중 하나의 값 # 시퀀스 객체에서 요소 여러 개를 랜덤하게 가져오기 random.sample(seq, 2) # return: seq 리스트에서 2개의 요소를 뽑아 리스트로 만들어 리턴 datetime 모듈 사용법 from datetime import datetime # datetime 객체 생성하기 # datetime(년, 월, 일, 시간, 분, 초) birthday = datetime(1994, 6, 27) # datetime.datetime(1994, 6, 27, 0, 0) birthday = datetime(1994, 6, 27, 6, 30, 27) # datetime.datetime(1994, 6, 27, 6, 30, 27) # year, month, day, hour, minute, second 속성에 접근 가능 birthday.year # 1994 birthday.month # 6 # weekday() 메서드를 사용하면 요일을 0(월) ~ 6(일) 인덱스로 반환 birthday.weekday() # 0 # 현재 시간으로 datatime 객체 생성하기 datetime.now() # datetime.datetime(2021, 5, 7, 23, 46, 7, 925228) # datetime 객체로 두 날짜 사이의 시간 차이 구하기 datetime(2021, 1, 2) - datetime(2020, 1, 1) # datetime.timedelta(days=367) datetime.now() - datetime(2021, 1, 1) # datetime.timedelta(days=126, seconds=86052, microseconds=468421) # 문자열로 된 시간을 datetime 객체로 파싱하기 parsed_date = datetime.strptime('Jan 15, 2019', '%b %d, %Y') parsed_date.month # 1 parsed_date.day # 15 parsed_date.minute # 0 # datetime 객체를 문자열로 만들기 date_string = datetime.strftime(datetime.now(), '%b %d, %Y') date_string # 'May 08, 2021' strftime() and strptime() Format Codes 는 다음 링크에서 확인 https://docs.python.org/3/library/datetime.html 함수에서 파라미터의 초깃값을 빈 리스트로 만들고 싶은 경우 함수 파라미터의 초깃값으로는 Immutable한 객체만 사용해야 한다. 만일 Mutable한 객체라면, 여러번 함수를 호출해도 처음에 초깃값으로 생성한 객체를 조작하게 된다. 따라서, 리스트를 인자로 받을 파라미터의 초깃값을 None으로 설정하고 함수 내부에서 if 조건문으로 체크하는 것이 바람직하다. def add_author(authors_books, current_books=None): if current_books is None: current_books = [] current_books.extend(authors_books) return current_books Reference 파이썬 코딩 도장 파이썬 del - 제타위키 파이썬 기초 Python, 파이썬 - Call by assignment, mutable, immutable, 파이썬 복사(Python Copy)

Python-Ecosystem · 2021-05-06

3-1. 프로세스

프로세스(Process)의 개념 1. 프로세스 실행중인 프로그램을 의미한다. 2. 프로세스의 문맥(Context) 프로세스의 현재 진행 상태를 알려주는 것 time sharing, multitasking 등의 실현은 각 프로세스의 문맥을 정확히 기록해두어야 가능하다! 하드웨어 문맥 : CPU의 수행 상태를 나타냄 ex) Program Counter, 각종 register → CPU 관점에서 파악! 프로세스의 주소 공간 : 어떤 자료구조가 어떤 값을 가지고 있는지, 어떤 함수가 호출되고 return되는지 등을 파악함 ex) code, data, stack → 메모리 관점에서 파악! 프로세스 관련 커널 자료 구조 ex) PCB(Process Control Block), Kernel stack(프로세스마다 다른 커널 스택을 가지기에 개별로 상태 파악 가능) → 운영체제 관점에서 파악! (운영체제가 프로세스를 어떻게 평가하는지) 프로세스의 상태 (Process State) Running : CPU를 잡고 Instruction을 수행 중인 상태 Ready : 메모리에 올리는 것 등 다른 조건을 모두 만족하고 CPU를 기다리는 상태 Blocked (wait, sleep) : CPU를 주어도 당장 Instruction을 수행할 수 없는 상태 ex) 프로세스 자신이 요청한 event(ex. I/O)가 즉시 만족되지 않아 기다리는 상태, 프로세스 주소 공간 중 필요한 부분이 메모리에 아직 올라와 있지 않을 때 등 현대 컴퓨터에 중기 스케줄러의 등장으로 추가된 상태 Suspended (stopped) : 외부적 이유로 프로세스의 수행이 정지된 상태. 프로세스는 통째로 디스크에 swap out된다. ex) 메모리에 너무 많은 프로그램이 올라와 있을 때 (by 중기 스케줄러), 사용자가 프로그램을 일시 정지시킨 경우 Blocked : 자신이 요청한 event가 만족되면 Ready Suspended : 외부에서 resume해 주어야 Active 있을 수도 없을 수도 있는 상태 New : 프로세스가 생성 중인 상태 Terminated : 수행(Execution)이 끝난 상태 프로세스의 상태도 프로세스 상태도 - suspended 상태 추가 위의 프로세스 상태도는 운영체제의 입장에서 프로세스 상태를 명시한 것이다. 따라서, monitor mode에서도 운영체제가 running하고 있다고 말하지 않고, 사용자 프로세스가 Running 상태에 있다고 말한다. 또한, interrupt 혹은 system call을 진행 중일 때, 사용자 프로세스는 (커널모드 혹은 유저모드에서) Running 상태에 있다고 간주한다. Suspended 상태의 경우, 외부적인 이유로 메모리에서 벗어나 있는 상태로서 inactive하다고 말하고, Blocked에서 벗어났느냐 Ready에서 벗어났느냐에 따라 Suspended Blocked, Suspended Ready로 나뉜다. 또한, Suspended Blocked 상태에서 이전에 요청한 I/O 작업이나 event가 마무리되면 Suspended Blocked이 Suspended Ready로 바뀌기도 한다. 프로세스 진행과 queue 커널 주소 공간의 자료구조 Queue 위 상태도에서 나오는 하드웨어 및 CPU의 Queue들은 머릿 속에서는 모두 흩어져 있는 것으로 분류되지만, 사실은 모두 커널 주소 공간 중 Data 영역에서 queue 자료구조를 만들어 관리하는 것이다. PCB (Process Control Block) 운영체제가 각 프로세스를 관리하기 위해 프로세스당 유지하는 정보 PCB의 구조 PCB의 구성 요소 (구조체로 유지) OS가 관리상 사용하는 정보 ex) Process state, Process ID, scheduling information & priority CPU 수행 관련 하드웨어 값 (프로세스 문맥 정보) ex) Program Counter, registers 메모리 관련 (프로세스 문맥 정보) ex) code, data, stack의 위치 정보 파일 관련 (프로세스 문맥 정보) ex) open file descriptors 문맥 교환 (Context Switch) CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정 문맥 교환 흐름 위 그림의 프로세스 A가 프로세스 B에게 CPU를 넘겨줄 때, 운영체제는 정확히 그 시점부터 프로세스 A가 다시 시작할 수 있게 프로세스 A의 PCB에 레지스터들의 저장된 값, Program Counter 값, 메모리 위치 정보 등을 저장한다. 새롭게 CPU를 얻게 되는 프로세스 역시 운영체제가 해당 프로그램의 PCB에서 상태를 읽어와 저장된 시점부터 다시 작업을 수행한다. 문맥 교환이 일어나는 경우와 아닌 경우 System call이나 Interrupt 발생 시 항상 문맥 교환이 일어나진 않는다. 보통은 위 그림의 (1)의 경우처럼 원래 작업 중이던 프로세스에게 다시 CPU 제어권을 넘겨 timer가 정한 시간에 도달할 때까지 작업을 수행하게 한다. 그러나 timer가 정한 시간이 다 되거나 I/O 요청으로 인해 프로세스가 blocked 상태가 되는 (2)의 경우에는 문맥 교환이 발생한다. 물론 (1)의 경우에도 커널 code를 실행하기 위해 CPU 수행 정보 등 약간의 context를 PCB에 저장해야 되지만 문맥 교환만큼 부담이 크지 않다. ex) Cache memory flush(캐시 메모리를 비우는 것)는 overhead가 큰데, 문맥 교환 시에는 이러한 캐시 메모리를 비워야 하는 반면, 단순한 커널모드와 유저모드 사이의 변환에서는 캐시 메모리를 비울 필요까지는 없다. 프로세스를 스케줄링하기 위한 큐 (Queue) Job queue : 현재 시스템 내에 있는 모든 프로세스의 집합 (Ready queue와 Device queue의 프로세스를 포함) Ready queue : 현재 메모리에 있으면서 CPU를 잡아 실행되기를 기다리는 프로세스의 집합 (혹은 줄) Device queue : I/O device의 처리를 기다리는 프로세스의 집합 (혹은 줄) 스케줄러 Long-term scheduler (장기 스케줄러 or job scheduler) 시작 프로세스 중 어떤 것에게 memory를 주고 ready queue로 보낼지 결정한다. degree of Multiprogramming(메모리에 올라가 있는 프로세스의 수)을 제어 메모리에 올라가 있는 프로그램 수가 너무 많아도 너무 적어도 안좋다. 그러나 현대의 대부분 컴퓨터의 time sharing system에서는 사용하지 않는다. (무조건 메모리에 프로세스를 올린다. = ready) Short-term scheduler (단기 스케줄러 or CPU scheduler) 어떤 프로세스에게 CPU를 주고 running 상태로 만들지 결정한다. 빠른 속도 (millisecond 단위) Medium-term scheduler (중기 스케줄러 or Swapper) 메모리 여유 공간을 마련하기 위해 메모리에 있는 프로세스를 통째로 디스크로 쫒아낸다. Long-term scheduler를 대신해 현대 컴퓨터의 degree of Multiprogramming을 제어 (프로그램은 실행 시 무조건 메모리에 올라가므로 어떤 것을 쫒아낼지가 이슈가 된다.) Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-05-04

2-2. 프로그램의 실행

Computer Science · 2021-05-02

Git 기초

Git 기초 Git 기본 이용 사이클 Git 저장소 선언하기 (Initialization & Repository) Git 저장소를 흔히 Repo(레포)라고 부르며, Repo는 git으로 관리하는 하나의 메인 저장소를 뜻함 사용자가 변경한 모든 내용 추적 가능 현재 상태, 변경 시점, 변경한 사용자, 설명 텍스트 등 관리할 폴더에서 git init 을 통해 선언 주목할 특징 Git은 이제 Local에서 모든 것을 저장 및 버전 관리 가능하고 나중에 원격 서버에 올려도 상관 없음 Git은 데이터를 추가만 할 수 있음 파일 삭제 == 삭제 기록 추가 (물론 온전한 삭제도 가능하지만, 버전 관리에서는 삭제 기록도 매우 중요) Git은 파일을 추적하지 않음 파일의 내용 단위로 각 문자와 줄을 추적 빈 디렉토리는 추적하지 않음 파일 추가/수정/삭제 변경 사항 선택 파일 상태 파일은 추적 여부로 구분해 tracked, untracked 파일로 나눌 수 있음 tracked 파일은 Unmodified(수정 없음), Modified(수정 있음), Staged(저장(커밋)을 위해 준비됨) 상태로 구분됨 스테이징(Staging)을 통해 커밋하고 싶은 파일 선택 스테이징이 필요한 이유? 여러 작업 중 일부분만 커밋해야 할 때 커밋 전 상태를 수정 또는 체크할 때 (안전하게 커밋하기 위함) 상태 업데이트 커밋(Commit)을 통해 새로운 버전으로 업로드 커밋을 하면, 각 버전마다 40자리의 숫자 + 알파벳 조합으로 이루어진 해시값이 존재 해시 값은 버전의 주소(Key) 해시값은 내용(파일 구조)을 사용해 생성됨 (파일이 어떤 폴더 밑에 있고, 어떤 내용이다 등의 상태를 40자리로 표현) Commit Hash 값으로 Checkout하면 버전 이동 가능 Git Branch 소프트웨어 버전 넘버링 상식 보통 세가지 숫자로 표현되며, 위 그림과 같이 각각 의미가 다름 마지막에 알파벳이 들어가는 경우도 있지만, 보통은 모두 숫자로 사용 1.1, 2.1 같이 두 개로 표현된 경우, 1.0.1, 2.0.1을 뜻함 브랜치 (Branch) 버전 관리시 수많은 오류를 개발자들이 각각 따로 처리하는 상황이 발생하는데, 이를 위해 브랜치 개념이 등장 브랜치는 시간의 흐름의 축 Git 명령어 프로젝트 총 관리자 및 시작자 관점 프로젝트 시작 선언 git init .git 파일이 생성됨 (처음엔 숨김 상태라 안보임) 모든 버전 관리 정보가 담겨있으므로 조심해야 함 (버전을 초기화하고 싶을 땐, 이 폴더를 통째로 삭제하면 됨) 로컬에서 Git 초기화 진행 시작 버전은 master branch에 기록 .gitignore 파일을 생성해 양식(정규표현식)에 맞춰 작성하면, 저장하고 싶지 않은 파일들을 무시할 수 있음 README.md 파일 작성 Repo의 메인 페이지 역할 프로젝트 설명 및 사용방법, 라이센스 등을 기술 유저 이름과 이메일 등록하기 (log에 남기는 용도) git config --global user.name="[이름]" : 깃 설정 파일을 내 모든 컴퓨터에 적용, 그 중 이름 정보 입력하겠다. git config --global user.email="[이메일]" : 깃 설정 파일을 내 모든 컴퓨터에 적용, 그 중 이메일 정보 입력하겠다. 파일 스테이지로 올리기 git add [file] [file]을 스테이지로 올림 (폴더나 전체도 가능) 스테이지에서 내리기 git restore --staged [file] 파일 상태 체크하기 (습관적으로) git status git diff 스테이지에 있는 내용 커밋 git commit -m "add README.md" 간단한 설명과 함께 커밋 커밋 기록 살펴보기 git log 조금 더 시각적으로 편하게 살펴보는 방법 git log --all --decorate --graph --oneline 위 방법에 간단한 별명을 붙이는 방법 git config --global alias.adog "log --all --decorate --graph --oneline" 원격 저장소와 연결 git remote add origin [url] origin이라는 이름으로 [url]과 연결 (origin은 원격 저장소에 관용 표현이므로 변경 가능) 연결 여부를 확인하는 명령어 git remote -v 원격 저장소로 올리기 git push origin master 원격 저장소 master branch에 업데이트 로컬과 원격 저장소가 동기화됨! 버전 이동하기 git log 로 원하는 버전의 해시값 확인 만일 과거로 돌아와 미래 로그가 안보인다면, git log --all git checkout [40자리 해시값의 앞 7자리] 예시 git checkout a703380 git checkout master 협업하는 개발자 시점 원격 저장소 다운받기 git clone [url] 파일 구조, 로그를 포함한 모든 것이 다운로드됨 기능별로 개발하기 master 브랜치는 배포 버전이므로 함부로 커밋하기 어려움… 필요한 기능은 병렬적으로 가지쳐서 개발하자! git branch [name] 처음에는 master를 가리키는 것처럼 보이지만 커밋하면 branch를 가리키는 것을 확인할 수 있음 [name] 없이 git branch를 쓰면, 현재 브랜치가 무엇인지 확인 가능 브랜치/버전 이동하기 git checkout [name] 브랜치 합치기 git merge [name] [name] 브랜치를 현재 브랜치로 합치기 기능 완성 후, master와 합치는데 주로 이용 같은 파일만 건드리지 않았으면 문제 없이 병합 가능! 가지가 복잡한 브랜치 합치기 git rebase master - 자주 사용!! base(기준점)를 master의 끝 점으로 re-base(재설정)해서 그래프를 한 줄로 만듬 브랜치 지우기 git branch -d [name] 완료했거나 필요가 없어진 브랜치를 삭제 프로젝트 리더 시점 다른 개발자가 원격에 메인 버전을 업데이트 하면, 최신 버전을 다운받아 오고 싶음 원격에서 기록 가져오기 git fetch - 자주 사용!! 원격 저장소와 동기화하지만 merge는 하지 않음 동일 파일을 건드리는 Conflict를 방지하기 위해 미리 체크할 수 있음 원격에서 기록 가져오고 합치기 git pull 원격 저장소와 동기화하고 merge까지 진행 충돌을 일으킨 개발자 시점 같은 파일의 같은 부분을 수정하고 합칠 때는 충돌(Conflict)이 발생함 커밋 되돌리기(reset, revert), 직접 충돌 부분 수정하기 등 다양한 해결법 존재 실수한 커밋을 RESET하기 git reset [option] [commit의 7자리 해시값] 해당 커밋 이후 기록을 없애기 (Hard, Mixed, Soft) 커밋으로 프로젝트가 망하면, 원하는 커밋으로 reset 가능 이미 원격 저장소에 올라가 있는 경우 사용해서는 안됨! 다른 개발자들과 버전이 달라져버린다… 실수한 커밋도 내 커밋, 기록하자! git revert [commit의 7자리 해시값] - 가장 좋음!! 되돌릴 커밋이 여러개라면 범위를 주어 한번에 되돌릴 수 있음 git revert [commit의 7자리 해시값]..[commit의 7자리 해시값] 선택한 커밋 하나만 되돌리고 다른 커밋 내용은 그대로 둠, 수정한 기록도 남김 협업하는데 커밋 로그를 함부로 지우면 서로 버전이 이상해질 수 있으니 revert로 수정 기록 남기자! 다만, revert 쓰는 것 보다도 가장 좋은건 수정해서 그냥 커밋을 하는 것이 아닐까? 브랜치 바꿔야하는데 커밋은 하기 싫을 때 현재 무언가 작업 중일 때 브랜치를 바꾸면, 작업 중인 내용이 바뀐 브랜치로 따라옴 git stash 현재 작업하고 있는 작업물을 따로 추적하지 않는 저장파일에 저장하기 Reference 티아카데미 Git & GitHub page 블로그 만들기 초보용 git 되돌리기

General · 2021-05-01

Git의 발전 과정

Git의 발전 과정 Git 탄생 배경 Git은 분산형 버전 관리 시스템 (DVCS, Distributed Version Control System) 처음엔 리눅스 오픈 커뮤니티에서 BitKeeper(회사)의 DVCS를 사용했으나, 이익을 추구하는 기업과 오픈 커뮤니티와의 상충이 발생 리눅스 창시자 Linus Tovalds를 중심으로 2005년 리눅스 오픈 커뮤니티에서 자체 툴로서 제작 버전 관리 시스템 (VCS, Version Control System) 파일의 변경 사항을 저장하고, 원하는 시점의 버전을 다시 꺼내올 수 있는 시스템 CVCS(중앙집중식 VCS) VS DVCS(분산형 VCS) 중앙집중식 버전 관리 시스템 (CVCS, Central Version Control System) 하나의 중앙 서버를 두고, 해당 서버에서 버전을 관리 최신 버전으로 업그레이드하기 위해, 최상단의 버전을 다운받고 수정해 업데이트하는 방식 메인 서버에 접속하지 않으면 로컬에서 개발 불가 메인 서버가 폭파되면 큰일남 효율적이지만, 여전히 협업의 불편함이 있음 분산형 버전 관리 시스템 (DVCS, Distributed Version Control System) 메인 서버와 개발자들의 컴퓨터 각각에 모든 코드와 파일 변경 정보들이 분산되어 버전을 관리 메인 서버에 파일들이 어떻게 수정되었고, 누가 변경했는지 등의 정보가 저장됨 로컬에서 버전 관리하고 메인 서버에 올릴 수 있음 메인 서버가 폭파되어도 버전들 생존 가능 보다 효율적인 협업 가능 Subversion (SVN) - CVCS CVCS의 대표적인 시스템 중 하나 파일의 모든 변경 사항을 저장 초기에 File A, B, C를 각각 만든다면, 각각의 파일마다 변경 사항 델타를 따로 저장 특정 버전을 다운 받을 때, 초깃값에서 해당 버전까지의 델타들을 합한 값인 파일을 다운받아 관리 Git - DVCS 특정 버전에 해당하는 모든 정보와 파일들을 스냅샷으로 찍어 관리 버전이 수정된 파일은 수정본을 올리고, 수정되지 않은 파일은 해당 파일이 존재하는 버전으로 연결되는 링크를 저장 최신 버전의 스냅샷만 유지하고 이전 버전은 델타로 관리 Reference 티아카데미 Git & GitHub page 블로그 만들기

General · 2021-04-28

Django 간단한 블로그 만들기

1. 가상환경 설정하기 (Window) 가상환경이란 자신이 원하는 환경을 구축하기 위해 필요한 모듈만 담아 놓는 바구니를 말한다. 프로젝트 기초 전부를 분리해 사용할 수 있기 때문에 유용하다. Virtualenv를 통한 설정 가상환경 생성하기 먼저, 명령 프롬프트에서 가상환경을 생성할 폴더를 만들고 해당 폴더로 이동한다. 홈 디렉토리(C:\Users\Name)에 생성하면 적당한 선택이다. mkdir djangogirls cd djangogirls 그리고 가상 환경을 생성한다. 가상환경을 이름을 설정할 수 있는데 여기서는 myvenv로 생성하기로 한다. python -m venv myvenv 가상환경 사용하기 myvenv\Scripts\activate 만일 실행이 안될 경우, cmd를 관리자 권한으로 실행한다. 2. 장고 설치하기 pip을 최신 버전으로 업데이트하기 python3 -m pip install --upgrade pip 장고 설치하기 pip install django~=2.0.0 3. 장고 프로젝트 시작하기 생성할 장고 프로젝트의 구조 djangogirls ├───manage.py └───mysite settings.py urls.py wsgi.py __init__.py manage.py: 사이트 관리를 도와주는 파일 settings.py: 웹사이트 설정이 있는 파일 urls.py: urlresolver가 사용하는 패턴 목록을 포함하는 파일 장고 프로젝트 시작하기 명령 (mysite는 프로젝트 이름이므로 변경가능) 현재 디렉토리에서 장고 프로젝트 생성 (myvenv) C:\Users\Name\djangogirls> django-admin.py startproject mysite . settings.py 설정 변경 정확한 현재 시간 설정 (선택) TIME_ZONE = 'Asia/Seoul' 정적파일 경로 추가 파일 끝에 STATIC_URL 바로 밑에 STATIC_ROOT 추가 STATIC_URL = '/static/' STATIC_ROOT = os.path.join(BASE_DIR, 'static') 호스트 이름 일치시키기 DEBUG가 True이고 ALLOWED_HOSTS가 비어 있으면, 호스트는 [‘localhost’, ‘127.0.0.1’, ‘[::1]’] 에 유효 PythonAnywhere에 앱을 배포한다면 다음과 같이 수정 ALLOWED_HOSTS = ['127.0.0.1', '.pythonanywhere.com'] 데이터베이스 설정하기 settings.py 파일 안에 sqlite 데이터베이스가 기본적으로 설치되어 있음 (기본 장고 데이터베이스 어댑터) DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), } } 데이터 베이스 생성 명령 (myvenv) ~/djangogirls$ python manage.py migrate 웹 서버 시작하기 (myvenv) ~/djangogirls$ python manage.py runserver 4. 장고 앱 만들기 장고 앱 만들기 프로젝트 내부에 장고 애플리케이션 생성 (blog는 앱 이름이므로 변경 가능) (myvenv) ~/djangogirls$ python manage.py startapp blog settings.py 속 INSTALLED_APPS에 새로 생성한 앱 등록 (앱 이름을 끝에 추가) INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'blog', ] 앱 생성 후 프로젝트 구조 djangogirls ├── mysite | __init__.py | settings.py | urls.py | wsgi.py ├── manage.py └── blog ├── migrations | __init__.py ├── __init__.py ├── admin.py ├── models.py ├── tests.py └── views.py 5. 모델 만들기 블로그 글 모델 객체 만들기 blog/models.py에 Model 객체를 선언해 모델 생성 (파일 내 내용 전부 삭제 후 아래 코드 추가) from django.conf import settings from django.db import models from django.utils import timezone class Post(models.Model): author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE) title = models.CharField(max_length=200) text = models.TextField() created_date = models.DateTimeField( default=timezone.now) published_date = models.DateTimeField( blank=True, null=True) def publish(self): self.published_date = timezone.now() self.save() def __str__(self): return self.title 데이터베이스에 모델 추가하기 모델에 생긴 변화를 알리기 위해 migration 파일 생성 python manage.py makemigrations blog 데이터베이스에 반영하기 python manage.py migrate blog 6. 장고 관리자 관리자 페이지 언어 변경 (선택) setting.py의 LANGUAGE_CODE = ‘ko’로 바꿀 것 blog/admin.py 파일 내용 수정 생성한 모델 import 및 모델 등록 ```python from django.contrib import admin from .models import Post admin.site.register(Post) ``` 관리자 계정 생성 서버를 실행하는 중에 관리자 계정을 생성해야만 한다. 코드 실행 후 유저 네임, 이메일 주소 및 암호 입력 (myvenv) ~/djangogirls$ python manage.py createsuperuser Username: admin Email address: admin@admin.com Password: Password (again): Superuser created successfully. 7. 서버 배포하기 PythonAnywhere로 배포 .gitignore 파일 설정 (github에 코드 push 전) 특정 파일들을 .gitignore 파일에 등록하면, git이 해당 파일들의 변화는 무시하고 추적하지 않게끔 할 수 있다. 여기서 db.sqlite3는 로컬 데이터베이스이고 이는 테스트 공간으로만 사용하는 것이 좋으므로, github 저장소에 저장하지 않는다. 에디터를 사용해 아래와 같은 내용으로 .gitignore 파일을 프로젝트 폴더(djangogirls)에 만들자. *.pyc *~ __pycache__ myvenv db.sqlite3 /static .DS_Store PythonAnywhere 서버에 Github에서 코드 가져오기 PythonAnywhere 콘솔에 다음 코드 입력 (my-first-blog는 github 저장소 이름) git clone https://github.com/<your-github-username>/my-first-blog.git PythonAnywhere에서 가상환경 생성 및 활성화하기 $ cd my-first-blog $ virtualenv --python=python3.6 myvenv Running virtualenv with interpreter /usr/bin/python3.6 [...] Installing setuptools, pip...done. $ source myvenv/bin/activate (myvenv) $ pip install django~=2.0 Collecting django [...] Successfully installed django-2.0.6 PythonAnywhere에서 데이터베이스 초기화 및 관리자 계정 생성하기 (mvenv) $ python manage.py migrate Operations to perform: [...] Applying sessions.0001_initial... OK (mvenv) $ python manage.py createsuperuser web app으로 블로그 배포하기 PythonAnywhere 대시보드에서 Web을 클릭하고 Add a new web app을 선택 도메인 이름 확정 후, 수동설정(munual configuration)을 클릭하고 Python 3.6을 선택한 다음, 다음(Next)을 클릭 가상환경 설정하기 PythonAnywhere 설정 화면의 가상환경(Virtualenv) 섹션에서 가상환경 경로를 입력해주세요(Enter the path to a virtualenv)라고 쓰여 있는 빨간색 글자를 클릭하고 /home/<your-username>/my-first-blog/myvenv/ 라고 입력 이동 경로를 저장하려면, 파란색 박스에 체크 표시하고 클릭 WSGI 파일 설정하기 PythonAnywhere에게 웹 애플리케이션의 위치와 Django 설정 파일명을 알려주는 역할 “WSGI 설정 파일(WSGI configuration file)” 링크(페이지 상단에 있는 “코드(Code)” 섹션 내 /var/www/<your-username>_pythonanywhere_com_wsgi.py 부분)를 클릭 모든 내용을 삭제하고 아래 코드 추가 import os import sys path = '/home/<your-PythonAnywhere-username>/my-first-blog' # PythonAnywhere 계정으로 바꾸세요. if path not in sys.path: sys.path.append(path) os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings' from django.core.wsgi import get_wsgi_application from django.contrib.staticfiles.handlers import StaticFilesHandler application = StaticFilesHandler(get_wsgi_application()) 저장(Save)을 누르고 웹(Web) 탭 누르기 큰 녹색 다시 불러오기(Reload) 버튼을 누르면, 모든 배포 작업 완료 8. URL 설정 및 뷰(View) 만들기 장고는 URLconf (URL configuration)를 사용 URLconf는 장고에서 URL과 일치하는 뷰를 찾기 위한 패턴들의 집합이다. mysite/urls.py에서 url 설정 mysite/urls.py의 초기 코드 """mysite URL Configuration [...] """ from django.contrib import admin from django.urls import path urlpatterns = [ path('admin/', admin.site.urls), ] blog 앱에서 mysite/urls.py로 url들 가져오기 from django.contrib import admin from django.urls import path, include # include 추가 urlpatterns = [ path('admin/', admin.site.urls), path('', include('blog.urls')), # blog.urls를 가져오는 코드 추가 ] blog/urls.py 파일 생성 및 코드 추가 from django.urls import path from . import views urlpatterns = [ path('', views.post_list, name='post_list'), # post_list 뷰를 루트 url에 할당 ] 뷰 만들기 뷰는 애플리케이션의 로직을 넣는 곳으로, 모델에서 필요한 정보를 받아와 템플릿에 전달하는 역할을 한다. blog/views.py 안에 뷰 만들기 초기 코드 from django.shortcuts import render # Create your views here. 뷰 만들기 from django.shortcuts import render # Create your views here. def post_list(request): ''' 요청(request)을 넘겨받아 render메서드를 호출한다. 이 함수는 render 메서드를 호출하여 받은(return) blog/post_list.html 템플릿을 보여준다. ''' return render(request, 'blog/post_list.html', {}) 9. 템플릿 만들기 템플릿이란 서로 다른 정보를 일정한 형태로 표시하기 위해 재사용 가능한 파일을 말한다. (장고의 템플릿 양식은 HTML) blog/templates/blog 디렉토리를 만들고, 디렉토리 내부에 html 파일 생성 하위 디렉토리를 만드는 것은 폴더가 구조적으로 복잡해졌을 때 찾기 쉽게 하기 위한 관습적 방법이다! post_list.html 파일 생성 및 원하는 html 코드 추가 예시 ```html Django Girls blog Django Girls Blog published: 14.06.2014, 12:14 My first post Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum. Donec id elit non mi porta gravida at eget metus. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus. published: 14.06.2014, 12:14 My second post Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum. Donec id elit non mi porta gravida at eget metus. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut f. ``` 10. 모델로부터 템플릿에 동적으로 데이터 가져오기 뷰에서 모델 연결하기 blog/views.py 파일 수정 from django.shortcuts import render from django.utils import timezone # 쿼리셋 동작을 위해 추가 from .models import Post # Post 모델을 사용하기 위해 import def post_list(request): # 쿼리셋 추가 posts = Post.objects.filter(published_date__lte=timezone.now()).order_by('published_date') return render(request, 'blog/post_list.html', {'posts': posts}) # 'posts' 매개변수 추가 템플릿에서 템플릿 태그를 사용해 보여주기 blog/templates/blog/post_list.html 에서 템플릿 태그 사용 <div> <h1><a href="/">Django Girls Blog</a></h1> </div> # 장고 템플릿에서의 루프 테크닉 {% for post in posts %} <div> <p>published: {{ post.published_date }}</p> <h1><a href="">{{ post.title }}</a></h1> <p>{{ post.text|linebreaksbr }}</p> </div> {% endfor %} 11. 간략하게 CSS 다루기 부트스트랩 설치하기 인터넷에 있는 파일을 연결하므로써 진행 html 파일 내 <head>에 아래 링크 추가 <link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/bootstrap/3.2.0/css/bootstrap.min.css"> <link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/bootstrap/3.2.0/css/bootstrap-theme.min.css"> 정적 파일 (static files) css 파일과 이미지 파일이 해당 앱에 static 폴더를 추가하고 폴더 안에 정적 파일 저장 (장고는 static 폴더를 자동을 찾을 수 있음!) blog 앱 안에 static 폴더 생성 djangogirls ├── blog │ ├── migrations │ ├── static │ └── templates └── mysite static 폴더 내부에 css 폴더를 만들고, css 파일을 생성해 저장 blog/static/css/blog.css 파일 생성 djangogirls └─── blog └─── static └─── css └─── blog.css blog.css 파일에 다음과 같은 예시 코드 추가 ```css .page-header { background-color: #ff9400; margin-top: 0; padding: 20px 20px 20px 40px; } .page-header h1, .page-header h1 a, .page-header h1 a:visited, .page-header h1 a:active { color: #ffffff; font-size: 36pt; text-decoration: none; } .content { margin-left: 40px; } h1, h2, h3, h4 { font-family: ‘Lobster’, cursive; } .date { color: #828282; } .save { float: right; } .post-form textarea, .post-form input { width: 100%; } .top-menu, .top-menu:hover, .top-menu:visited { color: #ffffff; float: right; font-size: 26pt; margin-right: 20px; } .post { margin-bottom: 70px; } .post h1 a, .post h1 a:visited { color: #000000; } ``` html 파일에서 정적 파일 로딩 및 css 파일 링크 추가 class를 추가하고 정적 파일을 로딩하여 css파일과 링크한 html 파일 예시 ```django {% raw %} {% load static %} // 정적 파일 로딩 Django Girls blog // css 파일 링크 추가 Django Girls Blog {% for post in posts %} published: {{ post.published_date }} {{ post.title }} {{ post.text|linebreaksbr }} {% endfor %} {% endraw %} ``` 12. 장고 템플릿 확장하기 템플릿 확장은 웹사이트 안의 서로 다른 페이지에서 HTML의 일부를 동일하게 재사용 할 수 있게 하는 것을 말한다. 기본 템플릿 생성하기 blog/templates/blog/ 에 base.html 파일 생성 block 템플릿 태그를 적절히 삽입한 뼈대 html 코드 추가 post_list.html 파일의 전체 코드 중 <body> 태그 내용만 바꿔 다음과 같이 base.html에 코드 추가 ```django {% raw %} {% load static %} Django Girls blog Django Girls Blog {% block content %} {% endblock %} {% endraw %} ``` 기본 템플릿과 확장 템플릿 연결하기 확장할 html 파일에는 블록에 대한 템플릿의 일부만 남김 block 템플릿 태그 추가 확장 태그를 파일 맨 앞에 추가 blog/templates/blog/post_list.html을 다음 코드로 변경 {% raw %} {% extends 'blog/base.html' %} {% block content %} {% for post in posts %} <div class="post"> <div class="date"> {{ post.published_date }} </div> <h1><a href="">{{ post.title }}</a></h1> <p>{{ post.text|linebreaksbr }}</p> </div> {% endfor %} {% endblock %} {% endraw %} Reference 가상환경 장고걸스 튜토리얼

Python-Ecosystem · 2021-04-27

2-1. 컴퓨터 시스템 구조

Computer Science · 2021-04-25

1. 운영체제 개요

운영체제(Operating System, OS)란? 하드웨어 바로 위에 설치되어 사용자 및 소프트웨어를 하드웨어와 연결시켜주는 시스템 소프트웨어이다. 협의의 운영체제 : 보통 커널을 지칭한다. 커널은 운영체제의 핵심 부분으로 메모리에 상주한다. 전공자 입장에서 주로 이 의미로 많이 쓰인다. 광의의 운영체제 : 컴퓨터 부팅 시, 커널 및 커널과 함께 실행되는 주변 시스템 유틸리티를 모두 총칭하는 개념이다. 운영체제의 목적 1. 컴퓨터 시스템 자원의 효율적 관리 효율성 : 주어진 하드웨어 자원(CPU, 기억장치, 입출력장치 등)을 활용하여 최대한 성능을 내도록 한다. ex) 실행 중인 프로그램들에게 짧은 시간 간격으로 CPU를 번갈아 할당하거나 메모리 공간을 적절히 분배하는 것 형평성 : 특정 사용자가 차별받지 않도록 사용자 간의 형평성을 고려하여 자원을 분배한다. 소프트웨어 자원(프로세스, 파일, 메시지)을 관리하거나 사용자 및 운영체제 스스로를 보호하기도 한다. 2. 사용자에게 편리한 컴퓨터 시스템 이용 환경 제공 실제로는 하나의 컴퓨터를 이용하는 여러 사용자들이 마치 자신만의 독자적 컴퓨터에서 프로그램을 실행시키는 듯한 느낌을 받게 한다. 또한, 하드웨어를 직접 다루는 복잡한 역할을 대신해준다. 운영체제의 분류 1. 동시 작업 가능 여부 단일 작업(single tasking) : 한 번에 하나의 작업만 처리한다. ex) MS-DOS 다중 작업(multi tasking) : 동시에 두 개 이상의 작업을 처리한다. ex) UNIX, MS Windows 2. 사용자 수 단일 사용자 ex) MS-DOS, MS Windows 다중 사용자 ex) UNIX, NT server 3. 처리 방식 시분할(time sharing) 여러 작업을 수행할 때, 컴퓨터 처리 능력을 일정한 시간 단위로 분할하여 사용하는 방식이다. 우리가 주로 사용하는 현대적 범용 컴퓨터는 대부분 이 방식을 사용한다. 일괄 처리 방식에 비해 짧은 응답시간을 가지지만 사용자의 수에 따라 처리시간이 달라진다. (0.01초의 처리시간이 사람이 많아질수록 0.1초, 1초와 같이 느려진다.) 이로 인해, Interactive한 속성(컴퓨터에 무언가를 입력하면 바로 화면에 결과가 나오는 방식)을 느낄 수 있으며, 실시간 방식과 달리 처리 시간의 제약이 따로 존재하진 않는다. 실시간(Realtime OS) 정해진 Deadline에 어떠한 작업이 무조건 마무리되어야 하는 실시간 시스템을 위해 만들어진 OS이다. 따라서, 한 치의 오차도 발생해서는 안 되는 공장 제어, 미사일 제어, 반도체 공정 등 특수 목적 시스템에 많이 사용된다. · Hard realtime system(경성 실시간 시스템) : 시간을 어기면 큰 문제가 생기는 시스템 ex) 공정 파이프라인 · Soft realtime system(연성 실시간 시스템) : 약간의 시간 어김이 허용되는 시스템 ex) 영화 스트리밍 영화 스트리밍, 웹서핑 등에 사용하는 보통의 범용 컴퓨터는 시분할 방식의 OS를 사용하지만 내비게이션 앱이나 블랙박스 영상 촬영 등은 잠깐의 시간 어김도 허용되서는 안 된다. 따라서, 범용 컴퓨터의 OS가 Realtime을 요구하는 Application들을 어떻게 지원해줘야 할 지에 대한 연구도 진행되고 있다. 일괄처리(batch processing) 과거의 컴퓨터 처리 방식 중 하나로 현대에는 익숙지 않은 방식이다. 작업 요청을 일정량 모아서 한꺼번에 처리하는 방식으로 interactive하지 않다. 다음 작업을 위해서는 작업이 완전히 종료될 때까지 기다려야 하는 불편함이 있다. 요즈음의 범용 컴퓨터 OS는 다중 작업, 다중 사용자, 시분할 처리 방식의 속성을 가진다. 다중 작업 관련 용어 정리 아래의 모든 용어는 ‘컴퓨터에서 여러 작업이 동시에 수행되는 것’을 의미한다. Multitasking Multiprogramming : 여러 프로그램이 메모리에 올라가 있음을 강조한다. Time sharing : CPU의 시간을 분할하여 사용하는 것을 강조한다. Multiprocess : process는 실행 중인 프로그램을 뜻하여, 여러 개의 실행 중인 프로그램을 말한다. Multiprocessor : 하나의 컴퓨터에 여러 CPU(processor)가 붙어 있음을 뜻한다. (하드웨어적으로 강조) 운영체제의 예 1. 유닉스(UNIX) 초기의 대형 컴퓨터(서버)를 위해 만들어진 운영체제로, multitasking과 다중 사용자가 가능하다. 복잡한 어셈블리어로 유닉스를 만든 것에 한계가 있어, 보다 high level에 해당하는 C언어가 탄생했다. 코드의 대부분이 C언어로 작성된 유닉스는 덕분에 기계어 집합이 전혀 다른 컴퓨터에도 이식하는 것이 쉬워져 높은 이식성을 보였다. (C언어 코드를 단순히 컴파일하면 되었다.) 유닉스는 최소한의 핵심적인 커널 구조만 가지며 메모리를 아꼈고, 복잡한 시스템에 맞게 확장이 용이했다. 또한, ‘공개 Software 정신’의 개념 하에 소스 코드를 공개하며 수많은 유닉스 기반의 OS들을 배출했다. System Ⅴ, FreeBSD(버클리 대학교 제작), SunOS, Solaris, Linux 등의 다양한 버전이 그 예이다. 특히, Linux는 개인용 컴퓨터를 비롯해 여러 환경에서 사용 가능한 특징을 보인다. 2. Microsoft 운영체제 단일 작업, 단일 사용자를 상정하며 시작되었다. DOS(Disk Operating System) : 단일 사용자용 운영체제이며, 640KB의 적은 메모리는 한계점이다. 이러한 한계가 있는 DOS에 새로운 기능이 계속 추가되며 DOS의 코드는 복잡해지고 누더기(?)가 되었다. 그 이후, DOS 위에서 Windows를 실행시키는 것이 가능해지고 점차 Windows가 독자적인 OS로 독립하였다. MS Windows : 제작된 다중 작업이 가능한 GUI 기반 운영체제이다. 하드웨어를 연결하면 별도의 사용자 조작이나 프로그램 설치 없이 바로 사용 가능한 Plug and Play 지원(그 당시엔 혁신적이었다.), DOS용 응용 프로그램과의 호환성, 풍부한 지원 소프트웨어 등의 특징이 있다. 3. 이외에도 애플 OS(Macintosh OS→Mac OS), 소형 디바이스(Handleheld device)를 위한 OS(PalmOS, Pocket PC(WinCE), Tiny OS) 등이 존재했고, 점차 iOS 같은 스마트 디바이스(Smart device)를 위한 OS 등 여러 형태의 운영체제로 발전하였다. 운영체제의 Issue 운영체제의 구조 CPU 스케줄링 : 빠른 처리 속도를 가진 CPU지만, 작업들을 어떤 순서로 할당하는 게 가장 효율적일지 고민한다. 메모리 관리 : 한정된 메모리를 어떤 작업들에 많게 혹은 적게 배분하고 제외시킬지에 관한 주제이다. 파일 관리 : 디스크에 파일을 어떻게 보관할지에 관한 주제이다. 디스크 헤드의 효율적인 움직임을 고민한다. 입출력 관리 : 다양한 입출력 장치와 컴퓨터 간의 정보 교환을 어떻게 할지 고민한다. 입출력 장치의 느린 처리속도를 극복하기 위해 빠른 처리 속도를 가진 CPU를 순간적으로 멈추는 Interrupt도 이 주제에서 다룬다. 프로세스 관리 : 컴퓨터 소프트웨어(프로그램)들을 어떻게 관리할지에 대한 주제이다. 보호 시스템, 네트워킹, 명령어해석기(Command Line Interpreter) 등의 주제도 존재한다. 내 스스로가 운영체제가 되었다고 생각하며 공부해보자 :) Reference 운영체제, 이화여대 반효경 교수님

Computer Science · 2021-04-24

Git과 Github의 차이

Git 버전 관리를 위한 ‘소프트웨어’ 분산형 버전 관리 시스템 (DVCS, Distributed Version Control System) like 영상을 찍는 앱 Github Git으로 저장되어 원격 전송된 내역들이 저장되는 공간을 제공하는 ‘서비스’ like 유튜브 Git과 Github의 관계 여러 개의 컴퓨터와 하나의 메인 서버가 소통하는 방식이 Git(컴퓨터들)과 Github(서버)의 관계 즉, 메인 서버(Github)와 개발자들의 컴퓨터들(Git) 각각에 코드가 분산되어 있음 Reference Git은 뭐고 Github은 뭔가요? Git과 Github 소개

General · 2021-04-23

프로그래머스 월간 코드 챌린지 시즌 2

종종 프로그래머스 문제를 풀다가 월간 코드 챌린지 시즌 1에 출제된 문제를 마주치곤 했다. 그 때는 어떤 대회인지 살짝 궁금하면서도 슥 지나쳤는데, 이번에 월간 코드 챌린지 시즌 2를 진행한다고 하여 흥미 반, 코딩테스트 감 유지 반으로 참여해 봤다. 이번 월간 코드 챌린지 시즌 2는 4월, 5월 두 번에 걸쳐 진행한다고 하며, 코딩을 좋아하는 20세 이상이면 누구나 참여가 가능하니 가벼운 마음으로 즐길 수 있는 좋은 대회라고 생각한다. 마지막 문제 풀이 끝나고 대쉬보드를 찍었는데, 그리 유의미한 등수는 아니었다 :) 중간에 개인적인 스케줄도 있었던 터라 온전히 집중하지 못하긴 했다. 첫 번째, 두 번째 문제는 금방 풀었는데, 세 번째 문제를 너무 복잡하게 접근했는지 원하는 대로 알고리즘이 동작하지 않아 테스트 케이스의 일부만 해결됐다. 문제 해결 전략은 확실히 보였는데, 개인적으로 트리의 루트노드와 리프노드를 설정하는 방법에 미숙함을 느껴 아쉬웠다. 그래도 즐겁게 대회를 즐겼다! 5월 챌린지도 기대된다 :)

Blog · 2021-04-16

백준 골드 티어 도착 기록

아름아름 1일 1문제 알고리즘 문제 풀이를 계속 하다보니 solved.ac에서 골드 티어에 도착해 있었다. (물론 못 푼날도 당연 존재한다…ㅋㅋㅋ) 알고리즘 괴수분들은 정말 많으시니까. 대단한 기록일리는 만무하지만, 그래도 예전 알고리즘 문제 유형도 몰랐던 갓난아기 시기에 비하면 정말 장족의 발전을 했다고 느낀다. 꾸역꾸역 어떻게든 잘해왔구나. 경험치 기록을 보니 본격적으로 백준을 풀기 시작한 12월 말즈음부터 대략 3개월 정도 걸렸나보다. 그동안 유형별 문제 풀이에 집중해서 그리디부터 DFS/BFS, DP, 최단경로 등 다양한 문제 유형에 대해 한 번 이상씩은 문제 풀이를 진행했다. 하지만 중간중간 기초가 될 수 있는 작은 유형들을 놓친 부분도 있어서, 이에 대해서 보강을 해야할 것 같다. 또한, 다른 유형 문제에 집중하다보면 이전에 공부했던 유형의 코드들은 가물가물해짐을 느낀다. 이제 슬슬 앞 부분에 대한 기억을 상기시키면서, 유형을 모른 상태로 문제 푸는 연습도 많이 해야겠다. 보통 백준기준으로 실버 3 ~ 골드 1까지의 문제를 막힘없이 풀 수 있는 정도가 되면, 기업 코테를 충분히 합격할 수 있다고 한다. 아직 멀었지만 예전보다는 저 멀리에 있던 것이 드디어 살짝 눈에 보이는 느낌이 들어 참 감사하다. 코테에 대한 글들을 살펴보면 아직 내가 미처 신경쓰지 못한 부분들도 참 많은 것 같은데, 잘 보완해서 궤도에 오르면 좋겠다.

Blog · 2021-03-23

투 포인터 (Two Pointers)

Computer Science · 2021-03-08

소수 판별 알고리즘 - 에라토스테네스의 체

소수 (Prime Number) 판별 알고리즘 소수란 1보다 큰 자연수 중 1과 자기자신을 제외한 자연수로는 나누어떨어지지 않는 자연수를 말한다. 코딩 테스트에서는 어떠한 자연수가 소수인지 아닌지 판별해야 하는 문제가 자주 출제되므로 알고리즘을 기억해두면 좋다. 다음은 기본적인 소수 판별 알고리즘을 파이썬으로 구현한 것이다. # 소수 판별 함수 정의 (2이상의 자연수에 대하여) def is_prime_number(x): # 2부터 (x - 1)까지의 모든 수를 확인하며 for i in range(2, x): # x가 해당 수로 나누어떨어진다면 if x % i == 0: return False # 소수가 아님 return True # 소수임 print(is_prime_number(4)) print(is_prime_number(7)) 기본적인 소수 판별 알고리즘의 시간 복잡도는 O(N)이다. 2부터 N - 1까지의 모든 자연수에 대하여 차례차례로 연산을 수행하기 때문이다. 다만, 자연수의 범위가 10억과 같이 커진다면 연산 수행에 문제가 생기므로 시간복잡도를 개선할 필요성이 있다. 개선된 소수 판별 알고리즘 약수의 성질에서 시간 복잡도 개선의 단서를 찾을 수 있다. 어떤 한 수에 대한 모든 약수는 가운데 약수를 기준으로 곱셈 연산에 대해 대칭을 이룬다. 예를 들어, 16의 약수 1, 2, 4, 8, 16에서 2 X 8 = 16이고 8 X 2 = 16이다. 즉, 특정한 수에 대한 모든 약수를 찾을 때 가운데 약수(제곱근)까지만 확인하면 충분하다. 다음 코드는 이를 활용하여 소수 판별 알고리즘을 개선한 형태이다. # 소수 판별 함수 (2이상의 자연수에 대하여) def is_prime_number(x): # 2부터 x의 제곱근까지의 모든 수를 확인하며 for i in range(2, int(x ** 0.5) + 1): # x가 해당 수로 나누어 떨어진다면 if x % i == 0: return False # 소수가 아님 return True # 소수임 print(is_prime_number(4)) print(is_prime_number(7)) 이 경우 특정 수의 제곱근까지만 확인하는 과정이므로, 시간 복잡도는 O(√N)이 된다.(루트 N) 에라토스테네스의 체 알고리즘 지금까지 특정 수에 대하여 소수를 판별하는 과정을 살펴보았다. 더 나아가 만일 특정한 수의 범위가 주어지고 그 범위안의 존재하는 모든 소수를 찾아야 한다면 어떻게 해야할까? 이 상황에서는 다수의 자연수에 대하여 소수 여부를 판별하는 대표적 알고리즘인 에라토스테네스의 체를 사용할 수 있다. 에라토스테네스의 체 알고리즘의 동작 과정은 다음과 같다. 2번 단계에서는 남은 수 중에서 아직 처리하지 않은 가장 작은 소수 i(남은 수가 결국 소수)를 찾고, 3번 단계에서 i를 제외한 그 i의 배수를 모두 제거하는 과정을 반복한다. 다음은 N=26인 상황일 때의 동작과정이다. 에라토스테네스의 체 역시 약수의 성질을 적용할 수 있다. 예를 들어, 위 경우는 26의 대략적인 제곱근인 5까지만 확인하면 된다. 6부터는 배수가 5를 넘어갈 수 없고, 이미 앞에서 소수 2, 3, 5의 배수를 제거했기 때문이다. 따라서, √N까지의 자연수만 확인해도 동일한 결과를 얻을 수 있다. 다음은 에라토스테네스의 체 알고리즘을 파이썬 코드로 구현한 것이다. n = 1000 # 2부터 1000까지의 모든 수에 대하여 소수 판별 # 처음엔 모든 수를 소수(True)인 것으로 초기화(0, 1은 제외) array = [True for i in range(n + 1)] # 에라토스테네스의 체 알고리즘 수행 # 2부터 n의 제곱근까지의 모든 수를 확인하며 for i in range(2, int(n ** 0.5) + 1): if array[i] == True: # i를 제외한 i의 모든 배수를 지우기 j = 2 while i * j <= n: array[i * j] = False j += 1 # 모든 소수 출력 for i in range(2, n + 1): if array[i]: print(i, end=' ') 이러한 에라토스테네스의 체 알고리즘의 시간 복잡도는 O(NloglogN) 으로 선형시간에 가까울 정도로 매우 빠르므로, 다수의 소수를 찾는 문제에서 효율적이다. 다만, 각 자연수에 대한 소수 여부를 저장해야 하기 때문에 메모리가 많이 필요하다는 단점이 있다. 예를 들어, N이 10억인 경우 문제 해결이 어렵다. 본 포스팅은 ‘안경잡이 개발자’ 나동빈 님의 저서 ‘이것이 코딩테스트다’와 그 유튜브 강의를 공부하고 정리한 내용을 담고 있습니다.

Computer Science · 2021-03-03

기타 그래프 이론 - 최소 신장 트리 (MST, Minimum Spanning Tree)

신장 트리(Spanning Tree)란? 신장 트리(Spanning Tree)란 원본 그래프의 모든 노드를 포함하면서 사이클이 존재하지 않는 부분 그래프를 뜻한다. 위의 가운데 그림처럼 간선들이 모든 노드를 잇고 있지만, 사이클은 생기지 않는 부분 그래프가 신장 트리의 예시가 된다. 반면, 오른쪽 그림처럼 모든 노드를 잇지도 않고 사이클마저 생기는 것은 신장 트리에 해당되지 않는다. 이 개념을 트리라고 부르는 이유는 모든 노드가 포함되어 서로 연결되면서 사이클이 존재하지 않는다는 조건이 트리의 조건에 해당하기 때문이다. 이러한 트리의 특성으로 인해, 신장 트리가 가지는 총 간선의 개수는 노드의 개수 - 1이 된다. 최소 신장 트리(MST, Minimum Spanning Tree) 최소 신장 트리(MST, Minimum Spanning Tree)란 최소한의 비용으로 구성되는 신장 트리를 의미한다. 최소 신장 트리의 개념은 여러 문제 상황에서 유용할 수 있는데, 만일 N개의 도시가 있고 두 도시 사이에 도로를 놓아 전체 도시가 서로 연결될 수 있게 하는 경우 최소 신장 트리가 사용된다. 위 그림을 예시로 보면, 3개의 도시가 있는 상황에서 모든 도시를 최소 비용으로 연결하는 방법은 오른쪽 그림과 같다. 크루스칼 알고리즘 (Kruskal Algorithm) 크루스칼 알고리즘(Kruskal Algorithm)은 대표적인 최소 신장 트리 알고리즘들 중 하나이다. 그리디 알고리즘으로 분류되며 동작 과정은 다음과 같다. 요약하자면, 모든 간선을 최소 비용 순으로 하나씩 확인하여 사이클을 생성하지 않는 간선들만 최소 신장 트리에 포함시키는 것이다. 구체적인 예시로 더 살펴보자. 위와 같이 원본 그래프가 주어졌을 때, 먼저 간선을 오름차순으로 정렬하고 작업을 수행한다. 위 그림의 테이블은 가독성을 위주로 간선 정보가 나열되어 있기 때문에 혼돈하지 않도록 하자. 처음으로 가장 최소인 비용을 가지는 3, 4번 노드를 잇는 간선을 확인한다. 두 노드는 다른 집합에 속해 있어 사이클 생성이 불가능하므로 Union 함수를 호출해 같은 집합으로 만들어 최소 신장 트리에 포함한다. 다음으로 다음 최소 비용에 해당하는 4, 7번 노드를 잇는 간선을 확인한다. 두 노드 역시 다른 집합에 속해 사이클을 생성하지 않으므로, Union 함수로 최소 신장 트리에 포함한다. 다음 최소 비용에 해당하는 4, 6번 노드를 잇는 간선도 두 노드가 다른 집합에 속해 있으므로 Union 함수를 호출해 최소 신장 트리에 포함시킨다. 다음 최소 비용에 해당하는 6, 7번 노드를 잇는 간선을 확인한다. 6번과 7번 노드의 경우 같은 집합에 속해 있기 때문에, 사이클을 발생시킨다. 따라서, 최소 신장 트리에 해당 간선을 포함시키지 않고 무시한다. 다음 최소 비용인 1번과 2번 노드를 잇는 간선을 확인한다. 두 노드는 다른 집합에 속하므로 Union 함수를 호출하여 같은 집합으로 합쳐 최소 신장 트리에 포함한다. 다음 최소 비용에 해당하는 2번 6번 노드를 연결하는 간선도 서로 다른 집합에 속하므로 최소 신장트리에 포함시킨다. 다음 최소 비용에 해당하는 2번 노드와 3번 노드를 연결하는 간선은 두 노드가 같은 집합에 속하므로 무시한다. 다음 최소 비용에 해당하는 5번과 6번 노드를 잇는 간선은 두 노드가 서로 다른 집합에 속하므로, Union 함수를 호출하여 최소 신장트리에 포함시킨다. 마지막으로 1번과 5번 노드를 잇는 간선은 두 노드가 서로 같은 집합에 속해 있으므로 무시하도록 한다. 연산을 모두 수행하면 최종적으로 위와 같은 최소 신장 트리가 나온다. 이 최소 신장 트리의 모든 간선의 비용을 합하면, 해당 값이 최종 비용이 된다. 위의 과정을 파이썬 코드로 구현하면 다음과 같다. # input # 7 9 # 1 2 29 # 1 5 75 # 2 3 35 # 2 6 34 # 3 4 7 # 4 6 23 # 4 7 13 # 5 6 53 # 6 7 25 # 특정 원소가 속한 집합을 찾기 (Find 연산) def find_parent(parent, x): # 루트 노드를 찾을 때까지 재귀 호출 if parent[x] != x: parent[x] = find_parent(parent, parent[x]) return parent[x] # 두 원소가 속한 집합을 합치기 (Union 연산) def union_parent(parent, a, b): a = find_parent(parent, a) b = find_parent(parent, b) if a < b: parent[b] = a else: parent[a] = b # 노드의 개수와 간선(Union 연산)의 개수 입력 받기 v, e = map(int, input().split()) parent = [0] * (v + 1) # 부모 테이블 초기화하기 # 모든 간선을 담을 리스트와 최종 비용을 담을 변수 edges = [] result = 0 # 부모 테이블에서, 부모를 자기 자신으로 초기화 for i in range(1, v + 1): parent[i] = i # 모든 간선에 대한 정보를 입력 받기 for _ in range(e): a, b, cost = map(int, input().split()) # 비용순으로 정렬하기 위해서 튜플의 첫 번째 원소를 비용으로 설정 edges.append((cost, a, b)) # 간선을 비용순으로 정렬 edges.sort() # 간선을 하나씩 확인하며 for edge in edges: cost, a, b = edge # 사이클이 발생하지 않는 경우에만 집합에 포함 if find_parent(parent, a) != find_parent(parent, b): union_parent(parent, a, b) result += cost print(result) 크루스칼 알고리즘의 시간 복잡도는 Elog(E)이다. 이와 같은 시간복잡도를 가지는 이유는 크루스칼 알고리즘에서 가장 시간이 오래 걸리는 부분이 정렬을 수행하는 작업이며, E개의 간선을 정렬하기 때문이다. 내부에서 이뤄지는 서로소 집합 알고리즘의 시간 복잡도는 정렬 알고리즘의 시간 복잡도보다 작기 때문에 무시한다. 본 포스팅은 ‘안경잡이 개발자’ 나동빈 님의 저서 ‘이것이 코딩테스트다’와 그 유튜브 강의를 공부하고 정리한 내용을 담고 있습니다.

Computer Science · 2021-02-20

기타 그래프 이론 - 서로소 집합 (Disjoint Sets)

서로소 집합 (Disjoint Sets) 서로소 집합이란 공통 원소가 없는 두 집합을 의미한다. 예를 들어, {1, 2}, {3, 4}는 서로소 관계이지만, {1, 2}, {2, 3}은 2라는 공통된 원소가 존재하므로 서로소 관계가 아니다. 서로소 집합 자료구조 (Union Find 자료구조) 서로소 집합 자료구조(Union Find 자료구조)는 서로소 부분 집합들로 나누어진 원소들의 데이터를 처리하기 위한 자료구조이다. 서로소 집합 자료구조에는 두 가지 연산이 존재하는데, 두 개의 원소가 포함된 집합을 하나의 집합으로 합치는 합집합(Union) 연산과 특정한 원소가 속한 집합이 어떤 집합인지 알려주는 찾기(Find) 연산이 그것이다. 서로소 집합 자료구조의 동작 과정 1. 기본 동작 과정 (합치기 연산이 여러 개 주어졌을 경우) 합치기 연산이 여러 개 주어졌을 경우, 위와 같은 동작 과정을 거쳐 작업을 수행한다. 이를 구체적으로 살펴보자. 위와 같이 4개의 Union 연산이 주어졌을 상황을 가정해보자. 먼저 노드 개수만큼의 크기를 가지는 부모 노드를 표현하는 테이블을 생성하고, 테이블 내 각 노드의 부모노드를 자기자신으로 초기화한다. 테이블 생성 및 초기화가 끝나면, 첫 번째로 Union(1, 4) 연산을 처리한다. 이를 처리하기 위해 Union 연산의 인자 값으로 주어진 노드 1과 노드 4의 루트 노드를 찾는다. 여기서는 각자 자기자신이 루트 노드에 해당하므로, 1과 4 중 더 큰 번호에 해당하는 노드 4의 부모노드를 1번 노드로 설정한다. 일반적으로, 큰 번호 노드를 작은 번호 노드의 자식 노드로 설정하는 것이 관행이 있어서 이 규칙을 따라 예시를 진행하겠다. Union(1, 4) 연산이 끝나면, Union(2, 3) 연산을 진행한다. 노드 2와 노드 3에 대하여 루트 노드를 찾는데, 이번에도 자기자신이 루트 노드이고 3이 더 큰 번호 노드이므로 3번 노드의 부모 노드를 2번 노드로 설정한다. 다음으로 Union(2, 4) 연산을 위와 같은 방식으로 또 진행한다. 2번 노드의 루트 노드는 자기 자신이고, 4번 노드의 루트 노드는 1번 노드이다. 2번 노드가 1번 노드보다 큰 번호이므로, 1번 노드를 2번 노드의 부모 노드로 설정한다. 마지막으로 Union(5, 6) 연산을 똑같은 방법으로 수행한다. 각각의 노드의 루트 노드는 자기자신이고 6번 노드가 더 큰 번호이므로, 5번 노드는 6번 노드의 부모 노드로 설정된다. 이와 같은 서로소 집합 자료구조는 각 집합들간의 연결성을 통해 총 몇 개의 집합이 존재하는지를 손쉽게 확인할 수 있다는 장점이 있다. 위의 1, 2, 3, 4번 노드들은 하나의 루트 노드를 가지며 트리 구조 형태를 띈다. 이런 경우 1, 2, 3, 4번 노드들은 원소가 4개인 하나의 집합으로 파악할 수 있다. 또한 5, 6번 노드도 원소가 2개인 또 다른 집합으로서 존재한다. 결론적으로, 위 그래프에서는 총 2개의 집합(1, 2, 3, 4번 노드 집합과 5, 6번 노드 집합)이 존재하고, 그 2개의 집합은 서로소 관계를 가진다. 다만, 기본적인 형태의 서로소 집합 자료구조에서는 루트 노드에 즉시 접근할 수 없다는 단점도 동시에 가지고 있다. 루트 노드를 찾기 위해서는 부모 테이블에서 해당 노드의 부모 노드를 계속 확인하며 거슬러 올라가야만 한다. 위의 과정을 파이썬 코드로 구현하면 다음과 같다. # input # 6 4 # 1 4 # 2 3 # 2 4 # 5 6 # 특정 원소가 속한 집합을 찾기 (Find 연산) def find_parent(parent, x): # 루트 노드를 찾을 때까지 재귀 호출 if parent[x] != x: return find_parent(parent, parent[x]) return x # 두 원소가 속한 집합을 합치기 (Union 연산) def union_parent(parent, a, b): a = find_parent(parent, a) b = find_parent(parent, b) if a < b: parent[b] = a else: parent[a] = b # 노드의 개수와 간선(Union 연산)의 개수 입력 받기 v, e = map(int, input().split()) parent = [0] * (v + 1) # 부모 테이블 초기화하기 # 부모 테이블에서, 부모를 자기 자신으로 초기화 for i in range(1, v + 1): parent[i] = i # Union 연산을 각각 수행 for i in range(e): a, b = map(int, input().split()) union_parent(parent, a, b) # 각 원소가 속한 집합 출력하기 print('각 원소가 속한 집합: ', end='') for i in range(1, v + 1): print(find_parent(parent, i), end=' ') print() # 부모 테이블 내용 출력하기 print('부모 테이블: ', end='') for i in range(1, v + 1): print(parent[i], end=' ') 2. 기본 구현 방법의 개선 위의 기본적인 Union Find 구현 방법은 수행 시간 면에서 문제점이 있다. 합집합(Union) 연산이 편향되게 이루어지는 경우 찾기(Find) 함수가 비효율적으로 동작한다는 점이다. 위는 최악의 경우를 가정한 예시다. 위와 같이 Union 연산이 편향적으로 수행되면, 5번 노드에 대해서 찾기(Find) 함수를 수행할 시 모든 노드를 다 확인하여 1번 노드를 루트 노드로 반환하는 비효율적인 동작을 보인다. 이 때, 시간 복잡도는 O(V)다. 따라서 Find 함수를 개선하기 위해 경로 압축(Path Compression) 기법을 사용한다. 다음은 경로 압축 기법을 구현한 파이썬 코드인데, 이는 기본적인 Find 함수에 약간의 변형만으로 구현된다. # 특정 원소가 속한 집합을 찾기 def find_parent(parent, x): # 루트 노드가 아니라면, 루트 노드를 찾을 때까지 재귀적으로 호출 if parent[x] != x: parent[x] = find_parent(parent, parent[x]) return parent[x] 경로 압축 기법을 적용하면, 각 노드에 대하여 Find 함수를 호출한 이후에 해당 노드의 루트 노드가 바로 부모 노드가 된다. 위의 파이썬 코드를 사용하면 같은 예시에 대하여 위 그래프와 같이 모드 노드들이 자신의 루트 노드를 부모 노드로 가지는 결과를 보여준다. 시간 복잡도도 개선되는 모습을 보인다. 서로소 집합을 활용한 사이클 판별 서로소 집합은 무방향 그래프에서 사이클을 판별할 때 사용 가능하다. (방향이 있는 그래프에서는 DFS를 사용한다.) 서로소 집합을 사용한 사이클 판별 알고리즘의 과정은 다음과 같다. 이를 더 구체적으로 살펴보자. 처음에는 기존 서로소 집합 자료구조 구현과 같은 초기화 과정을 거친다. 각 노드에 대하여 부모 노드를 자기자신으로 설정한다. 그 다음, 1번 노드와 2번 노드를 연결하는 간선을 확인하여, 어떤 노드가 부모노드가 될 지 판단한다. 1번과 2번 노드의 부모 노드는 각자 자기자신이므로, 더 큰 번호에 해당하는 2번 노드의 부모 노드를 1번 노드로 설정한다. 다음은 1번 노드와 3번 노드를 잇는 간선을 확인한다. 1번 노드와 3번 노드도 각각의 부모 노드가 자기 자신이므로, 더 큰 번호에 해당하는 3번 노드의 부모 노드를 1번 노드로 설정한다. 끝으로 2번 노드와 3번 노드 사이의 간선을 확인한다. 2번 노드와 3번 노드 각각의 루트 노드는 1번 노드이므로, 이미 같은 집합에 속해 있음을 알고 사이클이 발생함을 파악할 수 있다. 서로소 집합을 사용한 사이클 판별 알고리즘의 파이썬 구현은 다음 코드와 같다. # input # 3 3 # 1 2 # 1 3 # 2 3 # 특정 원소가 속한 집합을 찾기 (Find 연산) def find_parent(parent, x): # 루트 노드를 찾을 때까지 재귀 호출 if parent[x] != x: parent[x] = find_parent(parent, parent[x]) return parent[x] # 두 원소가 속한 집합을 합치기 (Union 연산) def union_parent(parent, a, b): a = find_parent(parent, a) b = find_parent(parent, b) if a < b: parent[b] = a else: parent[a] = b # 노드의 개수와 간선(Union 연산)의 개수 입력 받기 v, e = map(int, input().split()) parent = [0] * (v + 1) # 부모 테이블 초기화하기 # 부모 테이블에서, 부모를 자기 자신으로 초기화 for i in range(1, v + 1): parent[i] = i cycle = False # 사이클 발생 여부 for i in range(e): a, b = map(int, input().split()) # 사이클이 발생한 경우 종료 if find_parent(parent, a) == find_parent(parent, b): cycle = True break # 사이클이 발생하지 않았다면 합집합(Union) 연산 수행 else: union_parent(parent, a, b) if cycle: print("사이클이 발생했습니다.") else: print("사이클이 발생하지 않았습니다.") 본 포스팅은 ‘안경잡이 개발자’ 나동빈 님의 저서 ‘이것이 코딩테스트다’와 그 유튜브 강의를 공부하고 정리한 내용을 담고 있습니다.

Computer Science · 2021-02-14

최단 경로 (Shortest Path) - 벨만 포드 (Bellman-Ford)

Computer Science · 2021-02-11

최단 경로 (Shortest Path) - 플로이드 워셜 (Floyd-Warshall)

Computer Science · 2021-01-04

최단 경로 (Shortest Path) - 다익스트라 (Dijkstra Algorithm)

Computer Science · 2020-12-19

모두를 위한 딥러닝 Part 2

General · 2020-12-02

다이나믹 프로그래밍 (Dynamic Programming)

Computer Science · 2020-11-27

모두를 위한 딥러닝 Part 1

Machine Learning 개요 # 머신러닝이란? Explicit(=many rules)한 프로그래밍을 지양하고, 프로그램에게 데이터를 보고 스스로 학습할 능력을 부여해서 어떠한 결과를 도출하게끔 하는 연구하는 분야 → Field of study that gives computers the ability to learn without being explicitly programmed (Arthur Samuel, 1959) # 학습 방법에 따른 유형 1. Supervised learning : 컴퓨터에게 정답(label)이 무엇인지 알려주면서 학습시키는 방법 (label이 있는 data로 학습) Regression 어떠한 연속된 값을 주어진 데이터들의 특징(feature)을 기준으로 예측하는 문제 ex) 시험공부에 투자한 시간에 대한 기말시험 ‘점수’ 예측 Binary Classification 주어진 데이터를 2개의 카테고리로 분류하는 문제 ex) 개와 고양이 구분 Multi-Class(=Multi-Lable) Classification : 주어진 데이터를 3개 이상의 카테고리로 분류하는 문제 ex) 시험공부에 투자한 시간에 대한 기말시험 ‘등급’ 예측 2. Unsupervised learning : 정답(label)을 알려주지 않고 비슷한 데이터를 군집화하여 미래를 예측하는 학습 방법 (label이 없는 data로 학습) ex) Google news grouping, Word clustering Clustering Dimensionality Reduction etc… Linear Regression # Linear Regression 주어진 학습 데이터를 가장 잘 설명할 수 있는 선을 찾아 분석하는 방법이다. (Regression은 연속하는 값을 가지는 학습 데이터에 한해 사용한다.) 위 그림처럼 주어진 데이터를 그래프에 표현하고 여러가지 선을 긋다보면 파란선이 해당 데이터를 가장 잘 표현함을 알 수 있다. 이러한 선을 H(x) = Wx + b의 형태의 수식으로 찾아내는 것을 Linear Regression이라고 한다. 위 그림의 파란선은 H(x) = x로 나타낼 수 있다. # Loss & Cost function Cost function은 예상한 가설(선)이 데이터에 얼마나 잘 맞는지 확인하는 함수이다. 보통 예측값에서 실제값을 뺀 값의 제곱인 (H(x) - y)²을 Loss로 사용하여 Cost function을 구한다. 즉 이렇게 계산한 모든 Loss의 평균을 내면 Cost function을 구할 수 있다. 딥러닝에서는 주로 이 Cost function이 사용되고 이러한 Cost function을 최소화시키는 W, b를 찾는 것이 목표가 된다. Multi-variable linear regression # Mulit-variable linear regression 앞에서 공부했던 선형 회귀는 하나의 변수에 대하여 출력을 계산했다. 그러나 위 시험 점수 예측 사례의 퀴즈 1 점수, 퀴즈 2 점수, 중간고사 점수처럼 여러개의 변수를 고려하여 회귀를 진행할 땐 어떻게 해야할까? 기존의 선형 회귀 식은 H(x) = Wx + b였다. 다변량 선형 회귀는 위와 같이 기존 선형 회귀와 유사하게 새로운 가중치 w를 각각의 새로운 변수 x들에 곱해주면 된다. 다변량 선형 회귀의 비용함수 역시 선형 회귀의 비용함수 식을 그대로 가져오되 Hypothesis만 다변량 회귀식으로 적용하여 사용한다. Hypothesis를 n개의 변수에 대하여 일반화하면 위와 같다. 그러나 n의 값이 커질수록 식이 길어서 이를 표현하기 어려워지는 문제가 생긴다. 식이 길어지는 문제는 행렬(Matrix)을 도입하는 방법(= Vectorization)으로 해결할 수 있다. 변수 x들에 대한 행렬 X와 각각의 변수에 대한 가중치 w들을 표현하는 행렬 W를 사용해 H(X) = XW라는 Hypothesis를 사용할 수 있다. 일반적으로 이론에 사용되는 식에서는 H(x) = Wx 처럼 W를 앞에 사용하지만, 실제로 구현할 때는 XW와 같이 X를 앞에 두고 사용한다. Vectorization은 n개의 변수에 대해 n번이나 수행되어야 하는 계산을 한번으로 줄여 효율적인 계산을 돕는 이점이 있다. 위는 기말 시험 점수를 예측하는 다변량 선형 회귀에 대한 예시이다. 왼쪽 상단의 표에는 3가지 시험 점수 변수와 기말 점수 변수에 대한 데이터가 5개 있다. 이러한 데이터 하나하나를 Instance라고 한다. 행렬로 다변량 선형 회귀를 수행할 때는 그 행과 열에 정보가 담겨 있는데, X의 행은 instance의 개수(data의 개수), 열은 독립변수의 개수를 나타낸다. W의 행은 독립변수의 개수를 나타내며 열은 출력 개수를 나타낸다. 그리고 두 행렬 X와 W를 계산한 결과를 담는 행렬은 행이 instance의 개수, 열이 출력의 개수를 나타낸다. Logistic Regression # 이진 분류 (Binary classification) 이진 분류(Binary Classification)는 어떤 문제에 대하여 두 가지 중 하나를 결정하는 문제이다. 메일이 스팸메일인지 아닌지, 페이스북 피드를 보여줄지 말지, 방금 진행한 신용카드 거래가 사기인지 아닌지 판단하는 것이 이진 분류의 예다. 일반적으로 결정해야할 두 가지 결과는 0, 1로 인코딩해 사용한다. # 로지스틱 회귀 (Logistic Regression) 1. 로지스틱 회귀와 시그모이드(Sigmoid) 함수 이진 분류를 가장 잘 해결할 수 있는 방법으로 로지스틱 회귀(Logistic Regression)가 있다. 기존의 선형 회귀는 시험에 통과할 사람을 정확히 예측하는게 어렵고, 입력값이 커질수록 출력값이 0~1 범위를 크게 벗어나 결과를 두 가지로 분류하기 어렵다. 이러한 출력값을 0~1 범위로 압축하는 함수를 이용해 출력값을 분류하는 것이 로지스틱 회귀이다. 로지스틱 회귀에서는 0~1 범위로 출력값을 압축하는 함수로 시그모이드(Sigmoid) 함수를 사용한다. 시그모이드 함수는 모든 출력값이 0~1 사이에서 나오는 특징이 있다. 이를 통해, 기존 가설인 선형 회귀에 시그모이드 함수를 덧입혀 이진 분류에 적합한 새로운 가설 H(x)를 만들 수 있다. 2. 로지스틱 회귀의 Cost 함수 기존 선형 회귀의 cost 함수는 기울기가 0이 되는 값이 하나여서 쉽게 최솟값을 찾을 수 있었지만, 로지스틱 회귀의 경우 비선형 함수인 sigmoid 함수로 인해 cost 함수가 훨씬 구불구불한 형태를 띄게 된다. 이로 인해, 기울기가 0이 되는 지점이 많아져 시작점에 따라 경사하강법으로 찾는 최솟값의 지점이 달라진다. 즉, cost 함수의 진짜 최솟값을 찾는 것이 어렵다. 이를 극복하기 위해, 로지스틱 회귀에서는 위와 같은 cost 함수를 사용한다. 가장 왼쪽에 있는 그래프는 y = 1일 때의 cost 함수, 그 옆에 있는 그래프는 y = 0일 때의 cost 함수이다. 시그모이드 함수로 인해 생기는 지수함수적 특성을 log 함수를 사용해 중화한 덕분에 전체적으로 포물선과 비슷한 형태를 띈다. 따라서, 최솟값 찾기가 용이하다. cost 함수 그래프를 살펴보자. y = 1일 때의 그래프에서 H(x)가 1에 가까울수록(예측값이 정답에 가까울수록) cost 함수가 작아지고 H(x)가 0에 가까울수록(예측값이 틀릴수록) cost 함수가 무한대로 커진다. 반대로 y = 0일 때의 그래프에서 H(x)가 1에 가까울수록(예측값이 틀릴수록) cost 함수가 무한대로 커지고 H(x)가 0에 가까울수록(예측값이 정답에 가까울수록) cost 함수가 작아진다. 로지스틱 회귀의 cost 함수가 비용함수의 역할을 정확히 수행함을 확인할 수 있다. 비용함수를 텐서플로우로 실제로 구현할 때는 C(H(x), y) = - ylog(H(x)) - (1 - y)log(1 - H(x)) 식을 사용한다. 위의 y = 1일 때와 y = 0일 때의 비용함수를 똑같이 표현한 같은 식이며 구현의 편의를 위해 사용한다. Multi-Class Classification - Softmax # 다중 클래스 분류 (Multi-Class Classification) 앞선 로지스틱 회귀에서는 두 가지 선택지만 결정했다. 만약 세 가지 이상의 클래스를 두고 결정해야 하는 상황이라면 다중 클래스 분류(Multi-Class Classification)를 한다. 위와 같이 시간과 출석 여부라는 두 가지 변수에 대하여 A, B, C 세 가지 성적을 매기는 상황을 가정해보자. 성적 분포의 그래프는 오른쪽 그래프와 같다. 성적이 표현된 그래프를 로지스틱 회귀를 사용한다고 생각하고 A에 대해, B에 대해, C에 대해 각각 이진 분류한다면 위와 같이 3가지 선을 그을 수 있다. A인지 아닌지, B인지 아닌지, C인지 아닌지를 구별하는 세 가지 선을 그은 것이다. 이 3가지 식을 행렬로 표현하면 왼쪽 그림과 같다. 그리고 계산의 편의를 위해 이 식들을 또 하나의 행렬로 통합하면 오른쪽 그림과 같아진다. 오른쪽 그림의 계산식의 3가지 출력이 각각 A, B, C에 대한 H(x) 값이 된다. A, B, C에 대한 각각의 예측값이 0~1 범위에 있게 하고 모두 합해 1이 나오게 한다면 편리한 계산을 할 수 있다. 이를 위해 위 그림과 같은 Softmax 함수를 사용한다. Softmax 함수를 사용하면 A, B, C에 대한 세 가지 예측값을 확률로서 사용할 수 있게 된다. Softmax로 도출된 각각의 확률은 One-Hot Encoding을 통해 1 혹은 0으로 분류되고 각각의 예측값이 결론적으로 가리키는 것이 A인지 B인지 C인지를 확인할 수 있게 된다. ※ Softmax의 Cost 함수 Learning rate, Overfitting and Regularization # Learning rate (학습률) Gradient Descent를 진행할 때, 각 step마다 어느 정도씩 진행할지 Learning rate(학습률)을 지정하여 설정할 수 있다. (위 그림에서 알파값이 학습률을 나타낸다.) 학습률을 너무 큰 값으로 설정하면 스텝마다 큰 폭으로 학습이 진행되어 왼쪽 그림처럼 w값이 발산해버리는 오버슈팅(Overshooting) 문제가 발생할 수 있다. 반대로 학습률을 너무 작은 값으로 설정하면 스텝마다 작은 폭으로 학습이 진행돼 오른쪽 그림처럼 학습이 더뎌지는 문제가 발생한다. 학습률 설정에 정답은 없지만 처음에 0.01의 학습률을 설정하고 양상에 따라 조절하는 것도 한 방법이 될 수 있다. # 데이터 전처리 (Preprocessing) 데이터들을 다루다보면 x data에 해당하는 각각의 변수들의 값의 범위가 서로 크게 차이날 수 있다. 이러한 경우 적절한 학습률을 설정해도 오버피팅이나 언더피팅이 발생할 수 있는데, x data를 적절하게 전처리(Preprocessing)해주면 다시 정상적으로 학습시킬 수 있다. 이러한 전처리는 보통 zero-centered를 통해 원래의 데이터를 0을 중심으로 분포하게 만들거나, Normalization을 통해 변수 값의 범위를 특정 범위에 속하게 만드는 방법들이 있다. 이러한 normalize의 대표적인 예 중 하나가 표준화(Standardization)이다. 기존의 data에서 그 평균을 빼고 표준편차로 나눠주면 data는 표준정규분포를 따르게 되어 특정 범위 내에 분포하게 된다. 고등학교에서 통계 과목을 배울 때, 자주 봤던 이 개념을 사용해 data를 표준화시키면 정상적인 학습 진행에 큰 도움을 준다. # 오버피팅 (Overfitting) 학습시킨 모델이 training data(학습 데이터)에서만 너무 잘 맞아서 test data나 실제 문제에서는 좋은 성능을 발휘하지 못하는 현상을 오버피팅(Overfitting)이라고 한다. 오른쪽 그림은 학습 데이터에서 +와 -를 완벽하게 가르지만 실제 문제를 다룰 때는 +와 -를 나누는 성능이 왼쪽 그림에 비해 더 떨어질 수 있다. 이 경우엔 오버피팅 문제가 없는 왼쪽 모델이 더 성능이 좋으므로 모델을 학습시킬 땐 항상 오버피팅에 대해 경계해야 한다. 오버피팅의 해결책으로는 1. training data를 더 많이 확보하는 것 2. feature의 개수를 줄이는 것(=x변수를 줄이는 것) 3. Regularization시키는 것 등이 있다. # Regularization Regularization이란 데이터를 가르는 모델의 구불구불한 선을 조금 더 평탄하게 만드는 것을 의미한다. 보통 가중치 w의 값이 커질수록 모델의 선이 구불구불해지고, w의 값이 작아질수록 모델의 선이 평탄하게 뻗게 된다. 가중치 w 값을 보다 작게 하여 모델의 선을 적당히 평탄하게 만드는 Regularization을 통해 오버피팅을 어느정도 줄일 수 있다. Regularization은 cost 함수에 위 식을 더해주는 것으로서 구현하고 이를 L2 Regularization이라고 부른다. 맨 왼쪽의 람다 변수는 regularization strength라고 불리는데, 이 값이 0에 가까울수록 Regularization의 영향을 적게 한다는 의미고 이 값이 커질수록 Regularization의 영향력을 크게 한다는 의미이다. 이를 통해 가중치 값을 낮추고 오버피팅을 어느정도 극복할 수 있다. 본 포스팅은 김성훈 교수님의 강의 ‘모두를 위한 딥러닝’을 학습하고 정리한 내용을 담고 있습니다.

General · 2020-11-18

이진 탐색

순차 탐색 일반적으로 자주 사용되는 탐색으로, 앞에서부터 데이터를 하나씩 차례대로 확인하며 리스트 안에 있는 특정 데이터를 찾는 방법이다. 보통 정렬되지 않은 리스트에서 데이터를 찾을 때 사용한다. 충분한 시간이 있다면 데이터가 아무리 많아도 항상 원하는 데이터를 찾을 수 있는 것이 장점이다. 시간 복잡도는 최악의 경우 O(N)을 보장한다. # 순차 탐색 함수 구현 def sequential_search(target, array): for i in range(len(array)): if array[i] == target: return i + 1 # 현재 위치 반환 (인덱스이므로 1을 더함) array = [4, 5, 1, 3, 2] target = 3 print(sequential_search(target, array)) 4 이진 탐색 이진 탐색은 탐색 범위를 절반씩 좁혀가며 데이터를 탐색하는 방법이다. 순차 탐색과는 다르게 배열 내부의 데이터가 정렬된 상태여야만 사용 가능하다. 이진 탐색에는 탐색하고자하는 범위의 시작점, 끝점 그리고 중간점을 위치를 나타내는 변수로서 사용한다. 찾으려는 데이터와 중간점 위치에 있는 데이터를 반복적으로 비교해서 원하는 데이터를 찾는 것이 이진 탐색 과정이다. 한 번 확인할 때마다 확인하는 원소의 개수가 대략 절반씩 줄어든다는 점에서 시간 복잡도가 O(logN)이다. 1. 재귀함수를 이용한 이진 탐색 n = 10 target = 7 array = [1, 3, 5, 7, 9, 11, 13, 15, 17, 19] def binary_search(array, target, start, end): if start > end: return None mid = (start + end) // 2 if array[mid] == target: return mid elif array[mid] > target: return binary_search(array, target, start, mid - 1) else: return binary_search(array, target, mid + 1, end) result = binary_search(array, target, 0, n - 1) if result == None: print("원소가 존재하지 않습니다.") else: print(result + 1) 4 2. 반복문을 이용한 이진 탐색 n = 10 target = 7 array = [1, 3, 5, 7, 9, 11, 13, 15, 17, 19] def binary_search(array, target, start, end): while start <= end: mid = (start + end) // 2 # 찾은 경우 중간점 인덱스 반환 if array[mid] == target: return mid # 중간점의 값보다 찾고자 하는 값이 작은 경우 왼쪽 확인 elif array[mid] > target: end = mid - 1 # 중간점의 값보다 찾고자 하는 값이 큰 경우 오른쪽 확인 else: start = mid + 1 return None result = binary_search(array, target, 0, n - 1) if result == None: print("원소가 존재하지 않습니다.") else: print(result + 1) 4 파이썬 이진 탐색 라이브러리 bisect - bisect_left(array, x): 정렬된 순서를 유지하면서 배열 array에 x를 삽입할 가장 왼쪽 인덱스를 반환 - bisect_right(array, x): 정렬된 순서를 유지하면서 배열 array에 x를 삽입할 가장 오른쪽 인덱스를 반환 from bisect import bisect_left, bisect_right a = [1, 2, 4, 4, 8] x = 4 print(bisect_left(a, x)) # 정렬된 순서를 유지하면서 배열 a에 x를 삽입할 가장 왼쪽 인덱스를 반환 print(bisect_right(a, x)) # 정렬된 순서를 유지하면서 배열 a에 x를 삽입할 가장 오른쪽 인덱스를 반환 2 4 - 값이 특정 범위에 속하는 데이터 개수 구하기 from bisect import bisect_left, bisect_right # 값이 [left_value, right_value]인 데이터의 개수를 반환하는 함수 def count_by_range(a, left_value, right_value): right_index = bisect_right(a, right_value) left_index = bisect_left(a, left_value) return right_index - left_index a = [1, 2, 3, 3, 3, 3, 4, 4, 8, 9] # 값이 4인 데이터 개수 출력 print(count_by_range(a, 4, 4)) # 값이 [-1, 3] 범위에 있는 데이터 개수 출력 print(count_by_range(a, -1, 3)) 2 6 본 포스팅은 ‘안경잡이 개발자’ 나동빈 님의 저서 ‘이것이 코딩테스트다’와 그 유튜브 강의를 공부하고 정리한 내용을 담고 있습니다.

Computer Science · 2020-11-18

정렬 알고리즘

정렬(Sorting)이란? 데이터를 특정한 기준에 따라서 순서대로 나열하는 것을 의미한다. 선택 정렬 (Selection Sort) 데이터가 무작위로 여러 개 있을 때, 가장 작은 데이터를 선택해 앞으로 보내는 과정을 반복하는 정렬이다. 가장 작은 데이터를 선택해 맨 앞에 있는 데이터와 바꾸고, 다음으로 작은 데이터를 골라 앞에서 두 번째 데이터와 바꾸는 과정을 끝까지 반복해 데이터를 정렬한다. 선택 정렬을 파이썬으로 구현하면 다음과 같다. # 배열의 원소를 오름차순으로 정렬 array = [7, 5, 9, 0, 3, 1, 6, 2, 4, 8] for i in range(len(array)): min_index = i # 가장 작은 원소의 인덱스 for j in range(i+1, len(array)): if array[min_index] > array[j]: min_index = j array[i], array[min_index] = array[min_index], array[i] print(array) 선택 정렬은 다른 더 빠른 정렬 알고리즘들에 비해 비효율적인 면이 있다. 선택 정렬의 시간 복잡도는 이중 for문을 수행한다는 점에서 직관적으로 O(N²)임을 알 수 있다. 삽입 정렬 (Insertion Sort) 삽입 정렬은 특정 데이터를 적절한 위치에 삽입하여 정렬하는 알고리즘이다. 이는 특정 데이터의 앞까지 데이터들은 정렬되어 있다고 가정하고, 정렬된 데이터들 사이에서 적절한 위치를 골라 해당 데이터를 삽입하는 방식으로 진행된다. 삽입 정렬을 파이썬으로 구현하면 다음과 같다. array = [7, 5, 9, 0, 3, 1, 6, 2, 4, 8] for i in range(1, len(array)): for j in range(i, 0, -1): if array[j] < array[j - 1]: # 한 칸씩 왼쪽으로 이동 array[j], array[j - 1] = array[j - 1], array[j] else: # 자신보다 작은 데이터를 만나면 그 위치에서 멈춤 break print(array) 삽입 정렬은 선택 정렬에 비해 실행 시간의 측면에서 더 효율적인 알고리즘으로 알려져 있고, 특히 데이터가 거의 정렬되어 있을 때 매우 빠르게 동작하는 특징이 있다. 삽입 정렬의 시간 복잡도는 이중 for문이 사용된 점을 보고 O(N²)임을 알 수 있지만 최선의 경우 O(N)을 가진다. 데이터가 거의 정렬되어 있는 상황이라면, 퀵정렬 알고리즘보다도 빠르게 동작한다. 퀵 정렬 (Quick Sort) 퀵정렬은 일반적으로 가장 많이 사용되는 알고리즘이자 대부분의 프로그래밍 언어 정렬 라이브러리의 근간이 되는 알고리즘이다. 기준 데이터(Pivot, 피벗)를 설정하고 그 기준보다 큰 데이터와 작은 데이터의 위치를 교환한 후, 리스트를 반으로 나누는 방식(분할)을 반복해 정렬을 진행한다. 파이썬으로 이를 구현하면 다음과 같다. 여기서 피벗을 정하는 방식은 리스트의 첫 번째 데이터를 피벗으로 정하는 호어 분할(Hoare Partition)을 바탕으로 한다. array = [5, 7, 9, 0, 3, 1, 6, 2, 4, 8] def quick_sort(array, start, end): if start >= end: # 원소가 1개면 종료 return pivot = start left = start + 1 right = end # 엇갈릴 때까지 반복 while left <= right: # 피벗보다 큰 데이터를 찾을 때까지 반복 while left <= end and array[left] <= array[pivot]: left += 1 # 피벗보다 작은 데이터를 찾을 때까지 반복 while right > start and array[right] >= array[pivot]: right -= 1 if left > right: # 엇갈렸다면 작은 데이터와 피벗을 교체 array[right], array[pivot] = array[pivot], array[right] else: # 엇갈리지 않았다면 작은 데이터와 큰 데이터를 교체 array[left], array[right] = array[right], array[left] # 분할 이후 왼쪽 부분과 오른쪽 부분에서 각각 정렬 수행 quick_sort(array, start, right - 1) quick_sort(array, right + 1, end) quick_sort(array, 0, len(array) - 1) print(array) 퀵정렬의 평균 시간 복잡도는 O(NlogN)이다. 데이터를 절반씩 분할하며 진행한다고 가정하면, 기하급수적으로 분할 횟수가 감소함을 알 수 있다. 퀵정렬은 데이터가 무작위로 입력되는 경우 빠르게 동작할 가능성이 높지만, 이미 데이터가 정렬되어 있는 경우에는 최악의 경우 O(N²)의 시간 복잡도를 가지며 느리게 동작한다. 하지만, 대부분의 정렬 라이브러리는 피벗값 설정 로직을 추가해 최악의 경우에도 O(NlogN)의 시간 복잡도를 보장하므로 크게 신경쓰지 않아도 된다. 계수 정렬 (Count Sort) 계수 정렬 알고리즘은 특정 조건(모든 데이터가 0을 포함한 양의 정수로 표현될 수 있어야 함)에 부합해야 한다는 제약이 있지만, 조건이 갖춰지면 매우 빠르게 동작하는 정렬 알고리즘이다. 데이터의 모든 범위를 담을 수 있는 크기의 리스트를 선언해, 데이터를 직접 세어 리스트에 기록한 후 정렬한다. 그러므로 가장 큰 데이터와 가장 작은 데이터의 차이가 작을 때(1,000,000을 넘지 않을 때) 효과적으로 사용할 수 있다. # 모든 원소 값은 0보다 크거나 같음 array = [7, 5, 9, 0, 3, 1, 6, 2, 9, 1, 4, 8, 0, 5, 2] # 모든 원소 값이 0으로 초기화 된 모든 범위를 포함하는 리스트 생성 count = [0] * (max(array) + 1) for i in range(len(array)): count[array[i]] += 1 # 각 데이터에 해당하는 인덱스의 값 증가 # 리스트의 정보를 확인하여 그 값만큼 출력 반복 for i in range(len(count)): for j in range(count[i]): print(i, end=' ') 모든 데이터가 양의 정수(0을 포함한)로 표현될 수 있다면, 데이터의 개수가 N, 데이터 중 최댓값이 K일 때, 최악의 경우에도 O(N + K)의 시간 복잡도를 보장한다. 공간 복잡도 역시 O(N + K)이다. 또한, 데이터의 크기가 한정되어 있고 많이 중복되어 있을수록 유리하다. 정렬 알고리즘 비교 본 포스팅은 ‘안경잡이 개발자’ 나동빈 님의 저서 ‘이것이 코딩테스트다’와 그 유튜브 강의를 공부하고 정리한 내용을 담고 있습니다.

Computer Science · 2020-11-17

DFS(Depth-First Search) & BFS(Breadth-First Search)

그래프 탐색 하나의 자료구조로서 그래프(Graph)는 데이터와 데이터 사이의 관계를 잘 표현해주는 자료구조이다. 그래프는 기본적으로 데이터가 담기는 노드(Node)와 데이터 사이를 연결하는 간선(Edge)으로 이루어져있다. 노드는 정점(Vertex)이라고도 불린다. 그래프 탐색은 하나의 노드를 시작으로 다수의 노드를 방문하는 것을 말하며, 간선으로 연결되어 있는 두 노드는 서로 ‘인접’해 있다고 한다. DFS (Depth-First Search, 깊이 우선 탐색) DFS는 그래프의 깊은 부분을 우선적으로 탐색하는 알고리즘이다. 특정한 경로로 먼저 최대한 깊숙이 탐색한 후, 다시 돌아와 다른 경로를 탐색한다. DFS는 스택이나 재귀함수를 활용해 구현하며, 기본 순서는 다음과 같다. 탐색 시작 노드를 스택에 삽입하고 방문 처리한다. 스택의 최상단 노드에 방문하지 않은 인접 노드가 있으면 그 인접 노드를 스택에 넣고 방문 처리한다. 방문하지 않은 인접 노드가 없으면 스택에서 최상단 노드를 꺼낸다. 2번의 과정을 더 이상 수행할 수 없을 때까지 반복한다. 위와 같은 그래프를 DFS로 탐색 시, 방문 순서는 1 - 2 - 7 - 6 - 8 - 3 - 4 - 5 이다. 파이썬으로 이를 구현하면 다음과 같다. def dfs(graph, v, visited): # 현재 노드 방문 visited[v] = True print(v, end=' ') # 현재 노드의 인접 노드를 재귀적으로 방문 for i in graph[v]: if not visited[i]: dfs(graph, i, visited) # 각 노드가 연결된 정보 표현 graph = [ [], [2, 3, 8], [1, 7], [1, 4, 5], [3, 5], [3, 4], [7], [6, 8], [1, 7] ] # 각 노드의 방문 정보 표현 visited = [False] * 9 # DFS 함수 호출 dfs(graph, 1, visited) BFS (Breadth-First Search, 너비 우선 탐색) BFS는 가까운 노드부터 탐색하는 알고리즘이다. BFS는 큐 자료구조를 활용해 구현하는 것이 일반적이며 다음과 같은 절차로 이루어진다. 탐색 시작 노드를 큐에 삽입하고 방문 처리를 한다. 큐에서 노드를 꺼내 해당 노드의 인접 노드 중에서 방문하지 않은 노드를 모두 큐에 삽입하고 방문 처리를 한다. 2번의 과정을 더 이상 수행할 수 없을 때까지 반복한다. 위 그래프를 BFS로 탐색하면 1 - 2 - 3 - 8 - 7 - 4 - 5 - 6 이다. 이를 파이썬으로 구현하면 다음과 같다. from collections import deque # BFS 메서드 정의 def bfs(graph, start, visited): queue = deque([start]) visited[start] = True # 큐가 빌 때까지 반복 while queue: # 큐에서 하나의 원소를 뽑아 출력 v = queue.popleft() print(v, end=' ') # 아직 방문하지 않은 인접 노드들을 큐에 삽입하고 방문 처리 for i in graph[v]: if not visited[i]: queue.append(i) visited[i] = True # 각 노드가 연결된 정보 표현 graph = [ [], [2, 3, 8], [1, 7], [1, 4, 5], [3, 5], [3, 4], [7], [6, 8], [1, 7] ] visited = [False] * 9 bfs(graph, 1, visited) Reference gimtommang11 자료구조 그래프 3. DFS & BFS 본 포스팅은 ‘안경잡이 개발자’ 나동빈 님의 저서 ‘이것이 코딩테스트다’와 그 유튜브 강의를 공부하고 정리한 내용을 담고 있습니다.

Computer Science · 2020-10-20

재귀 함수(Recursive Function)

자기 자신을 다시 호출하는 함수를 의미한다. 이는 어린 시절 수학 과목을 공부할 때 마주하는 프랙털(Fractal) 구조와 비슷하다. 프랙털 구조에서는 같은 모양의 도형이 무한히 반복되는 형태를 볼 수 있다. 같은 모양이 무한히 반복되는 삼각형 재귀 함수가 자기 자신을 호출하는 것도 무한히 반복되는 양상을 보인다. 따라서, 재귀 함수를 사용할 때는 항상 종료 조건을 명시해 함수의 끝을 만들어야 한다. 또한, 재귀 함수는 컴퓨터 내부 메인 메모리의 스택 공간에 적재된다. 이 말은 재귀 함수가 스택 자료구조와 내부적으로 동일함을 의미한다. 따라서, DFS와 같이 스택 자료구조를 사용해야 하는 알고리즘은 재귀 함수를 통해 간편히 구현할 수 있다. 다음은 파이썬으로 구현한 간단한 재귀 함수이다. def recursive_function(n): if n == 100: return print(n, "번째 재귀함수에서", n+1, "번째 재귀함수를 호출합니다.") recursive_function(n+1) print(n, "번째 재귀함수가 종료됩니다.") recursive_function(1) 위 재귀 함수는 100번째에 호출될 때 가장 나중에 호출되었던 함수들부터 모든 함수들이 하나씩 종료되는 스택과 같은 구조를 보인다. 본 포스팅은 ‘안경잡이 개발자’ 나동빈 님의 저서 ‘이것이 코딩테스트다’와 그 유튜브 강의를 공부하고 정리한 내용을 담고 있습니다.

Computer Science · 2020-10-19

스택(Stack)과 큐(Queue)

스택(Stack) 스택 자료구조는 상자 쌓기와 비슷하다. 차곡 차곡 아래서부터 위로 상자를 쌓아 나가면, 상자를 뺄 때는 상자들이 무너지지않게 맨 위의 가장 나중에 쌓은 상자부터 빼야 한다. 스택도 마찬가지다. 가장 나중에 들어온 데이터를 가장 먼저 빼는 후입선출(LIFO: Last In First Out) 구조를 가진다. 상자 쌓기 게임 Dropping Box 파이썬에서는 별도의 라이브러리 없이 기본 리스트 자료형으로 스택을 쉽게 구현할 수 있다. # Stack으로 삽입(5) - 삽입(2) - 삽입(3) - 삽입(7) - 삭제() - 삽입(1) - 삽입(4) - 삭제() 구현 stack = [] stack.append(5) stack.append(2) stack.append(3) stack.append(7) stack.pop() stack.append(1) stack.append(4) stack.pop() # 가장 윗 부분부터 출력 print(stack[::-1]) 큐(Queue) 큐는 우리에게 상당히 익숙한 자료구조다. 흔히 얘기하는 선착순 혹은 놀이공원 대기줄처럼 먼저 도착한 데이터가 먼저 그 대기줄을 빠져나가게 된다. 이러한 구조를 선입선출(FIFO: First In First Out) 구조라고 한다. 이러한 큐는 구조적 속성상 ‘공정한 자료구조’라고도 불린다. 흔한 놀이공원의 대기 줄.jpg 큐를 파이썬으로 구현할 때는 collections 라이브러리의 deque 자료구조가 유용하다. 리스트 자료형보다 데이터의 삽입 및 삭제가 빨라 구현이 용이하다. # 삽입(5) - 삽입(2) - 삽입(3) - 삽입(7) - 삭제() - 삽입(1) - 삽입(4) - 삭제() from collections import deque queue = deque() queue.append(5) queue.append(2) queue.append(3) queue.append(7) queue.popleft() queue.append(1) queue.append(4) queue.popleft() print(queue) # 먼저 들어온 순서대로 출력 queue.reverse() print(queue) # 역순으로 출력

Computer Science · 2020-10-18

CodeUP 기초 100제 마무리 완료! (by Python)

코드업 기초 100제를 드디어 마무리했습니다. 저는 저에게 익숙한 파이썬으로 진행했는데, 금방 끝날 줄 알았던 문제풀이가 모두 완료되기까지 꽤 오랜 시간이 걸렸어요. 문제들이 기초 문법 다지기와 같은 것이 많았는데, 번거로우면서도 미처 몰랐던 작은 부분까지 차곡차곡 다져갈 수 있어서 좋은 경험이었단 생각이 듭니다. 요즈음 나동빈 님의 ‘이것이 취업을 위한 코딩 테스트다’ 책을 유튜브와 병행하며 공부하고 있는데, 책에서 권하는 코딩 테스트 준비 로드맵의 첫 번째가 바로 ‘CodeUp 기초 100제’ 풀기였습니다. 1단계를 마무리했으니 이제 조금 더 편한 마음으로 알고리즘 이론과 높은 난이도 문제 풀이에 집중할 수 있겠습니다. 기초 100제에 있는 문제는 전부 풀었는데, 3문제 정도는 원래 빠져있었나 봐요. repl.it에서 코드를 실행하며 문제를 풀었지만, 기초여도 미처 생각지 못한 테스트 케이스들 혹은 낯설은 문제들에 의해 잘못된 풀이를 제출할 때가 있었습니다. (기초일수록 더욱 respect하기!!) 또 뒷부분 마지막에 몰려 있는 2차원 배열 문제들은 꽤 오래 생각해야 풀리는 문제들이 많았어요. 가장 시간이 오래 걸리는 부분이었지만 가장 재밌었던 기초 100제의 꽃이라고 느꼈습니다 :) 최근 학습 그래프를 보니 문제 풀이에 오래 걸린 이유를 알겠네요… 물론 다른 프로그래밍 공부도 했기 때문에 변명은 있지만, 변명은 변명일 뿐! 더욱더 꾸준히 알고리즘 공부를 병행해야겠습니다 :)

Blog · 2020-09-18

'이것이 취업을 위한 코딩 테스트다'로 코딩 테스트 시작하기

“코딩 테스트를 떨어졌다!” 최근에 가장 많이 맞닥뜨린 상황이다. 인턴, 정규직 지원은 아니지만 간절히 원하던 교육 프로그램에 지원할 때마다 항상 2차 코테를 넘어서지 못하고 있다… 비전공자의 입장이다 보니 코테에 대한 제대로 된 지식 없이 약간의 문제 풀이 연습으로 도전한 게 화근인 듯싶다. 처음에는 1차 코테를 통과하길래 솔직히 “오? 되나?” 싶었다. 그러나 다른 분들 후기를 보고 나니 코테는 시간 복잡도나 알맞은 자료구조 선택 같이 깊게 생각하고 코드에 녹여야 할 요소가 많았다. 사실, 교육 프로그램 입과를 목표로 했기 때문에 코테 준비사항에서도 큰 요구가 없는 것 같았다. ‘자료구조’나 ‘알고리즘’이 중요한 과목임을 알지만 ‘들어가서 공부하자’ 싶었다. 특히, 비전공자니까 혼자 공부하는 것보단 어딘가에 소속돼서 교육 받아야 한다는 생각이 강했다. (함께하는 동료들도 만나야 시너지가 있으니까!) 하지만, 막상 코테를 접하니 교육 프로그램 입과 문제에서도 (모든 문제가 그렇지는 않았지만) ‘자료구조’, ‘알고리즘’에 대한 이해가 필요했다. 그렇게 입과에 떨어지고 점점 시간이 지나가다 보니, 내실이 부족해져 감을 느꼈다. 이전 동아리 동료들과 프로젝트를 하며 항상 재밌게 공부했던 프로그래밍인데, 시간이 지날수록 발전이 없구나… 서글퍼졌다. 그래서 내린 결론은 ‘나에게 집중하자!’이다. 지금은 공백에 대한 걱정이나 교육 프로그램에 의지하지말고 스스로 부족한 것에 집중하기로 결정했다. 특히나 나이에 관대한 곳이 IT니까 조급하지 말고 길게 보자고 다독였다. 그렇게 차근차근하다 보면 좋은 기회가 오지 않을까? :) 자료구조와 알고리즘에 한해서 현재 나의 상태를 보면, 전공도 부전공도 아니지만 컴퓨터공학과 수업을 통해 C언어로 자료구조 공부를 한 적이 있다. (친절하고 열정적이신 교수님 덕에 높은 집중력으로 A+를 받았었다.) 하지만, 지금 바로 구현할 수 있냐고 묻는다면 그렇지 않다. (특히, 그래프 단원 쪽에서 다익스트라나 벨만포드를 보고 경악했던 기억이 난다.) 그래도 과제를 하며 스택, 큐, 힙, 우선순위 큐 같은 여러 지식들에 익숙해졌으니까, 이제는 책을 보고 문제를 풀며 온전히 내 것으로 만들어 보고자 한다. 어떤 책으로 공부할까? 이전에 SW 마에스트로를 하던 동생에게 알고리즘 책으로 유명한 종만북을 추천받은 적이 있는데, 찾아보니 무지 어려워 보였다. C++을 배워본 적이 없으니까 나의 미천한 C 실력으로는 아직 무리라고 판단했다. ‘종만북’으로 유명한 구종만 님의 알고리즘 문제해결전략 그러던 중, 유튜브에서 자주 영상을 챙겨봤었던 ‘안경잡이 개발자’ 나동빈 님이 최근에 내신 저서 ‘이것이 취업을 위한 코딩 테스트다’를 발견했다. 책을 살 때는 항상 신중히 구매하는 편인데, 이 책은 알찬 콘텐츠 구성과 나동빈 님께 느끼는 신뢰가 있어서인지 큰 고민 없이 바로 구매했다. (이렇게 저항감 없이 구매하는 건 참 오랜만이다…) 나에게는 자료구조, 알고리즘뿐만 아니라 코딩 테스트의 일반적인 지식도 필요했는데, 이 책은 자료구조, 알고리즘에 대한 내용과 더불어 초보자 알고리즘 독학 로드맵, 최근 기업 코테의 동향까지 하나로 모아져 있었다. 또한, 파이썬이 익숙한 편이라 문제 풀이의 주 언어로 파이썬을 사용했다는 점도 매력적이었다. 거기에 유튜브 인강까지 매주 토, 일 진행한다고 하니 망설일 이유가 없었다. 이제 1강 들었는데 강의 길이가 꽤나 길었다. 그래도 꾸준히 공부한 내용을 기록하며 마지막에는 책에 대한 리뷰까지 행복하게 남기고 싶다. 알고리즘 푸는 것이 꽤나 즐겁다고 느끼는 요즈음이다. 부족한 부분 투성이지만 하나하나 나의 장점으로 만들어 가야겠다.

Blog · 2020-09-06

Lucian Log

Contact

All Posts