이렇게 글을 적게 되는게 얼마 만인지 놀라울 따름이다. 매번 시간이 없어서, 여유가 없어서라는 핑계를 대가며 글을 적는 것은 잠시 미루어두곤 했다. 지금부터 5년전이었나? 군대 전역하고 1년 정도 후이니, 아마 그때쯤이었을 것이다. 여름 방학에 여느 건축학과 학생들은 열심히 유럽 건축 여행기를 찾아보며 여행 루트를 짜고 있을 때, 나는 침대에 엎드려 노트북에 열심히 부자가 되는 법을 찾아보고 있던 때였다. 누구나 그렇지 않을까? 쉽게 돈을 버는 방법, 남들처럼 쿨(?)하게 사는 방법에 대해 관심이 많았던 철부지 대학생이었다. 당시 학교 커뮤니티 페이지에 올라온 글을 보고, 처음으로 취직이 아닌 창업이라는 말도 안되는 길을 걷게 되었다. 그만큼 나는 충동적인 사람이었다. 하고 싶은 건 해야만 했고, 해보지 못하면 직성이 풀리지 않는 그런 사람.

우리는 이렇게 작은 아이디어로 이렇게 상도 많이 받았고, 이만큼 대단한 꿈을 꾸고 있습니다. 우리와 함께 해줄 사람을 찾습니다.

엄청 간단한 설명과 조금은 조잡하게 끼워 맞춰진 카드 이미지에는 그런 말들이 적혀 있었다. 보고 있노라면 나도 모르게 이미지를 줄이고, 폰트크기를 바꾸고 조금 촌스러운 폰트는 로보토 같은 깔끔한 폰트로 변경하고.. 원색으로 꾸며진 이미지는 파스텔톤의 정갈한 이미지로 변경하면 좋겠다는 생각을 하면서 나도 모르게 사진갤러리에 저장했었다. 그 이후로는 수업이 귀에 들어오지 않아, 수업만 들어가면 다른 생각만 하며 교수님 이야기는 흘려 들었던 것 같다.(사실 그걸 떠나서 애당초 건축으로부터는 관심이 떠난 후여서 그랬는지도 모른다.) 그 이미지를 하루종일 보면서 밤낮없이 사흘을 해당 아이템을 요목조목 뜯어보며 생각한 끝에 내린 결론은.. 사실 그렇게 긍정적인 판단은 아니었다. 청년 5명에, 하드웨어 프로덕트를 만들어 홈 트레이닝 시장에 들어가겠다. 디자인 아이디어 상품이라 킥 기능만 살리면 정말 작은 시장성은 있어보였지만, 사실 하드웨어 시장바닥에서 살아남기라는 것 자체가 말도 안된다고 생각했다. 첨단 기술도 없고, 이미 가진 네이밍 밸류가 있는 것도 아니며, 지금 있는 시장의 파이를 쪼개기에도 영향력이 한참 부족해보였다.당시 아이템의 대부분 아이디어는 2015년 6월에 한국 최초 출시한 스마트 워치에서 대부분 대체가 가능했기 때문이었다. 근데도 하겠다고 뛰어든 건 뭐랄까.. 미래에 대한 불안감? 현재 아무것도 하지 않는 본인에 대한 실망을 채우려는 얄팍한 시도였는지도 모른다.

나 창업하려구!

당시에 학교에서 마주치는 사람들한테 게임 매크로마냥 내뱉던 대답이었다. 엊그제까지 꿈인 적도 없었으면서 정말 얄팍하게 내 현재에 대한 변명거리 쯤으로 삼으려고 그랬었는지도 모르겠다. 남들은 건축 디자인을 공부하겠다고, 연 몇천만원이 넘는 유학비를 감당하며 졸업후에 유럽 전문 예술학교를 또 다니겠다고 하는데, 나는 그렇게 할 자신이 없었다. 아니 그렇게 하고싶을 만큼 열정이 충분하지 않았다. 학교에 재학중이던 때에 르 꼬르뷔제부터 스티븐 홀, 안도 타다오 같은 유명 거장 건축가를 이야기하며, Fancy한 예술가적 분위기를 좋아하는 학생들이 많았던 것 같은데 도저히 이해도 안될 뿐더러 일단 재미가 없었다. 내가 거장도 아닌데, 거장처럼 행동할 것도 없었고 거장이 되고 싶은 생각도 없었고, 이래저래 분위기가 맞지 않았다.

개방감, 위요감, 공간감, 공간과의 관계성

건축을 하다보면 저런 단어들을 자주 마주하게 되는데, 사실 와닿지도 않았다. 물론 좋은 공간이라는 것은 분명히 있다. 여기저기 돌아다니다보면 나도 모르게 편안함을 느끼고 계속 있고 싶어지는 곳들이 분명 있기 때문이다. 그렇기 때문에 유현준 씨같은 사람들이 미디어에 나와, 우리나라의 공간들은 문제가 많다며 지적하는 것이 아닐까 싶긴하다. 그럼에도 불구하고 휴학 포함 7년을 건축분야를 굴러본 내게 남은 것은 글쎄.. 수치를 잘 가늠하는 정도의 감각, 그리고 일반인보다는 조금 나은 스케치 능력. 발표를 자주하다보니 발표 능력 정도가 되시겠다. 어찌됐던 맞지 않는 분야는 털어버려야 직성이 풀리기에 3학년이 되던 5년차에 자퇴를 생각했지만 그것도 쉽진 않았다. 그렇다고 내가 지금 당장 뭘 어떻게 하려는 대안도 없이 뛰쳐나가는 건 답이 없었으니까. 그래서 나름대로 목적있(어보이)는 방황을 시작했다. 남들이 나한테 이렇게 물을 때 이렇게 답했다.

그래서 넌 졸업하고 뭘하려고? 나 창업하려구!

기회는 언제나 찾아온다.

긴 인생도 아니고, 겨우 1회 차에 30년 차쯤 되니까 인생에도 나름대로 운명이나 기회라는 것들이 있다는 것을 믿게 되었다. 대부분의 RPG 게임에서는 만렙이 99가 디폴트 값이다. 사람이 보통 최대로 사는 나이가 100살 정도라고 하니, 인생을 압축해서 즐길 수 있게끔 그렇게 레벨링 시스템이 짜여진 것이 아닌가 싶다. RPG 게임도 레벨 30정도에 들어서면서부터는 어느정도 시스템에 익숙해지게 된다. 접속하자마자 내가 사냥해야하는 곳이 맵의 어느지점쯤인지 알게 되고, 한번 사냥해야할 때 어떤 스킬셋이 유리한지 알게되고 어떤 방향으로 키워나가야 할지 조금은 눈에 보이기 시작한다. 물론 고수들의 공략을 확인하지 않으면, 내 선택이 최선인지 알 수는 없지만 나름대로 이런 저런 선택을 하면서 조금씩 강해지기 시작한다. 인생도 마찬가지인 것 같다. 30살쯤 되고 나니, 내가 뭘 해야할지 정도는 감이 잡힌다. 내가 더 공부해야할 것들이 무엇이며 어떤 것들을 공부해야 그 쪽으로 나아갈지 어두운 밤처럼 느껴지고 깜깜해도 무드등이 켜진 것 정도의 밝기의 앞길은 읽어볼 수 있다.

당시에 다양한 기회들이 나를 덮쳐왔다.

나는 연애를 쉬어본 적이 없는데(순전히 내 의견이지만, 연애만큼 새로운 것을 시작하게끔 계기를 만들어주는 것은 없다고 생각한다. 사랑의 힘은 강력하다.), 당시 여자친구는 처음으로 다른 분야의 사람이었다. 건축학과 특성상 작업 반경을 벗어나는 관계를 만드는 것 자체가 굉장히 어려웠는데 당시에 데이팅 앱이 유행하기 시작한 시초였는데, 이를 통해서 당시 여자친구를 만나게 되었다. 여자친구는 컴퓨터 공학과 산업 공학을 복수전공하고 본인 분야에 대해서 열심히 공부하고 최선을 다하던 친구였다. 우연찮은 계기로 알고리즘 문제를 푸는 것을 보게되었고 나도 관심이 가게 되었다. 내가 건축 분야를 혐오했던 이유 중에 하나는 논리를 감성으로 풀어나간다는 점이었다. 내가 생각하는 논리는 충분한 증거와 원칙을 가지고 결과로의 정당성을 얻어내는 과정이라고 한다면, 건축의 논리라는 것은 그 증거와 원칙이 디자인의 느낌과 감각에 있었기 때문이다. 내가 마주하게 되었던 프로그래밍은 좀 달랐다. 조금은 수학과 비슷하면서도, 충분한 증거와 원칙이라는 것이 감각이 아닌 절대적인 것이었기 때문이다. 글로 표현하는 것이 서툴러 이상한 표현일 수도 있지만 당시 내 느낌은 그랬다.당시 여자친구가 풀어내는 알고리즘들을 보고, 신선한 충격을 받았다. 이런 걸 공부하는 분야가 있다고? 왜 이걸 이제야 알았을까? 거기에서 온 느낌은 말로 표현할 수 없을만큼 충격적이고 신선했다. 어쨌든 나는 그런 기회를 받아드리기로 했고, 이윽고 결정했다. 이게 뭔지는 모르겠지만, 재미있으니까 공부해야겠다.

학점도 내려놓은 인생

결국에는 겉으로는 창업을 외치며, 평소에는 프로그래밍을 공부하고, 학교에서는 엎드리는 이상한 사람이 되었다. 태어나서 단 한번도 책상에서 잠들어본 적 없는 내가.. 이렇게 되버리다니! 나름대로 웃기면서도 정말 즐거운 나날들이었던 것 같다. 아침 저녁으로 창업지원단에서 마련해준 사무실로 출퇴근하면서, 시간이 나면 프로그래밍 책을 읽고, 나름대로 돈을 벌겠다고 시간이 날 땐 과외를 하고, 막상 열심히 다녀야할 대학교에서는 피곤해져서 잠들어버리는.. 신기한 시간들이었다. 당연한 결과였겠지만, 이때부터는 학점을 B에만 맞추자고 생각했던 것 같다. 무슨 이유에서인지는 모르겠으나, 나는 당시에 건축 분야로는 절대 안가게 될거라고 스스로 생각했던 것 같다. 이제는 스스로 결정할 수 있다. 결정하겠다라는 생각을 처음으로 해본 것 같다. 이때부터 조금은 입체적으로 생각할 수 있는 사람이 되었다. 내가 결정하는 것들이 단순히 잘 살기 위함이 아니라, 한번 사는 인생 이것저것 다해보자는 결심을 처음으로 하게 되었다.

뭐 당연한 말이지만, 3학년 이후로 학점이야기..는 별로 하고 싶지 않다. 1,2학년 때는 나름대로 학점에 A도 많고 4점대도 받아본 나름대로 장학생이었던 것 같은데, 대학생이라는 평가잣대에서 3학년 이후의 모습은 사실 너무 막나가는게 아닌가 싶은 생각이 들 정도였다. 동기들한테 듣던 얘기로는 쟤 진짜 저러다가 어쩔려고 그러는지? 인생 너무 막산다라는 이야기도 들리기도 했으니 뭐.. 결론적으로 5년 쯤 뒤에 와서 돌아보니, 내 결정을 놀라워하는 사람도 많고 실제로 부럽다고 하는 사람들도 많으니 그렇게 틀리지는 않은 결정이었던 것 같다.

그래서 지금 삶은 어떤가

사실 이런 글을 몇 년전부터 써내려왔으면 좋았겠다라는 생각이 든다. 인생에 남는 것은 "사진"이라는 말도 있지만, 사실 글만큼 생각을 잘 표현하는 매체는 없다. 내가 1살 때부터 만들어온 역사들은 당시의 사진에는 충분히 나와있지만, 내가 했던 생각과 이야기들은 따로 적혀있는 것이 별로 없다. 일기장이 있으면 그 글들을 읽으며 되짚어 가보며 당시의 생각을 회고하기 쉬운데, 지금은 당시의 느낌들을 골똘히 생각해봐야 조금은 따라갈 수 있기 때문이다. 어찌됐던 지금은 충분히 만족하는 삶을 살고 있다. 제작년 말에 졸업을 하며 졸업작품 상도 수상하고 나름대로는 분야에서 큰 회사에도 가서 다녀봤지만, 지금 인생만큼 행복하지 않았다. 스물 다섯에 했던 고민들이 얼추 맞아떨어지는 중이라 스스로에게도 꽤 대견하기도 하고 나름 굉장하다고 생각하기도 한다.

학교를 졸업하던 시기와 맞물려 현실적인 이유로 졸업을 생각하게 되어서 창업팀에서도 나오게 되었고, 이 덕분에 널널해진 시간으로 졸업작품에 매진할 수 있었다. 원래 같으면 7일중 순수 작업시간이 12시간을 채 넘지 못했기 때문에 늘 작업물이 시원찮았었다. 마음에 들지 않았으나, 이미 분야에 대한 정은 다 떨어진 후라 크게 심적으로 힘들지는 않았다. 늘 그렇듯이 담담하게 받아들였던 것 같다. 결론적으로는 졸업 시기에 시간이 많아지게 되서 프로그래밍 공부도 놓치지 않고 열심히 할 수 있었으며, (당시에는 임베디드 분야를 생각하며 공부했다.) 졸업작품도 코로나와 맞물려 직접 건축모형을 만들지도 않아도 되어서 손재주가 나쁜 나로서는 엄청 큰 메리트를 얻었다. 덕분에 드론이라는 매개체와 연결한 산업클러스터라는 나름 신선한 주제로 작업물을 풀어갈 수 있었다. 그래서 3년간 바닥을 기었던 내 성적을 보란듯이 비웃으며 총 10학점 수업인 졸업 설계에서 A+라는 학점과 수상이라는 신기록으로 졸업할 수 있었던 것 같다. 나는 졸업 이후에 일도 하면서 또 추가적으로 공부를 하면서 내가 생각하는 미래에 부합하는 회사들에 지원했고, 그 중 가장 가고싶었던 도메인에 입사해서 8개월을 이어가고 있다. 원래는 웹개발 보다는 임베디드 쪽을 생각하며 공부했지만 공부하던 중에 알게된 여러 생각들이 다시 내 마음을 바꿔 웹 백엔드라는 분야에서 일을 하고 있다.

급하게 마무리 지어야할 것 같은데, 오늘은 5월 5일이기때문에 놀러가야한다. 놀고와서 또 시간이 날 때 글을 마무리 지어야 겠다.

프로바이더는 Nest의 기본이 되는 개념이다. 이해가 쉽지 않아서 공식문서를 보며 정리하고 있는 중이다. 대부분의 기본 Nest 클래스는 서비스, 리포지토리, 팩토리, 헬퍼등 프로바이더로 분류된다. 이렇게 구분하는 방식 자체가 프로바이더(Provider)인 것 같다.

기본적으로 프로바이더의 중심 컨셉은 종속성으로 주입할 수 있다는 것이다. 주입할 수 있다는 이야기는 @Injectable() 데코레이터가 붙어있다는 것이다. 전체 애플리케이션의 중심에 있는 AppService에 붙은 @Injectable()은 Provider화 하기 위한 하나의 방식이다.

이를 통해 NestApp 내부의 객체는 서로 다양한 관계를 만들 수 있으며 객체의 인스턴스를 "연결"하는 기능은 대부분 Nest 런타임 시스템에 의해 짜여져서 애플리케이션으로서 작동한다는 이야기다.

예제로 살펴보는 Providers

src/user/user.service.ts

import { Injectable } from '@nestjs/common';
import { UserDto } from './dto/user.dto';
@Injectable()
export class UserService {
  private users: UserDto[] = [
    new UserDto('kim1', '브라이언 김'),
    new UserDto('park1', '존 박'),
  ];
  findAll() : Promise<UserDto[]> {
    return new Promise((resolve) =>
      setTimeout(
        () => resolve(this.users),
        100,
      ),
    );
  }
  findOne(id: string) : UserDto | object {
    const foundOne = this.users.filter(user => user.userId === id);
    return foundOne.length ? foundOne[0] : { msg: 'nothing' };
  }
  saveUser(userDto: UserDto) : void {
    this.users = [...this.users, userDto];
  }
}

3 line에서 @Injectable()을 선언해서, 이 싱글톤 객체(서비스)의 Dependency가 생성된다. Controller에서 사용할 로직은 Service 영역에서 사용할 수 있도록 짜여져 있고, 선언된 각 Method( ex) findOne, saveUser)들은 데이터를 조작하고 생성하고 조회하거나 삭제하는(CRUD)의 역할을 담당한다.

위와 같이 서비스 싱글톤 객체를 만들면, 메모리에 떠있기만 한다. 객체가 살아나긴 했는데 어떻게 쓸 수 있게 되는지 알아보자. 따라서 Controller의 소스를 만들어보자!

src/user/user.controller.ts

import { Body, Controller, Get, Param, Post, Res } from '@nestjs/common';
import { UserDto } from './dto/user.dto';
import { UserService } from './user.service';
@Controller('user')
export class UserController {

  // 의존성(Dependency) 주입
  **constructor(private userService: UserService) {
    this.userService = userService;
  }**
  @Get('list')
  findAll(): Promise<UserDto[]> {
    return this.userService.findAll();
  }
  @Get(':userId')
  findOne(@Param('userId') id: string): any | object {
    return this.userService.findOne(id);
  }
  @Post()
  saveUser(@Body() userDto: UserDto): string {
    this.userService.saveUser(userDto);
    return Object.assign({
      data: { ...userDto },
      statusCode: 201,
      statusMsg: `saved successfully`,
    });
  }
}

위의 Controller 코드를 통해서 살펴보자. Controller에는 생성자가 존재하고 해당 생성자에는 UserService라는 타입의 userService argument를 받아 UserController 내부의 멤버 변수에 주입한다.

생성자를 통해서, 객체 생성될 때 Provider을 넣어주는 것을 아마 주입이라고 표현하는 것 같다. @Injectable()은 결국 주입될 수 있도록 의존성(Dependency)를 만들어주는 것이다.

코드만 떼어서 살펴보면 아래와 같다. 결국은 이렇게 하게되면 UserService라는 싱글톤 객체를 Controller에 넣어주게되서, 내부 메서드를 사용할 수 있게 된다. 넣어줄 수 있는 객체 자체를 Providers이라고 부른다. 넣어지는 것을 의존성 주입(Dependency Injection, DI)이라고 부른다.

constructor(private userService: UserService) {
    this.userService = userService;
  }

IOC와 DI

IOC(Inversioin Of Control, 제어 역전)

메소드나 객체의 호출 작업을 개발자가 따로 코드를 작성해서 이루어지는 것이 아니라 Nest의 경우 Application 내부의 독자적인 제어(외부)에서 결정되는 것을 의미한다. 기존 프로그래밍 언어에서 객체나 인스턴스는 new와 같은 생성 지시어를 이용해서 메모리를 할당받는 식으로 직접 수행했다. 하지만 IOC의 개념이 도입된 NestJS에서는 세부적인 설정만을 명시하고 Nest가 인스턴스 lifeCycle을 제어하도록 위임한다는 뜻이다.

정말 쉽게 말해서, 내가 직접 Service 인스턴스나, Controller 인스턴스 혹은 Module 인스턴스같은 것들을 직접 필요에따라 인스턴스를 생성하고 삭제할 필요가 없어지는 것을 의미한다. 어떤 기능을 하는지, 어떻게 주입되는지에 대한 적절한 설정만 해두면 Application이 Runtime에 직접 이를 조정하고 제어한다.

DI(Dependency Injection, 의존성 주입)

의존성 주입이라는 것은 의존적인 객체(Controller 객체에 Service객체를 넣어서, Controller에서 Service의 메서드를 call할 수 있도록 넣어서 사용)를 직접 생성하지 않고 외부에서 결정한 뒤 연결하는 것을 의미한다. DI를 내포한 코딩(@Injectable())을 통해서 객체 지향성을 보장하며, 모듈간의 결합도를 낮추고, IOC의 구현에 적합한 플랫폼 부품(Provider)를 작성할 수 있게 된다.

윗 글을 정리해보자면 DI에 의해 주입된 의존성 명시에 의해 NestJS는 IOC를 지원하고 수행한다. 의존성을 가지고 주입될 수 있도록 의존 관계를 명시하고, 의존관계에 묶인 함수, 클래스, API등을 묶어서 처리할 수 있도록 해주므로 서비스의 동작을 추상적으로 연결하는 것을 쉽게 만들어 준다.고 이해했다.

스프링에서 중심개념이 튀어나왔기 때문에 스프링 개념으로 설명을 해야한다. 간단히 요약해보자면, provide는 key, 아래있는 use...로 쓴 것이 value로 Nest Application 내부의 IoC Container에 등록된 뒤, DI를 진행(resolve)할 수 있다.

Provider의 실행 과정

1. @Injectable() 데코레이터를 발견하면 해당 클래스를 Nest IOC 컨테이너가 관리할 수 있는 클래스로 선언한다.
2. Controller에서 해당 Provider Token에 대한 의존성을 생성자 주입(DI)과 함께 생성한다.
3. Module에서 Provider Token을 해당 Provider의 클래스와 연결한다.

// 코드 작성시
@Module({
      controllers: [UsersController],
      providers: [UsersService],
})

// 실제 컴파일될 때 코드
@Module({
  controllers: [UsersController],
  providers: [
        {    
          provide: UsersService,
          useClass: UsersService,
        },
        ];
})

위와 같은 종속성 처리는 부트스트랩(main.ts > bootstrap();)에 의해 발생한다.

Custom Provider 살펴보기

NestJS의 Provider에서 좀 어렵기도하고 흥미롭기도 한 부분이 Custom Provider 이부분이다. 원하는 목적과 최적화 성능에 맞춰 개발자가 Custom Provider를 정의하고 사용할 수 있는데 예시 코드를 작성하며 이해해 보았다.

useValue

모형 객체에 실제 구현을 대체하는데 용이하다.

import { connection ] from './connection'; // 외부 파일의 객체
@Module({
   providers: [
        {
        provide: UsersService,      //사용할 provide 
        useValue: ${대체할 Provider},//실제 provide
        },
    ],
})
export class AppModule {}

혹은 문자열 값 토큰을 외부 파일에서 가져온 다른 객체와 연결하는 기능을 제공할 수도 있다.

import { connection } from './connection'; //외부 파일의 connection 객체

@Module({
    provide: 'CONNECTION', // 문자열 토큰
    useValue: connection, //해당 토큰과 연결할 외부 파일 객체
    },
  ],
});
export class AppModule{ }        

위의 패턴을 사용해 문자열 형태의 Token으로 객체를 연결하고 싶다면, 종속성을 클래스 이름으로 선언해야 한다.

@Injectable()
export class UsersRepository {
      constructor(@Inject('CONNECTION') connection: Connection) {}
}

useClass

동적으로 해결해야 할 필요가 있는 클래스를 결정할 때 쓸 수 있다. (ex 추상 or 기본 클래스를 환경에 따라 다르게 넣어주고자 하는 다양한 상황에서)

const configServiceProvider = {
      provider: ConfigService,
      useClass:
          process.env.NODE_ENV === 'development' // 환경에 따라 서비스를 정해 연결
              ? DevelopmentConfigService,
              : ProductionConfigService,
    };

  @Module({
      providers: [configServiceProvider],
  })

  export class AppModule {}

useFactory

동적인 Provider 생성이 가능하다. 실제 Provider는 정의한 Factory Function의 return값으로 제공된다. Factory의 작업에 다른 Provider를 주입하는 것도 가능하다. (하지만 이 부분은 주의할 점이 있음, 하단 메커니즘에 표시)

const connectionFactory = {
  provide: 'CONNECTION',
  useFactory: (optionsProvider: OptionsProvider) => {
    const options = optionsProvider.get();
    return new DatabaseConnection(options);
  },
  inject: [OptionsProvider], // 팩토리에 optionProvider를 주입하기 위해 필요
};

@Module({
  providers: [connectionFactory],
})
export class AppModule {}

동적으로 Provider를 생성한다는 말에서 '동적'이라는 말은 Factory Function에서 처리된 결과로 반환받은 Provider 클래스를 주입받는 것과 동일하다. useFactory는 개발할 때 사용하는데, 위의 예시코드처럼 Database Config Service를 Database Service에 항상 주입해놓지 않고 필요시에만 저렇게 Factory를 통해 주입할 수 있다.

이렇게 사용하면 Production/dev 환경을 분리하거나 Database를 변경하면서 사용해야할 때 쉽게 Service를 적용할 수 있도록 config(환경)과 database service(비즈니스 로직)이 분리될 수 있어서 유용하다.

useExisting

기존의 Provider에 대한 별칭 설정이 가능하다. 동일한 Provider에 대한 접근하는 방법이 별칭까지 두가지로 늘어난다.(ex 클래스 기반 Provider와 문자열 토큰 기반 Provider를 별칭을 통해서 분리 시킴, alias 개념임)

@Injectable() //클래스 기반 Provider
class LoggerService {
     // 비즈니스 로직
}

const loggerAliasProvider = { //문자열 토큰 기반 Provider, 별칭 생성
      provide: 'AliasedLoggerService',
      useExisting: LoggerService, //종속성 설정
};

@Module({
  providers: [LoggerService, loggerAliasProvider],
})
export class AppModule {}

Custom Provider Export

다른 Provider와 동일하게 사용자 지정 Provider 또한 선언된 모듈 내부로 범위가 지정된다. 다른 모듈에 표시하기 위해서는 Export를 통해 내보내기를 수행해야한다. 문자열 토큰을 내보낼수도 있으며, 전체 Provider 객체를 내보낼 수도 있음!

export with Token

const connectionFactory = {
  provide: 'CONNECTION',
  useFactory: (optionsProvider: OptionsProvider) => {
    const options = optionsProvider.get();
    return new DatabaseConnection(options);
  },
  inject: [OptionsProvider],
};

@Module({
  providers: [connectionFactory],
  exports: ['CONNECTION'], // 지정한 토큰만을 export
})
export class AppModule {}

export with the full provider object

const connectionFactory = {
  provide: 'CONNECTION',
  useFactory: (optionsProvider: OptionsProvider) => {
    const options = optionsProvider.get();
    return new DatabaseConnection(options);
  },
  inject: [OptionsProvider],
};

@Module({
  providers: [connectionFactory],
  exports: [connectionFactory], // 전체 Provider 객체를 export
})
export class AppModule {}

마치며

대충 이정도면 Providers라는 개념을 이해하기는 쉬울 것 같다. 이전까지는 Providers:[]라고 적혀있으면 멘붕이 왔었는데, 이제는 좀 쉽게 이해할 수 있을 것 같다. 결국엔 내부에서 사용될 객체를 나열해서 집어넣는 것이라고 보면 되겠다. 그 집어넣는 과정에서 config(context or 환경)에 따라 다르게 집어넣거나, 집어넣는 것을 다른 이름으로 집어넣거나 하는 방식에 있어서 use... 어노테이션을 활용하는 것이고... 100% 이해는 안됐지만 나름 이해하려고 노력중이다..

테스트가 자동화되어있으면 차후에 유지관리 측면에서 혹은 문제가 발생하거나 했을 때의 개발차원의 자원이 과도하게 들어가는 것을 막을 수 있기때문에 필수적으로 취급된다. 자동화를 통해 개발중에 개별 유닛으로 테스트하거나 테스트 스위트를 쉽게 빠르고 반복할 수 있다. 이는 릴리즈의 품질과 성능 목표 충족도를 확인하는데 크게 도움이 된다. 자동화는 적용범위를 늘리고 개발자에게 더 빠른 피드백 루프를 제공한다. 자동화는 개별 개발자의 생산성도 높여주고, 소스 코드 제어 체크인, 기능 통합 및 버전 릴리즈와 같은 중요한 개발 수명주기 단계에서 테스트가 실행되도록 한다.

이러한 테스트는 단위 테스트, 종단간(e2e) 테스트, 통합 테스트등 다양한 유형에 걸쳐있는 경우가 많다. 단위 테스트의 경우 개별 모듈의 성능을 검사하고 체크하며, e2e테스트는 성능 한계점까지 커버리지를 확인하는 테스트고, 실제 환경과 동일하게 차용해서 확실함을 높인 테스트다. 통합 테스트의 경우 이러한 테스트를 종합적으로 테스트로 구축해서 전반적인 서비스 로직 흐름이 원활하게 돌아가는지 확인하기 위한 테스트다. 테스트가 필수적인 것은 확실히 알 수 있지만, 이를 초기 세팅하는 과정이 귀찮고 지루할 수 있다. Nest는 효과적인 테스트를 위한 다양한 툴과 모범 사례를 공유하고 있다.

Nest

• 구성 요소(Module)에 대한 기본 단위 테스트 및 애플리케이션에 대한 e2e테스트를 자동으로 구축해준다.
• 기본 도구 제공(예 : 격리 모듈/어플리케이션 로더를 빌드하는 테스터)
• Jest 및 Supertest와 통합을 즉시 제공하는 동시에 테스트 도구에 대해 독립적이다.
• 구성 요소(Module)을 쉽게 모의(Mock)하기 위해서 테스트 환경에서 Nest 종속성 주입 시스템을 사용할 수 있다.

언급했듯이 Nest는 특정 도구를 강제하지 않으므로 원하는 테스트 프레임워크를 사용할 수 있다. 필요한 요소(예: 테스트 실행기)를 교체하기만하면 Nest의 기성 테스트의 이점을 계속 누릴 수 있다.

Installation

$ npm i --save-dev @nestjs/testing

Unit Testing

예제를 통해서, (공식문서에는 Cats를 이용해서 만든 모듈로 존재하는데, 이를 User로 바꾼다.) 클래스 테스트를 확인해보자. 앞서 언급했듯이 기본 테스트 프레임워크로 Jest가 제공된다. 테스트 실행자 역할을 하며 Mock, Spy 등에 도움되는 assert 함수 및 테스트 이중 유틸이 제공된다. 기본 테스트에서 이런 클래스를 수동으로 인스턴스화해서, 컨트롤러와 서비스가 API대로 동작하는지 확인한다.

users.controller.spec.ts

import { UsersController } from './users.controller';
import { UsersService } from './users.service';

describe('UsersController', () => {
  let UsersController;
  let UsersService;

  beforeEach(() => {
    UsersService = new UsersService();
    UsersController = new UsersController(UsersService);
  });

  describe('findAll', () => {
    it('should return an array of users', async () => {
      const result = ['test'];
      jest.spyOn(UsersService, 'findAll').mockImplementation(() => result);

      expect(await catsController.findAll()).toBe(result);
    });
  });
});

테스트 파일은 users.controller.spec.ts이나, users.service.test.ts와 같은 네이밍으로 파일이름을 지어야한다.

위의 샘플코드는 사소한 것이기 때문에 실제 Nest 테스트와는 다르다. 위엔 실제로 의존성 주입도 되어있지 않다. (UsersService의 인스턴스를 UsersController에 전달한다는 점에 유의하자!) 테스트중인 클래스를 수동으로 인스턴스화하는 이러한 형식의 테스트는 프레임워크와 독립적이므로 종종 격리된 테스트라고 합니다. Nest기능을 보다 광범위하게 사용하는 애플리케이션을 테스트하는데 도움이 되는 기능들을 살펴보자.

Testing utilities

@nestjs/testing 패키지는 보다 강력한 테스트 프로세스를 가능하게 하는 유틸리티 세트를 제공한다. 내장된 Test클래스를 사용하여 이전 예제를 다시 작성해보자.

users.conroller.spec.ts

import { Test } from '@nestjs/testing';
import { UsersController } from './users.controller';
import { UsersService } from './users.service';

describe('UsersController', () => {
  let usersController: UsersController;
  let userService: UsersService;

  beforeEach(async () => {
    const module = await Test.createTestingModule({
        controllers: [UsersController],
        providers: [UsersService],
      }).compile();

    usersService = module.get<UsersService>(UsersService);
    usersController = module.get<UsersController>(UsersController);
  });

  describe('findAll', () => {
    it('should return an array of users', async () => {
      const result = ['test'];
      jest.spyOn(usersService, 'findAll').mockImplementation(() => result);

      expect(await usersController.findAll()).toBe(result);
    });
  });
});

Test클래스는 기본적으로 전체 Nest runtime을 Mock하는 애플리케이션 실행 컨텍스트를 제공하는 데 유용하지만, Mocking 및 재정의를 포함하여 클래스 인스턴스를 쉽게 관리할 수 있는 Hook을 제공한다. Test 클래스에는 모듈 메타데이터 객체를 인수로 사용하는 createTestingModule() 메서드가 있다. (@Module() 데코레이터에 전달하는 동일한 객체). 이 메서드는 몇가지 메서드를 제공하는 TestingModule 인스턴스를 반환한다. 단위 테스트에서 중요한 것은 compile()메서드다. 이 메소드는 의존성이 있는 모듈을 bootstrap하고(애플리케이션이 NestFactory.create()를 사용하여 기존 main.ts 파일에서 bootstrap되는 방식과 유사함) 테스트할 준비가 된 모듈을 반환한다.

compile()메서드는 비동기이므로 컴파일까지 기다려야한다. 모듈이 컴파일 되면 get()메서드를 사용하여 선언하는 정적 인스턴스(controller 및 provider)를 검색할 수 있습니다.

TestingModule은 모듈 참조 클래스에서 상속되므로 범위가 지정된 프로바이더(임시 또는 요청 범위)를 동적으로 확인하는 기능이다. resolve()메서드를 사용하여 이 작업을 수행한다.(get()메서드는 정적 인스턴스만 검색할 수 있다.)

const moduleRef = await Test.createTestingModule({
                          controllers: [UsersController],
                          providers: [UsersService],
                    }).compile();

usersService = await moduleRef.resolve(UsersService);

resolve()메서드는 자체 DI 컨테이너 하위 트리에서 프로바이더의 고유한 인스턴스를 반환한다. 각 하위트리에는 고유한 컨텍스트 식별자가 있다. 따라서 이 메서드를 두번 이상 호출하고 인스턴스 참조를 비교하면 같지 않음을 알 수 있다.

프로바이더의 프로덕션 버전을 사용하는 대신 테스트 목적으로 Custum Provider로 재정의할 수 있다. 예를 들어 DB에 연결하는 대신 데이터베이스 서비스를 Mock할 수 있다. 다음 섹션에서 재정의를 다루겠지만, 단위 테스트에서 사용할 수 있다.

End-to-end testing

개별 모듈 및 클래스에 초점을 맞춘 단위 테스트와 달리 엔드-투-엔드(e2e)테스트는 최종 사용자가 프로덕션 레벨에서 가질 수 있는 수준보다 훨씬 더 디테일하고 총체적인 수준에서의 클래스 및 모듈 테스트다. system, application의 scale이 커질수록 각 API 엔드 포인트의 end-2-end 동작을 수동으로 테스트하기 어렵다. 자동화된 e2e 테스트는 시스템 전반적인 동작이 정확하고 프로젝트 요구사항을 충족하는지 확인하는데 도움된다. e2e 테스트를 수행하기 위해 방금 단위 테스트에서 다룬 것과 유사하게 사용한다. Nest를 사용하면 supertest 라이브러리를 사용해서 HTTP 요청을 쉽게 시뮬레이션 할 수 있다.

users.e2e-spec.ts

import * as request from 'supertest';
import { Test } from '@nestjs/testing';
import { UsersModule } from '../../src/users/users.module';
import { UsersService } from '../../src/users/users.service';
import { INestApplication } from '@nestjs/common';

describe('Users', () => {
  let app: INestApplication;
  let usersService = { findAll: () => ['test'] };

  beforeAll(async () => {
    const moduleRef = await Test.createTestingModule({
      imports: [UsersModule],
    })
      .overrideProvider(UsersService)
      .useValue(catsService)
      .compile();

    app = moduleRef.createNestApplication();
    await app.init();
  });

  it(`/GET users`, () => {
    return request(app.getHttpServer())
      .get('/users')
      .expect(200)
      .expect({
        data: catsService.findAll(),
      });
  });

  afterAll(async () => {
    await app.close();
  });
});

이 예에서는 앞에서 설명한 몇가지 개념을 기반으로 한다. 이전에 사용한 compile() 메서드 외에도 이제 createNestApplication() 메서드를 사용하여 전체 Nest 런타임 환경을 인스턴스화한다. 실행중인 앱에 대한 참조를 app변수에 저장하여 HTTP요청을 시뮬레이션하는데 사용할 수 있다.

Supertest의 request() 함수를 사용하여 HTTP 테스트를 시뮬레이션한다. 이러한 HTTP 요청이 실행중인 Nest 앱으로 라우팅되기를 원하므로 request() 함수에 Nest의 기반이 되는 HTTP 리스터에 대한 참조를 전달한다.(이는 Express 플랫폼에서 사용할 수 있다.) 따라서 구성 request(app.getHttpServer()).request() 호출은 이제 Nest 앱에 연결되어 래핑된 HTTP 서버를 전달한다. 이 서버는 실제 HTTP 요청을 시뮬레이션하는 메소드를 노출합니다. 예를 들어, request(...).get('/cats')를 사용하면 네트워크를 통해 들어오는 get '/cats'와 같은 실제 HTTP 요청과 동일한 Nest앱에 대한 요청이 시작된다.

이 예에서는 테스트할 수 있는 하드코딩된 값을 간단히 반환하는 UsersService의 대체(test-double) 구현도 제공한다. 이러한 대체 구현을 제공하려면 overrideProvider()를 사용해야 한다. 마찬가지로 Nest는 각각 overrideGuard(), overrideInterceptor(), overrideFilter() 및 overridePipe() 메서드를 사용하여 가드, 인터셉터, 필터 및 파이프를 재정의하는 메서드를 제공한다.

각 재정의 메서드는 커스텀 프로바이더에 대해 설명된 메서드를 미러링하는 3가지 메서드가 있는 객체를 반환한다.

• useClass: 객체(프로바이더, 가드 등)을 재정의할 인스턴스를 제공하기 위해 인스턴스화될 클래스를 제공한다.
• useValue: 객체를 재정의할 인스턴스를 제공한다.
• useFactory: 객체를 재정의할 인스턴스를 반환하는 함수를 제공한다.

각 재정의 메서드 유형은 차례로 TestingModule 인스턴스를 반환하므로 fluent style의 다른 메서드와 연결할 수 있다. 이러한 체인의 끝에 compile()을 사용하여 Nest가 모듈을 인스턴스화하고 초기화하도록 해야한다.

또한 때로는 사용자 정의 Logger를 제공하고 싶을 수도 있다. 테스트가 실행될 때(예: CI 서버에서). setLogger() 메소드를 사용하고 LoggerService 인터페이스를 충족하는 객체를 전달하여 TestModuleBuilder에 테스트중에 기록하는 방법을 지시한다. 기본적으로 오류로그만 콘솔에 기록된다. 컴파일된 모듈에는 다음 표에 설명된 몇가지 유용한 메서드가 있다.

createNestApplication()

주어진 모듈을 기반으로 Nest 애플리케이션(INestApplication인스턴스)을 만들고 반환한다. init() 메서드를 사용하여 애플리케이션을 수동으로 초기화해야 한다.

createNestMicroservice()

지정된 모듈을 기반으로 Nest 마이크로 서비스(INestMicroservice 인스턴스)를 만들고 반환한다.

get()

애플리케이션 환경에서 사용 가능한 컨트롤러 또는 프로바이더(가드, 필터등 포함)의 정적 인스턴스를 검색한다. 모듈 참조 클래스에서 상속된다.

resolve()

애플리케이션 환경에서 사용할 수 있는 컨트롤러 또는 프로바이더(가드,필터 등 포함)의 동적으로 생성된 범위 인스턴스(요청 또는 일시적)를 검색한다. 모듈 참조 클래스에서 상속된다.

select()

모듈의 종속성 그래프를 탐색한다. 선택한 모듈에서 특정 인스턴스를 검색하는데 사용할 수 있다.(get()메서드에서 엄격모드(strict: true)와 함께 사용됨).

e2e 테스트 파일을 test 디렉토리에 보관하자! 테스트 파일에는 .e2e-spec 접미사가 있어야 한다.

Overriding globally registered enhancers

전역적으로 등록된 가드(또는 파이프, 인터셉터 또는 필터)가 있는 경우 해당 인핸서를 재정의하기 위해 몇가지 단계를 더 수행해야 한다. 원래 등록을 요약하면 다음과 같다.

providers: [
    {
    provide: APP_GUARD,
    useClass: JwtAuthGuard,
    },
],

APP_*토큰을 통해 가드를 "다중"프로바이더로 등록하는 것이다. 여기서 JwtAuthGuard를 교체하려면 등록시 이 슬롯에 있는 기존 프로바이더를 사용해야 한다.

providers: [
  {
    provide: APP_GUARD,
    useExisting: JwtAuthGuard,
  },
  JwtAuthGuard,
],

useClass를 useExisting으로 변경하여 Nest가 토큰 뒤에서 인스턴스화하는 대신 등록된 프로바이더를 참조하자.

이제 JwtAuthGuard는 TestingModule을 만들 때 재정의할 수 있는 일반 프로바이더로 Nest에 표시된다.

const module = await Test.createTestingModule({
      imports: [AppModule],
})
    .overrideProvider(JwtAuthGuard)
    .useClass(MockAuthGuard)
    .compile();

이제 모든 테스트에서 모든 요청에 MockAuthGuard를 사용한다.

Testing request-scoped instances

요청 범위 프로바이더는 들어오는 각 요청에 대해 고유하게 생성된다. 요청이 처리를 완료한 후 인스턴스가 가비지 콜렝팅(Garbage Collecting)된다. 테스트된 요청을 위해 특별히 생성된 종속성 주입 하위 트리에 액세스할 수 없기 때문에 문제가 된다.

우리는(위 섹션을 기반으로)resolve()메서드를 사용해서 동적으로 인스턴스화된 클래스를 검색할 수 있다는 것을 알고 있다. DI 컨테이너 하위 트리의 수명주기를 제어하기 위해 고유한 컨텍스트 식별자를 전달할 수 있다. 이를 테스트 컨텍스트에서 어떻게 사용하는가?

미리 컨텍스트 식별자를 생성하고 Nest가 이 특정 ID를 사용하여 들어오는 모든 요청에 대한 하위트리를 만들도록 하는 것이다. 이러한 방식으로 테스트된 요청을 위해 생성된 인스턴스를 검색할 수 있다.이를 수행하려면 ContextIdFactory에서 jest.spyOn()을 사용한다.

const contextId = ContextIdFactory.create();
jest
    .spyOn(ContextIdFactory, `getByRequest`)
    .mockImplementation(()=>contextId);

이제 contextId를 사용하여 후속 요청에 대해 생성된 단일 DI 컨테이너 하위 트리에 엑세스할 수 있다.

usersService = await module.resolve(UsersService, contextId);

Unit test (단위 테스트)

NestJS는 내장된 종속성 주입을 사용해서 쉽게 테스트 코드를 작성할 수 있도록 도와준다! 종속성 주입은 일반적으로 클래스가 아닌 인터페이스를 기반으로하지만, TypeScript에서 인터페이스는 런타임이 아닌 컴파일 타임에만 존재한다.(런타임에는 인터페이스는 증발함.) 그렇기 때문에 타입에 대한 100% 신뢰성을 부여하기 어렵다. NestJS에서는 클래스 기반 주입을 사용하는 것이 일반적이다.

import { Test, TestingModule } from '@nestjs/testing';

describe('UserService', () => {
  let userService: UserService;
  let userRepository: UserRepository;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [UserService, UserRepository],
    }).compile();

    userService = module.get<UserService>(UserService);
    userRepository = module.get<UserRepository>(UserRepository);
  });
}

기존에 Express에서는 sinon과 같은 패키지를 사용해서 테스트하려는 Service를 모킹(Mocking)해서 사용했으며, 테스트 프레임워크를 직접 설치해서 사용했었지만 NestJS에서는 특정 도구를 강제하지는 않지만 JEST를 기본 테스트 프레임워크로 제공해주며 테스팅 패키지도 제공하기 때문에 개발자가 다른 도구를 찾는데 소모하는 리소스를 줄일 수 있다.

NestJS에서 제공하는 @nestjs/testing패키지를 사용하면 테스트에 사용되는 종속성만 선언해서 모듈을 만들고 해당 모듈로 UserService, UserRepository를 가져올 수 있다. 따로 단위테스트를 작성하기 위해서는 페이크 데이터를 만들어줄 필요가 있다. 기본적으로 들어갔다 나오는 결과물에 대한 것들을 지정해줘야 실제 테스팅이 이루어지기 때문이다. 물론 다른 프레임워크를 이용하면 데이터를 실제로 만들지 않아도 편리하게 할 수 있다.

Jest Mocking

const userRepositorySaveSpy = jest
        .SpyOn(userRepository, 'save')
        .mockResolvedValue(savedUser);

Jest에서는 모킹(Mocking)함수를 기본적으로 제공한다. 모킹은 단위테스트를 작성할 때. 해당 코드가 의존하는 부분을 가짜로 대체해서 만드는 것을 의미한다. 일반적으로는 테스트하려는 코드가 의존하는 부분을 직접 생성하기가 너무 부담스러울때 모킹이 사용된다. 위 코드에서는 SpyOn으로 userRepository의 save함수를 호출하는 것을 Mock하고, 이 Mock된 함수는 mockResolvedValue의 결괏값을 리턴하도록 하고 있다.

쉽게 말하면, userReposity에서 'save'를 call하는 것을 추적하면서, 결과값이 savedUser가 되도록하는 mocking함수라고 보면 된다.

이런식으로 Mocking함수에 넣어줄 실제 형태를 만들어서 삽입할 수 있다.

const savedUser: User = { firstName : 'brian', lastName: 'Kim' };

NestJS에서 단위 테스트 작성

서비스에서 사용된 updateUser 메서드

async updateUser(
  id: number,
  requestDto: UserUpdateRequestDto,
): Promise<User> {
      const userToUpdate = await this.userRepository.findOne({where: { id: id },});

    if(!userToUpdate) {
        throw new BadRequestException(Message.NOT_FOUND_ERROR);
    }

    const { firstName, lastName, isActive);
    user.update(firstName, lastName, isActive);

    return this.userRepository.save(user);
}

유저 정보 수정 / 존재하지 않는 유저 정보 수정

Jest를 이용해서 위의 User 정보를 수정하는 서비스의 단위 테스트를 작성해보도록 하자! UserService의 updateUser 메서드를 테스트하려고하는데, 이 메서드에서는 두 가지를 테스트해야 한다. 유저 정보가 존재할 때는 성공적으로 수정하고 유저 정보가 존재하지 않을 경우엔 실패하는 로직에 대해서 검증이 필요하다.

describe('UserService', () => {
    describe('유저 정보 수정', () => {
        if('존재하지 않는 유저 정보를 수정할 경우 NotFoundError 발생시킨다.', async () => {
            const userId: number = 1;

                const updateUserDto: UpdateUserDto = {
                      firstName: 'John',
                      lastName: 'Park'
            }

                const userRepositoryFindOneSpy = jest
                    .spyOn(userRepository, 'findOne')
                    .mockResolvedValue(undefined);

          try {
                await userService.updateUser(userId, updateUserDto);
          } catch(e) {
                expect(e).toBeInstanceOf(NotFoundException);
                expect(e.message).toBe(Message.NOT_FOUND_ERROR);
          }

          expect(userRepositoryFindOneSpy).toHaveBeenCalledWith({
                where: {
                      id: userId,
                },
          });
        });
    });
})

위의 단위 테스트 코드에서는 존재하지 않는 유저의 정보를 수정할 때는 findOne 메서드가 null값을 반환할 거라고 모킹해준다. updateUser 메서드는 가짜로 null의 값이 반환되는 줄 알고 null일 때, NotFoundError가 발생하는 로직을 실행하게 된다. expect(e).toBeInstanceOf(NotFoundException)는 이 오류 메시지 객체가 NotFoundException 클래스의 인스턴스인지 확인하는 작업이며, .toBe로 값을 비교해서 올바르게 오류 메시지가 나왔는지 검증할 수 있다.

유저 정보 수정 / 유저 정보를 성공적으로 수정

describe('UserService', () => {
  describe('유저 정보 수정', () => {
    it('유저 정보를 성공적으로 수정한다.', async () => {
      const userId: number = 1;

      const updateUserDto: UpdateUserDto = {
        firstName: 'John', 
        lastName: 'Park'
        isActive: false,
      };

      const existingUser = User.of({
        id: userId,
        firstName: 'Brian',
        lastName: 'Kim',
        isActive: true,
      });

      const savedUser = User.of({
        id: userId,
        ...updateUserDto,
      });

      const userRepositoryFindOneSpy = jest
        .spyOn(userRepository, 'findOne')
        .mockResolvedValue(existingUser);

      const userRepositorySaveSpy = jest
        .spyOn(userRepository, 'save')
        .mockResolvedValue(savedUser);

      const result = await userService.updateUser(userId, updateUserDto);

      expect(userRepositoryFindOneSpy).toHaveBeenCalledWith({
        where: {
          id: userId,
        },
      });
      expect(userRepositorySaveSpy).toHaveBeenCalledWith(savedUser);
      expect(result).toEqual(savedUser);
    });
  });
})

updateUser메서드에서 유저 정보를 찾아서 유저 정보를 정상적으로 수정했다는 로직의 테스트다. 미리 정의해놓은 existingUser을 반환할 거라고 모킹 해주고, 이 반환된 값을 수정해서 저장하면 saveduser을 반환할거라고 Mock했다. 그리고 오류가 없이 정상적으로 처리된 내용을 result에 값을 담고, Jest의 expect를 통해 검증한다. 먼저, .toHaveBeenCalledWith는 Mocking 함수가 특정 인수로 호출되었는지 확인하는데 사용될 수 있고, .toEqual로 개체의 모든 속성을 재귀적으로 비교한다.

UserService의 User정보를 수정하는 코드의 일부분을 살펴보았다.

마치며

E2E테스트는 (End to End) 종단테스트로 환경에 의존하지만, 단위 테스트는 기본적으로 환경이랑 상관없이 빠르게 실행되어야 한다. E2@테스트에서는 보통 테스트 데이터베이스를 사용하고, 테스트의 신뢰성이 높지만 속도가 느리다는 단점이 있다.

@Nest/Swagger

Swagger는 API 문서 자동화도구이다. Nest를 실질적으로 프로젝트에 적용한 적이 없었기 때문에 이전에는 DB를 기록하는 방식으로 DBdiagram이라는 웹 서비스를 이용했었다. API의 변경사항이 있을때마다 수기로 작성해서 변경시켜줘야하는 부분에서 번거로움이 많았고, 프론트엔드와 의사소통 과정중에 변동사항을 일일히 모아서 적용시켜야 했었다. Swagger라는 Nest 툴을 이용하면 이러한 API 문서를 따로 작성할 필요 없이 구현 코드를 수정하면서 API 문서를 같이 수정할 수 있다. (아무래도 개발자들은 모든걸 코드로 해결하고 싶어하는 것 같다(?))

만약에 코드와 API 문서를 따로 관리하게 되면, 코드는 수정되고 API 문서는 갱신하지 않아 최신화되지 않으면 다른 팀원들에게 공유된 API 문서가 실제 코드내의 API와 다른 문제가 발생할 수 있다. 그리고, 일일히 문서화하는 것에서 큰 실수가 발생할 수 있지만 실제 구동을 코드에 영향주지 않으면서 테스트할 수 있다는 점이 크게 장점이다.

다른 장점으로는 Swagger로 작성된 API 페이지를 따로 생성해서 실제로 값을 요청하고 응답을 확인하는 테스트할 수 있는 인터페이스를 제공한다는 것이다. /api/docs 이런 페이지에서 실제로 확인할 수 있다.

NestJS에서 Swagger install

Swagger를 사용하는 방법은 간단하다. NestJS에서 사용할 수 있도록 모듈이 제공되고 있다. 아래의 모듈들을 설치하면 된다.

Swagger-ui-express를 사용하는 경우

npm install --save @nestjs/swagger swagger-ui-express

NestJS(fastify)를 사용하는 경우

npm install --save @nestjs/swagger fastify-swagger

NestJS에서 Swagger 사용하기

swagger-home

1. main.ts에서 SwaggerModule를 사용해서 아래와 같이 초기화한다.

import { NestFactory } from '@nestjs/core';
import { AppModule } from 'src/app.module';
import { setupSwagger } from 'src/util/swagger';
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
    // ... 생략
  setupSwagger(app);
  await app.listen(3000);
}
void bootstrap();

따로 setupSwagger를 만들 수도 있다. DocumentBuilder로 문서의 기본을 구성할 수 있다. 제목, 설명, 버전 등과 같은 속성을 설정할 수 있는 몇 가지 메서드를 제공한다. API 문서를 만들기 위해 SwaggerModule의 createDocument() 메서드를 사용한다.

import { INestApplication } from '@nestjs/common';
import { SwaggerModule, DocumentBuilder } from '@nestjs/swagger';
/**
 * Swagger 세팅
 *
 * @param {INestApplication} app
 */
export function setupSwagger(app: INestApplication): void {
  const options = new DocumentBuilder()
    .setTitle('NestJS Study API Docs')
    .setDescription('NestJS Study API description')
    .setVersion('1.0.0')
    .build();
  const document = SwaggerModule.createDocument(app, options);
  SwaggerModule.setup('api-docs', app, document);
}

아래의 코드에서 setup() 메서드를 통해서 Swagger UI를 Mount하는 Path를 설정할 수 있다. 브라우저에서 http://localhost:3000/api-docs로 이동하면 Swagger UI가 표시된다.

SwaggerModule.setup('api-docs', app, document);

swagger-controller

기초 구성은 끝났으니 이제 만들어진 API에 문서화를 해보자. @nestjs/swagger에서 제공하는 데코레이터들을 사용하면 된다.

import { ApiTags, ApiOperation, ApiResponse } from '@nestjs/swagger';

@Controller('v1/users')
@ApiTags('유저 API')
export class UserController {
  constructor(private readonly userService: UserService) {}

  @Post()
  @ApiOperation({ summary: '유저 생성 API', description: '유저를 생성한다.' })
  @ApiCreatedResponse({ description: '유저를 생성한다.', type: User })
  async create(@Body() requestDto: UserCreateRequestDto, @Res() res: Response) {
    const user: User = await this.userService.createUser(requestDto);

    return res.status(HttpStatus.CREATED).json(user);
  }
}

컨트롤러(Controller)에만 Swagger를 사용하고 Swagger UI를 확인해본다.

swagger-api-test

API에 대한 Swagger UI가 만들어졌는데, Try it out버튼을 클릭하면 API의 동작을 테스트할 수 있는 화면이 나온다.

Execute 버튼을 클릭하면 API를 호출해서 응답을 확인할 수 있다.

@ApiTags()로 ‘유저 API’를 설정하였는데 해당 컨트롤러가 어떤 API 인지 설정할 수 있다. 각 API에 대한 설명으로는 @ApiOperation()로 설정할 수 있다. @ApiCreatedResponse()와 같은 API 응답에 대해서 정의할 수 있는 데코레이터를 제공한다.

@nestjs/swagger에서 제공하는 API 응답 데코레이터들은 아래와 같다. 개별내용은 나중에 포스팅으로 정리하도록 하겠다. 현재 필요한 내용들은 위에 내용들이 대부분이지만, 추가적인 응답에 대한 정의도 내릴 수 있는 것으로 보인다. 모든 데코레이터는 Api%로 시작한다!

@ApiOkResponse()
@ApiCreatedResponse()
@ApiAcceptedResponse()
@ApiNoContentResponse()
@ApiMovedPermanentlyResponse()
@ApiBadRequestResponse()
@ApiUnauthorizedResponse()
@ApiNotFoundResponse()
@ApiForbiddenResponse()
@ApiMethodNotAllowedResponse()
@ApiNotAcceptableResponse()
@ApiRequestTimeoutResponse()
@ApiConflictResponse()
@ApiTooManyRequestsResponse()
@ApiGoneResponse()
@ApiPayloadTooLargeResponse()
@ApiUnsupportedMediaTypeResponse()
@ApiUnprocessableEntityResponse()
@ApiInternalServerErrorResponse()
@ApiNotImplementedResponse()
@ApiBadGatewayResponse()
@ApiServiceUnavailableResponse()
@ApiGatewayTimeoutResponse()
@ApiDefaultResponse()

유저를 생성하는 API의 코드에서는 UserCreateRequestDto 클래스를 사용하는데 이 클래스는 현재는 Swagger UI에서는 표시되어 있지 않다.

swagger-dto-schema

import { ApiPropertyOptional } from '@nestjs/swagger';

export class UserCreateRequestDto {
  @ApiProperty({ description: '이름' })
  firstName!: string;

  @ApiProperty({ description: '성' })
  lastName!: string;
}

UserCreateRequestDto 클래스의 속성에 @ApiProperty() 데코레이터를 사용해서 Swagger 문서화를 할 수 있다. @ApiProperty()에서 제공하는 옵션들을 활용해서 다양한 설정도 할 수 있다. 보통 DTO를 정의할 때는 @Column() 정의가 마무리되는 마지막에 @ApiProperty()를 이용해서 정의해준다.

그렇게 작성하고나면 API 명세와 마찬가지로 Swagger UI에서 UserCreateRequestDto 클래스의 Schema도 확인할 수 있다.

swagger-user-schema

import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';
import { ApiProperty } from '@nestjs/swagger';

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  @ApiProperty({ description: 'id' })
  id!: number;

  @Column({
    length: 50,
  })
  @ApiProperty({ description: '이름' })
  firstName!: string;

  @Column({
    length: 50,
  })
  @ApiProperty({ description: '성' })
  lastName!: string;

  @Column({ default: true })
  @ApiProperty({ description: '활동' })
  isActive!: boolean;

  static of(params: Partial<User>): User {
    const user = new User();

    Object.assign(user, params);

    return user;
  }
}

컨트롤러에서 반환하는 타입을 User로 설정하였는데 User.ts도 Dto 클래스와 같은 방식으로 Swagger를 사용할 수 있다.

마치며

Swagger를 사용하지 않고 Wiki와 같이 API 문서를 따로 관리한다면Swagger보다 더 유연한 API 문서 제공이 가능할 수 있다. 하지만 Wiki를 사용한다면 코드를 수정할 때마다 최신화하는 것을 잊지 말아야 한다. 이 부분이 굉장히 불편하고 실제로 프로젝트를 진행하면서 많은 방해가 되기도한다. 또 추가적으로 Postman처럼 API를 테스트할 수 있는 도구를 제공해야 한다. 물론 Swagger를 통해서 문서화의 일부를 유연하게 가져갈 수 있지만, 문서화를 통해서 진행하는것이 훨씬 더 명확하기 때문에 놓치지 않는 것이 중요하다.

더 많은 @nestjs/swagger의 데코레이터들은 여기에서 확인할 수 있다. 공식문서의 OPENAPI 단락에서 더 많은 정보를 얻을 수 있다.

Reference

https://docs.nestjs.com/openapi/introduction https://docs.nestjs.com/openapi/decorators

Controllers

컨트롤러는 들어오는 요청(request)를 처리하고 응답(response)를 클라이언트에 돌려주는 역할을 맡는 중심적인 모듈이다. (API).controllers.ts와 같은 파일명으로 작성하게되고, API 디렉토리에 저장하게 된다.

컨트롤러의 목적은 애플리케이션에 대한 특정 요청을 수신하는 것입니다. 라우팅 메커니즘은 어떤 컨트롤러가 어떤 요청을 수신하는지 제어합니다. 종종 각 컨트롤러에는 둘 이상의 라우트가 있으며 다른 라우트는 다른 작업을 수행할 수 있다.

기본 컨트롤러를 만들기 위해 클래스와 데코레이터를 사용한다. 데코레이터는 클래스를 필수 메타데이터와 연결하고 Nest가 라우팅 맵을 만들 수 있도록 한다(요청을 해당 컨트롤러에 연결).

Controller.ts에는 비즈니스 로직은 포함되어있지 않고, 실질적인 로직은 Service에 담긴다. 따라서 express에서의 route설정과 동일한 역할을 하게된다. 그렇기 때문에 해당되는 route에 적절한 함수(비즈니스 로직)을 call하는 역할만을 수행한다.

Controller 템플릿 생성 & 기본 형식

nest g resource [name]

다음과 같은 명령어를 통해서 Controller의 템플릿 파일을 생성할 수 있다.  위 명령어를 사용해서 생성하게 되면 `name.controller.ts`과 같은 형식으로 파일이 새로 생성된다. 내부는 클래스로 선언된 기본 파일이 만들어진다.

## Routing
예제를 통해서 라우트를 생성하는 방법을 알아보도록 하자. 기본 컨트롤러를 정의하기 위해서는 `@Controller()`과 같은 데코레이터를 사용해야한다. 이전에 공부했던 내용처럼 `@Controller()`과 같이 경로(path)를 지정하지 않으면 기본적으로 `/(루트 경로)`를 통하는 요청을 수신하게 된다. 따라서,컨트롤러 데코레이터에 지정한 경로를 새로 지정하지 않고, API 계층화를 성립시킬 수 있다.

코드를 통해 살펴보자.

```ts
import { Controller, Get } from '@nestjs/common';
import { UsersService } from './user.service';
@Controller('user')
    export class UsersController {
         constructor(private readonly usersService:UsersService){ }
    @Get()
    findAll(): Promise<UserEntity[]> {
        return this.usersService.findAll();
    }

위 코드를 살펴보면 Controller라는 데코레이터로 user라는 라우트를 설정하고 있으며, 거기에 오는 GET HTTP Verb에 대한 응답을 지정하고 있다. contructor를 이용해서 UsersService를 초기화 시켜주고, 내부에서 해당 로직을 사용할 수 있도록 하고 있다. findAll() 내장 메서드를 사용하게 되면, 요청 핸들러가 자바스크립트 객체 또는 배열을 반환할 때 자동으로 JSON으로 직렬화된다. 그러나 자바스크립트 기본 타입(string, number, boolean)을 반환하면 Nest는 직렬화를 시도하지 않고 값만 되돌려보낸다. 이렇게하면 응답처리가 가볍게 처리된다.

응답의 상태코드를 별도로 지정해두지 않으면 성공 코드로, POST 요청의 경우에는 201을 되돌려주고 나머지는 기본적으로 200만을 되돌려준다. 핸들러 수준에서 @HttpCode(...) 데코레이터를 활용하면 이 동작을 변경해줄 수 있다. @HttpCode()나 기타 데코레이터들을 아래에서 다루도록 하자.

요청 객체(Request object)

핸들러는 종종 클라이언트 요청 세부정보에 액세스할 수 있어야 한다. Get 요청이든, Post 요청이든 서버에 요청이 올 때 내부에 딸려오는 토큰이나 데이터를 가지고 자격권한을 판별해야하니까. Nest는 Express 기반이기 때문에 기본적으로 요청객체 접근이 가능하다. 핸들러의 시그니처에 @Req() 데코레이터를 추가하면 Nest에 주입하도록 지시하고 이를 통해서 요청객체에 접근할 수 있다. 단 사용하기 이전에 @types/express패키지를 미리 설치해줘야 한다.

함수 시그니쳐란?

함수 시그니처 혹은 메서드 시그니처는 컴파일러가 함수를 구분하기 위한 구성요소라고 한다. 쉽게 말하면 두 가지 다른 함수가 있을 때 이 함수의 구분점이 되는 요소들을 말한다.

• 1. 함수의 이름(함수명)
• 2. 매개변수(Parameter)의 개수
• 3. 매개변수의 타입(Types)
• 4. 반환 타입(Return Type)

import { Controller, Get, Req } from '@nestjs/common';
import { Request } from 'express'; // 요청객체 express에서 가져오기

@Controller('user')// 경로 접두사
export class CatsController {
  @Get() // 요청 라우트
  findAll(@Req() request: Request): string {
    return 'This action returns all users';
  }
}

위의 코드를 살펴보면, express의 기본 타입 패키지에서 Request라는 요청객체를 가져온 것을 확인할 수 있다. 핸들러 내부의 매개변수로 Request타입을 전달함으로서, 컨트롤러 내부에서 요청객체에 접근해서 데이터를 조작할 수 있다. 조작이라기보다는 내부 데이터를 가공해서 어떻게 사용할지를 정하는 과정이겠지만.. 이것을 다시 Service 비즈니스 로직에 필요한 내용들을 분리해서 매개변수로 전달하면 요청객체 내부에 딸려온 데이터나 헤더같은 것을 통해서 다양한 기능을 구현할 수 있다.

요청객체(Request)

요청객체는 HTTP 요청 자체의 메타데이터를 나타낸다. 쿼리 문자열(?=&), 매개변수, HTTP 헤더, 본문에 대한 속성 값을 포함단다. 대부분 이러한 속성을 직접 잘라낼 필요는 없다. @Body나 @Query()같은 데코레이터가 미리 준비되어있다! 요청객체에 대한 부분만 좀더 세부적으로 나타내면 좋을 듯 하다.

요청객체 관련 데코레이터

• @Req(), @Reqest() 요청객체 전체를 가져오는 데코레이터, 이를 통해서 express의 req인자의 방식으로 요청객체에 접근할 수 있다.
• @Res(), @Response() 응답객체 전체를 가져오는 데코레이터, 이를 통해서 express의 res인자의 방식으로 응답객체에 접근할 수 있다.
• @Next() 핸들러 처리에서 미들웨어로 사용하기 위해서 다음 콜백을 지정하는 데코레이터다. express의 커스텀 미들웨어의 맛만 봤지만, nestjs에서 미들웨어를 작성하는 방법은 생각해본적이 없지만 공부해보면 좋을 듯하다.
• @Session() 핸들러에서 요청객체 내부에 있는 session을 가져오는 데코레이터, 이를 통해 express의 req.session에 접근하는 방식과 동일하게 접근이 가능하다.
• @Param(key?: string) req.params, req.params[key] 와 같이 전달인자에 접근하는 방식이다.
• @Body(key?: string) req.body, req,body[key]와 같이 바디값에 접근하는 방식이다.
• @Query(key?: string) req.query, req.query[key]와 같이 쿼리문자열에 접근하는 방식이다.
• @Headers(name?: string) req.headers, req.headers[name]와 같이 헤더에 접근하는 방식이다.

Resources

이전에는 GET 라우트를 통해서 users 리소스를 가져오는 엔드포인트를 정의했다. 일반적으로 서버 측에 새 레코드를 생성하는 엔드포인트도 제공하려고 한다. 이를 위해 POST 핸들러도 정의해보도록 하겠다.

import { Controller, Get, Post } from '@nestjs/common';
import { UserEntity } from './entity/user.entity';
import { UsersService } from './user.service';
@Controller('user')
    export class UsersController {
         constructor(private readonly usersService:UsersService){ }
    @Get()
    findAll(): Promise<UserEntity[]> {
        return this.usersService.findAll();
    }
    @Post()
    createUser(): Promise<UserEntity[]> {
         return this.usersService.createNewUser(); 
    }

위와 같이 간단하게 작성해볼 수 있을 것 같다. Nest는 모든 표준 HTTP 메소드에 대해 데코레이터를 제공한다. @Get(), @Post(), @Delete(), @Patch(), @Options(), @Head(), @All() 이를 통해서 express에서 구성했던 엔드포인트를 간단하게 경로 중복코드없이 작성할 수 있다.

Route wildcards

패턴 기반 라우트도 지원된다. 별표(*)는 와일드 카드로 사용되며 모든 문자조합과 일치한다.

@Get('ab*cd')
findAll() {
    return 'This route uses as wildcard';
    }

'ab*cd' 라우트 경로는 abcd, ab_cd, abecd 등의 라우트 경로와 일치한다. ?, +, * 및 () 문자는 라우트 경로에 사용될 수 있으며 해당 정규표현식 대응 부분의 하위집합이다. 하이픈(-)과 점(.)은 문자열 기반 경로로 문자 그대로 해석된다.

Status Code

위에서 나왔던 내용인데, 201로 POST 요청에 대한 응답하는 것을 제외하곤 모든 응답 상태코드는 기본적으로 200이다. 핸들러 레벨에서 @HttpCode(${status code})데코레이터를 추가해서 이러한 동작을 쉽게 변경할 수 있다.

import { HttpCode } from '@nestjs/common';

...코드 생략...

@Post()
@HttpCode(204)
create() {
  return 'This action adds a new user';
}

종종 상태코드는 정적이 아니지만 다양한 요인에 따라 달라진다. 응답(@Res()를 사용하여 주입)객체를 사용할 수 있다.

Headers

커스텀 응답헤더를 지정하려면 @Headers() 데코레이터 또는 라이브러리별 응답객체를 사용할 수 있다. (그리고 비즈니스 로직에서는 res.header()을 직접 호출해서 사용한다.)

@Post()
@Header('Cache-Control', 'none')
create() {
  return this.usersService.createUser()
}

Redirection

응답을 특정 URL로 리디렉션 하려면 @Redirct() 데코레이터 또는 라이브러리별 응답객체를 사용할 수 있다. (그리고 비즈니스 로직에서는 res.redirect()를 직접 호출해서 사용한다.) @Redirect()는 url과 statusCode라는 두개의 인수를 취하며 둘 다 선택사항이다. 생략된 경우는 기본적으로 statusCode의 기본값은 302(Found)이 된다.

@Get()
@Redirect('https://nestjs.kr', 301)

가끔 HTTP 상태코드 또는 리디렉션 URL을 동적으로 확인해야 할 수 있다. 다음과 같은 형태로 라우트 핸들러 메서드에서 객체를 반환하면 된다.

{
  "url": string,
  "statusCode": number,
}

반환된 값은 @Redirect() 데코레이터에 전달된 모든 인수를 재정의한다. 예를 들면

@Get('docs')
@Redirct('https://docs.nestjs.com', 302)
getDocs(@Query('version') version) {
  if(version && version === '5') {
    return { url: 'https://docs.nestjs.com/v5/' };
  }
}

Route Parameters

요청의 일부로 동적데이터를 수락해야 하는 경우 정적 경로가 있는 라우트가 동작하지 않는다. (예: GET /users/1은 ID가 1d인 user data를 가져온다.). 매개변수가 있는 라우트를 정의하기위해서 라우트 경로에 라우트 매개변수 토큰 tokens을 추가하여 요청 URL의 해당 위치에서 동적값을 캡처할 수 있다. 아래 @Get() 데코레이터 예제의 경로 매개변수 토큰은 이 사용법을 보여준다. 이렇게 선언된 라우트 매개변수는 @Param() 데코레이터를 사용하여 액세스할 수 있으며, 이는 메소드 시그니처에 추가되어야 한다.

@Get(':id')
findOne(@Param() params):string {
  console.log(params.id);
  return `This action returns a #${params.id} user`
}

@Param()은 메소드 매개변수(Params)를 데코레이팅한다. 라우트 매개변수를 메소드 본문내에서 장식된 메소드의 매개변수의 속성으로 사용할 수 있도록 한다. 코드에서 보듯이 params.id를 참조해서 id 매개변수에 액세스할 수 있다. 특정 매개변수 토큰을 데코레이터에 전달한 다음에 직접 라우트 매개변수를 참조할 수 있다.

@Get(':id')
findOne(@Param('id') id : string): string {
      return `This action returns a #${id} user`;
}

쉽게 말하면 라우트 매개변수에서, @Param()을 전달해서 전체 매개변수를 접근하게 하거나, @Param('id')처럼 특정 매개변수에 직접 접근할 수 있도록 하는 방식이다. 이 방식을 이용하면 parameter를 접근해서, 동적으로 요청마다 다른 값들에 대응해서 핸들러가 작동하도록 할 수 있다.

Sub-Domain Routing

@Controller() 데코레이터는 들어오는 요청의 HTTP 요청의 HTTP 호스트가 특정값과 일치하도록 host옵션을 사용할 수 있다.

@Controller({host : 'admin.example.com'})
export class AdminController {
  @Get()
  index(): string {
    return 'Admin Page';
  }
}

이 부분의 용도가 잘 이해가 가지 않는다.

Scopes

다른 프로그래밍 언어 배경을 가진 사람들의 경우 Nest에서 거의 모든 것이 들어오는 요청에서 공유된다는 사실을 배우는 것은 예상치 못한 일이다. 데이터베이스에 대한 연결 풀, 전역상태의 싱글톤 서비스 등이 있다. Node.js는 모든 요청이 별도의 스레드에서 처리되는 요청/응답 다중스레드 상태 비저장(Multi-Threaded Stateless)모델을 따르지 않는다. 따라서 싱글톤 인스턴스를 사용하는 것은 애플리케이션에 완전히 안전하다.

그러나 컨트롤러 요청 기반 수명이 바람직한 동작일 수 있는 경우가 있다. 예를 들어 GraphQL 애플리케이션의 요청별 캐싱, 요청 추적 또는 멀티테넌시가 있다.

Asynchronicity

우리는 최신 자바스크립트를 좋아하며 데이터 추출이 대부분 비동기적이라는 것을 알고 있다. 이것이 Nest가 비동기(async)기능을 지원하고 잘 작동되는 이유다.

모든 비동기 함수는 Promise객체를 반환해야 한다. 즉, Nest가 자체적으로 해결할 수 있는 지연된 값을 반환할 수 있다. 이것의 예를 보자.

Promise 처리법
@Get()
async findAll(): Promise<any[]> {
  return [];
}

위의 코드는 실제로 동작한다. 또한 Nest 라우트 핸들러는 RxJS 관찰가능한 스트림을 반환할 수 있으므로 훨씬 더 강력하다. Nest는 자동으로 아래의 소스를 구독하고 마지막으로 내보낸 값을 가져온다.

RxJS의 Observable과 Promise의 비교에 대한 내용을 글로 따로 남기자. https://stackoverflow.com/questions/37364973/what-is-the-difference-between-promises-and-observables

Observable 처리법
@Get()
findAll(): Observable<any[]> {
  return of([]);
}

Request payloads

POST 라우트 핸들러의 이전 예제엔 클라이언트 매개변수를 허용하지 않았다. 여기에 @Body() 데코레이터를 추가하여 이 문제를 해결하자.

그러나 TypeScript를 사용하는 경우 DTO(Data Transfer Object : 데이터 전송객체)의 스키마를 결정해야 한다. DTO는 데이터가 네트워크를 통해 전송되는 방식을 정의하는 객체다. TypeScript 인터페이스를 사용하거나 간단한 클래스를 사용하여 DTO 스키마를 확인할 수 있다. 흥미롭게도 여기서 클래스를 사용하는 것이 좋다. 왜냐하면 클래스는 자바스크립트 ES6 표준 기법의 일부이므로 컴파일된 자바스크립트에서 실제 엔티티로 유지된다. 반면 TypeScript 인터페이스는 트랜스 팡리중에 제거되기 때문에 Nest는 런타임에 이를 참조할 수 없다. 파이프와 같은 기능은 런타임에 메타타입에 엑세스 할 수 있을때 추가 가능성을 제공하기 때문에 중요하다.

CreateUserDto

export class CreateUserDto {
  name: string;
  age: number;
  email: string;
}

기본 속성은 세가지로 설정했다. 이름과, 나이, 그리고 이메일 정보만 가지고 있다. 그런 다음 이를 Controller내부에서 import시키면 새로 만든 DTO를 사용할 수 있다.

import createUserDto from './interfaces/createUser.dto';
@Post()
async create(@Body() createUserDto: CreateUserDto) {
  return 'This action adds a new user';
}

Handling errors

오류 처리에 대한 내용은 따로 글을 작성하자!

NestJS

NodeJS 및 Server Side JS를 위한 수많은 우수한 Library와 Helper, Tools가 있지만, 아키텍처 문제를 효과적으로 해결한 라이브러리는 전무하다. 이를 위해서 NestJS 팀은 1.테스트가 용이하며, 2.확장 가능및 느슨한 결합, 3. 유지 관리에 용이한 조건의 웹 서버 라이브러리로서 NestJS를 개발했다. 아키텍처는 Angular로부터 많은 영감을 받았다.

설치 방식

CLI를 통해서 설치한다.

$ npm i -g @nestjs/cli
$ nest new nest_practice

src directory

nest new nest_practice 명령어를 통해서 새로운 Nest App을 구축하면, node_module, src등과 eslint, tsconfig, prettier등 환경 설정과 같은 파일들이 생성된다. 먼저 src 내부 디렉토리 구조를 살펴보자.

src
├ app.controller.ts
├ app.controller.spec.ts
├ app.module.ts
├ app.service.ts
⎣ main.ts

>>- `app.controller.ts`
하나의 경로(root, `/`)를 지닌 기본 컨트롤러
- `app.controller.spect.ts` 
컨트롤러에 대한 `유닛테스트`
- `app.module.ts`
Nest 어플리케이션의 루트 모듈, 모든 Nest모듈은 이 모듈에 `연결`되어있어야 한다.
- `app.service.ts` 
하나의 메소드를 가진 기본 서비스
- `main.ts`
Nest App instance를 생성하는 함수 `NestFactory`를 사용하는, Nest 어플리케이션의 Entry 파일

## Express.js
---
Nest는 Express를 기반으로하고 있기 때문에 기본 Express 서버코드와 비교해보며 알아보는 것이 도움이 될 수도 있다. 아래 코드는 express에서 `controller`와 `router`를 분리해서 사용하는 예시다.

 ```js
//controller.js
export function sayHello (req, res) {
    res.send('Hello World!');
}

// router.js
const router = express.Router();
router.get('/', sayHello);

export default router;

// app.js
app.use('/', router);

//http://localhost:3000/
Hello World!

Nest.js

Controller

Nest에서 Controller는 Express에서의 Router라고 생각하면된다. (Service는 바로 다음에 쓸거다.)

// src/app.controller.ts
import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService){}

  @Get()
  sayHello(): string {
    return this.appService.sayhello();
  }
}

@Controller()는 express의 app.use('/', router)에서 '/'와 같은 역할을 한다. @Controller('say') 이렇게 인자로 string을 넘겨주면 express에서 app.use('/say', router)로 작성한 코드와 동일한 기능을 한다.

AppController 코드를 해석해보면, 루트경로로 GET요청이 들어오면

appService 안의 sayHello 함수를 실행하고 결과를 반환해라

와 동일하게 작동한다. 추가적으로 @Get(), @Post(), @Delete() 등 다른 HTTP 요청 메소드도 동일하게 처리할 수 있는 데코레이터가 있다.

Service

Nest에서 Service는 express에서의 controller라고 생각하면 된다. Nest의 Controller와 비지니스 로직을 분리하기 위해 Service가 존재한다.

import { Injectable } from '@nestjs/common';

@Injectable()
export class AppService {
  sayHello(): string {
    return 'Hello Nest!';
  }
}

위와 같이 메소드를 정의하고 AppModule에서 provider로 등록을 하면 Controller에서 사용할 수 있다.

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';

@Module({
  imports: [],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

HTTP

인터넷 상에서 정보를 주고받는 통신목적으로 사용되는 프로토콜이다. 리소스를 받는 쪽을 클라이언트(Client)가 되고, 리소스를 보내주는 쪽이 서버(Server)가 된다. HTTP에 관련된 내용은 이전에 공부한 이전 글 - 클라이언트와 서버의 통신 HTTP 에서 일부 살펴볼 수 있다. 물론 내용은 불충분하지만, 기초적인 HTTP를 이해하는데 무리는 없다.

HTTP의 약점

HTTP는 사용하기 간편하고, 통신에 적합한 프로토콜이다. 그럼에도 불구하고 모든 통신 프로토콜이 그러하듯 보안과 관련한 몇 가지 약점을 가지고 있는데, HTTP의 약점을 한번 살펴보도록 하자.

• 평문(암호화 하지 않은)통신이기 때문에 도청 가능하다.

• 통신 상대를 확인하지 않기 때문에(인증절차가 없기 때문에) 위장 가능하다.
• 완전성을 증명할 수 없기 때문에 변조 가능하다.

평문이기 때문에 도청 가능하다.

HTTP를 사용한 Request나 Response 통신 내용은 HTTP 자신을 암호화하는 기능은 없기 때문에 통신 전체가 암호화 되지는 않는다. 즉, 평문으로 HTTP 메시지를 보내게 된다.

• TCP/IP는 도청 가능한 네트워크다.

TCP/IP 구조의 통신 내용은 전부 통신 도중에 경로에서 엿볼 수 있기 때문이다. 인터넷은 전 세계를 경유하는 네트워크로 되어있다. 어느 서버와 클라이언트가 통신할 때, 통신 경로 상에 있는 네트워크 기기나 케이블이나 컴퓨터 등을 모두 소유하고 있는 경우는 없다. 다자간의 통신으로 이루어지기 때문에 메시지가 도청당할 수 있다. 통신이 이루어지는동안 지나는 여러 기기들이 있다.

같은 세그먼트의 통신은 네트워크 상에 흐르고 있는 패킷을 수집하는 것으로 도청할 수 있다. 패킷을 수집하려면 패킷을 해석하는 패킷 캡처나 스니퍼라는 툴을 이용한다.

암호화로 도청을 피한다.

현재 통신데이터 도청으로부터 피하기 위해서 여러 방법이 고안되고 있다. 그 중에 가장 보급되어있는 기술이 암호화인데, 암호화에는 몇 가지의 대상이 있다.

1) 통신 암호화

한 가지는 통신을 암호화하는 방법이다. HTTP에는 암호화 구조는 없지만 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)(SSL 신버전이 TLS지만, SSL로 통합해서 부른다.)라는 다른 프로토콜을 TCP/IP 위, 애플리케이션 계층 아래에 조합함으로써, HTTP의 통신 내용을 암호화할 수 있다. SSL 등을 이용해 안전한 통신로를 확립하고 나서 그 통신로를 사용해 HTTP 통신을 한다. 이렇게 SSL을 조합한 HTTP를 HTTPS(HTTP Secure)나 HTTP over SSL이라 불린다.

2) 콘텐츠 암호화

다른 한 가지는 통신하고 있는 콘텐츠의 내용 자체를 암호화해 버리는 방법이다. HTTP에 암호화를 하는 기능은 없기 때문에 HTTP를 사용해서 운반하는 것을 암호화하는 것이다. 즉 HTTP메시지에 포함되는 콘텐츠(바디)를 암호화해버리는 것이다.

물론 콘텐츠 암호화를 유효하게 적용하려면 클라이언트와 서버가 콘텐츠의 암호화나 복호화 구조를 가지고 있는 것이 전제가 되므로, 평상시에 유저가 사용하는 브라우저와 웹 서버에서 이용하는 것은 어렵다. 주로 웹 서비스에서 적용한다.

통신 상대를 확인하지 않기 때문에 위장 가능하다.

HTTP를 사용한 Request나 Response에서는 통신 상대를 확인하지 않는다. Request를 보낸 곳이 정말 URI에서 지정된 호스트인지, Response를 반환한 클라이언트가 진짜 받은 곳인지 HTTP로는 모른다.

누구나 요청 가능!

HTTP에 의한 통신은 상대가 누구인지 확인하는(인증하는) 절차가 없기 때문에 누구든지 요청할 수 있다. 요청이 오면 상대가 누구든지 무언가의 Response를 반환한다.(host나 포트 등에 웹 서버 제한이 없을 경우)

HTTP는 누구이던 간에 요청을 보내면 응답을 무조건 주는 단촐한 구조로 되어있지만, 상대를 확인하지 않는 점이 약점일 수가 있다. 예상되는 약점은 아래와 같다.

• 요청을 보낸 곳의 웹 서버가 원래 의도한 응답을 보내야하는 웹 서버인지 아닌지를 모른다. 가짜 웹 서버 있을 수 있다. 서버 신뢰문제

• 응답을 돌려준 곳이 원래 의도한 요청을 보내는 클라이언트인지 모른다. 가짜 클라이언트일지도 모른다. 클라이언트 신뢰문제
• 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수 없다. 중요한 정보를 불특정한 곳에 돌려보낼 수도 있다. 인증문제
• 어디에서 누가 요청한건지 확인이 안된다. 출처 불분명
• 의미없는 요청도 수신하게 된다. DDos 무분별 공격 우려

상대를 확인하는 증명서

HTTP에서는 통신 상대를 확인할 수 없지만, SSL로 간접적으로 확인할 수 있다. SSL은 암호화뿐 아니라 상대를 확인하는 수단으로 증명서를 제공한다. 증명서는 신뢰할 수 있는 제3자인 인증기관에서 발행하기때문에 서버나 클라이언트의 실존한다는 사실을 증명한다!(AWS SSL 인증 절차 관련 블로깅 필요!) 그 증명서를 위조하는 것은 기술적으로 상당히 어렵다.

이 증명서를 이용함으로써, 통신 상대가 내가 통신하고자하는 서버임을 알려주고, 이용자는 불특정한 곳으로 정보가 누설되는 위험성을 크게 줄일 수 있다.

완전성을 증명할 수 없기 때문에 변조 가능!

완전성이란 정보의 정확성을 의미한다. 그것을 증명할 수 없다는 이야기는 정보가 진짜인지 가짜인지, 정확한지 틀린것이 있는지 알아내기가 어렵다는 뜻이다.

수신한 내용이 다를지도 모른다.

HTTP가 완전성을 증명할 수 없다는 뜻은 만약 요청이나 응답이 발신된 후에 수신할때까지 변조되어도 그 사실을 알 수 없다. 발신된 요청/응답 내용이 중간에 변조된지 확인이 어렵다.

예를 들어, 어떤 웹 사이트에서 콘텐츠를 다운로드했다고하면 내 컴에 다운로드 된 파일과 서버에서 날아오는 파일이 같은건지 알 수없다는 뜻이다. 정말 다른 내용으로 변경되었다해도 나는 그 사실을 파악할 수 없다.

• 현대 운영체제의 기본 요구조건은 프로세스 관리
• 운영체제는 프로세스에게 자원을 할당하고(인터리빙, 세마포어), 프로세스들이 정보를 공유하고 교환, 각 프로세스의 리소스를 다른 프로세스로부터 보호하고, 프로세스들간에 동기화(세마포어) 시킨다.
  • 이러한 요구조건을 만족시키기 위해, 운영체제는 각 프로세스에 대해 그 프로세스의 상태와 리소스 소유권을 표시하고, 프로세스 제어를 가능케하는 자료구조(PCB : Process Control Block, 프로세스 제어 블록)를 유지해야 한다.
• 인터리빙(Interleaving) vs. 동시 수행(execute simultaneously)
  • 병행성
  • 단일 처리기상에서 다중 프로그래밍을 지원하는 경우, 여러 프로세스의 수행은 시간적으로 번갈아 수행, 즉 인터리빙(Interleaving)이 될 수 있다.
  • 다중 처리기상에서는 프로세스 수행이 인터리빙될 뿐 아니라, 여러 프로세스가 동시에 수행될 수 있다.
• 쓰레드 개념의 도입으로 인해 프로세스의 관리가 더욱 어려워졌다.
  • 다중 쓰레드 시스템에서 프로세스는 리소스 소유권에 대한 속성(attribute)를 보유한 반면, 여러 병행수행 스트림(execution stream)의 속성은 한 프로세스 내에서 수행되는 쓰레드의 특성(property)이다.

프로세스 배경지식

컴퓨터 플랫폼은 하드웨어 자원들의 집합으로 구성되어있다. 컴퓨터 프로그램은 어떤 업무를 수행하기 위해 개발된 것인데, 주어진 하드웨어 플래폼 상에서 직접 응용을 작성하는 것은 비효율적이다. 공통 루틴 그리고 리소스 공유를 위해 소프트웨어가 필요해졌다. 그렇기 때문에 이러한 내부 리소스를 보호하는 기법을 필요로 한다. OS는 프로그램이 사용할 수 있는 편리하고, 풍부하고, 안전하고, 일관성있는 인터페이스를 제공한다. OS는 리소스에 대해 균일하고 추상화된 표현을 제공한다. 프로그램은 해당 리소스를 요청하고 접근 가능하다.

프로세스란?

프로세스는 멀티프로그래밍과 시분할 시스템의 메인 컨셉으로, 응용프로그램 실행 모델을 이야기한다. 실행중인 프로그램, 컴퓨터 상에서 실행중인 프로그램의 인스턴스, 처리기에 할당되어 수행될 수 있는 개체(entity), 명령들의 순차 수행, 현재 상태, 연계된 시스템 자원들의 집합 등에 의해 특징지어지는 활성화 단위(a unit of activity) 이 모든 것이 프로세스라고 부를 수 있다. 간단하게 실행중인 프로그램이라고 이해하는 것이 편할 것 같다.

프로세스의 필수 요소

1. 프로그램 코드

동일 프로그램을 수행하는 서로 다른 프로세스들이 공유할 수 있는 부분)

• 그 코드와 연계된 데이터의 집합과 스택(User Stack, Kernel Stack)
• 프로그램이 수행 중 특정 시점에, 프로세스는 여러가지 요소들에 의해 유일하게 식별되어야 한다.

2. PCB(Process Control Block)

• 식별자(Process ID)
• 상태(Process State)
• 우선순위
• 프로그램 카운터
• CPU 카운터
• 메모리 포인터
• 문맥 데이터(Context data)
• 입출력 상태 정보
• accounting data (아이디 & 비밀번호)

PCB의 주요 역할

• 수행하는 프로세스를 인터럽트한 후 나중에 그 인터럽트가 발생되지 않은 것처럼 프로세스 수행을 재개할 수 있도록 충분한 정보를 유지하는 것
• 다수의 프로세스를 지원하고 다중처리를 제공할 수 있게 해주는 주요 도구

  • Context Switching 어떤 프로세스가 인터럽트될 때, 프로그램 카운터 및 처리기 레지스터들(하드웨어의 Context Data)의 현재 값이 해당 프로세스 제어블록(PCB)의 적절한 필드에 저장되고, 그 프로세스의 상태가 (이후 설명될) 블록 또는 준비 등과 같은 값으로 변경

  • OS는 다른 프로세스 선택해서 수행 상태로 만들고, 그 프로세스의 프로그램 카운터와 문맥 데이터를 처리기 레지스터로 적재해서 새로운 프로세스를 수행(CPU는 한번에 한개의 프로세스만 수행한다.)
  • 단일 처리기 컴퓨터에서는 임의 시점에 단 하나의 프로세스만이 수행된다.

프로세스 상태 (수행 / 비수행)

• 프로그램을 실행하기 위해 그 프로그램에 대한 프로세스 또는 태스크가 생성된다.
• 처리기 관점에서 볼 때, 처리기는 프로그램 카운터 레지스터(PC Register)값에 의해 결정된 순서에 따라 명령어들을 수행한다.
• 프로그램 카운터는 시간이 흐름에 따라 다른 프로세스들을 표현하는 다른 프로그램 내의 코드를 가리킬 수 있다
• 개별 프로그램의 관점에서 프로그램의 수행은 자신에 속한 일련의 명령어들을 수행한다.
• 개별 프로세스 행위의 특성은 그 프로세스를 위해 수행되는 일련의 명령어 리스트로 표현한다.
• 이러한 리스트를 프로세스의 trace라고 부른다.
• 처리기 행위의 특징은 다양한 프로세스 트레이스이 어떻게 인터리빙되는지를 보임으로써 표현될 수 있다.

2상태 프로세스 모델

• 상태 종류
  • 수행(Running, 실행)
  • 비수행(Not Running, 비실행)

운영체제란 컴퓨터 하드웨어(입출력 장치, CPU)의 리소스를 관리해주면서 동시에 여러 애플리케이션이 작동할 수 있는 환경을 제공해주는 소프트웨어다.

• OS는 프로그램들이 리소스를 필요로 할 때 필요 리소스를 할당해준다.
• OS는 각각 자원을 할당받은 프로그램들이 서로 엉키지 않고 효율적으로 작동하도록 제어해준다.
• 운영체제(OS)가 하는 일

1. 프로세스 관리
2. 메모리 관리
3. 저장소 관리
4. 보안

운영체제의 부팅과정

컴퓨터의 전원이 나가면 CPU는 ROM에 저장되어 있는 내용을 읽는다. ROM(Read Only Memory)은 컴퓨터에 전원이 나가도 사라지지않는 비휘발성 메모리며, 계속 보관되어야할 정보들을 저장한다. ROM안에는 POST(Power On Self-Test)와 부트로더(Boot Loader)가 저장되어 있다.

POST는 컴퓨터 전원이 켜지면 가장 먼저 실행되는 프로그램으로 컴퓨터에 이상이 있는지 체크하는 프로그램이다. 부트로더(Boot Loader)는 하드디스크에 저장되어 있는 OS 프로그램을 가져와서 RAM에 넘겨준다.

부트로더(Boot Loader)

부트로더란 운영체제가 시동되기 이전에 미리 실행되면서 커널이 올바르게 시동되기 위해 필요한 모든 관련 작업을 마무리하고 최종적으로 운영 체제를 시동시키기 위한 목적을 가진 프로그램을 말한다.

Interrupt(인터럽트)

컴퓨터가 부팅이 되면 OS 프로그램을 실행한 후 사용자의 입력 이벤트를 기다린다. 이 이벤트를 인터럽트라고 한다. 인터럽트가 발생되면 OS는 해당 명령어(Interrupt를 발생시킨) 주소를 기억한다. 그 후 인터럽트가 끝나면 해당 주소로 돌아가 다음 명령어를 수행하거나 대기상태로 돌아간다.

Interrupt(인터럽트)

인터럽트는 말그대로 방해의 의미를 가지고 있다. CPU가 프로그램을 실행하고 있을 때 입출력 하드웨어 등의 장치에 예외상황(에러라던지, 입력이라던지, 출력이라던지..) 다양한 상황에 대해서 CPU가 처리할 수 있도록 중간에 멈추게 한다. 인터럽트가 발생하면 CPU가 수행중이던 작업은 따로 저장하게 되고(CPU 내부 레지스터나 메인 메모리 등), 인터럽트가 발생한 작업을 먼저 수행하게된다. 관련 내용은 나중에 집중해서 쓰도록 하겠다.

운영체제의 구조

운영체제는 DOS 시절부터 꾸준히 발전해왔다. 기본적으로 하나의 CPU는 하나의 작업(Interrupt)만 처리할 수 있다. 따라서 예전에는 하나의 작업이 끝날 때까지 다른 작업은 대기만 하고 있어서 효율이 낮았다.

작업 1, 작업 2를 처리해야 한다. 작업 1이 I/O 자원을 사용한다. 작업 2 대기, CPU 자원 대기 작업 1이 CPU 자원을 사용한다. 작업 2 대기, I/O 자원 대기 작업 2가 I/O 자원을 사용한다. CPU 자원 대기 작업 2가 CPU 자원을 사용한다. I/O 자원 대기

멀티 프로그래밍(Multi-Programming)

이러한 문제를 해결하기 위해 생긴 방법론이 멀티 프로그래밍 원리다. 멀티 프로그래밍의 기본 개념은 입출력을 수행하고 있는 경우, 다른 작업에 CPU를 할당해서 처리하도록 한다. 반대로 CPU가 작업을 하고 있는 경우, 입출력 장치들을 대기 상태로 만들어서 입출력이 필요한 작업에게 입출력 리소스를 할당한다.

작업 1, 작업 2를 처리해야 한다. 작업 1이 CPU 자원을 사용한다. 작업 2가 I/O 자원을 사용한다. 작업 1이 I/O 자원을 사용한다. 작업 2가 CPU 자원을 사용한다.

멀티 태스킹(Multi-tasking)

기술이 발전하면서 프로세서의 처리 속도가 더욱 빨라졌는데 역설적으로 C프로세서의 낭비가 더욱 커졌다. 그 이유는 프로세서의 처리 속도의 발전 속도를 입출력 장치가 따라가지 못해서 프로세서의 낭비가 더욱 커지게 된다.

작업 1, 작업 2를 처리해야 한다. 작업 1에게 CPU 자원 할당, 작업 2에게 I/O 자원 할당 작업 1를 완료하여 CPU 대기, 작업 2 처리 중 (이때, 작업 2가 처리될 때까지 CPU는 대기 상태여서 자원 낭비 발생)

이러한 문제를 해결하기 위해 나온 개념이 멀티 태스킹(Multi-tasking)이다. 멀티 태스킹은 각각에 작업들에게 자원 할당 시간을 정해줘서 그 시간이 지나면 다른 작업들에게 자원을 넘겨준다. 이때, 각 자원들에게 시간을 할당하는 것이 스케쥴링이고 Job 스케쥴링과 CPU 스케쥴링이 있다.

운영체제 원리

운영체제는 interrupt-driven방식으로 사용자의 요청(Event 혹은 Interrupt)이 발생하면 운영체제는 적절하게 자원(CPU, I/O, 메모리 등)을 분배하여 그 요청을 처리하는 구조이다.

Interrupt에는 크게 두 가지가 있다. H/W interrupt와 S/W interrupt가 있다. H/W interrupt는 I/O, 메모리, CPU와 관련된 interrupt이고 S/W interrupt는 프로그램이 실행되다가 발생될 수 있는 Errors, 운영체제 Services들에 대한 요청인 System Call이 있다. S/W interrupt는 잘못 처리하면 한 작업이 자원을 계속 점유하거나 컴퓨터의 동작을 크게 저해할 수 있기 때문에 여러 방법을 써서 이를 예방해야 한다.

그 첫 번째로 Dual-Mode Execution이다. 운영체제는 기본적으로 사용자에게 인터페이스를 제공하는 User Mode와 기기들을 직접 관리하는 Kernel Mode로 구분된다. Kernel에서의 작업은 컴퓨터의 중요한 부분에 해당하는 작업이기에 사용자가 직접 작업하다가 문제가 생길 시 컴퓨터 전체에 영향을 끼치기 때문에 User Mode와 Kernel Mode로 나눠 사용자가 접근하지 못하게 한다.

사용자가 User Mode에서 작업을 명령하면 Kernel Mode에서 이를 처리해야하는데 그 연결고리 역할을 하는 것이 바로 Mode-Bit이다. 운영체제는 User mode에 들어온 명령어와 일치하는 Mode-Bit을 가진 Kernel Mode의 명령어를 찾아 Kernel에서 실행한 후, 그 결과를 User-Mode에 넘기고 일을 마무리한다. 이러한 행위를 System Call이라 한다.

두 번째로 Timer가 있다. Timer는 말 그대로 프로세스들에게 유효 시간을 부여하여 그 시간이 지나면 프로세스를 종료시켜 Error가 발생하여 작업이 멈추더라도 CPU를 계속 점유하는 것을 방지한다.

프로그래밍 패러다임

패러다임이라는 것은 일종의 생각이나 사고의 틀이라고 생각하면 된다. 그동안 패러다임의 전환과 같은 다양한 광고카피를 봐왔지만 패러다임이라는 용어에는 익숙해지지 못했던 것 같다. 그래서 위키를 찾아 간단하게 정리해보고자 한다.

패러다임

한 시대의 사람들의 견해나 사고를 근본적으로 규정하고 있는 인식의 체계. 또는, 사물에 대한 이론적인 틀이나 체계. 순화어는 `틀'.

이를 통해 간단하게 생각해보자면 프로그래밍 패러다임이라는 것은 프로그래머가 어떤 관점에서 코드를 작성할 지를 결정하는 하나의 틀이라고 생각하면 된다. 코드를 어떤 생각을 가지고 작성하는지에 관한 문제라고 생각한다. 가장 근대에 와서는 명령형 프로그래밍그리고 선언형 프로그래밍 이 두가지 패러다임이 가장 메인스트림의 형태를 띠고 있는 패러다임이다.

명령형 프로그래밍

명령형 프로그래밍은 기본적으로 코드를 작성하는 것이 원하는 결과를 달성해나가는 과정에만 중심을 두는 프로그래밍 패러다임이다. 그렇기 때문에 무엇(What)을 달성할 것인지 나타내는 것보다 어떻게(How)할 것인지를 설명하는 사고에 가깝다. 간단하게 예제 코드를 만들어보자.

var str = '111111211111'
let answer = ''
var target = '2'

for(let i = 0; i < str.length; i++){
  if(str[i] === target){
        answer += '1';
      } else {
         answer += str[i] 
    }
}

위의 코드는 str이라는 대상 문자열에서 2라는 타겟을 찾아 1로 바꾸어 만들어주는 과정을 담고 있다. 중간 중간 target이나 answer등의 변수명을 통해서 목적의 방향성을 이야기하지만, 코드만 한번 보고 목적을 파악하는 것은 어렵다. 따라서, 최종적으로 어떤 목적을 두고 프로그래밍을 한 것인지에 대한 것을 주석으로 남겨두어야 코드를 쉽게 읽을 수 있다.

선언형 프로그래밍

그렇다면 선언형 프로그래밍은 어떨까? 선언적 프로그래밍은 명령형 프로그래밍과 다르게 달성하는 세세한 과정(How)보다 목표한 바가 무엇이고, 어떻게 이루어지는지 결과(What)에 대한 것을 중심에 두는 프로그래밍 패러다임이다. 그렇기 때문에 세부적인 과정은 간략화되어 과정보다 결과물에 좀더 집중한 결과물을 만들 수 있다. 이번엔 선언형 프로그래밍의 예시 코드를 살펴보자.

var str = '111111211111'
1. str[str.indexOf('2')]='1'
2. str.replace('2','1')

위에서 하나하나 살펴보며 찾아서 무엇을 바꿀지에 대한 것을 일일히 명령해줬다면, 해당 과정을 간략화된 단어 몇개로 코드가 어떻게 어떤 결과물을 만들어내는지 직관적으로 이해할 수 있다. 이건 새로운 명령을 만들지 않고, 추상화되어있는 일련의 과정을 사고로 결과물을 만들어내는 코드로 구성되어있다. 두 가지 방법을 각각 간단하게 보면 첫번째는 '2'의 인덱스를 찾아서 해당 인덱스의 값을 '1'로 바꾸어준다.가 되고, 두번째는 '2'라는 문자열을 찾아서, '1'로 바꾸어준다.라는 방식으로 주석도 없이 간결하게 코드를 이해할 수 있다.

그렇다면 함수형 프로그래밍이란?

함수형 프로그래밍이란 선언형에서 뿌리를 뻗어나온 패러다임인데, 말 그대로 함수가 프로그래밍 전반의 중심이 되도록 하는 패러다임이다. 위의 선언형 프로그래밍을 보면 JavaScript 내장 메서드를 이용해서 연산이 이루어지고 있다.

indexOf('2')메서드는 때려죽여도, 문자열 내부의 2의 index값만 가져올 것이고, replace('2','1')는 미친듯이 때려도 처음 만난 2의 값을 1로 바꾸기만 할 것이다.

함수형 프로그래밍이란 함수의 기능은 본연의 기능으로 유지하면서, 작성하는 프로그래밍 패러다임이다.

함수형 프로그래밍의 컨셉

1. 변경 가능한 상태를 불변상태(Immutable)로 만들어, SideEffect를 없애자.

어렸을 때 수학책에서 봤던 함수를 살펴보면 f(x) = y 뭐가 들어가든 같은 결과가 나오게끔 만들어진다. 위의 함수는 x를 넣으면 때려죽여도 y값만 출력하게된다. 여기서 중요한 것은 함수 내부의 상태는 어떤 상황에서도 유지되고 결과값은 항상 동일해야 한다는 것이다. 내부에 어떤 상황도 만들지 않기 때문에 결과예측이 틀리는 경우는 없다.

//순수함수
function func1(a,b){
 return a+b; 
}
--------------------------

state ='add';

function func2(a,b){
  //상태에 따른 결과값 변경
  if(state === 'add'){
    return a+b;
  } else {
       return a-b; 
  }
}

위의 코드를 보면 명확하게 알 수 있다. 첫번째 함수는 어떤 외부 상황이나 내부 상황에 의해서 값이 변동되지 않고 동일하게 두 전달인자의 합만을 반환한다. 하지만 두번째 함수는 외부의 state 혹은 내부의 상황에 따라서 a+b 혹은 a-b를 출력한다. 함수형 프로그래밍의 가장 핵심은 외부에 영향을 받지 않고, 상황에 따라 변동하지 않는 순수함수가 되어야한다는 것이다. 순수함수에 대한 이야기는 다음에 담도록 하겠다.

SideEffect

Side Effect란, 본래 의도와 다르게 다음과 같은 변화 혹은 변화가 발생하는 작업을 말한다.

• 변수의 값이 변경됨
• 자료 구조를 제자리에서 수정함
• 객체의 필드값을 설정함
• 예외나 오류가 발생하여 실행이 중단됨
• 콘솔 또는 파일 I/O가 발생됨

2. 모든 것은 객체이다.

함수형 프로그래밍에서 모든 것은 객체다. 클래스 외에 함수 또한 객체이기 때문에 함수를 값으로도 할당할 수 있고, 파라미터로 전달 및 결과 값을 반환할 수 있다. 위 3가지를 모두 지키는 객체를 1급 객체라고 한다. 함수형 프로그래밍 언어에서는 위 3가지 조건을 모두 만족 시켜 1급 객체가 된다. 1급 객체에 대한 것도 다른 글로 남기겠다.

3. 코드를 간결하게 하고, 가독성을 높여 로직에 집중시키자.

Lambda 및 Collection, Stream과 같은 API를 통해 보일러 플레이트를 제거하고, 내부에 직접적인 함수 호출을 통해 가독성을 높일 수 있다. 일을 위한 일이 줄어 실제 구현할 로직에만 집중할 수 있다.

4. 동시성 작업을 보다 쉽고 안전하게 구현하자.

위에 설명한 immutable 값을 사용해, 여러 쓰레드에서 접근을 하더라도 SideEffect가 발생하지 않는다. 또한 Lock이나, UnLock같은 보호장치도 필요하지 않다.

마치며

기본적으로 함수형 프로그래밍 언어인 JavaScript를 통해 여러 경험을 할 수 있었다. 내가 원하는 결과를 만들어 내기위해서 중간에 진행해야했던 많은 명령형 코드들을 추상화시켜서 가볍게 만들 수 있었고, C++이나 C언어를 할때와는 다르게 편리성을 크게 느끼기도 했다. 그런만큼 여전히 이전 언어에서 사용하던 불필요한 과정들을 자꾸만 해서 코드가 가독성이 떨어지고, 결과 예측이 어렵게 되고 하던 다양한 과정을 느꼈다. JavaScript를 좀 더 자세하게 공부해서 함수형 프로그래밍, 즉 만들어진 바퀴를 어떻게 더 잘 활용할 것인가를 지속적으로 고민해야된다.

이렇게 글을 쓰고나니 이전에 공부한 것들을 적던 때랑은 또 다르게 느껴진다. 이런 글들이 쌓여 언젠가 내 무기가 될 것이라고 생각하니 타자를 치는 손이 훨씬 가볍게 느껴진다. 물론 쓰면서 100% 이해되지 않은 부분도 많지만, 공부해나가다보면 언젠가 확실히 이해해서 다른 사람에게도 명쾌하게 설명할 수 있지 않을까? 물론 코드스테이츠를 하면서 공부했던 부분들도 있어서 이해가 조금 더 쉽긴했지만 아직 가야할 길이 멀게만 느껴진다. 힘내자.

SQL (Structured Query Language)

SQL은 RDBMS에 저장된 데이터와 통신하기 위해 필요한 프로그래밍 언어다. SQL문법은 영어와 유사하게 만들어져서 쉽게 읽고 쓰고 해석할 수 있다.

SQL 명령어

1. DML(Data Manipulation Language) : 데이터 조작어

데이터 조작어는 데이터베이스 사용자 또는 응용 프로그램 소프트웨어가 컴퓨터 데이터베이스에 대해 데이터 검색, 등록, 삭제, 갱신을 위한, 데이터베이스 언어 또는 데이터베이스 언어다. 2007년 현재 가장 대중적 데이터 조작 언어는 SQL 데이터 조작 언어이다. SQL은 관계형 데이터베이스에 대해 검색 및 업데이트 등의 데이터 조작을 위해 사용된다. 데이터베이스 사용자가 사용하는 언어다.

(1) SELECT

DB에 있는 데이터를 조회하거나 검색하기 위한 명령어. RETRIEVE 라고도 부름.

(2) INSERT

DB에 데이터를 삽입할때 사용하는 명령어.

(3) UPDATE

DB에 있는 데이터를 갱신(내용 변경)할 때 사용하는 명령어.

(4) DELETE

DB에 있는 데이터를 삭제할 때 사용하는 명령어.

2. DDL(Data Definition Language) : 데이터 정의어

데이터 정의어는 데이터베이스의 데이터를 정의하는 언어다. DDL은 데이터를 정의하는데, 정의라 함은 데이터베이스의 객체들을 정의하는 것이다. 데이터 베이스 객체는 테이블, 뷰, 인덱스 (기타 : synonym, sequence, partitioin table)등을 포함한다. 데이터를 정의하기 위해서 객체들을 생성, 삭제, 변경할 수 있다.

(1) CREATE

DB에 새로운 테이블 구조를 생성하기 위한 명령어.

(2) ALTER

DB에 있는 테이블 구조를 변경할 때 사용하는 명령어.

테이블 구조 변경 명령어

• ADD COLUMN : 테이블에 새로운 속성을 추가한다.

  ALTER TABLE 테이블명 ADD(추가할컬럼명, 데이터타입);

• MODIFY COLUMN : 테이블의 속성을 수정한다.

  ALTER TABLE 테이블명 MODIFY(변경할컬럼명, 변경할데이터TYPE);

• DROP COLUMN : 테이블에 속성을 삭제한다.

  ALTER TABLE 테이블명 DROP COLUMN 삭제할컬럼명;

• RENAME TO : 테이블명을 새로운 이름으로 변경한다.

  ALTER TABLE 기존테이블명 RENAME TO 새로운 테이블명;

(3) DROP

DB의 테이블을 삭제할 때 사용하는 명령어.

(4) TRUNCATE

DB의 테이블 내부의 모든 내용을 삭제하는 명령어. 내용만 삭제하므로 구조는 남는다.

3. DCL(Data Control Language) : 데이터 제어어

데이터 제어어는 데이터베이스에서 데이터에 대한 액세스를 제어하기 위한 데이터베이스 언어다. 권한 부여(GRANT)와 권한 회수(REVOKE)등이 있으며, 설정할 수 있는 권한으로는 연결(CONNECT), 질의(SELECT), 자료 삽입(INSERT), 갱신(UPDATE), 삭제(DELETE) 등이 있다.

(1) GRANT문

데이터베이스 사용자에게 사용권한을 부여한다.

(2) REVOKE문

데이터베이스 사용자로부터 권한을 회수한다.

GRANT CONNECT FROM kim62210
GRANT CONNECT, RESOURCE FROM kim62210

(3) 설정 가능한 권한 목록

• CONNECT - DB 또는 스키마에 연결하는 권한
• SELECT - DB에서 데이터를 검색/조회하는 권한
• INSERT - DB에 데이터를 등록할 수 있는 권한
• UPDATE - DB에 데이터를 갱신할 수 있는 권한
• DELETE - DB에 데이터를 삭제할 수 있는 권한
• USAGE - 스키마 또는 함수와 같은 데이터베이스 객체를 사용할 수 있는 권한

4. TCL(Transaction Control Language) : 트랜잭션 제어어

(1) COMMIT

커밋은 트랜잭션 처리가 정상적으로 종료되어 트랜잭션이 수행한 변경 내용을 데이터베이스에 반영하는 연산. 내용을 변경한 트랜잭션이 완료되면 그 트랜잭션에 의해 데이터베이스는 새롭게 저장된다. 이 상태는 시스템 오류가 발생하더라도 취소되지 않는다.

(2) ROLLBACK

롤백은 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성이 깨졌을 때, 트랜잭션이 만든 모든 변경상황을 취소하고 이전 상태로 되돌리는 연산

(3) SAVEPOINT

세이브포인트는 현재의 트랜잭션을 작게 분할하는 명령어다. 저장된 SAVEPOINT는 ROLLBACK TO SAVEPOINT를 이용해서 지정한 곳까지 ROLLBACK할 수 있다. 여러개의 SQL문을 수반한 트랜잭션의 경우, 사용자가 트랜잭션 중간단계에서 SAVEPOINT를 지정할 수 있다.

주의사항

세이브포인트를 만들고 COMMIT 연산을 하게되면 커밋 연산 이전에 만든 세이브포인트들은 모두 날아간다. 세이브포인트는 한 트랜잭션에 여러개가 있을 수 있다.

데이터베이스시스템은 데이터베이스를 효과적으로 관리하기 위한, 많은 데이터를 효율적으로 관리하고 지원하기 위한 소프트웨어라고 일전에 공부했다. 데이터베이스시스템 통칭 DBMS는 사용자로 하여금 데이터를 추가,삭제,갱신,삽입하더라도 데이터베이스 전체의 통일성(원자성)이 깨지지 않도록 해주며, 데이터 추상화로 데이터 접근성을 높이고 계속적인 관리로 기존 데이터와의 불일치성이 나타나지 않도록 균일하게 관리해주는 일종의 데이터 관리 프로세스라는 것을 배웠다. 지금부터는 DBMS의 구성요소, DBMS의 언어외 기타 다양한 것들을 톺아보도록 하자!

데이터베이스 언어

DBMs는 사용자들이 데이터베이스에 원하는 바(View)를 표현하기 위해 데이터베이스 언어를 제공한다. SQL(질의어), QUEL(미적분학..머시기..), 관계대수 등의 데이터베이스 언어가 제안되고 상용 DBMS에 구현되어있다. SQL이 현대에서는 짱먹었지만, SQL에 다양한 것이 있다. 이후에 데이터베이스 언어인 SQL을 다루도록 할 때 상세히 다루도록하고 이런 언어가 있다 정도만 알고 넘어가야겠다.

SQL 예제

1. sID 2222인 학생의 이름을 찾자!

   SELECT name
   FROM student
   where sID = '2222';

2. sID가 2222인 학생이 듣고있는 교과목을 찾아보자!

   SELECT subject 
   FROM student
   where sID = '2222';

위의 SQL은 간단하게 나타내 본 예제다. DB응용 애플리케이션은 SQL이라는 언어를 이용해서 개발한다. 일반적으로 SQL에 프로그래밍 요소를 추가하는 방식 또는 SQL API를 이용해서 진행한다.

데이터베이스 관리 시스템 구성 요소

데이터베이스 관리 시스템(DBMS)는 아주 복잡하고 방대한 소프트웨어다. 상용에 쓰고있는 mySQL, mariaDB, MongoDB 등 다양한 소프트웨어들이 있다. DBMS는 개념적으로 두가지의 구성요소를 가지고 있는데, 첫째는 질의어 처리기, 둘째로는 저장 관리자다.

1. 질의어 처리기
   • 사용자의 질의어(Query)를 처리한다.
   • 데이터 접근 권한을 부여하고 철회한다.
   • 인증 기능을 담당한다.
2. 저장관리자

• 데이터 하단부분을 의미한다.
• 데이터 저장, 검색 역할을 맡는다.
• 파일 구조, index, 트랜잭션 관리 등을 맡는다. 1) 데이터베이스 관리 2) 데이터 사전(metadata) 관리

Metadata(데이터 사전)

DBMS는 사용자가 저장하여 관리하고자하는 DB 외에도 DB에 대한 데이터를 관리한다. 데이터베이스 관리 시스템에서는 메타 데이터(즉, 데이터를 설명하는 데이터)를 저장하는 장소를 데이터 사전이라고 부르며, 데이터 사전에는 데이터베이스 스키마에 대한 데이터, 제약조건에 대한 데이터, 접근 권한에 대한 데이터 등 다양한 데이터가 관리되고 있다.

트랜잭션 관리

트랜잭션 관리는 DBMS의 주요한 기능이다. 트랜잭션 관리는 동시성 제어와 복구 기능으로 나뉜다.

데이터베이스 시스템의 역사

데이터베이스 기술 시스템에 대한 간단한 역사를 이야기해보자. 50,60년대에는 데이터베이스 이전 단계인 파일 시스템을 이용하여 자료 처리를 했고, 이후 70년대에는 네트워크 데이터 모델과 계층 데이터 모델을 주로 사용했다. 1970년 E.Codd가 관계형 데이터 모델을 처음 제안했는데, 80년대 초에 관계형 모델을 지원하는 상용 DBMS가 처음 출시되고 이후 데이터베이스 기술은 급박하게 발전했다. 80년대 중후반에 객체지향 데이터베이스 시스템에 대한 개념이 생겨서 이후 많은 연구가 이루어졌다.

90년대 중후반에 데이터 보관과 데이터 마이닝에 대한 연구가 이뤄지면서 객체 관계형 데이터 모델이 90년대 후반에 정립되었다. 2000년대에는 XML이 나타나면서 데이터베이스 산업에서는 튜닝 및 자동 데이터베이스 관리 기술이 발전했으며 이를 지원하는 상업 데이터베이스 시스템이 나타났다. 2010년 이후 BigTable, Pnuts, Hadoop(apache)와 같은 대용량 저장 시스템 또는 대용량 분산처리 플랫폼이 개발되어 사용되고있다.

마치며

DBMS에 대한 내용을 간단하게 훑고 넘어간다. 이런 역사가 있고, 이런 구성요소들이 있다는 내용을 빠르게 읽고 습득했다. 차후에 DBMS 혹은 데이터베이스 관련 서적을 구하거나 웹 페이지를 통해서 좀더 학습하고 정리해서 내 머리속에 넣어야겠다. 이전까지 DB, DBMS가 헷갈리고있었는데 어느정도 정리는 된 것 같다. 이후에 mySQL이나 MongoDB같은 DB 플랫폼 Documentation으로 공부해야겠다.

인스턴스와 스키마

데이터 베이스의 인스턴스와 스키마는 데이터베이스 분야에서 사용하는 용어인데, 프로그래밍에서의 변수의 값과 타입(type)에 대응되는 유사한 개념이다. 인스턴스(instance)는 실질적인 데이터 리소스를 이야기하고, schema는 데이터베이스의 구조를 의미하니, 거의 유사한 개념이라고 봐도 될 것 같다.

데이터베이스 스키마는 데이터베이스의 논리적(추상적? 의미적?) 또는 물리적 구조(실질적 데이터)를 의미한다.구체적으로 데이터베이스 모델에 따라서 또한 데이터베이스를 보는 높이에 따라 다르다. 그러나 데이터베이스 스키마는 데이터가 저장되는 공간에 대한 구조를 표현한다는 점에서는 같다. 우선 데이터 스키마가 결정되고 나면 실제 데이터 값이 스키마 형태로 저장하고 관리되는데 데이터의 실질적인 값을 인스턴스라고 부른다.일반적으로 시간이 지나면 데이터베이스의 인스턴스는 계속 바뀌고 수정되지만, 스키마는 시간에 따라서(효율성에 따라서 바뀔 수도 있지만) 대체로 바뀌지 않는 형식이다.

데이터 추상화

일반적으로 컴퓨터과학에서는 추상화가 어떤 사물에 대한 세세한 개체로부터 중요한 개념을 분리하는 프로세스라고 길게 이야기하는데, 어떤 기능 구현을 위해서 필요한 과정들을 하나로 뭉쳐서 핵심을 볼 수 있도록 만드는 과정이다. 저번에는 밥을 먹는 과정을 이야기했지만, 이번에는 조금 컴과틱하게 예시를 들어보겠다.

가령, 정수 100보다 작고, 0보다 큰 숫자들의 모임인 n배열이 있다고 했을 때 n배열을 구해보도록 하자. 그러면 답 n을 구하고자 할때 과정의 중간 단계들이 있을 것이다. 중간 단계가 다음과 같다고 가정해보자.

1. 우선 전체 0에서 100까지의 숫자를 가지고 각각의 숫자들이 소수인지 아닌지 확인해야할 것이다.
2. 확인한 뒤에는 n이라는 배열 변수에 담아주어야 한다.
3. 이후에 이를 출력하는 과정이 필요하다.

가볍게 적어봤다. 작은 문제를 세세히 나누려고 하니 쉽지않다. 여기에서 좀 더 나눠 본다고 하면, 두번째 소수체크 부분이 나누어진다.

** 2. 해당 숫자가 소수인지 확인해야 한다. (isPrime(num)) ** 2-1. target인 num의 제곱근 범위까지 나누어 떨어지는 숫자가 1외에 있는지 확인한다. 2-1-1. 만약 1이외에 숫자가 있다면, false 2-1-2. 1이외에 숫자가 없다면, true

이렇게 세가지 과정이 되면, 중간의 소수인지 확인하는 과정을 따로 묶어 isPrime(num)과 같이 표현할 수 있다. 물론 문제를 해결하려고 할 때 알고리즘을 작성해야하는 것은 마찬가지지만, 소수를 구하는 기능이 되고나면 isPrime이라는 하나의 방법적인 도구가 된다. 이런 식으로 큰 문제에서 떨어져 나온 세부적인 사항들을 묶어서, 단순화 시켜나가는 방식이다. 데이터베이스 역시, 관련된 데이터를 묶어서 연관데이터를 구성할 수 있고, 이를 통해서 특정한 데이터베이스 구축이라는 목표를 달성할 수 있다. 내가 이해한 것이 맞는지는 모르나, 후에 더 공부하다보면 상세히 알게되리라 믿는다. 현실에서의 실눈뜨고 보기랑 비슷해보인다.

데이터 추상화 레벨

데이터베이스 시스템은 데이터베이스에 대한 추상화를 제공하는데, 추상화를 위해 관점(높이 또는 레벨)은 세 가지로 구성되어있다. 데이터베이스는 사실 컴퓨터 내부에는 물리적으로 아주 어렵게 저장되어있겠지만, 세가지 다른 관점에서 편하게 볼 수 있다. 논리적 레벨의 데이터 추상화는 데이터베이스에 저장되어 있는 데이터와 데이터간의 관계를 논리적 관점에서 추상화하는 것이다.

    Type student = record
        ID : string;
        name : string;
        department : string;
        grade : string;
    end;

다음과 같은 스키마를 선언한다고 할 때, student는 하나의 레코드이고, ID(string 타입), name(string타입), department(string 타입), grade(string 타입) 4가지 구성요소로 이루어져있다고 선언하는 것이다.

3단계 추상화

3단계 추상화를 나타낼 때, 위와 같이 나타낸다. 내부 단계를 내부 스키마 혹은 물리적 스키마라고 부르고, 개념 단계를 논리적 스키마 혹은 개념 스키마라고 부른다. 가장 최외곽을 외부 스키마 혹은 뷰 레벨이라고 부르는데, 나눠진 것이 어려운 것이지 이해하면 쉽다.

뷰 레벨에서는 개념 스키마를 이용해서 사용자가 원하는 데이터 조합으로 만들어 낸 뷰를 볼 수 있다. 내가 뽑아내는 방식에 따라 뷰가 달라지기 때문에 조합은 무한에 가깝다.(그래도 조합으로 따지면 범위를 찾을 수는 있겠지만..)논리적 레벨에서는 개략적인 데이터 구조를 보여준다. ID, name, department, grade와 같이 이런 데이터들을 포함하고 있다는 것을 보여준다. 물리적 레벨에서는 추상화는 실제 데이터 레코드가 어떻게 저장되는지를 보여주며, 데이터 필드의 길이, 필드간의 간격길이, 레코드의 전체 길이와 같은 것이 들어가기도 한다.

각 레벨마다 추상화하는 방식은 DBMS마다 좀 다르기도 하지만, 기본적으로 한 데이터베이스에 기반하고 있는 정보들이라는 것이 중요하다. 어찌됐던 스키마와 뷰들이 가르키고 있는 곳은 컴퓨터에 저장되어있는 데이터 베이스 하나다. 데이터베이스에서 3단계 추상화가 성립되면, 추상화에 따라 데이터베이스 스키마를 생성하고, 그 결과 3단계 스키마 구조가 짜여진다. 각 레벨에 따른 스키마는 뷰 스키마, 논리적 스키마, 물리적 스키마로 부른다. 참고로, 3단계 스키마 구조는 1978년에 제안되었고, 일명 ANSI/SPARC 구조라고도 한다. 상용 데이터베이스는 기본적으로 3단계 스키마 구조를 지원하려고 한다.

데이터 모델(data model)

데이터 모델은 데이터, 데이터 관계성, 데이터 의미, 데이터 제약 조건 등을 기술하는 specification 또는 개념적인 도구다. 데이터 모델은 데이터 추상화를 지원하는 도구이며, 우리는 데이터 모델을 이용해서 데이터를 개념화하거나 조작할 수 있다.

데이터 모델의 종류에는 관계형 데이터 모델, 객체지향 데이터 모델, 객체관계형 데이터모델, 네트워크 데이터 모델, 계층 데이터 모델등이 있으며 또한 개체-관계 데이터 모델, XML 데이터 모델 등 다수가 제안되어있다. 네트워크 데이터 모델 및 계층(트리 구조)데이터 모델은 현대사회에서는 더이상 사용되지 않으며 이를 지원하는 구 시스템을 레거시라고 부른다. 상용 DBMS는 위에서 하나를 제공하는데 관계형 데이터모델은 관계형 데이터베이스만을 지원한다. 데이터 모델은 사용자가 데이터베이스를 보는 관점을 나타내기 때문에 데이터 모델이 다른 DBMS은 동일 데이터베이스를 저장/관리해도 서로 완전히 다른 DBMS로 보인다.

Relation 예제

관계형 데이터 모델은 80년대 이후 가장 많이 사용되는 데이터 모델이며, 위의 그림은 관계형 데이터 모델의 기본 요소인 Relation(릴레이션)을 보여준다. 우리가 일반적으로 인지하고 있는 테이블 형식이다. 각 column은 속성을 의미하고, 각 row는 단일 records다.

일단 여기까지만 정리하고 넘어가자. 객체형 데이터 베이스나 NoSQL도 공부해야하고 공부해야할 것이 산더미다..

데이터베이스(DB, Database)는 서로 연관성있는 데이터들의 모임을 이야기한다. 일반적으로 우리가 관심 있는 데이터베이스는 컴퓨터에 저장되어 있는 데이터이며, 또한 데이터 용량이 방대하며 주기억장치에는 저장이 불가능하여 2차저장장치인 하드디스크 또는 플래시 메모리에 저장되는 데이터다.

말그대로 데이터베이스 분야는 대용량 데이터 처리 기술을 연구 및 개발하는 것이 목적이다. 관심있는 데이터 베이스분야는 모두 대용량 데이터이며 정형화 데이터 및 비정형 데이터를 모두 포함하고 있다. 참고적으로 비교적 작은 데이터 처리를 다루는 분야는 자료구조(data structure)이다.

DB? DBMS?

위에 적힌 것처럼 데이터베이스는 연관성있는 데이터들의 모임이다. 데이터베이스는 컴퓨터에 저장되는 데이터의 모임으로 자료량이 어마무시해서 HDD나 SSD에 저장되곤 한다. 컴퓨터에 데이터베이스를 넣어놓기만 하면 어디에 쓸 수 있을까? 데이터를 처리하고 관리하기 위해서 사용되는 소프트웨어를 DBMS(Database Management System)라고 부른다. 한국어로 데이터베이스 관리 시스템이다. DBMS에는 다양한 종류가 있는데, DBMS 혹은 DBS라고 부르기도 한다.

DBMS

DBMS는 사용자에게 데이터를 관리하는데에 필요한 기능들을 제공한다. 기본적으로 데이터를 정의한다던지, 생성한다던지 변경하고 삭제하고 접근하고 조작에 필요한 모든 기본 연산 기능을 제공한다. 또 DBMS는 데이터 추상화(간편하게 부르기!), 데이터 독립성(데이터는 독립되어 저장), 데이터 보호 등의 관리차원에서 필요한 것들도 모두 제공해준다. DBMS는 데이터베이스와 데이터베이스 관리시스템을 통칭하는 말에 가깝다.

그래서? DB가 있으면 뭐가 좋은데?

일단 데이터베이스를 왜 쓰는건지 생각해봐야한다. 예를 들어 20~30명 정도의 데이터를 보관하고 관리한다면 간단한 자료구조들로도 충분히 가능하다. 연결리스트, 해시테이블, 스택, 큐 같은 것들이다. 하지만 수백만에 달한다고하면 단순한 데이터 자료구조만으로는 감당하기 힘들다. 우리나라 국민 전체의 신상데이터를 보관한다고 하면 전체 데이터 용량이 엄청나고, 일반적인 조회방식이나 관리방식으로는 데이터를 관리하기가 현실적으로 어렵다. 그러면 왜 쓰면 좋을까?

사용자 입장에서 데이터베이스 사용 장점

1. 데이터 추상화 제공

데이터를 추상화할 수 있게 도와준다. 추상화라는 의미가 되게 어렵게 다가오는데 기본적으로 중심적인 개념을 가지고 전체 큰 부분을 간략하게 나타낼 수 있도록 하는 것이다.

예를 들어 밥을 먹다.라는 간단한 행동이지만, 세부적으로 따져보면 숟가락을 든다. 숟가락을 밥 위로 이동시킨다. 숟가락으로 밥을 푼다. 숟가락을 그대로 들어올린다. 숟가락을 입으로 이동시킨다. 입을 연다. 숟가락을 입속으로 넣는다.와 같은 어이없이 긴 이야기가 될 수 있다.

밥을 먹는다는 작은 행동을 표현하기 위해 이만큼의 설명이 필요한데, 밥을 먹다라는 두 단어로도 저 과정을 충분히 연상할 수 있다. 데이터도 한 사람에 대한 의료정보라고하면 수많은 내역들이 있는데 이를 응집해서 OOO님의 의료정보식으로 간략하게 추상화시킬 수 있다. 내가 이해하는 추상화는 정보를 하나로 표현할 수 있도록 간략화하는 것에 가깝다. 이후에 추상화에 대한 이야기를 좀 더 적어보겠지만, 우선은 내가 이해한대로 이해하는 것이 좋겠다.

2. 데이터 접근의 용이성 제공

데이터베이스 시스템은 데이터 접근을 위한 언어를 제공하고 편리한 사용자 인터페이스를 제공한다. 만약에 node의 기본 모듈인 fs을 이용해서 데이터에 접근한다고하면 수많은 코드들이 엉기어 읽기 힘들어질 것이다. 파일을 열고, 파일을 연 상태에서 내부 파일에 들어있는 데이터를 받아서 이를 가공하고 다시 데이터 변경 메소드를 사용하고... 과정만 생각해도 복잡하다. 하지만 DBMS라면 SELECT * FROM (TABLE)과 같이 간편하게 데이터를 열람할 수 있다. 수정/삭제도 동일하다.

3. 데이터 중복 및 불일치성에 대한 제어 용이

데이터베이스 불일치성은 데이터 간에 값이 서로 일치하지 않는 현상을 말하는데, 파일 시스템을 사용하면 놓치는 부분이 생겨서 데이터가 온전히 유지되기 힘들다. 실수로 하나라도 놓치거나 하나라도 더 추가하면 원래 데이터와 갱신된 데이터간의 차이가 생기기 시작하고, 어디서 비틀렸는지 찾지 못하면 그 수많은 데이터에서 문제인 부분을 찾아야하니 고깝다. 중복이 생기면 불일치성이 생기고, 하나라도 손실되면 불일치성이 생긴다.

4. 데이터 무결성 제약조건(integrity constraint) 유지 용이

말이 어렵지만, 데이터에는 제약조건이 있다. 님 나이가 몇살이에요?라고 물어보는데 음.. 저는 -33살이요라고 말하는 사람이 어디있을까? 나이에는 예컨데 1살에서 100살 사이와 같은 제약조건이 붙는다. 그런 제약조건이 존재하지 않는 데이터는 없다. 명확성도 떨어질 뿐더러, 데이터가 말하는 바를 이해하기 어렵다. 하지만 이를 수동으로 조작하게 된다면? 혹여 조건문에서 예외케이스를 발견하지 못한다면? 아마 데이터베이스에는 제약조건을 어긴 데이터가 들어갈지도 모른다. 수백만의 데이터가 있다고 생각한다면 매번 이를 정상화 시키기 위한 시간조차도 허비되는 자원이 될지도 모른다.

데이터 관리 측면에서 데이터베이스 사용 장점

1. 갱신 원자성 제공

데이터베이스 시스템에서는 데이터 갱신이 원자적으로(전체가 동일하게) 이루어져야 하며, 이는 데이터 갱신시에 갱신 연산이 부분적으로 데이터베이스에 반영되질 않음을 의미한다. 갱신 연산이 부분적으로 이루어지면 데이터베이스 상태가 불일치되거나 데이터베이스 제약조건이 깨질 수도 있다. 예컨데 나이 조건을 20살 이상으로 변경했다고 치자. 근데 절반의 데이터만 적용되어 갱신되고 나머지가 되지 않는다면? 전체 데이터베이스는 통일성(원자성)을 잃고 무너진다. 제약조건이 깨진 것도 문제고, 데이터베이스 상태가 맛이 간 것이나 다름없다.

2. 다수 사용자의 동시성 제어

데이터베이스 시스템 환경은 다수의 사용자가 동시에 동일한 데이터베이스 시스템 환경에 접근하게 된다. 내가 접속한 곳과, 다른 곳에서 접속했을 때 데이터베이스 상태가 다르다면 문제가 된다. 그렇기 때문에 다수가 사용하더라도 같은 데이터베이스 상태로 제어를 제공할 수 있어야 된다.

3. 데이터 보호

데이터 보호는 다양한 사이버 공격, 혹은 데이터 접근으로부터 데이터를 보호하는 것이다. 데이터베이스는 기본적으로 이러한 데이터 보호 기능을 제공한다. 파일 시스템이랑 계속 비교하는데, 아무래도 데이터를 다루는 것은 동일하니 비교하는 것이다. 데이터베이스 시스템에서 제공하는 것은 데이터만을 위한, 데이터에 의한, 데이터의 보호를 목적으로 만들어진 보호 기능이기 때문에 OS에서 기본적으로 제공하는 보안 기능과는 확연한 차이를 보인다. 이러한 차이는 나중에 알아보자!

데이터 백업 및 회복

데이터가 날아갔다! 그러면 지옥을 경험할지도 모른다. 100만명 분의 데이터가 갑자기 날아갔다면 어떻게 반응해야될까? 아마 깜짝놀래고 키보드 샷건치는 것만으로는 부족하다. 시스템 장애에 의해서 날아갔다면 그것도 나름대로 모니터가 부서지는 일이 벌어질지도 모른다. 기본적으로 DBMS는 히스토리를 이용해서 데이터를 백업해두거나 리스토어 시킬 수 있는 기능을 제공한다.

파일시스템(file System)

일반적으로 운영체제(OS)에 기본적으로 탑재된 기능이다. 유닉스나 리눅스는 fileSystemㅇ이라는 파일시스템을 제공한다. 파일을 읽고, 쓰고, 저장하고, 삭제하고, 열고, 닫고 등의 기본적인 파일 관리 기능을 제공하는 것이다. 데이터베이스 관리 시스템은 이 파일 시스템을 이용한 경우가 대부분인데, 따라서 DBMS는 운영체제의 프로세스 중에 하나다. 파일 시스템으로도 DB관리가 가능하지만, 데이터가 너무 많을 때, 그리고 일일히 OS에서 관리하기 어렵다는 점에서 DBMS에 밀리는 부분이 많다. 알아두자!

네트워크의 사전적 의미는 전선이나 혈관, 통로 등으로 이루어진 망형 조직이다. '네트워크'라는 용어는 방송사 네트워크, 인맥을 의미하는 휴먼 네트워크(Human Network) 등 다양한 의미로 사용하는데, 그 중 가장 많이 쓰이는 의미는 컴퓨터와 컴퓨터를 연결해주는 망이다.

컴퓨터와 컴퓨터를 연결한 네트워크는 이전보다 더 편리한 세상을 만들었다. 네트워크가 보편화되기 전에는 보고서를 제출하려면 직접 하드카피를 인쇄해 전달해야 했지만, 지금은 이메일(Email)이나 웹하드(Webhard), 클라우드(Cloud) 기반의 스토리지(Storage)를 통해 제출하는 것이 일반적인 상황이 되었다. 이처럼 네트워크는 이전과는 비교할 수 없는 편리함을 가져다줬다. 인터넷은 이런 네트워크 응용 서비스의 한 종류라고 할 수 있는데, 스마트폰을 통해 인터넷을 사용할 수 있는 것도 각각의 응용 서비스 모두가 네트워크로 연결되어 있기 때문에 가능한 것이다. 스마트폰에서 사용하는 모바일 네트워크는 WIFI, 4G LTE, 5G 등 무선 통신망을 이용한다.

네트워크를 구축하려면 컴퓨터 간의 연결 규격 즉, 프로토콜(Protocol)이라는 것이 필요하다. 여러 프로토콜 중 가장 대표적으로 널리 쓰이고 또한 인터넷에서 사용되고 있는 TCP/IP에 대해 자세히 알아보자!

TCP/IP

TCP/IP(Transmission Control Protocol/Internet Protocol의 약자)는 컴퓨터 간에 통신할 수 있도록 만든 프로토콜의 하나다. 이 프로토콜에 기반하고 있는 것이 인터넷인데, TCP/IP가 인터넷의 기반 프로토콜로 자리잡은 이유는 하드웨어(Hardware), 운영체제(OS), 접속 매체와 관계없이 동작할 수 있는 개방형 구조이기 때문이다. 원래는 TCP/IP는 OSI(Open Systems Interconnection) 7계층에 포함되는 프로토콜로, TCP/IP는 네 개의 계층으로 이루어져 있다.

원래 OSI 7계층은 네트워킹을 위한 물리적 장비에서 실제 서비스를 제공하기 위한 애플리케이션에 이르는 단계를 계층화한 것을 말한다. 이러한 계층화를 통해, 상위 레벨에서는 하위 레벨에서 구현한 내용을 모르더라도 표준화된 인터페이스를 통해 네트워크 시스템을 개발하고 운영할 수 있다. TCP/IP는 OSI 7계층을 좀더 단순화해서 4계층으로 정의한 것이다.TCP는 데이터의 흐름 관리, 데이터 정확성 확인 등의 역할을 수행하고 IP는 데이터(패킷)을 목적까지 전송하는 역할을 담당한다. TCP/IP는 개방형 구조로서, 특정 운영체제나 하드웨어에 영향을 받지 않고 근거리와 원거리 모두 데이터를 전송할 수 있다.

IP(Internet Protocol)

IP 주소(IP Address)는 TCP/IP로 연결된 네트워크에서 각각의 컴퓨터를 구분하려고 사용하는 주소다. IP 주소는 숫자로 구성되어 있고, '123.123.123.123.'과 같이 네 개로 구분된 10진수를 사용한다. 사용할 수 있는 IP 주소 범위는 다음과 같다.

이론적으로 컴퓨터가 TCP/IP 네트워크에 연결되려면 IP 주소가 있어야 하고, 인터넷에 연결된다면 전세계 모든 컴퓨터에 원격으로 접속할 수 있어야 한다. 하지만 수많은 컴퓨터에 각기 다른 고유한 IP주소를 할당하기에는 한계가 있다. 모바일 인터넷의 급속한 확산과 함께 IP 주소 고갈 문제가 심각해졌다. 그러나 현재는 초기 보다 문제가 어느정도 해결되었다. 네트워크 및 라우터의 발달로 사설 IP를 통해 대부분의 인터넷 서비스를 이용할 수 있게 되었기 때문이다. 따라서 모든 인터넷 클라이언트가 공인IP를 사용할 필요가 없고, 이를 해결하려고 고안된 방안인 IPv6의 보급은 다소 늦춰질 전망이다.

사설 IP는 일반적으로 10.x.x.x, 192.x.x.x 등 몇 가지 IP 블록을 사용하지만, 실제로는 모든 인터넷 IP를 사용할 수 있다. 다만 네트워크 구성상 직접 인터넷에 연결되지 않고 라우터 장비 등에서 제공하는 NAT(Network Access Translator) 기능을 이용해서 접속해야 한다. NAT를 이용해서 공인 IP로 대응하면 인터넷에 접속할 수 있다. 쉽게 생각하면 집에서 사용하는 유무선 인터넷 공유기를 생각하면 된다. 공유기에 연결된 컴퓨터나 스마트폰은 DHCP(Dynamic Host Configuration Protocol)라고 하는 동적 IP 할당 프로토콜에 의해서 사설 IP를 배정받게 되고, 공유기를 통해 인터넷 연결이 관리된다.

인터넷

인터넷 자체는 네트워크 인프라를 의미하고, 우리가 알고있는 WWW, Email 서비스 등은 인터넷 기반의 서비스다. 웹은 인터넷에 기반한 서비스이기 때문에 인터넷과 관련된 기본 기술과 용어, 동작원리들은 잘 이해하고 있어야한다.

인터넷 기반 서비스

인터넷 기반의 대표적인 서비스는 웹(WWW) 이외에도 이메일(Email), FTP, Telnet, DNS, News 등이 있다. 인터넷 초창기에는 웹보다 다른 것들이 주된 서비스였으나, 지금은 웹이 절대적이다. 최근에는 이메일 서비스 조차도 독립적인 사설 웹 서비스 위에 올라가 있다. SNS 서비스가 등장하면서 웹 서비스 위에서 구동되는 서비스는 훨씬 더 다양해졌다. 아래 적혀진 모든 서비스의 프로토콜이 따로 되어있는데 모두 TCP/IP 라는 프로토콜로 물리적으로 연결되어 있다.

프로토콜(Protocol) 프로토콜은 네트워크에 연결된 컴퓨터들간의 통신 규약

물리적인 네트워크 연결은 TCP/IP를 사용하지만, 응용 서비스를 위한 별도의 규격으로 이해하면 된다. 포트는 네트워크 서비스를 접속하기 위한 접점으로 하나의 컴퓨터에서 여러 개의 네트워크 서비스를 제공하는 경우 이들을 구분하기 위한 목적으로 사용한다. 은행에서 입출금, 대출, 신용카드, 보험 등 업무에 따라 창구를 구분해 놓은 것과 같은 개념으로 이해하면 된다. 해당 업무를 처리하지 않는 창구에서는 내가 원하는 서비스를 받을 수 없는 것과 마찬가지로 포트와 프로토콜이 일치하지 않는 경우에는 정상적으로 네트워크 서비스를 사용할 수 없다.

DNS(Domain Name System)

우리나라 국민이라면 다른 사람과 구별되는 고유번호인 주민번호가 있다. 컴퓨터도 마찬가지로 단말기마다 부여된 고유한 번호가 있는데, 그게 IP다. IP주소는 네트워크에서 사용하는 구분 번호다. 그런데, 사람들끼리 이름이 아니라 주민번호로 부르면 얼마나 힘들까? 그래서 만들어진게 도메인 이름 시스템이다. 고유번호에 이름을 만들어줘서 쉽게 구분지을 수 있도록 만든 것이다. www.naver.com, www.google.com 등의 인터넷 주소는 호스트(컴퓨터) 이름(www) + 도메인 이름(google.com)의 형태로 되어 있다. 여기서 도메인 이름은 전 세계적인 관리 체계가 있기 때문에 마음대로 붙일 수는 없고, 도메인을 관리하는 기관이나 업체에 일정 비용을 지불하고 사용할 수 있다.

우리가 일상적으로 사용하는 도메인 이름을 통한 웹 사이트 접속도 겉으로는 보이지 않지만, 내부적으로 도메인 이름을 IP Address로 변환하는 서비스를 이용하는 것이다. 이러한 서비스를 도메인 이름 시스템이라고 부른다.

DNS 처리 과정

1. PC의 호스트 파일에 www.google.com에 대한 IP 주소정보가 있는지 확인한다.

   윈도우 : c:\windows\system32\drivers\etc\hosts 리눅스 : /etc/hosts

2. PC의 DNS캐시에 www.google.com에 대한 IP 주소가 있는지 확인한다.

3. Local DNS에 www.google.com에 대한 DNS query를 보낸다. Local DNS는 내 PC 에 설정되어 있는 네임서버다. 예) 168.126.63.1 (KT DNS), 8.8.8.8 (google DNS) 등

4. Local DNS의 DNS 캐시정보에 www.google.com에 대한 IP 주소가 있는지 확인한다.

5. Local DNS는 Root DNS에 www.google.com에 대한 IP 주소를 요청하는 DNS query를 보낸다.

6. Root DNS는 자신의 ZONE 파일에 정보가 있다면 IP 주소를 응답하고, 없다면 .COM의 DNS 서버 주소를 반환한다.

7. Local DNS는 Root DNS에서 받은 COM DNS에 www.google.com에 대한 IP 주소정보를 요청하는 DNS query를 보낸다.

8. COM DNS는 자신의 ZONE파일에 정보가 있다면 IP주소를 응답하고, 없다면 google.com의 DNS 서버 주소를 응답한다.

9. Local DNS는 COM DNS에서 받은 google.com DNS에 www.google.com에 대한 IP 주소 정보를 요청하는 DNS query를 보낸다.

10. google.com DNS 는 ZONE 파일 정보를 확인하여 IP 주소를 응답해준다.

11. Local DNS는 google.com DNS에서 응답받은 IP 주소를 client에 응답한다. 그러면서 TTL 시간 동안 www.google.com 의 IP 주소를 캐싱한다.

12. client는 Local DNS에서 받은 IP 주소(www.google.com)로 접속 요청을 한다. 그러면서 TTL 시간 동안 www.google.com의 IP 주소를 캐싱한다.

13. www.google.com 서버는 www.google.com 첫 화면을 client에 전송한다.

이전에 브라우저가 리소스를 가져와서 파서를 이용해서 파싱트리를 구성하고, 파싱트리를 컴파일러를 통해서 기계어로 번역하는 과정까지 살펴봤다. 그 과정에서 HTML이라는 마크업 언어는 유연하기 때문에 파싱이 어렵다는 사실까지 알았다. 그렇다면 내부에서 파싱이 일어날때 어떤 알고리즘을 이용해서 이것들을 파싱하게 되는지, 중간에는 어떤 알고리즘을 이용해서 토큰화하는지, 최종적으로는 이런 트리를 어떻게 구성하는지에 대한 알고리즘들을 간단하게 살펴보도록 하겠다.

파싱 알고리즘

HTML은 일반적인 하향식, 상향식 파싱이 안되는데 이전 글에서 살펴본 것과 마찬가지로 문법에 예외 사항이 많이 있다는 이유로 하나로 퉁치기에는 조금 성의가 부족한 것 같아 몇 가지를 살펴보자.

1. 언어의 너그러운 속성, 간혹 태그가 생략되는 경우가 존재한다.
2. 잘 알려져 있는 HTML 오류에 대해서 브라우저에서 미리 필터링을 한다.
3. 변경에 의한 재파싱, 일반적으로 소스는 파싱하는 동안 변하지 않지만 HTMl에서 document.write를 포함하고 있는 스크립트태그는 토큰을 추가할 수 있기 때문에 실제로는 입력과정에서 파싱이 수정된다.

일반적인 파싱 기술을 사용할 수 없기 때문에 브라우저는 HTML 파싱을 위해 별도의 파서를 생성한다. 파싱 알고리즘은 HTML Documentation에 자세히 설명되어 있다. 알고리즘은 토큰화(어휘 나누기)와 트리 구축(구조로 만들기) 이렇게 두 단계로 되어 있다.

토큰화는 어휘 분석으로서 입력 값을 토큰으로 파싱한다. HTML에서 토큰은 시작 태그, 종료 태그, 속성 이름과 속성 값이다.

토큰화는 토큰을 인지해서 트리 생성자로 넘기고 다름 토큰을 확인하기 위해 다음 문자를 확인한다. 그리고 입력의 마지막까지 이 과정을 반복한다.

HTML 공식 문서에 나와있는 파싱 과정이다.(HTML5 명세에 나와있음)

토큰화 알고리즘

알고리즘을 돌고 난후 문서 리소스는 HTML 토큰이 된다. 알고리즘은 상태 기계(State Machine)이라고 볼 수 있다. 각 상태는 하나 이상의 연속된 문자를 입력받아 이 문자에 따라 다음 상태를 갱신한다. 그러나 결과는 현재의 토큰화 상태와 트리 구축 상태의 영향을 받는데. 이것은 같은 문자를 읽어 들여도 현재 상태에 따라 다음 상태의 결과가 다르게 나온다는 것을 의미한다. 알고리즘은 전체를 설명하기에 너무 복잡하니 원리 이해를 도울만한 간단한 예제를 한번 보자.

<html>
   <body>
      Hello world
   </body>
</html>

초기 상태는 "resource state"다. <이 문자를 만나면 '태그 열림 상태'가 된다. a부터 z까지의 문자를 만나면 '시작 태그 토큰'을 생성하고 상태는 태그 이름 상태로 변하는데 이 상태는 >문자를 만날 때까지 유지한다. 각 문자에는 새로운 토큰 이름이 붙는데 이 경우 생성된 토큰은 html토큰이 된다. (일종의 flag 상태 방식을 이용한 알고리즘인 것 같다.)

> 문자에 도달하면 현재 토큰이 발행되고 상태는 다시 자료 상태로 바뀐다. 자료 상태는 토큰화 디폴트 상태값인 것 같다. 태그는 동일한 절차에 따라 처리된다. html과 body 태그를 발행하고 다시 디폴트 상태가 됐다. Hello World의 H 문자를 만나면 문자 토큰이 생성되고 발행된다. 이것은 종료 태그의 <문자를 만날때까지 진행한다. Hello World의 각 문자에 대한 문자 토큰이 발행된다.

이후 진행은 똑같다.

일종의 문자 번역 방식인데, 시작태그(<)와 종료태그(>)를 가지고 토큰 대상에 대한 속성을 정의내리는 방식인 것 같다.

트리 구축 알고리즘

파서가 생성되면 문서 객체가 생성된다.

트리 구축이 진행되는 동안 문서 최상단에서는 DOM트리가 수정되고 요소가 추가된다. 토큰화에 의해 생긴 노드는 트리 생성자에 의해 처리된다. 각 토큰을 위한 DOM 요소의 명세는 정의되어 있다. DOM 트리에 요소를 추가하는 것이 아니라면 열린 요소는 스택(Stack, 임시 버퍼)에 추가된다. 이 스택은 부정확한 중첩과 종료되지 않은 태그를 교정한다. 알고리즘은 상태기계라고 설명할 수 있고, 상태는 삽입모드라고 부른다.

토큰 알고리즘과 마찬가지로 동일한 예제를 통해 살펴보자.

 <html>
   <body>
      Hello world
   </body>
</html>  

트리 구축 단계에서 입력 값은 토큰화 단계에서 만들어진 토큰들이다. 받아온 html 토큰은 html 태그 전 상태에서 읽게 되고, 토큰은 이 모드에서 처리한다. 이것은 HTMLHtmlElement 요소를 생성하고 문서 객체의 최상단에 추가된다.

상태는 head 태그 이전 모드로 바뀌고 body토큰을 받는다. head 토큰이 없어도 HTMLHeadElement는 무조건 생성되어 트리에 추가된다.

이후 head 내부 모드가 되고, 다음은 head 다음으로 바뀐다. body 토큰이 처리되고, HTMLBodyElement가 생서되어 추가되고, body 안쪽 모드가 된다.

Hello World의 문자열의 모든 문자 토큰을 받는데, 첫 번째 토큰이 생성되면 본문 노드가 추가되면서 다른 문자들이 그 노드에 추가된다. body 종료토큰을 받으면 body 다음상태가 된다. 이후 html 종료토큰을 받으면 body 다음 다음모드로 바뀐다. 마지막 파일 토큰을 모두 받으면 파싱이 종료된다.

브라우저의 오류 처리

HTML 페이지에서 "유효하지 않은 구문"이라는 오류를 본 적이 없다. 이는 브라우저가 모든 오류 구문을 교정하기 때문이다. 아래 오류가 포함된 예시를 살펴보자.

<html>  
   <mytag></mytag>
   <div>
     <p>
   </div>
   Really lousy HTML
   </p>
</html>  

1. mytag라는 존재하지 않는 태그명을 사용했다.
2. p태그와 div태그는 중첩되어 있다. 그럼에도 불구하고 정상적으로 파싱이 가능한데, 그 이유는 파서가 HTML 오류를 일부 자동적으로 수정하기 때문이다.

북마크와 이전/다음 버튼 처럼 수 년간 브라우저 안에서 구현되어있는 것이다. 잘 알려진 HTML 오류를 찾을 수 있지만, 브라우저는 다른 브라우저들처럼 관습적으로 오류를 수정한다. 이는 명세에 잘 정리 되어있지만 몇 가지만 짚어보도록 하겠다.

1. 어떤 태그의 안쪽에 추가하려는 태그가 금지된 것일 때 일단 허용된 태그를 먼저 닫고 금지된 태그는 외부에 추가한다. .
2. 파서가 직접 요소를 추가해서는 안된다. HTML, BODY, TBODY, TR, TD, LI같은 태그들은 생략해도 가능하다. .
3. 인라인 요소 안쪽에 블록 요소가 있는 경우 부모 블록 요소를 만날 때까지 모든 인라인 태그를 닫는다. .
4. 이런 방법으로 해결되지 않으면 태그를 추가하거나 무시할 수 있는 상태가 될때까지 요소를 닫는다.

<br> 대신 </br>

인터넷 익스플로러, 파이어폭스의 호환성을 위해서 이것을 대체해서 이해한다. 오류는 내부적으로 처리되고, 사용자에게 보여지지 않는다.

추가내용 기술 예정..

마치며

이번에는 브라우저 내부의 파싱 알고리즘, 토큰화 알고리즘, 마지막으로 트리 구축 알고리즘이 어떤 방식으로 작동하는지에 대해 알아봤다. 기본적으로 모든 파싱과정에서 사용되는 알고리즘들은 특정 문자 혹은 토큰을 flag 현재 상태를 구분하는 구분자 역할로 사용한다.

References

document.write HTML Documentation Naver D2

파서는 이전 글에서 봤듯이, 데이터(문서 파일)이 왔을 때 이것을 컴퓨터가 이해할 수 있게끔 구조를 재구성하는 단계라고 이해하면 되겠다. 파서는 우선 문서가 오게되면 이 문서를 토큰이라는 유효성이 있는 단어 단위로 나누어 분해하고, 이것을 언어구문규칙에 따라 파싱트리로 재생성한다. 결과적으로는 기계어로 바꾸기 직전단계까지의 과정을 파서가 담당하고 있는 것이다. 파서가 파싱을 통해 파싱트리가 완성되면 파싱트리를 가지고 컴파일러는 기계어로 변환하는 작업에 들어간다. 일종의 컴퓨터에서 전처리기의 역할을 브라우저 파서가 맡고 있다고 생각하면 된다.

파싱 예

전에 이렇게 정해진 규칙에 따라서 2 + 3 - 1을 분해하는 과정을 거쳤다. 이 과정에서 의미 있는 어휘들인 연산자 +,-, 그리고 중간에 들어가는 숫자원소들 단위로 나누어 파싱트리의 노드를 구성했던 것을 기억하고 있을 것이다.

여기에서 사용된 어휘 기준(어휘를 나누는 기준)은 수학에서는 표현식의 정수, 기호단위로 나누어진다 라는 것이다.

사용된 구문 조건에는 여러 개가 있을 텐데, 대표적인 것들을 따져보면 다음과 같다.

1. 언어 구문의 기본적인 요소는 표현식, 항, 연산자다.
2. 언어에 포함되는 표현식의 수는 제한이 없다.
3. 표현식은 '항'뒤에 '연산자' 그 뒤에 또 다른 항이 따르는 형태다.
4. 연산자는 더하기 토큰 또는 빼기 토큰이 온다.
5. 정수 토큰 또는 하나의 표현식은 항이다.

입력된 값 2+3-1을 분석해 보자.

규칙에 맞는 첫 번째 부분 문자열은 2이다. 규칙 5번에 따르면 이것은 하나의 항이다. 두 번째로 맞는 것은 2+3 인데 이것은 항 뒤에 연산자와 또 다른 항이 등장한다는 세 번째 규칙과도 일치한다. 입력 값의 마지막 부분까지 진행하면 또 다른 일치를 발견할 수 있다. 2+3은 항과 연산자와 항으로 구성된 하나의 새로운 항이라는 것을 알고 있기 때문에 2+3-1은 하나의 표현식이 된다. 2++은 어떤 규칙과도 맞지 않기 때문에 유효하지 않은 입력이 된다.

파서의 종류

파서는 기본적으로 하향식 파서와 상향식 파서가 있다. 하향식 파서는 구문의 상위 구조로부터 일치하는 부분을 찾기 시작하는데 반해 상향식 파서는 낮은 수준에서 점차 높은 수준으로 찾는다.

두 종류의 파서가 예제를 어떻게 파싱하는지 살펴보자. 하향식 파서는 2+3과 같은 표현식에 해당하는 높은 수준의 규칙을 먼저 찾는다. 그 다음 표현식으로 2+3-1을 찾을 것이다. 표현식을 찾는 과정은 일치하는 다른 규칙을 점진적으로 더 찾아내는 방식인데 어쨌거나 가장 높은 수준의 규칙을 먼저 찾는 것으로부터 시작한다.

상향식 파서는 입력 값이 규칙에 맞을 때까지 찾아서 맞는 입력 값을 규칙으로 바꾸는데 이 과정은 입력 값의 끝까지 진행된다. 부분적으로 일치하는 표현식은 파서 스택에 쌓인다.

상향식 파서는 입력 값의 오른쪽으로 이동하면서(입력 값의 처음을 가리키는 포인터가 오른쪽으로 이동하는 것을 상상) 구문 규칙으로 갈수록 남는 것이 점차 감소하기 때문에 이동-감소 파서라고 부른다.

파서 자동 생성

파서를 생성해 줄 수 있는 도구를 파서 생성기라고 한다. 언어에 어휘나 구문 규칙 같은 문법을 부여하면 동작하는 파서를 만들어 준다. 파서를 생성하는 것은 파싱에 대한 깊은 이해를 필요로 하고 수동으로 파서를 최적화하여 생성하는 것은 쉬운 일이 아니기 때문에 파서 생성기는 매우 유용하다.

웹킷은 잘 알려진 두 개의 파서 생성기를 사용한다. 어휘 생성을 위한 플렉스(Flex)와 파서 생성을 위한 바이슨(Bison)이다. 렉스(Lex)와 약(Yacc)이라는 이름과 함께 들어본 적이 있을지도 모르겠다. 플렉스는 토큰의 정규 표현식 정의를 포함하는 파일을 입력 받고 바이슨은 BNF 형식의 언어 구문 규칙을 입력 받는다.

Flex(Fast lexical analyzer generator)

HTML 파서

HTML 파서는 HTML마크업을 파싱 트리로 변환한다.

HTML 문법 정의

HTML의 어휘와 문법은 W3C에 의해 명세로 정의되어 있다. 현재 버전은 HTML4와 초안 상태로 진행 중인 HTML5 이다.

문맥 자유 문법이 아님

파싱 일반 소개를 통해 알게 된 것처럼 문법은 BNF와 같은 형식을 이용하여 공식적으로 정의할 수 있다.

안타깝게도 모든 전통적인 파서는 HTML에 적용할 수 없다. 그럼에도 불구하여 지금까지 파싱을 설명한 것은 그냥 재미때문은 아니다. 파싱은 CSS와 자바스크립트를 파싱하는 데 사용된다. HTML은 파서가 요구하는 문맥 자유 문법에 의해 쉽게 정의할 수 없다.

HTML 정의를 위한 공식적인 형식으로 DTD(문서 형식 정의)가 있지만 이것은 문맥 자유 문법이 아니다. 이것은 언뜻 이상하게 보일 수도 있는데 HTML이 XML과 유사하기 때문이다. 사용할 수 있는 XML 파서는 많다. HTML을 XML 형태로 재구성한 XHTML도 있는데 무엇이 큰 차이점일까?

차이점은 HTML이 더 "너그럽다"는 점이다. HTML은 암묵적으로 태그에 대한 생략이 가능하다. 가끔 시작 또는 종료 태그 등을 생략한다. 전반적으로 뻣뻣하고 부담스러운 XML에 반하여 HTML은 "유연한" 문법이다.

이런 작은 차이가 큰 차이를 만들어 낸다. 웹 제작자의 실수를 너그럽게 용서하고 편하게 만들어주는 이것이야 말로 HTML이 인기가 있었던 이유다. 다른 한편으로는 공식적인 문법으로 작성하기 어렵게 만드는 문제가 있다. 정리하자면 HTML은 파싱하기 어렵고 전통적인 구문 분석이 불가능하기 때문에 문맥 자유 문법이 아니라는 것이다. XML 파서로도 파싱하기 쉽지 않다.

DOM

파싱 트리는 DOM 요소와 속성 노드의 트리로서 출력을 위한 출력 트리가 된다. DOM은 문서 객체 모델(Document Object Model)의 준말이다. 이것은 HTML 문서의 객체 표현이고 외부를 향하는 자바스크립트와 같은 HTML 요소의 연결 지점이다. 트리의 최상위 객체는 문서이다.

DOM은 마크업과 1:1 관계를 맺는다.

<html>
  <body>
      <p>Hello World</p>
      <div>
          <img src="example.png"/><div>
      </div>
  </body>
</html>

다음과 같은 마크업이 있다고 했을 때, 이런 방식으로 DOM트리를 구성하게 된다.

HTML과 마찬가지로 DOM은 W3C에 의해 명세가 정해져 있다. 이것은 문서를 다루기 위한 일반적인 명세인데 부분적으로 HTML 요소를 설명하기도 한다. HTML 정의는 www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html에서 찾을 수 있다.

트리가 DOM 노드를 포함한다고 말하는 것은 DOM 접점의 하나를 실행하는 요소를 구성한다는 의미다. 브라우저는 내부의 다른 속성들을 이용하여 이를 구체적으로 실행한다.

파싱

파싱은 렌더링 엔진에서 매-우 중요한 과정이다. 파싱은 중요하기 때문에 자세하게 들어가보자. 우선 문서 파싱(parsing)은 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것을 의미한다. 파싱 결과는 보통 문서 구조를 나타내는 노드트리인데, 파싱 트리(Parse Tree) 또는 문법 트리(syntex tree)라고 부른다. 기본적으로 파싱이라는 것은 어떤 문서를 브라우저가 읽을 수 있게끔 구조를 분해하는 과정이라고 이해할 수 있다.

2 + 3 - 1 이라는 표현식이 있을때, 파싱 트리로 만들면 다음과 같은 구조를 가지게 된다.

문법

파싱은 문서에 작성된 언어 또는 형식의 규칙에 따르는데 파싱할 수 있는 모든 형식은 정해진 용어와 구문 규칙에 따라야한다. 이를 문맥 자유 문법이라는데 정확한 내용은 나중에 참고해야겠다.

파서-어휘 분석기 조합

파싱은 어휘 분석, 그리고 구문 분석이라는 두 가지로 구분할 수 있다. 어휘 분석은 자료를 토큰으로 분해하는 과정이다. 토큰은 유효하게 구성된 단위의 집합체로 용어집이라고 볼 수 있다. 보통 사전에 등장하는 모든 단어라고 생각하면 쉽다.

파서는 보통 두 가지의 일을 하는데 자료를 유효한 토큰으로 분해하는 어휘 분석(토큰 변환)이 있고, 언어 구문 규칙에 따라 문서를 분석함으로써 파싱 트리를 생성하는 파서가 있다. (일단 데이터가 오면, 단어별로 나누고, 정해진 규칙에 따라 이전에 만들어진 것 같은 파싱 트리를 구성한다.) 어휘 분석기는 공백과 줄 바꿈같은 의미 없는 문자를 제거하기도 한다.

파싱은 계속 반복된다. 전체가 모두 파싱트리가 될 때까지... 파서는 보통 어휘 분석기로부터 새 토큰을 받아서 구문 규칙과 일치하는지 확인한다. 규칙에 맞으면 토큰에 해당하는 노드가 파싱 트리에 추가되고 파서는 또 다른 토큰을 요청한다.

나는 밥을 먹는다.라는 문장이 있을때, 어휘 분석기 혹은 토큰 분석기는 각각을 나, 는, 밥, 을, 먹, 는다. 식으로 의미가 있는 단어(토큰)으로 분해하고, 나는 + 밥을 + 먹는다. 식으로 의미가 이어질 수 있는 구문 규칙에 따라 언어 구문 규칙에 따라 조합한다는 식으로 이해하면 좋을 것 같다.

규칙에 맞지 않으면 파서는 토큰을 내부적으로 저장하고 토큰과 일치하는 규칙이 발견될 때까지 요청한다. 맞는 규칙이 없는 경우 예외로 처리하는데 이것은 문서가 유효하지 않고 구문 오류를 포함하고 있다는 의미다.

변환 (컴파일)

파서트리는 최종 결과물이 아니다. 중간단계에서 문서를 쪼개서 이해할 수 있는 단위로 묶어주는 역할이라고 볼 수 있다. 파싱은 보통 문서를 다른 양식으로 변환하는데 컴파일의 한 예에 가깝다. 소스 코드를 기계 코드로 만드는 컴파일러는 파싱 트리가 생성된 후에 이걸 기계 코드 문서로 다시 바꾼다.

소스코드를 받아서, 파서가 문서를 토큰이라는 단위로 쪼개어 문법에 맞게끔 파싱트리를 구성하는 단계까지 진행하고, 컴파일러는 이렇게 생서된 파싱트리를 가지고 기계어로 변환하는 컴파일 과정을 거친다.

이 부분에 대해서는 나중에 보충하도록 하자.(2021.8.24)

서론

브라우저는 사람들이 웹을 이용하기 위해 사용하는 응용소프트웨어다. 아마 다른 어떤 소프트웨어보다도 (물론 OS가 제일 많겠지만...) 많이 사용한다. 이제부터 나는 브라우저가 어떻게 작동하는지 공부해보고 정리하려고 한다. 브라우저 주소창에 google.com을 입력했을 때 어떤 과정을 거쳐 페이지가 나타나고 화면에 뿌려지게 되는지 하나하나 찾아가보고자 한다.

브라우저에 대해 알아보자.

브라우저의 종류

브라우저에는 정말 다양한 것들이 있다. 윈도우의 부산물인 edge나, firefox, 구글의 chrome, apple의 safari, 오페라와 같은 다양한 것들이 있다. statcounter의 통계를 보면 65%가 넘는 과반이 크롬 브라우저를 사용하는 것으로 볼 수 있다. 과거 12년 기준으로 62%였다고 하니 브라우저 판은 크게 변한 것이 없다. 근데 chrome은 오픈소스 브라우저니까 브라우저시장은 오픈소스 브라우저가 지배하고 있다고 해도 과언이 아니다.

브라우저가 뭘까?

브라우저는 사용자가 어떤 페이지 요소를 클릭해서 리소스를 서버측에 요청할 수 있도록 해주고 응답으로 받아온 리소스를 브라우저에 표시하는 것이 메인 기능이다. 리소스는 보통 HTML이지만 PDF 나 이미지 혹은 동영상 형태이기도 하다. 리소스는 리소스마다 고유한 주소를 가지게 되는데, 과거 URL이라고 불렸던 URI(Uniform Resource Identifier)에 의해 정해진다.

브라우저는 HTML과 CSS에 적혀진 그대로 HTML을 번역해서 뿌려주게 되는데, 이 세부 내용은 W3C(World Wide Web Consortium)에서 결정한다. 과거에는 사람마다 형식이나 양식에 대해서 자유로워 호환성 문제에서 큰 문제가 있었지만 현재는 이것이 표준 규약으로 굳어졌다.

브라우저의 사용자 인터페이스는 거의 비슷하다. 어떤 브라우저를 사용하던지간에 어려움없이 사용할 수 있는 이유다.

• URI를 입력하는 줄
• 이전 페이지, 다음 페이지
• 북마크 기능
• 홈 버튼

그 외에도 요즘에는 Extension이 부지기수로 쏟아져 나오고 있지만, 가장 기본적이고 중심적인 기능은 이것들이고 대부분의 UI들이 비슷하게 구성되어있어 중간에 다른 브라우저를 사용한다고 해도 어렵지 않게 사용할 수 있다.

브라우저의 기본 구조

브라우저는 다음과 같은 기본 구성 요소를 가지고 있따.

1. 사용자 인터페이스(User Interface) 위에서 적어두었던 것들이 바로 UI다.

2. 브라우저 엔진 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어한다.

3. 렌더링 엔진 요청한 리소스를 표시하는 역할을 한다. HTML을 요청하면 HTML과 CSS를 파싱해서 각 플랫폼 하부에서 실행된다.

4. 통신 HTTP 요청과 같은 네트워크 호출에 사용된다. 이건 플랫폼 독립적인 인터페이스고 각 플랫폼의 하부에서 실행된다.

5. UI 백엔드 콤보박스와 창 같은 기본적인 장치를 그린다. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서 OS사용자 인터페이스 체계를 가져와 그린다.(Mac 유저와, Windows 유저가 스크롤 바, 콤보박스, 인풋 같은 것들이 다르게 그려지는 이유다.)

6. 자바스크립트 해석기 스크립트 코드를 해석하고 실행시킨다.

7. 자료 저장소 이 부분은 자료를 저장하는 계층이다. 쿠키를 저장하는 것이나 모든 종류의 리소스를 하드디스크에 저장할 필요가 있다. HTML5 명세에는 웹 데이터 베이스가 정의되어 있다.

출처 : naver D2 - 브라우저는 어떻게 동작하는가

크롬은 대부분의 브라우저와 달리 각 탭마다 별도의 렌더링 엔진 인스턴스를 유지한다. 각 탭은 독립된 프로세스로 처리된다. 그렇기 때문에 프로세스 관리자를 열었을 때 탭 갯수만큼이나 많이 올라와있는 크롬 프로세스들을 확인할 수 있다.

렌더링 엔진

렌더링 엔진의 역할은 요청 받은 내용을 브라우저 화면에 표시하는 일이다. 렌더링 엔진은 HTML 및 XML 문서와 이미지를 표시할 수 있다. 물론 플러그인이나 브라우저 extension을 이용해 PDF나 다른 유형도 표시할 수 있다.

렌더링 엔진들

여러가지 브라우저가 있지만 주로 쓰이는 파이어 폭스나 크롬, 사파리는 두 종류의 렌더링 엔진으로 이루어져 있다. 파이어폭스는 모질라에서 직접 만든 게코(Gecko) 엔진을 사용하고 사파리와 크롬은 웹킷(WebKit)엔진을 이용한다.

웹킷은 최초 리눅스 플랫폼에서 동작하기 위해서 제작된 오픈소스 엔진으로 애플이 맥과 윈도우즈에서 사파리 브라우저를 지원하기 위해서 수정을 더했다. 자세한 내용은 webkit.org에서 확인할 수 있다.

동작 과정

렌더링 엔진은 통신으로부터 요청한 문서의 내용을 얻는 것으로 시작하는데 문서의 내용은 보통 8Kb 단위로 전송한다. 다음은 렌더링 엔진의 기본적인 동작 과정이다.

출처: naver D2

렌더링 엔진은 HTML 문서를 먼저 파싱하고, '콘텐츠 트리' 내부에서 태그를 DOM 노드로 변환한다. 그 다음 외부 CSS 파일과 함께 포함된 스타일 요소도 파싱한다. 스타일 정보와 HTML 표시 규칙은 "렌더 트리"라고 부르는 또 다른 트리를 생성한다.

렌더 트리는 색상 또는 면적과 같은 시각적 속성이 있는 사각형을 포함하고 있는데 정해진 순서대로 화면에 표시된다. 렌더 트리 생성이 끝나면 배치가 시작된다. 이것은 각 노드가 화면의 정확한 위치에 표시되는 것을 의미한다. 다음은 UI 백엔드에서 렌더 트리의 각 노드를 가로지르며 형상을 만들어내는 그리기 과정이다.

일련의 과정들이 차례대로 진행된다는 것이 중요하다. 렌더링 엔진은 좀 더 나은 사용자 경험을 위해 가능하면 빠르게 내용을 표시하는데 모든 HTML을 파싱할 때까지 기다리지 않고 배치와 그리기 과정을 시작한다. 네트워크로부터 나머지 내용이 전송되기를 기다리는 동시에 받은 내용의 일부를 먼저 화면에 표시한다.

• 웹킷

• 게코

웹킷과 게코는 용어가 조금 다를 뿐 동작 과정의 중심 개념은 거의 동일하다.

게코는 시각적으로 처리되는 렌더 트리를 '형상 트리(frame tree)'라고 부르고 각 요소를 '형상(frame)'이라고 하는데 웹킷은 '렌더 객체(render object)'로 구성되어 있는 '렌더 트리(render tree)'라는 용어로 부른다. 웨빗은 요소를 배치하는데 '배치(layout)'이라는 용어를 사용하지만 게코는 '리플로우(reflow)'라는 용어로 부른다. '어태치먼트(attachment, 부착)'은 웹킷이 렌더 트리를 생성하기 위해 DOM 노드와 시각 정보를 연결하는 과정이다. 게코는 HTML과 DOM 트리 사이에 '콘텐츠 싱크(content sink)'라고 부르는 과정을 두는데 이는 DOM 요소를 생성하는 공정으로 웹킷과 비교하여 거의 비슷하다.

References

• 브라우저는 어떻게 동작하는가?
• Render-tree Construction, Layout, and Paint
• Adding interactivity with javascript
• 오픈소스 웹킷(Webkit) 구조와 원리