[K8s 공부 (3)](/2021/06/study-k8s-3)에서 이어집니다.

## Namespace

- 리소스를 네임스페이스 안에 모아 둘 수 있다. 따라서 클러스트 하나에서 여러 개의 네임스페이스를 둘 수 있다. - 클러스트 내부의 가상의 클러스터로 볼 수 있다.
- 클러스터를 생성하면 기본적으로 네임스페이스가 4개 생성되어 있다.

```bash
» kubectl get namespace
NAME              STATUS   AGE
default           Active   8d
kube-node-lease   Active   8d
kube-public       Active   8d
kube-system       Active   8d
```

- `kube-system`: 이 namespace는 우리가 건들 필요가 없음. 시스템 프로세스, master, kubectl 을 관리
- `kube-public`: config map 과 같이 public하게 (인증이 없어도) 접근할 수 있는 데이터를 관리

```bash
» kubectl cluster-info
Kubernetes control plane is running at https://192.168.64.3:8443
KubeDNS is running at https://192.168.64.3:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
```

- `kube-node-lease`: nodes의 하트비트. 각 노드의 현재 가용성을 관리.
- `default`: 여기서 우리가 만드는 리소스가 생성됨.

```bash
» kubectl create namespace my-namespace
namespace/my-namespace created
» kubectl get namespace
NAME              STATUS   AGE
default           Active   8d
kube-node-lease   Active   8d
kube-public       Active   8d
kube-system       Active   8d
my-namespace      Active   11s
```

이렇게 명령어로 생성하는 것 외에, namespace 설정 파일로도 만들 수 있음. (이게 더 낫다)

### 왜 네임스페이스를 만들어야 하나?

공식 문서에 따르면, 10명이하의 사용자가 있는 작은 프로젝트에서는 네임스페이스를 사용하지 말라고 한다. 뭐 그럼에도 네임스페이스별로 관리해서 개발하는 것이 여러가지 이점이 있다.

만약 클러스터에 하나의 네임스페이스만 있다고 가정해보자. 온갖 리소스들이 디폴트 네임스페이스에 생성되고, 복잡한 deployments의 경우 여러가지 리소스들이 섞이게 될 것이다. 그렇게 되면 여러개의 컴포넌트가 섞이게 되면서 현재의 overview를 볼 수 없을 것이다.

따라서 리소스를 네임스페이스를 통해서 그룹화 할 수 있다. `Database` `Monitoring` `Elastic Stack` `nginx-ingress` 등으로 관리 할 수 있다.

또 두개의 팀이 있고, 하나의 디폴트 네임스페이스만 쓴다고 가정해보자. 두 팀이 같은 deployment 이름으로 다른 설정으로 배포한다면, 하나의 deployment를 덮어버리는 사태가 발생한다. 이러한 충돌을 방지하기 위해서는, 팀별로 네임스페이스를 별도로 관리하는 것이 좋다. 그리고 팀별로 분리하게 되면, 서로의 리소스를 침해하는 등의 문제도 발생하지 않을 것이다.

마지막으로, staging, deployment 등 배포 레벨을 여러개로 관리하는 경우를 생각해보자. nginx-ingress controller, elastic 등은 배포 환경에 상관없이 재활용할 수 있으므로 네임스페이스를 활용하는 것이 좋다.

- 컴포넌트를 구조화 할 수 있음
- 팀 사이의 충돌을 방지할 수 있음
- 다른 환경에서도 서비스를 재사용할 수 있음
- 네임스페이스 별로 접근과 리소스를 제한할 수 있음

### 네임스페이스의 특징

- 다른 네임스페이스에 있는 대부분의 리소스에 접근할 수 없다. (다른 네임스페이스에 있는 configmap, secret을 참조하는 등을 할 수 없다.) 그러나, 서비스의 경우에는 가능하다.
- 일부 컴포넌트는 네임스페이스 내부에서 생성할 수 없다. (글로벌로 생성해야하는 것들) 이러한 것들에는 volume, node 가 있다.

`네임스페이스 내부에 생성할 수 없는 것들`

```bash
» kubectl api-resources --namespaced=false
NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
componentstatuses                 cs           v1                                     false        ComponentStatus
namespaces                        ns           v1                                     false        Namespace
nodes                             no           v1                                     false        Node
persistentvolumes                 pv           v1                                     false        PersistentVolume
mutatingwebhookconfigurations                  admissionregistration.k8s.io/v1        false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io/v1        false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io/v1                false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io/v1              false        APIService
tokenreviews                                   authentication.k8s.io/v1               false        TokenReview
selfsubjectaccessreviews                       authorization.k8s.io/v1                false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io/v1                false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io/v1                false        SubjectAccessReview
certificatesigningrequests        csr          certificates.k8s.io/v1                 false        CertificateSigningRequest
flowschemas                                    flowcontrol.apiserver.k8s.io/v1beta1   false        FlowSchema
prioritylevelconfigurations                    flowcontrol.apiserver.k8s.io/v1beta1   false        PriorityLevelConfiguration
ingressclasses                                 networking.k8s.io/v1                   false        IngressClass
runtimeclasses                                 node.k8s.io/v1                         false        RuntimeClass
podsecuritypolicies               psp          policy/v1beta1                         false        PodSecurityPolicy
clusterrolebindings                            rbac.authorization.k8s.io/v1           false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io/v1           false        ClusterRole
priorityclasses                   pc           scheduling.k8s.io/v1                   false        PriorityClass
csidrivers                                     storage.k8s.io/v1                      false        CSIDriver
csinodes                                       storage.k8s.io/v1                      false        CSINode
storageclasses                    sc           storage.k8s.io/v1                      false        StorageClass
volumeattachments                              storage.k8s.io/v1                      false        VolumeAttachment
```

`네임스페이스 내부에 생성할 수 있는 것들`

```bash
» kubectl api-resources --namespaced=true
NAME                        SHORTNAMES   APIVERSION                     NAMESPACED   KIND
bindings                                 v1                             true         Binding
configmaps                  cm           v1                             true         ConfigMap
endpoints                   ep           v1                             true         Endpoints
events                      ev           v1                             true         Event
limitranges                 limits       v1                             true         LimitRange
persistentvolumeclaims      pvc          v1                             true         PersistentVolumeClaim
pods                        po           v1                             true         Pod
podtemplates                             v1                             true         PodTemplate
replicationcontrollers      rc           v1                             true         ReplicationController
resourcequotas              quota        v1                             true         ResourceQuota
secrets                                  v1                             true         Secret
serviceaccounts             sa           v1                             true         ServiceAccount
services                    svc          v1                             true         Service
controllerrevisions                      apps/v1                        true         ControllerRevision
daemonsets                  ds           apps/v1                        true         DaemonSet
deployments                 deploy       apps/v1                        true         Deployment
replicasets                 rs           apps/v1                        true         ReplicaSet
statefulsets                sts          apps/v1                        true         StatefulSet
localsubjectaccessreviews                authorization.k8s.io/v1        true         LocalSubjectAccessReview
horizontalpodautoscalers    hpa          autoscaling/v1                 true         HorizontalPodAutoscaler
cronjobs                    cj           batch/v1beta1                  true         CronJob
jobs                                     batch/v1                       true         Job
leases                                   coordination.k8s.io/v1         true         Lease
endpointslices                           discovery.k8s.io/v1beta1       true         EndpointSlice
events                      ev           events.k8s.io/v1               true         Event
ingresses                   ing          extensions/v1beta1             true         Ingress
ingresses                   ing          networking.k8s.io/v1           true         Ingress
networkpolicies             netpol       networking.k8s.io/v1           true         NetworkPolicy
poddisruptionbudgets        pdb          policy/v1beta1                 true         PodDisruptionBudget
rolebindings                             rbac.authorization.k8s.io/v1   true         RoleBinding
roles                                    rbac.authorization.k8s.io/v1   true         Role
```

### 네임스페이스 내부에 컴포넌트를 만드는 법

이전에 설정파일들로 만들어보았지만, 별도로 네임스페이스를 지정한 적이 없다. 이 경우에는 기본값으로 default 네임스페이스에 생성되어버린다.

```bash
» kubectl apply -f mongo-configmap.yaml --namespace=my-namespace
configmap/mongodb-configmap created
```

또는, `metadata.namespace`에 기재하는 방법 있다.

```yaml
» cat mongo-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: mongodb-configmap
  namespace: my-namespace
data:
  database_url: mongodb-service # 서비스 메타데이터 네임을 그대로 가져온다.%
```

이를 가져오기 위해서는, `-n`을 활용하면 된다.

```bash
» kubectl get configmap -n my-namespace
NAME                DATA   AGE
kube-root-ca.crt    1      19m
mongodb-configmap   1      97s
```

귀찮으니 설정파일 내부에 기재해두자. 문서화에도 도움이되고, 까먹지도 않고 자동으로 편리하게 적용할 수 있다.

### 디폴트 네임스페이스 변경하기

앞서 살펴보았던 것처럼, 기본값은 `default`다. 이 기본값을 바꿔주는 것이 [kubens](https://github.com/ahmetb/kubectx)다.

```bash
» brew install kubectx
==> Downloading https://ghcr.io/v2/homebrew/core/kubectx/manifests/0.9.3
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/kubectx/blobs/sha256:30c0b39d23e542bc936994a8c1a47705f0205e42e59cb043adaed21
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:30c0b39d23e542bc936994a8c1a47705f0205e42
######################################################################## 100.0%
==> Pouring kubectx--0.9.3.all.bottle.tar.gz
==> Caveats
zsh completions have been installed to:
  /usr/local/share/zsh/site-functions
==> Summary
🍺  /usr/local/Cellar/kubectx/0.9.3: 12 files, 37.8KB
```

```bash
» kubens
default
kube-node-lease
kube-public
kube-system
my-namespace
```

활성화 되어있는 네임스페이스가 색이 칠해져서 보일 것이다.

![kubectx](./images/kubectx.png)

```bash
» kubens my-namespace
Context "minikube" modified.
Active namespace is "my-namespace".
```


무지성에서 시작하는 K8s 공부해보기 시리즈(4) namespace의 정의를 정확히 알아야지

K8s 공부 (4)

ECMAScript (ES2015, ES) 모듈이란 자바스크립트에서 각 코드를 하나의 청크로 구성할 수 있게 해주는 방법을 제공한다. 먼저, 자바스크립트의 값을 외부로 노출을 시킨다.

```javascript
export const sum = (a, b) => a + b
```

그리고 이 값(함수)을 필요로 하는 곳에서 아래와 같이 사용한다.

```javascript
import { sum } from './test'

sum(1, 2)
```

대부분의 경우에는 위의 예제 처럼 상단에 필요한 모듈들을 static하게 import하는 것이 일반적이지만, 떄때로 이를 필요에 따라 조건부로 불러올 수도 있다. [dynamic import](https://caniuse.com/?search=dynamic%20import)라고 불리며, 이는 ES2020(ES11)에 포함된 기능이다.

```javascript
const sum = await import('./test')
```

`await import`는 프로미스를 리턴하고 이 때부터 동적으로 모듈을 불러오기 시작한다. 그리고 모듈을 성공적으로 불러오면, promise는 모듈을 resolve하거나 실패할 경우 reject 하게 된다.

그리고 `import`내의 구문은 모듈의 위치를 가리키는 string이면 되기 때문에, 함수 외부에서 인수로 받거나 계산된 string을 받는 것들도 가능하다.

```javascript
export const sum = (a, b) => a + b
```

```javascript
async function calc(a, b) {
  const { sum } = await import('./test')
  sum(a, b)
}

calc(1, 2) // 3
```

이제 default 의 경우를 살펴보자.

```javascript
const sum = (a, b) = > a + b
export default sum
```

이 경우에는 `default` 키워드를 사용하면 된다.

```javascript
async function calc() {
  const { default: sum } = await import('./test')
  sum(1, 2)
}
```

한가지 유의 할 것은,

```javascript
const sum = await import('./test')
```

이렇게는 안된다는 것이다.

default와 그 외의 것들이 섞여있는 경우라면 아래와 같이 처리하면 된다.

```javascript
const sum = (a, b) => a + b
export const sum1 = (a, b) => a + b
export const sum2 = (a, b) => a + b

export default sum
```

```javascript
const { default: sum, sum1, sum2 } = await import('./test')
```


ESModule을 동적으로 import 하기

소프트웨어 개발 원칙 중의 하나인 [DRY, don't repeat yourself](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) 는 너무나도 유명해서 별로 설명할게 없긴한다. type을 잘 사용하면, 조금 더 효과적으로 소프트웨러를 설계할 수 있다.

## 타입 확장하기

```typescript
interface Person {
  name: string
  age: number
}

// don't
interface PersonWithBirthday {
  name: string
  age: number
  birth: Date
}

// do
interface PersonWithBirth extends {
  birth: Date
}
```

`type`을 사용한다면, `&`으로도 가능하다.

```typescript
type PersonWithBirth = Person & { birth: Date }
```

## 타입 좁히기

이전 예제와 반대의 예제를 들어보자. 이번엔 큰 타입에서 작은 타입의 subset이 필요한 경우다.

```typescript
interface User {
  userId: string
  name: string
  age: number
  email: string
}

interface SelectedUser {
  userId: string
  email: string
}
```

이 역시 중복이 발생하므로, 좋지 못한 방법이다.

```typescript
type SelectedUser = {
  userId: User['userId']
  email: User['email']
}

interface SelectedUser {
  userId: User['userId']
  email: User['email']
}
```

오오 놀랍다. 타입의 값을 마치 객체에서 값을 꺼내온 것마냥 썼다. 이렇게 해두면, `User`의 `userId`가 number로 바뀌게되도, 자동으로 그 타입도 따라가게 될 것이다.

하지만 이 역시도 번거로운 점이 있다. key조차도 나는 똑같이 할 건데, 굳이 키를 다시 선언할 필요가 있을까?

```typescript
type SelectedUser = {
  [k in 'userId' | 'email']: User[k]
}
```

![type-operations1](./images/type-operation1.png)

오옹 신기하다. 하지만 이미 우리는 이것보다 더 편한 방법을 알고 있다.

```typescript
type SelectedUser = Pick<User, 'userId' | 'email'>
```

[Pick](https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-keys) 을 쓰면 간단하게 해결할 수 있다.

## 공통타입 추출하기

```typescript
interface Save {
  action: 'save'
  body: string
  id: string
}

interface Load {
  action: 'load'
  body: string
  id: string
}

type Action = Save | Load
type ActionType = 'save' | 'load' // Repeat!
```

두 타입은 `action`의 값 외엔 모든게 똑같은데, 여기서 `action`을 또다른 타입으로 추려내기 위해서 `'save' | 'load'`를 썼다. 이것도 마찬가지로, 아래 처럼 바꿀 수 있다.

```typescript
type ActionType = Action['action'] // type ActionType = "save" | "load"
```

## 타입 옵셔널하게 사용하기

객체의 모든 키가 옵셔널 하다면 어떻게 해야할까? 일일히 모두 물음표를 달아야할까?

```typescript
interface Person {
  age?: number
  name?: string
  email?: string
  gender?: string
}
```

그렇지 않다. `Partial<Person>`을 사용하면, 안에 있는 모든 키를 옵셔널하게 바꿔준다. 이는 옵셔널한 값을 받는 상황 (api로 값을 업데이트 한다던지)에 매우 유용하게 쓸 수 있다.

```typescript
function update(options: Partial<Person>) {
  // .. 적당히 값을 받아서 처리한다.
}
```

## 값으로 부터 타입을 추출하기

기본적으로 개발 흐름은 타입을 선언하고 값을 쓰는 형태로 가지만, 반대인 경우가 있을 수 있다. 이 경우에는 아래와 같이 하면 된다.

```typescript
const INIT_VALUES = {
  width: 640,
  height: 480,
  price: 150_000,
  name: 'monitor',
}

type Options = typeof INIT_VALUES
// 위 타입은 아래와 같다.
// type Options = {
//     width: number;
//     height: number;
//     price: number;
//     name: string;
// }
```

한가지 조심해야 할 것은, `typeof`의 사용이다. 아래 두 코드는 엄연히 다르다.

```typescript
const t = typeof INIT_VALUES // "object"
type o = typeof options
// type Options = {
//     width: number;
//     height: number;
//     price: number;
//     name: string;
// }
```

값을 선언한 코드에 `typeof`를 때리면 자바스크립트 런타임의 [typeof](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Operators/typeof)를 실행하게 된다. 값을 가져오고 싶은건지, type을 가져오고 싶은건지 확실히 해야 한다. 조건문 같은 곳에 `typeof`를 둔다면 자바스크립트 런타임의 `typeof`를 실행한다는 것을 명심하자. `type`에 `typeof`를 쓰면, 타입스크립트만 알아듣는다.

이렇게 쓰긴했지만, 어디까지나, 타입을 먼저쓰고 값을 쓰는 경우가 훨씬 더 일반적이고 정확하다.

## 함수의 결과를 타이핑 하기

함수의 결과를 타이핑하고 싶다면, [ReturnType](https://www.typescriptlang.org/docs/handbook/utility-types.html#returntypetype)과 제네릭을 활용하면 된다.

```typescript
function getUserInfo(userId: string) {
  // ...

  return {
    userId,
    name: 'hello',
    age: (Math.random() * 100) / 100,
    email: 'random@email.com',
  }
}

type userInfo = ReturnType<typeof getUserInfo>
// 위와 같다.
// type userInfo = {
//     userId: string;
//     name: string;
//     age: number;
//     email: string;
// }
```

이러한 패턴은 라이브러리에서 함수의 리턴을 emit할 때 많이 쓴다. 주의할 점은, 제네릭에 `getUserInfo`가 아니고 `typeof gerUserInfo`가 들어갔다는 점이다. `ReturnType`는 타입을 제네릭으로 받아야 한다.

```typescript
type t = typeof getUserInfo

// 위와 같다.
// type t = (userId: string) => {
//     userId: string;
//     name: string;
//     age: number;
//     email: string;
// }
```

이로써 함수만 바꾸더라도, 타입까지 자동으로 바뀌어서 [single source of truth](https://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%A7%84%EC%8B%A4_%EA%B3%B5%EA%B8%89%EC%9B%90)를 지킬 수 있었다.

## 제네릭으로 파라미터 제한하기

제네릭 타입은 함수를 위한 타입과 같다. 그리고 함수가 DRY 원칙을 지키기 위한 수단인 것을 감안했을때, 제네릭도 마찬가지로 타입의 DRY를 위한 필수 요소라고 볼 수 있다.

```typescript
interface Name {
  first: string
  last: string
}

type PairProgrammer<T extends Name> = [T, T]

const day1: PairProgrammer<Name> = [
  { last: 'KIM', first: 'YONGCHAN' },
  { last: 'LEE', first: 'JAEYONG' },
]

const day2: PairProgrammer<Name> = [
  { last: 'KIM' }, // Property 'first' is missing in type '{ last: string; }' but required in type 'Name'.
  { last: 'LEE' }, // Property 'first' is missing in type '{ last: string; }' but required in type 'Name'.
]
```

> 한가지 조금 개인적으로 아쉬운것은, 제네릭 파라미터를 생략할 수 없다는 점이다. `PairProgrammer<Name>` 대신 `PairProgrammer`를 쓸 수 없다는 점이다.

## Pick 구현해보기

이렇게 `extends` 키워드까지 활용한다면, `Pick`과 동일한 타입을 추출하는 나만의 `Pick`을 만들 수 있다.

```typescript
type MyPick<T, K extends keyof T> = {
  [k in K]: T[k]
}
```


interface를 더 좋아하지만 type이 더 간지남

타입스크립트의 타입과 제네릭 적극 활용하기

무지성에서 시작하는 K8s 공부해보기 시리즈(3)

K8s 공부 (3)

타입스크립트의 타입 체크는 가끔 내가 생각하는 것보다 광범위 해서 생각치도 못한 결과를 만들어 낼 때가 있다. 아래와 같은 코드가 있다고 가정해보자.

```typescript
interface Vector2D {
  x: number
  y: number
}

function calcLength(v: Vector2D) {
  return Math.sqrt(v.x * v.x + v.y * v.y)
}
```

그리고 새로운 interface를 만들고, 이를 함수의 값으로 넣었다.

```typescript
interface Vector2DWithName extends Vector2D {
  name: string
}

const a: Vector2DWithName = { name: 'hi', x: 5, y: 10 }
calcLength(a) // works fine

interface Vector2DName {
  name: string
  x: number
  y: number
}

const b: Vector2DName = { name: 'hello', x: 10, y: 10 }
calcLength(b) // works fine, too.
```

`Vector2DWithName`야 뭐, `extends`로 그 둘 사이에 관계가 어떻게 어떻게 보였다고 치더라도, `Vector2DName`과 `Vector2D` 둘 사이에는 별다른 관계가 선언되거나 한적이 없음에도 정상적으로 작동하는 것을 볼 수 있다.

타입스크립트의 타입시스템은 '구조적으로' 타입이 맞기만 한다면 이를 허용해준다. 여기서 등장한 용어가 바로 [structural typing](https://www.typescriptlang.org/docs/handbook/type-compatibility.html) 이다. (뭐 제대로된 번역을 본적이 없어서 그냥 구조적 타이핑이라고 하겠다.)

일반적으로 다른 언어, C#, Java 등에서는 허용하지 않는 방법이다. 그러나 이 때문에 예기치 못한 문제를 만들어 낼 수 있다.

```javascript
interface Vector3D {
    x: number
    y: number
    z: number
}

function normalize(v: Vector3D) {
    const length = calcLength(v) // z가 고려되지 않음
    return {
        x: v.x / length,
        y: v.y / length,
        z: v.z / length // z의 값이 이상하게 나옴
    }
}

normalize({x:3, y:4, z:5}) // 그러나 에러는 안남
```

일반적으로 함수를 작성할 때, 함수에서 들어오는 인수가 애초에 원하는 대로 의도한 인수만 가지고 있고, 그 외의 값은 안올 것이라고 기대하고, 그게 일반적이다. 그러나 타입스크립트의 타입 시스템에서는 그렇지 않다. 타입스크립트의 타입은 열려있기 때문이다. 이러한 함정(?) 때문에, 타입스크립트를 처음 접하게 되면 아래와 같은 실수를 많이 범하게 된다.

```typescript
function calcLengthV1(v: Vector3D) {
  let length = 0
  for (const axis of Object.keys(v)) {
    const coord = v[axis] // Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'Vector3D'.
    // No index signature with a parameter of type 'string' was found on type 'Vector3D'.(7053)
    length += Math.abs(coord)
  }
  return length
}
```

내가 선언한 `v`의 키 값들은 x,y,z로 잘되어 있고, 이는 모두 string이라 잘 들어가야 한다. 그리고 값들도 number라서 length에 잘 더할 수 있어야 한다. 그런데 왜 에러가 나지?

> [https://yceffort.kr/2021/05/do-not-use-suppressImplicitAnyIndexErrors](/2021/05/do-not-use-suppressImplicitAnyIndexErrors) 에서 한번 다룬적이 있다.

그러나, 위에서 이야기 한 것처럼 타입스크립트의 타입이 열려 있다는 것을 생각해본다면 타당한 에러다.

```typescript
const v = { x: 1, y: 2, z: 3, name: 'hi, h i~' }
calcLengthV1(v) // name의 값이 NaN이라서 결과가 NaN으로 뜰 수 있다.
```

따라서, 위의 코드는 타입스크립트 상에서 이렇게 바뀌어야 정확하게 값을 낼 수 있다.

```typescript
function calcLengthV2(v: Vector3D) {
  return Math.abs(v.x) + Math.abs(v.y) + Math.abs(v.z)
}
```

이런 구조적 타이핑은 클래스에서도 재밌는 현상(?) 을 만들어 낸다.

```typescript
class MadMonster {
  tan: string
  constructor(tan: string) {
    this.tan = tan
  }
}

const hi1 = new MadMonster('hello') // 원래 내가 의도한 코드
const hi2: MadMonster = { tan: 'hello' } // ?!?!
```

왜 `hi2`가 `MadMonster`로 할당이 가능한걸까? `MadMonster`에는 `tan`이라는 string 속성이 있다. 추가로, `constructor` (`Object.prototype`에서 온) 를 가지고 있는데, 이는 `tan`이라는 인수를 받기 때문에 구조적으로 일치한다. 그렇다. 구조적 타이핑의 결과 인 것이다.

구조적 타이핑이 꼭 이렇게 거지같기만(?) 한 것은 아니다. 테스트 할 때는 유용하게 사용할 수 있다.

```typescript
interface Employee {
  name: string
  id: number
}

function getEmployee(db: DB): Employee[] {
  const rows = db.runQuery('SELECT name, id from EMPLOYEES')
  return rows.map((row) => ({ name: row[0], id: row[1] }))
}
```

DB를 테스트하는 코드를 만든다고 가정했을 때, 구조적 타이핑을 활용하면 아래와 같은 방법으로 테스트 할 수 있다.

```typescript
interface Employee {
  name: string
  id: number
}

interface DB {
  runQuery: (sql: string) => any[]
}

function getEmployee(db: DB): Employee[] {
  const rows = db.runQuery('SELECT name, id from EMPLOYEES')
  return rows.map((row) => ({ name: row[0], id: row[1] }))
}
```

`getEmployee`에는 `runQuery`가 존재하는 DB 어댑터를 넣어주면 된다. 위 코드는 프로덕션/테스트를 가지리 않고 잘 동작할 것이다. 구조적 타이핑을 활용하여, 굳이 실제 DB를 구현하지 않아도 테스트 코드를 짤 수 있게 되었다. 굳이 DB를 mocking할 필요가 없다. 추상화한 `DB` 덕분에, 우리의 로직을 테스트와 프로덕션 상에서 모두 안전하게 작동시킬 수 있다.

## 결론

- 자바스크립트는 덕타이핑 특성을 가지고 있고, 타입스크립트는 구조적 타이핑을 활용하여 이 모델을 구현해 냈다고 볼 수 있다.
- 인터페이스에 할당 되는 값은, 형식적으로 선언되어 있는 속성 이상의 속성을 추가로 가질 수 있다. 즉 열려 있다.
- 클래스 또한 구조적 타이핑을 따르고 있으므로 조심해야 한다.
- 구조적 타이핑은 유닛 테스트 시에 유용하다.


얀센 맞고 정신 나가서 하루를 순삭당했습니다

Latest

K8s 공부 (4)

ESModule을 동적으로 import 하기

타입스크립트의 타입과 제네릭 적극 활용하기

K8s 공부 (3)

타입스크립트의 구조 타이핑