PyYAML 사용 시 키 이름 “on”이 True로 바뀌는 사례


환경

  • GitHub Actions
  • Python
  • PyYAML


배경

  • GitHub Actions Workflow 파일을 동적으로 Python을 통해 수정하는데 YAML 파일 파싱시 on이라는 키가 True로 바뀌는 상황이 발생해서 정리.


예시

아래와 같이 Python에서 yaml을 통해 파일을 읽어서 출력하면 on이 사라지고 True가 들어가 있는걸 볼 수 있다.

코드

import io
import yaml

file_content = """
name: Workflow Complete Event Test

on:
  workflow_run:
    workflows: [ "Push Main Branch" ]
    types:
      - completed
"""

file_like_object = io.StringIO(file_content)
yaml_content = yaml.safe_load(file_like_object)

print(yaml_content)

결과

{'name': 'Workflow Complete Event Test', True: {'workflow_run': {'workflows': ['Push Main Branch'], 'types': ['completed']}}}


이유

검색해보니 PyYAML의 경우 YAML 1.1 버전을 지원하고 있으며 1.1 버전의경우 "on"은 boolean으로 간주되며 그렇기에 True로 바뀌는게 맞다고 한다. YAML 1.2를 아직 지원하지 않다고 하기에 의도된 동작이며 방법을 따로 찾아야한다.


해결 방법

여러가지 방식이 있다.

  • Loader의 코드를 변경해서 설정
  • Key에 따옴표("" 또는 '')를 사용
  • 다른 Python 모듈 사용

따옴표가 눈에 띄어서 없애고 싶은 마음이 들지만 두번째 방식이 가장 간단해보이고 기존 yaml 모듈 변경이 없어서 해당 방식을 적용했다.

코드

import io
import yaml

file_content = """
name: Workflow Complete Event Test

'on':
  workflow_run:
    workflows: [ "Push Main Branch" ]
    types:
      - completed
"""

file_like_object = io.StringIO(file_content)
yaml_content = yaml.safe_load(file_like_object)

print(yaml_content)

결과

{'name': 'Workflow Complete Event Test', 'on': {'workflow_run': {'workflows': ['Push Main Branch'], 'types': ['completed']}}}


기타

True를 키 이름으로 사용

  • 키가 True로 잡히는데 Python에서 True를 사용하니 접근이 가능했다.

코드

import io
import yaml

file_content = """
name: Workflow Complete Event Test

on:
  workflow_run:
    workflows: [ "Push Main Branch" ]
    types:
      - completed
key:
  on: "test"
"""

file_like_object = io.StringIO(file_content)
yaml_content = yaml.safe_load(file_like_object)

print(yaml_content[True])

결과

{'workflow_run': {'workflows': ['Push Main Branch'], 'types': ['completed']}}


YAML 파일 생성 시 생성되는 키 이름

  • 여기서 yaml.dump를 통해 파일을 만들면 키는 true로 들어간다.

코드

import io
import yaml

file_content = """
name: Workflow Complete Event Test

on:
  workflow_run:
    workflows: [ "Push Main Branch" ]
    types:
      - completed
key:
  on: "test"
"""

file_like_object = io.StringIO(file_content)
yaml_content = yaml.safe_load(file_like_object)

with open('example.yaml', 'w') as file:
    yaml.dump(yaml_content, file)

결과

$ cat example.yaml
name: Workflow Complete Event Test
true:
  workflow_run:
    types:
    - completed
    workflows:
    - Push Main Branch
key:
  true: test


참고자료

Case of converting key name “on” to True when using PyYAML


Environment and Prerequisite

  • GitHub Actions
  • Python
  • PyYAML


Background

  • on key was automatically changed to True when modifying GitHub Actions Workflow file dynmically using Python.


Example

When reading and outputting a file using yaml in Python as shown below, you’ll notice that on is replaced with True.

Code

import io
import yaml

file_content = """
name: Workflow Complete Event Test

on:
  workflow_run:
    workflows: [ "Push Main Branch" ]
    types:
      - completed
"""

file_like_object = io.StringIO(file_content)
yaml_content = yaml.safe_load(file_like_object)

print(yaml_content)

Result

{'name': 'Workflow Complete Event Test', True: {'workflow_run': {'workflows': ['Push Main Branch'], 'types': ['completed']}}}


Reason

According to searching, PyYAML supports YAML 1.1 and in version 1.1, "on" is considered as a boolean value which is why it gets converted to True. Since YAML 1.2 is not yet supported, this behavior is intentional, and you will need to find an alternative solution.


Solution

There are many ways to solve it.

  • Modify Loader code
  • Use quote("" or '') to key
  • Use another Python module

Although I was tempted to remove the quotation marks, the second method seemed the simplest and didn’t require changes to the existing YAML module, so I applied that approach.

Code

import io
import yaml

file_content = """
name: Workflow Complete Event Test

'on':
  workflow_run:
    workflows: [ "Push Main Branch" ]
    types:
      - completed
"""

file_like_object = io.StringIO(file_content)
yaml_content = yaml.safe_load(file_like_object)

print(yaml_content)

Result

{'name': 'Workflow Complete Event Test', 'on': {'workflow_run': {'workflows': ['Push Main Branch'], 'types': ['completed']}}}


Others

Use True as key name

  • Key is set to True and it can be accessed via True in Python.

Code

import io
import yaml

file_content = """
name: Workflow Complete Event Test

on:
  workflow_run:
    workflows: [ "Push Main Branch" ]
    types:
      - completed
key:
  on: "test"
"""

file_like_object = io.StringIO(file_content)
yaml_content = yaml.safe_load(file_like_object)

print(yaml_content[True])

Result

{'workflow_run': {'workflows': ['Push Main Branch'], 'types': ['completed']}}


Key name after YAML file created

  • Key is set to true if make file via yaml.dump.

Code

import io
import yaml

file_content = """
name: Workflow Complete Event Test

on:
  workflow_run:
    workflows: [ "Push Main Branch" ]
    types:
      - completed
key:
  on: "test"
"""

file_like_object = io.StringIO(file_content)
yaml_content = yaml.safe_load(file_like_object)

with open('example.yaml', 'w') as file:
    yaml.dump(yaml_content, file)

Result

$ cat example.yaml
name: Workflow Complete Event Test
true:
  workflow_run:
    types:
    - completed
    workflows:
    - Push Main Branch
key:
  true: test


Reference

DynamoDB Throttling 발생 사례 정리


환경

  • AWS
  • DynamoDB


배경

  • DynamoDB 프로비저닝된 모드에서 Auto Scaling 사용 시 Throttling이 발생해서 이유를 조사해서 정리함.


이슈

  • DynamoDB 프로비저닝된 모드에서 Auto Scaling 설정을 사용했음에도 Throttling이 발생함.


이유

DynamoDB 관련 개념과 용어 정리

  • 내용을 정리하기 앞서서 몇 가지 개념과 용어가 새로 나와서 정리한다.

온디맨드 모드와 프로비저닝된 모드

  • 온디맨드 모드: 용량 계획 없이 초당 수백만 개의 요청을 처리할 수 있는 서버리스 청구 옵션으로 사용한만큼 지불하는 방식으로 보면 된다.
  • 프로비저닝된 모드: 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정할 수 있으며 Auto Scaling을 사용하여 트래픽 변경에 따라 테이블의 프로비저닝된 용량을 자동으로 조정할 수 있다.
  • 관련 링크: https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/capacity-mode.html

WCU와 RCU

  • 프로비저닝된 용량 모드에서 애플리케이션에 필요한 초당 데이터 읽기 및 쓰기 단위이다.
  • WCU: 테이블에서 데이터를 쓰는 각 API 호출이 쓰기 요청이다.
  • RCU: 테이블에서 데이터를 읽는 각 API 호출이 읽기 요청이다.
  • 각 WCU 및 RCU에 대한 용량은 공식 문서에 나와있다.
  • 관련 링크: https://aws.amazon.com/ko/dynamodb/pricing/provisioned/

Auto Scaling

  • 위에 설명한 용량 단위의 최솟값 및 최댓값 그리고 목표 사용률 설정할 수 있다.
  • 목표 사용률에 따라 최솟값 및 최댓값 사이에서 용량을 조절한다. 간단하게 예를 들어 목표 사용률이 70% 이고 700 RCU를 사용한다면 1000 RCU를 프로비저닝 해둔다. 아래 정리하겠지만 남은 300 RCU를 패딩(Padding)이라 한다.
  • 관련 링크: https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/AutoScaling.html

패딩(Padding), 버스트 용량 그리고 Spike


Spike 발생 시 Throttling 발생 이유

  • 프로비저닝된 용량을 훨씬 넘어서는 Spike(갑작스러운 데이터 요청) 발생 시 아래와 같은 순서로 요청이 처리될 수 있다고 한다.
목표 사용률 이하 RCU 사용
-> 모든 RCU(목표 사용률 이하 RCU + Padding)를 통해 처리
-> 버스트 용량에서 처리
  • Spike에 대해 그래프에서와 같이 처음에는 버스트 용량에서 처리되다가 버스트 용량을 다 소진하면서 Throttling이 발생한다. 이후 Auto Scaling이 완료된 이후에는 Throttling이 사라진다.
  • 문서에 따르면 “Auto scaling triggers when your consumed capacity breaches the configured target utilization for two consecutive minutes. CloudWatch alarms might have a short delay of up to a few minutes before triggering auto scaling.”라고 나와있다.
  • DynamoDB의 경우 Auto Scaling이 일어나려면 CloudWatch에 1분간 연속해서 사용된 값이 목표 사용률을 넘어야 한다고 했다. 그렇기에 아래와 같은 이유로 지연이 생기게 되며 이게 순간적인 많은 요청에 대해 Throttling을 발생 시킨다.
    • CloudWatch에 표시되려면 약간의 시간 지연이 필요하다.
    • CloudWatch에 연속된 1분동안 목표 사용률을 넘는 상황이 발생하면 Auto Scaling을 시작한다.
    • Auto Scaling이 되는 과정에서 위에서 언급한 “목표 사용률 이하 RCU 사용 → 모든 RCU(목표 사용률 이하 RCU + Padding)를 통해 처리 → 버스트 용량에서 처리”를 넘어서는 요청에 대해서는 Throttling이 발생한다.
  • 관련 링크: https://aws.amazon.com/ko/blogs/database/handle-traffic-spikes-with-amazon-dynamodb-provisioned-capacity/
  • 관련 링크: https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/AutoScaling.html


작가의 생각

  • Auto Scaling에서도 급격한 요청에 대해서는 Scaling을 탐지하는 부분과 조정하는 시간이 필요하기에 앞으로 설계시 이에 대한 고려도 하면 좋을거 같다.
  • 관련 조사를 진행하면서 DynamoDB Auto Scaling에 대해 많이 배웠다.
  • 예상하지 못한 급격한 트래픽 요청에 대해서는 알람이 오게 해야하며 트랙픽 증가가 예정된 부분이 있다면 점검하는 습관을 만들어야겠다.


참고자료

Post about case of DyanmoDb throttling


Environment and Prerequisite

  • AWS
  • DynamoDB


Background

  • Investigated and summarized the reasons for throttling when using auto scaling in DynamoDB provisioned mode.


Issue

  • Throttling occurs in DynamoDB even though auto scaling is set in provisioned mode.


Reason

  • Before summarize content, let me clarify some concepts and words.

On-demand capacity mode and Provisioned capacity mode

  • On-demand capacity mode: A serverless billing option that can serve millions of requests per second without capacity planning. Easily say pay what I used.
  • Provisioned capacity mode: Specify the number of reads and writes per second that you require for your application. We can use auto scaling to adjust your table’s provisioned capacity automatically in response to traffic changes.
  • Related Link: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html

WCU and RCU

  • Specify the number of data reads and writes per second that you require for your application. Unit of read and write in provisioned mode.
  • WCU: Each API call to write data to your table is a write request.
  • RCU: Each API call to read data from your table is a read request.
  • Each size of WCU and RCU is on official document.
  • Related Link: https://aws.amazon.com/dynamodb/pricing/provisioned/

Auto Scaling

  • We can set minimum, maximum provisioned capacity unit as mentioned in above and target utilization.
  • Capacity is controlled between minimum and maximun following to target utilization. For example if target utilization is 70% and use 700 RCU, then provisioned would be 1000 RCU. I will explain later but rest 300 RCU are called padding.
  • Related Link: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html

Padding, Burst Capacity and Spike


Reason of Throttling When Spike Occurs

  • When a spike(sudden request traffic) exceeds the provisioned capacity, requests may be processed in the following order.
Use RCU under Target Utilization
-> Use All RCU(RCU under Target Utilization + Padding)
-> Use Burst Capacity
  • In spike, as shown in the above graph, firstly burst capacity handles requests and then throttling occures after use all prepared burst capacity. After auto scaling is done, then throttling disappears.
  • In document it says “Auto scaling triggers when your consumed capacity breaches the configured target utilization for two consecutive minutes. CloudWatch alarms might have a short delay of up to a few minutes before triggering auto scaling.”.
  • In DynamoDB auto scaling occurs when consumed capacity breaches the configured target utilization for two consecutive minutes. Therefore, delays occur for the following reasons, leading to throttling in reponse to spike in requests.
    • There is a short delay of up to CloudWatch.
    • Auto scaling will be started when consumed capacity breaches the configured target utilization for two consecutive minutes.
    • Throttling occurs in process of auto scaling over above “Use RCU under Target Utilization -> Use All RCU(RCU under Target Utilization + Padding) -> Use Burst Capacity” requests.
  • Related Link: https://aws.amazon.com/blogs/database/handle-traffic-spikes-with-amazon-dynamodb-provisioned-capacity/
  • Related Link: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html


Author’s Thoughts

  • Due to scaling timing detection and setting time in auto scaling, it is good to consider about it when designing.
  • I learned many things about DynamoDB auto scaling.
  • Make alarm for unexpected sudden increase traffic. Make habit of review capacity when there is plan to have more traffic.


Reference

상반기 회고


작성 이유

  • 상반기 과제가 끝나기도 했고 의무감도 있고 남은 2024년을 계획 할 마음으로 작성한다.
  • 항상 글을 작성하면 머릿속에 너무 많은 생각이 있어서 글이 많이 길어지는데 짧게 필요한 내용만 작성하려 한다. 회사 업무, 개인 업무 그리고 자기 개발정도에 대해서만 적어보겠다.


회사 업무

1월부터 6월까지

1월

새로운 업무들을 받아서 했으나 중간에 한번 업무가 바뀌었다. 관련해서 새로 배우는 기간으로 실질적인 업무를 하기보다는 따라가기에 바빴다. 기존에 하던 업무를 병행해서 진행했다. 새로 익히고 하는 기간이라 정신없이 지나갔다.

2월~3월

서비스 측과 소통하면서 시스템을 연결하는 업무를 했다. 관련하여 일을 하면서 소통하는 부분이 업무에 있어서 큰 부분을 차지한다는 걸 깨달았고 디버깅하면서 작은 단편적인 지식을 배우게 되었다. 앞선 일들과 작은 이슈 해결과 기능 개발 정도만 했다. 많은 사람들과 소통하면서 엔지니어의 또 다른 능력으로 소통하는 게 정말 중요하다는 걸 느꼈다. 특별하게 어떤 소통의 기술이 늘어났다고 할 수 있을지는 모르지만 약간의 두려움이 사라지고 맷집이 생긴 거 같다.

4월~6월

과제의 마감이 6월이었기에 과제 마감을 위한 작업을 했다. 작은 이슈들을 수정하고 소통도 열심히 했다. 정말 “이걸 우리가 다 할 수 있을까?” 하는 과제였는데 마무리가 된 거 같다. 꽤 오래 했던 과제라 마무리한 만큼 뿌듯했다. 이전과 마찬가지로 작은 이슈 해결이나 기능 개발 정도만 했다.


그래서 1월부터 6월은?

앞서 기록을 다 했지만… 뭔가 성과를 냈다고 할 수 있는 무언가를 만들지는 못했다. 6월에 마무리해야 하는 과제를 향해 열심히 달렸으며 중간에 어려운 상황들을 해결하긴 했다. Terraform 관련한 이슈도 찾아내고 새로운 데이터베이스 관련 코드도 추가하고 갑작스러운 이슈에 케이스를 오픈해 해결하기도 하고 네트워크 연결이 안 되는 부분도 서비스 측과 소통하면서 하나씩 해결했다. 개발 관련된 부분들을 뒤로하고 오직 6월 과제 완수만을 바라보며 달렸던 거 같다. 마무리해서 뿌듯하다. 이제는 밀렸던 부분들을 정리하고 새로운 기능들을 개발했으면 좋겠다. (물론 쉬면 더 좋겠다!)

6월까지 지내오면서 느낀 몇 가지만 짧게 정리하면 아래와 같다.

  • 엔지니어에게 소통 능력은 개발 능력만큼 중요하다. 서로가 같은 생각을 하고 있는지 확인하는 부분, 업무를 전달하는 부분, 요구사항을 이해하는 부분 이런 모든 부분이 소통에 속하는 거 같다. 이러한 부분들이 잘 이루어지지 않으면 결국 만들어내는 소프트웨어 제품에 영향이 갔었다. 예를 들어 업무를 전달했는데 이해한 부분이 달라서 다시 요청하거나 생각했던 범위가 달라서 다시 이야기하거나 하는 부분들이 있었다.
  • 여러 방면으로 의심을 해봐야 한다. 사람은 실수할 수 있으며 그 과정을 하나하나 볼 필요가 있다. 여기서 의심은 누군가를 비난하는 게 아니라 사람이 입력하는 것과 같은 부분이 있으면 문제가 생길 수 있음을 알아야 하고 소통해서 확인해야 한다. 사람뿐만 아니라 오픈소스도 의심할 필요가 있다. 사람이 검증하는 부분이기에 실수가 있을 수 있으며 이슈가 생겼을 때 바라볼 필요가 있다. 실제로 항상 최신 코드를 가져와서 사용하다가 이슈가 발생한 적이 있었다. 처음에 의심하지 않아 다른 길로 빠질 수도 있었었는데 관련한 내용을 우연히 검색으로 발견할 수 있었다.
  • 기술이 다가 아니다. 10분 만에 해결될 일이 감정 문제로 10일이 걸릴 수도 있다. 개발은 완료되었지만, 서비스 측에 갑자기 생긴 프로세스로 업무가 늘어난 사례가 있었다. 실무자의 협조가 어렵다고 한 부분을 매니저 또는 더 위에 상급자의 도움을 받아서 더 빠르게 해결한 경우도 있었다. 이렇듯 때로는 개발만이 아닌 사람을 통해서도 문제가 해결될 수 있는 거 같다.

기술적으로 어떤 걸 만들거나 큰 업적이나 멋진 말이 없어서 실망스러울 수도 있지만 개발 외에 관련한 부분들을 많이 배운 거 같다.

관리나 행정적인 부분에서 이해가 안 가는 부분들이 있었다. 팀원 혹은 업무의 분배나 타 부서와의 협업이나 위에서부터 내려오는 일 등등에 대해 물음표가 생길 때가 꽤 있었다. 여러 높은 의사 결정권자들을 회사와 정치에서 보면서 “과연 나라면 어떻게 했을까?”라는 질문을 많이 했었다. 속으로 화가 날 때 답답할 때 그리고 이해가 안 갈 때가 더 많았던 거 같다.

유독 이번에는 집중하기 어려운 환경이었다. 일하는 중간에 인터럽트가 자주 발생했었다. 이슈가 발생하거나 다른 업무 요청이 오거나 우선순위가 바뀌는 거와 같은 여러 요인이 있었다. 스프린트에 있는 티켓을 가져가서 개발을 집중해서 하고 싶은데 여러 요청과 이슈가 생기면서 집중하기 어려웠고 생산성이 저하되는 일이 있었다. 내 개인 능력의 문제도 맞지만, 팀원 전체가 같은 부분을 느꼈기에 이러한 부분이 개선되었으면 어떨까 싶었고 나라도 조금씩 개선해 보고 싶다.

문득 생각이 들었는데 체력적으로나, 정신적으로 약간 지친 거 같기도 하다. 나태해진 부분도 있었다. 해야 할 일을 뒤로 미루기도 하고 사실 피한 적도 있었다. 도와드려야 하는 상황에 여유가 없어서 내 일만 한 적도 있었다. 지친 게 원인이었던 거 같고 여러 가지 신경 쓸 일들이 생겨서 그런 거 같다. 무리해서 달리면 무조건 탈이 나기 때문에 앞으로는 지치거나 힘들 때는 쉴 생각이다.

사실 쓰고 싶은 이야기와 생각이 너무도 많지만 이번에는 여기까지만 쓰겠다. 평소에 생각이 많았는데 적으려니 중구난방이라 앞으로는 생각날 때마다 일기에라도 정리해 봐야겠다.


개인 업무와 자기 개발

블로그

내가 소중하게 여기는 블로그로 최대한 시간을 내서 쓰고 있다. 예전에는 공부한 내용이나 기록을 주로 했었는데 요즘은 사례 중심으로 글을 쓰고 있다. 여전히 글 하나를 쓰는 데는 긴 시간이 걸린다… 최소 3시간 정도는 걸리는 거 같다. 남들한테 보이는 글이고 생각보다 많은 사람들이 본다는 생각에 많은 시간을 쓰는 거 같다. 그런데 여기에만 시간을 투자해서 다른 공부를 못하는데 여전히 개선해야 할 부분이다. 영어로도 꼭 쓰는데…. 여기서도 시간이 오래 걸린다. 따로 시간을 내서 영어 쓰기 공부를 안 하고 있어서 이렇게라도 영어 쓰기를 공부하자는 마음에 하는 거라 그만둘 수 없다. 하지만 요즘은 번역기에 많이 의존하고 있다 으악.

앞으로도 여러 가지 내용의 글을 쓸 예정이다. 공부한 내용, 기록, 사례 등등 더 다양한 글로 형식에 얽매이지 않고 쓸 예정이다.

게임

이전 회고에서도 작성했지만 게임을 만들고 메시지를 전달하고 싶다. 그래서 퇴근 후 혹은 주말에 시간을 내서 공부하고 있다. Unity는 어느 정도 공부를 해서 최근에는 그림을 직접 그리려고 일러스트레이터를 공부하고 있다.

요즘에 체력이 내 마음을 따라가지 못해서 거의 못하고 있는데… (마음이 아프다ㅠ 내 몸이여!) 10분이라도 공부하려고 노력하고 있다.

올해 말에는 리소스를 그릴 수 있고 게임 줄거리가 나와서 개발에 들어가는 게 목표다. 얼른 게임을 만들어서 메시지도 전하고 사람들에게 감동이나 여운을 주고 싶다.

영어 공부

마음 같아서는 영어, 스페인어, 중국어 등등 많은 외국어를 하고 싶은데 역시나 세상은 쉽지 않다. 시간이 없어서 출근할 때 그리고 운동할 때마다 영어 회화를 듣고 있다. 시간 없으니 이렇게라도 꾸준하게 공부할 예정이다.

전공 및 개발 공부

사실 따로 정리할 필요가 없는 게 항상 어디를 가나 궁금한 부분들이 생기고 찾아보는 거 같다. 회사에 많은 교육 과정도 있어서 하게 되면 자연스럽게 공부도 하게 된다. 이 정도만 꾸준하게 유지할 수 있으면 좋겠다.

회사 DX 크리에이터

내 목표 중 하나인 큰 무대에서 발표하는 것을 연습하기 위해 올해 DX 크리에이터에 지원했고, 합격하여 활동했다. DX 크리에이터란 DX(Device eXperience)부문의 임직원이 회사 생활을 알리는 영상을 직접 기획, 출연, 촬영 및 편집하는 활동이다. 단순히 업무만 하는 것보다 목표에 다가가고 발표를 연습하기 위해 지원했는데, 이 과정이 리프레시되면서 큰 도움이 되고 있다.

발표와 카메라 앞에 서는 목표를 위해 여기서도 열심히 활동하고 있다.


남은 2024년의 목표

정말 짧게 쓴다는 게 또 길어졌다. 이걸 또 영어로 옮기려면 시간이 들겠지?! 그래도 남은 2024년의 목표를 작게나마 정리한다.

  • 충분히 일을 하고 있지만 올해도 큼지막한 하나의 성과를 내고 싶고 발표도 하면 좋겠다.
  • 업무 관련된 내용들만 썼지만 다 필요 없고 건강이 최고다. 건강 없으면 아무것도 없다 진짜. 건강이 제일 우선이다.
  • 지금 하는 대로 열심히 성실하게 살자.
  • 이제부터는 시간이 금인데 항상 매사에 최선을 다해서 집중하자.
  • 인생에는 우선순위가 있다. 그 우선순위와 가치에 따라 행동하자. 가족이 중요하다!

글을 쓰면서 나 자신을 돌아보는데 그래도 괜찮은 6개월을 보냈고 건강을 꼭 잘 챙기면서 남은 2024년을 보내면 좋겠다.

부족한 만큼 앞으로도 언제나 겸손하고 성실하게 최선을 다하면서 살자!