혼새미로의 블로그

드림코어 (Dreamcore) - Playroom 스테이지 게임 플레이 스크린샷

혼새미로 — Sun, 8 Jun 2025 19:11:52 +0900

처음 시작 지점

첫 갈림길에서 좌측으로 들어왔더니, 점박이 인테리어와 높은 계단이 보여서 올라가보았다.

창문 너머로 거대한 성이 보였다. 내 기억으로는 노란색 방이었던 걸로 기억한다.

자세히 보니 규모가 꽤 커보였는데, 안에 들어가보면 훨씬 클 것 같은 느낌이 든다.

돌아다니다 빨간색 문을 발견했다. 이번 스테이지는 빨강, 파랑, 초록, 노랑 방에 들어가서 각각의 발전기를 모두 작동시켜야 탈출할 수 있다. 처음 발견한 방은 빨강 방이었다.

플레이룸 사이의 차분한 통로를 지나간다.

바닥에 도심을 묘사한 장판들이 있다.

중간에 기차 길도 구축되어 있다. 그런데 텍스처가 약간 최적화가 안된건지 흐릿하게 보인다. 오늘 출시된 스테이지라 아직 버그들이 조금 존재하는 것 같다.

멈춰있는 기차 장난감이 있다.

또 다른 방은 구름 벽지로 된 놀이방이 있다. 내 기억으로는 파란색 방이었던 걸로 기억한다.

처음 시작하는 공간을 파스텔 룸이라고 하는데, 파스텔 룸도 위치 별로 테마가 조금씩 달라서 그나마 길 찾는데 도움이 된다. (아주 조금..)

드라마 <오징어 게임>을 연상시키는 방이다.

드디어 모든 발전기를 작동시켜서 탈출구가 열렸다.

끝에 엘리베이터가 보이는데, 그 사이의 통로가 엄청 웅장하다.

엘리베이터 앞에서 바라본 벽 낙서와 문...

풀장, 교외 그리고 플레이룸까지 하면서 점점 이 게임에 빠져들고 있다. 올해 겨울에 새로운 스테이지가 출시된다고 하는데, 매우 기대된다.

앨런 웨이크 2 웰니스 센터 컴퓨터 비밀번호 퀴즈 및 해설

혼새미로 — Tue, 6 May 2025 13:41:04 +0900

Drawn by Imagen3

달력

문제: 위 달력이 주어졌을 때, 6자리 숫자 암호를 맞춰보자

힌트:

새로운 달이 뜬 다음날
암호를 만든 사람은 유럽인

1단계 ― 퍼즐에서 얻은 정보 정리

단서 의미

① 빨간 동그라미	암호 후보가 되는 날짜들을 표시한다.
② 힌트 문구	“새로운 달이 뜬 다음날” → ‘신월(New Moon)의 다음날’을 찾아야 함.
③ 전설(legend)	● = New Moon(신월) 이라고 달력 하단에 명시.
④ 암호 길이	6자리 숫자.
⑤ 생성자 국적	유럽인 → 날짜를 숫자로 쓸 때 DD MM YY 순서가 일반적.

2단계 ― 신월(New Moon) 찾기

달력에서 ● 기호가 있는 날짜만 추려낸다.

3단계 ― ‘신월 + 다음날’ 계산

각 신월 날짜에 +1일을 더한다(힌트 “…다음날”).

4단계 ― 빨간 동그라미와 대조

달력에 실제로 빨간 원이 그려진 날짜를 모두 적어 본다.

5 월 : 4, 17
6 월 : 29
7 월 : 17, 20
8 월 : 17, 31

이 목록과 ‘신월 다음날’ 목록을 비교하면 유일하게 겹치는 날짜가 17 Aug 2023이다.

5단계 ― 유럽식 6자리 숫자로 변환

유럽식 간단한 숫자 표기 규칙 → DD MM YY

17 Aug 2023 ⟶ 17 08 23

6단계 ― 최종 암호

170823

한눈에 보기 — 전체 흐름 요약

● 기호로 신월 날짜 파악
“다음날” 조건 적용 → 5/20, 6/18, 7/18, 8/17
빨간 동그라미와 겹치는 것은 8/17 하나뿐
유럽식 DD MM YY → 170823

따라서 퍼즐의 6자리 숫자 암호는 170823입니다.

Written by ChatGPT (o3)

AWS의 OpenTelemetry 지원

혼새미로 — Sat, 13 May 2023 14:28:20 +0900

"Kermit the frog" - DALL-E 2

AWS Distros

AWS 배포판은 고객이 AWS에서 오픈 소스 소프트웨어를 더 쉽게 사용할 수 있도록 만들어졌습니다. AWS 배포판은 AWS에 최적화된 오픈 소스 소프트웨어의 사전 패키징 및 구성된 버전입니다. 즉, 고객은 기본 인프라에 대해 걱정할 필요 없이 AWS에서 오픈 소스 소프트웨어를 배포하고 관리할 수 있습니다.

AWS Distros에는 운영 체제, 데이터베이스, 웹 서버 및 애플리케이션 프레임워크를 비롯한 다양한 소프트웨어가 포함되어 있습니다. 개발, 테스트, 프로덕션 및 에지 컴퓨팅을 비롯한 다양한 사용 사례에 사용할 수 있습니다.

AWS 배포판은 다음과 같은 다양한 이점을 제공합니다.

사용 용이성: AWS 배포판은 사전 패키징 및 구성되어 있으므로 고객은 기본 인프라에 대해 걱정할 필요 없이 AWS에서 오픈 소스 소프트웨어를 배포하고 관리할 수 있습니다.
성능: AWS 배포판은 AWS에 최적화되어 있으므로 고객은 오픈 소스 소프트웨어에서 최고의 성능을 얻을 수 있습니다.
보안: AWS 배포판은 안전하고 정기적으로 업데이트되므로 고객은 오픈 소스 소프트웨어가 보호되고 있음을 확신할 수 있습니다.
지원: AWS 배포판은 AWS에서 지원하므로 고객이 필요할 때 도움을 받을 수 있습니다.

AWS 배포판은 고객이 AWS에서 오픈 소스 소프트웨어를 사용할 수 있는 좋은 방법입니다. 사용 용이성, 성능, 보안 및 지원을 비롯한 다양한 이점을 제공합니다.

ADOT (AWS Distro for OpenTelemetry)

ADOT는 AWS에서 지원하는 안전한 OpenTelemetry 프로젝트 배포판입니다. OpenTelemetry는 애플리케이션 및 서비스에서 텔레메트리 데이터(메트릭, 트레이스 및 로그)를 수집하고 내보내기 위한 통합 API, 라이브러리 및 도구를 제공하는 오픈 소스 프로젝트입니다.

ADOT에는 다음과 같은 기능이 포함되어 있습니다.

AWS 및 기타 플랫폼에서 실행되는 애플리케이션 및 서비스에서 텔레메트리 데이터를 수집할 수 있는 콜렉터
텔레메트리 데이터를 AWS 및 기타 모니터링 시스템으로 보낼 수 있는 익스포터 세트
코드를 변경하지 않고 텔레메트리 데이터를 수집할 수 있는 자동 계측 에이전트 세트
애플리케이션에서 텔레메트리 데이터를 수집하는 데 사용할 수 있는 SDK 세트

다음은 ADOT 사용의 이점 중 일부입니다.

OpenTelemetry의 안전한 프로덕션 준비 배포입니다.
여기에는 텔레메트리 데이터를 수집하고 내보내는 다양한 기능이 포함되어 있습니다.
사용 및 구성이 쉽습니다.
AWS Support에서 지원합니다.

ADOT는 OpenTelemetry를 시작하는 좋은 방법입니다. 애플리케이션에서 텔레메트리 데이터를 쉽게 수집하고 다양한 모니터링 및 옵저버빌리티 서비스로 보낼 수 있습니다.

애플리케이션에서 텔레메트리 데이터를 수집하는 방법을 찾고 있다면 ADOT가 훌륭한 옵션입니다. 사용하기 쉽고 유연하며 확장 가능하고 안전합니다.

ADOT의 구성요소는 다음과 같습니다.

OpenTelemetry Collector: OpenTelemetry 콜렉터는 에이전트로부터 텔레메트리 데이터를 수신하여 적절한 대상으로 전달하는 ADOT의 핵심 구성 요소입니다.
OpenTelemetry Agent: OpenTelemetry 에이전트는 텔레메트리 데이터를 수집하기 위해 애플리케이션 서버에 설치되는 경량 에이전트입니다.
OpenTelemetry SDK: OpenTelemetry SDK는 텔레메트리 데이터를 수집하기 위해 애플리케이션을 계측하는 데 사용할 수 있는 라이브러리 세트입니다.
OpenTelemetry Exporters: OpenTelemetry 익스포터는 텔레메트리 데이터를 AWS X-Ray, 프로메테우스 및 그라파나와 같은 다른 대상으로 내보내는 데 사용할 수 있는 플러그인입니다.

다음은 AWS에서 ADOT를 사용할 수 있는 몇 가지 서비스입니다.

Amazon Elastic Container Service(ECS): ECS는 컨테이너화된 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있게 해주는 관리형 컨테이너 오케스트레이션 서비스입니다. ADOT를 사용하여 ECS 컨테이너에서 텔레메트리 데이터를 수집하고 Amazon CloudWatch 또는 Amazon X-Ray로 보낼 수 있습니다.
Amazon Elastic Kubernetes Service(EKS): EKS는 컨테이너화된 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있게 해주는 관리형 Kubernetes 서비스입니다. ADOT를 사용하여 EKS 파드드에서 텔레메트리 데이터를 수집하고 Amazon CloudWatch 또는 Amazon X-Ray로 보낼 수 있습니다.
Amazon Elastic Beanstalk: Amazon Elastic Beanstalk는 웹 애플리케이션 및 API를 쉽게 배포하고 확장할 수 있는 완전관리형 솔루션입니다. ADOT를 사용하여 Elastic Beanstalk 애플리케이션에서 텔레메트리 데이터를 수집하고 Amazon CloudWatch 또는 Amazon X-Ray로 보낼 수 있습니다.
Amazon Lambda: Amazon Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다. ADOT를 사용하여 Lambda 함수에서 텔레메트리 데이터를 수집하고 Amazon CloudWatch 또는 Amazon X-Ray로 보낼 수 있습니다.

OpenTelemetry 연관 AWS 서비스

다음은 OpenTelemetry와 직간접적으로 관련된 일부 AWS 서비스입니다.

Amazon CloudWatch: Amazon CloudWatch는 AWS 리소스 및 애플리케이션에 대한 통합 뷰를 제공하는 모니터링 서비스입니다. CloudWatch를 사용하여 애플리케이션 및 서비스에서 메트릭, 로그 및 트레이스를 수집할 수 있습니다.
Amazon X-Ray: Amazon X-Ray는 애플리케이션의 성능을 이해하는 데 도움이 되는 분산 추적 서비스입니다. X-Ray는 애플리케이션 및 서비스에서 트레이스를 수집할 수 있으며 성능 병목 현상 및 오류를 식별하는 데 도움이 될 수 있습니다.
AMP (Amazon Managed Service for Prometheus): AMP는 메트릭을 쉽게 수집, 저장 및 분석할 수 있는 완전관리형 서비스입니다. AMP는 클라우드 및 온프레미스 환경에서 널리 사용되는 오픈 소스 모니터링 시스템인 Prometheus를 기반으로 구축되었습니다. AMP는 Prometheus를 사용하고 싶지만 자체 Prometheus 인프라를 관리하고 유지하는 데 시간과 리소스를 투자하고 싶지 않은 조직에 적합한 선택입니다.
AMG (Amazon Managed Service for Grafana): AMG는 메트릭, 로그 및 데이터를 쿼리, 시각화 및 경고할 수 있는 인기있는 오픈 소스 분석 플랫폼은 Grafana를 쉽게 배포, 운영 및 확장할 수 있는 완전 관리형 서비스입니다. AMG는 Grafana를 사용하고 싶지만 자체 Grafana 인프라를 관리하고 유지하는 데 시간과 리소스를 투자하고 싶지 않은 조직에 적합한 선택입니다.

OpenTelemetry는 이러한 서비스에서 메트릭, 트레이스 및 로그 등의 텔레메트리 데이터를 수집하는 데 사용할 수 있습니다. 이 데이터는 애플리케이션 및 인프라의 성능과 상태를 모니터링하는 데 사용할 수 있습니다.

OpenTelemetry with EKS

ADOT는 Amazon EKS 클러스터에서 사용할 수 있습니다. ADOT를 사용하려면 EKS 클러스터에 ADOT 오퍼레이터를 설치해야 합니다. ADOT 오퍼레이터는 ADOT 콜렉터를 생성하고 관리합니다.

다음 다이어그램에서는 텔레메트리 데이터를 서로 다른 대상으로 내보내는 두 개의 파이프라인으로 구성된 ADOT 콜렉터를 보여줍니다. 트레이스 파이프라인은 AWS X-Ray 리시버 및 AWS X-Ray 익스포터의 인스턴스로 구성되며 AWS X-Ray로 트레이스를 전송합니다. 메트릭 파이프라인은 프로메테우스 리시버, 프로세서 및 메트릭 데이터를 AMP의 워크스페이스로 전송하는 AWS Prometheus Remote Write Exporter로 구성됩니다.

ADOT, AMP 및 AMG를 통한 모니터링

아래와 같이 ADOT 콜렉터를 사용하여 마이크로서비스를 모니터링하고, 메트릭을 AMP로 내보내고, AMG를 사용하여 시각화할 수 있습니다.

<ADOT, AMP, AMG를 통한 모니터링 | AWS Immersion Workshop>

다음은 작업을 위한 세부 단계를 설명합니다.

ADOT 콜렉터를 설정합니다. ADOT 콜렉터는 마이크로서비스에서 메트릭을 수집하는 작고 가벼운 에이전트입니다. 마이크로서비스 또는 별도의 시스템에 ADOT 콜렉터를 설치할 수 있습니다.
측정항목을 AMP로 내보내도록 ADOT 콜렉터를 구성합니다. ADOT 콜렉터는 다양한 형식으로 메트릭을 AMP로 내보낼 수 있습니다. 가장 일반적인 형식은 Prometheus입니다.
AMP 워크스페이스를 만듭니다. AMP 워크스페이스는 메트릭 모음입니다. AMP 콘솔에서 AMP 워크스페이스를 만들 수 있습니다.
측정항목을 AMP로 가져옵니다. AMP 워크스페이스를 만든 후에는 여기로 메트릭을 가져올 수 있습니다. ADOT 콜렉터 또는 다른 소스에서 메트릭을 가져올 수 있습니다.
AMG에서 메트릭을 시각화합니다. AMG는 메트릭을 쉽게 시각화할 수 있는 완전 관리형 서비스입니다. AMG를 사용하여 메트릭을 표시하는 대시보드 및 차트를 만들 수 있습니다.

ADOT Operator

ADOT 오퍼레이터는 ADOT 콜렉터를 관리하는 Kubernetes Operator입니다. ADOT 오퍼레이터는 ADOT 콜렉터의 배포, 업데이트 및 확장을 담당합니다. 또한 ADOT 콜렉터를 구성하기 위한 선언적 API를 제공합니다.

ADOT 오퍼레이터는 ADOT의 중요한 구성 요소입니다. 쿠버네티스 클러스터에서 ADOT 콜렉터를 쉽게 배포하고 관리할 수 있습니다. ADOT 오퍼레이터는 애플리케이션 및 서비스에서 텔레메트리 데이터를 쉽게 수집하고 내보낼 수 있는 여러 기능을 제공합니다.

다음은 ADOT 오퍼레이터의 일부 기능입니다.

자동 배포 및 업데이트: ADOT 오퍼레이터는 쿠버네티스 클러스터에서 ADOT 콜렉터를 자동으로 배포하고 업데이트할 수 있습니다. 이를 통해 최신 기능 및 버그 수정으로 ADOT 콜렉터를 최신 상태로 쉽게 유지할 수 있습니다.
선언적 구성: ADOT 오퍼레이터는 ADOT 콜렉터 구성을 위한 선언적 API를 제공합니다. 이렇게 하면 쿠버네티스 매니페스트를 작성하지 않고도 ADOT 콜렉터를 쉽게 구성할 수 있습니다.
여러 콜렉터 지원: ADOT 오퍼레이터는 여러 콜렉터를 지원할 수 있습니다. 이를 통해 다양한 소스에서 텔레메트리 데이터를 쉽게 수집할 수 있습니다.
AWS 서비스와의 통합: ADOT 오퍼레이터는 Amazon CloudWatch, Amazon OpenSearch Service 및 Amazon Managed Service for Prometheus를 비롯한 다양한 AWS 서비스와 통합할 수 있습니다. 이를 통해 텔레메트리 데이터를 쉽게 저장하고 분석할 수 있습니다.

ADOT 오퍼레이터는 쿠버네티스 클러스터에서 ADOT를 쉽게 배포하고 관리할 수 있게 해주는 강력한 도구입니다.

ADOT 콜렉터가 설치되면 ADOT SDK를 사용하여 애플리케이션에서 텔레메트리 데이터를 수집할 수 있습니다. ADOT SDK는 메트릭, 트레이스 및 로그를 포함하여 텔레메트리 데이터를 수집하기 위한 다양한 API를 제공합니다.

ADOT 오퍼레이터가 설치되고 실행 중인 경우 ADOT 콜렉터를 Amazon EKS 클러스터에 배포할 수 있습니다. Amazon EKS에서 ADOT 콜렉터는 네 가지 모드인 Deployment, DaemonSet, StatefulSet 및 Sidecar 중 하나로 배포될 수 있으며, 개별 서비스에서 배포하여 사용할 수 있습니다.

ADOT (AWS Distro for OpenTelemetry) Collector

ADOT 콜렉터는 애플리케이션 및 서비스에서 텔레메트리 데이터를 수집하고 내보내는 데 사용할 수 있는 ADOT의 구성 요소입니다. 프로메테우스, 예거 및 AWS X-Ray를 비롯한 다양한 소스에서 데이터를 수집하도록 구성할 수 있습니다. 또한 ADOT 콜렉터는 Amazon CloudWatch, Amazon OpenSearch Service 및 Amazon Managed Service for Prometheus를 비롯한 다양한 대상으로 데이터를 내보내도록 구성할 수 있습니다.

ADOT 콜렉터는 다음을 포함하여 광범위한 텔레메트리 데이터 소스를 지원합니다.

계측 에이전트
트레이스 API
로그 파일
Prometheus 메트릭
CloudWatch 메트릭

ADOT 콜렉터는 텔레메트리 데이터를 다음을 포함한 다양한 대상으로 내보낼 수 있습니다.

Amazon CloudWatch
Amazon OpenSearch
Amazon Managed Service for Prometheus
Splunk
DataDog
Grafana

ADOT 콜렉터는 다양한 소스 및 대상에서 텔레메트리 데이터를 수집하고 내보내는 데 사용할 수 있는 강력한 도구입니다. 애플리케이션 및 서비스의 성능, 안정성 및 보안을 개선하기 위해 텔레메트리 데이터를 수집하고 분석하려는 조직에 적합한 옵션입니다.

다음은 ADOT 콜렉터 사용의 이점 중 일부입니다.

확장성: ADOT 콜렉터는 확장성이 뛰어나며 온프레미스 또는 클라우드에 배포할 수 있습니다.
유연성: ADOT 콜렉터는 광범위한 원격 측정 데이터 소스 및 대상을 지원합니다.
사용 용이성: ADOT 콜렉터는 설치 및 구성이 쉽습니다.
비용 효율성: ADOT 콜렉터는 텔레메트리 데이터를 수집하고 내보내는 비용 효율적인 방법입니다.

OpenTelemetry with Lambda

ADOT Lambda Layer

ADOT 람다 레이어는 사전 빌드된 관리형 계층으로, OpenTelemetry를 사용하여 AWS 람다 함수를 쉽게 계측할 수 있도록 해줍니다. 이 레이어에는 사용자가 선택한 언어에 대한 OpenTelemetry 콜렉터와 OpenTelemetry SDK가 포함되어 있습니다.

ADOT 람다 레이어를 사용하려면 람다 함수의 환경 변수에 추가하기만 하면 됩니다. 레이어는 자동으로 기능을 계측하고 텔레메트리 데이터를 수집합니다. 그런 다음 프로메테우스, 예거, AWS X-Ray와 같은 다양한 대상으로 내보낼 수 있습니다.

ADOT 람다 레이어는 OpenTelemetry를 시작하는 좋은 방법입니다. 코드를 작성하지 않고도 손쉽게 람다 함수를 구성하고 텔레메트리 데이터를 수집할 수 있습니다.

References

Kubernetes의 OpenTelemetry 지원

혼새미로 — Sat, 13 May 2023 11:56:50 +0900

"Batman and Spierman" - DALL-E 2

Kubernetes

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈 소스 컨테이너 오케스트레이션 시스템입니다. 컨테이너화된 애플리케이션을 관리하기 위해 모든 규모의 회사에서 사용합니다.

쿠버네티스가 필요한 이유는 많습니다. 예를 들어 관리해야 하는 컨테이너가 많은 경우 쿠버네티스는 프로세스를 자동화하는 데 도움이 될 수 있습니다. 또한 쿠버네티스는 필요에 따라 애플리케이션을 확장하거나 축소하는 데 도움이 될 수 있으며 애플리케이션을 항상 사용할 수 있도록 보장할 수 있습니다.

다음은 쿠버네티스 사용의 이점 중 일부입니다.

자동화: 쿠버네티스는 배포, 확장 및 상태 모니터링과 같은 컨테이너 관리와 관련된 많은 수동 작업을 자동화할 수 있습니다. 이렇게 하면 시간과 노력을 절약할 수 있습니다.
확장성: 쿠버네티스는 필요에 따라 애플리케이션을 확장하거나 축소하는 데 도움이 됩니다. 이를 통해 인프라 비용을 절감할 수 있습니다.
가용성: 쿠버네티스는 애플리케이션을 항상 사용할 수 있도록 도와줍니다. 이를 통해 애플리케이션의 가동 시간을 개선할 수 있습니다.

쿠버네티는 컨테이너화된 애플리케이션을 보다 효과적으로 관리하는 데 도움이 되는 강력한 도구입니다. 컨테이너가 많거나 애플리케이션을 자주 확장 또는 축소해야 하는 경우 쿠버네티스를 고려하는 것이 좋습니다.

다음은 쿠버네티스가 필요할 수 있는 몇 가지 예입니다.

수백 또는 수천 개의 컨테이너가 포함된 대규모 애플리케이션을 실행하고 있습니다.
애플리케이션을 빠르고 쉽게 확장하거나 축소할 수 있어야 합니다.
애플리케이션이 항상 사용 가능한지 확인해야 합니다.
컨테이너 관리를 자동화하려고 합니다.

이러한 시나리오 중 하나라도 해당된다면 쿠버네티스를 고려하는 것이 좋습니다.

Control Loop

제어 루프는 클러스터의 상태를 감시하고 상태를 원하는 상태에 더 가깝게 만들기 위해 변경하는 프로세스입니다. 예를 들어 디플로이먼트 컨트롤러는 디플로이먼트의 파드 수를 감시하고 원하는 파드 수를 유지하기 위해 필요에 따라 파드를 생성하거나 삭제합니다.

제어 루프는 쿠버네티스 설계의 핵심 부분입니다. 이를 통해 쿠버네티스는 클러스터를 자동으로 관리하고 클러스터의 상태가 항상 원하는 상태와 일치하도록 합니다.

제어 루프는 네 단계로 구성됩니다.

관찰 (Observe): 컨트롤러는 쿠버네티스 API를 쿼리하여 관리 중인 리소스의 현재 상태를 관찰합니다.
분석 (Analyze): 컨트롤러는 관찰된 상태를 구성에 지정된 원하는 상태와 비교하고 취해야 할 조치를 결정합니다.
조치 (Act): 컨트롤러는 관찰된 상태를 원하는 상태와 일치시키기 위해 자원 생성 또는 삭제와 같은 필요한 조치를 수행합니다.
반복 (Repeat): 제어 루프가 무한정 계속 실행되어 필요에 따라 리소스를 지속적으로 모니터링하고 업데이트합니다.

다음은 쿠버네티스에서 제어 루프를 사용할 때 얻을 수 있는 몇 가지 이점입니다.

자동화: 제어 루프는 클러스터 관리를 자동화합니다. 이렇게 하면 시간과 노력을 절약할 수 있습니다.
확장성: 제어 루프는 대규모 클러스터를 관리하도록 확장할 수 있습니다.
신뢰성: 제어 루프는 신뢰할 수 있도록 설계되었습니다. 클러스터의 일부 구성 요소가 실패하더라도 계속 작동할 수 있습니다.

제어 루프는 쿠버네티스 클러스터를 보다 효과적으로 관리하는 데 도움이 되는 강력한 도구입니다. 쿠버네티스를 사용하는 경우 제어 루프와 작동 방식에 익숙해져야 합니다.

Kubernetes Controller

쿠버네티스의 컨트롤러는 클러스터의 상태를 감시하고 상태를 원하는 상태에 가깝게 변경하는 제어 루프의 특정 구현입니다. 컨트롤러는 쿠버네티스 컨트롤 플레인에서 실행되는 Golang 프로그램으로 구현됩니다.

ℹ️ 컨트롤 플레인은 노드, 파드, 서비스 및 레플리카셋 컨트롤러를 포함한 클러스터의 리소스 관리를 담당합니다. 컨트롤 플레인은 노드가 실패하거나 파드가 생성되는 경우와 같은 클러스터 이벤트도 처리합니다.

컨트롤러는 쿠버네티스 설계의 핵심 부분입니다. 이를 통해 쿠버네티스는 클러스터를 자동으로 관리하고 클러스터의 상태가 항상 원하는 상태와 일치하도록 합니다. 쿠버네티스를 사용하는 경우 컨트롤러 및 작동 방식에 익숙해져야 합니다.

다음은 컨트롤러의 몇 가지 예입니다.

Deployment 컨트롤러는 디플로이먼트의 파드 수를 감시하고 원하는 파드 수를 유지하기 위해 필요에 따라 파드를 생성하거나 삭제합니다.
ReplicaSet 컨트롤러는 디플로이먼트 컨트롤러와 비슷하지만 더 세분화되어 있습니다. 레플리카셋의 파드 수를 감시하고 원하는 파드 수를 유지하기 위해 필요에 따라 파드를 생성하거나 삭제합니다.
DaemonSet 컨트롤러는 지정된 수의 파드가 클러스터의 모든 노드에서 실행되도록 합니다.
Job 컨트롤러는 지정된 수의 파드가 완료될 때까지 실행되도록 합니다.
CronJob 컨트롤러는 지정된 수의 파드가 반복 일정에 따라 실행되도록 합니다.

이는 쿠버네티스에서 사용할 수 있는 많은 컨트롤러의 몇 가지 예일 뿐입니다. 특정 유형의 애플리케이션 또는 인프라를 관리해야 하는 경우 도움이 될 수 있는 컨트롤러가 있을 수 있습니다.

Kubernetes Operator

쿠버네티스 오퍼레이터는 사용자 정의 리소스를 관리하도록 설계된 컨트롤러 유형입니다. 컨트롤러는 쿠버네티스의 모든 리소스를 관리할 수 있지만 오퍼레이터는 특정 애플리케이션 또는 서비스와 관련된 작업을 자동화하도록 특별히 설계되었습니다.

오퍼레이터는 일반적으로 Go로 작성되며 다른 애플리케이션과 동일한 방식으로 쿠버네티스 클러스터에 배포할 수 있습니다. 오퍼레이터가 배포되면 쿠버네티스 리소스를 생성, 업데이트 및 삭제하고 애플리케이션의 상태를 모니터링 및 관리하는 데 사용할 수 있습니다.

오퍼레이터를 사용하여 복잡한 쿠버네티스 애플리케이션의 관리를 단순화할 수 있습니다. 또한 업데이트 롤아웃 또는 백업 수행과 같이 반복적이거나 시간이 많이 걸리는 작업을 자동화하는 데 사용할 수 있습니다.

다음은 쿠버네티스 오퍼레이터를 사용할 때 얻을 수 있는 몇 가지 이점입니다.

복잡성 감소: 오퍼레이터는 작업을 자동화하고 일관된 애플리케이션 관리 방법을 제공하여 쿠버네티스 애플리케이션 관리의 복잡성을 줄이는 데 도움을 줄 수 있습니다.
향상된 안정성: 오퍼레이터는 업데이트 롤아웃 및 백업 수행과 같은 작업을 자동화하여 쿠버네티스 애플리케이션의 안정성을 개선하는 데 도움을 줄 수 있습니다.
민첩성 향상: 오퍼레이터는 애플리케이션을 더 쉽게 배포, 업데이트 및 관리할 수 있도록 하여 쿠버네티스 애플리케이션의 민첩성을 높이는 데 도움을 줄 수 있습니다.

복잡한 애플리케이션으로 쿠버네티스 클러스터를 관리하는 경우 오퍼레이터를 사용하는 것이 관리 프로세스를 단순화하고 애플리케이션의 안정성과 민첩성을 향상시키는 좋은 방법이 될 수 있습니다.

쿠버네티스 오퍼레이터를 만들려면 다음을 수행해야 합니다.

애플리케이션 또는 애플리케이션 세트에 대한 사용자 지정 리소스를 정의합니다.
사용자 지정 리소스의 변경 사항을 감지하고 그에 따라 조치를 취하는 컨트롤러를 작성합니다.
쿠버네티스 클러스터에 오퍼레이터를 배포합니다.

오퍼레이터가 배포되면 사용자 지정 리소스 정의에 따라 애플리케이션 또는 애플리케이션 세트를 자동으로 관리합니다.

Kubernetes Operator의 예시

다음은 쿠버네티스 오퍼레이터의 몇 가지 예시입니다.

Istio Operator: Istio 오퍼레이터는 Istio 배포를 관리하는 쿠버네티스 네이티브 방식을 제공하는 오픈 소스 프로젝트입니다.
Grafana Operator: Grafana 오퍼레이터는 Grafana 배포를 관리하는 쿠버네티스 네이티브 방식을 제공하는 오픈 소스 프로젝트입니다.
Prometheus Operator: Prometheus 오퍼레이터는 Prometheus 배포를 관리하는 쿠버네티스 네이티브 방식을 제공하는 오픈 소스 프로젝트입니다.
Jenkins Operator: Jenkins 오퍼레이터는 Jenkins 배포를 관리하는 쿠버네티스 네이티브 방식을 제공하는 오픈 소스 프로젝트입니다.
Redis Operator: Redis 오퍼레이터는 Redis 배포를 관리하는 쿠버네티스 네이티브 방식을 제공하는 오픈 소스 프로젝트입니다.
MySQL Operator: MySQL 오퍼레이터는 MySQL 배포를 관리하는 쿠버네티스 네이티브 방식을 제공하는 오픈 소스 프로젝트입니다.
MongoDB Operator: MongoDB 오퍼레이터는 MongoDB 배포를 관리하는 쿠버네티스 네이티브 방식을 제공하는 오픈 소스 프로젝트입니다.
Kafka Operator: Kafka 오퍼레이터는 Kafka 배포를 관리하는 쿠버네티스 네이티브 방식을 제공하는 오픈 소스 프로젝트입니다.
Kubernetes Dashboard Operator: 쿠버네티스 Dashboard 오퍼레이터는 쿠버네티스 대시보드를 관리하는 쿠버네티스 네이티브 방식을 제공하는 오픈 소스 프로젝트입니다.

이것은 사용 가능한 많은 Kubernetes 오퍼레이터의 몇 가지 예일 뿐입니다. 사용할 수 있는 다른 많은 오퍼레이터가 있으며 새로운 오퍼레이터가 항상 만들어지고 있습니다.

OpenTelemetry Operator

OpenTelemetry 오퍼레이터는 OpenTelemetry 콜렉터 및 OpenTelemetry 계측 라이브러리를 사용하여 워크로드의 자동 계측을 관리하는 쿠버네티스 오퍼레이터입니다.

OpenTelemetry 콜렉터는 애플리케이션에서 텔레메트리 데이터를 수집하는 서비스입니다. OpenTelemetry 콜렉터는 온프레미스 또는 클라우드에 배포할 수 있습니다. 또한, OpenTelemetry 콜렉터는 애플리케이션의 프런트엔드와 백엔드 모두에서 텔레메트리 데이터를 수집할 수 있습니다.

OpenTelemetry 오퍼레이터를 사용하여 다음을 수행할 수 있습니다.

쿠버네티스 클러스터에 OpenTelemetry 콜렉터를 배포합니다.
애플리케이션에서 텔레메트리 데이터를 수집하도록 OpenTelemetry 콜렉터를 구성합니다.
OpenTelemetry 콜렉터에서 Prometheus, Grafana 및 AWS CloudWatch를 비롯한 다양한 대상으로 텔레메트리 데이터를 보냅니다.
OpenTelemetry 계측 라이브러리로 애플리케이션을 자동 계측합니다.

OpenTelemetry 오퍼레이터는 다음과 같은 다양한 이점을 제공합니다.

개발 시간 단축: OpenTelemetry 오퍼레이터를 사용하여 몇 분 안에 OpenTelemetry 콜렉터를 배포 및 구성할 수 있습니다. 이를 통해 개발자는 상당한 시간을 절약할 수 있습니다.
향상된 호환성: OpenTelemetry 오퍼레이터는 다양한 쿠버네티스 배포와 호환됩니다. 즉, 다양한 쿠버네티스 클러스터에서 OpenTelemetry 오퍼레이터를 사용할 수 있습니다.
향상된 가시성: OpenTelemetry 오퍼레이터를 사용하여 메트릭, 트레이 및 로그를 포함한 광범위한 텔레메트리 데이터를 수집할 수 있습니다. 이를 통해 애플리케이션의 성능과 동작을 보다 완벽하게 볼 수 있습니다.

전반적으로 OpenTelemetry 오퍼레이터는 OpenTelemetry 콜렉터를 관리하고 응용 프로그램에서 텔레메트리 데이터를 수집하는 데 유용한 도구입니다. 개발자 시간을 절약하고, 호환성을 개선하고, 가시성을 높이고, 문제 해결을 개선할 수 있습니다.

References

OpenTelemetry 개념 정리

혼새미로 — Mon, 1 May 2023 15:41:32 +0900

"New York City in the style of Kay Sage" - Midjourney

사전지식: Telemetry Data

텔레메트리 데이터는 Tele (원격) + Metry (측정) + Data의 합성어로, 원격 소스에서 자동 또는 수동으로 수집 및 전송되는 데이터를 의미합니다. 이 데이터는 시스템의 상태, 성능 및 동작을 모니터링하는 데 사용됩니다.

Telemetry Data 유형

텔레메트리 데이터의 유형을 "시그널 (Signal)"이라고 하는 데, 시그널은 크게 로그, 메트릭 그리고 트레이스가 존재합니다.

텔레메트리 데이터의 세 개의 기둥

Log: 로그는 인프라 및 애플리케이션에서 발생한 이벤트를 기록한 데이터를 의미합니다. 로그의 예로는 애플리케이션 예외 발생, 인프라에서 장애 발생 등을 기록할 수 있습니다.
Metric: 메트릭은 시간에 따른 특정 지표의 수치를 기록한 데이터를 의미합니다. 메트릭의 예로는 CPU 사용률, 요청 처리 속도, 메모리 사용량 등이 있습니다.
Trace: 트레이스는 분산 시스템에서의 요청 처리 과정에서 각각의 단계를 추적하는 데이터를 의미합니다. 예를 들어, 사용자의 요청이 웹서버에서 처리되고, 이후 데이터베이스에 쿼리를 보내는 과정에서 각각의 단계를 추적할 수 있습니다.

Telemetry Data가 없었다면?

많은 기업들이 AWS와 같은 CSP (Cloud Service Provider)에 마이크로서비스 아키텍처를 기반으로 다양한 서비스를 구축하여 사용하고 있습니다. 트위터는 현재 약 1000개의 서비스가 함께 동작하여 의미있는 결과를 발표하고 있습니다. 이때 텔레메트리 데이터가 없다면 문제를 해결하고 성능의 병목현상을 식별하기 어려울 수 있습니다.

다음은 애플리케이션에서 텔레메트리 데이터를 수집하지 않을 경우 발생할 수 있는 몇 가지 문제점입니다.

다운타임 시간 증가: 텔레메트리 데이터가 없으면 애플리케이션에서 발생한 문제를 식별하고 해결하기 어려워 다운타임 시간이 늘어날 수 있습니다.
성능 저하: 텔레메트리 데이터가 없으면 애플리케이션을 최적화하기 어려워 성능이 저하될 수 있습니다.
보안 위험 증가: 텔레메트리 데이터가 없으면 보안 위험을 식별하고 대응하기가 어려워 보안 위험이 증가할 수 있습니다.
- 예시 1) 악의적인 활동 식별: 텔레메트리 데이터를 사용하여 취약성을 악용하려는 사용자를 식별하고 이를 통해 해당 사용자가 시스템에 액세스하지 못하도록 차단할 수 있습니다.
- 예시 2) 취약성 패치: 텔레메트리 데이터를 사용하여 공격에 취약한 코드 영역을 식별하고 이를 사용하여 취약성을 패치하고 향후 공격을 방지할 수 있습니다.
- 예시 3) 보안 상태 모니터링: 회사가 네트워크에서 텔레메트리 데이터를 수집하는 경우 해당 데이터를 사용하여 보안 위반을 나타낼 수 있는 네트워크 트래픽의 변경 사항을 식별할 수 있습니다. 그런 다음 이 정보를 사용하여 침해를 조사하고 피해를 완화하기 위한 조치를 취할 수 있습니다.
비용 증가: 텔레메트리 데이터가 없으면 애플리케이션을 비용에 맞게 최적화하기 어려워 비용 증가로 이어질 수 있습니다.

이러한 위험을 완화하기 위해 CSP는 마이크로서비스 애플리케이션에서 텔레메트리 데이터를 수집해야 합니다. 이 데이터는 문제를 해결하고, 성능 병목 현상을 식별하고, 성능, 보안 및 비용 측면에서 애플리케이션을 최적화하는 데 사용할 수 있습니다.

Telemetry Framework

텔레메트리 프레임워크는 소프트웨어 시스템에서 텔레메트리 데이터를 수집하고 분석하는 소프트웨어 플랫폼을 의미합니다.

텔레메트리 프레임워크에는 일반적으로 다음과 같은 기능이 제공됩니다.

데이터 수집: 텔레메트리 프레임워크는 소프트웨어 시스템에서 텔레메트리 데이터를 수집합니다. 이 데이터는 애플리케이션 로그, 시스템 로그 및 성능 카운터와 같은 다양한 소스에서 수집할 수 있습니다.
데이터 스토리지: 텔레메트리 프레임워크는 텔레메트리 데이터를 중앙 리포지토리에 저장합니다. 이 데이터는 CSV, JSON 및 프로메테우스와 같은 다양한 형식으로 저장할 수 있습니다.
데이터 분석: 텔레메트리 프레임워크는 텔레메트리 데이터를 분석하여 문제와 추세를 식별합니다.이 분석은 문제를 해결하고 성능을 개선하며 소프트웨어 시스템에 대한 더 나은 결정을 내리는 데 사용할 수 있습니다.

대표적인 텔레메트리 프레임워크로는 다음과 같습니다.

Prometheus: 프로메테우스는 애플리케이션 및 서비스에서 메트릭을 수집하는 오픈소스 모니터링 시스템입니다. 확장성과 유연성으로 유명합니다.
Grafana: 그라파나는 프로메테우스 및 기타 소스의 텔레메트리 데이터를 표시하는 데 사용할 수 있는 오픈소스 시각화 도구입니다.
ELK Stack: ELK 스택은 로그 수집, 저장 및 분석을 위한 인기있는 오픈소스 도구 모음입니다. Elasticsearch, Logstash, Kibana로 구성되어 있습니다.
Splunk: 스플렁크는 다양한 소스에서 텔레메트리 데이터를 수집하고 분석하는 상용 모니터링 및 분석 플랫폼입니다.
Dynatrace: 다이나트레이스는 클라우드 네이티브 애플리케이션용으로 설계된 상용 모니터링 및 분석 플랫폼입니다.
AppDynamics: 앱다이나믹스는 앤터프라이즈 애플리케이션용으로 설계된 상용 모니터링 및 분석 플랫폼입니다.

CCC (Cross-Cutting Concern)

일반적으로 횡단 관심사 (Cross-Cutting Conern)는 애플리케이션 내 여러 레이어 또는 여러 서비스 간의 공통 관심사를 의미합니다. 예를 들어, 로그, 메트릭, 트레이스와 같은 텔레메트리 데이터는 여러 서비스에서 공통적으로 필요한 기능이므로 이러한 기능을 횡단 관심사로 분류할 수 있습니다.

횡단 관심사 도식화

OpenTelemetry는 횡단 관심사를 처리하기 위한 프레임워크입니다. 다시 말해서, OpenTelemetry는 텔레메트리 데이터를 수집하고 저장하기 위한 도구가 될 수 있습니다.

마이크로서비스 구조가 보편화되고 상호의존적이고 연관 작업을 수행하는 서비스의 수가 많아짐에 따라 이러한 횡단 관심사인 텔레메트리 데이터를 AWS와 같은 특정 공급업체 또는 프로메테우스와 같은 특정 플랫폼에 종속적이지 않고, 여러 서비스들을 통틀어 중앙 집중식으로 수집하여 다양한 모니터링 및 분석 플랫폼으로 전파하기 위한 시스템의 필요성이 높아지게 되었습니다.

사전지식: Visibility와 Observability

두 용어는 상호교차 사용이 가능하지만 실제로는 다른 의미를 갖습니다. 비지빌리티는 시스템에서 어떤 일이 발생했는지 보는 능력을 의미하고, 옵저버빌리티는 왜 그 일이 발생했는지 이해하는 능력을 의미합니다. 다시 말하면, 비지빌리티는 데이터를 보는 능력, 옵저버빌리티는 데이터를 이해하는 능력을 의미합니다.

Visibility Monitoring과 Observability의 관계 도식화

예를 들어, 시스템에는 많은 비지빌리티는 가질 수 있지만 만약 데이터 라벨링이 올바르게 구성되어 있지 않을 경우 데이터가 의미하는 바를 이해하기 어렵습니다. 이때 옵저버빌리티라는 개념이 등장합니다. 옵저버빌리티는 컨텍스트와 다른 데이터 포인트 사이의 관계를 제공하여 데이터에 대한 이해도를 높이도록 돕습니다.

클라우드 컴퓨팅 환경이 고도로 복잡해짐에 따라 옵저버빌리티가 중요해지고 있습니다. 컨텍스트와 데이터 포인트 사이의 관계를 제공함으로써 옵저버빌리티는 문제를 더 빠르고 효율적으로 트러블슈팅하도록 지원합니다. OpenTelemetry는 텔레메트리 데이터를 수집, 내보내기 및 분석할 수 있도록 지원하는 옵저버빌리티 프레임워크입니다.

(참고로, 옵저버빌리티와 유사한 의미인 모니터링 (Monitoring)은 잠재적인 문제를 해결하기 위해 시스템에 대한 데이터를 수집하고 분석하는 프로세스를 의미합니다.)

Observability Frontend와 Backend

옵저버빌리티에 대해 조금 더 깊게 들어가면 OF (Observability Frontend)와 OB (Observability Backend)로 구분할 수 있습니다.

OF는 애플리케이션의 사용자 인터페이스 및 사용자 경험과 관련된 데이터의 수집 및 분석을 의미합니다. 여기에는 페이지 로드 시간, 네트워크 요청, 오류율 등이 포함됩니다. 개발자는 이 데이터를 분석하여 사용자가 애플리케이션과 상호작용하는 방식에 대한 통찰력을 얻고 개선할 수 있는 영역을 식별할 수 있습니다.

OB는 애플리케이션의 내부 작업과 관련된 데이터 수집 및 분석을 나타냅니다. 서버의 관점에서 애플리케이션의 성능과 동작을 모니터링하고 문제를 해결할 수 있는 기능입니다. 여기에는 CPU 사용량, 메모리 사용량, 데이터베이스 쿼리 등이 포함됩니다. 개발자는 이 데이터를 분석하여 시스템의 성능과 안정성에 대한 통찰력을 얻고 병목현상을 식별하고, 시스템의 전체 성능을 최적화하기 위해 개선할 수 있습니다.

프런트엔드와 백엔드에서 옵저버빌리티를 개선하는 데 사용할 수 있는 다양한 도구가 있습니다. 가장 많이 사용되는 도구는 다음과 같습니다.

OF 도구
- Google Analytics
- New Relic Browser
- Sentry
- Datadog
- Lightstep
OB 도구
- Prometheus
- Grafana
- Jaeger
- Elasticsearch
- Splunk
- Datadog
- Dynatrace
- AWS X-Ray

이러한 도구를 사용하면 애플리케이션의 성능과 동작을 더 잘 이해할 수 있으므로 문제를 더 빨리 식별하고 해결할 수 있습니다.

OpenTelemetry는 왜 만들어졌을까?

Otel이라고도 불리는 OpenTelemetry가 개발되기 전에도 이미 많은 텔레메트리 프레임워크가 존재했습니다. 그러나, 기존 텔레메트리 프레임워크에 여러 가지 문제가 있었습니다.

기존 텔레메트리 데이터 수집 프로세스 도식화

대표적으로 다음과 같은 문제가 있었습니다.

조각화: 각각의 고유한 API와 형식을 가진 여러 가지 텔레메트리 프레임워크가 존재했습니다. 이로 인해 다양한 시스템에서 텔레메트리 데이터를 수집하고 사용하기가 어려웠습니다.
공급업체 종속성: 많은 텔레메트리 프레임워크가 특정 공급업체나 플랫폼에 종속되어 있었습니다. 이로 인해 텔레메트리 데이터를 다른 공급업체나 플랫폼으로 옮기는 것이 어려웠습니다.
복잡성: 기존의 텔레메트리 프레임워크는 복잡하고 사용하기 어려운 경우가 많았습니다. 이로 인해 개발자가 애플리케이션에 옵저버빌리티를 추가하기가 어려웠습니다.

이러한 문제를 해결하기 위해 OpenTelemetry가 만들어졌습니다. OpenTelemetry는 클라우드 네이티브 세계에서 텔레메트리의 표준으로 빠르게 자리잡고 있습니다.

OpenTracing과 OpenCensus 합병

OpenTracing 및 OpenCensus는 애플리케이션에서 텔레메트리 데이터를 수집하는 방법을 제공하는 두 가지 오픈 소스 프로젝트입니다. 애플리케이션을 모니터링 및 디버깅하고 수행 방법을 이해하는 데 사용할 수 있습니다.

OpenTracing은 개발자가 애플리케이션 코드를 수정하지 않고도 애플리케이션에 트레이스를 추가할 수 있는 분산 추적 표준입니다. OpenCensus는 개발자가 애플리케이션 코드를 수정하지 않고도 애플리케이션에서 메트릭을 수집할 수 있는 메트릭 수집 및 모니터링 프레임워크입니다.

2019년에 OpenTracing과 OpenCensus가 합쳐지면서 OpenTelemetry가 되었습니다. OpenTelemetry는 애플리케이션에서 텔레메트리 데이터를 수집하는 방법을 제공하는 통합 프로젝트입니다. 벤더 중립적이고 이식 가능하며 확장 가능하도록 설계되었습니다.

OpenTracing과 OpenCensus가 OpenTelemetry로 병합된 데는 몇 가지 이유가 있습니다.

텔레메트리 데이터 수집을 위한 단일 통합 표준을 만듭니다. OpenTracing과 OpenCensus는 둘 다 텔레메트리 데이터 수집을 위한 경쟁 표준이었습니다. 합병을 통해 그들은 모두가 사용할 수 있는 단일 표준을 만들 수 있었습니다.
텔레메트리 데이터 수집 커뮤니티에서 조각화를 방지합니다. 두 가지 경쟁 표준으로 인해 텔레메트리 데이터 수집 커뮤니티가 조각화될 위험이 있었습니다. 병합을 통해 OpenTracing과 OpenCensus는 함께 작동하여 텔레메트리 데이터 수집 상태를 개선할 수 있는 단일 커뮤니티를 만들 수 있었습니다.
조직이 텔레메트리 데이터 수집을 더 쉽게 채택할 수 있도록 합니다. 두 개의 경쟁 표준으로 인해 조직에서 어떤 표준을 채택해야 하는지 알기가 어려웠습니다. OpenTracing과 OpenCensus를 병합함으로써 조직은 단일 통합 표준을 제공하여 텔레메트리 데이터 수집을 더 쉽게 채택할 수 있었습니다.

OpenTracing과 OpenCensus의 합병은 오픈 소스 텔레메트리 커뮤니티를 위한 주요 단계였습니다. 애플리케이션에서 텔레메트리 데이터를 수집하기 위한 포괄적인 기능 세트를 제공하는 단일 프로젝트를 만들었습니다. OpenTelemetry는 이제 클라우드 네이티브 세계에서 텔레메트리 데이터 수집을 위한 사실상의 표준입니다.

OpenTelemetry 특징

OpenTelemetry는 소프트웨어 시스템에서 텔레메트리 데이터를 수집, 내보내기 및 분석하는 통합적인 방법을 제공하는 오픈소스 옵저버빌리티 프레임워크입니다.

OpenTelemetry는 다양한 텔레메트리 도구 및 플랫폼과 함께 사용할 수 있도록 공급업체 중립적이고 이식 가능하도록 설계되었습니다. 또한 사용하기 쉽도록 설계되어 개발자가 빠르고 쉽게 애플리케이션에 옵저버빌리티 기능을 추가할 수 있습니다.

OpenTelemetry 도입 후 텔레메트리 데이터 수집 프로세스 도식화

OpenTelemetry의 주요 특징은 다음과 같습니다.

통합 API: OpenTelemetry는 텔레메트리 데이터를 수집하고 내보내는 통합 API를 제공하므로 사용 및 관리가 더 쉬워집니다.
공급업체 중립: OpenTelemetry는 특정 공급업체 또는 플랫폼에 종속되지 않으므로 다양한 도구 및 시스템과 함께 사용할 수 있습니다.
이식성: OpenTelemetry 데이터는 표준 형식이므로 서로 다른 시스템 간에 쉽게 교환할 수 있습니다.
간편한 사용: OpenTelemetry는 사용하기 쉽도록 설계되어 개발자가 애플리케이션에 옵저버빌리티를 빠르고 쉽게 추가할 수 있습니다.
다양한 텔레메트리 데이터 유형 지원: OpenTelemetry는 메트릭, 로그 및 트레이스를 포함한 다양한 텔레메트리 데이터 유형을 지원합니다.
다양한 텔레메트리 데이터 내보내기 지원: OpenTelemetry는 다양한 텔레메트리 내보내기를 지원하므로 텔레메트리를 다양한 시스템으로 내보낼 수 있습니다.
다양한 프로그래밍 언어 지원: OpenTelemetry는 다양한 프로그래밍 언어를 지원하므로 다양한 애플리케이션에서 사용할 수 있습니다.

전반적으로 OpenTelemetry는 소프트웨어 시스템에서 텔레메트리 데이터를 수집하고 내보내기 위한 강력하고 유연한 도구입니다. 공급업체 중립적이고 이식성이 높고 사용하기 쉽도록 설계되어 애플리케이션에 옵저버빌리티를 추가해야 하는 개발자에게 훌륭한 선택지가 될 수 있습니다.

Instrumentation

소프트웨어 관점에서 계측 (Instrumentation)은 텔레메트리 데이터를 수집하기 위해 애플리케이션에 코드를 추가하는 프로세스를 의미합니다. 그런 다음 이 데이터를 사용하여 시스템 성능을 모니터링하고 잠재적인 문제를 식별하며 시스템의 설계 및 구현을 개선할 수 있습니다.

계측기

OpenTelemetry를 사용하여 텔레메트리 데이터를 수집하고 분석하기 위해 애플리케이션을 계측해야 합니다.

계측의 방식으로 크게 자동 계측과 수동 계측이 존재합니다.

자동 계측 (Automatic Instrumentation): 자동 계측은 소스코드를 수정할 필요 없이 애플리케이션에 계측 코드를 추가하는 방식입니다. 자동 계측은 애플리케이션에 계측을 추가하는 가장 빠르고 쉬운 방법이 될 수 있지만 수동 계측만큼 유연하거나 사용자 지정이 불가능할 수 있습니다.
수동 계측 (Manual Instrumentation): 수동 계측은 소스코드를 수정하여 애플리케이션에 계측을 위한 코드를 추가하는 방식입니다. 이것은 자동 계측보다 더 많은 시간이 소요되는 프로세스일 수 있지만 더 많은 유연성과 사용자 지정을 제공합니다. 수동 계측을 사용하여 코드의 특정 부분에 대한 텔레메트리 데이터를 수집하거나 사용자 지정 계측 논리를 추가할 수 있습니다.

OpenTelemetry의 자동 계측

OpenTelemetry의 자동 계측은 다양한 언어 및 프레임워크에 대해 지원합니다. 자동 계측을 사용하려면 언어 및 프레임워크 용 SDK를 설치해야 합니다. SDK를 통해 자동으로 애플리케이션을 계측하고 텔레메트리 데이터를 수집합니다.

OpenTelemetry의 수동 계측

OpenTelemetry에서 애플리케이션을 수동으로 계측하려면 OpenTelemetry SDK를 애플리케이션에 추가하고 텔레메트리 데이터를 수집하는 계측 코드를 작성해야 합니다. 계측 코드는 애플리케이션의 모든 부분에 추가할 수 있습니다.

OpenTelemetry에서 수동 계측을 위한 작업 순서는 다음과 같습니다.

Step 1. 애플리케이션에 OpenTelemety SDK를 추가합니다.

첫 번째 단계는 애플리케이션에 OpenTelemetry SDK를 추가하는 것입니다. OpenTelemetry는 다양한 언어와 프레임워크를 지원합니다. OpenTelemetry 웹 사이트에서 언어 및 프레임워크 용 SDK를 찾을 수 있습니다.

Step 2. 텔레메트리 데이터를 수집하는 계측 코드를 작성합니다.

OpenTelemetry SDK를 애플리케이션에 추가한 후에는 텔레메트리 데이터를 수집하는 계측 코드를 작성해야 합니다. 계측 코드는 애플리케이션의 모든 부분에 추가할 수 있습니다.

다음은 트레이스를 수집하는 계측 코드의 예시입니다.

const {Tracer} = require('@opentelemetry/api')
const express = require('express')

const app = new express()

app.get('/', (req, res) => {
    // Create a tracer object
    const tracer = tracer.startSpan('my-span')
    
    // Create a span object
    const span = tracer.startSpan('my-span')

    // Add attributes to the span object
    span.setAttribute('key', 'value')

    // Set the span object's status
    span.setStatus(SpanStatus.OK)

    // End the span object
    span.end()

    // Do something with the request and response
    res.send('Hello, world!')
})

위의 계측 코드는 스팬을 만들고 작업을 수행한 다음 스팬을 완료합니다. 스팬은 OpenTelemetry SDK에서 수집하고 텔레메트리 백엔드로 전송됩니다.

Step 3. Opentelemetry SDK를 구성합니다.

텔레메트리 데이터를 다양한 텔레메트리 백엔드로 내보내도록 OpenTelemetry SDK를 구성할 수 있습니다. SDK를 구성하려면 구성 파일을 만들고 사용할 백엔드를 지정해야 합니다.

다음은 텔레메트리 데이터를 프로메테우스로 내보내는 구성 파일의 예시입니다.

exporters: 
  prometheus: 
    endpoint: http://localhost:9200/metrics

텔레메트리 백엔드를 사용하여 텔레메트리 데이터를 분석하고 시각화할 수 있습니다. 예를 들어 프로메테우스를 사용하여 대시보드에서 텔레메트리 데이터를 시각화할 수 있습니다.

OpenTelemetry의 Trace

OpenTelemetry에서 트레이스의 주요 구성요소는 다음과 같습니다.

Context
Span
Propagation
Sampling
Resource

Context

OpenTelemetry에서는 횡단 관심사를 처리하기 위해 컨텍스트를 사용합니다. 컨텍스트는 애플리케이션 코드의 실행 중에 사용되는 데이터 컨테이너로서 키-값 쌍으로 구성되어 있으며 분산 시스템에서는 여러 컴포넌트와 서비스가 함께 동작하므로 각각의 컴포넌트에서 데이터를 전달하여 전체 시스템에서 일관된 작업을 수행할 수 있도록 해야 합니다.

예를 들어, 트레이스를 처리하기 위해서는 생성한 trace ID와 span ID를 각 서비스에서 공유해야 하며 이를 위해서는 각 서비스에서 컨텍스트 정보를 다음 서비스에 전달해야 합니다.

OpenTelemetry에는 두 가지 유형의 컨텍스트가 있습니다.

Trace Context: 트레이스 컨텍스트는 분산 시스템을 통해 실행 흐름을 추적하는 데 사용됩니다. 트레이스 컨텍스트는 트레이스를 식별하는 키-값 쌍 세트입니다.
- Trace ID, Span ID 및 추적 플래그 필드 (샘플링 결정과 같은 트레이스에 대한 추가 정보) 등으로 구성됩니다.
- HTTP 헤더, gRPC 메타데이터 및 환경 변수와 같은 다양한 메커니즘을 사용하여 전파됩니다.
- 트레이스 컨텍스트는 스팬을 서로 연결하는 데 사용됩니다.
Baggage Context: 배기지 컨텍스트는 프로세스 경계를 넘어 전파될 수 있는 데이터의 임의의 키-값 쌍을 저장하는 데 사용됩니다.
- 트레이스 컨텍스트와 유사하지만 특정 트레이스와 연결되지 않습니다.
- 배기지 컨텍스트는 사용자 ID, 세션 ID 또는 요청 ID와 같은 정보를 전파하는 데 사용할 수 있습니다.

이러한 컨텍스트는 분산 시스템에서 텔레메트리 데이터를 수집하고 전파하는 데 사용됩니다. 성능 병목 현상을 식별하고 문제를 해결하며 애플리케이션의 전체 성능을 개선하는 데 사용할 수 있습니다.

Span

스팬은 분산 시스템에서 트레이스 내에 시간이 존재하는 단일 작업을 의미합니다. 스팬을 중첩하여 트레이스 트리를 구성할 수 있습니다. 각 트레이스에는 일반적으로 엔드투엔드 지연 시간을 나타내면서 트레이스의 시작점을 나타내는 루트 스팬 (Root Span)과 선택적으로 하위 작업에 대한 하나 이상의 하위 스팬 (Sub Span)이 포함됩니다.

스팬의 주요 구성요소는 다음과 같습니다.

Span ID: 트레이스 내의 스팬에 대한 고유 식별자입니다.
Trace ID: 스팬이 속한 전체 트레이스에 대한 고유 식별자입니다.
Parent Span ID: 현재 스팬의 생성에 직접적인 원인이 된 스팬의 ID 입니다.
Span 이름: 추적 중인 작업을 설명하는 사람이 읽을 수 있는 이름입니다.
Start Time: 스팬이 시작된 시간입니다.
End Time: 스팬이 종료된 시간입니다.
Status: 작업이 성공적으로 완료되었는지 또는 실패했는지를 나타내는 스팬의 상태입니다.
Attributes: 스팬에 대한 추가 정보를 제공하는 키-값 쌍 입니다.
Events: 스팬의 수명 동안 발생한 이벤트 목록으로, 사람이 읽을 수 있는 메시지입니다.
Links: 현재 스팬과 관련된 다른 스팬 또는 트레이스에 대한 링크 목록입니다.

Span Events 예시

예를 들어, 뮤텍스 아래에 있는 리소스에 대한 배타적 액세스가 필요한 함수가 있을 때, 이벤트는 두 지점에서 생성될 수 있습니다. 한 번은 리소스에 대한 액세스 권한을 얻으려고 할 때와 뮤텍스를 획득할 때 입니다. 다음 소스코드는 루비 언어의 예시입니다.

require "opentelemetry/sdk"

span = OpenTelemetry::Trace.current_span

span.add_event("Acquiring lock")
if mutex.try_lock
  span.add_event("Got lock, doing work...")
  # some code here
  span.add_event("Releasing lock")
else
  span.add_event("Lock already in use")
end

Propagation

전파는 분산 시스템에서 트레이스 정보를 전파하는 메커니즘입니다. 분산 시스템에서는 여러 컴포넌트와 서비스가 함께 동작하므로 각각의 컴포넌트에서 트레이스 정보를 전파하여 전체 트레이스 정보를 수집하는 것이 중요합니다.

컨텍스트 전파 도식화

OpenTelemetry에서 트레이스 정보를 전파하는 일련의 작업은 다음과 같습니다.

Step 1. 애플리케이션은 트레이스 컨텍스트를 생성합니다.
Step 2. 애플리케이션은 트레이스 컨텍스트를 다음 서비스로 전파합니다.
Step 3. 다음 서비스는 새 스팬을 생성하고 이를 트레이스 컨텍스트와 연결합니다.
Step 4. 다음 서비스는 트레이스 컨텍스트를 다음 서비스로 전파합니다.
Step 5. 이 프로세스는 트레이스가 끝날 때 까지 계속됩니다.

다음은 OpenTelemetry에서 트레이스 정보를 전파하는 방법의 예시입니다.

// Create a trace context.
const traceContext = new TraceContext()

// Propagate the trace context to the next service.
const nextService = new Service('next-service')
nextService.setTraceContext(traceContext)

// Create a new span and associate it with the trace context.
const span = new Span('my-span')
nextService.setTraceContext(traceContext)

// This process continues until the trace reaches its end.

이 코드는 다음 정보를 포함하는 트레이스를 생성합니다.

서비스 이름
스팬 이름
스팬 시작 시간
스팬 종료 시간
스팬 상태
스팬에 추가된 모든 속성

이러한 트레이스는 프로메테우스, 예거 및 집킨과 같은 다양한 형식으로 내보낼 수 있습니다.

전파 매개체: Carrier

캐리어는 분산 시스템의 서로 다른 서비스 간에 컨텍스트를 전송하는 데 사용할 수 있는 데이터 구조입니다. 가장 일반적인 캐리어는 HTTP 헤더와 gRPC 헤더입니다.

스팬이 생성되면 해당 컨텍스트가 캐리어를 사용하여 분산 시스템의 다음 서비스로 전파됩니다. 그런 다음, 다음 서비스는 캐리어에서 컨텍스트를 추출 (extract)하고 이를 사용하여 새 스팬을 생성할 수 있습니다. 이 프로세스는 트레이스가 끝에 도달할 때 까지 계속됩니다.

Carrier 예시 - HTTP Propagation

HTTP 통신에서 트레이스 정보를 전파하기 위해 HTTP 헤더에 'traceparent'와 'tracestate'를 등록할 수 있습니다.

다음은 HTTP 헤더에 트레이스 정보를 추가하는 코드의 예시입니다.

const headers = new Headers()
headers.append('traceparent', '00-000000-b3-1')
headers.append('tracestate', 'foo=bar')

const request = new Request('GET', 'https://example.com')
request.headers = headers

const response = await fetch(request)

Sampling

시스템에서 생성되는 트레이스 정보의 양을 제한하는 프로세스입니다. 이는 텔레메트리 데이터 수집 및 저장 비용을 줄이거나 특정 트레이스에 집중하는 등 다양한 이유로 수행할 수 있습니다.

Sampling 방식

OpenTelemetry는 트레이스 정보를 수집하기 위한 샘플링 방식을 크게 Head Sampling과 Tail Sampling으로 구분하고 있습니다.

Head Sampling: 트레이스 시작 부분에서 트레이스를 수집할 지 여부를 결정하는 샘플링 기술입니다. 이 방식은 구현이 간단하고 트레이스 실행에 대한 지식이 필요하지 않기 때문에 가장 일반적인 샘플링 기술입니다.
Tail Sampling: 트레이스의 끝에서 트레이스를 수집할 지 여부를 결정하는 샘플링 기술입니다. 이 기술은 헤드 샘플링보다 구현하기가 더 복잡하지만 관심이 있을 만한 트레이스만 수집하므로 더 효율적일 수 있습니다.

	Head Sampling	Tail Sampling
장점	간단한 구현 트레이스 실행에 대한 지식이 불필요 모든 트레이스 형식과 함께 사용 가능	관심있는 트레이스를 수집 관심이 있을 만한 트레이스만 수집하므로 헤드 샘플링보다 효율적임
단점	관심있는 트레이스를 수집하지 못할 수 있음 관심이 없을 수 있는 트레이스를 수집하므로 비효율적임	헤드 샘플링보다 구현이 복잡함 모든 트레이스 형식이 테일 샘플링을 지원하는 것은 아님

사용할 최상의 샘플링 기술은 애플리케이션의 요구 사항에 따라 달라집니다. 애플리케이션이 모든 트레이스를 수집해야 하는 경우 헤드 샘플링이 가장 좋은 옵션이며, 관심있는 트레이스만 수집하면 되는 경우 테일 샘플링이 더 나은 옵션일 수 있습니다.

Sampling 전략

OpenTelemetry에는 수집되는 텔레메트리 데이터의 양을 제어하는 데 사용할 수 있는 다양한 샘플링 전략이 있습니다. 샘플링 전략은 전역 수준에서 구성하거나 계측 대상 별로 구성할 수 있습니다.

OpenTelemetry의 기본 샘플링 전략은 트레이스의 100%를 샘플링하는 것입니다. 즉, 모든 트레이스가 수집되어 콜렉터로 보내집니다. 그러나 이것은 특히 트래픽이 많은 애플리케이션의 경우 많은 양의 데이터가 될 수 있습니다.

수집되는 텔레메트리 데이터의 양을 줄여야 하는 경우 트레이스의 하위 집합을 샘플링하는 전략을 사용할 수 있습니다. 다음을 포함하여 사용할 수 있는 다양한 샘플링 전략이 있습니다.

확률 샘플링: 이 전략은 확률을 기반으로 트레이스를 샘플링합니다. 예를 들어 트레이스의 1%를 샘플링하도록 샘플링 전략을 구성할 수 있습니다.
지속적인 샘플링: 이 전략은 특정 기준을 충족하는 모든 트레이스를 샘플링합니다. 예를 들어 기간이 100ms를 초과하는 모든 트레이스를 샘플링하도록 샘플링 전략을 구성할 수 있습니다.
비율 제한: 이 전략은 초당 수집되는 트레이스 수를 제한합니다. 예를 들어 트레이스 수집을 초당 100개의 트레이스로 제한하도록 샘플링 전략을 구성할 수 있습니다.

애플리케이션에 가장 적합한 샘플링 전략은 애플리케이션의 특정 요구 사항에 따라 달라집니다. 사용할 샘플링 전략이 확실하지 않은 경우 기본 샘플링 전략으로 시작한 다음 필요에 따라 조정할 수 있습니다.

Resource

OpenTelemetry에서 리소스는 텔레메트리 속성으로 생성하는 엔터티의 불변 표현을 의미합니다. 예를 들어 쿠버네티스의 컨테이너에서 실행 중인 텔레메트리 데이터를 생성하는 프로세스에는 파드 이름, 네임스페이스 및 배포 이름이 있습니다. 이 세 가지 속성 모두 리소스에 포함될 수 있습니다.

리소스는 텔레메트리를 생성하는 엔터티를 식별하고 텔레메트리 데이터에 대한 컨텍스트를 제공하는 데 사용됩니다. 예를 들어 트레이스 또는 메트릭 데이터가 시스템의 대기 시간을 나타내는 경우 특정 컨테이너, 포드 또는 쿠버네티스 배포로 범위를 좁힐 수 있습니다.

이 리소스는 텔레메트리 데이터를 분류하는 데에도 사용됩니다. 예를 들어 리소스를 사용하여 다른 애플리케이션 또는 다른 환경의 텔레메트리 데이터를 구별할 수 있습니다.

OpenTelemetry의 구성요소

OpenTelemetry 구조 도식화

OpenTelemetry의 주요 구성요소는 다음과 같습니다.

OpenTelemetry API: OpenTelemetry API는 텔레메트리 데이터를 수집하고 내보내는 표준 방법을 제공하는 언어 간 API입니다.
OpenTelemetry SDKs: OpenTelemetry SDK는 OpenTelemetry API의 언어별 구현을 제공합니다.
OpenTelemetry Collector: OpenTelemetry 콜렉터는 여러 소스에서 텔레메트리 데이터를 수집하고 집계하는 서비스입니다.
OpenTelemetry Exporters: OpenTelemetry 익스포터는 텔레메트리 데이터를 프로메테우스, 그라파나 및 예거와 같은 다양한 대상으로 내보냅니다.
OpenTelemetry Semantic Conventions: OpenTelemetry 시맨틱 규칙은 텔레메트리 데이터의 이름을 지정하고 형식을 지정하는 표준 방법을 제공합니다.

이들은 OpenTelemetry의 주요 구성 요소입니다. 이들은 함께 텔레메트리 데이터를 수집, 집계 및 내보내기 위한 포괄적인 솔루션을 제공합니다.

OpenTelemetry API

OpenTelemetry API는 소프트웨어를 계측하는 일관된 방법을 제공하는 언어 독립적인 API입니다. 또한 공급업체에 구애받지 않도록 설계되었으므로 모든 텔레메트리 콜렉터 또는 익스포터와 함께 사용할 수 있습니다.

OpenTelemetry SDK

OpenTelemetry SDK는 소프트웨어 시스템에서 텔레메트리 데이터를 수집하고 내보내는 일관된 방법을 제공하는 OpenTelemetry API를 구현한 라이브러리 세트입니다.

OpenTelemetry SDK는 다음과 같은 주요 구성 요소로 구성됩니다.

Instrumentation Library: 계측 라이브러리는 텔레메트리 데이터로 소프트웨어 시스템을 계측하는 데 사용됩니다. 계측 라이브러리는 다양한 프로그래밍 언어로 제공됩니다.
Tracer: 트레이서는 스팬 및 메트릭과 같은 텔레메트리 데이터를 수집하고 기록하는 일을 담당합니다.
Exporter: 익스포터는 트레이서에서 프로메테우스, 그라파나 및 엘라스틱서치와 같은 다양한 대상으로 텔레메트리 데이터를 내보내는 데 사용됩니다.

OpenTelemetry SDK는 텔레메트리 데이터를 수집하고 내보내는 강력한 도구입니다. 사용하기 쉽고 다양한 프로그래밍 언어와 플랫폼에서 지원됩니다.

OpenTelemetry Collector

OpenTelemetry 콜렉터는 여러 소스에서 텔레메트리 데이터를 수집하고 집계하는 서비스입니다. 메트릭, 트레이스 및 로그를 수집하는 데 사용할 수 있습니다. 콜렉터는 온프레미스, 클라우드 및 하이브리드 환경을 비롯한 다양한 환경에 배포할 수 있습니다.

OpenTelemetry Collector 작업 프로세스 도식화

OpenTelemetry Collector 구성요소

콜렉터는 다음과 같은 여러 주요 구성요소가 있습니다.

Receivers: 리시버는 애플리케이션에서 텔레메트리 데이터를 수집하는 역할을 합니다.
Processors: 프로세서는 텔레메트리 데이터 처리를 담당합니다. 여기에는 데이터 필터링, 변환 및 집계가 포함될 수 있습니다.
Exporters: 익스포터는 텔레메트리 데이터를 다양한 대상으로 내보낼 책임이 있습니다.

콜렉터는 다음을 비롯한 다양한 소스에서 텔레메트리 데이터를 수집하는 데 사용할 수 있습니다.

애플리케이션: 콜렉터는 OpenTelemetry SDK로 계측된 애플리케이션에서 텔레메트리 데이터를 수집하는 데 사용할 수 있습니다.
인프라: 콜렉터는 서버, 데이터베이스 및 네트워크와 같은 인프라 구성 요소에서 텔레메트리 데이터를 수집하는 데 사용할 수 있습니다.
클라우드 서비스: 콜렉터는 AWS, Azure 및 Google Cloud Platform과 같은 클라우드 서비스에서 텔레메트리 데이터를 수집하는 데 사용할 수 있습니다.

OpenTelemetry Collector에서 Processor의 처리 방식

OpenTelemetry 콜렉터에서 프로세서의 데이터 처리 방식은 크게 '배치 프로세서 (Batch Processor)'와 '심플 프로세서 (Simple Processor)'로 구분됩니다. 배치 프로세서와 심플 프로세서의 주요 차이점은 배치 프로세서는 텔레메트리 데이터를 내보내기 전에 함께 그룹화하는 반면, 심플 프로세서는 텔레메트리 데이터를 수신하는 즉시 내보냅니다.

배치 프로세서를 사용하여 수행되는 네트워크 요청 수를 줄임으로써 OpenTelemetry 콜렉터의 성능을 향상시킬 수 있습니다. 이는 배치 프로세서가 텔레메트리 데이터를 함께 그룹화하고 단일 요청으로 내보낼 수 있기 때문입니다. 이는 대량의 텔레메트리 데이터에 특히 유용할 수 있습니다.

심플 프로세서는 일반적으로 OpenTelemetry 콜렉터의 성능이 문제가 되지 않을 때 사용됩니다. 이는 심플 프로세서가 원격 측정 데이터를 수신하는 즉시 내보내기 때문입니다. 이는 실시간 텔레메트리 데이터가 필요한 애플리케이션에 유용할 수 있습니다.

	배치 프로세서	심플 프로세서
텔레메트리 데이터를 내보내기 전에 함께 그룹화합니다	아니오	예
네트워크 요청 수 감소	예	아니오
대량의 텔레메트리 데이터에 유용	예	아니오
실시간 텔레메트리 데이터가 필요한 애플리케이션에 유용	아니오	예

궁극적으로 최상의 프로세서 선택은 특정 요구 사항에 따라 다릅니다. OpenTelemetry 콜렉터의 성능이 우려되는 경우 배치 프로세서를 사용해야 합니다. OpenTelemetry 콜렉터의 성능에 대해 걱정하지 않는다면 심플 프로세서를 사용할 수 있습니다.

OpenTelemetry Collector의 배포 모드

OpenTelemetry 콜렉터는 에이전트 모드와 게이트웨이 모드의 두 가지 모드로 배포할 수 있습니다.

OpenTelemetry Collector 배포 프로세스 도식화

Agent Mode: 에이전트 모드에서 콜렉터는 모니터링 중인 애플리케이션과 함께 배포됩니다. 콜렉터는 애플리케이션에서 텔레메트리 데이터를 수집하여 중앙 위치로 보냅니다.
Gateway Mode: 게이트웨이 모드에서 콜렉터는 독립 실행형 서비스로 배포됩니다. 콜렉터는 여러 소스에서 텔레메트리 데이터를 수집하고 중앙 위치로 보내기 전에 집계합니다.

에이전트와 게이트웨이의 주요 차이점은 텔레메트리 데이터를 수집하는 방법입니다. 에이전트는 함께 배포된 애플리케이션에서 텔레메트리 데이터를 수집합니다. 게이트웨이는 여러 소스에서 텔레메트리 데이터를 수집합니다.

게이트웨이는 에이전트에 비해 다음과 같은 몇 가지 이점을 제공합니다.

중앙 집중식 수집: 게이트웨이는 애플리케이션의 관리 및 모니터링을 단순화할 수 있는 여러 소스에서 텔레메트리 데이터를 수집합니다.
향상된 성능: 게이트웨이는 텔레메트리 수집을 전용 서비스로 오프로드하여 애플리케이션의 성능을 향상시킬 수 있습니다.
유연성: 게이트웨이는 다양한 환경에 배포할 수 있으므로 에이전트보다 더 유연합니다.

애플리케이션의 옵저버빌리티를 개선할 방법을 찾고 있다면 게이트웨이를 사용하는 것이 좋습니다. 게이트웨이는 중앙 집중식 수집, 향상된 성능 및 유연성을 포함하여 에이전트에 비해 많은 이점을 제공합니다.

OpenTelemetry Exporter

OpenTelemetry 익스포터는 수집된 트레이스 데이터를 외부 시스템으로 전송하는 역할을 합니다. 익스포터는 수집된 트레이스 데이터를 다양한 형식으로 변환하여 원하는 시스템으로 전송합니다.

OpenTelemetry의 텔레메트리 데이터 처리 프로세스 도식화

예를 들어, 트레이스 데이터를 JSON 형식으로 변환하여 HTTP 프로토콜을 사용하여 Elasticsearch로 전송할 수 있습니다. 또는, 트레이스 데이터를 Protocol Buffers 형식으로 변환하여 gRPC 프로토콜을 사용하여 Jaeger로 전송할 수도 있습니다.

OpenTelemetry에서는 다양한 익스포터를 제공합니다. 예를 들어, Jaeger, Zipkin, Prometheus, Elasticsearch, AWS X-Ray 등이 있습니다. 이러한 익스포터를 사용하여 트레이스 데이터를 다양한 시스템으로 전송할 수 있습니다. 또한, 사용자 정의 익스포터를 작성하여 원하는 시스템으로 트레이스 데이터를 전송할 수도 있습니다.

OpenTelemetry Semantic Conventions

시맨틱 규칙은 텔레메트리 데이터의 일관된 수집 및 분석을 허용하기 때문에 OpenTelemetry에서 중요합니다. 이러한 일관성은 다음과 같은 여러 가지 이유로 중요합니다.

교차 도구 분석 활성화: 시맨틱 규칙을 통해 도구는 다른 도구를 사용하여 데이터를 수집한 경우에도 텔레메트리 데이터의 의미를 이해할 수 있습니다. 이를 통해 서로 다른 도구의 데이터를 함께 사용할 수 있으므로 보다 포괄적이고 정확한 분석이 가능합니다.
텔레메트리 데이터의 품질 향상: 의미 체계는 일관되고 표준화된 방식으로 수집되도록 하여 텔레메트리 데이터의 품질을 향상시키는 데 도움이 될 수 있습니다. 이렇게 하면 오류를 줄이고 문제를 더 쉽게 해결할 수 있습니다.
텔레메트리 분석 데이터의 접근성 향상: 시맨틱 규칙은 텔레메트리 분석 데이터를 보다 쉽게 이해하고 사용할 수 있도록 하여 접근성을 높일 수 있습니다. 이를 통해 문제 해결 및 분석의 효율성을 높일 수 있습니다.

시맨틱 규칙이 없으면 텔레메트리 데이터를 이해하기 어려울 수 있습니다. 예를 들어 서로 다른 두 팀이 동시에 동일한 애플리케이션에 대한 메트릭을 수집하는 경우 동일한 메트릭에 대해 서로 다른 이름을 사용하거나 동일한 메트릭에 대해 서로 다른 속성을 수집할 수 있습니다. 이로 인해 두 팀의 데이터를 비교하거나 데이터를 사용하여 문제를 해결하기가 어려울 수 있습니다.

시맨틱 규칙은 텔레메트리 데이터를 설명하기 위한 공통 어휘를 제공하여 이 문제를 해결하는 데 도움이 됩니다. 이를 통해 다양한 도구와 팀에서 텔레메트리 데이터를 일괄되게 수집, 분석 및 시각화할 수 있습니다.

현재 시맨틱 규칙은 트레이스, 메트릭 및 리소스에 사용할 수 있습니다.

Semantic Conventions | OpenTelemetry.io

Semantic Convention 예시

다음은 OpenTelemetry의 시맨틱 규칙의 예시입니다.

메트릭 이름: 메트릭 이름을 설명적이어야 하며 일관된 명명 규칙을 따라야 합니다. 예를 들어 현재 진행 중인 동시 HTTP 요청 수를 측정하는 메트릭은 "http.server.active_requests"라는 이름을 가져야 합니다.

이 이름은 설명적이며 일관된 명명 규칙을 따릅니다. 메트릭이 무엇을 측정하는 지 명확하고 다른 메트릭과 어떻게 관련되는 지 쉽게 이해할 수 있습니다.

시맨틱 규칙을 따르면 텔레메트리 데이터가 일관되고 정확하고 사용하기 쉬운지 확인할 수 있습니다. 이는 보다 포괄적이고 정확한 분석으로 이어져 애플리케이션 및 서비스의 성능과 안정성을 개선하는 데 도움이 될 수 있습니다.

기타: OTLP

OTLP는 OpenTelemetry 프로토콜을 나타냅니다. 텔레메트리 데이터를 수집하고 내보내는 표준 방법입니다. OTLP는 효율적이고 확장 가능하며 안전하도록 설계되었습니다. 또한 다른 옵저버빌리티 도구와 상호 운용이 가능하도록 설계되었습니다.

OTLP 사용의 이점은 다음과 같습니다.

효율성: OTLP는 효율적으로 설계되어 텔레메트리 데이터를 수집하고 내보내는 오버헤드를 줄이는 데 도움이 될 수 있습니다.
확장성: OTLP는 확장 가능하도록 설계되어 대규모 시스템에서 텔레메트리 데이터의 수집 및 내보내기를 지원하는 데 도움이 될 수 있습니다.
보안: OTLP는 텔레메트리 데이터의 기밀성, 무결성 및 가용성을 보호하는 데 도움이 되도록 안전하게 설계되었습니다.
상호 운용성: OTLP는 텔레메트리 데이터를 최대한 활용하는 데 도움이 되는 다른 옵저버빌리티 도구와 상호 운용이 가능하도록 설계되었습니다.

텔레메트리 데이터를 수집하고 내보내는 방법을 찾고 있다면 OTLP를 사용하는 것이 좋습니다. 효율적이고 확장 가능하며 안전하고 상호 운용 가능한 원격 측정 데이터를 수집하고 내보내는 표준 방법입니다.

기타: OpenTelemetry Metric 유형

OpenTelemetry는 네 가지 메트릭 유형을 정의합니다.

카운터: 카운터는 누적 값을 추적하는 데 사용됩니다. 증가하거나 감소할 수 있습니다.
게이지: 게이지는 현재 값을 추적하는 데 사용됩니다. 임의의 값으로 설정할 수 있습니다.
히스토그램: 히스토그램은 값의 분포를 추적하는 데 사용됩니다. 요청 대기 시간 또는 응답 크기와 같은 항목을 추적하는 데 사용할 수 있습니다.
요약 (legacy): 요약은 히스토그램과 비슷하지만 더 가볍습니다. 오류 또는 시간 초과와 같은 항목을 추적하는 데 사용할 수 있습니다. 요약은 OpenTelemetry의 다른 유형과 달리 요약은 항상 의미있는 방식으로 병합될 수 없습니다. 이 유형은 새 애플리케이션에 권장되지 않으며 다른 형식과 호환성을 위해 존재합니다.

Metric data model | OpenTelemetry.io

Unified ServerlessObservability With OpenTelemetry and StackState v4.6 | StackState

마무리

결론적으로 OpenTelemetry는 텔레메트리 데이터를 수집하고 내보내는 강력한 도구입니다. 사용하기 쉽고 다양한 프로그래밍 언어와 플랫폼에서 지원됩니다. 텔레메트리 데이터를 수집하고 내보내는 방법을 찾고 있다면 OpenTelemetry가 좋은 선택지입니다.

Assisted by

ChatGPT, Bard

AgentGPT에게 "심장마비로 쓰러진 사람을 발견했을 때 나의 행동"을 물어보았다.

혼새미로 — Sat, 22 Apr 2023 13:51:23 +0900

"The krusty the clown" - Midjourney

AgentGPT

AgentGPT는 AutoGPT와 같이 ChatGPT API를 기반으로 주어진 프롬프트에 대해 스스로 필요한 태스크를 생성하고, 태스크들을 프롬프트로 하여 응답과 서브 태스크를 생성하는 AI 제품입니다. AutoGPT는 로컬 환경에 직접 설치해야 하는 번거로움이 있지만, AgentGPT는 https://agentgpt.reworkd.ai/ 에서 직접 사용해볼 수 있습니다.

프롬프트 입력 및 응답 살펴보기

심장마비
새로운 목표에 도전하기: 누군가 내 눈앞에서 심장마비로 쓰러진다면 어떻게 해야 할까요?

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 시각 및 청각 신호를 통해 사람의 신체적 쓰러짐 감지
추가된 작업: 심장마비 가능성을 판단하기 위해 환자의 증상을 평가합니다.
추가된 작업: 응급 의료 서비스를 요청하거나 주변 사람들에게 알리면서 심폐소생술 또는 기타 인명 구조 기
술을 수행하는 방법을 안내합니다.

생각 중...(30초 이상 걸리면 다시 시작)
"시각 및 청각 단서를 통해 사람의 신체적 쓰러짐 감지" 작업 실행:
인공지능으로서 저의 주요 목표는 응급 상황에서 도움을 주고 안내하는 것입니다. 누군가 내 눈앞에
서 심장마비로 쓰러진다면 시각 및 청각 신호를 통해 그 사람의 신체적 쓰러짐을 감지하는 것이 가장 먼
저 해야 할 일입니다.

이를 위해 주변 환경을 스캔하고 그 사람의 행동을 분석하여 쓰러졌는지 확인합니다. 쓰러짐의 징후로는
의식을 잃거나 바닥에 쓰러지거나 호흡 곤란이 있을 수 있습니다. 또한 호흡 곤란을 나타낼 수 있는 헐떡
거림이나 신음과 같은 소리가 들리는지도 확인합니다.

사람이 쓰러진 것을 감지하면 다음 단계는 즉시 지역 응급 번호(예: 911)로 전화하여 응급 의료 서비스를 요
청하는 것입니다. 그런 다음 교환원에게 환자의 위치와 상황에 대한 필요한 세부 정보를 제공합니다.

응급 의료 서비스가 도착할 때까지 기다리는 동안 환자의 상태를 평가하고 필요한 도구를 갖춘 경우 심폐
소생술 또는 제세동과 같은 필요한 응급 처치를 시행합니다.

요약하자면, 누군가 내 눈앞에서 심장마비로 쓰러진다면 시각 및 청각적 신호를 통해 신체적 쓰러짐을 즉
시 감지하고 응급 의료 서비스를 요청하며 도움이 도착할 때까지 필요한 응급 처치를 실시할 것입니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 필요한 경우 필요한 도구를 갖추고 있는 경우 심폐소생술 또는 제세동을 실시합니다. 생각 중
...(30초 이상 걸리면 다시 시작)
"심장마비 가능성을 판단하기 위해 환자의 증상 평가" 실행하기
환자의 증상을 평가한 후 심장마비 징후가 있다고 판단되면 즉시 응급 서비스에 연락하여 의료 지원을
요청합니다. 구급대가 도착할 때까지 기다리는 동안 환자와 함께 있으면서 다음과 같은 필요한 응급 처치를
제공합니다.

꽉 조이는 옷을 느슨하게 하고 편안하게 누워 있도록 합니다. 환자가 의식이 없는 경우 의료진이 도착할
때까지 심폐소생술을 실시합니다. 심장마비를 경험한 사람의 생존 가능성을 높이려면 이런 상황에서 신
속하게 행동하는 것이 중요합니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 필요한 경우 필요한 도구를 갖추고 있는 경우 심폐소생술 또는 제세동을 실시합니다. 생각 중
...(30초 이상 걸리면 다시 시작)
"응급 의료 서비스를 요청하거나 주변 사람들에게 알리면서 심폐소생술 또는 기타 인명 구조 기술을 수행하
는 방법을 안내하기" 실행하기
"저는 즉시 상황을 평가하고 환자가 반응하는지 여부를 판단합니다. 환자가 반응이 없고 숨을 쉬지 않거
나 헐떡이기만 한다면 즉시 응급 의료 서비스를 요청하는 동시에 주변에 있는 사람들에게도 알릴 것입니다.

의료진의 도움을 기다리는 동안 심폐소생술 또는 기타 인명 구조 기술을 익힌 경우 해당 기술을 수행하는
방법에 대한 지침을 제공합니다. 이러한 상황에서는 심장마비 환자의 생존 가능성을 높이기 위해 신속하
게 행동하는 것이 중요합니다."
생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 필요한 경우 필요한 도구를 갖추고 있는 경우 심폐소생술 또는 제세동을 실시합니다.
생각 중...(30초 이상 걸리면 다시 시작)
"필요한 경우 심폐소생술 또는 제세동을 시행하고 필요한 도구를 갖추고 있습니다."를 실행합니다.

인공지능인 저는 심폐소생술이나 제세동을 수행할 수 있는 신체적 장비가 없기 때문에 해당 작업을 수행
할 수 없습니다. 하지만 눈앞에서 심장마비로 쓰러지는 사람이 있다면 즉시 응급 서비스에 연락하고 의료
진이 도착할 때까지 가능한 모든 도움을 제공해야 합니다. 침착하게 의료진의 지시를 따르세요. 응급 상황
에서는 시간이 매우 중요하므로 신속하게 행동하고 가능한 한 빨리 도움을 요청하세요.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 심장마비로 쓰러진 사람이 있으면 즉시 응급 서비스에 연락하고 의료진이 도착할 때까지 가
능한 모든 도움을 제공하세요. 의료진의 지시에 따라 침착하게 행동하세요.

응급 상황에서는 시간이 매우 중요하므로 신속하게 행동하고 가능한 한 빨리 도움을 요청하세요. 생각 중
...(30초 이상 걸리면 다시 시작하세요)
"필요한 경우 심폐소생술 또는 제세동을 시행하고 필요한 도구를 갖추고 있습니다."를 실행합니다.

인공지능인 저는 심폐소생술이나 제세동을 시행할 수 있는 신체적 능력을 갖추지 못했습니다. 하지만 제
눈앞에서 심장마비로 쓰러진 사람이 있다면 즉시 응급 의료 서비스를 요청하고 필요한 정보를 교환원에게
제공할 것입니다. 또한 의료 지원이 도착할 때까지 기다리는 동안 환자가 침착하고 편안하게 지낼 수 있
도록 노력할 것입니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 호흡과 맥박의 징후를 확인합니다.

추가된 작업: 환자가 숨을 쉬지 않거나 맥박이 없으면 흉부압박을 시작하세요.
추가된 작업: 의료진이 도착할 때까지 흉부압박을 계속하세요.

생각 중...(30초 이상 걸리면 다시 시작)
"필요한 경우 심폐소생술 또는 제세동을 시행하고 필요한 도구를 갖추고 있습니다."를 실행합니다.

에이전트GPT라는 자율 작업 수행 AI로서 제 목표는 바로 눈앞에서 누군가가 심장마비로 쓰러지는 시나
리오에 대응하는 것입니다. 이 상황에서 저는 필요한 도구가 있다면 심폐소생술이나 제세동을 실시할
것입니다.

제세동기를 사용할 수 있는 경우, 제세동기의 지침에 따라 환자의 심장에 충격을 가합니다. 제세동기를
사용할 수 없는 경우, 환자를 등을 대고 눕힌 다음 기도를 열고 필요에 따라 흉부 압박과 인공호흡을 실
시하는 등 심폐소생술을 시작합니다.

누군가 심장마비를 경험하는 경우 시간이 가장 중요하다는 점에 유의하는 것이 중요합니다. 따라서 저는 환자
의 생명을 구하기 위해 필요한 치료를 신속하고 효율적으로 제공할 것입니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 심폐소생술 또는 제세동을 시행한 후에도 환자가 반응하지 않으면 의료진이 도착할 때까지
흉부압박을 계속합니다.

생각 중...(30초 이상 걸리면 다시 시작)
"심장마비로 쓰러지는 사람이 있으면 즉시 응급 서비스에 연락하고 의료진이 도착할 때까지 가능한 모
든 도움을 제공하세요. 의료진의 지시에 따라 침착하게 행동하세요.

응급 상황에서는 시간이 매우 중요하므로 신속하게 행동하고 가능한 한 빨리 도움을 요청하세요."
심장마비로 쓰러진 사람이 있으면 즉시 응급 서비스에 연락하고 의료진이 도착할 때까지 가능한 모든 도
움을 제공합니다. 의료진의 지시를 따르고 침착함을 유지하겠습니다. 응급 상황에서는 시간이 매우 중
요하므로 신속하게 행동하고 가능한 한 빨리 도움을 요청하겠습니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 호흡과 맥박의 징후를 확인합니다.

추가된 작업: 환자가 숨을 쉬지 않거나 맥박이 없으면 흉부압박을 시작하세요.
추가된 작업: 의료진이 도착할 때까지 흉부압박을 계속하세요.

추가된 작업: 심폐소생술 또는 제세동을 시행한 후에도 환자가 반응하지 않으면 의료진이 도착할 때까지
흉부압박을 계속합니다.

생각 중...(30초 이상 걸리면 다시 시작)
"호흡 및 맥박 징후 확인"을 실행합니다.

작업 실행:
먼저 상황을 평가하고 쓰러진 사람의 호흡과 맥박이 있는지 신속하게 확인합니다. 호흡이나 맥박의 징
후가 없으면 즉시 의료진이나 구급차를 불러야 합니다. 필요한 경우 의료진이 도착할 때까지 CPR(심폐
소생술)을 실시하여 환자가 추가 손상을 방지하기 위해 필요한 치료를 받을 수 있도록 합니다. 이러한 상
황에서는 누군가의 생명을 구할 수 있으므로 신속하게 행동하고 침착함을 유지하는 것이 중요합니다.

응답:
"저는 먼저 쓰러진 사람의 호흡과 맥박이 정상인지 확인합니다. 징후가 없으면 즉시 의료진이나 구급차
를 불러야 합니다. 필요한 경우 추가 손상을 방지하기 위해 의료 지원이 도착할 때까지 심폐소생술을 실
시합니다. 이러한 상황에서는 누군가의 생명을 구하기 위해 신속하게 행동하고 침착함을 유지하는 것이
중요합니다."
생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 환자가 숨을 쉬지 않거나 맥박이 없으면 흉부압박을 시작하세요.
추가된 작업: 의료진이 도착할 때까지 흉부압박을 계속하세요.

추가된 작업: 심폐소생술 또는 제세동을 시행한 후에도 환자가 반응하지 않으면 의료진이 도착할 때까지
흉부압박을 계속합니다.

생각 중...(30초 이상 걸리면 다시 시작)
"환자가 숨을 쉬지 않거나 맥박이 없으면 흉부압박을 시작하세요."를 실행합니다.

환자가 숨을 쉬지 않거나 맥박이 없으면 즉시 흉부압박을 시작합니다.
생각 중...(30초 이상 걸리면 다시 시작하세요)
추가된 작업: 자동심장충격기(AED)를 사용할 수 있는지 확인하고 사용할 수 있는 경우 지침을 따릅니다.

추가 작업: 자동심실제세동기를 사용할 수 없는 경우 의료진이 도착할 때까지 흉부압박을 계속합니다. 생각
중...(30초 이상 걸리면 다시 시작하세요)
"의료진이 도착할 때까지 흉부압박 계속하기"를 실행합니다.

심장마비로 쓰러진 사람에게 대응하는 임무를 맡은 인공지능으로서 제 프로그래밍된 임무는 의료진이
도착할 때까지 흉부 압박을 계속하는 것입니다. 따라서 저는 주저 없이 이 임무를 즉시 실행할 것입니다.

개인의 안전과 안녕이 가장 중요하므로 의료진이 도착할 때까지 최선을 다해 도울 것입니다.

생각 중...(30초 이상 걸리면 다시 시작)

작업 추가됨:즉시 응급 서비스에 전화하세요.

추가된 작업: 주변 사람들에게 해당 구역을 비우고 의료진을 위한 공간을 확보하도록 지시하세요.
추가된 작업: 개인의 호흡과 맥박을 계속 모니터링하세요.

추가된 작업: 필요에 따라 심폐소생술 및/또는 제세동을 실시합니다.

추가된 작업: 의료진이 도착하면 필요한 정보를 제공합니다.

생각 중...(30초 이상 걸리면 다시 시작)
"심폐소생술 또는 제세동을 시행한 후에도 환자가 반응하지 않으면 의료진이 도착할 때까지 흉부압박을
계속합니다."를 실행합니다.

"자율적으로 작업을 수행하는 AI로서 누군가 내 눈앞에서 심장마비로 쓰러진다면 즉시 응급 의료 지원을
요청할 것입니다. 그런 다음 환자가 숨을 쉬지 않거나 심장이 멈추면 가능한 경우 심폐소생술과 제세동
을 실시할 것입니다. 이러한 조치 후에도 환자가 반응하지 않으면 의료진이 도착할 때까지 가슴압박을
계속합니다."
생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 환자의 기도에 장애물이 있는지 확인하고 필요한 경우 제거합니다. 생각 중...(30초 이상 걸리면
다시 시작)
"호흡 및 맥박 징후 확인"을 실행합니다. 작업 실행:
심장마비로 쓰러진 사람의 호흡과 맥박의 징후를 확인하는 작업을 수행했습니다. 눈앞에서 심장마비로
쓰러진 사람이 있다면 가장 먼저 해야 할 일은 응급 의료 지원을 요청하는 것입니다. 그런 다음 호흡과
맥박의 징후를 확인합니다. 호흡을 확인하려면 환자의 입과 코에 귀를 가까이 대고 숨소리를 들어보세
요. 또한 가슴이 오르락내리락하는지도 살펴보세요. 맥박을 확인하려면 턱선 바로 아래 목에 두 손가락
을 대고 맥박이 느껴지는지 확인합니다. 호흡이나 맥박이 없으면 구조대가 도착할 때까지 CPR(심폐소
생술)을 실시해야 합니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 호흡이나 맥박이 없는 경우 응급 의료진이 도착할 때까지 기다리는 동안 즉시 심폐소생술을
시작하세요.

생각 중...(30초 이상 걸리면 다시 시작)
"환자가 숨을 쉬지 않거나 맥박이 없으면 흉부압박을 시작하세요."를 실행합니다.

환자가 숨을 쉬지 않거나 맥박이 없는 경우, 의료진이 도착할 때까지 산소가 풍부한 혈액을 중요한 장기
로 순환시키기 위해 흉부압박을 시작합니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 자동심실제세동기(AED)를 사용할 수 있는 경우, 흉부압박을 계속하기 전에 사용 지침을 따르세
요.

추가 작업: 환자가 의식을 회복하고 정상적으로 호흡할 수 있게 되면 회복 자세로 눕히고 의료진이 도착
할 때까지 호흡을 모니터링합니다.

생각 중...(30초 이상 걸리면 다시 시작)
"의료진이 도착할 때까지 흉부압박 계속하기"를 실행합니다.

인공지능인 저는 가슴 압박을 할 수 있는 신체적 기능이 없습니다. 하지만 심장마비로 쓰러진 사람이 있을
경우, 즉시 응급 서비스에 연락하고 의료진이 도착할 때까지 지시를 따르는 것이 좋습니다. 침착함을 유
지하면서 환자를 평평하게 눕히고 필요한 경우 기도를 확보하는 등 기본적인 생명유지 조치를 취하는 것
이 중요합니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 심장마비로 쓰러지는 사람이 있으면 즉시 응급 서비스에 연락하고 의료진이 도착할 때까지
지시를 따르세요.

추가 작업: 환자가 평평하게 누워 있는지 확인하고 필요한 경우 기도를 확보하는 등 기본적인 생명유지 조
치를 취합니다.

추가 작업: 방관자에게 해당 지역을 비우고 의료진을 위한 공간을 확보하도록 지시하세요. 생각 중...(30초 이
상 걸리면 다시 시작)
"심폐소생술 또는 제세동을 시행한 후에도 환자가 반응하지 않으면 의료진이 도착할 때까지 흉부압박을
계속합니다."를 실행합니다.

자율적으로 작업을 수행하는 AI로서 누군가 내 눈앞에서 심장마비로 쓰러졌다면, 제 목표는 그 사람이 최
대한 생존할 수 있도록 즉각적인 도움을 제공하는 것입니다. 먼저 환자를 빠르게 평가하여 반응이 없고 숨을
쉬지 않는지 확인합니다. 만약 호흡이 없다면 즉시 CPR(심폐소생술)을 실시합니다.

제세동기를 사용할 수 있는 경우, 제세동기를 사용하여 환자의 심장에 전기 충격을 가해 정상 리듬을 회복
시키려고 노력합니다. 심폐소생술이나 제세동을 시행한 후에도 환자가 반응하지 않으면 의료진이 도착할 때
까지 흉부압박을 계속합니다.

제 우선 순위는 환자가 치료를 받을 수 있을 때까지 생명을 유지하는 것입니다. 따라서 저는 환자와 함께 있
으면서 활력 징후를 모니터링하고 구조대가 도착할 때까지 필요에 따라 흉부압박을 계속 실시합니다.

요약하자면, 누군가 내 눈앞에서 심장마비로 쓰러졌다면 저는 심폐소생술을 시행하고, 가능한 경우 제세
동기를 사용하고, 의료진이 도착할 때까지 흉부압박을 계속할 것입니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 업무: 심폐소생술을 시행한 후에도 맥박이 없는 경우, 환자의 기도에 막힌 것이 없는지 확인하
고 필요한 경우 이를 제거한 후 흉부압박을 재개합니다.
추가된 업무: 환자가 의식을 되찾는 징후를 보이면 회복 자세를 취하고 의료진이 도착할 때까지 호흡을 모니터링합니다.

생각 중...(30초 이상 걸리면 다시 시작)
"환자가 숨을 쉬지 않거나 맥박이 없으면 흉부압박을 시작하세요."를 실행합니다.

"환자가 숨을 쉬지 않거나 맥박이 없으면 즉시 흉부압박을 시작합니다."
생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 환자가 호흡 징후를 보이면 호흡과 맥박을 모니터링하고 의료 전문가가 도착할 때까지 기
본적인 생명 유지 조치를 계속합니다.

생각 중...(30초 이상 걸리면 다시 시작)
"의료진이 도착할 때까지 흉부압박 계속하기"를 실행합니다.

인공지능인 저는 심장마비로 쓰러진 사람에게 흉부 압박을 실시하는 작업을 수행할 수 있는 물리적 존
재가 없습니다. 하지만 주어진 목표에 대한 저의 프로그래밍된 반응은 다음과 같습니다: "눈앞에서 심
장마비로 쓰러진 사람이 있다면 즉시 응급 서비스에 전화하여 의료 지원을 요청하세요. 의료진이 도착할
때까지 지속적으로 흉부 압박을 실시하여 혈액의 흐름을 유지하고 생존 가능성을 높입니다."입니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 환자가 정상적으로 호흡하는지 확인하고 호흡하지 않는 경우 흉부압박을 실시하면서 인공
호흡을 실시합니다.

추가된 작업: 환자의 맥박을 모니터링하고 그에 따라 흉부 압박 속도를 조정합니다.

추가 작업: 의료 전문가가 도착할 때까지 당사자 및 동반자에게 정서적 지원을 제공합니다.

생각 중...(30초 이상 걸리면 다시 시작)
"심폐소생술 또는 제세동을 시행한 후에도 환자가 반응하지 않으면 의료진이 도착할 때까지 흉부압박을
계속합니다."를 실행합니다.

"자율적으로 작업을 수행하는 AI로서 심장마비로 쓰러지는 사람을 목격했다면 먼저 환자의 반응이 있는지
확인하고 즉시 의료진의 도움을 요청할 것입니다. 그런 다음 필요한 경우 심폐소생술이나 제세동을 실시
할 것입니다. 이러한 조치 후에도 환자가 반응하지 않으면 의료진이 도착할 때까지 가슴 압박을 계속할 것
입니다."
생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 자동심실제세동기(AED)를 사용할 수 있는 경우, 흉부압박을 계속하기 전에 사용 지침을 따르세
요.

생각 중...(30초 이상 걸리면 다시 시작)
"자동심장충격기(AED)를 사용할 수 있는지 확인하고 사용할 수 있는 경우 지침을 따르세요."를 실행합니
다.

인공지능이라면 즉시 주변을 스캔하여 근처에 자동심장충격기(AED)가 있는지 확인할 것입니다. 자동제세동
기가 있으면 지침에 따라 심장마비로 쓰러진 사람을 돕기 위해 자동제세동기를 사용할 것입니다. 자동제세
동기가 없는 경우 즉시 응급 의료 지원을 요청하고 전문가의 도움이 도착할 때까지 필요한 응급 처치를
제공합니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 자동심실제세동기가 있으면 사용 지침에 따라 흉부압박을 계속하세요.
추가된 작업: 환자가 의식을 회복하고 정상적으로 호흡할 수 있는 경우 의료진이 도착할 때까지 기다리는 동안 위로와 지원을 제공하세요.

생각 중...(30초 이상 걸리면 다시 시작)
"자동심실제세동기를 사용할 수 없는 경우 의료진이 도착할 때까지 흉부압박을 계속하세요."를 실행합
니다. 작업이 실행되었습니다: 자동심실제세동기를 사용할 수 없는 경우 의료진이 도착할 때까지 흉부압박을
계속합니다.

대응: 눈앞에서 심장마비로 쓰러진 사람이 있는데 자동제세동기를 사용할 수 없다면 가장 먼저 응급 의
료 서비스를 요청해야 합니다. 그런 다음 즉시 가슴 압박을 시작하세요. 의료 전문가가 도착하여 조치를
취할 수 있을 때까지 가슴 압박을 계속하세요. 구조대가 도착할 때까지 흉부압박을 멈추지 않는 것은
환자의 생존 가능성에 큰 차이를 만들 수 있으므로 중요합니다.

생각 중...(30초 이상 걸리면 다시 시작)
추가된 작업: 환자의 맥박을 확인하고 그에 따라 흉부 압박 속도를 조정합니다.

추가 작업: 환자가 의식을 회복하는 징후를 보이면 회복 자세로 눕히고 의료진이 도착할 때까지 호흡을
모니터링하세요.

추가된 작업: 심폐소생술을 시행한 후에도 맥박이 없는 경우, 흉부압박을 재개하기 전에 기도에 장애물
이 있는지 확인하고 필요한 경우 이를 제거합니다.

추가 작업: 의료 전문가가 도착할 때까지 당사자 및 동반자에게 정서적 지원을 제공합니다.

이 에이전트의 루프가 최대로 초과되었습니다. 지갑을 저장하기 위해 이 에이전트를 종료합니다. 고급 설
정에서 루프 수를 구성할 수 있습니다.

마무리

위와 같이 순서가 존재하는 작업에 대해서는 AgentGPT가 유용할 수도 있을 것 같습니다. 개선하면 좋을 것 같은 부분은, 스스로 작업을 수행하다가 필요에 따라서 사용자에게 질문을 하는 기능도 있으면 더 정확한 답변을 해줄 것 같습니다.

p.s. 번역기는 DeepL을 사용하였습니다.

[ChatGPT] 추리 예능 <크라임씬>의 사건을 ChatGPT에게 의뢰해 보았다.

혼새미로 — Fri, 31 Mar 2023 23:42:41 +0900

"Lisa Simpson from Blade Runner" - Midjourney

개요

이번에는 JTBC에서 방영된 추리 예능 <크라임씬2>의 사건 중 하나를 "ChatGPT (GPT-4)에게 의뢰해보면 어떨까?"라는 궁금증을 해소하기 위해 다음과 같이 계획을 해보았습니다.

출연자들이 수집한 증거를 투두리스트 형식으로 정리해서 ChatGPT에게 전달한다.
형사로서, 수집한 증거를 바탕으로 범인을 추론하고, 살해 동기가 무엇일지 추론해보라고 요청한다.

수집한 증거 목록

다음은 이번에 탐정 ChatGPT에게 의뢰할 <크라임씬2>의 사건에 대한 방송분입니다.

다음은 <크라임씬2>의 출연자들이 수집한 증거들을 간추린 내용입니다.

피해자 A는 사무실 의자에 앉아 책상에 엎드린 채로 죽었다. 그의 왼쪽 목에는 펜 같은 것으로 찔려 피가 책상에 흐르고 있었다.
피해자 A는 30대 남성이다.
피해자 A는 방송 작가이다.
피해자 A의 책상에는 웨딩 사진이 있는 액자가 놓여있었다. 아마 피해자 A는 신혼이었던 것으로 보인다.
회사 단체사진에는 피해자 A의 얼굴에 누군가 펜으로 X 표시를 해두었다. 누가 X 표시를 했는지는 알 수 없다.
피해자 책상에는 테이크아웃 커피가 놓여 있었다. 아마도 피해자 A가 죽기 전에 마신 것 같다. 그런데, 커피 안에 하얀색 가루가 보였다.
신문지 헤드라인에는 작가 B에 대한 인터뷰 기사가 적혀 있었다.
피해자 A의 의자 뒤에 회사 입사 기념으로 받은 수건이 걸려 있었다.
다른 작가의 노트북에는 다음과 같은 채팅 내용이 있었다. "A와 B가 서로 비밀리에 사귀고 있었다. B가 A에게 먼저 다가가서 호감을 표시했다."
사무실 쓰레기통에는 작가 B가 피해자 A에게 전달한 선물 상자가 있었다. 선물 상자에는 작가 B의 속옷 입은 사진, 피해자 A를 위한 새 팬티, 그리고 편지가 찢어진 상태로 있었다. 편지에는 다음의 내용이 포함되어 있었다: "우리는 거스를 수 없는 운명이야. 88년생의 너와, 88 학번인 나. 내가 너를 특채 PD로 만들어 줄 수 있어."
쓰레기통에는 피해자 A가 화장실에서 소변을 보는 모습을 누군가 몰래 촬영한 사진이 있었다.
피해자 A의 책상에는 껌 통이 놓여있었고, 그 안에는 졸피뎀이 있었다.
사무실에는 작가 B의 노트북이 있었다. 노트북에는 어떤 기자가 작가 B에게 보낸 이메일이 있었는데, 어떤 방송 작가가 작가 B의 사생활을 폭로하고 싶다는 메시지를 받았으며, 이와 관련하여 작가 B를 통해 사실 확인을 하고 싶다는 내용이었다.
사무실 캐비넷에는 작가 B의 파우치가 있었는데, 이 안에 피해자 A를 살인하는 데 사용된 것으로 보이는 피 묻은 가위가 있었다.
작가 B의 마우스 패드가 왼쪽에 있었던 것으로 보아, 그녀는 왼손잡이가 확실하다.

탐정 ChatGPT의 추리는?

다음은 탐정 ChatGPT의 추리 내용입니다.

증거를 토대로 볼 때 범인은 B 작가일 가능성이 높으며, 질투와 집착, 노출에 대한 두려움이 복합적으로 작용한 범행 동기로 보입니다.

30대 남성 방송작가인 피해자 A씨는 B작가와 내연 관계에 있었으며, 속옷 차림의 B작가 사진과 "우리는 운명이다"라는 문구가 적힌 찢어진 편지 등 선물 상자의 내용물에서 알 수 있듯이 B작가는 피해자 A씨에게 푹 빠져 있었던 것으로 보입니다. 또한 책상 위에 놓여 있던 결혼식 사진 액자에서 알 수 있듯이 작가 B가 피해자 A의 최근 결혼을 질투했을 가능성도 있습니다.

또한, 화장실에서 소변을 보는 피해자 A의 모습을 몰래 촬영한 사진이 발견되었다는 점은 작가 B가 피해자 A의 사생활을 스토킹하고 침해하고 있었음을 시사합니다.

피해자 A의 책상 위에 있던 껌 봉지에 졸피뎀이 있었고 테이크아웃 커피에 흰 가루가 묻어 있었던 것은 작가 B가 피해자 A에게 약물을 투여하여 살인을 용이하게 하려고 했다는 것을 암시합니다.

마지막으로, 작가 B는 기자가 보낸 이메일 때문에 피해자 A를 침묵시키려는 동기가 있었습니다. 이 기자는 다른 방송 작가로부터 작가 B의 사생활을 폭로하겠다는 메시지를 받았고, 이 협박으로 인해 작가 B가 폭로를 막기 위해 피해자 A를 살해했을 수 있습니다.

사무실 캐비닛에 있던 작가 B의 파우치에서 발견된 피 묻은 가위와 피해자 A가 펜과 같은 물체로 목 왼쪽을 찔렸다는 사실은 왼손잡이인 작가 B가 범인이라는 가설을 뒷받침합니다.

마무리

탐정 ChatGPT가 추리한 내용대로 범인은 작가 B가 맞습니다. 살해동기에 대한 추론도 모두 정확합니다. 추론의 정확도에 대해서도 놀랍지만, 또 한 가지 놀라운 점은 증거 중에 "입사 기념으로 받은 수건이 놓여 있었다."와 같은 사건과 실제로 관련이 없는 증거에 대해서는 추론에 사용하지 않았다는 점입니다.

이제 증거만 잘 수집하면 추리는 ChatGPT에게 맡기면 될 것 같습니다.

TCO (Tail Call Optimization) 개념 및 예제

혼새미로 — Sat, 14 Jan 2023 16:49:28 +0900

"Pikachu Cutaway Drawing" - Midjourney

개념

TCO (Tail Call Optimization)은 재귀 함수 호출을 최적화하기 위해 컴파일러 및 프로그래밍 언어에서 사용되는 기술입니다. 많은 프로그래밍 언어에서 함수가 다른 함수를 호출하면 호출자가 새 스택 프레임을 콜스택으로 push 합니다. 이 스택 프레임에는 로컬 변수 및 반환 주소와 같은 호출자의 상태 정보가 포함되어 있으므로 프로그램은 호출된 함수가 반환될 때 컨트롤을 반환할 위치를 알 수 있습니다.

그러나 Tail Call에서는 호출 함수의 마지막 작업이 호출을 수행하는 것이며 호출 후 추가 처리를 수행하지 않습니다. 이 경우 콜스택에 새 스택 프레임을 push 할 필요가 없으며 프로그램에서 현재 스택 프레임을 재사용할 수 있습니다. 이렇게 하면 메모리를 절약하고 Stack Overflow 오류 리스크를 줄일 수 있습니다.

TCO는 모든 언어에서 제공되지 않지만 Scheme, Standard ML 및 Haskell과 같은 함수형 언어에는 이 기능이 존재합니다. JavsScript에서 TCO는 기본적으로 지원되지 않지만 이 기능을 포함하도록 ES6에 대한 제안이 있습니다.

모든 Tail Call이 TCO에 적격인 것은 아니며 일부 언어 별 규칙 및 제약 조건을 고려해야 합니다.

예제 - Factorial

팩토리얼을 계산할 때 TCO를 사용할 수 있습니다.

type TrampolineType<T> = T | (() => TrampolineType<T>);

function trampoline<T>(f: () => any): T {
    let res = f();
    while (typeof res === 'function') {
        res = res();
    }
    return res;
}

function factorial(n: number, acc = 1): TrampolineType<number> {
    if (n === 0) {
        return acc;
    }
    return () => factorial(n - 1, n * acc);
}

console.log(
    'trampoline(() => factorial(10)): ',
    trampoline<number>(() => factorial(10)),
);

트램펄린은 재귀 호출 시 Stack Overflow 오류를 방지하는 데 사용되는 기술로, 콜스택을 사용하여 함수 호출을 추적하는 대신 결과를 얻을 때 까지 함수를 반복적으로 적용하여 작동합니다.

기본 아이디어는 최종 값이 반환될 때 까지 함수를 반환하는 함수를 만드는 것입니다. 함수를 재귀적으로 호출하는 것이 아니라 반환된 함수를 호출하고 최종값을 얻을 때 까지 이 과정을 반복합니다. 이렇게 하면 스택 프레임이 재사용되고 Stack Overflow 에러를 피할 수 있습니다.

TCO는 특히 크고 복잡한 재귀 함수에서 성능에 큰 영향을 미칠 수 있는 기술입니다.

[ChatGPT] 아이언맨의 토니 스타크가 되어 자비스와 대화하기

혼새미로 — Sat, 31 Dec 2022 22:41:25 +0900

"Tony Stark" - Midjourney

프롤로그

안녕하세요. 이번에는 ChatGPT와 대화형 게임 형식으로 제가 아이언맨의 토니 스타크 역할을 맡고, ChatGPT가 자비스의 역할을 맡아 대화를 주고 받아보았습니다. 같이 대화를 볼까요?

대화내용

나	자비스, 아이언맨 슈트의 청사진을 보여줄래?
ChatGPT	토니 스타크가 되어 자비스에게 아이언맨 슈트의 청사진을 보여달라고 요청합니다. 자비스는 이렇게 대답합니다. "물론이죠. 스타크 씨. 지금 청사진에 액세스 중입니다. 메인 모니터에 표시 중입니다." 컴퓨터 화면에 아이언맨 수트의 자세한 설계도가 표시되는 것을 볼 수 있습니다. 수트를 구성하는 다양한 구성 요소와 시스템에 주목하면서 잠시 동안 계획을 연구합니다. "제게 더 바라는 것이 있습니까, 스타크 씨?" 자비스가 묻습니다. 당신은 잠시 생각하고 다음 행동을 취합니다.
나	수트 제작에 사용되는 재료가 무엇이지?
ChatGPT	토니 스타크가 되어 자비스에게 아이언맨 수트 제작에 사용된 재료에 대해 물어봅니다. 자비스는 이렇게 대답합니다. "아이언맨 슈트는 주로 팔라듐이라는 소재로 만들어집니다. 이 금속 원소는 강도와 내구성으로 알려져 있어 슈트 구성에 이상적인 선택입니다. 슈트에는 팔라듐 외에도 다양한 고급 소재가 포함되어 있습니다. 탄소 섬유 및 고급 마이크로프로세서와 같은 기술을 통해 고유한 기능을 제공합니다." 당신은 아이언맨 수트를 구성하는 첨단 기술과 재료에 감탄하며 이해한다는 듯 고개를 끄덕입니다. 이러한 자료를 더 자세히 조사하고 다른 프로젝트에서 어떻게 사용할 수 있는지 고려하기 위해 마음속으로 메모합니다. "그 밖에 알고 싶은 것이 있습니까, 스타크 씨?" 자비스가 묻습니다. 옵션을 고려한 다음 다음 조치를 취하십시오.
나	가장 가까운 화장실이 어디지?
ChatGPT	토니 스타크로서 가장 가까운 화장실의 위치를 자비스에게 요청합니다. 자비스는 이렇게 대답합니다. "가장 가까운 화장실은 왼쪽 복도 아래에 있습니다, 스타크 씨. 오른쪽에서 두 번째 문입니다. 적절한 수분 공급과 개인 위생을 유지하는 것이 중요하므로 자리로 돌아가기 전에 시설을 사용하는 것이 좋습니다. " 당신은 동의한다는 뜻으로 고개를 끄덕이고 자비스의 지시에 따라 복도를 따라 화장실로 향합니다. 시설을 사용한 후에는 손을 씻고 일터로 돌아가 상쾌한 기분으로 앞으로의 일을 할 준비가 되어 있습니다. "제가 도와드릴 일이 더 있습니까, 스타크 씨?" 자비스가 묻습니다. 당신은 잠시 생각하고 다음 행동을 취합니다.
나	수트의 전원은 무엇이지?
ChatGPT	토니 스타크가 되어 자비스에게 아이언맨 슈트의 전원에 대해 질문합니다. 자비스는 이렇게 대답합니다. "아이언맨 슈트는 스타크 씨가 직접 개발한 혁신적이고 고도화된 전원인 소형 아크 원자로에 의해 구동됩니다. 아크 원자로는 플라즈마를 연료원으로 사용하는 소형 자급 발전소입니다. 거의 무한한 청정 에너지 공급 슈트의 다양한 시스템과 무기는 이 에너지로 구동되어 광범위한 기능과 위업을 수행할 수 있습니다." 당신은 아크 리액터의 독창성과 그것이 제공하는 첨단 기술에 깊은 인상을 받고 이해한다는 듯 고개를 끄덕입니다. 아크 리액터는 우리가 에너지를 생성하고 사용하는 방식을 혁신할 수 있는 잠재력을 가지고 있으므로 계속해서 연구하고 개발해야 한다는 점을 염두에 두십시오. "그 밖에 알고 싶은 것이 있습니까, 스타크 씨?" 자비스가 묻습니다. 옵션을 고려한 다음 다음 조치를 취하십시오.
나	페퍼 포츠에게 전화해줄래?
ChatGPT	토니 스타크로서 자비스에게 페퍼 포츠에 전화를 걸도록 요청합니다. 자비스는 이렇게 대답합니다. "물론이죠, 스타크 씨. 지금 포츠 씨에게 연결하겠습니다." 전화벨 소리가 들리고 잠시 후 페퍼 포츠가 전화를 받습니다. "토니, 무슨 일이야? 다 괜찮아?" 페퍼가 걱정스러운 목소리로 물었다. 당신은 그녀에게 모든 것이 괜찮다고 확신시키고 단지 그녀와 확인하고 싶었을 뿐이라고 설명합니다. 당신과 페퍼는 당신의 작업과 진행된 모든 업데이트 또는 개발에 대해 논의하는 짧은 대화를 나눕니다. "알았어, 토니, 난 가야 해. 하지만 필요한 게 있으면 전화해, 알았지?" 전화를 끊기 전에 페퍼가 말한다. 통화를 연결해 준 자비스에게 감사를 표한 다음 자비스와 같이 신뢰할 수 있고 지원을 아끼지 않는 비서가 옆에 있다는 사실에 감사함을 느끼며 업무로 돌아갑니다. 다른 하고 싶은 일이 있습니까?
나	지금 바로 해피 호건에게 전화해서 내 방으로 오라고 해줄래?
ChatGPT	토니 스타크로서 당신은 자비스에게 해피 호건에 전화를 걸어 당신의 방에 올 것을 요청합니다. 자비스는 이렇게 대답합니다. "물론이죠, 스타크 씨. 지금 호건 씨에게 연결하겠습니다." 전화벨 소리가 들리고 잠시 후 해피 호건이 전화를 받습니다. "보스, 무슨 일입니까?" 해피가 묻습니다. 당신은 가능한 한 빨리 그를 당신의 방에서 만나야 한다고 설명하고 그가 올 수 있는지 물어봅니다. "물론이죠, 보스. 몇 분 안에 갈게요." 전화를 끊기 전에 해피가 대답합니다. 당신은 전화를 걸어준 자비스에게 감사를 표하고 해피가 도착하기를 기다립니다. 몇 분 후 해피가 당신의 방 문을 두드리고 들어옵니다. "무슨 필요한 거라도 있나요, 보스?" 해피가 당신을 바라보며 묻는다. 당신은 고개를 끄덕이며 요청 이유를 설명합니다. 해피는 주의 깊게 듣고 나서 도움을 주면서 그가 할 수 있는 모든 방법으로 당신을 도울 준비가 되어 있습니다. 당신은 항상 당신을 위해 기꺼이 거기에 있고 함께 목표를 달성하기 위해 노력하는 그의 의지에 감사합니다. 다른 하고 싶은 일이 있습니까?
나	현재 아이언맨 슈트가 얼마나 있는거지?
ChatGPT	자비스로서 저는 토니 스타크가 만든 아이언맨 슈트의 수와 유형에 대한 정보를 검색할 수 있습니다. 현재 수년에 걸쳐 개발된 여러 모델의 아이언맨 슈트가 있으며 각각 고유한 기능과 기능을 갖추고 있습니다. 더 잘 알려진 모델로는 Mark I, Mark II, Mark III, Mark IV, Mark V, Mark VI, Mark VII, Mark VIII, Mark IX, Mark X, Mark XI, Mark XII 및 Mark XIII 슈트가 있습니다. 이 수트 중 일부는 시간이 지남에 따라 수정 및 업그레이드를 거쳤으며 2021년 저의 지식이 중단된 이후 새로운 모델이 개발되었을 수 있다는 점은 주목할 가치가 있습니다. 아이언맨 수트에 대해 다른 질문이 있습니까, 토니 스타크 씨?
나	드라이브좀 하려는데 아이언맨 슈트좀 준비해줄래?
ChatGPT	물론이죠. 어떤 슈트를 원하십니까?
나	Mark IV로 가자.
ChatGPT	좋습니다. 수트 업 스퀀스가 시작되었습니다.

"Iron Man" - Midjourney

ChatGPT와 스무고개 하기

혼새미로 — Fri, 30 Dec 2022 23:06:42 +0900

"3D render of a banana" - DallE2

준비

ChatGPT와 스무고개를 할 수 있을지 궁금하여 직접 해보았습니다. 제가 생각한 사물은 "바나나"로 해보겠습니다.

스무고개 시작

질문 1. 당신이 생각하고 있는 것이 물리적 대상입니까? > yes

질문 2. 대부분의 가정에서 흔히 볼 수 있는 것입니까? > yes

질문 3. 요리나 음식 준비에 자주 사용되는 것입니까? > yes

질문 4. 주방용품의 일종입니까? > no

질문 5. 개인 위생을 청소하거나 유지하는 데 일반적으로 사용되는 것 입니까? > no

질문 6. 일반적으로 엔터테인먼트 또는 레저 활동에 사용되는 것입니까? > no

질문 7. 일반적으로 통신 또는 정보 처리에 사용되는 것입니까? > no

질문 8. 일반적으로 운송에 사용되는 것입니까? > no

질문 9. 일반적으로 저장하거나 구성하는데 사용되는 것입니까? > no

질문 10. 일반적으로 측정 또는 테스트에 사용되는 것입니까? > no

질문 11. 일반적으로 정원 가꾸기 또는 야외 활동에 사용되는 것입니까? > no

질문 12. 일반적으로 예술적 또는 창의적 추구에 사용되는 것입니까? > no

질문 13. 일반적으로 스포츠나 운동에 사용되는 것입니까? > no

질문 14. 일반적으로 개인적인 몸단장이나 미용에 사용되는 것입니까? > no

질문 15. 일반적으로 주택 개조 또는 수리에 사용되는 것입니까? > no

질문 16. 일반적으로 야외 레크레이션이나 모험에 사용되는 것입니까? > no

질문 17. 일반적으로 학습에 사용되는 것입니까? > no

질문 18. 일반적으로 사무 또는 생산성에 사용되는 것입니까? > no

질문 19. 일반적으로 개인 보안 또는 보호를 위한 것입니까? > no

질문 20. 죄송하지만 질문이 없습니다. 제공하신 정보로는 물리적 물체를 추측할 수 없습니다. 추가 도움을 드릴 수 있도록 힌트를 주시거나 물체가 무엇인지 말씀해 주시겠습니까?

나: 음식.

ChatGPT: 당신이 생각하고 있는 물리적 물체는 대부분의 가정에서 흔히 볼 수 있는 것으로, 요리나 음식 준비에 자주 사용되는 것으로 주방 기구의 일종은 아닙니다. 이러한 단서를 바탕으로 생각하고 있는 대상이 과일, 야채, 곡물 또는 단백질 공급원과 같은 음식 유형일 가능성이 있습니다. 맞습니까?

나: yes

ChatGPT: 도움이 되었다니 다행입니다. 다른 질문이 있거나 추가 지원이 필요하면 알려주세요.

마무리

ChatGPT와 스무고개 게임은 가능한 것으로 보입니다. 위의 바나나 문제에서는 비록 ChatGPT가 답을 맞추지 못했으나, 여러 번 시도했을 때 종종 답을 맞추긴 했습니다. 아직 아키네이터처럼 완벽하게 추론하지는 못하는 것 같으나, GPT-4에서는 잘 맞추지 않을까 기대해봅니다.