Inpa Dev ‍

[Cypress Studio] 더욱 간편해진 웹 테스트 자동화 툴

인파_ — Mon, 25 Mar 2024 09:33:24 +0900

Cypress Studio 소개

앞선 시간에 자바스크립트에 익숙하다면 쉽게 접할 수 있는 테스트 라이브러리인 cypress 에 대해서 기본적인 사용법을 알아보았다.

--------------------------------------------------

링크 박스

---------------------------------------------------

이처럼 기본적으로 테스팅을 위한 동작을 일일히 프로그래머가 코드를 짜야 하는데, 그러면 비전공자혹은 비개발 직군이 E2E 테스트를 하기 위해선 프로그래밍을 배워야 하는 러닝 커브가 있으며, 또한 테스트 케이스 수만큼 비슷한 E2E 테스트 코드를 반복적으로 작성해야 하여 테스트 코드 작성 시간이 오래걸리게 된다는 아쉬운점이 있다. 그래서 이를 좀 더 편하게 하는 기능이 있어 소개해본다.

Cypress Studio란 Cypress에서 제공하는 테스트 코드 자동화 기능으로, 웹 애플리케이션과 상호작용하면서 테스트 코드를 알아서 생성해주는 기능이다. 즉, 코드를 작성하고 사용자 동작 시나리오를 구성하는것이 아닌, 거꾸로 사용자의 마우스, 키보드 등의 액션과 페이지의 동작을 기록하여 자동으로 코드를 완성시켜 준다.

예를들어 버튼 클릭과 같은 동작에 대한 함수를 코딩 없이 만들어주며, 또한 특정 버튼에 대한 엘리먼트의 아이디나 클래스를 일일히 추적해서 알필요없이 클릭만 하면 자동으로 선택자를 추적해 만들어줘 훨씬 편해진다. 그래서 테스트 코드를 수동으로 작성하는 시간과 번거로움을 줄일 수 있어, Cypress를 새로 사용하거나 학습하는 사람들에게 유용하고 빠르게 테스트를 만들 수 있게 되어 업무 효율일 높일 수 있다.

다만 Cypress Studio는 아직 실험적인 기능이라 완성형 도구는 아님을 유의하자. 예를들어 Cypress Studio는 현재 E2E 테스트 작성에만 사용할 수 있으며, 여러 출처의 도메인을 사용하는 작성 테스트를 지원하지 않는다.

Cypress Studio 사용법

Cypress 설치하기

기존 cypress를 설치하여 사용하고 있는 독자분들이라면, 이 단계는 그냥 건너뛰어도 된다. 하지만 cypress를 처음 접하시는 분들은 https://www.cypress.io/install 링크에서 [Download Cypress.zip] 버튼을 눌러 exe 파일을 다운받자.

그리고 압축 파일을 적절한곳에 압축을 풀고 경로의 파일을 실행하면, 런치패드(Launchpad) 화면이 띄워지게 된다.

Cypress Studio 설정하기

초기 프로젝트 폴더 생성

먼저 중앙에 Drag your project directory here or browse manually 문구 버튼을 클릭하고 테스트 코드를 관리할 프로젝트 폴더를 선택해준다. 처음이라면 빈 폴더를 생성하고 등록해 주면 된다.

프로젝트 폴더를 등록하면, 아래와 같은 화면으로 넘어가게 되고 사진에 따라 진행해준다.

테스트 파일 생성

브라우저를 선택하면, 마치 웹앱과 같이 cypress 전용 웹애플리케이션이 새 창으로 열리게 된다. 새 테스트 파일을 생성하도록 하자.

테스트 코드 파일 생성

생성된 테스트 코드 파일 실행

Studio 설정 활성화 하기

사용자의 키보드, 마우스 클릭과 같은 여러 동작을 기록하여 자동으로 테스트 코드로 변환하기 위해서는 세팅에서 설정값 하나가 필요하다.

먼저 세팅을 눌러 파일을 열어 편집할 에디터를 지정해주고, ~~cypress.config.js~~ 파일을 열어서 안에 ~~experimentalStudio: true~~를 아래와 같이 추가해준다.

module.exports = {
  e2e: {
    // 자동 테스트 코드 생성 설정
    experimentalStudio: true,

    setupNodeEvents(on, config) {
      // implement node event listeners here
    },
  },
};

코드를 저장하면, cypress studio 크롬 웹앱이 재부팅되게 되고, 상단에 '자동화된 테스트 소프트웨어에 의해 제어되고 있습니다'라고 표기가 되며, 다시 세팅으로 들어가서 Project settings 를 클릭하고 스크롤을 내리면 아래와 같이 옵션이 활성화가 된 것을 확인할 수 있다.

Cypress Studio 시작하기

테스트 동작 코드를 수정하려면 위에서 생성한 spec.cy.js 파일을 수정하면 된다. 다만 우리는 사용자의 동작을 기록해서 자동으로 테스트 코드를 생성하는 기능을 하용할 것이기 때문에, 웹앱에서 cypress studio를 진행하도록 해보자.

자동 테스트 기록 & 생성

먼저 기록을 시작하기 위해선 아래와 같이 template spec 테스트 문구 옆에 마우스 커서를 살짝 올려보면 옆에 말풍선으로 Add New Test 문구가 뜨면서 클릭이 활성화 된다.

그러면 테스트할 웹페이지를 입력하라고 뜨게되고 여기에 국내 보편적인 사이트른 네이버 www.naver.com 을 입력해보자.

Continue 버튼을 누르게 되면 네이버 웹페이지로 이동하게 되는데, 이제 이 웹페이지에서 사용자가 행위, 동작을 하게되면 이에 맞게 왼쪽 로그 메뉴에 기록이 되게 된다.

예를들어 네이버 검색창에 텍스트를 입력하고 우측의 돋보기 버튼을 클릭하는 동작을 행하면, 좌측에 이에 대한 행위값이 기록되게 되며, Save Commands 버튼을 누르면 이를 코드로 변환하게 된다.

테스트 이름 입력

실제 테스트 코드는 위에서 생성하고 실행한 ~~spec.cy.js~~ 파일을 오픈하면 아래와 같이 사용자의 행위가 자동으로 테스트 코드로 변환된 것을 확인할 수 있다.

// template spec이라는 테스트 스위트를 정의합니다.
describe('template spec', () => {

  /* ==== Test Created with Cypress Studio ==== */
  
  // 네이버라는 테스트 케이스를 정의합니다.
  it('네이버', function() {
    /* ==== Generated with Cypress Studio ==== */
    cy.visit('www.naver.com'); // www.naver.com 라는 웹사이트를 방문합니다.
    cy.get('#query').clear('r'); // id가 query인 요소를 찾아서 r이라는 문자를 지웁니다.
    cy.get('#query').type('검색어를 입력하세요'); // id가 query인 요소에 '검색어를 입력하세요'라고 타이핑합니다.
    cy.get('#search-btn').click();  // id가 search-btn인 요소를 클릭합니다.
    /* ==== End Cypress Studio ==== */
  });
})

이렇게 생성된 테스트 코드 파일을 실행시키려면, GUI 앱에서 직접 파일을 클릭하면 자동으로 진행되게 된다.

테스트 명령 이어서 추가하기

만일 추가적인 테스팅 동작 코드가 필요하다라고 한다면, 아래 사진처럼 테스트 그룹에 마우스 커서를 갖다대면, 'Add Commands to Test' 말충선이 뜨게 된다. 이걸 클릭하면 다시 Cypress Studio 가 발동되며 동작 코드 변환을 시행하게 된다. 추가 수정을 한뒤 이전 처럼 커맨드를 저장해주면 된다.

엘리먼트 값 추적하기

내가 클릭한 메뉴나 버튼의 css 선택자를 알고 싶을 때가 있을 것이다. 이런 경우 개발자 도구를 열어 일일히 추적하기 보다는 cypress에서 제공해주는 기능을 이용하면 된다. 아래와 같이 간편히 셀렉터를 얻을 수 있다.

참고문헌

https://docs.cypress.io/guides/references/cypress-studio

테스트 코드 자동으로 만들기 feat. Cypress Studio | 카카오엔터테인먼트 FE 기술블로그

[Cypress] 웹 테스트 자동화 사용법 한눈에 정리

인파_ — Sun, 24 Mar 2024 01:19:50 +0900

Cypress 소개

소프트웨어 테스팅은 소프트웨어의 품질을 보장하고 결함을 예방하고 수정하는 데 매우 중요한 과정이다. 특히 지속적이고 반복적이고 자주 일어나는 작업들은 가능한 자동화하고 효율적으로 수행하는 것이 좋다.

cypress는 웹애플리케이션을 테스트하기 위한 자바스크립트로 작성된 가벼운 라이브러리로, 실제 애플리케이션과 테스트 코드를 동일한 브라우저에서 실행하는 방식을 취하고 있다. 브라우저 기반의 GUI를 사용하여 테스트의 실행 상태를 확인하고 디버깅할 수 있는 다양한 편의 기능을 제공한다.

예를들어 실행된 모든 테스트 명령과 각 명령이 실행될 때의 UI 상태를 스냅샷 형태로 모두 저장해 특정 시점의 UI 상태를 눈으로 확인할 수 있다. 또한 전체 테스트 진행 과정을 동영상으로 저장하거나 테스트가 실패했을 때 자동으로 스크린샷을 남길 수 있어 테스트가 실패했을 때 원인을 파악하기가 매우 쉽다.

브라우저에서 실행되기 때문에 필요한 경우 크롬 개발자 도구를 사용해 디버깅을 할 수도 있으며, 무엇보다 자바스크립트로 작성되었기 때문에 테스트 코드 역시 사용자가 웹 페이지에서 요소를 찾는 방식과 유사한 메서드를 제공하여 큰 러닝커브 없이 빠르게 학습이 가능하다는 장점이 있다.

E2E 테스트 도구

E2E( End-to-End ) 테스트란 '시작부터 끝까지'라는 의미로, 애플리케이션이 제대로 작동하는지, 사용자 관점에서 시스템 흐름을 테스트하는 소프트웨어 테스트 방법이다. 이 테스트의 목적은 실제 생산 환경과 유사한 환경에서 시스템이 전체적인 비즈니스 목표에 충족하는지 확인하기 위해 실제 사용자 시나리오를 시뮬레이션하고 해당 구성 요소의 통합 및 데이터 무결성을 검증하는 것이다.

쉽게 말해 실제 사용자 시나리오를 모방해 사용자가 개발한 시스템을 오류나 버그없이 예상대로 작동하는지에 대한 검증이라고 보면 된다. 예를 들어, 사용자가 쇼핑몰 사이트에 접속하고, 로그인하고, 상품을 검색하고, 장바구니에 담고, 결제하고, 주문 확인하는 일련의 사용 시나리오를 테스트 한다고 이해하면 된다.

이처럼, E2E 테스트는 테스트 방법론이며, Cypress는 이 방법론을 실제로 구현하기 위한 도구인 것이다.

Cypress vs Selenium

웹애플리케이션을 테스트 자동화할때 가장 유명한 도구를 고르자면 이구동성으로 Seleniun(셀레니움)을 고를 것이다.

Cypress와 Selenium은 웹 테스팅을 위한 도구로 각각 장단점과 차이점을 가지고 있다. 그렇다면 이 둘 중 어떤 도구를 선택해야 할까? 어떤 도구를 선택해야 할지는 테스팅의 목적, 범위, 요구사항, 환경 등에 따라 달라질 수 있다.

	cypress	selenium
언어	JavaScript만 지원	Java, Python, JavaScript, C#, Ruby 등 다양한 언어 지원
지원 브라우저	Chrome, Edge, Electron 일부 브라우저만 지원	Chrome, Firefox, Edge, Safari, Opera 등 대부분의 브라우저 지원
난이도	개발자 친화적이고, 테스트 환경 구축이 쉬움	테스트 환경 구축이 복잡하고, 드라이버나 서버가 필요함
테스트 속도	브라우저 내부에서 직접 테스트를 수행하므로 빠름	브라우저 드라이버를 통해 테스트를 수행하므로 상대적으로 느림
테스트 결과	테스트 러너에서 테스트 과정과 결과를 시각적으로 확인 가능	테스트 과정과 결과를 시각적으로 확인하기 어려움
테스트 범위	프론트엔드 테스트에 특화되어 있음	프론트엔드와 백엔드 테스트 모두 가능

정리하자면 다음과 같은 상황에서는 Cypress를 선택하는 것이 좋다.

프론트엔드 개발자가 자바스크립트로 테스트를 작성하고자 할 때
모던 웹 애플리케이션의 UI와 기능을 테스트하고자 할 때
테스트 환경을 쉽게 설정하고, 테스트 결과를 실시간으로 확인하고, 테스트를 디버깅하고자 할 때
테스트 주도 개발을 수행하고자 할 때

다음과 같은 상황에서는 Selenium을 선택하는 것이 좋다.

다양한 언어로 테스트를 작성하고자 할 때
다양한 브라우저와 플랫폼에서 테스트를 수행하고자 할 때
웹 서버를 통해 분산 테스팅이나 병렬 테스팅을 수행하고자 할 때

Cypress 설치하기

https://www.cypress.io/ 홈페이지에 들어가면 설치를 진행 할 수가 있다. 두가지 방법으로 가능한데, 모두 소개해본다.

Node.js 패키지 설치

npm 명령으로 cypress를 설치하고 open 명령을 통해 cypress 앱을 실행 시킬 수 있다.

> npm install cypress -D

> npx cypress open # cypress 앱 오픈

cypress를 실행하면 아래와 같은 화면으로 넘어가게 되고 사진에 따라 진행해준다.

exe 설치

노드 생태계가 없어도 바로 직접 실행 파일로도 cypress 앱을 다운 받을 수가 있다. 압축 파일을 다운받으면, 파일을 적절한곳에 압축을 풀고 경로의 파일을 실행하면, 런치패드(Launchpad) 화면이 띄워지게 된다.

exe 버전은 Cypress를 빠르게 사용해 볼 수 있는 방법으로만 시험적으로 제작된 도구이며, 몇가지 기능 제한이 따라 붙는다. 예를들어 Cypress Cloud로의 녹화 실행이 불가능하다고 한다.

위 창에서 Drag your project directory here or browse manually 문구 버튼을 클릭하고 테스트 코드를 관리할 프로젝트 폴더를 선택해준다. 처음이라면 빈 폴더를 생성하고 등록해 주면 된다. 그리고 위에 Node.js 패키지 설치방법에 연재한 순서와 같이 똑같이 진행해주면 된다.

Cypress 실행하기

테스트 프로젝트 생성

브라우저를 선택하면, 마치 웹앱과 같이 cypress 전용 GUI창이 새 브라우저 창으로 열리게 된다. 그리고 아래와 같이 새 테스트 파일을 생성하도록 하자.

테스트 코드 파일 생성

생성된 테스트 코드 파일 실행

테스트 시나리오 작성

테스트 동작 코드를 수정하려면 위에서 생성한 ~~spec.cy.js~~ 파일을 수정하면 된다.

우선 에디터로 돌아와서 ~~spec.cy.js~~ 파일을 오픈해보자. 그러면 아래와 같이 적혀져 있을 것이다.

describe('template spec', () => {
  it('passes', () => {
    cy.visit('https://example.cypress.io')
  })
})

위의 api 설명은 아래와 같다.

~~describe()~~ : 테스트 할 동작들을 묶어주는 전체 그룹.
~~it()~~ : 테스트 할 동작의 세부 단위 케이스.
~~cy.visit()~~ : 웹사이트 방문.

코드를 보면 JEST 테스트 라이브러리 코드 양식과 굉장히 유사하다고 볼 수 있다.

연습겸 간단하게 아래와 같이 바꿔보자.

describe('네이버 사이트 테스트 시트', () => {
  it('네이버 사이트 방문', () => {
    cy.visit('https://www.naver.com')
  })
})

그리고 cypress GUI 앱에서 아래와 같이 js 파일을 더블클릭하게 되면, 코드에 따라 자동화 테스트가 수행되게 된다.

위 처럼 실제 테스트가 시각적으로 진행되는 것을 볼 수 있다. 왼쪽 명령 로그 영역에는 위에서 작성한 코드의 명령들이 로그로 기록되며, 각 명령줄들에 마우스를 클릭하면 해당 명령이 실행될 때의 화면 상태를 각각 확인도 가능하다.

버튼 클릭 자동화

cypress의 자바스크립트 코드는 jQuery 함수 형식과 되게 비슷하게 되어있다. 예를들어 자바스크립트나 제이쿼리에서 버튼 엘리먼트를 가져오려면 아래와 같이 코드를 작성하는데,

document.querySelector('button');
$('button')

cypress도 이와 비슷하게 cy 객체의 ~~get()~~ 함수를 통해 안에 엘리먼트의 id값이나 class값을 적으면 자동으로 html의 엘리먼트를 가져오게 된다.

cy.get('button')

cy.get('.className');
cy.get('#idName');
cy.get('[class^="button_"]')

참고로 엘리먼트의 id값이나 class값은 개발자도구를 열어서 직접 추적해 얻는 방식도 있지만, cypress GUI 앱에서 더 간단히 얻을 수 있는 방법이 있다.

상단의 저격 크로스헤어 버튼을 누르고 아래처럼 클릭을 진행하면, 자동으로 cy 객체 코드가 완성되게 되고, 우측의 복사 버튼을 눌러 코드에 적용하면 되게 된다. 다만 복잡한 트리 구조의 구성일 경우 직접 개발자도구로 찾는것이 더 정확할 수도 있다.

그렇게해서 얻은 엘리먼트 객체를 뒤에 동작을 행하는 함수를 체이닝(chaining)으로 붙여주면 간단하게 버튼 클릭 행위를 자동화 할 수 있게 된다.

cy.get('#button').click()

버튼 클릭에 대한 시나리오를 짜고 싶다면 아래 처럼 ~~wait()~~ 함수와 적절히 섞어주면 마치 이른바 매크로를 구현할 수 있게 되는 것이다.

describe('무신사 사이트 테스트 시트', () => {
    it('쇼핑몰 버튼 클릭', () => {
        cy.visit('https://www.musinsa.com/app/'); // 무신사 방문
        cy.get('[u_cat_cd="001"] > a').click(); // 특정 버튼 클릭
        cy.wait(1000); // 1초 대기
        cy.get('[u_cat_cd="002"] > a').click();
        cy.wait(1000);
        cy.get('[u_cat_cd="003"] > a').click();
        cy.wait(1000);
        cy.get('[u_cat_cd="004"] > a').click();
    });
});

타이핑 자동화

이른바 쇼핑몰의 검색창에 검색 텍스트를 자동으로 써서 검색을 수행하는 매크로를 만들어보자. 사용하는 함수 역시 직관적으로 ~~type()~~ 을 통해 아주 간단히 구현할 수 있다.

describe('무신사 사이트 테스트 시트', () => {
    it('쇼핑몰 버튼 클릭', () => {
        // 무신사 사이트 방문
        cy.visit('https://www.musinsa.com/app/');

        // 무신사 검색
        cy.get('input#commonLayoutSearchForm').type('구찌 가방'); // 검색 입력창 엘리먼트를 가져와서 텍스트 타이핑
        cy.get('.sc-1ppcy5v-5').click(); // 돋보기 버튼 클릭

    });
});

이를 응용해서 검색창이 아닌 로그인 화면의 아이디와 패스워드 창에 텍스트를 타이핑하고 로그인 버튼을 누르도록 테스트케이스를 짜면, 로그인 매크로를 구현하는것과 같다

describe('네이버 테스트', () => {
    it('네이버 로그인', () => {
        cy.visit('https://nid.naver.com/nidlogin.login');

        cy.get('#id').type('test');
        cy.get('#pw').type('123123');

        cy.get('#log\\.login').click();
    })
})

드롭박스 자동 선택

~~<select>~~ 태그의 엘리먼트를 선택하는 자동화 테스트를 구현해 보자. 직관적으로 ~~select()~~ 함수를 통해 드롭다운 메뉴를 얻을 수 있다. 이밖에도 체크박스나 라디오버튼도 비슷한 과정이다.

describe('무신사 사이트 테스트 시트', () => {
    it('상품 메뉴 선택하기', () => {
        cy.visit('https://www.musinsa.com/app/goods/3791036?loc=goods_rank');

        // 상품 옵션 선택하기
        cy.get('.product-detail__sc-1d13nsy-1').select('M'); 
        cy.get('.product-detail__sc-1k1gum8-0').select('589908') 
    });
});

cypress의 함수 코드들은 기본적으로 비동기 함수들이며 실행 방식은 마치 자바스크립트의 await 비동기 방식
으로 동작된다. 그래서 별도로 Promise나 await 처리 없이 테스트 코드들을 써내려가도 충돌없이 사용이 가능하다.

Cypress 문법 정리

다양한 종류의 api 문법을 알고하고 싶다면 아래 공식문서를 참고해보자. 이번 글은 cypress의 기본적인 뼈대 구조를 이해하는데 초점을 두어 설명해본다.

Table of Contents | Cypress Documentation

Commands

docs.cypress.io

Cypress.io: Kitchen Sink

Cypress API The Cypress API enables you to configure the behavior of how Cypress works internally. You can do things like access Environment Variables, change configuration, create custom commands, and more.

example.cypress.io

Cypress 그룹핑

각 명령어들을 보기좋게 모듈화하여 묶는 그룹 함수들이다.

~~describe()~~ : 테스트 코드를 묶는 가장 큰 단위. 테스트 스위트
~~context()~~ : describe 내부에서 새로운 테스트 그룹을 정의하는 함수 (context는 describe와 기능적으로는 차이가 없거 단지, 의미적으로 구분하기 위해 사용한다. 생략해도 문제 없다)
~~it()~~ : 실제 테스트 케이스를 정의하는 함수

// 'My App'이라는 테스트 스위트를 정의합니다.
describe('My App', () => {

  // 'Login'이라는 테스트 그룹을 정의합니다. 이 테스트 그룹은 로그인 기능과 관련된 테스트 케이스들을 묶어줍니다.
  context('Login', () => {
  
    // 'Valid user'라는 테스트 케이스를 정의합니다. 이 테스트 케이스는 유효한 사용자 정보로 로그인하는 것을 테스트합니다.
    it('Valid user', () => {
      // 테스트할 내용을 작성합니다.
      cy.visit('/login'); // 로그인 페이지에 접속합니다.
      cy.get('#username').type('test'); // 아이디 입력창에 'test'라고 입력합니다.
      cy.get('#password').type('1234'); // 비밀번호 입력창에 '1234'라고 입력합니다.
      cy.get('#login-button').click(); // 로그인 버튼을 클릭합니다.
      cy.url().should('include', '/dashboard'); // 로그인이 성공하면 대시보드 페이지로 이동합니다.
    });
    
    // 'Invalid user'라는 테스트 케이스를 정의합니다. 이 테스트 케이스는 유효하지 않은 사용자 정보로 로그인하는 것을 테스트합니다.
    it('Invalid user', () => {
      // 테스트할 내용을 작성합니다.
      cy.visit('/login'); // 로그인 페이지에 접속합니다.
      cy.get('#username').type('wrong'); // 아이디 입력창에 'wrong'이라고 입력합니다.
      cy.get('#password').type('4321'); // 비밀번호 입력창에 '4321'이라고 입력합니다.
      cy.get('#login-button').click(); // 로그인 버튼을 클릭합니다.
      cy.contains('Invalid username or password'); // 로그인이 실패하면 에러 메시지를 표시합니다.
    });
  });
  
  // 'Logout'이라는 테스트 그룹을 정의합니다. 이 테스트 그룹은 로그아웃 기능과 관련된 테스트 케이스들을 묶어줍니다.
  context('Logout', () => {
  
    // 'Logout from dashboard'라는 테스트 케이스를 정의합니다. 이 테스트 케이스는 대시보드 페이지에서 로그아웃하는 것을 테스트합니다.
    it('Logout from dashboard', () => {
      // 테스트할 내용을 작성합니다.
      cy.login('test', '1234'); // cy.login()은 커스텀 커맨드로, 로그인을 수행하는 함수입니다.
      cy.visit('/dashboard'); // 대시보드 페이지에 접속합니다.
      cy.get('#logout-button').click(); // 로그아웃 버튼을 클릭합니다.
      cy.url().should('include', '/login'); // 로그아웃이 성공하면 로그인 페이지로 이동합니다.
    });
    
  });
  
});

Cypress Hook

Cypress hook는 테스트 스위트의 실행 전후에 특정한 작업을 수행할 수 있게 해주는 기능이다. 이를 이용해 테스트 환경을 설정하거나, 테스트 데이터를 준비하거나, 테스트 결과를 정리하거나, 테스트 로그를 기록하거나, 테스트 에러를 처리하거나 등의 작업을 할 수 있다.

~~before()~~ : 테스트 스위트의 첫 번째 테스트 케이스가 실행되기 전에 한 번만 실행
~~after()~~ : 테스트 스위트의 마지막 테스트 케이스가 실행된 후에 한 번만 실행
~~beforeEach()~~ : 테스트 스위트의 각 테스트 케이스가 실행되기 전에 매번 실행됩
~~afterEach()~~ : 테스트 스위트의 각 테스트 케이스가 실행된 후에 매번 실행

Cypress hook은 describe()나 context() 안에 작성할 수 있으며, it()안에는 작성할 수 없다

describe('Test E2E by Cypress', () => {

  context('Mobile Version', () => {
  
    // 이 hook은 Mobile Version 테스트 그룹의 각 테스트 케이스가 실행되기 전에 매번 실행. 
    beforeEach(() => {
      // ... Codes executed before each test case inside it() hooks ...
    });
    
    // 이 테스트 케이스는 beforeEach() hook이 실행된 후에 실행
    it('Login Button Should be Somewhere', () => {
      // ... Real Executing test codes for some application ...
    }); 
    
  });
});

Cypress Assertion

Cypress Assertion이란 Cypress에서 테스트의 결과가 예상한 값과 일치하는지 검증하는 방법을 말한다. 예를들어 어느 제목의 텍스트가 특정 문자열과 일치하는지 확인하는데 이용된다.

// h2태그의 text가 특정 제목인지 확인
cy.get('h2').should('have.text', '특정 제목');

// button을 클릭하고 나면 class에 active가 있어야 하는 경우
cy.get('button').click().should('have.class', 'active')

// 해당 객체가 없어야 하는 경우
cy.get('button').should('not.exist')

// 두 조건을 만족해야 하는 경우 (and)
cy.get('#header a')
  .should('have.class', 'active') // 클래스명이 active 일 경우
  .and('have.attr', 'href', '/users') // href 속성 값이 /users 일경우

// 체크박스가 disabled된 경우
cy.get(':checkbox').should('be.disabled')

// input에 특정 값이 없어야 하는 경우
cy.get('input').should('not.have.value', 'US')

// URL 로 호출을 하고, 해당 주소 RETURN BODY에 {name: 'inpa'}이 있어야 하는 경우
cy.request('/users/1').its('body').should('deep.eq', { name: 'inpa' })

Cypress Assertion은 비동기적으로 동작하며, 테스트 대상이 조건을 만족할 때까지 기다린다. 만약 조건을 만족하지 못하면, Cypress는 에러를 발생시키게 된다. 또한 체이닝(chaining)역시 가능하며, and나 or를 사용하여 여러 개의 조건을 연결할 수 있다.

Cypress Commands

프로그래밍에서 반복되는 코드가 있으면 이를 함수로 묶어 모듈화 하는것이 중요하다. cypress 역시 테스트를 자동화시킴에 따라 즐비하게 중복 및 반복되는 코드들이 많아질수 있는데, 이 역시 함수 단위로 묶어 사용하는 기능을 '사용자 정의 명령어' 라고 한다.

우선 사용자 정의 명령어를 사용하기 위해서는, cypress 프로젝트의 support 폴더 내의 commands.js 파일을 이용할 필요가 있다.

그리고 새로운 사용자 정의 명령어를 추가하려면 commands.js 파일 안에 ~~Cypress.Commands.add~~ 메소드를 사용하여 추가해주면 된다. 예를들어 로그인 프로세스는 아이디 입력, 비밀번호 입력, 로그인 버튼 클릭 이렇게 3개의 프로세스로 이루어져 있는데, 만일 로그인을 테스트하는데 있어 자주 이용하여 모듈화를 시킨다고 하면 아래와 같다.

Cypress.Commands.add('login', (email, password) => {
  cy.get('input[name=email]').type(email);
  cy.get('input[name=password]').type(password);
  cy.get('form').submit();
});

/*
어렵게 생각할 필요없이 아래의 함수를 새로 만들어 사용한다고 보면 된다.

const login = (email, password) => {
  cy.get('input[name=email]').type(email);
  cy.get('input[name=password]').type(password);
  cy.get('form').submit();
}
*/

이렇게 추가된 사용자 정의 명령어는 별도의 require나 import 없이도, Cypress에서 자동으로 인식하기 때문에 테스트 파일 어디에서나 전역적으로 사용할 수 있게 된다.

describe('네이버 테스트', () => {
    it('네이버 로그인', () => {
        cy.visit('https://nid.naver.com/nidlogin.login');
		
        // commands.js에 정의된 사용자 정의 명령어 수행
        cy.login('test', '123123')
    })
})

Cypress then

cypress ~~then()~~ 메소드는 명령어와 결과를 콜백 함수의 인자로 전달해, 명령 결과에 액세스하고 이에 대한 추가 로직을 수행하는데 사용된다.

cy.get('.list-item').then(($listItem) => {
  // $listItem은 .list-item의 첫 번째 DOM 요소를 jQuery 객체로 감싼 것입니다.
  // 여기서 추가 작업을 수행할 수 있습니다.
  $listItem.css('color', 'red');
});

cy.get('.element').then(($el) => {
  if ($el.hasClass('active')) {
    // .element가 'active' 클래스를 가지고 있으면 추가 작업을 수행합니다.
  }
});

 cy.request('https://jsonplaceholder.typicode.com/posts/1').then((response) => {
    cy.log(response)
    
    expect(response.status).to.equal(200);
    expect(response.status).to.eq(200);
});

cypress then 과 promise then 은 서로 연관 없다

다만 유의할점은, Cypress의 then 키워드는 자바스크립트의 ~~Promise.then~~ 과 전혀 아무런 관련이 없다는 점이다. 아무래도 코드 구문 생김새가 매우 비슷하여 이러한 착각을 할 수도 있지만, Cypress의 then 키워드는 동기/비동기와 관련이 없는 명령어이다. 실지로 catch 문은 통하지 않는다는걸 확인할 수 있다.

정리하자면, Cypress의 then 은 단순히 명령 결과에 액세스하고 이에 대한 추가 작업을 수행하는 데 사용되는 것일 뿐이다. 예를들어 cy 객체에서 지원하는 메소드로 체이닝해서 사용해도 충분하지만, 가져온 값에 뭘 더하거나 하는 등 별도의 추가 연산 작업이 필요할때 연산 코드를 then 블록 안에 쓰는 용도인 것이다.

cy.get('option:first')
  .should('be.selected')
  .then(($option) => {
    // $option is yielded
  })

Cypress Wrapping

~~cy.wrap()~~ 은 자바스크립트 객체나 값을 Cypress 명령어 체인에 포함시키기 위해 사용되는 메소드이다.

쉽게 생각해서 간단하게 비유를 들자면 제이쿼리에서 제이쿼리 전용 체이닝 메소드를 사용하기 위해서는 ~~$(obj)~~ 와 같이 $ 괄호 안에 객체를 넣어서 사용해야 했다. 이와 똑같은 원리라고 보면 된다.

// JavaScript 객체를 cy.wrap()으로 감싸고, .should() 명령어를 사용하여 객체의 속성을 검사
const object = { name: 'Cypress' };
cy.wrap(object).should('have.property', 'name', 'Cypress');

이러한 래핑 기능은 주로 비동기적으로 반환된 값들을 cy 객체로 감싸 Cypress 명령어 체인에 포함시켜 테스트의 유연성을 높일 수가 있다.

cy.get('button').then(($button) => {
  if ($button.hasClass('active')) {
    cy.wrap($button).click();
  }
});

Cypress Window

테스트할 웹페이지의 DOM에 접근해서 조작을 하고 싶을 상황이 있을 것이다. 이때 ~~cy.window~~ 를 통해 현재 테스트 중인 페이지의 window 객체를 반환받을 수 있다. ~~cy.window~~ 는 비동기적으로 실행되므로, 역시 위에서 배운 ~~.then()~~ 메소드를 사용하여 결과를 처리해야 한다.

cy.window().then((win) => {

  // win은 현재 페이지의 window 객체입니다.
  console.log('Window object:', win);
  
  // DOM 요소에 직접 접근하여 조작합니다.
  win.document.querySelector('button').click();
  
  // 페이지에 정의된 전역 변수나 함수에 접근합니다.
  console.log('Page title:', win.title);
});

Cypress Cookie

테스트 중에 사용자 인증 상태를 유지하거나, 특정 쿠키 값을 검사하는 등의 작업을 지원한다. ~~cy.getCookies()~~ 명령어는 현재 브라우저의 모든 쿠키를 가져와 쿠키 객체 배열을 반환하며, 각 객체는 쿠키의 이름, 값, 도메인 등의 정보를 포함한다.

cy.getCookies().then((cookies) => {
  // cookies는 쿠키 객체 배열입니다.
});

cy.setCookie('auth_key', '123key');
cy.getCookie('auth_key').should('have.property', 'value', '123key');

Cypress는 테스트 실행 시 기본적으로 모든 쿠키를 지우므로, 필요한 경우 테스트 시작 전에 쿠키를 설정해야 할 수도 있다.

Cypress 설정 옵션

Cypress를 처음 시작하면 Cypress 구성 파일인 ~~cypress.config.js~~이 파일이 생성되게 되는데, 여기서 전반적은 cypress의 전역 설정들을 지정할 수가 있다. 자세한 여러 세팅값들은 아래 공식문서를 참고하면 된다.

Configuration | Cypress Documentation

This guide is for Cypress 10+ and the new JavaScript configuration file format.

docs.cypress.io

브라우저 출처 정책 비활성화

만일 로그인과 같은 브라우저의 보안 정책과 연관된 테스트케이스를 수행하게 된다면 높은 확률로 아래와 같이 블락되며 제대로 테스트 코드 수행이 안될 것이다.

훌륭한 보안 정책이지만 아무래도 테스트 하는 입장에서는 불필요한 부분이기 마련이다. 따라서 ~~chromeWebSecurity~~ 옵션을 비활성함에 따라 동일 출처 정책 및 안전하지 않은 혼합 콘텐츠에 대해 Chromium 기반 브라우저의 웹 보안을 끌 수가 있다.

module.exports = {
    e2e: {
        // 크로미움 동일 출처 정책 보안 비활성화
        chromeWebSecurity: false,
    },
};

페이지 로딩 제한시간 설정

기본적으로 테스트 페이지 로딩 제한 시간이 60초로 설정이 되어잇기 때문에, 만일 로딩이 좀 오래걸리는 사이트를 테스트할 예정이라면 로딩 시간 초과로 테스트가 실패하기 때문에 추가 설정을 통해 로딩 제한 시간을 늘려주어야 한다.

module.exports = {
  e2e: {
    // 자동 테스트 코드 생성 설정
    experimentalStudio: true,

    // 페이지 로드 제한 시간 설정
    pageLoadTimeout: 120000 // 120sec
  },
};

페이지 크기 설정

기본적으로 테스트할 웹페이지의 크기는 1000x660 으로 설정하였기 때문에 아래와 같이 웹페이지의 스타일에 따라 짤리는 현상이 발생하기도 한다. 추가 설정을 통해 페이지의 뷰포트를 맞출 수 있다.

module.exports = {
  e2e: {
     // 테스트 페이지 뷰포트 설정
     viewportWidth: 1600, 
     viewportHeight: 900,

    setupNodeEvents(on, config) {
      // implement node event listeners here
    },
  },
};

참고문헌

https://microsoft.github.io/code-with-engineering-playbook/automated-testing/e2e-testing/

https://docs.cypress.io/guides/overview/why-cypress

ttps://rae-gi.tistory.com/23

https://blog.naver.com/o_zak/222671883835

Window 10 컴퓨터 부팅 / 절전 시간 확인하기

인파_ — Mon, 15 May 2023 15:16:10 +0900

윈도우 10 부팅 / 절전 시간 확인하기

가끔 사내에서 출퇴근을 하였는데도 사원의 실수로 출퇴근을 찍지 않았거나 혹은 전산 오류로 인해 기록이 남아 있지 않은 경우, 자신의 출퇴근 기록을 증빙할 수 있는 자료를 요청할 수 있다. 이에 대한 대표적인 증명 방법으로 자신의 컴퓨터 시스템 부팅 기록을 확인하는 것인데, 이는 윈도우 OS의 이벤트 뷰어를 통해 확인 할 수가 있다.

1. 이벤트 뷰어 실행하기

우선 이벤트 뷰어를 실행한다. 방법은 다음과 같이 두가지로 이행이 가능하다.

~~Win+X~~ 키를 누르고 이벤트 뷰어 메뉴를 클릭하여 실행하거나,

~~Win+R~~ 키를 눌르고 실행 입력창에 "eventvwr" 를 적고 실행하면 된다.

2. 로그 필터링 하기

각 컴퓨터 동작을 나타내는 윈도우 이벤트 ID 라는 것이 존재하는데, 그 수가 무수히 많다. 따라서 이들 중에 '부팅' 관련된 이벤트 ID만을 필터링해야 된다.

이벤트 뷰어 창이 뜨면 [Windows 로그] → [시스템 메뉴]를 선택하고, 우측 작업 항목 중 [현재 로그 필터링] 메뉴를 선택한다.

그리고 로그 필터링 창에서 찾고자 하는 행위의 이벤트 ID를 입력하고 확인을 눌러주면 된다.

6005번과 6006번은 컴퓨터 부팅 관련 이벤트 ID 이다

그러면 중앙 로그 부분에 이벤트 ID 6005 와 6006 번이 필터링 되어 날자 및 시간 별로 부팅 로그들이 날짜 별로 정렬되게 된다.

해당 로그를 더블 클릭하면 언제 시스템이 시작되었고 시스템 종료가 되었는지 구체적인 날짜 정보와 내용을 확인할 수 있다.

컴퓨터 부팅 관련 이벤트 ID

6005 : 이벤트 로그 시작, 부팅 기록
6006 : 정상적인 시스템 종료 기록
6008 : 비정상 시스템 종료 기록

컴퓨터 절전 모드 관련 이벤트 ID

절전모드 관련 이벤트는 조금 겹치는 ID가 많다. 이 중에는 더이상 사용되지 않는 ID도 있기도 하다.

1 or 15 or 108 : 컴퓨터가 절전 모드에서 다시 시작되었음
42 or 107 : 컴퓨터가 절전 모드로 전환
109 : 컴퓨터가 절전 모드에서 취소
110 : 컴퓨터가 절전 모드로 전환을 시도했지만 실패

1번, 42번, 107번 이면 충분할것 같다

컴퓨터 로그인 / 로그아웃 관련 이벤트 ID

4624 : 계정이 성공적으로 로그인 됨
4627 : 계정이 로그아웃됨

스레드를 많이 쓸수록 항상 성능이 좋아질까?

인파_ — Wed, 10 May 2023 07:53:13 +0900

스레드를 많이 쓰면 쓸수록 성능이 높아지는가

프로세스와 스레드를 처음 학습할때, 스레드는 프로세스 내에 존재하는 실행 단위이며, 이 스레드가 여러개인 덕분에 우리가 음악을 들으며 웹서핑을하거나 파일을 다운 받는 '동시 작업'이 가능하다라고 배웠을 것이다. 그래서인지 이러한 질문에 대해 깊게 고민할 필요 없이, 스레드가 많을 수록 동시 처리 작업 수가 증가하는 것이니, 당연히 멀티 스레드가 무조건 성능이 더 좋다고 생각할 것이다.

하지만 모든 상황에 대해 무조건 멀티 스레드가 싱글 스레드보다 무조건 좋다고 말할 순 없다. 모든 기술들에는 각각의 기회비용이 존재하고, 싱글 스레드와 멀티 스레드 역시 각각의 장점에 맞는 기회비용들이 존재하기 때문이다.

이 부분은 스레드를 겉햝기로만 배운 지원자를 걸러내기 위해 기술 면접에서 가끔 등장하는 고수준의 질문이기도 하다. 만일 기술 면접에서 해당 질문을 받았다고 가정해보자. 여러 대답들이 나올수는 있겠지만, 이 질문은 지원자가 스레드에 어느 정도까지 알고 있는지, 어떤 관점에서 문제를 바라보는지, 알고 있는 지식을 잘 정리해서 성능과 연결지어 판단할 수 있는지 이런 것들을 확인하기 위한 목적이다. 스레드의 내부 구조까지 파악하고 동시성(Concurrency)에 대한 깊은 지식이 있어야만 대답할 수 있는 질문이기 때문이다.

사람이 생각하는 동시성과 컴퓨터가 행하는 동시성 작동 차이

지금부터 싱글 스레드와 멀티 스레드 두 가지 모델을 비교하고 언제 어느때에 무엇이 더 좋은지 왜 멀티 스레드가 항상 성능이 좋지 않은지에 대해 알아보도록하자.

1. 임계 영역에 대한 동기화 비용

멀티 스레드는 자원을 공유하기 때문에 프로세스 생성에 비해 적은 메모리와 자원을 소모하고 컨텍스트 스위칭도 멀티 프로세스에 비해 빠르다는 장점이 있다. 하지만 여러 개의 스레드가 임계 영역(Critical Section)의 공유 자원에 접근할 수 있기 때문에, 데이터의 일관성과 정확성을 유지하기 위해 동기화(Synchronized) 기법을 사용하여야 한다.

공유 자원에 대한 임계 영역

임계 영역(Critical Section)
멀티 스레드 프로그래밍에서 임계 영역은 공유 자원을 접근하는 코드 영역을 말한다. 대표적으로 전역 변수나 heap 메모리 영역을 들 수 있겠다.

동기화 기법에는 여러가지가 있는데 대표적인 두가지로 뮤텍스(Mutex) 나 세마포어(Semaphore) 같은 잠금 기법이 있다. 이들은 한 번에 하나의 스레드만 공유 자원에 접근할 수 있도록 제한해야 하여 데이터에 대한 일관성을 유지한다. 그러나 이러한 동기화 기법은 스레드 간의 경쟁과 대기 상황을 발생시키므로, 오히려 성능에 부정적인 영향을 미칠 수 있다.

예를들어, 뮤텍스나 세마포어와 같은 동기화 기법을 사용하는 경우 스레드가 데이터에 접근하기 전에 락(Lock)을 획득하고, 데이터에 접근한 후에 락을 해제하는데, 이러한 락 획득 및 해제 작업은 추가적인 시간이 소요되며, 나머지 스레드의 실행을 중지하거나, 대기하게 만들어야 하므로 프로그램의 성능이 저하될 수 있다.

또한 CPU 캐시와 메모리 사이의 캐시 데이터 일관성 문제도 발생할 수 있는데, 여러 개의 스레드가 동시에 공유하는 메모리나 데이터에 대해 수정을 가할때 특정 CPU 코어의 캐시에 저장된 데이터와 다른 CPU 코어의 캐시에 저장된 데이터가 일치하지 않는 경우가 발생한다. 이럴 경우, 다른 CPU 코어에서 변경한 데이터가 현재 CPU 코어의 캐시에 반영되지 않은 상태로 사용되어 문제가 발생할 수 있어, CPU 캐시에서 데이터를 불러오는 비용이 발생하므로 성능에 영향을 미치게 된다.

지금까지의 얘기를 정리하자면, 멀티 스레드 프로그램이 많은 양의 공유 데이터를 사용하는 경우 동기화 및 캐시 일관성 작업으로 인해 병목이 일어나 성능이 떨어진다. 그럼 반대로 만일 공유 데이터의 양이 적고, CPU와 메모리 사용량이 적은 경우 오히려 싱글 스레드 프로그램이 멀티 스레드보다 더 좋다고 할 수 있을까? 이는 아주 틀린말은 아니지만, 실제로 대부분의 프로그램에서는 많은 양의 데이터와 복잡한 로직을 처리해야 하고 요즘 CPU는 기본적으로 다중 코어를 탑재하므로, 이러한 병목 현상이 있더라도 왠만한 상황에선 멀티 스레드 프로그램이 싱글 스레드 프로그램보다 빠르다. 그렇지만 멀티 스레드라고 해서 싱글 스레드보다 성능 상승 곡선이 무조건적으로 가파르지 않다.

2. 컨텍스트 스위칭 오버헤드

컨텍스트 스위칭 오버헤드(context switching overhead)는 여러개의 프로세스나 스레드가 있을때, CPU가 현재 프로세스나 스레드의 상태를 저장하고 다른 프로세스나 스레드로 전환될 때 발생하는 비용을 의미한다. 이 스위칭 하는 과정에서 CPU 시간과 자원을 소모하므로 성능에 영향을 미치는 것이다.

프로세스 1에서 프로세스 2 로 전환하는 과정에서 약간의 틈(오버헤드) 가 있다

우리가 멀티 프로세스 대신 멀티 스레드로 프로그램 모델을 구성하는 이유는 프로세스의 컨텍스트 스위칭 오버헤드 보다 스레드의 컨텍스트 스위칭 오버헤드가 훨씬 작아 병목이 적기 때문이다. 하지만 어디까지나 프로세스에 비해 상대적으로 작다는 것이지 오버헤드 자체 비용은 결코 무시할수는 없다.

즉, 싱글 스레드 모델에서는 스레드가 한개 이니 컨텍스트 스위칭 오버헤드가 발생되지 않지만, 멀티 스레드 모델은 스레드가 여러개이니 컨텍스트 스위칭 오버헤드가 발생하게 되고, 스레드가 많으면 많을 수록 스위칭 횟수도 많아지고 덩달아 오버헤드도 많아져 성능이 저하될 수 있다는 의미이다. 특히 싱글 코어와 같은 옛날 CPU와 같이 코어 수는 적은데 스레드 수를 계속 늘리게 되면, 각 코어에서 경합하는 스레드 수가 점점 많아질 거고, 어느 순간에는 오버헤드 때문에 성능 한계에 부딪히게 될 수 있게 된다.

만일 단순히 CPU만을 사용하는 계산작업이라면 오히려 멀티 스레드보다 싱글 스레드로 프로그래밍하는 것이 더 효율적일 수 있다. 조금 극단적인 예를 들어보자면, 1부터 1억 까지 덧셈을 하는 작업을 100번 수행해야 하는 프로그램이 있다고 하자. 싱글 스레드 어플리케이션이라면 다음과 같이 for문을 중첩함으로써 구성할 수 있겠다.

long sum = 0; 
for(int j=0; j<100; j++) {
  for(int i=0; i<10000000; i++) {
    sum += i;  
  } 
}

반면 멀티 스레드 어플리케이션 이라면 아래의 코드를 각각의 100개의 스레드에게 분배하고 동시에 실행시키게 될 것이다.

long sum = 0; 

/* --------- 스레드 1 --------- */
new Thread(() -> {
    for (int i = 0; i < 10000000; i++) {
        sum += i;
    }
}).start();
/* --------- -------- --------- */

/* --------- 스레드 2 --------- */
new Thread(() -> {
    for (int i = 0; i < 10000000; i++) {
        sum += i;
    }
}).start();
/* --------- -------- --------- */

// ...

/* --------- 스레드 100 --------- */
new Thread(() -> {
    for (int i = 0; i < 10000000; i++) {
        sum += i;
    }
}).start();
/* --------- -------- --------- */

실제론 그렇지는 않겠지만, 1부터 1억 까지 덧셈하는데 10초가 걸린다고 가정해보자. 일반적으로 생각하면 싱글 스레드 모델에선 10초가 걸리는 작업을 100번 직렬로 수행했으니 1000초가 걸리고, 멀티 스레드 모델에선 100개의 스레드가 동시에 실행하므로 10~11초 사이 정도 걸릴것이라고 예상 할 것이다. 하지만 이는 옳지 않다. 왜냐하면 멀티 스레드에서 발생하는 context swtiching overhead 비용 때문에, 100개의 스레드들이 서로 스위칭되면서 발생되는 병목으로 인해 동시 처리의 이점보다 소요 시간이 클 수 있으므로 오히려 싱글 스레드보다 연산 처리가 느려져 버릴수가 있게 된다.

context switching 이라는 잠재적인 비용때문에 실제 걸리는 시간은 더 크다

다시 한번 말하지만 이는 조금 극단적인 예시 이긴 하다. 비록 컨텍스트 스위칭 오버헤드와 추가적인 동기화 오버헤드가 발생하지만, 멀티 스레드는 CPU 코어를 효율적으로 활용하기 때문에 아주 옛날의 싱글 코어 프로세서가 아닌 이상 멀티 스레드의 컨텍스트 스위칭 오버헤드쪽이 더 느리다고 단언할 수는 없다. 따라서 이 부분은 단지 멀티 스레딩의 잠재적인 단점을 보여주기 위해 특별히 설계된 예시이며, 실제 시나리오에서는 다양한 상황에 따라 결과가 달라질 수 있으므로 참고에 유의해야 한다. 글쓴이가 말하고 싶은 것은, "스레드가 많을수록 작업을 분리해서 동시에 처리하니까 항상 빠르다"는 고정 관념을 컴퓨터를 배운 독자분들이라면 깰 필요성이 있다는 것을 강조하고 싶은 점이다.

3. 잔여 스레드의 리소스 낭비

많은 양의 작업을 여러개의 스레드로 빠르게 처리한다는 멀티 스레드 취지는 좋지만, 회사의 서비스 이용률이 24시간 항상 바쁜 상태이지는 않을 것이다. 즉, 멀티 스레드 어플리케이션에서 이용률이 한산하여 스레드를 한두개 밖에 이용하지 않을때, 나머지 잔여 스레드들이 CPU, 메모리, 네트워크 등의 자원을 불필요하게 점유해서 성능 저하나 오류의 원인이 될 수 있게 된다. 우선 놀고 있는 스레드가 많을 수록 불필요하게 메모리를 차지하고 있는 셈이기 때문에 당연히 시스템 자원 낭비가 발생된다. 그런데 놀고 있음에도 CPU는 다른 스레드에게 CPU 시간을 양도하도록 설계 되어 있기 때문에 노는 스레드와 다른 스레드 간에 컨텍스트 스위칭을 하여 CPU의 효율성을 떨어뜨린다. 즉, 스레드가 작업을 수행하지 않더라도 존재 자체만으로 여전히 리소스를 소비하고 오버헤드를 생성하기 때문에 잔여 스레드의 문제는 결코 가볍지 않은 것이다.

이러한 문제를 해결하기 위해서는, 노는 스레드의 개수를 최소화하고, 스레드 풀(Thread Pool)과 같은 매커니즘을 사용하여 스레드의 개수를 관리하여 리소스 낭비를 최소화하는 것이 중요하다.

스레드 풀은 나중에 쓰일 예비 스레드들을 담고 있는 상자이다

4. 어플리케이션 성격에 따른 제약

"스레드를 많이 쓰면 쓸수록 동시에 더 많은 작업들을 실행할 수 있다"라는 말에는 우리도 모르게 암묵적으로 해당 어플리케이션은 더 작은 작업들로 잘게 쪼개서 동시에 실행이 가능한 성격의 어플리케이션이라는 전제를 깔고 생각한다. 즉, 어플리케이션의 목적과 주제에 따라 아키텍쳐가 달라질 수 있다는 얘기인데, 예를들어 만약 개발하는 어플리케이션의 동작이 순차적으로 실행돼야만 하는 특징을 가지거나 잘게 쪼개서 동시에 실행하기에 매우 어려운 성격의 어플리케이션이라면 오히려 멀티 스레드 구성은 별 이점이 없다는 것이다. 이에 대한 대표적인 예시로는 CPU 바운드 어플리케이션과 I/O 바운드 어플리케이션을 예로 들 수 있다.

CPU 바운드
- CPU 연산 능력에 의존하는 작업을 말한다
- 데이터 마이닝, 영상 처리 작업, 이미지 프로세싱, 암호화폐 마이닝 ..등

I/O 바운드
- I/O 장치의 응답 속도에 의존하는 작업을 말한다
- 파일 입출력, 네트워크 통신, 데이터베이스 접근 ..등

CPU 바운드 어플리케이션

오라클에서 아키텍트로 일하고 있는 Goetz가 2002, 2006년에 발표한 자바 병렬 프로그래밍에 관한 책과 논문에 따르면 CPU 바운드 작업에서 적절한 스레드 수는 코어 수 + 1 이라고 주장했었다. 이는 위에서 살펴보았던 컨텍스트 스위칭 오버헤드 비용 때문이라는 걸 유추할 수 있을 것이다. 따라서 CPU 바운드 어플리케이션은 cpu를 많이 쓰기 때문에 코어수와 비슷한 수준 이상으로 스레드 수를 늘려봤자 별 이점이 없으며, 오히려 각 코에서 쓰레드 수가 많아질수록 컨텍스트 스위칭 때문에 오버헤드만 더 많아져서 성능이 안 좋은 영향을 주게 된다. 그래서 스레드의 개수가 적절하게 설정되어야 최적의 성능을 얻을 수 있는 것이다.

I/O 바운드 어플리케이션

파일 입출력, 네트워크 통신, 데이터베이스 조회와 같은 입출력 작업이 많을 경우 스레드를 늘리는 것이 좋다. 이러한 작업들은 I/O 장치의 응답 속도에 의존하는 것이 큰데, 예를 들어 파일 입출력은 파일을 읽기 위해 디스크에서 데이터를 조회하는데 있어 하드웨어 한계상 입출력 작업에 걸리는 시간이 상대적으로 오래 걸리므로 이때 CPU는 입출력이 완료될때까지 휴무 상태가 된다. 그래서 만일 싱글 스레드일 경우 I/O 작업하는 동안 블로킹 되어 아래와 같이 낭비가 발생하게 된다.

멀티 스레드는 I/O 작업이 처리될 동안 다음에 이행할 작업들을 다른 스레드에게 자원을 할당하여 수행할 수 있도록 할 수 있다. 네트워크 통신도 마찬가지로 네트워크 상황에 따라 전송 시간이 오래 걸릴 수 있으므로 통신 지연동안 스레드를 재활용 시키는 것이다.

따라서 I/O 작업이 많은 상황에서는 CPU 코어 수보다 2배 3배 혹은 그 이상으로 스레드 수를 늘려주는 것이 코어들을 더 효율적으로 쓸 수 있기 때문에 성능 면에서 이점이 얻을 수 있다. 그러나 우리가 앞서 배웠듯이 스레드를 늘리면 늘릴수록, 잔여 스레드의 컨텍스트 오버헤드와 동기화 등의 문제점이 동반 될 수 있기 때문에, I/O 바운드 어플리케이션에 멀티 스레드 모델 대신 비동기 I/O 처리에 특화된 이벤트 기반 프로그래밍 모델을 접목하기도 한다. 가장 대표적으로 Node.js 어플리케이션을 들 수 있다.

Node.js와 같은 싱글 스레드 + 이벤트 기반 프로그래밍 모델에서는 이벤트 루프(Event Loop)를 통해 이벤트를 감지하고, 이벤트 핸들러(Event Handler)를 호출하여 해당 이벤트를 처리하는 식이다. 만약 입출력 작업을 수행해야 하는 경우, 이벤트 핸들러는 비동기 I/O를 사용하여 입출력 작업을 수행하고, 입출력 작업이 완료될 때까지 이벤트 루프를 블로킹하지 않게 된다. 그래서 작업 처리 도중 다른 작업을 처리할 수 있어서, 멀티 스레드 모델에 비해 더 적은 리소스를 사용하고 높은 처리량을 보여줄 수 있다.

물론 비동기 I/O 처리 주체는 Node.js에 내장된 libuv 라이브러리의 스레드 풀에서 가져온 멀티 스레드로 처리하는 것이다. 웹브라우저도 멀티 스레드 프로그램이며 이를 이용해 비동기 작업을 수행하는 것이다.

Node.js 내부 구조

그러면 멀티 스레드 프로그래밍 모델과 차이점이 없냐고 말할 수 는 있겠지만, Node.js의 메인 스레드는 싱글 스레드이기 때문에 멀티 스레드 모델에서 발생할 수 있는 동기화 문제나 경쟁 상태 등을 걱정할 필요가 없이 CPU 바운드 혹은 I/O 바운드 작업이 발생하면 그때에만 멀티 스레드를 가져와 사용해, 이른바 멀티 스레드 모델 변형 버전인 '싱글 스레드 + 이벤트 기반 프로그래밍 모델 + 비동기 I/O 모델' 이라고 말한다.

GUI 어플리케이션

GUI 어플리케이션은 창(window), 아이콘(icon), 메뉴(menu), 포인터(pointer) 등의 그래픽 사용자 인터페이스(GUI)를 통해 사용자와 상호작용하는 애플리케이션이다. 키보드, 마우스, 터치스크린 등의 입력 장치로부터 발생하는 이벤트를 감지하고, 적절한 메시지나 액션을 수행 한다.

이러한 GUI 어플리케이션에서는 보통 싱글 스레드를 사용하는 것이 안정적이다. 멀티 스레드를 사용할 경우 스레드 간의 동기화 문제로 인해 이벤트 처리 순서가 뒤바뀌거나, 데드락이 발생할 가능성이 있어, UI 갱신에 문제가 생기게 되어 사용자 경험을 해치게 되기 때문이다. 따라서 이벤트 루프(Event Loop)를 이용해 이벤트 처리를 싱글 스레드로 순차적으로 처리하는 이벤트 기반 프로그래밍 모델에 적합하다.

5. 프로그래밍 난이도

싱글 스레드는 단 하나의 스레드가 모든 작업을 처리하기 때문에, 프로그램 구조가 단순하여 개발이 더 쉽고 CPU, 메모리를 적게 사용한다. 반면 멀티 스레드는 스레드 간의 동기화 처리, 잘못된 스레드 관리로 인해 메모리 누수, 데드락 등의 문제에 대해 관리가 필요하기 때문에 개발이 굉장히 복잡해진다.

글쓴이가 말하고 싶은 것은 당연히 대체적으로 멀티 스레드가 싱글 스레드 보다 성능이 더 뛰어나지만, 그렇다고 해서 무턱대고 어플리케이션 개발을 무작정 멀티 스레드로 진행하다 온갖 동시성 문제에 직면하여, 어플리케이션의 안정성과 유지보수성을 저해하는 것은 두마리 토끼를 모두 잡으려다가 한마리도 못 잡는 격이 되어 버릴수 있다는 점이다.

따라서 멀티 스레드 모델은 프로그래머에게 높은 수준의 역량과 경험이 필요하기 때문에 모델 선택에 있어 신중하게 고려하고, 프로그램의 특성과 목적에 따라 적절한 멀티 스레딩 전략을 선택하고, 성능 최적화와 동시성 관련 이슈들에 대한 철저한 이해와 학습이 필요해진다.

# 참고자료

https://youtu.be/jSaBkvtHhrM

https://www.bryanbraun.com/2012/06/25/multitasking-and-context-switching/

https://www.baeldung.com/java-volatile-variables-thread-safety

https://medium.com/@punyatoya213/multithreading-can-be-fun-too-part-2-e27f1841c8ca

https://medium.com/pocs/single-thread-server-vs-multi-thread-server-c1fda66bbcd0

https://realpython.com/python-concurrency/

자바스크립트 이벤트 루프 동작 구조 & 원리 끝판왕

인파_ — Mon, 8 May 2023 13:30:25 +0900

자바스크립트 비동기와 이벤트 루프

브라우저의 멀티 스레드로 작업을 동시에

Javascript는 싱글 스레드 언어라고 들어본 적이 있을 것이다. '싱글' 스레드라 한 번에 하나의 작업만 수행이 가능하다. 반면 Java 나 Python은 멀티 스레드를 지원하여 원하는 코드 로직을 동시에 수행 시키는 멀티 작업이 가능하다.

그런데 웹 애플리케이션에서는 네트워크 요청이나 이벤트 처리, 타이머와 같은 작업을 멀티로 처리해야 하는 경우가 많다. 만일 싱글 스레드로 브라우저 동작이 한번에 하나씩 수행하게 되면, 우리가 파일을 다운로드 받을 동안 브라우저는 파일을 다 받을 때까지 웹서핑도 못하고 멈춰 대기해야 할 것이다. 따라서 파일 다운, 네트워크 요청, 타이머, 애니메이션 이러한 오래 걸리고 반복적인 작업들은 자바스크립트 엔진이 아닌 브라우저 내부의 멀티 스레드인 Web APIs에서 비동기 + 논블로킹으로 처리된다. 비동기 + 논블로킹(Async + Non blocking)는 메인 스레드가 작업을 다른 곳에 요청하여 대신 실행하고, 그 작업이 완료되면 이벤트나 콜백 함수를 받아 결과를 실행하는 방식을 말한다. (쉽게 말해 파일 다운로드 요청 작업을 백그라운드 작업으로 전이하여 동시에 처리가 가능하도록 한 것으로 이해하면 된다)

즉, 비동기로 동작하는 핵심요소는 자바스크립트 언어가 아니라 브라우저라는 소프트웨어가 가지고 있다고 보면 된다. Node.js 에서는 libuv 내장 라이브러리가 처리한다.

이벤트 루프는 브라우저 동작을 제어하는 관리자

싱글 스레드인 자바스크립트의 작업을 멀티 스레드로 돌려 작업을 동시에 처리시키게 하던가, 또는 여러 작업 중 어떤 작업을 우선으로 동작시킬 것인지 결정하는 세심한 컨트롤을 하기 위해 존재하는 것이 바로 이벤트 루프(Event Loop) 이다. 이벤트 루프는 브라우저 내부의 Call Stack, Callback Queue, Web APIs 등의 요소들을 모니터링하면서 비동기적으로 실행되는 작업들을 관리하고, 이를 순서대로 처리하여 프로그램의 실행 흐름을 제어하는 녀석이다. 간단히 표현하자면 브라우저의 동작 타이밍을 제어하는 관리자라고 보면 된다.

이벤트 루프의 동작 과정을 간단히 살펴보자면, 자바스크립트의 ~~setTimeout~~이나 ~~fetch~~ 와 같은 비동기 자바스크립트 코드를 브라우저 Web APIs에게 맡기고, 백그라운드 작업이 끝난 결과를 콜백 함수 형태로 큐(Callback Queue)에 넣고 처리 준비가 되면 호출 스택(Call Stack)에 넣어 마무리 작업을 진행한다.

마치 순회(loop) 하는듯하여 이벤트 루프라 부르는 것이다

이러한 이벤트 루프를 이용한 프로그램 방식을 이벤트 기반(Event Driven) 프로그래밍이라고 한다. 이벤트 기반 프로그래밍은 프로그램의 흐름이 이벤트에 의해 결정되는 방식이다. 예를 들어 사용자의 클릭이나 키보드 입력과 같은 이벤트가 발생하면, 그에 맞는 콜백 함수가 실행한다. 대표적으로 자바스크립트의 ~~addEventListener(이벤트명, 콜백함수)~~ 가 있겠다.

이벤트 기반 프로그래밍은 으로 비동기 작업을 쉽게 처리할 수 있고, 멀티 스레드 언어에 비해 단순하고 직관적인 코드 작성을 가능하게 하며, 브라우저와 같은 환경에서도 안정적인 실행을 가능하게 하여 사용자와의 상호작용을 높일 수 있다. 따라서 이를 이해하고 적절한 방식으로 비동기 작업을 처리하는 것은, 자바스크립트를 이용한 웹 애플리케이션 개발에 있어서 매우 중요하다.

자바스크립트는 왜 싱글 스레드 인가?

자바스크립트는 1995년에 넷스케이프에서 웹 브라우저에서 동적인 웹 페이지를 만들기 위해 개발된 스크립트 언어이다. 당시에는 멀티 코어 프로세서가 보편화되지 않았고, 자바스크립트는 웹 브라우저에서 간단한 스크립트 동작을 수행하는 데 주로 사용되었기 때문에 복잡한 병렬 처리를 필요로 하지 않아, 메모리 사용량이 적고, 동기화 문제를 피할 수 있는 싱글 스레드로 구현하였다. 그러나 싱글 스레드는 오래 걸리는 작업이 실행되면 다른 작업들이 대기해야 하므로 응답성이 떨어진다. 또한 CPU 코어를 여러 개 사용할 수 없으므로 성능이 제한된다. 이러한 문제들을 해결하기 위해 언어 자체의 설계를 바꾸는 것 보단, 브라우저의 멀티 스레드를 이용하는 자바스크립트의 비동기 프로그래밍을 지원하는 것이다. 그리고 이 비동기 프로그래밍의 핵심이 이벤트 루프인 것이다. (다만 Web worker 최신 기술을 통해 자바스크립트도 멀티 스레드 구현이 가능해졌다)

자바스크립트 엔진 구동 환경

자바스크립트를 실행하는 소프트웨어로는 우리가 잘 알고 있는 웹브라우저와 런타임인 Node.js 가 있다. 이벤트 루프 동작 원리를 배우기 앞서, 싱글 스레드인 자바스크립트 엔진이 어느 곳을 거쳐 비동기 작업을 수행하는지 우선 이 둘의 내부 구성도를 눈에 익혀보자.

본 포스팅에서 예시를 드는 웹브라우저는 Chrome 브라우저이다. 다른 브라우저는 자바스크립트 엔진이나 내부 구성이 약간식 다를수 있다는 점은 유의하자

브라우저의 내부 구성도

브라우저는 웹 사이트를 화면에 보여주기 위해 여러가지 역할을 하는 부품들로 이루어져 있다. 그중 우리가 알아볼 것은 자바스크립트 비동기 코드의 동작 과정이니, 이에 관련된 구성 요소로는 Web APIs, Event Table, Callback Queue, Event Loop 등이 있다.

Call Stack : 자바스크립트 엔진이 코드 실행을 위해 사용하는 메모리 구조
Heap : 동적으로 생성된 자바스크립트 객체가 저장되는 공간
Web APIs: 브라우저에서 제공하는 API 모음으로, 비동기적으로 실행되는 작업들을 전담하여 처리한다. (AJAX 호출, 타이머 함수, DOM 조작 등)
Callback Queue : 비동기적 작업이 완료되면 실행되는 함수들이 대기하는 공간
Event Loop : 비동기 함수들을 적절한 시점에 실행시키는 관리자
Event Table: 특정 이벤트(timeout, click, mouse 등)가 발생했을 때 어떤 callback 함수가 호출되야 하는지를 알고 있는 자료구조 (위 그림에는 없음)

Web APIs의 종류

Web APIs는 타이머, 네트워크 요청, 파일 입출력, 이벤트 처리 등 브라우저에서 제공하는 다양한 API를 포괄하는 총칭이다. Web API는 브라우저(Chrome)에서 멀티 스레드로 구현되어 있다. 그래서 브라우저는 비동기 작업에 대해 메인 스레드를 차단하지 않고 다른 스레드를 사용하여 동시에 처리할수 있는 것이다.

예를 들어, ~~setTimeout~~ 비동기 작업은 Web APIs의 한 종류인 Timer API 에서 타이머 스레드를 사용하여 타이머를 수행한다. 마찬가지로, ~~XMLHttpRequest~~ , ~~fetch~~와 같은 네트워크 관련 API는 네트워크 스레드를 사용하여 네트워크 요청과 응답을 처리된다.

Web APIs의 대표적인 종류로는 다음과 같다.

DOM : HTML 문서의 구조와 내용을 표현하고 조작할 수 있는 객체
XMLHttpRequest: 서버와 비동기적으로 데이터를 교환할 수 있는 객체. AJAX기술의 핵심.
Timer API: 일정한 시간 간격으로 함수를 실행하거나 지연시키는 메소드들을 제공
Console API : 개발자 도구에서 콘솔 기능을 제공
Canvas API: ~~<canvas>~~ 요소를 통해 그래픽을 그리거나 애니메이션을 만들 수 있는 메소드들을 제공
Geolocation API: 웹 브라우저에서 사용자의 현재 위치 정보를 얻을 수 있는 메소드들을 제공

이때 오해하지 말하야할 것이 모든 Web API들이 비동기로 동작되는 것이 아니다. Web API에는 동기적으로 처리되는 것과 비동기적으로 처리되는 것이 모두 있다. 예를 들어 DOM API나 Console API는 동기적으로 처리되고, XMLHttpRequest나 Timer API는 비동기적으로 처리된다.

Callback Queue의 종류

Web APIs가 여러 API들을 묶어 말하듯이, Callback Queue도 여러가지 종류의 Queue를 묶어 총칭하는 개념이다. Callback Queue에는 (macro)task queue와 microtask queue 두 가지 종류가 있다.

Task Queue : ~~setTimeout~~, ~~setInterval~~, ~~fetch~~, ~~addEventListener~~ 와 같이 비동기로 처리되는 함수들의 콜백 함수가 들어가는 큐 (macrotask queue 는 보통 task queue 라고 부른다)
Microtask Queue : ~~promise.then~~, ~~process.nextTick~~, ~~MutationObserver~~ 와 같이 우선적으로 비동기로 처리되는 함수들의 콜백 함수가 들어가는 큐 (처리 우선순위가 높음)

Callback Queue의 종류에 따라 이벤트 루프가 콜 스택으로 옮기는 순서가 달라진다. 일반적으로 microtask queue가 가장 우선순위가 높아 먼저 microtask queue를 처리하여 먼저 비우고 그라음 task queue의 콜백을 처리한다.

이벤트 루프를 배우기 전에 ~~Promise.then~~ 결과가 ~~setTimeout~~보다 우선 된다는 것을 미리 배웠다면, 왜 프로미스가 먼저 처리되는지에 대한 이유가 이벤트 루프의 동작 원리와 관련이 있다는걸 알 수 있을 것이다.

또한 같은 queue 안에 적재되는 콜백이라도 어떠한 비동기 작업이냐에 따라 우선순위가 다른 태스크들이 있을 수 있다. 예를들어 Microtask Queue에 적재되는 Promise 와 Mutation Observer 콜백 중 Mutation Observer이 먼저 처리되는 식이다.

AnimationFrame Queue

브라우저의 큐는 콜백 큐 뿐만 아니라 브라우저 애니메이션 작업에 대한 처리를 담당하는 AnimationFrame Queue도 있다. 자바스크립트 애니메이션 동작을 제어하는 ~~requestAnimationFrame~~ 메소드를 통해 콜백을 등록하면, 이 큐에 적재되어 브라우저가 repaint 직전에 AnimationFrame Queue에 있는 작업들을 전부 처리한다. 따라서 자바스크립트 스타일 관련 코드들을 AnimationFrame Queue에 비동기로 처리하도록 구성하면 브라우저가 애니메이션의 타이밍을 관리하고, 적절한 프레임 속도를 유지하고, 다른 탭이나 창에 있을 때 애니메이션을 중지함으로써 브라우저의 애니메이션 동작의 성능과 품질을 향상시킬 수 있다.

웹 애니메이션 최적화 requestAnimationFrame 가이드

자바스크립트 웹 애니메이션 웹페이지의 애니메이션을 구현할때 CSS의 animatoin , transition , transform 속성을 통해 구현할 수도 있지만, 보다 사용자와의 복잡한 상호작용을 구현하게 하기 위해 Javasc

inpa.tistory.com

Node.js의 내부 구성도

NodeJS 환경에서도 브라우저와 거의 비슷한 구조를 볼 수 있는데, 차이점이 있다면 내장된 libuv 라이브러리를 사용하여 비동기 IO를 지원한다는 점이다. 또한 브라우저에서는 Web API를 사용하여 DOM 조작, AJAX 호출, 타이머 및 애니메이션 등과 같은 다양한 작업을 처리하지만, Node.js에서는 Web API가 아닌 Node.js API를 사용하여 파일 시스템 액세스, 네트워크 액세스, 암호화, 압축 및 해제 등과 같은 다양한 작업을 처리한다. 예를 들어, Node.js에서 HTTP 요청을 수행하려면 http 모듈을 사용한다. 단, Node.js에서도 일부 Web API를 사용할 수 있는데, ~~setTimeout~~, ~~setInterval~~ 등이 그렇다.

이처럼 Node.js에서 자바스크립트 엔진은 비동기 작업을 위해서 Node.js의 API를 호출하며, 이때 넘겨진 콜백은 libuv 의 이벤트 루프를 통해 스케쥴되고 실행된다. Node.js의 내부 구성으로는 다음과 같다.

V8 (JavaScript 엔진) : Node.js에서 사용하는 JavaScript 엔진으로 코드를 컴파일하고 실행한다
Bindings (Node API) : Node.js 시스템과 V8 엔진 간의 상호작용을 가능하게 하는 C++ 라이브러리
Libuv 라이브러리 : Node.js에서 비동기 I/O 작업을 처리하기 위한 C 라이브러리
Event Queue : 비동기 I/O 작업 결과를 저장하고 처리하기 위한 자료구조 (웹브라우저의 Task Queue와 비슷하다)
Event Loop : Event Queue에 저장된 I/O 작업 결과를 처리하고, 다음 작업을 수행하도록 하는 관리자
Worker Threads : CPU 집약적인 작업을 처리하기 위해 Node.js 10 버전부터 추가된 멀티 스레드. worker threads는 메인 스레드와 독립적인 V8 엔진 인스턴스를 가진다.

자바스크립트 이벤트 루프 동작 과정

앞의 내용을 복습하자면, 싱글 스레드인 자바스크립트에서도 작업의 동시 처리을 지원할 수 있는 비결에는 이벤트 루프가 자바스크립트 엔진과 브라우저의 웹 API를 연결하여 비동기적인 일 처리를 가능케 하기 때문이다. 다만 모든 자바스크립트 코드를 비동기로 처리할 수 있는 것은 아니다. 자바스크립트에는 비동기로 동작하는 비동기 전용 함수가 있는데 대표적으로 ~~setTimeout~~ 이나 ~~fetch~~, ~~addEventListener~~ 가 있다.

브라우저의 Web APIs는 위 그림과 같이 각각 전용 작업을 처리하는 API 스레드들로 구성된 집합을 말한다. 따라서 ~~setTimeout~~ 이 호출되면 Timer API 라는 별도의 스레드에서 타이머 동작이 별도로 실행되는 것이며, ~~fetch~~ 가 호출되면 Ajax API 스레드에서 네트워크 통신이 이루어 지는 것이다.

이벤트 루프(Event Loop)는 이 비동기 함수 작업을 Web API에 옮기는 역할을 하고 작업이 완료되면 콜백을 큐(Queue)에 적재했다가 다시 자바스크립트 엔진에 적재해 수행시키는 일종의 '작업을 옮기는 역할' 만을 한다. 작업을 처리하는 주체는 자바스크립트 엔진과 웹 API 이다. 그래서 이벤트 루프는 Call Stack에 현재 실행 중인 작업이 있는지 그리고 Task Queue에 대기 중인 작업이 있는지 반복적으로 확인하는 일종의 무한 루프만을 돌고, 대기 작업이 있다면 작업을 옮겨주는 형태로 동작한다고 보면 된다. (그래서 이벤트 '루프' 이다)

// 이벤트 루프의 동작을 나타내는 가상의 코드
while(queue.waitForMessage()){ // 큐에 메시지가 있을 때까지 대기
  queue.processNextMessage(); // 가장 오래된 메시지를 큐에서 꺼내서 호출 스택으로 옮김
}

지금부터 알아볼 이벤트 루프 동작 과정은 자바스크립트 코드가 브라우저 내부에서 작업 이동이 어떠한 형식으로 어떠한 원리로 진행이 되는지 알아보는 것이다. 마침 자바스크립트 이벤트 루프 과정을 Lydia Hellie 분이 아주 고퀄리티로 gif 애니메이션으로 표현한 이미지가 있어서 이를 참고하여 소개해본다.

setTimeOut 내부 동작 과정

우선 가장 흔한 타이머 비동기 함수의 이벤트 루프 과정을 알아보도록 하자.

function bar() {
  setTimeout(() => {
  	console.log("Second")
  }, 500);
}

function foo() {
  console.log("First");
}

function baz() {
  console.log("Third");
}

bar();
foo();
baz();

위의 자바스크립트 코드 실행 과정은 다음의 순서로 진행된다.

~~bar()~~ 함수가 호출되고 그안의 ~~setTimeout()~~ 함수가 호출되어 스택에 쌓인다.
~~setTimeout()~~ 함수의 매개변수에 할당된 콜백 함수를 Timer Web API에 전달한다. 그리고 Timer Web API 에서는 백그라운드로 500 밀리초를 셈한다.
다음 ~~foo()~~ 함수가 호출되고 콘솔창(output)에 "First" 가 출력된다.
이때 500 밀리초 대기 시간이 만료되면서, 이벤트 루프는Timer Web API에서 가지고 있던 콜백 함수를 Task Queue 로 옮긴다.
그다음 ~~baz()~~ 함수가 호출되고 콘솔창에 "Third" 가 출력된다.
스택에 있는 모든 메인 자바스크립트 코드가 실행 완료 되어 Call Stack이 비워지게 된다.
이벤트 루프는 Call Stack 이 비어있는 경우를 탐지하여, Task Queue 에 있는 콜백 함수를 Call Stack 으로 옮긴다.
Call Stack 에서 콜백 함수 코드를 실행하게 되고 콜솔창에는 "Second" 가 출력된다.

이 동작 원리의 핵심은 특정한 작업에 대해 비동기로 멀티 작업을 할 수 있다는 것이다. 비동기 동작 예시가 고작 타이머를 셈하는 ~~setTimeout~~ 이라 잘 와닿지 않을 수 있다. 하지만 파일 입출력이나 키보드 타이핑 하는 이벤트 동작일 경우라면 어떻까? 비동기가 없다면 파일을 다운 받거나 키보드를 타이핑 하는 동안에는 동안 웹사이트는 멈추게 되어 아무것도 못하게 될 것이다. 바로 이벤트 루프는 이러한 작업들을 별도로 브라우저의 멀티 스레드에게 인가하여 비동기로 처리해주는 핸들러 역할을 하는 것이다.

웹브라우저와 Node.js의 Web API 차이

웹브라우저의 Web APIs 와 Node.js 의 Node.js APIs 들은 구성은 비슷하지만 동작 측면에서 약간 차이가 있다. 웹브라우저의 Web APIs는 비동기 작업이 끝나면 스스로 callback queue에 적재하지만, Node.js API들은 이벤트 루프가 직접 옮겨준다. 예를들어 Timer Web API에서 타이머가 모두 지나가면, 자바스크립트 환경이 웹브라우저냐 Node.js 냐에 따라 차이가 갈린다.

Node.js : Timer API가 타이머 완료 이벤트를 발생시키고, 이벤트 루프가 이를 감지하여 Task Queue에 콜백 함수를 추가한다.
웹브라우저 : Timer API가 스스로 Task Queue에 콜백 함수를 추가한다.

Promise 내부 동작 과정

Task Queue 와 Microtask Queue

Callback Queue는 Web API가 수행한 비동기 함수를 넘겨받아 Event Loop가 해당 함수를 Call Stack에 넘겨줄 때까지 비동기 함수들을 쌓아놓는 곳이다. 위에서 Callback Queue의 종류에는 (Macro)Task Queue, MicroTask Queue 2가지가 있다고 하였는데, 그중 자바스크립트 Promise 객체의 콜백이 쌓이는 곳이 바로 MicroTask Queue이다. 그리고 MicroTask Queue는 그 어떤 곳보다 가장 먼저 우선으로 콜백이 처리되게 된다. (심지어 브라우저 화면 렌더링하기 전보다 말이다)

MicroTask Queue 처리 과정

실제 예시 코드에서 setTimeout 가 Promise 객체의 콜백이 동시에 주어졌을때 어떻게 처리되는지 확인해보자. 코드 내용을 살펴보면 먼저 setTimeout 을 통해서 0초동안 대기 하였다가 "Timeout!" 을 출력하는 콜백 함수를 실행한다. 그다음 Promise 객체에 의해 "Promise!" 라는 텍스트를 출력하는 then 핸들러의 콜백 함수를 실행한다. 이 코드를 실행해보면 아래와 같이 동작 애니메이션이 발생한다.

console.log('Start!');

setTimeout(() => {
	console.log('Timeout!');
}, 0);

Promise.resolve('Promise!').then(res => console.log(res));

console.log('End!');

1. Call Stack에 ~~console.log('Start!')~~ 코드 부분이 쌓인 뒤 실행 되어 콘솔창에 "Start!" 가 출력

2. ~~setTimeout~~ 코드가 콜 스택에 적재되고 실행되면, 그 안의 콜백 함수가 이벤트 루프에 의해 Web API로 옮겨지고 타이머가 작동하게 된다. (0초라서 사실상 바로 타이머는 종료된다)

3. 타이머가 종료됨에 따라 ~~setTimeout~~ 의 콜백 함수는 MacroTask Queue에 이벤트 루프에 의해 적재되게 된다.

4. ~~Promis~~e 코드가 콜스택에 적재 되어 실행되고 ~~then~~ 핸들러의 콜백 함수가 이벤트 루프에 의해 MicroTask Queue에 적재되게 된다.

5. ~~console.log('End!')~~ 코드가 실행되고 "End!" 텍스트가 콘솔창에 출력된다.

6. 모든 메인 스레드의 자바스크립트 코드가 실행이되어 더이상 Call Stack엔 실행할 스택이 없어 비워지게 된다.

7. 그러면 이벤트 핸들러가 이를 감지하여, Callback Queue에 남아있는 콜백 함수들을 빼와 Call Stack에 적재하게 된다.

8. 이때 2종류의 Queue 중 MicroTask Queue에 남아있는 콜백이 우선적으로 처리된다. (만일 콟개이 여러개가 있다면 전부 처리된다)

9. MicroTask Queue가 비어지면, 이제 이벤트 루프는 MacroTask Queue에 있는 콜백 함수를 Call Stack에 적재해 실행되게 된다.

따라서 최종 코드의 실행 순서는 아래와 같이 된다.

Async/Await 내부 동작 과정

자바스크립트의 Async/Await 는 비동기 논블로킹 동작을 동기적으로 처리하기 위해 ES7 부터 새롭게 도입된 것으로 복잡한 콜백이나 ~~then~~ 핸들러의 지옥(hell) 코드를 극복하는 핵심이다. Async/Await 의 기본적인 사용 문법에 대해서는 독자분들도 익히 알고 있을 것이다. 하지만 많은 사람들이 Async/Await 을 단순히 비동기를 동기적으로 처리해준다는 효과만 알고있어서인지, 비동기 코드와 동기 코드가 같이 쓰여져 있을 경우 이들의 확실한 처리 과정을 정확하게 알지 못한다.

예를들어 다음과 같이 async 함수를 동일 코드 레벨에서 실행한다고 해보자.

const one = () => Promise.resolve('One!');

async function myFunc(){
	console.log('In function!');
	const res = await One();
	console.log(res);
}

console.log('Before Function!');
myFunc();
console.log('After Function!');

1. 콘솔에 'Before Function!' 이 출력된다.

2. async 함수인 ~~myFunc()~~ 이 호출된다.

3. async 함수 안에 있는 콘솔 함수가 실행되어 콘솔에 'In Function!' 이 출력된다.

가끔 async 함수를 메인 코드가 모두 실행되어야 나중에 실행되는 비동기 함수로 알고 있는 사람들이 많은데, async 함수는 블럭 내부에서 await 키워드를 사용하기 위한 함수 키워드 일 뿐 그냥 프로미스 객체를 반환하는 조금 특벽한 일반적인 함수이다. 따라서 async 함수라도 일반 함수처럼 호출 스택이 쌓이고, async 함수 내의 비동기가 아닌 동기 코드는 일반 코드와 같이 실행된다.

4. Promise 객체를 반환하는 ~~one()~~ 비동기 함수를 호출한다.

5. 이때 ~~one()~~ 비동기 함수 왼쪽에 ~~await~~ 키워드로 인해, ~~myFunc~~ 함수의 내부 실행은 잠시 중단되고 Call stack 에서 빠져나와 나머지 부분은 Microtask Queue 에 적재된다. 이는 자바스크립트 엔진이 ~~await~~ 키워드를 인식하면 async 함수의 실행은 지연되는 것으로 처리하기 때문이다.

6. 마지막으로 콘솔에 'After Function!' 이 출력된다.

7. 모든 메인 스레드의 자바스크립트 코드가 실행이되어 더이상 Call Stack엔 실행할 스택이 없어 비워지게 된다.

8. 그러면 이벤트 핸들러가 이를 감지하여, Microtask Queue에 남아있는 async 함수를 빼와 Call Stack에 적재하게 된다.

8. Promise 객체의 결과물인 'One!' 문자열을 변수 ~~res~~ 에 받고 이를 콘솔에 출력한다.

Async/Await 오해와 진짜 동작

그럼 이번에는 ~~myFunc()~~ 함수를 호출하는 메인 스택에서 ~~await~~ 키워드를 붙여주면 어떻게 될까? 참고로 최신 자바스크립트에서는 최상위 await 을 지원하기 때문에 별도로 즉시 실행 IIFE를 묶지 않아도 동작이 가능하다.

const one = () => Promise.resolve('One!');

async function myFunc(){
	console.log('In function!');
	const res = await one();
	console.log(res);
}

console.log('Before Function!');
await myFunc();
console.log('After Function!');

출력 결과를 보면, 위의 Async/Await 처리 과정 1 과 다른 결과가 나오는걸 볼 수 있다. 일단 기본적인 Async/Await 문법 개념을 알고 있다면 이 부분은 그렇게 어렵지 않을 것이다. 하지만 우리는 지금 이벤트 루프 동작에 대해 배우고 있다. 그럼 저 최상위 await 코드 동작을 이벤트 루프로 내부적으로 따져보자.

아마 많은 새내기들이 여기서 막힐 것이다. 우리는 await 키워드를 사용하는 Promise 반환 비동기 ~~one()~~ 함수의 결과 콜백이 Microtask Queue에 적재된다는 것을 알고 있다. 그런데 Microtask Queue의 콜백들은 우선 메인 Call Stack이 비워져 있어야 이벤트 루프가 옮겨 처리한다. 하지만 아직 메인 Call Stack에는 ~~console.log(‘After Function!’)~~ 이 남아 있다. 그런데 출력 결과를 보면 ~~console.log(‘After Function!’)~~ 이 실행되기 전에 ~~await myFunc()~~ 먼저 처리되고 콘솔을 출력함을 볼 수 있다.

이게 어떻게 된 일 일까? 우리가 지금까지 배운 이벤트 루프 동작이 잘못된 것일까?

사실 Async/Await의 진짜 동작은 다음과 같다. 예를 들어, 아래와 같은 코드가 있다고 하자.

let x = await bar(); // bar() 함수 정의는 생략
console.log(x);
console.log('Done');

위의 코드는 사실 다음과 같은 코드와 같은 의미를 가진다.

bar().then(x => { 
    console.log(x); 
    console.log('Done'); 
});

즉, await 키워드 다음에 나오는 동일 라인의 코드들은 모두 ~~await bar()~~ 의 ~~then~~ 핸들러의 콜백 함수로 들어간다는 뜻이다.

실제로 async/await 키워드는 ~~promise.then()~~ 메소드를 사용하지 않고도 비동기 코드를 작성할 수 있게 해주는 문법적인 편의 기능(syntactic sugar)일 뿐이다. 즉, async/await 키워드는 ~~promise.then()~~ 메소드를 대체하는 것이 아니라, promise.then() 메소드를 간결하고 명확하게 작성할 수 있게 해주는 것이다.

따라서 최종 정리하자면 ~~myFunc()~~ 코드는 프로미스 핸들러로 풀면 아래와 같이 구성되게 되고, 각 then 핸들러들이 MicroTask Queue에 차곡 차곡 쌓임으로써 순서대로 출력되는 것이다.

const one = () => Promise.resolve('One!');

async function myFunc(){
	console.log('In function!');
	const res = await one();
	console.log(res);
}

console.log('Before Function!');
await myFunc();
console.log('After Function!');

/* ---------------- ↓↓↓ 변환 ↓↓↓ ---------------- */

const one = () => Promise.resolve('One!'); 

function myFunc(){
	console.log('In function!');
	return one().then(res => {
	  console.log(res);
	});
}

console.log('Before Function!');
myFunc().then(() => {
  console.log('After Function!');
});

즉, ~~await myFunc()~~ 다음에 나오는 코드들이 ~~myFunc()~~의 then 핸들러의 콜백으로서 Microtask Queue에 적재되고 이벤트 루프에 다시 Call stack에 옮겨져서 실행되는 것이다.

MicroTask Queue의 무한 루프

Task Queue와 MicroTask Queue의 차이점은 단순한 우선순위 차이 정도 밖에 없지만, 좀더 확장해서 브라우저 동작 관점에서 보면 이는 굉장히 중요한 요소이다. MicroTask Queue의 콜백은 가장 높은 우선 순위로 처리되지만 이는 브라우저가 화면을 렌더링하는 과정보다 더 먼저 처리되게 되는데, 만일 MicroTask Queue에 잘못된 무한 루프 동작의 버그의 코드가 들어가게 되면 웹페이지가 먹통이 되어버리는 현상이 발생할 수 있기 때문이다.

아래 코드를 봐보자. 버튼이 하나 있고 여기에 이벤트 콜백이 등록 되어 있다. 이 이벤트 콜백은 Task Queue에 적재되어 실행되게 된다.

<button id="btn">Click me</button>

<script>
  // 버튼을 클릭하면 콘솔에 Clicked를 출력하는 이벤트 핸들러를 등록합니다.
  document.getElementById("btn").addEventListener("click", () => {
    document.body.insertAdjacentHTML('beforeend', "<p>Clicked</p>");
  });
</script>

See the Pen MicroTask Queue의 무한 루프 1 by barzz12 (@inpaSkyrim) on CodePen.

이 상태에서 한번 ~~setTimeout~~ 무한 루프를 구현해보자. 아래 '무한루프 시작' 버튼을 누르면 타이머가 계속 돌여 "Loop" 콘솔을 출력할 것이다. 그 상태에서 버튼을 Click me 해보자. 아무 이상 없이 화면에 'Clicked'가 표시될 것이다.

~~setTimeout~~ 의 루프 콜백이 Task Queue에 실시간으로 적재되면서 처리되는 도중, 버튼 클릭 이벤트를 발생시키면 이벤트 콜백 역시 Task Queue에 적재되어 실행이 되기 때문에, 비록 무한 루프 코드라도 브라우저 동작 자체는 문제없는 것이다.

<button id="btn">Click me</button>
<button id="btn2">무한루프 시작</button>

<div id="loopArea" style="border: 1px solid black; max-height: 150px; overflow-y: auto;"></div>

<script>
  // 버튼을 클릭하면 콘솔에 Clicked를 출력하는 이벤트 핸들러를 등록합니다.
  document.getElementById("btn").addEventListener("click", () => {
    document.body.insertAdjacentHTML('beforeend', "<p>Clicked</p>");
  });

  document.getElementById("btn2").addEventListener("click", () => {
    // setTimeout 함수는 Task Queue에 콜백을 추가
    function loop() {
      setTimeout(() => {
        document.getElementById("loopArea").append("Loop\n");
        loop(); // loop 함수가 setTimeout 객체의 콜백으로 자신을 계속해서 추가
      }, 0);
    }

    // loop 함수를 호출
    loop();
  });
</script>

See the Pen MicroTask Queue의 무한 루프 2 by barzz12 (@inpaSkyrim) on CodePen.

이번에는 Promise 객체를 이용해 재귀 함수 호출로 무한 루프를 구현해 보자. 로프 동작 코드 자체는 위의 ~~setTimeout~~과 별다른 차이가 없다. 다만 이 루프 콜백이 Task Queue 가 아닌 MicroTask Queue에 들어간다는 차이점이 있는데, MicroTask Queue 가 무한 루프에 빠지게 되면 어떻게 되는지 보자. (예비 브라우저를 하나 준비해서 테스트하기를 권장한다)

<button id="btn">Click me</button>
<button id="btn2">무한루프 시작</button>

<div id="loopArea" style="border: 1px solid black; max-height: 150px; overflow-y: auto;"></div>

<script>
  // 버튼을 클릭하면 콘솔에 Clicked를 출력하는 이벤트 핸들러를 등록합니다.
  document.getElementById("btn").addEventListener("click", () => {
    document.body.insertAdjacentHTML('beforeend', "<p>Clicked</p>");
  });

  document.getElementById("btn2").addEventListener("click", () => {
    // Promise 객체는 MicroTask Queue에 콜백을 추가
    function loop() {
      Promise.resolve().then(() => {
        document.getElementById("loopArea").append("Loop\n");
        loop(); // loop 함수가 Promise 객체의 콜백으로 자신을 계속해서 추가
      });
    }

    // loop 함수를 호출
    loop();
  });
</script>

See the Pen MicroTask Queue의 무한 루프 3 by barzz12 (@inpaSkyrim) on CodePen.

웹사이트가 먹통이 되어 버릴 것이다. 똑같은 무한 루프 동작인데 하나는 웹사이트 동작에 문제가 없었고, 하나는 웹사이트 자체가 블락이 되어버려 어떠한 동작을 할 수 없게 된 것이다. 왜냐하면 MicroTask Queue가 비어있지 않으므로 다른 매크로태스크나 이벤트 콜백이 실행될 수 없기 때문이다. 무한 루프 코드 때문에 끊임없이 MicroTask Queue에 콜백이 적재되게 되고 이벤트 루프가 이들을 브라우저 화면 렌더링을 하기전에 우선으로 끊임 없이 처리 또 처리하고 있기 때문에, 결국 사용자 이벤트에 반응하지 못하고, 페이지가 멈추거나 응답하지 않게 되는 것이다.

이 예시 코드의 사례는 조금 극단적인 억지 코드라 잘 와닿지 않을 수 있다. 하지만 이 파트의 핵심은 만일 MicroTask Queue를 사용하는 Promise 코드나 Mutation Observer 의 콜백에서 무한 루프 까지는 아니더라도 지나치게 MicroTask Queue에 콜백을 지나치게 적재하는 작업이 있다면 이를 조심히 다루어야 한다는 점이다.

Animation Frames

Animation Frames는 브라우저가 화면을 다시 그릴 때 실행되는 함수들을 담아두는 곳이다. 예를 들어, 웹 페이지에서 움직이는 동그라미를 그리고 싶다면, requestAnimationFrame이라는 함수를 사용해서 동그라미의 위치를 바꿔주는 콜백 함수를 매개변수로 넣어줘 Animation Frames에 적재되어 실행된다. 그러면 브라우저가 화면을 갱신할 때마다 동그라미의 위치가 바뀌면서 움직이는 것처럼 보이게 된다.

// setTimeout() 함수 매개변수에 콜백 함수를 넣어주듯이 requestAnimationFrame도 마찬가지이다
requestAnimationFrame(function() {
    // 동그라미의 요소를 찾아서 변수에 저장
    let circle = document.getElementById("circle");

    // 동그라미의 스타일을 변경하여 위치를 반영
    circle.style.left = x + "px";
    circle.style.top = y + "px";
})

Animation Frames의 우선순위는 브라우저에 따라 다를 수 있다. Task Queue와 Microtask Queue가 모두 처리된 후에 실행될 수도 있고, Task Queue와 Microtask Queue 사이에 실행될 수도 있다. 이는 이벤트 루프의 명세가 업데이트 렌더링 단계에서 언제 콜백을 호출할지 정확하게 정의하지 않기 때문이다.

console.log("script start");

// task queue에 적재
setTimeout(function () {
  console.log("setTimeout");
}, 0);

// microtask queue에 적재
Promise.resolve()
  .then(function () {
    console.log("promise1");
  })
  .then(function () {
    // 8. microtask 실행
    console.log("promise2");
  });

// AnimationFrame에 적재
requestAnimationFrame(function () {
  console.log("animation");
});

console.log("script end");

"script start"를 출력
setTimeout 함수가 Task Queue에 “setTimeout” 태스크를 추가
Promise.resolve 함수가 MicroTask Queue에 “promise1” 태스크를 추가
requestAnimationFrame 함수가 Animation Frames Queue에 “animation” 태스크를 추가
"script end"를 출력
"promise1"을 출력
Promise.then 함수가 마이크로태스크 큐에 “promise2” 태스크를 추가
"promise2"를 출력
"animation"을 출력
"setTimeout"을 출력

자바스크립트 이벤트 루프 시각화

직접 코드를 쓰고 조작하여 애니메이션으로 볼 수 있는 시각화 사이트가 있어 소개해본다. 이것저것 실험해보며 브라우저 내부에서 비동기 동작이 어떠한 순서로 일어나는지 알아보자.

http://latentflip.com/loupe/?code=JC5vbignYnV0dG9uJywgJ2NsaWNrJywgZnVuY3Rpb24gb25DbGljaygpIHsKICAgIHNldFRpbWVvdXQoZnVuY3Rpb24gdGltZXIoKSB7CiAgICAgICAgY29uc29sZS5sb2coJ1lvdSBjbGlja2VkIHRoZSBidXR0b24hJyk7ICAgIAogICAgfSwgMjAwMCk7Cn0pOwoKY29uc29sZS5sb2coIkhpISIpOwoKc2V0VGltZW91dChmdW5jdGlvbiB0aW1lb3V0KCkgewogICAgY29uc29sZS5sb2coIkNsaWNrIHRoZSBidXR0b24hIik7Cn0sIDUwMDApOwoKY29uc29sZS5sb2coIldlbGNvbWUgdG8gbG91cGUuIik7%21%21%21PGJ1dHRvbj5DbGljayBtZSE8L2J1dHRvbj4%3D

latentflip.com

# 참고자료

[10분 테코톡] 병민의 브라우저의 Event Loop

https://dev.to/lydiahallie/javascript-visualized-event-loop-3dif

https://dev.to/lydiahallie/javascript-visualized-promises-async-await-5gke

https://iamsjy17.github.io/javascript/2019/07/20/how-to-works-js.html

https://meetup.nhncloud.com/posts/89

https://sculove.github.io/post/javascriptflow/

‍ 완벽히 이해하는 동기/비동기 & 블로킹/논블로킹

인파_ — Tue, 2 May 2023 21:25:07 +0900

동기/비동기 & 블로킹/논블록킹

프로그래밍에서 웹 서버 혹은 입출력(I/O)을 다루다 보면 동기/비동기 & 블로킹/논블로킹 이러한 용어들을 접해본 경험이 한번 쯤은 있을 것이다. 대부분 사람들은 용어들이 나타내고자 하는 행위에 대해선 멀티 태스킹과 밀접한 관련이 있다는 것을 알고 있다. 그래서 두 개념을 비슷한 것으로 오해하는 사람들이 꽤 많다. ‍

동기/비동기 와 블로킹/논블로킹 이 두 개념은 표현 형태는 비슷해 보일지라도, 서로 다른 차원에서 작업의 수행 방식을 설명하는 개념이다. 동기/비동기는 요청한 작업에 대해 완료 여부를 신경 써서 작업을 순차적으로 수행할지 아닌지에 대한 관점이고,블로킹/논블록킹은 단어 그대로 현재 작업이 block(차단, 대기) 되느냐 아니냐에 따라 다른 작업을 수행할 수 있는지에 대한 관점이다.

이처럼 두 개념에 대한 의미 차이는 명확하지만, 프로그래밍에서는 종종 혼용되어 사용되기도 한다. 대표적으로 자바스크립트의 ~~setTimeout()~~ 함수를 일반적으로 비동기 함수라고만 부르지만 동시에 논블로킹 함수이기도 하다. 즉, 우리가 편의상 부르는 자바스크립트 비동기 함수는 사실 비동기 + 논블로킹 함수인 것이다. 따라서 이들을 정확하게 구분하고 이해하는 것이 컴퓨터 아키텍쳐를 이해하는데 있어 중요하다.

동기(Synchronous) / 비동기(Asynchronous)

동기(同期)와 비동기(非同期)를 알아보기 앞서, 이 두 개념을 한글이 아닌 영단어로 학습 하길 강력히 권장하는 바다. 왜냐하면 한글로 직역하자면 '같은 기간' 또는 '같은 주기'라는 뜻의 한자를 사용하는데 오히려 의미를 이해하는데 있어 더욱 혼동만 주기 때문이다. 그래서 영단어를 파보자면 Synchronous의 Syn는 그리스어로 '함께'이란 뜻이고 chrono는 '시간'이라는 뜻이다.

즉, Synchronous는 작업 시간을 함께 맞춰서 실행한다 라는 뜻으로 해석된다. 작업을 맞춰 실행한다는 말은 요청한 작업에 대해 완료 여부를 따져 순차대로 처리하는 것을 말한다. Asynchronous는 앞에 A라는 접두사가 붙어 부정하는 형태이다. 그래서 동기와 반대로 요청한 작업에 대해 완료 여부를 따지지 않기 때문에 자신의 다음 작업을 그대로 수행하게 된다.

동기는 작업 B가 완료되어야 다음 작업을 수행하고, 비동기는 작업 B의 완료 여부를 따지지 않고 바로 다음 작업을 수행한다

비동기의 성능 이점

보통 비동기 특징을 이용하여 성능과 연관지어 말한다. 왜냐하면 요청한 작업에 대하여 완료 여부를 신경쓰지 않고 자신의 그다음 작업을 수행한다는 것은, I/O 작업과 같은 느린 작업이 발생할 때, 기다리지 않고 다른 작업을 처리하면서 동시에 처리하여 멀티 작업을 진행할수 있기 때문이다. 이는 전반적인 시스템 성능 향상에 도움을 줄 수 있다.

예를 들어, 웹 애플리케이션에서 데이터베이스 쿼리를 수행하는 작업이 있다고 가정해보자. 이 작업을 만일 동기적으로 수행하면, 데이터베이스에서 응답이 올 때까지 기다려야 한다. 그러면 이 때 웹 애플리케이션은 다른 요청을 처리하지 못하므로, 대규모 트래픽이 발생할 경우 웹 애플리케이션의 성능이 저하될 수 있다. 하지만 비동기 방식으로 데이터베이스 쿼리를 수행하면, 데이터베이스에서 응답이 올 때까지 기다리는 동안에도 다른 요청을 '동시에 처리'할 수 있게 된다. 이렇게 비동기 방식을 사용하면, 대규모 트래픽에서도 안정적으로 동작할 수 있는 웹 애플리케이션을 만들 수 있다.

여기서 '동시 처리' 라는 개념은 두 개 이상의 작업이 동시에 실행되는 것을 의미 한다. 이는 멀티 스레드나 멀티 프로세싱과 같은 방식으로 구현될 수 있다. 자바스크립트 같은 경우 비동기로 작업을 요청하면 브라우저에 내장된 멀티 스레드로 이루어진 Web API에 작업이 인가되어 메인 Call Stack과 작업이 동시에 처리되게 된다. 쉽게 비유하자면 작업을 백그라운드에 인가한다고 생각하면 된다. 대표적인 비동기 작업의 종류로는 애니메이션 실행, 네트워크 통신, 마우스 키보드 입력, 타이머 등 많다. 다만 자바스크립트 코드 실행 자체는 Web API가 아닌 Call Stack에서 실행된다.

자바스크립트 이벤트 루프 구조 & 동작 원리

자바스크립트 비동기와 이벤트 루프 브라우저의 멀티 스레드로 작업을 동시에 Javascript는 싱글 스레드 언어라고 들어본 적이 있을 것이다. '싱글' 스레드라 한 번에 하나의 작업만 수행이 가능하

inpa.tistory.com

동기와 비동기는 작업 순서 처리 차이

위에서 동기와 비동기를 요청한 작업에 대해 완료 여부에 대한 차이라고 말했었다. 이를 쉽게 말하자면 여러개의 요청 작업을 순차적으로 처리하느냐 아니냐에 따른 차이로 보면 된다. 요청한 작업에 대한 완료 알림을 반드시 받아야 다음 작업을 수행한다는 말은 작업을 순서대로 처리한다는 말이기 때문이다. 따라서 동기 작업은 요청한 작업에 대해 순서가 지켜지는 것을 말하는 것이고, 비동기 작업은 순서가 지켜지지 않을 수 있다는 것을 말한다.

예를들어 A, B, C 라는 3 개의 작업(Task)이 있다고 가정하자. 동기 방식으로 실행하면 A → B → C 순서대로 실행되게 되고, 비동기 방식으로 실행하면 A → C → B 또는 C → A → B 등의 무작위의 순서로 실행되게 되는 것이다.

동기(Synchronous)

비동기(Asynchronous)

정리하자면 작업 3개를 요청했는데 응답에서 그 순서가 지켜진다면 동기이고 어떤 게 먼저 올지 모른다면 비동기라고 보면 된다.

Blocking / Non-Blocking

블로킹과 논블록킹은 단어에서 알 수 있듯이 다른 요청의 작업을 처리하기 위해 현재 작업을 block(차단, 대기) 하냐 안하냐의 유무를 나타내는 프로세스의 실행 방식이다.

동기/비동기가 전체적인 작업에 대한 순차적인 흐름 유무라면, 블로킹/논블로킹은 전체적인 작업의 흐름 자체를 막냐 안 막냐로 볼 수 있는 것이다. 예를 들어, 파일을 읽는 작업이 있을 때, 블로킹 방식으로 읽으면 파일을 다 읽을 때까지 대기하고, 논블로킹 방식으로 읽으면 파일을 다 읽지 않아도 다른 작업을 할 수 있다.

비동기와 논블로킹 개념 차이

아마 새내기 개발자들이 가장 혼동하는 부분이 비동기와 논블로킹의 차이 부분일 것이다. 포스팅 초반에서 자바스크립트의 ~~setTimeout~~ 함수를 비동기 함수이며 동시에 논블로킹 함수이라고 했다. 이는 어떠한 관점으로 ~~setTimeout~~ 을 바라보느냐에 따라 각기 부르는게 달라지기 때문이다. 예를들어 아래 코드는 ~~setTimeout~~ 함수를 사용하여 1초 후에 "Hello, world!"를 출력하는 비동기 논블로킹 코드의 예제이다. 코드를 실행하면, "시작"과 "끝"이 먼저 출력되고, 1초 후에 "1초 후에 실행됩니다!"가 출력되게 된다.

console.log("시작");

setTimeout(() => {
  console.log("1초 후에 실행됩니다!");
}, 1000);

console.log("끝");

즉, 출력 순서와 정의된 코드 라인 순서가 맞지 않은 것이다. 이는 ~~setTimeout~~ 함수에 대해 타이머 작업 완료 여부를 신경 쓰지 않고 바로 그 다음 콘솔 작업을 수행하였기 때문이다. 그리고 ~~setTimeout~~ 함수의 타이머 작업 완료 알람을 콜백 함수를 통해 값을 받아 출력하였다. 따라서 ~~setTimeout~~ 은 비동기(Asynchronouse)이다.

다른 시각으로 보면 메인 함수 작업에 대해서 ~~setTimeout~~ 함수는 자신의 타이머 작업을 수행하기 위해 메인 함수를 블락하지 않고 백그라운드에서 별도로 처리되었다. 메인 함수를 블락하지 않으니 ~~setTimeout~~ 함수를 호출하고 바로 그 다음 콘솔 함수를 호출한 것이다. 따라서 ~~setTimeout~~ 은 논블로킹(Non-blocking)이다.

그런데 결국은 비동기나 논블로킹이나 추구하는 결과로만 보자면 동시에 다른 작업을 수행한다는 점에서 그게 그것이라고 볼 수도 있다. 이는 시점과 관련된 이론적인 개념이라 실제 코드에서 경계를 구분하기가 애매하기도 하다. 그래서 프로그래밍에선 이를 혼용하여 사용하는 것 같다. 그러나 엄연한 나타내는 의미는 다르다.

우리가 동기/비동기, 블로킹/논블로킹을 혼동하는 이유는, 자바스크립트를 처음 배울 때 프로그래밍 서적이나 강의에서 ~~setTimeout~~ 과 같은 함수를 '비동기 함수' 라고 지칭하고 외워버려서 그렇다고 생각한다. 그래서 '비동기' 라고 하면 자연스럽게 병렬 실행을 떠올라 비동기와 논블로킹을 혼동하는 것이다.
비동기는 출력 순서와 관련된 개념이고 논블로킹이 병렬 실행과 관련된 개념이다. 따라서 글쓴이는 개인적으로 이 부분은 잘못되었다고 비판하고 싶다. 아무리 조금 난해한 개념이라도 처음부터 비동기 + 논블로킹 함수라고 가르치는것이 추후를 위해 개념을 다잡는데 옳다고 본다.

비동기 논블로킹과 콜백 함수

자바스크립트 비동기 프로그래밍에서 빠지지 않는 개념이 바로 콜백(callback) 이다. 비동기 논블로킹이란 다른 작업의 결과를 기다리지 않고 병렬적으로 실행되는 방식을 말하는데, 이때 다른 작업의 완료 여부나 결과에 대한 후처리를 위해 이용되는 방식이 콜백 함수이다.

그럼 콜백 함수는 비동기와 관련이 있는 것일까? 논블로킹과 관련이 있는 것일까? 정답은 둘다 관련이 있다. 엄밀히 따지자면 콜백 함수는 비동기 논블로킹을 구현하는 하나의 기술이지 개념이 아니다. 콜백 지옥(callback hell) 때문에 콜백 함수 방식으로 비동기 논블로킹을 구현하기 싫다면 Promise 객체를 이용하여도 되고 아예 이벤트로 emit 하여 처리하여도 된다. 방법은 여러가지이다. 핵심은 비동기 논블로킹을 구현하는 기술은 콜백 외에 여러가지가 있다는 점이고 콜백은 그 중 하나일 뿐이라는 것이지 동기/비동기 & 블로킹/논블로킹 개념과 직접적인 관련은 없다.

/* 콜백 함수 방식으로 구현한 비동기 + 논블로킹 서버 요청 작업 */

$.ajax({
  url: 'https://jsonplaceholder.typicode.com/todos/1', 
  type: 'GET', 
  dataType: 'json', 
  success: function(data) { // 요청이 성공하면 호출될 콜백 함수
    console.log(data); 
  },
  error: function(err) { // 요청이 실패하면 호출될 콜백 함수
    throw err;
  }
});

// 요청을 보내는 동시에 다른 작업을 수행할 수 있습니다.
console.log('Hello');

/* 프로미스 객체 방식으로 구현한 비동기 + 논블로킹 서버 요청 작업 */

fetch('https://jsonplaceholder.typicode.com/todos/1') 
  .then((response) => {
    return response.json(); 
  })
  .then((data) => {
    console.log(data); 
  })
  .catch((err) => {
    throw err; 
  });

// 요청을 보내는 동시에 다른 작업을 수행할 수 있습니다.
console.log('Hello');

/* 이벤트 방식으로 구현한 비동기 + 논블로킹 파일 다운 작업 */

const fileReader = new FileReader(); // FileReader 객체를 생성
const input = document.querySelector('input');
const file = input.files[0]; // input 태그에서 선택된 파일을 가져옵니다

fileReader.addEventListener('load', function() {
	console.log(fileReader.result); // 파일이 load가 완료되면 내용을 출력합니다.
});

fileReader.addEventListener('error', function(err) {
	throw err;
});

// 요청을 보내는 동시에 다른 작업을 수행할 수 있습니다.
console.log('Hello');

누가 제어권을 가지고 있느냐

다른 서적에선 동기/비동기와 블로킹/논블로킹을 보다 명확히 구분하기 위해서 '제어권' 이라는 어려운 단어를 쓴다. 제어권은 간단히 말해서 함수의 코드나 프로세스의 실행 흐름을 제어할 수 있는 권리 같은 것이다. 이 개념은 운영체제(OS)의 커널(kernel)에서 따온 개념으로 I/O 동작에서 설명하는 부분이다. 즉, Blocking과 Non-Blocking은 호출된 함수(callee)가 호출한 함수(caller)에게 제어권을 바로 주느냐 안주느냐로 구분된다. 제어권이 넘어가버리면 해당 스레드는 블로킹되게 된다.

다음은 A 함수와 B 함수 작업에 대해 A 함수가 B 함수를 Blocking 방식으로 호출할시 제어권 상태를 나타낸 그림이다.

Blocking

A 함수가 B 함수를 호출하면 B에게 제어권이 넘어간다
제어권을 넘겨받은 B는 함수를 실행한다.
이때 A는 B에게 제어권을 넘겨주었기 때문에 A 함수 실행을 잠시 멈춘다. (Block)
B 함수가 실행이 끝나면 자신을 호출한 A에게 제어권을 돌려준다.
제어권을 다시 받은 A 함수는 그다음 작업을 실행한다.

다음은 A 함수와 B 함수 작업에 대해 A 함수가 B 함수를 Non-Blocking 방식으로 호출할시 제어권 상태를 나타낸 그림이다.

Non Blocking

A 함수가 B 함수를 호출한다.
호출된 B 함수는 실행되지만, 제어권은 A 함수가 그대로 가지고 있는다.
A 함수는 계속 제어권을 가지고 있기 때문에 B 함수를 호출한 이후에도 자신의 코드를 계속 실행한다.

동기/비동기 + 블로킹/논블로킹 조합

지금까지 동기/비동기 와 블로킹/논블로킹 각각의 차이점에 대해 알아보았다. 이처럼 둘은 유사하지만 엄연히 다른 개념이다. 그래서 프로그램 아키텍쳐에서는 이 두 개념이 함께 조합되어 사용된다. 예를들어 다음 4가지로 조합이 가능하다.

Sync Blocking (동기 + 블로킹)
Async Blocking (비동기 + 블로킹)
Sync Non-Blocking (동기 + 논블로킹)
Async Non-Blocking (비동기 + 논블로킹)

이러한 동기/비동기와 블로킹/논블로킹의 조합은 프로그램이 작동하는 방식에 영향을 미치는 중요한 요소다. 어떠한 요소를 조합하여 사용하느냐에 따라 프로그램의 성능과 효율성을 높일 수 있기 때문이다.

대표적인 예로 Node.js 를 들 수 있다. Node.js에서 비동기 방식으로 파일을 읽거나 네트워크 요청을 보낼 때는 비동기 & 논블로킹 방식을 사용하여 작업이 완료될 때까지 다른 작업을 수행할 수 있도록 한다. 반면에, Node.js에서 코드 실행 시점을 늦춰주거나 순차적인 의존성이 있는 작업을 처리할 때는 동기 & 블로킹 방식을 사용하여 작업의 순서와 타이밍을 제어할 수 있도록 한다.

제로초(조현영)의 node.js 교제

아마 우리는 이미 개념이 적용된 프레임워크를 이용해 편리하게 사용해 왔어서 와닿지 않을 수 있다. 하지만 이러한 이론적인 부분을 이해하고 적용한다면 직접 설계할때 더욱 효율적인 어플리케이션을 개발에 도움이 될 수 있으며, 개념들을 명확히 알고 있으면 Node.js의 동작 원리와 장점을 더 잘 이해하고 활용할 수 있을 것이다. 따라서 동기/비동기와 블로킹/논블로킹의 개념을 이해하고 적절한 조합을 선택하는 것이 중요하다.

Sync Blocking 조합

Sync Blocking 조합은 다른 작업이 진행되는 동안 자신의 작업을 처리하지 않고 (Blocking), 다른 작업의 완료 여부를 바로 받아 순차적으로 처리하는 (Sync) 방식이다. 다른 작업의 결과가 자신의 작업에 영향을 주는 경우에 활용할 수 있다.

실생활 동작 예시

어느 개발팀에서 사원1, 사원2, 사원3 와 팀장이 있다고 하자. 개발팀장은 개발팀 작업의 흐름을 조율하고, 사원들에게 업무를 지시한다고 한다.

팀장 : 사원1씨 업무 A 좀 해주세요
사원1 : 네 알겠습니다. (A를 처리중)
팀장 : (사원1이 A를 다할때까지 아무일도 하지 않고 기다린다)
사원1 : 팀장님 A 업무 완료했습니다.
팀장 : 수고했어요. 사원2씨 업무 B좀 해주세요.
사원2 : 네 알겠습니다. (B를 처리중)
팀장 : (사원2가 B를 다할때까지 아무일도 하지 않고 기다린다)
사원2 : 팀장님 B 업무 완료했습니다.
팀장 : 수고했어요. 사원3씨 업무 C좀 해주세요.
...생략

코드 동작 예시

Sync Blocking 의 대표적인 예로 파일을 읽어 내용을 처리하는 로직을 들 수 있다. 파일을 먼저 읽어야 그다음 작업을 처리할 수 있기 때문이다.

const fs = require('fs'); // 파일 시스템 모듈 불러오기

// 동기적으로 파일 읽기
const data1 = fs.readFileSync('file1.txt', 'utf8'); // file1을 sync으로 read 함
console.log(data1); // 파일 내용 출력하고 적절한 처리를 진행

const data2 = fs.readFileSync('file2.txt', 'utf8'); 
console.log(data2); 

const data3 = fs.readFileSync('file3.txt', 'utf8'); 
console.log(data3);

이러한 Sync Blocking 은 코드가 순차적으로 실행되는 특성을 가지고 있다. 그래서 Sync Blocking 조합은 일반적으로 작업이 간단하거나 작업량이 적은 경우에 사용된다. 작은 데이터를 처리하거나 파일 하나를 읽고 쓰는 경우에는 Sync Blocking 방식이 더 간단하고 직관적일 수 있다. 하지만 작업량이 많거나 시간이 오래 걸리는 작업을 처리해야 하는 경우에는 Sync Blocking 방식을 사용하면 독이 된다. 왜냐하면 작업을 처리하면 작업이 끝날 때까지 다른 작업을 처리하지 못하므로, 전체 처리 시간이 오래 걸리게 되어 비효율적이게 되게 된다. 따라서 이러한 경우에는 바로 뒤에서 다룰 Async Non-Blocking 방식을 사용하여 작업을 처리하는 것이 좋다.

적용 프로그램 예시

대표적으로 C나 JAVA의 코드 실행 후 커맨드에서 입력을 받는 경우가 이에 해당된다. 사용자로부터 입력을 받아야 그 입력값을 가지고 내부 처리를 하여 결과값을 콘솔에 출력해주기 때문에 순차적인 작업이 요구된다. 내부적으로 본다면 실행 코드가 콘솔창을 띄우고 Please enter your name 텍스트를 치고 난 다음 사용자의 리턴값이 필요하기 때문에 제어권을 시스템에서 사용자로 넘겨 사용자가 값을 입력할때까지 기다리는 것이다.

Async Non-Blocking 조합

Async Non Blocking 조합은 다른 작업이 진행되는 동안에도 자신의 작업을 처리하고 (Non Blocking), 다른 작업의 결과를 바로 처리하지 않아 작업 순서가 지켜지지 않는 (Async) 방식이다. 다른 작업의 결과가 자신의 작업에 영향을 주지 않은 경우에 활용할 수 있다.

실생활 동작 예시

팀장 : 사원1씨 A업무좀 해주세요. (동시에 지시)
팀장 : 사원2씨 B업무좀 해주세요. (동시에 지시)
팀장 : 사원3씨 C업무좀 해주세요. (동시에 지시)
팀장 : 다른일을 해야지 ~
사원2 : 팀장인 B 모두 처리했습니다. (업무량에 따라 각 사원마다 완료하는 시간이 제각기 다를 수 있다)
사원1 : 팀장인 A 모두 처리했습니다.
사원3 : 팀장인 C 모두 처리했습니다.

코드 동작 예시

위에서 파일 읽기 코드를 Sync Blocking 방식으로 구현하였는데 이를 그대로 Async Non-Blocking 방식으로도 코드를 구현할 수 있다. Sync Blocking 방식과 두드러진 차이점은 호출 함수에 콜백 함수를 넣었다는 점이다. 이를 통해 비동기 논블로킹 방식대로 처리된 작업의 결과를 후처리 할 수 있게 된다. 그리고 비동기 이기 때문에 작업의 순서를 고려하지 않아 동기 블로킹과는 거꾸로 가장 먼저 'done' 이라는 콘솔 로그가 찍히게 되고 그 후에 파일 내용이 출력될 것이다.

// 비동기적으로 파일 읽기
const fs = require('fs'); // 파일 시스템 모듈 불러오기

fs.readFile('file.txt', 'utf8', (err, data) => { // 파일 읽기 요청과 콜백 함수 전달
  if (err) throw err; // 에러 처리
  console.log(data); // 파일 내용 출력
});

fs.readFile('file2.txt', 'utf8', (err, data) => {
  if (err) throw err; 
  console.log(data);
});

fs.readFile('file3.txt', 'utf8', (err, data) => { 
  if (err) throw err; 
  console.log(data);
});

console.log('done'); // 작업 완료 메시지 출력

~~fs.readFileSync~~ 와 ~~fs.readFile~~ 함수는 둘다 똑같이 파일을 읽는 함수이지만 동기냐 비동기냐에 따라 차이가 있다.
즉, ~~fs.readFileSync~~ 함수는 동기적으로 파일을 읽고 ~~fs.readFile~~ 함수는 비동기적으로 파일을 읽는다.

이처럼 Async Non Blocking 조합은 작업량이 많거나 시간이 오래 걸리는 작업을 처리해야 하는 경우에 적합하다. 예를 들어, 대용량 데이터를 처리하거나 많은 요청을 처리하는 서비스에서는 Async Non Blocking 방식을 사용하여 한 작업이 처리되는 동안 다른 작업을 처리할 수 있으므로 전체 처리 시간을 줄일 수 있어 어플리케이션 처리 성능을 향상시킬 수 있게 된다.

활용 예시 프로그램

비동기 논블로킹을 활용하는 프로그램은 많이 있다. 그중 예를 들자면, 웹 브라우저의 파일 다운로드가 비동기 논블로킹을 활용하는 예시 라고 할 수 있다. 웹 브라우저는 웹 사이트에서 파일을 다운로드할 때, 파일의 전송이 완료될 때까지 다른 작업을 하지 않고 기다리는 것이 아니라, 다른 탭이나 창을 열거나 웹 서핑을 할 수 있다. 이는 웹 브라우저가 파일 다운로드를 비동기적으로 처리하고, 콜백 함수를 통해 다운로드가 완료되면 알려주는 방식으로 구현되어 있기 때문이다.

파일들이 거의 동시에 다운 받음을 Waterfall 그래프에서 시각적으로 확인할 수 있다

Sync Non-Blocking 조합

Sync Non-Blocking 조합은 다른 작업이 진행되는 동안에도 자신의 작업을 처리하고 (Non Blocking), 다른 작업의 결과를 바로 처리하여 작업을 순차대로 수행 하는 (Sync) 방식이다.

실생활 동작 예시

팀장이 업무 A, B, C를 사원 1, 2, 3 에게 시키려고 한다. 그런데 업무 특성상 업무 A를 완료해야 업무 B를 할 수 있고, 업무 B를 완료해야 업무 C를 할 수 있다고 한다.

팀장 : 사원1씨 업무 A 좀 해주세요
사원1 : 네 알겠습니다. (A를 처리중)
팀장 : 다음 업무 B를 하려면 A가 완료되야 하는데.. 사원1씨 다했어요?
사원1 : 아직이요 A 처리중입니다
팀장 : 사원1씨 다했어요?
사원1 : 아직이요 A 처리중입니다
사원1 : 팀장님 A 모두 완료했습니다
팀장 : 수고했어요. 사원2씨 업무 B좀 해주세요.
사원2 : 네 알겠습니다. (B를 처리중)
팀장 : 다음 업무 C를 하려면 B가 완료되야 하는데.. 사원2씨 다했어요?
...생략

코드 동작 예시

동기 + 논블로킹 코드를 표현하는데 적합한 대중적인 언어로 자바(Java)를 들 수있다. 스레드(Thread) 객체를 만들어 요청 작업을 백그라운드에 돌게 하고 메인 메서드에서 while문을 통해 스레드가 모두 처리되었는지 끊임없이 확인하고, 처리가 완료되면 다음 메인 작업을 수행한다.

// Runnable 인터페이스를 구현하는 클래스 정의
class MyTask implements Runnable {
    @Override
    public void run() {
        // 비동기로 실행할 작업
        System.out.println("Hello from a thread!");
    }
}

public class Main {
    public static void main(String[] args) {
        // Thread 객체 생성
        Thread thread = new Thread(new MyTask());

        // 스레드 실행
        thread.start();

        // Non-Blocking이므로 다른 작업 계속 가능
        System.out.println("Main thread is running...");

        // Sync를 위해 스레드의 작업 완료 여부 확인
        while (thread.isAlive()) {
            System.out.println("Waiting for the thread to finish...");
        }
        System.out.println("Thread finished!");
        
        System.out.println("Run the next tasks");
    }
}

분명 스레드를 이용하여 작업을 병렬적으로 처리하도록 지시했지만, 메인 코드의 while문을 수행함으로서 요청한 작업의 완료 여부를 계속 확인하고 결과적으로 결국 동기적으로 작업을 순서대로 수행됨을 볼 수 있다.

자바스크립트(Javascript) 경우에는 동기 + 논블로킹 코드를 구현하기에는 지원하는 메서드에 한계가 있어 완벽히 표현할 수는 없다. 다만 이와 비슷하게 표현할 수 있는 기법이 있는 데 바로 async/await 키워드 이다. 기본적으로 ~~Promise.then~~ 핸들러 방식은 비동기 논블로킹 방식이라 볼 수 있다. 이때 비동기 작업들 간의 순서가 중요하다면 ~~await~~ 키워드를 통해 동기적으로 처리해 줄 수 있다.

예를 들어 Node.js에서 여러개의 파일을 읽어서 내용을 비교하는 작업을 한다고 가정해보자. 이를 Sync Non-Blocking 방식으로 작성한다면, 세 파일을 동시에 읽기 시작하고 (Non Blocking), 두 파일의 읽기가 모두 완료되면 내용을 비교하는 후처리를 진행한다 (Sync).

const fs = require('fs'); 
const { promisify } = require('util'); // 유틸리티 모듈 불러오기
const readFileAsync = promisify(fs.readFile); // fs.readFile 함수를 Promise 객체를 반환하는 함수로 변환

async function readFiles() {
  try {
    // Promise.all() 메소드를 사용하여 여러 개의 비동기 작업을 병렬로 처리합니다. (비동기 논블로킹)
    const [data1, data2, data3] = await Promise.all([
      readFileAsync('file.txt', 'utf8'), // file.txt 파일을 읽습니다.
      readFileAsync('file2.txt', 'utf8'), // file2.txt 파일을 읽습니다.
      readFileAsync('file3.txt', 'utf8') // file3.txt 파일을 읽습니다.
    ]);

    // 파일 읽기가 완료되면 data에 파일 내용이 들어옵니다.
    console.log(data1); // file.txt 파일 내용을 출력합니다.
    console.log(data2); // file2.txt 파일 내용을 출력합니다.
    console.log(data3); // file3.txt 파일 내용을 출력합니다.

    // 파일 비교 로직 실행...

  } catch (err) {
    throw err;
  }
}

readFiles(); // async 함수를 호출

async/await은 비동기 논블로킹 방식을 동기 논블로킹 방식으로 바꿔주는 기법이라고 할 수 있지만, 그러나 async/await은 내부적으로는 여전히 비동기 논블로킹 방식으로 동작한다는 점은 유의하자. async 함수 자체가 메인 콜 스택(call stack)이 모두 실행되어 비워져야 수행하기 때문에 비동기 논블로킹이기 때문이다.

활용 예시 프로그램

동기 논블로킹은 흔하지 않는 케이스이지만 그래도 이를 표현할 수 있는 프로그램이 있다. 게임에서 맵을 이동할때를 생각해보자. 우선 맵 데이터를 모두 다운로드 해야 할 것이다. 그동안 화면에는 로딩 스크린이 뜬다. 이 로딩 스크린은 로딩바가 채워지는 프로그램이 수행하고 있는 것이다. 즉, 제어권은 여전히 나한테 있어 화면에 로드율이 표시되는 것이다. 그리고 끊임없이 맵 데이터가 어느정도 로드가 됬는지 끊임없이 조회한다. 자신의 작업을 계속하고 있지만 다른 작업과의 동기를 위해 계속해서 다른 작업이 끝났는지 조회하는 것이다.

Sync Blocking vs Sync Non-Blocking

그런데 가만히 보면 블로킹이든 논블로킹이든 메인 함수에서 결국은 코드를 순차적으로 수행하기 때문에 전체 작업의 최종 걸린 시간은 둘이 차이가 없어 보인다. 그럼 두 방식은 도긴개긴인 것인가?

성능 차이는 상황에 따라 다르겠지만, 일반적으로 동기 + 논블로킹이 동기 + 블로킹보다 효율적일 수 있다. 왜냐하면 동기 + 논블로킹은 호출하는 함수가 제어권을 가지고 있어서 다른 작업을 병렬적으로 수행할 수 있기 때문이다. 반면에 동기 + 블로킹은 호출하는 함수가 제어권을 잃어서 다른 작업을 수행할 수 없기 때문입니다

게임 로딩 화면과 더불어 동기 + 논블로킹의 또다른 예제로는 브라우저에서 파일을 다운로드하면 나타나는 다운로드 진행바를 들 수 가 있다.

웹브라우저에서 파일을 다운로드 할 경우 작업은 웹브라우저의 Web APIs 으로 작업을 백그라운드로 넘기고 '제어권'을 바로 반환받아 다른 작업을 수행할 수 있다. 이것이 Non Blocking 이다.

그런데 웹브라우저는 파일 다운로드 작업의 완료 여부에 관심이 있다. 즉, 다운로드 작업이 언제 끝나고 얼마나 진행되었는지 파일 다운로드 로드율을 브라우저 하단바에 표시해준다. 그리고 파일이 모두 다운로드 완료되면 사용자가 원하는 최종 작업인 파일 다운로드 작업을 수행하게 된다. 이것이 Synchronous 이다.

이때 우리는 파일을 다운로드 하면서 웹서핑을 하거나 유튜브 음악을 들을 수 있다. 제어권을 가지고 있기 때문에 브라우저가 멀티 태스킹을 하도록 적절히 코드를 구현하였기 때문에 가능한 것이다. 따라서 동기 + 논블로킹 방식은 일반적인 동기 + 블로킹 방식보다 구현에 따라 더 효율적으로 작업을 처리 할 수 있다고 볼 수 있다. (자바스크립트의 async/await 으로 상상하면 오히려 이해가 안될수가 있다. 자바의 스레드 객체로 상상하자)

Async Blocking 조합

Async Blocking 조합은 다른 작업이 진행되는 동안 자신의 작업을 멈추고 기다리는 (Blocking), 다른 작업의 결과를 바로 처리하지 않아 순서대로 작업을 수행하지 않는 (Async) 방식이다. Async-blocking 의 경우는 실무에서 잘 마주하기 쉽지 않아 다룰일이 거의 없다. 그래서 그냥 넘어가도 크게 문제는 없다.

Async Blocking vs Sync Blocking

위 사진만 보더라도 위의 Sync-blocking 수행 그림과 큰 차이가 없어 보인다. 실제로 독자분이 느낀 그대로 개념적으로 차이가 있을 뿐이지 정말로 성능적으로 차이가 없다.

보통 Async-blocking은 개발자가 비동기 논블록킹으로 처리 하려다가 실수하는 경우에 발생하거나, 자기도 모르게 블로킹 작업을 실행하는 의도치 않은 경우에 사용된다. 그래서 이 방식을 안티 패턴(anti-pattern)이라고 치부하기도 한다.

활용 예시 프로그램

다만 Async Blocking 이 실제로 적용된 실무 사례가 있긴 하다. Node.js + MySQL의 조합이 대표적인데, Node.js에서 비동기 방식으로 데이터베이스에 접근하기 때문에 Async 이지만, MySQL 데이터베이스에 접근하기 위한 MySQL 드라이버가 블로킹 방식으로 작동되기 때문이다.

JavaScript는 비동기 방식으로 MySQL에 쿼리를 보낸다. (Async)
MySQL은 쿼리를 처리하면서 JavaScript에게 제어권을 넘겨주지 않는다. (Blocking)
그러면 JavaScript는 다른 작업을 계속 수행할 수 있지만, MySQL의 결과값을 필요로 하기 때문에 MySQL이 쿼리를 완료할 때까지 기다려야 된다.
결국 Sync Blocking과 작업 수행에 차이가 없게 된다.

이렇게 JavaScript와 MySQL의 조합은 비동기적이면서도 블로킹되는 Async Blocking 조합이라고 할 수 있다. 이러한 오묘한 조합은 오히려 개발자에게 혼동만 일으키기 때문에 그래서 실무에서는 Node.js 서버 프로그래밍할때 아예 async/await로 동기 처리를 하는 편이다.

const mysql = require('mysql');

// connectDB 함수를 정의
async function connectDB () {
  // DB 연결 정보를 담은 객체 생성
  let connectionInfo = {
    host: 'localhost', // DB 호스트 주소
    user: 'root', // DB 유저 이름
    password: '1234', // DB 비밀번호
    database: 'spyncdb' // DB 이름
  };
  
  // connection 객체를 생성하고 반환
  let connection = mysql.createConnection(connectionInfo);
  return connection;
}

// mysql 라이브러리를 사용하는 경우
async function userHandler (username, displayName, profilePicture, email) {
  // DB에 연결
  connection = await connectDB() 
  
  // DB를 선택
  await connection.query ('USE spyncdb;'); 
  
  // 쿼리를 실행하고 결과를 받음
  let result = await connection.query ('SELECT * FROM users WHERE username = ?', [username]); 
}

// userHandler 함수를 호출하고 user_id 값을 얻으려고 함
let user_id = await userHandler (aUser.username, aUser.displayName, aUser.profilePicture, aUser.email); // userHandler 함수가 비동기 작업을 완료할 때까지 기다림
console.log (user_id); // user_id 출력

# 참고자료

https://medium.com/from-the-scratch/wtf-is-synchronous-and-asynchronous-1a75afd039df

https://notes.arkalim.org/notes/programming/asynchronous%20programming/

https://www.youtube.com/watch?v=oEIoqGd-Sns

https://joooing.tistory.com/entry/%EB%8F%99%EA%B8%B0%EB%B9%84%EB%8F%99%EA%B8%B0-%EB%B8%94%EB%A1%9C%ED%82%B9%EB%85%BC%EB%B8%94%EB%A1%9C%ED%82%B9

https://velog.io/@ellyheetov/Asynchoronous-VS-Synchoronous-1

https://velog.io/@nittre/%EB%B8%94%EB%A1%9C%ED%82%B9-Vs.-%EB%85%BC%EB%B8%94%EB%A1%9C%ED%82%B9-%EB%8F%99%EA%B8%B0-Vs.-%EB%B9%84%EB%8F%99%EA%B8%B0

https://ttl-blog.tistory.com/782

자바스크립트의 핵심 '비동기' 완벽 이해 ❗

인파_ — Mon, 1 May 2023 08:58:48 +0900

자바스크립트의 동기와 비동기

자바스크립트는 싱글 스레드 언어이기 때문에 한 번에 하나의 작업만 수행할 수 있다. 즉, 이전 작업이 완료되어야 다음 작업을 수행할 수 있게 된다. 우리가 프로그래밍을 하면서 일반적으로 각 함수와 코드들이 위에서 아래로 차례로 동작하는 방식이라고 할 수 있다. 이러한 코드 순차 실행을 동기(Synchronous) 라고 부른다.

그런데 동기 방식은 간단하고 직관적이지만, 작업이 오래 걸리거나 응답이 늦어지는 경우에는 전체적인 성능과 사용자 경험에 영향을 줄 수 있다. 예를 들어 서버에 데이터를 요청하고 응답을 받아야 하는 작업이 있다면, 응답이 올 때까지 다른 작업을 하지 못하고 대기해야 한다. 이렇게 되면 프로그램의 흐름이 멈추거나 지연되게 된다.

따라서 자바스크립트로 여러 작업을 동시에 처리하기 위해 비동기(Asynchronous) 라는 개념을 도입하여, 특정 작업의 완료를 기다리지 않고 다른 작업을 동시에 수행할 수 있도록 하였다. 자바스크립트를 배우다 보면 ~~setTimeout()~~ 함수나 ~~fetch()~~ 함수를 접해볼 것이고, 이들은 비동기로 동작한다는 소리를 한번 쯤은 들어본 적이 있을 것이다. 비동기는 메인 스레드가 작업을 다른 곳에 인가하여 처리되게 하고, 그 작업이 완료되면 콜백 함수를 받아 실행하는 방식으로, 쉽게 말해 작업을 백그라운드에 요청하여 처리되게 하여 멀티로 작업을 동시에 처리하는 것으로 보면 된다.

서버에 데이터를 요청하고 응답을 받아야 하는 작업이 있다면, 응답이 오는 것과 상관없이 다른 작업을 계속 이어나가 병렬로 작업을 동시 처리가 가능해져 프로그램의 흐름이 멈추거나 지연되지 않게 된다. 따라서 Task들이 병렬적으로 동시에 처리되게 되고 총 코드 실행 시간은 획기적으로 줄어들게 된다.

자바스크립트의 비동기 특징

비동기 처리의 유용성

예를 들어 웹 애플리케이션에서 데이터베이스 쿼리를 수행하는 작업이 있다고 가정해보자. 이 작업을 만일 동기적으로 수행하면, 데이터베이스에서 응답이 올 때까지 기다려야 한다. 그러면 이 때 웹 애플리케이션은 다른 요청을 처리하지 못하므로, 대규모 트래픽이 발생할 경우 웹 애플리케이션의 성능이 저하될 수 있다.

하지만 비동기 방식으로 데이터베이스 쿼리를 수행하면, 데이터베이스에서 응답이 올 때까지 기다리는 동안에도 다른 요청을 처리할 수 있게 된다. 결과가 주어지는데 시간이 걸리더라도 그 시간 동안 다른 작업을 할 수 있으므로 자원을 효율적으로 사용할 수 있는 것이다. 이렇게 비동기 방식을 사용하면, 대규모 트래픽에서도 안정적으로 동작할 수 있는 웹 애플리케이션을 만들 수 있다.

대표적으로 웹에서 비동기 처리를 가능하게 하는 Ajax 기술이 있다. 다른 서버에게 데이터를 요청할때 ~~XMLHttpRequest~~ 객체나 혹은 ~~fetch~~ 메서드로 요청을하게 하는데, 서버로부터 응답을 기다리는 동안에도 사용자와의 인터랙션을 유지할 수 있으므로 사용자 경험을 향상시킬 수 있게 된다.

// fetch 함수에 URL 전달
fetch("https://jsonplaceholder.typicode.com/todos/1")
  .then(function(response) {
    return response.json(); // 응답을 JSON 형식으로 변환
  })
  .then(function(data) {
    console.log(data); // JSON 데이터를 출력
  })
  .catch(function(error) {
    console.error(error); // 에러를 출력
  });

비동기의 병렬 처리 원리

아마 자바스크립트 개발자라면 필수로 익히는 것이 호출 스택과 이벤트 루프 일 것이다. 그리고 아래와 같은 그림을 눈빠지게 봐왔을 것이다. 비동기 함수의 콜백 함수가 이벤트 루프에 의해서 Callback Queue에 담기고 다시 싱글 스레드인 Call Stack에 담겨서 콜백 함수가 실행되는 동작 원리 까지는 아마 대부분의 강의에서 접해보고 넘어갔을 것이다.

그런데 자바스크립트는 싱글 스레드 언어라고 했는데 어떻게 작업(task)들을 동시에 처리가 가능하는 것일까?

이에 대해 정확히 설명하지 못하는 독자분들은, 아마 다른 곳에서 자바스크립트 이벤트 루프와 호출 스택 과정을 학습하는데 있어 높은 확률로 Call Stack 우측에 있는 Web APIs 에 대해서 대충 보고 넘어갔을 것이다. 왜냐하면 자바스크립트를 실행하는 콜 스택(Call Stack)은 싱글 스레드지만, 서버에게 리소스를 요청하거나 파일 입출력 혹은 타이머 대기 작업을 실행하는 Web APIs 들은 멀티 스레드이기 때문에 동시 작업 처리가 가능하기 때문이다. (멀티 스레드를 잘 모른다면 백그라운드에서 동시에 처리된다고 이해하면 된다)

Web API는 타이머, 네트워크 요청, 파일 입출력, 이벤트 처리 등 브라우저에서 제공하는 다양한 API를 포괄하는 API의 총칭이다. 브라우저마다 다르겠지만, 크롬 브라우저 일 경우 Web API는 멀티 스레드로 구현되어 있다.

즉, 브라우저라는 소프트웨어가 멀티 스레드 이기 때문에 메인 자바스크립트 스레드를 차단하지 않고 다른 스레드를 사용하여 Web API의 작업을 처리하여 동시 처리가 가능한 것이다.

만일 아래와 같이 3초를 대기하는 setTimeout 비동기 함수와 그외 작업(Task)들이 있다고 한다면, 이 setTimeout 코드가 Web APIs 들 중 타이머 처리를 담당하는 Timer API에 넘어가서 3000ms 밀리초를 병렬로 처리되면서, 동시에 메인 콜 스택의 Task1, Task2 ... 를 처리하는 것이다.

setTimeout(() => {
	console.log('5초 대기 완료')
}, 3000);

Task1();
Task2();
Task3();

각 싱글 스레드가 동시에 처리하니 멀티 스레드이다

정리하자면 브라우저는 멀티스레드로 이루어져 있고 비동기 함수는 이러한 동시적 처리 작업 원리 덕분에 우리는 비동기 함수를 통해 성능 향상을 누릴 수 있었던 것이었다.

자바스크립트 이벤트 루프 구조 & 동작 원리

inpa.tistory.com

왜 완벽한 멀티 스레딩이 아닌가

setTimeout을 이용해 비동기의 멀티 작업 처리를 설명했지만, 사실 자바스크립트의 비동기는 완벽한 멀티 스레딩이 아니다. 왜냐하면 타이머 3000ms 만 병렬적으로 처리되고, 그 안의 콜백 함수 실행 코드는 추후에 이벤트 루프에 인해 콜 스택(Call Stack)에 들어가 싱글 스레드로 처리되기 때문이다.

setTimeout 뿐만 아니라 fetch 비동기 함수도 마찬가지이다. 서버에 요청해서 리소스를 다운로드 하는 것은 멀티 스레드로 병렬적으로 처리되지만, 요청이 완료되고 나서의 후처리 then 핸들러의 콜백 함수는 콜 스택에 별도로 처리된다.

병렬로 동시 처리할꺼면 전체를 완전히 처리할 것이지 왜 이런식으로 번거롭게 나눈 것일까?

아마 자바의 멀티 스레드(Thread) 프로그래밍을 해보신 독자분들은 이에 대한 이유를 알고 있을 것이다. 완전한 병렬 처리는 성능 만큼은 이득을 얻을수 있을지도 모르겠지만, 항상 동시성 문제가 따라와 synchronized 처리가 수반된다는 사실 말이다. 자바스크립트 비동기만 배우신 분들은 이에 대해 잘 와닿지 않을 수 있지만, 이 synchronized 처리를 잘못하면 오히려 성능 감소가 일어나기 때문에 고난이도의 지식과 실력을 요구한다. 따라서 자바스크립트에서는 동시성 문제에 대해 심플하게 처리하기 위해 비동기 콜백 함수 방식을 채택하였다고 보면 된다. 이밖에 자바스크립트 언어를 설계할 과거 당시에는 멀티 프로세서 컴퓨터는 보편적이지 않았을 뿐더러 자바스크립트가 처리할 코드 양도 적었기 때문이라는 이유도 있다.

자바스크립트도 멀티 스레딩을 사용하고 싶어

그럼 자바스크립트는 영원히 멀티 스레딩을 구현 못하는 것일까? 그래서 나온 것이 바로 웹 워커(web workers)이다. 웹 워커를 이용하면 자바스크립트도 자바의 스레드와 같이 멀티 스레드 프로그래밍을 할 수가 있다.

// 웹 워커 스크립트 파일(worker.js)
self.addEventListener('message', function(e) {
  // 메인 스크립트로부터 메시지를 받으면 실행할 함수
  var result = "Hello " + e.data;
  self.postMessage(result); // 결과를 메인 스크립트로 전송
}, false);

// 메인 스크립트에서 웹 워커 사용 예시
var worker = new Worker('./worker.js'); // 웹 워커 객체 생성

worker.addEventListener('message', function(e) {
  // 웹 워커로부터 메시지를 받으면 실행할 함수
  console.log(e.data); // 결과 출력
}, false);

worker.postMessage('World'); // 웹 워커에게 메시지 전송

Node.js에서도 Worker_Threads 모듈로 멀티 스레드를 구현할 수 있다.

브라우저의 비동기 처리

이러한 비동기 원리는 꼭 자바스크립트 언어 뿐만 아니라 브라우저의 HTML 마크업 언어에서도 동일하게 적용된다. HTML 의 파싱 동작 방식을 예로 들 수 있는데, 아래와 같이 다음과 같이 ~~<script>~~ 태그를 HTML 파일의 ~~<head>~~ 태그 안에 넣으면, 자바스크립트 파일이 다운로드되고 실행될 때까지 HTML 파싱이 중단되게 된다. 이는 사용자가 웹 페이지의 내용을 보는데 오래 기다려야 하게 된다.

<!DOCTYPE html>
<html>
<head>
  <script src="script1.js"></script>
  <script src="script2.js"></script>
  <script src="script3.js"></script>
</head>
<body>
  <h1>웹 페이지 제목</h1>
  <p>웹 페이지 내용</p>
</body>
</html>

Synchronous

자바스크립트에 비동기 함수가 있다면 html에도 비동기를 이용할 수 있는 기술이 있다. 바로 ~~<script>~~ 태그에 붙이는 ~~async~~ 과 ~~defer~~ 키워드 이다. async와 defer 속성은 자바스크립트 파일을 비동기적으로 다운로드하고 실행할 수 있게 해준다. 이렇게 하면 HTML 파싱과 자바스크립트 다운로드가 동시에 진행되어 페이지 로딩 속도를 향상시킬 수 있게 된다.

<!DOCTYPE html>
<html>
<head>
  <script async src="script1.js"></script>
  <script async src="script2.js"></script>
  <script async src="script3.js"></script>
</head>
<body>
  <h1>웹 페이지 제목</h1>
  <p>웹 페이지 내용</p>
</body>
</html>

Asynchronous

그림을 비교하면 똑같은 작업을 처리하는데 있어 Asynchronous가 총 걸린 Time이 더 적은걸 볼 수 있다.

이 역시 위에서 배운 자바스크립트와 Web APIs 원리와 같이, 파일 다운로드 동작 자체를 비동기로 브라우저 내부의 멀티 스레드에 양도하고 계속 html 파싱을 이어나가면서 동시에 파일을 다운받는 원리이다.

HTML의 비동기는 자바스크립트의 콜 스택과 이벤트 루프 동작과는 별개로 브라우저 내부 구현에 의존하는 것이다.

웹 어플리케이션을 이용하는 사용자들은 빠른 서비스를 원하지, 불러오는 속도가 느리고 반응이 없는 것을 원하지 않기 때문에 비동기적으로 페이지를 구성하는 것은 필수 스킬이라 볼 수 있다.

비동기 처리의 문제점

다만 성능 향상을 위해 비동기 처리를 이용할때 주의해야 할 점이 있다. Asynchronous는 요청한 작업의 완료 여부를 기다리지 않고 자신의 그다음 작업을 계속 수행해 나간다고 했다. 그런데 만일 그다음 실행할 작업이 이전에 요청한 작업의 결과가 반드시 필요할 경우 문제가 생긴다.

쉽게 예를 들어보면 아래의 html의 스크립트 코드는 에러를 일으키게 된다. 왜냐하면 ~~$('body').appned()~~ 코드는 제이쿼리 전용 코드로서 제이쿼리 라이브러리 파일이 다운을 모두 받은 상태여야만 사용할 수 있기 때문이다. 하지만 제이쿼리 소스파일 호출을 비동기적으로 진행해 소스파일이 다운로드 되기도 전에 제이쿼리 코드를 사용했으니 에러가 일어나는게 당연한 것이다. (만일 소스파일 다운을 엄청 빨리한다면 에러가 일어나지 않을 수 있다)

<script async src='https://code.jquery.com/jquery-3.6.0.min.js'></script>
<script>
	// 제이쿼리 파일을 비동기적으로 호출하고 바로 제이쿼리 전용 코드를 실행 시켰기 때문에 에러가 발생하다
    $('body').append('<h1>Hello World</h1>'); // ! ERROR
</script>

이밖에도 서버로부터 데이터를 받을때 비동기 함수의 결과가 동기적으로 실행되는 코드에 영향을 줄 때도 문제가 된다.

예를 들어 다음 코드는 서버의 데이터베이스를 조회하여 데이터를 가져오는 로직을 간단하게 표현한 예제이다. ~~getDB()~~ 함수를 통해 데이터베이스를 조회하는데, 이때 조회 시간이 3초 걸린다고 가정하자. 그리고 DB로부터 응답을 받게 되면 ~~data~~ 변수에 저장하고 값을 두배 곱셈 연산 후 출력하려고 한다.

function getDB() {
    let data;
    // 데이터베이스에서 값을 가져오는 3초 걸린다고 가정 (비동기 처리)
    setTimeout(() => {
        data = 100;
    }, 3000);

    return data;
}

function main() {
    let value = getDB();
    value *= 2;
    console.log('value의 값 : ', value);
}
main(); // 메인 스레드 실행

하지만 결과를 확인해 보니 ~~data~~ 변수에 NaN이라는 이상한 값이 들어가 있다. 왜 이런 결과가 나왔을까? 그 이유는 비동기 함수인 setTimeout 함수가 3초 동안 대기하는 동안 완료될 때까지 기다리지 않고 다음 코드인 ~~console.log(data)~~를 실행하 였기 때문이다. 이때 ~~data~~ 변수에는 아직 데이터가 저장되지 않았으므로 여기에 연산을 하니 이상한 값이 출력되는 것이다.

그렇다면 위와 같이 작업의 순서를 맞추는 것이 필수 불가결일 경우 어쩔수 없이 비동기를 포기하고 동기로 처리해야 되나 싶지만, 이를 해결하는 몇가지 기법이 있다. 가장 대표적인 것이 콜백 함수 기법이다.

비동기를 알맞게 처리하기 위한 기법

비동기와 콜백 함수

흔히 비동기를 다룰때 자주 엮여 등장하는 개념이 콜백(callback) 함수이다. 콜백 함수는 자바스크립트의 일급 객체 특성을 이용해 함수의 매개변수에 함수 자체를 넘겨, 함수 내에서 매개변수 함수를 실행하는 기법을 말한다.

비동기 방식은 요청과 응답의 순서를 보장하지 않는다. 따라서 응답의 처리 결과에 의존하는 경우에는 콜백 함수를 이용하여 작업 순서를 간접적으로 끼워 맞출 수 있다. 콜백 함수 방식으로 위의 문제 코드를 수정하면 다음과 같게 된다.

function getDB(callback) {
    // 데이터베이스로부터 3초 후에 데이터 값을 받아온 후, 콜백 함수 호출
    setTimeout(() => {
        const value = 100;
        callback(value);
    }, 3000);
}

function main() {
    // 호출할 작업에 콜백 함수를 넘긴다
    getDB(function(value) {
        let data = value * 2;
        console.log('data의 값 : ', data);
    });
}
main();

위 코드는 콜백 함수 내에서 ~~data~~ 변수의 값을 받아 출력하므로, 비동기 작업이 완료된 후에 출력되게 된다. 즉, 콜백 함수는 비동기 함수에서 작업 결과를 전달받아 처리하는데 사용되어 작업 순서를 맞출수 있게 되는 것이다. 따라서 비동기 함수와 콜백 함수는 서로 밀접한 관계를 가지고 있다고 말하는 것이다.

다만 너무 복잡하게 얽힌 비동기 처리 때문에 콜백 함수 방식은 코드 복잡도를 증가시켜, 개발자가 어플리케이션의 흐름을 읽기 어려워지는 등의 문제가 있을 수 있어 잘못하면 콜백 지옥(callback hell) 에 빠질수 있다는 단점이 있다. 조금 억지스러운 코드지만 정말로 콜백 함수들을 복잡하게 중첩하여 구성한다면 아래와 같은 '아됴겐'에 맞아 허리가 구부러진 우스꽝 스러운 코드 모양이 되게 된다.

비동기와 프로미스 객체

콜백 함수는 엄연히 말하자면 비동기를 순차적으로 처리하기 위한 일종의 '편법' 같은 것이지 정식으로 지원하는 비동기 전용 함수가 아니다. 따라서 자바스크립트의 Promise 객체는 이러한 한계점을 극복하기 위해 비동기 처리를 위한 전용 객체로서 탄생하였다. Promise는 비동기 작업의 성공 또는 실패와 그 결과값을 나타내는 객체이다. 그래서 Promise를 사용하면 비동기 작업을 쉽고 깔끔하게 연결할 수 있게 된다.

function getDB() {
  return new Promise((resolve) => {
    setTimeout(() => {
      const value = 100;
      resolve(value);
    }, 3000);
  });
}

function main() {
  getDB()
    .then((value) => {
      let data = value * 2;
      console.log('data의 값 : ', data);
    })
    .catch((error) => {
      console.error(error);
    });
}

main();

자바스크립트 Promise 개념 & 문법 정복하기

콜백 지옥을 탈출하는 새로운 문법 자바스크립트에서 '비동기 처리' 란 현재 실행중인 작업과는 별도로 다른 작업을 수행하는 것을 말한다. 예를 들어 서버에서 데이터를 받아오는 작업은 시간

inpa.tistory.com

비동기와 async / await

하지만 프로미스도 완벽한 해결책은 아니다. 왜냐하면 Callback Hell이 있듯이 지나친 then 핸들러 함수의 남용으로 인한 Promise Hell이 존재하기 때문이다. 즉, 프로미스가 여러 개 연결되면 코드가 길어지고 복잡해질 수 있다는 것이다. 그래서 자바스크립트에는 async/await라는 문법이 또한 추가되었다. async/await는 프로미스를 기반으로 하지만, 마치 동기 코드처럼 작성할 수 있게 해준다. 비동기 작업을 쉽게 읽고 이해할 수 있게 해주기 때문에 비동기 작업을 처리할 일이 있다면 대게 async/await 방식을 쓰는 것이 보통이다.

자바스크립트에서 Promise나 async/await와 같은 문법을 사용하는 이유도 이런 비동기 처리의 흐름을 좀 더 명확하게 인지하고자 하는 노력인 것이다.

function getDB() {
    return new Promise((resolve, reject) => {
        // 데이터베이스에서 값을 가져오는 3초 걸린다고 가정 (비동기 처리)
        setTimeout(() => {
            const value = 100;
            resolve(value); // Promise 객체 반환
        }, 3000);
    });
}

async function main() {
    let data = await getDB(); // await 키워드로 Promise가 완료될 때까지 기다린다
    data *= 2;
    console.log('data의 값 : ', data);
}
main(); // 메인 스레드 실행

자바스크립트 Async/Await 개념 & 문법 정복

자바스크립트 비동기 처리 3가지 방식 자바스크립트는 싱글 스레드 프로그래밍 언어기 때문에 멀티 작업을 하기 위해선 비동기 처리 방식이 자주 쓰인다. 비동기 처리는 백그라운드로 동작되기

inpa.tistory.com

그럼 무조건 await가 답인가?

이렇게 보면 async/await이 비동기를 처리함에 있어 callback이나 Promise 방식보다 훨씬 좋아 보이지만, 사용 방법에 따라서는 코드가 복잡해질 수도 있다. 따라서 이 비동기 처리에 대한 3가지 방식은 용도에 맞춰서 적절히 사용해야 한다.

왜냐하면 callback 방식은 별 다른 키워드 없이도 정말 단순하게 구현할 수 있는 문법이기 때문에, 콜백 지옥을 맞이할 정도의 복잡한 상황이 아닐 때면 오히려 사용하면 가독성이 좋다. 대표적인 예로 Node.js의 Express 프레임워크는 서버 라우팅을 콜백 함수로 처리하는 방식을 제공한다.

const express = require("express"); // Express 모듈 불러오기
const app = express(); // Express 앱 객체 생성

// /home url 경로에 GET 요청이 들어오면 이에 대한 라우팅 정의
app.get("/home", function (req, res) {
  // 응답 보내기
  res.send("Hello, Express!");
});

따라서, 콜백 함수는 복잡하기 않고 비교적 심플한 비동기 작업을 처리해야 할 때 사용하면 오히려 프로미스 방식보다 더 좋을 수 있다. 반면에 비교적 복잡한 비동기 작업을 처리할 때는 Promise 객체를 사용하면 코드를 보다 간결하게 작성할 수 있다.

# 참고자료

https://velog.io/@nittre/%EB%B8%94%EB%A1%9C%ED%82%B9-Vs.-%EB%85%BC%EB%B8%94%EB%A1%9C%ED%82%B9-%EB%8F%99%EA%B8%B0-Vs.-%EB%B9%84%EB%8F%99%EA%B8%B0

https://dev.to/lydiahallie/javascript-visualized-event-loop-3dif

https://medium.com/sjk5766/javascript-%EB%B9%84%EB%8F%99%EA%B8%B0-%ED%95%B5%EC%8B%AC-event-loop-%EC%A0%95%EB%A6%AC-422eb29231a8

PurgeCSS 사용법 - CSS 프레임워크 코드 최적화

인파_ — Sat, 22 Apr 2023 11:55:05 +0900

CSS 프레임워크의 문제점

웹 어플리케이션을 구축할때 서비스 품질과 성능도 중요하지만, 빠지지 않는 것이 웹디자인이다. 웹디자인은 사용자의 첫인상과 만족도에 큰 영향을 미치기 때문에 신경써야 한다. 하지만 웹디자인을 처음부터 만드는 것은 쉽지 않다. 복잡한 CSS 코드를 작성하고 반응형으로 만들고 호환성을 확인하는 과정은 많은 시간과 노력이 필요하기 때문이다.

그래서 많은 웹 개발자들은 Bootstrap, Foundation, Bulma, Pure.css, UIKit, Materialise, Tailwind와 같은 CSS 프레임워크를 사용한다. CSS 프레임워크는 미리 정의된 CSS 클래스와 구성 요소를 제공하여, 일관되고 표준화된 방식으로 쉽고 빠르게 고퀄리티의 웹디자인을 만들 수 있으며, 재사용하고 유지 관리에도 용이하다.

그런데 이러한 CSS 프레임워크에는 치명적인 단점이 존재한다. 온갖 디자인 요소들을 css 클래스로 미리 정의하여 파일로 제공하기 때문에, 현재 내 서비스에 사용하지도 않은 css 코드가 있어도 불필요한 CSS 코드가 로딩되어 웹 페이지의 로딩 속도를 저하하기 때문이다. 디자인도 디자인이지만 만일 웹 페에지 속도가 느리면 소비자들은 망설임없이 뒤로 가기를 해버리기 때문에 서비스에 치명적이게 된다. 거기다 CSS 파일을 비동기로 로드하면 레이아웃이 꺠져 SEO에도 점수가 깎이기 때문에 우회적인 최적화 방법은 전무하다고 볼 수 있다.

따라서 사용하지 않은 CSS 클래스 코드를 제거하는 것이 유일한 방법인데, 이러한 작업을 개발자가 일일히 대조하며 할 수도 없는 노릇이다.

그래서인지 Tailwind CSS 프레임워크에서는 자체로 CSS Tree Shaking 기능을 제공하여, 불필요한 CSS 코드를 자동으로 제거하여 웹 페이지의 로딩 속도를 개선해준다. Tailwind는 프로덕션(Production) 빌드 시 사용하지 않는 CSS 코드를 자동으로 찾아 제거하므로 최종 CSS 번들은 필요한 코드만 있는 작은 용량의 파일이 되게 된다.

웹페이지에 현재 사용하고 있는 css 클래스만 빌드한다

그럼 Tailwind를 제외한 부트스트랩과 같은 나머지 CSS 프레임워크는 이러한 최적화 기능을 제공하지 않아 고려대상에서 제외 되어야 하는 것일까?

PurgeCSS

Getting Started | PurgeCSS

Getting Started Most bundlers and frameworks to build websites are using PostCSS. The easiest way to configure PurgeCSS is with its PostCSS plugin. Install the PostCSS plugin: npm i -D @fullhuman/postcss-purgecss yarn add @fullhuman/postcss-purgecss --dev

purgecss.com

PurgeCSS는 HTML, JS 등의 파일에서 사용된 CSS 선택자와 일치하는지 확인하고, CSS 파일에서 사용하지 않는 선택자를 제거하여 파일 크기를 줄이고 성능을 향상시키는 자바스크립트 라이브러리이다. 사실 Tailwind도 자체적으로 PurgeCSS를 내장하고 있어 CSS 트리 쉐이킹이 가능한 것이다. 부트스트랩 공식 홈페이지에 가봐도 Unused CSS에 대한 최적화로 PurgeCSS를 안내하고 있는 걸 볼 수 있다.

또한 다양한 웹 플러그인과 함께 쓰일수 있으니, 확장성도 좋다고 볼 수 있다

PurgeCSS CLI 사용법

이 포스팅에서는 아주 기초적인 커맨드 라인 사용법만을 소개한다. 만일 React나 Webpack과 같은 플러그인과 혼합 사용법을 알고 싶다면 위의 가이드 링크에서 참고하길 바란다.

1. PurgeCSS를 프로젝트에 다운로드 한다.

# purgecss는 dev용이니 devDependencies에 설치
> npm i --save-dev purgecss

2. CSS 프레임워크를 적용한 html or js와 css 파일을 프로젝트 폴더에 위치 시킨다

dist : 최적화된 css 파일을 담을 폴더
b-boot.css : 부트스트랩 통짜 파일
index.html : 부트스트랩 CSS 코드가 적용된 웹페이지 문서

<!-- 부트스트랩 클래스 코드가 사용된 html 파일 -->
<!DOCTYPE html>
<html>
<head>
    <title>Bootstrap Sample</title>
    <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css">
</head>
<body>
    <div class="container">
      <div class="row">
        <div class="col-sm-6">
          <h2 class="ps-md-6 m-5">Column 1</h2>
          <p>Some text..</p>
        </div>
        <div class="col-sm-6">
          <h2>Column 2</h2>
          <p>Some text..</p>
        </div>
      </div>
    </div>
</body>
</html>

3. 아래 CLI 명령어를 실행한다.

> npx purgecss --css [부트스트랩 파일] --content [html or js 파일] --output [결과물을 저장할 폴더]

> npx purgecss --css bootstrap/b-boot.css --content bootstrap/index.html --output bootstrap/dist

Options:
  -V, --version                        버전 번호를 출력합니다
  -con, --content <files...>           콘텐츠 파일의 글로브 패턴
  -css, --css <files...>               CSS 파일의 글로브 패턴
  -c, --config <path>                  설정 파일의 경로
  -o, --output <path>                  정리된 CSS 파일을 쓸 파일 경로 또는 디렉토리
  -font, --font-face                   사용하지 않는 폰트 페이스를 제거하는 옵션
  -keyframes, --keyframes              사용하지 않는 키프레임을 제거하는 옵션
  -v, --variables                      사용하지 않는 변수를 제거하는 옵션
  -rejected, --rejected                제거된 선택자를 출력하는 옵션
  -rejected-css, --rejected-css        제거된 CSS를 출력하는 옵션
  -s, --safelist <list...>             제거되지 않아야 할 클래스의 목록
  -b, --blocklist <list...>            제거되어야 할 선택자의 목록
  -k, --skippedContentGlobs <list...>  스캔되지 않아야 할 폴더/파일의 글로브 패턴 목록
  -h, --help                           명령어에 대한 도움말을 표시합니다

4. CSS 최적화된 결과물이 나오면 원본 파일 대신 프로젝트에 적용하면 된다.

관계 대수 & 관계 해석 표현법 총정리

인파_ — Fri, 21 Apr 2023 10:41:08 +0900

관계 대수 (Relation Algebra)

관계 대수식이란 기존 릴레이션(테이블)들로부터 새로운 릴레이션을 생성하는 절차적 언어 문법이라고 보면 된다. 릴레이션에 대해 기본적인 연산자들을 적용하여 보다 복잡한 관계 대수식을 점차적으로 만들 수 있다.

쉽게 생각해 우리가 숫자를 더하거나 나누어 원하는 수를 도출하듯이, 릴레이션을 관계 대수라는 전용 연산자를 통해 더하거나 곱해 원하는 릴레이션을 도출하는 것으로 생각하면 된다.

관계 연산자들은 릴레이션의 특성에 따라 일반 집합 연산과 순수 관계 연산으로 나뉘며, 각각의 연산 결과는 또 다른 관계 대수식의 입력으로 사용될 수 있다.

이렇게 관계 대수식은 사용자가 원하는 데이터를 얻기 위한 절차를 시스템에 명세하는 데이터 언어로서 관계 데이터 모델에서의 릴레이션을 조작하기 위한 기본 연산 중 하나이다. 그래서 관계 대수는 상용 관계 DBMS들에서 널리 사용되는 SQL의 이론적인 기초이기도 하다. 또한 SQL을 구현하고 최적화하기 위해 DBMS의 내부 언어로서도 사용된다.

관계 대수의 8대 연산자

8대 관계 연산자란, 관계형 데이터베이스에서 자주 사용되는 8가지 기본적인 연산자들을 의미한다. 이러한 연산자들은 데이터베이스의 기초적인 연산들이며, 관계형 데이터베이스에서 매우 중요한 개념이다. 관계 연산자들을 잘 이해하고 사용함으로써, 데이터베이스의 질의를 보다 효율적으로 수행할 수 있기 때문이다.

셀렉션 : 테이블에서 한 개 끄집어낸다
프로젝션 : 학생 테이블에서 특정한 학번 이름만 출력.
합집합 : union 겹치는 걸 제외하고 테이블 합
교집합 : 겹치는 것만 테이블
차집합 : A - B 한 결과 테이블
카티션 곱 : 나올수 있는 조합 경우의 수
조인 : 결합
디비전 : 분할

셀렉션 연산자 σ

원하는 데이터를 수평적으로 도출함
σ (sigma)로 연산자를 표현

~~σ DNO=3 (EMPLOYEE)~~ : EMPLOYEE 테이블에서 DNO가 3인 행을 도출

프로젝션 연산자 Π

원하는 데이터를 수직적으로 도출함
Π (pi)로 연산자를 표현
보통 셀렉션의 결과 릴레이션에는 중복 튜플이 존재할 수 없지만, 프로젝션 연산의 결과 릴레이션에는 중복된 튜플들이 존재할 수 있다. 따라서 도출된 릴레이션에 중복이 들어있다면 이 중복은 자동으로 제거된다.

~~Π TITLE(~~EMPLOYEE~~)~~ : EMPLOYEE 테이블에서 TITLE 열을 도출

합집합 연산자 ∪

두 릴레이션의 튜플들을 합침
합친 결과 릴레이션에서 중복된 투플들은 제외됨
∪ 로 연산자를 표현
합집합은 합집합 호환 조건이 맞아야만 실행할 수 있다.

합집합 호환 (union compatible)
서로 다른 테이블에 union 하는데 있어, 갯수가 다르거나 도메인이 다르면 안된다. 이 규칙은 합집합, 차집합, 교집합에 모두 적용된다.
예를들어, 아래의 EMPLOYEE 릴레이션과 DEPARTMENT 릴레이션은 기본적으로 어트리뷰트 수가 다르므로 합집합 호환 조건에 맞지 않는다고 생각할 수 있다.

그러나 EMPLOYEE 릴레이션에서 DNO를 프로젝션한 결과 릴레이션과 DEPARTMENT 관계에서 DEPTNO를 프로젝션한 결과 릴레이션은 애트리뷰트수가 같으며 DEPTNO와 DNO 도메인이 같기 때문에, 따라서 두 릴레이션은 결과적으로 합집합 호환 조건이 부합된다.

김창섭이 속한 부서의 부서번호 + 개발 부서의 부서번호

교집합 연산자 ∩

두 릴레이션의 튜플들의 겹치는 부분만을 도출
∩로 연산자를 표현

차집합 연산자 -

두 릴레이션의 튜플들의 겹치지 않는 부분만을 도출
-로 연산자를 표현

카티션 곱 연산자 ×

두 릴레이션(테이블) 에서 가능한 모든 조합을 만들어주는 연산자
두 테이블로 만들 수 있는 모든 경우의 수를 나타내는 전체 집합을 도출
카디션 곱해서 나오는게 값이 크면 오버헤드가 너무 커지기 때문에 실제로는 카티션 곱 연산자는 사용하지않고 뒤에서 배울 조인(join) 연산자를 사용한다.
×로 연산자를 표현

디비전 연산자 ÷

한 테이블에서 다른 테이블의 모든 값을 가지고 있는 행들을 찾아주는 연산자
'모든 ~에 대해 ~하는' 형태의 질의에 사용될 수 있음
디비전은 나누는 테이블의 열의 개수만큼 결과 테이블의 열의 개수가 줄어들게 된다
÷로 연산자를 표현

조인 연산자 ⋈

두 개의 릴레이션으로부터 연관된 투플들을 결합하는 연산자
⋈로 연산자를 표현
조인 연산자는 다음과 같이 연산 방식에 따라 여러 조인으로 나뉜다
- 세타 조인(theta join)
- 동등 조인(equi join)
- 자연 조인(natural join)
- 외부 조인(outer join)
- 세미 조인(semi join)

세타 조인 & 동등 조인

세타 조인은 두 릴레이션에서 공통된 애트리뷰트를 기준으로 비교 연산자(=,<>,<=,<,>=,>)를 사용하여 조건을 만족하는 튜플들을 결합하는 것이다.
동등 조인은 세타 조인 중에서 비교 연산자가 =인 조인이다.
즉, 두 릴레이션에서 공통된 애트리뷰트의 값이 같은 튜플들을 결합하는 것을 말한다.

자연 조인

동등 조인의 결과 릴레이션에서 조인 애트리뷰트를 제외한 조인 (중복 필드 제거)

외부 조인

널값이 들어 있는 투플들을 다루기 위해서 조인 연산을 확장한 조인
일반적인 조인은 두 릴레이션에서 대응되는 튜플이 없을 경우, 그 튜플을 결과에 포함시키지 않는다. 하지만 외부 조인은 대응되는 튜플이 없어도 결과에 포함시키고, 상대 릴레이션의 애트리뷰트 값은 null로 채운다.
외부 조인에는 어느 릴레이션을 기준으로 null로 채우는지에 따라 3가지로 나뉜다.
- 왼쪽 외부 조인(left outer join)
- 오른쪽 외부 조인(right outer join)
- 완전 외부 조인(full outer join)

left outer join

right outer join

full outer join

집단 함수

한 릴레이션에서 특정 속성들의 값들에 대해 총합, 평균, 최대, 최소, 개수 등의 연산을 수행하는 함수
관계 대수의 표현력을 높이기 위해 새로 추가된 연산자
집단 함수는 각 그룹에 대해 독립적으로 적용되며, 그룹화 연산자와 함께 사용 된다.
AVG, SUM, MIN, MAX, COUNT

그룹화

한 릴레이션에서 특정 속성들의 값에 따라 튜플들을 여러 그룹으로 분류하고, 각 그룹에 대해 집단 함수를 적용하는 연산자
그룹화 연산자는 G로 표기됨

관계 대수와 SQL

관계 대수는 관계 데이터베이스에서 릴레이션을 조작하기 위한 절차적 언어이다. 즉, 원하는 데이터를 얻기 위해 어떤 연산을 어떤 순서로 수행할 것인지를 수학 공식 처럼 명시함으로써 릴레이션을 도출 할 수 있다. 관계 대수에는 일반 집합 연산자와 순수 관계 연산자가 있으며, 이들은 모두 릴레이션을 입력으로 받아 릴레이션을 출력한다.
SQL은 관계 데이터베이스에서 데이터를 정의하고 조작하기 위한 선언적 언어이다. 즉, 원하는 데이터가 무엇인지만 선언하면 데이터베이스 시스템이 알아서 최적의 방법으로 질의를 수행한다. SQL에는 DDL(Data Definition Language), DML(Data Manipulation Language), DCL(Data Control Language) 등의 구성 요소가 있으며, 이들은 모두 릴레이션에 대한 연산을 표현이다.

관계 대수와 SQL은 서로 밀접한 관계에 있다고 볼 수 있다. 애초에 관계 대수의 업그레이드 버전이 SQL 이기 때문이다. SQL은 관계 대수의 한계를 극복하고, 관계 데이터베이스에서 다양한 데이터를 쉽고 강력하게 조작할 수 있도록 해준다. 아주 쉽게 비유하자면, 수학 공식과 같은 관계 대수식을 프로그래밍 언어처럼 구성한게 SQL이라고 보면 된다.

예를 들어, 관계 대수의 셀렉트 연산자는 SQL의 WHERE 절과 대응되고, 프로젝트 연산자는 SQL의 SELECT 절과 대응된다. 또한, 관계 대수의 조인 연산자는 SQL의 JOIN 절과 대응되며, 집단 함수와 그룹화 연산자는 SQL의 집합 함수와 GROUP BY 절과 대응된다.

-- 셀렉트 연산자: σ<salary > 3000000> (EMP)
SELECT * FROM EMP WHERE salary > 3000000;

-- 프로젝트 연산자: Π<name, dept> (EMP)
SELECT name, dept FROM EMP;
  
-- 합집합 연산자: EMP ∪ MANAGER
SELECT * FROM EMP UNION SELECT * FROM MANAGER;
  
-- 교집합 연산자: EMP ∩ MANAGER
SELECT * FROM EMP INTERSECT SELECT * FROM MANAGER;
  
-- 차집합 연산자: EMP - MANAGER
SELECT * FROM EMP EXCEPT SELECT * FROM MANAGER;
  
-- 카티션 곱 연산자: EMP × DEPT
SELECT * FROM EMP CROSS JOIN DEPT;
  
-- 조인 연산자: EMP ⋈<EMP.dept = DEPT.dno> DEPT
SELECT * FROM EMP JOIN DEPT ON EMP.dept = DEPT.dno;
  
-- 디비전 연산자: WORKS ÷ PROJECT
SELECT empno FROM WORKS GROUP BY empno HAVING COUNT(*) = (SELECT COUNT(*) FROM PROJECT);
  
-- 집단 함수와 그룹화 연산자: DNO G AVG_SALARY (EMP)
SELECT DNO, AVG(SALARY) AS AVG_SALARY FROM EMP GROUP BY DNO;

따라서, SQL 언어를 학습하기 앞서 먼저 관계 대수를 이해하면 릴레이션 도출 원리는 거의 같으니 단순히 SQL 문법만 추가로 배우면 이미 데이터베이스 테이블을 다루는데 문제가 없다. 물론 처음부터 SQL을 통해 관계 대수의 개념과 원리를 학습할 수도 있다.

관계 해석 (Relation Calculus)

우리가 지금까지 배운 관계 대수는 전용 연산자를 통해 원하는 목표 데이터를 얻기 위하여 어떻게 데이터를 검색할 것인지 절차를 수학 식으로 순차적으로 명세해 릴레이션을 도출해왔다.

반면, 관계 해석은 원하는 데이터가 무엇인지만 선언하는 이른바 비절차적 언어이다. 즉, 원하는 데이터만 명시하고 "어떻게 질의를 해석하는가"에 대해 언급이 없는 선언만 하는 언어인 것이다.

관계 해석은 튜플 관계 해석 (Tuple Relational Calculus), 도메인 관계 해석 (Domain Relational Calculus) 종류가 있으며, 수학 식 형태로는 아래와 같다.

-- EMPLOYEE 릴레이션에서 급여가 3000 이상인 사원들의 이름과 급여를 찾는 관계 해석 식
{<t.Ename, t.Salary> | t ∈ EMPLOYEE ∧ t.Salary ≥ 3000}

-- 위의 관계 해석식과 매칭되는 SQL 코드
SELECT Ename, Salary
FROM EMPLOYEE
WHERE Salary >= 3000;

구분	구성요소	기호	설명
연산자	OR 연산	V	원자식 간 “또는”이라는 관계로 연결
	AND 연산	∧	원자식 간 “그리고”라는 관계로 연결
	NOT 연산	ㄱ	원자식에 대해 부정
정량자	전칭 정량자 (Universal Quantifier	∀	모든 가능한 튜플 “For All” # All의 ‘A’를 뒤집은 형
정량자	존재 정량자 (Existential Quantifier)	∃	어떤 튜플 하나라도 존재 “There Exists” # Exists의 ‘E’를 뒤집은 형

관계 대수식과 완전히 다른 관계 해석식을 보니 머리만 아프다

관계 대수 vs 관계 해석

관계대수는 어떻게 데이터를 처리할지를 효율적으로 정하는 데 사용되며, 관계해석은 어떤 데이터가 필요한지를 더욱 간단하게 정의하는 데 사용된다고 보면 된다.

관계대수	관계해석
절차적 언어(순서 명시)	비절차적 언어(계산 수식의 유연적 사용), 프레디킷 해석(Predicate Calculus) 기반
원하는 정보를 얻기 위해 어떻게 (how) 질의를 해석하는지를 기술	원하는 정보가 무엇 (what) 인지만 명시하고 어떻게 질의를 해석하는지에 대해 언급하지 않는 선언
연산자와 피연산자로 구성되며, 연산자는 릴레이션에 적용되어 새로운 릴레이션을 생성	명제와 변수로 구성되며, 명제는 참 또는 거짓의 값을 가지고, 변수는 릴레이션의 튜플이나 애트리뷰트 값을 나타냄
연산자의 종류에 따라 다양한 데이터 조작을 할 수 있음	연결자와 한정자를 사용하여 복잡한 조건식을 만들 수 있음
종류로는 순수관계 연산자, 일반집합 연산자가 있다	종류로는 튜플 관계 해석, 도메인 관계 해석이 있다

관계 해석을 반드시 공부해야 되는가

보통 대학 강의나 데이터베이스 교제를 보면, 관계 대수에 대해 자세히 다루고 바로 SQL로 넘어가지, 관계 해석을 중점적으로 다루지는 않는다. 관계 대수로 릴레이션 조합법 및 도출 원리를 배우고 바로 SQL로 실전 데이터베이스 질의를 습득하는 것 만으로도 실무를 하는데 충분하기 때문이다.

애초에 관계 해석은 비절차적인 언어이기 때문에, 컴퓨터가 직접 실행할 수 있는 형태가 아니다. 그래서 관계 해석으로 표현된 질의를 관계 대수로 변환하거나 SQL로 번역해야 하는 추가 작업이 든다. 따라서 데이터베이스 관련 서적에서는 관계 대수에 대해 자세히 다루고 관계 해석은 간단하게 다루는 경우가 많다. 하지만 이것은 관계 해석이 중요하지 않다는 의미가 아니라, 관계 대수가 실제 데이터베이스 시스템에서 더 많이 사용되고 구현하기 쉽기 때문이다.

관계 해석을 공부하면 데이터베이스의 이론적인 배경과 논리적인 구조를 이해할 수 있고, SQL을 보다 효과적으로 작성하고 분석할 수 있다. 또한 관계 해석은 데이터베이스의 의미와 제약 조건을 명확하게 표현할 수 있는 방법이므로, 데이터베이스 설계와 모델링에도 도움이 된다. 실제로 관계 해석은 관계 대수와 동등한 표현력을 가지고 있으며, 논리적인 추론과 수학적인 표현을 사용하여 질의를 정의할 수 있다. 따라서 관계 해석은 데이터베이스에 대한 깊은 지식과 실력을 향상시키는 데 유용하다.

그러나 아무래도 관계 대수, 관계 해석을 모두 공부하기에는 시간적인 여유 때문에 현실적으로는 힘든것은 사실이다. 그래서 관계 대수를 우선적으로 공부하고, 관계 해석은 필요한 부분만 공부하는 것도 나쁘지 않다. 중요한 것은 데이터베이스의 이론과 SQL을 통해 데이터베이스 실습을 병행하면서 데이터베이스에 대한 깊은 지식과 실력을 향상시키는 것이다.

# 참고자료

https://slidesplayer.org/slide/17323973/

https://velog.io/@ieed0205/%EA%B4%80%EA%B3%84%EB%8C%80%EC%88%98-SQL-LEEToday

https://wook-2124.tistory.com/333

first-child / first-of-type 속성 차이점

인파_ — Thu, 20 Apr 2023 08:17:16 +0900

first-child 와 first-of-type 차이점

first-child 와 first-of-type은 똑같이 자식 형제 요소 고르는것같은데 무엇이 다를까? 한방에 이해하기 쉽게 간단명료하게 설명하면 이렇다.

div > p:first-child

'div 하위의 p 요소 중 첫번째 요소' 로 읽는 게 아니라 'div 하위의 첫번째 자식인 요소가 p 요소' 이면이다.
즉, div의 자손 요소중에 first-child를 고르는데 그게 p이면 스타일을 적용한다.
만일 p가 없다면 스타일을 적용하지 않는다.
'div first-child is p' 라고 영어 문장으로 이해하면 된다.

.parent > span:first-child {
	background: lightgreen;
}

.parent2 > p:first-child {
	background: lightgreen;
}

<div class="parent">
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <p class="box box1">p</p>
    <p class="box box1">p</p>
</div>

<div class="parent2">
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <p class="box box1">p</p>
    <p class="box box1">p</p>
</div>

See the Pen first-child by barzz12 (@inpaSkyrim) on CodePen.

div > p:first-of-type

마찬가지로 'div 하위의 p 요소 중(OF) 첫번째 요소' 라고 읽으면 바로 이해가 될 것이다.
즉, div의 자손요소중에 p태그를 모두 고르고 그중에 first-of-type만 스타일을 적용한다.
'div p first-of-type' 라고 영어 문장으로 이해하면 된다.

.parent > span:first-of-type {
	background: lightgreen;
}

.parent2 > p:first-of-type {
	background: lightgreen;
}

<div class="parent">
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <p class="box box1">p</p>
    <p class="box box1">p</p>
</div>

<div class="parent2">
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <span class="box box1">span</span>
    <p class="box box1">p</p>
    <p class="box box1">p</p>
    <p class="box box1">p</p>
</div>

See the Pen first-of-type by barzz12 (@inpaSkyrim) on CodePen.

last-child 와 last-of-type 차이점

last-child 와 last-of-type 도 똑같은 개념으로 적용된다고 보면된다.

div > p:last-child

div의 자손 요소중에 first-child를 고르는데 그게 p이면 스타일을 적용한다.
만일 p가 없다면 스타일을 적용하지 않는다.

.parent > span:last-child {
	background: lightgreen;
}

.parent2 > p:last-child {
	background: lightgreen;
}

See the Pen Untitled by barzz12 (@inpaSkyrim) on CodePen.

div > p:last-of-type

div의 자손요소중에 p태그를 모두 고르고 그중에 first-of-type만 스타일을 적용한다.

.parent > span:last-of-type {
	background: lightgreen;
}

.parent2 > p:last-of-type {
	background: lightgreen;
}

See the Pen Untitled by barzz12 (@inpaSkyrim) on CodePen.

웹 애니메이션 최적화 requestAnimationFrame 가이드

인파_ — Tue, 18 Apr 2023 09:55:49 +0900

자바스크립트 웹 애니메이션

웹페이지의 애니메이션을 구현할때 CSS의 ~~animatoin~~ , ~~transition~~ , ~~transform~~ 속성을 통해 구현할 수도 있지만, 보다 사용자와의 복잡한 상호작용을 구현하게 하기 위해 Javascript와 함께 사용하여 스타일을 변화시키도 한다. 예를들어 특정 영역을 클릭하거나 웹페이지를 스크롤할때 변화무쌍한 애니메이션 작업들이 그러하다.

그래서 간단하고 규칙적인 애니메이션은 CSS로만 요소의 좌표값이나 스타일 크기를 변화시키고, 세밀한 조작이 필요한 애니메이션은 자바스크립트로 스타일 속성을 변경 시키는 편이다. 하지만 자바스크립트로 스타일 속성을 변화시키는 방법은 CSS보다 (특히 모바일에서) 성능이 좋지 않다. 따라서 어쩔수 없이 자바스크립트와의 상호 협력이 필요할 경우 이를 위한 최적화 기법이 존재한다.

이번 포스팅은 이러한 애니메이션 관련 최적화 API인 ~~requestAnimationFrame()~~ 에 대한 사용법과 원리를 소개해보는 시간을 가져 보겠다. 브라우저라는 소프트웨어를 전문적으로 다루는 프론트엔드 개발자일 경우 이에 관한 지식은 거의 필수라고 볼 수 있다.

브라우저 렌더링 단계

브라우저가 화면에 무언가를 그리기까지는 아래 사진과 같이 게 3 단계로 나눌 수 있다.

Javascript - 애니메이션 및 기타 작업 스크립트를 수행 (DOM 생성)
Style - CSS 규칙을 어떤 요소에 적용할지 계산하는 프로세스 (CSSOM 생성)
Layout - 브라우저는 DOM과 CSSOM을 결합하여 객체들의 위치와 크기 등을 계산하는 렌더 트리(Render Tree)를 생성.
Paint(redraw) - 브라우저는 렌더 트리를 사용하여 실제로 화면에 픽셀을 출력 (객체가 실제 화면에 그려지는 것을 의미)
Composite - 브라우저는 화면에 출력되는 객체들을 합성하여 최종 화면을 생성

현재는 저 단계 하나하나를 여기서는 자세히 알아볼 필요는 없고, 자바스크립트로 엘리먼트를 무언가 변화를 준다면 코드를 실행하고 끝~ 이 아니라, 위와 같은 복잡한 랜더링 파이프라인 단계를 지나 화면에 그린다는 정도로만 알고 있으면 된다.

브라우저 프레임

게임 모니터를 고르다보면 60hz, 120hz 라고 모니터 주사율을 들어본 적이 있을 것이다. 이는 1초동안 모니터 화면의 출력 빈도를 나타내는 단위 이다. 그리고 보통 hz는 frame과 관련이 있다.

우리가 영화나 애니메이션을 보는 것은 사실 짧은 시간 간격에 이어지는 장면을 보는 것이다. 이 각각의 장면을 frame이라고 한다. 즉, 프레임은 한 장의 사진이라 봐도 무방하다. 그리고 특정 시간 내에 보여지는 frame 갯수를 frame rate 혹은 frame per second 줄여서 fps라고 한다. (게임을 해보면 가장 자주 듣는 단위일 것이다)

보통 인간의 눈은 1초에 60번 장면이 넘어가야 부드럽다고 느낀다고 한다. 그래서 현대 기기들은 시각적인 효과를 위해 초당 60번 화면을 다시 그리도록 기본적으로 설계된다. 이를 60fps 혹은 60hz 라고 불리우는 이유이다.

굳이 FPS를 설명하고 Hz까지 설명하는 이유는 웹 화면에 부드러운 애니메이션 움직임 효과를 주기 위해선 이 프레임 단위에 맞게 설계해야 되기 때문이다. 초당 60개의 프레임을 렌더링 한다는 말은, 16.666 밀리세컨드(1000ms / 60fps) 간격으로 프레임 생성이 필요한 셈이 된다. 따라서 자바스크립트로 사용자에게 부드러운 애니메이션을 구현하려면 16.6ms밀리초 마다 코드를 호출하는 식으로 구현해야 한다.

타이머 함수를 이용한 애니메이션 스크립팅

따라서 자바스크립트로 일정 시간마다 코드를 반복 호출하는 대표적인 방법으로는 타이머 함수인 ~~setInterval()~~ 와 ~~setTimeout()~~ 을 이용해 60프레임에 맞게 스크립팅을 한다면 아래 코드와 같이 구성할 수가 있다.

const performAnimation = () => {
  /* 스타일 조정 스크립트 */
}

// 1초에 60번 무한 반복
setInterval(performAnimation, 1000 / 60)

const performAnimation = () => {
  /* 스타일 조정 스크립트 */
  
  setTimeout(performAnimation, 1000 / 60); // 함수 내부에서 다시 setTimeout을 호출하여 반복
}

setTimeout(performAnimation, 1000 / 60);

타이머 함수의 문제점

그러나 ~~setInterval()~~ 와 ~~setTimeout()~~ 의 문제점은 주어진 시간내에 동작을 할 뿐 프레임을 신경 쓰지 않고 동작한다는 점이다. 타이머 함수는 프레임 단위로 프레임 시작 시간에 맞춰 실행됨을 보장하지 못하기 때문이다.

만일 아래 그림처럼 약 16ms 간격으로 프레임 단위가 진행되어야 하는데, 브라우저가 다른 작업 수행으로 인해 지연되어 자바스크립트의 콜백 코드 부분이 단위 중간에서 호출되었다고 하자.

자바스크립트 실행에 의해 리플로우가 일어나 위에서 본 브라우저 렌더링 단계인 레이아웃 - 페인트 - 합성 과정이 다시 일어나게 되는데, 그러면 프레임이 생성되지 못하고 누락되어 버려 1 프레임이 깎여버리는 현상이 나타나게 된다.

이러한 현상이 일어날 수 있는 이유는 자바스크립트의 콜 스택(call stack)은 싱글 스레드 이기 때문이다

프레임이 깎인다는 것은 곧 프레임 드랍이 일어나 결국 화면이 버벅이게 된다. 이러한 지연(delay) 발생 문제 때문에 대안으로 탄생한 것이 바로 rAF(requestAnimationFrame) 이다.

requestAnimationFrame

requestAnimationFrame 함수는 시스템이 프레임을 그릴 준비가 되면 애니메이션 프레임을 호출하여 애니메이션 웹페이지를 보다 원활하고 효율적으로 생성할 수 있도록 해준다. 실제 화면이 갱신되어 표시되는 주기에 따라 함수를 호출해주기 때문에 자바스크립트가 프레임 시작 시 실행되도록 보장해주어 위와 같은 밀림 현상을 방지해준다.

아래 이미지는 requestAnimationFrame 를 통해 애니메이션을 구현할 때, 각 프레임이 브라우저의 프레임 주기에 맞추어 일정한 시간 간격으로 렌더링됨을 보여준다. requestAnimationFrame 함수가 실행되면 브라우저는 다음 프레임이 그려지기 전에 함수를 실행하도록 예약하기 때문에 각 프레임이 정확히 16.6ms 간격으로 렌더링되게 되게 된다.

See the Pen setInterval vs requestAnimationFrame by barzz12 (@inpaSkyrim) on CodePen.

이처럼 애니메이션 프레임을 페인팅할 준비가 됐을 때 호출한다는 부분은, 이전 setInterval 방식이 준비가 되지 않아도 페인팅을 요청하는 것과 대비되면서, 보다 웹브라우저에 최적화 되어 있다고 말할 수 있다. 또한 지연 및 블로킹 현상이 생기지 않아 보다 부드러운 애니메이션을 제공한다.

requestAnimationFrame 장점

백그라운드 동작 중지

setInterval 같은 경우 브라우저의 다른 탭 화면을 보거나 브라우저가 최소화되어 있을 때 계속 타이머가 돌아 콜백을 호출하기 때문에 시스템 리소스 낭비를 초래하고 불필요한 전력을 소모하게 만든다.

반면 requestAnimationFrame는 페이지가 비활성화 된 상태이면 페이지 화면 그리기 작업도 브라우저에 의해 일시 중지됨으로 CPU 리소스나 배터리 수명을 낭비하지 않게 된다.

디스플레이 주사율에 맞게 호출 횟수

이 특징은 최적화된 웹 애니메이션을 구현하는데 있어 setInterval 과 requestAnimationFrame 의 결정적인 차이점이라고 말할 수 있다. 지금까지 1초에 60번 호출한다고 써왔지만, 정확히 말하자면 자신의 모니터가 60hz 주사율 모니터일 경우이다. 즉, 웹브라우저는 디스플레이의 주사율을 따르며 만일 144hz 주사율 고사양 모니터일 경우 rAF 역시 1초에 144번 호출되게 된다.

정리하자면 setInterval 에서는 콜백 함수 호출 간격을 시간을 지정해주고 호출 횟수를 설정하지만, rAF에서는 모니터의 주사율을 그대로 따르게 되어 최적화 되어 있다는 것이다. 그리고 이러한 특성 때문에 rAF는 스크롤 이벤트 최적화 기법으로도 쓰이기도 한다.

Animation frames 큐에서 처리

requestAnimationFrame(rAF) 함수도 setTimeout 이나 여타 이벤트 핸들러와 같이 "애니메이션 프레임"을 그리기 위한 콜백 함수를 등록하고 비동기 task로 분류하여 처리된다. 이때 중요한 특징은 rAF는 일반적인 task queue가 아니라 animation frame이라는 별개의 queue에서 처리된다는 점이다.

Animation frames 은 브라우저의 렌더링 엔진이 다음 프레임을 그리기 전에 실행해야 하는 rAF에 등록한 콜백 함수들을 담는 큐이다. 별도의 큐에서 적재되어 이벤트 루프에 의해 꺼내지기 때문에 실행이 뒤쳐지거나 하는 현상을 감소할수가 있다. 단, requestAnimationFrame도 브라우저의 CPU나 GPU 사용량 여부 등에 따라 콜백 함수 실행이 밀릴 수도 있다.

위는 브라우저의 자바스크립트 이벤트 루프 주기의 실행을 그림으로 표현한 것이다. 그림을 처음 보면 되게 눈 아프로 복잡하게 보일 수 있는데 간단히 정리하면 다음과 같다.

Task queue 1 - 이벤트 콜백 함수, setTimeout 및 setInterval 비동기 콜백 함수를 처리
Task queue 2 - Task queue 1에 있는 모든 콜백 함수들이 실행된 후 실행되어야 하는 다음 콜백 함수들이 들어간다.
Microtask queue - Promise 객체, Mutation Observer 객체를 처리 (가장 우선순위가 높음)
Animation frames - requestAnimationFrame 와 같이 브라우저 렌더링과 관련된 태스크 처리

간단한 이벤트 루프 호출 스택만을 본 독자분들은 난이도가 수직 상승하는 느낌을 받을 수 있겠지만, 똑같은 비동기 함수라도 이렇게 처리 우선순위 큐가 별도로 있다는 정도 알고 있으면 된다.

~~Promise.then~~ 결과가 ~~setTimeout~~보다 우선 된다는 소리도 바로 이 때문이다.

requestAnimationFrame 사용법

~~requestAnimationFrame~~ 사용법은 ~~setTimeout~~ 처럼 콜백 함수 내부에서 재귀 호출 하는 식으로 구성하면 된다. 브라우저는 애니메이션 프레임을 출력할 때마다 requestAnimationFrame 에 등록된 콜백 함수들을 비동기로 호출하여, 애니메이션을 부드럽게 출력해준다. 대신 차이점은 ~~setTimeout~~ 은 타이머를 지정해주어야 하지만, ~~requestAnimationFrame~~ 은 프레임 단위로 동작하기 때문에 별도의 반복 플래그가 필요 없다는 점이다.

const performAnimation = () => {
  /* 스타일 조정 스크립트 */
  
  requestAnimationFrame(performAnimation) // 함수 내부에서 다시 requestAnimationFrame을 호출하여 반복
}

requestAnimationFrame(performAnimation);

그리고 ~~setTimeout~~ 을 취소하기 위해 ~~clearTimout~~ 을 사용하듯이, ~~requestAnimationFrame~~ 를 취소하는 방법으로 ~~cancelAnimationFrame~~ 를 사용한다. 아래와 같이 특정한 조건에서 애니메이션을 중지하고 싶을때 이용하면 된다.

let raf; // requestAnimationFrame을 담을 변수

const performAnimation = () => {
    /* 스타일 조정 스크립트 */
	
    // 특정한 조건일 경우 raf를 중지하고 콜백 종료
    if(조건) {
    	cancelAnimationFrame(raf);
		return;
    }

    raf = requestAnimationFrame(performAnimation) // 함수 내부에서 다시 requestAnimationFrame을 호출하여 반복
}

requestAnimationFrame(performAnimation);

requestAnimationFrame 예제

다음은 로켓 요소가 있고, ~~requestAnimationFrame~~를 통해 y좌표 값을 조정하여 위로 올리는 코드를 반복 호출하여 애니메이션을 실행하는 예제이다.

<img class="rocket" src="https://www.freeiconspng.com/thumbs/rocket-png/rocket-png-1.png" alt="로켓 애니메이션">
<count class="value">0</count>
<button>다시 시작</button>

const rocket = document.querySelector('.rocket');
const value = document.querySelector('.value');
let yPos = 0;
let rafId;

// 콜백 함수
const render = () => {
  yPos += 2; // y 좌표 증가

  rocket.style.transform = `translateY(${-yPos}px)`; // 로켓을 위로 올리기
  value.innerHTML = yPos; // 카운터 표시

  // 만약 로켓 위치가 일정 y좌표값일 경우 requestAnimationFrame 종료
  if (yPos >= 500) {
    cancelAnimationFrame(rafId);
    return;
  }

  rafId = requestAnimationFrame(render); // rAF 반복 호출
}

requestAnimationFrame(render); // 애니메이션 시작

// 만일 로켓에 마우스 커서를 올려놓으면 애니메이션 중지
rocket.addEventListener('mouseover', () => {
  cancelAnimationFrame(rafId);
});

// 만일 로켓에 마우스 커서를 빼면 애니메이션 재시작
rocket.addEventListener('mouseout', () => {
  requestAnimationFrame(render);
});

See the Pen requestAnimationFrame by barzz12 (@inpaSkyrim) on CodePen.

애니메이션 타이머 이용하기

requestAnimationFrame 함수의 콜백 함수의 인자로 매개변수를 전달하면 requestAnimationFrame 함수가 실행되기 시작한 이후의 시간을 얻을 수 있다. 이를 이용해 애니메이션 수행 시간을 구해 특정 타이머일때 스크립트를 실행하는 식의 응용이 가능하다.

let startTime;

// requestAnimationFrame의 콜백 함수에 매개변수를 정의
const draw = (timestamp) => {
    if (!start) start = timestamp; // 애니메이션 시작 시간

	currentTime = timestamp - startTime;

	// 애니메이션이 실행된지 2초가 지나면..
	if(currentTime > 2000) { 
        console.log('END');
        return;
    }

	requestAnimationFrame(draw);
}

requestAnimationFrame(draw);

# 참고자료

https://youtu.be/9XnqDSabFjM

https://dribbble.com/shots/1945400-FPS-frames-per-second

https://jbee.io/web/optimize-scroll-event/

한방에 이해하는 attribute 와 property 속성 차이

인파_ — Mon, 17 Apr 2023 08:12:01 +0900

Attribute vs Property 정의 차이

attribute 와 property 를 한국어로 번역하자면 둘다 '속성' 이라는 의미를 가지고 있다. 단순히 단어명이 같은 것을 떠나서 실제로 둘은 html 요소에 대한 클래스와 아이디와 같은 속성을 가리킨다. 이처럼 어트리뷰트와 프로퍼티의 둘은 같은 의미를 내포하지만, 웹 프로그래밍에서 이 둘은 구체적인 차이점이 존재 한다.

HTML의 Attribute

어트리뷰트는 HTML의 속성이다. 엘리먼트에 아이디나 클래스와 같은 추가적인 정보를 일컫는다고 보면 된다

<!-- div 엘리먼트의 id와 class 속성은 어트리뷰트 이다 -->
<div id="inpa" class="bold"></div>

<!-- input 엘리먼트의 type과 value 속성은 어트리뷰트 이다 -->
<input type="text" value="0">

DOM의 Property

프로퍼티는 DOM의 속성이다. 즉, html의 attribute를 DOM 내에서 대신해서 표현이라고 보면 된다.

<div class='my-class' style="color: red;"></div>

<script>
    // className과 style은 프로퍼티이다
    document.querySelector('div').className; // "my-class"
    document.querySelector('div').style.color; // "red"
</script>

위 트리는 ~~<div class= ‘my-class’></div>~~ 태그를 DOM 으로 표현한 것인데 위에서 ~~className~~이 property가 되는 것으로 보면 된다. div 태그 안에 ~~class="이름"~~ 으로 되어있는데 ~~className~~ 속성명으로 접근해서 설정할 수 있는 이유는 어트리뷰트와 프로퍼티가 비록 이름은 다를지라도 서로 연결되어있어서 그렇다.

DOM은 HTML을 자바스크립트 객체(Object)로 표현한 문서 모델이라고 보면 된다. 그래서 자바스크립트로 HTML 구조의 부분과 통신하고, 업데이트하고, 생성하고, 삭제하는 행위를 할 수 있다.

[JS] 브라우저 DOM 다루기 문법 총정리

브라우저 DOM 종류 브라우저는 HTML 문서를 로드한 후, 해당 문서에 대한 모델을 메모리에 생성한다. 이때 모델은 객체의 트리로 구성되는데, 이것을 DOM tree라 한다. 문서 노드(Document Node) 트리의

inpa.tistory.com

Attribute vs Property 기능 차이

엘리먼트 속성 접근 차이

attribute는 html 안에서 property 는 DOM tree 안에서 존재한다. 이것이 뜻하는 바는 attribute는 정적으로 변하지 않고 property는 동적으로 그 값이 변할 수 있다는 의미를 내포하고 있다. 예를 들어 체크 박스 태그가 있을 때 유저가 체크박스에 체크를 하면 attribute의 상태는 변하지 않지만 property의 상태는 checked로 변하게 된다.

실전 예를 들어보자. 아래 input 태그가 있고 ~~value~~ 어트리뷰트로 0 값을 가지고 있다.

<input type="text" value="0">

이를 자바스크립트 DOM 문법을 통해서 input 엘리먼트에 접근해 value 속성 값을 가져올 수 있다. 여기서 ~~input.value~~ 는 프로퍼티이다.

const input = document.querySelector('input');
console.log(input.value); // '0'

이번엔 value 속성값을 임의의 값으로 변경해보자. ~~input.value~~ 의 값을 재설정하고 다시 확인해 보면 변경된 값으로 설정 되었음을 확인 할 수 있다.

input.value = 66;
console.log(input.value); // '66'

그런데 HTML 태그를 보면 여전히 value의 값은 0 인채 그대로 있는걸 볼 수 있다.

위에서 말한 어트리뷰트는 정적이고 프로퍼티는 동적 이라는 말이 바로 이것이다. 어트리뷰트와 프로퍼티는 둘이 연결되어 있긴 하지만 엄밀히 다른 녀석이라, 프로퍼티의 값을 변경해도 DOM 객체만 업데이트 되고 HTML은 업데이트 되지 않아 어트리뷰트의 값은 그대로 인 것이다.

DOM은 JavaScript 모델이므로 굳이 HTML 속성을 계속 업데이트할 필요가 없다. 실제로 리소스 낭비가 될 수 있어 이런식으로 설계 되었다고 보면 된다.

따라서 DOM과 HTML 둘다 특정 속성에 대해 값을 변경하고 싶다면, ~~setAttribute()~~ 메서드를 통해 업데이트 해주면 된다.

const input = document.querySelector('input');

input.setAttribute('value', 99);

console.log(input.value); // '99'

사용자 정의 속성 접근 차이

HTML에 미리 정의된 태그의 속성 뿐만 아니라 개발자가 임의로 엘리먼트에 사용자 정의 속성을 만들어 넣을 수도 있다.

<!-- 실제 html에 없는 사용자 정의 임의 속성 custom -->
<input type="text" value="0" custom="9999">

그런데 프로퍼티의 특징으론 엘리먼트가 가진 모든 속성이 프로퍼티로 되지는 않다는 점이다. HTML에 지정된 속성들은 프로퍼티로도 표현되지만, 엘리먼트에 임의로 지정한 사용자 정의 속성은 프로퍼티로 자동으로 표현되지 않는다. 실제로 자바스크립트로 접근해보면 9999 가 아닌 undefined 라는 결과값을 내뱉는다.

const input = document.querySelector('input');
console.log(input.custom); // undefined

이러한 사용자 정의 속성 값에 접근하려면 ~~getAttribute()~~ 와 ~~setAttribute()~~를 사용하면 된다.

console.log(input.getAttribute('custom')); // '9999'

속성 이름 제약사항

프로퍼티는 자바스크립트 객체 이기 때문에 프로퍼티 이름은 점(.)연산자 표기법을 사용하는 식별자로 간주되고, 식별자 규칙을 따라야해서 프로퍼티명을 이름 짓는데 제약이 있다. 예를들어 어트리뷰트는 ~~background-image~~ 와 같이 - 문자를 사용해도 되지만, 프로퍼티는 변수명 규칙에 따라야 하기 때문에 ~~backgroundImage~~ 로 접근해야 된다.

const div = document.querySelector('div');

// 프로퍼티
div.style.backgroundImage = 'url()';

// 어트리뷰트
div.setAttribute('style', 'background-image: url()');

프로퍼티 이름과 속성 이름이 서로 다른 몇몇 예로는, class/className , readonly/readOnly, maxlength/maxLength 등이 있다. 예약어인 경우 ~~className~~ 처럼 다른 이름이 존재하고, 여러 단어로 이루어진 속성이름인 경우 낙타 표기법(CamelCase)을 사용해서 표현된다.

성능 차이

일반적으로 프로퍼티 접근이 ~~getAttribute()~~ 와 ~~setAttribute()~~ 메서드보다 약간 더 빠르다. 따라서 사용자 정의 속성과 같이 별도의 프로퍼티가 없는 경우에만 메서드를 이용하고 그외에는 프로퍼티로 접근하는 방법이 이상적이라 볼 수 있다.

# 참고자료

https://ultimatecourses.com/blog/attributes-versus-properties-in-javascript

https://medium.com/hexlant/attribute-%EC%99%80-property-%EC%9D%98-%EC%B0%A8%EC%9D%B4-c6f1c91ba91

[JS] 재미있게 확실히 이해하는 null / undefined / NaN 차이

인파_ — Fri, 14 Apr 2023 09:47:21 +0900

자바스크립트의 요상한 falsy 값

자바스크립트에서 null, NaN, undefined는 다른 프로그래밍 언어에는 없는 자바스크립트에만 있는 요상한 falsy 값으로서, 이들은 모두 값이 없음(falsy)을 나타내는 특별한 값이다. 그래서 이들은 조건문에서 false로 평가되어 진다.

값	Boolean 문맥	Number 문맥	String 문맥
null	false	0	"null"
undefined	false	NaN	"undefined"
NaN	false	NaN	"NaN"
Infinity	true	Infinity	"Infinity"

하지만 대부분 null, NaN, undefined 간의 의미의 구체적인 차이에 대해 애매모호하게 알거나 정확히 모르는 사람이 꽤 많다. 따라서 이번 포스팅에는 null, NaN, undefined값을 두루마리 휴지로 비유한 이미지를 통해 정확히 어떤 의미이며 왜 이러한 의미인지 알아보는 시간을 가져 보겠다.

두루마리 휴지로 비유하는 falsy 값

위 이미지는 자바스크립트 falsy 값에 대한 일종의 유머적 비유이다. 모두 의미 없거나 부적절한 값들이지만 휴지 형태에 따라 확실히 의미하는 바가 다름을 볼 수 있다. 이들 4개의 값을 설명하자면 다음과 같다.

0 의 상태

정수 0은 대다수 프로그래밍 언어에서 false로 평가된다. 이를 휴지로 비유하면 휴지 내용물이 없다는 의미이다. 단, 0 이라도 고유한 숫자 타입 이듯이 휴지 내용물이 없어도 휴지임을 알 수 있는 '곽티슈' 와 이를 담는 '휴지걸이'는 잔존한다.

null 의 상태

보통 null을 그저 값이 없는 상태라고 알고 있는 분들이 많지만, 이는 정확하지 않은 의미이다. 정확히 null은 어느 reference 변수에 대해 주소값이 없는 것을 표현하기 위한 키워드 값이다. 객체의 속성 값이 존재하지 않을 때나 함수의 매개변수를 초기화하는 용도로 사용 되기도 한다.

레퍼런스 변수란 객체와 같이 힙(heap) 공유 메모리 영역에 저장되는 포인터 라고 이해하면 된다.

그런데 null은 오로지 reference 변수에만 담을 수 있기 때문에, 일반적인 값인 정수나 문자를 저장하는 primitive 변수에는 null을 저장할 수 없다. 따라서 Java에서는 이 primitive 변수에 대해 값을 주지 않을 경우 지정된 초기화 값을 자동으로 할당하게 하였고, C언어에서는 가비지 값을 자동으로 할당한다.

#include <stdio.h>

int main() {
   int num;
   printf("%d", num); // -56982792084 이상한 쓰레기 값
   return 0;
}

public class MyClass {
    int number; // 인스턴스 변수

    public static void main(String[] args) {
        MyClass obj = new MyClass();
        System.out.println(obj.number); // 출력 결과: 0 (원래는 C언어 처럼 쓰레기값이 나오지만 JVM에 의해서 기본값으로 설정된다)
    }
}

reference 변수냐 primitive 변수냐 에 따라 타입이 없는 자바스크립트로도 알수가 있는데, 1을 할당한 변수의 타입은 number 타입이지만, null을 할당한 변수의 타입은 object 임을 알 수가 있다.

결론적으로, 위의 0과 다른점은 곽티슈는 없지만 휴지걸이는 잔존해 있다는 점이다. 왜냐하면 null 값을 들고 있는 객체 자체는 프로그래머가 정의하여 메모리에 올려져 주소값을 받은 준비가 되어 있기 때문이다.

즉, 값은 없지만 값을 담을 수 있는 그릇은 있는 것이다. 따라서 휴지를 담는 휴지걸이 자체는 잔존해 있는 것이다.

undefined 의 상태

undefined는 변수가 정의되어 있지 않은 상태, 즉 값이 할당되지 않은 상태를 나타낸다.

바로 위에서 primitive, reference 변수를 들며 자바와 C언어에서 어떻게 초기화를 진행하는지에 대해 설명하였었다. 두 언어만 하더라도 어떤 타입의 변수냐에 따라 초기화되는 과정이 달랐다.

따라서 자바스크립트에선 심플하게 어떤 타입의 변수든 간에 값이 없다는걸 undefined 라는 표현으로 퉁쳤다고 보면 된다. 심지어 변수 타입 자체도 ~~undefined~~ 로 되어 있다. 심플하게 표현하기 위해 이러한 방식을 취한것 같은데, 만일 기존의 C언어나 자바에 익숙한 개발자들에겐 오히려 혼동만 일으킨 것 같다고 개인적으로 생각된다.

null vs undefined

null과 undefined 차이점은 내부 메모리적인 측면에서 봐야 된다.

undefined는 변수가 초기화되지 않았거나, 객체의 속성이 존재하지 않는 등의 경우에 자동으로 할당되는 값으로, 이때의 변수는 메모리에 존재하지만 값이 없기 때문에 크기가 매우 작다.

반면, null은 개발자가 의도적으로 값이 없음을 할당한 경우에 사용되는 값으로, 이때의 변수는 빈 객체를 가리키는 객체 포인터이기 때문에 주소값을 나중에라도 받기위해 크기가 있어 메모리를 차지하게 된다.

따라서, undefined 값을 가진 변수의 메모리 용량은 작고, null 값을 가진 변수의 메모리 용량은 크다고 정리할 수 있겠다. (이는 상대적인 비교일 뿐이므로 실제로는 거의 차이가 없다고 봐도 된다)

다만, 자바스크립트에서는 변수가 컴파일 시점이 아닌 런타임 시점에 동적으로 할당되기 때문에, 변수의 크기는 런타임 환경에 따라 다를 수 있어 메모리 크기는 정확히 알 수 없다.

반면 자바(Java)에선 reference 변수 같은 경우 32비트 JVM 기준으로 4바이트가 할당되게 된다.

null 과 undefined가 서로 완전히 다른 존재라는 점은, 자바스크립트에서 타입을 출력해보면 알 수 있다.

null 과 undefined 비교

마지막으로 휴지로 비유한 그림을 보면 아예 빈 공간임을 볼 수가 있는데, 휴지 내용물도 그 휴지를 담을 휴지걸이 자체도 없기 때문이다. 왜냐하면 타입 자체가 ~~undefined~~ 이기 때문이다.

위에서 null을 비유할때 아무것도 담기지 않은 그릇이라 표현했는데, undefined는 그릇 자체가 통째로 없는 것이다.

NaN 의 상태

NaN은 Not a Number의 약자로 숫자가 아닌 값을 나타낸다. 그러나 숫자가 아니지만 타입은 Number 타입으로 취급된다. 숫자 타입이면서 숫자가 아닌 값이라니 뭔가 말이야 방구야 싶겠지만, 실제로 이러한 표현에 대한 필요성이 존재한다.

예를들어 문자 "100" 을 숫자 타입으로 형변환하면 어떠한 에러 없이 숫자 100으로 치환이 된다. 이러한 기능이 있는 이유는 대부분의 사용자가 입력한 값이 문자열 형태인 경우가 많아 이를 숫자로 변환하여 계산해야 하는 상황이 많기 때문이다.

대표적으로 form에 입력한 모든 값은 문자열이다

그런데 해당 문자가 "100ABC" 와 같은 숫자와 일반 문자열이 섞인 형태일 경우, 이를 함수를 통해 숫자로 변환할때 문제가 된다. 그래서 타입 자체는 넘버 타입으로 변환은 됬지만 내용물이 숫자가 아니라는 값을 표현하기 위해 NaN 이라는 표현을 쓰는 것이다. 그래서 NaN은 일종의 오류 값으로 취급된다. 이밖에도 숫자와 문자열을 연산하려고 해도 NaN이 발생한다.

반면 자바(Java)에선 문자열이 유효한 숫자 형식이 아닐경우 NumberFormatException을 발생시킨다.

// 문자 100을 + 연산자를 통해 숫자로 형변환
let a = +"100"; 
console.log(a); // 숫자 100

// 문자 ABC를  + 연산자를 통해 숫자로 형변환
let b = +"ABC";
console.log(b); // NaN (숫자로 형변환해서 숫자 타입 값이지만 숫자가 아님)

이를 휴지로 비유하면 '이 값은 말도 안 되는 값'이라는 뜻을 표현하기 위해 두루마리 휴지를 저런식으로 말도안되게 이상하게 꽂은 것으로 보면 된다.

⚙️ 난잡한 if-else 문 리팩토링 기법 (가독성 & 성능↑)

인파_ — Thu, 13 Apr 2023 08:19:59 +0900

자바스크립트 조건문 리팩토링

아무리 고급적인 프로그래밍 문법, 기법들을 익히고 그걸 활용하더라도, 자신의 코드에서 가장 많이 비중을 차지하는 문법은 아마 조건문 일 것이다. 프로그램은 반복문과 조건문만 있으면 돌아간다라는 말이 있듯이 조건 분기문은 프로그래밍의 기본이기도 하다. 그런데 이 if-else 분기문을 생각없이 지나치게 중첩하고 생각없이 코드를 나열한다면 가독성이 크게 떨어진다는 문제점이 생기게 된다. 예를들어 if문 안에 if가 있고 그 else문 안에 if~else 안의 if 등등.. 이렇게 코드를 짜듯이 말이다. 농담 삼아 아래와 같이 코드가 마치 아됴겐을 맞은것과 같은 모습이 되어 버릴지도 모른다.

아됴겐 ~

물론 컴퓨터 입장에선 코드 로직상 문제는 없을텐지만 이를 나중에 사람이 유지보수 하기 위해 코드를 복기하는 과정에서 굉장한 노력과 시간 그리고 스트레스가 소모될 것이다. 그래서 이러한 if문을 최적화하는 스타일 기법이 존재한다.

이번 포스팅에선 4가지의 방법론을 소개할 예정인데, 첫번째와 두번째는 if문의 위치를 조정함으로써 좀더 보기 편하게 유지보수 좋게 만들어주는 코드 순서에 가깝다면, 세번째 네번째는 '디자인 패턴'에 가깝다.

주니어 프로그래머와 시니어 프로그래머를 가르는 기준은 회사마다 '사바사' 이기 때문에 항상 논란이 되지만, if문을 어떤식으로 짜느냐에 따라 이 둘을 가를수 있다는 점은 누구나 동의한다. 그만큼 조건문 리팩토링은 사소한 것 처럼 보이지만 유지보수가 중요한 현업에서 굉장히 중요하게 여겨진다. 지금부터 주니어 딱지의 1mg 이라도 떼보러 가보자.

길다란 조건식은 함수로 분리

아래 예제는 날짜를 구해서 비교를 통해 여름 방학인지, 겨울 방학인지 구하는 조건식이다. 한눈에 봐도 조건식의 코드가 굉장히 난잡한 것을 볼 수 있다.

const now = new Date();
const year = date.getFullYear();

if (now > new Date(year, 6, 25) && now < new Date(year, 7, 31)) {
	// 매년 6월 25일 ~ 7월 31일 일 경우 
	console.log('여름 방학 입니다');
} else if (now > new Date(year, 11, 19) && now < new Date(year + 1, 1, 28)) {
	// 매년 11월 19일 ~ 내년 1월 28일 일 경우 
	console.log('겨울 방학 입니다');
}

주석을 통해 어느정도 뜻하는 바를 한눈에 알 수는 있지만 분기문 코드 자체가 여전히 난잡하고 불성 사납다.

이럴 경우 조건식 자체를 아예 함수로 만들어서 심플하게 구성하는 것이 좋다. 이때 함수명을 이름만 보고도 무엇을 판단하는 로직인지 쉽게 알 수 있게 하기 위해 적절한 함수명을 지어준다. 조건문을 리팩토링한 결과는 아래와 같다.

function isSummerVacation(now) {
  const year = date.getFullYear();
  return now > new Date(year, 6, 25) && now < new Date(year, 7, 31)
}

function isWinterVacation(now) {
  const year = date.getFullYear();
  return now > new Date(year, 11, 19) && now < new Date(year + 1, 1, 28)
}

const now = new Date();

if (isSummerVacation(now)) {
	// 매년 6월 25일 ~ 7월 31일 일 경우 
	console.log('여름 방학 입니다');
} else if (isWinterVacation(now)) {
	// 매년 11월 19일 ~ 내년 1월 28일 일 경우 
	console.log('겨울 방학 입니다');
}

~~isSummerVacation()~~ 함수와 ~~isWinterVacation()~~ 함수를 만들어주고 길다란 조건문을 함수의 return 문으로 넣었다. 그리고 if 문의 블록에는 함수 호출문으로 변경해준다. 이렇게 함으로써 코드가 더욱 가독성이 좋아짐을 볼수있다. 전체적인 로직 자체는 변한게 없다. 코드를 모듈화하여 그저 if 문의 조건식 코드 길이를 함수 호출문을 통해 획기적으로 줄인 것이다.

Early Return 기법

Early Return이란 조건문에서 먼저 Return할 수 있는 부분은 분리하여 우선 초반 라인의 if문 내에서 Return하여 함수를 미리 종료하는 기법을 말한다. if-else문이 너무 많으면 읽기가 어렵고 조건에 대해 명시적이지 않을 수 있는데, Early Return을 적용하면 뒤의 코드로 진입하지 않아 else문을 사용하지 않아, 로직은 변함이 없으면서 가독성이 좋고 더 명시적인 코드로 리팩토링 할 수 있다.

다음과 같이 ~~loginService()~~ 라는 함수에 로그인 여부, 토큰 여부, 가입 여부를 확인하는 중첩 분기문이 있다고 가정해보자.

function loginService(isLogin, user) {
    let result = '';

    // 1. 로그인 여부 확인
    if (isLogin == false) {
        // 2. 토큰 존재 확인
        if (checkToken() == true) {
            // 3. 가입 여부 재확인
            if (user.nickName == undefined) {
                registerUser(user); // 회원 가입하기
                result = '회원가입 성공';
            } else {
                refreshToken(); // 토큰 발급
                result = '로그인 성공';
            }
        } else {
            throw new Error('에러 - 토큰이 없습니다 !');
        }
    } else {
        result = '이미 로그인 중';
    }

    result += ` (+ 시도 횟수 ${count++}번)`;
    return result;
}

이 코드 모습을 대충 그림으로 흐름도를 표현하자면 아래와 같이 될 것이다.

의도하고자 하는 바는 알겠지만 계속 조건을 중첩해서 들어가 생각해야 되기 때문에 코드 가독성이 그렇게 좋지 않아 보인다. 따라서 이를 최적화 해보자.

Early Return 리팩토링 순서

1. if문 다음에 나오는 공통된 절차를 첫번째 분기점 내부에 각각 넣는다

코드 중복을 피하려고 꺼내놨더니 거꾸로로 다시 중복 시켜놓는 것으로 보일 수 있다. 다만 이는 리팩토링에 있어 필요한 과정이니 그대로 이행하자.

이때 여기서 첫번째 분기점이란, 코드 레벨의 첫 if문을 말한다. 즉, if문 안의 if문 같은 경우 제외 된다.

function loginService(isLogin, user) {
    let result = '';

    if (isLogin == false) {
        if (checkToken() == true) {
            if (user.nickName == undefined) {
                registerUser(user);
                result = '회원가입 성공';
            } else {
                refreshToken();
                result = '로그인 성공';
            }
        } else {
            throw new Error('에러 - 토큰이 없습니다 !');
        }

        result += ` (+ 시도 횟수 ${count++}번)`; // 공통된 절차
        return result; // 공통된 절차
    } else {
        result = '이미 로그인 중';

        result += ` (+ 시도 횟수 ${count++}번)`; // 공통된 절차
        return result; // 공통된 절차
    }
}

2. 분기점에서 짧은 절차부터 실행하게 if문을 반전 시킨다

if문 과 else문을 블럭을 보면 코드 절차가 긴것은 if문이다. 따라서 절차가 짧은 else 블럭 코드 부분을 if 문에 넣어주기 위해 if-else를 반전 시킨다. 간단하게 기존의 ~~if (isLogin == false)~~ 를 거꾸로 ~~if (isLogin == true)~~ 로 구성해주면 코드를 뒤바꿀 수 있게 되어 짧은 부분이 위쪽으로 오게 되고 길다란 부분이 아래쪽으로 오게 된다.

function loginService(isLogin, user) {
    let result = '';

    if (isLogin == true) { // else와 뒤바꾸기 위하여 boolean 을 반전시킨다
        result = '이미 로그인 중';

        result += ` (+ 시도 횟수 ${count++}번)`;
        return result;
    } else {
        if (checkToken() == true) {
            if (user.nickName == undefined) {
                registerUser(user);
                result = '회원가입 성공';
            } else {
                refreshToken();
                result = '로그인 성공';
            }
        } else {
            throw new Error('에러 - 토큰이 없습니다 !');
        }

        result += ` (+ 시도 횟수 ${count++}번)`;
        return result;
    }
}

만일 아래와 같이 첫 if문이 else문이 없는 순수 if문이라서 진행에 무리가 있다면, 아래와 같이 간단하게 빈 else문을 만들어 버리고 진행하면 된다. (그게 그거기 때문)

3. 짧은 절차가 끝나면 return(함수 내부의 경우)이나 break(for문 내부의 경우) 로 일찍 중단점을 추가한다

본문의 예제는 함수문 이고, 이미 리턴문을 위로 올렸으니 그대로 진행하면 된다.

4. else를 제거한다. (이 때 중첩하나가 제거된다)

function loginService(isLogin, user) {
    let result = '';

    if (isLogin == true) {
        result = '이미 로그인 중';

        result += ` (+ 시도 횟수 ${count++}번)`;
        return result;
    } // else { 를 제거한다

    if (checkToken() == true) {
        if (user.nickName == undefined) {
            registerUser(user); 
            result = '회원가입 성공';
        } else {
            refreshToken(); 
            result = '로그인 성공';
        }
    } else {
        throw new Error('에러 - 토큰이 없습니다 !');
    }

    result += ` (+ 시도 횟수 ${count++}번)`;
    return result;
}

5. 다시 1번 부터 돌아가 작업을 반복한다

공통된 절차를 첫번째 분기점 내부에 넣는다

분기점에서 짧은 절차부터 실행하게 if문을 반전한다

else를 제거한다 (중첩이 하나 제거된다)

6. 리팩토링 결과

이렇게 중첩 조건문들을 하나하나 꺼내면서 리팩토링한 결과 코드의 모습은 마치 아래와 같이 중첩되지 않고 하나의 레벨에서 각 조건식을 판별하는 형태가 되게 된다. 이러헥 구성하면 로직이 의미하고자 하는 바를 한눈에 알 수 있고 조건식을 중첩하여 생각하지않고 분리하여 생각함으로써 코드를 빠르게 복기할 수 있게 된다.

function loginService(isLogin, user) {
    let result = '';

    // 1. 로그인 여부 확인
    if (isLogin == true) {
        result = '이미 로그인 중';

        result += ` (+ 시도 횟수 ${count++}번)`;
        return result;
    }

    // 2. 토큰 존재 확인
    if (checkToken() == false) {
        throw new Error('에러 - 토큰이 없습니다 !');
    }

    // 3. 가입 여부 재확인
    if (user.nickName == undefined) {
        registerUser(user); // 회원 가입하기
        result = '회원가입 성공';
    } else {
        refreshToken(); // 토큰 발급
        result = '로그인 성공';
    }

    result += ` (+ 시도 횟수 ${count++}번)`;
    return result;
}

3번째 분기인 가입 여부 재확인 부분은 다시한번 리팩토링을 하여 else를 없애도 되고 안없애도 된다.

Early Return 기법은 비단 자바스크립트 프로그래밍 언어 뿐만 아니라 다른 프로그래밍 언어에도 당연히 똑같이 적용되는 부분이니 연습해두면 좋다.

Lookup Table 기법

이번에는 좀더 자바스크립트 스러운 조건문 클린 코드를 소개해볼 것이다. 이 리팩토링 기법은 자바스크립트 프로그래밍 언어만의 일급 객체의 특성을 이용한 방법으로, 기존의 else if 로직을 key-value 쌍의 형태로 각각의 논리를 캡슐화한 것이다. 마치 객체 테이블을 조회하여 분기를 실행하는것과 같다하여 Lookup Table 기법이라 불리운다.

예를 들어 아래와 같이 각 소셜 서비스들의 전용 로그인 함수들이 있다고 가정하고, ~~socialLogin()~~ 함수에서 하나의 매개변수 ~~where~~에 대해 조건별로 로그인 분기가 일자 형태로 나뉘어져 있다고 하자.

// ... 복잡한 로그인 과정 생략한 모듈
const naverLogin = (id) => { return '네이버'; };
const kakaoLogin = (id) => { return '카카오'; };
const facebookLogin = (id) => { return '페이스북'; };
const googleLogin = (id) => { return '구글'; };

const socialLogin = (where, id) => {
    let domain;

    if (where === 'naver') {
        domain = naverLogin(id);
    } else if (where === 'kakao') {
        domain = kakaoLogin(id);
    } else if (where === 'facebook') {
        domain = facebookLogin(id);
    } else if (where === 'google') {
        domain = googleLogin(id);
    }

    return `${domain} ${id}`;
};

console.log(socialLogin('naver', 'inpa'));
console.log(socialLogin('google', 'inpa'));

else if의 연속으로, 이 코드 모습을 대충 그림으로 흐름도를 표현하자면 아래와 같이 될 것이다.

보기엔 가독성 면에서 그렇게 큰 문제가 되지 않아 보이지만, 이러한 구성의 코드를 좀더 효율적으로 짤 수 가 있다.

Lookup Table 리팩토링 순서

1. 조건문만을 따로 분리한다

가장 먼저 ~~socialLogin()~~ 함수내 분기문 코드만 따로 뽑아내어 별도의 ~~executeLogin()~~ 함수로 분리해 구성해준다. 그러면 기존 ~~socialLogin()~~ 함수는 ~~executeLogin()~~ 함수를 호출해 결과값을 받는 형식이 된다.

const executeLogin = (where, id) => {
    if (where === 'naver') {
        domain = naverLogin(id);
    } else if (where === 'kakao') {
        domain = kakaoLogin(id);
    } else if (where === 'facebook') {
        domain = facebookLogin(id);
    } else if (where === 'google') {
        domain = googleLogin(id);
    }
};

const socialLogin = (where, id) => {
    let domain = executeLogin(where, id);
    return `${domain} ${id}`;
};

2. if-else 문을 switch-case 문으로 변환한다

중첩 if문이 아닌 형태는 switch 문으로 변환이 가능하다. 변환하면 아래와 같이 구성될 것이다.

const executeLogin = (where, id) => {
    switch (where) {
        case 'naver':
            return naverLogin(id);
        case 'kakao':
            return kakaoLogin(id);
        case 'facebook':
            return facebookLogin(id);
        case 'google':
            return googleLogin(id);
    }
};

const socialLogin = (where, id) => {
    let domain = executeLogin(where, id);
    return `${domain} ${id}`;
};

참고로 자바스크립트에서 switch-case문일 경우, 다른 언어에서는 해당 케이스로 jump를 해서 바로 원하는 곳으로 이동하지만, js는 case를 나열된 순서대로 평가하기 때문에 사용을 지양하라는 설도 있다.

3. switch-case 문을 객체로 변환한다

switch문을 잘보면 각 문자열 case마다 이에 맞는 함수를 호출하고 있다는 규칙성을 찾을 수 있다. 따라서 case 부분을 객체의 key 값으로, 리턴문을 객체의 value 값으로 구성해준다면 아래와 같이 자바스크립트 객체로 똑같이 구성이 가능하게 된다.

const executeLoginMap = {
    naver: naverLogin,
    kakao: kakaoLogin,
    facebook: facebookLogin,
    google: googleLogin,
};

const socialLogin = (where, id) => {
    let domain = executeLoginMap[where](id); // naver일 경우 naverLogin(id) 로 함수 실행
    return `${domain} ${id}`;
};

그리고 기존 ~~socialLogin()~~ 함수에서 ~~executeLoginMap~~ 객체를 호출 할때 배열 인자를 통해 호출할 key값을 얻게하고, ~~executeLoginMap[where]~~ 통해 얻은 객체의 value값인 함수 표현식을 가져와 그대로 ~~(id)~~ 매개변수를 할당하여 함수를 실행함으로써 결과값을 얻는, 마치 아름다운(?) 코드 디자인 패턴의 일종이라고 볼 수 있다.

처음 그림과 비교하자면, 기존에는 올바른 분기를 검사하기 위해 일일히 각 A, B, C 분기를 일일히 모두 순회하여야 하지만, Lookup Table 기법을 적용하면 모든 조건을 순회할 필요없이 매개변수의 값에 따라 이에 해당하는 객체의 key-value 구성에 따라 각각의 논리는 별도의 함수로 다시 작성되므로 함수를 호출하는 식으로 구성하였기 때문에, 프로세스가 아래 그림과 같이 병렬적으로 분기에 접근하게 되는 형태가 되고 이는 곧 성능 향상으로 직결되게 된다.

Responsibility chain pattern

다만 Lookup Table 기법은 매치된 분기가 있으면 그 분기만 실행하고 함수를 종료한다. 그리고 key 매칭 방식을 사용하기 때문에 하나의 인자값(where)에 대해서만 비교를 하니 만일 여러개의 인자를 비교한다고 하면 적합하지가 않게 된다.

따라서 이에 대한 대응 기법으로 책임 연쇄 패턴(Chain Responsility Pattern)이 존재한다.

책임 연쇄 패턴은 GOF 디자인 패턴의 한 종류로서, 분기문의 블럭들을 객체화 하여, 다수의 처리 객체(핸들러)들을 체인 형태로 묶는 패턴이다. 그래서 어떠한 요청이 발생하였을 때 그 요구를 처리할 객체 핸들러를 순회하는 식으로 하여 분기문을 객체 지향적으로 표현한 기법이라고 보면 된다.

각 네모 박스의 핸들러들이 연쇄적으로 작용된다

위의 Early Return 예제의 결과를 다시 가져와 보았다.

const refreshToken = () => {};
const registerUser = () => {};

function loginService(isLogin, checkToken, user) {
    let result = '';
    let count = 0;

    // 1. 로그인 여부 확인
    if (isLogin == true) {
        result += '이미 로그인 중';
        result += ` (+ 시도 횟수 ${++count}번)`;
        return result;
    }

    // 2. 토큰 존재 확인
    if (checkToken == false) {
        throw new Error('에러 - 토큰이 없습니다 !');
    }

    // 3. 가입 여부 재확인
    if (user.nickName == undefined) {
        registerUser(user); // 회원 가입하기
        result += '회원가입 성공';
        result += ` (+ 시도 횟수 ${++count}번)`;
        return result;
    }

    refreshToken(); // 토큰 발급
    result += '로그인 성공';
    result += ` (+ 시도 횟수 ${++count}번)`;
    return result;
}

console.log(loginService(false, true, { nickName: 'inpa' })); // 로그인 성공 (+ 시도 횟수 1번)
console.log(loginService(true, false, { nickName: 'inpa' })); // 이미 로그인 중 (+ 시도 횟수 1번)
console.log(loginService(false, true, {})); // 회원가입 성공 (+ 시도 횟수 1번)
console.log(loginService(false, false, { nickName: 'inpa' })); // Error: 에러 - 토큰이 없습니다 !

이 자체로도 문제는 없지만 만일 새로운 분기문이 추가될 경우 함수 코드 자체를 통짜로 뜯어 고쳐야 할 수도 있다. 이는 하나의 함수 안에 여러가지의 인자에 대한 조건 판단을 하는 책임을 중앙 집권 적으로 모아져 있기 때문이다.

클래스를 이용한 책임 연쇄 패턴 설계

따라서 위의 Early Return 예제의 결과를 책임 연쇄 패턴으로 재구성 해보자. 코드를 자바(Java) 프로그래밍 언어 스럽게 클래스를 이용해 설계하자면 다음과 같다.

[GOF] Chain Of Responsibility 패턴 - 완벽 마스터하기

Chain Of Responsibility Pattern 책임 연쇄 패턴(Chain Of Responsibility Pattern, COR)은 클라이어트의 요청에 대한 세세한 처리를 하나의 객체가 몽땅 하는 것이 아닌, 여러개의 처리 객체들로 나누고, 이들을 사

inpa.tistory.com

class Handler {
    nextHandler; // 연결될 다음 핸들러 객체를 저장하는 필드
    result = '';
    count = 0;

    setNext(handler) {
        this.nextHandler = handler; // 메서드를 통해 연결할 핸들러를 등록한다
        return handler; // 메서드 체이닝을 위해 인자의 핸들러를 리턴한다
    }
}

class LoginHandler extends Handler {
    check(isLogin, checkToken, user) {
        // 1. 로그인 여부 확인
        if (isLogin == true) {
            this.result = '이미 로그인 중';
            this.result += ` (+ 시도 횟수 ${++this.count}번)`;
            return this.result;
        } else {
            return this.nextHandler.check(isLogin, checkToken, user);
        }
    }
}

class TokenHandler extends Handler {
    check(isLogin, checkToken, user) {
        // 2. 토큰 존재 확인
        if (checkToken == false) {
            throw new Error('에러 - 토큰이 없습니다 !');
        } else {
            return this.nextHandler.check(isLogin, checkToken, user);
        }
    }
}

class JoinHandler extends Handler {
    check(isLogin, checkToken, user) {
        // 3. 가입 여부 재확인
        if (user.nickName == undefined) {
            registerUser(user); // 회원 가입하기
            this.result = '회원가입 성공';
            this.result += ` (+ 시도 횟수 ${++this.count}번)`;
            return this.result;
        } else {
            return this.nextHandler.check(isLogin, checkToken, user);
        }
    }
}
class SuccessHandler extends Handler {
    check(isLogin, checkToken, user) {
        refreshToken(); // 토큰 발급
        this.result = '로그인 성공';
        this.result += ` (+ 시도 횟수 ${++this.count}번)`;
        return this.result;
    }
}

const loginService = (isLogin, checkToken, user) => {
    let result = '';

    // 1. 핸들러(처리 객체) 생성
    const handler1 = new LoginHandler();
    const handler2 = new TokenHandler();
    const handler3 = new JoinHandler();
    const handler4 = new SuccessHandler();

    // 2. 핸들러 체이닝 등록
    handler1.setNext(handler2).setNext(handler3).setNext(handler4);

    // 3. 핸들러 실행
    result = handler1.check(isLogin, checkToken, user); // handler1 → handler2 → handler3 → handler4

    return result;
};

console.log(loginService(false, true, { nickName: 'inpa' })); // 로그인 성공 (+ 시도 횟수 1번)
console.log(loginService(true, false, { nickName: 'inpa' })); // 이미 로그인 중 (+ 시도 횟수 1번)
console.log(loginService(false, true, {})); // 회원가입 성공 (+ 시도 횟수 1번)
console.log(loginService(false, false, { nickName: 'inpa' })); // Error: 에러 - 토큰이 없습니다 !

각 핸들러들이 자기 고유의 요청에 대한 처리 책임을 지니고 있으며, 실행부에서 setNext() 메서드를 통해 핸들러를 체인 시켜준다. 그리고 실행 함수를 호출하면 마치 if-else 처럼 분기를 객체마다 순회하면서 처리를 하게 되는 것이다. 이런 식으로 복합문 else if 논리를 분리하는 데 성공했다.

좀더 심플한 책임 연쇄 패턴 설계

다만 자바스크립트는 일급 객체의 특징을 갖는 언어로서 굳이 클래스 지향으로 설계할 필요가 없다. 이 부분은 모든 GOF 디자인 패턴의 단점이기도 한데, 당장 위의 코드만 봐도 엄청나게 길어진걸 확인 할 수 있다. 따라서 일반 객체를 이용해 다음과 같이 좀 더 자바스크립트 프로그래밍 답게 심플하게 리팩토링 할 수가 있다.

먼저 객체를 담은 배열을 생성하고, 원소 객체마다 match와 action이라는 함수를 각각 만들어 준다. match 부분은 if문의 조건식을 넣는 부분이고, action은 if문 블록 안의 실행 코드를 넣는 부분이다. match는 false일 경우 다음 match로 넘어가게 된다. action은 match가 true 일경우 실행되고 평가를 종료하게 된다.

const rules = [
    {
        match: function (a, b, c) { /* ... */ },
        action: function (a, b, c) { /* ... */ }
    },
    {
        match: function (a, b, c) { /* ... */ },
        action: function (a, b, c) { /* ... */ }
    },
    {
        match: function (a, b, c) { /* ... */ },
        action: function (a, b, c) { /* ... */ }
    }
]

이러한 기법을 이용해서 최종으로 구성한 자바스크립트 책임 연쇄 패턴 코드는 다음과 같다.

const Handler = {
    result: '',
    count: 0,
    rules: [
        {
            // match는 false일 경우 다음 match로 넘어가게 된다.
            match(isLogin, checkToken, user) {
                return isLogin ? true : false; // 1. 로그인 여부 확인
            },
            // action은 match가 true 인 실행 부분을 기재한다
            action(isLogin, checkToken, user) {
                Handler.result = '이미 로그인 중';
                Handler.result += ` (+ 시도 횟수 ${Handler.count++}번)`;
                return Handler.result;
            },
        },
        {
            match(isLogin, checkToken, user) {
                return !checkToken ? true : false;  // 2. 토큰 존재 확인
            },
            action(isLogin, checkToken, user) {
                throw new Error('에러 - 토큰이 없습니다 !');
            },
        },
        {
            match(isLogin, checkToken, user) {
                return user.nickName == undefined ? true : false; // 3. 가입 여부 재확인
            },
            action(isLogin, checkToken, user) {
                registerUser(user); // 회원 가입하기
                Handler.result = '회원가입 성공';
                Handler.result += ` (+ 시도 횟수 ${++Handler.count}번)`;
                return Handler.result;
            },
        },
        {
            match(isLogin, checkToken, user) {
                return true; // 마지막 핸들러 부분이니까 바로 action() 이 실행되도록
            },
            action(isLogin, checkToken, user) {
                refreshToken(); // 토큰 발급
                Handler.result = '로그인 성공';
                Handler.result += ` (+ 시도 횟수 ${++Handler.count}번)`;
                return Handler.result;
            },
        },
    ],
};

const socialLogin = (isLogin, checkToken, user) => {
    let result = '';

    // {march, action} 핸들러 객체가 들어있는 의사 결정 규칙 배열 rules를 순회하면서
    for (const rule of Handler.rules) {
        // 만일 해당 분기에 해당되면
        if (rule.match(isLogin, checkToken, user)) {
            result += rule.action(isLogin, checkToken, user); // 그 분기의 실행부를 호출한다
            return result;
        }
    }
};

console.log(loginService(false, true, { nickName: 'inpa' })); // 로그인 성공 (+ 시도 횟수 1번)
console.log(loginService(true, false, { nickName: 'inpa' })); // 이미 로그인 중 (+ 시도 횟수 1번)
console.log(loginService(false, true, {})); // 회원가입 성공 (+ 시도 횟수 1번)
console.log(loginService(false, false, { nickName: 'inpa' })); // Error: 에러 - 토큰이 없습니다 !

# 참고자료

FE재남 유튜브 - if else 리팩토링

https://javascript.plainenglish.io/how-to-refactor-your-complex-nested-if-else-code-28aa162047d5

‍ 멀티 태스킹 & 멀티 프로세싱 개념 한방 정리

인파_ — Thu, 6 Apr 2023 10:14:00 +0900

컴퓨터의 병행 처리

우리가 음악을 들으면서, 웹서핑을 하고, 메신저의 메시지를 확인할 수 있는 이유는 컴퓨터가 자원을 효율적으로 사용하는 멀티 태스킹(Multi Tasking) 기술 덕분이다. 멀티 태스킹이란 컴퓨터에서 여러 작업을 동시에 실행하는 능력을 말한다. 좀더 자세히 말하자면, OS를 통해 CPU가 작업하는데 필요한 자원을 프로세스 또는 스레드간에 나누는 행위를 말한다. 두 가지 이상 작업을 동시에 처리할 수 있는 이유가 이러한 자원 분담 원리 때문이다.

지금 부터 제한된 자원을 가지고 수십가지의 프로그램을 동시에 실행할 수 있는 원리를 파헤쳐 보자.

프로세싱의 발전 과정

단일 프로세스 (Single Process)

초창기 컴퓨터는 단일 프로세스 시스템 이었다. 한번에 하나의 프로그램만이 실행할 수 있어서, 또 다른 프로그램을 실행하고 싶다면 현재 프로그램을 종료해야 했다. 거기다 CPU 사용률이 효율적이지 못했는데, 프로그램 실행 도중 I/O(입출력) 작업과 같은 일이 생기게 되면 CPU는 프로세스를 멈추고 그대로 놀아버리기 때문이다.

IO(input/output) 이란?
흔히 프로그래밍에서 IO 라고 하면 대표적으로 3가지 뜻을 내포하고 있다.
- 파일을 읽고 쓰는 것
- 서버 네트워크의 어딘가와 데이터를 주고 받는 것
- 마우스, 키보드와 같은 입출력 장치와 데이터를 주거나 받는 것

작업 도중 I/O 작업을 시작하게 되면 끝날 때까지 기다려야 한다

멀티 프로그래밍 (Multi Programming)

이러한 문제를 해결하기 위해 여러개의 프로그램을 메모리에 올려놓고 하나의 CPU에서 번갈아 가며 동시에 실행시키는 방안을 첨가 하였다.

멀티 프로그래밍은 여러개의 프로그램이 동시에 실행된다는 의미로서, CPU 사용률을 극대화 시키는게 목적을 두었다. 단일 프로세스의 문제점이었던 프로세스 #1 작업 시작 후 I/O 작업을 만나게 되면 CPU가 노는게 아니라 프로세스 #2 작업을 시작하게 된다. 다시 프로세스2 작업 시작 후 I/O 작업을 만나게 되면 프로세스1 작업을 시작하게 된다.

그러나 어느 한 프로그램이 CPU 사용 시간이 길어지면 다른 프로세스는 계속 대기를 해야 한다는 문제점이 존재 하였다. 위의 그림에서 P #1 작업 시간이 엄청 길어질 경우 P #2 는 실행될 기회조차 못 얻게 된다.

멀티 태스킹 (Multi Tasking)

멀티 프로그래밍의 취지는 좋았지만 어느한 프로세스가 모두 실행되야 다음 프로세스가 실행될 수 있는 한계점이 있었다. 따라서 이것을 해결하기 위해 프로세스는 한번 CPU를 사용할때 아주 짧은 시간(quantum)만 실행되도록 하여 각 프로그램의 작업을 아주 작은 단위로 번갈아 가며 처리하면서, 작업 응답 시간을 최소화 시키는 멀티 태스킹 원리가 탄생하였다.

이때 잘게 나뉘어진 프로세스 끼리 작업이 스위칭 되는 것을 문맥 교환(Context Switching) 이라고 한다.

프로세스를 아주 잘게 쪼개 번갈아가며 처리

이렇게 프로세스 작업이 잘게 나뉘어져 교대로 실행함으로써 얻게 되면 이점은 다음과 같다.

1. 빠른 반응성 제공

첫째, CPU가 잘게 나눈 각 작업들을 빠르게 번갈아 가며 수행함으로서, 여러 작업을 동시에 처리하는 것처럼 보이게 만들어, 사용자에게 더 빠른 반응성을 제공하여 정말로 동시에 프로그램이 실행되는 것처럼 느껴 차이를 못느끼게 된다.

2. 문제 해결 용이성

둘째, 작업을 나누었기 때문에 예기치 않은 문제가 발생했을 때, 해당 작업만 중지할 수 있게 된다. 이러한 방식으로, 전체 시스템이 멈추는 것을 방지할 수도 있다.

3. 멀티 프로세서의 효율적인 활용

셋째, 멀티 프로세싱 또는 멀티 코어를 사용하는 시스템에서 여러 개의 프로세서(CPU)가 동시에 작업을 효율적으로 처리할 수 있다.

4. 프로세스 우선순위 조절

넷째, 프로세스 간의 우선순위를 조절이 수월해진다. 예를들어 우선순위가 높은 작업은 더 자주 실행되어, 더 빠른 처리를 할 수도 있는 셈이다.

따라서, 작업을 작게 나누어 처리하는 원리는 빠른 반응성을 제공하는 핵심 부분인 셈이다. 그러나 응답성을 향상하기 위해서 문맥 교환(Context Switching)이 자주 일어나게 될 경우 오히려 성능 이슈가 발생할 수 있다는 문제점이 있다. 왜냐하면 프로세스 끼리 스위칭 하는 작업은 우리가 생각하는 것 보다 꽤나 무거운 작업에 해당하기 때문이다.

멀티 프로세싱 (Multi Processing)

옛날 컴퓨터의 CPU는 싱글 코어(core) 였다. 이 싱글 코어에서 여러개의 작업을 동시에 처리하기 위해 멀티 태스킹과 같은 기술을 차용해 작업을 처리한 것이다. 그러나 시대가 발전함에 동시에 CPU 코어의 발열 한계로 인해 코어 깡 클럭을 높이지 않고 코어를 늘리는 방향으로 듀얼 코어, 쿼드 코어 CPU 제품을 출시하기 시작했다.

컴퓨터를 맞출때 한번 쯤은 '4코어 8스레드'와 같은 CPU 스펙에 대해 들어본적이 있을텐데 바로 이것을 말하는 것이다.

즉, 한 CPU에 두개 이상의 코어를 둬서 전체적인 성능을 향상시키는 방향으로 전환을 한 것이다. 그리고 여러 개의 CPU 코어가 동시에 작업을 처리하는 것을 멀티 프로세싱 (Multi Processing) 이라 한다. 이러한 멀티 프로세싱을 아키텍쳐 구조에 따라 종류도 여러가지 이다.

멀티 CPU 코어가 하나의 JOB에 대해 병렬로 처리하거나 여러 JOB에 대해 병렬로 처리

멀티 프로세싱 vs 멀티 태스킹

멀티 프로세싱 (Multi Processing)이란, 여러 개의 CPU 코어가 동시에 작업을 처리하는 것을 의미한다. 여러 개의 프로세서가 병렬로 작업을 수행하므로, 단일 프로세스보다 빠른 처리 속도를 보장할 수 있다.
멀티 태스킹 (Multi Tasking)은 단일 CPU에서 여러 개의 작업을 동시에 처리하는 것을 의미한다. 하나의 CPU가 여러 작업들을 번갈아가며 처리하므로, 여러 개의 작업을 동시에 수행하는 것처럼 보이게 된다.
따라서, 둘은 여러 작업에 대해서 동시에 처리하는 목적은 비슷하지만, 멀티 태스킹은 하나의 CPU에서 여러 개의 작업을 처리하는 반면, 멀티 프로세싱은 여러 개의 CPU가 각각의 작업을 처리하는 것이라는 차이점이 있다.

멀티 태스킹이 두 팔로 여러 작업을 번갈아 빠르게 처리하는 것이라면, 멀티 프로세싱은 팔이 6개인 것이다

멀티 프로세싱 + 멀티 태스킹 조합

둘은 서로 다른 동시 처리 방법이기 때문에 이 둘을 조합하여 더욱 더 시너지 효과를 누릴 수 있다.

멀티 태스킹

멀티 프로세싱

여러 작업에 대한 멀티 프로세싱 + 멀티 태스킹

하나의 작업에 대한 멀티 프로세싱 + 멀티 태스킹

멀티 프로세싱 vs 멀티 프로세스

multi processing 과 multi process 는 영어는 그저 동명사(-ing) 차이 이지만, 이 둘이 의미하는 바는 전혀 다르다. 아마 많은 사람들이 이 둘을 햇깔려 할 것이다.

멀티 프로세싱은 하나의 시스템에서 여러 개의 프로세서(CPU)를 사용하여 작업을 처리하는 것을 의미한다. 즉, 프로세서(CPU)가 멀티인 것이다. 여러 개의 프로세서가 동시에 작업을 처리하므로, 전체적인 처리 속도가 빨라지는 효과에 목적을 둔다.
반면, 멀티 프로세스는 하나의 응용 프로그램을 여러 개의 프로세스로 분리하여 실행하는 것을 의미하는 것이다. 즉, 프로세스(process)가 멀티인 것이다. 여러 개의 프로세스가 동시에 실행되므로, 하나의 프로세스가 죽어도 프로그램이 죽지않아 프로그램 전체의 안정성이 높아지는 것에 목적을 둔다. 보통 멀티 프로세스는 부모 프로세스와 그의 여러 자식 프로세스로 이루어져 있다.

브라우저의 멀티 프로세스

# 참고자료

https://youtu.be/QmtYKZC0lMU

https://velog.io/@ashappyasikonw/Single-Process-System-Multi-programming-Multitasking-%EC%9D%B4%EB%9E%80

https://jenkov.com/tutorials/java-concurrency/concurrency-vs-parallelism.html

https://donghoson.tistory.com/15

‍ 멀티 프로세스 vs 멀티 스레드 비교 완전 총정리

인파_ — Wed, 5 Apr 2023 12:18:00 +0900

멀티 프로세스와 멀티 스레드는 한 어플리케이션에 대한 처리방식 이라고 보면 된다. 단순히 프로그램을 여러개 띄워놓는 것이 멀티 프로세스가 아니라 이 둘은 언제 어느때에 어떤 방식으로 처리하느냐에 따라 다른 것으로 이해해야 한다.

이름으로 유추할 수 있듯이 멀티 프로세스와 멀티 스레드는 여러개의 프로세스, 스레드가 동작하는 것을 일 컫는다. 단일이 아닌 다중으로 돌아감으로써 성능 향상 등 여러가지 효과를 얻을 수 있다. 하지만 또한 이로 인해 발생되는 부가적인 문제점도 발생하게 된다. 지금 부터 이에 대해 자세히 알아보자

‍ ‍완전히 정복하는 프로세스 vs 스레드 개념

한눈에 이해하는 프로세스 & 스레드 개념 전공 지식 없이 컴퓨터의 프로그램을 이용하는데는 문제 없어 왔지만 소프트웨어를 개발하는 사람으로서 컴퓨터 실행 내부 요소를 따져보게 될때, 아

inpa.tistory.com

Multi Process

멀티 프로세스는 운영체제에서 하나의 응용 프로그램에 대해 동시에 여러 개의 프로세스를 실행할 수 있게 하는 기술을 말한다. 보통 하나의 프로그램 실행에 대해 하나의 프로세스가 메모리에 생성되지만, 부가적인 기능을 위해 여러개의 프로세스를 생성하는 것이다.

멀티 프로세스 vs 멀티 프로세서

프로세스(process)는 프로그램의 실행 상태를 말하고, 프로세서(processer)는 CPU 코어를 일컫는다. 둘이 단어가 유사해서 굉장히 혼동할 수 있을텐데, 어쨋든 둘이 의미하는바는 완전히 다르다고 보면 된다.
따라서 멀티 프로세스는 하나의 프로그램에서 여러 개의 프로세스를 실행하는 것을 의미하고, 멀티 프로세서는 여러 개의 CPU 코어가 하나의 시스템에서 동시에 실행되는 것을 의미한다.

멀티 프로세스 내부를 보면, 하나의 부모 프로세스가 여러 개의 자식 프로세스를 생성함으로서 다중 프로세스를 구성하는 구조이다. 한 프로세스는 실행되는 도중 프로세스 생성 시스템 콜을 통해 새로운 프로세스들을 생성할 수 있는데, 다른 프로세스를 생성하는 프로세스를 부모 프로세스(Parent Process)라 하고, 다른 프로세스에 의해 생성된 프로세스를 자식 프로세스(Child Process)라 한다.

부모 프로세스와 자식 프로세스는 각각 고유한 PID(Process ID)를 가지고 있다. 부모 프로세스는 자식 프로세스의 PID를 알고 있으며, 이를 통해 자식 프로세스를 제어할 수 있다. 또한, 자식 프로세스는 부모 프로세스의 PID와 PPID(Parent Process ID)를 알고 있어, 이를 통해 부모 프로세스와의 통신이 가능하다.

다만, 통신이 가능할 뿐이지, 부모 프로세스와 자식 프로세스는 엄연히 서로 다른 프로세스로 독립적으로 실행되며, 독립적인 메모리 공간을 가지고 있어 서로 다른 작업을 수행한다. 대표적인 예로 웹 브라우저의 상단 탭(Tab) 이나 새 창을 들 수 있다. 각 브라우저 탭은 같은 브라우저 프로그램 실행이지만, 각기 다른 사이트 실행을 행하기 때문이다.

이러한 브라우저 멀티 프로세스 원리를 확인하기 위한 간단한 실험도 가능하다. 여러개의 탭을 띄운뒤, 하나의 탭에서 F12로 개발자 도구를 열고 콘솔 탭에 ~~while(1) {}~~ 무한 루프 코드를 실행 시켜보자. 그러면 해당 탭에서는 클릭도 안되고 먹통이 되는 현상을 경험할 수 있다.

하지만 다른 탭에는 정상적으로 브라우징이 가능하다. 이는 탭 마다 다른 프로세스로 동작하기 때문이다.

멀티 프로세스의 장점

1. 프로그램 안전성

멀티 프로세스는 각 프로세스가 독립적인 메모리 공간을 가지므로, 한 프로세스가 비정상적으로 종료되어도 다른 프로세스에 영향을 주지 않는다. 그래서 프로그램 전체의 안전성을 확보할 수 있다는 장점이 있다.

예를 들자면 크롬 브라우저에서 여러개의 탭을 띄우고 여러곳의 웹사이트를 방문해 서비스를 이용한다고 하자. 이때 어느 한 탭의 웹사이트에서 무언가 잘못되어 먹통이 되었다.

아주 심각한 오류가 아닌 이상, 당장 그 브라우저 탭의 웹사이트는 이용을 못하겠지만, 다른 탭은 별 문제없이 이용이 가능할 것이다. 이러한 이유는 자식 프로세스가 여러개 생성되어 메모리에 별도로 관리되기 때문이다.

2. 프로그램 병렬성

멀티 프로세스와 여러개의 CPU 코어를 활용하여 둘의 시너지를 합쳐, 다중 CPU 시스템에서 각 프로세스를 병렬적으로 실행하여 성능을 향상 시킬 수 있다. 예를 들어 이미지 처리나 비디오 인코딩과 같은 작업을 여러 개의 코어나 CPU에 분산시켜 빠르게 처리할 수 있다.

다만, 이 부분은 멀티 프로세스 만의 장점이라기 보단, 멀티 프로세스와 멀티 스레드 둘의 장점이 옳다. 그리고 멀티 스레드로 구성하는 것이 멀티 프로세스로 구성하는 것보다 훨씬 효율적이고 빠르기 때문에, 멀티 프로세스로 성능을 올리는 행위는 거의 없다고 보면 된다. 이에 대해선 뒤의 멀티 스레드 파트에서 다시 다룬다.

3. 시스템 확장성

멀티 프로세스는 각 프로세스가 독립적이므로, 새로운 기능이나 모듈을 추가하거나 수정할때 다른 프로세스에 영향을 주지 않는다. 그래서 시스템의 규모를 쉽게 확장할 수 있다.

이 부분에 대해서는 컴퓨터의 소프트웨어로 예시를 드는 것보다 네트워크의 서버(server)로 드는 것이 적절하기 때문에 잠시 분산 서버에 대해서 말해보겠다. 대규모 웹 서비스에서는 수많은 요청을 동시에 처리하기 위해 여러대의 서버를 두고 로드 밸런서(Load Balancer)와 같은 장비를 사용하여 클라이언트 요청 트래픽을 분산 시킨다. 이때 여러대의 서버는 컴퓨터를 여러개를 말하는 것일 수도 있고, 하나의 성능 좋은 컴퓨터에 여러개의 서버 프로세스를 두는 것을 말하기도 한다. 멀티 프로세스의 상황은 후자이다.

서버 프로그래밍을 해본 백엔드 개발자분들은 서버 클러스터(cluster)를 구성해본 적이 있을 것이다. 하나의 컴퓨터에 여러개의 서버 프로세스를 띄움으로써 요청을 분산시키는 것이다. Node.js 진영에선 대표적으로 PM2 가 있다.

이렇게 멀티 프로세스를 사용하여 여러 대의 서버에 요청을 분산시켜 처리함으로써, 시스템의 규모를 쉽게 확장할 수 있으며, 부가로 서버의 장애나 다운타임을 최소화할 수 있게 되는 것이다.

멀티 프로세스의 단점

1. Context Switching Overhead

멀티 태스킹(multi tasking)을 구성하는데 핵심 기술인 컨텍스트 스위칭(context switching) 과정에서 성능 저하가 올 수 있다. 특히나 프로세스를 컨텍스트 스위칭 하면, CPU는 다음 프로세스의 정보를 불러오기 위해 메모리를 검색하고, CPU 캐시 메모리를 초기화하며, 프로세스 상태를 저장하고, 불러올 데이터를 준비해야 하기 때문에, 이로 인한 빈번한 Context Switching 작업으로 인해 비용 오버헤드가 발생할 수 있게 된다. 반면 스레드를 컨텍스트 스위칭하면 프로세스 스위칭 보다 가벼워 훨씬 빠르고 좋다.

프로세스 1에서 2로 스위칭할때 아주 약간의 빈 시간(오버헤드)가 발생한다

따라서, 멀티 프로세스 환경에서는 Context Switching Overhead를 최소화하는 방법이 중요하다. 이를 위해서 프로세스 수를 적정하게 유지하거나, I/O 바운드 작업이 많은 프로세스와 CPU 바운드 작업이 많은 프로세스를 분리하여 관리하고, CPU 캐시를 효율적으로 활용하는 등의 방법을 고려해 봐야 한다.

2. 자원 공유 비효율성

멀티 프로세스는 각 프로세스가 독립적인 메모리 공간을 가지므로, 결과적으로 메모리 사용량이 증가하게 된다.

만일 각 프로세스간에 자원 공유가 필요할 경우 프로세스 사이의 어렵고 복잡한 통신 기법인 IPC(Inter-Process Commnuication)을 사용하여야 한다.

IPC란 운영체제 상에서 실행 중인 프로세스 간에 정보를 주고받는 메커니즘을 말한다. 이를 위해 파이프, 소켓, 메세지 큐 등 다양한 방법이 사용된다. 그런데 IPC 자체로 오버헤드가 발생한다. 예를 들어, 파이프나 소켓과 같은 IPC 기법은 데이터를 복사하거나 버퍼링하는 과정에서 성능 저하가 발생할 수 있기 때문이다. 또한 코드의 복잡도를 증가시킨다.

Multi Thread

스레드는 하나의 프로세스 내에 있는 실행 흐름이다. 그리고 멀티 스레드는 하나의 프로세스 안에 여러개의 스레드가 있는 것을 말한다. 따라서 하나의 프로그램에서 두가지 이상의 동작을 동시에 처리하도록 하는 행위가 가능해진다.

웹 서버는 대표적인 멀티 스레드 응용 프로그램이다. 사용자가 서버 데이터베이스에 자료를 요청하는 동안 브라우저의 다른 기능을 이용할 수 있는 이유도 바로 멀티 스레드 기능 덕분인 것이다. 즉, 하나의 스레드가 지연되더라도, 다른 스레드는 작업을 지속할 수 있게 된다.

네트워크, 데이터베이스 작업을 하면서 사용자와 상호작용을 동시에

보다 멀티 프로세스와의 차이점을 부각시키기 위해, 멀티 프로세스를 설명할때 예시를 들었던 웹 브라우저를 다시 들어보겠다. 멀티 프로세스는 웹 브라우저에서의 여러 탭이나 여러 창이라고 말했었다. 대신 멀티 스레드는 웹 브라우저의 단일 탭 또는 창 내에서 브라우저 이벤트 루프, 네트워크 처리, I/O 및 기타 작업을 관리하고 처리하는데 사용된다고 보면된다.

멀티 스레드의 장점

윈도우, 리눅스 등 많은 운영체제들이 멀티 프로세싱을 지원하고 있지만 멀티 스레딩을 기본으로 하고 있다. 왜 멀티 프로세스 보다 멀티 스레드로 프로그램을 돌리는 것이 유리한지 그 이유에 대해 알아보자. (이는 스레드 자체의 장점이기도 하다)

1. 스레드는 프로세스보다 가벼움

일단 스레드는 프로세스 보다 용량이 가볍다. 그도 그럴게 스레드는 프로세스 내에서 생성되기 때문에 스레드의 실행 환경을 설정하는 작업이 매우 간단하여 생성 및 종료가 빠르다. 또한 스레드는 프로세스와 달리, 코드, 데이터, 스택 영역을 제외한 나머지 자원을 서로 공유하기 때문에 기본적으로 내장되어 있는 데이터 용량이 프로세스보다 당연히 작다. 그래서 스레드를 생성하고 제거할 때, 프로세스 내부의 자원만을 관리하면 되기 때문에 프로세스 생성, 제거 보다 훨씬 빠른 것이다.

2. 자원의 효율성

멀티 스레드는 하나의 프로세스 내에서 여러 개의 스레드를 생성되기 때문에, heap 영역과 같은 공유 메모리에 대해 스레드 간에 자원을 공유가 가능하다. 이를 통해, 프로세스 간 통신 (IPC)을 사용하지 않고도 데이터를 공유할 수 있기 때문에, 자원의 효율적인 활용이 가능해 시스템 자원 소모가 줄어든다.

3. Context Switching 비용 감소

스레드에도 컨텍스트 스위칭 오버헤드가 존재한다. 하지만 상대적으로 프로세스 컨텍스트 스위칭 오버헤드보다 훨씬 낮아 비용이 낮다는 장점이 있다.

프로세스 컨텍스트 스위칭 비용은 스위칭할 때마다 CPU 캐시에 있는 내용을 모두 초기화하고, 새로운 프로세스 정보를 CPU 캐시에 적재해야 하므로 높은 비용이 든다. 반면, 스레드 컨텍스트 스위칭 비용은 스위칭할 때 스레드 간에 공유하는 자원을 제외한 스레드 정보(stack, register)만을 교체하면 되므로 프로세스 컨텍스트 스위칭 비용보다 상대적으로 낮은 것이다.

4. 응답 시간 단축

앞의 멀티 스레드의 장점을 종합해보자면, 멀티 스레드는 스레드 간의 통신이나 자원 공유가 더욱 용이하며, 프로세스 보다 가벼워 컨텍스트 스위칭 오버헤드도 작다. 따라서 멀티 프로세스 보다 응답 시간이 빠르다.

예를 들어, 웹 서버에서 클라이언트 요청을 처리하는 경우, 멀티 프로세스 방식에서는 각 요청마다 프로세스를 생성하여 처리해야 하므로, 오버헤드가 크지만, 멀티 스레드 방식에서는 여러 개의 스레드가 하나의 프로세스 내에서 요청을 처리할 수 있으므로, 오버헤드가 감소해 더욱 빠른 응답 시간을 보장할 수 있는 것이다.

이러한 이유로, 멀티 프로세서 환경에서 멀티 스레드를 사용하여 작업을 처리하는 것이 멀티 프로세스를 사용하는 것보다 더 효율적이다라고 말할 수 있다.

멀티 스레드의 단점

1. 안정성 문제

멀티 프로세스 모델에서는 각 프로세스가 독립적으로 동작하므로 하나의 프로세스에서 문제가 발생해도 다른 프로세스들은 영향을 받지 않기 때문에 프로그램이 죽지 않고 계속 동작할 수 있다. 그러나 멀티 스레드 모델에서는 기본적으로 하나의 스레드에서 문제가 발생하면 다른 스레드들도 영향을 받아 전체 프로그램이 종료될 수 있다.

물론 이는 프로그래머의 역량에 따라 극복할 수 가 있다. 예를들어 스레드에 에러가 발생할 경우 이에 대한 적절한 예외 처리를 잘 해놓는다던지, 에러 발생 시 새로운 스레드를 생성하거나 스레드 풀(Thread Pool)에서 잔여 스레드를 가져오던지 하여 프로그램 종료를 방지할 수 있다. 다만, 이때 새로운 스레드 생성이나 놀고 있는 스레드 처리에 추가 비용이 발생하게 된다.

2. 동기화로 인한 성능 저하

멀티 스레드 모델은 여러 개의 스레드가 공유 자원에 동시에 접근할 수 있기 때문에, 동기화 문제가 발생할 수 있다. 예를들어 여러 스레드가 동시에 한 자원을 변경해 버린다면 의도되지 않은 엉뚱한 값을 읽어 서비스에 치명적인 버그가 생길수도 있다. 따라서 스레드 간 동기화(syncronized)는 데이터 접근을 제어하기 위한 필수적인 기술이다.

동기화 작업은 여러 스레드들이 자원에 대한 접근을 순차적으로 통제하는 것이다. 그러면 동시 접근으로 인한 동시 수정과 같은 현상은 일어나지 않게 된다. 그러나 동기화 작업은 여러 스레드 접근을 제한하는 것이기 때문에 병목 현상이 일어나 성능이 저하될 가능성이 높다는 단점이 있다.

이를 해결하기 위해 임계 영역(Critical Section)에 대하여 뮤텍스(mutex), 또는 세마포어(Semaphore) 방식을 활용한다.

임계 영역(Critical Section)
- 멀티 스레드 프로그래밍에서 임계 영역은 공유 자원을 접근하는 코드 영역을 말한다. 대표적으로 전역 변수나 heap 메모리 영역을 들 수 있겠다.

뮤텍스(Mutex)
- 공유 자원에 대한 접근을 제어하기 위한 상호 배제 기법 중 하나로, 임계 영역에 진입하기 전에 락(lock)을 획득하고, 임계 영역을 빠져나올 때 락을 해제하여 다른 스레드들이 접근할 수 있도록 한다. 한마디로 오직 1개의 스레드만이 공유 자원에 접근할 수 있도록 제어하는 기법이다.

세마포어(Semaphore)
- 세마포어는 동시에 접근 가능한 스레드의 개수를 지정할 수 있다. 세마포어 값이 1이면 뮤텍스와 동일한 역할을 하며, 값이 2 이상이면 동시에 접근 가능한 스레드의 수를 제어할 수 있다. 스레드가 임계 영역에 진입하기 전에 세마포어 값을 확인하고, 값이 허용된 범위 내에 있을 때만 락을 획득할 수 있는 형식이다. 한마디로 뮤텍스 상위 호환 이라고 보면 된다.

3. 데드락 (교착 상태)

Deadlock 이란, 다수의 프로세스나 스레드가 서로 자원을 점유하고, 다른 프로세스나 스레드가 점유한 자원을 기다리는 상황에서 발생하는 교착 상태를 말한다. 여러 개의 스레드가 서로 대기하면서 무한정 기다리게되는 무한 루프와 같은 증상이라고 보면된다.

예를들어, 스레드 1 은 자원 A을 점유하고 있는 상태에서 자원 B가 필요한 상황이다. 그리고 스레드 2 는 자원 B를 점유하고 있는 상태에서 자원 A이 필요한 상황이다. 하지만 스레드 1은 자원 B가 필요한 상황에서 자원 A을 빌려줄 수 있는 상황이 아니고, 스레드 2또한 자원 A이 필요한 상태에서 자원 B를 빌려줄 수 없는 상황인 것이다.

이처럼 다수의 쓰레드가 같은 lock을 동시에, 다른 명령에 의해 획득하려 할 때 서로 절대 불가능한 일을 계속적으로 기다리는 상황을 이야기 한다.

이러한 현상은 스레드의 특징인 공유 자원에 대한 동시 엑세스로 인한 문제로, 이를 방지하기 위한 상호배제(Mutual Exclusion), 점유와 대기(Hold and Wait), 비선점(No Preemption), 순환 대기(Circular Wait) 등의 알고리즘을 통해 극복해야 한다.

다만, 데드락은 멀티 스레드만의 단점이라기 보다는 멀티 프로세스와 스레드 모델의 공통된 문제점이라고 말하는 것이 옳다. 왜냐하면 프로세스 끼리는 기본적으로 독립적인 메모리 공간이지만 IPC를 통해 공유 자원을 사용할 수 있기 때문에 멀티 스레드와 똑같이 교착 상태에 빠질 수 있기 때문이다.

4. 그래도 Context Switching Overhead

앞서 멀티 프로세스보다 멀티 스레드의 컨텍스트 스위칭 오버헤드가 작아 성능에 유리하다라고 설명했었지만, 그래도 컨텍스트 스위칭 오버헤드 비용 자체를 무시할수는 없다. 특히나 스레드 수가 많으면 많을 수록 그만큼 컨텍스트 스위칭이 많이 발생되게 되고 당연히 이는 성능 저하로 이어진다.

이 부분은 '스레드를 많이 쓸수록 항상 성능이 좋아질까?' 라는 물음으로 던질 수 있다. 보통 사람들이 생각하기에는 스레드가 많으면 많을 수록 그만큼 동시 처리수가 늘어나 당연히 스레드가 많으면 무조건 좋다고 이야기할 것이다. 하지만 '컨텍스트 스위칭 오베허드'라는 개념을 알고 있는 개발자인 우리들은 '과연 꼭 그럴까?' 라는 의문을 던져야 한다.

이 부분은 스레드를 겉햝기로만 배운 지원자를 걸러내기 위해 기술 면접에서 가끔 등장하는 고수준의 질문이기도 하다. 이에 대한 자세한 내용은 아래 포스팅을 참고하길 바란다.

-------------------------------------- 링크 나중에 추가 --------------------------

5. 디버깅이 어려움

멀티 스레드를 사용하면, 여러 개의 스레드가 동시에 실행되기 때문에, 각 스레드의 동작을 추적하기 어려울 수 있다. 예를들어 코드를 디버깅하는 도중에 다른 스레드가 실행되어 예기치 않은 결과가 발생할 수 있다. 또한 어떤 스레드가 언제 어떤 자원에 접근하고, 어떤 순서로 실행되는지 등을 파악하기 어려울 수 있다.

따라서 스레드 간의 상호작용과 동기화 기법을 잘 이해하고, 디버깅 도구를 적극적으로 활용해야 한다.

6. 운영체제의 지원이 필요

오늘날의 윈도우, 리눅스, 맥 OS에선 모두 기본적으로 멀티 스레딩을 기본적으로 지원하도록 설계 되었으니 문제점이라기에는 약간 어폐가 있긴 하다. 하지만, 1980년대의 SunOS3와 같은 오래된 유닉스 시스템에는 스레드가 없었고 프로세스만 있는, 멀티 스레딩을 지원하지 않는 운영 체제가 있었기 때문에 멀티 스레드의 단점으로 넣어 보았다. (그만 잊어도 된다 )

# 참고자료

https://brunch.co.kr/@huewu/4

https://charlezz.medium.com/process%EC%99%80-thread-%EC%9D%B4%EC%95%BC%EA%B8%B0-5b96d0d43e37

https://eunjinii.tistory.com/41

https://jojozhuang.github.io/programming/java-concurrency-dead-lock/

‍ ‍완전히 정복하는 프로세스 vs 스레드 개념

인파_ — Mon, 3 Apr 2023 22:24:35 +0900

한눈에 이해하는 프로세스 & 스레드 개념

전공 지식 없이 컴퓨터의 프로그램을 이용하는데는 문제 없어 왔지만 소프트웨어를 개발하는 사람으로서 컴퓨터 실행 내부 요소를 따져보게 될때, 아마 컴퓨터 운영체제에 대해 입문하게 되면 가장 먼저 듣고 배우게 될 개념이 프로세스와 스레드 일 것이다. 결론 부터 말하자면 이 둘을 한마디로 정의하자면 다음과 같다.

프로세스 (Process)	스레드 (Thread)
운영체제로부터 자원을 할당받은 작업의 단위	프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위

운영체제(OS)에 대한 기본 배경 지식이 없다면 위의 정의가 무슨 소리인지 이해가 잘 되지 않을 것이다. 그래도 위의 문장에는 나름 설명이 함축되어 잘 정리 되어 있는 셈이다. 일단 프로세스의 작업의 단위 라는 단어와 스레드의 실행 흐름의 단위 라는 단어를 기억해 두고 글을 읽어보자. 글을 정독했을때 저 단어의 의미에 대해 확실히 깨닫게 될 것이다.

프로그램 과 프로세스

정적 프로그램 (Static Program)

컴퓨터 전공이 아니라서 '프로세스' 라는 명칭은 낯설수 있는데, '프로그램' 은 친숙하리라 생각된다.

프로그램은 윈도우의 *.exe 파일이나 Mac의 *.dmg 파일과 같은 컴퓨터에서 실행 할 수 있는 파일을 통칭한다. 단, 아직 파일을 실행하지 않은 상태이기 때문에 정적 프로그램(Static Program) 줄여서 프로그램(Program)이라고 부른 것이다.

어떠한 프로그램을 개발하기 위해선 자바나 C언어와 같은 언어를 이용해 코드를 작성하여 완성된다. 즉, 프로그램은 쉽게 말해서 그냥 코드 덩어리 인 것이다.

프로세스 (Process)

프로그램이 그냥 코드 덩어리이면, 프로세스는 프로그램을 실행 시켜 정적인 프로그램이 동적(動的)으로 변하여 프로그램이 돌아가고 있는 상태를 말한다. 즉, 컴퓨터에서 작업 중인 프로그램을 의미하는 것이다.

이 개념은 절대 생소한 것이 아니다. ~~ctrl + alt + del~~ 단축키를 눌러 우리가 항상 보던 '작업' 관리자를 열어보면 개념이 고대로 들어있는걸 볼 수 있을 것이다.

작업 끝내기는 실행중인 프로그램인 프로세스를 끝내는 것이다

모든 프로그램은 운영체제가 실행되기 위한 메모리 공간을 할당해 줘야 실행될 수 있다. 그래서 프로그램을 실행하는 순간 파일은 컴퓨터 메모리에 올라가게 되고, 운영체제로부터 시스템 자원(CPU)을 할당받아 프로그램 코드를 실행시켜 우리가 서비스를 이용할 수 있게 되는 것이다.

프로그램 → 프로세스

어쨋든 똑같은 어플리케이션을 실행 하냐 안하냐 차이일 뿐이라서, 일반적으로 프로세스와 프로그램을 같은 개념으로 이야기할 때가 많지만, 정의를 보았듯이 엄밀히 따지면 이 둘은 다른 개념인 것이다.

최종적으로 이 둘을 간단 명료하게 정리하면 아래 표와 같다.

프로그램	프로세스
어떤 작업을 하기 위해 실행할 수 있는 파일	실행되어 작업중인 컴퓨터 프로그램
파일이 저장 장치에 있지만 메모리에는 올라가 있지 않은 정적인 상태	메모리에 적재되고 CPU 자원을 할당받아 프로그램이 실행되고 있는 상태
쉽게 말해 그냥 코드 덩어리	그 코드 덩어리를 실행한 것

스레드

프로세스의 한계

과거에는 프로그램을 실행할 때 프로세스 하나만을 사용해서 이용했었다. 하지만 기술이 발전됨에 따라 프로그램이 복잡해지고 다채로워짐으로써 프로세스 작업 하나만을 사용해서 프로그램을 실행하기에는 한계가 있었다.

오늘날 컴퓨터는 파일을 다운 받으며 다른 일을 하는 멀티 작업은 너무 당연한 기능이라고 생각할지 모르겠지만, 과거에는 파일을 다운받으면 실행 시작부터 실행 끝까지 프로세스 하나만을 사용하기 때문에 다운이 완료될때까지 하루종일 기다려야 했다. 그렇다고 동일한 프로그램을 여러 개의 프로세스로 만들게 되면, 그만큼 메모리를 차지하고 CPU에서 할당받는 자원이 중복되게 될 것이다. 스레드(Thread)는 이러한 프로세스 특성의 한계를 해결하기 위해 탄생 하였다.

스레드의 개념

스레드란, 하나의 프로세스 내에서 동시에 진행되는 작업 갈래, 흐름의 단위 를 말한다.

이해하기 쉽게 비유를 들자면, 크롬 브라우저가 실행 되면 프로세스 하나가 생성될 것이다. 그런데 우리는 브라우저에서 파일을 다운 받으며 온라인 쇼핑을 하면서 게임을 하기도 한다.

즉, 하나의 프로세스 안에서 여러가지 작업들 흐름이 동시에 진행되기 때문에 가능한 것인데, 이러한 일련의 작업 흐름들을 스레드라고 하며 여러개가 있다면 이를 멀티(다중) 스레드 라고 부른다.

아래 그림에서 보듯이 하나의 프로세스 안에 여러개의 스레드들이 들어 있다고 보면 된다. 스레드 수가 많을 수록 당연히 프로그램 속도도 동시에 하는 작업이 많아져 성능이 올라간다.

스레드를 지렁이 같이 표현한 이유는 번역하면 실타래 이며, 실행 흐름을 표현하기 위해서이다

일반적으로 하나의 프로그램은 하나 이상의 프로세스를 가지고 있고, 하나의 프로세스는 반드시 하나 이상의 스레드를 갖는다. 즉, 프로세스를 생성하면 기본적으로 하나의 main 스레드가 생성되게 된다. 스레드 2개, 3개.. 는 프로그램을 개발한 개발자가 직접 프로그래밍하여 위치 시켜주어야 한다. 그래서 별도로 스레드 프로그래밍 과목이 있는 이유이기도 하다.

지금까지 프로그램, 프로세스, 스레드에 관한 아주 기본적인 개념 흐름과 차이에 대해 알아보았다. 그러나 이정도의 운영체제 지식만으로는 "프로세스와 스레드의 차이에 대해 말하라는" 기술 면접에서 통과하기는 힘들 것이다.

왜냐하면 단순 프로세스와 스레드의 차이점 뿐만 아니라 프로세스와 스레드의 내부 작동 방식을 이해하고 있는지 궁금해하는 면접관이 대부분이기 때문이다. 사실 위에서 한 설명은 뉴비라도 최대한 이해하기 쉽게 풀어쓴 내용이라 저 부분만으로는 프로세스와 스레드를 이해하는데 있어 많이 부족하다. 운영체제가 시스템 자원을 어떤 방식으로 할당하고 프로그램은 자원을 어떤 방식으로 활용하는 내부 작동 방식을 이해하고 있어야, 기술 면접도 그렇고 나중에 스레드 프로그래밍 할때 응용이 가능하기 때문에 이 포스팅을 끝까지 읽는 것을 권장하는 바다.

프로세스 & 스레드의 메모리

프로세스의 자원 구조

프로그램이 실행되어 프로세스가 만들어지면 다음 4가지의 메모리 영역으로 구성되어 할당 받게 된다.

코드 영역(Code / Text) : 프로그래머가 작성한 프로그램 함수들의 코드가 CPU가 해석 가능한 기계어 형태로 저장되어 있다.
데이터 영역(Data) : 코드가 실행되면서 사용하는 전역 변수나 각종 데이터들이 모여있다. 데이터영역은 .data ,.rodata, .bss 영역으로 세분화 된다.
- .data : 전역 변수 또는 static 변수 등 프로그램이 사용하는 데이터를 저장
- .BSS : 초기값 없는 전역 변수, static 변수가 저장
- .rodata : const같은 상수 키워드 선언 된 변수나 문자열 상수가 저장
스택 영역(Stack) : 지역 변수와 같은 호출한 함수가 종료되면 되돌아올 임시적인 자료를 저장하는 독립적인 공간이다. Stack은 함수의 호출과 함께 할당되며, 함수의 호출이 완료되면 소멸한다. 만일 stack 영역을 초과하면 stack overflow 에러가 발생한다.
힙 영역(Heap) : 생성자, 인스턴스와 같은 동적으로 할당되는 데이터들을 위해 존재하는 공간이다. 사용자에 의해 메모리 공간이 동적으로 할당되고 해제된다.

위의 그림에서 Stack과 Heap 영역이 위아래로 화살표가 쳐 있는 것을 볼 수 있는데, 이는 코드 영역과 데이터 영역은 선언할 때 그 크기가 결정되는 정적 영역이지만, 스택 영역과 힙 영역은 프로세스가 실행되는 동안 크기가 늘어났다 줄어들기도 하는 동적 영역이기 때문에 이를 표현한 것이다.

아래 그림을 보면서 간략히 정리하자면, 프로그램이 여러개 실행된다면 메모리에 프로세스들이 담길 주소 공간이 생성되게 되고 그 안에 Code, Data, Stack, Heap 공간이 만들어지게 된다.

스레드의 자원 공유

스레드는 프로세스가 할당 받은 자원을 이용하는 실행의 단위로서, 스레드가 여러개 있으면 우리가 파일을 다운 받으며 동시에 웹 서핑을 할 수 있게 해준다. 스레드끼리 프로세스의 자원을 공유하면서 프로세스 실행 흐름의 일부가 되기 때문에 동시 작업이 가능한 것이다. 그래서 아래 사진과 같이 하나의 프로세스 내에 여러개의 스레드가 들어있는 상태인 것이다.

이때 프로세스의 4가지 메모리 영역(Code, Data, Heap, Stack) 중 스레드는 Stack만 할당받아 복사하고 Code, Data, Heap은 프로세스내의 다른 스레드들과 공유된다. 따라서 각각의 스레드는 별도의 stack을 가지고 있지만 heap 메모리는 고유하기 때문에 서로 다른 스레드에서 가져와 읽고 쓸 수 있게 된다.

stack은 함수 호출 시 전달되는 인자, 되돌아갈 주소값, 함수 내에서 선언하는 변수 등을 저장하는 메모리 공간이기 때문에, 독립적인 스택을 가졌다는 것은 독립적인 함수 호출이 가능하다 라는 의미이다. 그리고 독립적인 함수 호출이 가능하다는 것은 독립적인 실행 흐름이 추가된다는 말이다.
즉, stack을 가짐으로써 스레드는 독립적인 실행 흐름을 가질 수 있게 되는 것이다.

반면에 프로세스는 기본적으로 프로세스 끼리 다른 프로세스의 메모리에 직접 접근할 수는 없다.

이렇게 구성한 이유는 하나의 프로세스를 다수의 실행 단위인 스레드로 구분하여 자원을 공유하고, 자원의 생성과 관리의 중복성을 최소화하여 수행 능력을 올리기 위해서다.

프로세스의 자원 공유

기본적으로 각 프로세스는 메모리에 별도의 주소 공간에서 실행되기 때문에, 한 프로세스는 다른 프로세스의 변수나 자료구조에 접근할 수는 없다. 그렇다면 프로세스는 영원히 다른 프로세스 정보에 접근할 수 없을까?

현재 우리가 사용하는 대부분의 컴퓨터 프로그램을 보면 다른 프로그램에 있는 정보를 가져오는 경우는 심심치 않게 볼 수 있을 것이다. 이처럼 특별한 방법을 통해 프로세스가 다른 프로세스의 정보에 접근하는 것이 가능하다. 프로세스 간 정보를 공유하는 방법에는 다음과 같은 방법들이 있다.

IPC(Inter-Process Communication) 사용
LPC(Local inter-Process Communication) 사용
별도로 공유 메모리를 만들어서 정보를 주고받도록 설정

그러나 프로세스 자원 공유는 단순히 CPU 레지스터 교체뿐만이 아니라 RAM과 CPU 사이의 캐시 메모리까지 초기화되기 때문에 자원 부담이 크다는 단점이 있다. 그래서 다중 작업이 필요한경우 스레드를 이용하는 것이 훨씬 효율적이라, 현대 컴퓨터의 운영체제에선 다중 프로세싱을 지원하고 있지만 다중 스레딩을 기본으로 하고 있다.

프로세스 & 스레드의 동시 실행 원리

우리가 음악을 들으면서, 웹서핑을 하고, 메신저의 메시지를 확인할 수 있는 이유는 컴퓨터 내부적으로 프로세스와 스레드를 동시에 처리하는 멀티 태스킹(multi tasking) 기술 때문이다. 하지만 여기서 동시에 처리한다는 것이 심플하게 CPU 프로세서가 프로그램들을 한꺼번에 동시에 돌리는 것으로 생각하겠지만, 내부적으로 복잡한 원리에 의해 처리가 된다. 그리고 이 원리가 운영체제 이론의 핵심 원리이기도 하다. 지금부터 그 원리에 대해 파헤쳐 보도록 하자.

멀티 코어와 스레드

한번 컴퓨터 견적을 맞춰본 경험이 있는 독자분들은 4코어 8쓰레드 CPU에 대한 단어를 본 적이 있을 것이다.

CPU 한 개는 여러개의 코어를 가질수 있다. 코어는 말그대로 CPU 코어 유닛이다. 즉, 명령어를 메모리에서 뽑아 해석하고 실행하는 반도체 유닛이 4개가 있는 것이다. 4코어가 물리적 코어 갯수면, 8쓰레드는 논리적 코어 갯수를 말한다. 이 경우 물리적 코어 하나가 스레드 두 개 이상을 동시에 실행 가능하다는 의미가 된다. 즉, 운영체제가 8개의 작업을 동시에 처리할 수 있다는 뜻이다. 이를 하이퍼스레딩(Hyper-Threading) 기술이라 말한다.

단, 여기서 CPU의 쓰레드는 우리가 배운 프로세스의 쓰레드와는 조금 다른 개념이다. 엄밀히 말하자면 CPU의 스레드는 하드웨어적 스레드이고 프로그램의 스레드는 소프트웨어적 스레드로 구분한다.

그런데 우리는 컴퓨터를 이용할때 프로그램을 수십, 수백개를 켜 놓고 이용한다. 그럼 그 수십수백개의 프로세스들을 고작 8개의 논리적인 스레드도 어떻게 처리하는 것일까?

이 원리를 알기위해선 병렬성(Parallelism) 과 동시성(Concurrency)이라는 개념을 알고 있어야 한다. 이 개념은 운영체제의 프로세스, 스레드를 이해하는데 있어 가장 핵심 골자가 되는 녀석들이다.

CPU의 작업 처리 방식

병렬성 (Parallelism)

병렬성은 직관적으로 명령어를 메모리에서 뽑아 해석하고 실행하는 반도체 유닛인 여러개의 코어에 맞춰 여러개의 프로세스, 스레드를 돌려 병렬로 작업들을 동시 수행하는 것을 말한다.

듀얼코어, 쿼드코어, 옥타코어 등등 이런 명칭이 붙는 멀티코어 프로세서가 달린 컴퓨터에서 할 수 있는 방식이다.

동시성 (Concurrency)

동시성은 둘 이상의 작업이 동시에 실행되는 것을 의미한다. 이 '동시' 라는 의미에서 병렬성과 동시성의 한글 의미가 헷갈릴수 있다. Parallelism가 물리적으로 정말로 동시에 실행하는 것이라고 하면, Concurrency는 동시에 실행하는 것처럼 보이게 하는 것으로 이해하면 된다.

즉, 1개의 코어가 있고 4개의 작업이 있다고 가정하다면, 아래 그림과 같이 프로세스들을 계속 번갈아가면서 조금씩 처리함으로써 마치 프로그램이 동시에 실행되는 것 처럼 보이는 것이다. 이때 프로세스들을 번갈아가면서 매우 빠르게 처리하기 때문에 컴퓨터를 모르는 사람들이 보면 마치 동시에 돌아가는 것처럼 보이게 된다.

단, 이때 작업들을 번갈아가면서 실행할때 작업들을 아주 잘게 나누어 아주 조금씩만 작업을 수행하고 다음 작업으로 넘어가는 식으로 동작된다. 이렇게 하는 이유는 여러 작업을 동시에 처리하는 것처럼 보이게 만들어, 사용자에게 더 빠른 반응성을 제공하기 위해서다. 그리고 이렇게 진행 중인 작업들을 A → B → C → D 로 번갈아 바꾸는 것을 Context Switching 이라고 부른다.

각 프로세스 작업을 작게 쪼개어 번갈아 처리

동시성이 필요한 이유

그런데 상식적으로 생각해보면 동시성(Concurrency)은 '동시에 돌아가는 것 처럼' 보이는 거지, 정말 실제로 동시에 돌아가는 것이 아니기 때문에 최종 작업이 걸리는 시간은 거의 차이가 없을 것이다. 병렬성은 정말로 각 코어에 프로세스를 나눠 실행하는 거니까 듀얼 코어면 반 이상 줄어들텐데 말이다. 그렇다면 왜 이렇게 번거롭게 작업들을 스위칭 하며 처리하는 것일까?

첫번째는 하드웨어적 한계 때문이라고 할 수있다. CPU 발열 때문에 깡 클럭으로 성능을 올리기에는 한계에 봉착됬기 때문에 코어의 성능을 올리는 대신 코어를 여러개 탑재하여 쿼드 코어, 옥타 코어 CPU들을 출시하고 있다. 하지만 아무리 코어를 많이 넣어도 수십개의 코어를 넣은순 없으니 결국 하드웨어적 제한이 걸리게 되고 수십수백개의 프로세스를 돌리기 위해선 결국 동시성이 필요한 것이다.

두번째는 보다 논리적인 효율적인 이유에서이다. 4코어 8스레드의 CPU 환경에서 현재 총 16개의 작업이 있다고 가정을 해보자. 그중 8개는 오래 걸리는 작업이고, 나머지 8개는 짧은 시간을 필요로 하는 작업이라고 한다. 논리적인 8개의 코어이니 최대 8개까지 동시에 실행할수 있을텐데, 만일 최악의 경우 8개의 오래 걸리는 작업이 먼저 동시에 처리되기 시작했다고 하자. 이 경우 나머지 가벼운 8개의 작업은 처리하는데 짧은 시간이 걸리는 데에도 불구하고 현재 처리중인 8개의 작업이 다 끝날때 까지 기다려야 할 것이다. 따라서 이러한 비효율적인 면을 극복하기 위해 작업을 아주 잘게 나눠 번갈아 가면서 처리하는 동시성 개념을 채택한 것이다.

따라서 최대 8개의 작업에 대해서 8개의 논리적인 스레드가 병렬적으로 아주 빠르게 동시적으로 작업을 하면서, 그보다 많은 수십개의 소프트웨어적 스레드가 있다면 적절히 병렬성과 동시성을 섞어 동시에 돌리게 되게 된다.

프로세스 & 스레드의 생명 주기

프로세스와 스레드는 각각의 생명 주기를 가지고 있으며, 운영체제는 이러한 생명 주기를 관리하고, 프로세스와 스레드를 조정하여 시스템 자원을 효율적으로 사용할 수 있게 된다.

프로세스 스케쥴링

프로세스 스케줄링(Process Scheduling)은 운영체제에서 CPU를 사용할 수 있는 프로세스를 선택하고, CPU를 할당하는 작업을 말한다. 프로세스 스케줄링은 프로세스의 우선순위, 작업량 등을 고려하여 효율적으로 배치하여, 이를 통해 운영체제는 CPU를 효율적으로 사용하며 시스템 전반적인 성능을 향상시킨다. 그래서 스케줄링은 멀티 태스킹 작업을 만들어내는 데에 있어서 핵심적인 부분이다.

스케쥴링은 운영체제의 특징과 시스템 요구사항에 따라 다양한 알고리즘 방식으로 동작된다. 알고리즘 종류로는 대표적으로 FCFS(First-Come, First-Served), SJF(Shortest-Job-First), Priority, RR(Round-Robin), Multilevel Queue 등이 있다.

프로세스 상태

프로세스의 상태는 프로세스가 실행되는 동안 변경되는 고유 상태를 의미한다. 프로세스가 생성되어 실행하기 까지 프로세스는 여러가지의 상태를 갖게 되고, 상태의 변화에 따라 프로세스가 동작되는 것이다. 프로세스는 일반적으로 다음과 같은 5가지 상태를 가진다.

프로세스 상태	설명
생성 (new)	프로세스가 생성되고 아직 준비가 되지 않은 상태
준비 (ready)	프로세스가 실행을 위해 기다리는 상태 CPU를 할당받을 수 있는 상태이며, 언제든지 실행될 준비가 되어있다.
실행 (running)	프로세스가 CPU를 할당받아 실행되는 상태
대기 (waiting)	프로세스가 특정 이벤트(입출력 요청 등)가 발생하여 대기하는 상태 CPU를 할당받지 못하며, 이벤트가 발생하여 다시 READY 상태로 전환될 때까지 대기한다.
종료 (terminated)	프로세스가 실행을 완료하고 종료된 상태 더 이상 실행될 수 없으며, 메모리에서 제거되게 된다.

프로세스 상태 전이

프로세스 상태 전이란 프로세스가 실행되는 동안 상태가 OS에 의해 변경되는 것을 말한다. 운영체제는 프로세스의 상태를 감시하고, 프로세스 상태를 기반으로 프로세스 스케쥴링을 통해프로세스를 관리하고 제어한다. 예를 들어, READY 상태에 있는 여러 프로세스 중에서 어떤 프로세스를 RUNNING 상태로 바꿀지, TERMINATED 상태에 있는 프로세스를 제거하고 READY 상태에 있는 다른 프로세스를 선택할지 스케쥴링 알고리즘에 의해 동작된다.

Admitted (new → ready) : 프로세스 생성을 승인 받음
Dispatch (ready→ running) : 준비 상태에 있는 여러 프로세스들 중 하나가 스케줄러에 의해 실행됨
Interrupt (running → ready) : Timeout, 예기치 않은 이벤트가 발생하여 현재 실행 중인 프로세스를 준비 상태로 전환하고, 해당 작업을 먼저 처리
I/O or event wait (running → wainting) : 실행 중인 프로세스가 입출력이나 이벤트를 처리해야 하는 경우, 입출력이나 이벤트가 끝날 때까지 대기 상태로 전환
I/O or event completion (waiting → ready) : 입출력이나 이벤트가 모두 끝난 프로세스를 다시 준비 상태로 만들어 스케줄러에 의해 선택될 수 있는 상태로 전환

프로세스 컨텍스트 스위칭

컨텍스트 스위칭(Context Switching)은 CPU가 한 프로세스에서 다른 프로세스로 전환할 때 발생하는 일련의 과정을 말한다. 위의 동시성 (Concurrency) 파트에서 다뤘듯이 CPU는 한 번에 하나의 프로세스만 실행할 수 있으므로, 여러 개의 프로세스를 번갈아가며 실행하여 CPU 활용률을 높이기 위해 컨텍스트 스위칭이 필요한 것이다.

컨텍스트 스위칭을 좀더 구체적으로 말하자면, 동작 중인 프로세스가 대기를 하면서 해당 프로세스의 상태(Context)를 보관하고, 대기하고 있던 다음 순서의 프로세스가 동작하면서 이전에 보관했던 프로세스의 상태를 복구하는 작업을 말한다. 이러한 컨텍스트 스위칭이 일어날 때 다음번 프로세스는 스케줄러가 결정하게 된다. 즉, 컨텍스트 스위칭을 하는 주체는 스케줄러이다.

PCB (Process Control Block)

PCB(프로세스 제어 블록)는 운영체제에서 프로세스를 관리하기 위해 해당 프로세스의 상태 정보를 담고 있는 자료구조를 말한다.

프로세스를 컨텍스트 스위칭 할때 기존 프로세스의 상태를 어딘가에 저장해 둬야 다음에 똑같은 작업을 이어서 할 수 있을 것이고, 새로 해야 할 작업의 상태 또한 알아야 어디서부터 다시 작업을 시작할지 결정할 수 있을 것이다. 즉, PCB는 프로세스 스케줄링을 위해 프로세스에 관한 모든 정보 저장하는 임시 저장소인 것이다.

PCB는 프로세스의 생성과 동시에 만들어진다

따라서 운영체제는 PCB에 담긴 프로세스 고유 정보를 통해 프로세스를 관리하며, 프로세스의 실행 상태를 파악하고, 우선순위를 조정하며, 스케줄링을 수행하고, 다른 프로세스와의 동기화를 제어한다.

운영체제에 따라 PCB에 포함되는 항목이 다를 수 있지만 일반적으로 PCB내 에는 다음과 같은 정보가 포함되어 있다.

PCB 메모리

포인터 (Pointer) : 프로세스의 현재 위치를 저장하는 포인터 정보
프로세스 상태 (Process state) : 프로세스의 각 상태 - 생성(New), 준비(Ready), 실행(Running), 대기(Waiting), 종료(Terminated) 를 저장
프로세스 아이디 (Process ID, PID) : 프로세스 식별자를 지정하는 고유한 ID
프로그램 카운터 (Program counter) : 프로세스를 위해 실행될 다음 명령어의 주소를 포함하는 카운터를 저장
레지스터 (Register) : 누산기, 베이스, 레지스터 및 범용 레지스터를 포함하는 CPU 레지스터에 있는 정보
메모리 제한 (Memory Limits) : 운영 체제에서 사용하는 메모리 관리 시스템에 대한 정보
열린 파일 목록 (List of open file) : 프로세스를 위해 열린 파일 목록

Context Switching 과정

두 개의 프로세스 간에 컨텍스트 스위칭 과정을 그림으로 표현한 것이다.

CPU는 Process P1을 실행한다 (Executing)
일정 시간이 지나 Interrupt 또는 system call이 발생한다. (CPU는 idle 상태)
현재 실행 중인 Process P1의 상태를 PCB1에 저장한다. (Save state into PCB1)
다음으로 실행할 Process P2를 선택한다. (CPU 스케줄링)
Process P2의 상태를 PCB2에서 불러온다. (Reload state from PCB2)
CPU는 Process P2를 실행한다. (Executing)
일정 시간이 지나 Interrupt 또는 system call이 발생한다. (CPU는 idle 상태)
현재 실행 중인 Process P2의 상태를 PCB2에 저장한다. (Save state into PCB2)
다시 Process P1을 실행할 차례가 된다. (CPU 스케줄링)
Process P1의 상태를 PCB1에서 불러온다. (Reload state from PCB1)
CPU는 Process P1을 중간 시점 부터 실행한다. (Executing)

idle(대기) 과 executing(실행) 은 CPU의 동작 상태를 나타낸 것이다

Context Switching Overhead

이러한 컨텍스트 스위칭 과정은 사용자로금 빠른 반응성과 동시성을 제공하지만, 실행되는 프로세스의 변경 과정에서 프로세스의 상태, 레지스터 값 등이 저장되고 불러오는 등의 작업이 수행하기 때문에 시스템에 많은 부담을 주게된다.

위의 컨텍스트 스위칭 과정 그림을 보면 P1이 Execute에서 idle이 될 때 P2가 바로 Execute가 되지 않고 idle을 상태에 조금 있다가 Execute가 되는걸 볼 수 있다. 이 간극이 바로 컨텍스트 스위칭 오버헤드(overhead) 인 것이다.

컨텍스트 스위칭 오버헤드는 대표적으로 다음과 같은 행위에 의해서 발생된다.

PCB 저장 및 복원 비용
CPU 캐시 메모리 무효화에 따른 비용
프로세스 스케줄링 비용

컨텍스트 스위칭 과정에서 PCB를 저장하고 복원하는데 비용이 발생하며, 프로세스 자체가 교체되는 것이니 CPU의 캐시 메모리에 저장된 데이터가 무효화가 된다. 이 과정에서는 메모리 접근 시간이 늘어나고, 성능 저하가 발생할 수 있다. 또한 CPU 스케줄링 알고리즘에 따라 프로세스를 선택하는 비용도 만만치 않다.

바로 뒤에서 다루겠지만, 컨텍스트 스위칭은 꼭 프로세스 뿐만 아니라 여러개의 스레드들 끼리도 스위칭이 일어난다. 보통 멀티 스레드라고 하면 여러개의 스레드가 동시에 돌아가니 프로그램 성능이 무조건 상승할거라 예상하지만, 이는 정확하지 않다. 컨텍스트 스위칭 오버헤드라는 변수 때문에 스레드 교체 과정에서 과하게 오버헤드가 발생하면 오히려 멀티 스레드가 싱글 스레드보다 성능이 떨어지는 현상이 나타날수 있기 때문이다.

스레드를 많이 쓸수록 항상 성능이 좋아질까?

스레드를 많이 쓰면 쓸수록 성능이 높아지는가 프로세스와 스레드를 처음 학습할때, 스레드는 프로세스 내에 존재하는 실행 단위이며, 이 스레드가 여러개인 덕분에 우리가 음악을 들으며 웹서

inpa.tistory.com

스레드 스케쥴링

프로세스 스케쥴링과 마찬가지로, 스레드 스케줄링(Thread Scheduling)은 운영체제에서 다중 스레드를 관리하며, CPU를 사용할 수 있는 스레드를 선택하고, CPU를 할당하는 작업을 말한다.

스레드의 우선순위, 실행 시간, 입출력 요청 등의 정보를 고려하여 CPU를 사용할 수 있는 스레드를 선택하는, 스레드 스케줄링 알고리즘은 프로세스 스케줄링 알고리즘과 유사하게 동작한다. 다양한 알고리즘이 있으며, 대표적으로는 Round Robin, Priority-based scheduling, Multi-level Queue scheduling 등이 있다.
다만 스레드 스케줄링은 프로세스 스케줄링과 다르게, 하나의 프로세스 내에서 다수의 스레드가 동작하는 형태이기 때문에, 스레드 간의 상호작용과 동기화 문제를 고려해야 한다는 차이점이 존재한다.

스레드 상태

프로세스 상태와 마찬가지로, 스레드에도 상태가 있다. 일반적으로 다음과 같은 4가지 상태를 가진다.

스레드 상태	설명
NEW	스레드가 생성되고 아직 호출되지 않은 상태
RUNNABLE	스레드가 실행되기 위해 기다리는 상태 CPU를 할당받을 수 있는 상태이며, 언제든지 실행될 준비가 되어있다.
BLOCKED	스레드가 특정 이벤트(입출력 요청 등)가 발생하여 대기하는 상태 CPU를 할당받지 못하며, 이벤트가 발생하여 다시 RUNNABLE 상태로 전환될 때까지 대기한다.
TERMINATED	스레드가 실행을 완료하고 종료된 상태 더 이상 실행될 수 없으며, 메모리에서 제거된다.

스레드 상태 전이

스레드 상태 전이에 대한 제어는 자바와 같은 스레드 프로그래밍에서 자세히 다루게 될 것이다.

실제로는 더 복잡하다

스레드 컨텍스트 스위칭

스레드 컨텍스트 스위칭(thread context switching)은 멀티 스레딩 환경에서 스레드 간의 실행을 전환하는 기술이다. 프로세스 컨텍스트 스위칭과 다른점은 스레드 컨텍스트 스위칭은 하나의 프로내스 내의 스레드들을 교환한다는 점이다.

TCB (Thread Control Block)

PCB 처럼, TCB(스레드 제어 블록)는 각 스레드마다 운영 체제에서 유지하는 스레드에 대한 정보를 담고 있는 자료구조이다. 그림에서 볼 수 있듯이 TCB는 PCB 안에 들어있다. 스레드가 프로세스 내에 위치한 것 처럼 말이다.

PCB와 TCB는 LinkedList로 구현되어 있다

역시 스레드의 상태 정보, 스레드 ID, 스레드 우선순위, 스케줄링 정보 등 다양한 정보를 저장한다. TCB도 스레드가 생성될 때 운영 체제에 의해 생성되며, 스레드가 실행을 마치고 소멸될 때 함께 소멸된다.

또한 스레드 간의 자원 공유와 동기화도 TCB를 사용하여 관리된다. 예를 들어, 뮤텍스(mutual exclusion)나 세마포어(semaphore)와 같은 동기화 기법을 사용할 때, TCB에서 해당 스레드의 뮤텍스나 세마포어 정보를 관리하고, 스레드가 해당 자원에 대한 접근 권한을 획득하거나 반납할 때 TCB의 정보를 업데이트하게 된다.

뮤텍스(mutex)
임계 구역에 1개의 스레드만 들어갈 수 있는 동기화 기법.

세마포어(semaphore)
임계 구역에 여러 스레드가 들어갈 수 있고, counter를 두어서 허용 가능한 스레드를 제한하는 기법

프로세스 컨텍스트 스위칭 vs 스레드 컨텍스트 스위칭

프로세스 컨텍스트 스위칭과 스레드 컨텍스트 스위칭은 모두 멀티태스킹 환경에서 여러 프로세스 또는 스레드를 동시에 실행하기 위한 기술이다. 그러나 두 기술은 몇 가지 차이점이 있다.

1. TCB가 PCB보다 가볍다

결론부터 말하자면, 스레드 컨텍스트 스위칭이 프로세스 컨텍스트 스위칭보다 더 빠르다.

위에서 프로세스와 스레드의 메모리 섹션에서 다뤘듯이, 프로세스 내의 스레드들은 text, data, heap 영역 메모리를 공유하기 때문에 TCB에는 stack 및 간단한 register 포인터 정보만을 저장하기 때문에 PCB보다 TCB가 가벼워 더 빨리 읽고 쓸수 있다.

2. 캐시 메모리 초기화 여부

CPU 캐쉬 메모리는 CPU와 메인 메모리 사이에 위치하며 CPU에서 한번 이상 읽어들인 메모리의 데이터를 저장하고 있다가, CPU가 다시 그 메모리에 저장된 데이터를 요구할 때, 메인 메모리를 통하지 않고 곧바로 데이터를 전달해 주는 용도이다.

그런데 프로세스 컨텍스트 스위칭이 일어날 경우, 다른 프로세스의 실행으로 인해 CPU가 새로운 명령어와 데이터를 로드해야 하기 때문에 CPU 캐시 메모리를 초기화 하여야 한다. 이것이 프로세스 컨텍스트 스위칭에 부담이 되는 요소이다.

스레드 컨텍스트 스위칭일 경우, 프로세스 내 스레드 간에 스택과 레지스터 값 등 일부 컨텍스트 정보만 변경되므로 CPU 캐시 메모리는 초기화되지 않는다. 다만 스레드가 다른 CPU 코어에서 실행될 때는 해당 코어의 캐시 메모리에 스레드 컨텍스트 정보가 로드되어야 하므로 초기화될 수 있다.

3. 자원 동기화 문제

스레드 컨텍스트 스위칭이 발생해 다른 스레드가 heap 영역의 공유 데이터에 접근할때, 이전 스레드가 이미 공유 자원을 사용하고 있는 경우 동기화 문제가 발생할 수 있다. 예를 들어, 두 개의 스레드가 동시에 하나의 변수를 수정하려고 할 때, 스레드 컨텍스트 스위칭이 발생하면 변수의 값을 잘못된 값으로 업데이트 할 수 있는 것이다. 이것을 스레드 간에 경쟁 조건 (race condition)이라고 한다.

프로세스는 기본적으로 독립된 공간이지만, IPC와 같은 공유 자원을 사용하는 경우에 똑같이 경쟁 조건이 발생 할 수가 있다. 예를 들어, 여러 개의 프로세스가 동시에 파일 시스템에 접근하여 파일을 수정하려고 할 때, 컨텍스트 스위칭이 발생할 때 다른 프로세스가 그 파일에 접근할 수 있기 때문에 파일 내용이 손상될 수 있다.

따라서 이들을 해결하기 위해선 각 상황에 적절한 공유 자원에 대한 동기화 메커니즘이 필요해진다.

Multi Process 와 Multi Thread

멀티 프로세스와 멀티 스레드는 한 어플리케이션에 대한 처리방식 이라고 보면 된다. 이름으로 유추할 수 있듯이 멀티 프로세스와 멀티 스레드는 여러개의 프로세스, 스레드가 동작하는 것을 일 컫는다.

예상할 수 있듯이, 프로세스와 스레드가 단일이 아닌 다중으로 돌아감으로써 성능 향상 등 여러가지 효과를 얻을 수 있게 된다. 하지만 또한 이로 인해 발생되는 부가적인 문제점도 발생하게 된다. 따라서 각각의 장단점을 파악하여 적재적소에 사용하는 것이 요구된다. 멀티 프로세스와 멀티 스레드 구성의 자세한 장단점에 대한 비교는 아래 포스팅을 참고하길 바란다.

‍ 멀티 프로세스 vs 멀티 스레드 장단점 완벽 정복

멀티 프로세스와 멀티 스레드는 한 어플리케이션에 대한 처리방식 이라고 보면 된다. 단순히 프로그램을 여러개 띄워놓는 것이 멀티 프로세스가 아니라 이 둘은 언제 어느때에 어떤 방식으로

inpa.tistory.com

# 참고자료

https://youtu.be/1grtWKqTn50

https://youtu.be/QmtYKZC0lMU

https://www.youtube.com/watch?v=iks_Xb9DtTM

https://zangzangs.tistory.com/109

https://wookkingkim.tistory.com/m/4

https://badcandy.github.io/2019/01/14/concurrency-01/

https://fastcampus.co.kr/media_branding_cs

https://lotuus.tistory.com/92

https://www.crocus.co.kr/1364

https://velog.io/@ssh1997/CS-Process-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4

https://velog.io/@curiosity806/Context-Switching%EC%9C%BC%EB%A1%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EB%8A%94-process%EC%99%80-thread

https://blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=jhc9639&logNo=221707378026

console.log는 이제 그만 ❗ - 다양한 콘솔 API 모음

인파_ — Mon, 3 Apr 2023 10:26:26 +0900

자바스크립트 Console API

자바스크립트의 코드의 결과값을 출력하거나 테스트를 하기 위해 ~~console.log()~~ 함수를 정말 많이 써왔을 것이다. 이때 ~~console.log()~~ 함수는 console 이라는 객체 안의 ~~log()~~ 라는 메서드를 불러다가 쓴 것이다. 즉, console 객체 내에는 log 뿐만 아니라 여러 기능을 하는 콘솔 관련 메서드들이 있는 것이다. 이 콘솔 메서드들은 log 보다 훨씬더 강력하고 다채로운 기능을 제공한다. 다만 익숙치 않아서 지금까지 log 만 주궁장창 써왔던 것이다. 지금 부터 강력한 자바스크립트 콘솔 API 유용한 기능에 대해 알아보자.

console.log("콘솔 로그") 
console.info("콘솔 정보") 
console.debug("콘솔 디버그") 
console.warn("콘솔 경고") 
console.error("콘솔 오류")
console.table("콘솔 테이블")
console.group("콘솔 그룹")
console.time("콘솔 타이머")
console.count("콘솔 카운드")

console.log

기본적으로 인자로 전달된 값들을 화면으로 출력해준다. 이때 콤마(,)를 통해 출력하고 싶은 여러개의 인자를 집어 넣을 수 있다. 콤마를 통해 출력값을 이을 경우 별다른 개행 문자 없이 자동으로 띄어쓰기 해준다.

const a = 1;
const b = 'hello';
const c = true;

console.log(a); // 하나만 로그
console.log(a, b, c); // 여러 개를 동시에 로그

문자열 포맷팅

C언어나 Java를 먼저 해본 분이라면 아마 ~~printf()~~ 라는 메서드를 잘 알 것이다. 이 메서드는 첫번째 문자열 내의 %d 와 %s 같은 치환자를 콤마 뒤에 입력한 인자로 매칭하여 변환시킨다.

System.out.printf("Hello my name is %s", "인파");

치환 문자열	설명
%o 또는 %O	JavaScript 객체를 출력합니다. 객체 이름을 클릭하면 검사기에 더 자세한 정보를 보여줍니다.
%d 또는 %i	정수를 출력합니다. 서식도 지원합니다. 예를 들어 console.log("Foo %.2d", "1.1")은 정수부를 0이 앞서는 두 자리로 표현하므로 Foo 01 을 출력합니다.
%s	문자열을 출력합니다.
%f	부동소수점 수를 출력합니다. 서식도 지원합니다. 예를 들어 console.log("Foo %.2f", "1.1")은 소수부를 두 자리로 표현하므로 Foo 1.10 을 출력합니다.

다만 요즘에는 템플릿 리터럴 문법으로 ~~console.log(`${a}는 숫자 ${b}는 문자열`)~~ 와 같이 사용하는 것을 선호하는 편이다.

const a = 1;
const b = 'hello';

// 문자열 포매팅
console.log('%d는 숫자 %s는 문자열', a, b); 

// 템플릿 문자열
console.log('${a}는 숫자 ${b}는 문자열');

출력 스타일링

html 요소를 스타일링 해주기 위해 css 를 가미하듯이 이와 비슷하게 콘솔 출력물 자체에 css를 적용할 수 가 있다.

위에서 본 문자열 포매팅 문법으로 스타일링을 뜻하는 기호는 %c 를 이용해, 콤마 다음으로 css 문법을 인라인으로 그대로 적어 주면 된다.

console.log("This is %cMy stylish message", "color: yellow; font-style: italic; background-color: blue; padding: 2px");

console.log("%cText color is green and increased font size", "color: green; font-size: 2rem;")

다중 출력 스타일

%c 를 여러 번 사용하여 각 문자마다 스타일링을 적용할 수 가 있다.

console.log("Multiple styles: %cred %corange", "color: red", "color: orange", "Additional unformatted message");

출력 스타일 모듈화

만일 위와 같은 방식이 가독성 측면에 좋지 않으면 다음과 같이 배열로 css 를 지정하는 식으로도 응용이 가능하다.

배열을 선언하고 각 배열 인자에 문자열로 css 문법을 기재한다.
그리고 이들을 ~~String.join~~ 시켜 배열을 하나의 문자열로 치환하시킨다.
이때 인자마다 끝에 ; 기호를 첨가해준다. 인라인으로 css 속성이 여러개 있을 경우 ; 로 구분해 주어야 되기 때문이다.
그러면 결과로 하나의 문자열로 된 css 문법이 반환되게 되는 식이다.

let styles = [
    'background: linear-gradient(#D33106, #571402)', 
    'border: 1px solid #3E0E02',
    'color: white',
    'display: block',
    'text-shadow: 0 1px 0 rgba(0, 0, 0, 0.3)',
    'box-shadow: 0 1px 0 rgba(255, 255, 255, 0.4) inset, 0 5px 3px -5px rgba(0, 0, 0, 0.5), 0 -13px 5px -10px rgba(255, 255, 255, 0.4) inset',
    'line-height: 40px',
    'text-align: center',
    'font-weight: bold'
].join(';'); // 각 배열 인자들을 join 시켜 하나의 문자열로 치환하고 인자마다 끝에 ; 기호를 첨가해준다

console.log('%c a spicy log message ?', styles);

객체 형식으로 출력

만일 다음과 같이 각 변수의 값을 모두 출력하기 위해 우리는 지금까지 아래와 같이 사용해왔을 것이다.

const name = 'fatfish'
const age = 24
const job = 'Front end development engineer'
const hobbies = 'read, write article'

console.log(name, age, job, hobbies)

다만 이렇게 무지성으로 나열할 경우, 출력할 인자가 많아질 수록 몇번째의 값이 어떤 인자값인지 혼동스러울때가 있다. 이때는 구조 분해 문법으로 그대로 콘솔 로그 인자에 넣어주면 콘솔 화면에 객체 형식으로 포매팅하여 출력해주게 된다.

console.log({ name, age, job, hobbies })

콘솔 로그의 함정 & 주의점

브라우저의 ~~console.log~~ 를 사용할때 주의해야할 점이 있다. 예를들어 다음 예제가 콘솔에 어떻게 표시될지 예상해보자.

var obj = {};

console.log(obj);

obj.a = 1;

콘솔이 출력되는 라인은 아직 ~~obj~~ 에 값을 넣기 전이니 당연히 결과값이 {} 빈값이 출력이 될 것이다.

그런데 아래 화살표를 눌러보면, 아래와 같이 값이 a: 1 이 들어가 있음을 볼 수 있다. 즉, 결과값이 무언가 이상하게 짬뽕이 되어버린 것이다.

이러한 현상이 일어나는 이유는, ~~console.log~~는 참조를 로깅하기 때문에 객체와 같이 내용물이 변할 수 있는 것들은 내용이 실시간으로 바뀌기 때문이다.

객체 뿐만 아니라 배열도 마찬가지이다.

var arr = [];

console.log(arr, arr.length);

// 복잡한 코드가 있다고 가정

setTimeout(function() { // 비동기 가정
  arr.push(5);
}, 0);

비동기를 통해 배열값 push를 후처리 하였기 때문에 당장 콘솔 결과값은 빈배열에 배열 length는 0이지만, 화살표를 눌러 안의 내용을 살펴보면 첫번째 인덱스 값이 들어가 있고 length 역시 1로 찍혀져 있는 걸 볼 수 있다.

이밖의 콘솔 자매들

직접 스타일링 해주는 것도 좋지만 아래 미리 제공하는 콘솔 API 들도 이용하면 유용하다.

~~console.log~~ : 아이콘이 없는 검은색 텍스트
~~console.info~~ : 진한 텍스트
~~console.debug~~ : 파란색 텍스트
~~console.warn~~ : 아이콘이 있는 노란색 텍스트
~~console.error~~ : 아이콘이 있는 빨간색 텍스트

단, 브라우저 종류마다 출력되는 스타일은 약간 다르다는 점은 유의하자

var playerOne = 120;
var playerTwo = 130;
var playerThree = 140;
var playerFour = 150;
var playerFive = 160;

console.log("Console.log" + " " +  playerOne);
console.debug("Console.debug" + " " +playerTwo);
console.info("Console.info" + " " + playerFour);
console.warn("Console.warn" + " " + playerThree);
console.error("Console.error" + " " + playerFive);

크롬 콘솔 출력 화면

이때 ~~console.error~~ 와 ~~console.warn~~ 은 단순한 값 출력 뿐만 아니라 문제가 발생하는 코드 라인 스택을 표시한다는 점에서 기능상 차이를 보인다.

보통 catch 문과 같이 오류 메세지를 콘솔 화면에 출력하기 위해 에러 내용을 습관적으로 ~~console.log~~ 로 처리하는 사람들이 있는데, 그릇된 방법은 아니지만 이보다 ~~console.error~~ 메서드를 사용하는 것이 훨씬 현명하다. 왜냐하면 ~~console.warn~~과 같이 붉은색 배경에 기호 출력 뿐만 아니라 누적된 함수 호출 스택을 콘솔 화면에 표시해 주기 때문이다.

const a = () => {
  console.error("error");
}
const b = () => {
  a()
}
const c = () => {
  b()
}

c()

console.assert

assert는 error와 같이 동작하지만 첫번째 인수가 false인 경우에만 메시지 및 스택 추적을 콘솔에 기록한다. 첫 번째 인수가 true이면 아무 작업도 수행하지 않는다.

그냥 if문 과 ~~console.error~~ 문을 좀더 코드 한 줄로 심플하게 처리하기 위해 있는 것으로 보면 된다.

let name = "inpa";
let msg = 2;

console.assert(typeof msg === 'number', { name, msg: msg }); // 출력 안함

msg = "2";

console.assert(typeof msg === 'number', { name, msg: msg }); // 출력

console.group

만일 콘솔 화면에 출력할 값들이 많을때, 이들을 그룹화 하여 무엇에 대한 출력값인지 구분하기 위해 가독성을 높이기 위한 메서드이다. ~~console.group~~ 은 중첩해서 사용할 수 있다.

console.group("쇼핑몰 로그");
console.log("로그인 됐는지 우선 확인");

console.group("회원 관련 작업");
console.log("아이디 확인");
console.log("비번 확인");
console.groupEnd();

console.group("상품 관련 작업");
console.log("가격 변동이 있는가?");
console.log("재고는 남아있는가?");
console.groupEnd();

console.log("마무리 작업");
console.groupEnd();

~~console.group~~ 안에 그룹할 내용을 작성하고 끝에 ~~console.groupEnd~~ 로 그룹을 묶어 하나의 집합을 형성한다고 보면 된다.

그룹 열기 / 닫기

만일 처음부터 그룹이 닫혀져 있게 하고 싶다면 ~~console.groupCollpased~~ 를 사용 하면 된다.

console.group("쇼핑몰 로그"); // 그룹 열기
console.log("로그인 됐는지 우선 확인");

console.groupCollapsed("회원 관련 작업"); // 그룹 닫기
console.log("아이디 확인");
console.log("비번 확인");
console.groupEnd();

console.groupCollapsed("상품 관련 작업"); // 그룹 닫기
console.log("가격 변동이 있는가?");
console.log("재고는 남아있는가?");
console.groupEnd();

console.log("마무리 작업");
console.groupEnd();

console.time

자바스크립트의 코드 수행 시간을 확인할때 유용한 콘솔 메서드 이다.

보통은 ~~Date.now()~~ 를 통해 현재 시간을 ms 세컨드로 구하고 코드 수행이 끝난 시간을 구해 이의 차이값으로 구할수도 있지만 이런 번거로운 방법보다 콘솔 API를 통해 간단하고 정확히 수행 시간을 구할 수 있다.

// time과 timeEnd에 같은 타이머 이름을 주어야 정상적으로 작동한다.
let count = 0

console.time('time1')

for (let i = 0; i < 1000000000; i++) {
  count++
}

console.timeEnd('time1') // time1: 1382.543212890625 ms

console.time('time2')

for (let i = 0; i < 1000000000; i++) {
  count++
}

console.timeEnd('time2') // time2: 6366.410888671875 ms

console.table

만일 다음과 같이 반복되고 규칙적인 key와 value가 있는 객체가 들어있는 배열일 경우, 마치 엑셀과 같이 테이블 형식으로 가독성 좋게 출력이 가능하다. 최신 웹브라우저에서는 모두 지원되는 기능으로 콘솔을 이용해 배열 데이터 내용을 파악할 때 편리하다.

const foods = [
  {
    name: ' ',
    price: 30.89,
    group: 1,
  },
  {
    name: ' ',
    price: 20.71,
    group: 1,
  },
  {
    name: ' ',
    price: 10.31,
    group: 2,
  },
  {
    name: ' ',
    price: 5.98,
    group: 2,
  },
]

console.table(foods)

배열 객체 뿐만 아니라 다차원 배열 역시 테이블 형태로 출력이 가능하다.

const dolls = [ ['라이언', 5], ['어피치', 3], ['콘', 2], ['무지', 3], ['프로도', 3] ];
console.table(dolls)

console.dir

객체를 로깅 할 필요가 있을 경우 이 메서드를 사용하는 것도 괜찮다.

예를들어 DOM의 body 부분을 ~~console.log~~ 로 그대로 출력해보면 html 태그가 출력되지만,

console.log(document.body)

console.dir로 출력하면 DOM 객체(Object)로 콘솔에 출력됨을 확인 할 수가 있다.

console.dir(document.body)

console.trace

호출된 함수 스택을 자동으로 추적해준다. 함수가 여기 저기 모듈 파일에서 호출될 경우 이를 추적할때 유리하다.

function foo() {
  function bar() {
    console.trace(); // 스택 추적
  }
  bar();
}

foo();

console.count

특정 호출된 값이 몇 번 호출 되었나 횟수를 기록하고 싶을 때 사용한다고 보면 된다.

console.count('카운터1'); // 카운터1: 1
console.count('카운터1'); // 카운터1: 2

console.count('카운터2'); // 카운터2: 1
console.count('카운터2'); // 카운터2: 2

console.count('카운터1'); // 카운터1: 3

console.clear

콘솔 화면이 지저분할 경우 clear 해 줄 수 있다. 직접 치기 귀찮으면 아래 사진의 왼쪽 상단의 버튼을 눌러주면 자동으로 메서드를 호출하여 청소시킨다.

console.clear()

# 참고자료

https://javascript.plainenglish.io/its-2022-please-don-t-just-use-console-log-anymore-217638337c7d

https://www.zerocho.com/category/JavaScript/post/5b2b45cf1350f9001b662ba6

모바일 / 태블릿 에서만 CSS 파일 로드 최적화

인파_ — Sun, 2 Apr 2023 13:31:55 +0900

CSS 파일 로드 최적화

보통 ~~<link>~~ 태그의 css 파일 로드는 브라우저의 렌더링을 차단(blocking) 하기 때문에, css 파일이 크면 클수록 그만큼 웹페이지 속도에 영향을 미치게 된다. 따라서 왠만해선 css 파일의 용량을 최적화하여 줄이는 것이 좋으며 소스를 분리할 수 있는 것은 따로 분리하여 비동기 로드 시키는 것이 좋다.

예를들어 모바일 혹은 태블릿에서만 실행되는 미디어쿼리 선택자 부분은 메인 css 파일에 한꺼번에 때려넣기에는 약간 무리가 있다. 이때 모바일 소스를 다른 css 파일로 분리하고, 사용자의 화면 비율에 따라 선택적으로 css 파일을 로드하도록 하는 방법이 있는데, 이는 다음과 같다.

<!-- 모바일(480px 이하에서만 css 파일 로드) -->
<link
  rel="stylesheet"
  href="mobile.css"
  media="screen and (max-width: 480px)" 
/>
  
<!-- 태블릿(1080px 이하에서만 css 파일 로드) -->  
<link
  rel="stylesheet"
  href="tablet.css"
  media="screen and (max-width: 1080px)" 
/>

css 파일을 분할하여 메인 css의 크기가 작아지는 효과도 있고 별도로 모바일, 태블릿 화면의 css 소스들을 관리할 수 있다는 일거양득의 효과를 얻을 수 있을 것이다.

웹에서 음악 객체(Audio) 다루기

인파_ — Sat, 1 Apr 2023 20:18:43 +0900

HTML Audio 태그

HTML ~~<audio>~~ 태그는 웹 페이지에서 오디오를 재생하기 위해 사용되는 요소이다. MP3, WAV, OGG 등 다양한 오디오 포맷 파일을 웹에서 재생할 수 있다.

audio 태그 속성

속성	값	설정 내용
src	파일 경로	재생할 음원 파일의 경로 설정(mp3, wav, ogg 파일 등)
autoplay	autoplay	자동 재생 여부 설정(브라우저에 html파일이 로드되자마자 음악파일이 재생됨)
loop	loop	반복 재생 여부 설정
controls	controls	컨트롤 패널(재생/정지 버튼 등) 노출 여부 설정
muted	muted	음소거 설정

<!-- src 속성을 통해 오디오 파일의 경로를 지정 -->
<!-- controls 속성을 추가하면 오디오 재생 컨트롤러가 표시 -->
<!-- autoplay 속성을 추가하면 페이지가 로드될 때 자동으로 오디오가 재생 -->
<!-- loop 속성을 추가하면 오디오가 끝나면 자동으로 반복 재생 -->
<audio src="sound.mp3" autoplay loop controls id="myAudio"></audio>

오디오 파일 포맷 지정

~~<audio>~~ 태그 내부에 ~~<source>~~ 태그를 통해 다양한 타입의 오디오 포맷을 입력해주면, 브라우저가 알아서 지원하는 포맷으로 재생한다. 그리고 type 속성에는 해당 오디오 파일의 MIME 타입을 지정한다.

아래와 같이 여러 개의 ~~<source>~~ 태그를 사용하면 브라우저에서 지원하는 오디오 파일 타입을 우선적으로 재생하게 된다.

<audio autoplay loop controls>
  <source src="sound.mp3" type="audio/mpeg">
  <source src="sound.ogg" type="audio/ogg">
  오디오가 지원되지 않는 브라우저입니다. <!-- <audio> 요소 내에 위치하는 텍스트는 사용자의 브라우저가 <audio> 요소를 지원하지 않을 경우 화면에 표시 -->
</audio>

브라우저	지원 포맷
Internet Explorer	MP3, WAV
Chrome	MP3, WAV, Ogg Vorbis
Firefox	MP3, WAV, Ogg Vorbis
Safari	MP3, WAV, AAC

Javascript로 Audio 다루기

위의 오디오 요소를 자바스크립트 상에서 재생/일시 정지 등의 세밀한 컨트롤을 할 수가 있다.

자바스크립트 상에서 Audio 객체를 생성하거나, 혹은 HTML 상에 ~~<audio>~~ 태그를 선언해둔 상태라면, 엘리먼트 취득 방식으로 audio 객체를 확보할 수도 있다.

const audio = new Audio('audio.mp3'); // `audio.mp3` 파일을 로딩
audio.play(); // 오디오 재생

<!-- HTML audio 태그 -->
<audio src="sound.mp3" id="myAudio"></audio>

<script>
    const myAudio = document.getElementById("myAudio") // Audio객체 취득
    myAudio.play(); // 음원 재생
    myAudio.pause(); // 일시 정지
</script>

이러한 Audio 객체는 다양한 메서드와 이벤트를 제공하므로, 다양한 오디오 제어 기능을 구현할 수 있다.

See the Pen MP3 Playback via HTML5 Audio Elements by Anson Kao (@ansonkao) on CodePen.

Audio 객체

Audio 객체 프로퍼티

프로퍼티	설정 내용
src	음원파일 경로 : "경로/파일명.확장자"
volume	볼륨 : 0~1
loop	반복 여부: true \| false
autoplay	자동재생 여부: true \| false
muted	음소거 여부: true \| false
paused	일시정지 여부: true \| false
ended	재생완료 여부: true \| false
duration	음원의 전체 길이(초 단위)
currentTime	음원의 현재 재생 위치(초 단위)

const audio = new Audio('audio.mp3');

// audio가 load 될 때 자동재생 됨
audio.autoplay = true;

// audio의 재생시점을 5초로 설정함
audio.currentTime = 5;

// audio의 길이를 초(seconds) 단위로 반환
audio.duration;

// audio를 반복 재생함
audio.loop = true;

// audio 음소거
audio.muted = true;

// audio의 경로를 지정함(URL)
audio.src = "my_audio.mp3";

// audio의 음량을 0.2로 지정함
// 음량은 0.0 ~ 1.0 사이 값으로 지정할 수 있고, 1.0이 가장 큰 음량
audio.volume = 0.2;

Audio 객체 메서드

메서드	작동 내용
play()	재생
pause()	일시정지
addTextTrack()	새로운 트랙을 추가
canPlayType()	브라우저가 해당 오디오 타입을 재생할 수 있는지 체크
load()	오디오 객체를 리로드

const audio = new Audio('audio.mp3');

audio2.loop = true; // 반복재생하지 않음
audio2.volume = 0.5; // 음량 설정

audio2.play(); // sound2.mp3 재생

setTimeout(function () { // 5초 후 sound2.mp3 일시정지
	audio2.pause();
}, 5000);

// audio를 다시 load함. 주로 audio의 src나 설정이 바뀌었을 경우에 사용
audio.src = "sound2.mp3";
audio.load();

/* 오디오 처음부터 재생 */
audio.currentTime = 0; // 재생 위치를 처음으로 설정
audio.play(); // 처음부터 다시 재생됨

Audio 객체 이벤트

오디오가 재생되거나 일시정지될 때 발생하는 이벤트 등을 처리할 수 있다.

이벤트	상황
canplaythrough	음원 파일이 모드 로드되어 재생 가능할 때
play	재생이 시작될 때
playing	재생 중일 때
puase	일시 정지되었을 때
ended	재생이 완료되었을 때
volumechange	볼륨이 변경될 때

// 오디오 재생 시
audio.addEventListener('play', function() {
  console.log('오디오가 재생되었습니다.');
});

// 오디오 일시정지 시
audio.addEventListener('pause', function() {
  console.log('오디오가 일시정지되었습니다.');
});

음원 자동 재생 브라우저 정책

크롬이나 사파리, 파이어폭스 같은 대부분 브라우저의 경우 보안 정책 상 사용자의 명시적인 액션(클릭 ..등)이 없는 상태에서의 자동 음원 재생과 같은 기능은 작동하지 않는다.

예를들어 아래와 같이 자바스크립트로 오디오 객체를 로드하고 자동으로 ~~play()~~ 메서드를 통해 음원을 재생하도록 설정하였지만 브라우저 상에서 이를 차단한다는 것이다.

const audio = new Audio('audio.mp3');
audio.play();

즉, 사용자가 버튼 클릭과 같은 작업을 통해 ~~play()~~ 메서드를 호출해야만 음원을 재생할 수 있다는 것이다. 따라서 아래와 같이 코드를 구성해야 한다.

<button id="play-button">음악 재생</button>

<script>
    const audio = new Audio('audio.mp3');
    const playButton = document.getElementById('play-button');

    playButton.addEventListener('click', function() {
      audio.play();
    });
</script>

이전에는, Chrome 브라우저에서 자바스크립트를 이용하여 음원을 자동으로 재생하는 것이 가능했지만, 이는 악성코드의 유포나 사용자의 개인정보를 탈취하는 등의 보안 위협이 될 수 있었기 때문이다.

Audio Player 라이브러리

만일 웹페이지에 멋진 mp3 기능을 추가하고 싶다면 미리 만들어진 자바스크립트 라이브러리를 사용하는 것도 방법이다. 자체적으로 CSS 스타일링이 되어 있어서 느낌 좋은 미디어 플레이어를 자신의 홈페이지에 추가할 수 있다.

Calamansi.js - HTML5 & JS Audio Player by Voerro | Voerro Tutorials

Live demo of Calamansi.js - a HTML5 & JS Audio Player by Voerro

www.voerro.com

OnAirCode

We’ll provide resources, examples, tutorials related to web design, graphics, mobile app development for designer and developer with ideas.

onaircode.com

35+ JavaScript Music Players - Free Code + Demos

1. Music Player App Author: Rafaela Lucas (rafaelavlucas) Created on: December 26, 2019 Made with: HTML, SCSS, JS Tags: music-player, music stream, player songs, daily ui, daily ui challenge 2. HTML Audio Player Author: Zakari Abdessamad (vanderzak) Create

devsnap.me

26 HTML Audio Player For Websites In Codepen

If you have a music related website and want to improve the design or add more functions capabilities for your music player to attract as…

niemvuilaptrinh.medium.com

Web Audio API

이처럼 HTML에서 audio 객체를 이용하면, 오디오를 재생/정지하고 볼륨을 조정하거나 이벤트 처리를 할 수 있다. 그러나 딱 이 정도의 기능이 끝이다. 그 이상은 없다.

Web Audio API는 웹 브라우저에서 오디오 처리와 재생을 위한 강력한 신생 API 이다. 오디오 데이터를 샘플링하고, 필터링하고, 조작하여 오디오 음원 자체를 컨트롤하고 분석할 수 있는 방법을 제공해주어 일반 Audio 객체보다 더 높은 수준의 오디오 제어가 가능하다는 점 등이 있다. 예를들어 음원에 다양한 이펙트 효과를 줄 수 있으며, 음원의 주파수 데이터 취득을 통한 Pitch(높낮이), Gain(볼륨) 등의 계산도 가능하고 마이크를 통해 스트림으로 들어오는 소리에 대한 분석도 가능하다.

Web Audio API - Web API | MDN

Web Audio API는 웹에서 오디오를 제어하기 위한 강력하고 다양한 기능을 제공합니다. Web Audio API를 이용하면 오디오 소스를 선택할 수 있도록 하거나, 오디오에 이펙트를 추가하거나, 오디오를 시

developer.mozilla.org

<audio src="audio.mp3"></audio>
<label for="playback-rate">Playback Rate</label>
<input type="range" id="playback-rate" min="0.5" max="2" step="0.1" value="1">

<script>
    // 오디오 파일 로드
    const audioContext = new AudioContext(); // 오디오 컨텍스트를 생성
    const audioElement = document.querySelector('audio'); // HTML audio 요소 가져오기
    const audioSource = audioContext.createMediaElementSource(audioElement); // 오디오 소스를 생성

    // 재생 속도 변경을 위한 슬라이더 생성
    const playbackRateSlider = document.querySelector('#playback-rate');
    playbackRateSlider.addEventListener('input', () => {
      // 사용자가 슬라이더를 조작하면 playbackRate 속성(오디오 재생 속도)가 변경
      audioElement.playbackRate = playbackRateSlider.value;
    });

    // 오디오 재생
    audioSource.connect(audioContext.destination); // 오디오 소스를 오디오 컨텍스트의 출력에 연결
    audioElement.play();
</script>

그러나 Web Audio API는 강력한 만큼 일반 Audio 객체보다 복잡해 높은 학습률을 요구한다. 따라서 단순한 오디오 재생 기능만을 필요로 하는 경우에는 일반 Audio 객체를 사용하는 것이 적합할 수 있고, 다양한 사운드 작업 및 분석이 필요하다면 Web Audio API를 사용하는 것이 좋다.

# 참고자료

http://www.tcpschool.com/html-tags/audio

https://stackoverflow.com/questions/9419263/how-to-play-audio

https://curryyou.tistory.com/337

☕ 람다식 리팩토링 하기 (Comparator 축약 원리)

인파_ — Fri, 31 Mar 2023 09:28:16 +0900

Comparator 람다식 리팩토링 해보기

다음은 실제로 자바 프로그래밍에서 배열을 정렬(sort) 할때 사용되는 Comparator 인터페이스 사용 예제이다.

Apple 클래스가 있고 생성자 인자로 사과의 무게(weight)값을 받는다. 그리고 실행부에서 배열로 사과 객체를 담고, 사과 무게에 따라 배열 요소들을 정렬하려고 한다. 이를 코드로 구현하면 아래와 같이 구현할 수 있다.

class Apple {
    private final int weight; // 사과 무게

    public Apple(int weight) {
        this.weight = weight;
    }

    public int getWeight() {
        return weight;
    }

    @Override
    public String toString() {
        return "Apple{" + "weight=" + weight + '}';
    }
}

public class Main {
    public static void main(String[] args) {
        Apple[] inventory = new Apple[] {
                new Apple(34),
                new Apple(12),
                new Apple(76),
                new Apple(91),
                new Apple(55)
        };

        Arrays.sort(inventory, new Comparator<Apple>() {
            @Override
            public int compare(Apple o1, Apple o2) {
                return Integer.compare(o1.getWeight(), o2.getWeight());
            }
        });
        
        System.out.println(Arrays.toString(inventory));
    }
}

배열을 출력해보니, 사과 객체들이 무게에 따라 순서대로 정렬됨을 볼 수 있다.

하지만 인텔리제이와 같은 IDE를 쓴다면, Comparator 익명 구현 클래스를 람다표현식으로 리팩토링 하라고 조언을 해줄 것이다.

그런데 람다식으로 변환했더니 이번엔 또 변환하라고 IDE에서 조언해준다.

변환해보니 확실히 기존 람다식 보단 코드 줄이 확연히 줄었음을 볼 수 있다. 그런데 갑자기 쌩뚱맞게 Comparator의 정적 메소드를 호출하고 그 안에는 람다의 메서드 참조 문법을 써 놓았다. 대체 어떤 원리로 람다표현식을 이렇게 축약을 할 수 있는지 가늠이 안간다.

실제로 이는 실전에서 정말 많이 쓰이는 기법인데, 단순하게 암기하고 넘기지 말고 왜 저런식으로 줄일 수 있는지 지금부터 하나하나 파헤쳐 보자.

Comparator의 축약 원리 파헤치기

우선 해당 람다식은 메소드 참조로 문법적으로 생략이 불가능 하다.

Arrays.sort(inventory, (o1, o2) -> Integer.compare(o1.getWeight(), o2.getWeight()));

만일 ~~(a1, a2) -> Integer.compare(a1, a2)~~ 처럼 되어있으면 ~~Integer::compare~~ 로 생략할 수 있었겠지만, 매개변수가 Integer.compare 메서드의 인자로 그대로 들어간게 아니라 별도로 메서드를 호출하고 있기 때문이다.

그러면 영원히 코드 식을 줄일수 없는것 인가?

생각을 환기 시켜보면 해답은 간단하다. 바로 람다 함수 자체를 메서드가 반환하도록 만들면 된다.

람다 함수식은 일급 객체로 취급된다. 일급 객체의 특징으로는 변수에 함수를 할당할수 있고 함수를 리턴값으로도 활용할 수 있다. 대표적으로 자바스크립트의 함수가 변수에 넣거나 자체 함수를 반환하는 기법을 사용한다.

즉, 이러한 특성을 이용해 별도의 정적 메서드를 만들고, 그 메서드가 특정 람다 함수식을 리턴하도록 해주면, 길다란 람다식을 단순히 메서드 호출 코드로 줄일수 있는 것이다. 그래서 우선 간단하게 프로토타입으로 람다식을 반환하는 정적 메서드를 작성해보면 다음과 같이 되겠다.

public class Main {

    public static Comparator<Apple> comparingInt() {
        // 람다식을 Comparator 인터페이스 타입으로 반환
        return (a1, a2) -> Integer.compare(a1.getWeight(), a2.getWeight());
    }

    public static void main(String[] args) {
        Apple[] inventory = new Apple[]{
                new Apple(34),
                new Apple(12),
                new Apple(76),
                new Apple(91),
                new Apple(55)
        };

        Arrays.sort(inventory, comparingInt()); // 단순한 메서드 호출로 생략함 (가독성 ↑)
        
        System.out.println(Arrays.toString(inventory));
    }
}

구현한 메서드를 좀 더 사용성 좋게 바꿔보자. 지금은 Apple 객체의 weight 값만 다루니까 저렇게 작성해도 되지만, 나중에 Banana 객체의 prize 값으로 정렬할수도 있는 기능을 확장할 수 도 있다. 따라서 외부에 의해 바뀔수 있는 부분인 ~~a.getWeight()~~ 부분을 매개변수화 하여 처리하도록 하면 된다.

그런데 ~~a.getWeight()~~ 는 단순히 데이터가 아닌 함수를 호출하는 코드 로직이다. 이를 어떻게 매개변수화 하면 되는 것일까?

우리는 자바 람다에 대해 배우고 있다. 파라미터로 들어올 값은 반드시 정수나 문자열과 같은 고정된 데이터만 들어오라는 법은 없다. 즉, ~~a.getWeight()~~ 를 리턴하는 람다식으로 매개변수화 하여 함수형 인터페이스로 받으면 되는 것이다.

이제 어떠한 함수형 인터페이스 타입을 매개변수의 타입으로 정해야 할지 고민해야 되는데, Apple 타입의 객체를 파라미터로 받아 int 값인 무게를 반환하기 때문에 여기에 적절한 함수형 인터페이스는 ~~ToIntFunction<Apple>~~ 이다.

public static Comparator<Apple> comparingInt(ToIntFunction<Apple> keyExtractor) {
    // 매개변수로 람다식을 받아서 추상 메서드 실행 : keyExtractor.applyAsInt(a1) == a1.getWeight()
    return (a1, a2) -> Integer.compare(keyExtractor.applyAsInt(a1), keyExtractor.applyAsInt(a2));
}

마지막으로 다른 제네릭 타입도 받을수 있게 타입 파라미터를 T 기호로 바꿔주면 완성이다.

그리고 ~~(a) -> a.getWeight()~~ 람다식은 메서드 참조로 ~~Apple::getWeight~~ 로 축약이 가능하니 최종 완성본은 다음과 같다.

public class Main {
    public static <T> Comparator<T> comparingInt(ToIntFunction<? super T> keyExtractor) {
        return (a1, a2) -> Integer.compare(keyExtractor.applyAsInt(a1), keyExtractor.applyAsInt(a2));
    }

    public static void main(String[] args) {
        Apple[] inventory = new Apple[]{
                new Apple(34),
                new Apple(12),
                new Apple(76),
                new Apple(91),
                new Apple(55)
        };

        Arrays.sort(inventory, comparingInt(Apple::getWeight)); // (a) -> a.getWeight()
        
        System.out.println(Arrays.toString(inventory));
    }
}

실제 Comparator와 비교하기

실제 자바에 정의되어 있는 Compator 인터페이스의 ~~comparingInt()~~ 메서드 시그니처를 보면 지금까지 우리가 구현한 것과 별반 차이가 없는 것을 볼 수 있다.

Arrays.sort(inventory, Comparator.comparingInt(Apple::getWeight));

이런식으로 람다식이 오히려 코드의 가독성을 해친다고 생각하면 입글 객체의 특성을 이용하여 메서드로 람다식을 반환하도록 구성해줌으로써 코드식이 단순히 메서드 호출로 구성해준다면 보다 클린한 리팩토링 코드가 될 것이다.

‍ 프로세스 / 데몬 / 서비스 차이 한방 정리

인파_ — Thu, 30 Mar 2023 17:03:16 +0900

프로세스 (Process)

프로세스는 메모리에 적재되어 CPU에 의해 실행되는 컴퓨터 프로그램을 지칭한다. 각 프로세스는 고유한 프로세스 ID(PID)를 가지며, 운영체제는 프로세스 간의 자원 공유를 관리한다. 예를 들어, 웹 브라우저를 실행하는 경우 브라우저라는 프로그램은 하나의 프로세스로 실행되는 것이다. 그리고 프로세스는 눈에 보이는 프로세스(foreground process) 와 눈에 보이지 않은 프로세스(background process) 로 구분된다.

작업관리자 창을 보면 백그라운드 프로세스 카테고리가 있다

포그라운드 프로세스	백그라운드 프로세스
사용자와 상호작용하는 프로세스	프로세스는 사용자와 상호작용하지 않고 시스템에서 실행되는 프로세스
최소화를 하더라도 눈에 보이는 프로세스를 포그라운드 프로세스	눈에 보이지 않지만 뒤에서 일을 하고 있는 프로세스를 백그라운드 프로세스
인터넷, 카카오톡, 메모장, 그림판 등 눈에 보이는 프로그램	백신 프로그램, 그래픽 드라이버, 마이크 드라이버 등 눈에 보이지 않는 프로그램

데몬 (Daemon)

데몬은 백그라운드에서 실행되는 프로그램으로, 사용자가 직접적으로 제어하지 않고 백그라운드에서 돌면서 여러 작업을 하는 프로그램을 말한다. 사용자의 요청을 기다리고 있다가 요청이 발생하면 이에 적절히 대응하는 리스너와 같은 역할을 한다. 즉, 메모리에 상주하면서 특정 요청이 오면 즉시 대응 할 수 있도록 대기중인 프로세스를 말한다.

Daemon 단어의 어원

데몬이란 용어는 맥스웰의 도깨비 사고 실험에서 영감을 얻어 탄생하였다. 맥스웰의 도깨비는 보이지 않는 곳에서 분자들을 골라주는 일을 하는데, 보이지 않는 곳에서 조용히 일한다는 점에서 맥스웰의 도깨비와 데몬 프로그램은 비슷하기 때문이다. 또한 데몬는 악마나 유령을 뜻하는데, 유령은 걷지 않고 항상 떠 있다는 점에서 백그라운드에서 조용하게 항상 수행되는 프로그램을 데몬 프로그램이라 부르게 된 것이다.

데몬은 항상 돌아가고 있어야하는 웹서버에 적합하여 일반적으로 서버에서 주로 사용된다. 대표적인 예로 Apache 웹서버의 httpd가 바로 데몬 프로그램이다. httpd는 웹서버에 백그라운드에서 실행되면서 서버로 들어오는 요청에 자동으로 응답해 준다.

이밖에도 유닉스(리눅스) 운영체제에서 운영체제에서 프로세스 이름 끝이 d로 끝나는 프로세스들이 대표적인데 inetd, httpd, nfsd, sshd, named, lpd 등이 있다.

서비스 명	데몬 명	정의
Linux 슈퍼데몬	xinetd	Linux 내 여러 서비스를 한번에 관리
File Transfer Protocol	vsftpd	File을 전송하는 서비스
Secure Shell Service	sshd	암호화 원격 작업이 가능한 서비스
Network File System	nfs	Network 를 이용하여 FileSystem 을 공유하는 서비스
Domain Name Service	named	IP와 Domain 을 mapping 시켜주는 서비스
Web Service	httpd	Browser 를 이용하여 웹 문서 페이지를 출력시킬 수 있는 서비스
Database Management	mysqld	DB를 관리하는 서비스
Mail Service(send)	sendmail	mail을 전송할 수 있는 서비스

서비스 (Service)

서비스는 백그라운드에서 실행되는 응용 프로그램이다. 윈도우 서비스는 일반적으로 사용자 인터페이스를 필요로 하지 않는 작업(네트워크 서비스, 데이터베이스 서버, 백업 서비스) 등을 수행한다. 이러한 서비스들은 시스템이 부팅될 때 자동으로 시작되며, 사용자가 로그인하지 않은 상태에서도 계속해서 실행된다.

이렇게만 보면 데몬과 서비스의 차이가 잘 와닿지 않을 것인데, 윈도우 OS에서는 백그라운드에서 실행되는 응용 프로그램을 service 라 부르고 유닉스(리눅스) OS에서는 daemon 이라고 불리운다고 보면 된다. 즉, 둘이 거의 비슷하다.

프로세스, 데몬, 서비스 차이

데몬 vs 백그라운드 프로세스

일반적으로 프로세스와 데몬의 차이는 프로세스는 필요시 실행시키는 것이고 데몬은 자동 실행이라는 것이다. 예를들어 노트패드를 실행시키려면 사용자가 직접 조작해야되지만, 백신 프로그램은 컴퓨터를 재부팅해도 자동으로 실행된다.

그럼 포그라운드가 아닌 백그라운드 프로세스와 데몬은 무슨 차이일까?

데몬과 백그라운드 프로세스의 가장 큰 차이점은 운영체제에서 사용되는 점이다. 데몬은 주로 유닉스나 리눅스와 같은 운영체제에서 사용되며 시스템 레벨에서 실행되는 반면, 백그라운드 프로세스는 윈도우 운영체제에서 사용되며 데몬과 비슷한 역할을 수행하지만 대신 서비스(Service)라는 용어를 사용한다는 점에서 미세한 차이가 있다고 보면 된다. 또한 데몬은 유닉스와 같은 운영체제에서는 일반적으로 init 프로세스를 통해 실행되는 반면, 윈도우 운영체제에서는 서비스 매니저를 통해 실행된다.

init 프로세스는 시스템이 종료될 때까지 계속 실행되는 데몬 프로세스이며 다른 모든 프로세스의 직간접 부모 프로세스이다.

윈도우 서비스 매니저 / init 프로세스 리스트

데몬 vs 서비스

Daemon 과 Service는 비슷한 개념이지만, 운영 체제 차이점 있다고 했다. 그외에도 사용처에도 차이가 있는데, 데몬은 일반적으로 서버에서 주로 사용되고, 서비스는 다른 프로그램이나 서비스를 지원하기 위해 실행된다. 데몬은 시스템에서 독립적으로 실행되고, 서비스는 시스템의 상태를 모니터링하고, 백그라운드에서 실행되는 애플리케이션을 제어하고, 작업을 수행하는 등의 역할 지원하는데 초점이 맞춰져 있다는 뜻이다.

하지만 이들 용어는 종종 상호교환적으로 사용되기도 하며, 컴퓨터 시스템에서 다양한 역할을 수행하므로, 구체적인 용어 해석은 사용되는 컨텍스트에 따라 달라질 수 있다. 예를들어 리눅스에서 포트/프로토콜 정보를 정의해놓은 /etc/services 디렉토리가 있기 때문에 두 OS에서 '서비스'와 '데몬'은 혼용되어 쓰인다고 보면 된다.

그렇지만 윈도우 일반 솔루션에서도 데몬이라는 용어를 쓰기도 한다. 그 솔루션의 기능을 수행하기 위해서는 필수적으로 항상 실행이 되어 있어야 하기에, 프로세스라 부르면 조금 어색해져 데몬이라 부르는 것이다.

# 참고자료

https://hec-ker.tistory.com/323

https://jins-dev.tistory.com/entry/Daemon-%EA%B3%BC-Background-Process-%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

https://blogger.pe.kr/770

☕ 람다식을 더 짧게 - 메소드::참조 문법

인파_ — Thu, 30 Mar 2023 09:52:54 +0900

람다식 메소드::참조

자바의 람다표현식을 통해 코드 정의를 혁신적으로 줄여주었지만 이보다 더 간략하게 줄이는 문법이 있다.

메소드 참조(Method Reference)는 말 그대로 실행하려는 메소드를 참조해서 매개 변수의 정보 및 리턴 타입을 알아내어, 람다식에서 굳이 선언이 불필요한 부분을 생략하는 것을 말한다.

람다식은 복잡하고 길다란 로직보단 기존 메소드들을 단순히 호출만 하는 경우가 많다. 예를 들어 두 개의 값을 받아 작은 수를 리턴하는 Math 클래스의 ~~max()~~ 정적 메소드를 호출하는 람다식은 다음과 같다.

(x, y) -> Math.max(x, y)

이 자체로도 간략해 보이지만, 자바 개발진은 그러지 않은가 보다. 함수 형태를 보면 리턴값 자체가 또다른 Math 클래스의 메소드를 호출하는 것 뿐이고, 람다 함수의 매개변수 역시 그대로 ~~max()~~ 메서드의 매개변수로 들어가기 때문에 코드 중복이 발생하기 때문이다.

따라서 중복되는 매개변수를 없애고, 화살표를 없애고, 클래스가 메소드를 참조하는 기호인 . 기호를 :: 기호로 변환하면 다음과 같이 표현 할 수 있게 된다.

Math::max; // (x, y) -> Math.max(x, y)

메서드 참조 조건과 타입 추론

만약 ~~Math::min~~ 메서드 참조를 변수에 담고 싶다면, 함수형 인터페이스 타입인 IntBinaryOperator 인터페이스를 사용하면 된다. 두 개의 int 형 입력값을 받아 int 값을 리턴하는 함수 디스크립터를 갖고 있기 때문이다.

IntBinaryOperator b = Math::min;
b.applyAsInt(100, 200); // 100

이런식으로 문법 함축이 가능한 이유는 컴파일러가 람다식의 타입을 추론하기 때문이다. 이때 람다 타입 추론은 기존의 람다 익명 함수와는 약간 차이가 있다. 오히려 더 간단한데, 인터페이스의 추상 메서드 형태와 반환 메서드의 시그니처 형태가 같으면 된다.

위의 그림과 같이, IntBinaryOperator 인터페이스의 추상 메서드는 int형 매개변수 2개를 받으며 반환 타입이 int형이고, Math 클래스의 max 메서드 역시 타입이 똑같이 구성되어 있기 때문에, 이를 컴파일러가 추론해서 가능한 것이다.

정리하자면, 람다식의 메소드 참조 문법을 사용하기 위해서는 다음의 3가지 조건을 만족하면 된다.

함수형 인터페이스의 매개변수 타입 == 메소드의 매개변수 타입
함수형 인터페이스의 매개변수 개수 == 메소드의 매개변수 개수
함수형 인터페이스의 반환 타입 == 메소드의 반환 타입

메서드 참조 종류

어떠한 메서드를 참조하여 실행하느냐에 메소드 참조도 종류가 나뉘게 된다.

종류	람다 표현식	메서드 참조
정적 메서드 참조	~~(x) -> ClassName.method(x)~~	~~ClassName::method~~
인스턴스 메서드 참조	~~(x) -> obj.method(x)~~	~~obj::method~~
매개변수의 메서드 참조	~~(obj, x) -> obj.method(x)~~	~~ClassName::method~~
생성자 참조	~~(x, y) -> new ClassName(x, y)~~	~~ClassName::new~~

정적 메소드 참조

다음은 Interger 클래스의 ~~parseInt()~~ 정적 메서드를 호출하는 람다식을 메소드 참조로 리팩토링한 예제이다.

정적 메소드를 참조할때, 메서드 참조 :: 기호 앞부분에 클래스명을 그대로 기재하는 것이 특징이다.

Function<String, Integer> stringToInt;

// (x) -> ClassName.method(x)
stringToInt = (s) -> Integer.parseInt(s);

// ClassName::method
stringToInt = Integer::parseInt;

stringToInt.apply("100");

인스턴스 메소드 참조

다음은 ArrayList 클래스의 인스턴스를 만들고 인자로 Collection을 받아 리스트에 요소들을 추가하는 람다식을 메소드 참조로 리팩토링한 예제이다.

인스턴스의 메소드를 참조할때, 메서드 참조 :: 기호 앞부분에 상단에 선언한 인스턴스 변수를 기재하는 것이 특징이다.

ArrayList<Number> list = new ArrayList<>();
Consumer<Collection<Number>> addElements;

// (x) -> obj.method(x)
addElements = (arr) -> list.addAll(arr);

// obj::method
addElements = list::addAll;

addElements.accept(List.of(1, 2, 3, 4, 5));

System.out.println(list); // [1, 2, 3, 4, 5]

매개변수의 메서드 참조

다음은 String 클래스의 인스턴스를 받아 문자열의 길이를 구하는 람다식을 메소드 참조로 리팩토링한 예제이다.

매개변수의 메소드를 참조할때, 메서드 참조 :: 기호 앞부분에 정적 메소드 참조와 똑같이 매개변수의 클래스 타입명을 기재하는 것이 특징이다.

Function<String, Integer> size;

// (obj, x) -> obj.method(x)  
size = (String s1) ->  s1.length();

// ClassName::method
size = String::length;

size.apply("Hello World"); // 11

생성자 참조

생성자도 일종의 메소드 이기 때문에 메서드 참조가 가능하다. 리턴값이 단순히 객체를 생성하는 것이기 때문에 적용이 가능한 것이다. 대신 생성자는 고유 메서드명이 없기 때문에 ~~new~~ 로 표시한다.

BiFunction<Integer, Integer, Object> constructor;

// (x, y) -> new ClassName(x, y)  
constructor = (x, y) -> new Object(x, y);

// ClassName::new
constructor = Object::new;

이때 생성자 오버로딩을 통해 매개 변수 개수에 따라서 인스턴스화를 구현하려고 할때, 람다식을 각기 다른 함수형 인터페이스에 대입하여 실행시켜야 한다.

import java.util.function.BiFunction;
import java.util.function.Function;
import java.util.function.Supplier;

class Customer {
    String name;
    int age;

    public Customer() {
    }

    public Customer(String name) {
        this.name = name;
    }

    public Customer(String name, int age) {
        this.name = name;
        this.age = age;
    }
}

public static void main(String[] args) {
    // 생성자 인자 없이 생성할때
    Supplier<Customer> function1 = Customer::new;
    Customer customer1 = function1.get();

    // 생성자 인자 1개로만 생성할때 (입력타입, 생성자클래스)
    Function<String, Customer> function2 = Customer::new;
    Customer customer2 = function2.apply("홍길동");

    // 생성자 인자 2개로만 생성할때 (입력타입1, 입력타입2, 생성자클래스)
    BiFunction<String, Integer, Customer> function3 = Customer::new;
    Customer customer3 = function3.apply("홍길동", 55);
}

이를 고급 응용하자면 Map 컬렉션에 생성자 람다를 넣어서 인스턴스 관리를 통해 '지연 인스턴스화' 기법을 구현할 수 있다. 이 기법은 다이나믹 팩토리 패턴으로서 리플렉션 대안으로 응용이 가능하다.

class Fruit {}

class Apple extends Fruit {
    int count;

    public Apple(int count) {
        this.count = count;
    }
}
class Banana extends Fruit {
    int count;

    public Banana(int count) {
        this.count = count;
    }
}

class Constructor {
    public static Map<String, Function<Integer, Fruit>> map = new HashMap<>();

    static {
        map.put("apple", Apple::new);
        map.put("banana", Banana::new);
    }

    public static Fruit makeFruit(String name, int count) {
        if(map.containsKey(name)) {
            return map.get(name.toLowerCase()).apply(count);
        }
        return null;
    }
}

public static void main(String[] args) {
    Apple apples = (Apple) Constructor.makeFruit("apple", 10);
    Banana bananas = (Banana) Constructor.makeFruit("banana", 4);
}

부록) 자바스크립트의 메소드 참조

자바스크립트의 화살표 함수도 사실 람다 표현식의 일종이다. 그래서 자바와 같이 화살표 함수에 대한 메서드 참조가 가능하다.

List<Number> list = Arrays.asList(1, 2, 3, 4, 5, 6);

// 기존 람다 방식
list.forEach( (e) -> System.out.println(e) );

// 메소드 참조 방식
list.forEach(System.out::println);

const arr = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];

// 기존 콜백 방식
arr.forEach( (e) => console.log(e) );

// 메소드 참조 방식
arr.forEach(console.log);

그런데 사실 이 부분은 메서드 참조 같은 고급진 기능이 아니라, 자바스크립트의 함수 선언식 자체를 넘겼을 뿐이다.

자바스크립트로 브라우저의 이벤트를 등록할때 다음과 같이 addEventListener의 핸들러로 바로 화살표 함수를 정의해줘도 되지만 한단계 거쳐 먼저 함수를 선언하고 함수 자체를 넘겨줘본 경험이 있을 것이다.

const handler = () => {};

window.addEventListener('click', handler);

addEventListener 메서드가 매개변수로 callback 함수를 받아 내부에서 실행시켜주기 때문에 이러한 수식이 가능한 것이다.

자바스크립트의 forEach 구현

그래서 forEach를 간단하게 직접 구현해보면 아래와 같이 될 것이다. 자바스크립트 함수 매개변수로 함수 자체를 받아 함수 내부에서 매개변수를 ~~callback()~~ 괄호를 붙여 함수 호출을 해주는 것이다.

function forEach(arr, callback) {
    for(const i of arr) {
        callback(i); // console.log(i)
    }
}

const arr = [0, 1, 2, 3, 4, 5];
forEach(arr, console.log);

자바의 forEach 구현

이러한 원리가 고대로 자바의 람다에서도 적용된다라고 생각하면 된다. 특정 함수형 인터페이스 타입으로 매개변수를 받고 매개변수의 추상 메서드를 호출함으로써 콜백이 실행되게 되는 것이다.

다음은 forEach 동작을 자바로 아주 간단하게 구현해본 코드이다.

public static void forEach(int[] arr, Consumer<? super Number> callback) {
    for (int i : arr) {
        callback.accept(i); // System.out.println(i)
    }
}

public static void main(String[] args) {
    int[] arr = {1,2,3,4,5};
    forEach(arr, System.out::println);
}

# 참고자료

https://dev-kani.tistory.com/38

https://steady-coding.tistory.com/307

☕ 함수 디스크립터(Function Descriptor) 란?

인파_ — Wed, 29 Mar 2023 13:39:02 +0900

함수 디스크립터

보통 자바의 람다 표현식(Lambda Expression)의 사용 용도를 두가지로 정의하는데, 하나는 람다 함수로서의 용도 그리고 다른 하나는 함수형 인터페이스의 추상 메서드의 역할을 설명해놓은 시그니처로서 쓰인다.

그중 함수 디스크립터(Function Descriptor)는 단어 그대로 함수가 어떤 입력값을 받고 어떤 반환값을 주는지에 대한 설명을 람다 표현식 문법으로 표현한 것을 의미한다고 보면 된다.

예를들어, ~~() -> void~~ 는 파라미터 리스트가 없으며 void를 반환하는 함수를 의미하는 디스크립터며, ~~(int, int) -> double~~ 는 두개의 int를 파라미터로 받아 double형 자료를 반환하는 함수를 설명한다고 보면 된다.

이처럼 함수 디스크립터는 주로 java.util.function 패키지의 함수형 인터페이스를 람다식으로 사용할때 어떤 역할을 하는 함수인지 간략하게 보여주는 시그너처이다.

타입스크립트 진영에서는 아예 함수 자체 타입을 람다식(화살표 함수)로 표현하는데 이것도 함수 디스크립터 일종이라고 봐도 무방하다.

함수형 인터페이스	함수 디스크립터 (추상 메서드가 어떤 역할을 하는지 간략하게 설명)
Predicate	T -> boolean
Consumer	T -> void
Function<T,R>	T -> R
Supplier	( ) -> T
BiPredicate<L, R>	(L, R) -> boolean
BiConsumer<L, R>	(T, U) -> void
BiFunction<T,U,R>	(T, U) -> R
Runnable	() -> void

☕ 함수형 인터페이스 표준 API 총정리

인파_ — Tue, 28 Mar 2023 09:49:35 +0900

함수형 인터페이스 표준 API

함수형 인터페이스(functional interface)는 추상메서드가 1개만 정의된 인터페이스를 통칭하여 일컫는다. 이 인터페이스 형태의 목적은 자바에서 람다 표현식(Lambda Expression)을 이용해 함수형 프로그래밍을 구현하기 위해서 이다.

// @FunctionalInterface 어노테이션을 인터페이스에 붙여주면, 
// 두 개 이상의 메소드 선언 시 컴파일 오류를 발생시켜 개발자의 실수를 줄일 수 있다.
@FunctionalInterface
public interface Animal {
		public void method();
}

그런데 곰곰히 생각해보면 함수의 형태(Signature)는 다양하다. 함수의 리턴 값이 있을수도 없을수도 있고 매개변수 갯수가 1개 혹은 2개일 수도 있다. 이러한 형태의 함수를 일일히 정의해서 사용하기엔 너무 양이 많으니, 자바 개발진들이 미리 함수형 인터페이스를 만들어 제공하는 것이 바로 이번 시간에 배울 함수형 인터페이스 표준 API 이다.

자바에서 자료구조를 컬렉션 프레임워크로 미리 만들어 제공하듯이, 자주 사용할 것 같은 람다 함수 형태를 함수형 인터페이스 표준 API로 미리 만들어 제공해준다라고 이해하면 된다.

표준 API 종류

함수적 인터페이스 표준 API는 ~~java.util.function~~ 패키지로 제공된다. 이 패키지 안에 있는 함수적 인터페이스 종류로는 Consumer, Supplier, Function, Operator, Predicate 가 있다. 이 인터페이스명은 각 함수의 형태와 목적에 따라 조금 재미있게 붙여진 이름인데 이에 대해서는 뒤에서 자세히 다룬다.

import java.util.function.*;

함수형 인터페이스	메서드 형태	API 활용	매개변수	반환값
Runnable	void run()	매개 변수를 사용 안하고 리턴을 하지 않는 함수 형태로 이용 대표적으로 쓰레드의 매개 변수로 이용	X	X
Consumer<T>	void accept(T t)	매개 변수를 사용만 하고 리턴을 하지 않는 함수 형태로 이용	O	X
Supplier<T>	T get()	매개 변수를 사용 안하고 리턴만 하는 함수 형태로 이용	X	O
Function<T, R>	R apply(T t)	매개값을 매핑(=타입변환)해서 리턴하기	O	O
Predicate<T>	boolean test(T t)	매개값이 조건에 맞는지 단정해서 boolean 리턴	O	O
Operator	R applyAs(T t)	매개값을 연산해서 결과 리턴하기	O	O

(T: 데이터 타입, R: 리턴 타입)

이 처럼 다양한 함수적 형태가 될수 있는 것들을 추려 모아 정리하여 API로 제공함으로써, 우리 같은 개발자들은 굳이 추상 메소드 하나 가진 인터페이스를 일일히 정의할 필요없이 API 만 가져다 쓰면 되는 것이다.

표준 API는 타입 제공 용도이다

자바의 람다식을 변수나 매개변수에 할당하기 위해서는 그에 해당하는 인터페이스 타입이 필요하다.

예를 들어 자바스크립트 같은경우 약타입 언어이기 때문에 다음과 같이 변수에 함수를 대입만하면 알아서 타입 추론이 된다.

let a = () => {};

하지만 자바는 강타입 언어이기 때문에 어떠한 정수면 정수에 맞는 타입을, 함수면 함수에 맞는 타입을 지정해 주어야 한다. 그래서 람다 함수를 담을 수 있는 대표할 타입을 인터페이스 타입으로 정한 것이라고 이해하면 된다. (정확히는 인터페이스 익명 구현 객체를 간략화 한 것이다)

@FunctionalInterface
public interface Animal {
		public void run();
}

// run() 이라는 메서드를 인터페이스 타입으로 선언하여 정의
Animal a = () -> {};

그런데 함수형 인터페이스라고 하지만 사실상 인터페이스명이 딱히 정해져 있지 않기 때문에 문제가 발생한다. 그냥 추상 메소드 한개만 가지고 있으면 모든 인터페이스는 함수적 인터페이스로 취급될 수 있기 때문이다.

이것이 왜 문제냐면 메소드를 설계할때 애매해진다. 만일 파라미터로 람다 함수를 받는 어떠한 메소드를 설계한다고 하면, 이 매개변수의 인터페이스 타입명을 지정하는데 애로사항이 생긴다. 라이브러리 사용자가 인터페이스 타입명을 어찌 지을지 어떻게 알고 강타입 언어인 자바에서 설계를 하느냐인 문제이다.

따라서 자바 개발진들이 미리 함수형 인터페이스 이름들을 정해 제공하는 것이 위의 표에서 본 Runnable, Consumer, Supplier, Function, Operator, Predicate 인터페이스인 것이다.

Runnable 인터페이스

함수형 인터페이스와 람다 함수를 이해하는데 있어 가장 좋은 것이 바로 Runnable 인터페이스이다. 실제 자바 패키지에 정의 되어있는 Runnalbe 인터페이스 선언 코드를 보면 다음과 같이 되어 있다.

뭘 달린다 혹은 실행한다라는 의미인것 같은데 당최 이러한 인터페이스는 왜 만들었는지 어디에 사용되는지 애매모호하다.

앞서 말했듯이 이러한 인터페이스들을 만든 이유는 람다 함수의 타입명을 미리 지정하기 위해서 라고 했다. 즉, 매개변수를 받지도 않고 리턴값이 없고 그냥 실행만 하는 람다 함수 형태를 받는 메서드를 설계할때 람다 매개변수의 인터페이스 타입을 Runnable로 설정하면 되는 것이다. 그리고 그 메소드가 바로 우리가 잘 아는 Thread 클래스의 메서드(생성자)이다.

Thread thread = new Thread( () -> {
    for(int i = 0; i < 10; i++) {
        System.out.println(i);
    }
} );

실제 Thread 클래스 정의문에 가서 생성자 형태를 보면 다음과 같이 파라미터로 Runnalbe 타입의 ~~target~~ 변수를 받아 사용한 다는 것을 볼 수 있다.

이것이 함수형 인터페이스 표준 API의 존재 이유다. Runnalbe외에도 여러가지 자바 메소드에서 미리 파라미터 타입으로 정의된 여러 종류의 함수형 인터페이스 표준 API에 정의된 타입을 받도록 설계하였기 때문에 자유롭게 람다식을 할당 할 수 있는 것이다.

함수형 인터페이스 API 사용법

이제부터 함수적 인터페이스 API의 구체적인 사용법에 대해 상세히 알아볼 시간을 가질텐데, 엄청난 양의 표준 API를 보고 절대 겁먹지 말자. 절대로 일일히 다 외우려 하지말고 String 이나 List 클래스의 메서드 처럼 필요할때마다 찾아서 사용하면 된다.

이 표준 API들은 사실상 알고보면 별거 아닌 놈들이다. 단어만 그럴싸하게 함수형 인터페이스 API 라고 하지, 그냥 람다식을 이용해 프로그래밍할때 자주 사용될것 같은 함수 모양, 형태를 미리 만들어놓고 인터페이스 이름만 아주 그럴싸하게 전문가 처럼 지어놓은 것 뿐이다.

예를들어 바로 다음에 배울 Consumer 인터페이스 API도 그냥 뭔가 대단한 자료형 마냥 보이겠지만, 그냥 매개변수만 받고 반환값이 없는 형태의 함수를 표현하기 위해 '소비' 라는 단어를 골라 넣은 것 뿐이다. 그리고 자바에는 타입이 여러개이니 각 타입들에 맞춰 Consumer 를 여러개로 구성한 것이다.

이 점을 유의해서 인터페이스 표준 API를 살펴보면 공부에 대한 거부감이나 압박감 없이 스무스하게 학습 할 수 있을 것이다.

Consumer 인터페이스

역할 : 매개값만 받고 처리 (리턴값 X)
실행 메서드 : ~~accept()~~
소비(consume)한다는 말은 사용만 할 뿐 리턴값이 없다는 뜻으로 보면 된다.

인터페이스 형태	내용
Consumer<T>	T 형태의 인자값을 받는다
BiConsumer<T, U>	T, U 형태의 인자값 2개를 받는다
XXXConsumer	XXX 형태의 인자값을 받는다
ObjXXXConsumer<T>	T, XXX 형태의 인자값 2개를 받는다

BiConsumer의 Bi 뜻은, 라틴어에서 파생된 영어 접두사 bi- 로 "둘"을 의미한다. 따라서 매개변수를 두개 받는다로 이해하며 암기하면 된다.

Consumer 종류

인터페이스 명	추상 메소드	설명
Consumer<T>	void accept(T t)	객체 T를 받아 소비
BiConsumer<T, U>	void accept(T t, U u)	객체 T와 U를 받아 소비
DoubleConsumer	void accept(double value)	double 값을 받아 소비
IntConsumer	void accept(int value)	int 값을 받아 소비
LongConsumer	void accept(long value)	long 값을 받아 소비
ObjDoubleConsumer<T>	void accept(T t, double value)	객체 T와 double 값을 받아 소비
ObjIntConsumer<T>	void accept(T t, int value)	객체 T와 int 값을 받아 소비
ObjLongConsumer<T>	void accept(T t, long value)	객체 T와 long 값을 받아 소비

public static void main(String[] args) {

    // 객체 T를 받아 출력하는 함수 정의
    Consumer<String> c1 = t -> System.out.println("입력값 : "+ t);
    c1.accept("홍길동");

    // 객체 T와 U를 받아 출력하는 함수 정의
    BiConsumer<String, Integer> c2 =  (a, b) -> System.out.println("입력값1 : "+ a+ ", 입력값2 : "+ b);
    c2.accept("홍길동", 100);

    // int 값을 받아 출력하는 함수 정의
    IntConsumer c3 = a -> System.out.println("입력값 : "+ a);
    c3.accept(100);

    // double 값을 받아 출력하는 함수 정의
    DoubleConsumer c4 = a -> System.out.println("입력값 : "+ a);
    c4.accept(100.01);

    // long 값을 받아 출력하는 함수 정의
    LongConsumer c5 = a -> System.out.println("입력값 : "+ a);
    c5.accept(2100000000);
}

만일 3개 이상의 매개변수를 받는 람다 함수를 만들고 싶다면, 직접 인터페이스를 정의해서 사용하여야 한다.

interface TripleConsumer<T, U, K> {
    void accept(T t, U u, K k);
}

public class Main {
    public static void main(String[] args) {

        TripleConsumer<String, Double, Integer> c1 = (t, u, k) -> {
        	System.out.printf("%s + %f + %d", t, u, k);
        };
        
        c1.accept("안녕", 101.23, 999);
    }
}

Supplier 인터페이스

역할 : 아무 매개값 없이 리턴값만을 반환
실행 메서드 : ~~getXXX()~~
생산(supply)한다는 말은 데이터를 반환(공급) 한다는 뜻으로 보면 된다.

인터페이스 형태	내용
Supplier<T>	T형 반환
XXXSupplier	XXX형 반환

Supplier 종류

인터페이스 명	추상 메소드	설명
Supplier<T>	T get()	T 객체를 리턴
BooleanSupplier	Boolean getAsBoolean()	Boolean 값을 리턴
DoubleSupplier	double getAsDouble()	double 값을 리턴
IntSupplier	int getAsInt()	int 값을 리턴
LongSupplier	long getAsLong()	long 값을 리턴

public static void main(String[] args) {

    // T 객체를 리턴하는 함수 정의
    Supplier<Object> supplier = () -> new Object();
    System.out.println(supplier.get());

    // Boolean 값을 리턴하는 함수 정의
    BooleanSupplier booleanSup =  () -> true;
    System.out.println(booleanSup.getAsBoolean());

    // int 값을 리턴하는 함수 정의
    IntSupplier intSup = () -> {
        int num = (int) (Math.random() * 6) + 1;
        return num;
    };
    System.out.println("주사위 랜덤 숫자 : " + intSup.getAsInt());

    // double 값을 리턴하는 함수 정의
    DoubleSupplier doubleSup = () -> 1.0;
    System.out.println(doubleSup.getAsDouble());

    // long 값을 리턴하는 함수 정의
    LongSupplier longSup = () -> 1L;
    System.out.println(longSup.getAsLong());
}

Function 인터페이스

역할 : 매핑(타입 변환)하기
실행 메서드 : ~~applyXXX()~~
매핑 한다는 말은, 예를들어 여러 데이터 항목들이 들은 객체에서 특정 타입 값을 추출하거나 혹은 다른 타입으로 변환하는 작업에 사용한다고 보면 된다.

인터페이스 형태	내용
Function<T, R>	T 받아서 R 리턴
BiFunction<T, U, R>	T, U 받아서 R 리턴
XXXFunction<T>	XXX 받아서 T 리턴
XXXtoYYYFunction	XXX 받아서 YYY 리턴
toXXXFunction<T>	T 받아서 XXX 리턴
toXXXBiFunction<T, U>	T, U 받아서 XXX 리턴

T와 U는 매개변수 타입이고 R을 리턴(return) 타입 기호하고 보면 된다.

Function 종류

인터페이스 명	추상 메소드	설명
Function<T, R>	R apply(T t)	객체 T를 객체 R로 매핑
BiFunction<T, U, R>	R apply(T t, U u)	객체 T와 U를 객체 R로 매핑
DoubleFunction<R>	R apply(double value)	double을 객체 R로 매핑
IntFunction<R>	R apply(int value)	int를 객체 R로 매핑
IntToDoubleFunction	double applyAsDouble(int value)	int를 double로 매핑
IntToLongFunction	long applyAsLong(int value)	int를 long으로 매핑
LongToDoubleFunction	double applyAsDouble(long value)	long을 double로 매핑
LongToIntFunction	int applyAsInt(long value)	long을 int로 매핑
ToDoubleBiFunction<T, U>	double applyAsDouble(T t, U u)	객체 T와 U를 double로 매핑
ToDoubleFunction<T>	double applyAsDouble(T value)	객체 T를 double로 매핑
ToIntBiFunction<T, U>	int applyAsInt(T t, U u)	객체 T와 U를 int로 매핑
ToIntFunction<T>	int applyAsInt(T t)	객체 T를 int로 매핑
ToLongBiFunction<T, U>	long applyAsLong(T t, U u)	객체 T와 U를 long으로 매핑
ToLongFunction<T>	long applyAsLong(T t)	객체 T를 long으로 매핑

public static void main(String[] args) {

    // int형을 String으로 타입 변환하는 함수 정의
    Function<Integer, String> intToStr = t -> String.valueOf(t);
    String str = intToStr.apply(100);

    // String을 int형으로 타입 변환하는 함수 정의
    ToIntFunction<String> strToInt = t -> Integer.parseInt(t);
    int num = strToInt.applyAsInt("100");

    // int형을 double형으로 타입 변환하는 함수 정의
    IntToDoubleFunction intToDouble = t -> (double) t;
    double d = intToDouble.applyAsDouble(100);
}

class Student {
    private String name;

    int korean_score;
    int english_score;
    int math_score;

    Student(String name, int korean_score, int english_score, int math_score) {
        this.name = name;
        this.korean_score = korean_score;
        this.english_score = english_score;
        this.math_score = math_score;
    }

    String getName() {
        return name;
    }
}

public static void main(String[] args) {

    List<Student> list = List.of(
            new Student("홍길동", 99, 12, 45),
            new Student("임꺽정", 76, 20, 8),
            new Student("고담덕", 36, 50, 33),
            new Student("김좌진", 77, 89, 91)
    );

    // 각 학생의 이름 가져오는 함수 정의 (매개타입 : Student 객체, 리턴타입 : String형)
    Function<Student, String> getNameFunc = (s) -> s.getName();

    // 각 학생의 교과목 평균 계산하고 가져오는 함수 정의 (매개타입 : Student 객체, 리턴타입 : int형)
    ToDoubleFunction<Student> getScoreFunc = (s) -> {
        int sum = s.korean_score + s.english_score + s.korean_score;
        double avg = sum / 3.0;
        return avg;
    };

    for (Student student : list) {
        String name = getNameFunc.apply(student);
        double avg = getScoreFunc.applyAsDouble(student);
        System.out.printf("%s 평균 점수 : %f\n", name, avg);
    }
}

Operator 인터페이스

역할 : 매개값 계산해서 동일한 타입으로 리턴하기
실행 메서드 : ~~applyXXX()~~
Function과 비슷하지만, 매개값을 리턴값으로 매핑(타입 변환)하는 역할보다는 매개값을 이용해서 연산을 수행한 후 동일한 타입으로 리턴값을 제공하는 역할에 초점이 가있다.

인터페이스 형태	내용
UnaryOprater<T>	T타입 연산하고 리턴
BinaryOperator<T>	T타입 연산하고 리턴
XXXUnaryOperator	XXX 타입 1개 연산
XXXBinaryOperator	XXX 타입 2개 연산

Unary는 단항(연산이 1개) 이고, Binary는 이항(연산이 2개) 이라는 뜻이다.

Operator 종류

인터페이스 명	추상 메소드	설명
UnaryOperator<T>	T apply(T t) Function<T, R>의 하위 인터페이스	T를 연산한 후 R 리턴
BinaryOperator<T>	T apply(T t, T u) BiFunction<T, U, R>의 하위 인터페이스	T와 U를 연산 후 R 리턴
DoubleUnaryOperator	double applyAsDouble(double)	한 개의 double을 연산
DoubleBinaryOperator	double applyAsDouble(double, double)	두 개의 double을 연산
IntUnaryOperator	int applyAsInt(int)	한 개의 int를 연산
IntBinaryOperator	int applyAsInt(int, int)	두 개의 int를 연산
LongUnarayOperator	long applyAsLong(long)	한 개의 long을 연산
LongBinaryOperator	long applyAsLong(long, long)	두 개의 long을 연산

class Operation {
    static int calculate(int[] arr, IntBinaryOperator o) {
        int result = arr[0];

        for (int i = 1; i < arr.length; i++) {
            result = o.applyAsInt(result, arr[i]);
        }

        return result;
    }
}

public static void main(String[] args) {

    int[] numbers = {3, 1, 7, 6, 5};

    // 배열 요소의 모든 합 구하기
    int sum = Operation.calculate(numbers, (x, y) -> {
        return x + y;
    });
    System.out.println(sum);

    // 배열 요소의 모든 곱 구하기
    int mul = Operation.calculate(numbers, (x, y) -> {
        return x * y;
    });
    System.out.println(mul);

    // 배열 요소중 가장 큰 수 구하기
    int max = Operation.calculate(numbers, (x, y) -> {
        int tmp;

        if(x > y)
            tmp = x;
        else
            tmp = y;

        return tmp;
    });
    System.out.println(max);

    // 배열 요소중 가장 작은 수 구하기
    int min = Operation.calculate(numbers, (x, y) -> {
        int tmp;

        if(x < y)
            tmp = x;
        else
            tmp = y;

        return tmp;
    });
    System.out.println(min);
}

Predicate 인터페이스

역할 : 매개값을 받고 true / false 리턴
실행 메서드 : ~~test()~~
매개값을 받아 참/거짓을 단정(predicate) 한다고 생각하면 된다.

인터페이스 형태	내용
Predicate<T>	T 를 받아 boolean 리턴
BiPredicate<T, U>	T, U를 받아 boolean 리턴
XXXPredicate	XXX를 받아 boolean 리턴

Predicate 종류

인터페이스 명	추상 메소드	설명
Predicate<T>	Boolean test(T t)	객체 T를 조사
BiPredicate<T, U>	Boolean test(T t, U u)	객체 T와 U를 비교 조사
DoublePredicate	Boolean test(double value)	double 값을 조사
IntPredicate	Boolean test(int value)	int 값을 조사
LongPredicate	Boolean test(long value)	long 값을 조사

class Student {
    String name;
    int score;

    public Student(String name, int score) {
        this.name = name;
        this.score = score;
    }
}

public static void main(String[] args) {

    List<Student> list = List.of(
            new Student("홍길동", 99),
            new Student("임꺽정", 76),
            new Student("고담덕", 36),
            new Student("김좌진", 77)
    );

    // int형 매개값을 받아 특정 점수 이상이면 true 아니면 false 를 반환하는 함수 정의
    IntPredicate scoring = (t) -> {
        return t >= 60;
    };

    for (Student student : list) {
        String name = student.name;
        int score = student.score;
		
        // 함수 실행하여 참 / 거짓 값 얻기
        boolean pass = scoring.test(score);
        
        if(pass) {
            System.out.println(name + "님 " + score + "점은 국어 합격입니다.");
        } else {
            System.out.println(name + "님 " + score + "점은 국어 불합격입니다.");
        }
    }
}

함수형 인터페이스 디폴트 메서드

Function 합성

중고등학생때 수학 시간에 ~~f(x)~~ 함수와 ~~g(x)~~ 함수가 있을 때, 이 두 함수를 합성하여 ~~f(g(x))~~ 라는 합성 함수를 다뤄본 기억이 어렴풋이나마 있을 것이다. ~~f(g(x))~~ 는 ~~g(x)~~의 결과를 다시 ~~f(x)~~ 함수의 인자로 넣어준 것이다.

이처럼 두 람다 함수를 연결하여 합성시킬 수 있는데, 이 합성 시키는 메서드를 자바에서 함수형 인터페이스의 디폴트 메서드로서 제공한다.

인터페이스 메서드	설명
default <V> Function <T, V> andThen (Function <? super R, ? extends V> after);	f(g(x)) 합성함수
default <V> Function <V, R> compose(Function <? super V, ? extends T> before);	g(f(x)) 합성함수 (andThen의 반대)
static <T> Function<T, T> identity();	항등함수 (자기 자신 반환)

합성 함수는 Function 인터페이스 뿐만 아니라 Consumer 이나 Operator 인터페이스도 존재한다.

람다 합성 사용 예시 1

간단한 수학 함수를 코드로 표현해 보았다. 숫자를 받으면 4를 빼는 함수 f(x) 와 숫자를 받으면 두배 곱해주는 함수 g(x) 를 람다표현식으로 선언하였다. 그리고 이 둘을 andThen 과 compose로 합성하여 사용하면 다음과 같다.

public static void main(String[] args) {

    Function<Integer, Integer> f = num -> (num - 4); // f(x)
    Function<Integer, Integer> g = num -> (num * 2); // g(x)

    // f(g(x))
    int a = f.andThen(g).apply(10);
    System.out.println(a); // (10 - 4) * 2 = 12

    // g(f(x)) - andThen을 반대로 해석하면 된다
    int b = f.compose(g).apply(10);
    System.out.println(b); // 10 * 2 - 4 = 16

}

andThen 과 compose 의 차이는 간단하다.

~~f.andThen(g)~~ 를 수행하면 f 함수를 실행한 결과 값을 다시 g 함수의 인자로 전달하여 결과를 얻게 된다. 단, f 함수의 리턴 타입이 g 함수의 매개변수 타입과 호환되어야 한다.

~~f.compose(g)~~ 를 수행하면 g 함수를 실행한 결과 값을 다시 f 함수의 인자로 전달하여 결과를 얻게 된다. 즉, andThen의 반대 버전이라고 보면 된다.

즉, ~~x.andThen(y)~~ 는 ~~y.compose(x)~~ 와 동일하다고 보면 된다.

람다 합성 사용 예시 2

다음 Member 클래스와 Address 클래스가 있고, Member 클래스에서 Address 객체를 합성(composition) 하여 가지고 있다. 이 객체끼리 합성된 관계를 합성 함수를 통해 멤버의 도시 주소값을 불러오는 간단한 예제이다.

class Member {
    private String name;
    private Address address; // Address 객체를 합성(composition)

    public Member(String name, Address address) {
        this.name = name;
        this.address = address;
    }

    public String getName() { return name; }

    public Address getAddress() { return address; }
}

class Address {
    private String country;
    private String city;

    public Address(String country, String city) {
        this.country = country;
        this.city = city;
    }

    public String getCountry() { return country; }

    public String getCity() { return city; }
}

public static void main(String[] args) {

    Member member = new Member("홍길동", new Address("조선", "한양"));

    // Member 매개타입과 Address 리턴타입
    Function<Member, Address> f = x -> x.getAddress(); // Address 객체를 얻기

    // Address 매개타입과 String 리턴타입
    Function<Address, String> g = x -> x.getCity(); // city 문자열 얻기

    // f(g(x))
    Function<Member, String> fg = f.andThen(g);
    String city = fg.apply(member); // Address 객체를 얻고(f 실행), Address 객체에서 city 필드값을 얻기(g 실행)
    System.out.println("거주 도시 : " + city);

    fg = g.compose(f);
    city = fg.apply(member);
    System.out.println("거주 도시 : " + city);
}

Predicate 결합

Predicate 함수형 인터페이스는 참 / 거짓 값을 리턴하는 함수를 다룬다. 즉, true / false 조건식에 대하여 이들을 결합하여 and 연산, or 연산을 행한다고 보면 된다.

인터페이스 메소드	설명
default Predicate<T> and (Predicate<? super T> other)	and 연산
default Predicate<T> or (Predicate<? super T> other)	or 연산
default Predicate<T> negate()	역 부정
static <T> Predicate<T> isEqual(Object targetRef)	객체 비교

람다 결합 사용 예시

조건문을 구성할때 ~~if(x > 10 && x < 20)~~ 이런식으로 조건 연산자를 이용해 범위를 구성해본적이 있을 것이다. 이것을 람다 함수로 표현한 것이라고 보면 된다.

public static void main(String[] args) {

    Predicate<Integer> greater = x -> x > 10;
    Predicate<Integer> less = x -> x < 20;

    // x > 10 && x < 20
    Predicate<Integer> between = greater.and(less); 
    System.out.println(between.test(15)); // true

    // x > 10 || x < 20
    Predicate<Integer> all = greater.or(less); 
    System.out.println(all.test(5)); // true

    // x <= 10
    Predicate<Integer> negate = greater.negate(); 
    System.out.println(negate.test(50)); // false
}

~~isEqual()~~ 정적 인터페이스 메소드는 입력값으로 받은 객체와 같은지 판단해주는 메소드 이다. 그냥 ~~equals()~~ 를 람다 함수로 표현한 것이라고 보면 된다.

public static void main(String[] args) {
    // 함수의 인자로 들어온 문자열이 "홍길동" 인지 판별해주는 함수
    Predicate<String> checkMyName = Predicate.isEqual("홍길동");

    System.out.println(checkMyName.test("임꺽정")); // false
    System.out.println(checkMyName.test("홍길동")); // true
}

자바 컬렉션의 함수형 인터페이스

마지막으로 자바의 컬렉션 프레임워크에 함수형 인터페이스와 함께 사용할 수 있는 메서드도 별도로 지원한다.

인터페이스	메서드	설명
Collection	boolean removeIf(Predicate<E> filter);	조건에 맞는 엘리먼트를 삭제
List	void replaceAll(UnaryOperator<E> operator);	모든 엘리먼트에 operator를 적용하여 대체(replace)
Iterable	void forEach(Consumer<T> action);	모든 엘리먼트에 action 수행

인터페이스	메서드	설명
Map	V compute(K key, BiFunction<K, V, V> f);	지정된 키에 해당하는 값에 f를 수행
Map	V computeIfAbsent(K key, Function<K, V> f);	지정된 키가 없으면 f 수행후 추가
Map	V cumputeIfPresent(K key, BiFunction<K, V, V> f)	지정된 키가 있을 때, f 수행
Map	V merge(K key, V value, BiFunction<V, V, V> f);	모든 엘리먼트에 Merge 작업 수행, 키에 해당하는 값이 있으면 f 수행해서 병합후 할당
Map	void forEach(BiConsumer<K, V> action);	모든 엘리먼트에 action 수행
Map	void replaceAll(BiFunction<K, V, V> f);	모든 엘리먼트에 f 수행후 대체

public static void main(String[] args) {
    List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);

    // 각 요소에 10을 곱함
    list.replaceAll( (x) -> x * 10 );

    // 리스트는 Iteratble을 상속하니까 사용이 가능
    list.forEach( (x) -> System.out.println(x) );
}

함수형 인터페이스 API 사용 정리표

보다시피 함수형 인터페이스 종류는 결코 적은게 아니라 하나하나 기억하기 애매하기도 하고, 언제 어느때 인터페이스 타입을 골라 사용할지 바로 떠올리기도 힘들다. 그래서 한눈에 들어올 수 있게 잘 정리된 도식을 가져와 보았다.

왼쪽 세로 부분은 매개변수 타입을 나타내는 것이고, 각 표의 위쪽 부분은 함수 반환 타입을 나타내는 것이다. 만일 double 형 매개변수를 받아 void 로 행하는 함수형 인터페이스가 무엇인지 찾으려면, 왼쪽에서 (double) → 을 찾고 표 상단의 → void 를 매치해보면 바로 DoubleConsumer 인터페이스를 사용한다는 것을 알 수 있게 된다.

# 참고자료

https://hbase.tistory.com/78

https://palpit.tistory.com/673

http://blog.orfjackal.net/2014/07/java-8-functional-interface-naming-guide.html

☕ 람다 표현식(Lambda Expression) 완벽 정리

인파_ — Mon, 27 Mar 2023 09:09:16 +0900

람다 표현식 (Lambda Expression)

람다 표현식(lambda expression)이란 함수형 프로그래밍을 구성하기 위한 함수식이며, 간단히 말해 자바의 메소드를 간결한 함수 식으로 표현한 것이다.

지금까지 자바에서는 메서드를 하나 표현하려면 클래스를 정의해야 했다. 하지만 람다식으로 표현하면 메서드의 이름과 반환값을 생략할 수 있고 이를 변수에 넣어 자바 코드가 매우 간결해지는 장점이 있다.

아래 그림에서 보듯이 ~~int add(int a, int b) {}~~ 메소드 표현식을, 메서드 타입, 메서드 이름, 매개변수 타입, 중괄호, return 문을 생략하고, 화살표 기호를 넣음으로써 코드를 혁명적으로 함축했음을 볼 수 있다. 이러한 특징으로 람다식을 이름이 없는 함수 익명 함수(anonymous function) 라고도 한다.

int add(int x, int y) {
    return x + y;
}

// 위의 메서드를 람다 표현식을 이용해 아래와 같이 단축 시킬수 있다. (메서드 반환 타입, 메서드 이름 생략)
(int x, int y) -> {
	return x + y;
};

// 매개변수 타입도 생략 할 수 있다.
(x, y) -> {
	return x + y;
};

// 함수에 리턴문 한줄만 있을 경우 더욱 더 단축 시킬 수 있다. (중괄호, return 생략)
(x, y) -> x + y;

타입을 생략을 해도 컴파일러가 에러를 띄우지않는 이유는, 컴파일러 나름대로 생략된 타입 위치를 추론하여 동작하게 해주기 때문이다.

람다식이 처음에는 생소하게 느껴져 오히려 거부감이 들 수 있다. 하지만 문법이 혁신적으로 간결해 지는 것만큼, 람다식에 익숙해지면 가독성 면에서 큰 장점을 얻게 된다. 특히 컬렉션(Collection)의 요소를 필터링하거나 매핑하여 원하는 결과를 쉽게 얻을 수 있다.

람다식과 자바스크립트 익명 화살표 함수

만일 자바를 배우기 앞서 자바스크립트 프로그래밍을 먼저 배운 독자 분들이라면 자바의 람다 표현식을 이해하는데 있어 매우 수월할 것이다. 사실 자바스크립트의 익명 화살표 함수 자체가 람다 함수 일종이기 때문이다. 괄호를 생략하거나 등 람다의 기본 문법 체계도 자바와 자바스크리브 둘다 비슷하다. 단지 화살표 모양이 => 와 -> 로 다를 뿐이다.

람다식을 자바스크립트 문법 형태와 자바의 문법 형태를 비교하자면 아래 코드와 같다.

const MyFunction = {
    print: function() {}
};

MyFunction.print = (str) => console.log(str);
let myfunc = MyFunction;
myfunc.print("Hello World");

interface MyFunction {
	void print(String str);
}

public class Main {
    public static void main(String[] args) {
        MyFunction myfunc = (str) -> System.out.println(str);
        myfunc.print("Hello World");
    }
}

변수에 함수를 담을때, 자바스크립트는 약타입 언어라 타입에 관계없이 자유롭게 받을 수 있지만, 자바 같은 경우 강타입 언어 이기 때문에 반드시 함수에 대한 타입을 선언하여야 한다. 하지만 자바에는 8가지 타입(primitive 타입과 reference 타입) 밖에 없기 때문에 함수 데이터 자체를 담을수 있을만한 자료형이 딱히 적합한 것이 없다. 그래서 자바 개발진들은 인터페이스를 익명 구현 객체 타입으로써, 함수를 해당 인터페이스 타입으로 받을 수 있게 설계한 것이다.

람다식과 함수형 인터페이스

람다식의 형태를 보면 마치 자바의 메소드를 변수로 선언하는 것 처럼 보이지만, 사실 자바는 메소드를 단독으로 선언할 수는 없다. 형태만 그렇게 보일 뿐이지 코드를 보면 람다 함수식을 변수에 대입하고 변수에서 메서드를 호출해서 사용하는 것이 마치 객체와 다름이 없다.

MyFunction myfunc = (str) -> System.out.println(str);
myfunc.print("Hello World");

사실 람다식도 결국은 객체이다. 정확히 말하면 인터페이스를 익명 클래스로 구현한 익명 구현 객체를 짧게 표현한 것 뿐이다.

객체 지향 방식 vs 람다 표현 방식

이에 대해서 기존 자바7에서 표현 했던 객체 지향 방식과 람다 표현 방식을 비교해보며 이해해보자.

다음 IAdd 라는 인터페이스가 있고 ~~add()~~ 추상 메서드가 있다. 우리는 이 인터페이스를 구현하여 메서드를 정의해 덧셈 기능을 이용할 예정이다.

기존에는 인터페이스를 클래스에 implements 하고 오버라이딩하여 사용해 왔다.

interface IAdd {
    int add(int x, int y);
}

class Add implements IAdd {
    public int add(int x, int y) {
        return x + y;
    }
}
        
public class Main {
    public static void main(String[] args) {
        // 생 클래스로 메소드 사용하기
        Add a = new Add();
        
        int result1 = a.add(1, 2);
        System.out.println(result1);
    }
}

더 나아가선 한번만 사용하고 버려질 클래스라면, 굳이 번거롭게 클래스를 선언하지 말고 익명 클래스로 일회용 오버라이딩 하여 사용하기도 하였다.

interface IAdd {
    int add(int x, int y);
}

public class Main {
    public static void main(String[] args) {
        // 익명 클래스로 정의해 사용하기 (일회용)
        Iadd a = new IAdd() {
            public int add(int x, int y) {
                return x + y;
            }
        };
        
        int result2 = a.add(1, 2);
        System.out.println(result2);
    }
}

그리고 람다는 이 익명클래스 코드 부분을 짧게 표현한 것이다.

interface IAdd {
    int add(int x, int y);
}

public class Main {
    public static void main(String[] args) {
        // 람다 표현식으로 함축 하기
        IAdd lambda = (x, y) -> { return x + y; }; // 람다식 끝에 세미콜론을 잊지말자
        
        int result3 = lambda.add(1, 2);
        System.out.println(result3);
    }
}

람다식 객체를 콘솔에 출력 해보면, 익명 클래스 표현 형식과 또다른 ~~외부클래스명$$Lambda$번호~~ 와 같은 독자적인 표현 형식을 지니고 있음을 알 수 있다.

즉, 아무 클래스나 추상 클래스의 메소드를 람다식으로 줄이거나 하는 행위는 못한다라는 뜻이다. 오로지 인터페이스로 선언한 익명 구현 객체만이 람다식으로 표현이 가능하다. 그리고 람다 표현이 가능한 이러한 인터페이스를 가리켜 함수형 인터페이스라 총칭한다.

함수형 인터페이스 란?

함수형 인터페이스란 딱 하나의 추상 메소드가 선언된 인터페이스를 말한다. 위의 IAdd 인터페이스 예제 코드가 바로 함수형 인터페이스 이다. 그리고 람다식은 함수형 인터페이스 안에 정의된 하나의 추상 메소드 선언을 짧게 표현한 것이다.

생각해보면 람다식 자체가 하나의 메소드를 한줄로 정의하는 표현식이기 때문에, 인터페이스에 두개 이상 추상 메서드가 들어있으면 이를 코드로 겹쳐 표현할 방법이 달리 없기 때문에, 오로지 추상 메소드 한개만 가진 인터페이스가 람다식의 타겟 타입(targe type)이 될 수 있는 것이다.

단, Java 8 버전 부터 이용이 가능한 인터페이스의 final 상수나 default, static, private 메서드는 추상 메서드가 아니기 때문에, 이들 여러개가 인터페이스에 들어있어도 오로지 추상 메서드가 한개이면 함수형 인터페이스로 취급 된다.

// 함수형 인터페이스가 될 수 있다.
interface IAdd {
    int add(int x, int y);
}

// 함수형 인터페이스가 될수 없다.
interface ICalculate {
    int add(int x, int y);
    int min(int x, int y);
}

// 구성요소가 많아도 결국 추상 메서드는 한개이기 때문에 함수형 인터페이스이다.
interface IAdd {
    int add(int x, int y);

    final boolean isNumber = true; // final 상수
    default void print() {}; // 디폴트 메서드
    static void print2() {}; // static 메서드
}

@FunctionalInterface

나만의 함수적 인터페이스를 만들 때 두 개 이상의 추상 메소드가 선언되지 않도록 컴파일러가 checking 해주는 기능이 있는데, 인터페이스 선언 시 ~~@FunctionalInterface~~ 어노테이션을 붙여주게 된다면 두 개 이상의 메소드 선언 시 컴파일 오류를 발생시켜준다. 이는 개발자의 실수를 줄여주는 역할을 한다.

@FunctionalInterface
public interface MyFunctional {
    public void method();
    public void otherMethod(); // 컴파일 오류 발생
}

이밖의 함수형 인터페이스의 개념 원리 및 자바에서 제공하는 함수형 인터페이스 표준 API 종류에 대해서 상세히 이해하고 싶다면 다음 포스팅을 참고하길 바란다.

☕ 함수형 인터페이스 표준 API 총정리

함수형 인터페이스 표준 API 함수형 인터페이스(functional interface)는 추상메서드가 1개만 정의된 인터페이스를 통칭하여 일컫는다. 이 인터페이스 형태의 목적은 자바에서 람다 표현식(Lambda Expressi

inpa.tistory.com

람다식의 타입 추론

람다식으로 코드를 혁신적으로 줄일 수 있다는 점은 알았다. 그런데 리턴 타입도 파라미터 타입도 없는 람다식을 컴파일러가 이 함수가 어떤 타입 함수인지 알고 문법을 허용하는 것일까?

사실 컴파일러 스스로 람다 함수식을 보고 추론하여 타입을 유추하기 때문에 가능한 것이다. 무슨 AI 처럼 추론할 정도는 아니고 사람이 미리 정의해놓은 정의문을 보고 추론해주는 것이다.

위의 예제는 아주 간단한 예제이고, 대부분의 함수형 인터페이스를 이용하게 되면 제네릭(Generics)을 사용하게 되는데, 컴파일러가 타입을 추론하는 데 필요한 타입 정보 대부분을 제네릭에서 판별하여 얻는다고 보면 된다.

다음 코드를 봐보자. List 자료형을 만들고 리스트의 타입 파라미터를 String으로 지정하였다. 그리고 Collections 클래스의 ~~sort~~ 메소드를 불러와 첫번째 매개변수로는 리스트 객체를 두번째 매개변수로는 람다 함수를 전달 하였다.

import java.util.Arrays;
import java.util.Collections;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> words = Arrays.asList("aaa", "bbb", "ccc", "ddd");

        Collections.sort(words, (s1, s2) -> Integer.compare(s1.length(), s2.length()));
    }
}

참고로 아래의 Collections 클래스의 sort 메서드 정의문을 보면, 람다함수의 함수형 인터페이스 타입은 ~~java.util.Comparator~~ 로 지정되어 있으며, 람다의 매개변수 타입은 Comparator 인터페이스의 제네릭 T 타입으로 지정되어 있는걸 볼 수 있다.

이러한 형태에서 컴파일러가 타입을 유추하는 순서는 다음과 같이 된다.

sort 메소드의 첫번째 매개변수로 List<String> 형태의 객체가 들어온다.
첫번째 매개변수의 타입 지정에 의해 sort 메소드의 제네릭 타입 매개변수는 모두 String으로 지정되게 된다.
따라서 Comparator 인터페이스 제네릭 타입도 String으로 지정되며, 추상 메서드의 매개변수 타입도 String으로 지정된다.
최종적으로 람다 함수의 타입 구성은 int형 메소드 반환 타입과 String 형 매개변수 타입 두개로 추론되게 된다.

단, 개발자 입장에선 코드를 복기할때 람다식의 타입을 위와 같이 유추하기에는 시간이 걸리기에, 상황에 따라 명시적으로 람다식 파라미터에 타입을 기재하기도 한다. 무엇이 좋은지 정답은 없고 상황에 따라 개발자가 결정해야 한다.

Collections.sort(words, (String s1, String s2) -> Integer.compare(s1.length(), s2.length()));

람다 표현식 활용하기

다양한 람다식의 할당

람다식의 가장 큰 특징은 바로 변수에 정수를 할당하듯이 함수를 할당할 수 있다는 것이다.

사실 함수도 일반 데이터 처럼 메모리 주소가 할당 되어 있다. 지금까지 클래스로 메소드를 사용해왔기에 메소드의 메모리 주소를 변수에 할당하는 일은 없었지만, 람다식을 이용하면 함수(실행코드)의 주소를 사용하여 C언어, 파이썬 같은 함수 스타일의 프로그래밍을 작성할 수 있게 된 것이다.

람다식 변수 할당

interface IAdd {
    int add(int x, int y);
}

public class Main {
    public static void main(String[] args) {
        IAdd lambda = (x, y) -> x + y; // 함수를 변수에 할당
        lambda.add(1, 2); // 함수 사용
    }
}

람다식 매개변수 할당

특히 람다식은 메소드의 매개변수에 바로 입력값으로 넣는 방식으로 정말 자주 애용된다. 이것을 함수를 메소드의 매개변수로 넘겨준다고 표현한다.

interface IAdd {
    int add(int x, int y);
}

public class Main {
    public static void main(String[] args) {
    	int n = result( (x, y) -> x + y ); // 메소드의 매개변수에 람다식을 전달
        System.out.println(n); // 3
    }
    
    public static int result(IAdd lambda) {
    	return lambda.add(1,2);
    }
}

기존의 자바의 메소드 같은 경우 변수에 할당하거나 매개변수로 넣거나 리턴값으로 사용하는 행위는 꿈도 못 꾸어 왔을 것이다. 하지만 람다식이 이런식으로 응용이 가능한 이유는 람다는 익명 함수(Anonymous Function)이며, 익명 함수는 모두 일급 객체로 취급 되기 때문이다.

함수를 매개변수로 전달해서 사용하는 것을 무슨 신박한 기능처럼 소개했지만, 사실 클래스 참조 객체를 넘겨 준 것과 다름이 없다. 왜냐하면 람다식은 익명 구현 객체(익명 클래스)를 심플화 환것이고, 익명 클래스도 결국 클래스 참조 객체이니, 우리가 메소드에 참조 객체를 넘겨 메소드 내에서 객체의 메서드를 사용한 것처럼 별반 다르지 않다.

람다식 반환값 할당

일급 객체의 또다른 특징이라고 말할수 있는 메서드의 반환값을 람다함수 자체를 리턴하도록 지정 해줄 수 있다. 즉, 메서드의 리턴값이 메서드(함수)인 것이다.

interface IAdd {
    int add(int x, int y);
}

public class Main {
    public static void main(String[] args) {
        IAdd func = makeFunction(); // 메소드의 반환값이 람다 함수
        int result = func.add(1, 2);
        System.out.println(result); // 3
    }

    public static IAdd makeFunction() {
        return (x, y) -> x + y;
    }
}

람다식 실전 예제

Thread 호출

자바의 쓰레드를 먼저 배우신 독자 분들이라면, 다음과 같은 코드 문법 구성에 대해 익숙할 것이다.

이는 신박한 문법이 아니고 결국은 자세히 보면 ~~new Thread()~~ 생성자 안에 매개변수로서 람다식을 넣은 것 뿐이다.

Thread thread = new Thread( () -> {
    for (int i = 0; i < 10; i++) {
        System.out.println(i);
    }
});

enum을 깔끔하게

enum 객체의 확장을 조금 더 간결하고 깔끔하게 만들 수도 있다.

[JAVA] ☕ Enum 열거형 타입 문법 & 응용 정리

Enum 열거 타입 먼저 Enum은 "Enumeration"의 약자다. Enumeration은 "열거, 목록, 일람표" 라는 뜻을 가지고 있으며, 보통 한글로는 열거형이라고 부른다. 즉, 열거형(enum)은 요소, 멤버라 불리는 명명된 값

inpa.tistory.com

enum Operation {
    PLUS("+") { 
        public double apply(double x, double y) { return x + y; }
    },
    MINUS("-") {
        public double apply(double x, double y) { return x - y; }
    },
    TIMES("*") {
        public double apply(double x, double y) { return x * y; }
    },
    DIVIDE("/") {
        public double apply(double x, double y) { return x * y; }
    };
    
    private final String symbol;
   
    Operation(String symbol) { this.symbol = symbol; }
    
    @Override public String toString() { return symbol; } 
    public abstract double apply(double x, double y);
}

import java.util.function.DoubleBinaryOperator;

enum Operation {
    PLUS("+", (x, y) -> x + y),
    MINUS("-", (x, y) -> x - y),
    TIMES("*", (x, y) -> x * y),
    DIVIDE("/", (x, y) -> x / y);

    private final String symbol;
    private final DoubleBinaryOperator op;

    Operation(String symbol, DoubleBinaryOperator op) {
        this.symbol = symbol;
        this.op = op;
    }

    @Override
    public String toString() { return symbol; }

    public double apply(double x, double y) {
        return op.applyAsDouble(x, y);
    }
}

public class Main {
    public static void main(String[] args) {
        // 사용은 아래와 같이
        Operation.PLUS.apply(2, 3);
    }
}

람다식의 형변환

사실 람다식은 익명 객체이고 타입이 없다. 정확히 말하면 함수형 인터페이스로 람다식을 참조할 수 있을 뿐이다. 그래서 사실 인터페이스 타입의 변수에 람다식을 할당하는 행위는 캐스팅 연산자가 생략 되어 있다.

IAdd func = () -> {});

IAdd func = (IAdd) (() -> {}); // 원래는 양변의 타입이 다르므로 형변환이 필요

이러한 특징을 이용해 람다식을 모든 클래스의 최상위 클래스인 Object 클래스로 형변환이 가능하다. 이러한 특징이 있다는 정도만 알고 넘어가자.

interface IAdd {
    int add(int x, int y);
}

public class Main {
    public static void main(String[] args) {
        IAdd lambda = (x, y) -> x + y;
        System.out.println(lambda);

        // Object 타입으로 업캐스팅하기 위해선 두번 캐스팅 해주어야 한다
        Object lambda_obj = (Object) (IAdd) ((x, y) -> x + y);
        System.out.println(lambda_obj);
    }
}

람다 표현식의 한계

이처럼 람다표현식은 안그래도 길다란 자바 코드를 말끔히 줄이는데 상당한 일조를 하지만, 단점이나 사용하기에 적절치 못한 경우가 존재한다.

1. 람다는 문서화를 할 수 없다

람다 자체는 이름이 없는 함수이기 때문에 메서드나 클래스와 다르게 문서화를 할 수 없다. 그래서 코드 자체로 동작이 명확하게 설명되지 않거나 람다가 길거나 읽기 어렵다면, 쓰지 않는 방향으로 리팩토링하는 것을 고려해야 한다.

2. 람다는 디버깅이 다소 까다롭다

람다식은 기본적으로 익명 구현 객체 기반이기 때문에, 익명 객체 특성상 디버깅 할때 콜 스택(call stack) 추적이 매우 어려운 단점을 가지고 있다.

예를들어 0을 나누는 같은 오류가 나타나는 코드를 일반 for문과 람다식을 이용한 표현을 코드를 실행하면 다음 과 같이 에러 줄 서부터 확연히 다른걸 볼 수 있다.

public static void main(String[] args) {
    List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);

    for (Integer i : list) {
        for (int j = 0; j < i; j++) {
            System.out.println(i / j);
        }
    }
}

public static void main(String[] args) {
    List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);

    list.forEach(i -> {
        IntStream.range(0, i).forEach(j -> {
            System.out.println(i/j);
        });
    });
}

이는 람다가 내부적으로 수행하는 작업이 더 많기 때문에 발생하는 현상이기 때문에, 코드가 복잡해 질수록 어디에서 문제가 발생했는지 확인하기가 어려워지게 된다. 그리고 이는 곧 성능과 연결 되기 도 한다.

3. stream에서 람다를 사용할 시 for문 보다 성능이 떨어진다

어플리케이션 성능에 매우 민감한 사람이라면 치명적인 단점이 될 수 도 있다.

아래 예제는 0 부터 10000 까지 단순 순회하는 로직을 stream의 람다와 단순 for문으로 구성하고 각각 실행시간을 나노초로 구하는 코드이다. 결과를 보듯이 두 실행시간 차이는 결코 적지 않다.

public static void main(String[] args) {

    // 람다식 stream 순회 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    long startTime = System.nanoTime(); // 코드 시작 시간

    IntStream.range(0,10000).forEach((value) -> {});

    long endTime = System.nanoTime(); // 코드 끝난 시간
    long durationTimeSec = endTime - startTime;
    System.out.println("람다식 stream 순회 : " + durationTimeSec + "n/s");


    // 일반 for문 순회 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    startTime = System.nanoTime(); // 코드 시작 시간

    for(int i=0; i<10000; i++){
    }

    endTime = System.nanoTime(); // 코드 끝난 시간
    durationTimeSec = endTime - startTime;
    System.out.println("일반 for문 순회 : " + durationTimeSec + "n/s");
}

4. 람다를 남발하면 코드가 지저분해질 수 있다

기존에는 동작 행위를 미리 클래스의 메서드로 정의해놓고 실행부에서 갖다 쓰는 것이었지만, 람다는 동작 행위를 실행부에서 지정하는 식이다. 그래서인지 람다식을 남발하다보면 비슷하게 생긴 함수를 계속 중복 생성하고 있는 자신을 발견 할 수 있다.

interface OperationStrategy {
    // (int x, int y) -> int
    int calculate(int x, int y);
}

// Template
class OperationTemplate {
    int calculate(int x, int y, OperationStrategy cal) {
        int result = cal.calculate(x, y);
        return result;
    }
}

public static void main(String[] args) {
    int x = 100;
    int y = 30;

    OperationContext cxt = new OperationContext();

    int result = cxt.calculate(x, y, (x1, y1) -> x1 + y1);
    System.out.println(result); // 130

    result = cxt.calculate(x, y, (x1, y1) -> x1 - y1);
    System.out.println(result); // 70

    result = cxt.calculate(x, y, (x1, y1) -> x1 * y1);
    System.out.println(result); // 3000

    result = cxt.calculate(x, y, (x1, y1) -> x1 / y1);
    System.out.println(result); // 3
}

비스무리한 람다 함수를 메서드 아규먼트로 지정하고 있다. 위의 예제는 아주 간단한 예시라 와닿지 않을 수 있지만 람다식 로직이 두줄 세줄이 넘어간다면 실행부의 코드가 지저분해 질 수도 있다.

5. 재귀로 만들경우에는 다소 부적합하다

람다식을 통해 재귀 함수를 구축하면 실행 조차 안되는 컴파일 에러가 나타난다.

public static void main(String[] args) {

    UnaryOperator<Long> factorial = (x) -> {
        x == 0 ? 1 : x * factorial.apply(x - 1); // compile error
    };

    factorial(1);
}

# 참고자료

https://github.com/yeGenieee/java-live-study/blob/main/%5B15%5DJava%20Live%20Study.md

@media는 이제 그만 ! 최신 @container 사용법

인파_ — Fri, 24 Mar 2023 09:44:38 +0900

컨테이너 쿼리 vs 미디어 쿼리

컨테이너 쿼리는 미디어 쿼리와 같이 문서의 스타일을 반응형으로 지정할 수 있다. 이 둘의 작동 방식은 유사하지만, 차이점은 어느 것을 기반으로 동작되냐는 점이다. 예를들어 미디어 쿼리는 디바이스 또는 미디어 유형을 기반으로 뷰포트에 의해 반응하지만, 컨테이너 쿼리는 페이지내의 특정 컴포넌트 요소 기반으로 반응한다.

아래 그림을 보면 이해가 될텐데, 미디어 쿼리는 브라우저 너비를 기준으로 반응하지만, 컨테이너 쿼리는 문서 내 각 요소 의 크기나 모양에 따라 반응형 쿼리를 지정할 수 있다는 점에서 상위 호환이라고 할 수 있다.

컨테이너 쿼리가 없었을 시절에는 자바스크립트의 Resize Observer 기술을 통해 특정 요소의 크기 변화를 관찰하여 스크립트로 스타일링을 해주어야 했다. 하지만 이제 간단한 CSS 컨테이너 문법 지정을 통해 매우 간편하게 보다 세밀하고 정확한 반응형 쿼리를 구현할 수 있게 되었다.

컨테이너 쿼리의 장점

컨테이너 쿼리 기능이 빛을 발하는 순간은 아래와 같은 '심플 모드' 나 '확장 모드' 기능을 지원하는 반응형 사이드바를 설계할 때 우측 본문 영역에 대한 반응형 스타일링이 필요할 때이다.

예를들어 좌측 사이드바 영역을 제외한 우측 본문 영역 안에 있는 여러 요소들을 홈페이지의 가로폭에 따라 요소에 변화를 주어야 한다고 할때, 기존 방식대로 미디어 쿼리(@media)를 쓴다면 사이드바 영역을 포함한 전체 브라우저 가로폭을 계산하기 때문에 '심플 모드' 일때 와 '확장 모드' 일때를 모두 고려해야 되어 같은 디자인을 적용하더라도 본문과 구분하여 따로 관리해야하는 불편함이 있다.

굳이 구현한다 라면 아래와 같이 사이드바가 '심플 모드' 냐 '확장 모드' 에 따라 사이드바의 길이에 따라 미디어 쿼리를 두번 구현해야 할지도 모른다. 왜냐하면 본문(main) 영역 부분이 사이드바 길이와 함께 브라우저 폭을 계산해야 되기 때문이다.

main {
	width: 1100px;
}

/* 사이드바 확장 모드 상태일때의 반응형 쿼리 */
@media screen and (max-width: 1400px) {
    html[data-sidebar='expand'] main {
        padding: 0 35px;
        width: 100%;
    } 
}

/* 사이드바 심플 모드 상태일때의 반응형 쿼리 */
@media screen and (max-width: 1200px) {
    html[data-sidebar='simple'] main {
        padding: 0 35px;
        width: 100%;
    }
}

그러나 위의 본문의 main 영역을 컨테이너 쿼리로 지정한다면, 좌측 사이드바 상태를 따지지 않고 오로지 main 영역의 가로폭에 따라 반응하기 때문에 좀더 직관적이고 유지 보수 좋게 구성할 수 있게 된다.

main {
    width: 1100px;
    container-name : main-container;
    container-type : inline-size;
}

/* 본문 메인 특정 영역에 따른 반응형 쿼리 */
@container main-container (max-width: 992px) { 
    html main {
        padding: 0 35px;
        width: 100%;
    }
}

CSS Container Queries 정리

컨테이너 쿼리 사용법

컨테이너 쿼리는 브라우저 viewport 기준이 아닌, 특정 요소의 크기에 따라 반응적인 동작을 한다. 그래서 가장 먼저 해야 할 일은 반응형을 적용할 컨테이너 요소를 지정하는 것이다. 그래야 특정 요소를 기준으로 치수를 계산하기 때문이다.

1. 먼저 반응형으로 등록할 요소를 컨테이너로 등록해준다.

~~container-name~~ 을 통해 쿼리 컨테이너의 이름을 지정한다.

div {
  container-name: div-container; /* 컨테이너 쿼리 요소 이름 */
}

2. 컨테이너 요소의 타입을 지정해준다.

~~container-type~~ 에는 ~~size~~, ~~inline-size~~, ~~normal~~ 속성값이 존재한다.

~~inline-size~~ : 인라인 레벨 기준으로 컨테이너를 적용. 요소의 ~~width~~ 값에 따라 반응형이 동작된다.
~~size~~ : 블록 레벨 기준으로 컨테이너를 적용. ~~width~~ 뿐만 아니라 ~~height~~ 값에 따라 반응형이 동작 된다.
~~normal~~ : 해당 값이 부여된 요소를 container에서 제외시킨다. 일종의 none 의미라고 보면 되겠다.

div {
    container-name: div-container;
    container-type: inline-size; /* 왠만한 상황에선 inline-size 로 이용한다고 보면 된다 */
}

div {
    /* container-name / container-type */
    container : div-container / inline-size; /* 한줄로도 단축 표현이 가능하다 */
}

3. @container 반응 치수를 지정해준다

@media 쿼리를 등록했던 것 처럼 똑같이 @container 쿼리를 등록해주면 된다. 이때 컨테이너 이름을 지정해주면 특정 컨테이너 내에서만 반응하고, 이름을 지정 안해주면 모든 컨테이너에 대해 전역으로 반응하게 된다.

/* 모든 컨테이너 요소에 반응 */
@container (min-width: 700px) {
  div {
    font-size: 2em;
  }
}

/* 특정 container-name의 요소에 반응 */
@container div-container (min-width: 700px) {
  div {
    font-size: 2em;
  }
}

컨테이너 쿼리 길이 단위

viewport의 vw, vh 단위 처럼 container의 너비와 높이를 기준으로 하는 상대 기준점 단위가 존재한다. 이 단위값을 이용하면 요소의 구체적인 길이 값을 다시 계산할 필요 없이 다른 컨테이너에서 유연하게 사용할 수 있다.

cqw : 쿼리 컨테이너 너비의 1%
cqh : 쿼리 컨테이너 높이의 1%
cqi : 쿼리 컨테이너 인라인 크기의 1%
cqb : 쿼리 컨테이너의 블록 크기의 1%
cqmin : cqi 또는 cqb 중 더 작은 값
cqmax : cqi 또는 cqb 중 더 큰 값

/* 컨테이너의 인라인 크기를 기준으로 제목의 글꼴 크기를 설정 */
@container (min-width: 700px) {
  div {
    font-size: 1em + 2cqi;
  }
}

컨테이너 쿼리 브라우저 지원 범위

IE를 제외하곤 왠만한 PC, Mobile 브라우저에서 문제없이 모두 지원됨을 볼 수 있어 더욱더 사용하지 않을 이유가 없다.

컨테이너 쿼리 폴리필

만일 마이너한 구형 브라우저를 꼭 지원해야만 한다면, 폴리필(polyfill) 된 라이브러리가 있으니 이걸 사용하면 된다. 사용법도 css에 컨테이너 쿼리 문법을 쓰고 라이브러리를 로드해 스크립트만 실행하면 알아서 브라우저의 컨테이너 쿼리 지원 유무를 감지하고 폴리필 해준다.

A first look at container-query-polyfill, a polyfill for CSS Container Queries

Surma has been working on container-query-polyfill, a lightweight polyfill for CSS Container Queries. Let’s take a look at how it works and how it differs from cqfill … What Unlike cqfill —which was covered here before— this Polyfill for Container

www.bram.us

<script src="https://unpkg.com/container-query-polyfill/dist/container-query-polyfill.modern.js"></script>
<script>
    const supportsContainerQueries = "container" in document.documentElement.style;
    if (!supportsContainerQueries) {
      import("container-query-polyfill");
    }
</script>

# 참고자료

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries

https://web.dev/cq-stable/

크롬 브라우저 PNA 권한과 CORS 해결하기

인파_ — Thu, 23 Mar 2023 07:29:39 +0900

Chrome PNA (Private Network Access)

사설망 접근(private network access) 이란, 비인증된 공인(public) 웹사이트에서, 사이트를 방문한 사용자의 와 같은 사설 네트워크망(~~localhost(127.0.0.1)~~ or 192.168.0.* 아이피) 엔드포인트에 엑세스하려 할때, 브라우저가 요청을 제한하는 새로운 보안 향상 WSC 사양을 말한다.

PNA 동작 메커니즘은 CORS(Cross-Origin Resource Sharing) 정책을 확장한 개념으로 적용된다. 그래서 사이트에서 사설 네트워크 서버의 허가를 우선 예비 요청(Preflight) 하고 브라우저가 요청을 승인한 경우에만, 공공 웹사이트에서 사설 네트워크 서버의 리소스에 엑세스가 가능하고 그렇지 않으면 CORS 에러가 뜨게 된다.

악명 높은 CORS 개념 & 해결법 - 정리 끝판왕

악명 높은 CORS 에러 메세지 웹 개발을 하다보면 반드시 마주치는 멍멍 같은 에러가 바로 CORS 이다. 웹 개발의 신입 신고식이라고 할 정도로, CORS는 누구나 한 번 정도는 겪게 된다고 해도 과언이

inpa.tistory.com

즉, 앞으로 공공 인터넷 웹사이트에서 내부 네트워크 자원에 접근하려면 브라우저의 허락을 받아야만 하는 것이다.

PNA 탄생 배경

브라우저를 통한 네트워크 침입

이 사양은 브라우저를 통해 침투하는 방식의 해킹 공격을 보다 어렵게 만들겠다는 취지로 탄생 되었다. 브라우저는 많은 서비스와 상호 작용해야 하기 때문에, 기본적으로 로컬 네트워크 내부의 거의 모든 리소스에 연결할 수 있다는 특징을 악용하여, 브라우저는 로컬 네트워크에 대한 공격을 위한 교두보로 프록시로서 이용되왔었다.

예를들어 악성 웹사이트를 개설해 두고 피해자를 사이트 접속을 유도함으로써 피해자의 네트워크에 들어가 엔드포인트를 감염시키는 게 가능하다. 사용자가 악성 웹사이트에 액세스하면 브라우저는 사용자 모르게 라우터에 자동 요청을 보내 라우터의 인증을 우회할 수 있기 때문에, 악의적인 웹사이트에서 라우터 설정을 수정할 수 있는 악성 코드를 보내 라우터를 조작하는 식으로 감염시킨다.

실제로 해커가 CSRF 공격을 통해 300,000개 이상의 무선 라우터에 대한 DNS 서버 설정을 변경하여 정보를 탈취한 사례도 있다.

크로스 사이트 요청 취약점을 악용하여 라우터의 DNS 설정을 변경하는 공격의 3단계

사설 내부망을 사용하고 있는 사용자가 악의적인 사이트에 접속한다.
악성 자바스크립트가 로컬 네트워크 내부의 컴퓨터에서 로드되어 로컬 컴퓨터가 라우터의 DNS 설정을 자동으로 변경하도록 한다.
라우터는 네트워크의 모든 디바이스에 대해 악성 네임서버(DNS)를 사용하도록 설정됨에 따라, 해당 망에 연결된 모든 사용자들의 라우팅 요청을 오염시킨다.
금융(또는 기타) 사이트에 연결을 시도하는 디바이스는 이제 로그인 자격 증명을 캡처할 수 있는 가짜 웹사이트로 리다이렉션 될 수 있다.

이러한 보안적인 취약점 때문에 브라우저는 이제 사설망에 대해서 검사를 철저히 한다는 개념으로 PNA 사양이 탄생하게 된 것이다. 그러면 각종 엔드포인트 장비들을 노리는 CSRF(교차 사이트 요청 조작) 공격으로부터 비교적 안전해지게 된다.

Chrome PNA 정책 적용 시기

Google에 따르면 Chrome 94 버전부터 PNA가 등장했으며 현재까지 시범적으로 운용되다가, 2023년 5월에 출시될 Chrome 113 버전에서 정식으로 릴리즈 될 예정이라고 한다. 같은 크로미움 계열인 Edge 브라우저 역시 베타 채널에 도입된 상태이다. 따라서 브라우저 자체에서 비공개 네트워크 요청을 하는 애플리케이션이 있다면 이에 맞게 대처를 해야 할 것이다.

Private Network Access update: Introducing a deprecation trial - Chrome Developers

Chrome is deprecating access to private network endpoints from non-secure public websites in Chrome 94 as part of the Private Network Access specification. Read on for recommended actions.

developer.chrome.com

PNA CORS 에러 현상

CORS 의 메세지 종류

일반적인 CORS 메세지

먼저 일반적으로 발생하는 CORS 에러는 다음과 같다. 에러 메세지에서 안내하듯이 이 부분은 백엔드쪽에서 CORS 관련 헤더인 Access-Control-Allow-* 응답만 잘 해주면 별다른 문제없이 해결이 된다.

Access to XMLHttpRequest at 'http://xxxx' from origin 'http://xxxxx' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

PNA CORS 메세지

그런데 서버에서 CORS 관련 헤더 요청 응답을 모두 처리해줬는데, 이번엔 다음과 같은 또다른 CORS 에러가 발생해서 당황한 경험이 있을 것이다.

Access to XMLHttpRequest at 'http://10.x.x.x/xxxx' from origin 'http://xxxx.xxx.com' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `private`

위 에러 메세지 내용 부분을 해석하자면, 요청 클라이언트가 보안 컨텍스트가 아니며 리소스가 비공개 주소 공간 로컬에 있다는 말이다. 즉, 위에서 다루었던 PNA(Priavte Network Address) 관련 사양이다.

PNA CORS 발생 상황

요청 단계 방향

포스팅 초반에 잠깐 소개했듯이, PNA CORS 발생 상황은 공인 IP에서 사설/로컬 IP로의 낮은 수준으로 가는 요청을 할때 발생된다. 예를 들어 아래 그림에서 Public 네트워크(http://example.com)에서 Private 네트워크(http://router.local) 로의 요청을 하거나, 또는 Private 네트워크에서 Local 호스트의 요청이 이에 해당된다.

public 네트워크 사이트 → private 네트워크 사이트 (CORS !!)
public 네트워크 사이트 → 로컬 호스트 (CORS !!)
private 네트워크 사이트 → 로컬 호스트 (CORS !!)

insecure public website

다만 무조건 공인 웹사이트에서 요청하면 PNA CORS에 걸리는게 아니라, 정확히 말하자면 비인증된* 공인 웹사이트에서 요청하면 걸리는 것이다. 즉, https 나 wss 와 같은 ssl을 먹인 사이트라면 PNA CORS는 발생하지 않게 된다.

도메인 여부

마지막으로 요청을 보낸 공인 웹사이트가 아이피 형태가 아닌 도메인이 씌워져 있을 경우에만 발생한다. 아무리 insecure public website 이라도 도메인 형태가 아닐경우 PNA CORS 에러는 발생하지 않는다.

PNA CORS 관련 헤더

일반적인 CORS 현상을 해결하기 위해 ~~Access-Control-Allow-Origin~~ 헤더를 설정하여 해결 하였 듯이, PNA CORS 역시 관련 헤더인 ~~Access-Control-Allow-Private-Network~~ 헤더를 설정 하면 된다. 이를 도식으로 표현하자면 아래와 같이 된다.

하위 자원에 대한 요청을 사설망에 보내기 전에, 앞서 예비 요청(Preflight)을 보낸다.
이때 요청 헤더에 ~~Access-Control-Request-Private-Network: true~~ 를 실어 서버에 보낸다
요청 전달을 받은 서버에서 ~~Access-Control-Allow-Private-Network: true~~ 를 통해 허락이나 불허를 응답한다.
엑세스 허락이 되면 본요청 통신이 이루어지게 된다.

PNA CORS 해결 방법

1. 요청 주체를 변경

앞서 말했듯이 공인 IP라고 해도 insecure일 경우에만 PNA CORS가 발생한다고 하였으니, 호출하는 주체의 scheme를 HTTPS로 설정하면 가져오려는 리소스가 HTTP여도 문제없이 호출이 가능해진다.

혹은 요청하려는 리소스를 사설/로컬 네트워크가 아닌 공인 네트워크로 변경하는 방법도 가능하다.

2. 크롬 브라우저 옵션 변경

크롬 혹은 엣지 브라우저 검색창에 다음 URL로 이동한다.

chrome://flags
edge://flags

그리고 Block insecure private network requests 항목과 Send Private Network Access preflights 항목의 설정값을 Disabled로 설정 하면 된다.

3. Chrome Origin Trials 이용

개발자 지원 기능을 이용하여 로컬 네트워크 접근을 허용할 수 있다.

https://developer.chrome.com/origintrials/#/trials/active 로 접속해서, Private Network Access from non-secure contexts 항목의 REGISTER 를 클릭한다. 단, 이 방법은 PNA를 허용할 웹사이트의 API 키를 발급받아 사용하는 형태이기 때문에 사용할 수 있는 기간이 정해져 있다.

4. Access-Control-Allow-Private-Network 헤더 설정

지금까지 소개한 위의 방법은 간단하게 설정만으로 해결이 가능하겠지만, 이는 보안적으로 안전하지 않으며, CORS는 서버가 아닌 브라우저에서 차단하는 메커니즘 이기 때문에, 서비스 이용자들이 직접 자기가 쓰는 컴퓨터의 브라우저 설정을 일일히 조작해야 한다는 번거롭다는 치명적인 단점이 존재한다.

따라서 가장 이상적인 해결책은 백엔드쪽에서 ~~Access-Control-Allow-Private-Network~~ 헤더 설정을 하면 되는 것이다.

HTTP/1.1 OPTIONS localhost:8080/cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

# 참고자료

https://www.boannews.com/media/view.asp?idx=104187

https://developer.chrome.com/blog/private-network-access-update/

https://arstechnica.com/information-technology/2022/01/new-chrome-security-measure-aims-to-curtail-an-entire-class-of-web-attack/

Chain Of Responsibility 패턴 - 완벽 마스터하기

인파_ — Wed, 22 Mar 2023 08:57:47 +0900

Chain Of Responsibility Pattern

책임 연쇄 패턴(Chain Of Responsibility Pattern, COR)은 클라이어트의 요청에 대한 세세한 처리를 하나의 객체가 몽땅 하는 것이 아닌, 여러개의 처리 객체들로 나누고, 이들을 사슬(chain) 처럼 연결해 집합 안에서 연쇄적으로 처리하는 행동 패턴이다.

이러한 처리 객체들을 핸들러(handler)라고 부르는데, 요청을 받으면 각 핸들러는 요청을 처리할 수 있는지, 없으면 체인의 다음 핸들러로 처리에 대한 책임을 전가한다. 한마디로 책임 연쇄라는 말은 요청에 대한 책임을 다른 객체에 떠넘긴다는 소리이다. 떠넘긴다고 하니까 부정적인 의미로 들릴수도 있겠지만, 이러한 체인 구성은 하나의 객체에 처리에 대한 책임을 요청을 보내는 쪽(sender)과 요청을 처리하는(receiver) 쪽을 분리하여 각 객체를 부품으로 독립시키고 결합도를 느슨하게 만들며, 상황에 따라서 요청을 처리할 객체가 변하는 프로그램에도 유연하게 대응할 수 있다는 장점을 가지고 있다. 특히나 중첩 if-else문들을 최적화하는데 있어 실무에서도 많이 애용되는 패턴중 하나이기도 하다.

좀 더 접근하기 쉽게 실생활로 비유를 든다면, 예를들어 소비자가 문의를 위해 고객센터에 전화를 걸었다고 해보자. 그러면 아래와 같은 순서로 요청을 처리해본 경험을 한 번 씩은 겪어 봤을 것이다.

첫 번째로, 자동 응답기 음성 로봇이 응답하게 된다. 그런데 만일 음성 로봇이 제시하는 해결책에 대해서 1부터 4까지 선택사항중 해당하는 번호가 없다면 아마 여러분도 그렇고 대다수의 사람들이 기타 버튼을 눌러 상담원 연결을 누를 것이다.
두 번째로, 상담사가 전화를 받았지만 길게 통화한 결과 제대로된 기술적인 도움을 받지 못했다고 한다. 그러면 상담원이 직접 엔지니어에게 전화를 연결해주게 된다.
세 번째로, 엔지니어와 통화하고 적합한 솔루션을 제시해줌으로써 문제가 해결되어 통화를 종료한다.

자동 응답기 -> 상담사 -> 엔지니어 체인 구성

마치 소비자의 요청에 대해 각 처리 서비스들이 무엇인가 체인처럼 연결되는 흐름이 되는 것 처럼 보일 것이다.

여기서 핸들러(Handler)는 자동 응답기 로봇, 상담사, 엔지니어가 된다. 즉, 각 핸들러에서 요청을 처리할 수 있는지의 여부를 따지고 불가능하면 다음 핸들러로 떠넘기는 과정을 진행한 것을 코드로 구현한 것이 책임 연쇄 패턴인 것이다.

책임 연쇄 패턴 구조

Handler : 요청을 수신하고 처리 객체들의 집합을 정의하는 인터페이스
ConcreteHandler : 요청을 처리하는 실제 처리 객체
- 핸들러에 대한 필드를 내부에 가지고 있으며 메서드를 통해 다음 핸들러를 체인시키고 다음 바라본다.
- 자신이 처리할 수 없는 요구가 나오면 바라보고 있는 다음 체인의 핸들러에게 요청을 떠넘긴다.
- ConcreteHandler1 - ConcreteHandler2 - ConcreteHandler3 - ... 이런식으로 체인 형식이 구성되게 된다.
Client : 요청을 Handler 전달한다

여기서 핸들러끼리 체이닝 되는 구조는 어떤 형태이든 상관이 없다. 리스트형 일수도 있고 선형 일 수도 있고 트리 형태일 수도 있다.

책임 연쇄 패턴 특징

패턴 사용 시기

특정 요청을 2개 이상의 여러 객체에서 판별하고 처리해야 할때
특정 순서로 여러 핸들러를 실행해야 하는 경우
프로그램이 다양한 방식과 종류의 요청을 처리할 것으로 예상되지만 정확한 요청 유형과 순서를 미리 알 수 없는 경우
요청을 처리할 수 있는 객체 집합이 동적으로 정의되어야 할 때 (체인 연결을 런타임에서 동적으로 설정)

패턴 장점

클라이언트는 처리 객체의 체인 집합 내부의 구조를 알 필요가 없다.
각각의 체인은 자신이 해야하는 일만 하기 때문에 새로운 요청에 대한 처리객체 생성이 편리해진다.
클라이언트 코드를 변경하지 않고 핸들러를 체인에 동적으로 추가하거나 처리 순서를 변경하거나 삭제할 수 있어 유연해진다
요청의 호출자(invoker)와 수신자(receiver) 분리시킬 수 있다.
- 요청을 하는 쪽과 요청을 처리하는 쪽을 디커플링 시켜 결합도를 낮춘다
- 요청을 처리하는 방법이 바뀌더라도 호출자 코드는 변경되지 않는다.

패턴 단점

실행 시에 코드의 흐름이 많아져서 과정을 살펴보거나 디버깅 및 테스트가 쉽지 않다.
충분한 디버깅을 거치지 않았을 경우 집합 내부에서 무한 사이클이 발생할 수 있다.
요청이 반드시 수행된다는 보장이 없다. (체인 끝까지 갔는데도 처리되지 않을 수 있다)
책임 연쇄로 인한 처리 지연 문제가 발생할 수 있다. 다만 이는 트레이드 오프로서 요청과 처리에 대한 관계가 고정적이고 속도가 중요하면 책임 연쇄 패턴 사용을 유의하여야 한다.

예제를 통해 알아보는 Chain Of Responsibility 패턴

책임을 분리하여 연결짖기

사용자로부터 url 문자열을 입력받으면, 각 url의 프로토콜, 도메인, 포트를 파싱해서 정보를 출력해주는 프로그램을 만든다고 해보자.

클린하지 않은 문제의 코드 ❌

일반적으로는 아래와 같이 처리문을 하나의 메서드로 통짜로 구성할 것이다.

class UrlParser {
    public static void run(String url) {
        // protocol 파싱
        int index = url.indexOf("://");
        if (index != -1) {
            System.out.println("PROTOCOL : " + url.substring(0, index));
        } else {
            System.out.println("NO PROTOCOL");
        }

        // domain 파싱
        int startIndex = url.indexOf("://");
        int lastIndex = url.lastIndexOf(":");

        System.out.print("DOMAIN : ");
        if (startIndex == -1) {
            if (lastIndex == -1) {
                System.out.println(url);
            } else {
                System.out.println(url.substring(0, lastIndex));
            }
        } else if (startIndex != lastIndex) {
            System.out.println(url.substring(startIndex + 3, lastIndex));
        } else {
            System.out.println(url.substring(startIndex + 3));
        }

        // port 파싱
        int index2 = url.lastIndexOf(":");
        if (index2 != -1) {
            String strPort = url.substring(index2 + 1);
            try {
                int port = Integer.parseInt((strPort));
                System.out.println("PORT : " + port);
            } catch (NumberFormatException e) {
                e.printStackTrace();
            }
        }

    }
}

class Client {
    public static void main(String[] args) {
        String url1 = "http://www.youtube.com:80";
        System.out.println("INPUT: " + url1);
        UrlParser.run(url1);

        String url2 = "https://www.inpa.tistory.com:443";
        System.out.println("INPUT: " + url2);
        UrlParser.run(url2);

        String url3 = "http://localhost:8080";
        System.out.println("INPUT: " + url3);
        UrlParser.run(url3);
    }
}

동작에는 문제는 없지만, 이런식으로 구성할 경우 만일 path나 queryString도 구하는 새로운 처리 로직이 추가될 경우 메서드 로직을 통짜로 수정해야할 것이고 이전의 로직과 겹치는게 없는지 복기해야 한다. 당장 코드만 봐도 프로토콜, 도메인, 포트를 구하는데 있어 ~~indexOf()~~ 메서드를 자체적으로 사용하고 있어 겹치는 부분이 있는 것을 볼 수 있다.

또한 사용자가 포트 정보는 원하지 않을 경우 코드를 지울수는 없으니 포트 파싱 부분만 뺀 비슷한 코드로 이루어진 메서드를 따로 생성해야 한다. 이는 요구에 대한 처리를 중앙 집권적으로 모두 가지고 있기 때문에 발생하는 현상이다.

책임 연쇄 패턴을 적용한 코드 ✔️

그렇다면 프로토콜만을 파싱하는 책임과 도메인만을 파싱하는 책임 이렇게 처리 책임을 각 객체들로 분리하고 이들 끼리 체인으로 연결함으로써 좀더 유연하게 프로그램 로직을 구성할 수 있게 된다. 이를 그림으로 표현하자면 아래와 같다.

핸들러는 본인의 역할만을 수행하고 추가 처리 로직이 필요하다면 유연하게 체인을 추가해주면 되며 체인을 구조적으로 다양하게 구성할수 있게 된다.

책임 연쇄를 적용하는 방법은 그리 어렵지 않다. 기존의 코드에서 각 담당하는 부분을 따로 핸들러(Handler) 객체로 내빼주면 된다.

전략 패턴이 전략 알고리즘 코드를 객체화 한 것이고, 상태 패턴은 객체의 상태를, 명령 패턴이 커맨드를 객체화 한 것과 같이, 책임 연쇄 패턴은 조건문의 요청 처리 로직 자체를 객체화 한 것으로 보면 된다. 그리고 일반적인 조건 분기문 같은 경우 다중으로 구성될 수 있으니 이를 체인으로 객체끼리 연결함으로써, 각 if문 로직을 클래스로 표현하였다고 보면 된다.

// 구체적인 핸들러를 묶는 인터페이스 (추상 클래스)
abstract class Handler {
    // 다음 체인으로 연결될 핸들러
    protected Handler nextHandler = null;

    // 생성자를 통해 연결시킬 핸들러를 등록
    public Handler setNext(Handler handler) {
        this.nextHandler = handler;
        return handler; // 메서드 체이닝 구성을 위해 인자를 그대로 반환함
    }

    // 자식 핸들러에서 구체화 하는 추상 메서드
    protected abstract void process(String url);

    // 핸들러가 요청에 대해 처리하는 메서드 
    public void run(String url) {
        process(url);

        // 만일 핸들러가 연결된게 있다면 다음 핸들러로 책임을 떠넘긴다
        if (nextHandler != null)
            nextHandler.run(url);
    }
}

class ProtocolHandler extends Handler {
    @Override
    protected void process(String url) {
        int index = url.indexOf("://");
        if (index != -1) {
            System.out.println("PROTOCOL : " + url.substring(0, index));
        } else {
            System.out.println("NO PROTOCOL");
        }
    }
}

class DomianHandler extends Handler {
    @Override
    protected void process(String url) {
        int startIndex = url.indexOf("://");
        int lastIndex = url.lastIndexOf(":");

        System.out.print("DOMAIN : ");
        if (startIndex == -1) {
            if (lastIndex == -1) {
                System.out.println(url);
            } else {
                System.out.println(url.substring(0, lastIndex));
            }
        } else if (startIndex != lastIndex) {
            System.out.println(url.substring(startIndex + 3, lastIndex));
        } else {
            System.out.println(url.substring(startIndex + 3));
        }
    }
}

class PortHandler extends Handler {
    @Override
    protected void process(String url) {
        int index = url.lastIndexOf(":");
        if (index != -1) {
            String strPort = url.substring(index + 1);
            try {
                int port = Integer.parseInt((strPort));
                System.out.println("PORT : " + port);
            } catch (NumberFormatException e) {
                e.printStackTrace();
            }
        }
    }
}

class Client {
    public static void main(String[] args) {
        // 1. 핸들러 생성
        Handler handler1 = new ProtocolHandler();
        Handler handler2 = new DomianHandler();
        Handler handler3 = new PortHandler();

        // 2. 핸들러 연결 설정 (handler1 → handler2 → handler3)
        handler1.setNext(handler2).setNext(handler3);

        // 3. 요청에 대한 처리 연쇄 실행
        String url1 = "http://www.youtube.com:80";
        System.out.println("INPUT: " + url1);
        handler1.run(url1);

        System.out.println();

        String url2 = "https://www.inpa.tistory.com:443";
        System.out.println("INPUT: " + url2);
        handler1.run(url2);

        System.out.println();

        String url3 = "http://localhost:8080";
        System.out.println("INPUT: " + url3);
        handler1.run(url3);
    }
}

중첩된 if-else 문 재구성하기

첫번째 패턴 예제는 중앙 집권화한 로직을 핸들러 객체로 분리하여 책임을 분산시키는 방법을 소개했다면, 두번째 패턴 예제는 중첩된 if-else 조건문을 책임 연쇄 패턴으로 유연하며 가독성 좋게 구성하는 사례를 들어볼 것이다.

클린하지 않은 문제의 코드 ❌

서버가 있고 사용자가 미들웨어를 통해 로그인 하는 과정을 자바의 클래스로 간단하게 표현해 보았다. 코드가 길어보여 어려워보이지만 간단하게 구성해본 예제이다. 서버는 각종 사용자 정보들을 Map 자료형태로 지니고 있고, 미들웨어는 각종 로그인 인증 로직들을 관리하며, 클라이언트에서 각종 미들웨어의 boolean 메서드를 통해 조건 분기문을 통해 로그인 과정을 처리한다.

class Server {
    private Map<String, String> users = new HashMap<>();

    // 서버에 유저 등록
    public void register(String email, String password) {
        users.put(email, password);
    }

    // 서버에 해당 이메일이 가입되어 있는지
    public boolean hasEmail(String email) {
        return users.containsKey(email);
    }
    
    // 서버에 해당 계정의 비밀번호가 일치하는지
    public boolean isValidPassword(String email, String password) {
        return users.get(email).equals(password);
    }
}

class Middleware {
    private int limit = 3;
    private int count = 0;

    Server server;

    public Middleware(Server server) {
        this.server = server;
    }

    // 로그인 횟수 시도
    public boolean limitLoginAttempt() {
        if (count > limit) {
            System.out.println("로그인 요청 횟수 제한 !!");
            return false;
        }
        count++;
        return true;
    }

    // 아이디, 패스워드 인증
    public boolean authorize(String email, String password) {
        if (!server.hasEmail(email)) {
            System.out.println("가입된 이메일 계정이 없습니다 !");
            return false;
        }

        if (!server.isValidPassword(email, password)) {
            System.out.println("패스워드가 다릅니다 !");
            return false;
        }

        System.out.println("로그인 완료 !!");
        return true;
    }

    // 사용자가 admin 계정인지, 혹은 일반 user 계정인지 검증
    public boolean authentication(String email) {
        if (email.equals("inpa@tistory.com")) {
            System.out.println("Hello, admin!");
            return true;
        } else {
            System.out.println("Hello, user!");
            return false;
        }
    }

    // 만일 관리자가 아닌 일반 유저일 경우 유저의 요청에 대해선 모두 로깅
    public void logging() {
        System.out.println("요청을 로깅합니다.");
    }
}

class Client {
    public static void main(String[] args) throws IOException {
        // 1. 서버 생성 및 등록
        Server server = new Server();
        server.register("john@naver.com", "123123");
        server.register("kail@google.com", "456456");
        server.register("inpa@tistory.com", "789789");

        // 2. 인증 로직을 처리하는 미들웨어 생성
        Middleware middleware = new Middleware(server);

        // 3. 클라이언트로부터 로그인 시도
        do {
            BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
            System.out.print("\nEmail: ");
            String email = reader.readLine();
            System.out.print("Password: ");
            String password = reader.readLine();

            // 만일 로그인 횟수가 남아있을 경우
            if (middleware.limitLoginAttempt()) {
                // 이메일 패스워드 인증
                if (middleware.authorize(email, password)) {
                    // 인증되었을 경우 일반 유저 계정인지 관리자 계정인지 검증
                    if (middleware.authentication(email)) {
                        // ...
                    } else {
                        // 관리자가 아닌 일반 유저 계정일 경우 로깅 처리
                        middleware.logging();
                    }
                    break;
                } else {
                    continue;
                }
            } else {
                throw new RuntimeException("로그인 시도 횟수 초과로 프로그램을 종료합니다");
            }
        } while (true);
    }
}

동작은 문제없어 보이지만 딱봐도 클라이언트 쪽 실행 코드가 굉장히 복잡하다. 여러 인증 로직들을 하나하나 따져가며 만일 '참'일 경우 다음 인증 로직을 따져가는 중첩 if-else문 형태로 되어 있다.

이런 코드는 코드를 복기할때나 테스트할때 굉장히 난해하게 되며 특히나 if문 중첩은 단계가 늘어날 수록 중첩 블록이 분기에서 안정적으로 작동하는지 확신하기도 어렵다. 거기다 만일 새로운 인증 메서드가 추가된다면 분기문 전체를 뜯어 고쳐야 될 수 있다.

코드가 커질수록 점점 복잡해진다

책임 연쇄 패턴을 적용한 코드 ✔️

물론 각 인증 로직들이 별개의 메서드로 분리되어 있지만, 결국 실행부에선 복잡한 if-else로 구성되는건 마찬가지이고 하나의 미들웨어 클래스에서 중앙 집권 적인 책임을 지니고 있기 때문에, 책임 연쇄 패턴으로 인증 로직들을 별개의 핸들러 클래스로 분리하고 체이닝 함으로써 if-else 형태를 보다 유연하게 구성할 수가 있게 된다.

인증 로직들을 별개의 핸들러로 분리하고 연결한다

이번 패턴 적용 예제는 첫번째 예제와는 약간 차이를 두었는데, 핸들러 메서드를 추상 메서드로 각 객체별로 구체화 하는 것이 아닌, 부모의 ~~check()~~ 메서드를 자식 핸들러에서 오버라이드(Override)하고, 만일 체인 호출이 필요할 경우 ~~super~~ 키워드를 통해 부모 메서드를 호출함으로써 다음 핸들러를 호출하는, 자바 클래스의 상속 특징을 이용하였다라고 볼 수 있다.

또한 요청에 대한 로직 및 결과를 모두 핸들러 클래스에게 위임 했으니, 복잡한 if-else 분기에 따른 로직을 처리하기 위해 핸들러에서 flag 라는 정수를 반환하도록 하여, 실행부에서 정수값에 따라 루프문 동작을 제어하는 식으로 구성하였다.

// Handler 역할
abstract class Middleware {
    // 다음 체인으로 연결될 핸들러
    protected Middleware nextMiddleware = null;

    // setter 메서드를 통해 연결시킬 핸들러를 등록
    public Middleware setNext(Middleware middleware) {
        this.nextMiddleware = middleware;
        return middleware; // 메서드 체이닝 구성을 위해 인자를 그대로 반환함
    }

    // 핸들러가 요청에 대해 처리하는 메서드
    public short check(String email, String password) {
        /*
          flag는 클라이언트 실행부에서 while문을 빠져나가기 위한 조건값으로 사용된다
          -2 : Exception 일으킴
          -1 : break 동작 (루프문 종료)
          0 : continue 동작 (처음부터 콘솔 입력 받기)
          1 : 그대로 처리를 진행함
         */
        short flag = 1;

        // 만일 핸들러가 연결된게 있다면 다음 핸들러로 책임을 떠넘긴다
        if (nextMiddleware != null) {
            flag = nextMiddleware.check(email, password);
        }

        return flag;
    }
}

// ConcreteHandler 역할
class LimitLoginAttemptMiddleware extends Middleware {
    private int limit = 3; // 로그인 시도 최대 횟수 3회
    private int count = 0;

    @Override
    public short check(String email, String password) {
        short flag = 1;

        if (count > limit) {
            System.out.println("로그인 요청 횟수 제한 !!");
            flag = -2; // Exception 플래그
        } else {
            flag = super.check(email, password);
        }

        count++;

        return flag;
    }
}

class AuthorizeMiddleware extends Middleware {
    private Server server;

    public AuthorizeMiddleware(Server server) {
        this.server = server;
    }

    @Override
    public short check(String email, String password) {
        short flag = 1;

        if (!server.hasEmail(email)) {
            System.out.println("This email is not registered!");
            flag = 0; // continue 플래그
        } else if (!server.isValidPassword(email, password)) {
            System.out.println("Wrong password!");
            flag = 0; // continue 플래그
        } else {
            flag = super.check(email, password);
        }

        return flag;
    }
}

class AuthenticationMiddleware extends Middleware {
    @Override
    public short check(String email, String password) {
        short flag = 1;

        if (email.equals("inpa@tistory.com")) {
            System.out.println("Hello, admin!");
            flag = -1; // break 플래그
        } else {
            System.out.println("Hello, user!");
            flag = super.check(email, password);
        }

        return flag;
    }
}

class LoggingMiddleware extends Middleware {
    @Override
    public short check(String email, String password) {
        System.out.println("요청을 로깅합니다.");
        return -1; // break 플래그
    }
}

class Client {
    public static void main(String[] args) throws IOException {
        // 1. 서버 생성 및 등록
        Server server = new Server();
        server.register("john@naver.com", "123123");
        server.register("kail@google.com", "456456");
        server.register("inpa@tistory.com", "789789");

        // 2. 인증 로직을 처리하는 핸들러 생성
        LimitLoginAttemptMiddleware middleware1 = new LimitLoginAttemptMiddleware();
        AuthorizeMiddleware middleware2 = new AuthorizeMiddleware(server);
        AuthenticationMiddleware middleware3 = new AuthenticationMiddleware();
        LoggingMiddleware middleware4 = new LoggingMiddleware();

        // 3. 핸들러 체인
        middleware1
                .setNext(middleware2)
                .setNext(middleware3)
                .setNext(middleware4);

        // 4. 클라이언트로부터 로그인 시도
        do {
            BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
            System.out.print("\nEmail: ");
            String email = reader.readLine();
            System.out.print("Password: ");
            String password = reader.readLine();

            // 핸들러부터 정수 flag를 받아, 정수값에 따라 루프문 다음 동작을 처리
            short result = middleware1.check(email, password);

            if (result == -2) {
                throw new RuntimeException("로그인 시도 횟수 초과로 프로그램을 종료합니다");
            } else if (result == -1) {
                break;
            } else if (result == 0) {
                continue;
            }

        } while (true);
    }
}

오히려 기존 코드보다 디자인 패턴을 적용한 코드가 양도 많아지고 복잡성이 증가한 것처럼 느낄 수 있겠지만, 실행부를 좀더 한눈에 알 수 있게 심플하게 처리했다라는 점에서 의의를 가질 수 있다.

실무에서 찾아보는 Chain Of Responsibility 패턴

Java

java.util.logging.Logger의 log()
javax.servlet.Filter의 doFilter()

사용자가 요청시 서블릿에 접근하기 전에 다양한 필터를 거치도록 할 수 있다. 만약 아래와 같은 컨트롤러가 있고, "/hello"로 요청을 받으면 필터를 타도록한다.

@ServletComponentScan
@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "hello";
    }
}

@WebFilter(urlPatterns = "/hello") // 특정 url 서블릿에 접근할시 다음 필터를 적용
public class MyFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        System.out.println("게임 참여");
        chain.doFilter(request, response);
        System.out.println("게임 끝");
    }
}

Spring Framework

스프링 프로젝트에 Spring Securiry 의존성을 추가하고 아래와 같이 Security 필터에 대한 체인을 설정을 할 수 있다.

@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    
    // 체인 필터를 설정하는 코드
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // 모든 페이지의 접근권한을 인증없이 허가
        http.authorizeRequests().anyRequest().permitAll().and().addFilter(new MyFilter());
    }
}

# 참고자료

코딩으로 학습하는 GoF의 디자인 패턴 - 백기선

https://refactoring.guru/design-patterns/chain-of-responsibility

GIS DEVELOPER 유튜브 - Chain of Responsibility

복합체(Composite) 패턴 - 완벽 마스터하기

인파_ — Tue, 21 Mar 2023 08:26:43 +0900

Composite Pattern

복합체 패턴(Composite Pattern)은 복합 객체(Composite) 와 단일 객체(Leaf)를 동일한 컴포넌트로 취급하여, 클라이언트에게 이 둘을 구분하지 않고 동일한 인터페이스를 사용하도록 하는 구조 패턴이다.

복합체 패턴은 전체-부분의 관계를 갖는 객체들 사이의 관계를 트리 계층 구조로 정의해야 할때 유용하다. 윈도우나 리눅스의 파일 시스템 구조를 떠올려보면 쉽게 이해할 수 있다.

폴더(디렉토리) 안에는 파일이 들어 있을수도 있고 파일을 담은 또 다른 폴더도 들어있을 수 있다. 이를 복합적으로 담을수 있다 해서 Composite 객체라고 불리운다. 반면 파일은 단일 객체 이기 때문에 이를 Leaf 객체라고 불리운다. 즉 Leaf는 자식이 없다.

폴더-파일 관계 와 Composite-Leaf 관계

복합체 패턴은 바로 이 폴더와 파일을 동일한 타입으로 취급하여 구현을 단순화 시키는 것이 목적이다. 폴더 안에는 파일 뿐만 아니라 서브 폴더가 올수 있고 또 서브 폴더안에 서브 폴더가 오고.. 이런식으로 계층 구조를 구현하다 보면, 자칫 복잡해 질 수 도 있는 복합 객체를 재귀 동작을 통해 하위 객체들에게 작업을 위임한다. 그러면 복합 객체와 단일 객체를 대상으로 똑같은 작업을 적용할 수 있어 단일 / 복합 객체를 구분할 필요가 거의 없어진다.

윈도우에선 폴더와 파일은 엄연히 다른 놈이지만, 리눅스(Unix)에선 디렉토리와 파일은 모두 파일로 취급된다. 어찌보면 리눅스 OS가 복합체(Composite) 패턴을 통해 계층 구조를 구현하였다고 볼 수 있다.
당연히 실제 설계는 다르겠지만, 복합체 패턴은 입문하기 어려운 패턴중 하나이기에 이러한 비유를 통해 좀더 패턴에 친숙하게 접근하도록 해보자.

정리하자면, Composite 패턴은 그릇과 내용물을 동일시해서 재귀적인 구조를 만들기 위한 디자인 패턴이라고 말할 수 있다.

Composite 패턴 구조

Component : Leaf와 Compsite 를 묶는 공통적인 상위 인터페이스
Composite : 복합 객체로서, Leaf 역할이나 Composite 역할을 넣어 관리하는 역할을 한다.
- Component 구현체들을 내부 리스트로 관리한다
- add 와 remove 메소드는 내부 리스트에 단일 / 복합 객체를 저장
- Component 인터페이스의 구현 메서드인 operation은 복합 객체에서 호출되면 재귀 하여, 추가 단일 객체를 저장한 하위 복합 객체를 순회하게 된다.
Leaf: 단일 객체로서, 단순하게 내용물을 표시하는 역할을 한다.
- Component 인터페이스의 구현 메서드인 operation은 단일 객체에서 호출되면 적절한 값만 반환한다
Client : 클라이언트는 Component를 참조하여 단일 / 복합 객체를 하나의 객체로서 다룬다.

복합체 패턴의 핵심은 Composite 와 Leaf가 동시에 구현하는 ~~operation()~~ 인터페이스 추상 메서드를 정의하고, Composite 객체의 ~~operation()~~ 메서드는 자기 자신을 호출하는 재귀 형태로 구현하는 것이다. 왜냐하면 폴더 안에 폴더를 넣고, 그 안에 또 폴더를 넣고 파일을 넣는 트리 구조를 생각해보면, 재귀적으로 반복되는 형식이 나타나기 때문이다. 그래서 단일체와 복합체를 동일한 개체로 취급하여 처리하기 위해 재귀 함수 원리를 이용한다.

Composite 패턴 흐름

클래스 구성

interface Component {
    void operation();
}

class Leaf implements Component {

    @Override
    public void operation() {
        System.out.println(this + " 호출");
    }
}

class Composite implements Component {

    // Leaf 와 Composite 객체 모두를 저장하여 관리하는 내부 리스트
    List<Component> components = new ArrayList<>();

    public void add(Component c) {
        components.add(c); // 리스트 추가
    }

    public void remove(Component c) {
        components.remove(c); // 리스트 삭제
    }

    @Override
    public void operation() {
        System.out.println(this + " 호출");
        
        // 내부 리스트를 순회하여, 단일 Leaf이면 값을 출력하고,
        // 또다른 서브 복합 객체이면, 다시 그 내부를 순회하는 재귀 함수 동작이 된다.
        for (Component component : components) {
            component.operation(); // 자기 자신을 호출(재귀)
        }
    }
    
    public List<Component> getChild() {
        return components;
    }
}

클래스 흐름

class Client {
    public static void main(String[] args) {
        // 1. 최상위 복합체 생성
        Composite composite1 = new Composite();

        // 2. 최상위 복합체에 저장할 Leaf와 또다른 서브 복합체 생성
        Leaf leaf1 = new Leaf();
        Composite composite2 = new Composite();

        // 3. 최상위 복합체에 개체들을 등록
        composite1.add(leaf1);
        composite1.add(composite2);

        // 4. 서브 복합체에 저장할 Leaf 생성
        Leaf leaf2 = new Leaf();
        Leaf leaf3 = new Leaf();
        Leaf leaf4 = new Leaf();

        // 5. 서브 복합체에 개체들을 등록
        composite2.add(leaf2);
        composite2.add(leaf3);
        composite2.add(leaf4);

        // 6. 최상위 복합체의 모든 자식 노드들을 출력
        composite1.operation();
    }
}

클라이언트에서 operation 메서드를 호출하게 되면, 단일체일 경우 값이 호출 되고, 복합체일 경우 자기 자신을 호출하는 재귀 함수에 의해 저장하고 있는 하위 Leaf 객체들을 순회하여 호출하게 된다.

Composite 패턴 특징

패턴 사용 시기

데이터를 다룰때 계층적 트리 표현을 다루어야 할때
복잡하고 난해한 단일 / 복합 객체 관계를 간편히 단순화하여 균일하게 처리하고 싶을때

패턴 장점

단일체와 복합체를 동일하게 여기기 때문에 묶어서 연산하거나 관리할 때 편리하다.
다형성 재귀를 통해 복잡한 트리 구조를 보다 편리하게 구성 할 수 있다.
수평적, 수직적 모든 방향으로 객체를 확장할 수 있다.
새로운 Leaf 클래스를 추가하더라도 클라이언트는 추상화된 인터페이스 만을 바라보기 때문에 개방 폐쇄 원칙(OCP)을 준수 한다. (단일 부분의 확장이 용이)

패턴 단점

재귀 호출 특징 상 트리의 깊이(depth)가 깊어질 수록 디버깅에 어려움이 생긴다.
설계가 지나치게 범용성을 갖기 때문에 새로운 요소를 추가할 때 복합 객체에서 구성 요소에 제약을 갖기 힘들다.
예를들어, 계층형 구조에서 leaf 객체와 composite 객체들을 모두 동일한 인터페이스로 다루어야하는데, 이 공통 인터페이스 설계가 까다로울 수 있다.
- 복합 객체가 가지는 부분 객체의 종류를 제한할 필요가 있을 때
- 수평적 방향으로만 확장이 가능하도록 Leaf를 제한하는 Composite를 만들때

예제를 통해 알아보는 Composite 패턴

아이템을 담는 가방을 담은 가방

복합(composite) 객체와 단일(leaf) 객체를 상자와 아이템으로 비유하자면 아래 그림과 같이 표현할 수 있을 것이다. 상자 안에 아이템을 넣고, 다시 그 상자를 상자 안에 넣는 식으로 말이다.

이러한 구조를 객체 지향 프로그래밍으로 보다 유지보수가 용이하게 컴포지트 패턴을 통해 구현해보자.

다음 Item 클래스와 그를 담는 Bag 클래스가 있다고 하자. 가방안에 아이템을 담는 형식이니, Item 클래스는 Leaf가 되고 Bag 클래스는 Composite가 된다.

아래 코드에서 우리가 구현하고 싶은 것은 Bag 속 리스트에 담겨진 Item 객체들의 총 가격(price) 값을 추출하고 싶다고 한다. 그런데 단순히 가방 안에 아이템들이 들어있을 뿐 아니라 복수의 아이템을 담은 또다른 가방들이 여러개 들어 있을 수 있고 그 가방안에 가방이 들어있을 수 있다. 그렇다면 루트 가방일 경우 하위 계층까지 순회하여 아이템의 price값을 합산해야 되는데 이러한 계층 트리 구조를 컴포지트 패턴으로 클래스를 구성을 하면 아래와 같이 되게 된다.

Composite와 Leaf 객체를 공용으로 묶는 ItemComponent 인터페이스를 정의하고, Composite와 Leaf 객체에서 동시에 쓰이는 추상 메소드를 정의한다.
Composite 객체인 Bag 클래스에서 ItemComponent 타입의 공용 아이템을 담는 내부 리스트를 정의한다.
Component 인터페이스의 공통적인 operation인 ~~getPrice()~~ 메서드는 Item일 경우 그대로 price값을 반환하면 되지만, Bag일 경우 가방은 단순히 아이템을 담는 그릇일 뿐이기 때문에 자기 자신을 호출하여 현재 가방에 들어있는 Item을 순회하는 재귀 동작을 행하게 된다.

// Component 인터페이스
interface ItemComponent {
    int getPrice();
    String getName();
}

// Composite 객체
class Bag implements ItemComponent {
    // 아이템들과 서브 가방 모두를 저장하기 위해 인터페이스 타입 리스트로 관리
    List<ItemComponent> components = new ArrayList<>();

    String name; // 가방 이름

    public Bag(String name) {
        this.name = name;
    }

    // 리스트에 아이템 & 가방 추가
    public void add(ItemComponent item) {
        components.add(item); 
    }

    // 현재 가방의 내용물을 반환
    public List<ItemComponent> getComponents() {
        return components; 
    }

    @Override
    public int getPrice() {
        int sum = 0;

        for (ItemComponent component : components) {
            // 만일 리스트에서 가져온 요소가 Item이면 정수값을 받을 것이고, Bag이면 '재귀 함수' 동작이 되게 된다 ☆
            sum += component.getPrice(); // 자기 자신 호출(재귀)
        }

        return sum; // 그렇게 재귀적으로 돌아 하위 아이템들의 값을 더하고 반환하게 된다.
    }

    @Override
    public String getName() {
        return name;
    }
}

// Leaf 객체
class Item implements ItemComponent {
    String name; // 아이템 이름
    int price; // 아이템 가격

    public Item(String name, int price) {
        this.name = name;
        this.price = price;
    }

    @Override
    public int getPrice() {
        return price;
    }

    @Override
    public String getName() {
        return name;
    }
}

class Client {
    public static void main(String[] args) {

        // 1. 메인 가방 인스턴스 생성
        Bag bag_main = new Bag("메인 가방");

        // 2. 아이템 인스턴스 생성
        Item armor = new Item("갑옷", 250);
        Item sword = new Item("장검", 500);

        // 3. 메인 가방에는 모험에 필요한 무구 아이템만을 추가
        bag_main.add(armor);
        bag_main.add(sword);

        // 4. 서브 가방 인스턴스 생성
        Bag bag_food = new Bag("음식 가방");

        // 5. 아이템 인스턴스 생성
        Item apple = new Item("사과", 400);
        Item banana = new Item("바나나", 130);

        // 6. 서브 가방에는 음식 아이템만을 추가
        bag_food.add(apple);
        bag_food.add(banana);

        // 7. 서브 가방을 메인 가방에 넣음
        bag_main.add(bag_food);

        // ----------------------------------------------------- //

        Client client = new Client();

        // 가방 안에 있는 모든 아이템의 총 값어치를 출력 (가방안에 아이템 뿐만 아니라 서브 가방도 들어있음)
        client.printPrice(bag_main);

        // 서브 가방 안에 있는 모든 아이템의 총 값어치를 출력
        client.printPrice(bag_food);
    }

    public void printPrice(ItemComponent bag) {
        int result = bag.getPrice();
        System.out.println(bag.getName() + "의 아이템 총합 : " + result + " 골드");
    }
}

클라이언트에서는 ItemComponent 만을 사용하기 때문에 Item, Bag 구현체 상관 없이(전체, 개별 구분 없이) 구현 메소드만 호출하면 내부에서 정의된 구현에 따라 원하는 값을 얻을 수 있게 된다.

만일 패턴을 사용하지 계층 트리 구조를 구현하기 위해 매우 하드한 코딩을 해야 할지도 모른다.

파일 디렉토리 시스템 구현

본 포스팅 초반에 에시를 들었던 파일-폴더 시스템을 구현해보자. 예를들어 리눅스에서 ls 나 ~~tree~~ 명령어를 쓰면 파일들이 일괄적으로 출력되는데 이 기능을 비슷하게 컴포지트 패턴을 통해 구성해보고자 한다. 위에서 한번 연습했던 가방-아이템 구조를 폴더-파일 구조로 그대로 치환만 하면 된다.

// Component
interface Node {
    // 계층 트리 출력
    void print();
    void print(String str);

    // 파일/폴더 용량 얻기
    int getSize();
}

// Composite
class Folder implements Node {
    private String name; // 폴더 이름

    private ArrayList<Node> list;

    public Folder(String name) {
        this.name = name;
        list = new ArrayList<>();
    }

    // 리스트에 폴더, 파일 추가
    public void add(Node node) {
        list.add(node);
    }

    // 공백 indent 표현 처리를 위한 print 메서드 오버로딩
    public void print() {
        this.print("");
    }

    public void print(String str) {
        int size = getSize(); // 폴더가 담고 있는 모든 파일에 대한 용량 합산

        System.out.println(str + "\uD83D\uDCC2" + name + " (" + size + "kb)");

        for (Node node : list) {
            // Folder 일 경우 재귀 동작
            node.print(str + "    "); // 인자로 공백문자를 할당하여 indent 처리
        }
    }

    // 각 파일의 용량(kb) 구하기
    public int getSize() {
        int sum = 0;
        for (Node node : list) {
            sum += node.getSize(); // print 로직과 똑같이 재귀 동작
        }
        return sum;
    }
}

// Leaf
class File implements Node {
    private String name; // 파일 이름
    private int size; // 파일 사이즈

    public File(String name, int size) {
        this.name = name;
        this.size = size;
    }

    public void print() {
        this.print("");
    }

    public void print(String str) {
        System.out.println(str + "\uD83D\uDCDC" + name + " (" + size + "kb)");
    }
    
    public int getSize() {
        return size;
    }
}

class Client {
    public static void main(String[] args) {

        Folder root = new Folder("root");

        File file1 = new File("file1", 10);
        Folder sub1 = new Folder("sub1");
        Folder sub2 = new Folder("sub2");

        root.add(sub1);
        root.add(file1);
        root.add(sub2);

        File file11 = new File("file11", 10);
        File file12 = new File("file12", 10);

        sub1.add(file11);
        sub1.add(file12);

        File file21 = new File("file21", 10);

        sub2.add(file21);

        // 전체 dir 출력
        root.print();
    }
}

클라이언트에선 폴더든 파일이든 노드 객체를 생성하고 복합체인 폴더에 추가만 해주면 알아서 계층 구조가 형성되게 되고, 이를 순회할때 재귀 동작을 통해 모든 노드들을 접근하게 된다.

참고로 print 메서드를 두개로 오버로딩(overloading) 한게 이상할수도 있지만, 공백 indent를 표현하기 위한 기법 중 하나이다. 문자열 파라미터를 가진 print 메서드를 재귀적으로 호출하여 공백을 추가하는 식이다.

# 참고자료

코딩으로 학습하는 GoF의 디자인 패턴 - 백기선

https://www.youtube.com/watch?v=g96bJvVDZPs

https://refactoring.guru/design-patterns/composite

https://stacktraceguru.com/composite-design-pattern/

http://www-sop.inria.fr/axis/cbrtools/usermanual-eng/Patterns/Composite.html

https://springframework.guru/gang-of-four-design-patterns/composite-pattern/

경량(Flyweight) 패턴 - 완벽 마스터하기

인파_ — Mon, 20 Mar 2023 09:05:59 +0900

Flyweight Pattern

플라이웨이트 패턴(Flyweight Pattern)은 재사용 가능한 객체 인스턴스를 공유시켜 메모리 사용량을 최소화하는 구조 패턴이다. 간단히 말하면 캐시(Cache) 개념을 코드로 패턴화 한것으로 보면 되는데, 자주 변화는 속성(extrinsit)과 변하지 않는 속성(intrinsit)을 분리하고 변하지 않는 속성을 캐시하여 재사용해 메모리 사용을 줄이는 방식이다. 그래서 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 최적화를 노리는 경량 패턴이라고도 불린다.

Flyweight 단어 의미는 Fly(가벼운) + Weight(무게)를 뜻함으로써, 복싱의 체급에서 유래되었다. 이를 자바 프로그래밍에 접목해보면 모든 객체를 일일히 인스턴스화 하지않고 재사용할수 있는 객체는 재사용함으로써 메모리를 가볍게 만든다는 의미로서 쓰인다보 보면 된다.

객체를 일일히 생성한것과 객체를 공유 상태로 만든 것에 대한 메모리 무게 차이

플라이웨이트 패턴 구조

Flyweight : 경량 객체를 묶는 인터페이스.
ConcreteFlyweight : 공유 가능하여 재사용되는 객체 (intrinsic state)
UnsahredConcreteFlyweight : 공유 불가능한 객체 (extrinsic state)
FlyweightFactory : 경량 객체를 만드는 공장 역할과 캐시 역할을 겸비하는 Flyweight 객체 관리 클래스
- GetFlyweight() 메서드는 팩토리 메서드 역할을 한다고 보면 된다.
- 만일 객체가 메모리에 존재하면 그대로 가져와 반환하고, 없다면 새로 생성해 반환한다
Client : 클라이언트는 FlyweightFactory를 통해 Flyweight 타입의 객체를 얻어 사용한다.

intrinsic 와 extrinsic 상태

플라이웨이트 패턴에서 가장 주의 깊게 보아야 할 점이 바로 Intrinsic와 Extrinsic의 상태를 구분하는 것이다.

intrinsic란 '고유한, 본질적인' 이라는 의미를 가진다. 본질적인 상태란 인스턴스가 어떠한 상황에서도 변하지 않는 정보를 말한다. 그래서 값이 고정되어 있기에 충분히 언제 어디서 공유해도 문제가 없게 된다.

extrinsic이란 '외적인, 비본질적인' 이라는 의미를 가진다. 인스턴스를 두는 장소나 상황에 따라서 변화하는 정보를 말한다. 그래서 값이 언제 어디서 변화할지 모르기 때문에 이를 캐시해서 공유할수 는 없다.

intrinsic한 객체 : 장소나 상황에 의존하지 않기 때문에 값이 고정되어 공유할 수 있는 객체
extrinsic한 객체 : 장소나 상황에 의존하기 때문에 매번 값이 바뀌어 공유할 수 없는 객체

폭탄 피하기 게임을 예를 들어보자.

무수히 떨어지는 폭탄 들은 모두 하나의 객체일 것인데, 이 폭탄 객체들을 일일히 new 를 통해 인스턴스화하면 객체를 생성 할때마다 메모리를 차지하게 되어 게임이 무거워질 것이다. 떨어지는 폭탄 객체는 어차피 모두 같기 때문에 이를 일일히 생성하는건 중복이기 때문이다. 따라서 이 폭탄을 플라이웨이트로 처리함으로써 폭탄 인스턴스는 하나만 만들고 공유하여 이를 가져와 화면에 흩뿌리면 될 일이다. 그런데 여기서 플라이웨이트 적용 기준이 되는 상태를 구분할 필요가 있다.

우선 떨어지는 폭탄들이 가지고 있는 정보는 다음과 같다고 한다.

폭탄 모양
폭탄 색깔
폭탄 x, y 좌표 위치

여기서 폭탄 모양이나 색깔 값은 본질적인 폭탄 상태를 나타나기 때문에 캐시하여 여러 곳에 공유할 수 있다. 반면 폭탄 객체의 x, y 좌표 값은 실시간으로 변화하기 때문에 이를 캐시하여 공유할 수는 없다.

따라서 폭탄 클래스 구조를 플라이웨이트 디자인 패턴으로 표현한다면, 폭탄의 형태나 색깔 같은 고정 정보를 포함하고 있는 객체는 ConcreteFlyweight로 구현 되고, 폭탄의 좌표값 같은 정보를 변화 정보를 포함하고 있는 객체는 UnsahredConcreteFlyweight로 구현 되게 된다. 그리고 이 폭탄 객체를 FlyweightFactory가 생성하고 캐싱하고 관리를 하는 것이다.

플라이웨이트 패턴 특징

패턴 사용 시기

어플리케이션에 의해 생성되는 객체의 수가 많아 저장 비용이 높아질 때
생성된 객체가 오래도록 메모리에 상주하며 사용되는 횟수가 많을때
공통적인 인스턴스를 많이 생성하는 로직이 포함된 경우
임베디드와 같이 메모리를 최소한으로 사용해야하는 경우에 활용

패턴 장점

애플리케이션에서 사용하는 메모리를 줄일 수 있다.
프로그램 속도를 개선 할수 있다.
- new로 인스턴스화를 하면 데이터가 생성되고 메모리에 적재 되는 미량의 시간이 걸리게 된다.
- 객체를 공유하면 인스턴스를 가져오기만 하면 되기 때문에 메모리 뿐만 아니라 속도도 향상시킬 수 있게 되는 것이다.

패턴 단점

아무래도 코드의 복잡도가 증가한다.

예제를 통해 알아보는 Flyweight 패턴

마인크래프트 필드에 나무 심기

아래 사진과 같이 마인크래프트에 숲을 구현하기 위해 지형(Terrain)에 나무 객체들을 심으려고 한다.

이 나무(Tree) 객체에 대해 필요한 데이터는 다음과 같다고 한다.

나무 종류
메시 폴리곤 (mesh)
나무껍질 텍스쳐 (texture)
잎사귀 텍스쳐 (texture)
위치 매개변수

나무에도 여러가지 종류의 나무가 있으며, 나무의 형태를 구현하는 mesh와 texture 그리고 나무가 어느 지형 좌표에 심어질지에 대한 x, y 위치 매개변수가 필요하다.

나무 종류

클린하지 않은 문제의 코드 ❌

가장 심플한 방법은 Tree 객체를 new 생성자로 인스턴스화 하여 배치하는 것이다. 하지만 이렇게 하면 아마 메모리 부족으로 게임이 터져버릴 것이다.

하나의 나무 객체가 포함하고 있는 메시와 텍스쳐의 데이터의 크기는 만만치 않으며, 이렇게 많은 나무 객체로 이루어진 숲 전체를 하나의 화면에 담아내기에는 무리이기 때문이다.

class Memory {
    public static long size = 0; // 메모리 사용량

    public static void print() {
        System.out.println("총 메모리 사용량 : " + Memory.size + "MB");
    }
}

class Tree {
    long objSize = 100; // 100MB

    String type; // 나무 종류

    Object mesh; // 메쉬
    Object texture; // 나무 껍질 + 잎사귀 텍스쳐

    // 위치 변수
    double position_x;
    double position_y;

    public Tree(String type, Object mesh, Object texture, double position_x, double position_y) {
        this.type = type;
        this.mesh = mesh;
        this.texture = texture;
        this.position_x = position_x;
        this.position_y = position_y;

        // 나무 객체를 생성하였으니 메모리 사용 크기 증가
        Memory.size +=  this.objSize;
    }
}

// Client
class Terrain {
    // 지형 타일 크기
    static final int CANVAS_SIZE = 10000;

    // 나무를 렌더릴
    public void render(String type, Object mesh, Object texture, double position_x, double position_y) {
        // 나무를 지형에 생성
        Tree tree = new Tree(
                type, // 나무 종류
                mesh, // mesh
                texture, // texture
                Math.random() * CANVAS_SIZE, // position_x
                Math.random() * CANVAS_SIZE // position_y
        );

        System.out.println("x:" + tree.position_x + " y:" + tree.position_y + " 위치에 " + type + " 나무 생성 완료");
    }
}

public static void main(String[] args) {
    // 지형 생성
    Terrain terrain = new Terrain();

    // 지형에 Oak 나무 5 그루 생성
    for (int i = 0; i < 5; i++) {
        terrain.render(
                "Oak", // type
                new Object(), // mesh
                new Object(), // texture
                Math.random() * Terrain.CANVAS_SIZE, // position_x
                Math.random() * Terrain.CANVAS_SIZE // position_y
        );
    }

    // 지형에 Acacia 나무 5 그루 생성
    for (int i = 0; i < 5; i++) {
        terrain.render(
                "Acacia", // type
                new Object(), // mesh
                new Object(), // texture
                Math.random() * Terrain.CANVAS_SIZE, // position_x
                Math.random() * Terrain.CANVAS_SIZE // position_y
        );
    }

    // 지형에 Jungle 나무 5 그루 생성
    for (int i = 0; i < 5; i++) {
        terrain.render(
                "Jungle", // type
                new Object(), // mesh
                new Object(), // texture
                Math.random() * Terrain.CANVAS_SIZE, // position_x
                Math.random() * Terrain.CANVAS_SIZE // position_y
        );
    }

    // 총 메모리 사용률 출력
    Memory.print();
}

각각 Oak 나무, Acacia 나무, Jungle 나무 5개씩 100MB를 곱하면 총 1500 MB 메모리가 사용되게 된다.

플라이웨이트 패턴을 적용한 코드 ✔️

최적화의 핵심은 나무가 수백 그루 넘게 있는다 해도 대부분 비슷하게 보인다는 것이다. 즉, 나무를 생성하는데 사용된 mesh와 texture를 재사용하여 표현해도 어차피 같은 나무이니 문제가 없는 것이다.

따라서 공통으로 사용되는 모델 데이터와 실시간으로 변하는 위치 매개변수를 분리하여 객체를 구성해주면, 지형에서 나무를 구현할때 나무 모델 인스턴스 하나를 공유받고 위치 매개변수만 다르게 설정해주면 메모리 사용량을 절반 이상을 줄일 수 있을 것이다.

1. intrinsic 객체와 extrinsic 객체 쪼개기

마인크래프트 게임 내에서 똑같은 메시와 나무껍질 텍스쳐를 일일히 여러번 메모리에 올릴 이유가 없기 때문에 공유되는 나무 모델 객체를 기존 Tree 클래스에서 따로 빼준다. 그러면 아래와 같이 TreeModel 클래스는 ConcreteFlyweight가 되고 좌표값을 가지고 있는 기존 Tree 클래스는 UnsahredConcreteFlyweight 가 된다.

// ConcreteFlyweight - 플라이웨이트 객체는 불변성을 가져야한다. 변경되면 모든 것에 영향을 주기 때문이다.
final class TreeModel {
    // 메시, 텍스쳐 총 사이즈
    long objSize = 90; // 90MB

    String type; // 나무 종류
    Object mesh; // 메쉬
    Object texture; // 나무 껍질 + 잎사귀 텍스쳐

    public TreeModel(String type, Object mesh, Object texture) {
        this.type = type;
        this.mesh = mesh;
        this.texture = texture;

        // 나무 객체를 생성하여 메모리에 적재했으니 메모리 사용 크기 증가
        Memory.size += this.objSize;
    }
}

// UnsahredConcreteFlyweight
class Tree {
    // 죄표값과 나무 모델 참조 객체 크기를 합친 사이즈
    long objSize = 10; // 10MB

    // 위치 변수
    double position_x;
    double position_y;

    // 나무 모델
    TreeModel model;

    public Tree(TreeModel model, double position_x, double position_y) {
        this.model = model;
        this.position_x = position_x;
        this.position_y = position_y;

        // 나무 객체를 생성하였으니 메모리 사용 크기 증가
        Memory.size +=  this.objSize;
    }
}

이때 Tree 클래스와 TreeModel 간의 관계를 맺어주어야 하는데, 상속을 통해 해주어도 되고, 이 예제에서는 합성(Composition)을 통해 맺어주었다. 그리고 ConcreteFlyweight인 TreeModel 클래스를 final화 시켜 불변 객체로 만들어준다. 나무 모델은 중간에 메시와 텍스쳐가 변경될 일이 없기 때문이다.

2. Flyweight 팩토리 만들기

나무 모델 객체에 플라이웨이트를 적용하였으니 이를 생성하고 관리하는 FlyweightFactory 클래스를 만든다.

플라이웨이트 팩토리의 핵심은 다음과 같다.

Flyweight Pool : HashMap 컬렉션을 통해 키(key) 와 나무 모델 객체를 저장하는 캐시 저장소 역할
getInstance 메서드 : Pool에 가져오고자 하는 객체가 있는지 검사를 하여 있으면 그대로 반환, 없으면 새로 생성

// FlyweightFactory
class TreeModelFactory {
    // Flyweight Pool - TreeModel 객체들을 Map으로 등록하여 캐싱
    private static final Map<String, TreeModel> cache = new HashMap<>(); // static final 이라 Thread-Safe 함

    // static factory method
    public static TreeModel getInstance(String key) {
        // 만약 캐시 되어 있다면
        if(cache.containsKey(key)) {
            return cache.get(key); // 그대로 가져와 반환
        } else {
            // 캐시 되어있지 않으면 나무 모델 객체를 새로 생성하고 반환
            TreeModel model = new TreeModel(
                    key,
                    new Object(),
                    new Object()
            );
            System.out.println("-- 나무 모델 객체 새로 생성 완료 --");

            // 캐시에 적재
            cache.put(key, model);

            return model;
        }
    }
}

3. Client 최적화 하기

기존 Terrain 클래스의 나무를 생성하는 render() 메서드의 내부 로직은 단순히 사용자로부터 매개변수를 받아 그대로 tree 객체를 생성할 뿐이었다. 그러나 기존 Tree 객체를 따로 TreeModel로 나누로, TreeModelFactory 까지 생성하였으니 이제 이들을 이용하는 클라이언트의 코드를 최적화 작업을 진행해 주어야 한다.

Flyweight를 이용한 최적화 작업은 다음과 같다.

먼저 TreeModel 에서 공유되고 있는 나무 모델 객체를 가져온다. (없다면 새로 생성)
가져온 나무 모델과 좌표값을 이용해 나무 객체를 새로 생성한다.

단순히 2단계로 구성된것 뿐이지만, 공유 객체를 가져와 사용함으로써 쓸데없는 mesh와 texture 낭비를 방지한 것이다.

// Client
class Terrain {
    // 지형 타일 크기
    static final int CANVAS_SIZE = 10000;

    // 나무를 렌더릴
    public void render(String type, double position_x, double position_y) {
        // 1. 캐시 되어 있는 나무 모델 객체 가져오기
        TreeModel model = TreeModelFactory.getInstance(type);

        // 2. 재사용한 나무 모델 객체와 변화하는 속성인 좌표값으로 나무 생성
        Tree tree = new Tree(model, position_x, position_y);

        System.out.println("x:" + tree.position_x + " y:" + tree.position_y + " 위치에 " + type + " 나무 생성 완료");
    }
}

public static void main(String[] args) {
    // 지형 생성
    Terrain terrain = new Terrain();

    // 지형에 Oak 나무 5 그루 생성
    for (int i = 0; i < 5; i++) {
        terrain.render(
                "Oak", // type
                Math.random() * Terrain.CANVAS_SIZE, // position_x
                Math.random() * Terrain.CANVAS_SIZE // position_y
        );
    }

    // 지형에 Acacia 나무 5 그루 생성
    for (int i = 0; i < 5; i++) {
        terrain.render(
                "Acacia", // type
                Math.random() * Terrain.CANVAS_SIZE, // position_x
                Math.random() * Terrain.CANVAS_SIZE // position_y
        );
    }

    // 지형에 Jungle 나무 5 그루 생성
    for (int i = 0; i < 5; i++) {
        terrain.render(
                "Jungle", // type
                Math.random() * Terrain.CANVAS_SIZE, // position_x
                Math.random() * Terrain.CANVAS_SIZE // position_y
        );
    }

    // 총 메모리 사용률 출력
    Memory.print();
}

패턴 적용 전에는 1500MB 메모리 사용량이 들었지만, 패턴 적용 후에는 메모리 사용량이 확연히 줄어들었음을 확인할 수 있다. 이전에는 통짜로 나무 객체를 생성함에 비해, 나무 모델을 따로 플라이웨이트로 분리함으로써 중복된 mesh, texture 사용을 공유시켜 메모리를 아낀 것이다.

이처럼 공유할수 있는 intrinsic(본질적) 상태의 데이터를 분간하여 캐싱함으로써 프로그램을 최적화를 추구하는것이 훌륭한 프로그래머의 자질이라고 할수 있을 것이다.

Garbage Collection 처리 주의사항 ️

위에서 구현한 TreeModelFactory에서는 HashMap을 이용해 TreeModel의 인스턴스를 캐싱하여 관리하고 있다. 이와 같이 '인스턴스를 관리' 하는 기능을 자바 프로그래밍에서 구현하여 사용할 때에는 반드시 '관리되고 있는 인스턴스는 GC(Garbage Collection) 처리되지 않는다' 라는 점을 주의해야 한다.

즉, 나무를 모두 렌더링을 완료하여 더이상 나무를 생성할 일이 없다라면, 반드시 TreeModelFactory에 잔존해있는 Flyweight Pool 을 비워줄 필요가 있는 것이다. 그래야 인스턴스에 대한 참조를 잃은 TreeModel 인스턴스들이 GC에 의해 메모리 청소가 되게 된다. 그렇지 않으면 더이상 나무를 생성할 일이 없는데도 TreeModel 데이터가 메모리에 쓸데없이 잔존하게 된다. 메모리 최적화를 위해 플라이웨이트 패턴을 썼는데 마지막 맺음에서 이렇게 허점이 생기면 뒤가 쓰린 법이다.

[JAVA] ☕ 가비지 컬렉션 동작 원리 & GC 종류 총정리

가비지 컬렉션(GC) 란? 가비지 컬렉션(Garbage Collectoin, 이하 GC)은 자바의 메모리 관리 방법 중의 하나로 JVM(자바 가상 머신)의 Heap 영역에서 동적으로 할당했던 메모리 중 필요 없게 된 메모리 객체(

inpa.tistory.com

실무에서 찾아보는 Flyweight 패턴

Java

String Constant Pool

String Constant Pool 개념이 바로 Flyweight Pool 개념이다.
자바는 String 데이터에 대해 별도로 string constant pool 영역에 적재한다.
그래서 같은 문자열 데이터 다시 사용될때 pool을 검사해 있다면 이를 공유한다.
만일 pool에 없다면 새로 메모리를 할당하여 pool에 등록한 후 재사용한다.
즉, String 클래스는 Flyweight 패턴을 통해 리터럴 문자열 데이터에 대한 캐싱을 하고 있는 것이다.
또한 String 클래스는 불변(immutable) 객체 특성을 가지고 있다.

[JAVA] ☕ String 타입 특징 이해하기 (String Pool & 문자열 비교)

여타 대부분의 프로그래밍 언어에서 문자열 이라는 데이터를 저장하기 위해 string 이라는 데이터 타입을 사용한다. 이 string 데이터를 다루는데 있어 특별히 유의해야 할점은 없어보이지만, 자바

inpa.tistory.com

// 문자열 리터럴은 String Pool에 저장되는 Flyweight 패턴을 이용한다.
String str1 = "Hello"; 
String str2 = "Hello";
 
// 두 주소값이 같다는 말은 메모리에 하나의 데이터만 적재되고 이를 공유하고 있다는 반증
System.out.println(str1 == str2); // true

// new 연산자를 이용한 방식은 Flyweight 패턴을 적용하지 않는다.
String str3 = new String("Hello"); 
String str4 = new String("Hello");

// 서로 다른 힙 메모리에 저장된 데이터이니 두 주솟값은 다르다
System.out.println(str3 == str4); // false

Integer의 valueOf()

자바의 Interger 클래스의 ~~valueOf()~~ 메서드는 정적 팩토리 메서드로서, ~~valueOf()~~ 메서드를 통해 값을 할당하면 Flyweight 패턴을 통해 캐시되게 된다.
~~valueOf()~~ 메소드가 호출 되었을 때 요청된 Integer 값이 -128 ~ 127 범위의 정수라면 캐싱을 이용하도록 설계 되어있다.
Integer 뿐만 아니라 Double이나 Boolean 같은 Wrapper 클래스들도 마찬가지로 적용된다.

// valueOf 정적 팩토리 메서드로 수를 등록하면 캐시됨
// auto boxing으로 Integer i1 = 100; 으로 선언하여도 똑같음
Integer i1 = Integer.valueOf(100); 
Integer i2 = Integer.valueOf(100);

System.out.println(i1 == i2); // true

// 생성자로 수를 등록하면 캐시 안됨
Integer i3 = new Integer(100);
Integer i4 = new Integer(100);

System.out.println(i3 == i4); // false

// -128 ~ 127 는 캐시 됨
Integer i1 = Integer.valueOf(100);
Integer i2 = Integer.valueOf(100);

System.out.println(i1 == i2); // true

// -128 ~ 127 를 넘어선 수는 캐시 안됨
Integer i3 = Integer.valueOf(1000);
Integer i4 = Integer.valueOf(1000);

System.out.println(i3 == i4); // false

# 참고자료

코딩으로 학습하는 GoF의 디자인 패턴 - 백기선

https://refactoring.guru/design-patterns/flyweight

https://www.hanbit.co.kr/channel/series/series_view.html?cms_code=CMS3043948395&hcs_idx=3

정적 팩토리 메서드 패턴 (Static Factory Method)

인파_ — Fri, 17 Mar 2023 19:53:32 +0900

Static Factory Method Pattern

정적 팩토리 메서드(Static Factory Method) 패턴은 개발자가 구성한 Static Method를 통해 간접적으로 생성자를 호출하는 객체를 생성하는 디자인 패턴이다. 우리는 지금까지 객체를 인스턴스화 할때 직접적으로 생성자(Constructor)를 호출하여 생성하였는데, 별도의 객체 생성의 역할을 하는 클래스 메서드를 통해 간접적으로 객체 생성을 유도하는 것이다. 그리고 이 정적 메서드를 통칭적으로 정적 팩토리 메서드 패턴이라고 부르는 것이다.

class Book {
    private String title;
    
    // 생성자를 private화 하여 외부에서 생성자 호출 차단
    private Book(String title) { this.title = title; }
    
    // 정적 팩토리 메서드
    public static Book titleOf(String title) {
        return new Book(title); // 메서드에서 생성자를 호출하고 리턴함
    }
}

public static void main(String[] args) {
	// 정적 메서드 호출을 통해 인스턴스화된 객체를 얻음
    Book book1 = Book.titleOf("어린왕자"); 
}

정적 팩토리 메서드는 이름 취지에서도 알 수 있듯이 GOF의 팩토리 메서드, 추상 팩토리 패턴의 팩토리(Factory) 개념을 따와 심플하게 변형시킨 팩토리 변형 패턴 종류라고 보면 된다.

그렇다면 왜 멀쩡한 생성자를 냅두고 번거롭게 한단계 거쳐 정적 팩토리 메서드를 통해 객체를 생성하는지에 대한 실용성에 대해 의문을 가질것이다. 그런데 실제로 정적 팩토리 메서드는 단순히 생성자의 역할을 대신 이행하는 것 뿐만 아니라 개발자가 좀 더 가독성 좋은 코드를 작성하고 객체 지향적으로 프로그래밍 할 수 있게 도와주기 때문에 실무에서도 심심치 않게 사용되고 있다. 이것은 생성자(Constructor)의 본질적인 문제점을 극복하기 위해서 이기도 한데, 지금부터 왜 정적 팩토리 메서드를 이용해야 되는지에 대한 이유를 알아보자.

생성자 대신 정적 팩토리 메서드를 고려하라

자바 프로그래밍의 간판이라 할수 있는, 조슈아 블로크(Joshua J. Bloch)의 저서 [이펙티브 자바] 책에서 소개하는 아이템 중에서 첫 번째로 조언 하는것이 바로 '생성자 대신 정적 팩토리 메서드를 고려하라' 이다. 정적 팩토리 메서드에 어떠한 특징이 있길래 이렇게 강조하는지 특징에 대해 차례차례로 알아가보자.

정적 팩토리 메서드 특징

1. 생성 목적에 대한 이름 표현이 가능하다

지금까지 클래스를 설계할때 다양한 타입의 객체를 생성하기 위해, 생성 목적에 따라 생성자를 오버로딩하여 구분하여 사용해왔다. 하지만 문제는 이러한 객체를 new 키워드를 통해 생성자로 생성하려면, 개발자는 해당 생성자의 인자 순서와 내부 구조를 알고 있어야 목적에 맞게 객체를 생성할수가 있다는 번거로움이 있다.

예를들어 다음과 같이 Car 클래스는 브랜드명과 자동차 색깔을 정의하는 멤버를 가지고 있다고 하자. 브랜드명은 반드시 생성자를 통해 외부로부터 입력을 받아야 되지만, 자동차 색깔은 기본값이 '검정'이며 선택적으로 입력받을 수 있다고 한다. 즉, 객체 생성에 있어 필수 속성과 선택 속성이 나뉘게 되는데, 이를 생성자를 통해 구현하면 두가지 형식의 생성자 오버로딩으로 처리하고, 이를 호출하는 쪽에서 생성자의 인자 갯수를 다르게 할당함으로써 구현해야 된다.

class Car {
    private String brand;
    private String color = "black";

    public Car(String brand, String color) {
        this.brand = brand;
        this.color = color;
    }

    public Car(String brand) {
        this.brand = brand;
    }
}

public static void main(String[] args) {
    // 검정색 테슬라 자동차 
    Car teslaCar = new Car("Tesla");

    // 빨간색 BMW 자동차
    Car bmwRedCar = new Car("BMW", "Red");
}

지금까지는 아는게 이것밖에 없어 이런식으로 사용해왔겠지만 위의 방식은 문제점이 있다.

프로그래밍 할때 중요한 요소 중에 하나가 코드를 읽기 쉽도록 작성해야 한다는 점이다. 그런 의미에서 new 생성자 방법은 단지 매개변수의 유형과 개수를 제안할 뿐이지 어떠한 역할 표현이나 편의성을 제공하지 않는다. 즉, 생성자로 넘기는 매개변수 만으로는 반환될 객체의 특성을 제대로 표현하기가 어렵다는 것이다.

만일 나 자신이 클래스를 설계하고 오로지 나만 클래스를 이용한다고 가정한다면 이는 큰 문제가 되지 않는다. 하지만 패키지로 배포하여 남이 사용한다거나 협업을 해야된다면 말은 달라진다. 외부 사용자 입장에선 ~~new Car()~~ 에 몇개를, 몇번째 인자에 어떤 타입을 할당해야 자신이 원하는 색깔의 브랜드 자동차를 생성할수 있는지에 대한 정보를 얻기 위해선 결국은 Car 클래스 내부 구조를 뜯어봐야 한다. 만일 클래스가 바이트로 컴파일된 상태라면 이를 디컴파일 해야하고 번거롭다.

이러한 현상은 생성자 이름은 반드시 클래스 이름으로 고정되어 있기 때문에 일어나는 현상이다. 그냥 언어 설계상 어쩔수 없는 것이다.

따라서 정적 메서드를 통해 적절한 메서드 네이밍을 해준다면 반환될 객체의 특성을 한번에 유추할 수 있게 된다. 왜냐하면 네이밍을 통해 어떤 값을 이용해 자동차 객체를 만들려고 하는지 쉽게 설계 의도를 전달할 수 있기 때문이다.

class Car {
    private String brand;
    private String color;

    // private 생성자
    private Car(String brand, String color) {
        this.brand = brand;
        this.color = color;
    }

    // 정적 팩토리 메서드 (매개변수 하나는 from 네이밍)
    public static Car brandBlackFrom(String brand) {
        return new Car(brand, "black");
    }

    // 정적 팩토리 메서드 (매개변수 여러개는 of 네이밍)
    public static Car brandColorOf(String brand, String color) {
        return new Car(brand, color);
    }
}

public static void main(String[] args) {
    // 검정색 테슬라 자동차 
    Car teslaCar = Car.brandBlackFrom("Tesla");

    // 빨간색 BMW 자동차
    Car bmwRedCar = Car.brandColorOf("BMW", "Red");
}

이처럼 생성자 대신 정적 팩토리 메서드를 호출함으로써 생성될 객체의 특성에 대해 쉽게 묘사할 수 있다는 장점이 있어 코드의 가독성을 높여주게 된다. 생성자로 만드는 것보다 의미를 가진 메소드를 이용하면 객체 생성의 의미를 훨씬 파악하기 쉽기 때문이다.

정적 팩토리 메서드를 구성하고자 한다면, 반드시 생성자에 private 접근 제어자를 두어 외부에서 new 키워드를 이용하여 객체를 생성하는 것을 잊지 말자!

2. 인스턴스에 대해 통제 및 관리가 가능하다

메서드를 통해 한단계 거쳐 간접적으로 객체를 생성하기 때문에, 기본적으로 전반적인 객체 생성 및 통제 관리를 할 수 있게 된다. 즉, 필요에 따라 항상 새로운 객체를 생성해서 반환할 수도 있고, 아니면 객체 하나만 만들어두고 이를 공유하여 재사용하게 하여 불필요한 객체를 생성하는 것을 방지 할 수 있는 것이다.

대표적인 예로 Singleton 디자인 패턴 을 들 수 있는데, getInstance() 라는 정적 팩토리 메서드를 사용해 오로지 하나의 객체만 반환하도록 하여 객체를 재사용해 메모리를 아끼도록 유도할 수 있다.

class Singleton {
    private static Singleton instance;

    private Singleton() {}

    // 정적 팩토리 메서드
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

public static void main(String[] args) {
    Singleton s1 = Singleton.getInstance();
    Singleton s2 = Singleton.getInstance();
    Singleton s3 = Singleton.getInstance();

    System.out.println(s1);
    System.out.println(s2);
    System.out.println(s3);

    System.out.println(s1 == s2);
    System.out.println(s1 == s3);
}

또다른 예로는 인스턴스에 대한 캐싱(Caching) 절차 구조를 정적 팩토리 메서드로 구현할 수 있다. 인스턴스에 대해 캐싱을 한다면 필요한 인스턴스만 뽑아 재사용하여 메모리를 절약할 수 있게 된다.

아래 코드를 살펴보면 요일 정보를 나타내는 Day 객체와, 이 Day 객체를 생성하는 DayFactory 팩토리 객체가 있다. 그중 팩토리 객체를 보면 내부적으로 HashMap 자료구조를 이용하여 key값을 통해 인스턴스를 캐싱하여 관리하고 있는데, 정적 팩토리 메서드가 호출되면 먼저 캐시 저장소를 조회하여 기존 Day 객체가 있는지 검사하고, 있으면 그대로 반환하여 재사용을 유도하고, 없다면 새로 생성해서 캐싱해두게 된다.

이렇게 인스턴스를 통제하는 것은 인스턴스가 단 하나뿐임을 보장하는 것이고, Flyweight 디자인 패턴의 근간이 되게 된다.

class Day {
    private String day;

    public Day(String day) { this.day = day; }

    public String getDay() { return day; }
}

// Day 객체를 생성하고 관리하는 Flyweight 팩토리 클래스
class DayFactory {

	// Day 객체를 저장하는 캐싱 저장소 역할
    private static final Map<String, Day> cache = new HashMap<>();
	
    // 자주 사용될것 같은 Day 객체 몇가지를 미리 등록한다
    static { 
    	cache.put("Monday", new Day("Monday")); 
        cache.put("Tuesday", new Day("Tuesday")); 
        cache.put("Wednesday", new Day("Wednesday")); 
    }

    // 정적 팩토리 메서드 (인스턴스에 대해 철저한 관리)
    public static Day from(String day) {

        if(cache.containsKey(day)) {
            // 캐시 되어있으면 그대로 가져와 반환
            System.out.println("해당 요일은 캐싱되어 있습니다.");
            return cache.get(day);
        } else {
            // 캐시 되어 있지 않으면 새로 생성하고 캐싱하고 반환
            System.out.println("해당 요일은 캐싱되어 있지 않아 새로 생성하였습니다.");
            Day d = new Day(day);
            cache.put(day, d);
            return d;
        }
    }
}

public static void main(String[] args) {
    // 이미 등록된 요일 가져오기
    Day day = DayFactory.from("Monday");
    System.out.println(day.getDay());

    // 등록되지 않은 요일 가져오기
    day = DayFactory.from("Friday");
    System.out.println(day.getDay());
}

이렇게 인스턴스의 생성에 관여하여, 생성되는 인스턴스의 수를 통제할 수 있는 클래스를 인스턴스 통제 (instance-controlled) 클래스라고 한다.

3. 하위 자료형 객체를 반환할 수 있다

클래스의 다형성의 특징을 응용한 정적 팩토리 메서드 특징이다. 메서드 호출을 통해 얻을 객체의 인스턴스를 자유롭게 선택할수 있는 유연성을 갖는 것이다.

interface SmarPhone {}

class Galaxy implements SmarPhone {}
class IPhone implements SmarPhone {}
class Huawei implements SmarPhone {}

class SmartPhones {
    public static SmarPhone getSamsungPhone() {
        return new Galaxy();
    }

    public static SmarPhone getApplePhone() {
        return new IPhone();
    }

    public static SmarPhone getChinesePhone() {
        return new Huawei();
    }
}

이러한 아이디어는 인터페이스를 정적 팩터리 메서드의 반환 타입으로 사용하는 인터페이스 기반 프레임워클르 만드는 핵심이 된다. 대표적으로 자바의 컬렉션 프레임워크인 java.util.Collections 클래스를 들 수 있는데, 이 클래스는 Collection 인터페이스를 반환하는 여러 정적 팩토리 메서드를 가지고 있다.

Collections 클래스와 Collection 인터페이스의 이름을 보면 's' 를 붙인걸 볼 수 있는데, 이것을 Collection 인터페이스의 동반 클래스(Companion Class) 라고 부른다. 위의 SmartPhones 예제 코드에도 컬렉션을 그대로 응용한 것이다.

하지만 java 8 버전부터는 인터페이스가 정적 메서드를 가질수 있게 되어 동반 클래스 개념은 더이상 필요없어졌다. 즉, 인터페이스에 그냥 정적 팩토리 메서드를 선언하면 된다.

interface SmarPhone {
    public static SmarPhone getSamsungPhone() {
        return new Galaxy();
    }

    public static SmarPhone getApplePhone() {
        return new IPhone();
    }

    public static SmarPhone getChinesePhone() {
        return new Huawei();
    }
}

4. 인자에 따라 다른 객체를 반환하도록 분기할 수 있다

메서드이니 매개변수를 받을수 있을테고, 메서드 블록 내에서 분기문을 통해 여러 자식 타입의 인스턴스를 반환하도록 응용 구성이 가능하다. 위의 3번에 대한 확장 예제라고 보면 된다.

interface SmarPhone {
    public static SmarPhone getPhone(int price) {
        if(price > 100000) {
            return new IPhone();
        }

        if(price > 50000) {
            return new Galaxy();
        }

        return new Huawei();
    }
}

5. 객체 생성을 캡슐화 할 수 있다

생성자를 사용하는 경우 외부에 내부 구현을 드러내야 하는데, 정적 팩토리 메서드는 구현부를 외부로 부터 숨길 수 있어 캡슐화(encapsulation) 및 정보 은닉(information hiding)을 할수 있다는 특징이 있다. 또한 노출하지 않는다는 특징은 정보 은닉성을 가지기도 하지만 동시에 사용하고 있는 구현체를 숨겨 의존성을 제거해주는 장점도 지니고 있다. 이 예제 역시 위의 3번의 확장 예이다.

아래 예제 코드를 보면, 메인 메서드에서 오로지 GradeCalculator의 정적 팩토리 메서드 of() 를 호출하여 Grade 인터페이스 타입의 객체를 반환할 뿐이지, Grade 인터페이스의 구현체인 A ~ F 객체 존재에 대해서는 모르게 된다. 즉, 구현체를 생성해서 반환할 책임은 정적 팩토리 메서드를 가진 GradeCalculator 이고, 클라이언트는 구현체를 신경쓸 필요없이 제공되는 메서드를 호출만 하면 되어 편리하게 사용이 가능해진다.

interface Grade {
    String toText();
}

class A implements Grade {
    @Override
    public String toText() {return "A";}
}

class B implements Grade {
    @Override
    public String toText() {return "B";}
}

class C implements Grade {
    @Override
    public String toText() {return "C";}
}

class D implements Grade {
    @Override
    public String toText() {return "D";}
}

class F implements Grade {
    @Override
    public String toText() {return "F";}
}

class GradeCalculator {
	// 정적 팩토리 메서드
    public static Grade of(int score) {
        if (score >= 90) {
            return new A();
        } else if (score >= 80) {
            return new B();
        } else if (score >= 70) {
            return new C();
        } else if (score >= 60) {
            return new D();
        } else {
            return new F();
        }
    }
}

public static void main(String[] args) {
    String jeff_score = GradeCalculator.of(36).toText();
    String herryPorter_score = GradeCalculator.of(99).toText();

    System.out.println(jeff_score); // F
    System.out.println(herryPorter_score); // A
}

정적 팩토리 메서드 네이밍 규칙

정적 팩토리 메서드 와 다른 정적 메서드와 역할을 구분짓기 위해 독자적인 네이밍 컨벤션(Convention)이 존재한다. 단, 정적 팩토리 메서드에서의 네이밍은 단순히 선호도 의미를 넘어서 거의 법칙 정도로 사용되는 것이니, 각 네이밍의 역할에 대해 알아두는 것은 개념을 아는 것만큼 중요하다. (이를 왜 지켜야 되는지는 정적 팩토리 메서드 문제점 색션에서 후술한다)

정적 팩토리 메서드에서 사용되는 네이밍 단어 종류는 다음과 같다.

from : 하나의 매개 변수를 받아서 객체를 생성
of : 여러개의 매개 변수를 받아서 객체를 생성
getInstance | instance : 인스턴스를 생성. 이전에 반환했던 것과 같을 수 있음
newInstance | create : 항상 새로운 인스턴스를 생성
get[OrderType] : 다른 타입의 인스턴스를 생성. 이전에 반환했던 것과 같을 수 있음
new[OrderType] : 항상 다른 타입의 새로운 인스턴스를 생성

// from : 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드
Date d = Date.from(instant);

// of : 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드
Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING);

// valueOf : from과 of의 더 자세한 버전
BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);

// instance 혹은 getInstance : (매개변수를 받는다면) 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지는 않는다.
StackWalker luke = StackWalker.getInstance(options);

Calendar instance = Calendar.getInstance();

// create 혹은 newInstance : instance 혹은 getInstance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장한다.
Object newArray = Array.newInstance(classObject, arrayLen);

// getType : getInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다. Type은 팩터리 메서드가 반환할 객체의 타입이다.
FileStore fs = Files.getFileStore(path);

// newType : newInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다. Type은 팩터리 메서드가 반환할 객체의 타입이다.
BufferedReader br = Files.newBufferdReader(path);

// type : getType과 newType의 간결한 버전
List<Complaint> litany = Collections.list(legacyLitany);

실무에서 찾아보는 정적 팩토리 메서드

사실 우리는 자바에서 제공하는 여러 패키지의 클래스들을 가져와 사용하면서 우리들은 알기도 모르게 정적 팩토리 메서드를 사용해 왔다. 그저 지칭하는 단어만 모르고 있을 뿐 그에 대한 톡톡한 효과를 누리고 있었던 것이다.

Optional의 of()

자바 8버전 부터 지원하는 Optional 객체를 얻기 위해선 아래와 같이 new 키워드 대신 ~~of()~~ 메서드를 이용해 객체를 얻도록 설계 되어 있다. 위에서 배운 정적 팩토리 메서드 네이밍 컨밴션을 잘 따른 예이기도 하다.

Optional<Integer> value = Optional.of(1000);

List의 of()

이부분은 하위 자식 객체 반환 및 캡슐화에 대한 실전 구현체 예이다.

자바 8버전 부터 지원하는 List 인터페이스의 ~~of()~~ 메서드는 인터페이스를 반환하는 정적 팩토리 메서드이다. 사용자 입장에선 반환되는 클래스가 어떤 타입인지 알 필요 없이, 그냥 ~~of()~~ 메서드의 기능이 무엇인지만 알고 호출만 하면 되는 것이다.

// 리터럴 값으로 List 타입 객체 생성
List<Integer> list = List.of(1, 2, 3);

// 배열 객체로 List 타입 객체 생성
Integer[] array = {1,2};
List<Integer> list = List.of(array);

Integer의 valueOf()

이부분은 정적 팩토리 메서드의 '인스턴스를 캐싱하여 관리가 가능하다'는 실제 자바 구현체 예이다.

실제로 primitive 타입의 Wrapper 클래스들은 값을 캐싱(Caching)하여 자바 프로그램을 최적화하도록 설계 되어 있다. 예를들어 Intefer 클래스의 ~~valueOf()~~ 메서드는 입력값이 -128 ~ 127 범위의 정수라면 캐싱을 이용하도록 설계 되어있다.

실제 Interger.valueOf(int i) 메서드 시그니처를 보자면, 파라미터 i 가 캐싱된 상수 숫자의 범위내에 있다면 객체를 새로 생성하지 않고 배열에 미리 생성해 두었던 객체를 반환하는 걸 볼 수 있다. 범위를 벗어난 경우 새로운 객체를 생성한다.

// -128 ~ 127 는 캐시 됨
Integer i1 = Integer.valueOf(100);
Integer i2 = Integer.valueOf(100);

System.out.println(i1 == i2); // true

// -128 ~ 127 를 넘어선 수는 캐시 안됨
Integer i3 = Integer.valueOf(1000);
Integer i4 = Integer.valueOf(1000);

System.out.println(i3 == i4); // false

Lombok으로 정적 팩토리 메서드 만들기

롬복을 이용해 간단하게 정적 팩토리 메서드를 지정해줄 수 있다.

@RequiredArgsConstructor(staticName = "of")
class Product {
    private Long id;
    private String name;
}

public class Main {
    public static void main(String[] args) {
        Product p = Product.of();
    }
}

정적 팩토리 메서드 문제점

생성자보단 정적 팩토리 메서드를 고려해야 하지만, 정적 팩토리 메서드도 단점이 존재하니 이를 잘 파악하고 사용하여야 한다.

1. private 생성자일 경우 상속 불가능

정적 팩토리 메서드로 클래스를 설계를 하면 생성자를 private 접근 제어자로 설정하게 된다. 따라서 정적 팩토리 메서드를 적용하는 경우에는 상속을 이용한 확장이 불가능해진다.

다만, 이 부분은 단점이라기 보단 스펙에 가깝다고 얘기할수 있다.
대표적인 예로 자바의 Collections 클래스를 보면 생성자가 private로 되어 있다. 이는 일부로 상속을 하게 하지 않기 위한 설계된건데, Collections는 자바의 컬렉션에 대한 헬퍼 제공 용도이지 상속을 통해 무언가를 확장하게 하기 위한 용도가 아니기 때문이다. 따라서 이러한 제약은 상속(Inheritance) 보단 합성(Composition)을 사용하도록 유도하게 하거나, 불변(Immutable) 객체로 만들고 싶을때 사용되는 하나의 코드 패턴이라고 보면 된다.

2. API 문서에서의 불편함

생성자는 하나의 자바 프로그래밍 언어의 스펙이기 때문에 JavaDoc 같은 문서에서 상단에 정의되어 있기 때문에 빠르게 그에 대한 스펙 검색을 할수가 있다. 반면에 정적 팩토리 메서드는 개발자가 임의로 만든 메서드이기 때문에, 안그래도 그 많은 메서드들 중에서 정적 팩토리 역할을 하는 메서드를 뒤져서 찾아 이해해야 한다.

따라서 클래스 설계자는 API 문서를 깔끔하게 작성할 필요가 있으며, 정적 팩토리 메서드를 작성할때 네이밍 컨밴션을 지킴으로써 문제점을 극복하기도 한다.

이 많은 메서드 설명을 뒤지기 전에 네이밍 컨밴션으로 역할을 유추가 가능하다

이처럼 정적 팩터리 메서드와 생성자는 각각 장단점을 이해하고 사용하는 것이 좋으나, 대부분 정적 팩토리를 사용하는 게 유리한 경우가 더 많다.

# 참고자료

https://tecoble.techcourse.co.kr/post/2020-05-26-static-factory-method/

Template Callback 디자인 패턴

인파_ — Fri, 17 Mar 2023 19:53:20 +0900

Template Callback Pattern

탬플릿 콜백 패턴(Template Callback Pattern)은 스프링 프레임워크에서 DI(Dependency injection) 의존성 주입에서 사용하는 특별한 전략 패턴이다. 스프링의 JdbcTemplate, RestTemplate, TransactionTemplate, RedisTemplate과 같은곳에 사용된다.

한마디로 GOF 디자인 패턴은 아니고 전략 패턴의 확장판 정도로 보면 된다.

기존의 전략 패턴은 변화되는 전략 알고리즘 부분을 컴파일 타임에서 클래스로 만든뒤 구현체를 주입해 주어야 되지만, 템플릿 콜백 패턴은 런타임 타임에서 익명 클래스를 이용해 동적으로 전략 알고리즘을 주입한다. 용어도 그냥 전략 패턴에서의 컨텍스트(Context)를 템플릿으로 치환한 것일 뿐이며 콜백은 익명 클래스를 만들어진 메서드를 칭하는 것이다.

정리하자면 템플릿 콜백 패턴은 복잡하지만 바뀌지 않는 일정한 패턴을 갖는 작업 흐름이 존재하고 그중 일부분만 자주 바꿔서 사용해야 하는 경우에 적합한 패턴이라고 보면 된다.

콜백(Callback) 이란?

프로그래밍에서 콜백(callback)은 하나의 오브젝트를 다른 오브젝트의 메소드에 매개변수로 넘겨주는 실행 가능한 코드를 말한다. 파라미터로 전달되지만 값을 넘겨주는게 아닌 특정 로직을 담은 일종의 함수를 넘겨서 실행시키기 위해 사용 된다.

즉, callback은 코드가 호출(call)은 되는데 코드를 넘겨준 곳의 뒤(back)에서 실행된다는 것이다. 콜백을 넘겨받는 함수는 이 콜백 함수를 필요에 따라 즉시 실행할 수도 있고, 아니면 나중에 실행할 수도 있다.

자바스크립트의 콜백

자바스크립트를 배운 독자분들이라면 콜백이라는 단어는 질리도록 들어봤을 것이다. 간단하게 함수를 변수에 할당하고 함수의 인자로 넘겨주면 그것이 콜백이다.

// 콜백 함수
const callback = function(num) {
	return ++num;
}

// 콜백을 함수의 매개변수로 넘김
function increaseNum(num, callback) {
	let result = callback(num);
    console.log(result);
}

increaseNum(1, callback); // 2

자바의 콜백

본래 자바의 메소드는 일급 객체가 아니기 때문에 콜백 행위는 불가능 했다. 하지만 자바8에서 등장한 람다함수를 통해 콜백을 구현할 수 있게 되었다.

템플릿 콜백 패턴은 이름만 되게 거창해 보이지 사실 아래 코드 모습과 별반 다르지 않다. 어렵게 생각할 필요가 전혀 없다.

interface IAdd {
    int add(int x, int y);
}
 
public class Main {
    public static void main(String[] args) {
    	int n = result( (x, y) -> x + y ); // 메소드의 매개변수에 람다식을 전달
        System.out.println(n); // 3
    }
    
    public static int result(IAdd lambda) {
    	return lambda.add(1,2);
    }
}

템플릿 콜백 패턴 흐름

콜백은 보통 단일 메소드로 이루어진 인터페이스를 사용한다. (이를 함수형 인터페이스 라고 부른다)

템플릿의 작업 흐름 중 특정 기능을 위해 한 번 호출되는 경우가 일반적이기 때문이다.

만일 하나의 템플릿에서 여러 가지 종류의 전략을 사용해야 한다면 두개 이상의 콜백 오브젝트를 사용 할 수도 있다. (메소드 구현을 여러개 해놓은 익명 클래스)

클래스 구성

// 콜백
interface Callback {
    int execute(final int n);
}

// 템플릿
class Template {
    int workflow(Callback cb) {
        System.out.println("Workflow 시작");
        int num = 100;
        int result = cb.execute(num);
        return result;
    }
}

// 클라이언트
public class Client {
    public static void main(String[] args) {
        int x = 100;
        int y = 20;

        Template t = new Template();
        int result = t.workflow(new Callback() {
            @Override
            public int execute(final int n) {
                return n * n;
            }
        });
        System.out.println(result); // 100 * 100 = 10000
    }
}

클래스 흐름

클라이언트의 역할은 템플릿 안에서 실행될 로직을 담은 콜백(Callback) 객체를 만들고, 콜백이 참조할 정보를 제공한다.
만들어진 콜백은 클라이언트가 템플릿의 메소드를 호출할 때 파라미터로 전달된다.
템플릿은 정해진 흐름을 따라 작업(Workflow)을 시작한다.
내부에서 생성한 참조 정보(변수)를 생성한다.
콜백 오브젝트의 메소드 호출하면서 입력값으로 참조 정보(변수)를 전달한다.
콜백은 클라이언트 메소드에 있는 정보와 템플릿이 제공한 참조정보를 이용하여
메소드 작업을 수행한다.
작업 수행한 후 그 결과값을 다시 템플릿에 반환한다.
템플릿은 콜백이 돌려준 정보를 사용해서 작업(Workflow)을 마저 수행한다.
작업이 마무리되면,
최종 결과에 따라 클라이언트에 다시 반환한다.

템플릿 콜백 패턴 특징

전략 패턴과 스프링의 의존성 주입(DI)의 장점을 익명 내부 클래스 사용 전략과 결합해 독특하게 활용되는 패턴

패턴 장점

전략패턴은 따로 전략 알고리즘을 정해놓은 별도의 전략 클래스가 필요했지만, 템플릿-콜백 패턴은 별도의 전략 클래스 없이, 전략을 사용하는 메소드에 매개변수값으로 전략 로직을 넘겨 실행하기 때문에 전략 객체를 일일히 만들 필요가 없다.
외부에서 어떤 전략을 사용하는지 감추고 중요한 부분에 집중할 수 있다.

패턴 단점

스프링 클라이언트에서 DI를 사용하지 않게 되면, Bean으로 등록되지 않아 싱글톤 객체가 되지 않게 된다.
인터페이스를 사용하지만 실제 사용할 클래스를 직접 선언하기 때문에 결합도가 증가하게 된다. 다만, 그렇다고 해서 무리하게 결합도를 낮추는 행위를 할 필요는 없다.

전략 패턴 → 템플릿 콜백 패턴 변환 예제

기존 전략 패턴 코드

간단하게 사칙 연산을 전략으로 취급하여 구성한 예제 코드이다.

사직 연산을 전략 객체로 구현한 OperationStrategy 군과 이를 사용하는 OperationContext 객체가 있다.

interface OperationStrategy {
    // (int x, int y) -> int
    int calculate(int x, int y);
}

class Plus implements OperationStrategy {
    public int calculate(int x, int y) {
        return x + y;
    }
}

class Sub implements OperationStrategy {
    public int calculate(int x, int y) {
        return x - y;
    }
}

class Multi implements OperationStrategy {
    public int calculate(int x, int y) {
        return x * y;
    }
}

class Divide implements OperationStrategy {
    public int calculate(int x, int y) {
        return x / y;
    }
}

class OperationContext {
    OperationStrategy cal;

    void setOpertaion(OperationStrategy cal) {
        this.cal = cal;
    }
    int calculate(int x, int y) {
    	System.out.println("연산 시작");
        int result = cal.calculate(x, y);
        System.out.println("연산 종료");
        return result;
    }
}

public class Client {
    public static void main(String[] args) {
        int x = 100;
        int y = 30;

        OperationContext cxt = new OperationContext();

        cxt.setOpertaion(new Plus());
        int result = cxt.calculate(x, y);
        System.out.println(result); // 130

        cxt.setOpertaion(new Sub());
        result = cxt.calculate(x, y);
        System.out.println(result); // 70

        cxt.setOpertaion(new Multi());
        result = cxt.calculate(x, y);
        System.out.println(result); // 3000

        cxt.setOpertaion(new Divide());
        result = cxt.calculate(x, y);
        System.out.println(result); // 3
    }
}

템플릿 콜백 패턴 코드

간단한 전략 알고리즘일 경우 굳이 전략 팩토리 객체를 정의하여 코드 라인수만 차지할 필요가 전혀 없다.

템플릿 콜백 패턴으로 변환해주면, 클라이언트에서 바로 익명 클래스 혹은 람다함수로 알고리즘 로직 코드를 정의한뒤 매개변수로 주입만 시켜주면 된다.

Context가 템플릿 역할
Strategy 부분이 콜백(Callback)

interface OperationStrategy {
    // (int x, int y) -> int
    int calculate(int x, int y);
}

// Template
class OperationTemplate {
    int calculate(int x, int y, OperationStrategy cal) {
    	System.out.println("연산 시작");
        int result = cal.calculate(x, y);
        System.out.println("연산 종료");
        return result;
    }
}

public class Client {
    public static void main(String[] args) {
        int x = 100;
        int y = 30;

        OperationTemplate cxt = new OperationTemplate();

        int result = cxt.calculate(x, y, new OperationStrategy() {
        	// callback
            @Override
            public int calculate(int x, int y) {
                return x + y;
            }
        });
        System.out.println(result); // 130

        result = cxt.calculate(x, y, new OperationStrategy() {
        	// callback
            @Override
            public int calculate(int x, int y) {
                return x - y;
            }
        });
        System.out.println(result); // 70

        result = cxt.calculate(x, y, new OperationStrategy() {
        	// callback
            @Override
            public int calculate(int x, int y) {
                return x * y;
            }
        });
        System.out.println(result); // 3000

        result = cxt.calculate(x, y, new OperationStrategy() {
        	// callback
            @Override
            public int calculate(int x, int y) {
                return x / y;
            }
        });
        System.out.println(result); // 3
    }
}

중복 코드 제거하기

위의 클라이언트(main 메소드)에서 전략을 주입하는 부분을 자세히 보면 무언가 반복적으로 익명 클래스를 정의해 주입하는 모습이 보인다. 이러한 부분도 결국 쓸데없는 코드 중복이기 마련이다.

다만, 이 부분은 템플릿 콜백 패턴을 사용하는데 좀 더 최적화를 위해 리팩토링(Refactoring)을 진행할 수도 있다는 예시이지, 반드시 이행할 필요는 없으며, 전략에 따라 선택적으로 이행하면 된다.

아래 코드 역시 명답은 아니며 다양한 전략에 따라 얼마든지 변화될 수 있다는 점은 숙지하자.

class OperationContext {

    int calculate(int x, String operation, int y) {
        System.out.println("연산 시작");
        int result = execute(operation).calculate(x, y);
        System.out.println("연산 종료");
        return result;
    }

    // 익명 클래스를 Template 클래스 내에 아예 정의함으로써 클라이언트의 전략 주입 중복 코드를 줄임
    private OperationStrategy execute(final String oper) {

        return new OperationStrategy() {
            public int calculate(int x, int y) {
                int result = 0;
                switch(oper) {
                    case "+" : result = x + y; break;
                    case "-" : result = x - y; break;
                    case "*" : result = x * y; break;
                    case "/" : result = x / y; break;
                }
                return result;
            }
        };
    }
}

public class Client {
    public static void main(String[] args) {
        int x = 100;
        int y = 20;

        OperationContext cxt = new OperationContext();

        int result = cxt.calculate(x, "+", y);
        System.out.println(result); // 120

        result = cxt.calculate(x, "-", y);
        System.out.println(result); // 80

        result = cxt.calculate(x, "*", y);
        System.out.println(result); // 2000

        result = cxt.calculate(x, "/", y);
        System.out.println(result); // 5
    }
}

람다로 변환하기

혹은 함수형 인터페이스 구성으로도 처리되는 간단한 전략 알고리즘이라면, 람다표현식을 통해 코드를 획기적으로 짧게 줄일수 있다.

public class Client {
    public static void main(String[] args) {
        int x = 100;
        int y = 30;

        OperationContext cxt = new OperationContext();

        int result = cxt.calculate(x, y, (x1, y1) -> x1 + y1);
        System.out.println(result); // 130

        result = cxt.calculate(x, y, (x1, y1) -> x1 - y1);
        System.out.println(result); // 70

        result = cxt.calculate(x, y, (x1, y1) -> x1 * y1);
        System.out.println(result); // 3000

        result = cxt.calculate(x, y, (x1, y1) -> x1 / y1);
        System.out.println(result); // 3
    }
}

템플릿 메서드 패턴 → 템플릿 콜백 패턴 변환 예제

사실 전략 패턴과 템플릿 메서드 패턴은 서로 연관은 없다. 다만 전략 알고리즘을 개별 클래스로 정의하고 때에 따라 주입한다는 관점에서 비슷하기 때문에 이 예제를 넣었다.

템플릿 메서드의 전략 알고리즘 부분은 추상 메소드로서 서브 클래스가 상속하여 개별로 정의하는데, 상속(Inheritance)는 객체 지향 프로그래밍에서 지양해야 할 부분이기 때문에 따로 전략 패턴으로 재구성을 하거나, 아니면 콜백을 이용해 상속 대신 위임으로 처리 할 수 있다.

기존 템플릿 메서드 패턴 코드

예를 들자면 위의 전략 패턴 예제와 같은 사칙 연산 예제를 그대로 가져와 템플릿 메서드 패턴으로 표현하자면 아래와 같이 된다.

abstract class OperationTemplate {

    public final void templateMethod(int x, int y) {
        int num1 = 100;
        int num2 = calculate(x, y);
        System.out.println(num1 * num2);
    }

    abstract int calculate(int x, int y);
}

class Plus extends OperationTemplate {

    @Override
    int calculate(int x, int y) {
        return x + y;
    }
}

class Sub extends OperationTemplate {

    @Override
    int calculate(int x, int y) {
        return x - y;
    }
}

class Multi extends OperationTemplate {

    @Override
    int calculate(int x, int y) {
        return x * y;
    }
}

public class Client {
    public static void main(String[] args) {
        int x = 100;
        int y = 20;

        // 1. 템플릿 메서드가 실행할 구현화한 하위 알고리즘 클래스 생성하고 템플릿 실행
        OperationTemplate template = new Plus();
        template.templateMethod(x, y); // 12000

        template = new Sub();
        template.templateMethod(x, y); // 8000

        template = new Multi();
        template.templateMethod(x, y); // 200000
    }
}

추상 메서드인 ~~calculate()~~를 각 서브 클래스들이 오버라이딩하여 재정의하는 형태인데, 이 역시 간단한 전략인 경우 서브 전략 클래스들을 없애고 콜백으로 바꿔버릴 수 있다.

템플릿 콜백 패턴 코드

먼저 인터페이스를 정의하고, 템플릿 메서드의 인자에 인터페이스 매개변수를 추가해주면 된다. 그리고 추상 클래스였던 템플릿 클래스를 일반 클래스로 변환 시킨다.

interface OperationStrategy {
    // (int x, int y) -> int
    int calculate(int x, int y);
}

class OperationTemplate {

    public final void templateMethod(int x, int y, OperationStrategy oper) {
        int num1 = 100;
        int num2 = oper.calculate(x, y);
        System.out.println(num1 * num2);
    }
}

public class Client {
    public static void main(String[] args) {
        int x = 100;
        int y = 20;

        OperationTemplate template = new OperationTemplate();
        
        template.templateMethod(x, y, (x1, y1) -> x1 + y1); // 12000

        template.templateMethod(x, y, (x1, y1) -> x1 - y1); // 8000

        template.templateMethod(x, y, (x1, y1) -> x1 * y1); // 200000
    }
}

그리고 익명 클래스 혹은 람다함수를 인자로 주게되면, 템플릿 메서드 패턴도 따로 서브 클래스를 만들지 않고도 위임을 이용하여 로직이 문제없이 실행되게 된다.

# 참고자료

토비의 스프링3 (이일민)

https://yongdev.tistory.com/142

빌더(Builder) 패턴 - 완벽 마스터하기

인파_ — Thu, 16 Mar 2023 08:06:38 +0900

Builder Pattern

빌더 패턴(Builder Pattern)은 복잡한 객체의 생성 과정과 표현 방법을 분리하여 다양한 구성의 인스턴스를 만드는 생성 패턴이다. 생성자에 들어갈 매개 변수를 메서드로 하나하나 받아들이고 마지막에 통합 빌드해서 객체를 생성하는 방식이다.

이해하기 쉬운 사례로 수제 햄버거를 들 수 있다. 수제 햄버거를 주문할때 빵이나 패티 등 속재료들은 주문하는 사람이 마음대로 결정된다. 어느 사람은 치즈를 빼달라고 할수 있고 어느 사람은 토마토를 빼달라고 할수 있다. 이처럼 선택적 속재료들을 보다 유연하게 받아 다양한 타입의 인스턴스를 생성할수 있어, 클래스의 선택적 매개변수가 많은 상황에서 유용하게 사용된다.

빌더 패턴 탄생 배경

점층적 생성자 패턴

점층적 생성자 패턴(Telescoping Constructor Pattern)은 필수 매개변수와 함께 선택 매개변수를 0개, 1개, 2개 .. 받는 형태로, 우리가 다양한 매개변수를 입력받아 인스턴스를 생성하고 싶을때 사용하던 생성자를 오버로딩 하는 방식이다.

class Hamburger {
    // 필수 매개변수
    private int bun;
    private int patty;

    // 선택 매개변수
    private int cheese;
    private int lettuce;
    private int tomato;
    private int bacon;

    public Hamburger(int bun, int patty, int cheese, int lettuce, int tomato, int bacon) {
        this.bun = bun;
        this.patty = patty;
        this.cheese = cheese;
        this.lettuce = lettuce;
        this.tomato = tomato;
        this.bacon = bacon;
    }

    public Hamburger(int bun, int patty, int cheese, int lettuce, int tomato) {
        this.bun = bun;
        this.patty = patty;
        this.cheese = cheese;
        this.lettuce = lettuce;
        this.tomato = tomato;
    }
    

    public Hamburger(int bun, int patty, int cheese, int lettuce) {
        this.bun = bun;
        this.patty = patty;
        this.cheese = cheese;
        this.lettuce = lettuce;
    }

    public Hamburger(int bun, int patty, int cheese) {
        this.bun = bun;
        this.patty = patty;
        this.cheese = cheese;
    }

    ...
}

public static void main(String[] args) {
    // 모든 재료가 있는 햄버거
    Hamburger hamburger1 = new Hamburger(2, 1, 2, 4, 6, 8);

    // 빵과 패티 치즈만 있는 햄버거
    Hamburger hamburger2 = new Hamburger(2, 1, 1);

    // 빵과 패티 베이컨만 있는 햄버거
    Hamburger hamburger3 = new Hamburger(2, 0, 0, 0, 0, 6);
}

하지만 이러한 방식은 클래스 인스턴스 필드들이 많으면 많을 수록 생성자에 들어갈 인자의 수가 늘어나 몇번째 인자가 어떤 필드였는지 햇갈릴 경우가 생기게 된다. 만일 여러 종류의 햄버거를 생성하기 위해 Hamburger 생성자의 몇번째 인수가 양상추의 갯수인지 토마토의 갯수인지 파악할 필요가 있다.

또한 매개변수 특성상 순서를 따라야 하기 때문에 위의 '빵과 베이컨만 있는 햄버거'를 원할경우 억지로 파라미터에 0을 전달해야 된다. 생성자로만으로는 필드를 선택적으로 생략할 수 있는 방법이 없기 때문이다.

그리고 무엇보다 타입이 다양할 수록 생성자 메서드 수가 기하급수적으로 늘어나 가독성이나 유지보수 측면에서 좋지 않다.

자바 빈(Java Beans) 패턴

이러한 단점을 보완하기 위해 Setter 메소드를 사용한 자바 빈(Bean) 패턴이 고안 되었다. 매개변수가 없는 생성자로 객체 생성후 Setter 메소드를 이용해 클래스 필드의 초깃값을 설정하는 방식이다.

class Hamburger {
    // 필수 매개변수
    private int bun;
    private int patty;

    // 선택 매개변수
    private int cheese;
    private int lettuce;
    private int tomato;
    private int bacon;
    
    public Hamburger() {}

    public void setBun(int bun) {
        this.bun = bun;
    }

    public void setPatty(int patty) {
        this.patty = patty;
    }

    public void setCheese(int cheese) {
        this.cheese = cheese;
    }

    public void setLettuce(int lettuce) {
        this.lettuce = lettuce;
    }

    public void setTomato(int tomato) {
        this.tomato = tomato;
    }

    public void setBacon(int bacon) {
        this.bacon = bacon;
    }
}

public static void main(String[] args) {
    // 모든 재료가 있는 햄버거
    Hamburger hamburger1 = new Hamburger();
    hamburger1.setBun(2);
    hamburger1.setPatty(1);
    hamburger1.setCheese(2);
    hamburger1.setLettuce(4);
    hamburger1.setTomato(6);
    hamburger1.setBacon(8);

    // 빵과 패티 치즈만 있는 햄버거
    Hamburger hamburger2 = new Hamburger();
    hamburger2.setBun(2);
    hamburger2.setPatty(1);
    hamburger2.setCheese(2);

    // 빵과 패티 베이컨만 있는 햄버거
    Hamburger hamburger3 = new Hamburger();
    hamburger3.setBun(2);
    hamburger2.setPatty(1);
    hamburger3.setBacon(8);
}

기존 생성자 오버로딩에서 나타났던 가독성 문제점이 사라지고 선택적인 파라미터에 대해 해당되는 Setter 메서드를 호출함으로써 유연적으로 객체 생성이 가능해졌다. 하지만 이러한 방식은 객체 생성 시점에 모든 값들을 주입 하지 않아 일관성(consistency) 문제와 불변성(immutable) 문제가 나타나게 된다.

1) 일관성 문제

필수 매개변수란 객체가 초기화될때 반드시 설정되어야 하는 값이다. 하지만 개발자가 깜빡하고 ~~setBun()~~ 이나 ~~setPatty()~~ 메서드를 호출하지 않았다면 이 객체는 일관성이 무너진 상태가 된다. 즉, 객체가 유효하지 않은 것이다. 만일 다른곳에서 햄버거 인스턴스를 사용하게 된다면 런타임 예외가 발생할 수도 있다.

이는 객체를 생성하는 부분과 값을 설정하는 부분이 물리적으로 떨어져 있어서 발생하는 문제점이다. 물론 이는 어느정도 생성자(Constructor)와 결합하여 극복은 할 수 있다. 하지만 다음에 소개할 불변성의 문제 때문에 자바 빈즈 패턴은 지양해야 한다.

2) 불변성 문제

자바 빈즈 패턴의 Setter 메서드는 객체를 처음 생성할때 필드값을 설정하기 위해 존재하는 메서드이다. 하지만 객체를 생성했음에도 여전히 외부적으로 Setter 메소드를 노출하고 있으므로, 협업 과정에서 언제 어디서 누군가 Setter 메서드를 호출해 함부로 객체를 조작할수 있게 된다. 이것을 불변함을 보장할 수 없다고 얘기한다.

마치 완성된 햄버거에 중간에 치즈를 교체한다고 햄버거를 막 분리하는 것과 같은 이치이다 (입맛 떨어지게)

빌더(Builder) 패턴

빌더 패턴은 이러한 문제들을 해결하기 위해 별도의 Builder 클래스를 만들어 메소드를 통해 step-by-step 으로 값을 입력받은 후에 최종적으로 ~~build()~~ 메소드로 하나의 인스턴스를 생성하여 리턴하는 패턴이다.

빌더 패턴 사용법을 잠시 살펴보면, StudentBuilder 빌더 클래스의 메서드를 체이닝(Chaining) 형태로 호출함으로써 자연스럽게 인스턴스를 구성하고 마지막에 ~~build()~~ 메서드를 통해 최종적으로 객체를 생성하도록 되어있음을 볼 수 있다.

public static void main(String[] args) {

    // 생성자 방식
    Hamburger hamburger = new Hamburger(2, 3, 0, 3, 0, 0);

    // 빌더 방식
    Hamburger hamburger = new Hamburger.Builder(10)
        .bun(2)
        .patty(3)
        .lettuce(3)
        .build();
}

빌더 패턴을 이용하면 더이상 생성자 오버로딩 열거를 하지 않아도 되며, 데이터의 순서에 상관없이 객체를 만들어내 생성자 인자 순서를 파악할 필요도 없고 잘못된 값을 넣는 실수도 하지 않게 된다. 점층적 생성자 패턴과 자바빈즈 패턴 두 가지의 장점만을 취하였다고 볼 수 있다.

빌더 패턴 구조

빌더 패턴 구현 자체는 난이도가 어렵지 않으니 빠르고 쉽게 구성이 가능하다.

예를들어 다음과 같은 Student 클래스에 대한 객체 생성만을 담당하는 별도의 빌더 클래스를 만들려고 한다.

class Student {
    private int id;
    private String name = "아무개";
    private String grade = "freshman";
    private String phoneNumber = "010-0000-0000";

    public Student(int id, String name, String grade, String phoneNumber) {
        this.id = id;
        this.name = name;
        this.grade = grade;
        this.phoneNumber = phoneNumber;
    }
    
    @Override
    public String toString() {
        return "Student { " +
                "id='" + id + '\'' +
                ", name=" + name +
                ", grade=" + grade +
                ", phoneNumber=" + phoneNumber +
                " }";
    }
}

빌더 클래스 구현하기

먼저 Builder 클래스를 만들고 필드 멤버 구성을 만들고자 하는 Student 클래스 멤버 구성과 똑같이 구성한다.

class StudentBuilder {
    private int id;
    private String name;
    private String grade;
    private String phoneNumber;
    
}

그리고 각 맴버에대한 Setter 메서드를 구현해준다. 이때 가독성을 좋게 하면서도 기존 Setter와의 다른 특성을 가지고 있는 점을 알리기 위해서, set 단어는 빼주고 심플하게 멤버이름으로만 메서드명을 지어준다.

class StudentBuilder {
    private int id;
    private String name;
    private String grade;
    private String phoneNumber;

    public StudentBuilder id(int id) {
        this.id = id;
        return this;
    }

    public StudentBuilder name(String name) {
        this.name = name;
        return this;
    }

    public StudentBuilder grade(String grade) {
        this.grade = grade;
        return this;
    }

    public StudentBuilder phoneNumber(String phoneNumber) {
        this.phoneNumber = phoneNumber;
        return this;
    }
}

여기서 주목할 부분은 각 Setter 함수 마지막 반환 구문인 ~~return this~~ 부분이다. 여기서 ~~this~~란 StudentBuilder 객체 자신을 말한다. 즉, 빌더 객체 자신을 리턴함으로써 메서드 호출 후 연속적으로 빌더 메서드들을 체이닝(Chaining) 하여 호출할 수 있게 된다. ex) ~~new StudentBuilder().id(값).name(값)~~

마지막으로 빌더의 목표였던 최종 Student 객체를 만들어주는 build 메서드를 구성해준다. 빌더 클래스의 필드들을 Student 생성자의 인자에 넣어줌으로써 멤버 구성이 완료된 Student 인스턴스를 얻게 되는 것이다.

class StudentBuilder {
    private int id;
    private String name;
    private String grade;
    private String phoneNumber;

    public StudentBuilder id(int id) { ... }

    public StudentBuilder name(String name) { ... }

    public StudentBuilder grade(String grade) { ... }

    public StudentBuilder phoneNumber(String phoneNumber) { ... }

    public Student build() {
        return new Student(id, name, grade, phoneNumber); // Student 생성자 호출
    }
}

빌더 클래스 실행하기

이렇게 구성한 빌더 객체를 실행하면 아래와 같은 성질의 코드가 구현되게 된다.

public static void main(String[] args) {

    Student student = new StudentBuilder()
                .id(2016120091)
                .name("임꺽정")
                .grade("Senior")
                .phoneNumber("010-5555-5555")
                .build();

    System.out.println(student);
}

빌더 패턴 네이밍 형식

빌더 패턴의 멤버 설정 메서드 네이밍 방식에는 대표적으로 3가지 정도 존재한다.

멤버이름()
set멤버이름()
with멤버이름()

Student student = new StudentBuilder(2016120091)
        .name("홍길동")
        .grade("freshman")
        .phoneNumber("010-5555-5555")
        .build();

Student student = new StudentBuilder(2016120091)
        .setName("홍길동")
        .setGrade("freshman")
        .setPhoneNumber("010-5555-5555")
        .build();

Student student = new StudentBuilder(2016120091)
        .withName("홍길동")
        .withGrade("freshman")
        .withPhoneNumber("010-5555-5555")
        .build();

이중 그냥 멤버이름으로만 메서드명을 짓는 첫번째 네이밍 방식이 추천되어진다.

두번째 네이밍 방식은 정통적인 자바(Java) 스러운 네이밍 형식인데 일반 Setter 메소드와 햇깔릴 소지가 있다.

세번째는 Setter와 구분키 위해 'with' 라는 키워드를 사용한것이며, 빌더 지연 생성 방식에서 미리 빌더를 설정할때 쓰이기도 한다.

Builder 패턴 장단점 총정리

빌더 패턴 장점

1. 객체 생성 과정을 일관된 프로세스로 표현

생성자 방식으로 객체를 생성하는 경우는 매개변수가 많아질수록 가독성이 급격하게 떨어진다. 클래스 변수가 4개 이상만 되어도 각 인자 순서 마다 이 값이 어떤 멤버에 해당되는지 바로 파악이 힘들다.

반면 다음과 같이 빌더 패턴을 적용하면 직관적으로 어떤 데이터에 어떤 값이 설정되는지 한눈에 파악할 수 있게 된다. 특히 연속된 동일 타입의 매개 변수를 많이 설정할 경우에 발생할 수 있는 설정 오류와 같은 실수를 방지할 수 있다.

// 생성자 방식
Student student1 = new Student(2016120091, "홍길동", "freshman", "010-5555-5555");

// 빌더 방식
Student student2 = new StudentBuilder()
            .id(2016120091)
            .name("임꺽정")
            .grade("Senior")
            .phoneNumber("010-5555-5555")
            .build();

다만 빌더 패턴이 탄생하게된 옛 시대와 달리, 요즘에는 인텔리제이나 이클립스 같은 왠만한 IDE에선 아래와 같이 생성자 매개변수에 대한 미리보기 힌트 기능을 제공해주기 때문에 이 부분은 요즘 트렌드에는 맞지 않을 수도 있다.

2. 디폴트 매개변수 생략을 간접적으로 지원

본래 디폴트 매개변수라는 건 인자 값을 설정해줘도 되고 설정 안하고 생략해도 되는것을 말한다. 그런데 파이썬이나 자바스크립트와 달리 자바 언어에선 기본적으로 메서드에 대한 디폴트 매개변수를 지원하지 않는다.

따라서 디폴트 매개변수를 구현하기 위해선 클래스 필드 변수에 초깃값을 미리 세팅하고, 초깃값이 세팅된 필드 인자를 제외시킨 생성자를 따로 구현하는 식으로 설계해야 한다. 하지만 이는 결국 지나친 생성자 오버로딩 열거를 통한 본래의 문제점을 회귀한 꼴이 된다.

class Student {
    private int id;
    private String name;
    private String grade = "freshman"; // 디폴트 매개변수 역할
    private String phoneNumber;

    public Student(int id, String name, String grade, String phoneNumber) {
        ...
    }
	
    // 디폴트 매개변수를 제외한 인자들을 받는 생성자 오버로딩
    public Student(int id, String name, String phoneNumber) {
        ...
    }

    @Override
    public String toString() {
        return "Student { " +
                "id='" + id + '\'' +
                ", name=" + name +
                ", grade=" + grade +
                ", phoneNumber=" + phoneNumber +
                " }";
    }
}

빌더 패턴에서도 디폴트 매개변수를 구현하는 방법은 똑같다. 다만 빌더라는 객체 생성 전용 클래스를 경유하여 이용함으로써 디폴트 매개변수가 설정된 필드를 설정하는 메서드를 호출하지 않는 방식으로 마치 디폴트 매개변수를 생략하고 호출하는 효과를 간접적으로 구현할수 있게 된다.

class StudentBuilder {
    private int id;
    private String name;
    private String grade = "freshman"; // 디폴트 매개변수 역할
    private String phoneNumber;

    ...
}

// 디폴트 필드인 grade를 제외하고 빌더 구성 및 인스턴스화
Student student1 = new StudentBuilder(2016120091)
        .name("홍길동")
        .phoneNumber("010-5555-5555")
        .build();

System.out.println(student1);

3. 필수 멤버와 선택적 멤버를 분리 가능

객체 인스턴스는 목적에 따라 초기화가 필수인 멤버 변수가 있고 선택적인 멤버 변수가 있을 수 있다.

만일 Student 클래스의 id 필드가 인스턴스화 할때 반드시 필수적으로 값을 지정해 주어야 하는 필수 멤버 변수라고 가정해보자. 이를 기존 생성자 방식으로 구현하려면 초기화가 필수인 멤버 변수만을 위한 생성자를 정의하고 선택적인 멤버 변수에 대응하는 생성자를 오버로딩을 통해 열거하거나, 혹은 전체 멤버를 인자로 받는 생성자만을 선언하고 매개변수에 null을 받는식으로 구성하여야 한다.

class Student {
    // 초기화 필수 멤버
    private int id;

    // 초기화 선택적 멤버
    private String name;
    private String grade;
    private String phoneNumber;

    public Student(int id, String name, String grade, String phoneNumber) {
        this.id = id;
        this.name = name;
        this.grade = grade;
        this.phoneNumber = phoneNumber;
    }
}

Student student = new Student(2010234455, null, null, null);

이는 한눈에 봐도 별로 좋지 않은 방법임을 알수 있을 것이다.

따라서 빌더 클래스를 통해 초기화가 필수인 멤버는 빌더의 생성자로 받게 하여 필수 멤버를 설정해주어야 빌더 객체가 생성되도록 유도하고, 선택적인 멤버는 빌더의 메서드로 받도록 하면, 사용자로 하여금 필수 멤버와 선택 멤버를 구분하여 객체 생성을 유도할 수 있다.

class StudentBuilder {
    // 초기화 필수 멤버
    private int id;

    // 초기화 선택적 멤버
    private String name;
    private String grade;
    private String phoneNumber;

    // 필수 멤버는 빌더의 생성자를 통해 설정
    public StudentBuilder(int id) {
        this.id = id;
    }

    // 나머지 선택 멤버는 메서드로 설정
    public StudentBuilder name(String name) {
        this.name = name;
        return this;
    }

    public StudentBuilder grade(String grade) {
        this.grade = grade;
        return this;
    }

    public StudentBuilder phoneNumber(String phoneNumber) {
        this.phoneNumber = phoneNumber;
        return this;
    }

    public Student build() {
        return new Student(id, name, grade, phoneNumber);
    }
}

Student student1 = 
        new StudentBuilder(2016120091) // 필수 멤버
        .name("홍길동") // 선택 멤버
        .build();

Student student2 = 
        new StudentBuilder(2016120091) // 필수 멤버
        .name("임꺽정") // 선택 멤버
        .grade("freshman") // 선택 멤버
        .build();

Student student3 = 
        new StudentBuilder(2016120091) // 필수 멤버
        .name("주몽") // 선택 멤버
        .grade("Senior") // 선택 멤버
        .phoneNumber("010-5555-5555") // 선택 멤버
        .build();

4. 객체 생성 단계를 지연할 수 있음

객체 생성을 단계별로 구성하거나 구성 단계를 지연하거나 재귀적으로 생성을 처리 할수 있다. 즉, 빌더를 재사용 함으로써 객체 생성을 주도적으로 지연할 수 있는 것이다.

// 1. 빌더 클래스 전용 리스트 생성
List<StudentBuilder> builders = new ArrayList<>();

// 2. 객체를 최종 생성 하지말고 초깃값만 세팅한 빌더만 생성
builders.add(
    new StudentBuilder(2016120091)
    .name("홍길동")
);

builders.add(
    new StudentBuilder(2016120092)
    .name("임꺽정")
    .grade("senior")
);

builders.add(
    new StudentBuilder(2016120093)
    .name("박혁거세")
    .grade("sophomore")
    .phoneNumber("010-5555-5555")
);

// 3. 나중에 빌더 리스트를 순회하여 최종 객체 생성을 주도
for(StudentBuilder b : builders) {
    Student student = b.build();
    System.out.println(student);
}

6. 초기화 검증을 멤버별로 분리

만일 생성자로 부터 멤버값을 받는 형태라면, 각 생성자 매개변수에 대한 검증 로직을 생성자 메소드 마다 복잡하게 구현하여야 한다. 이는 생성자의 크기가 비대해지게 되는 결과를 낳게 된다.

class Student {
	...

	// 각 매개변수에 대한 검증을 하나의 생성자 모두 처리하고 있다
    public Student(int id, String name, String grade, String phoneNumber) {
        if (!grade.equals("freshman") && !grade.equals("sophomore") && !grade.equals("junior") && !grade.equals("senior")) {
            throw new IllegalArgumentException(grade);
        }

        if (!phoneNumber.startsWith("010")) {
            throw new IllegalArgumentException(phoneNumber);
        }

        this.id = id;
        this.name = name;
        this.grade = grade;
        this.phoneNumber = phoneNumber;
    }
}

빌더를 이용하면 생성될 객체의 멤버 변수의 초기화와 검증을 각각의 멤버별로 분리해서 작성할 수 있다. 빌더의 각각의멤버 설정 메서드에서 검증 과정을 분담함으로써 유지 보수를 용이하게 하는 것이다.

class StudentBuilder {
	...

    public StudentBuilder(int id) {
        this.id = id;
    }

    public StudentBuilder name(String name) {
        this.name = name;
        return this;
    }

    public StudentBuilder grade(String grade) {
        if (!grade.equals("freshman") && !grade.equals("sophomore") && !grade.equals("junior") && !grade.equals("senior")) {
            throw new IllegalArgumentException(grade);
        }
        this.grade = grade;
        return this;
    }

    public StudentBuilder phoneNumber(String phoneNumber) {
        if (!phoneNumber.startsWith("010")) {
            throw new IllegalArgumentException(phoneNumber);
        }
        this.phoneNumber = phoneNumber;
        return this;
    }

    public Student build() {
        return new Student(id, name, grade, phoneNumber);
    }
}

물론 이러한 형식은 흔히 Getter & Setter 형식에서도 많이 이용되는 패턴이기도 하다. 하지만 어느 클래스에 Setter 메서드를 구현한다는 말은 객체 멤버의 변경 가능성을 열어둔것과 같아 불변성 문제가 터지게 된다. (바로 다음에 설명)

7. 멤버에 대한 변경 가능성 최소화를 추구

많은 개발자들이 자바 프로그래밍을 하면서 멤버에 값을 할당할때 흔히 사용하는 것이 Setter 메서드인데, 그중 클래스 맴버 초기화를 Setter을 통해 구성하는 것은 매우 좋지 않은 방법이다. 즉, 이 부분은 위의 빌더 패턴 탄생 배경에서 다루었던 Java Beans Pattern인 Setter 메서드를 통해 멤버 초기화를 하지 말아야 하는 이유에 대한 좀 더 고수준 적인 내용이다.

일반적으로 프로그램을 개발하는데 있어 다른 사람과 협업할때 가장 중요시되는 점 중 하나가 바로 불변(immutalbe) 객체이다. 불변 객체란 객체 생성 이후 내부의 상태가 변하지 않는 객체이다. 불변 객체는 오로지 읽기(get) 메소드만을 제공하며 쓰기(set)는 제공하지 않는다. 대표적으로 자바에서 final 키워드를 붙인 변수가 바로 불변이다.

현업에서 불변 객체를 이용해 개발해야 하는 이유로는 다음과 같다.

불변 객체는 Thread-Safe 하여 동기화를 고려하지 않아도 된다
만일 가변 객체를 통해 작업을 하는 도중 예외(Exception)가 발생하면 해당 객체가 불안정한 상태에 빠질 수 있어 또 다른 에러를 유발할 수 있는 위험성이 있기 때문이다.
불변 객체로 구성하면 다른 사람이 개발한 함수를 위험없이 이용을 보장할 수 있어 협업에도 유지보수에도 유용하다.

따라서 클래스들은 가변적 이여야 하는 매우 타당한 이유가 있지 않는 한 반드시 불변으로 만들어야 한다. 만약 클래스를 불변으로 만드는 것이 불가능하다면 가능한 변경 가능성을 최소화해야 한다.

예를들어 경우에 따라 변수에 final 키워드를 붙일수 없는 상황이 생길 수도 있다. 이때는 Setter 메서드 자체를 구현하지 않음으로서 불변 객체를 간접적으로 구성이 가능하다.그러면 결국은 돌도 돌아 생성자를 이용하라는 것인데 역시나 지나친 생성자 오버로딩 문제가 발생하게 된다. 그래서 연구된것이 빌더 클래스이다.

즉, 최종 정리하자면 빌더 패턴은 생성자 없이 어느 객체에 대해 '변경 가능성을 최소화' 를 추구하여 불변성을 갖게 해주게 되는 것이다.

빌더 패턴 단점

1. 코드 복잡성 증가

우선 빌더 패턴을 적용하려면 N개의 클래스에 대해 N개의 새로운 빌더 클래스를 만들어야 해서, 클래수 수가 기하급수적으로 늘어나 관리해야 할 클래스가 많아지고 구조가 복잡해질 수 있다. 또한 선택적 매개변수를 많이 받는 객체를 생성하기 위해서는 먼저 빌더 클래스부터 정의해야한다. 다만 이부분은 여느 디자인 패턴이 가지는 단점이기도 하다.

2. 생성자 보다는 성능은 떨어진다.

매번 메서드를 호출하여 빌더를 거쳐 인스턴스화 하기 때문에 어쩌면 당연한 말일지도 모른다. 비록 생성 비용 자체는 크지는 않지만, 어플리케이션의 성능을 극으로 중요시되는 상황이라면 문제가 될수 있다.

3. 지나친 빌더 남용은 금지

클래스의 필드의 개수가 4개 보다 적고, 필드의 변경 가능성이 없는 경우라면 차라리 생성자나 정적 팩토리 메소드를 이용하는 것이 더 좋을 수 있다. 빌더 패턴의 코드가 다소 장황하기 때문이다. 따라서 클래스 필드의 갯수와 필드 변경 가능성을 중점으로 보고 패턴을 적용 유무를 가려야한다.

다만 API 는 시간이 지날수록 많은 매개변수를 갖는 경향이 있기 때문에 애초에 빌더 패턴으로 시작하는 편이 나을 때가 많다고 말하는 경향도 있다.

Builder 디자인 패턴 종류

빌더 패턴에는 여타 디자인 패턴과는 다르게 두가지 디자인 종류가 존재한다. GOF의 디자인 패턴에서 소개하는 빌더 패턴과 이펙티브 자바(Effective Java) 책에서 소개하는 빌더 패턴 구조가 서로 다르기 때문이다.

이펙티브 자바의 빌더 패턴 : 생성시 지정해야 할 인자가 많을때 사용. 객체의 일관성 불변성이 목적.
GoF의 빌더 패턴 : 객체의 생성 단계 순서를 결정해두고 각 단계를 다양하게 구현하고 싶을때 사용.

일단 두 책의 관점이 다르고 GoF의 디자인 패턴은 1994년에 발매되었고 이펙티브 자바가 2001년에 나중에 나왔기 때문이라고 생각 된다.

심플 빌더 패턴 (Effective Java)

보통 개발자들이 빌더 패턴을 말할 때 정의되는 것이 이펙티브 자바에서 소개한 빌더 패턴이다. GOF 빌더 패턴과 구분하기 위해 심플 빌더 패턴(Simple Builder Pattern) 이라고도 불리운다.

심플 빌더 패턴은 생성자가 많을 경우 또는 변경 불가능한 불변 객체가 필요한 경우 코드의 가독성과 일관성, 불변성을 유지하는 것에 중점을 둔다. 심플 빌더 패턴은 위에서 우리가 배운 빌더 패턴과 차이가 거의 없다. 다만 빌더(Builder) 클래스가 구현할 클래스의 정적 내부 클래스(Static Inner Class)로 구현된다는 점이 다르다.

빌더 클래스가 static inner class로 구현되는 이유로는 다음과 같다.

첫 번째, 하나의 빌더 클래스는 하나의 대상 객체 생성만을 위해 사용된다. 그래서 두 클래스를 물리적으로 그룹핑함으로써 두 클래스간의 관계에 대한 파악을 쉽게 할 수 있다.

두 번째, 대상 객체는 오로지 빌더 객체에 의해 초기화 된다. 즉, 생성자를 외부에 노출시키면 안되기 때문에 생성자를 private로 하고, 내부 빌더 클래스에서 private 생성자를 호출함으로써 오로지 빌더 객체에 의해 초기화 되도록 설계 할 수 있다.

세 번째, inner class를 쓰면 좋은건 알겠는데 왜 하필 static 으로 선언해주어야 하냐면, 정적 내부 클래스는 외부 클래스의 인스턴스 없이도 생성할 수 있는데, 만일 일반 내부 클래스로 구성한다면 내부 클래스를 생성하기도 전에 외부 클래스를 인스턴스화 해야 한다. 빌더가 최종적으로 생성할 클래스의 인스턴스를 먼저 생성해야 한다면 모순이 생기기 때문이다.

네 번째, 메모리 누수 문제 때문에 static으로 내부 클래스를 정의해주어야 한다. 자세한건 다음 포스팅을 참고하길 바란다.

Simple 빌더 패턴 구현하기

빌더 클래스를 Static Nested Class로 정의한다.
빌더를 통해 인스턴스화 하기 때문에 대상 객체 생성자는 private로 정의한다.
빌더 클래스의 생성자는 public으로 하며, 필수 파라미터에 대해 생성자의 파라미터로 받는다.
선택적 파라미터에 대해서는 메소드로 제공한다. 이때 메소드의 반환값은 빌더 객체 자신(this) 이어야 한다.
마지막 단계로 최종 객체를 생성하는 ~~build()~~ 메소드를 정의하여 클라이언트에게 최종 생성된 결과물을 제공한다.
이때 생성자의 인수로 빌더 인스턴스 자기자신을 전달하고, 대상 객체 생성자에서 빌더 인스턴스의 필드를 각각 대입하여 최종 완성본이 나오게 된다.

class Person {
    // final 키워드로 필드들을 불변 객체로 만든다.
    private final String name;
    private final String age;
    private final String gender;
    private final String job;
    private final String birthday;
    private final String address;

    // 정적 내부 빌더 클래스
    public static class Builder {

        // 필수 파라미터
        private final String name;
        private final String age;

        // 선택 파라미터
        private String gender;
        private String job;
        private String birthday;
        private String address;

        // 필수 파라미터는 빌더 생성자로 받게 한다
        public Builder(String name, String age) {
            this.name = name;
            this.age = age;
        }

        // 선택 파라미터는 각 메서드를 통해 정의한다
        public Builder gender(String gender) {
            this.gender = gender;
            return this;
        }

        public Builder job(String job) {
            this.job = job;
            return this;
        }

        public Builder birthday(String birthday) {
            this.birthday = birthday;
            return this;
        }

        public Builder address(String address) {
            this.address = address;
            return this;
        }

        // 대상 객체의 private 생성자를 호출하여 최종 인스턴스화 한다
        public Person build() {
            return new Person(this); // 빌더 객체 자신을 넘긴다.
        }
    }

    // private 생성자 - 생성자는 외부에서 호출되는것이 아닌 빌더 클래스에서만 호출되기 때문에
    private Person(Builder builder) {
        this.name = builder.name;
        this.age = builder.age;
        this.gender = builder.gender;
        this.job = builder.gender;
        this.birthday = builder.birthday;
        this.address = builder.address;
    }

    @Override
    public String toString() {
        return "Person{" +
                "name='" + name + '\'' +
                ", age='" + age + '\'' +
                ", gender='" + gender + '\'' +
                ", job='" + job + '\'' +
                ", birthday='" + birthday + '\'' +
                ", address='" + address + '\'' +
                '}';
    }
}

public static void main(String[] args) {

    Person person = new Person
            .Builder("홍길동", "26") // static inner class 초기화 (필수 파라미터)
            .gender("man") // 선택 파라미터
            .job("Warrior")
            .birthday("1800.10.10")
            .address("조선")
            .build();

    System.out.println(person);
}

디렉터 빌더 패턴 (GOF)

GOF에서 정의하고 있는 디자인 패턴은 복잡한 객체의 생성 알고리즘과 조립 방법을 분리하여 빌드 공정을 구축하는것이 목적이다. 빌더를 받아 조립 방법을 정의한 클래스를 Director라고 부른다.

심플 빌더 패턴은 하나의 대상 객체에 대한 생성만을 목적을 두지만, 디렉터 빌더 패턴은 여러가지의 빌드 형식을 유연하게 처리하는 것에 목적을 둔다. 어찌보면 일반적인 빌더 패턴을 고도화 시킨 패턴이라고 볼 수 도 있다.

Director 빌더 패턴 구조

Builder : 빌더 추상 클래스
ConcreteBuilder : Builder의 구현체. Product 생성을 담당한다.
Director : Builder에서 제공하는 메서드들을 사용해 정해진 순서대로 Product 생성하는 프로세스를 정의
Product : Director가 Builder로 만들어낸 결과물.

이러한 구조는 클라이언트가 직접 빌더의 모든 API를 사용하는 게 아닌, Director을 통해서 간단하게 인스턴스를 얻어올 수 있고 코드를 재사용할 수 있도록 한다.

Director 빌더 패턴 구현하기

다음 예제는 일반적인 자바 데이터를 저장하고 있는 Data 객체를 Builder 인터페이스를 통해 적절한 문자열 포맷으로 변환하는 예제이다.

PlainTextBuilder : Data 인스턴스의 데이터들을 평이한 텍스트 형태로 만드는 API
JSONBuilder : Data 인스턴스의 데이터들을 JSON 형태로 만드는 API
XMLBuilder : Data 인스턴스의 데이터들을 XML 형태로 만드는 API

이때 각 문자열 포맷으로 변환하는 프로세스를 Director 객체가 담당하게 된다. 클라이언트는 Director를 이용하여 간단한 메서드 호출만으로 복잡한 빌드 공정 과정을 알필요없이 결과물을 얻을 수 있다.

class Data {
    private String name;
    private int age;

    public Data(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

abstract class Builder {
    // 상속한 자식 클래스에서 사용하도록 protected 접근제어자 지정
    protected Data data;

    public Builder(Data data) {
        this.data = data;
    }

    // Data 객체의 데이터들을 원하는 형태의 문자열 포맷을 해주는 메서드들 (머리 - 중간 - 끝 형식)
    public abstract String head();
    public abstract String body();
    public abstract String foot();

}

// Data 데이터들을 평범한 문자열로 변환해주는 빌더
class PlainTextBuilder extends Builder {

    public PlainTextBuilder(Data data) {
        super(data);
    }

    @Override
    public String head() {
        return "";
    }

    @Override
    public String body() {
        StringBuilder sb = new StringBuilder();

        sb.append("Name: ");
        sb.append(data.getName());
        sb.append(", Age: ");
        sb.append(data.getAge());

        return sb.toString();
    }

    @Override
    public String foot() {
        return "";
    }
}

// Data 데이터들을 JSON 형태의 문자열로 변환해주는 빌더
class JSONBuilder extends Builder {

    public JSONBuilder(Data data) {
        super(data);
    }

    @Override
    public String head() {
        return "{\n";
    }

    @Override
    public String body() {
        StringBuilder sb = new StringBuilder();

        sb.append("\t\"Name\" : ");
        sb.append("\"" + data.getName() + "\",\n");
        sb.append("\t\"Age\" : ");
        sb.append(data.getAge());

        return sb.toString();
    }

    @Override
    public String foot() {
        return "\n}";
    }
}

// Data 데이터들을 XML 형태의 문자열로 변환해주는 빌더
class XMLBuilder extends Builder {
    public XMLBuilder(Data data) {
        super(data);
    }

    @Override
    public String head() {
        StringBuilder sb = new StringBuilder();

        sb.append("<?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n");
        sb.append("<DATA>\n");

        return sb.toString();
    }

    @Override
    public String body() {
        StringBuilder sb = new StringBuilder();

        sb.append("\t<NAME>");
        sb.append(data.getName());
        sb.append("<NAME>");
        sb.append("\n\t<AGE>");
        sb.append(data.getAge());
        sb.append("<AGE>");

        return sb.toString();
    }

    @Override
    public String foot() {
        return "\n</DATA>";
    }
}

// 각 문자열 포맷 빌드 과정을 템플릿화 시킨 디렉터
class Director {
    private Builder builder;

    public Director(Builder builder) {
        this.builder = builder;
    }

    // 일종의 빌드 템플릿 메서드라 보면 된다
    public String build() {
        StringBuilder sb = new StringBuilder();

		// 빌더 구현체에서 정의한 생성 알고리즘이 실행됨
        sb.append(builder.head());
        sb.append(builder.body());
        sb.append(builder.foot());

        return sb.toString();
    }
}

public static void main(String[] args) {
    // 1. 포맷할 자바 데이터 생성
    Data data = new Data("홍길동", 44);

    // 2. 일반 텍스트로 포맷하여 출력하기
    Builder builder1 = new PlainTextBuilder(data);
    Director director1 = new Director(builder1);
    String result1 = director1.build();
    System.out.println(result1);

    // 3. JSON 형식으로 포맷하여 출력하기
    Builder builder2 = new JSONBuilder(data);
    Director director2 = new Director(builder2);
    String result2 = director2.build();
    System.out.println(result2);

    // 4. XML 형식으로 포맷하여 출력하기
    Builder builder3 = new XMLBuilder(data);
    Director director3 = new Director(builder3);
    String result3 = director3.build();
    System.out.println(result3);
}

이처럼 Director는 템플릿화 한 메서드를 통해 일관된 프로세스로 인스턴스를 만드는 빌드 과정을 단순화 하고, 클라이언트 쪽에선 Director가 제공하는 메서드를 호출하므로써 코드를 재사용할 수 있게 된다.

즉, Builder 는 부품을 만들고, Director는 ㅠuilder가 만든 부품을 조합해 제품을 만든다고 할 수 있다.

GOF의 빌더 패턴은 여러 디자인 패턴의 짬뽕

지금 까지 구현해본 GOF의 디렉터 빌더 패턴은 어찌 보면 빌드 과정을 추상화 및 단순화한 Facade 패턴과 빌드 과정 코드를 템플릿화한 Template Method 패턴 그리고 원하는 문자열 형식의 각 빌드 전략 알고리즘을 정의한 Strage 패턴을 짬뽕 시킨 디자인 패턴이라고 볼수도 있다.

Lombok의 @Builder

개발자가 좀더 편하게 빌더 패턴을 이용하기 위헤 Lombok에서는 별도의 어노테이션을 지원한다. 클래스에 @Builder 어노테이션만 붙여주면 클래스를 컴파일 할 때 자동으로 클래스 내부에 빌더 API가 만들어진다.

단, 롬복의 @Builder는 GOF의 디렉터 빌더가 아닌 심플 빌더 패턴을 다룬다는 점은 유의하자.

빌더 어노테이션 구현하기

@Builder : PersonBuilder 빌더 클래스와 이를 반환하는 builder() 메서드 생성
@AllArgsConstructor(access = AccessLevel.PRIVATE) : @Builder 어노테이션을 선언하면 전체 인자를 갖는 생성자를 자동으로 만드는데, 이를 private 생성자로 설정
@ToString : toString() 메서드 자동 생성

import lombok.AccessLevel;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.ToString;

@Builder
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@ToString
class Person {
    private final String name;
    private final String age;
    private final String gender;
    private final String job;
    private final String birthday;
    private final String address;
}

public static void main(String[] args) {
    Person person = Person.builder()
            .name("홍길동")
            .age("26")
            .gender("man") // 선택 파라미터
            .job("Warrior")
            .birthday("1800.10.10")
            .address("조선")
            .build();
}

필수 파라미터 빌더 구현하기

@Builder 어노테이션으로 빌더 패턴을 구현하면 필수 파라미터 적용을 지정해줄수가 없다. 따라서 대상 객체 안에 별도의 ~~builder()~~ 정적 메서드를 구현함으로써, 빌더 객체를 생성하기 전에 필수 파라미터를 설정하도록 유도할수 있고, 또한 파라미터 검증 로직도 추가해줄 수 있다.

@Builder
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@ToString
class Person {
    private final String name;
    private final String age;
    private final String gender;
    private final String job;
    private final String birthday;
    private final String address;

    // 필수 파라미터 빌더 메서드 구현
    public static PersonBuilder builder(String name, String age) {
        // 빌더의 파라미터 검증
        if(name == null || age == null)
            throw new IllegalArgumentException("필수 파라미터 누락");

        // 필수 파라미터를 미리 빌드한 빌더 객체를 반환 (지연 빌더 원리)
        return new PersonBuilder().name(name).age(age);
    }
}

public static void main(String[] args) {

    Person person = Person.builder("홍길동", "26") // 필수 파라미터
            .gender("man") // 선택 파라미터
            .job("Warrior")
            .birthday("1800.10.10")
            .address("조선")
            .build();

    System.out.println(person);
}

실무에서 찾아보는 Builder 패턴

Java

java.lang.StringBuilder의 append()
java.lang.StringBuffer의 append()
java.nio.ByteBuffer의 put() - CharBuffer, ShortBuffer, IntBuffer, LongBuffer, FloatBuffer, DoubleBuffer 도 마찬가지
javax.swing.GroupLayout.Group의 addComponent()
java.lang.Appendable의 구현체
java.util.stream.Stream.Builder

StringBuilder

자바의 문자열 클래스하면 배우는 StringBuilder가 이름에서 보듯이 그 예이다.

빌더에 해당하는 StringBuilder를 생성하고, 빌더가 제공하는 append 메서드로 파라미터를 구성하고, 최종적으로 toString을 호출해서 String 객체를 생성하는 일련의 과정이 빌더 패턴이기 때문이다.

public static void main(String[] args) {
    String result = new StringBuilder()
            .append("hello ")
            .append("world!")
            .toString(); // build()

    System.out.println(result);
}

StreamBuilder

Stream API가 제공하는 StreamBuilder도 마찬가지이다. StreamBuilder를 사용하면 Stream에 들어갈 요소를 add 할 수 있고, 최종적으로 build를 호출해서 stream 객체를 생성한다.

public static void main(String[] args) {
    Stream.Builder<String> stringBuilder = Stream.builder();
    Stream<String> stream = stringBuilder.add("hello").add("world!").add("bye..").build();

    stream.forEach(System.out::println);
}

Spring Framework

스프링 프레임워크에선 UriComponents 인스턴스를 Uricomponentsbuilder를 통해서 만들 수 있다. uri를 하드코딩해서 만드는 것보다 안전하게 만들 수 있다.

public static void main(String[] args) {
    UriComponents uriComponents = UriComponentsBuilder.newInstance()
            .scheme("https")
            .host("kangworld.tistory.com")
            .build();

    System.out.println(uriComponents);
}

# 참고자료

이펙티브 자바 Effective Java 3/E

코딩으로 학습하는 GoF의 디자인 패턴 - 백기선

https://refactoring.guru/design-patterns/builder

https://www.youtube.com/watch?v=_GCiJAFU2DU

퍼사드(Facade) 패턴 - 완벽 마스터하기

인파_ — Tue, 14 Mar 2023 08:55:10 +0900

Facade Pattern

퍼사드 패턴(Facade Pattern)은 사용하기 복잡한 클래스 라이브러리에 대해 사용하기 편하게 간편한 인터페이스(API)를 구성하기 위한 구조 패턴 이다. 예를들어 라이브러리의 각 클래스와 메서드들이 어떤 목적의 동작인지 이해하기 어려워 바로 가져다 쓰기에는 난이도가 높을때, 이에 대한 적절한 네이밍과 정리를 통해 사용자로 하여금 쉽게 라이브러리를 다룰수 있도록 인터페이스를 만드는데, 우리가 교제를 보고 필기노트에 재정리를 하듯이 클래스를 재정리하는 행위로 보면 된다.

본래 프로그램이라는 것은 업데이트를 통해 점점 커지게 된다. 버전이 올라갈수록 많은 클래스들이 만들어져 서로 관계를 맺으면서 점점 복잡해지게 된다. 그래서 커다란 솔루션을 구성하려면 상호 관련된 많은 클래스들을 적절히 제어해야 할 필요성이 있다. 이때 이 처리를 개별적으로 제어하는 것이 아닌 일종의 '창구'를 준비하여 중계할 수 있도록 구성해준다면, 사용자는 창구를 통해서 간단한 명령 요구만 내리면 요구에 대해 필요한 모든 집약적 행위들을 창구가 알아서 처리해 결과를 내주게 된다.

고객은 복잡한 절차 지식없이 고객센터(창구)에 요구만 하면 결과를 얻는다

이처럼 퍼사드(Facade) 패턴은 복잡하게 얽혀 있는 것을 정리해서 사용하기 편한 인터페이스를 고객에게 제공한다고 보면된다. 그래서 고객은 복잡한 시스템을 알 필요없이 시스템의 외부에 대해서 단순한 인터페이스를 이용하기만 하면 된다. 퍼사드를 이용하면 자칫 동작의 목적과 같은 중요한 사항을 놓치는 실수를 줄일 수 있다.

Facade라는 단어의 뜻은 건축물의 정면을 의미한다. 건축물의 정면은 보통 건축물의 이미지와 건축 의도를 나타내기 때문에 오래 전부터 특별한 디자인을 적용하여 의미를 부여했다. 이처럼 건축물 정면만 봐도 이 건물이 어떤 목적을 하는지 단번에 알수 있다는 특징을 차용하여 명명 지은 것이다.

퍼사드 패턴 구조

Facade : 서브시스템 기능을 편리하게 사용할 수 있도록 하기 위해 여러 시스템과 상호 작용하는 복잡한 로직을 재정리해서 높은 레벨의 인터페이스를 구성한다. Facade 역할은 서브 시스템의 많은 역할에 대해 ‘단순한 창구’가 된다. 클라이언트와 서브시스템이 서로 긴밀하게 연결되지 않도록 한다.
Additional Facade : 퍼사드 클래스는 반드시 한개만 존재해야 한다는 규칙같은 건 없다. 연관 되지 않은 기능이 있다면 얼마든지 퍼사드 2세로 분리한다. 이 퍼사드 2세는 다른 퍼사드에서 사용할 수도 있고 클라이언트에서 직접 접근할 수도 있다.
SubSystem(하위 시스템) : 수십 가지 라이브러리 혹은 클래스들
Client : 서브 시스템에 직접 접근하는 대신 Facade를 사용한다.

퍼사드 패턴은 전략 패턴이나 팩토리 패턴과 같은 여타 다른 디자인 패턴과는 다르게 클래스 구조가 정형화 되지 않은 패턴이다. 반드시 클래스 위치는 어떻고 어떤 형식으로 위임을 해야되고 이런것이 없다. 그냥 퍼사드 클래스를 만들어 적절히 기능 집약화만 해주면 그게 디자인 패턴이 되는 것이다. (패턴이라기 보단 논리에 가깝다)

C언어나 파이썬에서 어떠한 복잡한 로직의 코드가 있으면 이걸 main 함수에서 모두 실행하는 것이 아니라, 함수(function) 분리를 통해 main 함수의 코드를 심플하게 구성해본 경험이 있을 것이다. 이를 객체 지향 프로그래밍 관점으로 치환한 것이 퍼사드 패턴이다. 즉, 퍼사드는 복잡한 것(내부에서 실행되고 있는 많은 클래스의 관계나 사용법)을 단순하게 보여주는 것에 초점을 둔다. 클라이언트로 하여금 복잡한 것을 의식하지 않도록 해주는 것이다.

Client들은 복잡한 Subsystem을 의식하지않고 Facade라는 창구를 통해 결과를 얻는다

재귀적인 Facade 패턴의 적용

재귀적 퍼사드란 위에서 언급한 Additional Facade 를 말하는 것이다. 예를들어 다수의 클래스, 다수의 패키지를 포함하고 있는 큰 시스템에 요소 요소 마다 Facade 패턴을 여기 저기 적용하고 다시 그 Facade를 합친 Facade를 만드는 식으로, 퍼사드를 재귀적으로 구성하면 시스템은 보다 편리하게 된다. 이처럼 퍼사드는 한개만 있으라는 법은 없으며 필요에 의하면 얼마든지 늘려 의존할 수 있다.

퍼사드 패턴 특징

패턴 사용 시기

시스템이 너무 복잡할때
그래서 간단한 인터페이스를 통해 복잡한 시스템을 접근하도록 하고 싶을때
시스템을 사용하고 있는 외부와 결합도가 너무 높을 때 의존성 낮추기 위할때

패턴 장점

하위 시스템의 복잡성에서 코드를 분리하여, 외부에서 시스템을 사용하기 쉬워진다.
하위 시스템 간의 의존 관계가 많을 경우 이를 감소시키고 의존성을 한 곳으로 모을 수 있다.
복잡한 코드를 감춤으로써, 클라이언트가 시스템의 코드를 모르더라도 Facade 클래스만 이해하고 사용 가능하다.

외부에서 내부 로직을 직접 사용하기 떄문에 내부 로직의 구조를 변경한다고 하거나 파라미터나 리턴값 등을 변경할 경우 직접적으로 영향을 받아 수정이힘들거나 불가능한 경우가 종종 있다. 하지만 중간에 매개체 역할을 해주는 퍼사드 객체가 있기 때문에 실제 내부 로직이 어떻게 변경이 되더라도 상관이 없어지므로 의존성이 감소된다.

패턴 단점

퍼사드가 앱의 모든 클래스에 결합된 God 객체가 될 수 있다
퍼사드 클래스 자체가 서브시스템에 대한 의존성을 가지게 되어 의존성을 완전히는 피할 수는 없다.
어찌되었건 추가적인 코드가 늘어나는 것이기 때문에 유지보수 측면에서 공수가 더 많이 들게 된다.
따라서 추상화 하고자하는 시스템이 얼마나 복잡한지 퍼사드 패턴을 통해서 얻게 되는 이점과 추가적인 유지보수 비용을 비교해보며 결정하여야 한다.

예제를 통해 알아보는 Facade 패턴

복잡한 DBMS 시스템 간편하게 재구성

데이터베이스로부터 어떤 데이터를 조회해서 출력해주는 JDBC 비스무리한 자바 패키지가 있다고 하자. 우리는 이 라이브러리를 이용하여 데이터베이스로부터 값을 얻어오고 화면에 데이터를 파싱해서 예쁘게 출력하려는 프로그램을 만들려고 한다.

패키지에는 총 4개의 Cache, DBMS, Row, Message 클래스가 존재한다. 그리고 아래 그림에서 볼 수 있듯이 각 행위에 대해 각 클래스들의 역할이 정해져 있다.

각 클래스들의 역할 (점선)

그런데 이 라이브러리를 이용하는데 있어 데이터베이스를 조회해서 데이터를 가공하기 까지 다음과 같은 규칙이 존재한다고 한다.

dbms를 바로 조회하기전에
과거에 조회된 데이터인지를 캐시에서 먼저 조사를 하고
캐시에 데이터가 있다면 이 캐시에 데이터를 가공하고 출력
캐시에 데이터가 없다면 DBMS를 통해서 조회를 하고
조회된 데이터를 가공하고 출력함과 동시에 캐시에 저장한다.

DBMS에 조회된 데이터는 성능을 위해 반드시 캐시에 저장해야 되는 것을 잊지 말아야하고, 또한 데이터를 가공하기 위해서는 Message 클래스를 써야 한다. 이 수칙을 따르지 않으면 라이브러리가 제대로 작동하지 않아 개발자는 위의 사항을 제대로 숙지한 상태에서 프로그래밍을 하여야 한다.

우선 라이브러리의 각 클래스에 대한 은유적인 코드는 아래와 같다고 한다.

// DBMS에 저장된 데이터를 나타내는 클래스
class Row  {
    private String name;
    private String birthday;
    private String email;

    public Row(String name, String birthday, String email) {
        this.name = name;
        this.birthday = birthday;
        this.email = email;
    }

    public String getName() {
        return name;
    }

    public String getBirthday() {
        return birthday;
    }

    public String getEmail() {
        return email;
    }
}

// 데이터베이스 역할을 하는 클래스
class DBMS {
    private HashMap<String, Row> db = new HashMap<>();

    public void put(String name, Row row) {
        db.put(name, row);
    }

    // 데이터베이스에 쿼리를 날려 결과를 받아오는 메소드
    public Row query(String name) {
        try {
            Thread.sleep(500); // DB 조회 시간을 비유하여 0.5초대기로 구현
        } catch(InterruptedException e) {}

        return db.get(name.toLowerCase());
    }
}

// DBMS에서 조회된 데이터를 임시로 담아두는 클래스 (속도 향상)
class Cache {
    private HashMap<String, Row> cache = new HashMap<>();

    public void put(Row row) {
        cache.put(row.getName(), row);
    }

    public Row get(String name) {
        return cache.get(name);
    }
}

// Row 클래스를 보기좋게 출력하는 클래스
class Message {
    private Row row;

    public Message(Row row) {
        this.row = row;
    }

    public String makeName() {
        return "Name : \"" + row.getName() + "\"";
    }

    public String makeBirthday() {
        return "Birthday : " + row.getBirthday();
    }

    public String makeEmail() {
        return "Email : " + row.getEmail();
    }
}

클린하지 않은 문제의 코드 ❌

문제의 코드는 당연히 라이브러리의 코드를 그대로 메인 로직에 작성하여 구현하는 것이다. 데이터를 조회하고 출력되기 까지 여러개의 객체가 사용되고 있다.

물론 당장은 프로그램이 정상적으로 돌아가 서비스에는 문제가 없을지는 모르겠지만, 나중에 수정과 확장함에 있어 개발자가 위의 수칙들을 까먹고 실수를 하여 서비스에 버그가 생길수 있다.

class Client {
    public static void main(String[] args) {
        // 1. 데이터베이스 생성 & 등록
        DBMS dbms = new DBMS();
        dbms.put("홍길동", new Row("홍길동", "1890-02-14", "honggildong@naver.com"));
        dbms.put("임꺽정", new Row("임꺽정", "1820-11-02", "imgguckjong@naver.com"));
        dbms.put("주몽", new Row("주몽", "710-08-27", "jumong@naver.com"));

        // 2. 캐시 생성
        Cache cache = new Cache();

        // 3. 트랜잭션에 앞서 먼저 캐시에 데이터가 있는지 조회
        String name = "홍길동";
        Row row = cache.get(name);

        // 4. 만약 캐시에 없다면
        if (row == null){
            row = dbms.query(name); // DB에 해당 데이터를 조회해서 row에 저장하고
            if(row != null) {
                cache.put(row); // 캐시에 저장
            }
        }

        // 5. dbms.query(name)에서 조회된 값이 있으면
        if(row != null) {
            Message message = new Message(row);

            System.out.println(message.makeName());
            System.out.println(message.makeBirthday());
            System.out.println(message.makeEmail());
        }
        // 6. 조회된 값이 없으면
        else {
            System.out.println(name + " 가 데이터베이스에 존재하지 않습니다.");
        }
    }
}

퍼사드 패턴을 적용한 코드 ✔️

따라서 이러한 사항들을 개발자가 직접 기억해서 하나하나 따져가며 코드를 작성하는 것보다, 이 사항들을 묶은 클래스를 하나 추가해서 단순화된 인터페이스를 통해 서브 클래스를 다룸으로써 개발자의 실수를 줄이고자 하는 것이 바로 퍼사드(Facade) 패턴이다. 마치 교제에 있는 풀어져 있는 내용들을 필기노트에 요약하듯이, 퍼사드 객체에 사용 로직을 묶어 재정리 함으로써 단순화 시켜 개발을 보다 용이하게 해주는 것이다.

다음과 같이 퍼사드 클래스를 생성해 주고 메인 메소드의 로직을 퍼사드 클래스의 메서드에 통짜로 넣는다. (분리가 필요하면 메서드를 더 늘린다)

class Facade {
    private DBMS dbms = new DBMS();
    private Cache cache = new Cache();

    public void insert() {
        dbms.put("홍길동", new Row("홍길동", "1890-02-14", "honggildong@naver.com"));
        dbms.put("임꺽정", new Row("임꺽정", "1820-11-02", "imgguckjong@naver.com"));
        dbms.put("주몽", new Row("주몽", "710-08-27", "jumong@naver.com"));
    }

    public void run(String name) {
        Row row = cache.get(name);

        // 1. 만약 캐시에 없다면
        if (row == null){
            row = dbms.query(name); // DB에 해당 데이터를 조회해서 row에 저장하고
            if(row != null) {
                cache.put(row); // 캐시에 저장
            }
        }

        // 2. dbms.query(name)에서 조회된 값이 있으면
        if(row != null) {
            Message message = new Message(row);

            System.out.println(message.makeName());
            System.out.println(message.makeBirthday());
            System.out.println(message.makeEmail());
        }
        // 3. 조회된 값이 없으면
        else {
            System.out.println(name + " 가 데이터베이스에 존재하지 않습니다.");
        }
    }
}

class Client {
    public static void main(String[] args) {

        // 1. 퍼사드 객체 생성
        Facade facade = new Facade();

        // 2. db 값 insert
        facade.insert();

        // 3. 퍼사드로 데이터베이스 & 캐싱 & 메세징 로직을 한번에 조회
        String name = "홍길동";
        facade.run(name);
    }
}

퍼사드 패턴을 적용하니 메인 로직이 엄청 심플해졌다. 이처럼 퍼사드의 핵심은 인터페이스(API)를 적게 구성하는 것이다. 라이브러리에서 제공하는 클래스나 메소드가 많이 보이면, 프로그래머는 무엇을 사용하면 좋을지 망설이게 되고 호출하는 순서도 doc을 살펴보며 주의해야만 한다. 주의해야 한다는 말은 다르게 말하면 틀리기 쉽다는 것이다. 따라서 퍼사드의 메서드를 가능한 적게 구성하는 것이 좋다.

오해하지 말아야 할 점은 퍼사드는 하위 시스템 클래스들을 캡슐화 하는 것이 아니다. 그냥 서브 시스템들을 사용할 간단한 인터페이스를 제공할 뿐 이다. 사용자가 서브 시스템 내부의 클래스를 직접 사용하는 것을 제한할 수는 없다. 그래서 오히려 추상화에 가깝다고 볼 수 있다.

대부분의 경우 퍼사드 객체는 하나만 있어도 충분하므로, 퍼사드 클래스를 싱글톤으로 구성해주면 좋다.

# 참고자료

코딩으로 학습하는 GoF의 디자인 패턴 - 백기선

https://youtu.be/mQlOqyFE3oI

https://refactoring.guru/design-patterns/facade

http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html

반복자(Iterator) 패턴 - 완벽 마스터하기

인파_ — Mon, 13 Mar 2023 09:43:50 +0900

Iterator Pattern

반복자(Iterator) 패턴은 일련의 데이터 집합에 대하여 순차적인 접근(순회)을 지원하는 패턴이다.

데이터 집합이란 객체들을 그룹으로 묶어 자료의 구조를 취하는 컬렉션을 말한다. 대표적인 컬렉션으로 한번쯤은 들어본 리스트나 트리, 그래프, 테이블 ..등이 있다.

요소를 다양한 방법으로 저장하는 컬렉션

보통 배열이나 리스트 같은 경우 순서가 연속적인 데이터 집합이기 때문에 간단한 for문을 통해 순회할수 있다. 그러나 해시, 트리와 같은 컬렉션은 데이터 저장 순서가 정해지지 않고 적재되기 때문에, 각 요소들을 어떤 기준으로 접근해야 할지 애매해진다.

예를들어 아래와 같이 트리 구조가 있다면 어떤 상황에선 깊이(세로)를 우선으로 순회 해야 할 수도 있고, 너비(가로)를 우선으로 순회할수도 있기 때문이다.

어떤 기준으로 순회할지 컬렉션마다 다를수 있다

이처럼 복잡하게 얽혀있는 자료 컬렉션들을 순회하는 알고리즘 전략을 정의하는 것을 이터레이터 패턴이라고 한다.

컬렉션 객체 안에 들어있는 모든 원소들에 대한 접근 방식이 공통화 되어 있다면 어떤 종류의 컬렉션에서도 이터레이터만 뽑아내면 여러 전략으로 순회가 가능해 보다 다형(多形) 적인 코드를 설계할 수 있게 된다.

자바의 컬렉션 프레임워크(JCF)에서 각종 컬렉션을 무리없이 순회할수 있는 것도 내부에 미리 이터레이터 패턴이 적용되어 있기 때문이다.

이밖에도 이터레이터 패턴은 별도의 이터레이터 객체를 반환 받아 이를 이용해 순회하기 때문에, 집합체의 내부 구조를 노출하지 않고 순회 할 수 있다는 장점도 있다.

이터레이터 패턴 구조

Aggregate (인터페이스) : ConcreateIterator 객체를 반환하는 인터페이스를 제공한다.
- iterator() : ConcreateIterator 객체를 만드는 팩토리 메서드
ConcreateAggregate (클래스) : 여러 요소들이 이루어져 있는 데이터 집합체
Iterator (인터페이스) : 집합체 내의 요소들을 순서대로 검색하기 위한 인터페이스를 제공한다.
- hasNext() : 순회할 다음 요소가 있는지 확인 (true / false)
- next() : 요소를 반환하고 다음 요소를 반환할 준비를 하기 위해 커서를 이동시킴
ConcreateIterator (클래스) : 반복자 객체
- ConcreateAggregate가 구현한 메서드로부터 생성되며, ConcreateAggregate 의 컬렉션을 참조하여 순회한다.
- 어떤 전략으로 순회할지에 대한 로직을 구체화 한다.

이터레이터 패턴 흐름

클래스 구성

// 집합체 객체 (컬렉션)
interface Aggregate {
    Iterator iterator();
}

class ConcreteAggregate implements Aggregate {
    Object[] arr; // 데이터 집합 (컬렉션)
    int index = 0;

    public ConcreteAggregate(int size) {
        this.arr = new Object[size];
    }

    public void add(Object o) {
        if(index < arr.length) {
            arr[index] = o;
            index++;
        }
    }

    // 내부 컬렉션을 인자로 넣어 이터레이터 구현체를 클라이언트에 반환
    @Override
    public Iterator iterator() {
        return new ConcreteIterator(arr);
    }
}

// 반복체 객체
interface Iterator {
    boolean hasNext();
    Object next();
}

class ConcreteIterator implements Iterator {
    Object[] arr;
    private int nextIndex = 0; // 커서 (for문의 i 변수 역할)

    // 생성자로 순회할 컬렉션을 받아 필드에 참조 시킴
    public ConcreteIterator(Object[] arr) {
        this.arr = arr;
    }

    // 순회할 다음 요소가 있는지 true / false
    @Override
    public boolean hasNext() {
        return nextIndex < arr.length;
    }

    // 다음 요소를 반환하고 커서를 증가시켜 다음 요소를 바라보도록 한다.
    @Override
    public Object next() {
        return arr[nextIndex++];
    }
}

클래스 흐름

public static void main(String[] args) {
    // 1. 집합체 생성
    ConcreteAggregate aggregate = new ConcreteAggregate(5);
    aggregate.add(1);
    aggregate.add(2);
    aggregate.add(3);
    aggregate.add(4);
    aggregate.add(5);

    // 2. 집합체에서 이터레이터 객체 반환
    Iterator iter = aggregate.iterator();

    // 3. 이터레이터 내부 커서를 통해 순회
    while(iter.hasNext()) {
        System.out.printf("%s → ", iter.next());
    }
}

위의 예제에선 구현을 간단히 하기 위해 집합 객체의 내부 컬렉션을 배열로 표현했지만, 배열 뿐만 아니라 여러 복잡한 컬렉션으로도 이터레이터 구현이 가능하다.

이터레이터 패턴 특징

패턴 사용 시기

컬렉션에 상관없이 객체 접근 순회 방식을 통일하고자 할 때
컬렉션을 순회하는 다양한 방법을 지원하고 싶을 때
컬렉션의 복잡한 내부 구조를 클라이언트로 부터 숨기고 싶은 경우 (편의 + 보안)
데이터 저장 컬렉션 종류가 변경 가능성이 있을 때
- 클라이언트가 집합 객체 내부 표현 방식을 알고 있다면, 표현 방식이 달라지면 클라이언트 코드도 변경되어야 하는 문제가 생긴다.

패턴 장점

일관된 이터레이터 인터페이스를 사용해 여러 형태의 컬렉션에 대해 동일한 순회 방법을 제공한다.
컬렉션의 내부 구조 및 순회 방식을 알지 않아도 된다.
집합체의 구현과 접근하는 처리 부분을 반복자 객체로 분리해 결합도를 줄 일 수 있다.
- Client에서 iterator로 접근하기 때문에 ConcreteAggregate 내에 수정 사항이 생겨도 iterator에 문제가 없다면 문제가 발생하지 않는다.
순회 알고리즘을 별도의 반복자 객체에 추출하여 각 클래스의 책임을 분리하여 단일 책임 원칙(SRP)를 준수한다.
데이터 저장 컬렉션 종류가 변경되어도 클라이언트 구현 코드는 손상되지 않아 수정에는 닫혀 있어 개방 폐쇄 원칙(OCP)를 준수한다.

패턴 단점

클래스가 늘어나고 복잡도가 증가한다.
- 만일 앱이 간단한 컬렉션에서만 작동하는 경우 패턴을 적용하는 것은 복잡도만 증가할 수 있다.
- 이터레이터 객체를 만드는 것이 유용한 상황인지 판단할 필요가 있다.
구현 방법에 따라 캡슐화를 위배할 수 있다.

예제를 통해 알아보는 Iterator 패턴

이터레이터로 순회 전략을 나누기

클라이언트 요구사항은 다음과 같다. 게시판에 글을 올릴건데, 게시글을 최근글, 작성순으로 정렬해서 나열 할 수 있게 해달라고 한다. 즉, 두가지 정렬 전략을 구현해야 되는 것이다.

클린하지 않은 문제의 코드 ❌

다음은 게시글(Post)과 게시판(Borad)를 표현한 인스턴스이다.

게시글에는 게시글 제목 title과 게시글 발행 날짜 필드가 있다. (코드 간략화를 위해 게시글 내용은 생략하였다)

// 게시글
class Post {
    String title; // 게시글 제목
    LocalDate date; // 게시글 발행일

    public Post(String title, LocalDate date) {
        this.title = title;
        this.date = date;
    }
}

// 게시판
class Board {
    // 게시글을 리스트 집합 객체로 저장 관리
    List<Post> posts = new ArrayList<>();

    public void addPost(String title, LocalDate date) {
        this.posts.add(new Post(title, date));
    }

    public List<Post> getPosts() {
        return posts;
    }
}

public static void main(String[] args) {
    // 1. 게시판 생성
    Board board = new Board();

    // 2. 게시판에 게시글을 포스팅
    board.addPost("디자인 패턴 강의 리뷰", LocalDate.of(2020, 8, 30));
    board.addPost("게임 하실분", LocalDate.of(2020, 2, 6));
    board.addPost("이거 어떻게 하나요?", LocalDate.of(2020, 6, 1));
    board.addPost("이거 어떻게 하나요?", LocalDate.of(2021, 12, 22));

    List<Post> posts = board.getPosts();
    
    // 3. 게시글 발행 순서대로 조회하기
    for (int i = 0; i < posts.size(); i++) {
        Post post = posts.get(i);
        System.out.println(post.title + " / " + post.date);
    }

    // 4. 게시글 날짜별로 조회하기
    Collections.sort(posts, (p1, p2) -> p1.date.compareTo(p2.date)); // 집합체를 날짜별로 정렬
    for (int i = 0; i < posts.size(); i++) {
        Post post = posts.get(i);
        System.out.println(post.title + " / " + post.date);
    }
}

일반적으로 for문을 돌려 집합체의 요소들을 순회하였다. 그러나 이러한 구성 방식은 Board에 들어간 Post를 순회할 때, Board가 어떠한 구조로 이루어져 있는지를 클라이언트에 노출된다. 따라서 이를 보다 객체 지향적으로 구성하기 위해 이터레이터 패턴을 적용해보자.

이터레이터 패턴을 적용한 코드 ✔️

위에서 이터레이터 인터페이스를 직접 만들어 썼지만, 자바에선 이미 이터레이터 인터페이스를 지원한다. 자바의 내부 이터레이터를 재활용해서 메서드 위임을 통해 코드를 간단하게 구현할 수도 있다.

순회 전략으로는 리스트 저장 순서대로 조회와 날짜 순서대로 조회 두가지가 존재한다. 따라서 이에 대한 이터레이터 클래스 역시 두가지 생성해주면 된다.

ListPostIterator : 저장 순서 이터레이터
DatePostIterator : 날짜 순서 이터레이터

그리고 ListPostIterator 와 DatePostIterator 객체를 반환하는 팩토리 메서드를 Board 클래스에 추가만 해주면 완성 된다.

// 저장 순서 이터레이터
class ListPostIterator implements Iterator<Post> {
    private Iterator<Post> itr;

    public ListPostIterator(List<Post> posts) {
        this.itr = posts.iterator();
    }

    @Override
    public boolean hasNext() {
        return this.itr.hasNext(); // 자바 내부 이터레이터에 위임해 버림
    }

    @Override
    public Post next() {
        return this.itr.next(); // 자바 내부 이터레이터에 위임해 버림
    }
}

// 날짜 순서 이터레이터
class DatePostIterator implements Iterator<Post> {
    private Iterator<Post> itr;

    public DatePostIterator(List<Post> posts) {
        // 최신 글 목록이 먼저 오도록 정렬
        Collections.sort(posts, (p1, p2) -> p1.date.compareTo(p2.date));
        this.itr = posts.iterator();
    }

    @Override
    public boolean hasNext() {
        return this.itr.hasNext(); // 자바 내부 이터레이터에 위임해 버림
    }

    @Override
    public Post next() {
        return this.itr.next(); // 자바 내부 이터레이터에 위임해 버림
    }
}

// 게시판
class Board {
    // 게시글을 리스트 집합 객체로 저장 관리
    List<Post> posts = new ArrayList<>();

    public void addPost(String title, LocalDate date) {
        this.posts.add(new Post(title, date));
    }

    public List<Post> getPosts() {
        return posts;
    }

    // ListPostIterator 이터레이터 객체 반환
    public Iterator<Post> getListPostIterator() {
        return new ListPostIterator(posts);
    }

    // DatePostIterator 이터레이터 객체 반환
    public Iterator<Post> getDatePostIterator() {
        return new DatePostIterator(posts);
    }
}

public static void main(String[] args) {
    // 1. 게시판 생성
    Board board = new Board();

    // 2. 게시판에 게시글을 포스팅
    board.addPost("디자인 패턴 강의 리뷰", LocalDate.of(2020, 8, 30));
    board.addPost("게임 하실분", LocalDate.of(2020, 2, 6));
    board.addPost("이거 어떻게 하나요?", LocalDate.of(2020, 6, 1));
    board.addPost("이거 어떻게 하나요?", LocalDate.of(2021, 12, 22));

    // 게시글 발행 순서대로 조회하기
    print(board.getListPostIterator());

    // 게시글 날짜별로 조회하기
    print(board.getDatePostIterator());
}

public static void print(Iterator<Post> iterator) {
    Iterator<Post> itr = iterator;
    while(itr.hasNext()) {
        Post post = itr.next();
        System.out.println(post.title + " / " + post.date);
    }
}

이제 클라이언트는 게시글을 순회할 때 Board 내부가 어떤 집합체로 구현(Array, List, Tree, Queue ..등) 되어 있는지 알 수 없게 감추고 전혀 신경 쓸 필요가 없게 되었다. 그리고 순회 전략을 각 객체로 나눔으로써 때에 따라 적절한 이터레이터 객체만 받으면 똑같은 이터레이터 순회 코드로 다양한 순회 전략을 구사할 수 있게 되었다.

집합체 구현에 상관 없이 순회를 표현 ✔️

Iterator를 사용하는 또다른 이유는 이터레이터를 사용함으로써 집합체 구현과 분리할 수 있기 때문이다.

Iterator<Post> itr = iterator;
while(itr.hasNext()) {
    Post post = itr.next();
    System.out.println(post.title + " / " + post.date);
}

이터레이터 객체를 반환하면 컬렉션을 순회할때 ~~hasNext()~~ 와 ~~next()~~ 라는 Iterator의 메소드만을 이용하기 때문에, 집합체인 Board의 내부 구성을 감출수 있게 된다. 즉, 위의 while문은 Board의 구현에 의존하지 않는 것이다.

이 말은 만일 추후에 Board의 집합체를 수정하더라도 Board 클래스가 올바른 Iterator만을 반환해 준다면 클라이언트의 코드(위의 while 루프)는 변경하지 않아도 되게 된다.

실무에서 찾아보는 Iterator 패턴

Java

java.util.Enumeration 과 java.util.Iterator
Java StAX (Streaming API for XML)의 Iterator 기반 API
- XmlEventReader, XmlEventWriter

java.util.Enumeration

Iterator가 만들어지기 전 java 1.0부터 있었던 API
과거의 클래스로서, 현재는 안쓰고 Iterator로 기능이 대체 되었다.
java 9 에서는 Enumeration Iterator로 변환해주는 코드가 추가되었다. ~~asIterator()~~

Iterator	Enumeration
요소를 반복하는 데 사용되는 일반 커서이며 모든 컬렉션 클래스에 적용할 수 있다.	Vector와 같은 레거시 클래스에만 적용할 수 있으므로 일반 커서가 아니다. 컬렉션 클래스에 대한 읽기 권한만 있다.
반복 메서드 : hasNext(), next()	반복 메서드 : hasMoreElements(), nextElement()
반복자를 사용하여 컬렉션의 요소를 제거할 수 있다.	읽기 권한만 있기 때문에 열거를 사용하여 컬렉션의 요소를 제거할 수 없다.

public static void main(String[] args) {
    Vector<Integer> rollno = new Vector<>();
    rollno.add(1);
    rollno.add(2);
    rollno.add(3);
    rollno.add(4);
    rollno.add(5);
    
    Enumeration<Integer> classNine = rollno.elements();

    // hasMoreElements(), nextElement() 로 순회
    while (classNine.hasMoreElements()) {
        System.out.println(classNine.nextElement());
    }
}

java.util.Iterator

hasNext() : 순회할 요소가 있는지 확인
next() : 현재 커서의 요소를 출력하고 다음으로 커서를 이동
remove() : Iterator에서 next()로 받았던 해당 엘리먼트를 삭제.
- 모든 이터레이터에서 다 지원하는 것은 아니다. UnsupportedOperationException()을 던지는 경우가 많다.
- 보통 이 기능은 동시에 다발적으로 같은 명령을 수행해도 안전한 컬렉션에서 제공한다.
forEachRemaining() : 함수형 인터페이스를 통해 순회 코드를 심플화 해준다

public static void main(String[] args) {
    Set<Integer> aggregate = new TreeSet<>(List.of(1,2,3,4,5));

    // hasNext(), next(), remove()
    Iterator<Integer> itr = aggregate.iterator();
    while(itr.hasNext()) {
        System.out.printf("%d 삭제", itr.next());
        itr.remove();
    }

    System.out.println(aggregate); // []
}

public static void main(String[] args) {
    Set<Integer> aggregate = new TreeSet<>(List.of(1,2,3,4,5));

    // 이터레이터의 while 문 코드를 for문으로 축약할 수 도 있다.
    for (Iterator<Integer> i = aggregate.iterator(); i.hasNext();) {
        System.out.println(i.next());
    }

    // forEachRemaining()
    aggregate.iterator().forEachRemaining(System.out::println);
}

Java StAX (Streaming API for XML)

XML 파일 포맷을 읽거나 만들때 사용하는 자바 라이브러리
콘솔 기반의 API, 이터레이터 기반의 API를 제공한다.
- 이터레이터 기반의 API : xml의 Element마다 이벤트가 지나가면서 캡쳐하며 그 영역을 표현하는 XMLEvent라는 인스턴스가 새로 만들고 이를 이용하는 방식이다. (XmlEventReader, XmlEventWriter)
- 콘솔 기반의 API : 하나의 인스턴스가 Element를 지나가면서 직접 안의 내용들을 변경하는 방식이다. 그래서 메모리는 이터레이터 기반보다 효율적이지만 재사용, 변경 측면에서는 좋지 않아 이터레이터 기반의 API를 사용하는 것이 권장된다.
비슷한 SAX(Simple API for XML)도 있지만, SAX는 XML을 읽기만 가능하다.

이터레이터 기반의 API 코드 예제는 다음과 같다.

<?xml version="1.0" encoding="UTF-8"?>
<books>
    <book title="오징어 게임"/>
    <book title="숨바꼭질"/>
    <book title="우리집에 왜 왔니"/>
</books>

public static void main(String[] args) throws FileNotFoundException, XMLStreamException {

    // 1. XMLEventReader 객체를 만드는 팩토리 객체를 얻는다.
    XMLInputFactory xmlInputFactory = XMLInputFactory.newInstance();

    // 2. XMLEventReader 객체를 만든다.
    XMLEventReader reader = xmlInputFactory.createXMLEventReader(new FileInputStream("book.xml"));

    // 3. 이터레이터 순회한다.
    while(reader.hasNext()) {
        // <books> 엘리먼트를 캡쳐하여 그 영역을 표현하는 XMLEvent 인스턴스를 생성
        XMLEvent nextEvent = reader.nextEvent();

        // 엘리먼트에 자식 엘리먼트가 있을 경우
        if(nextEvent.isStartElement()) {
            StartElement startElement = nextEvent.asStartElement(); // <book>
            QName name = startElement.getName();
            if(name.getLocalPart().equals("book")) {
                // 엘리먼트의 속성을 얻는다. <book title=""/>
                Attribute title = startElement.getAttributeByName(new QName("title"));
                System.out.println(title.getValue());
            }
        }
    }
}

Spring Framework

CompositeIterator

기존의 Interator에 add 기능만 하나 추가한 것
add() : 여러 Iterator들을 조합(Composite)해서 사용할 수 있다.

public class IteratorInSpring {
 
    public static void main(String[] args) {
        CompositeIterator iterator;
    }
}

# 참고자료

코딩으로 학습하는 GoF의 디자인 패턴 - 백기선

https://refactoring.guru/design-patterns/iterator

:before :after 에 text-decoration 효과 없애기

인파_ — Sun, 12 Mar 2023 11:47:43 +0900

의사 클래스 선택자에 밑줄 효과 지우기

무색무취한 ~~<a>~~ 링크 태그를 꾸미기 위해 ~~:before~~ 나 ~~:after~~ 에 아이콘을 넣는 경우가 종종 있다.

이때 anchor 태그의 밑줄 효과인 ~~text-decoration~~ 속성을 텍스트에만 적용하고 ~~content~~ 속성의 아이콘 표시 부분은 적용하고 싶지 않을때가 있을텐데, 아무리 의사 선택자에 ~~text-decoration~~ 속성을 ~~none~~으로 해도 밑줄이 지워지지 않은 현상 때문에 애로사항이 생겼을 것이다.

해결방법은 의사 선택자의 ~~display~~ 속성을 ~~inline-block~~ 으로 설정해주면 된다.

<a href="#">My link</a>

<a class="no-underline" href="#">My link</a>

a {
    text-decoration: underline;
}

a:before {
    content: "★";
}

a.no-underline:before {
    /* inline-block 설정하고 밑줄효과를 none으로 해주면 된다 */
    display: inline-block;
    text-decoration: none;
}

See the Pen :before에 text-decoration 없애기 by barzz12 (@inpaSkyrim) on CodePen.

텍스트 말줄임표(...) 간단 적용하기

인파_ — Sat, 11 Mar 2023 16:30:51 +0900

글자 ellipsis 적용하기

일정한 영역 내에 문단을 넘치지 않으면서 생략 기호를 쓰고 싶어 말줄임표(...)를 적용하고 싶다면, CSS 속성의 ~~text-overflow: ellipsis~~ 를 적용하면 된다. 다만 이 속성을 적용하기 위해선 몇가지 사전 작업이 꼭 필요하다.

적용할 해당 요소는 display 속성이 block / inline-block 이어야 한다 (그래야 width를 적용할수가 있다)
적용할 해당 요소는 width를 지정해주어야 한다. (그래야 넘치는 기준을 정하기 때문이다)
적용할 해당 요소는 overflow가 hidden 이어야 한다. (그래야 넘치는 부분이 가려지기 때문이다)
마지막으로 text-overflow를 ellipsis 로 처리하면 된다

싱글 라인 말줄임표 적용

.ellipsis {
    display: inline-block; /* 특정 너비를 가지도록 상황에 따라 block or inline-block 으로 변경 */
    width: 200px; /* inline-block처럼 콘텐츠에 따라 유동적인 너비를 가진다면 직접 너비를 설정 */
    overflow: hidden; /* 넘치는 부분 가리기 */
    text-overflow: ellipsis; /* ... 처리하기 */
    
    white-space: nowrap; /* 줄바꿈 안하기 (한 줄 밑줄임표 적용) */
}

멀티 라인 말줄임표 적용

만일 한줄 줄임이 아닌 여러 줄을 적용하고 어느 라인 기전에 말줄임을 적용하고 싶다면 특별한 속성을 사용하여야 한다.

.ellipsis-multi {
    display: block;
    width:22%;
    overflow:hidden;
    text-overflow:ellipsis;

	/* 여러 줄 밑줄임표 적용 */
    display: -webkit-box;
    -webkit-box-orient: vertical;
    -webkit-line-clamp: 3; /* 3번째 줄까지만 글자를 표현하고 그 이후는 줄임 처리 */
}

See the Pen text ellipsis by barzz12 (@inpaSkyrim) on CodePen.

️ 웹문서에 최적화된 독특한 HTML 태그 10가지

인파_ — Fri, 10 Mar 2023 07:46:07 +0900

figure & figcaption 태그

이 태그들은 이미지, 동영상 과 같은 멀티미디어 콘텐츠의 캡션 및 기타 메타데이터를 추가하는 방법을 제공한다. 물론 이미지, 동영상을 표현하는데 적합한 ~~<img>~~ , ~~<video~~> 태그들이 존재하지만, 이들을 ~~<figure>~~ 태그로 한번 더 감싸주면, 웹 페이지의 접근성과 검색 엔진 최적화가 개선된다고 한다. 멀티미디어 콘텐츠에 대한 컨텍스트 및 추가 정보를 제공하여 사용자가 이해하기 쉽고 검색 엔진이 웹 페이지를 색인화할 수 있기 때문이다.

~~<figcaption>~~ 태그는 소스에 대한 제목 또는 설명과 같은 추가 정보를 제공하는 캡션(caption)으로써, <figure> 태그 내부 하단에 배치된다.

<!-- 이미지에 대한 컨테이너 -->
<figure>
  <img src=https://bit.ly/2bgFrvL width="600px"/>
  <figcaption>World Map</figcaption> <!-- 이미지의 캡션을 정의 -->
</figure>

당장 이곳 티스토리 블로그도 개발자도구를 살펴보면 이미지를 포스팅에 표시할때 ~~<figure>~~ 엘리먼트를 사용한다는 걸 알 수 있다.

mark 태그

웹사이트의 해당 문구가 키워드 정보 제공용이고 핵심 사항을 강조하고 싶은 경우 사용되는 태그이다. 마치 우리가 책에서 중요한 문구를 강조하고 싶을때 형광펜으로 긋듯이 생각하면 된다.

~~<mark>~~ 태그를 사용하면 검색 엔진이 텍스트의 문맥과 관련성을 더 쉽게 이해할 수 있게 해주기 때문에 웹 페이지의 사용성과 접근성을 개선하는 데 도움이 될 수 있다.

<p>The quick <mark>brown fox</mark> jumps over the lazy dog.</p>

See the Pen Untitled by barzz12 (@inpaSkyrim) on CodePen.

abbr 태그

문서에 '약어' 기능을 추가할 수 있다. 사용자가 약어 위로 마우스를 가져가면 전체 형식이 표시되는 일종의 툴팁이라 보면 된다. 스크린 리더, 맞춤법 검사기 및 검색 엔진에 이점이 있다.

비슷한 약어 태그인 ~~<acronym>~~ 도 있지만 HTML5에서 지원되지 않으며 현재 사용되지 않는다

<p>
    마우스 커서를 
    <abbr title="안녕하세요 인파입니다 방문해주셔서 감사해요">고유명사</abbr> 
    에 올리면 설명 캡션이 생겨요!
</p>

See the Pen abbr 태그 by barzz12 (@inpaSkyrim) on CodePen.

del & ins 태그

흔히 글자 가운데 취소선을 긋기 위해 ~~<s>~~ 태그를 이용하지만 ~~<del>~~ 태그는 최신 시맨틱 태그로서 이것을 사용하기를 권장된다. 또한 ~~<ins>~~ 태그와 결합하면 단순 취소선 표시 뿐만 아니라 수정된 테스트를 옆에 강조 표시로 나타내게 할 수도 있다.

<p>Pluto <del>is</del> <ins>isn’t</ins> a planet.</p>

<p>John <del>likes</del> <ins>LOVES</ins> his new iPod.</p>

See the Pen del & ins 태그 by barzz12 (@inpaSkyrim) on CodePen.

ruby 태그

단어의 위나 옆에 배치되어 발음을 나타내는 작은 문자 또는 기호인 루비 주석을 만드는 데 사용되는 태그이다.

<p>
  The word 
  <ruby>안녕하세요<rt>annyeonghaseyo</rt></ruby> <!-- 글자 위에 작은 주석이 표시-->
  means "hello" in Korean
</p>

See the Pen ruby 태그 by barzz12 (@inpaSkyrim) on CodePen.

sup & sub 태그

문서에 위첨자(x²) 및 아래첨자 (x₀) 를 문서에 추가해준다. 일일히 특수기호를 뒤지지 말고 간단한 태그로 구현이 가능한 것이다.

<p>
  length<sup>2</sup> +
  width<sup>2</sup> =
  hypotenuseA<sup>2</sup>
</p>

See the Pen sub & sup by barzz12 (@inpaSkyrim) on CodePen.

wbr 태그

이 태그는 단어를 여러 줄로 나누는 위치를 나타내는 데 사용된다. 무슨 말이냐 하면, 가로폭을 줄일 경우 텍스트가 영역을 오버플로하여 레이아웃 문제를 일으켜 단어 중간에서 끊어져 읽기 어렵게 만드는데 이를 방지하는데 사용된다고 보면 된다. 요소 영역에 가로 스크롤 자체를 사용하지 않으려할때 유용히 쓰일 수 있다.

아래 예제 에서 텍스트 박스 크기를 줄이면서 링크 문자열의 단어 개행이 어떤식으로 되는지 확인해보자.

<p>
  아래 링크 문자열은 강제로 개행할 경우 텍스트가 단어 중간에서 끊어져 읽기 어려운 문제를 일으키기 때문에 이를 방지 하기 위해 적절하게 단어대로 개행하도록 한다
  <br><br>
  https://<wbr>www<wbr>.creativebloq<wbr>.com/
</p>
<!--
    강제로 개행해도 링크의 문자열이 단어 단위대로 끊어지도록 설정
    https://
    www
    .creativebloq
    .com/
-->

See the Pen object 태그 by barzz12 (@inpaSkyrim) on CodePen.

time 태그

이름 그대로 웹 페이지에 특정 날짜 및 시간 관련 정보를 표시하는 데 사용된다. ~~<time>~~ 태그를 명시해주면, 기계가 읽을 수 있는 형식 으로 시간과 날짜를 지정할 수 있으므로 검색 엔진이 더 쉽게 이해할 수 있는 장점이 있다.

사용법은 아래 코드와 같이 날짜를 표현하는 단어에 ~~<time>~~ 태그로 감싸주고 ~~datetime~~ 속성을 주어서 기계가 읽을 수 있는 형식을 지정한다. 이때 형식은 날짜 및 시간을 나타내는 표준화된 형식인 ISO 8601 표준이어야 한다. 그리고 사람이 읽을 수 있는 7월 7일 이라는 텍스트를 표현함으로써, 사람과 기계가 동시에 읽을 수 있는 time 표현을 문서에 그릴 수 있는 것이다.

<p>Posted: <time datetime="2020-07-07">7월 7일</time></p>

address 태그

왠만한 회사 웹사이트 하단(footer) 부분을 보면 이메일, 전화, 주소와 같은 비즈니스 정보를 기재해 둔다. 이때 무지성으로 ~~<div>~~ 태그로 표현하지말고 좀더 시맨틱(sematic)한 주소 전용 태그인 ~~<address>~~로 감싸 표현해주면 html에서 의미론적으로 주소를 마크업 해줘 좋다.

<address>    
   Written by <a href="mailto:info@rijsat.com">Rijwan Ansari</a>.<br>     
   Visit us at:<br>    
   RijSat.com<br>    
   Buddhanagar, Kathmandu<br>    
   Nepal    
</address>

번역 방지 속성

태그의 속성을 ~~translate="no"~~ 로 설정하면 번역 변환이 자동으로 방지된다. 회사나 브랜드 로고나 이름과 같은 단어를 번역하지 않으려는 경우에 유용하다.

<p translate="no">Brand name</p>

# 참고자료

https://javascript.plainenglish.io/9-unique-html-tags-you-need-to-know-5ceecfcf0095

https://blog.duda.co/8-cool-html-tags-you-didn-t-know-existed

CSS 선택자를 모던하게 :where() / :is() / :has() / :not()

인파_ — Thu, 9 Mar 2023 09:28:51 +0900

:where() 가상 선택자

~~:where~~ 의사 클래스 선택자는 css 코딩할때 선택자의 중복을 줄이는 데 도움이 되는 녀석이다.

예를들어 다음과 같이 여러 엘리먼트 안에 있는 anchor 태그에 hover 효과를 주기위해선 각 선택자들을 콤마를 이어 나열하여 표현하여야 했었다.

<nav>
  <ul>
    <a href="#">element 1</a>
  </ul>
</nav>

<footer>
  <ol>
    <a href="#">element 2</a>
  </ol>
</footer>

<aside>
  <p>
    <a href="#">element 3</a>
  </p>
</aside>

nav > ul a:hover,
footer > ol a:hover,
aside > p a:hover {
  color: purple;
  text-decoration: underline wavy deeppink;
}

그런데 코드를 보면 ~~a:hover~~ 부분이 각 선택자마다 중복되는 것을 확인 할 수 있을 것이다. 거기다 적용해야할 요소가 많으면 많을 수록 선택자의 양도 늘어나 나중에 가독성 및 유지보수도 힘들어지게 되며, 만일 쉼표로 이어진 이들 선택자중 하나가 잘못되면 전체가 적용되어지지 않는 문제점이 생기게 된다.

:where() 사용법

이때 ~~:where()~~ 선택자를 통해 보다 모던스럽게 css 코드를 구성할 수 있다. 불필요한 중복을 없애 코드 자체도 짧아지게 되고, 각 선택자를 개별적으로 분석하기 때문에 만일 잘못된 선택자가 있어도 이해가 안되면 그대로 버려버려 확장성도 좋다.

:where(nav > ul, footer > ol, aside > p) a:hover {
  color: purple;
  text-decoration: underline wavy deeppink;
}

See the Pen :where 선택자 by barzz12 (@inpaSkyrim) on CodePen.

이중 :where() 처리

좀 더 이 선택자의 강력한 효과를 확연히 느낄수 있게 좀 길다란 예시 코드를 가져와봤다.

다음 선택자들을 보면 section, article, aside, nav 선택자와 그의 자손인 h1 ~ h6 선택자가 반복되는 걸 볼 수 있다. 이를 이중 ~~:where()~~ 을 통해 획기적으로 줄일 수가 있다.

section h1, section h2, section h3, section h4, section h5, section h6, 
article h1, article h2, article h3, article h4, article h5, article h6, 
aside h1, aside h2, aside h3, aside h4, aside h5, aside h6, 
nav h1, nav h2, nav h3, nav h4, nav h5, nav h6 {
  color: #BADA55;
}

/* ↓ */

:where(section, article, aside, nav) :where(h1, h2, h3, h4, h5, h6) {
  color: #BADA55;
}

:where() 한계점

다만 ~~::before~~ 나 ~~::after~~ 와 같은 의사 요소는 DOM에 있는 요소가 아니므로 선택이 불가능해 묶을수 없다는 한계가 있다.

/* 동작하지 않음 */
a:where(::before, ::after) {
  ...
}

/* 어쩔수 없이 쉼표로 이어야 한다  */
a::before,
a::after {
  ...
}

:is() 가상 선택자

이 선택자는 위에서 배운 ~~:where~~ 선택자와 동일하게 동작된다.

단, 유일한 차이점은 명시도 에 있다. id 선택자는 다른 선택자보다 우선순위가 가장 높고, css 코드가 아래일 수록 우선순위가 적용된다고 들어본적이 있을 것인데 이것을 말하는 것이다. 즉, ~~:where()~~는 명시도가 0이지만 ~~:is()~~는 명시도가 가장 높다.

:where()와 :is() 차이점

아래 예제 코드를 보면 ~~<header>~~ , ~~<main>~~ , ~~<footer>~~ 안의 글자의 색을 스타일링 하려 한다. 이때 각각 ~~:where()~~ 와 ~~:is()~~ 로 글자색을 지정하고 css 마지막에 전체 선택자로 글자색을 녹색으로 덮어 씌웠다. 결과는 어떻게 될까?

<article>
  <h2>:where()</h2>
  <header class="where">
    <p>Section</p>
  </header>
  <main class="where">
    <p>Aside</p>
  <main/>
  <footer class="where">
    <p>Footer</p>
  </footer>
</article>

<article>
  <h2>:is()</h2>
  <header class="is">
    <p>Section</p>
  </header>
  <main class="is">
    <p>Aside</p>
  </main>
  <footer class="is">
    <p>Footer</p>
  </footer>
</article>

/* 맨 아래 정의된 선택자에 의해 무시된다 */
:where(header.where, main.where, footer.where) p {
  color: red;
}

/* 가장 명시도가 높아 밑에 뭐가 있던 무조건 적용된다 */
:is(header.is, main.is, footer.is) p {
  color: orange;
}

/* 전체 선택자 처리 */
header p,
main p,
footer p {
  color: green;
}

See the Pen :is() 선택자 by barzz12 (@inpaSkyrim) on CodePen.

~~:where()~~ 은 명시도가 0이기 때문에 css 마지막에 선언된 전체 선택자에 의해 효과가 덮어씌워졌다. 그러나 ~~:is()~~는 명시도가 높아 가장 높은 우선순위를 가지기 때문에 뒤에 뭐가 오든 무조건 해당 스타일로 적용되게 된다.

:not() 가상 선택자

이 선택자는 이름 그대로 ~~:not()~~ 괄호 안의 매개변수 요소를 제외한 모든 요소의 스타일을 지정하는 데 사용된다.

~~:not()~~ 을 이용하면 솔루션에 대해서 좀더 심플하게 해결책을 구성할 수 가 있는데, 예를 들어 다음 리스트 박스 마다 간격을 주기 위해 ~~margin-bottom~~을 설정하였다고 하자.

<div class="card">
  <ul>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
    <li>Item 4</li>
    <li>Item 5</li>
  </ul>
</div>

ul li {
  margin-bottom: 20px;
}

See the Pen :not 선택자 by barzz12 (@inpaSkyrim) on CodePen.

하지만 모든 리스트 하단에 margin이 들어가 박스가 대칭이 이루어지지 않는 문제점이 있다.

margin-top도 설정하는 법이나 강제로 li 요소 마지막은 margin을 설정하지 않도록 하는 방법도 있겠지만 좀더 심플하고 코드 한줄로 해결할 수가 있다.

/* li 요소 마지막은 적용하지 않는다 */
ul li:not(:last-of-type) {
  margin-bottom: 20px;
}

See the Pen Untitled by barzz12 (@inpaSkyrim) on CodePen.

이밖에도 이를 응용해 속성 선택자에서 지원안하는 != not equals 연산자 기능을 구현할 수도 있다.

[CSS] 속성 선택자 not equal 구현하기 [attr!=value]

Attribute Selector not equal 구현 CSS 속성(Attribute) 선택자 문법에는 equal 연산자와 함께 다양한 기호 문법을 지원한다. [attr=value] : attr 속성이 정확히 value인 요소를 선택 [attr~=value] : attr 속성이 정확히 v

inpa.tistory.com

:has() 가상 선택자

~~:has()~~ 는 최근에 추가된 선택자이다. 이 선택자는 해당 부모 선택자가 특정 자식 선택자를 가지고 있을 경우 적용하는 이른바 css의 if문 버전이라 보면 된다. 기존에는 이를 구현하려면 css로만은 문법적인 한계가 있어서 SCSS나 자바스크립트를 통해서만 가능했다. 하지만 ~~:has()~~ 개념은 굉장히 유용하고 편리한 선택자 개념이라 jQuery에서 제이쿼리 전용 선택자으로만 쓰였지만, 얼마전 드디어 공식화 되었다.

사용법은 예를들어 ~~div.parent~~ 가 만일 p 요소를 가지고 있는 경우에만 자신의 요소에 스타일을 적용하고 싶다면 다음과 같다.

<div class="parent">
  <p>Child</p>
</div>

/* div 요소가 자식으로 p를 가지고 있을 경우 스타일 적용 */
div:has(> p) {
  background: red;
}

:has() 선택자 조합 종류

~~:has()~~ 괄호 안 매개변수로 선택자 문법을 넣음으로써 자식, 형제, 자손 선택자를 다양한 폭으로 지정해줄 수 있다.

/* a 요소가 자손으로 img를 가지고 있을 경우 */
a:has(img) {
}

/* a 요소가 자식으로 img를 가지고 있을 경우 */
a:has(> img) {
}

/* h3 요소가 형제로 p를 가지고 있을 경우 */
h3:has(+ p) {
}

/* article 요소가 자손으로 h3 그리고 p를 가지고 있을 경우 (and 논리) */
article:has(h3, p) {
}

:has() 와 :not() 조합

이번엔 약간 난이도 높은 조합을 가져와 보았다. ~~:has()~~ 와 ~~:not()~~ 가상 요소를 어떤 순서대로 조합하느냐에 따라 논리적으로 완전히 달라지기 때문에, 어떻게 되는지 코드를 보고 추론해보자.

/* div 요소가 자손으로 h3을 가지고 있지 않을 경우 전체 칼라 적용 */
div.section1:not(:has(h3)) {
  color: red;
}

/* div 요소의 자손이 h3이 아닌 요소가 있을 경우 전체 칼라 적용 */
div.section2:has(:not(h3)) {
  color: blue;
}

See the Pen :has() 와 :not() 조합 by barzz12 (@inpaSkyrim) on CodePen.

자바스크립트 셀렉터 조합

~~:has()~~ 선택자는 스크립트로 동적으로 요소를 조작해야 할때 빛을 발한다.

예를들어 ~~div.parent~~ 가 만일 p 요소를 가지고 있는 경우에만 엘리먼트를 가져오고 싶다면, 기존에는 child 요소를 일일히 순회해서 탐색하며 분간해야 됬지만, 이 selector 하나로 곧바로 일치하는 요소를 가져올 수 있게 되었다.

<div class="parent">
  <input type="checkbox" />
  <p>Child</p>
</div>

<div class="parent">
  <input type="radio" />
  <p>Child</p>
</div>

<div class="parent">
  <p>Child</p>
</div>

document.querySelectorAll('.parent:has(p)')

/* 제이쿼리도 자체 지원한다. */
$('.parent:has(p)')

브라우저가 :has() 를 지원하는지 테스트

단, 최신 스펙인 만큼 아직 파이어폭스나 인터넷 익스플로러에서는 아직 사용할 수 없다는 단점이 있다.

만일 해당 브라우저가 이 선택자를 지원하는지 알아보고 우회 방법을 적용하고 싶다면 ~~@supports~~ 를 통해 구성해주면 된다.

@supports(selector(:has(p))) {
  /* Supported! */
}

@supports not (selector(:has(p))) {
  /* Not Supported! 우회코드 작성 */
}

[CSS] 최신 CSS 기능 지원여부 확인 @supports

@supports 최신 스펙의 css값을 사용할 때, 해당 css를 제공하는 브라우저에 따라 맞춤형으로 적용할 수 있게 css를 선언할 수 있다. 방법은 바로 @supports 문법(기능 쿼리, feature query)을 이용하는 것이

inpa.tistory.com

# 참고자료

https://junghan92.medium.com/%EB%B2%88%EC%97%AD-where-is-has-%EB%8B%B9%EC%8B%A0%EC%9D%98-%EC%82%B6%EC%9D%84-%EB%8D%94-%EC%89%BD%EA%B2%8C-%EB%A7%8C%EB%93%A4%EC%96%B4-%EC%A4%84-%EC%83%88%EB%A1%9C%EC%9A%B4-css-%EC%84%A0%ED%83%9D%EC%9E%90-ee44dd58aa3b

https://css-tricks.com/complete-guide-to-css-functions/

️ 스크립트 없이 구현 가능한 독특한 HTML 태그 9가지

인파_ — Wed, 8 Mar 2023 07:53:16 +0900

이번 포스팅은 HTML5을 배우는데 있어 접하지 못한 독특한 엘리먼트들을 소개해 보는 시간을 가져볼 것이다. 기존의 태그와 자바스크립트를 조합하여 힘들게 구현해야 하는 컴포넌트들을 태그 하나로만 구현할수 있어, 비록 아주 자주 사용될 녀석들이 아니지만 한번 쯤 훑어보고 존재 정도만 머리에 각인시키고 있다면, 추후에 도움이 될 것이다. 각 요소의 속성 상세 스펙은 MDN을 참고하면 된다.

progress 태그

progress 요소는 진행 정도를 나타내는 바를 만드는 태그이다. 주로 자신의 스킬 퍼센티지를 표기하거나 api 사용량을 표현하는데 자주 애용된다.

엘리먼트의 max 에 따른 value 속성값에 따라 bar의 게이지가 포함되는 원리이다.

<progress value="50" max="100"></progress>

See the Pen progress by barzz12 (@inpaSkyrim) on CodePen.

meter 태그

meter 태그는 progress 요소와 같이 진행 정도 바를 표현하지만, progress는 값의 상태만 전달 할 수 있는 것에 비해 meter은 속성에 따라 값이 높고 낮을때 색상을 다르게 설정하여 작업의 진행 상태를 세세하게 표현이 가능하다.

value, min, max, low, high, optimum 속성을 통해 진행정도에 따른 색상변경이 가능하다. 기본적으로 값의 포화도에 따라 초록색 → 노란색 → 빨간색으로 색상이 변경된다.

value : 현재 측정값 지정
min : 범위의 하한을 지정
max : 범위의 상한을 지정
low : 낮은 값 범위 지정
high : 높은 값 범위 지정
optimum : 최상의 또는 최적의 숫자 범위를 지정

<meter value="15" min="0" max="100" low="20" high="65" optimum="15" id="meter"></meter>

See the Pen meter by barzz12 (@inpaSkyrim) on CodePen.

map & area 태그

이미지맵을 만들 수 있는 엘리먼트이다. 이미지맵이란 이미지에 여러가지 클릭 가능한 영역을 말하는 것이다.

쉽게 예를 들어 각 국가별 코로나 발생 현황 사이트를 만든다고 했을때, 세계지도에 국가 영토 위치별로 해당 링크 요소를 이미지에 여러개 위치 시켜주고 싶을때 이용된다고 보면 된다. 바로 아래 예제를 통해 한눈에 이해할 수 있을 것이다.

<map name="continents_map">
  <area shape="circle" coords="70,70,10" href="#north_america"> <!-- 이미지의 좌표 70,70,10 에 링크를 표시 -->
  <area shape="circle" coords="133,185,10" href="#south_america">
  <area shape="circle" coords="270,137,10" href="#africa">
  <area shape="circle" coords="292,44,10" href="#europe">
  <area shape="circle" coords="469,201,10" href="#australia">
  <area shape="circle" coords="374,65,10" href="#asia">
  <area shape="circle" coords="340,267,10" href="#antartica">
</map>

<!-- usemap 속성을 통해 map & area 기능을 사용할 이미지를 상호작용한다 (continents_map) -->
<img usemap="#continents_map" src=https://bit.ly/2bgFrvL width="600px" />

See the Pen Image map by Preethi Sam (@rpsthecoder) on CodePen.

picture 태그

이미 ~~<img>~~ 태그로 이미지를 문서에 표현 해왔겠지만, ~~<picture>~~ 태그는 특정 화면 크기, 해상도에 따라 여러 이미지 지정이 가능하여, 개발자는 특정 화면 크기, 해상도 또는 기타 미디어 조건에 가장 적합한 이미지를 제공할 수 있다는 특징이 있다. 즉, 환경에 맞는 이미지를 다운로드 해서 보여줄 수 있으므로, 페이지 로딩 속도를 높일 수 있게 된다.

반응형 홈페이지의 경우 최적화를 위해 모바일 이미지와 PC화면의 이미지를 다르게 설정하여 모바일 사용자가 쓸데없이 큰 이미지를 다운로드 받지 않게 하기 위해 이용된다고 보면 된다.

아래와 같이 설정하면 각 media 사이즈에서 각 해당 이미지 보여주게 된다.

<picture>
    <source srcset="src/01.jpeg" media="(min-width:1200px)" type="image/jpeg"/>
    <source srcset="src/02.jpeg" media="(min-width:900px)" type="image/jpeg"/>
    <source srcset="src/03.jpeg" media="(min-width:500px)" type="image/jpeg"/>
    <img src="src/04.jpeg" />
</picture>

~~<picture>~~ 요소 내의 ~~<source>~~ 요소는 다양한 유형의 장치 또는 브라우저에 대해 다양한 버전의 이미지를 제공하는 데 사용된다
~~<source>~~ 요소의 ~~srcset~~ 속성은 이미지의 소스를 지정한다.
~~<source>~~ 요소의 ~~type~~ 속성은 이미지 유형을 지정한다.
마지막 ~~<img>~~ 요소는 만일 브라우저가 ~~<picture>~~ 요소를 지원하지 않는 경우에 대한 방지책으로 넣어준다.

detail & summary 태그

클릭으로 정보를 보여주고 숨기는 기능으로서, 일종의 '접은 글' 기능을 간단한 태그로만 구현하는 것으로 보면 된다. 원래 자바스크립트로 복잡하게 구현해야 될 사항을 이런식으로 별도의 엘리먼트로 공식 지원해주는 것이다.

~~<summary>~~ 태그 안에는 클릭 하기 전의 내용이 보여지게 되고, 클릭 시 펼쳐질 내용을 다음에 입력하면 된니다. css로는 ~~[open]~~ 이라는 CSS선택자를 통해 스타일 변경 가능 하다.

<details>
	<summary>클릭 전 볼 수 있는 영역</summary>
	<span>클릭 후에만 표시되는 영역</span>
</details>

details[open] {
	background-color: sky;
}

See the Pen Untitled by barzz12 (@inpaSkyrim) on CodePen.

input 태그 속성

달력 날짜 속성

input 태그의 type 속성으로 달력 및 일일, 주, 월별 그룹 지정도 가능하다. 브라우저 환경에 따라 달력 위젯의 형태는 달라질 수 있다

<input type="date"/>
<input type="week"/>
<input type="month"/>
<input type="time"/>

See the Pen 달력, 날짜 선택기 by barzz12 (@inpaSkyrim) on CodePen.

색상 선택기

만일 color picker 기능이 웹페이지에 필요하다면 무거운 라이브러리 없이 정말 간단하게 구현이 가능하다.

<input id="color_picker" type="color" onchange="showHex();"> 
<h1>COLOR ME !</h1>

function showHex(){
  document.querySelector("h1").style.color = document.querySelector("#color_picker").value;
}

See the Pen Untitled by barzz12 (@inpaSkyrim) on CodePen.

datalist 태그

자바스크립트 없이 auto complete(자동 완성 기능) 를 사용 가능하게 해주는 요소이다. 또한 타이핑에 따른 메뉴 필터 기능 제공한다.

사용법은 아래와 같은데 이때 유의해야 할점은, ~~<input>~~의 list 속성값과 ~~<datalist>~~의 id명을 똑같이 맞춰주어야 동작된다.

<!-- input의 list와 datalist의 id 명칭은 동일해야 된다 -->

<label for="movie">What is your favourite movie?</label>
<input type="text" list="movie-options"/>

<datalist id="movie-options">
  <option value="Dune"/>
  <option value="Dark waters"/>
  <option value="The Artist"/>
  <option value="The Avengers"/>
  <option value="Iron Man"/>
  <option value="Iron Man II"/>
  <option value="Matrix"/>
</datalist>

See the Pen datalist 태그 by barzz12 (@inpaSkyrim) on CodePen.

template 태그

동적으로 복잡한 엘리먼트 요소를 DOM에 삽입할때 보통 문자열 형태로 만들고 innerHTML이나 제이쿼리 함수로 삽입 할 것이다. 나쁘지 않은 방법이지만 문자열은 하이라이트도 안되서 가독이 좋지 않는 다는 한계점이 있다.

이를 극복하기 위해 아예 html에 ~~<template>~~ 태그로 감싸면 이 요소는 문서 표시가 아닌 템플릿용으로 취급되게 하는 템플릿 태그가 추가 되었다. 템플릿 요소 내부의 모든 콘텐츠는 비활성화되며 렌더링 되지 않는다.

예를 들어 아래 ~~<table>~~ 행을 버튼을 누르면 스크립트로 동적으로 추가하고 싶다면, <template> 요소를 자바스크립트로 호출하여 템플릿 태그 내부에서 마크업을 복사하고 테이블 마크업에 추가하는 식으로 구성 할 수 있다.

<table id="myTable">
    <tr>
        <th>Sl. No.</th>
        <th>Input</th>
    </tr>
    <tr>
        <td>1.</td>
        <td>
            <input type="text" />
        </td>
    </tr>
</table>

<!-- 버튼 클릭하면 자바스크립트 실행 -->
<input type="button" value="New Row" onclick="addRow()">

<!-- 테이블에 추가할 테이블 내부 템플릿 -->
<template id="rowTemplate">
    <tr>
        <td></td>
        <td>
            <input type="text" />
        </td>
    </tr>
</template>

function addRow() {
  // 템플릿 요소 가져오기
  const template = document.querySelector('#rowTemplate');
  
  // 템플릿을 추가할 요소 가져오기
  const tbl = document.querySelector('#myTable');
  
  // 템플릿의 content 속성과 그의 자식 모든 요소를 복사
  const clone = template.content.cloneNode(true); 
  
  // 기존 요소에 복사한 템플릿을 추가
  tbl.appendChild(clone);
}

See the Pen template 태그 by barzz12 (@inpaSkyrim) on CodePen.

optgroup 태그

선택 상자를 구현하기 위해 ~~<select>~~ 태그와 내부 리스트인 ~~<option>~~ 태그를 사용할 텐데, 이 리스트를 그룹으로 묶어 표현할때 사용된다. 예를 들어 영화 목록을 시간별로 그룹화해야 하는 경우 다음과 같이 구성될 수 있다.

<label for="showtimes">Showtimes</label>

<select id="showtimes" name="showtimes"> 
    <optgroup label="1PM">
        <option value="titanic">Twister</option> 
        <option value="nd">Napoleon Dynamite</option> 
        <option value="wab">What About Bob?</option> 
    </optgroup> 
    
    <optgroup label="2PM">
        <option value="bkrw">Be Kind Rewind</option> 
        <option value="stf">Stranger Than Fiction</option> 
    </optgroup> 
</select>

See the Pen optgroup 태그 by barzz12 (@inpaSkyrim) on CodePen.

# 참고자료

노마드 코더 - 개발자가 모르는 신박한 HTML 태그 5개

https://velog.io/@jiseon-han/%EC%8B%A0%EA%B8%B0%ED%95%9C-HTML-%ED%83%9C%EA%B7%B8-5%EA%B0%9C

브라우저 이미지 캐시 방지하기

인파_ — Tue, 7 Mar 2023 13:00:50 +0900

Disable Image Cache

웹페이지 속도 테스트나 혹은 이미지를 다루는 라이브러리 중에 이미지를 Ajax로 불러오다가 캐시에 의한 CORS 에러 문제 등 여러 이유들에 의해서 브라우저가 이미지를 캐싱 하지 않게 하고 싶은 때가 있을 것이다.

그러나 직접 서버에서 캐시 관련 헤더 설정을 할수 없거나 다른 업체의 서버를 사용하는 경우 결국 프론트단에서 처리해야 한다. ~~ctrl + F5~~ 강력 새로고침으로 임시적으로 해결할수는 있지만, 매번 이럴수도 없고 무슨 방법이 없을까 고민하겠지만 의외로 방법은 간단하다.

브라우저는 이미지를 완전히 같은 url 이름으로 불러들일때는 캐시한 이전 이미지를 불러온다. 이러한 특성을 이용하여 url의 쿼리스트링 값만 다르게 주는 것으로 캐시되지 않은 똑같은 이미지를 불러오도록 하는 편법을 쓸 수 있다.

예를들어 picture.jpg?1222259157 와 같이 이미지 url ? 뒤의 쿼리스트링 값을 랜덤으로 설정해줘서 할당해주면 된다. 쿼리스트링 값이 달라져도 가져오는 리소스는 동일하니 문제 없는 것이다.

아래는 자바스크립트로 현재 날짜 시간값을 쿼리 스트링으로 할당한 예제이다. 이외에도 랜덤 함수로도 구현할 수 있다.

document.querySelector('img').src = `https://이미지경로?${new Date().getTime()}`

리소스 캐시로 인한 CORS 에러 현상 고찰

인파_ — Mon, 6 Mar 2023 09:37:26 +0900

브라우저 캐시로 인한 CORS 문제

CORS(Cross-Origin Resource Sharing)는 서로 다른 출처(Origin)의 리소스를 공유하고 싶을때 사용하는 정책을 말한다.

기본적으로 브라우저는 SOP(Same Origin Policy) 정책을 따르기 때문에 외부 리소스에 대해서 차단한다. 하지만 인터넷은 여러 사람들에게 오픈된 환경이고, 이런 환경에서 웹페이지에서 다른 출처에 있는 리소스를 가져와 사용하는 일은 매우 흔한 일이라 모든 외부 리소스를 무턱대고 막으면 지금처럼 웹이 발전하지 않았을 것이다. 따라서 외부 리소스라도 허용 가능한 예외 사항을 두었는데 그것이 CORS 정책이다.

[WEB] 악명 높은 CORS 개념 & 해결법 - 정리 끝판왕

inpa.tistory.com

요청 방식에 따라 다른 CORS 발생 여부

이때 브라우저는 HTTP 요청에 대해서 어떤 방식으로 요청을 하느냐에 따라 CORS를 자동으로 허용하기도 막기도 한다. 예를들어 <img> 태그와 같은 인라인으로 리소스를 요청하면 다른 출처의 리소스라도 검사 없이 자동 통과된다. 그러나 자바스크립트 Ajax 요청일 경우 어김없이 차단되어 버린다.

요청 방식에 따라 다른 CORS 발생 여부를 좀 더 이해하기 쉽게 아래 html 코드를 직접 작성하고 테스트 해보자. 똑같은 서버 도메인으로 부터 check.svg 이미지를 가져오지만 결과는 다르게 된다.

※ 참고로 해당 호스팅 서버는 cors 설정이 되어있지 않는 서버라고 가정해보자.

<img src="https://third-party-test.glitch.me/check.svg" alt="이미지">

<script>
    fetch('https://third-party-test.glitch.me/check.svg')
        .then(response => response.blob())
        .then(imgBlob => {
            const imageObjectURL = URL.createObjectURL(imgBlob); // 응답 받은 이미지를 blob 객체로 변환
            const img = document.createElement('img'); // 이미지 태그를 생성하고
            img.src = imageObjectURL; // 이미지 경로를 설정한뒤
            document.body.append(img); // html에 추가
        })
</script>

페이지 결과를 보면 이미지가 하나만 나타나는 걸 볼 수 있을 것이다.

브라우저 개발자 도구의 Network 창을 보면 check.svg 이미지에 대해서 두번 요청은 했지만 자바스크립트 fetch Type으로 요청한 것이 Status가 CORS error 임을 볼수가 있다.

fetch 요청 처리에 대한 헤더 목록을 보면 그 이유를 알 수 있는데, 클라이언트가 자신의 Origin을 요청 헤더에 넣어 서버에 전달했지만, 서버에선 별다른 액션 없이 ~~Access-Control-Allow-Origin~~ 헤더를 응답해주지 않았고, 이를 브라우저가 감지하여 사단에 차단한 것이다. 여기서 오해하지 말아야 할 점이 서버는 리소스를 정상 응답했지만 브라우저가 cors 관련 헤더 없다고 차단해 버린 것이다.

반면 브라우저는 ~~<img>~~, ~~<video>~~ 와 같은 일부 미디어 태그를 통해 리소스를 요청할 CORS를 제한하지 않는다.그래서 HTTP 요청시 Origin 헤더를 추가하지 않고, 브라우저도 별다른 검사 없이 통과하게 해주는 것이다.

캐시에 저장된 리소스를 그대로 불러올 경우

그런데 이 CORS를 제한하지 않고 받은 리소스를 브라우저가 로컬 캐시에 저장하고 재활용 할 경우 문제가 발생하게 된다.

예를 들어 아래와 같이 이미지를 요청 할경우 문제없이 서버로 부터 외부 리소스를 받는다.

※ 참고로 해당 호스팅 서버는 cors 설정이 되어있는 서버이기 때문에 자바스크립트 ajax 요청에도 정상적으로 응답하게 된다.

<img src="https://tistory4.daumcdn.net/tistory/5927418/skin/images/sample.png" alt="이미지">

<script>
    fetch('https://tistory4.daumcdn.net/tistory/5927418/skin/images/sample.png', { mode: 'cors' })
        .then(response => response.blob())
        .then(imgBlob => {
            const imageObjectURL = URL.createObjectURL(imgBlob);
            const img = document.createElement('img');
            img.src = imageObjectURL;
            document.body.append(img);
        })
</script>

이번에는 자바스크립트 fetch 요청을 3초 뒤에 하라고 ~~setTimeout()~~ 메서드를 통해 설정해보자. 이렇게 하는 이유는 이미지 태그로 요청한 sample.png 이미지가 브라우저 로컬 캐시에 저장하도록 시간을 주기 위해서 이다. 그러면 3초 뒤에 똑같은 이미지 URL을 요청할 경우 브라우저는 자동으로 최적화를 위해 서버에 요청을 때리는 것이 아닌 캐시 저장소에서 리소스를 가져오게 된다.

<img src="https://tistory4.daumcdn.net/tistory/5927418/skin/images/sample.png" alt="이미지">

<script>
    setTimeout(() => {
        fetch('https://tistory4.daumcdn.net/tistory/5927418/skin/images/sample.png', { mode: 'cors' })
            .then(response => response.blob())
            .then(imgBlob => {
                const imageObjectURL = URL.createObjectURL(imgBlob);
                const img = document.createElement('img');
                img.src = imageObjectURL;
                document.body.append(img);
            })
    }, 3000);
</script>

그런데 결과는 CORS 에러가 뜬다. 분명 서버에서 모든 출처를 허용하는 access-control-allow-origin: * 헤더를 설정하였고, ~~setTimeout()~~ 메서드를 전 까지는 문제없이 잘 받아왔는데 말이다.

리소스에 대한 요청 / 응답 헤더를 보면 왜 그런지에 대한 유추가 가능하다.

앞서 말했듯이 ~~<img>~~ 태그로 불러오는 인라인 리소스 요청일 경우엔 요청 헤더에는 Origin 헤더가 없다. 따라서 서버에서도 Access-Control-Allow-Origin 헤더를 실어 보내지 않게되고, 이 상태 그대로 캐시에 적재되게 된다.

그리고 3초 뒤에 똑같은 리소스 URL을 요청했을때 캐시 저장소에 있는 리소스를 가져오는데, 응답 헤더에 ~~Access-Control-Allow-Origin~~ 헤더가 없기 때문에 아래와 같이 No ' Access-Control-Allow-Origin' header 라고 에러 메세지를 내뿜는 것이다.

캐시로 인한 CORS 에러 해결방법

crossorigin 속성 할당하여 강제 CORS 검사 행하기

해결 방법은 아래와 같이 ~~<img>~~ 태그의 속성으로 crossorigin 을 할당해 주면 된다.

<img crossorigin src="https://tistory4.daumcdn.net/tistory/5927418/skin/images/sample.png" alt="이미지">

<script>
    setTimeout(() => {
        fetch('https://tistory4.daumcdn.net/tistory/5927418/skin/images/sample.png', { mode: 'cors' })
            .then(response => response.blob())
            .then(imgBlob => {
                const imageObjectURL = URL.createObjectURL(imgBlob);
                const img = document.createElement('img');
                img.src = imageObjectURL;
                document.body.append(img);
            })
    }, 3000);
</script>

crossorigin 속성

~~<audio>~~ , ~~<img>~~ , ~~<link>~~ , ~~<script>~~ 및 ~~<video>~~ 와 같은 미디어 요소 의 crossorigin 속성은 요소가 교차 출처 요청을 처리하는 방법을 정의하는 속성이다. 보통은 클라이언트에서 쿠키나 인증 헤더를 실어 서버에 보낼때 사용되는 속성이지만, 이것을 태그 속성으로 명시하면 인라인 리소스 요청이든 뭐든 강제적으로 CORS 정책을 따르게 하여 리소스에 대한 엑세스 권한을 요청하게 한다.

개발자 도구의 헤더 목록을 보면 더 감이 잡힐 것이다. 비록 인라인 리소스 요청이지만 요청 헤더에 Origin 헤더가 담긴걸 볼 수 있고 서버도 이에 반응하여 cors 헤더를 응답함을 볼 수 가 있다.

따라서 3초 뒤에 행해지만 자바스크립트 Ajax 요청 역시 캐시에 리소스를 가져오더라도, 이미 캐시 저장소에 있는 리소스는 ~~Access-Control-Allow-Origin~~ 헤더가 설정된 리소스 이기 때문에 CORS 관문 검사에 통과되는 것이다.

crossorigin 속성이 있는데 서버 CORS 허용이 안될 경우

반대로 만일 서버에서 별다른 cors 헤더 설정을 하지 않았을 경우 ~~<img crossorigin src>~~ 인라인 요청도 결국 cors 에러 로그가 나타나게 된다. 왜냐하면 crossorigin 속성은 강제로 CORS 검사 관문을 행하기 때문이다.

정리하자면, 서버에 Origin 허용이 된 상태에서 동일한 리소스에 대한 중복 요청을 cors를 통해 가져올 경우 위의 엇갈림을 조심하면 된다. 또한 브라우저 로컬 캐시 뿐만 아니라 이밖에도 프록시(Proxy)나 CloudFront와 같은 CDN 서비스를 이용할때도 CORS 캐시 문제가 따라오게 된다. 보통 클라우드의 CDN 서비스일 경우 이러한 경우를 대비해 별도로 Cache Key 설정을 제공하니 이에 대해서 검색해보길 바란다.

마우스 wheel & scroll 이벤트 멈춤 감지하기

인파_ — Sun, 5 Mar 2023 13:27:33 +0900

마우스 휠 & 스크롤 멈춤 감지 방법

사용자가 문서를 스크롤 하면 이벤트를 발생시키는데, 스크롤을 멈추면 이를 감지하여 스크립트 처리를 하고 싶은 상황이 있을 것이다.

마우스 스크롤을 감지하는 이벤트는 두가지가 있는데, 문서를 스크롤하면 발생하는 'scroll' 이벤트와 그냥 마우스 가운데 휠 버튼을 내리면 발생하는 'wheel' 이벤트가 있다. 이 이벤트들에 ~~setTimeout()~~ 메서드와 조합해서 종단 지점을 감지하는 로직을 구현 할수가 있다.

let scrolling; // setTimeout() 메서드를 할당하는 전역 변수

window.addEventListener('scroll', (e) => {
    if (!scrolling) {
    	console.log('start scrolling!');
    }
    
    // 일정시간(250ms) 뒤에 스크롤 동작 멈춤을 감지
    clearTimeout(scrolling);
    scrolling = setTimeout(() => {
        console.log('stop scrolling!');
        
        scrolling = undefined;
    }, 250);
})

let wheeling; // setTimeout() 메서드를 할당하는 전역 변수

window.addEventListener('wheel', (e) => {
    if (!wheeling) {
    	console.log('start wheeling!');
    }

    // 일정시간(400ms) 뒤에 스크롤 동작 멈춤을 감지
    clearTimeout(wheeling);
    wheeling = setTimeout(() => {
        console.log('stop wheeling!');
        
        wheeling = undefined;
    }, 400);
})

'mousewheel'은 deprecated 된 구형 이벤트로서 최신 이벤트 스펙인 'wheel' 사용을 권장한다.

말풍선 디자인 자동 만들기 사이트

인파_ — Sat, 4 Mar 2023 16:12:43 +0900

말풍선 생성하기 사이트

간단하게 말풍선 스타일링을 바로 만들수 있는 제너레이터이다.

말풍선 꼬리표 위치(Side) 와 모양(Pointer triangle) 과 크기(Pointer size)를 지정해주고 옆의 css 코드를 붙여넣으면 완성된다.

<div class="speech-bubble">
	<h1>Bubbly</h1>
	<h2>CSS speech bubbles made easy!</h2>
</div>

Bubbly — CSS speech bubbles made easy

projects.verou.me