이수재 블로그

[Proxmox] 설치 후 추천 설정 작업

SooJae — Fri, 29 Nov 2024 00:44:37 +0900

1. No valid subscription 알람창 제거

Proxmox를 실행하면 다음과 같은 알람창이 표시된다.

You do not have a valid subscription for this server. Please visit www.proxmox.com to get a list of available options.

다음 과정을 통해 알람창을 없애보자.

1. proxmoxlib.js 파일 편집

nano /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js

2. Ctrl + w (찾기) 를 누른 후 No valid subscription 를 적으면 해당 위치로 이동한다.

3. 아래 캡처에서 빨간색으로 표시된 부분의 코드를 기존의 `!==`에서 `===`로 수정해준다.

4. 저장하면 더 이상 No valid subscription 알람이 나타나지 않는다.

2. 무료 레포지토리 설정 + 패키지 업데이트

설치하자마자 `$ apt-get update`를 하면 에러가 발생한다. Proxmox VE 레포지토리는 기본적으로 엔터프라이즈(유료 구독)로 되어있기 때문이다. 그래서 무료로 사용자용 레포지토리(pve-no-subscription)를 이용해야한다.

Proxmox 콘솔로 접속 후, 아래 화면에서 Shell 부분을 클릭한 후에 하나씩 작업해보자.

1. sources.list.d 폴더 내의 파일들 제거 (warning 방지)

rm /etc/apt/sources.list.d/*

2. 다음 명령어로 레포지토리 추가

echo "deb [arch=amd64] http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list

3. apt 업데이트

apt update && apt full-upgrade

3. 네트워크 변경

공유기 변경으로 인해 게이트웨이(공유기 주소)가 변경 되거나, 설치시 네트워크를 잘못 입력했을 경우 네트워크를 변경하는 방법이다.

1. `$ nano /etc/network/interfaces`

2. address와 gateway를 변경 (아래 캡쳐 참고)

참고로 필자는 iptime -> asus 공유기로 교체했기 때문에 `address: 192.168.50.100/24`, `gateway: 192.168.50.1` 로 변경했다.

4. DNS 설정

인터넷을 사용하는 통신사를 변경했을때, DNS를 변경해줘야 한다.

1. dns를 관리하는 resolv.conf 파일에 접근

nano /etc/resolv.conf

2. nameserver 등록

참고 ) 통신사별 네임서버 목록

KT
- 기본 DNS 서버 : 168.126.63.1
- 보조 DNS 서버 : 168.126.63.2

SKT
- 기본 DNS 서버 : 219.250.36.130
- 보조 DNS 서버 : 210.220.163.82

LG
- 기본 DNS 서버 : 164.124.101.2
- 보조 DNS 서버 : 203.248.252.2

Google
- 기본 DNS 서버 : 8.8.8.8
- 보조 DNS 서버 : 8.8.4.4

5. 유저 설정

시스템 구성 시 보안을 강화하기 위해 루트(root) 계정으로 직접 SSH 접속하는 대신, 별도의 일반 사용자를 생성하고 SSH 접속을 설정하는 방식으로 접근하자.

proxmox 서버에 접속해서 유저 생성

$ adduser jerry
$ apt install sudo
$ groupadd sudoers
$ usermod -g sudoers jerry
$ EDITOR=nano visudo
$ su jerry

로컬에서 ssh 공개키를 서버로 복사

ssh-copy-id root@192.168.50.100

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.0.12's password:

Number of key(s) added:        1

Now try logging into the machine, with:   "ssh 'root@192.168.0.12'"
and check to make sure that only the key(s) you wanted were added.

`$ nano /etc/ssh/sshd_config`파일 에서 비밀번호 인증 및 루트 계정 로그인 방식을 차단

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no

ssh 서비스 리스타트

sudo systemctl restart ssh

REFERENCES

Proxmox(PVE) 8 설치 후 해야할 일 - https://velog.io/@wooadev/ProxmoxPVE-8-%EC%84%A4%EC%B9%98-%ED%9B%84-%ED%95%B4%EC%95%BC-%ED%95%A0-%EC%9D%BC-No-valid-subscription-%ED%8C%9D%EC%97%85-%EC%97%86%EC%95%A0%EA%B8%B0

HDD Mount - https://velog.io/@hong-brother/Proxmox

Proxmox VE 기초설정 - https://annyeong.me/n/proxmox-setup

Proxmox DHCP 설정 - https://velog.io/@minse0204/Proxmox-DHCP-%EC%84%A4%EC%A0%95

[Proxmox] Proxmox 8.3버전 설치

SooJae — Wed, 27 Nov 2024 22:50:20 +0900

Proxmox를 설치해보자. USB 저장소가 필요하다.

컴퓨터 사양

CPU: AMD Ryzen 5 5600
RAM: 64GB
SSD: 1TB (512GB + 512GB)
GPU: NVIDIA GeForce GTX 1660 Super

1. Proxmox ISO 파일 다운로드

Downloads

Proxmox VE 8.3 ISO Installer Version 8.3-1 File Size 1.45 GB Last Updated November 21, 2024 SHA256SUM b5c2d10d6492d2d763e648bc8562d0f77a90c39fac3a664e676e795735198b45

www.proxmox.com

위 사이트에 접속한 후에 `Proxmox VE 8.3 ISO Installer`를 다운받는다. (아래 화면 참고)

2. Rufus 다운로드

아래 사이트에서 Rufus를 다운받자.

Rufus - 간편한 방법으로 부팅 가능한 USB 드라이브 만들기

Rufus는 USB 키/펜드라이브, 메모리 스틱 등과 같은 부팅 가능한 USB 플래시 드라이브를 포맷하고 생성하는 데 도움이 되는 유틸리티입니다. Rufus는 작은 크기에도 불구하고 필요한 모든 것을 제공

rufus.ie

3. Proxmox 부팅용 USB 제작

Rufus를 이용해서 준비한 USB를 부팅용 USB를 만들어보자.

Proxmox 설치용 USB 제작이 완료되었다.

4. 부팅 순서 변경

USB를 Proxmox를 설치할 기기에 연결한 후, 부팅을 진행한다. 부팅 시 BIOS 메뉴에 진입하려면 특정 키(주로 Delete 키)를 반복해서 누른다. 부팅 순서 변경은 아래 글을 참고하면 된다.

부팅 순서를 변경하는 방법

PC에서 부팅 순서를 변경하는 방법을 알아보십시오. 다음 단계에 따라 부팅 시퀀스 우선 순위와 하드 드라이브 BBS 우선 순위를 설정하십시오.

kr.msi.com

부팅 순서 변경이 완료되면, 기기를 재시작한다.

5. Proxmox 설치

재시작하면 아래와 같은 화면이 표시된다. 일반적으로 첫 번째 옵션을 선택하지만, 필자의 경우 검은 화면이 나타나 두 번째 옵션(Terminal UI)을 선택해 설치를 진행했다.

검은 화면이 나타난 모습

나라, 시간대, 키보드 설정

Contry: South Korea
Timezone: Asia/seoul
keyboard layout: U.S English

패스워드, 이메일 설정

Root password: 루트 사용자 패스워드
Administrator email: 루트 사용자 이메일

네트워크 설정

네트워크 주소들은 기본 값으로 지정했다. hostname만 내 임의로 지정했다.

Management Interface:Proxmox VE가 사용할 네트워크 인터페이스를 선택하는 항목
Hostname (FQDN):Proxmox 서버의 호스트 이름을 설정
IP Address (CIDR):Proxmox 서버가 사용할 고정 IP 주소를 설정. CIDR 표기법을 사용하여 서브넷 마스크를 포함해야 한다.
Gateway Address:서버가 외부 네트워크와 통신하기 위해 사용할 게이트웨이 주소를 설정
DNS Server Address:서버가 도메인 이름을 해석할 때 사용할 DNS 서버 주소를 설정.

위 화면에서는 DNS Server에 168.126.63.1를 사용했는데, 이는 내 인터넷 통신사가 KT여서 KT의 DNS서버가 자동으로 설정되었다.

이어서 진행하면 설치가 완료되며 다음과 같은 화면이 표시된다.

6. 콘솔 연결

Proxmox서버 설치가 완료됐다! 이제 해당 서버의 공유기와 같은 망에 존재하는 기기로 위의 주소로 접속 해보면 다음과 같은 화면이 표시된다.

username: root
password: 설치시 등록했던 비밀번호

로그인후 콘솔창이 나오면 설치 확인까지 완료!

REFERENCE

Proxmox 설치 - https://phum.co.kr/tech-32/

[Spring] DeepL API를 이용한 번역 기능 추가하기

SooJae — Fri, 20 Sep 2024 23:21:04 +0900

DeepL 번역

대표적인 번역 API 로는 Google Translate API, Microsoft Azure Translator, 그리고 최근 많이 사용되는 DeepL API가 있다.

솔직히, 아직까지는 DeepL이 다른 번역 API들보다 더 우수한 번역 결과를 보여주는 것 같다. 이번 시간에는 DeepL API를 스프링 부트에 적용하여 번역 기능을 추가해보자.

DeepL API Key 발급

우선 아래 사이트로 접속한다.

DeepL Pro | 텍스트, Word 및 기타 문서를 안전하게 번역하세요

빠르고 정확하며 안전한 번역. 개인 및 팀 사용자용 DeepL Pro.

www.deepl.com

회원가입을 한 후에, 위 화면에서 DeepL API Free 플랜을 신청한다.

모든 필드를 작성하자

위와 같은 화면이 나오는데, 요금이 발생하지는 않는다. 무료 플랜의 경우 500,000자까지 이용할 수 있다.

무료 플랜 구독을 완료한 후에, 내 계정에 들어가서 위의 API키를 복사한다.

Deepl-mock

Deepl-mock은 DeepL API를 모방하여 애플리케이션 테스트를 간소화하기 위한 모의 서버이다. 이를 통해 실제 API 호출을 하지 않고도 DeepL API와의 상호작용을 테스트할 수 있으며, 프록시 서버도 포함되어 있어 프록시 사용 테스트도 가능하게 해준다.

GitHub - DeepLcom/deepl-mock: deepl-mock is a mock HTTP server that simulates some behavior of the DeepL API to simplify applica

deepl-mock is a mock HTTP server that simulates some behavior of the DeepL API to simplify application testing. - DeepLcom/deepl-mock

github.com

위의 리포지토리를 클론 받은 후에 도커로 띄우거나 npm으로 실행하면 된다. 도커로 띄어보자.

$ docker image build -t deepl/deepl-mock .
$ docker run -d --rm --name deepl-mock -p3000:3000 -p3001:3001 deepl/deepl-mock

프로젝트 구성

build.gradle.kts

gradle 파일에 deepL라이브러리를 추가해준다.

implementation("com.deepl.api:deepl-java:1.6.0")

TranslateController.kt

@RestController
@RequestMapping("/api/v1/translate")
class TranslateController(
    private val translateService: TranslateService
) {

    @PostMapping
    fun translate(@RequestBody translateRequest: TranslateRequest): String {
        return translateService.translate(translateRequest)
    }
}

TranslateRequest.kt

data class TranslateRequest(
    val text: String,
    val targetLang: LanguageCode
)

TranslateService.kt

@Service
class TranslateService(
    private val translator: Translator = Translator(
        "여기에 발급 받은 DeepL API Key 값을 입력. 절대 외부(깃허브 등)에 노출 금지!!",
        TranslatorOptions().setServerUrl("http://localhost:3000") // deepL-mock을 연결하기 위한 로컬주소. 제거 예정 
        .setSendPlatformInfo(false) // DeepL로 내 어플리케이션 정보를 보내지 않음
    ),

    ) {

    fun translate(text: String, targetLang: LanguageCode): String {
        return translator.translateText(
            text, null, targetLang.code, TextTranslationOptions().setFormality(Formality.PreferMore)
        ).text
    }
}

enum class LanguageCode(val code: String) {
    ENGLISH("en-US"),
    KOREAN("ko"),
}

테스트 결과

이제 서버를 실행 후, 호출을 해보면 아래와 같이 `양성자 빔`값(테스트용 고정 값)을 리턴한다.

DeepL API 호출이 정상적으로 동작하는 것을 확인했으므로, 이제 실제 API를 호출할 수 있도록 `TranslateService.kt` 코드에서 `.setServerUrl("http://localhost:3000")`를 제거한다.

결과

번역이 잘 된것을 확인 할 수 있다. 그러나, 첫 번째 단어인 `Hooks`는 `후크`로 번역하기 보다는 `Hooks`그대로 두거나, `훅`으로 번역되 기를 원한다면. DeepL의 glossary 기능을 사용하여 특정 단어를 사용자 정의할 수 있다.

Glossary 기능 추가

Glossary기능을 통해 커스텀 용어집을 만들어보자. 우선 이전 코드를 수정해야한다.

TranslateRequest.kt

data class TranslateRequest(
    val text: String,
    val targetLang: Lang,
    val sourceLang: Lang,
    val glossaryId: String?
)

TranslateService.kt

@Service
class TranslateService(
    private val translator: Translator = Translator(
        "여기에 발급 받은 DeepL API Key 값을 입력. 절대 외부(깃허브 등)에 노출 금지!!",
        TranslatorOptions().setSendPlatformInfo(false) // DeepL로 내 어플리케이션 정보를 보내지 않음
    ),

    ) {

	fun translate(translateRequest: TranslateRequest): String {
        val translationOptions = TextTranslationOptions().setFormality(Formality.PreferMore)
        // glossaryId가 있으면 glossary를 사용하겠다는 의미
        translateRequest.glossaryId?.let { translationOptions.setGlossary(it) }

        val text = translator.translateText(
            translateRequest.text,
            // Glossary 기능을 설정하면 sourceLang을 꼭 지정을 해야한다.
            translateRequest.sourceLang.sourceCode,
            translateRequest.targetLang.targetCode,
            translationOptions
        ).text
        return text
    }

    fun createGlossary(createGlossaryRequest: CreateGlossaryRequest): CreateGlossaryResponse {
        val createGlossary = translator.createGlossary(
            createGlossaryRequest.glossaryName,
            createGlossaryRequest.sourceLang.sourceCode,
            createGlossaryRequest.targetLang.targetCode,
            GlossaryEntries(createGlossaryRequest.entries)
        )
        return CreateGlossaryResponse(
            glossaryId = createGlossary.glossaryId,
            ready = createGlossary.isReady,
            name = createGlossary.name,
            sourceLang = createGlossary.sourceLang,
            targetLang = createGlossary.targetLang,
            creationTime = createGlossary.creationTime,
            entryCount = createGlossary.entryCount
        )
    }

    fun getGlossary(glossaryId: String): GlossaryInfo {
        return translator.getGlossary(glossaryId)
    }
}

// 영어의 경우 번역시 sourceCode일때와 targetCode일때 코드가 다르다. 
// targetCode일때는 EN-US, EN-GB로 구분해서 써야한다.
enum class Lang(val sourceCode: String, val targetCode: String) {
    ENGLISH("EN", "EN-US"),
    KOREAN( "KO","KO"),
}

Glossary 적용 후, 테스트 결과

위의 glossaryId를 저장해두자.

`Hook : 훅`으로 저장한 후 다시 번역을 시도해보니, 성공적으로 `Hooks`가 `훅`으로 번역되었다.

성공!

그런데...

Glossary를 사용할 때는 한계가 있다. Glossary 기능을 이용하려면 `sourceLang`이 `null`일 수 없어, 언어 감지 기능을 사용할 수 없다.
또한, `sourceLang`을 `ENGLISH`로 지정한 상태에서 번역을 진행하면, 아래와 같이 자연스럽지 않은 번역이 나올 수 있다.

`text`가 영어, 일본어, 중국어, 프랑스어 등 다양한 언어로 무작위로 입력되는 환경에서, 그 언어에 맞게 `sourceLang`을 자동으로 변경하고 싶지만, 이를 자동화하기가 쉽지 않다. 결국 둘 중에 하나를 포기해야한다.

glossary 기능을 포기
`sourceLang`값 `null` (언어감지 기능)을 포기

glossary 기능을 포기하는 것이 좋을 것 같다.

REFERENCES

DeepL API 문서 - https://developers.deepl.com/docs/v/ko

[Spring AI] Vector Store와 RAG를 이용한 할루시네이션 방지

SooJae — Wed, 18 Sep 2024 20:27:15 +0900

스프링 AI 시리즈

[Spring AI] 준비 (기본 개념, OpenAI API Key, 크레딧 충전)
[Spring AI] 챗봇 만들기 (Kotlin)
[Spring AI] Vector Store와 RAG를 이용한 할루시네이션 방지
[Spring AI] OpenAI 비용을 절감하는 방법

주의: 해당 포스팅 진행시, embedding된 데이터에 대한 질문을 OpenAI의 GPT-4 모델을 사용하여 처리할 때마다 약 0.01달러의 비용이 발생합니다.

AI 할루시네이션(Hallucination)

지난 포스팅에서 AI가 `이수재`라는 사람에 대한 정보를 보유하고 있지 않음에도 불구하고, 존재하지 않는 정보를 생성했다. 이는 할루시네이션이라고 불리며, AI가 학습한 데이터 내에서 명확한 답을 찾지 못하거나 관련 정보가 부족할 때, 추론을 통해 그럴듯한 답을 만들어내는 현상이다.

실제 프로젝트 진행 중, AI에서 할루시네이션이 발생하는 경우는 주로 AI가 정확한 정보에 접근하지 못하거나 불완전한 데이터를 기반으로 추론할 때 나타난다. 특히, 사내 기술 문서나 회사 내부에서만 사용하는 전용 자료처럼 인터넷에 존재하지 않거나 공개되지 않은 정보의 경우 이러한 문제가 자주 발생한다.

이러한 문제를 해결하는 데 도움을 줄 수 있는 것이 바로 `Vector store`, `embedding`, 그리고 `RAG (Retrieval- Augmented Generation)`이다.

`Embedding`은 문서나 데이터를 AI가 이해할 수 있는 벡터 형태로 변환하는 기술로, 이를 통해 데이터를 벡터화하여 AI가 처리할 수 있게 한다.

`Vector store`는 이렇게 벡터화된 데이터를 저장하고, 필요한 정보를 빠르게 검색할 수 있도록 해준다.

`RAG`는 이 과정에서 중요한 역할을 한다. AI가 질문을 받으면, RAG는 먼저 Vector Store에서 해당 질문과 관련된 정보를 검색하고, 검색된 데이터를 바탕으로 AI가 답변을 생성한다. 이로 인해 AI는 embedding 형태로 저장된 사내 기술 문서나 관련 정보등을 활용하여 더욱 정확하고 관련성 높은 답변을 제공할 수 있다.

결국, embedding을 통해 데이터를 벡터화하고, Vector store에서 필요한 정보를 검색하며, RAG로 이를 AI 모델이 활용할 수 있도록 하여, 할루시네이션을 방지하고 정확한 답변을 도출할 수 있게 된다.

RAG에 대해 좀 더 알아보고 싶다면, 아래 블로그를 참고하면 좋다. 내용이 굉장히 잘 정리되어있다.

문서 전처리와 임베딩의 중요성: RAG 프로젝트 성공하기

최근 저는 회사에서 RAG(Retrieval-Augmented Generation)를 활용한 사내 문서 챗봇 프로젝트를 진행하게 되었습니다. 이 프로젝트를 진행하면서 채팅의 퀄리티를 높이려면, 문서의 전처리와 임베딩이 중

medium.com

이제 Spring AI 코드를 만들어보자.

Vector Store 설치

Spring AI가 지원하는 다양한 Vector Store가 존재하지만, 이번 프로젝트에서는 `Chroma DB`라는 Vector Store를 설치해보자.

docker-compose.yaml

services:
  chroma:
    image: ghcr.io/chroma-core/chroma:0.5.4
    container_name: chroma-db
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ./local-env/volumes/chroma-data:/chroma/chroma
    command: "--workers 1 --host 0.0.0.0 --port 8000 --proxy-headers --log-config chromadb/log_config.yml --timeout-keep-alive 30"
    environment:
      - IS_PERSISTENT=TRUE
    ports:
      - "8000:8000"

ChromaDB Admin

ChromaDB를 위한 정식 UI 도구는 아직 존재하지 않는다. 하지만 UI 환경에서 ChromaDB를 작업할 수 있도록 도와주는 비공식 오픈소스인 ChromaDB Admin을 활용해보자.

GitHub - flanker/chromadb-admin: Admin UI for Chroma embedding database built with Next.js

Admin UI for Chroma embedding database built with Next.js - flanker/chromadb-admin

github.com

위 리포지토리를 `git clone`한 후에, 실행시켜준다.

$ pnpm install && pnpm dev

그 후, http://localhost:3000에 접속하면 아래와 같은 화면을 확인 할 수 있다.

이제 본격적으로 코드를 작성해보자.

전체 파일 구조

이번 포스팅에 필요한 파일들만 표시

build.gradle.kts

plugins {
    kotlin("jvm") version "1.9.25"
    kotlin("plugin.spring") version "1.9.25"
    id("org.springframework.boot") version "3.3.3"
    id("io.spring.dependency-management") version "1.1.6"
}

group = "org.example"
version = "0.0.1-SNAPSHOT"

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

repositories {
    mavenCentral()
    maven { url = uri("https://repo.spring.io/milestone") }
}

extra["springAiVersion"] = "1.0.0-M2"

dependencies {
    implementation("org.springframework.ai:spring-ai-openai-spring-boot-starter")
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("org.springframework.boot:spring-boot-starter-validation")
	// 아래 라이브러리 추가
    implementation("org.springframework.ai:spring-ai-chroma-store-spring-boot-starter")

    
    implementation("org.jetbrains.kotlin:kotlin-reflect")
    testImplementation("org.springframework.boot:spring-boot-starter-test")
    testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")   
}

dependencyManagement {
    imports {
        mavenBom("org.springframework.ai:spring-ai-bom:${property("springAiVersion")}")
    }
}

kotlin {
    compilerOptions {
        freeCompilerArgs.addAll("-Xjsr305=strict")
    }
}

tasks.withType<Test> {
    useJUnitPlatform()
}

application.yml

spring:
  application:
    name: spring-ai
  ai:
    openai:
      api-key: # 여기에 발급 받은 OpenAI API Key 값을 입력. 절대 외부(깃허브 등)에 노출 금지!!
      embedding:
        options:
          model: text-embedding-ada-002
      chat:
        options:
          model: gpt-3.5-turbo
          temperature: 0.7
          max-tokens: 200

    vectorstore:
      chroma:
        client:
          host: http://localhost
          port: 8000
        collection-name: vector_store
        initialize-schema: true

AiChatConfig.kt (이전 포스팅에서 만들었던 파일)

@Configuration
class AiChatConfig(
    val chatClient: ChatClient.Builder,
) {
    @Bean
    fun chatClient(): ChatClient {
        return chatClient.build()
    }
}

AiDocumentController.kt

@RestController
@RequestMapping("/api/v1/documents")
class AiDocumentController(
    private val aiDocumentService: AiDocumentService
) {


    @PostMapping("/markdown")
    fun createDocumentFromMarkDown() {
        return aiDocumentService.storeDocumentsFormMarkdown()
    }

    @PostMapping("/chat")
    fun chat(@RequestBody chatAiDocumentRequest: AiDocumentChatRequest): AiDocumentChatResponse {
        return aiDocumentService.chat(chatAiDocumentRequest)
    }
}

AiDocumentService.kt

@Service
class AiDocumentService(
    private val vectorStore: VectorStore,
    private val chatClient: ChatClient,
) {

    @Value("classpath:/documents/rules-of-hooks.md")
    var mdResource: Resource? = null

    fun storeDocumentsFormMarkdown() {
        val textReader = TextReader(mdResource)
        val splitDocuments = TokenTextSplitter().split(textReader.read())
        vectorStore.add(splitDocuments)
    }

    fun chat(chatAiDocumentRequest: AiDocumentChatRequest): AiDocumentChatResponse {
        val response = chatClient.prompt()
            .advisors(
                QuestionAnswerAdvisor(
                    vectorStore, SearchRequest.defaults()
                )
            )
            .user(chatAiDocumentRequest.userInput)
            .call()
            .content()

        return AiDocumentChatResponse(response);
    }

AiDocumentChatRequest.kt

data class AiDocumentChatRequest(
    @NotBlank(message = "User input must not be blank")
    val userInput: String = ""
)

AiDocumentChatResponse.kt

data class AiDocumentChatResponse(val response: String)

rules-of-hooks.md

리액트 공식 문서에서 `rules-of-hooks.md` 파일을 GitHub에서 다운로드하여 프로젝트의 `resources/documents` 경로에 추가했다.

react.dev/src/content/reference/rules/rules-of-hooks.md at main · reactjs/react.dev

The React documentation website. Contribute to reactjs/react.dev development by creating an account on GitHub.

github.com

이제 서버를 실행시킨 후, markdown 문서를 chromadb에 적재시켜보자.

curl --location --request POST 'http://localhost:8080/api/v1/documents/markdown'

http://localhost:3000에 접속(chromadb-admin)하면, markdown파일의 내용들이 적재가 된 것을 확인할 수 있다.

chromadb-admin 화면

이제 스프링부트 서버에 질문을 해보자. 앞서 적재한 `rules-of-hooks.md` 파일의 내용과 유사한 질문을 하면, 해당 내용을 바탕으로 적절한 답변을 제공할 것이다.

이제 이수재에 대해 물어보면, 이전 포스팅에서 이상한 답변이 나왔던 것과 달리, chromaDB에 저장된 내용만을 바탕으로 답변한다.

chromadb에 저장된 내용만을 바탕으로 답변

그런데...

비용이 지나치게 많이 발생하고 있다. 질문 한번에 약 0.01달러가 발생하고있다. 예를 들어, 사내 기술 문서를 위한 챗봇을 만든다면 GPT-4 모델을 사용하는 것은 오버 엔지니어링일 수 있다. 사내 문서 검색이나 관련성 높은 답변 제공에는 고사양 AI 모델이 꼭 필요하지 않을 수 있으므로, 더 경량화된 모델이나 로컬 LLM을 고려하는 것이 적합할 수 있다.

다음 포스팅에서는 비용 절감을 위한 여러 방법을 시도해보자.

REFERENCES

문서 전처리와 임베딩의 중요성: RAG 프로젝트 성공하기 - https://medium.com/@minji.sql/%EB%AC%B8%EC%84%9C-%EC%A0%84%EC%B2%98%EB%A6%AC%EC%99%80-%EC%9E%84%EB%B2%A0%EB%94%A9%EC%9D%98-%EC%A4%91%EC%9A%94%EC%84%B1-rag-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EC%84%B1%EA%B3%B5%ED%95%98%EA%B8%B0-97ae34e879b4

Vector Store란 - https://devocean.sk.com/blog/techBoardDetail.do?ID=164964&boardType=techBlog

RAG = Vector Search + LLM 1편 - https://blog.mnc.ai/74

스프링 AI - https://docs.spring.io/spring-ai/reference/api/embeddings.html

hELLO 스킨 4.10버전 백틱 인라인 코드 설정

SooJae — Fri, 13 Sep 2024 21:18:44 +0900

hELLO스킨은 4.10버전 기준으로 화면 구조가 변경되어서, `document.querySelectorAll()` 코드를 다음과 같이 변경해야한다.

HTML편집 화면 </body> 앞에 삽입

<script> 
  window.onload = function() { 
  let textNodes = document.querySelectorAll("div.contents_style > *:not(figure):not(pre):not(div)");
  textNodes.forEach(node => {
    node.innerHTML = node.innerHTML.replace(/`(.*?)`/g, `<code class='notion-code'>$1</code>`);
  });
}
</script>

CSS편집 화면 코드 추가

.notion-code {
    font-family: Consolas !important;
    line-height: normal !important;
    background: rgba(135,131,120,0.15) !important;
    color: #EB5757 !important;
    border-radius: 3px !important;
    font-size: 85% !important;
    padding: 0.2em 0.4em !important;
    margin-right: 0.2em !important;
    display: inline-block !important;
}

백틱을 이용한 인라인 코드블록 관련 내용은 아래 블로그들을 참고하면 된다.

[티스토리]10초만에 가능한 인라인 코드블록 편하게 적용하는 방법

안녕하세요 무택입니다 :) 오늘은 티스토리에서 인라인코드를 코드블록으로 만드는 방법 + 간편하게 설정할 수 있는 방법에 대해 써보려고 합니다. 개발 관련 블로그를 운영하고 있고 운영할 생

mu08.tistory.com

티스토리에 백틱으로 인라인 코드 블럭 만들기

들어가며 `Velog`에서 작성했던 글들을 `Tistory`로 이전하면서 `Tistory`에서도 인라인 코드 블럭을 적용할 수 있다는 사실을 이번에 처음 알게 되었다. 하지만 알아보니 굉장히 번거로운 과정을 거쳤

dev-qhyun.tistory.com

cannot deserialize from Object value (no delegate- or property-based Creator)]

SooJae — Wed, 11 Sep 2024 00:32:54 +0900

에러 발생

개발하면서 다음과 같은 에러가 발생했다.

JSON parse error: Cannot construct instance of org.example.springai.dto.AiChatRequest (although at least one Creator exists): 
cannot deserialize from Object value (no delegate- or property-based Creator)]

아래와 같이 생성자가 하나일 때 발생한 에러.

data class AiChatRequest(
    val userInput: String
)

Jackson이 객체를 역직렬화할 때는 두 가지 전략을 사용하여 데이터를 객체로 변환한다.

Delegating-based: 하나의 값(예: 문자열, 숫자 등)만을 필드로 갖는 경우 그 값을 해당 클래스에 직접 전달하여 생성자를 호출한다. 이를 통해 단일 값으로 생성할 수 있는 객체에 적합하다.
Properties-based: 클래스 내의 여러 필드를 이용해 객체를 생성하는 방식이다. 이 방식은 JSON에서 키-값 쌍을 각각 클래스의 필드에 매핑합니다. 즉, JSON의 각 속성을 클래스의 필드에 직접 대응시킨다.

Jackson은 필드가 1개일 때 어느 방식으로 역직렬화할지 알지 못해 오류를 발생시키는 경우가 있다. AiChatRequest 클래스가 필드가 1개인 경우, Jackson은 이를 단일 값으로 취급해야 하는지, 아니면 키-값 쌍으로 취급해야 하는지 결정할 수 없어서 발생하는 문제다.

해결법

기본 값 제공 방법 (이 방법으로 해결)

Kotlin에서 제공하는 기본값은 Jackson이 기본 생성자를 호출할 수 있게 하며, 이로 인해 Jackson이 역직렬화를 올바르게 수행할 수 있게 된다. 필드가 없을 경우에는 기본값을 사용하고, 값이 제공될 경우 해당 값을 사용하게 된다.

data class AiChatRequest(
    @NotBlank(message = "User input must not be blank")
    val userInput: String = ""
)

그 외 방법 - @JsonCreator 사용

단일 필드 클래스에서 Jackson에게 명시적으로 생성자를 사용하도록 지시할 수 있습니다. 이를 위해 @JsonCreator와 @JsonProperty 어노테이션을 사용하여 Jackson이 올바르게 역직렬화할 수 있게 도울 수 있습니다.

data class AiChatRequest(
        @JsonProperty("userInput") 
        @NotBlank(message = "User input must not be blank") 
        val userInput: String
)

하지만 `@JsonProperty` 어노테이션을 사용하는 것은 다른 개발자가 그 이유를 쉽게 유추하기 힘들기 때문에, 사용하지 않는 것이 더 낫다고 판단했다.

REFERENCES

[Spring] Kotlin에서 data class의 필드가 1개일 때 역직렬화가 안 되는 문제 (no delegate- or property-based Creator) - https://cl8d.tistory.com/111

[Spring AI] 챗봇 만들기 (Kotlin)

SooJae — Tue, 10 Sep 2024 02:20:47 +0900

스프링 AI 시리즈

[Spring AI] 준비 (기본 개념, OpenAI API Key, 크레딧 충전)
[Spring AI] 챗봇 만들기 (Kotlin)
[Spring AI] Vector Store와 RAG를 이용한 할루시네이션 방지
[Spring AI] OpenAI 비용을 절감하는 방법

이제 본격적으로 OpenAI과 Spring AI를 활용한 챗봇을 만들어보자.

전체 파일 구조

이번 포스팅에 필요한 파일들만 표시

build.gradle.kts

plugins {
    kotlin("jvm") version "1.9.25"
    kotlin("plugin.spring") version "1.9.25"
    id("org.springframework.boot") version "3.3.3"
    id("io.spring.dependency-management") version "1.1.6"
}

group = "org.example"
version = "0.0.1-SNAPSHOT"

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

repositories {
    mavenCentral()
    maven { url = uri("https://repo.spring.io/milestone") }
}

extra["springAiVersion"] = "1.0.0-M2"

dependencies {
    implementation("org.springframework.ai:spring-ai-openai-spring-boot-starter")
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("org.springframework.boot:spring-boot-starter-validation")
    
    implementation("org.jetbrains.kotlin:kotlin-reflect")
    testImplementation("org.springframework.boot:spring-boot-starter-test")
    testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

dependencyManagement {
    imports {
        mavenBom("org.springframework.ai:spring-ai-bom:${property("springAiVersion")}")
    }
}

kotlin {
    compilerOptions {
        freeCompilerArgs.addAll("-Xjsr305=strict")
    }
}

tasks.withType<Test> {
    useJUnitPlatform()
}

application.yml

spring:
  application:
    name: spring-ai
  ai:
    openai:
      api-key: # 여기에 발급 받은 OpenAI API Key 값을 입력. 절대 외부(깃허브 등)에 노출 금지!!
      chat:
        options:
          model: gpt-3.5-turbo
          temperature: 0.7
          max-tokens: 200

AiChatConfig.kt

@Configuration
class AiChatConfig(
    val chatClient: ChatClient.Builder
) {
    @Bean
    fun chatClient(): ChatClient {
        return chatClient.build()
    }
}

OpenAiEmbeddingConfig.kt

@Configuration
@EnableConfigurationProperties(OpenAiEmbeddingProperties::class)
class OpenAiEmbeddingConfig(
    private val openAiEmbeddingProperties: OpenAiEmbeddingProperties
) {
    @Bean
    fun embeddingModel(): EmbeddingModel {
        return OpenAiEmbeddingModel(OpenAiApi(openAiEmbeddingProperties.apiKey))
    }
}

DTO(AiChatRequest.kt, AiChatResponse.kt)

// AiChatRequest
data class AiChatRequest(
    @NotNull(message = "User input must not be null")
    val userInput: String = ""
)


// AiChatResponse
data class AiChatResponse(val response: String

AiChatController.kt

@RestController
@RequestMapping("/api/v1/chat")
class AiChatController(
    private val aiChatService: AiChatService
) {
    @PostMapping
    fun chat(@RequestBody aiChatRequest: AiChatRequest): AiChatResponse {
        return aiChatService.chat(aiChatRequest)
    }
}

AiChatService.kt

@Service
class AiChatService(
    private val chatClient: ChatClient,
    private val aiPromptService: AiPromptService
) {

    fun chat(aiChatRequest: AiChatRequest): AiChatResponse {
        val prompt = aiPromptService.createPrompt(aiChatRequest.userInput)
        return AiChatResponse(chatClient.prompt(prompt).call().content())
    }
}

system-message.st

You are a helpful AI assistant that helps people find information. Your name is {name}
You should reply to the user's request. and do not repeat it.

user-message.st

Tell me {userInput}

AiPromptService.kt

@Service
class AiPromptService(
    @Value("classpath:prompts/chat/system-message.st")
    private val systemResource: Resource,
    @Value("classpath:prompts/chat/user-message.st")
    private val userResource: Resource,
) {
    // 유저 입력을 메시지로 변환
    private fun createUserMessage(userInput: String): Message =
        PromptTemplate(userResource).createMessage(
            mapOf("userInput" to userInput)
        )

    // 시스템 메시지 생성
    private fun createSystemMessage(): Message =
        SystemPromptTemplate(systemResource).createMessage(
            mapOf("name" to "Jerry")
        )

    // 프롬프트 생성
    fun createPrompt(userInput: String): Prompt =
        Prompt(listOf(createUserMessage(userInput), createSystemMessage()))
}

위의 PromptService는 조금 자세히 살펴보자.

systemResource: 시스템의 역할이나 행동을 정의하는 메시지를 저장한 템플릿 파일인 system-message.st
userResource: 사용자가 입력한 내용을 담는 메시지를 저장한 템플릿 파일인 user-message.st

이 두 리소스는 각각 특정 메시지 패턴을 따르며, 메시지 내부에서 동적으로 값을 바인딩할 수 있도록 구성되어 있다.

`createUserMessage` 함수의 경우 `userInput`에 사용자에게 입력받은 `userInput`이 바인딩이 된다.
`createSystemMessage` 함수의 경우 `name`에 `Jerry`가 바인딩 된다.

그래서 시스템의 이름을 물어보면 `Jerry`라고 답을 한다.

대화형 AI에서는 사용자의 질문에 자연스럽고 일관된 답변을 제공하기 위해, 시스템의 역할과 사용자 입력을 효과적으로 전달하는 방법이 중요하다.

이를 위해 템플릿 파일을 서비스에 맞게 변경하거나, 템플릿 메시지를 데이터베이스에 저장하여 동적으로 활용하는 방식이 필요할 것이다.

추가

예?

나는 배우도 아니고, 연기력이 좋지도 않다. 위처럼 AI가 잘못된 정보를 응답해주는 것을 AI 할루시네이션이라고 한다.

AI 할루시네이션

AI 할루시네이션이란 인공지능 모델, 특히 자연어 처리(NLP) 모델이 실제로 존재하지 않거나 잘못된 정보를 마치 사실인 것처럼 생성하거나 제공하는 현상을 의미한다. 이는 인공지능이 주어진 데이터를 바탕으로 패턴을 학습하고 추론을 하지만, 때때로 오류를 범하거나 기존의 정보와 일치하지 않는 새로운 정보를 생성할 때 발생한다.

다음 포스팅에서 Spring AI와 벡터 스토어(Vector Store)를 활용하여 AI 할루시네이션을 줄이고, 보다 신뢰성 있는 답변을 제공하는 방법을 알아보자.

REFERENCES

스프링 ai prompt - https://docs.spring.io/spring-ai/reference/api/prompt.html

[Spring AI] 준비 (기본 개념, OpenAI API Key, 크레딧 충전)

SooJae — Mon, 9 Sep 2024 23:55:48 +0900

스프링 AI 시리즈

[Spring AI] 준비 (기본 개념, OpenAI API Key, 크레딧 충전)
[Spring AI] 챗봇 만들기 (Kotlin)
[Spring AI] Vector Store와 RAG를 이용한 할루시네이션 방지
[Spring AI] OpenAI 비용을 절감하는 방법

스프링 AI란?

Spring AI는 인공지능(AI) 기능을 Spring 애플리케이션에 통합하기 위한 라이브러리이다. 기존에는 거의 파이썬으로만 AI를 활용했지만, 이제 Spring AI를 통해 Java에서도 AI를 활용할 수 있다.

기본 개념 (더보기를 눌러주세요)

모델

AI 모델은 텍스트, 이미지, 오디오 등 다양한 입력을 처리하여 결과를 생성하는 알고리즘이다. Spring AI는 언어, 이미지, 오디오 입력과 출력을 지원하며, 임베딩(Embeddings)도 지원하여 더 고급 사용 사례를 처리할 수 있게 한다. GPT 같은 모델은 사전 훈련된 모델로, 일반적으로 사용자가 특별한 기계 학습 배경 없이도 활용할 수 있는 장점이 있다.

프롬프트(Prompt)

프롬프트는 AI 모델에 원하는 출력을 유도하기 위해 입력하는 텍스트이다. 단순한 문자열 입력처럼 보일 수 있지만, 사실상 시스템의 역할과 사용자 입력 등을 포함하는 복잡한 구조이다. 이를 통해 사용자는 모델의 출력을 원하는 방향으로 유도할 수 있다.

예:

'If the answer is not in the context, inform the user that you can't answer the question.'등의 프롬프트를 통해서 AI 할루시네이션(Hallucination)을 방지
'answer only in Korean.' 프롬프트를 통해서 한국어로만 답변하도록 설정

프롬프트 템플릿

Spring AI에서는 StringTemplate 라이브러리를 이용해 프롬프트를 동적으로 생성할 수 있다. 예를 들어, 특정 사용자 입력에 따라 맞춤형 프롬프트를 만들 수 있으며, 이 프롬프트는 Spring MVC 아키텍처에서의 "View"와 비슷하게 작동한다.

임베딩(Embeddings)

임베딩은 텍스트, 이미지, 비디오 등의 입력을 벡터로 변환한 숫자 표현이다. 이 벡터는 AI 모델이 의미를 이해하고 서로 다른 입력 간의 유사성을 비교할 수 있게 해준다. 특히 RAG(Retrieval Augmented Generation) 패턴과 같은 실용적인 응용에서 중요한 역할을 한다.

토큰(Tokens)

토큰은 AI 모델에서 입력과 출력을 처리하는 기본 단위이다. 입력된 텍스트는 토큰으로 변환되고, 출력될 때 다시 텍스트로 변환된다. 토큰 수에 따라 비용이 발생하며, API 호출에서 모델이 한 번에 처리할 수 있는 토큰 수에는 제한이 있다. 이를 컨텍스트 윈도우라고 부른다.

구조화된 출력

AI 모델의 출력은 일반적으로 문자열 형태로 제공된다. 하지만 필요할 경우, 특정 형식으로 구조화된 데이터를 얻기 위해 추가적인 프롬프트 구성 및 변환이 필요할 수 있다. Spring AI는 이 과정도 지원한다.

외부 데이터 및 API와의 통합

AI 모델의 데이터셋이 최신 정보까지 포함하지 않는 경우가 많다. 이를 해결하기 위한 방법으로는 파인튜닝, 프롬프트 스터핑, 그리고 함수 호출 같은 기법이 있다. 특히 함수 호출을 통해 AI 모델이 외부 시스템의 실시간 데이터를 활용할 수 있게 한다.

RAG(Retrieval Augmented Generation)

RAG는 AI 모델의 프롬프트에 외부 데이터를 통합하여 더 정확한 응답을 생성하는 기법이다. 이는 벡터 데이터베이스와 결합되어, 유사한 내용을 찾아 프롬프트에 넣고 AI 모델에 전달한다.

함수 호출(Function Calling)

Spring AI는 대형 언어 모델(LLM)이 외부 API와 통신할 수 있도록 함수 호출 기능을 지원한다. 이 기능은 모델이 외부 시스템의 API를 호출하여 필요한 데이터를 실시간으로 처리하게 해준다.

AI 응답 평가

Spring AI는 AI 모델이 생성한 응답을 평가하는 Evaluator API를 제공한다. 이를 통해 생성된 응답의 품질을 확인하고, 사용자 요청과 모델 응답의 일치 여부를 평가할 수 있다.

이 개념들을 바탕으로 Spring AI는 Java 개발자가 AI 기술을 손쉽게 애플리케이션에 통합하고 활용할 수 있는 다양한 도구를 제공하고 있다.

OpenAI API Key 생성

https://platform.openai.com/api-keys에 접속하면 아래와 같은 화면을 확인할 수 있다.

You와 Service account가 있는데 Service account를 선택하는 것이 좋다. 그 이유는

1. 개인 계정(You)을 사용하면 개인의 인증 정보와 애플리케이션의 인증 정보가 혼재되기 때문에, 여러 서비스에서 동일한 API 키를 사용할 때 보안 리스크가 커진다. 반면 Service Account는 애플리케이션에 필요한 최소한의 권한만 부여하여 권한 분리가 명확하게 이루어진다.
2. 애플리케이션의 Service Account를 통해 발급된 Secret Key는 보다 쉽게 관리하고, 필요 시 교체(회전)할 수 있다. 개인 계정의 키를 사용하게 되면 개인이 계정을 변경하거나 보안 이슈가 발생할 때 모든 애플리케이션의 키를 다시 설정해야 하는 번거로움이 있다.

그러므로 Service Account를 사용하자. Account ID는 프로젝트 명으로 하는 것이 좋다.

시크릿키를 만들면 아래와 같이 키가 나오는데, 절대 깃 허브에 올리거나 외부에 노출하지 말아야 한다. 저 키가 노출되는 순간 요금 폭탄이 발생한다고 생각하는게 좋다. 혹시나 노출이 되었다면 즉시 해당 키를 폐기하고 재 발급 받자.

크레딧 충전

모든 OpenAI의 API호출에는 토큰 수 기준으로 과금이 된다.(가격표: https://openai.com/api/pricing/)

물론 OpenAI를 사용하지 않는 방법도 있다.

1. 다른 상업용 AI 모델의 API를 사용 (Google의 Gemini, Meta의 LLaMA 등)
2. 허깅페이스에 있는 모델(https://huggingface.co/models)을 다운받아 직접 로컬로 실행하는 방법 -> 내 컴퓨터가 GPT역할을 해야하므로 성능이 좋아야한다.
3.직접 모델을 만드는 방법.

하지만 이번엔 빠른 Spring AI 사용을 위해 OpenAI API를 사용하자.

다음 링크로 접속하면 Billing 화면이 보인다. https://platform.openai.com/settings/organization/billing/overview

위 화면에서 `Add to credit balance` 버튼을 눌러, 카드 결제를 통해 충전할 수 있다(tax 별도...)

토큰?

앞서 언급했듯이, OpenAI API의 요금은 토큰 수에 따라 부과된다. 참고로, Input 토큰(사용자가 API에 요청할 때 보낸 텍스트의 토큰 수)과 Output 토큰(OpenAI가 해당 요청에 대해 응답으로 생성한 텍스트의 토큰 수) 모두 요금 부과의 대상이다.
토큰에 대한 정확한 기준은 없지만, 영어 텍스트의 경우 대략적으로 4글자가 1토큰으로 계산된다고 알려져있다.

https://platform.openai.com/tokenizer 사이트에 접속하여 테스트를 해보자.

예: Hello, my name is Lee Sujae, and I want to become a good developer.

67자에 19토큰

영어로 입력해보면 토큰화를 비교적 잘 처리한다. 이제 한글을 사용해보자. 한글은 영어에 비해 같은 내용을 표현할 때 글자 수가 적으므로, 토큰 수가 줄어들 것으로 기대할 수 있다.

예: 안녕, 내 이름은 이수재라고 해. 나는 좋은 개발자가 되고싶어.

감히 한글을 써? 너는 1:1 교환이다

그러나 예상과 달리 한글은 더 많은 토큰을 차지한다. 거의 한 글자당 1토큰으로 계산되기 때문에, 비용 효율성을 고려하면 가능하면 영어로 입력하는 것이 좋다.

또한, 문장 부호(‘, . ? 등)도 거의 각각 하나의 토큰으로 계산되므로, 가능하다면 사용하는 것을 줄이는 것이 좋다.

Spring AI 사용 준비가 끝났다.

REFERENCES

Spring AI - https://spring.io/projects/spring-ai

OpenAI API -https://openai.com/api

OAuth2.0이란?

SooJae — Mon, 9 Sep 2024 00:25:15 +0900

OAuth 2.0이란 무엇인가?

OAuth 2.0은 인터넷 애플리케이션이 사용자의 자원에 안전하게 접근할 수 있도록 돕는 인증 및 권한 부여 프레임워크다. 이 프레임워크는 사용자의 민감한 인증 정보를 직접 공유하지 않고, 대신 액세스 토큰을 통해 애플리케이션이 자원에 접근할 수 있게 한다. 이 방식은 특히 클라우드 서비스나 API 통합에서 자주 사용된다.

주요 개념

예:

1. 사용자가 구글 드라이브 API를 사용하는 A라는 서비스에 OAuth2를 통해 가입했다.
2. 사용자는 OAuth2 인증을 거쳐 로그인한 후, 권한 요청 팝업이 표시되었고, 사용자는 구글 드라이브의 자원 접근을 허가했다.
3. 그 결과, A 서비스는 구글 드라이브에서 사용자의 사진을 다운로드할 수 있었다.

1. Resource Owner (자원 소유자)

자원 소유자는 시스템에 저장된 데이터나 리소스의 실제 소유자를 의미한다. 대부분의 경우 자원 소유자는 애플리케이션 사용자다. 이 사용자는 자신의 자원을 제3자 애플리케이션이 접근할 수 있도록 허용한다.

위의 예시 : 사용자 (구글 드라이브에 저장된 사진을 소유하고 있는 사용자)

2. Client (클라이언트)

클라이언트는 자원 소유자를 대신해 자원에 접근하려는 애플리케이션이다. 클라이언트는 사용자의 자원에 직접 접근할 수 없으며, 권한 부여 서버를 통해 권한을 요청한다. 예를 들어, 사용자 데이터에 접근하려는 모바일 앱이나 웹 애플리케이션이 클라이언트에 해당한다.

위의 예시 : A 서비스 (사용자의 구글 드라이브에 접근하여 사진을 다운로드하려는 애플리케이션)

3. Authorization Server (권한 부여 서버)

권한 부여 서버는 자원 소유자로부터 권한을 부여받은 후 클라이언트에게 액세스 토큰을 발급하는 서버다. 이 서버는 클라이언트의 신원을 확인하고, 자원에 접근할 수 있는 권한을 관리한다.

위의 예시: 구글의 OAuth 2.0 권한 부여 서버 (A 서비스에 액세스 토큰을 발급하는 역할)

4. Resource Server (자원 서버)

자원 서버는 클라이언트가 요청하는 자원을 호스팅하는 서버다. 클라이언트가 액세스 토큰을 전달하면, 자원 서버는 해당 클라이언트가 적절한 권한을 갖고 있는지 확인하고 자원에 대한 접근을 허용한다. 자원 서버는 보통 API 서버 형태로 존재한다.

위의 예시 : 구글 드라이브 서버 (사진 파일이 저장된 자원을 관리하는 서버)

권한 부여 방식 (Grant Types)

OAuth 2.0에는 여러 가지 권한 부여 방식이 존재하며, 각각 특정한 시나리오에 맞게 설계되어 있다. 이는 클라이언트가 어떻게 자원 소유자에게 권한을 요청하고, 액세스 토큰을 발급받는지를 정의한다.

1. Authorization Code Grant (인가 코드 방식)

OAuth 2.0에서 가장 널리 사용되는 인증 방식이다. 서버 기반 애플리케이션에서 주로 사용되며, 사용자가 권한 부여를 완료한 후 인가 코드를 클라이언트에게 발급하고, 클라이언트는 이를 이용해 액세스 토큰을 얻는다.
사용 예: 웹 애플리케이션에서 구글, 페이스북과 같은 제3자 인증 서버를 통해 로그인하는 경우.

2. Client Credentials Grant (클라이언트 자격 증명 방식)

사용자가 개입하지 않고, 클라이언트가 자신의 자격 증명을 이용해 액세스 토큰을 요청하는 방식이다. 주로 서버 간 통신에서 사용된다.
사용 예: 백엔드 시스템 간 통신에서 리소스 접근을 제어할 때.

3. Refresh Token Grant (리프레시 토큰 방식)

사용자의 액세스 토큰이 만료되었을 때 리프레시 토큰을 사용해 새로운 액세스 토큰을 발급받는 방식이다. 이를 통해 사용자는 다시 인증하지 않아도 기존 권한을 계속 유지할 수 있다.
사용 예: 세션을 유지하면서 사용자에게 추가 인증을 요구하지 않도록 하는 경우.

4. Password Grant (패스워드 방식)

사용자가 클라이언트에 직접 아이디와 비밀번호를 제공해 인증을 처리하는 방식이다. 보안상의 위험 때문에 권장되지 않으며, 대부분의 경우 사용이 지양된다.
사용 예: 레거시 시스템이나 간단한 내부 애플리케이션에서 사용될 수 있지만, 현재는 거의 사용되지 않는다.

5. Device Authorization Grant (디바이스 코드 방식)

사용자가 UI가 제한된 디바이스에서 인증할 때 사용하는 방식이다. 사용자는 다른 디바이스에서 웹 브라우저를 통해 권한 부여 절차를 완료하고, 디바이스는 디바이스 코드를 사용해 액세스 토큰을 받는다.
사용 예: 스마트 TV나 게임 콘솔 같은 제한된 디바이스에서 사용자가 인증할 때. 맥북으로 스마트 TV를 미러링 할때 입력하는 4자리 값

6. Implicit Grant (암시적 방식)

클라이언트가 액세스 토큰을 바로 받는 방식으로, 주로 클라이언트 애플리케이션이 브라우저에서 실행되는 경우 사용됩니다. 보안 문제로 OAuth 2.1에서는 사용이 권장되지 않으며, 대부분의 경우 Authorization Code Grant로 대체된다.
사용 예: 과거에 주로 사용되었으나 현재는 거의 사용되지 않는 방식.

OAuth 2.0의 장점

1. 보안 강화

OAuth 2.0은 자원 소유자의 민감한 자격 증명을 클라이언트 애플리케이션과 직접 공유하지 않고, 액세스 토큰을 사용해 자원에 접근할 수 있도록 한다. 이렇게 하면 자격 증명 유출 위험을 줄이고, 토큰의 만료나 리프레시를 통해 보안을 추가적으로 강화할 수 있다.

2. 유연성

OAuth 2.0은 다양한 인증 흐름을 제공하여, 웹 애플리케이션, 모바일 앱, 서버 간 통신 등 여러 상황에 맞게 사용할 수 있다. 각 흐름은 특정한 사용 사례에 맞게 설계되어 있어, 상황에 맞는 최적의 인증 방식을 선택할 수 있다.

3. 확장성

OAuth 2.0은 다양한 클라이언트와 서비스 간의 인증 및 권한 부여 과정을 쉽게 확장할 수 있는 프레임워크다. 예를 들어, 하나의 인증 서버를 통해 여러 애플리케이션이 공통으로 인증 및 권한 부여 절차를 사용할 수 있다. 이를 통해 복잡한 통합 시나리오에서도 일관된 방식으로 사용자 인증을 처리할 수 있다.

4. 서드파티 애플리케이션 통합

OAuth 2.0은 서드파티 애플리케이션이 사용자의 자원에 안전하게 접근할 수 있도록 하는 표준화된 방식을 제공한다. 이를 통해 사용자는 신뢰하는 서드파티 애플리케이션이 자신을 대신해 자원에 접근하도록 허용할 수 있다. 이 과정에서 사용자는 자신의 자격 증명을 제공하지 않고도, 특정한 자원에 대한 접근 권한만을 안전하게 위임할 수 있다.

활용 사례

소셜 로그인: 사용자들이 페이스북, 구글, 트위터 등 소셜 미디어 계정을 사용해 다른 서비스에 로그인할 수 있는 기능이 OAuth 2.0을 통해 구현된다. 사용자는 별도의 아이디와 비밀번호를 생성하지 않고, 기존의 소셜 계정을 통해 권한을 위임받아 다양한 애플리케이션에 로그인할 수 있다.
API 접근 제어: 많은 서비스가 외부 애플리케이션이나 파트너가 자신들의 API를 통해 데이터를 요청할 수 있도록 한다. 이때 OAuth 2.0을 사용하여 외부 애플리케이션이 API에 접근할 수 있는 권한을 안전하게 부여할 수 있다.
클라우드 서비스 통합: 다양한 클라우드 서비스 간의 데이터 통합이나 상호작용을 가능하게 한다. 예를 들어, 구글 드라이브에 저장된 파일을 다른 서비스에서 접근할 때 OAuth 2.0을 통해 구글 계정 자격 증명을 사용하지 않고도 안전하게 파일에 접근할 수 있다.

결론

OAuth 2.0은 다양한 인터넷 서비스 간의 안전한 인증 및 권한 부여를 제공하는 강력한 프레임워크다. 이 프로토콜을 사용하면 클라이언트 애플리케이션이 사용자의 자원에 안전하게 접근할 수 있으며, 여러 상황에 맞춘 유연한 인증 흐름을 통해 각 서비스 간의 통합을 쉽게 확장할 수 있다. OAuth 2.0을 도입하면 애플리케이션의 보안을 강화하고, 사용자 경험을 개선할 수 있는 중요한 인증 방식이 될 수 있다.

REFERENCES

- ChatGPT

해싱(Hashing)과 일반 해시 함수(non-cryptographic hash function)

SooJae — Wed, 28 Aug 2024 02:00:01 +0900

해싱

해싱(Hashing)은 가변 길이의 입력 데이터를 받아서 고정 길이의 출력 값으로 변환하는 과정을 의미한다. 이때 생성된 고정된 크기의 값은 해시 값 또는 다이제스트(digest)라고 불리며, 원본 데이터와는 크기나 형식이 다르다. 해싱은 데이터의 무결성 검증, 빠른 데이터 검색, 비밀번호 저장 등 다양한 목적으로 사용된다.

특징

단방향성: 해싱은 단방향 함수이다. 즉, 원본 데이터를 해시 값으로 변환할 수는 있지만, 반대로 해시 값에서 원본 데이터를 복원하는 것은 불가능하다. 이 때문에 해싱은 암호화와는 다르며, 주로 데이터의 무결성을 확인하는 데 사용된다.
고유성(충돌 저항성): 서로 다른 입력값이 동일한 해시 값을 생성할 확률은 매우 낮다. 이를 충돌 저항성이라고 하며, 이 특성 덕분에 해싱은 데이터의 무결성을 검증하는 데 유용하다. 이상적으로는 해시 함수는 서로 다른 두 개의 입력값이 동일한 해시 값을 생성하지 않도록 설계된다.
고정된 출력 크기: 해시 함수는 입력 데이터의 크기와 상관없이 항상 고정된 크기의 해시 값을 생성한다. 예를 들어, SHA-256 해시 함수는 256비트 크기의 해시 값을 생성한다.
빠른 계산: 해시 함수는 계산이 빠르고, 입력 데이터가 크더라도 해시 값을 빠르게 생성할 수 있다. 이 특징은 해싱이 대규모 데이터 처리나 빠른 검색 기능에 사용되는 이유 중 하나이다.

다음 해시 함수를 살펴보자.

public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        char val[] = value;
        for (int i = 0; i < value.length; i++) {
            h = 31 * h + val[i];
        }
        hash = h;
    }
    return h;
}

Effective Java에서 Joshua Bloch는 값 31이 홀수와 소수이기 때문에 의도적으로 선택되었다고 설명한다.

해시와 홀수

해시 곱셈 상수를 짝수로 곱했을 경우와 홀수로 곱했을 경우의 차이를 비교해보자.

짝수를 곱할 때

숫자 5(이진수 101)를 짝수 2로 곱하면 10(이진수 1010)이 된다.
숫자 6(이진수 110)을 짝수 2로 곱하면 12(이진수 1100)이 된다.
짝수를 곱할 시 마지막 비트가 항상 0이 되므로, 표현 가능한 숫자 범위의 절반 밖에 사용하지 못한다. 그래서 같은 해시 값, 즉 해시 충돌이 일어날 가능성이 높아진다.

홀수를 곱할 때

숫자 5(이진수 101)를 홀수 3으로 곱하면 15(이진수 1111)가 된다.
숫자 6(이진수 110)을 홀수 3으로 곱하면 18(이진수 10010)이 된다.
마지막 비트까지 전부 사용할 수 있다. 그러므로 서로 다른 해시 값을 가질 가능성이 높아지고, 충돌이 줄어든다.

해시와 소수(prime number)

소수는 1과 자기 자신 외에는 나눌 수 없는 수. 소수는 약수가 적기 때문에 해시 코드 생성 시 충돌을 줄이는 데 도움이 된다. 즉, 해시 함수에서 소수를 사용하면 해시 값의 분포가 더 고르게 퍼지게 되어, 서로 다른 입력값이 같은 해시 값을 가질 확률이 낮아진다.

이외에 해쉬 곱셈 상수 31을 사용하는 이유 중 하나로 31이 2^5 - 1이어서 쉬프트 연산을 통해 (N << 5) - N과 같이 속도를 개선할 수 있다고 한다. 그렇다면 31(홀수 + 상수 + 쉬프트 연산)과 19(홀수 + 상수)사이에 실제로 속도 차이가 있을까? 1억번씩 호출하여 비교해보자.

해시 곱셈 상수 31 vs 19 속도 비교

package org.example;

public class HashTestMain {

  // 해시 상수 31을 사용하는 클래스
  static class HashWith31 {
    private String value;

    public HashWith31(String value) {
      this.value = value;
    }

    @Override
    public int hashCode() {
      int result = 1;
      result = 31 * result + (value != null ? value.hashCode() : 0);
      return result;
    }
  }

  // 해시 상수 19를 사용하는 클래스
  static class HashWith19 {
    private String value;

    public HashWith19(String value) {
      this.value = value;
    }

    @Override
    public int hashCode() {
      int result = 1;
      result = 19 * result + (value != null ? value.hashCode() : 0);
      return result;
    }
  }

  public static void main(String[] args) {
    // 테스트할 문자열
    String testString = "This is a test string for hashCode performance measurement.";

    // 반복 횟수
    int iterations = 100_000_000;

    // HashWith19 클래스의 속도 측정
    HashWith19 hash19 = new HashWith19(testString);
    long startTime19 = System.nanoTime();
    int hash19Result = 0;
    for (int i = 0; i < iterations; i++) {
      hash19Result = hash19.hashCode() + i; // 캐싱 방지를 위해 i를 더함
    }
    long endTime19 = System.nanoTime();
    long totalTime19 = endTime19 - startTime19;

    // HashWith31 클래스의 속도 측정
    HashWith31 hash31 = new HashWith31(testString);
    long startTime31 = System.nanoTime();
    int hash31Result = 0;
    for (int i = 0; i < iterations; i++) {
      hash31Result = hash31.hashCode() + i; // 캐싱 방지를 위해 i를 더함
    }
    long endTime31 = System.nanoTime();
    long totalTime31 = endTime31 - startTime31;

    System.out.println("Hash 곱셈 상수 19를 사용했을 때 총 시간: " + totalTime19 + " nanoseconds");
    System.out.println("Hash 곱셈 상수 31을 사용했을 때 총 시간: " + totalTime31 + " nanoseconds");
  }
}

실행 시에는 19와 31 각각 주석처리를 하고 독립적으로 실행하였다. 결과는 다음과 같다.

해쉬 곱셈 상수가 19일 때 오히려 더 빠르다. 여러 번 테스트해본 결과, 31이 더 빠를 때도 있지만 차이는 크지 않다. 컴퓨터의 성능이 향상된 덕분인지, 이제는 31을 사용한다고 속도가 개선된다는 것은 과거의 이야기인 것 같다.

HashCode()

hashCode() 메서드의 실제 동작을 살펴보자.

public static void main(String[] args) {
    String anotherTest = "java";
    String test = "test";
    String oneMoreTest = "dev";
    System.out.println(test.hashCode()); // output: 3556498
    System.out.println(test.hashCode()); // output: 3556498
    System.out.println(anotherTest.hashCode()); // output: 3254818
    System.out.println(oneMoreTest.hashCode()); // output: 99349
}

결과를 보면 해시 함수 특징을 알 수 있다.

hashCode() 호출은 단방향 연산으로, 생성된 해시 값만으로는 원래 문자열을 복구할 수 없다.
결정론적이다. 동일한 변수를 두 번 호출했을 때, 동일한 해시 값을 반환한다.
Java의 int는 32비트(4바이트)의 고정된 크기를 가진다. 즉 hashCode()메서드가 반환하는 해시 값(int 형태)도 항상 32비트의 고정된 길이다.

일반 해시 함수?

일반 해시 함수(Non-cryptographic hash function)는 보안 목적으로 설계되지 않은 해시 함수로, 주로 데이터 검색, 해시 테이블, 체크섬과 같은 용도에 사용된다. 일반 해시 함수는 빠른 계산 속도와 충돌을 적절히 처리할 수 있는 성능을 중시하지만, 암호화 수준의 보안성을 제공하지는 않는다.

특징

빠른 계산: 일반 해시 함수는 보안성을 고려하지 않기 때문에, 매우 빠르게 계산할 수 있다. 이는 대규모 데이터 집합에서 효율적으로 사용할 수 있도록 설계된 것이다.
충돌 허용: 일반 해시 함수는 보안보다는 성능에 중점을 두므로, 충돌이 발생할 가능성이 있을 수 있다. 그러나 이러한 충돌은 일반적으로 해시 테이블에서 적절히 처리될 수 있다.
용도: 일반 해시 함수는 데이터베이스 검색, 파일 무결성 확인, 분산 시스템에서의 데이터 균형 맞추기 등 비보안적인 용도로 주로 사용된다.

예시

MurmurHash: 매우 빠르고 충돌이 적은 해시 함수로, 주로 해시 테이블에서 사용된다.
CityHash: 구글에서 개발한 해시 함수로, 매우 빠르면서도 높은 성능을 제공한다.
DJB2: 단순하고 빠르며, 자주 사용되는 해시 함수 중 하나이다.

References

Java HashMap은 어떻게 동작하는가? - https://d2.naver.com/helloworld/831311

Deep Dive into Hasing - https://www.baeldung.com/cs/hashing

[K8S] labels, selector, matchLabels에 대하여

SooJae — Thu, 6 Jul 2023 20:47:19 +0900

개인적으로 공부한 내용을 작성한 게시글입니다. 잘못된 내용이 있을 수 있습니다.
틀린 부분을 알려주시면 바로 고치겠습니다.감사합니다.

쿠버네티스 리소스의 Manifest 파일들을 작성하다보면 많은 labels, matchLabels, selectors 필드들을 볼 수 있다.
이번 포스팅을 통해 이들을 정리해보려고 한다.

Selector

Deployment

우선 Deployment의 Manifest 파일을 살펴보자

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
      track: stable
    matchExpressions:
      - {key: tier, operator: In, values: [backend, backend2, backend3]}
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
        tier: backend
        track: stable
    spec:
      containers:
        - name: hello
          image: "gcr.io/google-samples/hello-go-gke:1.0"
          ports:
            - name: http
              containerPort: 80

`metadata`필드의 `labels`필드는 Deployment자체의 label 정보를 의미한다.
`selector`필드의 `matchLabels`와 `matchExpressions`필드는 배포할 Pod의 labels를 가리킨다.
`matchLabels`와 `matchExpressions`는 각각의 필드에 AND(&&) 연산자가 사용되고, `matchLabels`와 `matchExpressions` 끼리도 AND(&&) 연산자가 사용된다.
`template`필드부터는 사실 Pod의 metadata라고 생각하면 된다. 그래서 `template`필드의 `labels`필드는 Deployment의 label 정보가 아닌 Pod의 자체의 label 정보이다.
그래서 꼭 `selector.matchLabels`와 `template.metadata.labels`는 일치해야 한다!
라벨을 지정하면 다음 커맨드로 해당 라벨이 존재하는 리소스들을 조회할 수 있다. `$ kubectl get <resource> -l <label>`

Service

이제 Service의 Manifest 파일을 살펴보자

apiVersion: v1
kind: Service
metadata:
  name: hello
  labels:
    app: hello
spec:
  selector: # matchLabels가 존재하지 않는다.
    app: hello
    tier: backend
  ports:
  - protocol: TCP
    port: 80
    targetPort: http

`metadata`필드의 `labels`필드는 Service의 label 정보를 의미한다.
`selector`필드는 해당 값의 label을 가진 Pod들을 Service 대상으로 지정한다.
`matchLabels`필드와 `matchExpressions`필드가 존재하지 않는다.

위에서 확인할 수 있듯이 `matchLabels`, `matchExpresisons` 필드가 Service에는 존재하지 않는다. 대신 `selector`필드만으로도 `matchLabels`처럼 동작한다.
사실 Deployment뿐만 아니라 Job, ReplicaSet, 그리고 DaemonSet에서도 `matchLabels`, `matchExpressions`필드가 있다.

그렇다면 왜 Service만 matchLabels, matchExpressions 필드가 없을까?

내 개인적인 생각은 Job, Deployment, ReplicaSet, DaemonSet은 다양한 Pod들을 생성하거나 직접적으로 제어해야 하기 때문에 `matchExpressions`를 사용한다고 생각한다.

반면에, Service는 네트워크 요청을 기존에 존재하고, 동일한 역할을 수행하는 Pod들에 라우팅 하는 것이기 때문에, 라벨을 명확하게 정하는 것이 좀 더 안정적일 것이다.
그래서 `matchExpressions`를 삭제하고, `selector` 만으로 `matchLabels` 역할을 하도록 한 것이 아닐까 생각한다. (괜히 matchLabels가 존재하면, matchExpressions 기능도 있을 것이라 생각하여 작성할 수 있으므로)

ETC

Equality-based, Set-based Requirement

사실 위의 `matchLabels`는 Equality-based requirement(동등 기반 요구)방식, `matchExpression`는 Set-based Requirement(집합 기만 요구)이다.

API는 현재 Equality-based, Set-based이라는 두 가지 유형의 selector를 지원한다. label selector는 쉼표로 여러 label을 선택할 수 있는데, 이때 쉼표는 AND(&&) 연산자 역할을 한다. OR(||) 연산자는 존재하지 않는다.

Equality-based requirement

Equality-based 또는 InEquality-based requirements를 통해 label의 keys와 values로 필터링할 수 있다. `=, ==, !=` 연산자를 이용하여 필터링할 수 있다. `=`, `==` 은 둘 다 동등함을 의미한다.

Set-based requirement

Set-based label requirements는 values 집합에 따라 keys를 필터링할 수 있다. in, notin 그리고 exists (키 식별자만) 연산자를 이용하여 필터링할 수 있다.

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
partition,environment notin (qa)

첫 번째는 key가 `environment`일 경우, value가 `production` 또는 `qa`인 label을 필터링한다.
두 번째는 key가 `tier`일 경우, value가 `frontend`, `backend`가 아닌 label을 필터링한다
세 번째는 value를 체크하지 않는다. 오직 `partition`인 key가 있는 label을 필터링한다.
네 번째도 value를 체크하지 않는다. 오직 `partition`가 아닌 key가 있는 label을 필터링한다.
다섯 번째는 key가 `partition` 또는 `environment`일 때 value가 `qa`가 아닌 key가 있는 label을 필터링한다.

따라서, Service 리소스는 Equality-based selector를 사용하는 반면, 나머지 리소스들은 Equality-based selector와 Set-based selector 모두 사용한다는 것을 알 수 있다.

labels 작성 예시

release : "stable", "canary"
environment : "dev", "qa", "production"
tier : "frontend", "backend", "cache"
partition : "customerA", "customerB"
track : "daily", "weekly"

REFERENCES

Assigning Pods to Nodes - https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/

Labels and Selectors - https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

[K8S] 쿠버네티스를 이용하여 Elasticsearch, Kibana, Logstash 배포 (with helm)

SooJae — Tue, 6 Jun 2023 01:31:42 +0900

개인적으로 공부한 내용을 작성한 게시글입니다. 잘못된 내용이 있을 수 있습니다.
틀린 부분을 알려주시면 바로 고치겠습니다. 감사합니다.

이제 K8S 이용하여 Elasticsearch를 배포해 보자. Helm이라는 패키징 툴을 이용해서 배포할 것이다.

Helm 이란

쿠버네티스를 통해 애플리케이션을 배포하기 위해서는 많은 리소스들이 필요하다. 대표적으로 Pod, Deployment, Statefulset, DaemonSet, Service, ConfigMap, Secret, PersistentVolume, PersistentVolumeClaim, Ingress 등등
위의 리소스들의 템플릿은 비슷한데, 배포하기 위해서는 애플리케이션마다 모두 yaml파일을 만들어야 하고, 관리를 해줘야 한다.

그에 반해 helm을 이용하면 공통적인 템플릿을 만들어 Value 값만 바꿔가며 환경, 프로젝트에 따라 다양하게 설정할 수 있어 관리가 용이해진다.

`$ brew install helm` 를 통해 helm을 설치할 수 있다.

elasticsearch 배포

bitnami의 elasticsearch에서 제공하는 values.yaml 파일의 설정을 사용하여 배포해 보자. `-f values.yaml` 옵션은 helm 차트를 values.yaml 파일의 값으로 커스터마이징 하라는 뜻이다.
이를 통해 stage환경에서는 `values_stage.yaml`, production 환경에서는 `values_production.yaml` 등의 파일을 따로 만들어서 환경에 따라 쉽게 설정을 적용할 수 있다.

values.yaml 다운로드

$ helm repo add bitnami https://charts.bitnami.com/bitnami

$ helm repo update

$ helm search repo -l bitnami/elasticsearch | head

$ wget https://raw.githubusercontent.com/bitnami/charts/master/bitnami/elasticsearch/values.yaml

배포

# jerry라는 네임스페이스 생성
$ kubectl create namespace jerry

# values.yaml 파일을 이용하여 my-elasticsearch 라는 이름의 애플리케이션 배포
$ helm install my-elasticsearch -f values.yaml --set sysctlImage.enabled=true -n jerry bitnami/elasticsearch

배포에 성공하면 아래와 같은 메시지가 나온다.

~~$ kubectl get pods -n jerry~~ 로 pods이 정상적으로 동작하는 것을 확인할 수 있다.

`$ kubectl port-forward -n jerry svc/my-elasticsearch 9200:9200 &` 커맨드를 통해 쿠버네티스 클러스터 내부의 서비스를 로컬 머신에서 직접 접근할 수 있도록 port-forwading 해준다.

`$ curl localhost:9200` 커맨드를 입력하면 elasticsearch을 정상적으로 호출되는 것을 확인할 수 있다.

추가로 kibana와 logstash도 배포해 보자.
이번에는 values.yaml 파일없이 bitnami에서 설정한 default 값을 사용하고, elasticsearch에 연결하기 위해 호스트 값과 포트번호만 set 옵션을 통해 바꿔보자.

kibana 배포

helm install my-kibana oci://registry-1.docker.io/bitnamicharts/kibana \
  --set "elasticsearch.hosts[0]=elasticsearch.jerry.svc.cluster.local" \
  --set elasticsearch.port=9200 \
-n jerry

logstash 배포

helm install my-logstash bitnami/logstash \
  --set elasticsearch.host=my-elasticsearch-master.jerry.svc.cluster.local \
  --set elasticsearch.port=9200 \
-n jerry

아래는 모든 배포된 애플리케이션의 리소스 들이다.

ETC

위에서는 공식 elasticsearch 이미지가 아닌 bitnami/elasticsearch 이미지를 사용했다.

Docker

hub.docker.com

Bitnami와 Official 이미지의 차이점

초기 설정 - BItnami는 애플리케이션에 배포와 설정을 단순화하는데 중점을 두고 있다. 실제 서비스에 적용하기 위한 기본 보안 설정 등이 이루어져 있다. 반면 공식 이미지는 사용자가 환경에 맞게 설정을 수정해야 할 수도 있다.
보안 설정: Bitnami는 보안에 많은 중점을 둔다. 이는 초기 설정에서부터 사용자가 적절한 보안 구성을 가지도록 도와준다.
유지 보수와 업데이트 - Bitnami와 공식 이미지 모두 자체 업데이트와 유지 보수 메커니즘이 있지만, Bitnami는 더욱 체계적인 프로세스를 가지고 있다.
커스텀: Bitnami의 경우 공식 이미지에 비해 사용자의 커스텀 설정이 제한적일 수 있다.
공식 지원 불가: Bitnami 이미지는 공식 개발자가 지원하지 않기 때문에, 문제 발생 시 Bitnami 커뮤니티나 Bitnami 지원 팀에 의존해야 할 수 있다.

References

bitnami elasticsearch 배포 - https://itsmetommy.com/2020/06/10/kubernetes-install-bitnami-elasticsearch-kibana-using-helm/

bitnami에서 values_procduction.yaml의 지원 중단 - https://github.com/bitnami/charts/issues/5095

[K8S] MacOS M2 환경 쿠버네티스 설치 (Docker Desktop)

SooJae — Mon, 29 May 2023 14:38:35 +0900

이번 시간에는 Kubernetes를 Docker Desktop를 사용하여 로컬환경에 설치하려고 한다. 이는 Lightweight Kubernetes Distributions 이라고 불리며 보통 개발과 테스트 환경에서 사용된다.

Lightweight Kubernetes Distributions에는 Docker Desktop 이외에 Minikube, MicroK8S, Kind, K3S등이 있다. 아래 링크에 들의 비교글이 있다.

https://www.baeldung.com/ops/kubernetes-lightweight-distributions#comparison

설치

1. 우선 Docker-desktop을 설치하자. 아래 링크로 들어가 Apple Chip 버전을 다운로드 후 설치하면 된다.

Download Docker Desktop | Docker

Docker Desktop is available to download for free on Mac, Windows, or Linux operating systems. Get started with Docker today!

www.docker.com

2. 설치된 Docker Desktop을 실행 후 메인 화면에서 설정 아이콘을 클릭

3. 설정 화면에서 Kubernetes 탭을선택하고 Enable Kubernetes를 체크한 후 재 시작한다.

4. ~~$ kubectl get all~~ 커맨드를 입력하면 정상적으로 설치된 것을 확인할 수 있다.

References

Lightweight Kubernetes Distributions이란 - https://www.baeldung.com/ops/kubernetes-lightweight-distributions

프론트엔드 구현 세부 사항 테스트

SooJae — Tue, 14 Mar 2023 03:31:46 +0900

이 글은 Kent C. Dodds의 Testing Implementation Details 포스트를 번역한 글입니다.

Thank you Kent C. Dodds. Because of your posts, I can continue to grow as an engineer.

이전에 enzyme를 사용할 때 (그 시절 모두가 사용했던 것처럼), 나는 enzyme의 특정 API를 신경 써서 사용했다. shallow rendering를 완전히 피하기 위해, `instance()`, `state()`, `find('컴포넌트이름')`와 같은 API를 사용하지 않았다. 그리고 다른 사람들의 풀 리퀘스트 코드를 검토할 때, 왜 이런 API들을 피해야 하는지에 대해 몇 번이고 설명했다.
그 이유는 이런 API들이 컴포넌트의 `구현 세부 사항`을 테스트하도록 만들기 때문이다.

사람들은 종종 '`구현 세부 사항`'이 무엇을 의미하는지 묻는다. 나는 '테스트를 더 어렵게 만드는 것'이라는 뜻으로 사용한다.

`구현 세부 사항` 테스트는 왜 나쁜가?

`구현 세부 사항`을 테스트해서는 안 되는 두 가지 큰 이유가 있다.

리팩터링만 했을 뿐인데 테스트 실패. False Negative
코드의 로직이 변경되어 정상적으로 동작하지 않음에도 테스트가 성공. False Positive

명확하게 말하자면, 테스트는 "소프트웨어가 작동하는지 확인하는 것"을 의미한다. 테스트가 성공하면 테스트는 "positive"(소프트웨어가 작동함) 임을 의미한다. 그렇지 않으면 테스트는 "Negative"(소프트웨어가 작동하지 않음)가 되었다는 것을 의미한다. "False"라는 용어는 테스트에서 잘못된 결과가 나왔다는 것을 의미한다.
즉, 소프트웨어가 실제로는 고장이 났지만 테스트는 성공(False Positive)하거나, 소프트웨어가 실제로는 작동하지만 테스트는 실패한 경우(False Negative)를 의미한다.

아래의 간단한 Accordion 컴포넌트를 예로 들어 각 컴포넌트들을 살펴보자

// accordion.js
import * as React from 'react'
import AccordionContents from './accordion-contents'

class Accordion extends React.Component {
  state = {openIndex: 0}
  setOpenIndex = openIndex => this.setState({openIndex})
  render() {
    const {openIndex} = this.state
    return (
      <div>
        {this.props.items.map((item, index) => (
          <>
            <button onClick={() => this.setOpenIndex(index)}>
              {item.title}
            </button>
            {index === openIndex ? (
              <AccordionContents>{item.contents}</AccordionContents>
            ) : null}
          </>
        ))}
      </div>
    )
  }
}

export default Accordion

위의 예제에서 왜 최신 함수 컴포넌트(with hook)가 아닌 구식 클래스 컴포넌트를 사용하는지 궁금하겠지만, 계속 읽다 보면 흥미로운 사실을 깨달을 것이다. (enzyme를 알면 이미 예상하고 있을 수도 있다.)

다음은 `구현 세부 사항`을 테스트하는 코드다:

// __tests__/accordion.enzyme.js
import * as React from 'react'
// shadow render를 사용하지 않는 이유 
// https://kcd.im/shallow
import Enzyme, {mount} from 'enzyme'
import EnzymeAdapter from 'enzyme-adapter-react-16'
import Accordion from '../accordion'

// enzyme 리액트 어댑터 설치
Enzyme.configure({adapter: new EnzymeAdapter()})

test('setOpenIndex sets the open index state properly', () => {
  const wrapper = mount(<Accordion items={[]} />)
  expect(wrapper.state('openIndex')).toBe(0)
  wrapper.instance().setOpenIndex(1)
  expect(wrapper.state('openIndex')).toBe(1)
})

test('Accordion renders AccordionContents with the item contents', () => {
  const hats = {title: 'Favorite Hats', contents: 'Fedoras are classy'}
  const footware = {
    title: 'Favorite Footware',
    contents: 'Flipflops are the best',
  }
  const wrapper = mount(<Accordion items={[hats, footware]} />)
  expect(wrapper.find('AccordionContents').props().children).toBe(hats.contents)
})

자신의 코드베이스에서 위와 같은 테스트를 본(혹은 작성한)적이 있다면 손을 들어보자( ).

OK. 이제 이 테스트가 어떤 문제를 일으키는지 살펴보자...

리팩터링시 False Nagatives

의외로 많은 사람들이 테스트, 특히 UI 테스트를 싫어한다. 왜 그럴까? 여러 가지 이유가 있지만, 내가 반복해서 듣는 한 가지 큰 이유는 테스트를 돌보는 데 너무 많은 시간을 소비하기 때문이다. "코드를 변경할 때마다 테스트가 실패한다!" 이는 생산성에 큰 걸림돌이 된다.
우리의 테스트가 왜 이런 짜증나는 문제를 일으키는지 살펴보자.

위의 Accordion을 여러 개의 Accordion이 한 번에 열 수 있도록 리팩터링 해보자. 리팩터링은 구현만 변경하고, 기존 동작은 전혀 변경하지 않는 것을 말한다. 따라서 동작을 변경하지 않도록 구현을 변경해 보자.

여러 Accordion 요소를 한 번에 열 수 있도록 내부 상태를 `openIndex`에서 `openIndexes`로 변경해 보자.

좋아, 앱에서 간단히 확인해 보니 모든 것이 여전히 제대로 작동하는 것으로 나타났다. 이제 나중에 여러 개의 Accordion을 여는 기능을 컴포넌트에 쉽게 추가할 수 있을 것 같다!
이제 테스트를 해보자! 펑 이런, 테스트가 실패했다. 어느 테스트가 실패한 걸까? `setOpenIndex sets the open index state properly.` 테스트가 실패했다.

에러 메시지 내용은?

expect(received).toBe(expected)

Expected value to be (using ===):
  0
Received:
  undefined

위의 테스트 실패가 실제 컴포넌트의 문제에 대해 경고하는 건가? 아니다! 컴포넌트는 여전히 정상적으로 작동한다.

이를 False Negative라고 한다. 애플리케이션 코드에 문제가 생긴 것이 아니라, 테스트 코드에 문제가 생겼기 때문에 테스트가 실패한 것을 의미한다. 솔직히 이런 상황이 테스트에서 제일 짜증 난다. 자, 테스트 코드를 수정해 보자.

결론: `구현 세부 사항`을 테스트하는 이러한 테스트 케이스에는 리팩터링 시 False Negative를 줄 수 있다. 그 결과 유지 관리가 어렵고 성가신 테스트 코드가 많이 생성된다.

False Positives

이제 동료가 Accordion 컴포넌트 작업을 하다가 다음과 같은 코드를 발견했다고 가정해 보자.

<button onClick={() => this.setOpenIndex(index)}>{item.title}</button>

그는 금방이라도 최적화 하고 싶은 마음에 "그래, render 함수 내부의 인라인 화살표 함수는 성능이 좋지 않으니, 리팩터링 해야겠다! 제대로 동작할 것 같은데, 빠르게 고치고 테스트해보자."라고 생각한다.

<button onClick={this.setOpenIndex}>{item.title}</button>

Cool. 테스트를 실행해보니... ✅✅ 완벽하다! 테스트에 대해 매우 확신하기 때문에 따로 브라우저에서 확인하지 않고 코드를 커밋했다. 이 커밋은 아무런 관련이 없는 PR(Pull Request)과 섞여 있고, 이 PR에는 수천 줄의 코드가 포함되어 있어 눈에 띄지 않게 된다.
결국 운영 환경에서 Accordion 기능이 고장 나게 되고, Nancy는 Salt Lake에서 다가오는 2월의 위키드 공연을 가지 못해 울고 있고, 당신의 팀은 기분이 좋지 않다 (※ 역자 주: 에러 코드를 찾고 수정하느라 공연을 보러 가지 못하고, 팀원들도 마찬가지...)

그렇다면 무엇이 잘못된 걸까? `setOpenIndex`가 호출될 때 상태가 변경되고 Accordion의 내용이 적절하게 표시되는지 확인하는 테스트가 없었나? 아니, 해당 기능의 테스트가 있었다!
하지만 문제는 `button`이 `setOpenIndex`에 올바르게 연결되었는지 확인하는 테스트가 없었다는 것이다.

이것을 False Positive라고 부른다. 이는 테스트는 성공했지만, 원래는 실패했어야 한다는 뜻이다! 어떻게 하면 재발을 방지할 수 있을까? 버튼 클릭 시 상태가 올바르게 업데이트되는지 확인하기 위한 또 다른 테스트를 추가해야 한다. 그리고 다시는 이런 실수를 반복하지 않도록 Code Coverage를 항상 100%로 유지해야 한다.
아, 그리고 ESLint 플러그인을 많이 만들어서 사람들이 구현 세부 사항을 테스트 하는 API를 사용하지 않도록 막아야 한다.

... 하지만 너무 귀찮다... 우리는 False Positive와 False Negative에 지쳐버린 상태다. 거의 테스트를 작성하지 않는 것이 더 좋을 것 같다. 모든 테스트를 삭제해 버리자!
만약 더 넓은 성공 구덩이(pit of success) (※역자 주: 구덩이의 절벽은 U자 형태로 되어있으니 올라가는 것(실패)은 어렵고 떨어지는 것(성공)은 쉽다. 즉 잘 만든 시스템일수록 성공하기는 쉽고, 실패하기는 오히려 어렵다는 뜻.)를 가진 도구가 있으면 좋지 않을까? 물론이지! 그런 도구가 있다!

`구현 세부 사항`이 없는 테스트

우리는 `구현 세부 사항`을 테스트하지 않도록 API를 제한하면서 Enzyme의 모든 테스트를 다시 작성할 수 있지만, React Testing Library 라이브러리를 사용하면 `구현 세부 사항`을 테스트하는 것이 애초에 어렵기 때문에, 이 라이브러리를 사용하기로 한다. 지금 바로 확인해 보자!

// __tests__/accordion.rtl.js
import '@testing-library/jest-dom/extend-expect'
import * as React from 'react'
import {render, screen} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import Accordion from '../accordion'

test('can open accordion items to see the contents', () => {
  const hats = {title: 'Favorite Hats', contents: 'Fedoras are classy'}
  const footware = {
    title: 'Favorite Footware',
    contents: 'Flipflops are the best',
  }
  render(<Accordion items={[hats, footware]} />)

  expect(screen.getByText(hats.contents)).toBeInTheDocument()
  expect(screen.queryByText(footware.contents)).not.toBeInTheDocument()

  userEvent.click(screen.getByText(footware.title))

  expect(screen.getByText(footware.contents)).toBeInTheDocument()
  expect(screen.queryByText(hats.contents)).not.toBeInTheDocument()
})

좋아. 하나의 테스트에서 모든 동작을 성공적으로 검증할 수 있다. 또한 이 테스트는 내부 상태의 이름이 `openIndex`, `openIndexes`, `tacosAreTasty` 중 어느 것이든 상관없이 성공한다. Nice! False Negative를 해결했다!
또한 클릭 핸들러가 제대로 연결되지 않은 경우에 테스트가 실패한다. 이러면 False Positive도 해결된다. 그리고 어떤 API를 사용하면 안 되는지를 기억할 필요도 없다. React Testing Library를 정상적으로 사용하기만 하면, Accordion 컴포넌트가 사용자가 원하는 대로 작동하고 있다는 확신을 가질 수 있는 테스트를 얻을 수 있다.

그럼... `구현 세부 사항`은 정확히 뭐야?

간단하게 정의하자면 다음과 같다.

구현 세부 사항은 사용자가 사용하거나 보거나 이해하지 못하는 사항이다.

우리가 답해야 할 첫 번째 질문은 "우리 코드의 사용자는 누구인가?"다.
브라우저에서 컴포넌트와 상호 작용할 end-user는 분명 사용자다. 그들은 렌더링 된 버튼과 콘텐츠를 보고 상호작용 할 것이다.
또한 주어진 props(위 코드의 경우 아이템의 리스트)로 Accordion을 렌더링 할 개발자도 있다. 그래서 React 컴포넌트에는 일반적으로 end-user와 developer라는 두 명의 사용자가 있다.
End-user와 developer는 애플리케이션 코드를 만들 때 반드시 고려해야하는 두 명의 "사용자"다.

그렇다면 각 사용자는 코드의 어떤 부분을 사용하고, 보고, 이해할 수 있을까?
End-user은 컴포넌트에서 렌더링 된 화면을 보고 상호작용한다. 반면 developer는 컴포넌트에 전달하는 props를 보고 상호 작용한다.
따라서 테스트는 일반적으로 "전달된 props를 올바르게 사용할 수 있는가" 와 "렌더링 된 화면이 올바른가" 이 두 가지를 테스트해야 한다.

이것이 바로 React Testing Library가 하는일이다. 이 라이브러리는 더미 props를 Accordion 컴포넌트에 전달한 다음 React Element를 쿼리 하는 구문(getByRole, getByText)등을 사용하여 렌더링 된 화면을 표시하고(또는 표시하지 않고), 렌더링 된 버튼을 클릭하여 상호작용한다.

Enzyme의 테스트를 생각해 보자. Enzyme는 `state와` `openIndex`를 참조하고 있었다. 위에서 언급한 두 가지 유형의 사용자에게는 어떤 함수가 호출되었는지, 인덱스가 primitive 한 값으로 저장되는지, 배열로 저장되는지는 솔직히 신경 쓰지 않는다. 또한 `setOpenIndex` 메서드에 대해서는 특히 알 필요가 없다.
하지만 Enzyme의 테스트 케이스는 아무도 신경 쓰지 않는 것들을 테스트하고 있다.

이것이 바로 Enzyme 테스트가 False Negatives를 일으키기 쉬운 이유다. end-user와 developer와는 다른 방식으로 테스트를 작성하기 때문에 애플리케이션 코드가 고려해야 하는 세 번째 사용자, 즉 테스트가 등장한다! 이 테스트는 솔직히 아무도 신경 쓰지 않는 사용자다.
나는 애플리케이션 코드가 이 세 번째 사용자인 테스트를 고려하지 않았으면 좋겠다. 완전히 시간 낭비다. 테스트 자체를 위한 테스트는 필요하지 않다. 자동화된 테스트는 애플리케이션 코드가 운영 환경의 사용자에게 잘 작동하는지 확인해야 한다.

"The more your tests resemble the way your software is used, the more confidence they can give you. — me"

"테스트가 소프트웨어 사용 방식과 유사할수록, 그것들이 제공하는 신뢰도는 더욱 높아진다." — kent

이에 대해 좀 더 알고 싶다면 다음을 참고하라. Avoid the Test User

그렇다면 hooks는?

글쎄, enzyme는 hooks에서 많은 문제가 있다. `구현 세부 사항`을 테스트할 때 구현이 변경되면 테스트에 큰 영향을 미친다. 클래스 컴포넌트를 hooks가 있는 함수형 컴포넌트로 마이그레이션 하는 경우 그 과정에서 테스트의 무언가를 망가뜨려도 알 수 없기 때문에 문제가 생긴다.

반면 React Test Library는 어떨까? 클래스 컴포넌트와 hooks가 있는 함수형 컴포넌트 둘다 정상적으로 작동한다. 이 글의 마지막에 있는 codesandbox 링크에서 확인해 볼 수 있다. 나는 React Testing Library로 작성하는 테스트를 다음과 같이 부른다:

구현 세부 사항이 없고 리팩터링에 용이하다.

결과

어떻게 `구현 세부 사항`을 테스트 하는 것을 피할 수 있을까? 올바른 테스팅 도구를 사용하는 것이 시작이다. 여기 무엇을 테스트해야 하는지 알기 위한 프로세스가 있다.
이 프로세스를 따르면 테스트할 때 올바른 마인드로 테스트할 수 있으며, 자연스럽게 `구현 세부 사항`을 피할 수 있다.

테스트되지 않은 코드베이스 중에서 에러가 발생했을 때 심각한 문제가 발생할 가능성이 있는 부분은 어디인가?( 예: 결제 시 에러)
해당 코드를 한개의 unit 혹은 몇 개의 unit으로 범위를 좁혀라 (예: "결제" 버튼 클릭 시 장바구니의 아이템과 함께 /checkout으로 요청함)
해당 코드를 살펴보고 '사용자'가 누구인지 생각하라(결제 form을 렌더링하는 developer, 버튼을 클릭하는 end-user)
코드가 손상되지는 않았는지 사용자가 직접 수동으로 테스트하기 위한 지침서를 작성하라.
예:
- 더미 데이터가 들어있는 장바구니를 사용하여 결제 form을 렌더링한다.
- 결제 버튼을 클릭한다.
- /checkout API로 보낼 때 더미 데이터가 올바르게 전송되는지 확인한다.
- fake 성공 응답이 잘 내려오는지 확인한다.
- 성공 메시지가 잘 보이는지 확인한다.
작업한 지침서를 자동화된 테스트로 작성하라.

도움이 되었으면 좋겠다! 테스트를 한 단계 더 발전시키고 싶다면 다음 사이트에서 Pro license를 얻는 것을 추천한다. TestingJavaScript.com

Good luck!

P.S. 위의 코드들을 확인하고 싶다면, codesandbox에서 확인할 수 있다.

P.S.P.S. 연습 문제로... 만약 `AccordionContents` 컴포넌트의 이름을 바꾸면 두 번째 Enzyme 테스트에서는 어떤 일이 일어날까?

[모던 자바 인 액션] 1장 보충 - 자바 8, 9, 10, 11 : 무슨 일이 일어나고 있는가?

SooJae — Thu, 9 Mar 2023 20:12:02 +0900

※ 이 글은 '모던 자바 인 액션' 책을 참고하여 작성되었습니다. 해당 책을 먼저 읽고 이해하신 후에 이 글을 읽으시는 것을 추천합니다.

1.1 역사의 흐름은 무엇인가

자바 1.0

스레드와 스레드락
메모리 모델 지원, 그러나 저수준 기능 활용이 힘들다

※ 메모리 모델이란 : https://parkcheolu.tistory.com/14

자바 5

스레드 풀
병렬 실행 컬렉션

※ 스레드 풀이란: https://jenkov.com/tutorials/java-concurrency/thread-pools.html

자바 7

병렬 실행에 도움을 줄 수 있는 Fork / Join 프레임워크, 그러나 활용이 힘들다

※ Fork/Join Framework in Java: https://warpgate3.tistory.com/entry/ForkJoin-Framework-in-Java

※ Java Fork and Join using ForkJoinPool: https://jenkov.com/tutorials/java-util-concurrent/java-fork-and-join-forkjoinpool.html

자바 8

스트림 API, 메서드 참조와 람다, 인터페이스의 디폴트 메서드
자바 8 기법은 함수형 프로그래밍에서 위력을 발휘한다.

1.2 왜 아직도 자바는 변화하는가?

1.2.2 스트림 처리

스트림이란 한번에 한 개씩 만들어지는 연속적인 데이터 항목들의 모임이다

리눅스의 스트림: https://love-every-moment.tistory.com/52

자바 8 에는 java.util.stream 패키지에 스트림 API 가 추가되었다
우리가 하려는 작업을 고수준으로 추상화해서 일련의 스트림으로 만들어 처리 할 수 있다
스레드라는 복잡한 작업을 사용하지 않으면서 공짜로 병렬성을 얻을 수 있다

1.2.3 동작 파라미터화로 메서드에 코드 전달하기

자바 8에서는 메서드를 다른 메서드의 인수로 넘겨주는(일급 객체) 기능을 제공하며, 이를 동작 파라미터화(behavior parameterization)라고 한다.

1.2.4 병렬성과 공유 가변 데이터

공유되지 않은 가변 데이터, 메서드, 함수 코드를 다른 메서드로 전달하는 두 가지 기능은 함수형 패러다임의 핵심적인 사항이다. (명령형 프로그래밍 패러다임에서는 일련의 가변 상태로 프로그램을 정의한다.)

1.3 자바 함수

프로그래밍 언어에서 함수(function)라는 용어는 메서드(method) 특히 정적 메서드(Static method)와 같은 의미로 사용된다. 자바의 함수는 이에 더해 수학적인 함수처럼 사용되며 부작용을 일으키지 않는 함수를 의미한다
객체(객체의 참조)도 값이다. new 또는 팩토리 메서드 또는 라이브러리 함수를 이용해서 객체의 값을 얻을 수 있다. 객체 참조는 클래스의 인스턴스(Instance)를 가리킨다
프로그래밍 언어의 핵심은 값을 바꾸는 것이고 이 값을 일급 값 (또는 시민) 이라고 부른다
자바 프로그래밍 언어의 다양한 구조체(메서드, 클래스 같은)가 값의 구조를 표현하는 데 도움될 수 있다.
메서드, 클래스 등은 이급 자바 시민에 해당한다.
만약 메서드와 클래스가 일급 시민으로 만들 수 있다면, 즉 런타임에 메서드를 전달할 수 있다면 프로그래밍에 유용하게 활용할 수 있다.(자바스크립트에서는 가능하지롱)

1.3.1 메서드와 람다를 일급 시민으로

// 자바 8 이전
File[] hiddenFiles = new File(".").listFiles(new FileFilter() {
	public boolean accept(File file) {
		return file.isHidden(); // 숨겨진 파일 필터링
    }
})

// 자바 8 이후
File[] hiddenFiles = new File(".").listFiles(File::isHidden);

`isHidden`이라는 함수(함수라는 용어를 사용했다는 것에 주목) 는 이미 준비되어 있으므로 자바 8의 메서드 참조 (method reference) :: ('이 메서드를 값으로 사용하라'의 의미)를 이용해서 listFiles 에 직접 전달할 수 있다.
람다 : 익명함수
- 예를 들어 (int x) -> x + 1, 즉 'x 라는 인수로 호출하면 x + 1을 반환'하는 동작을 수행하도록 코드를 구현할 수 있다
- 이용할 수 있는 편리한 클래스나 메서드가 없을 때 람다 문법을 이용해 더 간결하게 코드를 구현 가능하다

자바 8 이후 코드 예시

class Test {
	public static boolean isGreenApple(Apple apple) {
		return GREEN.equals(apple.getColor());
    }

    public static boolean isHeavyApple(Apple apple) {
        return apple.getWeight() > 150;
    }
	
	public interface Predicate<T> {
		boolean test(T t);
    }
	
	static List<Apple> filterApples(List<Apple> inventory, Predicate<Apple> p) {
		List<Apple> result = new ArrayList<>();
		for (Apple apple : inventory) {
			if (p.test(apple)) {
				result.add(apple);
            }
        }
		return result;
    }
}

다음처럼 메서드를 호출할 수도 있다.

filterApples(inventory, Apple::isGreenApple);
filterApples(inventory, Apple::isHeavyApple);

1.4 스트림

거의 모든 자바 애플리케이션은 컬렉션을 만들고 활용한다.

하지만 리스트에서 고가의 트랜잭션만 필터링할 경우 다음 코드처럼 많은 기본코드를 구현해야한다.

class LegacyTest {
  private static void groupTransaction() {
    // 그룹화된 트랜잭션을 더할 Map 생성
    Map<Currency, List<Transaction>> transactionsByCurrencies = new HashMap<>();
    // 트랜잭션의 리스트를 반복
    for (Transaction transcation : transactions) {
      // 고가의 트랜잭션을 필터링
      if (transaction.getPrice() > 1000) {
        // 트랜잭션의 통화 추출
        Currency currency = transaction.getCurrency();
        List<Transaction> transactionsForCurrency = transactionsByCurrencies.get(currency);
        // 현재 통화의 그룹화된 맵에 항목이 없으면 새로 만든다.
        if (transactionsForCurrency == null) {
          transactionsForCurrency = new ArrayList<>();
          transactionsByCurrencies.put(currency, transactionsForCurrency);
        }
        // 현재 탐색된 트랜잭션을 같은 통화의 트랜잭션 리스트에 추가한다.
        transactionsForCurrency.add(transaction);
      }
    }
  }
}

게다가 위 예제 코드에는 중첩된 제어 흐름 문장이 많아서 코드를 한번에 이해하기도 어렵다.
스트림 API를 이용하면 다음처럼 문제를 해결할 수 있다.

import static java.util.stream.Collectors.toList; 
class LegacyTest {
  private static void groupTransaction() {
    Map<Currency, List<Transaction>> transactionsByCurrencies = 
        transactions.stream()
            .filter((Transaction t) -> t.getPrice() > 1000) // 고가의 트랜잭션 필터링
            .collection(groupingBy(Transaction::getCurrency)); //통화로 그룹화함
  }
}

컬렉션

for-each루프를 이용해 반복 과정을 직접 처리함. -> 외부 반복
기본적으로 단일 CPU만 이용하여 순차적으로 처리한다.

스트림

라이브러리 내부에서 수행함. -> 내부 반복
기본적으로 멀티 CPU를 이용하여 병렬로 처리한다.

1.4.1 멀티 스레딩은 어렵다.

멀티 스레딩 모델은 순차적인 모델보다 다루기 어렵다.
두 스레드가 적절하게 제어되지 않은 상황에서 공유된 sum 변수에 숫자를 더하면 다음과 같은 문제가 있다. (책의 그림을 보는 것을 추천)

구성 환경

스레드 1, 스레드 2, 변수 sum (값 100)

스레드 1이 sum 변수 값을 읽는다.
스레드 2가 sum 변수 값을 읽는다.
스레드 1이 sum 변수에 3을 더한다.
스레드 2가 sum 변수에 5를 더한다.
스레드 1이 sum 변수에 103을 저장한다.
스레드 2가 sum 변수에 105를 저장한다. 결과 : 108이 아닌 105가 저장된다.

자바 8은 컬렉션을 처리하면서 발생하는 모호함과 반복적인 코드 문제 그리고 멀티코어 활용 어려움을 해결하기 위해 스트림 API를 도입했다.

자바의 병렬성과 공유되지 않은 가변 상태

흔히 자바의 병렬성은 어렵고, synchronized는 쉽게 에러를 일으킨다고 생각한다.
자바 8은 이를 해결하기 위해 두가지 방식을 사용한다.
- 라이브러리에서 분할 처리를 한다. 큰 스트림을 병렬 처리할 수 있도록 작은 스트림으로 분할한다.
- filter 같은 라이브러리 메서드로 전달된 메서드가 상호작용하지 않는다면 가변 공유 객체를 통해 병렬성을 누릴 수 있다.
  -> 여러 스레드가 동시에 가변 객체에 접근하더라도, 메서드가 상호작용하지 않기 때문에 안전하지만, 만약 전달되는 메서드가 공유되는 가변 객체를 변경한다면 문제가 발생한다. 이런 경우에는 스레드 동기화 기법을 사용하여 해결해야 한다.
함수형 프로그래밍에서 함수형이란 '함수를 일급 값으로 사용한다.'는 의미를 가지고 있지만 부가적으로 '프로그램이 실행되는 동안 컴포넌트 간에 상호작용이 일어나지 않는다' 라는 의미도 포함한다.

1.5 디폴트 메서드와 자바 모듈

자바 9의 모듈 시스템은 모듈을 정의하는 문법을 제공하므로 이를 이용해 패키지 모음을 포함하는 모듈을 정의할 수 있다.
모듈 덕분에 JAR 같은 컴포넌트 구조를 적용할 수 있다.
문서화와 모듈 확인 작업이 용이해졌다.

※ 자바 9 모듈이란: https://mslim8803.tistory.com/39

자바 8에서는 인터페이스를 쉽게 바꿀 수 있도록 디폴트 메서드를 지원한다.
디폴트 메서드는 특정 프로그램을 구현하는데 도움을 주는 기능이 아니라 미래에 프로그램이 쉽게 변화할 수 있는 환경을 제공하는 것이다.

List<Apple> heavyApples =
        inventory.stream()
                .filter((Apple a) -> a.getWeight() > 150)
                .collect(toList());

List<Apple> heavyApples =
        inventory
                .parallelStream()
                .filter((Apple a) -> a.getWeight() > 150)
                .collect(toList());

자바 8 이전에는 Stream()이나 parallelStream() 메서드를 지원하지 않았다.
이 기능을 추가하려면 Collection 인터페이스에 해당 메서드를 추가하고 ArrayList 등과 같은 구현체에 메서드를 구현해야 했다.
하지만 이미 컬렉션 API의 인터페이스를 구현하는 많은 컬렉션 프레임워크가 존재했다. 인터페이스에 새로운 메서드를 추가한다면 인터페이스를 구현하는 모든 클래스는 새로 추가된 메서드를 구현해야 했다.
자바 8은 클래스에서 구현하지 않아도 되도록 메서드를 인터페이스에 추가했다. 이를 디폴트 메서드라고 부른다.

※ 인터페이스 vs 추상 클래스:https://yaboong.github.io/java/2018/09/25/interface-vs-abstract-in-java8/

※ 다이아몬드 상속 문제: https://siyoon210.tistory.com/125

1.6 함수형 프로그래밍에서 가져온 다른 유용한 아이디어함수형 언어도 프로그램을 돕는 여러 장치를 제공한다.

일례로 명시적으로 서술형의 데이터를 이용해 null을 회피하는 기법이 있다. 자바 8에서는 NullPointer 예외를 피할 수 있도록 도와주는 Optional<T> 클래스를 제공한다. Optional<T>는 값이 없는 상황을 어떻게 처리할지 명시적으로 구현하는 메서드를 포함하고 있다.

※ null이 왜 나쁜가: https://www.mimul.com/blog/why-null-is-bad/

구조적 패턴 매칭 기법도 있다. 자바에서는 if-then-else나 switch문을 이용하지만 다른 언어에서는 패턴 매칭으로 더 정확한 비교를 구현할 수 있다는 사실을 증명했다.
아쉽게도 자바 8은 패턴 매칭을 완벽하게 지원하지 않는다.

※ (구조적) 패턴 매칭: https://0391kjy.tistory.com/8

REFERENCE

모던 자바 인 액션 - https://search.shopping.naver.com/book/search?bookTabType=ALL&pageIndex=1&pageSize=40&query=%EB%AA%A8%EB%8D%98%20%EC%9E%90%EB%B0%94%20%EC%9D%B8%20%EC%95%A1%EC%85%98&sort=REL

모던 자바 인 액션 소스 코드 - https://hanbit.co.kr/support/supplement_survey.html?pcode=B4926602499

프론트엔드에서는 어떤 것을 테스트 해야 할까?

SooJae — Tue, 7 Mar 2023 21:05:45 +0900

이 글은 Kent C. Dodds의 How to know what to test 포스트를 번역한 글입니다.

Thank you Kent C. Dodds. Because of your posts, I can continue to grow as an engineer.

테스트하는 방법을 아는 것은 훌륭하고 중요한 일이다. 나는 사람들에게 테스트의 기본 사항, 도구 구성 방법, 특정 시나리오에 대한 테스트 작성 방법 등을 알려주는 많은 콘텐츠를 만들었다.
하지만 테스트를 작성하는 방법을 알아도, 애플리케이션에 대한 신뢰성을 얻기 위해서는 그저 절반일 뿐이다. 무엇을 테스트할지 아는 것은 중요한 또 다른 절반이다.

워크숍 자료와 TestingJavaScript.com에서 무엇을 테스트해야 하는지 아는 방법에 대해 이야기하고 있지만, 이에 대한 질문을 많이 받아서 블로그 포스팅을 작성하는 것이 좋겠다고 생각했다. 가보자고!

테스트하는 이유 기억하기

우리는 사용자가 애플리케이션을 사용할 때 제대로 작동할 것이라는 신뢰성을 위해 테스트를 작성한다. 워크플로우를 개선하기 위해 테스트를 작성하는 사람들도 있지만, 나는 궁극적으로 신뢰성에 관심이 있다.
그렇기 때문에 우리가 테스트하는 것은 신뢰성 향상과 직결되어야 한다. 테스트를 작성할 때 고려해야 할 핵심 사항은 다음과 같다.

테스트 중인 코드에 대한 생각보다는 코드가 지원하는 Use Case에 대해 더 많이 생각하라.

코드 자체에 대해 생각하면 구현 세부 사항을 테스트하기 시작하게 되는데, 이것은 재앙으로 가는 길이다.
반대로 Use Case를 생각함으로써, 우리는 사용자가 애플리케이션을 사용하는 방식과 유사한 방식으로 테스트를 작성할 수 있다.
(※ 역자 주: 코드 내부의 동작 방식에 초점을 맞추는 게 아닌, 코드가 제공하는 기능을 테스트하는 것에 초점을 맞추라는 뜻이다.)

Code Coverage < Use Case Coverage

Code Coverage는 실행된 코드 라인의 비율을 나타내는 지표로, 테스트 중에 실행된 코드 라인을 보여준다. 예를 들어:

function arrayify(maybeArray) {
  if (Array.isArray(maybeArray)) {
    return maybeArray
  } else if (!maybeArray) {
    return []
  } else {
    return [maybeArray]
  }
}

현재, 이 함수에 대한 테스트가 없으므로 Code Coverage 보고서에는 이 함수에 대한 Coverage가 '0%'라고 표시된다.
이 경우 Code Coverage 보고서는 테스트가 필요함을 알려주지만, 이 함수의 중요성과 이 함수가 지원하는 Use Case가 무엇인지는 알려주지 않는다. 이것은 우리가 테스트를 작성할 때 가장 중요하게 고려해야 하는 사항이다.

사실 전체 애플리케이션을 고려하고 무엇을 테스트해야 할지 고민할 때, Code Coverage 보고서는 대부분의 시간을 어디에 사용해야 할지에 대한 인사이트를 제공하는 데 아주 부족하다. 대신 우리의 코드베이스에서 어떤 코드가 테스트되지 않았는지를 식별하는 데 도움이 된다.
따라서 Code Coverage 보고서를 보고 테스트가 누락된 부분을 확인할 때 if/else 문, loop 문, lifecyles에 대해 생각하지 말고, 자신에게 물어봐라:

"What use cases are these lines of code supporting, and what tests can I add to support those use cases?"

이 코드 라인들은 어떤 Use Case를 지원하고 있으며, 이 Use Case를 지원하는 어떤 테스트를 추가할 수 있을까?

"Use Case Coverage"는 우리가 테스트하는 Use Case의 수를 나타내는 지표이다. 불행하게도 자동화된 "Use Case Coverage"는 없다. 우리가 직접 만들어야 한다.
하지만 Code Coverage 보고서는 때때로 우리가 커버하지 않은 Use Case를 식별하는 데 도움이 될 수 있다. 한번 시도해 보자.

따라서 코드를 읽고 잠시 생각해 보면, "배열이 주어지면 배열을 리턴한다."는 Use Case를 파악할 수 있다.
이 Use Case 문장은 실제로 우리의 테스트에 대한 좋은 제목이 될 수 있다.

test('배열이 주어지면 배열을 리턴한다.', () => {
  expect(arrayify(['Elephant', 'Giraffe'])).toEqual(['Elephant', 'Giraffe'])
})

이 테스트가 완료되면 Coverage 보고서는 다음과 같이 표시된다 (강조 표시된 선이 Coverage):

이제 나머지를 살펴보면 아직 테스트하지 않은 Use Case가 두 개 더 있다는 것을 확인할 수 있다:

falsy 값이 주어지면 빈 배열을 리턴한다.
배열이 아닌 인자가 주어지면 해당 인자를 원소로 가지는 배열을 리턴한다.

테스트에 이 Use Case들을 추가하고, Code Coverage에 어떤 영향을 미치는지 확인해 보자.

test('falsy 값이 주어지면 빈 배열을 리턴한다', () => {
  expect(arrayify()).toEqual([])
})

좋아! 거의 다 왔어!

test(`배열이 아니고 falsy 값이 아니라면, 해당 인자를 원소로 가지는 배열을 리턴한다.`, () => {
  expect(arrayify('Leopard')).toEqual(['Leopard'])
})

멋지다! 브라보! 이제 이 함수의 Use Case를 변경하지 않는 한 테스트가 계속 정상적으로 통과할 것이라고 신뢰할 수 있다.

Code Coverage가 완벽한 지표는 아니지만, 우리 코드베이스에서 "Use Case Coverage"가 빠진 부분을 식별하는 유용한 도구가 될 수 있다.

Code Coverage로 Use Case를 숨길 수 있다.

가끔 Code Coverage 보고서에는 Code Coverage가 100%로 표시되지만, Use Case Coverage가 100%가 아닐 수 있다.
이것이 바로 내가 테스트를 작성하기 전에 모든 Use Case를 생각하려고 노력하는 이유이다.

예를 들어 `arrayify` 함수가 다음과 같이 구현되었다고 가정해 보자:

function arrayify(maybeArray) {
  if (Array.isArray(maybeArray)) {
    return maybeArray
  } else {
    return [maybeArray].filter(Boolean)
  }
}

아래 두 Use Case를 통해, 우리는 100%의 Coverage를 얻을 수 있다.

배열이 주어지면 배열을 리턴한다.
배열이 아닌 인자가 주어지면 해당 인자를 원소로 가지는 배열을 리턴한다.

하지만 Use Case Coverage 보고서를 보면 아래 Use Case는 빠져있는 것으로 나올 것이다:

falsy 값이 주어진다면, 빈 배열을 리턴한다.

이는 문제가 될 수 있다. 사용자가 직접 `arrayify()` 코드를 사용할 때 이러한 테스트 케이스는 코드에 대한 확신을 주지 못할 것이기 때문이다.
지금은 잘 작동하는 것 같고, 이 케이스에 대한 테스트를 작성하지 않아도 코드가 해당 Use Case를 지원할 수 있지만, 테스트를 작성하는 이유는 코드의 변경이 발생하더라도 우리가 의도한 Use Case를 계속해서 지원할 수 있도록 보장하기 위함이다.
따라서, 우리는 이러한 Use Case를 커버할 수 있도록 테스트를 추가해야 한다.

이 테스트가 누락되면 어떻게 잘못될 수 있는지에 대한 예로, 누군가 이 `.filter(Boolean)` 코드를 보고 "음, 이상하네... 저게 정말 필요한 건가?"라고 생각할 수 있다.
그래서 제거하면 테스트는 계속 통과하지만 잘못된 동작에 의존하는 모든 코드는 손상된다.

핵심 요점:

Test use cases, not code.

코드를 테스트하지 말고, Use Case들을 테스트하라.

React에 적용하는 방법

코드를 작성할 때는 지원해야 하는 사용자가 이미 두 명이라는 것을 기억하라: End 사용자와 developer 사용자. 다시 말하지만, Use Case보다 코드에 대해 초점을 맞추면, 코드의 세부사항을 구현하기 시작하게 되는 함정에 빠지기 쉽다.
그렇게 되면 의도치 않은 세 번째 사용자, 즉 테스트 사용자가 추가된다.

다음은 React로 개발하는 개발자들이 테스트에 대해 생각하는 몇 가지 측면이 있는데, 결국 세부 사항을 구현하는 테스트를 하게 된다.

이 모든 것에 대해 코드에 대해 생각하기보다는 코드가 End 사용자와, developer 사용자에게 영향을 미치는 요소에 대해 생각해야 하며, 다음과 같은 Use Case에 대해 생각하고 이를 테스트하라.

라이프사이클 메서드(Lifecycle methods)
요소 이벤트 핸들러(Element event handlers)
내부 컴포넌트 상태(Internal Component State)

반면, 두 사용자와 관련이 있으므로 테스트해야 하는 항목은 다음과 같다. 각각 DOM을 변경하거나, HTTP 요청을 하거나 콜백 프로퍼티를 호출하거나, 관찰 가능한 side effect 생성등 테스트를 하기 위한 여러 가지 유용한 작업들이 있다:

사용자(User) 상호작용(`@testing-library/user-event`라이브러리에서는 `userEvent`를 사용.): End 사용자가 컴포넌트가 렌더링 하는 요소(element)와 상호작용할 수 있는가?
프로퍼티(Props) 변경(React Testing Library에서 `rerender` 사용): developer 사용자가 컴포넌트를 새로운 프로퍼티로 re-render 되면 어떻게 되는가?
컨텍스트(Context) 변경(React Testing Library에서 `rerender` 사용): developer 사용자가 컨텍스트를 변경하여 컴포넌트가 re-reder 되면 어떻게 되는가
구독(Subscription) 변경: 컴포넌트가 구독하는 이벤트 Emitter가 변경되면 어떻게 되는가? (fierbase, redux store, router, media query, 온라인 상태와 같은 브라우저 기반 구독 같은)

애플리케이션에서 어디서부터 시작해야 하는지 어떻게 알 수 있나?

애플리케이션의 개별 컴포넌트와 페이지에 대해 '무엇을 테스트할지' 생각하는 방법은 알지만, 어디서부터 시작해야 하나?
다소 부담스러울 수 있다. 특히 대규모 애플리케이션에서 테스트를 막 시작한 경우라면 더욱 그렇다.

따라서 사용자의 관점에서 애플리케이션을 고려하고 다음과 같이 질문하라:

이 애플리케이션이 고장 났을 때 가장 화가 나는 부분은 어디인가?

좀 더 일반적으로:

이 애플리케이션에서 에러가 발생하면 큰일이 나는 곳은 어디인가?

애플리케이션이 지원하는 기능의 목록을 작성하고, 이 기준에 따라 우선순위를 정하는 것이 좋다. 팀 및 관리자와 함께 해보는 것도 좋다.
이 회의를 통해 회의에 참석한 모든 사람들이 테스트의 중요성을 이해하고, 테스트가 다른 기능 개발보다 우선순위를 갖는 것이 필요하다는 것을 확신하게 되어, 많은 이점을 얻을 수 있을 것이다.

우선순위가 정해진 목록이 있으면 특정 Use Case에 대해 대부분의 사용자가 거치는 '행복한 경로'를 포괄하는 단일 End To End(E2E) 테스트를 작성하는 것이 좋다.
이 방법으로 목록에 있는 몇 가지 주요 기능들을 테스트할 수 있다. 설정하는데 시간이 조금 걸릴 수 있지만, 투자 대비 큰 효과를 얻을 수 있다.

E2E테스트는 100% Use Case Coverage를 제공하지 않지만(100%를 얻으려는 시도조차 하지 말아야 한다.) 100% Code Coverage를 제공하지 않지만(E2E 테스트에서는 신경 쓰지 말아야 한다.), 좋은 출발점이 될 것이며, 현재 코드에 대한 자신감을 크게 높여줄 것이다.

몇 가지 E2E 테스트 케이스가 있으면 E2E 테스트에서 놓치고 있는 일부 특정 케이스에 대한 통합 테스트와, 해당 기능이 사용하는 더 복잡한 비즈니스 로직에 대한 Unit 테스트 작성을 시작할 수 있다.
100% Code Coverage를 목표로 삼지 말아야 한다. 그럴 가치가 없다.

테스트 문화와 합리적인 코드 커버리지 목표를 설정하는 방법에 대해 자세히 알아보려면 AssertJS 2018에서 발표한 Aaron Abramov의 강연을 시청하면 좋다: 소프트웨어 설계 원칙으로 테스트 패턴 수립하기

다양한 테스트 유형의 차이점에 대해 자세히 알아보려면 이 게시물을 보는 것이 좋다: 프론트엔드에서의 Static, Unit, Integration, E2E 테스트

결론

충분한 시간과 경험이 주어지면 무엇을 테스트해야 하는지 직관적으로 알 수 있다. 실수도 하고 약간의 어려움을 겪을 수도 있다. 포기하지 말고 계속 진행하자!

Good luck.

프론트엔드에서의 Static, Unit, Integration, E2E 테스트

SooJae — Sun, 5 Mar 2023 19:04:37 +0900

이 글은 Kent C. Dodds의 Static vs Unit vs Integration vs E2E Testing for Frontend Apps 포스트를 번역한 글입니다.

Thank you Kent C. Dodds. Because of your posts, I can continue to grow as an engineer.

TestingJavaScript.com에 있는 "Testing Practices with J.B. Rainsberger" 인터뷰에서 그는 내가 정말 좋아하는 비유를 들려주었다. 그는 다음과 같이 말했다.

"You can throw paint against the wall and eventually you might get most of the wall, but until you go up to the wall with a brush, you'll never get the corners. ️"

"벽에 페인트를 던진다면 결국 대부분의 벽을 페인트칠할 수 있지만, 붓을 들고 벽에 올라가지 않는 한 절대 모서리를 페인트칠할 수 없다. ️"

내가 테스트를 적용하는 관점에서 이 비유를 좋아하는 이유는, 올바른 테스트 전략을 선택하는 것은 벽에 그림을 그릴 때 붓을 고르는 것과 똑같기 때문이다.

벽 전체에 가느다란 붓을 사용해야 할까? 물론 아니다. 그렇게 하면 시간이 너무 오래 걸리고 최종 결과물이 균일하지 않을 것이기 때문이다. 200년 전 고조할머니가 바다 건너 가져온 가구 주변까지 롤러로 칠할 수 있을까? 불가능하다.

경우에 따라 사용하는 브러쉬가 다르듯이, 테스트에도 똑같이 적용된다.

이것이 바로 내가 트로피를 만든 이유다. 그 후 Maggie Appleton (egghead.io의 뛰어난 아트/디자인을 만든 사람)이 TestingJavaScript.com을 위해 이 트로피를 만들었다.

테스팅 트로피에는 4가지 타입의 테스트가 있다. 위의 설명은 화면 리더기를 사용하는 사용자(그리고 이미지가 로드되지 않는 경우)를 위해 아래 자세하게 설명하려고 한다.

End to End: 사용자처럼 행동하는 도우미 로봇이다. 앱을 클릭하고, 올바르게 작동하는지 확인한다. 'functional testing' 또는 e2e라고도 한다.
Integration: 여러 장치가 함께 상호 작용하여 잘 동작하는지 확인한다.
Unit: 기능들이 각각 독립적으로 잘 동작하는지 확인한다.
Static: 코드를 작성할 때 오타와 타입에러를 확인한다.

트로피가 보여주는 이러한 테스트 형식의 크기는 애플리케이션을 테스트할 때 얼마나 집중해야 하는지에 대한 상대적인 크기이다. (일반적으로) 이제 이런 다양한 형태의 테스트에 대해 자세히 살펴보고, 실질적으로 어떤 의미가 있는지, 그리고 테스트 비용을 최대한 활용하기 위해 무엇을 최적화할 수 있는지 알아보자.

테스트 타입

몇 가지의 예를 들어 어떤 종류의 테스트가 있는지 살펴보자.

End to End

일반적으로 전체 애플리케이션(프론트엔드 및 백엔드 모두)을 실행하며, 테스트는 실제 사용자가 사용하는 것처럼 앱과 상호 작용한다. 아래 테스트 코드는 cypress로 작성되었다.

import {generate} from 'todo-test-utils'

describe('todo app', () => {
  it('should work for a typical user', () => {
    const user = generate.user()
    const todo = generate.todo()
    // 여기서는 등록 절차를 진행한다.
    // 일반적으로 이 작업을 수행하는 e2e 테스트는 하나만 존재한다.
    // 나머지 테스트들은 동일한 endpoint를 호출할 것이다.
    // 애플리케이션이 인간과 같은 방식으로 동작하기 때문에, 
    // 우리는 수작업으로 테스트를 수행하지 않아도 된다.
    cy.visitApp()

    cy.findByText(/register/i).click()

    cy.findByLabelText(/username/i).type(user.username)

    cy.findByLabelText(/password/i).type(user.password)

    cy.findByText(/login/i).click()

    cy.findByLabelText(/add todo/i)
      .type(todo.description)
      .type('{enter}')

    cy.findByTestId('todo-0').should('have.value', todo.description)

    cy.findByLabelText('complete').click()

    cy.findByTestId('todo-0').should('have.class', 'complete')
    // etc...
    // 나의 E2E 테스트는 일반적으로 사용자가 하는 것과 비슷하게 동작한다.
    // 때로는 상당히 길어질 수 있다.
  })
})

Integration

아래 테스트는 전체 앱을 렌더링한다. 이는 Integration 테스트의 `필수 조건은 아니며`, 대부분의 Integration 테스트에서는 전체 앱을 렌더링 하지 않는다. 하지만 모듈의 렌더링 메서드에서 사용하는 모든 제공자들과 함께 렌더링 될 것이다. (가상의 `test/app-test-utils` 모듈의 렌더링 메서드가 하는 일이다.)
Integration 테스트의 기본 개념은 가능한 한 적게 모의(mock)을 하는 것이다. 나는 거의 다음 것들만 모의(mock)한다.

네트워크 Requests(MSW 사용)
애니메이션을 담당하는 컴포넌트 (테스트 중에 애니메이션을 기다릴 사람은 없을 테니까)

import * as React from 'react'
import {render, screen, waitForElementToBeRemoved} from 'test/app-test-utils'
import userEvent from '@testing-library/user-event'
import {build, fake} from '@jackfranklin/test-data-bot'
import {rest} from 'msw'
import {setupServer} from 'msw/node'
import {handlers} from 'test/server-handlers'
import App from '../app'

const buildLoginForm = build({
  fields: {
    username: fake(f => f.internet.userName()),
    password: fake(f => f.internet.password()),
  },
})

// integration 테스트는 일반적으로 MSW를 통한 HTTP Request만 모의(mock) 테스트한다.
const server = setupServer(...handlers)

beforeAll(() => server.listen())
afterAll(() => server.close())
afterEach(() => server.resetHandlers())

test(`logging in displays the user's username`, async () => {
  // 커스텀 렌더링은 애플리케이션이 로딩을 완료할 때까지 resolve하는 
  // Promise를 리턴한다. (서버 렌더링의 경우 필요하지 않을 수 있다.)
  // 또한 커스텀 렌더링은 초기 route를 지정(특정 페이지를 렌더링)할 수 있도록 해준다.
  await render(<App />, {route: '/login'})
  const {username, password} = buildLoginForm()

  userEvent.type(screen.getByLabelText(/username/i), username)
  userEvent.type(screen.getByLabelText(/password/i), password)
  userEvent.click(screen.getByRole('button', {name: /submit/i}))

  await waitForElementToBeRemoved(() => screen.getByLabelText(/loading/i))

  // 사용자가 로그인했는지 확인할 필요가 있는 모든 것을 assert 하라.
  expect(screen.getByText(username)).toBeInTheDocument()
})

이를 위해 일반적으로 테스트 사이에 모든 모의 테스트를 자동으로 재설정하는 등 몇 가지 사항을 전역적으로 설정한다.

React Testing Library 설정 문서에서 위와 같이 테스트 유틸리티 파일을 설정하는 방법을 배울 수 있다.

Unit

import '@testing-library/jest-dom/extend-expect'
import * as React from 'react'
// 위의 통합 테스트 예제에서와 같은 Integration 테스트 유틸리티 모듈이 있다면,
// @testing-library/react대신 해당 모듈을 사용해도 된다.
import {render, screen} from '@testing-library/react'
import ItemList from '../item-list'

// 몇몇 사람들은 이것들을 unit 테스트라고 부르지 않는다.
// 왜냐하면 리액트로 DOM에 렌더링을 하기 때문이다.
// 그들은 얕은(shallow) 렌더링을 사용하라고 할 것이다.
// 그들이 당신에게 이런 말들을 한다면, 이 링크를 보여주면 된다. https://kcd.im/shallow 
test('renders "no items" when the item list is empty', () => {
  render(<ItemList items={[]} />)
  expect(screen.getByText(/no items/i)).toBeInTheDocument()
})

test('renders the items in a list', () => {
  render(<ItemList items={['apple', 'orange', 'pear']} />)
  // note: 이렇게 간단한 경우에는 스냅샷을 사용하는 것도 고려해볼 수 있지만, 다음 조건이
  // 모두 충족될 때만 사용하는 것이 좋다.
  // 1. 스냅샷이 작을 때
  // 2. toMatchInlineSnapshot() 메서드를 사용할 때
  // Read more: https://kcd.im/snapshots
  expect(screen.getByText(/apple/i)).toBeInTheDocument()
  expect(screen.getByText(/orange/i)).toBeInTheDocument()
  expect(screen.getByText(/pear/i)).toBeInTheDocument()
  expect(screen.queryByText(/no items/i)).not.toBeInTheDocument()
})

누구나 아래의 코드를 unit 테스트라고 부르고, 그 말이 맞다.

// 순수 함수(pure functinos)는 unit 테스트에 가장 적합하며, 
// 그들에 대해 jest-in-case 라이브러리를 사용하는 것을 좋아한다.
import cases from 'jest-in-case'
import fizzbuzz from '../fizzbuzz'

cases(
  'fizzbuzz',
  ({input, output}) => expect(fizzbuzz(input)).toBe(output),
  [
    [1, '1'],
    [2, '2'],
    [3, 'Fizz'],
    [5, 'Buzz'],
    [9, 'Fizz'],
    [15, 'FizzBuzz'],
    [16, '16'],
  ].map(([input, output]) => ({title: `${input} => ${output}`, input, output})),
)

Static

// 버그를 발견할 수 있니?
// ESLint의 for-direction 규칙을 사용하면
// 코드 리뷰보다 더 빨리 발견할 수 있을 것이다.  
for (var i = 0; i < 10; i--) {
  console.log(i)
}

const two = '2'
// ok, 이건 좀 인위적이야, 
// 하지만 타입스크립트는 이것이 나쁘다는 것을 알려 줄 것이다:
const result = add(1, two)

다시, 왜 우리는 테스트를 해야하는가?

나는 우리가 처음부터 왜 테스트를 작성해야 하는지를 기억하는 것이 중요하다고 생각한다.

왜 ~~당신은~~ 테스트를 작성하는가? 내가 당신에게 테스트하라고 말했기 때문인가? PR시 테스트가 포함되지 않으면 reject 될까 봐 그런가? 테스트가 당신의 workflow를 개선해서 그런가?

내가 테스트를 작성하는 가장 중요한 이유는 신뢰성이다. 나는 앞으로 추가될 코드가 현재 운영 중인 앱을 망치지 않을 것이라는 신뢰를 갖고 싶다.
그래서 나는 어떤 일을 하든 작성하는 테스트가 애플리케이션에 대해 최대한 신뢰성을 얻을 수 있도록 하고, 테스트할 때 어떤 trade-off가 있는지 잘 알아 본다.

이 그림(my sliedes에서 발췌)에서 강조하고 싶은 테스팅 트로피에는 몇 가지 중요한 요소가 있다:

이미지 화살표는 자동화된 테스트를 고려할 때 생각해야 할 세 가지 trade-off를 나타 낸다:

Cost: ￠ heap ➡

테스팅 트로피가 올라갈수록, 더 많은 비용이 든다. 이는 지속적 통합 환경(Continuous integration environment)에서 테스트를 실행하는 실제 비용뿐만 아니라 엔지니어가 각 개별 테스트를 작성하고 유지 관리하는 데 걸리는 시간도 포함된다.
트로피의 위로 올라갈수록 실패 포인트가 많아지므로 테스트가 중단될 가능성이 높아져 테스트를 분석하고 수정하는데 더 많은 시간이 소요된다. 중요한 #복선이므로 기억하라.

Speed: ➡

테스트 트로피가 위로 올라갈수록 테스트는 일반적으로 느리게 실행된다. 이는 테스트 트로피에서 더 높은 단계로 올라갈수록 테스트가 실행하는 코드가 더 많기 때문이다.
Unit테스트는 일반적으로 의존성이 없거나 해당 의존성을 모킹(mocking)할 수 있는 작은 단위의 기능을 테스트한다.(수천 라인의 코드를 단 몇 줄로 효과적으로 대체). 중요한 #복선이므로 기억하라

Confidence: Simple problems ➡ Big problems

일반적으로 사람들이 테스트 피라미드 에 대해 이야기할 때 비용과 속도의 trade-off를 언급한다.
하지만 이것이 유일한 trade-off라면 테스팅 피라미드를 고려할 때 Unit 테스트에만 100% 집중하고, 다른 형태의 테스트를 완전히 무시할 것이다. 물론 이렇게 해서는 안되며, 그 이유는 내가 이전에 말한 적이 있는 매우 중요한 원칙이 있기 때문이다:

"The more your tests resemble the way your software is used, the more confidence they can give you."

테스트가 소프트웨어 사용 방식과 유사할수록, 더 많은 신뢰를 줄 수 있다.

위의 문장이 무엇을 의미 하는가? 즉, Marie 이모가 세무 소프트웨어를 사용하여 세금을 할 수 있도록 하려면 실제로 마리 이모가 해보는 방법보다 더 좋은 방법이 없다는 뜻이다.
하지만 Marie 이모가 버그를 찾아줄 때까지 기다릴 수는 없지 않은가? 그것은 시간이 너무 오래 걸리고 테스트해야할 일부 기능을 놓칠 수 있다. 여기에 정기적으로 소프트웨어 업데이트 하고 있다는 사실을 고려하면, 아무리 많은 사람들이 있더라도 이를 따라잡을 방법이 없다.

그럼 어떻게 해야할까? 우리는 trade-off를 고려해야한다. 어떻게? 소프트웨어를 테스트하는 소프트웨어를 작성한다. 테스트할 때 항성 trade-off를 고려하는 것은 이제 우리의 테스트가 Marie 이모가 소프트웨어를 테스트할 때만큼 안정적으로 소프트웨어가 사용되는 방식이과 비슷하지 않다는 것이다.
하지만 이런 접근 방식을 통해 실제 문제를 해결할 수 있기 때문에 테스트를 한다. 이것이 바로 모든 테스팅 트로피 레벨에서 우리가 하고 있는 일이다.

테스팅 트로피가 위로 올라갈 수록 "신뢰도 계수"라는 것이 높아진다. 이는 각 테스트 수준에서 상대적인 신뢰성 수준을 나타낸다.
트로피 위에는 수동 테스트가 있다고 상상할 수 있다. 수동 테스트는 매우 높은 신뢰성을 얻을 수 있지만, 테스트 비용이 매우 비싸고 속도도 느리다.

앞서 두가지 #복선을 기억하라고 했다:

트로피 위로 올라갈수록 실패 포인트가 많아지므로 테스트가 중단될 가능성이 높아져 테스트를 분석하고 수정하는데 더 많은 시간이 소요된다.

Unit테스트는 일반적으로 의존성이 없거나 해당 의존성을 모킹(mocking)할 수 있는 작은 단위의 기능을 테스트한다.(수천 라인의 코드를 단 몇 줄로 효과적으로 대체).

이 말들은 테스팅 피라미드의 아래쪽으로 갈수록 테스트하는 코드의 양이 적어진다는 것을 의미한다. 낮은 수준에서 작동하는 경우, 더 많은 테스트가 필요하며, 테스팅 피라미드의 상위 단계에서는 하나의 테스트로 더 많은 코드 라인을 커버할 수 있다.
사실, 테스팅 피라미드의 아래쪽으로 내려갈수록, 테스트가 불가능한 몇 가지 요소가 있다.

특히 정적 분석 도구로 비즈니스 로직에 대한 신뢰성을 얻을 수 없다. Unit 테스트는 의존성 호출이, 적절하게 이루어졌는지 보장할 수 없다. (호출 방법에 대한 Assertion은 할 수 있지만 Unit 테스트로 제대로 호출되는지는 보장할 수 없다.).
UI Integration 테스트는 백엔드에 올바른 데이터를 전달하고, 에러를 올바르게 처리하고 파싱하는지 보장할 수 없다.
End to End는 매우 훌륭하지만, 일반적으로 non-Production(운영 환경에 가깝지만 실제 운영 환경이 아닌 환경)에서 실행하여 신뢰성 대비 실용성의 trade-off가 있다.

이제 다른 방향으로 가보자. 테스팅 트로피의 맨 위에서 Form과 URL 생성의 edge case에 대해 E2E 테스트를 사용하여 특정 필드를 입력하고 제출 버튼을 클릭하는 것을 확인하기 위해 E2E 테스트를 사용하려고 하면, 전체 애플리케이션(백엔드 포함)을 실행하여 많은 설정 작업을 하게 된다. 이는 Integration 테스트에 좀 더 적합하다.

쿠폰 코드 계산기의 edge case를 테스트하기 위해 Integration 테스트를 사용하려고 한다면, 쿠폰 코드 계산기를 사용하는 컴포넌트를 렌더링할 수 있는지 확인하기 위해 설정 함수(setup function)에서 상당의 양을 작업을 할 것이다.
이런 edge case는 Unit 테스트에서 하는 것이 더 낫다.

만약 숫자 대신 문자열을 사용하여 add 함수를 호출했을 때의 결과를 검증하기 위해 Unit 테스트를 사용하려 한다면, TypeScript와 같은 정적 타입 체크 도구를 사용하는 것이 훨씬 더 효과적일 수 있다.

결과

트로피의 각 수준마다 각각의 trade-off를 갖고있다. E2E테스트는 실패 포인트가 더 많아서 어떤 코드가 문제를 일으켰는지 추적하기가 어려울 수 있지만, 이것은 더 많은 신뢰성을 가질 수 있다는 것을 의미한다.
이는 테스트를 작성할 시간이 충분하지 않은 경우 특히 유용하다.

애초에 테스트를 통해 문제를 발견하지 못하는 것보다는 자신감을 가지고 실패의 원인을 추적하는 것이 더 낫다.

결국 나는 그 구분에 별로 신경쓰지 않는다.
만약 내 Unit 테스트를 Integration 혹은 E2E라고 생각한다면(어떤 사람들은 그렇게 부르기도 한다 ‍♂️) 그렇게 생각해라.
나는 내 코드가 비즈니스 요구 사항을 충족하는 것이 더 중요하다. 그 목표를 달성하기 위해 다양한 테스트 전략을 혼합하여 사용할 것이다.

Good luck!

[yarn] npm을 막고 yarn으로 강제하는 방법

SooJae — Thu, 2 Mar 2023 19:11:20 +0900

패키지 매니저로 yarn을 사용하는데, 협업하는 과정에서 실수로 `npm` 명령어를 사용해서 `package-lock.json` 파일이 생성되는 경우가 종종 발생한다.

그때 마다 'npm 사용하지 마시고, yarn을 사용해주세요.'라고 말해야 하는 상황(시간이 지나서 또 package-lock.json 파일이 올라온다면...)을 피하고 싶다면 npm을 막고 yarn으로 강제하자.

3가지의 강제화 방법이 있다.

package.json 파일의 scripts 속성의 preinstall 속성을 이용한 강제화 (추천)

// package.json
{
	// ... 생략
  "scripts": {
    // ... 생략
    "preinstall": "node -e 'if(!/yarn\\.js$/.test(process.env.npm_execpath))throw new Error(\"yarn을 사용해주세요\")'"
  }	
}

`$ npm install` 실행시 결과

앞으로 후술할 Engines를 사용하는 방식처럼 따로 .npmrc 파일을 만들 필요가 없고, only-allow 방식처럼 라이브러리를 사용할 필요도 없다.

Package.json 파일의 Engines 값을 이용한 강제화

// package.json

{
  // ... 생략
  "engines": {
    "npm": "npm 대신 yarn을 사용해주세요"
  }
}

package.json 파일이 있는 위치에 .npmrc 파일을 생성하여 다음 코드를 추가해야 한다.

// .npmrc
engine-strict = true

`$ npm install` 실행 시 결과

only-allow 라이브러리 사용 (개인적으로 비 추천)

only-allow 라이브러리를 사용하면 원하는 패키지 매니저로 강제할 수 있다.
npm 주소 - https://www.npmjs.com/package/only-allow
하지만 굳이 라이브러리를 써야 하나 싶다. 또한 `boxen`과 `which-pm-runs` 라이브러리에 의존되어있기도 하다.

REFERENCE

Force yarn install instead of npm install for node modules - https://stackoverflow.com/a/41233367
How to Force Use Yarn or NPM - https://www.freecodecamp.org/news/how-to-force-use-yarn-or-npm/

[Security] Access control 종류(ACL, RBAC, ABAC)와 Coarse-grained, Fine-grained

SooJae — Wed, 1 Mar 2023 20:22:59 +0900

Coarse와 Fine

Coarse-grained와 Fine-grained의 사전적 뜻은 각각 `<석재.목재 등이>결이 거친`, `결이 고운` 이란 뜻이라고 한다. 감이 잡히지 않는다
Coarse, Fine 단어로만 찾아보면 아래와 같다.

Coarse

Fine

사전:  https://www.merriam-webster.com/dictionary/

즉 하나의 물질이 있다면 이것을 큰 입자들로 나누냐, 작은 입자들로 나누냐의 차이다. 즉 '매우 구체적인' 이라고 생각하면 된다.
사실 Coarse-grained와 Fine-grained는 프로그래밍에서 전반적으로 사용하는 용어다.

예를 들어 구글 시트 API를 호출하려면, 발급받은 ClientId와 SecretKey로 인증을 한 후에 구글 시트를 불러올 수 있다.
이때 Coarse-grained는 `getGoogleSheet` 함수 안에 인증 + 구글 시트 조회 + Rows 값 조회를 전부 넣는 것을 뜻한다.
반면 Fine-grained는 `authGoogleSheet`, `getGoogleSheet`, `getGoogleSheetRows` 각각 함수를 만들어서 호출하는 것을 뜻한다.
비교해 보면 Fine-grained가 좀 더 유연하게(authGoogleSheet를 다른 곳에서 호출하는 등) 사용할 수 있다. 하지만 작업시간이 Coarse-grained보다 오래 걸린다.

이제 Access Control 관점에서 살펴보자.

Access Control에서의 Coarse-grained와 Fine-grained

Coarse: 크루들은 사무실 문을 열 수 있다.
Fine: 판교에서 근무하는 크루들은 근무시간 동안 사무실 문을 열고 닫을 수 있다.
Finer: 판교에서 근무하고 클라우드 파트 소속인 크루들은 A 프로젝트에 배정이 되어있다면, 근무시간 동안 사무실 문을 열고 닫을 수 있다.

Coarse -> Fine으로 갈수록 점점 세분화(granularity)되어 보안이 강화되는 것을 확인할 수 있다.

Access Control의 종류

Access Control의 종류는 크게 3가지로 나눌 수 있다.

Access Control List (ACL)

사용자가 인증된 후에, 해당 사용자의 IP가 인증된 사용자 리스트(White List) 또는 차단된 사용자 리스트(Black 리스트)에 있는지에 따라 Access를 허용하거나 차단한다. 사용자 IP가 White List에 없을 경우에도 차단된다.

즉, ACL은 특정 사용자의 시스템 액세스 권한 여부를 결정하는 데 사용된다.

Role-based access control(RBAC)

사용자의 역할에 따라 액세스 권한을 부여하는 방식이다.

RBAC에서 사용자는 다른 권한을 부여받을 수 있는 여러 역할을 가질 수 있다. 예를 들어 IT회사에서의 RBAC을 다음과 같이 나눠볼 수 있다.

시스템 관리자 역할: 서버 관리, 시스템 관리
데이터베이스 관리자 역할: 데이터 베이스 관리, 복구
네트워크 관리자 역할: 네트워크 관리, 보안 설정

총 관리자는 각 권한을 부여/회수하는 것이 간단하고, 역할에 따라 어떤 권한을 갖고 있는지 쉽게 파악할 수 있다.

하지만 한계가 있다. 다음과 같은 경우를 살펴보자.
시스템 관리자가 데이터베이스의 역할도 부여받고 싶은데, 시스템 관리자의 역할이 주 업무이므로 데이터 베이스 관리 중 삭제, 복구는 불가능하도록 하고 싶다. 이럴 경우 어떻게 해야 할까?

다른 역할을 또 만들어야 한다.

시스템 & 데이터 관리자 역할: 서버 관리, 시스템 관리, 삭제 기능을 제거한 데이터 베이스관리

이때 또 네트워크 관리자 역할도 부여받는다면... 점점 역할이 많아지고 복잡해진다.

Attribute-based access control(ABAC)

역할 대신 속성을 이용하여 더 세밀하게 권한을 부여할 수 있다. 위의 RBAC의 한계를 개선할 수 있다.

속성은 사용자, 리소스, 작업, 개체, 환경 등을 설명하는 데이터다.

예를 들어, 특정 부서의 크루가 파일에 접근하려면 아래의 속성을 전부 갖고 있어야 한다.

사용자: 해당 부서 직원
리소스: 파일
동작: 읽기/쓰기
환경: 해당 부서의 컴퓨터

이처럼 여러 속성을 활용하여 권한에 대해 좀 더 세밀한 작업을 할 수 있다.
만약 읽기만 가능하도록 하고 싶으면 `쓰기` 속성을 제거하고, 재택에서도 되도록 하려면 `재택` 속성만 추가하면 된다.

ACL -> RBAC -> ABAC 순으로 점점 Coarse -> Fine으로 되는 것을 확인할 수 있다.
Fine일수록 유연해지고 세밀한 접근제어를 할 수 있지만, 그만큼 구현이 어렵고 관리포인트가 많아진다는 단점이 있다.

REFERENCES

dontcryme님 블로그 - https://blog.naver.com/dontcryme/30124306779

What is Fine-Grained Access Control? - https://www.immuta.com/blog/what-is-fine-grained-access-control-and-why-its-so-important/

What Is Fine-Grained Access Control? - https://www.styra.com/blog/what-is-fine-grained-access-control/

Coarse-grained vs. fine-grained access control - https://www.webfarmr.eu/2011/05/coarse-grained-vs-fine-grained-access-control-part-i/

[React] ChatGPT와 구글 스프레드 시트를 이용한 i18n작업

SooJae — Mon, 27 Feb 2023 20:50:35 +0900

ChatGPT

최근 ChatGPT가 핫하다. 필자도 프로그래밍 관련 질문들은 구글링 하기 전에, 먼저 ChatGPT에게 물어본다.

내 무습다.. 와 내 생각을 읽을라 카는데..

놀라운 부분은 필자가 `adopt`라는 scope function이 kotlin에 있지 않냐고 물어봤더니, 없다고 하는 것에 그치지 않고,
`adopt`의 늬앙스가 `apply`, `also`와 유사하여 사용자가 헷갈린 것이라 판단해, `apply`와 `also`에 대해 설명해 준다.

이 뛰어난 기능을 어딘가에 활용해볼까 고민하던 중, ChatGPT의 확장 프로그램을 구글 스프레드 시트에 설치하여 활용할 수 있다는 소식을 듣고, 구글 스프레드 시트로 작업한 i18n에 활용하기로 결정했다.

구글 스프레드 시트를 이용한 i18n 자동화 방법은 아래 게시물을 보는 것을 추천한다. 이런 게시물을 볼 때마다 정말 대단한 개발자 분들이 많다는 생각이 든다.

국제화(i18n) 자동화 가이드 : NHN Cloud Meetup

프런트엔드 개발을 하다 보면 국제화와 번역을 수작업과 막일로 하는 경우가 있습니다."복붙"이나 반복적인 수작업으로 인해 고통받는 모든 프런트엔드 개발자를 자동화 가이드를 작성하였습

meetup.nhncloud.com

우선 구글 스프레드 시트 API를 이용하기 위해서는 아래 작업이 필요하다.

[React] 구글 스프레드 시트 API 이용하기(with google-spreadsheet)

버전 정보 react: ^18.2.0 react-scripts: ^4.0.2 (5버전은 에러가 너무 많이 나서 다운그레이드) google-spreadsheet: ^3.3.0 구글 스프레드 시트 API 구글 스프레드 시트 API를 이용하여 받아온 데이터를 React에서

soojae.tistory.com

구글 스프레드 시트 작업이 완료되었다면, 이제 ChatGPT 사용을 위한 작업을 진행하자.

구글 스프레드 시트에 ChatGPT 확장 프로그램 설치

OpenAI API 플랫폼 페이지에 접속한다.

OpenAI API

An API for accessing new AI models developed by OpenAI

platform.openai.com

프로필을 눌러 View API keys메뉴 -> ~~Create new secret key~~를 눌러 API 키를 발급한 후, 복사한다.

확장 프로그램 -> 부가기능 설치하기 클릭

마켓플레이스에서 ChatGPT 를 검색하여 GPT for Sheets를 설치한다.

아래와 같이`Set API key`-> 발급 받은 API 키 값을 적용한다.

구글 스프레드 시트의 `GOOGLETRANSLATE` 기능을 사용하면 해당 키 값에 대한 번역을 해준다. (1차로 번역)
`GPT_TRANSLATE()` 함수를 사용하지 않는 이유는, `GOOGLETRANSLATE`과 번역 품질이 비슷하다. GPT는 호출 할때마다 과금이 되니 그냥 `GOOGLETRANSLATE`를 사용했다.

`키`값을 기준으로 `GOOGLETRANSLATE` 기능을 사용하여 각 국가의 언어로 번역해준다.

하지만 `키`값에 오타나, 영어가 아닌 언어, 잘못된 영어 문장이더라면(파란색 테두리) 확인이 불가능하다.
이때 ChatGPT를 사용하여 이를 체크하고 수정해보자.

위의 `문장 체크 실행셀`을 체크하면 아래와 같이 값을 출력한다.

만약 값이 올바르다면 OK를 출력하고, 그렇지 않다면 올바른 값으로 수정되도록 만들었다. 그럼 ChatGPT가 고쳐준 값으로 다시 체크해보자.

고쳐준 값 전부 통과했다.
GPT 함수의 형식은 다음과 같다

GPT("GPT를 적용 할 prompt", "참조할 셀", "Temperature (0~1값. 0에 가까울 수록 보수적, 1에 가까울수록 창의적인 답변을 리턴한다.)")

위에 작성한 `문장 체크 결과`의 GPT 함수는 다음과 같다.

GPT("Is this a correct word or sentence with no typos in English? If it is, just show 'OK', if it is wrong, correct it. This word or sentence is: ", A7, 0.1)

사용 후기

ChatGPT를 활용하여 구글 스프레드 시트 작업을 더욱 효율적으로 할 수 있었다.

물론 아직은 번역의 품질이나, 정보의 정확성 등. 부족한 면이 아직 보이지만 이것도 GPT의 버전이 올라가면서 고쳐질 것이라 생각한다.
구글이나 메타 등의 AI 서비스들이 출시되면 이런 서비스들의 발전이 더 가속화 될 것 같다.

그렇게 되면 가까운 미래에는 AI가 수 많은 직업을 대체할 것 같다. 개발자, 특히 코드 작성만 할 줄 아는 개발자는 대체될 가능성이 높을 것 같다.

대체 불가능한 개발자가 되도록 더 열심히 공부하고 노력해야겠다.

창의적인 아이디어, 복잡한 문제 해결 능력 갖췄던데...?

그럼 이제 구글 스프레드 시트를 이용하여 React에서 i18n을 작업해보자!

Reference

gpt-for-sheet - https://gptforwork.com/gpt-for-sheets/get-started

프론트엔드 테스트 - TDD와 종류(Unit, Integration, E2E)

SooJae — Mon, 27 Feb 2023 00:45:52 +0900

테스트 주도 개발(TDD)이란?

TDD는 Test-Driven Development의 약자로 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성하는 개발 프로세스다. TDD 프로세스는 다음 단계를 따른다.

테스트 코드 작성: 우선 구현하려는 동작을 설명하는 테스트 코드를 작성한다. 이때, 아직 동작을 구현하는 코드를 작성하지 않았으므로 테스트는 실패 해야한다.
테스트 실행: 테스트를 실행한다. 위에 언급했듯이, 코드를 작성하지 않았으므로 실패해야한다.
코드 작성: 1번에 작성했던 설명에 부합하는 코드를 작성한다. 이때 테스트를 통과하기 위한 목적으로만 작성해야한다.
즉 아직 존재하지 않은 많은 문제들을 생각하여 코드를 작성하기보다는 테스트 목표에 집중하여 작성하는 것이 중요하다.
테스트 실행: 테스트를 다시 실행한다.
리팩터링: 테스트를 통과하면 코드를 리팩터링 한다.

TDD의 이점

테스트를 먼저 작성함으로써, 개발자는 구현하려는 동작에 대해 먼저 생각하게 되어 특정한 요구사항에 맞는 코드를 작성할 수 있다.
코드의 유지보수성을 향상시키고, 시간이 지나도 프로젝트의 유지 관리가 쉬워진다.
코드 수정 시 미처 생각지 못한 부분(기존 코드에 영향을 받는)에 대한 문제점을 미리 파악할 수 있다.
애플리케이션에 대한 신뢰성이 높아진다.
테스트 코드는 동작 방식을 설명하니, 테스트 파일 자체를 문서로 활용할 수 있다.
각종 에러 케이스에 대한 생각을 많이 하게 되므로 두뇌 건강에 좋다.

테스트 종류

잠금(Unit) 테스트는 통과. 잠금과 상호 작용하는 문(Integration) 테스트는 실패

단위 테스트(Unit Test)

툴: Jasmine, Jest, Karma, Mocha

단위 테스트는 함수나 메서드와 같은 작은 단위의 코드를 테스트하는 데 중점을 두는 테스트 유형이다. 즉, 시스템의 전체적인 동작에 중점을 맞추지는 않는다.
단위 테스트의 목적은 코드의 각 단위가 예상대로 작동하고 요구 사항을 충족하는지 확인하는 것이다.

예: 카카오 프렌즈샵에서 상품을 구매하는 경우, 단위 테스트는 `구매` 기능을 테스트할 때 고객의 잔액에서 상품의 금액 만큼 출금하는지, 상품의 재고를 업데이트 하는지, 영수증을 잘 생성하는지 각각 확인한다.

코드 예시

import { render } from '@testing-library/react';
import Item from '../components/Item';

describe('Item', () => {
  it('should render item name and price', () => {
    const { getByText } = render(
      <Item name="Test Item" price={12000} addToCart={() => {}} />
    );
    expect(getByText('Test Item')).toBeInTheDocument();
    expect(getByText('Price: 12000')).toBeInTheDocument();
  });
  
  it('should remove item stock', () => {
  // ... 
  });
  // ...
});

통합 테스트(Integration Test)

툴 종류: Jest, Testing Library

통합 테스트는 시스템의 여러 단위 또는 구성 요소 간의 상호 작용을 검증하는 테스트 유형이다.
서로 다른 단위가 함께 동작하면서 흐름에 맞게 잘 동작하고, 예상한 결과를 생성하는지를 테스트한다.

예: 카카오 프렌즈샵에서 상품을 구매하는 경우, 통합 테스트는 `구매`시 고객의 잔액, 재고 업데이트, 영수증 생성시 다른 구성 요소 간의 상호 작용이 잘 되어 구매가 완료되는지 확인한다.

코드 예시

import { render, screen, fireEvent } from '@testing-library/react';
import Shop from '../pages/shop';

describe('Shop', () => {
  it('should display receipt after checkout', () => {
    render(<Shop />);
    const item1Button = screen.getByText('Item 1');
    const item2Button = screen.getByText('Item 2');
    const cartItems = screen.getAllByTestId('cart-item');
    const checkoutButton = screen.getByText('Checkout');
    const receiptItems = screen.getAllByTestId('receipt-item');
    const total = screen.getByTestId('receipt-total');

    // 장바구니에 상품 추가
    fireEvent.click(item1Button);
    fireEvent.click(item2Button);
    expect(cartItems).toHaveLength(2);

    // 장바구니에서 상품 제거
    const removeButton = cartItems[0].querySelector('button');
    fireEvent.click(removeButton);
    expect(cartItems).toHaveLength(1);

    // 상품을 구매하고, 영수증 출력
    fireEvent.click(checkoutButton);
    expect(receiptItems).toHaveLength(1);
    expect(receiptItems[0]).toHaveTextContent('Item 2 - 12000원');
    expect(total).toHaveTextContent('Total: 16000원');
  });
});

E2E 테스트 (End-To-End Test)

툴 종류: Cypress, Puppeteer

E2E 테스트는 시스템의 시작부터 끝까지 전체 흐름을 확인하는 테스트 유형이다.
시스템이 예상대로 작동하고 사용자의 요구 사항을 충족하는지 확인하기 위해 모든 구성 요소와 해당 구성 요소의 상호 작용을 테스트하는 것이 포함된다.

예: 카카오 프렌즈샵에서 상품을 `구매`하는 경우

고객이 카카오 로그인
상품을 선택하여 장바구니에 추가
상품 구매
결제 방식 선택
구매 완료
구매 영수증을 고객 메일로 전송

위의 예시처럼 사용자의 입장에서 전체 Flow가 정상적으로 동작을 하는지 확인한다.

코드 예시

const puppeteer = require('puppeteer');

describe('Shopping', () => {
  let browser;
  let page;

  beforeAll(async () => {
    // 테스트 환경 설정
    browser = await puppeteer.launch();
    page = await browser.newPage();
    await page.goto('http://localhost:3000');
    await page.type('[data-testid="login-email"]', 'user@example.com');
    await page.type('[data-testid="login-password"]', 'password');
    await page.click('[data-testid="login-button"]');
    await page.waitForNavigation();
  });

  afterAll(async () => {
    // 브라우저 종료
    await browser.close();
  });

  it('should allow a user to buy an item and receive a receipt', async () => {
    // 상품을 장바구니에 추가
    await page.click('[data-testid="item-123"]');
    await page.click('[data-testid="add-to-cart-button"]');
    await page.click('[data-testid="cart-icon"]');

    // 장바구니의 추가된 상품 체크
    const cartItem = await page.waitForSelector('[data-testid="cart-item"]');
    expect(await cartItem.evaluate(el => el.innerText)).toContain('Item 1');

    // 아이템 구매 
    await page.click('[data-testid="checkout-button"]');
    await page.click('[data-testid="confirm-purchase-button"]');
    await page.waitForSelector('[data-testid="receipt"]');

    // 영수증 화면 출력
    const receiptItems = await page.$eval('[data-testid="receipt-items"]', el => el.innerText);
    expect(receiptItems).toContain('Item 1');
    expect(receiptItems).toContain('12000 원');
    const receiptTotal = await page.$eval('[data-testid="receipt-total"]', el => el.innerText);
    expect(receiptTotal).toContain('Total: 16000 원');

    // 영수증을 고객 메일로 전송
    await page.click('[data-testid="send-receipt-button"]');
    const receiptSent = await page.waitForSelector('[data-testid="receipt-sent"]');
    expect(await receiptSent.evaluate(el => el.innerText)).toContain('Receipt sent to user@example.com');
  });
});

위에서 사용한 테스팅 라이브러리인 Puppeteer와 Jest에 대해 좀 더 알아보고 싶다면, 아래 포스트들을 읽어보는 것을 추천한다.

Puppeteer

[test tool 1] Puppeteer란?

소개 puppeteer은 구글에서 만든 노드 라이브러리로 Headless Chrome 또는 Chrominum을 제어할 수 있다. * headless? 백그라운드에서 작동하는 브라우저이다. 때문에 일반 사용자가 브라우저를 사용할 때처럼

kkangdda.tistory.com

Jest

Jest Tutorial: A Comprehensive Guide With Examples And Best Practices

This tutorial dive deep into every aspect of the Jest framework (i.e., installation, configuration, etc.) and test execution on local & cloud grids. The learnings of this Jest tutorial can be utilized in using Jest in an ideal manner in your project

www.lambdatest.com

그냥 E2E로만 테스트하면 안 될까?

위의 코드를 보면 어차피 Unit, Integration 테스트 코드를 작성해도, 실제로 사용자는 E2E 방식으로 동작할텐데 굳이 시간 써가면서 각 코드를 써야할까라는 생각이 든다.
사실 Unit, Integration에서 테스트 했던 내용들은 E2E 테스트로 확인할 수 있고, 테스트가 중복되는 경우가 많다.

하지만, Unit이 E2E보다 테스트 실행 시간이 훨씬 빠르다. 그리고 세분화 할수록 어떤 에러가 발생했는지도 빠르게 체크 할 수 있다. 정리하면 다음과 같다.

E2E만 사용할 경우(granularity가 낮을 수록)

테스트 코드 작성 시간 ↑
유지보수 비용 ↑
이슈 발생 시, 문제 해결 시간 ↓

E2E, Integrationm, Unit을 사용할 경우(granularity가 높을 수록)

테스트 작성 시간 ↓
유지보수 비용 ↓
이슈 발생 시, 문제 해결 시간 ↑

어떤 방식이 특별히 나쁘다라고 단언할 수는 없다. 각각의 Trade Off가 존재한다. 어느 정도까지 세분화를 할지는 프로젝트 규모와 개발 기한에 따라 달라질 것이다.

간단 팁

필요없는 테스트는 넘어가도 된다: 예를 들어 데이터베이스를 연결이 잘 되는지는 프론트엔드와 관련이 없으므로 테스트할 필요가 없다. 이에 대한 것은 따로 Unit 테스트를 할 필요가 없다.
E2E 테스트가 가장 우선시 되야한다: 결국은 사용자 관점으로 봐야하므로 E2E 테스트가 가장 우선시 되야한다. 하지만 동작 Flow와 관련 없는 것들은 세분화하자 (예: 프렌즈 샵의 상품의 재고를 표시하는 것은 굳이 E2E 테스트에서 확인할 필요가 없다.)
함수의 기능이 `단순한 연결`일 경우는 작성하지 않아도 된다: 예를 들어 NextJS의 getStaticProps는 데이터를 갖고와서 props에 넘겨주기만 하는 함수이다. 이 함수는 테스트할 필요가 없다. (함수 내에 데이터를 변환하거나 복잡한 로직이 있으면 모를까)

[Intellij] 인텔리제이에 ChatGPT 플러그인 적용

SooJae — Sun, 26 Feb 2023 00:11:03 +0900

23년 3월 11일 - ChatGPT 플러그인 2.1.3 버전 기준으로 정보 업데이트

이제 Intellij에도 ChatGPT 플러그인을 적용할 수 있다.

ChatGPT 플러그인 설치

1. Preferences... 메뉴( Mac 단축키: ~~Command + ,~~ ) - > Plugins -> ChatGPT 플러그인 설치

2. https://platform.openai.com/account/api-keys 에 로그인하고 API 키 발급

3. 인텔리제이 사이드 바에 ChatGPT 아이콘 클릭 후, 설정 아이콘 클릭

4. Official API키를 추가한다. (직접 ChatGPT에 요청을 보내는 API 서버를 만들었다면, Customize에 API 주소를 넣으면 된다.)

※ Email과 Password를 입력하고 로그인하면, 정보 저장은 절대 안하고 자동으로 토큰을 refresh 해준다고는 하는데... 굳이?
Access Token만 넣는게 안전해보여서 Access Token만 넣었다.

4-1. GPT 3.5 Turbo도 설정해서 사용할 수 있다. GPT-3.5란?

4-2. 자신만의 Custom Actions를 지정할 수 있다. (~~ChatGPT 플러그인 사용법~~ - ~~코드 요청~~에서 설명)

ChatGPT 플러그인 2.0 버전일 경우 설정

4. Offical 에 API Key를 추가한다.

연결 세팅 값

Read Timeout : GPT가 질문에 답변하기까지 대기할 수 있는 시간. 초과시 연결이 끊어진다. ( 네트워크 상태가 좋지 않으면 시간을 더 길게 변경할 수 있다. )

Connection Timeout : GPT에 연결되기까지 대기할 수 있는 시간. 초과시 연결이 끊어진다. (네트워크 상태가 좋지 않으면 시간을 더 길게 변경할 수 있다.)

ChatGPT 플러그인 사용법

기본 요청

아래와 같이 질문을 작성하면 GPT가 답변해준다.

아래 Search History를 클릭하면 사용자가 인텔리제이에서 찾았었던 (Mac 단축키: ~~Command + Shift + F~~) 값들에 대한 목록이 나온다.

코드 요청

코드 블럭을 지정한 후에 우클릭을 하면 preset 들을 이용하여 질문할 수 있다.

코드 선택후 Explain prefix를 사용한 결과

위의 요청 preset 목록 중 ~~Custom Actions~~를 누르면 위에 작업 했던 Custom Actions를 사용할 수 있다.

위 팝업에서 `Add Custom Action`을 누르면 요청을 보내기 쉽게 모달창을 띄워준다. (주로 사용하는 기능)

위 기능은 주로 사용하는 기능이다보니 단축키를 지정하는 것이 좋다. 제공해주는 단축키가 있긴한데, 기본 단축키가 Mac 기준으로 `Shift + Command + Q`로 되어있다.
그런데 이건 Mac 로그아웃 단축키라 키가 안먹히는데... 다른 단축키로 변경하자.

WebStorm -> Preferences... -> Keymap -> Plugins -> ChatGPT -> `Ctrl + Shift + C`로 변경

이렇게 설정하면 Extension selection( Mac 단축키 : `Option + ↑` )와 조합하여 야무지게 사용할 수 있다.

선택 범위를 지정한 후 Custom Action 실행

`Online Chat` 탭을 누르면 직접 ChatGPT 사이트에 접속해서 사용할 수 있지만, 현재는 사용할 수 없다.

현재 ChatGPT가 오픈된 지 얼마 안 됐지만, 이미 여러 개발자들이 ChatGPT를 활용한 다양한 플러그인들을 개발하고 있다.

앞으로 ChatGPT 버전이 업데이트 되면서 얼마나 많은 것들이 바뀔지 기대된다.

[React] Module not found: Can't resolve 'http2' in ~

SooJae — Fri, 24 Feb 2023 04:32:04 +0900

문제 발생

React에서 googleapis 라이브러리를 사용해보려고 했더니 다음과 같은 에러가 발생했다.

원인은 간단했다. googleapis가 Node.js에서만 동작하는 라이브러리기 때문이다.

npm을 잘 읽자...

해결 방법

해당 라이브러리는 Nodejs (express, nestjs 등)에서만 동작하는 라이브러리다. 사용하지 말자.

[React] 구글 스프레드 시트 API 이용하기(with google-spreadsheet)

SooJae — Wed, 22 Feb 2023 20:56:27 +0900

버전 정보

react: ^18.2.0
react-scripts: ^4.0.2 (5버전은 에러가 너무 많이 나서 다운그레이드)
google-spreadsheet: ^3.3.0

구글 스프레드 시트 API

구글 스프레드 시트 API를 이용하여 받아온 데이터를 React에서 처리하려고 한다.

API를 이용하면 자바스크립트나 파이썬등에서 코드를 통해 시트 내용을 조회, 생성, 수정, 삭제를 할 수 있다.

이 작업은 주로 정적인 사이트에 활용하기 좋다. 또한, 구글 스프레드시트에 익숙한 기획자들과의 협업에도 큰 도움이 될 수 있다.

예를 들어, 기획자들이 스프레드시트에서 작업한 내용을 DB에 반영해야 하는 경우가 종종 있다. 하지만 스프레드시트의 데이터가 자주 업데이트되면, 이를 관리하는 데 상당한 노력이 필요하게 된다. 반대로, 개발 측에서 데이터를 수정하면, 그 변경 내용을 스프레드시트에도 반영해야 한다.

이런 상황에서 한쪽에서 변경된 내용이 실수로 전달되지 않으면, 스프레드시트와 개발 쪽의 데이터가 일치하지 않을 위험이 있다.

이럴 때 구글 스프레드시트 API를 사용하면 두 매체 간의 데이터를 자동으로 동기화할 수 있어, 이러한 문제를 효과적으로 해결할 수 있다.

구글 스프레드 시트 API 등록 과정

우선 https://console.cloud.google.com/apis/credentials로 이동하여 프로젝트를 생성한다.

프로젝트를 생성 후에 서비스 계정을 생성한다.

사용자 인증 정보 화면의 서비스 계정 부분에 생성된 계정을 클릭하여 키를 추가한다.

키 추가가 완료되면, 해당 키값이 들어있는 json파일이 다운로드된다.

구글 스프레드 시트 API 활성화

처음 구글 스프레드 시트를 만들고, 위의 파일을 적용하면 API가 닫혀있어서 403 에러가 발생한다.

다음과 같이 API를 사용 상태로 수정하자.

권한 부여

위와 같이 작업 했더라도, 공유가 안되어 있어서 메시지만 다른 403 에러가 발생한다.

서비스 계정 목록에 있는 계정을 추가하자. 키 생성시 다운로드 받은 json파일에도 client_email이 존재한다.

스프레드 시트를 입맛에 맞게 만든다. 이때 Document ID와 worksheet ID값을 복사한다.

React 작업

$yarn add google-spreadsheet --dev

# 타입 스크립트를 사용할 경우
$yarn add @types/google-spreadsheet --dev

정상적으로 동작하는지만 확인하면 되기에 간단하게 작성했다.

위에서 다운로드 받은 파일을 적절한 위치에 넣은 후 require하고, 바로 위에서 복사한 Document ID 값을 넣어준다.

// src/libs/googlesheet.ts

import {GoogleSpreadsheet, GoogleSpreadsheetRow} from "google-spreadsheet";
import {useEffect, useState} from "react";

const credential = require(키 추가한 후 다운로드된 json파일 위치);

// 구글 시트 조회하는 로직
export const getGoogleSheet: () => Promise<GoogleSpreadsheet> = async () => {
    const doc = new GoogleSpreadsheet(Document ID 값 넣는 곳);
    // 구글 인증이 필요하다.
    await doc.useServiceAccountAuth(credential);
    await doc.loadInfo();
    return doc;
}

// 구글 시트 조회하는 custom useHook
const useGoogleSheet = (sheetId: string) => {
    const [googleSheetRows, setGoogleSheetRows] = useState<GoogleSpreadsheetRow[]>([]);

    const fetchGoogleSheetRows = async () => {
        const googleSheet = await getGoogleSheet();
        const sheetsByIdElement = googleSheet.sheetsById[sheetId];
        const rows = await sheetsByIdElement.getRows();
        setGoogleSheetRows(rows)
    }

    useEffect(() => {
        fetchGoogleSheetRows();
    },[]);

    return [googleSheetRows];
}

export default useGoogleSheet;

worksheet ID값도 넣어준다.

// src/App.tsx

const App = () => {

    const [data] = useGoogleSheet(worksheet ID 값 넣는곳);
    const languageList = ['아이디','설명'];

    return (
        <div>
            {data.map((row) => {
                return (<div>아이디: {row[languageList[0]]}, 설명: {row[languageList[1]]}</div>);
            })}
        </div>
    )

}

export default App;

React를 실행하면 정상적으로 받아오는 것을 확인할 수 있다.

Refereneces

thenewstack 사이트 - https://thenewstack.io/how-to-use-google-sheets-as-a-database-with-react-and-ssr

[Next.JS] SSG - getStaticPaths

SooJae — Tue, 21 Feb 2023 20:28:21 +0900

getStaticProps에 대해 익숙하지 않다면, 아래 글을 먼저 보는 것을 추천 드립니다.

[Next.JS] SSG - getStaticProps

getStaticProps SSG(Static Site Generator)는 페이지를 호출할 때마다 서버에서 pre-render하는 SSR와 달리 빌드시점에 pre-rendering을 한다. // posts는 빌드 시점에 getStaticProps()에 의해 채워진다. function Blog({ posts }

soojae.tistory.com

getStaticPaths

동적 경로를 사용하는 페이지에서 getStaticPaths라는 함수를 사용할 때 Next.js는 getStaticPaths에 지정된 모든 경로를 정적으로 미리 렌더링한다.

paths

paths값은 pre-rendering할 경로를 결정한다. 예를 들어 pages/posts/[id].js라는 이름의 동적 경로를 사용하는 페이지가 있다고 가정해보자. 이 페이지에서 getStaticPaths 메서드를 통해 다음을 return한다면

export async function getStaticPaths() {
    return {
      paths: [
        { params: { id: '1' }},
        {
          params: { id: '2' },
          // i18n을 구성하면 경로에 대한 locale도 return할 수 있다.
          locale: "en",
        },
      ],
      fallback: true, false 또는 "blocking" 
    }
}

위와 같이 작성하면 /posts/1 와 /posts/2이 `next build`시에 정적으로 페이지가 생성된다.

페이지 이름이 `pages/posts/[postId]/[commentId]`인 경우 params에는 `postId`와 `commentId`가 포함되어야 한다.
페이지 이름이 `pages/[...slug]`와 같은 포괄 경로를 사용하는 경우 매개변수에는 배열인 slug가 포함되어야 한다. 이 배열이 `['hello', 'world']`인 경우 Next.js는 /hello/world에 페이지를 정적으로 생성한다.
페이지에서 optional catch-all-route를 사용 할때, `null, [], undefined, false`를 사용하여 루트 최상위 경로를 렌더링한다. 예를 들어, `pages/[[...slug]]`에 `slug: false`를 제공하면 Next.js는 `/` 페이지를 정적으로 생성한다.
params는 case-sensitive하다. 그래서 Posts와 posts는 다른 경로로 인식한다.

Fallback 옵션

false일 경우

getStaticPaths에서 return하지 않은 path는 404 페이지를 return한다.
이 옵션은 생성할 경로 수가 적거나 새 페이지 데이터를 자주 추가하지 않는 경우에 유용하다
경로를 더 추가해야 하는데 `fallback: false`로 설정한 경우 빌드를 다시 실행해야 한다.

true일 경우

getStaticProps의 동작은 다음과 같은 방식으로 변경된다.

getStaticPaths에서 return된 경로는 빌드 시 getStaticProps에 의해 HTML로 렌더링된다.
빌드 시점에 생성되지 않은 경로는 404 페이지가 생성되지 않는다. 대신 Next.js는 해당 경로에 대한 첫 번째 요청 시 페이지의 "fallback" 버전을 제공한다. 구글과 같은 웹 크롤러는 fallback이 제공되지 않고, `path`는 `fallback: blocking`처럼 동작한다.
`fallback: true`로 설정된 페이지가 `next/link` 또는 `next/router`(클라이언트 측)를 통해 탐색되는 경우 Next.js는 fallback을 제공하지 않고 대신 페이지가 `fallback: blocking`으로 동작한다.
백그라운드에서 Next.js는 요청된 경로 HTML과 JSON을 정적으로 생성한다. 이때 getStaticProps도 실행된다.
완료되면 브라우저는 생성된 경로에 대한 JSON을 수신한다. 이는 필요한 props들이 포함된 페이지를 자동으로 렌더링하는 데 사용된다. 사용자 입장에서는 페이지가 fallback 페이지에서 full 페이지로 바뀐다.
동시에 Next.js는 이 경로를 미리 렌더링된 페이지 목록에 추가하여 동일한 경로에 요청이 들어오면, 빌드 할 때 pre-rendering된 페이지들과 마찬가지로 동작한다.

`fallback: true`는 next export를 사용할땐 동작하지 않는다.

fallback: true는 언제 사용해야 할까?

앱 데이터에 의존하는 정적페이지가 매우 많은 경우(ex: 매우 큰 전자 상거래 사이트)에 유용하다. 모든 제품 페이지를 빌드 시간에 미리 렌더링 하는 것은 매우 오랜 시간이 걸린다.
대신 페이지의 작은 하위 subset을 정적으로 생성하고 나머지 페이지에 대해서는 `fallback:true`로 한다. 사용자가 아직 생성되지 않은 페이지를 요청하면 loading indicator 또는 skeleton 컴포넌트 페이지가 표시된다.
getStaticProps가 완료되면 요청된 데이터로 페이지가 렌더링된다.
`fallback: true`일 경우 생성된 페이지를 업데이트 할 수 없다. ISR을 확인하자

Blocking일 경우

true일 경우와 비슷하게 동작하지만, getStaticPaths가 return하지 않은 새 path는 SSR과 동일하게 HTML이 생성될 때까지 기다린 다음 이후 요청을 위해 캐시되어 `path`당 한 번만 발생한다.

getStaticPaths에서 return된 `path`는 빌드 시점에 getStaticProps에 의해 HTML로 렌더링된다.
빌드 시점에 생성되지 않은 경로는 404 페이지가 생성되지 않는다. 대신 Next.js는 첫 번째 요청에 대해 SSR을 수행하고 생성된 HTML을 return한다.
완료되면 브라우저는 생성된 경로에 대한 HTML을 수신한다. 사용자 입장에서는 "브라우저가 페이지를 요청 중"에서 "전체 페이지가 로드됨"으로 전환된다. 로딩/폴백 상태의 플래시가 표시되지 않는다.
동시에 Next.js는 이 경로를 미리 렌더링된 페이지 목록에 추가한다. 동일한 경로에 대한 후속 요청은 빌드 시 미리 렌더링된 다른 페이지와 마찬가지로 생성된 페이지를 제공한다.
`fallback: 'blocking'`일 경우 생성된 페이지를 업데이트를 하지 않는다. 업데이트 하려면 ISR도 함께 사용해야한다.

`fallback: true`는 next export를 사용할땐 동작하지 않는다.

Fallback 페이지

페이지의 props가 비어있다.
`router`를 사용하면 fallback이 렌더링 되고있는지 감지할 수 있고, 렌더링 되는 중이라면 `router.isFallback` 값은 true를 return한다.

// pages/posts/[id].js
import { useRouter } from 'next/router'

function Post({ post }) {
  const router = useRouter()

  // 만약 page가 아직 생성되지 않았으면 getStaticProps()가 끝날때까지 
  // `<div>Loading...</div>`이 보여진다.
  if (router.isFallback) {
    return <div>Loading...</div>
  }

  // post관련 코드...
}

// build 시점에 이 메서드가 호출된다.
export async function getStaticPaths() {
  return {
    // `/posts/1` 과 `/posts/2`에 대한 페이지만 생성된다.
    paths: [{ params: { id: '1' } }, { params: { id: '2' } }],
    // fallback 값이 true이므로 정적으로 추가 페이지 생성할 수 있다.
	// 예: `/posts/3`
    fallback: true,
  }
}

// build 시점에 이 메서드가 호출된다.
export async function getStaticProps({ params }) {
  // params은 id값을 갖고 있다. `id`.
  const res = await fetch(`https://.../posts/${params.id}`)
  const post = await res.json()

  return {
    props: { post },
    // 요청이 들어올 때, 최대 10초마다 한 번 페이지를 재생성한다.
    revalidate: 10,
  }
}

export default Post

Fallback 테스트

※ 테스트 코드는 제 깃허브(https://github.com/SooJae/nextjs-ssg-fallback)에서 확인하실 수 있습니다.

getStaticPaths 메서드에서 id가 1~5인 유저 리스트를 조회하여 path를 return한다.
getStaticProps 메서드에서 해당 페이지에 접근할 경우 해당 id의 사용자를 조회한다. 조회 전 의도적으로 getStaticProps의 실행을 늦추기 위해 sleep 시간을 1초로 지정한다. (Fallback이 true일때와 'blocking'일때의 비교를 하기위해)
http://localhost:3000/users/{id} 경로로 접근

이때 각 Fallback값에 따라 결과가 어떻게 바뀌는지 확인해보자.

`$ yarn dev` 실행시 페이지에 매번 접근할 때마다 getStaticProps가 호출되므로 정확한 테스트를 위해,
`$ yarn build && yarn start`로 실행하여 배포할 때와 똑같은 환경으로 테스트 하자

Fallback: false인 경우

// pages/users/[id].tsx

import {GetStaticPropsContext} from "next";
import axios from "axios";

interface User {
    id: number,
    name: string,
    username: string,
    email: string
}

interface UserDetailPageProps {
    user: User
}

export const UserDetailPage = ({user}: UserDetailPageProps) => {
    return (
        <div>
            {user.id} / {user.name} / {user.email}
        </div>
    )
}

export const getStaticPaths = async () => {

    const {data: users}: { data: User[] } = await axios.get('https://jsonplaceholder.typicode.com/users');
    // 유저 리스트에서 5명.
    const partialUserList = users.slice(0, 5);
    const paths = partialUserList.map(user => ({params: {id: user.id.toString()}}));

    return {
        paths,
        fallback: false,
        // fallback: true,
        // fallback: 'blocking',
    }
}

export const getStaticProps = async (context: GetStaticPropsContext) => {
    const id = context.params?.id || '';

    await sleep(1000); // 사실 fallback: false일 경우에는 영향이 없다.

    const {data: user}: { data: User } =
        await axios.get(`https://jsonplaceholder.typicode.com/users/${id}`);

    return {
        props: {
            user
        }
    }
}

const sleep = (ms: number) => {
    return new Promise(resolve => setTimeout(resolve, ms))
}


export default UserDetailPage;

결과

존재하지 않는 path({id: 7}) 페이지에 접근하면 404 에러 페이지가 나온다.

Fallback: true인 경우

// pages/users/[id].tsx

import {GetStaticPropsContext} from "next";
import axios from "axios";
import {useRouter} from "next/router";

interface User {
    id: number,
    name: string,
    username: string,
    email: string
}

interface UserDetailPageProps {
    user: User
}

export const UserDetailPage = ({user}: UserDetailPageProps) => {
    const router = useRouter();
    // fallback version
    if (router.isFallback) {
        return (
            <div>
                Loading...
            </div>
        )
    }
    return (
        <div>
            {user.id} / {user.name} / {user.email}
        </div>
    )
}

export const getStaticPaths = async () => {

    const {data: users}: { data: User[] } = await axios.get('https://jsonplaceholder.typicode.com/users');
    // 유저 리스트에서 5명.
    const partialUserList = users.slice(0, 5);
    const paths = partialUserList.map(user => ({params: {id: user.id.toString()}}));

    return {
        paths,
        // fallback: false,
        fallback: true,
        // fallback: 'blocking',
    }
}

export const getStaticProps = async (context: GetStaticPropsContext) => {
    const id = context.params?.id || '';

    await sleep(1000);

    const {data: user}: { data: User } =
        await axios.get(`https://jsonplaceholder.typicode.com/users/${id}`);

    return {
        props: {
            user
        }
    }
}

const sleep = (ms: number) => {
    return new Promise(resolve => setTimeout(resolve, ms))
}


export default UserDetailPage;

결과

존재하지 않는 `path`({id: 7}) 페이지에 접근하면 `Loading...`(sleep 1초)이 보이고 페이지가 생성된다.
이때 다른 페이지({id:1})로 이동했다가 다시 {id:7} 페이지로 접근하면 로딩없이 바로 나온다. 즉 페이지가 캐싱되었다는 것을 알 수 있다.
주의할 점은 `fallback:false` 때와 달리 위의 코드에서 19~27번 라인의 코드가 없으면, 아래와 같은 에러가 발생하고, 빌드에 실패한다. (https://nextjs.org/docs/messages/prerender-error)

Fallback: 'blocking'인 경우

// pages/users/[id].tsx

import {GetStaticPropsContext} from "next";
import axios from "axios";
import {useRouter} from "next/router";

interface User {
    id: number,
    name: string,
    username: string,
    email: string
}

interface UserDetailPageProps {
    user: User
}

export const UserDetailPage = ({user}: UserDetailPageProps) => {
    // const router = useRouter();
    // // fallback version
    // if (router.isFallback) {
    //     return (
    //         <div>
    //             Loading...
    //         </div>
    //     )
    // }
    return (
        <div>
            {user.id} / {user.name} / {user.email}
        </div>
    )
}

export const getStaticPaths = async () => {

    const {data: users}: { data: User[] } = await axios.get('https://jsonplaceholder.typicode.com/users');
    // 유저 리스트에서 5명.
    const partialUserList = users.slice(0, 5);
    const paths = partialUserList.map(user => ({params: {id: user.id.toString()}}));

    return {
        paths,
        // fallback: false,
        // fallback: true,
        fallback: 'blocking',
    }
}

export const getStaticProps = async (context: GetStaticPropsContext) => {
    const id = context.params?.id || '';

    await sleep(1000);

    const {data: user}: { data: User } =
        await axios.get(`https://jsonplaceholder.typicode.com/users/${id}`);

    return {
        props: {
            user
        }
    }
}

const sleep = (ms: number) => {
    return new Promise(resolve => setTimeout(resolve, ms))
}


export default UserDetailPage;

결과

탭의 로고를 보면 로딩 중인것을 확인할 수 있다.

Fallback: true일때와 비슷하지만, 페이지 생성 중에 fallback 버전의 페이지(`
Loading...
`)를 보여주지 않는다.
loading 상태를 확실히 보여주기 위해 sleep을 1초가 아닌 2초로 두었다. 즉 로딩시간 1초 이내면 사용자가 로딩 중인것도 인지하기 힘들다.

Fallback 값 true vs 'blocking'

시간이 짧은 로직일 경우 - true일 경우 화면이 loading 상태 -> 렌더링이 완료된 페이지로 바뀌는 찰나의 flickering(혹은 flashing)때문에 UX가 오히려 안 좋아진다. 이때는 blocking을 사용하는 것이 좋아 보인다.
시간이 긴 로직일 경우 - bloking일 경우 화면의 변화가 없기 때문에, 사용자 입장에서는 웹사이트에 에러가 발생한 것으로 인식될 수 있다. 그러니 오래걸리는 로직은 true로 두어 loading 상태를 보여주는 것이 좋아보인다.

REFERENCES

Next.js 공식 사이트 - https://nextjs.org/docs/basic-features/data-fetching/get-static-props#runs-on-every-request-in-development
mskwon님 블로그 - https://velog.io/@mskwon/next-js-static-generation-fallback

[Next.JS] SSG - getStaticProps

SooJae — Mon, 20 Feb 2023 19:51:11 +0900

getStaticProps

SSG(Static Site Generator)는 페이지를 호출할 때마다 서버에서 pre-render하는 SSR와 달리 빌드시점에 pre-rendering을 한다.

// posts는 빌드 시점에 getStaticProps()에 의해 채워진다.
function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li>{post.title}</li>
      ))}
    </ul>
  )
}

// 이 함수는 Server Side에서 빌드 타임에 호출된다.
// Client Side에서는 호출되지 않으므로 직접 데이터베이스 쿼리를 수행할 수도 있다.
export async function getStaticProps() {

  const res = await fetch('https://.../posts')
  const posts = await res.json()

  // Blog 컴포넌트는 빌드 시점에 'posts'를 프로퍼티로 받는다.
  return {
    props: {
      posts,
    },
  }
}

export default Blog

페이지 렌더링에 필요한 데이터는 사용자 request 전에 빌드 시점에서 사용할 수 있다.
headless CMS에서 데이터를 갖고 온다.
getStaticProps는 HTML과 JSON 파일을 생성하며, 이 두 파일은 성능을 위해 CDN에 캐싱할 수 있다.
데이터는 공개적으로 캐시될 수 있다(사용자별이 아님). 특정 상황에서는 미들웨어를 사용하여 경로를 다시 작성함으로써 이 조건을 우회할 수 있다.
항상 서버에서 실행되며 클라이언트에서는 실행되지 않는다.
`next build`가 실행될 때 동작한다.
페이지에서만 사용가능하다. 즉 _app, _document, _error 파일에선 사용이 불가능하다. React는 페이지가 렌더링되기 전에 필요한 모든 데이터를 가지고 있어야 하기 때문이다.
`next dev`로 실행하면, getStaticProps는 매 요청마다 호출된다.

Context Object

context 파라미터의 객체에는 아래의 key값들이 있다.

params: 페이지가 dynamic route인 경우, (ex: page 이름이 [id].js라면 {id: ...} 객체 return)
req - HTTP 요청 객체(서버 전용)
res - HTTP 응답 객체(서버 전용)
query - 객체로 파싱된 URL의 Query String (ex: /post?type=news 일 경우 {type:'news'} 객체 return)
preview: true일 경우 Preview Mode 모드
previewData: preview에서 사용되는 데이터. setPreviewData함수를 이용하여 설정할 수 있다.
resolvedUrl: 클라이언트 전환을 위해 _next/data 접두사를 제거하고, 원래 쿼리 값을 포함하는 정규화된 요청 URL 버전
(ex /post?type=news 일 경우 '/post?type=news' 문자열 return
locale: 현재 로케일 값
locales: 사용 가능한 로케일의 목록 값
defaultLocale: 기본 로케일 값

Server side 코드 직접 작성

getStaticProps는 Server side에서만 실행되고, Client Side에서는 실행되지 않는다.

브라우저용 JS번들에도 포함되지 않으므로 API Route를 통해 데이터를 갖고오는 대신 직접 Server side 코드 (데이터베이스 쿼리등)를 직접 사용할 수 있다.

// lib/load-posts.js

export async function loadPosts() {
  const res = await fetch('https://.../posts/')
  const data = await res.json()

  return data
}

// pages/blog.js
import { loadPosts } from '../lib/load-posts'

export async function getStaticProps(context) {

  const posts = await loadPosts()

  return { props: { posts } }
}

API 경로는 CMS에서 일부 데이터를 가져오는 데 사용된다. 그 다음 해당 API 경로를 getStaticProps에서 직접 호출한다. 이렇게 하면 추가 호출이 발생하여 성능이 저하된다.

성능이 저하되지 않는 방법으로 lib폴더를 이용하는 방법이있다. CMS에서 데이터를 가져오는 로직은 `lib/` 폴더를 사용하여 공유할 수 있다. 그리고 그 데이터를 getStaticProps와 공유할 수 있다.

lib 폴더

일반적으로 Next.js프로젝트에서 사용되는 JavaScript 모듈을 저장하는 폴더.

lib폴더는 컴포넌트 또는 페이지에 종속되지 않는 util 함수, API 클라이언트, 데이터 로드 함수 등과 같은 코드를 보관하는 데 사용된다.

util 함수 : getStaticProps에서 데이터를 가공하거나 페이지에서 사용되는 헬퍼 함수를 lib 폴더에 넣어 재사용성을 높일 수 있다.
API 클라이언트: getStaticProps에서 API를 호출할 때, 일반적으로 fetch나 axios와 같은 라이브러리를 사용한다. 이러한 API 호출 코드를 lib 폴더에 넣어 재사용성을 높일 수 있다.
데이터 로드 함수: getStaticProps에서 데이터를 불러올 때, 데이터베이스나 외부 API 등에서 데이터를 가져오는 로직을 lib 폴더에 넣어 재사용성을 높일 수 있다.

Return 값

revalidate

정적 페이지를 다시 생성하는 시간을 지정하는 옵션. 해당 시간이 지나면 Nextj.js는 캐시된 페이지를 버리고 새 페이지를 생성한다.
revalidate()메서드를 이용해서 on-demand 방식으로 시간을 지정할 수 있다.

Incremental Static Regeneration(ISR)을 활용하는 페이지의 캐시 상태는 x-nextjs-cache 응답 헤더의 값을 읽어서 확인할 수 있다. 가능한 값은 다음과 같다.

MISS - 경로가 캐시에 없다(첫 번째 방문 시 최대 한 번만 발생).
STALE - 경로가 캐시에 있지만 revalidate 시간을 초과하여 백그라운드에서 업데이트 된다.
HIT - 경로가 캐시에 있고 revalidate 시간을 초과하지 않았다.

notFound

notFound를 사용하면 페이지에서 404 상태와 404 페이지를 return할 수 있다.

`notFound: true`를 사용하면 이전에 성공적으로 생성된 페이지가 있더라도 404페이지를 return한다. 이는 사용자가 생성한 콘텐츠가 작성자에 의해 삭제되는 등의 경우를 위함이다.

export async function getStaticProps(context) {
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  if (!data) {
    return {
      notFound: true,
    }
  }

  return {
    props: { data },
  }
}

getStaticPaths의 fallback: false 모드일 땐 notFound가 필요하지 않다.
getStaticPaths에서 pre-rendering할때 미리 path 목록을 생성하는데, 그 목록에 없는 페이지에 접근하면 404페이지를 return하기 때문이다. 테스트 링크

redirect

redirect는 클라이언트를 다른 페이지로 redirection한다.

export async function getStaticProps(context) {
  const res = await fetch(`https://...`)
  const data = await res.json()

  if (!data) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
        // statusCode: 301
      },
    }
  }

  return {
    props: { data },
  }
}

위 코드의 경우 data가 없으면 `/`로 redirection 한다.

`destination` 속성을 사용하여 redirection할 URL을 지정할 수 있다.
`permanent` 속성을 사용하여 해당 redirection을 영구 redirection로 설정할 수도 있다.
일반적으로 `permanent` 속성을 true로 설정하면 redirection을 클라이언트 캐시에 저장하고, 301 HTTP 상태 코드를 return한다.
false로 설정하면 매번 새로운 redirection을 받고, 302 HTTP 상태 코드를 return한다.
`redirect`를 사용하여 클라이언트를 다른 페이지로 redirection할 때는, 반드시 올바른 HTTP 상태 코드를 사용하여 redirection해야한다.
드물지만 구형 HTTP 클라이언트가 올바르게 redirection되도록 custom statusCode를 할당해야 하는 경우가 있다. 이 경우 statusCode 속성을 사용할 수 있지만 permanent 속성과 같이 사용할 수는 없다.

HTML, JSON 정적 페이지 생성

빌드 시점에 getStaticProps가 포함된 페이지가 pre-rendering되면 페이지의 HTML파일과 JSON이 생성된다.

이 JSON 파일은 `next/link` 또는 `next/router`의 Client Side 라우팅에 사용된다. getStaticProps를 사용하여 pre-rendering된 페이지로 이동하면 Next.js는 이 JSON 파일을 가져와 페이지 구성요소의 프로퍼티로 사용한다.

증분 정적 생성(ISR) 을 사용하는 경우, 백그라운드에서 Client Side 네비게이션에 필요한 JSON을 생성한다.

동일한 페이지에 대해 요청이 여러번 발생하는 것으로 표시될 수 있지만, 이는 사용자 성능에는 영향을 미치지 않는다.

process.cwd() 메서드로 파일 읽기

getStaticProps를 이용해서 file을 읽을 수 있다.

Next.js는 코드를 별도의 디렉터리에 컴파일하므로 return하는 경로가 페이지 디렉터리와 다르다. 그래서 `__dirname`을 사용할 수 없다. 대신에 `process.cwd()` 메서드를 사용해서 파일을 갖고 올 수 있다.

import { promises as fs } from 'fs'
import path from 'path'

function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li>
          <h3>{post.filename}</h3>
          <p>{post.content}</p>
        </li>
      ))}
    </ul>
  )
}

export async function getStaticProps() {
  const postsDirectory = path.join(process.cwd(), 'posts')
  const filenames = await fs.readdir(postsDirectory)

  const posts = filenames.map(async (filename) => {
    const filePath = path.join(postsDirectory, filename)
    const fileContents = await fs.readFile(filePath, 'utf8')

    return {
      filename,
      content: fileContents,
    }
  })
  return {
    props: {
      posts: await Promise.all(posts),
    },
  }
}

export default Blog

다음 포스팅으로 이어집니다.

[Next.JS] SSG - getStaticPaths

getStaticProps에 대해 익숙하지 않다면, 아래 글을 먼저 보는 것을 추천 드립니다. [Next.JS] SSG - getStaticProps getStaticProps SSG(Static Site Generator)는 페이지를 호출할 때마다 서버에서 pre-render하는 SSR와 달

soojae.tistory.com

REFERENCES

Next.js 공식 사이트 - https://nextjs.org/docs/basic-features/data-fetching/get-static-props#runs-on-every-request-in-development

[Next.JS] SSR - getInitialProps, getServerSideProps

SooJae — Sun, 19 Feb 2023 15:30:37 +0900

getInitialProps, getServerSideProps, getStaticProps 전부 Server Side Rendering(SSR)을 위해 필요한 함수들이다. SSR은 서버에서 미리 데이터를 채운 페이지를 브라우저에 보여준다. 이는 특히 SEO 구현에 유용하다.

이번 시간은 getInitalProp와 getServerSideProps에 대해 알아보자.

각각의 렌더링 유형은 props를 페이지 컴포넌트로 전달된다. 초기 HTML가 내려왔을 때, 클라이언트 측에서 이 props 데이터를 확인 할 수 있다. 이는 페이지에서 적절한 hydrate를 위함이다.
그러므로 클라이언트에서 사용하면 안되는 민감한 정보(secret key등)를 props로 전달하면 안 된다.

getInitialProps

사실 getInitialProps는 Automatic Static Optimization을 사용하지 못하기 때문에 권장하지 않는다. getInitialProps는 비동기로 동작하며 원하는 페이지에 static method 로서 추가할 수 있다.

function Page({ stars }) {
  return <div>Next stars: {stars}</div>
}

Page.getInitialProps = async (ctx) => {
  const res = await fetch('https://api.github.com/repos/vercel/next.js')
  const json = await res.json()
  return { stars: json.stargazers_count }
}

export default Page

getInitialProps에서 return된 데이터는 서버 렌더링 시 JSON.stringify가 수행하는 것과 유사하게 직렬화된다. getInitialProps에서 return된 객체가 Date, Map 또는 Set을 사용하지 않고 일반 Object인지 확인하자.
getInitialProps는 처음에는 서버에서 호출된다. 그 후 `next/link`또는 `next/router`를 이용하여 페이지 이동할 때는 클라이언트에서 호출된다.
만약 커스텀 _app에서 getInitialProps를 사용하고, 이동한 페이지에서 getServerSideProps가 구현되었다면, getInitialProps는 서버에서 실행된다.
= > getServerSideProps이 없으면 SSR할 필요가 없으므로 렌더링 최적화를 위해 CSR로 사용하지만, getServerSideProps이 있다면 SSR 때문에 어차피 최적화도 안될 것이다. (첫 페이지를 로딩할 때처럼 HTML과 스크립트를 다시 불러와야 하므로).
그래서 약간의 성능을 챙기기위해 서버에서 같이 실행되는 듯하다?(혹시 틀린 정보라면 댓글 부탁드립니다.)

Context Object

getInitialProps는 context 파라미터를 받는데, 이 파라미터 각체는 다음 프로퍼티를 갖고있다.

pathname - /pages 폴더 내에 있는 페이지의 현재 경로. (ex: /post?type=news 일 경우 /post)
query - 객체로 파싱된 URL의 Query String (ex: /post?type=news 일 경우 {type:'news'})
asPath - 브라우저에 표시되는 실제 경로(쿼리 포함)의 String (ex: /post?type=news 일 경우 /post?type=news)
req - HTTP 요청 객체(서버 전용)
res - HTTP 응답 객체(서버 전용)
err - 렌더링 중 오류가 발생한 경우 오류 객체

주의점

getInitialProps는 자식 컴포넌트에서 사용할 수 없고, 오직 default export가 정의된 페이지에서 사용할 수 있다.
getInitialProps 내부에서 SSR을 사용한다면, 애플리케이션이 느려지지 않게 적절히 import 해야한다.

getServerSideProps

페이지에서 getServerSideProps (SSR) 를 호출하면, Next.js는 각 요청에 대해 getServerSIdeProps가 return한 데이터를 사용하여 이 페이지를 pre-rendering한다.

function Page({ data }) {
  // 렌더링 데이터
}

// 매 요청마다 호출된다.
export async function getServerSideProps(context) {
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  // props 객체를 통해 data를 page로 전달한다.
  return { props: { data } }
}

export default Page

getServerSideProps는 서버 측에서만 실행되며 브라우저에서는 실행되지 않는다.
페이지를 직접 요청하면 요청 시점에 getServerSideProps가 실행되고, 이 페이지가 return된 소품과 함께 미리 렌더링된다.
`next/link`또는 `next/router`를 이용하여 페이지를 요청하면 Next.js가 서버에 API를 요청하고, 서버는 getServerSIdeProps를 실행한다.
https://next-code-elimination.vercel.app/ 에 들어가보면 Next.js로 만든 코드들을 Next.js 코드를 제거한 순수 client-side 코드로 변경하는 것을 볼 수 있다.
getServerSideProps는 페이지에서만 동작한다. 페이지가 아닌 파일(_app.js, _document.js, component등)에서는 동작하지 않는다.
getServerSideProps내에서 에러가 발생시 기본적으로 pages/500.js 을 보여준다. dev모드에서는 500파일을 보여주진 않고, 에러화면을 보여준다.

Context Object

context 파라미터의 객체에는 아래의 key값들이 있다.

params: 페이지가 dynamic route인 경우, (ex: page 이름이 [id].js라면 {id: ...} 객체 return)
req - HTTP 요청 객체(서버 전용)
res - HTTP 응답 객체(서버 전용)
query - 객체로 파싱된 URL의 Query String (ex: /post?type=news 일 경우 {type:'news'} 객체 return)
preview: true일 경우 Preview Mode 모드
previewData: preview에서 사용되는 데이터. setPreviewData함수를 이용하여 설정할 수 있다.
resolvedUrl: 클라이언트 전환을 위해 _next/data 접두사를 제거하고, 원래 쿼리 값을 포함하는 정규화된 요청 URL 버전
(ex /post?type=news 일 경우 '/post?type=news' 문자열 return
locale: 현재 로케일 값
locales: 사용 가능한 로케일의 목록 값
defaultLocale: 기본 로케일 값

notFount

`notFound: true`는 Next.js의 getServerSideProps 메서드에서 return되는 객체의 속성 중 하나로, 해당 페이지를 찾을 수 없음을 나타낸다.

예를 들어, 데이터베이스에서 요청한 데이터가 존재하지 않는 경우, 혹은 유효하지 않은 URL을 요청한 경우 등이 있다. 이 경우, `notFound: true`를 return하여 클라이언트에게 해당 페이지가 존재하지 않음을 알리고, 사용자를 404 페이지로 redirection할 수 있다.

export async function getServerSideProps(context) {
  const { params } = context;
  const post = await fetch(`https://api.example.com/posts/${params.id}`).then(res => res.json());

  if (!post) {
    return {
      notFound: true
    }
  }

  return {
    props: {
      post
    }
  }
}

위 예시 코드에서는 getServerSideProps 메서드에서 데이터베이스에서 요청한 데이터가 존재하지 않는 경우 `notFound: true`를 return한다. 이 경우, Next.js는 클라이언트에게 해당 페이지가 존재하지 않음을 알리고, 404 페이지로 redirection한다.

redirect

redirect는 Next.js의 getServerSideProps 메서드에서 return되는 객체의 속성 중 하나로, 클라이언트를 다른 페이지로 redirection한다.

예를 들어, 사용자가 로그인하지 않은 경우 로그인 페이지로 redirection하거나, 특정 조건이 충족되지 않는 경우 다른 페이지로 redirection하는 등이 있다.

export async function getServerSideProps(context) {
  const { req } = context;

  if (!req.headers.cookie) {
    return {
      redirect: {
        destination: '/login',
        permanent: false,
        // statusCode: 301
      }
    }
  }

  return {
    props: {
      // ...
    }
  }
}

위 예시 코드에서는 getServerSideProps 메서드에서 클라이언트의 쿠키를 검사하여 로그인하지 않은 경우 `redirect`를 return하여 로그인 페이지로 redirection한다.

`destination` 속성을 사용하여 redirection할 URL을 지정할 수 있다.
`permanent` 속성을 사용하여 해당 redirection을 영구 redirection로 설정할 수도 있다.
일반적으로, permanent 속성을 true로 설정하면 redirection을 클라이언트 캐시에 저장하고, 301 HTTP 상태 코드를 return한다.
false로 설정하면 매번 새로운 redirection을 받고, 302 HTTP 상태 코드를 return한다.
`redirect`를 사용하여 클라이언트를 다른 페이지로 redirection할 때는, 반드시 올바른 HTTP 상태 코드를 사용하여 redirection해야한다.
드물지만 구형 HTTP 클라이언트가 올바르게 redirection되도록 custom statusCode를 할당해야 하는 경우가 있다. 이 경우 statusCode 속성을 사용할 수 있지만 permanent 속성과 같이 사용할 수는 없다.

Edge APi Routes

API Routes란

getServerSideProps는 서버리스 런타임과 엣지 런타임 둘다 사용할 수 있다. 그러나 현재 Edge Runtime에서는 응답 객체에 접근 할 수 없다. 접근하기 위해서는 기본 런타임인 Node.js 런타임을 사용해야 한다.

export const config = {
  runtime: 'nodejs',
}

References

Next.JS 공식 홈페이지 - https://nextjs.org/docs/api-reference/data-fetching/get-initial-props

[Keycloak] keycloakify로 테마 커스텀 - 화면 작업 방식

SooJae — Fri, 17 Feb 2023 18:55:27 +0900

※ 이전 게시물과 이어집니다. 아직 keycloakify 설치, 세팅하기 전이라면 다음 포스팅을 확인해 주세요.

[Keycloak] keycloakify로 테마 커스텀 - 초기 설정

버전 정보 keycloak: v20.0.3 keycloakify: v6 로그인 테마 커스텀 사실 keycloak의 테마는 이쁘지 않다... 이를 극복하기위해 직접 freeMaker(https://freemarker.apache.org/) 즉, .ftl 확장자 파일을 수정해야 한다. freeMa

soojae.tistory.com

버전 정보

keycloak: v20.0.3
keycloakify: v6

화면 작업 방식

화면 작업 방식은 2가지로 보면 된다.

keycloak에서 기본으로 사용하는 login.ftl, register.ftl 등의 freemarker(.ftl) 파일 작업
기존 keycloak에는 없는 extra 파일 작업 (ex: 로그인 MFA 화면 등)

그럼 keycloak에서 기본으로 사용하는 freemarker 파일들은 어디서 확인할 수 있을까? 공식 문서에는 login.ftl, account.ftl, register.ftl 만 언급되고 나머지 ftl들은 찾을 수 없다.

다행히 keycloakify가 빌드된 폴더에서 이 파일들을 찾을 수 있다.

이전 시간에 작업했던 프로젝트에서 아래 경로로 들어가 보면 파일 목록들이 나온다.

keycloakify-advanced-starter/build_keycloak/src/main/resources/theme/keycloakify-advanced-starter/login

my-extra-page-1,2 는 extra 파일이므로 무시하자. email 폴더는 이메일 전송 시에 사용되는 email template들이 들어가 있다. 현재는 login 폴더 내의 파일들만 보면 된다.

화면 작업 순서

1. KcApp 폴더 내에 작업할 파일을 생성

2. keycloakify 양식에 맞게 이쁘게 파일 작업

3. KcContext.ts 파일 작업

작업한 파일들을 양식에 맞게 추가해 준다.
사실 이 부분은 keycloak에서 기본으로 제공해 주는 login.ftl, register.ftl 등의 파일들에는 작업하지 않아도 잘 동작한다.
하지만 하는 것이 유지보수 측면에서도 좋고 속이 편해진다. mockData에 sampleData를 넣음으로써 테스트하기도 용이하다.

4. KcApp.tsx 파일 작업

작업한 파일들의 경로를 추가해 준다.

5. KcContext.ts 파일의 mockPageId 작업

작업한 파일을 테스트하기 위해서는 mockPageId를 설정해야 한다. mockPageId는 하나밖에 설정할 수 없다.
그래서 한 화면씩만 테스트를 할 수 있다고 생각하면 된다.

6. (기존 keycloak에는 없는 extra 파일 작업 경우에만) package.json 파일 작업

7. `$ yarn start` 실행하여 작업한 화면 확인

성공!

앞으로 커스텀 화면을 작업할 때마다 위와 같이 진행하면 된다.

[Keycloak] keycloakify로 테마 커스텀 - 초기 설정

SooJae — Thu, 16 Feb 2023 05:18:08 +0900

버전 정보

keycloak: v20.0.3
keycloakify: v6

로그인 테마 커스텀

사실 keycloak의 테마는 이쁘지 않다...

꾸민 느낌 내려고 배경에 그라데이션 도형을 넣은게 더 열 받는다.

이를 극복하기위해 직접 freeMaker. 즉, .ftl 확장자 파일을 수정해야 한다.
freeMarker가 어떤 코드인지 확인하기 위해 keycloak 깃허브에서 .ftl 확장자를 찾아보면 아래와 같이 되어있다.

짧은 코드라 읽히긴 하지만, 이 코드 양이 많아지거나 커스텀 로직을 추가해야 한다고 생각하면 쉽지 않다.

저 위의 빨간 에러는 뭔데... jsp 하던 때로 돌아간 것 같다.

이를 위해 Joseph Garrone라는 개발자분이 React로도 개발이 가능하도록 (React로 개발 후에 빌드하면 ftl파일로 변화된다) keycloakify라는 라이브러리를 만들었다.

Keycloakify 설치

keycloakify-advanced-starter(https://github.com/garronej/keycloakify-advanced-starter) 에서 프로젝트를 clone 한 후에 Quick Start에 쓰여있는 순서에 맞춰서 작업을 진행한다.

$ yarn
$ yarn keycloak # 빌드를 한번 한다. (몇몇 assets 들은 public/keycloak_static 폴더에 복사되며
               # 이는 keycloak 외의 커스텀 페이지를 개발하기 위해 필요하다.)
$ yarn start # Hello World 페이지가 나온다.

# src/KcApp/kcContext.ts 파일의 15번째 줄의 주석을 제거하고, https://localhost:3000에 접속하면
# 이제 로그인 페이지를 개발할 수 있다.

# 테마를 완성하고 $yarn keyclock를 하여 표시되는 콘솔 문구들을 통해 테스트 하면된다.
$ yarn keycloak

src/KcApp 폴더에 있는 kcContext.ts 파일의 15번째 라인의 주석을 해제하자

import { getKcContext } from "keycloakify/lib/getKcContext";

export const { kcContext } = getKcContext<
    // NOTE: A 'keycloakify' field must be added 
    // in the package.json to generate theses pages
    // https://docs.keycloakify.dev/build-options#keycloakify.extrapages
    | { pageId: "my-extra-page-1.ftl"; } 
    | { pageId: "my-extra-page-2.ftl"; someCustomValue: string; }
    // NOTE: register.ftl is deprecated in favor of register-user-profile.ftl
    // but let's say we use it anyway and have this plugin enabled: https://github.com/micedre/keycloak-mail-whitelisting
    // keycloak-mail-whitelisting define the non standard ftl global authorizedMailDomains, we declare it here.
    | { pageId: "register.ftl"; authorizedMailDomains: string[]; }
>({
    // Uncomment to test the login page for development.
    "mockPageId": "login.ftl",     // <=============== 이 부분의 주석을 제거한다.
    "mockData": [
        {
            "pageId": "login.ftl",
            "locale": {
                //When we test the login page we do it in french
                "currentLanguageTag": "fr", 
            },

`$ yarn start` 를 실행하면 로그인 페이지가 잘 나온다. 이제 `$ yarn keycloak` 을 하면 많은 콘솔이 출력되는데 하나씩 뜯어보자.

  Building the keycloak theme...⌚
  Let keycloakify do its thang

# 생성된 테마는 도커이미지의 컨테이너의 "/opt/keycloak/providers" 폴더에 위치된다.
✅ Your keycloak theme has been generated and bundled into ./build_keycloak/target/keycloakify-advanced-starter-keycloak-theme-1.0.8.jar  
It is to be placed in "/opt/keycloak/providers" in the container running a quay.io/keycloak/keycloak Docker image.

...
# 테스트를 하기위해서 keycloak docker를 띄우자. 아래 커맨트를 이용하면 20.0.1 keycloak을 설치할 수 있다.
To test your theme locally you can spin up a Keycloak 20.0.1 container image with the theme pre loaded by running:

  $ ./build_keycloak/start_keycloak_testing_container.sh  
# 버전을 다르게 하고 싶으면 start_keycloak_testing_container.sh 파일을 수정하면 된다.
Test with different Keycloak versions by editing the .sh file. see available versions here: https://quay.io/repository/keycloak/keycloak?tab=tags

# 컨테이너가 올라가면 아래 순서대로 적용한다.
Once your container is up and running: 
- Log into the admin console   http://localhost:8080/admin username: admin, password: admin  
- Create a realm named "myrealm"
- Create a client with ID: "myclient", "Root URL": "https://www.keycloak.org/app/" and "Valid redirect URIs": "https://www.keycloak.org/app/*"
- Select Login Theme: keycloakify-advanced-starter (don't forget to save at the bottom of the page)
- Go to   https://www.keycloak.org/app/   Click "Save" then "Sign in". You should see your login page


# 이 프로세스를 시연한 데모 영상이다. 
Video demoing this process: https://youtu.be/N3wlBoH4hKg

그럼 순서대로 작업해보자.
우선 현재 기준 최신버전인 20.0.3으로 바꾸려고 한다.

~~$ vim ./build_keycloak/start_keycloak_testing_container.sh~~ 를 통해 버전만 변경해 준다.

이제 `$ ./build_keycloak/start_keycloak_testing_container.sh` 를 하면 20.0.3 버전으로 keycloak-testing-container 컨테이너 이름을 가진 keycloak 도커가 실행된다.
이제 아래 순서대로 진행하면 된다.

http://localhost:8080/admin에 접속
아이디: admin, 비밀번호: admin로 로그인
'myrealm'라는 이름의 realm 생성
'myrealm'내에서 'myclient'라는 이름의 client 생성
"Root URL": "https://www.keycloak.org/app/" 로 설정 "Valid redirect URIs": "https://www.keycloak.org/app/*" 로 설정
Login Theme을 keycloakify-advanced-starter로 설정
save 버튼 꼭 누르기!

여기서 Root URL은 이후 상대 경로들을 간편하게 작성하기 위해 default로 정의한 경로다.
예를 들어 위의 경우 Valid redirect URIs, Admin URL를 설정할 때 앞에 'https://www.keycloak.org/app/'을 따로 적어주지 않아도 된다.
Valid redirect URIs는 로그인 성공 후에 redirect 되는 URI를 제한한다.
위의 뜻을 해석하자면 https://www.keycloak.org/app/ 하위 주소(ex: https://www.keycloak.org/app/a, https://www.keycloak.org/app/b 등)가 아닌 다른 주소로 redirect 된다면 에러가 발생한다는 뜻이다.
Invalid parameter: redirect_uri 에러가 발생한다.

위와 같이 저장 후에 https://www.keycloak.org/app 에 접속하여 그대로 'save' 버튼을 누른 후에 'Sign in' 버튼을 누르면 아래와 같이 커스텀 된(?) 화면이 나온다.

커스텀 테마 덕분에 로그인 화면이 화사해졌다.

아이디: admin, 비밀번호: admin로 로그인을 시도해보자.
안된다. admin은 myRealm내의 가입된 사용자가 아니기 때문이다.

아래 포스트를 따라서 myRealm에 사용자를 생성하자. (18버전이라 화면이 살짝 다르지만 그대로 따라 하면 된다.)

[Keycloak] Realm, Client, User 생성 (Quarkus, 17버전 이후)

이번 시간에는 Realm과 Client, 그리고 User에 대해 알아보겠습니다. 위 그림에서 Application은 Client라고도 불립니다. 혼동을 방지하기위해 앞으로 Client라고 부르겠습니다. Realm Realm은 사용자, 인증, 인

soojae.tistory.com

이제 로그인이 가능하다!

반년 전만 해도 이런 식으로 테스트를 할 수 없었다. (keycloakify 라이브러리의 docs 페이지도 없었다.)
지금 이렇게 실제 적용하는 것과 비슷하게 테스트할 수 있도록 만들어주신 걸 보니, 어떻게 하면 사용자들이 쉽게 이해할 수 있을지 고민한 흔적들이 많이 보인다.
대단한 개발자라고 생각한다. 나도 열심히 실력을 키워서 이번 생에 이런 프로젝트 하나 이상은 꼭 만들어야지.

기초 작업은 끝났다! 다음 포스팅부터 본격적으로 로그인, 회원가입 화면들을 만들예정이다.

[Next.JS] _app.js, _document.js

SooJae — Wed, 15 Feb 2023 20:39:49 +0900

_app.js, _document.js

이 파일들은 pages폴더에 위치한 Next.JS에서 제공하는 로직을 override하기 위해 필요한 파일들이다. Next.JS에서 제공해 주는 기능만 사용한다면 생성하지 않아도 된다. 하지만 실제로 개발하다 보면 100% 커스텀해야 한다.

_app.js

_app은 모든 페이지에 레이아웃 형태로 항상 적용되어 있다.
페이지 이동 시에 상태가 변하지 않는다.
필요한 초기 데이터를 getInitialProps에서 받아 컴포넌트들에 공유할 수 있다.
global css를 추가하기 좋은 파일이다.

// _app.ts
const App = ({Component, pageProps}: AppProps) => {
  return <Component {...pageProps} />}
}

export default App;

위 코드에서 Component는 활성 중인 page다. 그래서 route간 이동할 때마다 Component는 항상 새 페이지로 교체된다.
pageProps는 `App.getInitialProps`를 이용하여 prefetching된 데이터를 받을 수 있다. 데이터가 없다면 빈 객체({})가 내려온다.

주의점

_app 에서는 Next.JS의 getStaticProps, getServerSideProps와 같은 Data Fetching methods가 동작하지 않는다.
server only file이며, Next.JS Server에서 사용함으로 Client에서 사용하는 로직 (eventListener의 window/ DOM로직)을 사용하면 안 된다. (window is not defined 에러 발생)
만약 getInitialProps를 _app에 사용하면 SSG의 효과가 없어 모든 페이지에 Automatic Static Optimization를 할 수 없다.
만약 _app에서 getInitialProps를 사용해야 한다면, `next/app`에서 App객체의 InitialProps를 통해 데이터를 가져와야 한다.

실제 사용 예제

getInitialProps를 이용하여 _app에서 특정 api를 호출 후, index.ts에 그 결과 값을 전달하는 로직을 만들어보자.

// _app.ts

interface DogProps {
    message: string,
    status: string
}

const CustomApp = ({Component, pageProps}: AppProps) => {
    return <Component {...pageProps} />
}

CustomApp.getInitialProps = async (appContext: AppContext) => {
    // 여기서의 App은 next/app 내의 App
    const appProps = await App.getInitialProps(appContext);
    let response = await fetch('https://dog.ceo/api/breeds/image/random');
    let dog: DogProps = await response.json()

    return {pageProps: dog}
}

export default CustomApp;

// index.ts

interface DogProps {
    message: string,
    status: string
}

const Home = (dog: DogProps) => { // _app.ts에서 내려받은 dog값
    return (
        <div>
            {dog.status !== "error" && <img src={dog.message} alt="강아지 사진"/>}
            {dog.status === "error" && <div>에러 발생!</div>}
        </div>
    )
}

export default Home;

결과

귀여워

_document.js

_document는 `html`과 `body` 태그를 커스텀하게 만들 수 있다.
`,` ``, `
`
그리고 ``는 적절한 렌더링을 위해 꼭 필요한 태그들이다.

const Document = () => {
    return (
        <Html lang="en"> // html 태그 커스텀
            <Head/>
            <body className="bg-white">  // body 태그 커스텀
            <Main/>
            <NextScript/>
            </body>
        </Html>
    )
}

export default Document;

주의점

_app 에서는 Next.JS의 getStaticProps, getServerSideProps와 같은 Data Fetching methods가 동작하지 않는다.
server only file이며, NextJS Server에서 사용함으로 Client에서 사용하는 로직 (eventListener의 window/ DOM로직)을 사용하면 안 된다. (window is not defined 에러 발생)
_document의 `` 컴포넌트는 `next/head` 파일 내의 ``컴포넌트와 다르다. `next/document` 파일에서 import 한 것이며, 이는 `` 내의 태그들은 모든 페이지에서 적용될 태그들만 사용해야 한다. 만약 `태그와 같이 페이지마다 다른 값이 보이려면 `next/head`의 ``를 사용해야 한다.
`
`
외에는 브라우저에서 실행되지 않으므로 비즈니스 로직이 있으면 안 된다.

커스텀 renderPage

이는 주로 CSS-in-JS (ex: emotion, styled-component)가 SSR에서 적용되도록 하기 위해서 사용한다.

class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const originalRenderPage = ctx.renderPage

    // 리액트 렌더링 로직
    ctx.renderPage = () =>
      originalRenderPage({
        // 애플리케이션 전체에 적용하기 위한 로직 (_app)
        enhanceApp: (App) => App,
        // 각 페이지에 적용하기 위한 로직 
        enhanceComponent: (Component) => Component,
      })

    // 부모 getInitialProps 실행. 위의 커스텀된 renderPage가 포함되어있다.
    const initialProps = await Document.getInitialProps(ctx)

    return initialProps
  }

  render() {
    return (
      <Html>
        <Head />
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    )
  }
}

export default MyDocument

References

Next.JS 공식 홈페이지 - https://nextjs.org/docs/advanced-features/custom-app

[스프링 시큐리티] WebSecurityConfigurerAdapter deprecated 대응

SooJae — Mon, 6 Feb 2023 23:21:10 +0900

WebSecurityConfigurerAdapter is deprecated

Spring Security 6.0 버전 기준으로 WebSecurityConfigurerAdapter를 완전 사용할 수 없게 됐다.

import를 하지 못한다.

기존 WebSecurityConfigurerAdapter를 상속 후에, configure 메소드를 오버라이딩 하는 방식은 deprecated 됐다.
대신 개발자가 직접 component-based security 설정을 할 수 있도록 변경되었다. 즉 커스텀 할 설정들을 @Bean으로 등록하여 사용한다.

HttpSecurity 설정

// 변경된 방식 (filterChain을 사용)

@Configuration
public class SecurityConfiguration {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests((authz) -> authz
                .anyRequest().authenticated()
            )
            .httpBasic(withDefaults());
        return http.build();
    }

}

// 기존 방식 (deprecated)

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests((authz) -> authz
                .anyRequest().authenticated()
            )
            .httpBasic(withDefaults());
    }

}

WebSecurity 설정

// 변경된 방식(WebSecurityCustomizer 클래스 사용)

@Configuration
public class SecurityConfiguration {

    @Bean
    public WebSecurityCustomizer webSecurityCustomizer() {
     // antMatchers 부분도 deprecated 되어 requestMatchers로 대체
        return (web) -> web.ignoring().requestMatchers("/ignore1", "/ignore2");
    }

}

// 기존 방식
@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

    @Override
    public void configure(WebSecurity web) {
        web.ignoring().antMatchers("/ignore1", "/ignore2");
    }

}

JDBC 설정

// 변경된 방식
@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.H2)
            .build();
    }

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        UserDetails user = User.withDefaultPasswordEncoder()
            .username("user")
            .password("password")
            .roles("USER")
            .build();
        auth.jdbcAuthentication()
            .withDefaultSchema()
            .dataSource(dataSource())
            .withUser(user);
    }
}


// 기존 방식
@Configuration
public class SecurityConfiguration {
    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.H2)
            .addScript(JdbcDaoImpl.DEFAULT_USER_SCHEMA_DDL_LOCATION)
            .build();
    }

    @Bean
    public UserDetailsManager users(DataSource dataSource) {
        UserDetails user = User.withDefaultPasswordEncoder()
            .username("user")
            .password("password")
            .roles("USER")
            .build();
        JdbcUserDetailsManager users = new JdbcUserDetailsManager(dataSource);
        users.createUser(user);
        return users;
    }
}

그 외에 공식문서에서 Ldap이나 In-memory 그리고 AuthenticationManager등의 변경된 설정법을 확인할 수 있다.

References

Spring Security without the WebSecurityConfigurerAdapter - https://spring.io/blog/2022/02/21/spring-security-without-the-websecurityconfigureradapter

Spring Security: Upgrading the Deprecated WebSecurityConfigurerAdapter - https://www.baeldung.com/spring-deprecated-websecurityconfigureradapter

[스프링 시큐리티] AuthenticationManager, AuthenticationProvider

SooJae — Mon, 6 Feb 2023 20:36:22 +0900

※ 이 글은 정수원님의 스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security 강의를 수강하면서 학습한 내용을 정리한 글입니다. 일부 강의 내용을 인용하였으며, 문제가 될 시 인용 부분을 수정 또는 삭제하겠습니다.

AuthenticationManager

인증 처리하는 filter로부터 인증처리를 지시받는 첫번째 클래스.
ID와 Password를 Authentication 인증 객체에 저장하고 이 객체를 AuthenticationManager에게 전달한다. 이 인증에 대해 관리를 하게 된다.

출처 : 스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security

AuthenticationManager 인터페이스를 실제로 구현한 것이 ProviderManager. 이 AuthenticationManager 인터페이스를 구현하면 커스텀 ProviderManager도 만들 수 있다.
AuthenticationProvider 목록 중에서 인증 처리 요건에 맞는 AuthenticationProvider를 찾아 인증 처리를 위임한다. 그래서 실제로 ProviderManager가 ID와 Password를 검증하지는 않는다. 단지 각 인증에 맞는 Provider를 찾아 인증처리를 맡긴다.
만약 ProviderManager에 해당 조건에 맞는 Provider가 없다면, 부모 ProviderManager에서 Provider를 탐색하여 찾는다면 부모 ProviderManager에게 인증을 맡긴다. (예: 위의 사진에서 Oauth 인증일 경우)
인증이 완료되면 자신을 호출한 Filter에게 결과 값을 넘겨준다.

AuthenticationProvider

ID와 Password가 검증하는 실질적인 클래스다. 위의 ProviderManager가 적절한 Provider 선택후 아래와 같은 로직이 동작한다.

출처 : 스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security

AuthenticationProvider는 인터페이스다. 이 인터페이스를 구현하면 커스텀 AuthenticationProvider도 만들 수 있다.
`authenticate` 메서드는 실질적인 인증처리를 하고, `support` 메소드는 인증 처리의 기준을 정한다.
authenticate 동작 순서 살펴보자.

ID검증: UserDetailsService에서 DB에서 사용자를 조회. 사용자가 없을 경우 UserNotFoundException 예외를 발생시킨다. 성공하면 UserDetails 객체를 반환한다.
Password 검증: 반환 받은 UserDetails 객체에 저장된 Password와 Authentication에 저장된 Password(로그인시 입력한 Password)를 `matches` 메서드를 이용하여 비교. 일치하지 않는다면 BadCredentialException 예외를 발생시킨다.
추가 검증 까지 완료하면 Authentication(유저 정보, 권한 정보)를 AuthenticationManager에게 전달. AuthenticationManager는 Filter에게 전달하고, Filter는 이 정보를 전역적으로 사용할 수 있게 SecurityContext에 전달한다.

References

스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security - https://www.inflearn.com/course/%EC%BD%94%EC%96%B4-%EC%8A%A4%ED%94%84%EB%A7%81-%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0/

[스프링 시큐리티] 필터(DelegatingFilterProxy, FilterChainProxy)

SooJae — Mon, 6 Feb 2023 19:12:59 +0900

필터

WAS에서 실행된 요청이 오면 이 요청이 서블릿으로 들어오는데, 서블릿에 들어오기 전에 처리를 하는 것이 필터.

필터의 흐름

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러

필터 체인

HTTP 요청 -> WAS -> 필터 1 -> 필터 2 -> 필터 3 -> 서블릿 -> 컨트롤러

DelegatingFilterProxy

이 필터는 Servlet 스펙에 있는 기술이기 때문에 Servlet 컨테이너에서만 생성되고 실행된다. Spring의 Ioc 컨테이너와는 컨테이너가 다르기 때문에 Spring Bean으로 Injection하거나 Spring에서 사용되는 기술을 Servlet에서 사용할 수 없다.

이를 가능하게 해주는 것이 DelegatingFilterProxy 클래스다.

출처 : 인프런 - 스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security

DelegatingFilterProxy는 springSecurityFilterChain 이름으로 생성된 빈을 ApplicationContext에서 찾아 요청을 위임한다. 실제로 보안 처리는 하지 않고 위임만 하는 Servlet Filter다.

DelegatingFilterProxy는 이 Servlet 컨테이너와 Spring의 Ioc 컨테이너를 연결해주는 필터라고 생각하면 된다.

FilterChainProxy

출처 : 인프런 - 스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security

전체적인 동작 방식을 살펴보자.

출처 : 인프런 - 스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security

HTTP요청이 들어오면 Servlet 컨테이너에서 요청을 받는다.
Servlet 컨테이너 내의 필터들이 동작하는 중간에 DelegatingFilterProxy Filter가 요청을 받으면 springSecurityFilterChain 이름으로 생성된 빈을 AnnotationConfigServletWebServerApplicationContext 객체에서 찾는다.
이 찾은 Filter Bean이 바로 FilterChainProxy다.

그 후에 FilterChainProxy Bean에 요청을 전달한다. 이제 FilterChainProxy에서 필터들을 이용하여 보안처리를 진행한 후 최종적으로 SpringMVC의 DeispatcherServlet에 전달하여 요청에 대한 Servlet 처리를 하게 된다.

References

스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security - https://www.inflearn.com/course/%EC%BD%94%EC%96%B4-%EC%8A%A4%ED%94%84%EB%A7%81-%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0/dashboard

Overview and Need for DelegatingFilterProxy in Spring - https://www.baeldung.com/spring-delegating-filter-proxy

스프링 공식 문서 - https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-filters-review

[스프링 시큐리티] HttpSecurity vs WebSecurity

SooJae — Sun, 5 Feb 2023 12:53:20 +0900

HttpSecurity vs WebSecurity

SpringBuilder는 웹 보안을 구성하는 빌더 클래스로서 웹 보안을 구성하는 빈 객체와 설정 클래스들을 생성하는 역할을 한다.
이 빌더의 종류로는 HttpSecurity와 WebSecurity가 있다. 오늘은 이 둘에 대해서 알아보려고 한다.

@Configuration
@EnableWebSecurity
public class CustomWebSecurityConfiguration extends WebSecurityConfigurerAdapter {
    @Override
    public void configure(WebSecurity web) throws Exception {
        web.ignoring()
        .antMatchers("/health", "/health/**")
        .antMatchers("/publics/**");
    }
    @Override
    public void configure(HttpSecurity http) throws Exception {
         http.csrf().disable()
            .authorizeRequests()
            .antMatchers("/health", "/health/**").hasRole('USER') // 무시된다.
            .anyRequest().authenticated();
}

WebSecurity는 HttpSecurity의 상위에 있다. WebSecurity의 `ignoring`에 endpoint를 만들면, Security Filter Chain이 적용되지 않는다.
이 경우 Cross-Site Scripting, XSS 공격, content-sniffing에 취약해진다.

HttpSecurity의 `permitAll`에 endpoint를 지정하면 인증처리의 결과를 무시하지만 Security Filter Chain이 적용되어 Cross-Site Scripting, XSS 공격, content-sniffing에 대한 검사를 할 수 있다.

위의 예제의 경우 WebSecurity에 `ignoring`에 설정된 `/publics/**` 엔드포인트에 대하여 HttpSecurity 부분은 동작하지 않는다.

실무에서 HttpSecurity의 `permitAll`이 설정된 endpoint에 잘못된 BearerToken 값이 들어오면 Security Filter Chain를 거치면서 에러를 반환하지만, WebSecurity는 `ignoring`이 설정된 잘못된 BearerToken 값이 들어와도 통과된다.

그래서 WebSecurity는 보안과 전혀 상관없는 로그인 페이지, 공개 페이지(어플리캐이션 소개 페이지 등), 어플리캐이션의 health 체크를 하기위한 API에 사용하고, 그 이외에는 HttpSecurity를 사용하는 것이 좋다.

References

SpringBoot : Security Configuration using HTTPSecurity vs WebSecurity - https://ravthiru.medium.com/springboot-security-configuration-using-httpsecurity-vs-websecurity-1a7ec6a23273

[Keycloak] 외부 DB(Mysql)로 변경 (Quarkus, 17버전 이후)

SooJae — Wed, 29 Jun 2022 11:38:39 +0900

이제껏 DB를 따로 생성하지 않아도 Realm, Client, User를 생성하고 저장할 수 있었던 이유는, Keycloak내의 내부 DB(h2)를 사용하고 있었기 때문입니다.
하지만 보통 운영 단계에서는 외부 DB를 사용하는 경우가 많으므로 Keycloak 내부 DB에서 외부 DB로 변경해보겠습니다.

설치 DB는 Mysql입니다. 저는 Docker Compose로 설치해보겠습니다.

Mysql 5버전 설치

# docker-compose.yml

version: "3.8"
services:
  mysql_5:
    image: mysql:5.7.38
    container_name: mysql_5
    environment:
      - MYSQL_DATABASE=keycloak5
      - MYSQL_USER=jerry
      - MYSQL_PASSWORD=password
      - MYSQL_ROOT_PASSWORD=root_password
    ports:
        - "3305:3306" # 포트는 3305번으로 생성하겠습니다.
    healthcheck:
      test: "mysqladmin ping -u root -p$${MYSQL_ROOT_PASSWORD}"

Mysql 8버전 설치

# docker-compose.yml

version: "3.8"
services:
  mysql_8:
    image: mysql:8.0.29
    container_name: mysql_8
    environment:
      - MYSQL_DATABASE=keycloak8
      - MYSQL_USER=jerry
      - MYSQL_PASSWORD=password
      - MYSQL_ROOT_PASSWORD=root_password
    ports:
      - "3308:3306" # 포트는 3308번으로 생성하겠습니다.
    healthcheck:
      test: "mysqladmin ping -u root -p$${MYSQL_ROOT_PASSWORD}"

이제 다음 커맨드를 입력하여 실행해 줍니다.

$ docker-compose up -d

Realm 백업

여태 작업 한 내용들이 아까우니, 백업을 해줍시다.

Export 메뉴로 들어가 Export를 하면 SampleRealm의 백업파일인 realm-export.json 파일이 다운로드 됩니다.

외부 DB 설정

17버전을 기준으로 변경되었습니다. 복잡했던 16버전에 비해, 17 이후 버전은 설정이 간편해졌습니다.
keycloak이 설치된 폴더안에 conf 폴더 내 keycloak.conf 파일을 수정하겠습니다.
다음 커맨드로 keycloak.conf파일에 접근합니다.

$ vi ./conf/keycloak.conf

keycloak.conf 파일을 아래와 같이 설정했습니다.

# Basic settings for running in production. Change accordingly before deploying the server.

# Port
# 기존 8080이었던 keycloak 포트를 9090으로 변경
http-port=9090 

# Database

# The database vendor.
db=mysql

# The username of the database user.
db-username=jerry

# The password of the database user.
db-password=password

# The full database JDBC URL. If not provided, a default URL is set based on the selected database vendor.
db-url=jdbc:mysql://localhost:3308/keycloak8

이후 keycloak을 재 실행 시켜줍니다.

$ sh ./bin/kc.sh start-dev

그럼 아래와 같이 keycloak8 데이터베이스에 테이블이 92개가 생성된 것을 확인 할 수 있습니다.

92개의 테이블이 생성됨

따로 테이블 생성이 필요 없는 이유는 keycloak이 실행되면서 liquibase가 실행되기 때문입니다.

# Keycloak 실행시 아래와 같은 로그가 발생하는데, jpa-changelog-master.xml 정보로 데이터베이스를 업데이트 한다는 것을 확인 할 수 있습니다.
2022-06-29 13:46:21,750 INFO  [org.keycloak.quarkus.runtime.storage.database.liquibase.QuarkusJpaUpdaterProvider] (main) Initializing database schema. Using changelog META-INF/jpa-changelog-master.xml

이제 http://localhost:9090 에 접속해 보면 아래와 같은 화면이 나옵니다. admin 계정을 생성해주세요.

이제 Export 했던 Realm 설정을 Import 하겠습니다.

Import 메뉴에서 Import를 하면 에러가 발생합니다.
그래서 위와 같이 Add realm 버튼을 누른 후 Select file을 클릭하여 백업해 두었던 realm-export.json파일을 선택합니다.

정상적으로 Realm이 생성되고, 외부 DB에서도 Realm이 생성된 것을 확인 할 수 있습니다.

수고하셨습니다.

[Keycloak] Realm, Client, User 생성 (Quarkus, 17버전 이후)

SooJae — Wed, 29 Jun 2022 10:57:42 +0900

이번 시간에는 Realm과 Client, 그리고 User에 대해 알아보겠습니다.

위 그림에서 Application은 Client라고도 불립니다. 혼동을 방지하기위해 앞으로 Client라고 부르겠습니다.

Realm

Realm은 사용자, 인증, 인가, 권한, 그룹이 관리하는 범위입니다.
한 Realm내의 Client들(위 그림에서는 Application입니다.)은 서로 SSO를 공유합니다. 각각의 Realm은 독립적입니다.
처음 Keycloak에 접속하면 Master Realm이 있는데, 이 Realm은 다른 Realm을 관리하는데만 사용합니다. (단지 관리를 하기위한 Realm이고, 다른 Realm이 Master Realm을 상속 받는 것은 아닙니다.)

Client

Client란 인증, 인가 업무를 Keycloak에게 요청할 수 있는 주로 어플리케이션이나 서비스를 뜻합니다. Keycloak은 Client들에게 보안이나, SSO를 제공해줍니다.

User

User란 Client를 이용하는 사용자를 뜻합니다. 사용자는 Realm단위로 되어있습니다. A라는 Realm에 가입된 X라는 사용자는 Client들에서 X의 아이디 하나로 로그인이 가능하지만, B라는 Realm에는 가입이 되어있지 않으므로 로그인이 불가능합니다.

Realm과 Client를 아래 예시로 설명해 보겠습니다.

위의 그림에서 카카오톡의 고유기능인 캘린더, 서랍, 공지사항을 제외한 각각의 Service(Client)는 같은 Realm을 사용하는 Client라고 볼 수 있습니다. 따로 가입하는 절차 없이 카카오톡 아이디로 바로 이용할 수 있기 때문입니다.
반면에 카카오 뱅크, 카카오 페이, 티스토리 등을 사용시에는 계정을 새로 가입해야하기 때문에, 같은 Realm이라고 볼 수 없습니다.

Realm과 Client 생성

왼쪽 사이드 바에서 Add realm 버튼을 눌러 Realm을 생성해줍시다.

Realm 생성이 완료되면, Clients 메뉴로 들어간 후 Create해줍니다.

Users 메뉴로 들어가 유저를 생성해줍니다.

Credentials 탭으로 들어가 비밀번호를 생성해줍니다.

Clients 메뉴로 들어와 account-console 링크를 눌러줍니다.

등록했던 아이디와 비밀번호를 입력해주세요.

정상적으로 접속된 것을 확인할 수 있습니다.

[Keycloak] 설치 (Quarkus, 17버전 이후)

SooJae — Tue, 28 Jun 2022 16:46:52 +0900

keycloak은 17버전 이후로 WildFly에서 Quarkus로 변경되었습니다. (https://www.keycloak.org/migration/migrating-to-quarkus)
17버전 이전과 설정 방법이 다르고 정보 또한 부족하여 많은 시행 착오를 겪었습니다. Keycloak을 사용하시는 분들께 도움이 되고자 작업했던 내용들을 정리하려고 합니다.

Keycloak이란

keycloak은 웹 앱, Restful 웹 서비스를 위한 SSO 솔루션입니다. Keycloak은 로그인, 등록, 관리 및 계정 관리를 위한 사용자 정의 가능한 사용자 인터페이스를 제공합니다. Keycloak을 통합 플랫폼으로 사용하여 기존 LDAP 및 Active Directory 서버에 연결할 수도 있습니다. Facebook 및 Google과 같은 타사 ID 제공업체에 인증을 위임할 수도 있습니다.

특징

브라우저 애플리케이션을 위한 Single Sign On / Single Sign Out
OpenID / SAML 지원.
소셜 로그인 - Google, GitHub, Facebook, Twitter 및 기타 소셜 네트워크로 로그인할 수 있습니다.
테마 지원 - 기본 Keycloak에서 제공해주는 페이지들을 커스텀 할 수 있습니다.
로그인 흐름 - 선택적 사용자 자체 등록, 비밀번호 복구, 이메일 확인, 비밀번호 업데이트 필요 등
세션 관리 - 관리자와 사용자가 사용자 세션을 보고 관리할 수 있습니다.
토큰 매퍼 - 사용자 속성, 역할 등을 원하는 방식으로 토큰과 명령문에 매핑합니다.

설치

설치는 Keycloak을 직접 다운 받는 방법 (공부 할때 추천) 과, Docker Compose를 이용하는 방법 두가지로 진행하겠습니다.
OpenJDK 11버전 이상이 설치되어 있어야 합니다. 설치 환경은 Mac 기준입니다.

1. Keycloak을 직접 다운로드

https://www.keycloak.org/downloads 에 접속하여 아래 Zip 파일을 다운 받습니다.

이후에 압축을 풀고 keycloak의 폴더에서 다음 커맨드를 입력합니다.

$ sh ./bin/kc.sh start-dev

2. Docker Compose로 설치

# docker-compose.yml

version: "3.8"
services:
  keycloak:
    image: quay.io/keycloak/keycloak:18.0.2
    container_name: keycloak
    environment:
      - KEYCLOAK_ADMIN=admin
      - KEYCLOAK_ADMIN_PASSWORD=admin
    ports:
      - "8080:8080"
    command: start-dev
    healthcheck:
      test: "curl -f http://localhost:8080/admin || exit 1"

이후에 다음 커맨드를 입력해 줍니다.

$ docker-compose up -d

Admin 계정 생성과 로그인

http://localhost:8080에 접속합니다.

위의 화면에서 최초 admin 계정을 생성합니다.
저는 아이디: admin, 비밀번호: admin으로 설정하겠습니다. (Docker Compose의 경우 이미 admin/admin으로 생성되어 있습니다.)

빨간색으로 표시된 부분을 클릭하고, 로그인을 합니다.

수고하셨습니다. 다음 포스트에서는 Realm, Client 그리고 User 생성을 해보겠습니다.

페이지 성능 최적화

SooJae — Mon, 26 Oct 2020 20:40:38 +0900

오늘은 페이지 성능 최적화에 대해 알아보겠습니다.
페이지 성능 최적화는 웹 서비스에서 중요한 개념이자, 이후에 포스팅할 CSR(Client Side Rendering)과 SSR(Server Side Rendering), 그리고 SSG(Static Site Generation)를 설명하기 위해 필요한 개념입니다.

페이지 성능 최적화를 해야 하는 이유?

사용자가 사이트를 방문한 후, 아무런 요청을 실행하지 않고 떠나는 비율을 이탈률이라고 합니다.

위의 그래프를 보시면 알 수 있듯이, 페이지 로딩 속도에 대한 이탈률을 보면 로딩 시간이 3초가 걸리면 32%, 5초면 90%, 6초면 106%, 10초면 123% 라고 합니다.
2018년도 자료이니, 2020년도인 지금은 로딩 속도에 대한 이탈률이 더 증가했다고 봐도 과언이 아닐 것입니다.
아무리 잘 만든 페이지라도, 사용자가 이용하지 않으면 말짱 도루묵이겠죠? 이런 이탈률을 줄이기 위해 페이지 성능 최적화가 필요합니다.

페이지 속도 측정에 가장 중요한 4가지 값

TTFB(Time to First Byte)

사용자가 웹 사이트를 호출하면 웹 서버에서 수신한 첫 번째 바이트가 도착하는 시간입니다.
즉, HTTP 요청에 걸리는 시간 + 서버의 요청 처리 시간 + 서버에서 클라이언트까지의 응답 시간이라고 보시면 됩니다.
TTFB 속도는 서버의 프로세스와 연관되어 있습니다.

최적화 방법

1. 호스팅 업체 변경
2. CDN 사용
3. 서버 코드 경량화

FCP(First Contentful Paint)

TTFB 이후에 콘텐츠(HTML 코드, 스타일, 이미지 등)가 표시될 때까지의 시간입니다.
이 시점은 사용자가 이 웹사이트가 실제로 동작한다고 인식하도록 해주기 때문에 중요합니다. (사용자 이탈률이 줄어듭니다.)
Pagespeed Insights(페이지 속도를 측정해주는 구글 툴)에서는 TTFB 측정은 건너뛰고 FCP 측정을 첫 번째로 합니다. 이는 개발자를 위한 것이며, Pagespeed Insight는 FCP를 활용하여 OnPage 최적화(제목 태그, 콘텐츠, 내부 링크 및 URL 최적화)를 위한 제안을 해줍니다.

최적화 방법

1. 데이터 압축
2. HTTP/2 사용
3. 리로드할 필요 없는 콘텐츠를 캐싱
4. 코드 경량화 & 스플리팅
5. 라이브러리 정리

FMP(First Meaningful Paint)

사용자에게 의미 있는 콘텐츠가 그려지기 까지의 시간입니다. 하지만 이벤트 리스너(화면 스크롤, 클릭 등)는 아직 추가되지 않았습니다.
사용자는 이 시점에서 페이지가 완전히 로드가 되었다고 인식합니다. 그러므로 FMP의 최적화는 좀 더 중요합니다.

최적화 방법

이미지 최적화, 사진이 많은 웹사이트일 때는 LazyLoading (예: Twitter, Instagram 등 스크롤을 내리면 추가 페이지 로딩)

TTI(Time To Interactive)

자바스크립트의 실행이 완료되어. 페이지가 상호작용 가능하게 될 때까지의 시간 (이벤트 발생 등).
대부분의 페이지 속도 테스트는 이 값을 기초로 사용합니다.

최적화 방법

FCP와 FMP를 최적화

이제 실제 화면을 통해 시점들을 살펴봅시다. 밑의 FP(First Paint)는 첫 픽셀이 그려지기 까지의 시간입니다.

위의 화면들을 보시면 중요한 시점은 FCP와 FMP인 것을 알 수 있습니다. 우리가 웹 사이트를 방문한다고 생각해봅시다.
페이지의 로딩이 끝날 때까지 흰 화면을 보여주기보다는, 화면을 부분적(FCP)으로 보여준 후 의미 있는 화면(FMP)을 보여주는 것이 좋겠죠?
그러므로 사용자에게 페이지의 성능이 좋다는 느낌을 주기 위해서는 FCP와 FMP시간을 단축시켜야 합니다.

페이지 로딩 최적화 방법과 자세한 설명은 TOAST UI에서 포스팅한 성능 최적화에서 확인해보시길 바랍니다.

글에 오류가 있으면 알려주세요 감사합니다.

REFERENCES

https://en.ryte.com/magazine/measure-page-speed
https://ui.toast.com/fe-guide/ko_PERFORMANCE/
https://marshall-ku.com/web/log/ttfb-%EB%8C%80%ED%8F%AD-%EB%8B%A8%EC%B6%95-%EC%84%B1%EA%B3%B5
https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/

npm과 npx의 차이

SooJae — Fri, 9 Oct 2020 21:32:27 +0900

이 글은 Magdalena Siljanoska의 Yes, it’s npx, not npm — the difference explained 를 번역한 게시물입니다.
Thank you Magdalena Siljanoska! Thanks to your writing, I can grow further as a developer.

나는 최근에 리액트를 배우면서 내가 잘 알고 있는 npm이 아닌 npx를 보고 혼란스러워했고, 많은 사람들이 혼란스러워하는 모습을 봤다.
우리들 중 일부는 그것이 이상하다고 생각했지만 별 생각이 없었고, 또 다른 사람들은 오타라고 생각하고 npm을 npx로 "고쳐서" 어려움을 겪었다.

몇번 더 이런 상황을 겪게 되니 이것에 대해 설명할 가치가 있다고 생각했다. 그래서 이 게시물을 작성하게 되었다. 나와 같이 npx에 대해 오해하고 있었던 모든 사람들을 위해서.

npm이 아니라 npx가 맞아! 오타가 아니야!

NPM

우리가 알고있듯이, npm은 의존성(dependency) 과 패키지 관리(package management)를 자동화 하기 위한 Node.js의 패키지 매니저이다.

우리는 프로젝트를 위한 모든 의존성 패키지를 package.json 파일에 지정할 수 있다. 그리고 언제든지, 그리고 누구라도 그 의존성 패키지들을 설치해야 할때는 단순히 npm install 만 타이핑하면 된다!

그것은 또한 versioning을 제공한다. versioning이란 우리 프로젝트에 의존하는 의존성 패키지들의 버전을 지정할 수 있게 해주는 것을 말한다.
그래서 대부분의 경우, 패키지의 버전 업데이트로 인해 우리의 프로젝트가 깨지는 것을 방지하거나, 우리가 선호하는 버전을 이용할 수 있게 해준다.

NPX

그와 반대로 npx는 Node 패키지들을 실행하는 도구다. 그리고 npm 5.2버전부터 npm 안에 포함되어있다.

npx는 다음과 같이 동작한다.

1. npx는 우선 기본적으로, 실행할 패키지가 실행 가능한 경로에 있는지 확인한다. (예를 들면, 우리의 프로젝트내에서 확인한다.)
2. 만약에 있다면, 그것을 실행한다.
3. 아니라면 패키지가 설치가 되지 않았다는 것으로 판단하여, npx가 가장 최신 버전의 패키지를 설치하고 실행한다.

위의 행동들은 기본 설정일때의 npx 동작방식이다. flags를 설정하면 사용자에 맞게 변경할 수 있다.

예를 들면, 만약에 npx some-package --no-install 을 실행시키면, 이는 npx가 some-package가 기존에 설치되어있지 않더라도 some-package를 실행시키라는 뜻이다.

npx flags에 대해 자세히 알고 싶다면 여기로 가라.

Example

예를들어 우리의 패키지가 my-package고, 이 패키지를 실행시키고 싶다고 생각해보자.

글쎄, npx가 없이 패키지를 실행하려면, 우리는 지역 경로(local path)로부터 my-package를다음과 같이 실행해야할 것이다.

$ ./node_modules/.bin/my-package

또는 package.json 파일의 scripts 부분에 작성하는 방법도 있다. 다음과 같이.

{
  "name": "something",
  "version": "1.0.0",
  "scripts": {
  "my-package": "./node_modules/.bin/my-package"
  }
}

그리고 npm run my-package 로 실행하면 된다.

반대로 npx를 이용하면 우리는 단순히 npx my-package 만 타이핑 하면 된다.

결론

덧붙이자면 npm !== npx 라는 것이고, 이 짧은 글이 당신의 npx에 대한 오해를 정리하는데 도움이 되었기를 바란다.

만약 다른 질문이 있으면 언제든지 댓글을 달면 된다.

해피코딩!

글에 번역 오류가 있으면 알려주세요 감사합니다.

ESLint와 Prettier 사용법과 차이점

SooJae — Wed, 7 Oct 2020 17:33:53 +0900

안녕하세요. 오늘은 ESLint와 Prettier의 개념과, 사용법 그리고 차이점에 대해 말해보려고 합니다.

ESLint

Linter의 기능

느슨한 형식의 언어인 Javascript에서는 코드 에러가 자주 발생합니다.
하지만 JavaScript는 동적 분석(프로그램을 직접 실행해서 코드를 분석 <=> 프로그램을 실행하지 않고 분석하는 정적 분석)을 하기 때문에 에러를 찾기 위해서는 코드를 직접 실행해서 확인을 해봐야 합니다.

이를 도와주는 것이 Linter입니다. Linter는 코드를 정적으로 분석하기 때문에, 프로그램을 실행하지 않고도 코딩 컨벤션에 위배되는 코드나 안티 패턴을 자동으로 검출해줍니다. 추가적으로 간단한 코드 포맷팅 기능도 있습니다.

ESLint 설치

$ npm i -D eslint

이제 eslint를 실행해봅시다.

$ ./node_modules/.bin/eslint -v

그런데 ./node_modules/.bin/eslint 를 직접 작성하기 번거로울 뿐만 아니라 보기에도 좋지 않다는 게 느껴질 것입니다. 이를 해결하기 위해 글로벌로도 설치해주세요.

$ npm i -g eslint

이제 eslint 명령어만로도 실행이 가능합니다.

$ eslint -v

※ 글로벌로 설치하기 싫거나, 설치를 하지 못하는 상황이고, 로컬에 있는 eslint만 사용하고 싶은데 ./node_modules/.bin/eslint 를 작성하기 힘들 때는 npx를 사용하면 됩니다. (npx란?)

$ npx eslint -v

이제 ESLint 패키지 설치가 완료되면 초기화를 해주세요.

$ eslint --init

그럼 다음과 같은 단계별 질문이 나옵니다.

? How would you like to use ESLint? … 
To check syntax only
❯ To check syntax and find problems
To check syntax, find problems, and enforce code style

// ESLint의 사용 목적은 무엇인가요?

? What type of modules does your project use? … 
❯ JavaScript modules (import/export)
CommonJS (require/exports)
None of these

// 어떤 타입의 모듈을 사용하나요?

? Which framework does your project use? … 
React
Vue.js
❯None of these

// 어떤 프레임워크에서 사용할 것인가요? (앵귤러는 왜 없나요...)

? Does your project use TypeScript? › No / Yes

// 타입 스크립트를 사용하나요?

? Where does your code run? … (Press <space> to select, <a> to toggle all, <i> to invert selection)
✔ Browser
✔ Node

// 어떤 환경에서 코드가 동작하나요?

? What format do you want your config file to be in? … 
JavaScript
YAML
❯ JSON

// 어떤 포맷으로 ESLint 설정파일을 생성할까요?

완료되면 .eslintrc.json 파일이 생성되며, 이 파일에는 ESLint에 대한 설정들이 있습니다.
.eslintrc.json 파일을 만들기 싫다면, package.json 파일 내의 eslintConfig 부분에서도 설정할 수 있습니다.

.eslintignore 파일을 생성하여 해당 파일, 폴더들에 대한 ESLint를 무시할 수도 있습니다. (프로젝트 내의 /node_modules/* and /bower_components/* 는 기본적으로 제외되어 있습니다.)

그럼 이제 예제를 통해 ESLint를 적용해 봅시다. test.js 파일을 생성해 주세요.

// test.js

const abc = 0

test.js 파일 생성후, 커맨드 창에 아래와 같이 입력하면 다음과 같은 메시지를 확인할 수 있습니다.

$ eslint test.js


/Users/soojae/IdeaProjects/Blog/Tools/Example/test.js
1:7 error 'abc' is assigned a value but never used no-unused-vars

✖ 1 problem (1 error, 0 warnings)

내용을 보니 변수를 선언한 후 사용을 하지 않아서 발생한 에러인 것을 확인할 수 있습니다.

console.log(abc)를 추가해서 abc를 사용해주세요.

// test.js

const abc = 0

console.log(abc)

다시 eslint test.js를 입력하면 에러가 발생하지 않는 것을 확인할 수 있습니다.

이제 간단한 에러를 자동으로 해결해주는 --fix를 사용해봅시다.

// package.json

[
  rules: {
  "semi": "error",
  }
]

"semi"는 세미콜론(;)이 필요한 위치에 없을 시 에러를 발생시킵니다.

$ eslint test.js --fix

test.js 파일을 확인해보면, 세미콜론(;)이 자동적으로 추가된 것을 확인할 수 있습니다.

// test.js

const abc = 0;

console.log(abc);

이제 ESLint와 한 세트로 붙어 다니는 Prettier에 대해 알아봅시다.

Prettier

Prettier는 어느 경우에 사용할까요? 사실 실 생활에서도 Pretter가 적용되어 있습니다.
탕수육(Code)을 먹을 때 부먹이냐 찍먹이냐의 싸울 때, 결국 사주는 사람(Pritter)의 취향으로 가게 됩니다.
코드로 본다면 한 개발자는 indent 값을 2로 주고 싶은데, 또 다른 개발자는 4로 주고 싶을 경우가 있을 것입니다. 이를 해결해 주는 것이 Prettier입니다.

Prettier는 2016년에 등장한 코드 포맷터입니다. Prettier를 사용하면 코드를 완전히 다시 작성해줍니다.(변경이 필요한 부분만 바꾸는 것이 아니라, 코드 전체를 새로 작성합니다.)
새로 작성한다고 해도 코드 내용은 변하지 않고, 구조적 뷰만 변경됩니다.

$ npm i -g -E prettier
$ npm i -D -E prettier

-E는 --save-exac의 축약어로서 해당 패키지를 정확한 버전으로 설치해줍니다. Prettier에서는 버전이 달라지면서 스타일이 변할 수 있기 때문에 이 옵션을 붙이는 것을 권장합니다.

이제 설정 파일인 .prettierrc.json 파일을 생성하고, Prettier 옵션을 https://prettier.io/docs/en/options.html 에 들어가서 알맞게 변경해주세요. 아래는 예시입니다.

//.prettierrc.json

{
  "arrowParens": "avoid",
  "bracketSpacing": true,
  "htmlWhitespaceSensitivity": "css",
  "insertPragma": false,
  "jsxBracketSameLine": false,
  "jsxSingleQuote": false,
  "printWidth": 80,
  "proseWrap": "preserve",
  "quoteProps": "as-needed",
  "requirePragma": false,
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "none",
  "useTabs": false
}

이제 test.js 파일을 다음과 같이 수정해주세요.

// test.js

const abc
= 0
    
console.
log(abc)

prettier를 적용하면 다음과 같은 결과가 나옵니다.

$ prettier test.js --write

// test.js

const abc = 0;
    
console.log(abc);

ESLint VS Prettier

ESLint는 코드 포맷터의 역할도 하지만, 주로 코드 에러를 잡아내고 코드 문법을 강제하는 등 코드 품질을 개선에 중점을 두었습니다.
Prettier는 코드의 최대 길이, 함수에서, 작은따옴표(')를 사용할 것인지 아니면 큰 따옴표(")를 사용할 것인지 등 코드가 예쁘게 보이도록 하는지에 중점을 두었습니다. 하지만 코드의 에러를 잡아내진 못합니다.
Prettier 공식 홈페이지에는 아래와 같은 문구가 있습니다.

use Prettier for formatting and linters for catching bugs!

즉 ESLint에도 코드 포맷팅이 있긴 하지만 Prettier의 코드 포맷팅에 비해 특화되어있지 않으므로, 코드 에러와 문법을 정적으로 탐지할때는 ESLint를 사용하고 포맷팅에는 Prettier를 사용하면 됩니다.

ESLint + Prettier

이제 ESLint와 Prettier를 같이 사용해봅시다.
하지만 위에서 말씀드렸듯이, ESLint가 코드 포맷터의 역할도 하기 때문에 해당 Prettier와 충돌할 수도 있습니다.
이를 방지하기 위해서 아래의 패키지를 추가합니다.

eslint-config-prettier 패키지는 ESLint 규칙에서 Pretter 규칙과 충돌하는 규칙들을 OFF 시키는 역할을 합니다.

$ npm i -D eslint-config-prettier

eslint-plugin-prettier는 Prettier 규칙들을 ESLint 규칙에 추가하는 패키지입니다. 즉, eslint --fix 만 실행해줘도 prettier --write를 사용할 필요 없이 prettier까지 적용시켜줍니다.

$ npm i -D eslint-plugin-prettier

.eslintrc.json 에 다음을 추가해주세요.

// .eslintrc.json

{
    "plugins": [
        "prettier"
    ],
    "rules": {
        "prettier/prettier": "error"
    }
}

이제 ESLint만 실행해도 Prettier의 포매팅 기능을 포함해서 실행합니다.

Git 저장소에 푸시 전 ESLint, Prettier 강제 적용 하기

매번 ESLint를 실행하는 것은 번거로울 뿐만 아니라, 같은 팀 내 개발자의 실수로 ESLint, Prettier를 적용하지 않은 코드들이 저장소에 푸시될 수도 있습니다.
그렇게 되면 깃 로그에 ESLint, Prettier 적용 같은 생산성 없는 로그들이 쌓이게 됩니다.
이런 경우를 방지하기 위해 commit 전에 코드들에게 ESLint와 Prettier이 강제적으로 적용되도록 만들어 봅시다.

이를 위해서는husky와 lint-staged 패키지가 추가로 필요합니다.

$ npm i -D husky lint-staged

Husky

Git Hook을 편리하게 관리해주는 툴입니다.
git의 특정 이벤트(commit, push, pull 등)가 발생하려고 하면, 그 순간에 Hook을 해서 스크립트가 실행되도록 해주는 것이 Git Hook입니다.

Git Hook에 대한 자세한 설명은 훅으로 Git에 훅 들어가기 에서 확인하시면 됩니다.

간단하게 사용할 용어들만 정리했습니다.

pre-commit : 커밋 메시지를 작성하기 전에 호출됨
prepare-commit-msg : 커밋 메시지 생성 후 편집기 실행 전에 호출됨
commit-msg : 커밋 메시지와 관련된 명령을 넣을 때 호출됨
post-commit : 커밋이 완료되면 호출됨
pre-push : 푸시가 실행되기 전에 호출됨

Husky도 .huskyrc, .huskyrc.json, .huskyrc.js, husky.config.js와 같은 별도의 설정 파일을 만들 수도 있습니다.
package.json 파일에 husky를 추가해주세요.

// package.json

"husky": {
    "hooks": {
      "pre-commit": "eslint --fix && prettier --write",
      "pre-push": "npm test"
    }
  },

lint-staged

husky만 사용한다면 프로젝트 내의 모든 코드를 검사하기 때문에 비효율 적입니다. lint-staged는 git에 staged 상태인 파일만 lint 해주는 도구입니다.

// package.json

"husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "pre-push": "npm test"
    }
  },
  "lint-staged": {
    "*.js": [
      "eslint --fix"
      "prettier --write"
    ]
  }

사실 위에서 eslint-plugin-prettier 패키지를 설치했기 때문에 eslint --fix만 사용해도 prettier --write까지 적용이 됩니다. 이제 에러를 잘 잡아내는지 확인하기 위해 console.log(abc)를 제거해주세요.

// test.js

const abc
= 0

이제 commit을 해주세요.

$ git commit -m "[Tools] eslint husky lint-staged 테스트"

husky > pre-commit (node v12.18.0)
✔ Preparing...
⚠ Running tasks...
❯ Running tasks for *.js
✖ eslint --fix [FAILED]
◼ prettier --write
↓ Skipped because of errors from tasks. [SKIPPED]
✔ Reverting to original state because of errors...
✔ Cleaning up... 

✖ eslint --fix:

/Users/soojae/IdeaProjects/Blog/Tools/Example/test.js
1:7 error 'abc' is assigned a value but never used no-unused-vars

✖ 1 problem (1 error, 0 warnings)

husky > pre-commit hook failed (add --no-verify to bypass)

변수 abc를 사용하지 않아 에러가 발생했고, commit이 발생되지 않았습니다.
Prettier까지도 적용이 되지 않는 것을 보아, ESLint 단계에서 에러를 잡아내자마자 실행이 멈췄다는 것을 알 수 있습니다.. 이제 ESLint 규칙에 위배되는 코드들이 Git 저장소에 올라 올 일은 없을 것입니다.
이제 다시 console.log(abc)를 추가해주세요.

// test.js

const abc
= 0

console.
log(abc)

다시 커밋을 하면 아래와 같은 메시지가 나옵니다.

$ git commit -m "[Tools] eslint husky lint-staged 테스트"

husky > pre-commit (node v12.18.0)
✔ Preparing...
✔ Running tasks...
✔ Applying modifications...
✔ Cleaning up... 
[master 17e09f6] [Tools] eslint huskey lint-staged 테스트
3 files changed, 17 insertions(+), 15 deletions(-)

commit이 완료되면 test.js에 prettier가 자동적으로 적용된 것을 확인할 수 있습니다.

// test.js
// prettier까지 적용된 것을 확인 할 수 있습니다.

const abc = 0;

console.log(abc);

현재 회사에서는 TSLint 만 사용하고 있습니다. 하지만 이번 대형 프로젝트에 투입되면서, 제대로 Lint가 제대로 적용이 안된 코드들이 올라오고 코드 스타일도 각각 달라서 혼란스러웠습니다.
다음 프로젝트에는 ESLint (2019년 이후로 TSLint 업데이트가 중단되고 ESLint에 추가된다고 합니다. TSLint in 2019를 참고해주세요.)와 prettier, husky, 그리고 lint-staged을 사용할 수 있도록 건의를 드려보려고 합니다.

그리고 앞으로 진행할 저의 토이 프로젝트에는 무조건 적용시킬 겁니다. ESLint와 Prettier는 그만큼 강력하고 개발자가 코드에만 집중할 수 있도록 도와주는 유용한 도구입니다.

글에 오류가 있으면 알려주세요. 감사합니다.

REFERENCES

https://jbee.io/web/formatting-code-automatically/

https://medium.com/better-programming/ESLint-vs-prettier-57882d0fec1d

https://subicura.com/2016/07/11/coding-convention.html

https://feynubrick.github.io/2019/05/20/eslint-prettier.html

https://woowabros.github.io/tools/2017/07/12/git_hook.html

https://medium.com/palantir/tslint-in-2019-1a144c2317a9

NCA 자격증 취득 후기

SooJae — Sun, 30 Aug 2020 23:27:40 +0900

회사를 다니면서 틈틈이 공부한 끝에 NCA 자격증을 취득했습니다. 자격증을 취득하기 위해 공부했던 방식과, 후기를 공유하려고 합니다.

네이버 클라우드 플랫폼 자격증 중에는 NCA, NCP, NCE 총 3가지가 있습니다. NCA 취득하고 NCP, NCP를 취득하고 NCE 시험을 볼 수 있습니다.
NCA 시험은 네이버 클라우드 플랫폼 자격증 중의 가장 기초가 되는 자격증입니다. 이 시험은 Overview, Compute, Storage, Network, Media에서 문제가 출제됩니다.

자격증 공부하는 방법은 네이버 클라우드 설명서(docs.ncloud.com/ko/) 사이트에 들어가셔서 Compute, Storage, Network, Media를 순서대로 전부 실습을 해보는 것이 좋습니다.
그 후에, 다시 설명서를 꼼꼼히 보셔야 합니다. 각 메뉴의 첫 번째 문단인 '사용하기 전에' 부분들은 유심히 보셔야 합니다. 그리고 설명서를 읽으시다가 숫자가 출몰한다면 전부 외우셔야 합니다 (예: 한 계정당 생성할 수 있는 서버 개수는 50개, 스토리지 용량 1GB 증가당 40 IOPS 증가, CLA 저장 용량은 100GB 등). 요금 가격까지는 외우실 필요 없지만, 요금이 어떻게 책정되는지는 아셔야 합니다. 글에서 볼드(Bold) 처리된 부분들도 당연히 외워야 합니다.

4가지 항목을 전부 공부하신 후, Overview를 봐야 하는데 사실 이 부분은 어떻게 공부해야 하는지 말씀드리기 조심스럽습니다.
모든 메뉴를 전부 공부하는 것이 완벽하나, 시간이 여의치 않다면 네이버 클라우드 플랫폼의 각 메뉴들이 기본적으로 어떤 일들을 하는지를 간략하게라도 공부하시는 것을 추천드립니다.
제가 봤던 시험에는 Overview에 해당하는 부분들이 VMware on Ncloud, AI·NAVER API, AI·Application Service, Analytics, SECURITY에서 출제되었습니다.
그 후에 네이버 클라우드 서비스(www.ncloud.com/product) 사이트에 들어가셔서 메뉴들을 하나씩 확인하며 특징들을 다시 정리해보시는 것을 추천드립니다.

공부를 하시다 보면 외울 것들이 꽤 많다는 것을 느끼실 텐데 저는 아래와 같은 방식으로 외웠습니다.
예를 들어, 한 계정당 생성할 수 있는 서버 수가 50대이니까 오토 스케일링이나 로드 밸런서에서 사용될 최대 서버 수는 50대가 안 넘겠죠? 오토스케일링당 생성할 수 있는 서버 수는 30대까지고, 하나의 로드밸런서에 바인드 할 수 있는 서버 수는 50대까지입니다.
또, 오토 스케일링을 공부하다 보면 Launch Configuration과 Auto Scaling Group가 나오는데, 전자는 서버 스펙을 설정, 후자는 Auto Scaling Group은 서버 생성 / 반납의 행위에 대한 요소들이라고 생각하시면 됩니다. 그럼 오토 스케일링에 관한 문제에서 해당 문제의 보기들이 Launch Configuration과 Auto Scaling Group 중 각각 어디에 해당하는 내용인지를 쉽게 찾으실 수 있으실 겁니다.

저는 프런트 엔드 개발자여서 인프라 지식이 상대적으로 낮았는데, 이번 NCA를 준비하면서 인프라에 대한 기본적인 지식들을 다시 쌓을 수 있어서 정말 좋았습니다.
오랜만에 자격증 시험을 봐서 힘들었지만, 자격증 취득에 보람을 느꼈습니다. 사실, 코로나 이후 반복되는 집돌이 생활과 끝없는 프런트엔드 공부에 슬럼프가 생겼었습니다.
하지만 NCA 시험을 준비하면서 생활에 활력이 생기고, 슬럼프에서 벗어났습니다. 매일 NCA 공부하고 외우는 것을 반복하니, 프런트엔드 공부가 하고 싶더라고요...
좋은 경험이었습니다. 또다시 프런트엔드 공부에 슬럼프가 발생하면 그땐 또 다른 공부를 하며 극복하려고 합니다.

그럼 NCA를 준비하시는 모든 분들 파이팅하세요!

앵귤러 컴포넌트 생명주기(Angular Component Lifecycle)

SooJae — Fri, 7 Aug 2020 18:29:29 +0900

Angular Component Lifecycle

안녕하세요. 오늘은 앵귤러의 기본이 되는 생명주기에 대해 알아보겠습니다.

앵귤러에는 8단계의 라이프 사이클이 있습니다. (constructor 함수는 타입스크립트에서 동작하므로 제외) 각 단계는 라이프 사이클 훅 이벤트라고 부릅니다.

앵귤러 라이프 사이클

constructor(Typescript)

constructor 함수는 앵귤러와 별개로 타입스크립트에서 호출하는 메서드입니다.
constructor 함수에는 컴포넌트에 의존성들(예: 서비스)을 주입(inject)하는 것이 가장 좋습니다. constructor 함수가 실행된 후에 앵귤러의 라이프 사이클이 실행됩니다.

ngOnChanges

constructor 함수 이후에 제일 처음 호출되는 라이프 사이클 훅 이벤트입니다.
자식컴포넌트에서 @Input 데코레이터를 이용하면 부모 컴포넌트에서 프로퍼티를 전달 받을 수 있습니다. 부모 컴포넌트에서 전달해주는 프로퍼티가 변경되면 ngOnChanges가 재 호출 됩니다.
부모 컴포넌트에서 동일한 값을 전달 받거나 전달 받은 값이 객체 내의 프로퍼티만 바꾼 값일 경우 호출되지 않습니다.
ngOnChanges 훅 함수는 부모 컴포넌트에서 받은 프로퍼티의 정보를 담고 있는 SimpleChanges 파라미터를 하나 더 받습니다. 이 파라미터는 다음과 같은 프로퍼티를 갖고있습니다.

previousValue : 이전에 받은 프로퍼티의 값을 갖고 있습니다.
currentValue : 방금 받은 프로퍼티의 값을 갖고 있습니다.
isFirstChange : 방금 받은 프로퍼티가 첫번째 프로퍼티라면 true, 아니라면 false를 반환합니다.

ngOnInit

ngOnChange 훅 함수 이후에 호출되고 초기에 한번만 호출됩니다.
클래스가 가지고있는 프로퍼티와 @Input을 통해 내려받은 프로퍼티가 모두 초기화가 된 이후에 호출됩니다.
주로 프로퍼티 값 설정, 서비스를 이용해 HTTP통신후 결과값을 프로퍼티에 할당하는 등 화면에 데이터가 표시되기 전 필요한 프로퍼티들을 초기화 시키는데 사용됩니다.

ngDoCheck

컴포넌트의 상태 변경을 감지한 후에 항상 호출됩니다. 그만큼 자주 실행되기 때문에 조심히 사용해야 합니다.
주로 변경 감지 로직 구현, 다른 컴포넌트에 대한 알고리즘을 작성할때 사용합니다.

ngAfterContentInit

컴포넌트의 템플릿을 컴포넌트 뷰로 준비하거나 뷰 안에 있는 디렉티브를 준비한 이후에 실행됩니다.
이 방법은 구성요소의 모든 바인딩을 처음으로 점검할 필요가 있을 때 실행한다.
ngDoCheck 훅 함수가 처음 실행된 직후에 한 번만 호출됩니다. 이 함수는 기본적으로 자식 컴포넌트 초기화와 연결 되어있습니다.

ngAfterContentChecked

ngAfterContentInit 훅 함수가 실행된 후에 호출됩니다.
앵귤러의 변경 감지 메커니즘에 의해 컴포넌트의 내용(content)의 변경을 확인(check)합니다. 또한 ngDoCheck 함수가 실행될 때마다 뒤 이어서 호출됩니다.
이 함수 또한 기본적으로 자식 컴포넌트 초기화와 연결되어 있습니다.

ngAfterViewInit

ngAfterContextChecked 훅 함수가 실행된 후에 호출됩니다.
컴포넌트 뷰가 완전히 초기화 되었을때(자식 컴포넌트 포함) 실행됩니다. 이 라이프 사이클 훅 함수는 오직 컴포넌트에만 적용됩니다.
자식 컴포넌트까지 완전히 초기화 되었을 때 실행되는 특성으로 인해, 부모 컴포넌트에서 자식 컴포넌트에 접근을 하는(@ViewChild 디렉티브) 함수를 사용할때 이 라이프 사이클 함수에 작성을 해줍니다.
화면에 적용 하는 라이브러리(echart, D3 등)또는 @ViewChild 디렉티브를 사용하려면 이 훅 함수에 코드를 넣어야 하기 때문에 자주 사용하는 편입니다.

ngAfterViewChecked

ngAfterViewInit 훅 함수가 실행된 후에 호출됩니다.
앵귤러의 변경 감지 메커니즘에 컴포넌트 뷰(자식 컴포넌트 포함)를 확인(check)합니다. ngAfterContentChecked 훅 함수가 실행될 때마다 이어서 호출됩니다.

ngOnDestroy

컴포넌트가 종료되기 직전에 옵저버블 구독해제, 이벤트 핸들러를 제거해서 메모리 누수를 방지힙니다.

라이프 사이클에서 초기에 한번만 호출하는 훅 함수와 변경을 감지할 때마다 호출함수를 나눈다면, 다음과 같이 정리할 수 있겠습니다.

글에 오류가 있으면 알려주세요. 감사합니다.

REFERENCE

https://indepth.dev/if-you-think-ngdocheck-means-your-component-is-being-checked-read-this-article/
https://www.freecodecamp.org/news/angular-lifecycle-hooks/

함수형 프로그래밍 전문가 되기 (Part 6)

SooJae — Sun, 26 Jul 2020 00:14:56 +0900

이 글은 Charles Scalfani의 So You Want to be a Functional Programmer (Part 6)를 번역한 게시물입니다.
Thank you Charles Scalfani! Thanks to your writing, I can grow into a better developer.

함수형 프로그래밍 컨셉들을 이해하는 첫 단계가 가장 중요하고 때로는 가장 어려운 단계다.
하지만 올바른 관점으로 접근한다면 그렇게 어렵지 않다.

이전 게시물 : Part 1, Part 2, Part 3, Part 4, Part 5

이제 어쩌지?

이 훌륭한 것들을 모두 배웠으니, 당신은 이렇게 생각할 것 이다. "이제 어쩌지? 이제까지 배운 것을 내 프로그래밍에 어떻게 적용시키지?"

사정에 따라 다르다. 만약 당신이 Elm또는 Haskell처럼 순수 함수형 언어를 할줄 안다면, 이 개념들을 잘 활용할 수 있을 것이고 이 언어들이 잘 활용할 수 있도록 도와줄 것이다.

만약 대부분의 사람들 처럼, Javascript 같은 명령형 언어를 사용한다면, 그동안 배웠던 것들을 많이 활용 할 수는 있지만, 훨씬 더 많은 연습이 필요할 것이다.

함수형 자바 스크립트

자바스크립트는 함수형 프로그래밍을 할 수 있도록 해주는 많은 특징들을 갖고있다. 순수하진 않지만 약간의 불변성을 갖도록 해줄 수 있고, 라이브러리를 이용한다면 좀 더 높은 불변성을 갖도록 해줄 수 있다.

이상적이지는 않지만, 만약 사용해야 한다면 함수형 프로그래밍의 이점을 얻지 않을 이유가 없다.

불변성

첫번째 고려해봐야 할 것은 불변성이다. ES2015(ES6)에서 나타난 새로운 키워드인 const가 있다. 이것은 일단 변수를 할당하면, 재할당이 불가능 하다.

const a = 1;
a = 2; // this will throw a TypeError in Chrome, Firefox or Node
       // but not in Safari (circa 10/2016)

정의된 a는 상수이다. 그리고 한번 할당된 후에는 재할당이 불가능 하다. 이 이유로 a = 2는 에러가 발생했다.

문제는 자바스크립트의 const는 한계가 있다는 것이다. 아래 예제를 살펴보자.

const a = {
    x: 1,
    y: 2
};
a.x = 2; // NO EXCEPTION!
a = {}; // this will throw a TypeError

a.x = 2는 왜 에러가 발생하지 않았을까? 그 이유는 단지 변수 a만 const키워드로 불변성이 되었을 뿐이기 때문이다.. a.*은 불변하지 않다.

const도 한계가 있다는 것을 알 수 있다.

그럼 위의 코드를 완전한 불변성을 만들 수 있을까?

불행하게도, 우리는 Immutable.js 라이브러리를 사용하는 방법 밖에 없다. 이 라이브러리는 자바스크립트에게 좀더 나은 불변성을 갖게 해주지만, 코드를 자바처럼 보이게 만든다.

커링과 합성 함수

이전 시리즈에서 커링함수를 어떻게 작성해야 하는지 배웠다.
아래 좀더 복잡한 예시를 살펴보자.

const f = a => b => c => d => a + b + c + d

커링 부분을 직접 작성했다는 것에 주목하자.

f함수를 호출할때 우리는 다음과 같이 작성해야 한다.

console.log(f(1)(2)(3)(4)); // prints 10

Lisp프로그래머가 위의 많은 괄호를 봤다면 울었을 것이다.

커링 함수를 작성하기 위한 많은 라이브러리가 있지만, 내가 가장 좋아하는 라이브러리는 Ramda이다

Ramda를 사용하면 아래와 같이 변경할 수 있다.

const f = R.curry((a, b, c, d) => a + b + c + d);
console.log(f(1, 2, 3, 4)); // prints 10
console.log(f(1, 2)(3, 4)); // also prints 10
console.log(f(1)(2)(3, 4)); // also prints 10

함수 정의는 그리 좋지 않지만, 모든 괄호를 넣을 필요는 없어졌다. 우리가 f를 호출할 때마다 원하는 만큼의 파라미터수를 정할 수 있다는 것에 유의해라.

Ramda를 사용해서 Part3와 Part4에서 작성했던 mult5AfterAdd10을 개선해보자

const add = R.curry((x, y) => x + y);
const mult5 = value => value * 5;
const mult5AfterAdd10 = R.compose(mult5, add(10));

Ramda는 R.add, R.multiply 함수도 있다. 위의 코드를 다시한번 개선 해보자.

const mult5AfterAdd10 = R.compose(R.multiply(5), R.add(10));

Map, Filter 그리고 Reduce

Ramda 라이브러리만의 map, filter, 그리고 reduce가 있다. 비록 이 함수들이 바닐라 자바스크립트의 Array.prototype에도 있지만, Ramda 라이브러리는 커링이 적용된다.

const isOdd = R.flip(R.modulo)(2);
const onlyOdd = R.filter(isOdd);
const isEven = R.complement(isOdd);
const onlyEven = R.filter(isEven);
const numbers = [1, 2, 3, 4, 5, 6, 7, 8];
console.log(onlyEven(numbers)); // prints [2, 4, 6, 8]
console.log(onlyOdd(numbers)); // prints [1, 3, 5, 7]

R.modulo는 2개의 파라미터를 받는다. 첫번째 파라미터는 나눠지는 수이고, 두번째 파라미터는 나누는 수이다.

isOdd 함수는 2로 나눈 나머지 값이다. 나머지가 0이면 falsey(홀수가 아님), 나머지가 1이면 truthy(홀수)이다. 우리는 2를 나누는 수로 지정하기 위해 modulo의 첫번 째와 두번째 파라미터를 뒤바꾼다.

isEven 함수는 단지 isOdd 함수의 보수(complement)일 뿐이다.

onlyOdd 함수는 isOdd의 조건자(boolean 값을 반환)가 있는 filter 함수이다.

onlyEven 함수는 isEven을 조건자로 사용하는 filter이다.

numbers를 onlyEven, onlyOdd에 넘겨줄 때, isEven 그리고 isOdd는 그들의 마지막 파라미터를 받고 우리가 기대한 숫자배열을 리턴한다.

자바스크립트의 단점들

대부분의 프런트엔드 개발자들은 브라우저에서 자바스크립트만을 사용한다. 왜냐하면 Javascript가 오랫동안 유일한 선택이었기 때문이다. 하지만 개발자들은 이제 자바스크립트를 직접 쓰는 것에서 멀어지고 있다.

대신에 개발자들은 다른 언어로 작성한 후, 컴파일 하고, 더 정확하게 자바스크립트로 변환한다.

CoffeeScript는 이런 언어들중에 가장 첫번째로 나온 언어이다. 최근에는 Angular 2에서 채택한 타입스크립트가 있다. Babel 또한 자바스크립트로 변환기(transpiler)로 고려할만 하다.

시간이 지날수록 점점 더 사람들은 이런 방식으로 프로그래밍을 하고 있다.
하지만 이 언어들은 자바스크립트로부터 시작된 언어들이고, 좀더 나아졌을 뿐이다. 순수 함수형 언어에서 자바스크립트로 변환하는 방법은 어떨까?

Elm

이번 시리즈에서 Elm이 함수형 프로그래밍을 이해하는데 도움을 줄 것이다.

근데 Elm이 뭐야? 어떻게 쓰는 건데?

Elm은 순수 함수형 언어이다. TEA(이 아키텍쳐는 Redux 개발자들에게 영감을 주었다.)라고 불리는 Elm 아키텍쳐를 사용하여 웹 응용 프로그램을 만드는데 사용할 수 있다.

Elm 프로그램은 런타임 에러가 없다.

Elm은 창시자인 Evan Czapliki가 일하는 NoRedInk 회사에서 프로덕션으로 사용된다.(그는 Prezi에서 일하기도 했다.)

더 자세한 정보는 NoredInk 출신의 Richard Feldman의 6 Months of Elm in Production 강연을 보아라.

그럼 나의 모든 자바스크립트 코드를 Elm으로 교체해야 하나요?

그럴필요는 없고 점차적으로 변경해가면 된다. 더 공부를 하고싶다면 다음 블로그를 보아라. How to use Elm at Work

Elm을 배워야 하는 이유

1. 순수 함수 언어로 프로그래밍을 하는 것은 제한적이기도 하고 자유롭기도 하다. 그것은 당신이 할 수 있는 것을 제한하지만 동시에 버그나, 나쁜 디자인으로부터 자유롭게 해준다. 모든 Elm은 Functionally Reactive Model인 Elm 아키텍쳐를 따르기 때문이다.

2. 함수형 언어는 당신이 더 좋은 프로그래머가 될 수 있도록 해준다. 이 글에 있는 내용들은 빙산에 일각이다. 당신은 프로그램을 경량화하고 안정되게 동작시키기 위해선 좀더 공부할 필요가 있다.

3. 자바스크립트라는 언어를 만드는데 10일밖에 걸리지 않았다. 하지만 20년간 다소 함수적이고, 다소 객체지향 적이며, 완전히 명령형 프로그래밍 언어가 되었다. Elm은 수십년동안 수학과 컴퓨터 과학 분야에서 활동해온 Haskell 커뮤니티에서 30년간 배운 것을 이용해 디자인 되었다.
Elm 아키텍쳐(TEA)는 수십년간 디자인되고 정제되었다. 그리고 Evan의 논문인 Functional Reactive Programming의 결과물이다. 이 디자인의 공식화에 들어간 사고(thinking)의 수준의 진가는 Controlling Time and Space를 보면 알 수 있다.

4. Elm은 개발자들의 더 나은 삶을 목표로 프런트엔드 개발자에 의해 디자인 되었다. Let's Be Mainstream를 보면 Elm의 목표를 좀 더 이해할 수 있을 것이다.

미래에는?

미래에 대해서 단정짓는 것은 불가능 하다. 하지만 약간의 추측은 할 수 있다. 아래는 내가 추측한 것들이다.

자바스크립트로 컴파일 되는 언어들이 주목 받을 것이다.

40년이상 존재해온 함수형 프로그래밍의 개념들은 소프트웨어의 복잡성 문제를 해결하기 위해 재평가 될 것이다.

하드웨어의 상태(예: 대량의 값싼 메모리와 빠른 프로세서)는 함수형 기술들을 가능하게 할 것이다.

CPU는 더 이상 빨라지지 않겠지만 코어 수는 계속 증가할 것이다.

가변 상태는 복잡한 시스템에서 가장 큰 문제중 하나로 인식될 것이다.

나는 지난 몇년 동안을 함수형 프로그래밍을 배우면서(물론 아직도 배우는 중이다.), 함수형 프로그래밍이 미래라고 믿고있기 때문에 이 글들을 작성했다.

내 목표는 다른 사람들이 이런 것들을 더 쉽게 배우고, 더 나은 프로그래머가 될 수 있도록 도와서 그들이 미래에 더 경쟁력 있는 직업을 가질수 있도록 돕는 것이다.

Elm이 미래에 거대한 언어가 될 것이라는 나의 예측이 틀렸다고 하더라도, 나는 함수형 프로그래밍과 Elm이 미래에 그 궤도에 오를 것이라고 확실하게 말할 수 있다.

이 글들을 읽은 후에 함수형 프로그래밍의 개념에 대한 당신의 능력과 이해력에 대해 더욱 자신감을 갖기를 바란다.

앞으로의 당신의 노력에 행운을 빈다.

글에 번역 오류가 있으면 알려주세요. 감사합니다.

함수형 프로그래밍 전문가 되기 (Part 5)

SooJae — Sun, 19 Jul 2020 23:04:03 +0900

이 글은 Charles Scalfani의 So You Want to be a Functional Programmer (Part 5)를 번역한 게시물입니다.
Thank you Charles Scalfani! Thanks to your writing, I can grow into a better developer.

함수형 프로그래밍의 개념을 이해하기 위해 내딛는 첫걸음은 매우 중요하다. 매우 힘든 첫걸음이지만 올바른 관점으로 접근한다면 힘들어할 필요가 없다.

이전 게시물 : Part 1, Part 2, Part 3, Part 4

참조 투명성

참조 투명성은 순수함수가 표현식으로 안전하게 대체될 수 있다고 설명하는 멋진 용어이다. 아래 예제가 이해하는데 도움이 될 것이다.

대수학에서 다음 공식을 봤을 때,

y = x + 10

그리고 x 값이 다음과 같을 때

x = 3

x값을 방정식에 대입하여 다음과 같은 식을 얻을 수 있다.

y = 3 + 10

방정식이 아직 유효하다는 것에 주목해라. 우리는 순수함수로도 위와 같이 대체를 할 수 있다.

여기 Elm로 작성한 문자열 주위에 작은 따옴표를 넣는 함수가 있다.

quote str =
    "'" ++ str ++ "'"

그리고 위의 함수를 사용하는 코드를 살펴보자.

findError key =
    "Unable to find " ++ (quote key)

findError는 key 검색을 실패할때 오류 메시지를 생성한다.

quote 함수가 순수하기 때문에, 우리는 간단히 함수를 quote 함수의 본문 (')으로 대체 할 수 있다.

findError key =
   "Unable to find " ++ ("'" ++ key ++ "'")

나는 이것을 Reverse Refactoring이라고 부른다(그 편이 이해가 잘된다). 이 프로세스는 프로그래머 또는 프로그램이 코드를 추론하기 위해 사용할 수 있다. (예: 컴파일러 또는 테스트 프로그램)

Reverse Refactoring은특히 재귀함수에 대한 추론을 할때 도움이 된다.

실행 순서

대부분의 프로그램들은 싱글 스레드다. 즉 한 번에 하나의 코드만 실행 된다. 프로그램이 멀티스레드 일지라도 대부분의 스레드는 I/O 작업(파일, 네트워크 기타 등등)이 완료될 때 까지 차단된다.

이것이 우리가 코드를 작성할 때 자연스럽게 순차적인 순서(ordered steps) 관점으로 생각하는 이유중 하나이다.

1. 빵을 꺼내라
2. 빵 2조각을 토스트 기계에 넣어라
3. 굽기를 선택해라
4. 레버를 밑으로 내려라
5. 토스트가 올라올때까지 기다려라
6. 토스트를 꺼내라
7. 버터를 꺼내라
8. 버터 칼을 꺼내라
9. 토스트에 버터를 발라라

이 예제에서 2가지 독립적인 동작이 있다. 버터를 꺼내는 것과, 빵을 굽는 것이다. 이들은 9단계가 되서야 상호의존적이 된다.

우리는 7, 8 단계와 1 ~ 6 단계를 동시에 진행 할 수 있다. 왜냐하면 서로에게 독립적인 행동들이기 때문이다.

하지만 동시에 진행하게 되면, 우리는 혼란에 빠진다. 아래의 예시를 살펴보자.

Thread 1
--------
1. 빵을 꺼내라
2. 빵 2조각을 토스트 기계에 넣어라
3. 굽기를 선택해라
4. 레버를 밑으로 내려라
5. 토스트가 올라올때까지 기다려라
6. 토스트를 꺼내라

Thread 2
--------
1. 버터를 꺼내라
2. 버터 칼을 꺼내라
3. Thread 1이 끝날때까지 기다려라
4. 토스트에 버터를 발라라

만약 스레드 1이 실패 하면 스레드 2는 어떤 일이 발생 할까? 두 스레드들을 조율하는 메커니즘은 무엇인가? 누가 토스트의 주인인가? 스레드 1? 스레드 2? 아니면 둘다?

이러한 복잡성에 대해 생각하지 않고, 차라리 우리의 프로그램이 단 하나의 스레드만 사용하도록 하는 것이 더 쉽다.

그러나 프로그램의 효율을 가능한 최대로 짜내야 한다면, 우리는 멀티스레딩 소프트웨어를 만드는 것에 엄청난 노력을 기울여야 한다.

그러나 멀티 스레딩에는 2가지 주요한 문제점이 있다. 첫번 째, 멀티 스레드 프로그램은 쓰기, 읽기, 추론, 테스트, 디버그가 어렵다.

두번째, 자바스크립트 같은 몇몇 언어들은 멀티스레딩을 지원하지 않는다. 지원 하더라도 성능이 좋지 않다.

그러나 순서 상관 없이 모든 것을 병렬로 처리되면 어떨까?

이상한 소리로 들릴지도 모르지만, 그렇게 나쁜 방법은 아니다. 이를 이해하기 위해 Elm 코드를 살펴보자.

buildMessage message value =
    let
        upperMessage =
            String.toUpper message
        quotedValue =
            "'" ++ value ++ "'"
    in
        upperMessage ++ ": " ++ quotedValue

buildMessage는 message와 value를 받은 뒤 대문자 message와 콜론(:), 그리고 작은 따옴표(')안의 value를 생산한다.

병렬로 처리하기 위해서는 upperMessage와 quotedValue가 독립적이여야 한다. 그렇다면 독립적이기 위해서는 어떤 조건이 필요할까?

독립적이기 위해서는 2가지를 충족시켜야 한다.
첫 번째, 순수 함수여야 한다. 순수함수는 실행될 때 서로의 실행에 영향을 끼치지 않기 때문에 독립적이기 위해서 중요하다.
두 번째, 한 함수의 출력 값이 다른 함수의 입력 값이 되면 안된다. 만약 이와 같은 상황이 일어난다면, 첫번째 스레드가 끝날 때까지 두번째 스레드가 실행되지 못하고 기다려야 한다.

위의 코드에서 upperMessage와 quotedValue는 둘다 순수 함수고, 다른 하나의 출력 값을 필요로 하지 않는다.

그러므로 이 두 함수는 순서에 상관없이 실행이 잘 된다.

컴파일러는 프로그래머의 도움없이 알아서 결정 할 수 있다. 하지만 이것은 부작용의 영향을 파악하는 것이 어렵기 때문에 순수 함수 언어에서만 가능하다.

순수 함수 언어의 실행 순서는 컴파일러에 의해 결정된다.

이것은 CPU 속도가 빨라지지 않고 있는 현재 시점에선 굉장한 이점이 있다. CPU 속도가 빨라지지 않는 대신에 코어수가 점점 더 증가하고 있는데, 이는 하드웨어 레벨에서 코드를 병렬로 실행시킬 수 있다는 것을 뜻한다.

불행하게도, 명령형 언어에서는 매우 거친 수준을 제외하고 이러한 코어 수 증가의 장점을 완전히 활용할 수 없다. 완전히 활용하려면 프로그램의 구조를 획기적으로 바꿔야 한다.

순수 함수형 언어를 사용하면 코드를 한줄도 변경하지 않고도 미세한 레벨의 CPU 코어를 자동으로 활용할 수 있다.

타입 명시

전적 타입 언어에서, 타입은 인라인(inline)으로 정의된다. 이 뜻을 이해 하기 위해 아래의 Java 코드를 살펴보자.

public static String quote(String str) {
    return "'" + str + "'";
}

함수 정의와 타입이 어떻게 함께 인라인이 되는지 주목해라. 제네릭을 사용한다면 더 구별하기 힘들어 질 것이다.

private final Map<Integer, String> getPerson(Map<String, String> people, Integer personId) {
// ...
}

나는 타입들을 Bold체로 표시해서 구별하기 쉽게 했지만, 그것들은 여전히 함수 정의에 방해가 된다. 변수의 이름을 찾으려면 주의 깊게 읽어야 한다.

동적 타입 언어에서 이것은 문제가 되지 않는다. 자바스크립트에서 코드를 다음과 같이 작성 할 수 있다.

var getPerson = function(people, personId) {
    // ...
};

타입의 정보가 없는 것이 문제가 되지 않는다면 읽기 더 쉬워진다.
단 하나의 문제는 타입 안전성을 포기한 것이다. 우리는 쉽게 이 파라미터들을 거꾸로 전달할 수도 있다. 즉, people을 숫자타입으로, personId를 객체타입으로 전달할 수 있다. 이렇게 변경을 하더라도 에러가 발생하지 않는다. 즉 프로그램상 문제가 있지만, 어디에서 에러가 발생했는지 발견하기 힘들다는 것을 뜻한다.
자바에서는 이런 현상이 일어나지 않는다. 컴파일 자체가 되지 않기 때문이다.

만약 우리가 자바스크립트의 유연함과 자바의 안정성을 모두 가질 수 있다면 어떨까?

그렇게 할 수 있다. 아래 Elm에서의 함수 타입 명시를 살펴보자.

add : Int -> Int -> Int
add x y =
    x + y

각 라인에서 타입 정보가 어떻게 작성되었는지 주목해라. 띄어쓰기는 분리를 하기 위함이다.

당신은 타입 명시에 오타가 있다고 생각할 수도 있다. 나는 내가 저 코드를 처음봤을때는 첫 -> 가 ,여야 한다고 생각했다. 하지만 오타가 아니었다.

괄호 함축(implied parentheses)을 사용하면 좀더 이해하기 쉬울 것이다.

add : Int -> (Int -> Int)

add 함수는 1개의 Int 파라미터를 사용한다. 그리고 1개의 Int 파라미터를 받고 Int를 리턴하는 함수를 리턴한다.

여기 괄호 함축(implied parentheses)을 사용한 또 다른 타입 명시 예제를 살펴보자.

doSomething : String -> (Int -> (String -> String))
doSomething prefix value suffix =
    prefix ++ (toString value) ++ suffix

doSomething 함수는 1개의 String 파라미터를 받아서 1개의 Int 파라미터를 받는 함수를 리턴하고, 1개의 String 파라미터를 받고 String을 리턴한다.

어떻게 모든 함수들은 1개의 파라미터만 받을까? 그 이유는 Elm에서의 모든 함수는 커링 함수이기 때문이다.

항상 코드는 오른쪽으로 진행되기 때문에 괄호가 필요한 것은 아니다. 그래서 아래와 같이 간단하게 작성할 수 있다.

doSomething : String -> Int -> String -> String

괄호는 함수를 파라미터로서 전달할때 필수적이다. 괄호가 없다면 타입 명시가 애매모호해진다. 아래 예제를 보자.

takes2Params : Int -> Int -> String
takes2Params num1 num2 =
    -- do something

위의 코드는 아래의 코드와 매우 다르다.

takes1Param : (Int -> Int) -> String
takes1Param f =
    -- do something

takes2Param 함수는 2개의 파라미터 Int와 또 다른 Int를 받는다. 반면에 takes1Param 함수는 한개의 (Int -> Int) 파라미터를 받는 함수이다.

여기 map을 위한 타입 명시가 있다.

map : (a -> b) -> List a -> List b
map f list =
    // ...

위 코드의 경우 괄호가 필요하다. 왜냐하면 함수 f의 타입이 (a -> b)이기 때문이다. 즉, 이 함수는 타입이 a인 파라미터를 받고, 타입이 b인 결과값을 리턴한다.

여기 a라는 어떤 타입이 있다. 타입이 대문자라면 그것은 명시적 타입(예 : String)이다.
타입이 소문자라면 그것은 어떤 타입이든 될 수 있다. 여기서 a의 타입이 String일수도 있지만, Int 일수도 있다.

만약 (a -> a) 라면, 그것은 input 타입과 output 타입이 반드시 같아야 한다는 것을 뜻한다.

위 코드의 map의 경우, (a -> b)로 되어있는데, 이는 a(input)와 b(output)가 같은 타입 일수도, 다른 타입 일수도 있다는 것을 뜻한다.

일단 a의 타입이 결정되면, a는 전체 구문에서 반드시 동일해야 한다.

(Int -> String) -> List Int -> List String

위에서 모든 a가 Int로 대체되었다. 그리고 b 또한 String 으로 대체되었다.

List Int 리스트에 Int타입 들이 포함되었다는 뜻이고, List String은 리스트에 String타입들이 포함되어 있다는 것을 뜻한다. 만약 당신이 자바 또는 다른 언어에서 제네릭 타입을 사용한다면 이 개념은 친숙할 것이다.

머리 아파! 이제 한계야!

오늘은 여기까지.

다음 마지막 게시물에서는 당신이 지금까지 배운 것을 실무에서 어떻게 사용할지를 이야기 하려고 한다.

다음 게시물 : Part 6

글에 번역 오류가 있으면 알려주세요. 감사합니다.

함수형 프로그래밍 전문가 되기 (Part 4)

SooJae — Sat, 18 Jul 2020 19:14:25 +0900

이 글은 Charles Scalfani의 So You Want to be a Functional Programmer (Part 4)를 번역한 게시물입니다.
Thank you Charles Scalfani! Thanks to your writing, I can grow into a better developer.

함수형 프로그래밍의 개념을 이해하기 위해 내딛는 첫걸음은 매우 중요하다. 매우 힘든 첫걸음이지만 올바른 관점으로 접근한다면 힘들어할 필요가 없다.

이전 게시물 : Part 1, Part 2, Part 3

커링

Part 3의 마지막 부분에서 mult5 함수는 1개의 파라미터를 받았고, add 함수는 2개의 파라미터를 받았기 때문에 mult5 함수와 add10 함수를 합성할 때 문제가 발생했었다.

우리는 모든 함수가 하나의 파라미터만 받도록 제한함으로써 이 문제를 해결할 수 있다.

나를 믿어라. 이건 그렇게 나쁜 방법이 아니다

우리는 2개의 파라미터를 사용하지만 한 번에 1개만 사용하는 add 함수를 작성한다. 커링 함수는 이것을 가능하게 해 준다.

커링 함수는 한 번에 1개의 파라미터만 받는 함수이다.

커링 함수는 우리가 mult5 함수와 합성하기 전에, 첫 번째 파라미터를 add 함수에게 준다. 그러고 나서 mult5AfterAdd10 함수가 호출될 때, add 함수는 두 번째 파라미터를 받게 된다.

이제 자바스크립트에서 add 함수에 커링을 적용한 것을 살펴보자.

var add = x => y => x + y

이 add 함수는 지금은 하나의 파라미터만 받고 나중에 또 다른 하나의 파라미터를 받는 함수이다.

자세히 말하면, add 함수는 1개의 파라미터 x를 받고, 1개의 파라미터 y를 받는 함수를 리턴하는데, 이는 결국 x와 y를 합하는 결과를 리턴하게 된다.

이제 우리는 이 add 함수를 이용하여 개선된 mult5AfterAdd10 함수를 만들 수 있다.

var compose = (f, g) => x => f(g(x));
var mult5AfterAdd10 = compose(mult5, add(10));

이 합성함수는 2개의 파라미터 f와 g를 받는다. 그리고 x라는 1개의 파라미터를 받는 함수를 리턴한다. 이 함수가 호출될 때 g함수에 x를 적용한 후에 그 결과를 f함수에 적용한다.

그래서 우리가 한건 정확히 뭘까? 단순한 구식 add 함수를 커링 방식의 버전으로 바꿨다. 첫 번째 파라미터인 10을 상위 함수에 전달할 수 있고, 마지막 파라미터는 mult5AfterAdd10이 호출될 때 전달될 것이다. 때문에 add 함수는 좀 더 유연해졌다.

이쯤 되면, Elm에서 커링을 이용한 add 함수를 어떻게 만들지 궁금할 것이다.

궁금할 필요 없다. Elm를 포함한 다른 함수형 언어에서는 모든 함수가 자동으로 컬링 된다.

그래서 add 함수는 동일하다.

add x y =
    x + y

아래 코드가 바로 Part 3에서 작성되었어야 할 mult5AfterAdd10 함수다.

mult5AfterAdd10 =
    (mult5 << add 10)

Elm은 자바스크립트 같은 명령형 언어를 이긴다. 왜냐하면 Elm은 커링과 합성 같은 함수적인 것들에 최적화되어있기 때문이다.

커링과 리팩터링

파라미터가 많은 함수인 일반 버전을 만든 다음, 파라미터가 적은 함수인 특정 버전을 만들기 위해 리팩터링 할 때 커링은 다시 한번 빛난다.

예를 들어, 문자열에 단일 괄호 세트와, 이중 괄호 세트를 추가하는 함수가 아래에 있다.

bracket str =
    "{" ++ str ++ "}"
doubleBracket str =
    "{{" ++ str ++ "}}"

사용 방법은 다음과 같다.

bracketedJoe =
    bracket "Joe"
doubleBracketedJoe =
    doubleBracket "Joe"

우리는 이제 bracket과 doubleBracket을 생성할 수 있다.

generalBracket prefix str suffix =
    prefix ++ str ++ suffix

하지만 이제 generalBracker을 사용할 때마다 bracket을 넘겨줘야 한다.

bracketedJoe =
    generalBracket "{" "Joe" "}"
doubleBracketedJoe =
    generalBracket "{{" "Joe" "}}"

사실 우리가 정말로 원하는 것은 일거양득(the best of both worlds)이다.

만약 우리가 generalBracket의 파라미터의 순서를 바꾼다면, 커링 함수라는 사실을 활용하여 bracket과 doubleBracket을 생성할 수 있다.

generalBracket prefix suffix str =
    prefix ++ str ++ suffix
bracket =
    generalBracket "{" "}"
doubleBracket =
    generalBracket "{{" "}}"

먼저 static으로 고정할 부분(prefix와 suffix)을 첫 번째 파라미터에 넣고, 변경될 가능성이 높은 파라미터(str)를 가장 마지막에 배치하면 쉽게 generalBracket의 특정 버전을 생성할 수 있다.

파라미터의 순서는 완전한 커링 활용을 위해서 중요하다.

또한 bracket과 doubleBracket은 Point-Free 표기법 즉, str 파라미터가 함축되었다는 것에 주목하자. bracket과 doubleBracket 모두 마지막 파라미터를 기다리고 있는 함수이다.

이제 우리는 이전과 동일하게 사용할 수 있다.

bracketedJoe =
    bracket "Joe"
doubleBracketedJoe =
    doubleBracket "Joe"

일반적인 함수형 함수

함수형 언어들에서 사용하는 일반적인 함수 3가지를 알아보자.

그전에, 아래의 자바스크립트 코드를 살펴보자.

for (var i = 0; i < something.length; ++i) {
    // do stuff
}

이 코드는 큰 문제가 있다. 버그는 아니다. 그 문제는 바로 boilerplate 코드다. 즉, 준비 코드를 계속 반복해서 작성해야 한다는 것이다.

만약 당신의 코드가 Java, C#, 자바스크립트, PHP, Python 같은 명령형 언어에서 작성한 코드라면, 당신은 함수형 언어보다 더 많은 boilerplate 코드를 작성하고 있는 자기 자신을 발견할 것이다.

그러니 boilerplate를 없애보자. boilerplate를 하나 또는 두 함수 안에 넣고 다시는 for-loop를 작성하지 않도록 해보자. 음... 사실 명령형 언어가 아닌 함수형 언어를 사용하기 전까지 불가능하다고 보면 된다.

things라는 배열을 변경해보자.

var things = [1, 2, 3, 4];
for (var i = 0; i < things.length; ++i) {
    things[i] = things[i] * 10; // MUTATION ALERT !!!!
}
console.log(things); // [10, 20, 30, 40]

안돼! 불변하지 않잖아!!

다시 시도해 보자. 이번엔 things가 불변할 것이다.

var things = [1, 2, 3, 4];
var newThings = [];
for (var i = 0; i < things.length; ++i) {
    newThings[i] = things[i] * 10;
}
console.log(newThings); // [10, 20, 30, 40]

우리는 things를 불변하게 만들었지만, newThings는 불변하지 않다.
일단 우리는 이 사실을 무시하고 넘어가자. 위의 코드는 명령형 프로그래밍 언어인 자바스크립트로 작성한 것이니까. 우리가 함수형 언어(예: Elm)를 사용한다면 불변할 것이다.

여기서의 요점은 이러한 함수들이 어떻게 동작하는지 이해하고, 우리 코드의 소음을 줄일 수 있도록 돕는 것이다.

이 코드를 가지고 함수에 넣자. 첫 번째, 공통 함수 map을 호출할 것이다. 왜냐하면 이 함수는 이전 배열의 각 요소를 새 배열의 새 값에 매핑시켜주기 때문이다.

var map = (f, array) => {
    var newArray = [];
    for (var i = 0; i < array.length; ++i) {
        newArray[i] = f(array[i]);
    }
    return newArray;
};

함수 f가 전달되어 map함수가 array에 있는 각 요소에 원하는 작업을 할 수 있다는 것에 주목하자.

이제 map 함수를 이용하기 위해 이전 코드를 다시 작성해보자.

var things = [1, 2, 3, 4];
var newThings = map(v => v * 10, things);

for-loop가 없다!. 그리고 훨씬 읽기 쉬워졌고, 추론하기도 쉽다.

기술적으로 map 함수 안에 for-loop가 있다. 그러나 적어도 더 이상 boilerplate 코드를 작성할 필요가 없어졌다.

이제 또 다른 공통 함수인 filter를 작성해보자.

var filter = (pred, array) => {
    var newArray = [];
for (var i = 0; i < array.length; ++i) {
        if (pred(array[i]))
            newArray[newArray.length] = array[i];
    }
    return newArray;
};

어떻게 pred 함수가 배열의 요소를 유지하고 싶으면 True, 요소를 버리고 싶으면 False를 리턴하는지 살펴보자.

아래의 filter 함수가 홀수를 필터링하는 동작을 살펴보자.

var isOdd = x => x % 2 !== 0;
var numbers = [1, 2, 3, 4, 5];
var oddNumbers = filter(isOdd, numbers);
console.log(oddNumbers); // [1, 3, 5]

새로운 filter 함수를 사용하는 것은 직접 for-loop 반복문을 작성하는 것보다 매우 간단하다.

마지막 공통 함수형 함수는 reduce이다. reduce는 리스트를 갖고 와서 하나의 값으로 줄이기 위해 사용되지만, 실제로는 훨씬 더 많은 것을 할 수 있다.

아래 함수는 함수형 언어에서 fold라고 불린다.

var reduce = (f, start, array) => {
    var acc = start;
    for (var i = 0; i < array.length; ++i)
        acc = f(array[i], acc); // f() 함수는 파라미터 2개를 받는다.
    return acc;
});

reduce함수는 f라는 감축 함수와 초기 값, 그리고 배열을 사용한다.

감축 함수인 f는 2개의 파라미터, array의 최근 요소, 그리고 누산기인 acc를 받는다. f함수는 이 파라미터들을 사용하여 각 반복마다 새로운 누산기를 생성한다.
반복이 끝나면, 최종 누산기의 값이 리턴된다.

아래는 fold가 어떻게 동작하는지를 이해하기 위한 예제이다.

var add = (x, y) => x + y;
var values = [1, 2, 3, 4, 5];
var sumOfValues = reduce(add, 0, values);
console.log(sumOfValues); // 15

add함수는 2개의 파라미터를 받아서 합한다.
reduce 함수는 초기값이 0부터 시작하고, 합치기 위해 배열 values에 이 값을 전달한다. reduce함수 안에서, 값이 반복됨에 따라 합이 누적된다. 마지막 총 누적된 결괏값인 sumOfValues가 리턴된다.

map, filter, 그리고 reduce 함수는 boilerplate인 for-loop 반복문을 작성할 필요 없이 배열을 조작할 수 있게 해 준다.

함수형 언어에서 map, filter, reduce는 훨씬 유용하다. 생성에서의 loop 조차 없고, 재귀로만 이루어져 있기 때문이다. 반복 함수들은 프로그래밍에 그렇게 많은 도움을 주진 못한다. 하지만 필수적이다.

머리 아파! 이제 한계야!

오늘은 여기까지.

이후 게시물에서는 참조 투명성, 실행 순서, 타입 등에 대해 이야기하려고 한다.

다음 게시물 : Part 5

글에 번역 오류가 있으면 알려주세요 감사합니다.

함수형 프로그래밍 전문가 되기 (Part 3)

SooJae — Thu, 16 Jul 2020 01:31:50 +0900

이 글은 Charles Scalfani의 So You Want to be a Functional Programmer (Part 3)를 번역한 게시물입니다.
Thank you Charles Scalfani! Thanks to your writing, I can grow into a better developer.

함수형 프로그래밍의 개념을 이해하기 위해 내딛는 첫걸음은 매우 중요하다. 매우 힘든 첫걸음이지만 올바른 관점으로 접근한다면 힘들어할 필요가 없다.

이전 게시물 : Part 1, Part 2

합성 함수

프로그래머로서 우리는 게으르다(좋은 뜻). 우리는 빌드, 테스트, 배포 코드를 계속해서 작성하는 것을 원하지 않는다.

우리는 항상 일을 한 번만 하는 방법과 그것을 어떻게 재 사용하여 다른 일을 할 수 있는지 알아내려고 노력한다.

코드 재사용은 좋다. 하지만 코드 재사용을 실제로 실천하긴 어렵다. 코드를 굉장히 상세하게 만들면, 그것을 재사용할 수 없다. 그렇다고 너무 일반적으로 만들면 애당초 사용하기 어려울 수 있다. 코드를 작고 재사용이 가능한 조각으로 만들면 그 코드는 더 복잡한 기능의 조각이 될 수 있다. 그렇기 때문에 이 둘 사이의 균형을 잡는 것이 중요하다.

함수형 프로그래밍에서, 함수들은 빌딩 블록이다. 우리는 매우 구체적인 작업을 하기 위해 함수들을 작성하고 레고 블록처럼 조립한다.

이것이 합성함수이다.

그래서 합성함수는 어떻게 동작할까? 두개의 자바스크립트 함수를 살펴보자.

var add10 = function(value) {
  return value + 10;
};

var mult5 = function(value) {
  return value * 5;
};

꽤 복잡하다. 화살표 함수 표현식을 사용해보자.

var add10 = value => value + 10;
var mult5 = value => value * 5;

훨씬 나아졌다. 이제 value에 10을 더한 값에 5를 곱하는 함수가 필요하다고 생각해보자. 다음과 같이 작성할 수 있을 것이다.

var mult5AfterAdd10 = value => 5 * (value + 10)

매우 간단한 예제이긴 하지만, 함수를 이렇게 작성하는 것은 좋지 않다. 그 이유는
첫째로, 괄호를 잊어버리는 실수를 할 수 있다.
둘째로, 우리는 이미 10을 더하는 함수와 5를 곱하는 함수를 각각 갖고 있다. 즉, 이미 있는 함수들을 다시 작성하고 있다.

그러니 add10과 mult5를 사용해서 새로운 함수를 만들어보자.

var mult5AfterAdd10 = value => mult5(add10(value));

우리는 단지 기존의 함수를 이용해서 mult5AfterAdd10 이라는 함수를 만들었다. 당연히 함수를 새로 만드는 것보다 이 방법이 더 좋다.
수학에서, f ∘ g는 합성 함수이다. 그리고 “g composed with f” 또는 일반적으로 “f after g”라고 읽는다. 그래서 (f ∘ g)(x) 는 x값과 함께 함수 g를 호출한 다음 함수 f를 호출한 것과 같다. 간단히 표현하자면 f(g(x))와 동일하다.

예제에서 우리는 mult5 ∘ add10(“mult5 after add10”)를 갖고 있다, 그러므로 이 함수의 이름은 mult5AfterAdd10 이라고 볼 수 있다. value과 함께 add10을 호출하고 후에 mult5를 호출했다. 간단히 표현하자면 mult5(add10(value))와 동일하다.

네이티브 자바스크립트는 합성함수가 없기 때문에 Elm을 예로 들어보겠다.

add10 value =
    value + 10
mult5 value =
    value * 5
mult5AfterAdd10 value =
    (mult5 << add10) value

Elm에서는 << 라는 연산자로 함수를 합성한다. 이 연산자는 데이터가 어떻게 흘러가는지 시각적으로 알려준다. 첫 번째로 value가 add10으로 전달된다. 그 결과는 mult5로 전달된다.

mult5AfterAdd10에 있는 괄호, (mult5 << add10)를 주시하자. 이것은 value를 적용하기 이전에 먼저 확정적으로 함수끼리 합성을 시키기 위해 괄호가 존재한다.

다음과 같은 방법으로 당신이 원하는 만큼 함수들을 합성할 수 있다.

f x =
   (g << h << s << r << t) x

x는 함수 t에 전달되고, 그 결과 값이 r로 전달된 후, 그 결과 값이 s로 전달된다. 이런 식으로 마지막 g까지 전달된다.
만약 자바스크립트에서 이와 같은 기능을 구현한 적이 있었다면, 그건 g(h(s(r(t(x))))) 이렇게 보였을 것이다. 괄호가 끔찍하다.

Point-Free 표기법

파라미터를 정의할 필요 없이 함수를 작성하는 Point-Free 표기법이라는 코딩 방식이 있다.
처음 보는 사람들은 이 방식이 이상하게 보일 것이지만, 계속 사용하다 보면 이 방식의 간결함에 감탄할 것이다.

당신은 mult5AfterAdd10에서 value가 파라미터 리스트에서 한 번, 사용될 때 한 번, 총 두 번 정의되었다는 것을 알아차렸을 것이다.

-- 이 함수는 파라미터가 1개다. 

mult5AfterAdd10 value =
    (mult5 << add10) value

그러나 이 파라미터는 add10이 동일한 파라미터를 사용할 것이기 때문에 불 필요하다. 같은 동작을 하는 Point-Free 방식으로 바꾸면 아래와 같다.

-- 이 함수 또한 파라미터가 1개다.

mult5AfterAdd10 =
    (mult5 << add10)

Point-Free 방식을 이용한 것이 더 많은 이점이 있다.

첫 번째, 우리는 불필요한 파라미터를 정의하지 않아도 된다. 그로 인해 정의할 파라미터 이름을 생각하느라 머리를 싸매지 않아도 된다.
두 번째, 덜 복잡해지기 때문에 좀 더 읽기 쉬워진다. 위의 예시는 단순하다. 하지만 함수 하나에 무수한 파라미터들이 있다고 상상해보자.

파라다이스에서의 문제

지금까지 어떻게 합성 함수가 동작하는지와 간결성, 명확성, 그리고 유연성을 위해 Point-Free 표기법으로 어떻게 함수를 정의해야 하는지를 살펴보았다.

이제 조금 다른 시나리오에서 이 아이디어들을 사용해보고, 그것들이 어떻게 진행되는지 살펴보자. add10 함수를 add로 변경한다고 상상해보자.

add x y =
    x + y
mult5 value =
    value * 5

어떻게 위의 두 함수를 이용해서 mult5AfterAdd10를 만들까?

읽던걸 멈추고 잠시 생각해보자. 생각이 끝났다면, 작성해보자.

작성이 끝났다면 비교해보자. 당신은 아래와 같이 작성했을 수도 있다.

-- 이 함수는 잘못됐어!!!

mult5AfterAdd10 =
    (mult5 << add) 10

하지만 이 함수는 동작하지 않는다. add의 파라미터가 2개이기 때문이다.

만약 Elm으로 이 개념을 이해하기 어렵다면 Javascript로 작성해보자.

var mult5AfterAdd10 = mult5(add(10)); // 이 함수는 동작하지 않는다.

이 코드는 왜 잘못됐을까?

add 함수는 2개의 파라미터가 필요한데 1개만 입력받았다. 그리고 그 부정확한 결과가 mult5로 전달되었고, 이는 결국 잘못된 결과를 산출할 것이다.

사실 Elm이었으면, 컴파일러 단계에서 에러가 발생할 것이다(Elm의 위대한 장점 중 하나). 다시 작성해보자.

var mult5AfterAdd10 = y => mult5(add(10, y)); // not point-free

이것은 Point-Free 방식이 아니지만, 이 방식으로도 동작은 한다. 하지만 더 이상 함수를 결합하지 못한다.
이 함수가 점점 더 복잡해질수록 문제가 생긴다. 만약 mult5AfterAdd10과 다른 함수를 결합하고 싶을 때가 되면 정말 곤란해질 것이다.
결국, 합성 함수의 유용성은 한계가 있으므로 이 두 개의 함수를 결합할 수 없게 되었다. 너무 아쉽다.

이 문제를 어떻게 해결할 수 있을까?

만약 add함수에 단 하나의 파라미터를 미리 전달하고, 두 번째 파라미터는 mult5AfterAdd10을 호출할 때 전달하는 방법이 있다면 훌륭할 것 같다.

찾아보니 방법이 있다. 커링이라는 방법이다.

머리 아파! 이제 한계야!!

오늘은 여기까지.

이후 게시물에서는 커링, 함수형 함수(map, filter, fold 등등), 참조 투명성 등에 대해 이야기할 예정이다.

다음 게시물: Part 4

글에 번역 오류가 있으면 알려주세요 감사합니다.

함수형 프로그래밍 전문가 되기 (Part 2)

SooJae — Wed, 15 Jul 2020 21:34:00 +0900

이 글은 Charles Scalfani의 So You Want to be a Functional Programmer (Part 2)를 번역한 게시물입니다.
Thank you Charles Scalfani! Thanks to your writing, I can grow into a better developer.

함수형 프로그래밍의 개념을 이해하기 위해 내딛는 첫걸음은 매우 중요하다. 그리고 그 첫 걸음은 매우 힘들다.

이전 게시물 : Part 1

친절한 알림

앞으로 나올 코드를 천천히 읽어라. 코드를 이해한 다음에 다음으로 넘어가라. 각각의 세션은 이전 세션과 이어진다.
서두르게 되면 나중에 중요해질 개념들을 놓칠 수도 있다.

리팩터링

아래 자바스크립트 코드를 보며 잠시 리팩터링에 대해 생각해보도록 하자.

function validateSsn(ssn) {
    if (/^\d{3}-\d{2}-\d{4}$/.exec(ssn))
        console.log('Valid SSN');
    else
        console.log('Invalid SSN');
}
function validatePhone(phone) {
    if (/^\(\d{3}\)\d{3}-\d{4}$/.exec(phone))
        console.log('Valid Phone Number');
    else
        console.log('Invalid Phone Number');
}

우리는 예전에 위와 같은 코드를 썼었다. 시간이 흐른 뒤 우리는 이 두 함수가 몇 가지 차이만 나고, 사실상 동일하다고 깨닫게 된다.

validatePhone 함수와 validateSSn 함수를 각각 복사/붙여 넣기로 만들기보다, 파라미터를 이용해서 단일 함수로 만들어야 한다.

이 예제에서는 값, 정규식, 출력 메시지의 마지막 부분인 'SSN', 'Phone Number'를 파라미터 값으로 지정할 수 있다.

리팩터링 된 코드를 살펴보자.

function validateValue(value, regex, type) {
    if (regex.exec(value))
        console.log('Invalid ' + type);
    else
        console.log('Valid ' + type);
}

이전 코드에서의 ssn과 phone 파라미터들은 이제 value로 표현된다.
정규식인 /^\\d{3}-\\d{2}-\\d{4}$/ 와 /^\$\\d{3}\$\\d{3}-\\d{4}$/ 는 regex로 표현된다.
출력 메시지의 마지막 부분인 'SSN', 'Phone Number'은 type으로 표현된다.

두 개의 함수를 사용하는 것보다 하나의 함수로 리팩터링 하는 것이 더 좋다. 함수들이 점점 늘어날수록 코드는 점점 안 좋아진다.
리팩터링 된 하나의 함수는 당신의 코드를 깔끔하게 하고, 유지 보수하기 좋게 해 준다.

예를 들어 버그가 발생했을 때, 똑같은 로직을 갖고 있는 함수들을 복사/붙여넣기한 경우에는(예: 첫 코드 블록) 전체 코드를 찾아야 한다. 하지만 하나의 함수만 사용한 경우에는 그 함수만 보고 고치면 된다.

하지만 아래와 같은 상황이 발생하면 어떻게 될까?

function validateAddress(address) {
    if (parseAddress(address))
        console.log('Valid Address');
    else
        console.log('Invalid Address');
}

function validateName(name) {
    if (parseFullName(name))
        console.log('Valid Name');
    else
        console.log('Invalid Name');
}

여기 parseAddress와 parseFullName 함수는 문자열을 가져와서 파싱 할 경우 true를 리턴하는 함수다.

이걸 어떻게 리팩터링 해야 할까?

우리는 이전 예제에서 했던 것처럼 address와 name을 value 파라미터로 바꿀 수 있다. 그리고 'Address'와 'Name'을 type로 바꿀 수 있다.
하지만 아직 정규식을 활용하는 함수가 남아있다.

만약 함수를 파라미터로 전달할 수 있다면...

고차 함수

많은 언어가 함수를 파라미터로 전달하는 것을 지원하지 않는다. 몇몇 언어에서는 가능하지만 만들기가 쉽지 않다. 함수형 프로그래밍에서 함수는 1급 시민이다. 다시 말하면 함수를 단지 '값'으로 취급한다.

함수들은 단지 값이기 때문에 우리는 그 함수들을 파라미터로 전달할 수 있다.

비록 자바스크립트가 순수 함수 언어는 아니지만, 당신은 몇몇 함수형 동작들을 할 수 있다. 아래 코드는 파싱 함수를 parseFunc라는 파라미터로 전달하여 위에서 본 두 함수를 단일 함수로 리팩터링 했다.

function validateValueWithFunc(value, parseFunc, type) {
    if (parseFunc(value))
        console.log('Invalid ' + type);
    else
        console.log('Valid ' + type);
}

위의 새로운 함수는 고차 함수라고 불린다.

고차 함수는 함수를 파라미터로 취급하거나, 함수를 리턴한다.

이제 이전 4개 함수에 대해 고차 함수를 호출할 수 있다.(자바스크립트에서 동작하는 Regex.exec는 정규식에 일치하는 부분이 있으면 truthy 한 값을 리턴한다.)

위의 새로운 함수는 고차 함수라고 불린다.

validateValueWithFunc('123-45-6789', /^\d{3}-\d{2}-\d{4}$/.exec, 'SSN');
validateValueWithFunc('(123)456-7890', /^\(\d{3}\)\d{3}-\d{4}$/.exec, 'Phone');
validateValueWithFunc('123 Main St.', parseAddress, 'Address');
validateValueWithFunc('Joe Mama', parseName, 'Name');

위의 코드는 동일한 4가지의 함수를 만드는 것보다 훨씬 좋다.

그런데 정규식을 보면 살짝 지저분하다. 깔끔해지도록 리팩터링 해보자.

var parseSsn = /^\d{3}-\d{2}-\d{4}$/.exec;
var parsePhone = /^\(\d{3}\)\d{3}-\d{4}$/.exec;

validateValueWithFunc('123-45-6789', parseSsn, 'SSN');
validateValueWithFunc('(123)456-7890', parsePhone, 'Phone');
validateValueWithFunc('123 Main St.', parseAddress, 'Address');
validateValueWithFunc('Joe Mama', parseName, 'Name');

훨씬 깔끔해졌다. 이제 우리는 핸드폰 번호를 파싱 하기 원할 때, 정규식을 복사/붙여넣기 하지 않아도 된다.

그러나 우리가 parseSsn과 parsePhone 외에, 파싱 하기 위한 더 많은 정규식이 있다고 생각해보자. 매번 정규식 파서를 만들 때마다, 우리는. exec를 끝에 붙여줘야 한다.
장담하건대, 이런 것(뒤에. exec를 붙이는 것)은 잊어버리기 쉽다.

이런 현상은 exec를 리턴하는 고차 함수를 만들어서 방지할 수 있다.

function makeRegexParser(regex) {
    return regex.exec;
}

var parseSsn = makeRegexParser(/^\d{3}-\d{2}-\d{4}$/);
var parsePhone = makeRegexParser(/^\(\d{3}\)\d{3}-\d{4}$/);

validateValueWithFunc('123-45-6789', parseSsn, 'SSN');
validateValueWithFunc('(123)456-7890', parsePhone, 'Phone');
validateValueWithFunc('123 Main St.', parseAddress, 'Address');
validateValueWithFunc('Joe Mama', parseName, 'Name');

makeRegexParser는 정규을 취하고 문자열을 실행하는 exec 함수를 리턴한다. validateValueWithFunc는 string과 value 입력 값을 parse 함수로 전달한다.
parseSsn와 parsePhone는 사실상 이전 코드와 같다. 정규 표현식을 exec 하는 함수이다.

물론, 코드가 많이 향상되었다고는 보기 힘들다. 위 코드는 단지 우리에게 고차 함수가 함수를 리턴하는 것을 보여주기 위한 예제이다.

여기서 makeRegexParser가 좀 더 복잡해졌을 때의 장점을 상상해보자.

고차 함수가 함수를 리턴하는 또 다른 예제를 살펴보자.

function makeAdder(constantValue) {
    return function adder(value) {
        return constantValue + value;
    };
}

파라미터인 constantValue와 adder를 리턴하는 makeAddr 함수가 있다. 이 함수는 입력된 파라미터 값에 전달받은 상수를 더한다.

어떻게 사용하는지 살펴보자.

var add10 = makeAdder(10);
console.log(add10(20)); // prints 30
console.log(add10(30)); // prints 40
console.log(add10(40)); // prints 50

우리는 add10 함수를 만들었다. 상수 10을 함수를 리턴하는 makeAdder에 전달해줌으로써 모든 값에 10이 더해질 것이다.

함수 adder는 makeAdder 함수가 리턴된 후에도 constantValue에 접근 할 수 있다는 점에 주목해라. 접근할 수 있었던 이유는 constantValue가 adder 함수가 생성되었을 때 해당 스코프에 있었기 때문이다.

이러한 동작은 매우 중요하다. 이런 동작이 없다면 함수가 함수를 리턴하는 것이 별로 유용하지 않았을 것이기 때문이다. 그래서 이 코드들이 어떻게 동작하는지 이해하는 것은 매우 중요하다.
이 동작은 클로저라고 한다.

클로저

클로저를 이용한 함수들을 살펴보자.

function grandParent(g1, g2) {
    var g3 = 3;
    return function parent(p1, p2) {
        var p3 = 33;
        return function child(c1, c2) {
            var c3 = 333;
            return g1 + g2 + g3 + p1 + p2 + p3 + c1 + c2 + c3;
        };
    };
}

이 예제에서 child는 child 자신의 변수들과 parent의 변수들, 그리고 grandParent의 변수 들에 접근한다.
parent는 parent 자신의 변수들과, grandParent의 변수에 접근한다.
grandParent는 오직 grandParent 자신의 변수들에 접근한다.

(위의 피라미드를 참고해라.)

이를 이용한 예제를 살펴보자.

var parentFunc = grandParent(1, 2); // returns parent()
var childFunc = parentFunc(11, 22); // returns child()
console.log(childFunc(111, 222)); // prints 738
// 1 + 2 + 3 + 11 + 22 + 33 + 111 + 222 + 333 == 738

parentFunc는 grandParent가 parent를 리턴할 때, parent의 스코프가 살아있도록 유지시켜준다.
비슷하게 childFunc는 parent가 child를 리턴할 때, child의 스코프가 살아있도록 유지시켜준다.

함수가 만들어질 때, 만들어졌을 당시 스코프의 모든 변수들은 함수의 생명 주기 동안 접근할 수 있다.
함수는 참조가 남아있는 한 여전히 존재한다. 예를 들어 child의 스코프는 childFunc가 child의 스코프를 계속 참조하는 한 존재한다.

클로저는 함수에 대한 참조에 의해 계속 살아 있는 함수의 스코프이다.

자바스크립트 안에서의 클로저들은 변수들이 변할 수(mutable) 있기 때문에 문제가 된다. 즉, 클로저들은 닫힌 시점부터 반환된 함수가 호출될 때까지 값을 변경할 수 있다.

고맙게도, 함수형 프로그래밍의 변수들은 불변(Immutable)하여 버그와 혼동이 생기지 않도록 해준다.

머리 아파! 이제 한계야!

오늘은 여기까지.

이후 게시물에서는 합성 함수, 커링, 일반적인 함수형 함수(map, filter, fold 등등) 등에 대해 이야기 할 예정이다.

다음 게시물 : Part3

글에 번역 오류가 있으면 알려주세요 감사합니다.

함수형 프로그래밍 전문가 되기 (Part 1)

SooJae — Sat, 11 Jul 2020 15:49:38 +0900

이 글은 Charles Scalfani의 So You Want to be a Functional Programmer (Part 1) 를 번역한 게시물입니다.

Thank you Charles Scalfani! Thanks to your writing, I can grow into a better developer.

운전 배우기

다른 사람들이 운전하는 것은 쉬워 보였지만, 우리가 운전을 배울 때는 생각했던 것보다 더 어려웠다.
우리는 부모님의 차로 연습을 했고, 동네의 길을 완전히 익힐 때까지는 고속도로를 달리지 않았다.
반복되는 연습과 공포스러운 순간들을 보내면서, 운전을 배우게 되고 마침내 운전면허증을 취득했다.

운전면허를 취득한 후, 여행할 때마다 우리의 운전실력은 점점 좋아졌고 자신감도 높아졌다.
그러다 다른 사람의 차를 운전해야 하거나, 기존의 차를 떠나보내고 새로운 차를 사야 하는 날이 왔다.

다른 차의 운전대 뒤에 앉아본 적이 없었나? 운전대 뒤에 앉은 게 정말 처음이었나? 사실 처음은 아니었다.
하지만 이전에 차에 탔을 때는 승객일 뿐이었다. 이번에는 모든 것을 제어하는 운전석에 앉아있다.

다른 차를 운전했을 때, 우리는 자신에게 몇 가지 질문을 던졌다. 열쇠는 어디에 꽂고, 라이트는 어디에 있고, 어떻게 방향 지시등을 사용하고, 어떻게 사이드 미러를 조정하는지.
그 후, 차는 꽤 순조롭게 항해했다. 처음과 비교해서 왜 쉬워진 것일까?

그 이유는 그 차가 예전 차와 꽤 비슷하기 때문이다. 그것은 차에 필요한 기본적인 것들을 모두 갖고 있고, 그 기본적인 것들은 비슷한 자리에 위치해있다.

이전 차와 몇 가지가 다르게 구현되었고, 추가된 기능들이 있을 수도 있다. 그 기능들은 처음 운전할 때, 심지어 두 번째 운전할 때도 사용하지 않는다. 하지만 시간이 흘러 우리가 유용하다고 판단되는 차의 새로운 기능들을 자연스럽게 배우게 된다.

프로그래밍 언어를 배우는 것은 이와 같다. 처음에는 가장 어렵다. 그러나 일단 허리띠를 졸라매면, 그 뒤의 것은 더 쉬워진다.

제2 외국어를 처음 시작할 때, 당신은 다음과 같은 질문을 묻는다. "모듈을 어떻게 만들지? 배열을 어떻게 탐색하지? substring 함수에서 파라미터는 무엇이지?"

당신이 이 새로운 언어를 배울 수 있다고 확신한다. 왜냐하면 그 새로운 언어는 당신이 예전에 배웠던 언어들에서 편하게 사용하기 위해 몇 가지 새로운 것들이 추가된 것뿐이기 때문이다.

당신의 첫 우주선

평생 한 대의 차를 운전해 왔든 수십 대의 차를 운전해 왔든, 당신이 우주선의 운전대 잡게 될 것이라고 생각해 봐라.

만약 당신이 우주선을 운행할 것이라면, 당신의 운전실력이 우주선을 운행하는 것에 도움을 줄 것이라고 기대하지 않는다. 0부터 다시 배울 것이라고 생각할 것이다.
아마 당신은 그 우주선을 운행하는 것은 지상에서 운전하는 것과 매우 다르다는 생각으로 훈련을 시작할 것이다.

물리학적으로는 변하지 않았다. 같은 우주에서 운행하는 것뿐이다.

함수형 프로그래밍을 배우는 것도 마찬가지다. 이제까지 자신이 알고 있던 프로그래밍 방식과 매우 달라질 것이라고 예상해야 한다. 그리고 당신이 알고 있는 기존 프로그래밍에 대한 많은 지식들은 함수형 프로그래밍을 이해하는데 도움이 되지 않을 것이다.

함수형 프로그래밍은 당신이 생각하는 기존 프로그래밍과 매우 다른 생각을 가지도록 가르쳐줄 것이다. 그만큼 함수형 프로그래밍을 깨닫게 된다면, 당신은 아마 기존 프로그래밍의 사고방식으로 돌아가지 않을 것이다.

당신이 알고 있는 모든 것을 잊어라

사람들은 이 구절을 이야기하는 것을 좋아한다. 함수형 프로그래밍을 배우는 것은 프로그래밍 공부를 처음부터 시작하는 것과 같다. 기존에 알고 있던 비슷한 많은 개념이 있지만, 모든 것을 다시 배워야 한다고 생각하는 것이 가장 좋다.

올바른 관점을 가진다면 올바른 생각을 가질 것이고, 올바른 관점은 개념이 어렵더라도 포기하지 않게 해 줄 것이다.

당신이 프로그래머로서 작성하던 기존 코드들 중에, 함수형 프로그래밍으로는 대체할 수 없는 부분들이 있다.

자동차는 후진을 할 수 있다. 하지만 우주선에서는 후진을 할 수 없다. "띠용? 후진을 못한다고?! 후진 없이 어떻게 운전을 하라고?!" 우주선은 3차원 공간에서 조종할 수 있기 때문에 역주행이 필요 없다는 것이 밝혀졌다. 일단 이것을 이해한다면, 당신은 절대 후진을 하지 않을 것이다. 사실 언젠간 당신은 '자동차는 왜 이렇게 제한이 많나?'라고 생각할 날이 올 것이다.

함수형 프로그래밍은 배우는 시간이 좀 걸린다. 그러니 인내심을 가져라.

그러므로 명령형 프로그래밍을 사용하던 냉동 창고에서 벗어나 함수형 프로그래밍이라는 온천에 살짝 들어가 보자.

앞으로 나올 많은 게시물들은 함수형 프로그래밍의 개념들에 대한 게시물이며, 당신이 함수형 프로그래밍을 배우기 전에 도움이 될 만한 것들이다.
만약 당신이 이미 함수형 프로그래밍에 대해 알고 있다면, 개념을 정리하는데 도움이 될 것이다.

함수형 프로그래밍을 배우기 위해 서두르지 마라, 지금부터 천천히 읽고 코딩 예제를 이해하는 시간을 가져라.
심지어 당신은 각 섹션이 끝난 후 생각을 정리하기 위해 읽는 것을 멈추고 싶을지도 모른다. 그럼 시간을 충분히 갖고 생각을 다 끝낸 후에 읽으면 된다.

가장 중요한 것은 당신이 이해하는 것이다.

순수성

함수형 프로그래밍을 사용하는 사람들이 순수성을 말할 때, 순수 함수를 언급한다.

순수 함수는 매우 간단한 함수이다. 순수 함수는 단지 입력된 파라미터에 따라 동작할 뿐이다.

아래는 자바스크립트의 순수 함수 예제이다.

var z = 10;
function add(x, y) {
  return x + y;
}

위의 add함수가 z변수에 접근하지 않는 것에 유의해라. add함수는 z변수를 읽지도, 쓰지도 않는다. 단지 입력된 파라미 터인 x와 y을 읽고, 두 파라미터를 더해서 결과로 반환할 뿐이다.

이것이 순수 함수이다. 만약 add함수가 z에 접근했다면, 더 이상 순수 함수가 아니다.

여기 또 다른 함수가 있다.

function justTen() {
  return 10;
}

함수 justTen이 순수 함수라면 상수만 반환할 수 있다. 왜?
왜냐하면 파라미터 값을 주지 않았기 때문이다. 순수 함수이기 때문에 입력된 파라미터 외에는 어떠한 것도 접근할 수 없다. 그러므로 이 함수가 반환할 수 있는 것은 상수 밖에 없다.

순수 함수는 파라미터 값들이 없으면 동작하지 않기 때문에 유용하지 않다. 함수 justTen이 위와 같이 정의되었다면 차라리 상수 값 10을 정의하여 사용하는 편이 낫다.

가장 유용한 순수 함수는 적어도 하나의 파라미터를 갖고 있어야 한다.

이 함수를 살펴보자

function addNoReturn(x, y) {
  var z = x + y
}

이 함수는 아무것도 반환하지 않는다. x와 y를 더한 후 변수 z에 대입하지만, 아무것도 반환은 하지 않는다.

유용한 순수 함수들은 무엇인가를 반환해야 한다.

처음에 봤던 add 함수를 다시 살펴보자.

function add(x, y) {
  return x + y;
}
console.log(add(1, 2)); // prints 3
console.log(add(1, 2)); // still prints 3
console.log(add(1, 2)); // WILL ALWAYS print 3

add(1, 2)은 항상 3을 반환한다는 것을 알 수 있다. 그렇게 놀랄 일이 아니다. 왜냐하면 순수 함수이기 때문이다.
만약 add 함수가 외부 값을 사용했다면, 함수의 동작을 예측할 수 없다.

순수 함수는 같은 Input이 입력된다면, 항상 같은 Output을 반환한다.

순수 함수는 외부 변수를 수정할 수 없다. 아래 함수들은 순수 함수가 아니다.

writeFile(fileName);
updateDatabaseTable(sqlCmd);
sendAjaxRequest(ajaxRequest);
openSocket(ipAddress);

위의 함수들은 모두 부작용(Side Effects)이 있다. 위 함수들은 호출될 때 파일이나 데이터베이스의 테이블을 조작하고, 데이터를 서버에 보낸다. 그리고 소켓통신을 하기 위해 OS를 호출한다. 위의 함수들은 단순히 입력된 값을 실행하는 것 외에 추가적으로 다른 작업을 한다.
당신은 절대 이 함수들이 어떤 값을 반환할지 예측할 수 없다.

순수 함수는 부작용(Side Effects)이 없다.

Javascript, Java, 그리고 C#과 같은 명령형 프로그래밍 언어에는 어디에나 부작용이 있다. 이는 프로그램의 어느 곳에서든 변수가 수정될 수 있기 때문에 디버깅을 매우 어렵게 만든다. 그럼 변수가 잘못된 값으로 바뀌어서 버그가 생겼을 때 어디를 봐야 하나? 모든 코드를 일일이 봐야 하나? 그건 좋지 않은 방법이다.

이쯤 되면 아마 "순수 함수만으로 어떻게 프로그래밍을 하라는 거야?"라고 생각할 것이다.

함수형 프로그래밍은 단순히 순수 함수를 작성하는 것만이 아니다.

함수형 언어들로 코드의 부작용을 완전히 없앨 수는 없다. 단지 부작용을 억제를 할 뿐이다. 왜냐하면 프로그램은 사용자와 밀접한 관계가 있기 때문에, 순수 함수로만 프로그램을 만들 수 없다.
우리의 목표는 비순수 함수를 최소한으로 하고, 우리의 프로그램의 순수 함수와 분리해서 작성하는 것이다.

불변성

아래의 코드를 처음 봤을 때가 생각나니?

var x = 1;
x = x + 1;

위의 코드를 이해하려면 수학 시간에 배운 것을 잊어야 한다. 수학에서는 x = x + 1이 성립되지 않는다. 하지만 명령형 프로그래밍에서 위의 식은 x + 1의 결과를 다시 x에 넣으라는 것을 의미한다.

하지만 함수형 프로그래밍에서 x = x + 1은 불가하다. 그렇기에 수학 시간에 잊었던 것들을 다시 기억해야 한다.

함수형 프로그래밍에서는 변수가 없다.

저장된 값들은 여전히 변수라고 불린다. 하지만 그것들은 사실 상수이다. 즉, x에 값이 할당되면 계속 그 값이 유지된다.

걱정하지 마라, x는 지역 변수이기 때문에 생명 주기가 짧다. 그러나 살아있는 동안에는 값이 절대 변할 수 없다.

아래는 웹 개발자를 위한 순수 함수형 프로그래밍 언어인 Elm를 이용한 상수 변수에 대한 예제이다.

addOneToSum y z =
  let
    x = 1
  in
    x + y + z

ML 스타일의 문법에 익숙하지 않다면 설명해 줄 수 있다. addOneToSum 함수는 y와 z 파라미터를 사용하는 함수다.

let 블록 안의 x에는 1이 할당되어 있다. 즉 생명주기 동안 x는 계속 1일 것이다. 이 생명 주기는 함수 실행이 끝날 때 종료될 것이다.
in 블록 안의 let block, viz.x 에는 정의된 값이 포함될 수 있다. x + y + z의 결과를 반환한다.

다시 한번 "변수 없이 프로그래밍을 어떻게 하라는 거지?"라는 소리가 나올 것이다.

언제 변수를 수정하고 싶은지 생각해보자. 떠오르는 2가지의 일반적인 경우가 있다. 바로 다중 값 수정(예: 객체나 레코드의 단일 값 수정)과 단일 값 수정(예: 반복문 카운터)이다.

함수형 프로그래밍은 값이 수정된 레코드의 복사본을 만들어 레코드의 값을 수정한다. 이를 가능하게 하는 데이터 구조를 이용하여 레코드의 모든 부분을 복사할 필요 없이 효율적으로 이를 수행한다.

함수형 프로그래밍의 값을 복사하는 방법으로 단일 값도 수정할 수 있다.

아, 반복문은 사용하지 않는다.

"뭐? 변수도 없는데 지금 반복문도 없다고 하는 거야? 화가 난다! 화가 나!"

워 워, 캄다운. 우리가 루프를 할 수 없는 것이 아니라, 단지 for, while, do, repeat, 기타 등등 같은 특정 반복문 구조들을 사용하지 않는 것이다.

함수형 프로그래밍은 반복을 하기 위해 재귀 함수를 이용한다.

여기 당신이 자바스크립트에서 반복을 사용할 수 있는 두 가지 방법이 있다.

// simple loop construct
var acc = 0;
for (var i = 1; i <= 10; ++i)
  acc += i;
console.log(acc); // prints 55

// without loop construct or variables (recursion)
function sumRange(start, end, acc) {
  if (start > end)
    return acc;
  return sumRange(start + 1, end, acc + start)
}
console.log(sumRange(1, 10, 0)); // prints 55

어떻게 재귀 함수가 스스로를 호출하여 for 반복문과 동일한 기능을 할 수 있는지 보자. 재귀 함수는 이전 값들을 수정하지 않는다. 대신에 이전 값들을 계산하고 반환된 새로운 값을 사용한다.

사실 함수형 프로그래밍을 조금만 공부해보면 자바스크립트에서는 재귀 함수를 찾기 힘들다는 것을 알게 된다. 두 가지 이유가 있다.
첫 번째, 자바스크립트의 문법은 매끄럽지 못하다(Syntax of Javascript is noisy). 두 번째, 당신은 아마 재귀적으로 생각하는 것에 익숙하지 않을 것이다.

Elm 문법을 보자. 좀 더 읽기 쉽고 이해하기 쉽다.

sumRange start end acc = 
  if start > end then 
    acc 
  else 
    sumRange (start + 1) end (acc + start)

실행해보면 아래와 같은 결과가 나온다.

sumRange 1 10 0 = -- sumRange (1 + 1) 10 (0 + 1)
sumRange 2 10 1 = -- sumRange (2 + 1) 10 (1 + 2)
sumRange 3 10 3 = -- sumRange (3 + 1) 10 (3 + 3)
sumRange 4 10 6 = -- sumRange (4 + 1) 10 (6 + 4)
sumRange 5 10 10 = -- sumRange (5 + 1) 10 (10 + 5)
sumRange 6 10 15 = -- sumRange (6 + 1) 10 (15 + 6)
sumRange 7 10 21 = -- sumRange (7 + 1) 10 (21 + 7)
sumRange 8 10 28 = -- sumRange (8 + 1) 10 (28 + 8)
sumRange 9 10 36 = -- sumRange (9 + 1) 10 (36 + 9)
sumRange 10 10 45 = -- sumRange (10 + 1) 10 (45 + 10)
sumRange 11 10 55 = -- 11 > 10 => 55
55

당신은 아마 for 반복문이 훨씬 이해하기 쉽다고 생각할 것이다. 논쟁의 여지가 있고, 좀 더 친숙함의 문제가 있지만, 비 재귀 함수의 반복문은 불변하지 않기(Mutaility) 때문에 좋지 않다.

여기서 불변성에 대해서 전부 설명하긴 힘들다. 불변성에 좀 더 공부하고 싶다면 Why Programmers Need Limits의 Global Mutable State 섹션을 보아라.

불변성의 확실한 장점은 만약 당신의 프로그램에 있는 변수에 접근할 경우, 당신은 오직 읽기만 할 수 있다. 즉, 아무도 그 값을 바꿀 수 없다는 뜻이다. 그렇기 때문에 어떠한 경우도 값이 바뀔 일이 없다.

그리고 만약 프로그램이 멀티 스레드라면, A 스레드가 B 스레드의 값을 변경할 수 없다. 값은 변하지 않으며, 만약 A 스레드에서 B스레드의 값을 수정하려면 기존 값으로부터 새로운 값을 만들어야 한다.

나는 90년대 중반에 Creature Crunch 라는 게임 엔진을 개발했었다. 그 엔진의 버그가 발생하는 가장 큰 원인은 멀티 스레드 문제였다. 그때 불변성에 대해 알았으면 좋았을 것이다. 하지만 그 당시 나는 2x와 4x CD-ROM 드라이브에서 실행되는 게임의 성능을 비교하는 것에 열중해 있었다.

불변성은 좀 더 간단하고, 안전한 코드를 만들어준다.

머리 아파! 이제 한계야!

오늘은 여기까지.

이 이후에는 고차 함수, 합성 함수, 커링 등에 대해서 포스팅할 예정이다.

다음 게시물 : Part2

글에 번역 오류가 있으면 알려주세요. 감사합니다.

[MacOS][Docker] Jenkins - 2. Jenkins 설정

SooJae — Mon, 2 Mar 2020 18:32:51 +0900

1. Plugin

필요한 플러그인을 설치해봅시다. 저는 빌드할 때 npm 명령어를 사용해야 해서 NodeJS 플러그인을 설치하겠습니다.
Jenkins 관리 - 플러그인 관리를 클릭합니다.

그 후에 설치 가능 탭을 누르고, 필터에 필요한 플러그인을 검색합니다.
그 후에 체크박스를 누르고 재시작 없이 설치하기를 클릭합니다. (플러그인 설치 실패시 지금 다운로드하고 재시작 후 설치하기로 설치해보시기 바랍니다.)

2. Global Tool Configuration

젠킨스 전체에서 사용할 도구를 설정하는 페이지입니다.
Jenkins 관리 - Global Tool Configuration을 클릭합니다.

다음과 같은 화면이 나옵니다.

JDK, Git은 대부분의 프로젝트에서 사용됩니다. 저는 추가로 Maven와 NodeJS를 설치하겠습니다.
Jenkins 도커 컨테이너에는 Git과 JDK는 기본적으로 설치되어 있습니다.
Kinematic에 Settings - General로 가서 JAVA_HOME을 확인합니다.

위에서 확인한 JAVA_HOME의 경로를 아래와 같이 써줍시다. Name은 변수로 사용될 이름입니다.
Git은 아래와 같이 설정해주시면 됩니다. Git은 따로 Name을 변경하지 않고 경로만 잡아주면 git 명령어를 사용할 수 있습니다.

Maven과 Nodejs는 젠킨스에서 자동으로 설치되도록 설정해줍니다. 그 후에 Save 버튼을 눌러주세요.

오류가 있으면 알려주세요. 감사합니다.

REFERENCE

Jenkins 초기 세팅 (Global Tool Configuration): https://blog.jiniworld.me/22

[Ubuntu 18.04] 우분투에 NodeJS 설치

SooJae — Sun, 1 Mar 2020 22:41:29 +0900

1. CURL 설치

$ sudo apt-get install curl

2. PPA를 추가

$ curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -

3. NodeJS 설치

$ sudo apt-get install -y nodejs

4. build-essential 설치

PPA를 통해서 NodeJS를 설치하면 NodeJS 뿐만 아니라 npm도 같이 설치됩니다. 하지만 npm install시 에러가 나는 것을 방지하여 build-essential을 설치해줍니다.

$ sudo apt-get install build-essential

REFERENCE

[Ubuntu 16.04] node.js 와 npm 설치: https://itstory.tk/entry/Ubuntu-1604-nodejs-와-npm-설치