> For the complete documentation index, see [llms.txt](https://jaemedevs-organization.gitbook.io/frontend_study/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jaemedevs-organization.gitbook.io/frontend_study/book/functional-programming/ch2.md).

# Chapter 2: 현실에서의 함수형 사고

## 🍄 1. 토니 피자에 오신 것을 환영합니다.

* 때는 2118년, 미래 사람들도 여전히 피자를 좋아한다. 하지만 이제는 로봇이 피자를 만든다. 그리고 로봇은 자바스크립트로 프로그래밍 되어 있다.
* 피자 가게를 운영하는 토니는 로봇에 함수형 사고를 많이 사용했다. 토니 가게가 어떻게 돌아가고 있는지 또 주방과 재고 창고는 어떻게 운영되는지 살펴보고 두 개의 함수형 사고를 어떻게 적용했는지 알아보자.

## 🍄 2. 파트 |: 액션과 계산, 데이터

* 토니는 함수형 사고 중에 가장 먼저 액션과 계산 데이터를 구분하는 것부터 시작했다.
* 함수형 프로그래머는 가장 먼저 이 세 가지를 구부하는데 쉽게 다룰 수 있는 부분과 조심히 다뤄야 할 부분을 명확하게 하기 위함이다.
* 토니가 만든 코드를 액션, 계산, 데이터로 구분해보자.

### 🌻 2-1. 액션

* 액션은 호출 횟수와 시점에 의존하는 것이다.
* 오븐이나 배달차 같은 자원과 요리 재료를 사용하는 것은 액션이다. 액션은 사용할 때 조심해야 한다.
* 액션의 예시
  * 반죽 펴기
  * 피자 배달
  * 재료 주문

### 🌻 2-2. 계산

* 어떤 것을 결정하거나 계획하는 것은 계산이다.
* 계산은 실행해도 다른 곳에 영향을 주지 않는다.
* 계산은 아무 때나 사용해도 주방이 엉망진창 될 걱정이 없기 때문에 토니는 계산을 좋아한다.
* 계산의 예시
  * 조리법에 나온 것을 두 배로 만들기
  * 쇼핑 목록 결정

### 🌻 2-3. 데이터

* 토니는 변경 불가능한(immutable) 데이터를 가능한 한 많이 쓰려 한다.
* 결제, 재고, 피자 조리법과 같은 것이 데이터이다.
* 데이터는 유연하기 때문에 저장하거나 네트워크로 전송하는 등 다양하게 쓸 수 있다.
* 데이터의 예시
  * 고객 주문
  * 영수증
  * 조리법

## 🍄 3. 변경 가능성에 따라 코드 나누기(계층 설계 맛보기)

* 피자사업이 성장하면서 토니가 만든 소프트웨어도 사업에 맞춰 달라져야 했다. 토니는 코드를 변경할 때 드는 비용을 줄이기 위해 함수형 사고로 코드를 구성하면 좋다는 것을 알고 있었다.
* 먼저 변경 가능성에 따라 코드를 나눠보자. 위쪽으로 갈수록 자주 바뀌는 코드가 있고 아래쪽으로 갈수록 자주 바뀌지 않는 코드가 있는 그림을 그려보자.
* 어떤 코드가 어디에 위치하면 좋을까? 가장 분명한 것은 자바스크립트 언어 자체이다. 자바스크립트 언어는 잘 바뀌지 않는다. 그래서 가장 아래쪽에는 배열이나 객체같은 언어 기능을 놓는 것이 좋다. 그리고 가운데에는 바뀔 수도 있지만 자주 바뀌지 않는 피자 조리에 대한 것이 좋다. 마지막으로 가장 위쪽은 이번 주 메뉴와 같이 자주 바뀌는 사업적인 내용을 둔다.

| 피자 주방 레이어 | 창고 레이어 |
| --------- | ------ |
| 이번주 메뉴    |        |

* 이번주 특별 메뉴를 위한 조리법 | 이번 주 사야 할 것
* 재료를 어디서 구입할지 결정 | | 피자만들기
* 조리법 순서 | 재료 목록
* 재료 목록에 대한 동작 | | 자바스크립트
* 객체
* 배열 | 자바스크립트
* 객체
* 숫자 |
* 각 계층은 그 아래에 있는 계층을 기반으로 만들어진다. 그래서 각 계층에 있는 코드는 더 안정적인 기반 위에 작성할 수 있다. 이런 구조로 소프트웨어를 만들면 코드를 쉽게 변경할 수 있다.
* 가장 위에 있는 코드는 의존성이 거의 없기 때문에 쉽게 바꿀 수 있다. 아래에 있는 코드들은 위에 있는 코드보다 의존성이 많아 바꾸기 어렵지만 자주 바뀌지 않는다.
* 함수형 프로그래머는 이 아키텍처 패턴이 계층을 만들기 때문에 **계층형 설계**라고 부른다. 계층형 설계는 일반적으로 비즈니스 규칙, 도메인 규칙, 기술 스택 계층으로 나눈다.
* 계층형 설계로 만든 코드는 테스트, 재사용, 유지보수가 쉽다.

## 🍄 4. 파트 ||: 일급 추상(주방을 자동화하기)

* 토니의 주방에는 로봇이 혼자 일하고 있었기 때문에 얼마 지나지 않아 확장성 문제가 생겼다. 토니는 고객이 원하는 속도로 피자를 만들 수 없다. **타임라인 다이어그램**은 로봇 한 대가 피자를 만들기 위한 액션을들 보여준다.
* 치즈피자 만들기 타임라인
  1. 주문 접수
  2. 반죽 만들기
  3. 반죽 펴기
  4. 소스 만들기
  5. 소스 뿌리기
  6. 치즈 갈기
  7. 치즈 뿌리기
  8. 오븐에 넣기
  9. 10분 기다리기
  10. 서빙
* 타임라인에 있는 모든 단계는 액션이다.
* 타임라인 다이어그램을 사용하면 액션이 시간 순서에 따라 어떻게 실행되는지 볼 수 있다. 액션은 실행 시점에 의존하기 위해 실행순서가 중요하다.

## 🍄 5. 분산 시스템을 타임라인으로 시각화하기

* 토니가 로봇 한 대로 피자를 만들고 있다. 좋은 피자를 만들고 있지만 단 한 대의 로봇이 일을 차례대로 하고 있기 때문에 빠르지 않다. 토니는 피자 하나를 로봇 세 대가 함께 만들면 더 빠를 것이라고 생각했다.
* 여러 대의 로봇이 함께 일을 하는 것은 분산 시스템을 의미한다. 분산 시스템에서 독립된 액션의 실행 순서는 어떻게 될지 모른다.
* 로봇은 각자 타임라인을 가지고 있다.
* 치즈피자 만들기 타임라인
  1. 주문 접수
  2. 로봇 1
     1. 반죽 만들기
  3. 로봇 2
     1. 치즈 갈기
  4. 로봇 3
     1. 소스 만들기
     2. 반죽 펴기
     3. 소스 뿌리기
     4. 치즈 뿌리기
     5. 오븐에 넣기
     6. 10분 기다리기
     7. 서빙
* 이렇게 타임라인을 구성하게 되면 각각의 타임라인에서 처리되는 일 순서가 섞여 누가 먼저 끝날지 알 수 없다.
* 이런 타임라인 다이어그램으로 일을 진행할 경우 엉뚱한 피자가 만들어질 가능성이 있다.

## 🍄 6. 각각의 타임라인은 다른 순서로 실행된다.

* 기본적으로 타임라인은 서로 순서를 맞출 수 있는 기능이 없다.
* 다른 타임라인 작업이 끝날 때까지 기다리라는 표시가 없어서 순서대로 다음 단계를 그냥 진행한다. 서로 다른 타임라인에 있는 액션 간 실행 순서는 보장할 수 없다.
* 소스가 먼저 완성되고 반죽이 나중에 완성될 수도 있다. 이 경우 소스를 만드는 로봇은 반죽이 나오기 전에 반죽을 펴는 작업을 한다.
* 이러한 섞이는 순서는 총 여섯 가지 방법이 나오고 소스 만들기가 가장 마지막 순서에 와야 제대로 된 피자가 완성된다.
* 타임라인을 서로 맞추지 않은 분산 시스템은 예측 불가능한 순서로 실행된다.

## 🍄 7. 어려운 경험을 통해 분산 시스템에 대해 배운 것

* 순차적인 프로그램을 분산 시스템으로 바꾸는 것은 어렵다는 것을 알았다. 올바른 순서로 동작하는 프로그램을 만들려면 액션에 집중할 필요가 있다는 것도 알았다.

### 🌻 1. 기본적으로 타임라인은 서로 순서를 맞추지 않는다.

* 반죽이 준비되지 않았는데도 다른 타임라인은 그냥 진행되었다. 타임라인은 서로 실행 순서를 맞춰야 한다.

### 🌻 2. 액션이 실행되는 시간은 중요하지 않다.

* 일반적으로 소스 만드는 것이 제일 오래 걸리는 작업이지만 항상 그렇지는 않다. 그래서 각각의 타임라인은 다른 타임라인의 순서와 관계없이 만들어야 한다.

### 🌻 3. 드물지만 타이밍이 어긋나는 경우는 실제로 일어난다.

* 테스트할 때는 없었지만 실제 서비스에서는 문제가 생겼다. 저녁에 주문이 많이 들어오면 가끔 발생하던 오류는 더 많이 발생한다. 타임라인은 항상 옳바른 결과를 보장해야 한다.

### 🌻 4. 타임라인 다어어그램으로 시스템의 문제를 알 수 있다.

* 다이어그램을 보고 치즈가 제 시간에 준비되지 않을 수 있다는 것을 알았다. 시스템을 잘 이해하기 위해 타임라인 다이어그램을 계속 쓰기로 했다.

## 🍄 8. 타임라인 커팅: 로봇이 서로를 기다릴 수 있게 하기

* 토니는 타임라인 **커팅**이라고 부른 기술을 쓰려고 한다.
* 타임라인 커팅은 여러 타임라인이 동시에 진행될 때 서로 순서를 맞추는 방법이다.
* 타임라인 커팅은 **고차 동작**으로 구현한다.
* 고차 동작이란 고차 함수로 만든 동작을 말한다.
* 각 타임라인은 독립적으로 동작하고 작업이 완료되면 다른 타임라인 끝나기를 기다리기 때문에 어떤 타임라인이 먼저 끝나도 괜찮다.
* 서로 순서를 맞춘 로봇 세대
  1. 주문 접수
     * 로봇 1
       * 반죽 만들기
     * 로봇 2
       * 치즈 갈기
     * 로봇 3
       * 소스 만들기
  2. 로봇 1,2,3 의 모든 작업이 끝날때까지 진행 X
  3. 반죽펴기
  4. 소스 뿌리기
  5. 치즈 뿌리기
  6. 오븐에 넣기
  7. 10분 기다리기
  8. 서빙
* 이렇게 타임라인의 시간을 맞추는 작업을 **커팅**이라고 부른다.

## 🍄 9. 좋은 경험을 통해 타임라인에 대해 배운 것

### 🌻 1. 타임라인 커팅으로 서로 다른 작업들을 쉽게 이해할 수 있다.

* 타임라인에 컷을 그려 동시에 할 수 있는 재료 준비와 순서대로 해야 하는 피자 만들기를 분리했다. 타임라인 커팅으로 더 짧아진 타임라인을 실행 순서에 상관없이 이해할 수 있다.

### 🌻 2. 타임라인 다이어그램을 사용하면 시간에 따라 진행하는 작업을 쉽게 이해할 수 있다.

* 타임라인은 동시에 실행되는 분산 시스템을 시각화하기 좋다.

### 🌻 3. 타임라인 다이어그램은 유연하다.

* 타임라인을 보고 쉽게 코드로 옮길 수 있다.
* 타임라인 다엉그램으로 동시에 진행되는 작업을 쉽게 모델링할 수 있다.

## 🍄 10. 정리

* 액션과 계산, 데이터를 구분하는 일은 함수형 프로그래머에게 가장 중요하고 첫 번째로 해야 하는 일이다.
* 함수형 프로그래머는 유지보수를 잘 하기 위해 계층형 설계를 사용한다. 각 계층은 코드의 변경 가능성에 따라 나눈다.
* 타임라인 다이어그램은 시간에 따라 변하는 액션을 시각화 하는 방법이다. 타임라인 다이어그램으로 액션이 다른 액션과 어떻게 연결되는지 볼 수 있다.
* 액션 간 협력을 위해 타임라인 커팅이라는 기술을 살펴봤다. 타임라인 커팅은 액션이 올바른 순서로 실행할 수 있도록 보장한다.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://jaemedevs-organization.gitbook.io/frontend_study/book/functional-programming/ch2.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.