일반적인 컴퓨터 분야에서 사용하는 용어를 다룹니다.

부트스트랩(Bootstrap), 부트스트래핑(Bootstrapping)

위키피디아의 설명에 따르면 부트스트랩이란 Boot(s) + Strap의 합성어로서 부츠(Boots)의 뒷 부분에 달린 끈 혹은 고리(Strap)를 말한다. 이 부트스트랩은 요즘 신발에도 달려나온다.

부트스트랩

출처: http://skyvington.blogspot.com/2008/05/boot-story.html

긴 부츠의 경우에는 발을 끝까지 넣기 힘들기 때문에 발을 넣고 부트스트랩이라는 이 고리에 손가락을 넣고 당겨서 부츠를 신는다. 부트스트랩이란 단어에 얽힌 to pull oneself up by one's bootstraps라는 표현도 있다. 어떤 사람이 신발을 신은 채로 자신의 신발에 붙어있는 부트스트랩으로 자신을 들어 올린다는 뜻이다. 말도 안되는 표현이지만, 시간이 지나면서 이 표현은 불가능한 일을 의미하고 있지만 자력으로 일을 해낸다는 의미로 바뀌는데 컴퓨터 분야에서는 보통 한 번 시작하면 다른 외부의 도움없이 스스로 진행하는 행위를 통틀어 사용하고 있다.

부팅

부트스트랩이라는 단어를 사용하는 대표적인 예가 부팅(Booting)인데, 이는 부트스크랩의 진행형인 Bootstrapping을 줄여서 표현한 단어이다.

부팅은 대부분 사람들은 단순히 컴퓨터 전원을 켜는 행위 혹은 전원을 켜서 윈도우나 맥의 OS화면이 나올때까지의 절차로 알고 있다. 맞는 말이긴 한데, 좀 더 자세히 설명을 하자면 컴퓨터 전원을 켜면 BIOS(Basic Input/Output System)가 실행된다. BIOS에서 CPU, 메모리 등의 주변 하드웨어를 진단 후에 부팅매체(보통 하드디스크)의 MBR(Master Boot Record)에 저장된 부트로더(Bootloader) 혹은 부트스트랩 코드라고 불리는 프로그램을 메모리로 복사한다. 여기까지가 BIOS의 역할이며 이후 컴퓨터의 제어권은 이 부트로더가 가지게 된다. 부트로더는 디스크에 있는 OS의 코드를 메모리에 올려서 OS를 실행하게 된다. 그 이후로는 컴퓨터의 제어권은 컴퓨터가 종료될 때까지 OS가 가지게 된다.

OS가 자신을 스스로 실행할 수 없으나 일단 실행 만되면 일체의 외부 도움 없이 컴퓨터를 완전하게 제어한다는 사실에 볼때 부트스트랩이라는 단어에 가장 어울리는 상황이라 할 수 있다.

컴파일러

컴파일러 분야의 부트스트래핑은 위에서 설명한 부팅과 같지만 다른 의미로 쓰인다. 컴파일러 분야에서는 스스로를 컴파일 할 수 있는 컴파일러를 만들어 나가는 과정을 부트스트래핑이라고 말한다. (컴파일러에 대한 개략적인 설명은 여기를 참고한다.)

보통 어떤 프로그래밍 언어를 만들때 반드시 컴파일러도 만드는데, 보통 초기에는 다른 언어로 컴파일러를 만든다. Go언어를 예로 들자면 Go언어의 초기 컴파일러는 C와 약간의 어셈블리어로 컴파일러를 만들었다. 그렇게 언어의 기능을 발전시켜 나가다가 1.5버전부터는 컴파일러 자체를 Go언어로 만들었다. (당연히, 물론 약간의 어셈블리어도 추가)

컴파일러의 부트스트래핑은 여러 장점이 있기 때문에 Python, Java, C#, C++ 등 대부분의 주요 언어에서는 부트스트래핑 과정을 거쳐서 자신의 언어로 컴파일러가 만들어졌다. 주요 장점은 아래와 같다.

  • 컴파일할 언어로 작성하기 때문에 중요한 테스트가 된다.
  • 컴파일러 개발자들은 컴파일 할 언어만 알면 된다.
  • 컴파일러 개발을 컴파일될 고급 언어로 할 수 있다. 보통은 저급언어로 고급언어 컴파일러를 만드는 경우가 많기 때문이다.

다만 과도기적으로 컴파일러의 컴파일 속도와 최적화 측면에서 문제가 있을 수 있지만, 대부분 시간이 지나면 해결된다.

추가적으로 읽어볼 내용

StackOverflow의 답변을 보면 개발자 관점에서 본 부트스트랩의 정의를 적어놓았다. 꽤 재미있는 내용인데, 글쓴이는

  • C언어로 C언어 컴파일러를 어떻게 만들 수 있는가?
  • 아직 구동하지 않은 OS가 없는데 OS 초기화 프로세스를 어떻게 실행할 수 있는가?

라는 도발적인 질문을 던진다. 글쓴이는 이 경우를 순환 의존(Circular Dependency)라고 정의한다. 우리말로 하자면 닭이 먼저냐 달걀이 먼저냐랑 같은 문제다. 글쓴이는 앞의 예를 들어 부트스트래핑은 이 순환의존 고리를 깨버리는 외부 객체의 도움이라고 명확하게 정의한다.

스캐폴딩(Scaffolding)

스캐폴드(Scaffold)는 원래 건축에서 유래된 단어다. 길거리를 지나가다보면 외벽에 임시로 작업자들이 지나다닐 수 있도록 만든 구조물이 있는데, 이게 바로 스캐폴드다.

스캐폴드

컴퓨터 프로그래밍에서도 스케폴딩이라는 용어를 사용한다. 위키피디아에서는 두 가지로 구분해서 설명한다.

첫 번째, 초기 프로젝트의 뼈대를 만들어주는 행위를 뜻한다. 어떤 프로젝트를 시작할 때 기본적인 README, License를 비롯하여 디렉토리 구조, 컴파일 설정 등이 자동으로 생성하는 CLI 혹은 UI 도구가 이와 같다.

두 번째, 일부 MVC(Model-View-Controller) 프레임워크에서 사용하는 의미이다. 루비 온 레일즈(Ruby on Rails)에서 처음 도입되었는데, 개발자가 사용하고자 하는 모델을 정의하면 자동으로 관련된 보일러플레이트 코드가 만들어지는 기법이다.

위키피디아에서는 크게 두 가지로 나누긴 했지만 자동으로 보일러플레이트 코드를 만들어준다는 측면에서 볼 때 크게 보면 두 가지 모두 같은 행위라 볼 수 있다.

많은 프레임워크에서 첫 번째 의미에 해당하는 스캐폴딩을 지원한다.

  • React.js 의 CRA (Create React Application)
  • Nest.js의 nest new PROJECTNAME
  • C#(.Net)의 Visual Studio에서 새 프로젝트 만들기
  • IntelliJ에서 Java 프로젝트 만들기

등등등...

보일러플레이트

원래 보일러플레이트는 19세기에 증기 보일러를 만들때 틀로 사용하는 강철판을 의미했다. 보일러플레이트에는 보일러 이름 등의 제조 정보가 음각으로 새겨져 있어서 보일러플레이트를 통과한 강철판에는 보일러 이름 등이 새겨지게 되었다. 이게 인쇄 분야로 이어져서 반복해서 사용하는 텍스트(주로 광고나 로고)를 의미하게 되었다.

몇 번을 찍어도 똑같이 찍히기 때문에 편집자나 작가들은 천편일률적인 작품이나 글을 비판할때 이 용어를 사용하기 시작하였다.

이 단어는 컴퓨터 프로그래밍 분야에도 사용하게 되었다. 컴퓨터 프로그래밍에서 보일러플레이트 코드(혹은 그냥 보일러플레이트)는 변화없이 여러 군데에서 반복되는 코드를 말한다. 주로 옛날에 만들어진 언어에서 많이 나타나는데, 프로그래머는 사소한 기능 하나 만드는데도 수 많은 코드를 작성해야 한다.

Java의 예를 들자면 속성으로 name, company를 가진 User라는 클래스를 하나 만든다고 하면 아래와 같은 코드가 만들어진다.

public class User {
    private String name;
    private String company;

    public Pet(String name, String company) {
        this.name = name;
        this.company = company;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getcompany() {
        return company;
    }

    public void setcompany(String company) {
        this.company = company;
    }
}

단순히 클래스 하나 만드는데 getter, setter가 모두 정의되어야 한다. 언어가 발전할수록 이런 보일러플레이트 코드가 없어지는데 Java를 염두에 두고 만들어진, 그리고 언어 자체 측면만 비교하면 Java보다 낫다고 평가를 받는 C#을 보면 위의 보일러플레이트는 아래와 같이 표현할 수 있다.

public class User
{
    public string Name { get; set; }
    public string Company { get; set; }
}

이렇게 보면 보일러플레이트 코드가 없어져야할 악의 축인것 같지만, 실제로 코딩할 때에는 수시로 보일러플레이트 코드를 사용한다. Nest.js를 개발한다면 어떤 모듈에 서비스를 만들거나 컨트롤러를 수 없이 만들어야 한다. 예를 들어 user의 서비스를 만든다면 Nest CLI로 아래와 같이 입력하면 된다.

$ nest g service user

그러면 user 디렉토리에 userService.ts, userService.spec.ts 파일이 생기며 각각의 파일에는 아래와 같은 코드가 생성된다.

// userService.ts
import { Injectable } from "@nestjs/common";

@Injectable()
export class MoveService {}

// userService.spec.ts
import { Test, TestingModule } from "@nestjs/testing";
import { MoveService } from "./move.service";

describe("MoveService", () => {
  let service: MoveService;

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

    service = module.get<MoveService>(MoveService);
  });

  it("should be defined", () => {
    expect(service).toBeDefined();
  });
});

이런 코드는 서비스를 만들기 위해서 가장 기본적인 틀이 되며 최소한의 변경으로 재사용할 수 있다. 이런 코드 역시 보일러플레이트 코드라고 한다.

Javascript

자바스크립트와 타입스크립트 용어 사전입니다.

바닐라 자바스크립트(Vanilla Javascript) 란?

바닐라 자바스크립트 혹은 vanilla.js는 한 마디로 말하면 자바스크립트(Javascript) 언어 자체를 말한다. 아니, 자바스크립트를 자바스크립트라고 부르지 왜 굳이 바닐라 자바스크립트라고 부를까? 이를 위해서는 자바스크립트 발전 역사를 알아야 한다.

라이브러리 전성시대

마이크로소프트의 Internet Explorer(이하 IE)가 Netscape와의 브라우저 전쟁에서 완승한 후 한때 90%가 넘는 점유율을 보일때가 있었으나 2004년 모질라 재단의 Firefox, 2008년 구글 Chrome이 각각 출시되면서 웹 브라우저 시장은 그야말로 혼돈의 도가니가 되었다. 여기서부터 웹개발자들의 고민이 시작되었다. Firefox와 Chrome과는 달리 IE는 웹 표준을 잘 지키지 않았기 때문에 브라우저간 호환성이 큰 문제가 되었다. 똑같은 자바스크립트나 CSS라도 브라우저마다 다르게 동작했고, 이는 곧 개발 비용의 상승으로 이어졌다. 이를 해결해주는 도구가 바로 jQuery 였다.

jQuery는 2006년 첫 출시 이래 근 10년간 큰 인기를 얻어왔다. 이 시기는 jQuery를 필두로 Dojo, Ext JS, MooTools 등등의 라이브러리가 득세를 한 시기였다. 웹 개발자들에게 이런 라이브러리들이 인기를 끈 이유는 크게 두 가지로 요약된다.

첫 번째, 앞서 말한 브라우져 호환성 문제 두 번째, jQuery를 사용하면 DOM 조작이나 CSS, 애니메이션을 굉장히 쉽게 사용할 수 있었다. 자바스크립트도 그렇게 어려운 편은 아니지만 사용성 측면에서는 사실 jQuery에 비할바가 아니었다.

문제

이렇게 라이브러리가 득세할 동안은 상당수 웹 개발자들이 자바스크립트 자체보다 jQuery, Dojo 같은 특정 라이브러리를 더 잘 알고있는 경우가 많았다. 다들 파스타 전문가라고는 하지만 실상을 보면 면을 삶을지도, 소스를 만들지도 모르면서 밀키트를 가져다가 데워먹는것과 같디고 할까.

또한 이러한 라이브러리들을 사용하면 몇 가지 문제가 있다. 첫 번째는, 심각한 성능 저하다.

자바스크립트 성능 비교

두 번째는, 라이브러리는 꽤 무겁다. jQuery를 예로 들자면, npm에서 확인해보면 3.6.0기준으로 1.32MB나 한다.

ES6(ES2015)의 등장과 SPA의 득세, 그리고

자바스크립트의 3번째 표준안인 ES6(ES2015)에는 모듈, 스코프, Promise 도입 등 굉장히 발전한 모습으로 돌아왔다. 언어 기능 자체도 좋아진데다가 앞서 말한 라이브러리의 많은 기능이 언어 자체에 추가되었다.

언어도 좋아졌지만 리액트를 비롯한 SPA가 득세를 하면서 자바스크립트 언어 자체의 중요성이 커지고 jQuery등의 라이브러리를 사용할 일이 더 줄어들었다.

함수 시그니쳐

컴퓨터 과학에서 함수 서명 혹은 메서드 서명은 컴파일러가 함수를 구분하기 위한 구성요소를 말한다. 프로그래밍 언어마다 시그니쳐를 구성하는 요소가 다르지만 대체적으로 아래의 요소가 포함되어 있다.

  • 함수의 이름
  • 매개변수(Parameter)의 개수
  • (옵셔널) 매개변수의 자료형
  • (옵셔널) 반환하는 값의 자료형

옵셔널로 표시된 항목들은 자료형이 없는 동적 언어에서는 해당사항이 없다. 만약 두 함수의 이름, 매개변수의 개수, 그 타입이 모두 같다면 이 두 함수의 시그니처는 같다고 할 수 있다.

백링크

Nest.js Controller 1편
Nest.js Controller 2편