TimeMixer 최신 시계열 예측 모델 탐구하기




기계 학습의 기본 주제 중 일부가 여전히 연구자들에게 알려지지 않은 점은 놀랍습니다. 이러한 주제들은 기본적이고 흔히 사용되지만 여전히 신비로운 측면이 있다고 생각됩니다. 기계 학습에 대한 재미있는 점은 우리가 작동하는 것들을 만들고 나서 그것들이 왜 작동하는지 파악하는 것입니다!

여기서 저는 몇 가지 기계 학습 개념의 미지 영역을 조사하여, 이러한 아이디어가 기본적으로 보일지라도 사실은 여러 겹의 추상화로 이루어진 것임을 보여줍니다. 이는 우리가 지식의 깊이를 의심하는 연습을 할 수 있도록 도와줍니다.

이 글에서 우리는 신경망의 전통적인 이해를 도전하는 딥러닝의 중요한 현상 몇 가지를 탐구합니다.

- 먼저, 완전히 이해되지 않은 배치 정규화와 그 기본 메커니즘에 대해 알아봅니다.
- 우리는 과잉 매개변수 모델이 일반화를 더 잘 하는 상반된 기술적 기계 학습 이론에 반하는 현상을 검토합니다.
- 그래디언트 하강의 암묵적인 정규화 효과를 탐구하며, 신경망을 보다 단순하고 보다 포괄적인 솔루션으로 자연스럽게 편향시키는 것 같습니다.
- 마지막으로, 대규모 신경망에 작은 부분 네트워크를 포함하고 있는 복권 티켓 가설에 대해 언급해 봅니다. 이 가설에 따르면 훈련을 독립적으로 받을 때 비슷한 성능을 달성할 수 있는 더 작은 부분 네트워크를 포함하고 있습니다.

<div class="content-ad"></div>

이 기사에는 4부분이 포함되어 있습니다. 그들은 서로 연결되어 있지 않기 때문에 원하는 부분으로 건너뛰어 읽어도 괜찮아요.

- 1. 배치 정규화
   - 우리가 이해하지 못하는 부분
   - 배치 정규화 고려 사항
- 2. 오버파라미터화와 일반화
   - 심층 학습의 이해는 일반화에 대한 재고가 필요합니다.
- 3. 신경망의 암묵적인 정규화
   - 실험 1
   - 실험 2
   - 경사 하강법은 자연 정규화기로 작용합니다.
- 4. 복권 티켓 가설
- 마지막으로.
   - 연락해요!
- 더 많은 읽을거리
- 참고 문헌

# 1. 배치 정규화

2015년 Sergey Ioffe와 Christian Szegedy에 의해 소개된 배치 정규화는 신경망을 더 빠르고 안정적으로 훈련시키기 위한 방법입니다. 이전에 입력 데이터를 평균이 0이고 분산이 1이 되도록 변환하면 수렴 속도가 더 빨라진다는 것이 알려져 있었습니다. 저자들은 이 아이디어를 더 발전시켜 입력층의 입력을 평균이 0이고 분산이 1인 것으로 변환하는 Batch Normalization을 소개했습니다.

<div class="content-ad"></div>

<img src="/assets/img/2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_0.png" />

배치 정규화는 신경망에서 일반적으로 사용되는 기능으로 자리를 잡았습니다. 그 중 한 가지 예가 유명한 ResNet 구조에서 사용되는 것입니다. 따라서 우리는 그 효과를 확신할 만큼 효과적일 수 있다고 말할 수 있습니다.

배치 정규화의 효과에 대한 흥미로운 연구 [2]는 전체 ResNet-866 네트워크를 학습할 때 93%의 정확도가 나왔지만, 모든 파라미터를 동결하고 배치 정규화 계층의 파라미터만 학습할 때 83%의 정확도를 얻었다는 것을 보여줍니다. 이는 단지 10%의 차이입니다.

배치 정규화는 세 가지 측면에서 이점이 있습니다:

<div class="content-ad"></div>

- 각 레이어의 입력을 정규화함으로써 학습 과정이 가속화됩니다.
- 초기 조건에 대한 민감도가 감소하여 조심스러운 가중치 초기화가 덜 필요합니다.
- 배치 정규화는 정규화기 역할도 합니다. 모델의 일반화를 향상시키고 경우에 따라 다른 정규화 기술이 필요하지 않을 수도 있습니다.

## 이해하지 못하는 부분

배치 정규화의 긍정적인 효과는 명백하지만, 누구도 그 효과적인 이유를 완전히 이해하고 있지는 않습니다. 배치 정규화 논문의 저자들은 배치 정규화를 내부 치프트 문제를 해결하기 위한 방법으로 소개했습니다.

내부 치프트에 대한 사전 경고는 처음에 상관없어 보이는 다양한 정의를 발견할 수 있다는 것입니다. 제가 정의하려는 방식을 여기에 나타내었습니다.

<div class="content-ad"></div>

신경망의 계층은 완료(출력 계층)에서 시작(입력 계층)으로 역전파 중 업데이트됩니다. 내부 공변량 변화는 이전 계층의 매개변수가 업데이트됨에 따라 해당 계층의 입력 분포가 훈련 중 변경되는 현상을 가리킵니다.

내부 공변량 변화는 훈련 속도를 늦추고 네트워크가 수렴하기 어렵게 만들며, 각 계층은 이전 계층의 업데이트로 인해 입력 분포의 변화에 지속적으로 적응해야 합니다.

원래 배치 정규화 논문의 저자들은 배치 정규화의 효과를 내부 공변량 변화 문제를 완화시키는 데 있다고 믿었습니다. 그러나 나중에 나온 다른 논문은 배치 정규화의 성공은 내부 공변량 변화와 무관하며 최적화 Landscape를 부드럽게 만듦으로써 성공했다고 주장했습니다.

![image](/assets/img/2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_1.png)

<div class="content-ad"></div>

위의 그림은 Batch Normalization에 대해 실제로 다루지는 않지만 매끄러운 손실 지형이 어떻게 보이는지 잘 시각화한 것입니다. 그러나 Batch Norm이 효과적인 이유가 손실 지형을 매끄럽게 만드는 데 있다는 이론에는 고민과 의문이 있습니다.

## Batch Norm 고려 사항

Batch Normalization이 어떻게 작동하는지에 대한 우리의 이해가 제한되어 있기 때문에 네트워크에 사용할 때 고려해야 할 사항은 다음과 같습니다:

- Batch Norm을 사용할 때 학습 및 추론 모드 간에 차이가 있습니다. 잘못된 모드 사용은 예상치 못한 동작을 일으킬 수 있으며 이를 식별하기 어려울 수 있습니다. [5]
- Batch Norm은 미니배치의 크기에 많이 의존합니다. 따라서 자세한 가중치 초기화가 덜 중요해지지만 올바른 미니배치 크기를 선택하는 것이 더 중요해집니다. [5]
- 활성화 함수 이전에 Batch Norm을 사용할지 또는 이후에 사용할지에 대해 여전히 논쟁이 진행 중입니다. [6]
- Batch Norm은 정규화 효과가 있지만, 드롭아웃이나 가중치 감쇠와 같은 다른 정규화와의 상호 작용은 명확히 알려지지 않았습니다.

<div class="content-ad"></div>

Batch Norms에 대한 많은 질문이 있지만, 이러한 레이어가 신경망에 어떤 영향을 미치는지 밝히기 위한 연구는 아직 진행 중입니다.

# 2. 초매개변수화(Over-Parameterization)와 일반화(Generalization)

![이미지](/assets/img/2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_2.png)

큰 네트워크들은 예전의 우리의 신경망 동작에 대한 믿음을 도전해왔습니다.

<div class="content-ad"></div>

과거에는 과도한 매개 변수가 사용된 모델을 사용하면 오버피팅될 것으로 전통적으로 믿어졌습니다. 따라서 해결 방법은 네트워크의 크기를 제한하거나 훈련 데이터의 오버피팅을 방지하기 위해 정규화를 추가하는 것이었습니다.

놀랍게도, 신경망의 경우 더 큰 네트워크를 사용할수록 일반화 오차(|훈련 오류 - 테스트 오류|)가 개선될 수 있습니다. 다시 말해, 더 큰 네트워크가 더 잘 일반화됩니다. 이는 예를 들어 VC dimension과 같은 전통적인 복잡성 지표들이 약속했던 것과 모순됩니다.

이 이론은 또한 딥 신경망이 훈련 데이터를 기억하거나 패턴을 학습함으로써 성능을 달성하는지 여부에 대한 논쟁을 제기합니다. 데이터를 기억한다면, 어떻게 보이지 않는 데이터를 예측하기 위해 일반화할 수 있을까요? 그리고 데이터를 기억하지 않고 단지 근본적인 패턴을 학습한다면, 라벨에 일정량의 노이즈를 추가하더라도 올바른 라벨을 예측하는 방법은 무엇일까요?

![What We Still Don't Understand About Machine Learning 3](/assets/img/2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_3.png)

<div class="content-ad"></div>

## 딥 러닝을 이해하려면 Generalization에 대해 다시 생각해야 합니다

이 주제에 대한 흥미로운 논문은 'Understanding deep learning requires rethinking generalization' [10] 입니다. 저자들은 전통적인 방식이 왜 더 큰 네트워크가 잘 일반화되며, 동시에 이러한 네트워크는 심지어 무작위 데이터에도 맞출 수 있는지 설명하지 못하는 것으로 주장합니다.

이 논문의 주목할 만한 부분 중 하나는 명시적 정규화인 weight decay, dropout 및 데이터 증가가 일반화 오차에 미치는 역할을 설명합니다:

Dropout 및 weight decay를 적용해도 InceptionV3는 여전히 무작위로 생성된 훈련 세트에 예상을 뛰어넘는 결과를 보였습니다. 이는 정규화를 가치 없게 하려는 것이 아니라, 모델 구조를 변경함으로써 더 큰 이득을 얻을 수 있다는 점을 강조하기 위한 것입니다.

<div class="content-ad"></div>


![그림](/assets/img/2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_4.png)

그렇다면 일반화가 잘되는 신경망은 어떻게 구별될까요? 정체가 되지 않는 것 같네요. 몇 가지를 다시 생각해야 할 것 같습니다:

- 모델의 유효 용량에 대한 이해
- 모델의 복잡성과 크기를 측정하는 방법. 모델 파라미터나 FLOPs가 좋은 지표인가요? 분명히 아닙니다.
- 일반화의 정의와 측정 방법.

![그림](/assets/img/2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_5.png)


<div class="content-ad"></div>

커다란 네트워크와 매개변수 개수가 일반화에 미치는 영향에 대해 다수의 논문과 블로그 포스트를 찾을 수 있습니다. 때로는 서로 모순되기도 합니다.

현재 우리가 이해한 바에 따르면, 더 큰 네트워크는 오버피팅되기 쉽지만, 깊이 덕분에 얕은 네트워크와 비교했을 때 더 복잡한 패턴을 학습할 수 있어 일반화가 잘 될 수 있습니다. 이는 대부분 도메인에 따라 다릅니다. 특정 데이터 유형은 작은 모델로부터 이점을 얻을 수 있으며 Occam의 면도날 원리를 따른 것일 수도 있습니다 (자세한 내용은 아래 게시물을 참고해주세요👇).

# 3. 신경망의 내재적 정규화

머신러닝의 핵심에는 Gradient Descent가 있습니다. Gradient Descent(GD)와 Stochastic Gradient Descent(SGD)는 머신러닝을 처음 시작하는 사람들에게 소화하기 쉬운 첫 번째 방법 중 하나입니다.

<div class="content-ad"></div>

알고리즘은 직관적으로 보이기 때문에 그 깊이가 많지 않을 것으로 예상할 수 있습니다. 그러나 기계 학습에서는 수영장의 버튼을 결코 찾을 수 없습니다.

신경망은 경사 하강법에 의한 내재적 규제로 인해 더 간단하고 일반적인 해결책을 찾도록 밀어낼 수 있을까요? 이전 부분에서 보여진 것처럼 초매개변수화된 네트워크가 일반화하는 이유가 될 수 있을까요?

![image](https://miro.medium.com/v2/resize:fit:1400/1*wDDffJESony5N7BvGdi-iw.gif)

주의해야 할 두 가지 실험이 있습니다.

<div class="content-ad"></div>

## 실험 1

[11]에서의 저자들이 CIFAR-10과 MNIST 데이터셋을 사용하여 SGD와 명시적 규제 없이 모델을 훈련시킨 결과, 네트워크의 크기가 증가할수록 테스트 및 훈련 오차가 계속 감소한다는 결론을 이끌었습니다. 이는 더 큰 네트워크가 오버피팅으로 인해 더 높은 테스트 오차를 가진다는 믿음과는 반대됩니다. 더 많은 매개변수를 네트워크에 추가해도 일반화 오차가 증가하지 않습니다. 그런 다음 네트워크에 임의의 라벨 노이즈를 추가하여 네트워크가 오버피팅하도록 만들었습니다. 아래 그림에서 확인할 수 있듯이, 5%의 임의 라벨을 추가해도 테스트 오차가 더욱 감소하며 오버피팅의 현저한 징후가 없습니다.

<img src="/assets/img/2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_6.png" />

## 실험 2

<div class="content-ad"></div>

중요한 논문인 “In Search of the Real Inductive Bias [12]”에서는 선형 분리 가능한 데이터셋을 사용하여 예측기를 맞추는 실험을 진행했습니다. 저자들은 로지스틱 회귀를 사용하여 경사 하강법과 규제 없이 최대 여백 분리자(하드 마진 SVM으로도 알려짐) 방향으로 솔루션을 편향시키는 것을 보여주었습니다. 이는 경사 하강법의 흥미로운 그리고 놀라운 행동입니다. 손실 및 최적화가 마진 최대화를 장려하는 용어와 관련이 없다는 점에서 지지 벡터 머신에서 발견되는 것과 같은 용어와 직접적으로 관련이 없기 때문에 경사 하강법은 자연적으로 최대 여백 분류기 방향으로 솔루션을 편향시킵니다.

![2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_7.png](/assets/img/2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_7.png)

## 경사 하강법은 자연적인 정규화 방법

이 실험들은 최적화 과정이 더 간단하고 안정적인 솔루션을 선호하는 암묵적인 정규화 효과를 시사합니다. 이는 GD가 더 간단한 모델을 선호하며 종종 "플랫" 최소값이라고 하는 특별한 종류의 로컬 최소값으로 수렴하며, 이는 더 낮은 일반화 오류를 가진 경우가 많습니다. 이것은 왜 딥 러닝 모델이 종종 훈련 데이터 이상의 실제 작업에서 성능이 우수한지 설명해주는데 도움이 됩니다. 이것은 최적화 과정 자체가 암묵적인 정규화의 형태로 간주될 수 있음을 시사하며, 훈련 데이터에서 오류가 적은 모델을 생성할 뿐만 아니라 보이지 않는 데이터를 예측하는 데 강건한 모델을 만들어냅니다. 전체적인 이론적 설명은 아직 활발한 연구 분야입니다.

<div class="content-ad"></div>

아마도 이 기사도 흥미로울 수 있을 거에요. 깊은 신경망이 현실의 통합된 표현으로 수렴하는 이유와 방법에 대해 말이죠:

## 4. 복권티켓 가설

모델 가지치기(pruning)는 훈련된 신경망의 매개변수를 90% 줄일 수 있습니다. 제대로 수행하면 정확도가 줄지 않은 채 이를 달성할 수 있어요. 다만, 모델을 가지치기할 수 있는 시점은 훈련 이후뿐이에요. 만약 불필요한 매개변수를 훈련 전에 제거할 수 있다면, 훨씬 적은 시간과 자원을 사용해도 된다는 뜻이죠.

복권티켓 가설[13]은 신경망에는 제대로 훈련되었을 때 원래 신경망과 비교 가능한 테스트 정확도에 도달할 수 있는 하위 신경망들이 포함되어 있다고 말해요. 이 하위 신경망들인 복권티켓은 초기 가중치가 그들의 훈련을 성공시키는 요인이라고 합니다.

<div class="content-ad"></div>

저자들은 이러한 서브네트워크를 반복적인 가지치기 방법을 통해 찾습니다:

- 네트워크 훈련: 먼저, 원래 가지치기되지 않은 네트워크를 훈련합니다.
- 가지치기: 훈련 후, 가중치의 p%를 가지칩니다.
- 가중치 초기화: 남은 가중치는 초기 초기화 값으로 설정됩니다.
- 재훈련: 가지친 네트워크를 재훈련하여 이전 네트워크보다 동일하거나 더 높은 성능을 달성할 수 있는지 확인합니다.
- 반복: 원래 네트워크의 희박성이 원하는 수준에 도달하거나 가지친 네트워크가 더 이상 가지치기되지 않은 네트워크의 성능을 따라갈 수 없을 때까지 이 프로세스를 반복합니다.

![이미지](/assets/img/2024-07-30-WhatWeStillDontUnderstandAboutMachineLearning_8.png)

제안된 반복적 훈련 방법은 계산 비용이 많이 소요되며, 다수의 실험에서 네트워크를 15번 이상 훈련해야 합니다.

<div class="content-ad"></div>

신경망에서 이러한 현상이 발생하는 이유는 아직 연구 중인 분야입니다. SGD가 네트워크를 훈련할 때 이기는 티켓에만 초점을 맞추고 네트워크 전체에는 주의를 기울이지 않을 수도 있을까요? 왜 일부 랜덤 초기화에는 이렇게 효과적인 하위 네트워크가 포함되어 있을까요? 이 이론을 깊이 있게 탐구하려면 [13]과 [14]를 놓치지 마세요.

# 마지막으로

기사를 읽어주셔서 감사합니다! 가능한 정확한 내용을 제공하기 위해 최선을 다해 노력했지만 필요한 수정 사항이 있다면 의견과 제안을 공유해 주세요.

## 함께 소통합시다!

<div class="content-ad"></div>

무료로 구독하시면 새 기사 알림을 받을 수 있습니다! 또한 LinkedIn과 Twitter에서도 저를 만날 수 있어요.

# 더 읽어볼 거리

지금까지 읽으신 분들께는 아래 기사들도 흥미롭게 느껴질 수 있어요:

# 참고 문헌

<div class="content-ad"></div>

1. Ioffe, S., & Szegedy, C. (2015). Batch Normalization: Accelerating Deep Network Training by Reducing Internal Covariate Shift. arXiv.

2. Outside the Norm, DeepLearning.AI

3. Santurkar, Shibani; Tsipras, Dimitris; Ilyas, Andrew; Madry, Aleksander (29 May 2018). “How Does Batch Normalization Help Optimization?”. arXiv:1805.11604

4. Li, H., Xu, Z., Taylor, G., Studer, C., & Goldstein, T. (2018). Visualizing the Loss Landscape of Neural Nets. arXiv

<div class="content-ad"></div>

| 5 | On The Perils of Batch Norm                                              |
| 6 | [Link to Tweet](https://x.com/svpino/status/1588501331316121601)       |
| 7 | Neyshabur, B., Li, Z., Bhojanapalli, S., LeCun, Y., & Srebro, N. (2018). Towards Understanding the Role of Over-Parametrization in Generalization of Neural Networks. arXiv. |
| 8 | Why is deep learning hyped despite bad VC dimension?                   |

<div class="content-ad"></div>

[9] DEEP NETS DON’T LEARN VIA MEMORIZATION

[10] Zhang, C., Bengio, S., Hardt, M., Recht, B., & Vinyals, O. (2017). Understanding Deep Learning Requires Rethinking Generalization. arXiv:1611.03530

[11] Neyshabur, B., Tomioka, R., & Srebro, N. (2015). In Search of the Real Inductive Bias: On the Role of Implicit Regularization in Deep Learning. arXiv:1412.6614

[12] Soudry, D., Hoffer, E., Nacson, M. S., Gunasekar, S., & Srebro, N. (2017). The Implicit Bias of Gradient Descent on Separable Data. arXiv:1710.10345

<div class="content-ad"></div>

[13] Frankle, J., & Carbin, M. (2019). The Lottery Ticket Hypothesis: Finding Sparse, Trainable Neural Networks. arXiv:1803.03635

[14] [https://www.lesswrong.com/posts/Z7R6jFjce3J2Ryj44/exploring-the-lottery-ticket-hypothesis](https://www.lesswrong.com/posts/Z7R6jFjce3J2Ryj44/exploring-the-lottery-ticket-hypothesis)

우리가 아직 이해하지 못하고 있는 머신 러닝의 5가지 장점




Node.js 내부에 대한 심층 탐구를 계속할 것을 환영합니다! 이 게시물에서는 Node.js 뒤의 강력한 엔진인 V8 엔진을 살펴보겠습니다. 이 엔진은 놀라운 속도와 효율성으로 JavaScript 코드를 실행합니다. V8의 아키텍처를 이해하고 JavaScript 실행을 최적화하는 방법은 보다 효율적인 Node.js 애플리케이션을 작성하는 데 도움이 될 수 있습니다.

![V8 Engine](/assets/img/2024-07-30-NodejsDetailsofV8Engine_0.png)

## V8 엔진이란 무엇인가요?

V8 엔진은 구글에서 개발한 오픈 소스 JavaScript 엔진입니다. 이 엔진은 C++로 작성되었으며 Google Chrome 및 Node.js에서 JavaScript 코드를 실행하는 데 사용됩니다. V8은 JavaScript를 직접 네이티브 기계 코드로 컴파일한 후 실행하여 JavaScript 해석과 비교하여 상당한 성능 향상을 이뤄냅니다.

<div class="content-ad"></div>

## V8 엔진의 주요 구성 요소

V8 엔진은 JavaScript 실행을 최적화하기 위해 함께 작동하는 여러 가지 주요 구성 요소로 구성되어 있습니다:

- 분석기
- Ignition 해석기
- TurboFan 컴파일러
- 가비지 수집기

각 구성 요소를 자세히 살펴보겠습니다.

<div class="content-ad"></div>

# 파서

파서는 V8 엔진의 파이프라인에서 첫 번째 구성 요소입니다. 그 주요 역할은 JavaScript 코드를 추상 구문 트리 (AST)로 변환하는 것입니다. 이는 코드의 구조를 계층적으로 표현한 것입니다.

- 렉시컬 분석: 파서는 먼저 렉시컬 분석을 수행하여 소스 코드를 토큰으로 분해합니다. 토큰은 코드의 가장 작은 의미 단위입니다.
- 구문 분석: 그 다음 파서는 구문 분석을 수행하여 토큰을 코드의 구문 구조를 나타내는 트리 구조 (AST)로 배열합니다.

AST는 V8 파이프라인의 나머지 부분이 코드를 이해하고 최적화하는 데 사용하는 중요한 중간 표현입니다.

<div class="content-ad"></div>

# Ignition Interpreter

이그니션은 V8 엔진의 인터프리터입니다. 이그니션은 파서에 의해 생성된 AST를 가져와 바이트코드로 변환하여 코드의 낮은 수준 표현으로 효율적으로 실행할 수 있도록 합니다.

- 바이트코드 생성: 이그니션은 AST를 바이트코드로 변환하여 코드의 더 조밀하고 최적화된 표현으로 변환합니다.
- 실행: 그런 다음 바이트코드는 이그니션 인터프리터에 의해 실행됩니다. 바이트코드를 해석하는 것은 컴파일된 기계 코드를 실행하는 것보다 일반적으로 더 느리지만, 더 빠른 시작시간 및 동적 코드 변경의 효율적 처리를 가능하게 합니다.

이그니션의 주요 역할은 JavaScript 코드를 빠르고 효율적으로 실행하면서 성능을 최적화하기 위해 사용할 수 있는 프로파일링 정보를 수집하는 것입니다.

<div class="content-ad"></div>

# TurboFan 컴파일러

TurboFan은 V8 엔진의 최적화 컴파일러입니다. Ignition에 의해 실행된 바이트코드를 가져와 많이 최적화된 기계 코드로 컴파일하여 자주 실행되는 코드 경로의 성능을 향상시킵니다.

- 프로파일링: Ignition이 바이트코드를 실행하는 동안 코드의 동작에 대한 프로파일링 정보(자주 호출되는 함수, 자주 실행되는 루프 등)를 수집합니다.
- 최적화: TurboFan은 프로파일링 정보를 사용하여 다양한 최적화를 적용하며, 자주 호출되는 함수를 인라인으로 처리하고 죽은 코드를 제거하며 루프를 최적화합니다.
- 코드 생성: TurboFan은 CPU에서 직접 실행할 수 있는 매우 최적화된 기계 코드를 생성하여 상당한 성능 향상을 이끌어냅니다.

# Garbage Collector

<div class="content-ad"></div>

V8 엔진의 가비지 컬렉터는 메모리를 관리하고 사용되지 않는 자원을 회수하는 역할을 합니다. V8은 두 세대로 객체를 구분하는 세대별 가비지 컬렉션 전략을 사용합니다: 젊은 세대와 늙은 세대.

- 젊은 세대: 새로 할당된 객체는 젊은 세대에 배치됩니다. 대부분의 객체가 수명이 짧기 때문에 가비지 컬렉터는 이 부분의 메모리를 자주 수집하고 정리하여 신속하게 재할당할 수 있습니다.
- 늙은 세대: 젊은 세대에서 여러 번의 가비지 컬렉션 주기를 버텨낸 객체는 늙은 세대로 이동됩니다. 가비지 컬렉터는 이 부분을 덜 자주 수집하지만 더 철저한 최적화를 수행합니다.

V8은 메모리를 회수하고 단편화를 최소화하기 위해 마크-스위프트(mark-sweep) 및 마크-컴팩트(mark-compact) 알고리즘의 조합을 사용하여 효율적인 메모리 관리를 보장합니다.

# V8 최적화 기술

<div class="content-ad"></div>

V8 엔진은 자바스크립트 코드의 성능을 향상시키기 위해 다양한 최적화 기술을 사용합니다. 이러한 기술을 이해하면 더 성능이 우수한 코드를 작성할 수 있습니다:

- 인라인 캐싱: V8은 속성 액세스를 최적화하기 위해 인라인 캐싱을 사용합니다. 속성이 여러 번 액세스되면 V8은 속성의 위치를 캐시하여 매번 찾는 오버헤드를 줄입니다.
- 숨겨진 클래스: V8은 객체 속성 액세스를 최적화하기 위해 숨겨진 클래스를 사용합니다. 객체가 생성될 때 V8은 속성을 설명하는 숨겨진 클래스를 할당합니다. 속성이 추가되거나 수정될 때 V8은 새로운 숨겨진 클래스를 생성하고 객체를 새 클래스로 전환하여 빠른 속성 액세스를 가능하게 합니다.
- 코드 인라인: V8은 자주 호출되는 함수를 인라인화하여 함수 호출을 함수 본문으로 대체합니다. 이렇게 하면 함수를 호출하는 오버헤드가 줄어들고 추가 최적화가 가능해집니다.
- 죽은 코드 제거: V8은 실행되지 않는 코드를 제거하여 컴파일된 코드의 크기를 줄이고 성능을 향상시킵니다.
- 루프 최적화: V8은 루프에 다양한 최적화를 적용합니다. 작은 루프를 펼치거나 루프 외부로 불변 코드를 올리는 등의 최적화를 수행합니다.

# V8 성능 최적화의 실제 예제

## 예제 1: 인라인 캐싱을 사용한 속성 액세스 최적화

<div class="content-ad"></div>

```js
function Point(x, y) {
  this.x = x;
  this.y = y;
}

const p1 = new Point(1, 2);
const p2 = new Point(3, 4);

function sumPoints(p1, p2) {
  return p1.x + p1.y + p2.x + p2.y;
}

console.log(sumPoints(p1, p2));
```

이 예제에서 V8은 p1.x, p1.y, p2.x, 및 p2.y의 속성 접근을 최적화하기 위해 인라인 캐싱을 사용합니다. 속성에 처음 액세스할 때 V8은 그 위치를 캐시하여 후속 액세스가 더 빠르게 이루어질 수 있도록 합니다.

## 자세한 분석

객체 생성:

<div class="content-ad"></div>

- Point 생성자 함수는 x 및 y 속성을 가진 객체를 생성합니다.
- new Point(1, 2) 및 new Point(3, 4)를 호출하면 각각의 속성 값을 가진 두 Point 객체(p1 및 p2)가 생성됩니다.

속성에 액세스:

- sumPoints 함수는 p1 및 p2의 x 및 y 속성에 액세스합니다.
- 초기에 V8은 이러한 객체에서 x 및 y 속성이 어디에 있는지 찾아야 합니다. 이 작업은 반복적으로 수행될 경우 상대적으로 느릴 수 있는 찾기 프로세스를 포함합니다.

첫 번째 찾기 및 인라인 캐싱:

<div class="content-ad"></div>

- V8가 처음 p1.x를 찾을 때, p1 객체 내의 x 속성을 찾아야 합니다. 이 과정은 속성을 찾기 위해 객체의 숨겨진 클래스( V8의 최적화 기술)를 확인하는 과정을 포함합니다.
- V8가 p1.x를 찾으면, 이 속성의 위치를 나중에 액세스하기 위해 저장(또는 캐싱)합니다. 이것이 "인라인 캐시"입니다.

이후의 찾기:

- p1.y에 접근할 때, V8는 유사한 찾기를 수행하고 y의 위치를 캐싱합니다.
- p2.x와 p2.y에 대해서도 동일한 캐싱 메커니즘이 적용됩니다.

최적화된 속성 액세스:

<div class="content-ad"></div>

- 초기 룩업 및 캐싱 후에는 이러한 속성에 대한 후속 액세스가 빨라집니다. V8은 캐시된 위치를 사용하여 룩업을 다시 수행하는 대신 빠르게 액세스할 수 있습니다.
- sumPoints 함수에서 p1.x에 액세스하고 해당 위치가 캐싱되면, 다음에 p1.x가 필요할 때 V8은 캐시에서 직접 검색하여 룩업 프로세스를 우회합니다.

## 예시 2: 히든 클래스를 활용하여 객체 생성 최적화

```js
function Point(x, y) {
  this.x = x;
  this.y = y;
}

const points = [];
for (let i = 0; i < 1000; i++) {
  points.push(new Point(i, i + 1));
}
```

이 예시에서 V8은 Point 객체의 생성을 최적화하기 위해 히든 클래스를 사용합니다. 속성 x와 y가 객체에 추가될 때 V8은 빠른 속성 액세스를 가능케 하기 위해 히든 클래스를 생성하고 전환합니다.

<div class="content-ad"></div>

# V8과 Node.js: 강력한 조합

V8 엔진의 최적화와 효율적인 JavaScript 코드 실행은 Node.js가 빠르고 성능이 뛰어난 이유 중 하나입니다. V8이 어떻게 작동하는지 이해함으로써, 이러한 최적화를 완전히 활용할 수 있는 Node.js 애플리케이션을 작성할 수 있습니다.

## V8과 메모리 관리(Node.js)

메모리 관리는 모든 애플리케이션의 중요한 측면입니다. Node.js에서 V8 엔진의 가비지 수집기는 메모리 할당 및 해제를 처리하여 메모리 누수 없이 애플리케이션이 원활하게 실행되도록 합니다.

<div class="content-ad"></div>

- 메모리 할당: V8은 새로운 객체를 young generation에 메모리를 할당합니다. 객체가 생성되고 사용됨에 따라 V8은 그들의 참조와 사용 패턴을 추적합니다.
- 가비지 컬렉션: 메모리가 부족해지면 V8의 가비지 수집기가 실행되어 사용되지 않는 메모리를 회수합니다. V8은 mark-sweep 및 mark-compact 알고리즘을 사용하여 더 이상 필요하지 않은 메모리를 식별하고 해제합니다.
- 큰 객체 관리: young generation에 맞지 않는 큰 객체는 old generation에 직접 할당됩니다. V8의 가비지 수집기는 이러한 객체를 별도로 관리하여 효율적인 메모리 사용을 보장합니다.

## 효율적인 Node.js 코드 작성을 위한 실용적인 팁

- 불필요한 객체 생성 피하기: 가비지 컬렉션의 오버헤드를 줄이기 위해 불필요한 객체 생성을 최소화하고 가능한 경우 객체를 재사용합니다.
- 속성 액세스 최적화: V8의 인라인 캐싱 및 히든 클래스 최적화를 활성화하기 위해 객체 속성에 일관되게 액세스합니다.
- 전역 변수 최소화: V8의 최적화 노력을 방해하고 메모리 누수로 이어질 수 있으므로 전역 변수 사용을 피합니다.
- 효율적인 데이터 구조 사용: 사용 사례에 맞는 적절한 데이터 구조를 선택합니다. 예를 들어, 색인된 컬렉션에는 배열을 사용하고 키-값 쌍에는 객체를 사용합니다.
- 프로파일링 및 최적화: node --prof 및 clinic과 같은 프로파일링 도구를 사용하여 성능 병목 현상을 식별하고 코드를 최적화합니다.

## 결론

<div class="content-ad"></div>

V8 엔진은 Node.js의 강력한 구성 요소로, JavaScript 코드를 빠르고 효율적으로 실행할 수 있게 합니다. V8가 어떻게 작동하는지 이해하고 최적화 기술을 활용하면, 확장성이 좋고 사용자 경험이 훌륭한 고성능 Node.js 애플리케이션을 작성할 수 있습니다.

다음 글에서는 Libuv 라이브러리를 살펴보고, Node.js에서 비동기 I/O 작업과 이벤트 루프 관리 역할을 이해할 것입니다. 많은 기대 부탁드립니다!

구독하고 팔로우하여 Node.js 내부 세계로의 흥미로운 여정에 참여해주세요!

질문이나 의견을 자유롭게 남겨주세요. 학습 여정에서 도와드릴 수 있습니다.

<div class="content-ad"></div>

행복한 코딩하세요!

Nodejs V8 엔진에서 알아둬야할 기능 정리




![image](/assets/img/2024-07-30-ShouldAngularDirectivesHaveStyles_0.png)

# Angular의 속성 지시자와 스타일에 관한 토론이 7년 동안 이어지고 있습니다. 그러나 이것이 변할 수도 있습니다.

평소처럼 Angular에서 보고된 이슈를 찾아보다가, 2017년에 시작된 흥미로운 토론을 발견했습니다. 7년 전부터 계속되어온 이야기죠.

토론이 상당히 길어서 주요 이슈를 이해하는 것이 실제로 어렵기 때문에 요약해 드리겠습니다.

<div class="content-ad"></div>

간단히 말하면 Angular 개발자들 중에 지시문에 styles 및 styleUrl을 정의할 수 있는 기능에 대한 큰 수요가 있습니다.

이해를 돕기 위해 이것을 분석해보겠습니다. Angular 애플리케이션은 주로 구성 요소와 조합으로 구축됩니다.

이것은 기능의 동작과 외관을 캡슐화하는 구성 요소를 구축한다는 의미입니다. 예를 들어 버튼. 그러면 해당 버튼으로 사용자 인터페이스를 구성할 수 있고, 이제는 내부 구현과 스타일에 더 이상 신경 쓰지 않아도 됩니다.

외관과 부분적인 동작은 CSS(또는 SCSS 등)를 사용하여 달성되며, @Component 지시문의 styles 속성이나 styleUrl에 내부적으로 정의된 스타일 시트로 이루어집니다. 이 속성은 스타일을 포함한 CSS 또는 SCSS 파일을 가리킵니다.

<div class="content-ad"></div>

하지만 구성 요소 이외에도 Angular에는 디렉티브라는 개체도 있습니다. 공식 Angular 문서에 따르면:

문서에는 컴포넌트의 호스트 요소의 색을 변경하는 디렉티브의 예가 제시되어 있습니다:

```js
import {Directive, ElementRef} from '@angular/core';
@Directive({
  standalone: true,
  selector: '[appHighlight]',
})
export class HighlightDirective {
  constructor(private el: ElementRef) {
    this.el.nativeElement
      .style.backgroundColor = 'yellow';
  }
}
```

그런데 99.9%의 작업을 컴포넌트와 표준 구성으로 수행할 수 있기 때문에 디렉티브가 필요한 이유가 무엇일까요?

<div class="content-ad"></div>

우리가 지시문을 적용하려는 컴포넌트가 자체 하이라이트 속성을 가질 수 없는 이유는 무엇인가요?

물론 가능합니다. 그러나 컴포넌트 라이브러리를 구축할 때와 같이 경우에 따라 그렇게 할 수 없는 경우가 있습니다.

예를 들어 Angular Material은 네이티브 입력 값을 Angular Material mat-form-field 컴포넌트와 함께 사용할 수 있도록 matInput 지시문을 사용합니다:

```js
<mat-form-field class="example-full-width">
    <mat-label>Favorite food</mat-label>
    <input matInput placeholder="Ex. Pizza" value="Sushi">
</mat-form-field>
```

<div class="content-ad"></div>

Angular Material과 기본 요소 간의 간격을 좁히는 목적으로 사용됩니다.

"mat-input"과 같이 자체 입력 구성 요소를 제공하지 않는 이유가 궁금할 수 있습니다. 이 동작을 캡슐화하기 위해 지시문을 사용하는 대신 왜 그런지 궁금할 수 있습니다.

그러나 Angular Material 개발자가 입력 API를 확장하고 싶지 않았다는 점이 합리적으로 보입니다. 즉, 입력 기본 속성을 변경하고 싶지 않았다는 것을 의미합니다. 따라서 지시문은 입력 요소의 동작을 좁게 변경하면서 입력 태그 이름을 포함한 입력 기능의 나머지에 영향을 주지 않는 가벼운 방법입니다.

결론적으로 우리가 얻을 수 있는 결론은 다음과 같습니다:

<div class="content-ad"></div>

- 지시문은 컴포넌트의 일부를 변경할 수 있도록 해주지만 나머지 부분에 영향을 미치지 않습니다.
- 이것은 구현을 변경하지 않고 다양한 컴포넌트에 적용할 수 있습니다.

그래서 지시문은 컴포넌트 조합이 불편한 상황에서 탈출구 역할을 합니다.

앵귤러에서는 특정한 경우에만 드물게 사용되는 매우 구체적인 요소입니다.

이제 우리 모두가 알고 있는 것은 앵귤러에서의 지시문의 목적입니다. 이는 2017년에 보고된 이슈의 주제를 이해하는 데 도움이 될 것입니다.

<div class="content-ad"></div>

앵귤러 문서의 지시문을 다시 살펴봅시다:

```js
import {Directive, ElementRef} from '@angular/core';
@Directive({
  standalone: true,
  selector: '[appHighlight]',
})
export class HighlightDirective {
  constructor(private el: ElementRef) {
    this.el.nativeElement
      .style.backgroundColor = 'yellow';
  }
}
```

이 코드에서 앵귤러스러운 부분이 있지 않은 것 같습니다. 훈련받은 눈은 즉시 알아차릴 것입니다.

앵귤러에서 컴포넌트에 스타일을 적용하려면 styles 또는 styleUrl 속성을 사용해야 합니다:

<div class="content-ad"></div>


```js
@Component({
  selector: 'profile-photo',
  template: `<img src="profile-photo.jpg" alt="Your profile photo">`,
  styles: ` img { border-radius: 50%; } `,
})
export class ProfilePhoto { }
```

앵귤러에서 스타일을 적용하는 방법이에요.

그러나 지시문에서는 지원하지 않기 때문에 그 Angular 기능을 사용할 수 없어요.

2017년 이슈가 다른 개발자들로부터 많은 지원을 받아 고쳐져야 한다는 합리적인 요구로 등장했어요:


<div class="content-ad"></div>

<img src="/assets/img/2024-07-30-ShouldAngularDirectivesHaveStyles_1.png" />

기능 요청에 대한 토론이 진행되면 의사 소통에 많은 오해가 있다는 느낌을 받습니다.

이 기능이 분명히 누락되어 있다고 생각하는 개발자들이 많습니다. 또한 다른 방법을 제안하고 필요성을 이해하지 못하는 개발자들도 있습니다.

Angular 문서에 표시된 것처럼, 디렉티브는 일반적인 구성과 부품 사용이 불편한 경우에 사용되는 이스케이프 햇치입니다.

<div class="content-ad"></div>

@Directive를 사용한 모든 예제들은 다른 방법으로 해결할 수 있습니다. 제안된 모든 해결책과 해결책을 모두 읽어 보았어요. 하지만 먼저, 특정한 상황에서 왜 누군가가 @Directive를 모두 필요로 하는지 전체 맥락을 설명하는 것이 매우 어렵다고 생각해요.

두 번째로, 제안된 해결책들은 지루합니다. 지시자들은 바로 이러한 경우를 처리하는 깔끔하고 편리한 방법을 제공하기 위해 존재하는 이유이기 때문에요.

현재 형태를 보면, 디렉티브를 사용하여 스타일을 적용하는 방식이 nativeElement (또는 글로벌 스타일 등)을 통해 이루어지는 것은 디자인 결정인 것처럼 느껴져요.

@Directive는 hacky하고 사용해서는 안 되는 것이므로, 생으로 남겨두어 사용을 자제하도록 해요. 정글에 있으니 자신의 힘으로 해결해보세요.

<div class="content-ad"></div>

그러나 Angular Material 팀과 기타 사용자는 지시문을 사용하며, 이들이 합리적인 사용 사례를 갖고 있는 것으로 나타났습니다.

그러므로 지시문은 그리 해킹적이지 않을 수도 있습니다. 아마도 우리는 지시문을 Angular 프레임워크의 중요한 부분으로 취급할 수 있을지도 모릅니다. 정의된 지시문은 동작을 변경하는 데 사용될 수 있습니다. 때로는 동작을 변경하는 데 CSS를 통해 변경을 필요로 할 수 있습니다.

이 경우, 실제로 Angular 기능을 제공할 수도 있습니다. 이 경우에는 styles 및 styleUrl에 대한 지원이 합리적입니다.

부가적인 혜택으로, 속성 지시문 API가 구성요소와 더 일치할 수 있습니다. 속성 지시문은 결국 가벼운 구성요소와 유사하기 때문에 이는 합리적인 일로 보입니다.

<div class="content-ad"></div>

그래서 directive를 스타일링해야 할까요? 주석을 달아보세요!

그리고, Angular 치트 시트 카드를 디자인했어요. 지금 주문하세요!

만약 이 글을 좋아하신다면, 박수를 치거나 이메일로 구독하고 공유하고 좋아요를 눌러주세요! 

소프트웨어 엔지니어링에 대해 최신 소식을 받고 싶으신가요? 이미 18,000명 이상의 구독자들이 Tom Smykowski의 기사를 구독하고 있어요. 이제 당신도 그들 중 하나가 되어보세요. 매월 $5만 내면 Tom Smykowski뿐만 아니라 Medium의 모든 기사에도 액세스할 수 있고, Tom Smykowski가 더 많은 흥미로운 이야기를 만들어 내게 됩니다! 지금 멤버십 가입하세요!

Angular 디렉티브에 스타일 적용하는 방법




마크다운 형식으로 표 태그를 변경합니다.

![Proxy Pattern](/assets/img/2024-07-30-DesignPatternsProxyinAngular_0.png)

구조 패턴은 클래스와 객체를 더 큰 구조로 결합하는 방법을 설명합니다.

구조 패턴은 다음과 같습니다:
1. 어댑터
2. 컴포지트
3. 프록시
4. 플라이웨이트
5. 퍼사드
6. 브릿지
7. 데코레이터

프록시 디자인 패턴(중재자로도 알려짐)은 객체를 생성하는 데 시간이 많이 소요되고 리소스를 많이 사용하는 경우에 유용합니다. 이 패턴을 사용하면 해당 객체를 실제로 필요한 시점까지 생성을 연기할 수 있습니다.

<div class="content-ad"></div>

프록시 디자인 패턴은 다음 상황에서 사용될 수 있습니다:

- 성능 최적화: 파일이 오래 걸리는 경우
- 원격 객체: 객체가 다른 주소 공간(예: 서버)에 있고 네트워크를 통해로드하는 데 오랜 시간이 걸리거나 네트워크 혼잡 기간에 특히 시간이 오래 걸리는 경우에 사용할 수 있습니다. 프록시는 클라이언트와 원격 객체 간의 통신에서 중계자 역할을 할 수 있습니다.
- 접근 제어: 객체에 대한 액세스 권한을 제한하고자 하는 경우, 프록시 디자인 패턴은 사용자의 권한을 확인한 후 요청을 대상 객체로 전달할 수 있습니다.
- 자원 관리: 네트워크 연결, 파일, 모듈 또는 기능과 같은 자원을 관리하려는 경우, 프록시 디자인 패턴을 사용하여 이러한 자원에 대한 액세스를 감시하고 제어할 수 있습니다.
- 네트워크 인터페이스: 로컬 객체에 네트워크 인터페이스를 제공하고자 할 때, 프록시 디자인 패턴을 사용하여 메서드 호출을 네트워크 메시지로 변환하거나 그 반대로 할 수 있습니다.

전체 데모를 보고 싶다면 데모 프로젝트를 확인해보세요.

프록시 디자인 패턴은 다양한 방식으로 설명할 수 있습니다. 여기서는 텍스트를 JSON으로 매핑하는 컨버터 예시를 들어 설명하겠습니다. 이 예시에서는 추가로 두 라이브러리를 설치해야 합니다.

<div class="content-ad"></div>

그 다음에는 다음 명령어를 사용하여 서버를 실행해야 합니다:

<div class="content-ad"></div>

```js
node server.js
```

server.js 스크립트가 있는 디렉토리에서 실행해주세요.

서버로부터 데이터를 가져오는 메서드가 포함된 서비스는 다음과 같이 제공됩니다:

```js
import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Observable } from 'rxjs';

@Injectable({
  providedIn: 'root'
})
export class DataService {

  private apiUrl = 'http://localhost:3000/text-data';

  constructor(private http: HttpClient) {}

  getTextData(): Observable<string> {
    return this.http.get(this.apiUrl, { responseType: 'text' });
  }
}
```

<div class="content-ad"></div>

여기에 Proxy 디자인 패턴의 전체 구현이 있습니다:

```js
import { Component } from '@angular/core';
import { DataService } from '../../common/service/data.service';
import { map, take } from 'rxjs';


export abstract class JsonParser {
  abstract parse(text: string): any;
}
export interface ConvertStringToObject {
  description: string;
}

@Component({
  selector: 'app-proxy',
  template:`
  <h3>Proxy 디자인 패턴은 중개자로도 알려져 있습니다.
    두 가지 추상화 사이의 중개 기능을 합니다.
  </h3>
  <div>{ (textData$| async)?.description }</div>`,
  styleUrl: './proxy.component.scss',
  providers: [DataService]
})
export class ProxyComponent extends JsonParser {
  textData$ = this.dataService.getTextData()
    .pipe(
      take(1),
      map(val => this.parse(val))
    );

  constructor(private dataService: DataService) { super() }

  parse(value: string): ConvertStringToObject {
    if (typeof value === 'string') {
      return { description: value };
    }
    return value;
  }
}
```

핵심은 문자열을 ConvertStringToObject 객체로 변환하는 변환 클래스인 JsonParser 추상 클래스입니다. 물론, 객체는 더 복잡할 수 있습니다. ProxyComponent 클래스는 JsonParser를 상속하며 parse 메소드의 전체 구현이 이미 포함되어 있습니다. 이 메소드에서 텍스트가 지정된 인터페이스의 객체로 변환됩니다.

## 요약:

<div class="content-ad"></div>

프록시 디자인 패턴의 이념을 소개하고 싶어요. 이 패턴은 하나의 추상화와 다른 추상화 사이에서 중재자 역할을 합니다. 여기서 하나의 추상화는 큰 파일, 잘못된 데이터 형식, 사용자 권한 확인 등의 여러 가지 것들일 수 있어요. 이 패턴의 목적은 사용자 상호작용을 지원하는 기능을 수행하는 것입니다.

자료:

- 자바. Wzorce 프로젝토베. 번역: Piotr Badarycz. 원제: 자바 디자인 패턴. 사용자 지침서. 저자: James William Cooper

제가 다른 Angular와 관련된 디자인 패턴에 관한 기사들도 있어요:

<div class="content-ad"></div>

구조적 패턴:
- 디자인 패턴 - 앵귤러에서 어댑터
- 디자인 패턴 - 앵귤러에서 컴포지트

창조적 패턴:
- 디자인 패턴 - 앵귤러에서 빌더

저는 영어를 잘하지 못해요. 영어 실력 향상을 위해 글을 쓰고 있어요.

Angular에서 Proxy 디자인 패턴 사용 방법




이미지 태그를 Markdown 형식으로 변경하십시오.


![이미지](/assets/img/2024-07-30-ImplementingShakeDetectionforInteractiveMobileWebAppsJavaScript_0.png)


## 흔들림 이벤트를 감지하는 이유

모바일 웹 앱에서 흔들림 이벤트를 감지하려는 이유는 다음과 같습니다:

- 상호 작용 기능: 컨텐츠 새로 고침, 게임에서 주사위 굴리기 또는 사용자 정의 작업 트리거와 같은 재미있고 매료되는 상호 작용을 구현합니다.
- 접근성: 터치 스크린을 사용하는 데 어려움을 겪는 사용자를 위한 대체 제어 방법을 제공합니다.

<div class="content-ad"></div>

## DeviceMotionEvent API 사용 방법(라이브러리 사용 안 함):

- window.addEventListener(`devicemotion`, handleMotion)을 사용하여 기기의 가속도계 데이터에 액세스합니다.
- event.acceleration.x, event.accelerationIncludingGravity.y 및 event.accelerationIncludingGravity.z를 기반으로 각 축(X, Y, Z)의 가속도를 계산합니다.
- 가속도 크기가 일정한 한계를 초과하는 가속도.magnitude를 기반으로 시간대 내에서 흔들림을 판단하는 임계값 기반 탐지 메커니즘을 구현합니다.
- 저역통과 필터링과 같은 기법을 사용하여 잡음과 우연한 움직임을 걸러내는 것을 고려합니다.

```js
function handleMotion(event) {
    const x = event.accelerationIncludingGravity.x;
    const y = event.accelerationIncludingGravity.y;
    const z = event.accelerationIncludingGravity.z;

    const acceleration = Math.sqrt(x * x + y * y + z * z);

    // 여기에 흔들림 감지 논리를 구현합니다
    // 예: 일정 시간 내에 가속도 한계를 초과하는지 확인
    if (acceleration > 15 && /* 시간 창에 대한 추가 조건 */) {
        console.log('흔들림 감지!');
    }
}

window.addEventListener('devicemotion', handleMotion);
```

## JavaScript 라이브러리 사용 방법(Shake.js):

<div class="content-ad"></div>

- CDN 또는 패키지 관리자를 사용하여 프로젝트에 Shake.js 라이브러리를 포함시킵니다.
- threshold, timeout 및 onshake 콜백과 같은 사용자 정의 옵션을 사용하여 Shake 인스턴스를 만듭니다.
- start()를 호출하여 흔들림 이벤트를 청취합니다.

```js
var myShakeEvent = new Shake({
    threshold: 15, // 선택적인 흔들림 강도 임계값
    timeout: 1000 // 선택적으로 이벤트 생성 빈도 결정
});

myShakeEvent.start();

window.addEventListener('shake', shakeEventDidOccur, false);

function shakeEventDidOccur() {
    console.log('흔들림 감지됨!');
}
```

## 추가 고려 사항:

- 사용자 개인정보: DeviceMotionEvent.requestPermission()을 사용하여 iOS 기기의 장치 모션 센서 접근 권한 요청.
- 세부 조정: 앱의 요구 사항에 따라 임계값 및 timeout 값을 조정하여 우연한 움직임으로 인한 잘못된 양성 결과를 피합니다.
- 현대적 브라우저: devicemotion이 널리 지원되지만 대상 브라우저와의 호환성을 확인하세요.

인터랙티브 모바일 웹 앱을 위한 흔들림 감지 구현하기





![이미지](/assets/img/2024-07-30-DesignPatternsBuilderinAngular_0.png)

창조적 디자인 패턴은 객체를 만드는 방법에 관심이 있습니다.

JavaScript, TypeScript 등에서 객체를 만드는 방법은 new 연산자를 사용하는 것입니다.

창조적 패턴으로는 다음이 있습니다:
1. Factory
2. Factory Method
3. Abstract Factory
4. Singleton
5. Prototype
6. Builder
7. Object Pool


<div class="content-ad"></div>

이 글에서는 빌더 패턴이 어떻게 작동하는지 설명하겠습니다. 데모 프로젝트에서 빌더 패턴의 예제를 확인하고 실행할 수 있습니다. 다음 링크에서 해당 프로젝트를 찾을 수 있습니다.

빌더 디자인 패턴은 이름에서 알 수 있듯이 구성 프로세스를 모델링하는 데 사용됩니다. 일상 생활에서는 집, 아파트 블록, 성, 구조물 등을 짓습니다. 집을 짓기 위해서는 특정 순서로 특정 제품을 사용해야 하는 특정 작업이 수행되어야 합니다. 웹 시스템에서 구축은 특정 필드가 있는 양식을 생성하는 방식으로 나타낼 수 있습니다. 유효성 검사가 성공하면 양식 데이터가 API로 전송됩니다. 양식은 집처럼 각각 다를 수 있습니다.

Angular는 빌더 패턴의 구현을 제공합니다. 이는 @angular/forms 라이브러리의 FormBuilder 클래스입니다. 이 클래스에는 그룹, 레코드, 컨트롤, 배열과 같은 여러 메서드가 포함되어 있으며 각각 양식 컨트롤을 생성합니다. FormBuilder를 사용하려면 클래스를 생성자에 주입해야 합니다:

```js
@Component({
// ...
})export class BuilderComponent {
   constructor(private formBuilder: FormBuilder) {}
}
```

<div class="content-ad"></div>

테이블 태그를 마크다운 형식으로 변경하거나 inject 함수에 전달하세요:

```js
@Component({
// ...
})
export class BuilderComponent {
     private formBuilder = inject(FormBuilder)
}
```

빌더 디자인 패턴의 구조는 여러 요소로 구성되어 있습니다.

인터페이스 — 모든 유형의 빌더에 공통인 제품 구성 단계를 선언합니다.

<div class="content-ad"></div>

빌더 - 건설 단계의 다양한 구현을 제공합니다. 특정 빌더는 공통 인터페이스를 공유하지 않는 제품을 생성할 수 있습니다. 저희 양식의 예시에서는 이것이 필드 설정 등입니다.

제품 - 이들은 우리 경우 양식을 구축하는 데 사용되는 객체들입니다. 이는 FormControl, FormGroup, FormArray 또는 FormRecord일 수 있습니다. 서로 다른 빌더에 의해 구성된 제품들은 동일한 클래스 계층 구조나 인터페이스에 속할 필요가 없습니다.

디렉터 클래스 - 우리 경우 양식을 생성하기 위해 건설 단계를 호출하는 순서를 정의합니다.

클라이언트 - 클라이언트는 디렉터에 빌더 객체 중 하나를 할당해야 합니다. 우리 경우에는 유효성 검사 또는 옵션 설정을 명시할 수 있을 것입니다. 클라이언트는 양식의 적용과 양식에서 다른 메서드로 데이터를 전달할 수 있습니다.

<div class="content-ad"></div>

사용자 정의 FormBuilder를 구현하는 방법은 다음과 같습니다:

```js
import { NgFor } from '@angular/common';
import { Component, inject } from '@angular/core';
import { AbstractControlOptions, FormArray, FormBuilder, FormGroup, ReactiveFormsModule, 
  ValidatorFn, AsyncValidatorFn, FormRecord, Validators } from '@angular/forms';


class NewDefinitionFormGroup extends FormGroup {
  constructor(controls: any, validatorOrOpts?: ValidatorFn | ValidatorFn[] | AbstractControlOptions | null, asyncValidator?: AsyncValidatorFn | AsyncValidatorFn[] | null) {
    super(controls);
    console.info('새로운 정의 키', Object.keys(controls));
  }
}

export class NewDefinitionFormBuilderPattern extends FormBuilder {
  override group<T extends {}>(controls: T, options?: AbstractControlOptions | null): FormGroup {
    return new NewDefinitionFormGroup(controls);
  }
}

@Component({
  selector: 'app-builder',
  standalone: true,
  imports: [ReactiveFormsModule, NgFor],
  templateUrl: './builder.component.html',
  styleUrl: './builder.component.scss',
  providers: [{
    provide: FormBuilder,
    useClass: NewDefinitionFormBuilderPattern
  }]
})
export class BuilderComponent {
  private formBuilder = inject(FormBuilder)

  radios: string[] = ['Male', 'Female'];
  selects: string[] = ['USA', 'Canada', 'UK', 'Australia', 'Other'];

  formBuilderGroup: FormGroup = this.formBuilder.group({
    name: this.formBuilder.control('', [Validators.maxLength(10)]),
    number: this.formBuilder.control(0, { nonNullable: true, }),
    group: this.formBuilder.group({
      groupName: this.formBuilder.control('', [Validators.required]),
    }),
    groupRadioSelectArrayChcekBox: this.formBuilder.group({
      radio: this.formBuilder.control(''),
      select: this.formBuilder.control(''),
      checkBox: this.formBuilder.array([
        this.createOption('checkBox 1'),
        this.createOption('checkBox 2'),
        this.createOption('checkBox 3')
      ])
    }),
    record: this.formBuilder.array([this.createRecord()])
  });

  createOption(defaultvalue: string, selected = false) {
    return this.formBuilder.group({
      selected: this.formBuilder.control(selected),
      value: this.formBuilder.control(defaultvalue)
    })
  }

  get checkBox(): FormArray {
    return this.formBuilderGroup.get('groupRadioSelectArrayChcekBox.checkBox') as FormArray;
  }
  get record(): FormArray {
    return this.formBuilderGroup.get('record') as FormArray;
  }

  createRecord(): FormRecord {
    return this.formBuilder.record({
      key: this.formBuilder.control(''),
      value: this.formBuilder.control(''),
    });
  }
  addRecord(): void {
    this.record.push(this.createRecord());
  }

  save() {
    console.log(this.formBuilderGroup);
  }
  reset() {
    this.formBuilderGroup.reset()
  }
}
```

새로운 `NewDefinitionFormBuilderPattern` 클래스의 통합은 providers 배열에 위치합니다. 해당 클래스를 인스턴스화할 때, 생성자는 `NewDefinitionFormBuilderPattern` 클래스로 대체되며, `group` 메서드를 재정의하고 새롭게 `NewDefinitionFormGroup` 클래스를 반환합니다. `NewDefinitionFormGroup` 클래스는 폼 컨트롤 키를 콘솔에 표시합니다.

첨부된 컨트롤이 있는 폼 구조의 템플릿은 다음과 같습니다:

<div class="content-ad"></div>


<div class="container">
    <form [formGroup]="formBuilderGroup" (ngSubmit)="save()">
        <div class="form-row">
            <label class="form-label" for="name">이름:</label>
            <input class="form-input" type="text" id="name" name="name" 
                formControlName="name">
        </div>
        <div class="form-row">
            <label class="form-label" for="number">Number:</label>
            <input class="form-input" type="number" id="number" name="number" 
                formControlName="number">
        </div>

        <div class="form-row" formGroupName="group">
            <label class="form-label" for="groupName">그룹명:</label>
            <input class="form-input" type="text" id="groupName" 
                formControlName="groupName">
        </div>

        <div class="form-group" formGroupName="groupRadioSelectArrayChcekBox">
            <label class="form-label">라디오버튼:</label>
            <div *ngFor="let radio of radios">
                <input class="form-input" type="radio" [value]="radio" 
                    formControlName="radio">{ radio }
            </div>

            <div class="form-row">
                <label class="form-label" for="select">선택:</label>
                <select class="form-input" id="select" 
                    formControlName="select">
                    <option *ngFor="let select of selects" [value]="select">
                        { select }
                    </option>
                </select>
            </div>

            <div class="form-group">
                <label class="form-label">체크박스: </label>
                <div formArrayName="checkBox" *ngFor="let item of checkBox.controls; let i = index">
                    <div [formGroupName]="i">
                        <input class="form-input" type="checkbox" formControlName="selected">
                        { item.value.value }
                    </div>
                </div>
            </div>
        </div>
        <div class="form-group">
            <div formArrayName="record">
                <label class="form-label">기록: </label>
                <button type="submit" (click)="addRecord()">
                    + 다른 기록 추가
                </button>

                @for ( record of record.controls; track record; let i = $index) {
                <div class="form-row" [formGroupName]="i">
                    <label class="form-label" for="key-{ i }">키:</label>
                    <input class="form-input" id="key-{ i }" type="text" 
                        formControlName="key">
                    <label class="form-label" for="value-{ i }">값:</label>
                    <input class="form-input" id="value-{ i }" type="text" 
                        formControlName="value">
                </div>
                }
            </div>
        </div>
        <button type="submit">제출</button>
        <button type="submit" (click)="reset()">초기화</button>
    </form>
</div>


위의 폼 구조는 제안사항입니다. FormBuilder 클래스는 폼 기능에 대한 방대한 메서드와 옵션을 제공합니다. 제안된 유효성 검사 방법은 여러 컨트롤을 결합하고 유효성을 검사할 수 있습니다.

아래는 Flexbox 속성을 사용하여 구축된 SCSS 스타일입니다:

```scss
.container {
    display: flex;
    flex-direction: column;
    align-items: center;
}

form {
    width: 100%;
    max-width: 700px;
    display: flex;
    flex-direction: column;
}

.form-row {
    display: flex;
    flex-direction: row;
    align-items: center;
    margin-bottom: 20px;

    .form-label {
        flex: 2;
        text-align: right;
        margin-right: 10px;
    }

    .form-input {
        flex: 3;
    }
}
.form-group {
    margin-bottom: 20px;
}
```

<div class="content-ad"></div>

# 요약:

Builder 패턴은 구축 중인 객체의 내부 표현을 변경하는 것을 허용하며 구축 세부 정보를 숨깁니다. 각 빌더는 다른 빌더와 시스템의 나머지 부분과 독립적입니다. 모듈화를 향상시키고 새로운 빌더를 쉽게 추가할 수 있습니다.

자료:

- Java. Wzorce projektowe. 번역: Piotr Badarycz. 원제: Java design patterns. A Tutorial. 저자: James William Cooper
- [Builder 디자인 패턴 참조 링크](https://refactoring.guru/pl/design-patterns/builder)

<div class="content-ad"></div>

다른 디자인 패턴과 관련된 내 Angular 기사:

구조 패턴:
- Angular에서 디자인 패턴 — 프록시
- Angular에서 디자인 패턴 — 컴포지트
- Angular에서 디자인 패턴 — 어댑터

영어 실력은 부족하지만, 영어 실력 향상을 위해 글을 써보고 있어요. 함께 응원해주세요!

Angular에서 빌더 디자인 패턴 사용 하는 방법




![이미지](/assets/img/2024-07-30-DesignPatternsCompositeinAngular_0.png)

구조 패턴은 클래스와 객체를 더 큰 구조로 결합하는 방법을 설명합니다.

구조 패턴은 다음과 같은 것들로 이루어져 있습니다:
1. 어댑터
2. 컴포지트
3. 프록시
4. 플라이급
5. 파사드
6. 브릿지
7. 데코레이터

컴포지트 디자인 패턴은 전체-부분 관계의 계층 구조를 만들거나 트리 데이터 구조를 만들 때 사용됩니다.

<div class="content-ad"></div>

복합 패턴의 구조는 여러 요소로 구성되어 있습니다:

- **클라이언트(Client)**: 구성 요소를 통해 모든 요소와 상호 작용합니다. 결과적으로 클라이언트는 간단한 요소와 복잡한 트리 요소 모두에 동일한 방식으로 작동할 수 있습니다.

- **컴포넌트(Component)**: 컴포넌트 인터페이스는 간단한 요소와 복잡한 트리 요소에 공통된 작업을 설명합니다.

- **리프(Leaf)**: 하위 요소가 없는 트리의 기본 요소입니다. 일반적으로 리프 컴포넌트는 대부분의 기능을 수행합니다. 왜냐하면 하위 요소가 없기 때문이죠.

<div class="content-ad"></div>

컨테이너 (또는 컴포지트) - 자식 요소인 잎이나 다른 컨테이너를 가지고 있는 요소입니다. 컨테이너는 내용물의 구체적인 클래스를 모르고 있습니다. 모든 자식 요소와는 구성 요소 인터페이스를 통해서만 통신합니다.

컴포지트와 구성을 혼동하지 마세요. 컴포지트는 객체의 계층 구조에서 작동하는 패턴입니다. 구성은 한 객체가 다른 객체를 포함하는 것입니다.

전체 데모를 보고 싶다면, 내 데모 프로젝트를 확인해보세요.

컴포지트 디자인 패턴은 여러 방법으로 설명할 수 있습니다. 저는 회사 구조를 표시하면서 매니저를 추가하고 추가된 직원을 매니저에 할당하는 기능의 예시를 제시할 것입니다.

<div class="content-ad"></div>

처음에 EmployeeHierarchyStructure 인터페이스에 일부 메서드가 추가되었습니다. ?는 선택 사항이라는 것을 나타냅니다. EmployeeHierarchyStructure 인터페이스의 구현은 다음과 같이 제시됩니다.

```js
export interface EmployeeHierarchyStructure {
    add?(employee: EmployeeHierarchyStructure): void;
    remove?(employee: EmployeeHierarchyStructure): void;
    getChild?(index: number): EmployeeHierarchyStructure | null;
    getName(): string;
    printDetails(indent?: string): void;
    getEmployees?(): EmployeeHierarchyStructure[];
}
```

Employee 클래스는 구현을 필요로하지 않습니다. 복합 디자인 패턴의 구조에서 Employee 클래스는 단말 요소를 대표합니다. Employee 클래스의 구현은 다음과 같습니다.

```js
export class Employee implements EmployeeHierarchyStructure {
    private name: string; 

    constructor(name: string ) {
        this.name = name; 
    }

    add(employee: EmployeeHierarchyStructure): void {
        throw new Error("Cannot add to a employee.");
    }

    remove(employee: EmployeeHierarchyStructure): void {
        throw new Error("Cannot remove from a employee.");
    }

    getChild(index: number): EmployeeHierarchyStructure | null {
        return null;
    }

    getName(): string {
        return this.name;
    }

    printDetails(indent: string = ''): void {
        console.info(`${indent}Employee: ${this.getName()}`);
    }

    getEmployees(): EmployeeHierarchyStructure[] {
        return [];
    }
}
```

<div class="content-ad"></div>

Manager 클래스는 Composite (Container) 엘리먼트를 반영합니다. 아래는 Manager 클래스의 구현 내용입니다:

```js
export class Manager implements EmployeeHierarchyStructure {
    private name: string; 
    private employees: Set<EmployeeHierarchyStructure>;

    constructor(name: string) {
        this.name = name; 
        this.employees = new Set<EmployeeHierarchyStructure>();
    }

    add(employee: EmployeeHierarchyStructure): void {
        this.employees.add(employee);
    }

    remove(employee: EmployeeHierarchyStructure): void {
        this.employees.delete(employee);
    }

    getChild(index: number): EmployeeHierarchyStructure | null {
        return Array.from(this.employees)[index] || null;
    }

    getName(): string {
        return this.name;
    }

    printDetails(indent: string = ''): void {
        console.info(`${indent} Manager: ${this.getName()}`);
        for (const employee of this.employees) {
            employee.printDetails(indent + '  ');
        }
    }

    getEmployees(): EmployeeHierarchyStructure[] {
        return Array.from(this.employees);
    }
}
```

Client 엘리먼트는 CompositeComponent로, 최상위 레벨에서 회사 소유주를 소유자로 정의합니다. addEmployeeForManager 메서드에서 일부 집계가 발생합니다. 매니저 객체를 제거하면 직원 객체를 생성하는 동안에는 오류가 발생하지 않고, 매니저에게 직원을 할당하는 과정에서만 오류가 발생합니다. 직원을 매니저에게 할당하는 것은 완전한 집계 (구성)를 나타냅니다. CompositeComponent 클래스의 구성요소는 다음과 같이 구현되었습니다:

```js
import { Component } from '@angular/core';
import { Employee, Manager } from '../model/model'

export interface ConfigurationOfAddingAnEmployee {
  managerName: string;
  employeeNeme: string;
  selectedManagerName: string;
}

@Component({
  selector: 'app-composite',
  templateUrl: './composite.component.html',
  styleUrls: ['./composite.component.scss']
})
export class CompositeComponent {

  boss: Manager = new Manager('Owner');
  selectedManager: Manager | null = null;

  company: ConfigurationOfAddingAnEmployee = {
    managerName: '',
    employeeNeme: '',
    selectedManagerName: ''
  };

  addManager(name: string) {
    const manager = new Manager(name);
    this.boss.add(manager);
    this.company.managerName = '';
  }

  addEmployeeForManager(managerName: string, employeeNeme: string) {
    const manager = this.findManager(managerName);
    if (manager) {
      const developer = new Employee(employeeNeme);
      manager.add(developer);
      this.company.employeeNeme = '';
    }
  }

  findManager(name: string): Manager | null {
    const managers = this.getAllManagers(this.boss);
    return managers.find(manager => manager.getName() === name) || null;
  }

  getAllManagers(manager: Manager): Manager[] {
    let managers: Manager[] = [manager];
    for (const employee of manager.getEmployees()) {
      if (employee instanceof Manager) {
        managers = managers.concat(this.getAllManagers(employee));
      }
    }
    return managers;
  }

  setSelectedManager(managerName: string) {
    this.selectedManager = this.findManager(managerName);
  }

}
```

<div class="content-ad"></div>

`CompositeComponent` 템플릿은 다음과 같습니다:

```js
<div class="container">
  <div class="row">
    <label for="selectedManager">매니저 선택: </label>
    <select id="selectedManager" [(ngModel)]="company.selectedManagerName" (ngModelChange)="setSelectedManager($event)">
      <option *ngFor="let manager of getAllManagers(boss)" [value]="manager.getName()">
        { manager.getName() }
      </option>
    </select>
  </div>

  <div class="row">
    <label for="managerName">매니저 이름: </label>
    <input type="text" id="managerName" name="managerName" [(ngModel)]="company.managerName">
    <button (click)="addManager(company.managerName)">매니저 추가</button>
  </div>

  <div class="row" *ngIf="selectedManager">
    <label for="employeeName">직원 이름: </label>
    <input type="text" id="employeeName" name="employeeName" [(ngModel)]="company.employeeName">
    <button (click)="addEmployeeForManager(company.selectedManagerName, company.employeeName)">
      매니저에게 직원 추가
    </button>
  </div>
</div>

<div>
  <h3>회사 구조</h3>
  <ul>
    <ng-container *ngIf="boss">
      <li *ngFor="let manager of boss.getEmployees()">
        <app-employee [manager]="manager"/>
      </li>
    </ng-container>
  </ul>
</div>
```

개요

Composite 패턴은 같은 인터페이스를 공유하는 단순한 leaf와 복잡한 container 두 가지 기본 요소 유형을 정의합니다. container는 leaf와 다른 container의 모음일 수 있습니다. 이를 통해 tree와 유사한 중첩 및 재귀적 객체 구조를 구성할 수 있습니다.

<div class="content-ad"></div>

자료:

- Java. Wzorce projektowe. 번역: Piotr Badarycz. 원제: Java design patterns. A Tutorial. 저자: James William Cooper
- [Composite Design Pattern - Refactoring Guru](https://refactoring.guru/pl/design-patterns/composite)
- [Composite Design Pattern - Java.edu.pl](https://java.edu.pl/inne/designPatterns/8.composite.php)

Angular에서 디자인 패턴과 관련된 다른 내 기사:

구조 패턴:
- Angular에서 프록시 디자인 패턴
- Angular에서 어댑터 디자인 패턴
생성 패턴:
- Angular에서 빌더 디자인 패턴

<div class="content-ad"></div>

영어 실력이 좋지 않아요. 영어 실력 향상을 위해 글을 쓰고 있어요.

Angular에서 Composite 디자인 패턴 사용 방법




![Angular for React Developers](/assets/img/2024-07-30-AngularforReactDevelopers_0.png)

안녕하세요! 오늘부터 Angular에 대해 이야기하는 시리즈 기사를 시작하려고 합니다. Angular는 JavaScript를 사용하여 구성 요소를 쉽고 빠르게 구축하는 UI 프레임워크입니다. 주로 React 개발자를 대상으로 하지만 JavaScript UI 프레임워크로 전환을 고려 중인 누구에게나 유용할 것으로 기대합니다.

저는 여러 해간 React 개발자로 일해왔으며 React는 UI 개발을 사랑하게 만들었습니다. 몇 년 전에 새로운 회사에 합류하면서 수년간 쌓인 코드베이스 위에 빌드해야 했기 때문에 Angular로 전환해야 했습니다. 이 기사들은 제가 그 전환이 시작된 때 손에 쥐고 있었으면 했던 가이드입니다.

두 프레임워크 간의 주요 차이점, Angular에서 좋아하는 점과 React에는 없어 아쉬운 부분, 그리고 Angular에 있었으면 했던 React의 부분 등을 이야기해보고 싶습니다. 논의해야 할 다양한 주제들이 많아서 각각을 세부적으로 다루는 부분으로 나눠 보려고 합니다.

<div class="content-ad"></div>

# React로의 나의 경험

우리가 React에 대해 이야기하는 것으로 시작해봅시다. 나는 Allstate의 딜러 서비스 부서에서 Extended Care 제품을 작업하기 시작했을 때, 대략 여섯 년 전(이 글을 쓰는 시점으로부터) React를 시작했습니다. 이전에는 Red Hat JBoss와 Java Server Pages (JSPs)로 작성된 HTML 사용자 인터페이스 같은 백엔드 서버에서 작업한 적이 있었지만, React를 사용한 UI 개발은 처음이었습니다. JQuery와 같은 프레임워크를 포함한 JavaScript에 대한 경험이 많았지만, 실제 페이지 로직의 대부분은 Java 코드로 작성되었습니다.

멘토를 찾는 것은 새로운 것을 배우는 좋은 방법이라는 것을 알게 되었고, 내가 React를 빠르게 익힐 수 있도록 도와준 Allstate의 멘토가 있어서 운이 좋았습니다. React를 배우는 것 뿐만 아니라 Redux와 같은 다른 프레임워크들도 사용되었기 때문에 제대로 개발할 수 있는 수준에 이르는 데 약 한 달이 걸렸습니다. Allstate의 팀은 페어 프로그래밍을 사용했는데, 이는 많이 도와줬습니다. 페어 프로그래밍에서는 한 명이 드라이버(실제로 키보드를 다루는 사람)이 되고, 다른 한 명이 네비게이터(드라이버를 안내하고 함께 고민하는 역할)였습니다. 새로 온 나는 드라이버로서, 이는 나를 배우는 과정에서 개념을 강화하는 데 도움이 되었습니다.

JSP 페이지를 이전에 작성했던 것과 비교했을 때, React는 상쾌한 바람같았고, UI 페이지를 작성하는 것이 정말 즐겁게 느껴졌습니다. 나는 종종 JavaScript를 싫어했었는데, 그 이유는 주로 타입이 없고 이해하기 어려운 방식으로 스크립트를 작성할 수 있기 때문이었습니다. React는 JavaScript에 대한 제약을 해소해주는 구조를 제공했고, TypeScript를 사용하여 타입 안전성을 확보할 수 있었습니다.

<div class="content-ad"></div>

나는 React 여정 몇 년을 거쳐 NextJS를 발견했다. NextJS는 React를 기반으로 만들어졌지만, 설정의 복잡성을 제거합니다. 설정 파일 보일러플레이트 대신 설정 설정을 재정의하기만 하면 되므로 고급 스타일시트 프레임워크인 SASS와 SCSS와 같은 고급 기능과 같이 정적 및 서버 측 렌더링을 지원합니다. NextJS와 같은 프레임워크로 프로젝트를 시작할 수 있다는 것은 개발 과정을 훨씬 원활하게 만들어 줍니다.

# Angular로의 전환

React 개발을 하면서 나는 React보다 더 나은 UI 개발 프레임워크를 찾고 있었습니다. 내 관심을 끈 몇 가지 흥미로운 프레임워크가 있었고 Angular도 그 중 하나였지만, 문법이 이상하고 React의 문법처럼 명확하지는 않았습니다.

React는 JSX라는 자체 비표준 구문을 갖고 있어 기본적으로 HTML과 JavaScript를 결합한 것이었는데, 처음에는 이것이 이상하게 느껴졌지만, 결국 view와 비즈니스 로직을 결합하는 우아한 방법으로 보였습니다. 나중에 클래스 기반 컴포넌트 대 함수형 컴포넌트 및 React Hooks에 대해서도 이야기할 것이지만, 함수형 컴포넌트와 React Hooks가 내가 가장 좋아하는 React의 부분입니다.

<div class="content-ad"></div>

올스테이트(Allstate)처럼, 새로운 회사에서 멘토를 만나 세계를 가르쳐 주신 분이 있어서 Angular에 대한 학습을 빠르게 적응하고 이제는 React보다 거의 선호합니다. 거의라고 말하는 이유는 React가 더 잘 처리하는 부분이 여전히 있기 때문입니다. 두 프레임워크를 대조하고 비교하는 것이 이 시리즈의 실제 주제입니다.

한 문서로 모든 것을 다루는 것은 불가능할 것이며, UI 개발의 여러 측면에 대해 React와 Angular가 다르게 다루는 방식에 대해 자세히 살펴볼 예정입니다. 또한 이 프레임워크와 함께 작동하여 UI 개발을 매력적으로 만드는 몇 가지 다른 프레임워크에 대해 언급할 것입니다. 흥미로운 다른 UI 프레임워크에 대한 몇 가지 언급도 있을 수 있지만, 주력은 Angular와 React에 있을 것입니다.

# Angular와 React에서 HTML 비교

먼저 Angular와 React에서 HTML 처리 방식에 대해 이야기하겠습니다. 어차피 이 두 프레임워크가 하는 일은 HTML 생성입니다. 나는 구시대적이어서 모든 HTML을 손으로 작성했던 시절에 소프트웨어 개발을 시작했습니다. 요즘에는 인터넷에서 보는 대부분의 HTML이 사용자가 페이지와 상호작용할 때마다 동적으로 생성됩니다.

<div class="content-ad"></div>

React에서 JSX를 사용하면 HTML이 JavaScript 코드와 통합됩니다. 많은 개발자들이 JSP를 작성하거나 PHP를 사용하는 것에 익숙한 경우, 조금 이상하게 느껴질 수 있습니다. JSP와 PHP 파일은 코드가 포함된 템플릿인 반면 JSX는 특정 위치에 HTML이 삽입된 JavaScript 파일과 같은 느낌입니다. 때로는 문자열, 숫자 또는 변수를 반환하는 대신 HTML 조각을 반환할 수도 있습니다:

```js
class UserComponent extends React.Component {
  function userToString(user) {
    return user.firstName + ' ' + user.lastName;
  }

  const user = {
    firstName: 'Manny',
    lastName: 'Ramirez'
  };

  render() {
    return (
      <div>
        <h1>Welcome</h1>
        <div>Greetings, {userToString(user)}!</div>
      </div>
    );
  }
}
```

React의 모든 컴포넌트는 HTML 객체 중 하나를 반환하며(렌더 메서드를 통해 또는 기능 컴포넌트의 반환 값으로), 그 안에 일부 코드가 포함될 수 있습니다.

Angular에서는 JavaScript 파일에 HTML을 지정할 수 있지만 일반적으로 HTML은 별도의 파일에 제공됩니다. HTML 파일에는 동적 부분을 위한 특별한 구문이 있으며, JSP나 PHP를 사용한 적이 있는 사람들에게 익숙한 느낌입니다.

<div class="content-ad"></div>

```js
# 환영합니다!

안녕하세요, { user }님! 여기에는 여러분의 메시지가 있어요:

<div *ngFor="let message of messages">
  <h2>{ message.subject }</h2>
  <div>{ message.body }</div>
  <hr/>
</div>

이 컴포넌트의 비즈니스 영역은 JavaScript 클래스로 둘러싸여 있습니다:

@Component({
    selector: 'app-sample',
    templateUrl: './sample.html',
    styleUrls: ['./sample.scss'],
})
export class Sample {
    @Input user: User;
    @Input messages: Array<Message>;

    someMethod() {
       ...
    }
}

이 문서에서 문법의 세부 사항을 다루지는 않겠지만, 비즈니스 로직이 뷰와 분리되어 있다는 것을 알 수 있습니다.

<div class="content-ad"></div>

앵귤러와 리액트는 모두 많은 컴포넌트에서 하나의 HTML 페이지를 만듭니다. 결과적으로 생성되는 HTML은 하나의 루트 노드를 가진 XML 트리입니다. 리액트와 앵귤러의 큰 차이점 중 하나는 리액트에서 컴포넌트가 항상 하나의 루트 노드를 갖는 HTML을 반환한다는 것입니다. 이것은 큰 제약은 아니지만 가끔은 다른 HTML 주변에 임의의 div 태그를 추가해야 할 때가 있습니다. 이 요구 사항을 충족시키기 위해 단지 이 div 태그를 넣어야 하는 경우를 피하기 위해 React.Fragment라는 특별한 컴포넌트가 만들어졌습니다. 반면 앵귤러는 반환된 HTML에 대해 이러한 제한을 두지 않습니다. 본질적으로, 앵귤러의 각 HTML 파일은 적절한 위치에 삽입된 프래그먼트입니다.

앵귤러와 리액트 HTML 사이의 또 다른 기본적인 차이점은 데이터 바인딩과 이벤트의 구문입니다. 리액트에서는 이러한 바인딩이 일반 HTML 속성과 유사하게 보이며 컴포넌트에 속성으로 전달됩니다. 또한, 이벤트 바인딩은 클릭과 같은 이벤트에 대해 자바스크립트 코드를 실행하는 개발자들이 익숙한 구문을 사용하여 바인딩합니다. 다만 호출할 함수의 이름만 제공하면 되는 겁니다:

...
render() {
  return (
    <div>
      <UserForm user={user} />
      <button onclick="handleButtonClick">Click Me!</button>
    </div>
  );
}
...

반면 앵귤러는 데이터 바인딩에 사용되는 속성에 특수 문자를 넣으며, 이 바인딩은 단방향 또는 양방향일 수 있습니다. 또한 이벤트 바인딩에 다른 문자를 사용합니다.

<div class="content-ad"></div>

<input type="text" ([ngModel])="title" />
<userform [user]="user" (changed)="handleFormChange($event)"></userform>
<button (click)="submitForm()">Submit</button>

이 입력란은 양방향 데이터 바인딩을 보여줍니다. 입력란의 값은 title이라는 변수이며, 입력란 내에서 업데이트가 이루어지면 동일한 변수 title이 업데이트됩니다. userform 컴포넌트는 단방향 바인딩을 나타내며, user 변수가 입력으로 전달되지만 출력으로 전달되지 않습니다. userform에서 발생하는 changed 이벤트는 handleFormChange 메서드를 호출합니다 ($event는 이벤트에서 전달된 데이터를 나타내는 특별한 구문입니다). 버튼 클릭 이벤트 핸들러에 표시된 것처럼 이벤트 구문은 마우스 및 키보드 이벤트에 사용됩니다.

React와 Angular 간의 차이 중 일부이며, 이후의 기사에서 더 다루겠지만, 지금까지 다룬 내용은 Angular와 React에서 페이지가 어떻게 구축되는지의 차이에 대한 통찰력을 제공하며, 한쪽에서 다른 쪽으로 옮겨갈 때 조금 익숙해지는 데 약간의 시간이 필요한 이유를 설명했습니다.

# 결론
```

<div class="content-ad"></div>

UI 개발 세계에서의 내 여정은 Java에서 시작되었습니다. 그곳은 무겁고 효율적이지 않았지만, 그 후 React를 발견하게 되면서 상황이 바뀌었습니다. React에서 앱을 개발하는 것을 정말 즐겼지만, 새 직장으로 전환하면서 Angular를 알게 되었고, 이제는 그것을 사용하고 있어요. 이러한 프레임워크에서 어떻게 앱이 개발되는지에는 많은 차이가 있고, HTML이 작성되는 방식만 해도 그것의 한 예시입니다. 이후에는, 상태 관리, 모듈화, 다른 프레임워크와의 통합, 비동기 이벤트, 그리고 각각의 프레임워크에서 독특한 기능과 같은 다양한 차이점에 대해 살펴볼 것입니다.

React 개발자를 위한 Angular 가이드




<img src="/assets/img/2024-07-30-Welcometosummer_0.png" />

극한 열기에서 약간의 주의를 하여 다양한 질병으로부터 자신을 보호하세요.

6월이 지나면 햇볕처럼 진짜 색을 드러내는데, 태양처럼, 뜨거운 햇볕, 그 열기, 그 뜨거움의 강도는 너무 강해서 사람들은 보통 갈증을 느끼게 됩니다. 인간의 몸이 상대적으로 더 많은 땀을 내기에 이른 겨울이다. 

보통 활동에 따라 인간의 몸에서 발생하는 땀은 대부분인데, 이로 인해 몸속 소금의 양이 설명되고 이는 인체 내에서의 질병 증가로 이어집니다.

<div class="content-ad"></div>

# 해결책

![image](/assets/img/2024-07-30-Welcometosummer_1.png)

덥고 짜증나는 문제를 해결하기 위한 해결책은 물을 최대한 많이 마시고 여름철에 가장 중요한 것에 대해 신경 써야 합니다. 방광 염증과 같은 여러 질병이 있으며 열에 의한 즉시적인 영향을 받는 경우가 많기 때문에 물을 최대한 활용해야 합니다.

아침은 라씨와 우유와 함께 섭취해야 하며, 이를 통해 열의 강도가 떨어지는 것을 느낄 수 있습니다. 그와는 반대로,

<div class="content-ad"></div>

여름철에 이중 빵 상자는 위장에 속쓰림을 일으키며 심장을 더 빨리 뛰게 만들기도 합니다. 그리고 이러한 흐름 중 많은 것들을 교란시켜 버리기도 하므로, 여름에 주로 소비하는 주스를 섭취하는 것이 중요합니다. 음식에 사용되는 신선한 채소 중에는 차가운 상태의 신선한 채소가 인간 몸에 매우 유용합니다.

여름철에는 수분 섭취 욕구가 높아져 사람들이 섭취해야 하는 음료를 찾게 됩니다. 많은 경우, 사람들은 길을 가다가 주스를 소비하는 것을 좋아합니다. 그러나 사람의 몸의 갈증을 해소하는 대신, 주스는 오히려 인체 시스템을 악화시킬 수 있는 요인입니다. 여름철에는 팔과 팔 주스가 널리 사용됩니다.

인도의 여름철에는 알루 부크하라 시럽을 마시는 것이 권장됩니다. 비록 산뜻하지만, 감기를 치료할 수 있습니다. 혈액 순환 및 기타 다양한 기능에 도움을 주는 예측 규칙이 있습니다.

Posts