# i18n: 다국어 처리와 글로벌 서비스의 필수 요소 파악하기

---

## Table of Contents

- [i18n이란 무엇인가](#i18n이란-무엇인가)
  - [유니코드(범용 코드 기반)](#유니코드범용-코드-기반)
  - [읽기 방식에 따른 css 지원](#읽기-방식에-따른-css-지원)
  - [로케일 대응](#로케일-대응)
    - [이름, 주소 등](#이름-주소-등)
    - [시간, 통화, 날짜 등](#시간-통화-날짜-등)
    - [문화적 상징 및 규제](#문화적-상징-및-규제)
  - [리소스의 외부화](#리소스의-외부화)
- [알아보면서..](#알아보면서)
- [Ref](#ref)

글로벌한 서비스를 하기 위해선 다국어 처리가 필수적이다. 글로벌 사용자가 쉽게 접근할 수 있는 웹을 만들기 위해 다국어 처리는 가장 첫 번째로 고려해야 할 항목이다. 더 나은 제품을 만들기 위해선 어떻게 다국어 처리를 하는것이 좋을지 알아보자.

## i18n이란 무엇인가

i18n 이란 Internationalization의 약자이며, 'i'와 'n' 사이에 18개의 글자가 있어 'i18n'으로 줄여 표현한다. 어떤 문화, 지역, 언어를 사용하는 사용자도 쉽게 서비스에 접근할 수 있도록 설계하고 개발하는 방식을 뜻한다.

국제화를 고려한 설계 방식은 서비스의 확장성에 상당한 영향을 준다. 언어 및 문화를 고려한 제품은 그렇지 않은 제품에서 확장하려 할 경우 개발 비용이 많이 드는 작업이다. 이런 이유로 이상적으로는 서비스 중간에 고려하는것이 아니라 서비스 초기에 기본으로 고려하는것이 가장 좋다.

국제화는 다음과 같은 항목을 반드시 고려해야 한다.

1. 유니코드 사용
2. 양방향 텍스트, 세로 텍스트 등 읽기 방식에 따른 css 지원
3. 날짜 및 시간 형식, 달력, 숫자 형식, 목록 형식, 이름 및 주소 형식 처리 같은 로케일 대응
4. 리소스의 외부화

간단하게 해당 내용을 살펴보려 한다.

### 유니코드(범용 코드 기반)

i18n의 기본은 서비스가 전 세계의 모든 문자 체계의 텍스트를 지원하는지 확인하는 것이다.
유니코드는 컴퓨터에서 사용되는 대부분의 언어, 기호, 고대 문자 등을 인코딩하고 나타내기 위한 표준이다. 최대 약 110만개의 문자를 인코딩 할 수 있어 단일 표준으로 전 세계 모든 언어와 스크립트를 지원하며 대부분의 웹 및 운영체제에서 기본적으로 제공하는 표준이다. 인코딩 자체를 뜻하는게 아니며, 어떻게 기호가 숫자로 변환 되는지를 정의하지 않는다. **그저 문자와 숫자간의 매핑을 정의하는 명세서일 뿐이다.**

### 읽기 방식에 따른 css 지원

세계에서 가장 많이 사용되는 문자 체계는 라틴어 문자 계열이고, 그 다음이 바로 아랍어이다. 대부분의 언어들은 주로 왼쪽에서 오른쪽으로 읽는 방식이지만 아랍어의 경우 오른쪽에서 왼쪽으로 읽는다.

이는 UI 레이아웃에도 영향을 미친다. 따라서 css 작성시 명시적 방향 값인 `left`, `right` 대신 논리적 방향 값인 `start`, `end`를 사용하는 것이 권장된다. 이렇게 하면 페이지 방향을 변경 하더라도 코드를 건드릴 필요가 없다.

### 로케일 대응

#### 이름, 주소 등

이름과 주소에 대한 정보를 저장하거나 UI로 표현할 때, 나라별로 다르게 표현하거나 저장해야 할 수 있다. 때문에 해당 데이터들을 어떻게 처리해야 하는지에 대한 고민이 필요하다.

나라마다 성을 주로 사용하는 나라와 이름을 주로 사용하는 나라들이 있으며 한글자의 이름을 사용하거나 매우 긴 이름을 사용하는 경우도 있다.

혹은 주소체계가 달라서 다른 방식으로 주소를 조회하고 저장해야 할 수 있다. 한국은 지번 주소 체계와 도로명 주소를 사용하지만, 일본은 주로 우편번호를 통해 주소를 조회하는게 일반적이다.

이와 같은 데이터들은 UI부터 저장 방식을 고려해 확장성을 갖도록 설계하면 지원하지 않던 국가에 쉽게 확장할 수 있다.

#### 시간, 통화, 날짜 등

시간, 통화, 날짜 등의 데이터는 하나의 표준된 방식으로 저장하는 데이터 이지만 로컬 사용자에게 현지 시간과 통화, 날짜에 맞춰서 표현할 수 있는 데이터들이다.

날짜 표기 방식으로 예로 들면 표기 순서와 구분 기호에서 주로 차이가 난다.
미국의 경우 월/일/년 순서 + 슬래시(/)를 이용하여 날짜를 표시하며, 유럽에선 일/월/년 순서 + 슬래시(/) or 점(.)을 혼동해서 쓴다. ISO 표준은 연/월/일 + 대시(-) 조합이지만 서비스하는 나라마다 유저가 느끼는 친숙함에 맞춰서 표시하는것이 좋다.

#### 문화적 상징 및 규제

사용자 경험에 혼란을 줄이기 위해서 문화적으로 다른 의미로 해석될 수 있는 상징이나 아이콘등을 파악하고 제공하는것이 중요하다.

서양권에선 `완료` 와 같은 긍정적인 의미로 사용하는 체크표시(✓)의 경우 일본의 경우 `선택`을 뜻할 때 사용하기도 하며, 다른 일부 국가의 경우 부정확함을 뜻할 수 있기 대문에 서비스를 제공하는 나라의 문화적인 차이에 맞게 변경해서 제공해야한다.

또한 나라별 규제에 대응할 필요도 있다. 미국의 경우 CCPA(California Consumer Privacy Act) 쿠키 정책을 따르고 있으며 유럽의 경우 GDPR(General Data Protection Regulation) 쿠키 정책을 따르고 있다.

### 리소스의 외부화

리소스를 외부화하지 않으면 서비스가 개발자에게 지나치게 의존적인 서비스가 되어버린다.
예를 들어, 번역된 파일이 소스코드 내부에 있다면 텍스트 하나를 수정하기 위해선 개발자가 내부 파일을 수정해서 다시 배포를 해야하는 플로우를 가지게 된다. 만약 잘못 수정할 경우 또 다시 배포 해야하는 경우가 생긴다. 더 나은 업무 효율을 위해서는 리소스를 최대한 외부화 해서 다국어 처리하는것이 중요하다.

## 알아보면서..

다국어 처리는 단순한 번역 이상의 과정으로, 각 지역의 사용자 경험을 고려해 서비스의 확장성을 높이는 필수 요소임을 다시 느꼈다. 주로 동양권 다국어 작업을 해 오면서 익숙했던 방식에서 벗어나, 이번 기회에 CSS의 읽기 방향 지원 등 다양한 요소의 중요성을 새롭게 인식하게 되었다.

## Ref

- https://www.w3.org/International/i18n-drafts/getting-started/index.html
- https://r12a.github.io/scripts/tutorial/part2
- https://www.unicode.org/standard/standard.html


다국어 처리와 글로벌 서비스의 필수 요소 파악하기

i18n: 다국어 처리와 글로벌 서비스의 필수 요소 파악하기

# github action reusable workflows 설정하기

---

## Table of Contents

- [기존 문제점](#기존-문제점)
- [설정 방법](#설정-방법)
- [Reusable workflow](#reusable-workflow)
- [Caller workflow](#caller-workflow)
- [주의해야할 점](#주의해야할-점)
- [ref](#ref)

### 기존 문제점

> 이 글은 github action에 대한 지식을 전부 설명하지 않습니다.

github action 으로 작성된 파이프라인을 보던 중 workflow 가 공통된 작업이 많았다. cloud에 업로드하는 경로, environment 만 다를 뿐 나머지 로직은 동일해서 해당 로직을 재사용 하는 방법을 알아봤다.

## 설정 방법

---

workflow 를 재사용하기 위해선 `reusable workflow` 와 `caller workflow` 를 구분해서 설정해야한다. `reusable workflow`는 단어 그대로 재사용이 가능한 workflow 인데, 공통된 로직을 해당 워크플로우에 작성하고 caller 에서는 가져다 쓰는 구조이다.

#### Reusable workflow

`.github/workflows` 디렉토리 내에서만 지원하고 하위 디렉토리나 다른 디렉토리에선 지원하지 않으며 `on`에 필수적으로 `workflow_call` 을 명시적으로 선언해야 `reusable workflow` 로서 사용할 수 있다.

```yml
on:
  workflow_call:
```

만약 나처럼 업로드 하기 위한 경로나, 환경에만 차이가 있다면 해당 값만 props 처럼 받아서 사용하고 싶을 텐데 이런 설정은 `inputs` 이나 `secrets` 키워드를 이용해서 지원한다.

```yml
# .github/workflow/reusable-workflow.yml

name: Reusable workflow

on:
  workflow_call:
    inputs:
      # 여기에 caller workflow 에 따라 달라지게 될 inputs을 입력한다.
      env:
        required: true
        type: string
        description: 'github action 실행 환경'
    secrets:


jobs:
  build:
	name: Build Service
	runs-on: ubuntu-latest
	steps:
	  # inputs이나 secrets의 값들은 다음과 같이 참조하여 호출한다.
	  - run: cp ${{ inputs.env }} .env
	# 생략..
```

#### Caller workflow

reusable workflow를 호출하는 workflow이다. 해당 workflow 내에서 `reusable workflow` 를 `uses` 키워드를 통해 호출한다.

```yml
# .github/workflow/dev-deploy.yml

name: Dev Deploy

on:
  push:
    branches: dev

jobs:
  deply:
    uses: ./.github/workflows/reusable-workflow.yml
    # reusable workflows의 inputs 내에 필요한 값은 with 키워드를 통해 전달한다.
    with:
      env: dev
    # secrets은 다음과 같이 상속해서 참조할 수도 있다.
    secrets: inherit
```

해당 파일을 보면 `reusable workflow` 가 같은 레포에 선언되어 있는걸 알수 있다. 위와 같이 설정할 경우 caller 와 reusable workflow는 동일한 커밋에서 호출된다.

만약 `reusable workflow` 가 다른 레포에 있다면 다음과 같이 호출한다.

```yml
# owner_name/repo_name_a/.github/workflow/dev-deploy.yml

name: Dev Deploy

on:
  push:
    branches: dev

jobs:
  deply:
    uses: owner_name/repo_name_b/.github/workflows/reusable-workflow.yml@main
    with:
      env: dev
    secrets: inherit
```

해당 파일을 보면 다른 워크플로에서 호출되고 있음을 알 수 있으며, 마지막에 @main 옵션을 통해 main 브렌치에 있는 workflow를 호출한다.

마지막 옵션은 ref 옵션으로 커밋 SHA, 릴리즈 태그, 브렌치 이름을 옵션에 포함시킬 수 있다. 만약 릴리즈 태그와 브렌치 이름이 같을 경우 릴리즈 태그를 더 우선시 해서 릴리즈 태그 옵션으로 호출한다.

### 주의해야할 점

1. 깃헙에서 가장 권장하는 옵션은 커밋 SHA 로 [보안상의 이유](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)로 해당 옵션을 가장 권장한다고 한다. 외부 workflow를 호출 할 때에는 해당 부분을 고려 해야겠다.

2. workflow는 최상위에서 호출한 caller 를 포함해서 최대 4개의 depth 까지 연결할 수 있다. reusable 내에 reusable 을 호출할 수 있지만 최대 4개의 depth 까지만 가능하기 때문에 만약 reusable workflow 를 설정한다면 해당 부분을 고려해서 구조를 설계해야 한다.

3. 하나의 workflows 에서는 최대 20개의 **단일** reusable workflow 를 호출할 수 있다. 만약 `최상위_workflow.yml` -> `called_workflow_1.yml` -> `called_workflow_2.yml` 일경우 2개로 계산 된다.

4. `secrets: inherit` 키워드를 사용하면 해당 workflow에만 secrets이 전달된다. 만약 secrets 을 하위 `reusable workflow` 에 제한적으로 전달되길 원하거나 모든 workflow 에 전달하길 원할경우 해당 부분을 고려해야한다.

## ref

---

- https://docs.github.com/en/actions/sharing-automations/reusing-workflows


github action reusable workflows 설정하기

# 연결 리스트(Linked List)

---

## 연결 리스트(Linked List)

데이터 구조의 한 종류로 여러개의 값을 저장하기 위한 구조 
데이터와 포인터가 한 쌍으로 구성된 것이 특징으로, 포인터가 다음 데이터의 메모리 위치를 가리킨다. 

![linked_list](linked_list.png) 

리스트에선 데이터가 메모리상의 떨어진 영역에 흩어져서 저장된다. 
흩어져 저장돼 있으므로 포인터를 처음부터 순서대로 따라가야만 원하는 데이터에 접근할 수 있다. 

데이터의 추가는 추가할 위치의 앞뒤 포인터를 변경만 하면 되므로 간단하다고 볼 수 있다. 

### 시간복잡도

| | Linked List |
| :------------------------------: | :---------: |
| **Access** | O(n) |
| **Insert/Remove from beginning** | O(1) |
| **Insert/Remove from end** | O(n) |
| **Insert/Remove from middle** | O(n) |

## ref

- [pngwing](https://www.pngwing.com/en/free-png-czavz)
- [McKenzie - Arrays, Linked Lists, and Big O Notation](https://medium.com/@mckenziefiege/arrays-linked-lists-and-big-o-notation-486727b6259b)
- [알고리즘 도감](https://apps.apple.com/kr/app/%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%EB%8F%84%EA%B0%90/id1047532631)

자료구조 - 연결 리스트(Linked List)