유튜브를 통해 많이 접하였던 송길영 작가의 책임을 이전부터 알았으나, 단순히 영상으로만 접하고 책을 읽어볼 생각은 하지 못하였었다. 그러나, 머리를 자르러 미용실을 가던 중 우연히 들르게된 알라딘 판매대에서 해당 책을 보고 사서 읽게 되었다.

저자는 한 철의 기상을 알려주는 일기예보처럼, 데이터를 통해 본 시대의 흐름을 파악하고 개인의 삶을 대비하기 위한 목적으로 책을 썻다고 한다. 책의 목적처럼 현 시대의 흐름을 여러 레퍼런스와 함께 잘 정리되어 작성되었고 쉽게 읽을 수 있었다.

프롤로그 - 쪼개지는, 흩어지는, 홀로 서는

제1장 K는 대한민국이 아니다.
 - K 프리미엄, 국적은 사라지고 스타일은 남아
 - '서울러'라는 소속감 혹는 구별 짓기
 - '오리너구리'를 포용할 수 있는 세계
 - '국민교육현장'의 공허한 메아리
 - 언어 습관이 조직의 운명을 바꾼다.

제2장 코파일럿은 퇴근하지 않는다.
 - 출퇴근 없는 AI 동료
 - 기계가 좋아서가 아니라 사람이 불편해서
 - 이심전심, 심심상인, AI 비서
 - 작가는 사라지고 장르만 남는다.
 - 주말 오후, 2시간만에 쇼핑몰을 개업하다.
 - 인류에겐 축복이지만, 당신에게는 재양일 수도
 - 재앙을 축복으로 만드는 연금술

제3장 채용이 아니라 영입
 - 대학은 입학만, 졸업 혹은 창업은 당신의 선택
 - 유명 대학 나온 동네 사장님들
 - 개인의 유동성, 조직의 역동성
 - 캘빈 클라인 모델이 상위 1% 프로그래머
 - 투명 사회의 생존법
 - 당신은 영입 대상입니까

제4장 효도의 종말, 나이듦의 미래
 - 아버지를 고용한 딸, 가녀장의 시대
 - 엄마처럼 OO하며 살고 싶지 않아
 - 죄책감은 나의 몫? 주고받음의 아름다움
 - 나이듦은 천차만별
 - '영웅시대'에는 효도가 필요 없어
 - 문제는 '나이'가 아니라 '나'이다

제5장 핵개인의 출현
 - 세계관을 주고받는 우아한 핵개인들
 - 그게 다 빚이었다.
 - 천륜은 사라져도 연대는 남는다.
 - 미정산 세대의 필연
 - 5분 존경 사회

에필로그 - 인정 강박, 경쟁하지 않는 사회를 위하여

위의 목차만 봐도 책에서 저자가 말하고 싶은 것이 어떤 건지 유추가 가능하다. 그러나, 저자는 주제 뿐만 아니라 시대적으로 왜 그러한 현상이 발생했는지 논리적으로 설명하고 주제에 대해 개인과 공동체가 가져야할 모습을 제안한다는 부분에서 책을 집필할 때의 고민이 느껴져 좋았다.

책 제목처럼 시대를 예보하는 책이기에 현재 시점에서 예보된 내용과 맞춰 읽어보면 흥미롭게 읽을 수 있을 것이다.

2023년에 나온 책으로써 이 책을 읽은 2025년 관점에서 봤을 때 2023년에 예측된 시대의 흐름이 너무나도 빠르게 다가왔다. 그래서 저자도 그러한 빠른 시대 변화에 맞춰 "시대예보: 호명사회"라는 책을 2024년에 빠르게 발간했지 않을까 싶다.(다음에 읽으려고 예정 중이다.😊)

물론 책이 쓰여진 그 당시에 데이터로도 해당 경향이 보여 작성된 것이겠지만, 이러한 경향이 불과 2년만인 2025년 현재에 매우 빠르게 주류가 된 것이 놀라웠다.(필자 기준 그렇게 느끼고 있다😅) 필자는 책에 쓰여진 내용이 벌써 적용되어 '음 맞지 맞지'의 느낌으로 읽었지만, 이러한 부분에 민감하지 않거나 생각해보지 않은 사람들에게는 신선한 시각을 줄 수 있는 책이라고 생각된다.

필자가 본 신선한 시각은 최근 AI Agent에 대해 관심이 많은 만큼 '제2장 코파일럿은 퇴근하지 않는다' 중 문제 해결에 관한 부분이다. 책에서 말하는 버전에 다른 문제 해결은 다음과 같다.

• 문제 해결 1.0: 내가 문제를 정의하고 전문가가 해결을 도와주는 것
• 문제 해결 2.0: 내가 문제를 정의하고 해결에 필요한 것을 파악해서 직접 해결하는 것
• 문제 해결 3.0: 내가 문제를 제기하고 AI가 문제 인식과 정의, 해결을 도와주는 것

여기에서 '문제 해결 3.0'이 많이 달라진 부분은 문제의 정의과 제기 그리고 문제 해결의 주체이다. AI가 고도화된 시점에서는 문제를 정의조차 하지 않아도 될 것이라는 부분이 신선하기 다가왔으며, 앞으로 문제를 제기할 수 있는 시각을 가지기 위해 관성적인 태도가 아닌 다양한 시각에서 문제를 바라볼 수 있는 태도를 가져야겠다는 생각이 들었다.

책에서 제안하고 말하는 상호 존중과 자기 인생의 능동적 결정권을 가지는 핵개인의 태도를 받아드리고 지향하여 이를 달성하고 싶다.(원래 필자는 원래 그쪽 성향이긴 했다.🤣)

클라우드 컴퓨팅은 크게 4가지로 나눌 수 있다.

• 퍼블릭(Public)
• 프라이빗(Private)
• 하이브리드(Hybrid)
• 멀티(Multi)

이 4가지 유형의 특징을 간단히 정리하면 다음과 같다.

일반적으로 퍼블릭 클라우드와 프라이빗 클라우드를 많이 사용한다.

퍼블릭(Public) 클라우드

• 가장 일반적인 유형
• 사용자는 컴퓨팅 리소스를 소유하지 않음
• 인터넷을 통해 제공
• 클라우드 제공 업체가 가상화 기술로 만든 서비스를 그대로 사용

프라이빗(Private) 클라우드

• 특정 조직 내 컴퓨팅 리소스를 소유
• 사설(Private) 네트워크를 통해 제공
• 가상 컴퓨팅 기술을 직접 구축

클라우드 서비스란?

클라우드 서비스는 인터넷을 통해 서버, 스토리지, 소프트웨어 등 필요한 IT 리소스와 애플리케이션을 사용하기 원할 때 언제든지 사용한 만큼(on-demand) 요금을 내는 서비스라고 할 수 있다.

이러한 클라우드 서비스는 여러가지 특징을 가지고 있다.

클라우드 서비스 특징

1. 탄력성/민첩성(Agility/Elasticity) a. 간략한 조작으로 생성/삭제 및 확장 b. 리소스에 대해 필요할 때 언제든 늘리고, 줄일 수 있음
2. 확장성(Scalability) a. 급증하는 서비스 트래픽에 빠르게 대비 b. 물리 서버를 확장하려면 시간이 오래 걸리는 반면, 클라우드는 즉시 확장 가능
3. 사용한 만큼 지불(on-demand) a. 무리한 자본지출 없이 빠른 시도와 회수 가능 b. 사용한 만큼 과금되며, 비용 예측이 가능 c. 기존 온프레미스 환경에서는 CAPEX가 많이 필요했지만 클라우드 환경에서는 CAPEX가 없이 운영 지출인 OPEX로 대체할 수 있게 되었다. -> 빠르게 투자 비용을 회수 할 수 있게 된다.

OPEX(Operational Expenditures): 운영 지출 CAPEX(Capital Expenditures): 자본 지출

4. 내결함성 및 재해 복구(Fault tolerance & Disaster Recovery) a. 내결함성과 재해 복구를 고려한 설계 가능 b. 클라우드 백업 및 클라우드 DR 구성으로 데이터 손상 등 긴급 상황에 대해 대처 가능

내결함성(Fault tolerance)

• 시스템의 일부 구성 요소가 작동하지 않더라도 계속 작동할 수 있는 기능

5. 고 가용성(High Availability) a. 여러 개의 데이터센터가 고속 네트워크 망으로 연결되어 가용성 설계 가능 b. 손쉬운 다중 가용영역 설정에 따라 고 가용성 보장
6. 유지 관리 최소화(Maintenance) a. 물리적 리소스 유지보수 불필요 -> 눈에 보이지 않는 비용(인력, 전기세, 임대 비용 등) 절약 가능 b. 물리적 리소스를 유지할 필요가 없고, 부분적으로 클라우드 CSP 벤더에 위임

클라우드 서비스 제공업체(CSP)

클라우드 서비스를 제공하는 벤더(vendor)를 클라우드 서비스 제공업체(CSP, Cloud Service Provider)라고 한다.

대표적인 해외 업체

• AWS(아마존)
• GCP(구글)
• Azure(MS)
• ORACLE Cloud(오라클)
• IBM Cloud(IBM)
• Alibaba Cloud(알리바바)
• Tencent Cloud(텐센트)

대표적인 국내 업체

• Naver Cloud Platform(네이버)
• NHN Cloud(NHN)
• KT Cloud(KT)
• Kakao i Cloud(카카오)
• Gabia Cloud(가비아)

클라우드 시장

2021년 기준 세계 클라우드 시장 점유율에서 AWS가 33%로 돋보적인 1위를 차지하고 있다. 해외뿐만 아니라 국내에서도 많이 사용되고 있다.

클라우드 서비스 모델

클라우드 SCP 벤더에서 제공하는 클라우드 서비스 종류에는 크게 3가지 모델이 존재한다.

• IaaS(Infrastructure-as-a-Service)
• PaaS(Platforms-as-a-Service)
• SaaS(Software-as-a-Service)

이를 구분하는 기준은 위 사진에서 볼 수 있는 클라우드에서 제공할 수 있는 9가지 기준에 따라 구분된다.

모든 것을 관리해야 하는 온프레미스(On-Premise) 환경과 달리 클라우드 서비스는 서비스에 따라 클라우드 제공자가 일부 또는 전부를 관리한다.

IaaS(Infrastructure-as-a-Service)

IaaS는 물리적인 자원이 가상화되어서 제공되는 서비스이다. 예를 들어 AWS의 EC2 등이 있다.

가상화(Virtualization)를 포함한 아래 존재하는 물리적인 자원인 서버(Server), 스토리지(Storage), 네트워킹(Networking)을 클라우드 제공자가 관리를 하게 된다.

PaaS

PaaS는 어플리케이션을 바로 구축할 수 있는 플랫폼을 제공한다.

모든 물리적 장비와 가상 인프라를 클라우드 제공자가 관리하고, 추가적으로 OS 영역, Middleware, 데이터베이스 관리 시스템, 분석 툴과 같은 Runtime을 제공한다. 예를 들어 AWS RDS, AWS Elastic Beanstalk 등이 있다.

SaaS

SaaS는 서비스형 소프트웨어를 말하며, PaaS에서 제공되는 것에 추가로 데이터와 응용 프로그램이 포함된다. 즉, SaaS는 특정 앱 또는 웹 포털(Web Portal)를 통해서 제공되는 서비스로 완전한 소프트웨어 솔루션을 말한다.

예를 들어, 구글 드라이브나 네이버 박스가 있고 AWS에서는 머신러닝 서비스인 Amazon SageMaker, VDI 서비스인 Amazon WorkSpaces 같은 것들이 여기에 해당된다.

On-Premise vs Cloud

아래는 온프레미스 환경과 클라우드 환경을 비교한 표이다.

참고 강의

• 초격차 패키지 Online. 한 번에 끝내는 AWS 기반 아키텍처 설계와 DevOps

Host는 간단히 말하자면 네트워크에 연결이 되어 있는 컴퓨터를 말하며, 크게 2가지로 나눌 수 있다.

• Host 중 네트워크 자체를 이루는 Host
• 네트워크를 이용하는 이용 주체로써의 Host

Host 중 네트워크 자체를 이루는 Host라면 이를 Switch라고 부르며, 네트워크를 이용하는 이용 주체로써의 Host는 End Point라고도 부른다.

기본적으로 스위치(Switch)의 역할은 스위치에 도착한 패킷을 특정 장치로 보내주는 스위칭(Switching)을 해주는 것이다. 네트워크 자체를 이루는 Host들을 모두 스위치라고 부를 수 있지만 특화된 역할에 따라, 속한 OSI 계층에 따라 세부적으로 다른 이름으로 불린다.

특수한 목적을 가진 스위치들을 제외한 스위치들은 여러 장치를 연결하여 LAN(local area network)를 형성하며 이는 로컬 영역 네트워크 즉, 같은 네트워크 주소를 가진다는 말과 같다.

Router

라우터(Router)는 스위치 중 하나로 서로 다른 IP 네트워크 간의 네트워크 트래픽을 전달하는 장치이다. 다시 말해, 다른 네트워크 주소들을 연결하기 위한 장치이다. 또한 라우터 또한 목적지로 가는 적합한 경로를 찾아주는 라우팅 기능을 한다.

Switch와 Router의 차이점

참고 자료

• [NetPractice] 과제를 위한 기초학습 - mseo
• 스위치, 라우터의 차이 - jihoon97
• https://server-engineer.tistory.com/582

IP는 Internet Protocal의 약자로, IP 주소는 Host에 대한 식별자이다.

현재 IP 주소는 IPv4, IPv6 버전을 가지고 있으며, 이 둘의 가장 큰 차이점은 주소의 길이이다. IPv4는 32 bit 주소 길이를 가지며, IPv6는 128 bit 주소 길이를 가진다. 일반적으로는 IPv4 환경을 사용한다.

IPv4주소는 일반적으로 192.168.123.132와 같이 마침표로 구분된 4개의 숫자가 있는 10진수의 형식으로 표시되지만, 이는 사실 2진수 숫자를 10진수로 표현한 것에 불과하다. 위의 IPv4 주소를 32비트로 표현하자면 11000000.10101000.01111011.10000100가 될 것이다. 즉, IPv4 주소는 8 bit 씩 끊어서 표시하는 것이다. 8개의 비트를 묶은 세션을 옥텟(octet)이라고 하는데, 이 옥텟을 변환한 수가 우리가 익히 아는 IP주소의 형태를 띄는 것이다.

이러한 IP 주소는 아래 명령어를 통해 확인할 수 있다.

• 윈도우(Window): ipconfig
• 맥(Mac): ifconfig

IPv4의 경우 32 bit 체계를 가지고 있으므로 약 43억개의 경우의 수를 가진다. 따라서 IPv4를 사용할 경우 인터넷에 Host로 참여할 수 있는 Host의 개수는 약 43억개로 제한된다. 이는 단순하게 생각해봐도 매우 부족하다. 따라서 이런 문제를 해결하기 위해 IP를 사용하는 네트워크 장치 수에 따라 효율적으로 사용할 수 있는 Network ID와 HostID가 등장하였다.

Network ID, Host ID

IP 주소는 Network ID, Host ID 두 부분으로 나뉘어진다.

• Network ID
  • Host들을 모은 네트워크를 지칭하는 주소
  • 네트워크 주소가 동일한 네트워크를 로컬 네트워크라고 한다.
• Host ID
  • 하나의 네트워크 내에 존재하는 Host를 구분하기 위한 주소

그런데 IP 주소에서 네트워크 ID와 호스트 ID를 구분하는 경계점이 고정되어있지 않다. 따라서 필요한 호스트 IP 개수에 따라 네트워크의 크리를 다르게 할당할 수 있다록 클래스(class)라는 개념을 도입하였다. 클래스는 A, B, C, D, E 클래스가 존재하며, 각각의 클래스에 할당되는 IP 주소 갯수와 역할이 다르다.

C 클래스는 멀티캐스트를 위해 사용되고, E 클래스는 예약 되어있는 클래스이기 때문에 A, B, C 클래스와는 구분된다.

클래스풀(Classful) 기반 주소 체계

대표적으로 많이 사용되는 A, B, C 클래스들의 IP 주소의 갯수는 대략 다음과 같다.

• A 클래스 : 약 16,000,000개
• B 클래스 : 약 65,000개
• C 클래스 : 약 250개

각각의 클래스에서 네트워크 주소와 호스트 주소를 나누는 기준은 아래와 같다.

A 클래스 -> 네트워크.호스트.호스트.호스트
B 클래스 -> 네트워크.네트워크.호스트.호스트
C 클래스 -> 네트워크.네트워크.네트워크.호스트

이러한 클래스들을 구분하기 위한 클래스 구분법은 맨 앞 옥텟의 주소가 무엇인지만 보면 구분할 수 있다. 각 클래스마다 가지는 맨 앞자리 옥텟은 아래와 같다.

A 클래스 -> 1~127.0.0.0 (로컬호스트)
B 클래스 -> 128~191.0.0.0
C 클래스 -> 192~223.0.0.0
D 클래스 -> 224~239.0.0.0

그런데 사실 클래스 기반으로 네트워크를 분할하는 기법은 현재는 사용하지 않는다. 클래스 기반보다 네트워크 주소를 세밀하게 분할하고 할당하기 위해서 네트워크 크기에 맞춰 1 bit 단위로 네트워크를 상세히 분할하는 방법을 사용한다.

과거 클래스 기반의 IP 주소 체계를 클래스풀(Classful)이라고 하는 반면 현재는 클래스 개념 자체를 버리는 클래스리스(Classless) 기반의 주소 체계를 사용한다. 그리고 이 클래스리스 기반 주소 체계를 사용하기 위해 도입된 것이 서브넷 마스크(Subnet Mask)이다.

Subnet Mask

서브넷(Subnet)은 부분 망이라는 뜻이다. IPv4 주소에서 네트워크 영역을 부분적으로 나눈 부분 망, 즉 부분 네트워크를 뜻하는 것이다. 이러한 서브넷을 만들 때 사용되는 것이 서브넷 마스크(Subnet Mask)이다. 이 서브넷 마스크를 이용하여 IP주소 체계의 Network ID와 Host ID를 서브넷 마스크를 통해 분리할 수 있다.

서브넷 마스크의 형태는 기본적으로 IPv4 주소와 같은 32 bit 이진수이며, IPv4와 같은 xxx.xxx.xxx.xxx 와 같은 형태를 가지고 있다. 이러한 서브넷 마스크를 이용해 IPv4 주소와 AND 연산하여 Network ID를 걸러낸다.

서브넷팅(Subnetting)

서브네팅(Subnetting)은 네트워크 관리자가 네트워크 성능을 향상시키기 위해, 자원을 효율적으로 분배하는 것이다. 다시 말해, IP 주소 낭비를 방지하기 위해 원본 네트워크를 여러개의 서브넷으로 분리하는 과정을 뜻한다.

네트워크적인 측면에서 말하자면, 너무 큰 브로드캐스트 도메인은 네트워크 환경에서 패킷전송을 느리게하고 성능저하를 발생시킨다. 따라서 네트워크를 쪼개서 통신 성능을 보장하는 것이다. 또한 IPv4 주소는 한정적이기 때문에 서브넷마스크를 이용해 필요한 네트워크 주소만 호스트 ID로 할당 할 수 있게 만들어 네트워크 낭비를 방지하는 것이다.

서브네팅의 반대는 슈퍼네팅이라고 한다.

서브넷팅은 서브넷 마스크의 bit 수를 증가시키는 것이라고 생각하면 이해가 편하다. 서브넷마스크의 bit 수를 1씩 증가시키면 할당할 수 있는 네트워크가 2배로 증가하고 호스트 수는 2배로 감소한다.

예를 들어 C클래스인 192.168.32.0/24를 서브넷 마스크의 bit 수를 1 증가시켜서 192.168.32.0/25로 변경한다고 하자.

192.168.32.0/24는 원래 하나의 네트워크였다. 이때 할당 가능한 host의 수는 $2^8 - 2 = 254개$이다. 여기서 2개를 빼는 이유는 첫번째 주소인 192.168.32.0은 Network Address로 쓰이고 마지막 주소인 192.168.32.255는 Broadcast로 쓰이기 때문에 호스트에 할당할 수 없기 때문이다.

이 때 서브넷 마스크의 bit 수를 1증가시켜서(서브넷팅) 192.168.32.0/25로 변경하게 되면 Network ID부분을 나타내는 부분이 24비트에서 25비트로 증가하고 Host ID를 나타내는 부분이 8개 비트에서 7개 비트로 줄어든다. 즉 할당 가능한 네트워크 수가 2개로 증가하고 각 네트워크(서브넷)당 할당가능한 호스트수는 $2^7-2 = 126$개로 줄어든다. 또한 서브넷 마스크가 255.255.255.128로 변한 것을 확인할 수 있다.

이런 식으로 효율적으로 IP 주소를 사용할 수 있게 만드는 것이다.

네트워크 브로드캐스트 주소

네트워크 주소(Network address)는 호스트 주소가 모두 0인 주소**로, 네트워크를 구별하기 위한 네트워크 주소로 사용되기 때문에 각 기기들이 통신하기 위한 고유 번호로는 사용되지 않는다.

브로드캐스트 주소(Broadcast adddress)는 반대로 호스트 부분이 모두 1인 주소를 말하며, 특정 네트워크에 속하는 모든 호스트/클라이언트들이 듣게 되는 주소이다. 목적이 있는 주소이기 때문에, 이 또한 각 기기들이 통신하는 고유 번호로 사용되지 않는다.

사설 IP(Private IP)

사설 IP는 전세계적으로 고유한 IP가 아닌, **네트워크 내에서 자유롭게 할당해서 쓰는 IP주소, 또는 대역으로 각 클래스마다 사설 IP대역이 존재((한다.

10.0.0.0~10.255.255.255 (A 클래스 사설 IP 대역)
172.16.0.0~172.31.255.255 (B 클래스 사설 IP 대역)
192.168.0.0~192.168.255.255 (C 클래스 사설 IP 대역)

이 사설 IP는 라우터에 의해 로컬 네트워크 상에서 PC나 장치에 할당되기 때문에 하나의 네트워크 안에서는 유일하나, 전체 네트워크 상에서는 유일하지 않다. 또한 사설 IP로는 인터넷에 직접 연결할 수 없다.

참고 자료

• IPv4주소 체계에 대한 암기사항 - 널널한 개발자 TV
• https://code-lab1.tistory.com/34
• https://engkimbs.tistory.com/622
• 서브넷 마스크(Subnet Mask)란? - Su Bak
• [NetPractice] 과제를 위한 기초학습 - mseo

간단히 말하자면 네트워크에 연결이 되어 있는 컴퓨터를 말한다. 그런데 Host는 크게 나누어서 생각할 수 있다.

• Host 중 네트워크 자체를 이루는 Host
• 네트워크를 이용하는 이용 주체로써의 Host

Host 중 네트워크 자체를 이루는 Host라면 이를 Switch라고 부르며, 네트워크를 이용하는 이용 주체로써의 Host는 End Point라고도 부른다.

End Point*의 역할에 따라 peer, server, client 등으로 불려진다. *Switch 또한 역할에 따라 여러 종류로 불리는데, 대표적으로 Router가 있다. OSI 7계층 위치에 따라서 L1 Switch, L2 Switch, ... 등으로도 불린다.

참고

• IDS (침입 탐지 시스템) : 네트워크 비정상 행동을 감지해 관리자에게 알린다
• IPS (침입 방지 시스템) : 침입 이전에 방지하고, 탐지했을 경우 처리까지 한다
• FireWall(방화벽) : 접근을 통제한다
• Peer : 동일 프로토콜 계층에서 대등한 지위로 동작하는 장치
• Switch : 데이터 링크 계층에서 작동하며 물리 포트에서 전송된 패킷을 MAC 주소로 스위칭한다 (로컬)
• Switching : 노드 간 연결을 중개하는 것을 뜻한다
• Router : 네트워크 계층에서 작동하며 다른 네트워크와 연결한다 (WAN)
• Ethernet : 다수의 시스템이 랜선 / 통신포트로 연결되어 통신하는 구조이다

Network

네트워크 중 가장 유명한 네트워크는 인터넷(Internet)이다. 이러한 인터넷을 구성하는 가장 중요한 2가지는 Router와 DNS 이다. 다시 말해 인터넷은 Router와 DNS의 집합체라고 할 수 있다.

참고 자료

• Host, Switch, Network 이들의 관계에 대해... - 널널한 개발자 TV

• MAC 주소
  • 네트워크 인터페이스 카드(Network Interface Card, NIC)에 대한 식별자
  • NIC 갯수에 따라 여러 개 존재할 수 있다.
  • 하드웨어 주소라고도 하며, 변경 가능하다.
• IP 주소
  • 호스트(Host)에 대한 식별자
  • 호스트(Host): 인터넷에 연결된 컴퓨터(또는 터미널(terminal))
  • NIC 하나 당 여러 개의 IP 주소를 바인딩(binding)할 수 있다.
• Port 번호
  • 소프트웨어 관점에서는 프로세스(Process)에 대한 식별자
  • 커널 관점(전송 계층 관점)에서는 서비스(Service)에 대한 식별자
  • 하드웨어 관점에서는 인터페이스(Interface)에 대한 식별자

참고 랜카드(Lan Card) = 네트워크 인터페이스 카드(Network Interface Card, NIC) = 이더넷카드(Ethernet Card)

참고 자료

• MAC주소, IP주소, Port번호가 식별하는 것 - 널널한 개발자 TV

데코레이터(Decorator)는 타입스크립트에서는 실험적으로 도입된 기능이다. 타입스크립트의 데코레이터는 자바(Java)의 어노테이션이나 파이썬(Python)의 데코레이터와 유사한 기능을 한다.그러나 자바 어노테이션은 컴파일 타임에 상관있지만 타입스크립트 데코레이터는 컴파일 타임에는 상관하지 않기 때문에, 오히려 파이썬(Python)의 데코레이터와 거의 비슷하다고 볼 수 있다.

데코레이터는 일종의 함수로 코드 조각을 장식해주는 역할을 하며, 타입스크립트에서는 그 기능을 함수로 구현하는 것이다. 메소드, 클래스, 프로퍼티, 파라미터 등 위에 @로 시작하는 데코레이터를 선언하여 장식하면 코드가 실행(런타임)이 되면 데코레이터 함수가 실행되어, 장식한 멤버를 보다 강력하게 만들어주는 것이다.

데코레이터를 잘 사용하면 횡단 관심사(cross-cutting concern)를 분리하여 관점 지향 프로그래밍을 적용한 코드를 작성할 수 있다. 또한 데코레이터 패턴은 클래스를 수정하지 않고 클래스의 멤버들의 정의를 수정 및 기능을 확장할 수 있는 구조적 패턴의 하나로, 데코레이터 패턴을 사용하면 전체 기능에 신경 쓰지 않고 특정 인스턴스에 초점을 맞출 수 있다.

지금까지의 데코레이터의 특징 정리하면 다음과 같다.

• 데코레이터는 클래스 선언, 메서드(method), 접근자(accessor), 프로퍼티(property) 또는 매개변수(parameter)에 첨부할 수 있는 특수한 종류의 선언이다.
• 데코레이터 함수에는 target(현재타겟), key(속성이름), descriptor(설명)가 전달된다. (단, 어떤 멤버를 장식했느냐에 따라 인수가 달라짐)
• 메소드나 클래스 인스턴스가 만들어지는 런타임에 실행된다. 즉, 매번 실행되지 않는다.
• 데코레이터는 클래스 또는 클래스 내부의 생성자, 프로퍼티, 접근자, 메서드, 그리고 매개변수에만 장식될 수 있다.

데코레이터 설정

타입스크립트의 데코레이터는 정식 지원하는 문법 기능이 아닌 실험적인(experimental) 기능이다. 타입스크립트에서 데코레이터를 사용하기 위해선 tsconfig.json 파일에서 experimentalDecorators 옵션을 활성화 해야 한다.

// tsconfig.json
{
  "compilerOptions": {
    ...
    "experimentalDecorators": true,
    ...
  }
}

데코레이터 함수 선언과 데코레이터 팩토리

데코레이터 함수 선언

데코레이터를 사용하기 위해서는 테코레이터 함수를 선언해야 한다. 데코레이터 함수는 테코레이팅된 선언(데코레이터가 선언되는 클래스, 메서드 등)에 대한 정보와 함께 호출되는 함수여야 한다.

아래는 메서드 데코레이터의 예시이며 테코레이터 함수의 인자는 어떤 테코레이터 함수이냐에 따라 다르다.

function deco(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
  console.log('데코레이터가 평가됨');
}

class TestClass {
  @deco()
  test() {
    console.log('함수 호출됨');
  }
}

const t = new TestClass();
t.test();

데코레이터가 평가됨
함수 호출됨

데코레이터 팩토리

데코레이터 팩토리 함수(decorator factory function)는 데코레이터 함수를 감싸는 래퍼(wrapper) 함수이다. 보통 데코레이터가 선언에 적용되는 방식을 원하는 대로 바꾸고 싶을 때 사용된다.

프로그래밍에서 함수에게 사용자가 인자를 전달할 수 있는 것과 유사하게, 데코레이터 함수 또한 팩토리를 사용해 사용자로부터 인자를 전달 받도록 설정할 수 있다. 즉, 데코레이터 팩토리는 사용자로부터 전달 받은 인자를, 내부에서 반환되는 데코레이터 함수는 데코레이터로 사용되는 것이다.

아래 예시를 보면, 클로저 변수로 사용자 인자를 받고 리턴값으로 데코레이터 함수를 반환하여 데코레이터를 실행하는 것을 볼 수 있다.

// 데코레이터 팩토리
function deco(value: string) {
  console.log('데코레이터가 평가됨');

  // 데코레이터 함수
  return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
    console.log(value);
  };
}

class TestClass {
  // 데코레이터 팩토리를 사용하면 인자 값을 전달할 수 있다.
  @deco('HELLO')
  test() {
    console.log('함수 호출됨');
}

const t = new TestClass();
t.test();

데코레이터가 평가됨
HELLO
함수 호출됨

데코레이터 합성 / 멀티 데코레이터

데코레이터의 또 다른 장점으로는 하나의 멤버에 동시에 여러 개의 데코레이터를 장식할 수 있는 점이다. 이를 데코레이터 합성(Decorator Composition)이라고도 부른다. 여러 개의 데코레이터를 사용하면 수학의 함수 합성(function compsition)과 같이 합성할 수 있게 되기 때문에 이렇게 부르며, 아래 데코레이터 선언의 합성 결과는 수학적으로 $f(g(x))$와 같다.

@f
@g
test

멀티 데코레이터의 실행 흐름은 다음 순으로 처리된다.

1. 각 데코레이터 표현식은 위에서 아래 방향(⬇︎)으로 평가(evaluate)된다.
2. 실행 결과는 아래에서 위로(⬆︎) 함수를 호출(call)된다.

데코레이터 팩토리를 사용해 멀티 데코레이터의 실행 흐름을 살펴보면 다음과 같다.

// Size 데코레이터 팩토리
function Size() {
  console.log('Size(): 평가됨');
  // Size 데코레이터
  return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
    console.log('Size(): 실행됨');
  };
}

// Color 데코레이터 팩토리
function Color() {
  console.log('Color(): 평가됨');
  // Color 데코레이터
  return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
    console.log('Color(): 실행됨');
  };
}

// Button 클래스 정의
class Button {
  // 메서드에 멀티 데코레이터 적용
  @Size()
  @Color()
  isPressed() {}
}

Size(): 평가됨
Color(): 평가됨
Color(): 실행됨
Size(): 실행됨

이처럼 @expression에서 expression 표현식을 함수로 평가하는 순서는 위에서 아래이다. 그리고 expression이 함수로 평가된(데코레이터 팩토리) 후에, 실행 결과(데코레이터 함수)가 실행되는 순서는 아래에서 위가 된다.

데코레이터 종류

Class Decorator

클래스 데코레이터(class decorator)는 클래스 선언 직전에 선언되는 데코레이터이다. 클래스 데코레이터는 클래스의 생성자의 클래스 정의(definiton)을 읽거나 수정할 수 있어 기존의 클래스 정의를 확장하는 용도로 사용할 수 있다. 선언 파일(*.d.ts)과 선언 클래스(declare class) 내에서는 사용할 수 없다. 클래스 데코레이터 매개변수로는 클래스 생성자 자체를 받게 되는 특징이 있다.

클래스 데코레이터 매개변수

• 첫 번째 argument (constructor) : 클래스(생성자 함수)가 전달된다. 타입스크립트가 클래스를 실행할 때 클래스의 생성자를 데코레이터의 constructor 파라미터로 자동 전달하므로, 생성자를 명시적으로 전달하지 않아도 된다.
• 클래스 데코레이터 리턴값
  • class 또는 void

// 제네릭 - 해당 함수를 호출할 때 동적으로 <>에 정의된 타입을 받음. 여기선 클래스 생성자 타입으로 받는의미
function classDecorator<T extends { new (...args: any[]): {} }>(constructorFn: T)
{
    ... 
} // 리턴값은 class 혹은 void

클래스 데코레이터 예제

아래 예시는 데코레이터가 Test의 constructor를 상속해서 추가로 프로퍼티를 지정하고 리턴해주었는데, 이게 그대로 Test 클래스의 constructor 쪽으로 가서 확장이 된다고 생각하면 된다. 그래서 실행 결과가 기존의 Test의 생성자에 없던 프로퍼티들이 추가된 것으로 데코레이터가 클래스의 멤버를 확장한 것이다.

function classDecorator<T extends { new (...args: any[]): {} }>(constructor: T) {
  // Test 클래스의 constructor를 상속해서 new Test() 가 되면 추가된 생성자도 실행되도록 설정
  return class extends constructor { 
    first_prop = 'override'; // 데코레이터에서 새로 프로퍼티를 덮어씌움
    new_prop = 'new property'; // 데코레이터에서 새로 프로퍼티를 추가
  };
}

@classDecorator
class Test {
  first_prop: string;

  constructor(m: string) {
    this.first_prop = m;
  }
}

let t = new Test('abcdefg');
console.log(t);
console.log( t.first_prop ); // 'override'

// 데코레이터로 설정된 프로토타입 확장은 타입 단언(Type Assertion) 필요
console.log( (t as any).new_prop ); // 'new property'

Test { 
    first_prop: 'override', 
    new_prop: 'new property' 
}
override
new property

클래스 데코레이터 팩토리 사용 예제

클래스 데코레이터에 데코레이터 팩토리를 이용한 예제이다. 데코레이터 팩토리에 전달된 사용자 인자값을 데코레이터 함수에서 사용해 결과를 리턴한다.

// 데코레이터 팩토리
function classDecorator(param1: string, param2: string) {
  // 데코레이터 함수
  return function <T extends { new (...args: any[]): {} }>(constructor: T) {
    return class extends constructor {
      new_prop = param1;
      first_prop = param2;
    };
  };
}

@classDecorator('안녕하세요', '반갑습니다')
class Test {
  first_prop: string;

  constructor(m: string) {
    this.first_prop = m;
  }
}

let t = new Test('world');
console.log(t);

Test { 
    first_prop: '반갑습니다', 
    new_prop: '안녕하세요' 
}

프로토타입(prototype)을 이용한 확장

장식된 클래스의 constructor를 확장하는 것뿐만 아니라 프로토타입을 이용하여 확장할 수 있다.

function classDecoratorFactory<T extends { new (...args: any[]): {} }>(constructorFn: T) {

   // 프로토타입으로 새로운 프로퍼티를 추가
   constructorFn.prototype.print2 = function () {
      console.log('this is print2');
   };
   constructorFn.prototype.gender = 'male';

   // 클래스를 프로퍼티에 상속시켜 새로운 멤버를 추가 설정
   return class extends constructorFn {
      public name = 'mark';
      private _age = 36;

      constructor(...args: any[]) {
         super(args);
      }

      public print() {
         console.log('this is print');
      }
   };
}

@classDecoratorFactory
class Test2 {}

const test2 = new Test2();

console.log(test2); // class_1 { name: 'mark', _age: 36 }

// 클래스 Test의 타입에는 print 함수가 없고, 데코레이터로 동적으로 추가된 형태이니, 타입 단언을 사용
(test2 as any).print(); // this is print 
(test2 as any).print2(); // this is print2 

console.log((test2 as any).gender); // male

Test2 { name: 'mark', _age: 36 }
this is print
this is print2
male

Method decorator

메서드 데코레이터(method decorator)는 메서드 선언 직전에 선언되는 데코레이터로 메서드 관찰, 수정 또는 대체하는 데 사용할 수 있다. 메서드의 속성 설명자(property descriptor)에 적용되고 메서드의 정의를 읽거나 수정할 수 있다. 선언 파일(*.d.ts), 오버로드 메서드(overload method), 선언 클래스에 사용할 수 없다.

참고 Property Descriptor는 객체의 프로퍼티들을 기존보다 정교하게 정의할 수 있는 ES5의 스펙이며, 프로퍼티의 특성을 설명하는 역할을 하는 객체이다. 이 Property Descriptor는 Object.getOwnPropertyDescriptor를 사용해서 가져올 수 있다.

메서드 데코레이터 함수가 전달 받는 인자는 총 3가지로 다음과 같다.

• 첫 번째 argument : static 프로퍼티가 속한 클래스의 생성자 함수 또는 인스턴스 프로퍼티에 대한 클래스의 prototype 객체
• 두 번째 argument : 해당 method의 이름
• 세 번째 argument : 해당 method의 property descriptor

function methodDecorator(
    target: any, // static 메서드라면 클래스의 생성자 함수, 인스턴스의 메서드라면 클래스의 prototype 객체
    propertyKey: string, // 메서드 이름
    descriptor: PropertyDescriptor // 메서드의 Property Descriptor
) {
    ... 
} // return 값 무시됨

메서드 데코레이터는 클래스, 메서드 이름, 호출된 메서드(해당 메서드는 Object.defineProperty()로 만들어 짐)로 정의된 메서드 순으로 전달받는다.

PropertyDescriptor interface PropertyDescriptor는 객체 속성의 특성을 기술하는 객체이다.

interface PropertyDescriptor {
 configurable?: boolean;    // 속성의 정의를 수정할 수 있는지 여부
 enumerable?: boolean;    // 열거형인지 여부
 value?: any;                // 속성 값
 writable?: boolean;        // 수정 가능 여부
 get?(): any;                // getter
 set?(v: any): void;        // setter
}

메서드 데코레이터 예제1

만약 해당 메서드가 호출될 때 특정 무엇인가를 동작시키고 싶다면 데코레이터에서 descriptor를 다음과 같이 재정의 해주면 된다.

function methodDecorator() {
  return function (target: any, property: string, descriptor: PropertyDescriptor) {

    // descriptor.value는 test() 함수 자체를 가리킨다. 이 함수를 잠시 변수에 피신 시킨다.
    let originMethod = descriptor.value; 

    // 그리고 기존의 test() 함수의 내용을 다음과 같이 바꾼다.
    descriptor.value = function (...args: any) {
      console.log('before');
      originMethod.apply(this, args); // 위에서 변수에 피신한 함수를 call, apply, bind 를 통해 호출
      console.log('after');
    };
  };
}

class Test {
  property = 'property';
  hello: string;

  constructor(m: string) {
    this.hello = m;
  }

  @methodDecorator()
  test() {
    console.log('test');
  }
}

let test = new Test("world")
test.test()

before
test
after

데코레이터 인수의 descriptor.value 로 접근하면 장식된 함수 자체로 접근하게 되는데 이를 잠시 백업하고 나중에 실행하는 식으로 응용이 가능하다. 중요한 점은 백업된 메서드를 호출할 때 apply를 이용하여 this를 바인딩해줘야 한다는 점이다. 만일 this를 바인딩하지 않으면 해당 메서드를 어느 객체가 호출 했는지 알 수 없기 때문이다.

메서드 데코레이터 예제2

좀더 응용하자면, 메서드 데코레이터로 특정 메서드의 실행 전/후 로깅, 실행시간을 측정 가능하다.

function methodDecorator() {
  return function (target: any, property: string, descriptor: PropertyDescriptor) {

    // descriptor.value는 test() 함수 자체를 가리킨다. 이 함수를 잠시 변수에 피신 시킨다.
    let originMethod = descriptor.value;

    // 그리고 기존의 test() 함수의 내용을 다음과 같이 바꾼다.
    descriptor.value = function (...args: any) {
      let startTS = new Date().getTime();

      originMethod.apply(this, args); // 위에서 변수에 피신한 함수를 call,apply,bind 를 통해 호출

      let endTS = new Date().getTime();

      console.log(`실행시간: ${(endTS - startTS) / 1000} S`);
    };
  };
}

// ...

test
실행시간: 0 S

Accessor Decorators

접근자 데코레이터(accessor decorator)는 접근자(accessor) 바로 앞에 선언한다. 접근자의 속성 설명자에 적용되고 접근자의 정의를 읽거나 수정할 수 있다. 선언 파일(*.d.ts)과 선언 클래스에는 사용할 수 없다.

접근자(accessor) 객체 프로퍼티를 객체 외에서 읽고 쓸 수 있는 함수이다. 쉽게 말하자면 getter와 setter이다. 타입스크립트에서는 getter, setter를 구현할 수 있는 get, set 키워드가 있다.

접근자 데코레이터 매개변수

• 첫 번째 argument : static 프로퍼티가 속한 클래스의 생성자 함수 또는 인스턴스 프로퍼티에 대한 클래스의 prototype 객체
• 두 번째 argument : 해당 method의 이름
• 세 번째 argument : 해당 method의 property descriptor

접근자 데코레이터 리턴값

• Property Descriptor 형태
• void

접근자 데코레이터 예제

특정 프로퍼티가 열거가 가능하지 결정하는 데코레이터 예제이다.

function Enumerable(enumerable: boolean) {
  return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
    descriptor.enumerable = enumerable;
  };
}

class Person {
  constructor(private name: string) {}

  @Enumberable(true)
  get getName() {
    return this.name;
  }

  @Enumberable(false)
  set setName() {
    this.name = name;
  }
}

const person = new Person('hello');
for (let key in person) {
  console.log(`${key}: ${person[key]}`);
}

결과를 출력하면 getName은 출력되지만 setName은 열거하지 못하게 되었기 때문에 for 문에서 key로 받을 수 없다.

name: hello
getName: hello

Property Decorators

속성 데코레이터(property decorator)는 클래스의 프로퍼티 선언 바로 전에 선언 된다. 속성 데코레이터는 메서드 데코레이터와 다르게 데코레이터 함수에 Property Descriptor가 인자로서 제공되지 않는다는 차이가 있다. 대신에 속성 데코레이터도 마찬가지로 Property Descriptor 형식의 객체를 반환해서 프로퍼티의 설정을 바꿀 수 있다.

속성 데코레이터 매개변수

• 첫 번째 argument : static 프로퍼티라면 클래스의 생성자 함수, 인스턴스 프로퍼티라면 클래스의 prototype 객체
• 두 번째 argument : 해당 property의 이름

속성 데코레이터 리턴값

• Property Descriptor 형태
• void

function propertyDecorator(
  target: any, // static 프로퍼티라면 클래스의 생성자 함수, 인스턴스 프로퍼티라면 클래스의 prototype 객체
  propertyName: string, // 프로퍼티 이름
): any {
    ...
} // return하는 값이 Property Descriptor 형태 또는 void. 이로서 해당 property의 writable 등을 조작할 수 있음

속성 데코레이터 예제

리턴값으로 Object.defineProperty()를 반환함으로써, 이를 통해 속성의 부가적인 설정을 할 수 있다.

예를들어 다음과 같이, 앞의 데코레이터는 boolean 타입의 인자를 전달받아 writable로 설정하게 되는데 writable이 false일 경우 해당 속성은 값을 수정할 수 없게 된다.

function writable(isWritable: boolean) {
  return function (target: any, propertyName: any): any {
    return {
      writable,
    };
  };
}

class Test {
  property = 'property';

  @writable(false)
  public data1 = 0;

  @writable(true)
  public data2 = 0;
}

const t = new Test();
t.data1 = 1000;
t.data2 = 1000; // 런타임 에러 !! - data2는 writable이 false라서 값을 대입할 수가 없다.

속성 데코레이터 getter, setter 설정 예제

좀더 응용하자면 다음과 같이 getter와 setter도 설정이 가능하다.

function SetDefaultValue(numberA: number, numberB: number) {
  return (target: any, propertyKey: string) => {
    const addNumber = numberA * numberB;
    let value = 0;

    // 데코레이터가 장식된 DataDefaultType의 num 이라는 프로퍼티의 객체 getter / setter 설정을 추가한다.
    Object.defineProperty(target, propertyKey, {
      get() {
        return value + addNumber; // 조회 할때는 더하기 시킴
      },
      set(newValue: any) {
        value = newValue - 30; // 설정 할때는 30을 뺌
      },
    });
  };
}

class DataDefaultType {
  @SetDefaultValue(10, 20)
  num: number = 0;
}

const test = new DataDefaultType();

test.num = 30;
console.log(`num is 30, 결과 : ${test.num}`); // num is 30, 결과 : 200

test.num = 130;
console.log(`num is 130, 결과 : ${test.num}`); // num is 130, 결과 : 300

num is 30, 결과 : 200
num is 130, 결과 : 300

Parameter Decorators

매개변수 데코레이터(parameter decorator)는 생성자 또는 메서드의 매개 변수에 선언되어 적용된다. 데코레이터는 가로로 써도 인식되기 때문에 함수의 매개변수 왼쪽 옆에 명시해 주면 된다. 선언 파일(*.d.ts), 선언 클래스에서는 사용할 수 없다.

파라미터 데코레이터 매개변수

• 첫 번째 argument : static 프로퍼티가 속한 클래스의 생성자 함수 또는 인스턴스 프로퍼티가 속한 클래스의 prototype 객체
• 두 번째 argument : 매개변수가 들어있는 method의 이름
• 세 번째 argument : 메서드 파라미터 목록에서의 index

function parameterDecorator(
  target: any, // static 메서드의 파라미터 데코레이터라면 클래스의 생성자 함수, 인스턴스의 메서드라면 prototype 객체
  methodName: string, // 매개변수가 들어있는 메서드의 이름
  paramIndex: number // 매개변수의 순서 인덱스
) {
    ...
} // 리턴값은 무시됨

매개 변수 데코레이터 예제

아래 예제는 제대로 된 값이 전달되었는지 확인하는 데코레이터이다. 매개 변수 데코레이터는 단독으로 사용하기 보다는 메서드 데코레이터와 함께 사용할 때 유용하게 사용된다.

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

// 매개 변수 데코레이터 함수
// target 클래스의 validators 속성에 유효성을 검사하는 함수 할당
function MinLength(min: number) {
  return function(target: any, propertyKey: string, parameterIndex: number) {
    target.validators = {
      minLength: function(args: string[]) {
        return args[parameterIndex].length >= min;
      }
    }
  }
}

// 메서드 데코레이터 함수
function Validate(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
  const method = descriptor.value;

  // 설명자의 value에 유효성 검사 로직이 추가된 함수를 할당
  descriptor.value = function(...args) {
    // target에 저장해둔 validators를 모두 수행한다. 이때 원래 메서드에 전달된 인수들을 각 validator에 전달한다.
    Object.keys(target.validators).forEach(key => {
      if (!target.validators[key](args)) {
        throw new BadRequestException();
      }
    })
    // 기존 함수를 실행
    method.apply(this, args);
  }
}

class User {
  private name: string;

  @Validator
  setName(@MinLength(3) name: string) {
    this.name = name;
  }
}

const t = new User();
t.setName('hello');
console.log('---------------');
t.setName('hi');    // BadRequestException

데코레이터 요약 및 호출 순서

각 데코레이터의 특징을 간략하게 정리하면 다음과 같다.

다양한 타입의 데코레이터에 대한 호출 순서는 다음과 같이 잘 정의되어 있다.

1. 매개 변수, 메서드 데코레이터에 이어서 접근자, 속성 데코레이터가 각 인스턴스 멤버에 적용된다.
   • 평가 순서는 메서드/접근자/속성 > 매개변수
2. 매개 변수 데코레이터에 이어서 메서드, 접근자, 속성 데코레이터가 각 정적 멤버에 적용된다.
   • 평가 순서는 메서드/접근자/속성 > 매개변수
3. 매개 변수 데코레이터가 생성자 > 클래스 데코레이터가 클래스에 적용된다.
   • 평가 순서는 클래스 > 생성자

속성/접근자/메서드 데코레이터의 호출 순서는 코드에서 나타나는 순서에 따라 달라진다.

참고 자료

• 한용재, "NestJS로 배우는 백엔드 프로그래밍", 제이펍, 2022
• https://typescript-kr.github.io/pages/decorators.html
• 타입스크립트 - @데코레이터 개념 & 사용법 정리

• https://itchallenger.tistory.com/765

하드 포크(hard fork)

하드 포크(hard fork)란 기본적으로 이전에는 허용되지 않았으며 불가능했던 작업을 가능하게 만드는 블록체인 소프트웨어에 대한 업그레이드이다. 즉, 개별적인 버전의 분할이 발생하게 된 것이다.

이더리움의 경우 2016년 The DAO 공격에 의해 하드포크를 진행하여 이더리움(Ethereum)과 이더리움 클래식(Ethereum Classic)으로 나뉘어졌다. 하드 포크의 또 다른 예로 비트코인은 2017년 트랜잭션 처리를 위해 분리된 증인(Segregated Witness, SegWit)를 도입하느냐 블록 크기를 늘리느냐에 대한 견해 차이로 하드포크되어 비트코인(Bitcoin)과 비트코인 캐시(Bitcoin Cash)로 나뉘어졌다. 또한 비트코인에서 ASIC을 이용한 채굴로 GPU가 불필요해짐에 따라 이에 불만으로 ASIC 채굴을 금지하는 하드포크로 인해 비트코인으로부터 나와 비트코인 골드(Bitcoin Gold)가 나오게 되었다.

이처럼 기존 블록체인에 호환이 되지 않는 기능을 추가하기 위해서는 체인 분할이 필수적이며 이를 하드 포크(hard fork)라고 부른다.

이는 분산 시스템에서 자주 발생하는 일인데 참여자들이 본인들의 미래를 직접 결정하고 현상에 만족스럽지 못한 참여자가 있다면 충분한 지지가 있을 때 자체적으로 네트워크를 분할해서 그들만의 블록체인을 시작할 수도 있는 것이다. 이는 막거나 허용하지 않는 중앙 당국이 없기 때문에 원하는 대로 할 수 있는 것이며, 이 시스템의 미학이라고 할 수 있다.

여기서 중요한 것운 우선 하드 포크 자체가 분할을 초래하는 것이 아니다. 특정 사안이 만족스럽지 못한 사람들이 있을 때만 분할이 발생하는 것이다. 만약 비트코인 캐시의 경우, 모든 이가 블록의 크기를 8MB로 늘리는 것에 동의했다면 전체 비트코인 네트워크가 8MB로 바뀌어 이 그대로를 비트코인이라고 불렀을 것이다. 즉, 하드 포크란 소프트웨어를 지칭하는 용어이며, 체인이 아닌 소프트웨어에 대한 작업이다.

소프트 포크(soft fork)

소프트 포크(soft fork)는 기존 블록체인의 기능을 일부 수정하는 것을 말한다. 하드포크와 달리 기존 블록체인의 기본 구조는 변경되지 않고 부분적인 기능 개선만 이루어지는 것이다. 즉, 기존 블록체인과 호환되지 않는 하드 포크와 달리 소프트 포크는 기존 블록체인의 프로토콜을 그대로 따르기 때문에 호환이 가능하다.

이러한 소프트 포크의 예로는 비트코인의 분리된 증인(Segregated Witness, SegWit)이 있다. 비트코인은 세그윗을 도입하기 위해 포크를 진행하였지만 세그윗은 기존 비트코인의 프로토콜을 따르기 때문에 다른 체인으로 분리되지 않으며, 기존 비트코인과 호환이 가능하다. 즉, 소프트 포크가 일어난 것이다.

초기 인터넷은 정적 이미지와 텍스트로만 이루어져 있어 HTML만 있다면 웹페이지를 만드는데 충분했다. 이후 인터넷은 발전하여 많은 일을 처리할 수 있게 되었고, 필요한 애플리케이션 역시 웹과 모바일 앱 양쪽으로 작성되고 있다. 이를 위해 자바스크립트는 화면을 동적으로 구성하기 위한 필수적인 도구로 떠올랐고 웹 기반 애플리케이션을 작성하기 위해 반드시 배워야하는 언어가 되었다.

이전에는 웹 페이지에서 구동되는 애플리케이션은 모두 SSR(server-side rendering) 방식으로 동작했다. 즉, 서버가 요청을 처리하고 HTML과 자바스크립트 응답을 브라우저에 전송하면 브라우저는 서버가 전송한 HTML 코드를 화면에 그려주고 동적으로 구성되는 부분은 함께 전달된 자바스크립트를 파싱하여 화면을 구성하였다.

하지만 시간이 지나면서 웹 기술은 복잡해지며 발전하였고, 웹 앱을 만드는데 필요한 기술들을 기존의 방식으로 개발하기에는 시간과 노력이 많이 들었다. 이에 따라웹 개발에 필요한 요소들을 묶어 개발자들이 쉽게 사용할 수 있도록 하고자하는 시도가 생겨났으며, 이러한 결과물들을 웹 프레임워크(web framework)라고 한다.

이러한 웹 프레임워크들은 다양하게 존재하기 때문에 선택에 어려움이 존재한다. 이 때 다음 사항들을 고려하면 좋다.

• 개발 문서
  • 쉽게 이해할 수 있게 잘 쓰인 개발 문서는 생산성을 올려준다.
• 사용자 수
  • 사용자 수가 많다는 것은 안정적으로 운용되고 있다는 것에 증거이다.
  • 궁금한 점을 커뮤니티를 통해 쉽게 찾을 수 있다.
• 활성 커뮤니티
• 깃허브 스타 수와 이슈 대응

Node.js

Node.js는 2009년에 릴리스되었다. 그 전까지 자바스크립트는 프런트엔드에서만 사용하는 언어라는 인식이 강했고 실제로도 그랬다. 웹 시장이 커지자 동적 페이지를 다루기 위해 HTML 내 <script> 태그로 삽입하여 주로 사용하였다. 그러나 브라우저에 삽입된 소스 코드가 그대로 노출되므로 보안에 취약하다는 인식이 있었고, 사용은 많이 하지만 '어디까지나 스크립트 언어'라는 괄시를 받기도 하였다.

이후 Node.js의 등장으로 자바스크립트를 이용해 서버를 구동할 수 있게 되었으며, 자바스크립트는 하나의 언어로 인정받게 되었다. 또 2008년 구글은 크롬 브라우저를 출시하면서 자체 개발한 자바스크립트 엔진인 V8을 크롬에 내장했고, 이 V8 엔진의 뛰어난 성능을 '자바스크립트는 느리다'라는 인식을 바꾸었다.

Node.js는 npm이라는 패키지 관리 시스템을 가지고 있어 누구나 자신이 만든 Node.js 기반 라이브러리를 등록해 다른 사람들이 사용할 수 있도록 공개할 수 있다. npm에 따르면 2022년 3월 기준 등록된 패키지 수가 약 190만개에 다다른다.이런 많은 패키지로 인해 많은 커뮤니티가 생성되고 자바스크립트와 Node.js의 입지는 증가하였다. 이러한 영향으로 인해 npm에 공개되어 있는 대부분의 소스 코드가 깃허브에 공개되어 있는데 깃허브는 2020년 3월에 npm을 인수하였다. 깃허브는 마이크로소프트가 인수하였으므로 사실상 npm은 마이크로소프트가 주도하게 되었다.

이러한 Node.js의 특징은 다음과 같다.

단일 스레드에서 구동되는 논블로킹 I/O 이벤트 기반 비동기 방식

여러 작업 요청이 한번에 많이 들어올 때, 각 작업을 처리하기 위한 스레드를 만들고 할당하는 방식을 멀티스레딩(multi-threading)이라고 한다. 멀티스레딩 방식은 여러 작업을 동시에 처리하기 때문에 처리 속도가 빠르기만, 공유 자원을 관리해야하고 잘 못하면 교착 상태(dead lock, 데드락)이 발생할 수 있다. 또한 스레드가 늘어날 때마다 메모리를 소모하기 때문에 메모리 관리 또한 중요하다.

이에 비해 Node.js는 단일 스레드에서 작업을 처리한다. 사실 애플리케이션 단에서는 단일 스레드이지만 백그라운드에서는 스레드 풀을 구성해 작업을 처리한다. Node.js는 개발자 대신 Node.js에 포함된 비동기 I/O 라이브러리인 libuv에서 스레드 풀을 관리하기 때문에 개발자는 단일 스레드에서 동작하는 것처럼 쉬운 코드를 작성할 수 있다. 웹 서버를 운용할 때는 CPU 코어를 분산해 관리하기 때문에 실제 작업은 여러 개의 코어에서 별개로 처리된다.

libuv Node.js에서 사용하는 비동기 I/O 라이브러리이다. 커널을 사용해 처리할 수 있는 비동기 작업을 발견하면 바로 커널로 넘기고, 이후 해당 작업들이 종료되어 커널로부터 시스템 콜을 받으면 이벤트 루프에 콜백을 등록한다. 커널이 지원하지 않는 작업일 경우 별도의 스레드에서 작업을 처리한다.

Node.js는 이렇게 들어온 작업을 앞의 작업이 끝날 때까지 기다리지 않고(논블로킹(non-blocking) 방식) 비동기로 처리한다. 즉, 입력은 하나의 스레드에서 받지만 순서대로 처리하지 않고 먼저 처리된 결과를 이벤트로 반환해주는 방식이 바로 Node.js가 사용하는 단일 스레드 논블로킹 이벤트 기반 비동기 방식이다.

Node.js의 장단점

이러한 단일 스레드 논블로킹 이벤트 기반 비동기 방식은 서버의 자원에 크게 부하를 가하지 않는다. 이는 대규모 네트워크 애플리케이션을 개발하기에 적합하지만 스레드를 하나만 사용하기 때문에 하나의 스레드에 문제가 생기면 애플리케이션 전체가 오류를 일으킬 위험이 있다.

하나의 스레드로 동작하는 것처럼 코드를 작성할 수 있다는 것은 개발자에게 큰 장점이다. 멀티 스레드를 직적 만들고 관리하며, 데드락을 생각할 필요가 없기 때문이다.

Node.js의 단점은 컴파일러 언어의 처리 속도에 비해 성능이 떨어진다는 점이다. 하지만 서버의 성능과 자바스크립트 엔진의 성능도 계속 늘어나고 있거 웬만한 웹 애플리케이션을 만들기에 충분하다. 다만 이벤트 기반 비동기 방식으로 복잡한 기능을 구현하다 보면 여러 이벤트를 동시에 처리하는 경우 '콜백 지옥'에 빠져 가독성이 떨어지는 코드가 만들어 질 수 있다.

하지만 ECMAScript 2016(ES6)에서 프로미스(Promis)가 도입되면서 간결한 표현으로 작성할 수 있게 되었고, ECMAScript 2017(ES7)에서는 async/await가 추가되면서 비동기 코드를 마치 동기적으로 처리하는 것처럼 코드를 작성할 수 있게 되었다.

이벤트 루프(Event Loop)

이벤트 루프(event loop)는 시스템 커널에서 가능한 작업이 있다면 그 작업을 커널에 이관하는 역할을 한다. 자바스크립트가 단일 스레드 기반이지만 Node.js가 논블로킹 I/O 작업을 수행할 수 있도록 해주는 핵심 기능이다.

이벤트 루프에는 6 단계로 이루어져 있다. 아래 그림은 위 그림의 이벤트 루프 동작 방식을 좀 더 단순화한 것이다. 각 단계는 처리해야 하는 콜백 함수를 담기 위한 큐(queue)를 가지고 있으며, 화살표는 각 단계가 전이되는 방향을 뜻한다. 꼭 반드시 다음 단계로 넘어가는 것은 아니다.

각 단계에는 해당 단계에서 실행되는 작업을 저장하는 큐(queue)가 있다. 또한 이벤트 루프의 구성 요소는 아니지만 nextTickQueue와 microTaskQueue가 존재한다. nextTickQueue와 microTaskQueue에 들어 있는 작업은 이벤트 루프가 어느 단계에 있든지 실행될 수 있다.

자바스크립트 코드는 유휴, 준비(idle, prepare) 단계를 제외한 어느 단계에서나 실행될 수 있다. node main.js 명령어로 Node.js 애플리케이션을 콘솔에서 실행하면 Node.js는 먼저 이벤트 루프를 생성한 다음 메인 모듈인 main.js를 실행한다. 이 과정에서 생성된 콜백들이 각 단계에 존재하는 큐에 들어가게 되는데, 메인 모듈의 실행을 완료한 다음 이벤트 루프를 계속 실행할 지 결정한다. 큐가 모두 비어 더 이상 수행할 작업이 없다면 Node.js는 루프를 빠져나가고 프로세스를 종료한다.

각 단계를 차례대로 살펴보자.

타이머(Timer) 단계

이벤트 루프는 타이머 단계(timer phase)에서 시작한다. 타이머 단계의 큐에는 setTimeout이나 setInterval과 같은 함수를 통해 만들어진 타이머들을 큐에 넣고 실행한다. now - registeredTime >= delta인 타이머들이 큐에 들어간다. 여기서 delta는 setTimeout(() => {}, delta)와 같이 타이머가 등록된 시각에서 얼마나 시간이 흐른 후 동작해야 하는지를 나타내는 값으로 대상 타이머들은 이미 실행할 시간이 지났다는 뜻이다. 타이머들을 최소 힙(min heap)으로 관리되며, 힙을 구성할 때 기준으로 실행할 시각이 가장 적게 남은 타이머가 힙의 루트가 된다. 이 단계에서는 최소 힙에 들어 있는 타이머들을 순차적으로 찾아 실행 후 힙을 재구성한다.

최소 힙(min heap) 최솟값을 찾기 위해 완전 이진 트리를 사용하는 자료구조

실행할 시간이 지난 타이머들의 콜백이 무한정 실행되는 것은 아니고 시스템의 실행 한도(hardl limit)에 도달하면 다음 단계로 넘어간다.

대기 콜백(Pending I/O callbacks) 단계

대기 단계(pending i/o callbacks phase)의 큐(pending_queue)에 들어 있는 콜백들은 현재 돌고 있는 루프 이전의 작업에서 큐에 들어온 콜백이다. 예를 들어 TCP 핸들러 내에서 비동기의 쓰기 작업을 한다면, TCP 통신과 쓰기 작업이 끝난 후 해당 작업의 콜백이 큐에 들어오며, 에러 핸들러 콜백도 pending_queue에 들어 온다.

타이머 단계를 거처 대기 콜백 단계에 들어오면, 이전 작업들의 콜백이 pending_queue에서 대기 중인지를 검사한다. 만약 실행 대기 중이라면 시스템 실행 한도에 도달할 때까지 꺼내 실행한다.

유휴, 준비(Idle, prepare) 단계

유휴 단계(idle phase)는 틱(tick)마다 실행되며, 준비 단계(prepare phase)는 매 폴링 직전에 실행된다. 이 두 단계는 Node.js의 내부 동작을 위한 것이다.

틱(tick) 프로그램 실행 시 최소 간격을 말하며 '틱 카운트'라고도 한다. 이벤트 루프에서는 각 단계가 이동하는 것을 뜻한다.

폴(Poll) 단계

폴 단계(poll phase)는 이벤트 루프 중 가장 중요한 단계로 새로운 I/O 이벤트를 가져와 관련 콜백을 수행한다. 예를 들어 소켓 연결과 같은 새로운 커넥션을 맺거나 파일 읽기와 같이 데이터 처리를 받아들인다.

이 단계가 가지고 있는 큐는 watch_queue이다. 이 단계에 진입한 후 *watch_queue가 비어 있지 않다면, 큐가 비거나 시스템 실행 한도에 다다를 때까지 동기적으로 모든 콜백을 실행한다. 만약 큐가 비게 되면 Node.js는 바로 다음 단계로 이동하지 않고 *check_queue(체크 단계의 큐), pending_queue(대기 콜백 단계의 큐), closing_queue(종료 콜백 단계의 큐)에 남은 작업이 있는지 검사한 후 작업이 있다면 다음 단계로 이동한다. 만약 큐가 모두 비어 해야할 작업이 없다면, 잠시 대기를 한다(타이머 최소 힙의 첫 번째 타이머를 꺼내 지금 실행할 수 있는 상태라면 그 시간만큼 대기 후 다음 단계로 이동한다.). 이렇게 하는 이유는 타이머 단계로 넘어가도 어짜피 첫 번째 타이머를 수행할 시간이 되지 않았기 때문에 이벤트 루프를 한 번 더 돌아야 하기 때문이다.

체크(Check) 단계

체크 단계(check phase)는 setImmediate의 콜백 만을 위한 단계이다. 큐가 비거나 시스템 실행 한도에 도달할 때까지 콜백을 수행한다.

종료 콜백(Close callbacks) 단계

종료 콜백 단계(close callbacks phase)에서는 socket.on('close', () => {})과 같은 close나 destory 이벤트 타입의 콜백이 처리된다. 이벤트 루프는 종료 콜백 단계를 마치고 나면 다음 루프에서 처리해야 하는 작업이 남아 있는지 검사한다. 만약 작업이 남아 있다면 타이머 단계부터 한 번 더 루프를 돌고, 아니라면 루프를 종료한다.

nextTickQueue, microTaskQueue

한편 nextTickQueue는 process.nextTick() API의 콜백들을 가지고 있으며, *microTaskQueue는 resolve된 Promise의 콜백을 가지고 있다. 즉, *libuv 라이브러리에 포함된 것이 아닌 Node.js에 포함된 기술이다. 이 두 큐에 들어 있는 콜백은 단계를 넘어가는 과정에서 먼저 실행되며, nextTickQueue는 microTaskQueue보다 높은 우선순위를 가지고 있다.

패키지 의존성 관리

package.json

Node.js 관련 프로젝트를 생성하게 되면 package.json 파일이 존재하게 된다. 생성된 package.json 파일의 역할은 다음과 같다.

• 애플리케이션이 필요 하는 패키지 목록 나열
• 각 패키지는 시멘틱 버저닝(semantic versioning) 규칙으로 필요한 버전을 기술한다.
• 다른 개발자와 같은 빌드 환경을 구성할 수 있어 버전이 달라 발생하는 문제를 예방할 수 있다.

유의적 버전(semantic versioning)은 패키지의 버전명을 숫자로 관리하는 방법으로 많이 사용되고 있으며 규칙은 다음과 같다.

[Major].[Minor].[Patch]-[label]

Major, Minor, Patch는 각각 숫자를 사용한다. 규칙에 따라 1.2.3-beta와 같이 사용한다.

• Major
  • 이전 버전과 호환이 불가능할 때 숫자를 하나 증가시킨다.
  • Major 버전이 바뀐 패키지를 사용하려면 반드시 breaking change(하위 호환성이 깨진 기능) 목록을 확인하고 이전 기능을 사용하는 코드를 수정해야 한다.
• Minor
  • 기능이 추가되는 경우 숫자를 증가시킨다.
  • 숫자가 증가되어도 이전 버전과 호환이 가능하다.
• Patch
  • 버그 수정 패치를 적용할 때 사용한다.
• label
  • 선택 사항으로 pre, alpha, beta와 같이 버전에 대해 부가 설명을 붙이고자 할 때 문자열로 작성한다.

유의적 버전을 사용할 때 완전히 동일한 버전만을 정의해야하는 것은 아니다. 다음과 같은 규칙을 사용해 의존성을 해치지 않는 다른 버전을 설치할 수 있다.

• ver: 완전히 일치하는 버전
• =ver: 완전히 일치하는 버전
• >ver: 큰 버전
• >=ver: 크거나 같은 버전
• <ver: 작은 버전
• <=ver: 작거나 같은 버전
• ~ver: 버전 범위(지정한 마지막 자리 내 범위)
  • ~1.0, 1.0.x: 1.0.0 이상 1.1.0 미만의 버전
• ^ver: SemVer 규약을 따른다는 가정에서 동작하는 규칙
  • ^1.0.2: 1.0.2 이상 2.0 미만의 버전
  • ^1.0: 1.0.0 이상 2.0 미만의 버전
  • ^1: 1.0.0 이상 2.0 미만의 버전

package-lock.json

프로젝트 루트 디렉토리에서 npm install 명령을 수행하면 node_modules 디렉토리와 package-lock.json 파일이 생성된다. node_modules는 프로젝트가 필요한 패키지들이 실제로 설치되는 장소이다. 애플리케이션은 런타임에 여기에 설치된 패키지들을 참조한다. package-lock.json 파일은 package.json에 선언된 패키지들이 설치될 때의 정확한 버전과 서로 간의 의존성을 표현한다.

package-lock.json 파일은 node_modules나 package.json 파일의 내용이 바뀌면 npm install 명령을 수행할 때 자동 수정된다. 만약 소스 코드 내에 package-log.json 파일이 이미 존재한다면 npm install 명령을 수행할 때 이 파일을 기준으로 패키지들을 설치하게 된다. 따라서 이를 이용해 팀원들 간의 정확한 개발 환경을 공유할 수 있기 때문에 소스 코드 저장소에서 관리해야 한다.

package.json 파일 분석

NestJS로 생성된 프로젝트의 package.json 파일을 바탕으로 package.json에 기술된 내용을 살펴볼 것이다.

{
  "name": "test",            // 1
  "version": "0.0.1",        // 2
  "description": "",        // 3
  "author": "",                
  "private": true,            // 4
  "license": "UNLICENSED",    // 5
  "scripts": {                // 6
    "prebuild": "rimraf dist",
    "build": "nest build",
    "format": "prettier --write \"src/**/*.ts\" \"test/**/*.ts\"",
    "start": "nest start",
    "start:dev": "nest start --watch",
    "start:debug": "nest start --debug --watch",
    "start:prod": "node dist/main",
    "lint": "eslint \"{src,apps,libs,test}/**/*.ts\" --fix",
    "test": "jest",
    "test:watch": "jest --watch",
    "test:cov": "jest --coverage",
    "test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand",
    "test:e2e": "jest --config ./test/jest-e2e.json"
  },
  "dependencies": {            // 7
    "@nestjs/common": "^9.0.0",
    "@nestjs/core": "^9.0.0",
    "@nestjs/platform-express": "^9.0.0",
    "reflect-metadata": "^0.1.13",
    "rimraf": "^3.0.2",
    "rxjs": "^7.2.0"
  },
  "devDependencies": {        // 8
    "@nestjs/cli": "^9.0.0",
    "@nestjs/schematics": "^9.0.0",
    "@nestjs/testing": "^9.0.0",
    "@types/express": "^4.17.13",
    "@types/jest": "28.1.8",
    "@types/node": "^16.0.0",
    "@types/supertest": "^2.0.11",
    "@typescript-eslint/eslint-plugin": "^5.0.0",
    "@typescript-eslint/parser": "^5.0.0",
    "eslint": "^8.0.1",
    "eslint-config-prettier": "^8.3.0",
    "eslint-plugin-prettier": "^4.0.0",
    "jest": "28.1.3",
    "prettier": "^2.3.2",
    "source-map-support": "^0.5.20",
    "supertest": "^6.1.3",
    "ts-jest": "28.0.8",
    "ts-loader": "^9.2.3",
    "ts-node": "^10.0.0",
    "tsconfig-paths": "4.1.0",
    "typescript": "^4.7.4"
  },
  "jest": {                    // 9
    "moduleFileExtensions": [
      "js",
      "json",
      "ts"
    ],
    "rootDir": "src",
    "testRegex": ".*\\.spec\\.ts$",
    "transform": {
      "^.+\\.(t|j)s$": "ts-jest"
    },
    "collectCoverageFrom": [
      "**/*.(t|j)s"
    ],
    "coverageDirectory": "../coverage",
    "testEnvironment": "node"
  }
}

1. name: 패키지 이름이다. version과 함께 고유한 식별자가 된다. 패키지를 npm에 공개하지 않는다면 선택 사항이다.
2. version: 패키지의 버전이다.
3. description: 패키지에 대한 설명이다.
4. private: true로 설정할 경우 공개되지 않는다.
5. license: 패키지의 라이센스이다. 공개된 패키지를 사용할 때 참고해야 한다.
6. scripts: npm run 명령과 함께 수행할 수 있는 스크립트이다. 스크립트를 이용해 다양한 기능을 구현할 수 있다.
7. dependencies: 패키지가 의존하는 다른 패키지들이 표기되어 있다. 프로덕션 환경에서 필요한 주요 패키지를 선언한다.
8. devDependencies: dependencies와 같은 기능을 하지만 개발 환경 또는 테스트 환경에서만 필요한 패키지를 여기서 선언한다. 실 사용 서비스에서는 불필요한 패키지를 설치하지 않도록 해야 한다.
9. jest: 테스팅 라이브러리 Jest를 위한 환경 구성 옵션이다. NestJS는 기본으로 Jest를 이용한 테스트를 제공한다.

참고 자료

• 한용재, "NestJS로 배우는 백엔드 프로그래밍", 제이펍, 2022
• https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
• https://www.voidcanvas.com/nodejs-event-loop

NestJS의 장점

NestJS는 Node.js에 기반을 둔 웹 API 프레임워크로서 Express 또는 Fastify 프레임워크를 래핑(wrapping)하여 동작한다.

래핑(Wrapping) 랩(wrap)으로 감싸듯이 기존의 라이브러리 등을 조금 더 사용이 쉽고 수월하게 한번 더 만드는 것

기본적으로 NestJS는 Express를 사용한다. Fastify는 밴치마크상으로 Express에 비해 약 2배 정도 빠르지만 Express가 가장 널리 사용되고 있고 Express 기반 미들웨어가 NestJS와 호환되기 때문이다.

미들웨어(Middleware) 서비스 및 기능을 애플리케이션에 제공하는 소프트웨어

Node.js는 쉽게 사용할 수 있고 확장성이 좋지만, 과도한 유연함으로 인해 결과물인 소프트웨어의 품질이 일정하지 않고 적절한 라이브러리를 찾기 위해 사용자가 많은 시간을 사용해야한다. 이를 보완하기 위해 NestJS는 데이터베이스, 객체 관계 매핑(object-reletional mapping, ORM), 설정(configuration), 유효성 검사 등 많은 기능을 기본 제공하면서도 필요한 라이브럴리르 쉽게 설치하여 확장할 수 있는 Node.js의 장점을 그대로 가지고 있다.

NestJS는 앵귤러(Angular)의 영향을 많이 받았다. 모듈/컴포넌트 기반으로 프로그램을 작성할 수 있어 재사용성을 높이고, 제어의 역전(inversion of control, IoC), 의존성 주입(dependency injection, DI), 관점 지향 프로그래밍(aspect-oriented programming, AOP) 같은 객체 지향 개녕을 도입하였다. 또한 타입스크립트(typescript)를 기본으로 사용하여 타입스크립트가 가진 타입 시스템의 장점을 누릴 수 있다.

웹 프레임워크가 갖추어야 할 필수 기능이라면 다음과 같은 것들이 있다.

• 최신 ECMA 스크립트 지원
• 타입스크립트(선택 사항이지만 사용 추세가 계속 늘어나고 있음)
• CQRS(command query responsibility separation)
• HTTP 헤더 보안(Express는 helmet을 사용)
• 편리한 설정
• 인터셉터(Interceptor)
• 다양한 미들웨어(middleware)
• 스케줄링(scheduling)
• 로깅(logging)
• 테스팅(testing)
• 스웨거(Swagger) 문서화
• ORM

NestJS는 이 중 대부분을 프레임워크에 내장하고 있고, 내장하지 않는 기능들은 쉽게 다른 모듈을 가져다 사용할 수 있다.

Express vs NestJS

Express는 이미 많은 회사들이 선택하여 운용되고 있는 검증된 프레임워크이다. 그러나 NestJS 또한 Express를 기본으로 선택하고 그 위에 여러 기능을 미리 구현해놓은 것이다. 이 둘을 간단히 비교하면 다음과 같다.

State of JS 2021에 따르면 아직 사용 경험은 많지 않다. Express가 상위에 있는 이유는 다른 프레임워크들이 Express 기반으로 만들어진 이유도 있다.

이어서 설문 조사 결과를 살펴볼 것인데, SvelteKit, Astro, Remix, Next.js, Nuxt, Gatsby는 엄밀히 말해 모두 프런트엔드의 영역에 가깝고 순수 백엔드 프레임워크라고는 할 수 없다. 그러나 프레임워크가 해결하고자 하는 목적에 맞게 도입해서 함께 사용하면 좋은 프레임워크들이다.

이를 이해하고 State of JS 2021를 기반으로 만족도와 인지도 등의 측면에서 살펴보자.

만족도

NestJS 사용자들의 만족도는 여러 프레임워크 중 중간 정도 순위로 85% 정도로 나왔다.

인지도

NestJS의 인지도는 69% 정도로 Express의 97%라는 수치에 비해서는 낮다. 따라서 인기 있는 Express를 사용하는 것이 좋아보이지만 상용 제품을 만들기까지 시간이 오래 걸릴 수 있다. Express를 사용하면 필요한 라이브러리들을 npm에서 찾고 검토하는 과정이 필요하기 때문이다.

반면에 NestJS는 백엔드 서버가 갖추어야할 많은 필수 기능을 프레임워크 내에 내장하고 있고, 필요한 기능을 추가 설치 및 적용하기 쉽다. 또한 IoC, DI를 채택하여 객체 지향 프로그래밍과 모듈화를 쉽게 할 수 있다.

성능

Nestjs 깃허브에는 PR이 제출될 때마다 Express, Fastify와의 성능 벤치마크 결과가 공개된다.

이는 각 PR의 Checks 탭에서 확인할 수 있으며, 위의 벤치마크 결과는 2023년 1월 6일에 merge된 #10811 PR의 결과이다.

NestJS에서는 Express와 Fastify를 적용했을 경우를 각각 구분하고, Express/Fastify 자체 성능도 측정한다. 측정 결과를 보면, Express가 Fastify보다 느리고, NestJS에 각각을 적용하면 약간 더 성능이 떨어지는 것을 알 수 있다. 이는 NestJS가 기본 제동하는 프레임워크의 크기가 크기 때문이다. 그러나 순수 Express/Fastify로 서버를 개발하다 보면 필수로 요구하는 라이브러리들을 추가하기 때문에 결국 NestJS에서 제공하는 기능을 모두 구현하면 성능 차이는 크지 않을 것이다.

지속 가능성

Express 깃허브를 보면 최근 4.18.2 버전을 업데이트했지만 그 전까지는 몇 년간 개발이 정체되어 있었따. 5.0을 준비하고 있기도 하고 매우 안정적인 프레임워크라서 문제없이 운용되고 있다는 증거로도 볼 수 있지만 최신 트렌드를 따라가지 못한다는 우려가 있다. 그러나 NestJS는 꾸준히 발전하고 있으며, 깃허브를 통해 커뮤니케이션도 활발히 하고 있다.

NestJS 설치

Node.js 설치

NestJS는 Node.js를 기반으로 한다. 따라서 먼저 Node.js를 먼저 다운로드 해야 한다. 안정적인 버전인 LTS를 선택하여 설치하는 것을 권장하며 Node.js 공식 사이트를 통해 설치할 수 있다.

NestJS 설치 및 프로젝트 생성

Node.js를 설치하면 기본적으로 Node.js의 패키지 매니저인 npm이 함께 설치된다. npm을 통해 https://www.npmjs.com/에 등록된 라이브러리 및 프레임워크들을 쉽게 설치, 삭제할 수 있게 해준다.

NestJS를 사용하기 위해서 먼저 @nestjs/cli를 설치해야한다.

$ npm i -g @nestjs/cli

i 명령어는 install 명령어의 약어이다. -g 옵션은 컴퓨터의 클로벌 환경에 설치하겠다는 것으로 모든 디렉토리에서 해당 패키지를 실행할 수 있다. 참고로 글로벌 환경에서 패키지가 설치되는 경로는 npm root -g 명령어로 확인할 수 있다.

이제 콘솔에 nest, nest -h 또는 nest --help라고 입력하면 @nest/cli가 제공하는 기능의 목록을 볼 수 있다.

$ nest

다양한 기능이 있지만 우리는 NestJS 프로젝트를 생성할 것이기 때문에 아래 명령어를 통해 프로젝트를 생성할 것이다.

$ nest new <project-name>

project-name에 해당하는 부분에 자신이 원하는 프로젝트 명을 기입하여 생성할 수 있다. 설치 도중 패키지 매니저를 어느 것으로 정할 것인지 묻는 화면이 나오면 원하는 것으로 선택하면 된다. 가장 무난한 것으로는 npm이며, yarn과 npnpm 또한 *npm과 함께 많이 쓰이는 자바스크립트 라이브러리 패키지 매니저이다.

설치를 마치면 보일러플레이트(boilerplate) 코드가 생성되어 아래처럼 디렉토리 구조를 구성한다.

보일러플레이트(boilerplate) 코드 꼭 필요한 기본 기능을 미리 준비해놓은 코드

아래 명령어를 통해 실행할 수 있다.

$ npm run start:dev

운영이 아닌 개발 단계에서는 npm run start가 아닌 npm run start:dev 명령어를 이용한 것이 좋다. package.json를 보면 start:dev키에 해당하는 값은 nest start --watch로 --watch 옵션은 소스 코드 변경을 감지하여 코드를 저장할 때마다 서버를 다시 구동하는 옵션이다.

포트는 기본적으로 3000번으로 설정되어 있는데, main.ts 파일을 보면 포트 설정 코드를 볼 수 있다.

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);    // 포트 설정 부분
}
bootstrap();

참고 자료

• 한용재, "NestJS로 배우는 백엔드 프로그래밍", 제이펍, 2022
• https://2021.stateofjs.com/en-US/libraries/back-end-frameworks/

solidity 내에서도 주석을 사용할 수 있다.

먼저 // 은 한 줄 주석이다. 주석을 달 부분에 //를 추가하면 쉽게 주석을 달 수 있다. 또한 여러 줄의 주석을 사용하고 싶다면 /*, */을 사용하면 된다. 두개의 사이에 여러 줄의 주석을 사용하면 된다.

주석을 사용하여 자신이 코드를 작성한 의도를 적는 것이 좋다. 특히, 함수에서 예상되는 행동값을 자네의 코드에 주석으로 설명한다면, 다른 개발자들(또는 6개월 동안 프로젝트를 멈춘 후 자네 자신!)이 코드 자체를 다 읽어보지 않고 훑어보더라도 큰 맥락에서 그 코드를 이해할 수 있다.

NatSpec Format

Solidity에서는 특수한 형태의 주석을 사용하여 함수, 반환 변수 등에 대한 풍부한 문서를 제공할 수 있다.

이를 위해 NatSpec Format 이라고 한다. NatSpec Format은 the Ethereum Natural Language Specification Fromat의 약자로 solidity 커뮤니티에서 표준으로 쓰이는 주석 형식이다.

NatSpec Format으로 만들어진 주석은 컴파일러를 통해 따로 JSON 파일로 추출해 낼 수 있다. 또한 NatSpec Format은 개발자 중심 메세지와 최종 사용자 대상 메세지로 구분되며, 이러한 메세지는 컨트랙트와 상호작용할 때(즉, 트랜잭션에 서명할 때) 최종 사용자에게 표시될 수 있다.

NatSpec Format 예시

NatSpec Format은 컨트랙트에서 각각 contract, interface, library, function, event, 변수(vaiable)들에서 사용할 수 있다.

한 줄을 위한 NatSpec Format은 ///을 사용하고, 여러 줄을 위한 NatSpec Format은 /**, */을 사용한다.

아래는 NatSpec 예시이다.

/// @title 기본적인 산수를 위한 컨트랙트
/// @author H4XF13LD MORRIS 💯💯😎💯💯
/// @notice 지금은 곱하기 함수만 추가한다.
contract Math {
  /// @notice 2개의 숫자를 곱한다.
  /// @param x 첫 번쨰 uint.
  /// @param y 두 번째 uint.
  /// @return z (x * y) 곱의 값
  /// @dev 이 함수는 현재 오버플로우를 확인하지 않는다.
  function multiply(uint x, uint y) returns (uint z) {
    // 이것은 일반적인 주석으로, natspec에 포함되지 않는다.
    z = x * y;
  }
}

태그(Tags)

위 예시에도 나타나 있듯이 NatSpec은 태그를 이용해 문서를 설명한다. 모든 태그들은 선택적이며, 만약 태그가 사용되지 않았다면 컴파일러는 해당 줄을 @notice로 태그가 지정된 것으로 간주한다.

아래는 각 NatSpec 태그의 용도와 사용 위치를 설명하는 표이다.

Dynamic expressions

Solidity 컴파일러는 solidity 코드에서 JSON 출력으로 NatSpec 문서로 전달한다. 출력된 JSON은 최종 사용자에게 직접 제공하거나 일부 전처리를 적용할 수 있다.

예를 들어 어떠한 함수에 다음과 같은 NatSpec이 있다고 하자.

/// @notice This function will multiply `a` by 7

만약 함수가 호출되고 a에 10이라는 값이 전달 되었다면, 최종 사용자에게는 다음과 같이 표기된다.

This function will multiply 10 by 7

이러한 동적 표현을 지정하는 것은 radspec 프로젝트에 자세하게 설명되어 있다.

Inheritance Notes

NatSpec을 사용하지 않는 함수들은 자동으로 해당 컨트랙트의 기본 함수의 문서를 자동으로 상속한다.

이에 대한 예외는 다음과 같다.:

• 매개변수 이름이 다른 경우
• 하나 이상의 기본 기능이 있는 경우
• 문서 상속의 사용할 컨트랙트를 지정하는 명시적인 태그인 @inheridoc 태그가 존재할 경우

Documentation Output

// ex1.sol
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.8.2 < 0.9.0;

/// @title A simulator for trees
/// @author Larry A. Gardner
/// @notice You can use this contract for only the most basic simulation
/// @dev All function calls are currently implemented without side effects
/// @custom:experimental This is an experimental contract.
contract Tree {
    /// @notice Calculate tree age in years, rounded up, for live trees
    /// @dev The Alexandr N. Tetearing algorithm could increase precision
    /// @param rings The number of rings from dendrochronological sample
    /// @return Age in years, rounded up for partial years
    function age(uint256 rings) external virtual pure returns (uint256) {
        return rings + 1;
    }

    /// @notice Returns the amount of leaves the tree has.
    /// @dev Returns only a fixed number.
    function leaves() external virtual pure returns(uint256) {
        return 2;
    }
}

컴파일러에 의해 구문 분석될 때 위와 같은 예제는 두개의 서로 다른 JSON 파일을 생성한다. 하나는 최종 사용자가 기능 실행 시 알림으로 사용하기 위한 것이고, 다른 하나는 개발자가 사용하가 위한 것이다.

다음과 같은 명령어로 생성할 수 있다.

solc --userdoc --devdoc ex1.sol

Note solidity 0.6.11 버전 이후로 NatSpec 출력에서는 version 및 kind 필드도 포함된다. 현재 version은 1로 설정되며, kind는 user 또는 dev이어야 한다. 추후 이전 버전을 더 이상 사용하지 않는 새 버전이 도입될 수도 있다.

사용자 문서 예시

{
  "version" : 1,
  "kind" : "user",
  "methods" :
  {
    "age(uint256)" :
    {
      "notice" : "Calculate tree age in years, rounded up, for live trees"
    }
  },
  "notice" : "You can use this contract for only the most basic simulation"
}

개발자 문서 예시

{
  "version" : 1,
  "kind" : "dev",
  "author" : "Larry A. Gardner",
  "details" : "All function calls are currently implemented without side effects",
  "custom:experimental" : "This is an experimental contract.",
  "methods" :
  {
    "age(uint256)" :
    {
      "details" : "The Alexandr N. Tetearing algorithm could increase precision",
      "params" :
      {
        "rings" : "The number of rings from dendrochronological sample"
      },
      "return" : "age in years, rounded up for partial years"
    }
  },
  "title" : "A simulator for trees"
}

참고 자료

• https://docs.soliditylang.org/en/v0.8.17/natspec-format.html
• https://github.com/aragon/radspec

#include <algorithm>

// default (1)
template <class ForwardIterator>  bool is_sorted (ForwardIterator first, ForwardIterator last);

// custom (2)    
template <class ForwardIterator, class Compare>  bool is_sorted (ForwardIterator first, ForwardIterator last, Compare comp);

범위 내의 요소들이 정렬되어 있는지 확인하는 함수이다. 기본적으로 오름차순(asceding)으로 정렬되어 있는지 확인하며, comp를 통해 정렬 기준을 정하여 정렬되어 있는지 확인할 수 있다.

시간 복잡도는 $O(N)$이다. 여기에서 $N$은 범위의 첫 번째와 마지막 사이의 거리이다. std::is_sorted()는 범위 내에서 정렬이 맞지 않는 것이 발견될 때까지 요소의 쌍을 비교한다.

Parameters

comp 함수의 원형을 아래와 같은 형태를 취해야 한다.

bool cmp(const Type &a, const Type &b);

Return value

• 주어진 범위내 정렬되어 있을 경우 true
  • 주어진 범위 내 요소가 1개일 경우 항상 true를 반환한다.
• 주어진 범위내 정렬되어 있지 않은 경우 false

Example

Do not use comp

#include <iostream>
#include <algorithm>

int main()
{
    int A[] = { 10, 11, 15, 12 };

    // Index 0 to 2
    int range1 = 3;

    // Index 0 to 3
    int range2 = 4;

    if (std::is_sorted(A, A + range1)) {
        std::cout << "Sorted in the range : " << range1 << std::endl;
    } else {
        std::cout << "Not Sorted in the range : " << range1 << std::endl;
    }

    if (std::is_sorted(A, A + range2)) {
        std::cout << "Sorted in the range : " << range2 << std::endl;
    } else {
        std::cout << "Not Sorted in the range : " << range2 << std::endl;
    }

    return 0;
}

Output

Sorted in the range : 3
Not Sorted in the range : 4

use comp

#include <iostream>
#include <algorithm>

using namespace std;

bool ignore_case(char a, char b)
{
    // Converts both characters to lowercase and checks if a <= b
    return (tolower(a) <= tolower(b));
}

// Function that checks if string is sorted while ignoring the case
bool check_if_sorted(string str)
{
    // Function call to is_sorted with binary predicate ignore_case
    return is_sorted(str.begin(), str.end(), ignore_case);
}

int main()
{
    // String which is to be checked
    string str = "tOY";

    // Function returned true, string is sorted
    if (check_if_sorted(str)) {
        cout << "Sorted";
    }
    // Function returned false, string not sorted
    else {
        cout << "Not sorted";
    }

    return 0;
}

Output

Not sorted

참고 자료

• https://cplusplus.com/reference/algorithm/is_sorted/?kw=is_sorted
• https://www.geeksforgeeks.org/stdis_sorted-in-cpp/

• call()은 address 데이터 타입 내에 존재하는 메서드로 다른 컨트랙트와 상호작용하는 저수준(low lever) 함수다.
• call()를 이용해 송금을 하거나 다른 스마트 컨트랙트의 함수를 호출할 수 있다.
• 가변적인 가스(gas)가 발생한다.
  • send() 와 trasfer()의 경우 2,300 gas를 발생시킨다.
• 이스탄불 하드포크(2019년 12월) 이후 gas 가격 상승에 따른 다른 스마트 컨트랙트 상호 작용 시 call() 사용을 권장한다.
  • send() 와 trasfer()이 소비하는 2,300 gas 로는 다른 스마트 컨트랙트을 작동하기에는 부족할 수 있기 때문이다.
• re-entrancy(재진입) 공격 위험이 있기 때문에, Check Effects Interactions Pattern을 사용해야 한다.
  • 또는 재진입 가드를 사용하여 해결할 수 있다.
• 유형 검사, 함수 존재 확인 및 인수 패킹을 우회하기 때문에 fallback 함수 호출을 통해서 이더를 보낼경우에 추천하지만, 존재하는 함수를 호출하는 방법으로는 추천하지 않는다.

사용 형태

call() 은 다양한 형태로 사용된다.

call 함수를 이용한 non-payable 함수 호출

function myFunction(uint _x, address _addr) public returns(uint, uint) {
    // do something
    return (a, b);
}

// function signature string should not have any spaces
(bool success, bytes memory result) = addr.call(abi.encodeWithSignature("myFunction(uint,address)", 10, msg.sender));

다른 컨트랙트의 함수를 호출할 때 사용되는 형태이다. 반환값은 함수 호출의 성공, 실패를 반환하는 bool과 호출한 함수의 반환값을 담는 bytes이며, abi.decode()로 변환하여 사용 가능하다.

(bool success, ) = addr.call(abi.encodeWithSignature("myFunction(uint,address)", 10, msg.sender));

호출한 함수의 반환값이 존재하지 않는다면 위와 같이 bytes를 생략해도 된다.

(bool success, bytes memory result) = addr.call("");

call에 전달된 함수가 존재하지 않으면 해당 스마트 컨트랙트의 fallback 함수가 호출된다. 만약, fallback 함수가 구현되지 않았다면, call()는 false를 반환한다.

(bool success, bytes memory result) = addr.call{gas: 1000000}(abi.encodeWithSignature("myFunction(uint,address)", 10, msg.sender));

위와 같이 호출할 함수에서 사용될 가스비를 지정해 줄 수도 있지만, 가스비를 하드코딩하는 것은 권장되지 않는다. 만약 사용할 가스비를 지정하지 않는다면, call() 함수전에 남아 있는 모든 가스가 호출할 함수로 공급된다.

call 함수를 이용한 payable 함수 호출

function myFunction(uint _x, address _addr) public payable returns(uint, uint) {
    // do something
    return (a, b);
}

(bool success, bytes memory result) = addr.call{value: msg.value}(abi.encodeWithSignature("myFunction(uint,address)", 10, msg.sender));

value를 통해 이더를 호출할 수 있다.

(bool success, bytes memory result) = addr.call{value: msg.sender}("");

call에 전달된 함수가 존재하지 않으면 해당 스마트 컨트랙트의 receive 함수가 호출된다. 만약, receive 함수가 구현되지 않았다면 fallback 함수가 호출되고, fallback 함수가 구현되지 않았다면 call()는 false를 반환한다.

(bool success, bytes memory result) = addr.call{value: msg.value, gas: 1000000}(abi.encodeWithSignature("myFunction(uint,address)", 10, msg.sender));

마찬가지로 권장되지 않지만 가스비를 하드코딩하는 것도 가능하다.

예제

아래 컨트랙트를 call()을 이용해 호출하는 예제들이다.

contract callee {
    event JustFallback(string _str);
    event JustReceive(string _str);

    function addNumber(uint256 _num1, uint256 _num2) public pure returns (uint256) {
        return _num1 + _num2;
    }

    fallback() external {
        emit JustFallback("JustFallback is called");
    }

    received() external {
        emit JustReceive("JustReceive is called");
    }
}

call() 이용한 송금

contract callSend {
    function transferEther(address payable _to) public payable {
        (bool success, ) = _to.call{value: msg.value}("");
        require(sucess, "failed to transfer ether");
    }
}

call() 이용한 외부 컨트랙트 함수 호출

contract callFunction {
    event calledFunction(bool _success, bytes _data);

    function callMethod(address _contractAddress, uint256 _num1, uint256 _num2) public {
        (bool success, btyes memory data) = _contractAddress.call(
            abi.encodeWithSignature("addNumber(uint256, uint256)", _num1, _num2);
        );
        require(success, "failed to call outer function");
        emit calledFunction(success, data);
    }
}

참고 자료

• https://solidity-by-example.org/call/
• https://dayone.tistory.com/37?category=918008
• https://kushgoyal.com/ethereum-solidity-how-use-call-delegatecall/
• https://kimsfamily.kr/514
• https://docs.openzeppelin.com/contracts/4.x/api/security#ReentrancyGuard

solidity는 0.6.0 버전 이후로 fallback 함수가 receive와 fallback으로 나뉘어졌다. 0.6.0 버전 이전의 fallback 함수는 이더를 보내거나 받을 때 실행되지만 0.6.0 버전 이후의 fallback 함수는 이더를 보낼 때 실행되고, 이더를 받을 때는 receive 함수가 실행된다. 즉, 하나의 기능을 세분화시켜 두가지로 나누어 놓은 것으로, 여기에서는 0.6.0 버전 이후의 fallback 함수에서 분화된 receive 함수를 소개할 것이다.

컨트렉트의 호출 함수가 확인되지 않을 때, 함수에서 이더를 보낼 때(transfer) 디폴트 함수로 동작하는 fallback 함수와는 다르게 receive 함수는 오직 이더를 받을 때 디폴트 함수로 실행된다.

선언 형태

receive 함수는 다음과 같은 형태로 선언된다.

receive() external payable {
    // ...
}

특징

• external과 payable 식별자가 필요하다.
• 각 컨트렉트는 하나의 receive 함수를 선언할 수 있다.
• 함수는 파라미터를 가질 수 없다.
• virtual 식별자를 사용할 수 있으며, override가 가능하다.

예제

아래 예제로 작성된 컨트랙트 주소(CA)로 사용자 지갑(EOA)에 있는 이더를 전송하면, 컨트렉트는 receive 함수를 호출할 것이다.

//SPDX-License-Identifier: MIT
pragma solidity 0.8.3;

contract FunctionsExample {

    mapping(address => uint) public balanceReceived;

    function receiveMoney() public payable {
        assert(balanceReceived[msg.sender] + msg.value >= balanceReceived[msg.sender]);
        balanceReceived[msg.sender] += msg.value;
    }

    function withdrawMoney(address payable _to, uint _amount) public {
        require(_amount <= balanceReceived[msg.sender], "not enough funds.");
        assert(balanceReceived[msg.sender] >= balanceReceived[msg.sender] - _amount);
        balanceReceived[msg.sender] -= _amount;
        _to.transfer(_amount);
    } 

    receive() external payable {
        receiveMoney();
    }
}

참고 자료

• https://docs.soliditylang.org/en/v0.8.17/contracts.html#receive-ether-function
• https://log4day.tistory.com/13
• https://dayone.tistory.com/36

fallback 함수는 무기명 함수 즉, 이름이 없는 함수이며 컨트랙트에서 하나의 디폴트 함수와 같다. fallback 함수는 직접 호출되지 않으며, 다음과 같은 상황에서 실행된다.

• 호출한 함수가 컨트렉트 내에서 조회되지 않을 경우
  • 외부에서 특정 컨트렉트를 호출했을 때, 해당 호출 주소(function identifier)가 확인되지 않으면 디폴트로 fallback 함수가 실행된다.
• 이더(ETH, ether)를 보낼 때 자동으로 실행

다시 말해, 스마트 컨트렉트에 함수로 요청을 보냈는데 실제로 없는 함수를 호출하거나 또는 이더를 보낼 때 fallback 함수가 디폴트로 실행된다. fallback 함수는 디폴트 함수와 같기 때문에 solidity에서 하나의 컨트렉트는 하나의 fallback 함수를 가질 수 있다.

solidity는 0.6.0 버전 이후로 fallback 함수가 receive와 fallback으로 나뉘어졌다. 0.6.0 버전 이전의 fallback 함수는 이더를 보내거나 받을 때 실행되지만 0.6.0 버전 이후의 fallback 함수는 이더를 보낼 때 실행되고, 이더를 받을 때는 receive 함수가 실행된다. 즉, 하나의 기능을 세분화시켜 두가지로 나누어 놓은 것이다. 여기에서는 0.6.0 버전 이후의 fallback 함수를 소개할 것이다.

선언 형태

fallback 함수는 다음과 같은 형태로 선언된다.

// 선언 유형 1
fallback () external [payable] {
    // ...
}

// 선언 유형 2
fallback (bytes calldata _input) external [payable] returns (bytes memory _output) {
    // ...
}

특징

• function 키워드가 없다.
• external 식별자가 붙는다.
• 함수 이름이 없다. (fallback으로 고정)
• 파라미터(parameter)를 받지 않는다.
  • 2번째 유형에서 byte calldata 형태의 파라미터를 설정하면 컨트랙트에 보내진 모든 데이터(= msg.data)를 반환하게 할 수 있다.
• 반환값이 없다.
  • 2번째 유형의 경우 컨트랙트에 보내진 모든 데이터(= msg.data)를 반환하게 할 수 있다.
• payable 옵션 적용 시, 이더를 받고 나서도 실행된다.
  • 기본은 이더 전송(transfer) 시점에서 실행된다.
• payable fallback 함수에서는 2300 gas 제한이 존재한다.
• virtual 키워드를 가질 수 있기 때문에 override 할 수 있다.
• modifier들을 가질 수 있다.

예제

아래 예제는 솔리티디 공식 문서 내에 존재하는 예제이다.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.6.2 <0.9.0;


contract Test {
    uint x;

    // 해당 코드는 Test 컨트렉트에 보내지는 모든 메세지에 대한 응답 코드로 작성하였다.
    //     ->    fallback 함수는 컨트렉트에서 조회한 함수가 없을 때 호출되기 때문
    // 이 컨트렉트 주소로 보내지는 이더를 전송(transfer) 요청은 예외를 발생시킬 수 있다.
    //    ->    `payable` 옵션이 없기 때문
    fallback() external { x = 1; }
}


contract TestPayable {
    uint x;
    uint y;

    // 이더를 보내는 요청이 아닌 모든 요청에서 fallback이 실행된다. - 컨트렉트 어카운트에서 이더 전송
    // 데이터를 포함한 요청에서 fallback 함수를 실행하게 한다.
    fallback() external payable { x = 1; y = msg.value; }

    // 이더를 보내는 요청에서 아래 함수는 실행된다. - 컨트렉트 어카운트로 이더 받음
    // 데이터가 포함되어 있지 않은 요청에서 함수 실행
    receive() external payable { x = 2; y = msg.value; }
  }


contract Caller {
    function callTest(Test test) public returns (bool) {
        (bool success,) = address(test).call(abi.encodeWithSignature("nonExistingFunction()"));

        // 조건식 -> test.x == 1
        require(success);

        // address(test)는 fallback 함수에 payable 옵션이 없기 때문에 send 요청을 할 수 없다.
        //    ->    address(test)는 address payable으로 변환 되어야 한다.
        address payable testPayable = payable(address(test));

        // 먄약 누군가 이더를 아래와 같이 보낸다면, 요청을 실패할 것이다. (return = false) 
        return testPayable.send(2 ether);
    }

    function callTestPayable(TestPayable test) public returns (bool) {
        (bool success,) = address(test).call(abi.encodeWithSignature("nonExistingFunction()"));

        // 조건식 -> test.x == 1 && test.y == 0
        require(success);

        (success,) = address(test).call{value: 1}(abi.encodeWithSignature("nonExistingFunction()"));

        // 조건식 -> test.x == 1 && test.y == 1
        require(success);

        // 누군가 이더를 아래와 같이 이더를 보내면 해당 컨트렉트의 receive 함수가 호출될 것이다.
         //    ->    실제 이더 전송에 필요한 가스는 더 많이 필요할 것이다. 해당 함수가 storage에 접근하기 때문
        (success,) = address(test).call{value: 2 ether}("");

        // 조건식 -> test.x == 2 && test.y == 2
        require(success);

        return true;
    }
}

참고 자료

• https://docs.soliditylang.org/en/v0.8.17/contracts.html#fallback-function
• https://log4day.tistory.com/12
• https://dayone.tistory.com/36
• https://kimsfamily.kr/514

• 솔리디티에는 tx.origin이라는 전역 변수가 있다.
• tx.origin은 call을 호출한 계정의 주소를 저장한다.

msg.sneder vs tx.origin

msg.sender와 tx.origin의 차이점을 알아보기 위해 아래와 같은 상황이 있다고 하자.

해당 상황은 다음과 같다.

1. 일반 이더리움 지갑 주소에 불과한 Externally Owned Address(EOA)을 가진 사용자가 컨트랙트 A를 배포한다.
2. 사용자가 컨트랙트 A의 함수 one()을 호출하면 내부의 함수 two()를 호출하고, 해당 함수는 내부적으로 컨트랙트 B의 함수 three()의 함수를 호출한다.

이러한 상황에서 컨트랙트 B에 대해 msg.sender는 컨트랙트 A가 될 것이다. 하지만 tx.origin은 트랜잭션을 시작한 주소가 된다. 즉, 이 경우 사용자(EOA)가 된다.

정리하자면,

• msg.sender
  • 함수의 호출자
  • 스마트 컨트랙트 또는 사용자(EOA)가 될 수 있다.
• tx.origin
  • 실제 트랜잭션이 시작한 사용자(EOA)
  • 스마트 컨트랙트는 서명된 트랜잭션을 보낼 수 없기 때문에 tx.origin는 컨트랙트가 될 수 없다.

tx.origin 인증 공격

tx.origin 인증 공격은 위와 같이 스마트 컨트랙트에서 tx.origin을 이용해 인증 작업을 하는 상황에서 실행할 수 있는 공격 방법이다.

예를 들어 다음과 같은 스마트 컨트랙트가 존재한다고 하자.

contract Phishable {
    address public owner;

    constructor (address _owner) {
        owner = _owner;
    }

    // 이더를 모으는 fallback 함수
    fallback () external payable {
        // ...
    }

    function withdrawAll(address _recipient) public payable {
        require(tx.origin == owner);
        _recipiect.transfer(this.balance);
    }
}

해당 컨트랙트는 tx.origin을 통해 인증을 하고 withdrawAll() 함수로 해당 컨트랙트의 이더를 전송하도록 구현되어 있다. 이 경우 공격자는 아래와 같은 컨트랙트를 작성해 공격하여 컨트랙트의 이더를 제한 없이 받을 수 있다.

interface Phishable {
    // ...
    function withdrawAll(address _recipient) external;
}

contract AttackContract {
    Phishable pishableContract;
    address attacker;

    constructor (Phishable _phisiableContract, address _attacker) {
        phishableContract = Phishable(_phishableContract);
        attacker = _attacker;
    }

    // 공격을 위한 fallback 함수
    fallback () external payable {
        phishableContract.withdrawAll(attacker);
    }
}

위의 공격 컨트랙트는 다음과 같이 실행된다.

1. 공격자는 owner에게 AttackContract가 일반 계정인 것 처럼 속여 해당 계정에 이더을 보내도록 유도한다.
2. AttackContract에게 owner가 이더를 보내게 되면, 공격을 위한 fallback 함수가 실행된다.
3. 해당 fallback 함수는 Phishable 컨트랙트의 withdrawAll() 함수를 호출하는데, 인자로 해커의 계정 주소를 넣는다.
4. 해당 트랜잭션의 tx.origin은 owner이다.
   • owner가 AttackContract에게 이더를 전송해AttackContract의 fallback 함수를 호출했고, 거기서 다시 Phishable의 withdrawAll() 함수를 호출했기 때문이다.
   • 이는 tx.origin은 call을 시작한 계정 정보를 계속 유지하고 있기 때문에 가능하다.
5. 공격은 성공하고 Phishable 컨트랙트에 모아진 이더는 공격자에게 전송된다!

이처럼 tx.origin을 사용하는 것은 위험하며, 최대한 사용하지 않는 것이 좋다. 솔리디티 공식 문서에서도 사용하지 않는 것을 강력 권장하고 있다.

해결법

• tx.orgin 대신 msg.sender를 사용하자.
• 꼭 사용해야하는 상황일 경우 외부 컨트랙트가 현재 컨트랙트를 호출하지 못하게 막기 위해 require(tx.origin == msg.sender)같은 방법을 사용하자.

참고 자료

• https://docs.soliditylang.org/en/v0.8.17/security-considerations.html#tx-origin
• https://blog.finxter.com/tx-origin-phishing-attack-smart-contract-security-series-part-4/
• https://steemit.com/kr/@etainclub/16-tx-origin

The DAO

The DAO는 최초의 탈중앙화된 자율조직으로 2016년 이더리움을 통해 Vitalik과 다른 사람들이 개발하였다.

핵심 프로토콜은 이더리움이었고, 벤처 투자 조합이라는 목적으로 설립되었다. 창립자들은 The DAO를 통해 이더리움 블록체인 상에 구현할 탈중앙화된 애플리케이션(Dapp) 개발을 지원하고, 블록체인을 통해서 본인들의 프로젝트를 탈중앙화하여 구현하려는 조직들을 도우려고 하였다.

The DAO는 탈중화된 자율조직 즉, DAO이기 때문에 국적이 없는 상태였기 때문에 권한에 대한 문제가 제기될 만했지만 그 문제는 차치하고 넘어갔다.

The DAO 공격

The DAO가 설립되고 활동하던 도중 The DAO는 토큰 판매를 통해서 크라우드 펀딩을 진행했다. 크라우드 펀딩이 끝난 2016년 5월까지 역사상 가장 성공적인 크라우드 펀딩 캠페인 모금액인 총 1억 5천만 달러가 모였다.

사람들은 블록체인에 무언가를 구현한다는 탈중앙화라는 개념과 새로운 형태의 인터넷 그리고 새로운 형태의 세계로 이동한다는 생각을 그저 믿고 있었다.

탈중앙화된 자율조직(DAO)은 전적으로 사람이 아닌 스마트 컨트랙트을 통해 운영되는데, 안타깝게도 The DAO의 코드에는 에러가 있었다. 즉, 이 자율조직에 스마트 컨트랙트에 오류가 있었던 것이다.

이에 따라 The DAO는 2016년 6월에 해킹 공격을 당해 5천만 달러를 잃었다. 여기서 흥미로운 점은 공격자가 실질적으로 아무런 불법도 저지르지 않았다는 것이다. 그들은 단지 코드에서 결함을 발견하고 이를 이용해서 본인들의 계좌로 돈을 빼냈을 뿐이다.

하지만 아무 조치도 취할 수 없었죠 The DAO는 자율조직이기 때문에 자율적으로 정해진 알고리즘과 코드를 따를 뿐이기 때문이다.

그리고 계약서에도 결함이 있었기 때문에 공격자가 계약의 일부로서 이를 유효한 트랜잭션처럼 실행시킬 수 있었다. 이때 계약서는 불변이며 블록체인 상에 존재하기 때문에 수정할 수도 없다.

하지만 여기서 좋은 소식은 The DAO가 코딩된 방식에 따르면 실패 방지 메커니즘이 존재하기 때문에 이번 경우처럼 공격자가 The DAO의 자회사인 다른 계정으로 돈을 옮겼다가 이들을 완전히 가지고 가는 경우가 발생하더라도 자금을 이동시키는 데에 30일가량이 필요하도록 설정되어 있디. 그 시간에 모두가 머리를 맞대 어떤 결정을 내릴지 숙고할 수 있는 것이다.

DAO의 딜레마와 이더리움

DAO의 딜레마

위에 상황과 같은 상황에서 딜레마가 발생한다. 바로 '코드는 법인가?'라는 딜레마이다.

커뮤니티의 한편에서는 DAO에서 코드는 법이기 때문에 이를 아무 말 없이 따를 것이다.

또 한편에서는 5천만 달러는 너무 많은 돈이고 이는 사람들의 소유라고 할 것이다. 따라서 이들은 블록체인에 하드 포크를 적용하고 규칙을 바꾸자고 주창할 것이다. 즉, 하드 포크를 적용하고 규칙을 바꾸어서 결국에는 계약의 규칙을 바꿀 수 있게 되는 것이며, 기본적으로 계약의 규칙을 파기하고 돈을 회수해서 다시 주인에게 돌려주자는 뜻이다.

이더리움 하드 포크

이런 *딜레마 끝에 하드 포크를 실행한다는 결정이 내려졌으며, Vitalik의 계획 하에 하드 포크로 이루어졌다.

하드 포크라고 해서 항상 분할을 뜻하는 것은 아니지만 이 경우에는 분할이 발생했다. 이는 일부가 이 결정에 만족하지 못했기 때문인데 공격자를 보호하려는 뜻에서가 아니라 이 블록체인 개념의 무결성을 보존하고자 하는 뜻에서 스마트 계약을 존중하는 것이 올바르다고 생각했기 때문이다.

이 하드 포크 작업에서 이더리움은 이더리움(Ethereum, ETH)과 이더리움 클래식(Ethereum Classic, ETC)으로 분할된다.

하드 포크 된 이더리움에서는 해커의 돈이 다시 The DAO의 손에 돌아가고 사람들에게 잘 분배가 되었으나 이더리움 클래식에서는 해커의 돈이 이더리움 클래식에 남게 되었다.

참고 자료

• "이더 도둑" - Matthew Leising Matthew Leising, (2017), The Ether Thief

C++에서 클래스 템플릿(class template)이란 클래스의 일반화된 선언을 의미한다.

클래스 템플릿을 사용하면, 타입에 따라 다르게 동작하는 클래스 집합을 만들 수 있다. 즉, 클래스 템플릿에 전달되는 템플릿 인수(template argument)에 따라 별도의 클래스를 만들 수 있게 된다. 템플시 인수는 타입이거나 명시된 타입의 상수값일 수 있다.

클래스 템플릿 문법

클래스 템플릿은 다음과 같은 문법으로 정의할 수 있다.

template <typename 타입 이름>
class 클래스 템플릿 이름
{
    // ...
}

C++98에서 추가된 typename 키워드는 이전에 class 키워드를 사용했기 때문에 템플릿 정의 내에서 typename 키워드 대신에 class 키워드를 사용할 수 있다.

클래스 템플릿 예제

#include <iostream>

tmplate <typename T>
class Data
{
private:
    T data_;
public:
    Data(T dt);
    T get_data();
}

int main()
{
    Data<string> str_data("클래스 템플릿");
    Data<int> int_data(12);

    std::cout << "str_data : " << str_data.get_data() << std::endl;
    std::cout << "int_data : " << int_data.get_data() << std::endl;
    return 0;
}

template <typename T>
Data<T>::Data(T dt)
{
    data_ = dt;
}

template <typename T>
T Data<T>::get_data()
{
    return data_;
}

Output

str_data : 클래스 템플릿
int_data : 12

클래스 템플릿의 특징

클래스 템플릿은 다음과 같은 특징을 가진다.

1. 하나 이상의 템플릿 인수를 가지는 클래스 템플릿을 선언할 수 있다.

    // 두 개의 템플릿 인수를 가지는 클래스 템플릿 선언
    template <typename T, int i>
    class X
    { ... }

2. 클래스 템플릿에 디폴트 템플릿 인수를 명시할 수 있다.

    // 디폴트 템플릿 인수의 타입을 int형으로 명시
    template <typename T = int, int i>
    class X
    { ... }

3. 클래스 템플릿을 기초 클래스로 하여 상속할 수 있다.

    // 클래스 템플릿 X를 상속받음
    template <typename T>
    class Y : public X <T>
    { ... }

특수화(specialization)

암시적 특수화(implicit specialization)

클래스 템플릿이 각각의 타입에 대해 처음으로 호출될 때, C++ 컴파일러는 해당 타입의 인스턴스(instance)를 생성한다.

생성된 인스턴스는 해당 타입에 대해 암시적으로 해당 타입에 특수화된 템플릿 함수이다. 따라서 해당 인스턴스는 함수 템플릿에 해당 타입이 사용될 때마다 호출된다.

명시적 특수화(explicit specialization)

클래스 템플릿은 특정 타입이나 값의 템플릿 인수에 대해 특수화를 할 수 있다. 특수화를 명시하면, 해당 타입에 대한 특변한 동작을 정의할 수 있다.

컴파일러는 전달된 인수에 정확히 대응하는 특수화된 정의를 발견하면, 더는 다른 템플릿을 찾지 않고 해당 정의를 사용한다.

명시적 특수화 예제

double형에 대한 명시적 특수화를 추가시킨 예제이다.

#include <iostream>

tmplate <typename T>
class Data
{
private:
    T data_;
public:
    Data(T dt);
    T get_data();
}

// double형에 대한 명시적 특수화
template <>
class Data<double>
{
private:
    double data_;
public:
    Data(double dt) { data_ = dt; }
    double get_data();
    {
        std::cout << "double형 데이터를 출력합니다." << std::endl;
        return data_;
    }
}


int main()
{
    Data<string> str_data("클래스 템플릿");
    Data<double> double_data(3.14);

    std::cout << "str_data : " << str_data.get_data() << std::endl;
    std::cout << "double_data : " << double_data.get_data() << std::endl;
    return 0;
}

template <typename T>
Data<T>::Data(T dt)
{
    data_ = dt;
}

template <typename T>
T Data<T>::get_data()
{
    return data_;
}

Output

str_data : 클래스 템플릿
double형 데이터를 출력합니다.
double_data : 3.14

std::basic_string, std::string

클래스 템플릿의 대표적인 예 중에 하나는 std::basic_string이다.

std::basic_string은 문자 유형에서 문자열을 만들기 위한 클래스 탬플릿이다.

template <class charT, class traits = char_traits<charT>, class Alloc = allocator<charT>> class basic_string;

이러한 std::basic_string에 대해 char 형에 대한 명시적 특수화를 한 클래스의 typedef 한 클래스가 std::string이다.

typedef basic_string<char> string;

부분 특수화(partial specialization)

만약 템플릿 인수가 2개 이상이고, 그 중 일부에 대해서만 특수화를 해야할 때는 부분 특수화(partial specialization)을 할 수 있다.

부분 특수화 방법은 먼저 template 키워드 다음에 나오는 꺾쇠괄호(<>)에 특수화하지 않는 타입의 템틀릿 인수를 명시한다. 그리고 다음에 다오는 꺾쇠괄호(<>)에 특수화하는 타입을 명시하면 된다.

부분 특수화 예제

template <typename T1, typename T2>
class X
{ ... }

템플릿 인수가 2개인 위의 템플릿 클래스 X를 double형에 대해 부분 특수화를 하면 다음과 같다.

template <typename T1>
class X<T1, double>
{ ... }

모든 템플릿 인수를 특수화하게 되면, 앞서 살펴본 완전한 명시적 특수화가 된다.

template <>
class X<double, double>
{ ... }

중첩 클래스 템플릿(nested class template)

C++에서 클래스나 클래스 템플릿 내에 또 다른 템플릿을 중첩하여 정의할 수 있으며, 이러한 템플릿을 멤버 템플릿(member template)이라고 한다.

멤버 템플릿 중 클래스 템플릿을 중첩 클래스 템플릿(nested calss template)이라고 한다. 이러한 중첩 클래스 템플릿은 바깥쪽 클래스 범위 내에서 클래스 템플릿으로 선언되며, 정의는 바깥쪽 클래스의 범위 내애서 뿐만아니라 범위 밖에서도 가능하다.

중첩 클래스 템플릿 문법

중첩 클래스 템플릿은 다음과 같은 문법으로 정의할 수 있다.

template <typename T>
class X
{
    template <typename U>
    class Y
    {
        // ...
    }

    // ...
}

int main()
{
    // ...
}

template<typename T>
template<typename U>
X<T>::Y<U>::멤버함수이름()
{
    // 멤버 함수 구현
}

이처럼 바깥쪽 클래스인 X의 외부에 중첩 클래스 템플릿 Y를 정의하면, 클래스 템플릿의 템플릿 인수와 멤버 템플릿의 템플릿 인수가 둘 다 앞에 명시되어야 한다.

템플릿을 위한 새로운 이름

C++11부터는 typedef 키워드를 이용해 템플릿 특수화를 위한 새로운 이름을 선언할 수 있다.

typedef X<double, 3.14> DoubleX;

// double_x는 X<double, 3.14> 타입이다.
DoubleX double_x;

참고 자료

• http://www.tcpschool.com/cpp/cpp_template_class
• https://stackoverflow.com/questions/1662107/whats-the-difference-between-stdstring-and-stdbasic-string-and-why-are-bot

함수 템플릿(function template)은 함수의 일반화된 선언을 의미한다.

함수 템플릿을 사용하면 같은 알고리즘을 기반으로 하면서, 서로 다른 타입에서 동작하는 함수를 한 번에 정의할 수 있다.

이는 임의의 타입으로 작성된 함수에 특정 타입을 매개변수로 전달하면, C++ 컴파일러에서 해당 타입에 맞는 함수를 생성해주기 때문이다.

함수 템플릿 문법

함수 템플릿은 다음과 같은 문법으로 사용할 수 있다.

template <typename 타입이름>
함수의 원형
{
    // 함수 구현
}

C++98에서 추가된 typename 키워드는 이전에 class 키워드를 사용했다. 따라서 C++ 컴파일러는 템플릿 정의 내의 typename 키워드와 class 키워드를 같은 것으로 간주한다.

typename 키워드를 사용해 정의된 타입 이름은 함수의 원형과 본체에서 임의의 타입으로 사용할 수 있다. typename 키워드로 정의된 매개변수에 어떠한 타입을 전달하면, 함수의 원형과 본체에서 정의된 타입은 모드 해당 타입으로 바뀌게 된다.

함수 템플릿 예제

아래 예제는 여러 타입의 변수의 값을 서로 바꾸는 Swap() 함수를 함수 템플릿으로 작성한 예제이다.

#include <iostream>
using namespace std;

template <typename T>
void Swap(T &a, T &b);

int main()
{
    int c = 2, d = 3;
    cout << "c : " << c << ", d : " << d << endl;
    Swap(c, d);
    cout << "c : " << c << ", d : " << d << endl;

    string e = "hong", f = "kim";
    cout << "e : " << e << ", f : " << f << endl;
    Swap(e, f);
    cout << "e : " << e << ", f : " << f << endl;

    return 0;
}

template <typename T>
void Swap(T &a, T &b)
{
    T temp;

    temp = a;
    a = b;
    b = temp;
}

Output

c : 2, d : 3
c : 3, d : 2
e : hong, f : kim
e : kim, f : hong

특수화된 템플릿 함수(specialized function template)

함수 템플릿의 인스턴스화(암시적 특수화(implicit specialization))

함수 템플릿이 각각의 타입에 대해 처음으로 호출될 때, C++ 컴파일러는 해당 타입의 인스턴스(instance)를 생성한다.

생성된 인스턴스는 해당 타입에 대해 암시적으로 특수화된 템플릿 함수이다. 따라서 해당 인스턴스는 함수 템플릿에 해당 타입이 사용될 때마다 호출된다.

명시적 특수화(explicit specialization)

C++의 함수 템플릿은 특정 타입에 대한 명시적 특수화(explicit specialization)를 제공하여 특정 타입에 대해 특정한 동작을 정의할 수 있다.

컴파일러는 호출된 함수에 정확히 대응하는 특수화된 정의를 발견하면, 더 이상 테블릿을 찾지 않고 해당 정의를 사용한다.

명시적 특수화 예제

Swap() 함수 템플릿에서 double 형에 대한 동작만 변경하기 위해 명시적 특수화를 사용한 예제이다.

#include <iostream>
using namespace std;

template <typename T> void Swap(T &a, T &b);
template <> void Swap<double>(double &a, double &b);

int main()
{
    int c = 2, d = 3;
    cout << "c : " << c << ", d : " << d << endl;
    Swap(c, d);
    cout << "c : " << c << ", d : " << d << endl;

    double e = 1.234, f = 4.321;
    cout << "e : " << e << ", f : " << f << endl;
    Swap(e, f);
    cout << "e : " << e << ", f : " << f << endl;

    return 0;
}

template <typename T>
void Swap(T &a, T &b)
{
    T temp;

    temp = a;
    a = b;
    b = temp;
}

template <>
void Swap<double>(double &a, double &b)
{
    return ;
}

Output

c : 2, d : 3
c : 3, d : 2
e : 1.234, f : 4.321
e : 1.234, f : 4.321

참고 자료

• http://www.tcpschool.com/cpp/cpp_template_function

C++의 프로그래밍 언어로서의 특징 중 하나는 일반화 프로그래밍(generic programming)이다.

일반화 프로그래밍은 데이터를 중시하는 객체 지향 프로그래밍과는 달리 프로그램의 알고리즘에 중점을 두는 프로그래밍이다.

C++에서 이런 일반화 프로그래밍을 지원하는 대표적인 기능 중 하나가 템플릿(template)이다.

템플릿(template)

템플릿(template)이란 매개변수의 타입에 따라 함수나 클래스를 생성하는 매커니즘을 의미한다.

템플릿은 타입이 매개변수에 의해 표현되기 때문에, 매개변수화 타입(parameterized type)이라고도 한다.

템플릿을 사용하면 타입마다 별도의 함수나 클래스를 만들지 않고, 여러 타입에서 동작할 수 있는 하나의 함수나 클래스를 작성하는 것이 가능하다.

이러한 템플릿을 사용하는 함수는 함수 템플릿(function template), 클래스는 클래스 템플릿(class template)이라고 한다.

참고 자료

• http://www.tcpschool.com/cpp/cpp_template_function